JP5908107B2 - 層認識のある前方誤り訂正のためのインターリーブ - Google Patents

Description

本発明は、誤り訂正データ発生器、誤り訂正デコーダ、誤り訂正符号化方法、誤り訂正復号化方法、および対応する計算機可読のディジタル記憶媒体に関する。

最初に、いわゆるＬＡ−ＦＥＣ（Ｌａｙｅｒ Ａｗａｒｅ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）方法の概要が、与えられるであろう。その内容は、［５］（非特許文献１）および［１８］（特許文献１）においてすでに発表された。ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）は、ＳＶＣビデオストリームの部分同士の間に依存性を導入する符号化効率を達成するための様々な時間的および層間予測を使用する。図１は、基層および基層の時間および空間分解能を増加させる１つの拡張層とともに、典型的な符号化構造を示す。さらに、図１は、階層予測構造および層間予測による時間−空間スケーラビリティの範囲内での依存性を図式化して示す。図１における矢印は、異なるアクセス装置間の依存性を示す。

ＳＶＣにおいて、基層は、拡張層より重要である。基層情報を失った場合には、拡張層情報は、失った予測情報のため役立たなくなるのが一般的である。

それゆえ、ロバスト性における相違は、ＳＶＣの伝送のために、一般的に有益であり、そこでは、基層は、拡張層より強い保護を得る。

米国特許出願公開第２０１０／０１７６８６号明細書

Cornelius Hellge, David Gomez-Barquero, Thomas Schierl, and Thomas Wiegand:Layer-Aware Forward Error Correction for Mobile Broadcast of Layered Media,IEEE Transactions on Multimedia, vol. 13, pp. 551-562, 2011.

請求項１に記載の誤り訂正エンコーダ、請求項８に記載の誤り訂正デコーダ、請求項１６に記載の誤り訂正符号化方法、請求項１７に記載の誤り訂正復号化方法、請求項１８に記載の計算機可読のディジタル記憶媒体は、上記でなされた説明に関して改良された誤り訂正符号化／復号化を提供する。

実施例は、第１のカテゴリー（第１のカテゴリーペイロードデータ）に属するペイロードデータを受信し、第２のカテゴリーに属するペイロードデータを受信し、第１のカテゴリーペイロードデータのための第１の誤り訂正データを決定し、かつ、第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定するための誤り訂正データ発生器を備えた誤り訂正エンコーダを提供する。誤り訂正エンコーダは、少なくとも第２の誤り訂正データおよび第２のカテゴリーペイロードデータを互いにインターリーブするためのインターリーバをさらに備え、第１の誤り訂正データおよび第１のカテゴリーペイロードデータのインターリーブに関する第１のインターリーブ長は、第２の誤り訂正データおよび第２のカテゴリーペイロードデータのインターリーブに関する第２のインターリーブ長と異なる。

更なる実施例は、第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームをデインターリーブするためのデインターリーバを備えた誤り訂正デコーダを提供する。誤り訂正デコーダは、デインターリーバからのデインターリーブされた形式の第１のカテゴリーペイロードデータ，第１の誤り訂正データ，第２のカテゴリーペイロードデータ，および第２の誤り訂正データを受信し、少なくとも第１の誤り訂正データを使用して第１のカテゴリーペイロードデータにおける起こり得るエラーを訂正し、かつ少なくとも第２の誤り訂正データを使用して第２のカテゴリーペイロードデータにおける可能なエラーを訂正するための誤り訂正器をさらに備える。第１のカテゴリーペイロードデータおよび第１の誤り訂正データのインターリーブに関する第１のインターリーブ長は、第２のカテゴリーペイロードデータおよび第２の誤り訂正データのインターリーブに関する第２のインターリーブ長と異なる。

更なる実施例によれば、誤り訂正符号化方法は、第１のカテゴリーに属するペイロードデータを受信し、かつ第２のカテゴリーに属するペイロードデータを受信するステップを含む。第１の誤り訂正データは、そのとき第１のカテゴリーペイロードデータのために決定される。第２の誤り訂正データは、第２のカテゴリーペイロードデータのために決定される。その方法は、さらに、少なくとも第２の誤り訂正データおよび第２のカテゴリーペイロードデータを互いにインターリーブすることを含み、第１の誤り訂正データおよび第１のカテゴリーペイロードデータのインターリーブに関する第１のインターリーブ長は、第２の誤り訂正データおよび第２のカテゴリーペイロードデータのインターリーブに関する第２のインターリーブと異なる。

更なる実施例は、誤り訂正復号化方法を提供する。この方法は、第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームを受信することからなる。インターリーブされたデータストリームは、その後デインターリーブされる。その方法もまた、第１のカテゴリーペイロードデータおよび第１の誤り訂正データを受信するかまたは獲得することからなる。第１のカテゴリーペイロードデータにおける可能なエラーは、少なくとも第１の誤り訂正データを使用して訂正され、かつ第２のカテゴリーペイロードデータにおける可能なエラーは、少なくとも第２の誤り訂正データを使用して訂正される。第１のカテゴリーペイロードデータおよび第１の誤り訂正データのインターリーブに関する第１のインターリーブ長は、第２のカテゴリーペイロードデータおよび第２の誤り訂正データのインターリーブに関する第２のインターリーブ長と異なる。

更なる実施例は、コンピュータ上で実行したとき、本願明細書において記載されているように、誤り訂正符号化または復号化方法、または、誤り訂正符号化方法および誤り訂正復号化方法の両方を実行するプログラムコードを有するコンピュータプログラムをその上に格納する計算機可読のディジタル記憶媒体を提供する。

更なる実施例は、ペイロードデータを受信して、ペイロードデータのための誤り訂正データを決定するための誤り訂正データ発生器と、誤り訂正データおよびペイロードデータをインターリーブするためのインターリーバとを備えた誤り訂正エンコーダを提供する。誤り訂正データは、インターリーブされたデータストリーム中のペイロードデータに先行し、ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異なる。

更なる実施例は、ペイロードデータおよびペイロードデータのための誤り訂正データからなるインターリーブされたデータストリームをデインターリーブするためのデインターリーバを備えた誤り訂正デコーダを提供する。誤り訂正データは、インターリーブされたデータストリーム中のペイロードデータに先行する。ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異なる。誤り訂正デコーダは、ペイロードデータおよび誤り訂正データを受信するための、そして、誤り訂正データを使用してペイロードデータにおける可能なエラーを訂正するための誤り訂正器をさらに備える。ペイロードデータだけが受信され、誤り訂正データが失われたときは、ペイロードは、利用できるが、おそらく誤りである。

以下に、本発明の好ましい実施例は、図面を参照してさらに詳細に説明される、そして、いくつかの設計態様に関して、利点を提供する本発明のさまざまな好ましい実施例が、強調される。

階層的予測構造および層間予測による時間−空間スケーラビリティ内での依存性を図式的に示す説明図である。 層認識のあるＦＥＣ生成の一般的アプローチを図式的に示す説明図である。 標準およびＬＡ−ＦＥＣの符号化を図式的に示す説明図である。 標準ＦＥＣおよびＬＡ−ＦＥＣの復号化を図式的に示す説明図である。 〔３〕において記述されているように、Ｒａｐｔｏｒプリコーディング処理による、ソースシンボルからプリコーディングシンボルの生成を図式的に示す説明図である。 〔３〕において記述されているように、Ｒａｐｔｏｒ符号のＬＴ−符号化処理による符号化シンボルの生成を概略的に示す説明図である。 〔１〕における仕様に続く、２層のためのＬＡ−ＦＥＣ Ｐａｐｔｏｒプリコーディングマトリックスを図式的に示す説明図である。 ２層を有するＬＡ−ＦＥＣ Ｒａｐｔｏｒ ＬＴ−符号化処理を図式的に示す説明図である。 １３００ｋｂｐｓの固定サービスビットレートでのＳＶＣ層ＣＲ(基層／拡張層)にわたって様々な符号レート分布で標準（ＳＴ）−ＦＥＣおよびＬＡ−ＦＥＣを使用しているＶＧＡ受信機のための２５０フレーム（図９Ａ）の静止画の平均枚数および平均ＰＳＮＲ値（図９Ｂ）を図式的に示す説明図である。 １３００ｋｂｐｓの固定サービスビットレートでのＳＶＣ層ＣＲ(基層／拡張層)にわたって様々な符号レート分布で標準（ＳＴ）−ＦＥＣおよびＬＡ−ＦＥＣを使用しているＶＧＡ受信機のための２５０フレーム（図９Ａ）の静止画の平均枚数および平均ＰＳＮＲ値（図９Ｂ）を図式的に示す説明図である。 標準ＬＤＰＣマトリックス（上部）および拡張ＬＤＰＣマトリックス（下部）を図式的に示す説明図である。 拡張ＬＡ−ＦＥＣ復号化マトリックスを図式的に示す説明図である。 ＡＷＧＮチャンネルにおける１６ｋ ＬＡ−ＦＥＣ対（vs.）１６ｋ 標準（St-）ＦＥＣのシミュレーション結果を示す説明図である。 ｋ０ソースおよびｐ０パリティシンボルおよび増加する時間多様性（ＩＬ=１，２，３）を有するＦＥＣソースブロック０（ＳＢ０）の様々なインターリーブ長（ＩＬ）を図式的に示す説明図である。 層０または単層のために使用された［２］において記述された、ＲａｐｔｏｒＱに類似したプリコーディングマトリックスを図式的に示す説明図である。同じプリコーディングマトリックスが復号化および符号化プロセスで使用されていることに注意されたい。 ＲａｐｔｏｒＱのＬＴ符号化プロセスを図式的に示す説明図である。 ２層を有するＬＡ−ＦＥＣ ＲａｐｔｏｒＱのプリコーディングプロセスを図式的に示す説明図である。 層０のプリコーディングシンボルに、２層および拡張マトリックスを有するＬＡ−ＦＥＣ ＲａｐｔｏｒＱ符号化プロセスの第２のステップを図式的に示す説明図である。 送信機側プロセスを図式的に示す説明図である。 伝送の範囲内で典型的なバースト誤りを含む受信機処理の一例を図式的に示す説明図である。 ＦＥＣソースブロックインターリーブのプロセスを図式的に示す説明図である。 単層の場合、各層（ＳＴ−ＦＥＣ）に対し独立してＦＥＣ生成を有する標準ＦＥＣ、および異なるインターリーブ長を持つＬＡ−ＦＥＣ ＵＩにつき、特定の抹消確率上のＰＳＮＲに関する受信ビデオ品質を図式的に示す説明図である。 基層（図２２Ａ）の、および、拡張層（図２２Ｂ）の、層復号確率を図式的に示す説明図である。 基層（図２２Ａ）の、および、拡張層（図２２Ｂ）の、層復号確率を図式的に示す説明図である。 １および８のインターリーブ長を有する単層（ＳＬ）と呼ばれる１つのＦＥＣソースブロックの範囲内で、オーディオおよびビデオの両方を有するメディア復号確率に関する比較を図式的に示す説明図である。 ソースシンボル数ｋ、ソースシンボルサイズＴ、ユニークなシンボル識別子（ＦＥＣ−ＩＤ）および実際のソースブロックのインターリーブ長（ＩＬ）を有するインターリーブ長(ＩＬ) の典型的な帯域内信号伝送を図式的に示す説明図である。

図面の説明を通して、これらの図面のいくつかに現れる要素は、これらの図の各々の同じ参照符号によって示され、かつ、機能に関する限りこれらの要素の繰り返された説明は、不必要な反復を回避するために、回避されることに注意すべきである。それにもかかわらず、１つの図面に関して備わる機能および説明は、異なるものが明示されない限り、他の図面にも当てはまるべきである。

層認識のあるＦＥＣ−一般的アプローチ：

このセクションは、ＬＡ−ＦＥＣアプローチに関する概観を提供する。ＬＡ−ＦＥＣの基本的なアプローチは、図２に示される。図２は、層認識のあるＦＥＣ生成の可能な一般的アプローチを示す。層０の冗長性は、以下の基本的なＦＥＣアルゴリズム（Ｒａｐｔｏｒ）を発生する。層１から層Ｎまでの冗長性は、すべての従属する層にわたって発生する。層認識のあるＦＥＣ（ＬＡ−ＦＥＣ）アプローチに関する基本的な考えは、従属するビデオ層にわたってＦＥＣアルゴリズムの符号化プロセスを延長することである。基層のＦＥＣ処理は、放置されている、それによって、基層が独立して復号化し得ることがなお可能であり、元のＦＥＣアルゴリズムの訂正能力を保っている。ＦＥＣアルゴリズムの範囲内のより重要でないメディア層からの導入された接続のため、より重要なメディア層は、付加的な修理データによって保護されている。これは、付加的な修理データを加えることなく、より重要な層の誤り訂正能力を増加させる。図２のスキームは、交差層ＦＥＣの生成を示す。基層（「層０」）ＦＥＣ生成プロセスが変わらない一方、「層１」のＦＥＣデータが「層１」および「層０」のソースシンボルにわたって発生し、「層２」のＦＥＣデータは「層Ｎ」のＦＥＣデータにいたるまで「層２」，「層１」，および「層０」などに発生する、そして、それは、「層Ｎ」およびすべての従属するメディア層のソースシンボルにわたって発生する。一般的なＦＥＣアプローチとして、ＬＡ−ＦＥＣは、いかなるＯＳＩ層（物理、リンクまたはアプリケーション層）でも統合することができ、単にすべての従属するメディア層上のメディア拡張層の符号化プロセスを拡張することによって、例えばＬＤＰＣ、ＲａｐｔｏｒなどＦＥＣコードだけでなくＲａｐｔｏｒＱにも適用できる。

ＬＡ−ＦＥＣアプローチの原理を示すために、図３および図４は、１つのソースブロックのための単純なパリティチェック符号を使用した標準ＦＥＣおよびＬＡ−ＦＥＣ（変更態様は、点線によってマークされている）の符号化および復号化プロセスを比較する。実施例において、抹消チャンネルが仮定されている。２つの良質な層は、ＦＥＣ符号化されており、そこでは、層１は、メディアストリーム（例えばＳＶＣ）の範囲内で、層間予測により層０に依存する。各層ｌ＝０，１に対し、３つのソースビットｋ０／１＝３および２つのパリティｐ０／１＝２ビットが存在する。

符号化（図３）のために、パリティビットは、ソースビットの単なるＸＯＲ処理により計算される。標準ＦＥＣを用いることにより、ＸＯＲプロセスは、現在の層の範囲内で適用されるだけであるが、ＬＡ−ＦＥＣを用いることにより、ＸＯＲプロセスは、既存の依存性に続く層全体に拡大される。それゆえ、層１のパリティビットが、層０および層１の両方の層のソースビット上に発生し、層０のパリティビットと共に、両方の層の誤り訂正のために、更に使用できる。ソースおよびパリティビットは、符号語に結合され、エラーを生起しやすいチャンネルを通じて伝送される。

概説された復号化例（図４）において、「？」によってマークされた層０の符号語内で３つの伝送エラーが存在し、層１においては、エラーは存在しない。概説された実施例は、ビットまたはパケットは正しく、もしくは、未知の状態で（図において『？』がマークされる）受信される抹消チャンネル、例えばバイナリ抹消チャンネル（ＢＥＣ）またはギルバート−エリオット（Gilbert-Elliot）チャンネルを仮定することに注意されたい。この種のチャンネルモデルは、下層側のＩＳＯ／ＯＳＩ層、例えば物理層、で実行される先行方法は、（例えば、ＬＤＰＣ符号または／および巡回冗長検査（ＣＲＣ）によって）誤り訂正または誤り検出を構成する、リンクまたはアプリケーション層での伝送エラーをシミュレーションするために用いられる。物理層上のＦＥＣコードは、概して、復調プロセスに由来するＬＬＲ値とともに作用するが、リンクまたはアプリケーション層ＦＥＣ上のＦＥＣコードは抹消別名ロットパケットとともに作用する。物理層で訂正できないパケットは、通常、誤りとマークされて、より上位の層（例えばリンクまたはアプリケーション層）に転送される。そのために、リンクまたはアプリケーション層で実行されるＦＥＣコードは、誤り検出のための実行手段を必要としない。しかしながら、挙げられた実施例がちょうど単純性のためにアプリケーションまたはリンク層上に示される、そして、この明細書内で提案された方法が「ＬＰＤＣコードを有する物理チャンネル上のＬＡ−ＦＥＣ」、それはエラーチャンネル（例えばＡＷＧＮ）に作用して、誤り検出のための手段を必要とする、セクション内のＬＰＤＣの記述に示されたように物理層に適用もできる点に、ここで注意することは重要である。標準ＦＥＣを用いることにより、層０内には充分なパリティビットが存在しない。従って、それは、訂正し得ない。層１がうまく受信されるにもかかわらず、それが層０において失われた依存性のため使用し得ない。ＬＡ−ＦＥＣを使用することにより、層１のパリティビットは、層０を訂正するための層０のパリティビットと共に使用し得る。挙げられた実施例において、ＬＡ−ＦＥＣのみとともに、両方の層は、訂正し得る。要約すれば、図４は、標準およびＬＡ−ＦＥＣの復号化を図式的に示す。ＬＡ−ＦＥＣを用いて、両方の層のパリティビットが、組合せ復号化のために使用し得る。

基層保護の改良は、拡張層の保護を減少させることにより成り立つ。ＬＡ−ＦＥＣについては、拡張層は、基層の独立性を訂正し得ない。それにもかかわらず、ＳＶＣビデオストリーム内に依存性が存在するため、基層が失われるこの種のケースにおいて、一般的に、拡張層データが、使用もできない。従って、ＬＡ−ＦＥＣは、ビデオ品質に関して標準ＦＥＣより劣るよう実行することは決してない。

［１］における議論の後に、ＳＴ−ＦＥＣおよび最適ＦＥＣアルゴリズムを有する層ｌを復号化するための条件は、式（１）によって与えられる：

ｒ₀＞ｋ₀ および ｒ₁＞ｋ₁ （１）

拡張層によりＬＡ−ＦＥＣのシンボルも、基層シンボルを保護し、基層を復号化する条件［１］は、ＬＡ−ＦＥＣとともに式（２）に変化する：

（ｒ₀≧ｋ₀）∪（ｒ₀＋ｒ₁≧ｋ₀＋ｋ₁） （２）

ＬＡ−ＦＥＣとともに、拡張層ＦＥＣの訂正は、基層の回復に依存するため、拡張層を回復する条件は、ＬＡ−ＦＥＣとともに式（３）に変化する：

（ｒ₁≧ｋ₁）∩（ｒ₀＋ｒ₁≧ｋ₀＋ｋ₁） （３）

しかしながら、拡張層は、既存のメディア依存性のため基層に依存するとはいえ、拡張層はいずれにしろ基層なしで使用できない。その結果、ＳＴ−ＦＥＣについても、拡張層の成功したメディア復号化の条件は、式（３）と同じである。

Ｒａｐｔｏｒ ＦＥＣへの層認識のあるＦＥＣ統合：

ＬＡ−ＦＥＣスキームは、ＬＤＰＣコード類似の物理層上のＦＥＣまたはＲａｐｔｏｒ［１］，［３］類似のより上位の層ＦＥＣsの両方に適用し得る。ここで典型的と考えられるより上位の層ＦＥＣは、Ｒａｐｔｏｒ−ＦＥＣである。示された拡張が、セクション「ＲａｐｔｏｒＱ−ＦＥＣへの層認識のあるＦＥＣ統合」に記載されているようなより効率的なＲａｐｔｏｒＱ ＦＥＣ［２］への類似の方法において適用し得ることに注意されたい。

Ｒａｐｔｏｒコードは、一般に線形時間符号化および復号化を有する噴水コードの第１の周知のクラスの一つである。符号化の準備において、一定量のデータは、ソースブロック内に集められる。ソースブロックのデータは、固定のシンボルサイズのｋ₀ソースシンボルに、更に分割される。図５および図６は、２つの符号化ステップ、プリコード生成およびＬＴ−符号生成からなる単一メディア「層０」に対し、［３］に記述されたようなＲａｐｔｏｒ符号化（en-）および復号化プロセスの２つのステップを示す。図５は、［３］に記述されたようなＲａｐｔｏｒプリコーディングプロセスによりソースシンボルからのプリコーディングシンボルの生成を図式的に示す。図６は、［３］に記述されたＲａｐｔｏｒ符号のＬＴ−符号化プロセスによる符号化シンボルの生成を図式的に示す。［３］における仕様書が、符号化および復号化のための同じ二段階プロセスを記述していることに注意されたい。第１のステップにおいて、固定レートの「プリコード」ステップ、ここで例えばＬＤＰＣのような任意の抹消コードは、一般的に、層ｌ＝０のいわゆるＬ₀プリコーディングシンボルを生成するために、ソースシンボルに適用し得る。プリコーディングシンボルの値は、プリコードマトリックスＧ＿ＬＤＰＣ₀,単位行列Ｉ＿Ｓ₀,零マトリックス０＿ＳｘＨ₀,および、ＬＴマトリックスＧ＿ＬＴ₀［０：ｋ₀−１］からなる図５に示されるマトリックスによって、決定される、そこでは、後者は、第２の符号化プロセスにおけるＧ＿ＬＴ₀［０：ｎ₀−１］の第１のｋ₀行と同一である。ブラケット内の値は、行の個数を意味する。マトリックスＧ＿ＬＴ₀の統合は、ＬＴ符号化後の第１のｋ₀符号化シンボルが、ソースシンボルと同一であり、Ｒａｐｔｏｒ符号は、組織符号語を提供することを確実にする。第１ステップを確定させた後に、プリコーディングシンボルは、第２ステップ、ＬＴ符号化に転送される。

ｎ₀符号化シンボルの泉は、ＬＴコードによって与えられ、図６に表現されたＧ＿ＬＴ₀[０：ｎ₀−１]マトリックスにより示されている接続に続くプリコーディングシンボルのＸＯＲ演算により計算されている。また、ＬＡ−ＦＥＣについては、基層符号化シンボルの生成が元のＲａｐｔｏｒプロセスに従うことに注意されたい。

標準ＦＥＣアプローチについては、層１（拡張層）の符号化シンボルは、［３］におけるプロセスの後に、同様に生成される。ＬＡ−ＦＥＣを有する拡張「層１」の符号化されたシンボルの生成のために、ＬＡ−ＦＥＣアプローチは、Ｒａｐｔｏｒ符号化プロセスに組込まれることを必要とする。これは、一方では、基層のプリコーディングシンボルのＬＴ符号化ステップのＧ＿ＬＴマトリックスの拡張を、そして他方では符号の組織的行動を保存するために、プリコーディングプロセスのＧ＿ＬＴマトリックスの拡張を必要とする。図７および図８は、層ｌ＝１の符号化されたシンボルの生成のための必要な拡張を示す。図７は、［１］における仕様書の後に、２つの層のためのＬＡ−ＦＥＣ Ｒａｐｔｏｒプリコーディングマトリックスを図式的に示す。

ＬＡ−ＦＥＣ Ｒａｐｔｏｒのプリコーディングマトリックスは、２層に対し図７に示される。マトリックスは、２層（左上および右下）の２つのプリコーディングマトリックス、零マトリックス（右上）、および層１から層０（左下）へのＬＡ−ＦＥＣ拡張、の連結からなる。ＬＡ−ＦＥＣ拡張は、コードを組織的に保つために必要とされる。Ｇ＿ＬＴ₁および関連した拡張Ｇ＿ＬＴ₀[ｎ₀：ｎ₀＋ｋ₁−１]の行が、位置ｎ₀から始まることに注意されたい。理由は、一方では層０の線形独立列の数を増すことであり、他方では符号化シンボルのユニーク識別子によって受信機でマトリックスの再生を許可することである。層０の符号化シンボルは、図８のプロセスの後に生成される。拡張層符号化シンボルを生成するために、両方の層のプリコーディングシンボルは、図８に記載されているＲａｐｔｏｒ符号化プロセスの次のステップに送られる。

ＬＡ−ＦＥＣ Ｒａｐｔｏｒプロセスの第２のステップは、図８（２層を有するＬＡ−ＦＥＣ ＬＴ符号化プロセス）に示される。第２のステップにおける符号化されたシンボルの生成は、Ｇ＿ＬＴ₀[ｎ₀：ｎ₀+ｎ₁−１]により層０のプリコーディングシンボルから拡張Ｇ＿ＬＴ₁[ｎ₀：ｎ₀+ｎ₁−１]マトリックスにまで及ぶ。層０のプリコードシンボルの追加の統合とともに、層１の符号化シンボルは、セクション「層認識のあるＦＥＣ 一般的アプローチ」の例における上記に模範となるように示されるようにジョイント復号化を行うため、層０の符号化シンボルとともに使用できる。

ＬＡ−ＦＥＣ拡張は、プリコード生成および［３］に記載されているＬＴ符号化のためにアルゴリズムを再利用する。「層０」の復号が成功した場合、ＬＡ−ＦＥＣ拡張による層全体に導入された接続は、もはや必要とされず、「層１」のＦＥＣプロセスにおける層０のプリコーディングシンボルをＸＯＲ演算することによって取り除き得る。このような場合、「層１」は、標準Ｒａｐｔｏｒ符号化プロセスの後に訂正でき、その最大訂正能力を可能にする。

ＬＡ−ＦＥＣの信号伝送：

送信システムにおけるＬＡ−ＦＥＣの使用は、ＬＡ−ＦＥＣ符号化と結合した多層アプローチをサポートするために特殊な信号伝送および転送技術を必要とする。リンクまたはアプリケーション層上のＬＡ−ＦＥＣ Ｒａｐｔｏｒ拡張の統合は、ＲＴＰ［６］上のリアルタイム伝送に適用されると見なされる。リアルタイムアプリケーションのために、ＲＴＰは、概して、その接続を持たないおよびそれが伝送における最小の遅延を許す信用できない性質のためにＵＤＰ［７］上で使用される。ＲＴＰは、メディア同期、伝送順序回復、多重化、ソース識別および受信状態フィードバック情報などの基本的な特徴を提供する。ＳＶＣのために、スケーラブルビデオコーディング［８］のためのＲＴＰペイロードフォーマットは、メディアペイロードパケット化およびＭＶＣ、マルチビュービデオ符号化［９］のためのＲＴＰペイロードフォーマットのために必要とされる。特に、ＳＶＣおよびＭＶＣのためのこれらのペイロードフォーマットは、層をなしたＳＶＣおよび多重化ＲＴＰセッションにおけるＭＶＣデータの伝送を定義する、そして、それは、伝送システムが伝送アドレス、例えば、ＩＰアドレス、ＵＤＰポートまたはＲＴＰパケットヘッダ（ＳＳＲＣ）の同期ソース識別子、に基づいてＬＡ−ＦＥＣ符号化プロセスを使用してＳＶＣ層およびＭＶＣ視点を簡単に区別するのを可能にする。セッション関連情報の信号伝送は、セッション記述プロトコル［１０］において定義される。同じコーデックの層または視点を含んでいるＲＴＰセッションの依存性を信号伝送するために、［１１］のＳＤＰ拡張が、必要とされる。

ＦＥＣ符号化データを伝送するために、ＩＥＴＦは、ＲＴＰにおいて使用もできる、ＦＥＣベースのコンテンツ配信プロトコルのための基本的な手段を定義している一般的なＦＥＣＦＲＡＭＥフレームワークを構築した。このフレームワークは、他の特徴のそばで複数のメディアおよび修理フローがどのように扱われるかについて定義し、そして更にペイロードパケット化情報の一部として、ソースシンボルに識別メカニズムを提供する。Ｒａｐｔｏｒコードを有するこのフレームワークを使用するために、［１２］が使用されることを目的とする。

このフレームワークをＬＡ−ＦＥＣに適用可能にするために、Ｒａｐｔｏｒ ＦＥＣスキーム［１３］およびＲａｐｔｏｒ ＲＴＰ ペイロードフォーマット［１４］が、修理フローをパケット化するために変更なしで使用し得る。Ｒａｐｔｏｒ ＦＥＣスキームのための信号伝送は、［１２］において定義される、そこでは、ＬＡ−ＦＥＣ基層保護およびＬＡ−ＦＥＣ拡張層保護のために必要であるとされるので、従属している修理フローの指示は、ＲＦＣ ６３６４［１５］においてすでに定義される。ＦＥＣフレームワークも追加ＦＥＣフローを特定する、そして、それがＬＡ−ＦＥＣ拡張層および基層ＦＥＣフローを有するケースであるように、それが誤り訂正のために共同で使用できる。ＳＤＰにおける追加フローのＦＥＣグループ分けのためのセマンティックスは、ＲＦＣ ５８８８［１７］に、メディア要素およびとりわけＦＥＣフレームワークのための一般グループ化は、ＲＦＣ ５９５６［１６］に記載されている。

ＲＦＣ ６３６４は、ＳＤＰの使用を特定するとともに、送信機および受信機の間にＦＥＣ フレームワークの信号伝送のために必要なパラメータを記述する。ＵＤＰフォーマット化された入力ストリームのために、プロトコル識別子は、『ＦＥＣ／ＵＤＰ』である。ＦＥＣ フレームワークは、ソースフローおよび修理フローを区別する。ソースＩＰアドレスは、属性『ソース−フィルタ』に記載されている。

複数のソースおよび修理フローのグループ化

ＦＥＣ フレームワークは、複数のソースおよび修理フローのグループ化を可能にする。この種のグループは、単一または複数のＦＥＣ フレームワークインスタンスによって保護されうる。ソースおよび修理フローの間の関連は、『グループ』属性によって示しうる。追加修理フローのための『グループ』属性の使用法に関する詳細は、ＲＦＣ ５９５６に記載されている。ＲＦＣ ５９５６の後に、１つの『グループ』属性に含まれるすべてのフローは、ＦＥＣグループと呼ばれている。１つ以上の修理フローが単一の『グループ』に存在する場合には、これらの修理フローは、付加的でなければならない。ＲＦＣ ５８８８は、『ＦＥＣ−ＦＥ』をＦＥＣフレームワークの使用のためのグループ化セマンティックスとして定義する。従って、『ａ＝ｇｒｏｕｐ：ＦＥＣ−ＦＲ』セマンティックスは、複数のフローを結びつけるために用いなければならない。

ＬＡ−ＦＥＣのための典型的なシナリオは、２つのソースフロー、Ｓ１（基層）およびＳ２（拡張層）および２つの修理フロー、Ｒ１（基層ＦＥＣ）およびＲ２（層認識のある基層および拡張層ＦＥＣ）を有する。この種のシナリオを記載することは、以下の例で示されるようなＳＤＰ内で２つのＦＥＣグループを特定することを要する：

a=group:ＦＥＣ−FR S1 R1
a=group:ＦＥＣ−FR S1 S2 R1 R2

すべての議論されたＲＦＣを結合している典型的なＳＤＰ記述は、以下（水平線は、ＳＤＰ記述内で異なるセクションを示す）に与えられる。

v=0
o=Cornelius 1122334455 1122334466 IN IP4 la−fec.example.com
s=SVC LA−FEC Raptor Example
t=0 0
a=group:FEC−FR S1 S2 R1 R2
a=group:FEC−FR S1 R1
c=IN IP4 233.252.0.1/127
a=group:DDP S1 S2
-----------------------------------------------
m=video 20000 RTP/AVP 96
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=fec−source−flow:id=0
a=mid:S1
-----------------------------------------------
m=video 20002 RTP/AVP 97
b=AS:64
a=framerate:15
a=rtpmap:97 H264-SVC/90000
a=fec-source-flow:id=1
a=mid:S2
a=depend:97 lay S1:97
-----------------------------------------------
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.3/127
a=fec−repair-flow:encoding−id=6;fssi=Kmax:8192,T:128,P:A
a=mid:R1
-----------------------------------------------
m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.4/127
a=fec−repair-flow:encoding−id=6;fssi=Kmax:8192,T:128,P:A
a=mid:R2

モバイルテレビチャンネルにおける典型的なシミュレーション結果:

図９Ａおよび９Ｂは、既存のリンク層−ＦＥＣ ＭＰＥ−ＦＥＣの置換として標準Ｒａｐｔｏｒコード（ＳＴ−ＦＥＣ）のＡＬ−ＦＥＣ実施態様およびＤＶＢ−Ｈにおける層認識のあるＲａｐｔｏｒ（ＬＡ−ＦＥＣ）を比較するモバイルテレビ（ＤＶＨ−Ｂ）チャンネルにおけるシミュレーションされた典型的な結果を示す。特に、２５０フレーム（図９Ａ）の静止画の平均枚数および１３００ｋｂｐｓの固定サービスビットレートのＳＶＣ層ＣＲ（基層／拡張層）全体にわたる様々な符号レート分布を有する標準（ＳＴ）−ＦＥＣおよびＬＡ−ＦＥＣを使用しているＶＧＡ受信機のための平均ＰＳＮＲ値（図９Ｂ）。ＳＴ−ＦＥＣについては、ＦＥＣデータは、各層のために他の層とは独立に生成される。ＬＡ−ＦＥＣについては、拡張層ＦＥＣデータは、基層のすべてのソースシンボル全体に発生する。これらの設定は、様々な符号レート分布および１３００ｋｂｐｓの固定トータルサービスビットレート（オーディオ、ビデオおよびＦＥＣを含む）でシミュレートされる。シミュレーションは、ソースシンボルｋ_lの層ｌ,ＣＲ＝ｋ／ｍの符号化されたシンボルｎ_lに対する比率によって算出されたＣＲを有するＣＲ＝０．６８の全ＦＥＣ符号レートを含む。層全体のＣＲ分布は、基層コードレートが第１の値であり、拡張層コードレートが第２の値であることを有する図の凡例において示される。上側の図は、２５０のフレームの伝送の全体にわたる静止画の枚数を示し、かつ、下側の図は、ＰＳＮＲに関する結果として生じる平均ビデオ品質を示す。下層のシミュレーション条件に関するより多くの詳細は、〔１〕で発見できる。

図から明らかなように、ＬＡ−Ｒａｐｔｏｒは、サービス連続性（静止画のより少ない枚数）および平均ビデオ品質（より高いＰＳＮＲ）に関して標準Ｒａｐｔｏｒスキームより優れている。これは、ＦＥＣ統合においてちょうど拡張層から基層まで追加の接続を加えることにより、サービスビットレートを増加させることなく実現する。

ＬＤＰＣコードを有する物理チャンネル上のＬＡ−ＦＥＣ：

このセクションは、ＬＡ−ＦＥＣがどのように物理層ＬＤＰＣコードに適用できるかについて示す。典型的なＦＥＣコードとして、我々は、ＤＶＢ−Ｓ２の物理層にＬＤＰＣコード１６ｋマトリックスを適用する。図１０は、基層（ＢＬ）のために使用される標準ＬＤＰＣマトリックスおよび拡張層（ＥＬ）符号化のために使用される拡張ＬＡ−ＦＥＣ ＬＤＰＣマトリックスを比較する。標準ＬＤＰＣマトリックスは、上部のマトリックスであり、かつ、拡張ＬＤＰＣマトリックスは、下部のマトリックスである。白の領域がゼロを含むのに対し、黒点はマトリックス中の１の位置を示す。

拡張層（ＥＬ）のために、標準ＬＤＰＣマトリックスは、単純な単位行列によって基層のソースシンボルに拡張される。これは、典型的な拡張を意味するだけである。より高度なマトリックス拡張を案出できる。ジョイント復号化マトリックス（拡張されたＬＡ−ＦＥＣ復号化マトリックス）は、図１１において表される。それは、ＢＬおよびＥＬのソースおよびパリティシンボルを１つの復号化マトリックスに組み込む。ＬＤＰＣコードを復号化するためのいかなる復号化アルゴリズムも、この拡張マトリックスを復号化するために使用し得る。

物理層ＬＤＰＣ符号のためのいくつかの典型的な結果は、ＡＷＧＮチャンネルにおける１６ｋのＬＡ−ＦＥＣ対（vs.）１６ｋのＳｔ−ＦＥＣのためのシミュレーション結果を示す図１２に示され、それ故、１６ｋのＬＤＰＣコードの標準ＦＥＣ（ｓｔＦＥＣ）を、ＡＷＧＮチャンネルにおける異なるＥｂＮｏ上にシミュレーションされる１６ｋのＬＤＰＣコード（ＬＡ−ＦＥＣ）のＬＡ−ＦＥＣ拡張と比較する。ＱＰＳＫが使用され、そして、等しいエラー保護を有する異なる符号レートが適用される。プロットは、基層および拡張層ＢＥＲ曲線を比較するとＳＴ−ＦＥＣ符号化（ＢＬ＋ＥＬとしての同じビットレート）のビット誤り率（ＢＥＲ）を示す。ＢＬパフォーマンスが増加することが分かる、その一方で、ＥＬパフォーマンスは、ＳＴ−ＦＥＣのような類似のパフォーマンスを示す。従来の同等でないエラー保護（ＵＥＰ）スキームについては、拡張層は、基層より保護されておらず、ＢＥＲ曲線は、拡張層パフォーマンスにおいて減少を示す。これは、ＬＡ−ＦＥＣスキームを有するケースおよび等しいエラー保護ではない。しかしながら、また、ＵＥＰは、ＬＡ−ＦＥＣに適用し得る。

時間インターリーブ：

時間インターリーブは、信号の時間多様性およびそれによりバースト誤りに対するロバスト性を増加させる重要な手段である。充分なインターリーブ長を伴って、サービスは、長いエラーバーストを克服し得る。典型的な時間インターリーブの主な障壁は、時間内のサービス同調またはザッピング時間の増加である。長時間のインターリーブは、受信機が、インターリーブ期間のすべてのパケットが受信されデインターリーブバッファに満たされるまで、待つことを要求する。すなわち、より長いインターリーブ長がサービスロバスト性を大幅に向上させるにもかかわらず、今日の伝送システムは、時間インターリーブ長を最小化しようとする。

ＦＥＣソースブロックの時間多様性は、ｋ₀ソースシンボルおよびｐ₀パリティシンボルおよびＩＬ＝（１，２，３）からなるｎ₀シンボルを有するＦＥＣソースブロック０（ＳＢ₀）のための図１３において表されるもののように、特定のインターリーブ長（ＩＬ）によって増加する。図１３は、ｋ₀ソースおよびｐ₀パリティシンボルおよび増加している時間多様性（ＩＬ＝１，２，３）を有するＦＥＣソースブロック０（ＳＢ₀）の異なるインターリーブ長（ＩＬ）を図式的に示す。

ソースブロックＳＢ₀のすべてのシンボルｎ₀＝４を回復するのに必要な時間は、シンボルに関してインターリーブ遅延ｄ_interlと呼ばれる。

ＲａｐｔｏｒＱ ＦＥＣへの層認識のあるＦＥＣ統合：

このセクションは、どのようにＬＡ−ＦＥＣがＲａｐｔｏｒＱ［２］ＦＥＣ符号に統合できるかについて示す。ＲａｐｔｏｒＱは、若干の更なる最適化によってパフォーマンスを増加させるＲａｐｔｏｒコード（セクション「Ｒａｐｔｏｒ ＦＥＣへの層認識のあるＦＥＣ統合」を参照）の進化版である。

ＲａｐｔｏｒＱプロセスは、〔２〕において特定され、Ｒａｐｔｏｒコードプロセス（セクション「Ｒａｐｔｏｒ ＦＥＣへの層認識のあるＦＥＣ統合」を参照）のような符号化および復号化のための同じ２つのステップで構成される。符号化プロセスが、符号化および復号化するための同じプロセスを有する方法において定義されることに注意されたい。第１のステップは、入力として一定サイズのソースシンボルｋ₀を取り込み、Ｌ₀プリコーディングシンボルを生成するプリコーディングプロセスである。ＲａｐｔｏｒＱは、ｋ₀のすべての値のために特定されるというわけではない。従って、ソースシンボルｋ₀の個数は、詰め物によって次に利用できるｋ₀´に増やされる。〔２〕において特定されたプリコーディングマトリックスは、図１４に示される。図１４は、層０または単層のために使用する〔２〕において特定されるようなＲａｐｔｏｒＱのプリコーディングマトリックスに関して図式的に示す。同様のプリコーディングマトリックスが復号化および符号化プロセスで用いられることに注意されたい。

プリコーディングマトリックスは、２つのＬＤＰＣサブマトリックス、Ｇ＿ＬＤＰＣ，１₀およびＧ＿ＬＤＰＣ，２₀、いわゆるＧ＿ＨＤＰＣ₀マトリックス、２つの単位行列Ｉ＿Ｓ₀およびＩ＿Ｈ₀およびｋ０´行を含むＧ＿ＥＮＣ₀マトリックスからなる。Ｇ＿ＥＮＣ₀が符号を組織的に保つことを必要とする一方、Ｇ＿ＬＤＰＣ，１₀，Ｇ＿ＬＤＰＣ，２₀，Ｇ＿ＨＤＰＣ₀，Ｉ＿Ｓ₀，Ｉ＿Ｈ₀は、ＲａｐｔｏｒＱプロセスの実際のプリコードを構成する。サブマトリックスの生成に関するさらなる詳細は、〔２〕で発見し得る。全てのプリコーディングマトリックスが、ソースシンボルｋ₀，ソースシンボルそれ自身，およびシンボルサイズＴの合計によって生成されることに注意されたい。

第２のステップは、図１５に示されるＲａｐｔｏｒＱのＬＴ符号化プロセスを構成する。図１５は、図式的に、ＲａｐｔｏｒＱのＬＴ符号化プロセスを図式的に示す。マトリックスＧ＿ＥＮＣ₀の中の密度分布が、Ｒａｐｔｏｒプロセス（セクション「Ｒａｐｔｏｒ ＦＥＣへの層認識のあるＦＥＣ統合」を参照）のＧ＿ＬＴ₀マトリックスと異なることに注意されたい。第２のステップは、第１のステップからＬ₀プリコーディングシンボルを取り込んで、プリコーディングシンボルの異なる組をＸＯＲ演算することによってｎ₀符号化シンボルを生成した。組は、疎行列であって、『０』および『１』からなるＧ＿ＥＮＣ₀マトリックスによって特定される。『１』は、その関連があるプリコーディングシンボルが関連した符号化シンボルのＸＯＲプロセスを含むことを意味する。

ＬＡ−ＦＥＣ ＲａｐｔｏｒＱのプリコーディングマトリックスは、２層のために図１６に示される、すなわち、図１６は、２層を有するＬＡ−ＦＥＣ ＲａｐｔｏｒＱのプリコーディングプロセスを図式的に示す。マトリックスは、２つの層（左上および右下）の２つのプリコーディングマトリックス、０マトリックス（右上）そして、層１から層０（左下）へのＬＡ−ＦＥＣ拡張、の連結からなる。ＬＡ−ＦＥＣ拡張は、コードを組織的に保つために要求される。Ｇ＿ＥＮＣ₁および関連した拡張Ｇ＿ＥＮＣ₀［ｎ₀：ｎ₀＋ｋ₁−１］の行が位置ｎ₀から始まることに注意されたい。その理由は、一方の側で層０の線形独立行の個数を増し、他方の側で符号化シンボルのユニーク識別子によって受信機でマトリックスの再生を可能にすることにある。層０の符号化シンボルは、図１５のプロセスに従って生成される。拡張層の符号化シンボルを生成するために、両方の層のプリコーディングシンボルは、図１７に示されたＲａｐｔｏｒＱ符号化プロセスの次のステップに転送される。図１７は、２つの層および層０のプリコーディングシンボルへの拡張マトリックスを有するＬＡ−ＦＥＣ ＲａｐｔｏｒＱ符号化プロセスの第２のステップを図式的に示す。

層１の符号化シンボルｎ₁は、層０および関連した符号化マトリックスＧ＿ＥＮＣ₀のプリコーディングシンボルを考慮している拡張符号化プロセスによって生成される。拡張Ｇ＿ＥＮＣ＝［Ｇ＿ＥＮＣ₀ Ｇ＿ＥＮＣ₁］マトリックスの第１のｋ₁行がプリコーディングステップに含まれるため、結果として生じる符号化シンボルは、組織的である。復号化プロセスが、ソースシンボルを受信シンボルに置き換え符号化シンボルをソースシンボルに置き換えること以外に関する同じステップを含む点に留意する必要がある。

不均一時間インターリーブ（ＬＡ−ＦＥＣ ＵＩ）を有するＬＡ−ＦＥＣ：

層認識のあるＦＥＣおよびＳＶＣおよびＭＶＣのような階層化メディアの組合せは、高速ザッピングおよび長時間インターリーブを結び付けるサービスの提供の新規な方法を可能にする。実施例は、特に、このセクションおよび次のセクションに記載されている不均一な時間インターリーブを有するＬＡ−ＦＥＣに関する。

高速ザッピングは、より低品質の基層および、バーストエラーを有するが低遅延に対して、低いロバスト性を有する短時間インターリーブによって与えられる。長時間インターリーブは、バースト損失を有するがより長い遅延に対して、より強いロバスト性を有するＳＶＣ拡張層によって提供される。しかしながら、拡張層は、基層全体の層認識のあるＦＥＣとともにＦＥＣ符号化されるため、基層も拡張層の改良された時間多様性から利益を受ける。

このスキームは、以下においてＬＡ−ＦＥＣまたはＬＡ−ＦＥＣ ＵＩを有する不均一時間インターリーブと呼ばれる。ＬＡ−ＦＥＣ ＵＩがＳＶＣまたは任意の他の種類の階層化メディアにも適用できるだけでなく、また、いかなる種類の時間同期データにも適用できる点に注意すべきことは、重要である。例えば、考えられるアプリケーションは、ＬＡ−ＦＥＣによって接続される短時間インターリーブを有するオーディオストリームおよび長時間インターリーブを提供するビデオストリームも有するべきであろう。図１８は、ＬＡ−ＦＥＣ ＵＩ（すなわち本願明細書において開示される教示に従う誤り訂正符号化のための方法）のプロセスを示して、説明に役立つ実例を与える。換言すれば、図１８は、送信機側を図式的に示す：ＬＡ−ＦＥＣ符号化を有する不均一時間インターリーブを有するＬＡ−ＦＥＣのプロセス、不均一時間インターリーブ、および同期のためのより短いインターリーブのパケットを遅延。

図１８は、送信機側上のＬＡ−ＦＥＣ ＵＩストリームを生成するための４つのステップを示す。

ＬＡ−ＦＥＣ ＵＩプロセスのステップ１（１）は、メディア符号化それ自体である。符号化ストリームは、例えばＳＶＣまたはＭＶＣによって、層０（第１のカテゴリーに属するペイロードデータ）の基層およびより高い層（第２のカテゴリー（そして、第３のカテゴリー、第４のカテゴリー・・・に可能な）に属するペイロードデータ）の関連した拡張層を有するｎメディア層を有する階層化メディアストリームでもあり得る。他の意味ある設定は、層０のオーディオストリームおよび層１の関連したビデオストリームを有し得る。図１８に描かれた上記実施例は、各々異なるビットレートを有する２つの層を示す。層ｋ_layer0＝１およびｋ_layer1＝２の異なるビットレートのため、各層の時間周期Δｔのビットストリームは、ｋソースシンボルに分割される。ソースシンボルは、実際の情報を含み、更なるＦＥＣ処理のための入力である。ステップ１（１）は、１つの／その（a/the）第１のカテゴリーに属するペイロードデータを受信するステップおよび１つの／その（a/the）第２のカテゴリーに属しているペイロードデータを受信するステップとみなし得る。

プロセスのステップ２（２）は、例えば、セクション「層認識のあるＦＥＣ」に記載されているような典型的なＲａｐｔｏｒコードに基づく、ＬＡ−ＦＥＣプロセスそのものである。図１８の説明は、ＦＥＣソースブロック（ＳＢ）（ペイロードデータ）および両方の層（すなわちペイロードデータおよび関連する誤り訂正データの第１および第２のカテゴリー）のパリティシンボルｐ（誤り訂正データ）を示す。実施例において、同じ符号レートは、ＣＲ＝ｋ／（ｋ＋ｐ）＝０．５を有する各層に適用される。また、不均一な符号レート分布が適用できる点に注意されたい。ＬＡ−ＦＥＣプロセスの後に、層０（第１のカテゴリーペイロードデータのための誤り訂正データ）の単一のパリティシンボルｐは、層０，ＳＢ₀，・・・，ＳＢ₃のソースブロックに含まれる層０のソースシンボル上の標準ＲａｐｔｏｒＱアルゴリズムとともに生成される。層１（第２のカテゴリーペイロードデータのための誤り訂正データ）のｐ＝２パリティシンボルは、層０のソースシンボル全体の拡張されたソースブロック上に生成される。ステップ２（２）は、第１のカテゴリーペイロードデータのための第１の誤り訂正データを決定するステップおよび第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定するステップとみなし得る。

ＬＡ−ＦＥＣ ＵＩプロセスのステップ３（３）は、不均一なインターリーブである、そして、それは、畳み込みインターリーバおよび層１のためのＩＬ₁＝４のインターリーブ長（実施例において、インターリーブ長は、ＦＥＣソースブロックの個数に対応する）および層０のためのＩＬ₀＝１を有するインターリーブでないことにより、図１８の実施例において表わされる。例えば、ブロックインターリーバのような他の任意の種類のインターリーバは、ＬＡ−ＦＥＣ ＵＩプロセスのために用いられ得ることに注意されたい。概説された実施例において、インターリーブプロセスは、固定サイズのＦＥＣシンボルに作用する。インターリーブプロセスが、例えば符号化ＦＥＣソースおよびパリティシンボルを含んでいるＵＤＰパケットのようなパケットレベル上に実行することも可能な点にここで注意することは、重要である。ステップ３（３）は、少なくとも第２の誤り訂正データ（層１パリティシンボル）および第２のカテゴリーペイロードデータ（層１シンボル）を互いにインターリーブするステップとみなし得る、そこでは、第１の誤り訂正データ（層０パリティシンボル（複数））および第１のカテゴリーペイロードデータ（層０シンボル）のインターリーブに関連する第１のインターリーブ長は、第２の誤り訂正データおよび第２のカテゴリーペイロードデータのインターリーブに関連する第２のインターリーブと異なる。図示の例において、第１のインターリーブ長は、１、すなわち第１の誤り訂正データおよび第１のカテゴリーペイロードデータのアクティブなインターリーブがこの例で実行されないことを意味するＩＬ₀＝１、である。しかしながら、一般に、少なくとも第１の誤り訂正データおよび第１のカテゴリーペイロードデータをインターリーブする追加ステップの間、第１の誤り訂正データは、第１のカテゴリーペイロードデータとインターリーブし得る。さらにまた、第１の誤り訂正データ、第１のカテゴリーペイロードデータ、第２の誤り訂正データおよび第２のカテゴリーペイロードデータは、統合インターリーブステップでインターリーブでき、そこでは、異なる第１および第２のインターリーブ長が使用される（このケースは、「少なくとも第２の誤り訂正データおよび第２のカテゴリーペイロードデータをインターリーブする」定式化によってもカバーされる）。

ＬＡ−ＦＥＣ ＵＩのステップ４（４）は、両方の層の同期のためのより短いインターリーブを有する層の遅延伝送を意味する。このように、誤り訂正符号化のための方法は、インターリーブされた第１の誤り訂正データおよび第１のカテゴリーペイロードデータの伝送を遅延させる追加ステップを含み得る。遅延長は、層０（第１のカテゴリー）のあるソースブロックのすべてのシンボルが受信されるときに、対応するソースブロックの層１（第２のカテゴリー）のすべてのシンボルも図１８に示されたように受信されるように設定されなければならない。シンボルの遅延長は、両方の層の実際のインターリーブ長および最高のビットレート（層１、すなわち第２のカテゴリー）を有する層のシンボルの個数に依存する。図１８の典型的なインターリーブを考慮して、同期の目的のための必要な遅延ｄは、ｄ＝（ＩＬ₁−ＩＬ₀）＊（ｋ₁＋ｐ₁）によって算出できる。

２つのビットストリームは、さらに、別々に伝送されるかまたは任意の種類の伝送チャンネルを通じて多重化される。実施例において、我々がリアルタイム伝送を考慮することに注意されたい、そこでは、両方の層は、特定の時間フレームおよびバースト抹消を有するチャンネルの伝送の範囲内において受信機で提示されることを要する。

対応する誤り訂正エンコーダは、第１のカテゴリー（第１のカテゴリーペイロードデータ）に属するペイロードデータおよび第２のカテゴリー（第２のカテゴリーペイロードデータ）に属するペイロードデータを受信するための、そして、第１のカテゴリーペイロードデータのための第１の誤り訂正データおよび第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定するための誤り訂正データ発生器を含み得る。誤り訂正エンコーダは、第２のカテゴリーに属するペイロードデータを受信するための、そして、第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定するための第２の誤り訂正データ発生器を更に含み得る。さらにまた、インターリーバは、少なくとも第２の誤り訂正データおよび第２のカテゴリーペイロードデータを互いにインターリーブするための誤り訂正エンコーダの一部でもよい、そこでは、第１の誤り訂正データおよび第１のカテゴリーペイロードデータのインターリーブに関連する第１のインターリーブ長は、第２の誤り訂正データおよび第２のカテゴリーペイロードデータのインターリーブに関連する第２のインターリーブ長と異なる。

本願明細書において開示される教示の実施例において、誤り訂正データ発生器は、第１の装置（すなわち第１の誤り訂正データ発生器）および第２の装置（すなわち第２の誤り訂正データ発生器）を含み得る。

図１９は、伝送内に典型的なバースト誤りを含んでいる実施例の受信機処理を示す。換言すれば、図１９は、受信機側を図式的に示す：デインターリーブを有する不均一な時間インターリーブを有するＬＡ−ＦＥＣプロセス、ＬＡ−ＦＥＣ復号化。

ステップ５（５）は、エラーを起こしやすいチャンネルの上のステップ（４）において発生するメディアストリームの伝送を示す。伝送は、両方の層に影響を及ぼすバースト誤りに影響される。与えられた実施例は、単に簡単のために抹消チャンネルにおいて概説される、そして、それはリンクまたはアプリケーション層（セクション「層認識のあるＦＥＣ」の注を参照）上の伝送エラーをシミュレートするために典型的に用いられる。しかしながら、同じプロセスは、エラーチャンネルにおいて適用もできる、そこでは、エラーの位置は、例えばセクション「ＬＤＰＣコードを有する物理チャンネル上のＬＡ−ＦＥＣ」に記載されているＬＡ−ＦＥＣ ＬＤＰＣコードを例えば使用するような受信機に知られていない。バースト誤りは、層０の４つのパケット（例えば４ビット／シンボル）および層１の８つのパケット（例えば８ビット／シンボル）の損失の原因となる、そこでは、消失したパケットの個数は、層の実際のビットレートに依存する。消失したパケットは、十字でマークされる。典型的な受信機が時間インスタンスｔ₀でメディアストリームに同調することが、仮定されている。受信機は、完全に受信されたシンボルまたはパケットを使用できるのみであることに注意されたい。同調がパケットの中央にある場合、受信機は、失われたヘッダのためパケットを理解することができなくて、それを廃棄するであろう。ヘッダが完全に受信された場合、パケットに関する全ての必要な情報が利用し得る。誤り訂正復号化方法において、ステップ５（５）は、第１のカテゴリーペイロードデータおよび第１の誤り訂正データを受信するステップとみなし得る。第１のカテゴリーペイロードデータは、インターリーブされたデータストリームにおける第１の誤り訂正データとインターリーブでき、そして、第１のカテゴリーペイロードデータおよび第１の誤り訂正データを受信するステップは、インターリーブされたデータストリームを受信することからなり得る。

ステップ６（６）は、受信されたメディアストリーム（すなわち、（少なくとも）第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームをデインターリーブしている）のデインターリーブを実行する。これは、受信機が各層ＩＬ₀およびＩＬ₁の実際のインターリーブ時間（インターリーブ長）を認識していることを要する。インターリーブ長は、バンド内において、または、バンド信号伝送の外から信号伝送し得る。

ステップ７（７）は、ＦＥＣ復号化を示す。すべてのパケットが伝送中に消失するため、層０の標準ＦＥＣは、ＳＢ₁およびＳＢ₂を訂正できない。ＬＡ−ＦＥＣコンセプトのため、拡張層（第２のカテゴリー）は、基層（第１のカテゴリー）を保護する、そして、より長時間のインターリーブのために、拡張層において失われた１つのパケットだけが存在する。すなわち、ＳＢ₁およびＳＢ₂の両方の層の訂正を可能にする式（２）および（３）を満足するために拡張層において受信された充分なパケットが存在する。換言すれば、ステップ７（７）は、少なくとも第１の誤り訂正データ、すなわち、第１の誤り訂正データおよび第２の誤り訂正データを使用して第１のカテゴリーペイロードデータにおける可能なエラーを訂正するステップに対応する。さらにまた、第２のカテゴリーペイロードデータは、少なくとも第２の誤り訂正データを使用して訂正される。第２のカテゴリーペイロードデータは、付加的な誤り訂正データ、例えば第３のカテゴリーペイロードデータ（例えば、層 ２、層 ３、・・・）に属する第３の誤り訂正データ、によって、更に保護し得る。基層のインターリーブと比較して拡張層のより長時間のインターリーブは、第１のカテゴリーペイロードデータおよび第１の誤り訂正データのインターリーブに関連する第１のインターリーブ長が、第２のカテゴリーペイロードデータおよび第２の誤り訂正データのインターリーブに関連する第２のインターリーブ長と異なることを意味する。

ステップ８（８）は、ＬＡ−ＦＥＣおよび不均一時間インターリーブの組合せによる、エラーを伴うことなく回復されたビデオストリームを示す。

誤り訂正デコーダは、デインターリーバおよび誤り訂正器から構成し得る。デインターリーバは、上記ステップ６（６）の一部またはすべての動作を実行するように構成し得る。誤り訂正器は、上記のステップ７（７）の一部またはすべての動作を実行するように構成し得る。特に、デインターリーバは、第２のカテゴリーに属するペイロードデータおよび対応する第２の誤り訂正データからなるインターリーブされたデータをデインターリーブするように構成し得る。インターリーブされたデータストリームは、第１のカテゴリーおよび対応する第１の誤り訂正データに属するペイロードデータから更に構成されることに注意されたい。

第１のカテゴリーペイロードデータおよび第１の誤り訂正データは、第２のカテゴリーペイロードデータおよび第２の誤り訂正データとともにインターリーブし得る。別の方法では、第１のカテゴリーペイロードデータおよび／または対応する第１の誤り訂正データは、第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームから、別々に供給し得る。さらに、第１のカテゴリーペイロードデータおよび第１の誤り訂正データは、実際のインターリーブ／デインターリーブ（インターリーブ長≠１）を必要とし得るかまたは実際のインターリーブ／デインターリーブ（インターリーブ長＝１）を必要とできない。換言すれば、（インターリーバ／デインターリーバによって）実際の（作動中の）インターリーブ／デインターリーブが実行されないときに、結果として生じるインターリーブ長は、１である。第１のインターリーブ長は、第１のカテゴリーペイロードデータおよび第１の誤り訂正データに関連している。第２のインターリーブ長は、第２のカテゴリーペイロードデータおよび第２の誤り訂正データに関連している。第１のインターリーブ長は、第２のインターリーブ長と異なる。

誤り訂正器は、第１のカテゴリーペイロードデータおよび第１の誤り訂正データを受信するように構成し得る。さらにまた、誤り訂正器は、デインターリーバからデインターリーブされた形の第２のカテゴリーペイロードデータおよび第２の誤り訂正データを受信するように構成し得る。第１のカテゴリーペイロードデータにおける可能なエラーは、少なくとも第１の誤り訂正データを使用している誤り訂正器によって訂正し得る。第２のカテゴリーペイロードデータにおける可能なエラーは、少なくとも第２の誤り訂正データを使用している誤り訂正器によって訂正し得る。

層認識のある前方誤り訂正（ＬＡ−ＦＥＣ）が実行されるときに、第１のカテゴリーペイロードデータ（例えば基層データ）における可能なエラーの訂正は、第２の誤り訂正データ（例えば拡張層の誤り訂正データ）はもちろん第１の誤り訂正データも使用し得る。上述したように、一般的に第２のカテゴリーペイロードデータの減少された誤り訂正能力の代償で、第１のペイロードデータの誤り訂正は、このようにより信頼性を高くし得る。この種の誤り訂正スキームは、第２のカテゴリーペイロードデータ（拡張層）が第１のカテゴリーペイロードデータ（基層）に依存するケースにおいて、特に使用し得る。

単層メディアおよびＦＥＣソースブロックのインターリーブを有する高速ザッピングおよび長時間インターリーブ：

類似の機構は、単層符号化に適用できる。図２０は、ＦＥＣソースブロックインターリーブのプロセスを示す。換言すれば、図２０は、高速同調中および長時間インターリーブのためのＦＥＣソースブロックインターリーブのプロセスを図式的に示す。

ステップ１（１）は、単層（層０）メディアストリームを示す。時間単位Δｔにつき、ｋソースシンボルが存在する。実施例において、ｋ＝２である。

ステップ２（２）は、ΔｔのＦＥＣソースブロック（ＳＢ_x）長およびｐパリティシンボルを有するＦＥＣ符号化を示す。実施例において、ｐ＝２である。ＦＥＣアルゴリズムは、例えばＬＤＰＣ、ＲａｐｔｏｒまたはＲａｐｔｏｒＱコードになり得る。

ステップ３（３）は、ＦＥＣソースブロックのインターリーブを示す、そこでは、インターリーブ長ＩＬ₀は、インターリーブされたＦＥＣソースブロックの個数を意味する。与えられた例において、ＩＬ₀＝３である。

ステップ４（４）は、典型的な同調時間ｔ₀および各ソースブロック（ＳＢ_x）の関連した同期位置（ＳＰ_x）を有する最終的な伝送スケジュールを示す。時間インスタンスｔ₀で同調する受信機は、ＳＰ₀において受信したビデオを開始し得る。この時点で、それはＳＢ₀の他のＦＥＣシンボルを受信しなかった、その結果、誤り訂正能力はこの時点で制限される。ＳＰ₁において、受信機は、１つの付加的なパリティシンボルを有するＳＢ₁を復号化し得る。ＳＰ₂の間、完全な訂正パフォーマンスおよび時間インターリーブ長が受信された。

対応する誤り訂正エンコーダは、ペイロードデータを受信して、ペイロードデータのための誤り訂正データを決定するための誤り訂正データ発生器；および、誤り訂正データおよびペイロードデータをインターリーブするためのインターリーバを含み得る。誤り訂正データは、インターリーブされたデータストリーム中のペイロードデータに先行する。ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異なる。ペイロードインターリーブ長の１つの可能な定義は、ペイロードインターリーブ長が、インターリーブされたデータストリームの対応するインターリーブされたデータブロックに挿入されている１つのペイロードデータブロックから、多くのペイロードデータ項目を記述する、ことである。同様に、誤り訂正データインターリーブ長は、先行するインターリーブされたデータブロックに挿入されている前記ペイロードデータブロックから生じている多くの誤り訂正データ項目を記述する。図２０の実施例において、ペイロードインターリーブ長は、１（すなわち、１つの与えられたソースブロックからのすべてのペイロードシンボルは、対応する伝送ブロックに含まれる）である。誤り訂正データインターリーブ長は、３（ＩＬ_{0,error correcting}＝３）である、なぜなら、あるソースブロックに属する少なくとも１つの誤り訂正シンボルは、対応するペイロードシンボルを含む伝送ブロックから間隔をおいて配置される３つの伝送ブロックである。例えば、ｔ₀から始まる伝送ブロックは、２つのペイロードシンボル「０」（白の正方形）を含む。対応する誤り訂正シンボル（灰色の正方形）は、ｔ_-1およびｔ_-2（図２０に明示されていない）で始まる２つの先行する伝送ブロックに含まれる。

随意に、前記ペイロードデータブロックからのすべてのペイロードデータ項目は、前記インターリーブされたデータブロックに挿入し得る、そして、対応する誤り訂正データ項目は、直接的に、または、間接的に前記インターリーブされたデータブロックに先行する少なくとも２つのインターリーブされたデータブロックに挿入し得る。

誤り訂正符号化のための対応する方法は、以下を含み得る：
−ペイロードデータを受信して、ペイロードデータのための誤り訂正データを決定する ；
−誤り訂正データおよびペイロードデータをインターリーブする、そこでは、誤り訂正 データは、インターリーブされたデータストリーム中のペイロードデータに先行する 、そして、ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異な る。

復号側（例えば受信機側）に関する限り、対応する誤り訂正デコーダは以下を含み得る：デインターリーバおよび誤り訂正器。デインターリーバは、ペイロードデータおよびｆｓペイロードデータのための誤り訂正データからなるインターリーブされたデータストリームをデインターリーブするために構成されている、そこでは、誤り訂正データは、インターリーブされたデータストリームにおけるペイロードデータに先行する、そして、ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異なる。誤り訂正器は、ペイロードデータおよび誤り訂正データを受信するために、そして、誤り訂正データを使用してペイロードデータにおける可能なエラーを訂正するために構成される、そこでは、ペイロードデータだけが受信され、かつ、誤り訂正データが失われた（例えば、誤り訂正データがもはや獲得し得ないような遅い同調による）ときに、ペイロードは利用し得るが、おそらく誤りである。

誤り訂正復号化のための対応する方法は、以下を含み得る：
−ペイロードデータおよびペイロードデータのための誤り訂正データからなるインター リーブされたデータストリームをデインターリーブする、そこでは、誤り訂正データ は、インターリーブされたデータストリーム中のペイロードデータに先行する、そし て、ペイロードインターリーブ長は、誤り訂正データインターリーブ長と異なる；
−ペイロードデータおよび誤り訂正データを受信する；および
−誤り訂正データを使用してペイロードデータにおける可能なエラーを訂正する、そこ では、ペイロードデータだけが受信され、かつ、誤り訂正データが失われたときに、 ペイロードは利用し得るが、おそらく誤りである。

この種の伝送スケジューリングについては、インターリーブ期間ＩＬ₀の後、同じ訂正パフォーマンスおよび時間多様性が達成される一方で、高速同調は可能である。この種の伝送スケジューリングは、ＬＡ−ＦＥＣなしで成し遂げられることもできて、受信機側上の高度なデインターリーブ機構も必要とする。

ＬＡ−ＦＥＣ ＵＩのためのパフォーマンス実施例：

シミュレーション結果は、固定バースト長をシミュレートするギルバート−エリオット（Gilbert-Elliot）モデルに基づいて実行される。我々は、９．５７シンボルの固定平均バースト長および抹消確率ｐ_erにより示される可変平均損失確率を仮定する。

ＳＶＣのようなシミュレーション（例えば７２０ｐ〜１０８０ｐの空間スケーラビリティ）：

表１は、選択された構成パラメータ上の概要を与える。ＳＶＣ符号化ビデオストリームおよび０．５の層につき固定の符号レートのために典型的であるので、この説明に役立つ実例は、１：２の層全体の特定のシンボル分布を仮定することに注意されたい。単層符号化と比較した更なる改良は、層全体の不均一符号レート分布によって成し遂げられ得る。

表１：メディアストリームおよびＦＥＣ符号化パラメータ：

単層の場合に関し特定の抹消確率ｐ_er上のＰＳＮＲ、各層（ＳＴ−ＦＥＣ）ごとに独立なＦＥＣ生成を有する標準ＦＥＣ、および様々なインターリーブ長をもつＬＡ−ＦＥＣ ＵＩに関する受信ビデオ品質が、図２１に示されており、基層の層復号化確率が、ＳＴ−ＦＥＣ ＵＩおよびＬＡ−ＦＥＣ ＵＩを有する基層復号化確率に関する違いを強調するために図２２に示されている。インターリーブ長ＩＬ＝９を有する単層のケースが、他のスキームのように時間内の同じ同調を提供せずに、単層のＦＥＣソースブロックインターリーブの潜在的パフォーマンスを意味するために含まれるだけであることに注意されたい。

図２１は、ＬＡ−ＦＥＣ、ＬＡ−ＦＥＣ ＵＩ、ＳＴ−ＦＥＣ、ＳＴ−ＦＥＣ ＵＩおよび単層（ＳＬ）符号化を有するＰＳＮＲに関して、ビデオ品質の比較を示す。２つの異なるインターリーブ長ＩＬ＝１（インターリーブでない）およびＩＬ＝９が、使用される。ＳＬ−ＩＬ＝１のみが、すべてのＬＡ−ＦＥＣ ＵＩスキームのように時間内の同じ同調を示すことに注意されたい。図２１における結果は、ＵＩなしでＬＡ−ＦＥＣ ＩＬ₀＝１；ＩＬ₁＝１が、ＳＴ−ＦＥＣスキームを上回って、ＳＬスキームに近づくことを示す。ＩＬ＝１パフォーマンス。ＬＡ−ＦＥＣ ＵＩ ＦＥＣ ＩＬ₀＝１；ＩＬ₁＝９は、遅延ＳＬ−ＩＬ＝１における同じ同調を提供する単層ＦＥＣ符号化を著しく上回る。ＬＡ−ＦＥＣ ＵＩは、単層ＩＬ＝９のパフォーマンスに達しない。すなわち、サービスへの速い同調を可能にしながら、ＬＡ−ＦＥＣ ＵＩスキームは、ＳＬ−ＩＬ１およびＳＬ−ＩＬ９の間にパフォーマンスを提供する。

図２２Ａおよび２２Ｂは、ＬＡ−ＦＥＣ、ＬＡ−ＦＥＣ ＵＩ、ＳＴ−ＦＥＣ、ＳＴ−ＦＥＣ ＵＩおよび単層（ＳＬ）符号化を復号化する基層および拡張層の比較を示す。２つの異なるインターリーブ長ＩＬ＝１（インターリーブではない）およびＩＬ＝９が、使用される。ＳＬ−ＩＬ＝１のみが、すべてのＬＡ−ＦＥＣ ＵＩスキームのような同じ同調時間を示すことに注意されたい。基層パフォーマンス上のＬＡ−ＦＥＣ ＵＩスキームは、２２（上部）に発見できる。拡張層のより長いインターリーブは、基層にいかなる影響を及ぼしもしないＳＴ−ＦＥＣ ＵＩに反して、ＬＡ−ＦＥＣについて、基層パフォーマンスは、増加する。全体としては、（ザッピング）時間の同じサービス同調を有するスキームと比較したとき、結果は、ＬＡ−ＦＥＣ ＵＩのパフォーマンスゲインを示す。更なるゲインは、層（ＵＥＰ）全体の符号レート分布の最適化によって、および、層全体のソースシンボル分布の他の比率によって期待される。

層０としてのオーディオストリームおよび層１としてのビデオストリームを持つＬＡ−ＦＥＣ ＵＩ：

提案されたＬＡ−ＦＥＣ ＵＩスキームが、例えばオーディオストリームの全域で単層ビデオに適用もできる点に注意すべきことは、重要である。これらのセクションは、層０のオーディオストリームおよび層１のビデオストリームを有することとともに若干のパフォーマンス結果を与える。

表２は、選択された構成パラメータ上の概観を与える。ビデオストリームと比較してオーディオ符号化ストリームのために現実的であり得るので、この説明に役立つ実施例が、１：８の２つの層全体の特定のシンボル分布と仮定されていることに注意されたい。さらにまた、０．５の層につき固定された符号レートが、仮定されている。単層符号化と比較した更なる改良は、層全体の不均一な符号レート分布によって達成され得る。

表２：メディアストリームおよびＦＥＣ符号化パラメータ：

図２３の結果は、１：８の層全体のビットレート比率を有する層０のオーディオストリームおよび層１のビデオストリームを有する設定を意味する。図は、１および８のインターリーブ長を有する単層（ＳＬ）と呼ばれる１つのＦＥＣソースブロック内に、オーディオおよびビデオの両方を有することに関するメディア復号化確率に関する比較を示す。換言すれば、図２３は、ＬＡ−ＦＥＣ ＵＩおよび単層（ＳＬ）符号化によるオーディオおよびビデオ層復号化の比較を示す。２つの異なるインターリーブ長ＩＬ＝１（インターリーブではない）およびＩＬ＝９が、使用される。すべてのＬＡ−ＦＥＣ ＵＩスキームのように、ＳＬ−ＩＬ＝１のみが時間内の同じ同調を示すことに注意されたい。

図２３の結果は、２つの層のビットレート間のより大きい違いについては、ＬＡ−ＦＥＣ ＵＩのゲインも増加することを示す。ＬＡ−ＦＥＣ ＵＩ ＶＩＤＥＯ符号化層が、ほとんどＳＬ設定のパフォーマンスに達する一方、オーディオストリームの小さなソースブロックは、エラーバーストチャンネルのより高いエラー領域において有益であるため、ＬＡ−ＦＥＣ ＵＩ オーディオストリームは、ＳＬストリームさえ上回る。

ＲａｐｔｏｒおよびＲａｐｔｏｒＱおよびＬＡ−ＦＥＣ ＵＩの信号伝送：

ＲａｐｔｏｒおよびＲａｐｔｏｒＱは、ソースシンボルｋ（バンド内の）およびＫｍａｘ（ＳＤＰ）、シンボルサイズＴ、各符号化されたシンボルＸ（ＩＥＴＦ ＦＥＣ ＦｒａｍｅｗｏｒｋにおけるＲａｐｔｏｒ ペイロード ＩＤに含まれる）のユニーク識別子、および受信機側（セクション「Ｒａｐｔｏｒ ＦＥＣへの層認識のあるＦＥＣ統合」およびセクション「ＲａｐｔｏｒＱ ＦＥＣへの層認識のあるＦＥＣ統合」を参照）でプリコーディングおよび符号化マトリックスを再生するための符号化ＩＤ（ＳＤＰ）およびＦＥＣ ＩＤ（帯域内）により、例えば定義される使用済みＦＥＣアルゴリズムの合計の帯域外もしくは帯域内信号伝送を要する。

ＬＡ−ＦＥＣは、拡張層シンボルの信号伝送を要する、そして、基層シンボルは、ジョイント復号化プロセス（セクション「ＬＡ−ＦＥＣの信号伝送」を参照）において使用できる。

受信機側でデインターリーブしているプロセスの効果的なメモリ管理のために、ＬＡ−ＦＥＣ ＵＩ ＲａｐｔｏｒまたはＲａｐｔｏｒＱは、さらに、全ての含まれる層のＦＥＣコード化されたシンボルのインターリーブ長（ＩＬ）の信号伝送（セクション「時間インターリーブ」を参照）を要する。

ＳＤＰ（セクション「ＬＡ−ＦＥＣの信号伝送」を参照）を使用している帯域信号伝送の典型的な出力は、潜在的な新しいパラメータ<<a:fec．インターリーブ：２００ｍｓ>>によって以下に示される

v=0
o=Cornelius 1122334455 1122334466 IN IP4 la−fec.example.com
s=SVC LA−FEC Raptor Example
t=0 0
a=group:FEC−FR S1 S2 R1 R2
a=group:FEC−FR S1 R1
c=IN IP4 233.252.0.1/127
a=group:DDP S1 S2
m=video 20000 RTP/AVP 96
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=fec−source−flow: id=0
a=mid:S1
m=video 20002 RTP/AVP 97
b=AS:64
a=framerate:15
a=rtpmap:97 H264−SVC/90000
a=fec−source−flow: id=1
a=mid:S2
a=depend:97 lay S1: 97
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.3/127
a=fec−repair−flow: encoding−id=6; fssi=Kmax:8192,T:128,P:A;
a=fec−interleaving: 200ms
a=mid:R1
m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.4/127
a=fec−repair−flow: encoding−id=6; fssi=Kmax:8192,T:128,P:A
a=fec−interleaving: 1000ms
a=mid:R2

他の可能性は、ソースシンボルｋの数を伴うインターリーブ長（ＩＬ）の典型的な帯域内信号伝送、ソースシンボルサイズＴ、ユニークなシンボル識別子（ＦＥＣ ＩＤ）および実際のソースブロックのインターリーブ長（ＩＬ）に関して図式的に示す図２４に記載されたようにパケットヘッダを有する帯域内信号伝送を行うことである。ＩＬ値は、ＳＤＰ実施例におけるａ＝ＦＥＣ−インターリーブパラメータに対応する。

最先端を越える進歩：

−不均一な時間インターリーブおよびＬＡ−ＦＥＣは、高速ザッピング（サービス同調 ）および長時間インターリーブをもたらす。短時間インターリーブを有する基層は、 高速同調を可能にする。拡張層は、ＬＡ−ＦＥＣのために基層を保護する長時間イン ターリーブを有する。
−サービスに同調する受信機は、最初に基層を復号化し始める。過渡期の後、それは、 拡張層を復号化し得る。ＬＡ−ＦＥＣのため、全部のサービスロバスト性は、拡張層 のより長い時間インターリーブによって増加する。
−両方の層の伝送スケジューリングは、基層と拡張層が不均一な時間インターリーブ長 と同期し続けるように基層伝送が遅延される方法でスケジュールされている。
−単層および階層化メディア符号化を有するＦＥＣソースブロックのインターリーブ
−受信機側での各層のＦＥＣソースブロックのインターリーブ長の信号伝送。
−ＬＡ−ＦＥＣは、いかなる同期データ、例えば単層およびその関連するオーディオス トリーム上の単層にも適用し得る。これは、既存のＬＡ−ＦＥＣ米国特許出願公開第２０１０／０１７６８６号明細書において考慮されていない。

いくつかの態様が、装置との関連で記載されていたにもかかわらず、これらの態様も対応する方法の説明を表すことは明らかである、そこでは、ブロックまたは装置は、方法ステップまたは方法ステップの特徴に対応する。同様に、方法ステップとの関連で記載されている態様も、対応する装置の対応するブロックまたは項目または特徴の説明を表す。方法ステップの一部または全部は、例えばマイクロプロセッサ、プログラム可能なコンピュータまたは電子回路などのハードウエア装置（を用いること）により実行し得る。いくつかの実施形態では、最も重要な方法ステップの一つまたはそれ以上のいくつかは、この種の装置によって実行し得る。

発明の符号化された／圧縮された信号は、ディジタル記憶媒体に保存でき、あるいは、例えばワイヤレス伝送媒体またはインターネットなどの有線の伝送媒体などの伝送媒体上に伝送し得る。

特定の実施要件により、本発明の実施例は、ハードウエアにおいて、または、ソフトウエアにおいて実施し得る。実施は、その上に格納される電子的に読み込み可能な制御信号を有するディジタル記憶媒体、例えばフロッピー（登録商標）ディスク、ＤＶＤ、ブルーレイ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリ、を使用して実行し得る、そして、それぞれの方法が実行されるように、それはプログラム可能なコンピュータシステムと協働する（または協働し得る）。従って、ディジタル記憶媒体は、計算機可読でもよい。

本発明によるいくつかの実施例は、電子的に読み込み可能な制御信号を有するデータ記憶媒体からなる、そしてそれは、本願明細書において記載されている方法のうちの１つが実行し得るように、プログラム可能なコンピュータシステムと協働し得る。

一般に、本発明の実施例は、プログラムコードを有するコンピュータプログラム製品として実施し得る、そして、コンピュータプログラム製品がコンピュータで動くときに、プログラムコードが方法のうちの１つを実行するために作動している。プログラムコードは、機械読み取り可能な担体に例えば格納し得る。

他の実施例は、本願明細書において記載されていて、機械読み取り可能な担体に格納される方法のうちの１つを実行するためのコンピュータプログラムからなる。

換言すれば、本発明の方法の実施例は、従って、コンピュータプログラムがコンピュータで動くとき、本願明細書において記載されている方法のうちの１つを実行するためのプログラムコードを有するコンピュータプログラムである。

本発明の方法の更なる実施例は、従って、その上に記録された、本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムを含むデータ担体（またはディジタル記憶媒体またはコンピュータ可読媒体）である。

本発明の方法の更なる実施例は、従って、本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムを表しているデータストリームまたは一連の信号である。データストリームまたは一連の信号は、データ通信接続、例えばインターネットを経て、転送されるように例えば構成し得る。

更なる実施例は、本願明細書において説明された方法の１つを実行するように構成されあるいは適合された処理手段、例えばコンピュータ、あるいはプログラム可能な論理装置を含む。

更なる実施例は、本願明細書において記載されていた方法の１つを実行するためのコンピュータプログラムをその上にインストールしているコンピュータを含む。

いくつかの実施形態では、プログラム可能な論理装置（例えばフィールドプログラム可能なゲートアレイ）は、本願明細書において記載されている方法の機能のいくつかまたは全てを実行するために用い得る。いくつかの実施形態では、フィールドプログラマブルゲートアレイは、本願明細書において記載されている方法の１つを実行するために、マイクロプロセッサと協働し得る。一般的に、方法は、いかなるハードウエア装置によっても好ましくは実行される。

上記した実施例は、本発明の原理のための、単なる実例である。改良および配置の変化および本願明細書において記載されている詳細は、他の当業者にとって明らかであるものと理解される。従って、最新の特許クレームの範囲のみによって制限され、そして、本願明細書および実施例の説明を通じて示される具体的な詳細だけによって制限されないことが、意図である。

参考文献
[1]A. Shokrollahi, "Raptor Codes," IEEE Transactions on Information Theor y, Vol. 52, Issue 6, pp. 2551-2567, 2006.
[2]M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder, "RaptorQ F orward Error Correction Scheme for Object Delivery," IETF RMT, draft-ietf-rm t-bb-fec-raptorq-04, August 2010, http://tools.ietf.org/html/draft-ietf-rmt- bb-fec-raptorq-04.
[3]M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery," IETF RFC 5053, Internet Engineering Task Force (IETF), Network Working Group, September 2007, http://tools.ietf .org/html/rfc5053.
[4]C. Hellge, T. Schierl, and T. Wiegand, "Mobile TV using scalable video vo ding and layer-aware forward error correction," IEEE International Conferenc e on Multimedia and Expo (ICME'08), Hanover, Germany, June 2008.
[5]Cornelius Hellge, David Gomez-Barquero, Thomas Schierl, and Thomas Wiegan d:
Layer-Aware Forward Error Correction for Mobile Broadcast of Layered Media,
IEEE Transactions on Multimedia, vol. 13, pp. 551-562, 2011.
[6]H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transpo rt Protocol for Real-time Applications", IETF STD 0064, RFC 3550, July 2003, http://tools.ietf.org/html/rfc3550.
[7]J. Postel, "User Datagram Protocol", IETF STD 6, RFC 768, September 1981, http://tools.ietf.org/html/rfc768.
[8]S. Wenger, Y.-K. Wang, T. Schierl, and A. Eleftheriadis, "RTP payload for mat for SVC video", IETF AVT, RFC 6190, May 2011, http://tools.ietf.org/html /rfc6190.
[9]Y.-K. Wang, T. Schierl, "RTP Payload Format for MVC Video," work in progr ess, IETF AVT, draft-ietf-payload-rtp-mvc-01.txt, September 2011, http://too ls.ietf.org/html/draft-ietf-payload-rtp-mvc-01.
[10]M. Handly, V. Jacobson, and C. Perkins, "SDP: Session Description Protoc ol", IETF RFC 4566, July 2006, http://tools.ietf.org/html/rfc4566.
[11]T. Schierl and S. Wenger, "Signaling media decoding dependency in Sessio n Description Protocol (SDP)," IETF MMUSIC, April 2009, http://tools.ietf.or g/html/rfc5583.
[12]M. Watson, A. Begen, V. Roca, "Forward Error Correction (FEC) Framework, " IETF FECFRAME, RFC 6363, October 2011.
[13]M. Watson, T. Stockhammer, M. Luby, "Raptor FEC Schemes for FECFRAME, " IETF FECFRAME, draft-ietf-fecframe-raptor-05, September 2011, http://tools.i etf.org/html/draft-ietf-fecframe-raptor-05.
[14]M. Watson, T. Stockhammer, "RTP Payload Format for Raptor FEC", IETF FEC FRAME, draft-ietf-fecframe-rtp-raptor-05, October 2011, http://tools.ietf.or g/html/draft-ietf-fecframe-rtp-raptor-05.
[15]A. Begen, "Session Description Protocol Elements for the Forward Error C orrection (FEC) Framework", IETF FECFRAME, RFC 6364, October 2011, http://to ols.ietf.org/html/rfc6364.
[16]A. Begen, "Forward Error Correction Grouping Semantics in the Session De scription Protocol", IETF FECFRAME, RFC 5956, September 2010, http://tools.i etf.org/html/rfc5956.
[17]G. Camarillo, H. Schulzrinne, "The Session Description Protocol (SDP) Gr ouping Framework," IETF MMUSIC, RFC 5888, June 2010, http://tools.ietf.org/h tml/rfc5888.
[18]Patent Application LA-FEC (Publication No. US 2010/017686 A1)

Claims (18)

1. 第１のカテゴリー（第１のカテゴリーペイロードデータ）に属するペイロードデータを受信し、第２のカテゴリーに属するペイロードデータを受信し、前記第１のカテゴリーペイロードデータのための第１の誤り訂正データを決定し、前記第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定するための誤り訂正データ発生器と、
   少なくとも前記第２の誤り訂正データおよび前記第２のカテゴリーペイロードデータを互いにインターリーブするためのインターリーバとを備え、
   前記第１の誤り訂正データおよび前記第１のカテゴリーペイロードデータのインターリーブに関する第１のインターリーブ長は、前記第２の誤り訂正データおよび前記第２のカテゴリーペイロードデータのインターリーブに関する第２のインターリーブ長と異なり、
   前記第１のカテゴリーペイロードデータは、基層に対応し、かつ、前記第２のカテゴリーペイロードデータは、スケーラブルビデオ符号化（ＳＶＣ）またはマルチビュービデオ符号化（ＭＶＣ）スキームの拡張層に対応し、
   前記第１のカテゴリーペイロードデータのデコーダ側の誤り訂正が前記第１の誤り訂正データおよび前記第２の誤り訂正データを使用できるように、前記誤り訂正データ発生器は、更に前記第１のカテゴリーペイロードデータを受信して、前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータに基いて前記第２の誤り訂正データを決定するように構成され、これにより、前記第１の誤り訂正データのみを使用することと比較して前記第１のカテゴリーペイロードデータのための誤り訂正パフォーマンスを改善し、
   前記第１のカテゴリーの特定のソースブロックの全てのシンボルが受信されたときに、対応するソースブロックの前記第２のカテゴリーの全てのソースシンボルも受信されるように、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データを遅延させるための遅延素子をさらに備えたこと、
   を特徴とする誤り訂正エンコーダ。
2. 前記第１のカテゴリーペイロードデータが、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データからなるインターリーブされたデータストリームの比較的短い部分から再構成できるように、前記第１のインターリーブ長は前記第２のインターリーブ長と異なり、かつ、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データが、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データからなる前記インターリーブされたデータストリームの比較的短い部分に影響を及ぼしている一つまたはそれ以上のデータエラーに関して比較的強いように、前記第２のカテゴリーペイロードデータは、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データからなる前記インターリーブされたデータストリームまたは他のインターリーブされたデータストリームの比較的長い部分から再構成できること、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
3. 前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータは、依存関係を介して相互に関係づけられていること、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
4. 前記第１のカテゴリーペイロードデータは、ペイロード内容の多重記述符号化（ＭＤＣ）の第１の記述の一部であり、前記第２のカテゴリーペイロードデータは、前記ペイロード内容の前記多重記述符号化の第２の記述の一部であること、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
5. 前記誤り訂正データ発生器は、層認識のある前方誤り訂正（ＬＡ−ＦＥＣ）を実行するために設定されること、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
6. 少なくとも前記第１のカテゴリーペイロードデータ、前記第１の誤り訂正データ、前記第２のカテゴリーペイロードデータ、および前記第２の誤り訂正データを多重化し、多重化データストリームを形成するためのマルチプレクサをさらに備えたこと、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
7. デコーダ側へ前記第１のインターリーブ長および前記第２のインターリーブ長の少なくとも一方に関するインターリーブ長情報を送信するための信号伝送要素をさらに備えたこと、
   を特徴とする請求項１に記載の誤り訂正エンコーダ。
8. 第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームをデインターリーブするためのデインターリーバと、
   前記デインターリーバからのデインターリーブされた形式における第１のカテゴリーペイロードデータ、第１の誤り訂正データ、前記第２のカテゴリーペイロードデータ、および前記第２の誤り訂正データを受信し、少なくとも前記第１の誤り訂正データを使用して前記第１のカテゴリーペイロードデータにおける可能なエラーを訂正し、かつ少なくとも前記第２の誤り訂正データを使用して前記第２のカテゴリーペイロードデータにおける可能なエラーを訂正するための誤り訂正器とを備え、
   前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データのインターリーブに関する第１のインターリーブ長は、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データのインターリーブに関する第２のインターリーブ長と異なり、
   前記第１のカテゴリーペイロードデータは、基層に対応し、かつ、前記第２のカテゴリーペイロードデータは、スケーラブルビデオ符号化（ＳＶＣ）またはマルチビュービデオ符号化（ＭＶＣ）スキームの拡張層に対応し、かつ、
   前記誤り訂正器は、前記第１のカテゴリーペイロードデータにおける前記可能な単数のエラーまたは前記可能な複数のエラーを訂正するために前記第２の誤り訂正データを使用するように構成されており、エンコーダ側の誤り訂正符号化が前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータに基いて前記第２の誤り訂正データを決定し、かつ、前記第１のカテゴリーの特定のソースブロックの全てのシンボルが受信されたとき、ソースブロックに対応する前記第２のカテゴリーの全てのソースシンボルも受信されるように、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データは、遅延されること、
   を特徴とする誤り訂正デコーダ。
9. 前記第１のカテゴリーペイロードデータが、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データからなるインターリーブされたデータストリームの比較的短い部分から再構成できるように、前記第１のインターリーブ長は、前記第２のインターリーブ長と異なり、かつ、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データは、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データからなる前記インターリーブされたデータストリームの比較的短い部分に影響を及ぼしているエラーに関して比較的強いように、前記第２のカテゴリーペイロードデータは、前記インターリーブされたデータストリームの比較的長い部分または前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データからなるインターリーブされたデータストリームから再構成できること、
   を特徴とする請求項８に記載の誤り訂正デコーダ。
10. 前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータは、依存関係を介して相互に関係づけられること、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
11. 前記第１のカテゴリーペイロードデータは、ペイロード内容の多重記述符号化（ＭＤＣ）の第１の記述の一部であり、かつ、前記第２のカテゴリーペイロードデータは、前記ペイロード内容の前記多重記述符号化の第２の記述の一部であること、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
12. 前記第１のカテゴリーペイロードデータは、オーディオデータからなり、かつ、前記第２のカテゴリーペイロードデータは、ビデオデータからなること、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
13. 前記誤り訂正器は、層認識のある前方誤り訂正（ＬＡ−ＦＥＣ）を実行するように構成されていること、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
14. 前記第１のカテゴリーペイロードデータ、前記第１の誤り訂正データ、前記インターリーブされた第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなる多重化データストリームをデマルチプレックスするためのデマルチプレクサ、をさらに備えたこと、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
15. エンコーダ側からの前記第１のインターリーブ長および前記第２のインターリーブ長の少なくとも１つに関するインターリーブ長情報を受信するための信号伝送要素をさらに備えたこと、
    を特徴とする請求項８に記載の誤り訂正デコーダ。
16. 第１のカテゴリーに属するペイロードデータを受信すること、
    第２のカテゴリーに属するペイロードデータを受信すること、
    前記第１のカテゴリーペイロードデータのための第１の誤り訂正データを決定すること、
    前記第２のカテゴリーペイロードデータのための第２の誤り訂正データを決定すること、および、
    少なくとも前記第２の誤り訂正データおよび前記第２のカテゴリーペイロードデータを互いにインターリーブすることを含み、
    前記第１の誤り訂正データおよび前記第１のカテゴリーペイロードデータのインターリーブに関する第１のインターリーブ長は、前記第２の誤り訂正データおよび前記第２のカテゴリーペイロードデータのインターリーブに関する第２のインターリーブ長と異なり、
    前記第１のカテゴリーペイロードデータは、基層に対応し、前記第２のカテゴリーペイロードデータは、スケーラブルビデオ符号化（ＳＶＣ）またはマルチビュービデオ符号化（ＭＶＣ）スキームの拡張層に対応し、
    前記第１のカテゴリーペイロードデータのデコーダ側の誤り訂正が前記第１の誤り訂正データおよび前記第２の誤り訂正データを使用できるように、前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータに基いて前記第２の誤り訂正データが決定され、前記第１の誤り訂正データのみを使用することと比較し第１のカテゴリーペイロードデータのための誤り訂正パフォーマンスを高め、かつ、
    前記第１のカテゴリーの特定のソースブロックの全てのシンボルが受信されたときに、対応するソースブロックの前記第２のカテゴリーの全てのソースシンボルも受信されるように、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データは、遅延されること、
    を特徴とする誤り訂正符号化方法。
17. 第２のカテゴリーペイロードデータおよび第２の誤り訂正データからなるインターリーブされたデータストリームを受信すること、
    前記インターリーブされたデータストリームをデインターリーブすること、
    第１のカテゴリーペイロードデータおよび第１の誤り訂正データを受信するかまたは獲得すること、
    少なくとも前記第１の誤り訂正データを使用して前記第１のカテゴリーペイロードデータにおける可能なエラーを訂正すること、および、
    少なくとも前記第２の誤り訂正データを使用して前記第２のカテゴリーペイロードデータにおける可能なエラーを訂正することを含み、
    前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データのインターリーブに関する第１のインターリーブ長が、前記第２のカテゴリーペイロードデータおよび前記第２の誤り訂正データのインターリーブに関する第２のインターリーブ長と異なり、
    前記第１のカテゴリーペイロードデータは、基層に対応し、前記第２のカテゴリーペイロードデータは、スケーラブルビデオ符号化（ＳＶＣ）またはマルチビュービデオ符号化（ＭＶＣ）スキームの拡張層に対応し、かつ、
    前記第２の誤り訂正データは、前記第１のカテゴリーペイロードデータにおける前記可能な単数のエラーまたは前記可能な複数のエラーを訂正するために使用され、エンコーダ側の誤り訂正符号化は、前記第１のカテゴリーペイロードデータおよび前記第２のカテゴリーペイロードデータに基づく前記第２の誤り訂正データを決定し、かつ、前記第１のカテゴリーの特定のソースブロックの全てのシンボルが受信されたときに、対応するソースブロックの前記第２のカテゴリーの全てのソースシンボルも受信されるように、前記第１のカテゴリーペイロードデータおよび前記第１の誤り訂正データは、遅延されること、
    を特徴とする誤り訂正復号化方法。
18. 請求項１６または１７に記載の方法をコンピュータ上で実行するとき、実行するためのプログラムコードを有するコンピュータプログラムをコンピュータ上に格納している計算機可読のディジタル記憶媒体。