JP2007124354A - サーバ及びその制御方法並びに映像配信システム - Google Patents

Abstract

【課題】 サーバでの変倍処理による負荷を軽減すること。
【解決手段】 ネットワーク２０２を介して複数のクライアントのウインドウに表示される映像データを配送するサーバ２０１は、前記複数のクライアントの少なくとも１つから送信された要求に応じて、前記映像データの解像度を変更する映像変倍部１０５と、前記複数のクライアントの優先度を設定する優先度設定部１０６と、優先度設定部１０６で設定された優先度に基づいて、優先度の高いクライアントから送信された要求を優先的に処理するように、映像変倍部１０５を制御する映像変倍制御部１０４と、前記優先的な処理が行われたクライアントに映像変倍部１０５で解像度が変更された映像データを送信する通信部１０２と、を備える。
【選択図】 図１

Description

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

近年、ネットワーク技術の発達に伴い、ネットワークを介してネットワークカメラ等のサーバから映像や音声を配信し、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などのクライアントで閲覧する映像配信システムが普及してきている。このような映像配信システムは、複数の遠隔地に設置されたカメラからの映像をリアルタイムで表示できるという特徴を生かし、特に特定の場所の監視を目的として使用されている。

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

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

サーバから配信されている映像データをクライアントで表示している際、クライアントでウインドウが任意の大きさに変更されると、クライアントで描画サイズを変更するためのリサイズ処理が行われる。例えば、サーバから配信された６４０×４８０（画素）の映像を表示している場合、そのウインドウ枠をドラッグして５００×３００（画素）のウインドウのサイズに縮小する。この場合、クライアントでは、６４０×４８０（画素）から５００×３００（画素）への解像度の変換処理（変倍処理）が行われる。クライアントにおける隣接画素に基づく補間処理によるウインドウの拡大表示では、ウインドウのサイズに応じた最適な画質を得ることができない。例えば、１６０×１２０（画素）の映像データを表示しているウインドウを６４０×４８０（画素）に拡大した場合、ウインドウのリサイズ前のデータを縦横４倍に引き伸ばして拡大表示しているため画質の劣化が生じてしまう。

また多数のクライアントがサーバに接続されている場合、映像データの解像度の変更処理が接続されている多数のクライアントで行われると、サーバでの負荷の増大が顕著になり、サーバの処理能力を超えてしまう。

本発明は、上記の問題点に鑑みてなされたものであり、サーバでの変倍処理による負荷を軽減することを目的とする。

本発明の第１の側面は、ネットワークを介して複数のクライアントにおいて表示される映像データを配送するサーバに係り、前記複数のクライアントの少なくとも１つから送信された要求に応じて、前記映像データの解像度を変更する映像変倍部と、前記複数のクライアントの優先度を設定する優先度設定部と、前記優先度設定部で設定された優先度に基づいて、優先度の高いクライアントから送信された要求を優先的に処理するように、前記映像変倍部を制御する映像変倍制御部と、前記優先的な処理が行われたクライアントに前記映像変倍部で解像度が変更された映像データを送信する通信部と、を備えることを特徴とする。

本発明の第２の側面は、映像配信システムに係り、上記のサーバと、前記ネットワークに通信可能に接続された複数のクライアントと、を備えることを特徴とする。また、前記複数のクライアントの各々は、前記サーバから受信した映像データをウインドウに表示する画像表示部と、前記ウインドウのサイズの変更を指示するための画像サイズ操作部と、前記画像サイズ操作部からの指示に応じて前記ウインドウのサイズを変更するように前記画像表示部を制御する画像サイズ制御部と、を備えることを特徴とする。

本発明の第３の側面は、ネットワークを介して複数のクライアントのウインドウに表示される映像データを配送するサーバの制御方法に係り、前記複数のクライアントのうち、設定された優先度に基づいて、優先度の高いクライアントから送信された映像データの解像度の変更要求を優先的に処理する工程と、前記優先的に処理したクライアントに前記要求に応じて解像度が変更された映像データを送信する工程と、を含むことを特徴とする。

本発明によれば、サーバでの変倍処理による負荷を軽減することができる。

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

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

サーバ２０１は、具体的には、被写体を撮影しその映像データを配信するためのネットワークカメラを具備し、そのネットワークカメラで撮影した映像データをネットワーク２０２を介して配送している。クライアント２０３〜２０６は、具体的には、サーバ２０１から送信された映像データを受信して表示するコンピュータである。これらサーバ２０１とクライアント２０３〜２０６は、ＬＡＮやインターネット等のネットワーク２０２に接続されている。クライアント２０３〜２０６は、ネットワーク２０２を介してサーバ２０１から配送される映像データを受信することができる。また、ネットワーク２０２にサーバ２０７などの複数のサーバを接続することによって、複数の遠隔地の映像データをクライアント２０３〜２０６でマルチ画面等にして同時表示することが可能となる。

次に、図１を参照して本実施形態に係るサーバ２０１の動作について説明する。

図１は、ネットワークカメラとして構成されるサーバ２０１の詳細な構成を示す図である。サーバ２０１は、撮像部１０１、通信Ｉ／Ｆ部１０２、ＣＰＵ１０３、映像変倍制御部１０４、映像変倍部１０５、優先度設定部１０６、映像圧縮部１０７を具備している。撮像部１０１は、図２のクライアント２０３〜２０６から操作することができる。クライアント２０３〜２０６から出された制御命令は、ネットワーク２０２からサーバ２０１内の通信Ｉ／Ｆ部１０２を通じ、ＣＰＵ１０３に出力送信される。撮像部１０１は、クライアント２０３〜２０６からＣＰＵ１０３の制御命令に従って動作する。これによりクライアントの所望するアングルで撮影することができる。映像変倍制御部１０４は、映像変倍部１０５の制御を行う。映像変倍部１０５は撮像部１０１で得られた映像データを撮像し、事前に設定された解像度でデジタル化する。すなわち、本実施の形態の変倍とは、映像データの解像度（サイズ）を変更する処理を指す。本実施形態では、クライアント２０３〜２０６に提供する映像の既定解像度を６４０×４８０（画素）、３２０×２４０（画素）の２種類とする。

この解像度はクライアント２０３〜２０６からの命令（変倍要求）で変更可能であり、これらの変更命令はＣＰＵ１０３を介して映像変倍制御部１０４で受信される。映像変倍制御部１０４は、クライアント２０３〜２０６からの変倍要求を受信して優先度設定部１０６を参照し、優先度の高いクライアントから送信された変倍要求を優先的に処理するように映像変倍部１０５を制御する。優先度設定部１０６は、特に複数のクライアントからの変倍要求を受信した場合に映像変倍を許可する優先度を設定する。具体的な手法としては、例えば、優先度設定部１０６は、図３に示す優先度テーブル３００を用いる。図３の優先度テーブル３００には、各クライアントを識別するための識別子としてのシリアル番号（クライアントＮｏ．）と、このシリアル番号に関連付けられた優先度とが関連付けて記憶されている。ここでは、各クライアントの優先度の値が小さいほど、高い優先度を持つものとするが、本実施形態はこれに限定されない。図３では、各クライアントの優先度を１〜１０の１０段階で例示的に示している。この場合、優先度が１０であるクライアントＮｏ．Ｎのクライアントの優先度が最も高く、優先度が１であるクライアントＮｏ．３０３のクライアントの優先度が最も低い。優先度が高く設定されるクライアントとしては、管理者クライアントや実際にサーバを制御することが可能な制御権を持つクライアントなどが挙げられる。なお、本実施形態では、各クライアントの優先度を１０段階で表したが、これに限定されず、所定数の段階で適宜設定することができる。
映像変倍部１０５で変倍処理した映像データは、映像圧縮部１０７に送信される。映像圧縮部１０７は、映像変倍部１０５で変倍処理した映像データをＪＰＥＧフォーマット等で圧縮する。ＣＰＵ１０３は、映像圧縮部１０７で圧縮された映像データをマルチストリーム化する。通信Ｉ／Ｆ部１０２は、これらの映像データをネットワーク２０２に接続されたクライアント２０３〜２０６に向けて配信する。なお、映像圧縮部１０７における圧縮方式はＪＰＥＧに限られず、ＢＭＰ、ＧＩＦ、ＰＮＧ、ＴＩＦＦ等の各種圧縮方式を用いることができる。
次に、本実施形態のクライアント２０３の動作について詳細を述べる。

クライアント２０３は、通信Ｉ／Ｆ部２０８、ＣＰＵ２０９、画像表示部２１０、画像サイズ操作部２１１、画像サイズ制御部２１２を備えている。画像サイズ操作部２１１は、マウスやキーボード等の入力装置であり、アプリケーションの制御やサーバ２０１への制御命令の送信等に使用する。サーバ２０１から送信された映像データは、通信Ｉ／Ｆ部２０８で受信されＣＰＵ２０９に送信される。ＣＰＵ２０９は、この配信された映像データを画像表示部２１０に表示する。クライアント２０４〜２０６もクライアント２０３と同様の構成となっている。

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

図４（Ａ）は、リサイズ前の画像表示装置上の表示内容を示す図である。４０１は画像表示装置である。４０２は画像表示装置で実行されているアプリケーションにより表示されているアプリケーションパネルである。アプリケーションパネル４０２内に表示されているウインドウ４０３は、映像を表示する領域を表している。本実施形態では、クライアント２０３〜２０６は、６４０×４８０（画素）の解像度の映像データを受信しているとする。よって、画像表示装置４０１上では、横方向Ｘが６４０（画素）、縦方向Ｙが４８０（画素）のサイズで表示されている。４０４はドラッグエリアであり、このエリア４０４を図４（Ｂ）に示すカーソル４０５を用いてドラッグ操作することによって、アプリケーションパネル４０２及びウインドウ４０３のサイズを任意のサイズに変更する（リサイズする）ことが可能となる。例えば、ウインドウ４０３の表示サイズを横方向Ｘが５１２（画素）、縦方向Ｙが３８４（画素）で表示させたい場合を例に挙げる。この場合、図４（Ｂ）に示すようにカーソル４０５を用いて５１２×３８４（画素）の画像表示サイズとなるようにドラッグエリア４０４を操作すればよい。そして、画像サイズ制御部２１２は、ＣＰＵ２０９を介して通信Ｉ／Ｆ部２０８から５１２×３８４（画素）の表示サイズ情報を変倍要求としてサーバ２０１に送信する。

サーバ２０１は、クライアントから変倍要求を受信すると、リサイズした映像データをクライアントに送信する。クライアントは、サーバ２０１から変倍処理された映像データを受信するとクライアントにおける映像データの変倍処理を中断する。このようにクライアントでの変倍処理を中断して、サーバが変倍処理を行うことによって、クライアントでの負荷を軽減することができる。逆に、サーバでの変倍処理が中断された場合には、クライアントが変倍処理を行うことになる。

図５は、本実施形態に係る変倍処理を実行する際の、サーバでの処理を説明するフローチャートである。

ステップＳ５０１では、サーバ２０１は、ネットワーク２０２を介してサーバ２０１に接続されている各クライアント２０３〜２０６に既定の解像度の映像データを配信する。

ステップＳ５０２では、サーバ２０１は、クライアントから送信された変倍要求を受信したか否かを判断する。変倍要求は、クライアントでクライアントウィンドウ４０３がリサイズされると、サーバ２０１に送信される。

ステップＳ５０３では、サーバ２０１は、ステップＳ５０２で変倍要求を送信したクライアントとは異なるクライアント（以下「他のクライアント」という）から送信された変倍要求を実行しているか否かを判断する。サーバ２０１は、他のクライアントから受信したリサイズ要求を実行していない場合には（ステップＳ５０３で「ＮＯ」）、ステップＳ５０４の処理を行う。サーバ２０１は、他のクライアントから受信したリサイズ要求を実行している場合は（ステップＳ５０３で「ＹＥＳ」）、ステップＳ５０６の処理を行う。

ステップＳ５０４では、サーバ２０１は、ステップＳ５０２で変倍要求を送信したクライアントから変倍要求を受け付けて、映像変倍部１０５で映像データの変倍処理を行う。その後、サーバ２０１は、映像圧縮部１０７で映像圧縮を実行し、クライアントに送信する映像データを生成する。

ステップＳ５０５では、サーバ２０１は、ステップＳ５０４で生成した映像データをＣＰＵ１０３及び通信Ｉ／Ｆ部１０２を介して変倍要求の送信元のクライアントに送信し、変倍処理を終了する。

ステップＳ５０６では、サーバ２０１内の映像変倍制御部１０４は、優先度設定部１０６に保持されている優先度テーブル３００を参照する。そして、ステップＳ５０２で受信した変倍要求の送信元のクライアントが現在変倍要求を実行しているクライアントよりも優先度が高いか否かを判断する。ステップＳ５０２で受信した変倍要求の送信元のクライアントが現在変倍要求を実行しているクライアントよりも優先度が高い場合には（ステップＳ５０６で「ＹＥＳ」）、ステップＳ５０７の処理を行う。逆に、変倍要求を実行しているクライアントがステップＳ５０２で受信した変倍要求の送信元のクライアントよりも優先度が高い場合には、ステップＳ５０２で受信した変倍要求の送信元のクライアントが最も優先度が低くなる。この場合、サーバ２０１は、ステップＳ５０８の処理を行う。

ステップＳ５０７では、サーバ２０１は、現在変倍処理を要求しているクライアントの中で最も優先度の低いクライアントへの変倍要求の許可を破棄する。そして、変倍要求の許可を破棄した旨をそのクライアントに通知する。サーバ２０１は、ステップＳ５０７の処理の後、ステップＳ５０４、ステップＳ５０５の順で処理を実行する。

ステップＳ５０８では、サーバ２０１は、ステップＳ５０２で受信した変倍要求を破棄し、変倍要求の送信元のクライアントに通知する。例えば、図３の優先度テーブル３００に示すように優先度が設定されている場合には、サーバ２０１は、クライアント３０１に対して変倍要求を許可している間にクライアント３０５から変倍要求を受信したとする。この場合、サーバ２０１は、優先度テーブル３００を参照して、クライアント３０１とクライアント３０５との優先度を比較する。そして、サーバ２０１は、優先度の低いクライアント３０１の変倍の許可を破棄する。サーバ２０１は、変倍の許可を破棄した旨をクライアント３０１へ通知した後、クライアント３０５の変倍要求を許可して、映像変倍処理を行う。そして、サーバ２０１は、映像圧縮処理を実行してクライアント３０５が所望する画像サイズに映像変倍された映像データを生成する。サーバ２０１は、このようにして生成した映像データをクライアント３０５に送信する。クライアントは、サーバ２０１から映像変倍された映像データを受信すると、映像ストリームの受信を既定の解像度である６４０×４８０（画素）の映像データから、受信した映像データに切り替えて表示する。

以上で述べたように、サーバ２０１が複数のクライアントに映像データを配信している途中で変倍要求をクライアントから受信した場合、優先度設定部１０６で設定されているクライアントの優先度に基づいて処理を行う。具体的には、優先度の高いクライアントからの映像変倍処理と映像圧縮を行い、画像サイズを変更する許可をクライアントに与え、映像変倍された映像データをクライアントに送信する。これにより、クライアントでの映像表示の際には、補間処理やリサンプリング処理が不要になり、より優先度の高いクライアントでの負荷を軽減することができる。本実施形態では、ウインドウのリサイズの方法として、マウスを用いたドラッグ操作による方法を例に挙げたが、これに限定されない。例えば、キーボードからのウインドウのサイズの数値指定によるリサイズ、スケジューリングや外部センサ等をトリガとした事前の設定条件に応じたリサイズ等、多様なリサイズ方法を本実施形態を適用することができる。

[第２の実施形態]
次に、図３、図６、図７を参照して本発明の好適な第２の実施形態を詳細に説明する。なお、第２の実施形態における全体構成は、第１の実施の形態に係る図１、図２に示す構成と同様であるため、同様の個所についての説明を省略する。本実施形態では、全てのクライアントからの変倍要求を満たすことができない場合におけるサーバ２０１の処理について説明する。このような場合としては、例えば、サーバ２０１から多数のクライアントに映像データを配信していたり、複数のクライアントで頻繁にウインドウのリサイズが行なわれていたり等の理由でサーバ２０１の負荷が増大する場合が挙げられる。

サーバ２０１における映像データの変倍の処理能力には限界がある。従って、サーバ２０１が多数のクライアントに変倍要求を許可している場合、あるクライアントでウインドウのリサイズが行われても、サーバ２０１の負荷が大き過ぎて、この変倍要求を受け付けられない場合がある。一般的に、画像サイズが大きいほど変倍処理によるサーバの負荷が大きくなる。よって、大きな画像サイズの変倍要求を許可するクライアント数が多くなるほど、同時に変倍要求を許可できるクライアント数が少なくなる。逆に、大きな画像サイズの変倍要求を許可するクライアント数が少なくなるほど、同時に変倍要求を許可することができるクライアント数が多くなる。

この場合、優先度の高いクライアントへの映像データの配信が可能になるまで、優先度の低いクライアントからの変倍の許可を破棄することによって、優先度の高いクライアントからのウインドウに表示する映像データの変倍要求を許可することが可能となる。そして、優先度の高いクライアントが所望する映像変倍処理を行い、映像圧縮処理を実行した上で、優先度の高いクライアントに映像変倍された映像データを送信することができる。この場合におけるサーバ２０１の処理の流れについてフローチャートを用いて説明する。

図７は、第２の実施形態に係る変倍処理を実行する際の、サーバでの処理を説明するフローチャートである。

ステップＳ７０１では、サーバ２０１は、あるクライアントからリサイズ要求を受信する。

ステップＳ７０２では、サーバ２０１は、サーバ２０１自身の負荷を考慮した上で、ステップＳ７０１で受信したリサイズ要求の受け付けが可能か否かを映像変倍制御部１０４で判断する。ステップＳ７０２で変倍要求の受け付けを判断する具体的な手法としては、例えば、サーバ２０１の負荷を考慮し、画像サイズと変倍要求を許可するクライアント数との関係に基づいて変倍要求を許可するかどうかを判断する手法がある。例えば、変倍予定の画像の解像度（サイズ）とその解像度に変倍する要求を許可するクライアント数との関係が図６に示すように決められているとする。サーバ２０１は、変倍要求を許可しているクライアント数が、図６で決められたクライアント数以下であるかどうかを判定した上で、映像変倍制御部１０４が変倍要求を受け付けるか否かを判断する。図６に示す例では、ＶＧＡ（画像サイズが６４０×４８０（画素））の変倍要求を許可するクライアント数が２の場合には、ＱＶＧＡ（画像サイズが３２０×２４０（画素））の変倍要求を許可することができない。ＶＧＡへの変倍要求を許可するクライアントが１である場合には、同時にＱＶＧＡへの変倍要求を許可するクライアント数は最大で４となる。また、ＶＧＡへの変倍要求を許可するクライアント数が０の場合には、ＱＶＧＡへの変倍要求を許可するクライアント数は最大で８となる。上記のような手法で変倍要求の受け付けが可能か否かを判断した結果、変倍要求の受け付けができない場合を説明する。この場合、サーバ２０１は、ステップＳ７０１で受信した変倍要求の発信元のクライアントよりも優先度の低いクライアントがサーバ２０１に接続されているか否かについて、優先度設定部１０６に保持されている優先度テーブル３００を参照して判断する。

ステップＳ７０３では、サーバ２０１は、サーバ２０１から映像データが配信されているクライアントの中で、ステップＳ７０１で受信した変倍要求の送信元のクライアントよりも優先度の低いクライアントの変倍の要求を許可を破棄した場合の処理を行う。この場合、サーバ２０１は、ステップＳ７０１で受信した変倍要求の受け付けが可能か否かを判断する。上記変倍要求の受け付けが可能であれば（ステップＳ７０３で「ＹＥＳ」）、ステップＳ７０４の処理を行い、可能でなければ（ステップＳ７０３で「ＮＯ」）、ステップＳ７０７の処理を行う。

ステップＳ７０４では、サーバ２０１は、サーバ２０１に接続されている中で最も優先度の低いクライアントからのリサイズ要求の許可を破棄し、サーバ２０１の負荷を軽減する。

ステップＳ７０５では、サーバ２０１は、ステップＳ７０１で受信したリサイズ要求を受け付け、映像変倍処理を行い、映像データを生成する。

ステップＳ７０６では、サーバ２０１は、ステップＳ７０５で生成した映像データを変倍要求の送信元のクライアントに送信する。クライアントは映像変倍された映像データを受信すると、映像ストリームの受信を既定の解像度である６４０×４８０（画素）の映像データからクライアントが送信した表示サイズ情報のサイズの映像データに切り替えて表示する。

ステップＳ７０７では、サーバ２０１は、ステップＳ７０３において、ステップＳ７０１で受信した変倍要求を受け付けることができないと判断した場合の処理を行う。すなわち、ステップＳ７０１で受信した変倍要求の発信元のクライアントよりも優先度の低いクライアントに対する変倍の許可を破棄しても変倍要求を受け付けることができないと判断した場合の処理を行う。具体的には、サーバ２０１は、ステップＳ７０１で受信した変倍要求を破棄し、変倍要求の送信元のクライアントに通知する。ステップＳ７０２において、ステップＳ７０１で受信した変倍要求を受け付けることが可能であれば、サーバ２０１は、ステップＳ７０５、ステップＳ７０６の順にステップを実行する。

例えば、サーバ２０１内の優先度設定部１０６に図３の優先度テーブル３００が設定されているとする。クライアント３０１及びクライアント３０２がＶＧＡの画像サイズでサーバ２０１から変倍要求を許可されている状態で、クライアント３０３でＶＧＡの画像サイズで受信している最中にウインドウのリサイズが行われる。これに応じて、クライアント３０３からの変倍要求をサーバ２０１が受信した場合（ステップＳ７０１の処理に対応）、クライアント３０３からの変倍要求を受け付けることが可能かどうかを判断する（ステップＳ７０２に対応）。この場合、図６の関係を考慮すると、既にＶＧＡのリサイズがクライアント３０１及びクライアント３０２で行なわれている。そのため、このままではクライアント３０３からの変倍要求を受け付けることができない。次に、図３の優先度テーブル３００を参照すると、クライアント３０３の優先度は１である。クライアント３０１及びクライアント３０２の中でクライアント３０３よりも優先度の低いクライアントが存在するか否か調べると、クライアント３０１とクライアント３０２が該当する。クライアント３０１とクライアント３０２の中で優先度が低いのはクライアント３０２である。図６の関係よりＶＧＡの変倍処理の許可することができるクライアント数は最大２である。このため、クライアント３０２に対する変倍処理の許可を破棄すれば、クライアント３０１のリサイズ要求を許可することができる。よって、映像変倍制御部１０４は、サーバ２０１がクライアント３０１の変倍処理の許可を破棄すれば、クライアント３０３の要求に応じた変倍処理を実行する負荷の余裕があると判断する（ステップＳ７０３の処理に対応）。そして、クライアント３０３よりも優先度の低いクライアント３０２の変倍の許可を破棄する（ステップＳ７０４の処理に対応）。映像変倍部１０５はクライアント３０３の要求に応じた映像変倍処理を行い、映像圧縮部１０７でクライアント３０３に送信する映像データを生成する（ステップＳ７０５の処理に対応）。上記で生成した映像データをクライアント３０３に送信し（ステップＳ７０６の処理に対応）、クライアント３０３は映像変倍された映像データを受信する。そして、映像ストリームの受信を既定解像度である６４０×４８０（画素）の映像データから、クライアント３０３が送信した表示サイズ情報のサイズの映像データに切り替えて表示する。

次に、クライアント３０１がＶＧＡの画像サイズで変倍要求が許可され、クライアント３０３、クライアント３０４、クライアント３０５、クライアント３０６でＱＶＧＡの画像サイズで変倍要求が許可されている場合を例に挙げる。この場合、クライアント３０２からの変倍要求を受信したときに（ステップＳ７０１の処理に対応）、既にＶＧＡの画像サイズへの変倍要求が許可されているクライアントが１、ＱＶＧＡの画像サイズへの変倍要求が許可されているクライアントが４となる。従って、図６の関係よりクライアント３０２からの変倍要求を受け付けることができないと判断する（ステップＳ７０２の処理に対応）。次に、図３の優先度テーブル３００を参照する。クライアント３０２よりも優先度が低いクライアント３０４、クライアント３０６の変倍処理の要求の許可を破棄しても、図６の関係よりクライアント３０２の変倍要求を許可することができない（ステップＳ７０３の処理に対応）。この場合は、クライアント３０２からの変倍要求を破棄し、上記をクライアント３０２に通知する（ステップＳ７０７の処理に対応）。

本実施形態で述べた図６の関係は代表値であり、クライアントの要求によってはこれらの値の中間値で処理が行なわれる。

以上に述べたように、サーバ２０１の負荷が多く、全てのクライアントからの変倍要求を満たすことができない場合、優先度の低いクライアントからの変倍要求の許可を破棄する。そして、優先度の高いクライアントからの映像変倍処理を実行することにより、優先度の高いクライアントからのウインドウの変倍要求を実行することが可能になる。

[第３の実施形態]
次に、図３を参照して本発明の好適な第３の実施形態を詳細に説明する。なお、第３の実施形態における全体構成は、第１の実施の形態に係る図１、図２に示す構成と同様であるため、同様の個所についての説明を省略する。

優先度の低いクライアントからの変倍要求に対しては、変倍要求を受け付けることができない場合が少なくない。この場合には、既に映像変倍処理を行ってクライアントに配信している映像データの中からその変倍要求に最も近い画像サイズの映像データを検出する。そして、その映像データをリサイズ要求の送信元のクライアントに送信することによって、可能な限りクライアントからの変倍の要求に対応する手法について説明する。

サーバ２０１は、あるクライアントからの変倍要求が受信されたときに、変倍要求の受け付けが可能であるか否かどうかを判断する。リサイズ要求を受け付けることができない場合は、既に映像変倍処理を行っている映像データの中から、変倍要求の画像サイズと最も近い画像サイズの映像データを検出し、上記で検出した映像データを変倍要求の送信元に送信する。

例えば、サーバ２０１内の優先度設定部１０６に図３の優先度テーブル３００が設定されているとする。この場合、クライアント３０１、クライアント３０２、クライアント３０３、クライアント３０５がサーバ２０１から映像変倍処理された映像データの配信を受けている途中で、クライアント３０４のユーザがウインドウのリサイズを行ったとする。このとき、既に変倍要求が許可されている映像データの中でクライアント３０１に配送している画像サイズがクライアント３０４から受信した変倍要求の画像サイズに最も近かったとする。また、クライアント３０４がＶＧＡの画像サイズで映像データの配信を受けている途中でリサイズを実行しようとしたときに、クライアント３０１はＶＧＡの画像サイズで変倍要求を許可されているとする。さらに、クライアント３０２、クライアント３０３、クライアント３０５はそれぞれＱＶＧＡの画像サイズでリサイズ要求を許可されているものとする。

クライアント３０４からの変倍要求をサーバ２０１が受信したときに、サーバ２０１は、クライアント３０４から受信したリサイズ要求の受け付けが可能であるかについて判断する。このとき既に、クライアント３０１はＶＧＡの画像サイズで変倍要求を許可され、クライアント３０２、クライアント３０３、クライアント３０５はＱＶＧＡの画像サイズで変倍要求を許可されている。前記４つのクライアントと比較するとクライアント３０４の優先度が最も低い。このため、このままではクライアント３０４からの変倍要求を受け付けることはできない。そこで、映像変倍処理を行っている映像データの中で、クライアント３０４からのサーバ２０１要求の画像サイズと最も近い映像データを検出する。この場合、クライアント３０４が要求した解像度に最も近い、クライアント３０１に配信中の映像データが検出されることになる。そして、上記で検出されたクライアント３０１に配信中の映像データをクライアント３０４にも送信する。具体的には、クライアント３０４のユーザが６４０×４８０（画素）の画像サイズから５００×３７５（画素）に変倍処理したときを例に挙げる。そして、クライアント３０４と最も画像サイズが近いクライアントであるクライアント３０１の画像サイズが５１２×３８４（画素）であったとする。この場合、クライアント３０１に配信している５１２×３８４（画素）に変倍された映像データをクライアント３０４にも送信する。

以上に述べたように、クライアントからの変倍要求を受け付けることができない場合には、既にサーバ２０１が配信している映像データの中から変倍要求の画像サイズに最も近い画像サイズの映像データを検出する。そして、映像データを変倍要求の送信元のクライアントに送信することによって、できる限り多くのクライアントからの変倍要求を満たすことができる。

本発明の好適な実施の形態に係るサーバの構成を示す図である。 本発明の好適な実施の形態に係る映像配信システムの全体システム構成を説明するブロック図である。 本発明の好適な実施の形態に係る優先度設定部が有する優先度テーブルの一例を示す図である。 本発明の好適な実施の形態に係る画像表示部で表示する画面を模式的に表した図である。 本発明の好適な第１の実施形態に係るサーバでの処理を示すフローチャートである。 画像サイズと変倍要求を許可するクライアント数との関係を示す図である。 本発明の好適な第２の実施形態に係るサーバの処理を示すフローチャートである。

符号の説明

１０２ 通信Ｉ／Ｆ
１０４ 映像変倍制御部
１０５ 映像変倍部と、
１０６ 優先度設定部
２０１ サーバ
２０２ ネットワーク

Claims (12)

1. ネットワークを介して複数のクライアントにおいて表示される映像データを配送するサーバであって、
   前記複数のクライアントの少なくとも１つから送信された要求に応じて、前記映像データの解像度を変更する映像変倍部と、
   前記複数のクライアントの優先度を設定する優先度設定部と、
   前記優先度設定部で設定された優先度に基づいて、優先度の高いクライアントから送信された要求を優先的に処理するように、前記映像変倍部を制御する映像変倍制御部と、
   前記優先的な処理が行われたクライアントに前記映像変倍部で解像度が変更された映像データを送信する通信部と、
   を備えることを特徴とするサーバ。
2. 前記映像変倍制御部は、前記映像変倍部で解像度の変更処理が実行されていない場合には、前記クライアントから送信された要求に対応する処理を許可し、解像度を変更するように前記映像変倍部を制御することを特徴とする請求項１に記載のサーバ。
3. 前記映像変倍制御部は、前記映像変倍部で前記映像データの解像度の変更処理が実行されている場合には、前記送信された要求の送信元のクライアントの優先度が、前記処理が実行されているクライアントの優先度よりも高いか否かを判断し、前記判断結果に基づいて優先的に処理を実行するクライアントを決定することを特徴とする請求項２に記載のサーバ。
4. 前記映像変倍制御部は、前記送信元のクライアントの優先度が、前記処理が実行されているクライアントの優先度よりも高いと判断した場合には、前記処理が実行されているクライアントのうち、最も優先度の低いクライアントの要求の許可を破棄し、前記破棄したクライアントに要求の許可を破棄したことを通知することを特徴とする請求項３に記載のサーバ。
5. 前記映像変倍制御部は、前記送信元のクライアントの優先度が、前記処理が実行されているクライアントの優先度よりも高くないと判断した場合には、前記送信元のクライアントの要求を破棄することを特徴とする請求項３に記載のサーバ。
6. 前記映像変倍制御部は、前記サーバの負荷に基づいて、前記送信された要求の送信元のクライアントの要求の受け付けが可能か否かを判断することを特徴とする請求項１に記載のサーバ。
7. 前記映像変倍制御部は、前記映像変倍部で前記映像データの解像度の変更処理が実行されているクライアントのうち、前記送信元のクライアントの優先度よりも低い優先度のクライアントの要求の許可を破棄した場合に、前記送信元のクライアントの要求の受け付けが可能となるか否かを判断することを特徴とする請求項６に記載のサーバ。
8. 前記映像変倍制御部は、前記送信元のクライアントの要求の受け付けが可能となると判断した場合には、前記送信元のクライアントの優先度よりも低い優先度のクライアントの要求の許可を破棄することを特徴とする請求項７に記載のサーバ。
9. 前記映像変倍制御部は、前記送信元のクライアントの要求の受け付けが可能とならないと判断した場合には、前記送信元のクライアントの要求を破棄することを特徴とする請求項７に記載のサーバ。
10. 前記映像変倍制御部は、前記クライアントに送信されている映像データのうち、前記破棄した送信元のクライアントの要求に最も近い画像サイズの映像データを前記破棄した送信元のクライアントに送信することを特徴とする請求項９に記載のサーバ。
11. 請求項１乃至請求項１０のいずれか１項に記載のサーバと、
    前記ネットワークに通信可能に接続された複数のクライアントと、
    を備え、
    前記複数のクライアントの各々は、
    前記サーバから受信した映像データをウインドウに表示する画像表示部と、
    前記ウインドウのサイズの変更を指示するための画像サイズ操作部と、
    前記画像サイズ操作部からの指示に応じて前記ウインドウのサイズを変更するように前記画像表示部を制御する画像サイズ制御部と、
    を備えることを特徴とする映像配信システム。
12. ネットワークを介して複数のクライアントのウインドウに表示される映像データを配送するサーバの制御方法であって、
    前記複数のクライアントのうち、設定された優先度に基づいて、優先度の高いクライアントから送信された映像データの解像度の変更要求を優先的に処理する工程と、
    前記優先的に処理したクライアントに前記要求に応じて解像度が変更された映像データを送信する工程と、
    を含むことを特徴とするサーバの制御方法。

Images