JP2020022187A - メディアファイルの処理装置及び処理方法 - Google Patents

Abstract

【課題】メディアデータの交換、管理、編集、およびプレゼンテーションを容易にするメディアファイルの処理装置及び処理方法を提供する。【解決手段】ファイル生成処理装置は、Ｌ−ＨＥＶＣに基づいてタイル符号化されたビデオデータに基づいて１又は複数のメディアファイルを生成する時、ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックを生成する。タイルトラックに関するメタデータは、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータを生成する。【選択図】図２

Description

本発明は、一般的には、メディアデータの交換、管理、編集、およびプレゼンテーションを容易にするフレキシブルで拡張可能なフォーマットを提供するとともに、特に圧縮されたビデオストリーム内のユーザにより選択された関心領域のＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ハイパーテキストトランスファープロトコル））およびＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（リアルタイムトランスポートプロトコル））ストリーミングに関してストリーム配信を改善するために、例えばＭＰＥＧ標準化機構により定義されたベースメディアファイルフォーマット（Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）に従う、タイムドメディアデータのカプセル化の分野に関する。特に、本発明は、特に１つ以上のタイルのデータの効率的ストリーミングまたは抽出を可能にする空間タイルなどのマルチレイヤ分割データを包含する基本ストリームをカプセル化するときにレイヤ間ディペンデンシーを符号化する方法、装置、およびコンピュータプログラムに関する。

ビデオ符号化は、ビデオ画像を送信または格納し得るように一連のビデオ画像のシリーズをコンパクトなデジタル化されたビットストリームに変換する方法である。符号化装置はビデオ画像を符号化するために使用され、関連する復号化装置はビットストリームを表示および鑑賞のために復元するために利用可能である。一般的目的は、ビットストリームを原ビデオ情報より小さいサイズであるように形成することである。このことは、ビットストリームコードを送信あるいは格納するために転送ネットワークまたは記憶装置に必要とされる容量を有利に小さくする。送信されるために、ビデオビットストリームは、一般的に、通例ヘッダおよびチェックビットを追加する伝送プロトコルに従ってカプセル化される。例えば３ＧＰＰの適応型ＨＴＴＰストリーミング（Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ（ＡＨＳ））、マイクロソフトのスムースストリーミング）あるいはアップルのＨＴＴＰライブストリーミングなどのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通してオーディオ／ビデオメディアをストリーミングするために、インターネットネットワークおよびモバイルネットワークを通してビデオストリーミングメカニズムが広く展開され使用されている。

近時、ムービングピクチャエクスパーツグループ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ））は、ＨＴＴＰを通しての既存のストリーミングソリューションを統一し、これらに取って代わる新しい標準規格を公開した。“ダイナミックアダプティブストリーミングオーバーＨＴＴＰ（Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ））と呼ばれるこの新しい標準規格は、標準的ウェブサーバに基づいてＨＴＴＰ上のメディアストリーミングモデルをサポートすることを意図していて、ここでインテリジェンス（すなわち、ストリーミングするメディアデータの選択と、ユーザの選択、ネットワーク条件、およびクライアントの能力へのビットストリームの動的適応）はもっぱらクライアントの選択肢および装置に依拠する。

このモデルでは、メディアプレゼンテーションは、データセグメントと、提示されるべきタイムドメディアデータの編成を表す“メディアプレゼンテーションデスクリプション（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ））”と呼ばれるマニフェストに編成されている。特に、マニフェストは、データセグメントをダウンロードするために使用するリソース識別子を含むとともに、妥当なメディアプレゼンテーションを得るためにこれらのデータセグメントを選択し結合するためのコンテキストを提供する。リソース識別子は、通例、ＨＴＴＰ−ＵＲＬ（ユニフォームリソースロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ））であり、場合によってはバイト範囲と組み合わされる。マニフェストに基づいて、クライアント装置は、任意の時に、そのニーズ、その能力（例えば、サポートされるコーデック、ディスプレイのサイズ、フレームレート、品質レベル、など）に応じ、ネットワーク条件（例えば、利用可能な帯域幅）に依存してメディアデータサーバからどのメディアセグメントをダウンロードするべきかを決定する。

例えばリアルタイムトランスポートプロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ））など、ＨＴＴＰに代わるプロトコルが存在することに留意するべきである。

加えて、ビデオ解像度は、標準精細度（ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ（ＳＤ））から高精細度（ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ（ＨＤ））へ、さらにウルトラハイ精細度（例えば、４Ｋ２Ｋまたは８Ｋ４Ｋ、すなわち、４，０９６×２，４００ピクセルまたは７，６８０×４，３２０ピクセルの画像を含むビデオ）まで、連続的に増大しつつある。しかし、全ての受信およびビデオ復号化装置が、特にビデオがウルトラハイ精細度のものであるときに、最大限の解像度でビデオにアクセスするためのリソース（例えば、ネットワークアクセス帯域幅またはＣＰＵ（（Ｃｅｎｔｒａｌ ＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）中央処理装置）を持っているわけではなく、全てのユーザがそのようなビデオにアクセスする必要があるわけでもない。そのような文脈においては、幾つかの関心領域（Ｒｅｇｉｏｎ−ｏｆ−Ｉｎｔｅｒｅｓｔ（ＲＯＩ））だけにアクセスする、すなわち、ビデオシーケンス全体のうちの幾つかの空間サブパーツだけにアクセスする、能力を提供することが特に有利である。

ビデオに属するフレームの空間サブパーツにアクセスする１つの公知メカニズムは、ビデオの各フレームを、一般にタイルと称される独立に復号化し得る空間エリアの配列として編成することにある。幾つかのビデオフォーマットＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（高精細度ビデオ符号化））などは、タイル定義のためのサポートを提供する。ユーザ定義されたＲＯＩは、１つまたは数個の連続するタイルをカバーすることができる。

代わりに、ユーザは、ビデオシーケンス中のピクチャの特定の細部だけに集中したければ、ＲＯＩを選択することができる。

従って、ビデオシーケンスまたはユーザが選択したＲＯＩをＨＴＴＰプロトコルに従ってストリーミングするためには、１つ以上のタイルへの空間的アクセスを可能にするとともにアクセスされるタイルの結合を可能にする仕方で符号化済みビデオビットストリームのタイムドメディアデータのカプセル化を提供することが重要である。

符号化済みビデオビットストリームは、一般に完全なフレームに対応する連続するテンポラルサンプルのセットとして構成されるＮＡＬユニット（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ（ネットワーク抽象化レイヤ））に編成され、テンポラルサンプルは復号化順序の関数として編成されるということを思い出すべきである。そのような符号化済みビットストリームをカプセル化し記述するためにファイルフォーマットが使用される。

説明のために、国際標準化機構ベースメディアファイルフォーマット（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ Ｏｒｇａｎｉｚａｔｉｏｎ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＩＳＯ ＢＭＦＦ））は、ローカル記憶またはネットワークを介してのもしくは他のビットストリーム配信メカニズムを介しての伝送のために符号化済みタイムドメディアデータビットストリームを記述する公知のフレキシブルで拡張可能なフォーマットである。このファイルフォーマットはオブジェクト指向である。それは、シーケンシャルにまたは階層的に編成されている、タイミングおよび構造パラメータなどの符号化済みタイムドメディアデータビットストリームのパラメータを定義するボックスと呼ばれるビルディングブロックから構成されている。このファイルフォーマットでは、タイムドメディアデータビットストリームは、トラックボックスと称される他のデータ構造において定義されるｍｄａｔボックスと称されるデータ構造に包含される。このトラックはサンプルのタイムドシーケンスを表し、サンプルは、単一のタイムスタンプと関連付けられた全てのデータ、すなわち単一のフレームと関連付けられた全データまたは同じタイムスタンプを共有する数個のフレームと関連付けられた全データ、に対応する。

マルチレイヤＨＥＶＣフォーマットのビデオなどのスケーラブルなビデオについては、階層化メディアデータ編成は、特定レベルのスケーラビリティでビデオをそれぞれ表す複数の依存的トラックを用いることによって効率的に表現され得る。トラック間でのデータ重複を避けるためにエクストラクタが使用され得る。１つの標準的ファイルフォーマットでは、エクストラクタは、他のネットワーク抽象化レイヤ（ＮＡＬ）ユニットを他のビットストリームから効率的に抽出することを可能にする、ビットストリームに直接含まれる特別の種類のネットワーク抽象化レイヤ（ＮＡＬ）データ構造である。例えば、エンハンスメントレイヤトラックのビットストリームは、ベースレイヤトラックからＮＡＬユニットを参照するエクストラクタを含むことができる。後に、そのようなエンハンスメントレイヤトラックがファイルフォーマットから抽出されるとき、エクストラクタは自分たちが参照しているデータにより取って代わられなければならない。

下位情報を記述し、この下位情報へのアクセスを容易にし、あるいはビットストリームを複数のセグメントに効率的に編成するためにＩＳＯ ＢＭＦＦを用いてこれらのメカニズムを埋め込むとき、幾つかの方策が採用され得る。

例えば、“Ｈ．２６４／ＳＶＣの適応型ＨＴＴＰストリーミングに関するＩＳＯベースメディアファイルフォーマットの示唆（Ｉｍｐｌｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ ｏｎ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ ｏｆ Ｈ．２６４／ＳＶＣ）”と題された論文において、著者のコフラー他（Ｋｏｆｌｅｒ ｅｔ ａｌ．）はＩＳＯ ＢＭＦＦの可能性および限界を考慮してＨＴＴＰストリーミングのためのスケーラブルなビデオビットストリーム（Ｈ２６４／ＳＶＣ）を編成するための３つの異なる方策を提示している。

ａ）ファイルタイプボックス“ｆｔｙｐ”と、全てのＩＳＯ ＢＭＦＦメタデータ（トラック定義を含む）を包含するムービーボックス“ｍｏｏｖ”とを含む特定のファイルヘッダを包含する単一のファイル。この単一のファイルは、符号化済みビットストリーム全体を包含する単一のｍｄａｔボックスも含む。この編成は、ローカル記憶には適するけれども、クライアントがビットストリーム全体のうちの一部分を必要とするだけであるかもしれないＨＴＴＰストリーミングには適合していない。このような編成は、好ましくは、ビットストリームが複数のセグメントに分割されるときには初期化ファイルとして使用されるファイルのために使用される。その編成がｂ）で定義される他の１つの単一ファイルがこの初期化ファイルの後に続く。この初期化ファイルは全セグメントに関する情報を収集する。

ｂ）フラグメンテーションに適する複数のｍｏｏｆ／ｍｄａｔボックスを包含する単一のファイル。ｍｏｏｆ／ｍｄａｔの各カップルは、ビットストリームの複数のセグメントのうちの１つに関連する。このフォーマットは、漸進的ダウンロードに配慮している。より詳しくは、ｍｏｏｆボックスはフラグメントレベルでｍｏｏｖボックスと同等である。この方式では、分割されたメディアファイルを用いて、スケーラブルなビットストリームは、異なるスケーラビリティレベルでビデオを表す複数の依存的トラックに分割され得る。エクストラクタは、他の１つまたは複数のトラックからのＮＡＬユニットを参照するために使用される特別のＮＡＬユニットである。タイル当たりに１トラックが使用される場合、全てのアドレス可能トラックは前もって準備されなければならず、トラックは独立して選択されることはできない。数個のタイルが表示されるべきであるならば、数個のビットストリームが復号化されなければならず、ベースレイヤは数回復号化される。ｃ）で記載される最後の編成は、各トラックの独立選択に特に適する。

ｃ）複数のセグメントファイル。各ファイルは、それ自身のＵＲＬによりアクセス可能であるとともに独立してダウンロード可能である。各ファイルは１つのフラグメントに関連付けられ、複数のセグメントファイルは好ましくは専用の初期化ファイルに先行される。各セグメントは、通例、一種のファイルヘッダとして作用するセグメントタイプボックス（ｓｔｙｐ）、任意のセグメントインデックスボックス（ｓｉｄｘ）および１つまたは複数のフラグメントから成る。さらに、各フラグメントはｍｏｏｆボックスおよびｍｄａｔボックスから成る。この方式では、分割されたメディアファイルを用いて、各トラックは、スケーラビリティの１つのレベルと関連付けられた関連するビットストリームと共にそれ自身のセグメントに格納される。必要ならば、依存的トラックから所要のビットストリームを参照するためにエクストラクタが使用される。このような符号化方式は、トラックを独立にストリーミングするために特に適する。それは、ＤＡＳＨ標準規格には良く適合しているけれども、数個のビットストリームを復号化せねばならず、従ってトラック当たりに１つのデコーダが必要なので、タイルストリーミングには適していない。さらに、２つ以上のタイルを選択するときにベースレイヤのビットストリームの重複があり得る。

文書“ＨＥＶＣおよびＭＶＣ＋ＤのＩＳＯ／ＩＥＣ１４４９６−１５ ２０１３／ＡＭＤ１エンハンストサポートのＷＤ３（ＷＤ３ ｏｆ ＩＳＯ／ＩＥＣ１４４９６−１５ ２０１３／ＡＭＤ１ Ｅｎｈａｎｃｅｄ ｓｕｐｐｏｒｔ ｏｆ ＨＥＶＣ ａｎｄ ＭＶＣ＋Ｄ）、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１、Ｗ１４３２８、２０１４年３月〜４月、バレンシア、スペイン”（以下では“ｗ１４３２８”と称される）に関連して行われた上記ボックスの定義およびこれらのボックスに含まれるサブボックスの定義は、ＩＳＯ ＢＭＦＦメタデータの編成を複雑であまり効率的でない編成とするであろう。

さらに、タイルトラックは階層化ＨＥＶＣのために適切に定義されていなくて、その使用を制限している。

これらの問題を解決するために、マルチレイヤビデオストリームのために階層化ＨＥＶＣにおいて空間タイルを処理するために特に適する効率的なデータ編成およびトラック記述方式が提供される。これは、ＩＳＯ ＢＭＦＦ構文解析の結果がより効率的で階層化ＨＥＶＣに適合することを保証する。

これらの制約に直面して、本発明者たちは、マルチレイヤタイルドタイムドメディアデータをサーバにおいてカプセル化し、複数のメディアセグメントファイルにカプセル化されたマルチレイヤタイルドタイムドメディアデータからタイムドメディアデータビットストリームを提供する方法および装置を提供する。

上記の従来技術の欠点を改善することは本発明の広範な目的である。

本発明の第１の態様に従って、 Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に基づいてタイル符号化されたビデオデータに基づいて１又は複数のメディアファイルを生成する処理装置は、前記ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックを生成するトラック生成手段と、前記トラック生成手段により生成されるタイルトラックに関するメタデータを生成するメタデータ生成手段であって、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、前記タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータを生成するメタデータ生成手段と、前記トラック生成手段により生成されたタイルトラックと前記メタデータ生成手段により生成されたメタデータとに基づく１又は複数のメディアファイルを生成するファイル生成手段とを有することを特徴とする。

本発明はソフトウェアにおいて実装され得るので、本発明は任意の適切なキャリヤ媒体でプログラマブルな装置に提供されるコンピュータ可読コードとして具体化され得る。有形のキャリヤ媒体は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードディスクドライブ、磁気テープ装置またはソリッドステート記憶装置などの記憶媒体を含み得る。過渡的キャリヤ媒体は、電気信号、電子信号、光信号、音響信号、磁気信号または電磁信号、例えばマイクロウェーブもしくはＲＦ信号、などの信号を含み得る。

本発明のさらなる利点は、図面および詳細な説明を検討すれば当業者にとって明らかとなるであろう。追加の利点がここに組み込まれることが意図されている。

ここで本発明の実施態様が、単なる例として、次の図面と関連して記述されるであろう。

階層化ＨＥＶＣのための本発明に従うトラックボックスを表す実施態様を示す。 タイルド階層化ＨＥＶＣのための本発明に従うトラックボックスを表す実施態様を示す。 １つ以上の実施態様が実装され得るサーバまたはクライアント装置のブロック図を表す。

以下の３つのパートは３つの異なる特徴、それぞれのピクチャの空間編成（パートＡ）、ＮＡＬユニット（パートＢ）、およびＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙと称される特別のディスクリプタ（パートＣ）、に関する周知の情報を記載する。これらの特徴は、図１から３に表されている実施態様をより良く理解してもらうためにここに記載される。

パートＡ
ビデオは、好ましくはスケーラブルなビデオまたはマルチビュービデオであって、種々のレベルのスケーラビリティ／ビューに編成される。

１つの特定の実施態様では、タイムドサンプル（例えば画像）を含むマルチレイヤタイルドタイムドメディアデータ（例えばスケーラブルタイルドビデオデータまたはマルチビュータイルドビデオデータ）などのマルチレイヤ分割タイムドメディアデータは、数個のタイムドメディアデータトラック、通例ベーストラックおよびタイルトラック、のセットとして送信される。なお１つの特定の実施態様では、ベーストラックはベースレイヤベーストラックおよび少なくとも１つのエンハンスメントレイヤベーストラックを含む。追加のタイルトラックはベースレイヤタイルトラックおよび／またはエンハンスメントレイヤタイルトラックであり得る。各タイムドメディアデータトラックは、数個のタイムドサンプルの１つの空間サブサンプル（例えば数個のＮＡＬユニット）を含む。各ビデオフレーム（タイムドサンプル）は、そのビデオフレームの空間サブパート（空間サブサンプル）に対応する独立して復号化可能なタイルから構成され得る。階層化ＨＥＶＣでは、各ビデオフレームは、そのビデオフレームの空間サブパート（空間サブサンプル）に対応する依存的に復号化可能なレイヤから構成され得る。さらに階層化ＨＥＶＣでは、各ビデオフレームは依存的に復号化可能なレイヤから構成されることができ、各レイヤはそのビデオフレームの空間サブパート（空間サブサンプル）に対応する独立して復号化可能なタイル（所与のレイヤのための）から構成されることができる。

トラックディペンデンシー（タイリング、レイヤ間および／またはレイヤ内ディペンデンシー）を記述するためにリストが使用される。タイムドメディアデータトラックのこのようなセットは、マルチレイヤ空間ビデオタイルの選択、組み立て、および効率的ストリーミングを可能にする。各トラックは、メディアセグメントファイルのセットとしてサーバ装置からクライアント装置へ送信され得る。初期化セグメントファイルは、メディアセグメントファイルを復号化するために必要とされるメタデータを送信するために使用され得る。

本発明の一実施態様は、例えば、ＨＥＶＣまたは階層化ＨＥＶＣ（ＬＨＶＣまたはマルチレイヤＨＥＶＣとしても周知されている）として周知されているビデオフォーマットに適用され得る。

ＨＥＶＣ標準規格では画像を空間的にタイル、スライス、およびスライスセグメントに分割し得ることを思い出していただきたい。この標準規格では、タイルは水平境界および垂直境界（すなわち行および列）により画定される画像の矩形領域に対応する。それは整数個の符号化ツリーユニット（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ（ＣＴＵ））を含む。従って、タイルは、例えば関心領域のための位置およびサイズを定義することによって関心領域を特定するために効率的に使用され得る。しかし、ＨＥＶＣビットストリームの構造およびネットワーク抽象化レイヤ（ＮＡＬ）ユニットとしてのそのカプセル化は、タイルと関連して編成されてはいなくて、スライスに基づいている。

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

スライスセグメントは、整数個の（ラスタースキャン順に）連続する符号化ツリーユニットを包含する。従って、スライスセグメントは、矩形または非矩形であり得るので、これは関心領域を表すのに適していない。それはＨＥＶＣビットストリームにおいて、スライスセグメントデータが追随するスライスセグメントヘッダを得るために符号化される。独立スライスセグメントと依存的スライスセグメントとの違いは、それらのヘッダにある。なぜならば、依存的スライスセグメントは独立スライスセグメントに依存し、そのヘッダの情報の量は独立スライスセグメントのそれより少ない。独立スライスセグメントおよび依存的スライスセグメントの両方が、タイルを画定するためにまたはエントロピー復号化同期ポイントとして使用される、対応するビットストリーム内のエントリーポイントのリストを包含する。

ＨＥＶＣ標準規格では、スライスセグメントは、次のように要約され得る規則に従ってタイルにリンクされる（一方または両方の条件が満たされなければならない）：
− スライスセグメント内の全てのＣＴＵは同じタイルに属する（すなわち、スライスセグメントは数個のタイルに属することはできない）；および
− タイル内の全てのＣＴＵは同じスライスセグメントに属する（すなわち、タイルは数個のスライスセグメントに、これらのスライスセグメントの各々がそのタイルだけに属することを条件として、分割され得る）。

パートＢ
上記のように、タイルは関心領域のための適切なサポートとみなされ得るが、スライスセグメントは、実際に通信網を通して運ばれるべくＮＡＬユニット内に置かれ、アクセスユニット（すなわち、ファイルフォーマットレベルにおける符号化済みピクチャまたはサンプル）を形成するために集められるものである。

ＨＥＶＣ標準規格では、ＮＡＬユニットのタイプは次のように定義され得るＮＡＬユニットヘッダの２バイトに符号化されることを思い出すべきである。

［数１］
ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ（） ｛
ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ
ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ
ｎｕｈ＿ｌａｙｅｒ＿ｉｄ
ｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１
｝
スライスセグメントを符号化するために使用されるＮＡＬユニットは、スライスセグメントアドレスシンタックスエレメントのおかげでスライスセグメント内の第１ＣＴＵのアドレスを示すスライスセグメントヘッダを含む。そのようなスライスセグメントヘッダは次のように定義され得る。

［数２］
ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ（） ｛
ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ
ｉｆ（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ ＞＝ ＢＬＡ＿Ｗ＿ＬＰ ＆＆ ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＜＝ ＲＳＶ＿ＩＲＡＰ＿ＶＣＬ２３）
ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ
ｓｌｉｃｅ＿ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ
ｉｆ（！ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ）｛
ｉｆ（ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）
ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｆｌａｇ
ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ａｄｄｒｅｓｓ
｝
Ｉｆ（！ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｆｌａｇ）｛［…］
タイリング情報は、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ピクチャパラメータセット））ＮＡＬユニットにおいて提供される。スライスセグメントとタイルとの関係は、これらのパラメータから演繹され得る。

空間的予測は境界で（定義により）リセットされるけれども、タイルが１つまたは複数の参照フレーム内の異なるタイルからの時間予測値を使用することを妨げるものは何もない。従って、独立のタイルを構築するために、予測ユニットのための動きベクトルは、１つまたは複数の参照フレーム内の一緒に置かれているタイル内に留まるために、符号化中、タイルの中に拘束されるのが有利である。さらに、ループ内フィルタ（デブロッキングフィルタおよびサンプルアダプティブオフセット（ｓａｍｐｌｅ ａｄａｐｔｉｖｅ ｏｆｆｓｅｔ（ＳＡＯ））フィルタ）は、唯一のタイルを復号化するときにエラードリフトが導入されないようにタイル境界で非アクティブ化されるのが好ましい。ループ内フィルタのそのような制御はＨＥＶＣ標準規格において利用可能であるということに留意するべきである。それは、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇとして知られているフラグと共にスライスセグメントヘッダ内にセットされる。このフラグを明示的にゼロにセットすることにより、タイル境界にあるピクセルは、隣のタイルの境界に接するピクセルに依存できなくなる。動きベクトルおよびループ内フィルタに関連するこれら２つの条件が満たされたとき、タイルは“独立して復号化可能なタイル”または“独立タイル”とみなされ得る。

パートＣ
ＭＰＥＧ−４パート１２標準規格の現存するサンプルグループ化メカニズムは、タイルをカプセル化するために使用され得る。従って、特別の種類の標準的ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙディスクリプタであるタイルディスクリプタを用いて特別のサンプルグループ記述が作成される。サンプルグループ化メカニズムは、トラック内のサンプルのパーティションを表現するために使用される。それらは、２つのボックスすなわち：サンプルのサンプルグループへの割り当てを記述するＳａｍｐｌｅＴｏＧｒｏｕｐボックス（‘ｓｂｇｐ’）および特定のサンプルグループ内のサンプルの共通特性を記述するＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス（‘ｓｇｐｄ’）、の使用に依拠する。１つの特定のタイプのサンプルグループ化は、タイプフィールド（‘ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ’）を介しての１つのＳａｍｐｌｅＴｏＧｒｏｕｐボックスおよび１つのＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスの結合によって定義される。多様なサンプルグループ化インスタンス（すなわち、ＳａｍｐｌｅＴｏＧｒｏｕｐボックスおよびＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスのペア）が様々なグループ化基準に基づいて存在し得る。

サンプルのタイリングに関連する特定のグループ化基準が使用される。‘ｔｒｉｆ’と称されるこの特定のグループ化タイプは、タイルの特性を記述し、標準的ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙから導出される。それはＴｉｌｅＲｅｇｉｏｎＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙと称されることができて、次のように定義される：

［数３］
ｃｌａｓｓ ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙ（） ｅｘｔｅｎｄｓ ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙ（‘ｔｒｉｆ’） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｇｒｏｕｐＩＤ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（２） ｉｎｄｅｐｅｎｄｅｎｔ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（６） ｒｅｓｅｒｖｅｄ＝０；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔ；ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｒｅｇｉｏｎ＿ｗｉｄｔｈ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｒｅｇｉｏｎ＿ｈｅｉｇｈｔ；
｝
この特定のタイプのグループエントリに従って、パラメータｇｒｏｕｐＩＤは、そのグループにより記述されるタイルのための一意の識別子である。パラメータｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔおよびｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔは、それぞれ、タイルにより表される矩形領域の左上ピクセルの、ＨＥＶＣフレームの左上のピクセルに対する水平オフセットおよび垂直オフセットをベース領域のルマサンプル（ｌｕｍａ ｓａｍｐｌｅ）単位でセットするために使用される。パラメータｒｅｇｉｏｎ＿ｗｉｄｔｈおよびｒｅｇｉｏｎ＿ｈｅｉｇｈｔは、それぞれ、タイルにより表される矩形領域の幅および高さをＨＥＶＣフレームのルマサンプル単位でセットするために使用される。

パラメータｉｎｄｅｐｅｎｄｅｎｔは、独立タイルの定義に関連して上で記載されたように、そのタイルが同じタイルのみに属するサンプルに関連する復号化ディペンデンシーを含むことを明示する２ビットワードである。説明のために、タイル編成を記述するためのＳＥＩメッセージ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ（補助的エンハンスメント情報））の標準的使用に関連して、ｔｉｌｅ＿ｓｅｃｔｉｏｎ＿ｅｘａｃｔ＿ｍａｔｃｈ＿ｆｌａｇとして知られているフラグは、その意味が次の通りにセットされ得るｉｎｄｅｐｅｎｄｅｎｔフラグの値をセットするために使用され得る。

− もしパラメータｉｎｄｅｐｅｎｄｅｎｔが０に等しければ、このタイルと同じフレームまたは前のフレーム内の他のタイルとの間の符号化ディペンデンシーはタイルセットレベルで記述されるかまたは不明である。

− もしパラメータｉｎｄｅｐｅｎｄｅｎｔが１に等しければ、このタイルと任意の参照フレーム内の異なるｇｒｏｕｐＩＤを有する他のタイルとの間にテンポラル符号化ディペンデンシーは無いけれどもこのタイルと参照フレーム内の同じｇｒｏｕｐＩＤを有するタイルとの間に符号化ディペンデンシーが存在し得る。

− もしパラメータｉｎｄｅｐｅｎｄｅｎｔが２に等しければ、このタイルと同じフレーム内の他のタイルとの間に符号化ディペンデンシーは無く、このタイルと参照フレーム内の他のどのタイルとの間にも符号化ディペンデンシーは無い。

ｉｎｄｅｐｅｎｄｅｎｔパラメータ値３は、取っておかれている。

各タイルの特性は、各タイルトラックについて、‘ｔｒｉｆ’ｇｒｏｕｐｉｎｇ＿ｔｙｐｅおよびＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを有する１つのＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス（‘ｓｇｐｄ’）を定義することによってムービーヘッダ（‘ｍｏｏｖ’ボックス）において一度与えられる。タイル特性はトラックフラグメントごとにも定義され得る。このようなｍｐ４トラックは、ビデオタイルトラックまたはタイルトラックとして定義され得る。ＨＥＶＣ標準規格では、ＨＥＶＣタイルトラックは、このトラック内の１つまたは複数のタイルが属するＨＥＶＣレイヤの他のＮＡＬＵ（通例、種々のパラメータセットなどのセットアップ情報）を運ぶＨＥＶＣトラックへの参照がそれについて存在するところのビデオタイルトラックである。その参照は、タイルベーストラックを示すために、‘ｓｂａｓ’４文字符号、あるは‘ｔｂａｓ’などのもっと詳細なもの、などのＭＰＥＧ−４パート１５標準規格において既に定義されている値を使用することができる。

１つのタイルトラックは、唯一のＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙおよび０個のＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙを有するか、または、唯一のＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙおよび１つ以上の、それからこのタイルセットが作られるところの依存的ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを有しなければならず、ＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙは、タイルのセットを記述するためのＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙのエクステンションである。これらのグループの各々に、１つのＮＡＬＵを１つのグループに関連付けるために使用され得る一意の識別子が割り当てられることに留意するべきである。タイル領域およびタイルセットは、‘ｔｂａｓ’トラック参照により示されるように、ベースＨＥＶＣレイヤにより算定される、ｇｒｏｕｐＩＤのための同じネーム空間を共有する（すなわち、同じベースレイヤを有するどのトラックにおいても同じｇｒｏｕｐＩＤを有する２つのタイル領域またはタイルセットがあってはならない）。

ここで新種のトラック、タイルトラック、を導入することは、ファイルフォーマット（Ｆｉｌｅ Ｆｏｒｍａｔ）デザインに準拠するために対応するサンプルエントリを定義することを意味する。実際には、各トラックは、その記述データの中に、必須のＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘ（‘ｓｔｓｄ’）を伴うＳａｍｐｌｅＴａｂｌｅＢｏｘ（‘ｓｔｂｌ’）を包含しなければならない。サンプル記述テーブルは、使用された符号化タイプに関する詳しい情報、および、トラックサンプルの復号化に必要な初期化情報を与える。ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘに格納される情報は、トラック特有であり、ビジュアルサンプルエントリのために抽象記述を特殊化することによってビデオトラックのために記述される。通例、ビジュアルサンプルエントリは、サンプルを処理するために使用される圧縮フォーマットデコーダを提供する“符号化名称”パラメータを包含する。このパラメータは、４文字符号として符号化される一意の識別子でなければならない。タイルトラック内に挿入されるサンプルを記述するために、次に私たちはこれらのサンプルを特別の種類のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙで記述しなければならない。タイルトラックのサンプルを処理するためにタイルケイパビリティを有するＨＥＶＣデコーダが必要であることを示すために、例えば符号‘ｈｖｔ１’により表されるＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが導入される。普通、サンプル記述テーブルには、デコーダ設定情報を提供するためにＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘがパラメータとして含まれる。ＨＥＶＣタイルトラックの特別の場合に関して、私たちは、設定ボックスを繰り返さず、トラックヘッダ内のトラック参照タイプ‘ｔｂａｓ’で示されるタイルベーストラックに記述されるものを継承する。任意に、タイルごとの平均ビットレートを記述するパラメータは、プロファイル、階層およびレベル情報と同じくＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙにセットされ得る。プロファイルは、通例アプリケーションドメインをターゲットとして、特徴の見地から標準規格のサブセットを定義する。各プロファイルは階層およびレベルを定義する。階層は入れ子にされた複雑さレベルとみなされることができ、各レベルは、ピクセルの数、スライスの数、タイル・・・のような幾つかの値のための限界を定める。複雑さが増す順に編成されて、プロファイルにおいて所与のレベルにある最高の階層を処理し得るデコーダは、同じプロファイルにおいて同じレベルかまたは下にあるより下位の任意の階層をサポートし得るであろう。帯域幅に基づく適応化のためにストリーミングしているクライアントに提供されるように、タイルごとのビットレート情報をこのボックスに格納することは有益であり得る。ｍｐ４ボックスの大部分に関しては、アプリケーション特有のニーズに調和するようにオプションの特別なボックスでＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙボックスが拡張され得る。

図１はＭＰＥＧ−４ファイルフォーマットに従う２つのスケーラビリティレイヤをカプセル化することの例を示す。図示されているように、各レイヤ（エンハンスメントレイヤＥＬおよびベースレイヤＢＬ）はそれ自身のトラックにカプセル化され、効率的なデータアドレッシングを可能にするとともにビデオの２つのトラックとしてのカプセル化をもたらす。

より正確には、図１は、マルチレイヤＨＥＶＣビットストリームに符号化されていてＳ個のサンプルを包含するメディアデータシーケンスのための全てのＩＳＯ ＢＭＦＦメタデータを包含するムービーボックス“ｍｏｏｖ”１００を表している。同じ原理が、ムービーフラグメントと共にまたはページ３のｂ）およびｃ）において定義されているセグメントとしてカプセル化されるメディアデータにも当てはまる。

単一の“ｍａｄａｔ”ボックス１０１は、２つのチャンク、すなわちベースレイヤのための１つのチャンク１０２およびエンハンスメントレイヤのための１つのチャンク１０３、に編成された符号化済みビットストリーム全体を包含し、各チャンクはＳ個のサンプル１０４、１０５を含む。エンハンスメントレイヤＥＬについて、チャンクＥＬ１０３は、Ｓ個のサンプルのための符号化済みビットストリームの対応する部分を含む。各サンプルは１つ以上のＮＡＬユニットに編成されている。さらに、ベースレイヤチャンク内の対応する部分を参照するためにエクストラクタ１０６を含めるための部分の先頭に特別のＮＡＬユニットが付加される。最後に、エンハンスメントレイヤチャンクは、パラメータを例えばピクチャレベル（ＰＰＳ）またはシーケンスレベル（ＳＰＳ）などの所与の“ｘ”レベルで定義するための種々のパラメータセット（“ｘＰＳ”１０７として要約されている）を含む。

“ｍｏｏｖ”ボックス１００は２つのボックス“ｔｒａｃｋ”、すなわち、もっぱらベースレイヤトラックのための１つ１１０（ベースレイヤカプセル化から生じる）およびもっぱらエンハンスメントレイヤトラックのための１つ１３０（エンハンスメントレイヤカプセル化から生じる）、を含む。

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

ベースレイヤトラック１１０は、シーケンシャルにまたは階層的に編成された、ビットストリームの符号化済み上記符号化済み部分のパラメータを定義する数個のボックスを含む。明瞭性を目的として、選ばれたボックスだけが図１に示されている。

トラックヘッダ１１１のための‘ｔｋｈｄ’という名前のボックスまたはサブボックスは、時間情報、空間情報および識別情報を含む。時間情報は、Ｓ個のサンプルの作成時間および改変時間に関係する（ｃｒｅａｔｉｏｎ＿ｔｉｍｅ、ｍｏｄｉｆｉｃａｔｉｏｎ＿ｔｉｍｅ）。ここで“ＢＬ”に等しい識別子（ｔｒａｃｋ＿ＩＤ）は、トラックを識別することを可能にする。空間情報は、ベースレイヤの表示サイズ情報（幅および高さ）を含む。

‘ｍｄｉａ’１１２という名前の他の１つのボックスまたはサブボックスは、メディア情報記述ボックスであって、ビットストリームのＳ個のサンプルに関連するメディアデータに関する情報を含む。

‘ｍｄｉａ’ボックスは、明瞭性を目的として表されていない幾つかのヘッダボックスと、記述情報自体を包含するメディア情報ボックス‘ｍｉｎｆ’１１３とを含む。この例では、‘ｍｉｎｆ’ボックスは３個の異なるボックスまたはサブボックスに細分されている。

第１のボックスまたはサブボックス‘ｏｉｎｆ’１１４は、レイヤおよびサブレイヤ（例えばテンポラルサブレイヤ）ならびにそれらの、オペレーションポイント、それらの間のディペンデンシー（もしあるならば）、オペレーションポイントのためのＨＥＶＣビットストリームのＶＰＳに包含されるプロファイル、階層およびレベル情報を表すｐｒｏｆ＿ｔｉｅｒ＿ｌｅｖｅｌパラメータを構成する編成などのオペレーションポイント情報を包含する。より詳しくは、ボックス‘ｏｉｎｆ’は、スケーラビリティ構造、レイヤの数、ここでは２個（ｍａｘ＿ｌａｙｅｒ＿ｃｏｕｎｔ＝２）、に関する情報を与えるパラメータ（（ｓｃａｌａ＿ｍａｓｋ）を含むとともに、各レイヤのために、識別子、プロファイル／階層およびレベル情報により、さらにこのオペレーションポイントを構成するレイヤのセットにより各々記述される、ファイル内のオペレーションポイントの数が後に続く依存的レイヤのリストを含む。

サンプルテーブルボックス（Ｓａｍｐｌｅ Ｔａｂｌｅ Ｂｏｘ）のための‘ｓｔｂｌ’）ボックス１１５という名前の第２のボックスまたはサブボックスは、サンプルを記述する情報を包含する。高効率ビデオ符号化（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ））方法に関する情報の一部分は、サンプル記述ボックス（Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｂｏｘ）のための‘ｓｔｓｄ’ボックス１１６またはサブボックスに含まれている。パラメータ“ｅｎｔｒｙ＿ｃｏｕｎｔ”は、唯一の（ビジュアル（Ｖｉｓｕａｌ））サンプルエントリ（Ｓａｍｐｌｅ Ｅｎｔｒｙ）が含まれていることを示す。４バイトの‘ｈｖｃ１’は、考慮されているメディアデータに対応するビットストリームが、下で‘ｈｖｃＣ’ボックス１１７において定義されているＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄにおいて与えられる設定（プロファイル、階層、およびレベルを含む）の下で動作するＨＥＶＣデコーダに準拠しデコーダにより使用可能である、ということを示す。この例では、バージョン設定は第１のもの（ｃｏｎｆｉｇＶｅｒｓｉｏｎ＝１）である。ＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄは、ＨＥＶＣビットストリームのビデオパラメータセット（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）に包含されるプロファイル、階層およびレベル情報をも与える。

‘ｔｃｏｎ’１１８という名前の第３のボックスまたはサブボックスは、トラックで運ばれる全てのレイヤおよびサブレイヤをリストし、ここでは１つだけである（ｎｕｍ＿ｌａｙｅｒ＝１）。取っておかれるパラメータ（ｒｅｓｅｒｖｅｄ ｐａｒａｍｅｔｅｒ）は、ボックスのさらなる進化のために常に０値を有する。

１つの好ましい実施態様では、‘ｏｉｎｆ’ボックスおよび／または‘ｔｃｏｎ’ボックスは任意であり、その任意性はイタリック体の使用によって信号される。例えば、唯一のエンハンスメントレイヤが存在するとき、２つの上記ボックス‘ｏｉｎｆ’１１４および‘ｔｃｏｎ’１１８（あるいは、これらのボックスのうちの１つだけ）はファイル内に存在しない。実際、レイヤを運ぶトラック内に、特にサンプル記述ボックス内に、エンハンスメントレベルのため全ての階層／プロファイル／レベル情報が含まれるであろうからオペレーションポイント情報は有益でないということが指摘されている。従って‘ｏｉｎｆ’ボックスおよび／または‘ｔｃｏｎ’は必須ではない。

レイヤの編成に関連する他の情報は、種々のサンプルエントリと同様に任意であってよい：‘ｓｈｖ１’、‘ｓｈｅ１’、‘ｓｈｖＣ’およびスケーラブルなＨＥＶＣだけのための４文字符号ならびに‘ｍｈｖ１’、‘ｍｈｅ１’、‘ｍｈｖＣ’およびマルチビューＨＥＶＣサンプルエントリだけのための４文字符号。１種または２種のサンプルエントリだけが維持され得る：例えば‘ｌｈｖ１’、‘ｌｈｖＣ’または‘ｌｈｅ１’、あるいは階層化ＨＥＶＣサンプルエントリを記述する４文字符号。

他のトラックはエンハンスメントレイヤ１３０のために専用される。それは、ｔｒａｃｋ＿ＩＤがエンハンスメントレイヤのための“ＥＬ”であることを除いて、ベースレイヤトラックの‘ｔｋｈｄ’ボックスと類似するトラックヘッダボックス‘ｔｋｈｄ’１３１またはサブボックスを含む。

エンハンスメントレイヤのためのトラックはトラック参照ボックス（Ｔｒａｃｋ Ｒｅｆｅｒｅｃｅ Ｂｏｘ）‘ｔｒｅｆ’１３２またはサブボックスを含む。それは、プレゼンテーションにおける、ここではエンハンスメントレイヤトラックである包含するトラックから、ここではベースレイヤトラックである他の１つのトラックへの、参照を提供する。

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

他の１つの参照‘ｏｒｅｆ’は、ここではベースレイヤトラックに置かれている‘ｏｉｎｆ’ボックスへの参照を可能にする。‘ｏｒｅｆ’参照は、イタリック体を用いることにより書かれる。実際以下で説明されるように、‘ｏｉｎｆ’ボックスがベースレイヤトラック内に存在しないことを前提として、もし参照レイヤが１つだけ存在するならば、‘ｏｒｅｆ’参照は任意であってよい。

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

この‘ｌｈｖｃ’ボックスは、以下でより詳しく記載される。

最後にベースレイヤトラックに関して‘ｍｄｉａ’ボックスは任意の‘ｔｃｏｎ’ボックス１３８を含む。

上で言及された好ましい実施態様に従って、予め定められた条件（例えば、１つだけのエンハンスメントレイヤ）に基づいて、‘ｔｒｅｆ’ボックス内の‘ｏｒｅｆ’参照を介しての‘ｏｉｎｆ’ボックスへの参照に関しては‘ｔｃｏｎ’ボックスはトラックから除去され得る。

より一般的には、もしベースレイヤを意味する各レイヤおよび数個のエンハンスメントレイヤのうちの各レイヤが別のトラックにカプセル化されるならば‘ｏｉｎｆ’ボックスおよび‘ｔｃｏｎ’ボックスは任意である。実際、代表的な設定では１つのレイヤが１つのオペレーションポイントに対応するとき、これらのボックスは有益な情報を何ら提供しない：‘ｔｃｏｎ’ボックスはトラック内に１つのレイヤがあることを示すだけであり、‘ｏｉｎｆ’は各トラックを記述するであろう（トラックは、それ自体がオペレーションポイントに合うレイヤに合うから）。‘ｏｉｎｆ’ボックス内に見出されるプロファイル／階層／レベル情報は、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄから直接読まれ得る。同様に、依存的レイヤ（すなわち、この場合にはトラック）のリストは、トラック参照ボックス（Ｔｒａｃｋ Ｒｅｆｅｒｅｃｅ Ｂｏｘ）を介して見出され得る。‘ｏｉｎｆ’ボックスおよび‘ｔｃｏｎ’ボックスは、数個のレイヤのカプセル化から１つのトラックがもたらされるときに有益であるにすぎないであろう。

他の１つの好ましい実施態様では、共通の‘ｓｂａｓ’トラック参照を有するトラックのセットについて、‘ｏｉｎｆ’ボックスを運ぶトラックがこのセットの中に高々１つ存在する。もし‘ｏｉｎｆ’ボックスが存在するならば、共通の‘ｓｂａｓ’被参照トラックを有する全てのトラックは、‘ｏｒｅｆ’タイプのトラック参照を用いることによって‘ｏｉｎｆ’ボックスを運ぶトラックにリンクされなければならない。

‘ｌｈｖＣ’ボックスは、ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘという名前のインデックスを含む。このフィールドは、オペレーションポイント情報ボックス‘ｏｉｎｆ’が存在するときにこのボックスにおいて文書化されるオペレーションポイントのインデックスを信号する。オペレーションポイントは、サブビットストリーム抽出プロセスにより得ることのできるＬ−ＨＥＶＣビットストリームの部分を表す。どの有効なオペレーションポイントも、他のオペレーションポイントと無関係に復号化され得る。

１つの好ましい実施態様では、ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘは、ｏｉｎｆボックスに記述されているオペレーションポイントの１−ベースのインデックスであるか（ここではエンハンスメントレベルのために‘２’）、あるいは不明であるかもしくは明示されていない場合には０でなければならない。

他の１つの実施態様では、デコーダ設定情報に関して、ベーストラックがＨＥＶＣで符号化されるか否かを示すｈｅｖｃ＿ｂａｓｅｌａｙｅｒ＿ｆｌａｇと称されるフィールドがある（ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（アドバンストビデオ符号化））フォーマットの頂部に階層化ＨＥＶＣが使用され得る）。この情報はトラック参照から見いだされ得る：もし‘ｓｂａｓ’参照により参照されたトラックがＨＥＶＣトラックでなければ、ベースレイヤはＨＥＶＣではない。このフラグは、他の１つのパラメータ：すなわち、特にオペレーションポイント情報のためのボックスが存在しないとき、デコーダ設定情報１３７の末尾のオペレーションポイントインデックス、を任意のものとするために使用され得る。そうすることにより、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄは次の通りに定義されるであろう：

［数４］
ａｌｉｇｎｅｄ（８） ｃｌａｓｓ ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ；ｂｉｔ（１） ｃｏｍｐｌｅｔｅ＿ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；
／／ ｐｒｅｖｉｏｕｓ ｂｉｔ ｆｏｒ “ｈｅｖｃ＿ｂａｓｅｌａｙｅｒ＿ｆｌａｇ”；
ｂｉｔ（２） ｒｅｓｅｒｖｅｄ ＝ ‘１１’ｂ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１２） ｍｉｎ＿ｓｐａｔｉａｌ＿ｓｅｇｍｅｎｔａｔｉｏｎ＿ｉｄｃ；
ｂｉｔ（１） ｏｐｅｒａｔｉｏｎＰｏｉｎｔＦｌａｇ；
ｉｆ（ｏｐｅｒａｔｉｏｎＰｏｉｎｔＦｌａｇ＝＝１） ｛
ｂｉｔ（１６） ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ；
｝
… ／／ ｒｅｓｔ ｏｆ ｔｈｅ ｄｅｃｏｄｅｒ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ
／／ ｗｉｔｈ ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ ｒｅｍｏｖｅｄ ａｔ ｔｈｅ ｅｎｄ．
この新しい構造は、デコーダ設定情報のサイズを大きくはせず、ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘのためにデフォルト値をセットする必要を回避する。

上で言及された文書ｗ１４３２８は、現在、ビットストリームにおいて使用されるスケーラビリティのタイプを示さずにＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄを定義している。ｗ１４３２８において現在定義されているようにジェネリック‘ｌｈｖ１’／‘ｌｈｅ１’が使用されるべきであるならば、クライアント側に存在するファイルリーダは、スケーラビリティタイプを理解するためにビデオパラメータセット（ｖｉｄｅｏ ｐａｒａｍｅｔｅｒ ｓｅｔ（ＶＰＳ））エクステンションをパースしなければならない。このＶＰＳは、ＮＡＬＵ１０７チャンク内に存在し得る。これは複雑なプロセスである。

１つの好ましい実施態様では、‘ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ’と称される１６ビットのスケーラビリティマスクを含む新しいＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄが提案される（ボックス１３７を見よ）。他の１つの実施態様では、構造全体が整数個のバイトに基づいて整列したままであることを条件として、スケーラビリティマスクはｎビットで表現されることができ、ｎは整数である。例えば、ＨＥＶＣ標準規格の場合の通りにｎ＝８である。

ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄは、ｗ１４３２８において定義される“ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ”と称されるフィールドを含み、これは明瞭性を目的として表示されていない。フィールド“ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ”は、ピクセルの最大数、および可能なタイルおよびスライスに関する情報を与える。

本発明の１つの好ましい実施態様では、サンプルを復号化するために必要とされる階層化ＨＥＶＣの種類を明確にするためにデコーダ設定レコードに他の１つのパラメータを、例えば“ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ”パラメータの後に、付け加えることが提案される。

［数５］
“
ｕｎｓｉｇｎｅｄ ｉｎｔ（８） ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１６） ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ；


ｂｉｔ（１） ｃｏｍｐｌｅｔｅ＿ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；
”
“ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ”の値（この例では‘２’）は、スケーラビリティのタイプ空間またはクオリティを示す。このフィールドは、クライアントが、スケーラビリティタイプがサポートされるかどうかを発見してそれがファイルをプレイできるかどうかを判定するのを助けるという利点を有する。ファイルをプレイできないとき、それは、例えばベースレイヤトラックのみのような、より下位のオペレーションポイントを選択することができる。

図２は、考慮されるピクチャのうちのエンハンスメントレイヤのみのピクチャが４個のタイルに分割されるときのＩＳＯベースメディアファイルフォーマット（ＩＳＯ−Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）に従う２つのスケーラビリティレイヤのカプセル化の例を示す。このカプセル化は、４つの追加のタイルトラック（１４０〜１４３）またはエンハンスメントタイルトラックＥＬＴＴを運ぶ。

ＨＥＶＣタイルトラックと同様に、エンハンスメントレイヤの空間サブパートの効率的アクセスを可能にするために階層化ＨＥＶＣタイルトラックを定義することが可能である。そのような場合のために、本発明の１つの実施態様では、ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙサンプル記述フォーマットを用いて特別のサンプルを伴う特別のトラックが作成される。

ＬＨＥＶＣタイルトラックは、このトラック内の１つまたは複数のタイルが属するＨＥＶＣレイヤの非ビデオ符号化レイヤのＮＡＬＵを運ぶＬＨＥＶＣトラックへの‘ｔｂａｓ’参照がそれについて存在するところのビデオトラックである。本発明の１つの実施態様では、新しいサンプル記述タイプが定義される。すなわち‘ｌｈｔ１’。

本発明の１つの実施態様では、タイルトラックのサンプルもサンプル記述ボックスもＶＰＳ、ＳＰＳまたはＰＰＳ ＮＡＬユニットを包含してはならず、これらのＮＡＬユニットは、トラック参照タイプ‘ｔｂａｓ’により識別される、関連付けられているレイヤを包含するトラックのサンプル内にまたはサンプル記述ボックス内に存在しなければならない（図２のエンハンスメントレイヤトラック１３０）。

本発明の１つの実施態様では、ＬＨＥＶＣタイルトラックおよび、‘ｔｂａｓ’トラック参照により示される、関連付けられているレイヤを包含するトラックまたはレイヤトラックの両方が、原ビットストリームがどのように復元されるかを示すために、ｗ１４３２８の付属書類Ｂ（Ａｎｎｅｘ Ｂ）において明らかにされているエクストラクタを使用する。これらのタイルトラックにおけるエクストラクタの存在は幾つかの適用領域においては制限されることがある、例えば、特に復号化してプレイするタイルのサブセットの選択を可能にするために、エクストラクタを各タイルトラック内にではなくてタイルベーストラック内に置くことが好ましいかもしれない。あるいは複数のタイルドレイヤの場合、既述サイズは、エクストラクタをタイルベーストラック内にのみ置くとき、小さくされる。

タイルトラックに内に格納されるＬＨＥＶＣサンプルは、ＩＳＯ／ＩＥＣ２３００８−２において定義されているように、１つ以上のタイルについてのスライスの完全なセットである。通例、タイルトラックが単一のタイルを参照するならば、このタイルを符号化するために使用される１つまたは複数のスライスだけがサンプル内に見出される。タイルトラックは、通例、１つのＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを（単一タイルのトラック）、または、１つのＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙおよび、ＨＥＶＣのために既に定義されている、このタイルセットがそれから構成されるところの１つ以上の依存的ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙを含む（マルチタイルトラック）。

もしサンプルに包含される符号化済みスライスがインスタンテニアスデコーディングリフレッシュ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｉｎｇ Ｒｅｆｒｅｓｈ（ＩＤＲ））スライス、クリーンランダムアクセス（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ（ＣＲＡ））スライス、またはブロークンリンクアクセス（Ｂｒｏｋｅｎ Ｌｉｎｋ Ａｃｃｅｓｓ（ＢＬＡ））スライスであることをサンプル内のＶＣＬ ＮＡＬユニットが示すならば、タイルトラックに格納されたＬＨＥＶＣサンプルは“ｓｙｎｃ”サンプル、例えばシークのようなランダムアクセスのための同期化サンプル、とみなされる。

正規のＬＨＥＶＣ（ｗ１４３２８において）サンプルのために定義されているサブサンプルおよびサンプルグルーピングは、ＬＨＥＶＣタイルサンプルのための同じ定義を有する。

本発明の１つの実施態様では、インプリメンテーションは、ＨＥＶＣシーケンスの完全なタイルのサブセットだけを復号化すると決定することができる。この場合、それは、ＨＥＶＣシーケンスを復号化している間、不要なトラックを廃棄するかあるいは幾つかのエクストラクタを無視するためにＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙおよびＴｉｌｅＳｅｔＧｒｏｕｐＥｎｔｒｙサンプルグループ記述内のタイルディペンデンシー情報を使用することができる。

図２において、図１と同じ参照符号を有する要素は同様である。さらに、明瞭性を目的として‘ｍｏｏｖ’ボックスだけが表されている。

図２においては‘ｍｏｏｖ’ボックスは４つのタイルトラックボックス１４０、１４１、１４２、１４３である追加のトラックボックスを含む。ここではタイルトラック１４１だけが記述される。他のタイルトラックボックスは容易に推測され得る。

タイルトラックボックスは‘ｔｋｈｄ’、トラックヘッダ（Ｔｒａｃｋ Ｈｅａｄｅｒ）ボックスまたはサブボックス１５０、を含み、これはＢＬレイヤトラックボックスおよびＥＬレイヤトラックボックスに属する‘ｔｋｈｄ’ボックス１１１または１３１と同じ特性を有する。

タイルトラックボックスは‘ｔｒｅｆ’、トラック参照（Ｔｒａｃｋ Ｒｅｆｅｒｅｎｃｅ）ボックスまたはサブボックスを含み、これは下記のこと：
− それがタイルベーストラックとの関係を示す４バイト‘ｔｂａｓ’を包含すること、および
− 識別子ｔｒａｃｋ＿ＩＤｓ［］は、このトラックのためのタイルベーストラックが識別子“ＥＬＢＴ”を有するエンハンスメントタイルトラックであることを示すこと、
を除いてＢＬレイヤトラックボックスおよびＥＬレイヤトラックボックスに属する‘ｔｒｅｆ’ボックスと同じ特性を有する。

タイルトラックボックスは、ＢＬトラックおよびＥＬトラックと同じく‘ｍｄｉａ’ボックス１５２、‘ｓｔｂｌ’ボックスまたはサブボックス１５３、‘ｓｔｓｄ’ボックスまたはサブボックス１５４を有するｍｉｎｆ（明瞭性を目的として表されていない）ボックスを含む。

‘ｓｔｂｌ’ボックス１５３は、特性をトラックサンプルに関連付ける２つのボックスまたはサブボックス：‘ｓｇｐｄ’１５６および‘ｓｇｐｄ’に含まれる‘ｔｒｉｆ’１５４、を含む。これらのボックスは、ｗ１４３２８において良く定義されている。

‘ｓｇｐｄ’は、特定のサンプルグループ内のサンプルの共通特性を記述するＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスである。ここで、パラメータ“ｄｅｆ＿ｓａｍｐｌｅ＿ｄｅｓｃｒ＿ｉｎｄｅｘ”は、トラックの全サンプルに当てはまるデフォルト特性：第１（および‘ｔｒｉｆ’ボックス内で唯一）、を示す。

‘ｔｒｉｆ’は、考慮されるタイルに関する情報を含むＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙボックスである。この場合、考慮されるタイルは値‘１’を有するｇｒｏｕｐＩＤにより特定され、その位置およびサイズは、それぞれ、“ｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ”、“ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔ”および“ｒｅｇｉｏｎ＿ｗｉｄｔｈ”、“ｒｅｇｉｏｎ＿ｈｅｉｇｈｔ”によって定められる。予備のパラメータは意味を持っておらず、独立フラグは、そのタイルが自己内蔵型（すなわち、復元されるために他のタイルを必要としない）であるか否かを示す。最後に、フルフレーム（ｆｕｌｌ−ｆｒａｍｅ）パラメータは、そのタイルがピクチャ全体（１）をカバーするか否か（０）を示す。

本発明の１つの実施態様では、新しいサンプルエントリ１５５を定義する４バイトは、メディアデータまたはＬＨＥＶＣタイルトラックのサンプルに対応するビットストリームが、下で‘ｌｈｖＣ’ボックス１５６において定義されるＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄあるいはより明確にはＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄにおいて与えられる設定（プロファイル、階層、およびレベルを含む）の下で動作するＨＥＶＣデコーダに準拠しデコーダにより使用可能であることを示す。

１つの実施態様では、４バイトは、‘ｌｈｔ１’である。

この新しいサンプルエントリの定義は下記のものであり得る。

［数６］
”
Ｂｏｘ Ｔｙｐｅｓ： ‘ｌｈｔ１’
Ｃｏｎｔａｉｎｅｒ： Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｂｏｘ（‘ｓｔｓｄ’）
Ｍａｎｄａｔｏｒｙ： Ｎｏ
Ｑｕａｎｔｉｔｙ： Ｚｅｒｏ ｏｒ ｍｏｒｅ ｓａｍｐｌｅ ｅｎｔｒｉｅｓ ｍａｙ ｂｅ ｐｒｅｓｅｎｔ
“
この新しいサンプルエントリの定義は、それがＬＨＥＶＣタイルトラックに関係することをパーサが直ちに認知することを可能にする。これは、現存するサンプルエントリでは可能ではなかった。

さらに、タイルトラックに関連するだけの幾つかの特別の特性が導入され得る。

上述されたように、このサンプルエントリはＬＨＥＶＣタイルトラックのメディアサンプルを記述する。ＬＨＥＶＣタイルトラック（サンプルエントリタイプ‘ｌｈｔ１’）のためのＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙの幅および高さは、トラックに包含される１つまたは複数のタイル（Ｔｉｌｅ）または１つまたは複数のタイルセット（ＴｉｌｅＳｅｔ）の最大幅および高さにセットされなければならない。タイルトラックのトラックヘッダ内のレイアウト情報（すなわち、レイヤ、タイルを位置決めするためのマトリックス、幅および高さ）は、‘ｔｂａｓ’トラック参照により特定される関連付けられた参照トラック（タイルベーストラックとも称される）のトラックヘッダ情報と同一でなければならず、そうでない場合は無視されなければならない。

好ましくは、‘ｌｈｔ１’サンプル記述の中の‘ｃｌａｐ’（クリーンアパーチャ（Ｃｌｅａｎ Ａｐｅｒｔｕｒｅ）を意味する）および‘ｐａｓｐ’（ピクセルアスペクト比（Ｐｉｘｅｌ Ａｓｐｅｃｔ Ｒａｔｉｏ）を意味する）は無視されなければならない。

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

［数７］
ｃｌａｓｓ ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙ（） ｅｘｔｅｎｄｓ ＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ（‘ｌｈｔ１’）｛
ＭＰＥＧ４ＢｉｔＲａｔｅＢｏｘ（）；
ｅｘｔｒａ＿ｂｏｘｅｓ ｂｏｘｅｓ；
｝
ＭＰＥＧ４ＢｉｔＲａｔｅＢｏｘおよびｅｘｔｒａ＿ｂｏｘｅｓはいずれもオプションである。

好ましくはＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙは、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ（あるいはＬＨＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたは階層化ＨＥＶＣフォーマットのための設定ボックスを示すための任意の名称）、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを包含しない。実際、これらのボックスは、‘ｔｂａｓ’トラック参照タイプにより示されるように、タイルベースＬＨＥＶＣトラックサンプル記述の中に見出される。

他の任意のボックスがＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙに含まれ得る。普通、ＬＨＥＶＣタイルトラックのＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘ内には、タイルベースＬＨＥＶＣトラックのＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘ内のエントリと同数のエントリがある。ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＨＥＶＣタイルトラックの周知のディスクリプタであって、ＨＥＶＣタイルトラックに関する記述的情報を包含する。

ＬＨＥＶＣタイルトラック（ＬＨＥＶＣ Ｔｉｌｅ Ｔｒａｃｋ）のためのＭＩＭＥタイプ‘ｃｏｄｅｃｓ’パラメータのためのサブパラメータは、標準規格を定義するｗ１４３２８の付属書類Ｅ．３で定義されている規則に従う。デコーダ設定レコードは、‘ｔｂａｓ’トラック参照タイプにより示されるように、ベーストラックサンプル記述から取られる。その後、このデコーダ設定レコードを用いてＭＩＭＥタイプ‘ｃｏｄｅｃｓ’のためのサブパラメータが構築される。

好ましくは、Ｌ−ＨＥＶＣのためのコーデックサブタイプパラメータは、次の例外を除けば、ＨＥＶＣのものと同一である：もしコーデックタイプがＬＨＶＣタイルトラックのジェネリックＬ−ＨＥＶＣメディアサンプル（すなわち、‘ｌｈｖ１コードポイント）を特定するならば、構築されるＨＥＶＣコーデックパラメータは“．ＳＸＸ”を付加されなければならず、“Ｓ”はスケーラビリティタイプを示し、“ＸＸ”はこのトラックのためのスケーラビリティマスクの値に対応するバイトであり；後置バイトはゼロならば省略され得る。これは、関連付けられたビデオを符号化するために使用されるコーデックに関する正確な情報を得るために例えばＤＡＳＨ表現（ＤＡＳＨ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）において有益であり得る。例えば、マルチビューストリーミングアプリケーションでは、マルチレイヤＨＥＶＣデコーダを有するＤＡＳＨクライアントは、空間またはクオリティスケーラビリティを示すコーデックパラメータで宣言された表現を選択しないであろう。

図３は、１つ以上の実施態様のステップが実行され得るサーバまたはクライアント装置３００のブロック図を表す。

好ましくは、装置３００は、通信バス３０２、装置のパワーアップ時にプログラムＲＯＭ３０６からの命令を実行するとともにパワーアップ後にメインメモリ３０８からのソフトウェアアプリケーションに関連する命令を実行し得る中央処理装置（ＣＰＵ）３０４を含む。メインメモリ３０８は例えば通信バス３０２を介してＣＰＵ３０４の作業領域として機能するランダムアクセスメモリ（ＲＡＭ）型のものであり、その記憶容量は、拡張ポート（図示されていない）に接続された任意のＲＡＭによって拡張され得る。ソフトウェアアプリケーションに関連する命令は、例えばハードディス（ＨＤ）３１０またはプログラムＲＯＭ３０６からメインメモリ３０８にロードされ得る。そのようなソフトウェアアプリケーションは、ＣＰＵ３０４により実行されたとき、図１および２に関して記載されたカプセル化ステップをサーバで実行させる。

参照番号３１２は、装置３００の通信網３１４への接続を可能にするネットワークインターフェースである。ソフトウェアアプリケーションは、ＣＰＵ３０４により実行されたとき、ネットワークインターフェースを通して受信された要求に応じて通信網を介してデータストリームおよび要求を他の装置に供給するようにされている。

参照番号３１６は、ユーザに対して情報を表示しおよび／またはユーザから入力を受信するためのユーザインターフェースを表す。

ここで、１つの変化形として、マルチメディアビットストリームの受信または送信を管理するための装置３００は、図１、２、および３に関して記載された方法を実行することのできる１つ以上の専用集積回路（ＡＳＩＣ）から成り得るということが指摘されるべきである。これらの集積回路は、例えば、非限定的に、ビデオシーケンスを生成しまたは表示しおよび／またはオーディオシーケンスを聞くための装置に統合される。

本発明の実施態様は、カメラ、スマートフォン、または、例えば特定の関心領域を徐々に拡大するためにＴＶのためのリモートコントローラとして働くタブレットなどの装置に埋め込まれ得る。それらは、特定の関心領域を選択することによってＴＶ番組の個人的閲覧経験を得るために同じ装置から使用されることもできる。ユーザによるこれらの装置の他の使用法は、彼の／彼女の好きなビデオの選択されたサブパートを他の接続されている装置と共有することである。それらは、監視カメラがこの発明の生成部分をサポートするとすれば、建物の監視下に置かれている特定の区域で何が起きるかを監視するためにスマートフォンまたはタブレット内で使用されることもできる。

当然に、局所的で特別の要求を満たすために、当業者は上記ソリューションに対して次の請求項により定義される発明の保護の範囲内に全て含まれる多くの改変および改造を加えることができる。

Claims (8)

1. Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に基づいてタイル符号化されたビデオデータに基づいて１又は複数のメディアファイルを生成する処理装置であって、
   前記ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックを生成するトラック生成手段と、
   前記トラック生成手段により生成されるタイルトラックに関するメタデータを生成するメタデータ生成手段であって、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、前記タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータを生成するメタデータ生成手段と、
   前記トラック生成手段により生成されたタイルトラックと前記メタデータ生成手段により生成されたメタデータとに基づく１又は複数のメディアファイルを生成するファイル生成手段と、を有することを特徴とする処理装置。
2. Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に基づいてタイル符号化されたビデオデータに基づく１又は複数のメディアファイルを処理する処理装置であって、
   前記ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックと、前記タイルトラックに関するメタデータであって、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、前記タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータと、を含む１又は複数のメディアファイルを受信する受信手段と、
   前記受信手段により受信された前記１又は複数のメディアファイルに基づいてビデオデータを再生する再生手段と、を有することを特徴とする処理装置。
3. 前記ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘは、タイルベースＬＨＥＶＣトラックサンプルディスクリプションボックスに記述されることを特徴とする請求項１又は２に記載の処理装置。
4. 前記ビデオデータは、ベースレイヤとエンハンスメントレイヤとを含む複数のレイヤに符号化されることを特徴とする請求項１乃至３の何れか１項に記載の処理装置。
5. 前記サンプルディスクリプションボックスは、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルテーブルボックスが有するボックスであることを特徴とする請求項１乃至４のうち、何れか１項に記載の処理装置。
6. 前記ＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙは、４文字の符号“ｌｈｔ１”で示されることを特徴とする請求項１乃至５のうち、何れか１項に記載の処理装置。
7. Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に基づいてタイル符号化されたビデオデータに基づいて１又は複数のメディアファイルを生成するための処理方法であって、
   前記ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックを生成するトラック生成工程と、
   前記トラック生成工程により生成されるタイルトラックに関するメタデータを生成するメタデータ生成工程であって、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、前記タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータを生成するメタデータ生成工程と、
   前記トラック生成工程により生成されたタイルトラックと前記メタデータ生成工程により生成されたメタデータとに基づく１又は複数のメディアファイルを生成するファイル生成工程と、を有することを特徴とする処理方法。
8. Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に基づいてタイル符号化されたビデオデータに基づく１又は複数のメディアファイルを処理する処理方法であって、
   前記ビデオデータのうち、少なくとも１つのタイル領域のビデオデータを有するタイルトラックと、前記タイルトラックに関するメタデータであって、ＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘ、ＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘまたはＭＰＥＧ４ＥｘｔｅｎｓｉｏｎＤｅｓｃｒｉｐｔｏｒｓＢｏｘを含まず、前記タイルトラックがＬ−ＨＥＶＣタイルトラックであることを示すＬＨＥＶＣＴｉｌｅＳａｍｐｌｅＥｎｔｒｙが、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）において規定されるサンプルディスクリプションボックスに記述されたメタデータと、を含む１又は複数のメディアファイルを受信する受信工程と、
   前記受信工程により受信された前記１又は複数のメディアファイルに基づいてビデオデータを再生する再生工程と、を有することを特徴とする処理方法。

Images