(57)【要約】【課題】動画像データの通信においてＴＦＲＣ制御を用いる場合に、輻輳によるパケット棄却の影響を軽減できるようにする。【解決手段】送信方法にＦＥＣを用いて動画像データの送受信を行う際に、単位時間当たりに送信するパケット数、及びその時の使用可能帯域から算出した閾値に応じてＦＥＣの冗長度を制御することにより、データパケットの復元可能性を向上させて、送信レートの平均値を無駄に高めることなく、誤り訂正を効率良く行うことができるようにする。【選択図】  図６
2010041326.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して動画像データを受信装置に送信するデータ送信装置であって、
前記動画像データの符号量が目標符号量となるように制御する符号量制御手段と、
前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御手段と、
前記レート制御手段で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化手段とを備えることを特徴とするデータ送信装置。
【請求項２】
前記ネットワークを介して送信するパケットを記憶装置に一時的に保管するパケット保管手段を更に備え、
前記送信レート制御手段は、前記目標符号量、及び前記記憶装置に保管されているデータ量のうち、少なくとも１つを所定の時間内に送信するパケット数の制御に用いることを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
前記動画像データをＭＰＥＧ−２、ＭＰＥＧ−４、ＭＰＥＧ−４  ＡＶＣ(Ｈ．２６４)を含む符号化方式で符号化する符号化手段を更に備え、
前記符号化手段により前記動画像データを符号化して前記ネットワークを介して送信することを特徴とする請求項１または２に記載のデータ送信装置。
【請求項４】
前記所定の時間は、ＲＴＴ、またはＧＯＰ(Group Of Picture)、或いはＧＯＶ(Group Of Video Object Plane)の時間のうち、少なくとも１つの値を整数倍した時間であることを特徴とする請求項１〜３の何れか１項に記載のデータ送信装置。
【請求項５】
前記送信レート制御手段は、データ受信装置の伝送エラー通知手段からパケット棄却を示す情報が通知された時に、次の所定の時間内に送信するパケット数を減少させることを特徴とする請求項１〜４の何れか１項に記載のデータ送信装置。
【請求項６】
前記受信装置との間のＲＴＴ(Round Trip Time)を測定するＲＴＴ測定手段を更に備え、
前記符号量制御手段は、前記ＲＴＴ測定手段により測定されたＲＴＴと前記伝送エラーの情報のうち、少なくとも１つを用いて前記目標符号量を設定することを特徴とする請求項５に記載のデータ送信装置。
【請求項７】
ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出手段と、
前記伝送エラー検出手段により検出された伝送エラーの情報を送信装置に通知する伝送エラー通知手段とを備えることを特徴とするデータ受信装置。
【請求項８】
前記伝送エラー通知手段は、ＲＴＣＰ(RTP Control Protocol)のレシーバーレポートを用いることを特徴とする請求項７に記載のデータ受信装置。
【請求項９】
送信装置との間のＲＴＴ(Round Trip Time)を測定するＲＴＴ測定手段を更に備えることを特徴とする請求項７または８に記載のデータ受信装置。
【請求項１０】
請求項１〜６の何れか１項に記載のデータ送信装置と、請求項７〜９の何れか１項に記載のデータ受信装置とを備えることを特徴とするデータ送受信システム。
【請求項１１】
ネットワークを介して動画像データを受信装置に送信するデータ送信方法であって、
前記動画像データの符号量が目標符号量となるように制御する符号量制御工程と、
前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御工程と、
前記レート制御工程で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化工程とを備えることを特徴とするデータ送信方法。
【請求項１２】
ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出工程と、
前記伝送エラー検出工程において検出された伝送エラーの情報を送信装置に通知する伝送エラー通知工程とを備えることを特徴とするデータ受信方法。
【請求項１３】
ネットワークを介して動画像データを受信装置に送信するデータ送信方法の各工程をコンピュータに実行させるコンピュータプログラムであって、
前記動画像データの符号量が目標符号量となるように制御する符号量制御工程と、
前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御工程と、
前記レート制御工程で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化工程とをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１４】
ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出工程と、
前記伝送エラー検出工程において検出された伝送エラーの情報を送信装置に通知する伝送エラー通知工程とをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１５】
請求項１３または１４に記載のコンピュータプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ送信装置、データ受信装置及びデータ送受信システムに関し、特に、有線あるいは無線のネットワークにおいて、動的に送信レートを変動する技術に用いて好適な技術に関する。
【背景技術】
【０００２】
近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となる、動画像データの視聴をインターネットなどの通信回線を通して見ることが一般に行われるようになってきている。
【０００３】
このような動画像データの通信を行う際に、特に、ライブ映像などのリアルタイム性を必要とする動画像データを長時間にわたり送信することがある。このようにするためには、ＲＴＰ(A Transport Protocol for Real-Time Applications)と呼ばれる形式のプロトコルを用いるのが一般的となっている。ＲＴＰは、音声や動画像などをリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦ(Internet Engineering Task Force)によりＲＦＣ1889及びＲＦＣ1890として定義されている。
【０００４】
また、ＲＴＰは、ＵＤＰ(User Datagram Protocol)の上位プロトコルである。これは、通信時の処理において、リソースの確保や通信エラーの補償を行わない代わりに、比較的単純な仕組みであることから通信速度が期待できるものとなっている。
【０００５】
一方、インターネットに代表される通信環境においては、トラフィックの大部分がＴＣＰ(Transmission Control Protocol)をベースとするプロトコルによって転送されている。ＴＣＰは、ネットワークの利用可能帯域にあわせて、パケットの送出量を調整する輻輳制御機構を有しているが、前述のＲＴＰに代表されるＵＤＰ系のプロトコルは、それ自体にはＴＣＰのような輻輳制御機構が無い。
【０００６】
そのため、場合によってはＲＴＰのトラフィックが原因でネットワークに輻輳状態を引き起こし、ＴＣＰ系のプロトコルによるトラフィックを阻害してしまうことがある。そこで近年、ＴＣＰと公平な通信を実現するためのレート制御方法の研究／開発において TCP-friendly という概念が注目されている。
【０００７】
TCP-friendly は、「同一ネットワークパス上における非ＴＣＰコネクションとＴＣＰコネクションのスループットが等しいこと」と定義されている。TCP-friendly に基づくレート制御は、ＴＦＲＣ(TCP-Friendly Rate Control)と呼ばれている。これは、輻輳などのネットワークの状態に応じてデータ送出量を自律的に調整することにより、ＴＣＰコネクションと公平にネットワーク帯域を共有する通信を実現するものである。
【０００８】
ＴＦＲＣの実現方法として知られている方法の１つに、ＴＣＰの輻輳制御機構で用いられているＡＩＭＤ(Additive Increase Multiplicative Decrease)型のウィンドウフロー制御を適用する方法がある。しかし、ＡＩＭＤ型のフロー制御はＲＴＴ(Round Trip Time)程度の比較的短いタイムスケールで、送信するパケット数を変動させる方法によるものであるため、送信レートの変動が激しい。
【０００９】
よって、ＡＩＭＤ型の制御は、ＲＴＰを用いて動画像データをリアルタイムに送信するなどの用途に使用するには、送信レートの変動が激しいことが大きな問題となる。そこで、ネットワークの使用可能帯域を算出して目標ビットレートとすることで、送信レートの変動を抑えることの出来るＴＦＲＣの制御方法が知られており、これは、ＩＥＴＦによりＲＦＣ3448として定義されている。
【００１０】
これは、一般にＴＣＰのスループット方程式として知られている「数１」に示す方程式により、ネットワークの使用可能帯域を算出するものである。
【００１１】
【数１】
2010041326.tif 000003
【００１２】
「数１」の方程式において、ＴTCPは算出すべきネットワーク使用可能帯域、ＭＴＵ(Maximum Transfer Unit)は送出パケットの最大サイズである。また、ＴoはＴＣＰの受信確認(Ack)が帰ってくるまでの最大待ち時間となるタイムアウト時間であり、ｐは１ＲＴＴ内のパケット棄却率を示している。ここで、パケット棄却とは、受信バッファに格納したパケットを捨てるなど、受信待ち状態に戻すことである。
【００１３】
「数１」で示した方程式３０１は、さらに簡略化した方程式３０２として使用される場合もある。すなわち、この方程式３０１により使用可能帯域を算出してＴＦＲＣを行うには、ＲＴＴとパケット棄却率を取得することが必要となる。
【００１４】
従来技術として、例えば、特許文献１においては、ＲＴＴの変化量からネットワークの輻輳状態を判定し、その判定結果に基づいて、FECパケットの数を制御する技術が提案されている。また、特許文献２においては、符号化ビット長からパケット数を算出し、FECパケットの検査シンボル数を決定する技術が提案されている。
【００１５】
【特許文献１】特開２００５―１７５８３７号公報
【特許文献２】特開２００５―３４７９２７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
これらの制御方法は、パケット棄却が発生することを前提とした制御方法であるため、パケット棄却が発生した場合に再生画像品質への影響が大きな問題となっている。
本発明は前述の問題点に鑑み、パケット棄却が発生した場合に再生画像品質への影響を少なくできるようにすることを目的としている。
【課題を解決するための手段】
【００１７】
本発明のデータ送信装置は、ネットワークを介して動画像データを受信装置に送信するデータ送信装置であって、前記動画像データの符号量が目標符号量となるように制御する符号量制御手段と、前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御手段と、前記レート制御手段で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化手段とを備えることを特徴とする。
【００１８】
本発明のデータ受信装置は、ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出手段と、前記伝送エラー検出手段により検出された伝送エラーの情報を送信装置に通知する伝送エラー通知手段とを備えることを特徴とする。
【００１９】
本発明のデータ送受信システムは、前記に記載のデータ送信装置と、前記に記載のデータ受信装置とを備えることを特徴とする。
【００２０】
本発明のデータ送信方法は、ネットワークを介して動画像データを受信装置に送信するデータ送信方法であって、前記動画像データの符号量が目標符号量となるように制御する符号量制御工程と、前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御工程と、前記レート制御工程で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化工程とを備えることを特徴とする。
【００２１】
本発明のデータ受信方法は、ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出工程と、前記工程において検出された伝送エラーの情報を送信装置に通知する伝送エラー通知工程とを備えることを特徴とする。
【００２２】
本発明のコンピュータプログラムは、ネットワークを介して動画像データを受信装置に送信するデータ送信方法の各工程をコンピュータに実行させるコンピュータプログラムであって、前記動画像データの符号量が目標符号量となるように制御する符号量制御工程と、前記受信装置から送信されるエラー情報に基づいて、所定の時間毎に送信するパケット数を制御して、送信ビットレートを決定する送信レート制御工程と、前記レート制御工程で決定された、前記所定の時間内に送信するパケットの数に基づいて、前記動画像データを所定の冗長度で誤り訂正符号に符号化する誤り訂正符号化工程とをコンピュータに実行させることを特徴とする。
また、本発明のコンピュータプログラムの他の特徴とするところは、ネットワークを介して受信したパケットから伝送経路における伝送エラーを検出する伝送エラー検出工程と、前記工程において検出された伝送エラーの情報を送信装置に通知する伝送エラー通知工程とをコンピュータに実行させることを特徴とする。
【発明の効果】
【００２３】
本発明によれば、レート制御に伴って、パケットロスなどの通信エラーが予測される時点の誤り訂正符号の冗長度を動的に高めることができ、送信レートの平均値を無駄に高めることをなくすことができる。これにより、誤り訂正を効率良く行うことが可能となり、パケット棄却の影響を少なくすることができる。
【発明を実施するための最良の形態】
【００２４】
（第１の実施形態）
本発明による第１の実施形態として、ＡＩＭＤ型の制御方法を用いたＴＦＲＣ制御に対して、本発明を適用した動画像データ送信装置について説明する。
まず、図１を参照しながら本実施形態の動画像データ送信装置の構成例を説明する。図１は、本発明の実施に好適な装置における動画像データ送信装置の本発明にかかわる部分の基本構成を示すブロック図である。
【００２５】
図１に示すように、本実施形態の動画像データ送信装置１００は、装置全体の動作を制御する制御部１０、動画像データを符号化する符号化部１０１、符号化されたデータからＲＴＰパケットを生成するＲＴＰパケット生成部１０２を有する。また、生成されたＲＴＰパケットから、ＦＥＣ(Forward Error Correction)パケットを生成するＦＥＣパケット生成部１０３を有する。また、ＦＥＣパケット生成部１０３において生成されたＲＴＰパケット及びＦＥＣパケットは、パケット送信バッファ（記憶装置）１０４に保管される。このパケット保管は、パケット送受信部１０６から伝送経路１０７に送信されるまでの間における一時的な保管である。このパケット送信バッファ１０４に保管されているデータ量は、所定の時間内に送信するパケット数の制御に用いられる。
【００２６】
さらに、本実施形態の動画像データ送信装置１００は、各パケットの送信タイミングの制御とバッファ状態の監視を行うスケジューリング部１０５、伝送経路１０７とのパケットの送受信を行うパケット送受信部１０６を有する。また、後述する動画像データ受信装置２００からパケットの再送要求があった場合に、再送要求されたパケットの再送を指示する再送制御部１０８を有する。また、スケジューリング部１０５から通知される送信バッファの情報などから目標ビットレートを算出し、符号化部１０１に通知するビットレート制御部１０９を有する。
【００２７】
ここで、ＦＥＣ(Forward Error Correction)とは、受信側でパケットの廃棄や誤りを検出した時に、本来送信すべき動画像データに付加した冗長データを用いて誤り訂正符号化を行い、パケットを復元する通信の技術である。このために、動画像データ送信装置１００においては、受信側で行う伝送エラー検出・訂正処理のために最低限必要となる冗長なデータを動画像データに付加する。これにより、伝送エラー（通信エラー）が発生したパケットを再送せずに、受信側で復元することが可能となる。
【００２８】
ＦＥＣの種類には、情報ビット列をブロックに区切り、ブロック毎に符号化するブロック符号化と、各ブロックの符号化がそれ以前のブロックに依存する畳み込み符号化がある。その中でも、よく知られている符号化方法は、ブロック符号化に属する、パリティ(ＸＯＲ)符号、ＢＣＨ符号、リードソロモン符号等が挙げられる。
【００２９】
本実施形態における図１に示す動画像データ送信装置１００の構成は、パリティ(ＸＯＲ)符号の方法に適したものである。本実施形態の動画像データ送信装置１００にパリティ(ＸＯＲ)符号を用いた場合は、ＦＥＣパケット生成部１０３では、ＲＴＰパケットからＸＯＲ演算（排他的論理輪）により冗長なデータを生成し、ＦＥＣヘッダ及びＲＴＰヘッダを付加したパケットを生成する。
【００３０】
次に、ＡＩＭＤ型のウィンドウフロー制御による輻輳回避の方法について説明する。
ＡＩＭＤ型の制御には、一般に、ＴＣＰ Ｒｅｎｏと呼ばれる制御方法が用いられることが多いため、ここではＴＣＰ Ｒｅｎｏの制御方法を例にして説明する。
【００３１】
図３は、ＴＣＰ Ｒｅｎｏの方法を用いたＡＩＭＤ制御の概要を示す図である。この制御方法では、はじめは徐々に送信レートを上げていく送信レート制御を行う（スロースタート）。また、パケットロスなどによりネットワークの輻輳を検知すると、ウィンドウサイズを小さく（１／２）することで、送信レートを下げる送信レート制御を行って輻輳を回避する。以後、この動作を繰り返すことでネットワークの使用可能帯域に追従したレート制御を行うものである。
【００３２】
ここで、図４を参照しながら、前述のＴＣＰ ＲｅｎｏタイプのＡＩＭＤ制御における、本実施形態の適用例について説明する。
図４は、図３に示したＡＩＭＤ型ウィンドウフロー制御における輻輳回避の詳細を示したものに、本発明の制御方法を適用した概略図である。
【００３３】
図４において、四角（□）は各々一つのパケットを示している。そして、動画像データ受信装置２００との間のＲＴＴ(Round Trip Time)を、スケジューリング部１０５内に設けられているＲＴＴ測定部１０５ａにより測定する。そして、ＲＴＴ測定部１０５ａで測定したＲＴＴ毎に、動画像データ受信装置２００に送信するパケット数を徐々に増加させ、パケットロスを検知するとウィンドウを大きく減少させる動作を繰り返すことを示している。本実施形態では、ＡＩＭＤ制御で生じるパケットロスなどの伝送エラーをＦＥＣにより、所定の時間毎に回復させることを基本とする。
【００３４】
制御方法の詳細を説明すると、図４に示すように、輻輳を検知してウィンドウサイズを下げた時のＦＥＣ冗長度を最低レベルにまで下げ、ウィンドウサイズを増加させると共に、ＦＥＣの冗長度を段階的に上げていくものである。この時、前回パケットロスが発生したウィンドウサイズに達した時のＦＥＣ冗長度が所定の値になるように冗長度を制御するようにしてもよい。
【００３５】
ＦＥＣの冗長度を上げると、送信するパケット数は多くなるが、パケットロスが発生した場合に、欠落したパケットを復元できる可能性が高くなるので、受信側での再生画像の乱れを緩和することが期待できる。さらに、棄却したパケットを再送する場合にも、再送を要するパケット数を少なくすることができる。
【００３６】
＜第２の実施形態＞
次に、本発明の第２の実施形態として、ＴＣＰのスループット方程式を用いたＴＦＲＣ制御について、本発明を適用した場合の実施形態について説明する。
本実施形態において、本発明の効果を発揮するのに好適な動画像データ送信装置の構成は、前述した第１の実施形態における図１と同様の構成でよい。また、本実施形態では、前記スループットの算出には、通信経路でのパケット棄却率（伝送エラー情報）とＲＴＴのうち、少なくとも１つを必要とするため、本実施形態に好適な受信装置は、図２に示すような構成を有する。
【００３７】
図２に示すように、本実施形態の動画像データ受信装置２００は、伝送経路２０６を通してパケットの送受信を行うパケット送受信部２０１と、受信したパケットを格納するパケット受信バッファ２０２を有する。
【００３８】
また、受信したパケットから棄却されたパケットの有無の検出、及び棄却率の算出を行うパケット棄却検出部２０３、棄却されたパケットがあった場合に、受信したパケットから棄却されたパケットの復元を行うパケット復元部２０４を有する。さらに、パケット復元部２０４において棄却パケットの復元ができなかった場合に、動画像データ送信装置１００に伝送エラー通知を行い、パケットの再送を要求する再送要求部２０５から構成されている。本実施形態においては、この伝送エラー通知を、ＲＴＣＰ(RTP Control Protocol)のレシーバーレポートを用いて行っている。
【００３９】
前述した「数１」に示したスループット方程式によって算出したレートを目安に送信レートを制御する場合、例えば、図５のレートの変動を示した概略図に示すように、一般に、ＡＩＭＤ制御と比較してレートの変動を抑えることが可能となる。
【００４０】
しかし、スループット方程式によってスループットを算出するには、「数１」に示すように、少なくともＲＴＴとパケット棄却率が必要となるため、パケット棄却が実際に発生している状況でないとスループットを算出することができない。
【００４１】
また、実際に動画像データを通信するために符号化する場合、一般に、ＭＰＥＧ−２やＭＰＥＧ−４、或いはＭＰＥＧ−４ ＡＶＣ(Ｈ．２６４) を含む符号化方式で符号化することが多い。これらの符号化方式では、当該フレーム内のデータのみで復号が可能なイントラ圧縮によるＩフレームや、時間的に前後のフレームとの差分を抽出して符号化し、圧縮率を上げたＰフレーム或いはＢフレームといういくつかのタイプの異なるフレームが存在する。これらのフレームは前述の圧縮・符号化方法の違いから、一連の動画像データを符号化した時、フレームタイプ毎にサイズが大きく異なる場合がある。
【００４２】
したがって、動画像データをフレーム毎にパケット化してネットワークに送信する場合、フレームのサイズによって、単位時間当たりに送信すべきパケットの数に偏りが出る場合がある。ＴＦＲＣでは、このような場合、ある程度パケットの送信間隔を平均化する方が望ましい。
【００４３】
もちろん、平均化することによって、パケット数が多いフレームでは、規定のフレームレート内でのパケット送信が間に合わない場合もあるので、それが問題になる場合は、受信側装置とのバッファサイズ等の調整が必要になる。さて、本実施形態では、ＴＦＲＣ制御の説明を簡単にするため、フレームタイプの違いによるパケット送信間隔の偏りについては考慮しないものとする。
【００４４】
このような前提において、本実施形態のＴＦＲＣ制御の方法について、図６のフローチャートを参照しながら説明する。
まず、ビットレート制御部１０９において、目標ビットレートを設定する（ステップＳ６０１）。ここで設定する目標ビットレートは、後述するステップＳ６０５で算出される値、またはステップＳ６０９において設定される値を用いて算出する。なお、初回の処理実行時には任意の目標値を読み込むなどして目標ビットレートを設定する。
【００４５】
次に、ステップＳ６０２に進み、符号化部１０１において動画像データの符号化を行う。ステップＳ６０２の符号化処理において行われる符号量制御は、ビットレート制御部１０９において設定された目標ビットレートとなるように、目標符号量が制御される。符号化部１０１で符号化されたデータを、ＲＴＰパケット生成部１０２においてパケット化して、ＲＴＰパケットを生成し、パケット送信バッファ１０４に格納する。
【００４６】
スケジューリング部１０５では、パケット送信バッファ１０４に格納されたパケットを随時監視し、まず単位時間当たりの送信ビットレートを計算する（ステップＳ６０３）。続いて、算出した単位時間当たりの送信ビットレートが、後述するステップＳ６１２で保持されている閾値を超えているか判断する（ステップＳ６０４）。
【００４７】
ここで、閾値が保持されていない場合は判断結果が（Ｎｏ）となり、ステップＳ６０６の処理へ進む。一方、ステップＳ６０４の判断の結果が閾値を越えている場合には、判断の結果が（Ｙｅｓ）となり、ステップＳ６０５の処理へ進む。
【００４８】
ステップＳ６０５では、図７に示すように、単位時間当たりの送信ビットレートが閾値を超えている割合によって、冗長度を決定する。ところで、図７に示す冗長度の数値は、ＦＥＣにパリティ(ＸＯＲ)符号を用いた場合の、１つのＦＥＣパケットを生成する元となるＲＴＰパケットの数を示している。例えば、超過レベルが２０〜３０％の場合は１６個のＲＴＰパケットから１つのＦＥＣパケットを生成することを示している。
【００４９】
ステップＳ６０５の処理をスケジューリング部１０５で行った場合、続いてビットレート制御部１０９において目標ビットレートを算出し（ステップＳ６０１）、算出した目標ビットレートを符号化部１０１に通知する。この時、目標ビットレートは、送信バッファの状態と送信レートの超過レベルを基に算出される。具体的には、パケット送信バッファ１０４に蓄積しているデータ量が多いほど目標ビットレートは高く設定し、一方、超過レベルが高いほど、目標ビットレートは低くなるように設定する。
【００５０】
次に、ステップＳ６０５、またはステップＳ６０６において設定されたＦＥＣ冗長度に従って、ＦＥＣパケット生成部１０３においてＦＥＣパケットを生成し（ステップＳ６０７）、パケット送信バッファ１０４に格納する。
【００５１】
パケット送信バッファ１０４に格納されたＲＴＰパケットとＦＥＣパケットは、スケジューリング部１０５からの指示により、パケット送受信部１０６に送られ、伝送経路１０７に送信される（ステップＳ６０８）。伝送経路１０７に送信されたパケットは、伝送経路２０６から動画像データ受信装置２００のパケット送受信部２０１により受信され、パケット受信バッファ２０２に一旦蓄積される。次に、パケット棄却検出部２０３において、通信経路でのパケット棄却の検出を行い（ステップＳ６０９）、続いてパケット棄却率の算出を行う。
【００５２】
ステップＳ６０９においてパケット棄却が検出された場合（Ｙｅｓ）、パケット送受信部２０１は、パケット棄却検出部２０３で算出されたパケット棄却率を、伝送経路２０６を介して動画像データ送信装置１００に通知する。
【００５３】
動画像データ送信装置１００のスケジューリング部１０５では、通知されたパケット棄却率、及びその時点でのＲＴＴを基にスループット方程式（「数１」）を用いて、スループットの算出を行う（ステップＳ６１０）。
【００５４】
次に、算出したスループットの値から、送信レートと比較する閾値を算出する（ステップＳ６１１）。この時、閾値を算出する最も簡単な方法は、数２の計算式のように、スループットに所定の係数を乗算する方法である。
【００５５】
【数２】
2010041326.tif 000004
【００５６】
数２において、係数ｋthは具体的には、０．５から０．９程度の値であり、閾値はスループット値より小さな値となるようにする。
【００５７】
一方、ステップＳ６０９においてパケット棄却が検出されなかった場合（Ｎｏ）もパケット棄却が検出された場合と同様に、伝送経路を介して動画像データ送信装置１００へ通知する。そして、スケジューリング部１０５において処理されるステップＳ６０１において、目標ビットレートを算出する。
【００５８】
この時の目標ビットレートを算出する最も簡単な方法は、数３の計算式のように、その時点で設定されている目標ビットレートＲpreに、所定の係数ｋtgを乗算する方法である。
【００５９】
【数３】
2010041326.tif 000005
【００６０】
数３において、係数ｋtgは具体的には、１．１から１．５程度の値であり、目標ビットレートＲpreは、元の値よりもやや大きい値に更新されることになる。また、目標ビットレートＲpreは、符号化部１０１に初期値が与えられている場合は、その初期値を超えないように制御してもよい。
【００６１】
ステップＳ６０９において、パケット棄却が検出されなかった場合（Ｎｏ）のもう一つの処理ステップＳ６１３では、「数１」のスループット方程式を用いずに閾値を更新する。この場合の閾値の簡単な算出方法は、ステップＳ６１１の計算方法と同様に、数４に示すような係数の乗算によるものである。
【００６２】
【数４】
2010041326.tif 000006
【００６３】
数４におけるＴpreはその時点で保持されている閾値を示しており、係数ｋthは１．１から１．５程度の値である。つまり、更新後の閾値は更新前の閾値よりも大きい値となる。
【００６４】
以上、図６に示したフローチャートの説明では、処理方法の説明を簡単にするため、閾値や目標ビットレートの算出式を単純な係数の乗算によるものとしたが、より効率や精度を上げるため、統計処理的な数値計算を用いてもよい。
【００６５】
なお、図６のフローチャートにおける処理ルーチンが１周期する時間は、０．５秒から数秒程度である。具体的には、ＲＴＴ、またはＧＯＰ(Group Of Picture)、或いはＧＯＶ(Group Of Video Object Plane)の時間のうち、少なくとも１つの値を整数倍であることが望ましい。
【００６６】
また、前述した実施形態においては、動画像データ送信装置１００と動画像データ受信装置２００とを別々に説明したが、これらの装置を伝送経路１０７及び伝送経路２０６を介して接続することにより、データ送受信システムを構成することができる。
【００６７】
（本発明に係る他の実施の形態）
前述した本発明の実施の形態における動画像データ送信装置を構成する各手段は、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。
【００６８】
また、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施の形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【００６９】
なお、本発明は、前述した動画像データ送信方法における各工程を実行するソフトウェアのプログラム（実施の形態では図６に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【００７０】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００７１】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【００７２】
プログラムを供給するための記録媒体としては種々の記録媒体を使用することができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【００７３】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【００７４】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００７５】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００７６】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施の形態の機能が実現される他、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行うことによっても前述した実施の形態の機能が実現され得る。
【００７７】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施の形態の機能が実現される。
【図面の簡単な説明】
【００７８】
【図１】本発明の第１の実施形態を示し、動画像データ送信装置の基本構成例を説明するブロック図である。
【図２】本発明の第２の実施形態を示し、動画像データ受信装置の基本構成例を説明するブロック図である。
【図３】本発明の第１の実施形態を示し、ＴＣＰ Ｒｅｎｏの方法を用いたＡＩＭＤ制御の概要を示す図である。
【図４】本発明の第１の実施形態を示し、ＡＩＭＤ型のウィンドウフロー制御に、実施形態の制御方法を適用した概略を説明する図である。
【図５】本発明の第２の実施形態を示し、スループット方程式によって算出したレートを目安に送信レートを制御した場合のレートの変動を示した概略図である。
【図６】本発明の第２の実施形態を示し、ＴＦＲＣ制御の方法の一例を説明するフローチャートである。
【図７】本発明の第２の実施形態を示し、単位時間当たりの送信ビットレートが閾値を超えている割合（超過レベル）による冗長度の設定値を説明する図である。
【符号の説明】
【００７９】
１０  制御部
１００  動画像データ送信装置
１０１  符号化部
１０２  ＲＴＰパケット生成部
１０３  ＦＥＣパケット生成部
１０４  パケット送信バッファ
１０５  スケジューリング部
１０５ａ  ＲＴＴ測定部
１０６  パケット送受信部
１０７  伝送経路
１０８  再送制御部
１０９  ビットレート制御部
２００  動画像データ受信装置
２０１  パケット送受信部
２０２  パケット受信バッファ
２０３  パケット棄却検出部
２０４  パケット復元部
２０５  再送要求部
２０６  伝送経路
【図１】
2010041326.tif 000007
【図２】
2010041326.tif 000008
【図３】
2010041326.tif 000009
【図４】
2010041326.tif 000010
【図５】
2010041326.tif 000011
【図６】
2010041326.tif 000012
【図７】
2010041326.tif 000013