JP4391231B2 - 複数のターミナルへのマルチメディア信号のブロードキャスト方法 - Google Patents

Description

本発明は、プレゼンテーション（例えば、ＭＰＥＧ−２）へのランダムアクセスを可能にするブロードキャストにおけるマルチメディアプレゼンテーション、或いは信号（ＭＰＥＧ−４プレゼンテーション等）のブロードキャストに関する。

このようなランダムアクセスを可能にするには、幾つかのターミナルが異なる間隔でプレゼンテーションの開始を取得できるように、所定のプレゼンテーションを何度かブロードキャストしなければならない。

ＭＰＥＧ−２トランスポートチャネル上でのＭＰＥＧ−４プレゼンテーションはＭＰＥＧ−２システムに対する補正書７において最近記載されている。

しかし、この補正書７は充分ではなく、更新が必要と思われる。本発明はＭＰＥＧ−４のプレゼンテーションを試行及び構築してから補正書７に従い該プレゼンテーションを達成できるか送信しないかを判断するものである。これは我々に放って置かれた或いは効率的に取り扱うことが不可能な機能があることを指摘させた。

その後、ＭＰＥＧ−４のプレゼンテーションの完全な送信を可能とするために補正書７の最小限の修正を試みた。このプロセスは徐々に増えていき、この書類は利用できない機能の点で現在何ができないか、及びＭＰＥＧ−２のトランスポートチャネル（以下、ＭＰＥＧ−２はＭＰＥＧ−２トランスポートを意味する）上でＭＰＥＧ−４プレゼンテーションのブロードキャストにおけるＭＰＥＧ−４の完全な機能を達成させるための我々の結論の点で現在何ができないかを整理しようとしていた。

１ 従来技術：補正書７の監査
１．１ ＭＰＥＧ−４の基本的ストリームの意味
ＭＰＥＧ−２の特徴の１つはプレゼンテーションへのランダムアクセスを可能にすることである。ＭＰＥＧ−２に従いＭＰＥＧ−４のプレゼンテーションを送信する場合のこの意味に焦点を当ててみる。

現在の殆どのＭＰＥＧの用語は付記１に定義されている。

付記２にはＭＰＥＧ−４プレゼンテーションの例が記載されている。

付記３は従来技術によるＭＰＥＧ−２マッピング上のＭＰＥＧ−４に関連する。

１．１．１ ＢＩＦＳ ＥＳ．
前提：プレゼンテーションへのランダムアクセスは２人の異なるユーザに同じプレゼンテーションを提供する。

主張：ＲＡＰではないＢＩＦＳコマンドＥＳのアクセスユニットはシーングラフ構造を修正すべきではない。

理由：そうでなければ、２人の異なるユーザが同じ時点で同じプレゼンテーションを有することはない。より正確には、プレゼンテーションへのランダムアクセスがあるから、我々は上記のような構造の修正の後にＲＡＰ ＡＵを想定することができるのである。ＲＡＰは必ずシーンの交換であり、シーンの交換は修正されたシーングラフである。従って、２人のユーザが同じプレゼンテーションを経験することはない。

結論：
ａ） 更新はプレゼンテーション目的ではなくシーン構造の構築にのみ使用される。従って、プレゼンテーションは非常に動的ではない。多くのＭＰＥＧ−４プレゼンテーションはＭＰＥＧ−２上では送信できない。例えば漫画は正常には取り扱えないであろう。

ｂ） 静的なプレゼンテーションの場合でも、非常に短い時間内ではリソースが利用可能か或いは利用可能となるであろうが、これはプレゼンテーションが大きい場合、帯域幅のために不可能である。これは、貧弱なプレゼンテーションとなるであろう（暫くして画像抜けがおきるであろう）。

１．１．２ ＯＤＥＳ．
前提：プレゼンテーションへのランダムアクセスは２人の異なるユーザに同じプレゼンテーションを提供する。

主張：ＲＡＰではないＯＤＥＳのアクセスユニットはストリーム構造を修正すべきではない。

理由：そうでない場合、２人の異なるユーザが同じ時点で同じプレゼンテーションを有することはない（ＢＩＦＳを参照）。

結論：ＯＤはプレゼンテーション内の修正を意味しないため、これはプレゼンテーションを変更しない。

１．１．３ ＪＰＥＧ、ＭＰＥＧ−Ｊ
主張：ＪＰＥＧ及びＭＰＥＧ−ＪはＰＥＳに送信しなければならない。

理由：補正書７を参照されたい。セクションではＢＩＦＳ及びＯＤだけしか実行できない。

結論：
ａ） セクションにおける既存のエラー検出機構は使用できない。ＪＰＥＧかＭＰＥＧ−Ｊか、或いはデータが破損しているかしていないかを知ることは重要であり得る。

ｂ） ＪＰＥＧ或いはＭＰＥＧ−Ｊ用のアクセスユニットのコピーを受信するＭＰＥＧ−４ターミナルの挙動は特定されていない（或いは許可されない）。

１．１．４ オーディオ及びビデオ
主張：オーディオ及びビデオはＰＥＳに送信しなければならない。

理由：補正書７を参照されたい。セクションではＢＩＦＳ及びＯＤだけしか実行できない。

結論：
ａ） オーディオ「ジングル（jingles）」及び「ビープ（beeps）」ならびに「ビデオクリップ（video clips）」は正常には取り扱えない。

ｂ） オーディオ、ビデオ用のアクセスユニットのコピーを受信するＭＰＥＧ−４ターミナルの挙動は特定されていない（或いは許可されない）。

１．２ コメント
通常の使用状況では、我々は複数のユーザに対し、プレゼンテーションの一部を同じアニメーションとして経験させ、他の部分はそう見せたくない。補正書７はＭＰＥＧ−４のプレゼンテーションの範囲を殆ど静的なＢＩＦＳシーン及び流れたオーディオ及びビデオに限定する。

漫画や軽量なａｄｓ等のアプリケーションは正常に取り扱うことはできない。

１．３ セクションのバージョン
ＭＰＥＧ−２はセクションにバージョン番号を与えることを可能にする。しかし、バージョン番号の数値が増える場合、バージョン番号の意味は状態の変更の信号である。

上述のＲＡＰ機構によれば、ＭＰＥＧ−４により提供される更新機構の使用は許可されない。実際、始まるセッションは第１利用可能セクションとなり、次いで全て次のバージョン番号となる。これは更新機構を扱う上で非常に制限された複雑な方法となる。
１．４ ＵＳ−Ａ−５ ４７７ ２６３
この文献は、ビデオディストリビューション技術を開示している。この技術は、MPEG-2において実現され、ユーザーに早送り機能、巻き戻し機能、チャンネル一次停止機能を提供するものである。このような機能は、特定のプログラムの異なる開始時間を有した様々なバージョンを記憶させることで実現される。特定のユーザーにプレゼンテーションするために解読されるプログラムのポインタもまた記憶される。あるユーザーがある特定の機能を命じた場合、ポインタは異なる開始時間を有したプログラムを指すように変更される。
この技術の欠点は、いくつかの異なるプログラムの異なるバージョンを格納すると同時に取り扱うことが必要であるため、リソースを消費するものであることである。

２ 本発明のプレゼンテーション
２．１ 目的
本発明の目的は従来技術の異なる欠点を克服することである。

特に本発明は上述の問題点を解決することを目的とし、特にシステムデータ（ＢＩＦＳ−Ｃｏｍｍａｎｄ ストリーム、ＯＤ−ストリーム、ＭＰＥＧ−Ｊ及びＪＰＥＧ ストリーム）を保護し、例えばブロードキャストシーンのＢＩＦＳ更新機構等のＭＰＥＧ−４機能の保存（必要な帯域幅を大幅に増加せずに）することを目的とする。

２．２ 本発明の主な特徴
後述するこれら及びその他の目的は、連続的なパケットを有し、該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなり、前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信されてなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法によって達成される。

本発明によれば、この方法は同じセッションのバージョンを併合する機構を実現し、異なる時間で発した少なくとも２つのバージョンが、それらに固有（ｐｅｃｕｌｉａｒ）なセッション部分を先ず使用し、次いで共有（ｓｈａｒｅｄ）セッション部分を使用する。

本発明は、連続的なパケットを有し、該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法に関する。

本発明によれば、前記パケットのそれぞれは、前記フロー内で、対応するセッションの次のパケットを識別するためのポインタを有し、前記フロー内の少なくとも２つの異なるパケットのために、前記パケットの少なくとも幾つかが前記次のパケットとして識別されるように前記フローが構成される。

好ましくは、前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信され、前記ポインタは前記フロー内で、対応するセッションのバージョンの次のパケットを識別し、セッションの異なるバージョンに属するパケットのポインタは、バージョンを併合すべく、同じ次のパケットにポイントを合わせることが可能である。

オプションとして、前記ポインタは、現在のパケットのバージョンの識別子とは異なるバージョン識別子を有する。

本発明の便利な特徴によれば、前記各パケットは、
現在のバージョンの識別子と；
次のバージョンの識別子と、を有し、
前記次のバージョンの識別子は、
前記現在のバージョンの識別子、或いは
複数のバージョンが併合された場合には、異なるバージョンの識別子の何れかである。

オプションとして、前記方法はＭＰＥＧ２の標準を実施する。

前記データはＭＰＥＧ−４タイプであることが有利である。

本発明は上記方法によりブロードキャストできる構造を有するマルチメディア信号にも関する。

本発明は上記方法によりマルチメディア信号のブロードキャストを処理する手段を有するターミナルにも関する。

該ターミナルは、事前に受信した少なくとも幾つかのセッション部分を記憶する手段を更に有するのが有利である。

２．３ 図面
本発明のその他の特徴及び利点は、例示を目的とし限定を目的としない以下の好ましい２つの実施例及び添付図面により明らかとなろう。

２．４ ＭＰＥＧ−４セクションの定義
システムデータをアドレス指定するために、我々はＭＰＥＧ−４セクションの定義を拡大することを提案している。これは１つのＭＰＥＧ−４セクションを全ての異なるストリームタイプ用に定義するという意味である。そうすることにより、（例えばボタンをクリックする時に反復されるビープ音等の）ブロードキャストセッションで繰り返される小さなオーディオサウンド、小さなビデオクリップの機能を提供することが可能となる。

本明細書では、セクションのタイプはＢＩＦＳストリーム及びＯＤストリーム用に定義されている。我々は全てのＩＳＯ／ＩＥＣ１４４９６内容のための包括的なセクションタイプを追加することを提案している。以後、ＢＩＦＳ及びＯＤセクションタイプを使用しないことが推奨されよう。

修正の詳細は本明細書の最後に記載される。

２．５ ＭＰＥＧ−４セクションへの前方参照の追加
２．５．１ 機構
プレゼンテーションへのランダムアクセスで生じる問題に対処するため、我々はＭＰＥＧ−４セクションにおいて前方参照機構を定義する。これにより、互いに接続された何人かのユーザがパケット共有しながら同じ動的プレゼンテーションを経験することができる。

エンドユーザにプレゼンテーションを提供する一連のデータをセッションと呼ぶことにする。各セッションは単一のＰＭＴに関連している。

プレゼンテーションにランダムアクセスさせることは、幾つかのセッションを同時に送信することを意味する。我々に関連する送信時間、デコード時間及びコンポジションタイムという３つの異なる時間を考慮すべきである。明瞭化のためにコンポジションタイムはデコード時間と等しいと仮定する。デコード時間及びコンポジションタイムはプレゼンテーションされるオブジェクトにリンクされておりプレゼンテーションを成し遂げるものである。送信時間は一連の流されたデータユニットに関連する。

アクセスユニットを受信できる最後の時（ｌａｓｔ ｍｏｍｅｎｔ）は、そのデコード時間である。アクセスユニットはデコード時間後には到着できない。

我々の目的は如何にして多数のセッションを送信するか、即ち、セッション間でデコード時間を保存できるように送信に従って如何にしてデータユニットを順序付ける（ｏｒｄｅｒ）かを説明することである。即ち、複数のセッションを独立させて扱う場合、多重化の問題が良く知られている。しかし我々の場合、セクションデータを共有することにより、セッション間で送信されるデータを実行および分析（ｔｒｙ ａｎｄ ｆａｃｔｏｒｉｓｅ）することができる。これは必要な帯域幅を短くする助けとなる。

これを達成するため、我々は複数のセクションにおける前方参照機構を提案する。各セクションには番号が付けられ次のセクションを参照する。従って、２つのセクションは次の同じセクションを参照しても良い。

これを初期化するために、各ＰＭＴにおける最初のセクションを伝え（ドキュメントＳＬ＿記述子及びＦＭＣ＿記述子の最後を参照）、ｆｉｅｌｄ ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ（ベース及びエクステンション）によってセクションにバージョン付けするための新たな動作（ｓｅｍａｎｔｉｃｓ）を提案する。更新は高い周波数で送信しても良いため、我々はこの目的のために１０ビットを割り当てることを提案する。これら２つの変化により、更新機構にアドレス付けすることができ、どのセクションをセッションによりデコードするかを制御することができる。

するとバージョン付けの意味は、
( ＰＭＴを取得する場合、ターミナルは対応する記述子（ＳＬ或いはＦＭＣ）により示されるｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒを有するセクションを探さなければならない。
( セクションを取得する場合、ターミナルはｎｅｘｔ＿ｓｅｓｓｉｏｎ＿ｖｅｒｓｉｏｎ−ｎｕｍｂｅｒにより示されるｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒを有する次のセクションを探さなくてはならない。

２．５．１．１ 帰結及び結果
この機構は完全な更新機構を提供しＪＰＥＧ、ＭＰＥＧ−Ｊ等の高価なリソースを共有することを可能にする。

この機構はＭＰＥＧ−４ターミナルからは完全に独立しており、これはＭＰＥＧ−２トランスポート多重分離装置のアプリケーションの特定する一部を修正することを意味する（即ち、我々がＤＭＩＦの形式主義を考察する場合にはトランスポート層）。

我々は小さなプレゼンテーションを周期的に送信させるセクションに対する前方参照パターンを計算した。我々はこの機構により生成されるパケットを、セッションがデータを共有しない単一の多重化方式と比較した。各セッションが出発した周波数は１Ｈｚ、更新の周波数は４Ｈｚであり、プレゼンテーションには１２個の更新があった。その場合、使用した帯域幅はこの方式の半分であった。

２．６ 修正
２．６．１ ｔａｂｌｅ＿ｉｄ指定の表２−２６

２．６．２ セクション定義の表２−６３

ｔａｂｌｅ＿ｉｄ−ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの場合、この８ビットフィールドは「０ｘ０４」或いは「０ｘ０５」或いは「０ｘ０６」に送られる。値「０ｘ０４」はＩＳＯ／ＩＥＣ １４４９６−１のシーン記述ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｃｅｎｅ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｅｃｔｉｏｎを示す。「０ｘ０５」の値はＩＳＯ／ＩＥＣ １４４９６−１オブジェクト記述子ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｏｂｊｅｃｔ＿ｄｅｓｃｒｉｐｔｏｒ＿ｓｅｃｔｉｏｎを示す。「０ｘ０６」の値はＩＳＯ／ＩＥＣ １４４９６−１ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｇｅｎｅｒｉｃ＿ｓｅｃｔｉｏｎを示す。

ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドは「１」に設定すべきである。

ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドはこの規格では特定すべきではない。

ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ−この１２ビットのフィールドはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ＿＿ｌｅｎｇｔｈ ｆｉｅｌｄの直後からＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの最後までのセクションに残っているバイト数を特定する。このフィールドの値は４０９３（０ｘＦＦＤ）を超えてはならない。

ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ−この１６ビットのフィールドはこの規格では特定すべきではない。その使用法及び値はユーザが定義する。

ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ＿ｂａｓｅ−[この５ビットのフィールドとはＩＳＯ＿ＩＥＣ＿１４４９６＿ｔａｂｌｅのメディアバージョン番号の最も重要な部分を示す。ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒの最も重要ではない部分はｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−ｅｘｔｅｎｓｉｏｎである。メディアバージョン番号は表の各新たなメディアセッションと共に１０２４を法とする１ずつ増加する。メディアセッション制御はアプリケーションの自由裁量である。]

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドとは１に設定すべきである。

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ−この８ビットのフィールドはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの数を示す。オブジェクト記述子の表或いはシーン記述子の表の最初のＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値は０ｘ００である。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒの値は表においてそれぞれ追加的セクションと共に１ずつ増加する。

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ−この８ビットのフィールドはこのセクションの一部であるオブジェクト記述子表或いはシーン記述表の最後のセクションの数を特定する。

ｍｅｄｉａ ｓｅｓｓｉｏｎ ｎｕｍｂｅｒ ｅｘｔｅｎｓｉｏｎ−この５ビットのフィールドとはＩＳＯ−ＩＥＣ−１４４９６の表のメディアセッション番号の最も重要ではない部分を示す。

ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−この１０ビットのフィールドは取得しなければならない次のセクションの次のメディアセッション番号を示す。

ＰＭＴ＿ｈａｓ＿ＳＬ＿ｄｅｓｃｒｉｐｔｏｒ（ｃｕｒｒｅｎｔ＿ＰＩＤ）ー ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎを送信するＩＳＯ／ＩＥＣ １３８１８−１のプログラム要素用のプログラムマップ表における記述子ループにＳＬ記述子が含まれていれば真となる疑似機能。

ＳＬ＿Ｐａｃｋｅｔ（）−ＩＳＯ／ＩＥＣ １４４９６−１のサブ項目１０．２．２に特定される同期層パケット。

ＰＭＴ＿ｈａｓ＿ＦＭＣ＿ｄｅｓｃｒｉｐｔｏｒ（ｃｕｒｒｅｎｔ＿ＰＩＤ）−ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎを送信するＩＳＯ／ＩＥＣ １３８１８−１のプログラム要素用のプログラムマップ表における記述子ループにＦＭＣ記述子が含まれていれば真となる疑似機能。

ＦｌｅｘＭｕｘＰａｃｋｅｔ（）−ＩＳＯ／ＩＥＣ １４４９６−１のサブ項目１１．２．４に特定されるＦｌｅｘＭｕｘ Ｐａｃｋｅｔ。

ＣＲＣ＿３２−この３２ビットのフィールドは、ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの全体の処理後にＩＴＵ−Ｔ Ｒｅｃ． Ｈ．２２２．０Ｉ ＩＳＯ／ＩＥＣ １３８１８−１の付記Ａに定義されるデコーダにおいてレジスタの０出力を与えるＣＲＣ値を含む。

２．６３ 記述子
２．６．３．１ ＳＬ記述子

２．６．３．２ ＳＬ記述子内のフィールドの意味の定義
ＥＳ＿ＩＤ−この１６ビットのフィールドはＩＳＯ／ＩＥＣ １４４９６−１ ＳＬ−ｐａｃｋｅｔｉｚｅｄ ｓｔｒｅａｍの識別子である。

ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−このフィールドはターミナルによりコンパイルされるべきセクションのメディアセッションを特定する。

２．６．３．３ ＦＭＣ記述子

２．６．３．４ ＦＭＣ記述子内のフィールドの意味の定義
ＥＳ＿ＩＤ−この１６ビットのフィールドはＩＳＯ／ＩＥＣ １４４９６−１ＳＬ−ｐａｃｋｅｔｉｚｅｄ ｓｔｒｅａｍの識別子を特定する。

ＦｌｅｘＭｕｘＣｈａｎｎｅｌ−この８ビットのフィールドはこのＳＬ−ｐａｃｋｅｔｉｚｅｄ ｓｔｒｅａｍに使用されるＦｌｅｘＭｕｘチャネルの数を特定する。

ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−このフィールドはターミナルによりコンパイルされるべきセクションのメディアセッションを特定する。

２．７ 例（図３〜７）
図３は、本発明の全般的な方法を示す。ＭＰＥＧ−２信号は関連するセッションを記述した第１プログラムマップテーブル（ＰＭＴ）３１よりなる。信号には幾つかの同様なＰＭＴ３２（１つのみ図示）が挿入され、それらが信号に接続される度に対応するプレゼンテーションをターミナルに取得させる。ＰＭＴ３１，３２はそれぞれ異なるバージョンのセッションに対応する。

従って、ＰＭＴ３１はバージョン番号３１１（バージョン「１」）を有し、これにより、セッション（矢印３４）のバージョン「１」に考慮される以下のパケット３３をターミナルに識別させる。同様に、パケット３３は、
バージョン番号３３１（前のパケットにより指定される）と；
次のバージョン番号３３２（更なるパケットを指定、矢印３５ ）とを有する。

同じ構造がＰＭＴ３２（矢印３６，３７）からセッション（バージョン「２」）の第２のバージョンに使用される。

最初は、一般に次のバージョン番号が現在の番号である。しかし、本発明によれば、矢印３８に示すように次のバージョン番号が現在の番号ではなく異なるバージョン番号を指定することも可能である。この場合、パケット３９及び４０（同じセッションの２つの別個のバージョンに属する）が同じパケット４１に指定する。換言すると、２つのバージョン（或いはそれらバージョンの一方を飛ばす）の組み合わせが存在する。

従って、パケット４１は、同時にセッションの受理を開始しないターミナルにより使用されるであろうが、一度しか送信されない。これは、送信すべきデータの量を低減し（特にパケット４１が大きい場合）、ターミナル内でいつでも素早く開始するのに非常に有効である。

勿論、ターミナルの開始が遅ければ（即ち、ＰＭＴ３２で）、パケット４１の受信が早すぎることはあり得る（前のパケットの処理が達成されていない）。その場合、ターミナルはバッファ内の対応するデータの処理を延期すべくそれを記憶する。

同様に、いつでも要求できる特定のシーケンス（ジングル或いはシーン等）を一度だけ（或いは制限された回数だけ）送信することができ、ターミナルに記憶される。このシーケンスは要求され次第、指定されたバージョン番号と共に、既に記憶されたものとして識別される。

図４（図３と類似する）は、セッションの融合においてセッションを如何にして相互に作用するかを示す。図５はストリーム相互作用の場合にセッションを如何にして相互に作用するかを示す。ＰＭＴ５１，５２はＢＩＦＳの基本的ストリーム５３，５４（図４と同様）、及びＯＤの基本的ストリーム５５を指摘する。更に、ＪＰＥＧ−ＥＳストリーム５６はパケット５７及びパケット５８により指摘される。

図６は本発明による前方参照機構を示す。図７はＭＰＥＧ−２による本方法の使用例の詳細を開示する。これは時間の経過軸線の一連のパケットを示す（４本の連続した線を示し、線の第１パケットが前の線の最後のパケットに時間内に続く）。

［付記１］
ＭＰＥＧ−４の定義
１． アクセスユニット（ＡＵ）
基本的ストリーム内のデータの個々にアクセス可能な部分。アクセスユニットは、タイミング情報が帰する最小のデータ要素である。

２． アルファマップ
テクスチャーマップに関連する透明なパラメータの表示である。

３．オーディオビジュアルオブジェクト
オーディオ及び／或いはビジュアルな明示を有する自然或いは人工的な表示である。この表示はＢＩＦＳシーン記述内の１つのノード或いはノードの１グループに対応する。各オーディオビジュアルオブジェクトは一つ或いは複数のオブジェクト記述子を使用してゼロ或いはそれ以上の基本的ストリームに関連付けされている。

４． オーディオビジュアルシーン（ＡＶシーン）
シーン記述情報と共に目的及びユーザの相互作用から生じる挙動を含む空間的及び時間的経過順の属性を定義する一組のオーディオビジュアル目的である。

５． シーン用のバイナリフォーマット（ＢＩＦＳ）
パラメータシーン記述フォーマットのコード付けされた表示である。

６． バッファモデル
プレゼンテーションのデコードに必要なバッファリソースをＩＳＯ／ＩＥＣ １４４９６に準拠するターミナルが如何にして管理するかを定義するモデル。

７． 配列されたバイト
コード付けされたビットストリームにおける位置であり、該ストリームの第１ビットから複数の８ビット組分離れた位置。

８． クロックレフェレンス
時間ベースの読みを送信する特別な時間スタンプである。

９．コンポジション
空間及び時間の経過順の属性及びオーディオビジュアルオブジェクトの階層を識別するためのシーン記述情報を適用するプロセス。

１０．コンポジションメモリ（ＣＭ）
コンポジションユニットを有するランダムアクセスメモリである。

１１．コンポジションタイムスタンプ（ＣＴＳ）
コンポジションユニットの公称合成時間のテーブル示である。

１２．コンポジションユニット（ＣＵ）
アクセスユニットからデコーダが生成する出力のうち個々にアクセス可能な部分である。

１３． 圧縮層
基本的ストリームのコード化された表示とそのデコードされた表示との間の変換を行うＩＳＯ／ＩＥＣ １４４９６の規格によるシステムの層である。デコーダを含む。

１４． デコーダ
基本的ストリームのコード化された表示とそのデコードされた表示との間の変換を行う要素である。

１５． デコーディングバッファ（ＤＢ）
アクセスユニットを含むデコーダの入力でのバッファである。

１６． デコーダの構成
基本的ストリームの記述子に含まれる情報を使用して基本的ストリームデータを処理するためのデコーダの構成である。

１７． デコーディング時間スタンプ（ＤＴＳ）
アクセスユニットの公称デコーディング時間の表示である。

１８． 配信層
大量の多重化基本ストリーム或いはＦｌｅｘＭｕｘ ストリームを記憶或いは送信可能な配信機構（コンピュータネットワーク等）のための一般的アブストラクトである。

１９． 記述子
基本的ストリーム或いはコード化されたオーディオビジュアル目的の特定の態様を記述するために仕様されるデータ構造である。

２０． ＤＭＩＦアプリケーションインターフェース（ＤＡＩ）
ＩＳＯ／ＩＥＣ １４４９６−６に特定されるインターフェースである。該インターフェースはここでは、ＳＬパケット化されたストリームデータの交換と、同期層及び配信層間の関連する制御情報をモデル化するのに使用される。

２１． 基本的ストリーム（ＥＳ）
単一のソース要素から圧縮層上の単一の目的地要素までのモノメディアデータの一連の流れである。

２２．基本的ストリームの記述子
エンコードフォーマット、初期化情報、同期層構成及び基本的ストリームに送信される内容に関するその他の記述情報を記述するオブジェクト記述子に含まれる構造である。

２３． 基本的ストリームインターフェース（ＥＳＩ）
基本的ストリームデータの交換と、圧縮層及び同期層間の関連する制御情報をモデル化するインターフェースである。

２４． ＦｌｅｘＭｕｘチャネル（ＦＭＣ）
１つのＦｌｅｘＭｕｘストリーム内の異なる構成ストリームに属するデータ同士を区別するラベルである。ＦｌｅｘＭｕｘストリーム内の１つのＦｌｅｘＭｕｘチャネルにおける一連のデータは単一のＳＬパケット化されたストリームに対応する。

２５． ＦＩｅｘＭｕｘパケット
ＦｌｅｘＭｕｘツールにより管理される最小のデータ要素である。これはヘッダ及びペイロードよりなる。

２６． ＦＩｅｘＭｕｘストリーム
一つ或いは複数のＳＬパケット化されたストリームからのデータを有する一連のＦｌｅｘＭｕｘパケットであり、それぞれが自身のＦｌｅｘＭｕｘチャネルにより識別される。

２７． ＦｌｅｘＭｕｘツール
多重データストリームからのデータのインターリービングを許容するツールである。

２８． グラフィックプロフィール
シーン記述ストリーム内で使用できるＢＩＦＳツールの許容し得るグラフィック要素のセットを特定するプロフィールである。ＢＩＦＳはグラフィック記述要素とシーン記述要素の両方よりなる。

２９． インター
以前にコード化されたパラメータを使用して予測を構築するコード化パラメータ用のモード。

３０． イントラ
以前にコード化されたパラメータを参照せずにエンコードを実行するコード化パラメータ用のモードである。

３１．初期オブジェクト記述子
受信ターミナルに、ＩＳＯ／ＩＥＣ １４４９６に従ってエンコードされた内容の一部への初期アクセスを可能とさせる特別なオブジェクト記述子である。これはプロフィール及びレベル情報を運んで内容の複雑さを記載する。

３２． 知的所有権の識別（ＩＰＩ）
一つ或いは複数のオーディオビジュアル目的の一部に対応する一つ或いは複数の基本的ストリームの独特な識別である。

３３． 知的所有権の管理及び保護（ＩＰＭＰ）システム
知的所有権を管理し保護する機構及びツールのための一般的用語である。そのようなシステムへの唯一のインターフェースが規範的に定義されている。

３４． 目的クロックレフェレンス（ＯＣＲ）
基本的ストリームのエンコーダの時間ベースを回復するためにデコーダにより使用されるクロックレフェレンスである。

３５．オブジェクト内容情報（ＯＣＩ）
一つ或いは複数の基本的ストリームを介して送信される内容に関する追加的情報である。該情報は集合して基本的ストリームの記述子となったものか、或いはそれ事態が基本的ストリームとして運ばれたものである。

３６．オブジェクト記述子（ＯＤ）
基本的ストリーム記述子により一つ或いは複数の基本的ストリームとして集合し、論理従属性を定義する記述子である。

３７．オブジェクト記述子コマンド
オブジェクト記述子或いはオブジェクト記述子のＩＤのリスト上で行われる、例えば更新や削除などのアクションを識別するコマンドである。

３８．オブジェクト記述子プロフィール
許可されるオブジェクト記述子ツール及び同期層ツールの構成を特定するプロフィールである。

３９．オブジェクト記述子ストリーム
オブジェクト記述子コマンド内にカプセル化されたオブジェクト記述子を送信する基本的ストリームである。

４０． 目的時間ベース（ＯＴＢ）
所定の基本的ストリームに対して、従ってそのデコーダに対して有効な時間ベースである。ＯＴＢは目的クロックレフェレンスを介してデコーダに送信される。この目的のデコーディング処理に関する全ての時間スタンプはこの時間ベースを参照する。

４１． パラメトリックオーディオデコーダ
ＩＳＯ／ＩＥＣ １４４９６−３の規格により、６Ｋｂｐｓ〜１６Ｋｂｐｓ間のビットレートでコード化された音声信号を表しデコード化する一組のツールである。

４２． サービスの質（ＱｏＳ）
基本的ストリームが自身が送信される送信チャネルから要求する性能である。ＱｏＳは一組の（例えば、ビットレート、遅延ジッタ、ビットエラーレート等の）パラメータにより特徴付けされる。

４３． ランダムアクセス
基本的ストリーム内の任意な時点で表示の読み及びデコードを開始するプロセスである。

４４． レフェレンスポイント
定義された特性を有するシステムのデータ或いは制御フロー内の場所である。

４５． レンダリング
シーン記述及びその構成オーディオビジュアル目的を共通の表示スペースから特定の表示装置（即ち、スピーカや視界窓）に送信するアクションである。

４６． レンダリングエリア
シーン記述及びその構成オーディオビジュアル目的がレンダリングされるディスプレイ装置の一部分である。

４７．シーン記述
オーディオビジュアルオブジェクトの空間的な一時的位置、及びオブジェクトとユーザの相互作用から生じる挙動を記述する情報である。シーン記述はオブジェクト記述子へのポインタによりオーディオビジュアルデータを有する基本的ストリームを参照する。

４８． シーン記述ストリーム
シーン記述情報を送信する基本的ストリームである。

４９． シーングラフ要素
［付記１］に特定されるオーディオ、ビジュアル及びグラフィックのノードを除く、オーディオビジュアルシーン（オーディオビジュアル目的の空間的な一時的位置、及び目的とユーザの相互作用から生じる挙動）の構造のみに関連するＢＩＦＳツールの要素である。

５０． シーングラフプロフィール
シーン記述ストリーム内で使用し得るＢＩＦＳツールの許可可能なシーングラフ要素の組を定義するプロフィールである。ＢＩＦＳはグラフィック要素シーン記述要素の両方よりなる。

５１． ＳＬパケット化ストリーム（ＳＰＳ）
１つの基本的ストリームをカプセル化する一連の同期層パケットである。

５２． 構造的オーディオ
ＩＳＯ／ＩＥＣ １４４９６−３により定義される合成音効果及び音楽を記述する方法である。

５３． 同期層（ＳＬ）
タイミング、及び同期情報、ならびにフラグメンテーション及びランダムアクセス情報を提供するＤＭＩＦアプリケーションインターフェースを介する通信用の基本的ストリームデータを適応する層である。同期層シンタックスは構成可能であり、空として構成することができる。

５４． 同期層構成
基本的ストリーム記述子に含まれる情報を使用する特定の基本的ストリームのための同期層シンタックスの構成である。

５５． 同期層パケット（ＳＬ−Ｐａｃｋｅｔ）
構成可能なヘッダ及びペイロードよりなる同期層により管理される最小のデータ要素である。ペイロードは１つの完全なアクセスユニット或いは部分的なアクセスユニットより構成されていても良い。

５６． シンタックス記述言語（ＳＤＬ）
ビットストリームのシンタックスの記述を可能にするＩＳＯ／ＩＥＣ １４４９６−１により定義された言語である。

５７． システムデコーダモデル（ＳＤＭ）
ＩＳＯ／ＩＥＣ １４４９６に準拠したターミナルの挙動のアブストラクトビューを提供するモデルである。該モデルはバッファモデルとタイミングモデルよりなる。

５８． システム時間ベース（ＳＴＢ）
ターミナルの時間ベースである。そのレゾルーションはインプリメンテーションに依存する。ターミナル内の全ての作業はこの時間ベースに従って実行される。

５９． ターミナル
ＩＳＯ／ＩＥＣ １４４９６−１により定義された相互作用のオーディオビジュアルシーンのコード化された表示を送信、受信及び表示するシステムである。これは単独型でも或いは、ＩＳＯ／ＩＥＣ １４４９６に準拠したアプリケーションシステムの一部でも良い。

６０． 時間ベース
クロックの概念である。これは周期的にインクリメントするカウンタに相当する。

６１． タイミングモデル
コード化された情報の表示に如何にして（明確に或いはそれとなく）組み込むか、また受信ターミナルで如何にして回復するか等のタイミング情報の意味を特定するモデルである。

６２． 時間スタンプ
時間ベースに関連する特定の瞬間の表示である。

３ 略語及びシンボル
ＡＵ アクセスユニット
ＡＶ オーディオビジュアル
ＢＩＦＳ シーン用のバイナリフォーマット
ＣＭ コンポジショメモリ
ＣＴＳ コンポジションタイムスタンプ
ＣＵ コンポジショユニット
ＤＡＩ ＤＭＩＦアプリケーションインターフェース（ＩＳＯ／ＩＥＣ１４４９６−６参照）
ＤＢ デコーディングバッファ
ＤＴＳ デコーディング時間スタンプ
ＥＳ 基本的ストリーム
ＥＳＩ 基本的ストリームインターフェース
ＥＳＩＤ 基本的ストリーム識別子
ＦＡＰ 顔のアニメーションパラメータ
ＦＡＰＵ ＦＡＰ ユニット
ＦＤＰ 顔の定義パラメータ
ＦＩＧ ＦＡＰ 補間グラフ
ＦＩＴ ＦＡＰ 補間テーブル
ＦＭＣ ＦｌｅｘＭｕｘ チャネル
ＦＭＯＤ ｘ／ｙのリマインダを以下の式を満たすようにして返す浮動小数点モジューロ（リマインダ）演算子：
Ｆｍｏｄ（ｘ／ｙ）＝ｘ−ｋ^＊ｙ、ここでｋは整数であり、
ｓｇｎ（ｆｍｏｄ（ｘ／ｙ）＝ｓｇｎ（ｘ）、及び
ａｂｓ（ｆｍｏｄ（ｘ／ｙ））＜ａｂｓ（ｙ）
ＩＰ 知的所有権
ＩＰＩ 知的所有権の識別アクション
ＩＰＭＰ 知的所有権の管理及び保護
ＮＣＴ ノードコード化テーブル
ＮＤＴ ノードデータのタイプ
ＮＩＮＴ 最も近い整数値
ＯＣＩ オブジェクト内容の情報
ＯＣＲ オブジェクトクロックレフェレンス
ＯＤ オブジェクト記述子
ＯＤＩＤ オブジェクト記述子識別子
ＯＴＢ 目的時間ベース
ＰＬＬ フェースロックループ
ＱｏＳ サービスの質
ＳＡＯＬ 構造オーディオ調整言語
ＳＡＳＬ 構造オーディオスコア言語
ＳＤＬ シンタックス記述言語
ＳＤＭ システムデコーダモデル
ＳＬ 同期層
ＳＬ−Ｐａｃｋｅｔ 同期層パケット
ＳＰＳ ＳＬパケット化ストリーム
ＳＴＢ システム時間ベース
ＴＴＳ テキストから音声
ＵＲＬ ユニバーサルリソース位置決め装置
ＶＯＰ ビデオオブジェクト平面
ＶＲＭＬ 仮想現実モデル言語

［付記２］
ＭＰＥＧ−４プレゼンテーションの記述
幾つかのＪＰＥＧ、１つのオーディオ及び１つのビデオを有する通常のＭＰＥＧ−４プレゼンテーションを考えてみる。
( ＩＯＤ記述子
( システム基本的ストリーム（ＢＩＦＳ＆ＯＤ）
( ＪＰＥＧ及び従来の基本的ストリーム等のメディア

２．１ ＢＩＦＳ
プレゼンテーションは第１にダウンロードツールバーを表示し（第１要素はダウンロードされている最中である）、第２に３Ｄ（複雑過ぎない）シーンを表示し、それに対し幾つかのビデオクリップ（図１参照）をもたらす幾つかの更新が追加される。

２．２ ＯＤ
ＯＤ基本的ストリームは異なるメディア（ＪＰＥＧ、オーディオ、ビデオ等）にポイントを合わせるオブジェクト記述子を含む。

２．２．１ 時間の経過順のスケジューリング
クライアントがプレゼンテーションの異なる要素を受信方法を記載する。
必要なことは、
( ＯＤ記述子がそれらを参照した後（ＯＤＥｘｅｃｕｔｅの意味）、
( ＢＩＦＳ更新がそれらの使用を推奨する前、
にメディアが到着することである。

図２ａ及び２ｂは２つの推奨される時間の経過順の受信順序を示す。２つは共同価である。

［付記３］
ＭＰＥＧ−２上のＭＰＥＧ−４のマッピング
ＭＰＥＧ−２は以下の２つの主要なパケット構造を有する。
( ＰＥＳ（パケット化基本的ストリーム）パケット構造
( セクション構造

ＭＰＥＧ−４の内容をこれら２つの構造内で実行することができる。

ＩＯＤ記述子のキャリッジと、以下の異なる可能なキャリッジを考察する。
( システム基本的ストリーム（ＢＩＦＳ＆ＯＤ）、
( 従来の基本的ストリーム（Ａｕｄｉｏ＆Ｖｉｄｅｏ）

ＭＰＥＧ−４規格によれば、システムの基本的ストリーム（ＢＩＦＳ＆ＯＤ）、及び
従来の基本的ストリーム（Ａｕｄｉｏ＆Ｖｉｄｅｏ）はＭＰＥＧ−４ＳＬ層或いはＭＰＥＧ−４ ＦｌｅｘＭｕｘ層（ＳＬ層を含む）の何れかに先ず組み込まれる。

ＪＰＥＧ及びＭＰＥＧ−Ｊも考察される。

３．１ ＭＰＥＧ−２信号、ＭＰＥＧ−４記述子
ＭＰＥＧ−２ＰＭＴテーブルはエンドユーザに提案される如何なるＭＰＥＧ−２プログラムも記述する。このテーブルでは、必要であれば異なるＭＰＥＧ−４ストリームを記述するＩＯＤ、ＳＬ及びＦｌｅｘＭｕｘ記述子等の異なるＭＰＥＧ−４記述子が見られる。ＢＩＦＳ及びＯＤ基本的ストリームはプレゼンテーションの一部であるため、ＭＰＥＧ−４基本的ストリームはＭＰＥＧ−４ＳＬ層或いはＦｌｅｘＭｕｘ層（ＳＬ層を含む）内に組み込まれる。

ＰＭＴテーブル（他のサービス及びネットワーク指向テーブルを有する）が繰り返されて、如何なる瞬間でもクライアントに素早くチューニングさせることができる。通常、このようなテーブルは毎秒数回反復させることができる。

ＩＯＤはＰＭＴテーブルのＴＳ＿ｐｒｏｇｒａｍ＿ｍａｐ＿ｓｅｃｔｉｏｎの一部である。

ＰＭＴには、プレゼンテーションに関連するＭＰＥＧ−４ストリームのリストがＩＯＤに従う。各ストリームはそのＭＰＥＧ−４記述子により特徴付けられる。

３．１ ＭＰＥＧ−２の内容、ＭＰＥＧ−４のシステム及び従来の基本的ストリーム：
ＭＰＥＧ−２の内容はパケット化された基本的ストリーム（ＰＥＳ）かセクションの何れかである。

ＰＥＳストリームは一連のＰＥＳパケットである。パケットはその長さが可変であり（かなり長い）、同期性があり、かなり連続しているが保護されていない。ＰＥＳシンタックスは同期性を支持する全ての基本的ストリームに対して共通のシンタックスである。ＰＥＳシンタックスを使用する第１基本的ストリームはオーディオ及びビジュアル基本的ストリームである。

セクションは、そのパケットの長さが可変であり（かなり短い）、同期性はなく、かなり不連続であり、保護されている。保護されているということは、各セクションを受信すると、該セクションが破損しているか否かを認識することができることを意味する。セクションが最初に使用されるのは、信号を運ぶ時である。２番目に使用されるのはダウンロードの時である。円形コンベヤ機構はセクションのパケット化に基づいている。

システムの基本的ストリームとして現在存在する全てのＭＰＥＧ−４ストリームはＭＰＥＧ−４時間スタンプの割り当てを許容すべくＭＰＥＧ−４ＳＬ層、或いはＦｌｅｘＭｕｘ層（ＳＬ層を含む）に少なくとも組み込まなければならない。

ＳＬ或いはＦｌｅｘＭｕｘストリームに一度変換されたＢＩＦＳ及びＯＤ基本的ストリームはＰＥＳ或いはセクション内で運ぶことができ、オーディオ及びビデオの基本的ストリームは常にＰＥＳ内で運ばなくてはならない。

ＰＥＳに組み込まれたシステム基本的ストリームの両タイプを先ず考察し、次に両ケースにおいてＰＥＳに組み込まれたオーディオ及びビデオの基本的ストリームに関連するセクションへの組み込みを考察する。

３．２．１ 第１のケース：ＰＥＳに組み込まれたシステム及び従来の基本的ストリーム
主要な問題は如何なる時も如何なるクライアントに対してもプレゼンテーションにチューニングを許可することである。ランダムアクセスの問題。

特に、これはＭＰＥＧ−４ＳＬ層で支持されるＲＡＰフラッグ、及びＰＭＴテーブルを使用することにより達成することができる。

３．２．１．１． ランダムアクセスポイントフラッグ
この特徴を支持するために、プレゼンテーションの全ての基本的ストリーム用にＳＬレベルにあるランダムアクセスポイントフラッグ（ＲＡＰ）を使用することができる。

ＢＩＦＳでは、ＲＡＰが１の場合、ＢＩＦＳ ＡＵは進行するＢＩＦＳの更新の全ての組み込みを含む。これは最終的に膨大なサイズのＢＩＦＳ ＡＵ（＃１Ｍｂｙｔｅ）となる。何かのコヒーレント性を提供する場合、プレーヤーは全てのＪＰＥＧテキスチャを待たなければならないという問題がある。これは膨大な情報であり、重いダウンロードである。これは、ＪＰＥＧの場合、ターミナルは１つのＡＵしか読まず、更なる可能なランダムアクセスのために後から送信されるその後のＡＵに注意を払えない、或いはターミナルがクラッシュするかを意味する。

ＯＤの場合、ＲＡＰが１の時、ＯＤ ＡＵはその結果及び進行する更新の組み込みを含む。アプリケーションはＯｄのサイズにはあまり関連しない。オーディオ及びビデオの基本的ストリームは連続的に読み込まれる。オーディオ「ジングル」及びビデオ「クリップ」はこのような基本的ストリーム内では送信できない。

「ＲＡＰ付きのストリーム」の図はＲＡＰの能力を使用する簡単なシナリオを示す。

第１のケースでは、以下のものが連続してターミナルに到着する。
１． ＢＩＦＳ（ＲＡＰ＝１） メディアなしでシーンを記述
２． ＯＤ（ＲＡＰ＝１） 第１ＪＰＥＧにポイントを合わせる
３． ＪＰＥＧ（ＲＡＰ＝１） 第１ＪＰＥＧ
４． ＢＩＦＳ（ＲＡＰ＝０） ＪＰＥＧがマッピングされるイメージテキスチャを記述
５． ＯＤ（ＲＡＰ＝０） オーディオ及びビデオを導入するため
６． ｔｈｅ Ａｕｄｉｏ ａｎｄ Ｖｉｄｅｏ（第１ＡＵ）
７． ＢＩＦＳ（ＲＡＰ＝０）オーディオ及びビデオがマッピングされる場所を記述
８． ｔｈｅ Ａｕｄｉｏ、Ｖｉｄｅｏ（その他のＡＵ）

第２のケースでは、以下のものが連続してターミナルに到着する。
１． ＯＤ（ＲＡＰ＝１） 第１ＪＰＥＧ、オーディオ及びビデオにポイントを合わせる
２． オーディオ、ビデオ
３． 第１ＪＰＥＧ（ＲＡＰ＝１）
４． ＢＩＦＳ（ＲＡＰ＝１） 第１のケースのＢＩＦＳ更新を組み込む
５． ＯＤ（ＲＡＰ＝０） 第２ＪＰＥＧへポイントを合わせる
６． 第２ＪＰＥＧ（ＲＡＰ＝１）
７． ＢＩＦＳ（ＲＡＰ＝０）第２ＪＰＥＧへポイントを合わせる
８． オーディオ及びビデオ。

第２のケースではＯＤが最初に到着し、次いでＲＡＰ＝１を有するＢＩＦＳが進行するＢＩＦＳの更新コマンドの幾つかを組み込む。

第３のケースでは、以下のものが連続してターミナルに到着する。
１． ＯＤ（ＲＡＰ＝１） 第１ＪＰＥＧ及び第２ＪＰＥＧ、オーディオ及びビデオにポイントを合わせる。このＯＤは第２のケースのｗｏ ＯＤを組み込む。
２． オーディオ及びビデオ
３． 第１ＪＰＥＧ（ＲＡＰ＝１）
４． 第２ＪＰＥＧ（ＲＡＰ＝１）
５． ＢＩＦＳ（ＲＡＰ＝１） 第２のケースのＢＩＦＳ更新を組み込む
６． オーディオ及びビデオ

「ＲＡＰを有するストリーム」の図から発した「異なるセッション」の図はどのコマンドからセッションが構築されるかを示す。

第１のケースでは上記のものが連続してターミナルに到着し、
第２のケースでは上記のものが連続してターミナルに到着し、
第３のケースでは上記のものが連続してターミナルに到着する。

結論：
１． 事実、ビデオ及びオーディオは継続的に流れるのに対し、ＯＤ，ＢＩＦＳ及びＪＰＥＧにはダウンロードを使用する。
２． シーン或いはＯＤの復元に限って言えばそれらが何処にあるのか知るのは困難である。進歩的なダウンロードを得るのに利益はない。シーンの進歩的なロードを採用すれば、受信側と送信側の両方で複雑さが増す（サーバはシーンの現在の状況を管理しなければならない）。
３． 「ジングル」或いは「クリップ」は不可能である。
４． ＪＰＥＧの起こり得る問題。
５． ＭＰＥＧ−４システムの基本的ストリームは保護されない。

３．２．１．１．１． ＰＭＴテーブルの使用
他の解決策は、新たなストリームのために反復しなければならない各新たなＰＭＴ、新たなＰＥＤ内への割り当てである。その場合、ＰＭＴが変化した場合にターミナルにどのように反応させるかを正確に定義しなければならない。ＰＭＴだけがプレゼンテーションへの完全なアクセスを許容するストリームを参照する。ＩＯＤから発してＰＭＴを完全に解析しなければならない。

「パケットのＲＡＰ＋ＰＭＴストリーム」の図は、ＭＰＥＧ−４システムの基本的ストリームに割り当てられたＰＩＤがＰＭＴテーブルの各瞬間に変化するという事実に関連する異なる基本的ストリームのために存在するＲＡＰ設備を使用するシナリオを示す。

第１のケースは第１ＰＭＴ ＰＩＤ割り当てにより以下の物がターミナルに連続的の到着する。
１． ＢＩＦＳ（ＲＡＰ＝１） ＰＩＤ ＢＩＦＳ＿０の下でメディアなしにシーンを記述する
２． ＯＤ（ＲＡＰ＝１） ＰＩＤ ＯＤ＿０の下で第１ＪＰＥＧにポイントを合わせる
３． ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
４． ＢＩＦＳ（ＲＡＰ＝０） ＪＰＥＧがマッピングされるイメージテキスチャを記述する
５． ＯＤ（ＲＡＰ＝０） オーディオ及びビデオを導入する
６． オーディオ及びビデオ
７． ＢＩＦＳ（ＲＡＰ＝０） オーディオ及びビデオが何処でマッピングされるかを記述する
８． オーディオ及びビデオ

第２のケースは第１のケースの続きである。第２ＰＭＴは新たなセッションを開始するために送信されており、従って、ｐｔｅ ｐｒｅｃｅｄｉｎ ＰＭＴと共に確立されたセッション及び新たなセッションはこの新たなＰＭＴにより確立し共に生きる。以下の物がターミナルに連続的に到着する。
１． ＢＩＦＳ（ＲＡＰ＝１） ＰＩＤ ＢＩＦＳ＿１の下でメディアなしにシーンを記述する
２． ＯＤ（ＲＡＰ＝１） ＰＩＤ ＯＤ＿１の下で第１ＪＰＥＧにポイントを合わせる
３． ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
４． オーディオ及びビデオ
５． ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ ＢＩＦＳ＿１の下で第２ＪＰＥＧにポイントを合わせる
６． ＯＤ（ＲＡＰ＝０）、ＰＩＤ ＯＤ＿１の下でオーディオ及びビデオにポイントを合わせる
７． オーディオ及びビデオ
８． ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ ＢＩＦＳ＿１の下でオーディオ及びビデオにポイントを合わせる
９． その後、両セッションのＯＤ及びＢＩＦＳはインターリーブされる。

第３のケースでは、以下のものがターミナルに連続的に到着する。
１０． ＢＩＦＳ（ＲＡＰ＝１） ＰＩＤ ＢＩＦＳ＿２の下でメディアなしにシーンを記述する
１１． ＯＤ（ＲＡＰ＝１） ＰＩＤ ＯＤ＿２の下で第１ＪＰＥＧにポイントを合わせる
１２． ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
１３． オーディオ及びビデオ
１４． ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ ＢＩＦＳ＿２の下で第２ＪＰＥＧにポイントを合わせる
１５． ＯＤ（ＲＡＰ＝０）、ＰＩＤ ＯＤ＿２の下でオーディオ及びビデオにポイントを合わせる
１６． オーディオ及びビデオ
１７． ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ ＢＩＦＳ＿２の下でオーディオ及びビデオにポイントを合わせる
１８． その後、両セッションのＯＤ及びＢＩＦＳはインターリーブされる。

「パケットのＲＡＰ＋ＰＭＴストリーム」の図から発する「ＲＡＰ＋ＰＭＴパケットストリーム」の図はＢＩＦＳとＯＤアクセスユニットの複製が何処で生じるかを示している。

結論：
＊ ＰＩＤの浪費を伴う進歩的なダウンロードを支持することは可能かも知れない（シーンの継続中）
＊ ＢＩＦＳ及びＯＤの更新は異なるＰＩＤを有して複製しなければならない（ビデオ及びオーディオ以外）
＊ オーディオ「ジングル」及びビデオ「クリップ」も不可能である。
＊ ＭＰＥＧ−４システムの基本的ストリームの保護は支持されていない。

３．２．２ 従来の基本的ストリームはＰＥＳに残るが、ＢＩＦＳ及びＯＤはセクションに組み込まれる。

このようなシナリオでは、ＢＩＦＳ及びＯＤは保護される（それらの破損を検出することができる）。

ＢＩＦＳ及びＯＤの更新は異なるテーブル及びセクション下で実行される。各ＢＩＦＳ及びＯＤの更新にはバージョン番号が割り当てられる。バージョン番号は変化する。

従来、ターミナルが特定のテーブルを管理する場合、受信したテーブルだけを読み込み、関連するバージョン番号が変更したか否かをチェックする必要がある。バージョン番号が変化していれば、ターミナルはテーブルのコンパイルを避けることができる。バージョン番号が変化していれば、ターミナルはテーブルをコンパイルしなければならない。

しかし、バージョン番号を管理する厳格な方法はアプリケーションに依存する。

コメント：標準がストリーム用のセクションを提供しないため、ＪＰＥＧもＰＥＳ、ＭＰＥＧ−Ｊ内に運ばなければならない。

仮定：
( 我々は上述と同じ意味規則を維持する。新たなセッションのＢＩＦＳに対応する全てのＳＬパケットを新たなセクション（新たなバージョン番号により識別される）に挿入することができる。

資産：
( このような機構により、進歩的なダウンロードが可能となる。
( ＢＩＦＳ及びＯＤの破損を検出することができる。
( ＢＩＦＳ及びＯＤの簡単な挿入（各セッションはその適切な時間線を有する）。

欠点：
( 各セッションに対するＢＩＦＳ及びＯＤセクションの完全な複製
( 多重ＳＬセクション？（１つのセクションユニットにつき１つのＳＬパケットを強制しなければならない）
( ＢＩＦＳとＯＤ間に起こり得る同期性の問題（解決可能）
( 現在の規格はセクション内でＭＰＥＧ−Ｊ及びＪＰＥＧを許可していないか？

付記２で論じているシーン記述の内容の例を開示する。 付記２で論じている従来技術による推奨する時間の経過順の２つの受信順序を開示する。 本発明の方法の使用を示す。 セッションの融合においてセッションを如何にして相互に作用するかを示す。 ストリーム相互作用の場合にセッションを如何にして相互に作用するかを示す。 本発明による前方参照機構を示す。 ＭＰＥＧ−２コンテキストにおける図６の方法の例を示す。

Claims (7)

1. 連続する複数のパケット（３１，３２，３３，３９，４０，４１）を含むデータフローとしてのマルチメディア信号を複数のターミナルへブロードキャストする方法であって、
   複数のセッションが前記データフローの連続する複数のパケットに含まれる一組のパケット含み、
   前記セッションの内の少なくとも１つは、幾つかのバージョン（バージョン「１」、バージョン「２」）下で送信され、同じセッションの幾つかのバージョンは、異なる開始時間に対応し、
   前記セッションのそれぞれのバージョンは、バージョン識別子を含むプログラムマップテーブルを有し、これにより、考慮すべき次のパケットをターミナルに識別させ、前記各パケットは、
   現在のバージョンの識別子と、
   次のバージョンの識別子と、
   を有し、前記次のバージョンの識別子は、
   前記現在のバージョンの識別子となるか、或いは
   同じセッションの複数のバージョンを併合する場合には、異なるバージョンの識別子となり、異なる時間で発した少なくとも２つのバージョンが、前記それぞれのバージョンに固有なセッション部分を先ず使用し、次いで共有セッション部分を使用する、
   ことを特徴とする方法。
2. 前記各パケットは、前記データフロー内で、対応するバージョンの次のパケットを識別するためのポインタ（３４〜３８）を有し、
   セッションの異なるバージョンに属する各パケット（３９，４０）の少なくとも幾つかのポインタは、同じ次のパケット（４１）にポイントを合わせる、
   ことを特徴とする請求項１に記載の方法。
3. パケットの前記ポインタは、前記パケットの現在のバージョンの識別子（３１１）とは異なるバージョン識別子（３３２）を含むことを特徴とする請求項２に記載の方法。
4. 前記方法は、ＭＰＥＧ２標準規格を実施することを特徴とする請求項１〜３の何れかに記載の方法。
5. 前記方法は、ＭＰＥＧ４標準規格を実施することを特徴とする請求項１〜４の何れかに記載の方法。
6. 請求項１〜５の何れかに記載の方法によりマルチメディア信号のブロードキャストを処理する手段を備えるターミナルであって、
   セッションの現在のバージョンに対応するプログラムマップテーブル（３１，３２）を取得する手段であって、該プログラムマップテーブルがバージョンの識別子を含む手段と、
   前記セッションの前記バージョンで考慮すべき次のパケット（３３）であって前記セッションの前記現在のバージョンまたは別のバージョンに属しているパケットを、前記プログラムマップテーブルに含まれる前記バージョンの識別子に基づいて識別する手段と、
   前記パケットのデータに基づいて、前記セッションに対応するプレゼンテーションを構成する手段と、
   を備えることを特徴とするターミナル。
7. 事前に受信した少なくとも幾つかのセッション部分を記憶する手段を備えることを特徴とする、請求項６に記載のターミナル。

Images