JP2021526756A

JP2021526756A - 全方位ビデオに関連付けられたオーバーレイ情報を決定する方法、装置、および記録媒体

Info

Publication number: JP2021526756A
Application number: JP2020567260A
Authority: JP
Inventors: サーチンジー．デシュパンダ
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2018-06-04
Filing date: 2019-05-28
Publication date: 2021-10-07
Also published as: WO2019235305A1; CN112237004A; US20210219013A1

Abstract

デバイスは全方位ビデオに関連付けられたオーバーレイ情報をシグナリングするように構成することができる。複数のオーバーレイのそれぞれについて、一意の識別子及びラベルがシグナリングされる。(段落【００７５】参照。)複数のオーバーレイに時間変化する更新がシグナリングされる。(段落【００７８】参照。)

Description

本開示は、対話型ビデオ配信の分野に関し、より具体的には、仮想現実アプリケーションにおいてオーバーレイ情報をシグナリングする技術に関する。

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

デジタルメディアコンテンツに含まれるデジタルビデオは、ビデオ符号化規格に従って符号化することができる。ビデオ符号化規格-は、ビデオ圧縮技術を組み込むことができる。ビデオ符号化規格の例としては、ISO/IEC MPEG-4 Visual及びITU-T H.264(ISO/IEC MPEG-4 AVCとしても公知である)並びにHigh-Efficiency Video Coding(HEVC)が挙げられる。ビデオ圧縮技術は、ビデオデータを記憶し送信するためのデータ要件を低減することを可能にする。ビデオ圧縮技術は、ビデオ系列における固有の冗長性を利用することにより、データ要件を低減することができる。ビデオ圧縮技術は、ビデオ系列を連続的により小さな部分(すなわち、ビデオ系列内のフレームの群、フレームの群内のフレーム、フレーム内のスライス、スライス内の符号化ツリーユニット(例えば、マクロブロック)、符号化ツリーユニット内の符号化ブロックなど)に再分割することができる。予測符号化技術を使用して、符号化されるビデオデータのユニットとビデオデータの参照ユニットとの間の差分値を生成することができる。差分値は、残差データと呼ばれることがある。残差データは、量子化された変換係数として符号化することができる。シンタックス要素は、残差データと参照符号化ユニットとを関連付けることができる。残差データ及びシンタックス要素は、準拠ビットストリームに含めることができる。準拠ビットストリーム及び関連メタデータは、データ構造に従ったフォーマットを有してもよい。準拠ビットストリーム及び関連メタデータは、送信規格に従って、ソースから受信デバイス(例えば、デジタルテレビ又はスマートフォン)に送信してもよい。伝送規格の例としては、デジタルビデオブロードキャスティング(Digital Video Broadcasting、DVB)規格、統合デジタル放送サービス規格(Integrated Services Digital Broadcasting、ISDB)規格、及び例えば、ATSC2.0規格を含む、高度テレビジョンシステムズ委員会(Advanced Television Systems Committee、ATSC)によって作成された規格が挙げられる。ATSCは、現在、いわゆるATSC3.0の一連の規格を開発している。

一実施例では、全方位ビデオに関連付けられたオーバーレイ情報をシグナリングする方法は、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングすることと、複数のオーバーレイに時間変化する更新をシグナリングすることと、を含む。

一実施例では、全方位ビデオに関連付けられたオーバーレイ情報を決定する方法は、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルを示すシンタックス要素をパースすることと、パ-スされたシンタックス要素の値に基づいてビデオをレンダリングすることと、を含む。

本開示の1つ以上の技術による、符号化されたビデオデータを送信するように構成することができるシステムの一例を示すブロック図である。本開示の1つ以上の技術による、符号化されたビデオデータ構造及び対応するデータ構造を示す概念図である。本開示の1つ以上の技術による、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。本開示の1つ以上の技術による、符号化されたビデオデータ及び対応するデータ構造を示す概念図である。本開示の1つ以上の技術による、座標系の一例を示す概念図である。本開示の1つ以上の技術による、球体上の特定領域の例を示す概念図である。本開示の1つ以上の技術による、球体上の特定領域の例を示す概念図である。本開示の1つ以上の技術による、符号化されたビデオデータを送信するように構成することができるシステムの実装形態に含まれ得る構成要素の一例を示す概念図である。本開示の1つ以上の技術を実装することができる受信デバイスの一例を示すブロック図である。

一般に、本開示は、仮想現実アプリケーションに関連付けられた情報をシグナリングするための種々の技術を説明する。具体的には、本開示は、オーバーレイ情報をシグナリングするための技術について説明する。いくつかの実施例では、本開示の技術は、伝送規格に関して説明されているが、本明細書において説明される技術は、一般に適用可能であってよいことに留意されたい。例えば、本明細書で説明する技術は、一般に、DVB規格、ISDB規格、ATSC規格、Digital Terrestrial Multimedia Broadcast(DTMB)規格、Digital Multimedia Broadcast(DMB)規格、Hybrid Broadcast and Broadband Television(HbbTV)規格、ワールド・ワイド・ウェブ・コンソーシアム(World Wide Web Consortium、W3C)規格、及びユニバーサルプラグアンドプレイ(Universal Plug and Play、UPnP)規格のうちのいずれかに適用可能である。更に、本開示の技術は、ITU-T H.264及びITU-T H.265に関して説明されているが、本開示の技術は、全方位ビデオ符号化を含むビデオ符号化に一般に適用可能であることに留意されたい。例えば、本明細書で説明する符号化技術は、ITU-T H.265に含まれるもの以外のブロック構造、イントラ予測技術、インター予測技術、変換技術、フィルタリング技術、及び/又はエントロピ符号化技術を含むビデオ符号化システム(将来のビデオ符号化規格に基づくビデオ符号化システムを含む)に組み込むことができる。したがって、ITU-T H.264及びITU-T H.265への参照は、説明のためのものであり、本明細書で説明する技術の範囲を限定するように解釈すべきではない。更に、本明細書での文書の参照による組み込みは、本明細書で使用される用語に関して限定する又は曖昧さを生むように解釈されるべきではないことに留意されたい。例えば、組み込まれた参照が、別の組み込まれた参照のものとは異なる用語の定義を与える場合、かつ/又はその用語が本明細書で使用されるような場合には、その用語は、それぞれの対応する定義を幅広く含むように、及び/又は代わりに特定の定義のそれぞれを含むように解釈されるべきである。

一実施例では、デバイスは、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングし、かつ複数のオーバーレイに時間変化する更新をシグナリングするように構成されている1つ以上のプロセッサを備える。

一実施例では、非一時的コンピュータ可読記憶媒体は、媒体上に記憶された命令を含み、この命令は実行されると、デバイスの1つ以上のプロセッサに、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングさせ、かつ複数のオーバーレイに時間変化する更新をシグナリングさせる。

一実施例では、装置は、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングする手段と、複数のオーバーレイに時間変化する更新をシグナリングする手段と、を備える。

一実施例では、デバイスは、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルを示すシンタックス要素をパースし、かつパ-スされたシンタックス要素の値に基づいてビデオをレンダリングするように構成されている1つ以上のプロセッサを備える。

一実施例では、非一時的コンピュータ可読記憶媒体は、媒体上に記憶された命令を含み、この命令は実行されると、デバイスの1つ以上のプロセッサに、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルを示すシンタックス要素をパースさせ、かつパ-スされたシンタックス要素の値に基づいてビデオをレンダリングさせる。

一実施例では、装置は、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルを示すシンタックス要素をパースする手段と、パ-スされたシンタックス要素の値に基づいてビデオをレンダリングする手段と、を備える。

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

ビデオコンテンツは、典型的には、一連のフレームからなるビデオシーケンスを含む。一連のフレームはまた、ピクチャ群(group of pictures、GOP)と呼ばれることがある。各ビデオフレーム又はピクチャは1つ以上のスライスを含むことができ、スライスは複数のビデオブロックを含む。ビデオブロックは、予測的に符号化され得る画素値(サンプルとも呼ばれる)の最大アレイとして定義することができる。ビデオブロックは、走査パターン(例えば、ラスター走査)に従って順序付けすることができる。ビデオエンコーダは、ビデオブロック及びその再分割に対して予測符号化を実行する。ITU-T H.264は、16×16のルマ(luma)サンプルを含むマクロブロックを規定する。ITU-T H.265は、類似の符号化ツリーユニット(Coding Tree Unit、CTU)構造を規定するが、ピクチャは、等しいサイズのCTUに分割することができ、各CTUは、16×16、32×32、又は64×64のルマサンフ゜ルを有する符号化ツリーフ゛ロック(Coding Tree Block、CTB)を含むことができる。本明細書で使用されるとき、ビデオブロックという用語は、一般に、ピクチャの領域を指すことがあり、又はより具体的には、予測的に符号化できる画素値の最大アレイ、その再分割、及び/又は対応する構造を指すことがある。更に、ITU-T H.265によれば、各ビデオフレーム又はピクチャは、1つ以上のタイルを含むように区画化してもよく、タイルは、ピクチャの矩形領域に対応する符号化ツリーユニットのシーケンスである。

ITU-T H.265では、CTUのCTBは、対応する四分木ブロック構造に従って符号化ブロック(CB)に区画化することができる。ITU-T H.265によれば、1つのルマCBは、2つの対応するクロマCB及び関連するシンタックス要素と共に、符号化ユニット(CU)と呼ばれる。CUは、CUに対する1つ以上の予測部(prediction unit、PU)を定義する予測部(PU)構造に関連し、PUは、対応する参照サンプルに関連する。すなわち、ITU-T H.265では、イントラ予測又はインター予測を使用してピクチャ領域を符号化する決定がCUレベルで行われ、CUに関し、イントラ予測又はインター予測に対応する1つ以上の予測を使用して、CUのCBに対する参照サンプルを生成することができる。ITU-T H.265では、PUは、ルマ及びクロマ予測ブロック(prediction block、PB)を含むことができ、正方形PBはイントラ予測に対してサポートされ、矩形PBはインター予測に対してサポートされる。イントラ予測データ(例えば、イントラ予測モードシンタックス要素)又はインター予測データ(例えば、動きデータシンタックス要素)は、PUを対応する参照サンプルに関連させることができる。残差データは、ビデオデータの各成分(例えば、ルマ(Y)及びクロマ(Cb及びCr))に対応する差分値のそれぞれのアレイを含むことができる。残差データは、画素領域内とすることができる。離散コサイン変換(discrete cosine transform、DCT)、離散サイン変換(discrete sine transform、DST)、整数変換、ウェーブレット変換、又は概念的に類似の変換などの変換を、画素差分値に適用して、変換係数を生成することができる。ITU-T H.265では、CUは、更に変換ユニット(TTransform Unit、TU)に再分割できることに留意されたい。すなわち、画素差分値のアレイは、変換係数を生成するために再分割することができ(例えば、4つの8×8変換を、16×16のルマCBに対応する残差値の16×16のアレイに適用することができる)、そのような再分割は、変換ブロック(Transform Block、TB)と呼ばれることがある。変換係数は、量子化パラメータ(quantization parameter、QP)に従って量子化され得る。量子化された変換係数(これはレベル値と呼ばれることがある)は、エントロピ符号化技術(例えば、コンテンツ適応可変長符号化(content adaptive variable length coding、CAVLC)、コンテキスト適応2値算術符号化(context adaptive binary arithmetic coding、CABAC)、確率区間分割エントロピ符号化(probability interval partitioning entropy coding、PIPE)など)に従ってエントロピ符号化することができる。更に、シンタックス要素、例えば、予測モードを示すシンタックス要素なども、エントロピ符号化することができる。エントロピ符号化され量子化された変換係数及び対応するエントロピ符号化されたシンタックス要素は、ビデオデータを再生成するために使用することができる準拠ビットストリームを形成することができる。二値化プロセスを、エントロピ符号化プロセスの一部としてシンタックス要素に対して実行することができる。二値化は、シンタックス値を一連の1つ以上のビットに変換するプロセスを指す。これらのビットは、「ビン」と呼ばれることがある。
仮想現実(VR)アプリケーションは、ヘッドマウントディスプレイでレンダリングすることができるビデオコンテンツを含むことができ、ユーザの頭部の向きに対応する全天球映像の領域のみがレンダリングされる。VRアプリケーションは、360度ビデオの360度全天球映像とも呼ばれる、全方位ビデオによって使用可能にすることができる。全方位ビデオは、典型的には、最大360度のシーンをカバーする複数のカメラによってキャプチャされる。通常のビデオと比較した全方位ビデオの明確な特徴は、典型的には、キャプチャされたビデオ領域全体のサブセットのみが表示される、すなわち、現在のユーザの視野(FOV)に対応する領域が表示されることである。FOVはまた、時に、ビューポートとも呼ばれる。他の場合では、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部として説明することができる。ビューポートのサイズは、視野以下でもよいことに留意されたい。更に、全方位ビデオは、モノスコープカメラ又はステレオスコープカメラを使用してキャプチャされ得ることに留意されたい。モノスコープカメラは、オブジェクトの単一視野をキャプチャするカメラを含んでもよい。ステレオスコープカメラは、同じオブジェクトの複数のビューをキャプチャするカメラを含んでもよい(例えば、わずかに異なる角度で2つのレンズを使用してビューをキャプチャする)。場合によっては、ビューポートの中心点は、視点と呼ばれることもあるという点に留意すべきである。しかしながら、本明細書で使用するとき、カメラに関連付けられた場合の視点(例えば、カメラ視点)という用語は、オブジェクトのビュー(単数又は複数)をキャプチャするために使用されるカメラに関連付けられた情報(例えば、カメラパラメータ)を指し得る。更に、場合によっては、全方位ビデオアプリケーションで使用するための画像は、超広角レンズ(すなわち、いわゆる魚眼レンズ)を使用してキャプチャされ得ることに留意されたい。いずれの場合も、360度の球面ビデオを作成するためのプロセスは、一般に、入力画像をつなぎ合わせること、つなぎ合わされた入力画像を3次元構造(例えば、球体又は立方体)上にプロジェクションして、いわゆるプロジェクトフレームをもたらし得ることとして説明することができる。更に、場合によっては、プロジェクトフレームの領域を、変換し、リサイズし、及び再配置してもよく、これによっていわゆるパックフレームをもたらすことができる。

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

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

参照により本明細書に組み込まれ、また本明細書においてはWangと記す、Wangらの、ISO/IEC JTC1/SC29/WG11 N17584、「WD 1 of ISO/IEC 23090-2 OMAF 2nd edition」、April 2018、San Diego、USでは、全方位メディアアプリケーションを可能にするメディアアプリケーションフォーマットが定義されている。Wangは、全方位ビデオシーケンスのための座標系;球面ビデオシーケンス又は画像を、それぞれ、2次元矩形ビデオシーケンス又は画像に変換するために使用され得る、投影及び矩形領域ごと(rectangular region-wise)のパッキングの方法;ISO Base Media File Format(ISOBMFF)を使用した全方位メディア及び関連メタデータの記憶;メディアストリーミングシステムにおける全方位メディアのカプセル化、シグナリング、及びストリーミング;並びにメディアプロファイル及びプレゼンテーションプロファイル、を指定する。簡潔にするために、本明細書では、Wangの完全な説明は提供されないことに留意されたい。しかしながら、Wangの関連するセクションを参照する。

Wangは、ビデオがITU-T H.265に従って符号化されるメディアプロファイルを提供する。ITU-T H.265は、高効率ビデオ符号化(High Efficiency Video Coding、HEVC),Recに記載されている。ITU-T H.265(2016年12月)は、参照により本明細書に組み込まれ、本明細書ではITU-T H.265と呼ばれる。上述のように、ITU-T H.265によれば、各ビデオフレーム又はピクチャは、1つ以上のスライスを含むように区画化してもよく、1つ以上のタイルを含むように更に区画化してもよい。図2A〜図2Bは、スライスを含み、ピクチャを更にタイルに区画化するピクチャ群の一例を示す概念図である。図2Aに示す例では、Pic4は、2つのスライス(すなわち、Slice₁及びSlice₂)を含むものとして示されており、各スライスは(例えばラスタ走査順に)CTUのシーケンスを含む。図2Bに示す例では、Pic4は、6つのタイル(すなわち、Tile₁〜Tile₆)を含むものとして示されており、各タイルは矩形であり、CTUのシーケンスを含む。ITU-T H.265では、タイルは、2つ以上のスライスに包含される符号化ツリーユニットからなっていてもよく、スライスは、2つ以上のタイルに包含される符号化ツリーユニットからなっていてもよいことに留意されたい。しかしながら、ITU-T H.265は、以下の条件のうちの1つ又は両方が満たされなければならないと規定している。(1)あるスライス中の全ての符号化ツリーユニットは同じタイルに属する、及び(2)あるタイル内の全ての符号化ツリーユニットは同じスライスに属する。

360度の球面ビデオは、領域を含んでもよい。図3に示す例を参照すると、360度の球面ビデオは、領域A、B、及びCを含み、図3に示すように、タイル(すなわち、Tile₁〜Tile₆)は、全方位ビデオの領域を形成することができる。図3に示す例では、各領域はCTUを含むものとして示されている。上述のように、CTUは、符号化されたビデオデータのスライス及び/又はビデオデータのタイルを形成することができる。更に、上述のように、ビデオ符号化技術は、ビデオブロック、その再分割、及び/又は対応する構造に従って、ピクチャの領域を符号化してもよく、ビデオ符号化技術は、ビデオ符号化パラメータを、ビデオ符号化構造の様々なレベルで調整すること、例えば、スライス、タイル、ビデオブロック、及び/又は再分割に対して調整することを可能にすることに留意されたい。一実施例では、図3に表す360度のビデオは、スポーツイベントを表してもよく、領域A及び領域Cがスタジアムのスタンドのビューを含み、領域Bが競技場のビューを含む(例えば、ビデオは、50ヤードラインに配置された360度カメラによってキャプチャされる)。

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

上述のように、Wangは、全方位ビデオの座標系を指定する。Wangでは、座標系は、単位球体と、3つの座標軸、すなわちX(前後)軸、Y(横方向、左右)軸、及びZ(垂直、上方)軸、とからなり、3つの軸は球体の中心で交差している。球体上の点の場所は、球体座標方位(φ)及び高度(θ)の対によって識別される。図4は、Wangで指定されるような、球面座標方位(φ)及び高度(θ)のX、Y、及びZ座標軸に対する関係を示す。Wangでは、方位角の値の範囲は、-180.0度以上〜180.0度未満であり、高度の値の範囲は、-90.0度以上〜90.0度以下であることに留意されたい。Wangは、球体上の領域が4つの大円によって指定される場合があり、大円(Riemannian circleとも呼ばれる)は、球体と、球体の中心点を通過する平面との交点であり、球体の中心と大円の中心とが同一位置にあると指定する。Wangは、球体上の領域が2つの方位円及び2つの高度円によって指定され得ることについて更に記載しており、方位円は、同じ方位値を有する全ての点を接続する球体上の円であり、高度円は、同じ高度値を有する全ての点を接続する球体上の円である。Wang内の球体領域構造は、様々なタイプのメタデータをシグナリングするための基礎をなす。

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

切り捨て又は四捨五入が意図されていない式において除算を表すために使用される。
x%y 剰余。xをyで割った余り、x>=0かつy>0の整数x及びyに対してのみ定義される。

本明細書で使用される式に関して、以下の論理演算子が使用され得ることに留意されたい:
x && y xとyとのブール論理「積」
x||y xとyとのブール論理「和」
!ブール論理「否」
x?y:z xが真であるか又は0に等しくない場合はyの値を評価し、そうでない場合はzの値を評価する。

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

本明細書で使用されるシンタックスにおいて、unsigned int(n)は、nビットを有する符号なし整数を指すことに留意されたい。更に、bit(n)は、nビットを有するビット値を指す。

上述したように、Wangは、国際標準化機構(ISO)ベースメディアファイルフォーマット(ISOBMFF)を使用して、全方向メディア及び関連メタデータを記憶する方法を指定する。Wangは、プロジェクトフレームによってカバーされる球体表面の面積を指定するメタデータをサポートするファイルフォーマットを指定する。具体的には、Wangは、以下の定義、シンタックス、及びセマンティクを有する球体領域を指定する球体領域構造を含む。
定義
球体領域構造(SphereRegionStruct)は、球体領域を指定する。
centre_tiltが0に等しい場合、この構造によって指定される球体領域は、以下のように導出される。
- azimuth_range及びelevation_rangeの両方が0に等しい場合、この構造によって指定される球面領域は球面上の点である。
- そうでない場合、球面領域は、以下のように導出される変数centreAzimuth、centreElevation、cAzimuth1、cAzimuth、cElevation1、及びcElevation2を用いて定義される。
centreAzimuth=centre_azimuth÷65536
centreElevation=centre_elevation÷65536
cAzimuth1=(centre_azimuthーazimuth_range÷2)÷65536
cAzimuth2=(centre_azimuth+azimuth_range÷2)÷65536
cElevation1=(centre_elevation+elevation_range÷2)÷65536
cElevation2=(centre_elevation+elevation_range÷2)÷65536

球体領域は、SphereRegionStructのこのインスタンスを含む構造のセマンティクスで指定された形状タイプ値を参照して以下のように定義される。
- 形状タイプ値が0に等しい場合、球体領域は、図5Aに示すように、4つの点cAzimuth1、cAzimuth2、cElevation1、cElevation2によって定義される4つの大円と、centreAzimuth及びcentreElevationによって定義される中心点とによって指定される。
- 形状タイプ値が1に等しい場合、球体領域は、図5Bに示すように、4つの点cAzimuth1、cAzimuth2、cElevation1、cElevation2によって定義される2つの方位円及び2つの高度円と、centreAzimuth及びcentreElevationによって定義される中心点とによって指定される。

centre_tiltが0に等しくない場合、球体領域は、最初に上記のように導出され、次いで、球体原点を起源として球体領域の中心点を通過する軸に沿って傾斜回転が適用され、そのとき、原点から軸の正方向の端に向かって見たときに角度値は時計回りに増加する。最終的な球体領域は、傾斜回転を適用した後のものである。

0に等しい形状タイプ値は、球体領域が図5Aに表すように4つの大円によって指定されることを示している。

1に等しい形状タイプ値は、図5Bに示すように、球体領域が2つの方位円及び2つの高度円によって指定されることを示している。

1より大きい形状タイプ値が予備としてある。

シンタックス

セマンティクス
centre_azimuth及びcentre_elevationは、球面領域の中心を指定するものである。
centre_azimuthは、両端値を含む、-180^*2¹⁶〜180^*2¹⁶-1の範囲にあるものとする。centre_elevationは、両端値を含む、-90^*2¹⁶〜90^*2¹⁶の範囲にあるものとする。
centre_tiltは、球体領域の傾斜角を指定し、centre_tiltは、両端値を含む、-180^*2¹⁶〜180^*2¹⁶-1の範囲にあるものとする。
azimuth_range及びelevation_rangeは、存在する場合、それぞれ、この構造によって指定される球体領域の方位範囲及び高度範囲を2^-16度の単位で指定する。azimuth_range及びelevation_rangeは、図5A又は図5Bに示すように、球体領域の中心点を通る範囲を指定する。SphereRegionStructのこのインスタンスにazimuth_range及びelevation_rangeが存在しない場合、SphereRegionStructのこのインスタンスを含む構造のセマンティクスにおいて指定されると推測される。azimuth_rangeは、両端値を含む、0〜360^*2¹⁶の範囲にあるものとする。elevation_rangeは、両端値を含む、0〜180^*2¹⁶の範囲にあるものとする。
interpolateのセマンティクスは、SphereRegionStructのこのインスタンスを含む構造のセマンティクスによって指定される。

上述のように、Wang内の球体領域構造は、様々なタイプのメタデータをシグナリングするための基礎をなす。球体領域に対して汎用時限メタデータトラックシンタックスを指定することに関して、Wangは、サンプルエントリ及びサンプルフォーマットを指定する。サンプルエントリ構造は、以下の定義、シンタックス、及びセマンティクスを有するものとして指定される。
定義
ちょうど1つのSphereRegionConfigBoxが、サンプルエントリに存在するものとする。
SphereRegionConfigBoxは、サンプルによって指定された球体領域の形状を指定する。サンプル内の球体領域の方位範囲及び高度範囲が変化しない場合、それらはサンプルエントリ内に示され得る。
シンタックス

セマンティクス
0に等しいshape_typeは、4つの大円によって指定される球体領域を指定する。1に等しいshape_typeは、2つの方位円及び2つの高度円によって指定される球体領域を指定する。1より大きいshape_typeの値が予約済みである。shape_typeの値は、(上述の)球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合に、形状タイプ値として使用される。
0に等しいdynamic_range_flagは、このサンプルエントリを参照する全てのサンプルにおいて、球体領域の方位範囲及び高度範囲が変化されないままであることを指定する。1に等しいdynamic_range_flagは、球体領域の方位範囲及び高度範囲がサンプルフォーマットで示されることを指定する。
static_azimuth_range及びstatic_elevation_rangeは、それぞれ、このサンプルエントリを参照する各サンプルに対して、球体領域の方位範囲及び高度範囲を2^-16度の単位で指定する。static_azimuth_range及びstatic_elevation_rangeは、図5A又は図5Bに示すように、球体領域の中心点を通る範囲を指定する。static_azimuth_rangeは、両端値を含む、0〜360*2¹⁶の範囲にあるものとする。static_elevation_rangeは、両端値を含む、0〜180*2¹⁶の範囲にあるものとする。static_azimuth_range及びstatic_elevation_rangeが存在し、両方とも0に等しい場合、このサンプルエントリを参照する各サンプルの球体領域は、球体表面上の点である。(上述の)球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合、static_azimuth_range及びstatic_elevation_rangeが存在する場合は、azimuth_range及びelevation_rangeの値は、それぞれ、static_azimuth_range及びstatic_elevation_rangeに等しいと推測される。
num_regionsは、このサンプルエントリを参照するサンプル内の球体領域数を指定する。num_regionsは、1に等しいものとする。num_regionsの他の値は予備とされる。

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

セマンティクス
上述の球体領域構造項目は、SphereRegionStruct構造を含むサンプルに適用される。
ターゲットメディアサンプルが、参照メディアトラック内のメディアサンプルであって、その合成時間が、このサンプルの合成時間以上であり、次のサンプルの合成時間未満であるとする。
0に等しいinterpolateは、このサンプルにおけるcentre_azimuth、centre_elevation、centre_tilt、azimuth_range(存在する場合)、及びelevation_range(存在する場合)の値が、ターゲットメディアサンプルに適用されることを指定し、1に等しいinterpolateは、ターゲットメディアサンプルに適用されるcentre_azimuth、centre_elevation、centre_tilt、azimuth_range(存在する場合)、及びelevation_range(存在する場合)の値が、このサンプル及び前のサンプルにおける対応するフィールドの値から直線的に補間されることを指定する。
同期サンプル、トラックの第1のサンプル、及びトラック断片の第1のサンプルに対するinterpolateの値は0に等しいものとする。

Wangでは、時限メタデータは、サンプルエントリ及びサンプルフォーマットに基づいてシグナリングしてもよい。例えば、Wangは、以下の定義、シンタックス、及びセマンティクスを有する初期ビューイング方向メタデータを含む。
定義
このメタデータは、関連付けられたメディアトラック、又は画像アイテムとして記憶された単一の全方位画像を再生する場合に使用されるべき初期ビューイング方向を示す。このタイプのメタデータ、centre_azimuth、centre_elevation、及びcentre_tiltの非存在下では、全て0に等しいと推測されたい。
OMAF(全方位メディアフォーマット)プレイヤは、指示された又は推定されたcentre_azimuth、centre_elevation、及びcentre_tiltを以下のように使用するべきである。
-OMAFプレイヤの方向/ビューポートメタデータが、ビューイングデバイスに含まれるか又はそれに取り付けられた方向センサを基礎にして取得される場合、OMAFプレイヤは、
・centre_azimuth値のみに従うべきであり、かつ、
・centre_elevation及びcentre_tiltの値を無視し、代わりに方向センサからのそれぞれの値を使用するべきである。
-そうでない場合は、OMAFプレイヤは、centre_azimuth、centre_elevation、及びcentre_tiltの3つ全てに従うべきである。

トラックサンプルエントリタイプ「初期ビュー方向時限メタデータ」を使用するものとする。

サンプルエントリのSphereRegionConfigBoxにおいて、shape_typeは0に等しいものとし、dynamic_range_flagは0に等しいものとし、static_azimuth_range0に等しいものとし、static_elevation_rangeは0に等しいものとする。

注記:このメタデータは、どの方位範囲及び高度範囲がビューポートによってカバーされているかにかかわらず、任意のビューポートに適用される。したがって、dynamic_range_flag、static_azimuth_range、及びstatic_elevation_rangeは、このメタデータが関連し、したがって0に等しい必要があるビューポートの寸法に影響を与えない。OMAFプレイヤが上記で結論付けたようにcentre_tiltの値に従う場合、centre_tiltの値は、ビューポートを表示する際に実際に使用されているものに等しいビューポートの球体領域の方位範囲及び高度範囲を設定することによって解釈することができる。
シンタックス

セマンティクス
注記1:サンプル構造がSphereRegionSampleから拡張されると、SphereRegionSampleのシンタックス要素がサンプルに含まれる。

centre_azimuth、centre_elevation、及びcentre_tiltは、グローバル座標軸に対してビューイング方向を2^-16度の単位で指定する。centre_azimuth及びcentre_elevationは、ビューポートの中心を示し、centre_tiltは、ビューポートの傾斜角を示す。

interpolateは、0に等しいものとする。

関連するメディアトラックにおける時系列サンプルからの再生開始時に、示されたビューイング方向が使用されるべきであることを、0に等しいrefresh_flagは指定する。各関連メディアトラックの時系列サンプルをレンダリングする時、すなわち、連続再生時と、時系列サンプルからの再生開始時との両方で、示されたビューイング方向が常に使用されるべきであることを、1に等しいrefresh_flagは指定する。

注記2:ビデオを連続して再生する場合でも、特定のビューイング方向が推奨されることをコンテンツ作成者が示すことを、1に等しいrefresh_flagは可能にする。例えば、1に等しいrefresh_flagは、シーンカット位置を示すことができる。

更に、Wangは、以下のように推奨ビューポート時限メタデータトラックを指定する。
推奨ビューポート時限メタデータトラックは、ユーザが視聴方位の制御を有さないか、又は視聴方位の制御を解除したときに表示されるべきビューポートを示す。
注記:推奨ビューポート時限メタデータトラックは、ディレクタのカットに基づいて、又は視聴統計の測定値に基づいて、推奨ビューポートを示すために使用されてもよい。

トラックサンプルエントリタイプ「rcvp」を使用するものとする。

このサンプルエントリタイプのサンプルエントリは、以下のように指定される。

viewport_typeは、表1に列挙されるように、推奨ビューポートのタイプを指定する。

viewport_descriptionは、推奨ビューポートのテキスト記述を提供する、ヌル終端UTF-8文字列である。

SphereRegionSampleのサンプルシンタックスを使用するものとする。

サンプルエントリのSphereRegionConfigBoxにおいて、shape_typeは0に等しいものとする。

static_azimuth_range及びstatic_elevation_rangeが存在する場合、又はazimuth_range及びelevation_rangeが存在する場合、それらは推奨ビューポートの方位範囲及び高度範囲をそれぞれ示す。

centre_azimuth及びcentre_elevationは、グローバル座標軸線に対する推奨ビューポートの中心点を示す。centre_tiltは、推奨ビューポートの傾斜角を示す。

時限テキストは、全方位ビデオの字幕及びクローズドキャプションを提供するために使用される。Wangでは、時限テキストキューは、球体に対して特定の領域上にレンダリングされてもよく(すなわち、ユーザが特定の方向を見るときにのみ視認可能である)、又は現在のビューポート上の領域にレンダリングされてもよく(すなわち、常に視聴方向に関係なく視認可能である)、その場合、テキスト/キュー領域の位置は現在のビューポートに対して相対的である。具体的には、Wangは、時限テキスト構成ボックスのための、以下の定義、シンタックス、及びセマンティクスを提供する。
定義
ボックスタイプ:‘otcf’
コンテナ:XMLSubtitleSampleEntry又はWVTTSampleEntry
必須:はい(全方位ビデオトラックに関連付けられた時限テキストトラックの場合)
数:1つ(全方位ビデオトラックに関連付けられた時限テキストトラックの場合)
このボックスは、時限テキストを全方向ビデオと共に提示するための構成情報を提供する。
シンタックス

セマンティクス
relative_to_viewport_flagは、時限テキストキューがどのようにレンダリングされるべきかを指定する。時限テキストが常にディスプレイスクリーン上に存在することが予想されること、すなわち、テキストキューがユーザの視聴方向とは独立して視認可能であることを、値1は示す。時限テキストが球体上の特定の位置でレンダリングされることが予想されること、すなわち、ユーザが、テキストキューがレンダリングされている方向を見ているときにのみ、テキストキューが視認可能であることを、値0は示す。
注記1:relative_to_viewport_flagが1に等しい場合、時限テキストが表示され得るアクティブエリアは、時限テキストトラックによって矩形領域として提供される。

relative_disparity_flagは、視差が1つのビューのディスプレイウィンドウの幅の割合値として提供されるか(値が1に等しい場合)、又は画素数として提供されるか(値が0に等しい場合)を示す。

1に等しいdepth_included_flagは、時限テキストがレンダリングされる領域の深さ(z値)が存在することを示す。値0は、時限テキストがレンダリングされる領域の深さ(z値)が存在しないことを示す。

region_countは、球体内の配置が提供されるテキスト領域の数を指定する。各領域は識別子によって識別される。(WebVTT及びTTMLの両方は、固有のidを使用して領域を識別する)。時限テキスト球体メタデータトラックを含む時限メタデータトラックが存在し、タイプ’cdsc’のトラック参照によってこの時限テキストトラックにリンクされる場合、region_countの値は0であるものとする。
注記2:WebVTT及びTTMLの両方は、一意の識別子を使用して領域を識別する。
region_idは、テキスト領域の識別子を提供する。この識別子は、IMSC1又はWebVTTトラック内の時限テキストストリーム内に定義された対応する領域の識別子に等しいものとする。

disparity_in_percentは、1つのビューのディスプレイウィンドウの幅の分画としての2^-16の単位での視差を示す。この値は負であってもよく、その場合、変位方向は逆である。この値を使用して、左目視野上の左及び右目視野上の右に領域を変位させる。

disparity_in_pixelsは、視差を画素で示す。この値は負であってもよく、その場合、変位方向は逆である。この値を使用して、左目視野上の左及び右目視野上の右に領域を変位させる。

SphereRegionStruct()は、球体の場所を示し、この球体の場所を他の情報と共に使用して、時限テキストが3D空間内に配置され表示される場所が決定される。球体の中心とこの球体の場所との間のベクトルは、時限テキストキューがレンダリングされるレンダリング3D平面に対する法線ベクトルである。この情報及び3D平面の深さは、時限テキストキューがレンダリングされる3D空間内のレンダリング3D平面の位置を決定するために使用される。

SphereRegionStruct()がOmafTimedTextConfigBoxに含まれる場合、以下が適用される。
OmafTimedTextConfigBoxに含まれるSphereRegionStruct()のシンタックス及びセマンティクスについて、shape_type、dynamic_range_flag、static_azimuth_range、及びstatic_elevation_rangeの値は、全て0に等しいと推測される。
centre_azimuth及びcentre_elevationは、他の情報と共に使用して、時限テキストが3D空間内に配置され表示される場所を決定するのに用いられる球体の場所を指定する。centre_azimuthは、両端値を含む、-180*2¹⁶〜180*2¹⁶-1の範囲にあるものとする。centre_elevationは、両端値を含む、-90*2¹⁶〜90*2¹⁶の範囲にあるものとする。
centre_tiltは、0に等しいものとする。
region_depthは、時限テキストがレンダリングされる領域の深さ(z値)を示す。深さ値は、時限テキスト領域の法線ベクトルのノルムである。この値は単位球体を基準とし、2^-16の単位である。

Wangは、オーバーレイ(例えば、ロゴ)をオン及びオフにすることを可能にするためのオーバーレイ構造を更に含む。オーバーレイは、360度のビデオコンテンツ上での視覚媒体のレンダリングとして定義することができる。視覚媒体は、ビデオ、画像、及びテキストのうちの1つ以上を含んでもよい。具体的には、Wangは、オーバーレイ構造のための、以下の定義、シンタックス、及びセマンティクスを提供する。
定義
OverlayStructは各オーバーレイ毎にオーバーレイ関連メタデータを指定する。
シンタックス

セマンティクス
num_overlaysは、この構造によって説明されるオーバーレイの数を指定する。0に等しいnum_overlaysが予備としてある。
num_flag_bytesは、overlay_control_flag[i]シンタックス要素によって集合的に割り当てられたバイト数を指定する。0に等しいnum_flag_bytesが予備としてある。
overlay_control_flag[i]が1に設定された場合、i番目のoverlay_control_struct[i]で定義される構造が存在することを定義している。OMAFプレイヤは、全てのiの値についてoverlay_control_flag[i]の両値を可能にするものとする。
0に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理する必要がないことを指定する。
1に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理するものとすることを指定する。1に等しいoverlay_control_essential_flag[i]及びOMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造をパース又は処理することができない場合、OMAFプレイヤは、この構造によって指定されたオーバーレイもバックグラウンドの視覚媒体も表示しないものとする。
byte_count[i]は、i番目のoverlay_control_struct[i]で表される構造のバイト数を与える。
overlay_control_struct[i][byte_count[i]]は、byte_count[i]で定義されるバイト数を有するi番目の構造を定義する。

Wangは、トラックが包含するオーバーレイの静的メタデータを以下のように記憶するためのオーバーレイ構成ボックスを更に提供する。
ボックスタイプ:’ovly’
コンテナ:ProjectedOmniVideoBox
必須:いいえ
数::ゼロ又は1
OverlayConfigBoxは、このトラックが包含するオーバーレイの静的メタデータを記憶するように定義される。

Wangは、関連する画像アイテムが包含するオーバーレイの静的メタデータを記憶するためのオーバーレイ項目特性を更に提供する。
ボックスタイプ:’ovly’
コンテナ:ItemPropertyContainerBox
必須:いいえ
数::ゼロ又は1
OverlayConfigPropertyは、関連する画像アイテムが包含するオーバーレイの静的メタデータを記憶するように定義される。

Wangに提供されるようなオーバーレイ構造は、理想的ではない場合がある。具体的には、オーバーレイは経時的に変化することがあり、この場合にはWangはオーバーレイの動的シグナリングを提供することができない。更に、Wangでのシグナリングは、複数のオーバーレイにとって理想的ではない場合がある。本明細書の技術によれば、各オーバーレイについて、複数のオーバーレイのための相対的順序を示すためにオーバーレイ層の順序がシグナリングされてもよい。更に、本明細書の技術によれば、各オーバーレイについて、オーバーレイ識別子がシグナリングされてもよい。オーバーレイ識別子は、異なる時間での1つ以上のオーバーレイのアクティブ化及び非アクティブ化の効率的な動的シグナリングのために使用されてもよい。

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

通信媒体110は、無線及び有線の通信媒体並びに/又は記憶デバイスの任意の組み合わせを含むことができる。通信媒体110としては、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、無線送信機及び受信機、ルータ、スイッチ、リピータ、基地局、又は様々なデバイスとサイトとの間の通信を容易にするために有用であり得る任意の他の機器を挙げることができる。通信媒体110は、1つ以上のネットワークを含むことができる。例えば、通信媒体110は、ワールドワイドウェブ、例えば、インターネットへのアクセスを可能にするように構成されたネットワークを含むことができる。ネットワークは、1つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び/又は規格化された電気通信プロトコルを含むことができる。標準化された電気通信プロトコルの例としては、Digital Video Broadcasting(DVB)規格、Advanced Television Systems Committee(ATSC)規格、Integrated Services Digital Broadcasting(ISDB)規格、Data Over Cable Service Interface Specification(DOCSIS)規格、Global System Mobile Communications(GSM)規格、符号分割多重アクセス(code division multiple access、CDMA)規格、第三世代パートナーシッププロジェクト(3rd Generation Partnership Project、3GPP)規格、欧州電気通信標準化機構(European Telecommunications Standards Institute、ETSI)規格、インターネットプロトコル(Internet Protocol、IP)規格、ワイヤレスアプリケーションプロトコル(Wireless Application Protocol、WAP)規格、及びInstitute of Electrical and Electronics Engineers(IEEE)規格が挙げられる。

記憶デバイスは、データを記憶することができる任意の種類のデバイス又は記憶媒体を含むことができる。記憶媒体は、有形又は非一時的コンピュータ可読媒体を含むことができる。コンピュータ可読媒体としては、光学ディスク、フラッシュメモリ、磁気メモリ、又は任意の他の好適なデジタル記憶媒体を挙げることができる。いくつかの例では、メモリデバイス又はその一部分は不揮発性メモリとして説明されることがあり、他の例では、メモリデバイスの一部分は揮発性メモリとして説明されることがある。揮発性メモリの例としては、ランダムアクセスメモリ(random access memory、RAM)、ダイナミックランダムアクセスメモリ(dynamic random access memory、DRAM)、及びスタティックランダムアクセスメモリ(static random access memory、SRAM)を挙げることができる。不揮発性メモリの例としては、磁気ハードディスク、光学ディスク、フロッピーディスク、フラッシュメモリ、又は電気的プログラム可能メモリ(electrically programmable memory、EPROM)若しくは電気的消去可能及びプログラム可能メモリ(electrically erasable and programmable、EEPROM)の形態を挙げることができる。記憶デバイス(単数又は複数)としては、メモリカード(例えば、セキュアデジタル(Secure Digital、SD)メモリカード)、内蔵/外付けハードディスクドライブ、及び/又は内蔵/外付けソリッドステートドライブを挙げることができる。データは、定義されたファイルフォーマットに従って記憶デバイス上に記憶することができる。

図6は、システム100の一実装形態に含まれ得る構成要素の一例を示す概念的描画である。図6に示す例示的な実装形態では、システム100は、1つ以上の演算デバイス402A〜402N、テレビサービスネットワーク404、テレビサービスプロバイダサイト406、ワイドエリアネットワーク408、ローカルエリアネットワーク410、及び1つ以上のコンテンツプロバイダサイト412A〜412Nを含む。図6に示す実装形態は、例えば、映画、ライブスポーツイベントなどのデジタルメディアコンテンツ、並びにデータ及びアプリケーション及びそれらに関連付けられたメディアプレゼンテーションが、演算デバイス402A〜402Nなどの複数の演算デバイスに配布され、かつ、それらによってアクセスされることが可能となるように構成され得るシステムの一例を表す。図6に示す例では、演算デバイス402A〜402Nは、テレビサービスネットワーク404、ワイドエリアネットワーク408、及び/又はローカルエリアネットワーク410のうちの1つ以上からデータを受信するように構成されている任意のデバイスを含むことができる。例えば、演算デバイス402A〜402Nは、有線及び/又は無線通信用に装備してもよく、1つ以上のデータチャネルを通じてサービスを受信するように構成してもよく、いわゆるスマートテレビ、セットトップボックス、及びデジタルビデオレコーダを含むテレビを含んでもよい。更に、演算デバイス402A〜402Nは、デスクトップ、ラップトップ又はタブレットコンピュータ、ゲーム機、例えば「スマート」フォン、セルラー電話、及びパーソナルゲーミングデバイスを含むモバイルデバイスを含んでもよい。

テレビサービスネットワーク404は、テレビサービスを含み得る、デジタルメディアコンテンツの配信を可能にするように構成されているネットワークの一例である。例えば、テレビサービスネットワーク404は、公共地上波テレビネットワーク、公共又は加入ベースの衛星テレビサービスプロバイダネットワーク、並びに公共又は加入ベースのケーブルテレビプロバイダネットワーク及び/又は頭越し型(over the top)サービスプロバイダ若しくはインターネットサービスプロバイダを含んでもよい。いくつかの実施例では、テレビサービスネットワーク404は、テレビサービスの提供を可能にするために主に使用され得るが、テレビサービスネットワーク404はまた、本明細書に記載された電気通信プロトコルの任意の組み合わせに基づく他の種類のデータ及びサービスの提供も可能とすることに留意されたい。更に、いくつかの実施例では、テレビサービスネットワーク404は、テレビサービスプロバイダサイト406と、演算デバイス402A〜402Nのうちの1つ以上との間の双方向通信を可能にすることができることに留意されたい。テレビサービスネットワーク404は、無線通信メディア及び/又は有線通信メディアの任意の組み合わせを含むことができる。テレビサービスネットワーク404は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、無線送信機及び受信機、ルータ、スイッチ、リピータ、基地局、又は様々なデバイスとサイトとの間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。テレビサービスネットワーク404は、1つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び/又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、DVB規格、ATSC規格、ISDB規格、DTMB規格、DMB規格、ケーブルによるデータサービスインターフェース標準(Data Over Cable Service Interface Specification、DOCSIS)規格、HbbTV規格、W3C規格、及びUPnP規格が挙げられる。

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

ワイドエリアネットワーク408は、パケットベースのネットワークを含み、1つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び/又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、汎欧州デジタル移動電話方式(Global System Mobile Communications、GSM)規格、符号分割多元接続(code division multiple access、CDMA)規格、3rd Generation Partnership Project(3GPP)規格、欧州電気通信標準化機構(European Telecommunications Standards Institute、ETSI)規格、欧州規格(EN)、IP規格、ワイヤレスアプリケーションプロトコル(Wireless Application Protocol、WAP)規格、及び例えば、IEEE802規格のうちの1つ以上(例えば、Wi-Fi)などの電気電子技術者協会(Institute of Electrical and Electronics Engineers、IEEE)規格が挙げられる。ワイドエリアネットワーク408は、無線通信メディア及び/又は有線通信メディアの任意の組み合わせを含むことができる。ワイドエリアネットワーク480は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、イーサネットケーブル、無線送信部及び受信部、ルータ、スイッチ、リピータ、基地局、又は様々なデバイス及びサイト間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。一実施例では、ワイドエリアネットワーク408はインターネットを含んでもよい。ローカルエリアネットワーク410は、パケットベースのネットワークを含み、1つ以上の電気通信プロトコルの組み合わせに従って動作することができる。ローカルエリアネットワーク410は、アクセス及び/又は物理インフラストラクチャのレベルに基づいてワイドエリアネットワーク408と区別することができる。例えば、ローカルエリアネットワーク410は、セキュアホームネットワークを含んでもよい。

図6を再び参照すると、コンテンツプロバイダサイト412A〜412Nは、マルチメディアコンテンツをテレビサービスプロバイダサイト406及び/又は演算デバイス402A〜402Nに提供することができるサイトの例を表す。例えば、コンテンツプロバイダサイトは、マルチメディアファイル及び/又はストリームをテレビサービスプロバイダサイト406に提供するように構成されている、1つ以上のスタジオコンテンツサーバを有するスタジオを含むことができる。一実施例では、コンテンツプロバイダのサイト412A〜412Nは、IPスイートを使用してマルチメディアコンテンツを提供するように構成してもよい。例えば、コンテンツプロバイダサイトは、リアルタイムストリーミングプロトコル(RTSP)、HTTPなどに従って、マルチメディアコンテンツを受信デバイスに提供するように構成されてもよい。更に、コンテンツプロバイダサイト412A〜412Nは、ハイパーテキストベースのコンテンツなどを含むデータを、ワイドエリアネットワーク408を通じて、受信デバイス、演算デバイス402A〜402N、及び/又はテレビサービスプロバイダサイト406のうちの1つ以上に提供するように構成してもよい。コンテンツプロバイダサイト412A〜412Nは、1つ以上のウェブサーバを含んでもよい。データプロバイダサイト412A〜412Nによって提供されるデータは、データフォーマットに従って定義することができる。

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

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

上述のように、Wangに提供されるようなオーバーレイ構造は、理想的ではない場合がある。一実施例では、本明細書に記載される技術によれば、データカプセル化部107は、以下の例示的な定義、シンタックス、及びセマンティクスに基づいて、オーバーレイ情報をシグナリングするように構成することができる。
定義
OverlayStructは各オーバーレイ毎にオーバーレイ関連メタデータを指定する。
シンタックス

セマンティクス
num_overlaysは、この構造によって説明されるオーバーレイの数を指定する。0に等しいnum_overlaysが予備としてある。
num_flag_bytesは、overlay_control_flag[i]シンタックス要素によって集合的に割り当てられたバイト数を指定する。0に等しいnum_flag_bytesが予備としてある。
overlay_idは、オーバーレイの一意の識別子を提供する。2つのオーバーレイは、同じoverlay_idを有さないものとする。
overlay_labelは、i番目のオーバーレイのためのヌル終端UTF-8ラベルを提供する。
overlay_layer_orderは、i番目のオーバーレイの相対的層順序を指定する。OMAFプレイヤは、それらがA>Bである場合、overlay_layer_order値Bを有するオーバーレイの上にoverlay_layer_order値Aを有するオーバーレイを表示するものとする。
overlay_control_flag[i]が1に設定された場合、i番目のoverlay_control_struct[i]で定義される構造が存在することが定義される。OMAFプレイヤは、全てのiの値についてoverlay_control_flag[i]の両値を可能にするものとする。
0に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理する必要がないことを指定する。1に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理するものとすることを指定する。1に等しいoverlay_control_essential_flag[i]及びOMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造をパース又は処理することができない場合、OMAFプレイヤは、この構造によって指定されたオーバーレイもバックグラウンドの視覚媒体も表示しないものとする。
byte_count[i]は、i番目のoverlay_control_struct[i]で表される構造のバイト数を与える。
overlay_control_struct[i][byte_count[i]]は、byte_count[i]で定義されるバイト数を有するi番目の構造を定義する。

一実施例では、シンタックス要素overlay_id、overlay_label、overlay_layer_orderのうちの1つ以上は、上記のものとは異なるビット数を使用してもよい。例えば、overlay_idは、8ビット、24ビット、又は32ビットを使用することができる。また、overlay_layer_orderは、8ビット、24ビット、又は32ビットを使用することができる。また、シンタックス要素の順序は、上記のものと比較して変更されてもよい。例えば、シンタックス要素overlay_idに続いて、シンタックス要素overlay_layer_orderがあり、これに続いてシンタックス要素overlay_labelがあってもよい。一実施例では、フィールドoverlay_id、overlay_label、overlay_layer_orderのうちの1つ以上は、上記のforループの代わりに、構造SingleOverlayStruct内でシグナリングされてもよい。

一実施例では、本明細書に記載される技術によれば、データカプセル化部107は、オーバーレイ情報をシグナリングするように構成することができ、そこでフラッグのシグナリングがバイトからビットに変換される。これにより、未使用ビットを確保することができ、より将来的な拡張性を提供する。一実施例では、データカプセル化部107は、以下の例示的な定義、シンタックス、及びセマンティクスに基づいて、オーバーレイ情報をシグナリングするように構成することができる。
定義
OverlayStructは各オーバーレイ毎にオーバーレイ関連メタデータを指定する。
シンタックス

セマンティクス
num_overlaysは、この構造によって説明されるオーバーレイの数を指定する。0に等しいnum_overlaysが予備としてある。
num_flag_bitsは、overlay_control_flag[i]シンタックス要素によって集合的に割り当てられたビット数を指定する。0に等しいnum_flag_bitsが予備としてある。
なお、このシンタックスには、符号なしのint(12)num_flag_bitsとして12ビットが使用されることに留意されたい。別の例では、異なるビット数、例えば11ビット、10ビット、又は14ビットが、num_flag_bitsに使用されてもよい。この場合、ビット数は、ハ゛イトアラインメント合わせのために確保されたままでもよい。例えば、次の2つのシンタックス要素が代わりにシク゛ナリンク゛されてもよい。
unsigned int(11)num_flag_bits;
bit(5)reserved=0;
overlay_idは、オーバーレイの一意の識別子を提供する。2つのオーバーレイは、同じoverlay_idを有さないものとする。
overlay_labelは、i番目のオーバーレイのためのヌル終端UTF-8ラベルを提供する。
overlay_layer_orderは、i番目のオーバーレイの相対的層順序を指定する。OMAFプレイヤは、これらがA>Bである場合、overlay_layer_order値Bを有するオーバーレイの上にoverlay_layer_order値Aを有するオーバーレイを表示するものとする。
overlay_control_flag[i]が1に設定された場合、i番目のoverlay_control_struct[i]で定義される構造が存在することを定義する。OMAFプレイヤは、全てのiの値についてoverlay_control_flag[i]の両値を可能にするものとする。
0に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理する必要がないことを指定する。1に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理するものとすることを指定する。1に等しいoverlay_control_essential_flag[i]及びOMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造をパース又は処理することができない場合、OMAFプレイヤは、この構造によって指定されたオーバーレイもバックグラウンドの視覚媒体も表示しないものとする。
byte_count[i]は、i番目のoverlay_control_struct[i]で表される構造のバイト数を与える。
overlay_control_struct[i][byte_count[i]]は、byte_count[i]で定義されるバイト数を有するi番目の構造を定義する。

上述のように、様々なオーバーレイが、異なる時間で有効及び無効にされてもよい。例えば、広告ロゴはオーバーレイとして使用されてもよく、表示されたオーバーレイロゴは経時的に動的に変化してもよい。一実施例では、このシグナリングのために、カプセル化されたデータは、オーバーレイ時限メタデータトラックを使用するように構成することができる。例示的なオーバーレイ時限メタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイ時限メタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)(例えば、広告のロゴ)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’movl’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

サンプル
定義
OverlaySampleに示されるサンプルシンタックスを使用するものとする。
シンタックス

num_active_overlaysは、アクティブなサンプルエントリOverlaySampleEntryでシグナリングされるOverlayStruct()構造からのオーバーレイの数を指定する。0の値は、アクティブなオーバーレイが無いことを示す。

active_overlay_idは、現在アクティブであるオーバーレイのオーバーレイ識別子を提供する。各active_overlay_idについて、サンプルエントリOverlaySampleEntryのOverlayStruct()構造は、整合するoverlay_id値を有するオーバーレイを含むものとする。OMAFプレイヤは、active_overlay_idによって示されたアクティブオーバーレイのみを任意の特定の時間に表示するものとし、非アクティブオーバーレイを表示しないものとする。

サンプルによる特定のオーバーレイのアクティブ化は、以前のサンプル(単数又は複数)からの、任意の以前にシグナリングされたオーバーレイの非アクティブ化をもたらす。

一実施例では、任意の特定の時間でアクティブな1つ以上のオーバーレイは、サンプルに直接シグナリングされてもよい。この場合、一実施例では、例示的なオーバーレイ時限メタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイ時限メタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)(例えば、広告のロゴ)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’dovl’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

OverlayStruct()は、前述したものと同じシンタックス及びセマンティクスを有する。

一実施例では、オーバーレイの一部は、サンプルエントリ内のそれらのオーバーレイ識別子を参照することによって、サンプルにシグナリングされる。更に、いくつかの新しいオーバーレイは、サンプルエントリ内のそれらのオーバーレイ構造をシグナリングすることによって直接シグナリングすることができる。この場合、一実施例では、例示的なオーバーレイ時限メタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイ時限メタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’dyol’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

num_active_overlays_by_idは、アクティブなサンプルエントリOverlaySampleEntryでシグナリングされるOverlayStruct()構造からのオーバーレイの数を指定する。
0の値は、サンプルエントリからのオーバーレイのうちアクティブなものが無いことを示す。

addl_active_overlays_flagが1に等しいことは、追加のアクティブオーバーレイがオーバーレイ構造(OverlayStruct())でサンプルに直接シグナリングされることを指定する。addl_active_overlays_flagが0に等しいことは、追加のアクティブオーバーレイがオーバーレイ構造(OverlayStruct())でサンプルに直接シグナリングされないことを指定する。

active_overlay_idは、現在アクティブなサンプルエントリからシグナリングされたオーバーレイのオーバーレイ識別子を提供する。各active_overlay_idについて、サンプルエントリOverlaySampleEntryのOverlayStruct()構造は、整合するoverlay_id値を有するオーハ゛ーレイを含むものとする。

サンプルによってシグナリングされたアクティブオーバーレイの総数は、存在する場合、OverlayStruct()内のnum_active_overlays_by_id及びnum_overlaysの合計に等しい。OMAFプレイヤは、アクティブオーバーレイのみを任意の特定の時間に表示するものとし、非アクティブオーバーレイを表示しないものとする。

上述のように、Wangでは、時限テキストシグナリングについて、relative_to_viewport_flagがシグナリングされる。一実施例では、データカプセル化部107は、オーバーレイ又は時限テキストに関し、特定の条件下で、共通参照座標で位置を指定するように構成することができる。例えば、この場合、オーバーレイは、3D空間内に配置されてもよく、選択された視点に応じて、その一部又は全部が視認可能であり得る。一実施例では、これは、ビューポートをオーバーレイするために行われてもよい。一実施例では、データカプセル化部107は、以下のように、SphereRegionStruct()と共にビューポートをシグナリングするように構成することができる。
シンタックス

セマンティクス
viewport_x、viewport_y、及びviewport_zは、共通参照座標系の中心として(0,0,0)を有する3D空間内の球体の中心の位置を、ミリメートル単位で、指定する。球体の中心は、以下のSphereRegionStruct(1)と共に、オーバーレイが3D空間内に配置され表示される場所を決定するビューポートの位置を指定する。
RecommendedViewportInformation()は、推奨ビューポートに関する情報を指定する。これは、例えば、推奨ビューポートに対応する時限メタデータトラックを指定するtrack_IDのリスト内のインデックスを含んでもよい。
SphereRegionStruct(1)は球体の場所を示し、これは、他の情報と共に使用して、オーバーレイが3D空間内に配置され表示される場所を決定する。球体の中心とこの球体の場所との間のベクトルは、オーバーレイがレンダリングされるレンダリング3D平面のノルムである。この情報及び3D平面の深さは、オーバーレイがレンダリングされる3D空間内のレンダリング3D平面の位置を決定するために使用される。

一実施例では、(viewport_x,viewport_y,viewport_z)を中心とする球体の半径のための追加のパラメータがシグナリングされてもよい。
unsigned int(16)sph_radius;
sph_radiusは、好適な単位で(viewport_x,viewport_y,viewport_z)に中心を有する3D空間における球体の半径を指定する。0の値は予備とされる。

一実施例では、上記の情報は、ローカル座標系に対応してもよい。一実施例では、上記の情報は、グローバル座標系に対応してもよい。一実施例では、上記のセマンティクスについて、好適な単位はメートルであってもよい。一実施例では、上記のセマンティクスについて、好適な単位はセンチメートルであってもよい。一実施例では、上記のセマンティクスについて、好適な単位はミリメートルであってもよい。

一実施例では、オーバーレイ不透明度情報の条件付きシグナリングの代わりに、データカプセル化部107は、オーバーレイ不透明度情報を常にシグナリングするように構成することができる。例えば、シグナリングは以下のようであってもよい。

overlay_opacityは、このオーバーレイに適用されるべき不透明度の%を指定する。0の値は、このオーバーレイが完全に透明であることを示す。100の値は、このオーバーレイが完全に不透明であることを示す。値は、両端値を含む、0〜100の範囲にあるものとする。値101〜128は予備としてある。

別の例では、オーバーレイ不透明度情報は、条件付きでシグナリングされてもよい。例えば、フラグの値に基づいてシグナリングされてもよい。この場合、シグナリングされていない場合、オーバーレイの不透明度に関して値を推測することができる。一実施例では、シグナリングされていない場合、オーバーレイの不透明度が100に等しい(すなわち、完全に不透明なオーバーレイ)と推測され得る。一実施例では、シグナリングされていない場合、オーバーレイの不透明度が0に等しい(すなわち、完全に透明なオーバーレイ)と推測され得る。一実施例では、シグナリングされていない場合、オーバーレイの不透明度が50に等しい(すなわち、半分不透明かつ半分透明なオーバーレイ)と推測され得る。一般に、いくつかの他の値は、シグナリングされていない場合のオーバーレイに関して推測され得る。

別の例では、上記のシンタックス及びセマンティクスは、iが5に等しくない場合にのみ、シンタックス要素の一部をシグナリングするように変更されてもよい。一実施例では、5に等しいiは、その位置がユーザインタラクションに基づいて選択されるオーバーレイに対応し得る。以下の実施例に示されるように、
シンタックス

又は

セマンティクス
0に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理する必要がないことを指定する。
1に等しいoverlay_control_essential_flag[i]は、OMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造を処理するものとすることを指定する。1に等しいoverlay_control_essential_flag[i]及びOMAFプレイヤがi番目のoverlay_control_struct[i]で定義される構造をパース又は処理することができない場合、OMAFプレイヤは、この構造によって指定されたオーバーレイもバックグラウンドの視覚媒体も表示しないものとする。iが5に等しい場合、
overlay_control_essential_flag[i]は、0に等しいと推測される。
byte_count[i]は、i番目のoverlay_control_struct[i]で表される構造のバイト数を与える。
iが5に等しい場合、byte_count[i]は、0に等しいと推測される。

このようにして、データカプセル化部107は、複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングし、かつ複数のオーバーレイに時間変化する更新をシグナリングするように構成されているデバイスの一例を表す。

図1を再び参照すると、インターフェース108は、データカプセル化部107によって生成されたデータを受信し、そのデータを通信媒体に送信及び/又は記憶するように構成された任意のデバイスを含んでもよい。インターフェース108は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を送信及び/若しくは受信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース108は、ファイルを記憶デバイス上に記憶することを可能にすることができるコンピュータシステムインターフェースを含むことができる。例えば、インターフェース108は、Peripheral Component Interconnect(PCI)及びPeripheral Component Interconnect Express(PCIe)バスプロトコル、独自のバスプロトコル、ユニバーサルシリアルバス(Universal Serial Bus、USB)プロトコル、I²C、又はピアデバイスを相互接続するために使用することができる任意の他の論理構造及び物理構造をサポートする、チップセットを含むことができる。

図1を再び参照すると、目的デバイス120は、インターフェース122と、データデカプセル化部123と、ビデオデコーダ124と、ディスプレイ126とを含む。インターフェース122は、通信媒体からデータ受信するように構成されている任意のデバイスを含むことができる。インターフェース122は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を受信及び/若しくは送信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース122は、準拠ビデオビットストリームを記憶デバイスから取得することを可能にするコンピュータシステム用インターフェースを含むことができる。例えば、インターフェース122は、PCI及びPCIeバスプロトコル、独自のバスプロトコル、USBプロトコル、I²C、又はピアデバイスを相互接続するために使用することができる任意の他の論理構造及び物理構造をサポートする、チップセットを含むことができる。データデカプセル化部123は、本明細書に記載された技術のうちの1つ以上に従って、データカプセル化部107によって生成されたビットストリームを受信し、サブビットストリーム抽出を実行するように構成することができる。

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

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

図7に示すように、受信デバイス600は、中央処理装置(単数又は複数)602、システムメモリ604、システムインターフェース610、データ抽出装置612、音声デコーダ614、音声出力システム616、ビデオデコーダ618、表示システム620、I/Oテ゛ハ゛イス(単数又は複数)622、及びネットワークインターフェース624を含む。図7に示すように、システムメモリ604は、オヘ゜レーティンク゛システム606及びアフ゜リケーション608を含む。中央処理装置(単数又は複数)602、システムメモリ604、システムインターフェース610、テ゛ータ抽出装置612、音声テ゛コータ゛614、音声出力システム616、ヒ゛テ゛オテ゛コータ゛618、表示システム620、I/Oテ゛ハ゛イス(単数又は複数)622、及びネットワークインターフェース624の各々は、コンホ゜ーネント間通信のために(物理的、通信的、及び/又は動作的に)相互接続してもよく、1つ以上のマイクロプロセッサ、デジタル信号プロセッサ(digital signal processor、DSP)、特定用途向け集積回路(application specific integrated circuit、ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array、FPGA)、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な好適な回路のいずれかとして実装することができる。受信デバイス600は、別個の機能ブロックを有するものとして図示されているが、このような図示は、説明を目的としており、受信デバイス600を特定のハードウェアアーキテクチャに限定しないという点に留意されたい。受信デバイス600の機能は、ハードウェア実装、ファームウェア実装、及び/又はソフトウェア実装の任意の組み合わせを使用して実現することができる。

CPU(単数又は複数)602は、受信デバイス600において実行するための機能及び/又はプロセス命令を実施するように構成してもよい。CPU(単数又は複数)602は、シングルコア及び/又はマルチコアの中央処理装置を含むことができる。CPU(単数又は複数)602は、本明細書に記載された技術のうちの1つ以上を実施するための命令、コード、及び/又はデータ構造を検索及び処理することが可能であり得る。命令は、システムメモリ604などのコンピュータ可読媒体に記憶することができる。

システムメモリ604は、非一時的又は有形のコンピュータ可読記憶媒体として説明することができる。いくつかの実施例では、システムメモリ604は、一時的及び/又は長期記憶部を提供することができる。いくつかの実施例では、システムメモリ604又はその一部は、不揮発性メモリとして記述してもよく、別の実施例では、システムメモリ604の一部は、揮発性メモリとして記述してもよい。システムメモリ604は、動作中に受信デバイス600によって使用され得る情報を記憶するように構成してもよい。システムメモリ604は、CPU(単数又は複数)602によって実行するためのプログラム命令を記憶するために使用することができ、受信デバイス600上で実行しているプログラムについて、プログラム実行中に情報を一時的に記憶するために使用してもよい。更に、受信デバイス600がデジタルビデオレコーダの一部として含まれる実施例では、システムメモリ604は、多数のビデオファイルを記憶するように構成してもよい。

アプリケーション608は、受信デバイス600内で実施されるか又はそれによって実行されるアプリケーションを含むことができ、受信デバイス600の構成要素について、その内に実装されるか若しくは含まれ、それによって動作可能であり、それによって実行され、及び/又は動作的/通信的に結合され得る。アプリケーション608は、受信デバイス600のCPU(単数又は複数)602に特定の機能を実行させることができる命令を含むことができる。アプリケーション608は、forループ、whileループ、ifステートメント、doループなどのコンピュータプログラミングステートメントで表現されたアルゴリズムを含むことができる。アプリケーション608は、特定のプログラミング言語を使用して開発することができる。プログラミング言語の例としては、Java(商標)、Jini(商標)、C、C++、Objective C、Swift、Perl、Python、PhP、UNIX Shell、Visual Basic、及びVisual Basic Scriptが挙げられる。受信デバイス600がスマートテレビを含む実施例では、テレビ製造業者又は放送局によってアプリケーションが開発してもよい。図7に示すように、アプリケーション608は、オペレーティングシステム606と連携して実行することができる。すなわち、オペレーティングシステム606は、受信デバイス600のCPU(単数又は複数)602及び他のハードウェアコンポーネントとのアプリケーション608のインタラクションを容易にするように構成してもよい。オペレーティングシステム606は、セットトップボックス、デジタルビデオレコーダ、テレビなどにインストールされるように設計されたオペレーティングシステムであってよい。本明細書に記載された技術は、ソフトウェアアーキテクチャのいずれか及び全ての組み合わせを使用して動作するように構成されたデバイスによって利用され得ることに留意されたい。

システムインターフェース610は、受信デバイス600の構成要素間で通信できるように構成してもよい。一実施例では、システムインターフェース610は、あるピアデバイスから別のピアデバイス又は記憶媒体にデータを転送することを可能にする構造を含む。例えば、システムインターフェース610は、アクセラレーテッドグラフィックスポート(Accelerated Graphics Port、AGP)ベースプロトコル、例えば、Peripheral Component Interconnect Special Interest Groupによって管理されたPCI Express(商標)(PCIe)ハ゛ス仕様などのヘ゜リフェラルコンホ゜ーネントインターコネクト(Peripheral Component Interconnect、PCI)バスベースプロトコル、又はピアデバイスと相互接続するのに使用することができる任意の他の形態の構造(例えば、独自のバスプロトコル)に対応するチップセットを含むことができる。

上述のように、受信デバイス600は、テレビサービスネットワークを介してデータを受信し、任意選択的に送信するように構成されている。上述のように、テレビサービスネットワークは、電気通信規格に従って動作することができる。電気通信規格は、例えば、物理シグナリング、アドレス指定、チャネルアクセス制御、パケット特性、及びデータ処理などの通信特性(例えば、プロトコル層)を定義することができる。図7に示す例では、データ抽出装置612は、信号からビデオ、音声、及びデータを抽出するように構成してもよい。信号は、例えば、態様DVB規格、ATSC規格、ISDB規格、DTMB規格、DMB規格、及びDOCSIS規格に従って定義され得る。

データ抽出装置612は、信号からビデオ、音声、及びデータを抽出するように構成してもよい。すなわち、データ抽出装置612は、サービス配信エンジンに対して互恵的な方法で動作することができる。更に、データ抽出装置612は、上述の構造のうちの1つ以上の任意の組み合わせに基づいて、リンク層パケットをパースするように構成されてもよい。

データパケットは、CPU(単数又は複数)602、音声デコーダ614、及びビデオデコーダ618によって処理してもよい。音声デコーダ614は、音声パケットを受信及び処理するように構成してもよい。例えば、音声デコーダ614は、音声コーデックの態様を実施するように構成されているハードウェア及びソフトウェアの組み合わせを含むことができる。すなわち、音声デコーダ614は、音声パケットを受信して、レンダリングのために音声出力システム616に音声データを提供するように構成してもよい。音声データは、Dolby及びDigital Theater Systemsによって開発されたものなどのマルチチャネルフォーマットを使用して、符号化してもよい。音声データは、音声圧縮フォーマットを使用して符号化してもよい。音声圧縮フォーマットの例としては、Motion Picture Experts Group(MPEG)フォーマット、先進的音響符号化(Advanced Audio Coding、AAC)フォーマット、DTS-HDフォーマット、及びドルビーデジタル(AC-3)フォーマットが挙げられる。音声出力システム616は、音声データをレンダリングするように構成してもよい。例えば、音声出力システム616は、音声プロセッサ、デジタル/アナログ変換装置、増幅器、及びスピーカシステムを含むことができる。スピーカシステムは、ヘッドホン、統合ステレオスピーカシステム、マルチスピーカシステム、又はサラウンドサウンドシステムなどの様々なスピーカシステムのいずれかを含むことができる。

ビデオデコーダ618は、ビデオパケットを受信及び処理するように構成してもよい。例えば、ビデオデコーダ618は、ビデオコーデックの態様を実施するように使用されるハードウェア及びソフトウェアの組み合わせを含むことができる。一例では、ビデオデコーダ618は、ITU-T H.262又はISO/IEC MPEG-2 Visual、ISO/IEC MPEG-4 Visual、ITU-T H.264(ISO/IEC MPEG-4 Advanced video Coding(AVC)としても知られている)、及びHigh-Efficiency Video Coding(HEVC)などの任意の数のビデオ圧縮規格に従って符号化されたビデオデータを復号化するように構成してもよい。表示システム620は、表示のためにビデオデータを検索及び処理するように構成してもよい。例えば、表示システム620は、ビデオデコーダ618から画素データを受信し、ビジュアルプレゼンテーションのためにデータを出力することができる。更に、表示システム620は、ビデオデータと関連するグラフィックス(例えば、グラフィカルユーザインターフェース)を出力するように構成してもよい。表示システム620は、液晶ディスプレイ(liquid crystal display、LCD)、プラズマディスプレイ、有機発光ダイオード(organic light emitting diode、OLED)ディスプレイ、又はビデオデータをユーザに提示することができる別のタイプのディスプレイデバイスなどの様々な表示デバイスのうちの1つを含むことができる。表示デバイスは、標準精細度コンテンツ、高精細度コンテンツ、又は超高精度コンテンツを表示するように構成してもよい。

I/Oデバイス(単数又は複数)622は、受信デバイス600の動作中に入力を受信し、出力を提供するように構成してもよい。すなわち、I/Oデバイス(単数又は複数)622は、レンダリングされるマルチメディアコンテンツをユーザが選択できるようにしてよい。入力は、例えば、押しボタン式リモートコントロール、タッチ感知スクリーンを含むデバイス、モーションベースの入力デバイス、音声ベースの入力デバイス、又はユーザ入力を受信するように構成された任意の他のタイプのデバイスなどの入力デバイスから生成され得る。I/Oデバイス(単数又は複数)622は、例えば、ユニバーサルシリアルバスプロトコル(Universal Serial Bus、USB)、Bluetooth(登録商標)、ZigBee(登録商標)などの規格化された通信プロトコル、又は例えば、独自の赤外線通信プロトコルなどの独自の通信プロトコルを使用して、受信デバイス600に動作可能に結合され得る。

ネットワークインターフェース624は、受信デバイス600がローカルエリアネットワーク及び/又はワイドエリアネットワークを介してデータを送信及び受信できるように構成してもよい。ネットワークインターフェース624は、Ethernet(登録商標)カードなどのネットワークインターフェースカード、光トランシーバ、無線周波数トランシーバ、又は情報を送信及び受信するように構成された任意の他の種類のデバイスを含むことができる。ネットワークインターフェース624は、ネットワークで利用される物理層及びメディアアクセス制御(Media Access Control、MAC)層に従って、物理的シグナリング、アドレッシング、及びチャネルアクセス制御を実行するように構成してもよい。受信機デバイス600は、図6に関して上述した技術のいずれかに従って生成された信号をパースするように構成することができる。このようにして、受信デバイス600は、複数のカメラに関連付けられた位置、回転、及びカバレッジ情報のうちの1つ以上を示すシンタックス要素をパースし、かつパ-スされたシンタックス要素の値に基づいてビデオをレンダリングするように構成されたデバイスの一例を表す。

1つ以上の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせで実装することができる。ソフトウェアで実装される場合に、この機能は、コンピュータ可読媒体上の1つ以上の命令又はコードとして記憶するか又は伝送され、ハードウェアベースの処理部によって実行することができる。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、データ記憶媒体又は通信媒体などの有形の媒体に対応する、コンピュータ可読記憶媒体を含むことができる。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的な有形のコンピュータ可読記憶媒体、又は(2)信号又は搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示中に記載された技術の実現のための命令、コード、及び/又はデータ構造を取り出すために、1つ以上のコンピュータ又は1つ以上のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。

一例として、非限定的に、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROM、又は他の光学ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、フラッシュメモリ、又は任意の他の媒体、すなわち命令若しくはデータ構造の形式で所望のプログラムコードを記憶するために使用可能であり、かつコンピュータによりアクセス可能な任意の他の媒体を含むことができる。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。例えば、命令がウェブサイト、サーバ、又は他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線(digital subscriber line、DSL)、あるいは赤外線、無線及びマイクロ波などの無線技術を使用して伝送される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、あるいは赤外線、無線及びマイクロ波などの無線技術は、媒体の定義に含まれる。しかし、コンピュータ可読媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一過性媒体を含まないが、代わりに非一時的な有形記憶媒体を対象としていることを理解されたい。本発明で使用する場合、ディスク(disk)及びディスク(disc)は、コンパクトディスク(Compact Disc、CD)、レーザーディスク(laser disc)、光学ディスク(optical disc)、デジタル多用途ディスク(Digital Versatile Disc、DVD)、フロッピーディスク(floppy disk)及びブルーレイ(登録商標)ディスク(Blu-ray(登録商標)disc)を含み、ディスク(disk)は通常データを磁気的に再生し、ディスク(disc)はレーザを用いてデータを光学的に再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれなければならない。

命令は、1つ以上のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲート配列(FPGA)、又は他の同等の集積又はディスクリートロジック回路などの1つ以上のプロセッサによって実行することができる。したがって、本明細書で使用されるとき、用語「プロセッサ」は、前記の構造、又は本明細書で説明する技術の実装に好適な任意の他の構造のいずれかを指すことができる。加えて、いくつかの態様において、本明細書に記載の機能は、符号化及び復号化するように構成された、又は複合コーデックに組み込まれた専用のハードウェアモジュール及び/又はソフトウェアモジュール内に設けられ得る。また、この技術は、1つ以上の回路又は論理素子中に完全に実装することができる。

本開示の技術は、無線ハンドセット、集積回路(integrated circuit、IC)、又はICのセット(例えば、チップセット)を含む多種多様なデバイス又は装置に実装することができる。様々なコンポーネント、モジュール、又はユニットを本開示中に示し、開示された技術を実行するように構成されたデバイスの機能的な態様を強調しているが、異なるハードウェアユニットによって実現することは必ずしも必要ではない。むしろ、前述したように、様々なユニットは、コーデックハードウェアユニットに組み合わせてもよく、又は好適なソフトウェア及び/又はファームウェアと共に、前述の1つ以上のプロセッサを含む、相互動作ハードウェアユニットの集合によって提供することができる。

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

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

<相互参照>
本特許出願は、合衆国法典第35巻米国特許法第119条の下で、2018年6月4日の仮出願第62/680,384号の優先権を主張するものであり、その内容の全体は、参照により本明細書に組み込まれる。

ITU-T H.265では、CTUのCTBは、対応する四分木ブロック構造に従って符号化ブロック (CB)に区画化することができる。ITU-T H.265によれば、1つのルマCBは、2つの対応する
クロマCB及び関連するシンタックス要素と共に、符号化ユニット(CU)と呼ばれる。CUは、CUに対する1つ以上の予測部(prediction unit、PU)を定義する予測部(PU)構造に関連し、PUは、対応する参照サンプルに関連する。すなわち、ITU-T H.265では、イントラ予測又はインター予測を使用してピクチャ領域を符号化する決定がCUレベルで行われ、CUに関し、イントラ予測又はインター予測に対応する1つ以上の予測を使用して、CUのCBに対する参照サンプルを生成することができる。ITU-T H.265では、PUは、ルマ及びクロマ予測ブロック(prediction block、PB)を含むことができ、正方形PBはイントラ予測に対してサポートされ、矩形PBはインター予測に対してサポートされる。イントラ予測データ(例えば、イントラ予測モードシンタックス要素)又はインター予測データ(例えば、動きデータシンタックス要素)は、PUを対応する参照サンプルに関連させることができる。残差データは、ビデオデータの各成分(例えば、ルマ(Y)及びクロマ(Cb及びCr))に対応する差分値のそれぞれのアレイを含むことができる。残差データは、画素領域内とすることができる。離散コサイン変換(discrete cosine transform、DCT)、離散サイン変換(discrete sine transform、DST)、整数変換、ウェーブレット変換、又は概念的に類似の変換などの変換を、画素差分値に適用して、変換係数を生成することができる。ITU-T H.265では、CUは、更に変換ユニット(TTransform Unit、TU)に再分割できることに留意されたい。すなわち、画素差分値のアレイは、変換係数を生成するために再分割することができ(例えば、4つの8×8変換を、16×16のルマCBに対応する残差値の16×16のアレイに適用することができる)、そのような再分割は、変換ブロック(Transform Block、TB)と呼ばれることがある。変換係数は、量子化パラメータ(quantization parameter、QP)に従って量子化され得る。量子化された変換係数(これはレベル値と呼ばれることがある)は、エントロピ符号化技術 (例えば、コンテンツ適応可変長符号化(content adaptive variable length coding、CAV
LC)、コンテキスト適応2値算術符号化(context adaptive binary arithmetic coding、CABAC)、確率区間分割エントロピ符号化(probability interval partitioning entropy coding、PIPE)など)に従ってエントロピ符号化することができる。更に、シンタックス要素、例えば、予測モードを示すシンタックス要素なども、エントロピ符号化することができる。エントロピ符号化され量子化された変換係数及び対応するエントロピ符号化されたシンタックス要素は、ビデオデータを再生成するために使用することができる準拠ビットストリームを形成することができる。二値化プロセスを、エントロピ符号化プロセスの一部としてシンタックス要素に対して実行することができる。二値化は、シンタックス値を一連の1つ以上のビットに変換するプロセスを指す。これらのビットは、「ビン」と呼ばれることがある。
仮想現実(VR)アプリケーションは、ヘッドマウントディスプレイでレンダリングすることができるビデオコンテンツを含むことができ、ユーザの頭部の向きに対応する全天球映像の領域のみがレンダリングされる。VRアプリケーションは、360度ビデオの360度全天球映像とも呼ばれる、全方位ビデオによって使用可能にすることができる。全方位ビデオは、典型的には、最大360度のシーンをカバーする複数のカメラによってキャプチャされる。通常のビデオと比較した全方位ビデオの明確な特徴は、典型的には、キャプチャされたビデオ領域全体のサブセットのみが表示される、すなわち、現在のユーザの視野(FOV)に対応する領域が表示されることである。FOVはまた、時に、ビューポートとも呼ばれる。他の場合では、ビューポートは、現在表示され、ユーザによって見られている球面ビデオの一部として説明することができる。ビューポートのサイズは、視野以下でもよいことに留意されたい。更に、全方位ビデオは、モノスコープカメラ又はステレオスコープカメラを使用してキャプチャされ得ることに留意されたい。モノスコープカメラは、オブジェクトの単一視野をキャプチャするカメラを含んでもよい。ステレオスコープカメラは、同じオブジェクトの複数のビューをキャプチャするカメラを含んでもよい(例えば、わずかに異なる角度で2つのレンズを使用してビューをキャプチャする)。場合によっては、ビューポートの中心点は、視点と呼ばれることもあるという点に留意すべきである。しかしながら、本明細書で使用するとき、カメラに関連付けられた場合の視点(例えば、カメラ視点)という用語は、オブジェクトのビュー(単数又は複数)をキャプチャするために使用されるカメラに関連付けられた情報(例えば、カメラパラメータ)を指し得る。更に、場合によっては、全方位ビデオアプリケーションで使用するための画像は、超広角レンズ(すなわち、いわゆる魚眼レンズ)を使用してキャプチャされ得ることに留意されたい。いずれの場合も、360度の球面ビデオを作成するためのプロセスは、一般に、入力画像をつなぎ合わせること、つなぎ合わされた入力画像を3次元構造(例えば、球体又は立方体)上にプロジェクションして、いわゆるプロジェクトフレームをもたらし得ることとして説明することができる。更に、場合によっては、プロジェクトフレームの領域を、変換し、リサイズし、及び再配置してもよく、これによっていわゆるパックフレームをもたらすことができる。

Wangは、ビデオがITU-T H.265に従って符号化されるメディアプロファイルを提供する。ITU-T H.265は、高効率ビデオ符号化(High Efficiency Video Coding、HEVC),Recに記載されている。ITU-T H.265(2016年12月)は、参照により本明細書に組み込まれ、本明細書ではITU-T H.265と呼ばれる。上述のように、ITU-T H.265によれば、各ビデオフレーム又はピクチャは、1つ以上のスライスを含むように区画化してもよく、1つ以上のタイルを含むように更に区画化してもよい。図2A〜図2Bは、スライスを含み、ピクチャを更にタイルに区画化するピクチャ群の一例を示す概念図である。図2Aに示す例では、Pic4は、2つのスライス(すなわち、Slice1及びSlice2)を含むものとして示されており、各スライスは(例えばラスタ走査順に)CTUのシーケンスを含む。図2Bに示す例では、Pic4は、6つのタイル(すなわち、Tile1〜Tile6)を含むものとして示されており、各タイルは矩形であり、CTUのシーケンスを含む。ITU-T H.265では、タイルは、2つ以上のスライスに包含される符号化ツリーユニットからなっていてもよく、スライスは、2つ以上のタイルに包含される符号化ツリーユニットからなっていてもよいことに留意されたい。しかしながら、ITU-T H.265は、以下の条件のうちの1つ又は両方が満たされなければならないと規定している。(1)あるスライス中の全ての符号化ツリーユニットは同じタイルに属する、及び(2)あるタイル内の全ての符号化ツリーユニットは同じスライスに属する。

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

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

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

1より大きい形状タイプ値が予備としてある。

シンタックス

セマンティクス
centre_azimuth及びcentre_elevationは、球面領域の中心を指定するものである。
centre_azimuthは、両端値を含む、-180*216〜180*216-1の範囲にあるものとする。centre_elevationは、両端値を含む、-90*216〜90*216の範囲にあるものとする。
centre_tiltは、球体領域の傾斜角を指定し、centre_tiltは、両端値を含む、-180*216〜180*216-1の範囲にあるものとする。
azimuth_range及びelevation_rangeは、存在する場合、それぞれ、この構造によって指定される球体領域の方位範囲及び高度範囲を2-16度の単位で指定する。azimuth_range及びelevation_rangeは、図5A又は図5Bに示すように、球体領域の中心点を通る範囲を指定する。SphereRegionStructのこのインスタンスにazimuth_range及びelevation_rangeが存在しない場合、SphereRegionStructのこのインスタンスを含む構造のセマンティクスにおいて指定されると推測される。azimuth_rangeは、両端値を含む、0〜360*216の範囲にあるものとする。elevation_rangeは、両端値を含む、0〜180*216の範囲にあるものとする。
interpolateのセマンティクスは、SphereRegionStructのこのインスタンスを含む構造のセマンティクスによって指定される。

上述のように、Wang内の球体領域構造は、様々なタイプのメタデータをシグナリングするための基礎をなす。球体領域に対して汎用タイムドメタデータトラックシンタックスを指定することに関して、Wangは、サンプルエントリ及びサンプルフォーマットを指定する。サンプルエントリ構造は、以下の定義、シンタックス、及びセマンティクスを有するものとして指定される。
定義
ちょうど1つのSphereRegionConfigBoxが、サンプルエントリに存在するものとする。
SphereRegionConfigBoxは、サンプルによって指定された球体領域の形状を指定する。サンプル内の球体領域の方位範囲及び高度範囲が変化しない場合、それらはサンプルエントリ内に示され得る。
シンタックス

セマンティクス
0に等しいshape_typeは、4つの大円によって指定される球体領域を指定する。1に等しいshape_typeは、2つの方位円及び2つの高度円によって指定される球体領域を指定する。1より大きいshape_typeの値が予約済みである。shape_typeの値は、(上述の)球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合に、形状タイプ値として使用される。
0に等しいdynamic_range_flagは、このサンプルエントリを参照する全てのサンプルにおいて、球体領域の方位範囲及び高度範囲が変化されないままであることを指定する。1に等しいdynamic_range_flagは、球体領域の方位範囲及び高度範囲がサンプルフォーマットで示されることを指定する。
static_azimuth_range及びstatic_elevation_rangeは、それぞれ、このサンプルエントリを参照する各サンプルに対して、球体領域の方位範囲及び高度範囲を2-16度の単位で指定する。static_azimuth_range及びstatic_elevation_rangeは、図5A又は図5Bに示すように、球体領域の中心点を通る範囲を指定する。static_azimuth_rangeは、両端値を含む、0〜360*216の範囲にあるものとする。static_elevation_rangeは、両端値を含む、0〜180*216の範囲にあるものとする。static_azimuth_range及びstatic_elevation_rangeが存在し、両方とも0に等しい場合、このサンプルエントリを参照する各サンプルの球体領域は、球体表面上の点である。(上述の)球体領域を記述する項目を、球体領域メタデータトラックのサンプルのセマンティクスに適用する場合、static_azimuth_range及びstatic_elevation_rangeが存在する場合は、azimuth_range及びelevation_rangeの値は、それぞれ、static_azimuth_range及びstatic_elevation_rangeに等しいと推測される。
num_regionsは、このサンプルエントリを参照するサンプル内の球体領域数を指定する。num_regionsは、1に等しいものとする。num_regionsの他の値は予備とされる。

Wangでは、タイムドメタデータは、サンプルエントリ及びサンプルフォーマットに基づいてシグナリングしてもよい。例えば、Wangは、以下の定義、シンタックス、及びセマンティクスを有する初期ビューイング方向メタデータを含む。
定義
このメタデータは、関連付けられたメディアトラック、又は画像アイテムとして記憶された単一の全方位画像を再生する場合に使用されるべき初期ビューイング方向を示す。このタイプのメタデータ、centre_azimuth、centre_elevation、及びcentre_tiltの非存在下では、全て0に等しいと推測されたい。
OMAF(全方位メディアフォーマット)プレイヤは、指示された又は推定されたcentre_azimuth、centre_elevation、及びcentre_tiltを以下のように使用するべきである。
-OMAFプレイヤの方向/ビューポートメタデータが、ビューイングデバイスに含まれるか又はそれに取り付けられた方向センサを基礎にして取得される場合、OMAFプレイヤは、
・centre_azimuth値のみに従うべきであり、かつ、
・centre_elevation及びcentre_tiltの値を無視し、代わりに方向センサからのそれぞれの値を使用するべきである。
-そうでない場合は、OMAFプレイヤは、centre_azimuth、centre_elevation、及びcentre_tiltの3つ全てに従うべきである。

トラックサンプルエントリタイプ「初期ビュー方向タイムドメタデータ」を使用するものとする。

centre_azimuth、centre_elevation、及びcentre_tiltは、グローバル座標軸に対してビューイング方向を2-16度の単位で指定する。centre_azimuth及びcentre_elevationは、ビューポートの中心を示し、centre_tiltは、ビューポートの傾斜角を示す。

interpolateは、0に等しいものとする。

更に、Wangは、以下のように推奨ビューポートタイムドメタデータトラックを指定する。
推奨ビューポートタイムドメタデータトラックは、ユーザが視聴方位の制御を有さないか、又は視聴方位の制御を解除したときに表示されるべきビューポートを示す。
注記:推奨ビューポートタイムドメタデータトラックは、ディレクタのカットに基づいて、又は視聴統計の測定値に基づいて、推奨ビューポートを示すために使用されてもよい。

タイムドテキストは、全方位ビデオの字幕及びクローズドキャプションを提供するために使用される。Wangでは、タイムドテキストキューは、球体に対して特定の領域上にレンダリングされてもよく(すなわち、ユーザが特定の方向を見るときにのみ視認可能である)、又は現在のビューポート上の領域にレンダリングされてもよく(すなわち、常に視聴方向に関係なく視認可能である)、その場合、テキスト/キュー領域の位置は現在のビューポートに対して相対的である。具体的には、Wangは、タイムドテキスト構成ボックスのための、以下の定義、シンタックス、及びセマンティクスを提供する。
定義
ボックスタイプ:‘otcf’
コンテナ:XMLSubtitleSampleEntry又はWVTTSampleEntry
必須:はい(全方位ビデオトラックに関連付けられたタイムドテキストトラックの場合)
数:1つ(全方位ビデオトラックに関連付けられたタイムドテキストトラックの場合)
このボックスは、タイムドテキストを全方向ビデオと共に提示するための構成情報を提供する。
シンタックス

セマンティクス
relative_to_viewport_flagは、タイムドテキストキューがどのようにレンダリングされるべきかを指定する。タイムドテキストが常にディスプレイスクリーン上に存在することが予想されること、すなわち、テキストキューがユーザの視聴方向とは独立して視認可能であることを、値1は示す。タイムドテキストが球体上の特定の位置でレンダリングされることが予想されること、すなわち、ユーザが、テキストキューがレンダリングされている方向を見ているときにのみ、テキストキューが視認可能であることを、値0は示す。
注記1:relative_to_viewport_flagが1に等しい場合、タイムドテキストが表示され得るアクティブエリアは、タイムドテキストトラックによって矩形領域として提供される。

1に等しいdepth_included_flagは、タイムドテキストがレンダリングされる領域の深さ(z値)が存在することを示す。値0は、タイムドテキストがレンダリングされる領域の深さ(z値)が存在しないことを示す。

region_countは、球体内の配置が提供されるテキスト領域の数を指定する。各領域は識別子によって識別される。(WebVTT及びTTMLの両方は、固有のidを使用して領域を識別する)。タイムドテキスト球体メタデータトラックを含むタイムドメタデータトラックが存在し、タイプ’cdsc’のトラック参照によってこのタイムドテキストトラックにリンクされる場合、region_countの値は0であるものとする。
注記2:WebVTT及びTTMLの両方は、一意の識別子を使用して領域を識別する。
region_idは、テキスト領域の識別子を提供する。この識別子は、IMSC1又はWebVTTトラック内のタイムドテキストストリーム内に定義された対応する領域の識別子に等しいものとする。

disparity_in_percentは、1つのビューのディスプレイウィンドウの幅の分画としての2-16の単位での視差を示す。この値は負であってもよく、その場合、変位方向は逆である。この値を使用して、左目視野上の左及び右目視野上の右に領域を変位させる。

SphereRegionStruct()は、球体の場所を示し、この球体の場所を他の情報と共に使用して、タイムドテキストが3D空間内に配置され表示される場所が決定される。球体の中心とこの球体の場所との間のベクトルは、タイムドテキストキューがレンダリングされるレンダリング3D平面に対する法線ベクトルである。この情報及び3D平面の深さは、タイムドテキストキューがレンダリングされる3D空間内のレンダリング3D平面の位置を決定するために使用される。

SphereRegionStruct()がOmafTimedTextConfigBoxに含まれる場合、以下が適用される。
OmafTimedTextConfigBoxに含まれるSphereRegionStruct()のシンタックス及びセマンティクスについて、shape_type、dynamic_range_flag、static_azimuth_range、及びstatic_elevation_rangeの値は、全て0に等しいと推測される。
centre_azimuth及びcentre_elevationは、他の情報と共に使用して、タイムドテキストが3D空間内に配置され表示される場所を決定するのに用いられる球体の場所を指定する。centre_azimuthは、両端値を含む、-180*216〜180*216-1の範囲にあるものとする。centre_elevationは、両端値を含む、-90*216〜90*216の範囲にあるものとする。
centre_tiltは、0に等しいものとする。
region_depthは、タイムドテキストがレンダリングされる領域の深さ(z値)を示す。深さ値は、タイムドテキスト領域の法線ベクトルのノルムである。この値は単位球体を基準とし、2-16の単位である。

上述のように、様々なオーバーレイが、異なる時間で有効及び無効にされてもよい。例えば、広告ロゴはオーバーレイとして使用されてもよく、表示されたオーバーレイロゴは経時的に動的に変化してもよい。一実施例では、このシグナリングのために、カプセル化されたデータは、オーバーレイタイムドメタデータトラックを使用するように構成することができる。例示的なオーバーレイタイムドメタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイタイムドメタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)(例えば、広告のロゴ)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’movl’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

一実施例では、任意の特定の時間でアクティブな1つ以上のオーバーレイは、サンプルに直接シグナリングされてもよい。この場合、一実施例では、例示的なオーバーレイタイムドメタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイタイムドメタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)(例えば、広告のロゴ)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’dovl’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

一実施例では、オーバーレイの一部は、サンプルエントリ内のそれらのオーバーレイ識別子を参照することによって、サンプルにシグナリングされる。更に、いくつかの新しいオーバーレイは、サンプルエントリ内のそれらのオーバーレイ構造をシグナリングすることによって直接シグナリングすることができる。この場合、一実施例では、例示的なオーバーレイタイムドメタデータトラックのシンタックス及びセマンティクスは、以下のようであってもよい。
概要
動的オーバーレイタイムドメタデータトラックは、複数のオーバーレイからのオーバーレイが異なる時間にアクティブであることを示す。用途に応じて、アクティブオーバーレイ(単数又は複数)は経時的に変化し得る。
サンプルエントリ
定義
トラックサンプルエントリタイプ’dyol’を使用するものとする。このサンプルエントリタイプのサンプルエントリは、以下のように指定される。
シンタックス

上述のように、Wangでは、タイムドテキストシグナリングについて、relative_to_viewport_flagがシグナリングされる。一実施例では、データカプセル化部107は、オーバーレイ又はタイムドテキストに関し、特定の条件下で、共通参照座標で位置を指定するように構成することができる。例えば、この場合、オーバーレイは、3D空間内に配置されてもよく、選択された視点に応じて、その一部又は全部が視認可能であり得る。一実施例では、これは、ビューポートをオーバーレイするために行われてもよい。一実施例では、データカプセル化部107は、以下のように、SphereRegionStruct()と共にビューポートをシグナリングするように構成することができる。
シンタックス

セマンティクス
viewport_x、viewport_y、及びviewport_zは、共通参照座標系の中心として(0,0,0)を有する3D空間内の球体の中心の位置を、ミリメートル単位で、指定する。球体の中心は、以下のSphereRegionStruct(1)と共に、オーバーレイが3D空間内に配置され表示される場所を決定するビューポートの位置を指定する。
RecommendedViewportInformation()は、推奨ビューポートに関する情報を指定する。これは、例えば、推奨ビューポートに対応するタイムドメタデータトラックを指定するtrack_IDのリスト内のインデックスを含んでもよい。
SphereRegionStruct(1)は球体の場所を示し、これは、他の情報と共に使用して、オーバーレイが3D空間内に配置され表示される場所を決定する。球体の中心とこの球体の場所との間のベクトルは、オーバーレイがレンダリングされるレンダリング3D平面のノルムである。この情報及び3D平面の深さは、オーバーレイがレンダリングされる3D空間内のレンダリング3D平面の位置を決定するために使用される。

又は

図1を再び参照すると、インターフェース108は、データカプセル化部107によって生成されたデータを受信し、そのデータを通信媒体に送信及び/又は記憶するように構成された任意のデバイスを含んでもよい。インターフェース108は、イーサネットカードなどのネットワークインターフェースカードを含むことができ、光送受信機、無線周波数送受信機、又は情報を送信及び/若しくは受信することができる任意の他の種類のデバイスを含むことができる。更に、インターフェース108は、ファイルを記憶デバイス上に記憶することを可能にすることができるコンピュータシステムインターフェースを含むことができる。例えば、インターフェース108は、Peripheral Component Interconnect(PCI)及びPeripheral Component Interconnect Express(PCIe)バスプロトコル、独自のバスプロトコル、ユニバーサルシリアルバス(Universal Serial Bus、USB)プロトコル、I2C、又はピアデバイスを相互接続するために使用することができる任意の他の論理構造及び物理構造をサポートする、チップセットを含むことができる。

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

図7に示すように、受信デバイス600は、中央処理装置(単数又は複数)602、システムメモリ604、システムインターフェース610、データ抽出装置612、音声デコーダ614、音声出力システム616、ビデオデコーダ618、表示システム620、I/Oテ゛ハ゛イス(単数又は複数) 622、及びネットワークインターフェース624を含む。図7に示すように、システムメモリ6
04は、オヘ゜レーティンク゛システム606及びアフ゜リケーション608を含む。中央処理装置(単数又は複数)602、システムメモリ604、システムインターフェース610、テ゛ータ抽出装置612、音声テ゛コータ゛614、音声出力システム616、ヒ゛テ゛オテ゛コータ゛618、表示システム620、I/Oテ゛ハ゛イス(単数又は複数)622、及びネットワークインターフェース624の各々は、コンホ゜ーネント間通信のために(物理的、通信的、及び/又は動作的に)相互接続してもよく、1つ以上のマイクロプロセッサ、デジタル信号プロセッサ(digital signal processor、DSP)、特定用途向け集積回路(application specific integrated circuit、ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array、FPGA)、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な好適な回路のいずれかとして実装することができる。受信デバイス600は、別個の機能ブロックを有するものとして図示されているが、このような図示は、説明を目的としており、受信デバイス600を特定のハードウェアアーキテクチャに限定しないという点に留意されたい。受信デバイス600の機能は、ハードウェア実装、ファームウェア実装、及び/又はソフトウェア実装の任意の組み合わせを使用して実現することができる。

システムメモリ604は、非一時的又は有形のコンピュータ可読記憶媒体として説明することができる。いくつかの実施例では、システムメモリ604は、一時的及び/又は長期記憶部を提供することができる。いくつかの実施例では、システムメモリ604又はその一部は、不揮発性メモリとして記述してもよく、別の実施例では、システムメモリ604の一部は、揮発性メモリとして記述してもよい。システムメモリ604は、動作中に受信デバイス600によって使用され得る情報を記憶するように構成してもよい。システムメモリ604は、CPU (単数又は複数)602によって実行するためのプログラム命令を記憶するために使用することができ、受信デバイス600上で実行しているプログラムについて、プログラム実行中に情報を一時的に記憶するために使用してもよい。更に、受信デバイス600がデジタルビデオレコーダの一部として含まれる実施例では、システムメモリ604は、多数のビデオファイルを記憶するように構成してもよい。

一例として、非限定的に、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROM、又は他の光学ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、フラッシュメモリ、又は任意の他の媒体、すなわち命令若しくはデータ構造の形式で所望のプログラムコードを記憶するために使用可能であり、かつコンピュータによりアクセス可能な任意の他の媒体を含むことができる。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。例えば、命令がウェブサイト、サーバ、又は他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線(digital subscriber line、DSL)、あるいは赤外線、無線及びマイクロ波などの無線技術を使用して伝送される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、あるいは赤外線、無線及びマイクロ波などの無線技術は、媒体の定義に含まれる。しかし、コンピュータ可読媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一過性媒体を含まないが、代わりに非一時的な有形記憶媒体を対象としていることを理解されたい。本発明で使用する場合、ディスク(disk)及びディスク(disc)は、コンパクトディスク(Compact Disc、CD)、レーザーディスク(laser disc)、光学ディスク(optical disc)、デジタル多用途ディスク(Digital Versatile Disc、DVD)、フロッピーディスク(floppy disk)及びブルーレイ (登録商標)ディスク(Blu-ray(登録商標)disc)を含み、ディスク(disk)は通常データを磁気的に再生し、ディスク(disc)はレーザを用いてデータを光学的に再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれなければならない。

Claims

全方位ビデオに関連付けられたオーバーレイ情報をシグナリングする方法であって、
複数のオーバーレイのそれぞれについて、一意の識別子及びラベルをシグナリングすることと、
前記複数のオーバーレイに時間変化する更新をシグナリングすることと、を含む、方法。
全方位ビデオに関連付けられたオーバーレイ情報を決定する方法であって、
複数のオーバーレイのそれぞれについて、一意の識別子及びラベルを示すシンタックス要素をパースすることと、
前記パ-スされたシンタックス要素の値に基づいてビデオをレンダリングすることと、を含む、方法。
請求項1又は2に記載のステップのいずれか及び全ての組み合わせを実行するように構成されている1つ以上のプロセッサを備える、デバイス。
請求項1〜2に記載の工程のいずれか及び全ての組み合わせを実行する手段を備える、装置。
非一時的コンピュータ可読記憶媒体であって、前記媒体上に記憶された命令を含み、前記命令が実行された場合には、デバイスの1つ以上のプロセッサに、請求項1〜2に記載の前記工程のいずれか及び全ての組み合わせを実行させる、非一時的コンピュータ可読記憶媒体。