(57)【特許請求の範囲】
【請求項１】
オーディオビジュアル符号化情報を、別個のデータストリームに分割し、ないしは別個のデータストリームの形態で供給し、
個々のデータストリームを、フレーム構造化された伝送規格の１つないしは複数のデータチャネルに多重化する、
オーディオビジュアル符号化情報を、フレーム構造化された所定の伝送規格にまとめる方法において、
（ａ）相互に通信する端末装置の能力、すなわち、どの形式のデータを符号化ないしは復号化できるかと、符号化ないしは復号化のためにどの方式がサポートされているかとを、コネクション確立後に交換し、
（ｂ）前記交換された端末装置の能力を前記所定の伝送規格内で定義し、
（ｃ）前記オーディオビジュアル符号化情報を、前記交換された端末装置の能力に基づき、前記所定の伝送規格が定義する符号化規格のデータ構造を使用して、ＭＰＥＧ−４のデータタイプの個々のデータストリームへ符号化し、
なお、前記符号化規格は、使用されるデータタイプと、使用される符号化ツールと、データ容量である符号化パラメタとについての指示を含み、
（ｄ）前記符号化された個々のデータストリームを、前記符号化によってフレーム構造化された伝送規格の複数のデータチャネルに、多重化された固定長の情報パケットとして伝送する（コンセプトＢ）か、または、
前記符号化された個々のデータストリームを、ただ１つのデータストリームへ多重化し、ただ１つのデータチャネルへ、多重化された固定長の情報パケットとして伝送する（コンセプトＡ）ことを特徴とする、
オーディオビジュアル符号化情報を、フレーム構造化された所定の伝送規格にまとめる方法。
【請求項２】
能力交換時と伝送チャネルオープン時とに使用される前記データ構造を同じに選択する、
請求項１に記載の方法。
【請求項３】
オブジェクト数の少ない、オブジェクトベースのオーディオビジュアル符号化情報に対して、対応するデータストリームを、Ｈ．２２３規格に準拠するマルチプレクサによってパケット化し、かつ個々のＨ．２４５規格に適合するＩＴＵチャネルに伝送する、
請求項１または２に記載の方法。
【請求項４】
パケットに割り当てられた伝送チャネル内で個々のパケットを割り当てるために、ＭＰＥＧ−４伝送では個々のエレメンタリデータストリームのアイデンティフィケーション（ＥＳ−ＩＤ）を含むデータフィールド（"portNumber"フィールド）を使用する、
請求項３に記載の方法。
【請求項５】
多重化方式から、ＭＰＥＧ−４出力データストリーム（ＳＬ−ＰＤＵ）のデータ形式を直接受け取り、これによって別の変換が不要である、
請求項３に記載の方法。
【請求項６】
ＭＰＥＧ−４にしたがうイニシャルオブジェクトデスクリプタを、オーディオビジュアル符号化情報に対して、別個のＩＴＵ−Ｈ．２２３規格に適合した、０とは異なる論理チャネルに収容する、
請求項３に記載の方法。
【請求項７】
オブジェクトベースのオーディオビジュアル符号化情報に対して、オブジェクト数が多い場合に、対応する複数のデータストリームを共通の１つのデータストリームに多重化し、該共通の１つのデータストリームをＩＴＵチャネルで伝送する、
請求項３に記載の方法。
【請求項８】
前記の多重化されたデータストリームの他に、フレーム構造化された伝送規格の伝送フレームにシグナリング情報を収容し、該シグナリング情報は、多重化された固定長の情報パケットが伝送されることを指示し、当該情報パケットに基づいて、同期化が、エラーを有するデータパケット時に実行できる、
請求項１，２または７に記載の方法。
【請求項９】
ＭＰＥＧ−４にしたがうイニシャルオブジェクトデスクリプタを、オーディオビジュアル符号化情報に対して、付加的なＩＴＵ−Ｈ．２４５規格に適合して論理チャネル０に収容する、
請求項１，２または７のいずれか１項に記載の方法。
【請求項１０】
別個の、ＳＬパケット化されたＭＰＥＧ−４エレメンタリデータストリームと、前記の付加的なＩＴＵ−Ｈ．２４５規格に適合する論理チャネル０の多重化されたデータとの間の割り当てデータを収容する、
請求項１，２，７または８のいずれか１項に記載の方法。
【請求項１１】
前記のシグナリング情報に対してデータフィールドを設け、該データフィールドは、一方で固定長であることと、また他方で多重化された情報パケットのパケットサイズとを示す、
請求項１，２，７，８または９のいずれか１項に記載の方法。
【請求項１２】
オーディオビジュアル符号化情報としてＭＰＥＧ−４データを使用し、該ＭＰＥＧ−４データを固定長のＦｌｅｘＭｕｘパケットに分割し、当該固定長のＦｌｅｘＭｕｘパケットを伝送フレームに多重化し、該伝送フレームによってＩＴＵ規格Ｈ．３２４による伝送が可能になる、
請求項１，２または７から１０までのいずれか１項に記載の方法。
【請求項１３】
ＩＴＵ規格Ｈ．３２４による可変長のアダプテーションレイヤ内で複数のＭＰＥＧ−４データを固定長のデータパケットに収容し、該データパケットのスタート領域に１つずつ長さフィールドを設け、該長さフィールドを、受信側の同期回復のために使用する、
請求項１から１２までのいずれか１項に記載の方法。
【請求項１４】
オーディオビジュアル符号化情報を、端末装置への別個のデータストリームに分割する、ないしは別個のデータストリームの形態で前記端末装置に供給する手段と、
個々のデータストリームを、フレーム構造化された伝送規格の１つまたは複数のデータチャネルに多重化する手段とを有する、
オーディオビジュアル符号化情報を、フレーム構造化された所定の伝送規格に送信側でまとめる端末装置において、
（ａ）相互に通信する端末装置の能力、すなわち、どの形式のデータを符号化ないしは復号化できるかと、符号化ないしは復号化のためにどの方式がサポートされているかとを、コネクション確立後に交換する手段と、
（ｂ）前記交換された端末装置の能力を前記所定の伝送規格内で定義する手段と、
（ｃ）前記オーディオビジュアル符号化情報を、前記交換された端末装置の能力に基づき、前記所定の伝送規格が定義する符号化規格のデータ構造を使用して、ＭＰＥＧ−４のデータタイプの個々のデータストリームへ符号化する手段と、
なお、前記符号化規格は、使用されるデータタイプと、使用される符号化ツールと、データ容量である符号化パラメタとについての指示を含み、
（ｄ）前記符号化された個々のデータストリームを、前記符号化によってフレーム構造化された伝送規格の複数のデータチャネルに、多重化された固定長の情報パケットとして伝送する（コンセプトＢ）か、または、前記符号化された個々のデータストリームを、ただ１つのデータストリームへ多重化し、ただ１つのデータチェネルへ、多重化された固定長の情報パケットとして伝送する（コンセプトＡ）手段とを
有することを特徴とする、
オーディオビジュアル符号化情報を、フレーム構造化された所定の伝送規格に送信側でまとめる端末装置。
【発明の詳細な説明】
【０００１】
従来の技術
マルチメディア通信のために低ビットレートで画像および音声データを伝送するために、ＩＴＵ  Ｈ．３２４規格書「低ビット・レートのマルチメディア通信のための端末」により、画像電話通信適用分野に有利なシステムが示されている。
【０００２】
図１にはＨ．３２４規格によるこのようなマルチメディアシステムの回路図が示されている。参照符号１で示したブロックには、Ｈ．３２４で詳細に示された部材群が収容されている。ビデオコーデック２は、ＩＴＵ−Ｈ．２６３／Ｈ．２６１の方式により構成されている。ＩＴＵ  Ｇ．７２３によるオーディオコーデック３には遅延装置４が後置接続されており、これにより場合によっては画像符号化と音声符号化との間の時間的差が調整される。装置５はデータプロトコル、例えばＶ．１４  ＬＡＰＭその他を処理するために使用され、装置６はＩＴＵ  Ｈ．２４５の制御プロトコルを処理する。コーデック２および３には、対応するＩ／Ｏ（Input／Output）装置７および８を介してオーディオビジュアルデータが供給される。プロトコルを処理する装置５および６は、装置９（ユーザデータアプリケーション）および１０（システム制御）を介してそれらの入力データをそれぞれ受け取る。コーデック２，３ならびにプロトコル処理装置５および６のデータストリームは、Ｈ．２２３規格に準拠するマルシプレクス／デマルシプレクス装置１１を介して一緒にまとめられる。後置接続されたモデム１２は、まとめられたこのデータストリームに対して、Ｖ．３４に適合するデータを、またシステム制御データに対して、Ｖ．２５に適合するデータを供給する。伝送網１３は、ブロック１に所属の網制御部１４と共に接続されている。
ＷＯ９８／２１８４６Ａから、同形式の多数のオーディオビジュアルデータストリームを共通の単一の中間データストリームに多重化することが公知である。これらの中間データストリームに対して誤り識別の手段が、相応するシグナリングを介して初期化フェーズにおいて講じられる。これらの中間データストリームは、単一の全体データストリームにグループ化される。
Lindbergh D.の"The H.324 Multimedia Communication Standard" IEEE Communications Magazine, US, IEEE Service Center, Piscataway, N. J.，第３４巻第１２号，１９９６年１２月１日（１９９６−１２−０１），第４６〜５１頁から同様に、データストリームをまとめることが公知である。フレーム構造において固定長のデータパケットを利用することにより、誤り耐性が向上する。誤り後のデータストリームへの同期回復は簡単に可能である。異なるシステムをカプセル化ないしはまとめることも簡単に行うことができる。
"Information Technology - Generic Coding of Audiovisual Object Part 1: System (Passage) ISO/IEC 14496-1 Final Committee Draft of International Standard"，１９９８年５月１８日から同様に信号をまとめることが公知である。
【０００３】
発明の利点
請求項１ならび従属請求項の特徴部分に記載された方法は、オブジェクトベースに符号化された情報、例えばＭＰＥＧ−４伝送規格に準拠する情報を、フレーム構造化された所定の伝送規格、例えばＩＴＵ規格にまとめるのに有利であり、この方法によって、符号化されたＭＰＥＧ−４データの伝送が可能である。従来のビデオ符号化方式、例えば冒頭に示したＩＴＵ−Ｈ．２６３／Ｈ．２６１のビデオ方式およびＧ．７２３．１のオーディオコーデックと比べて例えばつぎにような利点が得られる：
総合化されかつ自然なビジュアルオブジェクトならびにオーディオオブジェクトのオブジェクトベースの符号化、
改善された符号化効率、
ビデオ符号化の改善されたビジュアルエラー耐性、
オーディオビジュアルオブジェクトの配置を記述する固有の形式、
種々のオーディオビジュアルオブジェクトの同期化、
オーディオビジュアルオブジェクトとのインタラクション。
【０００４】
本発明の方式は（以下でコンセプトＡおよびＢと称する）相異なる２つのコンセプトに基づく。一般的にはこれらのコンセプトの各々はそれ自体で所望の機能（オブジェクトベースに符号化されたオーディオビジュアル情報の伝送）を保証するのに有利である。しかしながらコンセプトＡはオブジェクト数が多い場合に（すなわちＭＰＥＧ−４データストリームが多い場合に）有利である。２つのコンセプトを組み合わせることも可能である。
【０００５】
したがって本発明の方式はつぎのような大きな利点、すなわち、
すべてのＭＰＥＧ−４データストリームを（例えば多数のオブジェクト
を使用する際に）ＭＰＥＧ−４のＦｌｅｘＭｕｘ仕様によって、単一データストリームにパケット化することができ、ここでこのデータストリームは復号化のためのすべての情報を含む（コンセプトＡ）という利点、または／および
双方向通信を全ＭＰＥＧ−４機能に基づいて実行することができ、この際にＭＰＥＧ−４データを、繁雑にも付加的に通信規格の形式に適合化する必要がないという利点を有し、ここでこれは、マルチメディア通信規格Ｈ．３２４によって提供される機構を一貫して利用することによって得られる（コンセプトＢ）。
【０００６】
さらに能力交換時および伝送チャネルのオープン時に同一のデータ構造を使用する。このデータ構造によって、伝送すべきデータストリームタイプ、使用する符号化ツールおよびそのパラメタ、例えばデータ容量などが示される。
【０００７】
固定長のデータパケットを使用すること（コンセプトＡの場合）により、ないしはＨ．３２４に依拠する多重化規格Ｈ．２２３を利用すること（コンセプトＢ）により誤り耐性が高まる。誤り後のデータストリームへの同期回復は簡単に可能である。異なるシステムをカプセル化したり、またはまとめることも、例えばＨ．３２４プラットホームとＭＰＥＧ−４プラットホームとを組み合わることも簡単である。
【０００８】
図面
別の図面に基づいて本発明を詳しく説明する。ここで：
図２ａおよび２ｂは、Ｈ．３２４端末装置に基づくＭＰＥＧ−４マルチメディアシステムのブロック回路図を示しており、
図３は、固定長のシンプルモードにおけるＦｌｅｘ−Ｍｕｘプロトコルの構造を示しており、
図４は、固定長のＭｕｘモードにおけるＦｌｅｘ−Ｍｕｘプロトコルの構造を示しており、
図５は、ＩＴＵ  Ｈ．２２３のアダプテーションレイヤフレームを示しており、
図６は、論理ＩＴＵチャネルのデータのインタリーブを示しており、
図７は、ヘッダ形式を示しており、
図８は、Multiplex Entry Descriptorの例を示しており、
図９は、固定長のパケットを、可変長のＩＴＵアダプテーションレイヤにまとめることを示している。
【０００９】
実施例の説明
本発明の方法を詳しく説明する前に、より分かりやすくするために使用する規格を簡単に示す：
ＩＴＵ−Ｈ．３２４規格には、Ｈ．２６１／Ｈ．２６３のビデオコーデックと、Ｇ．７２３のオーディオコーデックと、Ｈ．２２３のマルチプレクサと、Ｈ．２４５の制御プロトコルとからなる端末装置が示されている。個別のコンポーネントの構造および組み合わせは、この規格に記載されている。
【００１０】
ＩＴＵ−Ｈ．２２３規格には、低ビットレートのマルチメディア通信のためのパケットベースの多重化プロトコルが示されている。これは２つのマルチメディア端末装置間、または端末装置とマルチポイントユニットとの間の低ビットレートの伝送に対して使用される。このプロトコルによって、オーディオ、ビデオ、データ情報の任意の組み合わせの伝送が、個別の通信チャネルを介して可能である。このプロトコルの特徴は「遅延が少ないこと」("Low Delay"）およびオーバーヘッドが少ないことである。多重化プロトコルを実装するために必要なプロトコルプロシージャはＨ．２４５規格に示されている。
【００１１】
ＩＴＵ−Ｈ．２４５規格「マルチメディア通信のための制御プロトコル」には、端末装置情報およびメッセージのシンタックスおよびセマンティクス、ならびに通信確立のための手順が示されている。これらのメッセージによって、端末装置能力／ケーパビリティの交換が可能であり、例えば端末装置Ａは端末装置Ｂに、端末装置Ａはビデオデータを復号化することができかつどの方式をサポートしているかをシグナリングする。
【００１２】
さらにプロトコルが示されており、これによってオーディオビジュアルデータを肯定応答メッセージによって高い信頼性で伝送可能である（端末装置Ａは端末装置Ｂにデータパケットを正しく受信したことをシグナリングする）。
【００１３】
ＩＴＵ−Ｈ．２６３／Ｈ．２６１規格には、圧縮されたビデオデータの符号化が低ビットレートのチャネルに対して示されている。
【００１４】
Ｇ．７２３．１規格には、圧縮されたビデオデータの復号化が低ビットレートのチャネルに対して示されている。
【００１５】
ＭＰＥＧ−４データをＨ．２４５規格によって伝送するためにはつぎのステップが必要である：
１．  双方向の通信を可能とするために、まず通信を行う端末装置の能力を交換（Capability Exchange）しなければならない。データ伝送は、Ｈ．２４５に適合してこのために設けられた論理チャネル０で行われる
２．  さらにＭＰＥＧ−４デコーダをコンフィギュレーションしなければならない。このために必要なＭＰＥＧ−４の固有情報、例えばイニシャルオブジェクトデスクリプタを、Ｈ．２４５例えば論理チャネル０に伝送するか、または別個の論理ＩＴＵチャネルを介して、例えばＩＴＵ−Ｈ．２２３規格に適合して、０と異なる論理チャネルに伝送する、
３．  引き続いてＨ．２４５によって、個別の論理チャネルを、オーディオビジュアルデータストリームを伝送するためにオープンしなければならない。
【００１６】
１．の能力交換（Capability Exchange）について
能力交換に対しては、ＭＰＥＧ−４能力をＨ．２４５内で定義するので十分であり、これは例えばつぎのようになる：
Is14496Capability
{
streamType            INTEGER (0..255)
ProfileIndication       INTEGER (0..255)
LevelIndication        INTEGER (0..255)
}
または
Is14496Capability
{
streamType            INTEGER (0..255)
DecoderSpecificInfo    OCTET STRING OPTIONAL
}
または
Is14496Capability
{
decConfDescr        DecorderConfigDescriptor
}
上記のデータ構造の個々のフィールドは、ＭＰＥＧ−４文書（ＩＳＯ／ＩＥＣ  １４４９６）に詳しく説明されている。この能力定義の利点は、データオーバーヘッドが少ないことであり、かつＭＰＥＧ−４規格内の仕様を参照していることであり、これによってＨ．２４５規格における付加的な定義のオーバーヘッドが回避されることである。steamTypeはデータストリームのタイプ（すなわち内容）を定義し、プロファイルインジケータは復号化ツールを定義し、レベルはこの復号化ツールのパラメタを定義する。ＭＰＥＧ−４内では例えばこれらのパラメタは、レベルインジケーションを除いて含まれており、これもＭＰＥＧによって規格化されるべきである。
【００１７】
is14496Capabilityは、コンセプトＢでは”Data Type”フィールドによって、Ｈ．２４５の機能OpenLogicalChannelによる論理チャネルのオープン時に、このチャネルで伝送されるＭＰＥＧ−４データタイプを示すためにも使用される。
【００１８】
２．のデコーダのコンフィギュレーションについて
能力交換によって端末装置能力を定義した後、デコーダのコンフィギュレーションを、イニシャルオブジェクトデスクリプタないしはオブジェクトデスクリプタの伝送によって実行される。これはイニシャルオブジェクトデスクリプタが交換されるＨ．２４５にしたがって要求／確認命令を用いて行われるか、またはイニシャルオブジェクトデスクリプタまたはＳＬパケット化されたオブジェクトデスクリプタストリームだけを含む新たなＩＴＵ論理チャネルをオープンすることによって行われる。
【００１９】
３．の論理チャネルのオープンおよびデータ伝送について
コンフィギュレーションの後、個別のＩＴＵチャネルがオープンされる。一般的にはつぎが成り立つ：
例えばＭＰＥＧ−４によるオーディオビジュアル符号化情報は、別個のデータストリームに分割される。ＭＰＥＧ−４に適合するデータストリームを形成するエンコーダは、その出力側にすでにこれらの別個のデータストリームのうちの複数のデータストリーム、例えばＳＬ（Synchronisation Layer）パケット化データストリームを供給する。図２ａおよび図２ｂには、エレメンタリデータストリーム（Ｅｌ．ストリーム）が、シンク（Synchronisation）レイヤの「エレメンタリストリームインタフェース」（Elementary Stream Interface）に示されている。ここで注意すべきであるのは、ＳＬパケットのヘッダが「ゼロ」にコンフィギュレーションできる（すなわち省略できる）ことである。このシンクレイヤ（Sync Layer）内では、エレメンタリデータストリームのパケット化が行われ、これはつぎにストリーム多重化インタフェース（Stream Multiplex Interface）において後続処理のために取り出し可能である。
【００２０】
コンセプトＢでは論理チャネルのオープンは、Ｈ．２４５に規定されたOpenLogicalChannelメッセージによって行われる。”portNumber”フィールドは、各論理チャネルのオープン時に、配属されたエレメンタリデータストリームアイデンティフィケーション（ＥＳ＿ＩＤ）をシグナリングするために使用され、これによってデータストリームがＭＰＥＧ−４側で参照される。ここでは、Is14496Capabilityの値が割り当てられるこの”streamType”フィールドによって（したがって能力交換時と同じデータ構造を使用することができる）、論理チャネルの内容（すなわちＭＰＥＧ−４−オブジェクトタイプ）をそれぞれ明示的に示すことができる。実質的な（これに続く）データ伝送の際、コンセプトＢではＳＬパケット化された個別のＭＰＥＧ−４データストリームは、「ストリーム多重化インタフェース（Stream Multiplex Interface）」で取り出され、論理ＩＴＵチャネルで伝送される。ＳＬパケット化されたＭＰＥＧ−４データストリームはこのためにＨ．２２３アダプテーションレイヤによってＡＬ−ＳＤＵパケットとして処理され、Ｈ．２２３規格によって多重化される（図２ａの実施例）。データのＭＰＥＧ−４フレーミングを、Ｈ．２２３のフレーミング（ＳＬ：＝ＡＬ−ＳＤＵ）に転送することによって誤り耐性が増し、パケットが誤りを伴って伝送された場合にも簡単な再同期化が可能である。さらにこれにより、ＭＰＥＧ−４データ形式をマルチプレクサの形式へ付加的に適合化する必要性が回避される。コンセプトＢによって（後から）別のＭＰＥＧ−４データストリームを動的に付加することができる。
【００２１】
コンセプトＡを変換するためには個々のデータストリームを、全体でただ１つのデータストリームにＭＰＥＧ−４  ＦｌｅｘＭｕｘによって多重化し、全体でただ１つの論理ＩＴＵチャネルで伝送する（図２ｂの実施例）。ＦｌｅｘＭｕｘによるＭＰＥＧ−４データストリームのこの形式の伝送のために、付加的なデスクリプタを定義し、これによってコネクション確立が可能になる。これらのデスクリプタだけで、個々のＭＰＥＧ−４データストリームの識別が可能である。これらのＭＰＥＧ−４固有のデータストリームは、ＭＰＥＧ−４ Ｆｌｅｘｍｕｘツールによって多重化される。ここでは固定長のパケットを使用することが定義され、これによって誤り耐性が増大する。誤り後のデータストリームへの同期回復はこれによって可能である。
【００２２】
以下にコンセプトＡを詳しく説明する。
【００２３】
図２ｂに示したように、つぎの論理ＭＰＥＧ−４オブジェクト（ＳＬパケット化データストリーム）をＭＰＥＧ−４ ＦｌｅｘＭｕｘツールによって伝送フレームに多重化し、単一の論理ＩＴＵチャネルＡＬ１で伝送することができる：
ＳＬ−オーディオ、
ＳＬ−ビデオ、
ＳＬ−ＯＣＲ（Object Clock Reference）、
ＳＬ−ＯＤ（Object Descriptor）、
ＳＬ−ＯＣＩ（Object Content Information）。
【００２４】
コンセプトＡに少し変更を加えると、同一タイプのデータだけ（したがってＳＬ−オーディオだけまたはＳＬ−ビデオだけ）を単一の論理チャネルにＦｌｅｘＭｕｘツールによって多重化することもできる。すなわちＭＰＥＧ−４データストリーム全体を、同様に複数の（しかしながらコンセプトＢの場合よりも少ない）論理ＩＴＵチャネルで伝送することができる。これにより状況によっては、多重化されたデータを受信側でより簡単に分割および復号化することができる。しかしながら以下では再び元々のコンセプトＡ、すなわち全ＭＰＥＧ−４データストリームを、ＦｌｅｘＭｕｘツールによって単一の論理ＩＴＵチャネルに多重化することを考察する。
【００２５】
コンセプトＡによって（コンセプトＢと同様に）同じタイプの複数のＭＰＥＧ−４データストリームを伝送することができる。これは例えば、複数のオーディオストリームを、単一の画像に付随する相異なる言語の音声に対して伝送する場合である。
【００２６】
コンセプトＡの方法に対しては、ＭＰＥＧ−４  ＦｌｅｘＭｕｘをコンフィギュレーションするためにMUXCODETABLE＿Entryを初期化フェーズ中に伝送しなければならない。
【００２７】
最終的にはＭＰＥＧ−４デコーダに、個々のＥＳストリームと、多重化すべきデータとの行われた対応付けを伝達しなければならない。これはチャネルマップテーブル（Channel Map Table）（またはストリームマップテーブル（Stream Map Table）とも称される）によって行われる。
【００２８】
これらの２つの情報は、オブジェクトデスクリプタと並んで復号化のために必要である。
【００２９】
付加的な情報MUXCODETABLE＿Entryおよびチャネルマップテーブルをイニシャルオブジェクトデスクリプタに挿入するために、新たなデスクリプタの定義が必要である。これらはエクステンションデスクリプタ（Extension Descriptors）の形式でイニシャルオブジェクトデスクリプタに挿入される。
【００３０】
【外１】
0004488465.tif 000002
【００３１】
太字印刷の部分は、ここで新たに定義されたデスクリプタを示している。
【００３２】
類似にMuxCodeTableEntryDescriptorsを構成することができる：
【００３３】
【外２】
0004488465.tif 000003
【００３４】
太字印刷の部分は、ここで新たに定義されたデスクリプタを示している。データフィールドnumberOfMuxCodeTableEntriesによって、最大１６のMuxCodeTableEntryを伝送することができる。constantLengthFlagと、フィールドFlexMuxLengthとによって受信側に、パケットサイズFlexMuxLength+2の固定長を有するＦｌｅｘＭｕｘパケットが伝送されることをシグナリングする。
【００３５】
ＭＰＥＧ−４に定義されたＦｌｅｘＭｕｘパケットは、一方では図３のシンプルモードで、他方では図４のＭｕｘＣｏｄｅで伝送される。
【００３６】
ここでは１２７バイトである奇数の長さ固定のパケットを使用することによって、長さフィールドの上位７ビットを同期化に利用することができる。これによって誤り耐性が増大し、パケットの長さフィールドに誤りがある場合に、再同期化が可能である。
【００３７】
これらのＦｌｅｘＭｕｘパケットを、ＩＴＵフレームにまとめなければならない。図５にはＩＴＵ−Ｈ．２２３のアダプテーションレイヤ（ＡＬ＝Adaptation Layer）フレームが示されており、これはＡＬ−ＰＤＵ（Protocol Data Unit）ペイロードフィールドを有する。ＦｌｅｘＭｕｘパケットは可変長であるため、長さフィールドにエラーがあった後では新たなＦｌｅｘＭｕｘパケットをサーチすることはできなくなってしまうおそれがある。このことは複数のＭＰＥＧ−４エレメンタリストリーム（例えばＢＩＦＳ，ＯＤおよびビデオ）を単一のＩＴＵチャネルで伝送する場合には殊に不利である。本発明により、ＭＰＥＧ−４  ＦｌｅｘＭｕｘパケット内で固定長を使用することによって、これはここでは可能である。
【００３８】
可変長の個々のＡＬ−ＰＤＵパケットは、マルチプレクサによってパケット化される。多重化レイヤの構造およびＭＰＥＧ−４ ＦｌｅｘＭｕｘデータストリームの基本的なまとめ方を簡単に説明する。
【００３９】
ＭＵＸプロトコルデータユニット（ＭＵＸ−ＰＤＵ）は、ヘッダと、情報フィールドとからなり、この情報フィールドには個々の論理ＩＴＵチャネルのデータがインターリブされている。図６にはその構造が示されている。
【００４０】
ヘッダは、図１に示した個々のフィールドからなる。
【００４１】
４ビット長の多重化コードは、Ｈ．２４５を介して伝送されるMultiplexEntryをポイントしており、これによって最大１５の相異なるMultiplexEntryを定義することができる。
【００４２】
ヘッダのエラー制御フィールドは３ビット長のＣＲＣフィールドであり、これによってヘッダにおけるエラーを識別することができる。
【００４３】
１ビットのパケットマーカーフィールドは、セグメント化された論理チャネルのＭＵＸ−ＳＤＵの終わりをマークする。
【００４４】
図６に示された情報フィールドは、Ｈ．２４５で伝送されるMultiplexTableによってコンフィギュレーションされる。
【００４５】
この情報フィールドは、Closing Flagによって任意にオクテット境界で終了することができるが、セグメント化できないチャネルのＭＵＸ−ＳＤＵは中断してはならない。
【００４６】
MultiplexEntryDescriptorは、Ｈ．２２３マルチプレクサをコンフィギュレーションし、かつ初期化フェーズにおいて伝送される（図８）。
【００４７】
この図でＬＣＮはLogicalChannelNumberを、ＲＣはRepeatCountを、ＵＣＦはUntilClosingFlagをそれぞれ意味している。利点は図９で明らかである：
単一のＩＴＵチャネルで複数のＭＰＥＧデータを伝送しかつ可変長のＭＰＥＧ−４パケットを利用する場合、後続のＦｌｅｘＭｕｘパケットはすべて復号化できない。長さフィールドを同期化マーカとして巧みに使用することにより、受信側の同期回復が可能である。
【００４８】
送信側の端末装置は、受信側の端末装置にパケット長を、ここで定義したMuxCodeTableEntryDescriptorsによってシグナリングする。このデスクリプタの特徴はフラグにあり、ここでこのフラグによって、固定長のＦｌｅｘＭｕｘパケットを使用することがシグナリングされる。さらに使用する長さを決定するフィールドが含まれており、このフィールドによって高いフレキシビリティが、高い誤り耐性に関連して保証される。
【００４９】
本発明は当然のことながらＭＰＥＧ−４データに対してだけ使用できるのではなく、規格化された伝送フレームにまとめられかつその復号化を簡単かつ誤りに対して耐性を有するように行わなければならない別のオーディオビジュアル符号化情報に対しても使用できる。
【００５０】
ここに示した方法は当然、送信側および受信側の端末装置で実現することができる。送信側でまとめるためには、オーディオビジュアル符号化情報を分割ないしは供給する相応の手段、ならびにデータストリームを多重化し、能力を交換するし、およびシグナリングする相応の手段を設けなければならない。受信側の評価に対しては、多重化されたデータチャネルの分解する手段、ならびに能力交換とその評価のため、およびシグナリングを評価するための手段が必要である。通例は対話モードによって処理されるため、加入者端末装置は、送信動作も、受信動作も共に装備される。
【図面の簡単な説明】
【図１】  Ｈ．３２４規格によるマルチメディアシステムの回路図である。
【図２ａ】  Ｈ．３２４端末装置に基づくＭＰＥＧ−４マルチメディアシステムのブロック回路図である。
【図２ｂ】  Ｈ．３２４端末装置に基づくＭＰＥＧ−４マルチメディアシステムのブロック回路図である。
【図３】  固定長のシンプルモードにおけるＦｌｅｘ−Ｍｕｘプロトコルの構造を示す図である。
【図４】  固定長のＭｕｘモードにおけるＦｌｅｘ−Ｍｕｘプロトコルの構造を示す図である。
【図５】  ＩＴＵ  Ｈ．２２３のアダプテーションレイヤフレームを示す図である。
【図６】  論理ＩＴＵチャネルのデータのインターリブを示す図である。
【図７】  ヘッダ形式を示す図である。
【図８】  Multiplex Entry Descriptorの例を示す図である。
【図９】  固定長のパケットを、可変長のＩＴＵ適合化レイヤにまとめることを示す図である。
【図１】
0004488465.tif 000004
【図２ａ】
0004488465.tif 000005
【図２ｂ】
0004488465.tif 000006
【図３】
0004488465.tif 000007
【図４】
0004488465.tif 000008
【図５】
0004488465.tif 000009
【図６】
0004488465.tif 000010
【図７】
0004488465.tif 000011
【図８】
0004488465.tif 000012
【図９】
0004488465.tif 000013