JP2013085293A - インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法 - Google Patents

Abstract

【課題】インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法を提供する。
【解決手段】メディアパケットからメディアビット列を生成し、生成されたメディアビット列を通じて前方誤り訂正符号を適用し、少なくとも１つの前方誤り訂正ビット列を生成し、少なくとも１つの前方誤り訂正ビット列から少なくとも１つの前方誤り訂正パケットを生成する。また、受信したメディアパケットからメディアビット列を形成し、受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成し、形成されたメディアビット列及び前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得し、回復したメディアビット列から損失メディアパケットを回復する。
【選択図】図６

Description

本発明は、概して、インターネットプロトコル（IP：internet protocol）ネットワークで送信されるリアルタイムのオーディオ及びビデオデータの前方誤り訂正（FEC：forward error correction）に関し、特に、IPネットワークで送信されたリアルタイムのオーディオ及びビデオのFECをサポートするシグナリング方法及びこのシグナリング方法をサポートする構文（syntax）に関する。

パケットは、IPネットワークでの送信中に損失することがある。しかし、パケット損失は、リアルタイムのビデオ及びオーディオアプリケーションのような多くのネットワークアプリケーションで許容できない。アプリケーションレイヤの前方誤り訂正（FEC）は、受信機／デコーダで損失メディア／データ／ソースパケットを回復する方法を提供する。ここで用いられる“／”は、同じ又は同様の構成要素の代替名を示す。FEC符号は、トランスポート又はアプリケーションレイヤでソースパケットを通じて適用され、ネットワークの送信機／エンコーダ又は他のノードで、冗長な情報を含むFECパケットを生成する。これらのFECパケットは、受信機に送信され、受信機は、受信したFECパケットの冗長な情報を使用して損失ソースパケットを回復する。

送信機／エンコーダで冗長性を生成するために、異なる符号化方法及び異なるFEC符号が使用され得る。受信機／デコーダは、損失ソースパケットをデコード及び回復するために、符号化方法及びパラメータについての情報を有する必要がある。従って、送信機／エンコーダがFEC符号化情報に関して受信機／デコーダに通知するために、シグナリング方法及び構文が必要になる。

リアルタイムトランスポートプロトコル（RTP：real-time transport protocol）及びユーザデータグラムプロトコル（UDP：user datagram protocol）は、一般的にIPネットワークでリアルタイムのビデオ／オーディオに使用されている。ペイロード（ソースパケット）は、RTP/UDP/IPプロトコルスタックでカプセル化される。一般的なFECパケットのRTPペイロードフォーマットはRFC2733に規定されており、リアルタイムのメディアの誤り訂正を可能にする。しかし、RFC2733は、FECペイロードを生成するために使用されるパケットの範囲を24の連続したパケットに制限し、メディア／ソース／データパケットのブロックについて１つのFECパケットの生成のみを可能にする。

SMPTE（Society of Motion Picture and Television Engineers）標準2002-1は、RFC2733への拡張を規定しており、これは、誤り訂正符号が、バースト損失の回復のために、24より多くのソース／メディアパケットに広がり得る不連続のメディアパケットに適用されることを可能にする。しかし、SMPTE 2002-1により、メディアパケットのブロックでの排他的論理和（XOR）符号化は、唯一のパケット損失がパケットの符号化ブロックで訂正され得るように、単一のFECパリティパケットしか生成可能にしない。IPネットワークでは（特に無線リンクを有するIPネットワークでは）、パケット損失は非常に高くなる可能性がある。このため、IPネットワークで送信されたリアルタイムのオーディオ及びビデオのパケット損失を適切に検出して訂正するために、強力な誤り訂正機能を有するFEC符号化方式が必要になる。更に、SMPTE 2002-1では、FECパケットのシグナリング方法及び構文は、符号化ブロックのパケットの総数（メディア+FEC）を含まない。すなわち、FECブロックサイズはヘッダに含まれない。従って、送信機／エンコーダは、FECブロックサイズ情報に関して受信機／デコーダに通知することができない。より強力なFEC(N,K)符号では、符号化ブロックのパケットの総数の値（すなわち、ブロックサイズ）はNであり、符号化ブロックで保護されるメディアパケットの数はKである。例えば、Kのメディアパケットがリードソロモン(N,K)符号でN-KのFECパケットを生成するために符号化される場合、Nの符号化パケットのブロックの中でN-Kまでのパケット損失が回復可能である。XOR符号化では、ブロックサイズNは、保護されるメディアパケットの数から得られ得る。すなわち、XOR符号化はKの保護されるメディアパケットから単一のFECパケットのみを生成し、１つのパケット損失のみを訂正するため、Nは常にK+1に等しい。しかし、これは、より強力な誤り訂正機能を有するFEC(N,K)符号には当てはまらない。XOR符号化とは異なり、FEC(N,K)符号のブロックサイズNは、独立したパラメータであり、直接的にKに関係しないことがある。Nは、損失パケットを正確に回復するために、受信機／デコーダで既知でなければならない。SMPTE 2002-1標準は、復号／回復動作についてFECブロック情報を必要とするFEC(N,K)符号のパラメータのシグナリングをサポートするのには十分でない。

従って、IPネットワークでのリアルタイムのビデオ／オーディオ伝送のために、より強力なFEC符号（例えば、RS符号）をサポートするFECヘッダの新しいデータ構造／構文が有利である。FECヘッダの新しいデータ構造／構文に関して、メディアパケットのRTPヘッダ及びペイロードが適切に保護され得るような、送信機での新しい保護／符号化方法が必要になる。更に、受信機での新しい回復方法が必要になる。

本発明は、IPネットワークで送信されたリアルタイムのオーディオ及びビデオのFECをサポートするシグナリング方法及び構文を提供する。更に、本発明は、送信機／エンコーダでソースパケットにFEC符号化を適用してFECパケットを生成する方法を提供し、受信機／デコーダで損失ソースパケットを回復する方法を提供する。本発明による方法を説明するためにリードソロモン符号化が一例として使用されているが、本発明は、他のFEC符号化方式にも同様に適用可能である。

リアルタイムメディアを保護する方法及び装置が記載され、メディアパケットを受信し、メディアパケットからメディアビット列を生成し、生成されたメディアビット列を通じて前方誤り訂正符号を適用し、少なくとも１つの前方誤り訂正ビット列を生成し、少なくとも１つの前方誤り訂正ビット列から少なくとも１つの前方誤り訂正パケットを生成することを含む。また、リアルタイムメディアパケットの損失から回復する方法及び装置が記載され、受信したメディアパケットからメディアビット列を形成し、受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成し、形成されたメディアビット列及び前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得し、回復したメディアビット列から損失メディアパケットを回復することを含む。更に、コンピュータ可読媒体での前方誤り訂正ヘッダのデータ構造が記載され、このデータ構造は、前方誤り訂正パリティパケットのインデックスの所定数の上位ビットを格納するフィールを含む。更に、コンピュータ可読媒体での前方誤り訂正ヘッダのデータ構造が記載され、このデータ構造は、前方誤り訂正パケット及びメディアパケットの総数を示すフィールドを含む。

送信機／エンコーダでの処理 本発明による符号化方式 本発明による代替の符号化方式 本発明によるFECパケット構造 本発明によるFECヘッダ 本発明に従って送信機／エンコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする保護方法のフローチャート 本発明に従って受信機／デコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする回復方法のフローチャート 本発明に従って送信機／エンコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする符号化／保護方法の概略図 本発明に従って受信機／デコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする回復方法の概略図

本発明は、添付図面と共に読まれたときに以下の詳細な説明から最も良く理解できる。

FEC符号の形式に加えて、FEC符号は、ブロックサイズN及びソースシンボル数Kのようなパラメータにより指定される。(N,K)システマティックFEC符号がKのメディア／ソース／データパケットを通じて適用されると、N-KのFECパケットが生成される。例えば、リードソロモン（RS：Reed-Solomon）符号は、周知の消去訂正符号である。KのメディアパケットがRS(N,K)符号でN-KのFECパケットを生成するために符号化される場合、Kのパケットの何らかの一部は、消去訂正でメディアデータを再構成するのに十分である。すなわち、RS(N,K)符号は、Nの符号化パケットのブロックの中でN-Kまでのパケット損失からの回復を可能にする。全体パケットは、下位レイヤ（媒体アクセス制御レイヤ、IPレイヤ又はUDPレイヤ等）により破棄されるため、単一のビット誤りが存在する場合であっても、パケットは、UDPレイヤの上（すなわち、RTP又はアプリケーションレイヤ）に正確に到達する、或いは全く到達しない。本発明の方法は、UDPレイヤの上にある。本発明では、パケットが正確に受信される、或いは損失することを仮定する。パケットが損失する場合、損失パケットの位置は、RTPヘッダのシーケンス番号からわかる。

図１を参照すると、メディア／ソースデータ（オーディオ及び／又はビデオデータ等）は、RTPパケット化器105によりパケット化され、RTPヘッダでカプセル化される。FEC符号は、FEC符号化処理110により複数のメディアパケットを通じて適用され、FECパケットを生成する。メディアパケット及び更なるFECパケットは、通信インタフェース125でUDP/IPプロトコルスタック115、120を通じて送信される。FEC不可能なシステムとの後方互換性のために、メディアパケットのフォーマットは、本発明のFEC符号化処理により変更されない。すなわち、メディアパケットは、依然としてFEC不可能なシステムにより受信して回復可能である。FECパラメータに関するシグナリング情報は、FECパケットで伝達される。メディアパケット及びFECパケットは、異なるUDPポートを使用して送信されてもよい。従って、非FECシステムは、メディアパケットに使用されたUDPポートからメディアパケットのみを受信する。FECパケットはまた、RTPヘッダの異なるペイロード形式により指定されてもよい。代替実施例では、FECパケット及びメディアパケットは、これらのペイロード形式により区別されてもよい。非FECシステムは、ペイロード形式を認識できない場合に、FECパケットを破棄する。

本発明の方式は、符号化ブロックでの複数のパケット損失から回復することができる。RS(N,K)符号に基づく１次元の方式が使用される場合（すなわち、RS(N,K)符号がKの連続したメディアパケットを通じて適用される場合）、N-K以下の損失メディアパケットのバースト誤りが回復可能である。

本発明の符号化方法の前に、メディアRTPパケットが並び替えられてもよい。図２を参照すると、L×Dのメディアパケットは２次元行列を形成する。符号化ブロックのメディアパケットは定期的に選択されてもよい。すなわち、FECパケットは、L（L>=1）の値だけ増加するシーケンス番号を用いて、メディアRTPパケットを通じて生成されてもよい。Lは保護されるパケットの列の数を示し、Dは保護されるパケットの行の数を示す。２次元方式のFEC符号化方式が使用される場合、L×(N-K)までの連続した損失パケットを回復することができるため、バースト誤りの回復が更に改善する。送信機では、同じFECパケットにより保護されたメディアパケットは、他のFECパケットにより保護されたLのパケットにより分離され、これにより、バーストが生じた場合に、符号化ブロックでの誤りパケットの数を低減する。受信機で復号化する前に、受信パケットは、図２に示すように並び替えられる。従って、連続したRTPパケットは、異なるFECパケットから回復され得る。

図２では、L*Dのメディアパケットの符号化方式が示されている。所定のFEC(N,K)（例えば、RS）符号によりカバーされるメディアパケットの間で選択される期間はLである。従って、FECパケット(h,m)（ｈ=0,1,...N-K-1;m=0,1...L-1）のペイロードは、iL+m（0≦i≦D-1）の番号のDのパケット（D=K）に基づいて計算される。１次元の方式（すなわち、FEC(N,K)をKの連続するメディアパケットに適用すること）は、Lが1に等しい場合の２次元の方式の特別な場合である。列の配列は説明上の例示である。FEC列ストリームを生成するためにデータパケットを構成する他の方法も考えられる。

２つの同時のFECストリームもサポート可能である。これは、オーバーヘッドの増加を犠牲にして、更に高い誤り訂正機能を可能にする。これらのFECストリームは、別のUDPポートで伝達され、別のRTPシーケンス番号の処理を有し、単一のFECストリームのみをサポートする受信機との後方互換性を維持してもよい。一例として、低い番号のポートは、列FECストリームを伝達し、第２のポートは、行FECストリームを伝達してもよい。

列FECストリーム（第１のストリーム）及び行FECストリーム（第２のストリーム）は、異なるFEC符号を使用して生成されてもよい。行FECストリームは、長さのパラメータLを用いて、連続したパケットの行に適用される。列が配列されると、図３に示すようなFEC構造を生成する（RTPのラベルのパケットがメディアパケットであり、FECのラベルのパケットがFEC(N,K)符号（K=D）により生成された列FECストリームパケットであり、FEC’のラベルのパケットがFEC(N’,K’)符号（K’=L）により生成された行FECストリームである）。

受信機／デコーダは、FECに関する制御情報と、FECパケットとFECパケットにより保護されたメディアパケットとの間の関連性情報とに関して通知される必要がある。これにより、受信機／デコーダは、FECブロックを正確に復号化し、何らかの損失メディアパケットを回復することができる。この情報は、FECパケットのFECヘッダで伝達される。FECパケットの基本フォーマットは図４に示されている。FECデータはRTPペイロード420である。RTPヘッダ405の後にFECヘッダ410があり、次にFECペイロード415がある。FECヘッダは、他の情報に加えて、FEC形式と、FEC符号化動作から生じたパケット（メディア+FEC）の総数（すなわち、FECブロックサイズ）、FECパケットに関連するメディアパケットの数、FECパケットに関連するメディアパケットの最小シーケンス番号、このFECパケットに関連するメディアパケットを選択するために使用される期間、FECパケットインデックス、列FECストリーム及び行FECストリームの指標を含む。FECヘッダはまた、メディアパケットのRTPヘッダを回復するための長さ回復、ペイロード形式回復及びタイムスタンプ回復のフィールドを含む。図５を参照すると、以下のフィールドの定義で、例示的なFECヘッダが示されている。
・SNBase低ビット（SNBase low bits）：これは、FECパケットに関連するパケットの最小シーケンス番号である。16のシーケンス番号が十分である場合、このパラメータは、全体のシーケンス番号を含む。長いシーケンス番号のトランスポートプロトコルでは、このフィールドは、シーケンス番号の最小位の16ビットを含む。
・長さ回復（Length Recovery）：このフィールドは、FECパケットに関連する何らかの損失メディアパケットの長さを回復するために使用される。
・E：このフィールドは、ヘッダが拡張可能であるか否かを示す。これは、ヘッダが拡張されることを示すために1に設定される。
・PT回復：このフィールドは、FECパケットに関連する何らかの損失メディアパケットのペイロード形式を回復するために使用される。
・インデックス拡張（Index ext）：このフィールドは、FECパリティパケットインデックスの最上位5ビットを含む。N-K<8のFEC(N,K)符号では、この値は0である。
・予備（Reserved）：このフィールドは使用されない。これは、将来の拡張のために確保され、0に設定される。受信機はこのフィールドの値を無視する。
・総数（Total_no）：このフィールドは、FEC符号化動作から生じたパケット（メディア+FEC）の総数（すなわち、FECブロックサイズ）を示す。FEC(N,K)（例えば、RS）符号では、このフィールドの値はNに等しい。
・TS回復（TS Recovery）：このフィールドは、FECパケットに関連する何らかの損失メディアパケットのタイムスタンプを回復するために使用される。
・N：このビットは、将来のヘッダ拡張のために確保され、0に設定される。
・D：このビットは、どのFECパケットがどのFECストリームに関連するかを決定する更なる手段として提供される。列（第１の）FECストリームからのFECパケットでは0に設定され、行（第２の）FECストリームからのFECパケットでは1に設定される。
・形式（Type）：このフィールドは、どの誤り訂正符号が選択されたかを示し、8ビットのRS符号が使用される場合に2に設定される。受信機は、認識できない形式の値を有するパケットを無視する。特定のFECを復号化する機能のない受信機は、FECパケットを無視する。
・インデックス（Index）：このフィールドは、FECパケットインデックスの最小位の3ビットを含む。
・オフセット（Offset）：このフィールドは、このFECパケットに関連するメディアパケットを選択するために使用され、図３に示す列で計算されるパケット（第１のFECストリーム）では、行列の列の数（Lパラメータ）である。行で計算されるパケット（第２のFECストリーム）では、このパラメータは常に1である。このフィールドは、適応的FECでは各FECストリームのセッション中に変更されてもよい。
・NA：このフィールドは、FEC(N,K)符号で符号化されたFECパケットに関連するメディアパケットの数を示し、図３に示す第１のFECストリームに属するパケットでは、行列の行の数（Dパラメータ）であり、第２のFECストリームに属するパケットでは列の数（Lパラメータ）に対応する。第１のFECストリーム及び第２のFECストリームは、異なるN及び／又はKのパラメータを有するFEC符号により生成されてもよい。第１のFECストリームでは、Kの値はDに等しく、第２のFECストリームでは、Lに等しい。このフィールドは、適応的FECでは各FECストリームのセッション中に変更されてもよい。
・SNBase拡張ビット（SNBase ext bits）：このフィールドは、16ビットより長い拡張シーケンス番号を必要とするプロトコルで使用される。16ビットのシーケンス番号が十分である場合、このパラメータは0に設定される。長いシーケンス番号を有するプロトコルでは、このフィールドは、シーケンス番号の最上位の8ビットを含む。すなわち、SNBase低ビットフィールドは、シーケンス番号の下位16ビットを含み、このフィールドは、シーケンス番号の下位16ビットより高い8ビットを含む。

インデックス拡張フィールド及び総数フィールドは、IPネットワークで送信されたリアルタイムのオーディオ及びビデオデータについてブロックサイズN及び保護されたメディアパケットの数Kでの強力なFEC符号のサポートに適応するために、本発明により追加された新しいフィールドである。所定のFECパケットにより保護されたメディアパケットは、以下の式により与えられるシーケンス番号を有するものとして規定される。
SNBase+j×Offset
0≦j＜NA
１つのFECパケットが受信機／デコーダにより受信されるとすぐに、FECに関する制御及び関連性情報がFECヘッダから取得され得る。

メディアパケットのRTPヘッダ及びペイロードの双方が保護される。図６を参照すると、FEC保護／符号化方法がフローチャートを使用して示されている。FEC保護方法は、605において、メディアパケットのRTPヘッダ及びペイロードから特定のフィールドを連結することにより保護されるメディアパケット毎のビット列を生成し、610において、ゼロを有する生成されたビット列を最も近い倍数のシンボルにパディング（padding）し、615において、ゼロを有するビット列を符号化ブロックで保護される最も長いビット列の長さにパディングし、620において、メディアビット列を通じてFEC符号を適用し、FECビット列を生成し、625において、FECビット列からFECパケットを生成することを含む。

本発明は、メディアパケットからビット列を形成する方法を提供する。保護／符号化動作について以下の手順に従う。保護されるメディアパケット毎に、ビット列は、指定の順序で以下のフィールドを連結することにより生成される。
・マーカービット（1ビット）（マークビットの値は0である）
・ペイロード形式（7ビット）
・タイムスタンプ（32ビット）
・メディアペイロードの長さ（バイト単位）の符号なしのネットワーク順の16ビット表現（16ビット）
・ペイロード（可変長）
ビット列の長さがRSシンボルの倍数に等しくない場合、ビット列は、最も近い倍数のシンボルにパディングされる。このパッドの値はゼロである。パッドは、ビット列の最後に追加される。ビット列の長さが等しくない場合、最も長いビット列の長さより短い各ビット列は、最も長いビット列の長さにパディングされる。このパッドの値もゼロである。パッドはビット列の最後に追加される。それぞれ生じたビット列は同じ長さであり、Sのシンボルを含む。

FEC(N,K)符号（例えば、RS符号）は、Kのメディアビット列を通じて適用され、それぞれサイズSのシンボルの(N-K)のFECビット列を生成する。N-Kの生成されたFECビット列は、N-KのFECパケットを取得するために使用される。FECビット列毎に、FECビット列の最初（最上位）のビットは、FECパケットのRTPヘッダのマーカービットに書き込まれる。FECビット列の次の7ビットは、FECパケットヘッダのPT回復フィールドに書き込まれる。FECビット列の次の32ビットは、FECパケットヘッダのTS回復フィールドに書き込まれる。次の16ビットは、FECパケットヘッダの長さ回復フィールドに書き込まれる。残りのビットは、FECパケットのペイロードに設定される。FEC符号化ブロックのFECパケットの位置は、0からN-K-1にインデックス化される。FECパケットのインデックスの下位3ビットは、FECヘッダのインデックスフィールドに挿入され、上位5ビットは、インデックス拡張フィールドに挿入される。FECヘッダの総数はNに設定される。

FECパケットにより、受信機／デコーダは、メディアパケットの損失から回復することが可能になる。本発明は、受信機でパケット損失から回復する方法を提供する。それぞれ個々のFECパケットヘッダは、FECブロックサイズ、基礎シーケンス番号（SNbase）、オフセット、保護されたメディアパケットの数（NA）、及びFECパケットインデックスを示す。受信機は、各FECパケットでこれらの送信された値を取り出し、FECパケットを元のメディアパケットに正確に関連付け、パケットを回復する正確な位置に配置する。パケット（メディア及びFEC）は正確に配列される。RS FEC復号化は、受信したメディア及びFECパケットから取得されたビット列で実行され、損失パケットを回復する。図７を参照すると、本発明は、以下のようにパケットから回復する方法を提供する。
・705において前述した処理を逆にすることにより、受信したメディアパケットからメディアビット列を形成する。
・FECパケットでは、710で指定した順序で以下のフィールドを連結することにより、ビット列が生成される。
○マーカービット（1ビット）
○PT回復（7ビット）
○TS回復（32ビット）
○長さ回復（16ビット）
○FECペイロード（可変長）
・メディアパケットから生成されたいずれかのビット列がFECパケットから生成されたビット列より短い場合、715において、FECパケットから生成されたビット列と同じ長さになるようにパディングする。パディングはビット列の最後に追加され、パディングの値は0である。
・720において、ビット列を通じてRS復号化を実行し、回復したビット列を生じる。
・725において、それぞれ回復したビット列からそれぞれ回復したパケットを取得する。
○標準的な12バイトのRTPヘッダを有し、ペイロードを有さない回復したパケットを生成する。
○新しいパケットのバージョンを2に設定する。
○P、X、CC及びMのフィールドの値を設定する。
○回復したビット列の最初のビットを破棄する。
○回復したパケットのペイロード形式を回復したビット列の次の7ビットに設定する。
○符号化ブロックのSNBase、オフセット及び回復したビット列の位置に従って、回復したパケットのSNフィールドを設定する。回復したパケットが符号化ブロックの第jのメディアパケットである場合、そのSNはSNBase+(j-1)×Offset（1≦j≦NA）に等しい。
○回復したパケットのTSフィールドを回復したビット列の次の32ビットに設定する。
○（ネットワーク順及び符号なし整数を仮定して）回復したビット列の次の16ビットは、ペイロードの長さを表す。以下の回復したビット列から回復したビット列のこれらの16ビットにより表されるバイトの数を受け取り、これらを回復したパケットに付加する。これはペイロードを表す。
○回復したパケットのSSRCを、保護しているメディアストリームのSSRCに設定する。
この方法は、RTPパケットのヘッダ及びペイロードの双方を完全に回復する。

時間と共に送信レートの大きな変化を回避するようにFECパケットがデータパケットでインターリーブされることを確保するために、何らかのインターリーブ及びパケット送信スケジューリングアルゴリズムが使用され得る。例えば、送信機のFEC処理モジュールは、メディアパケットを受信すると直ちにメディアパケットを通過し、ローカルのコピーを保持してもよい。符号化ブロックの十分なメディアパケットが受信されたとき又はタイマが終了したとき、FECパケットを生成し、これらを送出する。全ての場合において、それぞれ個々のFECパケットはFECブロックサイズ、基礎シーケンス番号（SNbase）、オフセット、及びデータパケットの数（NA）、並びにFECパケットインデックスを示す点に留意すべきである。受信機は、各FECパケットでこれらの送信された値を取り出し、FECパケットを元のデータストリームのパケットに正確に関連付け、回復のためにパケットを正確な位置に配置する。

図８は、本発明に従って送信機／エンコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする符号化／保護処理の概略図である。FEC保護／符号化処理は、RTPパケット化モジュール805により、メディアパケットのRTPヘッダ及びペイロードから特定のフィールドを連結することにより、保護されるメディアパケット毎のビット列を生成し、ゼロを有する生成されたビット列を最も近い倍数のシンボルにパディングし、ゼロを有するビット列を符号化ブロックで保護される最も長いビット列の長さにパディングすることを含む。次に、FEC符号は、FEC符号化及びパケット化モジュール810により、メディアビット列を通じて適用され、FECビット列を生成し、FECビット列からFECパケットを生成する。メディアパケット及びFECパケットは、UDP/IPプロトコルスタック815を通じてネットワークインタフェース820で通信される。RTPパケット化モジュール815、FEC符号化及びパケット化モジュール810、UDP/IPプロトコルスタック815及びネットワークインタフェース820は、全てセッション制御モジュール825と通信し、これにより制御される。

図９は、本発明に従って受信機／デコーダにおいてIPネットワークでリアルタイムのオーディオ及びビデオのFECをサポートする回復処理の概略図である。メディア及びFECパケットは、ネットワークインタフェース905により受信される。ネットワークインタフェースは、受信したメディアパケット及びFECパケットをUDP/IPプロトコルスタック910に転送する。UDP/IPプロトコルスタック910は、メディアパケット及びFECパケットをFEC復号化及びパケット化解除モジュール915に転送する。FEC復号化及びパケット化解除モジュール915は、FECパケットヘッダのフィールドを分離して解釈し、受信したメディアパケット及びFECパケットをFEC符号化ブロックに正確な順序で配置し、形成されたメディアパケットからのメディアビット列及び受信したFECパケットからのFECビット列を形成する。次に、RS復号化がビット列を通じて実行され、回復したビット列を生じる。このように、回復したパケットは、回復したビット列から得られる。FEC復号化及びパケット化解除モジュールは、データをRTPパケット化解除モジュール920に転送し、RTPパケット化解除モジュール920は、RTPパケットからRTPヘッダ情報及びRTPペイロードデータを取得する。ネットワークインタフェース905、UDP/IPプロトコルスタック910、FEC復号化及びパケット化解除モジュール915及びRTPパケット化解除モジュール920は、全てセッション制御モジュール925と通信し、これにより制御される。

本発明は、様々な形式のハードウェア、ソフトウェア、ファームウェア、専用目的プロセッサ又はこれらの組み合わせで実装されてもよい。本発明は、ソフトウェアとハードウェアとの組み合わせとして実装されることが好ましい。更に、ソフトウェアは、プログラムストレージ装置に明確に具現されたアプリケーションプログラムとして実装されることが好ましい。アプリケーションプログラムは、何らかの適切なアーキテクチャを有する機械にアップロードされて実行されてもよい。機械は、１つ以上の中央処理装置（CPU）、ランダムアクセスメモリ（RAM）及び入出力（I/O）インタフェースのようなハードウェアを有するコンピュータプラットフォームに実装されることが好ましい。コンピュータプラットフォームはまた、オペレーティングシステムとマイクロ命令コードとを含む。ここに記載する様々な処理及び機能は、マイクロ命令コードの一部でもよく、オペレーティングシステムを介して実行されるアプリケーションプログラムの一部でもよい（これらの組み合わせでもよい）。更に、更なるデータストレージ装置及び印刷装置のように、様々な他の周辺装置がコンピュータプラットフォームに接続されてもよい。

添付図面に示すいくつかの構成要素のシステム構成要素及び方法のステップは、ソフトウェアで実装されることが好ましいため、システム構成要素（又は処理ステップ）の間の実際の接続は、本発明がプログラムされる方法に応じて異なってもよいことが更にわかる。ここでの教示を踏まえて、当業者は、本発明の前記及び同様の実装又は構成を検討することができる。

以上の実施例に関し、更に、以下の項目を開示する。

（１）リアルタイムメディアを保護する方法であって、
メディアパケットを受信し、
前記メディアパケットからメディアビット列を生成し、
前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、少なくとも１つの前方誤り訂正ビット列を生成し、
前記少なくとも１つの前方誤り訂正ビット列から少なくとも１つの前方誤り訂正パケットを生成することを有する方法。

（２）前記生成されたメディアビット列のそれぞれの終端で、前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし、
それぞれパディングされたビット列が最も長いビット列の長さになるように、以前にパディングされたビット列の終端で更にパディングすることを更に有する、（１）に記載の方法。

（３）前記メディアビット列のそれぞれは、リアルタイムトランスポートプロトコル・ヘッダ、ペイロードの長さ及び前記メディアパケットのそれぞれのペイロードからの一式のフィールドを順に連結することにより生成される、（１）に記載の方法。

（４）前記一式のフィールド及び前記順は、マーカービット、ペイロード形式、タイムスタンプ、メディアペイロードの長さの表示及び前記メディアペイロードを有する、（３）に記載の方法。

（５）前記生成された前方誤り訂正ビット列のそれぞれは、前方誤り訂正パケットヘッダを埋めるために使用される、（１）に記載の方法。

（６）前記前方誤り訂正パケットのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに挿入し、
前記前方誤り訂正パケットの前記インデックスの所定数の上位ビットを前記誤り訂正パケットヘッダの第２のインデックスフィールドに挿入し、
前記前方誤り訂正パケットヘッダの総数フィールドを前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数に設定することを更に有する、（５）に記載の方法。

（７）リアルタイムメディアを保護する装置であって、
メディアパケットを受信する手段と、
前記メディアパケットからメディアビット列を生成する手段と、
前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、少なくとも１つの前方誤り訂正ビット列を生成する手段と、
前記少なくとも１つの前方誤り訂正ビット列から少なくとも１つの前方誤り訂正パケットを生成する手段と
を有する装置。

（８）前記生成されたメディアビット列のそれぞれの終端で、前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングする手段と、
それぞれパディングされたビット列が最も長いビット列の長さになるように、以前にパディングされたビット列の終端で更にパディングする手段と
を更に有する、（７）に記載の装置。

（９）前記メディアビット列のそれぞれは、リアルタイムトランスポートプロトコル・ヘッダ、ペイロードの長さ及び前記メディアパケットのそれぞれのペイロードからの一式のフィールドを順に連結することにより生成される、（７）に記載の装置。

（１０）前記一式のフィールド及び前記順は、マーカービット、ペイロード形式、タイムスタンプ、メディアペイロードの長さの表示及び前記メディアペイロードを有する、（９）に記載の装置。

（１１）前記生成された前方誤り訂正ビット列のそれぞれは、前方誤り訂正パケットヘッダを埋めるために使用される、（７）に記載の装置。

（１２）前記前方誤り訂正パケットのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに挿入する手段と、
前記前方誤り訂正パケットの前記インデックスの所定数の上位ビットを前記誤り訂正パケットヘッダの第２のインデックスフィールドに挿入する手段と、
前記前方誤り訂正パケットヘッダの総数フィールドを前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数に設定する手段と
を更に有する、（１１）に記載の装置。

（１３）リアルタイムメディアパケットの損失から回復する方法であって、
受信したメディアパケットからメディアビット列を形成し、
受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成し、
前記メディアビット列及び前記前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得し、
前記回復したメディアビット列から回復したメディアパケットを生成することを有する方法。

（１４）前記メディアビット列の終端で、前記メディアビット列を前記前方誤り訂正ビット列の長さにパディングすることを更に有する、（１３）に記載の方法。

（１５）リアルタイムメディアパケットの損失から回復する装置であって、
受信したメディアパケットからメディアビット列を形成する手段と、
受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成する手段と、
前記メディアビット列及び前記前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得する手段と、
前記回復したメディアビット列から回復したメディアパケットを生成する手段と
を有する装置。

（１６）前記メディアビット列の終端で、前記メディアビット列を前記前方誤り訂正ビット列の長さにパディングする手段を更に有する、（１５）に記載の装置。

（１７）前方誤り訂正ヘッダのデータ構造を格納したコンピュータ可読媒体であって、
前記データ構造は、前方誤り訂正パケット及びメディアパケットの総数を示すフィールドを有するコンピュータ可読媒体。

（１８）前方誤り訂正ヘッダのデータ構造を格納したコンピュータ可読媒体であって、
前記データ構造は、所定数の前方誤り訂正パケットのインデックスを格納するフィールを有するコンピュータ可読媒体。

Claims (14)

1. リアルタイムメディアを保護する方法であって、
   メディアパケットを受信し、
   前記メディアパケットからメディアビット列を生成し、
   前記メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成し、
   前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成し、
   前記前方誤り訂正ビット列から前方誤り訂正データを生成し、
   前方誤り訂正パケットを送信することを有し、
   前記前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前記生成された前方誤り訂正データとを含み、
   前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され、
   前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、
   前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す方法。
2. 前記生成されたメディアビット列のそれぞれの終端で、前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし、
   それぞれパディングされたビット列が最も長いビット列の長さになるように、以前にパディングされたビット列の終端で更にパディングすることを更に有する、請求項１に記載の方法。
3. 前記メディアビット列のそれぞれは、リアルタイムトランスポートプロトコル・ヘッダ、ペイロードの長さ及び前記メディアパケットのそれぞれのペイロードからの一式のフィールドを順に連結することにより生成される、請求項１に記載の方法。
4. 前記一式のフィールド及び前記順は、マーカービット、ペイロード形式、タイムスタンプ、メディアペイロードの長さの表示及び前記メディアペイロードを有する、請求項３に記載の方法。
5. 前記生成された前方誤り訂正ビット列のそれぞれは、前方誤り訂正パケットヘッダを埋めるために使用される、請求項１に記載の方法。
6. リアルタイムメディアを保護する装置であって、
   メディアパケットを受信する手段と、
   前記メディアパケットからメディアビット列を生成する手段と、
   前記メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成する手段と、
   前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成する手段と、
   前記前方誤り訂正ビット列から前方誤り訂正データを生成する手段と、
   前方誤り訂正パケットを送信する手段と、
   を有し、
   前記前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前記生成された前方誤り訂正データとを含み、
   前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され、
   前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、
   前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す装置。
7. 前記生成されたメディアビット列のそれぞれの終端で、前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングする手段と、
   それぞれパディングされたビット列が最も長いビット列の長さになるように、以前にパディングされたビット列の終端で更にパディングする手段と
   を更に有する、請求項６に記載の装置。
8. 前記メディアビット列のそれぞれは、リアルタイムトランスポートプロトコル・ヘッダ、ペイロードの長さ及び前記メディアパケットのそれぞれのペイロードからの一式のフィールドを順に連結することにより生成される、請求項６に記載の装置。
9. 前記一式のフィールド及び前記順は、マーカービット、ペイロード形式、タイムスタンプ、メディアペイロードの長さの表示及び前記メディアペイロードを有する、請求項８に記載の装置。
10. 前記生成された前方誤り訂正ビット列のそれぞれは、前方誤り訂正パケットヘッダを埋めるために使用される、請求項６に記載の装置。
11. リアルタイムメディアパケットの損失から回復する方法であって、
    受信したメディアパケットからメディアビット列を形成し、
    受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成し、
    前記メディアビット列及び前記前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得し、
    前記回復したメディアビット列から回復したメディアパケットを生成し、
    前記回復したメディアパケットを並び替え、回復したメディアパケットの複数の列及び複数の行の２次元行列を形成することを有し、
    前記受信した前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前方誤り訂正データとを含み、
    前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、
    前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す方法。
12. 前記メディアビット列の終端で、前記メディアビット列を前記前方誤り訂正ビット列の長さにパディングしたものを除去することを更に有する、請求項１１に記載の方法。
13. リアルタイムメディアパケットの損失から回復する装置であって、
    受信したメディアパケットからメディアビット列を形成する手段と、
    受信した前方誤り訂正パケットから前方誤り訂正ビット列を形成する手段と、
    前記メディアビット列及び前記前方誤り訂正ビット列を復号化し、回復したメディアビット列を取得する手段と、
    前記回復したメディアビット列から回復したメディアパケットを生成する手段と、
    前記回復したメディアパケットを並び替え、回復したメディアパケットの複数の列及び複数の行の２次元行列を形成する手段と
    を有し、
    前記受信した前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前方誤り訂正データとを含み、
    前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、
    前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す装置。
14. 前記メディアビット列の終端で、前記メディアビット列を前記前方誤り訂正ビット列の長さにパディングしたものを除去する手段を更に有する、請求項１３に記載の装置。

Images