(57)【要約】【課題】ネットワークに接続されたサーバから複数のクライアントに同時に異なる映像データを配信する場合において、ネットワークの許容帯域を超えて映像データ配信要求があった場合にも、他の有効なストリーム映像の画質への影響を最小にして、ストリーム増加が行えるようなシステムを提供する。【解決手段】ネットワークに接続された一つまたは複数の機器に、符号化圧縮された複数の映像データを同時に配信可能な配信サーバにおいて、該複数の映像ストリームデータをグループに分類する手段と、同一グループ内の特定のストリームデータのビットレートを低くする制御手段とを備えることを特徴とする。【選択図】図１
2007325109.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された一つまたは複数の機器に、符号化圧縮された複数の映像データを同時に配信可能な配信サーバにおいて、
該複数の映像ストリームデータをグループに分類する手段と、
同一グループ内の特定のストリームデータのビットレートを低くする制御手段とを備えることを特徴とする配信サーバ。
【請求項２】
同一のサブネットに配信されている映像ストリームデータ、または同一のユーザが利用している映像ストリームデータ、または同一の機器に配信されている映像ストリームデータ、または同一のアプリケーションで利用されている映像ストリームデータ、または多重化されて格納されている複数の映像データを同一のグループとして分類することを特徴とする請求項１記載の配信サーバ。
【請求項３】
ビットレートを低くする特定のストリームデータは、ストリームを受信する端末の再生状態によって決定することを特徴とする請求項１記載の配信サーバ。
【請求項４】
ストリームを受信する端末の再生状態とは、マルチウインドウ表示におけるアクティブウインドウか非アクティブウインドウかの状態であり、非アクティブウインドウで再生表示されている映像ストリームのビットレートを低くする制御手段を備えることを特徴とする請求項３記載の配信サーバ。
【請求項５】
ストリームを受信する端末の再生状態とは、ピクチャインピクチャ表示におけるメイン画面かサブ画面かの状態であり、サブ画面で再生表示されている映像ストリームのビットレートを低くする制御手段を備えることを特徴とする請求項３記載の配信サーバ。
【請求項６】
再生表示を行うための映像ストリームデータと蓄積するための映像ストリームデータを独立して配信する場合において、ビットレートを低くする特定のストリームデータは、再生表示を行うための映像ストリームデータとすることを特徴とする請求項１記載の配信サーバ。
【請求項７】
配信要求された映像ストリーム数の増加により、配信ビットレートがネットワーク帯域を越える場合に、同一グループ内の特定のストリームデータのビットレートを低くする制御を行うことを特徴とする請求項１記載の配信サーバ。
【請求項８】
通信状態の変化により、パケット欠落率が一定の値を超えた場合に、同一グループ内の特定のストリームデータのビットレートを低くする制御を行うことを特徴とする請求項１記載の配信サーバ。
【請求項９】
ビットレートを低くする制御は、量子化ステップの変更、またはフレームレートの変更、画素サイズの変更により行われることを特徴とする請求項１記載の配信サーバ。
【請求項１０】
ネットワークに接続された一つまたは複数の機器に、被写体を広角に撮像した映像とズーム撮影した映像の符号化圧縮ストリームデータを同時に配信可能なネットワークカメラにおいて、
該複数の映像ストリームデータをグループに分類する手段を備え、
配信ビットレートがネットワーク帯域を越える場合、あるいは通信状態の変化により、パケットの欠落率が一定の値を超えた場合には、同一グループ内の広角撮影映像ストリームデータ、またはズーム撮影映像ストリームデータのビットレートを低くする制御手段を備えることを特徴とするネットワークカメラ。
【請求項１１】
同一のサブネットに配信されている映像ストリームデータ、または同一のユーザが利用している映像ストリームデータ、または同一の機器に配信されている映像ストリームデータ、または同一のアプリケーションで利用されている映像ストリームデータ、または多重化されて格納されている複数の映像データを同一のグループとして分類することを特徴とする請求項１０記載のネットワークカメラ。
【請求項１２】
ビットレートを低くする制御は、量子化ステップの変更、またはフレームレートの変更、画素サイズの変更により行われることを特徴とする請求項１０記載のネットワークカメラ。
【請求項１３】
ネットワークに接続された一つまたは複数の機器に、符号化圧縮された複数の映像データを同時に配信可能な配信方法において、
該複数の映像ストリームデータをグループに分類する工程と、
同一グループ内の特定のストリームデータのビットレートを低くする制御工程とを備えることを特徴とする配信方法。
【請求項１４】
請求項１３記載の配信方法の各工程をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じて複数の映像データを同時に伝送可能な配信サーバ等に関するものである。
【背景技術】
【０００２】
ネットワークに接続された機器間で映像配信を行う装置、例えばカメラで撮影された映像に対して符号化圧縮処理を行い、ネットワーク上のクライアントの要求に応じて映像ストリーム配信を行うネットワークカメラなどが実用化されている。
【０００３】
これらの装置から配信される映像データは、カメラや再生装置の高性能化に伴い、より高精細で高画質の映像が配信されるようになり、高速なネットワーク帯域が必要とされるようになってきた。
【０００４】
一方、ネットワークインフラにおいても、家庭内でもブロードバンドネットワークが一般的となり、有線ＬＡＮ、無線ＬＡＮともに高帯域のネットワーク回線が利用されるようになってきた。
【０００５】
しかしながら、遠隔地からインターネット網を経由してデータの伝送を行う場合には、通信経路によっては十分な帯域が確保されないケースや、また無線ＬＡＮを利用している場合は、周囲の環境によって通信帯域を低下させてしまうケースもしばしば見られる。
【０００６】
こういったケースでは、クライアントからの配信要求に対して十分なスループットが得られないため大幅な画質の低下を招いてしまうこととなる。
【０００７】
これを解決するために、無線ＬＡＮを用いた映像や音声の配信において通信状態が悪化した場合の画質の低下を最小限に抑える技術として、特許文献１に開示される発明のように、通信エラーの状態に応じてビットレートを可変制御する方法が提案されている。
【０００８】
一方、ネットワークカメラのような映像配信装置では、複数のクライアントに同時に異なる映像データを配信するシステムも実用化されつつある。
【０００９】
例えば、放送電波を通じた映像配信においては、各チャネルに割り当てられた伝送帯域を用いて映像や音声プログラムを多重化したデータとして配信する方法を用いており、各クライアント（受信機）はチャネルを選択して所望の映像や音声を再生するものである。
これらの放送システムにおいて画質の低下を低減する方法として、特許文献２や特許文献３に開示される発明のように、多重化されたデータに含まれる複数のプログラムのビットレート配分を制御する方法が提案されている。
【００１０】
【特許文献１】特開２００５−６２８６号公報
【特許文献２】特開平９−１４９３８８号公報
【特許文献３】特開２００１−１３６１３９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、サーバから複数のクライアントに同時に異なる映像データを配信するシステムは、各サーバやクライアントが接続されているネットワークが持つ固有の帯域やネットワーク状態により、送受信可能な最大ビットレートには制限がある。そのため、接続されるクライアントの数や要求ストリームの数が増加することによって、通信エラーによる画質低下を招いてしまうこととなる。
【００１２】
この画質低下は、クライアントを操作しているユーザが高品質で見たい映像かどうかに拘わらず、制限帯域を越えたネットワークに接続されている全てのクライアントに配信されているストリームに均等に発生する。そのため、ユーザにとって品質の安定しない映像となってしまう。
【００１３】
また、クライアントから新たなストリーム要求を行ったときに、現在配信されている既存のストリームがすでに通信帯域をいっぱいに使用している場合には、サーバが要求ストリームの配信を拒否するようなケースが発生する。あるいは、固定的に決められている優先度に従って、特定のストリームのみが優先的に帯域を割り当てられていることにより、それ以外のストリームの品位が著しく低下するようなケースも発生する。
【００１４】
本発明の目的は、サーバから複数のクライアントに同時に異なる映像データを配信する場合において、ネットワークの許容帯域を超えて映像データ配信要求があっても、他の有効なストリーム映像の画質への影響を最小にし、ストリーム増加を行うことにある。
【課題を解決するための手段】
【００１５】
本発明の配信サーバは、ネットワークに接続された一つまたは複数の機器に、符号化圧縮された複数の映像データを同時に配信可能な配信サーバにおいて、該複数の映像ストリームデータをグループに分類する手段と、同一グループ内の特定のストリームデータのビットレートを低くする制御手段とを備えることを特徴とする。
本発明のネットワークカメラは、ネットワークに接続された一つまたは複数の機器に、被写体を広角に撮像した映像とズーム撮影した映像の符号化圧縮ストリームデータを同時に配信可能なネットワークカメラにおいて、該複数の映像ストリームデータをグループに分類する手段を備え、配信ビットレートがネットワーク帯域を越える場合、あるいは通信状態の変化により、パケットの欠落率が一定の値を超えた場合には、同一グループ内の広角撮影映像ストリームデータ、またはズーム撮影映像ストリームデータのビットレートを低くする制御手段を備えることを特徴とする。
本発明の配信方法は、ネットワークに接続された一つまたは複数の機器に、符号化圧縮された複数の映像データを同時に配信可能な配信方法において、該複数の映像ストリームデータをグループに分類する工程と、同一グループ内の特定のストリームデータのビットレートを低くする制御工程とを備えることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、映像配信サーバに対して、ネットワークの許容帯域を超えて映像データ配信要求があった場合にも、他の有効なストリーム映像の画質への影響を最小にしてストリーム増加が行える。従って、ユーザにとって見たいストリームを常に高品位で再生することができるという効果を生む。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１８】
（第１の実施形態）
図１は、本発明の第１の実施形態の全体構成を表すブロック図である。
第１の実施形態では、ネットワークカメラにおいて複数のクライアントに異なる映像ストリームデータを同時に配信するシステムについて説明する。
【００１９】
図１において、１０１は第１の実施形態のネットワークカメラ全体を表わす部分である。このネットワークカメラ１０１は、撮像部１０２、画像処理部１０３、符号化部１０４、ネットワークプロトコル処理部１０５、ＭＡＣ（メディアアクセスコントロール）１０６、レートコントロール部１０７及びコネクション管理情報記憶部１０８を備える。更に、ネットワークカメラ１０１は、ストリーム配信情報記憶部１０９、ＣＰＵ１１０を有している。
【００２０】
撮像部１０２は、動画像を撮像するためのレンズ、ＣＣＤ、ＣＣＤコントロール部などを含んでおり、撮像された映像は撮像部１０１でＲＧＢデジタルデータに変換され画像処理部１０３へ送られる。
【００２１】
画像処理部１０３では、ＲＧＢデジタルデータをＹＣｂＣｒ４：２：０フォーマットのデジタルデータに変換する処理、あるいは要求された送信映像の画像サイズへの変換処理、各種フィルター処理などを行って符号化部１０４へ送る。
【００２２】
この画像処理部１０３は、入力された単一の撮像映像に対して複数の異なる画素サイズや画質のデジタルデータを出力することが可能となっている。
【００２３】
符号化部１０４は、ＭＰＥＧ４フォーマットへ圧縮処理を行うための符号化処理部であり、画像処理部１０３から送られた複数のデジタルデータに対して、時分割で符号化圧縮処理を行い、複数のＭＰＥＧ４ストリームデータを生成する。
【００２４】
生成されたＭＰＥＧ４ストリームデータはネットワークプロトコル処理部１０５へ送られ、ここでＴＣＰ／ＩＰパケットデータに変換され、ＭＡＣ１０６を通じてネットワーク１１１へ配信される。
【００２５】
配信されるデータとして１１４に示すように実線で表わしたストリームはクライアントの要求と同一の画質、ビットレートで配信されるストリーム、１１５に示すように破線で表わしたストリームはビットレートを落としたストリームを示している。
【００２６】
符号化部１０４が出力する符号化データのビットレートは、ＣＰＵ１１０からの指示によりレートコントロール部１０７によって制御される。
【００２７】
レートコントロール部１０７では目標ビットレートを満たすよう、符号化部１０４に対して、ＭＰＥＧ４の量子化ステップを変更する制御やフレームレートを変更するためのスケジューリング制御を行う。
【００２８】
コネクション管理情報記憶部１０８は、各配信ストリームごとに、接続クライアントに関連する静的なネットワーク情報を記憶している領域であり、詳細は図２に後述する。
【００２９】
情報ストリーム配信情報記憶部１０９は、各配信ストリームごとに、ストリームのメタ情報や再生状態、通信状態など動的に変化する情報を記憶している領域であり、詳細は図３に後述する。
【００３０】
これらの記憶部はＣＰＵ１１０あるいはネットワークプロトコル処理部１０５によって参照、更新が行われる。
【００３１】
ＣＰＵ１１０では、前述したように、コネクション管理情報記憶部１０８やストリーム配信情報記憶部１０９のデータを参照して接続クライアントの管理を行う。また、ＣＰＵ１１０は、ネットワーク状態やクライアントの状態の変化に応じてこれらの記憶部のデータを更新する処理、レートコントロール部１０７へ目標ビットレートを指示する処理を行う。
【００３２】
また、他に各種ネットワークサーバプロトコルなどを実行する。ＣＰＵ１１０の処理内容の詳細についてはフローチャートを用いて後述する。
【００３３】
１１２は、ネットワークカメラ１０１から配信される映像ストリームデータを受信して再生するための装置であるクライアントＡ、また１１３は同様にクライアントＢを表わしている。
【００３４】
これらのクライアントは専用のビューワやＰＣのアプリケーション、ネットワーク対応デジタルＴＶなど、ネットワークに接続された映像再生機能を持つ端末である。
【００３５】
１１１はネットワークカメラ１０１や各クライアント１１２、１１３が接続されているネットワーク網を表わしており、ローカルネットワークやインターネットなどを含んでいる。
【００３６】
次に図２に、コネクション管理情報記憶部１０８の詳細を示す。
図２において、２０１はストリーム１に関連する情報記憶領域、２０２はストリーム２に関連する情報記憶領域、２０３はストリーム３に関連する情報記憶領域を表わしており、配信されている各ストリームごとにそれぞれ管理情報が記憶されている。
【００３７】
２０１ａはストリーム１に対する送信先ＩＰアドレスであり、送信先の端末が有しているＩＰアドレスが格納されている。
【００３８】
２０１ｂはストリーム１に対するユーザ名であり、配信ストリームを利用しているユーザを識別するためのＩＤである。
【００３９】
このユーザ名は例えば再生端末のＯＳが管理しているログイン名などが想定される。
２０１ｃはストリーム１に対する送信先ポート番号であり、ＴＣＰ／ＩＰプロトコルでコネクションを確立している場合のクライアント側のポート番号が格納されている。
【００４０】
２０１ｄはストリーム１に対するプロトコル番号であり、コネクションで使用しているプロトコル（ＴＣＰまたはＵＤＰなど）を識別する番号が格納されている。
【００４１】
２０１ｅはストリーム１に対するアプリケーションＩＤであり、配信ストリームを利用しているアプリケーションを識別するためのＩＤである。
【００４２】
このアプリケーションＩＤはクライアントとのストリーム配信要求ネゴシエーションの中で取得するものである。これらの情報は、ストリーム２（２０２）、ストリーム３（２０３）に対しても同様に格納されている。
【００４３】
図３は、ストリーム配信情報記憶部１０９の詳細を表わしている。
図３において、３０１はストリーム１に関連する情報記憶領域である。３０２はストリーム２に関連する情報記憶領域である。３０３はストリーム３に関連する情報記憶領域を表わしており、コネクション管理情報記憶部１０８と同様に、配信されているストリーム毎にそれぞれ管理情報が記憶されている。
【００４４】
３０１ａはストリーム１に対する平均ビットレートであり、クライアントから要求された映像の画質に対応して、ＣＰＵ１１０からレートコントロール部１０７に指示している目標ビットレートの値が格納されている。
【００４５】
３０１ｂはストリーム１に対するフレームレートであり、同様にクライアントから要求された映像のフレームレートに対応して、ＣＰＵ１１０が符号化部１０４に設定している目標フレームレートの値が格納されている。
【００４６】
３０１ｃはストリーム１に対する画素サイズであり、クライアントから要求された映像の画素サイズに対応して、ＣＰＵ１１０が画像処理部１０３および符号化部１０４に設定している出力画素サイズの値が格納されている。
【００４７】
３０１ｄはストリーム１に対する再生状態を表わしており、配信されている映像ストリームがクライアント側でアクティブ状態かどうかを示すものである。
【００４８】
例えば、クライアント側で配信映像をウインドウ表示している場合にそのウインドウが選択状態であればアクティブ、非選択状態であれば非アクティブという場合が考えられる。また、ピクチャインピクチャ表示で、メイン画面に表示されている映像をアクティブ、子画面表示を非アクティブ場合が考えられる。画面例については後述する。
【００４９】
この再生状態は、クライアント側で再生状態が変化した場合に、ネットワークカメラ側に通知される。
【００５０】
３０１ｅはストリーム１に対するパケット欠落率であり、このパケット欠落率をモニタすることにより、クライアントまでのネットワークの状態を知ることができる。
【００５１】
欠落率が高い場合は、ネットワークのどこかで帯域が不足したりネットワークの切断などにより、パケットが輻輳したり、喪失したりしていることを示している。
【００５２】
この欠落率は例えばＲＴＣＰプロトコルで規定されている、受信品質レポートなどを利用することで得ることができる。
【００５３】
これらの情報は、ストリーム２（３０２）、ストリーム３（３０３）に対しても同様に格納されている。
【００５４】
次に、図４〜図６において、図１に示されるＣＰＵ１１０が実行するソフトウエアの制御を、フローチャートを用いて詳細に説明する。
【００５５】
図４は、クライアントから新規に映像ストリーム配信要求が行われた場合の制御フローである。
【００５６】
図４において、ステップＳ４０１では、ネットワークカメラがクライアントからストリーム配信要求が来るのを待つ処理を実行する。
【００５７】
ここで、ステップＳ４０２において、配信要求を受け付けた場合は、ステップＳ４０３において、ネットワークカメラが接続されているネットワークの通信帯域の余裕度をチェックする処理を実行する。
【００５８】
この余裕度のチェックは、図３で説明した、ストリーム配信情報記憶部１０９に格納されている各ストリームの平均ビットレート（３０１ａ）をすべて合計した値と、接続ネットワークの実効帯域の値を比較することにより行われる。
【００５９】
ここで、ステップＳ４０４において、オーバーした場合、つまりビットレートの合計値が実効帯域に対してある安全率を超えた場合には、ステップＳ４０５へ進む。
【００６０】
オーバーしない場合には、ステップＳ４１５において、クライアントからの要求ストリームの生成指示、つまり画像処理部１０３及び符号化部１０４に対して、要求される画素サイズやフレームレート、要求画質の映像ストリームデータを生成するように設定する。
【００６１】
それからステップＳ４１６において、ネットワークプロトコル処理部１０５を通じて、Ｓ４１５で生成したストリームをネットワークに配信するような処理を実行する。
【００６２】
Ｓ４０４において、接続ネットワーク帯域をオーバーした場合には、まずステップＳ４０５において、グループ化ポリシーの取得を行う。
【００６３】
グループ化ポリシーとは、配信されている各ストリームをどういう単位でグループ化するかというものである。
【００６４】
これは、次のケースを想定している。即ち、
・同一サブネットに接続されている端末に配信しているストリームを一つのグループとする場合
・同一ユーザが利用しているストリームを一つのグループとする場合
・同一端末、つまり同一ＩＰアドレスに配信されているストリームを一つのグループとする場合
・同一端末の同一アプリケーションで利用されているストリームを一つのグループとする場合
【００６５】
各ストリームのグループ化はコネクション管理情報記憶部１０８に格納されている情報を参照することによって行うことができる。
【００６６】
ステップＳ４０６で、取得したグループ化ポリシーが同一サブネットの場合には、ステップＳ４０７で、新規要求ストリームの配信先と同一サブネットに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行う。
【００６７】
続いてステップＳ４１４において、抽出したストリームのビットレートを下げる処理を行う。
【００６８】
この処理はレートコントロール部１０７に対して、対象ストリームの目標ビットレートを低くする指示を実行することで実現される。
【００６９】
また、Ｓ４０８で、取得したグループ化ポリシーが同一ユーザの場合は、ステップＳ４０９で、新規要求ストリームの利用ユーザと同一ユーザに配信されているストリームのうち、非アクティブとなっているストリームを全て抽出する処理を行う。そして、ステップＳ４１４へ進む。
【００７０】
また、Ｓ４１０で、取得したグループ化ポリシーが同一端末の場合は、ステップＳ４１１で、新規要求ストリームの配信先端末と同一端末に配信されているストリームのうち、非アクティブとなっているストリームを全て抽出する処理を行う。そして、ステップＳ４１４へ進む。
【００７１】
また、Ｓ４１２で、取得したグループ化ポリシーが同一アプリケーションの場合は、ステップＳ４１３に進む。ステップＳ４１３では、新規要求ストリームを利用しているアプリケーションと同一アプリケーションに配信されているストリームのうち、非アクティブとなっているストリームを全て抽出する処理を行う。そして、ステップＳ４１４へ進む。
【００７２】
Ｓ４１４のビットレート低下処理が終了すると、Ｓ４１５で低下ビットレートのストリーム生成指示、Ｓ４１６の配信指示へ進み、処理を終了する。
【００７３】
図５では、図４とは逆に、すでに配信している映像ストリームのうちあるストリームの配信停止要求がクライアントから行われた場合の制御フローを説明する。
【００７４】
図５において、ステップＳ５０１では、ネットワークカメラがクライアントからストリーム配信停止要求が来るのを待つ処理を実行する。
【００７５】
ここで、ステップＳ５０２において、配信停止要求を受け付けた場合は、ステップＳ５０３に進む。ステップＳ５０３においては、停止要求ストリームの生成を停止する処理、つまり画像処理部１０３および符号化部１０４に対して、要求されたストリームデータの生成を停止するような設定を行う処理を実行する。
【００７６】
それからステップＳ５０４において、ネットワークプロトコル処理部１０５に対して配信の停止を行うような処理を実行する。
【００７７】
次に、ステップＳ５０５において、ネットワークカメラが接続されているネットワークの通信帯域の配信停止後の余裕度をチェックする処理を実行する。
【００７８】
この余裕度のチェックは、図４ステップＳ４０３で説明した処理と同様の処理によって行われる。
【００７９】
ここで、ステップＳ５０６において、帯域に余裕が出た場合、つまりビットレートの合計値が実効帯域に対してある安全率を下回った場合には、ステップＳ５０７へ進む。引き続きオーバーしている場合には、そのまま処理を終了する。
【００８０】
Ｓ５０７では、グループ化ポリシーの取得を行う。このグループ化ポリシーの取得はＳ４０５と同様の処理により実現される。
【００８１】
取得したグループ化ポリシーが同一サブネットの場合には、ステップＳ５０８において、新規要求ストリームの配信先と同一サブネットに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行う。続いてステップＳ５１６において、抽出したストリームのビットレートを標準状態、つまり最初にクライアントから要求された仕様のビットレートへ戻す処理を行う。
【００８２】
この処理はＳ４１４と同様にレートコントロール部１０７に対する指示により行われる。
また、Ｓ５１０において、取得したグループ化ポリシーが同一ユーザの場合は、ステップＳ５１１に進む。ステップＳ５１１においては、新規要求ストリームの利用ユーザと同一ユーザに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ５１６へ進んだ後、処理を終了する。
【００８３】
また、Ｓ５１２において、取得したグループ化ポリシーが同一端末の場合は、ステップＳ５１３に進む。ステップＳ５１３においては、新規要求ストリームの配信先端末と同一端末に配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ５１６へ進んだ後、処理を終了する。
【００８４】
また、Ｓ５１４において、取得したグループ化ポリシーが同一アプリケーションの場合は、ステップＳ５１５に進む。ステップＳ５１５においては、新規要求ストリームを利用しているアプリケーションと同一アプリケーションに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ５１６へ進んだ後、処理を終了する。
【００８５】
続いて図６では、クライアントの再生状態が変化した場合の制御フローを説明する。
図６において、ステップＳ６０１では、クライアントの再生状態をモニタする処理を行う。これは、クライアントに対して制御コマンド用のコネクションを確立しておき、ネットワークを通じて再生状態の変化を通知するコマンドを待つ処理を実行するものである。
再生状態の変化とは、図３で説明したストリーム配信情報記憶部１０９における再生状態３０１ｄがアクティブから非アクティブへ、または非アクティブからアクティブへ変化することである。
【００８６】
ここで、ステップＳ６０２において、再生状態の変化の検知、つまり変更が行われたことを表わすコマンドを受信した場合には、ステップＳ６０３において、グループ化ポリシーの取得を行う。このグループ化ポリシーの取得はＳ４０５と同様の処理により実現される。
【００８７】
取得したグループ化ポリシーが同一サブネットの場合には、ステップＳ６０５において、新規要求ストリームの配信先と同一サブネットに配信されているストリームのうち、再生状態が変更されたストリームを抽出する処理を行う。
【００８８】
続いてステップＳ６１２において、グループ内のストリームに対してビットレート制御が実行されているどうかのチェックを行い、ビットレート制御が行われている場合は、ステップＳ６１３、Ｓ６１４のビットレートの再設定処理へ進む。ビットレート制御が行われていない場合は処理を終了する。
【００８９】
また、Ｓ６０６において、取得したグループ化ポリシーが同一ユーザの場合は、ステップＳ６０７に進む。ステップＳ６０７においては、新規要求ストリームの利用ユーザと同一ユーザに配信されているストリームのうち、再生状態が変更されたストリームを抽出する処理を行い、ステップＳ６１２へ進む。
【００９０】
また、Ｓ６０８において、取得したグループ化ポリシーが同一端末の場合は、ステップＳ６０９に進む。ステップＳ６０９においては、新規要求ストリームの配信先端末と同一端末に配信されているストリームのうち、再生状態が変更されたストリームを抽出する処理を行い、ステップＳ６１２へ進む。
【００９１】
また、Ｓ６１０において、取得したグループ化ポリシーが同一アプリケーションの場合は、ステップＳ６１１に進む。ステップＳ６１１においては、新規要求ストリームを利用しているアプリケーションと同一アプリケーションに配信されているストリームのうち、再生状態が変更されたストリームを抽出する処理を行い、ステップＳ６１２へ進む。
【００９２】
Ｓ６１３、Ｓ６１４のビットレートの再設定処理では、まずステップＳ６１３において、抽出されたストリームのうち非アクティブに変化したストリームのビットレートを低下するように、レートコントロール部１０７に指示する処理を実行する。
【００９３】
次にステップＳ６１４において、アクティブに変化したストリームのビットレートを標準状態、つまり最初にクライアントから要求された仕様のビットレートへ戻ように、レートコントロール部１０７に指示する処理を実行する。
【００９４】
図７は、図８は、図６のフローチャートで説明した制御処理において、クライアントが映像ストリームを表示している場合の表示画面の一例を表わす。
【００９５】
図７はマルチウインドウ表示の例であり、図において、７０１はクライアントの画面全体の表示領域である。この表示領域に、７０２、７０３、７０４の３つの表示ウインドウが開かれており、それぞれのウインドウに独立して映像１、映像２、映像３のストリームデータの表示が行われている。
【００９６】
７０２ａ、７０４ａは７０２、７０４の各ウインドウのタイトルバーであり、それぞれストリームの名称「映像１」「映像２」「映像３」のタイトル文字列が表示されている。
この時点で７０４のウインドウがアクティブ状態となっているため、一番前面に表示されるとともに、そのタイトルバー７０４ａが選択色で表示されている。
【００９７】
一方、図８では、ピクチャインピクチャ表示の例である。図８において、図７と同様に、８０１はクライアントの画面全体の表示領域を表わしており、その中にメイン画面の表示映像８０２（映像１）、サブ画面の表示映像８０３（映像２）が再生表示されている。この例では、メイン画面をアクティブ状態としている。
【００９８】
（第２の実施形態）
第１の実施形態では、クライアントからの要求ストリームの増減があった場合の、配信ビットレートコントロール処理についての実施形態を説明したが、本発明はこれに限定されるものではない。
【００９９】
ネットワークカメラと映像再生クライアントが接続されているネットワークは、その配信経路において、帯域の狭いネットワークを経由するような場合や、周囲の環境変化による通信品質の低下が発生したりする場合がある。このような場合、配信映像データのパケットエラーや伝送遅延などが生じてしまうケースがある。
【０１００】
こういう状況においては、例えば映像データがＭＰＥＧ２やＭＰＥＧ４など、前後フレームや周辺画素データとの差分を用いた符号化方式により圧縮されている場合には、映像品質の劣化が特に大きくなってしまう。
【０１０１】
従って、第２の実施形態では、これらの通信状況の変化に対応してビットレートコントロールを行うことで映像品質の低下を小さくするような例について説明する。
【０１０２】
通信状況の変化については、例えばＲＴＰ制御プロトコルであるＲＴＣＰで規定されている受信レポートを利用したエラー率をモニタすることで実現できる。ＲＴＣＰの受信レポートの構成については後述する。
【０１０３】
図９は、本発明の第２の実施形態において、ＣＰＵ１１０が実行するソフトウエアの制御を表すフローチャートである。
【０１０４】
図９において、ステップＳ９０１では、現在配信中の各ストリームのパケット欠落率をすべてチェックする処理を行う。
【０１０５】
このパケット欠落率はストリーム配信情報記憶部１０９中に格納されているパケット欠落率フィールド３０１ｅを読み出すことで実現されるものであり、このフィールドは前述のＲＴＣＰ受信レポートを受け取るたびに更新される。そのため、常に最新の欠落率を知ることが可能である。
【０１０６】
ここで、ステップＳ９０２において、ある閾値より高い欠落率を持つストリームがあると判断された場合は、ステップＳ９０３において、グループ化ポリシーの取得を行う。このグループ化ポリシーの取得はＳ４０５と同様の処理により実現される。
【０１０７】
取得したグループ化ポリシーが同一サブネットの場合には、ステップＳ９０５において、欠落率が閾値を超えているストリームの配信先と同一サブネットに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行う。
【０１０８】
続いてステップＳ９１２において、グループ内のストリームに対してビットレート制御が実行されているどうかのチェックを行い、ビットレート制御が行われている場合は、ステップＳ９１３のビットレートの低下処理へ進む。ビットレート制御が行われていない場合は処理を終了する。
【０１０９】
また、Ｓ９０６において、取得したグループ化ポリシーが同一ユーザの場合は、ステップＳ９０７に進む。ステップＳ９０７においては、欠落率が閾値を超えているストリームの利用ユーザと同一ユーザに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ９１２へ進む。
【０１１０】
また、Ｓ９０８において、取得したグループ化ポリシーが同一端末の場合は、ステップＳ９０９に進む。ステップＳ９０９においては、欠落率が閾値を超えているストリームの配信先端末と同一端末に配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ９１２へ進む。
【０１１１】
また、Ｓ９１０において、取得したグループ化ポリシーが同一アプリケーションの場合は、ステップＳ９１１に進む。ステップＳ９１１においては、欠落率が閾値を超えているストリームを利用しているアプリケーションと同一アプリケーションに配信されているストリームのうち、非アクティブとなっているストリームをすべて抽出する処理を行い、ステップＳ９１２へ進む。
【０１１２】
Ｓ９１３のビットレートの低下処理では、抽出されたストリームのうち非アクティブに変化したストリームのビットレートを低下するように、レートコントロール部１０７に指示する処理を実行する。
【０１１３】
次に、図１０に、パケットの欠落率を収集するために利用するＲＴＣＰ受信レポートのパケット構造を示す。
【０１１４】
図１０において、１００１はＶ（バージョン番号フィールド）であり、ＲＴＰのバージョン番号が格納される。
【０１１５】
１００２はＰ（パディングフィールド）、１００３はＲＣ（受信レポートのブロック数フィールド）であり、このパケットに含まれる受信レポート数が格納される。
【０１１６】
１００４はＰＴ（パケットタイプフィールド）であり、受信レポート（ＲＲ）を示す２０１が格納される。
【０１１７】
１００５は長さフィールドであり、パケット共通ヘッダ以降のコンテンツの長さが格納される。
【０１１８】
１００６はレポート作成者のＳＳＲＣ（識別子）、１００７はレポート対象者のＳＳＲＣ（識別子）フィールドである。
【０１１９】
１００８は欠落率フィールドであり、欠落したパケット数を受信すべきパケット数で割った値が格納される。
【０１２０】
さらに、１００９は累積欠落パケット数フィールドであり、ＲＴＰセッションにおいて欠落したパケットの累積総数が格納される。
【０１２１】
また、１０１０は最大拡張シーケンス番号フィールド、１０１１はパケット間隔ジッタフィールド、１０１２は最新送信レポートのタイムスタンプフィールド、１０１３は最新送信レポート経過時間フィールドであり、詳細な説明は割愛する。
【０１２２】
レポート対象者のＳＳＲＣ（１００７）から最新送信レポート経過時間（１０１３）までのフィールドが受信レポートブロックの１単位となり、以降、受信レポートブロック２（１０１４）へと続いていく。
【０１２３】
（第３の実施形態）
第３の実施形態では、本発明において、広角で撮影された映像ストリームとズーム撮影の映像ストリームを同時に配信可能なネットワークカメラへの応用例を説明する。
【０１２４】
ネットワークカメラからの配信映像をクライアントで再生表示する場合においては、カメラが撮影している被写体の全体を把握するための広角の映像と、注目部分を詳しく見るためのズーム映像を表示画面上に並べて同時に見たい場合がある。
【０１２５】
第１、第２の実施形態では、ネットワークの許容帯域を越えた映像配信が発生した場合には、映像の品位低下を防ぐためにクライアントの再生状態（アクティブか非アクティブ）により配信ストリームのビットレートをコントロールするような場合を説明した。これに対して、第３の実施形態では、広角映像とズーム映像を同時に配信可能なネットワークカメラにおいて、広角映像のビットレートをコントロールするような実施形態について説明する。
【０１２６】
図１１は、図１に示したネットワークカメラの全体構成において、第３の実施形態に対する撮像部１０２、画像処理部１０３の詳細ブロックを表わす図である。
【０１２７】
図１１において、１１０１は広角映像を撮影するためのカメラユニットである広角撮像部を示している。
【０１２８】
この広角撮像部１１０１には、レンズ群１（１１０２）、ＣＣＤ１（１１０３）、ＣＣＤコントロール部１（１１０４）、画像処理部１（１１０５）が含まれている。レンズ群１１０２は被写体像を光学的にＣＣＤ１１０２へ投影するために複数枚のレンズで構成されており広角に被写体を撮像できる特性を持っている。
【０１２９】
ＣＣＤ（光電変換素子）１１０３はレンズ群１１０２によって投影された撮影画像をアナログ電気信号に変換するための素子であり、ＶＧＡサイズ（６４０×４８０ドット）の画素数を持っている。
【０１３０】
３０フレーム／秒の速度でデータを読み出すことができる。ＣＣＤコントロール部１１０４は、ＣＣＤ１１０３に転送クロック信号やシャッタ信号を供給するためのタイミングジェネレータ、ＣＣＤ出力信号のノイズ除去、ゲイン処理を行うための回路を含む。更に、ＣＣＤコントロール部１１０４は、アナログ信号を１０ビットデジタル信号に変換するためのＡ／Ｄ変換回路などを含んでいる。また、画像処理部１１０５は、ＣＣＤコントロール部１１０４より出力された１０ビットデジタル信号をガンマ変換、色空間変換、また、ホワイトバランス、ＡＥ、フラッシュ補正等の画像処理を行う。そして、画像処理部１１０５は、ＹＣｂＣｒ（４：２：０）フォーマットの８ビットデジタル信号出力を行うものである。
【０１３１】
この広角映像はＶＧＡサイズ（６４０×４８０ドット）の画素数で、３０フレーム／秒の周期で出力している。
【０１３２】
１１０６は希望するズーム画角で撮影するためのカメラユニットであるズーム撮像部を示している。
【０１３３】
このズーム撮像部１１０６には広角撮像部１１０１と同様に、レンズ群２（１１０７）、ＣＣＤ２（１１０８）、ＣＣＤコントロール部２（１１０９）、画像処理部２（１１１０）を含む。さらに、ズーム撮像部１１０６には、撮影方向を移動させるパン、チルト動作のための制御モータ１１１１が含まれる。
【０１３４】
レンズ群１１０７は通常画角で撮影できる特性をもつズームレンズとして構成されている。
【０１３５】
また、ＣＣＤ１１０８はＳＸＧＡサイズ（１２８０×１０２４）の画素数を持っており、３０フレーム／秒での読み出しが可能である。
【０１３６】
ＣＣＤコントロール部２（１１０９）、画像処理部２（１１１０）は広角撮像部１１０１の各ブロックと同様の動作を行うものである。
【０１３７】
パン・チルト制御モータ１１１１は、カメラユニットを水平方向に回転させるためのモータと垂直方向に回転させるためのモータの２つのモータ、およびそれぞれの駆動回路で構成されている。
【０１３８】
以上のように、本実施形態のネットワークカメラにはそれぞれ異なった画角で撮影が可能な２つの撮像部が搭載されており、それぞれの撮像部から出力されたデジタルデータは符号化部１０４へ送られる。
【０１３９】
続いて図１２に、第３の実施形態において、クライアントから新規に映像ストリーム配信要求が行われた場合の制御フローを示す。
【０１４０】
図１２において、ステップＳ１２０１では、ネットワークカメラがクライアントからストリーム配信要求が来るのを待つ処理を実行する。
【０１４１】
ここで、ステップＳ１２０２において、配信要求を受け付けた場合は、ステップＳ１２０３において、ネットワークカメラが接続されているネットワークの通信帯域の余裕度をチェックする処理を実行する。
【０１４２】
この余裕度のチェックは、図４、Ｓ４０３で説明した処理と同様の手順で行われる。ここで、ステップＳ１２０４において、オーバーした場合、つまりビットレートの合計値が実効帯域に対してある安全率を超えた場合には、ステップＳ１２０５へ進む。
【０１４３】
オーバーしない場合には、ステップＳ１２１５において、クライアントからの要求ストリームの生成指示、つまり画像処理部１０３及び符号化部１０４に対し、要求される画素サイズやフレームレート、要求画質の映像ストリームデータを生成する設定を行う。
【０１４４】
それからステップＳ１２１６において、ネットワークプロトコル処理部１０５を通じて、Ｓ１２１５で生成したストリームをネットワークに配信するような処理を実行する。
【０１４５】
Ｓ１２０４において、接続ネットワーク帯域をオーバーした場合には、まずステップＳ１２０５において、グループ化ポリシーの取得を行う。グループ化ポリシーの取得についても、図４、Ｓ４０５と同様の手順で行われる。
【０１４６】
ステップＳ１２０６において、取得したグループ化ポリシーが同一サブネットの場合には、ステップＳ１２０７において、新規要求ストリームの配信先と同一サブネットに配信されているストリームのうち、広角撮影映像のストリームをすべて抽出する処理を行う。
続いてステップＳ１２１４において、抽出したストリームのビットレートを下げる処理を行う。
【０１４７】
この処理はレートコントロール部１０７に対して、対象ストリームの目標ビットレートを低くする指示を実行することで実現される。
【０１４８】
また、Ｓ１２０８において、取得したグループ化ポリシーが同一ユーザの場合は、ステップＳ１２０９に進む。ステップＳ１２０９においては、新規要求ストリームの利用ユーザと同一ユーザに配信されているストリームのうち、広角撮影映像のストリームをすべて抽出する処理を行い、ステップＳ１２１４へ進む。
【０１４９】
また、Ｓ１２１０において、取得したグループ化ポリシーが同一端末の場合は、ステップＳ１２１１に進む。ステップＳ１２１１においては、新規要求ストリームの配信先端末と同一端末に配信されているストリームのうち、広角撮影映像のストリームをすべて抽出する処理を行い、ステップＳ１２１４へ進む。
【０１５０】
また、Ｓ１２１２において、取得したグループ化ポリシーが同一アプリケーションの場合は、ステップＳ１２１３に進む。ステップＳ１２１３においては、新規要求ストリームを利用しているアプリケーションと同一アプリケーションに配信されているストリームのうち、広角撮影映像のストリームをすべて抽出する処理を行い、ステップＳ１２１４へ進む。
【０１５１】
Ｓ１２１４のビットレート低下処理が終了すると、Ｓ１２１５で低下ビットレートのストリーム生成指示、Ｓ１２１６の配信指示へ進み、処理を終了する。
【０１５２】
図１３は、第３の実施形態において、クライアントが映像ストリームを表示している場合の表示画面の一例を表わす。
【０１５３】
図１３は図７と同様にマルチウインドウ表示の例であり、図において、１３０１はクライアントの画面全体の表示領域である。
【０１５４】
この表示領域に、１３０２に示すズーム映像画面、１３０３に示す広角映像画面の２つの表示ウインドウが開かれている。それぞれのウインドウには、ネットワークカメラのズーム撮像部１１０６で撮像され符号化されたズーム映像ストリーム、および広角撮像部１１０１で撮像され符号化された広角映像ストリームが独立して表示再生されている。
【０１５５】
（その他の実施形態）
第１、第２の実施形態では、各グループにおけるアクティブストリームは、アクティブウインドウに配信されているストリーム、ピクチャインピクチャ画面におけるメイン画面のストリームとしている。第３の実施形態では、ズーム映像のストリームとしているが、本発明はこれに限定されるものではない。例えば、リアルタイムに表示再生を行うためのストリームと蓄積保存のためのストリームが混在して配信されている場合においては、表示再生ストリームをビットレートコントロールの対象とするような実施形態も考えられるのは言うまでもない。
【０１５６】
また、通信帯域の品質を知るための手段としてＲＴＣＰの受信レポートを利用するような実施形態を説明した。しかし、本発明はこれに限定するものではなく、例えばＴＣＰを利用したストリーム配信の場合には、ネットワークプロトコル処理部１０５において、ＴＣＰの再送要求の頻度を各ストリームのコネクションごとにモニタすることにより同様の機能を実現できる。
【０１５７】
あるいは、ネットワークカメラと各クライアントが独自のアプリケーションでネゴシエーションすることで、通信品質をモニタすることも可能である。
また、第１〜第３の実施形態では、ビットレートコントロールの範囲を、新規に追加されたストリームの所属するグループ、あるいは通信エラー率が増加したストリームの所属するグループ内に限定した実施形態で説明した。しかし、本発明はこれに限定されるものではなく、同一グループ内でビットレートコントロールを行っても通信帯域が十分に確保できない場合には、他のグループに対しても同様のビットレートコントロールを行うような実施形態も考えられるのは言うまでもない。
【０１５８】
また、第１〜第３の実施形態では、ビットレートコントロールの手法として、レートコントロール部１０７からの制御による、ＭＰＥＧの量子化ステップの変更や、フレームレートの変更として説明した。しかし、本発明はこれに限定されるものではなく、映像の画素サイズの変更やより符号化効率の高い圧縮方法への切り替えなども含まれることは言うまでもない。
【０１５９】
さらに、配信される映像ストリームデータのグループとして、複数の映像データが多重化されて構成されているストリームを一つのグループとして分類する。そして、多重化されて格納されている各映像データ単位でビットレートを可変にするようにコントロールするという実施形態も考えられる。
【０１６０】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或いは装置に供給し、そのシステム等のコンピュータが記憶媒体からプログラムコードを読み出し実行することによっても達成される。
【０１６１】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１６２】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１６３】
また、コンピュータが読み出したプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１６４】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに接続された機能拡張ユニット等に備わるメモリに書込まれた後、そのプログラムコードの指示に基づきＣＰＵ等が実際の処理を行い、前述した実施形態の機能が実現される場合も含まれる。
【図面の簡単な説明】
【０１６５】
【図１】本発明の第１の実施形態による全体構成を表すブロック図である。
【図２】本発明の第１の実施形態によるコネクション管理情報記憶部の詳細を示す図である。
【図３】本発明の第１の実施形態によるストリーム配信情報記憶部の詳細を示す図である。
【図４】本発明の第１の実施形態によるクライアントから新規に映像ストリーム配信要求が行われた場合の制御を表わすフローチャートである。
【図５】本発明の第１の実施形態によるクライアントからストリームの配信停止要求が行われた場合の制御を表わすフローチャートである。
【図６】本発明の第１の実施形態による、クライアントの再生状態が変化した場合の制御を表わすフローチャートである。
【図７】本発明の第１の実施形態によるクライアントが映像ストリームを表示している場合のマルチウインドウ表示画面の一例を示す図である。
【図８】本発明の第１の実施形態によるクライアントが映像ストリームを表示している場合のピクチャインピクチャ表示画面の一例を示す図である。
【図９】本発明の第２の実施形態によるＣＰＵが実行するソフトウエアの制御を表わすフローチャートである。
【図１０】本発明の第２の実施形態によるＲＴＣＰ受信レポートのパケット構造を示す図である。
【図１１】本発明の第３の実施形態による撮像部、画像処理部の詳細ブロックを表わす図である。
【図１２】本発明の第３の実施形態によるクライアントから新規に映像ストリーム配信要求が行われた場合の制御を表わすフローチャートである。
【図１３】本発明の第３の実施形態によるクライアントが映像ストリームを表示している場合のマルチウインドウ表示画面の一例を示す図である。
【符号の説明】
【０１６６】
１０１  ネットワークカメラ全体
１０２  撮像部
１０３  画像処理部
１０４  符号化部
１０５  ネットワークプロトコル処理部
１０６  ＭＡＣ
１０７  レートコントロール部
１０８  コネクション管理情報記憶部
１０９  ストリーム配信情報記憶部
１１０  ＣＰＵ
１１１  ネットワーク網
１１２  クライアントＡ
１１３  クライアントＢ
【図１】
2007325109.tif 000003
【図２】
2007325109.tif 000004
【図３】
2007325109.tif 000005
【図４】
2007325109.tif 000006
【図５】
2007325109.tif 000007
【図６】
2007325109.tif 000008
【図７】
2007325109.tif 000009
【図８】
2007325109.tif 000010
【図９】
2007325109.tif 000011
【図１０】
2007325109.tif 000012
【図１１】
2007325109.tif 000013
【図１２】
2007325109.tif 000014
【図１３】
2007325109.tif 000015