JP2018524877A - カプセル化されたビットストリームからメディアデータ及びメタデータを取得するための、動作基点ディスクリプタを動的に設置可能な方法、デバイス及びコンピュータプログラム - Google Patents

Abstract

本発明は、ビットストリームのカプセル化から生じるカプセル化ビットストリームからメディアデータ及びメタデータを取得する方法に関し、ビットストリームの各々のメディアデータはレイヤに編成され、各レイヤはタイムドサンプル又はサブサンプルを備える。メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためにデータ構造体が取得される。各ビットストリームに対して少なくとも１つの動作基点ディスクリプタが取得され、少なくとも１つの動作基点ディスクリプタは、データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルを独立して復号可能とする記述的情報に関するメタデータを提供する。タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタは、グループに属するタイムドサンプルの記述的情報を定義する。
【選択図】 図７

Description

本発明は、概略として、特に、圧縮ビデオストリームにおいて対象となるユーザ選択領域のＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）及びＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）ストリーミングに関して、メディアデータの交換、管理、編集及び表示を容易化する柔軟かつ拡張可能なフォーマットを提供し、ストリーム配信を改善する、ＭＰＥＧ標準化機構によって規定されたベースメディアファイルフォーマットなどによるタイムドメディアデータのカプセル化の分野に関する。より具体的には、本発明は、カプセル化されたビットストリームからメディアデータ及びメタデータを取得するための、動作基点ディスクリプタを動的に設定可能な方法、デバイス及びコンピュータプログラムに関する。

ビデオコード化は、動画が送信又は記憶可能となる一連の動画を小さなデジタル化ビットストリームに変換する態様である。符号化デバイスは、ビットストリームを再構成して表示及び視聴するのに利用可能な関連の符号化デバイスとともに、動画をコード化するのに使用される。一般的な目的は、元のビデオ情報よりも小さなサイズとなるようにビットストリームを形成することである。これによって、有利なことに、ビットストリームコードを送信又は記憶するのに転送ネットワーク又は記憶デバイスで必要となる容量が減少する。送信されるために、ビデオビットストリームは一般に、通常はヘッダ及びチェックビットを付加する送信プロトコルに従ってカプセル化される。ビデオストリームメカニズムは、インターネットネットワーク及びモバイルネットワーク上で広範に配備及び使用されて、例えば、３ＧＰＰのアダプティブＨＴTＰストリーミング（ＡＨＳ）、マイクロソフトのスムースストリーミング又はアップルのＨＴＴＰライブストリーミングなどのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を介したオーディオ／ビデオメディアをストリーム配信する。

最近では、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）が、ＨＴＴＰを介した既存のストリーミング手段を統一して代替する新たな標準を公表した。この新たな標準を「Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）」といい、知能（すなわち、ストリーミングするメディアデータの選択並びにユーザの選択、ネットワーク条件及びクライアントの能力に対するビットストリームの動的な適応）が専らクライアントの選択及びデバイスに依拠する標準ウェブサーバに基づくＨＴＴＰを介したメディアストリーミングモデルに対応するものである。

このモデルでは、メディアの表示は、データセグメントにおいて、及び表示されるタイムドメディアデータの編成を表す「Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）」といわれるマニフェストにおいて編成される。特に、マニフェストは、ダウンロードデータセグメントについて使用されるリソース識別子を備え、有効なメディア表示を得るようにそれらのデータセグメントを選択及び合成するコンテキストを提供する。リソース識別子は、通常はＨＴＴＰ−ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）であり、おそらくはバイト範囲と組み合わせられる。マニフェストに基づいて、クライアントデバイスは、どのメディアセグメントがメディアデータサーバからダウンロードされるべきかを、その必要性、その能力（例えば、対応しているコーデック、表示サイズ、フレームレート、品質レベルなど）に従って、そしてネットワーク条件（例えば、利用可能な帯域幅）に応じて随時判定する。

なお、ＨＴＴＰに対する代替プロトコル、例えば、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）も存在する。

さらに、映像解像度も増加し続けており、標準精細（ＳＤ）から高精細（ＨＤ）まで、そして超高精細（例えば、４Ｋ２Ｋ又は８Ｋ４Ｋ、すなわち、４０９６×２４００画素又は７６８０×４３２０画素の画像からなる映像）まで進んでいる。しかし、特に、映像が超高精細のものであって全てのユーザがそのような映像を利用する必要があるわけではない場合、全ての受信及びビデオ復号デバイスが、最大解像度で映像にアクセスするリソース（例えば、ネットワークアクセス帯域幅又はＣＰＵ（中央処理装置））を有しているわけではない。そのような背景では、ビデオビットストリームの一部分のみをアクセスして抽出する能力を与えること、すなわち、例えば、あるスケーラビリティレイヤ、ビューワ、又は全ビデオシーケンスの空間的一部分のみにアクセスすることが特に有利となる。

映像に属するスケーラビリティレイヤ、ビュー、又は映像に属するフレームの空間的一部分にアクセスする既知のメカニズムは、ビデオの各フレームを、おそらくはコード化依存性とともにレイヤの構成として編成することに帰着する。ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）などのビデオフォーマットによっては、マルチビュー及び／又はタイル符号化に対して、時間的ＳＮＲ（品質）及び空間スケーラビリティレイヤへのサポートを提供する。例えば、ユーザ定義ＲＯＩは、１又は幾つかの隣接タイルをカバーし得る。マルチビューの場合、ユーザは、シングルビューよりもステレオを好み得る。スケーラビリティの場合、適切なレイヤが、例えばスクリーンサイズ又は処理電力の観点でユーザのデバイスに依存して選択可能となる。

ビデオビットストリームの関連部分（すなわち、サブビットストリーム）のみの選択、抽出及び送信を可能とするために、ビデオビットストリームの編成（より一般的には、ビデオだけでなく、オーディオ、メタデータ、サブタイトルなどを備え得るメディアデータの編成）がメディアレイヤに公開されなくてはならない。この編成は、動作点のリストとして表現される。

動作点は、動作基点ともいわれ、レイヤードＨＥＶＣビットストリームの一部分すなわちビットストリームサブセットであって、この特定のビットストリームサブセットを復号するのに必要とされる全てのデータからなるビットストリーム部分を抽出することによって取得可能であり、他の動作点とは無関係に復号可能なものを表す。結果として、動作点は、ゼロ以上かつ選択される最大値以下で変動する値の範囲の時間識別子に対応付けられた出力レイヤのセットとなる。説明の目的のため、３０Ｈｚ及び６０Ｈｚのフレームレートに対応する２つの時間識別子の値（０及び１）を図５ａ及び５ｂに示す。

図５ａ及び５ｂからなる図５は、非出力レイヤを伴うレイヤ構成の例を示す。
より正確には、図５ａは、ビデオシーケンスの幾つかの表示の間の関係の例を示す。これらの表示は、異なる時間解像度（すなわち、３０Ｈｚ及び６０Ｈｚのフレームレート）を有する表示からなり、時間解像度の各々について、表示は異なるビュー（すなわち、左（ｌｅｆｔ）、右（ｒｉｇｈｔ）及び共通（ｃｏｍｍｏｎ））からなる。

図示するように、共通ビューは、左右のビューから直接導出可能であり、３０Ｈｚのフレームレートの共通ビューは６０Ｈｚのフレームレートの共通ビューから直接導出可能である。
表示はまた、時間解像度の各々に応じてフルビューのスケーラブルでない表示を備える。

図５ｂに示すように、図５ａに示す表示は、３個の可能なビュー（すなわち、左、右及び共通）に対応する３層のレイヤに従って、及び２つのフレームレート（すなわち、３０Ｈｚ及び６０Ｈｚ）に従って符号化可能である。

したがって、ＨＴＴＰプロトコルに従うストリーミングビデオシーケンス又はユーザ選択データについて、選択データへのアクセスを可能とする態様での符号化ビデオビットストリームのタイムドメディアデータのカプセル化、並びにユーザ選択データの再構成、復号及び表示を可能とする最小量のデータを送信するそれらのコード化依存性を提供することが重要である。
適応ＨＴＴＰストリーミングの典型的使用は、ビットストリームスプライシングである。

図６は図６ａ、６ｂ及び６ｃからなり、ビットストリームスプライシングのアプリケーションの例を示す。

図６ａに示すように、ビットストリームスプライシングは、低解像度ビットストリーム（ＳＤ）から高解像度ビットストリーム（ＨＤ）への切換で起こり得る。図６ｂに示す他の例によると、ビットストリームスプライシングは、ライブビットストリーム（ｌｉｖｅ）から再生のためのオンデマンドビットストリーム（ｒｅｐｌａｙ）への切換で起こり得る。

そのような場合では、スプライスされたビットストリーム６０３は、それぞれの初期化セグメント（すなわち、国際標準化機構ベースメディアファイルフォーマットによるカプセル化される場合の「ｍｏｏｖ」及び「ｔｒａｋ」ボックス）に記載される編成を有する６０１及び６０２で示す２つの交互のビットストリームの組合せから生じる。

それによって２つのストリーム６０１及び６０２が異なる動作点を有する場合、スプライスされたビットストリーム６０３は、２つの異なる動作点リストの連結を含むべきである。これは、例えば、スプライスされたＨＥＶＣビットストリームを異なるＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）とともに記憶する場合に起こり得る。

一方で、Ｌ−ＨＥＶＣの現行のカプセル化フォーマットによると、２つの異なる動作点リストの連結をスプライスされたビットストリームに動的に関連付けることはできない。同様の制限が、時間とともに変化するレイヤ編成、スケーラビリティタイプ又はプロファイル、ティア又はレベル（実際には動作点の記述における任意のパラメータ）を有するビデオビットストリームで存在し、記述的メタデータ（例えば「ｔｒａｋ」ファイルフォーマットボックスの階層）は動的には更新できない。

例えば、長期断片化ＭＰ４ファイルをレイヤ構成の変更とともにストリーミングする場合にそのような問題に直面する。そのような場合、コンテンツ生成器が、２つのクラスのデバイス（例えば、ＳＤ、ＨＤ）に対して２つのスケーラブルなレイヤを定義する。ある期間後に、新たなクラスのデバイス（例えば、ＵＨＤ）が利用可能となった場合、２つのトラックを再利用し、追加のレイヤを付加することを可能とすべきである。動画断片が使用される構成では、断片を除去する動作は、情報の喪失をもたらすべきではない。ストリーミング中にレイヤ構成が変化する場合、これが捕捉されるべきである。

他の例が、同じプロファイル制約に従うファイルの連結に向けられる。そのような連結は、異なる戦略に従うことになる：
−両ファイルからのベースレイヤを含むトラックにおけるサンプルが単に連結され、異なるサンプル入力において、又はより大きなｈｖｃＣ ＮＡＬＵアレイにおいて、複数のＶＰＳ／ＳＰＳ／ＰＰＳをもたらし得る、
−非ベースレイヤからのサンプルが、トラックを１つずつ検査し、もしあれば、同様の制約でレイヤに対応するトラックからのサンプルにそれらを連結することによって連結され得る、
−第２のファイルの非ベースレイヤのトラックからのサンプルが、新たなセットのトラックに付加され、連結されるベーストラックとの同期を保持するように時間的にシフトされ得る。後者の手法は複雑であり、好適でないことがある。そのようなシナリオにおいて、トラックレイヤ構成の変化を可能とすることが有用となり得る。

これらの制限は、動作点についての現行のディスクリプタがｍｐ４ファイル全体に対して単一のインスタンスとして宣言されることから生じる。

符号化ビデオビットストリームが、完全なフレームに対応する連続する時間的サンプルのセットとして一般に構成されるＮＡＬ（ネットワーク抽象化レイヤ）ユニットに編成され、時間的サンプルが復号順序の関数として編成されていることを思い出すべきである。ファイルフォーマットは、そのような符号化ビットストリームをカプセル化及び記述するのに使用される。

説明の目的のため、国際標準化機構ベースメディアファイルフォーマット（ＩＳＯ ＢＭＦＦ）は、ネットワークを介して又は他のビットストリーム配信メカニズムを介したローカルな記憶又は伝送のために符号化タイムドメディアデータビットストリームを記述する公知の柔軟かつ拡張可能なフォーマットであるものとする。このファイルフォーマットは、オブジェクト指向である。これは、順次又は階層的に編成され、タイミング及び構造パラメータなどの符号化タイムドメディアデータビットストリームのパラメータを定義するボックスというブロックを構築することで構成される。このファイルフォーマットによって、タイムドメディアデータビットストリームは、ｔｒａｃｋ ｂｏｘという他のデータ構造で定義されるｍｄａｔ ｂｏｘというデータ構造体に含まれる。トラックは、単一のタイムスタンプに対応付けられた全てのデータ、すなわち、単一のフレームに対応付けられた全てのデータ又は同じタイムスタンプを共有する幾つかのフレームに対応付けられた全てのデータにサンプルが対応する場合のタイムドシーケンスのサンプルを表す。

マルチレイヤＨＥＶＣフォーマットの映像のようなスケーラブルな映像について、レイヤ化されたメディアデータ編成は、各々のトラックが特定レベルのスケーラビリティで映像を表す、複数の従属トラックを用いることによって効果的に表され得る。トラック間でのデータの重複を回避するため、エクストラクタが使用されてもよい。標準的ファイルフォーマットによると、エクストラクタは、他のビットストリームからの他のネットワーク抽象化レイヤ（ＮＡＬ）ユニットの効率的な抽出を可能とするビットストリームに直接含まれる特定種のネットワーク抽象化レイヤ（ＮＡＬ）データ構造体である。例えば、エンハンスメントレイヤトラックのビットストリームは、ベースレイヤトラックからＮＡＬユニットを参照するエクストラクタを備えていてもよい。その後、そのようなエンハンスメントレイヤトラックがファイルフォーマットから抽出されると、エクストラクタは、それらが参照しているデータによって置換されなければならない。

サブ情報を記述し、このサブ情報へのアクセスを容易化し、又はビットストリームを効率的に複数のセグメントに編成するこれらのメカニズムを組み込んだＩＳＯ ＢＭＦＦを用いる場合に、幾つかの戦略が採用され得る。

例えば、表題「Ｉｍｐｌｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ ｏｎ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ ｏｆ Ｈ．２６４／ＳＶＣ」、Ｋｏｆｌｅｒ他著の記事は、ＩＳＯ ＢＭＦＦの可能性と制限を考慮するＨＴＴＰストリーミングについてのスケーラブルなビデオビットストリーム（Ｈ２６４／ＳＶＣ）を編成するための３つの異なる戦略を示す。

ａ）（トラックの定義を含む）全てのＩＳＯ ＢＭＦＦメタデータを含むファイルタイプボックス「ｆｔｙｐ」及び動画ボックス「ｍｏｏｖ」を備える特定のファイルヘッダを含む単一のファイルであって、単一のファイルは全符号化ビットストリームを含む単一のｍｄａｔボックスも備える。この編成は、ローカルストレージには適するが、クライアントが全ビットストリームの一部のみを必要とするＨＴＴＰストリーミングには適合されない。そのような編成は、好ましくは、ビットストリームが複数のセグメントに断片化される場合に初期化ファイルとして使用されるファイルに使用される。この初期化ファイルには、編成がｂ）において規定される他の単一のファイルが続き、この初期化ファイルは全てのセグメントについての情報を収集する。

ｂ）断片化に適した複数のｍｏｏｆ／ｍｄａｔボックスを含む単一のファイルであって、ｍｏｏｆ／ｍｄａｔの各対がビットストリームの複数のセグメントの１つに対する。このフォーマットによってプログレッシブダウンロードが可能となる。より詳細には、ｍｏｏｆボックスは、断片レベルにおいてｍｏｏｖボックスと等価である。この手法によると、断片化メディアファイルを用いて、スケーラブルなビットストリームが、異なるスケーラビリティレベルで映像を表す複数の従属トラックに分割可能となる。エクストラクタは、他のトラックからＮＡＬユニットを参照するのに使用される特定のＮＡＬユニットである。タイル毎のトラックが使用される場合、全てのアドレス指定可能なトラックが予め準備されなければならず、トラックは独立して選択されることはできない。幾つかのタイルが表示されるべき場合、幾つかのビットストリームが復号されなければならず、ベースレイヤは何回か復号される。ｃ）において記載される最後の編成は、独立して選択された各トラックに特に適する。

ｃ）複数のセグメントファイルであって、各ファイルがそれ自体のＵＲＬによってアクセス可能であり、独立してダウンロード可能である。各ファイルは１つの断片に関係し、複数のセグメントファイルは好ましくは専用初期化ファイルに先行される。各セグメントは通常、ファイルヘッダの一種として作用するセグメントタイプボックス（ｓｔｙｐ）、選択的セグメントインデックスボックス（ｓｉｄｘ）及び１又は複数の断片からなる。ここでも各断片は、ｍｏｏｆ及びｍｄａｔボックスからなる。この手法によると、断片化されたメディアファイルを用いて、各トラックが、あるレベルのスケーラビリティに関係する対応のビットストリームとともにそれ自体のセグメントに格納される。必要であれば、必要なビットストリームを従属トラックから参照するのにエクストラクタが使用される。そのようなコード化手法は、独立してトラックをストリーミングするのに特に適する。これはＤＡＳＨ標準に正しく適合されるが、幾つかのビットストリームが復号されることによってトラック毎に１つのデコーダが必要となるので、タイルストリーミングには適さない。さらに、２以上のタイルを選択する場合には、ベースレイヤのビットストリームが潜在的に重複する。

上記ボックスの定義、及び「Ｄｒａｆｔ ｔｅｘｔ ｏｆ ＩＳＯ／ＩＥＣ ＤＩＳ １４４９６−１５ 第４版、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１、ＷＧ１５１８２、２０１５年４月、スイス、ジェノバ」（以下「ｗ１５１８２」という）として知られる文書を参照して構成されるそれらのボックスに含まれるサブボックスの定義は、ＩＳＯ ＢＭＦＦメタデータの複雑かつ非効率な編成をもたらすことになる。

さらに、タイルトラックは、ＬａｙｅｒｅｄＨＥＶＣに対して適切に定義されておらず、その使用を制限する。

これらの問題を解決するために、そして特に、動作点についてディスクリプタを動的に設定することを可能とするために、マルチレイヤビデオストリームについてのＬａｙｅｒｅｄＨＥＶＣにおいて空間タイル、スケーラブルレイヤ及びマルチビューを取り扱うのに特に適した効率的データ編成及びトラック記述手法が提供される。

これらの制約に直面して、発明者は、サーバにおけるマルチレイヤのタイル化されたタイムドメディアデータをカプセル化するための、及び複数のメディアセグメントファイルにおいてカプセル化されたマルチレイヤタイル化タイムドメディアデータからタイムドメディアデータビットストリームを供給するための方法及びデバイスを提供する。
本発明の広い意味での課題は、上述の従来技術の欠点を改善することである。

本発明の第１の観点によると、１以上のビットストリームのカプセル化から生じるカプセル化されたビットストリームからメディアデータ及びメタデータを取得する方法であって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記方法が、
前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を取得するステップ、及び
前記１以上のビットストリームの各々に対して少なくとも１つの動作基点ディスクリプタを取得するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップを備える方法が提供される。

したがって、本発明の方法は、特に標準化機構のベースメディアファイルフォーマットに従ってメディアデータを送信する場合に、動作基点ディスクリプタを動的に設定することにより、サーバとクライアントデバイスの間で伝送されるデータ量を最適化することを可能とする。

一実施形態では、前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている。

一実施形態では、前記カプセル化ビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて受信される前記少なくとも１つの動作基点ディスクリプタを備える。

一実施形態では、前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する。

一実施形態では、前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる。

一実施形態では、前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである。

一実施形態では、前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える。

一実施形態では、少なくとも１つのレイヤディスクリプタを取得するステップをさらに備え、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する。

一実施形態では、デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される。

一実施形態では、デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される。

一実施形態では、メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである。

一実施形態では、前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される。

本発明の第２の観点によると、１以上のビットストリームのカプセル化のためにカプセル化されるビットストリームにメディアデータ及びメタデータを提供する方法であって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記方法が、
前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を提供するステップ、及び
前記１以上のビットストリームの各々に対する少なくとも１つの動作基点ディスクリプタを提供するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップを備える方法が提供される。

したがって、本発明の方法は、特に標準化機構のベースメディアファイルフォーマットに従ってメディアデータを送信する場合に、動作基点ディスクリプタを動的に設定することにより、サーバとクライアントデバイスの間で伝送されるデータ量を最適化することを可能とする。

一実施形態では、前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている。

一実施形態では、前記カプセル化されるビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて送信される前記少なくとも１つの動作基点ディスクリプタを備える。

一実施形態では、前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する。

一実施形態では、前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる。

一実施形態では、前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである。

一実施形態では、前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える。

一実施形態では、前記方法が、少なくとも１つのレイヤディスクリプタを提供するステップをさらに備え、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する。

一実施形態では、デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される。

一実施形態では、デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される。

一実施形態では、メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである。

一実施形態では、前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される。

本発明の第３の観点によると、１以上のビットストリームのカプセル化から生じるカプセル化されたビットストリームからメディアデータ及びメタデータを取得するデバイスであって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記デバイスが、
前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を取得するステップ、及び
前記１以上のビットストリームの各々に対して少なくとも１つの動作基点ディスクリプタを取得するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップを実行するために構成されたプロセッサを備える、デバイスが提供される。

したがって、本発明のデバイスは、特に標準化機構のベースメディアファイルフォーマットに従ってメディアデータを送信する場合に、動作基点ディスクリプタを動的に設定することにより、サーバとクライアントデバイスの間で伝送されるデータ量を最適化することを可能とする。

一実施形態では、前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている。

一実施形態では、前記カプセル化ビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて受信される前記少なくとも１つの動作基点ディスクリプタを備える。

一実施形態では、前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する。

一実施形態では、前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる。

一実施形態では、前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである。

一実施形態では、前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える。

一実施形態では、前記プロセッサがさらに、少なくとも１つのレイヤディスクリプタを取得するステップを実行するように構成され、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する。

一実施形態では、デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される。

一実施形態では、デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される。

一実施形態では、メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである。

一実施形態では、前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される。

本発明の第４の観点によると、１以上のビットストリームのカプセル化のためにカプセル化されるビットストリームにメディアデータ及びメタデータを提供するデバイスであって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記デバイスが、
前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を提供するステップ、及び
前記１以上のビットストリームの各々に対する少なくとも１つの動作基点ディスクリプタを提供するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップを実行するために構成されたプロセッサ備えるデバイスが提供される。

したがって、本発明のデバイスは、特に標準化機構のベースメディアファイルフォーマットに従ってメディアデータを送信する場合に、動作基点ディスクリプタを動的に設定することにより、サーバとクライアントデバイスの間で伝送されるデータ量を最適化することを可能とする。

一実施形態では、前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている。

一実施形態では、前記カプセル化されるビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて送信される前記少なくとも１つの動作基点ディスクリプタを備える。

一実施形態では、前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する。

一実施形態では、前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる。

一実施形態では、前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである。

一実施形態では、前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える。

一実施形態では、前記プロセッサがさらに、少なくとも１つのレイヤディスクリプタを提供するステップを実行するように構成され、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する。

一実施形態では、デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される。

一実施形態では、デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される。

一実施形態では、メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである。

一実施形態では、前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される。

本発明はソフトウェアで実施され得るので、本発明はプログラム可能な装置への任意の適切な搬送媒体上での提供のためのコンピュータ可読コードとして具現され得る。有体搬送媒体は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードディスクドライブ、磁気テープデバイス又は固体メモリデバイスなどの記憶媒体からなり得る。一時的搬送媒体は、電気信号、電子信号、光信号、音響信号、磁気信号又は電磁信号、例えば、マイクロ波又はＲＦ信号などの信号を含み得る。

本発明の更なる効果が、図面及び詳細な説明を検討した当業者には明らかとなる。何らかの追加の効果がここに含まれることが意図されている。

ここで本発明の実施形態を、例示としてのみ、そして以下の図面を参照して説明する。

ＭＰＥＧ−４ファイルフォーマットによる２層のスケーラビリティレイヤをカプセル化する例を示す図である。 タイル化Ｌａｙｅｒｅｄ−ＨＥＶＣについての本発明によるトラックボックスを表示する実施形態を示す図である。 １以上の実施形態が実施され得るサーバ又はクライアントデバイスのブロック図である。 代替のトラック及びタイルトラック依存性シグナリングの例を示す図である。 非出力レイヤを伴うレイヤ構成の例を示す図である。 ビットストリームスプライシングのアプリケーションの例を示す図である。 本発明の実施形態による動作基点に対する特定のかつ動的に拡張可能なディスクリプタを示す図である。 標準動作基点ディスクリプタを示す図である。 レイヤ情報記述のための特定のかつ動的に拡張可能なディスクリプタを示す図である。 本発明によってカプセル化されたメディアファイルに対するクライアント端での処理を示すフローチャートである。 本発明による新たなデコーダ構成情報を示す図である。 本発明によるビデオビットストリームカプセル化のためのサーバ端での処理を示すフローチャートである。

以下の３章は、３つの異なる構成、それぞれ、ピクチャの空間編成、ＮＡＬユニット、及びＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙという特定のディスクリプタについての公知の情報を説明するものである。これらの構成を、図１から図３で表される実施形態のより深い理解のためにここに説明する。

＜ピクチャの空間編成＞
映像は好ましくはスケーラブル又はマルチビューの映像であり、様々なレベルのスケーラビリティ／ビューにおいて編成される。

特定の実施形態によると、タイムドサンプル（例えば、画像）を備えるマルチレイヤタイル化タイムドメディアデータ（例えば、スケーラブル又はマルチビューのタイル化ビデオデータ）などのマルチレイヤ区画のタイムドメディアデータは、幾つかのタイムドメディアデータトラックのセット、通常はベーストラック及びタイルトラックとして伝送される。さらに特定の実施形態によると、ベーストラックは、ベースレイヤベーストラック及び少なくとも１つのエンハンスメントレイヤベーストラックを備える。追加のタイルトラックは、ベースレイヤタイルトラック及び／又はエンハンスメントレイヤタイルトラックとなり得る。各タイムドメディアデータトラックは、幾つかのタイムドサンプルの１つの空間サブサンプル（例えば、幾つかのＮＡＬユニット）を備える。各ビデオフレーム（タイムドサンプル）は、ビデオフレームの空間小部分（空間サブサンプル）に対応する独立して復号可能なタイルで構成され得る。ＬａｙｅｒｅｄＨＥＶＣでは、各ビデオフレームは、ビデオフレームの空間小部分（空間サブサンプル）に対応する従属的に復号可能なレイヤで構成され得る。さらに、ＬａｙｅｒｅｄＨＥＶＣでは、各ビデオフレームは従属的に復号可能なレイヤで構成されていてもよく、各レイヤはビデオフレームの空間小部分（空間サブサンプル）に対応する（所与のレイヤに対して）独立して復号可能なタイルで構成されていてもよい。

トラック依存性（タイル化、レイヤ間及び／又はレイヤ内レイヤ依存性）を記述するのにリストが使用される。そのようなタイムドメディアデータトラックのセットによって、マルチレイヤ空間ビデオタイルの選択、構成及び効率的なストリーミングが可能となる。各トラックは、サーバデバイスからクライアントデバイスにメディアセグメントファイルのセットとして送信され得る。初期化セグメントファイルは、メディアセグメントファイルを復号するのに必要なメタデータを送信するのに使用され得る。

本発明の実施形態は、例えば、ＨＥＶＣ又はＬａｙｅｒｅｄＨＥＶＣとして知られる（ＬＨＶＣ又はマルチレイヤＨＥＶＣとしても知られる）ビデオフォーマットに適用可能である。

ＨＥＶＣ標準によると、画像は、タイル、スライス及びスライスセグメントに空間的に分割され得ることを注記しておく。この標準では、タイルは、横及び縦の境界（すなわち、行及び列）によって画定される画像の矩形領域に対応する。それは、整数の符号化ツリーユニット（ＣＴＵ）を含む。したがって、タイルは、例えば、対象領域について位置及びサイズを定義することによって、対象領域を識別するのに効果的に使用され得る。ただし、ＨＥＶＣビットストリームの構造及びネットワーク抽象化レイヤ（ＮＡＬ）ユニットとしてのそのカプセル化は、タイルに関しては編成されずにスライスに基づく。

ＨＥＶＣ標準では、スライスはスライスセグメントのセットであり、スライスセグメントのセットの第１のスライスセグメントは独立したスライスセグメント、すなわち、ヘッダ内に格納された一般的情報が他のスライスセグメントのものを参照しないスライスセグメントである。スライスセグメントのセットの他のスライスセグメントは、もしあれば、従属スライスセグメント（すなわち、ヘッダ内に格納された一般的情報が独立したスライスセグメントのものを参照するスライスセグメント）となる。

スライスセグメントは、整数の（ラスター走査順で）連続する符号化ツリーユニットを含む。したがって、スライスセグメントは矩形のものであってもなくてもよく、そのため、対象領域を表すのに適さない。それは、スライスセグメントデータが続くスライスセグメントヘッダに対してＨＥＶＣビットストリームにおいて符号化される。独立及び従属スライスセグメントはそれらのヘッダによって異なり、従属スライスセグメントは独立スライスセグメントに依存するので、そのヘッダの情報量は独立スライスセグメントの１つよりも小さい。独立及び従属スライスセグメントの双方とも、タイルを定義するのに使用され、又はエントロピー復号同期点として使用される対応のビットストリームにおける入力点のリストを含む。

ＨＥＶＣ標準によると、スライスセグメントは、以下のようにまとめられることができる規則に従ってタイルにリンクされる（一方又は両方の条件が満たされなければならない）：
−スライスセグメントにおける全てのＣＴＵが、同じタイルに属する（すなわち、スライスセグメントは複数のタイルに属することはできない）、及び
−タイルにおける全てのＣＴＵが、同じスライスセグメントに属する（すなわち、タイルは、これらのスライスセグメントのみがそのタイルに属することを条件として、幾つかのスライスセグメントに分割され得る）。

＜ＮＡＬユニット＞
上述したように、タイルが対象領域のための適切なサポートとしてみなされる一方で、スライスセグメントは、通信ネットワークを介した搬送のためにＮＡＬユニットに実際に挿入されてアクセスユニット（すなわち、ファイルフォーマットレベルでのコード化ピクチャ又はサンプル）を形成するように統合されるエンティティである。

ＨＥＶＣ標準によると、ＮＡＬユニットのタイプが、以下のように定義される２バイトのＮＡＬユニットヘッダにおいて符号化されることを再度注記しておく：

スライスセグメントをコード化するのに使用されるＮＡＬユニットは、スライスセグメントアドレスシンタックス要素によるスライスセグメントにおける第１のＣＴＵのアドレスを示すスライスセグメントヘッダを備える。そのようなスライスセグメントヘッダは、以下のように定義され得る：

タイル化情報が、ＰＰＳ（ピクチャパラメータセット）ＮＡＬユニットにおいて提供される。そして、スライスセグメントとタイルの間の関係が、これらのパラメータから推定可能となる。

空間予測が（定義によって）タイル境界上でリセットされる一方で、参照フレームにおける異なるタイルからの時間独立変数をタイルが使用することを妨げるものはない。したがって、独立タイルを構築するために、予測ユニットに対する移動ベクトルが、有利なことに符号化中にタイル内部で制限されて、参照フレームにおいて共に配置されるタイルに残る。さらに、１つのタイルのみを復号する場合にエラードリフトが導入されないように、好ましくは、ループ内フィルタ（デブロッキング及びサンプル適応オフセット（ＳＡＯ）フィルタ）がタイル境界上で非活性化される。なお、そのようなループ内フィルタの制御は、ＨＥＶＣ標準において利用可能である。それは、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇとして知られるフラグとともにスライスセグメントヘッダにおいて設定される。このフラグをゼロに明示的に設定することによって、タイル境界における画素は、隣接タイルの境界上となる画素に依存し得なくなる。移動ベクトル及びループ内フィルタに関するこれらの２つの条件が満たされる場合、タイルは「独立して復号可能なタイル」又は「独立タイル」とみなされることができる。

＜ＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙという特定のディスクリプタ＞
ＭＰＥＧ−４ Ｐａｒｔ１２標準の既存のサンプルグループ化メカニズムが、タイルをカプセル化するのに使用可能である。したがって、特定のサンプルグループの記述が、特定種の標準ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙディスクリプタであるタイルディスクリプタとともに作成される。サンプルグループ化メカニズムは、トラックにおけるサンプルの区画を表すために使用される。それらは、２つのボックス：サンプルグループへのサンプルの割当てを記述するＳａｍｐｌｅＴｏＧｒｏｕｐボックス（「ｓｂｇｐ」）及び特定のサンプルグループ内のサンプルの共通プロパティを記述するＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス（「ｓｇｐｄ」）の使用によるものである。特定タイプのサンプルグループ化が、タイプフィールド（「ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ」）を介して１つのＳａｍｐｌｅＴｏＧｒｏｕｐボックス及び１つのＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスの組合せによって定義される。複数のサンプルグループ化の例（すなわち、ＳａｍｐｌｅＴｏＧｒｏｕｐ及びＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスの対）が、様々なグループ化参照に基づいて存在し得る。

サンプルのタイル化に関する特定のグループ化参照が用いられる。この特定のグループ化のタイプは「ｔｒｉｆ」といい、タイルのプロパティを記述し、標準的ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙから導出される。それは、ＴｉｌｅＲｅｇｉｏｎＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙともいい、以下のように定義される：

この特定のタイプのグループ入力によると、パラメータｇｒｏｕｐＩＤは、グループによって記述されるタイルに対する固有の識別子である。パラメータｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ及びｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔは、ベース領域の輝度サンプルにおいて、ＨＥＶＣフレームの左上画素に対する、タイルによって表される矩形領域の左上画素の横及び縦オフセットをそれぞれ設定するのに使用される。パラメータｒｅｇｉｏｎ＿ｗｉｄｔｈ及びｒｅｇｉｏｎ＿ｈｅｉｇｈｔは、ＨＥＶＣフレームの輝度サンプルにおいて、タイルによって表される矩形領域の幅及び高さをそれぞれ設定するのに使用される。

パラメータｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇは、独立タイルの定義を参照して上述したように、同じタイルに属するサンプルのみに関する復号依存性をタイルが備えることを指定する２ビットワードである。説明の目的のため、及びタイル編成を記述するためのＳＥＩメッセージ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）の標準的使用に言及するため、ｔｉｌｅ＿ｓｅｃｔｉｏｎ＿ｅｘａｃｔ＿ｍａｔｃｈ＿ｆｌａｇとして知られるフラグが、その意味が以下のように設定され得るｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇパラメータの値を設定するのに使用され得る。
−パラメータｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇが０に等しい場合、このタイルと、同じフレーム又は前フレームにおける他のタイルとの間のコード化依存性は、タイル設定レベルで記述されるか、又は未知である。
−パラメータｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇが１に等しい場合、このタイルと、任意の参照フレームにおける異なるｇｒｏｕｐＩＤの他のタイルとの間の時間的なコード化依存性はないが、このタイルと参照フレームにおける同じｇｒｏｕｐＩＤのタイルとの間のコード化依存性はあり得る。
−パラメータｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇが２に等しい場合、このタイルと、同じフレームにおける他の任意のタイルとの間のコード化依存性はなく、このタイルと、参照フレームにおける任意の他のタイルとのコード化依存性もない。
ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇ値３は予約されている。

ｆｕｌｌ＿ｐｉｃｔｕｒｅパラメータは、１に設定される場合、このタイル領域が実際に完全なピクチャであることを示す。そのような場合、ｒｅｇｉｏｎ＿ｗｉｄｔｈ及びｒｅｇｉｏｎ＿ｈｅｉｇｈｔはレイヤ輝度サイズに設定されるべきであり、ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇは１に設定されるべきである。

パラメータｆｉｌｔｅｒｉｎｇ＿ｄｉｓａｂｌｅは、１に設定される場合、このタイル領域に隣接する画素へのアクセスを必要とする、このタイル領域への後段復号フィルタリング動作がないこと、すなわち、タイル領域のビット抽出再構成は隣接タイルを復号することなく可能であることを示す。

各タイルのプロパティが、各タイルトラックについて「ｔｒｉｆ」ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及びＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙで１つのＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス（「ｓｇｐｄ」）を定義することによって、動画ヘッダ（「ｍｏｏｖ」ボックス）において一度与えられる。タイルプロパティはまた、トラック断片毎に定義され得る。そのようなｍｐ４トラックは、ビデオタイルトラック又はタイルトラックとして定義され得る。ＨＥＶＣ標準によると、ＨＥＶＣタイルトラックは、このトラックにおけるタイルが属するＨＥＶＣレイヤの他のＮＡＬＵ（通常は、種々のパラメータセットなどのセットアップ情報）を搬送するＨＥＶＣトラックに対する参照があるようなビデオタイルトラックである。参照は、タイルベーストラックを示す「ｓｂａｓ」４文字コードなどのＭＰＥＧ−４ Ｐａｒｔ１５標準又は「ｔｂａｓ」などのより特化したものにおいて既に定義された値を使用することができる。

１つのタイルトラックは、１つかつ唯一の（図８ａに示す）ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを有し、かつＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙを有さないか、又は１つかつ唯一のＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙ及びこのタイルセットが作成された１以上の従属ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを有すべきであり、ＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙはタイルのセットを記述するＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙの拡張である。なお、これらのグループの各々は、ＮＡＬＵをグループに関連付けるのに使用され得る固有識別子に割り当てられる。タイル領域及びタイルセットは、「ｔｂａｓ」トラック参照として示すように、ベースＨＥＶＣレイヤによって範囲付けられるｇｒｏｕｐＩＤに対する同じネームスペースを共有する（すなわち、同じベースレイヤを有するいずれのトラックにおいても同じｇｒｏｕｐＩＤの２つのタイル領域又はタイルセットがあってはならない）。

新たな種類のトラック、ここではタイルトラックを導入することは、ファイルフォーマット設計に準拠するために対応のサンプル入力を定義することを意味する。もちろん、各トラックは、その記述的データの中に、強制的ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘ（「ｓｔｓｄ」）とともにＳａｍｐｌｅＴａｂｌｅＢｏｘ（「ｓｔｂｌ」）を含まなければならない。サンプル記述テーブルは、使用されるコード化タイプについての詳細な情報及びトラックサンプルの復号のための初期化情報を与える。ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘに格納された情報はトラック固有であり、任意のビジュアルサンプル入力に対する抽象記述を特殊化することによってビデオトラックに対して記述される。通常は、任意のビジュアルサンプル入力は、サンプルを取り扱うのに使用する圧縮フォーマットデコーダを提供する「コード化名」パラメータを含む。このパラメータは、４文字コードとして符号化された固有識別子でなければならない。タイルトラックに挿入されるサンプルを記述するためには、これらのサンプルを特定種のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙで記述しなければならない。ＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが導入され、例えばコード「ｈｖｔ１」によって表現されて、タイル能力を有するＨＥＶＣデコーダがタイルトラックのサンプルを処理する必要があることを示す。通常、サンプル記述テーブルにおいて、デコーダ構成情報を提供するのにＣｏｎｇｉｒｕｇａｔｉｏｎＢｏｘがパラメータとして含まれる。特定の場合のＨＥＶＣタイルトラックについて、我々は、構成ボックスを複製しないが、トラックヘッダにおいてトラック参照タイプ「ｔｂａｓ」において示されるタイルベーストラックにおいて記述されるものを受け継ぐ。選択的に、タイル毎の平均ビットレートを記述するパラメータは、ＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙ並びにプロファイル、ティア及びレベル情報において設定され得る。プロファイルは、通常はアプリケーション領域をターゲットとする構成に関して標準のサブセットを定義する。各プロファイルは、ティア及びレベルを定義する。ティアは、複雑化のレベルでネストされて見ることができ、各レベルは画素数、スライス数、タイルなどのある値に対する制限を定義する。増加する複雑さに編成されると、プロファイルにおける所与のレベルで最高のティアを扱うことができるデコーダは、同じプロファイルにおいて同等以下のレベルで、より低い任意のティアに対応することができる。このボックスにプリタイルビットレート情報を、帯域幅に基づく適応のためにストリーミングするクライアントに提供されるように格納するのが有用となり得る。ｍｐ４ボックスのほとんどについて、ＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙボックスは、アプリケーション固有のニーズに見合うように、選択的な追加のボックスで拡張され得る。

図１は、ＭＰＥＧ−４ファイルフォーマットに従って２層のスケーラビリティレイヤをカプセル化する例を示す。図示するように、各レイヤ（エンハンスメントレイヤＥＬ及びベースレイヤＢＬ）がそれ自体のトラックにおいてカプセル化され、効率的なデータアドレス化を可能とし、映像を２つのトラックとしてカプセル化することになる。
より正確には、図１は、マルチレイヤＨＥＶＣビットストリームに符号化されたメディアデータシーケンスに対する全てのＩＳＯ ＢＭＦＦメタデータを含み、Ｓサンプルを含む動画ボックス「ｍｏｏｖ」１００を表す。同じ原理が、動画断片とともに又は上述のｂ）及びｃ）で定義されたセグメントとしてカプセル化されたメディアデータに当てはまる。

単一の「ｍｄａｔ」ボックス１０１は、２つのチャンクに編成された全ての符号化ビットストリームを含み、一方がベースレイヤ１０２に対して、一方がエンハンスメントレイヤ１０３に対して編成され、各チャンクがＳサンプル１０４、１０５を含む。エンハンスメントレイヤＥＬについて、チャンクＥＬ１０３は、Ｓサンプルに対する符号化ビットストリームの対応する部分を備える。各サンプルは、１以上のＮＡＬユニットに編成される。さらに、特定のＮＡＬユニットが、ベースレイヤチャンクにおける対応の部分を参照するために、エクストラクタ１０６を含むための部分の開始において付加される。最後に、エンハンスメントレイヤチャンクは、所与の「ｘ」レベル、例えば、ピクチャレベル（ＰＰＳ）又はシーケンスレベル（ＳＰＳ）においてパラメータを定義するための様々なパラメータセット（「ｘＰＳ」１０７としてまとめられる）を備える。

「ｍｏｏｖ」ボックス１００は２つのボックス「ｔｒａｃｋ」を備え、一方が（ベースレイヤのカプセル化からもたらされる）ベースレイヤトラック１１０に専用となり、一方が（エンハンスメントレイヤのカプセル化からもたらされる）エンハンスメントレイヤトラック１３０に専用となる。

各レイヤトラックは、ｍｄａｔボックス１０１において示すそのそれぞれのＳサンプルを記述する。

ベースレイヤトラック１１０は、順次又は階層的に編成され、かつビットストリームの符号化された上記符号化部分のパラメータを定義する幾つかのボックスを備える。明瞭化のために、図１にはボックスの選択のみを示す。

トラックヘッダ１１１に対する「ｔｋｈｄ」というボックス又はサブボックスは、時間、空間及び識別情報を備える。時間情報は、Ｓサンプルの作成及び修正時間（ｃｒｅａｔｉｏｎ＿ｔｉｍｅ、ｍｏｄｉｆｉｃａｔｉｏｎ＿ｔｉｍｅ）に関する。ここでは識別子（ｔｒａｃｋ＿ＩＤ）は「ＢＬ」に等しく、トラックの識別を可能とする。空間情報は、ベースレイヤの表示サイズ情報（幅及び高さ）を備える。

「ｍｄｉａ」１１２とされる他のボックス又はサブボックスは、メディア情報記述ボックスであり、ビットストリームのＳサンプルに関するメディアデータについての情報を備える。

「ｍｄｉａ」ボックスは、明瞭化のために不図示の何らかのヘッダボックス及び記述情報自体を含むメディア情報ボックス「ｍｉｎｆ」１１３を備える。この例では、「ｍｉｎｆ」ボックスは、３個の異なるボックス又はサブボックスに小分けされる。

第１のボックス又はサブボックス「ｏｉｎｆ」１１４は、レイヤ及びサブレイヤ（例えば、時間サブレイヤ）並びに動作点を構成するそれらの編成などの動作点情報（動作点ディスクリプタともいう）、それらの間の依存性（もしあれば）、動作点に対するＨＥＶＣビットストリームのＶＰＳに含まれるプロファイル、ティア及びレベル情報を反映するｐｒｏｆ＿ｔｉｅｒ＿ｌｅｖｅｌパラメータを含む。より詳細には、ボックス「ｏｉｎｆ」は、図８の符号８００で示すように、スケーラビリティ構造についての情報を与えるパラメータ（ｓｃａｌａ＿ｍａｓｋ）、レイヤ数、ここでは２（ｍａｘ＿ｌａｙｅｒ＿ｃｏｕｎｔ＝２）、並びに各レイヤに対して識別子を備え、従属レイヤのリストの後にファイルにおける動作点数が続き、各々がプロファイル／ティア及びレベル情報によって及びこの動作点を構成するレイヤのセットによって記述される。

図８は、動作基点情報８００における標準動作基点ディスクリプタを示す。
図示するように、メディアデータ８０１は、記述的メタデータ８０４を備えるベースレイヤトラック８０２において符号化されるベースレイヤを用いて、及び記述的メタデータ８０５も備えるエンハンスメントレイヤトラック８０３において符号化されるエンハンスメントレイヤを用いて表示され得る。

ベースレイヤトラックメタデータ８０４は、メディアデータ８０１に対するデータ参照を備える。エンハンスメントレイヤトラックメタデータ８０５は、メディアデータ８０１に対するデータ参照及び例えば何らかのコード化依存性をシグナリングするベースレイヤトラックに対するトラック参照を備える。

動作基点情報「ｏｉｎｆ」８００は、トラック編成、特に、例えばスケーラブルＨＥＶＣ又はマルチビューＨＥＶＣのようなマルチレイヤビットストリームのサブセットを独立して復号可能な動作基点の編成に関する情報を備える。

より正確には、動作基点情報８００は、ビデオビットストリームのＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）及びＶＰＳ拡張からのプロファイル、ティア及びレベル情報８５１、動作基点ディスクリプタ８５２、並びに８５５で示すＶＰＳ拡張からのレイヤ間依存性及びＶＰＳ拡張からのスケーラビリティ寸法識別子を備える。動作点ディスクリプタ８５２は、ＶＰＳ拡張からの表示フォーマット情報８５３並びに８５４で示すＶＰＳ ＶＵＩ（Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）からのビット及びフレームレート情報を備える。

ＳａｍｐｌｅＴａｂｌｅＢｏｘに対する「ｓｔｂｌ」ボックス１１５という第２のボックス又はサブボックスは、各トラックに対するサンプルを記述する情報を含む。高効率ビデオコード化（ＨＥＶＣ）法に対して、情報の部分はＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘに対する「ｓｔｓｄ」ボックス１１６又はサブボックスに含まれる。パラメータ「ｅｎｔｒｙ＿ｃｏｕｎｔ」は、１つの（Ｖｉｓｕａｌ）ＳａｍｐｌｅＥｎｔｒｙのみが含まれることを示す。４バイトの「ｈｖｃ１」は、対象のメディアデータに対応するビットストリームが、「ｈｖｃＣ」ボックス１１７以下で定義されるＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄにおいて与えられる構成（プロファイル、ティア及びレベルを含む）の下で動作するＨＥＶＣデコーダによって準拠して使用可能であることを示す。この例では、バージョン構成は最初のものとなる（ｃｏｎｆｉｇＶｅｒｓｉｏｎ＝１）。ＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄはまた、ＨＥＶＣビットストリームのＶｉｄｅｏＰａｒａｍｅｔｅｒＳｅｔに含まれるプロファイル、ティア及びレベル情報を与える。

「ｔｃｏｎ」１１８という第３のボックス又はサブボックスは、トラックにおいて搬送される全てのレイヤ及びサブレイヤ、ここでは１のみ（ｎｕｍ＿ｌａｙｅｒｓ＝１）を列挙する。予約パラメータは、ボックスの更なる進化のために０値を常に有する。

実施形態によると、「ｔｃｏｎ」ボックスは任意であり、イタリック体の使用によって選択的に図１に示されている。例えば、１つのエンハンスメントレイヤのみがある場合、ファイルに「ｔｃｏｎ」１１８は存在しない。

レイヤの編成に関する他の情報は、様々な種類のサンプル入力：「ｓｈｖ１」、「ｓｈｅ１」、「ｓｈｖＣ」及びスケーラブルＨＥＶＣのみに対する任意の４文字コード並びに「ｍｈｖ１」、「ｍｈｅ１」、「ｍｈｖＣ」及びマルチビューＨＥＶＣサンプル入力のみに専用の任意の４文字コードのように任意となり得る。これらのコードは、識別される単一のスケーラビリティタイプを有するトラックに対応する。２以上の単一スケーラビリティタイプ（例えば、ＳＮＲ及びビュー寸法の双方）を有するトラックについて又は非出力レイヤであるトラックについて、１又は２種類のみのサンプル入力：例えば「ｌｈｖ１」、「ｌｈｖＣ」若しくは「ｌｈｅ１」又はレイヤ化されたＨＥＶＣサンプル入力を記述する任意の４文字コードが維持される。

他のトラックが、エンハンスメントレイヤ１３０に専用となる。それは、ｌｅ ｔｒａｃｋ＿ＩＤがエンハンスメントレイヤに対する「ＥＬ」であることを除き、トラックヘッダボックス「ｔｋｈｄ」１３１又はベースレイヤトラックの「ｔｋｈｄ」ボックスと同様のサブボックスを備える。

エンハンスメントレイヤに対するトラックは、ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘ「ｔｒｅｆ」１３２又はサブボックスを備える。それは、表示において、含まれるトラック、ここではエンハンスメントレイヤトラックからの参照を他のトラック、ここではベースレイヤトラックに提供する。

最初の参照「ｓｂａｓ」は、ベースレイヤ１１０のトラックがエンハンスメントトラック１３０に対するベーストラックであることを示す（ｔｒａｃｋ＿ｉｄｓ［］＝ＢＬ）。

他の参照「ｏｒｅｆ」は、ここではベースレイヤトラックに挿入される「ｏｉｎｆ」ボックス（動作基点ディスクリプタ）の参照を可能とする。「ｏｒｅｆ」参照は、イタリック体を用いて書かれている。もちろん、以下に説明するように、「ｏｒｅｆ」トラック参照タイプは、ベースレイヤトラックに「ｏｉｎｆ」ボックスが存在しない場合、１つの参照レイヤのみしかない場合には任意となり得る。

ベースレイヤトラックについて、エンハンスメントレイヤトラックは、「ｍｉｎｆ」ボックス１３４を含む「ｍｄｉａボックス」１３３を備える。この「ｍｉｎｆ」ボックスは、「ｓｔｓｄ」ボックスを含む「ｓｔｂｌ」ボックス１３５自体を備える。この最後のボックスは、例えば、対象のメディアデータに対応するビットストリームが、「ｌｈｖＣ」ボックス１３７において以下に定義される構成ボックスにおいて与えられる（プロファイル、ティア及びレベルを含む）構成の下で動作するＬ−ＨＥＶＣデコーダによって準拠して使用可能となることを示す４バイト「ｌｈｅ１」を備える。

この「ｌｈｖＣ」ボックスをより詳細に以下に示す。
最後に、ベースレイヤトラックについて、「ｍｄｉａ」ボックスは、選択的な「ｔｃｏｎ」ボックス１３８を備える。

上記実施形態によると、予め定義された条件（例えば、それ自体のトラックにおいて１つのみのエンハンスメントレイヤ）に基づいて、「ｔｃｏｎ」ボックスはトラックから除去されてもよい。これは、それらがそれら自体のトラックにおいてカプセル化されることを条件として複数のレイヤがある場合に相当し得る。

なお、トラック毎に１層のレイヤを有することによって幾つかの効果がもたらされる。まず、トラックはフィルタリング中に使用又は非使用のいずれかであるので、それはレイヤ化コンテンツのフィルタリングを簡素化し、トラック毎のマルチレイヤは、所望のＯＰによって使用されるレイヤ及びそのＯＰによっては使用されないレイヤの合成をトラックが含む場合にサンプル検査を課す。

さらに、そのような場合にトラックには単一のスケーラビリティ次元が存在する。これは、簡素化されたコード−ポイント（ｓｈｃ１／・・・）を用いてトラックのタイプを示すことを可能とし、スケーラビリティのタイプを識別するのにプロファイル及びレベルによることなく、マイムタイプの導出を簡素化する。

最後に、トラック毎に１層のレイヤを有することは、ストリームタイプが各タイプのスケーラブルコンテンツに対して定義されて単一のレイヤがトラックにおいて可能となるＬ−ＨＥＶＣのＭＰＥＧ−２ ＴＳ搬送との整合を改善することを可能とする。

しかし、トラック毎に単一のレイヤを有することには幾つかの欠点がある。
まず、非出力レイヤがそれら自体のトラックになければならないので、「ｓｔｂｌ」／「ｔｒｕｎ」ボックスが複製されることになるためにそれらはストレージを無駄にしてしまう。しかし、そのような場合（それによって出力レイヤとはならないレイヤ）は非常に限定的であることが考慮され得る。

また、トラック毎に単一のレイヤを有することは、それによってベースレイヤが１つのトラックに格納されるとともに全てのエンハンスメントレイヤが他のトラックに格納される場合又はそれによって全てのベース／ｌｈｅｖｃが１つのトラックに格納される場合を可能としない。そのために、トラック毎に１層のレイヤが、図１１において符号１１００で示すＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの修正又は図９の参照により示すような動的な「ｔｃｏｎ」ボックスの使用のいずれかをもたらす代替実施形態が検討される。

それによって「ｔｃｏｎ」ボックスが除去される場合では、レイヤ構造情報が、以下の図１１において１１０１で示すトラックによって搬送されるｌａｙｅｒＩＤの表示としてＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ（図１１における符号１１００）に格納される。最小及び最大時間サブレイヤは、何らかのレイヤを選択するのに「ｏｉｎｆ」によっては使用できないので、除去される。なお、それでも（単一レイヤの）ＨＥＶＣに対して定義された時間グループ化メカニズム（例えば、「ｔｓｃｌ」グループ化タイプ）を使用することができる。

より一般的には、ベースレイヤを意味する各レイヤ及び幾つかのエンハンスメントレイヤの各１層が個別のトラックにカプセル化される場合、「ｔｃｏｎ」ボックスは任意である。実際に、１層のレイヤが１つの動作点に対応する場合の標準的な構成について、このボックスは何ら有用な情報を提供せず、「ｔｃｏｎ」ボックスはトラックに１層のレイヤがあることを示すだけである。従属レイヤ（すなわち、この場合のトラック）のリストは、ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘを介して見ることができる。「ｔｃｏｎ」ボックスは、１つのトラックが幾つかのレイヤのカプセル化から生じる場合にのみ有用となり得る。

好適な実施形態によると、共通の「ｓｂａｓ」トラック参照のトラックのセットについて、このセットの間には、「ｏｉｎｆ」ボックスの情報を搬送する最大で１つのトラックがある。共通の「ｓｂａｓ」を参照するトラックの全トラックはまた、「ｏｒｅｆ」タイプトラック参照を用いることによって「ｏｉｎｆ」ボックスの情報を搬送するトラックにリンクされ得る。

ここで２つの選択肢があり、「ｓｂａｓ」トラック参照によって示すように、「ｏｒｅｆ」タイプを破棄し、「ｏｉｎｆ」情報がベーストラックにあることを強制するか（ハイブリッドコード化（ＡＶＣベーストラック＋ＨＥＶＣエンハンスメントトラック）の場合では、これはサンプルグループ「ｏｉｎｆ」がＡＶＣトラックにおいて許可されであろうことを意味する）、又は可能でない場合には、どのトラックが「ｏｉｎｆ」情報を示すサンプルグループ及びサンプルグループ記述ボックスを含むかをシグナリングするように「ｏｒｅｆ」を維持するかである。

図１１は、本発明による新たなデコーダ構成情報を示す。図示するように、レイヤ構造情報は、１１０１で示すトラックによって搬送されるｌａｙｅｒＩＤの表示を備えるＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ１１００に格納される。

情報がＩＳＯＢＭＦＦにおいて時間に対して変化することを可能とすることは、専用トラック、サンプル入力又はサンプルグループを用いることによって行われる。なお、レイヤ構成が「ｏｉｎｆ」及び選択的に「ｔｃｏｎ」ボックスによって現在提供されている。

実施形態によると、これらのボックスは、「ｍｉｎｆ」ボックスから除外され、図７に示すＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙクラスからデータを受け継ぐ。

図７は、本発明の実施形態による動作基点に対する特定のかつ動的に拡張可能なディスクリプタを示す。

図７に示すように、動作点情報は、抽象的ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙを特殊化することによって新たなＯｐｅｒａｔｉｎｇＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ７００を用いて取得され得る。

その実施形態によると、「ｏｒｅｆ」タイプを参照するトラックは、サンプルグループボックス７０３及びサンプルグループ記述ボックス７０２又はデフォルトのサンプルグループ化の場合にはサンプルグループ記述ボックス７０１のみを含むことになる。サンプルグループ記述ボックス７０１は、それによって、サンプルの任意のグループにマッピングされないトラックのサンプルがインデックス１（ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｉｎｄｅｘ＝１）を有するサンプルのグループのサンプルプロパティを受け継ぐような場合を示す。

ＯｐｅｒａｔｉｏｎＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ（例えば、ＯｐｅｒａｔｉｏｎＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ７０５）は、サンプルグループボックス７０３において定義される対応のサンプルについて、（図８を参照して説明した標準「ｏｉｎｆ」構造体８００などの）標準「ｏｉｎｆ」構造体で与えられる定義に従って、使用される情報のセットを提供する。

グループボックス７０３に対するサンプルが「ｏｉｎｆ」というｇｒｏｕｐｉｎｇ＿ｔｙｐｅを介してサンプルグループ記述ボックス７０２に関連付けられる図７に示す例は（なお、ここでは、このコードは説明のために与えられるにすぎず、動作点グループ入力を示すのに予約された任意の４文字コードが使用され得る）、図６を参照して説明した異なる動作基点のストリームスライシングから生じる２つのサンプルグループ（符号６０３）を示す。

当然に、２つのサンプルグループ記述入力の一方は、１つの特定のサンプルグループ記述入力のみが定義されることになるようにデフォルトによって定義されたサンプルグループ記述となり得る。言い換えると、最初のＮ１個のサンプルを特定のサンプルグループ記述に関連付け、他のサンプル（すなわち、「ｏｉｎｆ」グループにマッピングされないサンプル）をデフォルトのサンプルグループ記述に関連付けることが可能となる。

同様に、トラック内のレイヤ編成は時間とともに変化するので、動的な更新が必要とされる場合に「ｔｃｏｎ」ボックスは同様に修正され得る（すなわち、「ｍｉｎｆ」ボックスから新たなｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び新たなＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙに移動する）。
図９に示すように、新たなＬａｙｅｒＩｎｆｏＧｒｏｕｐＥｎｔｒｙ「ｔｃｏｎ」９００はその目的に使用され得る。ここでも、説明の目的のため、４文字コード「ｔｃｏｎ」と特定の入力の名前（ＴｒａｃｋＣｏｎｔｅｎｔＧｒｏｕｐＥｎｔｒｙであってもよい）が与えられる。

ＬａｙｅｒＩｎｆｏＧｒｏｕｐＥｎｔｒｙ「ｔｃｏｎ」は、以下のように定義され得る：

図９は、レイヤ情報記述に対する特定かつ動的に拡張可能なディスクリプタを示す。
ここでも、「ｏｒｅｆ」タイプを参照するトラックは、サンプルグループボックス９０３及びサンプルグループ記述ボックス９０２、又はデフォルトのサンプルグループ化の場合にはサンプルグループ記述ボックス９０１を含むことになる。

一定のレイヤ編成を有するトラックについて、デフォルトのサンプルグループ化が使用され得る。図６を参照して（例えば、ビットストリームスプライシング６０３において）説明したように、レイヤ編成は時間とともに変化する場合、サンプルグループボックスは、サンプルをそれらのトラック編成に適したレイヤにマッピングするように定義され得る。説明の目的のため、図６においてストリーム６０３におけるストリーム６０２のサンプルと合成されるストリーム６０１のサンプルに対応し得るグループ９０３において定義される最初のＮ１個のサンプル、及び図６においてストリーム６０３におけるストリーム６０１のサンプルと合成されるストリーム６０２のサンプルに対応し得る残りのＮ２個のサンプルが、サンプルグループ記述ボックス９０２における異なるレイヤ情報グループ入力と関連付けられ得る。

ここでも、２つのサンプルグループ記述入力の一方は、１つの特定のサンプルグループ記述入力のみが定義されることになるようにデフォルトによって定義されたサンプルグループ記述となり得る。言い換えると、最初のＮ１個のサンプルを特定のサンプルグループ記述（特定のレイヤ情報グループ入力）に関連付け、他のサンプル（すなわち、「ｔｃｏｎ」ｇｒｏｕｐｉｎｇ＿ｔｙｐｅのいずれのサンプルグループにもマッピングされないサンプル）をデフォルトのサンプルグループ記述（他のレイヤ情報グループ入力）に関連付けることが可能となる。

図１０は、本発明による、カプセル化されたメディアファイルに対するクライアント端における処理を示す。

図示するように、クライアントデバイスは、最初のステップ（ステップ１０００）において、ｍｐ４（又はＩＳＯＢＭＦＦ）ファイル又はｍｐ４（又はＩＳＯＢＭＦＦ）セグメントを受信する。それはｍｐ４パーサ（又はｍｐ４リーダ）によって翻訳又は構文解析される（すなわち、読み出され、又は復号される）。セグメントベースの配信の場合、受信は、メディア表示の最初の初期化セグメントから最後のセグメントまでの巡回処理となる。ｍｐ４ファイルについて、全てのデータはファイル受信時に利用可能となり得る。

続くステップ１００１は、ｍｐ４パーサが動作基点情報を探すことからなる。もちろん、１以上のＬ−ＨＥＶＣトラックのサンプルからのアクセスユニットを再構成するために、それらが属するターゲット出力レイヤ及び動作基点が最初に決定される必要があり得る。これは、「ｍｏｏｖ」ボックス（又はｍｐ４セグメントの場合における「ｍｏｏｆ」ボックス）の下で記述的メタデータを構文解析することによって行われ得る。

好適な実施形態によると、パーサは、それが遭遇する全ての「ｔｒａｋ」ボックスからトラックの内部リストをメモリ内に構築する。これらのトラックから、少なくとも１つのトラックが「ｏｒｅｆ」トラックとして参照される場合、これはファイル（又はセグメントのリスト）において利用可能な動作基点に関する情報を含むべきものである。そして、このトラックを記述するメタデータボックス、特に、動作点情報を示すグループ化タイプを有するグループボックスに対する何らかのサンプルを探すサンプルテーブルボックスが構文解析される。

これは、例えば、好適な実施形態による「ｏｉｎｆ」コードであればよい（例えば、サンプルグループボックス７０３及び図７を参照して説明したデフォルトのサンプルグループ化の場合にはサンプルグループ記述ボックス７０２又はサンプルグループ記述ボックス７０１）。これは、任意の予約された固有の（すなわち、他の目的のために使用されていない）４文字コードであればよい。

そのようなサンプルグループ（図７における符号７０３及び７０２）又は少なくともデフォルトのサンプルグループ（図７における符号７０１）が発見された場合（すなわち、テスト１００１が真の場合）、トラック選択は動作点パラメータに基づく（ステップ１００２）。
これに対して、テスト１００１が偽である場合、デフォルトのトラックが選択される（ステップ１００３）。これは、例えば、ファイルにおける最初のトラック又はトラックヘッダボックスにおける最低「レイヤ」値のものであればよい。あるいは、全てのトラックがユーザに提示され、プレーヤがユーザ選択を待機する。

選択されたトラックは、ステップ１００４においてそのトラック参照ボックス（「ｔｒｅｆ」）から発見可能な潜在的にコード化依存性を有する単純なトラックのみであるものとする。

再生する１以上のトラックが動作点情報から選択されると（ステップ１００２）、レイヤのリストが動作点情報グループ入力から識別され得る。そして、クライアントデバイスに対する次のステップは、識別されたレイヤがそこにカプセル化されるトラックを識別することである（ステップ１００５）。これは、以下のいずれかを介してトラック記述ボックスを構文解析することによって行われ得る。
−ｗ１５１８２で記述されるレイヤードＨＥＶＣファイルフォーマットの現バージョンによるトラックコンテンツ情報ボックス「ｔｃｏｎ」、
−サンプルグループ記述を介して図９を参照して説明した実施形態によると、「ｔｃｏｎ」値（又はサンプル又はトラックのサンプルのグループに対するレイヤ情報を示す任意の予約された固有の４文字コード）を有するグループ化タイプを探し、又は
−ある単一レイヤに１つのトラックが対応する他の実施形態によると、トラックに対する「ｌｈｖＣ」ボックスにおける修正されたＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ（図１１における符号１１００）からの情報を構文解析することによって（ステップ１１０１）レイヤがトラックに対応するか否かを識別する。図１１において１１０１で示す新たなｌａｙｅｒ＿ｉｄパラメータが、このサンプル入力に関連するサンプルに含まれるＶＣＬ ＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄの値を示す。そのような場合にはトラックはエクストラクタ及びアグリゲータだけを含むので、この値は図１１において１１０２で示すフラグｃｏｍｐｌｅｔｅ＿ｒｅｐｒｅｓｅｎｔａｔｉｏｎが０にセットされた場合に０となるべきである。

レイヤからトラックへのマッピングがステップ１００５中に実行され、パーサが（ステップ１００２中に）（図８のディスクリプタ８００において符号８５５によって記載されるように）動作点のレイヤが従属する従属レイヤのリストを取得したことが監視される。

動作点に対して取得されたトラック及び従属レイヤに対応する従属トラックは、ステップ１００４中に相互従属トラックのリストを形成するのに使用される。これらの従属性の性質を知るために、パーサは、ステップ１００６において取得されたトラックのトラック参照ボックスを検査する。

ベーストラックという特定のトラックが、ステップ１００７において発見されるべきである。

この特定のトラックは、アクセスユニット再構成を開始するトラックである。何も発見されない場合、これはエラーであり、プレーヤは、例えば、無効なメディアファイルを示すエラーメッセージを送信する（ステップ１００８）。

「ｓｂａｓ」トラック参照タイプを介して参照されるベーストラックが発見可能な場合、パーサは、ユーザによって与えられる時間において、この１つからのサンプル再構成を開始する（最初のサンプルを識別するサンプルテーブルボックスにおける何らかの誘導を必要とし得る）。

まず、テストが実行されてこの最初のサンプルがエクストラクタを含むか否かを判別する（ステップ１００９）。エクストラクタが存在する場合、これは、発見されたベーストラックからの「ｓｃａｌ」トラック参照タイプで、そこからサンプルデータを複製する参照トラックに対して示されるべきであり、サンプルの再構成が明示的であり、エクストラクタを分解すること、すなわち、エクストラクタＮＡＬユニットをエクストラクタによって指示されるＮＡＬユニットデータに置換することにある。

これは、トラックの各サンプルに対して実行されて、ステップ１０１１においてトラックを表し、最終的にステップ１０１２においてクライアントデバイスによって復号及び表示可能なビデオビットストリームを生成するＮＡＬユニットのリストを生成する。

説明の目的のため、これは、図４ａに表すタイルビットストリームのベースレイヤ４００に適用可能である。

これに対して、ステップ１００９においてエクストラクタが発見されない場合、ステップ１０１３において、パーサは、（例えば、以降で説明する図４ｂを参照して説明する「ｓａｂｔ」のような）ベーストラックに関連するトラック参照リストにおける何らかの特定の順序付けされたトラック参照があるか否かを確認する。

ステップ１０１３において特定の順序付けされたトラック参照が識別された場合、ステップ１０１４において復号順序依存のトラックの順序付けリストが構築される。

これに対して、ステップ１０１３において特定の順序付けされたトラック参照が識別されない場合、ＩＳＯ／ＩＥＣ２３００８−２（ＨＥＶＣ標準）に準拠する順序においてそれらのＮＡＬユニットを配列することによって、ＯｐｅｒａｔｉｏｎＰｏｉｎｔＩｎｆｏｒｍａｔｉｏｎＢｏｘによって示すように、アクセスユニットが、必要なトラックにおけるそれぞれのサンプルから再構成される。これは、ステップ１０１５の潜在的なアクセスユニット再構成である。選択的に、この潜在的又は明示的再構成における表示は、１１０１で示すｌａｙｅｒ＿ｉｄの直前に、図１１において１１００で示すＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの予約ビットの１つに配置され得る。

代替として、明示的再構成の場合に、エクストラクタがｍｐ４パーサによって分解されて、ビデオデコーダに対して、分解されることなく提供されないことを保証するために、特定のサンプル入力が、潜在的再構成のトラックに対して、及び明示的再構成のトラックに対して定義され得る。

再構成手段にかかわらず、パーサは、ステップ１０１２において復号可能ビットストリームを形成するように、ステップ１０１１において動作点に関与するトラックの全サンプルを考慮してそれらのサンプル（ＮＡＬユニット）を連結しなければならない。

なお、選択ステップ（１００１）は、ファイルにおいて再生する最初のサンプルの時間に依存し得る。例えば、図６における符号６０３によって記載されるスプライスされたストリームの記録から生じるストリームにおいて、サンプルの時間は、プレーヤがどこで開始するかに応じて、「ｏｒｅｆ」トラックとして参照されるトラックのサンプルグループ記述ボックス（図７におけるサンプルグループ記述ボックス７０２など）における、ある又は他のＯｐｅｒａｔｉｏｎＰｏｉｎｔＩｎｆｏＧｒｏｕｐＥｎｔｒｙをもたらすことになる。

図１２は、本発明による、ビデオビットストリームカプセル化のためのサーバ端での処理を示す。

図１２に記載されるアルゴリズムを用いて行われるカプセル化は、ヒントトラックを付加することによって適応的なＨＴＴＰ上のストリーム若しくはＲＴＰ上のストリーム用に又はローカルな記憶／記録用にストリームを準備するために行われ得る。カプセル化は、ｍｐ４ライタが１以上の符号化メディアストリームを入力として１つのｍｐ４ファイル又はｍｐ４セグメントのリストのいずれかを生成することによって扱われる。

なお、記述がビデオストリームのカプセル化に関する場合、動作点の使用及び依存性のシグナリングは他のレイヤードメディアタイプにも当てはまる。

ｍｐ４ライタの最初のステップ（ステップ１２００）は、例えば、ＨＥＶＣにおけるＶＰＳ（ＶｉｄｅｏＰａｒａｍｅｔｅｒＳｅｔ）、ＶＰＳ＿ＶＵＩ（Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）及びＶＰＳ拡張などのビデオビットストリームの上位記述パラメータを構文解析することにある。特に、ストリームが複数の動作基点及び依存性のある多数のレイヤを含む場合に、ｍｐ４ライタは、ビデオパラメータセットから複雑さの度合いを推定する。このレイヤ数から、ｍｐ４ライタは、１つのレイヤがそれ自体のトラックにあるものとしてそれが生成するトラック数を推定する。

マルチレイヤストリームの場合（すなわち、テスト１２０１が真の場合）、ｍｐ４ライタは、ＶＰＳ及びＶＰＳ拡張パラメータを図８を参照して説明した８００で示すディスクリプタなどのディスクリプタに配置することによってステップ１２０３中に動作基点ディスクリプタを満たす。

その間に、ｍｐ４ライタは、ビデオビットストリームにおけるベースレイヤ、すなわち、０に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＮＡＬユニットに対応するベーストラックの構成を開始する。

そのようなベーストラック構成は、単一のレイヤビットストリームの場合（すなわち、テスト１２０１が偽の場合）においても実行されて、カプセル化された単一のトラックを生成する（ステップ１２０２）。

（レイヤ数に対応する）他のトラックも、通常は、ｌａｙｅｒＩＤ値、例えば図１１に示すＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ情報１１００のｌａｙｅｒ＿ｉｄ１１０１を設定すること、及び「ｓｂａｓ」参照トラックを介してベーストラックを参照することによって開始される。

動作基点情報ディスクリプタに関するステップ１２０３は、主に、「ｔｒａｋ」ボックス並びに特にＶＰＳ及びＶＰＳ拡張パラメータを有するデフォルトのＯｐｅｒａｔｉｏｎＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ（例えば、図７における符号７０１）のサンプルテーブルボックスの階層を作成することにある。デフォルトによっては、（図７における符号７０３のような）ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは作成されない。

ＶＰＳ、ＶＰＳ＿ＶＵＩ及びＶＰＳ拡張パラメータから、ｍｐ４ライタは、ａｖｇ＿ｂｉｔ＿ｒａｔｅパラメータを介してステップ１２０４において平均ビットレートを知得する（存在しない場合は、ｍｐ４ライタは、サンプル数で除算された全体ストリームのサイズを概算して平均ビットレートを推定することができる）。

そして、１２０５において、エクストラクタ（明示的再構成）を使用するか否かが決定される。例えば、レイヤ数及びサンプル数を知ることで、エクストラクタ当たり、サンプル当たり、及び従属トラック当たり１２バイトが入力ビデオビットストリームに関する所与の割合以上にファイルのサイズを増加させるかを推定することができる。

説明の目的のため、ｍｐ４ライタは、対応のオーバヘッドがビットストリームのサイズを５％以上増加させない場合にエクストラクタを使用するようにパラメータ設定され得る。

カプセル化がインタラクティブな場合には、この決定及び閾値はユーザ決定可能であり、ｍｐ４ライタは、オーバヘッドを推定し、それを、エクストラクタを用いてビットストリームをカプセル化するか否かを決定することができるユーザに提供する。

オーバヘッドが許容可能なままである場合（又はユーザがエクストラクタを使用することを選択する場合）、ｍｐ４ライタは、ステップ１２０６においてエクストラクタ生成モードを活性化する。そのモードによると、どのようにしてサンプルを再構成するかを明示的に示すための表示が、依存性を有する各トラックの各サンプルに対して生成される。

これに対して、オーバヘッドが非常に重要な場合、ｍｐ４ライタは、サンプルの再構成がトラック参照のみから推定されるべきことを意味する潜在的再構成モードを検討する。

その目的のため、ｍｐ４ライタは、ステップ１２０７において、レイヤ依存性がＮＡＬユニットの正しい順序を保証するのに充分であるか否か又は曖昧さが残るか（例えば、個別のトラックにおいてタイルをカプセル化する場合）を確認する。順序が示されるべき場合、ｍｐ４ライタは、連結順序を示唆する特定のトラック参照タイプ（例えば「ｓａｂｔ」のものなど）に対象のトラック（例えば、図４ｂに示すようなタイル及びタイルベーストラック）をリンクさせる。

反対に、順序が指定されない（すなわち、テスト１２０７が偽である）場合、ｍｐ４ライタは、以下の再構成規則：所与の時間についてｎｕｈ＿ｌａｙｅｒ＿ｉｄを増加させる際の順序ＮＡＬユニットに依拠する特定のトラック参照を指定しない。

再構成方法が決定されると、ｍｐ４ライタは、ＮＡＬユニットを読み出し始め、サンプルテーブルボックスにサンプル情報（例えば、タイミング、データにおけるバイトオフセットなど）を示す。

それによってエクストラクタが使用される場合に、トラックが他のものに依存する場合、このトラックのサンプルは、（「ｓｃａｌ」トラック参照タイプを介して）エクストラクタを用いて参照トラックにおけるデータを参照する。

ｍｐ４ライタは、全てのサンプルが処理される（すなわち、テスト１２１２が偽となる）まで、サンプル記述及びカプセル化処理を実行する。

ステップ１２１３において、サンプルからサンプルへ、ｍｐ４ライタが新たなＶＰＳ、新たなＶＰＳ拡張又はレイヤ構成の変化（例えば、最大ｎｕｈ＿ｌａｙｅｒ＿ｉｄの変化）を検出した場合、ｍｐ４ライタは、新たなベーストラックがあるか否かを確認する（テスト１２１４）。これは、同じファイルにおける複数のメディアストリームをカプセル化する場合に相当し得るものであり、トラックのセットがｍｐ４ファイルに既に存在し、特に、０に等しいｌａｙｅｒ＿ｉｄ及び新たなビデオビットストリームを有するもの、例えば、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値が０のＮＡＬユニットも有する代替の独立したビデオビットストリームがカプセル化されることになる。

新たなベーストラックは、デフォルトのサンプルグループ記述ボックス（例えば、図７におけるデフォルトのサンプルグループ記述ボックス７０１）とともに１２１６中に新たな動作基点ディスクリプタの生成をもたらす。構成が変化しても新たなベーストラックがない（すなわち、テスト１２１４が偽となる）場合、ベーストラックサンプルグループは１２１５中に修正されて、新たなＯｐｅｒａｔｉｏｎＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ（例えば、図７の７０２における１つのＯｐｅｒａｔｉｏｎＰｏｉｎｔＧｒｏｕｐＥｎｔｒｙ）を生成し、関連するサンプルをグループ化タイプ「ｏｉｎｆ」（又は予約された４文字コード）のグループボックス７０３に更新する（又はそれでも存在しない場合には作成する）。

最後に、ｍｐ４ライタは、トラック記述及びそれらの依存性を有するｍｐ４ファイルを生成する。

サーバ端において実行されるこの処理は、ストリーム化されたメディアファイル、例えば、ｍｐ４セグメントを記録するために受信機端においても実行され得る。ステップ１２１３を参照して説明したように、１つのストリームから他のストリームに切り換える場合に受信機が現在のレイヤ構成について通知され、グループに対して新たなサンプル及びグループ化タイプ「ｏｉｎｆ」（又は専用の４文字コード）の関連の記述を追加又は作成することによってその動作基点ディスクリプタを更新するように、サーバは、何らかのｍｐ４セグメントのメタデータ部分においてレイヤ構成の記述を準備していてもよい。

図７を参照して説明したものの代替である実施形態によると、特定のトラックが、動作点情報ディスクリプタ（例えば、図８における動作点情報ディスクリプタ８００）から情報を搬送するサンプルに割り当てられる。そして、トラックサンプルのほとんどが空となる。このトラックは、特定のサンプル入力、例えば、Ｌａｙｅｒｅｄ−ＨＥＶＣパラメータセットストリームに対する「ｌｈｖｐ」で宣言される。ＬａｙｅｒｅｄＨＥＶＣストリームサンプル入力は、以下のＬＨＥＶＣパラメータストリーム構成を含む。

このトラックは、特定の「ｏｒｅｆ」トラック参照タイプを有する同じ動作点を用いて他のトラックによって参照されるべきである。「ｓｂａｓ」トラック参照タイプを介してベーストラックを共有するトラックのセットに対して、そのようなトラックは１つのみとなるべきである。

図７を参照して説明したものの他の代替実施形態は、「ｍｉｎｆ」ボックスにおける静的な「ｏｉｎｆ」（例えば、図８における「ｏｉｎｆ」８００）を維持するが、例えば、新たなレイヤがメディア表示に付加される場合に何らかのパラメータを変化させることを可能とするものである。これは、この「ｏｉｎｆ」ボックスの拡張バージョンに異なるものを付加するために、プロファイル構成比較のための追加の手段をｍｐ４パーサ及びライタに要求する。

その目的のため、ｍｐ４ライタは、動作基点を比較する特定のモジュールを必要とする。新たな動作基点がＶＰＳから検出されると、ｍｐ４ライタは、パラメータ毎に、新たな動作基点と静的な「ｏｉｎｆ」ボックスに既に格納されているものと比較する。少なくとも１つのパラメータが異なる場合、新たな入力がこの動作基点においてｏｉｎｆにおいて作成され、動作基点の数が増分される。

同様に、レイヤ情報が更新され、新たなレイヤ識別子を新たなビットストリームにおけるものに割り当ててＩＤ競合を回避する。その後、レイヤの最大数が新たなストリームに存在するレイヤ数で更新される。これらの新たなレイヤの各々について、それらの依存性が、ｏｉｎｆボックスのディスクリプタ８５５に格納される。最後に、新たなストリームが新たなスケーラビリティ寸法をもたらす場合、スケーラビリティマスクが更新され、したがってこの新たな寸法に対応する１ビットに設定する。

上記の文書ｗ１５１８２は、現在、ビットストリームにおいて使用されるスケーラビリティのタイプを示すことなくＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄを定義する。一般的な「ｌｈｖ１」／「ｌｈｅ１」が使用されるべき場合、ｗ１５１８２において現在定義されるように、クライアント側におけるファイルリーダは、ビデオパラメータセット（ＶＰＳ）拡張を構文解析してスケーラビリティのタイプを把握しなければならない。このＶＰＳは、ＮＡＬＵ１０７におけるチャンクであればよい。これは複雑な処理となる。

好適な実施形態（不図示）によると、「ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ」（ボックス１３７参照）という１６ビットのスケーラビリティマスクを含む新たなＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄが提案される。他の実施形態によると、ｎを整数とし、構造全体が整数のバイト上に整列されたままであるとすると、スケーラビリティマスクはｎビットで表され得る。例えば、ＨＥＶＣ規格にあるように、ｎ＝８である。

ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄは、明瞭化のために表されていない、ｗ１５１８２において定義された「ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ」というフィールドを備える。フィールド「ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ」は、画素の最大数並びに可能なタイル及びスライスに関する情報を与える。

特定の実施形態によると、例えば以下の「ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ」パラメータの後に他のパラメータをデコーダ構成記録に付加して、サンプルを復号するのに必要なレイヤードＨＥＶＣの種類を明確化することが提案される。

「ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ」の値（本例では「２」）は、空間又は品質のスケーラビリティのタイプを示す。このフィールドは、クライアントが、スケーラビリティタイプがサポートされているかを検出するとともにファイルを再生することができるかを判定することに役立つという効果を有する。ファイルを再生できない場合には、それは、例えばベースレイヤトラックのみなど、より低い動作点を選択することができる。

図２は、対象のピクチャのエンハンスメントレイヤのみのピクチャが４つのタイルに分割される場合のＩＳＯ−ベースメディアファイルフォーマットによる２つのスケーラビリティレイヤをカプセル化する例を示す。カプセル化は、４つの追加タイルトラック（１４０−１４３）又はエンハンスメントタイルトラックＥＬＴＴを配信する。

ＨＥＶＣタイルトラックと同様の態様において、エンハンスメントレイヤの空間小部分の効率的アクセスを可能とするようにＬａｙｅｒｅｄ−ＨＥＶＣタイルトラックを定義することが可能となる。そのような場合について、実施形態によると、特定のトラックが、ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙサンプル記述フォーマットを用いて特定のサンプルとともに作成される。

ＬＨＥＶＣタイルトラックは、このトラックにおけるタイルが属するＨＥＶＣレイヤの非ビデオコード化レイヤＮＡＬＵを搬送するＬＨＥＶＣトラックに対する「ｔｂａｓ」参照があるようなビデオトラックである。本発明の実施形態によると、新たなサンプル記述タイプ「ｌｈｔ１」が定義される。

実施形態によると、タイルトラックのサンプルもサンプル記述ボックスも、ＶＰＳ、ＳＰＳ又はＰＰＳのＮＡＬユニットを含むべきではなく、これらのＮＡＬユニットは、トラック参照タイプ「ｔｂａｓ」（図２におけるエンハンスメントレイヤトラック１３０）によって識別されるような関連のレイヤを含むトラックのサンプル又はサンプル記述ボックスにあるべきである。

実施形態によると、「ｔｂａｓ」トラック参照によって示すようなＬＨＥＶＣタイルトラック及び関連のレイヤを含むトラック又はレイヤトラックの双方は、ｗ１５１８２のＡｎｎｅｘＢにおいて定義されるようなエクストラクタを用いて、どのようにして元のビットストリームが再構成されるかを示す。これらのタイルトラックにおけるエクストラクタの存在は、幾つかのアプリケーション領域においては制限されることがあり、例えば、（図４ａを参照して説明したように）各タイルトラックではなくタイルベーストラックにエクストラクタを配置すること、特に復号及び再生するタイルのサブセットの選択を可能とすることが好ましい場合がある。あるいは、複数のタイル化されたレイヤの場合には、タイルベーストラックのみにおいてエクストラクタを配置する場合に記述サイズが減少される。

図４ａ及び４ｂからなる図４は、代替のトラック及びタイルトラック依存性のシグナリングの例を示す。

図４ａに示すシグナリングの例によると、タイムドサンプル４０１を備えるベースレイヤトラック４００は、タイルがある分の（すなわち、図４ａでは４個の）ベースレイヤのタイルトラックに対するトラック参照４０３を有する。ベースレイヤトラックは、トラック参照ボックスにおいて宣言される各タイルトラックに対する「ｓｃａｌ」参照タイプを有する（これは、メタデータ部分、例えば図８におけるメタデータ部分８０４において定義される）。

同様に、各タイルトラックは、そのトラック参照ボックスにおいて宣言される「ｔｂａｓ」トラック参照タイプを有する（これは、メタデータ部分、例えば図８におけるメタデータ部分８０４において定義される）。

さらに、ベースレイヤトラック４００の各サンプルは、ベースレイヤトラックにおいてタイルがある分のエクストラクタ４０２を有する。

サンプル４０７を備えるエンハンスメントレイヤ４０６は、同じ記述及び構成規則に従う。ベースレイヤトラック及びエンハンスメントレイヤトラックは、「ｓｂａｓ」及び「ｓｃａｌ」トラック参照タイプ４０４及び４０５を介して相互参照される。ここでは、「ｓｃａｌ」参照タイプは、各参照トラックにおけるサンプルからの各サンプルを再構成するのにエクストラクタが使用されることを示す。

図１ａに示すように、タイルトラックを用いるＨＥＶＣ又はＬ−ＨＥＶＣトラックは、そのタイルトラックからのデータを参照するのにエクストラクタを使用し、この場合、トラックは、図４ａに示すようにタイルトラックに対して「ｓｃａｌ」トラック参照を有すべきである。

＜タイル化されたアクセスユニットのデータ共有及び再構成＞
図４ｂは、それによってエクストラクタが使用されない依存性のシグナリングの例を示す。

そのような場合、タイルトラックを用いるＨＥＶＣ又はＬ−ＨＥＶＣトラックは、タイルトラックに対して専用の「ｓａｂｔ」トラック参照タイプ４５３を用いてタイル順序付けを示す（エクストラクタの使用に対して予約された「ｓｃａｌ」参照タイプをもはや示さない）。タイルトラックは、「ｔｂａｓ」トラック参照タイプを有するタイルベーストラックを参照し続ける。

「ｓａｂｔ」トラック参照は、ＨＥＶＣ又はＬ−ＨＥＶＣトラックからのタイルトラックを言及するのに使用されるにすぎない。「ｓａｂｔ」トラック参照がトラックに存在する場合、このトラックのサンプルはエクストラクタ又はアグリゲータを使用すべきではなく、ＨＥＶＣ又はＬ−ＨＥＶＣトラックのサンプルは、トラック参照の順において、このトラックの「ｓａｂｔ」トラック参照に示される全ての利用可能なトラックにおいて、同じ復号時間のサンプルに含まれるＮＡＬユニットをサンプルデータに付加することによって（すなわち、編集リストを考慮することなく時間−サンプルテーブルのみを用いて）再構成される。トラックに対して利用可能なデータがない場合には、対応のサンプルにはデータは割り当てられない。ＳＥＩ Ｓｕｆｆｉｘ ＮＡＬユニットは、再構成されるサンプルにおける全ての非ＶＣＬ ＮＡＬユニットの後に移動されるべきである。

トラックは、そのトラック参照ボックスにおいて定義された「ｓａｂｔ」及び「ｓｃａｌ」トラック参照の双方とも有さない。さらに、エクストラクタが使用されない場合（潜在的ＡＵ再構成）、「ｓｃａｌ」トラック参照の使用はあまり有用ではなく、除去され得る。もちろん、「ｏｉｎｆ」ボックスは各動作基点に対するレイヤ識別子の完全なリストを与え、レイヤ識別子は各トラックの「ｔｃｏｎ」ボックスにおいて（又はトラック毎に１つのレイヤのみがある場合には、デコーダ構成情報におけるレイヤ識別子としてトラックに直接に）示される。そして、アクセスユニットは、それらのＮＡＬユニットをＩＳＯ／ＩＥＣ２３００８−２（ＨＥＶＣ標準）に準拠した順序で構成することによって、ＯｐｅｒａｔｉｏｎＰｏｉｎｔＩｎｆｏｒｍａｔｉｏｎＢｏｘによって示される（そしてトラック参照によっては示されない）ような必要なトラックにおけるそれぞれのサンプルから再構成される。

タイルトラックに格納されるＬＨＥＶＣサンプルは、ＩＳＯ／ＩＥＣ２３００８−２において定義されるような１以上のタイルに対するスライスの完全なセットである。通常、タイルトラックが単一のタイルのことをいう場合、このタイルをコード化するのに使用されるスライスのみがサンプルにおいて発見される。タイルトラックは通常、１つのＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙ（単一タイルのトラック）、又は１つのＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙ及び１以上の従属ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを含み、このタイルセットはマルチタイルトラックで構成され、既にＨＥＶＣに対して定義されている。

タイルトラックに格納されたＬＨＥＶＣサンプルは、「ｓｙｎｃ」サンプル、例えば、サンプルに含まれるコード化されたスライスがＩｎｓｔａｎｔａｎｅｏｕｓＤｅｃｏｄｉｎｇＲｅｆｒｅｓｈ（ＩＤＲ）スライス、ＣｌｅａｎＲａｎｄｏｍＡｃｃｅｓｓ（ＣＲＡ）スライス又はＢｒｏｋｅｎＬｉｎｋＡｃｃｅｓｓ（ＢＬＡ）スライスであることをサンプルにおけるＶＣＬ ＮＡＬユニットが示すかを確かめるなど、ランダムアクセスのための同期サンプルとみなされる。

規則的な（ｗ１５１８２における）ＬＨＥＶＣサンプルに対して定義されたサブサンプル及びサンプルグループは、ＬＨＥＶＣタイルサンプルに対するものと同じ定義を有する。

本発明の実施形態によると、実施例は、ＨＥＶＣシーケンスの完全なタイルのサブセットのみを復号することを決定し得る。この場合、それは、ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙ及びＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙサンプルグループ記述におけるタイル依存性情報を用いて、不要なトラックを破棄し、又はＨＥＶＣシーケンスを復号しつつ幾つかのエクストラクタを無視してもよい。

図２において、図１と同じ符号を有する要素は同様のものである。さらに、明瞭化のために「ｍｏｏｖ」ボックスのみが表される。

図２において、「ｍｏｏｖ」ボックスは、４個のタイルトラックボックス１４０、１４１、１４２及び１４３の追加のトラックボックスを備える。ここではタイルトラック１４１のみを説明する。他のタイルトラックボックスは、容易に推測可能である。

タイルトラックボックスは、「ｔｋｈｄ」トラックヘッダボックス、すなわちサブボックス１５０を備え、これはＢＬ及びＥＬレイヤトラックボックスに属する「ｔｋｈｄ」ボックス１１１又は１３１と同じ特性を有する。

タイルトラックボックスは、「ｔｒｅｆ」トラック参照ボックス、すなわちサブボックス１５１を備え、これは、以下の点を除いて、ＢＬ及びＥＬレイヤトラックボックスに属する「ｔｒｅｆ」ボックスと同じ特性を有する。
−それは、タイルベーストラックに対する関係を示す４バイトの「ｔｂａｓ」を含み、
−識別子ｔｒａｃｋ＿ＩＤ［］は、このトラックに対するタイルベーストラックが識別子「ＥＬＢＴ」を有するエンハンスメントタイルトラックであることを示す。

タイルトラックボックスは、ＢＬ及びＥＬトラックとして「ｍｄｉａ」ボックス１５２、「ｓｔｂｌ」ボックスすなわちサブボックス１５３、「ｓｔｓｄ」ボックスすなわちサブボックス１５４を有するｍｉｎｆ（明瞭化のために図示しない）ボックスを備える。

「ｓｔｂｌ」ボックス１５３は、トラックサンプル「ｓｇｐｄ」１５６及び「ｓｇｐｄ」に含まれる「ｔｒｉｆ」１５４にプロパティを関連付ける２つのボックス又はサブボックスを備える。これらのボックスは、ｗ１５１８２において充分に定義されている。

「ｓｇｐｄ」は、特定のサンプルグループ内のサンプルの共通のプロパティを記述するＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスである。ここで、パラメータ「ｄｅｆ＿ｓａｍｐｌｅ＿ｄｅｓｃｒ＿ｉｎｄｅｘ」は、トラックの全サンプルに当てはまるデフォルトのプロパティ：最初（かつ「ｔｒｉｆ」ボックスにおいて唯一の）を示す。

「ｔｒｉｆ」は、対象のタイルについての情報を備えるＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙボックスである。この場合、対象のタイルは値「１」のｇｒｏｕｐＩＤによって識別され、その位置及びサイズは「ｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ」、「ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔ」、「ｒｅｇｉｏｎ＿ｗｉｄｔｈ」及び「ｒｅｇｉｏｎ＿ｈｅｉｇｈｔ」によってそれぞれ定義される。予約パラメータに意味はなく、独立したフラグが、そのタイルが自己包含されるかを示す（すなわち、再構成される他のタイルを必要としない）。最後に、フルフレームパラメータは、タイルが全ピクチャをカバーする（１）か否か（０）を示す。

実施形態によると、新たなサンプル入力１５５を定義する４バイトは、ＬＨＥＶＣタイルトラックのメディアデータ又はサンプルに対応するビットストリームが、ＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ又はより具体的には「ｌｈｖＣ」ボックス１５６において以下に定義されるＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄにおいて与えられる（プロファイル、ティア及びレベルを含む）構成の下で動作するＨＥＶＣデコーダによって準拠して使用可能であることを示す。

実施形態では、４バイトは、「ｌｈｔ１」である。
この新たなサンプル入力の定義は、以下のものであればよい。
ボックスタイプ：「ｌｈｔ１」
コンテナ：ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘ（「ｓｔｓｄ」）
強制：なし
品質：ゼロ以上のサンプル入力が存在し得る

新たなサンプル入力の定義によって、それがＬＨＥＶＣタイルトラックに言及することをパーサが直ちに認識することができる。これは、既存のサンプル入力では許可されていない。
さらに、タイルトラックに関する幾つかのサンプルプロパティのみが導入され得る。

上述のように、このサンプル入力は、ＬＨＥＶＣタイルトラックのメディアサンプルを記述する。ＬＨＥＶＣタイルトラック（サンプル入力タイプ「ｌｈｔ１」）のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙの幅及び高さがトラックに含まれるＴｉｌｅ又はＴｉｌｅＳｅｔの最大幅及び高さに設定されるべきである。タイルトラックのトラックヘッダにおけるレイアウト情報（すなわち、レイヤ、タイルを位置決めするためのマトリクス、幅及び高さ）は、「ｔｂａｓ」トラック参照によって定義される関連の参照トラック（タイルベーストラックともいう）のトラックヘッダ情報に同一となり、あるいは無視されるべきである。

好ましくは、「ｌｈｔ１」サンプル記述におけるいずれの「ｃｌａｐ」（Ｃｌｅａｎ Ａｐｅｒｔｕｒｅを意味する）及び「ｐａｓｐ」（Ｐｉｘｅｌ Ａｓｐｅｃｔ Ｒａｔｉｏを意味する）ボックスは無視されるべきである。

したがって、特定のサンプル記述が、特定種の標準ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙディスクリプタであるＬＨＥＶＣタイルディスクリプタに対して作成される。

ＭＰＥＧ４ＢｉｔＲａｔｅＢｏｘ及びｅｘｔｒａ＿ｂｏｘｅｓの双方は任意である。
好ましくは、ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙは、ＬＨＥＶＣＣｏｎｇｉｒｕｇａｔｉｏｎＢｏｘ（又はＬＨＶＣＣｏｎｇｉｒｕｇａｔｉｏｎＢｏｘ若しくはレイヤードＨＥＶＣフォーマットに対して構成ボックスを指定する任意の名前）、ＨＥＶＣＣｏｎｇｉｒｕｇａｔｉｏｎＢｏｘ又はＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＢｏｘを含まない。もちろん、これらのボックスは、「ｔｂａｓ」トラック参照タイプによって示されるように、タイルベースＬＨＥＶＣタイルサンプル記述において発見される。

他の選択的ボックスも、ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙに含まれ得る。通常、入力がタイルベースＬＨＥＶＣトラックのＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘにあるので、多数の入力がＬＨＥＶＣタイルトラックのＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘにある。ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＨＥＶＣタイルトラックの公知のディスクリプタであり、ＨＥＶＣタイルトラックについての記述的情報を含む。

ＬＨＥＶＣＴｉｌｅＴｒａｃｋについてのＭＩＭＥタイプ「ｃｏｄｅｃｓ」パラメータに対するサブパラメータは、標準を規定するｗ１５１８２のアネックスＥ．３に定義される規則に従う。デコーダ構成記録が、「ｔｂａｓ」トラック参照タイプによって示されるベーストラックサンプル記述からとられる。そして、ＭＩＭＥタイプ「ｃｏｄｅｃｓ」に対するサブパラメータは、このデコーダ構成記録を用いて構成される。

好ましくは、Ｌ−ＨＥＶＣに対するコーデックサブタイプパラメータは、以下の例外とともにＨＥＶＣのものと同一である：コーデックタイプがＬＨＶＣタイルトラックの一般的なＬ−ＨＥＶＣメディアサンプル（すなわち、「ｌｈｖ１」コードポイント）を特定している場合、構成されるＨＥＶＣコーデックパラメータは付加された「．ＳＸＸ」を有すべきであり、スケーラビリティタイプを示す「Ｓ」及び「ＸＸ」はこのトラックに対するスケーラビリティマスクの値に対応するバイトである；トレイリングバイトはゼロであれば省略され得る。これは、例えばＤＡＳＨ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにおいて、関連するビデオを符号化するのに使用されるコーデックについての正確な情報を有するのに有用となり得る。例えば、マルチビューストリーミングアプリケーションにおいて、マルチレイヤＨＥＶＣデコーダを有するＤＡＳＨクライアントは、空間又は品質スケーラビリティを示すコーデックパラメータで宣言されたＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することはない。

ＭＩＭＥタイプコーデックに対するサブパラメータに関する代替の実施形態では、ｗ１５１８２において提案されるものよりも小型のＭＩＭＥタイプがＤＡＳＨにおいて有用となり得る。特に、単一のスケーラビリティタイプのトラック毎に１つのレイヤを有する構成では、すなわち、選択的なコーデックＭＩＭＥパラメータのリスト項目内のサンプル入力は、「ｓｈｖ１」、「ｓｈｅ１」、「ｍｈｖ１」、「ｍｈｅ１」、「ｌｈｖ１」又は「ｌｈｅ１」であり、同じリスト項目に更なるデータは提供されない。特に、ある単一の動作基点が公表されるので、ＢＬＩｎｔｅｒｎａｌパラメータは、Ｏｌｓｌｄｘ及びＭａｘＴｉｄパラメータと同様に任意となり得る。これによって、「ｌｈｅｖｃｐｔｌ」選択肢をスキップすること、及び例えばエンハンスメントレイヤ（スケーラブル）を「ｓｈｖ１．Ａ７．１．Ｌ１２０．Ｂ０」として宣言することが可能となる。

図３は、１以上の実施形態のステップが実施されるサーバ又はクライアントデバイス３００のブロック図を表す。

好ましくは、デバイス３００は、通信バス３０２、デバイスの電源投入に応じてプログラムＲＯＭ３０６からの命令を実行することができる中央処理装置（ＣＰＵ）３０４、及び電源投入後に主メモリ３０８からのソフトウェアアプリケーションに関する命令を備える。主メモリ３０８は、例えば、通信バス３０２を介してＣＰＵ３０４の動作領域として機能するランダムアクセスメモリ（ＲＡＭ）タイプであり、そのメモリ容量は拡張ポート（不図示）に接続された選択的ＲＡＭによって拡張され得る。ソフトウェアアプリケーションに関する命令は、例えば、ハードディスク（ＨＤ）３１０又はプログラムＲＯＭ３０６から主メモリ３０８に読み込まれ得る。そのようなソフトウェアアプリケーションによって、ＣＰＵ３０４での実行時に、図１及び２を参照して説明したカプセル化ステップがサーバにおいて実行される。

符号３１２は、デバイス３００の接続が通信ネットワーク３１４を可能とするネットワークインターフェースである。ソフトウェアアプリケーションは、ＣＰＵ３０４によって実行されると、ネットワークインターフェースを介して受信されたリクエストに反応し、データストリーム及びリクエストを他のデバイスにネットワークを介して提供するように適合される。

符号３１６は、情報をユーザに表示し及び／又はユーザから入力を受信するユーザインタフェースを表す。

ここで、変形として、マルチメディアビットストリームの受信及び送信を管理するためのデバイス３００は、図１、２及び３を参照して説明した方法を実施することができる１以上の専用集積回路（ＡＳＩＣ）からなり得る。これらの集積回路は、例えば、そして非限定的に、ビデオシーケンスを生成若しくは表示するための及び／又はオーディオシーケンスを聞くための装置に一体化される。

本発明の実施形態は、例えば対象となる特定の領域を拡大するようにＴＶのリモートコントローラとして作用するカメラ、スマートフォン又はタブレットなどのデバイスに組み込まれてもよい。それらはまた、対象となる特定エリアを選択することによってＴＶ番組の個人用の閲覧体験を有するのに同じデバイスから使用され得る。ユーザによるこれらのデバイスの他の使用は、彼／彼女の選好するビデオの選択された一部を他の接続デバイスと共有することである。それらはまた、監視カメラがこの発明の生成部に対応するものとして、監視下にある建造物の特定エリアで何が起こっているかをモニタするのにスマートフォン又はタブレットにおいても使用され得る。

当然に、局所的かつ特定の要件を満たすために、当業者は、それらの全ては、以下の特許請求の範囲によって規定される本発明の保護範囲内に依然として含まれる多数の変形及び変更を上述の解決手段に適用することができる。

Claims (51)

1. １以上のビットストリームのカプセル化から生じるカプセル化されたビットストリームからメディアデータ及びメタデータを取得する方法であって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記方法が、
   前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を取得するステップ、及び
   前記１以上のビットストリームの各々に対して少なくとも１つの動作基点ディスクリプタを取得するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップ
   を備える方法。
2. 前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている、請求項１に記載の方法。
3. 前記カプセル化ビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて受信される前記少なくとも１つの動作基点ディスクリプタを備える、請求項１又は２に記載の方法。
4. 前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する、請求項３に記載の方法。
5. 前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる、請求項４に記載の方法。
6. 前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである、請求項３から５のいずれか一項に記載の方法。
7. 前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える、請求項３から５のいずれか一項に記載の方法。
8. 少なくとも１つのレイヤディスクリプタを取得するステップをさらに備え、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する、請求項１から４、６及び７のいずれか一項に記載の方法。
9. デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される、請求項８に記載の方法。
10. デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される、請求項１から９のいずれか一項に記載の方法。
11. メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである、請求項１から１０のいずれか一項に記載の方法。
12. 前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される、請求項１から１１のいずれか一項に記載の方法。
13. １以上のビットストリームのカプセル化のためにカプセル化されるビットストリームにメディアデータ及びメタデータを提供する方法であって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記方法が、
    前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を提供するステップ、及び
    前記１以上のビットストリームの各々に対する少なくとも１つの動作基点ディスクリプタを提供するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップ
    を備える方法。
14. 前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている、請求項１３に記載の方法。
15. 前記カプセル化されるビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて送信される前記少なくとも１つの動作基点ディスクリプタを備える、請求項１３又は１４に記載の方法。
16. 前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する、請求項１５に記載の方法。
17. 前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる、請求項１６に記載の方法。
18. 前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである、請求項１５から１７のいずれか一項に記載の方法。
19. 前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える、請求項１５から１７のいずれか一項に記載の方法。
20. 少なくとも１つのレイヤディスクリプタを提供するステップをさらに備え、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する、請求項１３から１６、１８及び１９のいずれか一項に記載の方法。
21. デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される、請求項２０に記載の方法。
22. デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される、請求項１３から２１のいずれか一項に記載の方法。
23. メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである、請求項１３から２２のいずれか一項に記載の方法。
24. 前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される、請求項１３から２３のいずれか一項に記載の方法。
25. プログラム可能な装置のためのコンピュータプログラム製品であって、該コンピュータプログラム製品は、前記プログラムがプログラム可能な装置に読み込まれて実行されると、請求項１から２４のいずれか一項に記載の方法の各ステップを実行するための命令を備える、コンピュータプログラム製品。
26. 請求項１から２４のいずれか一項に記載の前記方法を実施するためのコンピュータプログラムの命令を記憶するコンピュータ可読記憶媒体。
27. １以上のビットストリームのカプセル化から生じるカプセル化されたビットストリームからメディアデータ及びメタデータを取得するデバイスであって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記デバイスが、
    前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を取得するステップ、及び
    前記１以上のビットストリームの各々に対して少なくとも１つの動作基点ディスクリプタを取得するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップ
    を実行するために構成されたプロセッサを備える、デバイス。
28. 前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている、請求項２７に記載のデバイス。
29. 前記カプセル化ビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて受信される前記少なくとも１つの動作基点ディスクリプタを備える、請求項２７又は２８に記載のデバイス。
30. 前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する、請求項２９に記載のデバイス。
31. 前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる、請求項３０に記載のデバイス。
32. 前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである、請求項２９から３１のいずれか一項に記載のデバイス。
33. 前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える、請求項２９から３１のいずれか一項に記載のデバイス。
34. 前記プロセッサがさらに、少なくとも１つのレイヤディスクリプタを取得するステップを実行するように構成され、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する、請求項２７から３０、３２及び３３のいずれか一項に記載のデバイス。
35. デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される、請求項３４に記載のデバイス。
36. デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される、請求項２７から３５のいずれか一項に記載のデバイス。
37. メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである、請求項２７から３６のいずれか一項に記載のデバイス。
38. 前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される、請求項２７から３７のいずれか一項に記載のデバイス。
39. １以上のビットストリームのカプセル化のためにカプセル化されるビットストリームにメディアデータ及びメタデータを提供するデバイスであって、前記１以上のビットストリームの各々の前記メディアデータが１以上のレイヤに編成され、各レイヤがタイムドサンプル又はサブサンプルを備え、前記デバイスが、
    前記メディアデータのタイムドサンプルの少なくとも１つのグループの少なくとも１つの定義を含むメタデータを参照するためのデータ構造体を提供するステップ、及び
    前記１以上のビットストリームの各々に対する少なくとも１つの動作基点ディスクリプタを提供するステップであって、前記少なくとも１つの動作基点ディスクリプタは、前記データ構造体によって参照されるメタデータにおいて定義されたタイムドサンプルのグループに属するタイムドサンプルが独立して復号されることを可能とする記述的情報に関するメタデータを提供し、タイムドサンプルの１つのグループに関連付けられた各動作基点ディスクリプタが、前記グループに属する前記タイムドサンプルの前記記述的情報を定義する、ステップ
    を実行するために構成されたプロセッサ備えるデバイス。
40. 前記１以上のビットストリームの少なくとも１つの前記メディアデータが複数のレイヤに編成され、該レイヤの各々が、時間スケーラビリティレベル、空間スケーラビリティレベル、ＳＮＲスケーラビリティレベル、及び／又はマルチビュー表示におけるビューに関連付けられている、請求項３９に記載のデバイス。
41. 前記カプセル化されるビットストリームが、少なくとも１つのトラック、前記データ構造体、及び前記少なくとも１つのトラックにおいて送信される前記少なくとも１つの動作基点ディスクリプタを備える、請求項３９又は４０に記載のデバイス。
42. 前記カプセル化ビットストリームが複数のトラックを備え、前記少なくとも１つのトラック以外の該複数のトラックの各トラックが前記少なくとも１つのトラックを参照する、請求項４１に記載のデバイス。
43. 前記１以上のビットストリームの各々の各レイヤが、前記複数のトラックの特定のトラックに関連付けられる、請求項４２に記載のデバイス。
44. 前記少なくとも１つのトラックが、前記データ構造体及び前記少なくとも１つの動作基点ディスクリプタを送信するための専用トラックである、請求項４１から４３のいずれか一項に記載のデバイス。
45. 前記少なくとも１つのトラックが、タイムドサンプル又はサブサンプルを備える、請求項４１から４３のいずれか一項に記載のデバイス。
46. 前記プロセッサがさらに、少なくとも１つのレイヤディスクリプタを提供するステップを実行するように構成され、前記少なくとも１つのレイヤディスクリプタが、前記１以上のビットストリームの少なくとも１つにおいてレイヤ編成に関するメタデータを提供する、請求項３９から４２、４４及び４５のいずれか一項に記載のデバイス。
47. デフォルトのレイヤディスクリプタとして、該デフォルトのレイヤディスクリプタによって提供される前記メタデータに基づいてレイヤ編成に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つのレイヤディスクリプタが定義される、請求項４６に記載のデバイス。
48. デフォルトの動作基点ディスクリプタとして、該デフォルトの動作基点ディスクリプタによって提供される前記メタデータに基づいて記述的情報に関するメタデータに関連付けられないタイムドサンプルのグループに属するタイムドサンプルが復号されるように、１つの動作基点ディスクリプタが定義される、請求項３９から４７のいずれか一項に記載のデバイス。
49. メタデータを参照するための前記データ構造体が、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘタイプのものである、請求項３９から４８のいずれか一項に記載のデバイス。
50. 前記データ構造体によって参照され、タイムドサンプルの少なくとも１つのグループの定義を含むメタデータが、国際標準化機構ベースメディアファイルフォーマットによるＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘタイプの構造において定義される、請求項３９から４９のいずれか一項に記載のデバイス。
51. 実質的に図１０及び１２を参照して上述され、図１０及び１２に図示されるメディアデータ及びメタデータを取得又は提供する方法。

Images