(57)【要約】【課題】  ネットワークの状態によっては、消失した動画像データを再送しても、消失による画質の劣化を低減できない場合があった。また、消失した動画像データを再送すると、通信量が増加してしまうという問題があった。【解決手段】  ＲＴＴ取得部１０６は、ＲＴＰパケットの消失検知に応じて、送信装置がデータを送信してから受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する（Ｓ２０２）。そして、ＱｏＳ切替部１０７は、取得された時間情報に応じて、送信装置が送信したにもかかわらず受信装置が受信しなかった消失動画像データを再送するか、或いは、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化して送信するかを決定する（Ｓ２０３）。【選択図】  図３
2010074366.tif 000002
【特許請求の範囲】
【請求項１】
動画像データを受信装置へ送信する送信装置であって、
前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、
前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手段と
を有することを特徴とする送信装置。
【請求項２】
動画像データを送信する送信装置から動画像データを受信する受信装置であって、
前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、
前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手段と
を有することを特徴とする受信装置。
【請求項３】
前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する第１の処理時間、及び、前記受信装置が消失動画像データを検知してから前記消失情報を送信するまでに要する第２の処理時間を取得し、
前記時間情報は、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間と、前記受信装置から前記消失情報が送信されてから当該消失情報を受信するまでに要する時間との合計時間に応じた往復時間、及び、前記第１及び第２の処理時間の合計であり、
前記決定手段は、前記時間情報が示す時間が、前記受信装置による前記消失動画像データの検知時刻と前記消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
ことを特徴とする請求項１記載の送信装置。
【請求項４】
前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する処理時間を取得し、
前記時間情報は、前記受信装置がデータを送信してから前記送信装置が前記データを受信するまでに要する時間、及び前記処理時間の合計であり、
前記決定手段は、前記時間情報が示す時間が、前記消失情報の受信時刻と消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
ことを特徴とする請求項１記載の送信装置。
【請求項５】
前記消失動画像データが発生したことを示す消失情報を受信する受信手段を有し、
前記取得手段は、前記送信装置が前記消失情報を受信してから前記消失動画像データを再送するまでに要する処理時間を取得し、
前記時間情報は、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間と、前記受信装置から消失情報が送信されてから当該消失情報を受信するまでに要する時間との合計時間に応じた往復時間、及び、前記処理時間の合計であり、
前記決定手段は、前記時間情報が示す時間が、前記受信装置による前記消失情報の送信時刻と前記消失動画像データの復号時刻との時間差に応じた時間よりも短い場合、前記消失動画像データを再送すると決定する
ことを特徴とする請求項１記載の送信装置。
【請求項６】
送信順序が連続する複数の動画像データが消失動画像データとなった場合、
前記決定手段は、前記複数の消失動画像データのうち、第１の消失動画像データを再送すると決定した場合、前記第１の送信順序よりもあとの第２の前記消失動画像データを再送すると決定する
ことを特徴とする請求項１記載の送信装置。
【請求項７】
送信順序が連続する複数の動画像データが消失動画像データとなった場合、
前記決定手段は、前記複数の消失動画像データのうち、第１の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定した場合、
前記第１の消失動画像データよりも前の第２の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定することを特徴とする請求項１記載の送信装置。
【請求項８】
送信順序が連続する複数の動画像データが消失動画像データとなった場合、
前記決定手段は、前記複数の消失動画像データのうち、再送すると決定した消失動画像データを、再送しない消失動画像データを参照せずに符号化して送信すると決定する
ことを特徴とする請求項１記載の送信装置。
【請求項９】
動画像データを受信装置へ送信する送信装置が行う通信方法であって、
前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得工程と、
前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定工程と
を有することを特徴とする送信方法。
【請求項１０】
動画像データを受信装置へ送信するコンピュータに、
前記コンピュータがデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得手順と、
前記時間情報に応じて、前記コンピュータが送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手順と
を実行させることを特徴とするプログラム。
【請求項１１】
動画像データを送信する送信装置から動画像データを受信する受信装置が行う通信方法であって、
前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応する時間情報を取得する取得工程と、
前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定工程と
を有することを特徴とする通信方法。
【請求項１２】
動画像データを送信する送信装置から動画像データを受信するコンピュータに、
前記送信装置がデータを送信してから前記コンピュータが前記データを受信するまでに要する時間に対応する時間情報を取得する取得手順と、
前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記コンピュータが受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手順と
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は動画像データを送受信するための方法に関する。
【背景技術】
【０００２】
近年、通信環境並びにデータ処理環境の性能向上を背景として、動画像や音声といったマルチメディアデータを、ネットワークを介してリアルタイムに配信するストリーミング技術が実用化されている。このようなストリーミング技術が実用化されたことにより、ユーザはライブメディアまたは記録済みメディアのブロードバンド放送を視聴したり、記録済みメディアをオンデマンド（ｏｎ  ｄｅｍａｎｄ）で視聴したりすることができる。
【０００３】
そこで、音声や動画のリアルタイム配信やテレビ電話など、通信の遅延や停止が許されないサービスにとって、通信速度や遅延時間、ジッター量、パケット消失率などを保証するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）技術が重要な技術となっている。
【０００４】
例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）では、相手にデータが届かなかったことを検知し、届かなかったデータを相手に再送する再送制御機能が提供されている。
【０００５】
また例えば、イントラリフレッシュによりエラー伝播を防止する機能も提案されている（例えば特許文献１）。特許文献１には、動画通信中にパケットが消失した場合、受信側からのリフレッシュ要求に応答して、送信側装置が直ちにフレーム内符号化した動画像データを送信するようにしている。このようにすることにより、パケットが消失しても、正常な画像出力状態に迅速に復帰することができる。
【特許文献１】特開平０６−２３７４５１
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、ネットワークの状態によっては、消失した動画像データを再送しても、消失による画質の劣化を低減できない場合があった。また、消失した動画像データを再送すると、通信量が増加してしまうという問題があった。
【０００７】
即ち、例えば、通信系路上で消失した動画像データを再送しても、ネットワーク上で通信量が増加していると、再送された動画像データが再生（復号時刻）に間に合わない場合がある。また、この場合、再生に用いられない動画像データが再送されることになり、余計な通信量の増加を生じさせてしまう。
【０００８】
また、例えば通信経路上で動画像データが消失したことに応じてイントラリフレッシュを行うようにすればエラーの伝播を防ぐことはできるが、消失箇所に対応する再生画像は劣化してしまう。本発明は以上の問題に鑑みてなされたものであり、その目的は、通信帯域を効率的に利用すると共に、通信される動画像データの消失による再生画像の劣化を低減することである。
【課題を解決するための手段】
【０００９】
上記の問題点を解決するため、本発明の送信装置は、例えば以下のような構成を有する。
【００１０】
即ち、動画像データを受信装置へ送信する送信装置であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定手段とを有する。
【００１１】
また、本発明の受信装置は、動画像データを送信する送信装置から動画像データを受信する受信装置であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得手段と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定手段とを有する。
【００１２】
また、本発明の通信方法は、動画像データを受信装置へ送信する送信装置が行う通信方法であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得工程と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データを再送するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化して送信するかを決定する決定工程とを有する。
【００１３】
また、本発明の通信方法は、動画像データを送信する送信装置から動画像データを受信する受信装置が行う通信方法であって、前記送信装置がデータを送信してから前記受信装置が前記データを受信するまでに要する時間に対応した時間情報を取得する取得工程と、前記時間情報に応じて、前記送信装置が送信したにもかかわらず前記受信装置が受信しなかった消失動画像データの再送を要求するか、或いは、前記消失動画像データよりも再生時刻が後の動画像データを、前記消失動画像データを参照せずに符号化する要求をするかを決定する決定工程とを有する。
【発明の効果】
【００１４】
本発明によれば、通信帯域を効率的に利用することができると共に、通信される動画像データの消失による再生動画像の画質劣化を低減することができる。
【発明を実施するための最良の形態】
【００１５】
＜実施形態１＞
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１６】
図１は、本発明の実施形態に係る送信装置の機能構成例を示すブロック図である。
【００１７】
図１に示すように、本実施形態に係る送信装置１００は、動画像符号化部１０２、パケット生成部１０３、送受信データバッファ１０４、ＡＩＲ制御部１０５、ＲＴＴ取得部１０６、ＱｏＳ切替部１０７を備える。また、送信装置１００は、通信制御部１０８、再送制御部１０９、通信インターフェース１１０を備える。なお、送受信データバッファ１０４には、図示しない記憶手段によって、受信装置との間で送受信するデータが記憶される。送信装置１００は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを受信装置へ順次送信する送信装置である。また、送信装置１００は、映像を入力する映像入力装置１０１、及び伝送路１１１に接続される。
【００１８】
映像入力装置１０１は、ビデオカメラやＷｅｂカメラなどの映像を入力するための装置である。ただし、映像入力装置１０１が送信装置１００と一体となっていても良い。
【００１９】
つまり、送信装置１００は、パーソナルコンピュータ、ワークステーション、ノートブックＰＣ、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどの機器、或いはこれらの組み合わせにより実現可能である。
【００２０】
伝送路１１１は各種ネットワークに代表される伝送路であり、本実施形態においては、動画像データを始めとする各種パケットを通信するためのネットワークである。
【００２１】
送受信されるデータは送受信データバッファ１０４において一時的に記憶され、動画像データを送信するための通信経路やプロトコルは、通信制御部１０８において制御される。
【００２２】
動画像符号化部１０２は、上述の映像入力装置１０１から入力された動画像データをＭＰＥＧ−４方式により圧縮符号化する。動画像符号化部１０２は、圧縮符号化した動画像データを、フレーム単位でパケット生成部１０３へ入力する。
【００２３】
パケット生成部１０３は、動画像符号化部１０２から入力された動画像データをパケット化し、送受信データバッファ１０４へ記憶させる。本実施形態では、動画像データの符号化方式としてＭＰＥＧ−４  Ｖｉｄｅｏを用い、符号化動画像データ転送プロトコルとしてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）を用いる。従って、パケット生成部１０３は、符号化動画像データのＲＴＰペイロードフォーマットを規定しているＲＦＣ３５５０に従って符号化動画像データをパケット化するものとする。
【００２４】
通信制御部１０８は、送受信データバッファ１０４に記憶されたＲＴＰパケット（動画像データ）を、通信インターフェース１１０を介して所定の宛先（受信装置）へ向けて送信する。
【００２５】
ＡＩＲ制御部１０５は、後述するＱｏＳ切替部１０７からの指示に応じて、ＡＩＲ（Ａｄａｐｔｉｖｅ  Ｉｎｔｒａ  Ｒｅｆｒｅｓｈ）の制御を行う。ここで、イントラリフレッシュとは、通信経路上で消失したＲＴＰパケット（消失動画像データ）を参照しないように、強制的にフレーム内符号化（イントラ符号化）を行う処理である。そして、ＡＩＲは、消失したＲＴＰパケットを参照して符号化される動画像データのうち、動領域の動画像データを強制的にイントラ符号化にする方式である。ＡＩＲにおいて、静止領域のＲＴＰパケットを消失した場合、例えば、消失したＲＴＰパケットに対応するフレームよりも前のフレームのデータを参照させるようにすることができる。一般に、フレーム内符号化をすると、フレーム間符号化よりも符号化後のデータ量が大きくなるため、ＡＩＲによって、すべての領域を強制的にフレーム内符号化にするよりも、送信する動画像データのデータ量を低くすることができる。ただし、イントラリフレッシュにより、消失したＲＴＰパケットを参照して符号化されるすべての領域をフレーム内符号化するようにしても良い。また、エラー情報とは、送信装置１００が受信装置に対して送信したにも関わらず、受信装置が受信しなかったＲＴＰパケット（消失動画像データ）を通知するための情報（消失情報）である。このエラー情報として、例えばＲＴＣＰの受信者レポート（Ｒｅｃｅｉｖｅｒ  Ｒｅｐｏｒｔ、以下単にＲＲと称す）を使用した再送要求を用いることができる。即ち、ＡＩＲ制御部１０５は、消失したＲＴＰパケットよりも後に再生されるＲＴＰパケットを、消失したＲＴＰパケットのデータを参照せずに符号化するための制御を行う。
【００２６】
ＲＴＴ取得部１０６は、受信装置からのエラー情報の受信に応じてＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を取得する。本形態において、ＲＴＴは、受信装置における消失動画像データの検知から再送された消失パケットを受信するまでの時間である。つまり、ＲＴＴは、送信装置１００と受信装置間においてパケットが往復する時間（往復時間）に、受信装置による処理時間（受信側処理時間）及び、送信装置１００による処理時間（送信側処理時間）をそれぞれ加算した時間である。受信側処理時間とは、受信装置が消失パケットを検知してからエラー情報を送信するまでに要する時間であり、送信側処理時間とは、送信装置１００がエラー情報を受信してから再送パケットを生成・送信するまでに要する時間（送信側処理時間）を示す。
【００２７】
ＲＴＴ取得部１０６によるＲＴＴの取得処理の詳細は後述する。
【００２８】
ＱｏＳ切替部１０７は、ＲＴＴ取得部１０６によって取得されたＲＴＴに応じて、エラーに対するＱｏＳ技術を切り替える。つまり、ＱｏＳ切替部１０７は、ＲＴＴに応じて、受信装置側で受信されなかったＲＴＰパケット（消失動画像データ）を再送するか、エラーの伝播を防ぐためにＡＩＲ処理を行うかを決定する。そして、ＱｏＳ切替部１０７は、消失したパケットを再送する場合は再送制御部１０９に通知を行い、ＡＩＲ処理を行う場合はＡＩＲ制御部１０５に通知する。ＱｏＳ切替部１０７の処理の詳細は後述する。
【００２９】
再送制御部１０９は、ＱｏＳ切替部１０７からの通知に応じて、消失したＲＴＰパケット（消失動画像データ）の再送処理を行う。再送制御部１０９による再送処理の詳細は後述する。
【００３０】
次に、本実施形態の送信装置１００によるＱｏＳ切替処理の詳細について、図２を用いて説明する。図２は、本実施形態の送信装置１００におけるＱｏＳ制御の切り替え処理手順の一例を示すフローチャートである。尚、送信装置１００は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを受信装置へ順次送信する送信装置である。
【００３１】
まず送信装置１００は、受信装置からエラー情報（消失情報）を受信したか否かを通信制御部１０８において判断する（Ｓ２０１）。エラー情報は、受信装置がパケット消失を検知した場合に、消失したＲＴＰパケットを通知するための情報である。本形態のエラー情報には、消失したＲＴＰパケットのシーケンス番号、消失したＲＴＰパケットを検知した時刻、及び、エラー情報を受信装置が送信した時刻の情報が含まれる。
【００３２】
即ち、通信制御部１０８は、Ｓ２０１において、消失動画像データが発生したことを示す消失情報（エラー情報）を受信する。
【００３３】
本実施形態の受信装置は、受信したＲＴＰパケット（動画像データ）のヘッダ部分に記録されているシーケンス番号からパケット消失の有無を判断する。つまり、受信装置は、受信したＲＴＰパケットのシーケンス番号が連続した値であればパケット消失はないとし、シーケンス番号に抜けがあればパケット消失が発生したものとして、送信装置１００へエラー情報を通知する。尚、本形態の受信装置は、パケットの消失をエラーと判断するが、パケットの重複や順序誤りに関してはエラーとみなさない。つまり、受信装置は、パケットの重複に対しては重複パケットの一方を破棄し、順序誤りに対しては順不同パケットを順序通りに並べ替えるなどの処理を行う。このようにすれば、余計な再送要求による通信量の増加を低減することができる。
【００３４】
Ｓ２０１で、エラー情報（消失情報）を受信していないと判断されると、受信するまでＳ２０１の処理を繰り返す。一方、Ｓ２０１で、エラー情報を受信したと判断された場合は、Ｓ２０２に進む。
【００３５】
Ｓ２０２（取得手順）において、ＲＴＴ取得部１０６は、送信装置１００と受信装置間のＲＴＴを取得する（Ｓ２０２）。上述のように、本形態のＲＴＴは、受信装置がＲＴＰパケットの消失（消失動画像データ）を検知してから再送されたＲＴＰパケットが到着するまでに要する時間を示している。つまり、ＲＴＴには、ネットワーク上をパケットが往復する時間（往復時間）に、送信装置１００による処理の時間（送信側処理時間）及び、受信装置による処理の時間（受信側処理時間）を加算した時間の情報である。本実施形態において、ＲＴＴ取得部１０６は、エラー情報を受信してから、当該エラー情報を解析し、再送パケットを生成・送信するまでに要する時間（送信側処理時間）の情報を予め保持している。また、エラー情報には、受信装置がエラー情報を送信した時刻の情報、及び、受信装置が消失したＲＴＰパケットを検知した時刻の情報が含まれている。そして、ＲＴＴ取得部１０６は、エラー情報の取得に応じて現在の時刻を取得することで、受信装置がエラー情報を送信してから送信装置が受信するまでにかかった時間（上り片道時間）を算出する。また、ＲＴＴ取得部１０６は、受信装置がＲＴＰパケットの消失を検知してから送信装置に対してエラー情報を送信するまでに要する時間（受信側処理時間）の情報を取得する。
【００３６】
即ち、ＲＴＴ取得部１０６は、Ｓ２０２において、送信装置１００が消失情報（エラー情報）を受信してから消失動画像データを再送するまでに要する第１の処理時間（送信側処理時間）を取得する。また、ＲＴＴ取得部１０６は、受信装置が消失動画像データを検知してから消失情報（エラー情報）を送信するまでに要する第２の処理時間（受信側処理時間）を取得する。
【００３７】
また、本形態のＲＴＴ取得部１０６は、エラー情報に含まれている、送信装置１００がＲＴＰパケットを送信してから当該ＲＴＰパケットを受信するまでにかかった時間（下り片道時間）を取得する。
【００３８】
そして、上り片道時間と下り片道時間を合計することによって、送信装置と受信装置間の往復時間を算出する。このようにすることで、例えば、送信装置から受信装置への回線速度と受信装置から送信装置への回線速度が異なる場合であっても、より精度良く往復時間を算出することができる。ただし、例えば算出された上り片道時間を２倍することによって往復時間を得るようにしても良い。ＲＴＴ取得部１０６は、このようにして算出した往復時間に、予め持っている送信側処理時間、及び、エラー情報に含まれていた受信側処理時間を加えることで、本形態のＲＴＴを取得する。
【００３９】
即ち、ＲＴＴ取得部１０６は、Ｓ２０２において、送信装置１００がデータを送信してから受信装置が当該データを受信するまでに要する時間（下り片道時間）に対応した第１の時間情報（ＲＴＴ）を取得する。ＲＴＴ取得部１０６がＲＴＴを取得するとＳ２０３に進む。
【００４０】
Ｓ２０３（決定手順）において、ＱｏＳ切替部１０７は、Ｓ２０２において取得されたＲＴＴと、許容時間とを比較する。
【００４１】
ここで、本形態における許容時間は、上述のＲＴＰパケットの消失を検知した時刻と消失したＲＴＰパケットの復号開始時刻との時間差を示す。この許容時間は、ＲＴＰパケットの消失を検知した時点における受信装置の送受信データバッファに蓄えられている動画像データの量に応じた時間情報である。つまり、ＲＴＰパケットの消失を検知した時点において、送受信データバッファに多くのＲＴＰパケット（動画像データ）が蓄えられていれば、その分、許容時間は長くなる。
【００４２】
通常、受信装置は、ネットワーク上のパケット到着時間のゆらぎ（ジッタ）を吸収するために受信データバッファを有しており、受信データバッファ容量の制御により動画像を滑らかに復号、再生する。
【００４３】
本形態において、受信装置は、送信装置１００に対して送信するエラー情報に、ＲＴＰパケットの消失の検知時において蓄えられているＲＴＰパケット（動画像データ）のデータ量に応じた許容時間の情報を含めている。送信装置１００のＱｏＳ切替部１０７は、エラー情報に含まれる許容時間の情報を取得する。
【００４４】
ＲＴＴが許容時間よりも短い場合は、消失したＲＴＰパケット（消失動画像データ）を再送すれば、受信装置で再生することができる。一方、ＲＴＴが許容時間を超える場合、消失したＲＴＰパケットを再送しても、受信装置の再生に間に合わないため、再送データを再生できない。また、再生に用いることができないＲＴＰパケットの再送が行われるため、無駄な通信量の増加が発生してしまう。そこで、本形態の送信装置１００は、ＲＴＴが許容時間よりも短い場合は、消失したＲＴＰパケットの再送を行う。そして、ＲＴＴが許容時間よりも長い場合は再送を行わず、ＲＴＰパケットの消失によるエラーが、そのＲＴＰパケットよりも後に再生されるＲＴＰパケットに伝播することを防ぐためにＡＩＲ処理を行う。
【００４５】
ＱｏＳ切替部１０７は、Ｓ２０３で、ＲＴＴが許容時間以内であると判断した場合、再送制御部１０９に対して消失したＲＴＰパケットの再送指示を行う（Ｓ２０４）。つまり、ＱｏＳ切替部１０７は、再送パケットが受信装置における動画像データの復号（再生）に間に合う場合、再送制御部１０９へ消失したＲＴＰパケットを再送するように指示を出す。そして、再送指示を受けた再送制御部１０９は、Ｓ２０４において、送受信データバッファ１０４に記録されている消失したＲＴＰパケットを読み出し、受信装置へ再送する。
【００４６】
即ち、ＱｏＳ切替部１０７は、Ｓ２０３において、時間情報が示す時間（ＲＴＴ）が、受信装置による消失動画像データの検知時刻と消失動画像データの復号時刻との時間差に応じた時間（許容時間）よりも短い場合、消失動画像データを再送すると決定する。
【００４７】
一方、ＱｏＳ切替部１０７は、Ｓ２０３で、ＲＴＴが許容時間よりも大きいと判断した場合、ＡＩＲ制御部１０５に対してＡＩＲ処理を行うための指示を行う。つまり、ＱｏＳ切替部１０７は、再送パケットが受信装置における動画像データの再生（復号）に間に合わない場合、ＡＩＲの処理を行うためにＡＩＲ制御部を制御する。上述のように、ＡＩＲの処理は、ＲＴＰパケットの消失によるエラー伝播を防止するために、消失したＲＴＰパケット（消失動画像データ）を参照せずにフレーム内符号化する処理である。
【００４８】
通常、トラフィックの集中などによりネットワークが輻輳状態になると、それに従って送信装置１００と受信装置間においてパケットが往復する時間（往復時間）が長くなり、ＲＴＴも長くなる。従って、本形態のＱｏＳ切替部１０７は、輻輳状態になると主たるＱｏＳ制御機能を再送制御からＡＩＲ制御へと切り替える。ＡＩＲ処理の指示を受けたＡＩＲ制御部１０５は、フレーム内符号化する領域を特定し、特定した領域の情報を動画像符号化部１０２へ通知する（Ｓ２０５）。
【００４９】
ＡＩＲ制御部１０５は、フレーム内符号化する領域を、受信装置から受信したエラー情報に従って適切に判断することが可能である。つまり、ＡＩＲ制御部１０５は、消失したＲＴＰパケットの領域をフレーム間予測符号化により参照しないよう、動画像フレームの所定の分割領域（例えばマクロブロックやビデオパケット）単位で判断する。
【００５０】
動画像符号化部１０２は、ＡＩＲ制御部１０５から通知された所定の領域をフレーム内符号化することによりエラー伝播を防止する（Ｓ２０６）。このように、再送したＲＴＰパケットが受信装置における再生（復号）に間に合わない場合には、消失したＲＴＰパケットを再送しない。このようにすることにより、余計な再送による通信量の増加を低減することができる。また、再送パケットを受信装置が削除する処理負荷を低減することができる。
【００５１】
即ち、ＱｏＳ切替部１０７は、Ｓ２０３において、時間情報（ＲＴＴ）に応じて、送信装置１００が送信したにもかかわらず受信装置が受信しなかった消失動画像データを再送するか、或いは、ＡＩＲ処理を行うか決定する。ＡＩＲ処理は、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化する処理である。
【００５２】
次に、本実施形態のシステム全体の処理について、図３を用いて説明する。
【００５３】
図３は、本実施形態の送信装置と受信装置を含むシステム全体におけるＱｏＳ制御のシーケンスを示す図である。
【００５４】
送信装置１００と受信装置３０２は、ネットワーク３０１を介して相互に接続されており、送信装置１００は、動画像データのＲＴＰパケット（３０３〜３０６）を順次受信装置３０２へ送信する。
【００５５】
ネットワーク３０１上のエラーによりＲＴＰパケット３０５が消失すると、受信装置３０２はＲＴＰパケット３０３、３０４、３０６を受信すると共に、ＲＴＰパケットヘッダ中のシーケンス番号の不連続性によりＲＴＰパケット３０５の消失を検出する。受信装置３０２は、ＲＴＰパケット３０５の再送を要求するため、送信装置１００に対してエラー情報（ＲＲ３０７）を送信する。
【００５６】
送信装置１００は、受信装置３０２からのＲＲ３０７を受信すると上述のＲＴＴを取得する。このとき、ＲＴＴ取得段階においてネットワーク３０１は混雑していなかったため、ＲＴＴが許容時間以下であったとする。すなわち、受信装置３０２における動画像の再生（復号）に、再送されるＲＴＰパケット３０５が間に合うと判断されるものとする。この場合、送信装置１００は受信装置３０２へ消失したＲＴＰパケット３０５を再送し、エラー伝播防止のためのＡＩＲ制御を行わない。従って、再送されたＲＴＰパケット３０５を受信した受信装置３０２は、正常に動画像データを復号、再生することができる。
【００５７】
続いて、送信装置１００は、動画像データのＲＴＰパケット（３０８〜３１１）を順次受信装置３０２へ送信する。
【００５８】
ここで、ネットワーク３０１上のエラーによりＲＴＰパケット３１０が消失すると、受信装置３０２はＲＴＰパケット３０８、３０９、３１１を受信すると共に、ＲＴＰパケットヘッダ中のシーケンス番号の不連続性によりＲＴＰパケット３１０の消失を検知する。受信装置３０２は、ＲＴＰパケット３１０の再送を要求するため、送信装置１００に対してエラー情報（ＲＲ３１２）を送信する。
【００５９】
送信装置１００は、受信装置３０２からのＲＲ３１２を受信するとＲＴＴを取得する。このとき、ＲＴＴ取得段階においてネットワーク３０１は輻輳状態にあり、ＲＴＴが許容時間よりも長かったとする。すなわち、受信装置３０２における動画像の再生（復号）に、再送されるＲＴＰパケット３１０が間に合わないと判断されるものとする。この場合、送信装置１００は、受信装置３０２へ消失したＲＴＰパケット３１０を再送せず、エラー伝播防止のためにＡＩＲ制御を行う。従って、受信装置３０２は、ＲＴＰパケット３１０の消失による動画像データの復号エラーの時間的な伝播を防止することができる。
【００６０】
尚、図３の説明では、ＲＴＰパケットが１つ消失する場合について説明したが、通信制御部４０５は、送信順序が連続する複数のＲＴＰパケットの消失を検知することもできる。受信装置は、ＲＴＰパケットが連続して消失したことを検知すると、その時刻を取得すると共に、消失した各ＲＴＰパケットの復号時刻を取得する。上述のように、消失したＲＴＰパケットの復号時刻は、受信装置の送受信データバッファに蓄えられているＲＴＰパケットのデータ量に応じて決まる。そして、ＲＴＰパケットの消失を検知した時刻、各ＲＴＰパケットの復号時刻、受信側処理時間、及び、ＲＴＰパケットの消失検知時における送信装置から受信装置に対する片道時間（下り片道時間）を含むエラー情報を送信装置に対して送信する。エラー情報を受信した送信装置１００のＲＴＴ取得部１０６は、エラー情報の送信時刻と受信時刻から上り片道時間を取得し、それに下り片道時間を加算することで往復時間を取得する。ＲＴＴ取得部１０６は、往復時間に送信側処理時間と受信側処理時間を加算することで、ＲＴＴを取得する。また、ＱｏＳ切替部１０７は、ＲＴＴ取得部１０６によって取得されたＲＴＴと許容時間とを比較することで、消失した各ＲＴＰパケットを再送するか、ＡＩＲの処理を行うかを決定する。ここで、復号時刻がそれぞれ異なる消失ＲＴＰパケットの許容時間は、それぞれ異なる。
【００６１】
本形態のＱｏＳ切替部１０７は、送信順序が連続する複数の消失ＲＴＰパケットのうち、送信順序が前の消失ＲＴＰパケットから順に、再送するかＡＩＲ処理を行うかを決定する。そして、ＱｏＳ切替部１０７は、送信順序が連続する消失ＲＴＰパケットのうち、ある送信順序の消失ＲＴＰパケットを再送すると決めた場合、それよりも後の消失ＲＴＰパケットも再送すると決定する。即ち、ＱｏＳ切替部１０７は、複数の消失動画像データのうち、第１の消失動画像データを再送すると決定した場合、第１の消失動画像データよりも後の第２の消失動画像データを再送すると決定する。つまり、送信順序が前のＲＴＰパケットは、それよりも後のＲＴＰパケットよりも復号（再生）時刻が早い。従って、ある再送されたＲＴＰパケットが受信装置における復号（再生）に間に合う場合、それよりも後の送信順序のＲＴＰパケットを再送しても、その再送パケットが復号（再生）に間に合う。
【００６２】
つまり、例えば、連続して９つのＲＴＰパケットが消失した場合に、そのうち最も送信順序が前である消失ＲＴＰパケットの再送が間に合うと判断される場合、他の８つの消失ＲＴＰパケットの再送も間に合うと判断することができる。このようにすることで、より送信装置の処理を軽くすることができる。
【００６３】
また、ＱｏＳ切替部１０７は、送信順序が連続する複数の消失ＲＴＰパケットのうち、送信順序が後ろの消失ＲＴＰパケットから順に、再送するかＡＩＲ処理を行うか決定するようにしても良い。このとき、ある送信順序の消失ＲＴＰパケットを、再送せずにＡＩＲ処理を行うと決めた場合、それよりも前の消失ＲＴＰパケットも、再送せずにＡＩＲ処理を行うと決定する。即ち、ＱｏＳ切替部１０７は、複数の動画像データのうち、第１の消失動画像データを参照せずに未送信の動画像データを符号化して送信すると決定した場合、以下のように他の消失動画像データに対する処理を決定する。すなわち、第１の消失動画像データよりも前の第２の消失動画像データを参照せずに、未送信の動画像データを符号化して送信すると決定する。
【００６４】
つまり、送信順序が後のＲＴＰパケットは、それよりも前のＲＴＰパケットよりも復号（再生）時刻が遅い。従って、ある再送されたＲＴＰパケットが受信装置における復号（再生）に間に合わない場合、それよりも前の送信順序のＲＴＰパケットを再送しても、その再送パケットは復号（再生）に間に合わない。
【００６５】
つまり、例えば、連続して９つのＲＴＰパケットが消失した場合、そのうち最も送信順序が後ろである消失ＲＴＰパケットを再送しても、復号時刻に間に合わないと判断される場合、他の８つの消失ＲＴＰパケットを再送しても間に合わないと判断することができる。このようにすることで、より送信装置の処理を軽くすることができる。
【００６６】
また、送信順序が連続する複数のＲＴＰパケットが消失したことが検知された場合、どの送信順序の消失ＲＴＰパケットから、再送するかＡＩＲを行うかを決定するかを、受信装置からのエラー情報に含まれる送受信データバッファのデータ量に応じて判断しても良い。
【００６７】
また、本実施形態のＱｏＳ切替部１０７は、送信順序が連続する複数のＲＴＰパケットが消失し、そのうちの一部の消失ＲＴＰパケットに対して再送を行い、残りの消失ＲＴＰパケットに対しては、ＡＩＲ処理を行うと決定した場合、以下のような処理を行う。すなわち、再送する消失ＲＴＰパケットが再送しない消失ＲＴＰパケットを参照せずに符号化されるように、再送するＲＴＰパケットの動画像データを再符号化する。
【００６８】
即ち、ＱｏＳ切替部１０７は、複数の消失動画像データのうち、再送すると決定した消失動画像データを、再送しない消失動画像データを参照せずに符号化して送信すると決定する。
【００６９】
つまり、例えば、送信順序が連続する９つのＲＴＰパケットが消失した場合、ＱｏＳ切替部１０７は、送信順序が後ろの４つの消失ＲＴＰパケットを再送し、それ以外の５つの消失ＲＴＰパケットは再送せず、ＡＩＲ処理を行うと決定したとする。この場合、再送されたＲＴＰパケットの中には、再送しない５つのＲＴＰパケットのデータを参照しているものがある可能性があるため、再送パケットが正常に受信、復号されたとしても、再生画像が劣化する場合がある。そこで、本形態のＱｏＳ切替部１０７は、再送するＲＴＰパケットが、再送しない消失ＲＴＰパケットのデータを参照せずに符号化されるように、再送するＲＴＰパケットに対応する動画像データを再符号化すると決定する。このようにすることで、よりＲＴＰパケットの消失による再生画像の劣化をより低減することができる。ただし、再送するＲＴＰパケットに対してＡＩＲ処理の処理を行わないようにしても良い。
【００７０】
以上説明した通り、本実施形態の送信装置１００は、受信装置からＲＴＰパケットが消失したことを示すエラー情報（消失情報）が通知されると、消失したＲＴＰパケットを再送するかＡＩＲ処理を適用するかを切り替える。ここで、送信装置１００は、再送とＡＩＲ処理の切り替えを、エラー情報の受信時におけるネットワークの状況や受信装置が蓄えている動画像データのデータ量に応じて行う。つまり、再送したパケットが受信装置における動画像の再生（復号）に間に合う場合は再送処理を行い、間に合わない場合は再送を行わず、ＡＩＲ処理を行う。
【００７１】
このようにすることにより、復号に間に合わない（再生に用いない）ＲＴＰパケットの再送を防ぐことができるため、無駄な通信量の増加を低減することができるため、動画像品質を維持しながら通信帯域を効率的に利用することができる。
【００７２】
また、これにより、受信装置側で復号に間に合わなかった再送パケットを削除する処理を低減することができる。また、消失したＲＴＰパケットを再送した場合は、ＡＩＲの処理を行わないようにすることにより、送信装置におけるＡＩＲの処理を削減することができる。また、ＲＴＴと許容時間との比較に応じたＱｏＳの切り替えを送信装置が行うことにより、受信装置が持っている機能によらず、上記の効果を得ることができる。
【００７３】
尚、上記の実施形態では、ＲＴＴが、ＲＴＰパケットの消失を検知してから再送されたＲＴＰパケットの受信するまでの時間である場合の例について説明した。また、上記の実施形態では、許容時間が、ＲＴＰパケットの消失を検知してから、当該ＲＴＰパケットの復号時刻までの時間である場合の例について説明した。しかし、ＲＴＴと許容時間の例は上記の例に限らず、他に様々な形態を用いることができる。
【００７４】
例えば、ＲＴＴとして、下り片道時間と送信側処理時間の合計時間を用いるようにしても良い。この場合、許容時間として、送信装置１００におけるエラー情報の受信時刻と、当該エラー情報に対応する、消失したＲＴＰパケット（消失動画像データ）の受信装置における復号時刻との時間差を用いる。
【００７５】
つまり、受信装置は、送信するエラー情報に、消失したＲＴＰパケットのシーケンス番号、下り片道時間の他に、消失したＲＴＰパケットの復号時刻の情報を含める。下り片道時間は、送信装置がデータを送信してから受信装置が受信するまでに要する時間を示しており、受信装置は、例えば以下のように下り片道時間を取得することができる。すなわち、ＲＴＰパケットの消失を検知したときに受信したＲＴＰパケットの送信装置１００における送信時刻と受信装置における受信時刻から下り片道時間を取得することができる。また、復号時刻の情報は、受信装置における送受信データバッファに蓄積されている動画像データのデータ量に応じて決まる。
【００７６】
エラー情報を受信した送信装置１００のＲＴＴ取得部１０６は、下り片道時間に送信側処理時間を加算した時間をＲＴＴとして取得する。送信側処理時間は、送信装置１００が予め記憶している。
【００７７】
即ち、通信制御部１０８が、消失動画像データが発生したことを示す消失情報（エラー情報）を受信すると、ＲＴＴ取得部１０６は、送信側処理時間を取得する。上述のように、送信側処理時間は、送信装置１００が消失情報（エラー情報）を受信してから消失動画像データを再送するまでに要する処理時間である。そして、ＲＴＴ取得部１０６は、送信装置１００がデータを送信してから受信装置が当該データを受信するまでに要する時間（下り片道時間）、及び送信側処理時間の合計を時間情報（ＲＴＴ）として取得する。
【００７８】
また、ＱｏＳ切替部１０７は、許容時間（エラー情報の受信時刻と消失ＲＴＰパケットの復号時刻との時間差）を取得する。そして、ＱｏＳ切替部１０７は、ＲＴＴ（下り片道時間と送信側処理時間の合計）が許容時間よりも短い場合、再送すると決定する。一方、ＲＴＴが許容時間よりも長い場合、再送処理を行わず、ＡＩＲ処理を行うと決定する。
【００７９】
このようにしても、エラー発生時におけるネットワークの状況に応じて再送処理とＡＩＲ処理を切り替えることができ、上述の本発明の効果を得ることができる。
【００８０】
また、ＲＴＴのほかの例として、例えば、往復時間と送信側処理時間としても良い。この場合、許容時間として、受信装置におけるエラー情報の送信から、当該エラー情報に対応する、消失したＲＴＰパケットの復号時刻との時間差を用いる。
【００８１】
つまり、受信装置は、送信するエラー情報に、消失したＲＴＰパケットのシーケンス番号、エラー情報を送信した時刻の情報、下り片道時間、消失したＲＴＰパケットの復号時刻の情報のほかに、消失したＲＴＰパケットを検知した時刻の情報を含める。
【００８２】
エラー情報を受信した送信装置１００のＲＴＴ取得部１０６は、エラー情報の受信時刻と、エラー情報の送信時刻とに基づいて算出される上り片道時間とエラー情報に含まれている下り片道時間とを合計することで往復時間を得る。そして、ＲＴＴ取得部１０６は、得られた往復時間に送信側処理時間を加算した時間をＲＴＴとして取得する。また、ＲＴＴ取得部１０６は、許容時間（エラー情報の送信時刻と消失したＲＴＰパケットの復号時刻の時間差）を取得する。そして、ＱｏＳ切替部１０７は、ＲＴＴ（往復時間と送信側処理時間と受信側処理時間の合計時間）が許容時間よりも小さければ、再送処理を行わせる。一方、ＲＴＴが許容時間よりも大きければ、再送処理を行わずに、ＡＩＲ処理を行うようにＡＩＲ制御部１０５に対して指示を行う。
【００８３】
即ち、通信制御部１０８が、消失動画像データが発生したことを示す消失情報（エラー情報）を受信すると、ＲＴＴ取得部１０６は、送信側処理時間を取得する。上述のように、送信側処理時間は、送信装置１００が消失情報（エラー情報）を受信してから消失動画像データを再送するまでに要する処理時間である。
【００８４】
そして、ＲＴＴ取得部１０６は、上り片道時間と下り片道時間との合計時間に応じた往復時間、及び、送信側処理時間の合計を時間情報（ＲＴＴ）として取得する。上述のように、上り片道時間は、受信装置から消失情報（エラー情報）が送信されてから当該消失情報を受信するまでに要する時間であり、下り片道時間は、送信装置１００がデータを送信してから受信装置が当該データを受信するまでに要する時間を示している。
【００８５】
そして、ＱｏＳ切替部１０７は、時間情報が示す時間が、受信装置による消失情報の送信時刻と消失動画像データの復号時刻との時間差に応じた時間（許容時間）よりも短い場合、消失動画像データを再送すると決定する。
【００８６】
このようにしても、エラー発生時におけるネットワークの状況に応じて再送処理とＡＩＲ処理を切り替えることができ、上述の本発明の効果を得ることができる。
【００８７】
＜実施形態２＞
次に本発明の第２の実施形態について、実施形態１との差異を中心に説明する。
【００８８】
前述した第１の実施形態では、再送処理をするかＡＩＲ処理をするかを送信装置が決定する構成とした。これに対して本実施形態では、受信装置が、ＲＴＰパケットの消失検知時におけるネットワークの状態から、再送処理とＡＩＲ処理のどちらが有効かを決定して、送信装置へ指示する。
【００８９】
図４は、本実施形態に係る受信装置の機能構成例を示すブロック図である。
【００９０】
図４に示すように、受信装置４００は、通信インターフェース４０２、送受信データバッファ４０３、ＱｏＳ切替部４０４、通信制御部４０５、ＲＴＴ取得部４０６、動画像復号化部４０７を備えている。なお、送受信データバッファ４０３には、図示しない記憶手段によって、送信装置との間で送受信されるデータが記憶される。受信装置４００は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを順次送信する送信装置から動画像データを受信する受信装置である。また、受信装置４００は、出力機器４０８、及び伝送路４０１に接続される。
【００９１】
出力機器４０８は、映像を出力するための、例えばディスプレイ、蓄積装置、任意のネットワークへの送信装置等である。受信装置４００は、出力機器４０８と一体となっていても良い。
【００９２】
つまり、受信装置４００は、パーソナルコンピュータ、ワークステーション、ノートブックＰＣ、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどの機器、或いはこれらの組み合わせにより実現可能である。
【００９３】
図４において、伝送路４０１は各種ネットワークに代表される伝送路であり、本実施形態においては、ＲＴＰパケット（動画像データ）を始めとする各種パケットを通信するためのネットワークである。送受信されるデータは送受信データバッファ４０３において一時的に記憶され、動画像データを受信するためのプロトコルは、通信制御部４０５において制御される。
【００９４】
動画像復号化部４０７は、送信装置から受信して送受信データバッファに記憶された動画像データをＭＰＥＧ−４方式により復号化する。動画像復号化部４０７において復号化された動画像データは、出力機器４０８の仕様に基づいた単位（一般的にはフレーム単位）で出力機器４０８へ入力される。
【００９５】
通信制御部４０５は、実施形態１と同様に、受信したＲＴＰパケットのヘッダに記憶されているシーケンス番号から、パケット消失の有無を判断する。つまり、ＲＴＰパケットに含まれるシーケンス番号が連続していない場合、抜けているパケットが消失したと判断する。通信制御部４０５は、パケットの消失を検知すると、それをＲＴＴ取得部４０６に通知する。
【００９６】
ＲＴＴ取得部４０６は、パケット消失の通知に応じてＲＴＴを取得する。本形態において、ＲＴＴは、受信装置４００がパケット消失を検知してから再送パケットが到着するまでに要する時間である。つまり、ＲＴＴは、送信装置と受信装置４００間においてパケットが往復する時間（往復時間）に、受信装置４００による処理時間（受信側処理時間）と送信装置による処理時間（送信側処理時間）を加えた時間を示す。ここで、受信側処理時間とは、受信装置４００がパケット消失を検知してからエラー情報を送信するまでに要する時間であり、送信側処理時間とは、送信装置がエラー情報を受信してから再送パケットを生成・送信するまでに要する時間を示している。尚、上述のように、本実施形態では、受信装置４００が、消失したＲＴＰパケットの再送を要求するか、或いは、ＡＩＲ処理の要求をするかを決定する。従って、受信装置４００が送信するエラー情報の内容は、再送要求であるか、ＡＩＲ処理の要求であるかによって異なる。
【００９７】
尚、本実施形態のＲＴＴ取得部４０６は、ＲＴＰパケット（動画像データ）の通信に先立ち、送信側処理時間の情報を予め送信装置から取得しているものとする。また、ＲＴＴ取得部４０６は、ＲＴＰパケットの消失を検知した時刻を取得する。
【００９８】
また、ＲＴＴ取得部４０６は、消失したＲＴＰパケットの後に送信される、正常に受信されたＲＴＰパケットに含まれるパケットの送信時刻の情報により、下り片道時間を取得する。ここで、下り片道時間は、送信装置がデータを送信してから、当該データを受信装置４００が受信するまでに要する時間を示している。また、ＲＴＴ取得部４０６は、ＲＴＰパケットの消失を検知してからエラー情報を送信するまでに必要な時間を受信側処理時間として予め取得している。そして、ＲＴＴ取得部４０６は、下り片道時間を２倍することで得られる往復時間に、予め持っている送信側処理時間、及び受信側処理時間を加えることで、本形態のＲＴＴを取得する。ただし、ＲＴＴ取得部４０６が、例えば定期的に送信装置に対してデータを送信している場合、受信装置から送信装置へのデータの片道時間（上り片道時間）を取得することができる。この場合、往復時間を下り片道時間と上り片道時間の合計とするようにしても良い。このようにすれば、送信装置から受信装置への回線速度と受信装置から送信装置への回線速度が異なる場合であっても、より精度の高い往復時間を取得できる。
【００９９】
ＱｏＳ切替部４０４は、ＲＴＴ取得部４０６によって取得されたＲＴＴと、許容時間との比較結果に応じて、送信装置に対して、消失したＲＴＰパケットの再送要求をするか、ＡＩＲ処理の要求を行うか決定する。ここで、許容時間は、ＲＴＰパケットの消失を検知してから、消失したＲＴＰパケット（消失動画像データ）を復号するまでに要する時間である。ＱｏＳ切替部４０４によるＱｏＳの決定の詳細については後述する。
【０１００】
次に、本実施形態の受信装置４００によるＱｏＳ切替処理について、図５を用いて説明する。
【０１０１】
図５は、本実施形態の受信装置におけるＱｏＳ制御の切り替え処理手順の一例を示すフローチャートである。
【０１０２】
尚、受信装置４００は、フレーム内符号化された動画像データとフレーム間符号化された動画像データとを順次送信する送信装置から動画像データを受信する受信装置である。
【０１０３】
まず受信装置４００の通信制御部４０５は、パケット消失を検知したか否かを判断する（Ｓ５０１）。通信制御部４０５は、第１の実施形態と同様に、受信したＲＴＰパケットのヘッダ部分に記録されているシーケンス番号の連続性からパケット消失を検知する。
【０１０４】
Ｓ５０１で、パケット消失を検知していない場合には、検知するまでＳ５０１の処理を繰り返す。一方、Ｓ５０１で、パケット消失を検知した場合は、Ｓ５０２に進む。
【０１０５】
Ｓ５０２（取得手順）において、ＲＴＴ取得部４０６は、ＲＴＴを取得する。上述のように、本形態におけるＲＴＴは、通信制御部４０５がＲＴＰパケットの消失を検知してから、消失したＲＴＰパケットの復号するまでの時間である。また、消失したＲＴＰパケットの復号時刻は、そのときの送受信データバッファ４０３に蓄えられているＲＴＰパケット（動画像データ）のデータ量に応じて決まる。
【０１０６】
即ち、Ｓ５０２において、ＲＴＴ取得部４０６は、送信装置がデータを送信してから受信装置４００が当該データを受信するまでに要する時間（下り片道時間）に対応した時間情報（ＲＴＴ）を取得する。ＲＴＴ取得部４０６がＲＴＴを取得すると、Ｓ５０３に進む。
【０１０７】
Ｓ５０３（決定手順）において、ＱｏＳ切替部４０４は、消失したパケットの再送が間に合うか否かを判断する。ここでの判断は、Ｓ５０２において取得したＲＴＴが、受信装置４００において復号までに許容される時間（許容時間）以内か否かによって行われる。本形態における許容時間は、ＲＴＰパケットの消失を検知してから、該消失したＲＴＰパケットを復号するまでに要する時間である。つまり、ＱｏＳ切替部４０４は、ＲＴＴが許容時間よりも短ければ再送したパケットが再生（復号）に間に合うと判断し、ＲＴＴが許容時間よりも長いと再送したパケットが再生（復号）に間に合わないと判断する。ＱｏＳ切替部４０４が、再送パケットが再生（復号）に間に合うと判断すると、Ｓ５０４に進む。
【０１０８】
Ｓ５０４において、ＱｏＳ切替部４０４は、消失したＲＴＰパケットの再送要求を送信装置に対して送信する。
【０１０９】
一方、Ｓ５０３で、ＱｏＳ切替部４０４が、再送パケットが再生（復号）に間に合わないと判断するとＳ５０５に進む。そして、Ｓ５０５において、ＱｏＳ切替部４０４は、ＡＩＲ処理の要求を送信装置に対して送信する。
【０１１０】
即ち、ＱｏＳ切替部４０４は、Ｓ５０３で、時間情報（ＲＴＴ）に応じて、送信装置が送信したにもかかわらず受信装置４００が受信しなかった消失動画像データの再送を要求するか、或いは、ＡＩＲ処理を要求するか決定する。上述のように、ＡＩＲ処理は、消失動画像データよりも再生時刻が後の動画像データを、消失動画像データを参照せずに符号化する処理である。
【０１１１】
このように、受信装置４００のＱｏＳ切替部４０４は、ＲＴＴと許容時間との比較により、再送したＲＴＰパケットが再生（復号）に間に合うか否かを判断する。そして、ＱｏＳ切替部４０４は、再送したＲＴＰパケットが再生（復号）に間に合わないと判断した場合、再送要求ではなくＡＩＲ処理の要求を送信装置６０１へ送信する。一方、再送したＲＴＰパケットが再生（復号）に間に合うと判断した場合、ＡＩＲ処理の要求ではなく再送要求を送信装置６０１へ送信する。受信装置４００からの要求を受信した送信装置６０１は、要求の内容にしたがってパケットの再送制御あるいはＡＩＲ処理の制御を行う。
【０１１２】
次に、本実施形態のシステム全体の処理について、図６を用いて説明する。
【０１１３】
図６は、本実施形態の送信装置と受信装置を含むシステム全体におけるＱｏＳ制御のシーケンスを示す図である。
【０１１４】
送信装置６０１と受信装置４００は、ネットワーク６０２を介して相互に接続されており、送信装置は、動画像データのＲＴＰパケット（６０３〜６０６）を順次受信装置４００へ送信する。
【０１１５】
ネットワーク６０２上のエラーによりＲＴＰパケット６０５が消失すると、受信装置４００はＲＴＰパケット６０３、６０４、６０６を受信すると共に、ＲＴＰパケットヘッダ中のシーケンス番号の不連続性によりＲＴＰパケット６０５の消失を検知する。続いて受信装置４００は、ＲＴＰパケット６０５の消失を検知するとＲＴＴを取得する。上述したように、本形態におけるＲＴＴは、ＲＴＰパケット（動画像データ）の消失を検知してから再送されたＲＴＰパケットを受信するまでに要する時間である。つまり、ＲＴＴは、送信装置と受信装置との往復時間に送信側処理時間と受信側処理時間を加算した合計時間を示している。ＲＴＴ取得段階においてネットワーク６０２は混雑しておらず、ＲＴＴが許容時間以下であったとする。尚、本形態における許容時間は、ＲＴＰパケットの消失を検知した時刻から、当該ＲＴＰパケットを復号する時刻までに要する時間である。また、ＲＴＰパケットを復号する時刻は、ＲＴＰパケットの消失を検知した時点において送受信データバッファに蓄えられているＲＴＰパケット（動画像データ）のデータ量によって決まる。
【０１１６】
受信装置４００のＱｏＳ切替部４０４は、再送されたＲＴＰパケット６０５の到着が受信装置４００における復号時刻に間に合うと判断する。この場合、受信装置４００は、ＲＴＰパケット６０５の再送を要求するため、送信装置６０１に対してＲＲ６０７（エラー情報）を送信する。
【０１１７】
送信装置６０１は、受信装置４００からのＲＲ６０７を受信すると、受信装置４００へ消失したＲＴＰパケット６０５を再送し、エラー伝播防止のためのＡＩＲ制御を行わない。ＲＴＰパケット６０５の復号時間までに再送されたＲＴＰパケット６０５を受信した受信装置４００は、正常に動画像データを復号、再生することができる。
【０１１８】
続いて、送信装置６０１は、動画像データのＲＴＰパケット（６０８〜６１１）を順次受信装置４００へ送信する。
【０１１９】
ネットワーク６０２上のエラーによりＲＴＰパケット６１０が消失すると、受信装置４００はＲＴＰパケット６０８、６０９，６１１を受信すると共に、ＲＴＰパケットヘッダ中のシーケンス番号の不連続性によりＲＴＰパケット６１０の消失を検出する。続いて受信装置４００は、ＲＴＰパケット６１０の消失を検知するとＲＴＴを取得する。ＲＴＴ取得段階においてネットワーク６０２は輻輳状態にあり、ＲＴＴが許容時間よりも大きいものであったとする。すなわち、ＱｏＳ切替部４０４は、受信装置４００におけるＲＴＰパケット６１０の復号時刻に、再送されたＲＴＰパケット６１０の到着が間に合わないと判断する。この場合、受信装置４００のＱｏＳ切替部４０４は、ＲＴＰパケット６１０の再送を要求せず、エラー伝播防止のためのＡＩＲ処理を要求するため、送信装置６０１に対してＲＲ６１２（エラー情報）を送信する。
【０１２０】
送信装置６０１は、受信装置４００からのＲＲ６１２を受信すると、受信装置４００へＲＴＰパケット６１０を再送せず、エラー伝播防止のためにＡＩＲ制御を行う。従って、受信装置４００は、ＲＴＰパケット６１０の消失による動画像データの復号エラーの時間的な伝播を低減することができる。
【０１２１】
これにより、パケット消失時に再送するかＡＩＲ処理を行うかを受信装置側で判断して、送信装置へ指示することができる。
【０１２２】
このようにすることにより、復号に間に合わない（再生に用いない）ＲＴＰパケットの再送を防ぐことができるため、無駄な通信量の増加を低減することができ、動画像品質を維持しながら通信帯域を効率的に利用することができる。また、これにより、受信装置側で復号に間に合わなかった再送パケットを削除する処理を低減することができる。また、消失したＲＴＰパケットを再送した場合は、ＡＩＲ処理を行わないようにすることにより、送信装置におけるＡＩＲの処理を削減することができる。また、ＲＴＴと許容時間との比較に応じたＱｏＳの切り替えを受信装置が行うことにより、送信装置が持っている機能によらず、上記の効果を得ることができる。
【０１２３】
尚、本実施形態において、ＲＴＴは、送信装置と受信装置との間におけるデータの往復時間に、送信側処理時間、及び受信側処理時間を加算した合計時間である場合について説明した。また、この場合の許容時間は、ＲＴＰパケットの消失を検知してから、当該消失したＲＴＰパケットの復号時刻までの時間である場合について説明した。しかし、ＲＴＴ、許容時間は、この例に限らない。
【０１２４】
例えば、ＲＴＴとして、往復時間と送信側処理時間の合計時間としても良い。この場合、許容時間は、エラー情報の送信から、再送されたＲＴＰパケットの受信までの時間となる。つまり、ＲＴＴ取得部４０６は、ＲＴＰパケットの消失を検知した時点において、正常に受信されたＲＴＰパケットが送信装置によって送信された送信時刻と、受信装置によって受信された受信時刻に応じて、送信装置と受信装置間の片道時間を取得する。そして、例えば取得した片道時間を２倍することによって得られる往復時間に、予め取得している送信側処理時間を加算することによってＲＴＴを取得する。
【０１２５】
また、ＱｏＳ切替部４０４は、ＲＴＰパケットの消失の検知時刻に受信側処理時間を加算することで、エラー情報の送信時刻を取得することができる。この受信側処理時間は、固定値として、予め受信装置４００が記憶している。そして、エラー情報の送信時刻と、消失したＲＴＰパケットの復号時刻に応じて許容時間を取得し、取得された許容時間とＲＴＴを比較する。比較の結果、ＲＴＴよりも許容時間が長ければ、再送したＲＴＰパケットが再生（復号）に間に合うと判断し、送信装置に対して再送要求を行う。一方、ＲＴＴよりも許容時間が短い場合は、再送したＲＴＰパケットが再生（復号）に間に合わないと判断し、送信装置に対してＡＩＲ処理の要求を行う。
【０１２６】
このようにしても、上述のような本発明の効果を得ることができる。
【０１２７】
＜本発明に係る他の実施形態＞
前述の実施形態では、送信装置１００が動画像データの符号化処理を行う機能を有していたが、動画像符号化部１０２と送信装置１００とが別々の装置であっても良い。同様に、受信装置４００が動画像データの復号化処理を行う機能を有していたが、動画像復号化部４０７と受信装置４００とが別々の装置であっても良い。
【０１２８】
また、前述の実施形態では、動画像データの符号化方式としてＭＰＥＧ−４方式を用い、符号化動画像データ転送プロトコルとしてＲＴＰを用いた。しかし、動画像データの符号化方式としてはＭＰＥＧ−４方式に限らず、例えばＭＰＥＧ−２やＨ．２６４など、フレーム間予測符号化方式による符号化を行う類似の符号化方式を用いることができる。また、データ転送プロトコルについても、ＲＴＰに限らずＯＳＩ参照モデルの同一レイヤーの他のプロトコルまたは別レイヤーの他のプロトコルを用いることが可能である。エラー情報を送信するためのプロトコルについても、ＲＴＣＰの受信者レポートに限らずＴＣＰの否定応答（ＮＡＣＫ）など他のプロトコルを使用することが可能である。
【０１２９】
また、前述の実施形態は、システム或いは装置のコンピュータ（或いはＣＰＵ、ＭＰＵ等）によりソフトウェア的に実現することも可能である。したがって、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるコンピュータプログラム自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１３０】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０１３１】
また、前述の実施形態は、システム或いは装置のコンピュータ（或いはＣＰＵ、ＭＰＵ等）によりソフトウェア的に実現することも可能である。したがって、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるコンピュータプログラム自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１３２】
この場合、本発明の機能処理をコンピュータで実現するためのコンピュータプログラムは、記録媒体または有線／無線通信によりコンピュータに供給される。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、磁気テープ等の磁気記録媒体、ＭＯ、ＣＤ、ＤＶＤ等の光／光磁気記憶媒体、不揮発性の半導体メモリなどがある。
【０１３３】
有線／無線通信を用いたプログラムの供給方法としては、コンピュータネットワーク上のサーバを利用する方法がある。この場合、本発明を形成するコンピュータプログラムとなりうるデータファイル（プログラムデータファイル）をサーバに記憶しておく。プログラムデータファイルとしては、実行形式のものであっても、ソースコードであってもよい。
【０１３４】
そして、このサーバにアクセスしたクライアントコンピュータに、プログラムデータファイルをダウンロードすることによって供給する。この場合、プログラムデータファイルを複数のセグメントファイルに分割し、セグメントファイルを異なるサーバに分散して配置することも可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムデータファイルをクライアントコンピュータに提供するサーバ装置も本発明に含む。
【０１３５】
また、本発明のコンピュータプログラムを暗号化して格納した記録媒体をユーザに配布し、所定の条件を満たしたユーザに、暗号化を解く鍵情報を供給し、ユーザの有するコンピュータへのインストールを可能とすることも可能である。鍵情報は例えばインターネットを介してホームページからダウンロードさせることによって供給することができる。
【０１３６】
また、コンピュータにより実施形態の機能を実現するためのコンピュータプログラムが、実施形態の機能を、すでにコンピュータ上で稼働するＯＳの機能を利用して実現しても良い。さらに、本発明を構成するコンピュータプログラムの少なくとも一部が、コンピュータに装着される拡張ボード等のファームウェアとして提供され、拡張ボード等が備えるＣＰＵを利用して前述の実施形態の機能を実現してもよい。
【０１３７】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【０１３８】
【図１】第１の実施形態に係る送信装置１００の機能構成例を示すブロック図である。
【図２】第１の実施形態に係る送信装置におけるＱｏＳ制御の切り替え処理手順の一例を示すフローチャートである。
【図３】第１の実施形態に係る送信装置と受信装置を含むシステム全体におけるＱｏＳ制御のシーケンスを示す図である。
【図４】第２の実施形態に係る受信装置４００の機能構成例を示すブロック図である。
【図５】第２の実施形態に係る受信装置におけるＱｏＳ制御の切り替え処理手順の一例を示すフローチャートである。
【図６】の第２の実施形態に係る送信装置と受信装置を含むシステム全体におけるＱｏＳ制御のシーケンスを示す図である。
【符号の説明】
【０１３９】
１００  送信装置
１０４  送受信データバッファ
１０５  ＡＩＲ制御部
１０６  ＲＴＴ取得部
１０７  ＱｏＳ切替部
１０８  通信制御部
３０２  受信装置
４００  受信装置
４０３  送受信データバッファ
４０４  ＱｏＳ切替部
４０５  通信制御部
４０６  ＲＴＴ取得部
４０７  動画像復号化部
【図１】
2010074366.tif 000003
【図２】
2010074366.tif 000004
【図３】
2010074366.tif 000005
【図４】
2010074366.tif 000006
【図５】
2010074366.tif 000007
【図６】
2010074366.tif 000008