JP2021521676A - 仮想現実アプリケーションにおいて特定のメッセージをシグナリングするためのシステム及び方法 - Google Patents

Abstract

音声情報を示すアプリケーション固有メッセージは、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでシグナリングされる。（表１の‘０ｘ０６’、及び表４の「ｉｆ（ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ＝＝０ｘ０６）」を参照されたい。）

Description

本開示は、対話型ビデオ配布の分野に関し、より具体的には、仮想現実アプリケーションにおいてアプリケーション固有メッセージをシグナリングする技術に関する。
背景技術

デジタルメディア再生機能は、いわゆる「スマート」テレビを含むデジタルテレビ、セットトップボックス、ラップトップ又はデスクトップコンピュータ、タブレット型コンピュータ、デジタル記録デバイス、デジタルメディアプレイヤ、ビデオゲーミングデバイス、いわゆる「スマート」フォンを含む携帯電話、専用ビデオストリーミングデバイスなどを含む、広範囲のデバイスに組み込むことができる。デジタルメディアコンテンツ（例えば、ビデオ及び音声プログラム）は、例えば、無線テレビプロバイダ、衛星テレビプロバイダ、ケーブルテレビプロバイダ、いわゆるストリーミングサービスプロバイダを含むオンラインメディアサービスプロバイダなどの複数のソースから送信することができる。デジタルメディアコンテンツは、インターネットプロトコル（Internet Protocol、ＩＰ）ネットワークなどの双方向ネットワーク及びデジタル放送ネットワークなどの単方向ネットワークを含むパケット交換ネットワークで配信され得る。

デジタルメディアコンテンツに含まれるデジタルビデオは、ビデオ符号化規格に従って符号化することができる。ビデオ符号化規格は、ビデオ圧縮技術を組み込むことができる。ビデオ符号化規格の例としては、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ及びＩＴＵ−Ｔ Ｈ．２６４（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても公知である）並びにＨｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）が挙げられる。ビデオ圧縮技術は、ビデオデータを記憶し送信するためのデータ要件を低減することを可能にする。ビデオ圧縮技術は、ビデオ系列における固有の冗長性を利用することにより、データ要件を低減することができる。ビデオ圧縮技術は、ビデオ系列を連続的により小さな部分（すなわち、ビデオ系列内のフレームの群、フレームの群内のフレーム、フレーム内のスライス、スライス内の符号化木ユニット（例えば、マクロブロック）、符号化木ユニット内の符号化ブロックなど）に再分割することができる。予測符号化技術を使用して、符号化されるビデオデータのユニットとビデオデータの参照ユニットとの間の差分値を生成することができる。差分値は、残差データと呼ばれることがある。残差データは、量子化された変換係数として符号化することができる。シンタックス要素は、残差データと参照符号化ユニットとを関連付けることができる。残差データ及びシンタックス要素は、準拠ビットストリームに含めることができる。準拠ビットストリーム及び関連メタデータは、データ構造に従ったフォーマットを有してもよい。準拠ビットストリーム及び関連メタデータは、送信規格に従って、ソースから受信デバイス（例えば、デジタルテレビ又はスマートフォン）に送信してもよい。伝送規格の例としては、デジタルビデオブロードキャスティング（Digital Video Broadcasting、ＤＶＢ）規格、統合デジタル放送サービス規格（Integrated Services Digital Broadcasting、ＩＳＤＢ）規格、及び例えば、ＡＴＳＣ２．０規格を含む、高度テレビジョンシステムズ委員会（Advanced Television Systems Committee、ＡＴＳＣ）によって作成された規格が挙げられる。ＡＴＳＣは、現在、いわゆるＡＴＳＣ３．０の一連の規格を開発している。
発明の概要

一実施例では、全方位ビデオに関連付けられた情報をシグナリングする方法は、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいてシンタックス要素を条件付きでシグナリングすることを含む、音声情報を示すアプリケーション固有メッセージをシグナリングすることを含む。

一実施例では、全方位ビデオに関連付けられた情報を決定する方法は、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでパースすることを含む、音声情報を示すアプリケーション固有メッセージをパースすることを含む。

本開示の１つ以上の技術に係る、符号化されたビデオデータを送信するように構成することができるシステムの一例を示すブロック図である。 本開示の１つ以上の技術に係る、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。 本開示の１つ以上の技術に係る、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。 本開示の１つ以上の技術に係る、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。 本開示の１つ以上の技術に係る、座標系の例を示す概念図である。 本開示の１つ以上の技術に係る、球体上の領域の例を示す概念図である。 本開示の１つ以上の技術に係る、球体上の領域の例を示す概念図である。 本開示の１つ以上の技術に係る、プロジェクトピクチャ領域及びパックピクチャ領域の例を示す概念図である。 本開示の１つ以上の技術に係る、符号化されたビデオデータを送信するように構成され得るシステムの実装形態に含まれ得る構成要素の一例を示す概念的描画である。 本開示の１つ以上の技術を実施できる受信デバイスの一例を示すブロック図である。 発明を実施するための形態

一般に、本開示は、仮想現実アプリケーションに関連付けられた情報をシグナリングするための種々の技術を説明する。具体的には、本開示は、仮想現実アプリケーションにおいて特定のメッセージをシグナリングするための技術について説明する。いくつかの実施例では、本開示の技術は、伝送規格に関して説明されているが、本明細書において説明される技術は、一般に適用可能であってよいことに留意されたい。例えば、本明細書で説明する技術は、一般に、ＤＶＢ規格、ＩＳＤＢ規格、ＡＴＳＣ規格、Ｄｉｇｉｔａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ（ＤＴＭＢ）規格、Ｄｉｇｉｔａｌ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ（ＤＭＢ）規格、Ｈｙｂｒｉｄ Ｂｒｏａｄｃａｓｔ ａｎｄ Ｂｒｏａｄｂａｎｄ Ｔｅｌｅｖｉｓｉｏｎ（ＨｂｂＴＶ）規格、ワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium、Ｗ３Ｃ）規格、及びユニバーサルプラグアンドプレイ（Universal Plug and Play、ＵＰｎＰ）規格のうちのいずれかに適用可能である。更に、本開示の技術は、ＩＴＵ−Ｔ Ｈ．２６４及びＩＴＵ−Ｔ Ｈ．２６５に関して説明されているが、本開示の技術は、全方位ビデオ符号化を含むビデオ符号化に一般に適用可能であることに留意されたい。例えば、本明細書で説明する符号化技術は、ＩＴＵ−Ｔ Ｈ．２６５に含まれるもの以外のブロック構造、イントラ予測技術、インター予測技術、変換技術、フィルタリング技術、及び／又はエントロピ符号化技術を含むビデオ符号化システム（将来のビデオ符号化規格に基づくビデオ符号化システムを含む）に組み込むことができる。したがって、ＩＴＵ−Ｔ Ｈ．２６４及びＩＴＵ−Ｔ Ｈ．２６５への参照は、説明のためのものであり、本明細書で説明する技術の範囲を限定するように解釈すべきではない。更に、本明細書での文書の参照による組み込みは、本明細書で使用される用語に関して限定する又は曖昧さを生むように解釈されるべきではないことに留意されたい。例えば、組み込まれた参照が、別の組み込まれた参照とは、及び／又はその用語が本明細書で使用されるのとは異なる用語の定義を提供する場合では、その用語は、それぞれの対応する定義を幅広く含むように、及び／又は代わりに特定の定義のそれぞれを含むように解釈されるべきである。

一実施例では、デバイスは、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいてシンタックス要素を条件付きでシグナリングすることを含む、音声情報を示すアプリケーション固有メッセージをシグナリングするように構成された１つ以上のプロセッサを含む。

一実施例では、非一時的コンピュータ可読記憶媒体は、その媒体に記憶された命令を含み、命令は実行されると、デバイスの１つ以上のプロセッサに、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいてシンタックス要素を条件付きでシグナリングさせることを含んで、音声情報を示すアプリケーション固有メッセージをシグナリングさせる。

一実施例では、装置は、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいてシンタックス要素を条件付きでシグナリングすることを含む、音声情報を示すアプリケーション固有メッセージをシグナリングするための手段を備える。

一実施例では、デバイスは、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでパースすることを含んで、音声情報を示すアプリケーション固有メッセージをパースするように構成された１つ以上のプロセッサを含む。

一実施例では、非一時的コンピュータ可読記憶媒体は、その媒体に記憶された命令を含み、命令は実行されると、デバイスの１つ以上のプロセッサに、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでパースさせることを含んで、音声情報を示すアプリケーション固有メッセージをパースさせる。

一実施例では、装置は、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでパースすることを含む、音声情報を示すアプリケーション固有メッセージをパースするための手段を備える。

１つ以上の実施例の詳細は、添付の図面及び以下の明細書に記述されている。他の特徴、目的、及び利点は、明細書及び図面から、並びに特許請求の範囲から明白であろう。

ビデオコンテンツは、典型的には、一連のフレームからなるビデオシーケンスを含む。一連のフレームはまた、ピクチャ群（group of pictures、ＧＯＰ）と呼ばれることがある。各ビデオフレーム又はピクチャは１つ以上のスライスを含むことができ、スライスは複数のビデオブロックを含む。ビデオブロックは、予測的に符号化され得る画素値（サンプルとも呼ばれる）の最大アレイとして定義することができる。ビデオブロックは、走査パターン（例えば、ラスター走査）に従って順序付けすることができる。ビデオエンコーダは、ビデオブロック及びその再分割に対して予測符号化を実行する。ＩＴＵ−Ｔ Ｈ．２６４は、１６×１６のルマ（luma）サンプルを含むマクロブロックを規定する。ＩＴＵ−Ｔ Ｈ．２６５は、類似の符号化ツリーユニット（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、ＰＩＰＥ）など）に従ってエントロピ符号化することができる。更に、予測モードを示すシンタックス要素などのシンタックス要素も、エントロピ符号化することができる。エントロピ符号化され量子化された変換係数及び対応するエントロピ符号化されたシンタックス要素は、ビデオデータを再生成するために使用することができる準拠ビットストリームを形成することができる。二値化プロセスを、エントロピ符号化プロセスの一部としてシンタックス要素に対して実行することができる。二値化は、シンタックス値を一連の１つ以上のビットに変換するプロセスを指す。これらのビットは、「ビン」と呼ばれることがある。
仮想現実（ＶＲ）アプリケーションは、ヘッドマウントディスプレイでレンダリングすることができるビデオコンテンツを含むことができ、ユーザの頭部の向きに対応する全天球映像の領域のみがレンダリングされる。ＶＲアプリケーションは、３６０度ビデオの３６０度全天球映像とも呼ばれる、全方位ビデオによって使用可能にすることができる。全方位ビデオは、典型的には、最大３６０度のシーンをカバーする複数のカメラによってキャプチャされる。通常のビデオと比較した全方位ビデオの明確な特徴は、典型的には、キャプチャされたビデオ領域全体のサブセットのみが表示される、すなわち、現在のユーザの視野（ＦＯＶ）に対応する領域が表示されることである。ＦＯＶはまた、時に、ビューポートとも呼ばれる。他の場合では、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部として説明することができる。ビューポートのサイズは、視野以下でもよいことに留意されたい。更に、全方位ビデオは、モノスコープカメラ又はステレオスコープカメラを使用してキャプチャされ得ることに留意されたい。モノスコープカメラは、オブジェクトの単一視野をキャプチャするカメラを含んでもよい。ステレオスコープカメラは、同じオブジェクトの複数のビューをキャプチャするカメラを含んでもよい（例えば、わずかに異なる角度で２つのレンズを使用してビューをキャプチャする）。更に、場合によっては、全方位ビデオアプリケーションで使用するための画像は、超広角レンズ（すなわち、いわゆる魚眼レンズ）を使用してキャプチャされ得ることに留意されたい。いずれの場合も、３６０度の球面ビデオを作成するためのプロセスは、一般に、入力画像をつなぎ合わせ、つなぎ合わされた入力画像を３次元構造（例えば、球体又は立方体）上にプロジェクションして、いわゆるプロジェクトフレームをもたらし得ることとして説明することができる。更に、場合によっては、プロジェクトフレームの領域を、変換し、リサイズし、及び再配置してもよく、これによっていわゆるパックフレームをもたらすことができる。

伝送システムは、全方位ビデオを１つ以上の演算デバイスに送信するように構成することができる。演算デバイス及び／又は伝送システムは、１つ以上の抽象化層を含むモデルに基づいてもよく、各抽象化層のデータは、特定の構造、例えば、パケット構造、変調方式などに従って表される。定義された抽象化層を含むモデルの一例は、いわゆる開放型システム間相互接続（ＯＳＩ）モデルである。ＯＳＩモデルは、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、及び物理層を含む、７層スタックモデルを定義する。スタックモデル内の層の記述に関して上位（upper）及び下位（lower）という用語を使用することは、最上層であるアプリケーション層及び最下層である物理層に基づいてもよいという点に留意すべきである。更に、場合によっては、用語「層１」又は「Ｌ１」を使用して、物理層を指すことができ、用語「層２」又は「Ｌ２」を使用して、リンク層を指すことができ、用語「層３」又は「Ｌ３」又は「ＩＰ層」を使用して、ネットワーク層を指すことができる。

物理層は、一般に、電気信号がデジタルデータを形成する層を指すことができる。例えば、物理層は、変調された無線周波数（radio frequency、ＲＦ）シンボルがデジタルデータのフレームをどのように形成するかを定義する層を指すことができる。リンク層と呼ばれることもあるデータリンク層は、送信側での物理層処理前及び受信側での物理層受信後に使用される抽象化を指すことができる。本明細書で使用するとき、リンク層は、送信側でネットワーク層から物理層にデータを伝送するために使用され、受信側で物理層からネットワーク層へデータを伝送するために使用される抽象化を指すことができる。送信側及び受信側は論理的な役割であり、単一のデバイスは、一方のインスタンスにおける送信側と他方のインスタンスにおける受信側の両方として動作できることに留意されたい。リンク層は、特定のパケットタイプ（例えば、ムービングピクチャエクスパーツグループ−トランスポートストリーム（Motion Picture Expert Group - Transport Stream、ＭＰＥＧ−ＴＳ）パケット、インターネットプロトコルバージョン４（ＩＰｖ４）パケットなど）にカプセル化された様々な種類のデータ（例えば、ビデオファイル、音声ファイル、又はアプリケーションファイル）を物理層による処理のための単一汎用フォーマットに抽象化することができる。ネットワーク層は、一般に、論理アドレッシングが発生する層を指すことができる。すなわち、ネットワーク層は、一般に、アドレッシング情報（例えば、インターネットプロトコル（ＩＰ）アドレス）を提供することができ、これにより、データパケットをネットワーク内の特定のノード（例えば、演算デバイス）に送達することができる。本発明で使用する場合、ネットワーク層という用語は、リンク層の上の層及び／又はリンク層処理のために受信することができるような構造のデータを有する層を指すことができる。トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層の各々は、ユーザアプリケーションによって使用するためにデータをどのように送達するかを定義することができる。

ＩＳＯ／ＩＥＣ ＦＤＩＳ ２３０９０−２：２０１ｘ（Ｅ）；「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｃｏｄｅｄ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｏｆ ｉｍｍｅｒｓｉｖｅ ｍｅｄｉａ（ＭＰＥＧ−Ｉ）−Ｐａｒｔ ２：Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ ｍｅｄｉａ ｆｏｒｍａｔ，」ＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ ２９／ＷＧ ２０１８−０２−０７が、参照により本明細書に組み込まれ、本明細書ではＭＰＥＧ−Ｉと称され、全方位メディアアプリケーションを可能にするメディアアプリケーションフォーマットを定義する。ＭＰＥＧ−Ｉは、全方位ビデオシーケンスのための座標系；球面ビデオシーケンス又は画像を、それぞれ、２次元矩形ビデオシーケンス又は画像に変換するために使用され得る、投影及び矩形領域ごと（rectangular region-wise）のパッキングの方法；ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＩＳＯＢＭＦＦ）を使用した全方位メディア及び関連メタデータの記憶；メディアストリーミングシステムにおける全方位メディアのカプセル化、シグナリング、及びストリーミング；並びにメディアプロファイル及びプレゼンテーションプロファイル、を指定する。簡潔にするために、本明細書では、ＭＰＥＧ−Ｉの完全な説明は提供されないことに留意されたい。しかしながら、ＭＰＥＧ−Ｉの関連するセクションを参照する。

ＭＰＥＧ−Ｉは、ビデオがＩＴＵ−Ｔ Ｈ．２６５に従って符号化されるメディアプロファイルを提供する。ＩＴＵ−Ｔ Ｈ．２６５は、高効率ビデオ符号化（High Efficiency Video Coding、ＨＥＶＣ），Ｒｅｃに記載されている。ＩＴＵ−Ｔ Ｈ．２６５（２０１６年１２月）は、参照により本明細書に組み込まれ、本明細書ではＩＴＵ−Ｔ Ｈ．２６５と呼ばれる。上述のように、ＩＴＵ−Ｔ Ｈ．２６５によれば、各ビデオフレーム又はピクチャは、１つ以上のスライスを含むように区画化してもよく、１つ以上のタイルを含むように更に区画化してもよい。図２Ａ〜図２Ｂは、スライスを含み、ピクチャを更にタイルに区画化するピクチャ群の一例を示す概念図である。図２Ａに示す例では、Ｐｉｃ_４は、２つのスライス（すなわち、Ｓｌｉｃｅ_１及びＳｌｉｃｅ_２）を含むものとして示されており、各スライスは（例えばラスタ走査順に）ＣＴＵのシーケンスを含む。図２Ｂに示す例では、Ｐｉｃ_４は、６つのタイル（すなわち、Ｔｉｌｅ_１〜Ｔｉｌｅ_６）を含むものとして示されており、各タイルは矩形であり、ＣＴＵのシーケンスを含む。ＩＴＵ−Ｔ Ｈ．２６５では、タイルは、２つ以上のスライスが包含する符号化ツリーユニットからなっていてもよく、スライスは、２つ以上のタイルが包含する符号化ツリーユニットからなっていてもよいことに留意されたい。しかしながら、ＩＴＵ−Ｔ Ｈ．２６５は、以下の条件のうちの１つ又は両方が満たされなければならないと規定している。（１）あるスライス中の全ての符号化ツリーユニットは同じタイルに属する、及び（２）あるタイル内の全ての符号化ツリーユニットは同じスライスに属する。

３６０度の球面ビデオは、領域を含んでもよい。図３に示す例を参照すると、３６０度の球面ビデオは、領域Ａ、Ｂ、及びＣを含み、図３に示すように、タイル（すなわち、Ｔｉｌｅ_１〜Ｔｉｌｅ_６）は、全方位ビデオの領域を形成することができる。図３に示す例では、各領域はＣＴＵを含むものとして示されている。上述のように、ＣＴＵは、符号化ビデオデータのスライス、及び／又はビデオデータのタイルを形成することができる。更に、上述のように、ビデオ符号化技術は、ビデオブロック、その再分割、及び／又は対応する構造に従って、ピクチャの領域を符号化してもよく、ビデオ符号化技術は、ビデオ符号化パラメータを、ビデオ符号化構造の様々なレベルで調整すること、例えば、スライス、タイル、ビデオブロック、及び／又は再分割に対して調整することを可能にすることに留意されたい。一実施例では、図３に表す３６０度のビデオは、スポーツイベントを表してもよく、領域Ａ及び領域Ｃがスタジアムのスタンドのビューを含み、領域Ｂが競技場のビューを含む（例えば、ビデオは、５０ヤードラインに配置された３６０度カメラによってキャプチャされる）。

上述のように、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部であってもよい。したがって、全方位ビデオの領域は、ユーザのビューポートに応じて選択的に配信してもよく、すなわち、ビューポート依存配信が、全方位ビデオストリーミングにおいて可能になり得る。典型的には、ビューポート依存配信を可能にするために、ソースコンテンツは、符号化の前にサブピクチャシーケンスに分割され、各サブピクチャシーケンスは、全方位ビデオコンテンツの空間領域のサブセットをカバーし、そのとき、サブピクチャシーケンスは、互いに独立して単層ビットストリームとして符号化される。例えば、図３を参照すると、領域Ａ、領域Ｂ、及び領域Ｃのそれぞれ、又はこれらの部分のそれぞれが、独立して符号化されるサブピクチャビットストリームに対応し得る。各サブピクチャビットストリームは、それ自体のトラックとしてファイル中にカプセル化してもよく、ビューポート情報に基づいて、トラックを受信デバイスに選択的に配信してもよい。場合によっては、サブピクチャが重なり合う可能性があることに留意されたい。例えば、図３を参照すると、Ｔｉｌｅ_１、Ｔｉｌｅ_２、Ｔｉｌｅ_４、及びＴｉｌｅ_５がサブピクチャを形成してもよく、Ｔｉｌｅ_２、Ｔｉｌｅ_３、Ｔｉｌｅ_５、及びＴｉｌｅ_６がサブピクチャを形成してもよい。したがって、特定のサンプルが複数のサブピクチャ内に含まれてもよい。ＭＰＥＧ−Ｉは、整列して合成されたサンプルが、別のトラックに関連付けられたトラック内のサンプルのうちの１つを含む場合、サンプルは、その別のトラック内の特定のサンプルと同じ合成時間（composition time）を有する、又は、同じ合成時間を有するサンプルがその別のトラック内にない場合は、その別のトラック内の特定のサンプルの合成時間と比較して、最も近い先行する合成時間を有する、と規定している。更に、ＭＰＥＧ−Ｉは、構成成分ピクチャが、１つのビューに対応する空間的にフレームパックされた立体的ピクチャの一部を含むか、又はフレームパッキングが使用されていない場合、若しくは時間的インターリーブフレームパッキング構成が使用されている場合にピクチャ自体を含む、と規定している。

上述のように、ＭＰＥＧ−Ｉは、全方位ビデオの座標系を指定する。ＭＰＥＧ−Ｉでは、座標系は、単位球体と、３つの座標軸、すなわちＸ（前後）軸、Ｙ（横方向、左右）軸、及びＺ（垂直、上方）軸、とからなり、３つの軸は球体の中心で交差する。球体上の点の場所は、球体座標方位（φ）及び高度（θ）の対によって識別される。図４は、ＭＰＥＧ−Ｉで指定されるような、Ｘ、Ｙ、及びＺ座標軸に対する、球体座標での方位（φ）及び高度（θ）の関係を示す。ＭＰＥＧ−Ｉでは、方位の値範囲は、−１８０．０度以上、１８０．０度未満であり、高度の値範囲は、両端値を含む、−９０．０度〜９０．０度であることに留意されたい。ＭＰＥＧ−Ｉは、球体上の領域が４つの大円によって指定される場合があり、大円（Ｒｉｅｍａｎｎｉａｎ ｃｉｒｃｌｅとも呼ばれる）は、球体と、球体の中心点を通過する平面との交点であり、球体の中心と大円の中心とが同一位置にあると指定する。ＭＰＥＧ−Ｉは、球体上の領域が２つの方位円及び２つの高度円によって指定され得ることについて更に記載しており、方位円は、同じ方位値を有する全ての点を接続する球体上の円であり、高度円は、同じ高度値を有する全ての点を接続する球体上の円である。ＭＰＥＧ−Ｉ内の球体領域構造は、様々なタイプのメタデータをシグナリングするための基礎をなす。

本明細書で使用される式に関して、以下の算術演算子が使用され得ることに留意されたい。
＋ 加算
− 減算（２つの引数演算子として）又はネゲーション（単項プレフィックス演算子として）
^＊ 行列乗算を含む乗算
ｘ^ｙ べき乗。ｘのｙ乗を指定する。他のコンテキストでは、そのような表記は、べき乗としての解釈を意図していないスーパースクリプトに使用される。
／ ゼロへの結果切り捨てを伴う整数除算。例えば、７／４及び−７／−４は、１に切り捨てられ、−７／４及び７／−４は、−１に切り捨てられる。
÷ 切り捨て又は四捨五入が意図されていない式において除算を表すために使用される。

切り捨て又は四捨五入が意図されていない式において除算を表すために使用される。
ｘ％ｙ 剰余。ｘをｙで割った余りであり、ｘ＞＝０かつｙ＞０である整数ｘ及びｙに対してのみ定義される。

本明細書で使用される式に関して、以下の論理演算子が使用され得ることに留意されたい：
ｘ＆＆ｙ ｘとｙとのブール論理「積」
ｘ｜｜ｙ ｘとｙとのブール論理「和」
！ブール論理「否」
ｘ？ｙ：ｚ ｘが真であるか又は０に等しくない場合はｙの値を評価し、そうでない場合はｚの値を評価する。

本明細書で使用される式に関して、以下の関係演算子が使用され得ることに留意されたい。
＞ 大なり
＞＝ 大なり又は等しい
＜ 小なり
＜＝ 小なり又は等しい
＝＝ 等しい
！＝ 等しくない

本明細書で使用されるシンタックスにおいて、ｕｎｓｉｇｎｅｄ ｉｎｔ（ｎ）は、ｎビットを有する符号なし整数を指すことに留意されたい。更に、ｂｉｔ（ｎ）は、ｎビットを有するビット値を指す。

上述のように、ＭＰＥＧ−Ｉは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）を使用して、全方位メディア及び関連メタデータを記憶する方法を指定する。ＭＰＥＧ−Ｉは、プロジェクトフレームによってカバーされる球体表面の面積を指定するメタデータをサポートするファイルフォーマットを指定する。具体的には、ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクを有する球体領域を指定する球体領域構造を含む。
定義
球体領域構造（ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ）は、球体領域を指定する。

ｃｅｎｔｒｅ＿ｔｉｌｔが０に等しい場合、この構造によって指定される球体領域は、以下のように導出される。
−ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ両方が０に等しい場合、この構造によって指定される球体領域は球体表面上の点である。
−そうでない場合、球体領域は、以下のように導出される変数である、ｃｅｎｔｒｅＡｚｉｍｕｔｈ、ｃｅｎｔｒｅＥｌｅｖａｔｉｏｎ、ｃＡｚｉｍｕｔｈ１、ｃＡｚｉｍｕｔｈ、ｃＥｌｅｖａｔｉｏｎ１、及びｃＥｌｅｖａｔｉｏｎ２を用いて定義される。
ｃｅｎｔｒｅＡｚｉｍｕｔｈ＝ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ÷６５５３６
ｃｅｎｔｒｅＥｌｅｖａｔｉｏｎ＝ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ÷６５５３６
ｃＡｚｉｍｕｔｈ１＝（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ−ａｚｉｍｕｔｈ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＡｚｉｍｕｔｈ２＝（ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ＋ａｚｉｍｕｔｈ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＥｌｅｖａｔｉｏｎ１＝（ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ−ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ÷２）÷６５５３６
ｃＥｌｅｖａｔｉｏｎ２＝（ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ＋ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ÷２）÷６５５３６

球体領域は、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのこのインスタンスを含む構造のセマンティクスで指定された形状タイプ値を参照して以下のように定義される。
−形状タイプ値が０に等しい場合、球体領域は、図５Ａに示すように、４つの点ｃＡｚｉｍｕｔｈ１、ｃＡｚｉｍｕｔｈ２、ｃＥｌｅｖａｔｉｏｎ１、ｃＥｌｅｖａｔｉｏｎ２によって定義される４つの大円と、ｃｅｎｔｒｅＡｚｉｍｕｔｈ及びｃｅｎｔｒｅＥｌｅｖａｔｉｏｎによって定義される中心点とによって指定される。
−形状タイプ値が１に等しい場合、球体領域は、図５Ｂに示すように、４つの点ｃＡｚｉｍｕｔｈ１、ｃＡｚｉｍｕｔｈ２、ｃＥｌｅｖａｔｉｏｎ１、ｃＥｌｅｖａｔｉｏｎ２によって定義される２つの方位円及び２つの高度円と、ｃｅｎｔｒｅＡｚｉｍｕｔｈ及びｃｅｎｔｒｅＥｌｅｖａｔｉｏｎによって定義される中心点とによって指定される。

ｃｅｎｔｒｅ＿ｔｉｌｔが０に等しくない場合、球体領域は、最初に上記のように導出され、次いで、球体原点を起源として球体領域の中心点を通過する軸に沿って傾斜回転が適用され、そのとき、原点から軸の正方向の端に向かって見たときに角度値は時計回りに増加する。最終的な球体領域は、傾斜回転を適用した後のものである。
０に等しい形状タイプ値は、球体領域が図５Ａに表すように４つの大円によって指定されることを示している。
１に等しい形状タイプ値は、図５Ｂに示すように、球体領域が２つの方位円及び２つの高度円によって指定されることを示している。
１より大きい形状タイプ値が予約済みである。
シンタックス

セマンティクス
ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、及びｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、球体領域の中心を指定する。ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈは、両端値を含む、−１８０^＊２^１６〜１８０^＊２^１６−１の範囲にあるものとする。ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、両端値を含む、−９０^＊２^１６〜９０^＊２^１６の範囲にあるものとする。
ｃｅｎｔｒｅ＿ｔｉｌｔは、球体領域の傾斜角を指定し、ｃｅｎｔｒｅ＿ｔｉｌｔは、両端値を含む、−１８０^＊２^１６〜１８０^＊２^１６−１の範囲にあるものとする。
Ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、存在する場合、それぞれ、この構造によって指定される球体領域の方位範囲及び高度範囲を２^−１６の単位で指定する。ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、図５Ａ又は図５Ｂに示すように、球体領域の中心点を通る範囲を指定する。ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのこのインスタンスにａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在しない場合、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのこのインスタンスを含む構造のセマンティクスにおいて指定されると推測される。ａｚｉｍｕｔｈ＿ｒａｎｇｅは、両端値を含む、０〜３６０^＊２^１６の範囲にあるものとする。ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、両端値を含む、０〜１８０^＊２^１６の範囲にあるものとする。
ｉｎｔｅｒｐｏｌａｔｅのセマンティクスは、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔのこのインスタンスを含む構造のセマンティクスによって指定される。

上述のように、ＭＰＥＧ−Ｉ内の球体領域構造は、様々なタイプのメタデータをシグナリングするための基礎をなす。球体領域に対して汎用時間指定メタデータトラックシンタックスを指定することに関して、ＭＰＥＧ−Ｉは、サンプルエントリ及びサンプルフォーマットを指定する。サンプルエントリ構造は、以下の定義、シンタックス、及びセマンティクスを有するものとして指定される。
定義
ちょうど１つのＳｐｈｅｒｅＲｅｇｉｏｎＣｏｎｆｉｇＢｏｘが、サンプルエントリに存在するものとする。ＳｐｈｅｒｅＲｅｇｉｏｎＣｏｎｆｉｇＢｏｘは、サンプルによって指定された球体領域の形状を指定する。
サンプル内の球体領域の方位範囲及び高度範囲が変化しない場合、それらはサンプルエントリ内に示され得る。
シンタックス

セマンティクス
０に等しいｓｈａｐｅ＿ｔｙｐｅは、球体領域が、４つの大円によって指定されることを指定する。１に等しいｓｈａｐｅ＿ｔｙｐｅは、球体領域が、２つの方位円及び２つの高度円によって指定されることを指定する。１より大きいｓｈａｐｅ＿ｔｙｐｅの値が予約済みである。ｓｈａｐｅ＿ｔｙｐｅの値は、（上述の）球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合に、形状タイプ値として使用される。
０に等しいｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇは、このサンプルエントリを参照する全てのサンプルにおいて、球体領域の方位範囲及び高度範囲が変化されないままであることを指定する。１に等しいｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇは、球体領域の方位範囲及び高度範囲がサンプルフォーマットで示されることを指定する。
ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、それぞれ、このサンプルエントリを参照する各サンプルに対して、球体領域の方位範囲及び高度範囲を２^−１６の単位で指定する。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、図５Ａ又は図５Ｂに示すように、球体領域の中心点を通る範囲を指定する。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅは、両端値を含む、０〜３６０^＊２^１６の範囲にあるものとする。ｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、両端値を含む、０〜１８０^＊２^１６の範囲にあるものとする。ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在し、両方とも０に等しい場合、このサンプルエントリを参照する各サンプルの球体領域は、球体表面上の点である。（上述の）球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合、ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅが存在する場合は、ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅの値は、それぞれ、ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅに等しいと推測される。
ｎｕｍ＿ｒｅｇｉｏｎｓは、このサンプルエントリを参照するサンプル内の球体領域数を指定する。ｎｕｍ＿ｒｅｇｉｏｎｓは、１に等しいものとする。ｎｕｍ＿ｒｅｇｉｏｎｓの他の値は予備とされる。

サンプルフォーマット構造は、以下の定義、シンタックス、及びセマンティクスを有するものとして指定される。
定義
各サンプルは球体領域を指定する。ＳｐｈｅｒｅＲｅｇｉｏｎＳａｍｐｌｅ構造は、導出されたトラック形式で拡張してもよい。
シンタックス

セマンティクス
上述の球体領域構造項目は、ＳｐｈｅｒｅＲｅｇｉｏｎＳｔｒｕｃｔ構造を含むサンプルに適用される。

ターゲットメディアサンプルが、参照メディアトラック内のメディアサンプルであって、その合成時間が、このサンプルの合成時間以上であり、次のサンプルの合成時間未満であるとする。
０に等しいｉｎｔｅｒｐｏｌａｔｅは、このサンプルにおけるｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、ｃｅｎｔｒｅ＿ｔｉｌｔ、ａｚｉｍｕｔｈ＿ｒａｎｇｅ（存在する場合）、及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ（存在する場合）の値が、ターゲットメディアサンプルに適用されることを指定し、１に等しいｉｎｔｅｒｐｏｌａｔｅは、ターゲットメディアサンプルに適用されるｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、ｃｅｎｔｒｅ＿ｔｉｌｔ、ａｚｉｍｕｔｈ＿ｒａｎｇｅ（存在する場合）、及びｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ（存在する場合）の値が、このサンプル及び前のサンプルにおける対応するフィールドの値から直線的に補間されることを指定する。
同期サンプル、トラックの第１のサンプル、及びトラック断片の第１のサンプルに対するｉｎｔｅｒｐｏｌａｔｅは０に等しいものとする。

ＭＰＥＧ−Ｉでは、時間指定メタデータは、サンプルエントリ及びサンプルフォーマットに基づいてシグナリングしてもよい。例えば、ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有する初期ビューイング方向メタデータを含む。
定義
このメタデータは、関連付けられたメディアトラック、又は画像アイテムとして記憶された単一の全方位画像を再生する場合に使用されるべき初期ビューイング方向を示す。このタイプのメタデータ、ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、及びｃｅｎｔｒｅ＿ｔｉｌｔの非存在下では、全て０に等しいと推測されるべきである。
ＯＭＡＦ（全方位メディアフォーマット）プレイヤは、指示された又は推定されたｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、及びｃｅｎｔｒｅ＿ｔｉｌｔを以下のように使用するべきである。
−ＯＭＡＦプレイヤの方向／ビューポートメタデータが、ビューイングデバイスに含まれるか又はそれに取り付けられた方向センサを基礎にして取得される場合、ＯＭＡＦプレイヤは、
・ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ値のみに従うべきであり、かつ、
・ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ及びｃｅｎｔｒｅ＿ｔｉｌｔの値を無視し、代わりに方向センサからのそれぞれの値を使用するべきである。
−そうでない場合は、ＯＭＡＦプレイヤは、ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、及びｃｅｎｔｒｅ＿ｔｉｌｔの３つ全てに従うべきである。
トラックサンプルエントリタイプ「初期ビュー方向時間指定メタデータ」を使用するものとする。サンプルエントリのＳｐｈｅｒｅＲｅｇｉｏｎＣｏｎｆｉｇＢｏｘにおいて、ｓｈａｐｅ＿ｔｙｐｅは０に等しいものとし、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇは０に等しいものとし、ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ０に等しいものとし、ｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは０に等しいものとする。
注記：このメタデータは、どの方位範囲及び高度範囲がビューポートによってカバーされているかにかかわらず、任意のビューポートに適用される。したがって、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｆｌａｇ、ｓｔａｔｉｃ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ、及びｓｔａｔｉｃ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、このメタデータが関連し、したがって０に等しい必要があるビューポートの寸法に影響を与えない。ＯＭＡＦプレイヤが上記で結論付けたようにｃｅｎｔｒｅ＿ｔｉｌｔの値に従う場合、ｃｅｎｔｒｅ＿ｔｉｌｔの値は、ビューポートを表示する際に実際に使用されているものに等しいビューポートの球体領域の方位範囲及び高度範囲を設定することによって解釈することができる。
シンタックス

セマンティクス
注記１：サンプル構造がＳｐｈｅｒｅＲｅｇｉｏｎＳａｍｐｌｅから拡張されると、ＳｐｈｅｒｅＲｅｇｉｏｎＳａｍｐｌｅのシンタックス要素がサンプルに含まれる。
ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、及びｃｅｎｔｒｅ＿ｔｉｌｔは、グローバル座標軸に対してビューイング方向を２^−１６度の単位で指定する。ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ及びｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、ビューポートの中心を示し、ｃｅｎｔｒｅ＿ｔｉｌｔは、ビューポートの傾斜角を示す。
ｉｎｔｅｒｐｏｌａｔｅは、０に等しいものとする。
０に等しいｒｅｆｒｅｓｈ＿ｆｌａｇは、示されたビューイング方向が、関連するメディアトラックにおける時系列サンプルから、再生開始時に使用されるべきであることを指定する。１に等しいｒｅｆｒｅｓｈ＿ｆｌａｇは、示されたビューイング方向が、各関連メディアトラックの時系列サンプルをレンダリングするとき、すなわち、連続再生時と、時系列サンプルからの再生開始時との両方で、常に使用されるべきであることを指定する。
注記２：１に等しいｒｅｆｒｅｓｈ＿ｆｌａｇは、コンテンツ作成者が、ビデオを連続して再生する場合でも、特定のビューイング方向が推奨されることを示すことを可能にする。
例えば、１に等しいｒｅｆｒｅｓｈ＿ｆｌａｇは、シーンカット位置を示すことができる。

上述のように、ＭＰＥＧ−Ｉは、球面ビデオシーケンスを２次元矩形ビデオシーケンスに変換するために使用され得る投影及び矩形領域ごとのパッキングの方法を指定している。このようにして、ＭＰＥＧ−Ｉは、以下の定義、シンタックス、及びセマンティクスを有する領域ごとのパック構造を指定している。
定義
ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔは、パック領域と、対応するプロジェクト領域との間のマッピングを指定し、存在する場合は、ガードバンドの場所及びサイズを指定する。
注記：他の情報の中でも、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔはまた、コンテンツカバレージ情報を、２Ｄデカルトピクチャドメインにおいて提供する。
この項目のセマンティクスにおける復号されたピクチャは、このシンタックス構造用のコンテナに応じて以下のうちのいずれか１つである。
−ビデオについては、復号されたピクチャは、ビデオトラックのサンプルから得られる復号出力である。
−画像アイテムについては、復号されたピクチャは、画像の復元された画像アイテムである。
ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔの内容は、情報提供のために以下に要約され、一方で、基準としてのセマンティクスが、本項目において後に続く。
−プロジェクトピクチャの幅及び高さは、それぞれ、ｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐｒｏｊ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔで明示的にシグナリングされる。
−パックピクチャの幅及び高さは、それぞれ、ｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｗｉｄｔｈ及びｐａｃｋｅｄ＿ｐｉｃｔｕｒｅ＿ｈｅｉｇｈｔで明示的にシグナリングされる。
−プロジェクトピクチャが立体的であり、上部−底部又は横並びのフレームパック構成を有する場合、１に等しいｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇは、以下を指定する。
・このシンタックス構造におけるプロジェクト領域情報、パック領域情報、及びガードバンド領域情報は、各構成成分ピクチャに個別に適用され、
・パックピクチャ及びプロジェクトピクチャは、同じ立体的フレームパックフォーマットを有し、
・プロジェクト領域及びパック領域の数は、シンタックス構造におけるｎｕｍ＿ｒｅｇｉｏｎｓの値によって示される数の２倍である。
−ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔは、ループを含み、ループエントリは、両方の構成成分ピクチャにおいて、対応するプロジェクト領域及びパック領域に対応する（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しい場合）、又はプロジェクト領域及び対応するパック領域（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しい場合）に対応し、ループエントリは以下を含む。
・パック領域に対するガードバンドの存在を示すフラグ、
・パッキングタイプ（しかしながら、矩形領域でのパッキングのみが、ＭＰＥＧ−Ｉで指定される）、
・矩形領域パック構造ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）内における、プロジェクト領域と、対応するパック領域との間のマッピング、
・ガードバンドが存在する場合、パック領域のためのガードバンド構造ＧｕａｒｄＢａｎｄ（ｉ）。
矩形領域パック構造ＲｅｃｔＲｅｇｉｏｎＰａｃｋｉｎｇ（ｉ）の内容は、情報提供のために以下に要約され、一方で、基準としてのセマンティクスが、本項目において後に続く。
−ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、それぞれ、ｉ番目のプロジェクト領域の幅、高さ、上部オフセット、及び左オフセットを指定する。
−ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］は、回転及びミラーリングが存在する場合に、ｉ番目のパック領域に適用されて、それをｉ番目のプロジェクト領域に再マッピングする回転及びミラーリングを指定する。
−ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、それぞれ、ｉ番目のパック領域の幅、高さ、上部オフセット、及び左オフセット列を指定する。
ガードバンド構造、ＧｕａｒｄＢａｎｄ（ｉ）の内容は、情報提供のために以下に要約され、一方で、基準としてのセマンティクスが、本項目において後に続く。
−ｌｅｆｔ＿ｇｂ＿ｗｉｄｔｈ［ｉ］，ｒｉｇｈｔ＿ｇｂ＿ｗｉｄｔｈ［ｉ］，ｔｏｐ＿ｇｂ＿ｈｅｉｇｈｔ［ｉ］，又はｂｏｔｔｏｍ＿ｇｂ＿ｈｅｉｇｈｔ［ｉ］は、それぞれ、ｉ番目のパック領域の左側の、右側の、上方の、又は下方のガードバンドのサイズを指定する。
−ｇｂ＿ｎｏｔ＿ｕｓｅｄ＿ｆｏｒ＿ｐｒｅｄ＿ｆｌａｇ［ｉ］は、インター予測プロセスにおいてガードバンドが参照として使用されないように、符号化が制約されているかどうかを示す。
−ｇｂ＿ｔｙｐｅ［ｉ］［ｊ］は、ｉ番目のパック領域のガードバンドのタイプを指定する。
図６は、プロジェクトピクチャ内にあるプロジェクト領域の位置及びサイズ（左側）、並びにガードバンドを有するパックピクチャ内にあるパック領域の位置及びサイズ（右側）の例を示す。この例は、ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇの値が０に等しいときに適用される。
シンタックス

セマンティクス
ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、それぞれ、プロジェクトピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しい場合）、又はプロジェクトピクチャの構成成分ピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しい場合）のいずれかにおける、ｉ番目のプロジェクト領域の幅、高さ、上部オフセット、及び左オフセットを指定する。ｐｒｏｊ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐｒｏｊ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐｒｏｊ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、プロジェクトピクチャサンプルを単位とした相対値で示される。
注記１：２つのプロジェクト領域は、部分的に又は完全に互いに重なり合っていてもよい。例えば、領域ごとの品質ランク指標によって、品質差の指標が存在する場合、任意の２つの重複するプロジェクト領域の重複領域に対して、より高い品質を有することが示されるプロジェクト領域に対応するパック領域がレンダリングに使用されるべきである。
ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］は、ｉ番目のパック領域に適用されて、それをｉ番目のプロジェクト領域に再マッピングする回転及びミラーリングを指定する。ｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］が回転及びミラーリングの両方を指定する場合、回転は、パック領域のサンプル場所をプロジェクト領域のサンプル場所に変換するために、ミラーリングの前に適用される。以下の値が指定される。
０：変換なし
１：水平ミラーリング
２：１８０度（反時計回り）回転
３：水平方向にミラーリングする前に１８０度（反時計回り）回転
４：水平方向にミラーリングする前に９０度（反時計回り）回転
５：９０度（反時計回り）回転
６：水平方向にミラーリングする前に２７０度（反時計回り）回転
７：２７０度（反時計回り）回転
注記２：ＭＰＥＧ−Ｉは、パックピクチャ内のパック領域のサンプル場所を、プロジェクトピクチャ内のプロジェクト領域のサンプル場所に変換するためのｔｒａｎｓｆｏｒｍ＿ｔｙｐｅ［ｉ］のセマンティクスを指定する。
ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、それぞれ、パックピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが０に等しい場合）、又はパックピクチャの構成成分ピクチャ内（ｃｏｎｓｔｉｔｕｅｎｔ＿ｐｉｃｔｕｒｅ＿ｍａｔｃｈｉｎｇ＿ｆｌａｇが１に等しい場合）のいずれかにおける、ｉ番目のパック領域の幅、高さ、オフセット、及び左オフセットを指定する。ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、パックピクチャサンプルを単位とした相対値で示される。ｐａｃｋｅｄ＿ｒｅｇ＿ｗｉｄｔｈ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｈｅｉｇｈｔ［ｉ］、ｐａｃｋｅｄ＿ｒｅｇ＿ｔｏｐ［ｉ］、及びｐａｃｋｅｄ＿ｒｅｇ＿ｌｅｆｔ［ｉ］は、復号ピクチャ内における、ルマサンプルを単位とする水平及び垂直座標の整数値を表すものとする。
注記：２つのパック領域は、部分的に又は完全に互いに重なり合っていてもよい。

ＭＰＥＧ−Ｉは、パック領域内のルマサンプル場所を、対応するプロジェクト領域のルマサンプル場所へと再マッピングするための、矩形領域ごとのパッキングプロセスの逆プロセスを更に指定する。
このプロセスへの入力は以下の通りである。
−パック領域内のサンプル場所（ｘ，ｙ）であって、ｘ及びｙは、パックピクチャサンプルを単位とした相対値であり、サンプル場所は、パックピクチャ内において整数のサンプル場所にある、
−プロジェクト領域の幅及び高さ（ｐｒｏｊＲｅｇＷｉｄｔｈ、ｐｒｏｊＲｅｇＨｅｉｇｈｔ）であって、プロジェクトピクチャサンプルを単位とした相対値である、
−パック領域の幅及び高さ（ｐａｃｋｅｄＲｅｇＷｉｄｔｈ、ｐａｃｋｅｄＲｅｇＨｅｉｇｈｔ）であって、パックピクチャサンプルを単位とした相対値である、
−変換タイプ（ｔｒａｎｓｆｏｒｍＴｙｐｅ）、及び
−サンプリング位置に対するオフセット値（ｏｆｆｓｅｔＸ、ｏｆｆｓｅｔＹ）であって、０以上、１未満の範囲にあり、それぞれ、水平及び垂直のパックピクチャサンプルを単位とした相対値である。
注記：０．５に等しいｏｆｆｓｅｔＸ及びｏｆｆｓｅｔＹは両方、パックピクチャサンプルを単位として、サンプルの中心点にあるサンプリング位置を示す。
このプロセスの出力は以下の通りである。
−プロジェクト領域内におけるサンプル場所（ｈＰｏｓ、ｖＰｏｓ）の中心点であって、ｈＰｏｓ及びｖＰｏｓは、プロジェクトピクチャサンプルを単位とした相対値であり、非整数の実数値を有してもよい。
出力は、以下のように導出される。

簡潔のため、矩形領域パック構造、ガードバンド構造、及び領域ごとのパック構造の完全なシンタックス及びセマンティクスは、本明細書では提供されないことに留意されたい。更に、領域ごとのパック変数の完全な導出、及び領域ごとのパック構造のシンタックス要素に対する制約は、本明細書では提供されない。しかしながら、ＭＰＥＧ−Ｉの関連するセクションを参照する。

上述のように、ＭＰＥＧ−Ｉは、メディアストリーミングシステムにおいて、全方位メディアのカプセル化、シグナリング、及びストリーミングを指定している。特に、ＭＰＥＧ−Ｉは、動的適応ストリーミング・オーバー・ハイパーテキストトランスファープロトコル（ＨＴＴＰ）（ＤＡＳＨ）を使用して、全方位メディアをどのようにカプセル化、シグナリング、及びストリーミングするかを指定している。ＤＡＳＨは、ＩＳＯ／ＩＥＣ：ＩＳＯ／ＩＥＣ ２３００９−１：２０１４，「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）−Ｐａｒｔ １：Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ａｎｄ ｓｅｇｍｅｎｔ ｆｏｒｍａｔｓ，」Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ，２ｎｄ Ｅｄｉｔｉｏｎ，５／１５／２０１４（以下、「ＩＳＯ／ＩＥＣ ２３００９−１：２０１４」）に記載されており、本明細書に参考として組み込まれる。ＤＡＳＨメディアプレゼンテーションは、データセグメント、ビデオセグメント、及び音声セグメントを含むことができる。いくつかの実施例では、ＤＡＳＨメディアプレゼンテーションは、サービスプロバイダによって定義された所与の期間の線形サービス又は線形サービスの一部（例えば、単一のＴＶ番組、又はある期間にわたる連続した線形ＴＶ番組のセット）に対応することができる。ＤＡＳＨによれば、メディアプレゼンテーション記述（ＭＰＤ）は、適切なＨＴＴＰ−ＵＲＬを構築し、セグメントにアクセスしてストリーミングサービスをユーザに提供するために、ＤＡＳＨクライアントによって要求されるメタデータを含むドキュメントである。ＭＰＤドキュメントフラグメントは、拡張可能マークアップ言語（extensible Markup Language、ＸＭＬ）符号化メタデータフラグメントのセットを含むことができる。ＭＰＤのコンテンツは、セグメントのためのリソース識別子及びメディアプレゼンテーション内の識別されたリソースのためのコンテキストを提供する。ＭＰＤフラグメントのデータ構造及びセマンティックは、ＩＳＯ／ＩＥＣ２３００９−１：２０１４に関して記載されている。更に、ＩＳＯ／ＩＥＣ２３００９−１のドラフト版が現在提案されているということに留意されたい。したがって、本明細書において使用されているように、ＭＰＤは、ＩＳＯ／ＩＥＣ２３００９−１：２０１４に記載されているようなＭＰＤ、現在提案されているＭＰＤ、及び／又はこれらの組み合わせを含むことができる。ＩＳＯ／ＩＥＣ２３００９−１：２０１４において、ＭＰＤに記載されているようなメディアプレゼンテーションは、１つ以上のピリオド（Period）のシーケンスを含むことができ、各ピリオドは、１つ以上のアダプテーションセット（Adaptation Set）を含むことができる。アダプテーションセットが複数のメディアコンテンツコンポーネントを含む場合、各メディアコンテンツコンポーネントを個別に記述できることに留意されたい。各アダプテーションセットは、１つ以上のリプレゼンテーション（Representation）を含むことができる。ＩＳＯ／ＩＥＣ２３００９−１：２０１４において、各リプレゼンテーションは、次のように明記されている：（１）単一セグメントの場合、サブセグメントがリプレゼンテーションにわたりアダプテーションセットに整列される、及び（２）セグメントのシーケンスの場合、各セグメントは、テンプレートで生成されたユニバーサルリソースロケータ（Universal Resource Locator、ＵＲＬ）によってアドレス指定可能である。各メディアコンテンツコンポーネントのプロパティは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素、及び／又は例えば、ＣｏｎｔｅｎｔＣｏｍｐｏｎｅｎｔ要素を含むＡｄａｐｔｉｏｎＳｅｔ内の要素によって記述することができる。球体領域構造は、様々な記述子に対してシグナリングするＤＡＳＨ記述子の基礎をなすことに留意されたい。

更に、ＭＰＥＧ−Ｉは、ＭＰＥＧメディアトランスポートを介して動的適応ストリーミングを使用して、全方位メディアをどのようにして、カプセル化、シグナリング、及びストリーミングするかを指定している。ＭＭＴは、ＩＳＯ／ＩＥＣ：ＩＳＯ／ＩＥＣ ２３００８−１，「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔｓ−Ｐａｒｔ １：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ），」に記載されており、その全体が参照として本明細書に組み込まれる。ＭＭＴがビデオデータをストリーミングするために使用される場合、ビデオデータは、メディア処理ユニット（ＭＰＵ）内にカプセル化してもよい。ＭＭＴは、ＭＰＵを、「ＭＭＴエンティティによって処理され、他のＭＰＵから独立してプレゼンテーションエンジンによって消費され得るメディアデータ項目」として定義する。ＭＰＵの論理グループ分けが、ＭＭＴアセットを形成してもよく、ＭＭＴは、「マルチメディアプレゼンテーションを作り上げるために使用される任意のマルチメディアデータとしてアセットを定義する。アセットは、符号化されたメディアデータを搬送するための同じアセット識別子を共有するＭＰＵの論理グループ分けである。」１つ以上のアセットがＭＭＴパッケージを形成してもよく、ＭＭＴパッケージは、マルチメディアコンテンツの論理コレクションである。ＩＳＯ／ＩＥＣ ２３００８−１において提供されるように、ＭＭＴコンテンツは、メディアフラグメントユニット（ＭＦＵ）、ＭＰＵ、ＭＭＴアセット、及びＭＭＴパッケージから構成される。ＭＭＴコンテンツを生成するために、符号化されたメディアデータが、ＭＦＵに分解される。ここで、ＭＦＵは、独立して復号することができる符号化ビデオデータ又は他のユニットのアクセスユニット又はスライスに対応し得る。１つ以上のＭＦＵをＭＰＵに組み合わせてもよい。ＭＭＴパッケージは、１つ以上のアセットを含むことに加えて、プレゼンテーション情報（ＰＩ）及びアセット配信特性（ＡＤＣ）を含む。プレゼンテーション情報は、アセット間の空間的関係及び時間的関係を指定する文書（ＰＩ文書）を含む。場合によっては、パッケージ内のアセットの配信順序を決定するためにＰＩ文書を使用してもよい。ＰＩ文書は、１つ以上のシグナリングメッセージとして配信してもよい。シグナリングメッセージは、１つ以上のテーブルを含んでもよい。アセット配信特性は、配信に対するサービス品質（ＱｏＳ）要件及びアセット統計について記載している。

ＭＰＥＧ−Ｉは、ＯＭＡＦ仕様に従ってフォーマットされたＶＲコンテンツをストリーミングする目的で、アセット記述子及びアプリケーション固有シグナリングメッセージが定義される場合について記載している。ＭＰＥＧ−Ｉでは、以下のアプリケーションメッセージタイプが定義される。
・ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＱｕｅｒｙ：クライアントは、サーバがビュー依存ストリーミングをサポートしているかどうかを知るために、このコマンドを使用する
・ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＲｅｓｐｏｎｓｅ：サーバは、ビュー依存ストリーミングに対する、そのサポート能力の指示を伴って返信する。
・ＶＲＶｉｅｗｐｏｒｔＣｈａｎｇｅＦｅｅｄｂａｃｋ：受信エンティティは、現在のビューポートの指示を送信エンティティに送信する。
・ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＡｓｓｅｔｓＩｎｆｏｒｍａｔｉｏｎ：要求されたビューポートに一致するＯＭＡＦアセットのセットを決定した時点で、送信エンティティは、このメッセージを送信して、受信エンティティにストリーミングされることになる新しいＯＭＡＦ Ａｓｓｅｔについてクライアントに通知する。

表１は、ＭＰＥＧ−Ｉで定義されるアプリケーションメッセージのタイプを含む。表１に示すように、上述のメッセージタイプに加えて、ＭＰＥＧ−Ｉは、ガイドされたレンダリングをサポートするためのＶＲ−ＲＯＩＧｕｉｄｅアプリケーションメッセージと、音声情報をシグナリングするためのＶＲ３ＤＡｕｄｉｏＡｓｓｅｔＩｎｆｏｒｍａｔｉｏｎアプリケーション固有メッセージとを含む。

ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＲｅｓｐｏｎｓｅに関して、ＭＰＥＧ−Ｉは、表２に示すシンタックス及び以下のセマンティクスを提供する。表２及び下記の表において、ｕｉｍｓｂｆは、最上位ビットが先頭である符号なし整数のデータタイプを指し、ｂｓｌｂｆは左ビットが先頭であるビット列のデータタイプを指すことに留意されたい。

ｍｅｓｓａｇｅ＿ｉｄは、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＱｕｅｒｙメッセージの識別子を示し、ｖｅｒｓｉｏｎは、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＱｕｅｒｙメッセージのバージョンを示し、ｌｅｎｇｔｈは、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＱｕｅｒｙメッセージを、次のフィールドの最初からＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＱｕｅｒｙメッセージの最終バイトへと数えたときの長さをバイトで示す。このフィールドの値は、０に等しくないものとする。ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒは、アプリケーションがこのメッセージの内容を消費することを一意に識別するｕｒｎとしてのアプリケーション識別子を示す。ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅは、表１に提供されるアプリケーション固有メッセージタイプを定義する。ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされているかどうかを示す。

ＶＲ３ＤＡｕｄｉｏＡｓｓｅｔｌｎｆｏｒｍａｔｉｏｎに関して、ＭＰＥＧ−Ｉは、表３に示すシンタックス及び以下のセマンティクスを提供する。表３では簡潔にするために、各アセットに対する音声情報シンタックスは示されていないことに留意されたい。しかしながら、表３では、「ｕｒｎ：ｍｐｅｇ：ｍｍｔ：ａｐｐ：ｖｒ：２０１７」に等しいアプリケーション識別子に対応する各メッセージについて、全ての音声情報シンタックスがシグナリングされることに留意されたい。

ｍｅｓｓａｇｅ＿ｉｄは、ＶＲ３ＤＡｕｄｉｏＡｓｓｅｔＩｎｆｏｒｍａｔｉｏｎメッセージの識別子を示し、ｖｅｒｓｉｏｎは、ＶＲ３ＤＡｕｄｉｏＡｓｓｅｔＩｎｆｏｒｍａｔｉｏｎメッセージのバージョンを示し、ｌｅｎｇｔｈは、ＶＲ３ＤＡｕｄｉｏＡｓｓｅｔＩｎｆｏｒｍａｔｉｏｎメッセージを、次のフィールドの最初からＶＲ３ＤＡｕｄｉｏＡｓｓｅｔＩｎｆｏｒｍａｔｉｏｎメッセージの最終バイトへと数えたときの長さをバイトで示す。このフィールドの値は、０に等しくないものとする。ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒは、アプリケーションがこのメッセージの内容を消費することを一意に識別するｕｒｎとしてのアプリケーション識別子を示す。
ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔｓは、この記述子によって記述される音声アセットの数を指定する。
ａｓｓｅｔ＿ｉｄ＿ｌｅｎｇｔｈは、音声アセットｉｄの長さをバイトで指定する。ａｓｓｅｔ＿ｉｄ＿ｂｙｔｅは、音声アセットｉｄのバイトを含む。

ＭＥＰＧ−Ｉで定義されるアプリケーション固有のシグナリングメッセージは、理想的ではない場合がある。

図１は、本開示の１つ以上の技術による、ビデオデータをコード化する（符号化及び／又は復号する）ように構成することができる、システムの例を示すブロック図である。システム１００は、本開示の１つ以上の技術に従って、ビデオデータをカプセル化することができるシステムの例を表す。図１に示すように、システム１００は、ソースデバイス１０２と、通信媒体１１０と、目的デバイス１２０と、を含む。図１に示す例では、ソースデバイス１０２は、ビデオデータを符号化し、符号化したビデオデータを通信媒体１１０に送信するように構成された、任意のデバイスを含むことができる。目的デバイス１２０は、通信媒体１１０を介して符号化したビデオデータを受信し、符号化したビデオデータを復号するように構成された、任意のデバイスを含むことができる。ソースデバイス１０２及び／又は目的デバイス１２０は、有線及び／又は無線通信用に装備された演算デバイスを含むことができ、かつ、例えば、セットトップボックス、デジタルビデオレコーダ、テレビ、デスクトップ、ラップトップ、又はタブレットコンピュータ、ゲーム機、医療用撮像デバイス、及び、例えば、スマートフォン、セルラー電話、パーソナルゲームデバイスを含むモバイルデバイス、を含むことができる。

通信媒体１１０は、無線及び有線の通信媒体並びに／又は記憶デバイスの任意の組み合わせを含むことができる。通信媒体１１０としては、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、無線送信機及び受信機、ルータ、スイッチ、リピータ、基地局、又は様々なデバイスとサイトとの間の通信を容易にするために有用であり得る任意の他の機器を挙げることができる。通信媒体１１０は、１つ以上のネットワークを含むことができる。例えば、通信媒体１１０は、ワールドワイドウェブ、例えば、インターネットへのアクセスを可能にするように構成されたネットワークを含むことができる。ネットワークは、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。標準化された電気通信プロトコルの例としては、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）規格、Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ（ＡＴＳＣ）規格、Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｂｒｏａｄｃａｓｔｉｎｇ（ＩＳＤＢ）規格、Ｄａｔａ Ｏｖｅｒ Ｃａｂｌｅ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＤＯＣＳＩＳ）規格、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）規格、符号分割多重アクセス（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、ＤＯＣＳＩＳ）規格、ＨｂｂＴＶ規格、Ｗ３Ｃ規格、及びＵＰｎＰ規格が挙げられる。

図７を再び参照すると、テレビサービスプロバイダサイト４０６は、テレビサービスネットワーク４０４を介してテレビサービスを配布するように構成することができる。例えば、テレビサービスプロバイダサイト４０６は、１つ以上の放送局、ケーブルテレビプロバイダ、又は衛星テレビプロバイダ、又はインターネットベースのテレビプロバイダを含み得る。例えば、テレビサービスプロバイダサイト４０６は、衛星アップリンク／ダウンリンクを介したテレビプログラムを含む送信を、受信するように構成することができる。更に、図７に示すように、テレビサービスプロバイダサイト４０６は、ワイドエリアネットワーク４０８と通信することができ、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎからデータを受信するように構成することができる。いくつかの実施例では、テレビサービスプロバイダサイト４０６は、テレビスタジオを含むことができ、コンテンツはそこから発信できることに留意されたい。

ワイドエリアネットワーク４０８は、パケットベースのネットワークを含み、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、汎欧州デジタル移動電話方式（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（ＧＳＭ）規格、符号分割多元接続（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）（ＣＤＭＡ）規格、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）規格、欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）（ＥＴＳＩ）規格、欧州規格（ＥＮ）、ＩＰ規格、ワイヤレスアプリケーションプロトコル（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＷＡＰ）規格、及び例えば、ＩＥＥＥ８０２規格のうちの１つ以上（例えば、Ｗｉ−Ｆｉ）などの電気電子技術者協会（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）（ＩＥＥＥ）規格が挙げられる。ワイドエリアネットワーク４０８は、無線通信メディア及び／又は有線通信メディアの任意の組み合わせを含むことができる。ワイドエリアネットワーク４８０は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、イーサネットケーブル、無線送信部及び受信部、ルータ、スイッチ、リピータ、基地局、又は様々なデバイス及びサイト間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。一実施例では、ワイドエリアネットワーク４０８はインターネットを含んでもよい。ローカルエリアネットワーク４１０は、パケットベースのネットワークを含み、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。ローカルエリアネットワーク４１０は、アクセス及び／又は物理インフラストラクチャのレベルに基づいてワイドエリアネットワーク４０８と区別することができる。例えば、ローカルエリアネットワーク４１０は、セキュアホームネットワークを含んでもよい。

図７を再び参照すると、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、マルチメディアコンテンツをテレビサービスプロバイダサイト４０６及び／又は演算デバイス４０２Ａ〜４０２Ｎに提供することができるサイトの例を表す。例えば、コンテンツプロバイダサイトは、マルチメディアファイル及び／又はストリームをテレビサービスプロバイダサイト４０６に提供するように構成されている、１つ以上のスタジオコンテンツサーバを有するスタジオを含むことができる。一実施例では、コンテンツプロバイダのサイト４１２Ａ〜４１２Ｎは、ＩＰスイートを使用してマルチメディアコンテンツを提供するように構成してもよい。例えば、コンテンツプロバイダサイトは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ＨＴＴＰなどに従って、マルチメディアコンテンツを受信デバイスに提供するように構成してもよい。更に、コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、ハイパーテキストベースのコンテンツなどを含むデータを、ワイドエリアネットワーク４０８を通じて、受信デバイスである演算デバイス４０２Ａ〜４０２Ｎ、及び／又はテレビサービスプロバイダサイト４０６のうちの１つ以上に提供するように構成してもよい。コンテンツプロバイダサイト４１２Ａ〜４１２Ｎは、１つ以上のウェブサーバを含んでもよい。データプロバイダサイト４１２Ａ〜４１２Ｎによって提供されるデータは、データフォーマットに従って定義することができる。

図１を再び参照すると、ソースデバイス１０２は、ビデオソース１０４と、ビデオエンコーダ１０６と、データカプセル化装置１０７と、インターフェース１０８とを含む。ビデオソース１０４は、ビデオデータをキャプチャ及び／又は記憶するように構成された任意のデバイスを含むことができる。例えば、ビデオソース１０４は、ビデオカメラ及びそれに動作可能に結合された記憶デバイスを含むことができる。ビデオエンコーダ１０６は、ビデオデータを受信し、ビデオデータを表す適合したビットストリームを生成するように構成された、任意のデバイスを含むことができる。適合したビットストリームは、ビデオデコーダが受信し、それからビデオデータを再生することができるビットストリームを指すことがある。適合したビットストリームの態様は、ビデオ符号化標準に従って定義することができる。適合したビットストリームを生成するとき、ビデオエンコーダ１０６は、ビデオデータを圧縮することができる。圧縮は、非可逆的（視聴者に認識可能若しくは認識不可能）又は可逆的とすることができる。

再び図１を参照すると、データカプセル化装置１０７は、符号化ビデオデータを受信し、定義されたデータ構造に従って、例えば、一連のＮＡＬユニットである準拠ビットストリームを生成することができる。準拠ビットストリームを受信するデバイスは、そこからビデオデータを再生成することができる。適合ビットストリームという用語は、準拠ビットストリームという用語の代わりに使用され得ることに留意されたい。データカプセル化装置１０７は、ビデオエンコーダ１０６と同じ物理デバイス内に配置される必要はないことに留意されたい。例えば、ビデオエンコーダ１０６及びデータカプセル化装置１０７によって実行されるものとして説明される機能は、図７に示すデバイス間で配布してもよい。一実施例では、データカプセル化装置１０７は、１つ以上のメディアコンポーネントを受信し、ＤＡＳＨ及び／又はＭＭＴに基づいてメディアプレゼンテーションを生成するように構成されたデータカプセル化装置を含むことができる。

データカプセル化装置１０７は、メディアプレゼンテーション記述フラグメントを生成するように構成してもよい。データカプセル化装置１０７は、メディアコンポーネントを受信し、メディアプレゼンテーションに含めるための１つ以上のセグメントを生成するように構成してもよい。データカプセル化装置１０７は、本明細書に記載された技術に従ってパッケージを生成するように構成してもよい。データカプセル化装置１０７は、符号化されたビデオデータを受信し、パッケージに含めるための１つ以上のアセットを生成するように構成してもよい。データカプセル化装置１０７は、パッケージに含まれるアセットに関する情報を受信し、ＱｏＳ要件を提供するように構成してもよい。データカプセル化装置１０７は、プレゼンテーション情報文書を生成するように構成してもよい。

上述のように、ＭＰＥＧ−Ｉで定義されるアプリケーション固有のシグナリングメッセージは、理想的ではない場合がある。例えば、上述のように、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＲｅｓｐｏｎｓｅメッセージに関して、７ビットのシンタックス要素に対して、以下のセマンティクス、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔが提供され、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされているかどうかを示す。

しかしながら、ＭＰＥＧ−Ｉは、ビュー依存ストリーミングがサーバによってサポートされているかどうかを示すために、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔの７ビットがどのように使用されるかを示すことができない。本明細書の技術によれば、データカプセル化装置１０７は、表２に提供されたシンタックスに従って、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＲｅｓｐｏｎｓｅメッセージをシグナリングするように構成してもよい。ここで、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは以下のセマンティクスを有する。１に等しいｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされていることを指定し、０に等しいｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされていないことを指定する。値２〜１２７は予約済みである。

別の例では、１ビットは、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔをｂｓｌｂｆとしてシグナリングするために使用してもよく、７ビットは、ｕｉｍｓｂｆとして‘１１１１１１１’として予約済みのままとなる。この場合、ｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔのセマンティクスは、以下の通りであってもよい。
１に等しいｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされていることを指定する。０に等しいｖｉｅｗ＿ｄｅｐｅｎｄｅｎｔ＿ｓｕｐｐｏｒｔは、ビュー依存ストリーミングがサーバによってサポートされていないことを指定する。

ＶＲ３ＤＡｕｄｉｏＡｓｓｅｔｌｎｆｏｒｍａｔｉｏｎに関して、本明細書の技術によれば、データカプセル化装置１０７は、上記の表４に提供されたシンタックスに従って、ＶＲＶｉｅｗＤｅｐｅｎｄｅｎｔＳｕｐｐｏｒｔＲｅｓｐｏｎｓｅメッセージをシグナリングするように構成してもよい。表４では簡潔にするために、各アセットに対する音声情報シンタックスは示されていないことに留意されたい。更に、表４では、シンタックス要素である、ｍｅｓｓａｇｅ＿ｉｄ、ｖｅｒｓｉｏｎ、ｌｅｎｇｔｈ、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ、ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔｓ、ａｓｓｅｔ＿ｉｄ＿ｌｅｎｇｔｈ、及びａｓｓｅｔ＿ｉｄ＿ｂｙｔｅは、上述のセマンティクスを有し得ることに留意されたい。

一実施例では、本明細書の技術によれば、ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅは、以下のセマンティクスを有し得る。

ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅは、表１に提供されるアプリケーション固有メッセージタイプを定義する。
このようにして、データカプセル化装置１０７は、アプリケーション固有メッセージタイプを定義するシンタックス要素を、音声情報をシグナリングするアプリケーション固有メッセージ内に含み、条件付きで、アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素をシグナリングするように構成されている。

別の例では、ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅが上記の表４の０ｘ０６に等しい代わりに、いくつかの他の値を使用してもよい。例えば、値０ｘ０７を使用してもよい。

再び図１を参照すると、インターフェース１０８は、データカプセル化装置１０７によって生成されたデータを受信し、データを送信及び／又は通信メディアに記憶するように構成された任意のデバイスを含んでもよい。インターフェース１０８は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を送信及び／若しくは受信することができる任意の他の種類のデバイスを含んでもよい。更に、インターフェース１０８は、ファイルを記憶デバイス上に記憶することを可能にすることができるコンピュータシステムインターフェースを含むことができる。例えば、インターフェース１０８は、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスプロトコル及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスプロトコル、独自のバスプロトコル、ユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）（ＵＳＢ）プロトコル、Ｉ２Ｃ、又はピアデバイスを相互接続するために使用することができる任意の他の論理及び物理構造をサポートする、チップセットを含むことができる。

図１を再び参照すると、目的デバイス１２０は、インターフェース１２２と、データ脱カプセル化装置１２３と、ビデオデコーダ１２４と、ディスプレイ１２６とを含む。インターフェース１２２は、通信媒体からデータ受信するように構成されている任意のデバイスを含むことができる。インターフェース１２２は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を受信及び／若しくは送信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース１２２は、適合したビデオビットストリームを記憶デバイスから取得することを可能にするコンピュータシステム用インターフェースを含むことができる。例えば、インターフェース１２２は、ＰＣＩバスプロトコル及びＰＣＩｅバスプロトコル、独自のバスプロトコル、ＵＳＢプロトコル、Ｉ２Ｃ、又はピアデバイスを相互接続するために使用することができる任意の他の論理及び物理構造をサポートする、チップセットを含むことができる。データデカプセル化部１２３は、データカプセル化部１０７によって生成されたビットストリームを受信し、本明細書に記載された技術のうちの１つ以上に従ってサブビットストリーム抽出を実行するように構成することができる。

ビデオデコーダ１２４は、ビットストリーム及び／又はその許容可能な変形を受信し、それからビデオデータを再生するように構成されている任意のデバイスを含むことができる。ディスプレイ１２６は、ビデオデータを表示するように構成された任意のデバイスを含むことができる。ディスプレイ１２６は、液晶ディスプレイ（liquid crystal display、ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（organic light emitting diode、ＯＬＥＤ）ディスプレイ、又は別の種類のディスプレイなどの、様々なディスプレイデバイスのうちの１つを含むことができる。ディスプレイ１２６は、高解像度ディスプレイ又は超高解像度ディスプレイを含むことができる。ディスプレイ１２６は、ステレオスコープディスプレイを含んでもよい。図１に示す例では、ビデオデコーダ１２４は、データをディスプレイ１２６に出力するように説明されているが、ビデオデコーダ１２４は、ビデオデータを様々な種類のデバイス及び／又はそのサブコンポーネントに出力するように構成することができることに留意されたい。例えば、ビデオデコーダ１２４は、本明細書で説明するような任意の通信媒体にビデオデータを出力するように構成することができる。宛先デバイス１２０は、受信デバイスを含むことができる。

図８は、本開示の１つ以上の技術を実施できる受信デバイスの例を示すブロック図である。すなわち、受信デバイス６００は、上述のセマンティクスに基づいて信号をパースするように構成してもよい。更に、受信デバイス６００は、本明細書に記載される予想されるプレイ挙動に従って動作するように構成してもよい。更に、受信デバイス６００は、本明細書に記載される変換技術（translation technique）を実行するように構成してもよい。受信デバイス６００は、通信ネットワークからデータを受信し、仮想現実アプリケーションを含むマルチメディアコンテンツにユーザがアクセスすることを可能にするように構成され得る演算デバイスの一例である。図８に示す実施例では、受信デバイス６００は、例えば上述のテレビサービスネットワーク４０４などの、テレビネットワークを介してデータを受信するように構成されている。更に、図８に示す例では、受信デバイス６００は、ワイドエリアネットワークを介してデータを送受信するように構成されている。他の実施例では、受信デバイス６００は、テレビサービスネットワーク４０４を介して単にデータを受信するように構成してもよいことに留意されたい。本明細書に記載された技術は、通信ネットワークのうちのいずれか及び全ての組み合わせを使用して通信するように構成されているデバイスによって利用され得る。

図８に示すように、受信デバイス６００は、中央処理装置（単数又は複数）６０２、システムメモリ６０４、システムインターフェース６１０、データ抽出装置６１２、音声デコーダ６１４、音声出力システム６１６、ビデオデコーダ６１８、表示システム６２０、Ｉ／Ｏデバイス（単数又は複数）６２２、及びネットワークインターフェース６２４を含む。図８に示すように、システムメモリ６０４は、オペレーティングシステム６０６及びアプリケーション６０８を含む。中央処理装置（単数又は複数）６０２、システムメモリ６０４、システムインターフェース６１０、データ抽出装置６１２、音声デコーダ６１４、音声出力システム６１６、ビデオデコーダ６１８、表示システム６２０、Ｉ／Ｏデバイス（単数又は複数）６２２、及びネットワークインターフェース６２４の各々は、コンポーネント間通信のために（物理的、通信的、及び／又は動作的に）相互接続してもよく、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（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、ＩＣ）、又はＩＣのセット（例えば、チップセット）を含む多種多様なデバイス又は装置に実装することができる。様々なコンポーネント、モジュール、又はユニットは、開示された技術を実行するように構成されたデバイスの機能的な態様を強調するために本開示中に記載されているが、異なるハードウェアユニットによる実現は必ずしも必要ではない。むしろ、前述したように、様々なユニットは、コーデックハードウェアユニットと組み合わせてもよく、又は好適なソフトウェア及び／又はファームウェアと共に、前述の１つ以上のプロセッサを含む、相互動作ハードウェアユニットの集合によって提供することができる。

更に、上述の各実装形態で用いた基地局装置や端末装置の各機能ブロックや各種の機能は、一般的には集積回路又は複数の集積回路である電気回路によって実現又は実行することができる。本明細書に記載の機能を実行するように設計された回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け又は汎用アプリケーション集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタロジック、若しくは個々のハードウェアコンポーネント、又はそれらの組み合わせを備えていてもよい。汎用プロセッサは、マイクロプロセッサでもよく、あるいは、プロセッサは、従来のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンでもよい。上述した汎用プロセッサ又は各回路は、デジタル回路で構成しても、又はアナログ回路で構成してもよい。更に、半導体技術の進歩により現時点での集積回路に置き換わる集積回路化技術が現れれば、この技術による集積回路もまた使用可能となる。

様々な実施例について説明した。これら及び他の実施例は、以下の特許請求の範囲内である。

＜相互参照＞
本特許出願は、米国特許法第１１９条の下で、２０１８年４月１６日の仮出願第６２／６５８，５２９号の優先権を主張するものであり、その内容の全体は、参照により本明細書に組み込まれる。

Claims (5)

1. 全方位ビデオに関連付けられた情報をシグナリングするための方法であって、
   アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいてシンタックス要素を条件付きでシグナリングすることを含む、音声情報を示すアプリケーション固有メッセージをシグナリングするステップを含む、方法。
2. 全方位ビデオに関連付けられた情報を決定する方法であって、
   アプリケーション固有メッセージタイプを定義するシンタックス要素の値に基づいて、シンタックス要素を条件付きでパースすることを含む、音声情報を示すアプリケーション固有メッセージをパースするステップを含む、方法。
3. 請求項１又は２に記載のステップのいずれか及び全ての組み合わせを実行するように構成されている１つ以上のプロセッサを備える、デバイス。
4. 請求項１又は２に記載のステップのいずれか及び全ての組み合わせを実行する手段を備える、装置。
5. 記憶された命令を含む非一時的コンピュータ可読記憶媒体であって、前記命令は実行されると、デバイスの１つ以上のプロセッサに、請求項１又は２に記載のステップのいずれか及び全ての組み合わせを実行させる、非一時的コンピュータ可読記憶媒体。

Images