以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
[システム構成]
まず、本実施例に係るシンクライアントシステムの構成について説明する。図1は、実施例1に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。
図1に示すシンクライアントシステム1は、クライアント端末20が表示する画面をリモートでサーバ装置10に制御させるものである。つまり、シンクライアントシステム1は、実際にはサーバ装置10が実行した処理結果や保持するデータをクライアント端末20に表示させつつも、あたかもクライアント端末20が主体となって処理を実行したり、データを保持しているかのように振る舞う。
図1に示すように、シンクライアントシステム1は、サーバ装置10と、クライアント端末20とを有する。なお、図1の例では、1つのサーバ装置10に対し、1つのクライアント端末20を接続する場合を図示したが、任意の数のクライアント端末を接続できる。
これらサーバ装置10及びクライアント端末20は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、LAN(Local Area Network)やVPN(Virtual Private Network)などの任意の種類の通信網を採用できる。なお、サーバ装置10及びクライアント端末20間の通信プロトコルには、一例として、VNCにおけるRFB(Remote Frame Buffer)プロトコルを採用する場合を想定する。
サーバ装置10は、クライアント端末20に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置10には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことを「サーバ側リモート画面制御用アプリ」と記載する場合がある。
このサーバ側リモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側リモート画面制御用アプリは、クライアント端末20における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末20へ送信する。このとき、サーバ側リモート画面制御用アプリは、今回の画面生成の前にクライアント端末20で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。
このほか、サーバ側リモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末20へ送信する機能も有する。一態様としては、サーバ側リモート画面制御用アプリは、アプリケーションにより実行された処理結果から生成した画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側リモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末20へ送信する。これとともに、サーバ側リモート画面制御用アプリは、高頻度変更領域のビットマップ画像をMPEG−2やMPEG−4などのMPEG方式のデータにエンコードした上でクライアント端末20へ送信する。なお、ここでは、MPEG(Moving Picture Experts Group)方式のデータへ圧縮する場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばMotion−JPEG(Joint Photographic Experts Group)などを採用できる。
クライアント端末20は、サーバ装置10によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末20の一例としては、パーソナルコンピュータ(personal computer)など固定端末の他、携帯電話機、PHS(Personal Handyphone System)やPDA(Personal Digital Assistant)などの移動体端末を採用することができる。このクライアント端末20には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことを「クライアント側リモート画面制御用アプリ」と記載する場合がある。
このクライアント側リモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置10へ通知する機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
さらに、クライアント側リモート画面制御用アプリは、サーバ装置10から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置10から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一態様としては、クライアント側リモート画面制御用アプリは、サーバ装置10から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。その上で、クライアント側リモート画面制御用アプリは、動画向けの圧縮方式のデータを受信した場合にそのデータをデコードした上でブランク領域に表示する。
[サーバ装置の構成]
次に、本実施例に係るサーバ装置の機能的構成について説明する。図1に示すように、サーバ装置10は、OS実行制御部11aと、アプリ実行制御部11bと、グラフィックドライバ12と、フレームバッファ13と、リモート画面制御部14とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。
OS実行制御部11aは、OS(Operating System)の実行を制御する処理部である。一態様としては、OS実行制御部11aは、後述の操作情報取得部14aにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、OS実行制御部11aは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部11bへ指示する。また、OS実行制御部11aは、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部11bへ指示する。なお、以下では、アプリケーションのことを「アプリ」と記載する場合がある。
アプリ実行制御部11bは、OS実行制御部11aによる指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部11bは、OS実行制御部11aによってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部11bは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ13に描画する要求を後述のグラフィックドライバ12へ行う。このようにグラフィックドライバ12へ描画要求を行う場合には、アプリ実行制御部11bは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ12へ通知する。
なお、アプリ実行制御部11bが実行するアプリは、プリインストールされたものであってもよく、サーバ装置10の出荷後にインストールされたものであってもかまわない。また、JAVA(登録商標)などのネットワーク環境で動作するアプリであってもよい。
グラフィックドライバ12は、フレームバッファ13に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ12は、アプリ実行制御部11bからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ13上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリにより描画要求を受け付ける場合を説明したが、OS実行制御部11aからの描画要求を受け付けることもできる。例えば、グラフィックドライバ12は、OS実行制御部11aからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをOSにより指定されたフレームバッファ13上の描画位置へビットマップ形式で描画する。
フレームバッファ13は、グラフィックドライバ12により描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ13の一態様としては、VRAM(Video Random Access Memory)を始めとするRAM(Random Access Memory)、ROM(Read Only Memory)やフラッシュメモリ(flash memory)などの半導体メモリ素子が挙げられる。なお、フレームバッファ13は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。
リモート画面制御部14は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末20へ提供する処理部である。このリモート画面制御部14は、図1に示すように、操作情報取得部14aと、画面生成部14bと、変更頻度判別部14cと、高頻度変更領域識別部14dとを有する。さらに、リモート画面制御部14は、第1のエンコーダ14eと、第1の送信部14fと、第2のエンコーダ14gと、第2の送信部14hと、ヘッダ受信部14jと、描画遅延判定部14kと、送信制御部14mとを有する。
操作情報取得部14aは、クライアント端末20から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。また、操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。
画面生成部14bは、クライアント端末20の表示部22に表示させる画面の画像を生成する処理部である。一態様としては、画面生成部14bは、デスクトップ画面の更新間隔、例えば33msecが経過する度に、次のような処理を起動する。すなわち、画面生成部14bは、前回のフレーム生成時にクライアント端末20で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ13へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部14bは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。
変更頻度判別部14cは、フレームバッファ13に描画された画像を分割した領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部14cは、画面生成部14bにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部14cは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、33msec(ミリ秒)にわたって更新矩形の画像を蓄積する場合を想定する。
このとき、変更頻度判別部14cは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末20に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。
図2は、デスクトップ画面の分割要領を説明するための図である。図2に示す符号30は、変更頻度判別用のマップを示す。図2に示す符号31は、マップ30に含まれるメッシュを指す。図2に示す符号32は、メッシュ31を形成する画素のブロックに含まれる1画素を指す。図2に示す例では、変更頻度判別部14cがマップ30を占める画素のうち8画素×8画素のブロックを1つのメッシュとして分割する場合を想定している。この場合には、1つのメッシュに64個の画素が含まれることになる。
ここで、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部14cは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部14cは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を1つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と1つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。
図3A〜図3Cは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図3A〜図3Cに示す符号40A、符号40B及び符号40Nは変更頻度判別用のマップを示す。図3A及び図3Bに示す符号41A及び符号41Bは更新矩形を示す。ここで、マップ40Aのメッシュ内に図示した数字は、更新矩形41Aが展開された時点におけるメッシュの変更回数を示す。また、マップ40Bのメッシュ内に図示した数字は、更新矩形41Bが展開された時点におけるメッシュの変更回数を示す。さらに、マップ40Nのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図3A〜図3Cにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。
図3Aに示すように、更新矩形41Aがマップ40Aに展開された場合には、網掛け部分のメッシュが更新矩形41Aと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は0から1に加算される。さらに、図3Bに示すように、更新矩形41Bがマップ40Bに展開された場合には、網掛け部分のメッシュが更新矩形41Bと重なり合う。このため、変更頻度判別部14cは、網掛け部分のメッシュの更新回数を1つずつ加算する。この場合には、各メッシュの変更回数は1であるため、網掛け部分の変更回数は1から2に加算される。このようにして全ての更新矩形がマップに展開された段階では、図3Cに示すマップ40Nの結果が得られる。
そして、変更頻度判別部14cは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図3Cの例で言えば、閾値を「4」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述の第2のエンコーダ14gによりエンコードできる。なお、上記の「閾値」は、リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。
高頻度変更領域識別部14dは、クライアント端末20に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。
具体的に説明すると、高頻度変更領域識別部14dは、変更頻度判別部14cにより変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一態様としては、高頻度変更領域識別部14dは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。
図4は、メッシュ連結体の補正要領を説明するための図である。図4に示す符号51は補正前のメッシュ連結体を示す。図4に示す符号52は補間領域を示す。また、図4に示す符号53は補正後の矩形を示す。図4に示すように、高頻度変更領域識別部14dは、メッシュ連結体51に補間領域52を足し合わせることにより、メッシュ連結体51を矩形53に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形53が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と呼ぶこととする。
高頻度変更領域識別部14dは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部14dは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。
図5は、高頻度変更領域の候補の合成要領を説明するための説明図である。図5に示す符号61A及び符号61Bは、高頻度変更領域の候補を指す。図5に示す符号62は補間領域を指す。図5に示す符号63は、高頻度変更領域の候補61A及び高頻度変更領域の候補61Bの合成体を指す。図5に示すように、高頻度変更領域識別部14dは、互いの距離が距離d以内である高頻度変更領域の候補61A及び高頻度変更領域の候補61Bに補間領域62を足し合わせることにより、高頻度変更領域の候補61A及び高頻度変更領域の候補61Bを含む合成体63へ合成する。そして、高頻度変更領域識別部14dは、このようにして得た合成体を高頻度変更領域と識別する。
このように高頻度変更領域を識別すると、高頻度変更領域識別部14dは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信する。これによって、クライアント端末20で表示されるデスクトップ画面のビットマップ画像のうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部14dは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする。なお、高頻度変更領域識別部14dは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。
図6A〜図6Cは、高頻度変更領域の属性情報の通知要領を説明するための図である。図6Aに示す符号70Aは、フレームバッファ13に描画されたデスクトップ画面の一例を示す。図6B〜図6Cに示す符号70B及び符号70Cは、変更頻度判別用のマップを示す。図6Aに示す符号71は、ブラウザ画面を指す。図6Aに示す符号72は、動画再生画面を指す。図6Bに示す符号73は、マウスの移動軌跡を示す。図6Bに示す符号74は、アプリによる動画再生領域を示す。
図6Aに示すように、デスクトップ画面70Aには、ブラウザ画面71及び動画再生画面72が含まれる。このデスクトップ画面70Aから経時的な変化を追った場合には、図6Bに示すように、静止画であるブラウザ画面71の更新矩形は検出されず、マウスの移動軌跡73および動画再生領域74に関する更新矩形が検出される。このうち、動画再生領域74で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部14dにより識別されたものとする。この場合には、高頻度変更領域識別部14dは、図6Cに示す網掛け部分の高頻度変更領域の左上の頂点の座標(x,y)と、高頻度変更領域の幅wおよび高さhとを高頻度変更領域の属性情報としてクライアント端末20へ送信する。
なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸XYの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。
このように、デスクトップ画面の一部に高頻度変更領域が検出された場合には、デスクトップ画面のうち当該高頻度変更領域の動画化が開始される。この場合には、フレームバッファ13に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像が後述の送信制御部14mによって後述の第2のエンコーダ14gへ入力される。一方、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ13に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述の送信制御部14mによって後述の第1のエンコーダ14eへ入力される。
第1のエンコーダ14eは、後述の送信制御部14mから入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。一態様としては、第1のエンコーダ14eは、各更新矩形の画像をJPEGで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、静止画の圧縮方式としてJPEGを例示したが、GIF(Graphic Interchange Format)やPNG(Portable Network Graphics)などの他の方式を適用することもできる。
第1の送信部14fは、第1のエンコーダ14eによってエンコードされた更新矩形の符号化データをクライアント端末20へ送信する処理部である。一態様としては、第1の送信部14fは、後述の送信制御部14mによってヘッダ情報の付加が指示された場合には、更新矩形の符号化データをクライアント端末20へ送信するにあたってフレームID及び送信時刻のタイムスタンプ等のヘッダ情報を符号化データに付加した上でクライアント端末20へ送信する。このとき、第1の送信部14fは、第1のエンコーダ14eによってエンコードされた全ての更新矩形の符号化データにヘッダ情報を付加することもできるが、更新矩形の符号化データのうち少なくとも1つの符号化データにヘッダ情報を付加すればよい。以下では、一例として、第1の送信部14fは、同一のビットマップ画像から生成される更新矩形のうち最後に送信する更新矩形の符号化データにだけヘッダ情報を付加する場合を想定する。なお、上記の「フレームID」とは、フレームバッファ13に描画されたビットマップ画像のフレーム番号を指す。また、「送信時刻」とは、更新矩形の符号化データが第1の送信部14fによって送信される時刻を指す。
このように、全ての更新矩形の符号化データのうち1つの更新矩形の符号化データにヘッダ情報を付加して送信する場合には、次のような効果を実現できる。すなわち、クライアント端末20で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、後述の描画遅延判定部14kによってクライアント側での描画遅延をフレーム単位で監視させることができる。このため、ネットワークのトラフィック及びクライアント端末20の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
第2のエンコーダ14gは、後述の送信制御部14mから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第2のエンコーダ14gは、高頻度変更領域または変更領域の画像をMPEGで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてMPEGを例示したが、Motion−JPEGなどの他の方式を適用することもできる。
かかる第2のエンコーダ14gには、高頻度変更領域識別部14dによって高頻度変更領域が識別された場合には、高頻度変更領域の画像が後述の送信制御部14mから入力される。このように、高頻度変更領域が識別されずとも、動画化が強制的に開始される場合には、その段階で変更頻度を判別する処理が切り上げられて、変更頻度判別用のマップ内で変更のあった変更領域の画像が後述の送信制御部14mによって入力される。すなわち、動画化が強制的に開始された段階で変更頻度判別用のマップから変更回数の閾値判定を実行せずに、変更のあったメッシュに関し、上述したメッシュ連結体の生成、メッシュ連結体の矩形への補正や矩形の合成などが実行される。このようにして得られた変更領域の画像が後述の送信制御部14mによって入力される。
第2の送信部14hは、第2のエンコーダ14gによってエンコードされた動画の符号化データをクライアント端末20へ送信する処理部である。一態様としては、第2の送信部14hは、後述の送信制御部14mによってヘッダ情報の付加が指示された場合には、動画の符号化データのうち少なくともいずれか1つの符号化データにヘッダ情報を付加する。このように、動画の符号化データにヘッダ情報を付加した場合には、クライアント端末20で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、次のような効果を実現できる。すなわち、動画の符号化データが送信される場合には、クライアント端末20で画面の更新で描画が実行される処理量が多くなる。このように、クライアント端末20で描画遅延が発生する可能性が高くなる場面で、描画遅延のボトルネックとなりやすい動画の符号化データの描画にかかる処理負荷を基準にクライアント端末20での描画遅延を監視できる。
ヘッダ受信部14jは、クライアント端末20から返信されたヘッダ情報を受信する処理部である。このヘッダ受信部14jは、クライアント端末20から受信したヘッダ情報を後述の描画遅延判定部14kへ出力する。
描画遅延判定部14kは、ヘッダ受信部14jによって受信されたヘッダ情報に含まれる送信時刻と、当該ヘッダ情報の返信が受信された受信時刻との差から、クライアント端末20で画面の描画遅延が発生しているか否かを判定する処理部である。
一態様としては、描画遅延判定部14kは、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する。そして、描画遅延判定部14kは、先のようにして算出した送信時刻と受信時刻との時間差が所定の閾値Th1、例えば100msec以上であるか否かを判定する。このように、時間差が閾値Th1以上であるか否かによってネットワークの伝送遅延、ひいては伝送遅延に起因する描画遅延が発生しているか否かを判定できる。このとき、描画遅延判定部14kは、送信時刻と受信時刻との時間差が閾値Th1未満である場合には、送信時刻と受信時刻との時間差が所定のフレーム数、例えば5フレームにわたって所定の閾値Th2、例えば50msec以下であるか否かを判定する。このように、フレーム間で継続して時間差が閾値Th2以上であるか否かによって、後述の送信制御部14mが動画の符号化データの送信間隔を落とした場合に元の送信間隔に復帰させるか否かを判定できる。
送信制御部14mは、デスクトップ画面の送信を制御する処理部である。かかる送信制御部14mは、静止画の送信間隔F1及び動画の送信間隔F2が設定される図示しない送信間隔レジスタを用いて、更新矩形及び動画の符号化データの送信制御を実行する。ここで言う「送信間隔F1」とは、サーバ装置10からクライアント端末20へ静止画の符号化データを送信する間隔を指す。また、「送信間隔F2」とは、サーバ装置10からクライアント端末20へ動画の符号化データを送信する間隔を指す。なお、送信間隔レジスタには、例えば、静止画の送信間隔F1及び動画の送信間隔F2の初期値として33msecが設定されているものとする。
一態様としては、送信制御部14mは、描画遅延判定部14kによる描画遅延の判定結果に応じて動画の送信間隔F2を変更する制御を実行する。これを具体的に説明すると、送信制御部14mは、描画遅延判定部14kによって時間差が閾値Th1以上であると判定された場合に、動画化を実行中であるか否かを判定する。このとき、動画化が未だ実行されていない場合には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、送信制御部14mは、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第2のエンコーダ14gへ入力することによって、動画化を強制的に開始する。このように、静止画によるエンコードよりも圧縮率が高い動画によるエンコードを実行させることにより、ネットワークのトラフィックを軽減させる制御を実行する。一方、動画化が実行中である場合には、クライアント端末20の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、送信制御部14mは、動画の送信間隔F2を変更前よりも長い送信間隔に変更する。例えば、送信制御部14mは、初期値である33msecから100msecへ送信間隔F2を変更する。これによって、クライアント端末20にデコードさせる処理量をクライアント端末20の性能に合わせることにより、クライアント端末20での画面の描画遅延を抑制する。なお、送信間隔F2は、初期値である33msecから100msecへ既に引き下げられている場合には、100msecが維持される。
このように、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始し、クライアント端末20の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。それゆえ、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制できる。
また、送信制御部14mは、描画遅延判定部14kによって時間差が所定のフレーム数にわたって閾値Th2以下であると判定された場合に、動画の送信間隔F2を変更前の送信間隔に戻す。例えば、送信制御部14mは、100msecに引き下げられていた送信間隔F2を初期値である33msecに戻す。これは、時間差が所定のフレーム数にわたって閾値Th2以下である場合には、静止画および動画の符号化データの伝送および静止画および動画の符号化データのデコードが安定していると推定できるからである。
他の一態様としては、送信制御部14mは、第1のエンコーダ14eまたは第2のエンコーダ14gへ画像を入力する。これを具体的に説明すると、まず、送信制御部14mは、送信間隔レジスタから送信間隔F1及び送信間隔F2を読み出す。その上で、送信制御部14mは、動画化が実行中である場合には、前回に動画の符号化データを送信してから経過した送信経過時間t2が送信間隔F2に到達したか否か、すなわち送信経過時間t2≧送信間隔F2であるか否かを判定する。このとき、送信制御部14mは、送信経過時間t2≧送信間隔F2である場合には、高頻度変更領域または変更領域の画像を第2のエンコーダ14gへ入力する。一方、送信制御部14mは、送信経過時間t2<送信間隔F2である場合には、高頻度変更領域または変更領域の画像を第2のエンコーダ14gへ入力せず、送信間隔F2を経過するまで待機させる。
また、送信制御部14mは、前回に更新矩形の画像の符号化データを送信してから経過した送信経過時間t1が送信間隔F1に到達したか否か、すなわち送信経過時間t1≧送信間隔F1であるか否かを判定する。このとき、送信制御部14mは、送信経過時間t1≧送信間隔F1である場合には、高頻度変更領域に含まれない更新矩形の画像を第1のエンコーダ14eへ入力する。一方、送信制御部14mは、送信経過時間t1<送信間隔F1である場合には、更新矩形の画像を第1のエンコーダ14eへ入力せず、送信間隔F1を経過するまで待機させる。
その後、送信制御部14mは、更新矩形の画像、高頻度変更領域または変更領域の画像のいずれかを第1のエンコーダ14eまたは第2のエンコーダ14gへ入力したか、すなわち送信データがあるか否かを判定する。このとき、送信制御部14mは、送信データが存在する場合には、第1の送信部14fまたは第2の送信部14hのいずれかにヘッダ情報を付加させる。例えば、送信制御部14mは、第1のエンコーダ14eだけに画像が入力された場合、あるいは第1のエンコーダ14e及び第2のエンコーダ14gの両方へ画像が入力された場合には、第1の送信部14fにヘッダ情報を付加するように指示する。一方、送信制御部14mは、第2のエンコーダ14gにしか画像が入力されなかった場合には、第2の送信部14hにヘッダ情報を付加するように指示する。また、送信制御部14mは、第1のエンコーダ14eまたは第2のエンコーダ14gのいずれにも画像が入力されなかった場合には、送信データがないので、ヘッダ情報を付加する指示は実行しない。
なお、OS実行制御部11a、アプリ実行制御部11b、グラフィックドライバ12、リモート画面制御部14には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部14に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)が挙げられる。また、電子回路としては、CPU(Central Processing Unit)やMPU(Micro Processing Unit)などが挙げられる。
[クライアント端末の構成]
次に、本実施例に係るクライアント端末の機能的構成について説明する。図1に示すように、クライアント端末20は、入力部21と、表示部22と、クライアント側のリモート画面制御部23とを有する。なお、図1の例では、図1に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。
入力部21は、各種の情報、例えば後述のクライアント側リモート画面制御部23に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部22も、マウスと協働して、ポインティングデバイス機能を実現する。
表示部22は、各種の情報、例えばサーバ装置10から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。
リモート画面制御部23は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置10によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部23は、図1に示すように、操作情報通知部23aと、第1の受信部23bと、第1のデコーダ23cと、第1の表示制御部23dとを有する。さらに、リモート画面制御部23は、第2の受信部23eと、第2のデコーダ23fと、第2の表示制御部23gと、ヘッダ返信部23hとを有する。
操作情報通知部23aは、入力部21による操作情報をサーバ装置10へ通知する処理部である。一態様としては、操作情報通知部23aは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部23aは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。
第1の受信部23bは、サーバ装置10の第1の送信部14fにより送信された更新矩形の符号化データを受信する処理部である。一態様としては、第1の受信部23bは、サーバ装置10から受信した更新矩形の符号化データからヘッダ情報を取り出し、ヘッダ情報については第1の表示制御部23dへ出力する一方で、更新矩形の符号化データについては第1のデコーダ23cへ出力する。これによって、ヘッダ情報だけデコードをスキップさせる。なお、第1の受信部23bは、サーバ装置10の高頻度変更領域識別部14dによって送信された高頻度変更領域の属性情報も受信する。
第1のデコーダ23cは、第1の受信部23bによって受信された更新矩形の符号化データをデコードする処理部である。この第1のデコーダ23cには、サーバ装置10に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。
第1の表示制御部23dは、第1のデコーダ23cによってデコードされた更新矩形の画像を表示部22に表示させる処理部である。一態様としては、第1の表示制御部23dは、第1の受信部23bによって受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部22の画面領域に更新矩形のビットマップ画像を表示させる。また、第1の表示制御部23dは、第1の受信部23bによって高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第1の表示制御部23dは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部22の画面領域をビットマップ画像の表示対象外のブランク領域とする。このようにして画面の描画が終了すると、第1の表示制御部23dは、第1の受信部23bから入力されたヘッダ情報を後述のヘッダ返信部23へ出力する。
第2の受信部23eは、サーバ装置10の第2の送信部14hにより送信された動画の符号化データを受信する処理部である。この第2の受信部23eは、サーバ装置10の高頻度変更領域識別部14dによって送信された高頻度変更領域の属性情報も受信する。
第2のデコーダ23fは、第2の受信部23eによって受信された動画の符号化データをデコードする処理部である。この第2のデコーダ23fには、サーバ装置10に搭載されたエンコード方式に適合するデコード方式のデコーダが搭載される。
第2の表示制御部23gは、第2の受信部23eによって受信された高頻度変更領域の属性情報に基づき、第2のデコーダ23fによってデコードされた高頻度変更領域または変更領域の画像を表示部22に表示させる処理部である。一態様としては、第2の表示制御部23gは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部22の画面領域に高頻度変更領域の動画を再生させる。なお、動画の符号化データにヘッダ情報が付加されていた場合には、静止画の場合と同様に、デコードおよび画面の描画が終了した段階で後述のヘッダ返信部23hへ出力する。
ヘッダ返信部23hは、ヘッダ情報をサーバ装置10へ返信する処理部である。一態様としては、ヘッダ返信部23hは、サーバ装置10から第1の受信部23b及び第1の表示制御部23dを経由して入力されたヘッダ情報をサーバ装置10へ送信する。このようにヘッダ情報を返信することによって、サーバ装置10側で送信時刻と返信時刻の時間差から、ネットワークの伝送遅延、ひいては画面の描画遅延を推定することが可能になる。
なお、クライアント側のリモート画面制御部23には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部23に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ASICやFPGAが挙げられる。また、電子回路としては、CPUやMPUなどが挙げられる。
[処理の流れ]
次に、本実施例に係るシンクライアントシステムの処理の流れについて説明する。なお、ここでは、サーバ装置10によって実行される(1)画像送信処理を説明した後に、(2)送信間隔変更処理を説明する。
(1)画像送信処理
図7及び図8は、実施例1に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置10によって実行される処理であり、クライアント端末20が起動されている限り繰り返し実行する処理である。
図7に示すように、サーバ装置10は、送信間隔レジスタに記憶された静止画の送信間隔F1及び動画の送信間隔F2に初期値「33msec」を書き込む初期化を実行する(ステップS101)。
その後、サーバ装置10は、フレームバッファ13にビットマップ画像が描画されて前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成されると(ステップS102肯定)、次のような処理を実行する。すなわち、サーバ装置10は、送信間隔レジスタから静止画の送信間隔F1及び動画の送信間隔F2を読み出す(ステップS103)。
そして、サーバ装置10は、先に生成された更新矩形の画像から更新矩形送信用のパケットを生成し(ステップS104)、生成された更新矩形を図示しない作業用の内部メモリへ蓄積する(ステップS105)。
このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合(ステップS106否定)には、以降に続く高頻度変更領域の識別に関する処理をとばし、図8に示すステップS115へ移行する。
一方、更新矩形の蓄積を開始してから所定の期間が経過した場合(ステップS106肯定)には、サーバ装置10は、次のような処理を行う。すなわち、サーバ装置10は、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する(ステップS107)。そして、サーバ装置10は、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する(ステップS108)。
その後、サーバ装置10は、変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する(ステップS109)。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合(ステップS109否定)には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップS114へ移行する。
一方、変更頻度がしきい値を超えるメッシュが存在する場合(ステップS109肯定)には、サーバ装置10は、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する(ステップS110)。
そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合(ステップS111肯定)には、サーバ装置10は、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する(ステップS112)。なお、高頻度変更領域の候補が複数存在しない場合(ステップS111否定)には、矩形の合成を行わずにステップS113へ移行する。
続いて、サーバ装置10は、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末20へ送信する(ステップS113)。そして、サーバ装置10は、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする(ステップS114)。
その後、図8に示すように、動画化が実行中である場合(ステップS115肯定)には、サーバ装置10は、動画の送信経過時間t2が送信間隔F2に到達したか否か、すなわち送信経過時間t2≧送信間隔F2であるか否かを判定する(ステップS116)。
このとき、送信経過時間t2≧送信間隔F2である場合(ステップS116肯定)には、サーバ装置10は、高頻度変更領域または変更領域の画像を動画の符号化データへエンコードする(ステップS117)。
一方、送信経過時間t2<送信間隔F2である場合(ステップS116否定)には、サーバ装置10は、動画の符号化データの送信間隔を空ける必要があるので、ステップS117をスキップし、ステップS118へ移行する。
続いて、サーバ装置10は、静止画の送信経過時間t1が送信間隔F1に到達したか否か、すなわち送信経過時間t1≧送信間隔F1であるか否かを判定する(ステップS118)。
このとき、送信経過時間t1≧送信間隔F1である場合(ステップS118肯定)には、サーバ装置10は、更新矩形の画像を静止画の符号化データへエンコードする(ステップS119)。
一方、送信経過時間t1<送信間隔F1である場合(ステップS118否定)には、サーバ装置10は、静止画の符号化データの送信間隔を空ける必要があるので、ステップS119をスキップし、ステップS120へ移行する。
そして、ステップS117またはステップS119の処理でエンコードされた静止画または動画の符号化データ、すなわち送信データが存在する場合(ステップS120肯定)には、サーバ装置10は、次のような処理を実行する。すなわち、サーバ装置10は、静止画または動画のいずれかの符号化データにフレームID及び送信時刻を含むヘッダ情報を付加する(ステップS121)。その上で、サーバ装置10は、静止画の符号化データ及び/又は動画の符号化データの送信データをクライアント端末20へ送信する(ステップS122)。
その後、サーバ装置10は、ステップS102の処理に戻り、クライアント端末20が起動している限り、ステップS102〜ステップS122までの処理を繰り返し実行する。なお、クライアント端末20の電源がシャットダウンされた場合には、サーバ装置10は、処理を終了する。
(2)送信間隔変更処理
次に、本実施例に係る送信間隔変更処理について説明する。図9は、実施例1に係る送信間隔変更処理の手順を示すフローチャートである。この送信間隔変更処理は、サーバ装置10によって実行される処理であり、クライアント端末20が起動中である限り、繰り返し実行される。
図9に示すように、ヘッダ情報の返信を受信すると(ステップS201肯定)、サーバ装置10は、ヘッダ情報の返信が受信された受信時刻からヘッダ情報に含まれる送信時刻を差し引くことによって送信時刻と受信時刻との時間差を算出する(ステップS202)。
そして、サーバ装置10は、ステップS201のようにして算出した送信時刻と受信時刻との時間差が閾値Th1以上であるか否かを判定する(ステップS203)。このとき、時間差が閾値Th1以上である場合(ステップS203肯定)には、サーバ装置10は、動画化を実行中であるか否かをさらに判定する(ステップS204)。
ここで、動画化が未だ実行されていない場合(ステップS204否定)には、データ量の多い更新矩形の静止画の符号化データがネットワークのトラフィックを増大させている可能性が高いと推定できる。この場合には、サーバ装置10は、当該判定を実行した段階で変更頻度を判別する処理を切り上げて、変更頻度判別用のマップ内で変更のあった変更領域の画像を第2のエンコーダ14gへ入力することによって、動画化を強制的に開始する(ステップS205)。
一方、動画化が実行中である場合(ステップS204肯定)には、クライアント端末20の性能が現状のフレームレートで動画の符号化データをデコードするには能力不足であると推定できる。この場合には、サーバ装置10は、動画の送信間隔F2を変更前よりも長い送信間隔に変更する(ステップS206)。
また、送信時刻と受信時刻との時間差が閾値Th1未満(ステップS203否定)である場合には、サーバ装置10は、送信時刻と受信時刻との時間差が所定のフレーム数にわたって閾値Th2以下であるか否かをさらに判定する(ステップS207)。
このとき、時間差が所定のフレーム数にわたって閾値Th2以下である場合(ステップS207肯定)には、サーバ装置10は、動画の送信間隔F2を変更前の送信間隔に戻す(ステップS208)。なお、時間差が所定のフレーム数にわたって閾値Th2以下でない場合(ステップS207否定)には、送信間隔を戻さずに、上記のステップS201へ移行する。
上記のステップS205、ステップS206またはステップS208の処理が終了すると、サーバ装置10は、ステップS201の処理へ戻り、クライアント端末20が起動中である限り、ステップS201〜ステップS208までの処理を繰り返し実行する。なお、クライアント端末20の電源がシャットダウンされた場合には、サーバ装置10は、処理を終了する。
[実施例1の効果]
上述してきたように、本実施例に係るサーバ装置10では、更新矩形の静止画がネットワークの帯域を圧迫している可能性が高い場合には、動画化を強制的に開始する。また、本実施例に係るサーバ装置10では、クライアント端末20の性能が動画のデコードに追いつかない場合には、動画の符号化データの送信間隔を長くする。したがって、本実施例に係るサーバ装置10によれば、シンクライアントの操作レスポンスの低下を抑制しつつ、クライアント側での画面の描画遅延を抑制することが可能になる。
また、本実施例に係るサーバ装置10は、変更領域の画像が複数存在する場合に、少なくとも1つの変更領域の画像にヘッダ情報を付加する。このため、本実施例に係るサーバ装置10では、クライアント端末20で動画の符号化データのデコード及び画面の描画がなされてからヘッダ情報だけを返信させることで、クライアント側での描画遅延をフレーム単位で監視することができる。よって、本実施例に係るサーバ装置10によれば、ネットワークのトラフィック及びクライアント端末20の負荷と、描画遅延の監視精度とのトレードオフを調和させつつ、描画遅延を監視させることができる。
さらに、本実施例に係るサーバ装置10は、クライアント端末20で描画遅延が発生していない場合に、動画の符号化データを送信させる送信間隔F2を変更前の送信間隔に戻す。よって、本実施例に係るサーバ装置10によれば、クライアント端末20がネットワークの伝送遅延や描画遅延から復帰した場合には、動画の符号化データの送信をセーブせずに元の操作レスポンスを提供できる。