JP2014143496A - 送信装置、送信装置の制御方法およびプログラム - Google Patents

Abstract

【課題】サーバがクライアントの要求に応じて短時間でキーフレームを送信してリアルタイム性を確保しながらも、多数のクライアントの同時接続によるキーフレームの乱発的生成を防止する。
【解決手段】受信装置に符号化した動画データ動画データを送信する送信装置は、受信装置から受信した要求に対応するキーフレーム依頼と、該キーフレーム依頼の登録時から規定時間内に受信した別の要求に対応するキーフレーム依頼とを一つのキーフレーム依頼としてフレーム内符号化を実行する。

【選択図】 図７

Description

本発明は動画データのネットワーク伝送を行う送信装置、送信装置の制御方法およびプログラムに関する。

インターネット及びＬＡＮ上をリアルタイムに動画データをストリーム伝送する有力な技術として、ＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が知られている。ＲＴＰによるストリームを制御するプロトコルとして、ＲＴＳＰ（Ｒｅａｌｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）が一般的に利用されている。また、動画ストリーム伝送に利用される主要な動画符号化方式として、Ｈ．２６４（ＭＰＥＧ−４／ＡＶＣ）方式が知られている。Ｈ．２６４方式を始めとした動画符号化方式は、いわゆるフレーム間予測という方式を採用している。フレーム間予測方式において、動画像フレームは、一つのフレームのデータのみでそのフレーム画像を復号可能なフレームと、別フレームデータも含めて一つのフレーム画像を復号可能なフレームに分けることができる。特に、前者のフレームは他のフレームと区別するために、一般的にキーフレームと呼ばれ、Ｈ．２６２／２６３方式ではＩフレーム、Ｈ．２６４方式ではＩＤＲフレームに該当する。

動画データのキーフレームの有用性は、ランダムアクセスにおいて再生開始点（フレーム）となることにある。これは動画ストリーム伝送の際も同様である。従って、サーバは、クライアントから再生開始要求を受信した場合、キーフレームから送信することが重要である。何故なら、非キーフレームから送信したとしても、クライアントはキーフレームが到着するまでの間の動画フレームを正常に復号することはできないからである。従って、ビデオ会議や監視カメラの様にリアルタイム性が重要となる用途では、サーバは、クライアントからの再生開始要求に応じて、即座にキーフレームを送信する機能の実装が重要である。サーバがキーフレームの送信を即座に行わないと、クライアントは即座に再生を開始できない。すなわち、リアルタイム性を損なう。なお、一般的なキーフレームの生成間隔は数秒のオーダーである。このように、サーバは、クライアントからの再生開始要求またはキーフレーム同期要求に応じて、できるだけ早くキーフレームを送信する必要がある。

このような課題に対する従来技術として、サーバがクライアントから要求を受信すると、サーバ内の符号化部に対してキーフレームの即時生成を依頼するという方法がある。非特許文献１には、Ｆｕｌｌ ＩＮＴＲＡ−ｆｒａｍｅ Ｒｅｑｕｅｓｔ（ＦＩＲ）について記載されている。具体的には、非特許文献１には、クライアントがＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）に基づいて、サーバに対してフレーム内符号化データの即時生成と送信を要求するＦＩＲについて記載されている。サーバ内の符号化部は、ＦＩＲによってキーフレームの即時生成依頼を受けると、本来の次のキーフレーム生成のタイミングに関係なく、即座にキーフレームを生成する。すなわち、サーバはクライアントの再生開始要求の直後にキーフレームを生成し、送信できる。これにより、リアルタイム性が確保される。

T. Turletti and C. Huitema. RTP Payload Format for H.261Video Streams. 1996.

しかしながら、従来技術のように、サーバが、クライアントからの再生開始要求に応じてサーバ内の符号化部にキーフレームの即時生成を指示する方法では、複数のクライアントが短時間の間に接続要求を行った場合に問題が生じる。複数のクライアントが短時間の間に接続要求を行った場合、符号化部は短時間の間に複数のキーフレームを生成することにより、動画データの送信レートが不必要に高まってしまう。特に、動画ストリームが全てユニキャストで送信される場合、総送信データレートが一時的に急増することになり、データ伝送の輻輳を起こす可能性が高くなる。

また、符号化部が複数のキーフレームを短時間の間に生成すると、処理負荷が非常に高まることから、特に組み込み機器の符号化装置では機能停止に陥ることもある。動画ストリームがユニキャストで送信される場合、ネットワーク回線の容量から同時接続クライアント数は十数までに制限されることが現実的である。これに対し、マルチキャストで送信される場合は動画ストリームを共有するため数十から百程度のクライアント数に対応することが現実的な使用例である。つまり、ユニキャスト送信並びにマルチキャスト送信に対応するために、少なくとも数十のクライアントからの同時接続に耐えるシステムを実現することが要求される。

また、符号化部が出力する動画データは、リアルタイム動画視聴以外にも利用される場合もあり、このような場合にも問題が生じる。例えば、撮影映像の録画サービスを有する監視カメラシステムでは、リアルタイムストリームのクライアントが複数同時に接続しキーフレームが短時間に複数生成される。この場合、録画映像データにもキーフレームが複数記録されることになり、映像データのデータ量を無駄に増大させることになる。

本発明は、上記課題に鑑みてなされたものであり、サーバがクライアントの要求に応じて短時間でキーフレームを送信してリアルタイム性を確保しながらも、複数のクライアントの同時接続によるキーフレームの乱発的生成を防止することを目的とする。

上記目的を達成するための一手段として、本発明のデータ送信装置は以下の構成を備える。すなわち、受信装置に符号化した動画データを送信する送信装置であって、キーフレーム依頼を受けて動画データに対してフレーム内符号化を行う符号化手段と、前記受信装置から要求を受信し、該要求に対応するキーフレーム依頼を登録する管理手段とを備え、前記管理手段は、受信した要求に対応するキーフレーム依頼と、該キーフレーム依頼の登録時からから規定時間内に受信した別の要求に対応するキーフレーム依頼とを一つのキーフレーム依頼として、該規定時間の経過後に前記符号化手段に送ることを特徴とする。

本発明によれば、サーバがクライアントの要求に応じて短時間でキーフレームを送信してリアルタイム性を確保しながらも、複数のクライアントの同時接続によるキーフレームの乱発的生成を防止することが可能となる。

実施形態によるシステムの全体構成を示す図。 実施形態による送信装置の機能ブロックを示す図。 第１実施形態によるキーフレーム生成依頼処理フローチャートを示す図。 第１実施形態によるクライアント要求の解析処理フローチャートを示す図。 第１実施形態によるキーフレーム依頼格納部の例を示す図。 第１実施形態によるキーフレーム依頼の有効性判定処理フローチャートを示す図。 第１実施形態によるキーフレーム生成依頼処理フローチャートを示す図。 第１実施形態による符号化フレーム送信を示す図。 第２実施形態によるキーフレーム依頼の有効性判定処理フローチャートを示す図。 第３実施形態によるキーフレーム依頼の有効性判定処理フローチャートを示す図。

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

以下の実施形態では、一種類のＨ．２６４映像を出力可能な映像符号化装置を備えるネットワークカメラが、同時に複数の映像再生クライアントにストリーム配信する状況を想定する。なお、簡単のため、ネットワークカメラとクライアントとの間のネットワーク接続、配信メディア情報のやり取り、ストリーム送信の開始処理、停止処理の説明については省略する。

［第１実施形態］
図１は、本実施形態によるシステムの全体構成を示す図である。サーバとしてのネットワークカメラ１０１は、ネットワーク１０２を介して、クライアント１〜Ｎ（１０３〜１０５）と接続される。ここで、ネットワークカメラ１０１から出力される動画ストリーム（符号化後の動画データ）は、ユニキャストもしくはマルチキャストでクライアントに配信される。

図２は、本実施形態によるネットワークカメラ１０１（送信装置）の機能ブロックを示す図である。撮像部２０１は、映像を撮影し、撮像データ（動画データ）をビットマップデータとして符号化部２０２に渡す。符号化部２０２は、フレーム間予測を用いる符号化方式であるＨ．２６４方式で撮像データを圧縮符号化し、フレームデータとしてフレームバッファ２０３へ格納する。なお、符号化部２０２は、複数の符号化設定のＨ．２６４データストリームを同時に生成することはできない。ストリーム送信部２０４は、フレームバッファ２０３に格納されたフレームデータをＲＴＰパケットに変換する。ＲＴＰパケットは、通信部２０５、ネットワーク１０２を介してクライアント１〜Ｎ（１０３〜１０５）へ送信される。

ストリーム管理部２０６は、ＲＴＳＰに基づいたセッション管理の機能と、映像ストリームの送信管理の機能を有する。さらに、ストリーム管理部２０６は、クライアントからのＲＴＣＰメッセージに基づいたパケットロス及び輻輳の検知機能と、フレーム内符号化されたキーフレーム生成を符号化部２０２に対し依頼する機能を有する。

ストリーム管理部２０６は、まず、第１のクライアント１０３からＲＴＳＰ ＳＥＴＵＰ要求を受信すると、符号化部２０２に対し符号化処理の準備を指示する。次に、ストリーム管理部２０６は、クライアント１０３からＲＴＳＰ ＰＬＡＹ要求を受信すると、符号化部２０２に対しキーフレームの生成を依頼することにより、フレーム内符号化処理の開始を指示する。これと同時に、ストリーム管理部２０６は、ストリーム送信部２０４に対しクライアント１０３へのＨ．２６４データのストリーム送信を指示する。また、ストリーム管理部２０６は、キーフレーム依頼待機状況を格納するキーフレーム依頼格納部２０７を有する。ストリーム管理部２０６は、クライアントからのＲＴＳＰ ＰＬＡＹ要求に応じて、キーフレーム依頼格納部２０７を参照して、以下に述べるような方法で符号化部２０２に対してキーフレームの生成依頼処理を行う。

本実施形態によるストリーム管理部２０６が行う、符号化部２０２に対するフレーム内符号化されたキーフレーム生成依頼処理の手順について、図を参照して説明する。但し、簡単のため、ストリームの停止処理の説明については省略する。図３に、ストリーム管理部２０６が行うフレーム内符号化されたキーフレーム生成依頼処理のフローチャートを示す。図３示す処理は、ストリーム管理部２０６がクライアントから要求メッセージを受信した際に開始する。まず、ストリーム管理部２０６は、クライアントから受信した要求メッセージの解析処理を行う（Ｓ３０１）。ストリーム管理部２０６は、Ｓ３０１の解析の結果に基づいて、要求メッセージが新たなストリームの開始要求、すなわち、ＲＴＳＰ ＰＬＡＹ要求であるか否かを判断する（Ｓ３０２）。要求メッセージがＲＴＳＰ ＰＬＡＹ要求ではないと判断した場合（Ｓ３０２のＮｏ）は、ストリーム管理部２０６は処理をＳ３０４へ進める。一方、要求メッセージがＲＴＳＰ ＰＬＡＹ要求であると判断した場合（Ｓ３０２のＹｅｓ）は、ストリーム管理部２０６は、ＲＴＳＰ ＰＬＡＹ要求に対応するキーフレーム依頼の登録処理を行い（Ｓ３０３）、処理をＳ３０４へ進める。その後、ストリーム管理部２０６は、符号化部２０２を監視することによって、キーフレーム依頼の有効性を判定する処理を行い（Ｓ３０４）、符号化部２０２に対してキーフレーム生成依頼を実行する（Ｓ３０５）。その後、ストリーム管理部２０６は、キーフレーム依頼格納部２０７を参照し（Ｓ３０６）、待機しているキーフレーム依頼がある場合（Ｓ３０７のＹｅｓ）、処理をＳ３０１に戻す。待機しているキーフレーム依頼がない場合（Ｓ３０７のＮｏ）、ストリーム管理部２０６は、処理を終了する。

図３におけるクライアント要求の解析処理（Ｓ３０１）から、キーフレーム依頼の登録処理（Ｓ３０３）について、図４及び図５を用いて具体的に説明する。図４は、本実施形態によるクライアント要求の解析に関する処理（Ｓ３０１〜Ｓ３０３）の詳細な処理フローチャートを示す図である。Ｓ４０１とＳ４０２は、図３のＳ３０１とＳ３０２と同様の処理を行う。ストリーム管理部２０６は、まずクライアントから要求メッセージであるＲＴＳＰ要求を受信し（Ｓ４０１）、この要求が新たなストリームの送信依頼としてのＲＴＳＰ ＰＬＡＹ要求であるか否かを判定する（Ｓ４０２）。ＲＴＳＰ ＰＬＡＹ要求ではない場合（Ｓ４０２のＮｏ）、ストリーム管理部２０６は、このＲＴＳＰ ＰＬＡＹ要求に対応するキーフレーム依頼を登録する必要はないと判断して、処理を終了する。一方、ＲＴＳＰ ＰＬＡＹ要求である場合（Ｓ４０２のＹｅｓ）、ストリーム管理部２０６は、キーフレーム依頼格納部２０７を参照して（Ｓ４０３）、以降の処理を進める（Ｓ４０４〜Ｓ４０７）。

ここで、キーフレーム依頼格納部２０７について説明する。図５は、キーフレーム依頼格納部２０７に格納される内容を示す図である。キーフレーム依頼格納部２０７は、格納する項目として、待機状態であるキーフレーム依頼の有無を示す項目（５０１）と、登録時間（５０２）を有する。ここで、待機状態とは、ストリーム管理部２０６が受信したＲＴＳＰ ＰＬＡＹ要求に対応するキーフレーム依頼が、その依頼の実行のために待機している状態を表す。また、登録時間とは、そのキーフレーム依頼がストリーム管理部２０６に登録された時間を表す。図５（ａ）は、待機状態のキーフレーム依頼が無い場合のキーフレーム依頼格納部２０７の様子を示しており、依頼待機有無の項目（５０３）が０、すなわち、待機しているキーフレーム依頼が無いことを示している。したがって、登録時間（５０４）も０である。一方、図５（ｂ）はキーフレーム依頼が待機状態である場合のキーフレーム依頼格納部２０７の様子を示しており、依頼待機有無の項目（５０５）が１、すなわち、待機しているキーフレーム依頼が一つあることを示している。そして、この依頼が登録された時間が１０１０００ミリ秒と記録されている（５０６）。

ストリーム管理部２０６は、キーフレーム依頼格納部２０７を参照し（Ｓ４０３）、待機状態のキーフレーム依頼の有無を判定する（Ｓ４０４）。既に待機状態のキーフレーム依頼がある場合（Ｓ４０４のＹｅｓ）、すなわち図５（ｂ）の場合、ストリーム管理部２０６は、新たにキーフレーム依頼を登録する必要はないと判断して、処理を終了する。これは、複数の待機状態のキーフレーム生成依頼を作らずに、一つを共有するためである。一方、待機状態のキーフレーム依頼がない場合（Ｓ４０４のＮｏ）、すなわち図５（ａ）の場合、ストリーム管理部２０６は、更に現在キーフレームを送信中であるか判定する（Ｓ４０５）。なお、ここではストリーム管理部２０６がＲＴＳＰ ＰＬＡＹ要求を受信した後に、キーフレームを送信中か否かを判定するものとする。また、キーフレームを送信中であるかは、ストリーム送信部２０４を監視することによって判定できる。キーフレームを現在送信中である場合（Ｓ４０５のＹｅｓ）は、ストリーム管理部２０６は、キーフレームの生成が実行されることにより、新たに依頼を登録する必要はないと判断して、処理を終了する。なお、Ｓ４０３からＳ４０４を経ずにＳ４０５へ処理を進めることも可能である。一方、キーフレームを現在送信中でない場合（Ｓ４０５のＮｏ）は、ストリーム管理部２０６は、現在時刻を取得（Ｓ４０６）する。そして、ストリーム管理部２０６は、キーフレーム依頼格納部２０７の待機有無の項目（５０１）を１とし、取得した現在時刻を登録時間の項目（５０２）に設定し（Ｓ４０７）、処理を終了する。以上の手順により、ストリーム管理部２０６はクライアントからのストリーム開始要求に応じてキーフレーム依頼を即座には実行せず、まず待機状態とする。つまり、一つのキーフレーム依頼が登録されてから短時間の間にストリーム管理部２０６が別のクライアントからＲＴＳＰ ＰＬＡＹ要求を受信し、ＲＴＳＰ ＰＬＡＹ要求に対応するキーフレーム依頼が登録された場合、一つの待機状態が共有される。

次に、待機状態のキーフレーム依頼の有効性判定処理（Ｓ３０４）について、図６を参照して説明する。図６は、本実施形態によるキーフレーム依頼の有効性判定処理（Ｓ３０４）の詳細な処理フローチャートを示す図である。まず、ストリーム管理部２０６は、フレームバッファ２０３を監視し（Ｓ６０１）、符号化部によりキーフレームが生成されたか否かを判定する（Ｓ６０２）。キーフレームが作成されていない場合（Ｓ６０２のＮｏ）は、ストリーム管理部２０６は、待機状態のキーフレーム依頼の有効性判定は不要と判断して、処理を終了する。一方、キーフレームが作成された場合（Ｓ６０２のＹｅｓ）は、ストリーム管理部２０６は、キーフレーム依頼格納部２０７を参照する（Ｓ６０３）ことによって、待機状態のキーフレーム依頼があるか判定する（Ｓ６０４）。待機状態のキーフレーム依頼が無い場合（Ｓ６０４のＮｏ）は、ストリーム管理部２０６は、機状態のキーフレーム依頼の有効性判定は不要と判断して、処理を終了する。一方、待機状態のキーフレーム依頼がある場合（Ｓ６０４のＹｅｓ）は、ストリーム管理部２０６は、キーフレーム依頼格納部２０７の待機設定を無効化する（Ｓ６０５）。つまり、図５を（ｂ）から（ａ）のように変える。以上の手順により、ストリーム管理部２０６は、符号化部２０２がキーフレームを生成した場合には、それまで待機状態となっていたキーフレーム依頼に対して符号化が実行されたと判断し、このキーフレーム依頼を無効化する。

次に、図３におけるキーフレーム生成依頼処理（Ｓ３０５）について、図７を参照して説明する。図７は、本実施形態によるキーフレーム生成依頼処理（Ｓ３０５）の詳細な処理フローチャートを示す図である。まず、ストリーム管理部２０６は、キーフレーム依頼格納部２０７を参照し（Ｓ７０１）、待機状態のキーフレーム依頼があるか否かを判定する（Ｓ７０２）。待機状態のキーフレーム依頼がない場合（Ｓ７０２のＮｏ）は、ストリーム管理部２０６は、キーフレーム生成の必要はないと判断して、処理を終了する。一方、待機状態のキーフレーム依頼がある場合（Ｓ７０２のＹｅｓ）は、ストリーム管理部２０６は、キーフレーム依頼格納部２０７に格納されている現在時刻を取得する（Ｓ７０３）。そして、ストリーム管理部２０６は、取得した登録時間と所定の規定時間を比較して、この登録時間が規定時間を経過したか否かを判断する（Ｓ７０４）。待機状態のキーフレーム依頼に対して、前回符号化された時間から短い時間内で符号化を実行することを防ぐためである。登録時間が規定時間を経過していない場合（Ｓ７０４のＮｏ）は、ストリーム管理部２０６は、キーフレーム生成の必要はないと判断して、処理を終了する。登録時間が規定時間を経過した場合（Ｓ７０４のＹｅｓ）は、ストリーム管理部２０６は、符号化部２０２に対して直ちにキーフレームの生成依頼を行う（Ｓ７０５）。そして、ストリーム管理部２０６は、キーフレーム依頼格納部２０７の待機状態の設定を無効化し（Ｓ７０６）、処理を終了する。以上の手順により、ストリーム管理部２０６は、キーフレーム依頼が待機状態になってから規定時間内に符号化部２０２にキーフレーム生成の依頼を行うことができる。そして、符号化部２０２は、キーフレーム依頼を受けると即座に符号化処理を行い、キーフレームを生成する。

以上の手順によりキーフレーム依頼を遅延させて実行する様子について、図８を参照して説明する。図８（ａ）は、クライアント１（１０３）に対して送信される符号化フレームの様子を時間軸に沿って表している。キーフレーム８０１が最初に生成され、それ以降はフレーム間参照符号化された、いわゆるＰフレーム８０２が定期的に生成されている。

図８（ｂ）は、図８（ａ）の８０２のＰフレーム生成直後にクライアント２（１０４）からクライアントＮ（１０５）がＲＴＣＰ ＰＬＡＹ要求８０４を短時間の間に連続して行った場合の、本実施形態によるキーフレーム生成依頼処理の様子を表している。最初のＲＴＣＰ ＰＬＡＹ要求８０３に対応するキーフレーム依頼８０５は、所定の規定時間の間、待機状態（待機状態のキーフレーム依頼）となる（図４のＳ４０７）。所定の規定時間内に受信されたＲＣＴＰ ＰＬＡＹ要求８０４に対応するキーフレーム依頼は、待機状態のキーフレーム依頼８０５に統合される（図４のＳ４０４のＹｅｓ）。待機時間が所定の規定時間を経過した時点８０６で、ストリーム管理部２０６は符号化部２０２へキーフレーム生成を依頼する（図７のＳ７０５）。符号化部２０２は、キーフレーム生成依頼によりキーフレーム８０７を即座に生成する。

図８（ｃ）は、キーフレーム依頼が待機期間中に符号化部２０２がキーフレームを生成した場合の、本実施形態によるキーフレーム生成依頼処理の様子を表している。ＲＴＣＰ ＰＬＡＹ要求８０８に対応するキーフレーム依頼８０９は、キーフレーム８１０が生成された時点８１１で無効化される（図６のＳ６０５）。従って、図８（ｂ）の時点８０６のように、ストリーム管理部２０６は符号化部２０２へキーフレーム依頼８０９に起因したキーフレーム生成を依頼することはしない。

以上の説明の通り、本実施形態のストリーム管理部２０６は、図４に示した手順により、短時間の間に到着したクライアントからのストリーム送信開始要求に対し一つのキーフレーム依頼を待機させることで、それらの要求を共有する。また、キーフレーム依頼が待機状態である間にキーフレームが符号化された場合は、図６に示した手順により、その依頼は無効化される。更に、所定の短時間が経過すると、図７に示した手順により待機中のキーフレーム依頼を符号化部２０２へ行う。これにより、本実施形態による送信装置および送信装置の制御方法によれば、短時間の間に複数のクライアントからストリーム開始要求があった場合でも、キーフレームの乱発的生成を防止することができる。

［第２実施形態］
本実施形態では、第１実施形態におけるキーフレーム生成依頼の遅延実行に加え、パケットエラーの発生に応じてキーフレーム依頼の待機時間を短縮する。なお、本実施形態と第１実施形態とは、キーフレーム生成依頼実行の判断、すなわち、第１実施形態における図３のＳ３０５の詳細手順が異なる。従って、以下では本実施形態によるＳ３０５の詳細手順について説明する。

本実施形態によるキーフレーム生成依頼処理（Ｓ３０５）について、図９を参照して説明する。図９は、本実施形態によるキーフレーム生成依頼処理の詳細な処理フローチャートを示す図である。図９のＳ９０１、Ｓ９０２、Ｓ９０６〜Ｓ９０９は、図７のＳ７０１〜Ｓ７０６と同様の処理を行うため、説明を省略する。ストリーム管理部２０６は、待機状態のキーフレーム依頼がある場合（Ｓ９０２のＹｅｓ）、現在の送信状況を取得し（Ｓ９０３）、クライアント側で再生エラーが発生する程度のパケットエラーが発生しているか否か判定する（Ｓ９０４）。パケットエラーの発生有無は、クライアントから適時受信するＲＴＣＰ受信者応答（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）等から判断できる。

再生エラーが発生する程度のパケットエラーが発生していると判断した場合（Ｓ９０４のＹｅｓ）は、ストリーム管理部２０６は、キーフレーム依頼の待機時間を短縮する（Ｓ９０５）。より早くキーフレームをクライアントへ送信することで正常な再生を回復させるためである。なお、待機時間の短縮とは、待機時間をゼロとすることも含む。具体的には、ストリーム管理部２０６は、図５（ｂ）に示すキーフレーム依頼格納部２０７の登録時間５０６の値を、短縮した待機時間に対応する短縮時間分減算して再設定する。減算することによって、所定の規定時間を経過するまでの時間がより短くなり、ストリーム管理部２０６は、より早く符号化部２０２へキーフレーム生成を依頼できる。これにより、より早くキーフレームが生成されることになる。

このように、本実施形態では、ストリーム管理部２０６は再生エラーが発生する程度のパケットエラーが発生した場合に待機時間を短縮する。これにより、第１実施形態における動作と効果に加えネットワークエラーによる再生不具合のより早い回復を考慮した動作を行うことができる。なお、再生エラーが発生する程度のパケットエラー量の判断方法として、どのような方法を用いても構わない。また、１パケットのエラーのみで即キーフレーム依頼待機時間の短縮を行っても構わない。

［第３実施形態］
本実施形態では、第１実施形態におけるキーフレーム生成依頼の遅延実行に加え、ネットワークの輻輳の発生に応じてキーフレーム依頼の待機時間を延長する。なお、本実施形態と第１実施形態とはキーフレーム生成依頼実行の判断、すなわち第１実施形態における図３のＳ３０５の詳細手順が異なる。従って、以下では本実施形態によるＳ３０５の詳細手順について説明する。

次に、本実施形態によるキーフレーム生成依頼処理（Ｓ３０５）について、図１０を参照して説明する。図１０は、本実施形態によるキーフレーム生成依頼処理の詳細な処理フローチャートを示す図である。図１０のＳ１００１、Ｓ１００２、Ｓ１００６〜Ｓ１００９は、図７のＳ７０１〜Ｓ７０６と同様の処理を行うため、説明を省略する。ストリーム管理部２０６は、待機状態のキーフレーム依頼がある場合（Ｓ１００２のＹｅｓ）、現在の送信状況を取得し（Ｓ１００３）、輻輳が発生しているか否か判定する（Ｓ１００４）。輻輳の発生有無は、クライアントから適時受信するＲＴＣＰ受信者応答（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）等から判断される。

輻輳が発生していると判断した（Ｓ１００４のＹｅｓ）場合は、キーフレーム依頼の待機時間を延長する（Ｓ１００５）。データ量の大きいキーフレームの送信を遅らせることで、輻輳を悪化させないためである。更に、延長した待機時間に応じてキーフレーム依頼格納部２０７の登録時間を再設定する。これに従って、図５（ｂ）に示すキーフレーム依頼格納部２０７の登録時間５０６の値を、延長時間分加算する。加算することによって、所定の規定時間を経過するまでの時間がより長くなり、ストリーム管理部２０６は、より遅く符号化部２０２へキーフレーム生成を依頼できる。これにより、より遅くキーフレームが生成されることになる。

このように、本実施形態では、ストリーム管理部２０６はネットワーク上で輻輳が発生した場合に待機時間を延長する。これにより、第１実施形態における動作と効果に加えネットワークの輻輳と輻輳を悪化させないことを考慮した動作を行うことができる。なお、輻輳の判断方法として、どのような方法を用いても構わない。

以上の実施形態により、複数のクライアントが同時にストリーム送信開始を要求した場合であっても、キーフレームが連続して送信されることと符号化装置へ過度な負荷を与えることを回避することができる。更には、短時間で再生開始が可能なリアルタイム性も確保した動画ストリーム伝送を実現することができる。更に、本実施形態におけるサーバは、通信状況を認識可能であるため、送信ストリームのパケットエラーや通信路の輻輳、過度な数のクライアントからの再生開始要求、といった通信状況に応じてキーフレーム生成依頼実行の遅延時間を柔軟に調整できる。なお、本実施形態において発生させている遅延は、再生要求からキーフレーム生成までの遅延であり、撮像から伝送、再生までの遅延とは無関係であることに注意されたい。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (11)

1. 受信装置に符号化した動画データを送信する送信装置であって、
   キーフレーム依頼を受けて動画データに対してフレーム内符号化を行う符号化手段と、
   前記受信装置から要求を受信し、該要求に対応するキーフレーム依頼を登録する管理手段とを備え、
   前記管理手段は、受信した要求に対応するキーフレーム依頼と、該キーフレーム依頼の登録時から規定時間内に受信した別の要求に対応するキーフレーム依頼とを一つのキーフレーム依頼として、該規定時間が経過した後に前記符号化手段に送ることを特徴とする送信装置。
2. 前記管理手段は、前記規定時間内に前記符号化手段によって前記フレーム内符号化が行われたと判定した場合には、該フレーム内符号化が行われるまでに登録されているキーフレーム依頼を無効化とすることを特徴とする請求項１に記載の送信装置。
3. 前記管理手段は、前記符号化手段を監視することによって、前記判定を行うことを特徴とする請求項２に記載の送信装置。
4. 前記管理手段は、前記符号化手段によって前記フレーム内符号化が行われたデータが送信中であると判定した場合には、前記受信した要求に対応するキーフレーム依頼を登録しないことを特徴とする請求項１乃至３のいずれか１項に記載の送信装置。
5. 前記管理手段は、登録しているキーフレーム依頼がない場合であって、前記符号化手段によって前記フレーム内符号化が行われたデータが送信中でないと判定した場合には、前記受信した要求に対応するキーフレーム依頼を登録することを特徴とする請求項１乃至４のいずれか１項に記載の送信装置。
6. 前記管理手段は、前記受信した要求に対応するキーフレーム依頼の有無と、該キーフレーム依頼の登録時間を登録することを特徴とする請求項１乃至５のいずれか１項に記載の送信装置。
7. 前記管理手段は、前記受信装置において再生エラーが発生していると判定した場合、登録している登録時間の値を、予め決めた短縮時間分減算することを特徴とする請求項６に記載の送信装置。
8. 前記管理手段は、前記受信装置へのネットワークで輻輳が発生していると判定した場合、もしくは、該輻輳が予測されると判定した場合は、登録している登録時間の値を、予め決めた延長時間分加算することを特徴とする請求項６に記載の送信装置。
9. 前記要求は、前記受信装置による動画データの送信開始の要求、もしくは、前記フレーム内符号化した動画データの送信の要求であることを特徴とする請求項１乃至８のいずれか１項に記載の送信装置。
10. 受信装置に符号化した動画データを送信する送信装置の制御方法であって、
    キーフレーム依頼を受けて動画データに対して符号化手段がフレーム内符号化を行う工程と、
    前記受信装置から要求を受信して、管理手段が該要求に対応するキーフレーム依頼を登録する工程とを備え、
    前記管理手段は、受信した要求に対応するキーフレーム依頼と、該キーフレーム依頼の登録時から規定時間内に受信した別の要求に対応するキーフレーム依頼とを一つのキーフレーム依頼として、該規定時間が経過した後に前記符号化手段に送ることを特徴とする送信装置の制御方法。
11. 請求項１０に記載された送信装置の制御方法の各工程をコンピュータに実行させるためのプログラム。

Images