輻輳回避と共に損失パケット回復を行うシステム及び方法
【課題】損失パケット回復と輻輳回避とを統合することを目的とする。
【解決手段】パケット交換ネットワークでメディア会議を行うときに、損失パケットを克服して輻輳を回避する装置及び技術が記載される。損失パケットの問題を回避するために、受信機が冗長情報から何らかの損失パケットを再構成することを可能にする冗長情報がメディアストリームに挿入される。輻輳回避技術は、メディアストリームのビットレートを調整し、輻輳によるパケット損失のないサポート可能な最高のビットレートを見つけることを含む。ビットレートを高いレートに増加させるときに、更なるビットは、損失パケットの回復に使用される冗長情報から生じ、これにより、ネットワーク輻輳により生じた何らかの損失パケットはビットストリームに悪影響を及ぼさない。
【解決手段】パケット交換ネットワークでメディア会議を行うときに、損失パケットを克服して輻輳を回避する装置及び技術が記載される。損失パケットの問題を回避するために、受信機が冗長情報から何らかの損失パケットを再構成することを可能にする冗長情報がメディアストリームに挿入される。輻輳回避技術は、メディアストリームのビットレートを調整し、輻輳によるパケット損失のないサポート可能な最高のビットレートを見つけることを含む。ビットレートを高いレートに増加させるときに、更なるビットは、損失パケットの回復に使用される冗長情報から生じ、これにより、ネットワーク輻輳により生じた何らかの損失パケットはビットストリームに悪影響を及ぼさない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、輻輳回避と共に損失パケット回復を行うシステム及び方法に関する。
【背景技術】
【０００２】
ますます、テレビ会議システムは、回線交換ネットワーク（PSTN及びISDN等）ではなく、パケット交換ネットワーク（インターネット等）を使用し始めてきている。テレビ会議にパケット交換ネットワークを使用することでの１つの問題は、全てのパケット交換ネットワークが或る程度のパケット損失を受けるという点にある。控えめなパケット損失であっても、ビデオ品質はかなり損なわれる。
【０００３】
パケット損失の問題に対する既存の対策は、様々な誤り隠蔽技術と画像リフレッシュ機構とを使用することを含む。有用ではあるが、これらの技術はしばしば不十分である。これらは、頻繁に特定のビデオコーデックと統合されており、これらの技術がコーデック技術の進展毎に改革されることを必要とする。
【０００４】
典型的には、パケット交換ネットワークは、少なくとも２つの基本的な種類のパケット損失を有する。ネットワークのレイヤ1及び2が回復されない情報を損失したときに、物理的損失が生じ得る。例えば無線リンク（例えば、802.11a、802.11b、802.11g及び802.11nのようなWiFiネットワーク）が使用されるときに、この種類の損失は一般的である。しかし、有線及び光ファイバリンクでも物理レイヤの損失が生じ得る。第２の種類のパケット損失は、ネットワーク輻輳から生じ得る。
【０００５】
この第２の種類のパケット損失を克服するために、或るテレビ会議装置は、様々な輻輳回避技術を使用している。１つのこのような技術は、2002年11月26日に出願された“System and Method for Dynamic Bandwidth Allocation for Videoconferencing in Lossy Packet Switched Systems”という題の米国特許出願10/305,485号に記載されている。この特許出願の全ての内容を援用する。このような技術は、“動的帯域割り当て（Dynamic Bandwidth Allocation）”又は“DBA”と呼ばれることがある。これらの種類のDBAアルゴリズムは、帯域を増加使用とすると常にパケット損失を取り込むという本質的なリスクがある。このことは、損なわれた媒体という結果になり得る。他の種類の輻輳回避技術は、VCONのPacketAsssistと、損失パケット回復又は輻輳制御に関する他の標準とを含む。例えば、RFC2733は、XOR（パリティ）パケットを使用する損失パケット回復方法を提供する。RFC3448は、RFC4340と同様に、ユニキャスト輻輳制御方法を提供する。
【０００６】
更に、前方消失訂正（forward erasure correction）及び前方誤り訂正（forward error correction）のような損失データ回復技術が、ネットワークのレイヤ1及び2で使用され得る。これらの技術もまた、RAIDディスク及びCDROM/DVDのような記憶媒体で使用されている。近年、3GPPは前方誤り訂正を標準化した。前方誤り訂正はまた、H.320を介して送信されるビデオストリームにも提供され得る。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願10/305,485号
【非特許文献】
【０００８】
【非特許文献１】RFC2733
【非特許文献２】RFC3448
【発明の概要】
【発明が解決しようとする課題】
【０００９】
これまで、（例えば前方消失訂正を使用した）損失パケット回復と輻輳回避とを統合する実現は行われていない。このような統合を含むアルゴリズムを記載する。
【課題を解決するための手段】
【００１０】
一態様では、本発明は、損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法に関する。この方法は、損失パケット回復アルゴリズムをメディアストリームに適用することを含み得る。損失パケット回復アルゴリズムは、メディアストリームを含む送信データストリームに冗長情報を挿入することにより動作し得る。冗長情報は、前方消失訂正及び／又はリードソロモン符号化を使用して生成され得る。この方法は、輻輳回避アルゴリズムを送信データストリームに適用することを更に含み得る。輻輳回避アルゴリズムは、送信データストリームのデータレートを一時的に増加させ、ネットワークが高いデータレートをサポートすることができるか否かを決定することを更に含み得る。データレートは、送信データストリームに挿入される冗長情報の量を増加させることにより、一時的に増加し得る。
【００１１】
本発明はまた、損失のあるネットワークで受信したメディアデータを回復する方法に関し得る。メディアストリームは、データストリームと冗長情報とを有するデータストリームの一部として送信されている。この回復方法は、メディアストリームと冗長情報とを有する複数のパケットを受信し、受信パケットからメディアストリームの損失部分を再構成することを含み得る。
【００１２】
本発明はまた、前述のデータ回復及び輻輳回避を実行するように適合されたテレビ会議装置に関し得る。
【発明の効果】
【００１３】
本発明の実施例によれば、パケット損失を低減することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】パケット損失を防ぐために使用され得る損失パケット回復技術
【図２】特定のパケットが損失してデータが再構成される損失パケット回復技術
【図３】特定のパケットが損失してデータが再構成される損失パケット回復技術
【図４】損失パケット回復エンコーダ
【図５】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図６】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図７】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図８】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図９】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図１０】損失パケット回復デコーダ
【図１１】図１〜１０の損失パケット回復技術、エンコーダ及びデコーダと共に使用され得る輻輳回避アルゴリズムの状態機械
【図１２】図１〜１０による技術、エンコーダ、デコーダ及びアルゴリズムを使用して損失パケット回復と輻輳回避とを使用するエンコーダのデータレート
【発明を実施するための形態】
【００１５】
前方消失訂正と輻輳回避との使用を組み合わせたネットワーク送信で、損失パケットの影響を克服する技術が開示される。これらの技術は、“損失パケット回復（Lost Packet Recovery）”又は“LPR”と呼ばれることがある。
【００１６】
LPRは、損失RTPメディアパケットを回復するスケーラブルな方法である。ここに記載する例はビデオコーデックを対象としているが、メディアに特有ではない。ここに記載するLPR技術はまた、他の種類のRTPメディアストリームを保護するために使用され得る。LPRは、損失メディアパケットの前方消失訂正を提供するために、リードソロモン符号化を使用し、損失メディアパケットの回復を可能にする。
【００１７】
LPRが使用される場合、RTPペイロードは、ほぼ等しいサイズのデータパケットを生成するように再パケット化される。再パケット化されたストリームは、異なるRTPダイナミックペイロード形式（これは割り当てられたメディアペイロード番号と異なる）を使用し、完全にRTPに準拠する。ペイロード特有のヘッダは、元のRTPパケットを再構成するのに十分な情報を含む。LPRは、SSRC及びCSRC情報が回復セット（以下に説明する）の途中で変化しないことを仮定する。タイムスタンプ、シーケンス番号、元のペイロード形式及びマーカ・ビット（marker bit）が完全に回復され、回復されたRTPストリームが復号化可能になることを確保する。
【００１８】
次に、回復パケットは、このRTPストリームに追加される。回復パケットもRTPに準拠する。各回復パケットはまた、保護されたデータパケットを記述するペイロードヘッダを含む。各パケットのRTPペイロードは回復情報を含む。追加された回復パケットの数は、RTCP受信レポートから推定されたチャネル損失率に依存する。約50%のビットレートのオーバーヘッドを有するが、約15%までのチャネル損失率に対応可能である。
【００１９】
LPR保護は、全体メディアのビットレートの一部と考えられない点に留意すべきである。従って、実際に圧縮されたペイロードのみが数えられる。しかし、ネットワーク輻輳を回避するために、総計ビットレートが必要に応じて低減され得る。ネットワーク輻輳は、パケット損失以外に又はパケット損失に加えて望ましくない影響を有し得る点に留意すべきである。例えば、ネットワーク輻輳は、媒体の待ち時間の増加と、接続（シグナリング接続を含む）の劣化を生じ得る。従って、LPRプロトコルは、輻輳回避のための内蔵メッセージを有し得る。１つの適切な輻輳回避アルゴリズムについて以下に詳細に説明するが、様々な輻輳回避アルゴリズムが使用されてもよい。
【００２０】
メディアストリームに適用されるLPRの例について、図１〜３を参照して説明する。ビットレート、パケット損失率、パケットサイズ、データパケット対回復パケットの比等を含むこの例の詳細は、全てが単なる例であり、実装の詳細、チャネル状態等に応じて変化し得る。
【００２１】
2%のパケット損失率を有する300kbpsのビデオチャネルについて検討する。３つのパケット101、102及び103が送信される。(6+2)のLPRモードが使用される。これは、２つの回復パケット104、105が６つのデータパケット106〜111の各グループに挿入され、それぞれ８パケットの回復セットを生成することを意味する。回復パケット104、105は、最大データパケットとほぼ同じサイズであるが、何らかの更なるオーバーヘッドを含む。以下に詳細に説明するように、回復パケットは、６つのデータパケット106〜111のいずれか２つの再生成を可能にする。
【００２２】
300kbpsのチャネル制限内に留まるために、メディアレートは、約220kbpsまで低減可能であり、回復パケットに80kbpsを残す。それぞれの再パケット化されたデータパケットの目標サイズは500バイトになり得る。従って、各回復セットは、約32000ビットの情報を伝達し、これは、300kbpsのチャネルレートで107msの期間を表す。107msの期間は、保護期間と呼ばれる。
【００２３】
各パケット（すなわち、再パケット化されたデータパケット106〜111及び回復パケット104、105）は、通常の40バイトのIP+UDP+RTPヘッダのオーバーヘッドを含む。簡単にするために、このオーバーヘッドは示されていない。しかし、LPR自体に関連するオーバーヘッドが示されている。例えば、“3+420”は、420バイトの元のデータに加えて3バイトのオーバーヘッドがパケットに存在することを示す。回復パケットは100%のオーバーヘッドになる。オーバーヘッドの詳細は、以下に詳細に説明する。
【００２４】
図２は、回復処理を示している。データパケット3及び5（108、111）が損失したことを仮定する。LPRデコーダは、受信した６つのパケット（すなわち、データパケット1、2、4及び6並びに回復パケット1及び2）から再生成パケット201及び202を生成する。損失パケットの再生成は、６つのパケットが受信されるまで生じることができない点に留意すべきである。再生成の後に、元のRTPパケット203〜205がデータパケットから復元される。損失パケットの再生成は、以下に詳細に説明する。
【００２５】
図３は、２つより多くのパケットが損失したときのパケット回復の失敗を示している。この例では、データパケット3及び5と同様に、回復パケット1が損失している。グループのうち５つのみのパケットが受信されたため、パケット再生成は不可能である。LPRデコーダは部分的なパケットを再生成しない。元のパケットが完全に回復できない場合、部分的なパケット情報は破棄される。従って、データパケット1及び2（301、302）の双方が損失したものとして示されている。
【００２６】
図３に示すように、元のデータパケットの全てが回復できない場合、受信側デコーダが全体画像の高速更新を要求することが一般的である。代替として、2006年3月28日に発行された“Dynamic Intra-coded Macroblock Refresh Interval for Video Error Concealment”という題の米国特許7,020,203号に記載のようなウォークアラウンド・リフレッシュ（walk-around refresh）を要求する。この米国特許の全ての内容を援用する。いずれの場合でも、画像を訂正するために必要な時間は、損失したパケットの数の関数ではなく、回復セットの所定数のパケット（この例では２つ）より多くを損失することによりもたらされた失敗の間の平均時間になる。
【００２７】
300kbps及び2%のパケット損失のチャネルで、６つのデータパケットと２つの回復データパケットとの各保護セットが107msのチャネルデータをカバーする所定の例では、失敗の間の平均時間は、約258秒であると計算され得る。高速更新が約2秒を要求することを仮定すると、所与のLPRの例により保護されるチャネルで送信されるビデオは、99%より多くの時間で誤りのないことになる。この保護は、80kbpsの更なるオーバーヘッドをもたらし、これは約30%のチャネルレートになる。
【００２８】
前述のLPRの例の更なる態様は、図４を参照してより良く理解され得る。図４は、LPRエンコーダの実装を示している。この実装の変形も可能である。ビデオエンコーダ401は、ほとんど通常の方法で動作する様々なビデオエンコーダのいずれかでもよい。例えば、ビデオエンコーダは、H.261、H.263、H.264、MPEG-2、又はMPEG-4ビデオ圧縮標準に従って動作し得る。代替として、ビデオエンコーダは、様々な独自仕様のビデオコーディング技術のいずれかに従って動作し得る。
【００２９】
ビデオエンコーダ401の出力は、任意選択の暗号化モジュール402に供給され得る。暗号化モジュール402もまた、様々な既知の種類のいずれかでもよい。暗号化されたビデオデータ（又は暗号化が使用されない場合には暗号化されていないビデオデータ）は、RTP送信機403に供給され得る。RTP送信機403も通常のものでもよい。RTP送信機403により生成されたRTPパケットは、以下に詳細に説明するように、LPRパケット化器406によりLPRアルゴリズムを使用して再パケット化され得る。LPR回復パケット生成器407は、以下に詳細に説明するように、LPRパケット化器406及びビデオエンコーダ401から受信した情報に基づいて回復パケットを生成し得る。LPR回復パケット生成器は、LPRデータパケットとLPR回復パケットとを受信機（図示せず）に送信し得る。
【００３０】
RTCPモジュール404は、パケット損失及び他のチャネル統計を受信し、これらをLPRモード判定モジュール405に供給し得る。LPRモード判定モジュール405はLPRパケット化器406を制御する。LPRモード判定モジュール405は、LPR保護を行うか行わないかを判定し、使用されるLPR保護パラメータを決定し得る。LPR保護が行われない場合、LPRパケット化器406及びLPR回復パケット生成器407は、RTP送信機403により生成されたRTPパケットを、変更せずに通過し得る。
【００３１】
LPRモード判定モジュール405は以下のように動作し得る。まず、（前述の）保護期間が決定され得る。長い保護期間は効率的なパケット再生成（例えば少ない回復kbps）を提供するが、長い待ち時間を生成する。最も典型的なテレビ会議のビットレートでは、100msが適切な保護期間になり得る。128kbpsより小さいビットレートでは、長い保護期間が必要になってもよい。例えば、150msが64kbpsのレートに適する可能性がある。1Mbpsより大きいビットレートでは、短い保護期間が有利なことがある。例えば、50msが2Mbps以上のレートに適する可能性がある。他のパラメータも保護期間を決定する際に検討され得る。
【００３２】
次に、保護期間毎の全パケット数が決定され得る。一般的に、保護期間毎に小さいパケット数は、保護の効率を減少させる傾向になり得る。逆に、保護期間毎に大きいパケット数は、保護パケットをエンコード及びデコードするために必要な計算量を増加させる傾向になり得る。従って、ほとんどのチャネルについて、保護期間毎に約13以上のパケットが適切であると考えられる。保護期間毎のパケット数についての判定は、所望のデータレートに対する結果のパケットサイズも考慮すべきである。出力パケットサイズ（IPオーバーヘッドを含む）は、分割せずにIPSECトンネルを横断するために、1260バイト未満であるべきである。
【００３３】
保護期間毎のパケット数が定められると、保護期間毎の回復パケット数が選択され得る。回復パケット数は、（通常の確率的分析技術を使用して）保護の中断の間の平均時間が所定の規定値を満たす又は超えるように選択され得る。更に、全ての送信されたビデオチャネルの総計（LPR保護パケット及びRTPメッセージを含む）が、指定の輻輳上限を超えないように選択され得る。
【００３４】
以下のテーブルは、様々な損失条件で様々なビットレートに使用され得る例示的な保護モデルを示している。テーブル１は、パケット損失が3%を超えるときにデータレートを低減する輻輳回避アルゴリズム（以下に説明する）と共に使用可能であり、4%のパケット損失条件に適し得るLPRパラメータを示している。テーブル２は、輻輳回避アルゴリズムが使用中でないときに使用され得る2%のパケット損失条件のLPRパラメータを示している。
【００３５】
【表１】
【００３６】
【表２】
LPRパケット化器406は以下のように動作し得る。LPRパケット化器406は、パケット再生成符号化の効率を改善するために、RTP送信機403により生成された元のメディアパケットを細分する。LPRデータパケットは、唯一の発信元パケットからの情報を含む。メディアチャネルが暗号化されている場合、暗号化ストリームでLPR再パケット化が実行され得る。一般的に、LPRストリーム自体は再暗号化されない。すなわち、暗号化パケットと新しく生成されたLPR回復パケットとに追加されたLPRカプセル化フィールド（ヘッダ）は、平文で送信される。
【００３７】
元の発信元パケットが細分される場合（例えば、図１〜３のパケット1 101）、この発信元パケットの最初のLPRデータパケットは初期データパケット（例えば、図１〜３のデータ1 106）と呼ばれる。（存在する場合には）次のデータパケットは、後続データパケット（例えば、図１〜３のデータ2 107及びデータ3 108）と呼ばれる。後続データパケットの数は、初期データパケットで伝達され、従って、初期データパケットが送信されると変更できない。後続データパケット及び初期データパケットは、異なるLPR保護グループに存在してもよい。
【００３８】
シーケンス番号とペイロード形式とPフィールドとを除いて、元のRTPヘッダの全てのフィールドは、各LPRデータパケットで変更されずに伝達され得る。これは、タイムスタンプとマーカ・ビットとSSRC/CSRC情報とを含む。ペイロード番号は、ネゴシエーションされたLPRペイロード形式と交換され得る。シーケンス番号は、通常通りにLPRメディアストリームに連続的に割り当てられ得る。LPRパケットのPフィールドは0に設定され得る。LPRパケット化器406は、元のRTPシーケンス番号をLPR回復パケット生成器407に渡し得る。
【００３９】
各初期データパケットは、LPRに特有の7バイトのペイロードヘッダを含み得る。この例が図５に示されている。各後続データパケットは、3バイトのペイロードヘッダを含み得る。この例が図６に示されている。これらのペイロードヘッダは、RTPヘッダの直後に続き、ビデオ（又は他のメディア）ペイロードに先行し得る。ヘッダサイズ及び個々のフィールドのサイズ並びにこれらの構成は単なる例であり、他の構成も可能であることがわかる。
【００４０】
回復パケットのフィールド501、601は、回復セットで後に送信される回復パケット数を示すために使用され得る。回復セットの全てのデータパケットは、同じ数の回復パケットを伝達するべきである。伝達される回復パケット数は0でもよく、これは回復パケットが送信されないことを示す。このフィールドは6ビットのフィールドでもよく、64の回復パケットまでを許容する。形式のフィールド502、602は、それぞれ初期データパケット又は後続データパケットを示すために、00又は01に設定される2ビットのフィールドセットでもよい。これは、最初のペイロードバイトを検査することにより、LPRのヘッダ形式が決定されることを可能にする。
【００４１】
データインデックスのフィールド503、603は8ビットのフィールドでもよい。回復セットの最初のデータパケットは1のデータインデックスを割り当てられ得る。データインデックスは、そのセットの次のデータパケットでインクリメントされ得る。後続パケットのフィールド504は、初期パケットに関連する後続パケット数を指定するために使用される8ビットのフィールドでもよい。データパケットのフィールド604は、回復セットに含まれるデータパケット数を伝達するために使用される8ビットのフィールドでもよい。全てのデータパケットは、同じ数のデータパケットを伝達するべきである。
【００４２】
元のシーケンスのフィールド505は、元のRTPパケットシーケンス番号を示す16ビットのフィールドでもよい。これは、元のRTPパケットを再生成するために使用される。元のPビットのフィールド506は、元のRTPパケットにより伝達されるパディングビット（padding bit）を伝達するために使用される1ビットのフィールドでもよい。元のペイロード形式のフィールド507は、元のRTPパケットにより伝達されるペイロード形式を伝達するために使用される7ビットのフィールドでもよい。
【００４３】
LPR回復パケット生成器407は、以下のように動作し得る。LPR回復パケット生成器407は、元のメディアのRTPシーケンス番号を、LPRデータパケットの最後のLPRシーケンス番号と交換し得る。LPR回復パケット生成器407はまた、各回復セットの終わりにLPR回復パケットを挿入し得る。
【００４４】
各回復パケットはまた、図７に示すような9バイトのヘッダを含み得る。回復パケットヘッダは、RTPヘッダの直後に続き、ビデオ（又は他のメディア）ペイロードに先行し得る。前述のヘッダと同様に、フィールドの形式及びサイズは例示的であり、他の構成も使用されてもよい。
【００４５】
回復インデックスのフィールド701は、回復セットの回復パケットのシーケンスを示すために使用される6ビットのフィールドでもよい。最初の回復パケットは、1の回復インデックスを割り当てられ得る。回復インデックスは、回復セットの次の回復パケットでインクリメントされ得る。形式のフィールド702は、パケットが回復パケットであることを示すために、10に設定される2ビットのフィールドでもよい。回復パケットのフィールドは、回復セットのデータパケット数を含む8ビットのフィールドでもよい。全ての回復パケットは、対応するデータパケットにより伝達された同じ数の回復パケットを伝達するべきである。データパケットのフィールド704は、回復セットで送信されるデータパケット数を示す8ビットのフィールドでもよい。回復パケットは、対応するデータパケットで示された同じ数のデータパケットを示すべきである。
【００４６】
保護タイムスタンプのフィールド705は、回復セットの各データパケットのリードソロモン符号化されたRTPタイムスタンプを保持する32ビットのフィールドでもよい。これは、回復ペイロード自体で使用されるものと同じリードソロモン符号化を使用して結合され得る。このフィールドにより、損失データパケットのRTPタイムスタンプが再生成されることが可能になる。4バイトはネットワークの指示（in network order）である。
【００４７】
保護マーカ、フラグ及びサイズのフィールド706（図８に更に示す）は、リードソロモン符号化されたRTPマーカ・ビット802、フラグ値801及びデータパケットサイズ803を保有し得る。フラグ値は、LPRデータパケットが初期パケットである場合に1になってもよく、LPRデータパケットが後続パケットである場合に0に設定されてもよい。サイズは、LPRヘッダと同様にIP、UDP及びRTPヘッダを含み得る。データパケットサイズはネットワークの指示でもよい。
【００４８】
保護フィールドは、回復ペイロード自体で使用されたものと同じリードソロモン符号化を使用して結合される。このフィールドにより、回復可能な何らかの損失データパケットについて、LPRヘッダ形式、マーカ及びデータパケットサイズが再生成されることが可能になる。
【００４９】
回復パケットのペイロードは、リードソロモン256（RS256）符号化を使用して符号化され得る。初期データパケットの元のシーケンス505、元のPビット506、元のペイロード形式507及び後続パケット504のフィールドは、ペイロードバイトであるかのように保護され得る。これにより、初期データパケットが損失した場合に、この情報が回復可能になる。更に、回復パケットのペイロードヘッダは、３つのファントムデータ（Phantom Data）のフィールド（データパケット自体の長さ、マーカ・ビット及びタイムスタンプ）の符号化を含み得る。この場合も同様に、これにより、細分されたRTPパケットの全てのデータパケットが損失した場合に、この情報が回復可能になる。
【００５０】
各データパケットの各ペイロードバイトは、以下のRS256の生成関数に従って、各回復パケットの対応するバイトに寄与し得る。
【００５１】
【数１】
ただし、Diは第iのデータパケット（1≦i≦d）であり、Rjは第jの回復パケット（1≦j≦r）であり、Biはテーブル３に示す値を有する第iの基礎係数（1≦i≦d）であり、
【００５２】
【数２】
は以下に示すGガロア域（28）算術演算を使用して計算される。所与の基礎係数のテーブルは、回復セットの最大データパケット数を128に制限するが、他のデータパケット数が選択可能であり、それに従って適切なテーブルが計算され得る点に留意すべきである。
【００５３】
【表３】
ガロア域（28）算術演算は、２つの補助テーブル（ガロア・ログ関数（glog）テーブル及びガロア指数関数（gexp）テーブル）を使用して設定され得る。これらのテーブルは以下の通りである。
【００５４】
【表４】
【００５５】
【表５】
これらのテーブルは、以下に説明する様々な算術演算を計算するために使用され得る。
【００５６】
ガロア域（28）の加算及び減算は同じ演算であり、以下のように実行される。
【００５７】
【数３】
ただし、^は排他的論理和又はXOR演算である。通常の演算と同様に、次のようになる。
【００５８】
【数４】
ガロア域（28）の乗算は以下のように実行される。
【００５９】
【数５】
ただし、+は通常の加算演算である。通常の演算と同様に、次のようになる。
【００６０】
【数６】
また、次のようになる。
【００６１】
【数７】
ガロア域（28）の除算（a÷b）は以下のように実行される。
a÷b=gexp[glog[a]-glog[b]+255]
ただし、+は通常の加算演算であり、-は通常の減算演算である。通常の演算と同様に、a÷1=aである。また、通常通り、bは0ではない。
【００６２】
ガロア域（28）のべき乗関数（ab）は以下のように実行される。
ab=gexp[(glog[a]*b)%0xFF]
ただし、+は通常の加算演算であり、-は通常の減算演算であり、*は通常の乗算演算であり、%は通常のmod関数である。通常の演算と同様に、0でないaについてa0=1である。RS256参照コードでは、0は決してべき乗にならない。
【００６３】
前述のように、（パケットの）LPRグループサイズは、所望の保護期間（ミリ秒）を実現するように設定され得る。ビデオコーデックが全チャネルビットレートを使用しない場合、LPRグループは長い待ち時間を生じる。例えば、通常では1.5Mbpsで動作するビデオチャネルは、軽い動作期間に（in periods of light motion）750kbpsに低下し得る。これは、所望の２倍の長さの保護期間を生じる。このような状況は、選択されたLPRモードが所定のMTBFを満たし続けることを生じ得る。この例では、2の係数だけ所定のMTBFを超える。
【００６４】
或る場合には、この拡張保護期間が許容され得る。しかし、パケットが損失した場合に、これは長い待ち時間を生じ得る。従って、或る場合には、実際のビデオレートが変化するときに、送信機がそのLPRモードを調整することが望ましいことがある。３つのこのような調整について以下に説明するが、他の調整も可能である。
【００６５】
行うことができる１つの調整は、保護グループサイズに対するものである。或る実施例では、この設定は、各保護グループの境界で変更され得る。従って、送信機は、LPR出力パケットレートを監視し、グループ毎のパケット数を動的に適合させ得る。この調整が使用される場合、データレートが下がると、LPR保護オーバーヘッドは上がる傾向になる。しかし、このような場合のデータレートは一般的に通常の制限より小さいため、変更されたLPRモードは、一般的に依然として所定の輻輳上限の下に留まる。
【００６６】
行うことができる他の調整は、送信機が初期データパケットの送信時にその出力パケットサイズを変更することである。典型的には後続パケット数が初期データパケットで伝達されているため、一般的に、送信機は、後続パケットを送信するときに出力パケットサイズを変更するべきでない。従って、送信機は、LPR出力パケットレートと出力データレートとを監視し、保護期間毎のパケット数を維持するようにパケットサイズを動的に適合させ得る。
【００６７】
行うことができる他の調整は、送信機が空のデータパケットを送信して部分的な回復セットを完了することである。空のデータパケットは、前述の初期データパケットヘッダを含み得る。パケットに通常存在する他の情報（シーケンス番号、ペイロード形式、後続パケット数等）は、全て0に設定され得る。空のデータパケットは保護グループの一部であるため、前述の回復パケットの符号化はこれらのパケットを含み得る。これらのパケットはまた、デコード処理により回復可能である。また、空のデータパケットは、出力メディアパケットストリームの空のパケットを回避するために、LPRデコーダ（以下に説明する）により破棄され得る。
【００６８】
詰め込まれたパケット（fill packet）は、所定のデータレートを維持するために使用され得る。これらの詰め込まれたパケットは、受信機により破棄され得る。例示的な詰め込まれたパケットが図９に示されている。詰め込まれたパケットは、1の値を有する6ビットの拡張形式のフィールド901と、11の値を有する2ビットの形式のフィールド902とを含み得る。詰め込まれたパケットは、メディアストリームのLPRペイロード形式を使用したRTPパケットでもよい。タイムスタンプの値は、前に送信されたRTPパケットの値と同じでもよい。シーケンス番号は、前に送信されたパケットの値からインクリメントされてもよい。ペイロードは、前述の詰め込まれたヘッダで終了し得る。フィールドのペイロード長は、最大の指定パケットサイズ内で如何なる長さでもよい。
【００６９】
LPRデコーダの例が図１０に示されている。前述のLPRエンコーダと同様に、この実施例の変形も可能である。LPRデコーダの動作は、基本的に前述のLPRエンコーダの逆になり得る。具体的には、LPRパケットは、LPR回復モジュール1001により回復され得る。これらの回復されたLPRパケットは、RTP並び替えバッファ1002に渡され、RTP並び替えバッファは、通常のシステムと同様に、パケットを受信順に並び替え得る。LPR再生成器1003は、（LPR回復ブロック1001から）回復されたLPRパケットから受信した情報と、RTPCモジュール1006から受信したRTCP情報とに基づいて、何らかの損失パケットを再生成し得る。これらの再生成されたブロックは、（暗号化が発信元で使用されている場合）復号化ブロック1004により復号化され得る。最後に、復号化されたブロックがビデオデコーダ1005（又は必要に応じて他の種類のメディアエンコーダ）により処理され得る。
【００７０】
LPR回復モジュール1001及びLPR再生成器1003のみは、通常のシステムと比べて非標準の要素でもよく、これらの２つのモジュールはLPRが使用されないときにパススルー（pass-through）として動作し得る。
【００７１】
LPR回復モジュール1001は、全てのLPR RTPパケットを処理し得る。所与の例では、受信して再生成された全てのパケット（データ及び回復）は、直接にRTP並び替えバッファに渡され得る。各データパケットのオーバーヘッドデータにより、これらのパケットが何らかの順序でLPR回復モジュール1001により処理されることが可能になる。LPR回復モジュール1001はまた、LPR RTP受信レポート情報をRTCPモジュール1006に提供し得る。この情報は、何が受信されたかに基づいてもよい（例えば、受信されていない何らかのパケットが受信レポートで損失として特定され得る）。
【００７２】
回復可能な回復セットに損失データパケットが存在する場合、十分な回復パケットが受信されるとすぐに、LPR回復モジュールはこれらのパケットを回復し得る。前述のように、kのデータパケットが損失している場合、データを回復するためにkの回復パケットが受信されなければならない。この回復処理は、まず、マーカ・ビットと、データパケット長と、初期パケットフラグと、元のタイムスタンプとを回復することを含み得る。データパケット長は、元のデータパケットのペイロードを回復するために使用され得る。LPR RTPヘッダの“固定”の構成要素（例えば、SSRC、CSRC、LPRペイロード形式等）は、１つの回復パケットから採用され得る。LPR RTPヘッダの様々な部分（例えば、マーカ・ビット、タイムスタンプ及びシーケンス番号）は、回復ヘッダから回復された値に設定され得る。
【００７３】
LPRデータパケットiのシーケンス番号は以下の式に従って計算され得る。
Si=Sr-(d+r-i)
ただし、iは回復データパケットのインデックスであり、dは回復セットのデータパケット数であり、rは受信した回復パケットのインデックスであり、Siはパケットiのシーケンス番号である。
【００７４】
データパケットを受信する間に、前述のRS256生成関数を使用して、部分的な回復パケットが回復モジュール1001により構築され得る。そのセットの対応する回復パケットが受信されると、これらのパケットは、部分的な回復パケットと排他的論理和（XOR）され得る。結果の残りのパケットは、各回復パケットへの何らかの損失データパケットの寄与を保持する。例示的なシステムでは、それぞれの残りのパケットは、損失データパケットのそれぞれの線形結合である。従って、kの連立方程式（kの残りのパケットのそれぞれに１つ）が存在し、それぞれkの未知数（損失したkのデータパケットのそれぞれに１つ）が存在する。
【００７５】
当業者にわかるように、これらの式はk×kの行列として表され得る。k×kの行列は、例えばガウス消去法により数学的に解決され得る。このような演算は周知であるため、詳細はここでは説明しない。残りのデータで結果の逆行列を乗算することにより、損失データパケットを回復することができる。
【００７６】
前述の回復処理を示すために、図２の回復シナリオが実行され得る。明瞭にするために、実際のガロア域（28）の演算ではなく、通常の算術演算が使用される。回復パケットのデータは、以下の式（前述のRS256生成関数及びテーブルから導かれる）を使用して生成され得る。
R1=D1+D2+D3+D4+D5+D6
R2=2D1+4D2+6D3+9D4+13D5+14D6
部分的な回復パケットは、受信したパケットでデコーダにより計算され得る。前述の例で記載したように、パケット3及び4（図３の108、110）は受信されない。その結果、以下のようになる。
P1=D1+D2+D5+D6
P2=2D1+4D2+13D5+14D6
残りは、受信した回復パケットから部分的な回復パケットを減算することにより計算され得る。
r1=R1-P1=D3+D4
r2=R2-P2=6D3+9D4
従って、残りの生成行列は以下のようになる。
【００７７】
【数８】
ガウス消去法を介してこの行列を逆にすると、以下の結果になる。
【００７８】
【数９】
従って、損失データパケット（すなわち、データパケット3及び4）の情報は、以下の式を使用して回復され得る。
D3=3r1-r2/3
D4=-2r1+r2/3
LPRが使用中である場合、RTP並び替えバッファ1002はLPRデコーダと統合され得る。或る状況では、パケットが実際に到達する前に順序の狂ったパケットがLPRにより再生成され得るため、これは最小遅延の実装を可能にする。更に、或る実施例では、何らかのデータパケットが損失した場合にのみリードソロモンデコーダを動作して、回復セットの最初のdのパケットを取得することが望ましいことがある。この設計は最小の遅延を生じないことがあるが、計算効率が良くなり得る。
【００７９】
LPR再生成モジュール1003は、前述のように、データパケットから元のRTPストリームを再生成し得る。RTPパケットの何らかのデータパケットが損失している場合、そのRTPパケットは出力ストリームから省略される。LPRストリームは並び替えられているため、各パケットからの初期パケットが最初に受信されるべきである。後続パケットが最初に直面する場合、初期パケットが損失しており、後続パケットが破棄され得る。
【００８０】
出力RTPパケットは、初期データパケットのRTPヘッダ情報を使用する。ペイロード形式、シーケンス番号及びタイムスタンプは、初期データヘッダの値と交換される。ペイロードは、LPRヘッダが取り除かれて、初期データパケットと何らかの後続データパケットとから集められる。何らかの後続パケットが損失している場合、出力RTPパケットが抑制され得る。後続パケット数は初期データパケットのヘッダで伝達され得るため、既知でもよい点に留意すべきである。
【００８１】
前述のような損失パケット回復技術は、更に動作を拡張するために、輻輳回避アルゴリズムと結合され得る。例示的な輻輳回避アルゴリズムは前述の通りであり、動的帯域割り当て（DBA：Dynamic Bandwidth Allocation）と呼ばれる。DBAは、受信機のRTPスタック（図１０の1006）により報告されたパケット損失率に基づいてビットレートを下げることにより、輻輳を回避しようとし得る。受信機のRTPスタックは、一定の期間中（例えば毎200ms）の受信機のチャネルのパケット損失統計を生成する。これは、低いMTBF要件を有する最小のLPR構成を可能にしつつ、動的に変化するパイプへの高速な適合を可能にする（次に、これは低いオーバーヘッドを可能にする）。
【００８２】
図１１に示すように、DBAの制御ループは、最大レート状態1101と、速度低下状態1102と、速度上昇待機状態1103と、速度上昇状態1104と、常時損失状態1105とを有する状態機械として実現され得る。様々な状態遷移は以下のようになることがわかる。システムが最大レート状態1101（最大データレートが使用されていることを意味する）であることを仮定する。所定の閾値より大きいパケット損失は、速度低下状態1102への状態遷移1106を生じ得る。
【００８３】
速度低下状態において、システムは速度を減少させ、所定の閾値より大きいパケット損失を受け続けるか否かを検出するために待機する。閾値より大きいパケット損失が存在しない場合、システムは、速度上昇待機状態への遷移1108に従い得る。閾値より大きいパケット損失が存在し続け、最大数の速度低下の試行が使用されていない場合（ブロック1107）、システムは速度低下状態1102を続け、従って、ビットレートを減少させ続け得る。最大数の速度低下の試行が使用された場合、システムは常時損失状態1105に遷移する。
【００８４】
速度上昇待機状態において、所定の閾値より大きい更なるパケット損失は、システムを速度低下状態への遷移1109に従わせ得る。代替として、所定の期間の後に閾値より大きいパケット損失が存在しない場合、システムは、速度上昇状態1104への遷移1110に従い得る。
【００８５】
速度上昇状態1104において、システムは、ビットレートを増加させ、所定の閾値より大きい更なるパケット損失を待機し得る。パケット損失が存在しない場合、システムは、ビットレートが最大ビットレートより小さいか否かを決定し得る。小さい場合、システムは最大レート状態1101への遷移1111に従い得る。小さくない場合、システムは速度上昇状態1104を続け得る。速度上昇状態1104の間に所定の閾値より大きいパケット損失を受ける場合、システムは、所定の最大数の速度上昇の試行が行われたか否かを決定し得る（ブロック1112）。最大数の速度上昇の試行が行われていない場合、システムは、速度上昇待機状態への遷移1113に従い得る。最大数の速度上昇の試みが使用されている場合、システムは最大レート状態1101への遷移1114に従い得る。
【００８６】
前述の状態のそれぞれにおいて、異なるパケット損失閾値が使用されてもよい。更に、状態遷移の一部又は全てが、これらに関連する遅延を有してもよい。速度上昇は、ビットレートの15%ステップの増加で行われてもよい。パイプが完全に利用されており、パケット損失が報告されていない場合、次の速度上昇が生じる前にXタイマ周期（200ms*X）に等しくなり得る遅延がもたらされ得る。初期設定でXの値は2に設定され、400msの遅延を生じてもよい。連続的なパケット損失のレポートではなく、エコーレポートではない何らかのパケット損失は、状態遷移を生じ得る。
【００８７】
図１２は、動的に変化する帯域の可用性とDBA適合とを示している。図１２はまた、３つの一般的な損失のシナリオ（バースト損失、抑制されたパイプ及び常時損失）と共に、状態遷移、エコー遅延を示している。LPR保護の使用は、速度低下状態、速度上昇待機状態及び速度上昇状態の間の図１２の斜線の領域で示されている。速度上昇の試行は、輻輳上限をテストするために、LPR保護のオーバーヘッドを使用し得る。すなわち、ネットワーク輻輳状態が高いビットレートを許容するか否かを調べるために“冗長”データのみが使用されてもよい。輻輳上限のテストが失敗すると、“冗長”データのみが使用されているため、LPRはもたらされたパケット損失により生じた何らかの損失を保護する。このことにより、ビデオの中断のリスクを実質的に低減して、輻輳上限の調査が可能になる。
【００８８】
測定された輻輳上限は、完全にデータフローに適用可能である。例えば、複数のビデオストリームが送信されている場合、輻輳上限は総計ビットレートに適用し得る。前方消失保護は各ビデオストリームに独立して適用可能である。しかし、同じレベルの保護が全てのストリームに適用され得る。システムはまた、共通の前方消失訂正パケットでビデオストリームを併せて保護するように適合されてもよく、各ビデオストリームに異なるレベルの保護を適用するように適合されてもよい。
【００８９】
前方消失訂正はまた、ビデオストリームの一部のみに適用され得る。例えば、階層化ビデオ符号化が使用される場合、前方消失保護は、基本レイヤに適用されて、拡張レイヤに適用されなくてもよい。これはまた、様々なレイヤを異なる程度に保護するように適合されてもよい（いわゆる“不平等な保護（unequal protection）”）。これらの構成では、輻輳回避は全体データフローに当てはまる。
【００９０】
輻輳上限測定の例示的なLPRの調査（probe）がテーブル６に示されている。これらの調査は、所定値（例えば10%）だけデータレートを上昇させる可能性をテストするために使用され、短い期間（例えば800ms）の間に動作し得る。
【００９１】
【表６】
ここに記載された技術は、受信機が輻輳上限と消失保護レベルとを送信機にフィードバックという点で受信機主導でもよい。代替として、これらは、送信機主導のフレームワーク、又は制御ループが送信機と受信機との間で分散されるハイブリッド型フレームワークで使用され得る。何らかの適合で、マルチキャストストリームでの使用にも適する。記載された技術はまた、パケット再送信、周期的画像リフレッシュ及びビデオ誤り隠蔽のような他の技術と結合され得る。
【００９２】
前述のように、輻輳回避と前方消失訂正との組み合わせは、何れかの機構がそれ自体で実現できない固有の利点を提供する。１つのこのような利点は、ビットストリームでの前方消失保護パケットの量を実験的に増加させ、配信されたデータフローでの影響を観測することにより、輻輳上限が周期的に測定され得るという点にある。これらの保護パケットは、パケット損失からメディアを保護するのと同時に（レベルが輻輳上限を超える場合）、全体データレートを所望の“調査”レベルに増加させる。第２の利点は、輻輳上限を動的に測定するこの方法は、輻輳回避アルゴリズムで通常に使用されている受動的な方法により提供されるものより、許容帯域の非常に高速な決定を生じ得るという点にある。第３の利点は、全体フロー（メディア及び保護）が動的に測定された輻輳上限の下に留まるように抑制されたときに、保護されたメデイアフローが少ない遅延及び小さい保護オーバーヘッドで配信され得るという点にある。
【００９３】
ここに記載された技術の更なる利点は、ビデオデータレートが増加したときに、システムがパケット損失に対して保護するのに効率的になり得るという点にある。従って、高解像度ビデオの使用等でビットレートが増加すると、ここに記載された技術は、有用且つ効率的になる。
【００９４】
前方消失訂正と輻輳回避との統合は、複数の固有の利点を提供する。例えば、輻輳回避は、前方消失訂正に対して複数の固有の利点をもたらす。データリンクが混雑すると、そのリンクを通じた媒体の送信遅延が増加する。前方消失訂正のみを使用することは、許容可能なパケット損失率を生じ得るが、待ち行列遅延を低減しない。輻輳回避を制御ループに統合することにより、非常に小さい待ち時間で所望のサービス品質（QoS）を実現できる。更に、前方消失保護の効率は、大きい待ち時間のアプリケーションより小さい待ち時間のアプリケーションで小さくなる。データ損失の原因が簡単な輻輳である場合、ビットレートを低減することは、データフローに更なる前方消失訂正パケットを増加することより効率的になり得る。
【００９５】
逆に、前方消失訂正はまた、輻輳回避のみのものにかなりの価値を追加し得る。典型的には、輻輳回避技術は、データフローのレートを積極的に低減する。例えば、TCPの輻輳機構は、乗算係数だけデータレートを低減するが、加算係数を適用することにより非常に低く上がる。この理由は、データフローレートを増加することは、常に輻輳を生じるリスクがあり、従ってパケット損失を生成するからである。前方消失訂正が輻輳回避と統合されると、このリスクはかなり低減される。従って、前述のように、前方消失保護パケットの密度を単に増加させることにより、データレートが増加し得る。
【００９６】
更に、輻輳回避技術はまた、リンク速度を推定するように設計される。他のデータフローからの相互輻輳（cross-congestion）は、頻繁にパケット損失を生じ得る。相互輻輳が観測される時間までに、通常ではパケット損失は既に生じている。前方消失保護を含めることにより、このような相互輻輳によるパケット損失が回復可能になる。
【００９７】
ここに開示された技術は、マルチメディアデータ（ビデオデータ、オーディオデータ、静止画データ及び他の種類のデータ等）の送信用の何らかのシステムを含み、様々なシステムで使用され得る。このような技術は、典型的な汎用コンピュータシステム（デスクトップコンピュータ、ノートブックコンピュータ、ハンドヘルドコンピュータ、サーバ等）で使用され得る。代替として、これらの技術は、様々な装置形式のシステム（会議部屋のテレビ会議システム、デスクトップ型テレビ会議システム等）で使用され得る。ここに記載された技術はまた、インフラストラクチャ形式のテレビ会議装置（マルチポイント制御ユニット（MCU：multi-point control unit）、ブリッジ、メディアサーバ等）で使用され得る。
【００９８】
ここに記載された方法は、１つ以上のコンピュータプログラムにコード化され、コンピュータ可読媒体（コンパクトディスク、テープ、揮発性又は不揮発性メモリ等）に格納され得る。従って、プログラム記憶装置に格納された命令は、ここに記載された技術をプログラム可能制御装置（例えば、コンピュータ又は会議ユニット）に実行させるために使用され得る。開示された通信システムは、近端（near end）及び遠端（far end）の間の双方向通信を提供するものとして記載されているが、この開示の教示は一方向送信を提供するシステムにも適用可能であることがわかる。
【００９９】
好ましい実施例及び他の実施例の前述の説明は、出願人により考案された本発明の概念の範囲又は適用性を制限又は限定することを意図しない。ここに含まれる本発明の概念を開示する代わりに、出願人は特許請求の範囲により提供される全ての特許権を望む。従って、特許請求の範囲は、請求項又はその均等の範囲内にある全ての内容に対する全ての変更及び変形を含むことを意図する。
【０１００】
以上の実施例に関し、更に、以下の項目を開示する。
【０１０１】
（１）損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法であって、
損失パケット回復アルゴリズムを前記メディアストリームに適用し、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にし、
輻輳回避アルゴリズムを前記送信データストリームに適用し、前記輻輳回避アルゴリズムは、前記送信データストリームに挿入された冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させ、前記ネットワークが高いデータレートをサポートすることができるか否かを決定することを含む
ことを有する方法。
【０１０２】
（２）前記冗長情報は、１つ以上の回復パケットを有する、（１）に記載の方法。
【０１０３】
（３）回復パケット数は、RTCP受信レポートから決定されたチャネル損失率に依存する、（２）に記載の方法。
【０１０４】
（４）ネットワーク輻輳を回避するために必要に応じて総計ビットレートを低減することを更に有する、（１）に記載の方法。
【０１０５】
（５）前記損失パケット回復アルゴリズムは、前方消失訂正符号化を含む、（１）に記載の方法。
【０１０６】
（６）前記損失パケット回復アルゴリズムは、リードソロモン符号化を含む、（１）に記載の方法。
【０１０７】
（７）前記メディアストリームは、ビデオデータを有する、（１）に記載の方法。
【０１０８】
（８）ネットワークでメディアデータを送信するメディア符号化装置であって、
メディアエンコーダと、
前記メディアエンコーダからの出力を受信し、リアルタイム送信プロトコルに従って前記メディアエンコーダの出力を複数の発信元パケットとしてパッケージ化するように接続されたRTP送信機と、
前記ネットワークからチャネル情報を受信するように接続されたRTCPモジュールと、
前記RTCPモジュールから前記チャネル情報を受信するように通信可能に結合され、前記チャネル情報から使用されるLPR保護パラメータを決定するように適合され、前記LPR保護パラメータをLPRパケット化器に提供するように通信可能に結合されたLPRモード判定モジュールと、
RTP送信機からの出力を受信し、前記LPRモード判定モジュールから受信したパラメータを使用して前記RTP送信機の出力を複数のLPRデータパケットとして再パケット化するように接続されたLPRパケット化器と、
前記LPRパケット化器及び前記メディアエンコーダに結合され、前記LPRパケット化器及び前記メディアエンコーダから受信した情報に基づいてLPR回復パケットを生成するように適合され、前記LPRデータパケットと前記LPR回復パケットとを受信機に送信するように適合されたLPR回復パケット生成器と
を有するメディア符号化装置。
【０１０９】
（９）前記メディアエンコーダはビデオエンコーダである、（８）に記載のメディア符号化装置。
【０１１０】
（１０）前記LPRモード判定モジュールは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことによりLPR保護パラメータを決定する、（８）に記載のメディア符号化装置。
【０１１１】
（１１）各LPRデータパケットは、唯一の発信元パケットからの情報を含む、（８）に記載のメディア符号化装置。
【０１１２】
（１２）前記回復パケットのペイロードは、リードソロモン符号化を使用して符号化される、（８）に記載のメディア符号化装置。
【０１１３】
（１３）パケット型ネットワークで行われるメディア会議のLPR保護パラメータを決定する方法であって、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことを有する方法。
【０１１４】
（１４）前記保護期間は、前記メディア会議のビットレートに従って決定される、（１３）に記載の方法。
【０１１５】
（１５）メディアレートの関数としてLPR保護パラメータを調整することを更に有する、（３）に記載の方法。
【０１１６】
（１６）前記メディアレートの関数としてLPR保護パラメータを調整することは、グループ毎のパケット数を動的に適合させることを有する、（１５）に記載の方法。
【０１１７】
（１７）前記メディアレートの関数としてLPR保護パラメータを調整することは、パケットサイズを動的に適合させることを有する、（１５）に記載の方法。
【０１１８】
（１８）前記メディアレートの関数としてLPR保護パラメータを調整することは、空のデータパケットを送信することを有する、（１５）に記載の方法。
【０１１９】
（１９）ネットワークで送信機からメディアデータを受信するメディア復号化装置であって、
前記ネットワークから、LPRデータパケットとLPR回復パケットとを含むLPRパケットを受信するように結合されたLPR回復モジュールと、
前記LPRデータパケットを受信し、何らかの損失データパケットを再生成するように適合されたLPR再生成器と、
前記LPR再生成器に通信可能に結合され、前記LPR再生成器から損失パケットのレポートを受信し、損失パケット情報を前記送信機に送信するRTCPモジュールと、
前記LPR再生成器に結合され、前記LPRデータパケットと前記再生成されたデータパケットとを受信し、含まれるメディア情報をデコードするように結合されたメディアデコーダと
を有するメディア復号化装置。
【０１２０】
（２０）前記メディアデコーダはビデオデコーダである、（１９）に記載のメディア復号化装置。
【０１２１】
（２１）前記LPR回復モジュール及び前記LPR再生成器は、LPRアルゴリズムが使用中でないときにパススルーとして動作する、（１９）に記載のメディア復号化装置。
【技術分野】
【０００１】
本発明は、輻輳回避と共に損失パケット回復を行うシステム及び方法に関する。
【背景技術】
【０００２】
ますます、テレビ会議システムは、回線交換ネットワーク（PSTN及びISDN等）ではなく、パケット交換ネットワーク（インターネット等）を使用し始めてきている。テレビ会議にパケット交換ネットワークを使用することでの１つの問題は、全てのパケット交換ネットワークが或る程度のパケット損失を受けるという点にある。控えめなパケット損失であっても、ビデオ品質はかなり損なわれる。
【０００３】
パケット損失の問題に対する既存の対策は、様々な誤り隠蔽技術と画像リフレッシュ機構とを使用することを含む。有用ではあるが、これらの技術はしばしば不十分である。これらは、頻繁に特定のビデオコーデックと統合されており、これらの技術がコーデック技術の進展毎に改革されることを必要とする。
【０００４】
典型的には、パケット交換ネットワークは、少なくとも２つの基本的な種類のパケット損失を有する。ネットワークのレイヤ1及び2が回復されない情報を損失したときに、物理的損失が生じ得る。例えば無線リンク（例えば、802.11a、802.11b、802.11g及び802.11nのようなWiFiネットワーク）が使用されるときに、この種類の損失は一般的である。しかし、有線及び光ファイバリンクでも物理レイヤの損失が生じ得る。第２の種類のパケット損失は、ネットワーク輻輳から生じ得る。
【０００５】
この第２の種類のパケット損失を克服するために、或るテレビ会議装置は、様々な輻輳回避技術を使用している。１つのこのような技術は、2002年11月26日に出願された“System and Method for Dynamic Bandwidth Allocation for Videoconferencing in Lossy Packet Switched Systems”という題の米国特許出願10/305,485号に記載されている。この特許出願の全ての内容を援用する。このような技術は、“動的帯域割り当て（Dynamic Bandwidth Allocation）”又は“DBA”と呼ばれることがある。これらの種類のDBAアルゴリズムは、帯域を増加使用とすると常にパケット損失を取り込むという本質的なリスクがある。このことは、損なわれた媒体という結果になり得る。他の種類の輻輳回避技術は、VCONのPacketAsssistと、損失パケット回復又は輻輳制御に関する他の標準とを含む。例えば、RFC2733は、XOR（パリティ）パケットを使用する損失パケット回復方法を提供する。RFC3448は、RFC4340と同様に、ユニキャスト輻輳制御方法を提供する。
【０００６】
更に、前方消失訂正（forward erasure correction）及び前方誤り訂正（forward error correction）のような損失データ回復技術が、ネットワークのレイヤ1及び2で使用され得る。これらの技術もまた、RAIDディスク及びCDROM/DVDのような記憶媒体で使用されている。近年、3GPPは前方誤り訂正を標準化した。前方誤り訂正はまた、H.320を介して送信されるビデオストリームにも提供され得る。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願10/305,485号
【非特許文献】
【０００８】
【非特許文献１】RFC2733
【非特許文献２】RFC3448
【発明の概要】
【発明が解決しようとする課題】
【０００９】
これまで、（例えば前方消失訂正を使用した）損失パケット回復と輻輳回避とを統合する実現は行われていない。このような統合を含むアルゴリズムを記載する。
【課題を解決するための手段】
【００１０】
一態様では、本発明は、損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法に関する。この方法は、損失パケット回復アルゴリズムをメディアストリームに適用することを含み得る。損失パケット回復アルゴリズムは、メディアストリームを含む送信データストリームに冗長情報を挿入することにより動作し得る。冗長情報は、前方消失訂正及び／又はリードソロモン符号化を使用して生成され得る。この方法は、輻輳回避アルゴリズムを送信データストリームに適用することを更に含み得る。輻輳回避アルゴリズムは、送信データストリームのデータレートを一時的に増加させ、ネットワークが高いデータレートをサポートすることができるか否かを決定することを更に含み得る。データレートは、送信データストリームに挿入される冗長情報の量を増加させることにより、一時的に増加し得る。
【００１１】
本発明はまた、損失のあるネットワークで受信したメディアデータを回復する方法に関し得る。メディアストリームは、データストリームと冗長情報とを有するデータストリームの一部として送信されている。この回復方法は、メディアストリームと冗長情報とを有する複数のパケットを受信し、受信パケットからメディアストリームの損失部分を再構成することを含み得る。
【００１２】
本発明はまた、前述のデータ回復及び輻輳回避を実行するように適合されたテレビ会議装置に関し得る。
【発明の効果】
【００１３】
本発明の実施例によれば、パケット損失を低減することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】パケット損失を防ぐために使用され得る損失パケット回復技術
【図２】特定のパケットが損失してデータが再構成される損失パケット回復技術
【図３】特定のパケットが損失してデータが再構成される損失パケット回復技術
【図４】損失パケット回復エンコーダ
【図５】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図６】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図７】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図８】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図９】図１〜４の損失パケット回復技術と共に使用され得るパケットヘッダ
【図１０】損失パケット回復デコーダ
【図１１】図１〜１０の損失パケット回復技術、エンコーダ及びデコーダと共に使用され得る輻輳回避アルゴリズムの状態機械
【図１２】図１〜１０による技術、エンコーダ、デコーダ及びアルゴリズムを使用して損失パケット回復と輻輳回避とを使用するエンコーダのデータレート
【発明を実施するための形態】
【００１５】
前方消失訂正と輻輳回避との使用を組み合わせたネットワーク送信で、損失パケットの影響を克服する技術が開示される。これらの技術は、“損失パケット回復（Lost Packet Recovery）”又は“LPR”と呼ばれることがある。
【００１６】
LPRは、損失RTPメディアパケットを回復するスケーラブルな方法である。ここに記載する例はビデオコーデックを対象としているが、メディアに特有ではない。ここに記載するLPR技術はまた、他の種類のRTPメディアストリームを保護するために使用され得る。LPRは、損失メディアパケットの前方消失訂正を提供するために、リードソロモン符号化を使用し、損失メディアパケットの回復を可能にする。
【００１７】
LPRが使用される場合、RTPペイロードは、ほぼ等しいサイズのデータパケットを生成するように再パケット化される。再パケット化されたストリームは、異なるRTPダイナミックペイロード形式（これは割り当てられたメディアペイロード番号と異なる）を使用し、完全にRTPに準拠する。ペイロード特有のヘッダは、元のRTPパケットを再構成するのに十分な情報を含む。LPRは、SSRC及びCSRC情報が回復セット（以下に説明する）の途中で変化しないことを仮定する。タイムスタンプ、シーケンス番号、元のペイロード形式及びマーカ・ビット（marker bit）が完全に回復され、回復されたRTPストリームが復号化可能になることを確保する。
【００１８】
次に、回復パケットは、このRTPストリームに追加される。回復パケットもRTPに準拠する。各回復パケットはまた、保護されたデータパケットを記述するペイロードヘッダを含む。各パケットのRTPペイロードは回復情報を含む。追加された回復パケットの数は、RTCP受信レポートから推定されたチャネル損失率に依存する。約50%のビットレートのオーバーヘッドを有するが、約15%までのチャネル損失率に対応可能である。
【００１９】
LPR保護は、全体メディアのビットレートの一部と考えられない点に留意すべきである。従って、実際に圧縮されたペイロードのみが数えられる。しかし、ネットワーク輻輳を回避するために、総計ビットレートが必要に応じて低減され得る。ネットワーク輻輳は、パケット損失以外に又はパケット損失に加えて望ましくない影響を有し得る点に留意すべきである。例えば、ネットワーク輻輳は、媒体の待ち時間の増加と、接続（シグナリング接続を含む）の劣化を生じ得る。従って、LPRプロトコルは、輻輳回避のための内蔵メッセージを有し得る。１つの適切な輻輳回避アルゴリズムについて以下に詳細に説明するが、様々な輻輳回避アルゴリズムが使用されてもよい。
【００２０】
メディアストリームに適用されるLPRの例について、図１〜３を参照して説明する。ビットレート、パケット損失率、パケットサイズ、データパケット対回復パケットの比等を含むこの例の詳細は、全てが単なる例であり、実装の詳細、チャネル状態等に応じて変化し得る。
【００２１】
2%のパケット損失率を有する300kbpsのビデオチャネルについて検討する。３つのパケット101、102及び103が送信される。(6+2)のLPRモードが使用される。これは、２つの回復パケット104、105が６つのデータパケット106〜111の各グループに挿入され、それぞれ８パケットの回復セットを生成することを意味する。回復パケット104、105は、最大データパケットとほぼ同じサイズであるが、何らかの更なるオーバーヘッドを含む。以下に詳細に説明するように、回復パケットは、６つのデータパケット106〜111のいずれか２つの再生成を可能にする。
【００２２】
300kbpsのチャネル制限内に留まるために、メディアレートは、約220kbpsまで低減可能であり、回復パケットに80kbpsを残す。それぞれの再パケット化されたデータパケットの目標サイズは500バイトになり得る。従って、各回復セットは、約32000ビットの情報を伝達し、これは、300kbpsのチャネルレートで107msの期間を表す。107msの期間は、保護期間と呼ばれる。
【００２３】
各パケット（すなわち、再パケット化されたデータパケット106〜111及び回復パケット104、105）は、通常の40バイトのIP+UDP+RTPヘッダのオーバーヘッドを含む。簡単にするために、このオーバーヘッドは示されていない。しかし、LPR自体に関連するオーバーヘッドが示されている。例えば、“3+420”は、420バイトの元のデータに加えて3バイトのオーバーヘッドがパケットに存在することを示す。回復パケットは100%のオーバーヘッドになる。オーバーヘッドの詳細は、以下に詳細に説明する。
【００２４】
図２は、回復処理を示している。データパケット3及び5（108、111）が損失したことを仮定する。LPRデコーダは、受信した６つのパケット（すなわち、データパケット1、2、4及び6並びに回復パケット1及び2）から再生成パケット201及び202を生成する。損失パケットの再生成は、６つのパケットが受信されるまで生じることができない点に留意すべきである。再生成の後に、元のRTPパケット203〜205がデータパケットから復元される。損失パケットの再生成は、以下に詳細に説明する。
【００２５】
図３は、２つより多くのパケットが損失したときのパケット回復の失敗を示している。この例では、データパケット3及び5と同様に、回復パケット1が損失している。グループのうち５つのみのパケットが受信されたため、パケット再生成は不可能である。LPRデコーダは部分的なパケットを再生成しない。元のパケットが完全に回復できない場合、部分的なパケット情報は破棄される。従って、データパケット1及び2（301、302）の双方が損失したものとして示されている。
【００２６】
図３に示すように、元のデータパケットの全てが回復できない場合、受信側デコーダが全体画像の高速更新を要求することが一般的である。代替として、2006年3月28日に発行された“Dynamic Intra-coded Macroblock Refresh Interval for Video Error Concealment”という題の米国特許7,020,203号に記載のようなウォークアラウンド・リフレッシュ（walk-around refresh）を要求する。この米国特許の全ての内容を援用する。いずれの場合でも、画像を訂正するために必要な時間は、損失したパケットの数の関数ではなく、回復セットの所定数のパケット（この例では２つ）より多くを損失することによりもたらされた失敗の間の平均時間になる。
【００２７】
300kbps及び2%のパケット損失のチャネルで、６つのデータパケットと２つの回復データパケットとの各保護セットが107msのチャネルデータをカバーする所定の例では、失敗の間の平均時間は、約258秒であると計算され得る。高速更新が約2秒を要求することを仮定すると、所与のLPRの例により保護されるチャネルで送信されるビデオは、99%より多くの時間で誤りのないことになる。この保護は、80kbpsの更なるオーバーヘッドをもたらし、これは約30%のチャネルレートになる。
【００２８】
前述のLPRの例の更なる態様は、図４を参照してより良く理解され得る。図４は、LPRエンコーダの実装を示している。この実装の変形も可能である。ビデオエンコーダ401は、ほとんど通常の方法で動作する様々なビデオエンコーダのいずれかでもよい。例えば、ビデオエンコーダは、H.261、H.263、H.264、MPEG-2、又はMPEG-4ビデオ圧縮標準に従って動作し得る。代替として、ビデオエンコーダは、様々な独自仕様のビデオコーディング技術のいずれかに従って動作し得る。
【００２９】
ビデオエンコーダ401の出力は、任意選択の暗号化モジュール402に供給され得る。暗号化モジュール402もまた、様々な既知の種類のいずれかでもよい。暗号化されたビデオデータ（又は暗号化が使用されない場合には暗号化されていないビデオデータ）は、RTP送信機403に供給され得る。RTP送信機403も通常のものでもよい。RTP送信機403により生成されたRTPパケットは、以下に詳細に説明するように、LPRパケット化器406によりLPRアルゴリズムを使用して再パケット化され得る。LPR回復パケット生成器407は、以下に詳細に説明するように、LPRパケット化器406及びビデオエンコーダ401から受信した情報に基づいて回復パケットを生成し得る。LPR回復パケット生成器は、LPRデータパケットとLPR回復パケットとを受信機（図示せず）に送信し得る。
【００３０】
RTCPモジュール404は、パケット損失及び他のチャネル統計を受信し、これらをLPRモード判定モジュール405に供給し得る。LPRモード判定モジュール405はLPRパケット化器406を制御する。LPRモード判定モジュール405は、LPR保護を行うか行わないかを判定し、使用されるLPR保護パラメータを決定し得る。LPR保護が行われない場合、LPRパケット化器406及びLPR回復パケット生成器407は、RTP送信機403により生成されたRTPパケットを、変更せずに通過し得る。
【００３１】
LPRモード判定モジュール405は以下のように動作し得る。まず、（前述の）保護期間が決定され得る。長い保護期間は効率的なパケット再生成（例えば少ない回復kbps）を提供するが、長い待ち時間を生成する。最も典型的なテレビ会議のビットレートでは、100msが適切な保護期間になり得る。128kbpsより小さいビットレートでは、長い保護期間が必要になってもよい。例えば、150msが64kbpsのレートに適する可能性がある。1Mbpsより大きいビットレートでは、短い保護期間が有利なことがある。例えば、50msが2Mbps以上のレートに適する可能性がある。他のパラメータも保護期間を決定する際に検討され得る。
【００３２】
次に、保護期間毎の全パケット数が決定され得る。一般的に、保護期間毎に小さいパケット数は、保護の効率を減少させる傾向になり得る。逆に、保護期間毎に大きいパケット数は、保護パケットをエンコード及びデコードするために必要な計算量を増加させる傾向になり得る。従って、ほとんどのチャネルについて、保護期間毎に約13以上のパケットが適切であると考えられる。保護期間毎のパケット数についての判定は、所望のデータレートに対する結果のパケットサイズも考慮すべきである。出力パケットサイズ（IPオーバーヘッドを含む）は、分割せずにIPSECトンネルを横断するために、1260バイト未満であるべきである。
【００３３】
保護期間毎のパケット数が定められると、保護期間毎の回復パケット数が選択され得る。回復パケット数は、（通常の確率的分析技術を使用して）保護の中断の間の平均時間が所定の規定値を満たす又は超えるように選択され得る。更に、全ての送信されたビデオチャネルの総計（LPR保護パケット及びRTPメッセージを含む）が、指定の輻輳上限を超えないように選択され得る。
【００３４】
以下のテーブルは、様々な損失条件で様々なビットレートに使用され得る例示的な保護モデルを示している。テーブル１は、パケット損失が3%を超えるときにデータレートを低減する輻輳回避アルゴリズム（以下に説明する）と共に使用可能であり、4%のパケット損失条件に適し得るLPRパラメータを示している。テーブル２は、輻輳回避アルゴリズムが使用中でないときに使用され得る2%のパケット損失条件のLPRパラメータを示している。
【００３５】
【表１】
【００３６】
【表２】
LPRパケット化器406は以下のように動作し得る。LPRパケット化器406は、パケット再生成符号化の効率を改善するために、RTP送信機403により生成された元のメディアパケットを細分する。LPRデータパケットは、唯一の発信元パケットからの情報を含む。メディアチャネルが暗号化されている場合、暗号化ストリームでLPR再パケット化が実行され得る。一般的に、LPRストリーム自体は再暗号化されない。すなわち、暗号化パケットと新しく生成されたLPR回復パケットとに追加されたLPRカプセル化フィールド（ヘッダ）は、平文で送信される。
【００３７】
元の発信元パケットが細分される場合（例えば、図１〜３のパケット1 101）、この発信元パケットの最初のLPRデータパケットは初期データパケット（例えば、図１〜３のデータ1 106）と呼ばれる。（存在する場合には）次のデータパケットは、後続データパケット（例えば、図１〜３のデータ2 107及びデータ3 108）と呼ばれる。後続データパケットの数は、初期データパケットで伝達され、従って、初期データパケットが送信されると変更できない。後続データパケット及び初期データパケットは、異なるLPR保護グループに存在してもよい。
【００３８】
シーケンス番号とペイロード形式とPフィールドとを除いて、元のRTPヘッダの全てのフィールドは、各LPRデータパケットで変更されずに伝達され得る。これは、タイムスタンプとマーカ・ビットとSSRC/CSRC情報とを含む。ペイロード番号は、ネゴシエーションされたLPRペイロード形式と交換され得る。シーケンス番号は、通常通りにLPRメディアストリームに連続的に割り当てられ得る。LPRパケットのPフィールドは0に設定され得る。LPRパケット化器406は、元のRTPシーケンス番号をLPR回復パケット生成器407に渡し得る。
【００３９】
各初期データパケットは、LPRに特有の7バイトのペイロードヘッダを含み得る。この例が図５に示されている。各後続データパケットは、3バイトのペイロードヘッダを含み得る。この例が図６に示されている。これらのペイロードヘッダは、RTPヘッダの直後に続き、ビデオ（又は他のメディア）ペイロードに先行し得る。ヘッダサイズ及び個々のフィールドのサイズ並びにこれらの構成は単なる例であり、他の構成も可能であることがわかる。
【００４０】
回復パケットのフィールド501、601は、回復セットで後に送信される回復パケット数を示すために使用され得る。回復セットの全てのデータパケットは、同じ数の回復パケットを伝達するべきである。伝達される回復パケット数は0でもよく、これは回復パケットが送信されないことを示す。このフィールドは6ビットのフィールドでもよく、64の回復パケットまでを許容する。形式のフィールド502、602は、それぞれ初期データパケット又は後続データパケットを示すために、00又は01に設定される2ビットのフィールドセットでもよい。これは、最初のペイロードバイトを検査することにより、LPRのヘッダ形式が決定されることを可能にする。
【００４１】
データインデックスのフィールド503、603は8ビットのフィールドでもよい。回復セットの最初のデータパケットは1のデータインデックスを割り当てられ得る。データインデックスは、そのセットの次のデータパケットでインクリメントされ得る。後続パケットのフィールド504は、初期パケットに関連する後続パケット数を指定するために使用される8ビットのフィールドでもよい。データパケットのフィールド604は、回復セットに含まれるデータパケット数を伝達するために使用される8ビットのフィールドでもよい。全てのデータパケットは、同じ数のデータパケットを伝達するべきである。
【００４２】
元のシーケンスのフィールド505は、元のRTPパケットシーケンス番号を示す16ビットのフィールドでもよい。これは、元のRTPパケットを再生成するために使用される。元のPビットのフィールド506は、元のRTPパケットにより伝達されるパディングビット（padding bit）を伝達するために使用される1ビットのフィールドでもよい。元のペイロード形式のフィールド507は、元のRTPパケットにより伝達されるペイロード形式を伝達するために使用される7ビットのフィールドでもよい。
【００４３】
LPR回復パケット生成器407は、以下のように動作し得る。LPR回復パケット生成器407は、元のメディアのRTPシーケンス番号を、LPRデータパケットの最後のLPRシーケンス番号と交換し得る。LPR回復パケット生成器407はまた、各回復セットの終わりにLPR回復パケットを挿入し得る。
【００４４】
各回復パケットはまた、図７に示すような9バイトのヘッダを含み得る。回復パケットヘッダは、RTPヘッダの直後に続き、ビデオ（又は他のメディア）ペイロードに先行し得る。前述のヘッダと同様に、フィールドの形式及びサイズは例示的であり、他の構成も使用されてもよい。
【００４５】
回復インデックスのフィールド701は、回復セットの回復パケットのシーケンスを示すために使用される6ビットのフィールドでもよい。最初の回復パケットは、1の回復インデックスを割り当てられ得る。回復インデックスは、回復セットの次の回復パケットでインクリメントされ得る。形式のフィールド702は、パケットが回復パケットであることを示すために、10に設定される2ビットのフィールドでもよい。回復パケットのフィールドは、回復セットのデータパケット数を含む8ビットのフィールドでもよい。全ての回復パケットは、対応するデータパケットにより伝達された同じ数の回復パケットを伝達するべきである。データパケットのフィールド704は、回復セットで送信されるデータパケット数を示す8ビットのフィールドでもよい。回復パケットは、対応するデータパケットで示された同じ数のデータパケットを示すべきである。
【００４６】
保護タイムスタンプのフィールド705は、回復セットの各データパケットのリードソロモン符号化されたRTPタイムスタンプを保持する32ビットのフィールドでもよい。これは、回復ペイロード自体で使用されるものと同じリードソロモン符号化を使用して結合され得る。このフィールドにより、損失データパケットのRTPタイムスタンプが再生成されることが可能になる。4バイトはネットワークの指示（in network order）である。
【００４７】
保護マーカ、フラグ及びサイズのフィールド706（図８に更に示す）は、リードソロモン符号化されたRTPマーカ・ビット802、フラグ値801及びデータパケットサイズ803を保有し得る。フラグ値は、LPRデータパケットが初期パケットである場合に1になってもよく、LPRデータパケットが後続パケットである場合に0に設定されてもよい。サイズは、LPRヘッダと同様にIP、UDP及びRTPヘッダを含み得る。データパケットサイズはネットワークの指示でもよい。
【００４８】
保護フィールドは、回復ペイロード自体で使用されたものと同じリードソロモン符号化を使用して結合される。このフィールドにより、回復可能な何らかの損失データパケットについて、LPRヘッダ形式、マーカ及びデータパケットサイズが再生成されることが可能になる。
【００４９】
回復パケットのペイロードは、リードソロモン256（RS256）符号化を使用して符号化され得る。初期データパケットの元のシーケンス505、元のPビット506、元のペイロード形式507及び後続パケット504のフィールドは、ペイロードバイトであるかのように保護され得る。これにより、初期データパケットが損失した場合に、この情報が回復可能になる。更に、回復パケットのペイロードヘッダは、３つのファントムデータ（Phantom Data）のフィールド（データパケット自体の長さ、マーカ・ビット及びタイムスタンプ）の符号化を含み得る。この場合も同様に、これにより、細分されたRTPパケットの全てのデータパケットが損失した場合に、この情報が回復可能になる。
【００５０】
各データパケットの各ペイロードバイトは、以下のRS256の生成関数に従って、各回復パケットの対応するバイトに寄与し得る。
【００５１】
【数１】
ただし、Diは第iのデータパケット（1≦i≦d）であり、Rjは第jの回復パケット（1≦j≦r）であり、Biはテーブル３に示す値を有する第iの基礎係数（1≦i≦d）であり、
【００５２】
【数２】
は以下に示すGガロア域（28）算術演算を使用して計算される。所与の基礎係数のテーブルは、回復セットの最大データパケット数を128に制限するが、他のデータパケット数が選択可能であり、それに従って適切なテーブルが計算され得る点に留意すべきである。
【００５３】
【表３】
ガロア域（28）算術演算は、２つの補助テーブル（ガロア・ログ関数（glog）テーブル及びガロア指数関数（gexp）テーブル）を使用して設定され得る。これらのテーブルは以下の通りである。
【００５４】
【表４】
【００５５】
【表５】
これらのテーブルは、以下に説明する様々な算術演算を計算するために使用され得る。
【００５６】
ガロア域（28）の加算及び減算は同じ演算であり、以下のように実行される。
【００５７】
【数３】
ただし、^は排他的論理和又はXOR演算である。通常の演算と同様に、次のようになる。
【００５８】
【数４】
ガロア域（28）の乗算は以下のように実行される。
【００５９】
【数５】
ただし、+は通常の加算演算である。通常の演算と同様に、次のようになる。
【００６０】
【数６】
また、次のようになる。
【００６１】
【数７】
ガロア域（28）の除算（a÷b）は以下のように実行される。
a÷b=gexp[glog[a]-glog[b]+255]
ただし、+は通常の加算演算であり、-は通常の減算演算である。通常の演算と同様に、a÷1=aである。また、通常通り、bは0ではない。
【００６２】
ガロア域（28）のべき乗関数（ab）は以下のように実行される。
ab=gexp[(glog[a]*b)%0xFF]
ただし、+は通常の加算演算であり、-は通常の減算演算であり、*は通常の乗算演算であり、%は通常のmod関数である。通常の演算と同様に、0でないaについてa0=1である。RS256参照コードでは、0は決してべき乗にならない。
【００６３】
前述のように、（パケットの）LPRグループサイズは、所望の保護期間（ミリ秒）を実現するように設定され得る。ビデオコーデックが全チャネルビットレートを使用しない場合、LPRグループは長い待ち時間を生じる。例えば、通常では1.5Mbpsで動作するビデオチャネルは、軽い動作期間に（in periods of light motion）750kbpsに低下し得る。これは、所望の２倍の長さの保護期間を生じる。このような状況は、選択されたLPRモードが所定のMTBFを満たし続けることを生じ得る。この例では、2の係数だけ所定のMTBFを超える。
【００６４】
或る場合には、この拡張保護期間が許容され得る。しかし、パケットが損失した場合に、これは長い待ち時間を生じ得る。従って、或る場合には、実際のビデオレートが変化するときに、送信機がそのLPRモードを調整することが望ましいことがある。３つのこのような調整について以下に説明するが、他の調整も可能である。
【００６５】
行うことができる１つの調整は、保護グループサイズに対するものである。或る実施例では、この設定は、各保護グループの境界で変更され得る。従って、送信機は、LPR出力パケットレートを監視し、グループ毎のパケット数を動的に適合させ得る。この調整が使用される場合、データレートが下がると、LPR保護オーバーヘッドは上がる傾向になる。しかし、このような場合のデータレートは一般的に通常の制限より小さいため、変更されたLPRモードは、一般的に依然として所定の輻輳上限の下に留まる。
【００６６】
行うことができる他の調整は、送信機が初期データパケットの送信時にその出力パケットサイズを変更することである。典型的には後続パケット数が初期データパケットで伝達されているため、一般的に、送信機は、後続パケットを送信するときに出力パケットサイズを変更するべきでない。従って、送信機は、LPR出力パケットレートと出力データレートとを監視し、保護期間毎のパケット数を維持するようにパケットサイズを動的に適合させ得る。
【００６７】
行うことができる他の調整は、送信機が空のデータパケットを送信して部分的な回復セットを完了することである。空のデータパケットは、前述の初期データパケットヘッダを含み得る。パケットに通常存在する他の情報（シーケンス番号、ペイロード形式、後続パケット数等）は、全て0に設定され得る。空のデータパケットは保護グループの一部であるため、前述の回復パケットの符号化はこれらのパケットを含み得る。これらのパケットはまた、デコード処理により回復可能である。また、空のデータパケットは、出力メディアパケットストリームの空のパケットを回避するために、LPRデコーダ（以下に説明する）により破棄され得る。
【００６８】
詰め込まれたパケット（fill packet）は、所定のデータレートを維持するために使用され得る。これらの詰め込まれたパケットは、受信機により破棄され得る。例示的な詰め込まれたパケットが図９に示されている。詰め込まれたパケットは、1の値を有する6ビットの拡張形式のフィールド901と、11の値を有する2ビットの形式のフィールド902とを含み得る。詰め込まれたパケットは、メディアストリームのLPRペイロード形式を使用したRTPパケットでもよい。タイムスタンプの値は、前に送信されたRTPパケットの値と同じでもよい。シーケンス番号は、前に送信されたパケットの値からインクリメントされてもよい。ペイロードは、前述の詰め込まれたヘッダで終了し得る。フィールドのペイロード長は、最大の指定パケットサイズ内で如何なる長さでもよい。
【００６９】
LPRデコーダの例が図１０に示されている。前述のLPRエンコーダと同様に、この実施例の変形も可能である。LPRデコーダの動作は、基本的に前述のLPRエンコーダの逆になり得る。具体的には、LPRパケットは、LPR回復モジュール1001により回復され得る。これらの回復されたLPRパケットは、RTP並び替えバッファ1002に渡され、RTP並び替えバッファは、通常のシステムと同様に、パケットを受信順に並び替え得る。LPR再生成器1003は、（LPR回復ブロック1001から）回復されたLPRパケットから受信した情報と、RTPCモジュール1006から受信したRTCP情報とに基づいて、何らかの損失パケットを再生成し得る。これらの再生成されたブロックは、（暗号化が発信元で使用されている場合）復号化ブロック1004により復号化され得る。最後に、復号化されたブロックがビデオデコーダ1005（又は必要に応じて他の種類のメディアエンコーダ）により処理され得る。
【００７０】
LPR回復モジュール1001及びLPR再生成器1003のみは、通常のシステムと比べて非標準の要素でもよく、これらの２つのモジュールはLPRが使用されないときにパススルー（pass-through）として動作し得る。
【００７１】
LPR回復モジュール1001は、全てのLPR RTPパケットを処理し得る。所与の例では、受信して再生成された全てのパケット（データ及び回復）は、直接にRTP並び替えバッファに渡され得る。各データパケットのオーバーヘッドデータにより、これらのパケットが何らかの順序でLPR回復モジュール1001により処理されることが可能になる。LPR回復モジュール1001はまた、LPR RTP受信レポート情報をRTCPモジュール1006に提供し得る。この情報は、何が受信されたかに基づいてもよい（例えば、受信されていない何らかのパケットが受信レポートで損失として特定され得る）。
【００７２】
回復可能な回復セットに損失データパケットが存在する場合、十分な回復パケットが受信されるとすぐに、LPR回復モジュールはこれらのパケットを回復し得る。前述のように、kのデータパケットが損失している場合、データを回復するためにkの回復パケットが受信されなければならない。この回復処理は、まず、マーカ・ビットと、データパケット長と、初期パケットフラグと、元のタイムスタンプとを回復することを含み得る。データパケット長は、元のデータパケットのペイロードを回復するために使用され得る。LPR RTPヘッダの“固定”の構成要素（例えば、SSRC、CSRC、LPRペイロード形式等）は、１つの回復パケットから採用され得る。LPR RTPヘッダの様々な部分（例えば、マーカ・ビット、タイムスタンプ及びシーケンス番号）は、回復ヘッダから回復された値に設定され得る。
【００７３】
LPRデータパケットiのシーケンス番号は以下の式に従って計算され得る。
Si=Sr-(d+r-i)
ただし、iは回復データパケットのインデックスであり、dは回復セットのデータパケット数であり、rは受信した回復パケットのインデックスであり、Siはパケットiのシーケンス番号である。
【００７４】
データパケットを受信する間に、前述のRS256生成関数を使用して、部分的な回復パケットが回復モジュール1001により構築され得る。そのセットの対応する回復パケットが受信されると、これらのパケットは、部分的な回復パケットと排他的論理和（XOR）され得る。結果の残りのパケットは、各回復パケットへの何らかの損失データパケットの寄与を保持する。例示的なシステムでは、それぞれの残りのパケットは、損失データパケットのそれぞれの線形結合である。従って、kの連立方程式（kの残りのパケットのそれぞれに１つ）が存在し、それぞれkの未知数（損失したkのデータパケットのそれぞれに１つ）が存在する。
【００７５】
当業者にわかるように、これらの式はk×kの行列として表され得る。k×kの行列は、例えばガウス消去法により数学的に解決され得る。このような演算は周知であるため、詳細はここでは説明しない。残りのデータで結果の逆行列を乗算することにより、損失データパケットを回復することができる。
【００７６】
前述の回復処理を示すために、図２の回復シナリオが実行され得る。明瞭にするために、実際のガロア域（28）の演算ではなく、通常の算術演算が使用される。回復パケットのデータは、以下の式（前述のRS256生成関数及びテーブルから導かれる）を使用して生成され得る。
R1=D1+D2+D3+D4+D5+D6
R2=2D1+4D2+6D3+9D4+13D5+14D6
部分的な回復パケットは、受信したパケットでデコーダにより計算され得る。前述の例で記載したように、パケット3及び4（図３の108、110）は受信されない。その結果、以下のようになる。
P1=D1+D2+D5+D6
P2=2D1+4D2+13D5+14D6
残りは、受信した回復パケットから部分的な回復パケットを減算することにより計算され得る。
r1=R1-P1=D3+D4
r2=R2-P2=6D3+9D4
従って、残りの生成行列は以下のようになる。
【００７７】
【数８】
ガウス消去法を介してこの行列を逆にすると、以下の結果になる。
【００７８】
【数９】
従って、損失データパケット（すなわち、データパケット3及び4）の情報は、以下の式を使用して回復され得る。
D3=3r1-r2/3
D4=-2r1+r2/3
LPRが使用中である場合、RTP並び替えバッファ1002はLPRデコーダと統合され得る。或る状況では、パケットが実際に到達する前に順序の狂ったパケットがLPRにより再生成され得るため、これは最小遅延の実装を可能にする。更に、或る実施例では、何らかのデータパケットが損失した場合にのみリードソロモンデコーダを動作して、回復セットの最初のdのパケットを取得することが望ましいことがある。この設計は最小の遅延を生じないことがあるが、計算効率が良くなり得る。
【００７９】
LPR再生成モジュール1003は、前述のように、データパケットから元のRTPストリームを再生成し得る。RTPパケットの何らかのデータパケットが損失している場合、そのRTPパケットは出力ストリームから省略される。LPRストリームは並び替えられているため、各パケットからの初期パケットが最初に受信されるべきである。後続パケットが最初に直面する場合、初期パケットが損失しており、後続パケットが破棄され得る。
【００８０】
出力RTPパケットは、初期データパケットのRTPヘッダ情報を使用する。ペイロード形式、シーケンス番号及びタイムスタンプは、初期データヘッダの値と交換される。ペイロードは、LPRヘッダが取り除かれて、初期データパケットと何らかの後続データパケットとから集められる。何らかの後続パケットが損失している場合、出力RTPパケットが抑制され得る。後続パケット数は初期データパケットのヘッダで伝達され得るため、既知でもよい点に留意すべきである。
【００８１】
前述のような損失パケット回復技術は、更に動作を拡張するために、輻輳回避アルゴリズムと結合され得る。例示的な輻輳回避アルゴリズムは前述の通りであり、動的帯域割り当て（DBA：Dynamic Bandwidth Allocation）と呼ばれる。DBAは、受信機のRTPスタック（図１０の1006）により報告されたパケット損失率に基づいてビットレートを下げることにより、輻輳を回避しようとし得る。受信機のRTPスタックは、一定の期間中（例えば毎200ms）の受信機のチャネルのパケット損失統計を生成する。これは、低いMTBF要件を有する最小のLPR構成を可能にしつつ、動的に変化するパイプへの高速な適合を可能にする（次に、これは低いオーバーヘッドを可能にする）。
【００８２】
図１１に示すように、DBAの制御ループは、最大レート状態1101と、速度低下状態1102と、速度上昇待機状態1103と、速度上昇状態1104と、常時損失状態1105とを有する状態機械として実現され得る。様々な状態遷移は以下のようになることがわかる。システムが最大レート状態1101（最大データレートが使用されていることを意味する）であることを仮定する。所定の閾値より大きいパケット損失は、速度低下状態1102への状態遷移1106を生じ得る。
【００８３】
速度低下状態において、システムは速度を減少させ、所定の閾値より大きいパケット損失を受け続けるか否かを検出するために待機する。閾値より大きいパケット損失が存在しない場合、システムは、速度上昇待機状態への遷移1108に従い得る。閾値より大きいパケット損失が存在し続け、最大数の速度低下の試行が使用されていない場合（ブロック1107）、システムは速度低下状態1102を続け、従って、ビットレートを減少させ続け得る。最大数の速度低下の試行が使用された場合、システムは常時損失状態1105に遷移する。
【００８４】
速度上昇待機状態において、所定の閾値より大きい更なるパケット損失は、システムを速度低下状態への遷移1109に従わせ得る。代替として、所定の期間の後に閾値より大きいパケット損失が存在しない場合、システムは、速度上昇状態1104への遷移1110に従い得る。
【００８５】
速度上昇状態1104において、システムは、ビットレートを増加させ、所定の閾値より大きい更なるパケット損失を待機し得る。パケット損失が存在しない場合、システムは、ビットレートが最大ビットレートより小さいか否かを決定し得る。小さい場合、システムは最大レート状態1101への遷移1111に従い得る。小さくない場合、システムは速度上昇状態1104を続け得る。速度上昇状態1104の間に所定の閾値より大きいパケット損失を受ける場合、システムは、所定の最大数の速度上昇の試行が行われたか否かを決定し得る（ブロック1112）。最大数の速度上昇の試行が行われていない場合、システムは、速度上昇待機状態への遷移1113に従い得る。最大数の速度上昇の試みが使用されている場合、システムは最大レート状態1101への遷移1114に従い得る。
【００８６】
前述の状態のそれぞれにおいて、異なるパケット損失閾値が使用されてもよい。更に、状態遷移の一部又は全てが、これらに関連する遅延を有してもよい。速度上昇は、ビットレートの15%ステップの増加で行われてもよい。パイプが完全に利用されており、パケット損失が報告されていない場合、次の速度上昇が生じる前にXタイマ周期（200ms*X）に等しくなり得る遅延がもたらされ得る。初期設定でXの値は2に設定され、400msの遅延を生じてもよい。連続的なパケット損失のレポートではなく、エコーレポートではない何らかのパケット損失は、状態遷移を生じ得る。
【００８７】
図１２は、動的に変化する帯域の可用性とDBA適合とを示している。図１２はまた、３つの一般的な損失のシナリオ（バースト損失、抑制されたパイプ及び常時損失）と共に、状態遷移、エコー遅延を示している。LPR保護の使用は、速度低下状態、速度上昇待機状態及び速度上昇状態の間の図１２の斜線の領域で示されている。速度上昇の試行は、輻輳上限をテストするために、LPR保護のオーバーヘッドを使用し得る。すなわち、ネットワーク輻輳状態が高いビットレートを許容するか否かを調べるために“冗長”データのみが使用されてもよい。輻輳上限のテストが失敗すると、“冗長”データのみが使用されているため、LPRはもたらされたパケット損失により生じた何らかの損失を保護する。このことにより、ビデオの中断のリスクを実質的に低減して、輻輳上限の調査が可能になる。
【００８８】
測定された輻輳上限は、完全にデータフローに適用可能である。例えば、複数のビデオストリームが送信されている場合、輻輳上限は総計ビットレートに適用し得る。前方消失保護は各ビデオストリームに独立して適用可能である。しかし、同じレベルの保護が全てのストリームに適用され得る。システムはまた、共通の前方消失訂正パケットでビデオストリームを併せて保護するように適合されてもよく、各ビデオストリームに異なるレベルの保護を適用するように適合されてもよい。
【００８９】
前方消失訂正はまた、ビデオストリームの一部のみに適用され得る。例えば、階層化ビデオ符号化が使用される場合、前方消失保護は、基本レイヤに適用されて、拡張レイヤに適用されなくてもよい。これはまた、様々なレイヤを異なる程度に保護するように適合されてもよい（いわゆる“不平等な保護（unequal protection）”）。これらの構成では、輻輳回避は全体データフローに当てはまる。
【００９０】
輻輳上限測定の例示的なLPRの調査（probe）がテーブル６に示されている。これらの調査は、所定値（例えば10%）だけデータレートを上昇させる可能性をテストするために使用され、短い期間（例えば800ms）の間に動作し得る。
【００９１】
【表６】
ここに記載された技術は、受信機が輻輳上限と消失保護レベルとを送信機にフィードバックという点で受信機主導でもよい。代替として、これらは、送信機主導のフレームワーク、又は制御ループが送信機と受信機との間で分散されるハイブリッド型フレームワークで使用され得る。何らかの適合で、マルチキャストストリームでの使用にも適する。記載された技術はまた、パケット再送信、周期的画像リフレッシュ及びビデオ誤り隠蔽のような他の技術と結合され得る。
【００９２】
前述のように、輻輳回避と前方消失訂正との組み合わせは、何れかの機構がそれ自体で実現できない固有の利点を提供する。１つのこのような利点は、ビットストリームでの前方消失保護パケットの量を実験的に増加させ、配信されたデータフローでの影響を観測することにより、輻輳上限が周期的に測定され得るという点にある。これらの保護パケットは、パケット損失からメディアを保護するのと同時に（レベルが輻輳上限を超える場合）、全体データレートを所望の“調査”レベルに増加させる。第２の利点は、輻輳上限を動的に測定するこの方法は、輻輳回避アルゴリズムで通常に使用されている受動的な方法により提供されるものより、許容帯域の非常に高速な決定を生じ得るという点にある。第３の利点は、全体フロー（メディア及び保護）が動的に測定された輻輳上限の下に留まるように抑制されたときに、保護されたメデイアフローが少ない遅延及び小さい保護オーバーヘッドで配信され得るという点にある。
【００９３】
ここに記載された技術の更なる利点は、ビデオデータレートが増加したときに、システムがパケット損失に対して保護するのに効率的になり得るという点にある。従って、高解像度ビデオの使用等でビットレートが増加すると、ここに記載された技術は、有用且つ効率的になる。
【００９４】
前方消失訂正と輻輳回避との統合は、複数の固有の利点を提供する。例えば、輻輳回避は、前方消失訂正に対して複数の固有の利点をもたらす。データリンクが混雑すると、そのリンクを通じた媒体の送信遅延が増加する。前方消失訂正のみを使用することは、許容可能なパケット損失率を生じ得るが、待ち行列遅延を低減しない。輻輳回避を制御ループに統合することにより、非常に小さい待ち時間で所望のサービス品質（QoS）を実現できる。更に、前方消失保護の効率は、大きい待ち時間のアプリケーションより小さい待ち時間のアプリケーションで小さくなる。データ損失の原因が簡単な輻輳である場合、ビットレートを低減することは、データフローに更なる前方消失訂正パケットを増加することより効率的になり得る。
【００９５】
逆に、前方消失訂正はまた、輻輳回避のみのものにかなりの価値を追加し得る。典型的には、輻輳回避技術は、データフローのレートを積極的に低減する。例えば、TCPの輻輳機構は、乗算係数だけデータレートを低減するが、加算係数を適用することにより非常に低く上がる。この理由は、データフローレートを増加することは、常に輻輳を生じるリスクがあり、従ってパケット損失を生成するからである。前方消失訂正が輻輳回避と統合されると、このリスクはかなり低減される。従って、前述のように、前方消失保護パケットの密度を単に増加させることにより、データレートが増加し得る。
【００９６】
更に、輻輳回避技術はまた、リンク速度を推定するように設計される。他のデータフローからの相互輻輳（cross-congestion）は、頻繁にパケット損失を生じ得る。相互輻輳が観測される時間までに、通常ではパケット損失は既に生じている。前方消失保護を含めることにより、このような相互輻輳によるパケット損失が回復可能になる。
【００９７】
ここに開示された技術は、マルチメディアデータ（ビデオデータ、オーディオデータ、静止画データ及び他の種類のデータ等）の送信用の何らかのシステムを含み、様々なシステムで使用され得る。このような技術は、典型的な汎用コンピュータシステム（デスクトップコンピュータ、ノートブックコンピュータ、ハンドヘルドコンピュータ、サーバ等）で使用され得る。代替として、これらの技術は、様々な装置形式のシステム（会議部屋のテレビ会議システム、デスクトップ型テレビ会議システム等）で使用され得る。ここに記載された技術はまた、インフラストラクチャ形式のテレビ会議装置（マルチポイント制御ユニット（MCU：multi-point control unit）、ブリッジ、メディアサーバ等）で使用され得る。
【００９８】
ここに記載された方法は、１つ以上のコンピュータプログラムにコード化され、コンピュータ可読媒体（コンパクトディスク、テープ、揮発性又は不揮発性メモリ等）に格納され得る。従って、プログラム記憶装置に格納された命令は、ここに記載された技術をプログラム可能制御装置（例えば、コンピュータ又は会議ユニット）に実行させるために使用され得る。開示された通信システムは、近端（near end）及び遠端（far end）の間の双方向通信を提供するものとして記載されているが、この開示の教示は一方向送信を提供するシステムにも適用可能であることがわかる。
【００９９】
好ましい実施例及び他の実施例の前述の説明は、出願人により考案された本発明の概念の範囲又は適用性を制限又は限定することを意図しない。ここに含まれる本発明の概念を開示する代わりに、出願人は特許請求の範囲により提供される全ての特許権を望む。従って、特許請求の範囲は、請求項又はその均等の範囲内にある全ての内容に対する全ての変更及び変形を含むことを意図する。
【０１００】
以上の実施例に関し、更に、以下の項目を開示する。
【０１０１】
（１）損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法であって、
損失パケット回復アルゴリズムを前記メディアストリームに適用し、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にし、
輻輳回避アルゴリズムを前記送信データストリームに適用し、前記輻輳回避アルゴリズムは、前記送信データストリームに挿入された冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させ、前記ネットワークが高いデータレートをサポートすることができるか否かを決定することを含む
ことを有する方法。
【０１０２】
（２）前記冗長情報は、１つ以上の回復パケットを有する、（１）に記載の方法。
【０１０３】
（３）回復パケット数は、RTCP受信レポートから決定されたチャネル損失率に依存する、（２）に記載の方法。
【０１０４】
（４）ネットワーク輻輳を回避するために必要に応じて総計ビットレートを低減することを更に有する、（１）に記載の方法。
【０１０５】
（５）前記損失パケット回復アルゴリズムは、前方消失訂正符号化を含む、（１）に記載の方法。
【０１０６】
（６）前記損失パケット回復アルゴリズムは、リードソロモン符号化を含む、（１）に記載の方法。
【０１０７】
（７）前記メディアストリームは、ビデオデータを有する、（１）に記載の方法。
【０１０８】
（８）ネットワークでメディアデータを送信するメディア符号化装置であって、
メディアエンコーダと、
前記メディアエンコーダからの出力を受信し、リアルタイム送信プロトコルに従って前記メディアエンコーダの出力を複数の発信元パケットとしてパッケージ化するように接続されたRTP送信機と、
前記ネットワークからチャネル情報を受信するように接続されたRTCPモジュールと、
前記RTCPモジュールから前記チャネル情報を受信するように通信可能に結合され、前記チャネル情報から使用されるLPR保護パラメータを決定するように適合され、前記LPR保護パラメータをLPRパケット化器に提供するように通信可能に結合されたLPRモード判定モジュールと、
RTP送信機からの出力を受信し、前記LPRモード判定モジュールから受信したパラメータを使用して前記RTP送信機の出力を複数のLPRデータパケットとして再パケット化するように接続されたLPRパケット化器と、
前記LPRパケット化器及び前記メディアエンコーダに結合され、前記LPRパケット化器及び前記メディアエンコーダから受信した情報に基づいてLPR回復パケットを生成するように適合され、前記LPRデータパケットと前記LPR回復パケットとを受信機に送信するように適合されたLPR回復パケット生成器と
を有するメディア符号化装置。
【０１０９】
（９）前記メディアエンコーダはビデオエンコーダである、（８）に記載のメディア符号化装置。
【０１１０】
（１０）前記LPRモード判定モジュールは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことによりLPR保護パラメータを決定する、（８）に記載のメディア符号化装置。
【０１１１】
（１１）各LPRデータパケットは、唯一の発信元パケットからの情報を含む、（８）に記載のメディア符号化装置。
【０１１２】
（１２）前記回復パケットのペイロードは、リードソロモン符号化を使用して符号化される、（８）に記載のメディア符号化装置。
【０１１３】
（１３）パケット型ネットワークで行われるメディア会議のLPR保護パラメータを決定する方法であって、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことを有する方法。
【０１１４】
（１４）前記保護期間は、前記メディア会議のビットレートに従って決定される、（１３）に記載の方法。
【０１１５】
（１５）メディアレートの関数としてLPR保護パラメータを調整することを更に有する、（３）に記載の方法。
【０１１６】
（１６）前記メディアレートの関数としてLPR保護パラメータを調整することは、グループ毎のパケット数を動的に適合させることを有する、（１５）に記載の方法。
【０１１７】
（１７）前記メディアレートの関数としてLPR保護パラメータを調整することは、パケットサイズを動的に適合させることを有する、（１５）に記載の方法。
【０１１８】
（１８）前記メディアレートの関数としてLPR保護パラメータを調整することは、空のデータパケットを送信することを有する、（１５）に記載の方法。
【０１１９】
（１９）ネットワークで送信機からメディアデータを受信するメディア復号化装置であって、
前記ネットワークから、LPRデータパケットとLPR回復パケットとを含むLPRパケットを受信するように結合されたLPR回復モジュールと、
前記LPRデータパケットを受信し、何らかの損失データパケットを再生成するように適合されたLPR再生成器と、
前記LPR再生成器に通信可能に結合され、前記LPR再生成器から損失パケットのレポートを受信し、損失パケット情報を前記送信機に送信するRTCPモジュールと、
前記LPR再生成器に結合され、前記LPRデータパケットと前記再生成されたデータパケットとを受信し、含まれるメディア情報をデコードするように結合されたメディアデコーダと
を有するメディア復号化装置。
【０１２０】
（２０）前記メディアデコーダはビデオデコーダである、（１９）に記載のメディア復号化装置。
【０１２１】
（２１）前記LPR回復モジュール及び前記LPR再生成器は、LPRアルゴリズムが使用中でないときにパススルーとして動作する、（１９）に記載のメディア復号化装置。
【特許請求の範囲】
【請求項１】
損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法であって、
損失パケット回復アルゴリズムを前記メディアストリームに適用するステップであり、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にするステップと、
輻輳回避アルゴリズムを前記送信データストリームに適用するステップと
を有し、
所定の期間の間に第１の所定の閾値より上のパケット損失が存在しない状態において、前記輻輳回避アルゴリズムは、
前記送信データストリームに挿入される冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させるステップと、
パケット損失を含む前記ネットワークからのチャネル情報を受信し、前記ネットワークが前記送信データストリームのより高いデータレートをサポート可能であるか否かを決定するために前記パケット損失を監視するステップと、
前記パケット損失が第２の所定の閾値の下に留まる場合、前記送信データストリームの前記より高いデータレートを維持しつつ、前記メディアストリームのビットレートを増加させるステップと
を含む方法。
【請求項２】
前記冗長情報は、１つ以上の回復パケットを有する、請求項１に記載の方法。
【請求項３】
回復パケット数は、RTCP受信レポートから決定されたパケット損失に依存する、請求項２に記載の方法。
【請求項４】
前記損失パケット回復アルゴリズムは、前方消失訂正符号化又はリードソロモン符号化を含む、請求項１ないし３のうちいずれか１項に記載の方法。
【請求項５】
前記メディアストリームは、ビデオデータを有する、請求項１に記載の方法。
【請求項６】
損失パケット回復アルゴリズムを前記メディアストリームに適用するステップは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことを有する、請求項１に記載の方法。
【請求項７】
前記保護期間は、前記メディアストリームのビットレートに従って決定される、請求項６に記載の方法。
【請求項８】
前記メディアストリームのビットレートの関数として損失パケット回復保護パラメータ（LPR保護パラメータ）を調整するステップを更に有する、請求項６又は７に記載の方法。
【請求項９】
前記メディアストリームのビットレートの関数としてLPR保護パラメータを調整するステップは、データ及び／又は回復パケットのパケットサイズを動的に適合させること、又は空のデータパケットを送信することを有する、請求項８に記載の方法。
【請求項１０】
メディアエンコーダと、１つ以上の損失パケット回復モジュールとを有し、損失のあるネットワークを通じて送信されたメディアストリームの破損を回避するメディア符号化装置であって、
前記１つ以上の損失パケット回復モジュールは、
損失パケット回復アルゴリズムを前記メディアストリームに適用し、ただし、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にし、
輻輳回避アルゴリズムを前記送信データストリームに適用するように構成され、
所定の期間の間に第１の所定の閾値より上のパケット損失が存在しない状態において、前記輻輳回避アルゴリズムは、
前記送信データストリームに挿入される冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させ、
パケット損失を含む前記ネットワークからのチャネル情報を受信し、前記ネットワークが前記送信データストリームのより高いデータレートをサポート可能であるか否かを決定するために前記パケット損失を監視し、
前記パケット損失が第２の所定の閾値の下に留まる場合、前記送信データストリームの前記より高いデータレートを維持しつつ、前記メディアストリームのビットレートを増加させるように適合されるメディア符号化装置。
【請求項１１】
前記チャネル情報から損失パケット回復保護パラメータ（LPR保護パラメータ）を決定するように更に構成される、請求項１０に記載のメディア符号化装置。
【請求項１２】
前記メディア符号化装置はビデオエンコーダである、請求項１０又は１２に記載のメディア符号化装置。
【請求項１３】
前記LPR保護パラメータは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことにより決定される、請求項１１又は１２に記載のメディア符号化装置。
【請求項１４】
前記回復パケットのペイロードは、リードソロモン符号化を使用して符号化される、請求項１２又は１３に記載のメディア符号化装置。
【請求項１】
損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法であって、
損失パケット回復アルゴリズムを前記メディアストリームに適用するステップであり、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にするステップと、
輻輳回避アルゴリズムを前記送信データストリームに適用するステップと
を有し、
所定の期間の間に第１の所定の閾値より上のパケット損失が存在しない状態において、前記輻輳回避アルゴリズムは、
前記送信データストリームに挿入される冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させるステップと、
パケット損失を含む前記ネットワークからのチャネル情報を受信し、前記ネットワークが前記送信データストリームのより高いデータレートをサポート可能であるか否かを決定するために前記パケット損失を監視するステップと、
前記パケット損失が第２の所定の閾値の下に留まる場合、前記送信データストリームの前記より高いデータレートを維持しつつ、前記メディアストリームのビットレートを増加させるステップと
を含む方法。
【請求項２】
前記冗長情報は、１つ以上の回復パケットを有する、請求項１に記載の方法。
【請求項３】
回復パケット数は、RTCP受信レポートから決定されたパケット損失に依存する、請求項２に記載の方法。
【請求項４】
前記損失パケット回復アルゴリズムは、前方消失訂正符号化又はリードソロモン符号化を含む、請求項１ないし３のうちいずれか１項に記載の方法。
【請求項５】
前記メディアストリームは、ビデオデータを有する、請求項１に記載の方法。
【請求項６】
損失パケット回復アルゴリズムを前記メディアストリームに適用するステップは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことを有する、請求項１に記載の方法。
【請求項７】
前記保護期間は、前記メディアストリームのビットレートに従って決定される、請求項６に記載の方法。
【請求項８】
前記メディアストリームのビットレートの関数として損失パケット回復保護パラメータ（LPR保護パラメータ）を調整するステップを更に有する、請求項６又は７に記載の方法。
【請求項９】
前記メディアストリームのビットレートの関数としてLPR保護パラメータを調整するステップは、データ及び／又は回復パケットのパケットサイズを動的に適合させること、又は空のデータパケットを送信することを有する、請求項８に記載の方法。
【請求項１０】
メディアエンコーダと、１つ以上の損失パケット回復モジュールとを有し、損失のあるネットワークを通じて送信されたメディアストリームの破損を回避するメディア符号化装置であって、
前記１つ以上の損失パケット回復モジュールは、
損失パケット回復アルゴリズムを前記メディアストリームに適用し、ただし、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、１つ以上の損失パケットの再構成を可能にし、
輻輳回避アルゴリズムを前記送信データストリームに適用するように構成され、
所定の期間の間に第１の所定の閾値より上のパケット損失が存在しない状態において、前記輻輳回避アルゴリズムは、
前記送信データストリームに挿入される冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させ、
パケット損失を含む前記ネットワークからのチャネル情報を受信し、前記ネットワークが前記送信データストリームのより高いデータレートをサポート可能であるか否かを決定するために前記パケット損失を監視し、
前記パケット損失が第２の所定の閾値の下に留まる場合、前記送信データストリームの前記より高いデータレートを維持しつつ、前記メディアストリームのビットレートを増加させるように適合されるメディア符号化装置。
【請求項１１】
前記チャネル情報から損失パケット回復保護パラメータ（LPR保護パラメータ）を決定するように更に構成される、請求項１０に記載のメディア符号化装置。
【請求項１２】
前記メディア符号化装置はビデオエンコーダである、請求項１０又は１２に記載のメディア符号化装置。
【請求項１３】
前記LPR保護パラメータは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことにより決定される、請求項１１又は１２に記載のメディア符号化装置。
【請求項１４】
前記回復パケットのペイロードは、リードソロモン符号化を使用して符号化される、請求項１２又は１３に記載のメディア符号化装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−２３５５２３（Ｐ２０１２−２３５５２３Ａ）
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願番号】特願２０１２−１７０９４１（Ｐ２０１２−１７０９４１）
【出願日】平成２４年８月１日（２０１２．８．１）
【分割の表示】特願２００８−１８９２１１（Ｐ２００８−１８９２１１）の分割
【原出願日】平成２０年７月２２日（２００８．７．２２）
【出願人】（５０００８０７２０）ポリコム・インコーポレイテッド (22)
【Ｆターム（参考）】
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願日】平成２４年８月１日（２０１２．８．１）
【分割の表示】特願２００８−１８９２１１（Ｐ２００８−１８９２１１）の分割
【原出願日】平成２０年７月２２日（２００８．７．２２）
【出願人】（５０００８０７２０）ポリコム・インコーポレイテッド (22)
【Ｆターム（参考）】
[ Back to top ]