JP5523163B2

JP5523163B2 - 送信装置、送信方法、プログラム

Info

Publication number: JP5523163B2
Application number: JP2010075664A
Authority: JP
Inventors: 亨強矢
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-03-29
Filing date: 2010-03-29
Publication date: 2014-06-18
Anticipated expiration: 2030-03-29
Also published as: JP2011211390A

Description

本発明は、有線あるいは無線のネットワークにおけるデータの送信方法に関する。

近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となる、動画データのストリーミング再生をインターネットなどの通信回線を利用して一般に行われるようになってきている。特に、ライブ映像などのリアルタイム性を必要とする動画データを送信するためには、ＲＴＰ（ＡＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌｆｏｒＲｅａｌ−ＴｉｍｅＡｐｐｌｉｃａｔｉｏｎｓ）と呼ばれる通信プロトコルが一般に使用されている。ＲＴＰは、主に音声や動画などをリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦによりＲＦＣ３５５０として定義されている。

ＲＴＰは、非コネクション型のプロトコルであるＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）の上位プロトコルであり、通信処理が比較的単純なことから通信速度が期待できる。しかしながら、通信エラーの補償は行われないため、通信経路途中でパケットの損失が発生すると、転送している音声や動画に乱れが生じることが懸念される。

そこでＲＴＰを用いて音声や動画データを転送する際に通信エラーを回避するための種々の手法が一般に知られている。例えば、ネットワークの状況に合わせて適応的に送信レートを制御する方法（レート制御）や、ＡＲＱ（ＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔ：自動再送要求）と呼ばれる、欠落したパケットを再送する技術が知られている。また、例えば、ＦＥＣ（ＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ：前方誤り訂正）と呼ばれる技術によって、欠落したパケットを受信装置が復元する方法が知られている。

ここで、ＲＴＰに使用されるＦＥＣはＲＦＣ５１０９で定義されており、誤り訂正符号の技術を使ってデータ転送中に発生するパケットの欠落を回復する技術である。

このＦＥＣの働きを簡単に説明すると、まず送信側では、送信データを基に誤り訂正符号化によって、受信側でのデータ復元処理のために使用される冗長なデータを生成し、送信データに付加して送信する。そして受信側では、受信したデータの誤りやパケットの欠落を検出した場合、受信した正常なデータと冗長データを用いて誤り訂正符号を復号することで、エラーとなったパケットを復元できる。

ＦＥＣとＡＲＱは、どちらも通信経路でのパケットのエラーを回復する技術であるが、ＦＥＣは冗長データを加えて送信するため、送信するデータ量が増加するデメリットがある。また、ＦＥＣには、ＡＲＱと比較すると、再送に伴う時間のロスが無いというメリットがある。そこで、ＡＲＱとＦＥＣを組み合わせることで、互いの利点を活かし、エラー回復の効果を上げるハイブリッドＡＲＱという技術が知られている。これは、一般にＦＥＣで復元できなかったパケットをＡＲＱにより補完する技術である。

特許文献１には、例えば伝送遅延が大きい受信機に対しては、ＡＲＱによる再送パケットが再生に間に合わない恐れがあることから、ＦＥＣの冗長データ量を増やしてＦＥＣによる回復率を上げることが記載されている。また、逆に伝送遅延が小さい受信機に対しては、ＡＲＱによる再送パケットが再生に間に合う可能性が高いことから、ＦＥＣの冗長データ量を少なくすることで、通信帯域の利用効率を向上させることが記載されている。

特登録０３７５７８５７号公報

しかしながら、エラー訂正用の冗長データが必要以上に送られてしまう場合や、必要な冗長データが送信されない場合が発生する恐れがあった。

例えば、受信装置が動画データを受信してから当該動画データを再生処理開始するまでの時間（バッファリング時間）が長い場合、伝送遅延が大きくても再送パケットが間に合う場合がある。再送パケットが間に合うにも関わらず、冗長パケットが必要以上に送信されてしまうと、ネットワークの帯域を有効に利用できなくなる恐れがあった。

また、例えば、受信装置におけるバッファリング時間が非常に短い場合、伝送遅延が小さくても再送パケットが間に合わない場合がある。再送パケットが間に合わないにも関わらず、冗長パケットが送信されないと、ロスしたパケットを復元できず、再生画像が劣化してしまう恐れがあった。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、エラー訂正用の冗長データの送信量をより適切に制御することである。

本発明の目的を達成するために、例えば本発明のデータ送信装置は以下の手段を備える。すなわち、メディアデータを受信装置に送信すると共に、当該受信装置が正常に受信しなかったメディアデータを復元するための冗長データを送信する送信装置であって、受信装置におけるメディアデータの受信から再生処理開始までの時間に応じたバッファリング時間を取得すると共に、前記送信装置と前記受信装置との間におけるデータの伝達時間を取得する取得手段と、前記バッファリング時間と前記伝達時間に基づいて前記メディアデータのデータ量に対する前記冗長データのデータ量を決定する決定手段と、前記決定手段の決定に応じて冗長データを生成する生成手段とを有する。

以上の手段からなる本発明によれば、エラー訂正用の冗長データの送信量をより適切に制御できるようになる。

送信装置１０１及び受信装置１０２の基本構成を示すブロック図。再送猶予時間と冗長度クラスの関係を示した図。冗長度クラスとパケット廃棄率に対する冗長度設定の例。送信装置１０１における冗長度制御に関する制御フローである。受信レポートタイプのＲＴＣＰパケットの構成図。実際の通信経路に適用した場合の概念図。動画データのフレームタイプに応じた冗長度制御の例。

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

＜実施形態１＞
本実施形態の送信装置、受信装置の構成について、図１を用いて説明する。図１において、送信装置１０１と受信装置１０２が、伝送路１０９を介して接続されている。

なお、送信装置１０１や受信装置１０２は、それぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ＬＡＮ）などで接続される。

また、本形態では、送信装置１０１が受信装置１０２に対してＲＴＰプロトコルに基づいて動画データ（動画パケット）をストリーミング配信する例について説明するが、この例に限らない。例えば、動画パケットの代わりに、音声データを格納した音声パケットを送信するなど、他のメディアデータの送信に本発明を適用することが可能である。

送信装置１０１は、データパケット生成部１０３、誤り訂正符号化部１０４、冗長度制御部１０５、送信バッファ１０６、再送制御部１０７、送受信部１０８を含んで構成される。

データパケット生成部１０３は、外部から入力された動画の符号化データを、通信に適したサイズに分割し、通信するために必要なヘッダを付加してＲＴＰのデータパケット（動画パケット）を生成する。

誤り訂正符号化部１０４は、冗長度制御部１０５から指示される冗長度に従って、動画パケットからＦＥＣパケットを生成する。なお、ＦＥＣパケットは、受信装置１０２が正常に受信しなかった動画パケットを受信装置１０２が復元するために用いる冗長データが格納された冗長パケットである。受信装置１０２は、正常に受信した他の動画パケットと、正常に受信したＦＥＣパケットを用いて、正常に受信できなかった動画パケットを復元できる。

送信バッファ１０６は、データパケット生成部１０３により生成された動画パケット、及び、誤り訂正符号化部１０４により生成されたＦＥＣパケットを一時的に保管する。

送受信部１０８は、送信バッファ１０６に一時保管された動画パケットおよびＦＥＣパケットを、伝送路１０９を介して受信装置１０２に送信する。すなわち、送信装置１０１は、メディアデータ（動画パケット）を受信装置１０２に送信すると共に、受信装置１０２が正常に受信しなかったメディアデータを復元するための冗長データ（ＦＥＣパケット）を送信する。送路１０９は各種ネットワークに代表される伝送路であり、本実施形態においては、動画パケットやＦＥＣパケットを通信するためのネットワークである。

送受信部１０８は、伝送路１０９からパケットを受信する機能も備えている。送受信部１０８は、例えば受信装置１０２におけるパケットの受信状況に関する通知パケットや、受信装置１０２が正常に受信しなかった動画パケットの再送要求パケットを受信する。

再送制御部１０７は、送受信部１０８が受信した再送要求パケットに対応する動画パケットを、送受信部１０８に再送させる。再送要求パケットに対応する動画パケットは、送信バッファ１０６に記憶されている。

冗長度制御部１０５は、送受信部１０８が受信装置１０２から受信した通知パケットに基づいて、誤り訂正符号の冗長度を決定する。そして、冗長度制御部１０５は、誤り訂正符号化部１０４に決定した冗長度を通知する。なお、誤り訂正符号の冗長度とは、動画データのデータ量に対する冗長データのデータ量である。誤り訂正符号化部１０４は、冗長度制御部１０５により通知された冗長度に従って、動画パケットからＦＥＣパケットを生成する。通知パケットの詳細と、冗長度制御部１０５による冗長度の決定方法の詳細は後述する。

受信装置１０２は送受信部１１０、受信バッファ１１１、受信状況解析部１１２、復元部１１３、再送要求部１１４、バッファ制御部１１５を含んで構成される。また、本形態の受信装置１０２は、再生処理部１１６、表示部１１７を含んでいる。
送受信部１１０は、送信装置１０１から送信される受信装置１０２宛てのパケットを伝送路１０９から受信する。また、送受信部１１０は、伝送路１０９に任意のパケットを送信する。

受信バッファ１１１は、送受信部１１０により受信された動画パケット、ＦＥＣパケットを格納する。受信状況解析部１１２は、受信バッファ１１１に格納されたパケットのシーケンスンナンバーを監視することで、例えば伝送路１０９上の中継装置で廃棄されるなどして失われたパケットを識別する。シーケンスナンバーとは、ＲＴＰで送信される動画パケットおよびＦＥＣパケットごとに連番で付加される番号である。受信状況解析部１１２は、シーケンスナンバーの抜けを監視することで正常に受信できなかった動画パケットを特定する。受信状況解析部１１２は、正常に受信できなかった動画パケットのシーケンスナンバーを復元部１１３に通知する。

復元部１１３は、受信状況解析部１１２からの通知に応じて、正常に受信した動画パケットとＦＥＣパケットを利用して誤り訂正符号を復号することにより、正常に受信できなかった動画パケットを復元する。受信バッファ１１１は、復元部１１３により復元された動画パケットを格納する。また、復元部１１３は、ＦＥＣパケットで復元できなかった動画パケットのシーケンスナンバーを再送要求部１１４に通知する。

再送要求部１１４は、復元部１１３からの通知に応じて、ＦＥＣパケットで復元できなかった動画パケットの再送要求パケットを生成し、送受信部１１０を介して送信装置１０１に送信する。

本形態の受信状況解析部１１２は、受信装置１０２におけるパケットの受信状況を示す通知パケット（受信レポート）を生成する。この受信レポートの送信は定期的に行われ、送信装置１０１の冗長度制御部１０５は、受信した受信レポートに応じて誤り訂正符号の冗長度を制御する。

バッファ制御部１１５は、受信装置１０２における動画データ（メディアデータ）の受信から再生処理開始までの時間に応じたバッファリング時間を入力する。また、バッファ制御部１１５は、受信バッファ１１１の動画パケットの格納状況を監視し、バッファリング時間に従って、再生処理部１１６へ復号処理の実行を指令する。

再生処理部１１６は、バッファ制御部１１５からの指示に応じて、受信バッファ１１１に格納されている動画パケットから符号化された動画データを取り出して復号する。表示部１１７は、復号された動画データを表示装置に出力する。

本形態では、受信装置１０２でのパケットの受信状況に関する通知パケット（受信レポート）や、送信装置１０１でのパケットの送信状況に関する通知パケット（送信レポート）の通信プロトコルにＲＴＣＰ（ＲＴＰＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）を用いる。ＲＴＣＰは、ＲＴＰと同様にＲＦＣ３５５０で定義され、主にＲＴＰでのデータ送受信の状況を送信側・受信側の双方で把握するために利用される。

ＲＴＣＰのパケットとして、以下の５種類が定義されている。すなわち、受信レポート、送信レポート、ソース記述、メンバシップ管理、及びアプリケーション定義の５種類である。なお、受信レポートはＲｅｃｅｉｖｅｒＲｅｐｏｒｔ（ＲＲ）、送信レポートはＳｅｎｄｅｒＲｅｐｏｒｔ（ＳＲ）、ソース記述はＳｏｕｒｃｅＤｅｓｃｒｉｐｔｉｏｎ（ＳＤＥＳ）とも呼ばれる。また、メンバシップ管理はＢＹＥ、アプリケーション定義はＡｐｐｌｉｃａｔｉｏｎ−Ｄｅｆｉｎｅｄ（ＡＰＰ）とも呼ばれる。

本実施形態の受信装置１０２が、受信状況に関する通知パケットとして送信するＲＴＣＰの受信レポートの構成を図５に示す。

図５に示すように、受信レポートは、ＲＴＣＰヘッダ５０１と、受信レポートブロック５０２と、プロファイル依存拡張５０３で構成される。受信レポートブロック５０２はＲＣ（ｒｅｃｅｐｔｉｏｎｒｅｐｏｒｔｃｏｕｎｔ）５０４に示される数だけ存在する。

次に受信レポートブロック５０２の構成について説明する。

瞬時廃棄率（ＦｒａｃｔｉｏｎＬｏｓｔ）５０５は、最後に受信レポートを生成してから、次の受信レポートを生成するまでに損失したＲＴＰパケットの割合を示す値を含むものである。

累積パケット廃棄率（ｃｕｍｕｌａｔｉｖｅｎｕｍｂｅｒｏｆｐａｃｋｅｔｓｌｏｓｔ）５０６は、通信を開始してから受信レポート生成までに損失したＲＴＰパケットの総数を含む値が格納される。

パケット間隔ジッタ（ｉｎｔｅｒａｒｒｉｖａｌｊｉｔｔｅｒ）５０７は、ＲＴＰパケットの受信時刻の揺らぎを統計的な計算により処理した予測値が含まれる。

ＬＳＲ（ｌａｓｔＳＲｔｉｍｅｓｔａｍｐ）５０８は、受信装置１０２が最後に受信した送信レポートから取得した６４ビットで構成されるＮＴＰ（ＮｅｔｗｏｒｋＴｉｍｅＰｒｏｔｏｃｏｌ）タイムスタンプの中間３２ビットを含む。すなわち、ＬＳＲ５０８には、受信装置１０２が最後に受信した送信レポートを送信装置１０１が送信した時刻が格納されている。

ＤＬＳＲ（ＤｅｌａｙｓｉｎｃｅｌａｓｔＳＲ）５０９は、受信装置１０２が最後に受信した送信レポートの受信時刻から、受信レポートを送信するまでの遅延時間を含む値が格納される。
尚、送信レポート（ＳＲ）は、前述した通りＲＴＣＰパケットのタイプの一つであり、主に送信状況を通知する為、送信側から受信側に配信される。

本実施形態の受信状況解析部１１２は、バッファリング時間を受信レポートの拡張領域であるプロファイル依存拡張５０３に格納する。バッファリング時間は、バッファ制御部１１５から通知される。このバッファリング時間は、ユーザによって設定されても良いし、例えばアプリケーションによって決定されても良い。送信装置１０１の冗長度制御部１０５は、上記のような受信レポートを含む通知パケットの受信に応じて、冗長度を制御する。

次に、冗長度制御部１０５におけるＦＥＣ冗長度の制御方法について説明する。

本形態の冗長度制御部１０５は、受信レポートに含まれる瞬時廃棄率５０５と、ＬＳＲ５０８と、ＤＬＳＲ５０９に格納された値と、プロファイル依存拡張５０３に格納されたバッファリング時間を利用して、冗長度を決定する。

冗長度制御部１０５は、その情報を含む通知パケット（受信レポート）を受信した時刻の情報を送受信部１０８から受け取る。この受信時刻をＲＴ（ｒｔｃｐ）と表記すると、送信装置１０１と受信装置１０２間の往復遅延時間ＲＴＴ（ＲｏｕｎｄＴｒｉｐＴｉｍｅ）は次の計算式で表せる。
ＲＴＴ＝ＲＴ（ｒｔｃｐ） − ＬＳＲ − ＤＬＳＲ
ＲＴＴは、送信装置１０１と受信装置１０２との間をパケットが往復するのに要する時間である。

再送するパケットが間に合うか否かを判断するには、受信装置１０２でのバッファリング時間からＲＴＴを減算した時間が目安となる。そこで、この時間を再送猶予時間と呼ぶことにすると、次の計算式で示すことができる。
再送猶予時間＝バッファリング時間 − ＲＴＴ
すなわち、冗長度制御部１０５は、バッファリング時間から伝達時間（ＲＴＴ）を差し引いて再送猶予時間（猶予時間）を取得する。

この再送猶予時間が大きいほど、再送パケットが受信装置１０２の再生処理に間に合う確率は高くなる。従って、パケットの廃棄率が同程度の伝送路であれば、再送猶予時間が短いほどＦＥＣ冗長度を高める必要がある。逆に再送猶予時間が長いほど、再送パケットによる補完が期待できるので、ＦＥＣ冗長度を低くすることができる。

本実施形態では、ＦＥＣ冗長度の決定に冗長度クラスという概念を用いる。冗長度クラスとは、再送猶予時間によって一意に決定されるクラスであり、例えば図２のように設定する。

本形態の冗長度制御部１０５は、受信レポートから求めた再送猶予時間に応じて、冗長度クラスを設定する。図２において、例えば、再送猶予時間（Ｔ）が閾値Ｔｈ（ｂ）と閾値Ｔｈ（ｃ）の間の場合、冗長度クラスはＢとなる。

また、本実施形態の冗長度制御部１０５は、冗長度クラスとパケット廃棄率に基づいてＦＥＣ冗長度を決定する。具体的な例を図３に示す。

図３において、グラフの横軸はパケット廃棄率であり、縦軸はＦＥＣ冗長度である。図３に示すように、各冗長度クラスにおいて、パケット廃棄率が高いほど、ＦＥＣ冗長度が高くなる。すなわち、冗長度制御部１０５は、受信装置１０２が正常に受信しなかったエラーデータ量に応じたエラー情報（瞬時廃棄率５０５）を取得する。そして、冗長度制御部１０５は、冗長度クラスＢに対応する受信装置において、例えばパケット廃棄率Ｅに応じたエラー情報が取得された場合、パケット廃棄率Ｅよりもエラーデータ量が多いエラー情報が取得された場合よりも、ＦＥＣ冗長度を低くする。

また、図３に示すように、パケット廃棄率が同じでも、冗長度クラスによってＦＥＣ冗長度が異なる。例えば、冗長度クラスＢ（３０２）の場合、パケット廃棄率がＥの時に設定されるＦＥＣ冗長度はＲｂとなり、再送猶予時間が短い冗長度クラスＡ（３０１）よりもＦＥＣ冗長度は低くなる。また、逆に再送猶予時間が長い冗長度クラスＣ（３０３）よりもＦＥＣ冗長度は高くなる。

すなわち、冗長度制御部１０５は、冗長度クラスＢに対応する第１の猶予時間が取得された場合、冗長度クラスＡに対応する第２の猶予時間が取得された場合よりも、ＦＥＣ冗長度（メディアデータのデータ量に対する冗長データのデータ量）を少なくする。

このように冗長度制御部１０５は、受信装置１０２のバッファリング時間とＲＴＴとパケット廃棄率などの通信状況を受信レポートから取得し、ＦＥＣ冗長度を制御する。このようにすることで、受信装置１０２の状況により適合した冗長度の制御を実現することができる。

冗長度制御部１０５によるＦＥＣ冗長度制御のもう一つの例を、図７を用いて説明する。この例において、冗長度制御部１０５は、動画データのフレームタイプに応じて冗長度を変更する。

本実施形態では、送信装置１０１のデータパケット生成部１０３に符号化データが入力されると説明したが、動画データの符号化方法には、ＭＰＥＧ−２やＭＰＥＧ−４、Ｈ．２６４（ＭＰＥＧ−４ＡＶＣ）などの符号化方法が広く使われている。例えばＭＰＥＧ−４の場合、符号化の方法によって主要な３つのフレームタイプがあることが知られている。

１つ目のタイプは、そのフレームのデータのみで復号可能な符号化方法でＩフレームと呼ばれている。２つ目のタイプは、時間的に前のフレームを参照してその差分情報を基に符号化したもので、Ｐフレームと呼ばれている。３つ目のタイプは、時間的に前後のフレームを参照して、その差分情報を基に符号化したもので、Ｂフレームと呼ばれる。

再送猶予時間によってクラス分けされた冗長度クラス毎に、ＦＥＣパケットを生成するフレームタイプを決める方法を図７を用いて説明する。

例えば、再送猶予時間が短い冗長度クラスＡでは、すべてのタイプのフレームのＦＥＣパケットを生成する。また、冗長度クラスＢでは、ＩフレームとＰフレームに対してＦＥＣパケットを生成しＢフレームの動画パケットを復元するためのＦＥＣパケットを生成しない。さらに、冗長度クラスＣでは、ＩフレームのＦＥＣパケットを生成し、ＰフレームとＢフレームのＦＥＣパケットを生成しない。再送猶予時間が十分に長い冗長度クラスＤでは、すべてのタイプのフレームのＦＥＣパケットを生成しない。

すなわち、冗長度制御部１０５は、冗長度クラスＡに対応する再送猶予時間が取得された場合、インターフレーム（Ｐ、Ｂフレーム）のＦＥＣデータとイントラフレーム（Ｉフレーム）のＦＥＣデータを生成することを決定する。また、冗長度制御部１０５は、冗長度クラスＣに対応する再送猶予時間が取得された場合、インターフレームのＦＥＣデータを生成せず、イントラフレームのＦＥＣデータを生成することを決定する。

なお、本形態では、冗長度クラスを４つに分類しているが、例えば、より多くのクラスに分類しても良い。また、フレームタイプによって異なる冗長度を設定するようにしても良い。

次に、本形態の送信装置１０１の処理について図４の処理フロー図を用いて説明する。
なお、本形態の送信装置１０１は、図４のフロー図に対応する処理プログラムを格納したＲＯＭから、送信装置１０１のＣＰＵが当該プログラムをＲＡＭに読み出して実行することにより実現される。

図４において、まず受信装置１０２との間で、通信するためのセッションを確立する（ステップＳ４０１）。なお、ＲＴＰやＲＴＣＰ等のプロトコルにより通信するためには、ＲＴＳＰ（ＲｅａｌＴｉｍｅＳｔｒｅａｍｉｎｇＰｒｏｔｏｃｏｌ）やＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）などを使用してセッションを制御する必要がある。本実施形態においては、主に送信と受信の２つの役割の通信であるので、この様な用途のセッション制御にはＲＴＳＰが適している。

次に、冗長度制御部１０５は、ＦＥＣ冗長度の初期設定を行う（ステップＳ４０２）。

通信開始前は、通信経路の状況がわからないので、ＦＥＣの冗長データによって帯域を無駄に使用しないように、ＦＥＣ冗長度を低めに設定しても良い。或いは、冗長度クラスとパケット廃棄率を制御範囲の中間程度の値に設定しても良い。或いは、既存のセッションに新たにセッションを追加する場合は、既存のセッションのＦＥＣ冗長度に合わせても良い。

ＦＥＣ冗長度の初期設定が完了したら、送受信部１０８は、動画パケット及びＦＥＣパケットの送信を開始する（ステップＳ４０３）。

送受信部１０８は、ステップＳ４０３で開始された通信が終了したか否かを判定する（ステップＳ４０４）。通信が終了したと判定された場合、送受信部１０８は、動画パケット及びＦＥＣパケットの送信を終了し（ステップＳ４０７）、セッションを削除する（ステップＳ４０８）。ステップＳ４０４で通信が終了していないと判定された場合はステップＳ４０５に進む。

動画パケットの通信中は、定期的に、ＲＴＣＰの送信レポートと受信レポートが相互に送られる。本実施形態の冗長度制御部１０５は、ＲＴＣＰの受信レポートを用いて、バッファリング時間とＲＴＴとパケット廃棄率を取得する（ステップＳ４０５）。すなわち、冗長度制御部１０５は、ステップＳ４０５（取得手順）で、受信装置１０２における動画パケット（メディアデータ）の受信から再生処理開始までの時間に応じたバッファリング時間を取得する。また、冗長度制御部１０５は、送信装置１０１と受信装置１０２との間におけるデータの伝達時間（ＲＴＴ）を取得する。

そして、冗長度制御部１０５は、バッファリング時間とＲＴＴとを用いて再送猶予時間を求めてＦＥＣの冗長度クラスを設定する（ステップＳ４０６）。そして、冗長度制御部１０５は、冗長度クラスとパケット廃棄率に応じてＦＥＣ冗長度を制御する。

すなわち、冗長度制御部１０５は、ステップＳ４０６（決定手順）で、バッファリング時間と伝達時間（ＲＴＴ）に基づいて動画データ（メディアデータ）のデータ量に対するＦＥＣデータ（冗長データ）のデータ量を決定する。

そして、誤り訂正符号化部１０４は、冗長度制御部１０５の決定に応じてＦＥＣパケット（冗長データ）を生成し（生成手順）、送受信部１０８から受信装置１０２に送信する。
本形態の冗長度制御部１０５は、ＲＴＣＰの受信レポートを受信する度にステップＳ４０５とＳ４０６の処理を行う。

例えばユーザの操作によって受信装置１０２においてバッファリング時間が変更になった場合、ステップＳ４０５で、冗長度制御部１０５は受信装置１０２からの通知パケット（受信レポート）に応じて変更後のバッファリング時間を取得する。そして、冗長度制御部１０５は、ステップＳ４０６で、ＲＴＴ（伝達時間）と、変更後のバッファリング時間とに基づいて、ＦＥＣ冗長度（動画データに対するＦＥＣデータのデータ量）を変更する。

なお、受信装置１０２においてＦＥＣを用いても復元できない動画パケットがあった場合には、再送要求パケットが送信装置１０１へ送信される。そして、送信装置１０１の再送制御部１０７は、再送要求された動画パケットを再送する。

ここまでに説明したように、本実施形態の送信装置１０１は、受信装置側で設定されるバッファリング時間と、通信状況に応じたＲＴＴから、再送猶予時間を算出する。そして、送信装置１０１は、算出された再送猶予時間と、パケット廃棄率（瞬時廃棄率５０５）に基づいてＦＥＣ冗長度を設定する。このようにすることで、効率の良いハイブリッドＡＲＱを実現できる。

本発明を実際の通信経路に適用した場合の例について、図６を用いて説明する。

図６において、横軸は再送猶予時間であり、Ｃｌｉｅｎｔ１〜３は、各々の再送猶予時間に基づいて位置付けされている。つまり、Ｃｌｉｅｎｔ１は、Ｃｌｉｅｎｔ１〜３のうちで最も再送猶予時間が長いクライアントであり、Ｃｌｉｅｎｔ２は、最も再送猶予時間が短いクライアントである。

図６に示すように、例えばＣｌｉｅｎｔ１は送信装置と同じイントラネット内に位置しており、ＲＴＴは２０ｍｓである。また、Ｃｌｉｅｎｔ１で設定されているバッファリング時間は４００ｍｓである。従って、Ｃｌｉｅｎｔ１の再送猶予時間は３８０ｍｓとなる。本形態では、Ｃｌｉｅｎｔ１は冗長度クラスＤに設定される。冗長度クラスＤは再送猶予時間が長いため、仮に動画パケットの欠落が発生しても再送パケットが受信装置における再生処理に間に合う可能性が高い。このため、送信装置１０１は、冗長度クラスＤに設定した受信装置に対しては、ＦＥＣ冗長度を低めに設定する（もしくはＦＥＣパケットを送信しない）。

一方、Ｃｌｉｅｎｔ２は、送信装置と同じ国に存在するが、Ｃｌｉｅｎｔ１よりも地理的に離れて位置しており、ＲＴＴは８０ｍｓである。また、Ｃｌｉｅｎｔ２で設定されているバッファリング時間は１００ｍｓである。従って、Ｃｌｉｅｎｔ２の再送猶予時間は２０ｍｓとなる。本形態では、Ｃｌｉｅｎｔ２は冗長度クラスＡに設定される。冗長度クラスＡは再送猶予時間が短いため、動画パケットが欠落すると再送パケットが受信装置における再生処理に間に合わない可能性が高い。このため、送信装置１０１は、冗長度クラスＡに設定した受信装置に対しては、ＦＥＣ冗長度を高めに設定する。

Ｃｌｉｅｎｔ３は、Ｃｌｉｅｎｔ１〜３の中で、地理的に送信装置から最も離れた位置に存在しており、ＲＴＴは４２０ｍｓである。また、Ｃｌｉｅｎｔ３で設されているバッファリング時間は６００ｍｓである。従って、Ｃｌｉｅｎｔ３の再送猶予時間は１８０ｍｓとなる。本形態では、Ｃｌｉｅｎｔ３は冗長度クラスＣに設定される。冗長度クラスＣは冗長度クラスＡやＢよりも再送猶予時間が長いため、冗長度制御部１０５は、冗長度クラスＡやＢの受信装置よりもＦＥＣ冗長度を低くする。また、冗長度クラスＣは冗長度クラスＤよりも再送猶予時間が短いため、冗長度制御部１０５は、冗長度クラスＤの受信装置よりもＦＥＣ冗長度を高くする。

すなわち、送信装置からの距離は、Ｃｌｉｅｎｔ１、２、３の順に近いが、バッファリング時間を考慮した再送猶予時間においては、Ｃｌｉｅｎｔ１、３、２の順に再送パケットが動画の再生に間に合う可能性が高くなる。

以上説明したように、本形態の冗長度制御部１０５は、バッファリング時間と伝達時間を考慮することにより、再送パケットが間に合う可能性に合わせてＦＥＣ冗長度を制御する。これにより、エラー訂正用の冗長データの送信量をより適切に制御できるようになる。

＜実施形態２＞
実施形態１では、バッファリング時間とＲＴＴに基づいてＦＥＣ冗長度を決定していたが、例えばインターネットなどのベストエフォートの通信回線では、ＲＴＴの値が揺らぐ、所謂ジッタの影響を受けることになる。

つまり、ジッタが大きいということは、動画パケットごとの伝達時間の差が大きい、すなわち、ばらついていることを示している。ジッタが大きい場合、短い伝達時間で到達する動画パケットについては特に問題ないが、伝達時間が長くかかってしまう動画パケットについては、再送猶予時間が予想より短くなり、再送パケットが間に合わなくなる可能性がある。

そこで、本実施形態では、実施形態１の方法で求めた再送猶予時間に、更にジッタの値を考慮して、ＦＥＣ冗長度を制御する方法について説明する。

具体的には、本形態の冗長度制御部１０５は、図５に示す受信レポートのパケット間隔ジッタ５０７から、通信回線のジッタを取得する。すなわち、冗長度制御部１０５は、送信装置１０１が送信した動画パケットの受信装置１０２による受信時刻のばらつきに応じたジッタ情報を取得する。そして、冗長度制御部１０５は、再送猶予時間が同じ場合、ばらつきが大きいジッタ情報が取得された場合のほうがＦＥＣ冗長度が低くなるようにメディアデータ（動画データ）のデータ量に対するＦＥＣデータのデータ量を決定する。

パケット間隔ジッタ５０７は、ＲＴＰパケットのインターバル時間を統計的な手法により算出した分散値であり、パケットの到着間隔の送信時と受信時の差の平均偏差として定義されている。

つまり、パケット間隔ジッタ５０７に格納された値が大きいほど、パケットの到着間隔が変動する可能性が大きくなる。そこで、本形態の冗長度制御部１０５は、ジッタの値が大きいほど、再送猶予時間を短く見積もる。

ただし、この方法に限らず、例えば、実施形態１で説明したような再送猶予時間をセッションごとに算出し、同等なセッションが複数あった場合に、ジッタの大きさによってＦＥＣの冗長度を変更しても良い。具体的には、同等の再送猶予時間であっても、ジッタが大きいセッションほどＦＥＣの冗長度を高く設定することで、伝送遅延が大きいときに廃棄されたパケットをＦＥＣパケットで復元できる。

例えば、送信装置が複数の受信装置にそれぞれ異なる動画データを送信している場合に、実施形態１の方法で各受信装置に対してそれぞれ算出した再送猶予時間が、すべて冗長度クラスＡに対応する場合、ＦＥＣパケットの生成が間に合わなくなる恐れがある。このような場合、冗長度制御部１０５は、ジッタが大きいセッションについては冗長度クラスＡに対応させ、ジッタが比較的小さいセッションについては冗長度クラスＢやＣなどに対応させる。このようにすることで、再送パケットが間に合わなくなる可能性が高いセッションについてより多くのＦＥＣパケットを送信できる。

なお、冗長度クラスの設定や冗長度の制御を行う方法は、本形態の方法に限らず、例えば、係数や多項式を用いて算出するようにしても良い。

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

Claims

メディアデータを受信装置に送信すると共に、当該受信装置が正常に受信しなかったメディアデータを復元するための冗長データを送信する送信装置であって、
受信装置におけるメディアデータの受信から再生処理開始までの時間に応じたバッファリング時間を取得すると共に、前記送信装置と前記受信装置との間におけるデータの伝達時間を取得する取得手段と、
前記バッファリング時間と前記伝達時間に基づいて前記メディアデータのデータ量に対する前記冗長データのデータ量を決定する決定手段と、
前記決定手段の決定に応じて冗長データを生成する生成手段と
を有することを特徴とする送信装置。
前記取得手段は、前記バッファリング時間から前記伝達時間を差し引いて猶予時間を取得し、
前記決定手段は、第１の猶予時間が取得された場合、前記第１の猶予時間より短い第２の猶予時間が取得された場合よりも、前記メディアデータのデータ量に対する冗長データのデータ量を少なくすることを特徴とする請求項１記載の送信装置。
前記メディアデータは符号化された動画データであり、
前記決定手段は、
前記第１の猶予時間が取得された場合、前記動画データのフレームのうち他のフレームを参照せずに復号可能なインターフレームの冗長データと、他のフレームを参照せずに復号可能なイントラフレームの冗長データを生成することを決定し、
前記第１の猶予時間より短い前記第２の猶予時間が取得された場合、前記インターフレームの冗長データを生成せず、前記イントラフレームの冗長データを生成することを決定することを特徴とする請求項２に記載の送信装置。
前記取得手段は、前記受信装置が正常に受信しなかったエラーデータ量に応じたエラー情報を取得し、
前記決定手段は、
第１のエラーデータ量に応じた第１のエラー情報と、前記第１の猶予時間が取得された場合、
前記第１のエラーデータ量よりも多い第２のエラーデータ量に応じた第２のエラー情報と、前記第１の猶予時間が取得された場合よりも、
前記メディアデータのデータ量に対する冗長データのデータ量が少なくなるように、前記メディアデータのデータ量に対する冗長データのデータ量を決定することを特徴とする請求項２記載の送信装置。
前記取得手段は、前記送信装置が送信したメディアデータのパケットの受信装置による受信時刻のばらつきに応じたジッタ情報を取得し、
前記決定手段は、
第１のばらつきに応じた第１のジッタ情報と、前記第１の猶予時間が取得された場合、
前記第１のばらつきよりもばらつきが大きい第２のばらつきに応じた第２のジッタ情報と、前記第１の猶予時間が取得された場合よりも、
前記メディアデータのデータ量に対する冗長データのデータ量が少なくなるように、前記メディアデータのデータ量に対する冗長データのデータ量を決定することを特徴とする請求項２又は４記載の送信装置。
前記取得手段は、前記受信装置からの通知に応じて前記受信装置において変更された後のバッファリング時間を取得し、
前記決定手段は、前記伝達時間と、前記変更された後のバッファリング時間とに基づいて、前記メディアデータのデータ量に対する冗長データのデータ量を変更することを特徴とする請求項１又は２記載の送信装置。
メディアデータを受信装置に送信すると共に、当該受信装置が正常に受信しなかったメディアデータを復元するための冗長データを送信する送信装置が行う送信方法であって、
受信装置におけるメディアデータの受信から再生処理開始までの時間に応じたバッファリング時間を取得すると共に、前記送信装置と前記受信装置との間におけるデータの伝達時間を取得する取得工程と、
前記バッファリング時間と前記伝達時間に基づいて前記メディアデータのデータ量に対する前記冗長データのデータ量を決定する決定工程と、
前記決定工程の決定に応じて冗長データを生成する生成工程と
を有することを特徴とする送信方法。
前記取得工程では、前記バッファリング時間から前記伝達時間を差し引いて猶予時間を取得し、
前記決定工程では、第１の猶予時間が取得された場合、前記第１の猶予時間より短い第２の猶予時間が取得された場合よりも、前記メディアデータのデータ量に対する冗長データのデータ量を少なくすることを特徴とする請求項７記載の送信方法。
前記メディアデータは符号化された動画データであり、
前記決定工程では、
前記第１の猶予時間が取得された場合、前記動画データのフレームのうち他のフレームを参照せずに復号可能なインターフレームの冗長データと、他のフレームを参照せずに復号可能なイントラフレームの冗長データを生成することを決定し、
前記第１の猶予時間より短い前記第２の猶予時間が取得された場合、前記インターフレームの冗長データを生成せず、前記イントラフレームの冗長データを生成することを決定することを特徴とする請求項８に記載の送信方法。
メディアデータを受信装置に送信すると共に、当該受信装置が正常に受信しなかったメディアデータを復元するための冗長データを送信するコンピュータに、
受信装置におけるメディアデータの受信から再生処理開始までの時間に応じたバッファリング時間を取得すると共に、前記送信装置と受信装置との間におけるデータの伝達時間を取得する取得手順と、
前記バッファリング時間と前記伝達時間に基づいて前記メディアデータのデータ量に対する前記冗長データのデータ量を決定する決定手順と、
前記決定手順の決定に応じて冗長データを生成する生成手順と
を実行させることを特徴とするプログラム。