以下、図面を参照して本発明の好適な実施形態について詳細に説明する。以下では、多くの実施形態を説明するが、実施形態間で共通の構成や処理については共通の参照番号を付し、これにより重複した説明を回避している。ただし、共通の参照番号が付されていてもその内容が前出の構成や処理と相違する点を含む場合には、その都度その相違する点については言及することにする。
(実施形態1)
図1は、本発明の実施形態に係る映像配信システムの構成を示すブロック図である。
映像配信装置としての映像配信サーバ100は、撮像装置101からの映像信号102を受けデータを圧縮するデータ圧縮装置103、ブートプログラムや各種データを記憶するメモリ104、演算や処理の制御を行う中央処理装置(CPU)105、ネットワークに接続するためのネットワークインターフェース(Network I/F)106を含む構成である。
撮像装置101は、映像配信サーバ100の制御信号107を受け、映像信号102を出力する。なお、本実施形態では、図示のように、映像配信サーバ100と撮像装置101とは独立した構成となっているが、両者が一体となった構成であってもよい。
データ圧縮装置103は、例えば圧縮チップにより実現されるもので、映像信号を圧縮してJPEGやMPEG等の形式のデータを出力し、メモリ102に格納する。
ネットワークインターフェース(I/F)106は、例えばネットワークチップにより実現されるもので、ネットワーク108とCPU105との間のデータのI/Oの機能を提供する。
複数のクライアント(情報処理端末)109(クライアント109−1,109−2,…,109−n)はそれぞれ、ビューワとして機能するもので、ネットワーク108を介して映像配信サーバ100より配信されたデータを受け取り表示する。クライアント109は、パーソナルコンピュータ(PC)や携帯型コンピュータ(PDA)、携帯電話などによって実現されうる。
メモリ104には、図2に示すように、マルチストリーム作成プログラム210、配信制御プログラム220、ストリーム負荷データ250、接続情報260等が格納される。
図3は、本実施形態における映像配信サーバ100によるマルチストリーム作成処理を示すフローチャートである。このフローチャートに対応するプログラムはマルチストリーム作成プログラム210に含まれ、CPU105によって実行される。ここでは、640x480、320x240、160x120の画像サイズのJPEGマルチストリームを扱う例を示す。
まずステップS301において、メモリ104内の各種設定パラメータの初期設定を行う。この際、図4に示すような構造のストリーム負荷データ250や、後述するサーバ処理の上限値である設定値Xなどのロードも行われる。ストリーム負荷データ250は、例えば圧縮チップ(データ圧縮装置103)の性能に基づいて、属性としての画像サイズごとの処理負荷の値を有する。図4に示した例では、画像サイズ160x120の場合の処理負荷を基準(=1)として各画像サイズの映像配信サーバ100のストリーム配信を処理するための負荷が記述されている。図4に示すデータは予め実験して得られた値であってもよいし、推定値であってもよい。すなわち、320x240のときの処理負荷は4、640x480のときの処理負荷が16、800x600のときの処理負荷が25、となっている。
次に、ステップS302において、ステップS301で設定された撮像パラメータを用いて撮像装置101の初期設定を行う。この設定は例えば、撮像装置101への制御信号107を使用して行うことができる。
次に、ステップS303において、ステップS301で設定されたデータ圧縮パラメータを用いてデータ圧縮装置103の初期設定を行う。この設定は例えば、圧縮する画像サイズなどを含む。
続くステップS304では、割り込みなどのイベントを待つ。以下のステップS320,S330,S340,S350,S360,S370はそれぞれ、受け取ったイベントの種類を判断するステップとなる。
受信したイベントが映像要求イベントであった場合は(ステップS320,yes)、要求された画像の属性であるサイズをデータ圧縮装置103に設定し(ステップS321)、その後ステップS304のイベントループに戻る。
データ圧縮装置103より映像作成完了イベントを受け取った場合は(ステップS330,yes)、メモリ104よりその画像を取り出し(ステップS331)、図5に示すような構造の接続情報260に従って、映像要求イベントを発行したクライアントに送信する(ステップS332)。接続情報260は、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズを記述したもので、後述する処理によって接続状況の変化に応じて更新される。
クライアント109より、ネットワークインターフェース106を介して、継続映像要求イベントを受け取った場合は(ステップS340,yes)、映像要求イベントを発行してステップS321と同様の処理を行い(ステップS341)、その後ステップS304のイベントループに戻る。ここで、継続映像要求イベントとは、映像配信サーバ100からクライアント109への映像の継続的な配信を要求するイベントである。
クライアント109より、ネットワークインターフェース106を介して、接続終了イベントを受け取った場合には(ステップS350,yes)、接続情報260から該当するデータを一件削除して(ステップS351)、ステップS304のイベントループに戻る。ここで、接続終了イベントとは、映像配信サーバ100とクライアント109との接続を断つために、クライアント109より、映像配信サーバ100に対して要求されるイベントである。また、この接続終了イベントは、何らかの理由で映像配信サーバ100からクライアント109への通信が途切れてしまったような場合にも発行されうる。
以上のステップS320〜S351のような処理によって本実施形態の映像配信機構が実現される。
次に、クライアント109より、ネットワークインターフェース106を介して、接続要求イベントを受け取った場合には(ステップS360,yes)、配信制御プログラム220に基づいて、配信制御処理を実行する(ステップS361)。この接続要求イベントは、クライアントより要求された映像ストリームの属性の情報(以下「要求画像属性」という。)も含む。
以下、この映像配信サーバ100によるステップS361における配信制御処理を、図6のフローチャートを用いて説明する。
まず、ステップS601で、接続要求イベントに含まれる要求画像属性を読み込み、ステップS602で、接続情報260を読み込む。この接続情報260を参照すれば現在接続されている全クライアントを特定することができる。
次に、ステップS603で、接続されているクライアントごとに、ストリーム負荷データ250を参照して、そのクライアントに対応する負荷を読み出し加算していき、その総和を全体負荷Fとして求める。この全体負荷Fによって現在の処理負荷が推定される。
図5の接続情報260および図4のストリーム負荷データ250に基づいて一例を説明する。図5の接続情報260を参照すると、現在クライアント109−1とクライアント109−2が映像配信サーバ100に接続されている。クライアント109−1は画像サイズが640x480の映像を要求しており、一方、クライアント109−2は画像サイズが160x120の映像を要求していることが分かる。次に、図4のストリーム負荷データ250を参照すると、640x480の画像の処理負荷は16、160x120の画像の処理負荷は1であるから、この場合の全体負荷F(すなわち、現在の処理負荷)は、F=16+1=17となる。
次に、ステップS604で、今回要求されている映像に対する負荷fをストリーム負荷データ250を参照して求める。たとえば、画像サイズ320x240の映像が要求されている場合には、ストリーム負荷データ250を参照すると、今回要求されている映像に対する負荷fは、4と推定される。
今回新たに要求されている映像の配信を実行する場合には、そのときの全体の処理負荷は、現在の処理負荷(=全体負荷F)に、今回要求されている映像に対する負荷fを追加した値となる。この値が映像配信サーバ100の処理能力の限界を超える場合には、全体のパフォーマンスが落ち、円滑なストリーミングが妨げられる可能性がある。そこで、ステップS605で、ステップS301で読み込んだサーバ処理の上限値である設定値X(以下「上限値X」という。)を読み出し、ステップS606で、全体負荷Fと負荷fとの和(=今回要求されている映像の配信を実行するとした場合の全体の処理負荷)が上限値X以下に収まっているかどうか(すなわち、X≧F+fを満たすかどうか)を判断する。ここで、X≧F+fを満たす場合には、ステップS607に進み、接続要求イベントの発行元のクライアントの情報を接続情報260に登録する。その後、映像要求イベントを発行し、ステップS321と同様の処理を行う(ステップS608)。一方、X≧F+fを満たさない場合には、接続要求イベントの発行元に拒否応答を返す(ステップS609)。
ここで、上限値Xについて説明しておく。この上限値Xは、映像配信サーバ100の管理者などによって変更することのできる値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。上限値Xは固定値としてあらかじめメモリ104に設定しておいてもよいが、例えばtelnetやftp、RPCなどの機構によってメモリ104に設定するようにしてもよい。
なお従来の方式では、この上限値はクライアントの接続数などで指定されており、管理者の許可する処理能力の上限値を表すものではなかった。従来のようにクライアントの接続本数で制限した場合、大きな負荷のストリームばかりが選択されたときに、映像配信装置の処理能力を上回り、全てのストリーム配信に不具合が出てしまい、逆に、小さな負荷のストリームばかりが選択されたときには、映像配信装置の処理能力に余力があるにもかかわらず、接続数が上限に達したということだけで配信が拒否されるという事態が生じていた。
一方、本実施形態の上限値Xは単なるクライアントの接続本数等ではなく、画像処理などにかかる負荷を直接示す値であるから、映像配信サーバの処理能力をより有効に活用することができる。
説明を図3のフローチャートに戻す。上記したステップS361の配信制御処理が終了すると、ステップS304のイベントループに戻る。
終了イベントを受け取った場合は(ステップS370,yes)、ステップS371に進み、接続情報260を全件削除して、このマルチストリーム作成処理を終了する。
以上説明した実施形態1によれば、映像配信サーバにおいて、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷(F+f)が推定され、それが所定の上限値(X)を超える場合には当該要求に係る接続が拒否される。これにより、映像配信サーバ100の処理負荷が能力の限界を超えてしまい全体のパフォーマンスが落ち、円滑なストリーミングが妨げられるような事態の発生を防止することができる。
特に、組み込み機器型のカメラサーバなど、比較的に処理能力の非力な映像配信サーバにおいてはこの効果が高い。このような機器の場合、転送路の制約に対して機器の処理能力の制約が大きく、機器の性能に対して転送路の性能が上回るため、従来型の接続本数の制限や、転送量の制約などだけでは適切な配信制御を行うことができなかったが、機器の処理能力によって配信制御を行うことで、映像配信サーバの処理能力をより有効に活用することができる。
なお、本実施形態における映像配信サーバへの接続は映像の配信を目的としたものであり、それ以外の処理を目的とした接続は考慮しなかった。したがって、上記の「接続を拒否する」という表現は「映像の配信を拒否する」と等価である(以下同様。)。
また、上述の実施形態では、画像の属性が画像のサイズを示す場合の例について説明したが、画像の属性としてはこの他に、符号化/復号化、画質、フレームレート、あるいはこれらの組み合わせ等が考えられ、これらの属性についても本発明を適用することができることは容易に理解できるであろう。
(実施形態2)
上述の実施形態1では、画像の属性として、画像サイズ、画質、フレームレート等を扱い、これらに応じた映像ストリームの配信制御について説明したが、本実施形態では、このような画像属性だけでなく、撮像装置(カメラ)の制御内容を示す「処理属性」をも加味した映像ストリームの配信制御を行う。
本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。ただし、メモリ104には、図7に示すように、実施形態1と同様のマルチストリーム作成プログラム210、配信制御プログラム220、ストリーム負荷データ250、接続情報260に加えて、撮像装置101を制御する手段としてのカメラ制御プログラム710が格納されている。このカメラ制御プログラム710を実行するかどうかはユーザが任意に設定することが可能であり、カメラ制御プログラム710が実行された場合には例えば、撮像装置101の向きを巡回させる巡回処理や、動体を検知してその動体を追尾するように撮像装置101の向きを移動させる動体追尾処理などのカメラ制御が行われる。なお、これらの各処理について個々に実行する/しないをユーザが設定できることがより好ましいが、ここでは説明を簡単にするために、カメラ制御プログラム710の実行/非実行の設定だけが行われると仮定する。なお、以下では、「カメラ制御プログラム710の実行/非実行」のことを「カメラ制御あり/なし」と略記する。
カメラ制御ありの場合には、CPU105の処理は映像ストリームの配信処理だけでなく、このカメラ制御にも割かれることになる。本実施形態ではこのことを考慮して、ストリーム負荷データ250には、画像サイズごとに、カメラ制御ありの場合とカメラ制御なしの場合の処理負荷がそれぞれ記述されている。図8に、このストリーム負荷データ250の構造例を示す。同図の例では、画像サイズが160x120でカメラ制御なしの場合の処理負荷を基準(=1)として、各ケースの処理負荷が記述されている。同様に、接続情報260にも、図9に示すように、現在接続されているクライアントごとに、画像サイズに加えカメラ制御あり/なしの情報が記述されている。
本実施形態におけるマルチストリーム作成処理は基本的に実施形態1における処理(図3、図6)とほぼ同様に行われる。
なお、本実施形態の場合、図6のステップS603では、例えば次のようにして全体負荷Fが求められる。図9の接続情報260を参照すると、現在クライアント109−1とクライアント109−2が映像配信サーバ100に接続されている。クライアント109−1は、画像サイズ640x480の映像を要求し、カメラ制御は「なし」の設定である。一方、クライアント109−2は、画像サイズ160x120の映像を要求しているが、カメラ制御は「あり」の設定である。次に、図8のストリーム負荷データ250を参照すると、640x480の画像についてカメラ制御なしの場合の処理負荷は16、160x120の画像についてカメラ制御ありの場合の処理負荷は2であるから、この場合の全体負荷Fは、F=16+2=18となる。
また、今回要求されている映像ストリームの作成にかかる負荷fをストリーム負荷データ250から求めるステップS604では、たとえば、画像サイズ320x240の映像が要求され、カメラ制御ありの設定がなされている場合には、図8のストリーム負荷データ250を参照すると、負荷f=5と推定される。
上限値Xは、実施形態1と同様、映像配信サーバ100の管理者などによって変更することのできる設定値であり、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される。実施形態1では、典型的に、上限値Xは、圧縮処理の負荷の総和に対する上限値として設定されたが、本実施形態では圧縮処理のみならずカメラ制御に要する負荷を含む処理負荷の総和に対する上限値として設定されることになる。
(実施形態3)
上述の実施形態1,2は、接続要求を受け取った際に、その要求に対する映像ストリームの作成・配信を実行するとした場合における全体の処理負荷(F+f)を推定し、それが所定の上限値(X)を超えるときは当該要求に係る接続を拒否する、というものであった。
本実施形態は、上限値(X)を超えるときに当該要求に係る接続を直ちに拒否するのではなく、映像配信サーバの余力の範囲内で提供可能な映像ストリームの属性の候補を選択肢として提供する。これにより、ユーザが接続できないケースを減らし、少なくとも低負荷のストリームを提供できるようにすることがねらいである。以下の説明では基本的に実施形態2を基に、相違する点を中心に説明するが、本実施形態は実施形態1に対しても適用が可能である。
本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。ただし、メモリ104には、図10に示すように、実施形態2と同様のマルチストリーム作成プログラム210、配信制御プログラム220、カメラ制御プログラム710、ストリーム負荷データ250、接続情報260に加えて、ストリーム選択肢情報270が格納されている。また、本実施形態のストリーム負荷データ250および接続情報260はそれぞれ、実施形態2と同様に、図8、図9に示したような構造を有するものとする。
本実施形態における映像配信サーバ100によるマルチストリーム作成処理は基本的に実施形態1,2における処理(図3)とほぼ同様に行われる。ただし本実施形態では、ステップS361における配信制御処理が、図11のフローチャートに従って行われる。
まず、ステップS1001で、接続情報260を読み込む。また、実施形態1,2におけるステップS601と同様に、接続要求イベントに含まれる要求画像属性も読み込む。
次に、ステップS1002で、接続情報260およびストリーム負荷データ250を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷F(現在の処理負荷)として計算する。次に、ステップS1003で、今回要求されている映像に対する負荷fをストリーム負荷データ250を参照して求める。
次に、ステップS1004で、ステップS301で読み込んだサーバ処理の上限値Xを読み出す。上限値Xは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップS1005で、全体負荷Fと負荷fとの和(=今回要求されている映像の配信を実行するとした場合の全体の処理負荷)が上限値X以下に収まっているかどうか(すなわち、X≧F+fを満たすかどうか)を判断する。ここで、X≧F+fを満たす場合には、ステップS1006に進み、接続要求イベントの発行元のクライアントの情報を接続情報260に登録する。その後、映像要求イベントを発行し、ステップS321と同様の処理を行い(ステップS1007)、本処理を終了する。
一方、ステップS1005で、X≧F+fを満たさない場合には、ステップS1008に進み、映像配信サーバ100の余力Yを求める。映像配信サーバ100の余力Yは、上限値X−全体負荷Fにより求める。
次に、ステップS1009で、求めた余力Yに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ250から読み出し、図12に示すような構造のストリーム選択肢情報270をメモリ104に書き込む。例えば、上限値X=25、全体負荷F=18と仮定すると、余力Y=25−18=7となる。その後、図8のストリーム負荷データ250から、負荷の値が7(=余力)以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報270を構成する。この例では具体的には、「jpeg320x240、カメラ制御なし」、「jpeg320x240、カメラ制御あり」、「jpeg160x120、カメラ制御なし」、「jpeg160x120、カメラ制御あり」、が抽出され、図12に示されるようなストリーム選択肢情報270が構成される。
次に、ステップS1010で、ストリーム選択肢情報270をクライアントへ通知し、ステップS1011で、イベントを待つ。
ステップS1012において、ストリーム選択肢情報270を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップS1013に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報270の選択番号などで受け取ることにしても良い。次に、ステップS1014で、ステップS607と同様に、属性特定要求イベントの発行元のクライアントの情報を接続情報260に登録し、続くステップS1015で、映像要求イベントを発行し、ステップS321と同様の処理を行う。
また、ステップS1016において、ストリーム選択肢情報270を渡したクライアントから接続終了イベントを受け取った場合、または、ステップS1017において、ストリーム選択肢情報270をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。
以上説明した実施形態3によれば、映像配信サーバ100の余力に応じた映像ストリーム(すなわち、映像配信サーバ100全体の処理負荷が上限値Xを超えない範囲で提供が可能な映像ストリーム)の候補が選択肢としてクライアントに通知され、ユーザはこれに応じて次善の映像ストリームを選択することができる。これにより、ユーザが接続できないケースを減らすことができ、少なくとも低負荷のストリームを提供できるようになる。
なお、上記の処理例では、ステップS1005で、全体負荷Fと負荷fとの和、すなわち、今回要求されている映像ストリームの配信を実行するとした場合の全体の処理負荷、が上限値Xを超える場合に、ステップS1008以降の処理が実行されて選択肢がクライアントに通知されるようにしたが、全体負荷Fと負荷fとの和が上限値Xを超えるかどうかに関わらず、選択肢をクライアントに通知するようにしてもよい。
(実施形態4)
上述の実施形態3では、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の選択肢をユーザに通知するようにした。しかし、映像配信サーバに課せられる負荷は刻々と変化するので、これに伴い余力も変動する。そこで本実施形態では、映像配信サーバの余力を監視し、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合には、改めて選択肢を通知するようにする。
図13は、本実施形態における映像配信サーバ100によるマルチストリーム作成処理を示すフローチャートである。このフローチャートにおける多くのステップは図3のフローチャートにおけるステップと同様であるので、同じ内容のステップには同じ参照番号を付しそれらの説明は省略し、以下では、図3と相違するステップについてのみ説明する。
図3と対照すると分かるように、図13のフローチャートには、ステップS304とステップS320との間に、ステップS310〜S316の処理が挿入されている。
ステップS310において、受信したイベントが、余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に発行される選択肢変化イベントであった場合は、ストリーム負荷データ250と接続情報260を読み込み(ステップS311)、クライアントごとに、次の一連の動作を経て選択肢を通知する(ステップS312)。
すなわち、接続情報260およびストリーム負荷データ250を参照して、現在接続されているクライアントごとの処理負荷を求め、その総和を全体負荷F(現在の処理負荷)として計算する。次に、上限値Xと全体負荷Fとの差分を余力Yとして求め、その余力Yに基づいて、提供可能な映像ストリームの属性の候補をストリーム負荷データ250から読み出し、メモリ104に格納されているストリーム選択肢情報270を更新する(ストリーム選択肢情報270がまだメモリ104に作成されていない場合には新規に作成する。)。そして、クライアント毎に新たな選択肢を通知し、その後ステップS304へ戻る。
なお、クライアントは、選択肢の通知を受け取ると、映像再生中であってもその選択肢が表示される。クライアントの使用者は、表示された選択肢から所望する属性を選択することができる。また、映像配信サーバ100の余力が増えたことで、より高品質な属性の選択肢が増えた場合には、クライアントは、その高品質な属性が自動で選択するように構成されていると好都合である。
クライアント側で別の属性が選択された場合には、属性変更要求イベントが映像配信サーバ100に発行される。
ステップS313において、属性変更要求イベントを受信した場合には、要求された属性を読み込み(ステップS314)、その属性でメモリ104に格納されている接続情報260の該当部分を変更する(ステップS315)。つづいて、映像要求イベントと選択肢変化イベントを発行する(ステップS316)。選択肢変化イベントは、接続情報260を変更した際に発行される。
さらに、図13のフローチャートが図3のフローチャートと異なっているのは、ステップS351の後にステップS352が新たに挿入されている点である。ステップS351で接続情報260から該当するデータが削除されると、その後、ステップS352において、選択肢が変化したことを示す選択肢変化イベントが発行される。
また、ステップS361で実行される配信制御処理も、基本的には図11に示したフローチャートに従って実行されるが、本実施形態では、ステップS1014において接続情報260に新たに接続されるクライアントの情報が追加登録され、ステップS1015で映像要求イベントが発行された後、この配信制御処理を完了する前にも選択肢変化イベントが発行される。
以上説明した実施形態4によれば、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があった場合に、新たな選択肢が随時提示されるので、クライアントの使用者はその余力に応じた最適な属性をタイムリーに選択することが可能になる。たとえば、最低限のストリームで接続していたクライアントも、サーバに余力が出た時点で、より高品質なストリームを要求し直すことができる。
(実施形態5)
上述の実施形態4では、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の候補に変化があると、その都度新たな選択肢が提示された。
しかし、余力が少なくなった場合には、選択肢は、現在提供しているストリームよりも低品質なストリームに減るだけで、高品質なストリームが増えることはない。そうすると、クライアントのユーザにとっては、現在閲覧中のストリームより低品質のものに切り換えることをわざわざ勧められるということになってしまい、好ましくないと考えることもできる。
そこで、本実施形態では、余力が増加した場合に限り、新たな選択肢を提示する。
これを実現するためには、実施形態4では図13のフローチャートにおけるステップS316において発行するようにした選択肢変化イベントを、発行しないようにする。同様に、実施形態4では図11のフローチャートにおけるステップS1015の後で発行するようにした選択肢変化イベントを、発行しないようにする。これにより、選択肢変化イベントが発行されるのは、接続が減少した場合に実行されるステップS352においてだけとなる。
つまり、接続が増加する場合には選択肢変化イベントを発行せず、接続が減少する場合のみ、選択肢変化イベントを発行する。
これにより、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の候補の数が増加した場合にのみ、クライアントに選択肢の変化通知がなされるので、クライアントの使用者は有益な通知だけを受け取ることができる。
(実施形態6)
本実施形態は、上述の実施形態3〜5のいずれかに記載した、提供可能な映像ストリームの属性の候補の選択肢を提供する映像配信サーバ100に対するクライアント109における制御処理に関する。以下では、実施形態3の映像配信システムに基づいて説明する。
図14は、実施形態におけるクライアント109の構成を示す図である。
クライアント109は、図示のように、映像配信サーバ100からのデータを、ネットワーク108を介して受け取るネットワークインタフェース(Network I/F)2001、演算や処理の制御を行う中央処理装置(PU)2002、必要なプログラムやデータを記憶するメモリ2003、LCDやCRTなどで構成される表示装置2004、を含む。
ネットワークインタフェース2001を介して受信した圧縮データはメモリ2003に一旦格納される。その後、CPU2002によってその圧縮データが伸張処理され、表示装置2004に表示される。もっとも、CPU2002に代わって伸張処理を実行する専用のデータ処理伸張装置(DSPなど)が付加された構成でもよい。
メモリ2003には、図15に示すように、映像配信サーバ100からの映像ストリームを受信するための映像ストリーム受信プログラム2100、後述する選択肢限定処理を実現するための選択肢限定プログラム2120、ビューワ機能を実現するためのビューワプログラム2130、クライアントの現在の余剰処理能力を測定するためのベンチマークプログラム2140等のプログラムが格納される他、画像の属性ごとのクライアントの処理負荷を示すクライアントストリーム負荷データ2150、映像配信サーバ100より通知される提供可能な映像ストリームの属性候補の選択肢の情報であるストリーム選択肢情報2160、選択肢限定プログラム2120の実行によって限定された選択肢データが記述されるストリーム限定選択肢情報2170等の各種データが格納される。
図16は、本実施形態におけるクライアント109によるマルチストリーム受信処理を示すフローチャートである。このフローチャートに対応するプログラムはストリーム受信プログラム2100に含まれ、CPU2002によって実行される。このストリーム受信プログラム2100は例えばビューワプログラム2130の実行においてコールされる。また、後述するように、ベンチマークプログラム2140および選択肢限定プログラム2120はストリーム受信プログラム2130の実行においてコールされるという関係である。
まずステップS2201において、メモリ2003内の各種設定パラメータの初期設定を行う。この際、図18に示すような構造のクライアントストリーム負荷データ2150のロードも行われる。クライアントストリーム負荷データ2150は、例えば、各画像サイズについてカメラ制御の有無別に、CPU2002の性能に基づく処理負荷を有する。図18に示した例では、画像サイズが160x120でカメラ制御なしの場合の処理負荷を基準(=1)として、各画像サイズについてカメラ制御の有無ごとに処理負荷が記述されている。
次に、ステップS2202で、接続要求イベントを発行し、これを映像配信サーバ100に送信する。上述したとおり、映像配信サーバ100は、この接続要求イベントの受信に応答して配信制御処理を実行し(図3、ステップS361)、状況に応じて、提供可能な映像ストリームの属性の候補の選択肢の情報を接続要求イベントの発行元のクライアントに送信する(図11、ステップS1010)。
なお、ステップS2202で接続要求イベントを送信する際、初期のストリーム種別の要求も送信する場合もある。ただし、映像受信サーバ100から接続拒否されたり、要求ストリーム以下の選択肢しか送付されなかったりする場合もありえる。
次のステップS2206で、イベントを待つ。
ステップS2203において、映像配信サーバ100より、提供可能な映像ストリームの属性の候補の選択肢の情報を受信したときは、メモリ2003内にその選択肢の情報をストリーム選択肢情報2160として保存し、その後、選択肢限定プログラム2120をコールすることにより、受信した選択肢を絞り込むための選択肢限定処理を実行する(ステップS2204)。このときのストリーム選択肢情報2160の構造例を図19に示す。
以下、このステップS2204における選択肢限定処理を、図17のフローチャートを用いて説明する。
まずステップS2301で、メモリ2003に保存されているストリーム選択肢情報2160を読み込んだ後、クライアント109がビューワの処理(すなわち、ビューワプログラム2130の実行)に割り当てることのできる現在の余剰処理能力を測定するため、ベンチマークプログラム2140を起動する(ステップS2303)。
このベンチマークプログラム2140は、ビューワプログラム2130の実行時に消費する処理能力を推定しやすくするために作られたもので、比較的処理負荷の軽いプログラムが適当である。ビューワプログラム2130にこのベンチマークプログラム2140を組み込んでおき、ビューワプログラム2130の起動時に余剰負荷を測定するようにしてもよい。ここで、ビューワプログラム2130は圧縮された映像データの伸張処理のプログラムを含み、この伸張処理の負荷がビューワプログラム2130の中で最も重いと仮定する。ベンチマークプログラム2140はビューワプログラム2130に、予め用意した処理量が既知の圧縮映像データの伸張処理を実行させる。
ステップS2304で、その伸張処理に要した時間Tを計測する。次に、この実行時間Tからクライアントの余剰処理能力である処理能力Pを算出する(ステップS2305)。ここでは、処理能力Pは実行時間Tに逆比例すると考える。例えば、実行時間Tが100msecであった場合の処理能力Pが2と算出されると仮定すると、実行時間Tが50msecであった場合の処理能力Pは4と算出されることになる。
次に、ステップS2306において、ストリーム選択肢情報2160の中から、処理能力がP以下の選択肢を抽出し、これをストリーム限定選択肢情報2170としてメモリ2003に格納する。処理能力がP以下であれば、現在のクライアントに余剰処理能力でも、十分な映像の表示速度やフレームレートを確保できる。一例として、ストリーム選択肢情報2160が図19に示されたとおりで、上記のステップS2305で算出された処理能力Pが4であった場合について説明する。図19のストリーム選択肢情報2160を参照すると、映像配信サーバ100より提示された選択肢としては、画像サイズ320x240と160x120のそれぞれについて、カメラ制御ありの場合とカメラ制御なしの場合の、4通りの候補がある。次いで、図18のクライアントストリーム負荷データ2150を参照すると、処理能力(=処理負荷)が4以下の選択肢は、画像サイズが320x240でカメラ制御なしの場合、画像サイズが160x120でカメラ制御ありの場合、および、同サイズでカメラ制御なしの場合、の3通りに絞られる。この3通りの候補がストリーム限定選択肢情報2170としてメモリ2003に格納される。
そして、上記の処理により選択肢が限定された場合には、ステップS2310で、その限定された選択肢を表示する。ステップS2311では、選択肢が限定されたか否かを判定し、限定された場合には、ステップS2312においてユーザにいずれか1つを選択させる。一方、たとえばステップS2305で算出された処理能力Pが小さく、選択肢が限定されなかった場合には、ステップS2313に進み終了イベントを発行する。以上によりステップS2204の処理が完了する。
なお、ステップS2312の処理については、ユーザに最終的な候補を選択させるかわりに、表示可能な最高画質のストリームを自動選択するようにしてもよい。
説明を図16のフローチャートに戻す。上記したステップS2204の選択肢限定処理を終えると、ステップS2205に進み、映像要求イベントを発行し、これを映像配信サーバ100に送信して、ステップS2206のイベントループに戻る。
映像配信サーバ100からの映像ストリーム(図3のステップS332を参照)の受信が完了し、受信完了イベントを発行すると(ステップS2207)、受信した映像ストリームを順次メモリ2003から取り込み(ステップS2208)、その映像ストリームを表示装置2004に表示する(ステップS2209)。その後、ステップS2211で継続映像要求イベントを発行し、ステップS2206のイベントループに戻る。
ステップS2214において、映像配信サーバ100から接続の拒否応答(図6のステップS609を参照)を受信した場合は、接続終了イベントを発行し(ステップS2212)、本マルチストリーム受信処理を終了する。
以上説明した実施形態6によれば、クライアント109は、映像配信サーバ100より、提供可能な映像ストリームの属性の候補の選択肢が通知されると、そのときのクライアント109の処理能力を推定する。そして、推定された処理能力に基づいて、上記選択肢の候補をさらに限定し、その限定された候補の選択肢を表示する。これにより、ユーザはクライアント側の処理能力に見合った属性の映像ストリームを、容易に指定することができる。
(実施形態7)
本実施形態では、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して選択する。
以下では、基本的に実施形態3を基に、相違する点を中心に説明するが、本実施形態は実施形態4、5に対しても適用が可能である。
本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。ただし、メモリ104には、図20に示すように、実施形態2と同様のマルチストリーム作成プログラム210、配信制御プログラム220、カメラ制御プログラム710、ストリーム負荷データ250、接続情報260、ストリーム選択肢情報270の他に、優先度テーブル280、優先度別ストリーム負荷データ290が格納されている。本実施形態でも、ストリーム負荷データ250および接続情報260はそれぞれ、実施形態3と同様の構造(図8、図9を参照)を有するものとする。ただし、本実施形態では、現在の接続情報260の内容が図22のようになっているとする。すなわち、図22を参照すると分かるように、映像配信サーバ100には現在、ビューワ(クライアント)109−1〜109−4の4台が接続されている。
本実施形態における映像配信サーバ100によるマルチストリーム作成処理は基本的に実施形態3で説明した図3のフローチャート、あるいは、実施形態4で説明した図13のフローチャートに従って行われる。ただし本実施形態では、ステップS361における配信制御処理が、図21のフローチャートに従って行われる。
まずステップS5101で、接続情報260を読み込む。また、実施形態3におけるステップS1001と同様に、接続要求イベントに含まれる要求画像属性も読み込む。
次に、ステップS5102で、接続情報260およびストリーム負荷データ250を参照して、接続されているクライアントごとの処理負荷を求め、その総和を全体負荷F(現在の処理負荷)として計算する。図22の接続情報260に基づき具体例を説明する。図22の接続情報260を参照すると、ビューワ109−1から109−4の接続があり、それぞれ、800x600でカメラ制御なし、160x120でカメラ制御有り、640x480でカメラ制御なし、800x600でカメラ制御なし、という属性の映像ストリームを要求していることが分かる。ここで、ストリーム負荷データ250を参照すると、各接続の処理負荷は、25、2、16、25である。よって、全体負荷Fは、これらの総和68と求められる(この値の例は後ほど使用する。)。
次に、ステップS5103で、サーバ処理の上限値Xを読み出す。上限値Xは上述したように、典型的には、システムの動作状況を把握している管理者によって、管理者の許可する処理能力の上限値として設定される値である。次に、ステップS5104で、映像配信サーバ100の余力Yを求める。余力Yは、上限値Xと全体負荷Fとの差分として求められる。その後、ステップS5105で、優先度別選択肢作成プログラム230を呼び出す。
優先度別選択肢作成プログラム230による動作例を図23に示す。
まずステップS5301で、図24に示すような構造の優先度テーブル280を読み込む。図24の優先度テーブルには、図8のストリーム負荷データ250と同様に分類されたそれぞれのケースについて優先度を示す情報が記述されている。具体的には、図24に示した例では、画像サイズ800x600でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が0、画像サイズ640x480でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が10に設定されている。また、画像サイズ320x240でカメラ制御ありの場合の優先度を示す情報が2、同サイズでカメラ制御なしの場合の優先度を示す情報が0、画像サイズ160x120でカメラ制御ありの場合およびカメラ制御なしの場合ともに優先度を示す情報が2に設定されている。ここでは、優先度を示す情報が0のときが最も優先度が高いと考える。
そして、ステップS5302で、ストリーム負荷データ250(図8)に記述された各ケースの負荷に、優先度テーブル280(図24)に記述された対応する優先度を示す情報の値を加算することにより、優先度別ストリーム負荷想定データ290を作成する。図25は、得られた優先度別ストリーム負荷想定データ290の例を示す図である。図8と図24とを重ね合わせてみれば、図25の結果が得られることが容易に理解できよう。
次に、ステップS5303で、ステップS5104で求めた余力Yに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ290から読み出し、図26に示すようなストリーム選択肢情報270をメモリ104に書き込む。ここで、上記した例の通り全体負荷Fが68とし、また、上限値Xが93に設定されていると仮定して具体例を示す。この場合の余力Yは93−68=25となる。その後、優先度別ストリーム負荷想定データ290から、負荷の値が25(=余力)以下である属性のセットを抽出し、各セットを候補とするストリーム選択肢情報270を構成する。図25の優先度別ストリーム負荷想定データ290の例では、「jpeg800x600、カメラ制御なし」、「jpeg320x240、カメラ制御あり」、「jpeg320x240、カメラ制御なし」、「jpeg160x120、カメラ制御あり」、「jpeg160x120、カメラ制御なし」、が抽出され、これにより図26に示されるようなストリーム選択肢情報270が構成される。
この例の場合、「jpeg640x480、カメラ制御なし」および「jpeg640x480、カメラ制御あり」のケースはそれぞれ、負荷が16および17で、余力(=25)の範囲内に収まるにもかかわらず(図8を参照)、優先度を示す情報10が加算されたことにより選択肢から外される一方、これらより負荷の大きい「jpeg800x600、カメラ制御なし」には優先度を示す情報による加算がされなかった(優先度を示す情報=0)ので、選択肢として抽出される結果となった。
このように優先度を設定することにより、処理負荷の大きい属性の映像ストリームを、処理負荷の小さい属性の映像ストリームより優先的に選択肢の候補に挙げることが可能になる。つまり、優先度の設定によって、余力内に収まる負荷の特定の属性のストリームについては選択肢に現れないように操作する。その一方で、上記特定の属性のストリームより負荷の高い属性のストリームを選択肢に入れるよう操作する。これにより、余力を、より負荷の高い属性のストリームにまわすことができる。
また、優先度を設定することで、サーバ管理者が意図するストリーム種別での接続を増やす傾向を作ることができる。たとえば、ストリーム負荷は大きいが、なるべく大きなサイズでの映像を優先的に配信しようとする場合には、ストリーム負荷は小さくても小サイズのストリームに対しては優先度を下げるよう設定すればよい。
なお、上記の例では、優先度を規定する値として、優先度を示す情報が0のときが最も優先度が高く、その値が大きくなるほど優先度が小さくなる値を考えた。これは、各属性の負荷に加算されることを前提に規定されたものである。一方このかわりに、優先度を、各属性の負荷に乗じられる重み付け係数として定義することも可能である。この場合には優先度の高低はその数値に応じたものとなる。
説明を図21のフローチャートに戻す。次に、ステップS5106で、ストリーム選択肢情報270をクライアントへ通知し、ステップS5107で、イベントを待つ。
ステップS5110において、ストリーム選択肢情報270を渡したクライアントから選択肢に基づいた属性特定要求イベントを受け取った場合はステップS5111に進み、要求された画像の属性を読み込む。このとき、属性はストリーム選択肢情報270の選択番号などで受け取ることにしても良い。また、実施形態1,2と同様に、ここで上限値Xと全体負荷Fおよび要求された優先度別ストリーム負荷fから接続の可否を制御しても良い。
次に、ステップS5112で、属性特定要求イベントの発行元のクライアントの情報を接続情報260に登録し、続くステップS5113で、映像要求イベントを発行するとともに、ステップS5114で選択肢変化イベントを発行する。
また、ステップS5120において、ストリーム選択肢情報270を渡したクライアントから接続終了イベントを受け取った場合、または、ステップS5130において、ストリーム選択肢情報270をクライアントに渡してから一定期間が経過しタイムアウトイベントが発行された場合には、本配信制御処理が終了する。
(実施形態8)
本実施形態では、接続要求に適合した映像ストリームの配信を行うには処理能力の余力が足りない場合、その優先度に応じて余力を作り出し、これにより、その要求に係る配信を実現させる。
本実施形態に係る映像配信システムの構成は実施形態7と同様である。すなわち、本実施形態に係る映像配信システム構成は図1に示されたもので、また、メモリ104に格納される内容は、図20に示されたとおりである。
また、本実施形態におけるマルチストリーム作成処理も実施形態7と同様、基本的には実施形態3で説明した図3のフローチャート、あるいは、実施形態4で説明した図13のフローチャートに従って行われ、ステップS361における配信制御処理は、図21のフローチャートに従って行われる。ただし本実施形態では、ステップS5105における優先度別選択肢作成処理は、図23のフローチャートのかわりに、図27のフローチャートに従って行われる。
まずステップS5701で、図24に示したような優先度テーブル280および、ステップS5101で読み込んだ要求画像属性を読み出す。次のステップS5702では、実施形態7におけるステップS5302と同様に、ストリーム負荷データ250(図8)に記述された各ケースの負荷に、優先度テーブル280(図24)に記述された対応する優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ290を作成する。次のステップS5703では、ステップS5104で求めた余力Yに基づいて、提供可能な映像ストリームの属性の候補を優先度別ストリーム負荷想定データ290から読み出し、図26に示すようなストリーム選択肢情報270を作成する。
次に、ステップS5704において、ステップS5701で読み込んだ要求画像属性が、ステップS5703で作成されたストリーム選択肢情報270に含まれているかどうかを判定する。要求画像属性がストリーム選択肢情報270に含まれている場合には、この優先度別選択肢作成処理を抜ける。一方、要求画像属性がストリーム選択肢情報270に含まれていない場合はステップS5705に進む。
ステップS5705では、優先度テーブル280を参照して要求画像属性の優先度を確認するとともに、接続情報260および優先度テーブル280を参照して要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されているかどうかを調べる。ここで要求画像属性の優先度よりも低い優先度のストリーム配信のための接続は現在のところ確立されていない場合には、そのままこの優先度別選択肢作成処理を抜ける。一方、要求画像属性の優先度よりも低い優先度のストリーム配信のための接続が確立されていた場合には、ステップS5706に進み、当該接続先のクライアントに接続拒否イベントを発行し、その後、ステップS5707において、その接続を拒否したクライアントに係る情報を接続情報260から削除する。
このステップS5705、S5706の具体例を示す。処理対象の接続要求イベントを発行したクライアントが109−5であり、現在、別の4つのクライアント(109−1〜4)が接続されており、そのときの接続情報260が図22に示すとおりであると仮定する。また、ステップS5701で読み込んだ接続要求イベントに含まれる要求画像属性が「jpeg800x600、カメラ制御なし」であったとする。
まず、優先度テーブル280を参照して要求画像属性の優先度を確認する。図24の優先度テーブル280を参照すると、要求画像属性「jpeg800x600、カメラ制御なし」の優先度を示す値は「0」に設定されており、最も高い優先度に設定されていることがわかる。
次に、接続情報260および優先度テーブル280を参照して要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係る接続が確立されているかどうかを調べる。ここで、図22の優先度テーブル260を調べてみると、クライアント109−1と109−4への映像ストリームの属性は「jpeg800x600、カメラ制御なし」であり、その優先度を示す値は「0」である。一方、クライアント109−2への映像ストリームの属性は「jpeg160x120、カメラ制御あり」で、図24の優先度テーブル280より、その優先度を示す値は「2」に設定されている。また、クライアント109−3への映像ストリームの属性は「jpeg640x480、カメラ制御なし」で、図24の優先度テーブル280より、その優先度を示す値は「10」に設定されている。そうすると、このクライアント109−2および109−3の接続が、要求画像属性の優先度よりも低い優先度の属性の映像ストリームに係るものであることが判明する。
ステップS5706では、この2つのクライアント109−2および109−3の両方に直ちに接続拒否イベントを発行してもよいが、ここでは、これらのうち優先度別負荷想定の値(図25を参照)が最も高いクライアント(すなわち、109−3)にのみ接続拒否イベントを発行することにする。これによりクライアント109−3の接続が解除された結果、余力が増えることになる。それでもなお要求画像属性の映像ストリームの作成には不足である場合には、続いてクライアント109−2に接続拒否イベントを発行するようにすればよいであろう。
ステップS5705,S5706の具体例は以上のとおりである。
次のステップS5708では、ステップS5703と同様にして再度ストリーム選択肢情報270を作成する。この場合には、ステップS5707での削除により、処理対象の接続要求イベントを発行したクライアントの要求画像属性がストリーム選択肢情報270に含まれることになる。
以上で、優先度別選択肢作成処理が終了する。
以上説明した優先度別選択肢作成処理によれば、優先度の高い属性のストリームへの接続要求を受けた場合、余力が足りないときには、優先度の低い属性の映像ストリームの配信を停止することで余力をつくり、これにより上記の優先度の高いストリームの配信を実行させることができる。
また、優先度の低いストリームの配信先であるクライアントの接続は解除せず(ステップS5706、S5707を実行しない)、ステップS5708では、その優先度の低いクライアントの接続を解除したと仮定した場合における余力Yを計算し、その余力Yから、優先度の高い要求画像属性のストリームにかかる負荷を減算した上で、再度選択肢を作成し直し、これを上記の優先度の低いストリームに係るクライアントに提示するようにしてもよい。この場合には、優先度の低いストリームの配信に係るクライアントの接続を切断せず、別の属性のストリームに切り換えて配信を続けることが可能になる。
(実施形態9)
上述した実施形態7,8では、映像ストリームの各属性に優先度の情報が設定されたが、本実施形態では、クライアントに優先度が設定され、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する。
本実施形態に係る映像配信システムの構成は実施形態8と同様である。すなわち、本実施形態に係る映像配信システム構成は図1に示されたもので、また、メモリ104に格納される内容は、図20に示されたとおりである。
また、本実施形態におけるマルチストリーム作成処理も、基本的には実施形態3で説明した図3のフローチャート、あるいは、実施形態4で説明した図13のフローチャートに従って行われ、ステップS361における配信制御処理は、図21のフローチャートに従って行われる。また、実施形態8と同様で、ステップS5105における優先度別選択肢作成処理は、図23のフローチャートではなく、図27のフローチャートに従って行われる。
ただし、優先度テーブル280のデータ構造は実施形態8におけるそれ(図24)とは異なっている。図28に、本実施形態における優先度テーブル280の構造例を示す。実施形態8における優先度は、図24のとおり、映像ストリームの属性に対して設定されたが、本実施形態における優先度は、図28に示すように、クライアント(ビューワ)に対して設定される。
この優先度を示す設定値は映像配信サーバ100において、管理者の操作に従って変更が可能であることはもちろんであるが、クライアントからの指示に応じて当該クライアントの優先度を示す設定値を変更することも可能である。
例えば、各クライアントは、映像配信サーバ100に発行する接続要求イベントに、要求映像属性の他、そのクライアントの優先度を示す情報を含めることが可能である。映像配信サーバ100はこの接続要求イベントを受け取ると、それに含まれている優先度を示す情報でもって優先度テーブル280の該当部分を更新することになる。
これに関連して、本実施形態において実施形態8とは相違する動作について説明する。
まず、図21の配信制御処理について。ステップS5101では、接続情報260を読み込むほか、接続要求イベントに含まれる要求画像属性を読み込む。さらに、接続要求イベントにそのクライアントの優先度の情報も含まれている場合にはその情報も読み込む。
次に、図27の優先度別選択肢作成処理について。ステップS5701では、図28に示したような優先度テーブル280および、ステップS5101で読み込んだ要求画像属性ならびにそのクライアントの優先度の情報を読み出す。ここでクライアントの優先度の情報が読み出された場合には、その情報でもって優先度テーブル280の該当部分を更新する。
ステップS5702では、ストリーム負荷データ250(図8)に記述された各ケースの負荷に、優先度テーブル280(図28)に記述された当該クライアントの優先度を示す値を加算することにより、優先度別ストリーム負荷想定データ290を作成する。この場合の優先度別ストリーム負荷想定データ290の例を図29に示す。
なお、クライアント側で優先度の指定がなされなかったために接続要求イベントにそのクライアントの優先度の情報が含まれていなかった場合で、かつ、優先度テーブル280にそのクライアントが登録されていない場合には、映像配信サーバ100で予め設定されたデフォルト値(例えば20)が用いられる。
以上、実施形態8との相違点を説明した。これ以外は実施形態8と同様な処理が行われる。
以上説明した実施形態9によれば、映像配信サーバ100に接続が可能な(すなわち、映像配信サーバ100より映像ストリームの配信を受けることが可能な)クライアントに優先度が設定され、この優先度および要求画像属性に基づいて、映像配信サーバ100の余力の範囲内で提供可能な属性の映像ストリームの選択肢が作成される。これにより、接続を要求するクライアントによって提示される選択肢の内容が異なるようになる。このため、優先度が高く設定されたクライアントほど、処理負荷の大きい属性の映像ストリームまでもが選択肢に含まれるようになり、サーバの能力の範囲内で、より多くの能力が分配されるようになる。
なお、上記の例では、クライアントに優先度が設定されたが、同様の考え方で、ユーザに優先度を設定し、それを考慮して提供可能な属性の映像ストリームの選択肢を作成する、というバリエーションを考えることもできる。たとえば、映像配信サーバ100が、クライアントから接続要求イベントを受け取ったことに応答してそのクライアントに対しユーザ認証処理を実行するように構成しておき、このユーザ認証を経てユーザの優先度が設定されるようにすればよい。
(実施形態10)
実施形態3では、図11に示したような配信制御処理のうち、とりわけステップS1001〜S1010の処理によって、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。
また、実施形態7では、図21に示した配信制御処理のうち、とりわけステップS5101〜S5106の処理によって、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの選択肢がクライアントに提示された。
これらの処理は、映像配信サーバ100において選択肢を作成するための評価工程と考えることができる。
また、クライアント側の処理例について説明した実施形態6では、図16に示したマルチストリーム受信処理では、ステップS2204において選択肢限定処理が行われる。この選択肢限定処理においては、とりわけ図17に示すステップS2301〜S2306の処理によって、限定された選択肢が求められた。そして、図16のステップS2205で映像要求イベントが発行された。これらは、受信ストリームを選択的に要求するための選択要求工程と考えることができる。
本実施形態では、上記したような評価工程や選択要求工程を実現する手段をそれぞれ独立した処理モジュールとして構成することより、選択肢の評価基準や受信ストリームの選択基準に自由度を持たせることを容易にする。
本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。また、クライアント109の構成は実施形態6で説明した図14の構成と同様である。ただし、クライアント109のメモリ2003に格納される内容は、図30に示すとおりである。これは実施形態6に係る図15とほぼ同様であるが、対照すると分かるように、本実施形態に係る図30にはベンチマークプログラム2140のかわりに、選択要求プログラム2145が含まれている。
他方、映像配信サーバ100のメモリ104に格納される内容は、図31に示すとおりである。これは実施形態7に係る図20とほぼ同様であるが、対照すると分かるように、本実施形態に係る図31には、選択肢評価プログラム240が追加的に含まれている。
図32は、本実施形態における映像配信サーバ100による選択肢評価処理を示すフローチャートである。このフローチャートに対応するプログラムが選択肢評価プログラム240である。
まずステップS6101で、評価に必要な情報(接続情報260、接続要求イベントから抽出される要求画像属性、上限値X等を含む。)を読み込む。次にステップS6102で、読み込んだ情報を基に、評価関数Sにより選択肢が求められる。
たとえば、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの候補を選択肢としてクライアントに通知するようにした実施形態3についていえば、評価関数Sは、図11に示したステップS1002(全体負荷Fの計算)、ステップS1008(余力Yの計算)、およびステップS1009(選択肢の生成)の各処理を実現する関数である。
また、映像配信サーバ100の余力の範囲内で提供可能な映像ストリームの属性の候補を、各属性に設定される優先度の情報を考慮して求め、それを選択肢としてクライアントに通知するようにした実施形態7についていえば、評価関数Sは、図21に示したステップS5102(全体負荷Fの計算)、ステップS5104(余力Yの計算)、およびステップS5105(優先度別選択肢作成処理)の各処理に実現する関数である。
選択肢評価プログラム240は配信制御プログラム220から独立したモジュールであるから、これが配信制御プログラム220に組み込まれている場合に比べれば、上記のように評価関数Sを任意に変更することが大幅に容易になる。これに伴い、選択肢評価プログラム240がこのような評価関数Sを有する以上、評価関数Sによって実現される処理部分については、もはや配信制御プログラム220自体が有している必要はない。
そして、ステップS6103で、その求められた選択肢の情報などを接続要求イベントの発行元のクライアントに通知する。
図33は、本実施形態におけるクライアント109による選択要求処理を示すフローチャートである。このフローチャートに対応するプログラムが選択要求プログラム2145であり、CPU2002によって実行される。
まず、ステップS6201で、接続要求イベントが発行されているかどうかを判断する。ここで接続要求イベントが発行されていなければステップS6202に進み、実施形態6のマルチストリーム受信プログラム2100によるステップS2202と同様の処理で、接続要求イベントを発行してこれを映像配信サーバ100に送信し、その後この選択要求処理を終了する。
一方、ステップS6201において接続要求イベントが発行されていない場合にはステップS6203に進み、評価関数Gによって、要求される映像選択が行われる。たとえば、実施形態6についていえば、評価関数Gは、選択肢限定プログラム2120を呼び出す処理に相当する。
次に、ステップS6204で、評価関数Gの結果に基づき映像要求が可能かどうかを判断する。映像要求が可能でないと判断した場合にはステップS6205に進み、評価関数Gの結果に応じた接続要求を決定し、続くステップS6202で接続要求イベントを送信発行してこれを映像配信サーバ100に送信し、その後この選択要求処理を終了する。この際、評価関数Gの結果によっては接続要求自体をやめるようにしてもよい。一方、ステップS6204において評価関数Gの結果に基づき映像要求が可能と判断した場合にはステップS6206に進み、実施形態6のマルチストリーム受信プログラム2100によるステップS2205と同様に映像要求イベントを発行してこれを映像配信サーバ100に送信し、その後この選択要求処理を終了する。
本実施形態は、映像配信サーバ100において、選択肢の生成に係る処理部分を配信制御プログラム220から独立したモジュールで構成したことにその特徴がある。これにより、任意の評価関数Sを容易に記述することができる。
また、クライアント109においても同様に、接続要求イベントおよび映像要求イベントの発行に係る選択要求処理部分をストリーム受信プログラム2100から独立したモジュールで構成した。これにより、任意の評価関数Gを容易に記述することができる。
(実施形態11)
以下では、実施形態10で説明した評価関数SまたはGのバリエーションについて説明する。
例えば、マルチストリーム配信を対価の支払いに応じた優先度の更新を実現することができる。
まず、クライアント109は、実施形態10の選択要求プログラム2145によるステップS6201と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する対価(金額)情報とを接続要求イベントに含めてこれをステップS6202で発行する。
これに応じて、映像配信サーバ100は、実施形態10の選択肢評価プログラム240のステップS6101と同様の処理において、接続要求に対して支払われる対価の情報が読み込まれる。
ステップS6102の評価関数Sは実施形態10とほぼ同等である。ただし本実施形態は、読み込んだ対価に応じて当該接続要求に係る優先度を更新する処理を含む(優先度テーブル280が更新される。)。例えば対価100円につき優先度を1上げることができる。具体例を示すと、例えば優先度10のビューワのユーザが100円支払うことで優先度9とすることができる。このようにユーザは対価を払うことで優先度を上げて接続することができる。
また、例えば、接続回数に応じたいわゆるポイント加算による優先度の更新を実現することができる。
まず、クライアント109は、実施形態10の選択要求プログラム2145によるステップS6201と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報を接続要求イベントに含めてこれをステップS6202で発行する。
これに応じて、映像配信サーバ100は、実施形態10の選択肢評価プログラム240のステップS6101と同様の処理において、接続要求に対するユーザ認証情報が読み込まれる。
ステップS6102の評価関数Sは実施形態10とほぼ同様である。ただし本実施形態は、ユーザ別にその接続回数に応じたポイントを管理し、ポイント数に応じて優先度を更新する(優先度テーブル280が更新される。)。例えば、ユーザAのポイント累計が100ポイントとなった時点でユーザAの優先度を1上げるようにする。具体例を示すと、例えば優先度10のビューワのユーザが100回の接続を行うことで優先度9とすることができる。このようにユーザは接続を重ねることで優先度を上げて接続することができる。
また、例えば、マルチストリーム配信を競り落とすことによる優先度の更新を実現することができる。
まず、クライアント109は、実施形態10の選択要求プログラム2140によるステップS6201と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、今回の接続に対する入札金額(オークション)情報を接続要求イベントに含めてこれをステップS6202で発行する。
これに応じて、映像配信サーバ100は、実施形態10の選択肢評価プログラム240のステップS6101と同様の処理において、接続要求に係る入札金額の情報が読み込まれる。
ステップS6102の評価関数Sは実施形態10とほぼ同様である。ただし本実施形態は、読み込んだ入札金額に応じて当該接続要求に係る優先度を更新する処理を含む(優先度テーブル280が更新される。)例えば、複数のユーザA、B、Cがそれぞれ、100円、200円、300円で接続要求した場合、Cの優先度を0、A、Bの優先度を100とすることで、実質的にユーザCのみを優先的に接続させるようなことができる。
また、例えば、映像配信サーバ100の余力がなく接続をあきらめた場合に、後に使えるポイント、クーポンなどを発行してもらうことに伴う優先度の更新を実現することができる。
まず、クライアント109は、実施形態10の選択要求プログラム2140のステップS6201と同様の処理において、最初の接続要求を行う際に、ユーザ認証によるユーザ情報と、特定のストリーム接続の要求とを接続要求イベントに含めてこれをステップS6202で発行する。
これに応じて、映像配信サーバ100は、実施形態10の選択肢評価プログラム240のステップS6101と同様の処理において、ユーザ情報とストリーム属性が読み込まれる。
ステップS6102の評価関数Sは実施形態10とほぼ同等である。ただし本実施形態は、受け取った特定のストリームへの接続要求が実現できない際(選択肢に含ませることができない場合)に、ユーザに対して所定数のポイントを発行し、一定期間内に同一のユーザが接続してきた際にこのポイント情報に応じて優先度を更新する処理を含む(優先度テーブル280が更新される。)。例えば、1ポイントにつき優先度を1上げることができる。これにより、当初の接続が拒否されたユーザが報われるかたちで接続を実現することができる。
以上のように、対価、接続数、ポイントなどによって、特定の優先度を上げることについて述べたが、もちろん、逆に、該当クライアント(またはユーザ)以外のクライアント(またはユーザ)の優先度を下げることによっても同様の効果を得ることができる。この場合、図27の優先度別選択肢作成プログラム230によるステップS5705で述べたように、減算されたユーザの方が接続拒否対象となる場合が出てくることとなり、実質的に他のユーザの優先度を上げることが実現できる。なお、このステップS5706で接続拒否する場合には、接続拒否の対象となった優先度を初期値に戻しておくこともできる。初期値に戻さない場合は、ユーザが何らかの対価、ポイントなどを払うことで元に戻していくことが実現されるし、初期値に戻す場合は初期接続において皆平等ということが実現される。
(実施形態12)
評価関数SおよびGに関して、更に別のバリエーションを説明する。
図34は、本実施形態におけるストリーム負荷データの例を示している。このデータ構造は図8に示したストリーム負荷データと同様であるが、画像サイズ640x480のバリエーションとして、320x240の映像を拡大することにより640x480とした映像ストリームが加えられている。同図によれば、通常の640x480の映像ストリームについては、カメラ制御ありのときの負荷が17、カメラ制御なしのときの負荷が16であるのに対し、320x240の映像を拡大して640x480とした映像ストリームについては、カメラ制御ありのときの負荷が9、カメラ制御なしのときの負荷が8となっており、負荷が大きく低減されることがわかる。なお、これは画像サイズ640x480の映像ストリームについての一例であり、他のサイズの映像ストリームについても同様な設定をなしうる。ただしここでは、それらの記述を省略した。
さて、処理対象の接続要求イベントを発行したクライアントが109−5であり、現在、別の4つのクライアント(109−1〜4)が接続されており、そのときの接続情報260が図22に示すとおりであると仮定する。また、上限値Xは70に設定されている。図22の接続情報260を参照すると、クライアント109−1〜4はそれぞれ、
(1)800x600、制御なし
(2)160x120、制御あり
(3)640x480、制御なし
(4)800x600、制御なし
の画像属性を持つ映像を要求していることがわかる。図34のストリーム負荷データ250を参照すると、それぞれの要求にかかる負荷は、25,2,16,25である。そして、全体負荷FはF=25+2+16+25=68である。ここで、クライアント109−5が「640x480、制御あり」の接続要求を発行したとする。このクライアント109−5の要求にかかる負荷fは、図34のストリーム負荷データ250を参照すると、f=17である。そうすると、この場合は、F+f=68+17=85となり、上限値X=70を超えており、このままではクライアント109−5の要求どおりの接続は拒否せざるを得ない。
そこで、本実施形態では、図34のストリーム負荷データ250に基づいて、図11のステップS1009のような処理いったん作成される選択肢から、通常の「640x480、制御なし」を外し、その代替として、320x240の拡大バージョンである「640x480、制御なし」を加える。さらに、クライアント109−5が要求している「640x480、制御あり」についても、通常の「640x480、制御なし」ではなく320x240の拡大バージョンである「640x480、制御なし」を代用する。これが実現すれば、クライアント109−5の接続を確立した場合の全体負荷F+fはF+f=25+2+8+25+9=69となり、上限値70を越えずに全て接続することが可能となる。このような調整の後、接続要求選択肢変化イベントを発行するようにすればよい。
そこで、本実施形態では次のような処理を行う。まず、現在の全体負荷F(クライアント109−1〜4にかかる負荷)と処理対象の接続要求に対する負荷(クライアント109−5にかかる負荷)とを推定し、両者の負荷の合計(すなわち、クライアント109−5の接続を確立した場合の全体負荷)が上限値Xを超えるか否かを判定する。ここで上限値Xを超える場合には、ストリーム負荷データに基づいて、いったん抽出した候補の少なくともいずれかを、近似的な属性(要求よりも小さなサイズの画像を拡大させたもの)を有する負荷の小さい別の候補によって代替することを、該当する他のクライアントおよび/またはクライアント109−5に求める。この求めに他のクライアントおよび/またはクライアント109−5が応じ、これにより、クライアント109−5の接続を確立した場合の全体負荷が上限値Xを下回ることになれば、クライアントからの当初の要求に近い接続を実現できることになる。
また、クライアント側でも、図33のステップS6203に示したような評価関数Gによって、例えば「640x480、制御なし」要求時に、それが選択不可の場合には、320x240を拡大したバージョンの「640x480、制御なし」で代用して、ステップS6205で再度選択させるという実施形態も、同様に可能である。
(実施形態13)
上述の各実施形態では、映像配信サーバ100の負荷は、各ケースごとの負荷があらかじめ記述されたテーブル(ストリーム負荷データ)に基づいて推定された。この場合、クライアントの接続状態によっては推定と実際とで差が開き、実際にはサーバの処理能力に余裕がある場合であってもクライアントの接続を拒否してしまったり、データ量の少ないストリームの選択肢しか生成されなかったりする場合がある。
そこで、本実施形態では映像配信サーバ100のCPUの負荷状態を実際に測定することで、この実測値を用いてサーバの能力をより無駄なく使用するようにする。
本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。ただし、メモリ104には、図35に示すように、マルチストリーム作成プログラム210、配信制御プログラム220、カメラ制御プログラム710、接続情報260に加え、CPU負荷測定プログラム1310および、そのCPU負荷測定プログラム1310の実行により生成されるCPU負荷データ1320が格納されている。CPU負荷データ1320は、所定のデータ送信レート(例えば、1kbps)あたりのデータ配信にかかるCPU負荷の指標を表す。
図36はCPU負荷データ1320の構造例を示す図である。3401はシステムの初期状態でのCPUの処理能力をあらわす値(無負荷データ)、3405は800x600のサイズの画像を圧縮する場合のCPUの必要処理能力を示す値、3402は640x480のサイズの画像を圧縮する場合のCPUの必要処理能力を示す値、3403は320x240のサイズの画像を圧縮する場合のCPUの必要処理能力を示す値、3404は160x120のサイズの画像を圧縮する場合のCPUの必要処理能力を示す値である。3406は配信時にかかるCPUの必要処理能力を示す値である。
また、本実施形態における接続情報260は、図39に示すようなデータ構造を有する。本実施形態における接続情報260には、同図に示すように、現在接続されているクライアントとそのクライアントから要求されている画像サイズ、ならびにそのクライアントの接続に係る画像送信レートが記述されている。
図37は、本実施形態におけるマルチストリーム作成処理を示すフローチャートである。このフローチャートは図3とほぼ同様であるが、相違する点は、本実施形態では、ステップS301とS302との間で、ステップS1301としてCPU負荷測定プログラム1310が起動され点と、ステップS361における配信制御処理が、図38のフローチャートに従って行われる点である。
ステップS1301において、CPU測定プログラム1310が起動すると、まず、圧縮処理も動いておらずクライアントも接続されない初期状態でのCPU負荷が測定される。ここでは、一定時間内に特定の処理を行った回数を基本としてCPUの処理能力が測定され、得られた値がCPUの処理能力の上限値データ(無負荷データ)3401としてメモリ104上に保存される。
次に圧縮処理にかかるCPU負荷を測定するために、圧縮処理が開始される。このとき、画像サイズ毎のCPU負荷が無負荷状態の場合と同様の方法で測定される。これにより160x120、320x240、640x480、800x600の4種類のサイズについて圧縮処理で必要とされるCPUの負荷がそれぞれ測定されて、圧縮負荷基準値データ3404、3403、3402、3405としてそれぞれメモリ104上に保存される。
次に、ステップS361における配信制御処理を、図38のフローチャートを用いて説明する。
まず、ステップS3301で、接続要求イベントに含まれる要求画像属性を読み込み、ステップS3302で、図39に示したような接続情報260を読み込む。
次に、ステップS3303で、接続情報260の各接続ごとに送信を行う画像データサイズとCPU負荷データ250を掛け合わせた負荷データ、さらに要求画像の属性毎の圧縮にかかるCPU負荷データを加算していくことで全体負荷F30が総和として求められる。
例えば、図39に示した接続情報260の場合、クライアント(ビューワ)109−1と109−2の接続があり、それぞれ640x480と160x120の画像で、画像送信レート30の属性を持つ映像を要求していることがわかる。ここで、640x480の画像データサイズをD3001kbyte、160x120の画像データサイズをD3003kbyte、単位送信レートあたりのCPUの配信負荷データ(3406)F3006、640x480のデータ圧縮にかかる負荷データ(3402)をF3402、160x120のデータ圧縮にかかる負荷データ(3404)をF3404、とすると、全体負荷F30は、
F30=D3001×8×F3006×30
+D3003×8×F3006×30
+F3402+F3404
となる。
次に、ステップS3304で、今回要求されている属性に対する負荷f30を同様の方法で求める。例えば、320x240の画像属性を持つ画像が要求されている場合、画像サイズをD3002byte、320x240のデータ圧縮にかかる負荷データ(3403)をF3403、とすると、
f30=D3002×8×F3006×30+F3403
となる。
ステップS3305で、はじめに実測された無負荷データすなわち上限値(3401)をX30として読み込み、ステップS3306で、このX30とF30+f30と比較する。
比較の結果、X30がF30+f30より大きい場合には、今回要求されている接続を許可してもサーバの処理の上限を超えることはない。そこでこの場合には、ステップS3307に進み、要求されている接続を接続情報260に追加登録してメモリ104に保存する。その後、ステップS3308で映像要求イベントを発生して、この配信制御処理を終了する。
一方、ステップS3306の比較の結果、X30がF30+f30以下である場合には、今回要求されている接続を許可するとサーバの処理能力の上限を超えてしまう。そこでこの場合には、ステップS3309で、接続要求に対する拒否応答を返し、その後この配信制御制御処理を終了する。
ここで、要求されている接続の画像サイズがすでに配信を行っている接続と同一の画像サイズである場合、画像圧縮にかかるCPU負荷をさらに追加する必要はない。例えば、すでに配信を行っている160x120の画像サイズを持つ画像が要求されている場合、画像サイズをD3003byteとし、画像送信レートを30とすると、
f30=D3002×8×F3006×30
となる。
また、複数のネットワークインターフェースを持つシステムの場合、例えば有線LAN接続と無線LAN接続、モデム接続ではそれぞれ、データ配信にかかるCPUの負荷に大きな違いがある。このような場合、それぞれのインターフェース毎に配送負荷情報を持つことでより正確なCPUの負荷状況を知ることが可能となる。
本実施形態では特定のデータ送信レートにかかるCPUの負荷データを一定のものとして扱ったが、実際に送信を行い、CPUの負荷データを測定することでより正確なCPUに対する負荷状況を求めることでより好適なマルチストリーム配送を行うこともできる。
以上のようにすることで、映像配信システムの処理能力の上限値以下で、マルチストリーム配信が可能となる。
(実施形態14)
上述した実施形態10〜12では、映像配信サーバ100における、余力の範囲内で提供可能な映像ストリームの属性の候補の抽出に係る処理部分や、クライアント109における、接続要求イベントおよび映像要求イベントの発行に係る選択要求処理部分を独立のモジュールで構成し、これらの処理部分にはさまざまなバリエーションのアルゴリズムを適用可能であることを示した。以下では、上記映像ストリームの候補の抽出処理における抽出基準または抽出方針や、上記選択要求処理における選択基準または選択方針のことを、「ポリシー」とよぶ。そして、本実施形態では、このポリシーの変更の要求(ポリシー変更要求)を受け付け、現在使用している評価関数を、要求されたポリシーに応じた評価関数に切り替えることを可能にする。
図40は、本実施形態に係る映像配信システムの概略構成を示す図である。上述の各実施形態と同様に、映像配信サーバ100は、ネットワーク108を介して、クライアント(ビューワ)109に接続される構成である。ビューワ109は基本的には複数であり、ネットワーク108を介して映像配信サーバ100より配信されたデータを受け取り表示する。より具体的には、本実施形態に係る映像配信システムの構成は図1に示した構成と同様である。また、クライアント109の構成は実施形態6で説明した図14の構成と同様である。
ただし、クライアント109のメモリ2003に格納される内容は、図41に示すとおりである。すなわち、メモリ2003には、ストリーム受信プログラム2100、ビューワプログラム2130、選択要求プログラム2145(選択肢限定プログラム2120などはこれに内包される。)、そして、ビューワポリシー切り替えプログラム2146が含まれている。
本実施形態の選択要求プログラム2145が、実施形態10と異なるのは、ビューワポリシー切り替えプログラム2146によって、評価関数Gが置き換えられることである。
一方、映像配信サーバ100のメモリ104の格納内容は図42に示すとおりで、マルチストリーム作成プログラム210、配信制御プログラム220、選択肢評価プログラム240(優先度別選択肢作成プログラム230などはここに内包される。)、サーバポリシー切り替えプログラム245、ポリシーテーブル246、接続情報260などが格納されている。
本実施形態の選択肢評価プログラム240が、実施形態10と異なるのは、サーバポリシー切り替えプログラム245によって、評価関数Sが置き換えられることである。
サーバポリシー切り替えプログラム245による映像配信サーバ100の動作を図43に示す。
ステップS7201でイベントを待つ。ステップS7202は、検出されたイベントがポリシー変更イベントかどうかを判断するステップである。ポリシー変更イベントは、変更したいポリシーの種別の情報を含む。検出されたイベントがポリシー変更イベントであった場合、ステップS7203でそのポリシー変更イベントに含まれるポリシーの種別の情報に応じてサーバ評価関数Sを置き換える。なお、このポリシー変更イベントは、例えばサーバ管理のためのWebページや設定ツールによって生成されるメニュー選択などで実現される。また、ポリシー変更イベントはhttpやRPC接続などで、ネットワーク108を介して、遠隔地から変更イベントを受け付けてもよい。ステップS7204では、例えば実施形態13の接続情報260(図39)と同様な情報から接続先のクライアント(ビューワ)に対してビューワポリシー変更イベントを発行し、その後、ステップS7201のイベントループに戻る。
ステップS7210における終了イベントによって、このサーバポリシー切り替えプログラム245が終了する。
次に、ビューワポリシー切り替えプログラム2145によるクライアント109の動作を図44に示す。
ステップS7301でイベントを待つ。ステップS7302でポリシー変更イベントがあると、ステップS7303で、そのイベントに含まれるポリシーの種別の情報に応じてビューワ評価関数Gを置き換え、その後ステップS7301のイベントループに戻る。ポリシー変更イベントはhttpやRPC接続などで、ネットワーク108を介して、遠隔地から変更イベントを受け付けてもよい。ステップS7310における終了イベントにより、このビューワポリシー切り替えプログラム2145は終了する。
上記したステップS7203やステップS7303で置き換えられる評価関数は例えば、図45に示すようなポリシーテーブルを用いて実現される。例えば、「解像度優先」ポリシーでは、図24のサーバの優先度テーブルで示されるような優先度において、800x600が優先度0、640x480が優先度10、320x240が優先度20、160x120が40で、カメラ制御ありがそれぞれ優先度+5であるような場合の、評価関数S1が考えられる。
また、「フレームレート優先」ポリシーでは、ストリーム負荷の軽いものを優先して、800x600が優先度30、640x480が優先度20、320x240が優先度10、160x120が優先度0で、カメラ制御ありがそれぞれ優先度+5であるような場合の、評価関数S2が考えられる。
また「サーバ最適」ポリシーでは、代替ストリームを用いてでもサーバの負荷上限を超えない、サーバにとってより適した選択肢を提示する評価関数S3が考えられる。
また、「クライアント最適」ポリシーでは、代替ストリーム不可で、クライアントの要求を最大限に尊重した評価関数S4が考えられる。
ビューワ側の評価関数Gに関しても同様である。
このようにすることで、選択的なマルチストリーム配送を行う際の配送ポリシーを自由に変更することができる。
この際、映像配信サーバ100、あるいはクライアント109上の実際の負荷が把握できていることと、ストリームの負荷が把握できていること、また、ストリームの代用などのルールが評価関数に組み込めることが必須であり、ポリシーテーブルに示されたポリシーと評価関数の対応がそれを実現している。
(実施形態15)
実施形態14では、あらかじめ定められたポリシーを切り替えるものであったが、本実施形態では、ポリシーサーバによって配送ポリシーを入れ替えることで、より柔軟に多様な環境に対応する。
図46は、本実施形態に係る映像配信システムの概略構成を示す図である。実施形態14と同様に、映像配信サーバ100は、ネットワーク108を介して、クライアント(ビューワ)109に接続される。本実施形態ではこれに加えて、ネットワーク108にポリシーサーバ200が接続されている。映像配信サーバ100およびクライアント109におけるメモリの内容は実施形態14と同様である。また、ポリシーサーバ200は、映像配信サーバ100と同様に一般的なコンピュータで実現できるものであるからここではその構成の説明は省略するが、そのメモリには、ポリシー変更プログラムが格納されている。
本実施形態におけるサーバポリシー切り替えプログラム245による映像配信サーバ100の動作は、実施形態14と同様、図43のフローチャートに示したとおりであるが、ステップS7202では、ポリシー変更イベントは、後述するようにポリシーサーバ200から送付されてくる。また、本実施形態におけるビューワポリシー切り替えプログラム2146によるクライアント109の動作は、実施形態14と同様、図44のフローチャートに示したとおりであるが、ステップS7302では、ポリシー変更イベントは、ポリシーサーバ200から送付されてくる。
評価関数Sや評価関数Gは、例えばスクリプト言語などで書かれていてもよく、具体的にはそのスクリプトなどがポリシーサーバ200から、ネットワーク108を介して送られてくることで、それを受け取り、評価関数を入れ替えることができる。評価関数はプログラムのバイナリなどのオブジェクト形式などでももちろんよい。
次に、ポリシーサーバ200によるポリシー変更処理について説明する。図47は、本実施形態におけるポリシーサーバ200によるポリシー変更処理を示すフローチャートである。このフローチャートに対応するプログラムが先述のポリシー変更プログラムに含まれる。
まず、ステップS7601で、図48に示すようなポリシーメニューを表示する。これは例えばグラフィカルユーザインタフェース(GUI)として実現される。
次に、ステップS7602で、ポリシーメニューからポリシーが選択されると、実施形態14の図45で示したようなポリシーテーブルによって選択されたポリシーに対応する評価関数を求め、ステップS7603で、ポリシー変更イベントと共に対応する評価関数の情報を映像配信サーバ100およびビューワ109に送付する。
また、さらに、送付する評価関数に対して、例えばネットワーク帯域などのシステムの属性によって、評価関数の属性を変更して送付することもできる。
具体的には、ネットワーク帯域が狭い場合には、例えば図34に示したストリーム負荷データ252と同様な負荷テーブルで、ネットワーク帯域1000MHzで0、100MHzで1、10MHzで5などの負荷を加えた形での、評価関数を送付する。
こうすることで、マルチストリームの映像配信システムや、ビューワ単体での負荷評価ではなく、システム全体としての評価を可能とする評価関数を実現できる。
以上のように、ポリシーサーバ200によって、映像配信サーバ100とビューワ109にポリシー変更イベントを発行し、評価関数を入れ替えることにより、システム全体としてのマルチストリーム配送の多様性、利便性を実現できる。
また、評価関数が映像配信サーバ100やビューワ109に組み込まれていないことから、一般的なアップグレードに対応しやすいだけでなく、システム全体の負荷などが変った際に、評価関数を適宜正しく直すことができる。
(他の実施形態)
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム(図3〜6のいずれかに示すフローチャートに対応したプログラム)を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。
従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD−ROM、DVD−R)などがある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明のクレームに含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。