JP6960528B2 - メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム - Google Patents

Description

本発明は、メディアコンテンツを生成および処理するための方法および装置に関する。

本発明は、例えばＭＰＥＧ標準化機構によって定義されたＩＳＯベースメディアファイルフォーマットに従った仮想現実メディアコンテンツを含むステレオメディアコンテンツのカプセル化、構文解析、およびストリーミングに関するものであり、仮想現実メディアコンテンツの交換、管理、編集、およびプレゼンテーションを容易にし、適応型ｈｔｔｐストリーミングプロトコルを使用して例えばインターネットのようなＩＰネットワーク上での配信を改善するための、柔軟で拡張可能なフォーマットを提供する。

国際標準化機構ベースメディアファイルフォーマット（ＩＳＯ ＢＭＦＦ、ＩＳＯ／ＩＥＣ１４４９６−１２）は、ローカル記憶または、ネットワークを介するかまたは別のビットストリーム配信メカニズムを介する伝送のいずれかのための符号化された時分割（Ｔｉｍｅｄ）メディアデータビットストリームを記述する周知の柔軟かつ拡張可能なフォーマットである。このファイルフォーマットはオブジェクト指向である。これは、順次または階層的に編成されるボックスと呼ばれるビルディングブロックから構成される。これらのボックスは、タイミングパラメータおよび構造パラメータのような、符号化された時分割メディアデータビットストリームのパラメータを定義する。ファイルフォーマットでは、プレゼンテーション全体をムービーと呼ぶ。プレゼンテーション全体（またはメディアプレゼンテーション）に関連する記述メタデータは、４文字のコード「ｍｏｏｖ」によって識別されるムービーボックスと呼ばれるボックスに格納される。ムービーは、論理的にトラックに分割される（「ｍｏｏｖ」ボックスが各トラックに関連する１つまたは複数の「ｔｒａｋ」ボックスを含むなど）。各トラックは、メディアデータ（ビデオまたはオーディオのフレームなど）の時分割シーケンスを表す。各トラック内で、各時分割されたデータ単位をサンプルと呼ぶ。これは、ビデオまたはオーディオのフレームの場合がある。サンプルは、暗黙のうちに順番に番号付けされる。ムービーは、ムービーおよびトラックフラグメントのリストとして時間的に編成することができる。実際のサンプルは、ＭｅｄｉａＤａｔａＢｏｘｅｓと呼ばれるボックス内にある。ムービーフラグメント内には、トラック毎に０以上のトラックフラグメントのセットがある。トラックフラグメントは次に、０個以上のトラックランを含み、各トラックランは、そのトラックに対するサンプルの連続したランを文書化する。

ユーザ体験を改善し、特に没入型体験を提供するために、時分割メディアデータビットストリーム（ビデオおよびオーディオ）は、全方向性（または多方向性または複数方向性）であってもよい。３６０°パノラマビデオとしても知られるビデオに適用されると、ユーザは、表示されるシーン内に位置するように感じる。

全方向性ビデオは、３６０°カメラから、および／または、例えば、全てのカメラが共通の節点を有するように特別なリグに取り付けられたいくつかのカメラから得られたビデオストリームの画像を組み合わせることによって、得ることができる。このような画像の組み合わせは、画像スティッチング（ｓｔｉｔｃｈｉｎｇ）またはカメラスティッチングとして知られている。

このような全方向性ビデオは、ユーザの視線方向に従ったヘッドマウントディスプレイを介して、またはユーザを取り囲む湾曲した画面上への投影（投射）によって、レンダリングすることができる。また、ナビゲーションユーザインターフェースを有する従来の２Ｄ画面上に表示して、（ビューポートとしても知られている）全方向性ビデオのユーザの所望の部分に従って全方向性ビデオにパンインする（ｐａｎ ｉｎｔｏ）こともできる。これは、ユーザが仮想世界にいるように感じるので、仮想現実（ＶＲ）と呼ばれることが多い。仮想オブジェクトが全方位性ビデオに追加される場合、これは拡張現実感（ＡＲ）と呼ばれる。

図１は、サーバ装置１０１からクライアント装置１７０（１７０′としても示される）への全方向性メディアを撮像（キャプチャ）、送信、およびレンダリングするためのデータフローの一例を示す。

図示されるように、このメディアは、カメラシステム１００から取得され、ヘッドマウントディスプレイ（ＨＭＤ）１７０および１７０′に配信されるビデオコンテンツを有する。配信１６０は例えば、ストリーミングサーバ１６１およびストリーミングクライアント１６２を介して適応型ｈｔｔｐストリーミングプロトコルを使用して、インターネットのようなＩＰネットワーク１６３を介して実行することができる。

図示のために、使用されるカメラシステム１００は、立方体の各面に関連付けられた６つの標準カメラのセットに基づいている。これは、カメラシステムを取り囲む実際のシーンを表す画像を撮像する（ステップ１１０）ために使用される。この構成によれば、１つのカメラは前面画像を提供し、１つのカメラは背面画像を提供し、１つのカメラは左画像を提供し、１つのカメラは右画像を提供し、１つのカメラは底面画像を提供し、１つのカメラは頂部画像（平面画像）を提供する。

カメラシステム１００から得られた画像は、サーバ１０１において処理され（ステップ１２０）、３６０ビデオストリームまたは仮想現実メディアデータストリームとも呼ばれる全方向性ビデオストリームを形成する３６０画像を生成する。

処理ステップ１２０は同じ時間インスタンスの撮像画像をスティッチし、投影することから構成される。画像は、最初にスティッチされ、水平および垂直寸法の両方で３６０°の視野を形成する球１２１を表す３次元投影構造上に投影される。投影構造上の３６０画像データは、例えば正距円筒図法（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ｅｑｕｉｒｅｃｔａｎｇｕｌａｒ＿ｐｒｏｊｅｃｔｉｏｎ)）を使用して、２次元投影画像１２２にさらに変換される（撮像投影とも呼ばれる）。投影された画像は、球全体をカバーする。

代替的に、全方向性メディアが３６０度立体（ステレオスコピック）ビデオである場合、カメラシステム１００は、ステップ１１０において、３次元３６０度シーンをレンダリングするためにクライアントによって後で使用され得る左のビューおよび右のビューを表す画像シーケンスを撮像する複数のカメラから構成され得る。このような場合、上述の処理ステップ１２０は、左ビュー画像シーケンスと右ビュー画像シーケンスの両方に別々に適用される。任意選択で、ステップ１２５で、１つの単一の左＋右投影画像シーケンス上に結果として生じる同じ投影画像上への同じ時間インスタンスの各左ビュー画像および右ビュー画像をパックするためにフレームパッキングを適用することができる。いくつかの立体フレームパッキング配置、例えば、並列、上下、列ベースのインターリービング（Ｉｎｔｅｒｌｅａｖｉｎｇ）、行ベースのインターリービング、左右のビューを交互にする時間インターリービングが可能である。あるいは、立体フレームパッキング配置はまた、符号化ステップ１４０の後に独立したビデオビットストリームとなる別々の独立した投影画像シーケンスに左右のビューを保持することから成ることができる。たとえば、一方のビデオビットストリームは左ビュー画像を表し、他方のビデオビットストリームは右ビュー画像を表す。

任意選択的に、次に、領域ごとのパッキング１３０が、投影画像１２２をパック画像（ｐａｃｋｅｄ ｉｍａｇｅ）１３１上にマッピングするために適用される。領域ごとのパッキングは例えば、ユーザにとって最も有用な球の部分に関する信号情報を最大化するために、投影画像の領域の変換、サイズ変更、および再配置を適用することからなる。パック画像は、球全体の一部のみをカバーすることができることに留意されたい。領域ごとのパッキングが適用されない場合、パック画像１３１は、投影画像１２２と同一である。立体全方向性メディアの場合、領域ごとのパッキングは、ステップ１２５で選択されたフレームパッキング配置に応じて、左＋右投影画像シーケンスに、または左ビューおよび右ビュー投影画像シーケンスに別々に適用される。

投影画像１２２は、ステップ１４０において、１つ又は複数のビデオビットストリームに符号化される。立体全方向性メディアの場合、符号化ステップはステップ１２５で選択されたフレームパッキング配置に応じて、左＋右パッキング画像シーケンスに適用されるか、または左ビューおよび右ビューパッキング画像シーケンスに別々に適用される。あるいは、マルチビュー符号化が左ビューおよび右ビューのパッキング画像シーケンス上で使用することができる。

符号化フォーマットの例としては、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、Ｌ−ＨＥＶＣ（Ｌａｙｅｒｅｄ ＨＥＶＣ）などがある。以下では、ＨＥＶＣが、ＨＥＶＣおよびその階層化拡張（Ｌ−ＨＥＶＣ）の両方を指すために使用される。

ＨＥＶＣおよび同様のビデオ符号化フォーマットは、サンプルの異なる空間的区分（ｓｕｂｄｉｖｉｓｉｏｎ）、例えば、ピクチャ：タイル、スライス及びスライスセグメントを定義する。タイルは水平および垂直境界（すなわち、行および列）によって定義され、整数個のコーディングツリーユニット（ＣＴＵ）またはコーディングブロックを含むピクチャの矩形領域を定義し、これらはすべて、以下でコーディングユニットと呼ばれる。したがって、タイルは、ピクチャの空間サブパートを表すための良好な候補である。ただし、符号化されたビデオデータ（ビットストリーム）のシンタックス上の編成およびＮＡＬユニット（またはＮＡＬＵ）へのそのカプセル化は、むしろ、（ＡＶＣにおけるように）スライスおよびスライスセグメントに基づくものである。

ＨＥＶＣ内のスライスはスライスセグメントのセットであり、少なくとも第１のスライスセグメントは独立したスライスセグメントであり、もしあれば、他のスライスセグメントは従属スライスセグメントである。スライスセグメントは、整数個の連続する（ラスタスキャン順の）ＣＴＵを含む。スライスは、必ずしも矩形形状である必要はない（したがって、空間サブパート表現のためのタイルよりも適切ではない）。スライスセグメントは、ＨＥＶＣビットストリームでｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒとして符号化され、その後にｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｄａｔａが続く。独立スライスセグメント（ＩＳＳ）および従属スライスセグメント（ＤＳＳ）はそれらのヘッダによって異なり、従属スライスセグメントは、独立スライスセグメントのヘッダからの情報を再使用するので、より短いヘッダを有する。独立スライスセグメントと従属スライスセグメントとの両方は、ビットストリーム内のエントリポイントのリストを含む。

ビデオビットストリームがタイルで符号化されるとき、タイルは同じピクチャ内の近傍タイル（空間依存性）及び前の参照ピクチャ内の近傍タイル（時間依存性）からタイルが依存しないことを保証するために、動きが制約されることができる。このように、動きが制約されたタイルは、独立して復号可能である。

あるいは、パック画像は符号化の前にいくつかの空間サブピクチャに分割することができ、各サブピクチャは独立して符号化され、例えば、独立して符号化されたＨＥＶＣビットストリームを形成する。

したがって、符号化ステップ１４０の結果として、パック画像１３１は、１つ以上の独立して符号化されたビットストリームによって、または１つ以上の独立して符号化されたサブビットストリームから構成される少なくとも１つの符号化されたビットストリームによって、表現することができる。

次に、ステップ１５０において、これらの符号化されたビットストリームおよびサブビットストリームは、ＩＳＯＢＭＦＦフラグメントトラックおよび／または（上述した）トラックにカプセル化される。当該トラックまたはフラグメントトラックを含むファイルまたは小さな一時セグメントファイルは、例えば、ＭＰＥＧ標準化機構によって定義されたＩＳＯベースのメディアファイルフォーマットおよび全方向性メディアフォーマット（ＯＭＡＦ）に従ったカプセル化ファイルフォーマットに従って、ステップ１６５で提供される。結果として生じるファイルまたはセグメントファイルはｍｐ４ファイルまたはｍｐ４セグメントになる。カプセル化の間、ビデオまたはオーディオストリームに関する情報を提供するメタデータトラックと同様に、オーディオストリームをビデオビットストリームに追加することができる。

次に、カプセル化されたファイルまたはセグメントファイルは例えば、ｈｔｔｐ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを使用するインターネット経由で、または例えばディスクのような取り外し可能なデジタル媒体上で、配信機構１６０を介してクライアント１７０に配信される。説明のために、配信１６０は、ＭＰＥＧ標準化委員会（「ＩＳＯ／ＩＥＣ２３００９−１、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）、Ｐａｒｔ１：Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ａｎｄ ｓｅｇｍｅｎｔ ｆｏｒｍａｔｓ」）からのＤＡＳＨ（Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ)などのＨＴＴＰ上の適応ストリーミングを使用して実行される。

この規格は、ＨＴＴＰ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｉｏｎｓ（ＵＲＬ）とのメディアプレゼンテーションのメディアコンテンツのコンパクトな記述の関連付けを可能にする。このような関連付けは、典型的にはマニフェストファイルまたは記述ファイル１６４と呼ばれるファイルに記述される。ＤＡＳＨにおいて、このマニフェストファイルはＭＰＤファイル（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）とも呼ばれるＸＭＬファイルである。

クライアント装置１７０は、ＭＰＤファイルを受信することによって、各メディアコンテンツコンポーネントの記述を取得する。従って、メディアプレゼンテーションで提案されるメディアコンテンツコンポーネントの種類を認識し、ストリーミングクライアント１６２を介してストリーミングサーバ１６１から関連するメディアセグメント１６５をダウンロードするために使用されるＨＴＴＰ ＵＲＬを知る。したがって、クライアント１７０は（ＨＴＴＰリクエストを介して）ダウンロードし、再生する（すなわち、メディアセグメントの受信後にデコードし、再生する）メディアコンテンツコンポーネントを決定することができる。

クライアント装置はユーザのビューポート（すなわち、ユーザによって現在表示され、視聴されている球面ビデオの一部）に応じて、シーンのワイドビューを表すフルパック画像の空間部分に対応するメディアセグメントのみを取得することができることに留意されたい。ビューポート（球領域とも呼ばれる）は、３つの角度「ヨー、ピッチ、ロール」または水平および垂直範囲を有する「方位角、仰角、チルト」によって与えられる、球内の位置によって記述することができる。シーンのワイドビューは、フルパック画像によって表されるフルビューを表すことができる。

ＯＭＡＦに使用される用語によれば、以下のものがある：
球領域（Ｓｐｈｅｒｅ ｒｅｇｉｏｎ）＝４つの大円、または、２つの方位円および２つの仰角円のいずれかによって指定される球上の領域、またはある量のヨー、ピッチ、およびロール回転を適用した後の回転球上のそのような領域；
垂直範囲（Ｖｅｒｔｉｃａｌ ｒａｎｇｅ）＝球領域が４つの大円によって指定される場合、球領域の中心点を通る垂直視野、または他の場合、仰角範囲；
水平範囲（Ｈｏｒｉｚｏｎｔａｌ ｒａｎｇｅ）＝球領域が４つの大円によって指定される場合、球領域の中心点を通る水平視野、または他の場合、方位角範囲；
大円（ｇｒｅａｔ ｃｉｒｃｌｅ）＝球と球の中心点を通る平面との交点；
方位円（ａｚｉｍｕｔｈ ｃｉｒｃｌｅ）＝すべての点を同じ方位値で結ぶ球上の円；
仰角円（ｅｌｅｖａｔｉｏｎ ｃｉｒｃｌｅ）＝全ての点を同じ仰角値で結ぶ球上の円。

受信すると、カプセル化された仮想現実メディアファイルまたはメディアセグメントは、ステップ１４１でデコードされたデータストリームを抽出するために、ステップ１５１の間に解析される。ステップ１５１で受信されたＩＳＯＢＭＦＦファイルまたはセグメントの場合、構文解析は典型的には、記述メタデータから、カプセル化されたビデオビットストリームおよび／またはビデオサブビットストリームを抽出することができるｍｐ４リーダまたはｍｐ４パーサによって処理される。

次に、任意選択で、復号ステップ１４１から得られたパック画像はアンパックされ、投影画像が得られ、次いで、投影画像はビデオレンダリングのために処理され（ステップ１２１）、表示される（ステップ１１１）。ビデオレンダリングはいくつかのパラメータに依存し、その中には、ユーザの視点（ｐｏｉｎｔ ｏｆ ｖｉｅｗ）、視点（ｐｏｉｎｔ ｏｆ ｓｉｇｈｔ）、および投影画像を生成するために使用される投影（複数可）があることに留意されたい。図示のように、ビデオをレンダリングするステップは、復号された投影画像を球上に再投影するステップを含む。このような再投影から得られた画像は、ヘッドマウントディスプレイ１７０′に表示される。

立体ビューを処理するために、図１を参照して説明されるプロセスは、複製されてもよく、または部分的に複製されてもよい。

ＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）ビデオストリームのいくつかの画像を仮想現実メディアデータストリームのパノラマ画像にスティッチすることは、非常に高いビットレートおよび非常に高い解像度の仮想現実メディアデータストリームをもたらすことが観察されている。したがって、システムの観点から、帯域幅の無駄を避け、クライアントプレーヤの処理能力に準拠（適合）するために、仮想現実メディアデータへのアクセスを最適化する必要がある。

このような必要性は、仮想現実メディアデータストリームが図１を参照して説明したものとは別の目的に使用することも可能であることよりもさらに重要である。特に、３６０度のプロジェクタのアレイのような特定のディスプレイを有する３６０度の画像を表示するために、仮想現実メディアデータストリームを使用することができる。また、特定の視野を表示し、および／または視点（ｐｏｉｎｔ ｏｆ ｖｉｅｗ）、視野、および視点（ｐｏｉｎｔ ｏｆ ｓｉｇｈｔ）を変更するために使用することもできる。

本発明者らは、図１を参照して説明したプロセスに沿って、送信すべきメディアデータに関する情報を説明し、シグナリングする際に、いくつかの問題に気付いた。

たとえば、クライアントから特定の構文解析プロセスを要求するトラックのシグナリングが含まれ、これによってオーバーヘッドが生成され、複雑になる。

別の例は、ステレオビューのシグナリングが特定のカプセル化プロセスに限定され、比較的高価であることに関する。

別の例は、トラック内の符号化されたデータ内のカバレッジのシグナリングを含む。サブピクチャトラックがいくつかの異なるトラックにカプセル化される場合、既存の解決策は複雑であり、マルチトラックカプセル化プロセスに完全に準拠しない。

本発明は、前述の問題のうちの１つまたは複数に対処するように考案された。

この文脈において、例えばｈｔｔｐプロトコルを使用するインターネットのようなＩＰネットワーク上で、ストリーミングメディアコンテンツ（例えば、全方向性メディアコンテンツ）のためのソリューションが提供される。

本発明の一態様によれば、１つまたは複数のメディアファイルを生成するための方法であって、
第１のビューフレームおよび第２のビューフレームを含む符号化された立体メディアデータを取得することであって、各第１のビューフレームが第２のビューフレームに関連付けられている、前記取得することと、
前記符号化された立体メディアデータを含むトラックを生成することと、
左のビューに対応するビューフレームが識別されることに基づいて記述メタデータを生成することと、
前記生成されたトラックおよび前記生成された記述メタデータに基づいて前記１つまたは複数のメディアファイルを生成することと、
を含む方法が提供される。

本発明の実施形態は、特定のトラック、特に、ＯＭＡＦ内の「単独で提示されることを意図しない」トラックとして定義されるトラックに対して、より単純なシグナリングを提供する。これはＯＭＡＦコンテンツがサブピクチャトラックに分割されるとき、シグナリングオーバーヘッドおよび構文解析の複雑さを低減し、これは１つまたは複数の期間の間、ピクチャの一部に対応するデータを含むトラックを意味する。

実施形態によれば、記述メタデータを生成することは、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６−１２）で定義されているボックスＳｔｅｒｅｏＶｉｄｅｏＢｏｘを含めることを含む。

実施形態によれば、前記ボックスは、どのビューフレームが左のビューに対応するかをシグナリングするためのＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅを含む。

実施形態によれば、前記方法は、少なくとも１つの第１のビューフレームおよび関連する第２のビューフレームについて、前記第１のビューフレームをその関連する第２のビューフレームと組み立てて単一のフレームを形成することをさらに含み、前記符号化された立体メディアデータは、前記組み立てられた単一のフレームのうちの少なくとも１つを符号化することによって取得される。

実施形態によれば、前記方法は、前記クライアント側で表示されるべき表面に関する前記第１のビューまたは前記第２のビューのうちの少なくとも１つのためのカバレッジ情報を提供することと、前記カバレッジ情報が前記第１のビューおよび前記第２のビューの両方のために１回だけ提供される必要がある場合または前記第１のビューおよび前記第２のビューのそれぞれのために２回だけ提供される必要がある場合に、シグナリングのための情報を提供することと、をさらに含む。

実施形態によれば、第１のビューフレームおよび前記関連する第２のビューフレームが同じ符号化されたメディアデータに対応する場合、前記情報は、前記カバレッジ情報が前記第１のビューまたは前記第２のビューのうちの１つのみに提供されることをシグナリングするための所定の値をとるパラメータであり、そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューのそれぞれに提供される。

実施形態によれば、前記第１のビューフレームおよび前記関連する第２のビューフレームが異なる符号化されたメディアデータに対応する場合、前記方法は、前記クライアント側で表示されるべき表面に関する前記第１のビューまたは前記第２のビューのうちの少なくとも１つに対してカバレッジ情報を提供することをさらに含み、前記カバレッジ情報は前記第１のビューまたは前記第２のビューのそれぞれに対して提供され、そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューの両方に対して１回だけ提供される。

実施形態によれば、前記第１のビューフレームは左ビューフレームであり、前記第２のビューフレームは右ビューフレームである。

本発明の別の態様によれば、コンピュータまたはプロセッサによって実行されると、前記コンピュータまたはプロセッサに前述の方法を実行させるプログラムが提供される。

本発明の別の態様によれば、前述のプログラムを記憶したコンピュータ可読記憶媒体が提供される。

本発明の別の態様によれば、１つまたは複数のメディアファイルを生成するための装置が提供され、前記デバイスは、前述のような方法を実施するように構成される。

本発明の別の態様によれば、１つまたは複数の以上のメディアファイルを処理する方法であって、
前記１つまたは複数のメディアファイルを取得することと、
第１のビューフレームおよび第２のビューフレームを含む符号化された立体メディアデータを含むトラックを取得するために、前記取得された１つまたは複数のメディアファイルを処理することであって、各第１のビューフレームは第２のビューフレームに関連付けられている、前記処理することと、
左のビューに対応するビューフレームが識別されることに基づいて記述メタデータを取得するために、前記取得された１つまたは複数のメディアファイルを処理することと、
を含む方法が提供される。

実施形態によれば、前記記述メタデータは、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６−１２）で定義されるボックスＳｔｅｒｅｏＶｉｄｅｏＢｏｘを含む。

実施形態によれば、前記ボックスは、どのビューフレームが左のビューに対応するかをシグナリングするためのＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅを含む。

実施形態によれば、少なくとも１つの第１のビューフレームおよび前記関連する第２のビューフレームについて、前記第１のビューフレームはその関連する第２のビューフレームと組み立てられて（アセンブリされて）１つの単一のフレームを形成し、前記立体メディアデータは、前記組み立てられた単一のフレームのうちの少なくとも１つを復号することによって得られる。

実施形態によれば、前記方法は、前記クライアント側で表示されるべき表面に関する前記第１のビューまたは前記第２のビューのうちの少なくとも１つについてのカバレッジ情報を取得することと、前記カバレッジ情報が前記第１のビューおよび前記第２のビューの両方について１回だけ取得される必要がある場合、または前記第１のビューおよび前記第２のビューのそれぞれについて２回だけ取得される必要がある場合に、シグナリングするための情報を取得することと、をさらに含む。

実施形態によれば、前記第１のビューフレームおよび前記関連する第２のビューフレームが同じ符号化されたメディアデータに対応する場合、前記情報は、前記カバレッジ情報が前記第１のビューまたは前記第２のビューのうちの１つのみについて取得されることをシグナリングするための所定の値をとるパラメータであり、そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューのうちのそれぞれについて取得される。

実施形態によれば、前記第１のビューフレームおよび前記関連する第２のビューフレームが異なる符号化されたメディアデータに対応する場合、前記方法は、前記クライアント側で表示されるべき表面に関する前記第１のビューまたは前記第２のビューのうちの少なくとも１つについてのカバレッジ情報を取得することをさらに含み、前記カバレッジ情報は前記第１のビューまたは前記第２のビューのそれぞれについて取得され、そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューの両方について１回だけ取得される。

実施形態によれば、前記第１のビューフレームは左のビューフレームであり、前記第２のビューフレームは右のビューフレームである。

本発明の別の態様によれば、コンピュータまたはプロセッサによって実行されると、前記コンピュータまたはプロセッサに前述の方法を実行させるプログラムが提供される。

本発明の別の態様によれば、前述のプログラムを記憶したコンピュータ処可読記憶媒体が提供される。

本発明の別の態様によれば、１つまたは複数のメディアファイルを処理するための装置が提供され、前記装置は、前述のような方法を実施するように構成される。

本発明のさらなる利点は図面および詳細な説明を検討することにより、当業者に明らかになるのであろう。任意の追加の利点が本明細書に組み込まれることが意図される。
本発明の実施形態は、単なる例として、以下の図面を参照して以下に記載される。
図１は、サーバからクライアントへの全方向性ビデオを撮像（キャプチャ）、処理、カプセル化、送信、およびレンダリングするためのデータフローの一例を示す。 図２は、本発明の実施形態によるカプセル化の例を示すブロック図を示す。 図３は、本発明の１つまたは複数の実施形態を実施するためのコンピューティングデバイスの概略ブロック図である。

特定の実施形態によれば、パック画像１３１の符号化（図１のステップ１４０）から生じる符号化されたビットストリーム及びサブビットストリームはカプセル化ファイルフォーマット、例えば、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−２及びＩＳＯ／ＩＥＣ１４４９６−１５）、Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ＭｅｄｉＡフォーマット（ＯＭＡＦ）（ＩＳＯ／ＩＥＣ２３０９０−２）、及びＭＰＥＧ標準化機構によって定義される関連仕様に従って、ファイル又は小さい時間セグメントファイルにカプセル化される。

符号化されたビットストリーム（例えば、ＨＥＶＣ）および場合によってはそのサブビットストリーム（例えば、タイル化されたＨＥＶＣ、ＭＶ−ＨＥＶＣ、スケーラブルなＨＥＶＣ）は、１つの単一のトラックとしてカプセル化することができる。あるいは、空間的に関連する（すなわち、投影画像のサブ空間部分である）複数の符号化されたビットストリームを、いくつかのサブピクチャトラックとしてカプセル化することができる。あるいは、いくつかのサブビットストリーム（タイル、ビュー、レイヤ）を含む符号化されたビットストリーム（例えば、タイルＨＥＶＣ、ＭＶ−ＨＥＶＣ、スケーラブルなＨＥＶＣ）は、複数のサブピクチャトラックとしてカプセル化することができる。

サブピクチャトラックは、ピクチャまたは画像のサブパートのためのデータを埋め込むトラックである。サブピクチャトラックは、他のサブピクチャトラックに、またはサブピクチャが抽出されるフルピクチャを記述するトラックに関連付けられてもよい。例えば、サブピクチャトラックは、タイルトラックとすることができる。これは、ＡＶＣトラック、ＨＥＶＣトラック、ＨＥＶＣタイルトラック、又はサンプルのシーケンスとしてカプセル化された任意の圧縮ビデオビットストリームによって表すことができる。

タイルトラックは、画像の空間部分に対応する、或いは、画像又はピクチャのサブピクチャに対応する時分割ビデオサンプルのシーケンスである。これは、例えば、画像内の関心領域又は画像内の任意の領域とすることができる。タイルトラックに対応するデータは、ビデオビットストリームから取得することも、ビデオビットストリームのサブパートから取得することもできる。例えば、タイルトラックはＡＶＣ又はＨＥＶＣに準拠したビットストリームとすることができ、或いはＡＶＣ又はＨＥＶＣのサブパート又は例えばＨＥＶＣタイルのような任意の符号化されたビットストリームとすることができる。好ましい実施形態では、タイルトラックは独立して復号可能である（エンコーダが他のタイルから動き予測を除去するように注意を払った）。タイルトラックがタイルを有するＨＥＶＣで符号化されたビデオビットストリームに対応する場合、ＩＳＯ／ＩＥＣ１４４９６−１５ 第４版に記載されているように、「ｈｖｔ１」トラックとして示されるＨＥＶＣタイルトラックにカプセル化することができる。次に、タイルベーストラックを参照して、パラメータセット、ビデオデコーダをセットアップするための高レベル情報を取得することができる。ＨＥＶＣトラック「ｈｖｃ１」または「ｈｅｖ１」トラックにカプセル化することもできる。タイルトラックは、サブピクチャをより大きな画像又はピクチャに空間的に合成するために使用することができる。

タイルベーストラックは、これらの１つ以上のトラック間で共有されるデータまたはメタデータを含む、１つ又は複数のタイルトラックに共通のトラックである。タイルベーストラックは、１つまたは複数のタイルトラックから画像を構成するための命令を含むことができる。タイルトラックは、完全な復号またはレンダリングのためにタイルベーストラックに依存することができる。タイルベーストラックがタイル付きのＨＥＶＣで符号化されたビデオビットストリームから取得される場合、「ｈｖｃ２」または「ｈｅｖ２」トラックとして表されるＨＥＶＣトラックにカプセル化される。さらに、それはトラック参照「ｔｂａｓ」を介してＨＥＶＣタイルトラックによって参照され、ＩＳＯ／ＩＥＣ１４４９６−１５ 第４版に記載されているように、ＨＥＶＣタイルトラックに対する「ｓａｂｔ」トラック参照を使用してタイル順序を示すものとする。

合成トラック（参照トラックとも呼ばれる）は、画像を合成するために他のトラックを参照するトラックである。合成トラックの一例は、ビデオトラックの場合、サブピクチャトラックをより大きな画像に合成するトラックである。これは、例えば、各ビデオトラックからより大きな画像に画像を合成するための変換及び変換パラメータを提供するビデオトラックから導出されるトラックにおいて、ポスト復号操作によって行うことができる。合成トラックは、サブビットストリームの連結の結果得られるビットストリームを復号する前に他のビデオトラックまたはタイルトラックからＮＡＬユニットを抽出して形成する命令を提供するエクストラクタ（抽出器）ＮＡＬユニットを有するトラックであってもよい。合成トラックは例えば、他のトラックに対するトラック参照を介して、合成命令を暗黙的に提供するトラックであってもよい。

ＩＳＯ／ＩＥＣ１４４９６−１２はトラックのグループを記述するためにトラックレベルに配置されたボックスを提供し、ここで各グループは特定の特性を共有し、または、グループ内のトラックは特定の関係を有する。特定の特性または関係は、含まれるボックスのボックスタイプ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ）によって示される。含まれるボックスには識別子（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ）が含まれており、これを使用して同じトラックグループに属するトラックを判定できる。同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅおよびｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を持つトラックグループボックスを有するすべてのトラックは、同じトラックグループの一部である。ＭＰＥＧ ＯＭＡＦ標準規格は、タイプ「ｓｐｃｏ」のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘとして、空間合成のための特定のトラックグループを提案している。「ｓｐｃｏ」トラックグループ内の各トラックのサンプルは、より大きな画像を生成するために、この同じグループ内の他のトラックからのサンプルで（同じ合成または復号化時間で）空間的に合成することができる。

パック画像１３１の符号化（図１のステップ１４０）の結果得られる符号化されたビットストリーム及びサブビットストリームに依存して、ファイルフォーマットにおけるカプセル化のいくつかの変形が可能である。

図２は、本発明の一実施形態によるファイル／セグメントカプセル化（図１のステップ１５０）の一例を示すブロック図である。

ステップ２００で、サーバは、幾つかの空間的に関連するビデオビットストリーム（すなわち、パックされた画像の空間的サブパートを表し、空間的合成がより大きな画像を生成することがある）があるか、或いは、モーション制約タイル、または複数のサブピクチャトラックとしてクライアントに公開できる複数のビューのいずれかを表すビデオサブビットストリームを含むビデオビットストリームがあるかを判定する。符号化されたパック画像が単一のビデオビットストリームとして符号化されているために、或いは、コンテンツ作成者が符号化されたパック画像を複数のトラックとして公開することを望まないために、符号化されたパック画像を複数のトラックとして公開できない場合、ビデオビットストリームまたはビデオサブビットストリームは１つの単一のトラックにカプセル化される（ステップ２１０）。そうではない場合、ステップ２２０において、カプセル化されるべきメディアコンテンツが、モーション制約タイルを表すビデオサブビットストリームから構成されるかどうかが判定される。ｙｅｓの場合、複数のタイルトラックの少なくとも１つの合成を表すために、少なくとも１つの合成トラックが提供される必要があり得る。合成は、完全にパックされた画像、または完全にパックされた画像のサブパートのみを表すことができる。タイルトラックを有する合成トラックを使用することにより、クライアント側のストリームの個別のレンダリングと復号を必要とすることが回避される。クライアントに公開される可能な組み合わせの数は、コンテンツ作成者の選択に依存する。たとえば、コンテンツ作成者は、現在のユーザのビューポートに応じて、異なる視覚的品質を持つタイルを組み合わせることができる。このため、異なる視覚品質を持つパック画像を複数回符号化し、視覚的品質に関してタイルの異なる組み合わせを含む完全にパックされた画像を表すいくつかの合成トラックを提示することができる。ユーザのビューポートに応じて異なる品質でタイルを組み合わせることにより、コンテンツ作成者はネットワークリソースの消費を低減することができる。

ステップ２２０において、合成トラックが提供されなければならないと判定された場合、次に、合成トラックに対して暗黙の再構成（ｉｍｐｌｉｃｉｔ ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ）を使用できるか否かが判定される（ステップ２４０）。

暗黙の再構成とは、例えば、ＩＳＯ／ＩＥＣ１４４９６−１５ 第４版に定義されているような、タイルベース及びタイルトラックからのビットストリーム再構成を指す。合成トラックのサンプル中のエクストラクタを、それらがタイルトラックのサンプル中で参照するデータで置き換えることによって、タイルトラックのサンプルから合成トラックのサンプルを再構築するためにエクストラクタのようなインストリーム構造を使用するのではなく、暗黙の再構築は合成トラックのサンプルとタイルトラックとをトラック参照の順序で連結することによって合成トラックのサンプルを再構築することを可能にする（例えば、ＨＥＶＣ暗黙の再構成における「ｓａｂｔ」トラック参照）。

暗黙の再構成の使用は、使用のシナリオに依存する。いくつかのタイルトラックの合成が、符号化時のタイルの順序と比較して、復号時にタイルの再配置を必要とする場合、いくつかのスライスアドレスを書き換えなければならない。このような場合、暗黙的な再構成は不可能であり、エクストラクタを用いた明示的な再構成を選択しなければならない。

暗黙の再構成が可能である場合、タイルベーストラックが生成され（ステップ２４１）、ビデオサブビットストリームは独立して復号可能でないタイルトラックとして（例えば、ＨＥＶＣ「ｈｖｔ１」トラックとして）カプセル化される。

そうではない場合、エクストラクタトラックが生成され（ステップ２４２）、ビデオサブビットストリームは独立して復号可能なタイルトラックとして（例えば、ＨＥＶＣ「ｈｖｃ１」又は「ｈｅｖ１」トラックとして）カプセル化される。

ステップ２２０に戻り、メディアコンテンツがタイルサブビットストリームを含まないか、またはコンテンツ作成者が合成トラックを作成して公開したくない場合、空間的に関連するビデオビットストリームまたはビデオサブビットストリーム（例えば、タイルまたは複数のビュー）は、別々のサブピクチャトラックにカプセル化される（ステップ２３０）。そのような特定の場合には、タイルサブビットストリームがＨＥＶＣタイルである場合にはそれらはＨＥＶＣトラック「ｈｖｃ１」又は「ｈｅｖ１」トラックとしてカプセル化される。

ステップ２５０では、空間合成のためのシグナリングが、空間的に関連するビデオビットストリームまたはビデオサブビットストリームを一緒にグループ化するために追加される。空間合成シグナリングはグループを構成する各トラック（サブピクチャトラック、タイルトラック、合成トラック）に特定のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘを定義することによって提供することができる。例えば、ＭＰＥＧ ＯＭＡＦで定義され、以下に示すように、同じグループに関連するすべてのトラックに対して、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを持つタイプ「ｓｐｃｏ」のトラックグループを定義することができる：

このトラックグループボックスは、合成（コンポジション）内のトラックの相対的な２次元座標と、合成によって形成される画像の全体的なサイズとを提供する。合成は、パック画像全体、またはパック画像のサブパートのみを表すことができる。例えば、コンテンツ作成者は、複数の合成トラックを公開して、パック画像全体またはパック画像のサブパートのみを構築することを可能にしたい場合がある。

代替処理として、ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ（「ｓｐｃｏ」）は以下のように、合成ピクチャの幅と高さを表すパラメータｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈとｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔのみを定義することができる：

そして、合成（コンポジション）内のトラックの２次元座標は、以下のようなＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙで定義される新しいｆｕｌｌＢｏｘとして与えることができる：

または、以下のような新しい汎用サンプルグループ記述エントリで定義される新しいｆｕｌｌＢｏｘとして与えることができる：

ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄは、関連付けられたトラックグループの識別子を示す。したがって、トラックは、各トラックグループ内の異なる位置にある複数のトラックグループに関連付けることができる。ｔｒａｃｋ＿ｓｕｂｇｒｏｕｐ＿ｉｄは、サブグループ識別子を提供する。トラックグループ内でｔｒａｃｋ＿ｓｕｂｇｒｏｕｐ＿ｉｄを持つすべてのトラックは、同じトラックサブグループに関連する。

ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙは、合成（コンポジション）内のこのトラックのサンプルの左上隅の水平および垂直位置を提供する。

ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔは、合成（コンポジション）内のこのトラックのサンプルの幅と高さを提供する。

これらのパラメータは、これらのトラックを表す適応設定（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ）の空間関係を記述するためにＤＡＳＨマニフェストで使用することができるＤＡＳＨ空間関係記述（ＳＲＤ）記述子（ＩＳＯ／ＩＥＣ２３００９−１ 第３版で定義される）のパラメータと直接一致する。

ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｏｕｒｃｅ＿ｉｄパラメータと一致する。

ｔｒａｃｋ＿ｓｕｂｇｒｏｕｐ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄパラメータと一致する。

ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔは、それぞれＤＡＳＨ ＳＲＤパラメータであるｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔパラメータに一致する。

最後に、（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを介して）関連するトラックグループからのｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈとｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤ ｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔパラメータに一致する。

代替処理として、合成トラックがある場合、空間合成シグナリングは、この合成トラックによって暗黙的に提供することができる。実際、合成トラックがタイルベーストラックである場合、タイルベーストラックは、タイプ「ｓａｂｔ」のトラック参照を介してタイルトラックのセットを参照する。このタイルベーストラックおよびタイルトラックのセットは、合成グループを形成する。同様に、合成トラックがエクストラクタトラックである場合、エクストラクタトラックは、タイプ「ｓｃａｌ」のトラック参照を介してタイルトラックのセットを参照する。このエクストラクタトラックおよびタイルトラックのセットは、合成グループも形成する。どちらの場合も、ＩＳＯ／ＩＥＣ１４４９６−１５ 第４版に定義されているように、タイプ「ｔｒｉｆ」のサンプルグルーピングまたはデフォルトサンプルグルーピングを定義することによって、合成（コンポジション）内の各タイルトラックの相対２次元座標を提供することができる。

別の代替処理として、新しいエンティティグループを定義することによって、空間合成シグナリングを提供することができる。エンティティグループは、アイテムまたはトラックのグループである。エンティティグループは、ＭｅｔａＢｏｘ内のＧｒｏｕｐｓＬｉｓｔＢｏｘ内に示される。トラックを参照するエンティティグループは、ファイルレベルのＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘまたはムービーレベルのＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘで指定できる。ＧｒｏｕｐＬｉｓｔＢｏｘ（「ｇｒｐｌ」）には、定義されたグループピングタイプを示す関連する４文字コードとともに、それぞれＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘと呼ばれるフルボックスのセットが含まれる。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは以下のように定義される：

通常、ｇｒｏｕｐ＿ｉｄはグループのｉｄを提供し、ｅｎｔｉｔｙ＿ｉｄの設定はエンティティグループに関連するトラックのｔｒａｃｋ＿ＩＤを提供する。ｅｎｔｉｔｙ＿ｉｄの設定に続いて、特定のｇｒｏｕｐｉｎｇ＿ｔｙｐｅの追加データを定義することによって、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘの定義を拡張することができる。一実施形態によれば、たとえば（エンティティグループ合成のための）「ｅｇｃｏ」に等しいｇｒｏｕｐｉｎｇ＿ｔｙｐｅを伴う新しいＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは、空間的に関連するビデオビットストリームまたはビデオサブビットストリームの合成を記述するように定義できる。ｅｎｔｉｔｙ＿ｉｄの設定には、グループを構成するトラック（サブピクチャ、タイルトラック、合成トラック）のｔｒａｃｋ＿ＩＤの設定が含まれる。合成によって形成される画像の全体的なサイズは、この新しいｇｒｏｕｐｉｎｇ＿ｔｙｐｅ「ｅｇｃｏ」に関連する追加データの一部として提供することができる。

ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（「ｅｇｃｏ」）は以下のように定義される：

タイプ「ｅｇｃｏ」のエンティティグルーピングによって定義される合成内の各トラックの相対的な２次元座標はＩＳＯ／ＩＥＣ１４４９６−１５ 第４版に定義されるように、各タイルトラック内のタイプ「ｔｒｉｆ」のサンプルグルーピングまたはデフォルトサンプルグルーピングを定義することによって提供することができる。代替処理として、相対的な２次元座標は、グループに関係する各タイルトラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する新しい汎用フルボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（「２ｄｃｏ」）として定義することができる。

ｅｎｔｉｔｙ_ｇｒｏｕｐ_ｉｄは、グループを定義する、関連付けられたＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（「ｅｇｃｏ」）の識別子を提供する。

ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙは、合成内のこのトラックのサンプルの左上隅の水平および垂直位置を提供する。

ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔは、合成内のこのトラックのサンプルの幅と高さを提供する。

代替処理として、この新しい汎用ボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（「２ｄｃｏ」）は、以下のように新しいサンプルグルーピングとして定義できる：

ステップ２６０では、追加のシグナリングがトラックに関連付けられる。トラックがプレゼンテーションに十分でないか、または単独で提示されることが意図されていないかどうかをクライアントに知らせるために、シグナリングが追加される。

実際、いくつかのトラックには、単独では復号できない部分ビットストリームのみが含まれている場合がある。たとえば、これは、関連付けられたタイルベーストラック無しに復号できない「ｈｖｔ１」タイプのいくつかのタイルトラックの場合などである。

さらに、コンテンツ作成者は、いくつかのトラックが単独で提示されることを意図されておらず、メディアプレゼンテーションにおけるエントリポイントを構成しないことをクライアントに通知することを望む場合がある。

実際、ＩＳＯＢＭＦＦファイルに複数のビデオトラックが含まれている場合、これらのビデオトラックのうち１つ以上がメイントラックとしてシグナリングされることで、メディアプレイヤが、ユーザに公開するための、またはストリーミングマニフェストに公開するためのトラックの選択に役立つ。メイントラックシグナリングは、メディアファイルへのメディアプレーヤのエントリポイントを提供する。実際、同じレベルの重要度を有するトラックの長いリストを有する代わりに、いくつかは、より重要度が高く、一種の主要アイテムとしてプレーヤによって優先的に処理されるものとして注釈付けされるか、または記述される。

第１の実施形態では、トラックが単独で表示されることを意図していない情報をトラックヘッダにシグナリングすることができる。各トラックには、いくつかのトラックの特性を指定するトラックヘッダボックス「ｔｋｈｄ」（必須）がある。ＩＳＯＦＢＭＦＦフルボックスとして、このトラックヘッダボックスは、ボックスと関連付けられた特定のシグナリングに使用できる２４ビットのフラグパラメータを有する。メディアトラックのトラックヘッダのフラグの値は、プレゼンテーションでのトラックの使用方法に関する情報を提供するためにすでに使用されている（ｔｒａｃｋ＿ｅｎａｂｌｅｄ、Ｔｒａｋ＿ｉｎ＿ｍｏｖｉｅ、ｔｒａｃｋ＿ｉｎ＿ｐｒｅｖｉｅｗなど）。ビデオトラックが「単独で提示されることを意図している」か否かを示すために、フラグの新しい特定値「ｔｒａｃｋ＿ｎｏｎ＿ｄｉｓｐｌａｙａｂｌｅ＿ａｌｏｎｅ」をトラックヘッダボックスに定義することができる。この新しいフラグは、以下のように定義される：
「ｔｒａｃｋ＿ｎｏｎ＿ｄｉｓｐｌａｙａｂｌｅ＿ａｌｏｎｅ」:＝０ｘ００００１０は、トラックが単独で表示されることを意図しておらず、プレビューに使用できないことを示す（ｔｒａｃｋ＿ｉｎ＿ｐｒｅｖｉｅｗフラグ値をオーバーライドする）。デフォルトでは、このフラグ値は設定されない。トラックヘッダフラグのデフォルト値は変更されず、７に等しいことに留意されたい（ｔｒａｃｋ＿ｅｎａｂｌｅｄ ０ｘ１、ｔｒａｃｋ＿ｉｎ＿ｍｏｖｉｅ ０ｘ２、ｔｒａｃｋ＿ｉｎ＿ｐｒｅｖｉｅｗ ０ｘ４）。

第２の実施形態では、単独で表示されることが意図されていないトラックを補助トラックとして定義することができる。補助トラックはビデオトラックと同じようにコーディングされるが、ＭｅｄｉａＢｏｘのＨａｎｄｌｅｒＢｏｘで「ｖｉｄｅ」の代わりにハンドラタイプ値「ａｕｘｖ」を使用し、視覚的に表示することは意図されていない。代替処理として、ビデオ用の新しいハンドラタイプ「ｓｕｂｖ」およびオーディオ用の「ｓｕｂａ」は、トラックがそれぞれビデオまたはオーディオトラックと同じであるが、プレゼンテーションには十分ではないか、または単独で提示されることを意図していないことを知らせるように定義することができる。

第３の実施形態では、トラックがプレゼンテーションに十分でないか、または単独で提示されることを意図していないという情報を、トラックグループ情報の一部としてシグナリングすることができる。実際、サブピクチャ合成トラックグループ（つまり、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが「ｓｐｃｏ」に等しいＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内のｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値が同じトラック）にマッピングされたトラックは、提示可能な視覚的コンテンツをまとめて表す。しかし、このグルーピングにマッピングされた個々のトラックの各々は他のトラックなしに単独で提示されるように意図されてもよいし、されなくてもよい。単純な代替処理は、トラックが「単独で提示されることを意図している」か否かを示す新しいパラメータ「ｎｏｔ＿ｏｕｔｐｕｔ＿ｔｒａｃｋ」を「ｓｐｃｏ」ボックスに定義することで構成される。

代替実施形態では、このパラメータは単一ビットで表すことができ、他の７ビットは以下のように将来の使用または他のシグナリングのために予約される：

ｎｏｔ＿ｏｕｔｐｕｔ＿ｔｒａｃｋを１に設定した場合、トラックが単独で表示されることは意図されていないことを示す。デフォルトでは、これはゼロであると想定され、トラックはユーザへのプレゼンテーションのために選択可能である。同様に、トラックがＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘを含まない場合、それは単独で表示可能であると想定される。

第４の実施形態では、トラックがプレゼンテーションに十分でないか、または単独で提示されることを意図していないという情報は、他のトラック情報または他のトラック情報の組み合わせから推論することができる。

例えば、トラックの表示可能なステータスは、トラックの依存性を提供するトラック参照ボックス（「ｔｒｅｆ」）と、トラック内のサンプルに対する共通の定義を提供するＳａｍｐｌｅＥｎｔｒｙ（ビデオに対するＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ）とに基づいて検出することができる。

たとえば、トラックがタイプ「ｓａｂｔ」のトラック参照を有し、タイプ「ｔｂａｓ」のトラック参照を持ついくつか他のトラックによって参照されている場合、そのトラックはタイルベーストラックとしてマークされ、再生可能／選択可能トラックとしてマークされている。トラック参照「ｓａｂｔ」を介してこのトラックから参照されるすべてのトラックは、タイプ「ｈｖｔ１」のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙを有している場合、タイルトラック（「ｈｖｔ１」）としてマークすることができ、再生不能トラックとしてマークすることができる。あるいは、トラックがタイプ「ｔｂａｓ」のトラック参照およびタイプ「ｈｖｔ１」のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙを有する場合、トラックはタイルトラック（「ｈｖｔ１」）としてマークされ、再生不能トラックとしてマークされる。このトラックから参照されるすべてのトラックは、タイルベーストラックとしてマークされ、再生不能トラックとしてマークされる。あるいは、トラックがタイプ「ｓｃａｌ」のトラック参照を有する場合、トラックはエクストラクタトラックであり、再生可能トラックとしてマークされる。このトラックから参照されるすべてのトラックは、再生可能なタイルトラック（「ｈｖｃ１」）としてマークされる。デフォルトでは、再生可能トラックとしてマークすることができる。しかし、コンテンツ作成者は、デフォルトで再生不能トラックとしてそれらをマークすることを好む場合がある。さらに、トラックがトラック参照（「ｔｒｅｆ」）ボックスを含まず、トラックグループに関係しない場合、ＳａｍｐｌｅＥｎｔｒｙをチェックしなければならない。トラックが「ｈｖｃ１」または「ｈｅｖ１」として検出された場合、そのトラックは少なくとも再生可能トラックとしてマークされる。

第５の実施形態では、第３の実施形態の代替処理として、２次元座標（ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈおよびｔｒａｃｋ＿ｗｅｉｇｈｔ）がＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ（「ｓｐｃｏ」）で定義されていない場合、パラメータｎｏｔ＿ｏｕｔｐｕｔ＿ｔｒａｃｋは、以下に示すようにＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ（「ｓｐｃｏ」）で定義することができる：

あるいは、パラメータｎｏｔ＿ｏｕｔｐｕｔ＿ｔｒａｃｋは、２ＤＣｏｏｒｄｉｎａｔｅＩｎｔｅＴｒａｃｋＧｒｏｕｐＢｏｘ（）または２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（）またはＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙまたはサンプルグループ記述エントリレベルで定義された同様のボックスで定義できる。

さらにステップ２６０では、同様に、メイントラックまたは部分トラックを識別するために、明示的にシグナリングを追加することができる。

メディアファイル内のメイントラックとは、同じメディアタイプのトラックより、または異なるメディアタイプの関連トラックより重要と考えられるトラックのことである。例えば、メインビデオトラックは、メディアプレーヤが選択及び再生のためにユーザに公開すべきトラックである。また、メディアファイルをストリーミングまたは送信するときは、メイントラックをストリーミングマニフェストで公開すべきである。例えば、サブピクチャまたはタイルの空間合成の場合、メイントラックは合成トラックとすることができる。この場合も、空間合成の場合には、メイントラックは、（サブピクチャまたはタイルトラックとは反対に）フルピクチャに対応するビデオトラックとすることができる。プレーヤによってレンダリングされるトラックのセットにおいて、メイントラックは、優先的にレンダリングされるトラックとすることができる。送信コンテキストでは、メイントラックは優先的にフェッチされるトラックである。例えば、メディアファイル内のメイントラックは、メインメディアコンポーネントとしてストリーミングマニフェストに記述することができる。たとえば、ＭＰＥＧ ＤＡＳＨのマニフェストでは、メイントラックは、プリセレクション要素のメインのＡｄａｐｔａｔｉｏｎＳｅｔに、または「ｍａｉｎ」値を持つまたはメイントラックであることを示すＬａｂｅｌを持つＲｏｌｅ ｄｅｓｃｒｉｐｔｏｒを持つＡｄａｐｔａｔｉｏｎＳｅｔにすることができる。本発明は、メディアファイル内のメイントラックをシグナリングする様々な方法を説明する。

メディアファイル内の部分トラックは、メイントラックと組み合わせて、またはメイントラックおよび他の部分トラックと組み合わせてのみ処理することができるトラックである。タイプ「ｈｖｔ１」のタイルトラックは、部分トラックの例である。これらは、タイルベーストラックと組み合わせてのみ処理することができる。

メイン／部分トラックシグナリングは、上記のシグナリング「提示に十分でないか、または単独で提示されることを意図しない」シグナリングと同様にシグナリングすることができる。トラックヘッダフラグ内の明示的なフラグ値（例えば「Ｉｓ＿Ｍａｉｎ＿ｔｒａｃｋ」：＝０ｘ００００２０）によって、または下図のようなサブピクチャ合成トラックグループ（「ｓｐｃｏ」）ボックス内の新しい特定のパラメータ「ｍａｉｎ＿ｔｒａｃｋ」によってシグナリングすることができる：

このパラメータｍａｉｎ＿ｔｒａｃｋは、トラックグループ内のトラックがメイントラックまたはフルピクチャトラックであることを示すために使用することができる。この場合、パーサ（ｐａｒｓｅｒ）は、トラックグループ内のこのメイントラックまたはフルピクチャトラックのみがレンダリングされるべきである（値０に設定されているこのパラメータを有するグループ内の他のトラックではない）と考える。言い換えれば、他のトラックは部分トラックとして考慮される。

代替処理として、メイントラックは、トラック内のＵｓｅｒＤａｔａＢｏｘ（「ｕｄｔａ」)内のＫｉｎｄＢｏｘ（「ｋｉｎｄ」）を使用してシグナリングすることができる。ＫｉｎｄＢｏｘは、トラックにその役割または種類をラベル付けすることを可能にする。メイントラックは特定のｓｃｈｅｍｅＵＲＩ、例えば「ｕｒｎ：ｍｐｅｇ：１４４９６−１２：ｍａｉｎ」でＫｉｎｄＢｏｘを定義することによってシグナリングされる。

ｍｐ４ライタはメイントラックシグナリングを利用して、メイントラックをＤＡＳＨプリセレクション要素内のメイン適応設定（ａｄａｐｔａｔｉｏｎ ｓｅｔ）として設定し、部分トラックをＤＡＳＨ ＭＰＤ内の「隠れた」適応設定として設定することができる。「隠れた」適応設定は、ユーザによって選択されることが意図されていない適応設定である。それらは例えば「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｎｏｔ−ｓｅｌｅｃｔａｂｌｅ：２０１６」に設定された特定の＠ｓｃｈｅｍｅＩｄＵＲＩを有する関連する補足的または必須の記述子を定義することによって、ＤＡＳＨ ＭＰＤ内で明示的にシグナリングすることができる。

ステップ２７０では、トラックのためのおよびトラックの合成のためのコンテンツカバレッジ情報が、ビデオビットストリームまたはビデオサブビットストリームのカプセル化を記述するメタデータに追加される。

トラックカバレッジ情報は、このトラックによって表されるコンテンツによってカバーされる球上の領域に関する情報を提供する。

合成カバレッジ情報は、１つ以上のトラックの組み合わせに関連する球面上の領域に関する情報を提供する。例えば、ムービーファイルが空間的関係を有する複数のビデオトラックを含む場合、合成カバレッジ情報は、これらの複数のビデオトラックの空間的合成によってカバーされる球面上の領域である。別の例では、メディアファイルは複数のビデオトラックと、この一連のトラックをどのようにレンダリングするかを示す変換マトリックスとを含み、合成カバレッジ情報は、組み立てられた一連のトラックによってカバーされる領域に対応する。「合成カバレッジ情報」は、「グローバルカバレッジ情報」または「トラックグループ合成情報」と表すこともできる。合成またはグローバルカバレッジ情報は、これらの複数のビデオトラックのサブセットの合成の結果得られる球面上の領域を記述することもできる。

第１の実施形態として、トラックカバレッジ情報および合成カバレッジ情報は追加のシグナリングなしに、単一の共通のＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを使用してシグナリングすることができる。このような場合、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘの範囲は、ボックス階層内のこのボックスの定義の場所に依存する。クライアントは、カバレッジ情報がどこで宣言されるかを考慮することによって、カバレッジ情報がトラックコンテンツに関連するか、またはコンテンツ全体に関連するかを判定することができる。この実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、以下のように定義される：

ここで、ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅはカバーされる球領域の形状を指定し（例えば、ＭＰＥＧ ＯＭＡＦ、ＩＳＯ／ＩＥＣ２３０００−２０で定義されるものとして）、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（）は、以下のように定義される：

ここで、ｃｅｎｔｅｒ＿ｙａｗ、ｃｅｎｔｅｒ＿ｐｉｔｃｈ、およびｃｅｎｔｅｒ＿ｒｏｌｌはグローバル座標軸に対するカバー領域のビューポートの向きを指定し、ｈｏｒ＿ｒａｎｇｅおよびｖｅｒ＿ｒａｎｇｅは、存在する場合、カバーされる球領域の水平範囲および垂直範囲をそれぞれ指定し、補間は、現在使用されていない。

以下に説明する代替の実施形態では、メディアコンテンツは図１のステップ１２５で単一のフレームとしてパックするまたは組み立てることができる。次に、ステップ１５０において、パックされたフレームは単一のトラックとしてカプセル化される。

特に、メディアコンテンツは、立体画像を含む立体コンテンツである。立体画像は先に説明したように、異なるビュー（典型的には、左ビュー及び右ビュー）から構成される。この実施形態では、図１を参照して説明したように、ビューは、並列配置または上下配置に従って、単一のフレームを形成するようにパックされる。

第１の実施形態では、パックされたフレームを構成するビューについての異なるコンテンツカバレッジ情報をシグナリングすることが提案される。言い換えると、単一フレーム内にパックされたビューが立体画像の左ビューであるか又は右ビューであるかをシグナリングすることが提案される。

その目的では、例えば「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」ボックスのような１つ以上のビューのカバレッジに関する情報を含む１つ又は２つのボックスだけでなく、「ｐｒｏｊｅｃｔｅｄ ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ｖｉｄｅｏ ｂｏｘ」（「ｐｏｖｄ」）又はＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ（「ｓｐｃｏ」）において許可されるボックスはない。

さらに、立体コンテンツをシグナリングするためのパラメータ、例えば、パラメータ「ｖｉｅｗ＿ｉｄｃ」（７．３．６章のカバレッジ情報ボックスで定義される）を、異なる可能なカバレッジをシグナリングするために使用することができる。たとえば、「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」が、ｖｉｅｗ＿ｉｄｃ＝「１」の場合は立体コンテンツの左ビューのみのカバーされた球領域を表し、ｖｉｅｗ＿ｉｄｃ＝「２」の場合は右ビューを表し、ｖｉｅｗ＿ｉｄｃ＝「３」の場合は両方のビューの同じカバレッジを表すかを、「ｖｉｅｗ＿ｉｄｃ」がシグナリングする。

この第１の実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、以下のように定義される：

好ましくは、ｖｉｅｗ＿ｉｄｃが「０」に等しい場合、それはカバレッジ球領域がモノスコピック（平面視）であることを示し、「１」に等しい場合、それはカバレッジ球領域が立体コンテンツの左ビュー上にあることを示し、「２」に等しい場合、それはカバレッジ球領域が立体コンテンツの右ビュー上にあることを示し、「３」に等しい場合、それはカバレッジ球領域が左ビューおよび右ビューの両方上にあることを示す。

第２の実施形態では、制限された単純な変更を暗に意味するがコストがかかりすぎる「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」の複数のインスタンスを許可するのではなく、例えば「ｄｉｆｆｅｒｅｎｔ＿ｃｏｖｅｒａｇｅ＿ｐｅｒ＿ｖｉｅｗ」と呼ばれる新しいフラグを、前の「ｖｉｅｗ＿ｉｄｃ」パラメータに加えて、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘに定義して、各ビューについて異なるコンテンツカバレッジ情報があるか否かシグナリングすることができる。

この第２の実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、以下のように定義される：

前述のように、「ｖｉｅｗ＿ｉｄｃ」が「０」に等しいことはカバレッジ球領域がモノスコピックであることを示し、「ｖｉｅｗ＿ｉｄｃ」が「１」に等しいことはカバレッジ球領域が立体コンテンツの左ビュー上にあることを示し、「ｖｉｅｗ＿ｉｄｃ」が「２」に等しいことはカバレッジ球領域が立体コンテンツの右ビュー上にあることを示し、「ｖｉｅｗ＿ｉｄｃ」が「３」に等しいことはカバレッジ球領域が左ビューおよび右ビューの両方上にあることを示す。

タイプ「ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅ」はカバーされる球領域の形状を指定する。

構造「ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（）」は次のように定義される：

ここで：
−ｃｅｎｔｅｒ＿ａｚｉｍｕｔｈおよびｃｅｎｔｅｒ＿ｅｌｅｖａｔｉｏｎは、球領域の中心を指定する。ｃｅｎｔｅｒ＿ａｚｉｍｕｔｈは−１８０＊２^１６〜１８０＊２^１６−１の範囲内、ｃｅｎｔｅｒ＿ｅｌｅｖａｔｉｏｎは−９０＊２^１６〜９０＊２^１６の範囲内であり、
−ｃｅｎｔｅｒ＿ｔｉｌｔは球領域の傾斜角度を指定する。ｃｅｎｔｅｒ＿ｔｉｌｔは、−１８０＊２^１６〜１８０＊２^１６−１の範囲内とする。

構造「ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（）」の他のパラメータのセマンティクス（意味）は、前の実施形態と同じである。「ｃｅｎｔｅｒ＿ａｚｉｍｕｔｈ」、「ｃｅｎｔｅｒ＿ｅｌｅｖａｔｉｏｎ」、および「ｃｅｎｔｅｒ＿ｔｉｌｔ」は、それぞれ、前の実施形態における「ｃｅｎｔｅｒ＿ｙａｗ」、「ｃｅｎｔｅｒ＿ｐｉｔｃｈ」、および「ｃｅｎｔｅｒ＿ｒｏｌｌ」と同等であることに留意されたい。

より正確には、構造ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（ｒａｎｇｅ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇ、０）は以下を表す：
−「ｖｉｅｗ＿ｉｄｃ」＝「０」の場合、モノスコピックビューのカバーされた球領域、
−「ｖｉｅｗ＿ｉｄｃ」＝「１」またはｖｉｅｗ＿ｉｄｃ＝「３」の場合、左ビューのカバーされた球領域、
−「ｖｉｅｗ＿ｉｄｃ」＝「２」の場合、右ビューのカバーされた球領域、
−「ｖｉｅｗ＿ｉｄｃ」＝「３」であり「ｄｉｆｆｅｒｅｎｃｅ＿ｃｏｖｅｒａｇｅ＿ｐｅｒ＿ｖｉｅｗ」＝「０」の場合、左右両方のビューのカバーされた球領域。

ここで、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（ｒａｎｇｅ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇ、１）は、存在するなら（すなわち、ｖｉｅｗ＿ｉｄｃ＝「３」およびｄｉｆｆｅｒｅｎｔ＿ｃｏｖｅｒａｇｅ＿ｐｅｒ＿ｖｉｅｗ＝「１」の場合）右ビューのカバーされた球領域を表す。「ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅ」がビュー間で異なる場合、ボックス「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」ではなく構造「ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ」でこのパラメータを宣言する方がより適切である。

ボックス「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」に関連する第３の実施形態によれば、ビューごとに異なるカバレッジがある場合に、「ｖｉｅｗ＿ｉｄｃ」パラメータに追加ビットを使用することが提案される。追加ビットを使用すると、２つの異なるカバレッジの存在を示すことができる。第３の実施形態では、「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」が以下のように定義される：

ここで、
−「ｖｉｅｗ＿ｉｄｃ」が「０」に等しいことはカバレッジ球領域がモノスコピックであることを示し、
−「ｖｉｅｗ＿ｉｄｃ」が「１」に等しいことは、カバレッジ球領域が立体コンテンツの左ビュー上にあることを示し、
−「ｖｉｅｗ＿ｉｄｃ」が「２」に等しいことは、カバレッジ球領域が立体コンテンツの右ビュー上にあることを示し、
−「ｖｉｅｗ＿ｉｄｃ」が「３」に等しいことは、カバレッジ球領域が左ビューおよび右ビューの両方上にあり、
−「ｖｉｅｗ＿ｉｄｃ」＝「４」に等しいことは、カバレッジ球領域が左ビューおよび右ビューの両方上にあり、各ビューが異なるカバレッジ情報を有することを示し、
−「ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ」は前の実施形態と同じセマンティクスを有する：ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（ｒａｎｇｅ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇ，０)が左ビューのカバーされた球領域を表し、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（ｒａｎｇｅ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇ，１）が右ビューのカバーされた球領域を表す。

第４の実施形態では、「ｓｈａｐｅ＿ｔｙｐｅ」パラメータを１バイトで表すためにいくつかの予約されたビットを使用することによって、よりコンパクトなボックス「ｃｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」を有することが提案される。以下のように、メディアプレゼンテーションを記述するファイルに存在する各ボックス「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」に対して１バイトを節約することができる：

ここで、上記の各パラメータのセマンティクスは同じままである（表現サイズのみが小さくなる）。

したがって、ボックス「ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」は、コンテンツによってカバーされる球体上の領域に関する情報を提供する。コンテンツの性質は、このボックスのコンテナに依存する。ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ「ｓｐｃｏ」に存在する場合、コンテンツは同じサブピクチャ合成トラックグループに属する全てのトラックによって表されるコンテンツ全体を指し、これらのトラックから構成される合成ピクチャは、コンテンツ全体のパックピクチャと呼ばれる。トラックのサンプルエントリ内に存在する場合、コンテンツはこのトラック自体によって表されるコンテンツを指し、このトラック内のサンプルのピクチャは、コンテンツ全体のパックピクチャと呼ばれる。トラックに対してＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎ Ｂｏｘが存在しない場合、それは、コンテンツが球全体をカバーすることを示す。

Ｐｒｏｊｅｃｔｅｄ ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ｖｉｄｅｏ ｂｏｘ（「ｐｏｖｄ」）は、ＭＰＥＧ ＯＭＡＦによって定義され、トラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する中間ボックスであることに留意されたい。

さらに、ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎトラックグループボックス（「ｓｐｃｏ」）は、以下のように修正される：

ＩＳＯＢＭＦＦ ＦｕｌｌＢｏｘＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ（）をＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘに追加する以外の代替処理として、以下のようにＳｐｈｅｒｅＲｅｇｉｏｎＯｎＳｔｒｕｃｔを直接含めることもできる：

さらなる代替処理として、以下に示すように、合成のためのカバレッジ情報の存在を、たとえばｉｓ＿ｃｏｖｅｒａｇｅ＿ｉｎｆｏ＿ｉｓ＿ｐｒｅｓｅｎｔと表される追加パラメータの値に条件付けすることができる：

実際、ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘは、このＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘによって定義されるグループに関連するすべてのトラックで定義されているため、トラックグループ内に合成トラックがある場合、合成カバレッジ情報はこの合成トラックに対してのみ定義することができ、各タイルトラックに対して定義する必要はない。

第２の実施形態として、トラックカバレッジ情報および合成カバレッジ情報は、ローカルインジケーションとグローバルインジケーションとを区別するためのフラグ値を有する単一の共通ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを使用してシグナリングすることができる。ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘはＩＳＯＢＭＦＦ ＦｕｌｌＢｏｘであるため、トラックカバレッジとグローバルカバレッジとの区別は、ボックスのフラグパラメータによって表すことができる。

この第２の実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、以下のように定義される：

ボックスの構造は、ローカル及び合成カバレッジ情報が同じトラックに定義されなければならない場合にボックスの複数のインスタンスが定義できることを除いて、前の実施形態とほぼ同じである。

次に、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、コンテンツによってカバーされる球体上の領域に関する情報を提供するものとして定義される。コンテンツの性質は、フラグパラメータで与えられる。カバレッジ情報フラグのデフォルト値は０である。つまり、このボックスはコンテンツ全体のカバレッジを記述する。このトラックがサブピクチャ合成トラックグループに属する場合、コンテンツ全体は同じサブピクチャ合成トラックグループに属するすべてのトラックによって表されるコンテンツを指し、これらのトラックから構成される合成ピクチャは、コンテンツ全体のパックピクチャと呼ばれる。そうではない場合、コンテンツ全体は、このトラック自体によって表されるコンテンツを指し、このトラック内のサンプルのピクチャは、コンテンツ全体のパックピクチャと呼ばれる。

カバレッジ情報フラグの値が１である場合、このボックスは、このトラックによって表されるコンテンツのパックされたピクチャによってカバーされる球形領域を記述する。

このボックスがないことは、コンテンツが球全体をカバーすることを示す。

さらに、新たなフラグ値は、以下のように定義される：
ｃｏｖｅｒａｇｅ＿ｌｏｃａｌは、カバレッジ情報がボックスを含むトラックに対してローカルであることを示す。フラグ値は０ｘ０００００１である。デフォルトでは、この値は設定されていない。

第２実施形態の代替処理として、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘの定義はグローバルカバレッジ情報を持つＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘによって表されるトラックグループ（例えば、「ｓｐｃｏ」ボックスの１つ）を識別するｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを含むことができる。

次に、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは以下ように定義される：

代替処理として、第３の実施形態では、２つの異なるボックスが合成カバレッジ情報（ＴｒａｃｋＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ）またはトラックカバレッジ情報（ＴｒａｃｋＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ）のいずれかを記述するように定義される。ＣｏｍｐｏｓｉｔｉｏｎＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘが、このトラックが複数のトラックグループに関係する場合に、トラック内で複数回定義することができることを除いて、以前の実施形態と同じセマンティクスで、ボックスは以下のように定義される。パラメータｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄにより、ＣｏｍｐｏｓｉｔｉｏｎＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘで記述されたトラックグループ（たとえば、「ｓｐｃｏ」ボックスの１つ）を識別することができる。

代替処理として、第４の実施形態では、ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘトラックグループ（「ｓｐｃｏ」）またはＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ(第１の実施形態）内のＰｒｏｊｅｃｔｅｄ ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ｖｉｄｅｏ ｂｏｘ（「ｐｏｖｄ」）のいずれかにおいて、トラックおよび合成カバレッジ情報と、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを定義する機能とを区別するために、フラグ（第２の実施形態）を使用して、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを伴う実施形態を組み合わせることが可能である。両方のアプローチを可能にすることによって、これはＯＭＡＦコンテンツのためのカプセル化モードに依存するカバレッジシグナリングにおける柔軟性を提供する：
−単一トラックカプセル化：単一のＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、（Ｃｏｖｅｒａｇｅ＿ｌｏｃａｌフラグ値が設定されていない）トラックの「ｐｏｖｄ」ボックスで宣言できる
−複数トラックカプセル化：
〇 合成トラックあり：グローバルカバレッジ情報は、この合成トラックの「ｐｏｖｄ」内のＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘで宣言される（フラグ値ｃｏｖｅｒａｇｅ＿ｌｏｃａｌは設定されない）。オプションとして、サブピクチャトラックはＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを宣言できる（フラグ値Ｃｏｖｅｒａｇｅ＿ｌｏｃａｌが設定されている）。
〇 合成トラックなし：合成カバレッジ情報は、フラグ値ｃｏｖｅｒａｇｅ＿ｌｏｃａｌが設定されていない「ｓｐｃｏ」ボックス内のＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘで宣言される。オプションとして、サブピクチャトラックはＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘを宣言できる（フラグ値Ｃｏｖｅｒａｇｅ＿ｌｏｃａｌが設定されている）。

代替処理として、第５の実施形態では、トラックの合成が、トラックグループ（「ｔｒｇｒ」）メカニズムを使用するのではなく、新しいエンティティグループを使用して記述される場合、即ち、ファイルレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘ内またはムービーレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘ内に特定のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを定義することによって記述される場合、合成カバレッジ情報は、この特定のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘのプロパティとして直接定義することができ、即ち、上記の第１の実施形態で記述されたＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎｂｏｘはこの特定のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ内で直接宣言することができる。トラック関連のカバレッジ情報は、トラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内のＰｒｏｊｅｃｔｅｄ ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ｖｉｄｅｏ ｂｏｘ内で依然として定義される。

この特定のエンティティグループは、（ステップ２５０を参照して定義されたエンティティグループ「ｅｇｃｏ」に基づいて）以下のように見える：

または、以下のようにＳｐｈｅｒｅＲｅｇｉｏｎＯｎＳｔｒｕｃｔを直接含めることも可能である：

代替処理として、第６の実施形態では、トラックハンドラタイプに依存することによって、カバレッジ情報がトラックグループボックス「ｓｐｃｏ」に存在するか否かを決定することも可能である。メイントラックに「ｖｉｄｅ」ハンドラタイプがあり、サブピクチャトラックに「ａｕｘｖ」または「ｓｕｂｖ」トラックがあると想定すると、「ｓｐｃｏ」ボックスのｉｓ＿ｃｏｖｅｒａｇｅ＿ｉｎｆｏ＿ｉｓ＿ｐｒｅｓｅｎｔフラグが「ａｕｘｖ」または「ｓｕｂｖ」トラックに対して０に設定され（すなわちカバレッジ情報が存在しない）、「ｖｉｄｅ」トラックに対して１に設定される（すなわちカバレッジ情報が存在する）。

図２に戻ると、ステップ２８０において、仮想現実メディアコンテンツが実際には立体仮想現実メディアコンテンツであるかどうか、すなわち、左右のビューを含むかどうかがチェックされる。

コンテンツがモノスコピックである場合、プロセスは直接ステップ２９０に進む。

コンテンツが立体視（ステレオスコピック）である場合、ステップ２８５で、立体シグナリングがカプセル化に追加される。

立体コンテンツの場合、従来、左ビューシーケンスと右ビューシーケンスとの両方が立体カメラから取得され、合成タイプに従ってビデオシーケンスまたは２つのビデオシーケンスに合成される。

立体コンテンツの２つの異なるビューを表す２つのフレームを１つの単一フレームに結合するプロセスは、フレームパッキングと呼ばれる（図１のステップ１２５参照）。

フレームパッキングは、ステレオペアを形成する２つのビューを単一のフレームにパックすることからなる。よく知られて使用されるフレームパッキング配置がいくつか存在する：並列、上下、フレームシーケンシャル、垂直ラインインターリーブド（Ｉｎｔｅｒｌｅａｖｅｄ）タイプ…。例えば、ＭＰＥＧアプリケーションフォーマットＩＳＯ／ＩＥＣ ２３０００ １１第１版（「ス立体ビデオアプリケーションフォーマット」）またはＩＳＯ／ＩＥＣ ２３００１−８第２版（「コーディング独立コードポイント（ＣＩＣＰ）」）のようないくつかのフレームパッキングスキームが、これらの配置の一部を規定する。フレームパッキングは例えば、ＩＳＯ／ＩＥＣ ２３００１−８第２版に定義された値６を有するＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅのように、各ビューを別々のフレームに保持することからなることもできる（「ＣＩＣＰ」）。

例えば、さらにＣＩＣＰ仕様によれば、フレームパッキング配置の値３は各復号フレームが２つの構成ビューの対応するフレームの並列パッキング配置を含むことをシグナリングし、値４は、各復号フレームが２つの構成ビューの対応するフレームの上下パッキング配置を含むことをシグナリングする。

トラックが立体メディアデータを含むかどうかをシグナリングするために、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘが、ＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙまたは下位ボックスの１つ（例えば、トラックのＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに埋め込まれた「ＳｃｈｅｍｅＩｎｆｏｒｍａｔｉｏｎＢｏｘ」）に定義される。

ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、立体コンテンツを記述するためのＩＳＯＢＭＦＦ構造である。ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、ビデオトラック内の復号されたフレームがステレオペアを形成する２つの空間的にパックされた構成フレームの表現を含むか、またはステレオペアの２つのビューのうちの１つを含むかのいずれかを示すために使用される。ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ内のパラメータは、フレームパッキングスキーム（ステレオ配置スキームとも呼ばれる）に関する情報およびこのフレームパッキングスキームによる現在の配置またはフレームへのビューのパッキングに関する情報を提供する。ＳｔｅｒｅｏＶｉｄｅｏＢｏｘはメディアファイルのサンプル記述（例えばＩＳＯＦＢＭＦＦのＳａｍｐｌｅＴａｂｌｅＢｏｘ内）の部分に記述されており、プレイヤがメディアファイルを復号およびレンダリングできる要件を提供する。

ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、（ＩＳＯ／ＩＥＣ１４４９６−１２によれば）以下のように定義されている：

ここで、ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄは、コンテンツが立体ディスプレイ上にのみ表示され得ること、またはモノスコピックシングルビューディスプレイ上に表示するためにどのビューが使用され得るかを示し、ｓｔｅｒｅｏ＿ｓｃｈｅｍｅは、使用されるステレオ配置スキームおよび使用されるスキームによるステレオインジケーションタイプを示す整数であり、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅは、使用されるステレオ配置スキームによるステレオ配置タイプを示す。

ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、左ビューフレームおよび右ビューフレームを１つの単一トラックを形成する共通のパックされたフレーム内にパックするために使用されるフレームパッキングスキームおよびフレームパッキング配置（例えば、ＣＩＣＰ ＩＳＯ／ＩＥＣ ２３００１−８の§７．４で定義されるような並列配置または上下配置）を記述することを可能にする。しかしながら、それは、使用中にフレームパッキング配置において左ビュー又は右ビューがどこに位置しているかを示すことを可能にしない。実際、例えば、並列配置の場合、左ビューが並列配置の左側または右側にあるかどうかを示さず、同様に、例えば、上下配置の場合も、左ビューが上下配置の上または下にあるかどうかを示さない。

ここでは、立体視に関する情報を含み、さらに、両方のフレームパッキング配置のためのそのようなインジケーションを含むボックスが提案される。

特定の実施形態では、「ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ」のセマンティクスが、前述の問題に対処するために修正される。

特に、ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４（すなわち、ＣＩＣＰ ＩＳＯ／ＩＥＣ ２３００１−８に定義されているフレームパッキング配置の使用を示す）の場合、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ内のｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅのシンタックスは、以下のように修正される：
「ｓｔｅｒｅｏ＿ｓｃｈｅｍｅが４に等しい」：長さパラメータの値は３」（３バイト）であり、例えば「ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ」パラメータのようなビューのタイプを示すパラメータは、ｕｎｓｉｇｎｅｄ ｉｎｔ（８）タイプの３つのシンタックス要素を含む。

第１のシンタックス要素は例えば、ＩＳＯ／ＩＥＣ２３００１−８からの「ＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅ」のようなフレームパッキングのタイプに関する情報を含む。

第２のシンタックス要素の最下位ビットは例えば、ＩＳＯ／ＩＥＣ２３００１−８で指定される「ＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇ」の値のようなサンプリングに関する情報を含み、一方、他のビットは予約され、「０」に設定される。

第３のシンタックス要素は、例えばＩＳＯ／ＩＥＣ２３００１−８からの「ＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅ」のように、フレームパッキングの構成フレームの役割（すなわち、どの構成フレームがどのビューに対応するか）を解釈するためのインジケーションを含み、一方、他のビットは予約され、「０」に設定される。

第１のシンタックス要素（例えば、「ＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅ」）は、「ｆｒａｍｅ ０」および「ｆｒａｍｅ １」と示される２つの構成フレームを考慮する選択されたステレオパッキング配置を提供する（例えば、ｆｒａｍｅ ０およびｆｒａｍｅ １は、第１のシンタックス要素の値が「３」である並列（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）であるか、または、値が「４」である上下（ｔｏｐ−ｂｏｔｔｏｍ）である）。

次に、第３のシンタックス要素（「ＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅ」）は、ステレオパッキング配置における構成フレームの意図された解釈を示すことを可能にする。その値が「１」である場合、それは、２つの構成フレームがステレオビューシーンの左ビューおよび右ビューを形成し、ｆｒａｍｅ ０が左ビューに関連付けられ、ｆｒａｍｅ １が右ビューに関連付けられることを示す。さらに、反対に、その値が「２」である場合、それは、２つの構成フレームがステレオビューシーンの右ビューおよび左ビューを形成し、ｆｒａｍｅ ０が右ビューに関連付けられ、ｆｒａｍｅ １が左ビューに関連付けられることを示す。任意の他の値は、フレームパック構成フレーム間に特定の関係がないことを示すものとして解釈されるべきである。

例として、上記実施形態によれば、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは以下のように、フレームパッキング配置（第１のシンタックス要素）、ｑｕｉｎｃｕｎｘｓａｍｐｌｉｎｇｆｌａｇ（第２のシンタックス要素）、およびパックされたフレームにおける左右のビューのそれぞれの位置（第３のシンタックス要素）を公開する：

代替実施形態では、パックされたコンテンツパラメータのタイプ（「ＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅ」）の解釈をシグナリングするために第３のバイトを使用するのではなく、第２のシンタックス要素の予約ビットから数ビット（２ビットのみが必要である）が、ＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅパラメータの情報を伝達するために使用されうる。このような場合、「ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ」内の「ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ」のシンタックスは以下のように修正できる：
例えば、「ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ」が４に等しい場合：
−ｌｅｎｇｔｈの値は「２」であり、「ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ」はｕｎｓｉｇｎｅｄ ｉｎｔ（８）の２つのシンタックス要素を含む；
−修正された第１のシンタックス要素は、例えば、ＩＳＯ／ＩＥＣ２３００１−８からの「ＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅ」のようなフレームパッキングのタイプに関する情報を含む；
−修正された第２のシンタックス要素の第１の最下位ビットは例えば、ＩＳＯ／ＩＥＣ２３００１−８で指定されたＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇの値のように、サンプリングに関する情報を含み、新しい第２のシンタックス要素の第２および第３の最下位ビットは例えば、ＩＳＯ／ＩＥＣ２３００１−８で指定された「ＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅ」の値のように、フレームパッキングの構成フレームの役割を解釈するためのインジケーションを含み、したがって、修正された第２のシンタックス要素が値「０」または「３」を取る場合、パックされたフレーム内のそれぞれの位置に関する情報が指定されないことを意味し、修正された第２のシンタックス要素内の残りのビットは、予約され、「０」に設定される。

別の代替実施形態では、表示パックフレーム内の左ビューおよび右ビューの位置のインジケーションはオプションである。このような場合、ｓｔｅｒｅｏ_ｓｃｈｅｍｅ=「４」でｌｅｎｇｔｈ＝「２」のＳｔｅｒｅｏＶｉｄｅｏＢｏｘの「ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ」は、デフォルトでＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅの値１を有するものとして解釈されるべきである。

ＳｔｅｒｅｏＶｉｄｅｏＢｏｘの他のｓｔｅｒｅｏ＿ｓｃｈｅｍｅｓが、例えば、ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝「１」又は他のフレームパッキング配置を参照する将来のｓｔｅｒｅｏ＿ｓｃｈｅｍｅのために、使用中のフレームパッキング配置における左ビュー又は右ビューの位置のインジケーションから利益を得ることができることに留意されたい。

「ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ」内のビットまたはバイトに関して追加のコストなしに、各ビューの空間フリッピング情報（すなわち、２つの構成フレームのうちの１つが、表示のためにその意図された向きに対して空間的にフリップされるというインジケーション）ならびにビュー間符号化依存性を、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅパラメータに記述することができることに留意されたい。これは、第２のシンタックス要素の残りのビットを使用して行うことができる。例えば、本発明に従って、ＨＥＶＣビデオビットストリームからの以下のパラメータを、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅの第２または第３のシンタックス要素の残りのビットに追加することができる：
−ＩＳＯ／ＩＥＣ２３００８−２で定義されるようなセマンティクスで、残りのビットの１つにおいて、空間フリッピングの有無を示すパラメータ
−ＩＳＯ／ＩＥＣ２３００８−２で定義されるような、別の残りのビットにおいて（２つの構成フレームのうちのどちらがフリップされるかを示す）ｆｒａｍｅ０＿ｆｌｉｐｐｅｄ＿ｆｌａｇを示すパラメータ。
−ＩＳＯ／ＩＥＣ２３００８−２で定義されているｆｒａｍｅ０＿ｓｅｌｆ＿ｃｏｎｔａｉｎｅｄ＿ｆｌａｇまたはＩＳＯ／ＩＥＣ１４４９６−１０で定義されているｌｅｆｔ＿ｖｉｅｗ＿ｓｅｌｆ＿ｃｏｎｔａｉｎｅｄ＿ｆｌａｇを他の残りのビットに示すパラメータ
−ＩＳＯ／ＩＥＣ２３００８−２で定義されているｆｒａｍｅ１＿ｓｅｌｆ＿ｃｏｎｔａｉｎｅｄ＿ｆｌａｇ、または、ＩＳＯ／ＩＥＣ１４４９６−１０で定義されているｒｉｇｈｔ＿ｖｉｅｗ＿ｓｅｌｆ＿ｃｏｎｔａｉｎｅｄ＿ｆｌａｇを他の残りのビットに示すパラメータ。

さらに、「ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ」が１つの単一トラックに左ビューフレームおよび右ビューフレームをパックするために使用されるいくつかのステレオフレームパッキングスキームおよびステレオフレームパッキング配置を記述することを可能にする場合、ＩＳＯ／ＩＥＣ２３０９０−２（ＭＰＥＧ ＯＭＡＦ）において、左ビューおよび右ビューが別々のトラックにパックされるときに、容易な記述を可能にしない。この問題は、メディアコンテンツが立体的であり左右両方のビューを埋め込む１つまたは複数のビデオトラックにカプセル化されるたびに、仮想現実または全方向性メディアコンテンツだけでなく、任意のアプリケーションに対して発生することに留意されたい。

例えば、ＭＰＥＧ ＯＭＡＦ仕様は、ステレオビューの並列及び上下フレームパッキングのそれぞれのための値３及び４のみを許容し、以下のようにＳｔｅｒｅｏＶｉｄｅｏＢｏｘを用いてステレオコンテンツを記述することを推奨する：

しかし、本仕様はステレオビューを別個のトラックに記述することを可能にしない。

立体コンテンツの記述を単純化し、異なるＯＭＡＦ記述子における立体情報の繰り返しを回避するために、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、単一のフレーム内にパックされるか、または別々のトラックにカプセル化されるビューが何であれ、任意のタイプのビューカプセル化またはパッキングをサポートするように拡張することができる。

第１に、カプセル化プロセスにいくつかの制約を課すことができる：ステレオビューが異なる特性を有する場合、例えば、領域ごとの品質ランキングでは各ビューがそれ自体のトラックにカプセル化されなければならず、各トラックに対するＳｔｅｒｅｏＶｉｄｅｏＢｏｘはｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４（すなわち、ＣＩＣＰ ＩＳＯ／ＩＥＣ ２３００１−８で定義されるフレームパッキングを使用しなければならない）と、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ＝｛６，０｝とを有しなければならず、これは復号されたフレームがフレームパッキングなしに完全な２Ｄフレームを構成することを意味する。

そうすることによって、ＳｐｈｅｒｅＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘまたは２ＤＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘなどのＯＭＡＦ記述子内の他のどこかのビュー識別子（ｖｉｅｗ＿ｉｄｃ）を繰り返す必要がなくなる。トラックを解析することで、プレイヤは以下のことを判定できる：
−トラックには、モノスコピックコンテンツ（ＳｔｅｒｅｏＶｉｄｅｏＢｏｘなし）が含まれている
−トラックには、立体コンテンツが含まれている（ＳｔｅｒｅｏＶｉｄｅｏＢｏｘの存在）
〇 ステレオの場合、１つのビュー（ｔｒｅｆ＝「ｓｖｄｐ」を参照するか、参照されるか）または両方のビューを含むかどうか
〇 ステレオで、単一のビューを含む場合、（以下に説明するような）ＳｔｅｒｅｏＶｉｄｅｏＢｏｘを介したビュー識別子

ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ＝{６，０｝のＳｔｅｒｅｏＶｉｄｅｏＢｏｘを、左ビューまたは右ビューのいずれかを含む各トラックに対して定義することによって、コンテンツが立体コンテンツの一部であるが、どのトラックが右ビューの左であるかを識別することはできないことをシグナリングすることができる。

その後、左右のビューは、タイプ「ｓｖｄｐ」のトラック参照を使用して識別される。参照トラック「ｓｖｄｐ」を含むトラックは参照トラックとして識別され、それは参照トラックに依存し、立体関連メタ情報も含む。

さらに、トラックがどのビューに対応しているかを示すために、いくつかのパラメータ（ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄ、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ）が使用される。

ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄのセマンティクスは、以下のように定義される：
ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４かつｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅが「ｎｏｐａｃｋｉｎｇ」を示している場合、すなわちｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅ＝｛6、0}の場合、ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄ ＆１が１に等しいことはトラックが右ビューを含むことを示し、ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄ ＆２が２に等しいことは、トラックが左ビューを含むことを示す。この場合、値０及び３は禁止される。

代替処理として、ｓｉｎｇｌｅ＿ｖｉｅｗ＿ａｌｌｏｗｅｄパラメータの既存のセマンティクスを修正することを回避するために、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘの新しいバージョンが定義され、トラックに左ビュー（ｉｓ＿ｌｅｆｔ＿ｖｉｅｗ＝１）または右ビュー（ｉｓ＿ｌｅｆｔ＿ｖｉｅｗ＝０）が含まれているかどうかをシグナリングするために追加の１ビットパラメータ「ｉｓ＿ｌｅｆｔ＿ｖｉｅｗ」が提供される。

あるいは、追加パラメータは以下のセマンティクスを有する２ビットパラメータ「ｖｉｅｗ＿ｉｄｃ」（以下に示す）であり、それが０に等しい場合、トラック内のメディアコンテンツがモノスコピックであることを示し、１はトラック内のメディアコンテンツが立体コンテンツの左ビューであることを示し、２はトラック内のメディアコンテンツが立体コンテンツの右ビューであることを示し、３はトラック内のメディアコンテンツが左ビューおよび右ビューの両方を含むことを示す。

別の代替処理として、新しいパラメータを追加してＳｔｅｒｅｏＶｉｄｅｏＢｏｘの新しいバージョンを作成するのではなく、新しいフレームパッキング配置がｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４(ＣＩＣＰ ＩＳＯ／ＩＥＣ ２３００１−８の拡張に対応する）について定義され、すなわち、ｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４のときのパラメータｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅについて、新しい値、たとえば７が定義される。この新しい値は、以下のように定義される：
ＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅ＝７は、復号されたフレームが２つの構成フレームの対応する面の１つの単一面（すなわち、立体シーケンスの左ビューまたは右ビューのどちらか）を含むことを示す。

この新しいＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅの値に加えて、およびフレームパックされたビデオ表現でＱｕｉｎｃｘ（五点形）サンプリング構造が使用されているかどうかを知らせる既存の関連フラグＱｕｉｎｃｘＳａｍｐｌｉｎｇＦｌａｇに加えて、例えば、ＶｉｅｗＩｄｃＦｌａｇと呼ばれる新しい関連フラグが定義されており、フレームパックされたビデオ表現に存在するビューのタイプを識別することを可能にする。存在しないか、または指定されない場合、またはＶｉｅｗＩｄｃＦｌａｇの値０の場合は、左ビューおよび右ビューの両方が存在することを示すと推論され、値１は立体コンテンツの左ビューのみが存在することを示し、値２は立体コンテンツの右ビューのみが存在することを示し、ＶｉｅｗＩｄｃＦｌａｇの他のすべての値は、ＩＳＯ／ＩＥＣによる将来の使用のために予約される。

その場合、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘ内のｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４の定義は、以下のように修正される：
「ｓｔｅｒｅｏ＿ｓｃｈｅｍｅが４に等しい：ｌｅｎｇｔｈの値は２で、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅはｕｎｓｉｇｎｅｄ ｉｎｔ（８）の２つのシンタックス要素を含む。第１のシンタックス要素は、ＩＳＯ／ＩＥＣ２３００１−８からのＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅを含む。値０から６までのＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅについて、第２のシンタックス要素の最下位ビットは、ＩＳＯ／ＩＥＣ２３００１−８で指定されたＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇの値を含み、一方、他のビットは予約され、０に設定される。値７のＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅについて、第２のシンタックス要素の最下位２ビットは、左ビュー及び右ビューを識別し、そして（上に定義されるような）ＶｉｅｗＩｄｃＦｌａｇの値を含み、他のビットは予約され、０に設定される。」

代替処理として、以下のようにＳｔｅｒｅｏＶｉｄｅｏＢｏｘでｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４を定義することで、ＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇおよびＶｉｅｗＩｄｃＦｌａｇの両方を同時にシグナリングすることができる：
「ｓｔｅｒｅｏ＿ｓｃｈｅｍｅが４に等しい：ｌｅｎｇｔｈの値は３で、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅはｕｎｓｉｇｎｅｄ ｉｎｔ（８）の３つのシンタックス要素を含む。第１のシンタックス要素は、ＩＳＯ／ＩＥＣ２３００１−８からのＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅを含む。第２のシンタックス要素の最下位ビットはＩＳＯ／ＩＥＣ２３００１−８で指定されたＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇの値を含み、他のビットは予約され、０に設定される。第３のシンタックス要素の最下位２ビットは、左ビューおよび右ビューを識別し、そして（上に定義されるような）ＶｉｅｗＩｄｃＦｌａｇの値を含み、他のビットは予約され、０に設定される。」

一例として、上記の代替処理によれば、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、以下のようにコメントに示される可能な値で変更されないままである：

代替処理として、ＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇおよびＶｉｅｗＩｄｃＦｌａｇの両方が、以下のようにＳｔｅｒｅｏＶｉｄｅｏＢｏｘでｓｔｅｒｅｏ＿ｓｃｈｅｍｅ＝４を定義することで、オプションでシグナリングすることができる：
「ｓｔｅｒｅｏ＿ｓｃｈｅｍｅが４に等しい：ｌｅｎｇｔｈの値は１、２または３のいずれかであり、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅは、ｕｎｓｉｇｎｅｄ ｉｎｔ（８）の１、２または３つのシンタックス要素をそれぞれ含む。第１のシンタックス要素は、ＩＳＯ／ＩＥＣ２３００１−８からのＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅを含む。第２のシンタックス要素の最下位ビットは、存在する場合にはＩＳＯ／ＩＥＣ２３００１−８で指定されたＱｕｉｎｃｕｎｘＳａｍｐｌｉｎｇＦｌａｇの値を含み、他のビットは予約され、「０」に設定される。第３のシンタックス要素の最下位２ビットは、存在する場合には、左ビューおよび右ビューを識別し、（上記で定義された）ＶｉｅｗＩｄｃＦｌａｇの値を含み、他のビットは予約され、０に設定される。」第３のシンタックス要素が存在する場合は、第２のシンタックス要素が存在する。

別の代替処理として、４（ＣＩＣＰ ＩＳＯ／ＩＥＣ２３００１−８に定義されているフレームパッキングを使用）ではなく３（（ＩＳＯ／ＩＥＣ２３０００ １１ 第１版（「Ｓｔｅｒｅｏｓｃｏｐｉｃ ｖｉｄｅｏ ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ」）に定義されているフレームパッキングを使用）に等しいｓｔｅｒｅｏ＿ｓｃｈｅｍｅを使用して別々のトラックに左右のビューを編成する立体全方向性メディアのためのフレームパッキング配置をシグナリングすることができる。ＩＳＯ／ＩＥＣ１４４９６−１２第４版のＳｔｅｒｅｏＶｉｄｅｏＢｏｘ定義によれば：ｓｔｅｒｅｏ＿ｓｃｈｅｍｅが３に等しいことは、ｌｅｎｇｔｈの値が２であり、ｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅがｕｎｓｉｇｎｅｄ ｉｎｔ（８）の２つのシンタックス要素を含むことを示す。第１のシンタックス要素は、ＩＳＯ／ＩＥＣ２３０００−１１：２００９の表４からの立体合成タイプを含む。第２のシンタックス要素の最下位ビットは、ＩＳＯ／ＩＥＣ ２３０００−１１：２００９の８．４．３で指定されているようなｉｓ＿ｌｅｆｔ＿ｆｉｒｓｔの値を含み、他のビットは予約され、「０」に設定される。

したがって、３に等しいｓｔｅｒｅｏ＿ｓｃｈｅｍｅを持つＳｔｅｒｅｏＶｉｄｅｏＢｏｘをこのトラック内に定義することによって、（トラックが左／右ビューシーケンスタイプを表す、すなわち左または右ビューのみを表すことを意味する）値０ｘ３を持つｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅの第１のシンタックス要素を定義することによって、第２のシンタックス要素を、左ビューがセカンダリビューであることをシグナリングするために０として定義し、または左ビューがプライマリビューであることをシグナリングするために１として定義することによって、トラックが立体コンテンツの左ビューまたは右ビューを含むことをシグナリングすることができる。プライマリビューおよびセカンダリビューは、左ビューおよび右ビュートラックをリンクするトラック参照「ｓｖｄｐ」により識別される。タイプ「ｓｖｄｐ」の「ｔｒｅｆ」ボックスを持つトラックは、セカンダリビューシーケンスであり、参照されるトラックはプライマリビューシーケンスである。

ＳｔｅｒｅｏＶｉｄｅｏＢｏｘの新しいバージョン（バージョン＝１）を作成する実施形態におけるＳｔｅｒｅｏＶｉｄｅｏＢｏｘのサイズは、ｓｔｅｒｅｏ＿ｓｃｈｅｍｅおよびｓｔｅｒｅｏ＿ｉｎｄｉｃａｔｉｏｎ＿ｔｙｐｅに認可された数個の値に割り当てるバイト数を少なくすることで、バージョン０に比べて低減できることに留意されたい。

代替処理として、新しいパラメータｖｉｅｗ＿ｉｄｃを導入する実施形態のためのＳｔｅｒｅｏＶｉｄｅｏＢｏｘのよりコンパクトなバージョン１は、以下のように記述することができる（６バイトを節約する）：

同様に、追加パラメータが「ｖｉｅｗ＿ｉｄｃ」ではなく「ｉｓ＿ｌｅｆｔ＿ｖｉｅｗ」である場合も、同じコンパクトバージョンを定義できる。

さらに、フレームパッキングにより、ビューごとに１つのパックされたフレームとなる場合、ＤＡＳＨ複数ビュースキームは、ステレオペアを記述するために適応設定レベルの役割要素において使用され得る。

上記のすべての実施形態によれば、ビューが以下のように異なるトラックに分割される場合には不要となるため、ＳｐｈｅｒｅＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘおよび２ＤＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘ内のｖｉｅｗ＿ｉｄｃおよびｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇパラメータは削除される：

代替処理として、ｖｉｅｗ＿ｉｄｃおよびｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇパラメータは、以下に示すように、ＳｐｈｅｒｅＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘまたは２ＤＲｅｇｉｏｎＱｕａｌｉｔｙＲａｎｋｉｎｇＢｏｘの特定のバージョンに条件付けされる：

実際、トラックが左ビュー全体または右ビュー全体のいずれかのみを含む場合、このトラック内に定義された各品質ランキング領域につい（立体ビューをシグナリングする）ｖｉｅｗ_ｉｄｃを含める必要はない。このような場合、これらのボックスのバージョン＝＝０が使用される。それ以外の場合、トラックがパックされたビューを含むなら、それらのボックスのバージョン＝＝１が使用される。

図３は、本発明の１つまたは複数の実施形態を実施するためのコンピューティングデバイス３００の概略ブロック図である。コンピューティングデバイス３００は、マイクロコンピュータ、ワークステーション、またはライトポータブル装置などの装置とすることができる。コンピュータデバイス３００は、以下と接続された通信バスを備える：
−マイクロプロセッサのような中央処理装置（ＣＰＵ）３０１；
−本発明の実施形態の方法の実行可能コードを記憶するためのランダムアクセスメモリ（ＲＡＭ）３０２、ならびに、マニフェストの読取りおよび書込み、および／またはビデオの符号化、および／または所与のファイルフォーマットの下でのデータの読取りまたは生成のための方法を実施するために必要な変数およびパラメータを記録するように構成されたレジスタ、たとえば、拡張ポートに接続された任意選択のＲＡＭによって、そのメモリ容量を拡張することができる；
−本発明の実施形態を実施するためのコンピュータプログラムを記憶するためのリードオンリーメモリ（ＲＯＭ）３０３；
−同様に、典型的には、処理されるべきデジタルデータが送受信される通信ネットワークに接続されるネットワークインタフェース３０４。ネットワークインタフェース３０４は単一のネットワークインタフェースであってもよく、あるいは異なるネットワークインタフェース（例えば、有線および無線インタフェース、あるいは異なる種類の有線または無線インタフェース）のセットから構成されてもよい。データは、送信のためにネットワークインタフェースに書き込まれるか、またはＣＰＵ３０１内で動作するソフトウェアアプリケーションの制御下で受信のためのネットワークインタフェースから読み込まれる；
−ユーザからの入力を受信するため、またはユーザに情報を表示するためのユーザインターフェース（ＵＩ）３０５；
−ハードディスク（ＨＤ）３０６；
−ビデオソースまたはディスプレイなどの外部装置との間でデータを送受信するＩ／Ｏモジュール３０７。

実行可能コードは、リードオンリーメモリ３０３、ハードディスク３０６、または例えばディスクのようなリムーバブルデジタル媒体のいずれかに格納することができる。変形例によれば、プログラムの実行可能コードは、通信ネットワークによって、ネットワークインタフェース３０４を介して、実行される前に、ハードディスク３０６のような通信装置３００の記憶手段の１つに記憶されるように受信することができる。

中央演算処理装置３０１は、本発明の実施形態による１つ又は複数のプログラムの命令またはソフトウェアコードの一部の実行を制御し、指示するように構成され、その命令は、前述の記憶手段のうちの１つに記憶される。電源投入後、ＣＰＵ３０１は、例えばプログラムＲＯＭ３０３またはハードディスク３０６からこれらの命令がロードされた後、ソフトウェアアプリケーションに関連するメインＲＡＭメモリ３０２からの命令を実行することができる。このようなソフトウェアアプリケーションは、ＣＰＵ３０１によって実行されると、前の図に示されたフローチャートのステップを実行する。

この実施形態では、装置は、本発明を実施するためにソフトウェアを使用するプログラマブル装置である。しかしながら、代替的に、本発明はハードウェア（例えば、特定用途向け集積回路（ＡＳＩＣ）の形態）で実施されてもよい。

以上、本発明を特定の実施形態を参照して説明したが、本発明は特定の実施形態に限定されるものではなく、本発明の範囲内にある修正が当業者には明らかであろう。

例えば、本発明は、例えば特定の関心領域にズームインするためのＴＶまたはマルチメディアディスプレイのためのリモートコントローラとして動作する、カメラ、スマートフォン、ヘッドマウントディスプレイ、またはタブレットなどの装置に組み込まれてもよい。また、同じ装置から、特定の関心領域を選択することにより、マルチメディアプレゼンテーションのパーソナライズされたブラウジング体験を得るために使用することもできる。ユーザによるこれらの装置および方法からの別の使用は、ユーザの好ましいビデオのいくつかの選択されたサブパートを他の接続された装置と共有することである。監視カメラが本発明によるデータを提供するための方法をサポートするのであれば、監視下に置かれた建物の特定の領域で何が起こるかを監視するためにスマートフォンまたはタブレットと共に使用することができる。

前述の例示的な実施形態を参照すると、多くのさらなる修正および変形が当業者に示唆され、例としてのみ与えられ、本発明の範囲を限定することを意図されず、その範囲は添付の特許請求の範囲によってのみ決定される。特に、異なる実施形態からの異なる特徴は、適宜、交換されてもよい。

Claims (16)

1. １つまたは複数のメディアファイルを生成するための方法であって、
   第１のビューフレームおよび該第１のビューフレームが関連づけられた第２のビューフレームを含む符号化された立体メディアデータを取得することと、
   前記符号化された立体メディアデータを含むトラックを生成することと、
   左のビューに対応するビューフレームが識別されることに基づいて記述メタデータを生成することと、
   前記生成されたトラックおよび前記生成された記述メタデータに基づいて前記１つまたは複数のメディアファイルを生成することと、
   を含み、
   前記生成された記述メタデータは、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６−１２）で定義されるＳｔｅｒｅｏＶｉｄｅｏＢｏｘを含み、
   前記ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、どのビューフレームが左のビューに対応するかをシグナリングするためのＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅを含む方法。
2. 少なくとも１つの第１のビューフレームおよび関連する第２のビューフレームについて、前記第１のビューフレームをその関連する第２のビューフレームと組み立てて単一のフレームを形成することをさらに含み、前記符号化された立体メディアデータは、前記組み立てられた単一のフレームのうちの少なくとも１つを符号化することによって得られる、請求項１に記載の方法。
3. 前記方法は、表示されるべき表面に関する第１のビューまたは第２のビューのうちの少なくとも１つのためのカバレッジ情報を提供することと、前記カバレッジ情報が前記第１のビューおよび前記第２のビューの両方のために１回だけ提供される必要がある場合または前記第１のビューおよび前記第２のビューのそれぞれのために２回だけ提供される必要がある場合に、シグナリングのための情報を提供することと、をさらに含む、請求項２に記載の方法。
4. 前記第１のビューフレームおよび前記関連する第２のビューフレームが同じ符号化されたメディアデータに対応する場合、前記情報は、前記カバレッジ情報が前記第１のビューまたは前記第２のビューのうちの１つのみに提供されることをシグナリングするための所定の値をとるパラメータであり、
   そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューのそれぞれに提供される、請求項３に記載の方法。
5. 前記第１のビューフレームおよび前記関連する第２のビューフレームが異なる符号化されたメディアデータに対応する場合、前記方法は、表示されるべき表面に関する第１のビューまたは第２のビューのうちの少なくとも１つに対するカバレッジ情報を提供することをさらに含み、前記カバレッジ情報は前記第１のビューまたは前記第２のビューのそれぞれに対して提供され、
   そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューの両方に対して１回だけ提供される、請求項２に記載の方法。
6. 前記第１のビューフレームが左のビューフレームであり、前記第２のビューフレームが右のビューフレームである、請求項２に記載の方法。
7. １つまたは複数の以上のメディアファイルを処理する方法であって、
   前記１つまたは複数のメディアファイルを取得することと、
   第１のビューフレームおよび該第１のビューフレームが関連づけられた第２のビューフレームを含む符号化された立体メディアデータを含むトラックを取得するために、前記取得された１つまたは複数のメディアファイルを処理することと、
   左のビューに対応するビューフレームが識別されることに基づいて記述メタデータを取得するために、前記取得された１つまたは複数のメディアファイルを処理することと、
   を含み、
   前記記述メタデータは、ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ１４４９６−１２）で定義されるＳｔｅｒｅｏＶｉｄｅｏＢｏｘを含み、
   前記ＳｔｅｒｅｏＶｉｄｅｏＢｏｘは、どのビューフレームが左のビューに対応するかをシグナリングするためのＰａｃｋｅｄＣｏｎｔｅｎｔＩｎｔｅｒｐｒｅｔａｔｉｏｎＴｙｐｅを含む方法。
8. 少なくとも１つの第１のビューフレームおよび前記関連する第２のビューフレームについて、前記第１のビューフレームはその関連する第２のビューフレームと組み立てられて１つの単一のフレームを形成し、前記立体メディアデータは、前記組み立てられた単一のフレームのうちの少なくとも１つを復号することによって得られる、請求項７に記載の方法。
9. 前記方法は、表示されるべき表面に関する第１のビューまたは第２のビューのうちの少なくとも１つについてのカバレッジ情報を取得することと、前記カバレッジ情報が前記第１のビューおよび前記第２のビューの両方のために１回だけ取得される必要がある場合、または前記第１のビューおよび前記第２のビューのそれぞれのために２回だけ取得される必要がある場合に、シグナリングするための情報を取得することと、をさらに含む、請求項７に記載の方法。
10. 前記第１のビューフレームおよび前記関連する第２のビューフレームが同じ符号化されたメディアデータに対応する場合、前記情報は、前記カバレッジ情報が前記第１のビューまたは前記第２のビューのうちの１つのみについて取得されることをシグナリングするための所定の値をとるパラメータであり、
    そうではない場合、前記カバレッジ情報は、前記第１のビューおよび前記第２のビューのうちのそれぞれについて得られる、請求項９に記載の方法。
11. 前記第１のビューフレームおよび前記関連する第２のビューフレームが異なる符号化されたメディアデータに対応する場合、前記方法は、表示されるべき表面に関する第１のビューまたは第２のビューのうちの少なくとも１つについてのカバレッジ情報を取得することをさらに含み、前記カバレッジ情報は前記第１のビューまたは第２のビューのそれぞれについて取得され、
    そうではない場合、前記カバレッジ情報は、前記第１のビューおよび第２のビューの両方について１回だけ取得される、請求項８に記載の方法。
12. 前記第１のビューフレームは左のビューフレームであり、前記第２のビューフレームは右のビューフレームである、請求項８に記載の方法。
13. コンピュータまたはプロセッサによって実行される場合に、前記コンピュータまたはプロセッサに、請求項１乃至１２の何れか１項に記載の方法を実行させるプログラム。
14. 請求項１３に記載のプログラムを記憶するコンピュータ可読記憶媒体。
15. １つまたは複数のメディアファイルを生成するための装置であって、前記装置は、請求項１乃至６の何れか１項に記載の方法を実施するように構成されている装置。
16. １つまたは複数のメディアファイルを処理するための装置であって、請求項７乃至１２の何れか１項に記載の方法を実施するように構成されている装置。

Images