JP4347131B2 - 映像配信装置および方法 - Google Patents

Description

本発明は、映像配信システムに関し、特に、クライアントからの要求に応じた属性の映像ストリームを配信する映像配信システムにおける映像ストリームの配信を制御する技術に関する。

近年のストリーミング技術の発達により、サーバから配信される映像をクライアントで閲覧することが一般的になってきている。その際には、クライアントの要求する各種の属性（符号化／復号化、画質、ビットレートなど）に応じて、ストリームが選択されたり、画像変換などがされて、配信されている。

また、ＱｏＳなどの観点から、サーバ−クライアント間での配信データの制御も行われている（例えば特許文献１を参照。）
この他、組み込み機器型のカメラサーバの映像配信システムもあり、ユーザの要求によってカメラ制御などを行うことで所望する映像ストリームを得ることができる（例えば特許文献２を参照。）。

映像の配信制御の典型例は次のようなものである。たとえば、映像配信を行うサーバ（映像配信サーバ）は、複数のクライアントに同時に接続されて、それぞれのクライアントから映像ストリームの配信が要求される。ここで同時に映像配信を行うクライアント数が増えるほど映像配信サーバにかかる処理負荷は増大していく。そして、この処理負荷が映像配信サーバの処理能力を超えてしまうと全体のパフォーマンスが落ち、円滑なストリーミングが妨げられることになる。そこで従来は、同時に接続されるクライアントの数に制限を設け、その制限いっぱいの数のクライアントが接続されている状態で更に別のクライアントからの配信要求が来た場合にはその配信要求を拒否する、という制御が行われていた。

しかしながら、クライアントが任意の属性の映像ストリーム（マルチストリーム）の配信を要求することができ、映像配信サーバがそのクライアントからの要求に応じた属性の映像ストリームを配信するシステムを考えた場合には、クライアントごとに取り扱う映像ストリームの属性が異なり、その属性の違いによって処理負荷も異なるから、上記のように単純に同時に接続されるクライアントの数に制限を設けても有効な配信制御を実現することはできない。

そこで、本発明者は、一のクライアントから配信要求を受信し、その配信要求を受信した時点で接続されている他のクライアントのために要する処理負荷に基づいて、処理能力の余力を求め、この余力の範囲内で提供可能な映像ストリームの属性の候補を抽出して、その抽出された各候補を選択肢として上記一のクライアントに通知するようにした映像配信の制御技術を別途提案した。これにより、映像配信装置の余力を各クライアントに有効に分配することが可能になる。

特開２００３−００９１２６号公報 特開平１０−１６４４２０号公報

しかし、映像配信装置の処理能力の余力の範囲内で提供可能な映像ストリームの属性の候補を抽出する際の基準（抽出の方針）が固定されていると、ネットワーク環境の変化、管理者の設計方針の変更などに対応ができず、映像配信装置の余力を有効に分配できないケースもある。したがって、このような状況の変化に応じて、候補を抽出する際の基準を変更できることが望ましい。また、特定のクライアントやユーザからの要求を優先的に扱うような設計がされた場合にも、それに応じて候補を抽出する際の基準を変更できることが望ましい。

本発明は、上記したような課題、あるいはその他の課題を解決することを目的としている。

本発明の一側面に係る映像配信装置は例えば、クライアントからの要求に応じた属性の映像ストリームを配信する映像配信装置であって、一のクライアントから配信要求を受信する手段と、前記配信要求を受信した時点で接続されている他のクライアントのために要する処理負荷に基づいて処理能力の余力を求める手段と、所定の評価関数を用いて、前記余力の範囲内で提供可能な映像ストリームの属性の候補を抽出する手段と、抽出された各候補を選択肢として前記一のクライアントに通知する手段と、前記候補を抽出する手段における抽出方針を示すポリシーの変更の指示を受け付ける手段と、前記所定の評価関数を、前記変更に係るポリシーに応じた別の評価関数に切り替える手段とを有することを特徴とする。

本発明の別の側面に係る映像配信装置の制御方法は例えば、一のクライアントから配信要求を受信する手段と、前記配信要求を受信した時点で接続されている他のクライアントのために要する処理負荷に基づいて処理能力の余力を求める手段と、所定の評価関数を用いて、前記余力の範囲内で提供可能な映像ストリームの属性の候補を抽出する手段と、抽出された各候補を選択肢として前記一のクライアントに通知する手段とを有する映像配信装置の制御方法であって、前記候補を抽出する手段における抽出方針を示すポリシーの変更の指示を受け付けるステップと、前記所定の評価関数を、前記変更に係るポリシーに応じた別の評価関数に切り替えるステップとを有することを特徴とする。

本発明によれば、映像配信サーバやクライアントの処理能力に応じて、映像ストリームの最適な配信制御が実現される。

以下、図面を参照して本発明の好適な実施形態について詳細に説明する。以下では、多くの実施形態を説明するが、実施形態間で共通の構成や処理については共通の参照番号を付し、これにより重複した説明を回避している。ただし、共通の参照番号が付されていてもその内容が前出の構成や処理と相違する点を含む場合には、その都度その相違する点については言及することにする。

（実施形態１）
図１は、本発明の実施形態に係る映像配信システムの構成を示すブロック図である。

映像配信装置としての映像配信サーバ１００は、撮像装置１０１からの映像信号１０２を受けデータを圧縮するデータ圧縮装置１０３、ブートプログラムや各種データを記憶するメモリ１０４、演算や処理の制御を行う中央処理装置（ＣＰＵ）１０５、ネットワークに接続するためのネットワークインターフェース（Network I/F）１０６を含む構成である。

撮像装置１０１は、映像配信サーバ１００の制御信号１０７を受け、映像信号１０２を出力する。なお、本実施形態では、図示のように、映像配信サーバ１００と撮像装置１０１とは独立した構成となっているが、両者が一体となった構成であってもよい。

データ圧縮装置１０３は、例えば圧縮チップにより実現されるもので、映像信号を圧縮してＪＰＥＧやＭＰＥＧ等の形式のデータを出力し、メモリ１０２に格納する。

ネットワークインターフェース（Ｉ／Ｆ）１０６は、例えばネットワークチップにより実現されるもので、ネットワーク１０８とＣＰＵ１０５との間のデータのＩ／Ｏの機能を提供する。

複数のクライアント（情報処理端末）１０９（クライアント１０９−１，１０９−２，…，１０９−ｎ）はそれぞれ、ビューワとして機能するもので、ネットワーク１０８を介して映像配信サーバ１００より配信されたデータを受け取り表示する。クライアント１０９は、パーソナルコンピュータ（ＰＣ）や携帯型コンピュータ（ＰＤＡ）、携帯電話などによって実現されうる。

メモリ１０４には、図２に示すように、マルチストリーム作成プログラム２１０、配信制御プログラム２２０、ストリーム負荷データ２５０、接続情報２６０等が格納される。

図３は、本実施形態における映像配信サーバ１００によるマルチストリーム作成処理を示すフローチャートである。このフローチャートに対応するプログラムはマルチストリーム作成プログラム２１０に含まれ、ＣＰＵ１０５によって実行される。ここでは、６４０ｘ４８０、３２０ｘ２４０、１６０ｘ１２０の画像サイズのＪＰＥＧマルチストリームを扱う例を示す。

まずステップＳ３０１において、メモリ１０４内の各種設定パラメータの初期設定を行う。この際、図４に示すような構造のストリーム負荷データ２５０や、後述するサーバ処理の上限値である設定値Ｘなどのロードも行われる。ストリーム負荷データ２５０は、例えば圧縮チップ（データ圧縮装置１０３）の性能に基づいて、属性としての画像サイズごとの処理負荷の値を有する。図４に示した例では、画像サイズ１６０ｘ１２０の場合の処理負荷を基準（＝１）として各画像サイズの映像配信サーバ１００のストリーム配信を処理するための負荷が記述されている。図４に示すデータは予め実験して得られた値であってもよいし、推定値であってもよい。すなわち、３２０ｘ２４０のときの処理負荷は４、６４０ｘ４８０のときの処理負荷が１６、８００ｘ６００のときの処理負荷が２５、となっている。

次に、ステップＳ３０２において、ステップＳ３０１で設定された撮像パラメータを用いて撮像装置１０１の初期設定を行う。この設定は例えば、撮像装置１０１への制御信号１０７を使用して行うことができる。

次に、ステップＳ３０３において、ステップＳ３０１で設定されたデータ圧縮パラメータを用いてデータ圧縮装置１０３の初期設定を行う。この設定は例えば、圧縮する画像サイズなどを含む。

続くステップＳ３０４では、割り込みなどのイベントを待つ。以下のステップＳ３２０，Ｓ３３０，Ｓ３４０，Ｓ３５０，Ｓ３６０，Ｓ３７０はそれぞれ、受け取ったイベントの種類を判断するステップとなる。

受信したイベントが映像要求イベントであった場合は（ステップＳ３２０，ｙｅｓ）、要求された画像の属性であるサイズをデータ圧縮装置１０３に設定し（ステップＳ３２１）、その後ステップＳ３０４のイベントループに戻る。

データ圧縮装置１０３より映像作成完了イベントを受け取った場合は（ステップＳ３３０，ｙｅｓ）、メモリ１０４よりその画像を取り出し（ステップＳ３３１）、図５に示すような構造の接続情報２６０に従って、映像要求イベントを発行したクライアントに送信する（ステップＳ３３２）。接続情報２６０は、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズを記述したもので、後述する処理によって接続状況の変化に応じて更新される。

クライアント１０９より、ネットワークインターフェース１０６を介して、継続映像要求イベントを受け取った場合は（ステップＳ３４０，ｙｅｓ）、映像要求イベントを発行してステップＳ３２１と同様の処理を行い（ステップＳ３４１）、その後ステップＳ３０４のイベントループに戻る。ここで、継続映像要求イベントとは、映像配信サーバ１００からクライアント１０９への映像の継続的な配信を要求するイベントである。

クライアント１０９より、ネットワークインターフェース１０６を介して、接続終了イベントを受け取った場合には（ステップＳ３５０，ｙｅｓ）、接続情報２６０から該当するデータを一件削除して（ステップＳ３５１）、ステップＳ３０４のイベントループに戻る。ここで、接続終了イベントとは、映像配信サーバ１００とクライアント１０９との接続を断つために、クライアント１０９より、映像配信サーバ１００に対して要求されるイベントである。また、この接続終了イベントは、何らかの理由で映像配信サーバ１００からクライアント１０９への通信が途切れてしまったような場合にも発行されうる。

以上のステップＳ３２０〜Ｓ３５１のような処理によって本実施形態の映像配信機構が実現される。

次に、クライアント１０９より、ネットワークインターフェース１０６を介して、接続要求イベントを受け取った場合には（ステップＳ３６０，ｙｅｓ）、配信制御プログラム２２０に基づいて、配信制御処理を実行する（ステップＳ３６１）。この接続要求イベントは、クライアントより要求された映像ストリームの属性の情報（以下「要求画像属性」という。）も含む。

以下、この映像配信サーバ１００によるステップＳ３６１における配信制御処理を、図６のフローチャートを用いて説明する。

まず、ステップＳ６０１で、接続要求イベントに含まれる要求画像属性を読み込み、ステップＳ６０２で、接続情報２６０を読み込む。この接続情報２６０を参照すれば現在接続されている全クライアントを特定することができる。

次に、ステップＳ６０３で、接続されているクライアントごとに、ストリーム負荷データ２５０を参照して、そのクライアントに対応する負荷を読み出し加算していき、その総和を全体負荷Ｆとして求める。この全体負荷Ｆによって現在の処理負荷が推定される。

図５の接続情報２６０および図４のストリーム負荷データ２５０に基づいて一例を説明する。図５の接続情報２６０を参照すると、現在クライアント１０９−１とクライアント１０９−２が映像配信サーバ１００に接続されている。クライアント１０９−１は画像サイズが６４０ｘ４８０の映像を要求しており、一方、クライアント１０９−２は画像サイズが１６０ｘ１２０の映像を要求していることが分かる。次に、図４のストリーム負荷データ２５０を参照すると、６４０ｘ４８０の画像の処理負荷は１６、１６０ｘ１２０の画像の処理負荷は１であるから、この場合の全体負荷Ｆ（すなわち、現在の処理負荷）は、Ｆ＝１６＋１＝１７となる。

次に、ステップＳ６０４で、今回要求されている映像に対する負荷ｆをストリーム負荷データ２５０を参照して求める。たとえば、画像サイズ３２０ｘ２４０の映像が要求されている場合には、ストリーム負荷データ２５０を参照すると、今回要求されている映像に対する負荷ｆは、４と推定される。

今回新たに要求されている映像の配信を実行する場合には、そのときの全体の処理負荷は、現在の処理負荷（＝全体負荷Ｆ）に、今回要求されている映像に対する負荷ｆを追加した値となる。この値が映像配信サーバ１００の処理能力の限界を超える場合には、全体のパフォーマンスが落ち、円滑なストリーミングが妨げられる可能性がある。そこで、ステップＳ６０５で、ステップＳ３０１で読み込んだサーバ処理の上限値である設定値Ｘ（以下「上限値Ｘ」という。）を読み出し、ステップＳ６０６で、全体負荷Ｆと負荷ｆとの和（＝今回要求されている映像の配信を実行するとした場合の全体の処理負荷）が上限値Ｘ以下に収まっているかどうか（すなわち、Ｘ≧Ｆ＋ｆを満たすかどうか）を判断する。ここで、Ｘ≧Ｆ＋ｆを満たす場合には、ステップＳ６０７に進み、接続要求イベントの発行元のクライアントの情報を接続情報２６０に登録する。その後、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行う（ステップＳ６０８）。一方、Ｘ≧Ｆ＋ｆを満たさない場合には、接続要求イベントの発行元に拒否応答を返す（ステップＳ６０９）。

ここで、上限値Ｘについて説明しておく。この上限値Ｘは、映像配信サーバ１００の管理者などによって変更することのできる値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。上限値Ｘは固定値としてあらかじめメモリ１０４に設定しておいてもよいが、例えばｔｅｌｎｅｔやｆｔｐ、ＲＰＣなどの機構によってメモリ１０４に設定するようにしてもよい。

なお従来の方式では、この上限値はクライアントの接続数などで指定されており、管理者の許可する処理能力の上限値を表すものではなかった。従来のようにクライアントの接続本数で制限した場合、大きな負荷のストリームばかりが選択されたときに、映像配信装置の処理能力を上回り、全てのストリーム配信に不具合が出てしまい、逆に、小さな負荷のストリームばかりが選択されたときには、映像配信装置の処理能力に余力があるにもかかわらず、接続数が上限に達したということだけで配信が拒否されるという事態が生じていた。

一方、本実施形態の上限値Ｘは単なるクライアントの接続本数等ではなく、画像処理などにかかる負荷を直接示す値であるから、映像配信サーバの処理能力をより有効に活用することができる。

説明を図３のフローチャートに戻す。上記したステップＳ３６１の配信制御処理が終了すると、ステップＳ３０４のイベントループに戻る。

終了イベントを受け取った場合は（ステップＳ３７０，ｙｅｓ）、ステップＳ３７１に進み、接続情報２６０を全件削除して、このマルチストリーム作成処理を終了する。

以上説明した実施形態１によれば、映像配信サーバにおいて、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷（Ｆ＋ｆ）が推定され、それが所定の上限値（Ｘ）を超える場合には当該要求に係る接続が拒否される。これにより、映像配信サーバ１００の処理負荷が能力の限界を超えてしまい全体のパフォーマンスが落ち、円滑なストリーミングが妨げられるような事態の発生を防止することができる。

特に、組み込み機器型のカメラサーバなど、比較的に処理能力の非力な映像配信サーバにおいてはこの効果が高い。このような機器の場合、転送路の制約に対して機器の処理能力の制約が大きく、機器の性能に対して転送路の性能が上回るため、従来型の接続本数の制限や、転送量の制約などだけでは適切な配信制御を行うことができなかったが、機器の処理能力によって配信制御を行うことで、映像配信サーバの処理能力をより有効に活用することができる。

なお、本実施形態における映像配信サーバへの接続は映像の配信を目的としたものであり、それ以外の処理を目的とした接続は考慮しなかった。したがって、上記の「接続を拒否する」という表現は「映像の配信を拒否する」と等価である（以下同様。）。

また、上述の実施形態では、画像の属性が画像のサイズを示す場合の例について説明したが、画像の属性としてはこの他に、符号化／復号化、画質、フレームレート、あるいはこれらの組み合わせ等が考えられ、これらの属性についても本発明を適用することができることは容易に理解できるであろう。

（実施形態２）
上述の実施形態１では、画像の属性として、画像サイズ、画質、フレームレート等を扱い、これらに応じた映像ストリームの配信制御について説明したが、本実施形態では、このような画像属性だけでなく、撮像装置（カメラ）の制御内容を示す「処理属性」をも加味した映像ストリームの配信制御を行う。

本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図７に示すように、実施形態１と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、ストリーム負荷データ２５０、接続情報２６０に加えて、撮像装置１０１を制御する手段としてのカメラ制御プログラム７１０が格納されている。このカメラ制御プログラム７１０を実行するかどうかはユーザが任意に設定することが可能であり、カメラ制御プログラム７１０が実行された場合には例えば、撮像装置１０１の向きを巡回させる巡回処理や、動体を検知してその動体を追尾するように撮像装置１０１の向きを移動させる動体追尾処理などのカメラ制御が行われる。なお、これらの各処理について個々に実行する／しないをユーザが設定できることがより好ましいが、ここでは説明を簡単にするために、カメラ制御プログラム７１０の実行／非実行の設定だけが行われると仮定する。なお、以下では、「カメラ制御プログラム７１０の実行／非実行」のことを「カメラ制御あり／なし」と略記する。

カメラ制御ありの場合には、ＣＰＵ１０５の処理は映像ストリームの配信処理だけでなく、このカメラ制御にも割かれることになる。本実施形態ではこのことを考慮して、ストリーム負荷データ２５０には、画像サイズごとに、カメラ制御ありの場合とカメラ制御なしの場合の処理負荷がそれぞれ記述されている。図８に、このストリーム負荷データ２５０の構造例を示す。同図の例では、画像サイズが１６０ｘ１２０でカメラ制御なしの場合の処理負荷を基準（＝１）として、各ケースの処理負荷が記述されている。同様に、接続情報２６０にも、図９に示すように、現在接続されているクライアントごとに、画像サイズに加えカメラ制御あり／なしの情報が記述されている。

本実施形態におけるマルチストリーム作成処理は基本的に実施形態１における処理（図３、図６）とほぼ同様に行われる。

なお、本実施形態の場合、図６のステップＳ６０３では、例えば次のようにして全体負荷Ｆが求められる。図９の接続情報２６０を参照すると、現在クライアント１０９−１とクライアント１０９−２が映像配信サーバ１００に接続されている。クライアント１０９−１は、画像サイズ６４０ｘ４８０の映像を要求し、カメラ制御は「なし」の設定である。一方、クライアント１０９−２は、画像サイズ１６０ｘ１２０の映像を要求しているが、カメラ制御は「あり」の設定である。次に、図８のストリーム負荷データ２５０を参照すると、６４０ｘ４８０の画像についてカメラ制御なしの場合の処理負荷は１６、１６０ｘ１２０の画像についてカメラ制御ありの場合の処理負荷は２であるから、この場合の全体負荷Ｆは、Ｆ＝１６＋２＝１８となる。

また、今回要求されている映像ストリームの作成にかかる負荷ｆをストリーム負荷データ２５０から求めるステップＳ６０４では、たとえば、画像サイズ３２０ｘ２４０の映像が要求され、カメラ制御ありの設定がなされている場合には、図８のストリーム負荷データ２５０を参照すると、負荷ｆ＝５と推定される。

上限値Ｘは、実施形態１と同様、映像配信サーバ１００の管理者などによって変更することのできる設定値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。実施形態１では、典型的に、上限値Ｘは、圧縮処理の負荷の総和に対する上限値として設定されたが、本実施形態では圧縮処理のみならずカメラ制御に要する負荷を含む処理負荷の総和に対する上限値として設定されることになる。

（実施形態３）
上述の実施形態１，２は、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷（Ｆ＋ｆ）を推定し、それが所定の上限値（Ｘ）を超えるときは当該要求に係る接続を拒否する、というものであった。

本実施形態は、上限値（Ｘ）を超えるときに当該要求に係る接続を直ちに拒否するのではなく、映像配信サーバの余力の範囲内で提供可能な映像ストリームの属性の候補を選択肢として提供する。これにより、ユーザが接続できないケースを減らし、少なくとも低負荷のストリームを提供できるようにすることがねらいである。以下の説明では基本的に実施形態２を基に、相違する点を中心に説明するが、本実施形態は実施形態１に対しても適用が可能である。

本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図１０に示すように、実施形態２と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、ストリーム負荷データ２５０、接続情報２６０に加えて、ストリーム選択肢情報２７０が格納されている。また、本実施形態のストリーム負荷データ２５０および接続情報２６０はそれぞれ、実施形態２と同様に、図８、図９に示したような構造を有するものとする。

本実施形態における映像配信サーバ１００によるマルチストリーム作成処理は基本的に実施形態１，２における処理（図３）とほぼ同様に行われる。ただし本実施形態では、ステップＳ３６１における配信制御処理が、図１１のフローチャートに従って行われる。

まず、ステップＳ１００１で、接続情報２６０を読み込む。また、実施形態１，２におけるステップＳ６０１と同様に、接続要求イベントに含まれる要求画像属性も読み込む。

次に、ステップＳ１００２で、接続情報２６０およびストリーム負荷データ２５０を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。次に、ステップＳ１００３で、今回要求されている映像に対する負荷ｆをストリーム負荷データ２５０を参照して求める。

次に、ステップＳ１００４で、ステップＳ３０１で読み込んだサーバ処理の上限値Ｘを読み出す。上限値Ｘは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップＳ１００５で、全体負荷Ｆと負荷ｆとの和（＝今回要求されている映像の配信を実行するとした場合の全体の処理負荷）が上限値Ｘ以下に収まっているかどうか（すなわち、Ｘ≧Ｆ＋ｆを満たすかどうか）を判断する。ここで、Ｘ≧Ｆ＋ｆを満たす場合には、ステップＳ１００６に進み、接続要求イベントの発行元のクライアントの情報を接続情報２６０に登録する。その後、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行い（ステップＳ１００７）、本処理を終了する。

一方、ステップＳ１００５で、Ｘ≧Ｆ＋ｆを満たさない場合には、ステップＳ１００８に進み、映像配信サーバ１００の余力Ｙを求める。映像配信サーバ１００の余力Ｙは、上限値Ｘ−全体負荷Ｆにより求める。

次に、ステップＳ１００９で、求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ２５０から読み出し、図１２に示すような構造のストリーム選択肢情報２７０をメモリ１０４に書き込む。例えば、上限値Ｘ＝２５、全体負荷Ｆ＝１８と仮定すると、余力Ｙ＝２５−１８＝７となる。その後、図８のストリーム負荷データ２５０から、負荷の値が７（＝余力）以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報２７０を構成する。この例では具体的には、「ｊｐｅｇ３２０ｘ２４０、カメラ制御なし」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御あり」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御なし」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」、が抽出され、図１２に示されるようなストリーム選択肢情報２７０が構成される。

次に、ステップＳ１０１０で、ストリーム選択肢情報２７０をクライアントへ通知し、ステップＳ１０１１で、イベントを待つ。

ステップＳ１０１２において、ストリーム選択肢情報２７０を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップＳ１０１３に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報２７０の選択番号などで受け取ることにしても良い。次に、ステップＳ１０１４で、ステップＳ６０７と同様に、属性特定要求イベントの発行元のクライアントの情報を接続情報２６０に登録し、続くステップＳ１０１５で、映像要求イベントを発行し、ステップＳ３２１と同様の処理を行う。

また、ステップＳ１０１６において、ストリーム選択肢情報２７０を渡したクライアントから接続終了イベントを受け取った場合、または、ステップＳ１０１７において、ストリーム選択肢情報２７０をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。

以上説明した実施形態３によれば、映像配信サーバ１００の余力に応じた映像ストリーム（すなわち、映像配信サーバ１００全体の処理負荷が上限値Ｘを超えない範囲で提供が可能な映像ストリーム）の候補が選択肢としてクライアントに通知され、ユーザはこれに応じて次善の映像ストリームを選択することができる。これにより、ユーザが接続できないケースを減らすことができ、少なくとも低負荷のストリームを提供できるようになる。

なお、上記の処理例では、ステップＳ１００５で、全体負荷Ｆと負荷ｆとの和、すなわち、今回要求されている映像ストリームの配信を実行するとした場合の全体の処理負荷、が上限値Ｘを超える場合に、ステップＳ１００８以降の処理が実行されて選択肢がクライアントに通知されるようにしたが、全体負荷Ｆと負荷ｆとの和が上限値Ｘを超えるかどうかに関わらず、選択肢をクライアントに通知するようにしてもよい。

（実施形態４）
上述の実施形態３では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の選択肢をユーザに通知するようにした。しかし、映像配信サーバに課せられる負荷は刻々と変化するので、これに伴い余力も変動する。そこで本実施形態では、映像配信サーバの余力を監視し、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合には、改めて選択肢を通知するようにする。

図１３は、本実施形態における映像配信サーバ１００によるマルチストリーム作成処理を示すフローチャートである。このフローチャートにおける多くのステップは図３のフローチャートにおけるステップと同様であるので、同じ内容のステップには同じ参照番号を付しそれらの説明は省略し、以下では、図３と相違するステップについてのみ説明する。

図３と対照すると分かるように、図１３のフローチャートには、ステップＳ３０４とステップＳ３２０との間に、ステップＳ３１０〜Ｓ３１６の処理が挿入されている。

ステップＳ３１０において、受信したイベントが、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に発行される選択肢変化イベントであった場合は、ストリーム負荷データ２５０と接続情報２６０を読み込み（ステップＳ３１１）、クライアントごとに、次の一連の動作を経て選択肢を通知する（ステップＳ３１２）。

すなわち、接続情報２６０およびストリーム負荷データ２５０を参照して、現在接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。次に、上限値Ｘと全体負荷Ｆとの差分を余力Ｙとして求め、その余力Ｙに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ２５０から読み出し、メモリ１０４に格納されているストリーム選択肢情報２７０を更新する（ストリーム選択肢情報２７０がまだメモリ１０４に作成されていない場合には新規に作成する。）。そして、クライアント毎に新たな選択肢を通知し、その後ステップＳ３０４へ戻る。

なお、クライアントは、選択肢の通知を受け取ると、映像再生中であってもその選択肢が表示される。クライアントの使用者は、表示された選択肢から所望する属性を選択することができる。また、映像配信サーバ１００の余力が増えたことで、より高品質な属性の選択肢が増えた場合には、クライアントは、その高品質な属性が自動で選択するように構成されていると好都合である。

クライアント側で別の属性が選択された場合には、属性変更要求イベントが映像配信サーバ１００に発行される。

ステップＳ３１３において、属性変更要求イベントを受信した場合には、要求された属性を読み込み（ステップＳ３１４）、その属性でメモリ１０４に格納されている接続情報２６０の該当部分を変更する（ステップＳ３１５）。つづいて、映像要求イベントと選択肢変化イベントを発行する（ステップＳ３１６）。選択肢変化イベントは、接続情報２６０を変更した際に発行される。

さらに、図１３のフローチャートが図３のフローチャートと異なっているのは、ステップＳ３５１の後にステップＳ３５２が新たに挿入されている点である。ステップＳ３５１で接続情報２６０から該当するデータが削除されると、その後、ステップＳ３５２において、選択肢が変化したことを示す選択肢変化イベントが発行される。

また、ステップＳ３６１で実行される配信制御処理も、基本的には図１１に示したフローチャートに従って実行されるが、本実施形態では、ステップＳ１０１４において接続情報２６０に新たに接続されるクライアントの情報が追加登録され、ステップＳ１０１５で映像要求イベントが発行された後、この配信制御処理を完了する前にも選択肢変化イベントが発行される。

以上説明した実施形態４によれば、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に、新たな選択肢が随時提示されるので、クライアントの使用者はその余力に応じた最適な属性をタイムリーに選択することが可能になる。たとえば、最低限のストリームで接続していたクライアントも、サーバに余力が出た時点で、より高品質なストリームを要求し直すことができる。

（実施形態５）
上述の実施形態４では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があると、その都度新たな選択肢が提示された。

しかし、余力が少なくなった場合には、選択肢は、現在提供しているストリームよりも低品質なストリームに減るだけで、高品質なストリームが増えることはない。そうすると、クライアントのユーザにとっては、現在閲覧中のストリームより低品質のものに切り換えることをわざわざ勧められるということになってしまい、好ましくないと考えることもできる。

そこで、本実施形態では、余力が増加した場合に限り、新たな選択肢を提示する。

これを実現するためには、実施形態４では図１３のフローチャートにおけるステップＳ３１６において発行するようにした選択肢変化イベントを、発行しないようにする。同様に、実施形態４では図１１のフローチャートにおけるステップＳ１０１５の後で発行するようにした選択肢変化イベントを、発行しないようにする。これにより、選択肢変化イベントが発行されるのは、接続が減少した場合に実行されるステップＳ３５２においてだけとなる。

つまり、接続が増加する場合には選択肢変化イベントを発行せず、接続が減少する場合のみ、選択肢変化イベントを発行する。

これにより、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補の数が増加した場合にのみ、クライアントに選択肢の変化通知がなされるので、クライアントの使用者は有益な通知だけを受け取ることができる。

（実施形態６）
本実施形態は、上述の実施形態３〜５のいずれかに記載した、提供可能な映像ストリームの属性の候補の選択肢を提供する映像配信サーバ１００に対するクライアント１０９における制御処理に関する。以下では、実施形態３の映像配信システムに基づいて説明する。

図１４は、実施形態におけるクライアント１０９の構成を示す図である。

クライアント１０９は、図示のように、映像配信サーバ１００からのデータを、ネットワーク１０８を介して受け取るネットワークインタフェース（Network I/F）２００１、演算や処理の制御を行う中央処理装置（ＰＵ）２００２、必要なプログラムやデータを記憶するメモリ２００３、ＬＣＤやＣＲＴなどで構成される表示装置２００４、を含む。

ネットワークインタフェース２００１を介して受信した圧縮データはメモリ２００３に一旦格納される。その後、ＣＰＵ２００２によってその圧縮データが伸張処理され、表示装置２００４に表示される。もっとも、ＣＰＵ２００２に代わって伸張処理を実行する専用のデータ処理伸張装置（ＤＳＰなど）が付加された構成でもよい。

メモリ２００３には、図１５に示すように、映像配信サーバ１００からの映像ストリームを受信するための映像ストリーム受信プログラム２１００、後述する選択肢限定処理を実現するための選択肢限定プログラム２１２０、ビューワ機能を実現するためのビューワプログラム２１３０、クライアントの現在の余剰処理能力を測定するためのベンチマークプログラム２１４０等のプログラムが格納される他、画像の属性ごとのクライアントの処理負荷を示すクライアントストリーム負荷データ２１５０、映像配信サーバ１００より通知される提供可能な映像ストリームの属性候補の選択肢の情報であるストリーム選択肢情報２１６０、選択肢限定プログラム２１２０の実行によって限定された選択肢データが記述されるストリーム限定選択肢情報２１７０等の各種データが格納される。

図１６は、本実施形態におけるクライアント１０９によるマルチストリーム受信処理を示すフローチャートである。このフローチャートに対応するプログラムはストリーム受信プログラム２１００に含まれ、ＣＰＵ２００２によって実行される。このストリーム受信プログラム２１００は例えばビューワプログラム２１３０の実行においてコールされる。また、後述するように、ベンチマークプログラム２１４０および選択肢限定プログラム２１２０はストリーム受信プログラム２１３０の実行においてコールされるという関係である。

まずステップＳ２２０１において、メモリ２００３内の各種設定パラメータの初期設定を行う。この際、図１８に示すような構造のクライアントストリーム負荷データ２１５０のロードも行われる。クライアントストリーム負荷データ２１５０は、例えば、各画像サイズについてカメラ制御の有無別に、ＣＰＵ２００２の性能に基づく処理負荷を有する。図１８に示した例では、画像サイズが１６０ｘ１２０でカメラ制御なしの場合の処理負荷を基準（＝１）として、各画像サイズについてカメラ制御の有無ごとに処理負荷が記述されている。

次に、ステップＳ２２０２で、接続要求イベントを発行し、これを映像配信サーバ１００に送信する。上述したとおり、映像配信サーバ１００は、この接続要求イベントの受信に応答して配信制御処理を実行し（図３、ステップＳ３６１）、状況に応じて、提供可能な映像ストリームの属性の候補の選択肢の情報を接続要求イベントの発行元のクライアントに送信する（図１１、ステップＳ１０１０）。

なお、ステップＳ２２０２で接続要求イベントを送信する際、初期のストリーム種別の要求も送信する場合もある。ただし、映像受信サーバ１００から接続拒否されたり、要求ストリーム以下の選択肢しか送付されなかったりする場合もありえる。

次のステップＳ２２０６で、イベントを待つ。

ステップＳ２２０３において、映像配信サーバ１００より、提供可能な映像ストリームの属性の候補の選択肢の情報を受信したときは、メモリ２００３内にその選択肢の情報をストリーム選択肢情報２１６０として保存し、その後、選択肢限定プログラム２１２０をコールすることにより、受信した選択肢を絞り込むための選択肢限定処理を実行する（ステップＳ２２０４）。このときのストリーム選択肢情報２１６０の構造例を図１９に示す。

以下、このステップＳ２２０４における選択肢限定処理を、図１７のフローチャートを用いて説明する。

まずステップＳ２３０１で、メモリ２００３に保存されているストリーム選択肢情報２１６０を読み込んだ後、クライアント１０９がビューワの処理（すなわち、ビューワプログラム２１３０の実行）に割り当てることのできる現在の余剰処理能力を測定するため、ベンチマークプログラム２１４０を起動する（ステップＳ２３０３）。

このベンチマークプログラム２１４０は、ビューワプログラム２１３０の実行時に消費する処理能力を推定しやすくするために作られたもので、比較的処理負荷の軽いプログラムが適当である。ビューワプログラム２１３０にこのベンチマークプログラム２１４０を組み込んでおき、ビューワプログラム２１３０の起動時に余剰負荷を測定するようにしてもよい。ここで、ビューワプログラム２１３０は圧縮された映像データの伸張処理のプログラムを含み、この伸張処理の負荷がビューワプログラム２１３０の中で最も重いと仮定する。ベンチマークプログラム２１４０はビューワプログラム２１３０に、予め用意した処理量が既知の圧縮映像データの伸張処理を実行させる。

ステップＳ２３０４で、その伸張処理に要した時間Ｔを計測する。次に、この実行時間Ｔからクライアントの余剰処理能力である処理能力Ｐを算出する（ステップＳ２３０５）。ここでは、処理能力Ｐは実行時間Ｔに逆比例すると考える。例えば、実行時間Ｔが１００ｍｓｅｃであった場合の処理能力Ｐが２と算出されると仮定すると、実行時間Ｔが５０ｍｓｅｃであった場合の処理能力Ｐは４と算出されることになる。

次に、ステップＳ２３０６において、ストリーム選択肢情報２１６０の中から、処理能力がＰ以下の選択肢を抽出し、これをストリーム限定選択肢情報２１７０としてメモリ２００３に格納する。処理能力がＰ以下であれば、現在のクライアントに余剰処理能力でも、十分な映像の表示速度やフレームレートを確保できる。一例として、ストリーム選択肢情報２１６０が図１９に示されたとおりで、上記のステップＳ２３０５で算出された処理能力Ｐが４であった場合について説明する。図１９のストリーム選択肢情報２１６０を参照すると、映像配信サーバ１００より提示された選択肢としては、画像サイズ３２０ｘ２４０と１６０ｘ１２０のそれぞれについて、カメラ制御ありの場合とカメラ制御なしの場合の、４通りの候補がある。次いで、図１８のクライアントストリーム負荷データ２１５０を参照すると、処理能力（＝処理負荷）が４以下の選択肢は、画像サイズが３２０ｘ２４０でカメラ制御なしの場合、画像サイズが１６０ｘ１２０でカメラ制御ありの場合、および、同サイズでカメラ制御なしの場合、の３通りに絞られる。この３通りの候補がストリーム限定選択肢情報２１７０としてメモリ２００３に格納される。

そして、上記の処理により選択肢が限定された場合には、ステップＳ２３１０で、その限定された選択肢を表示する。ステップＳ２３１１では、選択肢が限定されたか否かを判定し、限定された場合には、ステップＳ２３１２においてユーザにいずれか１つを選択させる。一方、たとえばステップＳ２３０５で算出された処理能力Ｐが小さく、選択肢が限定されなかった場合には、ステップＳ２３１３に進み終了イベントを発行する。以上によりステップＳ２２０４の処理が完了する。

なお、ステップＳ２３１２の処理については、ユーザに最終的な候補を選択させるかわりに、表示可能な最高画質のストリームを自動選択するようにしてもよい。

説明を図１６のフローチャートに戻す。上記したステップＳ２２０４の選択肢限定処理を終えると、ステップＳ２２０５に進み、映像要求イベントを発行し、これを映像配信サーバ１００に送信して、ステップＳ２２０６のイベントループに戻る。

映像配信サーバ１００からの映像ストリーム（図３のステップＳ３３２を参照）の受信が完了し、受信完了イベントを発行すると（ステップＳ２２０７）、受信した映像ストリームを順次メモリ２００３から取り込み（ステップＳ２２０８）、その映像ストリームを表示装置２００４に表示する（ステップＳ２２０９）。その後、ステップＳ２２１１で継続映像要求イベントを発行し、ステップＳ２２０６のイベントループに戻る。

ステップＳ２２１４において、映像配信サーバ１００から接続の拒否応答（図６のステップＳ６０９を参照）を受信した場合は、接続終了イベントを発行し（ステップＳ２２１２）、本マルチストリーム受信処理を終了する。

以上説明した実施形態６によれば、クライアント１０９は、映像配信サーバ１００より、提供可能な映像ストリームの属性の候補の選択肢が通知されると、そのときのクライアント１０９の処理能力を推定する。そして、推定された処理能力に基づいて、上記選択肢の候補をさらに限定し、その限定された候補の選択肢を表示する。これにより、ユーザはクライアント側の処理能力に見合った属性の映像ストリームを、容易に指定することができる。

（実施形態７）
本実施形態では、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して選択する。

以下では、基本的に実施形態３を基に、相違する点を中心に説明するが、本実施形態は実施形態４、５に対しても適用が可能である。

本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図２０に示すように、実施形態２と同様のマルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、ストリーム負荷データ２５０、接続情報２６０、ストリーム選択肢情報２７０の他に、優先度テーブル２８０、優先度別ストリーム負荷データ２９０が格納されている。本実施形態でも、ストリーム負荷データ２５０および接続情報２６０はそれぞれ、実施形態３と同様の構造（図８、図９を参照）を有するものとする。ただし、本実施形態では、現在の接続情報２６０の内容が図２２のようになっているとする。すなわち、図２２を参照すると分かるように、映像配信サーバ１００には現在、ビューワ（クライアント）１０９−１〜１０９−４の４台が接続されている。

本実施形態における映像配信サーバ１００によるマルチストリーム作成処理は基本的に実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われる。ただし本実施形態では、ステップＳ３６１における配信制御処理が、図２１のフローチャートに従って行われる。

まずステップＳ５１０１で、接続情報２６０を読み込む。また、実施形態３におけるステップＳ１００１と同様に、接続要求イベントに含まれる要求画像属性も読み込む。

次に、ステップＳ５１０２で、接続情報２６０およびストリーム負荷データ２５０を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷Ｆ（現在の処理負荷）として計算する。図２２の接続情報２６０に基づき具体例を説明する。図２２の接続情報２６０を参照すると、ビューワ１０９−１から１０９−４の接続があり、それぞれ、８００ｘ６００でカメラ制御なし、１６０ｘ１２０でカメラ制御有り、６４０ｘ４８０でカメラ制御なし、８００ｘ６００でカメラ制御なし、という属性の映像ストリームを要求していることが分かる。ここで、ストリーム負荷データ２５０を参照すると、各接続の処理負荷は、２５、２、１６、２５である。よって、全体負荷Ｆは、これらの総和６８と求められる（この値の例は後ほど使用する。）。

次に、ステップＳ５１０３で、サーバ処理の上限値Ｘを読み出す。上限値Ｘは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップＳ５１０４で、映像配信サーバ１００の余力Ｙを求める。余力Ｙは、上限値Ｘと全体負荷Ｆとの差分として求められる。その後、ステップＳ５１０５で、優先度別選択肢作成プログラム２３０を呼び出す。

優先度別選択肢作成プログラム２３０による動作例を図２３に示す。

まずステップＳ５３０１で、図２４に示すような構造の優先度テーブル２８０を読み込む。図２４の優先度テーブルには、図８のストリーム負荷データ２５０と同様に分類されたそれぞれのケースについて優先度を示す情報が記述されている。具体的には、図２４に示した例では、画像サイズ８００ｘ６００でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が０、画像サイズ６４０ｘ４８０でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が１０に設定されている。また、画像サイズ３２０ｘ２４０でカメラ制御ありの場合の優先度を示す情報が２、同サイズでカメラ制御なしの場合の優先度を示す情報が０、画像サイズ１６０ｘ１２０でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が２に設定されている。ここでは、優先度を示す情報が０のときが最も優先度が高いと考える。

そして、ステップＳ５３０２で、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２４）に記述された対応する優先度を示す情報の値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。図２５は、得られた優先度別ストリーム負荷想定データ２９０の例を示す図である。図８と図２４とを重ね合わせてみれば、図２５の結果が得られることが容易に理解できよう。

次に、ステップＳ５３０３で、ステップＳ５１０４で求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ２９０から読み出し、図２６に示すようなストリーム選択肢情報２７０をメモリ１０４に書き込む。ここで、上記した例の通り全体負荷Ｆが６８とし、また、上限値Ｘが９３に設定されていると仮定して具体例を示す。この場合の余力Ｙは９３−６８＝２５となる。その後、優先度別ストリーム負荷想定データ２９０から、負荷の値が２５（＝余力）以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報２７０を構成する。図２５の優先度別ストリーム負荷想定データ２９０の例では、「ｊｐｅｇ８００ｘ６００、カメラ制御なし」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御あり」、「ｊｐｅｇ３２０ｘ２４０、カメラ制御なし」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」、「ｊｐｅｇ１６０ｘ１２０、カメラ制御なし」、が抽出され、これにより図２６に示されるようなストリーム選択肢情報２７０が構成される。

この例の場合、「ｊｐｅｇ６４０ｘ４８０、カメラ制御なし」および「ｊｐｅｇ６４０ｘ４８０、カメラ制御あり」のケースはそれぞれ、負荷が１６および１７で、余力（＝２５）の範囲内に収まるにもかかわらず（図８を参照）、優先度を示す情報１０が加算されたことにより選択肢から外される一方、これらより負荷の大きい「ｊｐｅｇ８００ｘ６００、カメラ制御なし」には優先度を示す情報による加算がされなかった（優先度を示す情報＝０）ので、選択肢として抽出される結果となった。

このように優先度を設定することにより、処理負荷の大きい属性の映像ストリームを、処理負荷の小さい属性の映像ストリームより優先的に選択肢の候補に挙げることが可能になる。つまり、優先度の設定によって、余力内に収まる負荷の特定の属性のストリームについては選択肢に現れないように操作する。その一方で、上記特定の属性のストリームより負荷の高い属性のストリームを選択肢に入れるよう操作する。これにより、余力を、より負荷の高い属性のストリームにまわすことができる。

また、優先度を設定することで、サーバ管理者が意図するストリーム種別での接続を増やす傾向を作ることができる。たとえば、ストリーム負荷は大きいが、なるべく大きなサイズでの映像を優先的に配信しようとする場合には、ストリーム負荷は小さくても小サイズのストリームに対しては優先度を下げるよう設定すればよい。

なお、上記の例では、優先度を規定する値として、優先度を示す情報が０のときが最も優先度が高く、その値が大きくなるほど優先度が小さくなる値を考えた。これは、各属性の負荷に加算されることを前提に規定されたものである。一方このかわりに、優先度を、各属性の負荷に乗じられる重み付け係数として定義することも可能である。この場合には優先度の高低はその数値に応じたものとなる。

説明を図２１のフローチャートに戻す。次に、ステップＳ５１０６で、ストリーム選択肢情報２７０をクライアントへ通知し、ステップＳ５１０７で、イベントを待つ。

ステップＳ５１１０において、ストリーム選択肢情報２７０を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップＳ５１１１に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報２７０の選択番号などで受け取ることにしても良い。また、実施形態１，２と同様に、ここで上限値Ｘと全体負荷Ｆおよび要求された優先度別ストリーム負荷ｆから接続の可否を制御しても良い。

次に、ステップＳ５１１２で、属性特定要求イベントの発行元のクライアントの情報を接続情報２６０に登録し、続くステップＳ５１１３で、映像要求イベントを発行するとともに、ステップＳ５１１４で選択肢変化イベントを発行する。

また、ステップＳ５１２０において、ストリーム選択肢情報２７０を渡したクライアントから接続終了イベントを受け取った場合、または、ステップＳ５１３０において、ストリーム選択肢情報２７０をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。

（実施形態８）
本実施形態では、接続要求に適合した映像ストリームの配信を行うには処理能力の余力が足りない場合、その優先度に応じて余力を作り出し、これにより、その要求に係る配信を実現させる。

本実施形態に係る映像配信システムの構成は実施形態７と同様である。すなわち、本実施形態に係る映像配信システム構成は図１に示されたもので、また、メモリ１０４に格納される内容は、図２０に示されたとおりである。

また、本実施形態におけるマルチストリーム作成処理も実施形態７と同様、基本的には実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われ、ステップＳ３６１における配信制御処理は、図２１のフローチャートに従って行われる。ただし本実施形態では、ステップＳ５１０５における優先度別選択肢作成処理は、図２３のフローチャートのかわりに、図２７のフローチャートに従って行われる。

まずステップＳ５７０１で、図２４に示したような優先度テーブル２８０および、ステップＳ５１０１で読み込んだ要求画像属性を読み出す。次のステップＳ５７０２では、実施形態７におけるステップＳ５３０２と同様に、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２４）に記述された対応する優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。次のステップＳ５７０３では、ステップＳ５１０４で求めた余力Ｙに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ２９０から読み出し、図２６に示すようなストリーム選択肢情報２７０を作成する。

次に、ステップＳ５７０４において、ステップＳ５７０１で読み込んだ要求画像属性が、ステップＳ５７０３で作成されたストリーム選択肢情報２７０に含まれているかどうかを判定する。要求画像属性がストリーム選択肢情報２７０に含まれている場合には、この優先度別選択肢作成処理を抜ける。一方、要求画像属性がストリーム選択肢情報２７０に含まれていない場合はステップＳ５７０５に進む。

ステップＳ５７０５では、優先度テーブル２８０を参照して要求画像属性の優先度を確認するとともに、接続情報２６０および優先度テーブル２８０を参照して要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されているかどうかを調べる。ここで要求画像属性の優先度よりも低い優先度のストリーム配信のための接続は現在のところ確立されていない場合には、そのままこの優先度別選択肢作成処理を抜ける。一方、要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されていた場合には、ステップＳ５７０６に進み、当該接続先のクライアントに接続拒否イベントを発行し、その後、ステップＳ５７０７において、その接続を拒否したクライアントに係る情報を接続情報２６０から削除する。

このステップＳ５７０５、Ｓ５７０６の具体例を示す。処理対象の接続要求イベントを発行したクライアントが１０９−５であり、現在、別の４つのクライアント（１０９−１〜４）が接続されており、そのときの接続情報２６０が図２２に示すとおりであると仮定する。また、ステップＳ５７０１で読み込んだ接続要求イベントに含まれる要求画像属性が「ｊｐｅｇ８００ｘ６００、カメラ制御なし」であったとする。

まず、優先度テーブル２８０を参照して要求画像属性の優先度を確認する。図２４の優先度テーブル２８０を参照すると、要求画像属性「ｊｐｅｇ８００ｘ６００、カメラ制御なし」の優先度を示す値は「０」に設定されており、最も高い優先度に設定されていることがわかる。

次に、接続情報２６０および優先度テーブル２８０を参照して要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係る接続が確立されているかどうかを調べる。ここで、図２２の優先度テーブル２６０を調べてみると、クライアント１０９−１と１０９−４への映像ストリームの属性は「ｊｐｅｇ８００ｘ６００、カメラ制御なし」であり、その優先度を示す値は「０」である。一方、クライアント１０９−２への映像ストリームの属性は「ｊｐｅｇ１６０ｘ１２０、カメラ制御あり」で、図２４の優先度テーブル２８０より、その優先度を示す値は「２」に設定されている。また、クライアント１０９−３への映像ストリームの属性は「ｊｐｅｇ６４０ｘ４８０、カメラ制御なし」で、図２４の優先度テーブル２８０より、その優先度を示す値は「１０」に設定されている。そうすると、このクライアント１０９−２および１０９−３の接続が、要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係るものであることが判明する。

ステップＳ５７０６では、この２つのクライアント１０９−２および１０９−３の両方に直ちに接続拒否イベントを発行してもよいが、ここでは、これらのうち優先度別負荷想定の値（図２５を参照）が最も高いクライアント（すなわち、１０９−３）にのみ接続拒否イベントを発行することにする。これによりクライアント１０９−３の接続が解除された結果、余力が増えることになる。それでもなお要求画像属性の映像ストリームの作成には不足である場合には、続いてクライアント１０９−２に接続拒否イベントを発行するようにすればよいであろう。

ステップＳ５７０５，Ｓ５７０６の具体例は以上のとおりである。

次のステップＳ５７０８では、ステップＳ５７０３と同様にして再度ストリーム選択肢情報２７０を作成する。この場合には、ステップＳ５７０７での削除により、処理対象の接続要求イベントを発行したクライアントの要求画像属性がストリーム選択肢情報２７０に含まれることになる。

以上で、優先度別選択肢作成処理が終了する。

以上説明した優先度別選択肢作成処理によれば、優先度の高い属性のストリームへの接続要求を受けた場合、余力が足りないときには、優先度の低い属性の映像ストリームの配信を停止することで余力をつくり、これにより上記の優先度の高いストリームの配信を実行させることができる。

また、優先度の低いストリームの配信先であるクライアントの接続は解除せず（ステップＳ５７０６、Ｓ５７０７を実行しない）、ステップＳ５７０８では、その優先度の低いクライアントの接続を解除したと仮定した場合における余力Ｙを計算し、その余力Ｙから、優先度の高い要求画像属性のストリームにかかる負荷を減算した上で、再度選択肢を作成し直し、これを上記の優先度の低いストリームに係るクライアントに提示するようにしてもよい。この場合には、優先度の低いストリームの配信に係るクライアントの接続を切断せず、別の属性のストリームに切り換えて配信を続けることが可能になる。

（実施形態９）
上述した実施形態７，８では、映像ストリームの各属性に優先度の情報が設定されたが、本実施形態では、クライアントに優先度が設定され、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する。

本実施形態に係る映像配信システムの構成は実施形態８と同様である。すなわち、本実施形態に係る映像配信システム構成は図１に示されたもので、また、メモリ１０４に格納される内容は、図２０に示されたとおりである。

また、本実施形態におけるマルチストリーム作成処理も、基本的には実施形態３で説明した図３のフローチャート、あるいは、実施形態４で説明した図１３のフローチャートに従って行われ、ステップＳ３６１における配信制御処理は、図２１のフローチャートに従って行われる。また、実施形態８と同様で、ステップＳ５１０５における優先度別選択肢作成処理は、図２３のフローチャートではなく、図２７のフローチャートに従って行われる。

ただし、優先度テーブル２８０のデータ構造は実施形態８におけるそれ（図２４）とは異なっている。図２８に、本実施形態における優先度テーブル２８０の構造例を示す。実施形態８における優先度は、図２４のとおり、映像ストリームの属性に対して設定されたが、本実施形態における優先度は、図２８に示すように、クライアント（ビューワ）に対して設定される。

この優先度を示す設定値は映像配信サーバ１００において、管理者の操作に従って変更が可能であることはもちろんであるが、クライアントからの指示に応じて当該クライアントの優先度を示す設定値を変更することも可能である。

例えば、各クライアントは、映像配信サーバ１００に発行する接続要求イベントに、要求映像属性の他、そのクライアントの優先度を示す情報を含めることが可能である。映像配信サーバ１００はこの接続要求イベントを受け取ると、それに含まれている優先度を示す情報でもって優先度テーブル２８０の該当部分を更新することになる。

これに関連して、本実施形態において実施形態８とは相違する動作について説明する。

まず、図２１の配信制御処理について。ステップＳ５１０１では、接続情報２６０を読み込むほか、接続要求イベントに含まれる要求画像属性を読み込む。さらに、接続要求イベントにそのクライアントの優先度の情報も含まれている場合にはその情報も読み込む。

次に、図２７の優先度別選択肢作成処理について。ステップＳ５７０１では、図２８に示したような優先度テーブル２８０および、ステップＳ５１０１で読み込んだ要求画像属性ならびにそのクライアントの優先度の情報を読み出す。ここでクライアントの優先度の情報が読み出された場合には、その情報でもって優先度テーブル２８０の該当部分を更新する。

ステップＳ５７０２では、ストリーム負荷データ２５０（図８）に記述された各ケースの負荷に、優先度テーブル２８０（図２８）に記述された当該クライアントの優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ２９０を作成する。この場合の優先度別ストリーム負荷想定データ２９０の例を図２９に示す。

なお、クライアント側で優先度の指定がなされなかったために接続要求イベントにそのクライアントの優先度の情報が含まれていなかった場合で、かつ、優先度テーブル２８０にそのクライアントが登録されていない場合には、映像配信サーバ１００で予め設定されたデフォルト値（例えば２０）が用いられる。

以上、実施形態８との相違点を説明した。これ以外は実施形態８と同様な処理が行われる。

以上説明した実施形態９によれば、映像配信サーバ１００に接続が可能な（すなわち、映像配信サーバ１００より映像ストリームの配信を受けることが可能な）クライアントに優先度が設定され、この優先度および要求画像属性に基づいて、映像配信サーバ１００の余力の範囲内で提供可能な属性の映像ストリームの選択肢が作成される。これにより、接続を要求するクライアントによって提示される選択肢の内容が異なるようになる。このため、優先度が高く設定されたクライアントほど、処理負荷の大きい属性の映像ストリームまでもが選択肢に含まれるようになり、サーバの能力の範囲内で、より多くの能力が分配されるようになる。

なお、上記の例では、クライアントに優先度が設定されたが、同様の考え方で、ユーザに優先度を設定し、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する、というバリエーションを考えることもできる。たとえば、映像配信サーバ１００が、クライアントから接続要求イベントを受け取ったことに応答してそのクライアントに対しユーザ認証処理を実行するように構成しておき、このユーザ認証を経てユーザの優先度が設定されるようにすればよい。

（実施形態１０）
実施形態３では、図１１に示したような配信制御処理のうち、とりわけステップＳ１００１〜Ｓ１０１０の処理によって、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。

また、実施形態７では、図２１に示した配信制御処理のうち、とりわけステップＳ５１０１〜Ｓ５１０６の処理によって、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。

これらの処理は、映像配信サーバ１００において選択肢を作成するための評価工程と考えることができる。

また、クライアント側の処理例について説明した実施形態６では、図１６に示したマルチストリーム受信処理では、ステップＳ２２０４において選択肢限定処理が行われる。この選択肢限定処理においては、とりわけ図１７に示すステップＳ２３０１〜Ｓ２３０６の処理によって、限定された選択肢が求められた。そして、図１６のステップＳ２２０５で映像要求イベントが発行された。これらは、受信ストリームを選択的に要求するための選択要求工程と考えることができる。

本実施形態では、上記したような評価工程や選択要求工程を実現する手段をそれぞれ独立した処理モジュールとして構成することより、選択肢の評価基準や受信ストリームの選択基準に自由度を持たせることを容易にする。

本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。また、クライアント１０９の構成は実施形態６で説明した図１４の構成と同様である。ただし、クライアント１０９のメモリ２００３に格納される内容は、図３０に示すとおりである。これは実施形態６に係る図１５とほぼ同様であるが、対照すると分かるように、本実施形態に係る図３０にはベンチマークプログラム２１４０のかわりに、選択要求プログラム２１４５が含まれている。

他方、映像配信サーバ１００のメモリ１０４に格納される内容は、図３１に示すとおりである。これは実施形態７に係る図２０とほぼ同様であるが、対照すると分かるように、本実施形態に係る図３１には、選択肢評価プログラム２４０が追加的に含まれている。

図３２は、本実施形態における映像配信サーバ１００による選択肢評価処理を示すフローチャートである。このフローチャートに対応するプログラムが選択肢評価プログラム２４０である。

まずステップＳ６１０１で、評価に必要な情報（接続情報２６０、接続要求イベントから抽出される要求画像属性、上限値Ｘ等を含む。）を読み込む。次にステップＳ６１０２で、読み込んだ情報を基に、評価関数Ｓにより選択肢が求められる。

たとえば、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの候補を選択肢としてクライアントに通知するようにした実施形態３についていえば、評価関数Ｓは、図１１に示したステップＳ１００２（全体負荷Ｆの計算）、ステップＳ１００８（余力Ｙの計算）、およびステップＳ１００９（選択肢の生成）の各処理を実現する関数である。

また、映像配信サーバ１００の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して求め、それを選択肢としてクライアントに通知するようにした実施形態７についていえば、評価関数Ｓは、図２１に示したステップＳ５１０２（全体負荷Ｆの計算）、ステップＳ５１０４（余力Ｙの計算）、およびステップＳ５１０５（優先度別選択肢作成処理）の各処理に実現する関数である。

選択肢評価プログラム２４０は配信制御プログラム２２０から独立したモジュールであるから、これが配信制御プログラム２２０に組み込まれている場合に比べれば、上記のように評価関数Ｓを任意に変更することが大幅に容易になる。これに伴い、選択肢評価プログラム２４０がこのような評価関数Ｓを有する以上、評価関数Ｓによって実現される処理部分については、もはや配信制御プログラム２２０自体が有している必要はない。

そして、ステップＳ６１０３で、その求められた選択肢の情報などを接続要求イベントの発行元のクライアントに通知する。

図３３は、本実施形態におけるクライアント１０９による選択要求処理を示すフローチャートである。このフローチャートに対応するプログラムが選択要求プログラム２１４５であり、ＣＰＵ２００２によって実行される。

まず、ステップＳ６２０１で、接続要求イベントが発行されているかどうかを判断する。ここで接続要求イベントが発行されていなければステップＳ６２０２に進み、実施形態６のマルチストリーム受信プログラム２１００によるステップＳ２２０２と同様の処理で、接続要求イベントを発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。

一方、ステップＳ６２０１において接続要求イベントが発行されていない場合にはステップＳ６２０３に進み、評価関数Ｇによって、要求される映像選択が行われる。たとえば、実施形態６についていえば、評価関数Ｇは、選択肢限定プログラム２１２０を呼び出す処理に相当する。

次に、ステップＳ６２０４で、評価関数Ｇの結果に基づき映像要求が可能かどうかを判断する。映像要求が可能でないと判断した場合にはステップＳ６２０５に進み、評価関数Ｇの結果に応じた接続要求を決定し、続くステップＳ６２０２で接続要求イベントを送信発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。この際、評価関数Ｇの結果によっては接続要求自体をやめるようにしてもよい。一方、ステップＳ６２０４において評価関数Ｇの結果に基づき映像要求が可能と判断した場合にはステップＳ６２０６に進み、実施形態６のマルチストリーム受信プログラム２１００によるステップＳ２２０５と同様に映像要求イベントを発行してこれを映像配信サーバ１００に送信し、その後この選択要求処理を終了する。

本実施形態は、映像配信サーバ１００において、選択肢の生成に係る処理部分を配信制御プログラム２２０から独立したモジュールで構成したことにその特徴がある。これにより、任意の評価関数Ｓを容易に記述することができる。

また、クライアント１０９においても同様に、接続要求イベントおよび映像要求イベントの発行に係る選択要求処理部分をストリーム受信プログラム２１００から独立したモジュールで構成した。これにより、任意の評価関数Ｇを容易に記述することができる。

（実施形態１１）
以下では、実施形態１０で説明した評価関数ＳまたはＧのバリエーションについて説明する。

例えば、マルチストリーム配信を対価の支払いに応じた優先度の更新を実現することができる。

まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４５によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する対価（金額）情報とを接続要求イベントに含めてこれをステップＳ６２０２で発行する。

これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に対して支払われる対価の情報が読み込まれる。

ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同等である。ただし本実施形態は、読み込んだ対価に応じて当該接続要求に係る優先度を更新する処理を含む（優先度テーブル２８０が更新される。）。例えば対価１００円につき優先度を１上げることができる。具体例を示すと、例えば優先度１０のビューワのユーザが１００円支払うことで優先度９とすることができる。このようにユーザは対価を払うことで優先度を上げて接続することができる。

また、例えば、接続回数に応じたいわゆるポイント加算による優先度の更新を実現することができる。

まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４５によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報を接続要求イベントに含めてこれをステップＳ６２０２で発行する。

これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に対するユーザ認証情報が読み込まれる。

ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同様である。ただし本実施形態は、ユーザ別にその接続回数に応じたポイントを管理し、ポイント数に応じて優先度を更新する（優先度テーブル２８０が更新される。）。例えば、ユーザＡのポイント累計が１００ポイントとなった時点でユーザＡの優先度を１上げるようにする。具体例を示すと、例えば優先度１０のビューワのユーザが１００回の接続を行うことで優先度９とすることができる。このようにユーザは接続を重ねることで優先度を上げて接続することができる。

また、例えば、マルチストリーム配信を競り落とすことによる優先度の更新を実現することができる。

まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４０によるステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する入札金額（オークション）情報を接続要求イベントに含めてこれをステップＳ６２０２で発行する。

これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、接続要求に係る入札金額の情報が読み込まれる。

ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同様である。ただし本実施形態は、読み込んだ入札金額に応じて当該接続要求に係る優先度を更新する処理を含む（優先度テーブル２８０が更新される。）例えば、複数のユーザＡ、Ｂ、Ｃがそれぞれ、１００円、２００円、３００円で接続要求した場合、Ｃの優先度を０、Ａ、Ｂの優先度を１００とすることで、実質的にユーザＣのみを優先的に接続させるようなことができる。

また、例えば、映像配信サーバ１００の余力がなく接続をあきらめた場合に、後に使えるポイント、クーポンなどを発行してもらうことに伴う優先度の更新を実現することができる。

まず、クライアント１０９は、実施形態１０の選択要求プログラム２１４０のステップＳ６２０１と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、特定のストリーム接続の要求とを接続要求イベントに含めてこれをステップＳ６２０２で発行する。

これに応じて、映像配信サーバ１００は、実施形態１０の選択肢評価プログラム２４０のステップＳ６１０１と同様の処理において、ユーザ情報とストリーム属性が読み込まれる。

ステップＳ６１０２の評価関数Ｓは実施形態１０とほぼ同等である。ただし本実施形態は、受け取った特定のストリームへの接続要求が実現できない際（選択肢に含ませることができない場合）に、ユーザに対して所定数のポイントを発行し、一定期間内に同一のユーザが接続してきた際にこのポイント情報に応じて優先度を更新する処理を含む（優先度テーブル２８０が更新される。）。例えば、１ポイントにつき優先度を１上げることができる。これにより、当初の接続が拒否されたユーザが報われるかたちで接続を実現することができる。

以上のように、対価、接続数、ポイントなどによって、特定の優先度を上げることについて述べたが、もちろん、逆に、該当クライアント（またはユーザ）以外のクライアント（またはユーザ）の優先度を下げることによっても同様の効果を得ることができる。この場合、図２７の優先度別選択肢作成プログラム２３０によるステップＳ５７０５で述べたように、減算されたユーザの方が接続拒否対象となる場合が出てくることとなり、実質的に他のユーザの優先度を上げることが実現できる。なお、このステップＳ５７０６で接続拒否する場合には、接続拒否の対象となった優先度を初期値に戻しておくこともできる。初期値に戻さない場合は、ユーザが何らかの対価、ポイントなどを払うことで元に戻していくことが実現されるし、初期値に戻す場合は初期接続において皆平等ということが実現される。

（実施形態１２）
評価関数ＳおよびＧに関して、更に別のバリエーションを説明する。

図３４は、本実施形態におけるストリーム負荷データの例を示している。このデータ構造は図８に示したストリーム負荷データと同様であるが、画像サイズ６４０ｘ４８０のバリエーションとして、３２０ｘ２４０の映像を拡大することにより６４０ｘ４８０とした映像ストリームが加えられている。同図によれば、通常の６４０ｘ４８０の映像ストリームについては、カメラ制御ありのときの負荷が１７、カメラ制御なしのときの負荷が１６であるのに対し、３２０ｘ２４０の映像を拡大して６４０ｘ４８０とした映像ストリームについては、カメラ制御ありのときの負荷が９、カメラ制御なしのときの負荷が８となっており、負荷が大きく低減されることがわかる。なお、これは画像サイズ６４０ｘ４８０の映像ストリームについての一例であり、他のサイズの映像ストリームについても同様な設定をなしうる。ただしここでは、それらの記述を省略した。

さて、処理対象の接続要求イベントを発行したクライアントが１０９−５であり、現在、別の４つのクライアント（１０９−１〜４）が接続されており、そのときの接続情報２６０が図２２に示すとおりであると仮定する。また、上限値Ｘは７０に設定されている。図２２の接続情報２６０を参照すると、クライアント１０９−１〜４はそれぞれ、
（１）８００ｘ６００、制御なし
（２）１６０ｘ１２０、制御あり
（３）６４０ｘ４８０、制御なし
（４）８００ｘ６００、制御なし
の画像属性を持つ映像を要求していることがわかる。図３４のストリーム負荷データ２５０を参照すると、それぞれの要求にかかる負荷は、２５，２，１６，２５である。そして、全体負荷ＦはＦ＝２５＋２＋１６＋２５＝６８である。ここで、クライアント１０９−５が「６４０ｘ４８０、制御あり」の接続要求を発行したとする。このクライアント１０９−５の要求にかかる負荷ｆは、図３４のストリーム負荷データ２５０を参照すると、ｆ＝１７である。そうすると、この場合は、Ｆ＋ｆ＝６８＋１７＝８５となり、上限値Ｘ＝７０を超えており、このままではクライアント１０９−５の要求どおりの接続は拒否せざるを得ない。

そこで、本実施形態では、図３４のストリーム負荷データ２５０に基づいて、図１１のステップＳ１００９のような処理いったん作成される選択肢から、通常の「６４０ｘ４８０、制御なし」を外し、その代替として、３２０ｘ２４０の拡大バージョンである「６４０ｘ４８０、制御なし」を加える。さらに、クライアント１０９−５が要求している「６４０ｘ４８０、制御あり」についても、通常の「６４０ｘ４８０、制御なし」ではなく３２０ｘ２４０の拡大バージョンである「６４０ｘ４８０、制御なし」を代用する。これが実現すれば、クライアント１０９−５の接続を確立した場合の全体負荷Ｆ＋ｆはＦ＋ｆ＝２５＋２＋８＋２５＋９＝６９となり、上限値７０を越えずに全て接続することが可能となる。このような調整の後、接続要求選択肢変化イベントを発行するようにすればよい。

そこで、本実施形態では次のような処理を行う。まず、現在の全体負荷Ｆ（クライアント１０９−１〜４にかかる負荷）と処理対象の接続要求に対する負荷（クライアント１０９−５にかかる負荷）とを推定し、両者の負荷の合計（すなわち、クライアント１０９−５の接続を確立した場合の全体負荷）が上限値Ｘを超えるか否かを判定する。ここで上限値Ｘを超える場合には、ストリーム負荷データに基づいて、いったん抽出した候補の少なくともいずれかを、近似的な属性（要求よりも小さなサイズの画像を拡大させたもの）を有する負荷の小さい別の候補によって代替することを、該当する他のクライアントおよび／またはクライアント１０９−５に求める。この求めに他のクライアントおよび／またはクライアント１０９−５が応じ、これにより、クライアント１０９−５の接続を確立した場合の全体負荷が上限値Ｘを下回ることになれば、クライアントからの当初の要求に近い接続を実現できることになる。

また、クライアント側でも、図３３のステップＳ６２０３に示したような評価関数Ｇによって、例えば「６４０ｘ４８０、制御なし」要求時に、それが選択不可の場合には、３２０ｘ２４０を拡大したバージョンの「６４０ｘ４８０、制御なし」で代用して、ステップＳ６２０５で再度選択させるという実施形態も、同様に可能である。

（実施形態１３）
上述の各実施形態では、映像配信サーバ１００の負荷は、各ケースごとの負荷があらかじめ記述されたテーブル（ストリーム負荷データ）に基づいて推定された。この場合、クライアントの接続状態によっては推定と実際とで差が開き、実際にはサーバの処理能力に余裕がある場合であってもクライアントの接続を拒否してしまったり、データ量の少ないストリームの選択肢しか生成されなかったりする場合がある。

そこで、本実施形態では映像配信サーバ１００のＣＰＵの負荷状態を実際に測定することで、この実測値を用いてサーバの能力をより無駄なく使用するようにする。

本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。ただし、メモリ１０４には、図３５に示すように、マルチストリーム作成プログラム２１０、配信制御プログラム２２０、カメラ制御プログラム７１０、接続情報２６０に加え、ＣＰＵ負荷測定プログラム１３１０および、そのＣＰＵ負荷測定プログラム１３１０の実行により生成されるＣＰＵ負荷データ１３２０が格納されている。ＣＰＵ負荷データ１３２０は、所定のデータ送信レート（例えば、１ｋｂｐｓ）あたりのデータ配信にかかるＣＰＵ負荷の指標を表す。

図３６はＣＰＵ負荷データ１３２０の構造例を示す図である。３４０１はシステムの初期状態でのＣＰＵの処理能力をあらわす値（無負荷データ）、３４０５は８００ｘ６００のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０２は６４０ｘ４８０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０３は３２０ｘ２４０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値、３４０４は１６０ｘ１２０のサイズの画像を圧縮する場合のＣＰＵの必要処理能力を示す値である。３４０６は配信時にかかるＣＰＵの必要処理能力を示す値である。

また、本実施形態における接続情報２６０は、図３９に示すようなデータ構造を有する。本実施形態における接続情報２６０には、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズ、ならびにそのクライアントの接続に係る画像送信レートが記述されている。

図３７は、本実施形態におけるマルチストリーム作成処理を示すフローチャートである。このフローチャートは図３とほぼ同様であるが、相違する点は、本実施形態では、ステップＳ３０１とＳ３０２との間で、ステップＳ１３０１としてＣＰＵ負荷測定プログラム１３１０が起動され点と、ステップＳ３６１における配信制御処理が、図３８のフローチャートに従って行われる点である。

ステップＳ１３０１において、ＣＰＵ測定プログラム１３１０が起動すると、まず、圧縮処理も動いておらずクライアントも接続されない初期状態でのＣＰＵ負荷が測定される。ここでは、一定時間内に特定の処理を行った回数を基本としてＣＰＵの処理能力が測定され、得られた値がＣＰＵの処理能力の上限値データ（無負荷データ）３４０１としてメモリ１０４上に保存される。

次に圧縮処理にかかるＣＰＵ負荷を測定するために、圧縮処理が開始される。このとき、画像サイズ毎のＣＰＵ負荷が無負荷状態の場合と同様の方法で測定される。これにより１６０ｘ１２０、３２０ｘ２４０、６４０ｘ４８０、８００ｘ６００の４種類のサイズについて圧縮処理で必要とされるＣＰＵの負荷がそれぞれ測定されて、圧縮負荷基準値データ３４０４、３４０３、３４０２、３４０５としてそれぞれメモリ１０４上に保存される。

次に、ステップＳ３６１における配信制御処理を、図３８のフローチャートを用いて説明する。

まず、ステップＳ３３０１で、接続要求イベントに含まれる要求画像属性を読み込み、ステップＳ３３０２で、図３９に示したような接続情報２６０を読み込む。

次に、ステップＳ３３０３で、接続情報２６０の各接続ごとに送信を行う画像データサイズとＣＰＵ負荷データ２５０を掛け合わせた負荷データ、さらに要求画像の属性毎の圧縮にかかるＣＰＵ負荷データを加算していくことで全体負荷Ｆ３０が総和として求められる。

例えば、図３９に示した接続情報２６０の場合、クライアント（ビューワ）１０９−１と１０９−２の接続があり、それぞれ６４０ｘ４８０と１６０ｘ１２０の画像で、画像送信レート３０の属性を持つ映像を要求していることがわかる。ここで、６４０ｘ４８０の画像データサイズをＤ３００１ｋｂｙｔｅ、１６０ｘ１２０の画像データサイズをＤ３００３ｋｂｙｔｅ、単位送信レートあたりのＣＰＵの配信負荷データ（３４０６）Ｆ３００６、６４０ｘ４８０のデータ圧縮にかかる負荷データ（３４０２）をＦ３４０２、１６０ｘ１２０のデータ圧縮にかかる負荷データ（３４０４）をＦ３４０４、とすると、全体負荷Ｆ３０は、
Ｆ３０＝Ｄ３００１×８×Ｆ３００６×３０
＋Ｄ３００３×８×Ｆ３００６×３０
＋Ｆ３４０２＋Ｆ３４０４
となる。

次に、ステップＳ３３０４で、今回要求されている属性に対する負荷ｆ３０を同様の方法で求める。例えば、３２０ｘ２４０の画像属性を持つ画像が要求されている場合、画像サイズをＤ３００２ｂｙｔｅ、３２０ｘ２４０のデータ圧縮にかかる負荷データ（３４０３）をＦ３４０３、とすると、
ｆ３０＝Ｄ３００２×８×Ｆ３００６×３０＋Ｆ３４０３
となる。

ステップＳ３３０５で、はじめに実測された無負荷データすなわち上限値（３４０１）をＸ３０として読み込み、ステップＳ３３０６で、このＸ３０とＦ３０＋ｆ３０と比較する。

比較の結果、Ｘ３０がＦ３０＋ｆ３０より大きい場合には、今回要求されている接続を許可してもサーバの処理の上限を超えることはない。そこでこの場合には、ステップＳ３３０７に進み、要求されている接続を接続情報２６０に追加登録してメモリ１０４に保存する。その後、ステップＳ３３０８で映像要求イベントを発生して、この配信制御処理を終了する。

一方、ステップＳ３３０６の比較の結果、Ｘ３０がＦ３０＋ｆ３０以下である場合には、今回要求されている接続を許可するとサーバの処理能力の上限を超えてしまう。そこでこの場合には、ステップＳ３３０９で、接続要求に対する拒否応答を返し、その後この配信制御制御処理を終了する。

ここで、要求されている接続の画像サイズがすでに配信を行っている接続と同一の画像サイズである場合、画像圧縮にかかるＣＰＵ負荷をさらに追加する必要はない。例えば、すでに配信を行っている１６０ｘ１２０の画像サイズを持つ画像が要求されている場合、画像サイズをＤ３００３ｂｙｔｅとし、画像送信レートを３０とすると、
ｆ３０＝Ｄ３００２×８×Ｆ３００６×３０
となる。

また、複数のネットワークインターフェースを持つシステムの場合、例えば有線ＬＡＮ接続と無線ＬＡＮ接続、モデム接続ではそれぞれ、データ配信にかかるＣＰＵの負荷に大きな違いがある。このような場合、それぞれのインターフェース毎に配送負荷情報を持つことでより正確なＣＰＵの負荷状況を知ることが可能となる。

本実施形態では特定のデータ送信レートにかかるＣＰＵの負荷データを一定のものとして扱ったが、実際に送信を行い、ＣＰＵの負荷データを測定することでより正確なＣＰＵに対する負荷状況を求めることでより好適なマルチストリーム配送を行うこともできる。

以上のようにすることで、映像配信システムの処理能力の上限値以下で、マルチストリーム配信が可能となる。

（実施形態１４）
上述した実施形態１０〜１２では、映像配信サーバ１００における、余力の範囲内で提供可能な映像ストリームの属性の候補の抽出に係る処理部分や、クライアント１０９における、接続要求イベントおよび映像要求イベントの発行に係る選択要求処理部分を独立のモジュールで構成し、これらの処理部分にはさまざまなバリエーションのアルゴリズムを適用可能であることを示した。以下では、上記映像ストリームの候補の抽出処理における抽出基準または抽出方針や、上記選択要求処理における選択基準または選択方針のことを、「ポリシー」とよぶ。そして、本実施形態では、このポリシーの変更の要求（ポリシー変更要求）を受け付け、現在使用している評価関数を、要求されたポリシーに応じた評価関数に切り替えることを可能にする。

図４０は、本実施形態に係る映像配信システムの概略構成を示す図である。上述の各実施形態と同様に、映像配信サーバ１００は、ネットワーク１０８を介して、クライアント（ビューワ）１０９に接続される構成である。ビューワ１０９は基本的には複数であり、ネットワーク１０８を介して映像配信サーバ１００より配信されたデータを受け取り表示する。より具体的には、本実施形態に係る映像配信システムの構成は図１に示した構成と同様である。また、クライアント１０９の構成は実施形態６で説明した図１４の構成と同様である。

ただし、クライアント１０９のメモリ２００３に格納される内容は、図４１に示すとおりである。すなわち、メモリ２００３には、ストリーム受信プログラム２１００、ビューワプログラム２１３０、選択要求プログラム２１４５（選択肢限定プログラム２１２０などはこれに内包される。）、そして、ビューワポリシー切り替えプログラム２１４６が含まれている。

本実施形態の選択要求プログラム２１４５が、実施形態１０と異なるのは、ビューワポリシー切り替えプログラム２１４６によって、評価関数Ｇが置き換えられることである。

一方、映像配信サーバ１００のメモリ１０４の格納内容は図４２に示すとおりで、マルチストリーム作成プログラム２１０、配信制御プログラム２２０、選択肢評価プログラム２４０（優先度別選択肢作成プログラム２３０などはここに内包される。）、サーバポリシー切り替えプログラム２４５、ポリシーテーブル２４６、接続情報２６０などが格納されている。

本実施形態の選択肢評価プログラム２４０が、実施形態１０と異なるのは、サーバポリシー切り替えプログラム２４５によって、評価関数Ｓが置き換えられることである。

サーバポリシー切り替えプログラム２４５による映像配信サーバ１００の動作を図４３に示す。

ステップＳ７２０１でイベントを待つ。ステップＳ７２０２は、検出されたイベントがポリシー変更イベントかどうかを判断するステップである。ポリシー変更イベントは、変更したいポリシーの種別の情報を含む。検出されたイベントがポリシー変更イベントであった場合、ステップＳ７２０３でそのポリシー変更イベントに含まれるポリシーの種別の情報に応じてサーバ評価関数Ｓを置き換える。なお、このポリシー変更イベントは、例えばサーバ管理のためのＷｅｂページや設定ツールによって生成されるメニュー選択などで実現される。また、ポリシー変更イベントはｈｔｔｐやＲＰＣ接続などで、ネットワーク１０８を介して、遠隔地から変更イベントを受け付けてもよい。ステップＳ７２０４では、例えば実施形態１３の接続情報２６０（図３９）と同様な情報から接続先のクライアント（ビューワ）に対してビューワポリシー変更イベントを発行し、その後、ステップＳ７２０１のイベントループに戻る。

ステップＳ７２１０における終了イベントによって、このサーバポリシー切り替えプログラム２４５が終了する。

次に、ビューワポリシー切り替えプログラム２１４５によるクライアント１０９の動作を図４４に示す。

ステップＳ７３０１でイベントを待つ。ステップＳ７３０２でポリシー変更イベントがあると、ステップＳ７３０３で、そのイベントに含まれるポリシーの種別の情報に応じてビューワ評価関数Ｇを置き換え、その後ステップＳ７３０１のイベントループに戻る。ポリシー変更イベントはｈｔｔｐやＲＰＣ接続などで、ネットワーク１０８を介して、遠隔地から変更イベントを受け付けてもよい。ステップＳ７３１０における終了イベントにより、このビューワポリシー切り替えプログラム２１４５は終了する。

上記したステップＳ７２０３やステップＳ７３０３で置き換えられる評価関数は例えば、図４５に示すようなポリシーテーブルを用いて実現される。例えば、「解像度優先」ポリシーでは、図２４のサーバの優先度テーブルで示されるような優先度において、８００ｘ６００が優先度０、６４０ｘ４８０が優先度１０、３２０ｘ２４０が優先度２０、１６０ｘ１２０が４０で、カメラ制御ありがそれぞれ優先度＋５であるような場合の、評価関数Ｓ１が考えられる。

また、「フレームレート優先」ポリシーでは、ストリーム負荷の軽いものを優先して、８００ｘ６００が優先度３０、６４０ｘ４８０が優先度２０、３２０ｘ２４０が優先度１０、１６０ｘ１２０が優先度０で、カメラ制御ありがそれぞれ優先度＋５であるような場合の、評価関数Ｓ２が考えられる。

また「サーバ最適」ポリシーでは、代替ストリームを用いてでもサーバの負荷上限を超えない、サーバにとってより適した選択肢を提示する評価関数Ｓ３が考えられる。

また、「クライアント最適」ポリシーでは、代替ストリーム不可で、クライアントの要求を最大限に尊重した評価関数Ｓ４が考えられる。

ビューワ側の評価関数Ｇに関しても同様である。

このようにすることで、選択的なマルチストリーム配送を行う際の配送ポリシーを自由に変更することができる。

この際、映像配信サーバ１００、あるいはクライアント１０９上の実際の負荷が把握できていることと、ストリームの負荷が把握できていること、また、ストリームの代用などのルールが評価関数に組み込めることが必須であり、ポリシーテーブルに示されたポリシーと評価関数の対応がそれを実現している。

（実施形態１５）
実施形態１４では、あらかじめ定められたポリシーを切り替えるものであったが、本実施形態では、ポリシーサーバによって配送ポリシーを入れ替えることで、より柔軟に多様な環境に対応する。

図４６は、本実施形態に係る映像配信システムの概略構成を示す図である。実施形態１４と同様に、映像配信サーバ１００は、ネットワーク１０８を介して、クライアント（ビューワ）１０９に接続される。本実施形態ではこれに加えて、ネットワーク１０８にポリシーサーバ２００が接続されている。映像配信サーバ１００およびクライアント１０９におけるメモリの内容は実施形態１４と同様である。また、ポリシーサーバ２００は、映像配信サーバ１００と同様に一般的なコンピュータで実現できるものであるからここではその構成の説明は省略するが、そのメモリには、ポリシー変更プログラムが格納されている。

本実施形態におけるサーバポリシー切り替えプログラム２４５による映像配信サーバ１００の動作は、実施形態１４と同様、図４３のフローチャートに示したとおりであるが、ステップＳ７２０２では、ポリシー変更イベントは、後述するようにポリシーサーバ２００から送付されてくる。また、本実施形態におけるビューワポリシー切り替えプログラム２１４６によるクライアント１０９の動作は、実施形態１４と同様、図４４のフローチャートに示したとおりであるが、ステップＳ７３０２では、ポリシー変更イベントは、ポリシーサーバ２００から送付されてくる。

評価関数Ｓや評価関数Ｇは、例えばスクリプト言語などで書かれていてもよく、具体的にはそのスクリプトなどがポリシーサーバ２００から、ネットワーク１０８を介して送られてくることで、それを受け取り、評価関数を入れ替えることができる。評価関数はプログラムのバイナリなどのオブジェクト形式などでももちろんよい。

次に、ポリシーサーバ２００によるポリシー変更処理について説明する。図４７は、本実施形態におけるポリシーサーバ２００によるポリシー変更処理を示すフローチャートである。このフローチャートに対応するプログラムが先述のポリシー変更プログラムに含まれる。

まず、ステップＳ７６０１で、図４８に示すようなポリシーメニューを表示する。これは例えばグラフィカルユーザインタフェース（ＧＵＩ）として実現される。

次に、ステップＳ７６０２で、ポリシーメニューからポリシーが選択されると、実施形態１４の図４５で示したようなポリシーテーブルによって選択されたポリシーに対応する評価関数を求め、ステップＳ７６０３で、ポリシー変更イベントと共に対応する評価関数の情報を映像配信サーバ１００およびビューワ１０９に送付する。

また、さらに、送付する評価関数に対して、例えばネットワーク帯域などのシステムの属性によって、評価関数の属性を変更して送付することもできる。

具体的には、ネットワーク帯域が狭い場合には、例えば図３４に示したストリーム負荷データ２５２と同様な負荷テーブルで、ネットワーク帯域１０００ＭＨｚで０、１００ＭＨｚで１、１０ＭＨｚで５などの負荷を加えた形での、評価関数を送付する。

こうすることで、マルチストリームの映像配信システムや、ビューワ単体での負荷評価ではなく、システム全体としての評価を可能とする評価関数を実現できる。

以上のように、ポリシーサーバ２００によって、映像配信サーバ１００とビューワ１０９にポリシー変更イベントを発行し、評価関数を入れ替えることにより、システム全体としてのマルチストリーム配送の多様性、利便性を実現できる。

また、評価関数が映像配信サーバ１００やビューワ１０９に組み込まれていないことから、一般的なアップグレードに対応しやすいだけでなく、システム全体の負荷などが変った際に、評価関数を適宜正しく直すことができる。

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

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（図３〜６のいずれかに示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。

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

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

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

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

図１は、本発明の実施形態に係る映像配信システムの構成図である。 図２は、実施形態１における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図３は、実施形態１におけるマルチストリーム作成処理を示すフローチャートである。 図４は、実施形態１におけるストリーム負荷データの構造例を示す図である。 図５は、実施形態１における接続情報の構造例を示す図である。 図６は、実施形態１における配信制御処理を示すフロチャートである。 図７は、実施形態２における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図８は、実施形態２におけるストリーム負荷データの構造例を示す図である。 図９は、実施形態１における接続情報の構造例を示す図である。 図１０は、実施形態３における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図１１は、実施形態３における配信制御処理を示すフローチャートである。 図１２は、実施形態３におけるストリーム選択肢情報の構造例を示す図である。 図１３は、実施形態４におけるマルチストリーム作成処理を示すフローチャートである。 図１４は、本発明の実施形態におけるビューワ（クライアント）の構成示す図である。 図１５は、実施形態６におけるクライアントのメモリに格納されるプログラムおよびデータを示す図である。 図１６は、実施形態６におけるマルチストリーム受信処理を示すフローチャートである。 図１７は、実施形態６における選択肢限定処理を示すフローチャートである。 図１８は、実施形態６におけるクライアントストリーム負荷データの構造例を示す図である。 図１９は、実施形態６におけるストリーム選択肢情報の構造例を示す図である。 図２０は、実施形態７における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図２１は、実施形態７における配信制御処理を示すフロチャートである。 図２２は、実施形態７における接続情報の例を示す図である。 図２３は、実施形態７における優先度別選択肢作成処理を示すフロチャートである。 図２４は、実施形態７における優先度テーブルの構造例を示す図である。 図２５は、実施形態７における優先度別ストリーム負荷想定データの例を示す図である。 図２６は、実施形態７におけるストリーム選択肢情報の例を示す図である。 図２７は、実施形態８における優先度別選択肢作成処理を示すフロチャートである。 図２８は、実施形態９における優先度テーブルの構造例を示す図である。 図２９は、実施形態９における優先度別ストリーム負荷想定データの例を示す図である。 図３０は、実施形態１０におけるクライアントのメモリに格納されるプログラムおよびデータを示す図である。 図３１は、実施形態１０における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図３２は、実施形態１０における映像配信サーバによる選択肢評価処理を示すフローチャートである。 図３３は、実施形態１０におけるクライアントによる選択要求処理を示すフローチャートである。 図３４は、実施形態１２におけるストリーム負荷データの例を示す図である。 図３５は、実施形態１３における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図３６は、実施形態１３におけるＣＰＵ負荷データの構造例を示す図である。 図３７は、実施形態１３におけるマルチストリーム作成処理を示すフローチャートである。 図３８は、実施形態１３における配信制御処理を示すフローチャートである。 図３９は、実施形態１３における接続情報の構造例を示す図である。 図４０は、実施形態１４に係る映像配信システムの概略構成を示す図である。 図４１は、実施形態１４におけるクライアントのメモリに格納されるプログラムおよびデータを示す図である。 図４２は、実施形態１４における映像配信サーバのメモリに格納されるプログラムおよびデータを示す図である。 図４３は、実施形態１４におけるサーバポリシー切り替えプログラムによる映像配信サーバの動作を示すフローチャートである。 図４４は、実施形態１４におけるビューワポリシー切り替えプログラムによるクライアントの動作を示すフローチャートである。 図４５は、実施形態１４におけるポリシーテーブルの一例を示す図である。 図４６は、実施形態１５に係る映像配信システムの概略構成を示す図である。 図４７は、実施形態１５におけるポリシーサーバによるポリシー変更処理を示すフローチャートである。 図４８は、実施形態１５におけるポリシーサーバによるポリシー変更処理において表示されるポリシーメニューの一例を示すフローチャートである。

Claims (12)

1. 映像ストリームを配信する映像配信装置であって、
   一のクライアントから配信要求を受信する受信手段と、
   映像ストリームの配信に要する負荷を示す負荷情報に基づいて、当該映像ストリームの優先度を決定する決定手段と、
   第１の映像ストリームに対応する第１の負荷情報及び第１の優先度と、第２の映像ストリームに対応する第２の負荷情報及び第２の優先度と、第３の映像ストリームに対応する第３の負荷情報及び第３の優先度とを記憶する記憶手段と、
   前記一のクライアントから受信した配信要求に対応する映像ストリームの配信の可否を、他のクライアントに映像ストリームを配信するために要する配信負荷に基づいて判定する判定手段と、
   前記判定手段により前記配信負荷に基づき前記第１の負荷情報に対応する前記第１の映像ストリームを配信しないと判定された場合、
   前記配信負荷と、前記第２の負荷情報と、前記第３の負荷情報と、解像度及びフレームレートの少なくともいずれかとに基づいて前記決定手段により決定された前記第２及び第３の優先度に基づいて前記判定手段により配信可能であると判定された前記第２及び前記第３の映像ストリームを示す選択肢情報を前記一のクライアントに通知する通知手段と、
   ポリシーの変更指示を受け付ける受付手段と、
   前記変更指示に応じて、前記第１の優先度、前記第２の優先度、前記第３の優先度を変更する変更手段と、
   とを有し、
   前記判定手段は、前記変更手段によって変更された優先度、映像ストリームの負荷情報、及び、前記配信負荷に基づいて、映像ストリームの配信可否を判定する
   ことを特徴とする映像配信装置。
2. 前記記憶手段は、
   前記第１の映像ストリームに対応する前記第１の優先度と、前記第２の映像ストリームに対応する前記第２の優先度と、前記第３の映像ストリームに対応する前記第３の優先度とを、第１のポリシーに対応付けて記憶するとともに、
   前記第１の映像ストリームに対応する第４の優先度と、前記第２の映像ストリームに対応する第５の優先度と、前記第３の映像ストリームに対応する第６の優先度とを、第２のポリシーに対応付けて記憶し、
   前記変更手段は、前記第１のポリシーから前記第２のポリシーへの変更指示に応じて、前記第１の優先度、前記第２の優先度、前記第３の優先度をそれぞれ、前記第４の優先度、前記第５の優先度、前記第６の優先度に変更する
   ことを特徴とする請求項１に記載の映像配信装置。
3. 一のクライアントから配信要求を受信する受信手段と、
   第１の画面サイズの第１の映像ストリームを配信するために要する負荷を示す第１の負荷情報、及び、前記第１の画面サイズよりも小さい第２の画面サイズの第２の映像ストリームを配信するために要する負荷を示す第２の負荷情報、及び、前記第２の映像ストリームの画面サイズが前記第２の画面サイズから前記第１の画面サイズに拡大された第３の映像ストリームを配信するために要する負荷を示す第３の負荷情報を記憶する記憶手段と、
   前記第１の負荷情報と前記第１の映像ストリームの第１の優先度とに基づいて前記第１の映像ストリームの第１の優先度別負荷情報を決定し、前記第２の負荷情報と前記第２の映像ストリームの第２の優先度とに基づいて前記第２の映像ストリームの第２の優先度別負荷情報を決定し、前記第３の負荷情報と前記第３の映像ストリームの第３の優先度とに基づいて前記第３の映像ストリームの第３の優先度別負荷情報を決定する決定手段と、
   前記配信要求を受信した時点で接続されている他のクライアントのために要する配信負荷と、前記配信要求がされた映像ストリームに対応する負荷情報とに基づいて、前記受信した配信要求に応じた映像ストリームの配信を行うか否かを判定する判定手段と、
   を有する映像配信装置の制御方法であって、
   前記判定手段により前記負荷情報と前記配信負荷とに基づいて前記配信要求に応じた前記第１の画面サイズの前記第１の映像ストリームの配信を行わないと判定された場合、
   前記第２及び前記第３の優先度別負荷情報と前記配信負荷とに基づいて配信可能であると判定された前記第２及び第３の映像ストリームを示す選択肢情報を前記一のクライアントに通知する通知ステップと、
   ポリシーの変更指示を受け付ける受付ステップと、
   前記変更指示に応じて、前記第１の優先度、前記第２の優先度、前記第３の優先度を変更する変更ステップと、
   を有し、
   前記通知ステップは、前記変更ステップで変更された優先度に応じて再決定された優先度別負荷情報と、前記配信負荷とに基づいて配信可能であると判定された映像ストリームの情報を通知する
   ことを特徴とする映像配信装置の制御方法。
4. 一のクライアントから配信要求を受信する受信手段と、
   第１の画面サイズの第１の映像ストリームを配信するために要する負荷を示す第１の負荷情報、及び、前記第１の画面サイズよりも小さい第２の画面サイズの第２の映像ストリームを配信するために要する負荷を示す第２の負荷情報、及び、前記第２の映像ストリームの画面サイズが前記第２の画面サイズから前記第１の画面サイズに拡大された第３の映像ストリームを配信するために要する負荷を示す第３の負荷情報を記憶する記憶手段と、
   前記第１の負荷情報と前記第１の映像ストリームの第１の優先度とに基づいて前記第１の映像ストリームの第１の優先度別負荷情報を決定し、前記第２の負荷情報と前記第２の映像ストリームの第２の優先度とに基づいて前記第２の映像ストリームの第２の優先度別負荷情報を決定し、前記第３の負荷情報と前記第３の映像ストリームの第３の優先度とに基づいて前記第３の映像ストリームの第３の優先度別負荷情報を決定する決定手段と、
   前記配信要求を受信した時点で接続されている他のクライアントのために要する配信負荷と、前記配信要求がされた映像ストリームに対応する負荷情報とに基づいて、前記受信した配信要求に応じた映像ストリームの配信を行うか否かを判定する判定手段と、
   を有する映像配信装置を制御するためのプログラムであって、前記判定手段により前記負荷情報と前記配信負荷とに基づいて前記配信要求に応じた前記第１の画面サイズの前記第１の映像ストリームの配信を行わないと判定された場合、前記配信装置に、
   前記第２及び前記第３の優先度別負荷情報と前記配信負荷とに基づいて配信可能であると判定された前記第２及び第３の映像ストリームを示す選択肢情報を前記一のクライアントに通知する通知ステップ、
   ポリシーの変更指示を受け付ける受付ステップ、
   前記変更指示に応じて、前記第１の優先度、前記第２の優先度、前記第３の優先度を変更する変更ステップ、
   を実行させるためのプログラムを含み、
   前記通知ステップは、前記変更ステップで変更された優先度に応じて再決定された優先度別負荷情報と、前記配信負荷とに基づいて配信可能であると判定された映像ストリームの情報を通知する
   ことを特徴とするプログラム。
5. 請求項４に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
6. 任意の映像ストリームの配信を映像配信装置に要求し、映像配信装置から映像ストリームの配信を受ける情報処理端末であって、
   第１の画面サイズよりも小さい第２の画面サイズの第１の映像ストリームを前記情報処理端末が再生するために要する負荷を示す第１の負荷情報、及び、前記第１の映像ストリームの画面サイズが前記第２の画面サイズから前記第１の画面サイズに拡大された第２の映像ストリームを前記情報処理端末が再生するために要する負荷を示す第２の負荷情報を記憶する記憶手段と、
   前記第１の負荷情報と前記第１の映像ストリームの第１の優先度とに基づいて前記第１の映像ストリームの第１の優先度別負荷情報を決定し、前記第２の負荷情報と前記第２の映像ストリームの第２の優先度とに基づいて前記第２の映像ストリームの第２の優先度別負荷情報を決定する決定手段と、
   前記映像配信装置に対して前記第１の画面サイズの映像ストリームの配信要求を送信したことに応じて、前記第２の画面サイズの前記第１の映像ストリーム、及び、前記第２の画面サイズが前記第１の画面サイズに拡大された前記第２の映像ストリームの配信が可能であることを示す選択肢情報を受信した場合、
   前記決定された前記第１の優先度別負荷情報、第２の優先度別負荷情報に応じて、前記選択肢情報に対応する前記第２の画面サイズの前記第１の映像ストリーム、及び、前記画面サイズが拡大された前記第２の映像ストリームから表示すべき映像ストリームを選択する選択手段と、
   前記選択された映像ストリームの情報を表示させる表示制御手段と、
   ポリシーの変更指示を受け付ける受付手段と、
   前記変更指示に応じて、前記第１及び第２の優先度を変更する変更手段と、
   を有し、
   前記決定手段は、前記優先度の変更に応じて優先度別負荷情報を再決定する
   ことを特徴とする情報処理端末。
7. 前記記憶手段は、
   前記第１の映像ストリームの優先度を示す前記第１の優先度と、前記第２の映像ストリームの優先度であって前記第１の優先度よりも低い第２の優先度とを、第１のポリシーと対応付けて記憶するとともに、
   前記第１の映像ストリームの優先度を示す第３の優先度と、前記第２の映像ストリームの優先度であって前記第３の優先度よりも高い第４の優先度とを、第２のポリシーと対応付けて記憶し、
   前記変更手段は、前記第１のポリシーから前記第２のポリシーへの変更指示に応じて、前記第１の映像ストリームに対応する優先度を前記第１の優先度から前記第３の優先度に変更し、前記第２の映像ストリームの優先度を前記第２の優先度から前記第４の優先度に変更する
   ことを特徴とする請求項６に記載の情報処理端末。
8. 任意の映像ストリームの配信を映像配信装置に要求する要求手段と、
   第１の画面サイズよりも小さい第２の画面サイズの第１の映像ストリームを再生するために要する負荷を示す第１の負荷情報、及び、前記第１の映像ストリームの画面サイズが前記第２の画面サイズから前記第１の画面サイズに拡大された第２の映像ストリームを再生するために要する負荷を示す第２の負荷情報を記憶する記憶手段と、
   前記第１の負荷情報と前記第１の映像ストリームの第１の優先度とに基づいて前記第１の映像ストリームの第１の優先度別負荷情報を決定し、前記第２の負荷情報と前記第２の映像ストリームの第２の優先度とに基づいて前記第２の映像ストリームの第２の優先度別負荷情報を決定する決定手段と、
   を有する情報処理端末の制御方法であって、
   前記映像配信装置に対して前記第１の画面サイズの映像ストリームの配信要求を送信したことに応じて、前記第２の画面サイズの前記第１の映像ストリーム、及び、前記第２の画面サイズが前記第１の画面サイズに拡大された前記第２の映像ストリームの配信が可能であることを示す選択肢情報を受信した場合、
   前記選択肢情報に対応する前記第１及び第２の映像ストリームのうち、再生可能な映像ストリームを前記記憶された前記第１及び第２の優先度別負荷情報に基づいて選択する選択ステップと、
   前記選択された映像ストリームの情報を表示させる表示制御ステップと、
   ポリシーの変更指示を受け付ける受付ステップと、
   前記変更指示に応じて、前記第１及び第２の優先度を変更する変更ステップと、
   を有し、
   前記選択ステップは、前記優先度の変更に応じて再決定された優先度別負荷情報に基づいて再生可能な映像ストリームを再選択する
   ことを特徴とする情報処理端末の制御方法。
9. 任意の映像ストリームの配信を映像配信装置に要求する手段と、
   第１の画面サイズよりも小さい第２の画面サイズの第１の映像ストリームを再生するために要する負荷を示す第１の負荷情報、及び、前記第１の映像ストリームの画面サイズが前記第２の画面サイズから前記第１の画面サイズに拡大された第２の映像ストリームを再生するために要する負荷を示す第２の負荷情報を記憶する記憶手段と、
   前記第１の負荷情報と前記第１の映像ストリームの第１の優先度とに基づいて前記第１の映像ストリームの第１の優先度別負荷情報を決定し、前記第２の負荷情報と前記第２の映像ストリームの第２の優先度とに基づいて前記第２の映像ストリームの第２の優先度別負荷情報を決定する決定手段と、
   を有する情報処理端末を制御するためのプログラムであって、
   前記映像配信装置に対して前記第１の画面サイズの映像ストリームの配信要求を送信したことに応じて、前記第２の画面サイズの前記第１の映像ストリーム、及び、前記第２の画面サイズが前記第１の画面サイズに拡大された前記第２の映像ストリームの配信が可能であることを示す選択肢情報を受信した場合、前記情報処理端末に、
   前記選択肢情報に対応する前記第１及び第２の映像ストリームのうち、再生可能な映像ストリームを前記記憶された前記第１及び第２の優先度別負荷情報に基づいて選択する選択ステップ、
   前記選択された映像ストリームの情報を表示させる表示制御ステップ、
   ポリシーの変更指示を受け付ける受付ステップ、
   前記変更指示に応じて、前記第１及び第２の優先度を変更する変更ステップ、
   を実行させるためのプログラムを含み、
   前記選択ステップは、前記優先度の変更に応じて再決定された優先度別負荷情報に基づいて再生可能な映像ストリームを再選択する
   ことを特徴とするプログラム。
10. 請求項９に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
11. 前記記憶手段は、
    第１の画面サイズの前記第１の映像ストリームを配信するために要する負荷を示す前記第１の負荷情報と、前記第１の画面サイズよりも小さい第２の画面サイズの前記第２の映像ストリームを配信するために要する負荷を示す前記第２の負荷情報と、前記第２の映像ストリームの前記第２の画面サイズの映像を前記第１の画面サイズの映像に拡大した前記第３の映像ストリームを配信するために要する負荷を示す前記第３の負荷情報と、前記第１、第２及び第３の優先度とを記憶し、
    前記通知手段は、
    前記他のクライアントに配信している映像ストリームの配信負荷に基づいて、前記第１の負荷情報に対応する前記第１の画面サイズの前記第１の映像ストリームを配信しないと前記判定手段により判定された場合、
    前記配信負荷と、前記第２の優先度及び前記第２の負荷情報と、前記第３の優先度及び前記第３の負荷情報とに基づいて配信可能であると前記判定手段により判定された前記第２の画面サイズの前記第２の映像ストリームと、前記第２の画面サイズの映像を前記第１の画面サイズの映像に拡大した前記第３の映像ストリームを示す選択肢情報とを、前記一のクライアントに通知する
    ことを特徴とする請求項１に記載の映像配信装置。
12. 前記記憶手段は、
    第１の画面サイズの前記第１の映像ストリームを配信するために要する負荷を示す前記第１の負荷情報と、前記第１の画面サイズよりも小さい第２の画面サイズの前記第２の映像ストリームを配信するために要する負荷を示す前記第２の負荷情報と、前記第２の映像ストリームの前記第２の画面サイズの映像を前記第１の画面サイズの映像に拡大した前記第３の映像ストリームを配信するために要する負荷を示す前記第３の負荷情報と、前記第１、第２及び第３の優先度とを記憶し、
    前記通知ステップは、
    前記他のクライアントに配信している映像ストリームの配信負荷に基づいて、前記第１の負荷情報に対応する前記第１の画面サイズの前記第１の映像ストリームを配信しないと前記判定手段により判定された場合、
    前記配信負荷と、前記第２の優先度及び前記第２の負荷情報と、前記第３の優先度及び前記第３の負荷情報とに基づいて配信可能であると前記判定手段により判定された前記第２の画面サイズの前記第２の映像ストリームと、前記第２の画面サイズの映像を前記第１の画面サイズの映像に拡大した前記第３の映像ストリームを示す選択肢情報とを、前記一のクライアントに通知する
    ことを特徴とする請求項３に記載の映像配信装置の制御方法。

Images