従属データストリームの送信方法
【課題】マルチキャスト通信における、ストリームユニットの効率的処理手法を提供する。
【解決手段】少なくとも１つの端末に向かう、アクセスユニットの形式で編成された少なくとも１つのデータストリームを送信する方法に関し、前記アクセスユニットの少なくとも幾つかが、端末における処理及び／又は前記ストリームの有用な速度を最適にするために、前記ストリーム又は他のストリームの従属しているユニットを指し示す少なくとも１つのポインタを含む。
【解決手段】少なくとも１つの端末に向かう、アクセスユニットの形式で編成された少なくとも１つのデータストリームを送信する方法に関し、前記アクセスユニットの少なくとも幾つかが、端末における処理及び／又は前記ストリームの有用な速度を最適にするために、前記ストリーム又は他のストリームの従属しているユニットを指し示す少なくとも１つのポインタを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の技術分野は、それぞれが基本ストリームユニット（elementary stream unit）によって構成された１つ又は数個のデータストリームの形式で、データを送信する分野である。より詳細には、本発明は、基本ストリームユニットが１つ又は数個の別のストリームユニットに従属している又はそれらに関連している場合、これらの基本ストリームユニットの処理を最適化することに関する。
【背景技術】
【０００２】
ある信号、例えば、マルチメディア形の信号が同期して１つのチャネルを介して送信される場合、ストリームユニットの処理にはほとんどあるいは全く問題が発生しない。必要なデータは前もって受信される。
【０００３】
他方、数個の送信チャネル及び／又は数個のサーバにより実現され、それらが所望の信号の一部をそれぞれ送信する非同期のシステムでは、これは当てはまらない。例えば、ＩＰ形のネットワークを介して送信又は一斉送信する場合である。
【０００４】
この場合、まだ受信していない他のストリームユニットを完結させることになっているストリームユニットを先に受信することがある。例えば、これはあるより高い階層レベルのデータ圧縮情報の可能性があり、データは階層符号化法を用いて符号化できる（これにより、ストリームは所定の階層レベルに対応させることができる）。このため、圧縮データの処理はランダムな結果を招き、一般に再生された信号に著しい劣化をもたらしたり、デコーダを完全にブロッキングすることさえある。
【０００５】
マルチメディアの同期化に関する従来の技術は、本来、ＲＴＰベースの伝送プロトコルとＭＰＥＧ−４「同期層(synchronisation)」とによって表される。これまでの取り組みでは、同期機構は、オーディオとビデオのストリームとを、遅延なしに表現できるように、時間的に同期させるように主に設計されてきた。このデータは、タイムスタンピングシステム（time stamping system）（基準クロック、デコーディングスタンプ及びプレゼンテーションスタンプ）を用いて伝達される。
【０００６】
種々の時間的及び空間的な充実化(enrichment)レベルを使用して表現可能なフレームを作成する階層符号化法の出現により、発明者は同期化に対する新しい要求が持ち上がっていることに注目した。
【０００７】
実際に、ストリームを（表示する間だけではなく）デコードする前に、同期化する必要がある。正しいフレームを作成するためには、ユニットをデコードするために必要なユニットを識別しなければならないため、この制約はプレゼンテーションの同期化よりも一層複雑である。たった１つの遅延のために、あるストリームが全体として使用できなくなり、さらにそれに基づいた全てのストリームが使用できないものになる可能性がある。このことは、発明者が確認した新規で明白でない問題である。
【０００８】
端末が、受信していなければならないが、まだ受信していないデータ（例えば、デコーディングキー）を用いて、受信したストリームユニットをデコード又は解読するする必要がある場合、同様の問題が発生する。この場合も、このデコーディング処置の結果は、少なくとも非効率であり、一般的に（再生された信号の点で）有害であり、この端末にブロッキングをもたらす可能性がある。これらの２つの場合では、望まれていない厄介な処理が行われることになる。
【０００９】
同報通信（マルチキャスト又は同報通信）システムの中で発見された別の重大な問題は、ユーザがどのような場合でも自分達が選択した全てのストリームを受信するために接続できるように、同じデータをマルチ同報通信（multibroadcast）する必要があることである。この特定の見解は、本願の出願人による未公開の欧州特許出願第ＥＰ−０１４６００４６２号の中ですでに説明されている。この技術によれば、各種の伝送の種類の特異性を考慮に入れて各ストリームユニットの処理を進める伝送レベルで処理が行われる。
【００１０】
同報通信及びマルチキャストのシナリオにおけるマルチメディア表示に関する従来の技術は、「カルーセルＭＰＥＧ−４（carousel MPEG-4）」の仕様書の中で説明されている。それにもかかわらず、その結果、いくつかの機能を用いることができず、またいくつかの機能はデータ速度の多くを消費することになる。２つの考えられる配信シナリオでは、マルチメディア表示に対するいくらかの入力された要素はいかなる時点でも必ず必要とされる(indicate)ことである。このことは、シーン例えばＢＩＦＳのシーンやテクスチャーの記述に関してデータを繰り返し使用することにつながる。
【００１１】
マルチメディアのコンテンツが豊富になると、この単純な繰返しは許容できないものではなくなり、ダウンロード時間が過大になる。さらに、この仕様では、幾つかのマルチメディア要素（短いオーディオ／ビデオのクリップ）を同報通信できない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
特に、本発明の目的は、上記技術の様々な不都合を克服することである。
【００１３】
より具体的に言うと、本発明の目的は、ストリームユニットが１つ又は数個の別のストリームユニットに依存する又は関連する場合、ストリームユニットを効率的に処理できる技術を提供することである。
【００１４】
さらに、本発明の目的は、特に、階層符号化又は基本データと充実化又は富化(enrichment)データとを結び付ける符号化方法によって符号化されたデータの場合、リンクされたストリームの処理を可能にするような技術を提供することである。
【００１５】
本発明の別の目的は、マルチ同報通信のシナリオの送信を最適化できる、また特に、受信時の品質を低下させずに使用するリソースの量を減らすことができる技術を提供することである。
【００１６】
換言すると、本発明の目的は、端末で実行される処理を、数量と品質との両方の観点において最適化することである。
【課題を解決するための手段】
【００１７】
これらの目的と後述する他の目的とは、本発明に基づいて、少なくとも１つの端末に少なくとも１つのデータストリームを送信する手順を用いて達成される。この手順では、データストリームはストリームユニットに編成される。本発明によれば、これらのストリームユニットの少なくとも幾つかは、前記データストリーム又は端末により先に受信されている別のデータストリーム中の、必要先行ユニットと呼ばれる少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含む。これは、必要先行ユニットが受信されていない場合、前記端末の中でこのストリームユニットの処理を行わないようにするためである。
【００１８】
このように、解像度の品質などを向上するために、端末における処理を制限し、ストリームユニットの処理をより容易にできる論理的な同期システムを利用できる。
本発明に基づいてこのように定義されたデータの形式は、ストリームの送信及び受信に対してだけでなく、それらの同報通信（ブロードキャスティング）、記録及び保管に関しても実行することができる。
【００１９】
本発明はこのように、特に、ストリーム又はストリームユニットの「バック」同期（"back" synchronization）という新しい問題を確認することと、処理するために全ての要素を利用できない場合、最も効率的な解決策はストリームユニットを処理することではないことと言う明白でない所見に基づいている。実際に、信号再生の点に関しては、ストリームユニットをデコードすることではなく、それを無視することが好ましいと思われる。このことは、再生された信号の劣化又は端末のブロッキングさえも引き起こす可能性がある。
【００２０】
好適には、本発明の方法は、別個に送信される少なくとも２つのデータストリームを送信することを含む。第１のデータストリームの１つのストリームユニットは、少なくとも１つの第２のデータストリーム中の少なくとも１つの必要先行ユニット(required previous unit)を指し示す。ここで、第１のデータストリームの前記ストリームユニットは、前記第２のストリーム内に含まれた充実化データを含む。
【００２１】
この場合、これらのデータストリームは、好適には、階層符号化の種々の階層レベルに対応させることができる。ここで、所与の階層レベルのストリームユニットの処理は、対応する下位の階層レベルのストリームユニットが受信された場合にのみ行われる。
【００２２】
このストリームユニットは、少なくとも１つの先行するユニットを指し示すことができる。これは、必要先行ユニットのシーケンスを定義する。
【００２３】
本発明の好ましい特性によれば、これらのポインタの少なくとも１つにより、考慮されているストリームユニットのデコーディング及び／又は解読を可能にするデータを含む少なくとも１つの必要先行ユニットを見つけ出すことができる。
【００２４】
前記必要先行ユニットは、端末が考えられたストリームユニットのデータをデコード及び／又は解読し、次にデコード後に表示する必要があるかどうかを決定することができるデータを含むことが好ましい。
【００２５】
別の好ましい方法によれば、これらのポインタの少なくとも１つは前記端末から知ることができるデータを指し示すため、端末は対応するストリームユニットを処理することができるかどうかを決定することができる。
【００２６】
好ましくは、本発明の別の態様によれば、これらのストリームユニットの少なくとも１つは、前記データストリーム中の又は近い将来に受信することができる別のデータストリーム中の少なくとも１つのストリームユニットを指す少なくとも１つのポインタを含む。
【００２７】
近い将来に受信することができるこの又はこれらのストリームユニットは、前記ポインタとのリンクを作ることができるマーカを有することが好ましい。
【００２８】
このため、別個の時間に送信された少なくとも２つの同様のストリームユニットのポインタは、近い将来に受信される同じストリームユニットを指し示すことができることが好ましい。
【００２９】
好ましくは、本発明の方法は、下記を含むグループに属する少なくとも２つの役割の中からのポインタの役割を示すインディケータ (indicator）を実現する。すなわち、検討されるストリームユニットを考慮できるようにするために、デコードする必要がある少なくとも１つの先行するストリームユニットを指し示すことと、
検討されるストリームユニットをデコード及び／又は解読するために必要なデータを含む少なくとも１つの先行するストリームユニットを指し示し、及び／又は保護システムのステータスへの参照を指し示すことと、少なくとも１つの後続するストリームユニットを指し示すこととである。
【００３０】
これらのデータストリームの少なくとも幾つかが、この役割を定義する従属記述子（dependency descriptor）を含むことが好ましい。
【００３１】
これらのデータストリームの少なくとも幾つかが、それ自体を必要先行ユニットとして識別できる従属マーカ（dependence marker）及び／又は前記ストリームの中の前記ストリームユニットの識別マーカ(identification marker)を含むことが好ましい。
【００３２】
本発明の方法が、受信されたストリームユニットの予備的な処理を必要としないような同期レベルで実行されることが好ましい。
【００３３】
本発明は、前述した送信手順に基づいて送信された１つ又は数個のデータストリームにも関連する。前述したように、そのようなデータ形式は、送信、同報通信、受信、及び記録（例えば、ビデオレコーダ又は光ディスクレコーダを用いる場合）並びにデータの保管（例えば、ＣＤ−ＲＯＭ、テープ、遠隔のサーバなど）のために使用できる。
【００３４】
また、本発明はこれらの動作の幾つかを容易に結合することができることに注意されたい。例えば、幾つかのデータストリームは同報通信とすることができ、別のデータストリームはＣＤ−ＲＯＭ又はサーバに送ることができる。ここで、第２のデータストリームは、第１のデータストリームをデコード（又は最適化）するために知られている必要がある。
【００３５】
そのようなデータストリームは、互いに独立して送信されるストリームユニットに編成される。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末で先に受信されている別のストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指し示し、前記ストリームユニットの処理は、必要先行ユニットが受信されていない場合は、前記端末では実行されないようにされる。
【００３６】
本発明は、互いに独立して送信されるストリームユニットに編成された少なくとも１つのデータストリームの形式で、少なくとも１つの端末に送信されるようにデータを作成したサーバにも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末で先に受信されている別のストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指す。
【００３７】
本発明は、互いに独立して送信されるストリームユニットに編成された少なくとも１つのデータストリームを受信することができる端末にも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末により既に受信されている別のストリーム中にある、必要先行ユニットと呼ばれる少なくとも１つのストリームユニットを指す。
【００３８】
本発明は、互いに独立して送信されるストリームユニットの中に編成された少なくとも１つのデータストリームを受信する手順にも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末により既に受信されている別のストリーム中にある、少なくとも１つのストリームユニット（必要先行ユニットと呼ばれる）を指し示す。また、この受信手順は下記のステップ、すなわち、あるストリームユニットの前記ポインタを分析するステップと、前記必要先行ユニットが受信されている場合には、前記ストリームユニットを処理するステップとを含む。
【００３９】
最後に、本発明は、特に、下記を含むグループに属するアプリケーションの１つに対する送信手順の使用法に関し、すなわち、ユーザが選択したプログラムにアクセスする前に、メッセージをシステマチックに同報通信することと、プログラムの特定の品質レベル及び／又は特定のオプションに条件付きアクセスをすることと、対話型のテレビとに関する。
【００４０】
本発明の別の特徴及び利点は、例証的な実施例及び添付した図面として与えられた以下の本発明の好ましい実施形態に関する説明を読めば一層明らかになるであろう。
【発明を実施するための最良の形態】
【００４１】
以下に説明する好ましい実施形態は、特にＭＰＥＧ−４型のシステムにおけるマルチメディアシステム内のストリームの送信に関する。
【００４２】
以前の技術
以前の技術では、マルチキャスト又は同報通信を行う場合に、マルチメディアのシーンを効率的に送信することを考慮していない（ビットレート及び機能性の点で）だけでなく、アクセス管理キー形の内容にリンクされた要素が相互依存するストリームの同期化を行うこともできない。
【００４３】
同報通信及びマルチキャストのシナリオにおけるマルチメディア表示
ある解決策が、「カルーセルＭＰＥＧ−４」の仕様書の中で提案されている。それにもかかわらず、機能の中には禁止されたり、高いビットレートを消費するものがある。考慮される２つの配信のシナリオでは、マルチメディア表示に対するいくつかの入力された要素をいかなる時点でも必要とされる。これは結果として、シーン、例えば、ＢＩＦＳのシーンやテクスチャーなどの記述に対してデータを繰り返すことになる。
【００４４】
マルチメディアのコンテンツが豊富になると、この単純な繰返しは許容できなくなり、ダウンロードの時間が過大になる結果につながる。さらに、この仕様は幾つかのマルチメディアの要素（短いオーディオ／ビデオのクリップ）を同報通信することはできない。
【００４５】
さらに、未公開の特許出願第ＥＰ−０１４６００４６２号では、データはある伝送レベルに応じて伝達される。対照的に、本発明によれば、全てのものが、伝送レベルとは独立した、いわゆる同期層レベルに置かれる。
【００４６】
これにより、様々な種類の伝送を取り除き、また時間及び論理的な同期化データ並びに１つの点におけるランダムアクセス用マーカを統一する利点が提供され、このため、独自の点でユニットを維持又は廃棄するための決定を計算することができる。このことは、さらにデータストリームに関するより多くの情報を知ることにつながり、これにより（ＢＩＦＳなどに対するビデオ／オーディオについての）データストリームの種類による決定を専門化できるようにされる。
【００４７】
マルチメディアの同期化
マルチメディアの同期化の点に関するこれまでの技術は、本質的に、ＲＴＰに基づいた伝送プロトコル及びＭＰＥＧ−４（「同期化層」）によって表示される。使用される同期化機構は、主にオーディオのストリーム及びビデオのストリームを、遅れなしに表現することができるように、時間同期するように設計されている。これらのデータは、タイムスタンプシステム（基準クロック、デコーディングスタンプ及びプレゼンテーションスタンプ）を用いて伝送されている。
【００４８】
様々な時間的及び空間的な充実化のレベルを使用して、表現可能なフレームを作る階層符号化が出現することにより、新しい同期化の必要性が生じている。実際に、データストリームは（それを表示する場合だけではなく）デコードする前に同期化することが必要である。正確なフレームを作るために、デコーディングを要求されたユニットを識別することが必要であるため、この制約は表示の同期化よりも一層複雑になる。１つの遅延が原因で、あるデータストリーム全体ひいては、そのデータストリームに基づくあらゆるデータストリームが使用できなくなる可能性がある。ここで見られるように、これはデコードされるユニット間の論理的な依存性の問題である。
【００４９】
時間間隔の減少は、既にビデオのＭＰＥＧ−４の中では考慮されているが、システム層(system layers)では実現できない。
【００５０】
データの保護
同期化の第３の事例、すなわち、マルチメディアのストリームにリンクされたデータ保護ストリームの同期化の事例は、以前の技術では考えられていない。
【００５１】
この場合は、どのマルチメディアのストリームユニットも、デコードする前に正しいキーを用いて確実に解読することが必要がある（そうでないと、破局的な結果が生じる可能性がある）。データストリームが同期していることが確実でないと、同期化ツールはこの必要性を保証できない。
【００５２】
このとき、デコーダの入力及びその出力は、同期化点(synchronisation points)である（その結果、デコードされたフレームを暗号化することができる）。
【００５３】
本発明の原理
本発明の目的は、とりわけ、マルチメディアのシーンのマルチキャスト(multicast)及び同報通信(broadcast)と、マルチメディアのデコーディングの論理的な同期化とを可能にすることである。
【００５４】
これは、これら２つの目的に到達できる下記の機構、すなわち、各回ストリームを構成するユニットが設定可能なやり方で識別されるように、ストリームを構成できる機構と、同報通信のシナリオ用のフロント連鎖機構（front chaining mechanism）とを用いて達成される。
【００５５】
このため、本発明の不可欠な技術要素は下記のようになる、すなわち、数個のデータストリームの要素間の又は同じストリーム内部の論理的な同期化要素（ビデオ、オーディオ、及びデータ保護システム）と、ストリームの各要素の種類に対して、それが依存する要素及びそれが依存する特定の要素を示すことができる解決手段とである。解決手段としてはいくつかの手段を用いることができる。
【００５６】
下記の手段、すなわち、従属記述子（dependency descriptor）と、従属マーカ（dependence marker）（オプション）と、従属ポインタ(Dependency Pointer)と、マーカ(Marker)（ストリームユニットを識別する）（オプション）とは、どのような種類の実施態様にも特に使用される。
【００５７】
少なくとも１つの実施形態のモードについての詳細な説明
ＭＰＥＧ−４の仕様
付属書１は、ＭＰＥＧ−４の仕様の形式で、ＭＰＥＧ形のデータに対して本発明を実施した場合の詳細な実例を示す。
【００５８】
レシーバの動作
端末は、自分のオブジェクト記述子（ObjectDescriptor）を用いて少なくとも１つのグラフィックシーンのオブジェクト（ＢＩＦＳストリーム：F#BIFS）を参照するＩＯＤ（InitialObjectDescriptor）を受信する。また、任意選択的に、ＩＯＤは少なくとも１つのグラフィックオブジェクトの記述オブジェクト（ＯＤストリーム：F#OD）を参照する。この端末は、以下に示す情報に基づいて、これらのストリームを開く。
【００５９】
これらのオブジェクト記述子のそれぞれは、それを構成する基本ストリーム記述子（ESDescriptor）を含む。各ESDescriptorは、dependsOnESIDフィールド及びＳＬ設定記述子（SLConfigDescriptor）を含む。
【００６０】
この従属ＥＳＩＤ(dependsOnESID)フィールドは、そのＥＳＩＤによって識別されたストリーム間に従属物のグラフを組み立てることができる。
【００６１】
ＳＬ設定記述子(SLConfigDescriptor)オブジェクトは、同期化ツール(synchronization tool)を形成できるようにする。
【００６２】
このＳＬ設定記述子（SLConfigDescriptor）オブジェクトの中には、下記の方法でレシーバが様々な従属物を検証するように、レシーバを形成する可能性が存在する。
【表１】
【００６３】
このように、あるストリームを別のストリームに従属していると宣言することができる（それ自体は通常の媒体又はＩＰＭＰ）。この場合、ストリームはそのＳＬ構成の中で、４つの別個のモードを用いて、どのようにこの依存性を示すかを記述する（従属記述子(Dependency descriptor）。
【００６４】
［ＤＴＳ及びＩＤバージョンのモード（モード０及び１）］
ストリームはこれらのアクセスユニット（ＡＵ）のそれぞれに対して、ストリーム自体の中のフロント依存性（front dependency）を示す。換言すると、このＡＵ（ｎ）は、どのアクセスユニットが次にデコードされるかを示す。このシグナリングは、モード０では次のアクセスユニット（固有の）のＤＴＳ又はモード１では次のアクセスユニットのＩＤのいずれかを記述する、各パケット内のマーカによって行われる。
【００６５】
この場合、再生される最初の要素の値が加えられる。
【００６６】
例えば、これは同報通信／マルチキャストモードにおけるＢＩＦＳストリームとすることができる。
【００６７】
［スケーラブルモード（モード２）］
ストリームはこれらのアクセスユニットのそれぞれに対して、従属するストリームに関する依存性を示す。このストリームは一意的であると想定される。
【００６８】
この原理は、図１に示されている。従属ストリーム１０のストリームユニット１１は、通常、ＳＬヘッダ（SLHeader）１１１及びデータフィールド（SL payload）１１２を含む。このヘッダ１１１は、特に、２つのポインタ、Ｄｅｐ１及びＤｅｐ２を含み、これらのポインタは、それぞれ基本ストリーム１４のストリームユニット１４１及び１４２を有する従属リンク１２及び１３を定義する。この基本ストリーム１４は、ストリームユニット１１を処理するために周知でなければならない。
【００６９】
［ＩＰＭＰモード（モード３）］
ストリームはこれらのアクセスユニットのそれぞれに対して、データ保護システムがユニットをデコードできるようにする識別子を示す。これが与えられると、このマーカはユニットを解読できるかどうかについて応答することができる。
【００７０】
ＳＬ設定記述子は、１つ又は数個の従属記述子（DependencyDescriptor）及び従属マーカ（DependencyMarker）を含むことができ、これにより、ストリーム内の種々の依存性の事例を調整することができる。（先験的には、１つの従属マーカで十分であるが、数個が存在することがある。）
【００７１】
このため、ＳＬ設定（SLConfig）が従属マーカを含む場合、それは自身のパケットのそれぞれに対してバージョンＩＤを示す（モード１及び３）。
【００７２】
アクセスユニット（AccessUnit）に対応するＳＬパケットのヘッダには、下記の事項、すなわち、ＳＬ設定記述子の各従属マーカに対する長さマーカ（markerLength）と、各従属記述子に対するdepLength長さの従属ポインタ（dependencyPointer）とが発見される。
【００７３】
これらの様々なマーキングが実行されると、システムは下記の事項、すなわち、ａ）モード０及び１により、「同報通信」モードで動作することと、ｂ）拡張性の依存性を管理することと、ｃ）ＩＰＭＰの依存性を管理することとを行うことができる。
【００７４】
ＩＰＭＰモードの動作説明
オブジェクトのオブジェクト記述子が受信されると、端末は関連した各ストリームのＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすること、特にマーカをデコードすることが可能になる。
【００７５】
ＩＰＭＰの場合は、図３に示すように、ＤＴＳ及び／又は従属ポインタが存在する。
【００７６】
各ストリームのＡＵについては、それがデコードされる前に、それが少なくともいずれかのストリーム識別子のデータ、すなわちＥＳＩＤ、ＤＴＳ、従属ポインタ（ＩＰＭ）３１を備えることによって、それはＩＰＭＰシステム３２により処理される。次に、ＩＰＭＰシステムは、デコーディングに関する情報３１１（Code Dec）を考慮することによってＡＵを処理（解読）できる場合は応答する（３３）。処理できなくて、ユニットのＤＴＳが終了する場合、ＡＵは破壊される（３４）。このため、矛盾したＡＵをデコードしようとする試みは行われない。
【００７７】
図４の実施例では、一方では図３の要素が存在するが、他方では、デコーディング（４１）の後に、画像の再生にリンクされた処理が存在する。実際に、フィールド３１２（CodeComp）を用いて、タトゥー（tattoo）すなわち画像上にメッセージを追加することなどの構成に関するデータは送信することができる。データ保護システム３２が、例えば、デコーダが必要なタトゥーを持っていないために、この構成を処理する方法を知らない場合は（それは画像を表示する方法を知らない）、画像は表示されない（４３）。
【００７８】
フレームは、例えばロゴでマークされることも予測できる。このロゴは、デコーダが正しいキーを持っていない場合は表示されない。
【００７９】
マルチキャスト／同報通信モードにおける動作の説明
この動作は図２の中で示されており、下記の事項、すなわち、送信されたストリーム２１と、第１のレシーバによって受信されたストリーム（セッション１）２２と、第１のレシーバによって受信されたストリーム（セッション２）２３と
を示す。
セッション１はパケット２１１で開始し、次にストリームユニット２１１が指すストリームユニット２１３を（２４）、次にリンク２５に基づいて、ストリームユニット２１５を取り入れる。
【００８０】
少し後で開かれたセッション２はストリームユニット２１２で開始する。ストリームユニット２１２はストリームユニット２１４を指し示す（２６）。
【００８１】
本発明によれば、２つ（又はそれ以上）のストリームユニットは、次の同じストリームユニットを指すことができる。それはマージ機構（merge mechanism）２７であり、ここでは、ストリームユニット２１３及び２１４の両方がストリームユニット２１５を指している。このため、それらは異なる時間に開始したが、２つのセッションは、「再生」段階の後、同じストリームユニット２１５を使用する。これにより、性能を明らかに向上させることができる。
【００８２】
この動作を具体的に説明する。
【００８３】
オブジェクト記述子を受信すると、端末はそれぞれの関連するストリームに対してＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすること、特に、マーカのデコーディングが可能になる。
【００８４】
このため、マルチキャスト／同報通信の場合は、モード０又は１では少なくとも１つの従属ポインタ、及びマーカ（「ＩＤによる」モード１）がＤＴＳに対して存在する。その結果、端末は各ストリームについて、どれが再生すべき最初のユニットかを知っている。このため、端末は各ストリームに対応する最初のユニットの再生を試みる。
【００８５】
端末が最初のユニットを受信すると、端末はその内容を表示し始めることができる。各ユニットは受信すべき次のユニットを従属ポインタの中に記述し、ＤＴＳ／マーカは独自の方法で各ユニットを識別する。
【００８６】
端末が最初のユニットを受信しない場合（端末はこのことをタイムアウトによって知ることができる）、又は所望のマーカに対応しないＲＡＰ＝１形をこのストリームユニットに関して受信する場合、端末は切断し（セッションを完全に閉じる）、また再接続しようとする。
【００８７】
この仕組みは、セッションのマネージャを考慮していることに注意されたい。
【００８８】
また、「ＩＤによる」モードは、次のユニットのＤＴＳが前もって知らされていない場合に必要とされることにも注意されたい。
【００８９】
この方式は、特に、ＢＩＦＳ、ＯＤ、テクスチャー、オーディオのクリップ、及びＭＰＥＧ−４におけるビデオのクリップに対して使用される。それはストリーム化されたオーディオ／ビデオに対しては、もはや使用されない。
【００９０】
拡張可能なモードにおける動作の説明
オブジェクト記述子が受信されると、端末は関連するストリームのそれぞれに対して、ＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすることが可能になる。拡張可能なビデオについては、１つのストリームをベースとして使用し、別の１つ又は数個のストリームはこのストリームに依存する。基本のストリームに依存する各ストリームは、従属記述子を宣言する。
【００９１】
改良ストリームの各ＡＵに関しては、端末はＡＵの従属ポインタを用いて、それが依存する基本ストリームのＤＴＳを参照する。
【００９２】
大抵の場合、基本ビデオの２つの基準ＡＵを指し示すために、改良ストリームの中に２つの従属ポインタが存在する。
【００９３】
同報通信＋ＩＰＭＰモードにおける動作の説明
この場合、例えばＢＩＦＳは、ＳＬ構成の中に２つの従属記述子を含む。１つは同報通信モードのために、他の１つはＩＰＭＰモード用に含む。同報通信モードがＩＤによる場合、それはマーカを含む。
【００９４】
アプリケーションの実施例
プログラム開始前の広告の同報通信
インターネット用ストリーミングの幾つかの場合では、コンテンツプロバイダは、内容自体を送る前に広告を意図的に送っている。インターネットのシナリオはユニキャスト（unicast）（クライアント−サーバ）であるため、これは段階的に行われる。広告のダウンロード及び広告の終了により、ビデオのストリーミングが開始される。
【００９５】
クライアント−サーバの動作に頼るものがないマルチキャスト又は同報通信のシナリオでは、要求の考えがない。このため、ユーザは通常現在の表示ステータスにアクセスするだけである。
【００９６】
フロント参照機構のおかげで、このシナリオはマルチキャスト又は同報通信では可能にされる。
【００９７】
実際に、広告は周期的な方法で送ることができ、また現在のプログラムを広告の後にマージすることができる。
【００９８】
このことは、例えば、全てのユーザが確実に始めに広告を見るようにすることができる（この間に、コンテンツは効率的でこま切れな(incremental)やり方でダウンロードすることができる）。
【００９９】
同じ種類のアプリケーションを、各同報通信する映画のための、映画のカテゴリーの通知とすることができる（親同伴が望ましい、年令が１６才未満、など）。
【０１００】
スケーラブルな条件付きアクセス
ここでのアイディアは、ユーザの正しい権利に基づいて別々に見ることができるビデオ及びオーディオのストリーム（固有の）を送ることである。保護キーに関したビデオフレームの依存性の信号により、ユーザがキーを有するストリームのみをデコードすることを可能にする。全てのキーを有する者は、全ての画像をデコードできるが、より少ない特権しか持たない者は、数個の画像しかデコードできない。これはよりスケーラブルなやり方（ここでは、時間的なスケーラビリティ）で、条件付きアクセスを実行できるようにする。
【０１０１】
最も複雑で有用なシナリオは、幾つかのストリームがあり、時間的なスケーラビリティ及び解像度を調整できるシナリオである。
【０１０２】
そのため、このフレーム依存のシステムでは、ほぼ連続的な方法で媒体に調整アクセスする（modulate access）ことが可能である。
【０１０３】
従って、あるユーザは５チャネルにわたって音声を受信できるキー（空間的な音声）を有し、別のユーザはステレオの音声のみを受信できるキーを有する。このことは、より詳細なインボイスを作ることも可能にする。
【０１０４】
ＭＰＥＧ−４の双方向テレビ
「セットトップボックス」のアプリケーションが静的であることを考えるのではなく、これらの種類のアプリケーションのいずれも、異なるチャネルを得ることができるＭＰＥＧ−４のアプリケーション（インライン式の機構）であると考えることができる。このＭＰＥＧ−４のアプリケーションは、アクティブ２４ｈｘ２４ｈであり、グラフィカルインターフェースなどを完全に再構成できる。
【０１０５】
シーンを同報通信する技術は、アプリケーションの部分（ＭＰＥＧ−Ｊ）だけでなくグラフィカルインターフェース（ＢＩＦＳ／テクスチャー／ＯＤ）をも効率的にダウンロードすることができる。
【０１０６】
このことは、より迅速な展開を可能にする。
【０１０７】
［付属書］
本発明によるＭＰＥＧ−４形の仕様の例
定義
ストリームユニット（ＡＵ：アクセスユニット）
基本ストリームの中で個別にアクセス可能なデータユニットである。ストリームユニット（又はアクセスユニット）は、時間のデータ要素に起因すると考えられる最小のエンティティーである。
【０１０８】
オーディオビジュアル・オブジェクト
オーディオ及び／又はビジュアルな方法で明示された自然の又は合成された（仮想の）オブジェクトの表現である。この表現は、ＢＩＦＳのシーケンス記述の中のノード又はノードのグループに該当する。各オーディオビジュアル・オブジェクトは、１つ又は数個のオブジェクト記述子を使用するゼロ、１つ、又は数個の基本ストリームに関連付けられる。
【０１０９】
オーディオビジュアル・シーケンス（ＡＶシーン）
シーンを記述し、自身の空間的又は時間的な属性を定義するデータ要素を有する、オブジェクト及びユーザの相互作用の結果として生ずる動作を含む、一連のオーディオビジュアル・オブジェクトである。
【０１１０】
シーン用のバイナリフォーマット（ＢＩＦＳ）
シーン記述のパラメトリック形式の符号化された表現である。
【０１１１】
端末
ＩＳＯ／ＩＥＣ１４４９６−１によって定義されたものと同様の、対話型のオーディオビジュアルのシーンの符号化された表現を送信又は受信及び表示するシステムである。それは、ＩＳＯ／ＥＩＣ１４４９６に準拠した独立したシステム又はアプリケーションシステムの一部とすることができる。
【０１１２】
略語及び記号
ＡＵ アクセスユニット又はスチームユニット
ＡＶ オーディオ−ビジュアル
ＢＩＦＳ シーン用のバイナリフォーマット
ＣＭ 構成メモリ
ＣＴＳ 構成タイムスタンプ
ＣＵ 構成ユニット
ＤＡＩ ＤＭＩＦアプリケーションインターフェース（ＩＳＯ／ＩＥＣ１４４９６−６を参照）
ＤＢ デコーディングバッファ
ＤＴＳ デコーディング用タイムスタンプ
ＥＳ 基本ストリーム
ＥＳＩ 基本ストリーム用インターフェース
ＥＳＩＤ 基本ストリーム用識別子
ＦＡＰ フェイシャルアニメーション（Facial Animation）用パラメータ
ＦＡＰＵ ＦＡＰユニット
ＮＣＴ ノード符号化テーブル
ＮＤＴ ノードデータ形
ＯＣＩ オブジェクト内容情報
ＯＣＲ オブジェクトクロック基準
ＯＤ オブジェクト記述子
ＯＤＩＤ オブジェクト記述子用識別子
ＯＴＢ オブジェクト時間ベース
ＰＬＬ 位相ロックループ
ＱｏＳ サービスの質
ＳＤＭ システムデコーダのモデル
ＳＬ 同期化層
ＳＬ−Ｐａｃｋｅｔ 同期化層のパケット
ＳＰＳ ＳＬパケット化ストリーム
ＳＴＢ システム時間ベース
ＴＴｓ テキスト−音声
ＵＲＬ ユーアールエル
ＶＯＰ ビデオオブジェクト面
ＶＲＭＬ 仮想現実モデリング言語
【０１１３】
ＳＬパケット用ヘッダの構成
シンタックス
【表２Ａ】
【表２Ｂ】
【０１１４】
セマンティクス
ＳＬパケット用ヘッダは、各個々の基本ストリームの必要性に基づいて構成することができる。選択できるパラメータは、クロック基準はもとより、タイムスタンプの存在、解像度、及び精度を含む。この柔軟性により、例えば、ＳＬパケット用ヘッダの内容を少し増加することができる。
【０１１５】
各基本ストリームに対して、この構成は、オブジェクト記述子に関連したES#Descriptorの一部であるＳＬ設定記述子の中で送信される。
【０１１６】
ＳＬパケット用ヘッダの中で構成できるパラメータは２つの種類、すなわち、各ＳＬパケットに適用されるもの（例えば、ＯＣＲ、sequenceNumber）及びアクセスユニットの中で単に表示されるもの（例えば、タイムスタンプ、アクセスユニット長（accessUnitLength）、瞬間ビットレート（instantBitrate）、劣化優先度（degradationPriority）など）に分割することができる。
【０１１７】
（あらかじめ定義された）列は、以下に詳しく記載したような、所定のパラメータの組のディフォルト値を固定することができる。この表は、将来のプロファイルに必要な設定などの所定の設定を含むように、ＩＳＯ／ＩＥＣ１４４９６の修正案によって更新することができる。
【０１１８】
【表３】
【０１１９】
表３は、ＳＬ設定記述子のあらかじめ定義された値の組を示している。
【０１２０】
【表４】
【０１２１】
表４は、ＳＬ設定記述子のあらかじめ定義された値の詳細を示している。
【０１２２】
useAccessUnitStartFlag−accessUnitStartFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useAccessUnitEndFlag−accessUnitEndFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useAccessUnitStartFlag及びuseAccessUnitEndFlagが使用可能でない場合、これは各ＳＬパケットが完全なアクセスユニットに対応することを意味する。
useRandomAccessPointFlag−RandomAccessPointFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
hasRandomAccessUnitsOnlyFlag−各ＳＬパケットがランダムアクセス点に対応することを示す。この場合、randomAccessPointFlagを使用する必要はない。
usePaddingFlag−paddingFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useTimeStampFlag−タイムスタンプがこの基本ストリームを同期させるために使用されることを意味する。それらはＳＬパケット用ヘッダの中に移送される。別の方法では、このＳＬパケット用ヘッダの中に移送されたaccessUnitRate、compositionUnitRate、startDecodingTimestamp、及びstartCompositionTimeStampのパラメータを同期化のために使用する必要がある。
【０１２３】
開始及び持続時間のタイムスタンプ（useTimeStampFlag=0）は、エラーがない環境を含む一定の条件の下でのみ使用することができる。ランダムアクセスは容易ではない。
useIdleFlag−この基本ストリームの中でidleFlagが使用されることを示す。
durationFlag−この基本ストリームに対するアクセスユニット及び構成ユニットの一定の持続時間が、続いて表示されることを示す。
timeStampResolution−第２のパルスによるオブジェクトの時間ベースの解像度である。
OCRResolution−第２の周期によるオブジェクトの時間ベースの解像度である。
timeStampLength−ＳＬパケット用ヘッダ内のタイムスタンプ・フィールドの長さである。timestampLengthはゼロから６４ビットの値を取らなければならない。
OCRlength−ＳＬパケット用ヘッダ内のobjectClockReferenceフィールドの長さである。数個のゼロは、この基本ストリームの中にはobjectClockReferenceが存在しないことを示す。OCRstreamFlagが配置される場合は、OCRLengthはゼロでなければならない。別の方法では、OCRlengthはゼロと６４ビットとの間の値を持つ。
AU#Length−この基本ストリームに対するＳＬパケット用ヘッダ内のaccessUnitLengthフィールドの長さである。AU#Lengthはゼロと３２ビットとの間の値を取る必要がある。
instantBitrateLength−この基本ストリームのＳＬパケット用ヘッダ内のinstantBitrateの長さである。
degradationPriorityLength−この基本ストリームのＳＬパケット用ヘッダ内にあるdegradationPriority用フィールドの長さである。
AU#SeqNumLength−この基本ストリームのＳＬパケット用ヘッダ内にあるAU#sequenceNumber用フィールドの長さである。
packetSeqNumLength−この基本ストリームのＳＬパケット用ヘッダ内にあるpacketSequenceNumber用フィールドの長さである。
timeScale−アクセスユニット及び構成ユニットの持続時間を表示するために使用される。第２のものは、またtimeScaleセクションに分割される。
accessUnitDuration−アクセスユニットの持続時間は、accessUnitDuration * 1/timeScale秒である。
compositionUnitDuration−構成ユニットの持続時間は、compositionUnitDuration * 1/timeScale秒である。
startDecodingTimeStamp−この基本ストリームの第１のアクセスユニットをデコードする必要がある時間を転送する。それはtimeStampResolutionによって規定された決定の中で転送される。
extension#field#control−このフィールドはＳＬの拡張を可能にする。値01b0は、記述子をSLConfigDescriptorの最後に配置する必要があることを示す。
markerDescriptors−この表は、ストリーム内の次のアクセスユニットを識別するマーカの記述子を示す。
dependencyDescriptors−この表は、前のアクセスユニット又は次のユニットをどのように参照しなければならないかを規定する従属記述子を示す。
【０１２４】
MarkerDescriptor
シンタックスは以下のようになる。
【表５】
【０１２５】
DependencyDescriptor
シンタックス
【表６】
【０１２６】
セマンティクス
モード
下記のように４つの定義されたモードがある。
モード０：ＤＴＳによるフロントの参照
モード１：マーカによるフロントの参照
モード２：バックスケーラビリティ（back scalability）の参照
モード３：ＩＰＭＰモード
【０１２７】
モード０及び１は、各アクセスユニットに次のアクセスユニットを参照させる。
【０１２８】
モード２は、各アクセスユニットにこのアクセスユニットをデコードするために必要な前のアクセスユニットを参照させる。（注意：場合によっては、３つ以上のdependencydescriptorsが２つ以上の必要なアクセスユニットを参照するために必要である。）
【０１２９】
モード３は、各アクセスユニットが不明瞭な識別子を含むことができるようにする。このアクセスユニットのデコーディング及び組立てが可能かどうかを決定するために、ＩＰＭＰシステムはこの不明瞭な識別子を使用できる。
【０１３０】
モード１及び３は、ストリームの中にMarkerDescriptorを必要とする。
【０１３１】
ＥＳＩＤ
このオプションのフィールドは、DependencyDescriptorが参照するストリームを識別する。
【０１３２】
SimpleDependencyDescriptorに関しては、ＥＳＩＤは下記の方法、すなわち、
モード０及び１：現在のストリームであることと、
モード２：dependsOnESIDに依存することと、
モード３：非適用であることと計算される。
dependencyLength−マーカ（存在する場合）又はdecodingTimeStampのいずれかの長さ。
value−第１のマーカ又はデコードする次のアクセスユニットの識別子の値。
【０１３３】
ＳＬパケット用ヘッダの仕様
シンタックス
【表７Ａ】
【表７Ｂ】
【０１３４】
セマンティクス
accessUnitStartFlag−これが１の場合、このＳＬパケットについてのロードの最初のバイトがアクセスユニットの開始点であることを示す。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されている場合、下記のルールに基づいて、そのディフォルト値を前のＳＬパケットから知ることができる。
【０１３５】
accessUnitStartFlag = (the SL packet before accessUnitEndFlag=1)?1:0
accessUnitEndFlag−これが１の場合、このＳＬパケットについてのロードの最後のバイトが現在のアクセスユニットの最後のバイトであることを示す。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されている場合、下記のルールに基づいて、そのディフォルト値はＳＬパケットを受信した後でのみ知ることができる。
【０１３６】
accessUnitEndFlag = (the SL packet after accessUnitStartFlag==1)?1:0
AccessUnitStartFlag及びAccessUnitEndFlagのいずれもがＳＬパケット用ヘッダの中で構成されていない場合、各ＳＬパケットは各accessUnitStartFlag = accessUnitEndFlag = 1である１つのアクセスユニットに対応することを意味する。
【０１３７】
ＳＬパケット用ヘッダがaccessUnitEndFlag及びaccessUnitLengthではなくaccessUnitStartFlagを使用するように構成される場合、端子は次のアクセスユニットが受信される前にアクセスユニットの端部を決定することができるという保証がないことに注意されたい。
【０１３８】
OCRflag−これが１の場合、objectClockReferenceが後に続くことを示す。OCRflagのディフォルト値はゼロである。
idleFlag−この基本ストリームが未確定の時間に対して不活性（すなわち、所望のデータがない）であることを示す。デコーダはこの符号を使用して、故意の欠如であるか又は次に続くＳＬパケット内のエラーによる欠如であるかを区別することができる。
paddingFlag−このＳＬパケットの中で使用されるデータ完了モードを示す。paddingFlagのディフォルト値はゼロである。
paddingBits−このＳＬパケットの中で使用されるデータ完了モードを示す。paddingBitsのディフォルト値はゼロである。
【０１３９】
paddingFlagが配置され、paddingBitsがゼロの場合、このＳＬパケットの後に続くロードが完了バイトのみから構成されることを示す。paddingFlagが配置され、paddingBitsがゼロの場合、accessUnitStartFlag、randomAccessPointFlag及びOCRflagを配置する必要がある。
【０１４０】
paddingFlagが配置され、paddingBitsがゼロよりも大きい場合、このＳＬパケットのロードの後に、ロードのバイトを整列させるためにゼロビットで形成されたpaddingBitsが続く。
【０１４１】
packetSequenceNumber−存在する場合、それはモジュールカウンタとして、各ＳＬパケットに対して連続的に増加させる必要がある。デコーダの中で不連続があると、１つ又は数個のＳＬパケットの欠落につながる。この場合、エラーを同期化層で表示する必要がある。このシンタックス要素をＳＬパケット用ヘッダの構成から割愛すると、同期化層によるストリームユニットの連続性の制御は、この基本ストリームに対しては行うことができない。
【０１４２】
ＳＬパケットの複製：ＳＬパケット用ヘッダの中にsequenceNumberフィールドを有する基本ストリームは、エラーを回復するためにＳＬパケットの複製を使用しなければならない。この複製されたＳＬパケットは、オリジナルの直ぐ後に続く必要がある。複製されたＳＬパケットのpacketSequenceNumberは、同じ値を有しなければならず、オリジナルのＳＬパケットの各バイトを、objectClockReferenceフィールド（存在する場合）を除いて複製する必要がある。このフィールドは、複製されたＳＬパケットに対する有効な値を符号化する必要がある。
【０１４３】
degPrioFlag−これが１の場合、degradationPriorityがこのパケットに存在することを示す。
degradationPriority−このＳＬパケットのロードの重要性を示す。streamPriorityは、ＥＳの基本的優先権を定義する。degradationPriorityは、基本的優先権に関してこのＳＬパケットに対する優先権の低下を定義する。このＳＬパケットに対する優先権は、下記の式によって与えられる。
SL#PacketPriority = streamPriority - degradationPriority
degradationPriorityは、この値を次に現れるまで維持する。特定の分配層(distribution layer)の例に対するアダプタだけでなく基本ストリーム用デコーダも、この表示を使用することができる。様々な基本ストリームのＳＬパケット間の劣化の割合は、the SL#PacketPriorityが低下するにつれて増加する。
objectClockReference−オブジェクト用のタイムスタンプを含む。ＯＴＲのｔの時間の値は、下記の式に基づいて、このＯＣＲのタイムスタンプから再構成される。
t = (objectClockReference/SL.OCRResolution) + K*(2SL OCRLength/SL.OCRResolution)
ここでｋは、objectClockReferenceのカウンタがカバーした時間である。
【０１４４】
objectClockReferenceは、OCRflagが配置されている場合のみ、ＳＬパケット用ヘッダの中に存在する。
１つのＯＣＲ値のみを、ＳＬパケットの内部にローディングすることなく移送できる。
２進のストリームの中でaccessUnitStartFlagが特に示したときに、アクセスユニットの最初にのみ存在するシンタックス要素のセマンティクスが、以下に記述されている。
【０１４５】
randomAccessPointFlag−これが１の場合、この基本ストリームの内容へのランダムアクセスが可能であることを示す。randomAccessPointsFlagは、accessUnitStartFlagが配置される場合のみ配置されなければならない。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されると、そのディフォルト値は、この基本ストリームに対してはSLConfigDescriptor.hasRandomAccessUnitOnlyFlagの値となる。
AU#sequenceNumber−存在する場合、それはモジュールカウンタとして各アクセスユニットに対して連続的に増加される必要がある。デコーダに不連続があると、ユニット全体にわたって１つ又は数個の欠落につながる。この場合、エラーを同期化層のユーザに表示する必要がある。このシンタックス要素をＳＬパケット用ヘッダの構成から割愛すると、同期化層によるストリームユニットの連続性の制御は、この基本ストリームに対しては実行することができない。
【０１４６】
アクセスユニットの複製：直前のＡＵではなく同じ数のシーケンスを用いて送られたアクセスユニットは、無視する必要がある。そのような複製のアクセスユニットは、そのオリジナルはＲＡＰを持っていないが複製のユニットはそれを有しており、送信されたストリームに対してランダムアクセス点を加えることができる。これにより、他のクライアントは既にストリームを受信している限りは、クライアントはその送信の間に規定された点でストリームに入ることができる。
【０１４７】
decodingTimeStampFlag−デコーディング用のタイムスタンプがこのパケットの中に存在することを示す。
compositionTimeStampFlag−タイムスタンプの構成がこのパケットの中に存在することを示す。
accessUnitLengthFlag−このアクセスユニットの長さがこのパケットの中に存在することを示す。
instantBitrateFlag−instantBitrateがこのパケットの中に存在することを示す。
decodingTimeStamp−関連したSLConfigDescriptorの中で構成されたデコーディング用タイムスタンプである。このアクセスユニットのデコーディング時間ｔｄは、下記の式に基づいて、このデコーディング用タイムスタンプから再構成される。
【０１４８】
td = (decodingTimeStamp / SL.timeStampResolution + K* 2SL.timStampLength / SL.timeStampResolution
ここで、ｋはdecodingTimeStampのカウンタがカバーした時間である。
decodingTimeStampは、デコーダの時間がこのアクセスユニットに対する時間構成から異なっている場合のみ存在しなければならない。
【０１４９】
compositionTimeStamp−関連したSLConfigDescriptorの中で構成されたタイムスタンプの構成である。第１の構成ユニットの時間構成ｔｃは、このアクセスユニットが下記の式に基づいたタイムスタンプの構成から再構成されるという事実から結果として生ずる。
【０１５０】
td = (compositionTimestamp / SL.timeStampResolution + k*2SL.timeStampLength / SL.timeStampResolution
ここで、ｋはcompositionTimeStampのカウンタがカバーした時間である。
【０１５１】
accessUnitLength−バイトで表したアクセスユニットの長さである。このシンタックス要素が存在しないか又は値がゼロの場合、アクセスユニットの長さは未知である。
instantBitrate−次のinstantBitrateのフィールドが見つかるまでの、この基本ストリームの１秒当たりのビット数の瞬間的なビットレートである。
markerValue−アクセスユニットを識別できるマーカの値である。このマーカは、markerDescriptorが存在する場合に定義される。
DependecyPointerValue−DependencyDescriptorによって定義されたＤＴＳ又はマーカ指数である。
MarkerDescriptorCount：マーカ用記述子の数である。
DependencyDescriptorCount：従属記述子の数である。
【０１５２】
デコーディング用セマンティクス
フロント参照機構（モデル０及び１）
ＥＳに関連したＳＬ設定記述子は、ストリームの中に入ることができる第１のアクセスユニットを示す。
【０１５３】
参照モードがＤＴＳの場合、ＳＬ設定記述子はdecodingTimeStampを含まなければならない。
【０１５４】
そうでない場合、マーカは各アクセスユニットをマークするために使用される。０及び−１は下記のように、特別な意味を有する、すなわち、／／０は、これ以上のアクセスユニットは後に続いて来ないことを意味し、／／−１は、どのアクセスユニットも使用できないことを意味する。
【０１５５】
各アクセスユニットは、マーカと、各アクセスユニットが次のアクセスユニットを示すことを可能にするdependencypointerとを含む必要がある。
【０１５６】
後方参照機構（モデル２）
ＳＬ設定記述子は、ＥＳＩＤが参照するＥＳ内のアクセスユニットを示すｎ個の従属記述子形の記述子を定義する。
【０１５７】
現在のストリームの各アクセスユニットは、識別子がES#baseと呼ばれるＥＳＩＤであるＥＳに対して、自身のＤＴＳを通して（ＥＳＩＤによって識別された）ES#baseのアクセスユニットを参照する従属ポインタを用いて、アクセスユニットを指し示す。
【０１５８】
ＩＰＭＰモード（モード３）
従属ポインタは、デコーディングの前にＩＰＭＰシステムに送信される。この不透明なポインタにより、ＩＰＭＰのリソースはアクセスユニットをデコードすることが可能か否かを決定できる。キーが受信されていない場合又はそれを行える権限がない場合は、それは否定の応答を行うことができる。この従属ポインタは、デコーディングの後で構成ユニットにリンクされる。
【０１５９】
それは構成する前にＩＰＭＰシステムに戻され、次にＩＰＭＰのリソースは、ユニットが存在できるか否かを決定する。
【０１６０】
クロック基準ストリーム
streamType = ClockReferenceStreamの基本ストリームは、オブジェクタ記述子（objector descriptor）を用いて宣言される必要がある。それは、オブジェクトのクロック基準用タイムスタンプを送信するために使用される。名前の組の中の複数の基本ストリームは、クロック基準情報を繰り返し送信することを避けるために、ＳＬ設定記述子内のOCR#ES#IDのシンタックス要素を用いて、そのようなClockReferenceStreamを参照できる。それにもかかわらず、OCR#ES#IDを用いる基本ストリーム間を循環して参照することは許可されていないことに注意されたい。
【０１６１】
自動化層上では、ＳＬレベルでパッケージ化されたストリームに対してＳＬパケット用ヘッダのシンタックスを構成することによって、ClockReferenceStreamを実行して、OCRResolution及びOCRLengthの必要なＯＣＲ値のみがＳＬパケット用ヘッダの中に存在するようにする。
【０１６２】
ＳＬパケットのチャージは、streamType = ClockReferenceStreamのパッケージ化されたＳＬストリームの中に存在しない。
【０１６３】
クロック基準ストリームに関するDecoderConfigDescriptorの中で、ObjectTypeIndicationを「0xFF」、１の間のhasRandomAccessUnitsOnlyFlag、及び「０」の間のbufferSizeDBの上に配置する必要がある。
【０１６４】
クロック基準ストリームのＳＬ設定記述子に対する推奨値を以下に示す。
【０１６５】
表８は、ClockReferenceStreamのＳＬ設定記述子のパラメータのＳＬ設定記述子の値を示している。
【０１６６】
【表８】
【０１６７】
同じ時間ベースのオブジェクトを共有する基本ストリームに関する制約
時間ベースのオブジェクトをOCR#ES#IDにより幾つかの基本ストリームの間で共有できる場合、下記のように、これらの基本ストリームへのアクセス及びそれらの処理に関する多数の制約が存在する。
【０１６８】
幾つかの基本ストリームが単純な時間ベースのオブジェクトを共有する場合、端末は集積されたクロック基準情報のない基本ストリームを、例えアクセス可能であっても、オブジェクトのクロック基準情報を伝送する基本ストリームがアクセス可能になるまで使用してはならない。
【０１６９】
集積されたクロック基準情報のない基本ストリームを、オブジェクトのクロック基準情報を伝送する基本ストリームの後で端子が利用可能になる場合、それを他のストリームと同期して配信する必要がある。このことは、時間ベースのオブジェクトの現在の値に依存するそのようなストリームを最初から配信してはならないことを意味することに注意されたい。
【０１７０】
オブジェクトのクロック基準情報を伝送する基本ストリームが利用できなくなる場合、又は他の場所で（例えば、待機モードで）使用される場合、同じ時間ベースのオブジェクトを使用する他の全ての基本ストリームはこの方式に従う必要がある、すなわち、それらは使用不可能になるか又は同じ方向で処理される必要がある。
【０１７１】
集積されたオブジェクトのクロック基準情報がない基本ストリームが利用不可能になっても、これは時間ベースのオブジェクトを共有する他の基本ストリームには影響を与えない。
【０１７２】
クロック基準及びタイムスタンプの値に対する構成オプションの使用
時間ベースのオブジェクトの再生における曖昧性の解決
objectClockReferenceの値の長さが限定されているために、これらのタイムスタンプは曖昧なことがある。ＯＴＢの時間の値は、下記の式に基づいて、objectClockRferenceがＳＬパケット用ヘッダに送信されるたびに再構成することができる。
tOTB#reconstructed = (objectClockReference / SL.OCRResolution) + k*(2SL.OCRLength / SL.OCRResolution)
ここで、ｋはループの数を示す整数の値である。結果として生じた時間ベースのtOTB#reconstructedは、秒で測定される。
【０１７３】
基本ストリームに対する最初のobjectClockReferenceが承認されると、ｋの値を１に設定する必要がある。後に続くobjectClockReferenceが現れるたびに、ｋの値は下記のように推定される。
【０１７４】
端末は、各瞬間に時間ベースのオブジェクトの値を推定するために、リソースを理解しなければならない。
【０１７５】
objectClockReferenceが受信されるたびに、ＯＴＢのtOTB#estimatedの現在の推定値をサンプリングする必要がある。これにより、tOTB#res(K)はｋの様々な値に対して評価される。持続時間│tOTB#estimated- tOTB#rec(k)│を最小にするｋの値は、tOTB#reconstructedに対する正しい値と考える必要がある。この値は、時間ベースのオブジェクトの予測機構に対する新しく貢献するものとして使用する必要がある。
【０１７６】
アプリケーションは、objectClockReferenceの要素に対して適当な長さ及び解像度を選択すること、並びに基本ストリームの中のobjectClockReferenceの挿入値に対して十分に高い周波数を選択することによって、この方式がｋに対して曖昧でない値を確実に発生するようにしなければならない。この値に対する選択は、ＳＬパケットに関する配信ジッタ（delivery jitter）及び端末とレシーバのクロック間の最大予想遅れに依存する。
【０１７７】
タイムスタンプの再生における曖昧性の解決
decodingTimeStamp及びcompositionTimeStampの値の長さが制限されていることにより、これらのタイムスタンプは、下記の式で示すように、曖昧になることがある。
Tts(m)=(TimeStamp/SL.timeStampResolution)+ m * (2SL.timeStampLength/SL.timeStampResolution)
ここで、TimeStampはdecodingTimeStamp又はcompositionTimestampのいずれかであり、ｍはループの数を示す全体の値である。
【０１７８】
タイムスタンプの正しいttimestampの値は、以下のように推定することができる。
TimeStampが受信されるたびに、ＯＴＢのtOTB#estimatedの現在の推定値をサンプリングする必要がある。tts(m)は、ｍの様々な値に対して評価される。期間│ tOTB#estimated- tts(m)│を最小にするｍの値は、ttimestampに対する正しい値と考えられる。
【０１７９】
アプリケーションは、時間事象の曖昧でない位置決めに関する要求事項に適合するために、各個別の基本ストリームに対して、タイムスタンプの長さ及び解像度を独立に選択することができる。この選択は、TimeStampが示した時点の後で、TimeStampが付いたＳＬパケットを送ることができる最大の時間及び時間の位置決めに関する要求された精度に依存する。
【０１８０】
オブジェクトのクロック基準及びタイムスタンプの使用に関する注釈
オブジェクトベースの時間の時系列により、/SL.OCRResolutionよりも大きい２つの別個の瞬間を区別することができる。アプリケーションが基本ストリームの組を同期化するために必要な精度を得ることができるように、十分に大きな寸法でOCRResolutionを選択する必要がある。
【０１８１】
タイムスタンプ及び構成スタンプ（composition stamp）により、/SL.timeStampResolutionよりも大きく分離した２つの個別の瞬間を区別することができる。アプリケーションが所定の基本ストリームに対するアクセスユニットを得るという点で必要とする精度を得ることができるように、十分に大きな寸法を用いてtimeStampResolutionを選択する必要がある。
【０１８２】
OCRResolutionよりも大きいTimeStampResolutionでは、事象間の最良の区別を得ることはできない。TimeStampResolutionがOCRResolutionよりも小さい場合、この特定のストリームについての事象は、この与えられたOCRResolutionでは可能な最大の精度を得ることはできない。
【０１８３】
OCRLengthのパラメータは、ＳＬヘッダの構成の中で示される。2SL.OCRLength/SL.OCRResolutionは、ループする前にobjectClockReferenceのカウンタによってカバーされた時間間隔である。全ての基本ストリームに対して時間事象の曖昧でない位置決めを行うというアプリケーションの要求に適合するために、十分大きなOCRLengthを選択しなければならない。
【０１８４】
アプリケーションが上記のように定義されたｋ値を知る場合、ＯＴＢの時系列は各時間の値に対して明らかになっている。アプリケーションがｋの要素を再構成できない場合、例えば、追加の情報なしでランダムアクセスを可能にするアプリケーションの場合は、ＯＴＢの時系列はモード2SL.OCRLength/SL.OCRResolutionに対して曖昧にされる。このため、このＯＴＢを参照する各タイムスタンプは曖昧である。それにもかかわらず、予想された最大ジッタ及びアクセスユニットをデコードする前に送ることができる持続時間に関する制約は、その知識を用いるようなアプリケーションの環境の中では、明瞭であると考えることができる。
【０１８５】
2SL.OCRLength / SL.OCRResolutionよりも大きい時間間隔2SL.timeStampLength/ SL.timeStampResolutionを選択する基本ストリームは、曖昧でない方法で、２つの時間間隔の最小の時間事象だけを得ることができることに注意されたい。
【０１８６】
場合によっては、ｋ及びｍを正しく推定できない場合、バッファモデルを超える可能性がある。このことは、デコーダにより予期しない動作及び結果を招くことになる。
【０１８７】
例えば、１ｍｓの精度で基本ストリームを同期化したいと望むアプリケーションを考える場合、OCRResolutionを１０００以上に選択する必要がある（これにより、２つの連続したＯＣＴパルス間の時間は１ｍｓとなる）。OCRResolution=2000と仮定できる。
【０１８８】
アプリケーションは、ＳＴＢとＯＴＢとの間のジッタを０．１％（すなわち、秒当たり１ｍｓ）と仮定する。このため、クロックを少なくとも秒ごとに調整する必要がある（すなわち、最悪のシナリオでは、クロックは精度の制約により１ｍｓ外れる）。objectclockReferenceは１秒ごとに送られると仮定できる。
【０１８９】
アプリケーションが、要素ｋを再構成する必要なしに２４ｈの明瞭なＯＴＢの時系列を持ちたいと思うことがある。このため、OCRLengthは、結果として、2SL.OCRLength/SL.OCRResolution＝２４ｈのように選択される。
【０１９０】
ここで、アプリケーションが、基本ストリーム内の事象を１０ｍｓの精度以外に同期化することを望むと仮定する。TimeStampResolutionを１００以上に選択する必要がある（これにより、TimeStampの２つの連続したパルス間の時間は１０ｍｓに等しい）。TimeStampResolution＝２００であると仮定する。
【０１９１】
アプリケーションは、デコーダ又は構成時間の前に最大１分でアクセスユニットを送りたいと希望する。このため、timeStampLengthは、2SL timeStampLength/SL.timeStampResolution=2 minutesのように選択される。
【図面の簡単な説明】
【０１９２】
【図１】本発明に基づいた、データストリームの別のデータストリームに関する従属処理の原理を示す図である。
【図２】時間がずれたセッションの形式で、ストリームを同報通信する場合及び２つの端末が受信する場合に、本発明の実現を示す図である。
【図３】ストリームユニットのデコーディング又は解読にリンクされた同期の実例を示す図である（ＩＰＭＰ）。
【図４】２つの保護点（デコーディング及び廃棄）を有する、図３の別の実例を示す図である。
【技術分野】
【０００１】
本発明の技術分野は、それぞれが基本ストリームユニット（elementary stream unit）によって構成された１つ又は数個のデータストリームの形式で、データを送信する分野である。より詳細には、本発明は、基本ストリームユニットが１つ又は数個の別のストリームユニットに従属している又はそれらに関連している場合、これらの基本ストリームユニットの処理を最適化することに関する。
【背景技術】
【０００２】
ある信号、例えば、マルチメディア形の信号が同期して１つのチャネルを介して送信される場合、ストリームユニットの処理にはほとんどあるいは全く問題が発生しない。必要なデータは前もって受信される。
【０００３】
他方、数個の送信チャネル及び／又は数個のサーバにより実現され、それらが所望の信号の一部をそれぞれ送信する非同期のシステムでは、これは当てはまらない。例えば、ＩＰ形のネットワークを介して送信又は一斉送信する場合である。
【０００４】
この場合、まだ受信していない他のストリームユニットを完結させることになっているストリームユニットを先に受信することがある。例えば、これはあるより高い階層レベルのデータ圧縮情報の可能性があり、データは階層符号化法を用いて符号化できる（これにより、ストリームは所定の階層レベルに対応させることができる）。このため、圧縮データの処理はランダムな結果を招き、一般に再生された信号に著しい劣化をもたらしたり、デコーダを完全にブロッキングすることさえある。
【０００５】
マルチメディアの同期化に関する従来の技術は、本来、ＲＴＰベースの伝送プロトコルとＭＰＥＧ−４「同期層(synchronisation)」とによって表される。これまでの取り組みでは、同期機構は、オーディオとビデオのストリームとを、遅延なしに表現できるように、時間的に同期させるように主に設計されてきた。このデータは、タイムスタンピングシステム（time stamping system）（基準クロック、デコーディングスタンプ及びプレゼンテーションスタンプ）を用いて伝達される。
【０００６】
種々の時間的及び空間的な充実化(enrichment)レベルを使用して表現可能なフレームを作成する階層符号化法の出現により、発明者は同期化に対する新しい要求が持ち上がっていることに注目した。
【０００７】
実際に、ストリームを（表示する間だけではなく）デコードする前に、同期化する必要がある。正しいフレームを作成するためには、ユニットをデコードするために必要なユニットを識別しなければならないため、この制約はプレゼンテーションの同期化よりも一層複雑である。たった１つの遅延のために、あるストリームが全体として使用できなくなり、さらにそれに基づいた全てのストリームが使用できないものになる可能性がある。このことは、発明者が確認した新規で明白でない問題である。
【０００８】
端末が、受信していなければならないが、まだ受信していないデータ（例えば、デコーディングキー）を用いて、受信したストリームユニットをデコード又は解読するする必要がある場合、同様の問題が発生する。この場合も、このデコーディング処置の結果は、少なくとも非効率であり、一般的に（再生された信号の点で）有害であり、この端末にブロッキングをもたらす可能性がある。これらの２つの場合では、望まれていない厄介な処理が行われることになる。
【０００９】
同報通信（マルチキャスト又は同報通信）システムの中で発見された別の重大な問題は、ユーザがどのような場合でも自分達が選択した全てのストリームを受信するために接続できるように、同じデータをマルチ同報通信（multibroadcast）する必要があることである。この特定の見解は、本願の出願人による未公開の欧州特許出願第ＥＰ−０１４６００４６２号の中ですでに説明されている。この技術によれば、各種の伝送の種類の特異性を考慮に入れて各ストリームユニットの処理を進める伝送レベルで処理が行われる。
【００１０】
同報通信及びマルチキャストのシナリオにおけるマルチメディア表示に関する従来の技術は、「カルーセルＭＰＥＧ−４（carousel MPEG-4）」の仕様書の中で説明されている。それにもかかわらず、その結果、いくつかの機能を用いることができず、またいくつかの機能はデータ速度の多くを消費することになる。２つの考えられる配信シナリオでは、マルチメディア表示に対するいくらかの入力された要素はいかなる時点でも必ず必要とされる(indicate)ことである。このことは、シーン例えばＢＩＦＳのシーンやテクスチャーの記述に関してデータを繰り返し使用することにつながる。
【００１１】
マルチメディアのコンテンツが豊富になると、この単純な繰返しは許容できないものではなくなり、ダウンロード時間が過大になる。さらに、この仕様では、幾つかのマルチメディア要素（短いオーディオ／ビデオのクリップ）を同報通信できない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
特に、本発明の目的は、上記技術の様々な不都合を克服することである。
【００１３】
より具体的に言うと、本発明の目的は、ストリームユニットが１つ又は数個の別のストリームユニットに依存する又は関連する場合、ストリームユニットを効率的に処理できる技術を提供することである。
【００１４】
さらに、本発明の目的は、特に、階層符号化又は基本データと充実化又は富化(enrichment)データとを結び付ける符号化方法によって符号化されたデータの場合、リンクされたストリームの処理を可能にするような技術を提供することである。
【００１５】
本発明の別の目的は、マルチ同報通信のシナリオの送信を最適化できる、また特に、受信時の品質を低下させずに使用するリソースの量を減らすことができる技術を提供することである。
【００１６】
換言すると、本発明の目的は、端末で実行される処理を、数量と品質との両方の観点において最適化することである。
【課題を解決するための手段】
【００１７】
これらの目的と後述する他の目的とは、本発明に基づいて、少なくとも１つの端末に少なくとも１つのデータストリームを送信する手順を用いて達成される。この手順では、データストリームはストリームユニットに編成される。本発明によれば、これらのストリームユニットの少なくとも幾つかは、前記データストリーム又は端末により先に受信されている別のデータストリーム中の、必要先行ユニットと呼ばれる少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含む。これは、必要先行ユニットが受信されていない場合、前記端末の中でこのストリームユニットの処理を行わないようにするためである。
【００１８】
このように、解像度の品質などを向上するために、端末における処理を制限し、ストリームユニットの処理をより容易にできる論理的な同期システムを利用できる。
本発明に基づいてこのように定義されたデータの形式は、ストリームの送信及び受信に対してだけでなく、それらの同報通信（ブロードキャスティング）、記録及び保管に関しても実行することができる。
【００１９】
本発明はこのように、特に、ストリーム又はストリームユニットの「バック」同期（"back" synchronization）という新しい問題を確認することと、処理するために全ての要素を利用できない場合、最も効率的な解決策はストリームユニットを処理することではないことと言う明白でない所見に基づいている。実際に、信号再生の点に関しては、ストリームユニットをデコードすることではなく、それを無視することが好ましいと思われる。このことは、再生された信号の劣化又は端末のブロッキングさえも引き起こす可能性がある。
【００２０】
好適には、本発明の方法は、別個に送信される少なくとも２つのデータストリームを送信することを含む。第１のデータストリームの１つのストリームユニットは、少なくとも１つの第２のデータストリーム中の少なくとも１つの必要先行ユニット(required previous unit)を指し示す。ここで、第１のデータストリームの前記ストリームユニットは、前記第２のストリーム内に含まれた充実化データを含む。
【００２１】
この場合、これらのデータストリームは、好適には、階層符号化の種々の階層レベルに対応させることができる。ここで、所与の階層レベルのストリームユニットの処理は、対応する下位の階層レベルのストリームユニットが受信された場合にのみ行われる。
【００２２】
このストリームユニットは、少なくとも１つの先行するユニットを指し示すことができる。これは、必要先行ユニットのシーケンスを定義する。
【００２３】
本発明の好ましい特性によれば、これらのポインタの少なくとも１つにより、考慮されているストリームユニットのデコーディング及び／又は解読を可能にするデータを含む少なくとも１つの必要先行ユニットを見つけ出すことができる。
【００２４】
前記必要先行ユニットは、端末が考えられたストリームユニットのデータをデコード及び／又は解読し、次にデコード後に表示する必要があるかどうかを決定することができるデータを含むことが好ましい。
【００２５】
別の好ましい方法によれば、これらのポインタの少なくとも１つは前記端末から知ることができるデータを指し示すため、端末は対応するストリームユニットを処理することができるかどうかを決定することができる。
【００２６】
好ましくは、本発明の別の態様によれば、これらのストリームユニットの少なくとも１つは、前記データストリーム中の又は近い将来に受信することができる別のデータストリーム中の少なくとも１つのストリームユニットを指す少なくとも１つのポインタを含む。
【００２７】
近い将来に受信することができるこの又はこれらのストリームユニットは、前記ポインタとのリンクを作ることができるマーカを有することが好ましい。
【００２８】
このため、別個の時間に送信された少なくとも２つの同様のストリームユニットのポインタは、近い将来に受信される同じストリームユニットを指し示すことができることが好ましい。
【００２９】
好ましくは、本発明の方法は、下記を含むグループに属する少なくとも２つの役割の中からのポインタの役割を示すインディケータ (indicator）を実現する。すなわち、検討されるストリームユニットを考慮できるようにするために、デコードする必要がある少なくとも１つの先行するストリームユニットを指し示すことと、
検討されるストリームユニットをデコード及び／又は解読するために必要なデータを含む少なくとも１つの先行するストリームユニットを指し示し、及び／又は保護システムのステータスへの参照を指し示すことと、少なくとも１つの後続するストリームユニットを指し示すこととである。
【００３０】
これらのデータストリームの少なくとも幾つかが、この役割を定義する従属記述子（dependency descriptor）を含むことが好ましい。
【００３１】
これらのデータストリームの少なくとも幾つかが、それ自体を必要先行ユニットとして識別できる従属マーカ（dependence marker）及び／又は前記ストリームの中の前記ストリームユニットの識別マーカ(identification marker)を含むことが好ましい。
【００３２】
本発明の方法が、受信されたストリームユニットの予備的な処理を必要としないような同期レベルで実行されることが好ましい。
【００３３】
本発明は、前述した送信手順に基づいて送信された１つ又は数個のデータストリームにも関連する。前述したように、そのようなデータ形式は、送信、同報通信、受信、及び記録（例えば、ビデオレコーダ又は光ディスクレコーダを用いる場合）並びにデータの保管（例えば、ＣＤ−ＲＯＭ、テープ、遠隔のサーバなど）のために使用できる。
【００３４】
また、本発明はこれらの動作の幾つかを容易に結合することができることに注意されたい。例えば、幾つかのデータストリームは同報通信とすることができ、別のデータストリームはＣＤ−ＲＯＭ又はサーバに送ることができる。ここで、第２のデータストリームは、第１のデータストリームをデコード（又は最適化）するために知られている必要がある。
【００３５】
そのようなデータストリームは、互いに独立して送信されるストリームユニットに編成される。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末で先に受信されている別のストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指し示し、前記ストリームユニットの処理は、必要先行ユニットが受信されていない場合は、前記端末では実行されないようにされる。
【００３６】
本発明は、互いに独立して送信されるストリームユニットに編成された少なくとも１つのデータストリームの形式で、少なくとも１つの端末に送信されるようにデータを作成したサーバにも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末で先に受信されている別のストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指す。
【００３７】
本発明は、互いに独立して送信されるストリームユニットに編成された少なくとも１つのデータストリームを受信することができる端末にも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末により既に受信されている別のストリーム中にある、必要先行ユニットと呼ばれる少なくとも１つのストリームユニットを指す。
【００３８】
本発明は、互いに独立して送信されるストリームユニットの中に編成された少なくとも１つのデータストリームを受信する手順にも関する。ここで、これらのストリームユニットの少なくとも幾つかは、少なくとも１つのポインタを含む。このポインタは、前記データストリーム中又は端末により既に受信されている別のストリーム中にある、少なくとも１つのストリームユニット（必要先行ユニットと呼ばれる）を指し示す。また、この受信手順は下記のステップ、すなわち、あるストリームユニットの前記ポインタを分析するステップと、前記必要先行ユニットが受信されている場合には、前記ストリームユニットを処理するステップとを含む。
【００３９】
最後に、本発明は、特に、下記を含むグループに属するアプリケーションの１つに対する送信手順の使用法に関し、すなわち、ユーザが選択したプログラムにアクセスする前に、メッセージをシステマチックに同報通信することと、プログラムの特定の品質レベル及び／又は特定のオプションに条件付きアクセスをすることと、対話型のテレビとに関する。
【００４０】
本発明の別の特徴及び利点は、例証的な実施例及び添付した図面として与えられた以下の本発明の好ましい実施形態に関する説明を読めば一層明らかになるであろう。
【発明を実施するための最良の形態】
【００４１】
以下に説明する好ましい実施形態は、特にＭＰＥＧ−４型のシステムにおけるマルチメディアシステム内のストリームの送信に関する。
【００４２】
以前の技術
以前の技術では、マルチキャスト又は同報通信を行う場合に、マルチメディアのシーンを効率的に送信することを考慮していない（ビットレート及び機能性の点で）だけでなく、アクセス管理キー形の内容にリンクされた要素が相互依存するストリームの同期化を行うこともできない。
【００４３】
同報通信及びマルチキャストのシナリオにおけるマルチメディア表示
ある解決策が、「カルーセルＭＰＥＧ−４」の仕様書の中で提案されている。それにもかかわらず、機能の中には禁止されたり、高いビットレートを消費するものがある。考慮される２つの配信のシナリオでは、マルチメディア表示に対するいくつかの入力された要素をいかなる時点でも必要とされる。これは結果として、シーン、例えば、ＢＩＦＳのシーンやテクスチャーなどの記述に対してデータを繰り返すことになる。
【００４４】
マルチメディアのコンテンツが豊富になると、この単純な繰返しは許容できなくなり、ダウンロードの時間が過大になる結果につながる。さらに、この仕様は幾つかのマルチメディアの要素（短いオーディオ／ビデオのクリップ）を同報通信することはできない。
【００４５】
さらに、未公開の特許出願第ＥＰ−０１４６００４６２号では、データはある伝送レベルに応じて伝達される。対照的に、本発明によれば、全てのものが、伝送レベルとは独立した、いわゆる同期層レベルに置かれる。
【００４６】
これにより、様々な種類の伝送を取り除き、また時間及び論理的な同期化データ並びに１つの点におけるランダムアクセス用マーカを統一する利点が提供され、このため、独自の点でユニットを維持又は廃棄するための決定を計算することができる。このことは、さらにデータストリームに関するより多くの情報を知ることにつながり、これにより（ＢＩＦＳなどに対するビデオ／オーディオについての）データストリームの種類による決定を専門化できるようにされる。
【００４７】
マルチメディアの同期化
マルチメディアの同期化の点に関するこれまでの技術は、本質的に、ＲＴＰに基づいた伝送プロトコル及びＭＰＥＧ−４（「同期化層」）によって表示される。使用される同期化機構は、主にオーディオのストリーム及びビデオのストリームを、遅れなしに表現することができるように、時間同期するように設計されている。これらのデータは、タイムスタンプシステム（基準クロック、デコーディングスタンプ及びプレゼンテーションスタンプ）を用いて伝送されている。
【００４８】
様々な時間的及び空間的な充実化のレベルを使用して、表現可能なフレームを作る階層符号化が出現することにより、新しい同期化の必要性が生じている。実際に、データストリームは（それを表示する場合だけではなく）デコードする前に同期化することが必要である。正確なフレームを作るために、デコーディングを要求されたユニットを識別することが必要であるため、この制約は表示の同期化よりも一層複雑になる。１つの遅延が原因で、あるデータストリーム全体ひいては、そのデータストリームに基づくあらゆるデータストリームが使用できなくなる可能性がある。ここで見られるように、これはデコードされるユニット間の論理的な依存性の問題である。
【００４９】
時間間隔の減少は、既にビデオのＭＰＥＧ−４の中では考慮されているが、システム層(system layers)では実現できない。
【００５０】
データの保護
同期化の第３の事例、すなわち、マルチメディアのストリームにリンクされたデータ保護ストリームの同期化の事例は、以前の技術では考えられていない。
【００５１】
この場合は、どのマルチメディアのストリームユニットも、デコードする前に正しいキーを用いて確実に解読することが必要がある（そうでないと、破局的な結果が生じる可能性がある）。データストリームが同期していることが確実でないと、同期化ツールはこの必要性を保証できない。
【００５２】
このとき、デコーダの入力及びその出力は、同期化点(synchronisation points)である（その結果、デコードされたフレームを暗号化することができる）。
【００５３】
本発明の原理
本発明の目的は、とりわけ、マルチメディアのシーンのマルチキャスト(multicast)及び同報通信(broadcast)と、マルチメディアのデコーディングの論理的な同期化とを可能にすることである。
【００５４】
これは、これら２つの目的に到達できる下記の機構、すなわち、各回ストリームを構成するユニットが設定可能なやり方で識別されるように、ストリームを構成できる機構と、同報通信のシナリオ用のフロント連鎖機構（front chaining mechanism）とを用いて達成される。
【００５５】
このため、本発明の不可欠な技術要素は下記のようになる、すなわち、数個のデータストリームの要素間の又は同じストリーム内部の論理的な同期化要素（ビデオ、オーディオ、及びデータ保護システム）と、ストリームの各要素の種類に対して、それが依存する要素及びそれが依存する特定の要素を示すことができる解決手段とである。解決手段としてはいくつかの手段を用いることができる。
【００５６】
下記の手段、すなわち、従属記述子（dependency descriptor）と、従属マーカ（dependence marker）（オプション）と、従属ポインタ(Dependency Pointer)と、マーカ(Marker)（ストリームユニットを識別する）（オプション）とは、どのような種類の実施態様にも特に使用される。
【００５７】
少なくとも１つの実施形態のモードについての詳細な説明
ＭＰＥＧ−４の仕様
付属書１は、ＭＰＥＧ−４の仕様の形式で、ＭＰＥＧ形のデータに対して本発明を実施した場合の詳細な実例を示す。
【００５８】
レシーバの動作
端末は、自分のオブジェクト記述子（ObjectDescriptor）を用いて少なくとも１つのグラフィックシーンのオブジェクト（ＢＩＦＳストリーム：F#BIFS）を参照するＩＯＤ（InitialObjectDescriptor）を受信する。また、任意選択的に、ＩＯＤは少なくとも１つのグラフィックオブジェクトの記述オブジェクト（ＯＤストリーム：F#OD）を参照する。この端末は、以下に示す情報に基づいて、これらのストリームを開く。
【００５９】
これらのオブジェクト記述子のそれぞれは、それを構成する基本ストリーム記述子（ESDescriptor）を含む。各ESDescriptorは、dependsOnESIDフィールド及びＳＬ設定記述子（SLConfigDescriptor）を含む。
【００６０】
この従属ＥＳＩＤ(dependsOnESID)フィールドは、そのＥＳＩＤによって識別されたストリーム間に従属物のグラフを組み立てることができる。
【００６１】
ＳＬ設定記述子(SLConfigDescriptor)オブジェクトは、同期化ツール(synchronization tool)を形成できるようにする。
【００６２】
このＳＬ設定記述子（SLConfigDescriptor）オブジェクトの中には、下記の方法でレシーバが様々な従属物を検証するように、レシーバを形成する可能性が存在する。
【表１】
【００６３】
このように、あるストリームを別のストリームに従属していると宣言することができる（それ自体は通常の媒体又はＩＰＭＰ）。この場合、ストリームはそのＳＬ構成の中で、４つの別個のモードを用いて、どのようにこの依存性を示すかを記述する（従属記述子(Dependency descriptor）。
【００６４】
［ＤＴＳ及びＩＤバージョンのモード（モード０及び１）］
ストリームはこれらのアクセスユニット（ＡＵ）のそれぞれに対して、ストリーム自体の中のフロント依存性（front dependency）を示す。換言すると、このＡＵ（ｎ）は、どのアクセスユニットが次にデコードされるかを示す。このシグナリングは、モード０では次のアクセスユニット（固有の）のＤＴＳ又はモード１では次のアクセスユニットのＩＤのいずれかを記述する、各パケット内のマーカによって行われる。
【００６５】
この場合、再生される最初の要素の値が加えられる。
【００６６】
例えば、これは同報通信／マルチキャストモードにおけるＢＩＦＳストリームとすることができる。
【００６７】
［スケーラブルモード（モード２）］
ストリームはこれらのアクセスユニットのそれぞれに対して、従属するストリームに関する依存性を示す。このストリームは一意的であると想定される。
【００６８】
この原理は、図１に示されている。従属ストリーム１０のストリームユニット１１は、通常、ＳＬヘッダ（SLHeader）１１１及びデータフィールド（SL payload）１１２を含む。このヘッダ１１１は、特に、２つのポインタ、Ｄｅｐ１及びＤｅｐ２を含み、これらのポインタは、それぞれ基本ストリーム１４のストリームユニット１４１及び１４２を有する従属リンク１２及び１３を定義する。この基本ストリーム１４は、ストリームユニット１１を処理するために周知でなければならない。
【００６９】
［ＩＰＭＰモード（モード３）］
ストリームはこれらのアクセスユニットのそれぞれに対して、データ保護システムがユニットをデコードできるようにする識別子を示す。これが与えられると、このマーカはユニットを解読できるかどうかについて応答することができる。
【００７０】
ＳＬ設定記述子は、１つ又は数個の従属記述子（DependencyDescriptor）及び従属マーカ（DependencyMarker）を含むことができ、これにより、ストリーム内の種々の依存性の事例を調整することができる。（先験的には、１つの従属マーカで十分であるが、数個が存在することがある。）
【００７１】
このため、ＳＬ設定（SLConfig）が従属マーカを含む場合、それは自身のパケットのそれぞれに対してバージョンＩＤを示す（モード１及び３）。
【００７２】
アクセスユニット（AccessUnit）に対応するＳＬパケットのヘッダには、下記の事項、すなわち、ＳＬ設定記述子の各従属マーカに対する長さマーカ（markerLength）と、各従属記述子に対するdepLength長さの従属ポインタ（dependencyPointer）とが発見される。
【００７３】
これらの様々なマーキングが実行されると、システムは下記の事項、すなわち、ａ）モード０及び１により、「同報通信」モードで動作することと、ｂ）拡張性の依存性を管理することと、ｃ）ＩＰＭＰの依存性を管理することとを行うことができる。
【００７４】
ＩＰＭＰモードの動作説明
オブジェクトのオブジェクト記述子が受信されると、端末は関連した各ストリームのＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすること、特にマーカをデコードすることが可能になる。
【００７５】
ＩＰＭＰの場合は、図３に示すように、ＤＴＳ及び／又は従属ポインタが存在する。
【００７６】
各ストリームのＡＵについては、それがデコードされる前に、それが少なくともいずれかのストリーム識別子のデータ、すなわちＥＳＩＤ、ＤＴＳ、従属ポインタ（ＩＰＭ）３１を備えることによって、それはＩＰＭＰシステム３２により処理される。次に、ＩＰＭＰシステムは、デコーディングに関する情報３１１（Code Dec）を考慮することによってＡＵを処理（解読）できる場合は応答する（３３）。処理できなくて、ユニットのＤＴＳが終了する場合、ＡＵは破壊される（３４）。このため、矛盾したＡＵをデコードしようとする試みは行われない。
【００７７】
図４の実施例では、一方では図３の要素が存在するが、他方では、デコーディング（４１）の後に、画像の再生にリンクされた処理が存在する。実際に、フィールド３１２（CodeComp）を用いて、タトゥー（tattoo）すなわち画像上にメッセージを追加することなどの構成に関するデータは送信することができる。データ保護システム３２が、例えば、デコーダが必要なタトゥーを持っていないために、この構成を処理する方法を知らない場合は（それは画像を表示する方法を知らない）、画像は表示されない（４３）。
【００７８】
フレームは、例えばロゴでマークされることも予測できる。このロゴは、デコーダが正しいキーを持っていない場合は表示されない。
【００７９】
マルチキャスト／同報通信モードにおける動作の説明
この動作は図２の中で示されており、下記の事項、すなわち、送信されたストリーム２１と、第１のレシーバによって受信されたストリーム（セッション１）２２と、第１のレシーバによって受信されたストリーム（セッション２）２３と
を示す。
セッション１はパケット２１１で開始し、次にストリームユニット２１１が指すストリームユニット２１３を（２４）、次にリンク２５に基づいて、ストリームユニット２１５を取り入れる。
【００８０】
少し後で開かれたセッション２はストリームユニット２１２で開始する。ストリームユニット２１２はストリームユニット２１４を指し示す（２６）。
【００８１】
本発明によれば、２つ（又はそれ以上）のストリームユニットは、次の同じストリームユニットを指すことができる。それはマージ機構（merge mechanism）２７であり、ここでは、ストリームユニット２１３及び２１４の両方がストリームユニット２１５を指している。このため、それらは異なる時間に開始したが、２つのセッションは、「再生」段階の後、同じストリームユニット２１５を使用する。これにより、性能を明らかに向上させることができる。
【００８２】
この動作を具体的に説明する。
【００８３】
オブジェクト記述子を受信すると、端末はそれぞれの関連するストリームに対してＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすること、特に、マーカのデコーディングが可能になる。
【００８４】
このため、マルチキャスト／同報通信の場合は、モード０又は１では少なくとも１つの従属ポインタ、及びマーカ（「ＩＤによる」モード１）がＤＴＳに対して存在する。その結果、端末は各ストリームについて、どれが再生すべき最初のユニットかを知っている。このため、端末は各ストリームに対応する最初のユニットの再生を試みる。
【００８５】
端末が最初のユニットを受信すると、端末はその内容を表示し始めることができる。各ユニットは受信すべき次のユニットを従属ポインタの中に記述し、ＤＴＳ／マーカは独自の方法で各ユニットを識別する。
【００８６】
端末が最初のユニットを受信しない場合（端末はこのことをタイムアウトによって知ることができる）、又は所望のマーカに対応しないＲＡＰ＝１形をこのストリームユニットに関して受信する場合、端末は切断し（セッションを完全に閉じる）、また再接続しようとする。
【００８７】
この仕組みは、セッションのマネージャを考慮していることに注意されたい。
【００８８】
また、「ＩＤによる」モードは、次のユニットのＤＴＳが前もって知らされていない場合に必要とされることにも注意されたい。
【００８９】
この方式は、特に、ＢＩＦＳ、ＯＤ、テクスチャー、オーディオのクリップ、及びＭＰＥＧ−４におけるビデオのクリップに対して使用される。それはストリーム化されたオーディオ／ビデオに対しては、もはや使用されない。
【００９０】
拡張可能なモードにおける動作の説明
オブジェクト記述子が受信されると、端末は関連するストリームのそれぞれに対して、ＳＬ設定記述子をチェックする。これにより、各ストリームに対してＳＬパケットのヘッダをデコードすることが可能になる。拡張可能なビデオについては、１つのストリームをベースとして使用し、別の１つ又は数個のストリームはこのストリームに依存する。基本のストリームに依存する各ストリームは、従属記述子を宣言する。
【００９１】
改良ストリームの各ＡＵに関しては、端末はＡＵの従属ポインタを用いて、それが依存する基本ストリームのＤＴＳを参照する。
【００９２】
大抵の場合、基本ビデオの２つの基準ＡＵを指し示すために、改良ストリームの中に２つの従属ポインタが存在する。
【００９３】
同報通信＋ＩＰＭＰモードにおける動作の説明
この場合、例えばＢＩＦＳは、ＳＬ構成の中に２つの従属記述子を含む。１つは同報通信モードのために、他の１つはＩＰＭＰモード用に含む。同報通信モードがＩＤによる場合、それはマーカを含む。
【００９４】
アプリケーションの実施例
プログラム開始前の広告の同報通信
インターネット用ストリーミングの幾つかの場合では、コンテンツプロバイダは、内容自体を送る前に広告を意図的に送っている。インターネットのシナリオはユニキャスト（unicast）（クライアント−サーバ）であるため、これは段階的に行われる。広告のダウンロード及び広告の終了により、ビデオのストリーミングが開始される。
【００９５】
クライアント−サーバの動作に頼るものがないマルチキャスト又は同報通信のシナリオでは、要求の考えがない。このため、ユーザは通常現在の表示ステータスにアクセスするだけである。
【００９６】
フロント参照機構のおかげで、このシナリオはマルチキャスト又は同報通信では可能にされる。
【００９７】
実際に、広告は周期的な方法で送ることができ、また現在のプログラムを広告の後にマージすることができる。
【００９８】
このことは、例えば、全てのユーザが確実に始めに広告を見るようにすることができる（この間に、コンテンツは効率的でこま切れな(incremental)やり方でダウンロードすることができる）。
【００９９】
同じ種類のアプリケーションを、各同報通信する映画のための、映画のカテゴリーの通知とすることができる（親同伴が望ましい、年令が１６才未満、など）。
【０１００】
スケーラブルな条件付きアクセス
ここでのアイディアは、ユーザの正しい権利に基づいて別々に見ることができるビデオ及びオーディオのストリーム（固有の）を送ることである。保護キーに関したビデオフレームの依存性の信号により、ユーザがキーを有するストリームのみをデコードすることを可能にする。全てのキーを有する者は、全ての画像をデコードできるが、より少ない特権しか持たない者は、数個の画像しかデコードできない。これはよりスケーラブルなやり方（ここでは、時間的なスケーラビリティ）で、条件付きアクセスを実行できるようにする。
【０１０１】
最も複雑で有用なシナリオは、幾つかのストリームがあり、時間的なスケーラビリティ及び解像度を調整できるシナリオである。
【０１０２】
そのため、このフレーム依存のシステムでは、ほぼ連続的な方法で媒体に調整アクセスする（modulate access）ことが可能である。
【０１０３】
従って、あるユーザは５チャネルにわたって音声を受信できるキー（空間的な音声）を有し、別のユーザはステレオの音声のみを受信できるキーを有する。このことは、より詳細なインボイスを作ることも可能にする。
【０１０４】
ＭＰＥＧ−４の双方向テレビ
「セットトップボックス」のアプリケーションが静的であることを考えるのではなく、これらの種類のアプリケーションのいずれも、異なるチャネルを得ることができるＭＰＥＧ−４のアプリケーション（インライン式の機構）であると考えることができる。このＭＰＥＧ−４のアプリケーションは、アクティブ２４ｈｘ２４ｈであり、グラフィカルインターフェースなどを完全に再構成できる。
【０１０５】
シーンを同報通信する技術は、アプリケーションの部分（ＭＰＥＧ−Ｊ）だけでなくグラフィカルインターフェース（ＢＩＦＳ／テクスチャー／ＯＤ）をも効率的にダウンロードすることができる。
【０１０６】
このことは、より迅速な展開を可能にする。
【０１０７】
［付属書］
本発明によるＭＰＥＧ−４形の仕様の例
定義
ストリームユニット（ＡＵ：アクセスユニット）
基本ストリームの中で個別にアクセス可能なデータユニットである。ストリームユニット（又はアクセスユニット）は、時間のデータ要素に起因すると考えられる最小のエンティティーである。
【０１０８】
オーディオビジュアル・オブジェクト
オーディオ及び／又はビジュアルな方法で明示された自然の又は合成された（仮想の）オブジェクトの表現である。この表現は、ＢＩＦＳのシーケンス記述の中のノード又はノードのグループに該当する。各オーディオビジュアル・オブジェクトは、１つ又は数個のオブジェクト記述子を使用するゼロ、１つ、又は数個の基本ストリームに関連付けられる。
【０１０９】
オーディオビジュアル・シーケンス（ＡＶシーン）
シーンを記述し、自身の空間的又は時間的な属性を定義するデータ要素を有する、オブジェクト及びユーザの相互作用の結果として生ずる動作を含む、一連のオーディオビジュアル・オブジェクトである。
【０１１０】
シーン用のバイナリフォーマット（ＢＩＦＳ）
シーン記述のパラメトリック形式の符号化された表現である。
【０１１１】
端末
ＩＳＯ／ＩＥＣ１４４９６−１によって定義されたものと同様の、対話型のオーディオビジュアルのシーンの符号化された表現を送信又は受信及び表示するシステムである。それは、ＩＳＯ／ＥＩＣ１４４９６に準拠した独立したシステム又はアプリケーションシステムの一部とすることができる。
【０１１２】
略語及び記号
ＡＵ アクセスユニット又はスチームユニット
ＡＶ オーディオ−ビジュアル
ＢＩＦＳ シーン用のバイナリフォーマット
ＣＭ 構成メモリ
ＣＴＳ 構成タイムスタンプ
ＣＵ 構成ユニット
ＤＡＩ ＤＭＩＦアプリケーションインターフェース（ＩＳＯ／ＩＥＣ１４４９６−６を参照）
ＤＢ デコーディングバッファ
ＤＴＳ デコーディング用タイムスタンプ
ＥＳ 基本ストリーム
ＥＳＩ 基本ストリーム用インターフェース
ＥＳＩＤ 基本ストリーム用識別子
ＦＡＰ フェイシャルアニメーション（Facial Animation）用パラメータ
ＦＡＰＵ ＦＡＰユニット
ＮＣＴ ノード符号化テーブル
ＮＤＴ ノードデータ形
ＯＣＩ オブジェクト内容情報
ＯＣＲ オブジェクトクロック基準
ＯＤ オブジェクト記述子
ＯＤＩＤ オブジェクト記述子用識別子
ＯＴＢ オブジェクト時間ベース
ＰＬＬ 位相ロックループ
ＱｏＳ サービスの質
ＳＤＭ システムデコーダのモデル
ＳＬ 同期化層
ＳＬ−Ｐａｃｋｅｔ 同期化層のパケット
ＳＰＳ ＳＬパケット化ストリーム
ＳＴＢ システム時間ベース
ＴＴｓ テキスト−音声
ＵＲＬ ユーアールエル
ＶＯＰ ビデオオブジェクト面
ＶＲＭＬ 仮想現実モデリング言語
【０１１３】
ＳＬパケット用ヘッダの構成
シンタックス
【表２Ａ】
【表２Ｂ】
【０１１４】
セマンティクス
ＳＬパケット用ヘッダは、各個々の基本ストリームの必要性に基づいて構成することができる。選択できるパラメータは、クロック基準はもとより、タイムスタンプの存在、解像度、及び精度を含む。この柔軟性により、例えば、ＳＬパケット用ヘッダの内容を少し増加することができる。
【０１１５】
各基本ストリームに対して、この構成は、オブジェクト記述子に関連したES#Descriptorの一部であるＳＬ設定記述子の中で送信される。
【０１１６】
ＳＬパケット用ヘッダの中で構成できるパラメータは２つの種類、すなわち、各ＳＬパケットに適用されるもの（例えば、ＯＣＲ、sequenceNumber）及びアクセスユニットの中で単に表示されるもの（例えば、タイムスタンプ、アクセスユニット長（accessUnitLength）、瞬間ビットレート（instantBitrate）、劣化優先度（degradationPriority）など）に分割することができる。
【０１１７】
（あらかじめ定義された）列は、以下に詳しく記載したような、所定のパラメータの組のディフォルト値を固定することができる。この表は、将来のプロファイルに必要な設定などの所定の設定を含むように、ＩＳＯ／ＩＥＣ１４４９６の修正案によって更新することができる。
【０１１８】
【表３】
【０１１９】
表３は、ＳＬ設定記述子のあらかじめ定義された値の組を示している。
【０１２０】
【表４】
【０１２１】
表４は、ＳＬ設定記述子のあらかじめ定義された値の詳細を示している。
【０１２２】
useAccessUnitStartFlag−accessUnitStartFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useAccessUnitEndFlag−accessUnitEndFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useAccessUnitStartFlag及びuseAccessUnitEndFlagが使用可能でない場合、これは各ＳＬパケットが完全なアクセスユニットに対応することを意味する。
useRandomAccessPointFlag−RandomAccessPointFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
hasRandomAccessUnitsOnlyFlag−各ＳＬパケットがランダムアクセス点に対応することを示す。この場合、randomAccessPointFlagを使用する必要はない。
usePaddingFlag−paddingFlagがこの基本ストリームの各ＳＬパケット用ヘッダの中に存在することを示す。
useTimeStampFlag−タイムスタンプがこの基本ストリームを同期させるために使用されることを意味する。それらはＳＬパケット用ヘッダの中に移送される。別の方法では、このＳＬパケット用ヘッダの中に移送されたaccessUnitRate、compositionUnitRate、startDecodingTimestamp、及びstartCompositionTimeStampのパラメータを同期化のために使用する必要がある。
【０１２３】
開始及び持続時間のタイムスタンプ（useTimeStampFlag=0）は、エラーがない環境を含む一定の条件の下でのみ使用することができる。ランダムアクセスは容易ではない。
useIdleFlag−この基本ストリームの中でidleFlagが使用されることを示す。
durationFlag−この基本ストリームに対するアクセスユニット及び構成ユニットの一定の持続時間が、続いて表示されることを示す。
timeStampResolution−第２のパルスによるオブジェクトの時間ベースの解像度である。
OCRResolution−第２の周期によるオブジェクトの時間ベースの解像度である。
timeStampLength−ＳＬパケット用ヘッダ内のタイムスタンプ・フィールドの長さである。timestampLengthはゼロから６４ビットの値を取らなければならない。
OCRlength−ＳＬパケット用ヘッダ内のobjectClockReferenceフィールドの長さである。数個のゼロは、この基本ストリームの中にはobjectClockReferenceが存在しないことを示す。OCRstreamFlagが配置される場合は、OCRLengthはゼロでなければならない。別の方法では、OCRlengthはゼロと６４ビットとの間の値を持つ。
AU#Length−この基本ストリームに対するＳＬパケット用ヘッダ内のaccessUnitLengthフィールドの長さである。AU#Lengthはゼロと３２ビットとの間の値を取る必要がある。
instantBitrateLength−この基本ストリームのＳＬパケット用ヘッダ内のinstantBitrateの長さである。
degradationPriorityLength−この基本ストリームのＳＬパケット用ヘッダ内にあるdegradationPriority用フィールドの長さである。
AU#SeqNumLength−この基本ストリームのＳＬパケット用ヘッダ内にあるAU#sequenceNumber用フィールドの長さである。
packetSeqNumLength−この基本ストリームのＳＬパケット用ヘッダ内にあるpacketSequenceNumber用フィールドの長さである。
timeScale−アクセスユニット及び構成ユニットの持続時間を表示するために使用される。第２のものは、またtimeScaleセクションに分割される。
accessUnitDuration−アクセスユニットの持続時間は、accessUnitDuration * 1/timeScale秒である。
compositionUnitDuration−構成ユニットの持続時間は、compositionUnitDuration * 1/timeScale秒である。
startDecodingTimeStamp−この基本ストリームの第１のアクセスユニットをデコードする必要がある時間を転送する。それはtimeStampResolutionによって規定された決定の中で転送される。
extension#field#control−このフィールドはＳＬの拡張を可能にする。値01b0は、記述子をSLConfigDescriptorの最後に配置する必要があることを示す。
markerDescriptors−この表は、ストリーム内の次のアクセスユニットを識別するマーカの記述子を示す。
dependencyDescriptors−この表は、前のアクセスユニット又は次のユニットをどのように参照しなければならないかを規定する従属記述子を示す。
【０１２４】
MarkerDescriptor
シンタックスは以下のようになる。
【表５】
【０１２５】
DependencyDescriptor
シンタックス
【表６】
【０１２６】
セマンティクス
モード
下記のように４つの定義されたモードがある。
モード０：ＤＴＳによるフロントの参照
モード１：マーカによるフロントの参照
モード２：バックスケーラビリティ（back scalability）の参照
モード３：ＩＰＭＰモード
【０１２７】
モード０及び１は、各アクセスユニットに次のアクセスユニットを参照させる。
【０１２８】
モード２は、各アクセスユニットにこのアクセスユニットをデコードするために必要な前のアクセスユニットを参照させる。（注意：場合によっては、３つ以上のdependencydescriptorsが２つ以上の必要なアクセスユニットを参照するために必要である。）
【０１２９】
モード３は、各アクセスユニットが不明瞭な識別子を含むことができるようにする。このアクセスユニットのデコーディング及び組立てが可能かどうかを決定するために、ＩＰＭＰシステムはこの不明瞭な識別子を使用できる。
【０１３０】
モード１及び３は、ストリームの中にMarkerDescriptorを必要とする。
【０１３１】
ＥＳＩＤ
このオプションのフィールドは、DependencyDescriptorが参照するストリームを識別する。
【０１３２】
SimpleDependencyDescriptorに関しては、ＥＳＩＤは下記の方法、すなわち、
モード０及び１：現在のストリームであることと、
モード２：dependsOnESIDに依存することと、
モード３：非適用であることと計算される。
dependencyLength−マーカ（存在する場合）又はdecodingTimeStampのいずれかの長さ。
value−第１のマーカ又はデコードする次のアクセスユニットの識別子の値。
【０１３３】
ＳＬパケット用ヘッダの仕様
シンタックス
【表７Ａ】
【表７Ｂ】
【０１３４】
セマンティクス
accessUnitStartFlag−これが１の場合、このＳＬパケットについてのロードの最初のバイトがアクセスユニットの開始点であることを示す。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されている場合、下記のルールに基づいて、そのディフォルト値を前のＳＬパケットから知ることができる。
【０１３５】
accessUnitStartFlag = (the SL packet before accessUnitEndFlag=1)?1:0
accessUnitEndFlag−これが１の場合、このＳＬパケットについてのロードの最後のバイトが現在のアクセスユニットの最後のバイトであることを示す。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されている場合、下記のルールに基づいて、そのディフォルト値はＳＬパケットを受信した後でのみ知ることができる。
【０１３６】
accessUnitEndFlag = (the SL packet after accessUnitStartFlag==1)?1:0
AccessUnitStartFlag及びAccessUnitEndFlagのいずれもがＳＬパケット用ヘッダの中で構成されていない場合、各ＳＬパケットは各accessUnitStartFlag = accessUnitEndFlag = 1である１つのアクセスユニットに対応することを意味する。
【０１３７】
ＳＬパケット用ヘッダがaccessUnitEndFlag及びaccessUnitLengthではなくaccessUnitStartFlagを使用するように構成される場合、端子は次のアクセスユニットが受信される前にアクセスユニットの端部を決定することができるという保証がないことに注意されたい。
【０１３８】
OCRflag−これが１の場合、objectClockReferenceが後に続くことを示す。OCRflagのディフォルト値はゼロである。
idleFlag−この基本ストリームが未確定の時間に対して不活性（すなわち、所望のデータがない）であることを示す。デコーダはこの符号を使用して、故意の欠如であるか又は次に続くＳＬパケット内のエラーによる欠如であるかを区別することができる。
paddingFlag−このＳＬパケットの中で使用されるデータ完了モードを示す。paddingFlagのディフォルト値はゼロである。
paddingBits−このＳＬパケットの中で使用されるデータ完了モードを示す。paddingBitsのディフォルト値はゼロである。
【０１３９】
paddingFlagが配置され、paddingBitsがゼロの場合、このＳＬパケットの後に続くロードが完了バイトのみから構成されることを示す。paddingFlagが配置され、paddingBitsがゼロの場合、accessUnitStartFlag、randomAccessPointFlag及びOCRflagを配置する必要がある。
【０１４０】
paddingFlagが配置され、paddingBitsがゼロよりも大きい場合、このＳＬパケットのロードの後に、ロードのバイトを整列させるためにゼロビットで形成されたpaddingBitsが続く。
【０１４１】
packetSequenceNumber−存在する場合、それはモジュールカウンタとして、各ＳＬパケットに対して連続的に増加させる必要がある。デコーダの中で不連続があると、１つ又は数個のＳＬパケットの欠落につながる。この場合、エラーを同期化層で表示する必要がある。このシンタックス要素をＳＬパケット用ヘッダの構成から割愛すると、同期化層によるストリームユニットの連続性の制御は、この基本ストリームに対しては行うことができない。
【０１４２】
ＳＬパケットの複製：ＳＬパケット用ヘッダの中にsequenceNumberフィールドを有する基本ストリームは、エラーを回復するためにＳＬパケットの複製を使用しなければならない。この複製されたＳＬパケットは、オリジナルの直ぐ後に続く必要がある。複製されたＳＬパケットのpacketSequenceNumberは、同じ値を有しなければならず、オリジナルのＳＬパケットの各バイトを、objectClockReferenceフィールド（存在する場合）を除いて複製する必要がある。このフィールドは、複製されたＳＬパケットに対する有効な値を符号化する必要がある。
【０１４３】
degPrioFlag−これが１の場合、degradationPriorityがこのパケットに存在することを示す。
degradationPriority−このＳＬパケットのロードの重要性を示す。streamPriorityは、ＥＳの基本的優先権を定義する。degradationPriorityは、基本的優先権に関してこのＳＬパケットに対する優先権の低下を定義する。このＳＬパケットに対する優先権は、下記の式によって与えられる。
SL#PacketPriority = streamPriority - degradationPriority
degradationPriorityは、この値を次に現れるまで維持する。特定の分配層(distribution layer)の例に対するアダプタだけでなく基本ストリーム用デコーダも、この表示を使用することができる。様々な基本ストリームのＳＬパケット間の劣化の割合は、the SL#PacketPriorityが低下するにつれて増加する。
objectClockReference−オブジェクト用のタイムスタンプを含む。ＯＴＲのｔの時間の値は、下記の式に基づいて、このＯＣＲのタイムスタンプから再構成される。
t = (objectClockReference/SL.OCRResolution) + K*(2SL OCRLength/SL.OCRResolution)
ここでｋは、objectClockReferenceのカウンタがカバーした時間である。
【０１４４】
objectClockReferenceは、OCRflagが配置されている場合のみ、ＳＬパケット用ヘッダの中に存在する。
１つのＯＣＲ値のみを、ＳＬパケットの内部にローディングすることなく移送できる。
２進のストリームの中でaccessUnitStartFlagが特に示したときに、アクセスユニットの最初にのみ存在するシンタックス要素のセマンティクスが、以下に記述されている。
【０１４５】
randomAccessPointFlag−これが１の場合、この基本ストリームの内容へのランダムアクセスが可能であることを示す。randomAccessPointsFlagは、accessUnitStartFlagが配置される場合のみ配置されなければならない。このシンタックス要素がＳＬパケット用ヘッダの構成から削除されると、そのディフォルト値は、この基本ストリームに対してはSLConfigDescriptor.hasRandomAccessUnitOnlyFlagの値となる。
AU#sequenceNumber−存在する場合、それはモジュールカウンタとして各アクセスユニットに対して連続的に増加される必要がある。デコーダに不連続があると、ユニット全体にわたって１つ又は数個の欠落につながる。この場合、エラーを同期化層のユーザに表示する必要がある。このシンタックス要素をＳＬパケット用ヘッダの構成から割愛すると、同期化層によるストリームユニットの連続性の制御は、この基本ストリームに対しては実行することができない。
【０１４６】
アクセスユニットの複製：直前のＡＵではなく同じ数のシーケンスを用いて送られたアクセスユニットは、無視する必要がある。そのような複製のアクセスユニットは、そのオリジナルはＲＡＰを持っていないが複製のユニットはそれを有しており、送信されたストリームに対してランダムアクセス点を加えることができる。これにより、他のクライアントは既にストリームを受信している限りは、クライアントはその送信の間に規定された点でストリームに入ることができる。
【０１４７】
decodingTimeStampFlag−デコーディング用のタイムスタンプがこのパケットの中に存在することを示す。
compositionTimeStampFlag−タイムスタンプの構成がこのパケットの中に存在することを示す。
accessUnitLengthFlag−このアクセスユニットの長さがこのパケットの中に存在することを示す。
instantBitrateFlag−instantBitrateがこのパケットの中に存在することを示す。
decodingTimeStamp−関連したSLConfigDescriptorの中で構成されたデコーディング用タイムスタンプである。このアクセスユニットのデコーディング時間ｔｄは、下記の式に基づいて、このデコーディング用タイムスタンプから再構成される。
【０１４８】
td = (decodingTimeStamp / SL.timeStampResolution + K* 2SL.timStampLength / SL.timeStampResolution
ここで、ｋはdecodingTimeStampのカウンタがカバーした時間である。
decodingTimeStampは、デコーダの時間がこのアクセスユニットに対する時間構成から異なっている場合のみ存在しなければならない。
【０１４９】
compositionTimeStamp−関連したSLConfigDescriptorの中で構成されたタイムスタンプの構成である。第１の構成ユニットの時間構成ｔｃは、このアクセスユニットが下記の式に基づいたタイムスタンプの構成から再構成されるという事実から結果として生ずる。
【０１５０】
td = (compositionTimestamp / SL.timeStampResolution + k*2SL.timeStampLength / SL.timeStampResolution
ここで、ｋはcompositionTimeStampのカウンタがカバーした時間である。
【０１５１】
accessUnitLength−バイトで表したアクセスユニットの長さである。このシンタックス要素が存在しないか又は値がゼロの場合、アクセスユニットの長さは未知である。
instantBitrate−次のinstantBitrateのフィールドが見つかるまでの、この基本ストリームの１秒当たりのビット数の瞬間的なビットレートである。
markerValue−アクセスユニットを識別できるマーカの値である。このマーカは、markerDescriptorが存在する場合に定義される。
DependecyPointerValue−DependencyDescriptorによって定義されたＤＴＳ又はマーカ指数である。
MarkerDescriptorCount：マーカ用記述子の数である。
DependencyDescriptorCount：従属記述子の数である。
【０１５２】
デコーディング用セマンティクス
フロント参照機構（モデル０及び１）
ＥＳに関連したＳＬ設定記述子は、ストリームの中に入ることができる第１のアクセスユニットを示す。
【０１５３】
参照モードがＤＴＳの場合、ＳＬ設定記述子はdecodingTimeStampを含まなければならない。
【０１５４】
そうでない場合、マーカは各アクセスユニットをマークするために使用される。０及び−１は下記のように、特別な意味を有する、すなわち、／／０は、これ以上のアクセスユニットは後に続いて来ないことを意味し、／／−１は、どのアクセスユニットも使用できないことを意味する。
【０１５５】
各アクセスユニットは、マーカと、各アクセスユニットが次のアクセスユニットを示すことを可能にするdependencypointerとを含む必要がある。
【０１５６】
後方参照機構（モデル２）
ＳＬ設定記述子は、ＥＳＩＤが参照するＥＳ内のアクセスユニットを示すｎ個の従属記述子形の記述子を定義する。
【０１５７】
現在のストリームの各アクセスユニットは、識別子がES#baseと呼ばれるＥＳＩＤであるＥＳに対して、自身のＤＴＳを通して（ＥＳＩＤによって識別された）ES#baseのアクセスユニットを参照する従属ポインタを用いて、アクセスユニットを指し示す。
【０１５８】
ＩＰＭＰモード（モード３）
従属ポインタは、デコーディングの前にＩＰＭＰシステムに送信される。この不透明なポインタにより、ＩＰＭＰのリソースはアクセスユニットをデコードすることが可能か否かを決定できる。キーが受信されていない場合又はそれを行える権限がない場合は、それは否定の応答を行うことができる。この従属ポインタは、デコーディングの後で構成ユニットにリンクされる。
【０１５９】
それは構成する前にＩＰＭＰシステムに戻され、次にＩＰＭＰのリソースは、ユニットが存在できるか否かを決定する。
【０１６０】
クロック基準ストリーム
streamType = ClockReferenceStreamの基本ストリームは、オブジェクタ記述子（objector descriptor）を用いて宣言される必要がある。それは、オブジェクトのクロック基準用タイムスタンプを送信するために使用される。名前の組の中の複数の基本ストリームは、クロック基準情報を繰り返し送信することを避けるために、ＳＬ設定記述子内のOCR#ES#IDのシンタックス要素を用いて、そのようなClockReferenceStreamを参照できる。それにもかかわらず、OCR#ES#IDを用いる基本ストリーム間を循環して参照することは許可されていないことに注意されたい。
【０１６１】
自動化層上では、ＳＬレベルでパッケージ化されたストリームに対してＳＬパケット用ヘッダのシンタックスを構成することによって、ClockReferenceStreamを実行して、OCRResolution及びOCRLengthの必要なＯＣＲ値のみがＳＬパケット用ヘッダの中に存在するようにする。
【０１６２】
ＳＬパケットのチャージは、streamType = ClockReferenceStreamのパッケージ化されたＳＬストリームの中に存在しない。
【０１６３】
クロック基準ストリームに関するDecoderConfigDescriptorの中で、ObjectTypeIndicationを「0xFF」、１の間のhasRandomAccessUnitsOnlyFlag、及び「０」の間のbufferSizeDBの上に配置する必要がある。
【０１６４】
クロック基準ストリームのＳＬ設定記述子に対する推奨値を以下に示す。
【０１６５】
表８は、ClockReferenceStreamのＳＬ設定記述子のパラメータのＳＬ設定記述子の値を示している。
【０１６６】
【表８】
【０１６７】
同じ時間ベースのオブジェクトを共有する基本ストリームに関する制約
時間ベースのオブジェクトをOCR#ES#IDにより幾つかの基本ストリームの間で共有できる場合、下記のように、これらの基本ストリームへのアクセス及びそれらの処理に関する多数の制約が存在する。
【０１６８】
幾つかの基本ストリームが単純な時間ベースのオブジェクトを共有する場合、端末は集積されたクロック基準情報のない基本ストリームを、例えアクセス可能であっても、オブジェクトのクロック基準情報を伝送する基本ストリームがアクセス可能になるまで使用してはならない。
【０１６９】
集積されたクロック基準情報のない基本ストリームを、オブジェクトのクロック基準情報を伝送する基本ストリームの後で端子が利用可能になる場合、それを他のストリームと同期して配信する必要がある。このことは、時間ベースのオブジェクトの現在の値に依存するそのようなストリームを最初から配信してはならないことを意味することに注意されたい。
【０１７０】
オブジェクトのクロック基準情報を伝送する基本ストリームが利用できなくなる場合、又は他の場所で（例えば、待機モードで）使用される場合、同じ時間ベースのオブジェクトを使用する他の全ての基本ストリームはこの方式に従う必要がある、すなわち、それらは使用不可能になるか又は同じ方向で処理される必要がある。
【０１７１】
集積されたオブジェクトのクロック基準情報がない基本ストリームが利用不可能になっても、これは時間ベースのオブジェクトを共有する他の基本ストリームには影響を与えない。
【０１７２】
クロック基準及びタイムスタンプの値に対する構成オプションの使用
時間ベースのオブジェクトの再生における曖昧性の解決
objectClockReferenceの値の長さが限定されているために、これらのタイムスタンプは曖昧なことがある。ＯＴＢの時間の値は、下記の式に基づいて、objectClockRferenceがＳＬパケット用ヘッダに送信されるたびに再構成することができる。
tOTB#reconstructed = (objectClockReference / SL.OCRResolution) + k*(2SL.OCRLength / SL.OCRResolution)
ここで、ｋはループの数を示す整数の値である。結果として生じた時間ベースのtOTB#reconstructedは、秒で測定される。
【０１７３】
基本ストリームに対する最初のobjectClockReferenceが承認されると、ｋの値を１に設定する必要がある。後に続くobjectClockReferenceが現れるたびに、ｋの値は下記のように推定される。
【０１７４】
端末は、各瞬間に時間ベースのオブジェクトの値を推定するために、リソースを理解しなければならない。
【０１７５】
objectClockReferenceが受信されるたびに、ＯＴＢのtOTB#estimatedの現在の推定値をサンプリングする必要がある。これにより、tOTB#res(K)はｋの様々な値に対して評価される。持続時間│tOTB#estimated- tOTB#rec(k)│を最小にするｋの値は、tOTB#reconstructedに対する正しい値と考える必要がある。この値は、時間ベースのオブジェクトの予測機構に対する新しく貢献するものとして使用する必要がある。
【０１７６】
アプリケーションは、objectClockReferenceの要素に対して適当な長さ及び解像度を選択すること、並びに基本ストリームの中のobjectClockReferenceの挿入値に対して十分に高い周波数を選択することによって、この方式がｋに対して曖昧でない値を確実に発生するようにしなければならない。この値に対する選択は、ＳＬパケットに関する配信ジッタ（delivery jitter）及び端末とレシーバのクロック間の最大予想遅れに依存する。
【０１７７】
タイムスタンプの再生における曖昧性の解決
decodingTimeStamp及びcompositionTimeStampの値の長さが制限されていることにより、これらのタイムスタンプは、下記の式で示すように、曖昧になることがある。
Tts(m)=(TimeStamp/SL.timeStampResolution)+ m * (2SL.timeStampLength/SL.timeStampResolution)
ここで、TimeStampはdecodingTimeStamp又はcompositionTimestampのいずれかであり、ｍはループの数を示す全体の値である。
【０１７８】
タイムスタンプの正しいttimestampの値は、以下のように推定することができる。
TimeStampが受信されるたびに、ＯＴＢのtOTB#estimatedの現在の推定値をサンプリングする必要がある。tts(m)は、ｍの様々な値に対して評価される。期間│ tOTB#estimated- tts(m)│を最小にするｍの値は、ttimestampに対する正しい値と考えられる。
【０１７９】
アプリケーションは、時間事象の曖昧でない位置決めに関する要求事項に適合するために、各個別の基本ストリームに対して、タイムスタンプの長さ及び解像度を独立に選択することができる。この選択は、TimeStampが示した時点の後で、TimeStampが付いたＳＬパケットを送ることができる最大の時間及び時間の位置決めに関する要求された精度に依存する。
【０１８０】
オブジェクトのクロック基準及びタイムスタンプの使用に関する注釈
オブジェクトベースの時間の時系列により、/SL.OCRResolutionよりも大きい２つの別個の瞬間を区別することができる。アプリケーションが基本ストリームの組を同期化するために必要な精度を得ることができるように、十分に大きな寸法でOCRResolutionを選択する必要がある。
【０１８１】
タイムスタンプ及び構成スタンプ（composition stamp）により、/SL.timeStampResolutionよりも大きく分離した２つの個別の瞬間を区別することができる。アプリケーションが所定の基本ストリームに対するアクセスユニットを得るという点で必要とする精度を得ることができるように、十分に大きな寸法を用いてtimeStampResolutionを選択する必要がある。
【０１８２】
OCRResolutionよりも大きいTimeStampResolutionでは、事象間の最良の区別を得ることはできない。TimeStampResolutionがOCRResolutionよりも小さい場合、この特定のストリームについての事象は、この与えられたOCRResolutionでは可能な最大の精度を得ることはできない。
【０１８３】
OCRLengthのパラメータは、ＳＬヘッダの構成の中で示される。2SL.OCRLength/SL.OCRResolutionは、ループする前にobjectClockReferenceのカウンタによってカバーされた時間間隔である。全ての基本ストリームに対して時間事象の曖昧でない位置決めを行うというアプリケーションの要求に適合するために、十分大きなOCRLengthを選択しなければならない。
【０１８４】
アプリケーションが上記のように定義されたｋ値を知る場合、ＯＴＢの時系列は各時間の値に対して明らかになっている。アプリケーションがｋの要素を再構成できない場合、例えば、追加の情報なしでランダムアクセスを可能にするアプリケーションの場合は、ＯＴＢの時系列はモード2SL.OCRLength/SL.OCRResolutionに対して曖昧にされる。このため、このＯＴＢを参照する各タイムスタンプは曖昧である。それにもかかわらず、予想された最大ジッタ及びアクセスユニットをデコードする前に送ることができる持続時間に関する制約は、その知識を用いるようなアプリケーションの環境の中では、明瞭であると考えることができる。
【０１８５】
2SL.OCRLength / SL.OCRResolutionよりも大きい時間間隔2SL.timeStampLength/ SL.timeStampResolutionを選択する基本ストリームは、曖昧でない方法で、２つの時間間隔の最小の時間事象だけを得ることができることに注意されたい。
【０１８６】
場合によっては、ｋ及びｍを正しく推定できない場合、バッファモデルを超える可能性がある。このことは、デコーダにより予期しない動作及び結果を招くことになる。
【０１８７】
例えば、１ｍｓの精度で基本ストリームを同期化したいと望むアプリケーションを考える場合、OCRResolutionを１０００以上に選択する必要がある（これにより、２つの連続したＯＣＴパルス間の時間は１ｍｓとなる）。OCRResolution=2000と仮定できる。
【０１８８】
アプリケーションは、ＳＴＢとＯＴＢとの間のジッタを０．１％（すなわち、秒当たり１ｍｓ）と仮定する。このため、クロックを少なくとも秒ごとに調整する必要がある（すなわち、最悪のシナリオでは、クロックは精度の制約により１ｍｓ外れる）。objectclockReferenceは１秒ごとに送られると仮定できる。
【０１８９】
アプリケーションが、要素ｋを再構成する必要なしに２４ｈの明瞭なＯＴＢの時系列を持ちたいと思うことがある。このため、OCRLengthは、結果として、2SL.OCRLength/SL.OCRResolution＝２４ｈのように選択される。
【０１９０】
ここで、アプリケーションが、基本ストリーム内の事象を１０ｍｓの精度以外に同期化することを望むと仮定する。TimeStampResolutionを１００以上に選択する必要がある（これにより、TimeStampの２つの連続したパルス間の時間は１０ｍｓに等しい）。TimeStampResolution＝２００であると仮定する。
【０１９１】
アプリケーションは、デコーダ又は構成時間の前に最大１分でアクセスユニットを送りたいと希望する。このため、timeStampLengthは、2SL timeStampLength/SL.timeStampResolution=2 minutesのように選択される。
【図面の簡単な説明】
【０１９２】
【図１】本発明に基づいた、データストリームの別のデータストリームに関する従属処理の原理を示す図である。
【図２】時間がずれたセッションの形式で、ストリームを同報通信する場合及び２つの端末が受信する場合に、本発明の実現を示す図である。
【図３】ストリームユニットのデコーディング又は解読にリンクされた同期の実例を示す図である（ＩＰＭＰ）。
【図４】２つの保護点（デコーディング及び廃棄）を有する、図３の別の実例を示す図である。
【特許請求の範囲】
【請求項１】
データストリームを構成するストリームユニットの少なくともいくつかが、あるデータストリーム中又は端末が先に受信している他のデータストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指す少なくとも１つのポインタを含み、該必要先行ユニットが受信されていない場合は、前記ストリームユニットの処理が前記端末において実行されないことを特徴とするストリームユニットに編成された少なくとも１つのデータストリームを少なくとも１つの端末に送信する送信方法。
【請求項２】
別々に送られる少なくとも２つのデータストリームの送信を含み、
第１のデータストリームの１つのストリームユニットは、少なくとも第２のデータストリームの少なくとも１つの必要先行ユニットを指し示し、
第１のデータストリームの前記ストリームユニットは、それ自体又は前記第２のデータストリームに含まれるデータの充実化データを含む、
ことを特徴とする請求項１に記載の送信方法。
【請求項３】
前記データストリームが階層符号化の異なる階層レベルに対応し、
所与の階層レベルのストリームユニットの処理は、対応する下位の階層レベルのストリームユニットが受信された場合にのみ実行されることを特徴とする請求項２に記載の送信方法。
【請求項４】
前記ストリームユニットが、必要先行ユニットのシーケンスを定義する少なくとも１つの先行データユニットを指し示すことを特徴とする請求項２又は３に記載の送信方法。
【請求項５】
前記ポインタの少なくとも１つが、検討されるストリームユニットのデコード及び／又は解読を可能にするデータを含む少なくとも１つの必要先行ユニットを得られるようにすることを特徴とする請求項１〜４のいずれかに記載の送信方法。
【請求項６】
検討されるストリームユニットのデータをデコード及び／又は解読して、デコードの後に表示する必要があるかどうかを端末が決定できるようにするデータを前記必要先行ユニットが含むことを特徴とする請求項５に記載の送信方法。
【請求項７】
前記ポインタの少なくとも１つが、前記端末が知り得るデータを指し示して、前記端末が対応するデータストリームを処理することができるかどうかを決定できるようにすることを特徴とする請求項１〜６のいずれかに記載の送信方法。
【請求項８】
前記ストリームユニットの少なくとも１つが、前記データストリーム又は続いて受信される別のデータストリームの少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする請求項１〜７のいずれかに記載の送信方法。
【請求項９】
後に受信されうる前記ストリームユニットが、前記ポインタとリンクするためのマーカを有することを特徴とする請求項８に記載の送信方法。
【請求項１０】
異なる時間に送信される少なくとも２つの同様なストリームユニットに含まれるポインタが、後に受信されうる同じストリームユニットを指し示すことを特徴とする請求項８又は９に記載の送信方法。
【請求項１１】
検討されるストリームユニットを考慮できるようにするために、デコードする必要がある少なくとも１つの先行するストリームユニットを指し示すことと、
検討されるストリームユニットをデコード及び／又は解読するために必要なデータを含む少なくとも１つの先行するストリームユニットを指し示し、及び／又は保護システムのステータスへの参照を指し示すことと、
少なくとも１つの後続するストリームユニットを指し示すことと
を含むグループに属する２つの役割の中からのポインタの役割を指定するインディケータを実現することを特徴とする請求項１〜１０のいずれかに記載の送信方法。
【請求項１２】
前記ストリームユニットの少なくとも幾つかが、前記役割を定義する従属記述子を含むことを特徴とする請求項１１に記載の送信方法。
【請求項１３】
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットとして自己を識別することができるようにする従属マーカを含むことを特徴とする請求項１〜１２のいずれかに記載の送信方法。
【請求項１４】
前記ストリームユニットの少なくとも幾つかが、前記ストリームの中に前記ストリームユニットの識別マーカを含むことを特徴とする請求項１〜１３のいずれかに記載の送信方法。
【請求項１５】
受信されたストリームユニットの先行する処理を必要としないような同期レベルで実行されることを特徴とする請求項１〜１４のいずれかに記載の送信方法。
【請求項１６】
請求項１から１５のいずれかの送信方法に基づいて送信されたデータストリーム。
【請求項１７】
少なくとも１つの端末に送信され及び／又は少なくとも１つの端末から受信され、また一方から他方へ別個に送信されるストリームユニットに編成されたデータストリームであって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は先に前記端末により受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことにより、前記ストリームユニットの処理は、前記必要先行ユニットが受信されていない場合は前記端末では実行されないことを特徴とするデータストリーム。
【請求項１８】
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は先行して端末で受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする互いに独立して送信されたストリームユニットに編成された少なくとも１つのデータストリームの形式で、少なくとも１つの端末に送信されるように作成されたデータ用のサーバ。
【請求項１９】
互いに独立して送信されたストリームユニットに編成された少なくとも１つのデータストリームを受信できる端末であって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする端末。
【請求項２０】
ストリームユニットに編成され、互いに独立して送信された少なくとも１つのデータストリームの受信方法であって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする受信方法。
【請求項２１】
前記ポインタの少なくとも１つが必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示し、次のステップ、すなわち、
ストリームユニットの前記ポインタを分析するステップと、
前記必要先行ユニットが受信されている場合は、前記ストリームユニットを処理するステップと
を含むことを特徴とする請求項２０に記載の受信方法。
【請求項２２】
ユーザが選択したプログラムにアクセスする前に、メッセージをシステマチックに同報通信することと、
条件に基づいてプログラムの特定の品質レベル及び／又は特定のオプションにアクセスをすることと、
対話型のテレビと
を含むグループに属するアプリケーションの１つとして行う請求項１から１５のいずれかに記載の送信方法の使用。
【請求項１】
データストリームを構成するストリームユニットの少なくともいくつかが、あるデータストリーム中又は端末が先に受信している他のデータストリーム中の少なくとも１つのストリームユニットであって、必要先行ユニットと呼ばれるストリームユニットを指す少なくとも１つのポインタを含み、該必要先行ユニットが受信されていない場合は、前記ストリームユニットの処理が前記端末において実行されないことを特徴とするストリームユニットに編成された少なくとも１つのデータストリームを少なくとも１つの端末に送信する送信方法。
【請求項２】
別々に送られる少なくとも２つのデータストリームの送信を含み、
第１のデータストリームの１つのストリームユニットは、少なくとも第２のデータストリームの少なくとも１つの必要先行ユニットを指し示し、
第１のデータストリームの前記ストリームユニットは、それ自体又は前記第２のデータストリームに含まれるデータの充実化データを含む、
ことを特徴とする請求項１に記載の送信方法。
【請求項３】
前記データストリームが階層符号化の異なる階層レベルに対応し、
所与の階層レベルのストリームユニットの処理は、対応する下位の階層レベルのストリームユニットが受信された場合にのみ実行されることを特徴とする請求項２に記載の送信方法。
【請求項４】
前記ストリームユニットが、必要先行ユニットのシーケンスを定義する少なくとも１つの先行データユニットを指し示すことを特徴とする請求項２又は３に記載の送信方法。
【請求項５】
前記ポインタの少なくとも１つが、検討されるストリームユニットのデコード及び／又は解読を可能にするデータを含む少なくとも１つの必要先行ユニットを得られるようにすることを特徴とする請求項１〜４のいずれかに記載の送信方法。
【請求項６】
検討されるストリームユニットのデータをデコード及び／又は解読して、デコードの後に表示する必要があるかどうかを端末が決定できるようにするデータを前記必要先行ユニットが含むことを特徴とする請求項５に記載の送信方法。
【請求項７】
前記ポインタの少なくとも１つが、前記端末が知り得るデータを指し示して、前記端末が対応するデータストリームを処理することができるかどうかを決定できるようにすることを特徴とする請求項１〜６のいずれかに記載の送信方法。
【請求項８】
前記ストリームユニットの少なくとも１つが、前記データストリーム又は続いて受信される別のデータストリームの少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする請求項１〜７のいずれかに記載の送信方法。
【請求項９】
後に受信されうる前記ストリームユニットが、前記ポインタとリンクするためのマーカを有することを特徴とする請求項８に記載の送信方法。
【請求項１０】
異なる時間に送信される少なくとも２つの同様なストリームユニットに含まれるポインタが、後に受信されうる同じストリームユニットを指し示すことを特徴とする請求項８又は９に記載の送信方法。
【請求項１１】
検討されるストリームユニットを考慮できるようにするために、デコードする必要がある少なくとも１つの先行するストリームユニットを指し示すことと、
検討されるストリームユニットをデコード及び／又は解読するために必要なデータを含む少なくとも１つの先行するストリームユニットを指し示し、及び／又は保護システムのステータスへの参照を指し示すことと、
少なくとも１つの後続するストリームユニットを指し示すことと
を含むグループに属する２つの役割の中からのポインタの役割を指定するインディケータを実現することを特徴とする請求項１〜１０のいずれかに記載の送信方法。
【請求項１２】
前記ストリームユニットの少なくとも幾つかが、前記役割を定義する従属記述子を含むことを特徴とする請求項１１に記載の送信方法。
【請求項１３】
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットとして自己を識別することができるようにする従属マーカを含むことを特徴とする請求項１〜１２のいずれかに記載の送信方法。
【請求項１４】
前記ストリームユニットの少なくとも幾つかが、前記ストリームの中に前記ストリームユニットの識別マーカを含むことを特徴とする請求項１〜１３のいずれかに記載の送信方法。
【請求項１５】
受信されたストリームユニットの先行する処理を必要としないような同期レベルで実行されることを特徴とする請求項１〜１４のいずれかに記載の送信方法。
【請求項１６】
請求項１から１５のいずれかの送信方法に基づいて送信されたデータストリーム。
【請求項１７】
少なくとも１つの端末に送信され及び／又は少なくとも１つの端末から受信され、また一方から他方へ別個に送信されるストリームユニットに編成されたデータストリームであって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は先に前記端末により受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことにより、前記ストリームユニットの処理は、前記必要先行ユニットが受信されていない場合は前記端末では実行されないことを特徴とするデータストリーム。
【請求項１８】
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は先行して端末で受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする互いに独立して送信されたストリームユニットに編成された少なくとも１つのデータストリームの形式で、少なくとも１つの端末に送信されるように作成されたデータ用のサーバ。
【請求項１９】
互いに独立して送信されたストリームユニットに編成された少なくとも１つのデータストリームを受信できる端末であって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする端末。
【請求項２０】
ストリームユニットに編成され、互いに独立して送信された少なくとも１つのデータストリームの受信方法であって、
前記ストリームユニットの少なくとも幾つかが、必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示す少なくとも１つのポインタを含むことを特徴とする受信方法。
【請求項２１】
前記ポインタの少なくとも１つが必要先行ユニットと呼ばれる、前記データストリーム中又は端末により先に受信されている別のデータストリーム中の少なくとも１つのストリームユニットを指し示し、次のステップ、すなわち、
ストリームユニットの前記ポインタを分析するステップと、
前記必要先行ユニットが受信されている場合は、前記ストリームユニットを処理するステップと
を含むことを特徴とする請求項２０に記載の受信方法。
【請求項２２】
ユーザが選択したプログラムにアクセスする前に、メッセージをシステマチックに同報通信することと、
条件に基づいてプログラムの特定の品質レベル及び／又は特定のオプションにアクセスをすることと、
対話型のテレビと
を含むグループに属するアプリケーションの１つとして行う請求項１から１５のいずれかに記載の送信方法の使用。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１０−１８７３８１（Ｐ２０１０−１８７３８１Ａ）
【公開日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願番号】特願２０１０−４４３２５（Ｐ２０１０−４４３２５）
【出願日】平成２２年３月１日（２０１０．３．１）
【分割の表示】特願２００３−５７５６３４（Ｐ２００３−５７５６３４）の分割
【原出願日】平成１５年３月７日（２００３．３．７）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
【公開日】平成２２年８月２６日（２０１０．８．２６）
【国際特許分類】
【出願日】平成２２年３月１日（２０１０．３．１）
【分割の表示】特願２００３−５７５６３４（Ｐ２００３−５７５６３４）の分割
【原出願日】平成１５年３月７日（２００３．３．７）
【出願人】（５９１０３４１５４）フランス・テレコム (290)
【Ｆターム（参考）】
[ Back to top ]