(57)【要約】【課題】  映像配信サーバやクライアントの処理能力に応じて、映像ストリームの最適な配信制御を実現すること。【解決手段】  一のクライアントから配信要求を受信すると、映像ストリームの配信のために接続されている他のクライアントごとに、前記配信要求を受信した時点における処理負荷が求められ、その合計値が現在の処理負荷として推定されるとともに（Ｓ６０３）、前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷が推定される（Ｓ６０４）。そして、推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との少なくともいずれかに基づいて、映像ストリームの配信制御が行われる（Ｓ６０６〜Ｓ６０９）。【選択図】  図６
2005318414.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの要求に応じた属性の映像ストリームを配信する映像配信装置であって、
一のクライアントから配信要求を受信する手段と、
映像ストリームの配信のために接続されている他のクライアントごとに、前記配信要求を受信した時点における処理負荷を求め、その合計値を現在の処理負荷として推定する手段と、
前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷を推定する手段と、
推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との少なくともいずれかに基づいて、映像ストリームの配信制御を行う手段と、
を有することを特徴とする映像配信装置。
【請求項２】
前記配信制御を行う手段は、推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との和が所定の上限値を超える場合に、前記一のクライアントからの配信要求を拒否することを特徴とする請求項１に記載の映像配信装置。
【請求項３】
撮像装置を制御する手段を更に有し、
前記現在の処理負荷および前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷は、前記撮像装置に対する制御の有無を考慮して推定されることを特徴とする請求項１または２に記載の映像配信装置。
【請求項４】
前記配信制御を行う手段は、
所定の上限値と前記現在の処理負荷との差分を余力として求める手段と、
前記余力の範囲内で提供可能な映像ストリームの属性の候補を抽出する手段と、
抽出された各候補を選択肢として前記一のクライアントに通知する手段と、
を含むことを特徴とする請求項１に記載の映像配信装置。
【請求項５】
前記余力の変動に伴い提供可能な映像ストリームの属性の候補が変化した場合、その変化後の各候補を新たな選択肢として前記一のクライアントに再度通知する手段を更に有することを特徴とする請求項４に記載の映像配信装置。
【請求項６】
前記余力の増加に伴い提供可能な映像ストリームの属性の候補の数が増加した場合に、その増加後の各候補を新たな選択肢として前記一のクライアントに再度通知する手段を更に有することを特徴とする請求項４に記載の映像配信装置。
【請求項７】
前記余力の範囲内で提供可能な映像ストリームの属性の候補は、各属性に設定される優先度の情報を考慮して選択されることを特徴とする請求項４から６までのいずれかに記載の映像配信装置。
【請求項８】
前記選択肢に前記配信要求に従う属性の映像ストリームの候補が含まれていない場合において、前記配信要求に従う属性の優先度よりも低い優先度の属性の映像ストリームの配信が他のクライアントに行われているときは、その配信を停止する手段と、
前記低い優先度の属性の映像ストリームの配信を停止した後に、前記余力の範囲内で提供可能な映像ストリームの属性の候補を再度抽出し、新たな選択肢として前記一のクライアントに通知する手段と、
を更に有することを特徴とする請求項７に記載の映像配信装置。
【請求項９】
前記余力の範囲内で提供可能な映像ストリームの属性の候補は、各クライアントに設定される優先度の情報を考慮して選択されることを特徴とする請求項４から６までのいずれかに記載の映像配信装置。
【請求項１０】
前記選択肢に前記配信要求に従う属性の映像ストリームの候補が含まれていない場合において、前記一のクライアントの優先度よりも低い優先度の他のクライアントへの配信が行われているときは、その配信を停止する手段と、
前記低い優先度の他のクライアントへの配信を停止した後に、前記余力の範囲内で提供可能な映像ストリームの属性の候補を再度抽出し、新たな選択肢として前記一のクライアントに通知する手段と、
を更に有することを特徴とする請求項９に記載の映像配信装置。
【請求項１１】
前記余力の範囲内で提供可能な映像ストリームの属性の候補は、クライアントの各ユーザに設定される優先度の情報を考慮して選択されることを特徴とする請求項４から６までのいずれかに記載の映像配信装置。
【請求項１２】
前記選択肢に前記配信要求に従う属性の映像ストリームの候補が含まれていない場合において、前記ユーザの優先度よりも低い優先度のユーザのクライアントへの配信が行われているときは、その配信を停止する手段と、
前記低い優先度のユーザのクライアントへの配信を停止した後に、前記余力の範囲内で提供可能な映像ストリームの属性の候補を再度抽出し、新たな選択肢として前記一のクライアントに通知する手段と、
を更に有することを特徴とする請求項９に記載の映像配信装置。
【請求項１３】
前記一のクライアントから前記配信要求と共に対価もしくはポイント数の情報を受け取る手段と、
この対価もしくはポイント数の情報に基づいて、前記優先度を調整する手段と、
を更に有することを特徴とする請求項７から１２までのいずれかに記載の映像配信装置。
【請求項１４】
推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との和が前記所定の上限値を超える場合に、前記一のクライアントへの前記配信要求に従う映像ストリームの配信を可能にするための代替の属性の候補を、該当する他のクライアントまたは当該一のクライアントを提示する手段を更に有することを特徴とする請求項１に記載の映像配信装置。
【請求項１５】
各属性ごとの特定の映像ストリームに対する処理負荷を実測する手段を更に有し、
前記現在の処理負荷は、映像ストリームの配信のために接続されている他のクライアントごとに、前記実測の結果に基づいて前記配信要求を受信した時点における処理負荷を求め、その合計値によって推定され、
前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷は、前記実測の結果に基づいて推定される
ことを特徴とする請求項１に記載の映像配信装置。
【請求項１６】
クライアントからの要求に応じた属性の映像ストリームを配信するための映像配信方法であって、
一のクライアントから配信要求を受信するステップと、
映像ストリームの配信のために接続されている他のクライアントごとに、前記配信要求を受信した時点における処理負荷を求め、その合計値を現在の処理負荷として推定するステップと、
前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷を推定するステップと、
推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との少なくともいずれかに基づいて、映像ストリームの配信制御を行うステップと、
を有することを特徴とする映像配信方法。
【請求項１７】
クライアントからの要求に応じた属性の映像ストリームを配信する映像配信サーバを制御するためのプログラムであって、
一のクライアントから配信要求を受信するためのコードと、
映像ストリームの配信のために接続されている他のクライアントごとに、前記配信要求を受信した時点における処理負荷を求め、その合計値を現在の処理負荷として推定するためのコードと、
前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷を推定するためのコードと、
推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との少なくともいずれかに基づいて、映像ストリームの配信制御を行うためのコードと、
を含むことを特徴とするプログラム。
【請求項１８】
請求項１７に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【請求項１９】
任意の属性の映像ストリームの配信を映像配信装置に要求し、その映像配信装置から前記要求に応じた映像ストリームの配信を受ける情報処理端末であって、
前記映像配信装置が提供可能な映像ストリームの属性の候補の情報を、前記映像配信装置から受信する手段と、
この情報処理端末の現在の処理能力を推定する手段と、
推定された前記処理能力に基づいて、受信した前記候補を絞り込む手段と、
前記絞り込まれた候補を表示し、表示された候補のうちのいずれかをユーザに選択させる手段と、
を有することを特徴とする情報処理端末。
【請求項２０】
任意の属性の映像ストリームの配信を映像配信装置に要求し、その映像配信装置から前記要求に応じた映像ストリームの配信を受ける情報処理端末の制御方法であって、
前記映像配信装置が提供可能な映像ストリームの属性の候補の情報を、前記映像配信装置から受信するステップと、
この情報処理端末の現在の処理能力を推定するステップと、
推定された前記処理能力に基づいて、受信した前記候補を絞り込むステップと、
前記絞り込まれた候補を表示し、表示された候補のうちのいずれかをユーザに選択させるステップと、
を有することを特徴とする情報処理端末の制御方法。
【請求項２１】
任意の属性の映像ストリームの配信を映像配信装置に要求し、その映像配信装置から前記要求に応じた映像ストリームの配信を受ける情報処理端末を制御するためのプログラムであって、
前記映像配信装置が提供可能な映像ストリームの属性の候補の情報を、前記映像配信装置から受信するためのコードと、
この情報処理端末の現在の処理能力を推定するためのコードと、
推定された前記処理能力に基づいて、受信した前記候補を絞り込むためのコードと、
前記絞り込まれた候補を表示し、表示された候補のうちのいずれかをユーザに選択させるためのコードと、
を含むことを特徴とするプログラム。
【請求項２２】
請求項２１に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像配信システムに関し、特に、クライアントからの要求に応じた属性の映像ストリームを配信する映像配信システムにおける映像ストリームの配信を制御する技術に関する。
【背景技術】
【０００２】
近年のストリーミング技術の発達により、サーバから配信される映像をクライアントで閲覧することが一般的になってきている。その際には、クライアントの要求する各種の属性（符号化／復号化、画質、ビットレートなど）に応じて、ストリームが選択されたり、画像変換などがされて、配信されている。
【０００３】
また、ＱｏＳなどの観点から、サーバ−クライアント間での配信データの制御も行われている（例えば特許文献１を参照。）
この他、組み込み機器型のカメラサーバの映像配信システムもあり、ユーザの要求によってカメラ制御などを行うことで所望する映像ストリームを得ることができる（例えば特許文献２を参照。）。
【０００４】
映像の配信制御の典型例は次のようなものである。たとえば、映像配信を行うサーバ（映像配信サーバ）は、複数のクライアントに同時に接続されて、それぞれのクライアントから映像ストリームの配信が要求される。ここで同時に映像配信を行うクライアント数が増えるほど映像配信サーバにかかる処理負荷は増大していく。そして、この処理負荷が映像配信サーバの処理能力を超えてしまうと全体のパフォーマンスが落ち、円滑なストリーミングが妨げられることになる。そこで従来は、同時に接続されるクライアントの数に制限を設け、その制限いっぱいの数のクライアントが接続されている状態で更に別のクライアントからの配信要求が来た場合にはその配信要求を拒否する、という制御が行われていた。
【０００５】
【特許文献１】特開２００３−００９１２６号公報
【特許文献２】特開平１０−１６４４２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、クライアントが任意の属性の映像ストリーム（マルチストリーム）の配信を要求することができ、映像配信サーバがそのクライアントからの要求に応じた属性の映像ストリームを配信するシステムを考えた場合には、従来のように単純に同時に接続されるクライアントの数に制限を設けても有効な配信制御を実現することはできない。クライアントごとに取り扱う映像ストリームの属性が異なり、その属性の違いによって処理負荷も異なるからである。同時に接続されるクライアント数が少なくてもそれぞれのクライアントが最高レベルの品質の映像を要求してくる場合には映像配信サーバの処理能力を超えてしまい、ストリーミングが滞る事態が生じる可能性は排除できない。
【０００７】
とりわけ、組み込み機器型のカメラサーバは、一般的な映像配信サーバなどに比べると非力であり、加えて、映像配信サーバのように画像の処理だけでなく各種の機器制御にも処理能力を割かれることになるので、上記の問題はより顕著である。
【０００８】
また、この問題はサーバの処理能力だけの問題ではなく、クライアントの処理能力によっても、システム全体としての処理能力は変わることに留意する必要もある。
【０００９】
また、クライアントの利用者は、クライアントの持つ処理能力に合った適切な画像属性の映像ストリームを選択するために、試行錯誤を繰り返して最適な映像ストリームを探し出す手間が必要であった。
【００１０】
さらに、同時に接続されているクライアントに対して、映像配信サーバの処理能力を分配する際に、単純に分配するだけではなく、多様な観点で分配することのできる配信制御技術が求められている。
【課題を解決するための手段】
【００１１】
本発明は、上記したような課題の少なくともいずれか、あるいはその他の課題を解決することを目的としている。
【００１２】
本発明の一側面に係る映像配信装置および方法によれば例えば、一のクライアントから配信要求を受信すると、映像ストリームの配信のために接続されている他のクライアントごとに、前記配信要求を受信した時点における処理負荷が求められ、その合計値が現在の処理負荷として推定されるとともに、前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷が推定される。そして、推定された前記現在の処理負荷と前記一のクライアントへの前記配信要求に従う映像ストリームの配信にかかる処理負荷との少なくともいずれかに基づいて、映像ストリームの配信制御が行われる。
【発明の効果】
【００１３】
本発明によれば、映像配信サーバやクライアントの処理能力に応じて、映像ストリームの最適な配信制御が実現される。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。以下では、多くの実施形態を説明するが、実施形態間で共通の構成や処理については共通の参照番号を付し、これにより重複した説明を回避している。ただし、共通の参照番号が付されていてもその内容が前出の構成や処理と相違する点を含む場合には、その都度その相違する点については言及することにする。
【００１５】
（実施形態１）
図１は、本発明の実施形態に係る映像配信システムの構成を示すブロック図である。
【００１６】
映像配信装置としての映像配信サーバ１００は、撮像装置１０１からの映像信号１０２を受けデータを圧縮するデータ圧縮装置１０３、ブートプログラムや各種データを記憶するメモリ１０４、演算や処理の制御を行う中央処理装置（ＣＰＵ）１０５、ネットワークに接続するためのネットワークインターフェース（Network I/F）１０６を含む構成である。
【００１７】
撮像装置１０１は、映像配信サーバ１００の制御信号１０７を受け、映像信号１０２を出力する。なお、本実施形態では、図示のように、映像配信サーバ１００と撮像装置１０１とは独立した構成となっているが、両者が一体となった構成であってもよい。
【００１８】
データ圧縮装置１０３は、例えば圧縮チップにより実現されるもので、映像信号を圧縮してＪＰＥＧやＭＰＥＧ等の形式のデータを出力し、メモリ１０２に格納する。
【００１９】
ネットワークインターフェース（Ｉ／Ｆ）１０６は、例えばネットワークチップにより実現されるもので、ネットワーク１０８とＣＰＵ１０５との間のデータのＩ／Ｏの機能を提供する。
【００２０】
複数のクライアント（情報処理端末）１０９（クライアント１０９−１，１０９−２，…，１０９−ｎ）はそれぞれ、ビューワとして機能するもので、ネットワーク１０８を介して映像配信サーバ１００より配信されたデータを受け取り表示する。クライアント１０９は、パーソナルコンピュータ（ＰＣ）や携帯型コンピュータ（ＰＤＡ）、携帯電話などによって実現されうる。
【００２１】
メモリ１０４には、図２に示すように、マルチストリーム作成プログラム２１０、配信制御プログラム２２０、ストリーム負荷データ２５０、接続情報２６０等が格納される。
【００２２】
図３は、本実施形態における映像配信サーバ１００によるマルチストリーム作成処理を示すフローチャートである。このフローチャートに対応するプログラムはマルチストリーム作成プログラム２１０に含まれ、ＣＰＵ１０５によって実行される。ここでは、６４０ｘ４８０、３２０ｘ２４０、１６０ｘ１２０の画像サイズのＪＰＥＧマルチストリームを扱う例を示す。
【００２３】
まずステップＳ３０１において、メモリ１０４内の各種設定パラメータの初期設定を行う。この際、図４に示すような構造のストリーム負荷データ２５０や、後述するサーバ処理の上限値である設定値Ｘなどのロードも行われる。ストリーム負荷データ２５０は、例えば圧縮チップ（データ圧縮装置１０３）の性能に基づいて、属性としての画像サイズごとの処理負荷の値を有する。図４に示した例では、画像サイズ１６０ｘ１２０の場合の処理負荷を基準（＝１）として各画像サイズの映像配信サーバ１００のストリーム配信を処理するための負荷が記述されている。図４に示すデータは予め実験して得られた値であってもよいし、推定値であってもよい。すなわち、３２０ｘ２４０のときの処理負荷は４、６４０ｘ４８０のときの処理負荷が１６、８００ｘ６００のときの処理負荷が２５、となっている。
【００２４】
次に、ステップＳ３０２において、ステップＳ３０１で設定された撮像パラメータを用いて撮像装置１０１の初期設定を行う。この設定は例えば、撮像装置１０１への制御信号１０７を使用して行うことができる。
【００２５】
次に、ステップＳ３０３において、ステップＳ３０１で設定されたデータ圧縮パラメータを用いてデータ圧縮装置１０３の初期設定を行う。この設定は例えば、圧縮する画像サイズなどを含む。
【００２６】
続くステップＳ３０４では、割り込みなどのイベントを待つ。以下のステップＳ３２０，Ｓ３３０，Ｓ３４０，Ｓ３５０，Ｓ３６０，Ｓ３７０はそれぞれ、受け取ったイベントの種類を判断するステップとなる。
【００２７】
受信したイベントが映像要求イベントであった場合は（ステップＳ３２０，ｙｅｓ）、要求された画像の属性であるサイズをデータ圧縮装置１０３に設定し（ステップＳ３２１）、その後ステップＳ３０４のイベントループに戻る。
【００２８】
データ圧縮装置１０３より映像作成完了イベントを受け取った場合は（ステップＳ３３０，ｙｅｓ）、メモリ１０４よりその画像を取り出し（ステップＳ３３１）、図５に示すような構造の接続情報２６０に従って、映像要求イベントを発行したクライアントに送信する（ステップＳ３３２）。接続情報２６０は、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズを記述したもので、後述する処理によって接続状況の変化に応じて更新される。
【００２９】
クライアント１０９より、ネットワークインターフェース１０６を介して、継続映像要求イベントを受け取った場合は（ステップＳ３４０，ｙｅｓ）、映像要求イベントを発行してステップＳ３２１と同様の処理を行い（ステップＳ３４１）、その後ステップＳ３０４のイベントループに戻る。ここで、継続映像要求イベントとは、映像配信サーバ１００からクライアント１０９への映像の継続的な配信を要求するイベントである。
【００３０】
クライアント１０９より、ネットワークインターフェース１０６を介して、接続終了イベントを受け取った場合には（ステップＳ３５０，ｙｅｓ）、接続情報２６０から該当するデータを一件削除して（ステップＳ３５１）、ステップＳ３０４のイベントループに戻る。ここで、接続終了イベントとは、映像配信サーバ１００とクライアント１０９との接続を断つために、クライアント１０９より、映像配信サーバ１００に対して要求されるイベントである。また、この接続終了イベントは、何らかの理由で映像配信サーバ１００からクライアント１０９への通信が途切れてしまったような場合にも発行されうる。
【００３１】
以上のステップＳ３２０〜Ｓ３５１のような処理によって本実施形態の映像配信機構が実現される。
【００３２】
次に、クライアント１０９より、ネットワークインターフェース１０６を介して、接続要求イベントを受け取った場合には（ステップＳ３６０，ｙｅｓ）、配信制御プログラム２２０に基づいて、配信制御処理を実行する（ステップＳ３６１）。この接続要求イベントは、クライアントより要求された映像ストリームの属性の情報（以下「要求画像属性」という。）も含む。
【００３３】
以下、この映像配信サーバ１００によるステップＳ３６１における配信制御処理を、図６のフローチャートを用いて説明する。
【００３４】
まず、ステップＳ６０１で、接続要求イベントに含まれる要求画像属性を読み込み、ステップＳ６０２で、接続情報２６０を読み込む。この接続情報２６０を参照すれば現在接続されている全クライアントを特定することができる。
【００３５】
次に、ステップＳ６０３で、接続されているクライアントごとに、ストリーム負荷データ２５０を参照して、そのクライアントに対応する負荷を読み出し加算していき、その総和を全体負荷Ｆとして求める。この全体負荷Ｆによって現在の処理負荷が推定される。
【００３６】
図５の接続情報２６０および図４のストリーム負荷データ２５０に基づいて一例を説明する。図５の接続情報２６０を参照すると、現在クライアント１０９−１とクライアント１０９−２が映像配信サーバ１００に接続されている。クライアント１０９−１は画像サイズが６４０ｘ４８０の映像を要求しており、一方、クライアント１０９−２は画像サイズが１６０ｘ１２０の映像を要求していることが分かる。次に、図４のストリーム負荷データ２５０を参照すると、６４０ｘ４８０の画像の処理負荷は１６、１６０ｘ１２０の画像の処理負荷は１であるから、この場合の全体負荷Ｆ（すなわち、現在の処理負荷）は、Ｆ＝１６＋１＝１７となる。
【００３７】
次に、ステップＳ６０４で、今回要求されている映像に対する負荷ｆをストリーム負荷データ２５０を参照して求める。たとえば、画像サイズ３２０ｘ２４０の映像が要求されている場合には、ストリーム負荷データ２５０を参照すると、今回要求されている映像に対する負荷ｆは、４と推定される。
【００３８】
今回新たに要求されている映像の配信を実行する場合には、そのときの全体の処理負荷は、現在の処理負荷（＝全体負荷Ｆ）に、今回要求されている映像に対する負荷ｆを追加した値となる。この値が映像配信サーバ１００の処理能力の限界を超える場合には、全体のパフォーマンスが落ち、円滑なストリーミングが妨げられる可能性がある。そこで、ステップＳ６０５で、ステップＳ３０１で読み込んだサーバ処理の上限値である設定値Ｘ（以下「上限値Ｘ」という。）を読み出し、ステップＳ６０６で、全体負荷Ｆと負荷ｆとの和（＝今回要求されている映像の配信を実行するとした場合の全体の処理負荷）が上限値Ｘ以下に収まっているかどうか（すなわち、Ｘ≧Ｆ＋ｆを満たすかどうか）を判断する。ここで、Ｘ≧Ｆ＋ｆを満たす場合には、ステップＳ６０７に進み、接続要求イベントの発行元のクライアントの情報を接続情報２６０に登録する。その後、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行う（ステップＳ６０８）。一方、Ｘ≧Ｆ＋ｆを満たさない場合には、接続要求イベントの発行元に拒否応答を返す（ステップＳ６０９）。
【００３９】
ここで、上限値Ｘについて説明しておく。この上限値Ｘは、映像配信サーバ１００の管理者などによって変更することのできる値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。上限値Ｘは固定値としてあらかじめメモリ１０４に設定しておいてもよいが、例えばｔｅｌｎｅｔやｆｔｐ、ＲＰＣなどの機構によってメモリ１０４に設定するようにしてもよい。
【００４０】
なお従来の方式では、この上限値はクライアントの接続数などで指定されており、管理者の許可する処理能力の上限値を表すものではなかった。従来のようにクライアントの接続本数で制限した場合、大きな負荷のストリームばかりが選択されたときに、映像配信装置の処理能力を上回り、全てのストリーム配信に不具合が出てしまい、逆に、小さな負荷のストリームばかりが選択されたときには、映像配信装置の処理能力に余力があるにもかかわらず、接続数が上限に達したということだけで配信が拒否されるという事態が生じていた。
【００４１】
一方、本実施形態の上限値Ｘは単なるクライアントの接続本数等ではなく、画像処理などにかかる負荷を直接示す値であるから、映像配信サーバの処理能力をより有効に活用することができる。
【００４２】
説明を図３のフローチャートに戻す。上記したステップＳ３６１の配信制御処理が終了すると、ステップＳ３０４のイベントループに戻る。
【００４３】
終了イベントを受け取った場合は（ステップＳ３７０，ｙｅｓ）、ステップＳ３７１に進み、接続情報２６０を全件削除して、このマルチストリーム作成処理を終了する。
【００４４】
以上説明した実施形態１によれば、映像配信サーバにおいて、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷（Ｆ＋ｆ）が推定され、それが所定の上限値（Ｘ）を超える場合には当該要求に係る接続が拒否される。これにより、映像配信サーバ１００の処理負荷が能力の限界を超えてしまい全体のパフォーマンスが落ち、円滑なストリーミングが妨げられるような事態の発生を防止することができる。
【００４５】
特に、組み込み機器型のカメラサーバなど、比較的に処理能力の非力な映像配信サーバにおいてはこの効果が高い。このような機器の場合、転送路の制約に対して機器の処理能力の制約が大きく、機器の性能に対して転送路の性能が上回るため、従来型の接続本数の制限や、転送量の制約などだけでは適切な配信制御を行うことができなかったが、機器の処理能力によって配信制御を行うことで、映像配信サーバの処理能力をより有効に活用することができる。
【００４６】
なお、本実施形態における映像配信サーバへの接続は映像の配信を目的としたものであり、それ以外の処理を目的とした接続は考慮しなかった。したがって、上記の「接続を拒否する」という表現は「映像の配信を拒否する」と等価である（以下同様。）。
【００４７】
また、上述の実施形態では、画像の属性が画像のサイズを示す場合の例について説明したが、画像の属性としてはこの他に、符号化／復号化、画質、フレームレート、あるいはこれらの組み合わせ等が考えられ、これらの属性についても本発明を適用することができることは容易に理解できるであろう。
【００４８】
（実施形態２）
上述の実施形態１では、画像の属性として、画像サイズ、画質、フレームレート等を扱い、これらに応じた映像ストリームの配信制御について説明したが、本実施形態では、このような画像属性だけでなく、撮像装置（カメラ）の制御内容を示す「処理属性」をも加味した映像ストリームの配信制御を行う。
【００４９】
本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図７に示すように、実施形態１と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、ストリーム負荷データ２５０、接続情報２６０に加えて、撮像装置１０１を制御する手段としてのカメラ制御プログラム７１０が格納されている。このカメラ制御プログラム７１０を実行するかどうかはユーザが任意に設定することが可能であり、カメラ制御プログラム７１０が実行された場合には例えば、撮像装置１０１の向きを巡回させる巡回処理や、動体を検知してその動体を追尾するように撮像装置１０１の向きを移動させる動体追尾処理などのカメラ制御が行われる。なお、これらの各処理について個々に実行する／しないをユーザが設定できることがより好ましいが、ここでは説明を簡単にするために、カメラ制御プログラム７１０の実行／非実行の設定だけが行われると仮定する。なお、以下では、「カメラ制御プログラム７１０の実行／非実行」のことを「カメラ制御あり／なし」と略記する。
【００５０】
カメラ制御ありの場合には、ＣＰＵ１０５の処理は映像ストリームの配信処理だけでなく、このカメラ制御にも割かれることになる。本実施形態ではこのことを考慮して、ストリーム負荷データ２５０には、画像サイズごとに、カメラ制御ありの場合とカメラ制御なしの場合の処理負荷がそれぞれ記述されている。図８に、このストリーム負荷データ２５０の構造例を示す。同図の例では、画像サイズが１６０ｘ１２０でカメラ制御なしの場合の処理負荷を基準（＝１）として、各ケースの処理負荷が記述されている。同様に、接続情報２６０にも、図９に示すように、現在接続されているクライアントごとに、画像サイズに加えカメラ制御あり／なしの情報が記述されている。
【００５１】
本実施形態におけるマルチストリーム作成処理は基本的に実施形態１における処理（図３、図６）とほぼ同様に行われる。
【００５２】
なお、本実施形態の場合、図６のステップＳ６０３では、例えば次のようにして全体負荷Ｆが求められる。図９の接続情報２６０を参照すると、現在クライアント１０９−１とクライアント１０９−２が映像配信サーバ１００に接続されている。クライアント１０９−１は、画像サイズ６４０ｘ４８０の映像を要求し、カメラ制御は「なし」の設定である。一方、クライアント１０９−２は、画像サイズ１６０ｘ１２０の映像を要求しているが、カメラ制御は「あり」の設定である。次に、図８のストリーム負荷データ２５０を参照すると、６４０ｘ４８０の画像についてカメラ制御なしの場合の処理負荷は１６、１６０ｘ１２０の画像についてカメラ制御ありの場合の処理負荷は２であるから、この場合の全体負荷Ｆは、Ｆ＝１６＋２＝１８となる。
【００５３】
また、今回要求されている映像ストリームの作成にかかる負荷ｆをストリーム負荷データ２５０から求めるステップＳ６０４では、たとえば、画像サイズ３２０ｘ２４０の映像が要求され、カメラ制御ありの設定がなされている場合には、図８のストリーム負荷データ２５０を参照すると、負荷ｆ＝５と推定される。
【００５４】
上限値Ｘは、実施形態１と同様、映像配信サーバ１００の管理者などによって変更することのできる設定値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。実施形態１では、典型的に、上限値Ｘは、圧縮処理の負荷の総和に対する上限値として設定されたが、本実施形態では圧縮処理のみならずカメラ制御に要する負荷を含む処理負荷の総和に対する上限値として設定されることになる。
【００５５】
（実施形態３）
上述の実施形態１，２は、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷（Ｆ＋ｆ）を推定し、それが所定の上限値（Ｘ）を超えるときは当該要求に係る接続を拒否する、というものであった。
【００５６】
本実施形態は、上限値（Ｘ）を超えるときに当該要求に係る接続を直ちに拒否するのではなく、映像配信サーバの余力の範囲内で提供可能な映像ストリームの属性の候補を選択肢として提供する。これにより、ユーザが接続できないケースを減らし、少なくとも低負荷のストリームを提供できるようにすることがねらいである。以下の説明では基本的に実施形態２を基に、相違する点を中心に説明するが、本実施形態は実施形態１に対しても適用が可能である。
【００５７】
本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図１０に示すように、実施形態２と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、ストリーム負荷データ２５０、接続情報２６０に加えて、ストリーム選択肢情報２７０が格納されている。また、本実施形態のストリーム負荷データ２５０および接続情報２６０はそれぞれ、実施形態２と同様に、図８、図９に示したような構造を有するものとする。
【００５８】
本実施形態における映像配信サーバ１００によるマルチストリーム作成処理は基本的に実施形態１，２における処理（図３）とほぼ同様に行われる。ただし本実施形態では、ステップＳ３６１における配信制御処理が、図１１のフローチャートに従って行われる。
【００５９】
まず、ステップＳ１００１で、接続情報２６０を読み込む。また、実施形態１，２におけるステップＳ６０１と同様に、接続要求イベントに含まれる要求画像属性も読み込む。
【００６０】
次に、ステップＳ１００２で、接続情報２６０およびストリーム負荷データ２５０を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。次に、ステップＳ１００３で、今回要求されている映像に対する負荷ｆをストリーム負荷データ２５０を参照して求める。
【００６１】
次に、ステップＳ１００４で、ステップＳ３０１で読み込んだサーバ処理の上限値Ｘを読み出す。上限値Ｘは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップＳ１００５で、全体負荷Ｆと負荷ｆとの和（＝今回要求されている映像の配信を実行するとした場合の全体の処理負荷）が上限値Ｘ以下に収まっているかどうか（すなわち、Ｘ≧Ｆ＋ｆを満たすかどうか）を判断する。ここで、Ｘ≧Ｆ＋ｆを満たす場合には、ステップＳ１００６に進み、接続要求イベントの発行元のクライアントの情報を接続情報２６０に登録する。その後、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行い（ステップＳ１００７）、本処理を終了する。
【００６２】
一方、ステップＳ１００５で、Ｘ≧Ｆ＋ｆを満たさない場合には、ステップＳ１００８に進み、映像配信サーバ１００の余力Ｙを求める。映像配信サーバ１００の余力Ｙは、上限値Ｘ−全体負荷Ｆにより求める。
【００６３】
次に、ステップＳ１００９で、求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ２５０から読み出し、図１２に示すような構造のストリーム選択肢情報２７０をメモリ１０４に書き込む。例えば、上限値Ｘ＝２５、全体負荷Ｆ＝１８と仮定すると、余力Ｙ＝２５−１８＝７となる。その後、図８のストリーム負荷データ２５０から、負荷の値が７（＝余力）以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報２７０を構成する。この例では具体的には、「ｊｐｅｇ３２０ｘ２４０、カメラ制御なし」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御あり」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御なし」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」、が抽出され、図１２に示されるようなストリーム選択肢情報２７０が構成される。
【００６４】
次に、ステップＳ１０１０で、ストリーム選択肢情報２７０をクライアントへ通知し、ステップＳ１０１１で、イベントを待つ。
【００６５】
ステップＳ１０１２において、ストリーム選択肢情報２７０を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップＳ１０１３に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報２７０の選択番号などで受け取ることにしても良い。次に、ステップＳ１０１４で、ステップＳ６０７と同様に、属性特定要求イベントの発行元のクライアントの情報を接続情報２６０に登録し、続くステップＳ１０１５で、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行う。
【００６６】
また、ステップＳ１０１６において、ストリーム選択肢情報２７０を渡したクライアントから接続終了イベントを受け取った場合、または、ステップＳ１０１７において、ストリーム選択肢情報２７０をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。
【００６７】
以上説明した実施形態３によれば、映像配信サーバ１００の余力に応じた映像ストリーム（すなわち、映像配信サーバ１００全体の処理負荷が上限値Ｘを超えない範囲で提供が可能な映像ストリーム）の候補が選択肢としてクライアントに通知され、ユーザはこれに応じて次善の映像ストリームを選択することができる。これにより、ユーザが接続できないケースを減らすことができ、少なくとも低負荷のストリームを提供できるようになる。
【００６８】
なお、上記の処理例では、ステップＳ１００５で、全体負荷Ｆと負荷ｆとの和、すなわち、今回要求されている映像ストリームの配信を実行するとした場合の全体の処理負荷、が上限値Ｘを超える場合に、ステップＳ１００８以降の処理が実行されて選択肢がクライアントに通知されるようにしたが、全体負荷Ｆと負荷ｆとの和が上限値Ｘを超えるかどうかに関わらず、選択肢をクライアントに通知するようにしてもよい。
【００６９】
（実施形態４）
上述の実施形態３では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の選択肢をユーザに通知するようにした。しかし、映像配信サーバに課せられる負荷は刻々と変化するので、これに伴い余力も変動する。そこで本実施形態では、映像配信サーバの余力を監視し、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合には、改めて選択肢を通知するようにする。
【００７０】
図１３は、本実施形態における映像配信サーバ１００によるマルチストリーム作成処理を示すフローチャートである。このフローチャートにおける多くのステップは図３のフローチャートにおけるステップと同様であるので、同じ内容のステップには同じ参照番号を付しそれらの説明は省略し、以下では、図３と相違するステップについてのみ説明する。
【００７１】
図３と対照すると分かるように、図１３のフローチャートには、ステップＳ３０４とステップＳ３２０との間に、ステップＳ３１０〜Ｓ３１６の処理が挿入されている。
【００７２】
ステップＳ３１０において、受信したイベントが、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に発行される選択肢変化イベントであった場合は、ストリーム負荷データ２５０と接続情報２６０を読み込み（ステップＳ３１１）、クライアントごとに、次の一連の動作を経て選択肢を通知する（ステップＳ３１２）。
【００７３】
すなわち、接続情報２６０およびストリーム負荷データ２５０を参照して、現在接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。次に、上限値Ｘと全体負荷Ｆとの差分を余力Ｙとして求め、その余力Ｙに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ２５０から読み出し、メモリ１０４に格納されているストリーム選択肢情報２７０を更新する（ストリーム選択肢情報２７０がまだメモリ１０４に作成されていない場合には新規に作成する。）。そして、クライアント毎に新たな選択肢を通知し、その後ステップＳ３０４へ戻る。
【００７４】
なお、クライアントは、選択肢の通知を受け取ると、映像再生中であってもその選択肢が表示される。クライアントの使用者は、表示された選択肢から所望する属性を選択することができる。また、映像配信サーバ１００の余力が増えたことで、より高品質な属性の選択肢が増えた場合には、クライアントは、その高品質な属性が自動で選択するように構成されていると好都合である。
【００７５】
クライアント側で別の属性が選択された場合には、属性変更要求イベントが映像配信サーバ１００に発行される。
【００７６】
ステップＳ３１３において、属性変更要求イベントを受信した場合には、要求された属性を読み込み（ステップＳ３１４）、その属性でメモリ１０４に格納されている接続情報２６０の該当部分を変更する（ステップＳ３１５）。つづいて、映像要求イベントと選択肢変化イベントを発行する（ステップＳ３１６）。選択肢変化イベントは、接続情報２６０を変更した際に発行される。
【００７７】
さらに、図１３のフローチャートが図３のフローチャートと異なっているのは、ステップＳ３５１の後にステップＳ３５２が新たに挿入されている点である。ステップＳ３５１で接続情報２６０から該当するデータが削除されると、その後、ステップＳ３５２において、選択肢が変化したことを示す選択肢変化イベントが発行される。
【００７８】
また、ステップＳ３６１で実行される配信制御処理も、基本的には図１１に示したフローチャートに従って実行されるが、本実施形態では、ステップＳ１０１４において接続情報２６０に新たに接続されるクライアントの情報が追加登録され、ステップＳ１０１５で映像要求イベントが発行された後、この配信制御処理を完了する前にも選択肢変化イベントが発行される。
【００７９】
以上説明した実施形態４によれば、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に、新たな選択肢が随時提示されるので、クライアントの使用者はその余力に応じた最適な属性をタイムリーに選択することが可能になる。たとえば、最低限のストリームで接続していたクライアントも、サーバに余力が出た時点で、より高品質なストリームを要求し直すことができる。
【００８０】
（実施形態５）
上述の実施形態４では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があると、その都度新たな選択肢が提示された。
【００８１】
しかし、余力が少なくなった場合には、選択肢は、現在提供しているストリームよりも低品質なストリームに減るだけで、高品質なストリームが増えることはない。そうすると、クライアントのユーザにとっては、現在閲覧中のストリームより低品質のものに切り換えることをわざわざ勧められるということになってしまい、好ましくないと考えることもできる。
【００８２】
そこで、本実施形態では、余力が増加した場合に限り、新たな選択肢を提示する。
【００８３】
これを実現するためには、実施形態４では図１３のフローチャートにおけるステップＳ３１６において発行するようにした選択肢変化イベントを、発行しないようにする。同様に、実施形態４では図１１のフローチャートにおけるステップＳ１０１５の後で発行するようにした選択肢変化イベントを、発行しないようにする。これにより、選択肢変化イベントが発行されるのは、接続が減少した場合に実行されるステップＳ３５２においてだけとなる。
【００８４】
つまり、接続が増加する場合には選択肢変化イベントを発行せず、接続が減少する場合のみ、選択肢変化イベントを発行する。
【００８５】
これにより、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補の数が増加した場合にのみ、クライアントに選択肢の変化通知がなされるので、クライアントの使用者は有益な通知だけを受け取ることができる。
【００８６】
（実施形態６）
本実施形態は、上述の実施形態３〜５のいずれかに記載した、提供可能な映像ストリームの属性の候補の選択肢を提供する映像配信サーバ１００に対するクライアント１０９における制御処理に関する。以下では、実施形態３の映像配信システムに基づいて説明する。
【００８７】
図１４は、実施形態におけるクライアント１０９の構成を示す図である。
【００８８】
クライアント１０９は、図示のように、映像配信サーバ１００からのデータを、ネットワーク１０８を介して受け取るネットワークインタフェース（Network I/F）２００１、演算や処理の制御を行う中央処理装置（ＰＵ）２００２、必要なプログラムやデータを記憶するメモリ２００３、ＬＣＤやＣＲＴなどで構成される表示装置２００４、を含む。
【００８９】
ネットワークインタフェース２００１を介して受信した圧縮データはメモリ２００３に一旦格納される。その後、ＣＰＵ２００２によってその圧縮データが伸張処理され、表示装置２００４に表示される。もっとも、ＣＰＵ２００２に代わって伸張処理を実行する専用のデータ処理伸張装置（ＤＳＰなど）が付加された構成でもよい。
【００９０】
メモリ２００３には、図１５に示すように、映像配信サーバ１００からの映像ストリームを受信するための映像ストリーム受信プログラム２１００、後述する選択肢限定処理を実現するための選択肢限定プログラム２１２０、ビューワ機能を実現するためのビューワプログラム２１３０、クライアントの現在の余剰処理能力を測定するためのベンチマークプログラム２１４０等のプログラムが格納される他、画像の属性ごとのクライアントの処理負荷を示すクライアントストリーム負荷データ２１５０、映像配信サーバ１００より通知される提供可能な映像ストリームの属性候補の選択肢の情報であるストリーム選択肢情報２１６０、選択肢限定プログラム２１２０の実行によって限定された選択肢データが記述されるストリーム限定選択肢情報２１７０等の各種データが格納される。
【００９１】
図１６は、本実施形態におけるクライアント１０９によるマルチストリーム受信処理を示すフローチャートである。このフローチャートに対応するプログラムはストリーム受信プログラム２１００に含まれ、ＣＰＵ２００２によって実行される。このストリーム受信プログラム２１００は例えばビューワプログラム２１３０の実行においてコールされる。また、後述するように、ベンチマークプログラム２１４０および選択肢限定プログラム２１２０はストリーム受信プログラム２１３０の実行においてコールされるという関係である。
【００９２】
まずステップＳ２２０１において、メモリ２００３内の各種設定パラメータの初期設定を行う。この際、図１８に示すような構造のクライアントストリーム負荷データ２１５０のロードも行われる。クライアントストリーム負荷データ２１５０は、例えば、各画像サイズについてカメラ制御の有無別に、ＣＰＵ２００２の性能に基づく処理負荷を有する。図１８に示した例では、画像サイズが１６０ｘ１２０でカメラ制御なしの場合の処理負荷を基準（＝１）として、各画像サイズについてカメラ制御の有無ごとに処理負荷が記述されている。
【００９３】
次に、ステップＳ２２０２で、接続要求イベントを発行し、これを映像配信サーバ１００に送信する。上述したとおり、映像配信サーバ１００は、この接続要求イベントの受信に応答して配信制御処理を実行し（図３、ステップＳ３６１）、状況に応じて、提供可能な映像ストリームの属性の候補の選択肢の情報を接続要求イベントの発行元のクライアントに送信する（図１１、ステップＳ１０１０）。
【００９４】
なお、ステップＳ２２０２で接続要求イベントを送信する際、初期のストリーム種別の要求も送信する場合もある。ただし、映像受信サーバ１００から接続拒否されたり、要求ストリーム以下の選択肢しか送付されなかったりする場合もありえる。
【００９５】
次のステップＳ２２０６で、イベントを待つ。
【００９６】
ステップＳ２２０３において、映像配信サーバ１００より、提供可能な映像ストリームの属性の候補の選択肢の情報を受信したときは、メモリ２００３内にその選択肢の情報をストリーム選択肢情報２１６０として保存し、その後、選択肢限定プログラム２１２０をコールすることにより、受信した選択肢を絞り込むための選択肢限定処理を実行する（ステップＳ２２０４）。このときのストリーム選択肢情報２１６０の構造例を図１９に示す。
【００９７】
以下、このステップＳ２２０４における選択肢限定処理を、図１７のフローチャートを用いて説明する。
【００９８】
まずステップＳ２３０１で、メモリ２００３に保存されているストリーム選択肢情報２１６０を読み込んだ後、クライアント１０９がビューワの処理（すなわち、ビューワプログラム２１３０の実行）に割り当てることのできる現在の余剰処理能力を測定するため、ベンチマークプログラム２１４０を起動する（ステップＳ２３０３）。
【００９９】
このベンチマークプログラム２１４０は、ビューワプログラム２１３０の実行時に消費する処理能力を推定しやすくするために作られたもので、比較的処理負荷の軽いプログラムが適当である。ビューワプログラム２１３０にこのベンチマークプログラム２１４０を組み込んでおき、ビューワプログラム２１３０の起動時に余剰負荷を測定するようにしてもよい。ここで、ビューワプログラム２１３０は圧縮された映像データの伸張処理のプログラムを含み、この伸張処理の負荷がビューワプログラム２１３０の中で最も重いと仮定する。ベンチマークプログラム２１４０はビューワプログラム２１３０に、予め用意した処理量が既知の圧縮映像データの伸張処理を実行させる。
【０１００】
ステップＳ２３０４で、その伸張処理に要した時間Ｔを計測する。次に、この実行時間Ｔからクライアントの余剰処理能力である処理能力Ｐを算出する（ステップＳ２３０５）。ここでは、処理能力Ｐは実行時間Ｔに逆比例すると考える。例えば、実行時間Ｔが１００ｍｓｅｃであった場合の処理能力Ｐが２と算出されると仮定すると、実行時間Ｔが５０ｍｓｅｃであった場合の処理能力Ｐは４と算出されることになる。
【０１０１】
次に、ステップＳ２３０６において、ストリーム選択肢情報２１６０の中から、処理能力がＰ以下の選択肢を抽出し、これをストリーム限定選択肢情報２１７０としてメモリ２００３に格納する。処理能力がＰ以下であれば、現在のクライアントに余剰処理能力でも、十分な映像の表示速度やフレームレートを確保できる。一例として、ストリーム選択肢情報２１６０が図１９に示されたとおりで、上記のステップＳ２３０５で算出された処理能力Ｐが４であった場合について説明する。図１９のストリーム選択肢情報２１６０を参照すると、映像配信サーバ１００より提示された選択肢としては、画像サイズ３２０ｘ２４０と１６０ｘ１２０のそれぞれについて、カメラ制御ありの場合とカメラ制御なしの場合の、４通りの候補がある。次いで、図１８のクライアントストリーム負荷データ２１５０を参照すると、処理能力（＝処理負荷）が４以下の選択肢は、画像サイズが３２０ｘ２４０でカメラ制御なしの場合、画像サイズが１６０ｘ１２０でカメラ制御ありの場合、および、同サイズでカメラ制御なしの場合、の３通りに絞られる。この３通りの候補がストリーム限定選択肢情報２１７０としてメモリ２００３に格納される。
【０１０２】
そして、上記の処理により選択肢が限定された場合には、ステップＳ２３１０で、その限定された選択肢を表示する。ステップＳ２３１１では、選択肢が限定されたか否かを判定し、限定された場合には、ステップＳ２３１２においてユーザにいずれか１つを選択させる。一方、たとえばステップＳ２３０５で算出された処理能力Ｐが小さく、選択肢が限定されなかった場合には、ステップＳ２３１３に進み終了イベントを発行する。以上によりステップＳ２２０４の処理が完了する。
【０１０３】
なお、ステップＳ２３１２の処理については、ユーザに最終的な候補を選択させるかわりに、表示可能な最高画質のストリームを自動選択するようにしてもよい。
【０１０４】
説明を図１６のフローチャートに戻す。上記したステップＳ２２０４の選択肢限定処理を終えると、ステップＳ２２０５に進み、映像要求イベントを発行し、これを映像配信サーバ１００に送信して、ステップＳ２２０６のイベントループに戻る。
【０１０５】
映像配信サーバ１００からの映像ストリーム（図３のステップＳ３３２を参照）の受信が完了し、受信完了イベントを発行すると（ステップＳ２２０７）、受信した映像ストリームを順次メモリ２００３から取り込み（ステップＳ２２０８）、その映像ストリームを表示装置２００４に表示する（ステップＳ２２０９）。その後、ステップＳ２２１１で継続映像要求イベントを発行し、ステップＳ２２０６のイベントループに戻る。
【０１０６】
ステップＳ２２１４において、映像配信サーバ１００から接続の拒否応答（図６のステップＳ６０９を参照）を受信した場合は、接続終了イベントを発行し（ステップＳ２２１２）、本マルチストリーム受信処理を終了する。
【０１０７】
以上説明した実施形態６によれば、クライアント１０９は、映像配信サーバ１００より、提供可能な映像ストリームの属性の候補の選択肢が通知されると、そのときのクライアント１０９の処理能力を推定する。そして、推定された処理能力に基づいて、上記選択肢の候補をさらに限定し、その限定された候補の選択肢を表示する。これにより、ユーザはクライアント側の処理能力に見合った属性の映像ストリームを、容易に指定することができる。
【０１０８】
（実施形態７）
本実施形態では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して選択する。
【０１０９】
以下では、基本的に実施形態３を基に、相違する点を中心に説明するが、本実施形態は実施形態４、５に対しても適用が可能である。
【０１１０】
本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図２０に示すように、実施形態２と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、ストリーム負荷データ２５０、接続情報２６０、ストリーム選択肢情報２７０の他に、優先度テーブル２８０、優先度別ストリーム負荷データ２９０が格納されている。本実施形態でも、ストリーム負荷データ２５０および接続情報２６０はそれぞれ、実施形態３と同様の構造（図８、図９を参照）を有するものとする。ただし、本実施形態では、現在の接続情報２６０の内容が図２２のようになっているとする。すなわち、図２２を参照すると分かるように、映像配信サーバ１００には現在、ビューワ（クライアント）１０９−１〜１０９−４の４台が接続されている。
【０１１１】
本実施形態における映像配信サーバ１００によるマルチストリーム作成処理は基本的に実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われる。ただし本実施形態では、ステップＳ３６１における配信制御処理が、図２１のフローチャートに従って行われる。
【０１１２】
まずステップＳ５１０１で、接続情報２６０を読み込む。また、実施形態３におけるステップＳ１００１と同様に、接続要求イベントに含まれる要求画像属性も読み込む。
【０１１３】
次に、ステップＳ５１０２で、接続情報２６０およびストリーム負荷データ２５０を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。図２２の接続情報２６０に基づき具体例を説明する。図２２の接続情報２６０を参照すると、ビューワ１０９−１から１０９−４の接続があり、それぞれ、８００ｘ６００でカメラ制御なし、１６０ｘ１２０でカメラ制御有り、６４０ｘ４８０でカメラ制御なし、８００ｘ６００でカメラ制御なし、という属性の映像ストリームを要求していることが分かる。ここで、ストリーム負荷データ２５０を参照すると、各接続の処理負荷は、２５、２、１６、２５である。よって、全体負荷Ｆは、これらの総和６８と求められる（この値の例は後ほど使用する。）。
【０１１４】
次に、ステップＳ５１０３で、サーバ処理の上限値Ｘを読み出す。上限値Ｘは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップＳ５１０４で、映像配信サーバ１００の余力Ｙを求める。余力Ｙは、上限値Ｘと全体負荷Ｆとの差分として求められる。その後、ステップＳ５１０５で、優先度別選択肢作成プログラム２３０を呼び出す。
【０１１５】
優先度別選択肢作成プログラム２３０による動作例を図２３に示す。
【０１１６】
まずステップＳ５３０１で、図２４に示すような構造の優先度テーブル２８０を読み込む。図２４の優先度テーブルには、図８のストリーム負荷データ２５０と同様に分類されたそれぞれのケースについて優先度を示す情報が記述されている。具体的には、図２４に示した例では、画像サイズ８００ｘ６００でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が０、画像サイズ６４０ｘ４８０でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が１０に設定されている。また、画像サイズ３２０ｘ２４０でカメラ制御ありの場合の優先度を示す情報が２、同サイズでカメラ制御なしの場合の優先度を示す情報が０、画像サイズ１６０ｘ１２０でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が２に設定されている。ここでは、優先度を示す情報が０のときが最も優先度が高いと考える。
【０１１７】
そして、ステップＳ５３０２で、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２４）に記述された対応する優先度を示す情報の値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。図２５は、得られた優先度別ストリーム負荷想定データ２９０の例を示す図である。図８と図２４とを重ね合わせてみれば、図２５の結果が得られることが容易に理解できよう。
【０１１８】
次に、ステップＳ５３０３で、ステップＳ５１０４で求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ２９０から読み出し、図２６に示すようなストリーム選択肢情報２７０をメモリ１０４に書き込む。ここで、上記した例の通り全体負荷Ｆが６８とし、また、上限値Ｘが９３に設定されていると仮定して具体例を示す。この場合の余力Ｙは９３−６８＝２５となる。その後、優先度別ストリーム負荷想定データ２９０から、負荷の値が２５（＝余力）以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報２７０を構成する。図２５の優先度別ストリーム負荷想定データ２９０の例では、「ｊｐｅｇ８００ｘ６００、カメラ制御なし」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御あり」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御なし」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御なし」、が抽出され、これにより図２６に示されるようなストリーム選択肢情報２７０が構成される。
【０１１９】
この例の場合、「ｊｐｅｇ６４０ｘ４８０、カメラ制御なし」および「ｊｐｅｇ６４０ｘ４８０、カメラ制御あり」のケースはそれぞれ、負荷が１６および１７で、余力（＝２５）の範囲内に収まるにもかかわらず（図８を参照）、優先度を示す情報１０が加算されたことにより選択肢から外される一方、これらより負荷の大きい「ｊｐｅｇ８００ｘ６００、カメラ制御なし」には優先度を示す情報による加算がされなかった（優先度を示す情報＝０）ので、選択肢として抽出される結果となった。
【０１２０】
このように優先度を設定することにより、処理負荷の大きい属性の映像ストリームを、処理負荷の小さい属性の映像ストリームより優先的に選択肢の候補に挙げることが可能になる。つまり、優先度の設定によって、余力内に収まる負荷の特定の属性のストリームについては選択肢に現れないように操作する。その一方で、上記特定の属性のストリームより負荷の高い属性のストリームを選択肢に入れるよう操作する。これにより、余力を、より負荷の高い属性のストリームにまわすことができる。
【０１２１】
また、優先度を設定することで、サーバ管理者が意図するストリーム種別での接続を増やす傾向を作ることができる。たとえば、ストリーム負荷は大きいが、なるべく大きなサイズでの映像を優先的に配信しようとする場合には、ストリーム負荷は小さくても小サイズのストリームに対しては優先度を下げるよう設定すればよい。
【０１２２】
なお、上記の例では、優先度を規定する値として、優先度を示す情報が０のときが最も優先度が高く、その値が大きくなるほど優先度が小さくなる値を考えた。これは、各属性の負荷に加算されることを前提に規定されたものである。一方このかわりに、優先度を、各属性の負荷に乗じられる重み付け係数として定義することも可能である。この場合には優先度の高低はその数値に応じたものとなる。
【０１２３】
説明を図２１のフローチャートに戻す。次に、ステップＳ５１０６で、ストリーム選択肢情報２７０をクライアントへ通知し、ステップＳ５１０７で、イベントを待つ。
【０１２４】
ステップＳ５１１０において、ストリーム選択肢情報２７０を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップＳ５１１１に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報２７０の選択番号などで受け取ることにしても良い。また、実施形態１，２と同様に、ここで上限値Ｘと全体負荷Ｆおよび要求された優先度別ストリーム負荷ｆから接続の可否を制御しても良い。
【０１２５】
次に、ステップＳ５１１２で、属性特定要求イベントの発行元のクライアントの情報を接続情報２６０に登録し、続くステップＳ５１１３で、映像要求イベントを発行するとともに、ステップＳ５１１４で選択肢変化イベントを発行する。
【０１２６】
また、ステップＳ５１２０において、ストリーム選択肢情報２７０を渡したクライアントから接続終了イベントを受け取った場合、または、ステップＳ５１３０において、ストリーム選択肢情報２７０をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。
【０１２７】
（実施形態８）
本実施形態では、接続要求に適合した映像ストリームの配信を行うには処理能力の余力が足りない場合、その優先度に応じて余力を作り出し、これにより、その要求に係る配信を実現させる。
【０１２８】
本実施形態に係る映像配信システムの構成は実施形態７と同様である。すなわち、本実施形態に係る映像配信システム構成は図１に示されたもので、また、メモリ１０４に格納される内容は、図２０に示されたとおりである。
【０１２９】
また、本実施形態におけるマルチストリーム作成処理も実施形態７と同様、基本的には実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われ、ステップＳ３６１における配信制御処理は、図２１のフローチャートに従って行われる。ただし本実施形態では、ステップＳ５１０５における優先度別選択肢作成処理は、図２３のフローチャートのかわりに、図２７のフローチャートに従って行われる。
【０１３０】
まずステップＳ５７０１で、図２４に示したような優先度テーブル２８０および、ステップＳ５１０１で読み込んだ要求画像属性を読み出す。次のステップＳ５７０２では、実施形態７におけるステップＳ５３０２と同様に、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２４）に記述された対応する優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。次のステップＳ５７０３では、ステップＳ５１０４で求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ２９０から読み出し、図２６に示すようなストリーム選択肢情報２７０を作成する。
【０１３１】
次に、ステップＳ５７０４において、ステップＳ５７０１で読み込んだ要求画像属性が、ステップＳ５７０３で作成されたストリーム選択肢情報２７０に含まれているかどうかを判定する。要求画像属性がストリーム選択肢情報２７０に含まれている場合には、この優先度別選択肢作成処理を抜ける。一方、要求画像属性がストリーム選択肢情報２７０に含まれていない場合はステップＳ５７０５に進む。
【０１３２】
ステップＳ５７０５では、優先度テーブル２８０を参照して要求画像属性の優先度を確認するとともに、接続情報２６０および優先度テーブル２８０を参照して要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されているかどうかを調べる。ここで要求画像属性の優先度よりも低い優先度のストリーム配信のための接続は現在のところ確立されていない場合には、そのままこの優先度別選択肢作成処理を抜ける。一方、要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されていた場合には、ステップＳ５７０６に進み、当該接続先のクライアントに接続拒否イベントを発行し、その後、ステップＳ５７０７において、その接続を拒否したクライアントに係る情報を接続情報２６０から削除する。
【０１３３】
このステップＳ５７０５、Ｓ５７０６の具体例を示す。処理対象の接続要求イベントを発行したクライアントが１０９−５であり、現在、別の４つのクライアント（１０９−１〜４）が接続されており、そのときの接続情報２６０が図２２に示すとおりであると仮定する。また、ステップＳ５７０１で読み込んだ接続要求イベントに含まれる要求画像属性が「ｊｐｅｇ８００ｘ６００、カメラ制御なし」であったとする。
【０１３４】
まず、優先度テーブル２８０を参照して要求画像属性の優先度を確認する。図２４の優先度テーブル２８０を参照すると、要求画像属性「ｊｐｅｇ８００ｘ６００、カメラ制御なし」の優先度を示す値は「０」に設定されており、最も高い優先度に設定されていることがわかる。
【０１３５】
次に、接続情報２６０および優先度テーブル２８０を参照して要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係る接続が確立されているかどうかを調べる。ここで、図２２の優先度テーブル２６０を調べてみると、クライアント１０９−１と１０９−４への映像ストリームの属性は「ｊｐｅｇ８００ｘ６００、カメラ制御なし」であり、その優先度を示す値は「０」である。一方、クライアント１０９−２への映像ストリームの属性は「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」で、図２４の優先度テーブル２８０より、その優先度を示す値は「２」に設定されている。また、クライアント１０９−３への映像ストリームの属性は「ｊｐｅｇ６４０ｘ４８０、カメラ制御なし」で、図２４の優先度テーブル２８０より、その優先度を示す値は「１０」に設定されている。そうすると、このクライアント１０９−２および１０９−３の接続が、要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係るものであることが判明する。
【０１３６】
ステップＳ５７０６では、この２つのクライアント１０９−２および１０９−３の両方に直ちに接続拒否イベントを発行してもよいが、ここでは、これらのうち優先度別負荷想定の値（図２５を参照）が最も高いクライアント（すなわち、１０９−３）にのみ接続拒否イベントを発行することにする。これによりクライアント１０９−３の接続が解除された結果、余力が増えることになる。それでもなお要求画像属性の映像ストリームの作成には不足である場合には、続いてクライアント１０９−２に接続拒否イベントを発行するようにすればよいであろう。
【０１３７】
ステップＳ５７０５，Ｓ５７０６の具体例は以上のとおりである。
【０１３８】
次のステップＳ５７０８では、ステップＳ５７０３と同様にして再度ストリーム選択肢情報２７０を作成する。この場合には、ステップＳ５７０７での削除により、処理対象の接続要求イベントを発行したクライアントの要求画像属性がストリーム選択肢情報２７０に含まれることになる。
【０１３９】
以上で、優先度別選択肢作成処理が終了する。
【０１４０】
以上説明した優先度別選択肢作成処理によれば、優先度の高い属性のストリームへの接続要求を受けた場合、余力が足りないときには、優先度の低い属性の映像ストリームの配信を停止することで余力をつくり、これにより上記の優先度の高いストリームの配信を実行させることができる。
【０１４１】
また、優先度の低いストリームの配信先であるクライアントの接続は解除せず（ステップＳ５７０６、Ｓ５７０７を実行しない）、ステップＳ５７０８では、その優先度の低いクライアントの接続を解除したと仮定した場合における余力Ｙを計算し、その余力Ｙから、優先度の高い要求画像属性のストリームにかかる負荷を減算した上で、再度選択肢を作成し直し、これを上記の優先度の低いストリームに係るクライアントに提示するようにしてもよい。この場合には、優先度の低いストリームの配信に係るクライアントの接続を切断せず、別の属性のストリームに切り換えて配信を続けることが可能になる。
【０１４２】
（実施形態９）
上述した実施形態７，８では、映像ストリームの各属性に優先度の情報が設定されたが、本実施形態では、クライアントに優先度が設定され、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する。
【０１４３】
本実施形態に係る映像配信システムの構成は実施形態８と同様である。すなわち、本実施形態に係る映像配信システム構成は図１に示されたもので、また、メモリ１０４に格納される内容は、図２０に示されたとおりである。
【０１４４】
また、本実施形態におけるマルチストリーム作成処理も、基本的には実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われ、ステップＳ３６１における配信制御処理は、図２１のフローチャートに従って行われる。また、実施形態８と同様で、ステップＳ５１０５における優先度別選択肢作成処理は、図２３のフローチャートではなく、図２７のフローチャートに従って行われる。
【０１４５】
ただし、優先度テーブル２８０のデータ構造は実施形態８におけるそれ（図２４）とは異なっている。図２８に、本実施形態における優先度テーブル２８０の構造例を示す。実施形態８における優先度は、図２４のとおり、映像ストリームの属性に対して設定されたが、本実施形態における優先度は、図２８に示すように、クライアント（ビューワ）に対して設定される。
【０１４６】
この優先度を示す設定値は映像配信サーバ１００において、管理者の操作に従って変更が可能であることはもちろんであるが、クライアントからの指示に応じて当該クライアントの優先度を示す設定値を変更することも可能である。
【０１４７】
例えば、各クライアントは、映像配信サーバ１００に発行する接続要求イベントに、要求映像属性の他、そのクライアントの優先度を示す情報を含めることが可能である。映像配信サーバ１００はこの接続要求イベントを受け取ると、それに含まれている優先度を示す情報でもって優先度テーブル２８０の該当部分を更新することになる。
【０１４８】
これに関連して、本実施形態において実施形態８とは相違する動作について説明する。
【０１４９】
まず、図２１の配信制御処理について。ステップＳ５１０１では、接続情報２６０を読み込むほか、接続要求イベントに含まれる要求画像属性を読み込む。さらに、接続要求イベントにそのクライアントの優先度の情報も含まれている場合にはその情報も読み込む。
【０１５０】
次に、図２７の優先度別選択肢作成処理について。ステップＳ５７０１では、図２８に示したような優先度テーブル２８０および、ステップＳ５１０１で読み込んだ要求画像属性ならびにそのクライアントの優先度の情報を読み出す。ここでクライアントの優先度の情報が読み出された場合には、その情報でもって優先度テーブル２８０の該当部分を更新する。
【０１５１】
ステップＳ５７０２では、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２８）に記述された当該クライアントの優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。この場合の優先度別ストリーム負荷想定データ２９０の例を図２９に示す。
【０１５２】
なお、クライアント側で優先度の指定がなされなかったために接続要求イベントにそのクライアントの優先度の情報が含まれていなかった場合で、かつ、優先度テーブル２８０にそのクライアントが登録されていない場合には、映像配信サーバ１００で予め設定されたデフォルト値（例えば２０）が用いられる。
【０１５３】
以上、実施形態８との相違点を説明した。これ以外は実施形態８と同様な処理が行われる。
【０１５４】
以上説明した実施形態９によれば、映像配信サーバ１００に接続が可能な（すなわち、映像配信サーバ１００より映像ストリームの配信を受けることが可能な）クライアントに優先度が設定され、この優先度および要求画像属性に基づいて、映像配信サーバ１００の余力の範囲内で提供可能な属性の映像ストリームの選択肢が作成される。これにより、接続を要求するクライアントによって提示される選択肢の内容が異なるようになる。このため、優先度が高く設定されたクライアントほど、処理負荷の大きい属性の映像ストリームまでもが選択肢に含まれるようになり、サーバの能力の範囲内で、より多くの能力が分配されるようになる。
【０１５５】
なお、上記の例では、クライアントに優先度が設定されたが、同様の考え方で、ユーザに優先度を設定し、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する、というバリエーションを考えることもできる。たとえば、映像配信サーバ１００が、クライアントから接続要求イベントを受け取ったことに応答してそのクライアントに対しユーザ認証処理を実行するように構成しておき、このユーザ認証を経てユーザの優先度が設定されるようにすればよい。
【０１５６】
（実施形態１０）
実施形態３では、図１１に示したような配信制御処理のうち、とりわけステップＳ１００１〜Ｓ１０１０の処理によって、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。
【０１５７】
また、実施形態７では、図２１に示した配信制御処理のうち、とりわけステップＳ５１０１〜Ｓ５１０６の処理によって、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。
【０１５８】
これらの処理は、映像配信サーバ１００において選択肢を作成するための評価工程と考えることができる。
【０１５９】
また、クライアント側の処理例について説明した実施形態６では、図１６に示したマルチストリーム受信処理では、ステップＳ２２０４において選択肢限定処理が行われる。この選択肢限定処理においては、とりわけ図１７に示すステップＳ２３０１〜Ｓ２３０６の処理によって、限定された選択肢が求められた。そして、図１６のステップＳ２２０５で映像要求イベントが発行された。これらは、受信ストリームを選択的に要求するための選択要求工程と考えることができる。
【０１６０】
本実施形態では、上記したような評価工程や選択要求工程を実現する手段をそれぞれ独立した処理モジュールとして構成することより、選択肢の評価基準や受信ストリームの選択基準に自由度を持たせることを容易にする。
【０１６１】
本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。また、クライアント１０９の構成は実施形態６で説明した図１４の構成と同様である。ただし、クライアント１０９のメモリ２００３に格納される内容は、図３０に示すとおりである。これは実施形態６に係る図１５とほぼ同様であるが、対照すると分かるように、本実施形態に係る図３０にはベンチマークプログラム２１４０のかわりに、選択要求プログラム２１４５が含まれている。
【０１６２】
他方、映像配信サーバ１００のメモリ１０４に格納される内容は、図３１に示すとおりである。これは実施形態７に係る図２０とほぼ同様であるが、対照すると分かるように、本実施形態に係る図３１には、選択肢評価プログラム２４０が追加的に含まれている。
【０１６３】
図３２は、本実施形態における映像配信サーバ１００による選択肢評価処理を示すフローチャートである。このフローチャートに対応するプログラムが選択肢評価プログラム２４０である。
【０１６４】
まずステップＳ６１０１で、評価に必要な情報（接続情報２６０、接続要求イベントから抽出される要求画像属性、上限値Ｘ等を含む。）を読み込む。次にステップＳ６１０２で、読み込んだ情報を基に、評価関数Ｓにより選択肢が求められる。
【０１６５】
たとえば、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの候補を選択肢としてクライアントに通知するようにした実施形態３についていえば、評価関数Ｓは、図１１に示したステップＳ１００２（全体負荷Ｆの計算）、ステップＳ１００８（余力Ｙの計算）、およびステップＳ１００９（選択肢の生成）の各処理を実現する関数である。
【０１６６】
また、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して求め、それを選択肢としてクライアントに通知するようにした実施形態７についていえば、評価関数Ｓは、図２１に示したステップＳ５１０２（全体負荷Ｆの計算）、ステップＳ５１０４（余力Ｙの計算）、およびステップＳ５１０５（優先度別選択肢作成処理）の各処理に実現する関数である。
【０１６７】
選択肢評価プログラム２４０は配信制御プログラム２２０から独立したモジュールであるから、これが配信制御プログラム２２０に組み込まれている場合に比べれば、上記のように評価関数Ｓを任意に変更することが大幅に容易になる。これに伴い、選択肢評価プログラム２４０がこのような評価関数Ｓを有する以上、評価関数Ｓによって実現される処理部分については、もはや配信制御プログラム２２０自体が有している必要はない。
【０１６８】
そして、ステップＳ６１０３で、その求められた選択肢の情報などを接続要求イベントの発行元のクライアントに通知する。
【０１６９】
図３３は、本実施形態におけるクライアント１０９による選択要求処理を示すフローチャートである。このフローチャートに対応するプログラムが選択要求プログラム２１４５であり、ＣＰＵ２００２によって実行される。
【０１７０】
まず、ステップＳ６２０１で、接続要求イベントが発行されているかどうかを判断する。ここで接続要求イベントが発行されていなければステップＳ６２０２に進み、実施形態６のマルチストリーム受信プログラム２１００によるステップＳ２２０２と同様の処理で、接続要求イベントを発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。
【０１７１】
一方、ステップＳ６２０１において接続要求イベントが発行されていない場合にはステップＳ６２０３に進み、評価関数Ｇによって、要求される映像選択が行われる。たとえば、実施形態６についていえば、評価関数Ｇは、選択肢限定プログラム２１２０を呼び出す処理に相当する。
【０１７２】
次に、ステップＳ６２０４で、評価関数Ｇの結果に基づき映像要求が可能かどうかを判断する。映像要求が可能でないと判断した場合にはステップＳ６２０５に進み、評価関数Ｇの結果に応じた接続要求を決定し、続くステップＳ６２０２で接続要求イベントを送信発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。この際、評価関数Ｇの結果によっては接続要求自体をやめるようにしてもよい。一方、ステップＳ６２０４において評価関数Ｇの結果に基づき映像要求が可能と判断した場合にはステップＳ６２０６に進み、実施形態６のマルチストリーム受信プログラム２１００によるステップＳ２２０５と同様に映像要求イベントを発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。
【０１７３】
本実施形態は、映像配信サーバ１００において、選択肢の生成に係る処理部分を配信制御プログラム２２０から独立したモジュールで構成したことにその特徴がある。これにより、任意の評価関数Ｓを容易に記述することができる。
【０１７４】
また、クライアント１０９においても同様に、接続要求イベントおよび映像要求イベントの発行に係る選択要求処理部分をストリーム受信プログラム２１００から独立したモジュールで構成した。これにより、任意の評価関数Ｇを容易に記述することができる。
【０１７５】
（実施形態１１）
以下では、実施形態１０で説明した評価関数ＳまたはＧのバリエーションについて説明する。
【０１７６】
例えば、マルチストリーム配信を対価の支払いに応じた優先度の更新を実現することができる。
【０１７７】
まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４５によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する対価（金額）情報とを接続要求イベントに含めてこれをステップＳ６２０２で発行する。
【０１７８】
これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に対して支払われる対価の情報が読み込まれる。
【０１７９】
ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同等である。ただし本実施形態は、読み込んだ対価に応じて当該接続要求に係る優先度を更新する処理を含む（優先度テーブル２８０が更新される。）。例えば対価１００円につき優先度を１上げることができる。具体例を示すと、例えば優先度１０のビューワのユーザが１００円支払うことで優先度９とすることができる。このようにユーザは対価を払うことで優先度を上げて接続することができる。
【０１８０】
また、例えば、接続回数に応じたいわゆるポイント加算による優先度の更新を実現することができる。
【０１８１】
まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４５によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報を接続要求イベントに含めてこれをステップＳ６２０２で発行する。
【０１８２】
これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に対するユーザ認証情報が読み込まれる。
【０１８３】
ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同様である。ただし本実施形態は、ユーザ別にその接続回数に応じたポイントを管理し、ポイント数に応じて優先度を更新する（優先度テーブル２８０が更新される。）。例えば、ユーザＡのポイント累計が１００ポイントとなった時点でユーザＡの優先度を１上げるようにする。具体例を示すと、例えば優先度１０のビューワのユーザが１００回の接続を行うことで優先度９とすることができる。このようにユーザは接続を重ねることで優先度を上げて接続することができる。
【０１８４】
また、例えば、マルチストリーム配信を競り落とすことによる優先度の更新を実現することができる。
【０１８５】
まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４０によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する入札金額（オークション）情報を接続要求イベントに含めてこれをステップＳ６２０２で発行する。
【０１８６】
これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に係る入札金額の情報が読み込まれる。
【０１８７】
ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同様である。ただし本実施形態は、読み込んだ入札金額に応じて当該接続要求に係る優先度を更新する処理を含む（優先度テーブル２８０が更新される。）例えば、複数のユーザＡ、Ｂ、Ｃがそれぞれ、１００円、２００円、３００円で接続要求した場合、Ｃの優先度を０、Ａ、Ｂの優先度を１００とすることで、実質的にユーザＣのみを優先的に接続させるようなことができる。
【０１８８】
また、例えば、映像配信サーバ１００の余力がなく接続をあきらめた場合に、後に使えるポイント、クーポンなどを発行してもらうことに伴う優先度の更新を実現することができる。
【０１８９】
まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４０のステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、特定のストリーム接続の要求とを接続要求イベントに含めてこれをステップＳ６２０２で発行する。
【０１９０】
これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、ユーザ情報とストリーム属性が読み込まれる。
【０１９１】
ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同等である。ただし本実施形態は、受け取った特定のストリームへの接続要求が実現できない際（選択肢に含ませることができない場合）に、ユーザに対して所定数のポイントを発行し、一定期間内に同一のユーザが接続してきた際にこのポイント情報に応じて優先度を更新する処理を含む（優先度テーブル２８０が更新される。）。例えば、１ポイントにつき優先度を１上げることができる。これにより、当初の接続が拒否されたユーザが報われるかたちで接続を実現することができる。
【０１９２】
以上のように、対価、接続数、ポイントなどによって、特定の優先度を上げることについて述べたが、もちろん、逆に、該当クライアント（またはユーザ）以外のクライアント（またはユーザ）の優先度を下げることによっても同様の効果を得ることができる。この場合、図２７の優先度別選択肢作成プログラム２３０によるステップＳ５７０５で述べたように、減算されたユーザの方が接続拒否対象となる場合が出てくることとなり、実質的に他のユーザの優先度を上げることが実現できる。なお、このステップＳ５７０６で接続拒否する場合には、接続拒否の対象となった優先度を初期値に戻しておくこともできる。初期値に戻さない場合は、ユーザが何らかの対価、ポイントなどを払うことで元に戻していくことが実現されるし、初期値に戻す場合は初期接続において皆平等ということが実現される。
【０１９３】
（実施形態１２）
評価関数ＳおよびＧに関して、更に別のバリエーションを説明する。
【０１９４】
図３４は、本実施形態におけるストリーム負荷データの例を示している。このデータ構造は図８に示したストリーム負荷データと同様であるが、画像サイズ６４０ｘ４８０のバリエーションとして、３２０ｘ２４０の映像を拡大することにより６４０ｘ４８０とした映像ストリームが加えられている。同図によれば、通常の６４０ｘ４８０の映像ストリームについては、カメラ制御ありのときの負荷が１７、カメラ制御なしのときの負荷が１６であるのに対し、３２０ｘ２４０の映像を拡大して６４０ｘ４８０とした映像ストリームについては、カメラ制御ありのときの負荷が９、カメラ制御なしのときの負荷が８となっており、負荷が大きく低減されることがわかる。なお、これは画像サイズ６４０ｘ４８０の映像ストリームについての一例であり、他のサイズの映像ストリームについても同様な設定をなしうる。ただしここでは、それらの記述を省略した。
【０１９５】
さて、処理対象の接続要求イベントを発行したクライアントが１０９−５であり、現在、別の４つのクライアント（１０９−１〜４）が接続されており、そのときの接続情報２６０が図２２に示すとおりであると仮定する。また、上限値Ｘは７０に設定されている。図２２の接続情報２６０を参照すると、クライアント１０９−１〜４はそれぞれ、
（１）８００ｘ６００、制御なし
（２）１６０ｘ１２０、制御あり
（３）６４０ｘ４８０、制御なし
（４）８００ｘ６００、制御なし
の画像属性を持つ映像を要求していることがわかる。図３４のストリーム負荷データ２５０を参照すると、それぞれの要求にかかる負荷は、２５，２，１６，２５である。そして、全体負荷ＦはＦ＝２５＋２＋１６＋２５＝６８である。ここで、クライアント１０９−５が「６４０ｘ４８０、制御あり」の接続要求を発行したとする。このクライアント１０９−５の要求にかかる負荷ｆは、図３４のストリーム負荷データ２５０を参照すると、ｆ＝１７である。そうすると、この場合は、Ｆ＋ｆ＝６８＋１７＝８５となり、上限値Ｘ＝７０を超えており、このままではクライアント１０９−５の要求どおりの接続は拒否せざるを得ない。
【０１９６】
そこで、本実施形態では、図３４のストリーム負荷データ２５０に基づいて、図１１のステップＳ１００９のような処理いったん作成される選択肢から、通常の「６４０ｘ４８０、制御なし」を外し、その代替として、３２０ｘ２４０の拡大バージョンである「６４０ｘ４８０、制御なし」を加える。さらに、クライアント１０９−５が要求している「６４０ｘ４８０、制御あり」についても、通常の「６４０ｘ４８０、制御なし」ではなく３２０ｘ２４０の拡大バージョンである「６４０ｘ４８０、制御なし」を代用する。これが実現すれば、クライアント１０９−５の接続を確立した場合の全体負荷Ｆ＋ｆはＦ＋ｆ＝２５＋２＋８＋２５＋９＝６９となり、上限値７０を越えずに全て接続することが可能となる。このような調整の後、接続要求選択肢変化イベントを発行するようにすればよい。
【０１９７】
そこで、本実施形態では次のような処理を行う。まず、現在の全体負荷Ｆ（クライアント１０９−１〜４にかかる負荷）と処理対象の接続要求に対する負荷（クライアント１０９−５にかかる負荷）とを推定し、両者の負荷の合計（すなわち、クライアント１０９−５の接続を確立した場合の全体負荷）が上限値Ｘを超えるか否かを判定する。ここで上限値Ｘを超える場合には、ストリーム負荷データに基づいて、いったん抽出した候補の少なくともいずれかを、近似的な属性（要求よりも小さなサイズの画像を拡大させたもの）を有する負荷の小さい別の候補によって代替することを、該当する他のクライアントおよび／またはクライアント１０９−５に求める。この求めに他のクライアントおよび／またはクライアント１０９−５が応じ、これにより、クライアント１０９−５の接続を確立した場合の全体負荷が上限値Ｘを下回ることになれば、クライアントからの当初の要求に近い接続を実現できることになる。
【０１９８】
また、クライアント側でも、図３３のステップＳ６２０３に示したような評価関数Ｇによって、例えば「６４０ｘ４８０、制御なし」要求時に、それが選択不可の場合には、３２０ｘ２４０を拡大したバージョンの「６４０ｘ４８０、制御なし」で代用して、ステップＳ６２０５で再度選択させるという実施形態も、同様に可能である。
【０１９９】
（実施形態１３）
上述の各実施形態では、映像配信サーバ１００の負荷は、各ケースごとの負荷があらかじめ記述されたテーブル（ストリーム負荷データ）に基づいて推定された。この場合、クライアントの接続状態によっては推定と実際とで差が開き、実際にはサーバの処理能力に余裕がある場合であってもクライアントの接続を拒否してしまったり、データ量の少ないストリームの選択肢しか生成されなかったりする場合がある。
【０２００】
そこで、本実施形態では映像配信サーバ１００のＣＰＵの負荷状態を実際に測定することで、この実測値を用いてサーバの能力をより無駄なく使用するようにする。
【０２０１】
本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図３５に示すように、マルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、接続情報２６０に加え、ＣＰＵ負荷測定プログラム１３１０および、そのＣＰＵ負荷測定プログラム１３１０の実行により生成されるＣＰＵ負荷データ１３２０が格納されている。ＣＰＵ負荷データ１３２０は、所定のデータ送信レート（例えば、１ｋｂｐｓ）あたりのデータ配信にかかるＣＰＵ負荷の指標を表す。
【０２０２】
図３６はＣＰＵ負荷データ１３２０の構造例を示す図である。３４０１はシステムの初期状態でのＣＰＵの処理能力をあらわす値（無負荷データ）、３４０５は８００ｘ６００のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０２は６４０ｘ４８０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０３は３２０ｘ２４０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０４は１６０ｘ１２０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値である。３４０６は配信時にかかるＣＰＵの必要処理能力を示す値である。
【０２０３】
また、本実施形態における接続情報２６０は、図３９に示すようなデータ構造を有する。本実施形態における接続情報２６０には、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズ、ならびにそのクライアントの接続に係る画像送信レートが記述されている。
【０２０４】
図３７は、本実施形態におけるマルチストリーム作成処理を示すフローチャートである。このフローチャートは図３とほぼ同様であるが、相違する点は、本実施形態では、ステップＳ３０１とＳ３０２との間で、ステップＳ１３０１としてＣＰＵ負荷測定プログラム１３１０が起動され点と、ステップＳ３６１における配信制御処理が、図３８のフローチャートに従って行われる点である。
【０２０５】
ステップＳ１３０１において、ＣＰＵ測定プログラム１３１０が起動すると、まず、圧縮処理も動いておらずクライアントも接続されない初期状態でのＣＰＵ負荷が測定される。ここでは、一定時間内に特定の処理を行った回数を基本としてＣＰＵの処理能力が測定され、得られた値がＣＰＵの処理能力の上限値データ（無負荷データ）３４０１としてメモリ１０４上に保存される。
【０２０６】
次に圧縮処理にかかるＣＰＵ負荷を測定するために、圧縮処理が開始される。このとき、画像サイズ毎のＣＰＵ負荷が無負荷状態の場合と同様の方法で測定される。これにより１６０ｘ１２０、３２０ｘ２４０、６４０ｘ４８０、８００ｘ６００の４種類のサイズについて圧縮処理で必要とされるＣＰＵの負荷がそれぞれ測定されて、圧縮負荷基準値データ３４０４、３４０３、３４０２、３４０５としてそれぞれメモリ１０４上に保存される。
【０２０７】
次に、ステップＳ３６１における配信制御処理を、図３８のフローチャートを用いて説明する。
【０２０８】
まず、ステップＳ３３０１で、接続要求イベントに含まれる要求画像属性を読み込み、ステップＳ３３０２で、図３９に示したような接続情報２６０を読み込む。
【０２０９】
次に、ステップＳ３３０３で、接続情報２６０の各接続ごとに送信を行う画像データサイズとＣＰＵ負荷データ２５０を掛け合わせた負荷データ、さらに要求画像の属性毎の圧縮にかかるＣＰＵ負荷データを加算していくことで全体負荷Ｆ３０が総和として求められる。
【０２１０】
例えば、図３９に示した接続情報２６０の場合、クライアント（ビューワ）１０９−１と１０９−２の接続があり、それぞれ６４０ｘ４８０と１６０ｘ１２０の画像で、画像送信レート３０の属性を持つ映像を要求していることがわかる。ここで、６４０ｘ４８０の画像データサイズをＤ３００１ｋｂｙｔｅ、１６０ｘ１２０の画像データサイズをＤ３００３ｋｂｙｔｅ、単位送信レートあたりのＣＰＵの配信負荷データ（３４０６）Ｆ３００６、６４０ｘ４８０のデータ圧縮にかかる負荷データ（３４０２）をＦ３４０２、１６０ｘ１２０のデータ圧縮にかかる負荷データ（３４０４）をＦ３４０４、とすると、全体負荷Ｆ３０は、
Ｆ３０＝Ｄ３００１×８×Ｆ３００６×３０
＋Ｄ３００３×８×Ｆ３００６×３０
＋Ｆ３４０２＋Ｆ３４０４
となる。
【０２１１】
次に、ステップＳ３３０４で、今回要求されている属性に対する負荷ｆ３０を同様の方法で求める。例えば、３２０ｘ２４０の画像属性を持つ画像が要求されている場合、画像サイズをＤ３００２ｂｙｔｅ、３２０ｘ２４０のデータ圧縮にかかる負荷データ（３４０３）をＦ３４０３、とすると、
ｆ３０＝Ｄ３００２×８×Ｆ３００６×３０＋Ｆ３４０３
となる。
【０２１２】
ステップＳ３３０５で、はじめに実測された無負荷データすなわち上限値（３４０１）をＸ３０として読み込み、ステップＳ３３０６で、このＸ３０とＦ３０＋ｆ３０と比較する。
【０２１３】
比較の結果、Ｘ３０がＦ３０＋ｆ３０より大きい場合には、今回要求されている接続を許可してもサーバの処理の上限を超えることはない。そこでこの場合には、ステップＳ３３０７に進み、要求されている接続を接続情報２６０に追加登録してメモリ１０４に保存する。その後、ステップＳ３３０８で映像要求イベントを発生して、この配信制御処理を終了する。
【０２１４】
一方、ステップＳ３３０６の比較の結果、Ｘ３０がＦ３０＋ｆ３０以下である場合には、今回要求されている接続を許可するとサーバの処理能力の上限を超えてしまう。そこでこの場合には、ステップＳ３３０９で、接続要求に対する拒否応答を返し、その後この配信制御制御処理を終了する。
【０２１５】
ここで、要求されている接続の画像サイズがすでに配信を行っている接続と同一の画像サイズである場合、画像圧縮にかかるＣＰＵ負荷をさらに追加する必要はない。例えば、すでに配信を行っている１６０ｘ１２０の画像サイズを持つ画像が要求されている場合、画像サイズをＤ３００３ｂｙｔｅとし、画像送信レートを３０とすると、
ｆ３０＝Ｄ３００２×８×Ｆ３００６×３０
となる。
【０２１６】
また、複数のネットワークインターフェースを持つシステムの場合、例えば有線ＬＡＮ接続と無線ＬＡＮ接続、モデム接続ではそれぞれ、データ配信にかかるＣＰＵの負荷に大きな違いがある。このような場合、それぞれのインターフェース毎に配送負荷情報を持つことでより正確なＣＰＵの負荷状況を知ることが可能となる。
【０２１７】
本実施形態では特定のデータ送信レートにかかるＣＰＵの負荷データを一定のものとして扱ったが、実際に送信を行い、ＣＰＵの負荷データを測定することでより正確なＣＰＵに対する負荷状況を求めることでより好適なマルチストリーム配送を行うこともできる。
【０２１８】
以上のようにすることで、映像配信システムの処理能力の上限値以下で、マルチストリーム配信が可能となる。
【０２１９】
（他の実施形態）
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【０２２０】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。
【０２２１】
従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。
【０２２２】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０２２３】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。
【０２２４】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０２２５】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０２２６】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０２２７】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０２２８】
【図１】図１は、本発明の実施形態に係る映像配信システムの構成図である。
【図２】図２は、実施形態１における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図３】図３は、実施形態１における映像配信サーバによるマルチストリーム作成処理を示すフローチャートである。
【図４】図４は、実施形態１におけるストリーム負荷データの構造例を示す図である。
【図５】図５は、実施形態１における接続情報の構造例を示す図である。
【図６】図６は、実施形態１における配信制御処理を示すフロチャートである。
【図７】図７は、実施形態２における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図８】図８は、実施形態２におけるストリーム負荷データの構造例を示す図である。
【図９】図９は、実施形態１における接続情報の構造例を示す図である。
【図１０】図１０は、実施形態３における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図１１】図１１は、実施形態３における配信制御処理を示すフローチャートである。
【図１２】図１２は、実施形態３におけるストリーム選択肢情報の構造例を示す図である。
【図１３】図１３は、実施形態４におけるマルチストリーム作成処理を示すフローチャートである。
【図１４】図１４は、本発明の実施形態におけるビューワ（クライアント）の構成示す図である。
【図１５】図１５は、実施形態６におけるクライアントのメモリに格納されるプログラムおよびデータを示す図である。
【図１６】図１６は、実施形態６におけるマルチストリーム受信処理を示すフローチャートである。
【図１７】図１７は、実施形態６における選択肢限定処理を示すフローチャートである。
【図１８】図１８は、実施形態６におけるクライアントストリーム負荷データの構造例を示す図である。
【図１９】図１９は、実施形態６におけるストリーム選択肢情報の構造例を示す図である。
【図２０】図２０は、実施形態７における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図２１】図２１は、実施形態７における配信制御処理を示すフロチャートである。
【図２２】図２２は、実施形態７における接続情報の例を示す図である。
【図２３】図２３は、実施形態７における優先度別選択肢作成処理を示すフロチャートである。
【図２４】図２４は、実施形態７における優先度テーブルの構造例を示す図である。
【図２５】図２５は、実施形態７における優先度別ストリーム負荷想定データの例を示す図である。
【図２６】図２６は、実施形態７におけるストリーム選択肢情報の例を示す図である。
【図２７】図２７は、実施形態８における優先度別選択肢作成処理を示すフロチャートである。
【図２８】図２８は、実施形態９における優先度テーブルの構造例を示す図である。
【図２９】図２９は、実施形態９における優先度別ストリーム負荷想定データの例を示す図である。
【図３０】図３０は、実施形態１０におけるクライアントのメモリに格納されるプログラムおよびデータを示す図である。
【図３１】図３１は、実施形態１０における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図３２】図３２は、実施形態１０における映像配信サーバによる選択肢評価処理を示すフローチャートである。
【図３３】図３３は、実施形態１０におけるクライアントによる選択要求処理を示すフローチャートである。
【図３４】図３４は、実施形態１２におけるストリーム負荷データの例を示す図である。
【図３５】図３５は、実施形態１３における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。
【図３６】図３６は、実施形態１３におけるＣＰＵ負荷データの構造例を示す図である。
【図３７】図３７は、実施形態１３におけるマルチストリーム作成処理を示すフローチャートである。
【図３８】図３８は、実施形態１３における配信制御処理を示すフローチャートである。
【図３９】図３９は、実施形態１３における接続情報の構造例を示す図である。
【図１】
2005318414.tif 000003
【図２】
2005318414.tif 000004
【図３】
2005318414.tif 000005
【図４】
2005318414.tif 000006
【図５】
2005318414.tif 000007
【図６】
2005318414.tif 000008
【図７】
2005318414.tif 000009
【図８】
2005318414.tif 000010
【図９】
2005318414.tif 000011
【図１０】
2005318414.tif 000012
【図１１】
2005318414.tif 000013
【図１２】
2005318414.tif 000014
【図１３】
2005318414.tif 000015
【図１４】
2005318414.tif 000016
【図１５】
2005318414.tif 000017
【図１６】
2005318414.tif 000018
【図１７】
2005318414.tif 000019
【図１８】
2005318414.tif 000020
【図１９】
2005318414.tif 000021
【図２０】
2005318414.tif 000022
【図２１】
2005318414.tif 000023
【図２２】
2005318414.tif 000024
【図２３】
2005318414.tif 000025
【図２４】
2005318414.tif 000026
【図２５】
2005318414.tif 000027
【図２６】
2005318414.tif 000028
【図２７】
2005318414.tif 000029
【図２８】
2005318414.tif 000030
【図２９】
2005318414.tif 000031
【図３０】
2005318414.tif 000032
【図３１】
2005318414.tif 000033
【図３２】
2005318414.tif 000034
【図３３】
2005318414.tif 000035
【図３４】
2005318414.tif 000036
【図３５】
2005318414.tif 000037
【図３６】
2005318414.tif 000038
【図３７】
2005318414.tif 000039
【図３８】
2005318414.tif 000040
【図３９】
2005318414.tif 000041