情報処理装置、画像送信方法及び画像送信プログラム
【課題】シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制すること。
【解決手段】サーバ装置１０は、ソフトウェアによる処理結果を示す画像を画像メモリに描画し、画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を動画化する。サーバ装置１０は、画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は高頻度の変更領域の画像に時刻情報を付加した上で端末装置へ送信する。サーバ装置１０は、端末装置から受信した時刻情報と、時刻情報が受信された時刻との差から、端末装置で描画遅延が発生しているか否かを判定する。サーバ装置１０は、描画遅延が発生している場合に、動画化が実行中でない場合には変更領域の動画化を開始させ、動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する。
【解決手段】サーバ装置１０は、ソフトウェアによる処理結果を示す画像を画像メモリに描画し、画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を動画化する。サーバ装置１０は、画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は高頻度の変更領域の画像に時刻情報を付加した上で端末装置へ送信する。サーバ装置１０は、端末装置から受信した時刻情報と、時刻情報が受信された時刻との差から、端末装置で描画遅延が発生しているか否かを判定する。サーバ装置１０は、描画遅延が発生している場合に、動画化が実行中でない場合には変更領域の動画化を開始させ、動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信方法及び画像送信プログラムに関する。
【背景技術】
【０００２】
シンクライアントというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持したりしているかのように振る舞う。
【０００４】
このように、サーバ及びクライアント間でクライアントに表示させる画面データを伝送する場合には、サーバ及びクライアント間のネットワークに輻輳が生じることによって伝送遅延が発生する場合がある。このネットワークの伝送遅延によって、サーバから伝送される画面データがクライアント側で描画されるのが遅れる結果、クライアントで行われる操作に対するレスポンスが悪化する。
【０００５】
ところで、ネットワークの伝送遅延を抑制する技術の一例として、ネットワーク帯域に合わせてメディアストリームデータの符号化ビット量、サンプリング周波数、フレームレート等を動的に変更する動的符号化レート変更方法が開示されている。この動的符号化レート変更方法では、端末間で符号化制御データが一定周期ごとに授受される。例えば、受信側の端末は、送信側の端末から、ヘッダ、送信時刻、要求サンプリング周波数、要求フレームレートや要求ビットレートなどを含む符号化制御データを受信する。そして、受信側の端末は、符号化制御データを用いて分析されるネットワーク帯域の分析結果から最適なフレームレートやビットレートを含む符号化制御データを生成した上で送信側の端末へ送信する。その後、送信側の端末は、受信側の端末から受信した符号化制御データにしたがって音声データおよび動画像を符号化することによりメディアストリームデータを生成し、メディアストリームデータを受信側の端末へ送信する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−２１４７５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記のシンクライアントシステムでは、以下に説明するように、シンクライアントの操作レスポンスを損なわずに、クライアント側での画面の描画遅延を抑制することができないという問題がある。
【０００８】
すなわち、ネットワークの伝送遅延を抑制するために、上記のシンクライアントシステムに動的符号化レート変更方法を援用することも考えられる。かかる援用を行った場合には、サーバ及びクライアント間のネットワーク帯域が狭くなるとサーバからクライアントへ伝送する画面データのフレームレートを画一的に落とすことになる。ところが、フレームレートを画一的に低下させたのでは、ネットワークの伝送遅延を抑制することによってクライアント側での画面の描画遅延は抑制できたとしても、クライアントでの画面の更新間隔も長くなるので、シンクライアントの操作レスポンスが悪化する。
【０００９】
開示の技術は、上記に鑑みてなされたものであって、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本願の開示する情報処理装置は、画像を記憶する画像メモリを有する。さらに、前記情報処理装置は、ソフトウェアによる処理結果を示す画像を前記画像メモリに描画する描画部を有する。さらに、前記情報処理装置は、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別する識別部を有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画化する動画化部を有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信する送信部を有する。さらに、前記情報処理装置は、前記端末装置から前記時刻情報を受信する受信部を有する。さらに、前記情報処理装置は、前記受信部によって受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定する判定部を有する。さらに、前記情報処理装置は、前記判定部によって前記画像の描画遅延が発生していると判定された場合に、前記動画化部による動画化が実行中でない場合には前記変更領域の動画化を前記動画化部に開始させ、前記動画化部による動画化が実行中である場合には前記送信部における画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する送信制御部を有する。
【発明の効果】
【００１１】
本願の開示する情報処理装置の一つの態様によれば、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【図２】図２は、デスクトップ画面の分割要領を説明するための図である。
【図３Ａ】図３Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図３Ｂ】図３Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図３Ｃ】図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４】図４は、メッシュ連結体の補正要領を説明するための図である。
【図５】図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。
【図６Ａ】図６Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図６Ｂ】図６Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図６Ｃ】図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７】図７は、実施例１に係る画像送信処理の手順を示すフローチャート（１）である。
【図８】図８は、実施例１に係る画像送信処理の手順を示すフローチャート（２）である。
【図９】図９は、実施例１に係る送信間隔変更処理の手順を示すフローチャートである。
【図１０Ａ】図１０Ａは、マップクリアの延長要領を説明するための図である。
【図１０Ｂ】図１０Ｂは、マップクリアの延長要領を説明するための図である。
【図１１Ａ】図１１Ａは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１１Ｂ】図１１Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１２】図１２は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１４】
［システム構成］
まず、本実施例に係るシンクライアントシステムの構成について説明する。図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【００１５】
図１に示すシンクライアントシステム１は、クライアント端末２０が表示する画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００１６】
図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末２０とを有する。なお、図１の例では、１つのサーバ装置１０に対し、１つのクライアント端末２０を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
【００１７】
これらサーバ装置１０及びクライアント端末２０は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコルには、一例として、ＶＮＣにおけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００１８】
サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことを「サーバ側リモート画面制御用アプリ」と記載する場合がある。
【００１９】
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
【００２０】
このほか、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一態様としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコードした上でクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。
【００２１】
クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal computer）など固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を採用することができる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことを「クライアント側リモート画面制御用アプリ」と記載する場合がある。
【００２２】
このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００２３】
さらに、クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードした上でブランク領域に表示する。
【００２４】
［サーバ装置の構成］
次に、本実施例に係るサーバ装置の機能的構成について説明する。図１に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、リモート画面制御部１４とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００２５】
ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。一態様としては、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行制御部１１ａは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。また、ＯＳ実行制御部１１ａは、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションのことを「アプリ」と記載する場合がある。
【００２６】
アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。
【００２７】
なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。
【００２８】
グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。例えば、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。
【００２９】
フレームバッファ１３は、グラフィックドライバ１２により描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００３０】
リモート画面制御部１４は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このリモート画面制御部１４は、図１に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄとを有する。さらに、リモート画面制御部１４は、第１のエンコーダ１４ｅと、第１の送信部１４ｆと、第２のエンコーダ１４ｇと、第２の送信部１４ｈと、ヘッダ受信部１４ｊと、描画遅延判定部１４ｋと、送信制御部１４ｍとを有する。
【００３１】
操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。また、操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
【００３２】
画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一態様としては、画面生成部１４ｂは、デスクトップ画面の更新間隔、例えば３３ｍｓｅｃが経過する度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。
【００３３】
変更頻度判別部１４ｃは、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、３３ｍｓｅｃ（ミリ秒）にわたって更新矩形の画像を蓄積する場合を想定する。
【００３４】
このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。
【００３５】
図２は、デスクトップ画面の分割要領を説明するための図である。図２に示す符号３０は、変更頻度判別用のマップを示す。図２に示す符号３１は、マップ３０に含まれるメッシュを指す。図２に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図２に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。
【００３６】
ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
【００３７】
図３Ａ〜図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図３Ａ〜図３Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図３Ａ及び図３Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図３Ａ〜図３Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
【００３８】
図３Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図３Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４１Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図３Ｃに示すマップ４０Ｎの結果が得られる。
【００３９】
そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図３Ｃの例で言えば、閾値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述の第２のエンコーダ１４ｇによりエンコードできる。なお、上記の「閾値」は、リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００４０】
高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
【００４１】
具体的に説明すると、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一態様としては、高頻度変更領域識別部１４ｄは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。
【００４２】
図４は、メッシュ連結体の補正要領を説明するための図である。図４に示す符号５１は補正前のメッシュ連結体を示す。図４に示す符号５２は補間領域を示す。また、図４に示す符号５３は補正後の矩形を示す。図４に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
【００４３】
高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。
【００４４】
図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。図５に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図５に示す符号６２は補間領域を指す。図５に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。図５に示すように、高頻度変更領域識別部１４ｄは、互いの距離が距離ｄ以内である高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。
【００４５】
このように高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これによって、クライアント端末２０で表示されるデスクトップ画面のビットマップ画像のうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
【００４６】
図６Ａ〜図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図６Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図６Ｂ〜図６Ｃに示す符号７０Ｂ及び符号７０Ｃは、変更頻度判別用のマップを示す。図６Ａに示す符号７１は、ブラウザ画面を指す。図６Ａに示す符号７２は、動画再生画面を指す。図６Ｂに示す符号７３は、マウスの移動軌跡を示す。図６Ｂに示す符号７４は、アプリによる動画再生領域を示す。
【００４７】
図６Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図６Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画再生領域７４で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、高頻度変更領域識別部１４ｄは、図６Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。
【００４８】
なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
【００４９】
このように、デスクトップ画面の一部に高頻度変更領域が検出された場合には、デスクトップ画面のうち当該高頻度変更領域の動画化が開始される。この場合には、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像が後述の送信制御部１４ｍによって後述の第１のエンコーダ１４ｅへ入力される。一方、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述の送信制御部１４ｍによって後述の第２のエンコーダ１４ｇへ入力される。
【００５０】
第１のエンコーダ１４ｅは、後述の送信制御部１４ｍから入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。一態様としては、第１のエンコーダ１４ｅは、各更新矩形の画像をＪＰＥＧで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、静止画の圧縮方式としてＪＰＥＧを例示したが、ＧＩＦ（Graphic Interchange Format）やＰＮＧ（Portable Network Graphics）などの他の方式を適用することもできる。
【００５１】
第１の送信部１４ｆは、第１のエンコーダ１４ｅによってエンコードされた更新矩形の符号化データをクライアント端末２０へ送信する処理部である。一態様としては、第１の送信部１４ｆは、後述の送信制御部１４ｍによってヘッダ情報の付加が指示された場合には、更新矩形の符号化データをクライアント端末２０へ送信するにあたってフレームＩＤ及び送信時刻のタイムスタンプ等のヘッダ情報を符号化データに付加した上でクライアント端末２０へ送信する。このとき、第１の送信部１４ｆは、第１のエンコーダ１４ｅによってエンコードされた全ての更新矩形の符号化データにヘッダ情報を付加することもできるが、更新矩形の符号化データのうち少なくとも１つの符号化データにヘッダ情報を付加すればよい。以下では、一例として、第１の送信部１４ｆは、同一のビットマップ画像から生成される更新矩形のうち最後に送信する更新矩形の符号化データにだけヘッダ情報を付加する場合を想定する。なお、上記の「フレームＩＤ」とは、フレームバッファ１３に描画されたビットマップ画像のフレーム番号を指す。また、「送信時刻」とは、更新矩形の符号化データが第１の送信部１４ｆによって送信される時刻を指す。
【００５２】
このように、全ての更新矩形の符号化データのうち１つの更新矩形の符号化データにヘッダ情報を付加して送信する場合には、次のような効果を実現できる。すなわち、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、後述の描画遅延判定部１４ｋによってクライアント側での描画遅延をフレーム単位で監視させることができる。このため、ネットワークのトラフィック及びクライアント端末２０の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
【００５３】
第２のエンコーダ１４ｇは、後述の送信制御部１４ｍから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第２のエンコーダ１４ｇは、高頻度変更領域または変更領域の画像をＭＰＥＧで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてＭＰＥＧを例示したが、Ｍｏｔｉｏｎ−ＪＰＥＧなどの他の方式を適用することもできる。
【００５４】
かかる第２のエンコーダ１４ｇには、高頻度変更領域識別部１４ｄによって高頻度変更領域が識別された場合には、高頻度変更領域の画像が後述の送信制御部１４ｍから入力される。このように、高頻度変更領域が識別されずとも、動画化が強制的に開始される場合には、その段階で変更頻度を判別する処理が切り上げられて、変更頻度判別用のマップ内で変更のあった変更領域の画像が後述の送信制御部１４ｍによって入力される。すなわち、動画化が強制的に開始された段階で変更頻度判別用のマップから変更回数の閾値判定を実行せずに、変更のあったメッシュに関し、上述したメッシュ連結体の生成、メッシュ連結体の矩形への補正や矩形の合成などが実行される。このようにして得られた変更領域の画像が後述の送信制御部１４ｍによって入力される。
【００５５】
第２の送信部１４ｈは、第２のエンコーダ１４ｇによってエンコードされた動画の符号化データをクライアント端末２０へ送信する処理部である。一態様としては、第２の送信部１４ｈは、後述の送信制御部１４ｍによってヘッダ情報の付加が指示された場合には、動画の符号化データのうち少なくともいずれか１つの符号化データにヘッダ情報を付加する。このように、動画の符号化データにヘッダ情報を付加した場合には、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、次のような効果を実現できる。すなわち、動画の符号化データが送信される場合には、クライアント端末２０で画面の更新で描画が実行される処理量が多くなる。このように、クライアント端末２０で描画遅延が発生する可能性が高くなる場面で、描画遅延のボトルネックとなりやすい動画の符号化データの描画にかかる処理負荷を基準にクライアント端末２０での描画遅延を監視できる。
【００５６】
ヘッダ受信部１４ｊは、クライアント端末２０から返信されたヘッダ情報を受信する処理部である。このヘッダ受信部１４ｊは、クライアント端末２０から受信したヘッダ情報を後述の描画遅延判定部１４ｋへ出力する。
【００５７】
描画遅延判定部１４ｋは、ヘッダ受信部１４ｊによって受信されたヘッダ情報に含まれる送信時刻と、当該ヘッダ情報の返信が受信された受信時刻との差から、クライアント端末２０で画面の描画遅延が発生しているか否かを判定する処理部である。
【００５８】
一態様としては、描画遅延判定部１４ｋは、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する。そして、描画遅延判定部１４ｋは、先のようにして算出した送信時刻と受信時刻との時間差が所定の閾値Ｔｈ１、例えば１００ｍｓｅｃ以上であるか否かを判定する。このように、時間差が閾値Ｔｈ１以上であるか否かによってネットワークの伝送遅延、ひいては伝送遅延に起因する描画遅延が発生しているか否かを判定できる。このとき、描画遅延判定部１４ｋは、送信時刻と受信時刻との時間差が閾値Ｔｈ１未満である場合には、送信時刻と受信時刻との時間差が所定のフレーム数、例えば５フレームにわたって所定の閾値Ｔｈ２、例えば５０ｍｓｅｃ以下であるか否かを判定する。このように、フレーム間で継続して時間差が閾値Ｔｈ２以上であるか否かによって、後述の送信制御部１４ｍが動画の符号化データの送信間隔を落とした場合に元の送信間隔に復帰させるか否かを判定できる。
【００５９】
送信制御部１４ｍは、デスクトップ画面の送信を制御する処理部である。かかる送信制御部１４ｍは、静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２が設定される図示しない送信間隔レジスタを用いて、更新矩形及び動画の符号化データの送信制御を実行する。ここで言う「送信間隔Ｆ１」とは、サーバ装置１０からクライアント端末２０へ静止画の符号化データを送信する間隔を指す。また、「送信間隔Ｆ２」とは、サーバ装置１０からクライアント端末２０へ動画の符号化データを送信する間隔を指す。なお、送信間隔レジスタには、例えば、静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２の初期値として３３ｍｓｅｃが設定されているものとする。
【００６０】
一態様としては、送信制御部１４ｍは、描画遅延判定部１４ｋによる描画遅延の判定結果に応じて動画の送信間隔Ｆ２を変更する制御を実行する。これを具体的に説明すると、送信制御部１４ｍは、描画遅延判定部１４ｋによって時間差が閾値Ｔｈ１以上であると判定された場合に、動画化を実行中であるか否かを判定する。このとき、動画化が未だ実行されていない場合には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、送信制御部１４ｍは、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第２のエンコーダ１４ｇへ入力することによって、動画化を強制的に開始する。このように、静止画によるエンコードよりも圧縮率が高い動画によるエンコードを実行させることにより、ネットワークのトラフィックを軽減させる制御を実行する。一方、動画化が実行中である場合には、クライアント端末２０の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、送信制御部１４ｍは、動画の送信間隔Ｆ２を変更前よりも長い送信間隔に変更する。例えば、送信制御部１４ｍは、初期値である３３ｍｓｅｃから１００ｍｓｅｃへ送信間隔Ｆ２を変更する。これによって、クライアント端末２０にデコードさせる処理量をクライアント端末２０の性能に合わせることにより、クライアント端末２０での画面の描画遅延を抑制する。なお、送信間隔Ｆ２は、初期値である３３ｍｓｅｃから１００ｍｓｅｃへ既に引き下げられている場合には、１００ｍｓｅｃが維持される。
【００６１】
このように、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始し、クライアント端末２０の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。それゆえ、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できる。
【００６２】
また、送信制御部１４ｍは、描画遅延判定部１４ｋによって時間差が所定のフレーム数にわたって閾値Ｔｈ２以下であると判定された場合に、動画の送信間隔Ｆ２を変更前の送信間隔に戻す。例えば、送信制御部１４ｍは、１００ｍｓｅｃに引き下げられていた送信間隔Ｆ２を初期値である３３ｍｓｅｃに戻す。これは、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下である場合には、静止画および動画の符号化データの伝送および静止画および動画の符号化データのデコードが安定していると推定できるからである。
【００６３】
他の一態様としては、送信制御部１４ｍは、第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇへ画像を入力する。これを具体的に説明すると、まず、送信制御部１４ｍは、送信間隔レジスタから送信間隔Ｆ１及び送信間隔Ｆ２を読み出す。その上で、送信制御部１４ｍは、動画化が実行中である場合には、前回に動画の符号化データを送信してから経過した送信経過時間ｔ２が送信間隔Ｆ２に到達したか否か、すなわち送信経過時間ｔ２≧送信間隔Ｆ２であるか否かを判定する。このとき、送信制御部１４ｍは、送信経過時間ｔ２≧送信間隔Ｆ２である場合には、高頻度変更領域または変更領域の画像を第２のエンコーダ１４ｇへ入力する。一方、送信制御部１４ｍは、送信経過時間ｔ２＜送信間隔Ｆ２である場合には、高頻度変更領域または変更領域の画像を第２のエンコーダ１４ｇへ入力せず、送信間隔Ｆ２を経過するまで待機させる。
【００６４】
また、送信制御部１４ｍは、前回に更新矩形の画像の符号化データを送信してから経過した送信経過時間ｔ１が送信間隔Ｆ１に到達したか否か、すなわち送信経過時間ｔ１≧送信間隔Ｆ１であるか否かを判定する。このとき、送信制御部１４ｍは、送信経過時間ｔ１≧送信間隔Ｆ１である場合には、高頻度変更領域に含まれない更新矩形の画像を第１のエンコーダ１４ｅへ入力する。一方、送信制御部１４ｍは、送信経過時間ｔ１＜送信間隔Ｆ１である場合には、更新矩形の画像を第１のエンコーダ１４ｅへ入力せず、送信間隔Ｆ１を経過するまで待機させる。
【００６５】
その後、送信制御部１４ｍは、更新矩形の画像、高頻度変更領域または変更領域の画像のいずれかを第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇへ入力したか、すなわち送信データがあるか否かを判定する。このとき、送信制御部１４ｍは、送信データが存在する場合には、第１の送信部１４ｆまたは第２の送信部１４ｈのいずれかにヘッダ情報を付加させる。例えば、送信制御部１４ｍは、第１のエンコーダ１４ｅだけに画像が入力された場合、あるいは第１のエンコーダ１４ｅ及び第２のエンコーダ１４ｇの両方へ画像が入力された場合には、第１の送信部１４ｆにヘッダ情報を付加するように指示する。一方、送信制御部１４ｍは、第２のエンコーダ１４ｇにしか画像が入力されなかった場合には、第２の送信部１４ｈにヘッダ情報を付加するように指示する。また、送信制御部１４ｍは、第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇのいずれにも画像が入力されなかった場合には、送信データがないので、ヘッダ情報を付加する指示は実行しない。
【００６６】
なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００６７】
［クライアント端末の構成］
次に、本実施例に係るクライアント端末の機能的構成について説明する。図１に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側のリモート画面制御部２３とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
【００６８】
入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス機能を実現する。
【００６９】
表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。
【００７０】
リモート画面制御部２３は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部２３は、図１に示すように、操作情報通知部２３ａと、第１の受信部２３ｂと、第１のデコーダ２３ｃと、第１の表示制御部２３ｄとを有する。さらに、リモート画面制御部２３は、第２の受信部２３ｅと、第２のデコーダ２３ｆと、第２の表示制御部２３ｇと、ヘッダ返信部２３ｈとを有する。
【００７１】
操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一態様としては、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００７２】
第１の受信部２３ｂは、サーバ装置１０の第１の送信部１４ｆにより送信された更新矩形の符号化データを受信する処理部である。一態様としては、第１の受信部２３ｂは、サーバ装置１０から受信した更新矩形の符号化データからヘッダ情報を取り出し、ヘッダ情報については第１の表示制御部２３ｄへ出力する一方で、更新矩形の符号化データについては第１のデコーダ２３ｃへ出力する。これによって、ヘッダ情報だけデコードをスキップさせる。なお、第１の受信部２３ｂは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。
【００７３】
第１のデコーダ２３ｃは、第１の受信部２３ｂによって受信された更新矩形の符号化データをデコードする処理部である。この第１のデコーダ２３ｃには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
【００７４】
第１の表示制御部２３ｄは、第１のデコーダ２３ｃによってデコードされた更新矩形の画像を表示部２２に表示させる処理部である。一態様としては、第１の表示制御部２３ｄは、第１の受信部２３ｂによって受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。また、第１の表示制御部２３ｄは、第１の受信部２３ｂによって高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｄは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。このようにして画面の描画が終了すると、第１の表示制御部２３ｄは、第１の受信部２３ｂから入力されたヘッダ情報を後述のヘッダ返信部２３へ出力する。
【００７５】
第２の受信部２３ｅは、サーバ装置１０の第２の送信部１４ｈにより送信された動画の符号化データを受信する処理部である。この第２の受信部２３ｅは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。
【００７６】
第２のデコーダ２３ｆは、第２の受信部２３ｅによって受信された動画の符号化データをデコードする処理部である。この第２のデコーダ２３ｆには、サーバ装置１０に搭載されたエンコード方式に適合するデコード方式のデコーダが搭載される。
【００７７】
第２の表示制御部２３ｇは、第２の受信部２３ｅによって受信された高頻度変更領域の属性情報に基づき、第２のデコーダ２３ｆによってデコードされた高頻度変更領域または変更領域の画像を表示部２２に表示させる処理部である。一態様としては、第２の表示制御部２３ｇは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域の動画を再生させる。なお、動画の符号化データにヘッダ情報が付加されていた場合には、静止画の場合と同様に、デコードおよび画面の描画が終了した段階で後述のヘッダ返信部２３ｈへ出力する。
【００７８】
ヘッダ返信部２３ｈは、ヘッダ情報をサーバ装置１０へ返信する処理部である。一態様としては、ヘッダ返信部２３ｈは、サーバ装置１０から第１の受信部２３ｂ及び第１の表示制御部２３ｄを経由して入力されたヘッダ情報をサーバ装置１０へ送信する。このようにヘッダ情報を返信することによって、サーバ装置１０側で送信時刻と返信時刻の時間差から、ネットワークの伝送遅延、ひいては画面の描画遅延を推定することが可能になる。
【００７９】
なお、クライアント側のリモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣやＦＰＧＡが挙げられる。また、電子回路としては、ＣＰＵやＭＰＵなどが挙げられる。
【００８０】
［処理の流れ］
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。なお、ここでは、サーバ装置１０によって実行される（１）画像送信処理を説明した後に、（２）送信間隔変更処理を説明する。
【００８１】
（１）画像送信処理
図７及び図８は、実施例１に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０によって実行される処理であり、クライアント端末２０が起動されている限り繰り返し実行する処理である。
【００８２】
図７に示すように、サーバ装置１０は、送信間隔レジスタに記憶された静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２に初期値「３３ｍｓｅｃ」を書き込む初期化を実行する（ステップＳ１０１）。
【００８３】
その後、サーバ装置１０は、フレームバッファ１３にビットマップ画像が描画されて前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成されると（ステップＳ１０２肯定）、次のような処理を実行する。すなわち、サーバ装置１０は、送信間隔レジスタから静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２を読み出す（ステップＳ１０３）。
【００８４】
そして、サーバ装置１０は、先に生成された更新矩形の画像から更新矩形送信用のパケットを生成し（ステップＳ１０４）、生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０５）。
【００８５】
このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０６否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、図８に示すステップＳ１１５へ移行する。
【００８６】
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０６肯定）には、サーバ装置１０は、次のような処理を行う。すなわち、サーバ装置１０は、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０７）。そして、サーバ装置１０は、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する（ステップＳ１０８）。
【００８７】
その後、サーバ装置１０は、変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０９）。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合（ステップＳ１０９否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１４へ移行する。
【００８８】
一方、変更頻度がしきい値を超えるメッシュが存在する場合（ステップＳ１０９肯定）には、サーバ装置１０は、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１１０）。
【００８９】
そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１１１肯定）には、サーバ装置１０は、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１２）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１１１否定）には、矩形の合成を行わずにステップＳ１１３へ移行する。
【００９０】
続いて、サーバ装置１０は、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１３）。そして、サーバ装置１０は、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする（ステップＳ１１４）。
【００９１】
その後、図８に示すように、動画化が実行中である場合（ステップＳ１１５肯定）には、サーバ装置１０は、動画の送信経過時間ｔ２が送信間隔Ｆ２に到達したか否か、すなわち送信経過時間ｔ２≧送信間隔Ｆ２であるか否かを判定する（ステップＳ１１６）。
【００９２】
このとき、送信経過時間ｔ２≧送信間隔Ｆ２である場合（ステップＳ１１６肯定）には、サーバ装置１０は、高頻度変更領域または変更領域の画像を動画の符号化データへエンコードする（ステップＳ１１７）。
【００９３】
一方、送信経過時間ｔ２＜送信間隔Ｆ２である場合（ステップＳ１１６否定）には、サーバ装置１０は、動画の符号化データの送信間隔を空ける必要があるので、ステップＳ１１７をスキップし、ステップＳ１１８へ移行する。
【００９４】
続いて、サーバ装置１０は、静止画の送信経過時間ｔ１が送信間隔Ｆ１に到達したか否か、すなわち送信経過時間ｔ１≧送信間隔Ｆ１であるか否かを判定する（ステップＳ１１８）。
【００９５】
このとき、送信経過時間ｔ１≧送信間隔Ｆ１である場合（ステップＳ１１８肯定）には、サーバ装置１０は、更新矩形の画像を静止画の符号化データへエンコードする（ステップＳ１１９）。
【００９６】
一方、送信経過時間ｔ１＜送信間隔Ｆ１である場合（ステップＳ１１８否定）には、サーバ装置１０は、静止画の符号化データの送信間隔を空ける必要があるので、ステップＳ１１９をスキップし、ステップＳ１２０へ移行する。
【００９７】
そして、ステップＳ１１７またはステップＳ１１９の処理でエンコードされた静止画または動画の符号化データ、すなわち送信データが存在する場合（ステップＳ１２０肯定）には、サーバ装置１０は、次のような処理を実行する。すなわち、サーバ装置１０は、静止画または動画のいずれかの符号化データにフレームＩＤ及び送信時刻を含むヘッダ情報を付加する（ステップＳ１２１）。その上で、サーバ装置１０は、静止画の符号化データ及び／又は動画の符号化データの送信データをクライアント端末２０へ送信する（ステップＳ１２２）。
【００９８】
その後、サーバ装置１０は、ステップＳ１０２の処理に戻り、クライアント端末２０が起動している限り、ステップＳ１０２〜ステップＳ１２２までの処理を繰り返し実行する。なお、クライアント端末２０の電源がシャットダウンされた場合には、サーバ装置１０は、処理を終了する。
【００９９】
（２）送信間隔変更処理
次に、本実施例に係る送信間隔変更処理について説明する。図９は、実施例１に係る送信間隔変更処理の手順を示すフローチャートである。この送信間隔変更処理は、サーバ装置１０によって実行される処理であり、クライアント端末２０が起動中である限り、繰り返し実行される。
【０１００】
図９に示すように、ヘッダ情報の返信を受信すると（ステップＳ２０１肯定）、サーバ装置１０は、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する（ステップＳ２０２）。
【０１０１】
そして、サーバ装置１０は、ステップＳ２０１のようにして算出した送信時刻と受信時刻との時間差が閾値Ｔｈ１以上であるか否かを判定する（ステップＳ２０３）。このとき、時間差が閾値Ｔｈ１以上である場合（ステップＳ２０３肯定）には、サーバ装置１０は、動画化を実行中であるか否かをさらに判定する（ステップＳ２０４）。
【０１０２】
ここで、動画化が未だ実行されていない場合（ステップＳ２０４否定）には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、サーバ装置１０は、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第２のエンコーダ１４ｇへ入力することによって、動画化を強制的に開始する（ステップＳ２０５）。
【０１０３】
一方、動画化が実行中である場合（ステップＳ２０４肯定）には、クライアント端末２０の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、サーバ装置１０は、動画の送信間隔Ｆ２を変更前よりも長い送信間隔に変更する（ステップＳ２０６）。
【０１０４】
また、送信時刻と受信時刻との時間差が閾値Ｔｈ１未満（ステップＳ２０３否定）である場合には、サーバ装置１０は、送信時刻と受信時刻との時間差が所定のフレーム数にわたって閾値Ｔｈ２以下であるか否かをさらに判定する（ステップＳ２０７）。
【０１０５】
このとき、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下である場合（ステップＳ２０７肯定）には、サーバ装置１０は、動画の送信間隔Ｆ２を変更前の送信間隔に戻す（ステップＳ２０８）。なお、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下でない場合（ステップＳ２０７否定）には、送信間隔を戻さずに、上記のステップＳ２０１へ移行する。
【０１０６】
上記のステップＳ２０５、ステップＳ２０６またはステップＳ２０８の処理が終了すると、サーバ装置１０は、ステップＳ２０１の処理へ戻り、クライアント端末２０が起動中である限り、ステップＳ２０１〜ステップＳ２０８までの処理を繰り返し実行する。なお、クライアント端末２０の電源がシャットダウンされた場合には、サーバ装置１０は、処理を終了する。
【０１０７】
［実施例１の効果］
上述してきたように、本実施例に係るサーバ装置１０では、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始する。また、本実施例に係るサーバ装置１０では、クライアント端末２０の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。したがって、本実施例に係るサーバ装置１０によれば、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制することが可能になる。
【０１０８】
また、本実施例に係るサーバ装置１０は、変更領域の画像が複数存在する場合に、少なくとも１つの変更領域の画像にヘッダ情報を付加する。このため、本実施例に係るサーバ装置１０では、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、クライアント側での描画遅延をフレーム単位で監視することができる。よって、本実施例に係るサーバ装置１０によれば、ネットワークのトラフィック及びクライアント端末２０の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
【０１０９】
さらに、本実施例に係るサーバ装置１０は、クライアント端末２０で描画遅延が発生していない場合に、動画の符号化データを送信させる送信間隔Ｆ２を変更前の送信間隔に戻す。よって、本実施例に係るサーバ装置１０によれば、クライアント端末２０がネットワークの伝送遅延や描画遅延から復帰した場合には、動画の符号化データの送信をセーブせずに元の操作レスポンスを提供できる。
【実施例２】
【０１１０】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１１１】
［マップクリアの延長］
例えば、上記の実施例１では、高頻度変更領域識別部１４ｄが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。
【０１１２】
一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。
【０１１３】
図１０Ａ及び図１０Ｂは、マップクリアの延長要領を説明するための図である。図１０Ａの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ８０Ａと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。また、図１０Ｂの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ８０Ｂと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。
【０１１４】
図１０Ａに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果８１Ａが得られた場合には、以降に変更回数が閾値を超えるメッシュ連結体が取得されなくとも識別結果８１Ａを所定の期間引き継ぐ。すなわち、図１０Ｂに示すように、マップ８０Ａで変更回数が閾値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果８１Ａを識別してから所定の期間内であれば高頻度変更領域の識別結果８１Ａを引き継ぐ。なお、上記の「閾値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【０１１５】
これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【０１１６】
［高頻度変更領域の縮小の抑制］
他の一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、当該縮小した度合いが所定の閾値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。
【０１１７】
図１１Ａ及び図１１Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図１１Ａの例では、時点Ｔ１の変更頻度判別用のマップ９０Ａと高頻度変更領域の識別結果９１Ａとを図示している。また、図１１Ｂの例では、時点Ｔ２の変更頻度判別用のマップ９０Ｂと高頻度変更領域の識別結果９１Ａとを図示している。なお、上記の時点Ｔ１および時点Ｔ２はＴ１＜Ｔ２であるものとする。
【０１１８】
図１１Ａに示すように、マップ９０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果９１Ａが得られた場合には、時点Ｔ１以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図１１Ｂに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定の閾値、例えば半分以下であるならば、高頻度変更領域の識別結果９１Ａを引き継ぐ。
【０１１９】
これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【０１２０】
［送信間隔変更の多段化］
また、上記の実施例１では、動画の送信間隔Ｆ２を初期値である３３ｍｓｅｃと１００ｍｓｅｃとの２つの値の間で遷移させる場合を例示したが、３つ以上の値の間を遷移させることとしてもかまわない。このように、３つ以上の値の間を遷移させる場合には、送信時刻と受信時刻の時間差が大きくなるほど長い送信間隔の値を割り当てるようにすればよい。
【０１２１】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１２２】
例えば、サーバ装置１０の第１の送信部１４ｆ及び第２の送信部１４ｈが実行する画像の送信処理を１つの送信部に統合することとしてもよい。また、クライアント端末２０の第１の受信部２３ｂ及び第２の受信部２３ｅが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第１の表示制御部２３ｄ及び第２の表示制御部２３ｇが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。
【０１２３】
［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１２を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。
【０１２４】
図１２は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図１２に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１２５】
ＨＤＤ１７０には、図１２に示すように、上記の実施例１で示したサーバ側のリモート画面制御部１４と同様の機能を発揮する画像送信プログラム１７０ａが予め記憶される。この画像送信プログラム１７０ａについては、図１に示した各々のリモート画面制御部１４に含まれる各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。
【０１２６】
そして、ＣＰＵ１５０が、画像送信プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１２に示すように、画像送信プログラム１７０ａは、画像送信プロセス１８０ａとして機能する。この画像送信プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス１８０ａは、図１に示したリモート画面制御部１４にて実行される処理、例えば図７〜図９に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１２７】
なお、上記の画像送信プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１２８】
１ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ 第１のエンコーダ
１４ｆ 第１の送信部
１４ｇ 第２のエンコーダ
１４ｈ 第２の送信部
１４ｊ ヘッダ受信部
１４ｋ 描画遅延判定部
１４ｍ 送信制御部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の受信部
２３ｃ 第１のデコーダ
２３ｄ 第１の表示制御部
２３ｅ 第２の受信部
２３ｆ 第２のデコーダ
２３ｇ 第２の表示制御部
２３ｈ ヘッダ返信部
【技術分野】
【０００１】
本発明は、情報処理装置、画像送信方法及び画像送信プログラムに関する。
【背景技術】
【０００２】
シンクライアントというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。
【０００３】
かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持したりしているかのように振る舞う。
【０００４】
このように、サーバ及びクライアント間でクライアントに表示させる画面データを伝送する場合には、サーバ及びクライアント間のネットワークに輻輳が生じることによって伝送遅延が発生する場合がある。このネットワークの伝送遅延によって、サーバから伝送される画面データがクライアント側で描画されるのが遅れる結果、クライアントで行われる操作に対するレスポンスが悪化する。
【０００５】
ところで、ネットワークの伝送遅延を抑制する技術の一例として、ネットワーク帯域に合わせてメディアストリームデータの符号化ビット量、サンプリング周波数、フレームレート等を動的に変更する動的符号化レート変更方法が開示されている。この動的符号化レート変更方法では、端末間で符号化制御データが一定周期ごとに授受される。例えば、受信側の端末は、送信側の端末から、ヘッダ、送信時刻、要求サンプリング周波数、要求フレームレートや要求ビットレートなどを含む符号化制御データを受信する。そして、受信側の端末は、符号化制御データを用いて分析されるネットワーク帯域の分析結果から最適なフレームレートやビットレートを含む符号化制御データを生成した上で送信側の端末へ送信する。その後、送信側の端末は、受信側の端末から受信した符号化制御データにしたがって音声データおよび動画像を符号化することによりメディアストリームデータを生成し、メディアストリームデータを受信側の端末へ送信する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−２１４７５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記のシンクライアントシステムでは、以下に説明するように、シンクライアントの操作レスポンスを損なわずに、クライアント側での画面の描画遅延を抑制することができないという問題がある。
【０００８】
すなわち、ネットワークの伝送遅延を抑制するために、上記のシンクライアントシステムに動的符号化レート変更方法を援用することも考えられる。かかる援用を行った場合には、サーバ及びクライアント間のネットワーク帯域が狭くなるとサーバからクライアントへ伝送する画面データのフレームレートを画一的に落とすことになる。ところが、フレームレートを画一的に低下させたのでは、ネットワークの伝送遅延を抑制することによってクライアント側での画面の描画遅延は抑制できたとしても、クライアントでの画面の更新間隔も長くなるので、シンクライアントの操作レスポンスが悪化する。
【０００９】
開示の技術は、上記に鑑みてなされたものであって、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本願の開示する情報処理装置は、画像を記憶する画像メモリを有する。さらに、前記情報処理装置は、ソフトウェアによる処理結果を示す画像を前記画像メモリに描画する描画部を有する。さらに、前記情報処理装置は、前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別する識別部を有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画化する動画化部を有する。さらに、前記情報処理装置は、前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信する送信部を有する。さらに、前記情報処理装置は、前記端末装置から前記時刻情報を受信する受信部を有する。さらに、前記情報処理装置は、前記受信部によって受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定する判定部を有する。さらに、前記情報処理装置は、前記判定部によって前記画像の描画遅延が発生していると判定された場合に、前記動画化部による動画化が実行中でない場合には前記変更領域の動画化を前記動画化部に開始させ、前記動画化部による動画化が実行中である場合には前記送信部における画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する送信制御部を有する。
【発明の効果】
【００１１】
本願の開示する情報処理装置の一つの態様によれば、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【図２】図２は、デスクトップ画面の分割要領を説明するための図である。
【図３Ａ】図３Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図３Ｂ】図３Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図３Ｃ】図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。
【図４】図４は、メッシュ連結体の補正要領を説明するための図である。
【図５】図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。
【図６Ａ】図６Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図６Ｂ】図６Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図６Ｃ】図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。
【図７】図７は、実施例１に係る画像送信処理の手順を示すフローチャート（１）である。
【図８】図８は、実施例１に係る画像送信処理の手順を示すフローチャート（２）である。
【図９】図９は、実施例１に係る送信間隔変更処理の手順を示すフローチャートである。
【図１０Ａ】図１０Ａは、マップクリアの延長要領を説明するための図である。
【図１０Ｂ】図１０Ｂは、マップクリアの延長要領を説明するための図である。
【図１１Ａ】図１１Ａは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１１Ｂ】図１１Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。
【図１２】図１２は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１４】
［システム構成］
まず、本実施例に係るシンクライアントシステムの構成について説明する。図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
【００１５】
図１に示すシンクライアントシステム１は、クライアント端末２０が表示する画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。
【００１６】
図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末２０とを有する。なお、図１の例では、１つのサーバ装置１０に対し、１つのクライアント端末２０を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
【００１７】
これらサーバ装置１０及びクライアント端末２０は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコルには、一例として、ＶＮＣにおけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。
【００１８】
サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことを「サーバ側リモート画面制御用アプリ」と記載する場合がある。
【００１９】
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側リモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
【００２０】
このほか、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一態様としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式のデータにエンコードした上でクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ（Moving Picture Experts Group）方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。
【００２１】
クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal computer）など固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を採用することができる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことを「クライアント側リモート画面制御用アプリ」と記載する場合がある。
【００２２】
このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００２３】
さらに、クライアント側リモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードした上でブランク領域に表示する。
【００２４】
［サーバ装置の構成］
次に、本実施例に係るサーバ装置の機能的構成について説明する。図１に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、リモート画面制御部１４とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
【００２５】
ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。一態様としては、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行制御部１１ａは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。また、ＯＳ実行制御部１１ａは、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションのことを「アプリ」と記載する場合がある。
【００２６】
アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。
【００２７】
なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。
【００２８】
グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。例えば、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。
【００２９】
フレームバッファ１３は、グラフィックドライバ１２により描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
【００３０】
リモート画面制御部１４は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このリモート画面制御部１４は、図１に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄとを有する。さらに、リモート画面制御部１４は、第１のエンコーダ１４ｅと、第１の送信部１４ｆと、第２のエンコーダ１４ｇと、第２の送信部１４ｈと、ヘッダ受信部１４ｊと、描画遅延判定部１４ｋと、送信制御部１４ｍとを有する。
【００３１】
操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。また、操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
【００３２】
画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一態様としては、画面生成部１４ｂは、デスクトップ画面の更新間隔、例えば３３ｍｓｅｃが経過する度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。
【００３３】
変更頻度判別部１４ｃは、フレームバッファ１３に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、３３ｍｓｅｃ（ミリ秒）にわたって更新矩形の画像を蓄積する場合を想定する。
【００３４】
このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。
【００３５】
図２は、デスクトップ画面の分割要領を説明するための図である。図２に示す符号３０は、変更頻度判別用のマップを示す。図２に示す符号３１は、マップ３０に含まれるメッシュを指す。図２に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図２に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。
【００３６】
ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
【００３７】
図３Ａ〜図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図３Ａ〜図３Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図３Ａ及び図３Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図３Ａ〜図３Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
【００３８】
図３Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図３Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４１Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図３Ｃに示すマップ４０Ｎの結果が得られる。
【００３９】
そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図３Ｃの例で言えば、閾値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述の第２のエンコーダ１４ｇによりエンコードできる。なお、上記の「閾値」は、リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【００４０】
高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
【００４１】
具体的に説明すると、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一態様としては、高頻度変更領域識別部１４ｄは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。
【００４２】
図４は、メッシュ連結体の補正要領を説明するための図である。図４に示す符号５１は補正前のメッシュ連結体を示す。図４に示す符号５２は補間領域を示す。また、図４に示す符号５３は補正後の矩形を示す。図４に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
【００４３】
高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。
【００４４】
図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。図５に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図５に示す符号６２は補間領域を指す。図５に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。図５に示すように、高頻度変更領域識別部１４ｄは、互いの距離が距離ｄ以内である高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。
【００４５】
このように高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これによって、クライアント端末２０で表示されるデスクトップ画面のビットマップ画像のうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
【００４６】
図６Ａ〜図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図６Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図６Ｂ〜図６Ｃに示す符号７０Ｂ及び符号７０Ｃは、変更頻度判別用のマップを示す。図６Ａに示す符号７１は、ブラウザ画面を指す。図６Ａに示す符号７２は、動画再生画面を指す。図６Ｂに示す符号７３は、マウスの移動軌跡を示す。図６Ｂに示す符号７４は、アプリによる動画再生領域を示す。
【００４７】
図６Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図６Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画再生領域７４で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、高頻度変更領域識別部１４ｄは、図６Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。
【００４８】
なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
【００４９】
このように、デスクトップ画面の一部に高頻度変更領域が検出された場合には、デスクトップ画面のうち当該高頻度変更領域の動画化が開始される。この場合には、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像が後述の送信制御部１４ｍによって後述の第１のエンコーダ１４ｅへ入力される。一方、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述の送信制御部１４ｍによって後述の第２のエンコーダ１４ｇへ入力される。
【００５０】
第１のエンコーダ１４ｅは、後述の送信制御部１４ｍから入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。一態様としては、第１のエンコーダ１４ｅは、各更新矩形の画像をＪＰＥＧで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、静止画の圧縮方式としてＪＰＥＧを例示したが、ＧＩＦ（Graphic Interchange Format）やＰＮＧ（Portable Network Graphics）などの他の方式を適用することもできる。
【００５１】
第１の送信部１４ｆは、第１のエンコーダ１４ｅによってエンコードされた更新矩形の符号化データをクライアント端末２０へ送信する処理部である。一態様としては、第１の送信部１４ｆは、後述の送信制御部１４ｍによってヘッダ情報の付加が指示された場合には、更新矩形の符号化データをクライアント端末２０へ送信するにあたってフレームＩＤ及び送信時刻のタイムスタンプ等のヘッダ情報を符号化データに付加した上でクライアント端末２０へ送信する。このとき、第１の送信部１４ｆは、第１のエンコーダ１４ｅによってエンコードされた全ての更新矩形の符号化データにヘッダ情報を付加することもできるが、更新矩形の符号化データのうち少なくとも１つの符号化データにヘッダ情報を付加すればよい。以下では、一例として、第１の送信部１４ｆは、同一のビットマップ画像から生成される更新矩形のうち最後に送信する更新矩形の符号化データにだけヘッダ情報を付加する場合を想定する。なお、上記の「フレームＩＤ」とは、フレームバッファ１３に描画されたビットマップ画像のフレーム番号を指す。また、「送信時刻」とは、更新矩形の符号化データが第１の送信部１４ｆによって送信される時刻を指す。
【００５２】
このように、全ての更新矩形の符号化データのうち１つの更新矩形の符号化データにヘッダ情報を付加して送信する場合には、次のような効果を実現できる。すなわち、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、後述の描画遅延判定部１４ｋによってクライアント側での描画遅延をフレーム単位で監視させることができる。このため、ネットワークのトラフィック及びクライアント端末２０の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
【００５３】
第２のエンコーダ１４ｇは、後述の送信制御部１４ｍから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第２のエンコーダ１４ｇは、高頻度変更領域または変更領域の画像をＭＰＥＧで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてＭＰＥＧを例示したが、Ｍｏｔｉｏｎ−ＪＰＥＧなどの他の方式を適用することもできる。
【００５４】
かかる第２のエンコーダ１４ｇには、高頻度変更領域識別部１４ｄによって高頻度変更領域が識別された場合には、高頻度変更領域の画像が後述の送信制御部１４ｍから入力される。このように、高頻度変更領域が識別されずとも、動画化が強制的に開始される場合には、その段階で変更頻度を判別する処理が切り上げられて、変更頻度判別用のマップ内で変更のあった変更領域の画像が後述の送信制御部１４ｍによって入力される。すなわち、動画化が強制的に開始された段階で変更頻度判別用のマップから変更回数の閾値判定を実行せずに、変更のあったメッシュに関し、上述したメッシュ連結体の生成、メッシュ連結体の矩形への補正や矩形の合成などが実行される。このようにして得られた変更領域の画像が後述の送信制御部１４ｍによって入力される。
【００５５】
第２の送信部１４ｈは、第２のエンコーダ１４ｇによってエンコードされた動画の符号化データをクライアント端末２０へ送信する処理部である。一態様としては、第２の送信部１４ｈは、後述の送信制御部１４ｍによってヘッダ情報の付加が指示された場合には、動画の符号化データのうち少なくともいずれか１つの符号化データにヘッダ情報を付加する。このように、動画の符号化データにヘッダ情報を付加した場合には、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、次のような効果を実現できる。すなわち、動画の符号化データが送信される場合には、クライアント端末２０で画面の更新で描画が実行される処理量が多くなる。このように、クライアント端末２０で描画遅延が発生する可能性が高くなる場面で、描画遅延のボトルネックとなりやすい動画の符号化データの描画にかかる処理負荷を基準にクライアント端末２０での描画遅延を監視できる。
【００５６】
ヘッダ受信部１４ｊは、クライアント端末２０から返信されたヘッダ情報を受信する処理部である。このヘッダ受信部１４ｊは、クライアント端末２０から受信したヘッダ情報を後述の描画遅延判定部１４ｋへ出力する。
【００５７】
描画遅延判定部１４ｋは、ヘッダ受信部１４ｊによって受信されたヘッダ情報に含まれる送信時刻と、当該ヘッダ情報の返信が受信された受信時刻との差から、クライアント端末２０で画面の描画遅延が発生しているか否かを判定する処理部である。
【００５８】
一態様としては、描画遅延判定部１４ｋは、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する。そして、描画遅延判定部１４ｋは、先のようにして算出した送信時刻と受信時刻との時間差が所定の閾値Ｔｈ１、例えば１００ｍｓｅｃ以上であるか否かを判定する。このように、時間差が閾値Ｔｈ１以上であるか否かによってネットワークの伝送遅延、ひいては伝送遅延に起因する描画遅延が発生しているか否かを判定できる。このとき、描画遅延判定部１４ｋは、送信時刻と受信時刻との時間差が閾値Ｔｈ１未満である場合には、送信時刻と受信時刻との時間差が所定のフレーム数、例えば５フレームにわたって所定の閾値Ｔｈ２、例えば５０ｍｓｅｃ以下であるか否かを判定する。このように、フレーム間で継続して時間差が閾値Ｔｈ２以上であるか否かによって、後述の送信制御部１４ｍが動画の符号化データの送信間隔を落とした場合に元の送信間隔に復帰させるか否かを判定できる。
【００５９】
送信制御部１４ｍは、デスクトップ画面の送信を制御する処理部である。かかる送信制御部１４ｍは、静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２が設定される図示しない送信間隔レジスタを用いて、更新矩形及び動画の符号化データの送信制御を実行する。ここで言う「送信間隔Ｆ１」とは、サーバ装置１０からクライアント端末２０へ静止画の符号化データを送信する間隔を指す。また、「送信間隔Ｆ２」とは、サーバ装置１０からクライアント端末２０へ動画の符号化データを送信する間隔を指す。なお、送信間隔レジスタには、例えば、静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２の初期値として３３ｍｓｅｃが設定されているものとする。
【００６０】
一態様としては、送信制御部１４ｍは、描画遅延判定部１４ｋによる描画遅延の判定結果に応じて動画の送信間隔Ｆ２を変更する制御を実行する。これを具体的に説明すると、送信制御部１４ｍは、描画遅延判定部１４ｋによって時間差が閾値Ｔｈ１以上であると判定された場合に、動画化を実行中であるか否かを判定する。このとき、動画化が未だ実行されていない場合には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、送信制御部１４ｍは、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第２のエンコーダ１４ｇへ入力することによって、動画化を強制的に開始する。このように、静止画によるエンコードよりも圧縮率が高い動画によるエンコードを実行させることにより、ネットワークのトラフィックを軽減させる制御を実行する。一方、動画化が実行中である場合には、クライアント端末２０の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、送信制御部１４ｍは、動画の送信間隔Ｆ２を変更前よりも長い送信間隔に変更する。例えば、送信制御部１４ｍは、初期値である３３ｍｓｅｃから１００ｍｓｅｃへ送信間隔Ｆ２を変更する。これによって、クライアント端末２０にデコードさせる処理量をクライアント端末２０の性能に合わせることにより、クライアント端末２０での画面の描画遅延を抑制する。なお、送信間隔Ｆ２は、初期値である３３ｍｓｅｃから１００ｍｓｅｃへ既に引き下げられている場合には、１００ｍｓｅｃが維持される。
【００６１】
このように、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始し、クライアント端末２０の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。それゆえ、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できる。
【００６２】
また、送信制御部１４ｍは、描画遅延判定部１４ｋによって時間差が所定のフレーム数にわたって閾値Ｔｈ２以下であると判定された場合に、動画の送信間隔Ｆ２を変更前の送信間隔に戻す。例えば、送信制御部１４ｍは、１００ｍｓｅｃに引き下げられていた送信間隔Ｆ２を初期値である３３ｍｓｅｃに戻す。これは、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下である場合には、静止画および動画の符号化データの伝送および静止画および動画の符号化データのデコードが安定していると推定できるからである。
【００６３】
他の一態様としては、送信制御部１４ｍは、第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇへ画像を入力する。これを具体的に説明すると、まず、送信制御部１４ｍは、送信間隔レジスタから送信間隔Ｆ１及び送信間隔Ｆ２を読み出す。その上で、送信制御部１４ｍは、動画化が実行中である場合には、前回に動画の符号化データを送信してから経過した送信経過時間ｔ２が送信間隔Ｆ２に到達したか否か、すなわち送信経過時間ｔ２≧送信間隔Ｆ２であるか否かを判定する。このとき、送信制御部１４ｍは、送信経過時間ｔ２≧送信間隔Ｆ２である場合には、高頻度変更領域または変更領域の画像を第２のエンコーダ１４ｇへ入力する。一方、送信制御部１４ｍは、送信経過時間ｔ２＜送信間隔Ｆ２である場合には、高頻度変更領域または変更領域の画像を第２のエンコーダ１４ｇへ入力せず、送信間隔Ｆ２を経過するまで待機させる。
【００６４】
また、送信制御部１４ｍは、前回に更新矩形の画像の符号化データを送信してから経過した送信経過時間ｔ１が送信間隔Ｆ１に到達したか否か、すなわち送信経過時間ｔ１≧送信間隔Ｆ１であるか否かを判定する。このとき、送信制御部１４ｍは、送信経過時間ｔ１≧送信間隔Ｆ１である場合には、高頻度変更領域に含まれない更新矩形の画像を第１のエンコーダ１４ｅへ入力する。一方、送信制御部１４ｍは、送信経過時間ｔ１＜送信間隔Ｆ１である場合には、更新矩形の画像を第１のエンコーダ１４ｅへ入力せず、送信間隔Ｆ１を経過するまで待機させる。
【００６５】
その後、送信制御部１４ｍは、更新矩形の画像、高頻度変更領域または変更領域の画像のいずれかを第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇへ入力したか、すなわち送信データがあるか否かを判定する。このとき、送信制御部１４ｍは、送信データが存在する場合には、第１の送信部１４ｆまたは第２の送信部１４ｈのいずれかにヘッダ情報を付加させる。例えば、送信制御部１４ｍは、第１のエンコーダ１４ｅだけに画像が入力された場合、あるいは第１のエンコーダ１４ｅ及び第２のエンコーダ１４ｇの両方へ画像が入力された場合には、第１の送信部１４ｆにヘッダ情報を付加するように指示する。一方、送信制御部１４ｍは、第２のエンコーダ１４ｇにしか画像が入力されなかった場合には、第２の送信部１４ｈにヘッダ情報を付加するように指示する。また、送信制御部１４ｍは、第１のエンコーダ１４ｅまたは第２のエンコーダ１４ｇのいずれにも画像が入力されなかった場合には、送信データがないので、ヘッダ情報を付加する指示は実行しない。
【００６６】
なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。
【００６７】
［クライアント端末の構成］
次に、本実施例に係るクライアント端末の機能的構成について説明する。図１に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側のリモート画面制御部２３とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
【００６８】
入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス機能を実現する。
【００６９】
表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。
【００７０】
リモート画面制御部２３は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部２３は、図１に示すように、操作情報通知部２３ａと、第１の受信部２３ｂと、第１のデコーダ２３ｃと、第１の表示制御部２３ｄとを有する。さらに、リモート画面制御部２３は、第２の受信部２３ｅと、第２のデコーダ２３ｆと、第２の表示制御部２３ｇと、ヘッダ返信部２３ｈとを有する。
【００７１】
操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一態様としては、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
【００７２】
第１の受信部２３ｂは、サーバ装置１０の第１の送信部１４ｆにより送信された更新矩形の符号化データを受信する処理部である。一態様としては、第１の受信部２３ｂは、サーバ装置１０から受信した更新矩形の符号化データからヘッダ情報を取り出し、ヘッダ情報については第１の表示制御部２３ｄへ出力する一方で、更新矩形の符号化データについては第１のデコーダ２３ｃへ出力する。これによって、ヘッダ情報だけデコードをスキップさせる。なお、第１の受信部２３ｂは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。
【００７３】
第１のデコーダ２３ｃは、第１の受信部２３ｂによって受信された更新矩形の符号化データをデコードする処理部である。この第１のデコーダ２３ｃには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
【００７４】
第１の表示制御部２３ｄは、第１のデコーダ２３ｃによってデコードされた更新矩形の画像を表示部２２に表示させる処理部である。一態様としては、第１の表示制御部２３ｄは、第１の受信部２３ｂによって受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。また、第１の表示制御部２３ｄは、第１の受信部２３ｂによって高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｄは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。このようにして画面の描画が終了すると、第１の表示制御部２３ｄは、第１の受信部２３ｂから入力されたヘッダ情報を後述のヘッダ返信部２３へ出力する。
【００７５】
第２の受信部２３ｅは、サーバ装置１０の第２の送信部１４ｈにより送信された動画の符号化データを受信する処理部である。この第２の受信部２３ｅは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。
【００７６】
第２のデコーダ２３ｆは、第２の受信部２３ｅによって受信された動画の符号化データをデコードする処理部である。この第２のデコーダ２３ｆには、サーバ装置１０に搭載されたエンコード方式に適合するデコード方式のデコーダが搭載される。
【００７７】
第２の表示制御部２３ｇは、第２の受信部２３ｅによって受信された高頻度変更領域の属性情報に基づき、第２のデコーダ２３ｆによってデコードされた高頻度変更領域または変更領域の画像を表示部２２に表示させる処理部である。一態様としては、第２の表示制御部２３ｇは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域の動画を再生させる。なお、動画の符号化データにヘッダ情報が付加されていた場合には、静止画の場合と同様に、デコードおよび画面の描画が終了した段階で後述のヘッダ返信部２３ｈへ出力する。
【００７８】
ヘッダ返信部２３ｈは、ヘッダ情報をサーバ装置１０へ返信する処理部である。一態様としては、ヘッダ返信部２３ｈは、サーバ装置１０から第１の受信部２３ｂ及び第１の表示制御部２３ｄを経由して入力されたヘッダ情報をサーバ装置１０へ送信する。このようにヘッダ情報を返信することによって、サーバ装置１０側で送信時刻と返信時刻の時間差から、ネットワークの伝送遅延、ひいては画面の描画遅延を推定することが可能になる。
【００７９】
なお、クライアント側のリモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣやＦＰＧＡが挙げられる。また、電子回路としては、ＣＰＵやＭＰＵなどが挙げられる。
【００８０】
［処理の流れ］
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。なお、ここでは、サーバ装置１０によって実行される（１）画像送信処理を説明した後に、（２）送信間隔変更処理を説明する。
【００８１】
（１）画像送信処理
図７及び図８は、実施例１に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０によって実行される処理であり、クライアント端末２０が起動されている限り繰り返し実行する処理である。
【００８２】
図７に示すように、サーバ装置１０は、送信間隔レジスタに記憶された静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２に初期値「３３ｍｓｅｃ」を書き込む初期化を実行する（ステップＳ１０１）。
【００８３】
その後、サーバ装置１０は、フレームバッファ１３にビットマップ画像が描画されて前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成されると（ステップＳ１０２肯定）、次のような処理を実行する。すなわち、サーバ装置１０は、送信間隔レジスタから静止画の送信間隔Ｆ１及び動画の送信間隔Ｆ２を読み出す（ステップＳ１０３）。
【００８４】
そして、サーバ装置１０は、先に生成された更新矩形の画像から更新矩形送信用のパケットを生成し（ステップＳ１０４）、生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０５）。
【００８５】
このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０６否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、図８に示すステップＳ１１５へ移行する。
【００８６】
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０６肯定）には、サーバ装置１０は、次のような処理を行う。すなわち、サーバ装置１０は、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０７）。そして、サーバ装置１０は、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する（ステップＳ１０８）。
【００８７】
その後、サーバ装置１０は、変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０９）。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合（ステップＳ１０９否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１４へ移行する。
【００８８】
一方、変更頻度がしきい値を超えるメッシュが存在する場合（ステップＳ１０９肯定）には、サーバ装置１０は、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１１０）。
【００８９】
そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１１１肯定）には、サーバ装置１０は、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１２）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１１１否定）には、矩形の合成を行わずにステップＳ１１３へ移行する。
【００９０】
続いて、サーバ装置１０は、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１３）。そして、サーバ装置１０は、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする（ステップＳ１１４）。
【００９１】
その後、図８に示すように、動画化が実行中である場合（ステップＳ１１５肯定）には、サーバ装置１０は、動画の送信経過時間ｔ２が送信間隔Ｆ２に到達したか否か、すなわち送信経過時間ｔ２≧送信間隔Ｆ２であるか否かを判定する（ステップＳ１１６）。
【００９２】
このとき、送信経過時間ｔ２≧送信間隔Ｆ２である場合（ステップＳ１１６肯定）には、サーバ装置１０は、高頻度変更領域または変更領域の画像を動画の符号化データへエンコードする（ステップＳ１１７）。
【００９３】
一方、送信経過時間ｔ２＜送信間隔Ｆ２である場合（ステップＳ１１６否定）には、サーバ装置１０は、動画の符号化データの送信間隔を空ける必要があるので、ステップＳ１１７をスキップし、ステップＳ１１８へ移行する。
【００９４】
続いて、サーバ装置１０は、静止画の送信経過時間ｔ１が送信間隔Ｆ１に到達したか否か、すなわち送信経過時間ｔ１≧送信間隔Ｆ１であるか否かを判定する（ステップＳ１１８）。
【００９５】
このとき、送信経過時間ｔ１≧送信間隔Ｆ１である場合（ステップＳ１１８肯定）には、サーバ装置１０は、更新矩形の画像を静止画の符号化データへエンコードする（ステップＳ１１９）。
【００９６】
一方、送信経過時間ｔ１＜送信間隔Ｆ１である場合（ステップＳ１１８否定）には、サーバ装置１０は、静止画の符号化データの送信間隔を空ける必要があるので、ステップＳ１１９をスキップし、ステップＳ１２０へ移行する。
【００９７】
そして、ステップＳ１１７またはステップＳ１１９の処理でエンコードされた静止画または動画の符号化データ、すなわち送信データが存在する場合（ステップＳ１２０肯定）には、サーバ装置１０は、次のような処理を実行する。すなわち、サーバ装置１０は、静止画または動画のいずれかの符号化データにフレームＩＤ及び送信時刻を含むヘッダ情報を付加する（ステップＳ１２１）。その上で、サーバ装置１０は、静止画の符号化データ及び／又は動画の符号化データの送信データをクライアント端末２０へ送信する（ステップＳ１２２）。
【００９８】
その後、サーバ装置１０は、ステップＳ１０２の処理に戻り、クライアント端末２０が起動している限り、ステップＳ１０２〜ステップＳ１２２までの処理を繰り返し実行する。なお、クライアント端末２０の電源がシャットダウンされた場合には、サーバ装置１０は、処理を終了する。
【００９９】
（２）送信間隔変更処理
次に、本実施例に係る送信間隔変更処理について説明する。図９は、実施例１に係る送信間隔変更処理の手順を示すフローチャートである。この送信間隔変更処理は、サーバ装置１０によって実行される処理であり、クライアント端末２０が起動中である限り、繰り返し実行される。
【０１００】
図９に示すように、ヘッダ情報の返信を受信すると（ステップＳ２０１肯定）、サーバ装置１０は、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する（ステップＳ２０２）。
【０１０１】
そして、サーバ装置１０は、ステップＳ２０１のようにして算出した送信時刻と受信時刻との時間差が閾値Ｔｈ１以上であるか否かを判定する（ステップＳ２０３）。このとき、時間差が閾値Ｔｈ１以上である場合（ステップＳ２０３肯定）には、サーバ装置１０は、動画化を実行中であるか否かをさらに判定する（ステップＳ２０４）。
【０１０２】
ここで、動画化が未だ実行されていない場合（ステップＳ２０４否定）には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、サーバ装置１０は、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第２のエンコーダ１４ｇへ入力することによって、動画化を強制的に開始する（ステップＳ２０５）。
【０１０３】
一方、動画化が実行中である場合（ステップＳ２０４肯定）には、クライアント端末２０の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、サーバ装置１０は、動画の送信間隔Ｆ２を変更前よりも長い送信間隔に変更する（ステップＳ２０６）。
【０１０４】
また、送信時刻と受信時刻との時間差が閾値Ｔｈ１未満（ステップＳ２０３否定）である場合には、サーバ装置１０は、送信時刻と受信時刻との時間差が所定のフレーム数にわたって閾値Ｔｈ２以下であるか否かをさらに判定する（ステップＳ２０７）。
【０１０５】
このとき、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下である場合（ステップＳ２０７肯定）には、サーバ装置１０は、動画の送信間隔Ｆ２を変更前の送信間隔に戻す（ステップＳ２０８）。なお、時間差が所定のフレーム数にわたって閾値Ｔｈ２以下でない場合（ステップＳ２０７否定）には、送信間隔を戻さずに、上記のステップＳ２０１へ移行する。
【０１０６】
上記のステップＳ２０５、ステップＳ２０６またはステップＳ２０８の処理が終了すると、サーバ装置１０は、ステップＳ２０１の処理へ戻り、クライアント端末２０が起動中である限り、ステップＳ２０１〜ステップＳ２０８までの処理を繰り返し実行する。なお、クライアント端末２０の電源がシャットダウンされた場合には、サーバ装置１０は、処理を終了する。
【０１０７】
［実施例１の効果］
上述してきたように、本実施例に係るサーバ装置１０では、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始する。また、本実施例に係るサーバ装置１０では、クライアント端末２０の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。したがって、本実施例に係るサーバ装置１０によれば、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制することが可能になる。
【０１０８】
また、本実施例に係るサーバ装置１０は、変更領域の画像が複数存在する場合に、少なくとも１つの変更領域の画像にヘッダ情報を付加する。このため、本実施例に係るサーバ装置１０では、クライアント端末２０で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、クライアント側での描画遅延をフレーム単位で監視することができる。よって、本実施例に係るサーバ装置１０によれば、ネットワークのトラフィック及びクライアント端末２０の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
【０１０９】
さらに、本実施例に係るサーバ装置１０は、クライアント端末２０で描画遅延が発生していない場合に、動画の符号化データを送信させる送信間隔Ｆ２を変更前の送信間隔に戻す。よって、本実施例に係るサーバ装置１０によれば、クライアント端末２０がネットワークの伝送遅延や描画遅延から復帰した場合には、動画の符号化データの送信をセーブせずに元の操作レスポンスを提供できる。
【実施例２】
【０１１０】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１１１】
［マップクリアの延長］
例えば、上記の実施例１では、高頻度変更領域識別部１４ｄが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。
【０１１２】
一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。
【０１１３】
図１０Ａ及び図１０Ｂは、マップクリアの延長要領を説明するための図である。図１０Ａの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ８０Ａと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。また、図１０Ｂの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ８０Ｂと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。
【０１１４】
図１０Ａに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果８１Ａが得られた場合には、以降に変更回数が閾値を超えるメッシュ連結体が取得されなくとも識別結果８１Ａを所定の期間引き継ぐ。すなわち、図１０Ｂに示すように、マップ８０Ａで変更回数が閾値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果８１Ａを識別してから所定の期間内であれば高頻度変更領域の識別結果８１Ａを引き継ぐ。なお、上記の「閾値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
【０１１５】
これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【０１１６】
［高頻度変更領域の縮小の抑制］
他の一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、当該縮小した度合いが所定の閾値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。
【０１１７】
図１１Ａ及び図１１Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図１１Ａの例では、時点Ｔ１の変更頻度判別用のマップ９０Ａと高頻度変更領域の識別結果９１Ａとを図示している。また、図１１Ｂの例では、時点Ｔ２の変更頻度判別用のマップ９０Ｂと高頻度変更領域の識別結果９１Ａとを図示している。なお、上記の時点Ｔ１および時点Ｔ２はＴ１＜Ｔ２であるものとする。
【０１１８】
図１１Ａに示すように、マップ９０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果９１Ａが得られた場合には、時点Ｔ１以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図１１Ｂに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定の閾値、例えば半分以下であるならば、高頻度変更領域の識別結果９１Ａを引き継ぐ。
【０１１９】
これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。
【０１２０】
［送信間隔変更の多段化］
また、上記の実施例１では、動画の送信間隔Ｆ２を初期値である３３ｍｓｅｃと１００ｍｓｅｃとの２つの値の間で遷移させる場合を例示したが、３つ以上の値の間を遷移させることとしてもかまわない。このように、３つ以上の値の間を遷移させる場合には、送信時刻と受信時刻の時間差が大きくなるほど長い送信間隔の値を割り当てるようにすればよい。
【０１２１】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【０１２２】
例えば、サーバ装置１０の第１の送信部１４ｆ及び第２の送信部１４ｈが実行する画像の送信処理を１つの送信部に統合することとしてもよい。また、クライアント端末２０の第１の受信部２３ｂ及び第２の受信部２３ｅが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末の第１の表示制御部２３ｄ及び第２の表示制御部２３ｇが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。
【０１２３】
［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１２を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。
【０１２４】
図１２は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図１２に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１２５】
ＨＤＤ１７０には、図１２に示すように、上記の実施例１で示したサーバ側のリモート画面制御部１４と同様の機能を発揮する画像送信プログラム１７０ａが予め記憶される。この画像送信プログラム１７０ａについては、図１に示した各々のリモート画面制御部１４に含まれる各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。
【０１２６】
そして、ＣＰＵ１５０が、画像送信プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１２に示すように、画像送信プログラム１７０ａは、画像送信プロセス１８０ａとして機能する。この画像送信プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス１８０ａは、図１に示したリモート画面制御部１４にて実行される処理、例えば図７〜図９に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１２７】
なお、上記の画像送信プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１２８】
１ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ 第１のエンコーダ
１４ｆ 第１の送信部
１４ｇ 第２のエンコーダ
１４ｈ 第２の送信部
１４ｊ ヘッダ受信部
１４ｋ 描画遅延判定部
１４ｍ 送信制御部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の受信部
２３ｃ 第１のデコーダ
２３ｄ 第１の表示制御部
２３ｅ 第２の受信部
２３ｆ 第２のデコーダ
２３ｇ 第２の表示制御部
２３ｈ ヘッダ返信部
【特許請求の範囲】
【請求項１】
画像を記憶する画像メモリと、
ソフトウェアによる処理結果を示す表示用の画像を前記画像メモリに描画する描画部と、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別する識別部と、
前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画化する動画化部と、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信する送信部と、
前記端末装置から前記時刻情報を受信する受信部と、
前記受信部によって受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定する判定部と、
前記判定部によって前記画像の描画遅延が発生していると判定された場合に、前記動画化部による動画化が実行中でない場合には前記変更領域の動画化を前記動画化部に開始させ、前記動画化部による動画化が実行中である場合には前記送信部における画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する送信制御部と
を有することを特徴とする情報処理装置。
【請求項２】
前記送信部は、前記変更領域の画像が複数存在する場合に、少なくとも１つの変更領域の画像に前記時刻情報を付加することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記送信制御部は、前記判定部によって前記画像の描画遅延が発生していないと判定された場合に、予め設定された特定の送信間隔で前記送信部に画像を送信させることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
コンピュータが、
画像を記憶する画像メモリにソフトウェアによる処理結果を示す画像を描画し、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別し、
前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画化し、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信し、
前記端末装置から前記時刻情報を受信し、
受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定し、
前記画像の描画遅延が発生している場合に、前記動画化が実行中でない場合には前記変更領域の動画化を開始させ、前記動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する
各処理を実行することを特徴とする画像送信方法。
【請求項５】
コンピュータに、
画像を記憶する画像メモリにソフトウェアによる処理結果を示す画像を描画し、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別し、
前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画化し、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信し、
前記端末装置から前記時刻情報を受信し、
受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定し、
前記画像の描画遅延が発生している場合に、前記動画化が実行中でない場合には前記変更領域の動画化を開始させ、前記動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する
各処理を実行させることを特徴とする画像送信プログラム。
【請求項１】
画像を記憶する画像メモリと、
ソフトウェアによる処理結果を示す表示用の画像を前記画像メモリに描画する描画部と、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別する識別部と、
前記画像メモリに描画された画像のうち前記識別部によって識別された高頻度の変更領域の画像を動画化する動画化部と、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信する送信部と、
前記端末装置から前記時刻情報を受信する受信部と、
前記受信部によって受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定する判定部と、
前記判定部によって前記画像の描画遅延が発生していると判定された場合に、前記動画化部による動画化が実行中でない場合には前記変更領域の動画化を前記動画化部に開始させ、前記動画化部による動画化が実行中である場合には前記送信部における画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する送信制御部と
を有することを特徴とする情報処理装置。
【請求項２】
前記送信部は、前記変更領域の画像が複数存在する場合に、少なくとも１つの変更領域の画像に前記時刻情報を付加することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記送信制御部は、前記判定部によって前記画像の描画遅延が発生していないと判定された場合に、予め設定された特定の送信間隔で前記送信部に画像を送信させることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
コンピュータが、
画像を記憶する画像メモリにソフトウェアによる処理結果を示す画像を描画し、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別し、
前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画化し、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信し、
前記端末装置から前記時刻情報を受信し、
受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定し、
前記画像の描画遅延が発生している場合に、前記動画化が実行中でない場合には前記変更領域の動画化を開始させ、前記動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する
各処理を実行することを特徴とする画像送信方法。
【請求項５】
コンピュータに、
画像を記憶する画像メモリにソフトウェアによる処理結果を示す画像を描画し、
前記画像メモリに描画される画像のフレーム間で変更の頻度が所定の頻度以上である高頻度の変更領域を識別し、
前記画像メモリに描画された画像のうち前記高頻度の変更領域の画像を動画化し、
前記画像メモリに描画された画像のうち変更のある変更領域の画像及び／又は前記動画化部によって動画化された高頻度の変更領域の画像に時刻情報を付加した上でネットワークを介して接続された端末装置へ送信し、
前記端末装置から前記時刻情報を受信し、
受信された時刻情報と、当該時刻情報が受信された時刻との差から、前記端末装置で画像の描画遅延が発生しているか否かを判定し、
前記画像の描画遅延が発生している場合に、前記動画化が実行中でない場合には前記変更領域の動画化を開始させ、前記動画化が実行中である場合には画像の送信間隔を変更前の送信間隔よりも長い送信間隔に変更する
各処理を実行させることを特徴とする画像送信プログラム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１Ａ】
【図１１Ｂ】
【図１２】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１１Ａ】
【図１１Ｂ】
【図１２】
【公開番号】特開２０１３−６２６２１（Ｐ２０１３−６２６２１Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１１−１９８７９９（Ｐ２０１１−１９８７９９）
【出願日】平成２３年９月１２日（２０１１．９．１２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２３年９月１２日（２０１１．９．１２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]