JP2017169001A - 表示画面データの伝送装置、伝送方法及び伝送プログラム - Google Patents

Abstract

【課題】動画の圧縮効率が低下するのを抑制すること。【解決手段】サーバ装置１０は、クライアント端末３０に表示させる表示画面データを記憶するメモリと、クライアント端末３０が有する入力装置のポインタの位置を取得する取得部と、メモリに記憶された表示画面データを更新する更新部と、メモリに記憶された表示画面データのフレーム間で更新頻度が閾値以上である領域を識別する識別部と、ポインタの位置の軌跡から更新頻度が閾値以上である領域の移動方向を探索する探索部と、更新頻度が前記閾値以上である領域を分割する境界線を移動方向に沿って設定することにより領域を分割する分割部と、領域が分割された各要素の画像に関する動画圧縮を複数のプロセッサに割り当て並列処理する圧縮部と、各要素の画像に関する動画圧縮データを送信する送信部とを有する。【選択図】図１

Description

本発明は、表示画面データの伝送装置、伝送方法及び伝送プログラムに関する。

シンクライアントシステムというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。このシンクライアントシステムは、実際にはサーバ装置により実行された処理結果やサーバ装置が保持するデータをクライアント端末に表示させつつも、あたかもクライアント端末が主体となって処理を実行しデータを保持しているかのように振る舞う。

例えば、シンクライアントシステムは、サーバ装置で資料作成やメールなどの業務に関するアプリケーションを実行させ、そのアプリケーションの処理結果をクライアント端末に表示させる。かかる業務アプリケーションの他にも、ＣＡＤ（Computer Aided Design）などのように精細な静止画を扱うアプリケーション、さらには、動画を扱うアプリケーションなどがシンクライアントシステムの適用範囲として拡充されつつある。

このように、サーバ装置からクライアント端末へデスクトップ画面のデータが伝送される場合、サーバ装置及びクライアント端末の間を接続するネットワークの帯域幅や伝送データ量などがボトルネックとなり、伝送遅延が発生する場合がある。この伝送遅延によって、サーバ装置からクライアント端末へ伝送されるデスクトップ画面のデータがクライアント端末側で描画されるのが遅れる結果、クライアント端末で行われる操作に対するレスポンスが悪化する。

かかる伝送遅延を抑制する技術の一例として、デスクトップ画面の中で更新が多い領域を動画化し、それ以外のデスクトップ画面上の更新の差分を静止画で送信するハイブリッド方式が提案されている。

国際公開第２０１４／０８０４４０号 特開２０１２−１１９９４５号公報 国際公開第２００９／１０２０１１号

ところで、２Ｋや４Ｋ等の高解像度のディスプレイの普及に伴って、シンクライアントシステムにおいても、サーバ装置が動画の圧縮符号化を実行する処理量や動画の圧縮符号化後にサーバ装置がクライアント端末へ伝送するデータ量も増加すると考えられる。

このことから、上記のハイブリッド方式において、動画化が行われる領域が分割された複数の小領域ごとに複数のＣＰＵ（Central Processing Unit）コアを利用して動画の圧縮符号化を並列して実行することも考えられる。

しかしながら、上記の技術では、デスクトップ画面上で動画化する領域の圧縮効率が低下する場合がある。

すなわち、動画の圧縮符号化では、フレーム間予測により圧縮効率が高められる。かかるフレーム間予測では、動きベクトル探索（ＭＥ：Motion Estimation）により動き補償が行われる。ところが、デスクトップ画面上で動画化する領域が分割される場合、当該領域が分割される方向によっては必ずしも動き補償が有効に機能しない場合がある。例えば、デスクトップ画面上で動画化する領域が分割されない場合に検出される動きベクトルとは直交する方向に当該領域が分割される場合、分割が一因となって動きベクトルの検出が不能となり、圧縮効率が低下する場合がある。

１つの側面では、本発明は、動画の圧縮効率が低下するのを抑制できる表示画面データの伝送装置、伝送方法及び伝送プログラムを提供することを目的とする。

一態様では、表示画面データの伝送装置は、端末装置に表示させる表示画面データを記憶するメモリと、前記端末装置が有する入力装置のポインタの位置を取得する取得部と、前記メモリに記憶された表示画面データを更新する更新部と、前記メモリに記憶された表示画面データのフレーム間で更新頻度が閾値以上である領域を識別する識別部と、前記ポインタの位置の軌跡から前記更新頻度が前記閾値以上である領域の移動方向を探索する探索部と、前記更新頻度が前記閾値以上である領域を分割する境界線を前記移動方向に沿って設定することにより前記領域を分割する分割部と、前記領域が分割された各要素の画像に関する動画圧縮を複数のプロセッサに割り当て並列処理する圧縮部と、前記各要素の画像に関する動画圧縮データを送信する送信部とを有する。

１つの側面として、動画の圧縮効率が低下するのを抑制できる。

図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。 図２は、デスクトップ画面の一例を示す図である。 図３Ａは、移動ベクトルの算出方法の一例を示す図である。 図３Ｂは、移動ベクトルの算出方法の一例を示す図である。 図３Ｃは、移動ベクトルの算出方法の一例を示す図である。 図４は、デスクトップ画面の一例を示す図である。 図５は、デスクトップ画面の一例を示す図である。 図６は、デスクトップ画面の一例を示す図である。 図７は、デスクトップ画面の一例を示す図である。 図８は、デスクトップ画面の一例を示す図である。 図９は、実施例１に係る分割処理の手順を示すフローチャート（１）である。 図１０は、実施例１に係る分割処理の手順を示すフローチャート（２）である。 図１１は、実施例１に係る第１の送信制御処理の手順を示すフローチャートである。 図１２は、実施例１に係る第２の送信制御処理の手順を示すフローチャートである。 図１３は、実施例１及び実施例２に係る伝送プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に添付図面を参照して本願に係る表示画面データの伝送装置、伝送方法及び伝送プログラムについて説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。図１に示すシンクライアントシステム１は、クライアント（client）端末３０が表示するデスクトップ画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０により実行された処理結果や保持するデータをクライアント端末３０に表示させつつも、あたかもクライアント端末３０が主体となって処理を実行したり、データを保持しているかのように振る舞う。

図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末３０とを有する。ここで、図１には、１つのサーバ装置１０につき１つのクライアント端末が接続される場合を例示したが、１つのサーバ装置１０に複数のクライアント端末を接続することもできる。すなわち、シンクライアントシステム１は、サーバベース方式、ブレードＰＣ方式及びＶＤＩ（Virtual Desktop Infrastructure）方式などの任意の形態で実装することができる。

これらサーバ装置１０及びクライアント端末３０は、ネットワーク２を介して、相互に通信可能に接続される。かかるネットワーク２には、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（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）実行部１１ａと、Ａｐｐ（Application program）実行部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、サーバ側リモート画面制御部１４とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば通信制御用のインタフェース、例えばＮＩＣ（Network Interface Card）などの機能を有するものとする。

ＯＳ実行部１１ａは、基本ソフトウェアであるＯＳの実行を制御する処理部である。

一実施形態として、ＯＳ実行部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行部１１ａは、マウスカーソルの位置がアプリケーションのアイコン上に存在する状態でダブルクリックが検出された場合、当該アイコンに対応するアプリケーションの起動を後述のＡｐｐ実行部１１ｂへ指示する。他の一例として、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作が検出された場合、ＯＳ実行部１１ａは、そのコマンドの実行をＡｐｐ実行部１１ｂへ指示する。

Ａｐｐ実行部１１ｂは、ＯＳ実行部１１ａによる指示にしたがってアプリケーションの実行を制御する処理部である。

一実施形態として、Ａｐｐ実行部１１ｂは、ＯＳ実行部１１ａによりアプリケーションの起動が指示された場合や起動中のアプリケーションにコマンドの実行が指示された場合、アプリケーションを動作させる。そして、Ａｐｐ実行部１１ｂは、アプリケーションを実行することにより得られた処理結果の表示用イメージをフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合、Ａｐｐ実行部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。

なお、Ａｐｐ実行部１１ｂが実行するアプリケーションは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリケーションであってもよい。

グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。

一実施形態として、グラフィックドライバ１２は、Ａｐｐ実行部１１ｂからの描画要求を受け付けた場合、アプリケーションの処理結果の表示用イメージをアプリケーションにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリケーションにより描画要求を受け付ける場合を例示したが、ＯＳ実行部１１ａからの描画要求を受け付けることもできる。例えば、グラフィックドライバ１２は、ＯＳ実行部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。

フレームバッファ１３は、グラフィックドライバ１２により描画されたビットマップデータを記憶する記憶デバイスである。

一実施形態として、フレームバッファ１３には、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭやフラッシュメモリなどの半導体メモリ素子を採用することができる。なお、フレームバッファ１３には、必ずしも半導体メモリ素子を採用せずともかまわず、ＨＤＤ（Hard Disk Drive）、光ディスクやＳＳＤ（Solid State Drive）などの補助記憶装置を採用することとしてもかまわない。

サーバ側リモート画面制御部１４は、サーバ側リモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末３０へ提供する処理部である。このサーバ側リモート画面制御部１４は、図１に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、更新頻度測定部１４ｃと、高頻度更新領域識別部１４ｄと、エンコーダ１４ｍと、第１の画像送信部１４ｋと、第２の画像送信部１４ｎとを有する。

操作情報取得部１４ａは、クライアント端末３０から操作情報を取得する処理部である。

一実施形態として、操作情報取得部１４ａは、上記の操作情報の例として、クライアント端末３０からマウスに関する操作情報やキーボードに関する操作情報などを取得することができる。例えば、操作情報取得部１４ａは、マウスに関する操作情報の例として、マウスの左右のクリックを始め、ダブルクリックやドラッグの他、デスクトップ画面上におけるマウスカーソルの位置やマウスホイールの回転量などを取得することができる。また、操作情報取得部１４ａは、キーボードに関する操作情報の例として、キーボードとして配列される各種のキー、例えばローマ字キー、ファンクションキー、Ｃｔｒｌキー、Ｓｈｉｆｔキー、テンキー、または、これらの組合せに関する押下操作を取得することができる。

画面生成部１４ｂは、クライアント端末３０の表示部３２に表示させるデスクトップ画面の画像を生成する処理部である。

一実施形態として、画面生成部１４ｂは、上記のデスクトップ画面を更新する間隔、例えば３０ｆｐｓが経過する度に、次のような処理を起動する。以下では、クライアント端末３０に表示させるデスクトップ画面を更新する間隔のことを「画面更新間隔」と記載する場合がある。かかる画面更新間隔は、サーバ装置１０及びクライアント端末３０の間の帯域幅やサーバ装置１０及びクライアント端末３０の性能などにより任意の間隔を採用することができる。例えば、画面生成部１４ｂは、サーバ装置１０からクライアント端末３０へ最後に送信された時点におけるデスクトップ画面全体のビットマップデータを保存する内部メモリ（不図示）と、フレームバッファ１３とを参照する。そして、画面生成部１４ｂは、上記の内部メモリに保存されたデスクトップ画面のビットマップデータと、フレームバッファ１３に記憶されたデスクトップ画面のビットマップデータとの間で画素値に差分がある画素を抽出する。その上で、画面生成部１４ｂは、先に抽出された画素にラベリング処理を実行し、同一のラベルが付与されたブロブを矩形状に形成することにより、上記の更新領域のパケットを生成する。このとき、画面生成部１４ｂは、更新領域ごとに当該更新領域の位置および大きさを特定可能な属性情報、例えば更新領域の左上の頂点の座標と更新領域の幅および高さとを付与する。

更新頻度測定部１４ｃは、デスクトップ画面が分割された要素ごとにフレーム間の更新の頻度を測定する処理部である。

一実施形態として、更新頻度測定部１４ｃは、デスクトップ画面がメッシュ状に分割されたメッシュの要素ごとに当該要素の更新頻度を測定する。かかる更新頻度の測定には、一例として、デスクトップ画面のメッシュに含まれる要素ごとに当該要素の更新回数が対応付けられた更新回数マップが用いられる。ここで言う「更新回数」とは、一例として、過去の所定のフレーム数Ｎ（Ｎは自然数）の間に要素が更新された回数を指す。例えば、更新頻度測定部１４ｃは、上記の画面更新間隔が経過する度に、次のような処理を実行する。すなわち、更新頻度測定部１４ｃは、上記の更新回数マップにおいてＮフレーム前に更新回数がインクリメントされた要素の更新回数をデクリメントすることにより、上記の更新回数マップから最古の測定結果を破棄する。その後、更新頻度測定部１４ｃは、画面生成部１４ｂにより生成された更新領域ごとに当該更新領域の属性情報により定義された平面が重なるメッシュの要素を検出する。その上で、更新頻度測定部１４ｃは、上記の更新回数マップに含まれる更新回数のうち、所定数、例えば「１」以上の更新領域が重なるメッシュの要素に対応する更新回数をインクリメントする。

高頻度更新領域識別部１４ｄは、デスクトップ画面のうち高頻度で更新される領域を高頻度更新領域として識別する処理部である。

一実施形態として、高頻度更新領域識別部１４ｄは、上記の画面更新間隔が経過する度に、上記の更新回数マップを用いて高頻度更新領域を識別する。例えば、高頻度更新領域識別部１４ｄは、上記の更新回数マップに含まれるメッシュの要素のうち更新回数が所定の閾値を超える要素を抽出する。その上で、高頻度更新領域識別部１４ｄは、更新回数が閾値を超える要素が存在する場合、先に抽出された要素にラベリング処理を実行し、同一のラベルが付与された要素のブロブを「高頻度更新領域」として識別する。なお、ここでは、要素のブロブを高頻度更新領域として識別する場合を例示したが、当該ブロブを所定の形状、例えば矩形に形成することもできるし、あるいは所定の距離以内にあるブロブ同士を合成してそのバウンディングボックスを高頻度更新領域として識別することもできる。

動画化判定部１４ｅは、動画化の要否を判定する処理部である。

一実施形態として、動画化判定部１４ｅは、所定のフレーム数Ｍ（Ｍは自然数）が経過する度に、高頻度更新領域識別部１４ｄにより高頻度更新領域が識別されたか否かを判定する。このとき、高頻度更新領域が識別された場合、現フレームｔが次に挙げる状況にあることを想定できる。例えば、ＣＡＤ（Computer Aided Design）のモデル、あるいはＣＡＥ（Computer Aided Engineering）の解析モデルなどのように、３ＤＣＧ（three-Dimensional Computer Graphics）によりレンダリングされたモデルがマウスイベント、例えばドラッグ＆ドロップにより移動された状況が挙げられる。この他、各種のウィンドウがマウスイベントにより移動された状況、さらには、クライアント端末３０で動画が再生されている状況などが挙げられる。このように、デスクトップ画面上に更新頻度が高い領域が存在する場合、動画化が実施される。一方、高頻度更新領域が識別されなかった場合、デスクトップ画面上で更新頻度が高い領域が存在しない可能性が高いと推定することができる。この場合、動画化は実施されない。

ベクトル情報算出部１４ｆは、マウスカーソルに関するベクトル情報を算出する処理部である。

一側面として、ベクトル情報算出部１４ｆは、動画化判定部１４ｅにより動画化の要否が判定されてからＭフレームが経過していない場合、あるいは動画化判定部１４ｅにより動画化の要否は判定されたが動画化が実施されない場合、操作情報取得部１４ａにより取得された現フレームｔにおけるマウスカーソルの座標を内部メモリのワークエリアに保存する。このように、現フレームｔにおけるマウスカーソルの座標が内部メモリに保存されることにより、動画化の実施が決定されたフレームでその１つ前のフレームにおけるマウスカーソルの座標を参照できる。

他の側面として、ベクトル情報算出部１４ｆは、動画化判定部１４ｅにより動画化の実施が決定された場合、次のような処理を実行する。すなわち、ベクトル情報算出部１４ｆは、内部メモリに保存された１つ前のフレームｔ−１におけるマウスカーソルの座標を読み出す。その上で、ベクトル情報算出部１４ｆは、内部メモリから読み出された１つ前のフレームｔ−１におけるマウスカーソルの座標と、操作情報取得部１４ａにより取得された現フレームｔにおけるマウスカーソルの座標とからマウスカーソルの移動方向及び移動量をベクトル情報として算出する。

動画化領域設定部１４ｇは、デスクトップ画面上で動画化を実施する領域を設定する処理部である。

一側面として、動画化領域設定部１４ｇは、動画化判定部１４ｅにより動画化の要否が判定されてからＭフレームが経過していない場合、あるいは動画化判定部１４ｅにより動画化の要否は判定されたが動画化が実施されない場合、次のような処理を実行する。すなわち、動画化領域設定部１４ｇは、高頻度更新領域識別部１４ｄにより識別された現フレームｔにおける高頻度更新領域の属性情報を内部メモリのワークエリアに保存する。かかる属性情報とは、高頻度更新領域の位置、形状や大きさを定義する情報を指し、例えば高頻度更新領域を形成する各頂点の座標などが挙げられる。このように、現フレームｔにおける高頻度更新領域の属性情報が内部メモリに保存されることにより、動画化の実施が決定されたフレームでその１つ前のフレームにおける高頻度更新領域の属性情報を参照できる。なお、ここでは、高頻度更新領域の属性情報の一例として、高頻度更新領域を形成する各頂点の座標を例示したが、高頻度更新領域が矩形に形成される場合、高頻度更新領域の左上の頂点の座標と高頻度更新領域の幅および高さとを属性情報に採用することもできる。

他の側面として、動画化領域設定部１４ｇは、動画化判定部１４ｅにより動画化の実施が決定された場合、次のような処理を実行する。すなわち、動画化領域設定部１４ｇは、内部メモリに保存された１つ前のフレームｔ−１における高頻度更新領域の属性情報を読み出す。その上で、動画化領域設定部１４ｇは、ベクトル情報算出部１４ｆにより算出されたマウスカーソルのベクトル情報を用いて、内部メモリから読み出された１つ前のフレームｔ−１における高頻度更新領域と形状が類似する、高頻度更新領域識別部１４ｄにより識別された現フレームｔにおける高頻度更新領域を探索する。

ここで、１つ前のフレームｔ−１及び現フレームｔの間で互いの形状が類似する高頻度更新領域の探索に成功した場合、動画化領域設定部１４ｇは、１つ前のフレームｔ−１から現フレームｔまでの移動方向および移動距離をフレーム間の移動ベクトルとして同定する。一方、１つ前のフレームｔ−１及び現フレームｔの間で互いの形状が類似する高頻度更新領域が探索できない場合、動画化領域設定部１４ｇは、フレーム間の移動ベクトルをＥｍｐｔｙ、例えば「０」に設定する。

その上で、動画化領域設定部１４ｇは、上記の移動ベクトルを用いて、次のＭフレーム後までの期間にわたってデスクトップ画面上で動画化を実施する領域を設定する。以下では、次のＭフレーム後までデスクトップ画面上で動画化を実施する領域のことを「動画化領域」と記載する場合がある。このとき、動画化領域設定部１４ｇは、現フレームｔにおける高頻度更新領域を起点とし、上記の移動ベクトルにしたがって動画化領域を設定することもできるが、当該高頻度更新領域には、１つ前のフレームｔ−１からの移動により現フレームｔでは更新がなかったメッシュの要素も含まれることになる。よって、動画化領域設定部１４ｇは、現フレームｔで画面生成部１４ｂにより生成された更新領域のうち現フレームｔにおける高頻度更新領域と重複する面積が最大である更新領域と重なる要素のブロブを動画化領域の設定に用いることもできる。例えば、動画化領域設定部１４ｇは、現フレームｔにおける更新領域を起点に設定すると共に移動ベクトルに定められた移動方向を目標に設定し、現フレームｔから次に動画化の実施の要否が判定されるＭフレーム後までのＭ回分にわたって現フレームｔにおける更新領域を上記の移動ベクトルに定められた移動距離にしたがって移動させる。その上で、動画化領域設定部１４ｇは、現フレームｔにおける更新領域、Ｍフレーム後に位置すると予測される予測更新領域、又は、現フレームｔからＭフレーム後までの更新領域の移動軌跡のうち少なくともいずれか１つと重なる要素のブロブを動画化領域に設定する。このとき、動画化領域設定部１４ｇは、移動ベクトルが「０」に設定されている場合、現フレームｔにおける更新領域と、Ｍフレーム後に位置すると予測される予測更新領域とが一致するので、現フレームｔにおける更新領域を動画化領域に設定する。このようにして設定された動画化領域の属性情報、例えば動画化領域の各頂点の座標が後述の分割部１４ｈへ出力される。

図２は、デスクトップ画面の一例を示す図である。図２の上段には、１つ前のフレームｔ−１におけるデスクトップ画面２００が示されると共に１つ前のフレームｔ−１における高頻度更新領域２０１が示されている。また、図２の中段には、現フレームｔにおけるデスクトップ画面２１０が示されると共に、図２の下段には、Ｍフレーム後の画面（予測）が示されている。さらに、図２の中段には、現フレームｔにおける高頻度更新領域２１１が破線で示されると共に１つ前のフレームｔ−１における高頻度更新領域２０１が実線で示されている。また、図２の下段には、現フレームｔにおける更新領域２１２が破線（太線）で示されると共にＭフレーム後の予測更新領域２１３が破線（細線）で示され、デスクトップ画面上で動画化が実施される動画化領域２１４が太線で示されている。図２に示す符号Ｃは、マウスカーソルを指す。なお、図２には、一例として、動画化の実施の要否が判定されるフレーム数の間隔が「６」である場合、すなわちＭ＝６である場合が示されている。

図２の中段に示すように、現フレームｔで高頻度更新領域２１１が識別されることにより、動画化の実施が決定される。このように動画化の実施が決定された場合、マウスカーソルの移動方向及び移動距離がベクトル情報ｖ１として算出される。ここでは、一例として、ベクトル情報ｖ１に含まれる移動方向が「右方向」である場合を想定する。かかるベクトル情報ｖ１に含まれる移動方向及び移動距離を参照して、１つ前のフレームｔ−１における高頻度更新領域２０１と形状が類似する、現フレームｔにおける高頻度更新領域２１１が探索される。そして、１つ前のフレームｔ−１から現フレームｔまでの高頻度更新領域２０１の移動方向および移動距離が移動ベクトルＶ４として算出される。なお、本例では、マウスカーソルの移動方向及び移動距離であるベクトル情報ｖ１と、移動ベクトルＶ４とは略同一となる。

図３Ａ〜図３Ｃは、移動ベクトルの算出方法の一例を示す図である。図３Ａには、図２に示した高頻度更新領域２０１が示される一方で、図３Ｂには、図２に示した高頻度更新領域２１１が示されている。なお、ここでは、画像の水平方向をＸ軸とし、画像の垂直方向をＹ軸とする画像の座標系を想定して以下の説明を行う。

図３Ａに示す高頻度更新領域２０１が持つ水平方向の線分及び図３Ｂに示す高頻度更新領域２１１が持つ水平方向の線分が比較される。すなわち、高頻度更新領域２０１の頂点Ｐ１及び頂点Ｐ２を結ぶ線分Ｌ１と、高頻度更新領域２１１の頂点Ｐ７及び頂点Ｐ８を結ぶ線分Ｌ７とは、互いのＹ座標が一致する。さらに、高頻度更新領域２０１の頂点Ｐ３及び頂点Ｐ４を結ぶ線分Ｌ３と、高頻度更新領域２１１の頂点Ｐ９及び頂点Ｐ１０を結ぶ線分Ｌ９とは、互いのＹ座標が一致する。さらに、高頻度更新領域２０１の頂点Ｐ５及び頂点Ｐ６を結ぶ線分Ｌ５と、高頻度更新領域２１１の頂点Ｐ１１及び頂点Ｐ１２を結ぶ線分Ｌ１１とは、互いのＹ座標が一致する。

これらのことから、水平方向の線分を垂直方向へシフトせずとも、高頻度更新領域２０１及び高頻度更新領域２１１が持つ水平方向の線分の数、及び、水平方向の線分の高さが一致することがわかる。よって、１つ前のフレームｔ−１及び現フレームｔの間で垂直方向への移動がないと推定できる。

図３Ａに示す高頻度更新領域２０１が持つ垂直方向の線分及び図３Ｂに示す高頻度更新領域２１１が持つ垂直方向の線分を比較すると、高頻度更新領域２０１の頂点Ｐ１及び頂点Ｐ６を結ぶ線分Ｌ６と、高頻度更新領域２１１の頂点Ｐ７及び頂点Ｐ１２を結ぶ線分Ｌ１２とが一致する。その一方で、高頻度更新領域２０１の頂点Ｐ２及び頂点Ｐ３を結ぶ線分Ｌ２と、高頻度更新領域２１１の頂点Ｐ８及び頂点Ｐ９を結ぶ線分Ｌ８とは、互いのＹ座標が所定の閾値以上の区間にわたって重複するが、互いのＸ座標が一致しない。さらに、高頻度更新領域２０１の頂点Ｐ４及び頂点Ｐ５を結ぶ線分Ｌ４と、高頻度更新領域２１１の頂点Ｐ１０及び頂点Ｐ１１を結ぶ線分Ｌ１１とは、互いのＹ座標が所定の閾値以上の区間にわたって重複するが、互いのＸ座標が一致しない。これらのことから、１つ前のフレームｔ−１及び現フレームｔの間で水平方向への移動があると推定できる。

このように水平方向への移動がある場合、１つ前のフレームｔ−１から現フレームｔまでの高頻度更新領域２０１の水平方向への移動距離を算出するために、互いのＹ座標が所定の閾値以上の区間にわたって重複する線分同士をペアとし、高頻度更新領域２０１の垂直方向の線分のＸ座標が高頻度更新領域２１１の垂直方向の線分のＸ座標と一致するまで移動させる。

すなわち、図３Ｃに示すように、高頻度更新領域２０１の線分Ｌ２をベクトル情報ｖ１の移動方向「右方向」にしたがって所定の画素ずつシフトさせる処理を、高頻度更新領域２０１の線分Ｌ２及び高頻度更新領域２１１の線分Ｌ８のＸ座標が一致するまで繰り返し実行する。これにより、線分Ｌ２の水平移動距離ｄ２が算出される。さらに、高頻度更新領域２０１の線分Ｌ４を所定の画素ずつシフトさせる処理を、高頻度更新領域２０１の線分Ｌ４及び高頻度更新領域２１１の線分Ｌ１０のＸ座標が一致するまで繰り返し実行する。これにより、線分Ｌ４の水平移動距離ｄ３が算出される。

このようにして２つの移動ベクトルＶ２及び移動ベクトルＶ３が得られる。すなわち、移動ベクトルＶ２は、垂直移動距離「０」及び水平移動距離「ｄ２」であるので、移動方向が「右方向」であり、移動距離が「ｄ２」と求まる。さらに、移動ベクトルＶ３は、垂直移動距離「０」及び水平移動距離「ｄ３」であるので、移動方向が「右方向」であり、移動距離が「ｄ３」と求まる。これら移動ベクトルＶ２及び移動ベクトルＶ３は、各種の統計処理、例えば平均や中央値の算出処理が実行されることにより、２つの移動ベクトルＶ２及びＶ３を代表する移動ベクトルＶ４を求めることができる。

なお、ここでは、１つ前のフレームｔ−１及び現フレームｔの間で垂直方向への移動がない場合を例示したが、１つ前のフレームｔ−１及び現フレームｔの間で垂直方向への移動がある場合、図３Ｃを用いて説明した処理を垂直方向へシフトさせる処理へ読み替えることにより垂直移動距離を求めることができる。そして、ベクトル情報ｖ１の移動方向が水平又は垂直でない場合、ベクトル情報ｖ１の移動方向を水平成分および垂直成分に分解して参照することとすればよい。

図２の説明に戻り、移動ベクトルＶ４が算出されると、図２の下段に示す通り、現フレームｔにおける更新領域２１２を起点に設定すると共に移動ベクトルＶ４に定められた移動方向「右方向」を目標に設定し、現フレームｔから次に動画化の実施の要否が判定される６フレーム後までの６回分にわたって現フレームｔにおける更新領域２１２を上記の移動ベクトルＶ４に定められた移動距離、例えば（ｄ２＋ｄ３）／２にしたがって移動させる。これにより、６フレーム後に位置すると予測される予測更新領域２１３が導出される。その上で、更新領域２１２、予測更新領域２１３、又は、現フレームｔからＭフレーム後までの更新領域２１２の移動軌跡のうち少なくともいずれか１つと重なる要素のブロブが動画化領域２１４として設定される。

このような動画化領域を設定することにより、フレーム間の移動ベクトルにしたがってＭフレーム後の将来に亘って更新頻度が高まると予測される範囲を推定できる。このため、現フレームｔまでの過去のフレームの更新頻度により定められた高頻度更新領域よりも、１フレームのトータルでサーバ装置１０からクライアント端末３０へ伝送されるデータ量を低減できる可能性が高まる。

図１の説明に戻り、分割部１４ｈは、動画化領域を分割する処理部である。

一実施形態として、分割部１４ｈは、動画化領域設定部１４ｇより設定された動画化領域の属性情報から動画化領域のサイズ、すなわち面積を算出する。続いて、分割部１４ｈは、後述のエンコーダ１４ｍに実装されるＣＰＵコア数と動画化領域のサイズとから、ＣＰＵ１コアあたりの処理サイズを決定する。その後、分割部１４ｈは、動画化領域のサイズが所定の閾値、例えばＣＰＵ１コアあたりの処理サイズ以下であるか否かを判定する。このとき、動画化領域のサイズが所定の閾値以下である場合、後述のエンコーダ１４ｍに実装されるＣＰＵコアが発揮する性能で動画化領域全体をエンコードできると推定できる。この場合、動画化領域を分割することにより動画の圧縮符号化処理で発生するオーバーヘッドをあえて被らずともよい。したがって、分割部１４ｈは、動画化領域の分割数を「１」に設定することにより、動画化領域の分割により動画の圧縮符号化処理にオーバーヘッドの発生を抑制する。一方、動画化領域のサイズが所定の閾値を超える場合、動画化領域のサイズが後述のエンコーダ１４ｍに実装されるＣＰＵコアが発揮する性能では手に余ると判断できる。この場合、動画化領域の分割が実施される。

すなわち、分割部１４ｈは、動画化領域のサイズ及びＣＰＵ１コアあたりの処理サイズに基づいて動画化領域の分割数を決定する。例えば、分割部１４ｈは、分割数の算出式「分割数＝（動画化領域のサイズ×平均処理時間）÷ＣＰＵ１コアあたりの処理サイズ」にしたがって分割数を決定する。かかる分割数の算出式における「平均処理時間」とは、単位面積あたりの動画圧縮にかかる１フレームあたりの平均所要時間を指す。例えば、後述のエンコーダ１４ｍの各ＣＰＵコアで動画圧縮処理が実行される場合にその所要時間を計測し、計測された所要時間を各ＣＰＵコアにより動画圧縮処理が行われたサイズ及びフレーム数で正規化することにより算出できる。

その上で、分割部１４ｈは、先に決定された動画化領域の分割数と、動画化領域設定部１４ｇにより算出された移動ベクトルとから、動画化領域を分割する形状およびサイズを決定する。ここで、分割部１４ｈは、動画化領域の面積を分割数で除算することにより分割サイズを決定した上で、動画化領域を分割する境界線を上記の移動ベクトルに含まれる移動方向に沿って設定する。このとき、分割部１４ｈは、移動方向と水平方向のズレが所定の範囲内である場合、上記の境界線を水平方向に設定することができる。例えば、分割部１４ｈは、移動ベクトルの算出時に算出された垂直移動距離が所定の閾値、例えば最小分割サイズ／２以下である場合、上記の境界線を水平方向に設定することができる。また、分割部１４ｈは、移動方向と垂直方向のズレが所定の範囲内である場合、上記の境界線を垂直方向に設定することができる。例えば、分割部１４ｈは、移動ベクトルの算出時に算出された水平移動距離が所定の閾値、例えば最小分割サイズ／２以下である場合、上記の境界線を垂直方向に設定することができる。このように分割用の境界線が設定された後、分割部１４ｈは、上記の境界線にしたがって動画化領域を分割する。

［既存技術の限界］
図４及び図５は、デスクトップ画面の一例を示す図である。図４及び図５には、デスクトップ画面３００上でＣＡＤの３次元モデルなどのオブジェクトＯｂ１がマウスイベントにより右方向へ移動される例が示されている。図４には、デスクトップ画面３００が分割される場合が示される一方で、図５には、デスクトップ画面３００が４分割される場合が示されている。図４に示すデスクトップ画面３００の動画の圧縮符号化が行われる場合、フレーム間予測によりマウスイベントの方向と同一の方向が動きベクトルｍ１として探索される。このようなデスクトップ画面３００において、上記の既存技術では、図５に示すように、境界線ｂ１及び境界線ｂ２により４つの領域に分割される場合がある。この場合、境界線ｂ１により動きベクトルｍ１とは直交する方向に分割されるので、動きベクトルｍ１を検出できない。この結果、動き補償が有効に機能せず、圧縮効率が低下する。

［本実施例に係る分割１］
図６は、デスクトップ画面の一例を示す図である。図６にも、デスクトップ画面４００上でＣＡＤの３次元モデルなどのオブジェクトＯｂ２がマウスイベントにより右方向へ移動される例が示されている。図６の上段には、デスクトップ画面４００が分割される前の状態が示される一方で、図６の下段には、デスクトップ画面４００が分割された後の状態が示されている。図６に示すデスクトップ画面４００で動画化領域設定部１４ｇにより移動ベクトルＶ５が算出されると共に動画化領域４１０が設定されたとしたとき、動画化領域４１０には、移動ベクトルＶ５の移動方向である右方向に沿って境界線ｂ３、ｂ４及びｂ５が設定される。これら境界線ｂ３、ｂ４及びｂ５により動画化領域４１０が分割される場合、動画化領域４１０が分割された４つの要素は、動きベクトルと平行な方向に分割されるので、動きベクトルを検出することができる。この結果、動き補償を有効に機能させることができるので、圧縮効率が低下するのを抑制できる。

［本実施例に係る分割２］
図７は、デスクトップ画面の一例を示す図である。図７には、デスクトップ画面５００上でＣＡＤの３次元モデルなどのオブジェクトＯｂ３がマウスイベントにより下方向へ移動される例が示されている。図７の上段には、デスクトップ画面５００が分割される前の状態が示される一方で、図７の下段には、デスクトップ画面５００が分割された後の状態が示されている。図７に示すデスクトップ画面５００で動画化領域設定部１４ｇにより移動ベクトルＶ６が算出されると共に動画化領域５１０が設定されたとしたとき、動画化領域５１０には、移動ベクトルＶ６の移動方向である下方向に沿って境界線ｂ６及びｂ７が設定される。これら境界線ｂ６及びｂ７により動画化領域５１０が分割される場合、動画化領域５１０が分割された３つの要素は、動きベクトルと平行な方向に分割されるので、動画圧縮時に動きベクトルを検出することができる。この結果、動き補償を有効に機能させることができるので、圧縮効率が低下するのを抑制できる。

［本実施例に係る分割３］
図８は、デスクトップ画面の一例を示す図である。図８には、デスクトップ画面６００上でＣＡＤの３次元モデルなどのオブジェクトＯｂ４がマウスイベントにより右斜め下方向へ移動される例が示されている。図８の上段には、デスクトップ画面６００が分割される前の状態が示される一方で、図８の下段には、デスクトップ画面６００が分割された後の状態が示されている。図８に示すデスクトップ画面６００で動画化領域設定部１４ｇにより移動ベクトルＶ７が算出されると共に動画化領域６１０が設定されたとしたとき、動画化領域６１０の各要素の縦横比が、移動ベクトルＶ７が分解された垂直成分と水平成分の比「１：３」と同一になるように、境界線ｂ８〜ｂ１０が設定される。これら境界線ｂ８〜ｂ１０により動画化領域６１０が分割される場合、動画化領域６１０が分割された６つの要素は、動きベクトルが最大限含まれる状態で分割されるので、動きベクトルとは直交する方向に分割される場合よりも、動画圧縮時に動きベクトルを検出することができる。この結果、動き補償を有効に機能させることができるので、圧縮効率が低下するのを抑制できる。

図１の説明に戻り、送信制御部１４ｊは、動画および静止画の送信制御を行う処理部である。

一側面として、送信制御部１４ｊは、静止画の送信制御を次のように実行する。すなわち、送信制御部１４ｊは、動画化判定部１４ｅにより動画化の実施が決定されている場合、画面生成部１４ｂにより生成された更新領域のうち更新領域を１つ選択する。そして、送信制御部１４ｊは、先に選択された更新領域が動画化領域設定部１４ｇにより設定された動画化領域内に含まれるか否かを判定する。このとき、送信制御部１４ｊは、更新領域が動画化領域内に含まれる場合、当該更新領域を第１の画像送信部１４ｋに送信させない。一方、送信制御部１４ｊは、更新領域が動画化領域内に含まれない場合、第１の画像送信部１４ｋに当該更新領域をクライアント端末３０へ送信させる。その後、送信制御部１４ｊは、画面生成部１４ｂにより生成された全ての更新領域が選択されるまで、上記の送信制御を繰り返し実行する。なお、動画化判定部１４ｅにより動画化の実施が決定されていない場合、画面生成部１４ｂにより生成された各更新領域を第１の画像送信部１４ｋに送信させる。

他の側面として、送信制御部１４ｊは、動画の送信制御を次のように実行する。すなわち、送信制御部１４ｊは、動画化判定部１４ｅにより動画化の実施が決定されている場合、分割部１４ｈにより動画化領域が分割された各要素を後述のエンコーダ１４ｍの各ＣＰＵコアへ割り当てて入力する。

エンコーダ１４ｍは、エンコードを行う処理部である。

一実施形態として、エンコーダ１４ｍは、複数のＣＰＵ（Central Processing Unit）コアにより実装される。これにより、エンコーダ１４ｍは、動画の圧縮符号化を並列して実行することができる。すなわち、エンコーダ１４ｍは、送信制御部１４ｊによりエンコーダ１４ｍの各ＣＰＵコアに割り当てられた動画化領域の各要素を各ＣＰＵコアで並列してエンコードする。なお、エンコード方式の一例として、ＭＰＥＧ−２やＭＰＥＧ−４などのＭＰＥＧ方式やＭｏｔｉｏｎ−ＪＰＥＧ方式などを採用できる。

第１の画像送信部１４ｋは、画面生成部１４ｂにより生成された更新領域の画像および属性情報をクライアント端末３０へ送信する処理部である。この更新領域を送信する場合の通信プロトコルには、一例としてＶＮＣにおけるＲＦＢプロトコルが採用される。

第２の画像送信部１４ｎは、エンコーダ１４ｍにより動画化領域の要素ごとにエンコードされたエンコード画像をクライアント端末３０へ送信する処理部である。このエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。

なお、ＯＳ実行部１１ａ、Ａｐｐ実行部１１ｂ、グラフィックドライバ１２、サーバ側リモート画面制御部１４には、次のようにして実装できる。例えば、ＣＰＵなどの中央処理装置に、上記の各処理部と同様の機能を発揮するプロセスをメモリ上に展開して実行させることにより実現できる。これらの処理部は、必ずしも中央処理装置で実行されずともよく、ＭＰＵ（Micro Processing Unit）に実行させることとしてもよい。また、上記の各処理部は、ハードワイヤードロジックによっても実現できる。

［クライアント端末３０の構成］
次に、本実施例に係るクライアント端末の構成について説明する。図１に示すように、クライアント端末３０は、入力部３１と、表示部３２と、クライアント側リモート画面制御部３３とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。

入力部３１は、各種の情報、例えば後述のクライアント側リモート画面制御部３３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部３２も、マウスと協働して、ポインティングデバイス機能を実現する。

表示部３２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。

クライアント側リモート画面制御部３３は、クライアント側リモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このクライアント側リモート画面制御部３３は、図１に示すように、操作情報通知部３３ａと、第１の画像受信部３３ｂと、第１の表示制御部３３ｃと、第２の画像受信部３３ｄと、デコーダ３３ｅと、第２の表示制御部３３ｆとを有する。

操作情報通知部３３ａは、入力部３１による操作情報をサーバ装置１０へ通知する処理部である。一例として、操作情報通知部３３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスカーソルのデスクトップ画面上の座標などを操作情報として通知する。他の一例として、操作情報通知部３３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。

第１の画像受信部３３ｂは、サーバ装置１０の第１の画像送信部１４ｋにより送信された更新領域の画像および属性情報を受信する処理部である。また、第１の画像受信部３３ｂは、サーバ装置１０の第１の画像送信部１４ｋにより送信された動画化領域の属性情報も受信する。

第１の表示制御部３３ｃは、第１の画像受信部３３ｂにより受信された更新領域の画像を表示部３２に表示させる処理部である。一例としては、第１の表示制御部３３ｃは、第１の画像受信部３３ｂにより受信された更新領域の属性情報に含まれる位置および大きさに対応する表示部３２の画面領域に更新領域のビットマップ画像を表示させる。また、第１の表示制御部３３ｃは、第１の画像受信部３３ｂにより動画化領域の属性情報が受信された場合、次のような処理を行う。すなわち、第１の表示制御部３３ｃは、動画化領域の属性情報に含まれる動画化領域の位置および大きさに対応する表示部３２の画面領域をビットマップ画像の表示対象外のブランク領域とする。

第２の画像受信部３３ｄは、サーバ装置１０の第２の画像送信部１４ｎにより送信された動画化領域の各要素のエンコード画像を受信する処理部である。また、第２の画像受信部３３ｄは、サーバ装置１０の第２の画像送信部１４ｎにより送信された動画化領域の属性情報も受信する。

デコーダ３３ｅは、第２の画像受信部３３ｄにより受信された動画化領域の各要素のエンコード画像をデコードする処理部である。このデコーダ３３ｅは、複数のＣＰＵコアにより実装することもできる。これにより、デコーダ３３ｅは、動画化領域の各要素のエンコード画像の復号化処理を並列して実行することができる。なお、デコーダ３３ｅには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。

第２の表示制御部３３ｆは、第１の画像受信部３３ｂにより動画化領域の属性情報に基づき、デコーダ３３ｅによりデコードされた動画化領域の各要素のデコード画像を表示部３２に表示させる処理部である。一例として、第２の表示制御部３３ｆは、動画化領域の属性情報に含まれる動画化領域の位置および大きさに対応する表示部３２の画面領域に動画化領域のデコード画像を表示させる。

なお、クライアント側リモート画面制御部３３には、次のようにして実装できる。例えば、ＣＰＵなどの中央処理装置に、上記の各処理部と同様の機能を発揮するプロセスをメモリ上に展開して実行させることにより実現できる。これらの処理部は、必ずしも中央処理装置で実行されずともよく、ＭＰＵに実行させることとしてもよい。また、上記の各処理部は、ハードワイヤードロジックによっても実現できる。

［処理の流れ］
次に、本実施例に係るシンクライアントシステム１の処理の流れについて説明する。なお、ここでは、サーバ装置１０により実行される（１）分割処理、（２）第１の送信制御処理、（３）第２の送信制御処理の順に説明する。

（１）分割処理
図９及び図１０は、実施例１に係る分割処理の手順を示すフローチャートである。この処理は、一例として、上記のデスクトップ画面を更新する間隔、例えば３０ｆｐｓが経過する度に繰り返し実行される。

図９に示すように、画面生成部１４ｂは、上記の内部メモリに保存された１つ前のフレームｔ−１のデスクトップ画面のビットマップデータと、フレームバッファ１３に記憶された現フレームｔのデスクトップ画面のビットマップデータとを比較する（ステップＳ１０１）。そして、画面生成部１４ｂは、２つのデスクトップ画面の間で画素値に差分がある画素にラベリング処理を実行し、同一のラベルが付与されたブロブを矩形状に形成することにより、上記の更新領域のパケットを生成する（ステップＳ１０２）。

続いて、更新頻度測定部１４ｃは、上記の更新回数マップにおいてＮフレーム前に更新回数がインクリメントされた要素の更新回数をデクリメントすることにより、上記の更新回数マップから最古の測定結果を破棄する（ステップＳ１０３）。その後、更新頻度測定部１４ｃは、上記の更新回数マップに含まれる更新回数のうち、ステップＳ１０２で生成された更新領域が所定数以上重なるメッシュの要素に対応する更新回数をインクリメントする（ステップＳ１０４）。

そして、高頻度更新領域識別部１４ｄは、上記の更新回数マップに含まれるメッシュの要素のうち更新回数が所定の閾値を超える要素にラベリング処理を実行し、同一のラベルが付与された要素のブロブを高頻度更新領域として識別する（ステップＳ１０５）。

その後、前回に動画化の要否が判定されてから所定のフレーム数Ｍ（Ｍは自然数）が経過していない場合（ステップＳ１０６Ｎｏ）、ベクトル情報算出部１４ｆは、操作情報取得部１４ａにより取得された現フレームｔにおけるマウスカーソルの座標を内部メモリのワークエリアに保存する（ステップＳ１０７）。そして、動画化領域設定部１４ｇは、ステップＳ１０５で識別された現フレームｔにおける高頻度更新領域の属性情報を内部メモリのワークエリアに保存する（ステップＳ１０８）。

一方、前回に動画化の要否が判定されてから所定のフレーム数Ｍが経過した場合（ステップＳ１０６Ｙｅｓ）、動画化判定部１４ｅは、ステップＳ１０５で高頻度更新領域が識別されたか否かにより、動画化を実施するか否かを判定する（ステップＳ１０９）。

このとき、動画化が実施されない場合（ステップＳ１０９Ｎｏ）、ベクトル情報算出部１４ｆは、操作情報取得部１４ａにより取得された現フレームｔにおけるマウスカーソルの座標を内部メモリのワークエリアに保存する（ステップＳ１０７）。そして、動画化領域設定部１４ｇは、ステップＳ１０５で識別された現フレームｔにおける高頻度更新領域の属性情報を内部メモリのワークエリアに保存する（ステップＳ１０８）。

一方、動画化が実施される場合（ステップＳ１０９Ｙｅｓ）、ベクトル情報算出部１４ｆは、内部メモリに保存された１つ前のフレームｔ−１におけるマウスカーソルの座標を読み出す（ステップＳ１１０）。その上で、ベクトル情報算出部１４ｆは、ステップＳ１１０で読み出された１つ前のフレームｔ−１におけるマウスカーソルの座標と、操作情報取得部１４ａにより取得された現フレームｔにおけるマウスカーソルの座標とからマウスカーソルの移動方向及び移動量をベクトル情報として算出する（ステップＳ１１１）。

そして、動画化領域設定部１４ｇは、内部メモリに保存された１つ前のフレームｔ−１における高頻度更新領域の属性情報を読み出す（ステップＳ１１２）。その上で、動画化領域設定部１４ｇは、ステップＳ１１１で算出されたマウスカーソルのベクトル情報を用いて、ステップＳ１１２で読み出された１つ前のフレームｔ−１における高頻度更新領域と形状が類似する、高頻度更新領域識別部１４ｄにより識別された現フレームｔにおける高頻度更新領域を探索する（ステップＳ１１３）。

ここで、図１０に示すように、１つ前のフレームｔ−１及び現フレームｔの間で互いの形状が類似する高頻度更新領域の探索に成功した場合（ステップＳ１１４Ｙｅｓ）、動画化領域設定部１４ｇは、１つ前のフレームｔ−１から現フレームｔまでの移動方向および移動距離をフレーム間の移動ベクトルとして同定する（ステップＳ１１５）。

そして、動画化領域設定部１４ｇは、現フレームｔにおける更新領域を起点に設定すると共に移動ベクトルに定められた移動方向を目標に設定し、現フレームｔから次に動画化の実施の要否が判定されるＭフレーム後までのＭ回分にわたって現フレームｔにおける更新領域を上記の移動ベクトルに定められた移動距離にしたがって移動させることにより、Ｍフレーム後に位置すると予測される予測更新領域を推定する（ステップＳ１１６）。

その上で、動画化領域設定部１４ｇは、現フレームｔにおける更新領域、Ｍフレーム後に位置すると予測される予測更新領域、又は、現フレームｔからＭフレーム後までの更新領域の移動軌跡のうち少なくともいずれか１つと重なる要素のブロブを動画化領域に設定する（ステップＳ１１７）。

一方、１つ前のフレームｔ−１及び現フレームｔの間で互いの形状が類似する高頻度更新領域が探索できない場合（ステップＳ１１４Ｎｏ）、動画化領域設定部１４ｇは、フレーム間の移動ベクトルを「０」に設定することにより、現フレームｔの更新領域をＭフレーム後に位置すると予測される予測更新領域に設定する（ステップＳ１１８）。この場合、動画化領域設定部１４ｇは、現フレームｔにおける更新領域を動画化領域に設定する（ステップＳ１１７）。

続いて、分割部１４ｈは、ステップＳ１１８で設定された動画化領域の属性情報から動画化領域のサイズを算出し、動画化領域のサイズと後述のエンコーダ１４ｍに実装されるＣＰＵコア数とから、ＣＰＵ１コアあたりの処理サイズを決定する（ステップＳ１１９）。その後、分割部１４ｈは、動画化領域のサイズが所定の閾値、例えばＣＰＵ１コアあたりの処理サイズ以下であるか否かを判定する（ステップＳ１２０）。

このとき、動画化領域のサイズが所定の閾値以下である場合（ステップＳ１２０Ｙｅｓ）、後述のエンコーダ１４ｍに実装されるＣＰＵコアが発揮する性能で動画化領域全体をエンコードできると推定できる。この場合、動画化領域を分割することにより動画の圧縮符号化処理で発生するオーバーヘッドをあえて被らずともよい。したがって、分割部１４ｈは、動画化領域の分割数を「１」に設定し（ステップＳ１２４）、ステップＳ１２３の処理へ移行する。

一方、動画化領域のサイズが所定の閾値を超える場合（ステップＳ１２０Ｎｏ）、動画化領域のサイズが後述のエンコーダ１４ｍに実装されるＣＰＵコアが発揮する性能では手に余ると判断できる。この場合、動画化領域の分割が実施される。

すなわち、分割部１４ｈは、動画化領域のサイズ及びＣＰＵ１コアあたりの処理サイズに基づいて動画化領域の分割数を決定する（ステップＳ１２１）。さらに、その上で、分割部１４ｈは、ステップＳ１２１で決定された動画化領域の分割数と、ステップＳ１１５で算出された移動ベクトルとから、動画化領域を分割する形状およびサイズを決定する（ステップＳ１２２）。その後、分割部１４ｈは、ステップＳ１２２で決定された分割形状および分割サイズにしたがって動画化領域を分割し（ステップＳ１２３）、処理を終了する。

（２）第１の送信制御処理
図１１は、実施例１に係る第１の送信制御処理の手順を示すフローチャートである。この処理は、一例として、画面更新間隔が経過する度に繰り返し実行される。図１１に示すように、動画化判定部１４ｅにより動画化の実施が決定されている場合（ステップＳ３０１Ｙｅｓ）、送信制御部１４ｊは、画面生成部１４ｂにより生成された更新領域のうち更新領域を１つ選択する（ステップＳ３０２）。

そして、送信制御部１４ｊは、ステップＳ３０２で選択された更新領域が動画化領域設定部１４ｇにより設定された動画化領域内に含まれるか否かを判定する（ステップＳ３０３）。このとき、更新領域が動画化領域内に含まれる場合（ステップＳ３０３Ｎｏ）、送信制御部１４ｊは、当該更新領域を第１の画像送信部１４ｋに送信させずにステップＳ３０５の処理へ移行する。

一方、更新領域が動画化領域内に含まれない場合（ステップＳ３０３Ｙｅｓ）、送信制御部１４ｊは、第１の画像送信部１４ｋに当該更新領域をクライアント端末３０へ送信させる（ステップＳ３０４）。

その後、画面生成部１４ｂにより生成された全ての更新領域が選択されるまで（ステップＳ３０５Ｎｏ）、上記のステップＳ３０２〜ステップＳ３０４の処理が繰り返し実行される。そして、画面生成部１４ｂにより生成された全ての更新領域が選択された場合（ステップＳ３０５Ｙｅｓ）、処理を終了する。

なお、動画化判定部１４ｅにより動画化の実施が決定されていない場合（ステップＳ３０１Ｎｏ）、送信制御部１４ｊは、画面生成部１４ｂにより生成された各更新領域を第１の画像送信部１４ｋへ順次送信させ（ステップＳ３０６）、処理を終了する。

（３）第２の送信制御処理
図１２は、実施例１に係る第２の送信制御処理の手順を示すフローチャートである。この処理は、一例として、動画化判定部１４ｅにより動画化の実施が決定されている場合に実行される。図１２に示すように、送信制御部１４ｊは、分割部１４ｈにより動画化領域が分割された各要素をエンコーダ１４ｍの各ＣＰＵコアへ割り当てて入力する（ステップＳ５０１）。

そして、エンコーダ１４ｍは、ステップＳ５０１でエンコーダ１４ｍの各ＣＰＵコアに割り当てられた動画化領域の各要素を各ＣＰＵコアで並列してエンコードする（ステップＳ５０２）。

その後、第２の画像送信部１４ｎは、エンコーダ１４ｍにより動画化領域の要素ごとにエンコードされたエンコード画像をクライアント端末３０へ送信し（ステップＳ５０３）、処理を終了する。

［効果の一側面］
上述してきたように、本実施例に係るサーバ装置１０は、サーバがクライアントへ伝送するデスクトップ画面の動画化領域を分割する場合、動画化領域における更新領域の移動方向に沿って動画化領域を分割する境界線を設定して分割する。したがって、本実施例に係るサーバ装置１０によれば、デスクトップ画面上で動画化する領域の圧縮効率が低下するのを抑制できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、サーバ側リモート画面制御部１４に含まれる処理部の一部をサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、サーバ側リモート画面制御部１４に含まれる処理部の一部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の伝送装置の機能を実現するようにしてもよい。

［伝送プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１３を用いて、上記の実施例と同様の機能を有する伝送プログラムを実行するコンピュータの一例について説明する。

図１３は、実施例１及び実施例２に係る伝送プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１３に示すように、コンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１３に示すように、上記の実施例１で示したサーバ側リモート画面制御部１４と同様の機能を発揮する伝送プログラム１７０ａが記憶される。この伝送プログラム１７０ａは、図１に示したサーバ側リモート画面制御部１４の各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から伝送プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、伝送プログラム１７０ａは、図１３に示すように、伝送プロセス１８０ａとして機能する。この伝送プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち伝送プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、伝送プロセス１８０ａが実行する処理の一例として、図９〜図１１に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

なお、上記の伝送プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に伝送プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から伝送プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに伝送プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから伝送プログラム１７０ａを取得して実行するようにしてもよい。

１ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行部
１１ｂ Ａｐｐ実行部
１２ グラフィックドライバ
１３ フレームバッファ
１４ サーバ側リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 更新頻度測定部
１４ｄ 高頻度更新領域識別部
１４ｅ 動画化判定部
１４ｆ ベクトル情報算出部
１４ｇ 動画化領域設定部
１４ｈ 分割部
１４ｊ 送信制御部
１４ｋ 第１の画像送信部
１４ｍ エンコーダ
１４ｎ 第２の画像送信部
３０ クライアント端末
３１ 入力部
３２ 表示部
３３ クライアント側リモート画面制御部
３３ａ 操作情報通知部
３３ｂ 第１の画像受信部
３３ｃ 第１の表示制御部
３３ｄ 第２の画像受信部
３３ｅ デコーダ
３３ｆ 第２の表示制御部

Claims (5)

1. 端末装置に表示させる表示画面データを記憶するメモリと、
   前記端末装置が有する入力装置のポインタの位置を取得する取得部と、
   前記メモリに記憶された表示画面データを更新する更新部と、
   前記メモリに記憶された表示画面データのフレーム間で更新頻度が閾値以上である領域を識別する識別部と、
   前記ポインタの位置の軌跡から前記更新頻度が前記閾値以上である領域の移動方向を探索する探索部と、
   前記更新頻度が前記閾値以上である領域を分割する境界線を前記移動方向に沿って設定することにより前記領域を分割する分割部と、
   前記領域が分割された各要素の画像に関する動画圧縮を複数のプロセッサに割り当て並列処理する圧縮部と、
   前記各要素の画像に関する動画圧縮データを送信する送信部と
   を有することを特徴とする表示画面データの伝送装置。
2. 前記探索部は、前記ポインタの位置の軌跡から前記更新頻度が前記閾値以上である領域の移動方向及び移動距離を探索し、
   前記分割部は、前記移動方向および前記移動距離に基づいて前記更新頻度が閾値以上である領域が所定のフレーム後までに移動する移動範囲に対応する領域を分割することを特徴とする請求項１に記載の表示画面データの伝送装置。
3. 前記分割部は、前記移動範囲に対応する領域の面積と、前記複数のプロセッサの個数とに基づいて前記移動範囲に対応する領域を分割する分割数を決定することを特徴とする請求項２に記載の表示画面データの伝送装置。
4. コンピュータが、
   端末装置が有する入力装置のポインタの位置を取得する処理と、
   前記端末装置に表示させる表示画面データを記憶するメモリに記憶された表示画面のデータを更新する処理と、
   前記メモリに記憶された表示画面データのフレーム間で更新頻度が閾値以上である領域を識別する処理と、
   前記ポインタの位置の軌跡から前記更新頻度が前記閾値以上である領域の移動方向を探索する処理と、
   前記更新頻度が前記閾値以上である領域を分割する境界線を前記移動方向に沿って設定することにより前記領域を分割する処理と、
   前記領域が分割された各要素の画像に関する動画圧縮を複数のプロセッサに割り当て並列処理する処理と、
   前記各要素の画像に関する動画圧縮データを送信する処理と
   を実行することを特徴とする表示画面データの伝送方法。
5. コンピュータに、
   端末装置が有する入力装置のポインタの位置を取得する処理と、
   前記端末装置に表示させる表示画面データを記憶するメモリに記憶された表示画面データを更新する処理と、
   前記メモリに記憶された表示画面データのフレーム間で更新頻度が閾値以上である領域を識別する処理と、
   前記ポインタの位置の軌跡から前記更新頻度が前記閾値以上である領域の移動方向を探索する処理と、
   前記更新頻度が前記閾値以上である領域を分割する境界線を前記移動方向に沿って設定することにより前記領域を分割する処理と、
   前記領域が分割された各要素の画像に関する動画圧縮を複数のプロセッサに割り当て並列処理する処理と、
   前記各要素の画像に関する動画圧縮データを送信する処理と
   を実行することを特徴とする表示画面データの伝送プログラム。

Images