JP3831558B2

JP3831558B2 - エンコード方法及びエンコーダ

Info

Publication number: JP3831558B2
Application number: JP29907399A
Authority: JP
Inventors: マクドナルドボーイスジル
Original assignee: ルーセントテクノロジーズインコーポレーテッド
Priority date: 1998-10-22
Filing date: 1999-10-21
Publication date: 2006-10-11
Anticipated expiration: 2019-10-21
Also published as: CA2281353A1; CA2281353C; JP2000134619A; US6317462B1; EP0996291A1

Description

【０００１】
【発明の属する技術分野】
本発明はインターネットを介した符号化済みビデオ信号の送受信に関し、特に、ＭＰＥＧ、ＭＰＥＧ−２、Ｈ．２６１、及びＨ．２６３標準に用いられているような効率的なフレーム間圧縮符号化技法を用いて符号化されたビデオ信号の送受信に関する。
【０００２】
【従来の技術】
あらゆるタイプのデータのインターネットを介した伝送が過去数年の間に急速に広まりつつあるため、最近では、デジタル的に符号化されたリアルタイムオーディオ及びビデオのユニバーサルデータグラムプロトコル（ＵＤＰ）を用いた、インターネットを介しての送信に興味が持たれてきている。ＵＤＰは信頼性の低いプロトコルであるため、ネットワークパケット喪失（パケットロス）が発生する可能性があり、その結果として、受信されるオーディオ及びビデオの品質に悪影響を及ぼす。パケットロスからの回復は受信側によってのみなされるか、あるいは、送信側及び受信側の双方をエラー回復プロセスに関与させることによってよりよい品質が実現される。例えばＡＴＭのような、優先順位付けをサポートしているネットワークにおいては、パケットロスが発生する場合におけるビデオ品質が、スケーラブルビデオ符号化を用いることによって改善されうる（例えば、R.Aravind, M.Civanlar, A.Reibmanによる“ＭＰＥＧ−２スケーラブルビデオ符号化アルゴリズムにおけるパケットロス回復性”という表題の論文（IEEE Transactions on Circuits and Systems for Video Technology, Vol.6, No.5, October 1996）を参照）。しかしながら、現時点では、インターネットにおいては優先順位付けの広範囲なサポートはなされていない。送信側及び受信側の双方が関与する、インターネットを介したオーディオ及びビデオのストリーミングにおけるエラー回復に係るこれまで提案された方法についての概説は、C.Perkins及びO.Hodsonによる“ストリーミング媒体の修復に関する選択肢”という表題の文献（Internet Engineering Task Force Internet RFC 2354）、及び、G.Carle及びE.Biersackによる“ＩＰベースのオーディオビジュアルマルチキャストアプリケーションに係るエラー回復技法の概観”という表題の文献（IEEE Network, November/December 1997）に記載されている。これらの概説に記載されている一般的な方法はオーディオ及びビデオの双方のＩＰ伝送に適用可能であるが、特定の技法がインプリメントされたこれまでの研究の大部分はオーディオのみを含むものである。その高いデータレート及びフレーム間符号化によるエラー伝播のために、ビデオ品質を維持することはオーディオよりもはるかに難しく、それゆえ、オーディオ用の技法を直接ビデオ信号に適用することは不可能である。
【０００３】
例えばＭｏｔｉｏｎ−ＪＰＥＧやウエーブレットベースの方式等の、インターネットを介したデジタルビデオ伝送の現時点で一般的な方式の多くは、フレーム内符号化を用いている。ＭＰＥＧ−１、ＭＰＥＧ−２、Ｈ．２６１、及びＨ．２６３標準に用いられているようなフレーム間符号化技法は、一般的にはフレーム内符号化技法よりも圧縮率の点でより効率的である。しかしながら、フレーム間標準は、インターネットパケットロスの影響をより受けやすい。なぜなら、一つのフレームにおけるエラーが多くのフレームに亘って伝播するからである。ＭＰＥＧビデオシーケンスは、フレーム内符号化（Ｉ）フレーム、フレーム間予測符号化フレーム（Ｐ）、及び双方向フレーム間符号化フレーム（Ｂ）を含んでいる。Ｉ及びＰフレームは、それ移行のフレームの予測に用いられ、Ｂフレームはそれ以降のフレームの予測には用いられない。例えば、Ｉフレームが１５フレーム毎に発生するＭＰＥＧビデオシーケンスを考える。ＭＰＥＧ符号化においては、フレーム間予測のために、予測可能な全てのＰ及びＢフレームは直前のＩフレームに依存している。よって、Ｉフレームの伝送中にエラーが発生すると、その効果は１５フレーム、すなわち５００ミリ秒に亘って持続し、これはビデオシーケンスの受け手に容易に認識されてしまう。受信されたビデオの品質は、デコーダ側に適用されるエラー隠蔽技法及び送信側に適用されるエラー回復技法の双方によって改善されうる。
【０００４】
フォワードエラー／抹消修正（ＦＥＣ）を用いるエラー回復技法は、伝送前にメディアストリームに冗長なデータを追加し、パケットロスが受け手側で、送信側とのコンタクトあるいは送信側からの再送信を必要とせずに回復されうるようにする方法である。フォワードエラー／抹消修正技法は、再送信を回避できるという点で、マルチキャストアプリケーションに適している。同一の冗長データが、マルチキャストグループ内の個々のレシーバにおいて、異なったパケットロスの修復に用いられる。その代わりに再送信が用いられると仮定すると、多重再送信要求が送出されなければならない。マルチメディアに係るフォワードエラー／抹消修正技法は、一般的には、メディア非依存ＦＥＣ及びメディア依存ＦＥＣの二つのカテゴリーに分類される（例えば、C.Perkins及びO.Hodsonによる“ストリーミング媒体の修復に関する選択肢”（Internet Engineering Task Force Internet RFC 2354, June 1998）という表題の文献を参照）。
【０００５】
メディア非依存ＦＥＣにおいては、あらゆるタイプのデータを保護する公知の情報理論が用いられる。D.Budge, R.McKenzie, W.Mills, 及びP.Longによる“ＲＴＰを用いたメディア非依存エラー修正”という表題の文献（Internet Engineering Task Force Internet Draft, May 1997）においては、二つあるいはそれ以上のデータパケットからパリティパケットを生成する目的で、排他的論理和（ＸＯＲ）演算のいくつかの変形が用いられる。リード・ソロモン（Reed-Solomon、ＲＳ）符号化などのより複雑な技法も利用可能である（例えば、G.Carle及びE.Biersackによる“ＩＰベースのオーディオビジュアルマルチキャストアプリケーションに係るエラー回復技法の概観”という表題の文献（IEEE Network, November/December 1997）を参照）。リード・ソロモン符号化は、システマティックフォワードエラー／抹消修正符号（組織前方誤り／消失訂正符号）の一例である。システマティックフォワードエラー／抹消修正符号は、情報バイトが修正なしにコードワードで送信される符号の一つである。よって、チャネルエラーが存在しない場合には、情報バイトを回復するためのリードソロモン復号化は不要である。ＲＳ（ｎ，ｋ）コードワードがバイトデータから生成される際には、ｋ個の情報バイトからｈ個のパリティバイトが生成され、全ｎバイト（ｎ＝ｋ＋ｈ）が送信される。このようなリード・ソロモンデコーダは、最大ｈ／２バイトまでのあらゆるエラー及びｈバイトの抹消を修正することが可能である。ここで、抹消とは、既知の位置におけるエラーとして定義される。ＲＳ符号化がパケットロスからパケット化されたデータを保護する目的で適用される場合には、長さｊバイトのｋ個の情報パケットがｊ個のＲＳコードワードを用いて符号化される。各々のＲＳコードワードに関しては、ｋ個の情報バイトがｋ個の相異なったパケットから（一つずつ）取り出されており、ｈ個の生成されたパリティバイトがｈ個の個別のパリティパケットに配置され、全ｎパケット（ｎ＝ｋ＋ｈ）が送出される。送信されるパケットには番号が付されており、パケットはそれ自体完全に受信されるかあるいは全く受信されないものと仮定されているため、レシーバはどのパケットが失われたかを決定することが可能であり、パケットロスは抹消と見なすことが可能である。よって、ｎ個の送信されたパケット中でｈ個（あるいはそれ以下の個数の）パケットが失われても、元のｋ個の情報パケットは完全に回復される。
【０００６】
ＲＳ符号化の重要な利点は、パラメータの選択に依存するが、複数個の連続したエラーから保護することが可能であるという点である。ＲＳ符号化におけるオーバーヘッド比率はｈ／ｋであり、ｋの大きな値に係るバーストエラー保護としては最も効率的である。例えば、ＲＳ（６，４）符号及びＲＳ（４，２）符号は、双方とも、バースト長２のエラー保護が可能である。しかしながら、ＲＳ（４，２）符号は１００％のオーバーヘッドを有するのに対し、ＲＳ（６，４）はわずか５０％のオーバーヘッドを有するに過ぎない。しかしながら、ブロック長を増加させることによってオーバーヘッドパーセンテージを低減することは遅延につながる。なぜなら、大きなブロック長を利用することは、送信前に大量のデータをバッファリングすることが必要になるからである。
【０００７】
メディア依存ＦＥＣ符号化においては、メディア非依存ＦＥＣ符号化とは異なり、マルチメディアストリームがデータとしてのみ扱われ、送信されるマルチメディアストリームの特定のタイプに係る知識が用いられる。M.Podolsky, C.Romer及びS.McCanneによる“インターネット上のパケットオーディオに係るＦＥＣベースのエラー制御のシミュレーション”という表題の論文（INFOCOM, March 1998, San Fransisco CA）及びV.Hardman, M.A.Sasse, M.Handley及びA.Watsonによる“インターネットを介した利用のための高信頼性オーディオ”という表題の論文（Proc. INET'95, Honolulu, HI, pp.171-78, June 1995）においては、標準的なオーディオストリームと共に、冗長低ビットレートオーディオストリームが１パケット分遅延させられた後に送信される。標準オーディオパケットが失われた場合には、レシーバは、その代替として、次のパケットにおいて受信される低ビットレートデータを利用する。この方法は、単一パケットロスに対する保護となる。
【０００８】
【発明が解決しようとする課題】
Perkins及びHodsonによる前掲の参照論文においては、ＦＥＣをマルチメディアビットストリーム全体に適用するのではなく、メディア非依存ＦＥＣ技法を符号化器の最高位ビットに適用することによってメディア依存技法及びメディア非依存技法を組み合わせるという提案がなされている。しかしながら、このことに関する詳細な情報は全く与えられていない。パケットロスからビデオ品質を保護する目的でＭＰＥＧビデオなどのフレーム間符号化ビデオに回復情報を追加する低オーバーヘッドでかつ低遅延な方法が必要とされている。
【０００９】
【課題を解決するための手段】
本発明に従って、ＭＰＥＧビデオ信号などのフレーム間符号化ビデオ信号が、ビデオストリームを高優先度部分及び低優先度部分に分割するデータ分割機能を利用する。その後、システマティックなフォワードエラー／抹消修正符号化が、高優先度部分のデータにのみ実行される。フォワードエラー／抹消修正された高優先度部分データ及びフォワードエラー／抹消修正されていない低優先度部分データは組み合わせられてパケットとされ、同一のネットワークを介して受信側宛に送出され、そこで復号化される。用いられる特定のＦＥＣによって提供されるエラーあるいは抹消に対する保護の程度に依存して、高優先度データを含む単一あるいは複数個のパケットの喪失が、高優先度部分における喪失の無いデータによって修正される。低優先度部分が保護されていない単一あるいは複数個のパケットにおける低優先度データの喪失の影響は、高優先度データが失われた場合よりも、復号化されたビデオ信号の品質には有害ではない。従って、フォワードエラー／抹消修正をより高優先度部分のデータに限定し、よって“より重要なデータ”の喪失に対してのみ保護することにより、与えられたパケットロスに係る保護に必要とされる全体としての要求が低減される。
【００１０】
本発明の望ましい実施例においては、リードソロモンエンコーダが、フレーム全体に係る高優先度データに対して適用される。ＲＳ（ｎ，ｋ）コードワードの各々に対して、各ｋ個のパケットから１情報バイトが取り出され、構成されたパリティバイトがｈ個の相異なったパケットに配置される。ここで、ｎ＝ｋ＋ｈである。個々のフレームのデータは、パケットヘッダと情報バイトあるいはパリティバイトのいずれかを含む高優先度データと及び、低優先度データバイトとの組み合わせより構成されるｎ個の等長パケットに配置される。低優先度データに関してはエラー修正符号化はなされないため、低優先度データバイトは情報バイトのみを含んでいる。等しいバイト数の高優先度データ（あらゆる一つのパケットにおける情報あるいはパリティ）がｎ個の等長パケットのそれぞれに配置され、等しいバイト数の低優先度データ（情報のみ）がこれら同一のｎ個のパケットに配置される。これらの高優先度データと低優先度データは、双方でビデオフレームを表現する。これらｎ個の等長パケットの中で、ｋ個のパケットのみが高優先度部分情報バイトを含んでおり、ｈ個のパケットは高優先度パリティバイトを含むのみである。これらｈ個のパケットの各々における各々の高優先度バイトポジションのパリティバイトは、ＲＳ（ｎ，ｋ）コードから、当該フレームに関連するｋ個の他の高優先度部分情報包含パケットにおける対応するバイトポジションでのｋ個の高優先度部分情報バイトに対して適用されるように、構成される。このようにパケットを配置することによって、与えられたパケットロス保護レートに対するオーバーヘッド量及び遅延を最小化することができる。
【００１１】
受信側デコーダは、フレームに係るデータを受信すると、各々のパケットに含まれる高優先度部分バイトと低優先度部分バイトを、それぞれのバイトすなわち各々の部分の個数に従って分割する。これらの個数は、パケットヘッダにおいて送信される。ＲＳ（ｎ，ｋ）復号化が、受信されたパケットにおける高優先度部分ポジションに亘って、バイト位置毎に適用される。ｎ個のフレームパケットにおける最大ｈ個が失われる場合には、ＲＳ復号化プロセスは、これら失われたパケットにおける各々の高優先度バイトを回復する。高優先度部分情報データを含むｎ個のパケットのうちのｋ個のパケットにおいて送信された高優先度部分情報バイトの完全な再構成がこのようにして実現される。低優先度部分データ中の失われたパケットは回復不能であるが、完全に復元された高優先度部分データが、高優先度部分情報のみしか利用可能でないフレームあるいはフレームの一部の品質レベルは低下するとしても、ビデオ画像の復号化を可能にする。
【００１２】
【発明の実施の形態】
ＭＰＥＧ−２標準（ＩＴＵ−Ｔ勧告Ｈ．２６２、“動画及び関連する音声情報の一般的符号化”、１９９５年７月）は、空間的スケーラビリティ、ＳＮＲスケーラビリティ、及びデータ分割を含む、スケーラブルなビデオ符号化を実行する種々の手段を含んでいる。スケーラブルビデオ符号化においては、相異なった利用可能帯域を有するレシーバが、ベースレイヤを受信し、帯域が利用可能である場合には単一あるいは複数個のエンハンスメントレイヤを受信することによって、符号化されたビデオを受信して、適切な表示を復号化できる。より多くのレイヤを受信すればするほど、復号化されるビデオの品質は高くなる。Arvind, Civanlar及びReibmanによる前掲の論文においては、ＡＴＭ等の優先順位付けをサポートするネットワークにおいてＭＰＥＧ符号化済みビデオ信号を送信する際のパケットロスに対する保護を実現する目的で、データ分割が適用される。詳細に述べれば、パケットロスに対する保護は、ベースレイヤをエンハンスメントレイヤより高い優先順位で送信することによって達成可能であることが示されている。現時点での公衆インターネットはパケットの優先順位付けをサポートしていないため、この技法はインターネットを介した符号化済みビデオの送信には適用され得ない。
【００１３】
しかしながら、本発明の発明者は、公衆インターネット等の優先順位付けをサポートしないネットワークにおいて、従来技術においては優先順位付けをサポートしているネットワークを介したパケット保護目的で用いられたデータ分割機能を利用することによって、技術的進展が実現されうることを見出した。データ分割機能をフォワードエラー／抹消修正機能と共に、優先順位付けをサポートしない公衆インターネットを介したフレーム間圧縮符号化ビデオ信号の送信に関して用いることにより、パケット保護に必要とされるオーバーヘッド量を低減し、一方でパケット保護対象であるビデオ品質の改善が実現される。さらに、同一パケット内に高優先度及び低優先度データを組み合わせることにより、同一オーバーヘッド及び保護に係る遅延を大幅に低減することが可能となる。
【００１４】
図１は、本発明に係るエンコーダの第一実施例を示すブロック図である。この実施例においては、ＭＰＥＧ標準データ分割に従ったエンコーダが、入力ビデオデータストリームを高優先度部分及び低優先度部分に分割する目的で利用される。入力ビデオデータストリーム１０１は、この種の標準に従ったデータ分割ＭＰＥＧ標準エンコーダ１０２に入力される。エンコーダ１０２は、例えばＭＰＥＧ−２データ分割標準等の標準に従って、入力ビデオビットストリームを圧縮／符号化し、圧縮／符号化されたビットストリームを二つの出力レイヤに分割する。第一レイヤはベースレイヤであり、本明細書においては高優先度（ＨＰ）部分と呼称される。第二レイヤはエンハンスメントレイヤであり、本明細書においては低優先度（ＬＰ）部分と呼称される。
【００１５】
ＭＰＥＧ符号化分野における当業者には公知であるが、ＭＰＥＧ符号化ビデオビットストリームは、シーケンスレベル、画像群（ＧＯＰ）レベル、画像（フレーム）レベル、及びスライスレベルにおけるヘッダを有する。よく知られているように、スライスは隣接するマクロブロック群より構成されており、各々のマクロブロックは、それ自体、四つの隣接するルミナンス（輝度）ブロックデータ及び二つのクロミナンスブロックより構成される群を有する。画像レベルにおいては、フレームは、フレーム内符号化（Ｉ）フレーム、フレーム間符号化予測（Ｐ）フレーム、あるいは双方向フレーム間予測（Ｂ）フレームとして分類される。マクロブロックレベルにおいては、予測タイプのＰ及びＢフレームに関しては、当該マクロブロックが他のフレームに関してフレーム間符号化あるいはフレーム内符号化されたものであるかを示す情報が、動きベクトル情報と共に包含されている。ブロックレベルにおける情報には、実際のピクセル情報から導出された低周波及び高周波離散コサイン変換（ＤＣＴ）係数が含まれる。
【００１６】
ＭＰＥＧ標準に従って、データ分割が、マクロブロックレイヤより上位、マクロブロックレイヤ、あるいはマクロブロックレイヤ内などの種々の相異なった優先度ブレークポイントにおいて実現されうる。一般に、符号化ビットストリームのより重要な部分、例えばヘッダ、動きベクトル及び低周波ＤＣＴ係数などはＨＰ部分に割り当てられ、より重要ではないデータ、例えば高周波ＤＣＴ係数などはＬＰ部分に割り当てられる。標準に従って、優先度ブレークポイントは各々のスライスに関して選択され、どのコードワードタイプがどの部分に配置されるかが決定される。
【００１７】
図１に示された実施例においては、標準的なデータ分割ＭＰＥＧエンコーダ１０２が用いられているが、優先度ブレークポイントは、分割されつつあるデータストリーム中のフレームタイプ（Ｉ、Ｐ、あるいはＢ）に従って決定される。詳細に述べれば、この実施例においては、各Ｉフレームに関しては全てのデータがＨＰ部分に配置され、ＬＰ部分に配置されるデータはない。他の実施例においては、各ＩフレームのデータをＨＰ及びＬＰ部分に分割することも可能である。各Ｂフレームに関しては、データ分割に係るＭＰＥＧ標準が許容するだけ多くのデータがＬＰ部分に配置され、残りのデータがＨＰ部分に配置される。各Ｐフレームに関しては、フレームデータは、各ブロックの最初の二つのＤＣＴ係数に係るデータエレメントがＨＰ部分に配置され、より高次のＤＣＴ係数がＬＰ部分に配置されるように、ＨＰ及びＬＰ部分に分割される。この実施例に関連して前述されたものとは異なった、ＬＰ及びＨＰ部分間の三つのフレームタイプにおける相異なった優先度ブレークポイントも、等しく用いられることが可能である。しかしながら、より高いブレークポイントはＰフレームではなくＩフレームに関して用いられ、それがＢフレームに係るブレークポイントよりも高いことが期待されている。標準に従ったこの実施例においては、シーケンス、ＧＯＰ、及び画像ヘッダは、エラー回復目的で、双方の部分にコピーされる。
【００１８】
本発明に従って、ＨＰ部分はシステマティックフォワードエラー／抹消修正符号によって符号化される。詳細に述べれば、この望ましい実施例においては、リードソロモン符号化が、単一のフレーム全体に関するＨＰデータに適用される。この実施例に関しては、複数個のフレームからのデータが符号化及び送信の前に集積されることに関して必要とされる場合に負わなければならない遅延を最小にする目的で、単一のフレームからのデータのみがフォワードエラー／抹消修正エンコーダ／パケタイザ１０３によって一度に操作される。他の実施例においては、Ｂフレーム及びその直後に続くアンカーフレーム（ＩあるいはＰフレーム）が、フォワードエラー／抹消修正エンコーダ／パケタイザ１０３によって同時に処理される。
【００１９】
リードソロモン符号化は、当該フレームに係るＭＰＥＧエンコーダ１０２からのＨＰデータ出力に対して適用される。以下に詳細に記述されているように、ＨＰ部分のバイト数及びＬＰ部分のバイト数は、最大許容パケット長及びパケット保護に係る希望される度合と共に、そのフレームに係るＨＰ情報バイト、ＬＰ情報バイト、及びＨＰ保護パリティバイトがフィットする等長パケット個数、ｎ、を決定するために用いられる。本発明に従って、ｎ個の等長パケットの各々は、ＬＰ情報バイトと、ＨＰ情報バイトとパリティバイトのうちのいずれかとの双方の組み合わせを含んでいる。パリティバイトは、ＨＰ情報バイトを含むｋ個のパケットの各々から一ＨＰ情報バイトを取り出し、これらｋ個のバイトから構成されたｈ個のパリティバイトを一度に一バイトずつｈ個の相異なったパケットに配置することでＲＳ（ｎ，ｋ）コードワードを構成することにより決定される。ここで、ｎ＝ｋ＋ｈである。よって、これらｈ個のパケットにおけるパリティバイトのバイト位置ｍ（ｍは、１からパケット内のＨＰ情報バイトの個数の間で変化する）は、ＨＰ情報バイトから、ｋ個のパケットにおいて同一のバイト位置ｍであるように導出される。これらｈ個のパケットにおける各バイト位置のパリティバイトは、他のｋ個のパケットにおける同一のバイト位置におけるＨＰ情報バイトから計算されるため、等長パケットの各々は同一個数のＨＰデータバイトを有しており、このＨＰデータバイトは全てが情報バイトであるか全てがパリティバイトであるかのいずれかである。それゆえ、各等長パケットは、同一個数のＬＰ情報バイトを含んでいる。フレーム内のＨＰ情報バイトの個数はパケット数ｋによって必ずしも分割可能ではないため、必要に応じてパッドバイトがｋ番目のパケットの終端部に付加される。同様に、ＬＰ情報バイトに関しても、ｎ番目のパケットにパッドバイトが適用される。
【００２０】
図２は、ＲＳ（４，３）符号に係るパケットフレームグループの配置例を示した模式図である。図より明らかなように、三つのパケット（ｋ＝３）がＨＰ情報バイトとＬＰ情報バイトを含んでおり、一つのパケット（ｈ＝１）がＨＰパリティバイトとＬＰ情報バイトを含んでいる。この図に示されているようにパケットを配置することにより、遅延を増大させることなく、与えられたパケットロス保護レートに関するオーバーヘッド量を最小になる。各パケットにおけるパケットヘッダは、パケット番号、パケットフレームグループ内のパケット数（ｎ）、パケットフレームグループ内のパリティデータを有するパケット数（ｈ）、当該フレームに係る一時参照値、フレームタイプ（Ｉ、Ｐ、あるいはＢ）、ＨＰ／ＬＰ優先度ブレークポイント、及び、各パケットにおけるＨＰ及びＬＰバイトの個数、を含んでいる。
【００２１】
データ分割ＭＰＥＧエンコーダ１０２の出力は、フレームに関連するビデオデータ入力ストリームに対して、二つのデータストリーム、すなわち出力１０４上のＨＰ部分データストリームと出力１０５上のＬＰ部分データストリームよりなり、双方がＦＥＣコーダ／パケタイザ１０３に入力される。入力フレームのＨＰ部分におけるバイト数、ＨＰ＃、と、入力フレームのＬＰ部分におけるバイト数、ＬＰ＃、とが、コーダ／パケタイザ１０３内のプロセッサ１０６に入力される。以下に詳細に記述されているように、フレーム当たりのバイト数の所定の最大値と共にＨＰ＃及びＬＰ＃の値を用いることによって、プロセッサ１０６は、パケットヘッダ、ＨＰ部分情報バイト、ＨＰ部分パリティバイト、及びＬＰ部分情報バイト全てを含むフレーム全体を送信するために必要とされるパケット数、ｎ、を決定する。さらに、プロセッサ１０６は、所定の保護レベルで他のｋ個のパケットにおいてＨＰ部分情報バイトを保護するために必要とされるパケット数、ｈ（＝ｎ−ｋ）、を決定する。プロセッサ１０６は、さらに、ｎ個のパケットの各々のバイト長を決定する。その後、プロセッサ１０６は、これらｎ個のパケットの各々に割り当てられるＨＰデータ／パリティバイト及びＬＰデータバイトの個数を、ｎ個のパケットの各々に割り当てられるＬＰ情報バイト数、ｋ個のパケットに割り当てられるＨＰ情報バイト数、及び、その他のｈ個のパケットに割り当てられるＨＰパリティバイト数、のそれぞれと共に、図２の例に示されているように決定する。
【００２２】
プロセッサ１０６が各々のパケットの配置及びそれぞれのパケットの個数を決める全てのパラメータを決定すると、リードソロモンＲＳ（ｎ，ｋ）符号化が、ＨＰ部分内の各バイト毎に実行される。詳細に述べれば、ＨＰ部分ビデオストリームがバイトインターリーバ１０７に入力され、インターリーバ１０７は、プロセッサ１０６によって決定されたパラメータに応答して、シーケンシャルなコードワードを生成し、それらはリードソロモンエンコーダ１０８に供給される。例えば、パケット当たりのＨＰバイトが６５０と計算された場合には、ＨＰストリーム中の１番目、６５１番目、１３０１番目、、、のバイトが、インターリーバ１０７によってインターリーブされ、ＨＰパリティバイトを含むｈ個のパケットに係る第一パリティバイト位置に対応するバイトを決定する目的で、ＲＳエンコーダ１０８への入力ワードが形成される。その後、２番目、６５２番目、１３０２番目、、、のバイトがインターリーブされ、ｈ個のＨＰパリティパケットに係る第二パリティバイト位置を決定する目的で、ＲＳエンコーダ１０８への次の入力ワードが構成される。このようにして、ＲＳエンコーダ１０８にはｋバイトよりなる一連の入力ワードがシーケンシャルに入力され、これらｋバイト入力ワードの各バイトは、ｋ個の相異なったパケットから取り出された各１情報バイトがインターリーブされたものである。ｋバイト入力ワードの各々に対して、ｈ個のパリティバイトが決定される。よって、各ｋバイト入力ワードに対して、ＲＳエンコーダ１０８は、ｋ個の情報バイト及びｈ個のパリティバイトを含むｎ個のバイトワードを出力する。
【００２３】
ｎ個の相異なったパケットに適切に属するバイトを含む、これら垂直方向に配置されたコードワードを列方向に配置されたパケットフォーマットに再アセンブルする目的で、デインターリーバ１０９が、ｎバイト出力ワードからの各々のバイトをｎ個の相異なった列のうちの個々の列に順次配置する。よって、これらｎ列のうちの最初のｋ列は全てＨＰ情報バイトを含み、最後のｈ列は全てＨＰパリティバイトを含んでいる。ｎ列が再構成される場合には、これらの列の各々は、パケタイザ１１０によって、パケットヘッダと、データ分割ＭＰＥＧエンコーダ１０２のＬＰ出力１０５からの各々のパケットに対して分配された、計算された固定数のＬＰ部分情報バイトとに組み合わせられる。各々のパケットは、図２にＲＳ（４，３）符号の場合に示されているフォーマットで、ＵＤＰ／ＩＰネットワークにおける伝送のために、出力１１１から順次出力される。
【００２４】
図２に示された例においては、フレーム情報を含むパケットが伝送中に一つも失われなかった場合には、ビデオ情報は完全にデコードされる（すなわち、エンコードされたものと同一である）。一つのパケット（あるいは、一般のＲＳ（ｎ，ｋ）符号化において最大ｈ個のパケット）が失われた場合には、そのパケットに含まれるＨＰ情報の全てがリードソロモンデコーダを用いることによって回復可能である。しかしながら、失われたパケット中のＬＰ情報データは、保護されていないために回復不能である。その結果、ＬＰデータが受信されたマクロブロックに対応する画像の部分は完全にデコードされ、ＬＰデータが失われたマクロブロックに対応する画像の部分はそのマクロブロックに係るＨＰデータのみがデコードされる。ＨＰデータのみを用いてデコードされたこれらのマクロブロックは、その画像を見る者によって認識されうるものであるが、ＨＰ／ＬＰ優先度ブレークポイントが適切に選択されている限りは、画像として不快なものではない。ＨＰデータのみを用いてデコードされたマクロブロックの正確な画像品質は、このＨＰ／ＬＰ優先度ブレークポイントとビデオソースの素材の特性に依存する。図１に示された実施例においては、標準的なデータ分割ＭＰＥＧエンコーダ１０２が入力ビデオストリームを圧縮／符号化してＨＰ及びＬＰ部分を形成するために用いられているが、双方の部分にコピーされる最低レベルのヘッダが画像ヘッダである。よって、いずれかのパケット及びそれに含まれていたＬＰ部分情報が失われると、それは回復不能であり、次のパケットにおいて受信されるＬＰ部分データは復号化プロセスに適切に組み込まれることが不可能になる。なぜなら、その受信されたデータが関連しているはずの識別可能な空間的エントリポイントが、次の画像ヘッダが受信されるまでは存在しないからである。よって、図１の実施例に関しては、ＬＰ部分情報の喪失に係る知覚可能な効果は、受信されたＬＰ部分情報内の次の画像ヘッダを含むパケットが受信されるまで、持続する。その画像ヘッダが受信されると、それ以降に引き続くＬＰ部分データは受信されたＨＰ部分データに適切に組み込まれる。
【００２５】
前述されているように、フレームデータのパケットへの厳密な配置は、フレーム内のＨＰ部分情報のバイト数とＬＰ部分情報のバイト数、ＲＳ（ｎ，ｋ）符号のパラメータ、及びパケットサイズの関数である。インターネットプロトコル（ＩＰ）伝送に関しては、この実施例においては、最大パケットサイズが、１５００バイトというイーサネット最大トランスポートユニット（ＭＴＵ）サイズに設定されている。ＲＳ（ｎ，ｋ）符号パラメータの選択は、フレームを送信するために必要とされるパケット数、ネットワークロスコンディション、及び、受認可能と考えられるオーバーヘッドパーセンテージに依存する。インターネットにおけるパケットロスはある程度バースト状に発生する傾向を有するため、ｋ／ｎ比は、ｎの小さな値に関しては小さく、また、ｎの大きな値に関しては大きく選択することが可能である。表１は、パケットロスのバースト状の性質に基づいた、ｎ及びｋ値の対の例を表わしたものである。ｋ／ｎ比は、ｎの小さな値に関しては小さく、また、ｎの大きな値に関しては大きく選択されている。
【表１】

【００２６】
表１に与えられているような（ｎ，ｋ）値のリストが与えられると、各フレームに関して用いられる特定の（ｎ，ｋ）値の組が、反復プロセスを用いて決定される。図３は、これらのパラメータを決定するためにプロセッサ１０６が従うステップの詳細を示した流れ図である。データ分割ＭＰＥＧエンコーダ１０２がビットストリームをＨＰ部分及びＬＰ部分に分割した後には、ＨＰ部分にＨＰ＃バイト、ＬＰ部分にＬＰ＃バイトが存在する。ステップ３０１においては、これらの情報を送信するために必要とされるパケット数ｎが、最大パケットサイズＰＳ_maxを仮定して、初期推定される。ここで、本実施例においては、ＰＳ_maxは、イーサネット（登録商標）ＭＴＵサイズから用いられているパケットヘッダバイト数を減算したものに等しい。初期推定ｎは、ｎ＝ｃｅｉｌ（ＨＢ＃＋ＬＢ＃）／ＰＳ_maxによって求められる。ｃｅｉｌ（）はシーリング関数である。このように、ｎの初期推定は、ＨＰパリティバイトを考慮せずに計算されるが、ＨＰパリティバイトもフレーム中に組み込まれなければならない。ステップ３０２においては、表１を用いて、推定値ｎに対応するｋの値が読み出される。ステップ３０３においては、ＨＢ＃情報バイトに関して必要とされるパケットサイズが、ＣｕｒＰａｃｋｅｔＳｉｚｅ＝ｃｅｉｌ（ＨＢ＃／ｋ）＋ｃｅｉｌ（ＬＢ＃／ｎ）から計算される。なぜなら、ＨＢ＃情報バイトはｋ個のパケットに分割され（パリティバイトは、残りのｈ個のパケットに分割される）、ＬＢ＃情報バイトはｎ個のパケットに分割されるからである。ステップ３０４においては、ＣｕｒＰａｃｋｅｔＳｉｚｅがＰＳ_maxと比較される。ＣｕｒＰａｃｋｅｔＳｉｚｅがＰＳ_maxよりも小さい場合には、その時点での（ｎ，ｋ）値が用いられる。それ以外の場合には、パケットサイズが大きすぎることになり、ｎが１だけインクリメントされる（ステップ３０５）。表１から、このインクリメントされたｎの値に対して新たなｋの値が読み出される。その後、ＣｕｒＰａｃｋｅｔＳｉｚｅがこれら新たなパラメータを用いて再計算される。このプロセスは、ＰＳ_maxよりも小さいＣｕｒＰａｃｋｅｔＳｉｚｅが計算された時点で終了する。よって、ｎ個のフレームの各々におけるＨＰバイト（情報あるいはパリティ）の実際の数ＨＢＰがｃｅｉｌ（ＨＢ＃／ｋ）に等しく、かつ、ｎ個のフレームの各々におけるＬＰバイトの実際の数ＬＰＢはｃｅｉｌ（ＬＰ＃／ｎ）に等しく、各フレームにおける総バイト数からパケットヘッダバイト数を減じたものであるＴＰＢは、ＨＢＰ＋ＬＰＢに等しい。
【００２７】
具体例として、Ｐフレームが５６３２バイトを有していて、ＨＢ＃＝２１２９バイト、ＬＢ＃＝３５０３ＬＰバイトと仮定する。ＰＳ_maxは１４７５バイトに等しいものと仮定する。この値は、１５００バイトというＭＴＵサイズからパケットヘッダ分の２５バイトを減じたものである。パケット数の初期推定ｎは、ｎ＝ｃｅｉｌ（（２１２９＋３５０３）／１４７５）＝ｃｅｉｌ（３．８１８）＝４である。表１より、ｎ＝４に対しては、ｋ＝３である。これらの値を用いて、ＨＰＢ、ＬＰＢおよびＴＰＢが計算される：ＨＰＢ＝ｃｅｉｌ（２１２９／３）＝７１０とＬＰＢ＝ｃｅｉｌ（３５０３／４）＝８７６と及び、ＴＰＢ＝７１０＋８７６＝１５８６であり、これはＰＳ_max＝１４７５よりも大きい。よって、このパラメータの組は有効ではなく、さらに反復が必要となる。次の反復においては、ｎは１だけインクリメントされて５になる。表１から、ｎ＝５に対してはｋ＝４である。これらのパラメータを用いて、ＨＰＢ、ＬＰＢ及びＴＰＢが計算される：ＨＰＢ＝ｃｅｉｌ（２１２９／４）＝５３３とＬＰＢ＝ｃｅｉｌ（３５０３／５）＝７０１と及び、ＴＰＢ＝５３３＋７０１＝１２３４である。このＴＰＢの値はＰＳ_max＝１４７５より小さい。
【００２８】
フレームに関してパラメータｎ、ｋ、ＨＰＢ及びＬＢＰがひとたび決定されると、前述されたリードソロモン符号化、及び、ＨＰ情報及びパリティバイト及びＬＰ情報バイトのパケットへの配置が実行される。詳細に述べれば、プロセッサ１０６がひとたびこれらのパラメータを各フレームに係る分割済みＨＰ及びＬＰデータから決定すると、前述されているように、そのフレームのデータはインターリーブされ、ＲＳ符号化され、デインターリーブされて、ＵＤＰ／ＩＰネットワークを介した送出向けにパケット化される。
【００２９】
図１に示された実施例においては、データ分割ＭＰＥＧエンコーダ１０２は、ビットストリームをＨＰ及びＬＰ部分に分割する目的で用いられる。図４は、別の実施例を示すブロック図である。この実施例は、厳密にはＭＰＥＧ規格に従ってはいないが、オーバーヘッドを低減して性能を向上させる目的で、標準規格に従ったＭＰＥＧエンコーダ及びデコーダを用いている。この実施例は、ＭＰＥＧ−１あるいはＭＰＥＧ−２ビデオ、及びＨ．２６１及びＨ．２６３等の他の同様のビデオ符号化標準に対して適用可能である。この実施例においては、標準的なＭＰＥＧエンコーダ（あるいは他の標準的なエンコーダ）４０１が、入力ビデオストリームを圧縮符号化する。その後、データスプリッタ４０２が、エンコーダ４０１の出力をＨＰ及びＬＰ部分に分割する。本発明の目的に関しては、標準ＭＰＥＧエンコーダ４０１とデータスプリッタ４０２との組み合わせにより、図１に示されたデータ分割ＭＰＥＧエンコーダ１０２と比較して、分割機能がより効率的かつ高性能に実行されることが可能になる。詳細に述べれば、スライスヘッダのみが双方の部分に複製され、他のデータは一方あるいは他方の部分にしか配置されず、双方ということはない。パケットのフレーム配置及びパケットヘッダそれ自体におけるフレーム情報の含まれ方のために、画像ヘッダ以上をそれぞれの部分に複製する必要が無く、オーバーヘッドが最小化される。しかしながら、スライスヘッダをＨＰ及びＬＰ部分の双方に配置することによって、パケットロスに際してＬＰデータに係るエントリポイントが提供される。よって、パケットロスしたパケットに引き続いて受信されたパケットにおいて、そのＬＰデータは、デコーダが次のスライスヘッダをＬＰ部分データと共に受信した後に、デコードされる画像に組み込まれる。図１に示された、パケットロスに引き続いて受信したＬＰデータの挿入ポイントが次のフレームである実施例と比較して、図４の実施例はＬＰデータの挿入ポイントが次のスライスであり、デコードされるビデオ信号の画質が向上する。
【００３０】
前述されているように、データ分割ＭＰＥＧデコーダ１０２は、Ｉフレームにおけるエラーが他のフレームに伝播することによる影響を最小化する目的で、全てのＩフレームデータがＨＰ部分に配置されるようにＩフレームを分割する。Ｂフレームは予測に用いられないため、データ分割標準を介して可能な限り多くのデータがＬＰ部分に配置される。図４に示された実施例においては、標準に従ってある程度のデータがＨＰ部分に必要とされる図１に示された実施例の場合とは異なって、全てのＢフレームに係る全てのデータがＬＰ部分に配置される。図１の実施例と図４の実施例の双方において、Ｐフレームデータは、前述された様式で、ＨＰ及びＬＰ部分に分割される。各々のＰフレーム内では、マクロブロックはフレーム間符号化されるかフレーム内符号化されるかのいずれかである。図４に示された実施例においては、各Ｐフレームにおけるフレーム間及びフレーム内符号化マクロブロックに対して相異なった優先度ブレークポイントが選択されるが、このことは、データ分割ＭＰＥＧエンコーダ１０２では不可能である。ＨＰ部分のみ（すなわち、ＬＰ部分無しで）デコードされたフレーム間符号化マクロブロックは、直前のフレームにおける対応する動き補償済みマクロブロックからの高周波数情報を保持しうるが、フレーム内符号化マクロブロックは保持しない。よって、フレーム内符号化マクロブロックに対する優先度ブレークポイントを、ＨＰ部分におけるＤＣＴ係数をフレーム間符号化マクロブロックよりもより多く含むように設定することが望ましい。このことによって、与えられた品質レベルに対するオーバーヘッドレートが低減され、同一のオーバーヘッドレートに対する品質が向上する。
【００３１】
データスプリッタ４０２のＨＰ及びＬＰ出力は、ＦＥＣコーダ／パケタイザ４０３に供給される。これは、図１に示されたＦＥＣコーダ／パケタイザと同様に機能するものであり、その機能については前述されている。ＦＥＣコーダ／パケタイザ４０３によって出力されるパケットは、ＵＤＰ／ＩＰネットワークを介して送出される。
【００３２】
図４に示された実施例においては、個別の標準ＭＰＥＧエンコーダ４０１及びデータスプリッタ４０２が含まれているが、前述されたデータ分割操作をサポートするデータコーダも、エンコーダ４０１及びスプリッタ４０２が実行する機能と同一の機能を等しく実行することが可能であることに留意されたい。
【００３３】
図１及び図４の実施例におけるエンコーダネットワークは、それらのネットワークに接続された対応するデコーダ宛に、出力パケットを公衆インターネットなどのＵＤＰ／ＩＰネットワークを介して送出する。マルチキャストエンコーダの場合には、送信は、送信される情報を各々受信する複数のエンドユーザ宛の同時ブロードキャストである。この種の相異なったエンドユーザ宛の経路に沿って相異なったパケットが失われうるため、パケットロスを保護する目的で本発明において用いられているＦＥＣ技法は、個々のデコーダがそのエンドユーザ宛の経路において失われた特定のパケットを、エンコーダによって用いられた特定のＲＳ符号によって提供されるパケット保護レベルまで回復することを可能にする。
【００３４】
図１に示されたエンコーダネットワークに係るデコーダネットワーク５００が図５に示されている。データ分割ＭＰＥＧエンコーダ１０２が図１に示されたエンコーダネットワークにおいては用いられているため、図５のデコーダネットワークは、対応するデータ分割ＭＰＥＧデコーダ５１０を組み込んでいる。図５においては、ＵＤＰ／ＩＰネットワーク５０１を介してエンコーダネットワークによって送信された一連のパケットが、デパケタイザ／デコーダ５０２に入力される。デパケタイザ／デコーダ５０２は、連続したパケットを受信して各々のパケットからヘッダ情報を抜き取り、それをプロセッサ５０４へ供給するデパケタイザ５０３を有する。パケットヘッダ情報には、パケット番号とフレーム番とフレームタイプ（Ｉ、Ｂ、Ｐ）とフレームの構造を規定する（ｎ，ｋ）フレームパラメータと、各々のパケットにおけるＨＰ部分のバイト数、ＨＰＢ、及び、ＬＰ部分のバイト、ＬＰＢが含まれる。プロセッサ５０４は、ヘッダ情報からフレームの開始を決定し、パラメータｎから多くのパケットが当該フレームを規定するために用いられることを“知る”。さらに、受信したパケット番号から、プロセッサ５０４は、これらｎ個のパケットのうちのどの特定のパケットが失われたか、及び、これらｎ個の一連のパケットの中での失われたパケットの位置を決定する。プロセッサ５０４よりこの種の全ての情報を受容すると、デパケタイザ５０３はフレーム内の各々のパケットからパケットヘッダを取り除き、各パケット内のデータをＨＰ部分及びＬＰ部分に分割する。失われたと決定されたパケットに関しては、デパケタイザ５０３は、ＨＰ及びＬＰデータストリームに“０”バイトあるいはエラーコードを挿入する。デパケタイザ５０３のＨＰシリアルバイトストリームは、ＨＰデータを含むｎ個のサブパケットよりなり、各々のサブパケットがＨＰＢバイトを含んでいる。このＨＰストリームはインターリーバ５０５に入力され、複数のサブパケットにわたって存在するＲＳ（ｎ，ｋ）符号化ワードをデコードし、最大ｈ個の失われたパケットからの失われたデータを置換する。よってサブパケットにわたる各々のバイト位置に関しては、そのバイト位置におけるそれらサブパケットの各々からバイトが選択され、ＲＳデコーダ５０６へ入力ワード形成される。
【００３５】
例として、図２に示された、ｎが４に等しくｋが３に等しいフレーム構造を用い、ＨＰＢが６５０バイトに等しいとすると、インターリーバ５０５は、ＨＰバイトストリームにおける１番目、６５１番目、１３０１番目、及び１９５１番目のバイトを選択し、ＲＳデコーダ５０６への４バイト入力ワードを構成する。ＲＳデコーダ５０６は、対応する３バイト出力ワードを決定し、これら３バイト出力ワードの各々のバイトが三つの情報サブパケットの第一バイト位置におけるＨＰバイトとなる。次に、インターリーバ５０５は、ＨＰバイトストリーム中の２番目、６５２番目、１３０２番目及び１９５２番目のバイトを、三つの情報サブパケットの各々における第二バイト位置を決定する目的で、ＲＳデコーダ５０６へ供給する。同様に、インターリーバ５０５は３番目から６５０番目のバイトを処理する。このようにして、各々のバイト位置における三つの情報バイトは、ＲＳデコーダ５０６によって順次出力される。ＲＳ（４，３）符号は最大一つの抹消の修正を行なうことが可能であるため、四つの内の一つのパケットが失われてデコーダネットワーク５００によって受信されない場合には、ＲＳデコーダ５０６は、失われたＨＰサブパケットにおける各々のバイト位置での失われたバイトを決定する。よって、プロセッサ５０４が第三パケットが失われたと決定した場合には、ＨＰバイトストリームにおける１３０１番目から１９５０番目までのバイトの各々のバイト位置に“０”バイトが挿入される。プロセッサ５０４は、これら失われたバイトの位置をＲＳデコーダ５０６に供給し、ＲＳデコーダ５０６は、三つの受信済みパケットからのバイトの供給を順次受ける際に、第三パケットの各々のバイト位置における個々の失われたバイトを回復する。よって、ＲＳデコーダ５０４は、失われた単一の第三パケットにおけるＨＰデータのサブパケット全体を回復することが可能となる。この例において、二つ以上のパケットが失われた場合、あるいは、一般にｈ個より多くのパケットが失われた場合には、ＲＳデコーダは失われたデータを再生成することができず、データ分割ＭＰＥＧデコーダ５１０によって認識されうるシーケンスエラーコードが回復されたデータ中のＨＰデータストリームの当該位置に挿入される。
【００３６】
ＲＳデコーダ５０６はｎバイトの入力ワードの各々に対してｋバイトワードを出力し、前記ｋバイトの各々が相異なったサブパケットに関連しているため、デインターリーバ５０７は、各々のｋバイト出力ワードを一度に一バイトずつｋ個の個々のＨＰサブパケットへ再度シーケンスに組み直し、送信された各々のパケット中のＨＰ情報を再形成する。再生成され、必要な場合には回復されてデインターリーバ５０７によって出力され、データ分割ＭＰＥＧデコーダ５１０の第一入力に入力される。失われたパケットが回復不能なところは、データストリームがシーケンスエラーコードを含んでいる。
【００３７】
デパケタイザ５０３によって導出されたｎ個のＬＰサブパケットにおけるＬＰ情報は、データ分割ＭＰＥＧデコーダ５１０の第二入力に同時に入力される。これらのパケットが失われた場合には、ＬＰデータは回復され得ない。なぜなら、フォワードエラー／抹消修正はＬＰ部分には適用されないからである。それゆえ、これらのパケットに関しては、デパケタイザ５０３のＬＰ出力には、失われたものであるとデータ分割ＭＰＥデコーダ５１０によって認識されるようなコードワードが含まれる。
【００３８】
いずれのパケットも失われなかった場合には、データ分割ＭＰＥＧデコーダ５１０へのＬＰ及びＨＰデータストリーム入力は、図１のデータ分割ＭＰＥＧエンコーダ１０２のＬＰ及びＨＰデータストリーム出力と等価である。最大ｈ個のパケットが失われた場合には、デコーダ５１０へ入力されるＨＰデータストリームはエンコーダ１０２によって出力されたＨＰデータストリームと等価であり、デコーダ５１０へ入力されるＬＰデータストリームには、失われたデータをマークするコードワードが含まれる。ｈ個より多くのパケットが失われてＲＳデコーダ５０６が失われたＨＰデータを回復できない場合には、データ分割ＭＰＥＧデコーダ５１０へ入力されるＨＰ及びＬＰデータストリームの双方が失われたデータ、すなわち、ＨＰデータストリームは実際のデータが欠落していることを示すシーケンスエラーコードを、ＬＰデータストリームは失われたデータであることを示す認識可能なコードワードを、それぞれ含んでいる。
【００３９】
データ分割ＭＰＥＧデコーダ５１０は、ＬＰ部分データ及びＨＰ部分データの入力に応答して、標準化されたアルゴリズムに従って、送信されたビデオデータを伸長して再形成する。フレーム内において、対応するＨＰデータが（実際に受信されたかあるいは回復されたかのいずれかで）利用可能であるがＬＰデータが利用可能ではない特定のペルに関しては、再構成されたビデオフレームのビデオ品質が劣化する。さらに、再構成されたビデオフレームにおける、失われたＬＰ部分データに関連しているそれらのペルに走査の観点で引き続く空間的部分も同様に品質が劣化する。なぜなら、次に受信されたパケットにおけるＬＰ部分データは当該フレーム内の特定の空間的ポイントに関連させられること、従ってＨＰデータに関連させられることが不可能であるからである。前述されているように、画像ヘッダのみがＨＰ及びＬＰ部分の双方に含まれている。よって、次の画像ヘッダが受信されるまでは、ビデオフレーム内の、失われたパケットに引き続く全てのＬＰ部分のデータが、ビデオ信号をデコードして再構成する目的で、空間的に対応するＨＰデータに組み合わせられることが不可能である。さらに、本実施例においては、個別のＨＰ及びＬＰ部分に分割されるフレームタイプはＰフレームであって、これらは次のフレームを予測する目的で使用されるため、当該フレームの残りの部分を再構成するためのＬＰ部分の喪失は、次のＰ及びＢフレームの品質に影響を与える。しかしながら、その影響は、より重要なＨＰ部分データが保護されている、本発明に係る実施例を用いない場合に引き起こされるデータの総喪失の影響に比べれば、遥かに低減されたものである。伝送に際してｈ個より多くのパケットが失われる場合には、ＨＰ部分データ及びＬＰ部分データの双方が失われて回復され得ない。よって、標準的なエラー打ち消し技法が、ビデオ品質の低減を最小にする目的で用いられる。
【００４０】
図４に示されたエンコーダネットワークに係るデコーダネットワーク６００が、図６に示されている。デコーダネットワークのこの実施例においては、デパケタイザ／デコーダ６０１が、図４のエンコーダネットワークによって送出されたデータストリームをＵＤＰ／ＩＰネットワークから受信する。デパケタイザ／デコーダ６０１は、図５に示されたデパケタイザ／デコーダ５０２と同一の様式で機能し、図５に関連した記述において示されているものと同一のエレメントを含んでいる。よって、デパケタイザ、インターリーバ、ＲＳデコーダ、デインターリーバに関してはここでは詳細には記述されない。デパケタイザ／デコーダ６０１の出力は、図５のデパケタイザ／デコーダ５０２の出力と同様に、ＬＰ及びＨＰ部分ストリームである。フレーム内のいずれのパケットも失われない場合には、このＬＰ及びＨＰ部分は、図４のエンコーダネットワークにおけるデータスプリッタ４０２の出力と等価である。１個からｈ個までのパケットが失われた場合には、失われた全てのＨＰデータが回復され、ＨＰデータストリームはデータスプリッタ４０２の出力と等価となる。しかしながら、デパケタイザ／デコーダ６０１によって出力されるＬＰストリームは、ＬＰデータが失われたことを示すコードワードを含んでいる。ｈ個より多くのパケットが失われた場合には、ＨＰ及びＬＰデータストリームの双方がエラーコードを含んでいる。あるいは、デパケタイザ／デコーダ６０１は、失われたＨＰ及びＬＰ情報の位置を表わす情報をデータマージャ６０２宛に送出する。
【００４１】
デパケタイザ／デコーダ６０１によって出力されるＬＰ及びＨＰデータストリームはデータマージャ６０２に入力され、これらのデータストリームが、標準ＭＰＥＧデコーダ６０３によって復号化かされ得るフォーマットを有する単一のデータストリームに組み合わせられる。ＭＰＥＧデコーダ６０３は、標準アルゴリズムを用いて符号化済みビデオ信号を伸長し、デジタルビデオ信号を再構成する。このデジタルビデオ信号はアナログビデオ信号に変換されてビデオ端末において表示される。
【００４２】
図４においてエンコーダの記述に関連して前述されているように、スライスヘッダがデータスプリッタ４０２によって出力されるＬＰ及びＨＰ部分の双方に含まれている。よって、図６のデコーダに関しては、パケット及びそのＬＰデータが失われると、それ以降のパケットにおいて受信されたＬＰデータに関するエントリポイントの位置が、そのデータの次のスライスヘッダを検出した際に設定される。よって、前述されているように、受信されたＬＰデータが次のフレームに係る次の画像ヘッダの受信に際してＨＰデータに再び組み込まれるような図５に示された実施例とは異なって、図６の実施例においては、失われたパケットに引き続くパケットにおいて受信されたＬＰデータが、次のスライスヘッダにおけるエントリポイントにおいて、受信あるいは回復されたＨＰデータと組み合わせられることが可能になる。それゆえ、図５に示された実施例の場合のように当該フレームの残り全体の品質が劣化させられるのではなく、失われたＬＰデータに係るフレームのその部分のみが、スライスヘッダが次に受信されるまで劣化させられることになる。さらに、デコードされたフレームの画質的に劣化させられる部分を最小化する目的で、そのフレームに基づいて予測されるそれ以降のフレームの劣化も最小化される。
【００４３】
以上の記述は、本発明の原理を例示するのみである。よって、当業者は、本明細書にはあらわには記述されていないが、本発明の原理を具体化する種々の変形例を作り出すことが可能であるが、それらは本発明の範疇に包含される。さらに、本明細書に記述された全ての実例及び条件言語は、本明細書の読者が、本発明の発明者によって提供される本発明の原理及び概念を理解するのを補助するための教育的目的のみのものであり、これら本明細書に記述された実例に係る制限無しに本発明は実施可能なものである。さらに、本発明の原理、側面、及び実施例を示す目的でなされた全ての記述は、それらに係る全ての実例と共に、それらの構造的及び機能的同等物を包含することを企図したものである。さらに、この種の同等物には、現時点で知られている同等物のみならず将来において開発される同等物、すなわち、その構造に拘わらず同一の機能を実行するように開発された全ての素子を含むことが企図されている。
【００４４】
よって、例えば、当業者は、本明細書に含まれるブロック図が本発明の原理を具体化する回路例を概念的に表現するものであることを理解すべきである。同様に、全ての流れ図、フローダイアグラム等は、コンピュータあるいはプロセッサが明示的に示されているいないに拘わらず、コンピュータによって読みとり可能な媒体によって実質的に表現されて単一あるいは複数個のコンピュータあるいはプロセッサによって実行される種々のプロセスを表現するものであることに留意されたい。
【００４５】
本明細書に含まれる図面に示された、“プロセッサ”として明示された機能ブロックを含む種々の素子の機能は、専用のハードウエア及び適切なソフトウエアと共に当該ソフトウエアを実行することが可能なハードウエアの使用を通じて提供されうる。プロセッサによって提供される場合には、それらの機能は、専用の単一プロセッサ、単一の共有されたプロセッサ、あるいは、そのうちのいくつかが共有された、複数個の個別のプロセッサ等によって提供される。さらに、“プロセッサ”あるいは“コントローラ”という術語の明示的使用は、ソフトウエアを実行することが可能なハードウエアのみを指し示すことを企図するものではなく、暗示的に、デジタルシグナルプロセッサ（ＤＳＰ）ハードウエア、ソフトウエアをストアするリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性記憶媒体を含むが、それらに制限されるものではない。他の汎用あるいはカスタムハードウエアも含まれることが可能である。それらの機能は、プログラムロジックの動作、専用ロジック、プログラム制御及び専用ロジックの組み合わせ等によって、さらには、手動で実行されうるが、それらの目的で本発明の実施者によって選択されうる特定の技法は本明細書本文より理解されうるものである。
【００４６】
本明細書の請求項において、特定の機能を実行する手段として表現されているあらゆる素子には、例えば、ａ）その機能を実行する回路素子の組み合わせ、あるいは、ｂ）ファームウエア、マイクロコード等の、そのソフトウエアを実行する適切な回路との組み合わせで当該機能を実行する、あらゆる形態のソフトウエア、を含む、当該機能を実行するあらゆる手段が包含されることが企図されている。そのような請求項によって規定される本発明は、種々の記述された手段によって提供される機能が、それら請求項が要求する様式で組み合わせられて実現されているという事実に基づくものである。よって、本発明の発明者は、本明細書に記述されているものと同等の機能を実現することが可能な全ての手段が本発明に包含されることを主張する。
【００４７】
【発明の効果】
以上述べたごとく、本発明によれば、パケットロスからビデオ品質を保護する目的でＭＰＥＧビデオなどのフレーム間符号化ビデオに回復情報を追加する低オーバーヘッドでかつ低遅延な方法が提供される。
【図面の簡単な説明】
【図１】本発明に従った、ビデオ信号を符号化して符号化済みビデオ信号をＨＰ部分とＬＰ部分とに分割するデータ分割ＭＰＥＧエンコーダを用いるビデオエンコーダの第一実施例を示すブロック図。
【図２】ＲＳ（４，３）符号化の一例に関するフレームに係るパケット内でのＨＰデータ及びパリティ情報、及びＬＰデータの配置を示す模式図。
【図３】フレーム内のＬＰ及びＨＰバイトの個数の関数として当該フレームに係るパラメータｎ及びｋを決定する方法の詳細を示す流れ図。
【図４】標準ＭＰＥＧエンコーダがビデオ信号を符号化する目的で用いられ、データスプリッタが符号化済み信号をＨＰ及びＬＰ部分に分割する、本発明に従ったビデオエンコーダの第二実施例を示すブロック図。
【図５】ＨＰ及びＬＰ部分からビデオ信号を復号化する目的でデータ分割ＭＰＥＧデコーダが用いられる、本発明に従った、失われたパケットが再構成されてＨＰ及びＬＰ部分が再形成されるビデオデコーダの実施例を示すブロック図。
【図６】データマネージャがＨＰ及びＬＰ部分を組み合わせてそれらがビデオ信号を復号化する標準ＭＰＥＧデコーダに供給される、本発明に従ったビデオデコーダの第二実施例を示すブロック図。
【符号の説明】
１０１入力ビデオデータストリーム
１０２データ分割ＭＰＥＧエンコーダ
１０３ＦＥＣコーダ／パケタイザ
１０４高優先度部分
１０５低優先度部分
１０６プロセッサ
１０７インターリーバ
１０８ＲＳエンコーダ
１０９デインターリーバ
１１０パケタイザ
１１１出力
４０１標準ＭＰＥＧエンコーダ
４０２データスプリッタ
４０３ＦＥＣコーダ／パケタイザ
５００デコーダネットワーク
５０１ＵＤＰ／ＩＰネットワーク
５０２デパケタイザ／デコーダ
５０３デパケタイザ
５０４プロセッサ
５０５インターリーバ
５０６ＲＳデコーダ
５０７デインターリーバ
５１０データ分割ＭＰＥＧデコーダ
６００デコーダネットワーク
６０１デパケタイザ／デコーダ
６０２データマージャ
６０３標準ＭＰＥＧデコーダ

Claims

パケットベースのネットワークを介する伝送のためにビデオ信号を符号化する方法において、本方法が、
（Ａ）ビデオ信号を圧縮符号化するステップと、
（Ｂ）前記圧縮符号化されたビデオ信号の少なくとも一つのフレームを高優先度部分情報バイトのストリームと低優先度部分情報バイトのストリームとに分割するステップと、
（Ｃ）前記高優先度部分情報バイトのストリーム内の所定のバイト位置に位置する所定の数の高優先度部分情報バイトの各入力に対してシステマティックフォワードエラー／抹消修正（ＦＥＣ）符号を適用して、入力された高優先度部分情報バイト及び関連する一つ又は複数のパリティバイトの組み合わせよりなる、各入力についてのＦＥＣ符号化された出力を生成するステップと、
（Ｄ）前記ストリーム内の前記低優先度部分情報バイトと、前記ＦＥＣ符号化された、複数の高優先度部分情報バイトとを含む所定の複数のパケットを形成するステップであって、前記所定の複数のパケットは、各々のＦＥＣ符号化された出力の各バイトを異なるパケット内の同じバイト位置に配置するようなやり方で、各々のＦＥＣ符号化された出力のうちの前記高優先度部分情報バイト及び前記関連する一つ又は複数のパリティバイトが前記複数のパケットにわたって分散されるように、前記低優先度部分情報バイトと前記複数のＦＥＣ符号化された出力とを前記複数のパケットに配置することによって形成され、各パケット内の所定の数のバイト位置が、前記低優先度部分情報バイトのストリームからの低優先度情報バイトを含むために割り当てられ、各パケット内の所定の数の同一のバイト位置が、前記ＦＥＣ符号化された出力からの全ての高優先度部分情報バイトと、全てのパリティバイトとのうちのいずれか一方を含むように割り当てられる、ステップとを有すること
を特徴とする方法。
各々のパケットが等しい長さを有し、各々のパケットに、等しい個数の低優先度部分情報バイトが含まれており、各々のパケットに、等しい個数の高優先度部分情報バイトあるいはパリティバイトが含まれていることを特徴とする請求項１に記載の方法。
前記方法が、さらに、
（Ｅ）前記圧縮符号化されたビデオ信号の前記少なくとも一つのフレームに関して、高優先度部分情報バイトの個数及び低優先度部分情報バイトの個数を決定するステップと、
（Ｆ）１つ又は複数のパケットの喪失に対する所定の望ましい最低保護レベルに関して、高優先度部分情報バイトの前記個数、低優先度部分情報バイトの前記個数、及びパケット当たりの所定の最大バイト数から、前記少なくとも一つのフレームに関して、（１）パケット当たりのバイト数、（２）高優先度部分情報バイト、関連するパリティバイト、及び低優先度部分情報バイトに対して必要とされる総パケット数（ｎ）、及び、（３）前記ｎ個のパケットのうちで高優先度部分情報バイトを含むパケット数（ｋ）を決定するステップと、
を有することを特徴とする請求項２に記載の方法。
前記ビデオ信号を圧縮符号化するステップがＭＰＥＧ符号化を用いることを特徴とする請求項１に記載の方法。
前記少なくとも一つのフレームが単一フレームであって、前記分割するステップが、前記圧縮符号化されたビデオ信号の情報バイトを、前記圧縮符号化されたビデオ信号のマクロブロックの各々における優先度ブレークポイントにおいて、高優先度部分情報バイトと低優先度部分情報バイトとに分割するステップを有し、
前記優先度ブレークポイントは、前記ビデオのフレームがフレーム内符号化Ｉフレームであるか、予測Ｐフレームであるか、あるいは予測Ｂフレームであるかに基づいて決定され、
前記フレームがＩフレームである場合には、前記優先度ブレークポイントは、前記圧縮符号化されたビデオ信号の実質的に全ての情報バイトが高優先度部分情報バイトであるように選択され、
前記フレームがＢフレームである場合には、前記優先度ブレークポイントは、前記圧縮符号化されたビデオ信号の実質的に全ての情報バイトが低優先度部分情報バイトであるように選択され、
前記フレームがＰフレームである場合には、前記圧縮符号化されたビデオ信号内のマクロブロックに係る情報バイトが、前記マクロブロックがフレーム内符号化マクロブロックであるかフレーム間符号化マクロブロックであるかに基づいて決定される優先度ブレークポイントにおいて、高優先度部分情報バイトあるいは低優先度部分情報バイトとして分割される
ことを特徴とする請求項４に記載の方法。
パケットベースのネットワークを介する伝送のためにビデオ信号を符号化するエンコーダにおいて、本エンコーダが、
前記ビデオ信号を圧縮符号化する手段と
前記圧縮符号化されたビデオ信号の少なくとも一つのフレームを高優先度部分情報バイトのストリーム及び低優先度部分情報バイトのストリームに分割する手段と
前記高優先度部分情報バイトのストリーム内の所定のバイト位置に位置する所定の数の高優先度部分情報バイトの各入力に対してシステマティックフォワードエラー／抹消修正（ＦＥＣ）符号を適用して、入力された高優先度部分情報バイト及び関連する１つ又は複数のパリティバイトの組み合わせよりなる、各入力についてのＦＥＣ符号化された出力を生成する手段と、
各々のＦＥＣ符号化された出力の各バイトを異なるパケット内の同じバイト位置にそれぞれ配置するようなやり方で、各々のＦＥＣ符号化された出力のうちの前記高優先度部分情報バイト及び前記関連する一つ又は複数のパリティバイトが所定の複数のパケットに亘って分散されるように、前記低優先度部分情報バイトと複数の前記ＦＥＣ符号化された出力とを前記所定の複数のパケットに配置する手段であって、各パケット内の所定の数のバイト位置は、前記低優先度部分情報バイトのストリームからの低優先度情報バイトを含むために割り当てられ、各パケット内の所定の数の同一のバイト位置が、前記ＦＥＣ符号化された出力からの全ての高優先度部分情報バイトと、全てのパリティバイトとのうちのいずれか一方を含むように割り当てられる、手段とを有する
ことを特徴とするエンコーダ。
各々のパケットが等しい長さを有し、各々のパケットに、等しい個数の低優先度部分情報バイトが含まれており、各々のパケットに、等しい個数の高優先度部分情報バイトあるいはパリティバイトが含まれていることを特徴とする請求項６に記載のエンコーダ。
前記エンコーダが、さらにプロセッサを有しており、前記プロセッサが、
前記圧縮符号化されたビデオ信号の前記少なくとも一つのフレームに関して、高優先度部分情報バイトの個数及び低優先度部分情報バイトの個数を決定し
１つ又は複数のパケットの喪失に対する所定の望ましい最低保護レベルに関して、高優先度部分情報バイトの前記個数、低優先度部分情報バイトの前記個数、及びパケット当たりの所定の最大バイト数から、前記少なくとも一つのフレームに関して、（１）パケット当たりのバイト数、（２）高優先度部分情報バイト、関連するパリティバイト、及び低優先度部分情報バイトに対して必要とされる総パケット数（ｎ）、及び、（３）前記ｎ個のパケットのうちで高優先度部分情報バイトを含むパケット数（ｋ）を決定する
ことを特徴とする請求項７に記載のエンコーダ。
前記ビデオ信号を圧縮符号化する手段がＭＰＥＧ符号化を用いることを特徴とする請求項６に記載のエンコーダ。
前記少なくとも一つのフレームが単一フレームであって、前記分割する手段が、前記圧縮符号化されたビデオ信号のマクロブロックの各々における優先度ブレークポイントにおいて、前記圧縮符号化されたビデオ信号の情報バイトを高優先度部分情報バイトと低優先度部分情報バイトとに分割し、
前記優先度ブレークポイントは、前記ビデオのフレームがフレーム内符号化Ｉフレームであるか、予測Ｐフレームであるか、あるいは予測Ｂフレームであるかに基づいて決定され、
前記フレームがＩフレームである場合には、前記優先度ブレークポイントは、前記圧縮符号化されたビデオ信号の実質的に全ての情報バイトが高優先度部分情報バイトであるように選択され、
前記フレームがＢフレームである場合には、前記優先度ブレークポイントは、前記圧縮符号化されたビデオ信号の実質的に全ての情報バイトが低優先度部分情報バイトであるように選択され、
前記フレームがＰフレームである場合には、前記分割する手段が、前記圧縮符号化されたビデオ信号内のマクロブロックに係る情報バイトを、前記マクロブロックがフレーム内符号化マクロブロックであるかフレーム間符号化マクロブロックであるかに基づいて決定される優先度ブレークポイントにおいて、高優先度部分情報バイトあるいは低優先度部分情報バイトとして分割する
ことを特徴とする請求項９に記載のエンコーダ。