JP7133038B2 - メディアコンテンツを送信する方法、装置及びコンピュータプログラム - Google Patents

Description

本発明はメディアデータをカプセル化し、送信するための方法及び装置に関する。

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

国際標準化機構ベース・メディアファイル・フォーマット（ＩＳＯ ＢＭＦＦ、ＩＳＯ／ＩＥＣ １４４９６－１２）は、ローカル記憶又は、ネットワークを介するか別のビットストリーム送信メカニズムを介する送信のいずれかのための符号化された時限メディアデータ・ビットストリームを記述する周知の柔軟で、かつ、拡張可能なフォーマットである。そのような符号化フォーマットの例は、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、及びＬ－ＨＥＶＣ（Ｌａｙｅｒｅｄ ＨＥＶＣ）である。ファイル・フォーマット拡張の別の例は、ＨＥＶＣ静止画のような静止画像又は静止画像のシーケンスのためのカプセル化ツールを記述するＩＳＯ／ＩＥＣ ２３００８－１２である。このファイル・フォーマットはオブジェクト指向である。それは、逐次的又は階層的に編成され、タイミング及び構造パラメータのような符号化された時限メディアデータ・ビットストリームのパラメータを定義するボックスと呼ばれる構築ブロック（又は４文字コードによって特徴づけられるデータ構造）から構成される。

ファイル・フォーマットでは、全体的なプレゼンテーションは動画と呼ばれる。動画は、メディア又はプレゼンテーションファイルの最上位階層に動画ボックス（４文字コード‘ｍｏｏｖ’）により記述される。この動画ボックスは、プレゼンテーションを記述する様々なボックスの設定を含む初期化情報コンテナを表す。それは論理的にトラックボックス（４文字コード‘ｔｒａｋ’と共に）により表されるトラックに分割される。各トラックは（トラック識別子（ｔｒａｃｋ＿ＩＤ）によって一意に識別される）、プレゼンテーション（例えば、ビデオのフレーム）に属するメディアデータの時限シーケンスを表す。各トラックは（トラック識別子（ｔｒａｃｋ＿ＩＤ）によって一意に識別される）、プレゼンテーション（例えば、ビデオのフレーム）に属するメディアデータの時限シーケンスを表す。各トラック内で、データの各時限単位はサンプルと呼ばれ、これは、ビデオ、オーディオ、又は時限メタデータのフレームであってよい。サンプルは、黙示的に順次番号付けられる。実際のサンプルデータは、動画ボックスと同じ階層でメディアデータボックス（４文字コード‘ｍｄａｔ’と共に）と呼ばれるボックスに保存される。

動画は、全体プレゼンテーションのための情報に続く、結合動画フラグメント及びメディアデータボックスのリストを含む動画ボックスとして、一時的に編成されてよい。動画フラグメント（４文字コード‘ｍｏｏｆ’のボックス）内には、動画フラグメントごとに０個以上のトラックフラグメントのセット（４文字コード‘ｔｒａｆ’のボックス）がある。トラックフラグメントは順次、０個以上のトラック・ラン・ボックス（‘ｔｒｕｎ’）を含み、各トラック・ラン・ボックスは、そのトラックフラグメントに対するサンプルの連続したランを文書化する。

ファイル・フォーマットでは、メディア又はプレゼンテーションファイルが動画ボックスと同じ階層のメタボックス（‘ｍｅｔａ’）内に記述された１つ以上の静的な項目（例えば、１つ以上の静止画像）を含むこともできる。このメタボックスは、静的な項目を記述する記述的情報を含んでよく、この記述的情報は複数のボックスに編成されており（例えば、項目情報ボックス（‘ｉｉｎｆ’）内の項目のリストや、項目の場所ボックス（‘ｉｌｏｃ’）内のデータ項目の場所（データボックス内）など）、各項目は項目識別子（ｉｔｅｍ＿ＩＤ）によって一意に識別される。実際の項目データは、メタボックスの項目データボックス（‘ｉｄａｔ’）又はファイル最上位階層のメディアデータボックス（‘ｍｄａｔ’）のいずれかに保存される。

ＩＳＯＢＭＦＦファイルは、複数のトラック（映像コンテンツのためのサブピクチャトラックも注記される）及び／又は複数の静的な項目を形成する、複数の符号化された時限メディアデータ・ビットストリーム又は符号化された時限メディアデータ・ビットストリームのサブ部を含んでよい。ＩＳＯＢＭＦＦ及びその拡張は、トラック、静的な項目、又はサンプルを一緒にグループ化するためのいくつかのグループ化機構を含む。グループは一般的に、共通のセマンティック及び／又は特徴を共有する。

例えば、ＩＳＯＢＭＦＦは、エンティティグループ機構、トラックグループ機構、及びサンプルグループ機構を備える。エンティティグループ機構は、トラック及び／又は静的な項目が示されたグループ化タイプ又はセマンティックに従ってグループ化されることを示すために使用され得る。トラックグループ機構は、示されたグループタイプ又はセマンティックに従ってトラックがグループ化されていることを示すために使用され得る。サンプルグループ機構は、示されたグループタイプ又はセマンティックに関連付けられた特定のプロパティが、トラック内のサンプルの示されたグループに適用することを示すために使用され得る。

ユーザ体験を改善し、特に没入型体験を提供するために、時限メディアデータ・ビットストリーム（ビデオ及びオーディオ）は、全方向（又は多方向性又は多数方向性）であってよい。３６０°パノラマビデオとしても知られるビデオに適用されると、ユーザは、表示されるシーン内に位置するように感じる。全方向ビデオは、３６０°カメラから及び／又は、例えば、全てのカメラが共通の節点を有するように特別なリグに搭載されたいくつかのカメラから得られたビデオストリームの画像を組み合わせることによって、得られてよい。このような画像の組合せは、画像スティッチング又はカメラスティッチングとして知られている。

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

発明者は特に、全方向メディアコンテンツが複数のトラックによって搬送されるいくつかのサブ部に分割される場合に、送信するためのメディアデータに関する情報を記述し、及び信号伝達するときに、いくつかの問題に気付いた。例は、クライアントから特定の解析プロセスを要求するトラックの信号を含み、これはオーバーヘッドを生成し、複雑である。別の例は、トラックのグループの信号と、特にオリジナルの全方向メディアコンテンツと、複数のサブピクチャトラックに埋め込まれた２次元（２Ｄ）メディアコンテンツ（投影された、パックされた、又は魚眼コード化されたかのいずれか）との間のマッピングに関連する。

別の例は、表示の準備ができた全方向メディアコンテンツを再構築するために、組み合わされることが許可されるか、又は許可されないサブピクチャトラックの信号を含む。既存ソリューションは、複雑であるか、又は十分に定義されておらず、２次元マルチトラックカプセル化プロセスのための既存の機構に完全に準拠していないかのいずれかである。

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

本発明の第１の態様によれば、シーンのワイドビューに対応する符号化メディアデータをカプセル化する方法が提供される。前記シーンの前記ワイドビューから投影ピクチャを得ることと、得られた前記投影ピクチャを少なくとも１つのパック化ピクチャにパッキングすることと、前記少なくとも１つのパック化ピクチャを少なくとも１つのサブピクチャに分割することと、前記少なくとも１つのサブピクチャを複数のトラックに符号化することと、前記符号化トラックに関連付けられた記述メタデータを生成することを有し、前記記述メタデータは、前記トラックにおいて符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間関係を示す、各トラックに関連付けられた情報の項目を含む、ことを特徴とする方法。

本発明の別の態様によれば、シーンのワイドビューに対応する符号化メディアデータをカプセル化する方法が提供される。前記シーンの前記ワイドビューから投影ピクチャを得ることと、投影ピクチャを少なくとも１つのサブピクチャに分割することと、前記少なくとも１つのサブピクチャを複数のトラックに符号化することと、前記符号化トラックに関連付けられた記述メタデータを生成することを有し、前記記述メタデータは、前記少なくとも１つの前記トラックにおいて符号化された前記少なくとも１つのサブピクチャと参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を含む、前記記述メタデータは、更に、前記参照ピクチャを示す第２の情報項目を含む、ことを特徴とする方法。

実施形態によれば、前記投影ピクチャを複数のサブピクチャに分割することは、前記投影ピクチャをパック化ピクチャにパッキングすることと、前記パック化ピクチャを複数のサブピクチャに分割することを含む。

実施形態によれば、前記第２の情報項目は、前記参照ピクチャが前記投影ピクチャであることを示すブランド値である。

実施形態によれば、前記第２の情報項目は、前記参照ピクチャが前記パック化ピクチャであることを示すブランド値である。

前記第２の情報項目は、各トラックに関連付けられた前記第１の情報項目に含まれる。

実施形態によれば、前記第２の情報項目は、前記第１の情報項目のパラメータとして定義される。

実施形態によれば、前記パラメータの存在は、前記第１の情報項目に提供されるフラグによって示される。

実施形態によれば、前記第２の情報項目は、前記第１の情報項目に提供されるフラグとして定義される。

実施形態によれば、前記第２の情報項目は、サブピクチャに対応するトラックのグループのプロパティを記述するために使用される特定のタイプのグループ情報として定義される。

本発明の別の態様によれば、複数の符号化トラック及び関連する記述メタデータを含むメディアファイルから少なくとも１つの画像を生成する方法が提供される。前記複数の符号化トラックが、シーンのワイドビューの投影ピクチャをパッキングすることによって得られるパック化ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを有することを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析することを有し、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラックに符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間関係を示す各トラックに関連付けられた情報項目を解釈することを含む、ことを特徴とする方法。

本発明の別の態様によれば、複数の符号化トラック及び関連する記述メタデータを含むメディアファイルから少なくとも１つの画像を生成するための方法が提供される。前記複数の符号化トラックが、シーンのワイドビューの投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを含むことを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析することを有し、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラックにおいて符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を解釈することと、参照ピクチャを示す第２の情報項目を解釈することを含む、ことを特徴とする方法。

実施形態によれば、前記シーンのワイドビューの投影ピクチャの分割は、前記投影画像をパッキングすることによって得られるパック化ピクチャを分割することによって得られる。

実施形態によれば、前記第２の情報項目は、前記参照ピクチャが前記投影ピクチャであることを示すブランド値である。

実施形態によれば、前記第２の情報項目は、前記参照ピクチャが前記パック化ピクチャであることを示すブランド値である。

実施形態によれば、前記第２の情報項目は、各トラックに関連付けられた前記第１の情報項目に含まれる。

実施形態によれば、前記第２の情報項目は、前記第１の情報項目のパラメータとして定義される。

実施形態によれば、前記パラメータの存在は、前記第１の情報項目に提供されるフラグによって示される。

実施形態によれば、前記第２の情報項目は、前記第１の情報項目に提供されるフラグとして定義される。

実施形態によれば、前記第２の情報項目は、サブピクチャに対応するトラックのグループのプロパティを記述するために使用される特定のタイプのグループ情報として定義される。

本発明の別の態様によれば、シーンのワイドビューに対応する符号化されたメディアデータをカプセル化するコンピューティングデバイスが提供される。前記シーンの前記ワイドビューから投影ピクチャを得ることと、得られた投影ピクチャを少なくとも１つのパック化ピクチャにパッキングすることと、前記少なくとも１つのパック化ピクチャを少なくとも１つのサブピクチャに分割することと、前記少なくとも１つのサブピクチャを複数のトラックに符号化することと、前記符号化トラックに関連付けられた記述メタデータを生成するように構成され、前記記述メタデータは、前記トラックにおいて符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間関係を示す、各トラックに関連付けられた情報項目を含む、ことを特徴とするコンピューティングデバイス。

本発明の別の態様によれば、シーンのワイドビューに対応する符号化されたメディアデータをカプセル化するためのコンピューティングデバイスが提供される。前記シーンの前記ワイドビューから投影ピクチャを得ることと、前記投影ピクチャを少なくとも１つのサブピクチャに分割することと、前記少なくとも１つのサブピクチャを複数のトラックに符号化することと、前記符号化トラックに関連付けられた記述メタデータを生成するように構成され、前記記述メタデータは前記トラック内で符号化された少なくとも１つのサブピクチャと参照ピクチャとの間の空間関係を示す、各トラックに関連する第１の情報項目を含み、前記記述メタデータは前記参照ピクチャを示す第２の情報項目をさらに含む、ことを特徴とするコンピューティングデバイス。

本発明の別の態様によれば、複数の符号化トラック及び関連する記述メタデータを含むメディアファイルから少なくとも１つの画像を生成するためのコンピューティングデバイスが提供される。複数の符号化トラックがシーンのワイドビューの投影ピクチャをパッキングすることによって得られるパック化ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを含むことを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析するように構成され、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラックに符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間関係を示す各トラックに関連付けられた情報項目を解釈することを含む、ことを特徴とするコンピューティングデバイス。

本発明の別の態様によれば、複数の符号化トラック及び関連する記述メタデータを含むメディアファイルから少なくとも１つの画像を生成するためのコンピューティングデバイスが提供される。複数の符号化トラックがシーンのワイドビューの投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを含むことを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析するように構成され、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラック内に符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を解釈することと、前記参照画像を示す第２の情報項目を解釈することを含む、ことを特徴とするコンピューティングデバイス。

本発明の別の態様によれば、プログラム可能な装置のためのコンピュータプログラム製品が提供される。プログラマブル装置のコンピュータプログラム製品であって、前記プログラマブル装置にロードされ、実行されるときに、請求項１から２０のいずれか１項に記載の方法を実施するための一連の命令を含む、ことを特徴とするコンピュータプログラム製品。

本発明の別の態様によれば、請求項１から２０のいずれか１項に記載の方法を実施するためのコンピュータプログラムの命令を記憶するコンピュータ可読記憶媒体が提供される。

本発明の別の態様によれば、実行時に、請求項１から２０のいずれか１項に記載の方法を実行させるコンピュータプログラムが提供される。

本発明のさらなる利点は図面及び詳細な説明を考察することにより、当業者に明らかになるであろう。任意の追加の利点は、本明細書に組み込まれることが意図される。本発明の実施形態は、単なる例として、以下の図面を参照して以下に記載される。

図１は、サーバからクライアントへの全方向ビデオをキャプチャ、処理、カプセル化、送信、及びレンダリングするためのデータフローの例を示している。 図２は、本発明の実施形態によるカプセル化の一例を示すブロック図を示している。 図３は、本発明の１つ以上の実施形態の実施のためのコンピューティングデバイスの概略ブロック図である。 図４は、いくつかのトラック及びグループ内の異なるメディアソースからのメディアデータを含むサブピクチャを符号化する例を示す。 図５は、本発明の実施形態によるＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びｓｏｕｒｃｅ＿ｉｄの使用例を示す。 図６は、本発明の実施形態によるＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びｓｏｕｒｃｅ＿ｉｄの第２の使用例を示す。 図７は、本発明の実施形態によるサブピクチャカプセル化を示す。 図８は、本発明の実施形態による解析プロセスを示す。 図９は、本発明の実施形態によるシステムを示す。 図１０ａは、本発明の実施形態による投影、オプションのパック及びサブピクチャトラックへの分割の全体プロセスのいくつかの例を示す。 図１０ｂは、本発明の実施形態による投影、オプションのパック及びサブピクチャトラックへの分割の全体プロセスのいくつかの例を示す。 図１０ｃは、本発明の実施形態による投影、オプションのパック及びサブピクチャトラックへの分割の全体プロセスのいくつかの例を示す 図１０ｄは、本発明の実施形態による投影、オプションのパック及びサブピクチャトラックへの分割の全体プロセスのいくつかの例を示す

図１は、サーバ装置１０１からクライアント装置１７０（１７０’としても示される）への全方向メディアをキャプチャ、送信、及びレンダリングするためのデータフローの例を示す。示される通り、このメディアは、カメラシステム１００から取得され、ヘッドマウントディスプレイ（ＨＭＤ）１７０及び１７０’に配信されるビデオコンテンツを有する。カメラシステム１００は、広角レンズ又は一緒に組み立てられた複数のカメラのセット（例えば、仮想現実用のカメラリグ）を備えた１つのカメラを含むことができる。配信１６０は例えば、ストリーミングサーバ１６１及びストリーミングクライアント１６２を介して、適応ｈｔｔｐストリーミング・プロトコルを使用して、インターネットのようなＩＰネットワーク１６３を介して実行されてよい。

図示のために、使用されるカメラシステム１００は、立方体の各面に関連付けられた６つの標準カメラのセットに基づいている。それは、カメラシステムを取り囲むリアルシーンを表す画像をキャプチャするために使用される（ステップ１１０）。この構成によれば、１つのカメラは前方の画像を提供し、１つのカメラは後方の画像を提供し、１つのカメラは左側の画像を提供し、１つのカメラは右側の画像を提供し、１つのカメラは下方の画像を提供し、１つのカメラは上方の画像を提供する。カメラシステム１００から得られた画像は、３６０ビデオストリーム又は仮想現実メディアデータストリームとも呼ばれる全方向ビデオストリームを形成する３６０画像を生成するために、サーバ１０１において処理される（ステップ１２０）。

処理ステップ１２０は、同時インスタンスのキャプチャされた画像をスティッチングすること及び投影することからなる。画像は、最初に水平及び垂直の寸法の両方で３６０°ビューを形成する球体１２１を表す三次元投影構造上にスティッチングされ、投影される。投影構造上の３６０画像データは、例えば正距円筒図法（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ｅｑｕｉｒｅｃｔａｎｇｕｌａｒ＿ｐｒｏｊｅｃｔｉｏｎ））を使用して、２次元投影画像１２２（キャプチャ投影とも示される）にさらに変換される。投影画像は球全体をカバーする。あるいは、全方向メディアが立体視３６０度ビデオである場合、カメラシステム１００は、三次元３６０度のシーンをレンダリングするために、クライアントにより後で使用され得る左ビュー及び右ビューを表す画像シーケンスをステップ１１０でキャプチャする複数のカメラで構成されてよい。このような場合、上述の処理ステップ１２０は、左ビューと右ビュー画像シーケンスの両方に別々に適用される。

オプションとして、ステップ１２５で、フレームパックは、同時インスタンスの左側のビュー画像及び右ビューの画像のそれぞれを、１つの単一の左＋右投影画像シーケンスに生じる同じ投影画像上にパックするように、適用されてよい。いくつかの立体視フレームパック構成は、例えば、並行、上下、列ベースのインターリービング、行ベースのインターリービング、左右のビューを交互にする時間的インターリービングが可能である。あるいは、立体視フレームパック構成は、符号化ステップ１４０の後に独立したビデオビットストリームを生じる、別々で独立した投影画像シーケンスに左及び右ビューを保持することからなってもよい。たとえば、１つのビデオビットストリームは左側のビューイメージを表し、別の１つは右側のビューイメージを表す。

オプションとして、領域的パック１３０は次に、パックされた画像１３１上に投影画像１２２をマッピングするために適用される。領域的パックは、例えば、ユーザに対して最も有用な球の部分上に信号情報を最大化するために、順番に変換（例えば、画素ブロックの回転、ミラーリング、コピー又は移動等）、投影画像の領域のサイズ変更及び再配置を適用することからなる。パックされた画像は、球全体の一部のみをカバーすることができることに留意されたい。領域的パックが適用されない場合、パックされた画像１３１は、投影画像１２２と同一である。立体視全方向メディアの場合、領域的パックは、ステップ１２５で選択されたフレームパック配置に依存する、左＋右投影画像シーケンス上、又は左ビュー及び右ビュー投影画像シーケンスの別々、のいずれかに適用する。

投影画像１２２又はパックされた画像１３１は、ステップ１４０において、１つ又は複数のビデオビットストリームに符号化される。立体視全方向メディアの場合、符号化ステップは、ステップ１２５で選択されたフレームパック配置に依存する、左＋右パック画像シーケンス、又は左ビュー及び右ビュー投影画像シーケンスの別々、のいずれかに適用する。あるいは、マルチビュー符号化は、左ビュー及び右ビューのパックされた画像シーケンス上で使用され得る。符号化フォーマットの例は、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、又はＬ－ＨＥＶＣ（Ｌａｙｅｒｅｄ ＨＥＶＣ）がある。

以下では、ＨＥＶＣはＨＥＶＣ及びそれの拡張階層化（Ｌ－ＨＥＶＣ）の両方を参照するために使用される。ＨＥＶＣ及び同様のビデオ符号化フォーマットは、サンプルの異なる空間的細分化、例えば、ピクチャ、タイル、スライス、及びスライスセグメントを定義する。タイルは、水平及び垂直の境界（すなわち、行及び列）によって定義され、符号化ツリーユニット（ＣＴＵ）又は符号化ブロックの整数を含むピクチャの矩形領域を定義し、以降全ては符号化ユニットと呼ばれる。そのように、タイルはピクチャの空間的サブ部を表すための良い候補である。しかしながら、シンタックス及びＮＡＬユニット（又はＮＡＬＵs）へのそれのカプセル化に関して、符号化ビデオデータ（ビットストリーム）編成は、（ＡＶＣのように）むしろスライス及びスライスセグメントに基づいている。

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

ビデオビットストリームがタイルで符号化されるとき、タイルは、同じピクチャ内の近傍タイル（空間依存性）及び先行参照ピクチャ内の近傍タイル（時間依存性）からタイルが依存しないことを保証するために、動き制限され得る。このように、動き制限されたタイルは、独立して復号可能である。あるいは、投影画像１２２又はパック画像１３１は、符号化前にいくつかの空間サブピクチャに分割されてよく、各サブピクチャは独立して、例えば、独立した符号化ＨＥＶＣビットストリームを形成しながら符号化される。あるいは、領域的パックステップ１３０及びいくつかの空間サブピクチャへの分割ステップは、メモリ内に完全な中間パック画像１３１を生成することなく、同時に実行されてよい。投影画像１２２は（又はオプションステップ１２５の後に生じる立体投影画像）、サブ部に分割されてよく、各サブ部は、ステップ１４０で符号化されるよう空間的サブピクチャに直接パックされてよい。

図１０ａ、１０ｂ、１０ｃ及び１０ｄは、本発明の実施形態によれば、投影、オプションのパック及びサブピクチャトラックへの分割の全体プロセスの幾つかの例を示している。投影ピクチャ１００１からの１つ以上の領域（１、２、３及び４と記す）は、いくつかの変換演算（アイデンティティ、上又は下のスケーリング、回転、ミラーリング、再配置等）を適用することによって、パック領域１００２（１’、２’、３’及び４’と記す）に再配置され、次に、１つ以上のサブピクチャトラック１００３に分割及び再編成される。分割はまた、パック領域（１’、２’、３’又は４’）当たり１つのサブピクチャトラックをもたらすことができる。また、パック及び分割操作は、投影ピクチャ１０１１から１つ以上のサブピクチャトラック１０１２へ直接的に、一度に実行されてよい。図１０ｃ及び１０ｄは、全方向コンテンツがステレオコンテンツである場合の異なる可能なカプセル化の例を提供する。このような場合、キャプチャステップ１１０は、立体視記録、通常、目ごとに１つのビデオを可能にするカメラリグを使用する。

図１０ｃは、フレームパックがない立体全方位性コンテンツの例を示している（図１のオプションステップ１２５）。次に、各投影ビュー１０２１は、領域的パックが各ビューに適用されるとき（１０２２において）、できる限り１０２３のような複数のサブピクチャトラックに独立してカプセル化される。この例では、各ビューの領域毎に１つのサブピクチャトラックがある。一つは、同じサブピクチャトラック内の同じ領域の両方のビューをカプセル化することであっても判定できる。次に、サブピクチャトラックは、使用されるフレームパックを示すサンプル記述的階層のステレオビデオボックスを含むであろう。

図１０ｄは、２つの投影ビュー１０３１を単一のフレームパック画像１０３２にパックするために適用されるフレームパック（図１のステップ１２５）がある、立体全方位性コンテンツの例を示す。次に、生じるフレームパック画像１０３２は、１０３３内のように、おそらく複数のサブピクチャトラックにカプセル化される。この例では、各サブピクチャトラックが所定の空間領域に対する両方のビューを記述する。パックが続く投影に関しては、１つのサブピクチャトラックが（図１０に示される通り）１つの領域又は多くの領域をカプセル化することができる。カプセル化モジュールは例えば、コンテンツを複数のパックされた領域を含むサブピクチャトラックにカプセル化するために、記述コスト対アクセス粒度のトレードオフを判定することができる。これは、パックされた領域の逆投影を計算することによるカプセル化が、パックされたフレーム内の連続する領域の逆投影にギャップがないことを見出す時の場合であってよい。

これは、パック化ピクチャからのこれらの領域を単一のサブピクチャトラックにグループ化するための判定基準になり得る。図１０ａ、１０ｂ、１０ｃ及び１０ｄは、同じサブピクチャトラックにおけるいくつかの領域のそのような集合を示す。カプセル化モジュールが投影ピクチャ内にギャップ、ホール又はカバーされていない画素を生成するサブピクチャトラック内の複数の領域を集める場合には、それは、サブピクチャトラックの位置及びサイズを、これらの複数の領域のバウンディングボックスの位置及びサイズと等しく設定することができる。したがって、符号化ステップ１４０の結果として、投影画像１２２又はパック画像１３１は、１つ以上が独立して符号化されたビットストリームによって、又は１つ以上が独立して符号化されたサブビットストリームで構成される少なくとも１つの符号化されたビットストリームによって表され得る。

それらの符号化されたビットストリーム及びサブビットストリームは、次に、ステップ１５０において、例えばＭＰＥＧ標準化機構によって定義されたＩＳＯベース・メディアファイル・フォーマット及び全方向メディアフォーマット（ＯＭＡＦ－ＩＳＯ／ＩＥＣ ２３０９０－２）によれば、カプセル化ファイル・フォーマットに従って、ファイル又は小さい時間セグメントファイル１６５にカプセル化される。生じるファイル又はセグメントファイルは、ｍｐ４ファイル又はｍｐ４セグメントであってよい。カプセル化の間、オーディオストリームはビデオ上又はオーディオストリーム上の情報を提供するメタデータトラックと共に、ビデオビットストリームに追加されてよい。

次に、カプセル化されたファイル又はセグメントファイルは例えば、ｈｔｔｐ（ハイパーテキスト・トランスファー・プロトコル）プロトコルを使用してインターネット上で、又は例えばディスクのような取り外し可能なデジタルメディア上で、配信メカニズム１６０を介してクライアント１７０に配信される。説明のために、配信１６０は、ＭＰＥＧ標準化委員会（「ＩＳＯ／ＩＥＣ ２３００９－１、ＨＴＴＰを介したダイナミックアダプティブストリーミング（ＤＡＳＨ）、第１部、メディアプレゼンテーション記述及びセグメントフォーマット」）からのＤＡＳＨ（ＨＴＴＰを介したダイナミックアダプティブストリーミング）のようなＨＴＴＰを介したダイナミックアダプティブストリーミングを使用して実行される。この規格は、メディアプレゼンテーションのメディアコンテンツのコンパクトな記述とＨＴＴＰユニフォームリソースロケーションズ（ＵＲＬｓ）との関連付けを可能にする。このような関連付けは、典型的にはマニフェストファイル又は記述ファイル１６４と呼ばれるファイルに記述される。ＤＡＳＨの文脈では、このマニフェストファイルはＭＰＤファイル(メディアプレゼンテーション記述)とも呼ばれるＸＭＬファイルである。

ＭＰＤファイルを受信することにより、クライアント装置１７０は、各メディア・コンテンツ・コンポーネントの記述を取得する。したがって、それは、メディアプレゼンテーションで提案されるメディアコンテンツ構成要素の種類を認識し、ストリーミングクライアント１６２を介して、ストリーミングサーバ１６１からの関連付けられたメディアセグメント１６５をダウンロードするために使用されるようＨＴＴＰ ＵＲＬｓを知得する。したがって、クライアント１７０は、（ＨＴＴＰ要求を介して）ダウンロードし、再生する（すなわち、復号し、メディアセグメントの受信後に再生するために）ために、どのメディア・コンテンツ・コンポーネントかを判定することができる。クライアント装置は、ユーザのビューポート（すなわち、ユーザによって現在表示され、視聴されている球面ビデオの一部）に依存する、シーンのワイドビューを表すフルパック画像の空間部分に対応するメディアセグメントのみを取得することができることに留意されたい。シーンのワイドビューは、フルパック画像によって表されるフルビューを表すことができる。

受信すると、ステップ１７１の間に、カプセル化された仮想現実メディアファイル又はメディアセグメントは、ステップ１７２で復号される１つ以上のデータストリームを抽出するために、解析される。ステップ１７１で受信されたＩＳＯＢＭＦＦファイル又はセグメントの場合、解析は、典型的には記述メタデータからカプセル化されたビデオビットストリーム及び／又はビデオサブビットストリームを抽出できるｍｐ４リーダ又はｍｐ４パーサによって処理される。次に、オプションとしてステップ１７３で、復号ステップ１７２から生じるパックされた画像又はパックされたサブ画像は、次にビデオレンダリングのために処理され（ステップ１７４）、表示される（ステップ１７５）投影画像を得るために、アンパックされる。あるいは、パックされたサブ画像は、投影ピクチャにアンパックされる前に、中間フルパック画像を合成するように再配置されてもよい。

ビデオレンダリングは、ユーザのビュー、視点及び投影画像を生成するために使用される投影の中から、いくつかのパラメータに依存することに留意されたい。示される通り、ビデオをレンダリングすることは、復号された投影画像を球上に再投影するステップを含む。このような再投影から得られた画像は、ヘッドマウントディスプレイ１７０’に表示される。立体ビューを処理するために、図１を参照することにより記述されるプロセスは、複製されてよく又は部分的に複製されてよい。ＵＨＤ（超高解像度）ビデオストリームのいくつかの画像を仮想現実メディアデータストリームのパノラマ画像にスティッチングすることは、非常に高いビットレート及び非常に高解像度の仮想現実メディアデータストリームをもたらすことが観察される。したがって、システムの観点から、及び帯域幅の消耗を回避するために、及びクライアントプレーヤの処理能力に準拠したままにするために、仮想現実メディアデータへのアクセスを最適化するためのニーズがある。

このようなニーズは、仮想現実メディアデータストリームが図１を参照することにより記述されたものより、他の目的のために使用され得ることがより一層重要である。特に、仮想現実メディアデータストリームは、３６０°のプロジェクタアレイのような特定のディスプレイを有する３６０°画像を表示するために使用され得る。それはまた、特定の視野を表示し、及び／又は視点、視野及び視点を変更するために使用され得る。特定の実施形態によれば、パック画像１３１の符号化（図１のステップ１４０）から生じる符号化ビットストリーム及びサブビットストリームは、カプセル化ファイル・フォーマット、例えば、ＩＳＯベース・メディアファイル・フォーマット（ＩＳＯ／ＩＥＣ １４４９６－１２及びＩＳＯ／ＩＥＣ １４４９６－１５）、全方向メディアフォーマット(ＯＭＡＦ)(ＩＳＯ／ＩＥＣ ２３０９０－２）及びＭＰＥＧ標準化機構によって定義される通りの関連付け仕様に従って、ファイル又は小さい時間セグメントファイルにカプセル化される。

符号化されたビットストリーム（例えば、ＨＥＶＣ）及びおそらくそれのサブビットストリーム（例えば、タイル化されたＨＥＶＣ、ＭＶ－ＨＥＶＣ、スケーラブルＨＥＶＣ）は、１つの単一トラックとしてカプセル化され得る。あるいは、空間的に関連する（すなわち、投影画像のサブ空間部である）複数の符号化されたビットストリームは、いくつかのサブピクチャトラックとしてカプセル化され得る。あるいは、いくつかのサブビットストリーム（タイル、ビュー、レイヤ）を含む符号化されたビットストリーム（例えば、タイル化されたＨＥＶＣ、ＭＶ－ＨＥＶＣ、スケーラブルＨＥＶＣ）は、複数のサブピクチャトラックとしてカプセル化され得る。サブピクチャトラックは、ピクチャ又は画像のサブ部、典型的には空間部又は矩形領域のための、データを埋め込むトラックである。サブピクチャトラックは、他のサブピクチャトラック又はサブピクチャを抽出するフルピクチャを記述するトラックに関連付けられてもよい。例えば、サブピクチャトラックは、タイルトラックとなることができる。それは、ＡＶＣトラック、ＨＥＶＣトラック、ＨＥＶＣタイルトラック、又はサンプルのシーケンスとしてカプセル化された任意の圧縮ビデオビットストリームによって表され得る。

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

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

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

ＩＳＯ／ＩＥＣ １４４９６－１２は、各グループが特定の特性を共有するか、又はグループ内のトラックが特定の関係を持つ、トラックのグループを記述するために、トラック階層（すなわち、ＩＳＯＢＭＦＦボックス階層における‘ｔｒａｋ’ボックス内）に位置する‘ｔｒｇｒ’と示されるボックスを提供する。このトラックグループボックスは、以下のように定義された空のコンテナである。
ボックスタイプ： ‘trgr’
コンテナ： ＴｒａｃｋＢｏｘ（‘trak’）
必須： No
数量： ０又は１
aligned(8) class TrackGroupBox extends Box(‘trgr’) {
}
このトラックグループボックスは、以下のように定義されたトラックグループタイプボックスのセットを含むことができる:
aligned(8) class TrackGroupTypeBox(unsigned int(32) track_group_type)
extends FullBox(track_group_type, version = 0, flags = 0)
{
unsigned int(32) track_group_id;
// 残りのデータは特定のtrack_group_typeに指定されてよい
track_group_type
}

このトラックグループタイプボックスのインスタンスによって宣言された特定の特性又は関係は、ボックスタイプ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ）によって示される。このボックスは、同じトラックグループに属するトラックを判定するために使用され得る、識別情報（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ）も含む。同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ及びｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有するトラックグループタイプボックスと共にトラックグループボックスを有する全てのトラックは、同じトラックグループの一部である。ボックスは、特定のトラックグループタイプのためのトラックに関連付けられる特定のパラメータの宣言も可能にする。ＭＰＥＧ ＩＳＯＢＭＦＦ規格は（ＩＳＯ／ＩＥＣ １４４９６－１２ 第７版 補正１－５月 ２０１８）、２次元空間関係のための特定のトラックグループＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘを、タイプ‘２ｄｃｃ’のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘとして提案している。

‘２ｄｃｃ’に等しいｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅを有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、このトラックが２Ｄ空間関係（例えば、ビデオソースの平面空間部に対応する）を有するトラックのグループに属することを示す。所定のｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、任意の原点（０、０）及びｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔにより定義される最大サイズを有する座標系を黙示的に定義し、ｘ軸は左から右に、及びｙ軸は上から下に向けられる。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内のｓｏｕｒｃｅ＿ｉｄの同じ値を有するトラックは、同じソースから生じるものとしてマッピングされ、それらの関連付けられた座標系は、同じ原点（０、０）及びそれらの軸の向きを共有する。ソース又はビデオソースは、全方向コンテンツのためにカメラ又はカメラのセットによってキャプチャされているコンテンツに対応する。

例えば、非常に高解像度のビデオは、サブピクチャトラックに分割され得る。次に、各サブピクチャトラックは、ソースビデオにおけるそれの位置及びサイズを搬送する。同じｓｏｕｒｃｅ＿ＩＤを持つ同じトラックグループ内のトラックは、同じｏｕｔｐｕｔ＿ｗｉｄｔｈ及びｏｕｔｐｕｔ＿ｈｅｉｇｈｔを宣言する。タイプ‘２ｄｃｃ’の２次元空間関係トラックグループは、以下のように定義される。
aligned(8) class SpatialRelationship2DSourceBox
extends FullBox(‘2dsr’, 0, 0) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
｝

aligned(8) class SubPictureRegionBox extends FullBox(‘sprg’,0,0) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
｝
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc’)
{
//track_group_idは、TrackGroupTypeBoxから引き継がれる;
SpatialRelationship2DSourceBox(); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
｝
ここで、ｏｂｊｅｃｔ＿ｘは、トラックグループを囲むことにより、指定された領域内のトラックの左上角の水平位置を指定する。

位置値は、トラックの幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０からｔｏｔａｌ_ｗｉｄｔｈ－１の範囲内にあれば、ｔｏｔａｌ＿ｗｉｄｔｈは、収容トラックグループによって定義され、ｏｂｊｅｃｔ＿ｙは収容トラックグループによって指定された領域内のトラックの左上角の垂直位置を指定することを含める。位置値は、トラックの幅と高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０からｔｏｔａｌ_ｈｅｉｇｈｔ－１の範囲内にあれば、ｔｏｔａｌ＿ｈｅｉｇｈｔは収容トラックグループによって定義され、ｏｂｊｅｃｔ＿ｗｉｄｔｈは収容トラックグループによって指定された領域内のトラックの幅を指定することを含める。位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１からｔｏｔａｌ＿ｗｉｄｔｈの範囲内にあれば、ｔｏｔａｌ＿ｗｉｄｔｈは収容トラックグループによって定義され、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは収容トラックグループによって指定された領域内のトラック高さを指定することを含める。位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１からｔｏｔａｌ＿ｈｅｉｇｈｔまでの範囲内にあれば、ｔｏｔａｌ＿ｈｅｉｇｈｔは収容トラックグループによって定義され、ｔｏｔａｌ＿ｗｉｄｔｈは、画素部で、「ｓｒｄ」トラックグループの座標系における最大幅を指定することを含める。

ｔｏｔａｌ＿ｗｉｄｔｈの値は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの同じ値を有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘの全てのインスタンスで同じであり、ｔｏｔａｌ＿ｈｅｉｇｈｔが画素部で、‘srd’トラックグループの座標系における最大高さを指定する。ｔｏｔａｌ＿ｈｅｉｇｈｔの値は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの同じ値を有するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘの全てのインスタンスで同じであり、ｓｏｕｒｃｅ＿ｉｄパラメータは、ソースのための一意の識別子を提供する。それは、このソースに関連付けられた座標系を黙示的に定義する。ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）は、収容トラックグループにより指定された領域内のトラックの停止位置及びサイズを提供するオプションのボックスである。

ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）がＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ内に存在する場合、次に、関連付けられたトラック内（このトラックは、定数、停止、サイズ及び位置を有する）に関連付けられたＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙはない。ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ（）がＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ内に存在しない場合、次に、関連付けられたトラック内（このトラックは、おそらく動的なサイズ及び／又は位置を有する）に１つ以上の関連付けられたＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙがある。

「２ｄｃｃ」サンプルグループを定義するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙ（）は、２次元空間関係トラックグループ内のサブピクチャトラックからのサンプルの位置及びサイズを宣言することを可能にする。ｇｒｏｕｐｉｎｇ＿ｔｙｐｅが‘２ｄｃｃ’に等しい場合、ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘのバージョン１が使用される。ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒの値は、対応する空間関係トラックグループのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと等しい。

ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙ（）は、以下のとおり定義される。
class SpatialRelationship2DGroupEntry () extends VisualSampleGroupEntry (‘2dcc’) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
ここで、ｏｂｊｅｃｔ＿ｘは、対応する空間関係トラックグループによって指定される座標系内のこのグループ内のサンプルの左上角の水平位置を指定する。

位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０からｔｏｔａｌ＿ｗｉｄｔｈ－１の範囲にあれば、ｔｏｔａｌ＿ｗｉｄｔｈは対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに含まれ、ｏｂｊｅｃｔ＿ｙは対応する空間関係トラックグループによって指定された座標系のこのグループ内のサンプルの左上角の垂直位置を指定することを含める。位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、０からｔｏｔａｌ＿ｈｅｉｇｈｔ－１の範囲にあれば、ｔｏｔａｌ＿ｈｅｉｇｈｔは対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに含まれ、ｏｂｊｅｃｔ＿ｗｉｄｔｈは対応する空間関係トラックグループによって指定された座標系のこのグループ内のサンプルの幅を指定することを含める。位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１からｔｏｔａｌ＿ｗｉｄｔｈの範囲にあれば、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは、対応する空間関係トラックグループによって指定される座標系のこのグループ内のサンプルの高さを指定することを含める。位置値は、トラック幅及び高さによって引き起こされる黙示的なリサンプリングを適用する前の値であり、１からｔｏｔａｌ＿ｈｅｉｇｈｔの範囲にある場合を含める。

‘２ｄｃｃ’トラックグループ内の各トラックのサンプルは、より大きな画像を生成するために、この同じグループ内の他のトラックからのサンプルで（同じ合成又は復号化時間で）空間的に合成され得る。パックされた画像１３１の符号化（図１のステップ１４０）から生じる符号化されたビットストリーム及びサブビットストリームへの依存により、ファイル・フォーマットにおけるカプセル化のいくつかの変形が可能である。

図２は、本発明の実施形態によるファイル／セグメントカプセル化（図１のステップ１５０）の一例を示すブロック図である。ステップ２００で、サーバはいくつかの空間的に関連付けられたビデオビットストリーム（すなわち、パックされた画像の空間的サブ部を表し、空間的合成がより大きな画像を生成する可能性がある）がある場合、又は複数のサブピクチャトラックとしてクライアントに公開され得る、動き制限されたタイル又は複数のビューのいずれかを表すビデオサブビットストリームを含むビデオビットストリームがある場合を判定する。それは、クリエータがパックされた符号化されたパック画像を複数のトラックとして公開したくない単一のビデオビットストリーム又はコンテンツとして符号化されるので、符号化されたパック画像が複数のトラックとして公開されない場合、ビデオビットストリーム又はビデオサブビットストリームは、次に１つの単一のトラックにカプセル化される（ステップ２１０）。

そうでない場合、それはステップ２２０において、カプセル化されるメディアコンテンツが、動き制限されたタイルを表すビデオサブビットストリームから合成される場合、判定される。ｙｅｓの場合、複数のタイルトラックの少なくとも１つの合成を表すために、少なくとも１つの合成トラックが提供される必要がある。合成は、完全にパックされた画像又は完全にパックされた画像のサブ部のみを表すことができる。タイルトラックで合成トラックを使用することは、クライアント側で別のレンダリング及びストリームの復号を要求することを防ぐ。クライアントに公開される可能な組み合わせの数は、コンテンツクリエータの選択に依存する。例えば、コンテンツクリエータは、現在のユーザのビューポートに応じて、異なる視覚的品質を持つタイルを組み合わせたい場合がある。これに対して、それは異なる視覚的品質を有するパック画像を数回符号化でき、視覚的品質に関してタイルの異なる組合せを備えるフルパック画像を表すいくつかの合成トラックを提案することができる。ユーザのビューポートに応じて異なる品質でタイルを結合することにより、コンテンツクリエータは、ネットワークリソースの消費を低減できる。

ステップ２２０において、合成トラックが提供されなければならないと判定される場合、次に合成トラックに対して黙示的な再構成が使用されるか否かが判定される（ステップ２４０）。黙示的な再構成とは、例えばＩＳＯ／ＩＥＣ １４４９６－１５第４版で定義されるように、タイルベース及びタイルトラックからのビットストリーム再構成を指す。タイルトラックのサンプル中でそれらが参照するデータにより、合成トラックのサンプルの抽出手段を置き換えることにより、タイルトラックのサンプルから合成トラックのサンプルを再構成するための抽出手段のようなインストリーム構造を使用するのではなく、黙示的な再構成は、参照トラックの順序（例えば、ＨＥＶＣの黙示的な再構成における‘ｓａｂｔ’参照トラック）における合成トラック及びタイルトラックのサンプルを連結することにより、合成トラックのサンプルを再構成することを可能にする。

黙示的な再構成の使用は、使用のシナリオに依存する。いくつかのタイルトラックの合成が、符号化でタイルの順序と比較して、復号化でタイルの再構成を必要とする場合、いくつかのスライスアドレスは、書き換えられなければならない。このような場合、黙示的な再構成は可能ではなく、抽出手段を備える明示的な再構成が選択されなければならない。黙示的な再構成が可能である場合、タイルベーストラックが生成され（ステップ２４１）、ビデオサブビットストリームは独立して復号可能ではないタイルトラックとして（例えば、ＨＥＶＣ‘ｈｖｔ１’トラックとして）カプセル化される。そうでない場合、抽出手段トラックが生成され（ステップ２４２）、ビデオサブビットストリームは独立して復号可能なタイルトラックとして（例えば、ＨＥＶＣ‘ｈｖｃ１’又は‘ｈｅｖ１’トラックとして）カプセル化される。

ステップ２２０に戻ると、メディアコンテンツは、コンテンツクリエータが合成トラックを作成及び公開したくないタイルサブビットストリーム又はコンテンツを含まない場合、次に空間的に関連付けられたビデオビットストリーム又はビデオサブビットストリーム（例えばタイル又は複数ビュー）が別のサブピクチャトラックにカプセル化される（ステップ２３０）。このような特定の場合では、タイルサブビットストリームがＨＥＶＣタイルである場合、それらはＨＥＶＣトラック‘ｈｖｃ１’又は‘ｈｅｖ１’トラックとしてカプセル化される。ステップ２５０では、空間合成のための信号が空間的に関連付けられたビデオビットストリーム又はビデオサブビットストリームを一緒にグループ化するように追加される。空間合成信号は、例えば前述のように、ＭＰＥＧ ＩＳＯＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６－１２ 第７版 補正１）で定義されるように、同じグループに関連する全てのトラックに対して、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するタイプ‘２ｄｃｃ’のトラックグループなど、グループを合成する各トラック（サブピクチャトラック、タイルトラック、合成トラック）内に固有のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘを定義することによって提供されてよい。

このトラックグループボックス‘２ｄｃｃ’は、合成内のトラックの相対的な２次元座標及び合成によって形成される画像の全体サイズを提供する。合成は、パックされた全体画像又はパックされた画像のサブ部のみを表すことができる。例えば、コンテンツクリエータは、パックされた全体画像又はパックされた画像のサブ部のみを構成することを可能にしながら、複数の合成トラックを公開したい場合がある。あるいは、合成は、全体投影画像又は投影画像のサブ部のみを表すことができる。‘２ｄｃｃ’トラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ、ｓｏｕｒｃｅ＿ｉｄ、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）からのパラメータは、それらのトラックを表す適応セットの空間関係を記述するために、ＤＡＳＨマニフェストで使用され得るＤＡＳＨ Ｓｐａｔｉａｌ－Ｒｅｌａｔｉｏｎｓｈｉｐ Ｄｅｓｃｒｉｐｔｉｏｎ（ＳＲＤ）記述子（ＩＳＯ／ＩＥＣ ２３００９－１ 第３版で定義される）のパラメータと直接一致する。

ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄパラメータに一致し、ｓｏｕｒｃｅ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｏｕｒｃｅ＿ｉｄパラメータに一致し、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤパラメータｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔパラメータにそれぞれ一致し、関連付けられたトラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを介して）からのｔｒａｃｋ＿ｇｒｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤ ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔパラメータに一致する。

代替として、合成トラックがある場合、空間合成信号は、この合成トラックによって黙示的に提供されてよい。実際、合成トラックがタイルベーストラックである場合、タイルベーストラックは、タイプ‘ｓａｂｔ’の参照トラックを介してタイルトラックのセットを参照する。このタイルベーストラック及びタイルトラックのセットは、合成グループを形成する。同様に、合成トラックが抽出手段トラックである場合、抽出手段トラックは、タイプ‘ｓｃａｌ’の参照トラックを介して、タイルトラックのセットを参照する。この抽出手段トラック及びタイルトラックのセットは、合成グループも形成する。両方の場合で、合成の各タイルトラックの相対的な２次元座標は、ＩＳＯ／ＩＥＣ １４４９６－１５ 第４版で定義されるように、タイプ‘ｔｒｉｆ’のサンプルグループ又は既定のサンプルグループを定義することにより提供され得る。

別の代替として、新しいエンティティグループを定義することによって、空間合成信号が提供され得る。エンティティグループは、項目又はトラックのグループである。エンティティグループは、ＭｅｔａＢｏｘ内のＧｒｏｕｐｓＬｉｓｔＢｏｘ内に示される。トラックを参照するエンティティグループは、ファイルレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘ又はムービーレベルＭｅｔａＢｏｘのＧｒｏｕｐｓＬｉｓｔＢｏｘ内で指定され得る。ＧｒｏｕｐＬｉｓｔＢｏｘ （‘ｇｒｐｌ’）は、定義されたグループタイプを示す４文字のコードが関連付けられた、それぞれＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘと呼ばれるフルボックスのセットを含む。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは次のように定義される。
aligned(8) class EntityToGroupBox(grouping_type, version, flags) extends FullBox(grouping_type, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i＜num_entities_in_group; i++)
unsigned int(32) entity_id;
// 残りのデータは特定のｇｒｏｕｐｉｎｇ＿ｔｙｐｅに対して指定され得る
｝

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

ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（‘ｅｇｃｏ’）は以下のとおり定義される。
aligned(8) class EntityToGroupBox(‘egco', version, flags)
extends FullBox(‘egco', version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i＜num_entities_in_group; i++)
unsigned int(32) entity_id;
unsigned int(16) total_width;
unsigned int(16) total_height;
unsigned int(32) source_id;
｝
ここで、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、合成サイズを備え、ｓｏｕｒｃｅ＿ｉｄはソースに対する一意の識別子を備え、ソースに関連付けられた座標系（つまり、原点（０，０）及びそれらの軸の方向） を黙示的に定義する。

ＤＡＳＨと比較すると、ｇｒｏｕｐ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄパラメータと一致し、ｓｏｕｒｃｅ＿ｉｄはＤＡＳＨ ＳＲＤ ｓｏｕｒｃｅ＿ｉｄパラメータと一致し、及びｔｏｔａｌ＿ｗｉｄｔｈ とｔｏｔａｌ＿ｈｅｉｇｈｔはＤＡＳＨ ＳＲＤ ｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔのパラメータとそれぞれ一致する。タイプ‘ｅｇｃｏ’のエンティティグループ化によって定義される合成内の各トラックの相対的な２次元座標は、以下に定義されるように、タイプ（‘ｅｇｃｏ’）のトラックグループを定義することによって提供され得る。
aligned(8) class SubPictureRegionBox extends FullBox(‘sprg',0,0) {
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
｝
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc')
｛
// track_group_idはTrackGroupTypeBoxから引き継がれる;
SubPictureRegionBox ();
｝
ここで、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔは、合成内の各トラックの相対的な２次元座標を備える。

タイプ‘ｅｇｃｏ’の所定のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘは、ｇｒｏｕｐ＿ｉｄがｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと等しいように定義することで、対応するＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘに関連付けられる。あるいは、‘ｅｇｃｏ’タイプのエンティティグループによって定義される合成内の各トラックの相対的な２次元座標は、ＩＳＯ／ＩＥＣ １４４９６－１５ 第４版で定義されるように、各タイルトラックに‘ｔｒｉｆ’タイプのサンプルグループ又は既定のサンプルグループを定義することによって、提供され得る。代替として、相対的な２次元座標は、グループに関連する各タイルトラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する新しい汎用フルボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（‘２ｄｃｏ’）として定義され得る。
aligned(8) class 2DCoordinateForEntityGroupBox extends FullBox(‘2dco', version, flags)
｛
unsigned int(32) entity_group_id;
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
｝

ここで、ｅｎｔｉｔｙ＿ｇｒｏｕｐ＿ｉｄはグループを定義する関連付けられたＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ（‘ｅｇｃｏ’）の識別子を備え、ｏｂｊｅｃｔ＿ｘ及びｏｂｊｅｃｔ＿ｙは合成内のこのトラックのサンプルの左上角の水平位置及び垂直位置を提供し、ｏｂｊｅｃｔ＿ｗｉｄｔｈ及びｏｂｊｅｃｔ＿ｈｅｉｇｈｔは合成内のこのトラックのサンプルの幅と高さを提供する。別の方法として、この新しい汎用ボックス２ＤＣｏｏｒｄｉｎａｔｅＦｏｒＥｎｔｉｔｙＧｒｏｕｐＢｏｘ（‘２ｄｃｏ’）は、以下のとおり新しいサンプルグループとして定義され得る。
class 2DCoordinateForEntityGroupBox extends VisualSampleGroupEntry('2dco')
｛
unsigned int(32) entity_group_id;
unsigned int(16) object_x;
unsigned int(16) object_y;
unsigned int(16) object_width;
unsigned int(16) object_height;
｝

図２に戻って、ステップ２６０で、トラックに対する領域的パック情報が、ビデオビットストリーム又はビデオサブビットストリームのカプセル化を記述するメタデータに追加される。領域的パックは、パックされた領域内のルマサンプル位置を、対応する投影された領域のルマサンプル位置に再マッピングするための情報を提供する。ＭＰＥＧ ＯＭＡＦでは、領域的パックが以下のデータ構造に従って記述されてよい。
aligned(8) class RegionWisePackingStruct() {
unsigned int(1) constituent_picture_matching_flag;
bit(7) reserved = 0;
unsigned int(8) num_regions;
unsigned int(32) proj_picture_width;
unsigned int(32) proj_picture_height;
unsigned int(16) packed_picture_width;
unsigned int(16) packed_picture_height;
for (i = 0; i ＜ num_regions; i++) {
bit(3) reserved = 0;
unsigned int(1) guard_band_flag[i];
unsigned int(4) packing_type[i];
if (packing_type[i] == 0) {
RectRegionPacking(i);
if (guard_band_flag[i])
GuardBand(i);
｝
｝
｝
ここで、ｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、相対的投影ピクチャサンプルユニットにおける投影ピクチャの幅及び高さをそれぞれ指定し、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、相対的パック化ピクチャサンプルユニットにおけるパック化ピクチャの幅及び高さをそれぞれ指定し、ｎｕｍ＿ｒｅｇｉｏｎは、ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しい場合のパックされた領域の数を指定する。

ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しい場合、パック領域の全体数は、２* ｎｕｍ＿ｒｅｇｉｏｎに等しく、ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）及びＧｕａｒｄＢａｎｄ（ｉ）内の情報は、投影ピクチャ及びパック化ピクチャの各立体構成ピクチャに適用し、ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）は、ｉ番目のパック領域とｉ番目の投影領域との間の領域的パックを指定し（すなわち、ｘ、ｙ、幅、高さ座標を、パック領域から任意の変換（回転、ミラーリング）を伴う投影領域に変換する）、及びＧｕａｒｄＢａｎｄ（ｉ）は、もしあれば、ｉ番目のパック領域について、ガードバンドを指定する。本発明の実施形態によれば、領域的パック情報がサブピクチャトラック内で定義されるとき、この構造は、完全投影ピクチャの参照によってサブピクチャトラックのパックのみを記述する。このように、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔは、サブピクチャトラックの幅及び高さに等しい。

ステップ２７０で、トラック及びトラックの合成のためのコンテンツカバレッジ情報が、ビデオビットストリーム又はビデオサブビットストリームのカプセル化を記述するメタデータに追加される。このステップはオプションである。トラックカバレッジ情報は、このトラックにより表されるコンテンツでカバーされる球上の領域の情報を備える。合成カバレッジ情報は、１つ以上のトラックの組合せに関連付けられる球面上の領域の情報を備える。例えば、ムービーファイルが空間関係を有する複数のビデオトラックを含む場合、合成カバレッジ情報は、これらの複数のビデオトラックの空間的合成によってカバーされる球面上の領域である。別の例では、メディアファイルは、複数のビデオトラック及びこのトラックのセットをレンダリングする方法を示す変換マトリクスを含み、合成カバレッジ情報は次に、組み立てられたトラックのセットによってカバーされる領域に対応する。「合成カバレッジ情報」は、「グローバルカバレッジ情報」又は「トラックグループ合成情報」と表すこともできる。合成又はグローバルカバレッジ情報はまた、これらの複数のビデオトラックのサブセットの合成から生じる球面上の領域を記述することができる。

第１の実施形態として、トラックカバレッジ情報及び合成カバレッジ情報は、追加の信号なしに、単一の共通カバレッジ情報ボックスを使用して、信号伝達され得る。そのような場合、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘの範囲は、ボックス階層内のこのボックスの定義の位置に依存する。クライアントは、カバレッジ情報が宣言されることを考慮することによって、トラックコンテンツ又はコンテンツ全体に関連するかどうかを判断することができる。この実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、以下のように定義される。
ボックスタイプ： ‘ｃｏｖｉ’
コンテナ： 投影全方向ビデオボックス（‘ｐｏｖｄ’）又はＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ(‘２ｄｃｃ’）
必須： Ｎｏ
数量： ０又は１
aligned(8) class CoverageInformationBox extends FullBox(‘covi', 0, 0) {
ContentCoverageStruct()
｝
ここで、ＣｏｎｔｅｎｔＣｏｖｅｒａｇｅＳｔｒｕｃｔは、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（）で記述されるカバー領域の数を以下の通り指定する。

aligned(8) SphereRegionStruct(range_included_flag) {
signed int(32) centre_azimuth;
signed int(32) centre_elevation;
signed int(32) centre_tilt;
if (range_included_flag) {
unsigned int(32) azimuth_range;
unsigned int(32) elevation_range;
｝
unsigned int(1) interpolate;
bit(7) reserved = 0;
｝
aligned(8) class ContentCoverageStruct() {
unsigned int(8) coverage_shape_type;
unsigned int(8) num_regions;
unsigned int(1) view_idc_presence_flag;
if (view_idc_presence_flag == 0) {
unsigned int(2) default_view_idc;
bit(5) reserved = 0;
} else
bit(7) reserved = 0;
for ( i = 0; i ＜ num_regions; i++) {
if (view_idc_presence_flag == 1) {
unsigned int(2) view_idc[i];
bit(6) reserved = 0;
｝
SphereRegionStruct(1);
｝
｝

ここで、ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅはコンテンツカバレッジを表す球体領域の形状を指定し、ｎｕｍ＿ｒｅｇｉｏｎｓは球体領域の数を指定し、ｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇ、ｄｅｆａｕｌｔ＿ｖｉｅｗ＿ｉｄｃ及びｖｉｅｗ＿ｉｄｃ［ｉ］は、ｉ番目の球体領域が立体視コンテンツの左側、右側、又は両方のビューにある場合を示すために使用されるプロパティであり、ｃｅｎｔｅｒ＿ａｚｉｍｕｔｈ、ｃｅｎｔｅｒ＿ｅｌｖｅｔｉｏｎ、ｃｅｎｔｅｒ＿ｔｉｌｔは世界座標軸、ａｚｉｍｕｔｈ＿ｒａｎｇｅ、及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅに対して相対的なカバー領域のビューポート方向を指定し、存在する場合、カバーされた球体領域の方位角と仰角の範囲をそれぞれ指定し、補間は現在使用されていない。したがって、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、コンテンツによってカバーされる球体上の領域の情報を備える。コンテンツの特性は、このボックスのコンテナに依存する。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘ‘２ｄｃｃ’に存在する場合、コンテンツは同じサブピクチャ合成トラックグループに属する全てのトラックによって表されるコンテンツ全体を指し、これらのトラックから合成される合成ピクチャは、コンテンツ全体のパック化ピクチャと呼ばれる。トラックのサンプルエントリ内に存在する場合、コンテンツはこのトラック自体によって表されるコンテンツを参照し、及びこのトラック内のサンプルピクチャは、コンテンツ全体のパック化ピクチャと呼ばれる。トラックに対してＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎ Ｂｏｘが存在しない場合、それは、コンテンツが球全体をカバーすることを示す。

投影全方向ビデオボックス（‘ｐｏｖｄ’）は、ＭＰＥＧ ＯＭＡＦによって定義され、トラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する中間ボックスであることに留意されたい。さらに、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループボックス（‘２ｄｃｃ’）は、以下のように修正される。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc')
｛
// track_group_idは、TrackGroupTypeBoxから引き継がれる；
SpatialRelationship2DSourceBox(); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
CoverageInformationBox(); // オプション
｝

第２の実施形態として、トラックカバレッジ情報及び合成カバレッジ情報は、ローカル及びグローバル指示を区別するためにフラグ値を有する単一の共通カバレッジ情報ボックスを使用して信号伝達され得る。ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘはＩＳＯＢＭＦＦ ＦｕｌｌＢｏｘであるため、トラックとグローバルカバレッジとの間の区別は、ボックスのフラグパラメータを介して表され得る。この第２の実施形態によれば、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎ Ｂｏｘは、以下のように定義される。
ボックスタイプ： ‘ｃｏｖｉ’
コンテナ ： 投影全方向ビデオボックス（‘ｐｏｖｄ’）
必須 ： Ｎｏ
数量 ： ０又は１
aligned(8) class CoverageInformationBox extends FullBox(‘covi', 0, 0) {
ContentCoverageStruct()
｝

ボックスの構造は、ボックスの複数のインスタンスが、ローカル及び合成の場合に定義されてよく、カバレッジ情報が同じトラックに定義されなければならないことを除いて、前の実施形態とほぼ同じである。次に、ＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘは、コンテンツによってカバーされる球上の領域の提供情報として定義される。コンテンツの特性は、フラグパラメータで与えられる。カバレッジ情報フラグの既定値は０で、このボックスはコンテンツ全体のカバレッジを記述することを意味する。このトラックが２次元空間関係トラックグループに属する場合、コンテンツ全体は同じ２次元空間関係トラックグループに属する全てのトラックによって表されるコンテンツを指し、これらのトラックから合成される合成ピクチャは、コンテンツ全体のパック又は投影ピクチャと呼ばれる。そうでない場合、コンテンツ全体はこのトラック自身によって表されるコンテンツを参照し、このトラック内のサンプルのピクチャは、コンテンツ全体のパック又は投影ピクチャと呼ばれる。

カバレッジ情報フラグの値が１である場合、このボックスは、このトラックによって表されるコンテンツのパック又は投影ピクチャによってカバーされる球状領域を記述する。このボックスが存在しないことは、コンテンツが球全体をカバーすることを示す。さらに、新たなフラグ値は、以下のように定義される。ｃｏｖｅｒａｇｅ＿ｌｏｃａｌ：は、カバレッジ情報がボックスを含むトラックにローカルであることを示す。フラグ値は０ｘ０００００１である。既定により、この値はセットではない。図２に戻って、ステップ２８０で、仮想現実メディアコンテンツが実際に立体仮想現実メディアコンテンツであるかどうか、すなわち、左及び右ビューを含むかどうかがチェックされる。コンテンツが平面視のみである場合、処理は直接ステップ２９０に進む。コンテンツが立体視である場合、ステップ２８５で、立体視信号がカプセル化に追加される。

立体視コンテンツについて、従来、左及び右ビューシーケンスの両方は立体視カメラから取得され、合成タイプによるビデオシーケンス又は２つのビデオシーケンスに合成される。立体視コンテンツの２つの異なるビューを表す２つのフレームを１つの単一フレームに結合するための処理は、フレームパックと呼ばれる（図１のステップ１２５参照）。フレームパックは、立体ペアを形成する２つのビューを単一のフレームにパッキングすることからなる。いくつかのよく知られ、使用されているフレームパック方法が存在する、並行、上下、フレーム順、垂直ライン仕切りタイプなど。例えば、ＭＰＥＧアプリケーションフォーマットＩＳＯ／ＩＥＣ ２３０００－１１ 第１版（「立体視ビデオアプリケーションフォーマット」）又はＩＳＯ／ＩＥＣ ２３００１－８ 第２版（「コーデック非依存コードポイント（ＣＩＣＰ）」）はこれらの方式のいくつかを定義する。フレームパックは例えば、ＩＳＯ／ＩＥＣ ２３００１－８ 第２版（「ＣＩＣＰ」）で定義された値６を有するＶｉｄｅｏＦｒａｍｅＰａｃｋｉｎｇＴｙｐｅのような、それぞれのビューを別々のフレームに保持することからなることもできる。

例えば、さらに本明細書によれば、値３は各復号化フレームが２つの構成ビューの対応するフレームの並列パッキング構成を含むことを信号伝達し、値４は、各復号化フレームが２つの構成ビューの対応するフレームの上下パック構成を含むことを信号伝達する。トラックが立体視メディアデータを含むかどうかを信号伝達するために、ＳｔｅｒｅｏＶｉｄｅｏＢｏｘがトラック内のＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに定義される。図２のステップ２５０に戻ると、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘは、以下の表に提供されるように、ビデオトラック間の空間関係を表すために、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）プロトコル（ＩＳＯ／ＩＥＣ ２３００９－１ 第３版）で定義されているように、空間関係記述子‘ＳＲＤ’の定義と一致するように定義される。

‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、トラックがビデオの空間部分に対応するトラックのグループに属していることを示す。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ‘２ｄｃｃ’のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内でｓｏｕｒｃｅ＿ｉｄの同じ値をもつトラックは、同じソース（つまり、同じ原点（０、０）及びそれらの軸の同じ方向）から生じるものとしてマッピングされる。より正確には、同じｓｏｕｒｃｅ＿ｉｄを有する２つのトラックグループからの完了合成ピクチャ（ｓｉｚｅ ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔを有する）が知覚的又は視覚的に等価である（例えば、２つの異なる解像度又は２つの異なる品質で同じ視覚コンテンツを表す２つの合成ピクチャ）。‘２ｄｃｃ’ ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘに属する全てのサブピクチャトラックは、同じｓｏｕｒｃｅ＿ｉｄを有する。

‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び異なるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを有するＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘに属するトラックは、互換性があり、それらが同じｓｏｕｒｃｅ＿ｉｄを有する場合、一緒に組み合わせられ得る。そうでない場合、サブピクチャトラックは、同じソースのサブ部を表さない、及び／又は、それらは‘２ｄｃｃ’ｔｒａｃｋ＿ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ及び異なるｓｏｕｒｃｅ＿ｉｄに、別のＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘからのサブピクチャトラックが組み合わされることは意図されていない。例えば、２つのサブピクチャトラックは、このソースを表す２次元投影ピクチャが視覚的に等価でない場合（例えば、それらが異なる投影フォーマット又は異なるビューポート方向を有する場合）、同じソースのサブ部を表さない。代替として、この後のルールは、異なるｓｏｕｒｃｅ＿ｉｄを有する‘２ｄｃｃ’トラックグループからのサブピクチャトラックをグループ化する代替グループが存在する場合であっても適用する。それは、それらのサブピクチャトラックが代替である（例えば、それらは異なる符号化フォーマット、例えば、ＡＶＣ及びＨＥＶＣなどを有する）、しかし、それらは異なる符号化フォーマットを有するサブピクチャトラックと組み合わされることが意図されていない。

図４は、上記のルールの例を示す。トラック＃１から＃４は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０に等しく、かつ、ｓｏｕｒｃｅ＿ｉｄが１に等しい、タイプ‘２ｄｃｃ’のトラックグループ４１に属する。トラック＃５から＃８は、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄは２０に等しいが、同じｓｏｕｒｃｅ＿ｉｄ ４００は１に等しい、タイプ‘２ｄｃｃ’の異なるトラックグループ４２に属する。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが３０に等しく、異なるｓｏｕｒｃｅ＿ｉｄ ４０１が２に等しい、タイプ‘２ｄｃｃ’の３番目のトラックグループ４３もある。さらに、いくつかの交互のグループ４４から４７がある。同じ代替グループに属する全てのトラック（つまり、それらのトラックヘッダボックス‘ｔｋｈｄ’内に同じａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ識別子を有する）は、代替データを含むトラックのグループ又はコレクションを指定する。代替データは、代替ビットレート、コーデック、言語、パケットサイズなどに対応してもよい。代替グループ内の１つのトラックのみが、いつでも再生され又はストリーミングされるべきである。

この例では、トラック＃１、＃５及び＃９は１００に等しい識別子を有する同一の代替グループ４４に属する。例えば、トラック＃１及びトラック＃５は、異なる品質の交互のトラックであり、トラック＃９はコーデックに関してトラック＃１及びトラック＃５への交互のトラックである。トラック＃２、＃６及び＃１０は、識別子が２００に等しい同じ代替グループ４５に属し、例えば、トラック＃２及びトラック＃６は、解像度が異なる代替トラックであり、トラック＃１０はフレームレートなどに関して、トラック＃２及びトラック＃６への代替トラックである。トラックグループ４１及び４２は、同一のｓｏｕｒｃｅ＿ｉｄ ４００を有し、トラックグループ４３は、トラックグループ４１及び４２に属するサブピクチャトラックが（他の制約、すなわち、代替グループ毎にほぼ１つのサブピクチャトラックに関して）一緒に組み合わせられ得ることを意味する、異なるｓｏｕｒｃｅ＿ｉｄ ４０１を有する。反対に、トラックグループ４３からのサブピクチャトラックは、それらが同じｓｏｕｒｃｅ＿ｉｄを有していないので、それらが同じ代替グループに属することができるにもかかわらず、トラックグループ４１及び４２からの任意のサブピクチャトラックと結合されることが意図されていない。

次に、ｓｏｕｒｃｅ＿ｉｄパラメータは、同じ空間合成の一部となり得るサブピクチャトラック上のプレーヤに表示を提供する。所定の空間位置に対して、一つのサブピクチャトラックは同じ所定の空間位置で他のサブピクチャトラックと視覚的に等価であると見なされ得る。これは、メディアコンテンツが複数のトラックに提供される場合、（サブピクチャ）トラック選択にとって有用である。さらに、それは選択されたサブピクチャトラックに依存して、動的適応（品質／ビットレート又は解像度において）が同じ空間合成を表示することを可能にする。いくつかの使用例は、図５及び６に従って説明される。

図５は、本発明の実施形態によるＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びｓｏｕｒｃｅ＿ｉｄの使用例を示す。同じビデオソース（例えば、同じ投影ビデオソース）は、品質（＠ｑｕａｌｉｔｙ１及び＠ｑｕａｌｉｔｙ２）に関して、２つの代替版を生成するために使用される。各代替版は、８つのサブピクチャトラック（投影領域又はパック領域を含む）に分割される。サブピクチャトラックの第１のセットは、低品質で利用可能である。サブピクチャトラックの第２のセットは、より高品質で利用可能である。品質レベル毎に１つで、２つのトラックグループが定義される。対応するサブピクチャトラックは、図５の右側部分（‘ｔｒａｋ’ボックス階層において）のように記載され得る。両方のトラックグループは、同一のｓｏｕｒｃｅ＿ｉｄ、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔを有する。サブピクチャトラック座標（ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）は、サブピクチャトラックの空間関係又はそれぞれのトラックグループ合成内の位置を記述する。両方のトラックグループは同じｓｏｕｒｃｅ＿ｉｄを有するため、それらが１番目のトラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０に等しい）からの同じソーストラック及びサブピクチャトラックを表す、この手段は、合成におけるそれらのそれぞれの位置に関して、同じトラックグループからのサブピクチャトラックと組み合わせられてよく、２番目のトラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが２０に等しい）からのサブピクチャトラックと組み合わせられてもよい。

図６は、本発明の実施形態によるＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘ及びｓｏｕｒｃｅ＿ｉｄの第２の使用例を示す。同じビデオソース（例えば、同じ投影ビデオソース）が、解像度（＠ｒｅｓｏｌｕｔｉｏｎ１及び＠ｒｅｓｏｌｕｔｉｏｎ２）に関して、２つの代替版を生成するために、使用される。サブピクチャトラックには２つのセットがあり、１つは高解像度用及び１つは低解像度用である。対応するサブピクチャトラックは、図６の右側部分（‘ｔｒａｋ’ボックス階層において）のように記述され得る。両方のトラックグループは、同じｓｏｕｒｃｅ＿ｉｄを有するが、それぞれのサブピクチャトラックの解像度に対応する、異なるｔｏｔａｌ＿ｗｉｄｔｈとｔｏｔａｌ＿ｈｅｉｇｈｔを有する。サブピクチャトラック座標（ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）は、サブピクチャトラックの空間関係又はそれらのそれぞれのトラックグループ合成内の位置を記述する。再び、両方のトラックグループが同じｓｏｕｒｃｅ＿ｉｄを有するので、１番目のトラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０に等しい）からの同じソーストラックとサブピクチャトラックを表すこの手段は、それらの合成におけるそれらのそれぞれの位置に関して、同じトラックグループのサブピクチャトラックと組み合わせられてよく、２番目のトラックグループ（ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが２０に等しい）からのサブピクチャトラックと組み合わせられてもよい。この場合、スケーリングは、それらが一緒に合成される場合、異なるトラックグループからのサブピクチャトラックに適用される。スケーリングファクタは、各トラックグループからのｔｏｔａｌ＿ｈｅｉｇｈｔとｔｏｔａｌ＿ｗｉｄｔｈとの間の比（例えば、Ｈ１／Ｈ２及びＷ１／Ｗ２）から推定され得る。

この例によれば、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄが１０に等しいトラックグループによって表される合成ピクチャは、各代替グループから１つのサブピクチャを選択することによって合成され得る。２次元（２Ｄ）ビデオコンテンツとは反対に、ＯＭＡＦメディアコンテンツは、球の内側表面に向かって外向きに見た球の中心からのユーザの視点を示す全方向メディアコンテンツを表す。次に、この３６０°メディアコンテンツは、ビデオ投影フォーマットを適用することによって２次元平面に投影される。次に、オプションで、領域的パックは、投影ピクチャからパック領域の中へ領域を再編成するよう適用される。３６０°メディアコンテンツは、魚眼レンズ（広角カメラレンズ）を用いてキャプチャされたいくつかの円形画像によって表わされてもよい。このように、ＯＭＡＦの文脈において、２Ｄピクチャは投影ピクチャ又はパック化ピクチャのいずれかであってよく、サブピクチャトラックは異なる種類のコンテンツを含んでもよい。投影ピクチャのサブ部（パックなし）、フレームパック化ピクチャのサブ部、例えば、コンテンツが立体視、投影及びパック化ピクチャのサブ部、又は魚眼符号化ピクチャのサブ部である場合。

本発明の実施形態によれば、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘの定義は、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標が投影ピクチャに、パック化ピクチャに、又は別のピクチャに対して相対的であるかどうかを示すために改善される。一実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標が常にパック化ピクチャに対して相対的であるように定義される。パックがない場合、パック化ピクチャは投影ピクチャに等しい。別の実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘは、ＯＭＡＦメディアコンテンツを含むサブピクチャトラックのサイズ及び位置座標がキャプチャステップ１１０と符号化ステップ１４０との間の処理ステップにおいて、投影ピクチャ又はパック化ピクチャ又は任意の中間ピクチャに対して相対的であるように定義される。特に、全方向性メディア（ＯＭＡＦ）用のアプリケーションフォーマットの場合、２Ｄ空間関係で表現される位置及びサイズが、投影又はパック化ピクチャを参照するかどうかは明確ではない。

一実施形態では、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘが常にパック化ピクチャに対して相対的である。パックがない場合、パック化ピクチャは投影ピクチャと同じである。別の実施形態では、好ましいアプローチはＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘが常に投影ピクチャに対して相対的であることを定義することである。シーンのワイドビューに対応する符号化メディアデータをカプセル化するための方法は、いくつかの実施形態では以下のステップを含むことができる。シーンの広いビューからの投影ピクチャを得ること、得られた投影ピクチャを少なくとも１つのパック化ピクチャにパッキングすること、少なくとも１つのパック化ピクチャを少なくとも１つのサブピクチャに分割すること、少なくとも１つのサブピクチャを複数のトラックに符号化すること、符号化トラックに関連付けられた記述メタデータを生成することであって、記述メタデータは、トラックにおいて符号化された少なくとも１つのサブピクチャと少なくとも１つの投影ピクチャとの間の空間関係を示す、各トラックに関連付けられた情報の項目を含む。

したがって、参照ピクチャの特定の信号は必要とされない。参照ピクチャは、サブピクチャがパック化ピクチャを分割することにより得られる場合であっても、投影ピクチャとなるように定義される。シーンのワイドビューに対応する符号化メディアデータをカプセル化するための方法は、いくつかの実施形態では以下のステップを含むことができる。シーンの広いビューからの投影ピクチャを得ること、投影ピクチャを少なくとも１つのサブピクチャに分割すること、少なくとも１つのサブピクチャを複数のトラックに符号化すること、符号化トラックに関連付けられた記述メタデータを生成すること、記述メタデータは、トラック内で符号化された少なくとも１つのサブピクチャと参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を含み、記述メタデータは、参照画像を示す第２の情報項目をさらに含む。したがって、メタデータ内の参照ピクチャを指定することにより、分割操作とは独立して、投影ピクチャ、パック化ピクチャ、又は他の参照ピクチャのいずれかに関連付けられたサブピクチャデータを生成することが可能である。

以下の表は、投影、例えば正距円筒図法（ＥＲＰ）又はキューブマップ投影、パック又は魚眼コンテンツを使用することのいずれかを含むサブピクチャトラック用のＯＭＡＦの文脈において、投影ピクチャに対して相対的である、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループサイズ及び座標プロパティの実用的なマップを提案する。以下の表において、‘ｒｗｐｋ’は領域的パック構造用のショートカット、すなわち、パック領域とそれぞれの投影領域との間のマップを指定する構造であり、もしあれば、ガードバンドの位置及びサイズを指定する。なお、‘ｆｏｖｉ’は、ＯＭＡＦプレーヤで魚眼画像のスティッチング及びレンダリングを可能にするためのパラメータを記述する構造で、ＦｉｓｈｅｙｅＶｉｄｅｏＥｓｓｅｎｔｉａｌＩｎｆｏＳｔｒｕｃｔのためのショートカットである。

ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘプロパティを投影ピクチャに対して定義することは、それらをパック化ピクチャに対して定義することと比較して、アプリケーションに利点を提供する。実際、ビューポート依存ストリーミングの場合、アプリケーションは現在のユーザのビューポートに対応する（すなわち、ユーザの視野と方向に対応する）サブピクチャトラックのみをダウンロードしたい場合がある。ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘプロパティが投影ピクチャに対して定義される場合、アプリケーションは、それが投影ピクチャ内で動いている間に、適切なサブピクチャトラックを選択するために、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤｄｅｓｃｒｉｐｔｉｏｎＢｏｘトラックグループからこの情報を直接使用できる。そうでない場合、アプリケーションは適切なサブピクチャトラックを選択することができる前に、サブピクチャパックコンテンツを投影ピクチャに変換するために、トラックグループ情報に加えて、ＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙ内に位置する領域的パック情報を解析する必要がある。

オプションで、空間関係を記述するトラックグループ（例えば、‘２ｄｃｃ’トラックグループ）は、所定のサブピクチャトラックについて、３６０°球へのそれのマップを提供する追加の記述子を含むことができる。この追加の記述子は、所定のユーザの視線方向に対応するトラックの関連するトラック又はセットのプレーヤによる選択がより容易になるように、メディアプレーヤのためのいかなる計算もなしに、２Ｄビデオサブピクチャトラックと３Ｄビューポートとの間のマップを提供する。次に、空間関係を記述するトラックグループは、以下のように書き換える。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc’) {
// ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄはＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘから引き継がれる;
SpatialRelationship2DSourceBox(); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
SphericalRegionBox (); // オプション
ここで、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘ及びＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘは、トラックグループに関連するサブピクチャトラックの２Ｄ座標系及びそれらの位置及びサイズをそれぞれ記述する。ＳｐｈｅｒｉｃａｌＲｅｇｉｏｎＢｏｘは以下のように定義される新しいボックスである（４文字コードは単なる一例であり、任意の４文字コードは、それが球領域の表示のために確保されている場合、使用されてよい）。
aligned(8) class SphericalRegionBox extends FullBox('sspr', 0, 0) {
SphereRegionStruct(1);
｝
ここで、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔは、方位角（垂直）及び仰角（水平）次元についての範囲を有する三重項（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｅｒ＿ｅｌｅｖａｔｉｏｎ、ｃｅｎｔｅｒ＿ｐｉｔｃｈ）又は（ヨー、ピッチ、ロール）として球領域を指定する。

図７は、本発明の実施形態によるサブピクチャカプセル化を示す。それは、オプションのステップ２６０、２８０、２８５を有する、図１のステップ２５０に対応する。ステップ７０１において、ユーザはカプセル化モジュール（例えば、図１のステップ１５０を担当するＩＳＯＢＭＦＦライタ又はｍｐ４パッケージャ又はライタ）を構成する。これは、カプセル化ソフトウェアを制御するグラフィカル・ユーザー・インターフェースを介して実行され得る。これは、カプセル化するためのソースの指定情報又はサブピクチャトラックへの分解、例えば１つの単一のメディアファイル又は多くのセグメントファイルの生成のようなカプセル化のためのパラメータからなる。あるいは、これはシーンをキャプチャする記録装置（カメラ、ネットワークカメラ、スマートフォン等）に設定として予め登録されてよい。

次に、カプセル化モジュールは、ステップ７０２において、参照ピクチャをキャプチャ画像として初期化する。これは、カプセル化モジュールを実行しているデバイスのＲＡＭに、キャプチャ画像のサイズを格納することからなる。次に、ステップ７０３で、カプセル化モジュールは、カプセル化構成が投影ステップを含むかどうかをチェックする。偽の場合、次のステップは７０６である。例えば、キャプチャコンテンツが３６０°コンテンツである場合、それは、投影ピクチャと呼ばれる２Ｄ画像上に投影され得る。投影が使用されている場合（テスト７０３ 真）、次にカプセル化モジュールは、メディアファイル（又はメディアセグメント）の記述メタデータで使用されている投影の記述を挿入する（ステップ７０４）。これは、例えば、ＯＭＡＦ仕様による投影全方向ビデオボックス‘ｐｏｖｄ’になり得る。次に（ステップ７０５）、参照ピクチャが投影ピクチャに設定される。これは例えば、この投影ピクチャのサイズがメモリに記憶されることを意味する。ステップ７０６は、キャプチャソースが立体視であるかどうか、及びビューが単一のフレームにパックされるかどうかをチェックすることからなる。テスト７０６が真である場合、カプセル化モジュールは、立体視コンテンツのための記述子をメディアファイルに挿入する（ステップ７０７）。ＯＭＡＦ又はＩＳＯＢＭＦＦの場合、それはＳｔｅｒｅｏＶｉｄｅｏＢｏｘである。テスト７０６が偽である場合、次のステップは７０９である。

ステップ７０７に続いて、フレームパック化ピクチャは、参照ピクチャにおいてメモリに記憶される。テスト７０９は、カプセル化構成が投影及びオプションでフレームパック化ピクチャがさらにパック領域に再配置される必要があることを示すかどうかをチェックすることからなる。テスト７０９が真である場合、カプセル化モジュールは、このパックの記述を領域（図１のオプションのステップ２６０に相当する）に挿入する（ステップ７１０）。ＯＭＡＦの場合、それは、‘ｒｗｐｋ’ボックスタイプによって識別されるＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘとなることができる。次に、７１１において、参照ピクチャがパック化ピクチャに設定される。テスト７０９が偽である場合、次のステップは７１２である。ステップ７１２におけるテストは、カプセル化構成、すなわち、サブピクチャトラックのための黙示的な信号又は明示的な信号が、ユーザ又はアプリケーションによって選択又は設定されるかどうかをチェックすることからなる。黙示的な信号がオフである場合、次にステップ７１３で、カプセル化モジュールはどの参照ピクチャがサブピクチャトラック生成に使用されるか（すなわち、それぞれサブピクチャトラックにカプセル化された空間部に分割されたピクチャ）を提供する記述メタデータを挿入する。

黙示的な信号がオンである場合、次のステップは７１４である。ステップ７１４において、カプセル化モジュールは、分割ピクチャの異なる空間部分の中で空間関係を記述するトラックグループを挿入する。特に、サブピクチャトラックの生じる合成のサイズは、メモリ（７０２、７０５、７０８、又は７１１において）に格納された参照ピクチャのサイズに設定される。たとえば、これはＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘのｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔパラメータであってよい。最後に、ステップ７１５で、カプセル化モジュールは、参照ピクチャ内の位置及びサイズに関して各サブピクチャトラックを記述する。これは例えば、これらのパラメータが静的又は空間関係記述のためのサンプルグループ記述ボックス（例えば、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＧｒｏｕｐＥｎｔｒｙボックス）である場合、ＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのパラメータの中に分割から生じる値を入れるためのＯＭＡＦ又はＩＳＯＢＭＦＦからなる。ステップ７１３の明示的信号は、図８に示される通り解析プロセスの説明と共に説明される通り、様々な方法で実行され得る。

いくつかの実施形態では、複数の符号化トラック及び関連付けられた記述メタデータを含むメディアファイルから少なくとも１つの画像を生成する方法であって、前記複数の符号化トラックが、シーンのワイドビューの投影ピクチャをパッキングすることによって得られるパック化ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを有することを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析することを有し、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラックに符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの投影ピクチャとの間の空間関係を示す各トラックに関連付けられた情報項目を解釈することを含む、ことを特徴とする方法。

いくつかの実施形態では、複数の符号化トラック及び関連付けられた記述メタデータを含むメディアファイルから少なくとも１つの画像を生成する方法であって、前記複数の符号化トラックが、シーンのワイドビューの投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化するトラックのグループを含むことを判定することと、前記トラックのグループに関連付けられた記述メタデータを解析することを有し、前記トラックのグループに関連付けられた記述メタデータを解析することは、前記トラックにおいて符号化された前記少なくとも１つのサブピクチャと前記少なくとも１つの参照ピクチャとの間の空間関係を示す、各トラックに関連付けられた第１の情報項目を解釈することと、参照ピクチャを示す第２の情報項目を解釈することを含む、ことを特徴とする方法。

メディアプレーヤは、ＩＳＯＢＭＦＦパーサを使用して、８０１でＯＭＡＦファイルを受信する。それは、メディアファイルに存在する異なるトラック及び、特にビデオトラックを識別する。それらのビデオトラックについて、パーサはこれらが、２Ｄピクチャ上に投影された全方向性メディアのための古典的な２Ｄビデオ又はビデオトラックであるかどうかをチェックする。これは、ステップ８０２の‘ｆｔｙｐ’ボックス内の主要ブランド又は互換ブランドのリストを見ることによって判定される。例えば、‘ｏｖｄｐ’へのブランドセットは、メディアファイルがＯＭＡＦビューポート依存ベースラインプレゼンテーションプロファイルのための技術を使用するＶＲ体験を含むことを示す。本発明は、一実施形態において、ＯＭＡＦビューポート依存プロファイルによるＶＲ体験がサブピクチャトラックをさらに使用することを示す明示的なブランド（主要ブランド値として、又は互換ブランドのリストに入れられること）を定義することを提案する。ブランド（主要ブランド又は互換ブランド）について、少なくとも２つの特定の値が定義され得る。

第１の値は、全方向依存プロファイルに対して、例えば‘ｏｄｐｒ’と名付けられて定義されてもよい。この値は、全方向性メディアが投影画像を参照するサブピクチャトラックに分割されることを示す。このブランドに準拠する任意のＩＳＯＢＭＦＦパーサ又はＯＭＡＦプレーヤは、サブピクチャトラックの位置を投影ピクチャ内の位置として解釈するものとする。なお、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、それぞれ投影画像の幅及び高さとして解釈されるものとする。第２の値は、全方向依存プロファイルに対して、例えば‘ｏｄｐａ’と名付けられて定義されてもよい。この値は、全方向性メディアがパック化ピクチャを参照するサブピクチャトラックに分割されることを示す。このブランドに準拠する任意のＩＳＯＢＭＦＦパーサ又はＯＭＡＦプレーヤは、サブピクチャトラックの位置をパック化ピクチャ内の位置として解釈するものとする。なお、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、それぞれパック化ピクチャの幅及び高さとして解釈されるものとする。

このブランドの１つが存在する場合、ＯＭＡＦプレーヤ又はメディアプレーヤは、直ぐに参照ピクチャ情報を取得するための方法を識別する。次に、それは、参照ピクチャの指示を含む空間関係記述について明示的トラックグループを解析する。これはステップ８０３で行われる。これらのブランドのいずれも‘ｆｔｙｐ’ボックスに存在しない場合、メディアファイルパーサ又はメディアプレーヤはサブピクチャトラックの存在、及びそれらが投影ピクチャ又はパック化ピクチャを参照するかどうかを判定するために、メディアファイルをさらに解析しなければならない（テスト８０２のオブジェクト）。本発明の実施形態によれば、空間関係を記述するトラックグループが明示的なトラックグループである場合、パーサは、８０３において、これらの明示的なトラックグループを解析する。ステップ８０４で、それは所定のトラックグループ（例えば、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄを介して識別される）内のサブピクチャトラックを記述するために使用される参照ピクチャを判定する。

これは、選択のためにサブピクチャトラックをユーザに提示するとき、又はサブピクチャトラックをレンダリングするときに考慮されなければならない。参照ピクチャで表現されたサブピクチャトラックからキャプチャピクチャへの画像を生成するために、追加の変換が必要とされてよい。例えば、参照ピクチャがパック化ピクチャである場合、投影ピクチャで表現するために、サブピクチャトラックの位置とサイズは、アンパックされなければならない。この処理はステップ８１２の対象である。ここで、我々はステップ８０３においてパーサによって使用されるよう、カプセル化ステップ７１３の間に明示的信号がどのように実行されるかを説明する。新しいブランドの別の実施形態では、それはトラック又はトラックグループレベルで明示的な信号を追加するように提案される。これは、ＩＳＯＢＭＦＦにおける２Ｄ空間関係記述のための‘２ｄｃｃ’トラックグループを使用して行われてよい。この追加の信号は、特にそれらが投影ピクチャ又はパック化ピクチャのための位置及びサイズを表すかどうかを判定するために、パーサ又はプレーヤがサブピクチャトラックを処理するのに役立つことができる。

そのような信号の一実施形態は、空間関係記述のための特定のトラックグループタイプボックス内に新しいパラメータを定義することであってもよい。好ましくは、それは、パーサが情報を得ることができるように、トラックグループボックスの必須部分、すなわち、空間関係記述のためのＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘにおいて定義される。この実施形態の一例は、以下であってよい。
aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc')
｛
// track＿ｇｒｏｕｐ＿ｉｄ はＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ から引き継がれる;
SpatialRelationship2DSourceBox(); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
｝
aligned(8) class SpatialRelationship2DSourceBox extends
FullBox(‘2dsr', 0, 0)
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int(1) reference_picture;
unsigned int(31) reserved
｝

ここで、「ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅ」は、値「０」を取ることが、このグループ内のサブピクチャトラックのための位置が投影ピクチャ座標系で表現されることを示す場合の新しいパラメータである。値「１」を取るときに、それはこのグループ内のサブピクチャトラックがパック化ピクチャで表現されることを示す。このパラメータに付与された名前は一例である。なお、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、それぞれ投影ピクチャの幅及び高さを示す。投影又はパック化ピクチャとの間の参照ピクチャの選択を単にサポートするよりも汎用であるために、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅは、キャプチャとエンコードとの間の参照として使用するための中間ピクチャに対応する値、いくつかの値をとることができる。例えば、値０は投影が存在しない場合にキャプチャされた画像のために使用されてよく（ステップ７０２）、値１は投影のみ、フレームパック化ピクチャのための値２（ステップ７０８）及びパックフレームのための値３（７１１）が存在する場合に使用されてよい（ステップ７０５）。この指示は、投影及びパックされたフレームのみをサポートする先の実施形態と比較して、２ビットを必要とする。

より明示的な信号である別の実施形態は、（整数値の代わりに）参照ピクチャを記述するための４ｃｃコードを提供することからなる。これは、記述（サブピクチャトラックあたり４バイト）に関して、よりコストがかかる。例えば、参照ピクチャが投影ピクチャであることを示すために、参照ピクチャ値を‘ｐｏｖｄ’に設定され得る。パック化ピクチャについて、それは‘ｒｗｐｋ’に設定されてよく、フレームパック化ピクチャについて、それは‘ｓｔｖｉ’になり得る。キャプチャ画像について、既定の場合は、キャプチャ画像を意味する「ｄｅｆａｕｌｔ」のために割当てられた４文字コード‘ｄｆｌｔ’に設定され得る。好ましくは、中間画像と整数コードとの間のマップは定義され、例えば、参照画像値のための相互運用可能なコードを有するよう、ｍｐ４登録権限により登録される。代替として、追加のｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅパラメータは、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘのオプションの部分、すなわちＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘにおいて宣言されてもよい。ステップ７１２において、それは明示的な信号が判定されるとき、必須部分にそれを有することが好ましい。これは、パーサ又はプレーヤがその情報を見つけることができることを確認することである。

別の代替実施形態では、空間関係記述のための特定のトラックグループタイプボックス内の追加の信号は、ＩＳＯＢＭＦＦ又はＯＭＡＦ内の空間関係記述のより古いバージョンを有する下位互換性を保存する方法で定義される。そのために、例えば、ｖｅｒｓｉｏｎ ＝ １又は同じｖｅｒｓｉｏｎ ＝ ０だが、フラグ値を有する、ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘの新しいバージョンが定義される。なお、従来技術におけるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、フラグ値を許容しないことを留意されるべきである。ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘにフラグ値を提供することは、本発明のこの実施形態の一部である。例えば、値０ｘ０１に設定されたフラグ値「ｒｅｆｅｒｅｎｃｅ＿ｉｎｆｏ＿ｉｓ＿ｐｒｅｓｅｎｔ」は、このトラックグループが空間関係情報の位置及びサイズについて考慮するために、参照画像上の情報を含むことを示すよう定義されてもよい。次に、２ｄｃｃトラックグループは、以下のように表され得る。

aligned(8) class SpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘2dcc', 0, flags)
｛
// ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ はＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ から引き継がれる
SpatialRelationship2DSourceBox(flags); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
｝
aligned(8) class SpatialRelationship2DSourceBox extends
FullBox('2dsr', 0, flags) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
if ( (flags & 0x01) == 1) {
unsigned int(1) reference_picture;
unsigned int(31) reserved
｝
｝
ここで、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃｔｕｒｅは、値「０」を取る場合、このグループ内のサブピクチャトラックのための位置が投影ピクチャ座標系で表されることを示す、新しいパラメータである。例として、パラメータの名前が付与される。なお、ｔｏｔａｌ＿ｗｉｄｔｈ及びｔｏｔａｌ＿ｈｅｉｇｈｔは、それぞれ投影画像の幅及び高さを示す。

フラグを使用することは、例えば２Ｄクラシックビデオに対して、参照ピクチャに曖昧性がない場合、各サブピクチャトラックの記述コストを低減する。参照ピクチャの有無を示すためにフラグを使用することは、２ｄｃｃトラックグループタイプの再使用が、全方向コンテンツをサブピクチャトラックに分割する両方の場合、すなわち、領域的パックステップを有するか又は有することなしに、処理することを可能にする。さらに別の実施形態では、ＴｒａｃｋＧｒｏｕｐｉｎｇＴｙｐｅＢｏｘの、又はＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＤｅｓｃｒｉｐｔｉｏｎＢｏｘのようなそれの引継ぎボックスのうちの１つのフラグパラメータは、参照ピクチャをフラグ値に直接提供するよう使用される。例えば、フラグパラメータが０に設定された最下位ビットを有するとき、これは参照ピクチャが全方向ビデオの場合、投影ピクチャであることを意味する。フラグパラメータが１に設定された最下位ビットを有するとき、それは参照ピクチャが全方向ビデオの場合、パック化ピクチャであることを意味する。既定値は、０に設定されたフラグ パラメータの最下位ビットである。この実施形態で、ファイル記述をよりコンパクトにする（サブピクチャトラックあたり４バイト節約）、ＳｐａｔｉａｌＲｅｌａｔｉｏｎｓｈｉｐ２ＤＳｏｕｒｃｅＢｏｘ内に追加のパラメータはない。

代替実施形態では、黙示的又は明示的サブピクチャトラック信号との間の区別が、２つの異なるトラックグループ化タイプの使用によって行われる。現在のグループ化タイプは、黙示的な信号のために使用され、新しいトラックグループ化タイプは明示的な空間関係トラックグループのために定義される。例えば、４つの文字コード‘ｅｄｃｃ’が使用され、新しいＴｒａｃｋＧｒｏｕｐｉｎｇＴｙｐｅＢｏｘが以下のように作成される。
aligned(8) class ExplicitSpatialRelationship2DDescriptionBox extends TrackGroupTypeBox(‘edcc', 0, flags)
｛
// ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ はＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘから引き継がれる;
ExplicitSpatialRelationship2DSourceBox(flags); // 必須、最初でなければならない
SubPictureRegionBox (); // オプション
aligned(8) class ExplicitSpatialRelationship2DSourceBox extends
FullBox(‘edsr', 0, flags) {
unsigned int(32) total_width;
unsigned int(32) total_height;
unsigned int(32) source_id;
unsigned int(8) reference_picture;
｝

カプセル化構成が、「黙示的」であると判定された場合（テスト８０１及び８０２ 偽）、特定の信号が使用されないことを意味し、パーサが参照ピクチャの黙示的な判定に入る。それは、変換又はデコード後の操作が実行され、潜在的に参照画像が提供されなければならない、制限情報ボックス‘ｒｉｎｆ’で宣言された方式を解析することにより構成する。ＯＭＡＦに対するほとんどの時間で、それはパック化ピクチャか、又は投影ピクチャであってよい。立体視コンテンツについて、それはフレームパック化ピクチャであってもよい。次に、パーサは、候補参照ピクチャを判定するためにＯＭＡＦ記述子の存在をチェックする。パーサは、メディアファイル内に領域的パック指示がない場合、空間関係記述のための位置及びサイズパラメータが投影画像に関して表現されると仮定する（テスト８１０ 偽）。領域的パックボックスが存在する場合、空間関係記述のための位置及びサイズパラメータは、パック化ピクチャに関して表現される（ステップ８１１）。オプションで、パーサは、空間関係を記述するトラックグループのサブピクチャトラック内のｓｔｖｉボックスの存在についてテストすることによって、フレームパック化ピクチャの有無を検討することができる（ステップ８０８）。存在する場合、パーサは、フレームパック化ピクチャを候補参照ピクチャとして記録する。より一般的に黙示的な信号について、サブピクチャトラックの位置及びサイズはキャプチャ１１０とエンコード１４０との間の異なる処理ステップから生じる最後のピクチャにおいて表現されると考えられる。

これらの異なる処理は、制限スキーム情報ボックス‘ｒｉｎｆ’に反映される。例えば、コンテンツ準備が投影１２０、フレームパック１２５、及び領域的パック１３０を含む場合、ＲｅｓｔｒｉｃｔｅｄＳｃｈｅｍｅＩｎｆｏＢｏｘ‘ｒｉｎｆ’ボックスは、それのＳｃｈｅｍｅＴｙｐｅＢｏｘ内に、投影が適用されたことを示す‘ｐｏｖｄ’ボックスを含む。この‘ｐｏｖｄ’ボックスは、それ自体、例えばＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘ‘ｒｗｐｋ’として、１３０で行われる領域的パックを記述する構造を含むことができる。なお、ステレオビデオボックスはステップ１２５で使用されるフレームパックを示すために、例えば、ＣｏｍｐａｔｉｂｌｅＳｃｈｅｍｅＴｙｐｅＢｏｘに存在する。最適化黙示モードについて及びクローズドシステムにおいては、カプセル化とパーサは構成情報を交換することができ、サブピクチャトラック記述のために、予め定義されたデフォルトモードを宣言するための設定を定義することができる。例えば、それらは、メディアが全方向性コンテンツを含む場合、サブピクチャトラックが常に投影画像を参照することを同意することができる。

本願発明の一実施形態によれば、図９は、システム９９１ ９９５がエンコーダ９５０又はデコーダ９００及び通信ネットワーク９９９の少なくとも１つを有することを示す。一実施形態によれば、システム９９５は例えば、デコーダ９００を含むユーザ端末のユーザインターフェース又はデコーダ９００と通信可能なユーザ端末を介して、デコーダ９００にアクセスを有するユーザにコンテンツ（例えば、ビデオ／オーディオコンテンツを表示／出力又はストリーミングするためのビデオ及びオーディオコンテンツ）を処理し、提供するためのものである。このようなユーザ端末は、コンピュータ、携帯電話、タブレット、又は（提供／ストリーミングされた）コンテンツをユーザに提供／表示することができる任意の他のタイプの装置であってもよい。システム９９５は、通信ネットワーク９９９を介して（連続ストリーム又は単一のフォーマットで例えば、先のビデオ／オーディオが表示／出力されている間に）ビットストリーム９０１を取得／受信する。一実施形態によれば、システム９９１はコンテンツを処理し、処理されたコンテンツ、例えば、後の時間で表示／出力／ストリーミングするために処理されたビデオ及びオーディオコンテンツを記憶するためのものである。システム９９１は例えば、エンコーダ９５０によって受信され、処理される、本発明の実施形態におけるワイドビューシーンに対応する画像９５１のオリジナルシーケンスを含むコンテンツを取得／受信し、エンコーダ９５０は通信ネットワーク９９１を介してデコーダ９００に通信されるビットストリーム９０１を生成する。

次に、ビットストリーム９０１はいくつかの方法でデコーダ９００に通信され、例えば、データが記憶装置からデコーダ９００に通信／ストリーミングされる時点で、それはエンコーダ９５０によって事前に生成されてよく、ユーザが記憶装置からコンテンツ（すなわち、ビットストリームデータ）を要求するまで、通信ネットワーク９９９内の記憶装置（例えば、サーバ又はクラウドストレージ上）にデータとして記憶装置に記憶される。また、システム９９１はユーザに（例えば、ユーザ端末上に表示されるユーザインターフェースのためのデータを通信することによって）、記憶装置に記憶されたコンテンツのコンテンツ情報（例えば、コンテンツのタイトルや、コンテンツを識別、選択、要求するための他のメタ／記憶位置データ）を提供／ストリーミングし、要求されたコンテンツが記憶装置からユーザ端末に配信／ストリーミングされ得るように、コンテンツに対するユーザ要求を受信して処理するためのコンテンツ提供装置を備えてもよい。好ましくは、本発明の実施形態ではユーザ端末はヘッドマウントディスプレイである。あるいは、エンコーダ９５０は、ユーザがコンテンツを要求するときに、ビットストリーム９０１を生成し、それをデコーダ９００に直接通信／ストリーミングする。次に、デコーダ９００は、ビットストリーム９０１（又は信号）を受信し、次に要求されたコンテンツをユーザに提供するためのユーザ端末により使用される、ビデオ信号９０９及び／又はオーディオ信号を取得／生成するために、本発明によるサブピクチャトラックのデコードを実行する。

図３は、本発明の１つ以上の実施形態を実施するためのコンピューティングデバイス３００の概略ブロック図である。コンピューティングデバイス３００は、例えばマイクロコンピュータ、ワークステーション、又はライトポータブルデバイスなどのデバイスであってよい。コンピューティングデバイス３００は、以下に接続されよう通信バスを備える。マイクロプロセッサのような中央演算処理装置（ＣＰＵ）３０１と、本発明の実施形態の方法を実行可能なコードを記憶するためのランダムアクセスメモリ（ＲＡＭ）３０２、及び所定のファイル・フォーマットでマニフェストの読取り及び書込みのため及び又はビデオを符号化するため及び／又はデータを読み出し又は生成するための方法を実施するために必要な変数及びパラメータを記録するように適合されたレジスタと、それのメモリ容量は例えば拡張ポートに接続されたオプションのＲＡＭにより拡張され得る、すなわち、本発明の実施形態を実現するためのコンピュータプログラムを記憶するための読み出し専用メモリ３０３（ＲＯＭ）と、ネットワークインターフェース３０４は、すなわち順次、処理されるデジタルデータが送信され又は受信されるコミュニケーションネットワークを介して通常接続される。

ネットワークインターフェース３０４は、単一のネットワークインターフェースであってもよく、又は異なるネットワークインターフェースのセット（例えば、有線及び無線インターフェース、又は異なる種類の有線又は無線インターフェース）で構成されてもよい。データは、送信のためにネットワークインターフェースに書き込まれるか、又はＣＰＵ３０１内で実行するソフトウェアアプリケーションの制御の下で受信のためにネットワークインターフェースから読み出される。ユーザからの入力を受け取るため、又はユーザに情報を表示するためのユーザインターフェース（ＵＩ）３０５。ハードディスク（ＨＤ）３０６。例えば、ビデオソース又はディスプレイのような外部装置から／まで、データを受信／送信するためのＩ／Ｏモジュール３０７。実行可能コードは、読み出し専用メモリ３０３、ハードディスク３０６、又は例えばディスクのようなリムーバブルデジタル媒体のいずれかに格納されてよい。変形例によれば、プログラムの実行可能コードは、実行される前にハードディスク３０６等の通信装置３００の記憶手段の１つに記憶されるように、ネットワークインターフェース３０４を介して、通信ネットワークの手段によって受信され得る。

中央演算処理装置３０１は、本発明の実施形態によるプログラムの命令又はソフトウェアコードの一部又はプログラムの実行を制御及び指向するように適合され、命令は前述の記憶手段のうちの１つに記憶される。電源オン後、ＣＰＵ３０１は例えば、それらの命令がプログラムＲＯＭ３０３又はハードディスク（ＨＤ）３０６からロードされた後に、ソフトウェアアプリケーションに関するメインＲＡＭメモリ３０２からの命令を実行することができる。このようなソフトウェアアプリケーションは、ＣＰＵ３０１によって実行されると、前の図に示されたフローチャートのステップが実行されるようにする。この実施形態では、装置は本発明を実施するためにソフトウェアを使用するプログラマブル装置である。しかしながら、代替的に、本発明はハードウェア（例えば、特定用途向け集積回路又はＡＳＩＣの形態で）で実施されてもよい。上述の通り、本発明は特定の実施形態を参照して説明されたが、本発明は特定の実施形態に限定されるものではなく、及び変形例は本発明の範囲内にある技術における当業者にとって明らかである。

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

多くのさらなる変更及び変形例は、単に例示的な方法で与えられ、本発明の範囲を限定することは意図されておらず、範囲は専ら添付の特許請求の範囲によって判定される、前述の例示的な実施形態を参照することにより、当業者に示唆されるであろう。特に、様々な実施形態からの異なる特徴は、必要に応じて入れ替えられてよい。

Claims (9)

1. ＩＳＯＢＭＦＦと互換性があるファイルフォーマットにおける符号化メディアデータをカプセル化する方法であって、
   前記符号化メディアデータはシーンのワイドビューに対応し、前記ワイドビューは球面の少なくとも一部に前記シーンの画像を投影したものであり、
   前記方法は、
   前記シーンの前記ワイドビューを平面上に投影した投影ピクチャを得ることと、
   前記投影ピクチャを複数のサブピクチャに分割することと、
   少なくとも１つのサブピクチャを符号化したデータを複数のトラックに格納することと、
   前記複数のトラックが属するトラックグループに関連付けられた記述メタデータを生成することと、
   を有し、
   前記記述メタデータは、
   符号化された前記少なくとも１つのサブピクチャと前記複数のトラックのサブピクチャを合成した合成ピクチャとの間の空間関係を示す各トラックに関連付けられた第１の情報と、
   前記合成ピクチャが領域的パックされているか否かを４文字コードによって示す第２の情報と、
   を有する、
   ことを特徴とする方法。
2. 前記領域的パックは、前記投影ピクチャをマッピングするために適用される、
   ことを特徴とする請求項１に記載の方法。
3. ＩＳＯＢＭＦＦと互換性があるファイルフォーマットにおける符号化メディアデータを処理する方法であって、
   前記符号化メディアデータはシーンのワイドビューに対応し、前記ワイドビューは球面の少なくとも一部に前記シーンの画像を投影したものであり、
   前記方法は、
   前記シーンの前記ワイドビューを平面上に投影した投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化したデータが格納された複数のトラックが属するトラックグループを識別することと、
   前記トラックグループに関連付けられた記述メタデータを識別することと、を有し、
   記述メタデータは、
   符号化された前記少なくとも１つのサブピクチャと前記複数のトラックのサブピクチャを合成した合成ピクチャとの間の空間関係を示す各トラックに関連付けられた第１の情報と、
   前記合成ピクチャが領域的パックされているか否かを４文字コードによって示す第２の情報と、
   を有する、
   ことを特徴とする方法。
4. 前記領域的パックは、前記投影ピクチャをマッピングするために適用される、
   ことを特徴とする請求項３に記載の方法。
5. ＩＳＯＢＭＦＦと互換性があるファイルフォーマットにおける符号化メディアデータをカプセル化するデバイスであって、
   前記符号化メディアデータはシーンのワイドビューに対応し、前記ワイドビューは球面の少なくとも一部に前記シーンの画像を投影したものであり、
   前記デバイスは、
   前記シーンの前記ワイドビューを平面上に投影した投影ピクチャを取得する手段と、
   前記投影ピクチャを複数のサブピクチャに分割する手段と、
   少なくとも１つのサブピクチャを符号化したデータを複数のトラックに格納する手段と、
   前記複数のトラックが属するトラックグループに関連付けられた記述メタデータを生成する手段と、
   を有し、
   前記記述メタデータは、
   符号化された前記少なくとも１つのサブピクチャと前記複数のトラックのサブピクチャを合成した合成ピクチャとの間の空間関係を示す各トラックに関連付けられた第１の情報と、
   前記合成ピクチャが領域的パックされているか否かを４文字コードによって示す第２の情報と、
   を有する、
   ことを特徴とするデバイス。
6. ＩＳＯＢＭＦＦと互換性があるファイルフォーマットにおける符号化メディアデータを処理するデバイスであって、
   前記符号化メディアデータはシーンのワイドビューに対応し、前記ワイドビューは球面の少なくとも一部に前記シーンの画像を投影したものであり、
   前記デバイスは、
   前記シーンの前記ワイドビューを平面上に投影した投影ピクチャの分割から生じる少なくとも１つのサブピクチャを符号化したデータが格納された複数のトラックが属するトラックグループを識別する手段と、
   前記トラックグループに関連付けられた記述メタデータを識別する手段と、を有し、
   前記記述メタデータは、
   符号化された前記少なくとも１つのサブピクチャと前記複数のトラックのサブピクチャを合成した合成ピクチャとの間の空間関係を示す各トラックに関連付けられた第１の情報と、
   前記合成ピクチャが領域的パックされているか否かを４文字コードによって示す第２の情報と、
   を有する、
   ことを特徴とするデバイス。
7. 前記領域的パックは、前記投影ピクチャをマッピングするために適用されることを特徴とする、
   請求項５又は６に記載のデバイス。
8. コンピュータに、請求項１から４のいずれか一項に記載の方法を実行させるためのプログラム。
9. 請求項８に記載のプログラムを記憶したコンピュータで読み取り可能な記憶媒体。

Images