(57)【要約】  全方位ビデオに関連付けられた情報をシグナリングし、パーシングし、判定する方法が開示される。一実施形態では、「トラックグループ識別子」は、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューの両方のうちの１つのコンテンツを含むかどうかを示す。（請求項１、２及び段落［０００４］、［０００５］、［０００８］〜［００１３］を参照されたい。）別の実施形態では、別の識別子（ＳｕｂＰｉｃＣｏｍｐＩｄ又はＳｐａｔｉａｌＳｅｔＩｄ）が、アダプテーションセットがサブピクチャに対応することを識別し、そのアダプテーションセットは、２つ以上のサブピクチャコンポジションのグループに対応することができる。（請求項３、４及び段落［００７８］〜［００８０］を参照されたい。）
2021520711.tif 000002
【特許請求の範囲】
【請求項１】
全方位ビデオと関連付けられた情報をシグナリングする方法であって、前記方法は、
トラックグループ識別子をシグナリングする工程を含み、
前記トラックグループ識別子をシグナリングする工程は、前記トラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを示す値をシグナリングする工程を含む、方法。
【請求項２】
全方位ビデオに関連付けられた情報を判定する方法であって、
全方位ビデオに関連付けられたトラックグループ識別子をパースする工程と、
前記トラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを前記トラックグループ識別子の値に基づいて判定する工程と、を含む方法。
【請求項３】
全方位ビデオに関連付けられた情報をシグナリングする方法であって、前記方法は、
識別子をシグナリングする工程を含み、
前記識別子は、アダプテーションセットがサブピクチャに対応することを識別し、
前記アダプテーションセットは、２つ以上のサブピクチャコンポジショングループに対応することができる、方法。
【請求項４】
全方位ビデオに関連付けられた情報を判定する方法であって、
全方位ビデオに関連付けられた識別子をパースする工程と、
アダプテーションセットがサブピクチャに対応することを前記識別子が識別するかどうかを判定する工程と、を含み、
前記アダプテーションセットは、２つ以上のサブピクチャコンポジショングループに対応することができる、方法。
【請求項５】
請求項１〜４に記載の工程のいずれか及び全ての組み合わせを実行するように構成された１つ以上のプロセッサを備える、デバイス。
【請求項６】
請求項１〜４に記載の工程のいずれか及び全ての組み合わせを実行するための手段を備える、装置。
【請求項７】
非一時的コンピュータ可読記憶媒体であって、前記媒体上に記憶された命令を含み、前記命令は実行されると、デバイスの１つ以上のプロセッサに、請求項１〜４に記載の前記工程のいずれか及び全ての組み合わせを実行させる、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、対話型ビデオ配信の分野に関し、より具体的には、仮想現実アプリケーションにおいてサブピクチャコンポジション情報をシグナリングする技術に関する。
【背景技術】
【０００２】
デジタルメディア再生機能は、いわゆる「スマート」テレビを含むデジタルテレビ、セットトップボックス、ラップトップ又はデスクトップコンピュータ、タブレット型コンピュータ、デジタル記録デバイス、デジタルメディアプレイヤ、ビデオゲーミングデバイス、いわゆる「スマート」フォンを含む携帯電話、専用ビデオストリーミングデバイスなどを含む、広範囲のデバイスに組み込むことができる。デジタルメディアコンテンツ（例えば、ビデオ及びオーディオプログラム）は、例えば、無線テレビプロバイダ、衛星テレビプロバイダ、ケーブルテレビプロバイダ、いわゆるストリーミングサービスプロバイダを含むオンラインメディアサービスプロバイダなどの複数のソースから発信することができる。デジタルメディアコンテンツは、インターネットプロトコル（Internet Protocol、ＩＰ）ネットワークなどの双方向ネットワーク及びデジタル放送ネットワークなどの単方向ネットワークを含むパケット交換ネットワークで送信してもよい。
【０００３】
デジタルメディアコンテンツに含まれるデジタルビデオは、ビデオ符号化規格に従って符号化することができる。ビデオ符号化規格は、ビデオ圧縮技術を組み込むことができる。ビデオ符号化規格の例としては、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ及びＩＴＵ−Ｔ  Ｈ．２６４（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても公知である）並びにＨｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＨＥＶＣ）が挙げられる。ビデオ圧縮技術は、ビデオデータを記憶し送信するためのデータ要件を低減することを可能にする。ビデオ圧縮技術は、ビデオ系列における固有の冗長性を利用することにより、データ要件を低減することができる。ビデオ圧縮技術は、ビデオ系列を連続的により小さな部分（すなわち、ビデオ系列内のフレームの群、フレームの群内のフレーム、フレーム内のスライス、スライス内の符号化木ユニット（例えば、マクロブロック）、符号化木ユニット内の符号化ブロックなど）に再分割することができる。予測符号化技術を使用して、符号化されるビデオデータのユニットとビデオデータの参照ユニットとの間の差分値を生成することができる。差分値は、残差データと呼ばれることがある。残差データは、量子化された変換係数として符号化することができる。シンタックス要素は、残差データと参照符号化ユニットとを関連付けることができる。残差データ及びシンタックス要素は、準拠ビットストリームに含めることができる。準拠ビットストリーム及び関連メタデータは、データ構造に従ったフォーマットを有してもよい。準拠ビットストリーム及び関連メタデータは、送信規格に従って、ソースから受信デバイス（例えば、デジタルテレビ又はスマートフォン）に送信されてもよい。伝送規格の例としては、デジタルビデオブロードキャスティング（Digital Video Broadcasting、ＤＶＢ）規格、統合デジタル放送サービス規格（Integrated Services Digital Broadcasting、ＩＳＤＢ）規格、及び例えば、ＡＴＳＣ２．０規格を含む、高度テレビジョンシステムズ委員会（Advanced Television Systems Committee、ＡＴＳＣ）によって作成された規格が挙げられる。ＡＴＳＣは、現在、いわゆるＡＴＳＣ３．０の一連の規格を開発している。
【発明の概要】
【０００４】
一実施例では、全方位ビデオと関連付けられた情報をシグナリングする方法が、トラックグループ識別子をシグナリングする工程を含み、トラックグループ識別子をシグナリングする工程が、トラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを示す値をシグナリングする工程を含む。
【０００５】
一実施例では、全方位ビデオに関連付けられた情報を判定する方法が、全方位ビデオに関連付けられたトラックグループ識別子をパースする工程と、トラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかをトラックグループ識別子の値に基づいて判定する工程と、を含む。
【図面の簡単な説明】
【０００６】
【図１】本開示の１つ以上の技術による、符号化されたビデオデータを送信するように構成することができるシステムの一例を示すブロック図である。
【図２Ａ】本開示の１つ以上の技術による、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。
【図２Ｂ】本開示の１つ以上の技術による、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。
【図３】本開示の１つ以上の技術による、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。
【図４】本開示の１つ以上の技術による、座標系の一例を示す概念図である。
【図５Ａ】本開示の１つ以上の技術による、球面上の領域を指定する例を示す概念図である。
【図５Ｂ】本開示の１つ以上の技術による、球面上の領域を指定する例を示す概念図である。
【図６】本開示の１つ以上の技術による、投影されたピクチャ領域及びパッキングされたピクチャ領域の例を示す概念図である。
【図７】本開示の１つ以上の技術による、符号化されたビデオデータを送信するように構成することができるシステムの実装形態に含まれ得る構成要素の一例を示す概念図である。
【図８】本開示の１つ以上の技術を実装することができるデータカプセル化装置の一例を示すブロック図である。
【図９】本開示の１つ以上の技術を実装することができる受信デバイスの一例を示すブロック図である。
【図１０】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１１】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１２】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１３】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１４】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１５】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１６】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１７Ａ】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１７Ｂ】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１８】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【図１９】本開示の１つ以上の技術による、メタデータのシグナリングの一例を示すコンピュータプログラムリストである。
【発明を実施するための形態】
【０００７】
一般に、本開示は、仮想現実アプリケーションに関連付けられた情報をシグナリングするための種々の技術を説明する。具体的には、本開示は、サブピクチャ情報をシグナリングするための技術について説明する。いくつかの実施例では、本開示の技術は、伝送規格に関して説明されているが、本明細書において説明される技術は、一般に適用可能であり得ることに留意されたい。例えば、本明細書で説明する技術は、一般に、ＤＶＢ規格、ＩＳＤＢ規格、ＡＴＳＣ規格、Ｄｉｇｉｔａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ（ＤＴＭＢ）規格、Ｄｉｇｉｔａｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ（ＤＭＢ）規格、Ｈｙｂｒｉｄ  Ｂｒｏａｄｃａｓｔ  ａｎｄ  Ｂｒｏａｄｂａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ（ＨｂｂＴＶ）規格、ワールド・ワイド・ウェブ・コンソーシアム（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ、Ｗ３Ｃ）規格、及びユニバーサルプラグアンドプレイ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ、ＵＰｎＰ）規格のうちのいずれかに適用可能である。更に、本開示の技術は、ＩＴＵ−Ｔ  Ｈ．２６４及びＩＴＵ−Ｔ  Ｈ．２６５に関して説明されているが、本開示の技術は、全方位ビデオ符号化を含むビデオ符号化に一般に適用可能であることに留意されたい。例えば、本明細書で説明する符号化技術は、ＩＴＵ−Ｔ  Ｈ．２６５に含まれるもの以外のブロック構造、イントラ予測技術、インター予測技術、変換技術、フィルタリング技術、及び／又はエントロピ符号化技術を含むビデオ符号化システム（将来のビデオ符号化規格に基づくビデオ符号化システムを含む）に組み込むことができる。したがって、ＩＴＵ−Ｔ  Ｈ．２６４及びＩＴＵ−Ｔ  Ｈ．２６５への参照は、説明のためのものであり、本明細書で説明する技術の範囲を限定するように解釈すべきではない。更に、本明細書での文書の参照による組み込みは、本明細書で使用される用語に関して限定する又は曖昧さを生むように解釈されるべきではないことに留意されたい。例えば、組み込まれた参照が、別の組み込まれた参照とは、及び／又はその用語が本明細書で使用されるのとは異なる用語の定義を提供する場合では、その用語は、それぞれの対応する定義を幅広く含むように、及び／又は代わりに特定の定義のそれぞれを含むように解釈されるべきである。
【０００８】
一実施例では、デバイスは、トラックグループ識別子をシグナリングするように構成された１つ以上のプロセッサを備え、トラックグループ識別子をシグナリングすることは、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを示す値をシグナリングすることを含む。
【０００９】
一実施例では、非一時的コンピュータ可読記憶媒体は、その媒体上に記憶された命令を含み、その命令は実行されると、デバイスの１つ以上のプロセッサにトラックグループ識別子をシグナリングさせ、トラックグループ識別子をシグナリングすることは、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを示す値をシグナリングすることを含む。
【００１０】
一実施例では、装置は、トラックグループ識別子をシグナリングする手段を備え、トラックグループ識別子をシグナリングすることは、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかを示す値をシグナリングすることを含む。
【００１１】
一実施例では、デバイスは、全方位ビデオに関連付けられたトラックグループ識別子をパースし、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかをそのトラックグループ識別子の値に基づいて判定するように構成された１つ以上のプロセッサを備える。
【００１２】
一実施例では、非一時的コンピュータ可読記憶媒体は、その媒体上に記憶された命令を含み、その命令は実行されると、デバイスの１つ以上のプロセッサに、全方位ビデオに関連付けられたトラックグループ識別子をパースさせ、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかをそのトラックグループ識別子の値に基づいて判定させる。
【００１３】
一実施例では、装置は、全方位ビデオに関連付けられたトラックグループ識別子をパースするための手段と、そのトラックグループ識別子に対応する各サブピクチャトラックが、左ビューのみ、右ビューのみ、又は左ビュー及び右ビューのうちの１つのコンテンツを含むかどうかをそのトラックグループ識別子の値に基づいて判定する手段とを備える。
【００１４】
１つ以上の実施例の詳細は、添付の図面及び以下の明細書に記述されている。他の特徴、目的、及び利点は、明細書及び図面から、並びに特許請求の範囲から明白であろう。
【００１５】
ビデオコンテンツは、典型的には、一連のフレームからなるビデオシーケンスを含む。一連のフレームはまた、ピクチャ群（group of pictures、ＧＯＰ）と呼ばれることがある。各ビデオフレーム又はピクチャは１つ以上のスライスを含むことができ、スライスは複数のビデオブロックを含む。ビデオブロックは、予測的に符号化され得る画素値（サンプルとも呼ばれる）の最大アレイとして定義することができる。ビデオブロックは、走査パターン（例えば、ラスター走査）に従って順序付けすることができる。ビデオ符号化装置は、ビデオブロック及びその再分割に対して予測符号化を実行する。ＩＴＵ−Ｔ  Ｈ．２６４は、１６×１６のルマ（ｌｕｍａ）サンプルを含むマクロブロックを規定する。ＩＴＵ−Ｔ  Ｈ．２６５は、類似の符号化ツリーユニット（Coding Tree Unit、ＣＴＵ）構造を規定するが、ピクチャは、等しいサイズのＣＴＵに分割することができ、各ＣＴＵは、１６×１６、３２×３２、又は６４×６４のルマサンプルを有する符号化ツリーブロック（Coding Tree Block、ＣＴＢ）を含むことができる。本明細書で使用されるとき、ビデオブロックという用語は、一般に、ピクチャの領域を指すことがあり、又はより具体的には、予測的に符号化できる画素値の最大アレイ、その再分割、及び／又は対応する構造を指すことがある。更に、ＩＴＵ−Ｔ  Ｈ．２６５によれば、各ビデオフレーム又はピクチャは、１つ以上のタイルを含むように区画化されてもよく、タイルは、ピクチャの矩形領域に対応する符号化ツリーユニットのシーケンスである。
【００１６】
ＩＴＵ−Ｔ  Ｈ．２６５では、ＣＴＵのＣＴＢは、対応する四分木ブロック構造に従って符号化ブロック（ＣＢ）に区画化することができる。ＩＴＵ−Ｔ  Ｈ．２６５によれば、１つのルマＣＢは、２つの対応するクロマＣＢ及び関連するシンタックス要素と共に、符号化ユニット（ＣＵ）と呼ばれる。ＣＵは、ＣＵに対する１つ以上の予測部（prediction unit、ＰＵ）を定義する予測部（ＰＵ）構造に関連し、ＰＵは、対応する参照サンプルに関連する。すなわち、ＩＴＵ−Ｔ  Ｈ．２６５では、イントラ予測又はインター予測を使用してピクチャ領域を符号化する決定がＣＵレベルで行われ、ＣＵに関し、イントラ予測又はインター予測に対応する１つ以上の予測を使用して、ＣＵのＣＢに対する参照サンプルを生成することができる。ＩＴＵ−Ｔ  Ｈ．２６５では、ＰＵは、ルマ及びクロマ予測ブロック（prediction block、ＰＢ）を含むことができ、正方形ＰＢはイントラ予測に対してサポートされ、矩形ＰＢはインター予測に対してサポートされる。イントラ予測データ（例えば、イントラ予測モードシンタックス要素）又はインター予測データ（例えば、動きデータシンタックス要素）は、ＰＵを対応する参照サンプルに関連させることができる。残差データは、ビデオデータの各成分（例えば、ルマ（Ｙ）及びクロマ（Ｃｂ及びＣｒ））に対応する差分値のそれぞれのアレイを含むことができる。残差データは、画素領域内とすることができる。離散コサイン変換（discrete cosine transform、ＤＣＴ）、離散サイン変換（discrete sine transform、ＤＳＴ）、整数変換、ウェーブレット変換、又は概念的に類似の変換などの変換を、画素差分値に適用して、変換係数を生成することができる。ＩＴＵ−Ｔ  Ｈ．２６５では、ＣＵは、更に変換ユニット（ＴTransform Unit、ＴＵ）に再分割できることに留意されたい。すなわち、画素差分値のアレイは、変換係数を生成するために再分割することができ（例えば、４つの８×８変換を、１６×１６のルマＣＢに対応する残差値の１６×１６のアレイに適用することができる）、そのような再分割は、変換ブロック（Transform Block、ＴＢ）と呼ばれることがある。変換係数は、量子化パラメータ（quantization parameter、ＱＰ）に従って量子化され得る。量子化された変換係数（これはレベル値と呼ばれることがある）は、エントロピ符号化技術（例えば、コンテンツ適応可変長符号化（content adaptive variable length coding、ＣＡＶＬＣ）、コンテキスト適応２値算術符号化（context adaptive binary arithmetic coding、ＣＡＢＡＣ）、確率区間分割エントロピ符号化（probability interval partitioning entropy coding、ＰＩＰＥ）など）に従ってエントロピ符号化することができる。更に、予測モードを示すシンタックス要素などのシンタックス要素も、エントロピ符号化することができる。エントロピ符号化され量子化された変換係数及び対応するエントロピ符号化されたシンタックス要素は、ビデオデータを再生成するために使用することができる準拠ビットストリームを形成することができる。二値化プロセスを、エントロピ符号化プロセスの一部としてシンタックス要素に対して実行することができる。二値化は、シンタックス値を一連の１つ以上のビットに変換するプロセスを指す。これらのビットは、「ビン」と呼ばれることがあ��。
仮想現実（ＶＲ）アプリケーションは、ヘッドマウントディスプレイでレンダリングすることができるビデオコンテンツを含むことができ、ユーザの頭部の向きに対応する全天球映像の領域のみがレンダリングされる。ＶＲアプリケーションは、３６０度ビデオの３６０度全天球映像とも呼ばれる、全方位ビデオによって使用可能にすることができる。全方向ビデオは、典型的には、最大３６０度のシーンをカバーする複数のカメラによってキャプチャされる。通常のビデオと比較した全方位ビデオの明確な特徴は、典型的には、キャプチャされたビデオ領域全体のサブセットのみが表示される、すなわち、現在のユーザの視野（ＦＯＶ）に対応する領域が表示されることである。ＦＯＶはまた、時に、ビューポートとも呼ばれる。他の場合では、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部として説明することができる。ビューポートのサイズは、視野以下でもよいことに留意されたい。更に、全方向ビデオは、モノスコープカメラ又はステレオスコープカメラを使用してキャプチャされ得ることに留意されたい。モノスコープカメラは、オブジェクトの単一視野をキャプチャするカメラを含んでもよい。ステレオスコープカメラは、同じオブジェクトの複数のビューをキャプチャするカメラを含んでもよい（例えば、わずかに異なる角度で２つのレンズを使用してビューをキャプチャする）。更に、場合によっては、全方向ビデオアプリケーションで使用するための画像は、超広角レンズ（すなわち、いわゆる魚眼レンズ）を使用してキャプチャされ得ることに留意されたい。いずれの場合も、３６０度の球面ビデオを作成するためのプロセスは、一般に、入力画像をつなぎ合わせ、つなぎ合わされた入力画像を３次元構造（例えば、球体又は立方体）上にプロジェクションして、いわゆるプロジェクトフレームをもたらし得ることとして説明することができる。更に、場合によっては、プロジェクトフレームの領域は、変換され、リサイズされ、及び再配置されてもよく、これによっていわゆるパックフレームをもたらし得る。
【００１７】
伝送システムは、全方位ビデオを１つ以上の演算デバイスに送信するように構成することができる。演算デバイス及び／又は伝送システムは、１つ以上の抽象化層を含むモデルに基づいてもよく、各抽象化層のデータは、特定の構造、例えば、パケット構造、変調方式などに従って表される。定義された抽象化層を含むモデルの一例は、いわゆる開放型システム間相互接続（Open Systems Interconnection（ＯＳＩ））モデルである。ＯＳＩモデルは、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、及び物理層を含む、７層スタックモデルを定義する。スタックモデル内の層の記述に関して上位（upper）及び下位（lower）という用語を使用することは、最上層であるアプリケーション層及び最下層である物理層に基づいてもよいという点に留意すべきである。更に、場合によっては、用語「層１」又は「Ｌ１」を使用して、物理層を指すことができ、用語「層２」又は「Ｌ２」を使用して、リンク層を指すことができ、用語「層３」又は「Ｌ３」又は「ＩＰ層」を使用して、ネットワーク層を指すことができる。
【００１８】
物理層は、一般に、電気信号がデジタルデータを形成する層を指すことができる。例えば、物理層は、変調された無線周波数（radio frequency、ＲＦ）シンボルがデジタルデータのフレームをどのように形成するかを定義する層を指すことができる。リンク層と呼ばれることもあるデータリンク層は、送信側での物理層処理前及び受信側での物理層受信後に使用される抽象化を指すことができる。本明細書で使用するとき、リンク層は、送信側でネットワーク層から物理層にデータを伝送するために使用され、受信側で物理層からネットワーク層へデータを伝送するために使用される抽象化を指すことができる。送信側及び受信側は論理的な役割であり、単一のデバイスは、一方のインスタンスにおける送信側と他方のインスタンスにおける受信側の両方として動作できることに留意されたい。リンク層は、特定のパケットタイプ（例えば、ムービングピクチャエクスパーツグループ−トランスポートストリーム（Motion Picture Expert Group - Transport Stream、ＭＰＥＧ−ＴＳ）パケット、インターネットプロトコルバージョン４（ＩＰｖ４）パケットなど）にカプセル化された様々な種類のデータ（例えば、ビデオファイル、音声ファイル、又はアプリケーションファイル）を物理層による処理のための単一汎用フォーマットに抽象化することができる。ネットワーク層は、一般に、論理アドレッシングが発生する層を指すことができる。すなわち、ネットワーク層は、一般に、アドレッシング情報（例えば、インターネットプロトコル（ＩＰ）アドレス）を提供することができ、これにより、データパケットをネットワーク内の特定のノード（例えば、演算デバイス）に送達することができる。本発明で使用する場合、ネットワーク層という用語は、リンク層の上の層及び／又はリンク層処理のために受信することができるような構造のデータを有する層を指すことができる。トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層の各々は、ユーザアプリケーションによって使用するためにデータをどのように送達するかを定義することができる。
【００１９】
参照により本明細書に組み込まれ、本明細書ではＭＰＥＧ−Ｉと呼ばれる、ＩＳＯ／ＩＥＣ  ＦＤＩＳ  ２３０９０−１２：２０１ｘ（Ｅ）「Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  −  Ｃｏｄｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ  ｏｆ  Ｉｍｍｅｒｓｉｖｅ  Ｍｅｄｉａ  （ＭＰＥＧ−Ｉ）−Ｐａｒｔ  ２：Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｍｅｄｉａ  Ｆｏｒｍａｔ」、ＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１（２０１７年１２月１１日）は、全方向メディアアプリケーションを可能にするメディアアプリケーションフォーマットを定義している。ＭＰＥＧ−Ｉは、全方向ビデオ；球面ビデオシーケンス又は画像を二次元矩形ビデオシーケンス又は画像にそれぞれ変換するために使用できる投影法及び矩形領域別パッキング法；ＩＳＯベースメディアファイル形式（ISO Base Media File Format（ＩＳＯＢＭＦＦ））を使用した全方位メディア及びそれに関連するメタデータの記憶；メディアストリーミングシステムにおける全方位メディアのカプセル化、シグナリング、及びストリーミング；並びにメディアプロファイル及びプレゼンテーションプロファイルの座標系を指定する。簡潔にするために、本明細書では、ＭＰＥＧ−Ｉの完全な説明を提供しないことに留意されたい。しかしながら、ＭＰＥＧ−ｌの関連する部分を参照する。
【００２０】
ＭＰＥＧ−Ｉは、ビデオがＩＴＵ−Ｔ  Ｈ．２６５に従って符号化されているメディアプロファイル提供する。ＩＴＵ−Ｔ  Ｈ．２６５は、高効率ビデオ符号化（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ、ＨＥＶＣ），Ｒｅｃに記載されている。ＩＴＵ−Ｔ  Ｈ．２６５（２０１６年１２月）は、参照により本明細書に組み込まれ、本明細書ではＩＴＵ−Ｔ  Ｈ．２６５と呼ばれる。上述のように、ＩＴＵ−Ｔ  Ｈ．２６５によれば、各ビデオフレーム又はピクチャは、１つ以上のスライスを含むように区画化されてもよく、１つ以上のタイルを含むように更に区画化されてもよい。図２Ａ〜図２Ｂは、スライスを含み、ピクチャを更にタイルに区画化するピクチャ群の一例を示す概念図である。図２Ａに示す例では、Ｐｉｃ４は、２つのスライス（すなわち、Ｓｌｉｃｅ１及びＳｌｉｃｅ２）を含むものとして示されており、ここで各スライスは（例えばラスター走査順に）ＣＴＵのシーケンスを含む。図２Ｂに示す例では、Ｐｉｃ４は、６つのタイル（すなわち、Ｔｉｌｅ１〜Ｔｉｌｅ６）を含むものとして示されており、各タイルは矩形であり、ＣＴＵのシーケンスを含む。ＩＴＵ−Ｔ  Ｈ．２６５では、タイルは、２つ以上のスライスが包含する符号化ツリーユニットからなっていてもよく、スライスは、２つ以上のタイルが包含する符号化ツリーユニットからなっていてもよいことに留意されたい。しかしながら、ＩＴＵ−Ｔ  Ｈ．２６５は、以下の条件のうちの１つ又は両方が満たされなければならないと規定している。（１）あるスライス中の全ての符号化ツリーユニットは同じタイルに属する、及び（２）あるタイル内の全ての符号化ツリーユニットは同じスライスに属する。
【００２１】
３６０度の球面ビデオは、領域を含むことができる。図３に示す例を参照すると、３６０度の球面ビデオは、領域Ａ〜Ｃを含み、図３に示すように、タイル（すなわち、Ｔｉｌｅ１〜Ｔｉｌｅ６）が、全方位ビデオの一領域を形成することができる。図３に示す例では、各領域はＣＴＵを含むものとして示されている。上述のように、ＣＴＵは、符号化されたビデオデータのスライス及び／又はビデオデータのタイルを形成することができる。更に、上述のように、ビデオ符号化技術は、ビデオブロック、その再分割、及び／又は対応する構造に従って１つのピクチャの各領域を符号化することができ、ビデオ符号化技術は、ビデオ符号化パラメータがビデオ符号化構造の様々なレベルにおいて調整されることを可能にし、例えば、スライス、タイル、ビデオブロックについて、及び／又は再分割において調整されることを可能にすることに留意されたい。一実施例では、図３に示される３６０度のビデオは、スポーツイベントを表すことができ、領域Ａ及び領域Ｃが、スタジアムのスタンドのビューを含み、領域Ｂが、競技場のビューを含む（例えば、ビデオは、５０ヤードラインに配置された３６０度カメラによってキャプチャされる）。
【００２２】
上述のように、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部とすることができる。このように、全方位ビデオの各領域は、ユーザのビューポートに応じて選択的に配信されることができ、すなわち、ビューポート依存配信を全方位ビデオストリーミングにおいて可能にすることができる。典型的には、ビューポート依存配信を可能にするためには、ソースコンテンツが、符号化前にサブピクチャシーケンスに分割され、各サブピクチャシーケンスが、全方位ビデオコンテンツの空間領域のサブセットをカバーし、サブピクチャシーケンスは、次いで、単層ビットストリームとして互いに独立して符号化される。例えば、図３を参照すると、領域Ａ、領域Ｂ、及び領域Ｃ、又はこれらの領域の一部分はそれぞれ、独立して符号化されたサブピクチャビットストリームに対応し得る。各サブピクチャビットストリームは、それ自体のトラックとしてのファイルにカプセル化されることができ、トラックは、ビューポート情報に基づいて受信デバイスに選択的に配信され得る。場合によっては、サブピクチャが重なり合うことが可能であることに留意されたい。例えば、図３を参照すると、Ｔｉｌｅ１、Ｔｉｌｅ２、Ｔｉｌｅ４、及びＴｉｌｅ５が、１つのサブピクチャを形成してもよく、Ｔｉｌｅ２、Ｔｉｌｅ３、Ｔｉｌｅ５、及びＴｉｌｅ６が、１つのサブピクチャを形成してもよい。したがって、ある特定のサンプルが複数のサブピクチャに含まれることがある。ＭＰＥＧ−Ｉは、コンポジション整列されたサンプルが、トラック内に、別のトラックに関連付けられた１つのサンプルを含む場所を提供し、そのサンプルが、その別のトラック内のある特定のサンプルと同じコンポジション時間を有する、又は同じコンポジション時間を有するサンプルが別のトラックで利用できない場合には、その別のトラック内のある特定のサンプルのコンポジション時間に関して最も近い先行するコンポジション時間を提供する。
更に、ＭＰＥＧ−Ｉは、フレームパッキングが使用されていないとき又は時間インターリーブフレームパッキング構成が使用されている場合に、構成ピクチャが、１つのビューに対応する空間的にフレームパッキングされた立体視ピクチャの一部を含む場所又はピクチャ自体を含む場所を提供する。
【００２３】
上述のように、ＭＰＥＧ−Ｉは、全方位ビデオの座標系を指定する。ＭＰＥＧ−Ｉでは、座標系は、単位球面及び３つの座標軸、すなわちＸ（前後）軸、Ｙ（横方向、左右）軸、及びＺ（垂直、上方）軸からなり、３つの軸は球体の中心で交差する。球面上の点の位置は、球面座標方位（ｆ）及び高度（θ）の対によって特定される。図４は、ＭＰＥＧ−Ｉで指定されるような、球面座標方位（ｆ）及び高度（θ）のＸ、Ｙ、及びＺ座標軸に対する関係を示す。ＭＰＥＧ−Ｉでは、方位角の値の範囲は、−１８０．０度以上〜１８０．０度未満であり、高度の値の範囲は、−９０．０度以上〜９０．０度以下であることに留意されたい。ＭＰＥＧ−Ｉは、４つの大円によって指定することができる球面上の領域の場所を指定することができ、ここで、大円（リーマン円（Riemannian circle）とも呼ばれる）は、球体と球体の中心点を通過する平面との交点であり、球体の中心と大円の中心とは同じ位置にある。
ＭＰＥＧ−Ｉは、更に、２つの方位円及び２つの高度円によって指定することができる球面上の領域の場所を指定することができ、ここで、方位円は、同じ方位角値を有する全ての点を結ぶ球面上の円であり、高度円は、同じ高度値を有する全ての点を結ぶ球面上の円である。
【００２４】
上述のように、ＭＰＥＧ−Ｉは、国際標準化機構（ＩＳＯ）ベースメディアファイル形式（ＩＳＯＢＭＦＦ）を使用して、全方位メディア及びそれに関連するメタデータを記憶する方法を指定する。ＭＰＥＧ−Ｉは、メタデータをサポートするファイル形式が、プロジェクトフレームによってカバーされた球面の領域を指定する場所を指定する。具体的には、ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有する球面領域を指定する球面領域構造を含む。
定義
球面領域構造（ＳｐｈｅｒｅＲｅｏｎＳｔｒｕｃｔ）は、球面領域を指定する。
【００２５】
ｃｅｎｔｒｅ＿ｔｉｌｔが０に等しいとき、この構造によって指定される球面領域は、以下のように導出される。
−ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅの両方が０に等しい場合、この構造によって指定される球面領域は球面上の点である。
−そうでない場合、球面領域は、以下のように導出される変数ｃｅｎｔｒｅＡｚｉｍｕｔｈ、ｃｅｎｔｒｅＥｌｅｖａｔｉｏｎ、ｃＡｚｉｍｕｔｈ１、ｅＡｚｉｍｕｔｈ、ｃＥｌｅｖａｔｉｏｎ１、及びｃＥｌｅｖａｔｉｏｎ２を用いて定義される。
ｃｅｎｔｒｅＡｚｉｍｕｔｈ＝ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ÷６５５３６
ｃｅｎｔｒｅＥｌｅｖａｔｉｏｎ＝ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ÷６５５３６
ｃＡｚｉｍｕｔｈ１＝（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ−ａｚｉｍｕｔｈ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＡｚｉｍｕｔｈ２＝（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ＋ａｚｉｍｕｔｈ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＥｌｅｖａｔｉｏｎ１＝（ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ−ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＥｌｅｖａｔｉｏｎ２＝（ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ＋ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ÷２）÷６５５３６
球面領域は、このＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのインスタンスを含む構造のセマンティクスで指定された形状タイプ値を参照して以下のように定義される。
−形状タイプ値が０に等しいとき、球面領域は、４つの点ｃＡｚｉｍｕｔｈ１、ｃＡｚｉｍｕｔｈ２、ｃＥｌｅｖａｔｉｏｎ１、ｃＥｌｅｖａｔｉｏｎ２によって定義される４つの大円並びにｃｅｎｔｒｅＡｚｉｍｕｔｈ及びｃｅｎｔｒｅＥｌｅｖａｔｉｏｎによって定義される中心点によって、図５Ａに示されるように指定される。
−形状タイプ値が１に等しいとき、球面領域は、４つの点ｃＡｚｉｍｕｔｈ１、ｃＡｚｉｍｕｔｈ２、ｃＥｌｅｖａｔｉｏｎ１、ｃＥｌｅｖａｔｉｏｎ２によって定義される２つの方位円及び２つの高度円並びにｃｅｎｔｒｅＡｚｉｍｕｔｈ及びｃｅｎｔｒｅＥｌｅｖａｔｉｏｎによって定義される中心点によって、図５Ｂに示されるように指定される。
ｃｅｎｔｒｅ＿ｔｉｌｔが０に等しくないとき、球面領域は、最初に上記のように導出され、次いで、球面領域の中心点を通過する球体の原点から始まる軸に沿って傾斜回転が適用される。ここで、原点から軸の正端に向かって見たときに角度値は時計回りに増加する。最終的な球面領域は、傾斜回転を適用した後のものである。
【００２６】
０に等しい形状タイプ値は、球面領域が図５Ａに示されるように４つの大円によって指定されることを示す。
【００２７】
１に等しい形状タイプ値は、図５Ｂに示されるように、球面領域が２つの方位円及び２つの高度円によって指定されることを示す。
【００２８】
１より大きい形状タイプの値は予備とされる。
【００２９】
シンタックス
【表１】
2021520711.tif 000003
セマンティクス
ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ及びｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、球面領域の中心を指定するものである。ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈは、−１８０＊２１６〜１８０＊２１６−１（両端値を含む）の範囲とする。ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、−９０＊２１６〜９０＊２１６（両端値を含む）の範囲とする。
ｃｅｎｔｒｅ＿ｔｉｌｔは、球面領域の傾斜角度を指定するものである。ｃｅｎｔｒｅ＿ｔｉｌｔは、−１８０＊２１６〜１８０＊２１６−１（両端値を含む）の範囲とする。
ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在する場合は、この構造で指定された球面領域の方位角及び高度の範囲をそれぞれ２−１６度の単位で指定する。ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、図５Ａ又は図５Ｂに示すように、球面領域の中心点を通る範囲を指定する。このＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのインスタンスにおいて、ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在しない場合、ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのこのインスタンスを含む構造のセマンティクスで指定されたように推測される。ａｚｉｍｕｔｈ＿ｒａｎｇｅは、０〜３６０＊２１６（両端値を含む）の範囲とする。ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、０〜１８０＊２１６（両端値を含む）の範囲とする。
【００３０】
補間のセマンティクスは、このＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのインスタンスを含む構造のセマンティクスによって指定される。
【００３１】
本明細書で使用される式に関して、以下の算術演算子が使用され得ることに留意されたい。
＋  加算
−  減算（２つの引数演算子として）又はネゲーション（単項プレフィックス演算子として）
＊  行列乗算を含む乗算
ｘｙ  べき乗。ｘのｙ乗を指定する。他のコンテキストでは、そのような表記は、べき乗としての解釈を意図していないスーパースクリプトに使用される。
／  ゼロへの結果切り捨てを伴う整数除算。例えば、７／４及び−７／−４は、１に切り捨てられ、−７／４及び７／−４は、−１に切り捨てられる。
÷  切り捨て又は四捨五入が意図されていない式において除算を表すために使用される。
【数１】
2021520711.tif 000004
切り捨て又は四捨五入が意図されていない式において除算を表すために使用される。
ｘ％ｙ  率。ｘをｙで割った余り、ｘ＞＝０かつｙ＞０の整数ｘ及びｙに対してのみ定義される。
本明細書で使用される式に関して、以下の論理演算子が使用され得ることに留意されたい：
ｘ  ＆＆  ｙ  ｘとｙとのブール論理「積」
ｘ  ｜｜  ｙ  ｘとｙとのブール論理「和」
！ブール論理「否」
ｘ？ｙ：ｚ  ｘが真であるか又は０に等しくない場合はｙの値を評価し、そうでない場合はｚの値を評価する。
本明細書で使用される式に関して、以下の関係演算子が使用され得ることに留意されたい。
＞  大なり
＞＝  大なり又は等しい
＜  小なり
＜＝  小なり又は等しい
＝＝  等しい
！＝  等しくない
本明細書で使用されるシンタックスにおいて、ｕｎｓｉｇｎｅｄ  ｉｎｔ（ｎ）は、ｎビットを有する符号なし整数を指すことに留意されたい。更に、ｂｉｔ（ｎ）は、ｎビットを有するビット値を指す。
【００３２】
更に、ＭＰＥＧ−Ｉは、コンテンツのカバレッジが１つ以上の球面領域を含む場所を指定する。ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有するコンテンツカバレッジ構造を含む。
定義
この構造内のフィールドは、コンテンツカバレッジを提供し、コンテンツカバレッジは、グローバル座標軸を基準にして、コンテンツによってカバーされる１つ以上の球面領域によって表される。
【００３３】
シンタックス
【表２】
2021520711.tif 000005
セマンティクス
ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅは、コンテンツカバレッジを表す球面領域の形状を指定する。ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅは、サンプルエントリを説明する句で指定されたｓｈａｐｅ＿ｔｙｐｅと同じセマンティクスを有する（以下に提示する）。ｃｏｖｅｒａｇｅ＿ｓｈａｐｅ＿ｔｙｐｅの値は、Ｓｐｈｅｒｅ  Ｒｅｇｉｏｎ（上記に提示された）を記述する句をＣｏｎｔｅｎｔＣｏｖｅｒａｇｅＳｔｒｕｃｔのセマンティクスに適用するときに形状タイプ値として使用される。
ｎｕｍ＿ｒｅｇｉｏｎｓは、球面領域の数を指定する。値０は予備とされる。
０に等しいｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇは、ｖｉｅｗ＿ｉｄｃ［ｉ］が存在しないことを指定する。１に等しいｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇは、ｖｉｅｗ＿ｉｄｃ［ｉ］が存在することを指定し、球面領域と特定の（左、右、又は両方の）ビューとの関連を示す。
ｄｅｆａｕｌｔ＿ｖｉｅｗ＿ｉｄｃが、０の場合、各球面領域が平面視であることを示し、１の場合、各球面領域が立体視コンテンツの左ビューにあることを示し、２の場合、各球面領域が立体視コンテンツの右ビューにあることを示し、３の場合、各球面領域が左右両方のビューにあることを示す。
ｖｉｅｗ＿ｉｄｃ［ｉ］が、１の場合、ｉ番目の球面領域が立体視コンテンツの左ビューにあることを示し、２の場合、ｉ番目の球面領域が立体視コンテンツの右ビューにあることを示し、３の場合、ｉ番目の球面領域が左右両方のビューにあることを示す。ｖｉｅｗ＿ｉｄｃ［ｉ］＝０は、予備とされる。
注記：１に等しいｖｉｅｗ＿ｉｄｃ＿ｐｒｅｓｅｎｃｅ＿ｆｌａｇは、非対称な立体視カバレッジを示すことができる。例えば、非対称な立体視カバレッジの一例は、ｎｕｍ＿ｒｅｇｉｏｎｓが２に等しいことを設定して、一方の球面領域が−９０°〜９０°（両端値を含む）の方位角範囲をカバーする左ビューにあることを示し、他方の球面領域が、−６０〜６０°（両端値を含む）の方位角範囲をカバーする右ビューにあることを示すことによって説明することができる。
ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ（１）がＣｏｎｔｅｎｔＣｏｖｅｒａｇｅＳｔｒｕｃｔ（）内に含まれる場合、Ｓｐｈｅｒｅ  Ｒｅｇｉｏｎ（上記に提示された）を記述する句が適用され、補完は０に等しいとする。
【００３４】
コンテンツカバレッジは、ｎｕｍ＿ｒｅｇｉｏｎｓ  ＳｐｈｅｒｅＲｅｏｎＳｔｒｕｃｔ（１）構造の結合によって指定される。ｎｕｍ＿ｒｅｇｉｏｎｓが１より大きい場合、コンテンツカバレッジは離散的となり得る。
【００３５】
ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有するサンプルエントリ構造を含む。
【００３６】
定義
ちょうど１つのＳｐｈｅｒｅＲｅｇｉｏｎＣｏｎｆｉｇＢｏｘが、サンプルエントリに存在するものとする。ＳｐｈｅｒｅＲｅｇｉｏｎＣｏｎｆｉｇＢｏｘは、サンプルによって指定された球面領域の形状を指定する。サンプル内の領域の方位角及び高度の範囲が変化しない場合、それらはサンプルエントリ内に示され得る。
シンタックス
【表３】
2021520711.tif 000006
セマンティクス
０に等しいｓｈａｐｅ＿ｔｙｐｅは、球面領域が４つの大円によって指定されることを指定する。１に等しいｓｈａｐｅ＿ｔｙｐｅは、球面領域が２つの方位円及び２つの高度円によって指定されることを指定する。１より大きいｓｈａｐｅ＿ｔｙｐｅの値は予備とされる。ｓｈａｐｅ＿ｔｙｐｅの値は、球面領域メタデータトラックのサンプルのセマンティクスにＳｐｈｅｒｅ  Ｒｅｇｉｏｎ（上記に提示された）を記述する句を適用するときに形状タイプ値として使用される。
０に等しいｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇは、このサンプルエントリを参照する全てのサンプルにおいて、球面領域の方位角及び高度の範囲が変更されないままであることを指定する。
１に等しいｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇは、球面領域の方位角及び高度の範囲がサンプルフォーマットにおいて示されることを指定する。
ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、このサンプルエントリを参照する各サンプルについて球面領域の方位角及び高度の範囲をそれぞれ２−１６度の単位で指定する。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、図５Ａ又は図５Ｂに示すように、球面領域の中心点を通る範囲を指定する。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅは、０〜３６０＊２１６（両端値を含む）の範囲とする。ｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、０〜１８０＊２１６（両端値を含む）の範囲とする。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在し、両方とも０に等しい場合、このサンプルエントリを参照する各サンプルの球面領域は、球面上の点である。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在する場合、球面領域メタデータトラックのサンプルのセマンティクスにＳｐｈｅｒｅ  Ｒｅｇｉｏｎ（上記に提示された）を記述する句を適用すると、ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅの値は、ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅにそれぞれ等しいと推測される。
ｎｕｍ＿ｒｅｇｉｏｎｓは、このサンプルエントリを参照するサンプル内の球面領域数を指定する。ｎｕｍ＿ｒｅｇｉｏｎｓは１に等しいとする。ｎｕｍ＿ｒｅｇｉｏｎｓの他の値は予備とされる。
更に、ＭＰＥＧ−Ｉは、以下の定義及びシンタックスを有するＣｏｖｅｒａｇｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｏｘを含む。
定義
ボックスタイプ：‘ｃｏｖｉ’
コンテナ：ＰｒｏｊｅｃｔｅｄＯｍｎｉＶｉｄｅｏＢｏｘ
必須：いいえ
数：ゼロ又は１
このボックスは、このトラックのコンテンツカバレッジに関する情報を提供する。
注記：全方位ビデオコンテンツをレンダリングするときにコンテンツによってカバーされていない領域を処理するのは、完全にＯＭＡＦ（Ｏｍｎｉｄｉｔｉｏｎａｌ  Ｍｅｄｉａ  Ｆｏｒｍａｔ）プレイヤによるものである。
コンテンツカバレッジを指定した球面領域内の各球面位置には、復号化されたピクチャ内の対応するサンプルがあるものとする。しかし、いくつかの球面位置は、対応するサンプルを復号化されたピクチャ内に有するが、コンテンツカバレッジの外側に存在する場合がある。
シンタックス
【表４】
2021520711.tif 000007
上述のように、ＭＰＥＧ−Ｉは、球面ビデオシーケンスを二次元矩形ビデオシーケンスに変換するために使用することができる投影法及び矩形領域別パッキング法を指定する。このようにして、ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有する領域別パッキング構造を指定する。
定義
ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔは、パッキングされた領域とそれぞれの投影された領域との間のマッピングを指定し、ガードバンドが存在する場合には、その位置及びサイズを指定する。
注記：その他の情報の中でも、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔは、二次元デカルトピクチャ領域内のコンテンツカバレッジ情報も提供する。
この句のセマンティクスにおいて復号化されたピクチャは、このシンタックス構造のコンテナに応じて、以下のいずれか１つとなる。
−ビデオの場合、復号化されたピクチャは、ビデオトラックのサンプルから得られる復号出力である。
−画像項目の場合、復号化されたピクチャは、その画像項目の再構成画像である。
ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔのコンテンツを、以下に情報として要約する（この句では、その後に規定のセマンティクスが続く）。
−投影されたピクチャの幅及び高さは、それぞれ、ｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔで明示的にシグナリングされる。
−パッキングされたピクチャの幅及び高さは、それぞれ、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔで明示的にシグナリングされる。
−投影されたピクチャが、立体視であり、上下又は左右のフレームパッキング構成を有する場合には、１に等しいｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇは、
○このシンタックス構造内の投影された領域情報、パッキングされた領域情報、及びガードバンド領域情報が、各構成ピクチャに個別に適用され、
○パッキングされたピクチャ及び投影されたピクチャが、同じ立体視フレームパッキング形式を有し、
○投影された領域及びパッキングされた領域の数が、シンタックス構造においてｎｕｍ＿ｒｅｇｉｏｎｓの値によって示されるものの２倍であることを指定する。
−ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔにはループが含まれ、そのループにおいて、ループエントリは、両方の構成ピクチャのそれぞれの投影された領域及びパッキングされた領域に対応し（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しいとき）、又は１つの投影された領域とそれぞれのパッキングされた領域に対応し（ｃｏｎｓｌｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しいとき）、ループエントリには以下が含まれる。
○パッキングされた領域のガードバンドの存在を示すフラグ、
○パッキングタイプ（ただし、ＭＰＥＧ−Ｉでは、矩形領域別パッキングのみが指定される）、
○投影された領域と矩形領域パッキング構造ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）におけるそれぞれのパッキングされた領域との間のマッピング、
ガードバンドが存在する場合、パッキングされた領域ＧｕａｒｄＢａｎｄ（ｉ）のガードバンド構造。
矩形領域パッキング構造ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）のコンテンツを、以下に情報として要約する（この句では、その後に規定のセマンティクスが続く）。
−ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、ｉ番目の投影された領域の幅、高さ、上部オフセット、及び左オフセットをそれぞれ指定する。
−ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］は、ｉ番目のパッキングされた領域に適用される回転及びミラーリングが存在する場合にはそれらを指定し、ｉ番目の投影された領域にリマッピングする。
−ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、ｉ番目のパッキングされた領域の幅、高さ、上部オフセット、左オフセットをそれぞれ指定する。
ガードバンド構造ＧｕａｒｄＢａｎｄ（ｉ）のコンテンツを、以下に情報として要約する（この句では、その後に規定のセマンティクスが続く）。
−ｌｅｆｔ＿ｇｂ＿ｗｉｄｔｈ［ｉ］、ｒｉｇｈｔ＿ｇｂ＿ｗｉｄｔｈ［ｉ］、ｔｏｐ＿ｇｂ＿ｈｅｉｇｈｔ［ｉ］、又はｂｏｔｔｏｍ＿ｇｂ＿ｈｅｉｇｈｔ［ｉ］は、ｉ番目のパッキングされた領域の左側、右側、上方、又は下方のガードバンドサイズをそれぞれ指定する。
−ｇｂ＿ｎｏｔ＿ｕｓｅｄ＿ｆｏｒ＿ｐｒｅｄ＿ｆｌａｇ［ｉ］は、インター予測プロセスにおける参照としてガードバンドが使用されないように符号化が制約されているかを示す。
−ｇｂ＿ｔｙｐｅ［ｉ］［ｊ］は、ｉ番目のパッキングされた領域のガードバンドのタイプを指定する。
図６は、（左側に）投影されたピクチャ内の投影された領域の位置及びサイズ、並びに（右側に）ガードバンドを有するパッキングされたピクチャ内のパッキングされた領域の位置及びサイズの例を示す。この例は、ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しいときに適用される。
シンタックス
【表５】
2021520711.tif 000008
セマンティクス
ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、投影されたピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しいとき）、又は投影されたピクチャの構成ピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しいとき）のいずれかでｉ番目の投影された領域の幅、高さ、上部オフセット、及び左オフセットを指定する。ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、相対的な投影されたピクチャサンプル単位で示される。
注記１：２つの投影された領域は、部分的に又は全体的に互いに重なり合ってもよい。例えば、領域別の品質ランク表示により品質差の表示がある場合、任意の２つの重複する投影された領域の重複範囲について、レンダリングには、より高品質であることが表示されている投影領域に対応するパックされた領域を使用する必要がある。
ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］は、ｉ番目のパッキングされた領域に適用される回転とミラーリングを指定し、ｉ番目の投影領域にリマッピングする。ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］が回転及びミラーリングの両方を指定するとき、回転は、パッキングされた領域のサンプル位置を投影された領域のサンプル位置に変換するためのミラーリングの前に適用される。以下の値が指定される。
０：変換なし
１：水平ミラーリング
２：１８０度（反時計回り）回転
３：水平にミラーリングする前に、１８０度（反時計回り）回転
４：水平にミラーリングする前に、９０度（反時計回り）回転
５：９０度（反時計回り）回転
６：水平にミラーリングする前に、２７０度（反時計回り）回転
７：２７０度（反時計回り）回転
注記２：ＭＰＥＧ−Ｉは、パッキングされたピクチャ内のパッキングされた領域のサンプル位置を投影されたピクチャ内の投影された領域のサンプル位置に変換するためにｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］のセマンティクスを指定する。
ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、パッキングされたピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しいとき）、又はパッキングされたピクチャの各構成ピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しいとき）のいずれかでｉ番目のパッキングされた領域の幅、高さ、オフセット、左オフセットをそれぞれ指定する。ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、相対的なパッキングされた画像サンプル単位で示される。ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、復号化されたピクチャ内の輝度サンプル単位の整数の水平垂直座標を表すものとする。
注記３：２つのパッキングされた領域は、部分的に又は完全に互いに重なり合ってもよい。
簡潔にするために、本明細書では、矩形領域パッキング構造、ガードバンド構造、及び領域別パッキング構造の完全なシンタックス及びセマンティクスを提供しないことに留意されたい。更に、本明細書では、領域別パッキング変数の完全な導出、及び領域ごとのパッキング構造のシンタックス要素に対する制約を提供しない。しかしながら、ＭＰＥＧ−Ｉの関連する部分を参照する。
【００３７】
上述のように、ＭＰＥＧ−Ｉは、メディアストリーミングシステムにおける全方位メディアのカプセル化、シグナリング、及びストリーミングを指定する。特に、ＭＰＥＧ−Ｉは、ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル（ＨＴＴＰ）（ＤＡＳＨ）を使用して、全方位メディアをどのようにカプセル化、シグナリング、及びストリーミングするかを指定する。ＤＡＳＨは、参照により本明細書に組み込まれる、ＩＳＯ／ＩＥＣ：ＩＳＯ／ＩＥＣ  ２３００９−１：２０１４、「Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  −  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ  （ＤＡＳＨ）  −  Ｐａｒｔ  １：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  ａｎｄ  Ｓｅｇｍｅｎｔ  Ｆｏｒｍａｔｓ」、国際標準化機構、第２版、２０１４年５月１５日（以下、「ＩＳＯ／ＩＥＣ  ２３００９−１：２０１４」とする）に記載される。ＤＡＳＨメディアプレゼンテーションは、データセグメント、ビデオセグメント、及び音声セグメントを含むことができる。いくつかの実施例では、ＤＡＳＨメディアプレゼンテーションは、サービスプロバイダによって定義された所与の期間の線形サービス又は線形サービスの一部（例えば、単一のＴＶ番組、又はある期間にわたる連続した線形ＴＶ番組のセット）に対応することができる。ＤＡＳＨによれば、メディアプレゼンテーション記述（ＭＰＤ）は、適切なＨＴＴＰ−ＵＲＬを構成し、セグメントにアクセスしてストリーミングサービスをユーザに提供するために、ＤＡＳＨクライアントによって要求されるメタデータを含むドキュメントである。ＭＰＤドキュメントフラグメントは、拡張可能マークアップ言語（eXtensible Markup Language、ＸＭＬ）符号化メタデータフラグメントのセットを含むことができる。ＭＰＤのコンテンツは、セグメントのためのリソース識別子及びメディアプレゼンテーション内の識別されたリソースのためのコンテキストを提供する。ＭＰＤフラグメントのデータ構造及びセマンティックは、ＩＳＯ／ＩＥＣ２３００９−１：２０１４に関して記載されている。更に、ＩＳＯ／ＩＥＣ２３００９−１のドラフト版が現在提案されているということに留意されたい。したがって、本明細書において使用されているように、ＭＰＤは、ＩＳＯ／ＩＥＣ２３００９−１：２０１４に記載のようなＭＰＤ、現在提案されているＭＰＤ、及び／又はこれらの組み合わせを含むことができる。ＩＳＯ／ＩＥＣ２３００９−１：２０１４において、ＭＰＤに記載されているようなメディアプレゼンテーションは、１つ以上のピリオド（Period）のシーケンスを含むことができ、各ピリオドは、１つ以上のアダプテーションセット（Adaptation Set）を含むことができる。アダプテーションセットが複数のメディアコンテンツコンポーネントを含む場合、各メディアコンテンツコンポーネントを個別に記述できることに留意されたい。各アダプテーションセットは、１つ以上のリプレゼンテーション（Representation）を含むことができる。ＩＳＯ／ＩＥＣ２３００９−１：２０１４において、各リプレゼンテーションは、次のように明記されている：（１）単一セグメントの場合、サブセグメントがリプレゼンテーションにわたりアダプテーションセットに整列される、及び（２）セグメントのシーケンスの場合、各セグメントは、テンプレートで生成されたユニバーサルリソースロケータ（Universal Resource Locator、ＵＲＬ）によってアドレス指定可能である。各メディアコンテンツコンポーネントのプロパティは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素、及び／又は例えば、ＣｏｎｔｅｎｔＣｏｍｐｏｎｅｎｔ要素を含むＡｄａｐｔｉｏｎＳｅｔ内の要素によって記述することができる。
【００３８】
ＩＳＯ／ＩＥＣ：ＩＳＯ／ＩＥＣ  ２３００９−１、「Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  −  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ  （ＤＡＳＨ）  −  Ｐａｒｔ  １：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  ａｎｄ  Ｓｅｇｍｅｎｔ  Ｆｏｒｍａｔｓ」、国際標準化機構、草稿第３版は、Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎについて記載しており、ここでＡｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎとは、少なくとも１つの他のＲｅｐｒｅｓｅｎｔａｔｉｏｎに対する補足的又は記述的な情報を提供するＲｅｐｒｅｓｅｎｔａｔｉｏｎである。Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性及び任意選択で＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性を含むＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素の属性によって記述される。＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性及び＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性は、表１Ａに提供されるようにＤＡＳＨで定義される。
【表６】
2021520711.tif 000009
上述のように、ＭＰＥＧ−Ｉは、コンポジション整列されたサンプルが、トラック内に、別のトラックに関連付けられた１つのサンプルを含む場所を提供し、そのサンプルが、その別のトラック内のある特定のサンプルと同じコンポジション時間を有する、又は同じコンポジション時間を有するサンプルが別のトラックで利用できない場合には、その別のトラック内のある特定のサンプルのコンポジション時間に関して最も近い先行するコンポジション時間を提供する。参照により本明細書に組み込まれる、Ｈａｎｎｕｋｓｅｌａら（「Ｈａｎｎｕｋｓｅｌａ」と呼ぶ）による、ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１  ＭＰＥＧ２０１７／Ｗ１７２７９、「Ｔｅｃｈｎｏｌｏｇｉｅｓ  ｕｎｄｅｒ  Ｃｏｎｓｉｄｅｒａｔｉｏｎ  ｏｎ  Ｓｕｂ−Ｐｉｃｔｕｒｅ  Ｃｏｍｐｏｓｉｔｉｏｎ  Ｔｒａｃｋ  Ｇｒｏｕｐｉｎｇ  ｆｏｒ  ＯＭＡＦ」２０１７年（マカオ）（「Ｈａｎｎｕｋｓｅｌａ」と呼ぶ）は、コンポジションピクチャを提案しており、このコンポジションピクチャは、提示に適したピクチャであり、サブピクチャコンポジショントラックグループのシンタックス要素によって指定されるように全てのトラックを空間的に配置することにより、サブピクチコンポジショントラックグループの全てのトラックのコンポジション整列されたサンプルの復号出力から取得される。
【００３９】
サブピクチャコンポジショントラックグループに関して、Ｈａｎｎｕｋｓｅｌａは、以下の定義、シンタックス、及びセマンティクスを有するサブピクチャコンポジショントラックグループデータ構造を提供する。
定義
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、このトラックが、コンポジションピクチャを得るために空間的に配置されることができる複数のトラックからなるコンポジションに属することを示す。このグループにマッピングされたビジュアルトラック同士（つまり、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’である、ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内でｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値が同じであるビジュアルトラック同士）は、提示可能なビジュアルコンテンツを全体として表す。
このグループにマッピングされた個々のビジュアルトラックはそれぞれ、他のビジュアルトラックなしで単独で表示されることを意図してもしなくてもよく、一方で、コンポジションピクチャは提示に適している。
注記１：コンテンツ作成者は、ＴｒａｃｋＨｅａｄｅｒＢｏｘのｔｒａｃｋ＿ｎｏｔ＿ｉｎｔｅｎｄｅｄ＿ｆｏｒ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ａｌｏｎｅフラグを使用して、あるビジュアルトラックだけが他のビジュアルトラックなしで単独で提示されることを意図しないことを示すことができる。
注記２：ＨＥＶＣビデオビットストリームが、タイルトラックとそれに関連するタイルベーストラックとの組で保持され、ビットストリームが、サブピクチャコンポジショントラックグループによって示されるサブピクチャを表す場合、タイルベーストラックのみがＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘを含む。
コンポジションピクチャは、以下のセマンティクスに従って指定されるように、同じサブピクチャコンポジショントラックグループに属し、同じ代替グループに属する全てのトラックのコンポジション整列されたサンプルの復号出力を空間的に配置することによって得られる。
【００４０】
シンタックス
【表７】
2021520711.tif 000010
セマンティクス
ｔｒａｃｋ＿ｘは、コンポジションピクチャ上のこのトラックのサンプルの左上隅の水平位置を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｘの値は、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ−１（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｙは、コンポジションピクチャ上のこのトラックのサンプルの左上隅の垂直位置を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｙの値は、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｗｉｄｔｈは、コンポジションピクチャ上のこのトラックのサンプルの幅を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｗｉｄｔｈの値は、１〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ−１（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｈｅｉｇｈｔは、コンポジションピクチャ上のこのトラックのサンプルの高さを輝度サンプル単位で指定する。ｔｒａｃｋ＿ｈｅｉｇｈｔの値は、１〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲とする。
ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈは、コンポジションピクチャの幅を輝度サンプル単位で指定する。ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈの値は、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値を有するＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの全てのインスタンスにおいて同じであるものとする。
ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔは、コンポジションピクチャの高さを輝度サンプル単位で指定する。ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔの値は、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値を有するＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの全てのインスタンスにおいて同じであるものとする。
ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、及びｔｒａｃｋ＿ｈｅｉｇｈｔによって表される矩形を、このトラックのサブピクチャ矩形と呼ぶ。
【００４１】
同じサブピクチャコンポジショントラックグループに属し、同じ代替グループに属する（すなわち、同じ非ゼロのａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値を有する）全てのトラックについて、サブピクチャ矩形の位置及びサイズは、それぞれ同一であるものとする。
【００４２】
サブピクチャコンポジショントラックグループのコンポジションピクチャは、以下のように導出される。
１）サブピクチャコンポジショントラックグループに属する全てのトラックの中から、各代替グループからの１つのトラックを選択する。
２）選択されたトラックごとに、以下を適用する。
ａ．０〜ｔｒａｃｋ＿ｗｉｄｔｈ−１（両端値を含む）の範囲のｉの各値について、及び０〜ｔｒａｃｋ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲のｊの各値について、輝度サンプル位置（（ｉ＋ｔｒａｃｋ＿ｘ）％ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、（ｊ＋ｔｒａｃｋ＿ｙ）％ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ）が、輝度サンプル位置（ｉ、ｊ）におけるこのトラックのサブピクチャの輝度サンプルと等しくなるように設定される。
ｂ．復号化されたピクチャが４：０：０以外の色差フォーマットを有する場合、色差成分はそれに応じて導出される。
同じサブピクチャコンポジショントラックグループに属し、異なる代替グループに属する（すなわち、ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐが０である又はａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値が異なる）全てのトラックのサブピクチャ矩形は、重複せず、間隙を有しないものとし、コンポジションピクチャの上記導出プロセスでは、各輝度サンプル位置（ｘ、ｙ）（ここで、ｘは、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ−１（両端値を含む）の範囲）であり、ｙは、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲）が、１回だけトラバースされる。
【００４３】
更に、Ｈａｎｎｕｋｓｅｌａは、どのようにサブピクチャコンポジショントラックグループが全方位ビデオに適用され得るかに関して、以下を提供している。
この句は、サブピクチャコンポジショントラックグループにマッピングされたトラックのいずれかが、サンプルエントリに含まれるＳｃｈｅｍｅＴｙｐｅＢｏｘ内に’ｒｅｓｖ’であるサンプルエントリタイプ及び’ｐｏｄｖ’であるｓｃｈｅｍｅ＿ｔｙｐｅを有するときに適用される。
【００４４】
各コンポジションピクチャは、任意のＰｒｏｊｅｃｔｉｏｎＦｏｒｍａｔＢｏｘによって示される投影フォーマットを有するパッキングされたピクチャであり、任意選択的に、同じサブピクチャコンポジショントラックグループの任意のトラックのサンプルエントリ内の任意のＳｔｅｒｅｏＶｉｄｅｏＢｏｘによって示されるフレームパッキング配置を有し、また、任意選択的に、同じサブピクチャコンポジショントラックグループの任意のＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘに含まれる任意のＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘによって示される領域別のパッキング形式を有する、パッキングされたピクチャである。
【００４５】
ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘにおけるＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのｔｒａｃｋ＿ｗｉｄｔｈ及びｔｒａｃｋ＿ｈｅｉｇｈｔは、それぞれ、輝度サンプル単位内の復号装置によって出力されるピクチャの幅及び高さであるものとする。
【００４６】
以下の制約が、このグループにマッピングされたトラックに適用される。
−このグループにマッピングされた各トラックは、’ｒｅｓｖ’であるサンプルエントリタイプを有するものとする。ｓｃｈｅｍｅ＿ｔｙｐｅは、サンプルエントリに含まれるＳｃｈｅｍｅＴｙｐｅＢｏｘ内の’ｐｏｄｖ’であるものとする。
−同じサブピクチャコンポジショントラックグループにマッピングされたトラックのサンプルエントリに含まれるＰｒｏｊｅｃｔｉｏｎＦｏｒｍａｔＢｏｘの全てのインスタンスのコンテンツは同一であるものとする。
−ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘは、任意のサブピクチャコンポジショントラックグループにマッピングされたトラックのサンプルエントリ内に存在しないものとする。
−ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘが特定のｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有するＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘに存在する場合、それは、同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を持つＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの全てのインスタンスに存在し、同一であるものとする。
注記：サブピクチャが平面視（一方のビューのみを含む）又は立体視（両方のビューを含む）のいずれかになるように、領域別のパッキングを、サブピクチャトラック内で保持される立体視全方位ビデオに適用することができる。左ビュー及び右ビューの両方からのパッキングされた領域が矩形領域を形成するように配置される場合、矩形領域の境界は、左ビュー及び右ビューの両方からなる立体視サブピクチャの境界とすることができる。左ビュー又は右ビューのみからのパッキングされた領域を配置して矩形領域を形成する場合、矩形領域の境界は、左ビュー又は右ビューのいずれかのみからなる平面視サブピクチャの境界とすることができる。
−同じサブピクチャコンポジショントラックグループにマッピングされたトラックのサンプルエントリに含まれるＲｏｔａｔｉｏｎＢｏｘの全てのインスタンスのコンテンツは同一であるものとする。
−同じサブピクチャコンポジショントラックグループにマッピングされたトラックのサンプルエントリに含まれるＳｔｅｒｅｏＶｉｄｅｏＢｏｘの全てのインスタンスのコンテンツは同一であるものとする。
−同じサブピクチャコンポジショントラックグループにマッピングされたトラックのＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの全てのインスタンスに含まれるＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎＢｏｘの全てのインスタンスのコンテンツは同一であるものとする。
各サブピクチャコンポジショントラックグループについて以下を適用する：
−平面視投影された輝度ピクチャの幅及び高さ（それぞれＣｏｎｓｔｉｔｕｅｎｔＰｉｃＷｉｄｔｈ及びＣｏｎｓｔｉｔｕｅｎｔＰｉｃＨｅｉｇｈｔ）は、以下のように導出される。
○ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘがＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ内に存在しない場合、ＣｏｎｓｔｉｔｕｅｎｔＰｉｃＷｉｄｔｈ及びＣｏｎｓｔｉｔｕｅｎｔＰｉｃＨｅｉｇｈｔは、それぞれ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ／ＨｏｒＤｉｖ１及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ／ＶｅｒＤｉｖ１と等しくなるように設定される。
○そうでなければ、ＣｏｎｓｔｉｔｕｅｎｔＰｉｃＷｉｄｔｈ及びＣｏｎｓｔｉｔｕｅｎｔＰｉｃＨｅｉｇｈｔは、それぞれ、ｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ／ＨｏｒＤｉｖ１、及びｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔ／ＶｅｒＤｉｖ１と等しくなるように設定される。
−ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘがＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ内に存在しない場合、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＦｌａｇは、０に等しくなるように設定される。そうでなければ、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＦｌａｇは、１に等しくなるように設定される。
−このサブピクチャコンポジショントラックグループの各コンポジションピクチャのサンプル位置のセマンティクスは、ＭＰＥＧ−Ｉの７．３．１節で指定されている。
Ｈａｎｎｕｋｓｅｌａで提案されたサブピクチャ領域ボックスは、理想的ではない場合がある。具体的には、Ｈａｎｎｕｋｓｅｌａで提案されたＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘは、サブピクチャコンポジショングループのシグナリングに関して十分な柔軟性をもたらさないことがある。
【００４７】
上述のように、ＤＡＳＨでは、トラックは、サブピクチャコンポジショントラックグループに属することができる。Ｈａｎｎｕｋｓｅｌａは、アダプテーションセットレベルでの＠ｓｐａｔｉａｌＳｅｔＩｄ属性を提案し、同じサブピクチャコンポジショントラックグループに属するトラックをグループ化する。具体的には、Ｈａｎｎｕｋｓｅｌａは、表１に関して以下に提供される定義を有する＠ｓｐａｔｉａｌＳｅｔＩｄ属性を提案している。以下の表では、「使用」の列について、Ｍ＝必須、ＣＭ＝条件付き必須、Ｏ＝任意選択であることに留意されたい。更に、「使用」の列は、代わりに、濃度（Ｃａｒｄｉｎａｌｉｔｙ）とラベル付けされる場合があることに留意されたい。また、「使用」の列内の１のエントリは、Ｍ（すなわち必須又は必要）に変更されてもよく、逆もまた同様であり、「使用」の列内の０．．１のエントリは、Ｏ（すなわち任意選択）又はＣＭ（すなわち、条件付き必須）に変更されてもよく、逆もまた同様である。
【００４８】
任意選択のアダプテーションセットレベル属性である、＠ｓｐａｔｉａｌＳｅｔＩｄは、同じサブピクチャコンポジショントラックグループに属するトラックを保持するアダプテーションセット同士をグループ化するために定義され、使用される。＠ｓｐａｔｉａｌＳｅｔＩｄのセマンティクスは以下の通りである。
【表８】
2021520711.tif 000011
Ｈａｎｎｕｋｓｅｌａにおいて提供される＠ｓｐａｔｉａｌＳｅｔＩｄ属性を使用して同じサブピクチャコンポジショントラックグループに属するトラックをグループ化することには、各アダプテーションセットは１つのサブピクチャコンポジショングループのみに属することができるという制限がある。場合によっては、アダプテーションセットは２つ以上のサブピクチャコンポジションに属し得る。例えば、ビデオが１６個のタイルから構成されており、各タイルが１つのＡｄａｐｔａｔｉｏｎＳｅｔ中にある場合、１つのサブピクチャコンポジションは、第１のコンポジションに属する１６個のタイルの全てをシグナリングすることができる。例えば、そのようなコンポジションは、より高い解像度及びより高いレベルのサポートを有するビデオ復号装置によって処理することができる。同時に、別のサブピクチャコンポジションは、第２のコンポジションに属する中央の４個のタイルのみをシグナリングすることができる。このコンポジションは、例えば、より低い解像度の低レベルのビデオ復号装置によって処理することができる。別の実施例では、アダプテーションセット１〜６が、キューブマッププロジェクションの左ビューに対応してもよく、アダプテーションセット７〜１２が、キューブマッププロジェクションの右ビューに対応してもよい。この場合、平面視クライアントをターゲットとする１つのサブピクチャコンポジションは６個のアダプテーションセットを使用することができ、ステレオクライアント用の別のサブピクチャコンポジションは１２個のアダプテーションセット全てを使用することができる。したがって、同じアダプテーションセットが、複数のサブピクチャコンポジションに属し得る。同じＡｄａｐｔａｔｉｏｎＳｅｔが複数のサブピクチャコンポジションに属している場合、これらのグループのタイプは＠ｓｐａｔｉａｌＳｅｔＩｄ属性でシグナリングすることはできない。
【００４９】
図１は、本開示の１つ以上の技術による、ビデオデータをコード化する（符号化及び／又は復号する）ように構成することができる、システムの例を示すブロック図である。システム１００は、本開示の１つ以上の技術に従って、ビデオデータをカプセル化することができるシステムの例を表す。図１に示すように、システム１００は、ソースデバイス１０２と、通信媒体１１０と、目的デバイス１２０と、を含む。図１に示す例では、ソースデバイス１０２は、ビデオデータを符号化し、符号化したビデオデータを通信媒体１１０に送信するように構成された、任意のデバイスを含むことができる。目的デバイス１２０は、通信媒体１１０を介して符号化したビデオデータを受信し、符号化したビデオデータを復号するように構成された、任意のデバイスを含むことができる。ソースデバイス１０２及び／又は目的デバイス１２０は、有線及び／又は無線通信用に装備された演算デバイスを含むことができ、かつ、例えば、セットトップボックス、デジタルビデオレコーダ、テレビ、デスクトップ、ラップトップ、又はタブレットコンピュータ、ゲーム機、医療用撮像デバイス、及び、例えば、スマートフォン、セルラー電話、パーソナルゲームデバイスを含むモバイルデバイス、を含むことができる。
【００５０】
通信媒体１１０は、無線及び有線の通信媒体並びに／又は記憶デバイスの任意の組み合わせを含むことができる。通信媒体１１０としては、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、無線送信機及び受信機、ルータ、スイッチ、リピータ、基地局、又は様々なデバイスとサイトとの間の通信を容易にするために有用であり得る任意の他の機器を挙げることができる。通信媒体１１０は、１つ以上のネットワークを含むことができる。例えば、通信媒体１１０は、ワールドワイドウェブ、例えば、インターネットへのアクセスを可能にするように構成されたネットワークを含むことができる。ネットワークは、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。標準化された電気通信プロトコルの例としては、Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）規格、Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ（ＡＴＳＣ）規格、Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＩＳＤＢ）規格、Ｄａｔａ  Ｏｖｅｒ  Ｃａｂｌｅ  Ｓｅｒｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＤＯＣＳＩＳ）規格、Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）規格、符号分割多重アクセス（code division multiple access、ＣＤＭＡ）規格、第三世代パートナーシッププロジェクト（3rd Generation Partnership Project、３ＧＰＰ）規格、欧州電気通信標準化機構（European Telecommunications Standards Institute、ＥＴＳＩ）規格、インターネットプロトコル（Internet Protocol、ＩＰ）規格、ワイヤレスアプリケーションプロトコル（Wireless Application Protocol、ＷＡＰ）規格、及びＩｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）規格が挙げられる。
【００５１】
記憶デバイスは、データを記憶することができる任意の種類のデバイス又は記憶媒体を含むことができる。記憶媒体は、有形又は非一時的コンピュータ可読媒体を含むことができる。コンピュータ可読媒体としては、光学ディスク、フラッシュメモリ、磁気メモリ、又は任意の他の好適なデジタル記憶媒体を挙げることができる。いくつかの例では、メモリデバイス又はその一部分は不揮発性メモリとして説明されることがあり、他の例では、メモリデバイスの一部分は揮発性メモリとして説明されることがある。揮発性メモリの例としては、ランダムアクセスメモリ（random access memory、ＲＡＭ）、ダイナミックランダムアクセスメモリ（dynamic random access memory、ＤＲＡＭ）、及びスタティックランダムアクセスメモリ（static random access memory、ＳＲＡＭ）を挙げることができる。不揮発性メモリの例としては、磁気ハードディスク、光学ディスク、フロッピーディスク、フラッシュメモリ、又は電気的プログラム可能メモリ（electrically programmable memory、ＥＰＲＯＭ）若しくは電気的消去可能及びプログラム可能メモリ（electrically erasable and programmable、ＥＥＰＲＯＭ）の形態を挙げることができる。記憶デバイス（単数又は複数）としては、メモリカード（例えば、セキュアデジタル（Secure Digital、ＳＤ）メモリカード）、内蔵／外付けハードディスクドライブ、及び／又は内蔵／外付けソリッドステートドライブを挙げることができる。データは、定義されたファイルフォーマットに従って記憶デバイス上に記憶することができる。
【００５２】
図７は、システム１００の一実装形態に含まれ得る構成要素の一例を示す概念図である。図７に示す例示的な実装形態では、システム１００は、１つ以上の演算デバイス４０２Ａ〜４０２Ｎ、テレビサービスネットワーク４０４、テレビサービスプロバイダサイト４０６、ワイドエリアネットワーク４０８、ローカルエリアネットワーク４１０、及び１つ以上のコンテンツプロバイダサイト４１２Ａ〜４１２Ｎを含む。図７に示す実装形態は、例えば、映画、ライブスポーツイベントなどのデジタルメディアコンテンツ、並びにデータ及びアプリケーション及びそれらに関連付けられたメディアプレゼンテーションが、演算デバイス４０２Ａ〜４０２Ｎなどの複数の演算デバイスに配信され、かつ、それらによってアクセスされることが可能となるように構成され得るシステムの一例を表す。図７に示す例では、演算デバイス４０２Ａ〜４０２Ｎは、テレビサービスネットワーク４０４、ワイドエリアネットワーク４０８、及び／又はローカルエリアネットワーク４１０のうちの１つ以上からデータを受信するように構成されている任意のデバイスを含むことができる。例えば、演算デバイス４０２Ａ〜４０２Ｎは、有線及び／又は無線通信用に装備されてもよく、１つ以上のデータチャネルを通じてサービスを受信するように構成されてもよく、いわゆるスマートテレビ、セットトップボックス、及びデジタルビデオレコーダを含むテレビを含んでもよい。更に、演算デバイス４０２Ａ〜４０２Ｎは、デスクトップ、ラップトップ又はタブレットコンピュータ、ゲーム機、例えば「スマート」フォン、セルラー電話、及びパーソナルゲーミングデバイスを含むモバイルデバイスを含んでもよい。
【００５３】
テレビサービスネットワーク４０４は、テレビサービスを含み得る、デジタルメディアコンテンツの配信を可能にするように構成されているネットワークの一例である。例えば、テレビサービスネットワーク４０４は、公共地上波テレビネットワーク、公共又は加入ベースの衛星テレビサービスプロバイダネットワーク、並びに公共又は加入ベースのケーブルテレビプロバイダネットワーク及び／又は頭越し型（over the top）サービスプロバイダ若しくはインターネットサービスプロバイダを含んでもよい。いくつかの実施例では、テレビサービスネットワーク４０４は、テレビサービスの提供を可能にするために主に使用され得るが、テレビサービスネットワーク４０４はまた、本明細書に記載された電気通信プロトコルの任意の組み合わせに基づく他の種類のデータ及びサービスの提供も可能とすることに留意されたい。更に、いくつかの実施例では、テレビサービスネットワーク４０４は、テレビサービスプロバイダサイト４０６と、演算デバイス４０２Ａ〜４０２Ｎのうちの１つ以上との間の双方向通信を可能にすることができることに留意されたい。テレビサービスネットワーク４０４は、無線通信メディア及び／又は有線通信メディアの任意の組み合わせを含むことができる。テレビサービスネットワーク４０４は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、無線送信機及び受信機、ルータ、スイッチ、リピータ、基地局、又は様々なデバイスとサイトとの間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。テレビサービスネットワーク４０４は、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、ＤＶＢ規格、ＡＴＳＣ規格、ＩＳＤＢ規格、ＤＴＭＢ規格、ＤＭＢ規格、ケーブルによるデータサービスインターフェース標準（Data Over Cable Service Interface Specification、ＤＯＣＳＩＳ）規格、ＨｂｂＴＶ規格、Ｗ３Ｃ規格、及びＵＰｎＰ規格が挙げられる。
【００５４】
図７を再び参照すると、テレビサービスプロバイダサイト４０６は、テレビサービスネットワーク４０４を介してテレビサービスを配信するように構成することができる。例えば、テレビサービスプロバイダサイト４０６は、１つ以上の放送局、ケーブルテレビプロバイダ、又は衛星テレビプロバイダ、又はインターネットベースのテレビプロバイダを含み得る。例えば、テレビサービスプロバイダサイト４０６は、衛星アップリンク／ダウンリンクを介したテレビプログラムを含む送信を、受信するように構成することができる。更に、図７に示すように、テレビサービスプロバイダサイト４０６は、ワイドエリアネットワーク４０８と通信することができ、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎからデータを受信するように構成することができる。いくつかの実施例では、テレビサービスプロバイダサイト４０６は、テレビスタジオを含むことができ、コンテンツはそこから発信できることに留意されたい。
【００５５】
ワイドエリアネットワーク４０８は、パケットベースのネットワークを含み、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、汎欧州デジタル移動電話方式（Global System Mobile Communications、ＧＳＭ）規格、符号分割多元接続（code division multiple access、ＣＤＭＡ）規格、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（３ＧＰＰ）規格、欧州電気通信標準化機構（European Telecommunications Standards Institute、ＥＴＳＩ）規格、欧州規格（ＥＮ）、ＩＰ規格、ワイヤレスアプリケーションプロトコル（Wireless Application Protocol、ＷＡＰ）規格、及び例えば、ＩＥＥＥ８０２規格のうちの１つ以上（例えば、Ｗｉ−Ｆｉ）などの電気電子技術者協会（Institute of Electrical and Electronics Engineers、ＩＥＥＥ）規格が挙げられる。ワイドエリアネットワーク４０８は、無線通信メディア及び／又は有線通信メディアの任意の組み合わせを含むことができる。ワイドエリアネットワーク４８０は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、イーサネットケーブル、無線送信部及び受信部、ルータ、スイッチ、リピータ、基地局、又は様々なデバイス及びサイト間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。一実施例では、ワイドエリアネットワーク４０８はインターネットを含んでもよい。ローカルエリアネットワーク４１０は、パケットベースのネットワークを含み、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。ローカルエリアネットワーク４１０は、アクセス及び／又は物理インフラストラクチャのレベルに基づいてワイドエリアネットワーク４０８と区別することができる。例えば、ローカルエリアネットワーク４１０は、セキュアホームネットワークを含んでもよい。
【００５６】
図７を再び参照すると、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、マルチメディアコンテンツをテレビサービスプロバイダサイト４０６及び／又は演算デバイス４０２Ａ〜４０２Ｎに提供することができるサイトの例を表す。例えば、コンテンツプロバイダサイトは、マルチメディアファイル及び／又はストリームをテレビサービスプロバイダサイト４０６に提供するように構成されている、１つ以上のスタジオコンテンツサーバを有するスタジオを含むことができる。一実施例では、コンテンツプロバイダのサイト４１２Ａ〜４１２Ｎは、ＩＰスイートを使用してマルチメディアコンテンツを提供するように構成されてもよい。例えば、コンテンツプロバイダサイトは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ＨＴＴＰなどに従って、マルチメディアコンテンツを受信デバイスに提供するように構成されてもよい。更に、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、ハイパーテキストベースのコンテンツなどを含むデータを、ワイドエリアネットワーク４０８を通じて、受信デバイスである演算デバイス４０２Ａ〜４０２Ｎ、及び／又はテレビサービスプロバイダサイト４０６のうちの１つ以上に提供するように構成されてもよい。コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、１つ以上のウェブサーバを含んでもよい。データプロバイダサイト４１２Ａ〜４１２Ｎによって提供されるデータは、データフォーマットに従って定義することができる。
【００５７】
図１を再び参照すると、ソースデバイス１０２は、ビデオソース１０４と、ビデオ符号化装置１０６と、データカプセル化装置１０７と、インターフェース１０８とを含む。ビデオソース１０４は、ビデオデータをキャプチャ及び／又は記憶するように構成された任意のデバイスを含むことができる。例えば、ビデオソース１０４は、ビデオカメラ及びそれに動作可能に結合された記憶デバイスを含むことができる。ビデオ符号化装置１０６は、ビデオデータを受信し、ビデオデータを表す適合したビットストリームを生成するように構成された、任意のデバイスを含むことができる。適合したビットストリームは、ビデオ復号装置が受信し、それからビデオデータを再生することができるビットストリームを指すことがある。適合したビットストリームの態様は、ビデオ符号化標準に従って定義することができる。適合したビットストリームを生成するとき、ビデオ符号化装置１０６は、ビデオデータを圧縮することができる。圧縮は、非可逆的（視聴者に認識可能若しくは認識不可能）又は可逆的とすることができる。
【００５８】
再び図１を参照すると、データカプセル化装置１０７は、符号化ビデオデータを受信し、定義されたデータ構造に従って、例えば、一連のＮＡＬユニットである準拠ビットストリームを生成することができる。準拠ビットストリームを受信するデバイスは、そこからビデオデータを再生成することができる。適合ビットストリームという用語は、準拠ビットストリームという用語の代わりに使用され得ることに留意されたい。データカプセル化装置１０７は、ビデオ符号化装置１０６と同じ物理デバイス内に配置される必要はないことに留意されたい。例えば、ビデオ符号化装置１０６及びデータカプセル化装置１０７によって実行されるものとして説明される機能は、図７に示すデバイス間で分散されてもよい。
【００５９】
一実施例では、データカプセル化装置１０７は、１つ以上のメディアコンポーネントを受信し、ＤＡＳＨに基づいてメディアプレゼンテーションを生成するように構成されたデータカプセル化部を含むことができる。図８は、本開示の１つ以上の技術を実装することができるデータカプセル化部の一例を示すブロック図である。データカプセル化部５００は、本明細書に記載された技術に従ってメディアプレゼンテーションを生成するように構成することができる。図８に示す例では、コンポーネントカプセル化部５００の機能ブロックは、メディアプレゼンテーション（例えば、ＤＡＳＨメディアプレゼンテーション）を生成するための機能ブロックに対応する。図８に示すように、コンポーネントカプセル化部５００は、メディアプレゼンテーション記述生成部５０２、セグメント生成部５０４、及びシステムメモリ５０６を含む。メディアプレゼンテーション記述生成部５０２、セグメント生成部５０４、及びシステムメモリ５０６の各々は、コンポーネント間通信のために（物理的、通信的、及び／又は動作的に）相互接続することができ、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な適切な回路のいずれかとして実装することができる。データカプセル化部５００は、別個の機能ブロックを有するものとして図示されるが、このような図示は、説明を目的としており、データカプセル化部５００を特定のハードウェアアーキテクチャに限定しないということに留意されたい。データカプセル化部５００の機能は、ハードウェア、ファームウェア及び／又はソフトウェアの実装形態の任意の組み合わせを用いて実現することができる。
【００６０】
メディアプレゼンテーション記述生成部５０２は、メディアプレゼンテーション記述フラグメントを生成するように構成することができる。セグメント生成部５０４は、メディアコンポーネントを受信し、メディアプレゼンテーションに含めるための１つ以上のセグメントを生成するように構成することができる。システムメモリ５０６は、非一時的又は有形のコンピュータ可読記憶媒体として説明することができる。いくつかの実施例では、システムメモリ５０６は、一時的及び／又は長期記憶部を提供することができる。いくつかの実施例では、システムメモリ５０６又はその一部は、不揮発性メモリとして説明することができ、別の実施例では、システムメモリ５０６の一部は、揮発性メモリとして説明することができる。システムメモリ５０６は、動作中にデータカプセル化部によって使用することができる情報を記憶するように構成することができる。
【００６１】
上述のように、Ｈａｎｎｕｋｓｅｌａで提案されたサブピクチャ領域ボックスは、理想的ではない場合がある。一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、以下の定義、シンタックス、及びセマンティクスに基づいて、サブピクチャ領域ボックスをシグナリングするように構成することができる。
定義
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘは、このトラックが、コンポジションピクチャを得るために空間的に配置されることができる複数のトラックからなるコンポジションに属することを示す。このグループにマッピングされたビジュアルトラック同士（つまり、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内でｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄの値が同じであるビジュアルトラック同士）は、提示可能なビジュアルコンテンツを全体として表す。
【００６２】
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘ内のｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄは、以下のように解釈される。
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットが’１０’である場合、それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有する各サブピクチャトラックが、左ビューのみのコンテンツを含むことを示す。
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットが’０１’である場合、それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有する各サブピクチャトラックが、右ビューのみのコンテンツを含むことを示す。
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットが’１１’である場合、それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有する各サブピクチャトラックが、左ビュー及び右ビューのコンテンツを含むことを示す。
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットが’００’である場合、それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるこのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有するサブピクチャトラックが、左ビュー又は右ビューのコンテンツを含むかについての情報がシグナリングされないことを示す。代替例では、’００’であるｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットは予備とされる。
代替例では、
ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値の２つの最下位ビットが’１１’である場合、それは、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるこのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有するサブピクチャトラックが、左ビュー及び右ビューのコンテンツを含むことを示す。
他の実施例では、上記の２つの最下位ビットの代わりに、最上位ビットが指示に使用されてもよいことに留意されたい。更に他の実施例では、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ内の任意の２ビットが指示に使用されてもよい。更に別の実施例では、少なくとも２ビット幅である新しいビットフィールドが、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘでシグナリングされてもよく、これは、上記の左ビュー／右ビュー／両方のビュー表示を示すために使用されてもよい。
【００６３】
別の変形例では、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値のスペースは、将来の拡張性のために以下のように分割されてもよい。
【００６４】
この規格のこのバージョンのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値は、０〜６５５３５の範囲とする。
【００６５】
６５５３５より大きいｓｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値は予備とされる。
【００６６】
別の実施例では、値６５５３５の代わりに、いくつかの他の値を使用して、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値のスペースを、予備として確保された値とこの規格のこのバージョンによって使用される値とに分割することができる。
【００６７】
このグループにマッピングされた個々のビジュアルトラックはそれぞれ、他のビジュアルトラックなしで単独で表示されることを意図してもしなくてもよく、一方で、コンポジションピクチャは提示に適している。
注記１：コンテンツ作成者は、ＴｒａｃｋＨｅａｄｅｒＢｏｘのｔｒａｃｋ＿ｎｏｔ＿ｉｎｔｅｎｄｅｄ＿ｆｏｒ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ａｌｏｎｅフラグを使用して、あるビジュアルトラックだけが他のビジュアルトラックなしで単独で提示されることを意図しないことを示すことができる。
注記２：ＨＥＶＣビデオビットストリームが、タイルトラックとそれに関連するタイルベーストラックとの組で得られ、ビットストリームが、サブピクチャコンポジショントラックグループによって示されるサブピクチャを表す場合、タイルベーストラックのみがＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘを含む。
コンポジションピクチャは、以下のセマンティクスに従って指定されるように、同じサブピクチャコンポジショントラックグループに属し、同じ代替グループに属する全てのトラックのコンポジション整列されたサンプルの復号出力を空間的に配置することによって得られる。
シンタックス
【表９】
2021520711.tif 000012
別の実施例では、ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔの上記ビットフィールド幅のうちの１つ以上が、３２ビットの代わりに１６ビットであってもよい。
セマンティクス
ｔｒａｃｋ＿ｘは、コンポジションピクチャ上のこのトラックのサンプルの左上隅の水平位置を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｘの値は、０〜ｃｏｍｐｏｓｉｔｉｏｎ  ｗｉｄｔｈ−１（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｙは、コンポジションピクチャ上のこのトラックのサンプルの左上隅の垂直位置を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｙの値は、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｗｉｄｔｈは、コンポジションピクチャ上のこのトラックのサンプルの幅を輝度サンプル単位で指定する。ｔｒａｃｋ＿ｗｉｄｔｈの値は、１〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ（両端値を含む）の範囲とする。
ｔｒａｃｋ＿ｈｅｉｇｈｔは、コンポジションピクチャ上のこのトラックのサンプルの高さを輝度サンプル単位で指定する。ｔｒａｃｋ＿ｈｅｉｇｈｔの値は、１〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−ｔｒａｃｋ＿ｙ（両端値を含む）の範囲とする。別の実施例では、ｔｒａｃｋ＿ｈｅｉｇｈｔの値は、１〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ（両端値を含む）の範囲とする。
ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈは、コンポジションピクチャの幅を輝度サンプル単位で指定する。ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈが存在しない場合には、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈは、このＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏと同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を持ち、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ内でシグナリングされたｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈのシンタックス要素に等しいと推測される。ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈの値は、１以上とする。
ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔは、コンポジションピクチャの高さを輝度サンプル単位で指定する。ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔが存在しない場合には、ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔは、このＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘと同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を持ち、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅが’ｓｐｃｏ’であるＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘ内でシグナリングされたｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔのシンタックス要素に等しいと推測される。ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔの値は、１以上とする。
同じサブピクチャコンポジショントラックグループに属する全てのトラックについて、フラグの最下位ビットの値は、ＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘが１つだけの場合、１に等しいとする。したがって、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ要素及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ要素は、ただ１つのＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘにおいてシグナリングされるものとする。
別の実施例では、
同じサブピクチャコンポジショントラックグループに属する全てのトラックについて、フラグの最下位ビットの値は、少なくとも１つのＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの場合、１に等しいとする。
【００６８】
したがって、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ要素及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ要素は、少なくとも１つのＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘにおいてシグナリングされるものとする。
【００６９】
変形例では、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔが０より大きいという制約の代わりに、これらのシンタックス要素は、マイナス１コーディングを使用して次のようなセマンティクスでコーディングすることができる。
【００７０】
ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１  ｐｌｕｓ  １は、コンポジションピクチャの幅を輝度サンプル単位で指定する。
ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１  ｐｌｕｓ  １は、コンポジションピクチャの高さを輝度サンプル単位で指定する。
変形例では、フラグの最下位ビット値の代わりに、フラグ内のいくつかの他のビットを使用して、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔのシグナリングを条件付けてもよい。例えば、以下のシンタックスでは、このためにフラグの最上位ビットを使用する。
【表１０】
2021520711.tif 000013
別の実施例では、ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔの上記１つ以上のビットフィールド幅が、１６ビットの代わりに３２ビットであってもよい。
【００７１】
ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、及びｔｒａｃｋ＿ｈｅｉｇｈｔによって表される矩形を、このトラックのサブピクチャ矩形と呼ぶ。
【００７２】
同じサブピクチャコンポジショントラックグループに属し、同じ代替グループに属する（すなわち、同じ非ゼロのａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値を有する）全てのトラックについて、サブピクチャ矩形の位置及びサイズは、それぞれ同一であるものとする。
【００７３】
サブピクチャコンポジショントラックグループのコンポジションピクチャは、以下のように導出される。
１）サブピクチャコンポジショントラックグループに属する全てのトラックから、各代替グループからの１つのトラックを選択する。
２）選択されたトラックごとに、以下を適用する。
ａ．０〜ｔｒａｃｋ＿ｗｉｄｔｈ−１（両端値を含む）の範囲のｉの各値について、及び０〜ｔｒａｃｋ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲のｊの各値について、輝度サンプル位置（（ｉ＋ｔｒａｃｋ＿ｘ）％ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、（ｊ＋ｔｒａｃｋ＿ｙ））が、輝度サンプル位置（ｉ、ｊ）におけるこのトラックのサブピクチャの輝度サンプルと等しくなるように設定される。
ｂ．復号化されたピクチャが４：０：０以外の色差フォーマットを有する場合、色差成分はそれに応じて導出される。
同じサブピクチャコンポジショントラックグループに属し、異なる代替グループに属する（すなわち、ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐが０である又はａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値が異なる）全てのトラックのサブピクチャ矩形は、重複せず、間隙を有しないものとし、コンポジションピクチャの上記導出プロセスでは、各輝度サンプル位置（ｘ、ｙ）（ここで、ｘは、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ−１（両端値を含む）の範囲）であり、ｙは、０〜ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔ−１（両端値を含む）の範囲）が、１回だけトラバースされる。
【００７４】
一実施例では、サブピクチャ領域ボックスは、以下のシンタックスに基づくことができる。
シンタックス
【表１１】
2021520711.tif 000014
他の実施例では、ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔの上記１つ以上のビットフィールド幅が、３２ビットの代わりに１６ビットであってもよい。
【００７５】
ここで、ｔｒａｃｋ＿ｘ、ｔｒａｃｋ＿ｙ、ｔｒａｃｋ＿ｗｉｄｔｈ、ｔｒａｃｋ＿ｈｅｉｇｈｔ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔのセマンティクスは上記の例に基づくことができ、ｃｏｍｐｏｓｉｔｉｏｎ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇのセマンティクスは以下に基づいている。
１に等しいｃｏｍｐｏｓｉｔｉｏｎ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、シンタックス要素ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔがこのボックスに存在することを指定する。０に等しいｃｏｍｐｏｓｉｔｉｏｎ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、シンタックス要素ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔがこのボックスに存在しないことを指定する。
Ｈａｎｎｕｋｓｅｌａに対して、本明細書に記載される技術によるサブピクチャ領域ボックスでは、サブピクチャコンポジショントラックグループ化のためのＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのシンタックス要素のビット幅が１６ビットから３２ビットに増加すること、サブピクチャコンポジショントラックグループ化のためのＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのトラック幅とトラックの高さのシンタックス要素の制約が緩和され、より多くの値が可能になること、サブピクチャコンポジショントラックグループ化のためのＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘのコンポジション幅及びコンポジション高さのシンタックス要素に新しい制約が提案されること、及びトラック高さの制約が変更され、サブピクチャコンポジショントラックグループの構成ピクチャの導出が変更されることに留意されたい。ＭＰＥＧ−Ｉではトップボトムシームスパンニングがサポートされていないため、これらの変更が、ＭＰＥＧ−Ｉとの全体的な機能的整合をもたらすことに留意されたい。
【００７６】
更に、Ｈａｎｎｕｋｓｅｌａに対して、本明細書に記載される技術によるサブピクチャ領域ボックスでは、サブピクチャコンポジショントラックグループ化が、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｔｙｐｅ’ｓｐｃｏ’及び同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を持つＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘによって示される場合、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値のスペースを分割して、あるコンポジションに属するサブピクチャトラックが、左ビューのみ、右ビューのみ、又は左及び右の両方のビューのコンテンツを含むかどうかを示すことが提案される。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値のスペースのこのような分割により、プレイヤはＳｕｂＰｉｃｔｕｒｅＲｅｇｉｏｎＢｏｘ及びＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘのパースを回避して、サブピクチャトラック及び結果的なコンポジションが属するビューに関する情報を判定することができる。代わりに、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を単にパースして、これを学習することができる。他の実施例では、ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値範囲のスペースを分割して、将来の拡張性をサポート。
【００７７】
更に、Ｈａｎｎｕｋｓｅｌａに対して、本明細書に記載される技術によるサブピクチャ領域ボックスでは、シンタックス変更及びフラグを使用して、ただ１つのインスタンスにおいて又は同じｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を有するＳｕｂＰｉｃｔｕｒｅＣｏｍｐｏｓｉｔｉｏｎＢｏｘの少なくとも１つのインスタンスにおいて、ｃｏｍｐｏｓｉｔｉｏｎ＿ｗｉｄｔｈ及びｃｏｍｐｏｓｉｔｉｏｎ＿ｈｅｉｇｈｔシンタックス要素をシグナリングすることが、ビットの節約をもたらす。
【００７８】
ＯＭＡＦバージョン２／ＯＭＡＦ修正のための新しいＤＡＳＨ要素及び属性を含む新しいＸＭＬスキーマを定義するために、新しいＸＭＬ名前空間を使用することが提案される。これにより、完全な後方互換性のある設計が提供されると断言される。これは、以下のように指定され得る。
ｘ．ｙ  ＸＭＬ名前空間及びスキーマ：
多数の新たなＸＭＬ要素及び属性が定義され、使用される。これらの新しいＸＭＬ要素は、別個の名前空間「ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８」において定義される。これらは、各セクション内の規定のスキーマ文書内に定義されている。名前空間指定子「ｘｓ：」は、「ＸＭＬ  Ｓｃｈｅｍａ  Ｐａｒｔ  １：Ｓｔｒｕｃｔｕｒｅｓ  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ」（Ｗ３Ｃ推奨、２００４年１０月２８日）に定義された名前空間ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａに対応するものとする。
「ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌｓｃｈｅｍａ−１／」本文書の各表の「データ型」列の項目は、ＸＭＬ  Ｓｃｈｅｍａ  Ｐａｒｔ  ２に定義されたデータタイプを使用し、「ＸＭＬ  Ｓｃｈｅｍａ  Ｐａｒｔ  ２：Ｄａｔａｔｙｐｅｓ  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ」（Ｗ３Ｃ推奨、２００４年１０月２８日）に定義された意味を有するものとする。
「ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌｓｃｈｅｍａ−２／」
上述したように、Ｈａｎｎｕｋｓｅｌａにおいて提供される＠ｓｐａｔｉａｌＳｅｔＩｄ属性をあるアダプテーションセットレベルで使用して、同じサブピクチャコンポジショントラックグループに属するアダプテーションセットをグループ化することには、各アダプテーションセットは１つのサブピクチャコンポジショングループのみに属することができるという制限がある。一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、サブピクチャコンポジション識別子要素をシグナリングするように構成され得る。一実施例では、サブピクチャコンポジション識別子要素は、表２に提供される例に基づいてもよい。
【００７９】
【表１２】
2021520711.tif 000015
一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素の子要素としてシグナリングされてもよい。一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素の子要素としてシグナリングされてもよい。一実施例では、複数のＳｕｂＰｉｃＣｏｍｐＩｄ要素が１つのＡｄａｐｔａｔｉｏｎＳｅｔ要素内に存在し、１つのアダプテーションセットが複数の異なるサブピクチャコンポジションに属することを可能にしてもよい。一実施例では、複数のＳｕｂＰｉｃＣｏｍｐＩｄ要素がＡｄａｐｔａｔｉｏｎＳｅｔ要素内に存在する場合、それぞれは異なる値を有する必要がある。一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄは、存在しない場合、０に等しいと推測される。別の実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄが存在しない場合、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔは、サブピクチャではなく、またサブピクチャコンポジションではない（又は属していない）こともある。この場合、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔは、提示のみのために選択されてもよい。ＳｕｂＰｉｃＣｏｍｐＩｄのデータ型は、ＸＭＬスキーマ内に定義されたとおりであってもよい。図１０は、表２に示される例示的なＳｕｂＰｉｃＣｏｍｐＩｄに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。一実施例では、図１０のスキーマ内のｓｕｂＰｉｃＣｏｍｐＰｉｄ要素は、代わりに以下の通りであってもよい。
＜ｘｓ：ｅｌｅｍｅｎｔ  ｎａｍｅ＝”ＳｕｂＰｉｃＣｏｍｐＩｄ”  ｔｙｐｅ＝”ｘｓ：ｕｎｓｉｇｎｅｄＳｈｏｒｔ”  ｍｉｎＯｃｃｕｒｓ＝”０”  ｍａｘＯｃｃｕｒｓ＝”ｕｎｂｏｕｎｄｅｄ”／＞
一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄ要素は、代わりに、表２Ａに示すように、ＳｐａｔｉａｌＳｅｔＩｄ要素と呼ぶこともある。
【００８０】
【表１３】
2021520711.tif 000016
複数のＳｐａｔｉａｌＳｅｔＩｄ要素がＡｄａｐｔａｔｉｏｎＳｅｔ要素内に存在し、１つのアダプテーションセットが複数の異なるサブピクチャコンポジションに属することを可能にしてもよい。複数のＳｐａｔｉａｌＳｅｔＩｄ要素がＡｄａｐｔａｔｉｏｎＳｅｔ要素内に存在する場合、それぞれは異なる値を有する必要がある。その要素のデータ型は、ＸＭＬスキーマ内に定義されたとおりであるものとする。この要素のＸＭＬスキーマは、以下に示すとおりとする。規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有するＸＭＬスキーマで表されるものとし、以下のように指定される。
【表１４】
2021520711.tif 000017
一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄ要素又はＳｐａｔｉａｌＳｅｔＩｄ要素のデータ型は、ｘｓ：ｕｎｓｉｇｎｅｄＳｈｏｒｔのデータ型の代わりに、ｘｓ：ｕｎｓｉｇｎｅｄＩｎｔ、又はｘｓ：ｕｎｓｉｇｎｅｄＢｙｔｅ、又はｘｓ：ｕｎｓｉｇｎｅｄＬｏｎｇ、又はｘｓ：ｓｔｒｉｎｇであってもよい。
【００８１】
一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、変更されたサブピクチャコンポジション識別子属性である＠ＳｕｂＰｉｃＣｏｍｐＩｄをシグナリングするように構成することができ、ここで＠ＳｕｂＰｉｃＣｏｍｐＩｄは、１０進表記の非負の整数からｕｎｓｉｇｎｅｄＳｈｏｒｔのリストに変更されている。そのリストを使用することで複数の空間セット識別子を１つのアダプテーションセットと関連付けることができることに留意されたい。一実施例では、サブピクチャコンポジション識別子属性は、表３に提供される例に基づいてもよい。
【００８２】
【表１５】
2021520711.tif 000018
一実施例では、＠ＳｕｂＰｉｃＣｏｍｐＩｄは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素の属性としてシグナリングされてもよい。一実施例では、＠ＳｕｂＰｉｃＣｏｍｐＩｄ要素は、ＡｄａｐｔａｔｉｏｎＳｅｔ要素及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素の属性としてシグナリングされてもよい。別の実施例では、属性ｏｍａｆ２：＠ｓｕｂＰｉｃＣｏｍｐＩｄが存在しない場合、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔは、サブピクチャではなく、またサブピクチャコンポジションではない（又は属していない）こともある。この場合、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔは、提示のみのために選択されてもよい。＠ｓｕｂＰｉｃＣｏｍｐＩｄのデータ型は、ＸＭＬスキーマ内に定義されたとおりであってもよい。図１１は、表３に示される例示的な＠ｓｕｂＰｉｃＣｏｍｐＩｄに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【００８３】
一実施例では、＠ｓｕｂＰｉｃＣｏｍｐＩｄ属性は、代わりに、表３Ａに示すように、＠ｓｐａｔｉａｌＳｅｔＩｄ要素と呼ぶこともある。
【００８４】
【表１６】
2021520711.tif 000019
一実施例では、＠ｓｕｂＰｉｃＣｏｍｐＩｄ属性又は＠ｓｐａｔｉａｌＳｅｔＩｄ属性のデータ型は、ｘｓ：ｕｎｓｉｇｎｅｄＳｈｏｒｔのデータ型の代わりに、ｘｓ：ｕｎｓｉｇｎｅｄＩｎｔのリスト、又はｘｓ：ｕｎｓｉｇｎｅｄＢｙｔｅのリスト、又はｘｓ：ｕｎｓｉｇｎｅｄＬｏｎｇのリスト、又はｘｓ：ｓｔｒｉｎｇのリストであってもよい。
【００８５】
一実施例では、＠ｓｐａｔｉａｌＳｅｔＩｄ属性は、表３Ｂに示されるようなｕｎｓｉｇｎｅｄＳｈｏｒｔのデータ型を有し得る。
【００８６】
【表１７】
2021520711.tif 000020
この場合、＠ｓｐａｔｉａｌＩｄ属性のＸＭＬスキーマは、以下の通りとすることができる。
【表１８】
2021520711.tif 000021
上記の表３Ｂに関する別の実施例では、ｏｍａｆ２：＠ｓｐａｔｉａｌＳｅｔＩｄのデータ型は、ｕｎｓｉｇｎｅｄＳｈｏｒｔの代わりに、ｕｎｓｉｇｎｅｄＢｙｔｅ、又はｕｎｓｉｇｎｅｄＩｎｔ、又はｕｎｓｉｇｎｅｄＬｏｎｇ、又はｓｔｒｉｎｇであってもよい。
【００８７】
一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、属性をシグナリングして、サブピクチャコンポジションに属する特定のアダプテーションセットはエンドユーザへの提示のために単独で選択されることを意図するものではないことを示すように構成することができる。ＩＳＯＢＭＦＦファイルでは、トラックを単独で提示されるものではないと指定することができる。また、ＤＡＳＨでは、ＡｄａｐｔａｔｉｏｎＳｅｔは、ＤＡＳＨクライアントによって独立して選択されてもよい。しかしながら、複数のアダプテーションセットがサブピクチャコンポジションを形成する場合、アダプテーションセットの独立した選択は防止されるべきである。一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、属性をシグナリングして、サブピクチャコンポジションに属する特定のアダプテーションセットはエンドユーザへの提示のために単独で選択されることを意図するものではないことを示すように構成することができる。一実施例では、この属性は、ＡｄａｐｔａｔｉｏｎＳｅｔ要素の属性としてアダプテーションセットレベルで存在する任意選択の属性であってもよい。一実施例では、この属性は、表４に提供される例に基づいてもよい。
【００８８】
【表１９】
2021520711.tif 000022
一実施例では、属性＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅは、代わりに、＠ｎｏＳｉｎｇｌｅＳｅｌｅｃｔｉｏｎ、又は＠ｎｏｔＦｏｒＳｉｎｇｌｅＳｅｌｅｃｔｉｏｎ、又はいくつかの他の同様の名前で呼ぶこともある。図１２は、表４に示される例示的な＠ＳｕｂＰｉｃＣｏｍｐＩｄに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【００８９】
一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、属性をシグナリングして、あるサブピクチャコンポジションに属する特定のアダプテーションセットは、エンドユーザへの提示のために単独で選択されることを意図するものではないことを示すように構成することができ、ここで、この属性は、表２に関して上記したＳｕｂＰｉｃＣｏｍｐＩｄ要素の属性である。一実施例では、この属性は、ＳｕｂＰｉｃＣｏｍｐＩｄ要素の属性としてアダプテーションセットレベルで存在する任意選択の属性であってもよい。一実施例では、この属性は、表５に提供される例に基づいてもよい。
【００９０】
【表２０】
2021520711.tif 000023
図１３は、表５に示される例示的な＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。図１３及び表５に関する一実施例では、ＳｕｂＰｉｃＣｏｍｐＩｄの全ての出現箇所をＳｐａｔｉａｌＳｅｔＩｄと置き換えてもよい。したがって、ｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅ属性は、表２Ａに関して上述したＳｐａｔｉａｌＳｅｔＩｄ要素の属性としてシグナリングされてもよい。
【００９１】
一実施例では、アダプテーションの選択及び提示に関する２つの可能な値のみを指定することができるブールデータ型をｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅに使用する代わりに、単一選択に関して３つの値を指定することができるデータ型を使用することができる。一実施例では、３つの値は、それぞれ、（１）アダプテーションセットは、単独で選択及び提示されることを意図するものではないこと、（２）アダプテーションセットは、単独で選択及び提示されることに関していかなる制限も有しないこと、及び（３）アダプテーションセットは、単独で選択及び提示されてもよく、されなくてもよいことを指定することができる。一実施例では、この場合、属性ｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅは、表６に提供される例に基づいてもよい。
【００９２】
【表２１】
2021520711.tif 000024
図１４は、表６に示される例示的な＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【００９３】
一実施例では、この場合、属性ｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅは、表７に提供される例に基づいていてもよく、ｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅは、ＳｕｂＰｉｃＣｏｍｐＩｄ要素の属性としてアダプテーションセットレベルで存在してもよい。
【００９４】
【表２２】
2021520711.tif 000025
図１５は、表７に示される例示的な＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅに対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。一実施例では、図１５及び表７に関して、ＳｕｂＰｉｃＣｏｍｐＩｄの全ての出現箇所をＳｐａｔｉａｌＳｅｔＩｄと置き換えてもよい。したがって、ｏｍａｆ２：＠ｎｏｔＩｎｔｅｎｄｅｄＦｏｒＳｅｌｅｃｔｉｏｎＡｌｏｎｅ属性は、表２Ａに関して上述したＳｐａｔｉａｌＳｅｔＩｄ要素の属性としてシグナリングされてもよい。
【００９５】
上記の実施例に関して、場合によっては、ＳｕｂＰｉｃＣｏｍｐＩｄは、代わりに、ＯｍｎｉＶｉｄｅｏＳｅｑｕｅｎｃｅＩｄ、又はＯｄｓｒＩｄ、又は類似の名前で呼ぶことができる。一実施例では、ｕｎｓｉｇｎｅｄＳｈｏｒｔの代わりに、データ型ｕｎｓｉｇｎｅｄＢｙｔｅをＳｕｂＰｉｃＣｏｍｐＩｄ要素に使用してもよい。一実施例では、ｕｎｓｉｇｎｅｄＳｈｏｒｔの代わりに、データ型ｕｎｓｉｇｎｅｄＩｎｔをＳｕｂＰｉｃＣｏｍｐＩｄ要素に使用してもよい。一実施例では、ｕｎｓｉｇｎｅｄＳｈｏｒｔのリストの代わりに、ｕｎｓｉｇｎｅｄＢｙｔｅのデータ型リストを＠ｓｕｂＰｉｃＣｏｍｐＩｄ属性に使用してもよい。一実施例では、ｕｎｓｉｇｎｅｄＳｈｏｒｔのリストの代わりに、ｕｎｓｉｇｎｅｄＩｎｔのデータ型リストを＠ｓｕｂＰｉｃＣｏｍｐＩｄ属性に使用してもよい。
【００９６】
ここで、サブピクチャコンポジションのＤＡＳＨシグナリングの別の態様を説明する。この態様は、ＤＡＳＨにカプセル化された時限メタデータとＤＡＳＨのメディア情報との関連付けに関する。これに関して、従来技術の手法では、時限メタデータトラックは、ＤＡＳＨリプレゼンテーションにカプセル化することができ、このリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＩｄには、時限メタデータトラックに関連付けられたメディアトラックを含むリプレゼンテーションの＠ｉｄ属性が含まれるとする。しかしながら、この関連付け方法は、サブピクチャコンポジションとの関連付けには不十分な場合がある。
【００９７】
したがって、時限メタデータがカプセル化されたＤＡＳＨリプレゼンテーションをサブピクチャコンポジションに対応する複数のアダプテーションセットに関連付けるための手法が提案される。このための２つの代替オプションについて説明する。
【００９８】
オプション１：１つ以上のサブピクチャコンポジションを時限メタデータＤＡＳＨリプレゼンテーションと関連付けるために、新しい＠ｒｅｆｅｒｅｎｃｅＩｄｓ属性をＡｄａｐｔａｔｉｏｎ  Ｓｅｔ及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングすることが提案される。
【００９９】
オプション２：＠ａｓｓｏｃｉａｔｉｏｎＩｄ内の複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値をシグナリングして、ＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにカプセル化された時限メタデータとサブピクチャコンポジションとの関連付けを示すことが提案される。
【０１００】
サブピクチャを符号化し、Ｐｅｒｉｏｄ内の複数のＡｄａｐｔａｔｉｏｎ  Ｓｅｔとしてシグナリングする場合、時限メタデータカプセル化ＤＡＳＨリプレゼンテーションを、個々のサブピクチャではなく、全体としてのサブピクチャコンポジションと関連付けるために効率的な機構が必要である。更に、この場合、あるサブピクチャについてのＡｄａｐｔａｔｉｏｎ  Ｓｅｔには、多くの場合、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎが含まれ得、そのような複数のＡｄａｐｔａｔｉｏｎ  Ｓｅｔが、サブピクチャコンポジション全体に対応する。したがって、１つ以上のサブピクチャコンポジションを時限メタデータＤＡＳＨリプレゼンテーションと関連付けるために、新しい＠ｒｅｆｅｒｅｎｃｅＩｄｓ属性をＡｄａｐｔａｔｉｏｎ  Ｓｅｔ及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングすることが提案される。
【０１０１】
また、ＤＡＳＨリプレゼンテーションにカプセル化された１つの時限メタデータトラックと複数のメディアトラックとの間のシグナリング関連付けを可能にすることも提案されている。複数のメディアリプレゼンテーションが、同じ時限メタデータトラックに関連付けられてもよく、このように、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値を１つの時限メタデータトラックと関連付けることは、より効率的であるので、可能である必要がある。例えば、最初のビューイング方位時限メタデータは、異なるビットレートで符号化された複数のＤＡＳＨリプレゼンテーションを有する１つの全方位ビデオについて同じとすることができる。同様に、１つのＤＡＳＨリプレゼンテーションにカプセル化された推奨ビューポート時限メタデータは、異なるビットレートで符号化された複数のＤＡＳＨリプレゼンテーションと関連付けられることが必要である。したがって、ＤＡＳＨリプレゼンテーションにカプセル化された１つの時限メタデータトラックと複数のメディアトラックと間のシグナリング関連付けを可能にすることが提案されている。
【０１０２】
次に、オプション１について説明する。
１つ以上のサブピクチャコンポジションを時限メタデータＤＡＳＨリプレゼンテーションと関連付けるために、新しい＠ｒｅｆｅｒｅｎｃｅＩｄｓ属性をＡｄａｐｔａｔｉｏｎ  Ｓｅｔ及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングすることが提案される。
＠ｒｅｆｅｒｅｎｃｅＩｄｓの値は値のリストであるものとし、ここで、このリスト内の各値は、この時限メタデータトラックがまとめて関連付けられているアダプテーションセットの＠ｓｐａｔｉａｌＳｅｔＩｄの値と等しい。
変形例では、＠ｒｅｆｅｒｅｎｃｅＩｄｓの値は、この時限メタデータトラックがめとめて関連付けられているサブピクチャコンポジションのアダプテーションセット要素内のＳｕｂＰｉｃＣｏｍｐＩｄ値の値のリストである。
変形例では、＠ｒｅｆｅｒｅｎｃｅＩｄｓの値は、値のリストであるものとし、このリストは、この時限メタデータトラックがまとめて関連付けられているサブピクチャコンポジションのアダプテーションセット要素内の＠ＳｕｂＰｉｃＣｏｍｐＩｄからの値を含むものとする。
変形例では、＠ｒｅｆｅｒｅｎｃｅＩｄｓは、＠ａｓｓｏｃｉａｔｉｏｎＡｄａｐｔａｔｉｏｎＳｅｔＩｄｓと呼ばれることがある。
参照識別子属性である、＠ｒｅｆｅｒｅｎｃｅＩｄｓは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ及び／又はＡｄａｐｔａｔｉｏｎＳｅｔ要素の属性としてシグナリングされてもよい。これは、表８Ａに示すようにシグナリングされてもよい。
【表２３】
2021520711.tif 000026
属性のデータ型は、ＸＭＬスキーマ内に定義されたとおりであるものとする。この属性のＸＭＬスキーマは、以下に示すとおりとする。規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有するＸＭＬスキーマで表されるものとし、以下のように指定される。
【表２４】
2021520711.tif 000027
変形例では、データ型ｌｉｓｔＯｆＵｎｓｉｇｎｅｄＳｈｏｒｔの代わりに、他のデータ型が、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄ属性に使用される場合がある。これは以下を含む。
●次のようなｘｓ：ｕｎｓｉｇｎｅｄＢｙｔｅのｘｓ：ｌｉｓｔであるｌｉｓｔｏｆＵｎｓｉｇｎｅｄＢｙｔｅのデータ型を、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄに使用してもよい。
【表２５】
2021520711.tif 000028
●次のようなｘｓ：ｕｎｓｉｇｎｅｄｌｎｔのｘｓ：ｌｉｓｔであるｌｉｓｔｏｆＵｎｓｉｇｎｅｄｌｎｔのデータ型を、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄに使用してもよい。
【表２６】
2021520711.tif 000029
●次のようなｘｓ：ｓｔｒｉｎｇのｘｓ：ｌｉｓｔであるｌｉｓｔｏｆＳｔｒｉｎｇのデータ型を、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄに使用してもよい。
【表２７】
2021520711.tif 000030
変形例では、＠ｒｅｆｅｒｅｎｃｅＩｄｓは、＠ｒｅｆｅｒｅｎｃｅＳｐａｔｉａｌＩｄｓと呼ばれることがある。変形例では、＠ｒｅｆｅｒｅｎｃｅＩｄｓは、＠ａｓｓｏｃｉａｔｉｏｎＳｐａｔｉａｌＩｄｓ、又は＠ａｓｓｏｃｉａｔｉｏｎＡｄａｐｔａｔｉｏｎＳｅｔＩｄｓ、又は＠ａｓｓｏｃｉａｔｉｏｎＳｐＣｏｍｐＩｄｓと呼ばれることがある。
変形例では、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄｓのデータ型は、リストの代わりに１つの数又は文字列であってもよい。したがって、ｏｍａｆ２：＠ｒｅｆｅｒｅｎｃｅＩｄｓのデータ型は、ｕｎｓｉｇｎｅｄＳｈｏｒｔ、又はｕｎｓｉｇｎｅｄＢｙｔｅ、又はｕｎｓｉｇｎｅｄＩｎｔ、又は文字列であってもよい。
変形例では、ＲｅｆｅｒｅｎｃｅＩｄｓ要素（＠ｒｅｆｅｒｅｎｃｅＩｄｓ要素の代わり）は、ＡｄａｐｔａｔｉｏｎＳｅｔ要素及び／又はＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素の子要素としてシグナリングされることができる。
変形例では、追加の＠ｒｅｆｅｒｅｎｃｅＩｄＴｙｐｅが、表９Ａに示すＲｅｐｒｅｓｅｎｔａｔｉｏｎ及び／又はＡｄａｐｔａｔｉｏｎＳｅｔ要素の属性としてシグナリングされてもよい。
【表２８】
2021520711.tif 000031
属性のデータ型は、ＸＭＬスキーマ内に定義されたとおりであるものとする。この属性のＸＭＬスキーマは、以下に示すとおりとする。規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有するＸＭＬスキーマで表されるものとし、以下のように指定される。
【表２９】
2021520711.tif 000032
オプション２を以下に記載する。
【０１０３】
オプション２では、＠ａｓｓｏｃｉａｔｉｏｎＩｄ内の複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値をシグナリングして、ＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにカプセル化された時限メタデータとサブピクチャコンポジションとの関連付けを示すことが提案される。
【０１０４】
提案されるテキストは、以下の通りである。
例えば、トラックサンプルエントリタイプ’ｉｎｖｏ’、’ｒｃｖｐ’、又は’ｔｔｓｌ’の時限メタデータトラックが、ＤＡＳＨプレゼンテーションにカプセル化され、サブピクチャコンポジション及び／又は全方位ビデオにまとめて関連付けられている場合、＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性には、全てのアダプテーションセット内の全てのＲｅｐｒｅｓｅｎｔａｔｉｏｎのＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄのリストが含まれるものとし、これらが全体としてサブピクチャコンポジション及び／又は全方位ビデオを形成し、対応する＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性値には、＠ａｓｓｏｃｉａｔｉｏｎＩｄリスト内のＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値の数と同じ数の’ｃｄｔｇ’値が含まれるものとする。
【０１０５】
この場合、＠ａｓｓｏｃｉａｔｉｏｎＩｄのリストを含む時限メタデータトラックは、リスト内で’ｃｄｔｇ’に等しい対応する＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ値を示すそれらの全てのリプレゼンテーションにまとめて適用されるものとする。
【０１０６】
更に、ＩＳＯ／ＩＥＣ  ＦＤＩＳ  ２３０９０−２に関して
複数のメディアリプレゼンテーションは、同じ時限メタデータトラックに関連付けられてもよく、このように、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄを１つの時限メタデータトラックと関連付けることは、より効率的であるので、可能にされる必要がある。例えば、最初のビューイング方位時限メタデータは、異なるビットレートで符号化された複数のＤＡＳＨリプレゼンテーションを有する１つの全方位ビデオについて同じとすることができる。同様に、１つのＤＡＳＨリプレゼンテーションにカプセル化された推奨ビューポート時限メタデータは、異なるビットレートで符号化された複数のＤＡＳＨリプレゼンテーションと関連付けられることが必要である。したがって、ＤＡＳＨリプレゼンテーションにカプセル化された１つの時限メタデータトラックと複数のメディアトラックと間のシグナリング関連付けを可能にすることが提案されている。
【０１０７】
したがって、以下の関連付けのタイプを使用することが提案される。
このメタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＩｄは、ＩＳＯ／ＩＥＣ  ＦＤＩＳ  ２３０９０−２の７．１．５．１節で指定されるように、時限メタデータトラックに関連付けられた、メディアトラックによって保持される全方位性メディアを含むリプレゼンテーションの属性Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄの１つ以上の値を含むものとする。このメタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性は、ＩＳＯ／ＩＥＣ  ＦＤＩＳ  ２３０９０−２．の７．１．５．１節で指定されるように、時限メタデータトラックがそれを介してメディアトラックに関連付けられるトラック参照タイプに等しい１つ以上の値を含むものとする。
【０１０８】
上述のように、ＤＡＳＨでは、Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、少なくとも１つの他のＲｅｐｒｅｓｅｎｔａｔｉｏｎに対する補足的又は記述的な情報を提供するＲｅｐｒｅｓｅｎｔａｔｉｏｎであり、Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性及び任意選択的に＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性を含むＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素の属性によって記述される。ＭＰＥＧ−Ｉは、ＤＡＳＨリプレゼンテーションにカプセル化され得る時限メタデータトラックを提供し、ここで、メタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性には、メディアトラックによって保持される全方位メディアを含むリプレゼンテーションの＠ｉｄ属性の１つ以上の値が含まれるものとし、それらの値は、’ｃｄｓｃ’トラック参照を介して時限メタデータトラックに関連付けられており、ここで、メタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性は’ｃｄｓｃ’と等しいものとする。
上述のように、ＭＰＥＧ−Ｉでは、トラックはグループ化されることができる。グループ化され得る参照するトラック（例えば、時限メタデータトラック）に対して、ＭＰＥＧ−Ｉは、ｔｒａｃｋ＿ＩＤｓについての以下のセマンティクスを提供する。
ｔｒａｃｋ＿ＩＤｓは、参照されるトラックのトラック識別子又は参照されるトラックグループのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を提供する整数の配列である。ｔｒａｃｋ＿ＩＤｓ［ｉ］の各値（ここで、ｉは、ｔｒａｃｋ＿ＩＤｓ［］アレイに対する有効なインデックスである）は、含まれているトラックから、ｔｒａｃｋ＿ＩＤｓ［ｉ］に等しいトラックＩＤを有するトラックへの、又はｔｒａｃｋ＿ＩＤｓ［ｉ］に等しいｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと、１に等しいＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘの（ｆｌａｇｓ＆１）とを有するトラックグループへの参照をもたらす整数である。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値が参照される場合、このトラック参照は、特定のトラック参照タイプのセマンティクスで特に明記されない限り、参照されるトラックグループの各トラックに個別に適用される。値０は存在しないものとする。所与の値は、アレイ内で複製されないものとする。
参照により本明細書に組み込まれる、Ｗａｎｇら（「Ｗａｎｇ」と呼ぶ）による、ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９  ／ＷＧ１１  ＭＰＥＧ２０１８／Ｍ４２４６０−ｖ２「［ＯＭＡＦ］  ［ＤＡＳＨ］  ［ＦＦ］  Ｅｆｆｉｃｉｅｎｔ  ＤＡＳＨ  ａｎｄ  Ｆｉｌｅ  Ｆｏｒｍａｔ  Ｏｂｊｅｃｔｓ  Ａｓｓｏｃｉａｔｉｏｎ」、２０１８年４月（サンディエゴ、米国）は、＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅという名前の任意選択の新しいリプレゼンテーションレベル属性を定義して、ＤＡＳＨオブジェクトのタイプ（それらについてのＩＤは＠ａｓｓｏｃｉａｔｉｏｎＩｄに含まれている）を示すことを提案しており、ここで、＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅの値が０、１、２、又は３に等しい場合、＠ａｓｓｏｃｉａｔｉｏｎＩｄの各値は、それぞれリプレゼンテーション、アダプテーションセット、ビューポイント、又は事前選択のＩＤであることを示し、＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅの３より大きい値は予備とされ、値が存在しない場合には、＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅの値は０と推測される。具体的には、Ｗａｎｇは、以下のテキストをＤＡＳＨに変更することを提案している。
Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性、任意選択で＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅ属性、及び任意選択で＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性を含む、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素によって記述される。Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎとは、他のＲｅｐｒｅｓｅｎｔａｔｉｏｎ、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ、Ｖｉｅｗｐｏｉｎｔ、又はＰｒｅｓｅｌｅｃｔｉｏｎとの関係に関する情報を提供するＲｅｐｒｅｓｅｎｔａｔｉｏｎである。Ａｓｓｏｃｉａｔｅｄ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのセグメントは、＠ａｓｓｏｃｉａｔｉｏｎＩｄ及び＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅによって識別されるＲｅｐｒｅｓｅｎｔａｔｉｏｎ、Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ、Ｖｉｅｗｐｏｉｎｔ、又はＰｒｅｓｅｌｅｃｔｉｏｎの復号化及び／又は提示のためのオプションであり得る。これらは補足的又は記述的な情報と見なすことができ、関連のタイプは＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性で指定される。
【０１０９】
注記−＠ａｓｓｏｃｉａｔｉｏｎＩｄ、０に等しい＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅ、＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅは同じＡｄａｐｔａｔｉｏｎ  ＳｅｔにないＲｅｐｒｅｓｅｎｔａｔｉｏｎ同士の間でのみ使用することができる。
【０１１０】
＠ａｓｓｏｃｉａｔｉｏｎＩｄ、＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅ、及び＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性は、表８において次のように定義される。
【表３０】
2021520711.tif 000033
Ｗａｎｇは、更に以下のテキストをＭＰＥＧ−Ｉに変更することを提案している。
例えば、トラックサンプルエントリタイプ’ｉｎｖｏ’又は’ｒｃｖｐ’の時限メタデータトラックは、ＤＡＳＨリプレゼンテーションにカプセル化することができる。
【０１１１】
このメタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅの値が０、１、２、又は３に等しいとき、このメタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＩｄ属性は、時限メタデータトラックに関連付けられたメディアトラックによって保持される全方位メディアをそれぞれ含む、リプレゼンテーション、アダプテーションセット、ビューポイント、又は事前選択のＩＤ値を含むものとする。このメタデータリプレゼンテーションの＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性は、’ｃｄｓｃ’とする。
【０１１２】
Ｗａｎｇのスキーム案は、以前のＤＡＳＨクライアントとの後方互換性がないことに注意されたい。これは、新しく提案された＠ａｓｓｏｃｉａｔｉｏｎＩｄＴｙｐｅ属性が１、２、又は３の場合、＠ａｓｓｏｃｉａｔｉｏｎＩｄの値が、以前のＤＡＳＨクライアントでは理解されないためであり、以前のＤＡＳＨクライアントは、＠ａｓｓｏｃｉａｔｉｏｎＩｄにおいて不明な＠ｉｄ値を検出することになり、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値のみを期待することになる。
【０１１３】
一実施例では、本明細書に記載される技術によれば、データカプセル化装置１０７は、２つの必須属性（ａｓｓｏｃｉａｔｉｏｎ＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＩｄＬｉｓｔ、ａｓｓｏｃｉａｔｉｏｎ＠ａｓｓｏｃｉａｔｉｏｎＫｉｎｄＬｉｓｔ）及び１つの任意選択の属性（ａｓｓｏｃｉａｔｉｏｎ＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅ）を有する１つ以上の関連要素を含む補足特性記述子をシグナリングするように構成され得る。任意選択の属性（ａｓｓｏｃｉａｔｉｏｎ＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅ）の値は、存在しない場合には、推測される。一実施例では、データカプセル化装置１０７は、以下の例示的な説明に基づいて、補足的特性記述子をシグナリングするように構成されてもよい。以下の説明に関して、一実施例では、単語「親要素」の１回以上の出現は、単語「この要素の記述子の親要素」と互換可能とすることができ、その逆も同様であることに留意されたい。
一実施例では、単語「この関連要素」の１つ以上の出現は、単語「この属性の関連要素」と互換可能とすることができ、逆もまた同様である。
【０１１４】
「ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：ａｓｓｏｃ：２０１８」と等しい＠ｓｃｈｅｍｅＩｄＵｒｉ属性を有するＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素は、関連記述子と呼ばれる。
【０１１５】
１つ以上の関連記述子が、アダプテーションセットレベル、リプレゼンテーションレベル、事前選択レベル、サブリプレゼンテーションレベルで存在してもよい。
【０１１６】
一実施例では、値０を有する属性ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅを含む関連記述子は、リプレゼンテーションレベルでは存在しないものとする。
【０１１７】
アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素内に含まれる関連記述子内の関連要素は、親要素（すなわち、アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素）が、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅ属性で示されるように、１つ以上のアダプテーションセット及び／又はリプレゼンテーション及び／又は事前選択及び／又はサブリプレゼンテーション要素に関連付けられていることを示し、これは、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＩｄＬｉｓｔによってシグナリングされる値のリストと、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＫｉｎｄＬｉｓｔによってシグナリングされる関連型とによって識別される。
【０１１８】
関連記述子の＠ｖａｌｕｅ属性は存在しないものとする。関連記述子は、表９に指定する属性を有する１つ以上の関連要素を含むものとする。
【表３１−１】
2021520711.tif 000034
【表３１−２】
2021520711.tif 000035
【表３１−３】
2021520711.tif 000036
図１６は、表９に示される例示的な関連記述子に対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【０１１９】
一実施例では、図１６のスキーマは、以下のように変更することができる。
【表３２】
2021520711.tif 000037
は、以下により置き換えられてもよい。
【表３３】
2021520711.tif 000038
一実施例では、データカプセル化装置１０７は、以下の例示的な説明に基づいて補足的特性記述子をシグナリングするように構成されてもよく、ここで、属性ａｓｓｏｃｉａｔｉｏｎ＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＩｄＬｉｓｔを使用する代わりに、ＩＤリストが、関連要素内でシグナリングされる。以下の説明に関して、一実施例では、単語「親要素」の１回以上の出現は、単語「この要素の記述子の親要素」と互換可能とすることができ、その逆も同様であることに留意されたい。一実施例では、単語「この関連要素」の１回以上の出現は、単語「この属性の関連要素」と互換可能とすることができ、逆もまた同様である。
【０１２０】
「ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：ａｓｓｏｃ：２０１８」と等しい＠ｓｃｈｅｍｅＩｄＵｒｉ属性を有するＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素は、関連記述子と呼ばれる。
【０１２１】
１つ以上の関連記述子が、アダプテーションセットレベル、リプレゼンテーションレベル、事前選択レベル、サブリプレゼンテーションレベルで存在してもよい。
【０１２２】
一実施例では、値０を有する属性ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅを含む関連記述子は、リプレゼンテーションレベルでは存在しないものとする。
【０１２３】
アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素内に含まれる関連記述子は、この要素の記述子の親要素（すなわち、アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素）が、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅ属性で示される、１つ以上のアダプテーションセット及び／又はリプレゼンテーション及び／又は事前選択及び／又はサブリプレゼンテーション要素に関連付けられていることを示し、これは、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＩｄＬｉｓｔによってシグナリングされる値のリストによって識別され、また関連要素の値のリストによって識別される。関連型は、ｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＫｉｎｄＬｉｓｔによってシグナリングされる。
【０１２４】
関連記述子の＠ｖａｌｕｅ属性は存在しないものとする。関連記述子は、表１０に指定する属性を有する１つ以上の関連要素を含むものとする。
【表３４−１】
2021520711.tif 000039
【表３４−２】
2021520711.tif 000040
図１７Ａは、表１０に示される例示的な関連記述子に対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。図１７Ｂは、表１０に示される例示的な関連記述子に対応する規定のＸＭＬスキーマの別の例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。図１７Ｂでは、データ型ｘｓ：ｕｎｓｉｇｎｅｄＢｙｔｅが、ａｓｓｏｃｉａｔｉｏｎＥｌｅｍｅｎｔＴｙｐｅに使用される。
【０１２５】
一実施例では、データカプセル化装置１０７は、以下の例示的な説明に基づいて補足的特性記述子をシグナリングするように構成されてもよく、ここで、ＸＰａｔｈ文字列は、同じ期間内のある要素と１つ以上の他の要素／属性との関連を指定するようにシグナリングされる。この実施例は、将来の拡張性及び特定性を可能にする。この実施例は、既存のＸＰａｔｈシンタックスも再使用する。ＸＰａｔｈは、Ｗ３Ｃで定義される。「ＸＭＬ  Ｐａｔｈ  Ｌａｎｇｕａｇｅ（ＸＰａｔｈ）」（Ｗ３Ｃ推奨、２０１０年１２月１４日）は、参照により本明細書に組み込まれる。上記の参照では、ＸＰａｔｈ  ２．０、ＸＰａｔｈの他のバージョン、例えばＸＰＡｔｈ  １．０又はＸＰａｔｈ  ３．０又はＸＰａｔｈのいくつかの将来のバージョンを使用してもよいことに留意されたい。以下の説明に関して、一実施例では、単語「親要素」の１回以上の出現は、単語「この要素の記述子の親要素」と互換可能とすることができ、その逆も同様であることに留意されたい。一実施例では、単語「この関連要素」の１つ以上の出現は、単語「この属性の関連要素」と互換可能とすることができ、逆もまた同様である。
「ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：ａｓｓｏｃ：２０１８」と等しい＠ｓｃｈｅｍｅＩｄＵｒｉ属性を有するＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素は、関連記述子と呼ばれる。
【０１２６】
１つ以上の関連記述子が、アダプテーションセットレベル、リプレゼンテーションレベル、事前選択レベル、サブリプレゼンテーションレベルで存在してもよい。
【０１２７】
アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素内に含まれる関連記述子は、親要素（すなわち、アダプテーションセット／リプレゼンテーション／事前選択／サブリプレゼンテーション要素）が、ｏｍａｆ２：ａｓｓｏｃｉａｔｉｏｎ要素におけるＸＰａｔｈクエリ及びｏｍａｆ２：＠ａｓｓｏｃｉａｔｉｏｎＫｉｎｄＬｉｓｔによってシグナリングされる関連型によって示される、ＭＰＤ内の１つ以上の要素に関連付けられる。
【０１２８】
関連記述子の＠ｖａｌｕｅ属性は存在しないものとする。関連記述子は、表１１に指定する属性を有する１つ以上の関連要素を含むものとする。
【表３５】
2021520711.tif 000041
図１８は、表１１に示される例示的な関連記述子に対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【０１２９】
一実施例では、要素Ａが、シグナリングされた関連型／種類を介して要素Ｂに関連付けられている場合、要素Ｂも、シグナリングされた同じ関連型／種類によって要素Ａと関連付けられている。別の実施例では、関連は方向性を有してもよい。したがって、関連要素を有する関連記述子が要素Ｃに含まれ、要素Ｃを要素Ｄ及びＥと関連付ける場合、要素Ｃは、シグナリングされた関連付け型／種類で要素Ｄ及びＥに関連付けられるが、要素Ｄ及びＥは、同じ方法で要素Ｃに関連付けられないことがある。
【０１３０】
別の実施例では、関連が一方向であるか双方向であるかを示すために、追加の属性が関連記述子にシグナリングされてもよい。例えば、関連が一方向であるか双方向であるかは、以下の表１２に示すようにシグナリングされてもよい。
【表３６】
2021520711.tif 000042
図１８は、表１２に示される例示的な関連記述子に対応する規定のＸＭＬスキーマの例を示し、ここで、規定のスキーマは、名前空間ｕｒｎ：ｍｐｅｇ：ｍｐｅｇＩ：ｏｍａｆ：２０１８を有する。
【０１３１】
本明細書に記載される例示的な関連記述子は、アダプテーションセット、リプレゼンテーションセット、及び／又は事前選択セットの集合を関連付けるときに、より簡潔なシグナリングを可能にすることに留意されたい。例えば、「／／ＡｄａｐｔａｔｉｏｎＳｅｔ」の関連をシグナリングすることによって、ａｓｓｏｃｉａｔｉｏｎＩｄｓ（例えば、１０２４、１０２５、１０２６、１０２７）の全てをシグナリングする必要がなくなる。更に、「／／ＡｄａｐｔａｔｉｏｎＳｅｔ／／Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ」の関連をシグナリングすることにより、処理が低減される。
【０１３２】
このようにして、データカプセル化装置１０７は、本明細書に記載された技術のうちの１つ以上に従って、仮想現実アプリケーションに関連付けられた情報をシグナリングするように構成されたデバイスの一例を表す。
【０１３３】
図１を再び参照すると、インターフェース１０８は、データカプセル化装置１０７によって生成されたデータを受信し、そのデータを通信媒体に送信及び／又は記憶するように構成された任意のデバイスを含んでもよい。インターフェース１０８は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を送信及び／若しくは受信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース１０８は、ファイルを記憶デバイス上に記憶することを可能にすることができるコンピュータシステムインターフェースを含むことができる。例えば、インターフェース１０８は、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）及びＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスプロトコル、独自のバスプロトコル、ユニバーサルシリアルバス（Universal Serial Bus、ＵＳＢ）プロトコル、Ｉ２Ｃ、又はピアデバイスを相互接続するために使用することができる任意の他の論理及び物理構造をサポートする、チップセットを含むことができる。
【０１３４】
図１を再び参照すると、目的デバイス１２０は、インターフェース１２２と、データ脱カプセル化装置１２３と、ビデオ復号装置１２４と、ディスプレイ１２６とを含む。インターフェース１２２は、通信媒体からデータ受信するように構成されている任意のデバイスを含むことができる。インターフェース１２２は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を受信及び／若しくは送信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース１２２は、適合したビデオビットストリームを記憶デバイスから取得することを可能にするコンピュータシステム用インターフェースを含むことができる。例えば、インターフェース１２２は、ＰＣＩ及びＰＣＩｅバスプロトコル、独自のバスプロトコル、ＵＳＢプロトコル、Ｉ２Ｃ、又はピアデバイスを相互接続するために使用することができる任意の他の論理及び物理構造をサポートする、チップセットを含むことができる。データデカプセル化部１２３は、データカプセル化部１０７によって生成されたビットストリームを受信し、本明細書に記載された技術のうちの１つ以上に従ってサブビットストリーム抽出を実行するように構成することができる。
【０１３５】
ビデオ復号装置１２４は、ビットストリーム及び／又はその許容可能な変形を受信し、それからビデオデータを再生するように構成されている任意のデバイスを含むことができる。ディスプレイ１２６は、ビデオデータを表示するように構成された任意のデバイスを含むことができる。ディスプレイ１２６は、液晶ディスプレイ（liquid crystal display、ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（organic light emitting diode、ＯＬＥＤ）ディスプレイ、又は別の種類のディスプレイなどの、様々なディスプレイデバイスのうちの１つを含むことができる。ディスプレイ１２６は、高解像度ディスプレイ又は超高解像度ディスプレイを含むことができる。ディスプレイ１２６は、ステレオスコープディスプレイを含んでもよい。図１に示す例では、ビデオ復号装置１２４は、データをディスプレイ１２６に出力するように説明されているが、ビデオ復号装置１２４は、ビデオデータを様々な種類のデバイス及び／又はそのサブコンポーネントに出力するように構成することができることに留意されたい。例えば、ビデオ復号装置１２４は、本明細書で説明するような任意の通信媒体にビデオデータを出力するように構成することができる。宛先デバイス１２０は、受信デバイスを含むことができる。
【０１３６】
図９は、本開示の１つ以上の技術を実装することができる受信デバイスの例を示すブロック図である。すなわち、受信デバイス６００は、上述のセマンティクスに基づいて信号をパースするように構成されてもよい。受信デバイス６００は、通信ネットワークからデータを受信し、仮想現実アプリケーションを含むマルチメディアコンテンツにユーザがアクセスすることを可能にするように構成され得る演算デバイスの一例である。図９に示す実施例では、受信デバイス６００は、例えば上述のテレビサービスネットワーク４０４などの、テレビネットワークを介してデータを受信するように構成されている。更に、図９に示す例では、受信デバイス６００は、ワイドエリアネットワークを介してデータを送受信するように構成されている。他の実施例では、受信デバイス６００は、テレビサービスネットワーク４０４を介して単にデータを受信するように構成されてもよいことに留意されたい。本明細書に記載された技術は、通信ネットワークのうちのいずれか及び全ての組み合わせを使用して通信するように構成されているデバイスによって利用され得る。
【０１３７】
図９に示すように、受信デバイス６００は、中央処理装置６０２、システムメモリ６０４、システムインターフェース６１０、データ抽出装置６１２、音声復号装置６１４、音声出力システム６１６、ビデオ復号装置６１８、表示システム６２０、Ｉ／Ｏデバイス６２２、及びネットワークインターフェース６２４を含む。図９に示すように、システムメモリ６０４は、オペレーティングシステム６０６及びアプリケーション６０８を含む。中央処理装置（単数又は複数）６０２、システムメモリ６０４、システムインターフェース６１０、データ抽出装置６１２、音声復号装置６１４、音声出力システム６１６、ビデオ復号装置６１８、表示システム６２０、Ｉ／Ｏデバイス（単数又は複数）６２２、及びネットワークインターフェース６２４の各々は、コンポーネント間通信のために（物理的、通信的、及び／又は動作的に）相互接続してもよく、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な好適な回路のいずれかとして実装することができる。受信デバイス６００は、別個の機能ブロックを有するものとして図示されているが、このような図示は、説明を目的としており、受信デバイス６００を特定のハードウェアアーキテクチャに限定しないという点に留意されたい。受信デバイス６００の機能は、ハードウェア実装、ファームウェア実装、及び／又はソフトウェア実装の任意の組み合わせを使用して実現することができる。
【０１３８】
ＣＰＵ（単数又は複数）６０２は、受信デバイス６００において実行するための機能及び／又はプロセス命令を実施するように構成されてもよい。ＣＰＵ（単数又は複数）６０２は、シングルコア及び／又はマルチコアの中央処理装置を含むことができる。ＣＰＵ（単数又は複数）６０２は、本明細書に記載された技術のうちの１つ以上を実施するための命令、コード、及び／又はデータ構造を検索及び処理することが可能であり得る。命令は、システムメモリ６０４などのコンピュータ可読媒体に記憶することができる。
【０１３９】
システムメモリ６０４は、非一時的又は有形のコンピュータ可読記憶媒体として説明することができる。いくつかの実施例では、システムメモリ６０４は、一時的及び／又は長期記憶部を提供することができる。いくつかの実施例では、システムメモリ６０４又はその一部は、不揮発性メモリとして記載されてもよく、別の実施例では、システムメモリ６０４の一部は、揮発性メモリとして記載されてもよい。システムメモリ６０４は、動作中に受信デバイス６００によって使用され得る情報を記憶するように構成されてもよい。システムメモリ６０４は、ＣＰＵ（単数又は複数）６０２によって実行するためのプログラム命令を記憶するために使用することができ、受信デバイス６００上で実行しているプログラムによって、プログラム実行中に情報を一時的に記憶するために使用されてもよい。更に、受信デバイス６００がデジタルビデオレコーダの一部として含まれる実施例では、システムメモリ６０４は、多数のビデオファイルを記憶するように構成されてもよい。
【０１４０】
アプリケーション６０８は、受信デバイス６００内で実施されるか又はそれによって実行されるアプリケーションを含むことができ、受信デバイス６００の構成要素内に実装されるか若しくは含まれ、それによって動作可能であり、それによって実行され、及び／又は動作的／通信的に結合され得る。アプリケーション６０８は、受信デバイス６００のＣＰＵ（単数又は複数）６０２に特定の機能を実行させることができる命令を含むことができる。アプリケーション６０８は、ｆｏｒループ、ｗｈｉｌｅループ、ｉｆステートメント、ｄｏループなどのコンピュータプログラミングステートメントで表現されたアルゴリズムを含むことができる。
アプリケーション６０８は、特定のプログラミング言語を使用して開発することができる。プログラミング言語の例としては、Ｊａｖａ（登録商標）、Ｊｉｎｉ（登録商標）、Ｃ、Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ  Ｃ、Ｓｗｉｆｔ、Ｐｅｒｌ（登録商標）、Ｐｙｔｈｏｎ（登録商標）、ＰｈＰ、ＵＮＩＸ（登録商標）  Ｓｈｅｌｌ、Ｖｉｓｕａｌ  Ｂａｓｉｃ、及びＶｉｓｕａｌ  Ｂａｓｉｃ  Ｓｃｒｉｐｔが挙げられる。受信デバイス６００がスマートテレビを含む実施例では、テレビ製造業者又は放送局によってアプリケーションが開発されてもよい。図９に示すように、アプリケーション６０８は、オペレーティングシステム６０６と連携して実行することができる。すなわち、オペレーティングシステム６０６は、受信デバイス６００のＣＰＵ（単数又は複数）６０２及び他のハードウェアコンポーネントとのアプリケーション６０８のインタラクションを容易にするように構成されてもよい。オペレーティングシステム６０６は、セットトップボックス、デジタルビデオレコーダ、テレビなどにインストールされるように設計されたオペレーティングシステムであってよい。本明細書に記載された技術は、ソフトウェアアーキテクチャのいずれか及び全ての組み合わせを使用して動作するように構成されたデバイスによって利用され得ることに留意されたい。
【０１４１】
システムインターフェース６１０は、受信デバイス６００の構成要素間で通信できるように構成されてもよい。一実施例では、システムインターフェース６１０は、あるピアデバイスから別のピアデバイス又は記憶媒体にデータを転送することを可能にする構造を含む。例えば、システムインターフェース６１０は、アクセラレーテッドグラフィックスポート（Accelerated Graphics Port、ＡＧＰ）ベースプロトコル、例えば、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｓｐｅｃｉａｌ  Ｉｎｔｅｒｅｓｔ  Ｇｒｏｕｐによって管理されたＰＣＩ  Ｅｘｐｒｅｓｓ（登録商標）（ＰＣＩｅ）バス仕様などのペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect、ＰＣＩ）バスベースプロトコル、又はピアデバイスと相互接続するのに使用することができる任意の他の形態の構造（例えば、独自のバスプロトコル）に対応するチップセットを含むことができる。
【０１４２】
上述のように、受信デバイス６００は、テレビサービスネットワークを介してデータを受信し、任意選択的に送信するように構成されている。上述のように、テレビサービスネットワークは、電気通信規格に従って動作することができる。電気通信規格は、例えば、物理シグナリング、アドレス指定、チャネルアクセス制御、パケット特性、及びデータ処理などの通信特性（例えば、プロトコル層）を定義することができる。図９に示す例では、データ抽出装置６１２は、信号からビデオ、音声、及びデータを抽出するように構成されてもよい。信号は、例えば、態様ＤＶＢ規格、ＡＴＳＣ規格、ＩＳＤＢ規格、ＤＴＭＢ規格、ＤＭＢ規格、及びＤＯＣＳＩＳ規格に従って定義され得る。
【０１４３】
データ抽出装置６１２は、信号からビデオ、音声、及びデータを抽出するように構成されてもよい。すなわち、データ抽出装置６１２は、サービス配信エンジンに対して相互的な方法で動作することができる。更に、データ抽出装置６１２は、上述の構造のうちの１つ以上の任意の組み合わせに基づいて、リンク層パケットをパースするように構成されてもよい。
【０１４４】
データパケットは、ＣＰＵ（単数又は複数）６０２、音声復号装置６１４、及びビデオ復号装置６１８によって処理されてもよい。音声復号装置６１４は、音声パケットを受信及び処理するように構成されてもよい。例えば、音声復号装置６１４は、音声コーデックの態様を実施するように構成されているハードウェア及びソフトウェアの組み合わせを含むことができる。すなわち、音声復号装置６１４は、音声パケットを受信して、レンダリングのために音声出力システム６１６に音声データを提供するように構成されてもよい。音声データは、Ｄｏｌｂｙ及びＤｉｇｉｔａｌ  Ｔｈｅａｔｅｒ  Ｓｙｓｔｅｍｓによって開発されたものなどのマルチチャネルフォーマットを使用して、符号化されてもよい。音声データは、音声圧縮フォーマットを使用して符号化されてもよい。音声圧縮フォーマットの例としては、Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）フォーマット、先進的音響符号化（Advanced Audio Coding、ＡＡＣ）フォーマット、ＤＴＳ−ＨＤフォーマット、及びドルビーデジタル（ＡＣ−３）フォーマットが挙げられる。音声出力システム６１６は、音声データをレンダリングするように構成されてもよい。例えば、音声出力システム６１６は、音声プロセッサ、デジタル／アナログ変換装置、増幅器、及びスピーカシステムを含むことができる。スピーカシステムは、ヘッドホン、統合ステレオスピーカシステム、マルチスピーカシステム、又はサラウンドサウンドシステムなどの様々なスピーカシステムのいずれかを含むことができる。
【０１４５】
ビデオ復号装置６１８は、ビデオパケットを受信及び処理するように構成されてもよい。例えば、ビデオ復号装置６１８は、ビデオコーデックの態様を実施するように使用されるハードウェア及びソフトウェアの組み合わせを含むことができる。一例では、ビデオ復号装置６１８は、ＩＴＵ−Ｔ  Ｈ．２６２又はＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６４（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）としても知られている）、及びＨｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＨＥＶＣ）などの任意の数のビデオ圧縮規格に従って符号化されたビデオデータを復号化するように構成されてもよい。表示システム６２０は、表示のためにビデオデータを検索及び処理するように構成されてもよい。例えば、表示システム６２０は、ビデオ復号装置６１８から画素データを受信し、ビジュアルプレゼンテーションのためにデータを出力することができる。更に、表示システム６２０は、ビデオデータと関連するグラフィックス（例えば、グラフィカルユーザインターフェース）を出力するように構成されてもよい。表示システム６２０は、液晶ディスプレイ（liquid crystal display、ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（organic light emitting diode、ＯＬＥＤ）ディスプレイ、又はビデオデータをユーザに提示することができる別のタイプのディスプレイデバイスなどの様々な表示デバイスのうちの１つを含むことができる。表示デバイスは、標準精細度コンテンツ、高精細度コンテンツ、又は超高精度コンテンツを表示するように構成されてもよい。
【０１４６】
Ｉ／Ｏデバイス（単数又は複数）６２２は、受信デバイス６００の動作中に入力を受信し、出力を提供するように構成されてもよい。すなわち、Ｉ／Ｏデバイス（単数又は複数）６２２は、レンダリングされるマルチメディアコンテンツをユーザが選択できるようにする。入力は、例えば、押しボタン式リモートコントロール、タッチ感知スクリーンを含むデバイス、モーションベースの入力デバイス、音声ベースの入力デバイス、又はユーザ入力を受信するように構成された任意の他のタイプのデバイスなどの入力デバイスから生成され得る。Ｉ／Ｏデバイス（単数又は複数）６２２は、例えば、ユニバーサルシリアルバスプロトコル（Universal Serial Bus、ＵＳＢ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）などの規格化された通信プロトコル、又は例えば、独自の赤外線通信プロトコルなどの独自の通信プロトコルを使用して、受信デバイス６００に動作可能に結合され得る。
【０１４７】
ネットワークインターフェース６２４は、受信デバイス６００がローカルエリアネットワーク及び／又はワイドエリアネットワークを介してデータを送信及び受信できるように構成されてもよい。ネットワークインターフェース６２４は、Ｅｔｈｅｒｎｅｔ（登録商標）カードなどのネットワークインターフェースカード、光トランシーバ、無線周波数トランシーバ、又は情報を送信及び受信するように構成された任意の他の種類のデバイスを含むことができる。ネットワークインターフェース６２４は、ネットワークで利用される物理層及びメディアアクセス制御（Media Access Control、ＭＡＣ）層に従って、物理的シグナリング、アドレッシング、及びチャネルアクセス制御を実行するように構成されてもよい。受信機デバイス６００は、図８に関して上述した技術のいずれかに従って生成された信号をパースするように構成することができる。このようにして、受信機デバイス６００は、仮想現実アプリケーションに関連付けられた情報を含む１つ以上のシンタックス要素をパースするように構成されたデバイスの一例を表す。
【０１４８】
１つ以上の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせで実装することができる。ソフトウェアで実装される場合に、この機能は、コンピュータ可読媒体上の１つ以上の命令又はコードとして記憶するか又は伝送され、ハードウェアベースの処理部によって実行することができる。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、データ記憶媒体又は通信媒体などの有形の媒体に対応する、コンピュータ可読記憶媒体を含むことができる。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的な有形のコンピュータ可読記憶媒体、又は（２）信号又は搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示中に記載された技術の実現のための命令、コード、及び／又はデータ構造を取り出すために、１つ以上のコンピュータ又は１つ以上のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。
【０１４９】
一例として、非限定的に、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、又は他の光学ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、フラッシュメモリ、又は任意の他の媒体、すなわち命令又はデータ構造の形式で所望のプログラムコードを記憶するために使用可能であり、かつコンピュータによりアクセス可能な任意の他の媒体を含むことができる。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。例えば、命令がウェブサイト、サーバ、又は他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（digital subscriber line、ＤＳＬ）、あるいは赤外線、無線及びマイクロ波などの無線技術を使用して伝送される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、あるいは赤外線、無線及びマイクロ波などの無線技術は、媒体の定義に含まれる。しかし、コンピュータ可読媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一過性媒体を含まないが、代わりに非一時的な有形記憶媒体を対象としていることを理解すべきである。本発明で使用する場合、ディスク（disk）及びディスク（disc）は、コンパクトディスク（Compact Disc、ＣＤ）、レーザーディスク（laser disc）、光学ディスク（optical disc）、デジタル多用途ディスク（Digital Versatile Disc、ＤＶＤ）、フロッピーディスク（floppy disk）及びブルーレイ（登録商標）ディスク（Blu-ray（登録商標）disc）を含み、ディスク（disk）は通常データを磁気的に再生し、ディスク（disc）はレーザを用いてデータを光学的に再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれなければならない。
【０１５０】
命令は、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は他の同等の集積又はディスクリートロジック回路などの１つ以上のプロセッサによって実行することができる。したがって、本明細書で使用されるとき、用語「プロセッサ」は、前記の構造、又は本明細書で説明する技術の実装に好適な任意の他の構造のいずれかを指すことができる。加えて、いくつかの態様において、本明細書に記載の機能は、符号化及び復号化するように構成された、又は複合コーデックに組み込まれた専用のハードウェアモジュール及び／又はソフトウェアモジュール内に設けられ得る。また、この技術は、１つ以上の回路又は論理素子中に完全に実装することができる。
【０１５１】
本開示の技術は、無線ハンドセット、集積回路（integrated circuit、ＩＣ）、又はＩＣのセット（例えば、チップセット）を含む多種多様なデバイス又は装置に実装することができる。様々なコンポーネント、モジュール、又はユニットは、開示された技術を実行するように構成されたデバイスの機能的な態様を強調するために本開示中に記載されているが、異なるハードウェアユニットによる実現は必ずしも必要ではない。むしろ、前述したように、様々なユニットは、コーデックハードウェアユニットと組み合わせてもよく、又は好適なソフトウェア及び／又はファームウェアと共に、前述の１つ以上のプロセッサを含む、相互動作ハードウェアユニットの集合によって提供することができる。
【０１５２】
更に、上述の各実装形態で用いた基地局装置や端末装置の各機能ブロックや各種の機能は、一般的には集積回路又は複数の集積回路である電気回路によって実現又は実行することができる。本明細書に記載の機能を実行するように設計された回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け又は汎用アプリケーション集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタロジック、若しくは個々のハードウェアコンポーネント、又はそれらの組み合わせを備えていてもよい。汎用プロセッサは、マイクロプロセッサでもよく、あるいは、プロセッサは、従来のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンでもよい。上述した汎用プロセッサ又は各回路は、デジタル回路で構成されても、又はアナログ回路で構成されてもよい。更に、半導体技術の進歩により現時点での集積回路に置き換わる集積回路化技術が現れれば、この技術による集積回路もまた使用可能となる。
【０１５３】
様々な実施例について説明した。これら及び他の実施例は、以下の特許請求の範囲内である。
【０１５４】
＜相互参照＞
この非仮出願は、米国特許法第１１９条の下で、２０１８年４月４日の出願番号６２／６５２，８４６号、２０１８年４月６日の出願番号６２／６５４，２６０号、及び２０１８年５月６日の出願番号６２／６７８，１２６号の優先権を主張するものであり、その内容の全体は、参照により本明細書に組み込まれる。
【図１】
2021520711.tif 000043
【図２Ａ】
2021520711.tif 000044
【図２Ｂ】
2021520711.tif 000045
【図３】
2021520711.tif 000046
【図４】
2021520711.tif 000047
【図５Ａ】
2021520711.tif 000048
【図５Ｂ】
2021520711.tif 000049
【図６】
2021520711.tif 000050
【図７】
2021520711.tif 000051
【図８】
2021520711.tif 000052
【図９】
2021520711.tif 000053
【図１０】
2021520711.tif 000054
【図１１】
2021520711.tif 000055
【図１２】
2021520711.tif 000056
【図１３】
2021520711.tif 000057
【図１４】
2021520711.tif 000058
【図１５】
2021520711.tif 000059
【図１６】
2021520711.tif 000060
【図１７Ａ】
2021520711.tif 000061
【図１７Ｂ】
2021520711.tif 000062
【図１８】
2021520711.tif 000063
【図１９】
2021520711.tif 000064
【国際調査報告】
2021520711.tif 000065
2021520711.tif 000066