JP5642183B2 - アクセスユニットストリームのための送信構想 - Google Patents

Description

本発明は、例えばビデオ、オーディオ、テキストまたはその他データ、アクセスユニットなどの、メディアのストリームなどのアクセスユニットストリームの送信、あるいは、送信のための前処理に関する。いくつかの実施形態では、その送信は、オーディオ放送信号（例えばＤＲＭ）によるビデオアクセスユニットの送信に関与する。

ビデオおよびオーディオデータのような特定の種類のデータの送信を特に専用とする多くの送信可能性がそれぞれある。例えば、ＤＶＢ―Ｔは、ビデオデータをブロードキャストするように設計された。ＤＲＭもまた、オーディオコンテンツを介して、例えば、海外で生活している国民に、母国で起こっていることについて情報を提供し、更新するために、広い地理的領域に点在したオーディエンスに到達するように設計された。考慮される送信可能性が何であれ、これらの送信可能性の設計パラメータ、例えば有用なデータのための最大帯域幅、サポートされているチャンネル又はプログラムの数、サポートされたチャンネル又はプログラムの中の帯域幅分布を調整することに関する性能などは、各送信可能性が設計されたデータの特定の形式によってもたらされた要求に合うように構成される。例えば、オーディオコンテンツは、ビデオコンテンツより小さい帯域幅を必要とする。さらに、許容誤差が異なる。送信可能性のいくつかは、それ自体で、限られた帯域幅能力を有する物理層による送信専用である。ＤＲＭは、例えば、最初は、より大きな放送距離を可能とする帯域において送信されるように設計されたが、そこから結果として生じる限られた帯域幅能力を受け入れた。

今までに利用できる送信可能性に基づいて、例えば帯域幅に関して、例えば、この種のアクセスユニットストリームを送信するように設計されていなかったいくつかの現存の送信可能性によって、アクセスユニットストリームの送信を可能にする送信構想または送信前処理構想が必要である。例えば、ＤＲＭ構造の範囲内などの送信可能性の範囲内でビデオ送信サービスを供給することを試みることを考える。ビデオコンテンツのニーズを考慮して、相当なバースト・ピッチでバーストを使用するときに、ＤＲＭは比較的低い帯域幅で有用なデータを送信する。こうした状況では、１つのプログラムから前述したビデオコンテンツへ切り換わるときに、相当な時間遅れが結果として生じるであろうし、その間、復号側で、復号器がビデオコンテンツに、同期する能力を有さないだろう。

従って、基礎をなす送信可能性または層を介して、アクセスユニットストリームの低い帯域幅送信および瞬時の同期を可能にしている送信構想または送信前処理構想を供給することが、本発明の目的である。

この目的は、請求項１に記載のアクセスユニットストリームを前処理するための装置、請求項２６に記載のアクセスユニットストリームを再生するための装置、請求項４５に記載のアクセスユニットストリームを前処理するための方法、請求項４６に記載のアクセスユニットストリームを再生するための方法、請求項４７に記載の送信信号、および、請求項４８に記載のコンピュータ・プログラムによって達成される。

本発明は、送信信号による送信のための、メディアコンテンツを示している、連続したアクセスユニットのアクセスユニットストリームを前処理するための装置であって、連続したアクセスユニットを、論理フレームのシーケンスの論理フレームの有用なデータセクションに連続して挿入すること、および、アクセスユニットの開始部分が含まれる各論理フレームに、アクセスユニットが各論理フレームに含まれる開始部分ごとに、そこを指し示しているポインタを含んでいるアクセスユニットテーブルを供給することによって、アクセスユニットストリームから論理フレームのシーケンスを生成するように構成された装置を供給する。

アクセスユニットの開始部分が含まれる各論理フレームが、各論理フレームに含まれるアクセスユニットの開始部分ごとに、そこを指し示しているポインタを含んでいるアクセスユニットテーブルを供給されるので、送信信号および論理フレームのシーケンスをそれぞれ受信している復号器は、ポインタを使用することにより、できるだけ早く論理フレームのアクセスユニットを見つけ、アクセスすることが可能である。

したがって、本発明の実施形態によれば、有用なデータセクションを含んでいる各論理フレームを有する、送信信号の論理フレームのシーケンスから、メディアコンテンツを示している、連続したアクセスユニットのアクセスユニットストリームを再生する装置が供給される。連続したアクセスユニットは、論理フレームのシーケンスの有用なデータセクションに連続して挿入され、その再生装置は、アクセスユニットの開始部分が含まれる所定の論理フレームに関して、その所定の論理フレームにアクセスユニットが含まれているアクセスユニットが存在するごとに、その所定の論理フレーム内の各開始部分の位置を指し示しているポインタを含んでいるその所定の論理フレームからアクセスユニットテーブルを抽出し、各ポインタの使用によって、所定の論理フレームに開始部分が含まれる各アクセスユニットを見つけ、その抽出を開始するように構成される。そして、その装置はまた、論理フレームのシーケンスの論理フレームの有用なデータセクションから、アクセスユニットストリームの連続したアクセスユニットを連続して抽出するようにも構成される。

好適な実施態様は、同封の従属クレームの対象である。

特に、本願の好ましい実施形態は、図に関して後述される。

図１は、本発明の実施形態に基づいた、論理フレームのシーケンスおよび論理フレームの構造へのアクセスユニットストリームの挿入を示している概略図を示す。 図２は、一実施形態に基づいた、送信チェーンのブロック図を示す。 図３は、一実施形態に基づいた、受信チェーンのブロック図を示す。 図４は、一実施形態に基づいた、図２のアクセスユニットストリーム前処理器によって実行されたアクセスユニットストリーム前処理のフローチャートを示す。 図５は、一実施形態に基づいた、論理フレームの構造を示している概略図を示す。 図６は、一実施形態に基づいた、仮想インターリービング方法を視覚化している概略図を示す。 図７ａは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｂは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｃは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｄは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｅは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｆは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｇは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｈは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｉは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｊは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｋは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｌは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図７ｍは、一実施形態に基づいた、図３のアクセスユニットストリーム再生機の動作モードを示しているフローチャートを示す。 図８は、ＦＥＣと関連して図３のアクセスユニットストリーム再生機の動作モードのための他の実施形態のフローチャートを示す。 図９は、ＦＥＣを実行した後の、または、ＦＥＣなしの、図３のアクセスユニットストリーム再生機の範囲内で動作モードを示しているフローチャートを示す。

最初に、図１および図２に関して、送信信号による送信のために、メディアコンテンツを示している、連続したアクセスユニットのアクセスユニットストリームの前処理のための実施形態が説明される。図２は、連続したアクセスユニットのアクセスユニットストリーム１４を生成するように構成されたアクセスユニットストリーム生成器１２を含んでいる送信器または送信チェーン１０を示しており、そのアクセスユニットストリーム１４は、例えばビデオコンテンツ又はビデオ及びオーディオコンテンツ又はニュースなどの時間で整列配置されたテキスト又はデータコンテンツなどのメディアコンテンツを示している。

アクセスユニットストリーム生成器１２は、ビデオ符号器、オーディオ符号器、および／または、テキストコンテンツ生成器などを含むことができ、または、いくつかの外部源からＡＵ（アクセスユニット）を受けることさえできる。したがって、アクセスユニットストリーム１４は、実際、一つ以上の別々のサブストリームで構成されており、同じ表示時間に関係している個々のサブストリームのアクセスユニットが、できるだけ近くにあるように、または、換言すれば、即時に、または、ある所定の最大タイムリミットの範囲内で、 アクセスユニットストリーム１４において互いに続くようにまとめられるように、その別々のサブストリームのアクセスユニットはインターリーブされた形式でアクセスユニットストリーム１４内に配列されている。

更に、図２の送信チェーン１０は、送信信号による送信のための連続したアクセスユニットのアクセスユニットストリーム１４を前処理するように構成されたアクセスユニットストリーム前処理器１６を含む。このために、アクセスユニットストリーム前処理器１６は、論理フレームのシーケンスの論理フレームの有用なデータセクションに連続したアクセスユニットを連続して挿入すること、および、アクセスユニットの開始部分が含まれる各論理フレームに、各論理フレームに含まれるアクセスユニットの開始部分ごとに、そこを指し示しているポインタを含んでいるアクセスユニットテーブルを供給することによって、アクセスユニットストリーム１４から論理フレームのシーケンス１８を生成するように構成される。図１は、例えば、例として４つのアクセスユニットＡＵ１〜ＡＵ４と、例として論理フレームＬＦ１、ＬＦ２およびＬＦ３を含んでいる論理フレームのシーケンス１８の対応する部分を含んでいるアクセスユニットストリーム１４の例となる部分を示す。図１に示すように、アクセスユニットストリーム前処理器１６は、各論理フレーム２０が論理フレームヘッダ２２および有用なデータセクション２４を含むように、構成されうる。後に詳しく述べるように、図１において表される論理フレームＬＦ１〜ＬＦ３がこのように図示されてはいるが、論理フレーム２０は一定の長さであることを必要としない。

図１の点線２６は、論理フレーム２０のシーケンス１８の有用なデータセクション２４へのアクセスユニット２８の連続した挿入を示す。図１から明白であるように、アクセスユニットストリーム前処理器１６は、アクセスユニット２８のいくつかの開始部分３２が実際に含まれるそれらの論理フレーム２０だけに、アクセスユニットテーブル３０を供給するように構成されうる。論理フレームＬＦ１〜ＬＦ３の中では、論理フレーム２０が、この種の論理フレームＬＦ１およびＬＦ３であって、一方、論理フレームＬＦ２は、アクセスユニット２４の開始部分を含まず、したがって、アクセスユニットテーブルを含まない。

更に、図１に示すように、アクセスユニットストリーム前処理器１６は、加えて、任意の論理フレームヘッダ２２が、その論理フレームヘッダ２２が属する各論理フレームの前端に、それらの前端に関して位置合わせされるように構成されうる。図１に示されるように、論理フレームヘッダ２２は、一定のサイズでもよい、すなわち、そのサイズは、論理フレーム２０の間で互いに等しくてもよい。しかし、アクセスユニットテーブル３０についていえば、アクセスユニットストリーム前処理器１６は、図１に示すように、それらの後端に、各アクセスユニットテーブル３０が属する各論理フレームの後端に、または、代わりに、各アクセスユニットテーブル３０が属する各論理フレームの前端に、アクセスユニットテーブル３０を位置合わせするように構成されうる（すなわち、前方又は後方挿入）。アクセスユニットテーブル３０は、その開始部分３２が各論理フレーム２０に含まれるアクセスユニット２０の数に応じて、変動するサイズ又は長さ３４を有しうる。例えば、論理フレームＬＦ１およびＬＦ３を比較すると、２つのアクセスユニットＡＵ３およびＡＵ４は、論理フレームＬＦ３の有用なデータセクション２４の中に配置された各開始部分３２を有するのに対して、ただ一つのアクセスユニット、すなわち、アクセスユニットＡＵ２だけが、論理フレームＬＦ１の有用なデータセクションの中に配置された開始部分３２を有し、その結果、論理フレームＬＦ１のアクセスユニットテーブル３４が論理フレームＬＦ３のアクセスユニットテーブル３０の長さ３４より小さい長さ３４を有する。

アクセスユニットストリーム前処理器１６が、このように、論理フレームヘッダ２２およびアクセスユニットテーブル３０を論理フレーム２０の前端および後端の別々の端に配置するように構成される場合、有用なデータセクション２４は、アクセスユニット２８の開始部分３２が含まれる論理フレーム２０に関して、論理フレームヘッダ２２およびアクセスユニットテーブル３０との間に、そして、アクセスユニット２８の開始部分３２が含まれない論理フレームに関して、論理フレームヘッダ２２および各論理フレームの反対の端との間に、配置される。

図２の送信チェーン１０は、更に、任意選択で、論理フレーム２０のシーケンス１８を含んでいる、または、そこに埋め込んでいる送信信号３８を送信するための送信ステージ３６を含む。例えば、送信ステージ３６は、送信信号３８をブロードキャストすることができる。送信ステージ３６は、ＯＳＩモデルによれば、アクセスユニットストリーム前処理器１６が属するトランスポート層の下にあるトランスポート層を示すことができる。例えば、論理フレームのシーケンスは、同様に送信フレームのシーケンスの形式で送信ステージ３６によって送信されるＭＳＣスチームに埋め込まれうる。そして、それの後者は各変調シンボルによって送信される。例えば、送信ステージ３６は、バーストで、そして、例えば、ＯＦＤＭ信号などの方法によって、送信信号３８を送信することができる。論理フレーム２０のサイズは、時間に関して一定でありうるし、または、可変でありうる。可変である場合には、各論理フレーム２０のサイズは、送信信号３８の補助情報チャネル内で示されうる。更に、送信信号３８の補助情報チャネルは、受信器側で有効な省力化を可能にするために、次の論理フレームを含む次のバーストがいつ起こるかを示しているデータ時間などの情報、および／または、論理フレームの開始および終わりが送信信号３８内のどこに配置されているかに関する表示を含むことができる。

このように、作動中、アクセスユニットストリーム生成器１２は、アクセスユニット２８を生成し、そして、アクセスユニットストリーム前処理器１６は、アクセスユニット２８の開始部分３２が含まれる各論理フレーム２０に、アクセスユニットテーブル３０を供給するとともに、連続したアクセスユニット２８を論理フレーム２０の有用なデータセクション２４に連続して挿入する。各アクセスユニットテーブル３０は、各論理フレーム２０に含まれているアクセスユニット２８の開始部分３２ごとに、各開始部分３２を指し示しているポインタ４０を含む。ポインタ４０が存在することによって、送信信号３８内の論理フレーム２０を受信している受信器は、復号器が適時にアクセスユニット２８の開始部分３２が含まれる第１の論理フレームを受けると即時に、第１のアクセスユニットを見つけ、アクセスすることが可能である。この目的で、受信器は、前もって論理フレーム２０の始まりおよび終わりの位置を知るために、例えば、送信信号の補助情報チャネルにおける上述の追加の表示を使用することができ、または、論理フレームの境界は、送信信号の全体の構造によって暗に測定されることができる。このように、送信ステージ３６により用いられる帯域幅が小さいときでも、送信信号３８によって伝達されたアクセスユニットストリームに同期するときの復号器遅延は、アクセスユニットを見つけるために復号器に別途必要となるであろう追加の同期の要求によっては、追加的に増加しない。

図３は、論理フレーム２０のシーケンス１８を含んでいる、または、その中で埋込まれたそのシーケンスを有する送信信号３８を受信することに適している受信チェーンまたは受信器５０を示す。受信チェーン５０は、任意選択で、送信ステージ３６に相当するものとして、受信ステージ５２を含む。換言すれば、受信ステージ５２は、送信ステージ３６が属する同じトランスポート層に属しうる。受信ステージ５２は、すでに上で概要を述べたように、例えば、特定のチャネル等で送信信号３８の中の送信された補助情報に基づいた送信信号３８内の論理フレームを見つけるためのいくつかの処理装置だけでなく、アンテナ、増幅器、復調装置、例えばターボ復号器を含んでいる前方向訂正器、および／または、デインターリーバ（ｄｅ−ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。

受信ステージ５２は、論理フレーム２０のシーケンス１８を、復号器５０により更に含まれるアクセスユニットストリーム再生器５４に転送する。アクセスユニットストリーム再生器５４は、論理フレーム２０のシーケンス１８から、連続したアクセスユニット２８のアクセスユニットストリーム１４を再生するように構成される。特に、再生器５４は、そこに配置されたアクセスユニット２８の開始部分３２を有する、送信信号３８によって受信された第１のものなどの所定の論理フレーム２０から、アクセスユニットテーブル３０を抽出し、抽出されたアクセスユニットテーブル３０によって、含まれた各ポインタ４０を用いて、各論理フレーム２０に開始部分３２が含まれる各アクセスユニット２８を見つけ、そして、その抽出を開始するように構成されうる。この他に、再生器５４は、受信ステージ５２から受信した論理フレーム２０のシーケンス１８の論理フレーム２０の有用なデータセクション２４から、アクセスユニットストリーム１４の連続したアクセスユニット２８を連続して抽出するように構成される。更に、復号器５０は、再生器５４によって論理フレーム２０から再生されるように、アクセスユニット２８のシーケンス１４によって伝達されたメディアコンテンツを復号する、および／または、表示するために、プレゼンター５６を含むことができる。プレゼンター５６は、例えば、ビデオ復号器、オーディオ復号器、および／または、テキスト若しくはデータのハンドラを含むことができる。更に、プレゼンター５６は、ビデオディスプレイおよび／またはスピーカを含むことができる。

図１〜図３に関して上述された特定の詳細は、好適であるが、任意である。以下では、特定の詳細および変形例の効果が説明される。例えば、上記のように、アクセスユニットストリーム前処理器１６は、アクセスユニットテーブル３０が各論理フレーム２０の後端と接するように、論理フレーム２０のシーケンス１８を生成するように構成されうる。この点に関して、論理フレーム２０の後端は、例えば、右側を指し示している図１の時間方向に関して、復号器５０で送信信号３８の中で時間において後に到達している論理フレーム２０の端であると理解されることに留意されたい。しかしながら、代わりに、アクセスユニットテーブル３０は、各論理フレーム２０の前端に接することができるだろう。あるいは、アクセスユニットテーブル３０は、各論理フレーム２０の後端若しくは前端から所定の一定のオフセットを有しうる。すべてのこれらの場合において、再生器５４は、所定の論理フレーム２０のアクセスユニットテーブル３０を見つけることが可能であり、そのアクセスユニットテーブル３０は、各論理フレーム２０の後端若しくは前端に、または、各論理フレーム２０の後端若しくは前端からの所定の一定のオフセットで、見積もられることになる。

更に、上述にもされたように、アクセスユニットストリーム前処理器１６は、ポインタ４０が、アクセスユニット２８の開始部分３２が含まれる論理フレーム２０の中で一定の方法で、各論理フレーム２０の後端若しくは前端に対して配置された位置決め点（ｒｅｇｉｓｔｒａｔｉｏｎ ｐｏｉｎｔ）から、各論理フレーム２０に含まれているアクセスユニット２８の開始部分３２を指し示すように、論理フレーム２０のシーケンス１８を生成するように構成されることができる。後述する特定の実施形態において、例えば、ポインタ４０は、各論理フレームの前端から測定された、バイト若しくはビット単位またはなんらかの他の単位長で、各アクセスユニットテーブル３０において示される。しかし、代わりに、その前端とは別の論理フレーム内の点は、ポインタ４０がアクセスユニット２８の開始部分３２をそこから指し示す、上述された位置決め点として機能しうる。したがって、再生器５４は、現在調べられた論理フレーム２０に開始部分３２が含まれる各アクセスユニットを見つける際に、位置決め点からの変位として、各ポインタ４０を使用するように構成されることができる。

更に、図１に関して明示的に述べられなかったが、図１は、アクセスユニットストリーム前処理器１６が、少なくとも、できる限り、連続したアクセスユニット２８を論理フレーム２０の有用なデータセクション２４にシームレスに挿入するように構成される場合を示す。図１のアクセスユニットＡＵ２とＡＵ３との間のギャップ５８は、例えば、各論理フレームに含まれている開始部分３２の数が増加するのに伴って増加する長さ３４を有する図１の実施形態のアクセスユニットテーブル３０のただの結果であり、その結果として、有用なデータセクションは、出現している追加の開始部分３２ごとに減少する。しかし、このようなギャップ５８の他は、図１のアクセスユニット２８は、論理フレーム２０の有用なデータセクション２４の中にシームレスに挿入されている。

しかしながら、代わりに、アクセスユニット２８は、そこに配置された無関係なパディング・データ（ｐａｄｄｉｎｇ ｄａｔａ）とともに論理フレーム２０の有用なデータセクション２４に挿入されうる。例えば、アプリケーションに応じて、アクセスユニット２８は、それが送信信号３８によって伝達される必要がある特定のビットレートとは無関係に、アクセスユニットストリーム生成器１２によって生成されることもあった。そして、正確にかかる送信レートに従うために、前述のパディング・データは、あるアクセスユニット２８間に差し込まれることもある。このように、パディング・データは、送信側で、以下で提示される任意の長さ表示およびポインタ４０を適宜に設定することによって、論理フレームのシーケンス内で組み込まれうる。しかしながら、代わりに、例えば、各ＡＵのためのＡＵテーブルの中で示された、使用されていない又は特定の「ストリームＩＤ」は、このＡＵが単に「パディング・データ」を含むだけである、すなわち、「パディングＡＵ」であることを示すことができ、その場合に、結果として生じるＡＵストリームもまた、送信側でパディングを可能にすることによって、シームレスに挿入されたＡＵストリームの前述された特性を維持するであろう。受信側では、これらのパディングＡＵは、スキップされる又は無視される。そして、ただ他のＡＵだけが更に処理されるだろう。

したがって、アクセスユニットストリーム再生器５４は、論理フレーム２０の有用なデータセクション２４から、連続したアクセスユニット２８を、シームレスに、または、単に連続して抽出することができる。連続したアクセスユニット２８を抽出するために、アクセスユニットストリーム再生器５４は、前述のポインタ４０の使用によって、または、代わりに、アクセスユニットを解析することにより各アクセスユニット２８の端を検出することによって、続くアクセスユニット２８の開始部分３２を見つけることができ、この端は、アクセスユニットストリーム再生器５４によって予想可能である図１のギャップのような状態５８が存在することを除いて、次のアクセスユニット２８の開始部分３２を示している。

更に、アクセスユニットストリーム前処理器１６は、論理フレームヘッダ２２の中で、連続したアクセスユニット２８のいずれも開始部分３２が含まれていない論理フレーム２０に関して、各論理フレーム２０にアクセスユニットテーブル３０の不存在、および、連続したアクセスユニット２８の少なくとも１つの開始部分３２が含まれる論理フレーム２０に関して、各論理フレームのアクセスユニットテーブル３０の長さ３４を示すように構成されることができる。この手段によって、アクセスユニットストリーム再生器５４は、各論理フレーム２０の論理フレームヘッダ２２から、各論理フレーム２０の中のアクセスユニットテーブル３０の不存在、又は、その長さを示している情報を抽出し、それに依存している各論理フレーム２０の有用なデータセクション２４の範囲を見つけることが可能である。特に、アクセスユニットストリーム再生器５４は、現在の論理フレームの各アクセスユニットテーブル３０がデータ破壊により破損している場合でさえ、有用なデータセクション２４の範囲を見つけることが可能であり、このように、アクセスユニットストリーム再生器５４は、正しく、このアクセスユニットテーブル３０と有用なデータセクション２４との間の境界を超えて、その間の論理フレームの境界の向こう側でさえある次の論理フレーム２０の有用なデータセクション２４まで及んでいるアクセスユニット２８を抽出し続けることが可能である。

同様に、アクセスユニットストリーム前処理器１６は、各論理フレームヘッダ２２が、各論理フレーム２０の後端若しくは前端に接する、または、そこから所定の一定のオフセットを有するように、構成されることができる。図１の実施形態において、すべての論理フレームヘッダ２２は、各論理フレーム２０の前端に接する。したがって、アクセスユニットストリーム再生器５４は、すなわち、例えば有用なデータセクション２４の特定の部分などの論理フレーム２０の残りの部分の範囲内でのデータ破壊とは無関係である、各論理フレーム２０の前端若しくは後端で、または、そこからの所定の一定のオフセットで、各論理フレームにおいて、論理フレームヘッダ２２を見つけるように構成されることができる。

図１の場合、例えば、アクセスユニットストリーム前処理器１６は、有用なデータの挿入方向６０を使用して、論理フレーム２０の有用なデータセクション２４に、連続したアクセスユニット２８の連続挿入を実行するように、そして、有用なデータ挿入方向６０に示している一定に配置された端、すなわち、一定に配置された後端、および、有用なデータの挿入方向６０とは反対を示している変動する端、すなわち、アクセスユニットテーブル３０の長さにより一定に配置された端からオフセットされる、変動して配置された前端を有する各論理フレーム２０の接続された部分２０を占めるために、論理フレーム２０の中でアクセスユニットテーブル３０を配置するように構成された。換言すれば、論理フレームヘッダ２２における長さ３４の表示は、アクセスユニットテーブル３１の一定に配置された端、すなわち、その後端から測定されたアクセスユニットテーブル３０の長さ又はサイズを測定しうる。したがって、アクセスユニットストリーム再生器５４は、論理フレーム２０の中の有用なデータの挿入方向と同じ有用なデータの抽出方向を使用して、論理フレーム２０から連続したアクセスユニット２８の連続した抽出を実行するように、そして、その一定に配置された端から有用なデータ抽出方向６０とは反対の方向にアクセスユニットテーブル３０の長さ３４を適用することによってアクセスユニットテーブル３０の変動する配置された端を見つけるように構成されることができる。

アクセスユニットテーブル３０および論理フレームヘッダ２２が、論理フレーム２０の前端および後端の反対の端に接する、または、論理フレーム２０の前端および後端の反対の端から一定にオフセットされるように、アクセスユニットストリーム前処理器１６が論理フレーム２０のシーケンスを生成するように構成される場合、および、したがって、アクセスユニットストリーム再生器５４は、図１の場合のように、各論理フレーム２０の前端および後端の異なる端で、または、各論理フレーム２０の前端および後端の異なる端に対し一定のオフセットで、アクセスユニットテーブル３０および各論理フレーム２０の論理フレームヘッダ２２を見つけるように構成される場合、有利でありえる。これは、論理フレームヘッダ２２の長さが変動し、その長さがＬＦヘッダ自体の内容に依存している場合に、特に、あてはまる。この場合、アクセスユニットストリーム再生器５４は、各論理フレームの有用なデータセクション２４の中でのデータ破壊に関係なく、アクセスユニットテーブル３０および論理フレームヘッダ２２を見つけることができて、論理フレームヘッダ２２のデータ破壊に関係なく、アクセスユニットテーブル３０を見つけることができ、そして、その逆もそうである。

さらにより具体的には、アクセスユニットストリーム前処理器１６は、アクセスユニットテーブル３０および論理フレームヘッダ２２が、論理フレーム２０の前端及び後端の反対の端と接し、その結果、有用なデータセクション２４が、アクセスユニット２８の開始部分３２が含まれる論理フレーム２０に関して、それぞれ、アクセスユニットテーブル３０と論理フレームヘッダ２２との間に、および、他の論理フレーム２０に関して、論理フレームヘッダ２２と論理フレーム２０の前端及び後端の反対のものとの間に、及んでいる結合部であるように、論理フレーム２０のシーケンス１８を生成するように構成されることができる。

すでに図１に示されたように、アクセスユニットストリーム前処理器１６は、図１のアクセスユニットＡＵ２などのその後の論理フレーム２０へと各論理フレーム２０の後端を超えて及んでいる、アクセスユニット２８の開始部分３２が含まれる各論理フレーム２０において、アクセスユニットテーブル３０に、各アクセスユニット２８の長さ６２を示している長さ表示、すなわち、その開始部分を指し示しているポインタ４０と結合されたときに各論理フレーム２０の後端を決定することができる表示を供給するように構成されることができる。図１において、アクセスユニットストリーム前処理器１６は、各ポインタ４０に、開始部分がポインタ４０によって指し示されるアクセスユニット２８の前述の長さ表示６２を加えるように模範的に構成される。（方向を解析する際の）後端がアクセスユニット２８を解析することによって確定できない、または、局部的データ誤りのため検出されるのを防止されるアクセスユニット２８の場合には、アクセスユニットストリーム再生器５４は、有用なデータセクション２４の中でアクセスユニット内容とパディング・データとの間を分離するために長さの表示６２を使用することができる。しかし、アクセスユニット２８の端が、アクセスユニットを解析することによって、例えば、アクセスユニット２８自体にある各アクセスユニット端フラグ（ｅｎｄ―ｏｆ―ａｃｃｅｓｓ―ｕｎｉｔ―ｆｌａｇ）を検出することによって、アクセスユニットストリーム再生器５４により検出可能である場合、各アクセスユニットテーブル３０の長さ表示６２が破損していた場合でさえ、アクセスユニットストリーム再生器５４は、各アクセスユニット２８の端を検出することができる。いずれにせよ、アクセスユニットストリーム再生器５４が、例えば、続く論理フレームのアクセスユニットテーブルが消失する又は破壊されるときでさえ、各論理フレーム２０の後端を超えてその後の論理フレームに及んでいることによって、開始部分が各論理フレーム２０の中に含まれるアクセスユニット２８の長さ６２を得るために、アクセスユニットテーブル３０からこのような長さ表示６２を得ることができることは、有利である。論理フレーム部分２４へのアクセスユニット２８のシームレスな挿入の場合には、再生器５４は、続くアクセスユニットの開始部分３２を見つけるために、連続した論理フレーム２０を超えて及んでいるかかるアクセスユニット２８の長さ６２の長さ表示を使用することさえできる。例えば、論理フレームＬＦ１のアクセスユニット３０がアクセスユニットＡＵ２の開始部分３２を指し示しているポインタ４０が手元にない程度まで、破損している場合には、再生器５４は、アクセスユニットＡＵ２の開始部分３２を検出するために、アクセスユニットＡＵ１の長さ６２を使用することができる。

しかしながら、長さ表示の代わりに、端ポインタ表示が、各ＡＵの端を直接、すなわち、開始部分３２を指し示しているポインタ４０から独立して、指し示すために使用されることができることに留意しなければならない。その効果は、上で概説された効果と同様である。端ポインタ表示は、例えば、各ＡＵの各端が含まれる論理フレームの、例えば前端などの上述の位置決め点から、このＡＵの端を指し示しているポインタを含むことができる。加えて、端ポインタ表示は、例えば現在のＬＦの後のＬＦから始まっているＬＦの数を計数することなどによって、各ＡＵの端がどのＬＦに含まれているかについて指し示しているＬＦインジケータを含むことができる。以下に示された説明を容易にするために、以下の実施形態によれば、長さ表示が使用される。しかしながら、これらの実施形態において、長さ表示は、各ＡＵの端を見つけることを可能にしている表示のために単に代表しているだけであると理解されるべきである。

すでに上で述べたように、アクセスユニットストリーム前処理器は、各論理フレーム２０に、各アクセスユニットテーブル３０の長さを示している論理フレームヘッダ２２を供給するように構成されることができる。以下でより詳細に提示された実施形態によれば、前処理器１６は、開始部分３２が各論理フレームに含まれるアクセスユニット２８ごとに、アクセスユニットテーブルエントリを各アクセスユニットテーブル３０に供給し、論理フレームヘッダ２２は、例えば、各アクセスユニットテーブル３０の中で各々一定の長さを有するアクセスユニットテーブルエントリの数で測定されたアクセスユニットテーブル３０の長さを示している。この種の具体的な実施形態は、図５を参照に後にＤＲＭ実施形態に関して説明される。図５について簡潔に述べると、そこに模範的に示された論理フレーム２０が、いくつかのアクセスユニットテーブルエントリ６４からなることが、図５から導き出せる。また、図５から導き出せるように、有用なデータセクション２４は、論理フレームヘッダ２２およびアクセスユニットテーブル３０を除いた論理フレーム２０の残りの部分を完全にカバーしないこともある。むしろ、図５に示すように、有用なデータセクション２４は、その所定数のバイト又はビット分、論理フレームヘッダ２２および／またはアクセスユニットテーブル３０からオフセットされうる。そして、その所定数は、例えば、復号器に知られている、または、送信信号３８内の余分のチャネルで復号器に送られる。図５の例において、例えば、ＦＥＣデータ６６（ここでは、一般的であるＲＳ（Ｒｅｅｄ Ｓｏｌｏｍｏｎ：リード・ソロモン）データ）は、論理フレームヘッダ２２と有用なデータセクション２４との間に配置される、または、配置されうる。このＲＳデータ６６は所定の長さを有している。拡張セクション６８は、有用なデータセクション２４とアクセスユニットテーブル３０との間に配置されうる。そのアクセスユニットテーブルは、一定の長さ、または、以下の実施形態の場合のように、例えば開始部分が現在の論理フレーム２０に含まれるアクセスユニット２８の数から知られる方法で依存する変動する長さ、または、拡張セクションとアクセスユニットテーブルとの間の知られた境界の拡張セクション自体の中に存在するその長さの表示を有する。アクセスユニットテーブルエントリ６４の開始部分は、一定の長さの単位で、論理フレーム２０の後端７０から、または、別の実施形態では、前端から、間隔を置いて配置されうる。したがって、再生器５４は、論理フレーム２０のアクセスユニットテーブル３０を抽出するとき、各アクセスユニットテーブルエントリに関して、対応しているアクセスユニット２８の各開始部分３２を指し示しているポインタ４０を得るために、一つのアクセスユニットテーブルエントリから次のものまでのこれらのアクセスユニットテーブルエントリ６４の一定の長さの単位で、アクセスユニットエントリ６４をステップすることによって、論理フレーム２０の後端７０で、あるいは、そこからの所定の一定のオフセットを有している、論理フレーム２０内の一位置で始めて、ＬＦヘッダ２２によって示された、アクセスユニットテーブルエントリ６４の数を連続して抽出するように構成されうる。アクセスユニットストリーム前処理器１６が、位置合わせされた後端から、すなわち、論理フレーム２０の後端７０から開始することで、アクセスユニットテーブル３０を入れる場合、有利でありえる。換言すれば、有用なデータ挿入方向６０に沿って各論理フレーム２０の中に含まれているアクセスユニット２８の第１の開始部分３２は、論理フレーム２０の後端７０からの第１のアクセスユニットテーブルエントリ６４、すなわち、論理フレーム２０の後端７０に最も近い若しくは接しているアクセスユニットテーブルエントリ６４内の各ポインタによって、アクセスユニットテーブル３０において示される。有用なデータの抽出方向６０に続く開始部分３２は、ユーザデータの挿入方向６０と反対の方向に沿って続く。これは、前処理器１６が、一度に論理フレーム単位でそれらを構成するよりは、むしろ論理フレーム２０を連続して構成することができるので、有利である。

後述する実施形態に関する場合にもあるように、前処理器１６は、アクセスユニットテーブルエントリのために個々のデータ破損検出および／または訂正を可能にしている付加的な冗長データを、各アクセスユニットテーブル３０に供給することができる。特に、各アクセスユニットテーブルエントリ６４自体は、個々の付加的な冗長データを含むことができる。各アクセスユニットテーブルエントリ６４は、少なくともポインタ４０と任意選択で各アクセスユニットテーブルエントリ６４の長さ６２を示している任意の長さ表示に関して計算された、および、そのデータ訂正検出を可能にしている第１の冗長データを供給されることができる。結果として、再生器５４は、個々にＡＵＴエントリの正確性をチェックすることが可能であり、そして、１つのＡＵＴエントリの破損は、同じＡＵテーブルの他のＡＵＴエントリの作業性を損なわない。更に、以下で更に詳細に概説されるように、第１の冗長データの存在は、一定の長さを有するＡＵＴエントリをステップするときに、例えば、破損したＬＦヘッダのために、ＡＵＴエントリの合計数が分からない場合、一列に並んでいる次のＡＵＴエントリの有効性または存在をチェックすることさえも可能にする。

加えて、または、代わりに、各アクセスユニットテーブルエントリ６４は、各アクセスユニットテーブルエントリ６４と関連したアクセスユニットのコンテンツに関して計算された、および、そのデータ破損検出を可能にしている第２の冗長データを供給されることができる。このように、各ＡＵの正確さは、個々に検出可能である。

更に、実施形態によれば、第１の冗長データは、ポインタ４０、任意選択で、任意の長さ表示、および、各アクセスユニットテーブルエントリ６４の第２の冗長データに関して計算され、それらのデータ訂正検出を可能にする。

図４に関して、一実施形態による、ポインタ４０をアクセスユニットテーブル３０に挿入するとともに、論理フレーム２０に連続してアクセスユニット２８を挿入する際の前処理器１６の動作モードは、説明される。図４のプロセスは、アクセスユニット２８を論理フレーム２０に連続して挿入することを続けるために、ステップ８０において、前処理器１６が次のアクセスユニット２８に移ることによって始まる。次に、ステップ８２で、前処理器１６は、現在のアクセスユニット２８の開始部分３２は、現在の論理フレーム２０内に位置づけられるかどうかに関してチェックする。この点に関しては、更なるアクセスユニットテーブルエントリ６４が、アクセスユニットテーブル３０に付け加えられる、または、別の言い方をすれば、アクセスユニットテーブル３０の長さが増加するにつれて、アクセスユニット２８の更なる開始部分３２がこの現在の論理フレームの中に含まれるとすぐに、現在の論理フレームの有用なデータセクション２４がサイズの点で減少することに留意されたい。このため、現在、現在の論理フレーム２０の有用なデータセクション２４が、その瞬間に少量の更なるアクセスユニット内容を調節する能力を有するにもかかわらず、そして、前処理器１６が、例えば、その論理フレームにアクセスユニット２８をシームレスに挿入することを求めるにもかかわらず、前処理器１６は、次の論理フレームの中のアクセスユニット２８の開始部分３２を位置付けることを決めることができる。開始部分３２が、現在の論理フレームの中に位置づけられるとすぐに、現在の論理フレーム２０の有用なデータセクション２４の残りの容量が、ポインタ１４を指し示すのに必要な新しいアクセスユニットテーブルエントリ６４を新しいアクセスユニットのこの新しい開始部分３２に追加するのに必要な量を適応させるのに十分でないだろう。このような状況に関する例は、アクセスユニットＡＵ３の開始部分３２の場合における図１に模範的に示される。

しかし、ギャップ５８のようなギャップは、模範的に前述されたそれらとは他の理由を有しうる。例えば、ＬＦが、パッディングが上述のように前処理器１６により導入される、断続しない送信信号３８を確実にするために、例えば送信ステージ３６に、集められ、出力されることを必要とするときに、アクセスユニットストリーム前処理によって処理されることになっている一列に並んだ次のＡＵデータが単にまだ利用可能でないこともありうる。

前処理器１６が、ステップ８２において、次の論理フレームに現在のアクセスユニット２８の開始部分３２を位置づけることを決定する場合、前処理器１６は、例えば、現在の論理フレームを閉じて、次の論理フレームを開くことを含んでいるステップ８４において、次の論理フレームに移る。現在の論理フレームを閉じることは、前処理器１６が、より詳細に下で後述される前方向誤り検出／訂正データなどのデータ破損検出／訂正のための前述の付加的な冗長データを計算して、送信ステージ３６に論理フレームを送り出すことを含む。次の論理フレーム２０を開くことは、例えば、これまで、アクセスユニットテーブルがこれらの次の論理フレームの中に存在しないことを示している最初の状態に、論理的論理フレームヘッダを事前設定することを含む。ステップ８４の後、そのプロセスは、再度、ステップ８２にループする。

ステップ８２におけるチェックが、現在のアクセスユニット２８が現在の論理フレームに位置づけられたその開始部分３２を有しなければならないことを生ずる場合、そのプロセスは、前処理器１６が、アクセスユニットテーブルを入れ、論理フレームヘッダを更新するステップ８６へと進む。特に、ステップ８６は、ステップ８２の対象である開始部分３２が現在の論理フレームの第１の開始部分３２である場合に、現在の論理フレーム２０内でのアクセスユニットテーブル３０を生成することを含みうる。この開始部分３２に関して、ポインタ４０および、任意選択で、長さ６２を示している長さ表示は、各アクセスユニットテーブルエントリ６４に挿入され、そして、それは、任意選択でアクセスユニットテーブルエントリ６４に関する、および、任意選択で、別々に、長さ表示に関する付加的な冗長データを含む。論理フレームヘッダ２２の更新は、この論理フレームヘッダ２２に示されたアクセスユニットテーブルエントリの数を増加させることを含む。

ステップ８２における「はい」オプションの結果として、前処理器１６はまた、ステップ８８において、現在のアクセスユニット２８を現在の論理フレーム２０に挿入する。その間、前処理器１６は、ステップ９０において、現在の論理フレーム２０が満ちているか、すなわち、現在の論理フレーム２０の有用なデータセクション２４の中に挿入されうるアクセスユニットデータがないかに関して、連続的にチェックする。もし満ちている場合、前処理器１６は、次の論理フレーム２０に移る、すなわち、現在の論理フレームを閉じて、次の論理フレームを開くために、ステップ９２に進む。ステップ９２の後は、そのプロセスは、ステップ８８へループする。しかしながら、現在の論理フレーム２０が、まだ完成されていない、または、完全に満たされていない場合、前処理器１６は、ステップ８８における挿入の間ずっと連続して他のチェック、すなわち、現在挿入されたアクセスユニットが完全に挿入されたものか、すなわち、現在のアクセスユニットの最後に到達したかに関してのチェック９４を実行する。もし現在のアクセスユニットの最後に到達していれば、そのプロセスは、シーケンス１４の次のアクセスユニットに移るために、ステップ８０へループする。そうでない場合には、そのプロセスは、ステップ８８へループする。

かなり一般的に、図２および図３の他の要素と同様に、送信チェーン１０、アクセスユニットストリーム前処理器１６、復号器５０、および、アクセスユニットストリーム再生器５４のための実施形態について説明した後に、以下では、オーディオ、テキストまたはデータ情報がＤＲＭにより送られるだけでなくなく、ビデオまたはビデオとオーディオの混合、または、他の時間整列されたテキスト情報も、その品質が受信側で受け入れられるような方法で、ＤＲＭにより送られる程度にまで、ＤＲＭ（ＤＲＭ＝デジタル・ラジオ・モンディエール（Ｄｉｇｉｔａｌ Ｒａｄｉｏ Ｍｏｎｄｉａｌｅ））により供給された送信可能性を拡張する可能性を示す本発明の実施形態が説明される。ＤＲＭの可能性を拡張するためのこの送信構想は、以下ではＤｉｖｅｅｍｏと呼ばれている。Ｄｉｖｅｅｍｏによって、例えば、教育および情報ビデオプログラムは、ＤＲＭによって送信されることができる。

下で説明された、以前はＤｒＴＶとして知られていたＤｉｖｅｅｍｏに関する実施形態は、ＤＲＭ（デジタル・ラジオ・モンディエール）によって、（おそらくはデータサービスと共に）ビデオおよびオーディオの送信を可能にする。考えられるアプリケーションは、情報および教育プログラムを海外に住んでいる市民に供給することに関係しうる。入手できる画像および音響品質は、カスタマーの期待のボトムエンド以上であり、しかしながら、使用の多くの分野に絶対的に充分である。

Ｄｉｖｅｅｍｏは、ＤＲＭによるビデオ・サービスを可能にするというアイデアを実施するための実施形態を形成する。ビデオ・サービスは、ＤＲＭ標準、すなわち、低い利用可能ビットレート、ＤＲＭに対応したサービス信号送信およびコンフィギュレーション、ＤＲＭにより供給された送信構造に関する対応性、受信誤りの効果的な処理などに適合される必要がある。

更なる態様によれば、後述するＤｉｖｅｅｍｏの実施形態は、送信チャネルの最大ビットレート使用量をもって割り込みフリーの「シリアルデータストリーム」としてパディングまたは付加的なオーバーヘッドを必要とせずに、一連の独立したデータパケット（「アクセスユニット」）を送信する包括的でＤＲＭから独立した方法を使用する送信方式を形成する。ここで、同時に、使用された送信方式（例えばＤＲＭ）の時間的標準および送信構造は、データ・ストリームへの受信を復号し、同期する（ｕｐ−ｓｙｎｃｈｒｏｎｉｚｉｎｇ）のに必要な情報を埋め込むために使用される。その結果、この情報の抽出は、すばやく可能であり、多くのビット誤りを有する非常に不都合な受信状況に関してさえ、ペイロード・データの損失に関して少しの影響を有するだけである。

Ｄｉｖｅｅｍｏ機能性：Ｄｉｖｅｅｍｏは、新情報および教育サービスのかなりの範囲への門戸を開く。単一の送信器で広い地理的領域に点在したオーディエンスに届き、海外で生活している国民に自国で何が起こっているかについて情報を提供し、更新することは、理想的なプラットフォームである。このマルチメディア・アプリケーションは、コスト効率の高い全球陸域の放送標準ＤＲＭに基づきうる。短波長に関するＤＲＭ送信は、送信システムに依存している１００平方キロメートルから十分に５´０００´０００平方キロメートル以上までの実質制限されていない有効範囲を有する。Ｄｉｖｅｅｍｏアプリケーションは、無料受信の可能性を提供し、衛星およびケーブルネットワークのようなゲートキーパーおよび第三者プロバイダから独立している。可能性に際限はなく、１つの送信器は、どこでも、いつでも、何百万人にも達することができる。

Ｄｉｖｅｅｍｏは、非常に効率的なトランスポート符合化およびパケット化を供給することができ、一方で、同時に、レシーバが、ロバストに復号して、すぐに送信された内容に（再）同期することを可能にする。ビデオストリームは、同期式多言語サポートを可能にする一つ以上のオーディオストリームを付随させることができる。システムはまた、ユニコード互換のラベルによるサービス選択、代替周波数信号およびスイッチング、アナウンスおよび警告／警報機能、などのようなＤＲＭプラットフォームの全ての利点を特徴とする。

プログラムにテキストバックグラウンド情報を伴っている非常にビットレート効率のよいテキストベースの情報サービスＪｏｕｒｎａｌｉｎｅ（登録商標）のような他のＤＲＭ技術と組み合わさるときに、多数の言語およびスクリプトにおけるサブタイトル字幕使用サービスは直ちに利用可能でありうる。

更に、各記載の中のビットおよびバイトの順序は、特に明記しない限り以下の表現法を使用する。
−図において、左の位置に示されたビットまたはバイトが、１番目であると考慮される。
−テーブルにおいて、左の位置に示されたビットまたはバイトが、１番目であると考慮される。
−バイト・フィールドにおいて、最大有効ビット（最上位ビット）が、１番目であると考慮されて、より高い数を表される。例えば、１バイトのＭＳｂは「ｂ₇」で表され、そして、最小有効ビット（ＬＳｂ）は「ｂ₀」で表される。
−ベクトル（数式）において、最小インデックスを有するビットが、１番目であると考慮される。

この文書において定められたすべての数値のための送信の順序は、ビッグエンディアン（ＭＳｂ−ｆｉｒｓｔ）である（『ネットワークバイトオーダ』）。

「マルチプレックスフォーマット」
Ｄｉｖｅｅｍｏは、ＭＳＣサブチャンネルのオーディオ、ビデオおよび可能性がある他のコンテンツを有する一連の『アクセスユニット』を運ぶことができる。このＭＳＣサブチャンネルは、『ストリームモード』で、すなわち、ＤＲＭパケットモード（ＤＲＭ Ｐａｃｋｅｔ Ｍｏｄｅ）を使用せずに、データサービスをもたらすように構成される。コンテンツの１つの仮想ストリームに属しているすべてのアクセスユニット（例えばビデオデータを運んでいるそれら全て）は、「ＡＵタイプ（ＡＵ Ｔｙｐｅ）」と呼ばれる仮想ストリーム識別子で印をつけられる。同じＡＵタイプを有するアクセスユニットは、それらの表示順にＭＳＣサブチャンネルで運ばれる。異なるＡＵタイプを有するアクセスユニットは、インターリーブされた形でＭＳＣサブチャンネルで運ばれる。その結果、同じ表示時間をカバーしているそれらのアクセスユニットは、できるだけ近くに集められてトランスポートされる。任意選択で、有用なデータセクションおよびすべてのヘッダ情報のペイロード・データは、リード・ソロモン算法（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ ａｌｇｏｒｉｔｈｍ）に基づいて、送信誤差前方向誤り訂正（ＦＥＣ）から保護される。これは、仮想インターリーバと同様に、ＲＳ復号器を再利用することを可能にするＤＲＭパケットモード（ＤＲＭ Ｐａｃｋｅｔ Ｍｏｄｅ）の拡張パケットモード仕様に類似している。

Ｄｉｖｅｅｍｏが基づくＤＲＭ信号伝達（ＤＲＭ Ｓｉｇｎａｌｉｎｇ）構造は、以下の機能をすでに可能にする。
●ＦＡＣ（ファースト・アクセスチャネル）において定められる最高４つまでのＤＲＭサービス（ＤＲＭ Ｓｅｒｖｉｃｅｓ）。ＤＲＭサービスは、選択のためにユーザに示された仮想項目である。各ＤＲＭサービスは、（ＰＡＤ（プログラム関連データ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｅｄ Ｄａｔａ）） として任意のデータ・サービス・コンポーネントを加えた）オーディオ形式である、または、スタンドアロン・データ・サービスである。
●ＭＳＣ（メインサービスチャネル（Ｍａｉｎ Ｓｅｒｖｉｃｅ Ｃｈａｎｎｅｌ））は、最高４つのＭＳＣストリーム（ＭＳＣ Ｓｔｒｅａｍ）の実際のビットストリームを運ぶ。各メインストリームは、一定のビットレートの１つのサービスコンポーネント（オーディオまたはＤｉｖｅｅｍｏコンテンツ）またはパケットモードで最高４つのサービスコンポーネントを運ぶ。
●ＭＳＣストリーム保護は、（ＤＲＭマルチプレックスごとに定義された）最高２つの保護レベル／コードレートまでから選択されることができる。ＥＥＰ（均一誤り保護（Ｅｑｕａｌ Ｅｒｒｏｒ Ｐｒｏｔｅｃｔｉｏｎ）は、それらのうちの１つを、ＭＳＣストリームに割り当て、ＵＥＰは、（各送信フレーム（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｆｒａｍｅ）の始まりでより良く保護されたバイトを有する）ＭＳＣストリームごとに両方を使用する。
●ＳＤＣ（サービス記述チャネル（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｃｈａｎｎｅｌ））は、ＤＲＭサービスのための記述的情報（例えばラベル、言語、原産地、その他）および一般の信号情報（代替周波数、現在時刻／日付、その他）を運ぶ。それはまた、オーディオ（エンティティ９）およびデータ（エンティティ５）サービスコンポーネントの符号化を示しているエンティティを運ぶ。後者は、Ｄｉｖｅｅｍｏのために使用されうる。

Ｄｉｖｅｅｍｏが基づくＭＳＣデータトランスポート構造は、以下の機能を有する。
●Ｄｉｖｅｅｍｏのための一定のビットレートデータ・ストリームで、送信フレーム（ＴＦ）および送信スーパーフレームフレーム（ＴＳＦ）構造
●ＤＲＭ３０： ＴＦ＝４００ｍｓ；ＴＳＦ＝１２００ｍｓ
●ＤＲＭ＋： ＴＦ＝１００ｍｓ；ＴＳＦ＝４００ｍｓ
●ＴＳＦの中のＴＦは、インデックスを付けられる：ＤＲＭ３０：０〜３；ＤＲＭ＋ ０〜４；
換言すれば、送信フレームは、送信信号の特定の長さの部分を示して、送信信号内で同期させられる。論理フレームは、送信フレームの内容を示す。

「フレーム構造」
以下において、どのようにＤＲＭ ＥＴＳＩ ＥＳ ２０１ ９８０ Ｖ３．１．１、デジタル・ラジオ・モンディエールのＭＳＣサブチャンネルにおいてＤｉｖｅｅｍｏ情報をトランスポートするか、すなわち、システム仕様が説明される。それぞれ、ＤＲＭ論理フレーム（ＤＲＭ Ｌｏｇｉｃａｌ Ｆｒａｍｅ）は、それぞれ放送信号に足る１００ｍｓ（ＤＲＭモードＡ〜Ｄ）または４００ｍｓ（ＤＲＭモードＥ）ためのデータを含む。ＤＲＭ論理フレームが、Ｄｉｖｅｅｍｏ情報を運ぶ場合、それは、Ｄｉｖｅｅｍｏ論理フレームと呼ばれている。

Ｄｉｖｅｅｍｏ論理フレーム２０の構造が、図５に示される。それは、必須のＬＦヘッダ２２、任意のＲＳデータセクション６６におけるリード・ソロモン冗長度情報、必須の有用なデータセクション２４、その後に続く任意の拡張セクション６８、および、端７０にあるＡＵテーブルを含む。

有用なデータセクション２４は、アクセスユニット２８の形で、有用なコンテンツ（例えばオーディオおよびビデオ情報）を含む。各アクセスユニット２８は、特定の表示時間をカバーするコンテンツを示す。それは、連続的なバイトストリームを形成するために、有用なデータセクション２４におけるその前のアクセスユニットに直接続く。アクセスユニット情報のこのバイトストリーム１４は、データのブロックに分けられる。これらのデータのブロックは、次に、連続したＤｉｖｅｅｍｏ論理フレーム２０の有用なデータセクション２４の中に位置付けられる。従って、アクセスユニット２８は、有用なデータセクション２４においてどこでも始まることができて、連続した論理フレーム２０の複数の有用なデータセクション２６にまたがることがある。

現在のＤｉｖｅｅｍｏ論理フレーム２０の有用なデータセクション２４の中で始まっている全てのアクセスユニット開始部分３２に関して、ＡＵテーブルセクション３０は、１つのＡＵテーブルエントリ（ＡＵ Ｔａｂｌｅ Ｅｎｔｒｙ）６４を運ぶ。これらのＡＵテーブルエントリ６４は、この有用なデータセクション２４の中で始まる第１のアクセスユニットを示している「ＡＵテーブルエントリ０」が、ＡＵテーブルセクション３６の最後に運ばれ、有用なデータセクション２４の中で始まる第２のアクセスユニットを示している「ＡＵテーブルエントリ１」が、「ＡＵテーブルエントリ０」の直前に運ばれるなどのように、順序付けられる。

ＬＦヘッダ２２は、以下のビットから成り、送信の順番に言及される：
１ビット：拡張フラグ
７ビット：ＡＵテーブルエントリの数
８ビット：ＬＦヘッダの第１のバイトに関して、すなわち、ＡＵテーブルエントリの数に関して計算されたＣＲＣ。

ＲＳデータ６６は、後述するように１ブロックのリード・ソロモン冗長度情報である。当然、システマティック冗長符号などの他の冗長符号は、ＬＦを保護して、それぞれ、セクション６６の中に位置付けられるために使用されうる。

各ＡＵテーブルエントリ６４は、送信の順番に、すなわち、図５の左から右に、言及された、以下のビットからなる。
３ビット：ＡＵストリームＩＤ（「仮想ストリーム識別子」）。それは、０〜７の値をとる。「７」は、パディング・データを運ぶために確保される。これらのビットは、任意であって、別の実施形態によれば、省くことができる。
１ビット：コンテンツがビデオ形式ならば、Ｉ−Ｆｒａｍｅフラグで、そうでなければ、ｒｆａである。このビットはまた、異なる実施形態によれば、省略されうる。
１２ビット：ＡＵオフセット４０（絶対指数値、０は、Ｄｉｖｅｅｍｏ論理フレーム（Ｄｉｖｅｅｍｏ Ｌｏｇｉｃａｌ Ｆｒａｍｅ）２０の第１のバイトを示している）。ＡＵオフセットは、このように、バイトで、現在の論理フレーム２０の前端から測定された前述のポインタ４０に対応する。ビット数、すなわち１２は、例えば、より短い論理フレームを使用している他の実施形態によれば、変更されうる。そして、加えて、または、代わりに、ＡＵオフセットは、バイト以外の単位でポインタ４０の長さを測定されうる。
１６ビット：ＡＵ長。ＡＵ長は、このように、前述の長さ６２に対応する。さらにまた、ビット数、すなわち１６は、アプリケーションに依存し、別の実施形態によれば変更されうる。加えて、または、代わりに、ＡＵ長は、バイト以外の単位で各ＡＵ長を測定しうる。そして、さらに、代案として、位置決め点は、上記のように、異なる方法で、各ＡＵの端を指し示すために、異なって選択されうる。
１６ビット：ＡＵタイムスタンプ（ＡＵ Ｔｉｍｅｓｔａｍｐ）（下記の詳細なタイミングの記載を参照。ＡＵテーブルエントリ６４の中のこの情報も、任意であって、他の実施形態によれば省略されうる。
１６ビット：ＡＵ ＣＲＣ。ＡＵ ＣＲＣは、アクセスユニット内容の『ＡＵ長』バイトに関して計算される。このように、ＡＵ ＣＲＣはまた、すなわち第２の冗長データとして、前述されて、各ＡＵＴエントリと関連したＡＵの内容の範囲内で、データ破損検出も可能にする。さらにまた、ビット数は、任意であって、変更されうる。
８ビット：このＡＵテーブルエントリの第１の８バイトに関して、すなわち、ＡＵストリームＩＤ、ＡＵコンテンツフラグ、ＡＵオフセット、ＡＵ長、ＡＵタイミングスタンプおよびＡＵ ＣＲＣに関して計算されたＡＵテーブルエントリＣＲＣＡＵテーブルエントリＣＲＣはまた、任意選択で、長さ６２を示している長さ表示、ポインタ４０、および、さらに任意選択で、第２の冗長データに関して計算された第１の冗長データとして前述されている。ここで、ＡＵテーブルエントリＣＲＣはまた、ＡＵテーブルエントリ内の付加情報も模範的に保護する。これは、当然任意である。これは、ＡＵテーブルエントリＣＲＣに費やされるビット数に適当でもある。

拡張フラグ（Ｅｎｈａｎｃｅｍｅｎｔ Ｆｌａｇ）が１にセットされる場合、ＡＵテーブル３０の直前に挿入される拡張セクション６８がある。拡張フラグが１にセットされない場合、ＡＵテーブル３０の直前に挿入される拡張セクション６８はない。拡張セクション６８は、将来の拡張、すなわち将来の機能性のために使用されうる。拡張セクション６８は、以下のフォーマットを有するかまたは送信の順番に言及される以下のビットからなる。
ｎｘ８ビット：拡張セクションデータ
８ビット：拡張セクションの最後のバイトに関して算出されたＣＲＣ
８ビット：拡張セクションデータの長さ「ｎ」

静的情報が拡張セクション６８の最後に運ばれ、その結果、拡張セクション６８の長さは、ＡＵテーブルセクション３０の周知の境界２６から始まって、復号器側で、そして、アクセスユニットストリーム受信器５４によって、それぞれ、導き出されることに留意されたい。

このように、前処理器１６は、ここで説明されたＤｉｖｅｅｍｏの実施形態によれば、例えば、図４によるプロセスを使用することにより、前述したように、ＬＦヘッダ２２、ＡＵテーブルエントリ６４および論理フレームの他のビットの中で前述のビットをセットする。

任意で、Ｄｉｖｅｅｍｏ論理フレームの内容または複数の連続したＬＦは、リード・ソロモン前方誤り訂正（ＦＥＣ）によって、ともに保護されうる。リード・ソロモン符号を算出するために、冗長情報６６は、ＬＦヘッダセクション２２、有用なデータセクション２４、（もし存在するならば）拡張セクション６８および（もし存在するならば）テーブル情報３０に関して算出される。ＦＥＣ方式のロバスト性を増加させるために、リード・ソロモン算法へのこの入力データは、後述するように実質的にインターリーブされる、すなわち、前処理器１６は、実質的に論理フレーム２０の前述のデータをインターリーブすることによって、システマティックＲＳコードの冗長データ６６を算出するが、インターリーブされないフォーマットで論理フレームを送り出す。そして、再生器５４は、受信された論理フレームの各位置をデインターリーブすることによって、正しい順序で受信された、受信された論理フレーム内の情報の正確さ、および正しい情報かをチェックする場合もしない場合もあり、冗長データ６６を用いてこのようにしてインターリーブされた論理フレームデータをチェックする場合もしない場合もある。

ＦＥＣ方式は、個々のＤｉｖｅｅｍｏ論理フレーム２０に基づいて、または、それぞれ、３（ＤＲＭモードＡ〜Ｄ）または４（ＤＲＭモードＥ）Ｄｉｖｅｅｍｏ論理フレーム２０をカバーしているＤＲＭ送信スーパーフレーム（ＤＲＭ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｕｐｅｒ Ｆｒａｍｅ）に基づいて適用されうる。ＦＥＣ保護が利用可能であるか否かにかかわらず、ＦＥＣ方式の正確な構成は、ＤＲＭのＳＤＣデータエンティティタイプ５において運ばれた特定用途向けデータによって定義されうる。リード・ソロモン算法は、ＲＳ（２５５；２３９；８）によって、すなわち、２３９のコンテンツバイトごとに１６の冗長情報バイトを生成することによって、定められうる。

図６のダイアグラムは、仮想インターリービング・アプローチを視覚化する。すなわち、前述の仮想インターリービングのために、前処理器１６は、例えば、受信データを有するこのプロシージャをエミュレートしている再生器５４によって、アプリケーション・データテーブル９８の中に、挿入パス１００に沿った列方向に、 関連した前述のＬＦデータ、すなわち冗長データそのもの以外を挿入することができる。アプリケーション・データテーブル９８およびＲＳデータテーブル１０２は、列ごとに互いに隣接して位置づけられる。前処理器１６は、ＲＳデータテーブル１０２の行ごとにＲＳデータを計算し、すなわちテーブル９８と１０２を組み合わせたものの各行は、１つのＲＳ符号語を形成し、前処理器１６は、それからパス１０４に沿った列方向に、少しのテーブル１０２を読み出して、このインターリーブされた順番にＲＳデータセクション６６を埋める。テーブル１０２を埋めるときに、再生器５４は、ＲＳデータ６６にデインターリーブする。

以下の定義は、図６の値ＲおよびＣに適用する。
Ｒ：仮想インターリービング・テーブル（Ｖｉｒｔｕａｌ Ｉｎｔｅｒｌｅａｖｉｎｇ Ｔａｂｌｅ）の行数、許容値は、例えば、１〜５１１である。
Ｃ：ＬＦの中で保護されるバイト数が分かっているので、Ｒの値によって、暗に与えられる。

Ｒの値は、ＳＤＣデータエンティティタイプ１４において信号を送られうる。Ｃの値は、アプリケーション・データ・テーブル（Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ Ｔａｂｌｅ）から算出されることができ、それは、ＳＤＣにおいて信号を送られるように、ちょうど１、３、または、４のＤｉｖｅｅｍｏ論理フレームを保持するのに十分大きいものでなければならない。列数は、ＦＥＣデータ６６のオーバーヘッドを決定する。Ｃの値がより小さくなるにつれて、オーバーヘッドは、より高くなる。

行数は、インターリービング深さおよびブロック遅延を決定する。Ｒの値がより小さくなるにつれて、受信データが処理される前にインターリービングをより小さくし、遅延をより小さくする。

テーブル９８および１０２それぞれのすべてのセルを埋めるのに送信されているデータが少ない場合、暗黙のパディングが適用されうる。

「ＤＲＭ信号送信」
Ｄｉｖｅｅｍｏサービスは、アプリケーションＩＤ値「２７₁₀」（５ビット）を有する速いアクセスチャンネル（ＦＡＣ）において信号を送られうる。

ＳＤＣデータ・エンティティ５は、以下の構造を有しうる。
１ビット：ＰＭフラグ（ＰＭ Ｆｌａｇ）：０（ＤＲＭストリームモード）
３ビット：ｒｆａ
１ビット：拡張フラグ
３ビット：アプリケーション・ドメイン：０ｘ００（ＤＲＭアプリケーション）
１６ビット：アプリケーションＩＤ：０ｘ５４５６（「ＴＶ」のためのＡＳＣＩＩ）
ｍｘ８ビット：アプリケーション・データ（下記参照）

ＳＤＣデータ・エンティティ５アプリケーションデータ・セクションのフォーマット：
２ビット：メジャー・バージョン、一般に０
３ビット：マイナー・バージョン、一般に０
１ビット：ＦＥＣフラグ（イネーブル：１；不使用：０）
１ビット：スーパーフレームフラグ（Ｄｉｖｅｅｍｏ論理フレームに関して算出されたＦＥＣ：０；３または４のＬＦ、すなわち、１つのＤＲＭ送信スーパーフレームに関して算出されたＦＥＣ：１）
９ビット：仮想インターリービングのための行数（０〜５１１；ＦＥＣフラグ＝０である場合だけ０）
ｎｘ８ビット：１つ又はそれ以上のＡＵコンフィグ・ブロック（ＡＵ Ｃｏｎｆｉｇ Ｂｌｏｃｋｓ）（下記参照）

各ＡＵコンフィグ・ブロック：
５ビット：バイトでのコンフィグ・ブロック長
３ビット：ＡＵストリームＩＤ（同じコンテンツタイプを運んでいるアクセスユニットの仮想ストリームを識別するために自由に選択される；それは０〜７から値をとることができ、その一方で、「７」はパディング・データを運ぶために確保される）
３ビット：コンテンツタイプ（０：ビデオ、１：音声、他の値：ｒｆａ）
５ビット：コーデックＩＤ（下記参照）
ｎｘ８ビット：コーデック仕様コンフィグ（Ｃｏｄｅｃ Ｓｐｅｃｉｆｉｃ Ｃｏｎｆｉｇ）（下記参照）

任意のＭＰＳオーディオによるＨＥ ＡＡＣ ｖ２のためのコーデック仕様コンフィグ、コーデックＩＤ ０ｘ００（コンテンツタイプ１）
１ビット：ＳＢＲフラグ
２ビット：オーディオモード（ＤＲＭシステムを参照）
３ビット：オーディオ・サンプリングレート（ＤＲＭシステム参照）
２ビット：ＭＰＥＧサラウンド（０：なし、１：５．１、２：７．１、３：バンドで）

Ｈ．２６４／ＡＶＣビデオのためのコーデック仕様コンフィグ：コーデックＩＤ ０ｘ００（コンテンツタイプ０）
２ビット：アスペクト比（０： ４：３、１： １６：９、他の値：ｒｆａ）
１１ビット：フレームごとの水平画素数
１１ビット：フレームごとの垂直ピクセル数
８ビット：１／４ステップにおける毎秒フレーム数

当然、ちょうど概説された実施形態は、単に図示しているだけであり、そして、他のコードおよび値は、同様に、または、今後、使用されうる。

Ｄｉｖｅｅｍｏは、ＤＲＭによるビデオ・サービスを可能にするというアイデアを利用するための実施形態を形成する。ビデオ・サービスは、ＤＲＭ標準、すなわち低い利用可能ビットレート、ＤＲＭコンプライアンス・サービス信号送信およびコンフィギュレーション、ＤＲＭにより供給された送信構造を有するコンプライアンス、受信誤りの効果的な処理などに適合されなければならない。

Ｄｉｖｅｅｍｏ定義のための可能な考慮／フレームワークは、信号送信がＳＤＣエンティティ５（新しいデータ・アプリケーションタイプ『Ｄｉｖｅｅｍｏ』）として実行されることができること、および、送信が同期データ・ストリームとして実行されることがあった。

以下の拘束条件が、満たされる必要がある。固定のフレーム長４００ｍｓ（ＤＲＭ３０）／１００ｍｓ（ＤＲＭ＋）、および、ＤＲＭ３０：１〜３５９８ｂｐｆ（７１．９６０ｂｐｓ）またはＤＲＭ＋：１〜２３２５ｂｐｆ（１８６．０００ｂｐｓ）の範囲の固定のバイト／フレーム（ｂｐｓ）：。コンテンツフォーマット（Ｃｏｎｔｅｎｔ Ｆｏｒｍａｔｓ）を定める際の以下の拘束条件／要求事項が、満たされる必要がある。チャネルの中のオーディオ／ビデオビットレートの可変および動的な割り当て。なんらかの最小バッファリング要件が存在しなければならない。オーディオおよびビデオ復号器は、いかなるフレキシブルなアクセスユニットサイズ（ビットレート相等物）を受けなければならない。ビデオ復号器は、『いかなる』（動的な）フレームレートも処理できなければならない、すなわち、符号器がコンテンツに動的に合わせうる。ビデオ復号器は、Ｉフレーム（Ｉ―ｆｒａｍｅｓ）が、つなぎを使う（独立したＡＵにおいて送信する）ように、失ったフレームを処理することができなければならない。タイムスタンプは、ＡＵ（一般の基本的なクロックと関連するオーバーフロー・カウンタ）ごとに示されなければならない。

ＡＵの中でビデオコンテンツのために使用されうるフォーマットは、ビデオのためのＡＶＣ／Ｈ．２６４、および、オーディオのためのＨＥ―ＡＡＣ ｖ．２（＋Ｓｕｒｒｏｕｎｄ）又はやがて公開されるＭＰＥＧスタンダードＵＳＡＣ（「統合された音声およびオーディオコーデック（Ｕｎｉｆｉｅｄ Ｓｐｅｅｃｈ ａｎｄ Ａｕｄｉｏ Ｃｏｄｅｃ）」）である。より新しい／より効率的なコーデックが、後に可能であるかもしれない。

ＤｉｖｅｅｍｏをＤＲＭに適用するときのアクセス遅延の合計は、以下の要因から生じうる。ＤＲＭ受信遅延（ＦＡＣ／ＳＤＣ復号、ＭＳＣインターリーバ、その他）、Ｄｉｖｅｅｍｏ ＦＥＣ（インターリーバ）（任意）、ビデオコーデックの（第１のＩフレームを受信するための）ＧｏＰサイズ。

更に、Ｄｉｖｅｅｍｏによってビデオを送信するときに考慮されなければならないビデオ・パラメータがあり、それは、Ｉフレームがビットレートの最高５０％をとること（受信誤りのために重要である）、前方向予測のみが、安定度の理由のために使用されなければならないこと、そして、（符号器によって）フレームレートは動的に適用されることである。

前述のタイムスタンプに関して、以下の考慮がなされなければならない。オーディオおよびビデオのための共通クロック基部は、使用されなければならない。典型的フレームレートを有する１／３ｍｓの最大ジッタが（例えば１５ｆｐｓ）結果として生じるように、１ｍｓの精度を有する基本的なクロックは、より良い妥協であるために継ぎ合せる。ＡＵごとにクロック・カウンタのための１６のビットは、ＯＫである必要がある（約６５秒の循環）。

Ｄｉｖｅｅｍｏ受信器が直面する表示始まり遅れは、最大１ｘＧｏＰ時間（ｉフレームの第１ビットの後で調整された）＋１ｘ ＧｏＰ時間（後に続くｉフレームの送信）である。

更に、下に説明されるＤｉｖｅｅｍｏ実施形態を実施するときに、以下のことが考慮されなければならない：最初の同期で、受信器は、アクティブであるｉフレームフラグ（→ＧｏＰの第１のビデオＡＵおよび対応するオーディオＡＵ）を有するＤｉｖｅｅｍｏヘッダエントリを待つことを必要とする。冗長度を加えるために、Ｄｉｖｅｅｍｏヘッダは、ＭＳＣ―ＬＦの最後でミラー化できる。受信器が２つのコピーを完全に比較することによってか、または、または、ＭＳＣ―ＬＦの端で、各エントリの第１のバイトを含むＤｉｖｅｅｍｏヘッダ＋ＣＲＣのまさに第１のバイトを比較することによって、容易に、壊れたエントリを訂正することができる。各ＡＵは、そのＡＵストリームＩＤによって定められうる。ＡＵストリームＩＤ７は、ＡＵコンテンツの連続したストリームでパディング・バイトを運んでいる仮想ＡＵデータを説明するために使用されうる。ＡＵごとのタイムスタンプ値は、上記のように、１ｍｓの精度に（すなわち、１６が６５秒にわたっている）に基づくことがありえる。

さまざまなＤｉｖｅｅｍｏ復号のフローチャートは、図７ａ〜図７ｍに関して説明される。これらの図に関して説明されるＤｉｖｅｅｍｏ復号は、再生器５４によって実行されうる。図７ａ〜７ｍの中で、復号は、概して２つの異なる種類に分けられる。第１に、短くすれば、ＤＬＦ復号と呼ばれている「Ｄｉｖｅｅｍｏ論理フレーム」復号が説明される。第２に、短くすれば、ＤＳＦ復号と呼ばれている「Ｄｉｖｅｅｍｏスーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）」復号が説明される。

ＤＬＦ復号において、ＦＥＣが１つのＬＦにわたって実施されるように、実際の復号が始まる前に、１つの論理フレーム（ＬＦ）がバッファされる。ＤＳＦ復号において、標準によって、ＦＥＣが３つまたは４つの論理フレームにわたって実施されるように、実際の復号が始まる前に、３つまたは４つの連続した論理フレームがバッファされる。

第１に、アクセスユニットストリーム再生器５４は、いくつかのＳＤＣパラメータ、すなわち、全部の論理フレームがＦＥＣによって保護されるかどうかに関して示しているＦＥＣフラグ（ＦＥＣＦ）、および、論理フレームがスーパーフレームにまとめられるかどうかに関して示しているスーパーフレームフラグ（ＳＦＦ）、その場合には上記ＤＳＦ復号が使用され、仮想インターリーバの行数、すなわち、すでに上で示したＲなどのような送信信号３８内の補助チャンネルパラメータを読み込む必要がある。これらのサービス・パラメータに基づいて、アクセスユニットストリーム再生器５４は、それから、図７ａ〜図７ｍに関して以下に説明される復号プロセスを開始する。

図７ａに示されるように、再生器５４は、断続的に、すなわち、ＤＬＦではすべてのＬＦ、ＤＳＦではすべてのＳＦが、始まりが図７ａに示されるステップを実行する。この開始では、１５０に示されるように、再生器５４は、送信信号３８の補助チャネル情報、すなわち、そのＳＤＣ部分についての、すなわち、ＳＤＣパラメータＦＥＣＦ、ＳＦＦおよびＲについての情報を有する。そのプロセスは、再生器５４がステップ１５２においてＦＥＣＦがＦＥＣ保護が使用されるという信号を送るかどうかに関してチェックすることで始める。「はい」の場合は、前処理器１６は、論理フレームの内容を保護するためのＦＥＣデータ６６を有するトランスポートパケットに、論理フレーム２０を埋込んだ。スーパーフレーム・グループ化が使用される場合、トランスポート層ストリームのＦＥＣコードは上記の通りに連続した３つまたは４つの論理フレームにわたって定められる。ＦＥＣＦがイネーブルである場合、ＦＥＣを用いた復号が１５４で起こり、イネーブルでなければ、ステップ１５６でＦＥＣなしでの復号が起こる。それぞれ、ステップ１５４および１５６に関する詳細は、図７ｂおよび図７ｉに関して説明される。

ステップ１５６でＦＥＣなしでの復号は、図７ｂにおいて更に詳細に示される。１５８に示されるように、プロセス１５４におけるＦＥＣなしで論理フレームを復号するプロセスは、前の論理フレームの復号から分かるアプリオリ情報から始める。この情報は、ＣＡＵＢと呼ばれている。ＣＡＵＢ情報は、特に、ＣＡＵ、すなわち、キャリー・オンＡＵ（ｃａｒｒｙ−ｏｎ ＡＵ）、すなわち、開始部分３２が現在考慮中の論理フレーム２０の前の論理フレーム２０にあるアクセスユニットを復号する際に再生器５４を助ける変数からなる構造である。以下の略記は、以下の記載において使用されて、ＣＡＵＢ情報から分かる。
ＡＵ：アクセスユニット、以下では、略記ＡＵは、ＣＡＵに反して、開始部分が現在のＬＦで始まるＡＵを示すために使用される
ＣＡＵ：キャリー・オンＡＵ（Ｃａｒｒｙ−ｏｎ ＡＵ）；
ＣＡＵＦ：ＣＡＵフラグ、すなわち、現在のＬＦの中に及んでいるキャリー・オンＡＵが存在していること、又は、存在していないことを示しているフラグ
ＰＣＡＵＢ：現在のＬＦおよび前のＬＦとの間の境界の前にＣＡＵのバイト、すなわち、すでに読み込まれたＣＡＵのバイトを示している、部分的ＣＡＵバイト（Ｐａｒｔｉａｌ ＣＡＵ Ｂｙｔｅｓ）。
ＬＰＣＡＵＢ：ＰＣＡＵＢの長さ、すなわち、ＰＣＡＵＢのバイト数又は長さ
ＣＡＵＳＩＤ：ＣＡＵストリームＩＤ（ＣＡＵ Ｓｔｒｅａｍ ＩＤ）、すなわち、ＣＡＵのＡＵストリームＩＤ値。
ＣＡＵＬ：ＣＡＵ長さ、すなわち、ＣＡＵの長さ、すなわち、前の論理フレームの中で各アクセスユニットテーブルエントリの長さ表示によって示された、図１の長さ６２
ＣＡＵＣＢ：ＣＡＵＣＲＣビット、すなわち、上述の拡張セクションの中で送信されたＣＡＵの中で前方向誤り検出を可能にするためのＣＲＣビット。

他の値は、ＣＡＵＢ情報、例えばＡＵコンテンツタイプ、ＡＵタイムスタンプ、ＬＦ内の拡張フラグの値などにも属しうる。

図７ｂのステップが再生器５４によって実行される限り、ＣＡＵＢ情報は変化しないままである。

ステップ１６０において、再生器５４は、図３に示されない再生器５４の内部バッファに、次の論理フレーム、すなわち、現在の論理フレームを読み込む。次のステップ、すなわち、ステップ１６２において、再生器５４は、図７ｃにおいて更に説明されているこのステップを有するアクセスユニットに、この論理フレーム２０を復号する。次に、アクセスユニットストリーム再生器５４は、ステップ１６４のこのようにして復号されたアクセスユニットをバッファして、ステップ１５８でさらにまた処理を始めるために、ステップ１６６のＣＡＵＢ情報を更新する。

アクセスユニットに現在の論理フレームを復号するプロセス、すなわち、ステップ１６２は、図７ｃに示すように、再生器５４が、２つのこと、すなわち、ＬＦバイトすなわち現在の論理フレームのバイトとＣＡＵＢ情報を知ることから始める。論理フレーム２０のバイト数は、固定される、または、そうでなければ、例えば、送信信号３８の前述の別々の補助情報チャネルの中の各補助情報の信号伝達によって変動するように示される。ステップ１７０において、再生器５４は、ＬＦヘッダおよびそのＣＲＣを読み込む。ステップ１７２において、再生器５４は、ＣＲＣがＬＦヘッダ情報、すなわち、論理フレームヘッダ２２の中に含まれたアクセスユニットテーブルエントリの数だけでなく拡張フラグと一致するかどうかに関して、ＣＲＣをチェックする。ＣＲＣがステップ１７２において一致しない場合、再生器は、ステップ１７４において、ＣＡＵがあるかどうかに関してチェックする、すなわち、再生器５４は、開始部分が前の論理フレームのいずれかにあるアクセスユニットがあり、一方で、このアクセスユニットの最後が到達されていないことを示しているかどうかに関して、内部のＣＡＵフラグをチェックする。ＣＡＵがあれば、再生器５４は、ステップ１７６においてＣＡＵバイトの復号を実行する。ステップ１７６は、図７ｅにおいて更に説明される。しかしながら、ＣＡＵフラグがステップ１７４においてイネーブルでないことが判明した場合、再生器５４はステップ１７８へ進む。ここで、現在の論理フレームは破棄される、または、より優先される。そして、この場合は、ここで考慮され、ＡＵテーブルエントリＣＲＣを評価することにより、有効なＡＵＴエントリを見つけることによる復号ＡＵテーブルエントリ（Ｄｅｃｏｄｅ ＡＵ Ｔａｂｌｅ Ｅｎｔｒｉｅｓ）およびＡｕバイトトライアルにゆだねられ、そのプロセスは、図７ｂのステップ１５８へループする。ステップ１７８は、図７ｆ〜図７ｇのプロセス部分の連結に対応する。類似して、点線によって示されるように、ＬＦの利用がステップ１７６の後にストップしうるが、再生器５４がステップ１７６の後に、実際に現在のＡＵＴエントリの演繹的な（ＬＦヘッダの破損のため）知られていない数からできるだけ多くのＡＵＴエントリを再生しようとすることを始めることはまた可能である。

しかしながら、ステップ１７２におけるＣＲＣチェックが、ＣＲＣ情報およびＬＦヘッダ情報との間で結果として一致する場合、再生器５４は、現在の論理フレームの後の部分から情報を抽出しようとすることを始める。特に、１８０に示されるように、ＣＲＣがステップ１７２において一致する場合、再生器５４は、加えて、現在の論理フレーム２０の正しく送信された論理フレームヘッダ２２において供給された少なくとも２つの情報項目、すなわち、現在の論理フレームのアクセスユニットテーブルのアクセスユニットテーブルエントリの数、および、拡張フラグＥＦの値についての情報を利用する。現在の論理フレームのアクセスユニットテーブルの範囲内でアクセスユニットテーブルエントリの数についての情報から結果として、再生器５４は、ＴＡＵＢ、すなわち、アクセスユニットバイトの全体数（ｔｈｅ ｔｏｔａｌ ｎｕｍｂｅｒ ｏｆ ａｃｃｅｓｓ ｕｎｉｔ ｂｙｔｅｓ）を得ることが可能である。ＥＦについての情報から結果として、再生器５４は、前述の拡張セクション６８の存在または不存在について知る。特に、ステップ１８２で、再生器５４は、すべてのアクセスユニットテーブルエントリに共通の一定の長さを、論理フレームヘッダ２２に示されるアクセスユニットテーブルエントリの数に乗算することによって、ＴＡＵＢを算出する。その後で、ステップ１８４において、再生器５４は、プロシージャが図７ｄに関して更に詳細に概説される現在の論理フレームの有用なデータセクション２４内のバイトを復号する。

このように、図７ｃに示されるプロシージャ部分は、３つのケースを作りだす。
ａ）ＬＦヘッダは、正しく復号可能であり、したがって、アクセスユニットは復号されることになっている
ｂ）ＬＦヘッダは、復号可能ではなく、したがって、アクセスユニットは復号されることができないが、ＣＡＵは存在し、復号されうる
ｃ）ＬＦヘッダは、復号可能ではなく、したがって、アクセスユニットは復号されることができないが、有効なＡＵＴエントリを発見する試みが実行されうる。加えて、ＣＡＵも存在せず、それ故、復号されない。

有用なデータセクション２４の中のＬＦアプリケーション・バイトの復号は、図７ｄに関して次に説明される。このプロセスセクションに入るときに、再生器５４は、１８６で示すように、ＬＦバイト、すなわち、論理フレームのバイト、ＣＡＵＢ情報、ＥＦ、ＴＡＵＥ、すなわち、アクセスユニットテーブルエントリの合計、および、ＴＡＵＢ、すなわち、アクセスユニットテーブルのバイトの合計についての情報を持つ。再生器５４は、ＣＡＵがあるかどうかに関してチェックするために、ステップ１８８でＣＡＵＦをチェックする。ＣＡＵがあれば、再生器５４は、ステップ１９０において現在のＬＦの中のＣＡＵバイトを復号し、そのステップは、図７ｅに関して更に下で説明される。ステップ１８８または１９０の後、再生器５４は、アクセスユニットテーブルエントリの数がゼロであるかどうかに関してＴＡＵＥをチェックするために、ステップ１９２へ進む。この数がゼロである場合、すなわち、現在の論理フレームの中のアクセスユニットテーブルがない場合、図７ｅのプロセスは終わる。しかし、ゼロでない場合は、再生器５４が、ステップ１９４においてＡＵテーブルエントリを復号し、ステップ１９６においてＬＦの有用なデータセクションからアクセスユニットバイトを復号する。ステップ１９４は、図７ｆに関して更に説明され、そして、ステップ１９６は図７ｇに関して更に説明される。図７ｄのプロセス部分の終わりに、再生器５４は、１９８に示されるように、最新のＣＡＵＢ情報についての情報を有し、アクセスユニットのバッファされたバージョンを有する。

このように、図７ｄのプロセス部分は、生じうる以下のケースに関係する。
ａ）論理フレームの有用なデータセクション２４の中のＡＵデータは、ＣＡＵとＡＵの両方を含む。
ｂ）現在の論理フレームの有用なデータセクション２４の中のＡＵデータは、ＣＡＵだけを含む。または、
ｃ）現在の論理フレームの有用なデータセクションの中のＡＵデータは、ＡＵだけを含む。

次に、ステップ１７６および１９０のＣＡＵバイトの復号は、図７ｅに関して更に詳細に説明される。このプロセス部分の始めに、再生器５４は、２００に示されるように、すでに、ＬＦバイトについての情報、すなわち、現在の論理フレームの中のバイト数、および、ＣＡＵＢ情報を有する。始めに、再生器５４は、ステップ２０２でＣＡＵデータを読み込み始める。再生器５４は、論理フレームヘッダ２２の一定の長さ、および、任意のＦＥＣデータセクション６６の存在（ＦＥＣＦを参照）とその一定の長さについての情報によって、この開始点が論理フレームにわたって時間に関して一定であるので、ステップ２０２における読み込みが始まることになる現在の論理フレームの有用なデータセクションの開始部分を見つけることができる。特に、ステップ２０２において、再生器５４は、ＣＡＵ、すなわち、前の論理フレームから現在の論理フレームに達しているアクセスユニットに属するのと同程度の現在の論理フレームの有用なデータセクション２４の開始部分から多くのビットを読み込もうとする。２つのケースが起こりうる。第１に、再生器５４は、現在の論理フレームの有用なデータセクションの終わりの前に、ＣＡＵの終わりに出会う。第２に、再生器５４は、ＣＡＵの終わりの前に、現在の論理フレームの有用なデータセクション２４の終わりに出会う。再生器５４は、２つの情報、すなわち、ＣＡＵＬすなわち前の論理フレームのいずれか、特にその中の各アクセスユニットテーブルの各アクセスユニットテーブルエントリから分かったＣＡＵの長さ、および、拡張セクション６８の存在又は不存在について（拡張フラグ参照）とこの情報がアクセスユニットテーブルがない場合には論理フレームのために利用できるバイトの最大数を定めるので、ＡＵＴに対して位置合わせされたセクション６８の長さを示しているこのセクション内に所定の位置から導き出されるようなこのセクションの長さについての情報に沿った論理フレームのバイト数に基づいて状況を予測することが可能である。ＣＡＵビット、すなわち、その部分の開始部分からの有用なデータセクションの部分を読み込んだ後に、再生器５４は、ステップ２０４において、ＬＰＣＡＵの内部状態、すなわち、これまでに論理フレームのシーケンスからすでに取り出されているＣＡＵの部分の長さを更新する。ステップ２０６において、再生器５４は、ＬＰＣＡＵがＣＡＵＬと等しいかに関して、すなわち、これまでに全部のＣＡＵが論理フレームのシーケンスから取り出されたかどうかに関してチェックする。ＣＡＵと等しくない場合には、ＣＡＵは、次の論理フレームに及び続け、再生器５４は、ステップ２０８において、ＣＡＵＢ情報の中のＰＣＡＵＢおよびＬＰＣＡＵＢを更新する、すなわち、現在の論理フレームを含んでいる論理フレームのシーケンスから既に取り出されているＣＡＵの部分に関する情報を更新する。しかし、ステップ２０６におけるチェックは、ＣＡＵが完全に論理フレームのシーケンスから取り出されたこと、すなわち、ＣＡＵの終わりが現在の論理フレームの有用なデータセクション２４に入ることを明らかにする場合、再生器５４は、ステップ２１０において、ＣＡＵに関するＣＲＣ情報が、ＣＡＵの開始部分が始まる論理フレームの中の各ＡＵテーブルエントリ６４から導き出され、ＣＡＵのためにこれまでに取り出され、バッファされたＣＡＵビットと一致するかに関してチェックする。これがそうであれば、再生器５４は、ステップ２１２において、復号されたＣＡＵユニットをバッファし、ステップ２１４において、ＣＡＵが現在もはや存在しない範囲に関してのＣＡＵＢ情報のパラメータをリセットする。しかしながら、ステップ２１０におけるＣＲＣチェックが、論理フレームのシーケンスから取り出されているＣＡＵビットが破損していることを明らかにする場合、再生器５４は、ステップ２１６のこのアクセスユニットＣＡＵを廃棄して、図７ｅのこのプロセス部分が終わるステップ２１４に進む。あるいは、再生器５４は、誤りであるとしてステップ２１６においてＣＡＵに印をつけ、それをプレゼンター５６に引き渡しうる。そして、それは、次に、例えばＡＵの内部ＦＥＣまたはＣＲＣデータ等の他の手段によって、または、破損したＣＡＵＣＲＣにより誤りであるとして印を誤って付けられたＡＵをうまく解析することによって、誤ったＡＵから有用な内容を引き出すように構成されうる。

このように、図７ｅは、３つの異なるケースについて述べた。すなわち、
ａ）ＣＡＵは、例えば、ＬＦ番号ｎを有している前の論理フレームにおいて始まり、例えば、番号ｎ＋１を有している現在の論理フレームで終わる。ここで、ＣＡＵＣＲＣは、ＣＡＵバイトと一致する、すなわち、ＣＡＵバイトが論理フレームのシーケンスから正しく取り出された。
ｂ）ＣＡＵは、例えば番号ｎを有する論理フレームなどの前の論理フレームのいずれかで始まり、例えば番号ｎ＋１を有している現在の論理フレームで終わり、そして、ＣＡＵＣＲＣは、ＣＡＵバイトが一致しない、すなわち、ＣＡＵのために取り出されていたバイトまたはＣＡＵＣＲＣの値が破損している。
ｃ）ＣＡＵは、論理フレーム番号ｎを有している論理フレームなどの前の論理フレームのいずれかにおいて始まり、しかし、このＣＡＵは、例えばＬＦ番号ｎ＋１を有している現在の論理フレームを超えて及び、例えば論理フレーム番号であるＬＦ番号ｎ＋２を有している次の論理フレームに及び、おそらくその中で終える。

ステップ１９４のアクセスユニットテーブルエントリを復号し、潜在的にステップ１７８の有効なＡＵＴエントリに対応するＬＦの部分を検査するプロセス部分は、図７ｆに関して以下で更に詳細に述べられる。ステップ１９４からこのプロセス部分に入るときに、再生器５４は、２１８に示されるように、ＴＡＵＥ、すなわち現在の論理フレーム内のアクセスユニットテーブルエントリの数と、ＬＦバイト、すなわち現在の論理フレームのバイトについて知っている。ステップ１７８からこのプロセス部分に入るときに、再生器５４は、ＡＵＴエントリの数を示すためのただ一定の数、ここでは例として７ビットをかけているＦＬヘッダによる）現在のケース１２８における、論理フレームの中のアクセスユニットテーブルエントリの最大に可能な数にＴＡＵＥを設定しうる。

図７ｆのこのプロセス部分内で、再生器５４は、ステップ２２０において、内部計数値、すなわち、ＲＡＵＥ、すなわち、残りのアクセスユニットエントリの数を、ＴＡＵＥ、アクセスユニットエントリの合計数と等しくするために、初期化することで始まる。もちろん、計数値を減らす代わりに、１で始まる計数値によって、処理されたエントリをカウントすることが可能だろう。

ステップ２２２において、ＲＡＵＥがゼロであるかに関して、すなわち、残された読み込まれるべきアクセスユニットテーブルエントリがないかどうかに関して、チェックした後、そのプロセスは、現在の論理フレームとそのアクセスユニットテーブルからそれぞれ読み込まれるべき残りのアクセスユニットテーブルエントリがある場合には、ステップ２２４に進む。ここで、再生器５４は、ＡＵＴＥＢ、すなわち、一列のアクセスユニットテーブルエントリに対応しているバイト、および、ＡＵＴＥＣＢ、すなわちそれに対応しているアクセスユニットテーブルエントリＣＲＣビットを読み込む。上ですでに説明されたように、再生器５４がアクセスユニットテーブルエントリ６４にアクセスする順番は、開始部分３２がこれらのアクセスユニットテーブルエントリ６４に示されるアクセスユニットの順番に対応している論理フレームの後端７０から前端７２の方向である。ステップ２２４の後、再生器５４は、ステップ２２６において、現在の論理フレームから取り出されたアクセスユニットテーブルエントリデータが破損されているかどうかに関してチェックするために、ステップ２２４でちょうど読み込んだアクセスユニットテーブルエントリのＣＲＣをチェックする。そうである場合、すなわち、データが破損している場合、再生器５４は、各アクセスユニットテーブルエントリ６４を破棄して、ステップ２２８の破棄を示している対応するフラグをセットする。あるいは、再生器５４は、少なくとも部分的に他の手段によって無効な情報を再構築しようとしうる。例えば、再生器５４は、（例えば、セクション２４への有用なデータのシームレスな挿入を仮定して）ＡＵ長さからＡＵオフセットを予測またはその逆をしようとしうる。そして、予測結果によって交換されるＡＵテーブルエントリの各予測された部分を用いてＣＲＣチェックをやり直す。この方法によって、再生器５４は、データ破損にもかかわらず、対応するＣＲＣと一致する正しいＡＵテーブルエントリを得ることができる。

現在のアクセスユニットテーブルエントリ６４のためのＣＲＣが、対応するデータと一致する場合、再生器５４は、ステップ２３０において、現在のアクセスユニットテーブルエントリ６４を解釈し、それを保存する。ＣＲＣ一致ケースが、再生器５４がちょうど有効なＡＵＴエントリ６４を見つけたという表示でもあることは強調されなければならない。言い換えれば、ステップ２２６を実行して、ステップ１７８から図７ｆのプロセス部分に入ったときに、再生器５４は、（ＡＵテーブルがＬＦ端に位置合わせされ、ＡＵテーブルエントリが一定ピッチで位置決めされることを利用することにより見つけられた）ＬＦの現在検査された部分が実際に有用なデータセクション２４、あるいは拡張セクション６８あるいはＡＵＴ３０の部分をそれぞれ形成するかに関して前もって知っていない。再生器５４は、ＬＦの現在検査された部分をＡＵＴエントリ６４として解釈するために、充分なチェック結果として、ＣＲＣ一致を使用することができる。あるいは、再生器５４は、現在のあり得るＡＵＴエントリが、ＬＦヘッダが破損していた場合に、有効である又は無効であるとどちらにみなされるかに依存して、例えば信頼性チェックなど追加のテストを実行しうる。例えば、ちょうど明らかになったＡＵＴエントリ６４のＡＵの開始部分３２は、先のＡＵの端の後に位置するべきであり、反対に、ちょうど明らかになったＡＵＴエントリ６４のＡＵの端がその後のＡＵの端の前に位置するべきである。したがって、信頼性チェックのいずれかが結果として否定したものであった場合、現在の推定上のＡＵＴエントリは排除されて、無効であるとみなされる。

ステップ２３０の後、再生器５４は、任意でその長さ６２についてと同様に、現在のアクセスユニットテーブルエントリ６４と関連した対応するアクセスユニットの開始部分３２について知っている。アクセスユニットテーブルエントリ６４の更なる内容に関して、参照は、この種の付加的なオプションについての上記を参照されたい。ステップ２２６におけるＣＲＣ整合チェックにかかわりなく、再生器５４は、ステップ２３２におけるステップ２２８及びステップ２３０のいずれかの後に１まで内部カウンタ状態ＲＡＵＥを減少させ、ステップ２２２へループする。このチェック２２２が、現在の論理フレームのアクセスユニットテーブル３０から取り出されるアクセスユニットテーブルエントリ６４の残りの数がゼロであることを明らかにするとすぐに、図７ｆのプロセス部分は、再生器５４がアクセスユニットテーブル３０の内部複製、すなわち、ステップ２３４で示したようなアクセスユニットテーブルエントリ構造を埋めたことで終了する。

換言すれば、図７ｆのプロセス部分は、アクセスユニットテーブルが現在の論理フレーム内に存在する、すなわち、アクセスユニットテーブルエントリ６４が存在する場合に、または、ＡＵＴエントリの有無（および数）がわかっていないので、ＡＵＴエントリ６４が存在するかどうかに関して判断するために、再生器５４で始まる。この場合に、たとえば、再生器５４が図７ｆのプロセス部分に入ることができないように、ＣＡＵが全部の論理フレームを取りうることはありえる。以下の異なるケースは、図７ｆのプロセス部分において想定される。
ａ）現在のアクセスユニットテーブルエントリおよびそのＣＲＣが一致する（そして、すべての信頼性チェックで合格した）
ｂ）現在のアクセスユニットテーブルエントリおよびそのＣＲＣが一致しない（または、信頼性チェックで失敗する）
ｃ）すべてのアクセスユニットテーブルエントリ（ＬＦヘッダから存在することが知られた全てのエントリ、または、（ＬＦヘッダの破損による）単に推定の上で現存するだけのＡＵＴエントリ）は、ＣＲＣが一致しているか否かにかかわりなく（ケースａ及びケースｂ）処理された。そこにおいて、状況ｃは、図７ｆのこのプロセス部分のための出口でもある。

破損している又はしていない現在の論理フレームの同上のアクセスユニットテーブルの前のアクセスユニットテーブルエントリのいくつかとは関わりなく再生器５４がＡＵＴＥＢおよびＡＵＴＥＣＢを読み込むことができる理由は、全てのアクセスユニットテーブルエントリが同じサイズであること、および、アクセスユニットテーブル３０が再生器５４がアクセスユニットテーブルエントリを見つけることができるように現在の論理フレームの後ろの端７０にその後端によって位置合わせされることであることに留意されたい。変形例があることは、すでに前述している。

更に、アクセスユニットテーブルおよび現在の論理フレームがそれにより供給される付加的な冗長データのため、アクセスユニットテーブルエントリ個別のデータ破損チェックが可能であって、復号側でエラーなしで送信されたアクセスユニットテーブルエントリは、他のアクセスユニットテーブルエントリのいずれかを送信する際の成功または棄却から独立して再生器５４によって評価されうる。

次に、図７ｇに関して、ステップ１９６または１７８においてＡＵバイトの復号の詳細が説明される。このプロセスセクションに入るときに、再生器５４は、以下の情報、ＴＡＵＥ、すなわちアクセスユニットテーブルエントリの合計数、ＡＵＥ情報、すなわち前の論理フレームと同様に現在の論理フレームのアクセスユニットテーブルエントリの内容、ＣＡＵＢ情報、ＬＦバイト、および、ＴＡＵＢ、すなわち開始部分３２が現在の論理フレームが始まるアクセスユニット２８のための現在の論理フレームの有用なデータセクション２４において現在の論理フレームの利用可能なバイトの合計数を認識しており、この前情報所有は、２３６で示されている。再生器５４は、以下の理由のためＴＡＵＢについて知っている。再生器５４は、開始部分が現在の論理フレーム２０の中に含まれるアクセスユニットに関係しているアクセスユニットデータが、論理フレーム２０の前端７２に最も近い開始部分３２から及ぶことを知っている。これは、それはデータ破損なしでおよび図７ｆのプロセス部分において最も始めの時間に関して受信された、または、破損しているがＤＳＦ若しくはＤＬＦ復号に関して後に説明されるようにＦＥＣによって得られたアクセスユニットテーブルエントリ６４のポインタ４０によって指し示された位置に対応する。有用なデータセクション２４の端は、論理フレームヘッダ情報、すなわち、セクション６８に面しているＡＵＴ３０の境界に直接隣接している（または代わりにそこから所定のオフセットを有している）このセクションの中のバイトから導き出されるものとしてのセクション６８の長さだけでなく、ＡＵテーブル３０に直接隣接しており、有用データセクション２４とアクセスユニットテーブル３０との間に配置されている拡張セクション６８の存在又は不存在についての表示（ＬＦヘッダ参照）に沿ったアクセスユニットテーブルエントリ６４の数に基づいて、再生器５４に知られる。後者の情報が利用可能でない場合、すなわち、ＡＵＴエントリの数もセクション６８の存在又は不存在も利用可能でない場合、再生器５４は、ＴＡＵＢを、有効に発見されたＡＵＴエントリのいくつかによって指し示された前述の最も左の開始部分３２、および、そして、最後、すなわち、この部分は単にＣＡＵを含んでいないので有効に発見されたＡＵＴエントリのいくつかによって指し示された最も右の開始部分３２に及んでいる有用なデータセクション２４のサブパートを測定するように制限しうる。

図７ｇのプロセス部分の始めに、再生器５４は、ステップ２３８において、２つの内部パラメータ、すなわち、ＲＡＵ、すなわち、図７ｇのプロセス部分においてまだ処理されていない残りのアクセスユニットの数、および、ＲＡＵＢ、すなわち、現在の論理フレームの有用なデータセクション２４からまだ読み込まれていない残りのＡＵバイトの数を初期化する。両方のパラメータは、ＴＡＵ、すなわち、この数が論理フレームヘッダから知られることによって、開始部分３２が現在の論理フレームに含まれるアクセスユニットの合計数、および、ＴＡＵＢにそれぞれ等しく設定される。ステップ２４０で、再生器５４は、ＲＡＵがゼロに等しいかに関して、すなわち、現在の論理フレームの中のその開始部分３２を残した処理されるべきアクセスユニットがあるかどうかに関して、チェックする。等しくない場合には、再生器５４は、現在の論理フレームの有用なデータセクション５４から現在のアクセスユニットのバイトを読み込むことにステップ２４２で進み、そのステップは図７ｈに関して下記で更に詳細に説明される。その後で、再生器５４は、現在のアクセスユニットに関連したＣＲＣがステップ２４２で読み込まれた現在のアクセスユニットに一致するかどうかに関してステップ２４４でチェックする。一致しない場合、再生器２４６は、ステップ２４６において現在のアクセスユニットを破棄する、または、すでに上で概説されたように、誤りとしてこのＡＵに印をつけ、更に処理／審理へとそれを渡す。しかしながら、ＣＲＣが現在のアクセスユニットと一致する場合、図７ｇのプロセスは、例えば、現在のデータ５６に同上を送るためのステップ２４８において、再生器５４が現在のアクセスユニットをバッファすることに進む。ステップ２４６および２４８のいずれかの後に、再生器５４は、ＲＡＵおよびＲＡＵＢの内部状態をステップ２５０において更新する。特に、ＲＡＵ、すなわち、処理されるべきアクセスユニットの数は、１にまで減少させられ、そして、ＲＡＵＢ、すなわち、有用なデータセクション２４において利用可能なアクセスユニットバイトの数は、更新される、すなわち、現在処理されたアクセスユニットのバイト数だけ減少させられる、または、有用なデータセクション２４の後端と処理される次のアクセスユニットとの差で異なっている。例外的な手段として、有用なデータセクション２４の端に遭遇するときに、再生器５４は、ＲＡＵＢをゼロにセットしうる。

ステップ２５０の後、図７ｇは、処理される残りのアクセスユニットと現在の論理フレーム内の開始部分を処理するために、ステップ２４０にループする。

ステップ２４０におけるチェックの結果としてＲＡＵがゼロに等しい、または、ＲＡＵＢがゼロに等しいとすぐに、再生器５４は、ステップ２５２に示すようにバッファされたうまく受信されたアクセスユニットを有する図７ｇのプロセス部分を終える。

図７ｇに関して、図７ｇの前記説明が、アクセスユニットテーブルエントリの数、すなわち、ＬＦヘッダによって示された最大の数又はそれにより正しく運ばれた数のいくつかが破損していてもしていなくてもよく、それに応じて、各フラグは図７ｆのステップ２２８においてセットされているという事実を無視したことに留意されたい。図７ｇの上記説明において、例えば、ＴＡＵが破損したアクセスユニットテーブルエントリのこの数まですでに減少させられ、その結果、ＴＡＵは、単に開始部分が現在の論理フレームの中に含まれ、関連したアクセスユニットテーブルエントリが使用可能／有効であったアクセスユニットの数を表すだけである。

図７ｇのプロセス部分の記載の中で、さらにまた、３つのケースに分化された。すなわち、
ａ）現在のアクセスユニットのための有用なデータセクション２４からの再組み立てされたＡＵ内容が、関連したＣＲＣと一致する、
ｂ）現在のアクセスユニットおよび関連したＣＲＣのための有用なデータセクション２４からの再組み立てされたＡＵ内容が一致しない、
ｃ）すべてのＡＵは処理された、または、有用なデータセクション２４のすべてのデータは処理された。そして、それは図７ｇのプロセスセクションのための終了条件である。

図７ｈにおいて、プロセス部分は、示されたように、ステップ２４２の現在のアクセスユニットのバイトを読み込むために再生器５４から入った。このプロセス部分に入るときに、再生器５４は、２５４に示されるように、以下の情報、すなわち、ＡＵＥ情報、ＣＡＵＢ情報およびＲＡＵＢを利用することができる。最初に、再生器５４は、ステップ２５６の現在のアクセスユニットの長さを関連アクセスユニットテーブルエントリから抽出する。ステップ２５８において、再生器５４は、ＡＵＬ、すなわち、現在のアクセスユニットの長さが、ＲＡＵＢ、すなわち、有用なデータセクション２４の中の残りのバイト数より大きいかどうかに関してチェックする。問い２５８に対する答えが「はい」である場合、再生器５４は、したがって、ＣＡＵＢ情報のパラメータを２６０においてセットする。特に、ステップ２６０において、再生器５４は、さらにＣＡＵ、すなわち、その後の論理フレームに及んでいるアクセスユニットがあることを示すために、ＣＡＵＦをセットする。ＬＰＣＡＵＢは、すでに現在の論理フレームから取り出されたＣＡＵのバイト数、すなわち、ＰＣＡＵＢの長さを意味する。ＣＡＵＬは、ＣＡＵの長さ６２、そして、ＣＡＵＣは、ＣＡＵのＣＲＣである。

しかし、現在のアクセスユニットが有用なデータセクション２４の残りの部分にはめ込まれる場合、再生器５４は、ステップ２６２において、その長さ６２、すなわちＡＵＬによって示されたように、現在のアクセスユニットの端まで現在のアクセスユニットのバイトを読み込む。その後で、再生器５４は、ＡＵバイトを更新する。

このように、以下のケースが、図７ｈにおいて分化された。
ａ）現在のアクセスユニットに対応するすべてのバイトは、現在の論理フレームから読み込まれうる
ｂ）現在のアクセスユニットの必ずしもすべてのバイトが、現在の論理フレームから読み込まれうるわけではない、すなわち、現在のアクセスユニットが続く、または、ＣＡＵになる。

図７ｉに関して、再生器５４によって実行されるプロセス部分は、ＦＥＣフラグがチェック１５２においてイネーブルされることが判明した場合のために示される。換言すれば、図７ｉは、ステップ１５４において、ＦＥＣに関する復号を例示する。この場合、再生器５４は、２６６で示されるように、フラグＳＦＦ、ＬＦバイトおよびＲへのアクセスを有する。ステップ２６８において、再生器５４は、ＳＦＦがイネーブルかどうかに関してチェックする。ＳＦＦがイネーブルの場合は、再生器５４は、ステップ２７０においてＦＥＣによるＳＦ復号に進み、イネーブルでない場合、ステップ２７２においてＦＥＣによるＬＦ復号に進む。ステップ２７２の第１のプロセス部分は、図７ｊに示される。２７４に示されるようにＣＡＵＢ情報について知っていることにより、再生器５４は、ステップ２７６で内部バッファに単一の論理フレームを読み込んで、ステップ２７８でその単一の論理フレームをＲＳ―ＦＥＣに従属させる。その後、図７ｃについて述べたようにステップ１６２においてちょうどなされたように、この論理フレームは、ステップ２８０のアクセスユニットに復号に従属する。その後、復号されたアクセスユニットは、ステップ２８２においてバッファされ、そして、ＣＡＵＢ情報は２８４で更新される。

すなわち、ＦＥＣによるＬＦ復号の場合には、現在の論理フレームは、さらに、アクセスユニットへの実際の論理フレーム復号が始まる前に、ＲＳ前方向誤り訂正／復号を通される。

ステップ２７８のＲＳ―ＦＥＣによる論理フレームを従属させることは、図７ｋにおいて更に例示される。特に、ＬＦバイトおよびＲについての情報に基づいて、２８６に示されるように、再生器５４は、ステップ２８８において、ＬＦヘッダオフセット、ＬＦＡＵデータオフセット、ＲＳオフセットおよびＲＳパリティビット＝１６＋ｘＲを設定し、ＲＳアプリケーション・テーブル９８およびＲＳパリティ・テーブル１０２を、それぞれ、ステップ２９０および２９２において埋める。Ｒがステップ２９４においてゼロに等しいかどうかに関してチェックした後に、再生器５４は、Ｒがゼロでない場合、ステップ２９６でＲＳ誤り訂正を行い、ステップ２９８でＲを減少させ、プロセスは、ステップ２９４へループする。チェックされたステップ２９４が、Ｒがゼロに等しいことを明らかにする場合、アプリケーション・データテーブル９８の中のＲＳアプリケーション・バイトは、ステップ３００のＬＦバイトを産生するためにデインターリーブされる面で読み出される。ＲＳ ＦＥＣが行Ｒを訂正するのに成功した場合、ＲＳ ＦＥＣは、訂正されたシンボルの数を戻して、訂正されたバイトを有する行を更新するように、そして、失敗した場合、マイナス１に戻して、行シンボルをそのままに保持するように構成されうる。しかし、他の実施態様もまた、可能である。更に、異なるＦＥＣコードは、使用されうる。

図７ｌは、図７ｉのステップ２７０におけるＦＥＣに関するＳＦ復号の詳細を示す。図に示すように、３０２に示されるように、ＣＡＵＢ情報を知っていると、再生器５４は、ステップ３０４において、３または４、または、別の実施形態によれば、他のいかなる数の連続した論理フレーム、すなわちスーパーフレームを、内部バッファに読み込み、そして、ステップ３０６におけるこのスーパーフレームＳＦをそれに関するＲＳ ＦＥＣに従属させ、図７ｃに関して説明されるようにＡＵの中にステップ３０８におけるＳＦの中の３つ／４つの論理フレームを復号し、ステップ３１０において復号されたアクセスユニットをバッファする。最後に、再生器５４は、ステップ３１２でＣＡＵＢ情報をアップデートする。図７ｋと同様に、図７ｍは、ＳＦをＲＳ ＦＥＣに従属させるケースを示す。図に示すように、３つ／４つ（または、より一般的には、ｎ個）の論理フレーム、すなわち、論理フレームのバイト、および、３１４に示されたようにＲの値にアクセスして、再生器５４は、ステップ３１６のセッティングを実行し、ＲＳアプリケーション・テーブルおよびステップ３１８および３２０のＲＳパリティ・テーブルをそれぞれ埋めて、ステップ３２２においてＲがゼロと等しいかどうかに関してチェックする。Ｒがゼロと等しくない場合には、再生器５４は、ステップ３２４でＲＳ誤り訂正を行って、ステップ３２２にループするためにステップ３２６でＲを減らす。Ｒがゼロに等しいとすぐに、再生器５４は、ステップ３２８において、ｎ個の論理フレームを得るために、インターリーブされたフォーマットのアプリケーション・データテーブル９８からＲＳアプリケーション・バイトを配置する。

最後に、図８および図９は、特定の更なる実施形態による再生器５４でのＦＥＣトランスポート保護処理の概要を示す。この実施形態によれば、３６００バイトに対応する１００行および３６列のテーブルは、構築される。実際に、ＬＦは、３５９８バイトを含むが、しかし、それは、説明を簡単にするため３６００バイトまで送受信器側で引き伸ばされる。すべてのバイトは、このテーブルに、以下の様式（１，１）、（２，１）…（１００，１）、（１，２）、（２，２）…（１０，１００）で列ごとに埋められる。このように、見かけのインターリービングを与える。アプリケーション列およびＦＥＣ列によって、リード・ソロモンＦＥＣの訂正能力は、テーブルの各行を復号するために決定され、使用される。我々はテーブルにおけるエラーの位置を知らないので、我々はＲＳエラー復号を使用しなければならない。いったんテーブルがＦＥＣ復号器に通されると、その出力は、完全に誤りのないバイトを含む場合もあり含まない場合もある。その両方の場合において、通常の復号は、連続的に使用される、すなわち、最初にＬＦヘッダの第１のバイトが復号され、それは、上記の１つと関連する別の実施形態によれば、ＬＦヘッダのサイズを我々に与え、成功した場合、完全なＬＦヘッダは復号されて、そのＣＲＣと比較される。ＬＦヘッダは、本実施形態によれば、ＡＵＴ情報を含むものとしてみなされ、個々のＡＵのために更に分析される。完全な復号器のフローチャートは、図８および図９にある。

このように、Ｄｉｖｅｅｍｏ実施形態は、以下の態様によって以下の効果を得る：

１．ＤＲＭシステムによってビデオ信号を符号化し、信号送信し、復号するための方法と装置
−バンド外信号
−バンドのデータ・アクセスの構成
−少なくとも一つの論理的データ・ストリーム
−オーディオ／ビデオ／データ（例えばサブタイトルのためのＪｏｕｒｎａｌｉｎｅ（登録商標））
−例えば、１ｘビデオ、５ｘオーディオ（異なる言語）
−オーディオおよびビデオのためにあらゆるコーデックは符号化可能（将来の拡張のための下位互換性）
−ＤＲＭ互換性（ＭＳＣ（ＳＤＣ標準一致）の中のフォーマッティング）
−効率的なビットレート使用（例えばスタッフィングなし）
−柔軟に設定可能（フレームレート、ビットレート、…）
−任意の故障保護（ＦＥＣ）、柔軟にパラメータ設定可能、仮想インターリービング、２回インターリーバ
−可能な限りの受信器の速い同期
−データ構造が、将来の拡張を可能にする−受信誤りに対するロバスト

２．デジタル・ラジオ・モンディエール（ＤＲＭ）システムによるビデオ信号の送信についての符号化および信号送信のための方法
−オーディオの、ビデオの、および、データのＡＵが、『直列ビットストリーム』として付加的なヘッダなしで送信される
−ＡＵおよびそれらの境界／長さの定義は、急速にアクセスおよび簡単な（再）同期を可能にするための放送方式（ＤＲＭ）の送信フレームの境界に関して位置合わせされる
−インデックスは、論理フレーム（ＬＦ）の中で、冗長に送信される
−ヘッダの欠陥の場合、復号器は、それでもなお、エンティティ定義／記述のチェーンを介してＡＵデータを抽出しうる
−ＡＵの、または、エンティティ定義／記述の欠陥の場合、単に個々のＡＵだけが失われ、必ずしも現在のＤＲＭ送信フレームのすべてのＡＵではない
−一つ又はそれ以上の（インターリーバされた）論理的データ・ストリームは、異なる長さのデータパケットに再分割される
−可能な限りのペイロード・データへの速い同期
−送信構造は、使用される（正方向ポインタ）
−供給される将来の拡張のための機構
−ＦＥＣパラメータは、送信誤差に適応できる
−インデックス内の、そして、データパケットの範囲内のエラー保護は、すべてのエラーのないペイロード・データの抽出を可能にする

前記実施形態、すなわち、Ｄｉｖｅｅｍｏ実施形態を含んでいる以下の実施形態と同様に、図１〜図３に関して最初に説明された実施形態をまとめると、論理フレームの前端／後端に関してアクセスユニットテーブルを位置合わせすることの１つの利点は、そのテーブルが復号器によって速く確実に見つけられることであり、そして、それらの長さが論理フレームの中のアクセスユニット開始部分の数に依存するが、埋め込まれているアクセスユニットの開始部分、すなわち、有用なデータセクションの開始部分は、例えば有用なデータ挿入方向に見るときに最後にアクセスユニットテーブルを配置することによって一定に保たれうる。ポインタは、論理フレームにおけるローカル・エラーが、分析され、使用されるためにエラーなしである他のアクセスユニットを妨げないように、絶対的な意味で、アクセスユニットの開始部分の位置を指し示す。アクセスユニットテーブルがなくなる場合、第１のキャリー・オンアクセスユニットは、そのアクセスユニットテーブルがその前端に配置されたときでさえ、完成されうる。そして、第１のキャリー・オンアクセスユニットが破損しており、したがって、このアクセスユニットの終わりおよび次のアクセスユニットの開始部分がシームレスな挿入にもかかわらずパースすることによって検出されない場合、次にアクセスユニットは、アクセスユニットテーブルのポインタは絶対的な意味、すなわち、静的である位置決め点から定義されるので、このアクセスユニットテーブルの正確な位置から独立しても、使用されうる。

さらに、アクセスユニットテーブルおよび論理フレームヘッダは、論理フレームの絶対的な開始部分又は絶対的な終わりに、または、その知られたオフセットで、位置合わせされて位置決めされるので、アクセスユニットテーブルおよび／または論理フレームヘッダは、その送信フレームに基づいて復号側によって容易におよび確実に見つけられる。たとえ両方とも、すなわち、アクセスユニットテーブルだけでなく論理フレームヘッダが、論理フレームの前端若しくは後端などの同じ端に関して位置合わせされたとしても、論理フレームヘッダおよびアクセスユニットテーブルのうちの少なくとも１つが上記実施形態と同様に一定の長さを有する場合、論理フレームの有用なデータセクションは見つけられうる。しかしながら、反対側に論理フレームヘッダおよびアクセスユニットテーブルを配置することによって、アクセスユニットの最適使用が可能である：論理フレームヘッダが破損している場合、有用なデータセクションの開始部分は、それでもなお、復号側で見つけられ、そして、現在のアクセスユニットは処理されうる。アクセスユニットテーブルが破損している場合、有用なデータセクションの端は、復号器で知られており、そして、おそらく、すべてのアクセスユニットはパージングによって再構築可能である。

アクセスユニットテーブルの中のアクセスユニット長さ情報を示すことの利点は、その上にある情報が、キャリー・オンアクセスユニットが破損していて、したがって通過できないとしても、次のアクセスユニット、すなわち、開始部分が現在の論理フレームの中に含まれる第１のアクセスユニットにアクセスするために、復号側で使用されうるということである。換言すれば、アクセスユニットのシームレスな挿入の場合には、このアクセスユニットの開始部分を指し示しているポインタが破損しているときでも、アクセスユニット長さ表示は、アクセスユニットにアクセスするのを助ける。パディングが必要である場合、このパディングは、特別に印を付けられたアクセスユニットタイプの形式でなされうる。そして、それは、通常のアクセスアクセスユニットタイプの他のアクセスユニットの中にシームレスに組み込まれ、その結果、シームレスな挿入は維持される。

アクセスユニットテーブルエントリのいくつかが破損している場合であっても、アクセスユニットテーブルエントリのＦＥＣ保護の上記可能性は、個別にアクセスユニットを処理することが可能である。このように、アクセスユニットテーブルの破損したエントリは、一定の長さのため、スキップされうる。そして、アクセスユニットテーブルのその後のエントリは、再生器によって問題なく評価されうる。これは、個別的なＣＲＣ保護の利点である。さらに、たとえＡＵＴエントリの数、または、その存在が分からなくても、有効なエントリが見つけ出されうる。

多くの修正は、前記実施形態に実行されうる。例えば、Ｄｉｖｅｅｍｏ実施形態の特定の詳細のための多くの変形例は、図１〜図３に関する記載から直ちに導き出せる。ＲＳ ＦＥＣに関して、他のＦＥＣコードが同様に使用されうる点に留意されたい。更に、ＬＦの中のＣＲＣの代わりに、ＦＥＣデータは、ＬＦに組み込まれうる。

いくつかの態様が装置に関連して説明されたが、これらの態様が対応する方法の記載をも示すことは明らかである。ここで、ブロックまたはデバイスは、方法ステップまたは方法ステップの機能に対応する。類似して、方法ステップに関連して説明された態様も、対応するブロックまたは項目の記載または対応する装置の機能を示す。方法ステップのいくつか又は全ては、例えばマイクロプロセッサ、プログラミング可能なコンピュータまたは電子回路などのハードウェア装置によって実行されうる（または使用しうる）。いくつかの実施形態では、最も重要な方法ステップのどれか一つ以上が、かかる装置によって実行されうる。

上記の結果として生じている送信信号は、デジタル記憶媒体に格納されうる、または、例えば無線送信媒体またはインターネットなどの有線送信媒体のような送信媒体で送信されうる。

特定の実現要求に応じて、本発明の実施形態は、ハードウェアにおいて、または、ソフトウェアにおいて実行されることができる。その実現は、その上に格納される電子的に読み込み可能な制御信号を有する、例えばフロッピー（登録商標）ディスク、ＤＶＤ、Ｂｌｕｅ―レイ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはＦＬＡＳＨメモリなどのデジタル記憶媒体を使用して実行され、そして、それは、各方法が実行されるように、プログラミング可能な計算機システムと協動する（または協動することができる）。従って、デジタル記憶媒体は、計算機可読でありえる。

本発明によるいくつかの実施形態は、プログラミング可能な計算機システムと協動することができる電子的に読み込み可能な制御信号を有するデータキャリアを含む。その結果、本願明細書において説明された方法のうちの１つは実行される。

通常、本発明の実施形態は、プログラムコードを有するコンピュータ・プログラム製品として実施されうる。そして、コンピュータ・プログラム製品がコンピュータ上で動作するときに、プログラムコードが方法のうちの１つを実行するために実施されている。プログラムコードは、例えば、機械読み込み可読キャリアに格納されることができる。

他の実施形態は、機械読み込み可読キャリアに格納された、本願明細書において説明された方法のうちの１つを実行するためのコンピュータ・プログラムを含む。

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

発明の方法の更なる実施形態は、従って、そこに記録された、本願明細書において説明された方法のうちの１つを実行するためのコンピュータ・プログラムを含んでいるデータキャリア（またはデジタル記憶媒体、またはコンピュータ可読媒体）である。

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

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

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

いくつかの実施形態において、プログラム可能な論理回路（例えば論理プログラミング可能デバイス）は、本願明細書において説明された方法の機能のいくつかまたは全てを実行するために使用されうる。いくつかの実施形態において、論理プログラミング可能デバイスは、本願明細書において説明された方法のうちの１つを実行するために、マイクロプロセッサと協動することができる。通常、本方法は、好ましくは、いかなるハードウェア装置によっても実行される。

上記実施形態は、本発明の原理のために、単に示しているだけである。装置の修正変更および本願明細書において説明された詳細が他の当業者にとって明らかであるものと理解される。従って、特許クレームの範囲だけによって制限され、本願明細書の実施形態の記載および説明として示された具体的な詳細よって制限されないという意図である。

Claims (38)

1. 送信信号（３８）による送信のための、メディアコンテンツを示している、連続したアクセスユニット（２８）のアクセスユニットストリーム（１４）を前処理するための装置であって、前記装置は、
   前記連続したアクセスユニット（２８）を論理フレーム（２０）のシーケンス（１８）の前記論理フレーム（２０）の有用なデータセクション（２４）に連続して挿入し、前記論理フレームは、それぞれ、アクセスユニット（２８）の開始部分を含まない論理フレーム、１つのアクセスユニットの開始部分が含まれる論理フレーム、２つのアクセスユニットの開始部分が含まれる論理フレームを含むこと、および、
   アクセスユニット（２８）の開始部分（３２）が含まれる各論理フレーム（２０）に、前記各論理フレーム（２０）に含まれている前記アクセスユニットの開始部分（３２）ごとに、そこを指し示しているポインタ（４０）を含んでいるアクセスユニットテーブル（３０）を供給すること、
   によって、前記アクセスユニットストリーム（１４）から論理フレームの前記シーケンス（１８）を生成するように構成され、
   前記装置は、各論理フレームに、前記連続したアクセスユニット（２８）のいずれの開始部分（３２）も含まれない論理フレームのための前記各論理フレーム（２０）におけるアクセスユニットテーブル（３０）の不存在、および、前記連続したアクセスユニット（２８）の少なくとも１つの前記開始部分（３２）が含まれる論理フレーム（２０）のための、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の長さを示している、論理フレームヘッダ（２２）を供給するように構成されること、
   前記装置は、前記開始部分（３２）が前記各論理フレーム（２０）に含まれるアクセスユニット（２８）ごとに、アクセスユニットテーブルエントリを、各アクセスユニットテーブル（３０）に、供給するように構成されること、そして、前記論理フレームヘッダ（２２）は前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の前記長さを示していること、前記アクセスユニットテーブルエントリの開始部分は一定の長さの単位で前記論理フレーム（２０）の前端（７２）若しくは後端（７０）から間隔を置いて配置されること、各アクセスユニットテーブルエントリ（６４）は、各論理フレームに含まれる前記アクセスユニット（２８）の前記開始部分（３２）のそれぞれを指し示しているポインタ（４０）を含むこと、
   前記装置は、有用なデータ挿入方向（６０）を使用して前記論理フレーム（２０）の前記有用なデータセクション（２４）への前記連続したアクセスユニット（２８）の前記連続挿入を実行するように、および、アクセスユニット（２８）の開始部分（３２）が含まれる前記論理フレーム（２０）の中で前記アクセスユニットテーブル（３０）と前記論理フレームヘッダを配置し、その結果、前記有用なデータセクション（２４）が、１つの一定に配置された境界、および、前記アクセスユニットテーブル（３０）の前記長さ（３４）に依存して、前記一定に配置された境界からオフセットされた変動して配置された境界を有している前記各論理フレームの結合部を占めるように、構成されること、
   前記装置は、前記アクセスユニットテーブル（３０）および論理フレームヘッダ（２２）が、前記論理フレーム（２０）の前記前端および前記後端のうちの異なる方の端に接する、または、前記論理フレーム（２０）の前記前端および前記後端のうちの反対側の端から一定にオフセットされるように、論理フレーム（２０）の前記シーケンスを生成するように構成されることを特徴とする、装置。
2. 前記装置は、前記論理フレームヘッダ（２２）が、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の中のアクセスユニットテーブルエントリの数の単位で、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の前記長さを示すように、前記各論理フレームに、前記論理フレームヘッダ（２２）を供給するように構成されることを特徴とする、請求項１に記載の装置。
3. 前記装置は、各アクセスユニットテーブルが、アクセスユニットテーブルエントリ個々のデータ破損検出および／または訂正を可能にしている付加的な冗長データを供給されるように構成されることを特徴とする、請求項１又は請求項２に記載の装置。
4. 前記装置は、前記アクセスユニットテーブル（３０）が、前記論理フレーム（２０）の前記後端若しくは前記前端に接する、または、前記論理フレーム（２０）の前記後端若しくは前記前端から所定の一定のオフセットを有するように、論理フレーム（２０）の前記シーケンス（１８）を生成するように構成されることを特徴とする、請求項１〜請求項３のいずれかに記載の装置。
5. 前記装置は、各アクセスユニットテーブル（３０）が、前記開始部分（３２）が前記各論理フレーム（２０）に含まれるアクセスユニット（２８）の数に依存している長さを有するように、論理フレーム（２０）の前記シーケンス（１８）を生成するように構成されることを特徴とする、請求項１〜請求項４のいずれかに記載の装置。
6. 前記装置は、前記ポインタ（４０）が、アクセスユニット（２８）の開始部分（３２）が含まれる前記論理フレーム（２０）の中で一定である方法で、前記各論理フレーム（２０）の前記後端若しくは前記前端に対して配置された位置決め点から、開始部分が前記各論理フレーム（２０）に含まれる前記アクセスユニット（２８）の前記開始部分（３２）を指し示すように、論理フレーム（２０）の前記シーケンス（１８）を生成するように構成されることを特徴とする、請求項１〜請求項５のいずれかに記載の装置。
7. 前記装置は、前記連続したアクセスユニット（２８）が、前記論理フレーム（２０）の前記有用なデータセクション（２４）にシームレスに挿入されるように、論理フレーム（２０）の前記シーケンスを生成するように構成されることを特徴とする、請求項１〜請求項６のいずれかに記載の装置。
8. 前記装置は、前記アクセスユニットテーブル（３０）と論理フレームヘッダ（２２）が前記論理フレーム（２０）の前記前端および前記後端のうちの異なる方の端に接し、その結果、前記有用なデータセクション（２４）が、アクセスユニット（２８）の開始部分（３２）が含まれる論理フレーム（２０）に関して、前記アクセスユニットテーブル（３０）と論理フレームヘッダ（２２）との間に、および、アクセスユニット（２８）の開始部分が含まれる前記論理フレーム以外の論理フレーム（２０）に関して、前記論理フレームヘッダ（２２）と前記論理フレーム（２０）の前記前端および前記後端のうちの異なる方の端との間に、それぞれ、及んでいる結合部であるように、論理フレーム（２０）の前記シーケンス（１８）を生成するように構成されることを特徴とする、請求項１〜請求項７のいずれかに記載の装置。
9. 前記装置は、前記論理フレームヘッダ（２２）が、すべての論理フレーム（２０）に関して一定の長さを有するように、論理フレーム（２０）の前記シーケンス（１８）を生成するように構成されることを特徴とする、請求項１〜請求項８のいずれかに記載の装置。
10. 前記装置は、アクセスユニット（２８）の開始部分（３２）が含まれる各論理フレーム（２０）において、前記アクセスユニットテーブル（３０）に、前記開始部分が前記各論理フレームに含まれるアクセスユニット（２８）の長さ（６２）を示している長さ表示を供給することを特徴とする、請求項１〜請求項９のいずれかに記載の装置。
11. 前記装置は、前記各論理フレームに含まれている前記アクセスユニットの開始部分ごとに、アクセスユニットテーブルエントリを、各アクセスユニットテーブルに供給するように構成されること、各アクセスユニットテーブルエントリは、前記各論理フレームに含まれているアクセスユニットの前記開始部分のそれぞれを指し示しているポインタを含んでいること、各アクセスユニットテーブルエントリは、前記各アクセスユニットテーブルエントリ（６４）の前記ポインタがその前記開始部分を指し示す前記アクセスユニットのコンテンツに関して計算され、前記各アクセスユニットテーブルエントリ（６４）の前記ポインタがその前記開始部分を指し示す前記アクセスユニットのコンテンツのデータ破損検出を可能にしている第２の冗長データを供給されることを特徴とする、請求項１〜請求項１０のいずれかに記載の装置。
12. 前記メディアコンテンツは、オーディオ、ビデオ、テキストまたはデータのコンテンツを含むことを特徴とする、請求項１〜請求項１１のいずれかに記載の装置。
13. 前記装置は、１つの論理フレームからその後の論理フレームへ移行するときに、前記開始部分が前記各論理フレームに含まれるアクセスユニットの数から独立した、前記その後の論理フレーム内の位置で前記挿入を始めることによって、前記連続したアクセスユニットの前記論理フレームへの前記連続した挿入を続けるように構成されることを特徴とする、請求項１〜請求項１２のいずれかに記載の装置。
14. 前記装置は、前記各論理フレームの前記有用なデータセクションの長さが、前記開始部分が前記各論理フレームに含まれるアクセスユニットの数とともに減少するレートで、前記アクセスユニットテーブルが、前記開始部分が前記各論理フレームに含まれるアクセスユニットの前記数とともに線形に増加する長さを有するように、論理フレームの前記シーケンスを生成するように構成されることを特徴とする、請求項１〜請求項１３のいずれかに記載の装置。
15. 前記装置は、アクセスユニットの少なくとも２つの別々の入力ストリームから前記アクセスユニットストリームを生成するように構成されたストリーム生成器を含み、それらアクセスユニットの各々は、ビデオ、オーディオ、テキストまたはデータのコンテンツを示し、前記ストリーム生成器は、各入力ストリームに関して、前記各入力ストリームの前記アクセスユニットが表示順に配列されるように、および、異なる入力ストリームの前記アクセスユニットが、同じ表示時間に関係しているアクセスユニットがまとめられるためにインターリーブされた形で、前記アクセスユニットストリーム内で、配列されるように、前記アクセスユニットストリームを生成するように構成されることを特徴とする、請求項１〜請求項１４のいずれかに記載の装置。
16. 各アクセスユニットテーブルは、前記開始部分が前記各論理フレームに含まれるアクセスユニットごとに１つのアクセスユニットテーブルエントリを含み、前記各アクセスユニットテーブルエントリがそれと関連していること、前記装置は、さらに、各アクセスユニットテーブルエントリが、前記各論理フレーム内のその関連したアクセスユニットの位置を指し示しているポインタと、その関連したアクセスユニットがどの入力ストリームに属するかを示しているストリームＩＤとを含むように、論理フレームの前記シーケンスを生成するように構成されることを特徴とする、請求項１５に記載の装置。
17. 各アクセスユニットテーブルは、前記開始部分が前記各論理フレームに含まれるアクセスユニットごとに１つのアクセスユニットテーブルエントリを含み、前記各アクセスユニットテーブルエントリがそれと関連していること、前記装置は、さらに、各アクセスユニットテーブルエントリが、前記各論理フレーム内のその関連したアクセスユニットの前記開始部分を指し示しているポインタと、その関連したアクセスユニットの長さを示している長さ表示とを含むように、論理フレームの前記シーケンスを生成するように構成されることを特徴とする、請求項１〜請求項１５のいずれかに記載の装置。
18. 前記論理フレームヘッダは、前記各論理フレームの前記前端若しくは前記後端のうちの１つに接する、または、前記各論理フレームの前記前端若しくは前記後端のうちの１つから所定のオフセットを有すること、そして、前記論理フレームは、さらに、それぞれ、一定の長さの、および、前記各論理フレームヘッダと隣接して配置された、ＦＥＣデータセクション（６６）を含み、前記ＦＥＣデータセクションは、システマティックＦＥＣデータを定め、前記ＦＥＣデータセクションの外側の前記論理フレームの部分をＦＥＣ保護し、少なくとも、前記有用なデータセクション、前記論理フレームヘッダ、および、存在するならば前記アクセスユニットテーブルを含むことを特徴とする、請求項１７に記載の装置。
19. 前記装置は、各論理フレームヘッダが、前記各論理フレームヘッダの中の拡張セクションの存在または不存在についての信号を送っているフラグをさらに含み、そして、存在するという信号が送られる場合、前記論理フレームヘッダおよび前記有用なデータセクションに前記拡張セクションが加わるように、論理フレームの前記シーケンスを生成するようにさらに構成されることを特徴とする、請求項１〜請求項１８のいずれかに記載の装置。
20. 請求項１〜請求項１９のいずれかに記載の送信信号による送信のための、メディアコンテンツを示している、連続したアクセスユニットのアクセスユニットストリームを前処理するための装置、および、前記送信信号を送信するための送信ステージを含んでいる、送信チェーン。
21. 前記送信ステージは、前記送信信号をブロードキャストするように構成されることを特徴とする、請求項２０に記載の送信チェーン。
22. 送信信号の論理フレームのシーケンスから、メディアコンテンツを示している、連続したアクセスユニットのアクセスユニットストリームを再生するための装置であって、各論理フレームは、有用なデータセクションを含み、前記連続したアクセスユニットは、論理フレームの前記シーケンスの前記有用なデータセクションに連続して挿入されること、前記論理フレームは、それぞれ、アクセスユニット（２８）の開始部分を含まない論理フレーム、１つのアクセスユニットの開始部分が含まれる論理フレーム、２つのアクセスユニットの開始部分が含まれる論理フレームを含むこと、前記装置は、アクセスユニットの開始部分が含まれる所定の論理フレームに関して、前記所定の論理フレームに含まれている前記アクセスユニットの開始部分ごとに、前記所定の論理フレーム内の各開始位置を指し示しているポインタを含んでいる前記所定の論理フレームからアクセスユニットテーブルを抽出するように、および、前記各ポインタの使用によって、前記開始部分が前記所定の論理フレームに含まれる前記各アクセスユニットを見つけ、その抽出を始めるように構成されること、前記装置はまた、論理フレームの前記シーケンスの前記論理フレームの前記有用なデータセクションから、前記アクセスユニットストリームの前記連続したアクセスユニットを連続して抽出するように構成され、
    前記装置は、各論理フレーム（２０）から、前記各論理フレーム（２０）のアクセスユニットテーブル（３０）の不存在、または、前記各論理フレーム（２０）のアクセスユニットテーブル（３０）の前記長さ（３４）を示している論理フレームヘッダ（２２）を抽出するように、および、それに依存している前記各論理フレーム（２０）の前記有用なデータセクション（２４）の範囲を見つけるように、構成されること、
    前記装置は、前記論理フレーム（２０）内の有用なデータ抽出方向を用いて、前記論理フレーム（２０）から前記連続したアクセスユニット（２８）の前記連続した抽出を実行するように、および、その一定に配置された端から前記有用なデータ抽出方向とは反対方向に、前記アクセスユニットテーブル（３０）の前記長さ（３４）を適用することによって、前記アクセスユニットテーブル（３０）の変動して配置される端を見つけるように、構成されること、および、
    前記論理フレームヘッダは、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の前記長さを示すこと、前記装置は、前記所定の論理フレーム（２０）から前記アクセスユニットテーブル（３０）を抽出する際に、各アクセスユニットテーブルエントリ（６４）に関して、前記各アクセスユニット（２８）の各開始位置を指し示しているポインタ（４０）を得るために、１つのアクセスユニットテーブルエントリ（６４）からその次までの一定の長さの単位で、前記論理フレーム（２０）の前端若しくは後端で、または、前記論理フレーム（２０）の前端若しくは後端から所定の一定のオフセットを有している、前記所定の論理フレーム（２０）内の位置で、始まって、ステップ実行することによって、アクセスユニットテーブルエントリ（６４）の数を、連続して抽出するように構成されることを特徴とする装置。
23. 前記装置は、前記所定の論理フレームから前記論理フレームヘッダのための付加的な冗長情報を抽出し、そして、前記論理フレームヘッダに関するデータ破損検出（１７２）または誤り訂正試行を実行するために、その付加的な冗長情報を使用し、そして、
    前記論理フレームヘッダが破損していることが判明した場合、
    場合により存在するアクセスユニットテーブルエントリ（６４）ごとに、各アクセスユニット（２８）の推定上の開始位置を指し示している推定上のポインタ（４０）および付加的な冗長データを得るために、
    前記場合により存在するアクセスユニットテーブルエントリに関してアクセスユニットテーブルエントリ個々のデータ破損検出を実行するために、そして、
    前記データ破損検出により正しいことが判明する、それら場合により存在するアクセスユニットテーブルエントリの前記ポインタが指し示す推定上の開始位置にあるアクセスユニットだけを、見つけ、その抽出を始めるために、
    １つの場合により存在するアクセスユニットテーブルエントリ（６４）からその次までの一定の長さの単位で、前記論理フレーム（２０）の前記前端若しくは前記後端で、または、前記論理フレーム（２０）の前記前端若しくは前記後端から所定の一定のオフセットを有している、前記所定の論理フレーム（２０）内の位置で、始まって、ステップ実行する（１７８）ように、構成されることを特徴とする、請求項２２に記載の装置。
24. 前記装置は、各論理フレーム（２０）において、前記各論理フレーム（２０）の前記後端若しくは前記前端に、または、前記論理フレーム（２０）の前記後端若しくは前記前端から所定の一定のオフセットで、前記論理フレームヘッダ（２２）を見つけるように構成されることを特徴とする、請求項２３に記載の装置。
25. 前記装置は、前記所定の論理フレームから前記論理フレームヘッダのための付加的な冗長情報を抽出し、そして、前記論理フレームヘッダに関するデータ破損検出（１７２）または誤り訂正試行を実行するために、その付加的な冗長情報を使用し、論理フレームヘッダが破損していることが判明した場合には、もしあるならば前記開始部分が前のいずれかの論理フレームに含まれるアクセスユニットに属している前記所定の論理フレームの前記有用なデータセクションの残りの部分を抽出し（１７６、１９０）、前記所定の論理フレームに及ばせるように、構成されること、前記残りの部分は、全ての論理フレームに関して一定に配置された前記所定の論理フレームの前記有用なデータセクションの開始位置で始まることを特徴とする、請求項２３又は請求項２４に記載の装置。
26. 前記装置は、前記開始部分（３２）が前記所定の論理フレーム（２０）に含まれる各アクセスユニット（２８）を見つける際、前記所定の論理フレーム（２０）の前記後端若しくは前記前端に対して配置された位置決め点からの変位として前記各ポインタ（４０）を使用するように構成されること、前記装置は、前記アクセスユニット（２８）の前記開始部分（３２）が含まれる他の論理フレーム（２０）の前記アクセスユニットテーブル（３０）を抽出し、前記他の論理フレーム（２０）内の前記位置決め点に対する変位としてそこに含まれる各ポインタ（４０）を使用するようにも構成されることを特徴とする、請求項２３又は請求項２５に記載の装置。
27. 前記装置は、前記論理フレーム（２０）の前記前端および前記後端のうちの異なる方の端に前記所定の論理フレーム（２０）の前記アクセスユニットテーブル（３０）および前記論理フレームヘッダ（２２）を見つけるように構成されることを特徴とする、請求項２３〜請求項２６のいずれかに記載の装置。
28. 前記装置は、前記アクセスユニットテーブル（３０）から、前記開始部分が前記所定の論理フレーム（２０）に含まれる各アクセスユニット（２８）の長さ（６２）を示している長さ表示を抽出するように構成されることを特徴とする、請求項２３〜請求項２７のいずれかに記載の装置。
29. 前記装置は、アクセスユニットテーブルエントリごとに、付加的な冗長データを抽出し、前記アクセスユニットテーブルエントリに関してアクセスユニットテーブルエントリ個々のデータ破損検出および／または訂正を実行するように、および、破損していない／訂正されている前記各アクセスユニットテーブルエントリを、前記開始部分が前記所定の論理フレームに含まれるそれらアクセスユニットだけを見つけ、その抽出を始めるように、構成されることを特徴とする、請求項２３〜請求項２８のいずれかに記載の装置。
30. 前記装置は、前記所定の論理フレームから前記アクセスユニットテーブルを抽出する際に、各アクセスユニットテーブルエントリから、前記ポインタ、および第２の付加的冗長データを抽出するように構成されること、前記装置は、前記各アクセスユニットテーブルエントリ（６４）の前記ポインタが前記開始部分を指し示す、前記アクセスユニットのコンテンツに関してデータ破損検出を実行するために前記第２の付加的な冗長データを使用するように構成されることを特徴とする、請求項２３〜請求項２９のいずれかに記載の装置。
31. 前記メディアコンテンツがオーディオ、ビデオ、テキスト、および／または、データのコンテンツを含むことを特徴とする、請求項２３〜請求項３０のいずれかに記載の装置。
32. 前記装置は、前記所定の論理フレームからその後の論理フレームへと移行するときに、前記開始部分が前記所定の論理フレームに含まれるアクセスユニットの数から独立して、前記その後の論理フレーム内の位置で前記抽出を始めることによって、前記論理フレームから前記連続したアクセスユニットの前記連続した抽出を続けるように構成されることを特徴とする、請求項２３〜請求項３１のいずれかに記載の装置。
33. 前記アクセスユニットストリームは、連続したアクセスユニットの少なくとも２つの別々の入力ストリームを含み、それらアクセスユニットの各々は、ビデオ、オーディオ、テキストまたはデータコンテンツを示すこと、入力ストリームごとに、前記各入力ストリームの前記アクセスユニットは、前記少なくとも２つの入力ストリームの表示順に前記アクセスユニットストリーム内で配列されること、前記アクセスユニットテーブルは、前記開始部分が前記各論理フレームに含まれるアクセスユニットごとに１つのアクセスユニットテーブルエントリを含み、前記各アクセスユニットテーブルエントリがそれと関連し、各アクセスユニットテーブルエントリは、前記各論理フレーム内のその関連したアクセスユニットの位置を指し示しているポインタと、その関連したアクセスユニットがどの入力ストリームに属するかを示すストリームＩＤとを含むこと、前記装置は、前記関連したアクセスユニットテーブルエントリの前記ストリームＩＤの使用によって、前記所定の論理フレームから抽出された前記アクセスユニットを、前記対応する入力ストリームに割り当てるように構成されることを特徴とする、請求項２５〜請求項３２のいずれかに記載の装置。
34. 前記論理フレームヘッダは、前記各論理フレームの前記前端若しくは前記後端のうちの１つに接する、または、前記各論理フレームの前記前端若しくは前記後端のうちの１つから所定のオフセットを有すること、そして、前記論理フレームは、さらに、それぞれ、一定の長さの、および、前記各論理フレームヘッダと隣接して配置された、ＦＥＣデータセクション（６６）を含み、前記ＦＥＣデータセクションは、システマティックＦＥＣデータを定め、前記ＦＥＣデータセクションの外側の前記論理フレームの部分をＦＥＣ保護し、少なくとも、前記有用なデータセクション、前記論理フレームヘッダ、および、存在するならば前記アクセスユニットテーブルを含むこと、前記装置は、前記論理フレームの前記ＦＥＣ保護された部分の前記ＦＥＣデータセクション内の前記ＦＥＣデータを用いて、ＦＥＣ処理を実行するように構成されることを特徴とする、請求項２４〜請求項３３のいずれかに記載の装置。
35. 前記装置は、さらに、各論理フレームヘッダ内で、拡張セクションが前記各論理フレーム内に存在するか否かについてのフラグを調べ、この情報を前記論理フレーム内の前記有用なデータセクションの範囲を見つけるために使用するように構成されることを特徴とする、請求項２４〜請求項３４のいずれかに記載の装置。
36. 送信信号（３８）による送信のために、メディアコンテンツを示している、連続したアクセスユニット（２８）のアクセスユニットストリーム（１４）を前処理するための方法であって、前記方法は、
    前記連続したアクセスユニット（２８）を、論理フレーム（２０）のシーケンス（１８）の前記論理フレーム（２０）の有用なデータセクション（２４）に連続して挿入し、前記論理フレームは、アクセスユニット（２８）の開始部分を含まない論理フレーム、１つのアクセスユニットの開始部分が含まれる論理フレーム、２つのアクセスユニットの開始部分が含まれる論理フレームをそれぞれ含むこと、および、
    アクセスユニット（２８）の開始部分（３２）が含まれる各論理フレーム（２０）に、前記各論理フレーム（２０）に含まれている前記アクセスユニットの開始部分（３２）ごとに、そこを指し示しているポインタ（４０）を含んでいるアクセスユニットテーブル（３０）を供給すること、
    によって、前記アクセスユニットストリーム（１４）から論理フレームの前記シーケンス（１８）を生成するステップを含み、
    前記方法は、各論理フレームに、前記連続したアクセスユニット（２８）のいずれの開始部分（３２）も含まれない論理フレームのための前記各論理フレーム（２０）におけるアクセスユニットテーブル（３０）の不存在、および、前記連続したアクセスユニット（２８）の少なくとも１つの前記開始部分（３２）が含まれる論理フレーム（２０）のための、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の長さを示している、論理フレームヘッダ（２２）を供給するように構成されること、
    前記方法は、前記開始部分（３２）が前記各論理フレーム（２０）に含まれるアクセスユニット（２８）ごとに、アクセスユニットテーブルエントリを、各アクセスユニットテーブル（３０）に、供給するように構成されること、そして、前記論理フレームヘッダ（２２）は前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の前記長さを示していること、前記アクセスユニットテーブルエントリの開始部分は一定の長さの単位で前記論理フレーム（２０）の前端（７２）若しくは後端（７０）から間隔を置いて配置されること、各アクセスユニットテーブルエントリ（６４）は、各論理フレームに含まれる前記アクセスユニット（２８）の前記開始部分（３２）のそれぞれを指し示しているポインタ（４０）を含むように構成されること、
    前記方法は、有用なデータ挿入方向（６０）を使用して前記論理フレーム（２０）の前記有用なデータセクション（２４）への前記連続したアクセスユニット（２８）の前記連続挿入を実行するように、および、アクセスユニット（２８）の開始部分（３２）が含まれる前記論理フレーム（２０）の中で前記アクセスユニットテーブル（３０）と前記論理フレームヘッダを配置し、その結果、前記有用なデータセクション（２４）が、１つの一定に配置された境界、および、前記アクセスユニットテーブル（３０）の前記長さ（３４）に依存して、前記一定に配置された境界からオフセットされた変動して配置された境界を有している前記各論理フレームの結合部を占めるように、構成されること、
    前記方法は、前記アクセスユニットテーブル（３０）および論理フレームヘッダ（２２）が、前記論理フレーム（２０）の前記前端および前記後端のうちの反対側の端に接する、または、前記論理フレーム（２０）の前記前端および前記後端のうちの反対側の端から一定にオフセットされるように、論理フレーム（２０）の前記シーケンスを生成するように構成されることを特徴とする、方法。
37. 送信信号の論理フレームのシーケンスから、メディアコンテンツを示している連続したアクセスユニットのアクセスユニットストリームを再生するための方法であって、各論理フレームは有用なデータセクションを含んでおり、前記連続したアクセスユニットは、論理フレームの前記シーケンスの前記有用なデータセクションに連続して挿入され、前記論理フレームは、アクセスユニット（２８）の開始部分を含まない論理フレーム、１つのアクセスユニットの開始部分が含まれる論理フレーム、２つのアクセスユニットの開始部分が含まれる論理フレームをそれぞれ含み、前記方法は、アクセスユニットの開始部分が含まれる所定の論理フレームに関して、前記所定の論理フレームに含まれている前記アクセスユニットの開始部分ごとに、前記所定の論理フレーム内の各開始位置を指し示しているポインタを含んでいる前記所定の論理フレームから、アクセスユニットテーブルを抽出するステップと、前記各ポインタを使用することによって、前記開始部分が前記所定の論理フレームに含まれる前記各アクセスユニットを見つけ、その抽出を始めるステップを含み、前記方法はまた、論理フレームの前記シーケンスの前記論理フレームの前記有用なデータセクションから前記アクセスユニットストリームの前記連続したアクセスユニットを連続して抽出するステップを含み、
    前記方法は、各論理フレーム（２０）から、前記各論理フレーム（２０）のアクセスユニットテーブル（３０）の不存在、または、前記各論理フレーム（２０）のアクセスユニットテーブル（３０）の前記長さ（３４）を示している論理フレームヘッダ（２２）を抽出するように、および、それに依存している前記各論理フレーム（２０）の前記有用なデータセクション（２４）の範囲を見つけるように、構成されること、
    前記方法は、前記論理フレーム（２０）内の有用なデータ抽出方向を用いて、前記論理フレーム（２０）から前記連続したアクセスユニット（２８）の前記連続した抽出を実行するように、および、その一定に配置された端から前記有用なデータ抽出方向とは反対方向に、前記アクセスユニットテーブル（３０）の前記長さ（３４）を適用することによって、前記アクセスユニットテーブル（３０）の変動して配置される端を見つけるように、構成されること、および、
    前記論理フレームヘッダは、前記各論理フレーム（２０）の前記アクセスユニットテーブル（３０）の前記長さを示すこと、前記方法は、前記所定の論理フレーム（２０）から前記アクセスユニットテーブル（３０）を抽出する際に、各アクセスユニットテーブルエントリ（６４）に関して、前記各アクセスユニット（２８）の各開始位置を指し示しているポインタ（４０）を得るために、１つのアクセスユニットテーブルエントリ（６４）からその次までの一定の長さの単位で、前記論理フレーム（２０）の前端若しくは後端で、または、前記論理フレーム（２０）の前端若しくは後端から所定の一定のオフセットを有している、前記所定の論理フレーム（２０）内の位置で、始まって、ステップ実行することによって、アクセスユニットテーブルエントリ（６４）の数を、連続して抽出するように構成されることを特徴とする、方法。
38. コンピュータ上で動作するときに、前記コンピュータに請求項３６又は請求項３７に記載の方法を実行させるためのプログラムコードを有するコンピュータ・プログラムがその上に記憶されていることを特徴とするコンピュータ可読媒体。

Images