(57)【要約】複数のターミナルへのマルチメディア信号のブロードキャスト方法。本発明は、連続的なパケットを有し、該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなり、前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信されてなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法に関する。本発明によれば、このような方法は同じセッションのバージョンを併合する機構を実現し、異なる時間で発した少なくとも２つのバージョンが、それらに特有なセッションの部分を先ず使用し、次いで共有されるセッションの部分を使用する。
2005502284.tif 000002
【特許請求の範囲】
【請求項１】
連続的なパケットを有し、
該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなり、
前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信されてなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法であって、
該方法は同じセッションのバージョンを併合する機構を実現し、異なる時間で発した少なくとも２つのバージョンが、それらに特有なセッションの部分を先ず使用し、次いで共有されるセッションの部分を使用することを含む方法。
【請求項２】
連続的なパケットを有し、
該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法であって、
前記パケットのそれぞれは、前記フロー内で、対応するセッションの次のパケットを識別するためのポインタを有し、
前記フロー内の少なくとも２つの異なるパケットのために、前記パケットの少なくとも幾つかが前記次のパケットとして識別されるように前記フローが構成されることを含む方法。
【請求項３】
前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信され、
前記ポインタは前記フロー内で、対応するセッションのバージョンの次のパケットを識別し、
セッションの異なるバージョンに属するパケットのポインタは、バージョンを併合すべく、同じ次のパケットにポイントを合わせることが可能であることを含む請求項２に記載の方法。
【請求項４】
前記ポインタは、現在のパケットのバージョンの識別子とは異なるバージョン識別子を含む請求項３に記載の方法。
【請求項５】
前記各パケットは、
現在のバージョンの識別子と；
次のバージョンの識別子と、を有し、
前記次のバージョンの識別子は、
前記現在のバージョンの識別子、或いは
複数のバージョンが併合された場合には、異なるバージョンの識別子の何れかであることを含む請求項４に記載の方法。
【請求項６】
前記方法はＭＰＥＧ２の標準を実施する、請求項１〜５の何れかに記載の方法。
【請求項７】
前記データはＭＰＥＧ４タイプである、請求項１〜６の何れかに記載の方法。
【請求項８】
請求項１〜７の何れかに記載の方法によりブロードキャストできる構造を有する、マルチメディア信号。
【請求項９】
請求項１〜７の何れかに記載の方法によりマルチメディア信号のブロードキャストを処理する手段を有する、ターミナル。
【請求項１０】
事前に受信した少なくとも幾つかのセッション部分を記憶する手段を更に有する、請求項９に記載のターミナル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プレゼンテーション（例えば、ＭＰＥＧ−２）へのランダムアクセスを可能にするブロードキャストにおけるマルチメディアプレゼンテーション、或いは信号（ＭＰＥＧ−４プレゼンテーション等）のブロードキャストに関する。
【背景技術】
【０００２】
このようなランダムアクセスを可能にするには、幾つかのターミナルが異なる間隔でプレゼンテーションの開始を取得できるように、所定のプレゼンテーションを何度かブロードキャストしなければならない。
【０００３】
ＭＰＥＧ−２トランスポートチャネル上でのＭＰＥＧ−４プレゼンテーションはＭＰＥＧ−２システムに対する補正書７において最近記載されている。
【０００４】
しかし、この補正書７は充分ではなく、更新が必要と思われる。本発明はＭＰＥＧ−４のプレゼンテーションを試行及び構築してから補正書７に従い該プレゼンテーションを達成できるか送信しないかを判断するものである。これは我々に放って置かれた或いは効率的に取り扱うことが不可能な機能があることを指摘させた。
【０００５】
その後、ＭＰＥＧ−４のプレゼンテーションの完全な送信を可能とするために補正書７の最小限の修正を試みた。このプロセスは徐々に増えていき、この書類は利用できない機能の点で現在何ができないか、及びＭＰＥＧ−２のトランスポートチャネル（以下、ＭＰＥＧ−２はＭＰＥＧ−２トランスポートを意味する）上でＭＰＥＧ−４プレゼンテーションのブロードキャストにおけるＭＰＥＧ−４の完全な機能を達成させるための我々の結論の点で現在何ができないかを整理しようとしていた。
【０００６】
１  従来技術：補正書７の監査
１．１  ＭＰＥＧ−４の基本的ストリームの意味
ＭＰＥＧ−２の特徴の１つはプレゼンテーションへのランダムアクセスを可能にすることである。ＭＰＥＧ−２に従いＭＰＥＧ−４のプレゼンテーションを送信する場合のこの意味に焦点を当ててみる。
【０００７】
現在の殆どのＭＰＥＧの用語は付記１に定義されている。
【０００８】
付記２にはＭＰＥＧ−４プレゼンテーションの例が記載されている。
【０００９】
付記３は従来技術によるＭＰＥＧ−２マッピング上のＭＰＥＧ−４に関連する。
【００１０】
１．１．１  ＢＩＦＳ  ＥＳ．
前提：プレゼンテーションへのランダムアクセスは２人の異なるユーザに同じプレゼンテーションを提供する。
【００１１】
主張：ＲＡＰではないＢＩＦＳコマンドＥＳのアクセスユニットはシーングラフ構造を修正する。
【００１２】
理由：そうでなければ、２人の異なるユーザが同じ時点で同じプレゼンテーションを有することはない。より正確には、プレゼンテーションへのランダムアクセスがあるから、我々は上記のような構造の修正の後にＲＡＰ  ＡＵを想定することができるのである。ＲＡＰは必ずシーンの交換であり、シーンの交換は修正されたシーングラフである。従って、２人のユーザが同じプレゼンテーションを経験することはない。
【００１３】
結論：
ａ）  更新はプレゼンテーション目的ではなくシーン構造の構築にのみ使用される。従って、プレゼンテーションは非常に動的ではない。多くのＭＰＥＧ−４プレゼンテーションはＭＰＥＧ−２上では送信できない。例えば漫画は正常には取り扱えないであろう。
【００１４】
ｂ）  静的なプレゼンテーションの場合でも、非常に短い時間内ではリソースが利用可能か或いは利用可能となるであろうが、これはプレゼンテーションが大きい場合、帯域幅のために不可能である。これは、貧弱なプレゼンテーションとなるであろう（暫くして画像抜けがおきるであろう）。
【００１５】
１．１．２  ＯＤＥＳ．
前提：プレゼンテーションへのランダムアクセスは２人の異なるユーザに同じプレゼンテーションを提供する。
【００１６】
主張：ＲＡＰではないＯＤＥＳのアクセスユニットはストリーム構造を修正すべきではない。
【００１７】
理由：そうでない場合、２人の異なるユーザが同じ時点で同じプレゼンテーションを有することはない（ＢＩＦＳを参照）。
【００１８】
結論：ＯＤはプレゼンテーション内の修正を意味しないため、これはプレゼンテーションを変更しない。
【００１９】
１．１．３  ＪＰＥＧ、ＭＰＥＧ−Ｊ
主張：ＪＰＥＧ及びＭＰＥＧ−ＪはＰＥＳに送信しなければならない。
【００２０】
理由：補正書７を参照されたい。セクションではＢＩＦＳ及びＯＤだけしか実行できない。
【００２１】
結論：
ａ）  セクションにおける既存のエラー検出機構は使用できない。ＪＰＥＧかＭＰＥＧ−Ｊか、或いはデータが破損しているかしていないかを知ることは重要であり得る。
【００２２】
ｂ）  ＪＰＥＧ或いはＭＰＥＧ−Ｊ用のアクセスユニットのコピーを受信するＭＰＥＧ−４ターミナルの挙動は特定されていない（或いは許可されない）。
【００２３】
１．１．４  オーディオ及びビデオ
主張：オーディオ及びビデオはＰＥＳに送信しなければならない。
【００２４】
理由：補正書７を参照されたい。セクションではＢＩＦＳ及びＯＤだけしか実行できない。
【００２５】
結論：
ａ）  オーディオ「ジングル（jingles）」及び「ビープ（beeps）」ならびに「ビデオクリップ（video clips）」は正常には取り扱えない。
【００２６】
ｂ）  オーディオ、ビデオ用のアクセスユニットのコピーを受信するＭＰＥＧ−４ターミナルの挙動は特定されていない（或いは許可されない）。
【００２７】
１．２  コメント
通常の使用状況では、我々は複数のユーザに対し、プレゼンテーションの一部を同じアニメーションとして経験させ、他の部分はそう見せたくない。補正書７はＭＰＥＧ−４のプレゼンテーションの範囲を殆ど静的なＢＩＦＳシーン及び流れたオーディオ及びビデオに限定する。
【００２８】
漫画や軽量なａｄｓ等のアプリケーションは正常に取り扱うことはできない。
【００２９】
１．３  セクションのバージョン
ＭＰＥＧ−２はセクションにバージョン番号を与えることを可能にする。しかし、バージョン番号の数値が増える場合、バージョン番号の意味は状態の変更の信号である。
【００３０】
上述のＲＡＰ機構によれば、ＭＰＥＧ−４により提供される更新機構の使用は許可されない。実際、始まるセッションは第１利用可能セクションとなり、次いで全て次のバージョン番号となる。これは更新機構を扱う上で非常に制限された複雑な方法となる。
【発明の開示】
【発明が解決しようとする課題】
【００３１】
２  本発明のプレゼンテーション
２．１  目的
本発明の目的は従来技術の異なる欠点を克服することである。
【００３２】
特に本発明は上述の問題点を解決することを目的とし、特にシステムデータ（ＢＩＦＳ−Ｃｏｍｍａｎｄ  ストリーム、ＯＤ−ストリーム、ＭＰＥＧ−Ｊ及びＪＰＥＧ  ストリーム）を保護し、例えばブロードキャストシーンのＢＩＦＳ更新機構等のＭＰＥＧ−４機能の保存（必要な帯域幅を大幅に増加せずに）することを目的とする。
【課題を解決するための手段】
【００３３】
２．２  本発明の主な特徴
後述するこれら及びその他の目的は、連続的なパケットを有し、該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなり、前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信されてなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法によって達成される。
【００３４】
本発明によれば、この方法は同じセッションのバージョンを併合する機構を実現し、異なる時間で発した少なくとも２つのバージョンが、それらに特有なセッションの部分を先ず使用し、次いで共有されるセッションの部分を使用する。
【００３５】
本発明は、連続的なパケットを有し、該パケットは複数のセッション内に構成され、各セッションは全体を形成する一組のパケットよりなる、データフローとしての複数のターミナルへのマルチメディア信号のブロードキャスト方法に関する。
【００３６】
本発明によれば、前記パケットのそれぞれは、前記フロー内で、対応するセッションの次のパケットを識別するためのポインタを有し、前記フロー内の少なくとも２つの異なるパケットのために、前記パケットの少なくとも幾つかが前記次のパケットとして識別されるように前記フローが構成される。
【００３７】
好ましくは、前記セッションの少なくとも幾つかは、異なる開始時間に対応する幾つかのバージョン下で送信され、前記ポインタは前記フロー内で、対応するセッションのバージョンの次のパケットを識別し、セッションの異なるバージョンに属するパケットのポインタは、バージョンを併合すべく、同じ次のパケットにポイントを合わせることが可能である。
【００３８】
オプションとして、前記ポインタは、現在のパケットのバージョンの識別子とは異なるバージョン識別子を有する。
【００３９】
本発明の便利な特徴によれば、前記各パケットは、
現在のバージョンの識別子と；
次のバージョンの識別子と、を有し、
前記次のバージョンの識別子は、
前記現在のバージョンの識別子、或いは
複数のバージョンが併合された場合には、異なるバージョンの識別子の何れかである。
【００４０】
オプションとして、前記方法はＭＰＥＧ２の標準を実施する。
【００４１】
前記データはＭＰＥＧ−４タイプであることが有利である。
【００４２】
本発明は上記方法によりブロードキャストできる構造を有するマルチメディア信号にも関する。
【００４３】
本発明は上記方法によりマルチメディア信号のブロードキャストを処理する手段を有するターミナルにも関する。
【００４４】
該ターミナルは、事前に受信した少なくとも幾つかのセッション部分を記憶する手段を更に有するのが有利である。
【００４５】
２．３  図面
本発明のその他の特徴及び利点は、例示を目的とし限定を目的としない以下の好ましい２つの実施例及び添付図面により明らかとなろう。
【発明を実施するための最良の形態】
【００４６】
２．４  ＭＰＥＧ−４セクションの定義
システムデータをアドレス指定するために、我々はＭＰＥＧ−４セクションの定義を拡大することを提案している。これは１つのＭＰＥＧ−４セクションを全ての異なるストリームタイプ用に定義するという意味である。そうすることにより、（例えばボタンをクリックする時に反復されるビープ音等の）ブロードキャストセッションで繰り返される小さなオーディオサウンド、小さなビデオクリップの機能を提供することが可能となる。
【００４７】
本明細書では、セクションのタイプはＢＩＦＳストリーム及びＯＤストリーム用に定義されている。我々は全てのＩＳＯ／ＩＥＣ１４４９６内容のための包括的なセクションタイプを追加することを提案している。以後、ＢＩＦＳ及びＯＤセクションタイプを使用しないことが推奨されよう。
【００４８】
修正の詳細は本明細書の最後に記載される。
【００４９】
２．５  ＭＰＥＧ−４セクションへの前方参照の追加
２．５．１  機構
プレゼンテーションへのランダムアクセスで生じる問題に対処するため、我々はＭＰＥＧ−４セクションにおいて前方参照機構を定義する。これにより、互いに接続された何人かのユーザがパケット共有しながら同じ動的プレゼンテーションを経験することができる。
【００５０】
エンドユーザにプレゼンテーションを提供する一連のデータをセッションと呼ぶことにする。各セッションは単一のＰＭＴに関連している。
【００５１】
プレゼンテーションにランダムアクセスさせることは、幾つかのセッションを同時に送信することを意味する。我々に関連する送信時間、デコード時間及び合成時間という３つの異なる時間を考慮すべきである。明瞭化のために、合成時間はデコード時間と等しいと仮定する。デコード時間及び合成時間はプレゼンテーションされるオブジェクトにリンクされておりプレゼンテーションを成し遂げるものである。送信時間は一連の流されたデータユニットに関連する。
【００５２】
アクセスユニットを受信できる最後の月は、そのデコード時間である。アクセスユニットはデコード時間後には到着できない。
【００５３】
我々の目的は如何にして多数のセッションを送信するか、即ち、セッション間でデコード時間を保存できるように送信に従って如何にしてデータユニットを注文するかを説明することである。即ち、複数のセッションを独立させて扱う場合、多重化の問題が良く知られている。しかし我々の場合、セクションデータを共有することにより、セッション間で送信されるデータを試みたり因数分解することができる。これは必要な帯域幅を短くする助けとなる。
【００５４】
これを達成するため、我々は複数のセクションにおける前方参照機構を提案する。各セクションには番号が付けられ次のセクションを参照する。従って、２つのセクションは次の同じセクションを参照しても良い。
【００５５】
これを初期化するために、各ＰＭＴ（ドキュメントＳＬ＿記述子及びＦＭＣ＿記述子の最後を参照）における第１セクションを知らせ、ｆｉｅｌｄ  ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ（ベース及びエクステンション）のおかげでセクションにバージョン付けするための新たな意味を提案する。更新は高い周波数で送信しても良いため、我々はこの目的のために１０ビットを割り当てることを提案する。これら２つの変化により、更新機構にアドレス付けすることができ、どのセクションをセッションによりデコードするかを制御することができる。
【００５６】
するとバージョン付けの意味は、
(  ＰＭＴを取得する場合、ターミナルは対応する記述子（ＳＬ或いはＦＭＣ）により示されるｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒを有するセクションを探さなければならない。
(  セクションを取得する場合、ターミナルはｎｅｘｔ＿ｓｅｓｓｉｏｎ＿ｖｅｒｓｉｏｎ−ｎｕｍｂｅｒにより示されるｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒを有する次のセクションを探さなくてはならない。
【００５７】
２．５．１．１  帰結及び結果
この機構は完全な更新機構を提供しＪＰＥＧ、ＭＰＥＧ−Ｊ等の高価なリソースを共有することを可能にする。
【００５８】
この機構はＭＰＥＧ−４ターミナルからは完全に独立しており、これはＭＰＥＧ−２トランスポート多重分離装置のアプリケーションの特定する一部を修正することを意味する（即ち、我々がＤＭＩＦの形式主義を考察する場合にはトランスポート層）。
【００５９】
我々は小さなプレゼンテーションを周期的に送信させるセクションの前方参照パターンを計算した。我々はこの機構により生成されるパケットを、セッションがデータを共有しない単一の多重化方式と比較した。各セッションが出発した周波数は１Ｈｚであり、更新の周波数は４Ｈｚであり、プレゼンテーションには１２個の更新があった。その場合、使用した帯域幅はこの方式の半分であった。
【００６０】
２．６  修正
２．６．１  ｔａｂｌｅ＿ｉｄ指定の表２−２６
【表１】
2005502284.tif 000003
【００６１】
２．６．２  セクション定義の表２−６３
【表２】
2005502284.tif 000004
【００６２】
ｔａｂｌｅ＿ｉｄ−ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの場合、この８ビットフィールドは「０ｘ０４」或いは「０ｘ０５」或いは「０ｘ０６」に送られる。値「０ｘ０４」はＩＳＯ／ＩＥＣ  １４４９６−１のシーン記述ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｃｅｎｅ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｅｃｔｉｏｎを示す。「０ｘ０５」の値はＩＳＯ／ＩＥＣ  １４４９６−１オブジェクト記述子ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｏｂｊｅｃｔ＿ｄｅｓｃｒｉｐｔｏｒ＿ｓｅｃｔｉｏｎを示す。「０ｘ０６」の値はＩＳＯ／ＩＥＣ  １４４９６−１ストリームを実行するＩＳＯ＿ＩＥＣ＿１４４９６＿ｇｅｎｅｒｉｃ＿ｓｅｃｔｉｏｎを示す。
【００６３】
ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドは「１」に設定すべきである。
【００６４】
ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドはこの規格では特定すべきではない。
【００６５】
ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ−この１２ビットのフィールドはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ＿＿ｌｅｎｇｔｈ  ｆｉｅｌｄの直後からＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの最後までのセクションに残っているバイト数を特定する。このフィールドの値は４０９３（０ｘＦＦＤ）を超えてはならない。
【００６６】
ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ−この１６ビットのフィールドはこの規格では特定すべきではない。その使用法及び値はユーザが定義する。
【００６７】
ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ＿ｂａｓｅ−[この５ビットのフィールドとはＩＳＯ＿ＩＥＣ＿１４４９６＿ｔａｂｌｅのメディアバージョン番号の最も重要な部分を示す。ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒの最も重要ではない部分はｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−ｅｘｔｅｎｓｉｏｎである。メディアバージョン番号は表の各新たなメディアセッションと共に１０２４を法とする１ずつ増加する。メディアセッション制御はアプリケーションの自由裁量である。]
【００６８】
ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ−この１ビットのフィールドとは１に設定すべきである。
【００６９】
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ−この８ビットのフィールドはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの数を示す。目的記述子の表或いはシーン記述子の表の最初のＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値は０ｘ００である。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒの値は表においてそれぞれ追加的セクションと共に１ずつ増加する。
【００７０】
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ−この８ビットのフィールドはこのセクションの一部である目的記述子表或いはシーン記述表の最後のセクションの数を特定する。
【００７１】
ｍｅｄｉａ  ｓｅｓｓｉｏｎ  ｎｕｍｂｅｒ  ｅｘｔｅｎｓｉｏｎ−この５ビットのフィールドとはＩＳＯ−ＩＥＣ−１４４９６の表のメディアセッション番号の最も重要ではない部分を示す。
【００７２】
ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−この１０ビットのフィールドは取得しなければならない次のセクションの次のメディアセッション番号を示す。
【００７３】
ＰＭＴ＿ｈａｓ＿ＳＬ＿ｄｅｓｃｒｉｐｔｏｒ（ｃｕｒｒｅｎｔ＿ＰＩＤ）ー  ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎを送信するＩＳＯ／ＩＥＣ  １３８１８−１のプログラム要素用のプログラムマップ表における記述子ループにＳＬ記述子が含まれていれば真となる疑似機能。
【００７４】
ＳＬ＿Ｐａｃｋｅｔ（）−ＩＳＯ／ＩＥＣ  １４４９６−１のサブ項目１０．２．２に特定される同期層パケット。
【００７５】
ＰＭＴ＿ｈａｓ＿ＦＭＣ＿ｄｅｓｃｒｉｐｔｏｒ（ｃｕｒｒｅｎｔ＿ＰＩＤ）−ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎを送信するＩＳＯ／ＩＥＣ  １３８１８−１のプログラム要素用のプログラムマップ表における記述子ループにＦＭＣ記述子が含まれていれば真となる疑似機能。
【００７６】
ＦｌｅｘＭｕｘＰａｃｋｅｔ（）−ＩＳＯ／ＩＥＣ  １４４９６−１のサブ項目１１．２．４に特定されるＦｌｅｘＭｕｘ  Ｐａｃｋｅｔ。
【００７７】
ＣＲＣ＿３２−この３２ビットのフィールドは、ＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎの全体の処理後にＩＴＵ−Ｔ  Ｒｅｃ．  Ｈ．２２２．０Ｉ  ＩＳＯ／ＩＥＣ  １３８１８−１の付記Ａに定義されるデコーダにおいてレジスタの０出力を与えるＣＲＣ値を含む。
【００７８】
２．６３  記述子
２．６．３．１  ＳＬ記述子
【表３】
2005502284.tif 000005
【００７９】
２．６．３．２  ＳＬ記述子内のフィールドの意味の定義
ＥＳ＿ＩＤ−この１６ビットのフィールドはＩＳＯ／ＩＥＣ  １４４９６−１  ＳＬ−ｐａｃｋｅｔｉｚｅｄ  ｓｔｒｅａｍの識別子である。
【００８０】
ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−このフィールドはターミナルによりコンパイルされるべきセクションのメディアセッションを特定する。
【００８１】
２．６．３．３  ＦＭＣ記述子
【表４】
2005502284.tif 000006
【００８２】
２．６．３．４  ＦＭＣ記述子内のフィールドの意味の定義
ＥＳ＿ＩＤ−この１６ビットのフィールドはＩＳＯ／ＩＥＣ  １４４９６−１ＳＬ−ｐａｃｋｅｔｉｚｅｄ  ｓｔｒｅａｍの識別子を特定する。
【００８３】
ＦｌｅｘＭｕｘＣｈａｎｎｅｌ−この８ビットのフィールドはこのＳＬ−ｐａｃｋｅｔｉｚｅｄ  ｓｔｒｅａｍに使用されるＦｌｅｘＭｕｘチャネルの数を特定する。
【００８４】
ｎｅｘｔ＿ｍｅｄｉａ＿ｓｅｓｓｉｏｎ＿ｎｕｍｂｅｒ−このフィールドはターミナルによりコンパイルされるべきセクションのメディアセッションを特定する。
【００８５】
２．７  例（図３〜７）
図３は、本発明の全般的な方法を示す。ＭＰＥＧ−２信号は関連するセッションを記述した第１プログラムマップテーブル（ＰＭＴ）３１よりなる。信号には幾つかの同様なＰＭＴ３２（１つのみ図示）が挿入され、それらが信号に接続される度に対応するプレゼンテーションをターミナルに取得させる。ＰＭＴ３１，３２はそれぞれ異なるバージョンのセッションに対応する。
【００８６】
従って、ＰＭＴ３１はバージョン番号３１１（バージョン「１」）を有し、これにより、セッション（矢印３４）のバージョン「１」に考慮される以下のパケット３３をターミナルに識別させる。同様に、パケット３３は、
バージョン番号３３１（前のパケットにより指定される）と；
次のバージョン番号３３２（更なるパケットを指定、矢印３５  ）とを有する。
【００８７】
同じ構造がＰＭＴ３２（矢印３６，３７）からセッション（バージョン「２」）の第２のバージョンに使用される。
【００８８】
最初は、一般に次のバージョン番号が現在の番号である。しかし、本発明によれば、矢印３８に示すように次のバージョン番号が現在の番号ではなく異なるバージョン番号を指定することも可能である。この場合、パケット３９及び３１０（同じセッションの２つの別個のバージョンに属する）が同じパケット３１１に指定する。換言すると、２つのバージョン（或いはそれらバージョンの一方を飛ばす）の組み合わせが存在する。
【００８９】
従って、パケット３１１は、同時にセッションの受理を開始しないターミナルにより使用されるであろうが、一度しか送信されない。これは、送信すべきデータの量を低減し（特にパケット３１１が大きい場合）、ターミナル内でいつでも素早く開始するのに非常に有効である。
【００９０】
勿論、ターミナルの開始が遅ければ（即ち、ＰＭＴ３２で）、パケット３１１の受信が早すぎることはあり得る（前のパケットの処理が達成されていない）。その場合、ターミナルはバッファ内の対応するデータの処理を延期すべくそれを記憶する。
【００９１】
同様に、いつでも要求できる特定のシーケンス（ジングル或いはシーン等）を一度だけ（或いは制限された回数だけ）送信することができ、ターミナルに記憶される。このシーケンスは要求され次第、指定されたバージョン番号と共に、既に記憶されたものとして識別される。
【００９２】
図４（図３と類似する）は、セッションの融合においてセッションを如何にして相互に作用するかを示す。図５はストリーム相互作用の場合にセッションを如何にして相互に作用するかを示す。ＰＭＴ５１，５２はＢＩＦＳの基本的ストリーム５３，５４（図４と同様）、及びＯＤの基本的ストリーム５５を指摘する。更に、ＪＰＥＧ−ＥＳストリーム５６はパケット５７及びパケット５８により指摘される。
【００９３】
図６は本発明による前方参照機構を示す。図７はＭＰＥＧ−２による本方法の使用例の詳細を開示する。これは時間の経過軸線の一連のパケットを示す（４本の連続した線を示し、線の第１パケットが前の線の最後のパケットに時間内に続く）。
【００９４】
［付記１］
ＭＰＥＧ−４の定義
１．  アクセスユニット（ＡＵ）
基本的ストリーム内のデータの個々にアクセス可能な部分。アクセスユニットは、タイミング情報が帰する最小のデータ要素である。
【００９５】
２．  アルファマップ
テクスチャーマップに関連する透明なパラメータの表示である。
【００９６】
３．  オーディオビジュアル目的
オーディオ及び／或いはビジュアルな明示を有する自然或いは人工的な表示である。この表示はＢＩＦＳシーン記述内の１つのノード或いはノードの１グループに対応する。各オーディオビジュアル目的は一つ或いは複数の目的記述子を使用してゼロ或いはそれ以上の基本的ストリームに関連付けされている。
【００９７】
４．  オーディオビジュアルシーン（ＡＶシーン）
シーン記述情報と共に目的及びユーザの相互作用から生じる挙動を含む空間的及び時間的経過順の属性を定義する一組のオーディオビジュアル目的である。
【００９８】
５．  シーン用のバイナリフォーマット（ＢＩＦＳ）
パラメータシーン記述フォーマットのコード付けされた表示である。
【００９９】
６．  バッファモデル
プレゼンテーションのデコードに必要なバッファリソースをＩＳＯ／ＩＥＣ  １４４９６に準拠するターミナルが如何にして管理するかを定義するモデル。
【０１００】
７．  配列されたバイト
コード付けされたビットストリームにおける位置であり、該ストリームの第１ビットから複数の８ビット組分離れた位置。
【０１０１】
８．  クロックレフェレンス
時間ベースの読みを送信する特別な時間スタンプである。
【０１０２】
９．  合成
空間及び時間の経過順の属性及びオーディオビジュアル目的の階層を識別するためのシーン記述情報を適用するプロセス。
【０１０３】
１０．  合成メモリ（ＣＭ）
合成ユニットを有するランダムアクセスメモリである。
【０１０４】
ｌｌ．  合成時間スタンプ（ＣＴＳ）
合成ユニットの公称合成時間の表示である。
【０１０５】
１２．  合成ユニット（ＣＵ）
アクセスユニットからデコーダが生成する出力のうち個々にアクセス可能な部分である。
【０１０６】
１３．  圧縮層
基本的ストリームのコード化された表示とそのデコードされた表示との間の変換を行うＩＳＯ／ＩＥＣ  １４４９６の規格によるシステムの層である。デコーダを含む。
【０１０７】
１４．  デコーダ
基本的ストリームのコード化された表示とそのデコードされた表示との間の変換を行う要素である。
【０１０８】
１５．  デコーディングバッファ（ＤＢ）
アクセスユニットを含むデコーダの入力でのバッファである。
【０１０９】
１６．  デコーダの構成
基本的ストリームの記述子に含まれる情報を使用して基本的ストリームデータを処理するためのデコーダの構成である。
【０１１０】
１７．  デコーディング時間スタンプ（ＤＴＳ）
アクセスユニットの公称デコーディング時間の表示である。
【０１１１】
１８．  配信層
大量の多重化基本ストリーム或いはＦｌｅｘＭｕｘ  ストリームを記憶或いは送信可能な配信機構（コンピュータネットワーク等）のための一般的アブストラクトである。
【０１１２】
１９．  記述子
基本的ストリーム或いはコード化されたオーディオビジュアル目的の特定の態様を記述するために仕様されるデータ構造である。
【０１１３】
２０．  ＤＭＩＦアプリケーションインターフェース（ＤＡＩ）
ＩＳＯ／ＩＥＣ  １４４９６−６に特定されるインターフェースである。該インターフェースはここでは、ＳＬパケット化されたストリームデータの交換と、同期層及び配信層間の関連する制御情報をモデル化するのに使用される。
【０１１４】
２１．  基本的ストリーム（ＥＳ）
単一のソース要素から圧縮層上の単一の目的地要素までのモノメディアデータの一連の流れである。
【０１１５】
２２．  基本的ストリームの記述子
エンコードフォーマット、初期化情報、同期層構成及び基本的ストリームに送信される内容に関するその他の記述情報を記述する目的記述子に含まれる構造である。
【０１１６】
２３．  基本的ストリームインターフェース（ＥＳＩ）
基本的ストリームデータの交換と、圧縮層及び同期層間の関連する制御情報をモデル化するインターフェースである。
【０１１７】
２４．  ＦｌｅｘＭｕｘチャネル（ＦＭＣ）
１つのＦｌｅｘＭｕｘストリーム内の異なる構成ストリームに属するデータ同士を区別するラベルである。ＦｌｅｘＭｕｘストリーム内の１つのＦｌｅｘＭｕｘチャネルにおける一連のデータは単一のＳＬパケット化されたストリームに対応する。
【０１１８】
２５．  ＦＩｅｘＭｕｘパケット
ＦｌｅｘＭｕｘツールにより管理される最小のデータ要素である。これはヘッダ及びペイロードよりなる。
【０１１９】
２６．  ＦＩｅｘＭｕｘストリーム
一つ或いは複数のＳＬパケット化されたストリームからのデータを有する一連のＦｌｅｘＭｕｘパケットであり、それぞれが自身のＦｌｅｘＭｕｘチャネルにより識別される。
【０１２０】
２７．  ＦｌｅｘＭｕｘツール
多重データストリームからのデータのインターリービングを許容するツールである。
【０１２１】
２８．  グラフィックプロフィール
シーン記述ストリーム内で使用できるＢＩＦＳツールの許容し得るグラフィック要素のセットを特定するプロフィールである。ＢＩＦＳはグラフィック記述要素とシーン記述要素の両方よりなる。
【０１２２】
２９．  インター
以前にコード化されたパラメータを使用して予測を構築するコード化パラメータ用のモード。
【０１２３】
３０．  イントラ
以前にコード化されたパラメータを参照せずにエンコードを実行するコード化パラメータ用のモードである。
【０１２４】
３１．  初期目的記述子
受信ターミナルに、ＩＳＯ／ＩＥＣ  １４４９６に従ってエンコードされた内容の一部への初期アクセスを可能とさせる特別な目的記述子である。これはプロフィール及びレベル情報を運んで内容の複雑さを記載する。
【０１２５】
３２．  知的所有権の識別（ＩＰＩ）
一つ或いは複数のオーディオビジュアル目的の一部に対応する一つ或いは複数の基本的ストリームの独特な識別である。
【０１２６】
３３．  知的所有権の管理及び保護（ＩＰＭＰ）システム
知的所有権を管理し保護する機構及びツールのための一般的用語である。そのようなシステムへの唯一のインターフェースが規範的に定義されている。
【０１２７】
３４．  目的クロックレフェレンス（ＯＣＲ）
基本的ストリームのエンコーダの時間ベースを回復するためにデコーダにより使用されるクロックレフェレンスである。
【０１２８】
３５．  目的内容情報（ＯＣＩ）
一つ或いは複数の基本的ストリームを介して送信される内容に関する追加的情報である。該情報は集合して基本的ストリームの記述子となったものか、或いはそれ事態が基本的ストリームとして運ばれたものである。
【０１２９】
３６．  目的記述子（ＯＤ）
基本的ストリーム記述子により一つ或いは複数の基本的ストリームとして集合し、論理従属性を定義する記述子である。
【０１３０】
３７．  目的記述子コマンド
目的記述子或いは目的記述子のＩＤのリスト上で行われる、例えば更新や削除などのアクションを識別するコマンドである。
【０１３１】
３８．  目的記述子プロフィール
許可される目的記述子ツール及び同期層ツールの構成を特定するプロフィールである。
【０１３２】
３９．  目的記述子ストリーム
目的記述子コマンド内にカプセル化された目的記述子を送信する基本的ストリームである。
【０１３３】
４０．  目的時間ベース（ＯＴＢ）
所定の基本的ストリームに対して、従ってそのデコーダに対して有効な時間ベースである。ＯＴＢは目的クロックレフェレンスを介してデコーダに送信される。この目的のデコーディング処理に関する全ての時間スタンプはこの時間ベースを参照する。
【０１３４】
４１．  パラメトリックオーディオデコーダ
ＩＳＯ／ＩＥＣ  １４４９６−３の規格により、６Ｋｂｐｓ〜１６Ｋｂｐｓ間のビットレートでコード化された音声信号を表しデコード化する一組のツールである。
【０１３５】
４２．  サービスの質（ＱｏＳ）
基本的ストリームが自身が送信される送信チャネルから要求する性能である。ＱｏＳは一組の（例えば、ビットレート、遅延ジッタ、ビットエラーレート等の）パラメータにより特徴付けされる。
【０１３６】
４３．  ランダムアクセス
基本的ストリーム内の任意な時点で表示の読み及びデコードを開始するプロセスである。
【０１３７】
４４．  レフェレンスポイント
定義された特性を有するシステムのデータ或いは制御フロー内の場所である。
【０１３８】
４５．  レンダリング
シーン記述及びその構成オーディオビジュアル目的を共通の表示スペースから特定の表示装置（即ち、スピーカや視界窓）に送信するアクションである。
【０１３９】
４６．  レンダリングエリア
シーン記述及びその構成オーディオビジュアル目的がレンダリングされるディスプレイ装置の一部分である。
【０１４０】
４７．  シーン記述
オーディオビジュアル目的の空間的な一時的位置、及び目的とユーザの相互作用から生じる挙動を記述する情報である。シーン記述は目的記述子へのポインタによりオーディオビジュアルデータを有する基本的ストリームを参照する。
【０１４１】
４８．  シーン記述ストリーム
シーン記述情報を送信する基本的ストリームである。
【０１４２】
４９．  シーングラフ要素
「Ｅｒｒｅｕｒ  ！  Ｓｏｕｒｃｅ  ｄｕ  ｒｅｎｖｏｉ  ｉｎｔｒｏｕｖａｂｌｅ」という句に特定されるオーディオ、ビジュアル及びグラフィックのノードを除く、オーディオビジュアルシーン（オーディオビジュアル目的の空間的な一時的位置、及び目的とユーザの相互作用から生じる挙動）の構造のみに関連するＢＩＦＳツールの要素である。
【０１４３】
５０．  シーングラフプロフィール
シーン記述ストリーム内で使用し得るＢＩＦＳツールの許可可能なシーングラフ要素の組を定義するプロフィールである。ＢＩＦＳはグラフィック要素シーン記述要素の両方よりなる。
【０１４４】
５１．  ＳＬパケット化ストリーム（ＳＰＳ）
１つの基本的ストリームをカプセル化する一連の同期層パケットである。
【０１４５】
５２．  構造的オーディオ
ＩＳＯ／ＩＥＣ  １４４９６−３により定義される合成音効果及び音楽を記述する方法である。
【０１４６】
５３．  同期層（ＳＬ）
タイミング、及び同期情報、ならびにフラグメンテーション及びランダムアクセス情報を提供するＤＭＩＦアプリケーションインターフェースを介する通信用の基本的ストリームデータを適応する層である。同期層シンタックスは構成可能であり、空として構成することができる。
【０１４７】
５４．  同期層構成
基本的ストリーム記述子に含まれる情報を使用する特定の基本的ストリームのための同期層シンタックスの構成である。
【０１４８】
５５．  同期層パケット（ＳＬ−Ｐａｃｋｅｔ）
構成可能なヘッダ及びペイロードよりなる同期層により管理される最小のデータ要素である。ペイロードは１つの完全なアクセスユニット或いは部分的なアクセスユニットより構成されていても良い。
【０１４９】
５６．  シンタックス記述言語（ＳＤＬ）
ビットストリームのシンタックスの記述を可能にするＩＳＯ／ＩＥＣ  １４４９６−１により定義された言語である。
【０１５０】
５７．  システムデコーダモデル（ＳＤＭ）
ＩＳＯ／ＩＥＣ  １４４９６に準拠したターミナルの挙動のアブストラクトビューを提供するモデルである。該モデルはバッファモデルとタイミングモデルよりなる。
【０１５１】
５８．  システム時間ベース（ＳＴＢ）
ターミナルの時間ベースである。そのレゾルーションはインプリメンテーションに依存する。ターミナル内の全ての作業はこの時間ベースに従って実行される。
【０１５２】
５９．  ターミナル
ＩＳＯ／ＩＥＣ  １４４９６−１により定義された相互作用のオーディオビジュアルシーンのコード化された表示を送信、受信及び表示するシステムである。これは単独型でも或いは、ＩＳＯ／ＩＥＣ  １４４９６に準拠したアプリケーションシステムの一部でも良い。
【０１５３】
６０．  時間ベース
クロックの概念である。これは周期的にインクリメントするカウンタに相当する。
【０１５４】
６１．  タイミングモデル
コード化された情報の表示に如何にして（明確に或いはそれとなく）組み込むか、また受信ターミナルで如何にして回復するか等のタイミング情報の意味を特定するモデルである。
【０１５５】
６２．  時間スタンプ
時間ベースに関連する特定の瞬間の表示である。
【０１５６】
３  略語及びシンボル
ＡＵ  アクセスユニット
ＡＶ  オーディオビジュアル
ＢＩＦＳ  シーン用のバイナリフォーマット
ＣＭ  合成メモリ
ＣＴＳ  合成時間スタンプ
ＣＵ  合成ユニット
ＤＡＩ  ＤＭＩＦ  アプリケーションインターフェース（ＩＳＯ／ＩＥＣ  １４４９６−６参照）
ＤＢ  デコーディングバッファ
ＤＴＳ  デコーディング時間スタンプ
ＥＳ  基本的ストリーム
ＥＳＩ  基本的ストリームインターフェース
ＥＳＩＤ  基本的ストリーム識別子
ＦＡＰ  顔のアニメーションパラメータ
ＦＡＰＵ  ＦＡＰ  ユニット
ＦＤＰ  顔の定義パラメータ
ＦＩＧ  ＦＡＰ補間グラフ
ＦＩＴ  ＦＡＰ補間テーブル
ＦＭＣ  ＦｌｅｘＭｕｘ  チャネル
ＦＭＯＤ  ｘ／ｙのリマインダを以下の式を満たすようにして返す浮動小数点モジューロ（リマインダ）演算子：
Ｆｍｏｄ（ｘ／ｙ）＝ｘ−ｋ*ｙ、ここでｋは整数であり、
ｓｇｎ（ｆｍｏｄ（ｘ／ｙ）＝ｓｇｎ（ｘ）、及び
ａｂｓ（ｆｍｏｄ（ｘ／ｙ））＜ａｂｓ（ｙ）
ＩＰ  知的所有権
ＩＰＩ  知的所有権の識別アクション
ＩＰＭＰ  知的所有権の管理及び保護
ＮＣＴ  ノードコード化テーブル
ＮＤＴ  ノードデータのタイプ
ＮＩＮＴ  最も近い整数値
ＯＣＩ  目的内容の情報
ＯＣＲ  目的クロックレフェレンス
ＯＤ  目的記述子
ＯＤＩＤ  目的記述子識別子
ＯＴＢ  目的時間ベース
ＰＬＬ  フェースロックループ
ＱｏＳ  サービスの質
ＳＡＯＬ  構造オーディオ調整言語
ＳＡＳＬ  構造オーディオスコア言語
ＳＤＬ  シンタックス記述言語
ＳＤＭ  システムデコーダモデル
ＳＬ  同期層
ＳＬ−Ｐａｃｋｅｔ  同期層パケット
ＳＰＳ  ＳＬパケット化ストリーム
ＳＴＢ  システム時間ベース
ＴＴＳ  テキストから音声
ＵＲＬ  ユニバーサルリソース位置決め装置
ＶＯＰ  ビデオ目的平面
ＶＲＭＬ  仮想現実モデル言語
【０１５７】
［付記２］
ＭＰＥＧ−４プレゼンテーションの記述
幾つかのＪＰＥＧ、１つのオーディオ及び１つのビデオを有する通常のＭＰＥＧ−４プレゼンテーションを考えてみる。
(  ＩＯＤ記述子
(  システム基本的ストリーム（ＢＩＦＳ＆ＯＤ）
(  ＪＰＥＧ及び従来の基本的ストリーム等のメディア
【０１５８】
【表５】
2005502284.tif 000007
【０１５９】
２．１  ＢＩＦＳ
プレゼンテーションは第１にダウンロードツールバーを表示し（第１要素はダウンロードされている最中である）、第２に３Ｄ（複雑過ぎない）シーンを表示し、それに対し幾つかのビデオクリップ（図１参照）をもたらす幾つかの更新が追加される。
【０１６０】
２．２  ＯＤ
ＯＤ基本的ストリームは異なるメディア（ＪＰＥＧ、オーディオ、ビデオ等）にポイントを合わせる目的記述子を含む。
【０１６１】
２．２．１  時間の経過順のスケジューリング
クライアントがプレゼンテーションの異なる要素を受信方法を記載する。
必要なことは、
(  ＯＤ記述子がそれらを参照した後（ＯＤＥｘｅｃｕｔｅの意味）、
(  ＢＩＦＳ更新がそれらの使用を推奨する前、
にメディアが到着することである。
【０１６２】
図２ａ及び２ｂは２つの推奨される時間の経過順の受信順序を示す。２つは共同価である。
【０１６３】
［付記３］
ＭＰＥＧ−２上のＭＰＥＧ−４のマッピング
ＭＰＥＧ−２は以下の２つの主要なパケット構造を有する。
(  ＰＥＳ（パケット化基本的ストリーム）パケット構造
(  セクション構造
【０１６４】
ＭＰＥＧ−４の内容をこれら２つの構造内で実行することができる。
【０１６５】
ＩＯＤ記述子のキャリッジと、以下の異なる可能なキャリッジを考察する。
(  システム基本的ストリーム（ＢＩＦＳ＆ＯＤ）、
(  従来の基本的ストリーム（Ａｕｄｉｏ＆Ｖｉｄｅｏ）
【０１６６】
ＭＰＥＧ−４規格によれば、システムの基本的ストリーム（ＢＩＦＳ＆ＯＤ）、及び
従来の基本的ストリーム（Ａｕｄｉｏ＆Ｖｉｄｅｏ）はＭＰＥＧ−４ＳＬ層或いはＭＰＥＧ−４  ＦｌｅｘＭｕｘ層（ＳＬ層を含む）の何れかに先ず組み込まれる。
【０１６７】
ＪＰＥＧ及びＭＰＥＧ−Ｊも考察される。
【０１６８】
３．１  ＭＰＥＧ−２信号、ＭＰＥＧ−４記述子
ＭＰＥＧ−２ＰＭＴテーブルはエンドユーザに提案される如何なるＭＰＥＧ−２プログラムも記述する。このテーブルでは、必要であれば異なるＭＰＥＧ−４ストリームを記述するＩＯＤ、ＳＬ及びＦｌｅｘＭｕｘ記述子等の異なるＭＰＥＧ−４記述子が見られる。ＢＩＦＳ及びＯＤ基本的ストリームはプレゼンテーションの一部であるため、ＭＰＥＧ−４基本的ストリームはＭＰＥＧ−４ＳＬ層或いはＦｌｅｘＭｕｘ層（ＳＬ層を含む）内に組み込まれる。
【０１６９】
ＰＭＴテーブル（他のサービス及びネットワーク指向テーブルを有する）が繰り返されて、如何なる瞬間でもクライアントに素早くチューニングさせることができる。通常、このようなテーブルは毎秒数回反復させることができる。
【０１７０】
ＩＯＤはＰＭＴテーブルのＴＳ＿ｐｒｏｇｒａｍ＿ｍａｐ＿ｓｅｃｔｉｏｎの一部である。
【０１７１】
ＰＭＴには、プレゼンテーションに関連するＭＰＥＧ−４ストリームのリストがＩＯＤに従う。各ストリームはそのＭＰＥＧ−４記述子により特徴付けられる。
【０１７２】
３．１  ＭＰＥＧ−２の内容、ＭＰＥＧ−４のシステム及び従来の基本的ストリーム：
ＭＰＥＧ−２の内容はパケット化された基本的ストリーム（ＰＥＳ）かセクションの何れかである。
【０１７３】
ＰＥＳストリームは一連のＰＥＳパケットである。パケットはその長さが可変であり（かなり長い）、同期性があり、かなり連続しているが保護されていない。ＰＥＳシンタックスは同期性を支持する全ての基本的ストリームに対して共通のシンタックスである。ＰＥＳシンタックスを使用する第１基本的ストリームはオーディオ及びビジュアル基本的ストリームである。
【０１７４】
セクションは、そのパケットの長さが可変であり（かなり短い）、同期性はなく、かなり不連続であり、保護されている。保護されているということは、各セクションを受信すると、該セクションが破損しているか否かを認識することができることを意味する。セクションが最初に使用されるのは、信号を運ぶ時である。２番目に使用されるのはダウンロードの時である。円形コンベヤ機構はセクションのパケット化に基づいている。
【０１７５】
システムの基本的ストリームとして現在存在する全てのＭＰＥＧ−４ストリームはＭＰＥＧ−４時間スタンプの割り当てを許容すべくＭＰＥＧ−４ＳＬ層、或いはＦｌｅｘＭｕｘ層（ＳＬ層を含む）に少なくとも組み込まなければならない。
【０１７６】
ＳＬ或いはＦｌｅｘＭｕｘストリームに一度変換されたＢＩＦＳ及びＯＤ基本的ストリームはＰＥＳ或いはセクション内で運ぶことができ、オーディオ及びビデオの基本的ストリームは常にＰＥＳ内で運ばなくてはならない。
【０１７７】
ＰＥＳに組み込まれたシステム基本的ストリームの両タイプを先ず考察し、次に両ケースにおいてＰＥＳに組み込まれたオーディオ及びビデオの基本的ストリームに関連するセクションへの組み込みを考察する。
【０１７８】
３．２．１  第１のケース：ＰＥＳに組み込まれたシステム及び従来の基本的ストリーム
主要な問題は如何なる時も如何なるクライアントに対してもプレゼンテーションにチューニングを許可することである。ランダムアクセスの問題。
【０１７９】
特に、これはＭＰＥＧ−４ＳＬ層で支持されるＲＡＰフラッグ、及びＰＭＴテーブルを使用することにより達成することができる。
【０１８０】
３．２．１．１．  ランダムアクセスポイントフラッグ
この特徴を支持するために、プレゼンテーションの全ての基本的ストリーム用にＳＬレベルにあるランダムアクセスポイントフラッグ（ＲＡＰ）を使用することができる。
【０１８１】
ＢＩＦＳでは、ＲＡＰが１の場合、ＢＩＦＳ  ＡＵは進行するＢＩＦＳの更新の全ての組み込みを含む。これは最終的に膨大なサイズのＢＩＦＳ  ＡＵ（＃１Ｍｂｙｔｅ）となる。何かのコヒーレント性を提供する場合、プレーヤーは全てのＪＰＥＧテキスチャを待たなければならないという問題がある。これは膨大な情報であり、重いダウンロードである。これは、ＪＰＥＧの場合、ターミナルは１つのＡＵしか読まず、更なる可能なランダムアクセスのために後から送信されるその後のＡＵに注意を払えない、或いはターミナルがクラッシュするかを意味する。
【０１８２】
ＯＤの場合、ＲＡＰが１の時、ＯＤ  ＡＵはその結果及び進行する更新の組み込みを含む。アプリケーションはＯｄのサイズにはあまり関連しない。オーディオ及びビデオの基本的ストリームは連続的に読み込まれる。オーディオ「ジングル」及びビデオ「クリップ」はこのような基本的ストリーム内では送信できない。
【０１８３】
「ＲＡＰ付きのストリーム」の図はＲＡＰの能力を使用する簡単なシナリオを示す。
【０１８４】
第１のケースでは、以下のものが連続してターミナルに到着する。
１．  ＢＩＦＳ（ＲＡＰ＝１）  メディアなしでシーンを記述
２．  ＯＤ（ＲＡＰ＝１）  第１ＪＰＥＧにポイントを合わせる
３．  ＪＰＥＧ（ＲＡＰ＝１）  第１ＪＰＥＧ
４．  ＢＩＦＳ（ＲＡＰ＝０）  ＪＰＥＧがマッピングされるイメージテキスチャを記述
５．  ＯＤ（ＲＡＰ＝０）  オーディオ及びビデオを導入するため
６．  ｔｈｅ  Ａｕｄｉｏ  ａｎｄ  Ｖｉｄｅｏ（第１ＡＵ）
７．  ＢＩＦＳ（ＲＡＰ＝０）オーディオ及びビデオがマッピングされる場所を記述
８．  ｔｈｅ  Ａｕｄｉｏ、Ｖｉｄｅｏ（その他のＡＵ）
【０１８５】
第２のケースでは、以下のものが連続してターミナルに到着する。
１．  ＯＤ（ＲＡＰ＝１）  第１ＪＰＥＧ、オーディオ及びビデオにポイントを合わせる
２．  オーディオ、ビデオ
３．  第１ＪＰＥＧ（ＲＡＰ＝１）
４．  ＢＩＦＳ（ＲＡＰ＝１）  第１のケースのＢＩＦＳ更新を組み込む
５．  ＯＤ（ＲＡＰ＝０）  第２ＪＰＥＧへポイントを合わせる
６．  第２ＪＰＥＧ（ＲＡＰ＝１）
７．  ＢＩＦＳ（ＲＡＰ＝０）第２ＪＰＥＧへポイントを合わせる
８．  オーディオ及びビデオ。
【０１８６】
第２のケースではＯＤが最初に到着し、次いでＲＡＰ＝１を有するＢＩＦＳが進行するＢＩＦＳの更新コマンドの幾つかを組み込む。
【０１８７】
第３のケースでは、以下のものが連続してターミナルに到着する。
１．  ＯＤ（ＲＡＰ＝１）  第１ＪＰＥＧ及び第２ＪＰＥＧ、オーディオ及びビデオにポイントを合わせる。このＯＤは第２のケースのｗｏ  ＯＤを組み込む。
２．  オーディオ及びビデオ
３．  第１ＪＰＥＧ（ＲＡＰ＝１）
４．  第２ＪＰＥＧ（ＲＡＰ＝１）
５．  ＢＩＦＳ（ＲＡＰ＝１）  第２のケースのＢＩＦＳ更新を組み込む
６．  オーディオ及びビデオ
【０１８８】
「ＲＡＰを有するストリーム」の図から発した「異なるセッション」の図はどのコマンドからセッションが構築されるかを示す。
【０１８９】
第１のケースでは上記のものが連続してターミナルに到着し、
第２のケースでは上記のものが連続してターミナルに到着し、
第３のケースでは上記のものが連続してターミナルに到着する。
【０１９０】
結論：
１．  事実、ビデオ及びオーディオは継続的に流れるのに対し、ＯＤ，ＢＩＦＳ及びＪＰＥＧにはダウンロードを使用する。
２．  シーン或いはＯＤの復元に限って言えばそれらが何処にあるのか知るのは困難である。進歩的なダウンロードを得るのに利益はない。シーンの進歩的なロードを採用すれば、受信側と送信側の両方で複雑さが増す（サーバはシーンの現在の状況を管理しなければならない）。
３．  「ジングル」或いは「クリップ」は不可能である。
４．  ＪＰＥＧの起こり得る問題。
５．  ＭＰＥＧ−４システムの基本的ストリームは保護されない。
【０１９１】
３．２．１．１．１．  ＰＭＴテーブルの使用
他の解決策は、新たなストリームのために反復しなければならない各新たなＰＭＴ、新たなＰＥＤ内への割り当てである。その場合、ＰＭＴが変化した場合にターミナルにどのように反応させるかを正確に定義しなければならない。ＰＭＴだけがプレゼンテーションへの完全なアクセスを許容するストリームを参照する。ＩＯＤから発してＰＭＴを完全に解析しなければならない。
【０１９２】
「パケットのＲＡＰ＋ＰＭＴストリーム」の図は、ＭＰＥＧ−４システムの基本的ストリームに割り当てられたＰＩＤがＰＭＴテーブルの各瞬間に変化するという事実に関連する異なる基本的ストリームのために存在するＲＡＰ設備を使用するシナリオを示す。
【０１９３】
第１のケースは第１ＰＭＴ  ＰＩＤ割り当てにより以下の物がターミナルに連続的の到着する。
１．  ＢＩＦＳ（ＲＡＰ＝１）  ＰＩＤ  ＢＩＦＳ＿０の下でメディアなしにシーンを記述する
２．  ＯＤ（ＲＡＰ＝１）  ＰＩＤ  ＯＤ＿０の下で第１ＪＰＥＧにポイントを合わせる
３．  ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
４．  ＢＩＦＳ（ＲＡＰ＝０）  ＪＰＥＧがマッピングされるイメージテキスチャを記述する
５．  ＯＤ（ＲＡＰ＝０）  オーディオ及びビデオを導入する
６．  オーディオ及びビデオ
７．  ＢＩＦＳ（ＲＡＰ＝０）    オーディオ及びビデオが何処でマッピングされるかを記述する
８．  オーディオ及びビデオ
【０１９４】
第２のケースは第１のケースの続きである。第２ＰＭＴは新たなセッションを開始するために送信されており、従って、ｐｔｅ  ｐｒｅｃｅｄｉｎ  ＰＭＴと共に確立されたセッション及び新たなセッションはこの新たなＰＭＴにより確立し共に生きる。以下の物がターミナルに連続的に到着する。
１．  ＢＩＦＳ（ＲＡＰ＝１）  ＰＩＤ  ＢＩＦＳ＿１の下でメディアなしにシーンを記述する
２．  ＯＤ（ＲＡＰ＝１）  ＰＩＤ  ＯＤ＿１の下で第１ＪＰＥＧにポイントを合わせる
３．  ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
４．  オーディオ及びビデオ
５．  ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ  ＢＩＦＳ＿１の下で第２ＪＰＥＧにポイントを合わせる
６．  ＯＤ（ＲＡＰ＝０）、ＰＩＤ  ＯＤ＿１の下でオーディオ及びビデオにポイントを合わせる
７．  オーディオ及びビデオ
８．  ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ  ＢＩＦＳ＿１の下でオーディオ及びビデオにポイントを合わせる
９．  その後、両セッションのＯＤ及びＢＩＦＳはインターリーブされる。
【０１９５】
第３のケースでは、以下のものがターミナルに連続的に到着する。
１０．  ＢＩＦＳ（ＲＡＰ＝１）  ＰＩＤ  ＢＩＦＳ＿２の下でメディアなしにシーンを記述する
１１．  ＯＤ（ＲＡＰ＝１）  ＰＩＤ  ＯＤ＿２の下で第１ＪＰＥＧにポイントを合わせる
１２．  ＪＰＥＧ（ＲＡＰ＝１）、第１ＪＰＥＧ、
１３．  オーディオ及びビデオ
１４．  ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ  ＢＩＦＳ＿２の下で第２ＪＰＥＧにポイントを合わせる
１５．  ＯＤ（ＲＡＰ＝０）、ＰＩＤ  ＯＤ＿２の下でオーディオ及びビデオにポイントを合わせる
１６．  オーディオ及びビデオ
１７．  ＢＩＦＳ（ＲＡＰ＝０）、ＰＩＤ  ＢＩＦＳ＿２の下でオーディオ及びビデオにポイントを合わせる
１８．  その後、両セッションのＯＤ及びＢＩＦＳはインターリーブされる。
【０１９６】
「パケットのＲＡＰ＋ＰＭＴストリーム」の図から発する「ＲＡＰ＋ＰＭＴパケットストリーム」の図はＢＩＦＳとＯＤアクセスユニットの複製が何処で生じるかを示している。
【０１９７】
結論：
＊  ＰＩＤの浪費を伴う進歩的なダウンロードを支持することは可能かも知れない（シーンの継続中）
＊  ＢＩＦＳ及びＯＤの更新は異なるＰＩＤを有して複製しなければならない（ビデオ及びオーディオ以外）
＊  オーディオ「ジングル」及びビデオ「クリップ」も不可能である。
＊  ＭＰＥＧ−４システムの基本的ストリームの保護は支持されていない。
【０１９８】
３．２．２  従来の基本的ストリームはＰＥＳに残るが、ＢＩＦＳ及びＯＤはセクションに組み込まれる。
【０１９９】
このようなシナリオでは、ＢＩＦＳ及びＯＤは保護される（それらの破損を検出することができる）。
【０２００】
ＢＩＦＳ及びＯＤの更新は異なるテーブル及びセクション下で実行される。各ＢＩＦＳ及びＯＤの更新にはバージョン番号が割り当てられる。バージョン番号は変化する。
【０２０１】
従来、ターミナルが特定のテーブルを管理する場合、受信したテーブルだけを読み込み、関連するバージョン番号が変更したか否かをチェックする必要がある。バージョン番号が変化していれば、ターミナルはテーブルのコンパイルを避けることができる。バージョン番号が変化していれば、ターミナルはテーブルをコンパイルしなければならない。
【０２０２】
しかし、バージョン番号を管理する厳格な方法はアプリケーションに依存する。
【０２０３】
コメント：標準がストリーム用のセクションを提供しないため、ＪＰＥＧもＰＥＳ、ＭＰＥＧ−Ｊ内に運ばなければならない。
【０２０４】
仮定：
(  我々は上述と同じ意味規則を維持する。新たなセッションのＢＩＦＳに対応する全てのＳＬパケットを新たなセクション（新たなバージョン番号により識別される）に挿入することができる。
【０２０５】
資産：
(  このような機構により、進歩的なダウンロードが可能となる。
(  ＢＩＦＳ及びＯＤの破損を検出することができる。
(  ＢＩＦＳ及びＯＤの簡単な挿入（各セッションはその適切な時間線を有する）。
【０２０６】
欠点：
(  各セッションに対するＢＩＦＳ及びＯＤセクションの完全な複製
(  多重ＳＬセクション？（１つのセクションユニットにつき１つのＳＬパケットを強制しなければならない）
(  ＢＩＦＳとＯＤ間に起こり得る同期性の問題（解決可能）
(  現在の規格はセクション内でＭＰＥＧ−Ｊ及びＪＰＥＧを許可していないか？
【図面の簡単な説明】
【０２０７】
【図１】付記２で論じているシーン記述の内容の例を開示する。
【図２】付記２で論じている従来技術による推奨する時間の経過順の２つの受信順序を開示する。
【図３】本発明の方法の使用を示す。
【図４】セッションの融合においてセッションを如何にして相互に作用するかを示す。
【図５】ストリーム相互作用の場合にセッションを如何にして相互に作用するかを示す。
【図６】本発明による前方参照機構を示す。
【図７】ＭＰＥＧ−２コンテキストにおける図６の方法の例を示す。
【図１】
2005502284.tif 000008
【図２】
2005502284.tif 000009
【図３】
2005502284.tif 000010
【図４】
2005502284.tif 000011
【図５】
2005502284.tif 000012
【図６】
2005502284.tif 000013
【図７】
2005502284.tif 000014
【国際公開パンフレット】
2005502284.tif 000015
2005502284.tif 000016
2005502284.tif 000017
2005502284.tif 000018
2005502284.tif 000019
2005502284.tif 000020
2005502284.tif 000021
2005502284.tif 000022
2005502284.tif 000023
2005502284.tif 000024
2005502284.tif 000025
2005502284.tif 000026
2005502284.tif 000027
2005502284.tif 000028
2005502284.tif 000029
2005502284.tif 000030
2005502284.tif 000031
2005502284.tif 000032
2005502284.tif 000033
2005502284.tif 000034
2005502284.tif 000035
2005502284.tif 000036
2005502284.tif 000037
2005502284.tif 000038
2005502284.tif 000039
2005502284.tif 000040
2005502284.tif 000041
2005502284.tif 000042
2005502284.tif 000043
2005502284.tif 000044
2005502284.tif 000045
2005502284.tif 000046
2005502284.tif 000047
2005502284.tif 000048
2005502284.tif 000049
2005502284.tif 000050
2005502284.tif 000051
2005502284.tif 000052
2005502284.tif 000053
2005502284.tif 000054
2005502284.tif 000055
【国際調査報告】
2005502284.tif 000056
2005502284.tif 000057
2005502284.tif 000058
2005502284.tif 000059