JP4926601B2 - 映像配信システム、クライアント端末及びその制御方法 - Google Patents

Description

本発明は、サーバからネットワークを介して映像データを配送する映像配信システム、クライアント端末及びその制御方法に関する。

近年、撮影した映像データをネットワークを介してサーバからクライアント端末に配送する映像配信システムが普及してきている。このようなシステムで、サーバは例えばネットワークカメラ、クライアント端末はコンピュータで構成されている。このような映像配信システムは、複数の遠隔地に設置されたカメラからの映像をリアルタイムで表示できるという特徴を生かし、特に特定の場所の監視を目的として使用されている。

映像に基づく監視を行う場合、クライアント端末の表示部に多数のサーバからの映像を同時に表示しなければならず、そのため各サーバからの映像は、それぞれ縮小したウインドウで表示されている。また注視したい映像がある場合は、その映像のウインドウのサイズを拡大して表示することができる。このようなウインドウのサイズ変更は、映像を表示するアプリケーションのウインドウのサイズを拡大或は縮小することにより行われる。具体的には、アプリケーションにより表示されているウインドウ枠をマウスでドラグ操作しながら所望のサイズに拡大或は縮小することで行われることが多い。

一方、サーバは事前に設定された解像度で撮影した映像データをクライアント端末に送信している。またこの解像度をクライアント端末からの要求により変更できるサーバが商品化されている。例えば監視者は、６４０×４８０（画素）、３２０×２４０（画素）のいずれかの解像度を選択してサーバに設定し、その設定した解像度で送信されてくる映像データを受信して表示できるものがある。サーバにおける解像度の変更は、映像データの最大解像度の１／２であれば画素のサンプリングを１／２にするだけで容易に実現できる（特許文献１参照）。

従って、サーバが提供する解像度としては、最大解像度をコンピュータや映像メディアの標準的な解像度、例えばＶＧＡサイズ（６４０×４８０（画素））としている。そして、その１／２のＱＶＧＡサイズ（３２０×２４０（画素））、更には、その１／２のＱＱＶＧＡサイズ（１６０×１２０（画素））を提供しているサーバが一般的である。しかし、予め高解像度のＣＣＤで撮像し、任意の解像度に応じた映像領域を送信したり、高速な画像処理ＬＳＩを使用して解像度変換したりすることで、サーバから送信する映像の解像度を既定値以外の任意の解像度に変更できるようにも構成できる。
特開平１１−１９６３７９号公報

サーバから配信されている映像データをクライアント端末で表示している際、クライアント端末で映像ウインドウが任意の大きさに変更されると、クライアント端末で描画サイズを変更するためのリサイズ処理が行われる。例えば、サーバから配信された６４０×４８０（画素）の解像度を有する映像を表示している場合、そのウインドウ枠を縮小する。この場合、クライアント端末では、６４０×４８０（画素）から例えば５００×３００（画素）の解像度へのリサイズ処理が行われる。

このようなクライアント端末でのリサイズ処理では、映像表示の際に隣接する画素間の補間処理やリサンプリング処理が行われるため、クライアント端末での処理に負荷が発生する。特にクライアント端末が多数のサーバと接続して多数の映像を表示している場合に、これら画像に同時にリサイズ処理を実施した場合には負荷の増大が顕著になる。このような負荷により、映像を表示する際にフレームレートの低下や、コンピュータの処理速度の低下が生じる。即ち、監視者が要求する様々な映像品質や、監視者が使用する様々な監視装置の動作状態に適応したリサイズ処理の負荷を低減することができなかった。

またクライアント端末における上述した隣接画素に基づく補間処理による拡大表示では、ウインドウのサイズに応じた最適な画質を得ることができない。例えば、１６０×１２０（画素）の映像データを表示している映像ウインドウを６４０×４８０（画素）に拡大した場合、リサイズ前のデータを縦横４倍に引き伸ばして拡大表示しているため画質の劣化が生じてしまう。

本発明の目的は上記従来技術の問題点を解決することにある。

また本願発明の特徴は、クライアント端末における画像のリサイズの負荷を軽減できる映像配信システム、クライアント端末及びその制御方法を提供することにある。

また本願発明の特徴は、クライアント端末における画像の拡大による画像の画質劣化を防止できる映像配信システム、クライアント端末及びその制御方法を提供することにある。

また本発明の特徴は、クライアント端末やサーバの動作状態やシステムの動作環境に適応した最適なリサイズ方法を選択できる映像配信システム、クライアント端末及びその制御方法を提供することにある。

上記目的を達成するために本発明の一態様に係る映像配信システムは、以下のような構成を備える。即ち、映像データを配信するサーバと、サーバにより配信された映像データをクライアント端末のウインドウに表示させる映像配信システムであって、
前記クライアント端末は、
前記サーバから映像データを受信する受信手段と、
前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更手段と、
前記受信手段により受信した映像データのサイズ変更処理を、前記クライアント端末で行う余力の有無を判定する判定手段と、
前記判定手段により余力があると判定された場合に、前記変更指示で変更されたウインドウの大きさに表示されるように、前記受信した映像データのサイズ変更処理をする第１の変更手段と、
前記判定手段により余力がないと判定された場合に、前記変更指示に応じて変更された前記ウインドウの大きさを示す前記表示サイズ情報を前記サーバに通知する通知手段と、
サイズ変更処理された映像データをウインドウに表示させる表示制御手段とを有し、
前記サーバは、
前記通知手段により通知された前記表示サイズ情報に基づいて、前記クライアント端末に配信する映像データのサイズ変更を行って前記クライアント端末に送信する第２の変更手段を有し、
前記表示制御手段は、前記第１の変更手段、もしくは、前記第２の変更手段によりサイズ変更が行われた映像データをウインドウに表示させることを特徴とする。

本発明によれば、クライアント端末でのリサイズ処理による負荷を低減できる。またこの変倍処理による画質の劣化を防止できるという効果がある。

更に、監視者の映像品質への要求や、監視システムの性能や環境に適応した最適なリサイズ処理の方法を選択できるという効果がある。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜実施の形態１＞
以下、図１〜図３を参照して本発明の実施の形態１を詳細に説明する。

図１は、本発明の実施の形態１に係る映像配信システムの全体システム構成を説明するブロック図である。まず、システムの構成要素について説明する。

サーバ１０１は、具体的には、被写体を撮影するためのネットワークカメラとして構成され、そのカメラで撮影した映像をネットワーク１２１を介して配信している。クライアント端末１１１は、具体的には、サーバ１０１から送信された映像データを受信して表示するコンピュータである。これらサーバ１０１とクライアント端末１１１は、ＬＡＮやインターネット等のネットワーク１２１に接続されている。更に、ネットワーク１２１に複数のサーバ１２２を接続することによって、遠隔地の複数の映像データをクライアント端末１１１でマルチ画面等にして同時表示することが可能となる。また、ネットワーク１２１に複数のクライアント端末１２４を接続することによって、閲覧者を限定せずに映像データの配信を行うことが可能となる。管理者クライアント端末１２３は、サーバ１０１のネットワークカメラの雲台部のパン、チルト操作、およびカメラの諸設定を行うことができるカメラの制御権を持つサーバ１０１の管理者である。

次に、本実施の形態に係るサーバ１０１について説明する。

サーバ１０１は、雲台撮像部１０２、映像変倍部１０３、映像圧縮部１０４、ＣＰＵ１０５、通信Ｉ／Ｆ部１０６を具備している。雲台撮像部１０２は、被写体を撮影し、映像データを映像変倍部１０３に送信する。雲台撮像部１０２は、雲台のパン、チルト駆動を管理者クライアント端末１２３からの制御命令に従って実行する。これにより所望のアングルで撮影することが可能となる。これら管理者クライアント端末１２３からのカメラ制御命令は、ＣＰＵ１０５を介して雲台撮像部１０２で受信される。映像変倍部１０３は、映像データをキャプチャし、事前に設定された解像度でデジタル化する。即ち、本実施の形態の変倍とは、映像データの解像度（サイズ）を変更する処理を指す。本実施の形態では、クライアント端末に提供する映像の解像度を６４０×４８０（画素）、３２０×２４０（画素）、１６０×１２０（画素）の３種類とする。この解像度はクライアント端末からの命令で変更可能であり、これらの変更命令はＣＰＵ１０５を介して映像変倍部１０３で受信される。映像圧縮部１０４は、映像変倍部１０３で撮像した３種類の解像度の映像データをＪＰＥＧフォーマット等で圧縮する。そしてＣＰＵ１０５は、こうして圧縮された３種類の圧縮データをマルチストリーム化する。通信Ｉ／Ｆ部１０６は、これらの映像データをネットワーク１２１に接続されたクライアント端末１１１，１２４に向けて配信する。

次に、本実施の形態に係るクライアント端末１１１について説明する。尚、他のクライアント端末１２４の構成も同様である。

クライアント端末１１１は、通信Ｉ／Ｆ部１１２、ＣＰＵ１１３、表示部１１４、入力部１１５を備えている。入力部１１５は、マウスやキーボードの入力装置であり、アプリケーションの制御や、サーバ１０１への制御命令の入力や送信等に使用する。サーバ１０１から送信された３種類の解像度の映像データは、通信Ｉ／Ｆ部１１２で受信されＣＰＵ１１３に送られる。ＣＰＵ１１３は、このクライアント端末で設定されている表示用の解像度の映像データを解凍し、アプリケーションソフトを介して表示部１１４に映像を表示する。

図２（Ａ）（Ｂ）は、本実施の形態に係るクライアント端末の表示部１１４で表示している画面を模式的に表した図であり、サーバ１０１から配信されている映像データを表示している状態を示している。ここで映像ウインドウのリサイズについて説明する。

図２（Ａ）は、リサイズ前のディスプレイの表示内容を示しており、２０２はアプリケーションにより表示されているウインドウである。このウインドウ２０２において、２０３は映像を表示する領域である映像ウインドウである。ここでは、クライアント端末１１１は６４０×４８０（画素）の解像度の映像データを受信している。よって、横方向２０４が６４０（画素）、縦方向２０５が４８０（画素）のサイズで表示されている。２０６はチルト制御バー、２０７はパン制御バーであり、各バーをスライドさせることによってサーバ１０１の雲台撮像部１０２の雲台のパン、チルトを遠隔制御できる。これにより、クライアント端末１１１は所望のアングルで被写体を撮影した映像を見ることができる。これらのカメラ制御用ツールバーは、制御権ボタン２０８を押すことによって、そのカメラの制御権を獲得したクライアント端末で使用可能となる。

この制御権ボタン２０８は、他のクライアント端末が制御権を取得していない状態でユーザが選択することにより有効となり、複数のクライアント端末が同時に同一のカメラを制御することができないように使用者を制限している。２０９はドラグエリアであり、このエリア２０９をマウスでドラグ操作することで、アプリケーションによる表示ウインドウ２０２や映像ウインドウ２０３のサイズを任意のサイズに変更する（リサイズ）ことが可能となる。

図２（Ｂ）は、カーソル２２０を使用したマウスのドラグ操作によってウインドウ２０２の大きさを変更した後の表示部１１４の表示内容を示している。このドラグ操作に応じて映像ウインドウ２０３は２１２で示すようにリサイズされ、横方向２１３が５１２（画素）、縦方向２１４が３８４（画素）の大きさに縮小されて表示されている。

このようなクライアント端末１１１での映像ウインドウのリサイズ操作により、サーバ１０１で送信している映像の解像度とは異なるサイズでの表示が必要となる。このため、クライアント端末では、リサンプリング処理や補間処理の負荷が発生する。このようなクライアント端末１１１の負荷を軽減するためには、受信した映像の解像度と同じサイズで表示することが有効である。このためには、サーバ１０１が、この変倍されたウインドウサイズに応じた解像度の映像データを提供する必要がある。

そこで本実施の形態１では、クライアント端末において、表示されるウインドウのサイズが変更されると、その変更された表示サイズに関する情報を、クライアント端末からサーバ１０１に送信する。これによりサーバ１０１は、その表示サイズに応じた解像度となるように映像変倍部１０３で、撮影する映像の解像度を変更し、こうして解像度が変更された映像データをクライアント端末に送信する。これによりクライアント端末における変倍処理の負荷を軽減できる。また、画像の変倍を撮影側で実行することにより、変倍に伴う画像の劣化を防止できる。

図３は、本実施の形態１に係る変倍処理を実行する際の、クライアント端末での処理を説明するフローチャートである。ここでは図２（Ｂ）に示したウインドウのリサイズが行われた場合のクライアント端末の処理を説明する。尚、この処理を実行するプログラムは、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。

ますステップＳ３０２で、サーバ１０１に接続して既定の解像度の映像データを受信する。本実施の形態１では、６４０×４８０（画素）の解像度の映像データを受信する。次にステップＳ３０３で、アプリケーションを起動して、６４０×４８０（画素）の大きさで映像ウインドウ２０３を開いて映像を表示する（図２（Ａ））。次にステップＳ３０４で、映像ウインドウのリサイズが行われたかどうかを判定し、リサイズが行われた場合はステップＳ３０５に進み、リサイズ後の映像ウインドウ２１２の表示サイズ情報を、通信Ｉ／Ｆ部１１２を介してサーバ１０１に送信する。本実施の形態１では、リサイズ後の映像ウインドウ２１２のサイズは、図２（Ｂ）より横方向５１２（画素）、縦方向３８４（画素）とする。

これによりステップＳ３０５で、サーバ１０１に対して、５１２×３８４（画素）の表示サイズ情報を送信する。これによりサーバ１０１は、その送信された表示サイズ情報に基づいて撮像サイズを６４０×４８０（画素）から５１２×３８４（画素）に変更し、その映像データをクライアント端末１１１に送信する。そしてステップＳ３０６で、クライアント端末１１１は、サーバ１０１から送信された映像ストリームの受信を６４０×４８０（画素）の映像データから５１２×３８４（画素）の映像データに切り替えて表示する。

以上説明したように本実施の形態１によれば、クライアント端末の映像ウインドウの表示サイズが６４０×４８０（画素）から５１２×３８４（画素）に変更された場合、サーバ１０１にリサイズ後の映像ウインドウの表示サイズ情報を送信する。これによりサーバ１０１は、５１２×３８４（画素）の解像度で映像をキャプチャしてクライアント端末１１１に送信することが可能になる。従って、クライアント端末での映像表示に際して、補間処理やリサンプリング処理が不要になり、クライアント端末における映像処理の負荷が低減できる。

また、クライアント端末における表示用映像ウインドウのサイズと、サーバ１０１から送信される映像データの解像度とが同じであるため、表示用ウインドウのリサイズによる画質の劣化は生じない。

本実施の形態１では、映像ウインドウのリサイズの方法として、クライアント端末におけるマウスのドラグによる方法を例に挙げたが、本発明はこれに限定されるものではない。例えば、キーボードからのウインドウサイズの数値指定によるリサイズ、スケジューリングや外部センサ等をトリガとした事前の設定条件に応じたリサイズ等、多様なリサイズ方法であっても良い。

またこの実施の形態１では、映像ウインドウサイズを縮小する場合で説明したが、本発明はこれに限定されるものでなく、映像ウインドウサイズを拡大する場合にも同様に適用できることはもちろんである。

＜実施の形態２＞
次に図４、図５を参照して本発明の実施の形態２を詳細に説明する。尚、実施の形態２における、配信システム、サーバ（ネットワークカメラ）とクライアント端末のハードウェア構成は、前述の実施の形態１の構成と同様であるため、それらの説明を省略する。

図４（Ａ）（Ｂ）は、実施の形態２に係るクライアント端末の表示部１１４に表示している画面を模式的に表した図である。ここでは、４台のサーバから配信されている４地点の映像データを同時に表示している。ここでは、映像ウインドウのリサイズについて説明する。

図４（Ａ）は、リサイズ前の表示部１１４における表示状態を示している。４０２はアプリケーションにより表示されるウインドウである。このウインドウ４０２において、４０５〜４０８のそれぞれは、サーバ１、サーバ２、サーバ３、サーバ４からの撮影映像をそれぞれ表示する映像ウインドウを示している。本実施の形態２に係るクライアント端末は、各サーバから配信された３２０×２４０（画素）の解像度の映像データを受信している。よって、各映像の横方向４０３は３２０（画素）、縦方向４０４は２４０（画素）である。ここで、このクライアント端末は、サーバ３（映像ウインドウ４０７）におけるカメラの制御権を取得しているものとする。

４０９はドラグエリアであり、このエリア４０９の枠をマウスでドラグ操作することにより、このウインドウ４０２や映像ウインドウ４０５〜４０８のサイズを任意のサイズに変更することが可能となる。

図４（Ｂ）は、マウスのドラグ操作によってウインドウ４０２のサイズを小さくした後の表示部１１４の表示内容を示している。この操作に応じて映像ウインドウ４０５〜４０８のそれぞれもリサイズ（縮小）され、横方向４１２が２００（画素）、縦方向４１３が１２０（画素）の大きさで表示されている。

前述のとおり、クライアント端末での映像ウインドウのリサイズ処理の負荷を軽減するためには、映像ウインドウのサイズに対応する解像度の映像データをサーバ１０１で生成して配信することが有効である。しかし、複数のクライアント端末が同一のサーバ１０１からの映像を表示している状態で、あるクライアント端末だけが勝手にサーバ１０１における撮影の解像度を変更すると以下の問題が生じる。即ち、他のクライアント端末が表示している映像の画質が変化したり、映像ウインドウの表示サイズが変化したりしてしまう。

そこで本実施の形態２ではこれらの問題を解決するために、映像ウインドウのリサイズに応じたサーバでの変倍処理は、そのサーバにおけるカメラ制御権を取得しているクライアント端末からの要求にのみ対応すること特徴とする。即ち、図４（Ａ）に示す映像ウインドウのリサイズが行われた場合は、制御権を取得しているサーバ３のみに対して変倍命令を送信し、その他のサーバの映像についてはクライアント端末でリサイズ処理を行う。

尚、サーバによる変倍処理により映像を表示しているウインドウ（このクライアント端末が制御権を有しているサーバからの映像）は、図４（Ｂ）の４１４のような太枠表示等によってクライアント端末に明示できる構成とする。これにより、複数の表示用ウインドウの内、サーバによる変倍処理が可能なウインドウが明確になり、クライアント端末の負荷の管理等、システム運用上の利便性を提供することが可能となる。

図５は、本発明の実施の形態２に係るカメラ制御権に応じて変倍処理を実行する際の、クライアント端末での処理を示したフローチャートであり、図４（Ｂ）に示すようなリサイズが行われた場合のクライアント端末の処理を説明する。尚、この処理を実行するプログラムは、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。

まずステップＳ５０２で、サーバ１〜４の各サーバに接続して既定の解像度の映像データを受信する。本実施の形態２では、各サーバから配信される３２０×２４０（画素）の解像度の映像データを受信する。そして、３２０×２４０（画素）の解像度の映像を表示可能な大きさの４つの領域を有する映像ウインドウ上に各サーバからの映像を表示する（図４（Ａ））。次にステップＳ５０３で、映像ウインドウのリサイズが行われたかどうかを判定し、行われた場合はステップＳ５０４に進み、いずれかのサーバ（ネットワークカメラ）の制御権を取得中であるか確認する。ここで制御権を取得しているサーバが存在している場合はステップＳ５０５に進み、その制御権を取得中のサーバ（ネットワークカメラ）、本実施の形態２では、サーバ３に対してリサイズ後の映像ウインドウの表示サイズ情報を送信する。

図４（Ｂ）では、リサイズ後の映像ウインドウのサイズは横方向２００（画素）、縦方向１００（画素）である。従って、サーバ３には、２００×１００（画素）という表示サイズ情報を送信する。サーバ３は、この表示サイズ情報に基づいて映像変倍部１０３における撮像サイズを３２０×２４０（画素）から２００×１００（画素）に変更し、その映像データをクライアント端末１１１に送信する。これによりステップＳ５０６で、サーバ３からの映像ストリームの受信を３２０×２４０（画素）の映像データから２００×１００（画素）の映像データに切り替えて表示する。

一方、ステップＳ５０４で、制御権を取得していないサーバ（ネットワークカメラ）からの映像に対しては、クライアント端末側で映像のリサイズ処理を実施して表示する。本実施の形態２では、サーバ１，２，４からの映像については、クライアント端末１１１でリサンプリング等の描画処理を実施し縮小して表示することになる。

以上説明したように本実施の形態２によれば、クライアント端末において映像ウインドウの表示サイズを変更した場合、サーバの制御権を取得しているクライアント端末のみが、そのサーバに対して映像の変倍処理を要求できる。従って、１つのサーバに対して複数のクライアント端末から変倍処理が同時に要求される状況を回避し、サーバでの変倍処理に対して優先権を与えることが可能になる。

またクライアント端末では、複数の映像ウインドウを表示している場合でも、制御権を有しているサーバからの映像に対する変倍処理を不要にできるので、クライアント端末における処理を少しでも軽減できるという効果がある。

＜実施の形態３＞
以下、図６〜図１０を参照して本発明の実施の形態３を詳細に説明する。尚、配信システム及びサーバ（ネットワークカメラ）とクライアント端末のハードウェア構成は、前述の実施の形態１で説明した構成と同様であるため、その説明を省略する。

図６（Ａ）（Ｂ）は、実施の形態３に係るクライアント端末の表示部１１４で表示される画面を模式的に表した図である。ここでは３台のサーバから配信されている３つの異なった解像度の映像データを同時に表示している。ここでは映像ウインドウのリサイズについて説明する。

図６（Ａ）は、リサイズ前の表示部１１４への表示状態を示している。６０２はサーバ１から送信される解像度３２０×２４０（画素）の映像データを表示している映像ウインドウを示す。６０３はサーバ２から送信される解像度６４０×４８０（画素）の映像データを表示している映像ウインドウを示す。そして６０４は、サーバ３から送信されてくる解像度１６０×１２０（画素）の映像データを表示している映像ウインドウを示している。前述の通り、これらの映像ウインドウは、マウスのドラグ操作等で任意の大きさにリサイズすることが可能である。

図６（Ｂ）は、マウスのドラグ操作によって各映像ウインドウをリサイズした後の表示部１１４への表示内容を示している。６０５はサーバ１から送信されてくる解像度３２０×２４０（画素）の映像を、２８０×１８０（画素）の大きさにクライアント端末でリサイズ処理して表示している映像ウインドウを示す。同様に６０６は、サーバ２から送信される解像度６４０×４８０（画素）の映像を、６００×３００（画素）の大きさにクライアント端末でリサイズ処理して表示している映像ウインドウを示す。更に６０７は、サーバ３から送信されてくる解像度１６０×１２０（画素）の映像を、２２０×１６０（画素）の大きさにクライアント端末で変倍処理して表示している映像ウインドウを示している。

本実施の形態３では、このようなクライアント端末での変倍処理で生じる負荷を低減することが目的であるが、変倍処理の負荷に対して十分余力がある処理性能の高いクライアント端末に対しては、負荷の低減を考慮する必要はない。従って、サーバでの変倍処理を実施するか否かは、クライアント端末での変倍処理の負荷の状態で判定することで、クライアント端末の性能に適応した処理を実施している。

図７は、本実施の形態３に係る映像の変倍処理におけるクライアント端末での処理を示したフローチャートであり、サーバでの変倍処理の可否をクライアント端末での処理の負荷量で決定したものである。ここでは、図６（Ｂ）に示した映像ウインドウのリサイズが行われた場合のクライアント端末の処理を説明する。尚、この処理を実行するプログラムは、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。

まずステップＳ７０２で、サーバ１〜３の各サーバに接続して既定の解像度の映像データを受信する。本実施の形態３では、サーバ１の３２０×２４０（画素）の映像データと、サーバ２の６４０×４８０（画素）の映像データと、サーバ３の１６０×１２０（画素）の映像データを受信する。そしてそれぞれの解像度に対応する大きさで映像ウインドウ上に、各サーバからの映像を表示する（図６（Ａ））。次にステップＳ７０３で、映像ウインドウのリサイズが行われたかどうかを判定する。ここでリサイズが行われた場合はステップＳ７０４に進み、クライアント端末でのリサイズ処理の負荷に余力があるか確認する。もし余力がなければステップＳ７０５に進み、リサイズしている映像データを送信しているサーバに対して、映像ウインドウの表示サイズ情報を送信する。そしてステップＳ７０６で、サーバで変倍処理された映像データを受信し、リサイズした映像ウインドウに表示する。尚、この場合も、制御権を有しているサーバだけに対してサイズ情報を送信して変倍処理を実行させることにより、他のクライアント端末への影響を少なく抑えることができる。

一方、ステップＳ７０４で、クライアント端末のリサイズ処理の負荷に余力がある場合にはステップＳ７０７に進み、負荷の低減を考慮する必要はないので、そのままクライアント端末で映像のリサイズ処理を実施して表示する。

次に、図８〜図１０を参照して、クライアント端末におけるリサイズ処理に対する負荷の判定方法を説明する。

ステップＳ７０４におけるクライアント端末の負荷の判定方法としては、映像ウインドウの大きさと、クライアント端末で変倍処理がされているか否か、によって決定されるクライアント端末の負荷量で判定することが可能である。つまり、映像ウインドウの表示サイズが大きいほど負荷が大きく、その表示サイズではクライアント端末での変倍処理が必要であれば負荷が大きい、という関係から判定基準を設定するものである。

図９は、この負荷量を数値化したテーブルの一例を示す図である。尚、このテーブルは前述のメモリ１１３ａに記憶されている。

９０１は映像ウインドウの表示サイズＤを示す。９０２はクライアント端末での変倍処理の有無を示す。９０３はクライアント端末の負荷量Ｌを示す。図９の例では、表示サイズが６４０×４８０（画素）以上の場合は標準外であるため変倍処理が「あり」となり、負荷量Ｌは「６４」となっている。また表示サイズが６４０×４８０（画素）に等しい場合は標準サイズで変倍処理が「なし」となるため、負荷量Ｌは前述の負荷量の半分の「３２」となっている。また、表示サイズが標準の６４０×４８０（画素）以下で３２０×２４０（画素）よりも大きい場合は標準以外でリサイズが「あり」となるため、負荷量Ｌは「４８」と大きくなっている。以下同様に、表示サイズに応じてリサイズの「有無」が決定され。これに応じて負荷量が設定されている。

図８は、実施の形態３に係る負荷テーブルで設定された負荷量Ｌを、クライアント端末における負荷量の判定基準としたフローチャートであり、図６（Ｂ）に示すリサイズが行われた場合の判定方法を説明する。尚、この処理を実行するプログラムは、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。

まずステップＳ８０２で、図９の負荷テーブルを参照して求めた負荷量Ｌに対して余力の有無を判定するための閾値Ｘを決定する。この閾値Ｘは、例えば、クライアント端末の処理性能によって決定される。例えば、高速のＣＰＵやグラフィックカード等を搭載したクライアント端末であれば変倍処理処理に対する性能も高いため、閾値Ｘは高く設定できる。本実施の形態３では、例えば閾値Ｘ＝５０に設定する。

次にステップＳ８０３で、リサイズ前の負荷量Ｌ１を算出する。本実施の形態３の図６（Ａ）では、３２０×２４０（画素）、６４０×４８０（画素）、１６０×１２０（画素）、の３つの大きさの映像ウインドウが表示されている。これらサイズはそれぞれサーバの既定表示サイズであるため変倍処理は不要で行っていない。従って、図９の負荷テーブルに基づき算出される負荷量Ｌ１は、８＋３２＋２＝４２となる。次にステップＳ８０４で、この負荷量Ｌ１とステップＳ８０２で設定された閾値Ｘとを比較する。ここではＸ（＝５０）＞Ｌ１（＝４２）であるため、クライアント端末の処理に余力があると判断してステップＳ８０５に進み、クライアント端末での変倍処理を実施する。

ステップＳ８０５では、変倍処理によるの負荷量Ｌ２を算出する。本実施の形態３の図６（Ｂ）では、２８０×１８０（画素）、６００×３００（画素）、２２０×１６０（画素）、の３つの大きさの映像ウインドウが変倍処理されて表示されている。これらのサイズはいずれもサーバ１０１における既定の解像度に対応していない。このためクライアント端末での変倍処理が必要となる。この場合、図９の負荷テーブルに基づいて決定される負荷量Ｌ２は、１２＋４８＋１２＝７２となる。次にステップＳ８０６で、この負荷量Ｌ２とステップＳ８０２で設定された閾値Ｘとを比較する。ここではＸ（＝５０）＜Ｌ２（＝７２）となるため、クライアント端末での変倍処理に余力がないと判断する。この場合は、各ウインドウの表示サイズ情報を、各サーバに通知して変倍要求を行う。

一方、ステップＳ８０６で、閾値Ｘよりも負荷量Ｌ２の方が小さい場合は、このクライアント端末での変倍処理に余力があると判断して、このクライアント端末による変倍処理を実行する。

尚、この図８のフローチャートでは、クライアント端末負荷の判定方法として負荷量Ｌを算出して判定する場合で説明した。しかしこれ以外の簡易な判定方法として、映像のフレームレートを使用した方法がある。

図１０は、本発明の実施の形態３の変形例に係る映像のフレームレートをクライアント端末の負荷判定基準とした処理を説明するフローチャートである。尚、この処理を実行するプログラムは、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。

図１０において、まずステップＳ１０２で、リサイズ前のフレームレート値（Ｆ１）を検出する。例えば、処理性能の高いクライアント端末がＮＴＳＣ方式の映像を受信している場合は、Ｆ１＝３０［フレーム／秒］］］となる。次にステップＳ１０３で、映像ウインドウをリサイズした後のフレームレート値（Ｆ２）を検出する。次にステップＳ１０４で、映像ウインドウのリサイズ前後のフレームレート値を比較する。ここでもしＦ１＝Ｆ２の場合はクライアント端末の処理に余力があると判断できる。

一方、ステップＳ１０４でＦ１＞Ｆ２の場合は、クライアント端末の変倍処理に対する負荷が大きくなり、映像データのデコード性能や描画性能の限界に達したために、フレームレートの低下が生じると考えられる。従って、この場合はクライアント端末の処理に余力が無いと判断して、表示サイズ情報をサーバに通知して変倍要求を行う。

以上説明したように実施の形態３によれば、クライアント端末の映像ウインドウの表示サイズを変更した際、クライアント端末の処理の負荷が高くなった場合にサーバ１０１での変倍処理を実施する。これにより、クライアント端末の処理性能に応じた適正なリサイズ処理をおこなうことが可能になる。

本実施の形態３では、クライアント端末の負荷の判定条件として、映像ウインドウのサイズに基づく負荷量Ｌやフレームレート値Ｆを例に挙げたが、本発明はこれに限定されるものではない。例えば、クライアント端末のＣＰＵ１１３の使用率が略１００％になった場合を判定条件として使用することなど、多様なクライアント端末の負荷判定方法に対しても本発明が適用できることはいうまでもない。

＜実施の形態４＞
図１１は、本発明の実施の形態４に係るクライアント端末における変倍処理を実行する処理を説明するフローチャートである。ここでは映像の品質に対して、画質を優先するか、または、動きを優先するかの２つのモードを選択できるシステムであって、図２（Ｂ）に示したウインドウのリサイズが行われた場合のクライアント端末の処理を説明する。尚、この処理を実行するプログラムや動作モードの設定状態は、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。又、この実施の形態４に係るシステム及び装置構成は前述の実施の形態１と同様であるため、その説明を省略する。

まずステップＳ１１０で、画質優先モード或は動き優先モードのいずれかが選択されて、その選択されたモードを設定する。次にステップＳ１１１に進み、ネットワーク１２１を介してサーバ１０１と接続し、既定の解像度の映像データを受信して表示する。本実施の形態４では、６４０×４８０（画素）の解像度の映像データを受信して表示するものとする（図２（Ａ））。次にステップＳ１１２に進み、図２（Ｂ）で前述したように、映像ウインドウのリサイズが行われたかどうかを判定する。ここでリサイズが行われたと判定した場合はステップＳ１１３に進み、映像ウインドウが縮小、或は拡大されたかどうかを判定する。

ここで映像ウインドウが縮小されたと判定した場合はステップＳ１１４に進み、ステップＳ１１０で設定された動作モードを識別する。ここで動き優先モードが設定されていればステップＳ１１６に進み、リサイズ後の映像ウインドウ２１２の表示サイズ情報を、通信Ｉ／Ｆ部１１２を介してサーバ１０１に送信する。本実施の形態４では、リサイズ後のウインドウサイズは図２（Ｂ）より横方向５１２（画素）、縦方向３８４（画素）とする。この場合にはステップＳ１１６で、サーバ１０１に対して、５１２×３８４（画素）の表示サイズ情報を送信する。これによりサーバ１０１は、その送信された表示サイズ情報に基づいて、撮像サイズを６４０×４８０（画素）から５１２×３８４（画素）に変更し、その映像データをクライアント端末１１１に送信する。そしてステップＳ１１７で、クライアント端末１１１は、サーバ１０１から送信された映像ストリームの受信を６４０×４８０（画素）の映像データから５１２×３８４（画素）の映像データに切り替えて表示する。

一方、ステップＳ１１４で、動作モードが画質優先モードであった場合はステップＳ１１８に進み、クライアント端末１１１で６４０×４８０（画素）のデータをリサンプリング処理によって５１２×３８４（画素）に変倍してから表示する。

またステップＳ１１３で、映像ウインドウが６４０×４８０（画素）から、例えば７００×５００（画素）に拡大した場合はステップＳ１１５に進み、設定されている動作モードを判定する。ここで動作モードが動き優先モードであった場合はステップＳ１１８に進み、クライアント端末１１１で６４０×４８０（画素）のデータを補間処理によって７００×５００（画素）に変倍してから表示する。一方、ステップＳ１１５で、動作モードが画質優先モードであった場合は、前述と同様にステップＳ１１６に進み、サーバ１０１で変倍処理した７００×５００（画素）の画像データをクライアント端末１１１に送信して表示する。

以上説明したように本実施の形態４によれば、クライアント端末の動作モードとウインドウのリサイズに応じて、変倍処理をサーバとクライアント端末のどちらで実施するかを選択して決定できる。

図１２は、本実施の形態４に係る動作モードと変倍処理の関係の一例を説明する図である。

ここでは、クライアント端末の動作モード１２０１と、映像ウインドウのリサイズ状態１２０２との４通りの条件に応じて、変倍処理の実施１２０３をサーバで行うかクライアント端末で行うかを選択できる。図１２に示す４通りの条件では、それぞれ以下のような理由に従って変倍処理が行われる。
（１）画質優先モード時にウインドウを拡大した場合は、その拡大したウインドウのサイズに応じてデータの解像度を高くして画質を確保しなければいけない。従って、サーバで変倍処理を実施する（１２１０）。
（２）画質優先モード時にウインドウを縮小した場合は、その縮小したウインドウのサイズ以上のデータの解像度があるため、リサンプリングだけで画質を確保できる。従ってクライアント端末で変倍処理を実施する（１２１１）。
（３）動き優先モード時にウインドウを拡大した場合は、回線容量の限界によって生じるフレームレートの低下を防止するためデータ量を増加させてはいけない。従って、クライアント端末で変倍処理を実施する（１２１２）。
（４）動き優先モード時にウインドウを縮小した場合は、その縮小したウインドウのサイズと同じ解像度にしてデータ量を減らしてフレームレートを確保する。従って、サーバで変倍処理を実施する（１２１３）。

尚、本実施の形態４では、動作モードの条件として画質優先と動き優先、ウインドウの拡大と縮小、の組み合わせによる例を挙げたが本発明はこれに限定されるものではない。例えば、スケジューリングや外部センサをトリガとして、クライアント端末、サーバのどちらで変倍処理を実施するかを決定しても良い。

＜実施の形態５＞
以下、図５及び図６を参照して本発明の実施の形態５について説明する。尚、この実施の形態５に係るシステム及び装置構成は、前述の実施の形態と同様であるため、その説明を省略する。

前述の実施の形態で説明した通り、一定の条件下において、クライアント端末で表示されるウインドウのサイズが変更されると、その変更された表示サイズに関する情報をクライアント端末からサーバ１０１に送信する。これによりサーバ１０１は、その表示サイズに応じた解像度となるように映像変倍部１０３で撮影する映像の解像度を変更し、こうして解像度を変更した映像データをクライアント端末に送信する。これによりクライアント端末における変倍処理の負荷を軽減できる。

一方、このようなウインドウのサイズに応じたサーバでの変倍処理により、映像データ量は変化する。もし映像データ量が増大した場合、ネットワークによっては、その回線の許容できるデータ量を超えてしまうか、或はその多くを占有してしまうなどの問題が生じる。このような問題を解決するため、ウインドウのサイズが変更された場合には、使用している回線容量や回線品質に応じて、クライアント端末とサーバのどちらで変倍処理を実施するかを選択することで、システムの環境に適応した変倍処理を行うことが可能となる。

図１３は、本実施の形態５に係るクライアント端末において、映像ウインドウの拡大が行われた場合の変倍処理を説明するフローチャートである。尚、この処理を実行するプログラムや動作モードの設定状態は、ＣＰＵ１１３のメモリ１１３ａに記憶されており、ＣＰＵ１１３の制御の下に実行される。又、この実施の形態５に係るシステム及び装置構成は前述の実施の形態１と同様であるため、その説明を省略する。ここでは回線の種類として、FTTH接続、即ち大容量回線と、PPP接続、即ち小容量回線の２つの回線を選択できるシステムの場合で説明する。

まずステップＳ１３０で、ＦＴＴＨ接続又はＰＰＰ接続を選択して設定する。次にステップＳ１３１で、ネットワーク１２１を介してサーバ１０１と接続し、既定の解像度の映像データを受信して表示する。本実施の形態５では、６４０×４８０（画素）の解像度の映像データを受信して表示する（図２（Ａ））。次にステップＳ１３２に進み、映像ウインドウの拡大が行われたかどうかを判定する。ここで拡大が行われた場合はステップＳ１３３に進み、設定されている回線種別を判定する。ここでＦＴＴＨ接続、即ち大容量回線の場合はステップＳ１３４に進み、拡大後の映像ウインドウの表示サイズ情報を、通信Ｉ／Ｆ部１１２を介してサーバ１０１に送信する。

本実施の形態５では、リサイズ後のウインドウサイズは、横方向１９２０（画素）、縦方向１０８０（画素）とする。

これによりステップＳ１３４で、サーバ１０１に対しては、１９２０×１０８０（画素）の表示サイズ情報を送信する。これによりサーバ１０１は、その送信された表示サイズ情報に基づいて、撮像サイズを６４０×４８０（画素）から１９２０×１０８０（画素）に変更し、その映像データをクライアント端末１１１に送信する。次にステップＳ１３５に進み、クライアント端末１１１は、サーバ１０１から送信された映像ストリームの受信を、６４０×４８０（画素）の映像データから１９２０×１０８０（画素）の映像データに切り替えて表示する。

一方、ステップＳ１３３で、回線種別がＰＰＰ接続、即ち小容量回線であった場合はステップＳ１３６に進み、クライアント端末１１１で６４０×４８０（画素）のデータを補間処理によって１９２０×１０２４（画素）に変倍してから表示する。

以上説明したように本実施の形態５によれば、回線の容量が小さい場合にウインドウが拡大された場合には、映像データ量を増大させないために変倍処理をクライアント端末で実施させる。これにより、回線の容量に応じた適切な変倍処理が可能となる。

尚、本実施の形態５では、クライアント端末の設定項目として回線種別を例に挙げた。しかし本発明はこれに限定されるものではない。

図１４は、クライアント端末の設定項目と変倍処理の関係の一例を説明する図である。

本実施の形態５では、回線条件１４０１に従ってクライアント端末、サーバのどちらで変倍処理を実施するかを決定した。この回線条件１４０１と同様に、以下の条件に応じて変倍処理をクライアント端末、サーバのどちらで変倍処理を実施するかを決定することが可能となる。
（１）性能条件１４０２は、クライアント端末の動作性能に関する項目例であり、クライアント端末が省エネモードの場合にはクライアント端末の負荷を抑えるため、サーバが変倍処理を実施する。
（２）機種条件１４０３は、クライアント端末の機種に関する項目例であり、クライアント端末が携帯電話の場合には処理性能が低いため、サーバが変倍処理を実施する。
（３）機能条件１４０４は、クライアント端末のアプリケーション機能に関する項目例を示す。クライアント端末が画像を録画している場合には、クライアント端末の負荷が重くなっているため、サーバが変倍処理を実施する。
（４）品質条件１４０５は、クライアント端末で表示する画像の品質に関する項目例を示す。クライアント端末で高品位の画像が必要とする場合は、映像ウインドウと同じ解像度の画像が必要であるため、サーバが変倍処理を実施する。

このような監視者が設定できる条件や、監視システムの環境条件は、これに限定されるものではない。スケジューリングや外部センサをトリガとして、クライアント端末、サーバのどちらで変倍処理を実施するかを決定するなど、多様な条件に対しても本例が適用できることはいうまでもない。監視システムの環境条件は多様であり、これらの条件に応じて変倍処理をどこで実施するかを決定してもよい。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成される文書検索システムに適用しても良いし、また、一つの機器からなる文書検索装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。上記実施形態では、図５から７、及び図９から１３のフローチャートに対応したプログラムである。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。 従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。

その他、プログラムの供給方法としては、クライアント端末コンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される。

以上説明したように本実施の形態によれば、クライアント端末でのリサイズ処理による負荷を低減できる。

クライアント端末での変倍指示による画質の劣化を防止できるという効果がある。

またサーバでの変倍処理を許可するクライアント端末を制限することで、複数のクライアント端末からの同時要求を回避できる。

また、クライアント端末でのリサイズ処理の負荷量に応じてサーバでの変倍処理を許可することで、サーバでの変倍処理による負荷を低減し、システムとしての負荷を適正に分散することが可能となる。

本発明の実施の形態１に係る映像配信システムの全体システム構成を説明するブロック図である。 本実施の形態に係るクライアント端末の表示部で表示している画面を模式的に表した図である。 本発明の実施の形態１に係るクライアント端末での処理を説明するフローチャートである。 実施の形態２に係るクライアント端末の表示部に表示している画面を模式的に表した図である。 本発明の実施の形態２に係るカメラ制御権に応じて変倍処理を実行する際の、クライアント端末での処理を示したフローチャートである。 実施の形態３に係るクライアント端末の表示部で表示している画面を模式的に表した図である。 実施の形態３に係る映像の変倍処理におけるクライアント端末での処理を示したフローチャートである。 負荷テーブルで算出された負荷量Ｌをクライアント端末の負荷判定基準としたフローチャートである。 実施の形態３に係る負荷量を数値化したテーブルの一例を示す図である。 実施の形態３の変形例では、映像のフレームレートをクライアント端末の負荷判定基準としたフローチャートである。 本発明の実施の形態４に係るクライアント端末における変倍処理を実行する処理を説明するフローチャートである。 本実施の形態４に係る動作モードと変倍処理の関係の一例を説明する図である。 本実施の形態５に係るクライアント端末において、映像ウインドウの拡大が行われた場合の変倍処理を説明するフローチャートである。 本実施の形態５に係るクライアント端末の設定項目と変倍処理の関係の一例を説明する図である。

Claims (16)

1. 映像データを配信するサーバと、サーバにより配信された映像データをクライアント端末のウインドウに表示させる映像配信システムであって、
   前記クライアント端末は、
   前記サーバから映像データを受信する受信手段と、
   前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更手段と、
   前記受信手段により受信した映像データのサイズ変更処理を、前記クライアント端末で行う余力の有無を判定する判定手段と、
   前記判定手段により余力があると判定された場合に、前記変更指示で変更されたウインドウの大きさに表示されるように、前記受信した映像データのサイズ変更処理をする第１の変更手段と、
   前記判定手段により余力がないと判定された場合に、前記変更指示に応じて変更された前記ウインドウの大きさを示す前記表示サイズ情報を前記サーバに通知する通知手段と、
   サイズ変更処理された映像データをウインドウに表示させる表示制御手段とを有し、
   前記サーバは、
   前記通知手段により通知された前記表示サイズ情報に基づいて、前記クライアント端末に配信する映像データのサイズ変更を行って前記クライアント端末に送信する第２の変更手段を有し、
   前記表示制御手段は、前記第１の変更手段、もしくは、前記第２の変更手段によりサイズ変更が行われた映像データをウインドウに表示させることを特徴とする映像配信システム。
2. 前記通知手段は、前記クライアント端末が前記サーバの制御権を有している場合に、前記表示サイズ情報を前記サーバに通知することを特徴とする請求項１に記載の映像配信システム。
3. 前記判定手段は、前記ウインドウのサイズおよび前記受信手段により受信した映像データの解像度を用いて前記サイズ変更処理の負荷を算出し、該算出の結果を閾値と比較して閾値より小さい場合に、前記クライアント端末で前記サイズ変更処理を行う余力があると判定することを特徴とする請求項１に記載の映像配信システム。
4. 前記判定手段は、前記ウインドウサイズ変更手段によりウインドウの大きさを変更する前後でのフレームレートを比較し、該比較の結果、等しい場合に、前記クライアント端末で前記サイズ変更処理を行う余力があると判定することを特徴とする請求項１に記載の映像配信システム。
5. サーバにより配信された映像データをウインドウに表示させるクライアント端末であって、
   前記サーバから映像データを受信する受信手段と、
   前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更手段と、
   前記クライアント端末の動作モードを設定する設定手段と、
   前記設定手段により設定された動作モードと、前記変更指示で変更された前記ウインドウの大きさに表示されるように映像データの解像度を変更する処理を前記クライアント端末において行うか前記サーバにおいて行うかとを対応付ける対応付け手段と、
   前記対応付け手段により、映像データの解像度を変更する処理を前記クライアント端末において行うと対応付けられた場合に、前記変更指示で変更された前記ウインドウの大きさに表示されるように前記受信した映像データの解像度を変更する変更手段と、
   前記対応付け手段により、映像データの解像度を変更する処理を前記サーバにおいて行うと対応付けられた場合に、前記変更指示で変更された前記ウインドウの大きさを示す表示サイズ情報を前記サーバに通知する通知手段と、
   解像度が変更された映像データをウインドウに表示させる表示制御手段と
   を有することを特徴とするクライアント端末。
6. 前記設定手段により、フレームレートよりも画質を優先する動作モードが設定された場合に、
   前記対応付け手段は、前記ウインドウの大きさを拡大する変更指示に対して、映像データの解像度を変更する処理を前記サーバにおいて行い、前記ウインドウの大きさを縮小する変更指示に対して、映像データの解像度を変更する処理を前記クライアント端末において行うように対応付けることを特徴とする請求項５に記載のクライアント端末。
7. 前記設定手段により、画質よりもフレームレートを優先する動作モードが設定された場合に、
   前記対応付け手段は、前記ウインドウの大きさを拡大する変更指示に対して、映像データの解像度を変更する処理を前記クライアント端末において行い、前記ウインドウの大きさを縮小する変更指示に対して、映像データの解像度を変更する処理を前記サーバにおいて行うように対応付けることを特徴とする請求項５に記載のクライアント端末。
8. 前記設定手段により、前記クライアント端末が受信した映像データを録画する動作モードが設定された場合に、前記対応付け手段は、映像データの解像度を変更する処理を前記サーバにおいて行い、
   前記設定手段により、前記クライアント端末が受信した映像データを録画する動作が設定されていない場合に、前記対応付け手段は、映像データの解像度を変更する処理を前記クライアント端末において行うように対応付けることを特徴とする請求項５に記載のクライアント端末。
9. 前記設定手段により、前記動作モードとして、前記クライアント端末が省エネモードに設定された場合に、前記対応付け手段は、映像データの解像度を変更する処理を前記サーバにおいて行い、
   前記設定手段により、前記動作モードとして、前記クライアント端末が省エネモードに設定されていない場合に、前記対応付け手段は、映像データの解像度を変更する処理を前記クライアント端末において行うように対応付けることを特徴とする請求項５に記載のクライアント端末。
10. サーバにより配信された映像データをウインドウに表示させるクライアント端末であって、
    前記サーバから映像データを受信する受信手段と、
    前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更手段と、
    前記受信手段により受信した映像データのサイズ変更処理を、前記クライアント端末で行う余力の有無を判定する判定手段と、
    前記判定手段により余力があると判定された場合に、前記変更指示で変更されたウインドウの大きさに表示されるように、前記受信した映像データのサイズ変更処理をする変更手段と、
    前記判定手段により余力がないと判定された場合に、前記変更指示に応じて変更された前記ウインドウの大きさを示す前記表示サイズ情報を前記サーバに通知する通知手段と、
    サイズ変更処理された映像データをウインドウに表示させる表示制御手段と
    を有するクライアント端末。
11. 前記通知手段は、前記クライアント端末が前記サーバの制御権を有している場合に、前記表示サイズ情報を前記サーバに通知することを特徴とする請求項１０に記載のクライアント端末。
12. 前記判定手段は、前記ウインドウのサイズおよび前記受信手段により受信した映像データの解像度を用いて前記サイズ変更処理の負荷を算出し、該算出の結果を閾値と比較して閾値より小さい場合に、前記クライアント端末で前記サイズ変更処理を行う余力があると判定することを特徴とする請求項１０に記載のクライアント端末。
13. 前記判定手段は、前記ウインドウサイズ変更手段によりウインドウの大きさを変更する前後でのフレームレートを比較し、該比較の結果、等しい場合に、前記クライアント端末で前記サイズ変更処理を行う余力があると判定することを特徴とする請求項１０に記載のクライアント端末。
14. 前記サーバと前記クライアント端末の通信回線であり、第１の容量は第２の容量よりも大きい、前記第１または前記第２の容量を有する通信回線を設定する回線設定手段をさらに有し、
    前記判定手段は、前記回線設定手段により前記第１の容量を有する通信回線が設定された場合、前記ウインドウの大きさを拡大する変更指示に対して、前記クライアント端末で前記サイズ変更処理を行う余力がないと判定し、
    前記回線設定手段により前記第２の容量を有する通信回線が設定された場合、前記ウインドウの大きさを拡大する変更指示に対して、前記クライアント端末で前記サイズ変更処理を行う余力があると判定する、
    ことを特徴とする請求項１０に記載のクライアント端末。
15. サーバにより配信された映像データをウインドウに表示させるクライアント端末の制御方法であって、
    前記サーバから映像データを受信する受信工程と、
    前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更工程と、
    前記受信工程において受信した映像データのサイズ変更処理を、前記クライアント端末で行う余力の有無を判定する判定工程と、
    前記判定工程において余力があると判定された場合に、前記変更指示で変更されたウインドウの大きさに表示されるように、前記受信した映像データのサイズ変更処理をする変更工程と、
    前記判定工程において余力がないと判定された場合に、前記変更指示に応じて変更された前記ウインドウの大きさを示す前記表示サイズ情報を前記サーバに通知する通知工程と、
    サイズ変更処理された映像データをウインドウに表示させる表示制御工程と
    を有するクライアント端末の制御方法。
16. サーバにより配信された映像データをウインドウに表示させるクライアント端末の制御方法であって、
    前記サーバから映像データを受信する受信工程と、
    前記ウインドウの大きさの変更指示を受け付け、ウインドウの大きさを変更するウインドウサイズ変更工程と、
    前記クライアント端末の動作モードを設定する設定工程と、
    前記設定工程において設定された動作モードと、前記変更指示で変更された前記ウインドウの大きさに表示されるように映像データの解像度を変更する処理を前記クライアント端末において行うか前記サーバにおいて行うかとを対応付ける対応付け工程と、
    前記対応付け工程において、映像データの解像度を変更する処理を前記クライアント端末において行うと対応付けられた場合に、前記変更指示で変更された前記ウインドウの大きさに表示されるように前記受信した映像データの解像度を変更する変更工程と、
    前記対応付け工程において、映像データの解像度を変更する処理を前記サーバにおいて行うと対応付けられた場合に、前記変更指示で変更された前記ウインドウの大きさを示す表示サイズ情報を前記サーバに通知する通知工程と、
    解像度が変更された映像データをウインドウに表示させる表示制御工程と
    を有することを特徴とするクライアント端末の制御方法。

Images