JP6721631B2 - ビデオの符号化・復号の方法、装置、およびコンピュータプログラムプロダクト - Google Patents

Description

本技術は、概してビデオの符号化・復号に関する。

背景

写真、映画撮影はその創世以来、画像およびビデオコンテンツが比較的狭い視野のカメラで撮影され、平坦なディスプレイに矩形のシーンとして表示されることが最も一般的であった。しかし、近年では画像およびビデオを撮影する新たなデバイスが出現しており、全周囲にわたる視聴覚コンテンツを撮影可能となっている。このコンテンツは、３６０度画像／ビデオまたは全方向画像／ビデオと呼ばれる。

さらに、ヘッドマウント・ディスプレイ等の新たな出力技術も発明、生産されている。当該デバイスは、使用者に、自身の全周囲の視覚的コンテンツを見ることを可能とする。このような視野が球状となる、新たな撮影および表示形態は一般的にバーチャル・リアリティ（ＶＲ）と呼ばれており、将来的に人々がメディアコンテンツを利用する一般的な手段となると目されている。

摘要

ここで、メディアコンテンツのストリーミング帯域幅を低減するための改良された方法と当該方法を実施する技術的装置が発明された。本発明の各種態様には、独立請求項に記載されている内容を特徴とする方法、装置、およびコンピュータプログラムを格納したコンピュータ可読媒体が含まれる。本発明の各種実施形態は、従属請求項に開示されている。

第１の態様によると方法が提供され、前記方法は、メディアコンテンツのビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための一連のインジケータを符号化することを含み、不均一の種類によって、第１のビューまたは領域のビデオストリームおよび第２のビューまたは領域のビデオストリームに対して異なる符号化パラメータを定義する。

第２の態様によると装置が提供され、前記装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含むメモリとを備え、前記メモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、前記装置に対して、メディアコンテンツのビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための一連のインジケータを符号化させるように構成され、不均一の種類によって、第１のビューまたは領域のビデオストリームおよび第２のビューまたは領域のビデオストリームに対して異なる符号化パラメータを定義する。

第３の態様によると非一時的コンピュータ可読媒体に実施されたコンピュータプログラムプロダクトが提供され、前記コンピュータプログラムプロダクトは、少なくとも１つのプロセッサによって実行されると、装置またはシステムに対して、メディアコンテンツのビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための一連のインジケータを符号化させるように構成されたコンピュータプログラムコードを含み、不均一の種類によって、第１のビューまたは領域のビデオストリームおよび第２のビューまたは領域のビデオストリームに対して異なる符号化パラメータを定義する。

ある実施形態によると、前記方法は上述の装置および／またはコンピュータプログラムプロダクトによって実施され、前記メディアコンテンツの前記ビットストリームの中にまたはこれに沿って、前記第１のビューまたは領域に関連付けられた第１の品質ランキング値および前記第２のビューまたは領域に関連付けられた第２の品質ランキング値を含めることをさらに含み、前記第１および第２の品質ランキング値の順序は、前記第１のビューまたは領域と前記第２のビューまたは領域との知覚される品質の順序を示す。

ある実施形態によると、前記方法は上述の装置および／またはコンピュータプログラムプロダクトによって実施され、前記メディアコンテンツの前記ビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための第２の一連のインジケータを含めることをさらに含み、前記第２の一連のインジケータは、同じ品質ランキング値を有する複数の領域中の前記不均一の種類を示す。

ある実施形態によると、前記方法は上述の装置および／またはコンピュータプログラムプロダクトによって実施され、前記メディアコンテンツの前記ビットストリームの中にまたはこれに沿って、前記ビデオストリームのいずれがより高品質であるかを示すパラメータを符号化することをさらに含む。

ある実施形態によると、前記メディアコンテンツは１つ以上の３６０度ピクチャを含む。

ある実施形態によると、前記一連のインジケータは、不均一インジケータマスクのそれぞれのビット位置に符号化される。

本発明の各種実施形態を以下の図面を参照して詳細に説明する。
図１は、一実施形態による装置を概略ブロック図で示す。 図２は、ある実施形態による装置のレイアウトを示す。 図３は、ある実施形態による表示デバイスを示す。 図４は、ある実施形態によるエンコーダを示す。 図５は、ある実施形態によるデコーダを示す。 図６は、エンドツーエンドＤＡＳＨシステムの一例を示す。 図７は、３６０度画像／ビデオコンテンツの作成の一例を示す。 図８は、単一視正距円筒パノラマピクチャを形成する処理の一例を示す。 図９は、詰め込まれた（packed）バーチャル・リアリティ（ＶＲ）フレームの一例を示す。 図１０は、ある実施形態による方法のフローチャートを示す。

詳細説明

本技術は１つ以上のカメラで撮影された全方向ビデオに関し、このビデオはネットワークを介してストリーミング配信され、例えばヘッドマウント・ディスプレイ（ＨＭＤ）等の視覚デバイスにレンダリングされる。本実施形態は、メディアコンテンツのストリーミング帯域幅の低減を促進する。

本技術について詳細に説明する前に、一実施形態による装置を図１および図２を参照して開示する。

図１は、例示的実施形態によるビデオ符号化システムのブロック図を、コーデックが組み込まれていてもよい電子デバイス５０の概略ブロック図として示す。ある実施形態では、この電子デバイスは、エンコーダまたはデコーダを備えてもよい。図２は、ある実施形態による装置のレイアウトを示す。電子デバイス５０は、無線通信システムにおける携帯端末またはユーザ端末であってもよく、カメラデバイスであってもよい。電子デバイス５０は、ローカルサーバまたはリモートサーバに設けられてもよく、コンピュータのグラフィック・プロセッシング・ユニットに設けられてもよい。前記デバイスは、ヘッドマウント・ディスプレイデバイスの一部として設けられてもよい。

デバイス５０は、これを収容、保護する筐体３０を備えてもよい。デバイス５０はさらに、液晶ディスプレイであるディスプレイ３２を備えてもよい。本発明の別の実施形態では、ディスプレイは画像またはビデオ表示に適した表示技術を採用してもよい。デバイス５０は、さらにキーパッド３４を備えてもよい。本発明の別の実施形態では、任意の好適なデータまたはユーザインタフェース機構を利用してもよい。例えば、このユーザインタフェースは、タッチ感知ディスプレイの一部としてのバーチャルキーボードまたはデータ入力システムとして実現されてもよい。

デバイス５０は、マイクロフォン３６または任意の好適な音声入力（デジタル信号入力であってもアナログ信号入力であってもよい）を備えてもよい。デバイス５０は、音声出力装置をさらに備えてもよい。本発明の各実施形態では、該音声出力装置は、受話口３８、スピーカー、アナログ音声出力接続部またはデジタル音声出力接続部のいずれかであってもよい。デバイス５０は、バッテリをさらに備えてもよい（または本発明の別の実施形態では、デバイスが、太陽電池、燃料電池、またはゼンマイ式発電機等の任意の好適な可搬性エネルギー装置によって電源供給されてもよい）。またデバイス５０は、画像や動画の記録や撮像が可能なカメラ４２を備えてもよい。カメラ４２は、少なくとも２つのカメラセンサを有する複数レンズカメラシステムである。このカメラは、個々のフレームを記録または検出可能であり、このフレームはコーデック５４またはコントローラに処理するために渡される。このデバイスは、別のデバイスからビデオおよび／または画像データを処理するために受信して、その後このデータを送信および／または格納してもよい。このデバイスは、カメラによって撮影された画像データから３６０度立体ビデオを生成することが可能である。

デバイス５０はさらに、別のデバイスとの短直線距離通信用の赤外線ポートを備えてもよい。ある実施形態によると、デバイス５０はさらに、例えばＢｌｕｅｔｏｏｔｈ（登録商標）無線接続またはＵＳＢ（Universal Serial Bus）／ＦｉｒｅＷｉｒｅ有線接続等の、任意の好適な近距離通信手段を備えてもよい。

デバイス５０は、これを制御するコントローラ５６またはプロセッサを備えてもよい。このデバイス５０またはコントローラ５６は、１つ以上のプロセッサまたはプロセッサ回路を含んでもよく、メモリ５８に接続されてもよい。メモリ５８は、画像、ビデオ、音声データのいずれの形式のデータを格納してもよく、および／またはコントローラ５６において実行される命令やプロセッサまたはプロセッサ回路によって実行される命令を格納してもよい。コントローラ５６は、画像、ビデオ、および／または音声データの符号化・復号の実行や、コントローラが実行する符号化・復号の補助に適したコーデック回路５４に接続されてもよい。

デバイス５０は、ユーザ情報を提供し、ネットワークにおけるユーザを認証、承認するための認証情報の提供に適した、例えばＵＩＣＣ（Universal Integrated Circuit Card）およびＵＩＣＣリーダー等のカードリーダー４８およびスマートカード４６をさらに備えてもよい。

デバイス５０は、コントローラに接続され、例えば携帯通信ネットワーク、無線通信システム、または無線ローカルエリアネットワークと通信するための無線通信信号の生成に適した無線インタフェース回路５２を備えてもよい。デバイス５０は、無線インタフェース回路５２に接続され、無線インタフェース回路５２で生成された無線周波数信号を単一または複数の別の装置に送信し、単一または複数の別の装置から無線周波数信号を受信するためのアンテナ４４をさらに備えてもよい。デバイス５０は、例えば電気ケーブルまたは光ファイバ接続等の有線接続によってデータを送信および／または受信するように構成された１つ以上の有線インタフェースを備えてもよい。この有線インタフェースは、例えばＨＤＭＩ（登録商標）、モバイル・ハイディフィニション・リンク（ＭＨＬ）、デジタル・ビジュアル・インタフェース（ＤＶＩ）等の１つ以上のデジタル表示インタフェース規格に準拠して動作するように構成されてもよい。

図３を参照して、別の実施形態による装置を開示する。図３は、例示的実施形態によるビデオ復号システムのブロック図を、電子デバイスの概略ブロック図として示す。図３のビデオ復号システムは、立体視を可能とするヘッドマウント・ディスプレイである。このヘッドマウント・ディスプレイは、左眼および右眼用の画像を表示する２つのスクリーン部または２つのスクリーンＤＩＳＰ１およびＤＩＳＰ２を備える。これらのディスプレイは両眼に近く配置されることから、レンズを使用して画像を見やすくし、両眼の視野をできるだけ網羅するように画像を拡大する。このデバイスは、ユーザが頭を振ってもあるべき箇所に留まるようにユーザの頭部に装着される。また、このデバイスは、頭部の動きや方向を特定する方位検出回路ＯＲＤＥＴ１を備えてもよい。この方位検出回路からの出力は、ユーザの視線の方向を推定するために使用されてもよい。もしくは、視線方向の推定のために、視線検出回路がデバイスに設けられてもよい。ヘッドマウント・ディスプレイによって、ユーザは記録されたコンテンツやストリーミング配信されたコンテンツを三次元（３Ｄ）で知覚することができる。

ヘッドマウント・ディスプレイの代わりに、拡張現実（augmented reality）／復号現実（mixed reality）（ＡＲ／ＭＲ）メガネをビデオ復号システムとして使用してもよい。

ビデオコーデックは、入力されたビデオを格納／送信に適した圧縮表現に変換するエンコーダと、その圧縮ビデオ表現を可視形態に戻す展開を行うデコーダとを備える。エンコーダは、ビデオをよりコンパクトな形態で（すなわち、より低いビットレートで）表現するために、元のビデオシーケンスの情報の一部を切り捨ててもよい。画像コーデックまたはピクチャコーデックはビデオコーデックと同様であるが、入力されたピクチャを他の入力ピクチャから独立して符号化し、符号化されたそれぞれのピクチャを他の符号化ピクチャから独立して復号する。以下においてビデオコーデック、ビデオ符号化やエンコーダ、またはビデオデコーダや復号のいずれに言及されている場合であっても、画像コーデック、画像符号化やエンコーダ、または画像デコーダや復号のそれぞれに対して同様に説明が当てはまることを理解されたい。

エンコーダへの入力として与えられたピクチャはソースピクチャとも呼ばれ、デコーダによって復号されたピクチャは復号ピクチャとも呼ばれる。ソースピクチャおよび復号ピクチャは、それぞれ以下のサンプル配列のセットのいずれかのような、１つ以上のサンプル配列からなっている。
・ 輝度（Luma）（Ｙ）のみ（モノクロ）
・ 輝度および２つのクロマ（ＹＣｂＣｒまたはＹＣｇＣｏ）
・ 緑、青、赤（ＧＢＲまたはＲＧＢ）
・ その他の非特定モノクロまたは三刺激色サンプリングを示す配列（例えば、ＹＺＸ、またはＸＹＺ）

「画素」という用語は、色成分のサンプル配列の、空間的に結びついたサンプル群を表すものであってもよい。内容によっては、「画素」という用語は１つのサンプル配列のみのサンプルを表すものであってもよい。

以下では、これらの配列は、実際に使用されている色表現方法に関わらず、輝度（ＬまたはＹ）およびクロマと呼ばれ、２つのクロマ配列はＣｂおよびＣｒとも呼ばれてもよい。実際に使用されている色表現方法は、例えば符号化されたビデオビットストリームにおいて示すことができる。ある成分が、３つのサンプル配列（輝度および２つのクロマ）の内の１つから配列または単一のサンプルとして定義されるか、モノクロフォーマットのピクチャを構成する配列または配列の単一のサンプルとして定義されてもよい。

一部の符号化システムではピクチャはフレームまたはフィールドのいずれであってもよく、別の符号化システムではピクチャはフレームに限定されていてもよい。フレームは、輝度サンプルと場合により対応するクロマサンプルの行列を含む。フィールドは、フレームの１つおきのサンプルの行の組であり、ソース信号がインターレースされている場合、エンコーダ入力として用いられてもよい。

クロマサンプル配列はなくてもよく（よって、モノクロサンプリングが使用される）、または輝度サンプル配列と比較されるときにサブサンプリングされてもよい。クロマフォーマットは、以下のようにまとめられる。
・ モノクロサンプリングでは、サンプル配列が１つのみ存在し、名目上輝度配列とみなされる。
・ ４：２：０サンプリングでは、２つのクロマ配列のそれぞれが輝度配列の半分の高さと半分の幅を有する。
・ ４：２：２サンプリングでは、２つのクロマ配列のそれぞれが輝度配列と同じ高さと半分の幅を有する。
・ ４：４：４サンプリングでは、別個の色平面が使用されない場合、２つのクロマ配列のそれぞれが輝度配列と同じ高さと幅を有する。

ピクチャの空間解像度は、水平および垂直方向において当該ピクチャを表す画素数またはサンプル数として定義されてもよい。あるいは、内容によっては、第１のピクチャと第２のピクチャとでサンプリンググリッドが同じ、すなわち、サンプリング間隔が同じであれば、第１のピクチャの空間解像度は、第２のピクチャの空間解像度と同じと定義されてもよい。後者の定義は、例えば、第１のピクチャと第２のピクチャとが、それぞれピクチャの別部位に対応する場合に適用されてもよい。例えば、第１の数の画素またはサンプルを有するピクチャの領域である第１の領域は、第１の解像度を有すると定義されてもよい。同領域は、第２の数の画素を有する場合、第２の解像度を有すると定義されてもよい。したがって、解像度は画素が含まれる領域における、当該画素の数、または単位角あたりの画素数として定義できる。

符号化構成によっては、輝度およびクロマサンプル配列は、インターリーブ方式で、例えばブロック単位でインターリーブされて符号化される。符号化構成によっては、サンプル配列を別個の色平面としてビットストリームに符号化し、そのビットストリームから別個に符号化された色平面をそれぞれ復号することができる。別個の色平面が使用される場合、そのそれぞれは（エンコーダおよび／またはデコーダによって）モノクロサンプリングのピクチャとして別々に処理される。

ビデオエンコーダは、ビデオ情報を２段階で符号化してもよい。
・ 第１段階で、特定のピクチャエリア（または「ブロック」）の画素値が予測される。この予測を例えば動き補償手段（符号化されるブロックと密接に対応する、先に符号化済みのビデオフレームの１つにあるエリアを探して示す手段）によって実施してもよく、これはインター予測またはインターピクチャ予測と称される。これに代えて、またはこれに加えて、予測を例えば空間手段（特定の方法で符号化されるブロックの周辺の画素値を用いる手段）によって実施してもよく、これはイントラ予測または空間予測と称される。符号化構成によっては、予測がなくても、予測信号があらかじめ定義されてもよい（例えば、ゼロ価ブロック）。
・ 第２段階で、予測誤差、すなわち画素の予測ブロックとその画素の元のブロックとの間の差分が符号化される。これは例えば、特定の変換（例えば、離散コサイン変換（Discrete Cosine Transform：ＤＣＴ）やその変形）を用いて画素値の差分を変換し、係数を量子化し、量子化済み係数をエントロピー符号化することによって行われる。量子化処理の忠実度は、多くのコーデックにおいて、いわゆる量子化パラメータ（Quantization Parameter：ＱＰ）により制御される、量子化ステップのサイズで制御できる。量子化処理の忠実度を変えることによって、エンコーダは画素表現の正確性（画質）と結果として得られる符号化ビデオ表現のサイズ（ファイルサイズまたは伝送ビットレート）との間のバランスを調整することができる。別の例では、画素値は、例えば、ハフマン符号化や算術符号化等の差分パルス符号変調とエントロピー符号化を用いて変換せずに符号化される。

符号化処理の例が図４に示されている。図４は、符号化される画像（Ｉ_ｎ）、画像ブロックの予測された表現（Ｐ'_ｎ）、予測誤差信号（Ｄ_ｎ）、再構成予測誤差信号（Ｄ'_ｎ）、予備再構成画像（Ｉ'_ｎ）、最終再構成画像（Ｒ'_ｎ）、変換（Ｔ）および逆変換（Ｔ^−１）、量子化（Ｑ）および逆量子化（Ｑ^−１）、エントロピー符号化（Ｅ）、参照フレームメモリ（ＲＦＭ）、インター予測（Ｐ_{ｉｎｔｅｒ}）、イントラ予測（Ｐ_{ｉｎｔｒａ}）、モード選択（ＭＳ）、およびフィルタリング（Ｆ）を示す。復号処理の例が図５に図示されている。図５は、画像ブロックの予測された表現（Ｐ'_ｎ）、再構成予測誤差信号（Ｄ'_ｎ）、予備再構成画像（Ｉ'_ｎ）、最終再構成画像（Ｒ'_ｎ）、逆変換（Ｔ^−１）、逆量子化（Ｑ^−１）、エントロピー復号（Ｅ^−１）、参照フレームメモリ（ＲＦＭ）、予測（インター予測またはイントラ予測）（Ｐ）、およびフィルタリング（Ｆ）を示す。

スケーラブルビデオ符号化とは、１つのビットストリームが、例えばビットレート、解像度、またはフレームレートが異なる、複数の表現のコンテンツを格納できるような符号化構造を指してもよい。このような場合、受信機は、その特性（例えば、ディスプレイ装置に最適な解像度）に応じて望ましい表現を抽出することができる。あるいは、サーバまたはネットワーク要素がビットストリームの一部を抽出し、例えばネットワーク特性や受信機の処理能力に応じて受信機に送信されるようにすることもできる。スケーラブルビットストリームの特定の部分のみを復号することにより、有意な復号表現を生成することができる。スケーラブルビットストリームは、一般的には、利用可能な最低品質動画を提供する１層の「基本レイヤ」と、下位レイヤと共に受信、復号されるとビデオ品質を高める１つ以上の「拡張レイヤ」から構成される。拡張レイヤに対する符号化効率を高めるために、レイヤの符号化表現は、一般に下位レイヤに依存する。例えば、拡張レイヤの動き情報およびモード情報が下位レイヤから予測されてもよい。同様に、拡張レイヤ予測を作成するために、下位レイヤの画素データを用いることもできる。

スケーラブルビデオ符号化方式によっては、ビデオ信号は基本レイヤおよび１つ以上の拡張レイヤに符号化されてもよい。拡張レイヤは、例えば、時間分解能（すなわち、フレームレート）や空間分解能を上げたり、あるいは別のレイヤやその一部によって表されるビデオコンテンツの品質を上げたりするだけでもよい。各レイヤは、そのすべての従属レイヤと合わせて、例えば、特定の空間分解能、時間分解能および品質レベルでのビデオ信号の一表現である。本明細書では、そのすべての従属レイヤと合わせたスケーラブルレイヤを「スケーラブルレイヤ表現」と呼ぶ。特定の忠実度で元の信号表現を生成するために、スケーラブルレイヤ表現に対応するスケーラブルビットストリームの一部が抽出され復号される。

「レイヤ」という語は、ビュースケーラビリティや深度拡張等、任意の種類のスケーラビリティの文脈において使用することができる。拡張レイヤは、ＳＮＲ拡張、空間拡張、マルチビュー拡張、深度拡張、ビット深度拡張、クロマフォーマット拡張、および／または色域拡張等の任意の種類の拡張を指してもよい。基本レイヤは、ベースビュー、ＳＮＲ／空間スケーラビリティの基本レイヤ、または深度が拡張されたビデオの符号化に対するテクスチャベースビュー等の任意の種類のベースビデオシーケンスを指してもよい。

現在、三次元（３Ｄ）ビデオコンテンツを提供するための各種技術が、調査、研究、開発されている。立体視または２ビュービデオにおいて、１つのビデオシーケンスまたはビューは左眼用、平行ビューは右眼用にしてもよい。

ビューは、１つのカメラまたは視点を表すピクチャのシーケンスとして定義することができる。ビューを表すピクチャは、ビュー成分とも呼ばれる。換言すれば、ビュー成分は単一のアクセス単位におけるビューの符号化された表現として定義することができる。マルチビュービデオの符号化では、ビットストリームにおいて２つ以上のビューが符号化される。複数のビューは通常、立体視用ディスプレイやマルチビュー裸眼立体視ディスプレイに表示されること、またはその他の３Ｄ構成に使用されることを目的としていることから、通常は同一のシーンを表し、コンテンツによっては異なる視点を表しながら部分的に重畳する。このように、マルチビュービデオの符号化にインタービュー予測を用いることによって、ビュー間の相関関係を活用し圧縮効率を向上させてもよい。インタービュー予測を実現する方法としては、第１のビュー中の符号化または復号されているピクチャの参照ピクチャリストに１つ以上のその他のビューの１つ以上の復号ピクチャを含めることが挙げられる。ビュースケーラビリティはこのようなマルチビュービデオの符号化またはマルチビュービデオのビットストリームを指してもよく、これらによって１つ以上の符号化されたビューを削除または省略することができ、その結果としてのビットストリームは適合性を保ちながら、元のものよりも少ない数のビューでビデオを表す。

Ｈ．２６４／ＡＶＣ規格（ＡＶＣまたはＨ．２６４／ＡＶＣと略称される場合もある）は、ＩＴＵ−Ｔ（国際電気通信連合の電気通信標準化部門）のビデオの符号化専門家グループ（ＶＣＥＧ）およびＩＳＯ（国際標準化機構）／ＩＥＣ（国際電気標準会議）の動画専門家グループ（ＭＰＥＧ）による統合ビデオチーム（ＪＶＴ）によって開発された。Ｈ．２６４／ＡＶＣ規格は、その元となる両標準化機構によって公開されており、ＩＴＵ−Ｔ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６−１０と呼ばれ、ＭＰＥＧ−４パート１０高度ビデオ符号化方式（Advanced Video Coding：ＡＶＣ）としても知られている。Ｈ．２６４／ＡＶＣ規格には複数のバージョンがあり、それぞれが仕様に新たな拡張や特徴を統合している。これらの拡張には、スケーラブルビデオ符号化（Scalable Video Coding：ＳＶＣ）やマルチビュービデオ符号化（Multiview Video Coding：ＭＶＣ）が挙げられる。

高効率ビデオ符号化（High Efficiency Video Coding）規格（ＨＥＶＣまたはＨ．２６５／ＨＥＶＣとも略してもよい）は、ＶＣＥＧとＭＰＥＧのビデオの符号化共同研究開発チーム（ＪＣＴ−ＶＣ）によって開発された。この規格は、その元となる両標準化機構によって公開されており、ＩＴＵ−Ｔ勧告Ｈ．２６５およびＩＳＯ／ＩＥＣ国際規格２３００８−２と呼ばれ、ＭＰＥＧ−Ｈパート２高効率ビデオ符号化として知られている。Ｈ．２６５／ＨＥＶＣのバージョン２は、スケーラブル拡張、マルチビュー拡張、および忠実度範囲拡張を含み、それぞれＳＨＶＣ、ＭＶ−ＨＥＶＣ、およびＲＥＸＴと略称される。本明細書におけるＨ．２６５／ＨＥＶＣ、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、ＲＥＸＴについての記載は、特に別途記載がない限り、本発明の出願日の時点で利用可能な、これら規格の最新バージョンについて言及されているもの理解されたい。

ここでは、Ｈ．２６４／ＡＶＣおよびＨＥＶＣの重要な定義やビットストリーム、符号化の構造、概念の一部が、実施形態を実施可能なビデオエンコーダやデコーダ、符号化方法、復号方法、ビットストリーム構造の例として説明される。Ｈ．２６４／ＡＶＣの重要な定義やビットストリーム、符号化の構造、概念の中にはＨＥＶＣにおける規格と同一のものもある。したがって、以下ではこれらも一緒に説明される。本発明の態様は、Ｈ．２６４／ＡＶＣやＨＥＶＣに限定されるものではなく、本明細書は本発明が部分的にまたは全体として実現される上で可能な原理を説明するためのものである

Ｈ．２６４／ＡＶＣまたはＨＥＶＣのエンコーダからの出力およびＨ．２６４／ＡＶＣまたはＨＥＶＣのデコーダへの入力のための基本単位はそれぞれ、ネットワーク抽象化層（Network Abstraction Layer：ＮＡＬ）単位である。パケット指向ネットワークでの伝送や構造化ファイルへの格納に対して、ＮＡＬ単位はパケットや同様の構造にカプセル化されてもよい。

ＮＡＬ単位は、後続データの種類のインジケータを含むシンタックス構造と、未加工バイトシーケンスペイロード（ＲＢＳＰ）の形態で必要に応じてエミュレーション防止バイトを散在させたデータを含む複数のバイトとして定義することができる。ＲＢＳＰは、ＮＡＬ単位にカプセル化される整数のバイトを含むシンタックス構造として定義することができる。ＲＢＳＰは空であるか、ＲＢＳＰストップビットおよび０に等しい後続のビットが０個以上続くシンタックス要素を含むデータビット列の形態を持つかのいずれかである。

ＮＡＬ単位は、ビデオ符号化レイヤ（ＶＣＬ）ＮＡＬ単位と非ＶＣＬ−ＮＡＬ単位とに分類することができる。ＶＣＬ ＮＡＬ単位は、符号化サンプルデータを含む。非ＶＣＬ−ＮＡＬ単位は、例えば、シーケンスパラメータセット、ピクチャパラメータセット、補助拡張情報（Supplemental Enhancement Information：ＳＥＩ）ＮＡＬ単位、アクセス単位区切り、シーケンスＮＡＬ単位の一端、ビットストリームＮＡＬ単位の一端、または補充データＮＡＬ単位のいずれかの種類であってもよい。パラメータセットは復号ピクチャの再構成に必要であってもよいが、他の非ＶＣＬ−ＮＡＬ単位の多くは、復号サンプル値の再構成には必要ない。

符号化ビデオシーケンスで不変のパラメータがシーケンスパラメータセットに含まれてもよい。復号処理に必要なパラメータに加え、シーケンスパラメータセットがビデオユーザビリティ情報（Video Usability Information：ＶＵＩ）を任意で含んでもよい。これは、バッファリングやピクチャ出力タイミング、レンダリング、およびリソース予約に重要なパラメータを含む。ＨＥＶＣでは、シーケンスパラメータセットＲＢＳＰには、１つ以上のピクチャパラメータセットＲＢＳＰ、またはバッファリング期間ＳＥＩメッセージを含む１つ以上のＳＥＩ−ＮＡＬ単位によって参照可能なパラメータが含まれる。ピクチャパラメータセットは、複数の符号化ピクチャで不変であるようなパラメータを含む。ピクチャパラメータセットＲＢＳＰは、１つ以上の符号化ピクチャのＶＣＬ−ＮＡＬ単位によって参照可能なパラメータを含んでもよい。

ＳＥＩ−ＮＡＬ単位は１つ以上のＳＥＩメッセージを含んでもよい。これらは出力ピクチャの復号には必要ないが、ピクチャ出力タイミング、レンダリング、エラー検出、エラー隠蔽、リソース予約等の関連処理を補助してもよい。複数のＳＥＩメッセージがＨ．２６４／ＡＶＣおよびＨＥＶＣで規定され、ユーザデータのＳＥＩメッセージによって組織や企業が独自に使用するＳＥＩメッセージを規定できる。Ｈ．２６４／ＡＶＣおよびＨＥＶＣは、規定されたＳＥＩメッセージのシンタックスとセマンティックを含むが、受信側でメッセージを取り扱う処理については何も定義されない。その結果、エンコーダはＳＥＩメッセージを作成する際、Ｈ．２６４／ＡＶＣ規格やＨＥＶＣ規格に従い、デコーダもそれぞれＨ．２６４／ＡＶＣ規格やＨＥＶＣ規格に準拠する必要があるが、ＳＥＩメッセージを出力順規定に準じて処理する必要はない。Ｈ．２６４／ＡＶＣおよびＨＥＶＣでＳＥＩメッセージのシンタックスとセマンティックを含める理由の１つは、異なるシステム仕様でも補助情報を同じ様に解釈し相互運用を可能にすることである。システム仕様は符号化側と復号側の両方で特定のＳＥＩメッセージを使用できるように要求するものであり、受信側で特定のＳＥＩメッセージを取り扱う処理も規定されてもよい。

ＨＥＶＣでは、２種類のＳＥＩ−ＮＡＬ単位、すなわち、互いに異なるnal_unit_type値を有する接尾ＳＥＩ−ＮＡＬ単位と接頭ＳＥＩ−ＮＡＬ単位がある。接尾ＳＥＩ−ＮＡＬ単位に含まれるＳＥＩメッセージは、復号順で接尾ＳＥＩ−ＮＡＬ単位の前に置かれるＶＣＬ−ＮＡＬ単位に関連付けられる。接頭ＳＥＩ−ＮＡＬ単位に含まれるＳＥＩメッセージは、復号順で接頭ＳＥＩ−ＮＡＬ単位の後に置かれるＶＣＬ−ＮＡＬ単位に関連付けられる。

入手可能なメディアファイルフォーマット規格には、ＩＳＯによるメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２、「ＩＳＯＢＭＦＦ」と略称される場合もある）、ＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１４、「ＭＰ４フォーマット」とも呼ばれる）、ＮＡＬ単位構造化ビデオ用のファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）、および３ＧＰＰファイルフォーマット（３ＧＰＰ ＴＳ ２６．２４４、「３ＧＰフォーマット」とも呼ばれる）が挙げられる。上述のファイルフォーマット（ＩＳＯＢＭＦＦそのものは除く）は、ＩＳＯＢＭＦＦから派生したものである。

ＩＳＯＢＭＦＦについての概念、構造、仕様が以下に、実施形態実現の基となりうるコンテナファイルフォーマットの例として記載される。本発明の態様はＩＳＯＢＭＦＦに限定されるものではなく、本明細書は本発明が部分的にまたは全体として実現される上で可能な原理を説明するためのものである。

ＩＳＯによるメディアファイルフォーマットにおける基本的要素をボックスと称する。各ボックスはヘッダとペイロードとを有する。ボックスヘッダは、ボックスの種類と、バイト単位のボックスのサイズとを示す。あるボックスは別のボックスを中に含んでもよく、ＩＳＯファイルフォーマットは、特定の種類のボックス内に含むことができるボックスの種類を指定する。さらに、各ファイルにおいていくつかのボックスが存在することが必須条件で、その他ボックスが任意で存在するようにしてもよい。また、ボックス種類によっては、ファイル内に複数のボックスが含まれるようにしてもよい。このように、ＩＳＯによるメディアファイルフォーマットはボックスの階層構造を指定するものとも考えられる。

ファイルフォーマットのＩＳＯファミリーによると、ファイルはボックスにカプセル化されるメディアデータとメタデータとを含む。各ボックスは、４文字コード（４ＣＣ）により識別され、当該ボックスの種類とサイズを示すヘッダから始まる。

ＩＳＯによるメディアファイルフォーマットに対応するファイルにおいて、メディアデータは、「mdat」（メディアデータ）ボックス内に設けられてもよく、「moov」（動画）ボックスを使用してメタデータを中に含んでもよい。場合によっては、ファイルが動作可能になるのは、「mdat」ボックスと「moov」ボックスとの両方の存在が必要となりうる。「moov」（動画）ボックスは１つ以上のトラックを含んでもよく、各トラックは、対応する１つの「trak」（トラック）ボックスに存在してもよい。トラックは、メディア圧縮フォーマット（ならびにそのＩＳＯによるメディアファイルフォーマットへのカプセル化）に応じてフォーマット化されたサンプルについてのメディアトラックを含む、数多くの種類の内の１つであってもよい。トラックは論理経路と称してもよい。ビデオトラックの場合、メディアサンプルは符号化ピクチャまたはアクセス単位に対応してもよい。

「trak」ボックスは、そのボックスの階層において、使用される符号化の種類についての詳細な情報を示すサンプル説明（SampleDescription）ボックスと、当該符号化に必要な任意の初期化情報とを含む。サンプル説明ボックスは、エントリカウントと、当該エントリカウントが示すのと同数のサンプルエントリを含む。サンプルエントリのフォーマットは、トラック種類固有であるが、一般的なクラス（例えばVisualSampleEntry、AudioSampleEntry）に基づくものである。トラック種類固有のサンプルエントリフォーマットが基づくサンプルエントリの種類は、トラックのメディアハンドラにより決定される。

例えば、記録アプリケーションがクラッシュする、メモリ空間が不足する、またはその他の事態が起きてデータ喪失が生じないよう、動画のフラグメントを使用してコンテンツをＩＳＯファイルに記録してもよい。動画のフラグメントを使用しなければ、例えば、動画ボックスのようなメタデータ全体が、ファイルの１つの連続した領域に書き込まれる必要があるファイルフォーマットとなるため、データ喪失が生じうる。さらに、ファイルを記録する際に、利用可能な記憶容量に対して、動画ボックスをバッファするのにメモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））空間が不足する可能性があり、動画を閉じた際に動画ボックスのコンテンツを再計算するのに時間がかかりすぎる可能性がある。さらに、動画フラグメントは、ファイルを通常のＩＳＯファイルパーサを使用してファイルの同時記録および再生を可能としうる。さらに、動画フラグメントが使用され、初期動画ボックスが、メディアコンテンツが同じで動画フラグメントなしで構成されたファイルに対して小さい場合には、例えばファイルの受信、再生を同時に行うような、プログレッシブダウンロードに対しては、初期バッファリングの期間を短くする必要がありうる。

動画フラグメントの特徴により、動画ボックス内に存在するはずであったメタデータを多数のデータに分割可能としうる。各データは、トラックの所定期間に対応する。すなわち、動画フラグメントの特徴は、ファイルのメタデータとメディアデータとをインターリーブ可能としうる。その結果、動画ボックスのサイズを限定でき、上述の使用状況を実現できる。

いくつかの例では、動画フラグメントのメディアサンプルはmdatボックス内に存在してもよい。一方で、動画フラグメントのメタデータについては、moofボックスが設けられてもよい。moofボックスは、moovボックス内に存在していた、所定期間の再生時間についての情報を含んでもよい。moovボックスそのものでも有効な動画を示すこともできるが、それに加えて同ファイル内に、動画フラグメントが続くことを示すmvexボックスが含まれてもよい。動画フラグメントは、moovボックスに時間的に関連付けられた表現を拡張しうる。

動画フラグメント内には、トラックごとに０から複数フラグメントとなるように、一連のトラックフラグメントが存在してもよい。さらにトラックフラグメントは、０から複数のトラックランを含んでもよい。各ランの文書は、そのトラックに対するサンプルの連続ランである（したがって、ひとまとまりのものとして扱える）。これらの構造においては、多くのフィールドは任意であって、初期設定可能である。moofボックスに含まれうるメタデータは、moovボックス内に含まれうるメタデータのサブセットに限定でき、場合によっては互いに異なる符号化が可能である。moofボックス内に含まれうるボックスについての詳細は、ＩＳＯＢＭＦＦ仕様で確認可能である。自立型動画フラグメントは、ファイル順で連続するmoofボックスとmdatボックスとからなり、mdatボックスが動画フラグメントのサンプル（moofボックスによりメタデータが提供される）を含むが、その他動画フラグメントのサンプルを（すなわち、その他いかなるmoofボックスも）含まないものと定義されうる。

メディアセグメントは、１つ以上の自立型動画フラグメントを含んでもよい。例えばＭＰＥＧ−ＤＡＳＨによるストリーミングのような配信に、メディアセグメントが使用されてもよい。

ＩＳＯによるメディアファイルフォーマットは、特定のサンプルに関連付けることができる時限式メタデータに対して３つの機構を含みうる。すなわち、サンプルグループ、時限式メタデータトラック、サンプル補助情報である。導出される仕様は、これら３つの機構の内の１つ以上のものと同様の機能を提供してもよい。

ＩＳＯによるメディアファイルフォーマットとその派生物（ＡＶＣファイルフォーマットおよびＳＶＣファイルフォーマット等）において、サンプルグループ化は、グループ化基準を基に、トラックにおける各サンプルを１つのサンプルグループに属するように割り当てることと定義されてもよい。サンプルグループ化におけるサンプルグループは、連続的なものに限られない。すなわち、連続しないサンプルが含まれてもよい。トラックにおけるサンプルのサンプルグループ化が複数存在しうるため、各サンプルグループ化はグループ化の種類を示す種類フィールドを有しうる。サンプルグループ化は２つのリンクされたデータ構造により示されてもよい。すなわち、（１）SampleToGroupBox（sbgpボックス）は、サンプルグループに対するサンプルの割当てを示し、（２）SampleGroupDescriptionBox（sgpdボックス）は、グループの性質を示す、各サンプルグループのサンプルグループエントリを含む。SampleToGroupBoxとSampleGroupDescriptionBoxについては、異なるグループ化基準に基づく複数のインスタンスがありうる。これらは、グループ化の種類を示すための種類フィールドにより区別されうる。SampleToGroupBoxは、例えばグループ化のサブタイプを示すために使用されうるgrouping_type_parameterフィールドを含んでもよい。

ビデオストリーミング用途等の、インターネットを介して多数のメディアコンテンツをリアルタイムで配信するために、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）が広く用いられている。ＨＴＴＰによるアダプティブストリーミングのため、いくつかの商用方式（Ｍｉｃｒｏｓｏｆｔ（登録商標）スムースストリーミング、Ａｐｐｌｅ（登録商標）アダプティブＨＴＴＰライブストリーミング、Ａｄｏｂｅ（登録商標）ダイナミックストリーミング等）が展開されており、標準化プロジェクトも進行している。アダプティブＨＴＴＰストリーミング（ＡＨＳ）は、3rd Generation Partnership Project（３ＧＰＰ）パケット交換ストリーミング（ＰＳＳ）サービスのリリース９（３ＧＰＰ ＴＳ ２６．２３４ リリース９：「Transparent end-to-end packet-switched streaming service (PSS); protocols and codecs（トランスペアレントエンドツーエンドパケット交換ストリーミングサービス（ＰＳＳ）；プロトコルおよびコーデック）」）において最初に標準化された。ＭＰＥＧは、３ＧＰＰ ＡＨＳリリース９を開始点としてＭＰＥＧ ＤＡＳＨ標準（ＩＳＯ／ＩＥＣ ２３００９−１：「Dynamic adaptive streaming over HTTP (DASH)-Part 1: Media presentation description and segment formats（ダイナミックアダプティブストリーミング・オーバーＨＴＴＰ（ＤＡＳＨ）第１部：メディアプレゼンテーション記述およびセグメントフォーマット）」、国際標準、第２版、２０１４年）を規定している。ＭＰＥＧ ＤＡＳＨおよび３ＧＰＰ−ＤＡＳＨは技術的に似通っており、これらをまとめてＤＡＳＨと称される場合がある。

ＤＡＳＨにおいて、マルチメディアコンテンツはＨＴＴＰサーバに記憶されて、ＨＴＴＰにより配信されてもよい。コンテンツは２つの部分に分けてサーバに記憶されてもよい、すなわち、メディアプレゼンテーション記述（Media Presentation Description：ＭＰＤ）と単一または複数のファイルにおけるセグメントである。ＭＰＤは、利用可能なコンテンツとその各種変形、そのＵＲＬアドレス、その他特徴のマニフェストを示す。セグメントは、実際のマルチメディアビットストリームをチャンクとして含む。ＭＰＤは、クライアントにＨＴＴＰによるダイナミックアダプティブストリーミングを構築するために必要な情報を提供する。ＭＰＤは、ＧＥＴセグメントリクエストを生成するための、各セグメントのＨＴＴＰ−ＵＲＬのようなメディアプレゼンテーション表す情報を含む。コンテンツ再生のために、ＤＡＳＨクライアントは例えばＨＴＴＰ、ｅメール、サムドライブ、ブロードキャスト、またはその他の送信方法により、ＭＰＤを取得してもよい。ＭＰＤを解析することで、ＤＡＳＨクライアントは、プログラムタイミング、メディアコンテンツ可用性、メディア種類、解像度、最小および最大メディア帯域幅、マルチメディア要素の各種符号化選択肢の存在、アクセシビリティ機能と必要なデジタル権利管理（Digital Rights Management：ＤＲＭ）、ネットワーク上のメディア要素の場所、およびその他コンテンツの特徴について把握可能となりうる。この情報を使用して、ＤＡＳＨクライアントは適切な符号化選択肢を選択し、例えばＨＴＴＰ ＧＥＴリクエストを使用して、セグメントを取得することで、コンテンツのストリーミングを開始してもよい。ネットワークスループットの変動を考慮して適切なバッファリングを行った後、クライアントは継続して以降のセグメントを取得し、ネットワーク帯域幅の変動も監視可能である。クライアントは、適切なバッファを維持するために、（より低いまたはより高いビットレートの）異なる選択肢のセグメントを取得することによって、利用可能な帯域幅に対応する方法を決定することができる。

ＤＡＳＨでは、以下の定義を使用することができる。メディアコンテンツ要素またはメディア要素は、メディアストリームに個別に符号化することができる、割り当てられたメディア要素の種類を有するメディアコンテンツの１つの連続した要素として定義することができる。メディアコンテンツは、１つのメディアコンテンツ期間または連続する一連のメディアコンテンツ期間と定義できる。メディアコンテンツ要素の種類は、音声、動画、またはテキスト等の単一の種類のメディアコンテンツとして定義することができる。メディアストリームは、メディアコンテンツ要素が符号化されたものとして定義することができる。

ＤＡＳＨでは、階層データモデルを使用して、以下のようにメディアプレゼンテーションを構成する。メディアプレゼンテーションは、１つまたは複数の期間のシーケンスからなる。各期間は１つまたは複数のグループを含む。各グループは１つ以上の適応セットを含む。各適応セットは、１つまたは複数の表現を含む。各表現は、１つまたは複数のセグメントからなる。グループは、同時に提示されることが想定されない複数の適応セットの集合として定義されてもよい。適応セットは、１つまたは複数のメディアコンテンツ要素が交換可能な一連の符号化されたものとして定義されてもよい。表現は、メディアコンテンツまたはそのサブセットの選択肢の１つであり、典型的には符号化における、ビットレート、解像度、言語、コーデック等の選択により異なるものである。セグメントは、メディアデータの特定の期間と、含まれているメディアコンテンツを復号して提示するためのメタデータを含む。セグメントはＵＲＩにより識別され、典型的にはＨＴＴＰ ＧＥＴリクエストにより、要求可能である。セグメントは、ＨＴＴＰ−ＵＲＬに関連するデータの単位と、任意でＭＰＤによって指定されるバイト範囲として定義することができる。

ＤＡＳＨ ＭＰＤはＸＭＬ（Extensible Markup Language）に準拠しているため、ＸＭＬで定義されている要素と属性によって指定される。ＭＰＤは、以下のとおりに指定可能である。すなわち、ＸＭＬ文書内の要素は、大文字の最初の文字で識別され、要素として太字で表示される。ある要素Element1が別の要素Element2に含まれていることを表すために、Element2.Element1と記載できる。要素の名前が２つ以上の結合語で構成されている場合、キャメルケースを使用してもよく、例えばImportantElementのように記載できる。要素が一度のみ提示されてもよく、または最小および最大発生は<minOccurs> ... <maxOccurs>によって定義されてもよい。ＸＭＬ文書における属性は、小文字の最初の文字で識別可能である。また、先頭に「@」記号を付して、例えば@attributeのようにしてもよい。要素Elementに含まれる特定の属性@attributeを指すために、Element@attributeと記載できる。属性の名前が2つ以上の結合語で構成されている場合、最初の単語の後にキャメルケースを使用し、@veryImportantAttributeのように記載してもよい。属性は、必須（Ｍ）、任意（Ｏ）、デフォルト値で任意（ＯＤ）、および条件付き必須（ＣＭ）のようにＸＭＬのステータスを割り当てられてもよい。

ＤＡＳＨでは、すべての記述子要素は同様に構造化される。すなわち、@schemeIdUri属性を含み、スキームを識別するＵＲＩとオプションの属性@valueと任意の属性@idを提供する。要素のセマンティックは使用されるスキームに固有である。スキームを識別するＵＲＩは、ＵＲＮまたはＵＲＬであってもよい。いくつかの記述子はＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ ２３００９−１）で規定されているが、さらに／あるいは記述子を他の仕様で規定することもできる。ＭＰＥＧ−ＤＡＳＨ以外の仕様で規定された場合、ＭＰＤは記述子要素の使用方法に関する特定の情報を提供しない。適切なスキーム情報による記述要素のインスタンス化は、ＤＡＳＨフォーマットを採用するアプリケーションまたは仕様に依存する。これらの要素の１つを使用するアプリケーションまたは仕様では、ＵＲＩの形式でScheme Identifierを定義し、当該Scheme Identifierが使用される場合の要素の値空間を定義する。Scheme Identifierは@schemeIdUri属性に表示される。単純な列挙値群が必要な場合は、各値に対してテキスト文字列を定義し、この文字列を@value属性に含めてもよい。構造化データが必要な場合は、任意の拡張要素または属性を別の名前空間に定義してもよい。@id値は、固有の記述子または記述子群を参照するために使用可能できる。記述子群の場合、属性@idと同一の値を持つ記述子は同義である必要がありえる。すなわち、@idの値が同じ記述子の１つに対する処理のみでよい。DescriptorTypeの２つの要素は、要素名、@schemeIdUriの値、および@value属性の値が等しい場合、同値となる。@schemeIdUriがＵＲＮの場合、同値とはＲＦＣ ２１４１の第５節で定義されるように、字句同値を指しうる。@schemeIdUriがＵＲＬの場合、同値とはＲＦＣ３９８６の６．２．１節で定義されているように、文字単位の同値を指しうる。@value属性が存在しない場合、同値は@schemeIdUriの同値によってのみ決定される。拡張名前空間の属性と要素は同値判定に無関係となりうる。同値判定の際に、@id属性を考慮しなくてもよい。

ＭＰＥＧ−ＤＡＳＨは、記述子EssentialPropertyおよびSupplementalPropertyを指定する。要素EssentialPropertyについて、メディアプレゼンテーションの著者は、要素が別のEssentialProperty要素と同じ@idを共有しない限り、記述子を処理しなければ当該記述子を含む親要素の情報を適切に使用できないと記している。複数のEssentialProperty要素が同じ@idを共有する場合、EssentialProperty要素の１つを、当該@idに対する同じ値で処理すればよい。個別の@id値の少なくとも1つのEssentialProperty要素が処理されることが期待される。スキームまたはEssentialProperty記述子の値が認識されない場合、ＤＡＳＨクライアントは記述子を含む親要素を無視するものと考えられる。ＭＰＤは、@idが互いに同じまたは異なる複数のEssentialProperty要素を含みうる。

要素SupplementalPropertyの場合、メディアプレゼンテーションの著者は、記述子が最適化処理のため、ＤＡＳＨクライアントによって使用される補足情報を含むことを記している。スキームまたはSupplementalProperty記述子の値が認識されない場合、ＤＡＳＨクライアントは記述子を無視するものと考えられる。ＭＰＤは複数のSupplementalProperty要素を含みうる。

ＭＰＥＧ−ＤＡＳＨは、ＩＳＯＢＭＦＦおよびＭＰＥＧ−２トランスポートストリームの両方のセグメントコンテナフォーマットを定義する。他の仕様により、他のコンテナフォーマットに基づくセグメントフォーマットを指定することができる。例えば、Ｍａｔｒｏｓｋａコンテナファイルフォーマットに基づくセグメントフォーマットが提案されている。以下に概略を述べる。ＭａｔｒｏｓｋａファイルがＤＡＳＨセグメント等として伝送される場合、ＤＡＳＨユニットとＭａｔｒｏｓｋａユニットとは、以下のように関連付けられる。（ＤＡＳＨの）サブセグメントは、１つ以上の連続したカプセル化されたＭａｔｒｏｓｋａコンテンツのクラスタとして定義されてもよい。ＤＡＳＨの初期化セグメントは、ＥＢＭＬヘッダ、（Ｍａｔｒｏｓｋａの）セグメントヘッダ、（Ｍａｔｒｏｓｋａの）セグメント情報およびトラックを含むことが必須とされ、任意で他のレベル１要素およびパディングを含むことができる。ＤＡＳＨのセグメントインデックスは、Ｍａｔｒｏｓｋａのキュー要素を含むことができる。

ＤＡＳＨは、様々に変更するネットワーク帯域幅に一致するよう、適応セット内の複数の異なる表現からメディアセグメントを動的に要求することで、速度適応に対応する。ＤＡＳＨクライアントが表現を上下に切り替える場合、表現内のコーディング依存関係を考慮する必要がある。表現切替えは、Ｈ．２６４／ＡＶＣ等のビデオ符号化技術で通常使用されるランダムアクセスポイント（ＲＡＰ）で発生しうる。ＤＡＳＨでは、ストリームアクセスポイント（ＳＡＰ）と呼ばれる一般的概念を導入している。これは、表現にアクセスして複数の表現間で切替えを実行するコーデックに依存しないソリューションである。ＤＡＳＨでは、ＳＡＰは表現の位置として指定され、メディアストリームの再生は、当該位置から開始する表現データに含まれる情報のみを使用して開始できる（初期化セグメント内に初期化データがあればそれが先行する）。これにより、ＳＡＰで表示の切替えを実行できる。

図６は、エンドツーエンドのＤＡＳＨシステムの簡略図である。エンドツーエンドのＤＡＳＨシステムは、以下のとおり構成される。配信サーバ６１０は典型的には従来のウェブ（ＨＴＴＰ）サーバであり、メディアコンテンツを提供する。配信サーバ６１０は、コンテンツ配信ネットワーク（ＣＤＮ）６２０に接続されてもよい。ＣＤＮ６２０を介して、ストリーミング配信されたコンテンツがエッジサーバ６２５に配信され、格納される。ＭＰＤは、コンテンツの複数のベースＵＲＬの信号による伝達を可能にし、これにより異なるエッジサーバ６２５におけるコンテンツの可用性を通知できる。あるいは、コンテンツサーバ６１０は、インターネット６０５に直接接続されてもよい。ＤＡＳＨクライアント６０１と、配信元６１０またはコンテンツを要求するエッジサーバ６２５との間でＨＴＴＰトラフィックをルーティングする経路上にウェブプロキシが存在してもよい。ウェブプロキシはＨＴＴＰメッセージをキャッシュ可能であり、したがってキャッシュされたコンテンツによりクライアント６０１の要求を処理可能である。これにより、プロキシから原点６１０またはエッジサーバ６２５に向かって必要なネットワーク帯域幅を削減されるため、ネットワークサービスプロバイダにおいて一般的に実施される方式である。エンドユーザ６０１に対しては、ＨＴＴＰキャッシュによりレイテンシが低減できる。ＤＡＳＨクライアント６０１は、モバイルセルラネットワーク等のアクセスネットワークを介してインターネット６０５に接続されてもよい。

ＤＡＳＨでは、幅と高さ（@widthと@height）、フレームレート（@frameRate）、ビットレート（@bandwidth）、表現間の指示された品質順序（@qualityRanking）に基づいて、同じ適応セット内の複数の表現間の自動選択が実現される。@qualityRankingのセマンティックは、次のように指定される。すなわち、ある表現の、同じ適応セット内の他の表現に対する品質ランクを指定する。値が低いほど品質の高いコンテンツを示す。@qualityRankingが存在しない場合、ランキングは定義されない。

本願では、「３６０度ビデオ」または「仮想現実（ＶＲ）動画」または「全方向性動画」という用語は同義として使用することができる。これらの用語は、一般的に、典型的な表示構成において、単一の時点では動画の一部のみが表示されるような巨大な視野を提供するビデオコンテンツを指す。例えば、ＶＲビデオは、例えば図３に示すような、例えば１００度視野を表示可能な頭部装着型ディスプレイ（ＨＭＤ）で見ることができる（図３に示す）。表示されるＶＲビデオコンテンツの空間サブセットは、ＨＭＤの向きに基づいて選択されてもよい。視聴環境の別の例を表す従来のフラットパネル視聴環境では、例えば最大で４０度の視界で表示が実行される。このようなフラットパネルディスプレイ上に広い視野のコンテンツ（例えば、魚眼画像）を表示する場合、ピクチャ全体ではなく、ピクチャの空間サブセットを表示してもよい。そのような例では、ＶＲビデオコンテンツの表示された空間サブセットは、視聴に使用される装置の方位に基づいて選択されてもよい。または例えば、ユーザに基本ユーザインタフェース（ＵＩ）制御を提供することによって、コンテンツのパニングを可能としてもよい。

ＨＭＤが使用しうるビデオインタフェースはＨＭＤＩであり、これはビデオ情報が３つのＴＭＤＳ（Transition Minimized Differential Signaling）チャネル（ＲＧＢ、ＹＣｂＣｒ）でビデオデータ期間として送信されるシリアルインタフェースである。別のビデオインタフェースとしてｓｕｐｅｒＭＨＬでは、ＴＭＤＳチャネルがより多く（６〜８個）存在するため、ビデオやその他のデータをより柔軟に転送できる。主な違いとしては、ＭＨＬがピクセルのＲＧＢ（またはＹＣｂＣｒ）情報を、１つのＴＭＤＳチャネルを介して順次送信することが挙げられる。

伝送チャネルまたは通信チャネルまたはチャネルは、ワイヤ等の物理的伝送媒体、または多重化媒体を介した論理的接続のいずれかを指してもよい。チャネルの例としては、ビデオインタフェースケーブルのレーンと、リアルタイム転送プロトコル（ＲＴＰ）ストリームとが挙げられる。

リアルタイム転送プロトコル（ＲＴＰ）は、音声や動画等の時限式メディアのリアルタイム転送に幅広く利用されている。ＲＴＰは、インターネットプロトコル（ＩＰ）上で動作するユーザデータグラムプロトコル（ＵＤＰ）上で動作する。ＲＴＰは、ＩＥＴＦ（Internet Engineering Task Force）リクエストフォーコメンツ（ＲＦＣ）３５５０（www.ietf.org/rfc/rfc3550.txt参照）で規定されている。ＲＴＰ転送では、メディアデータがＲＴＰパケットにカプセル化される。通常、各メディアの種類またはメディアコーディングフォーマットは、専用のＲＴＰペイロードフォーマットを有する。

ＲＴＰセッションは、ＲＴＰと通信する参加者のグループ内で関連付けを行うものであり、潜在的に多数のＲＴＰストリームを伝送可能なグループ通信チャネルである。ＲＴＰストリームは、メディアデータを含むＲＴＰパケットのストリームである。ＲＴＰストリームは、特定のＲＴＰセッションに属するＳＳＲＣによって識別される。ＳＳＲＣは、ＲＴＰパケットヘッダ内の３２ビットＳＳＲＣフィールドである同期ソースまたは同期ソース識別子のいずれかを指す。同期ソースは、当該同期ソースからのすべてのパケットが同じタイミングおよびシーケンス番号空間の一部を形成することを特徴としているため、受信機は同期ソースによってパケットをグループ化して再生することができる。同期ソースの例は、マイクロフォンまたはカメラ等の信号源から得られたパケットのストリームの送信者やＲＴＰミキサを含む。各ＲＴＰストリームは、ＲＴＰセッション内で一意のＳＳＲＣによって識別される。

３６０度画像またはビデオコンテンツは、例えば以下のようにして撮影および生成可能である。すなわち、画像またはビデオは、複数のレンズおよびセンサを備えたカメラ組またはカメラ装置によって撮影可能である。この撮影により、デジタル画像／ビデオ信号組が得られる。カメラ／レンズは、カメラ組またはカメラ装置の中心点の周りのすべての方向を網羅してもよい。同じ時間インスタンスの画像は、つなぎ合わされ、投影され、詰め込まれたＶＲフレームにマッピングされる。図７に当該処理の例を示す。まず、カメラ装置から入力画像７００を取得する。これらの入力画像は、つなぎ合わされて球体または立方体のような３次元投影構造に投影７１０される。投影構造は、平面またはその一部のような１つまたは複数の表面を含むと捉えられる。投影構造は、撮影ＶＲ画像／ビデオコンテンツが投影される１つまたは複数の面であって、そこからそれぞれの投影されたフレームを形成することが可能な面からなる３次元構造と定義できる。投影構造上の画像データはさらに、２次元投影されたフレーム７２０（投影ピクチャ）上に配置される。「投影」（無指向性投影）という用語は、入力画像組を、投影されたフレームに投影するプロセスとして定義することができる。投影されたフレームに対して例えば、正距円筒投影法（ＥＲＰ、正距円筒パノラマ）および立方体マップ（ＣＭＰ）表現フォーマット等、表現フォーマット組が事前定義されてもよい。

投影されたフレームを１つまたは複数の詰め込まれた（packed）ＶＲフレーム７４０（詰め込まれたピクチャまたは詰め込まれたフレーム）にマッピングするために、領域別マッピング７３０（領域別パッキング）を任意で適用することができる。場合によっては、領域別マッピングは、投影されたフレームから２つ以上の領域を抽出すること、任意で選択的に領域に幾何学的変換（回転、ミラーリング、および／または再サンプリング等）を適用すること、および変換された領域を詰め込まれたＶＲフレーム内の空間的に重ならない領域（構成フレーム区画内）に配置することを含むものと理解される。領域別マッピングを経ない場合、詰め込まれたＶＲフレームは投影されたフレームに等しい。それ以外の場合は、投影されたフレームの領域は、詰め込まれたＶＲフレーム内での各領域の位置、形状、およびサイズを示すことによって、詰め込まれたＶＲフレームにマッピングされる。マッピングという用語は、投影されたフレームが詰め込まれたＶＲフレームにマッピングされるプロセスとして定義されてもよい。詰め込まれたＶＲフレームという用語は、投影されたフレームのマッピングから生じるフレームとして定義することができる。実際には、入力画像は、中間ステップを要さずに、単一の処理で詰め込まれたＶＲフレームに変換することができる。詰め込まれたＶＲフレームは、画像／ビデオ符号化７５０のために提供される。

３６０度パノラマコンテンツ（画像やビデオ）は、カメラデバイスの撮影位置から水平方向に、３６０度視野全周を網羅する。垂直視野は、変動しうるもので、例えば、１８０度であってもよい。水平方向に３６０度視野、垂直方向に１８０度視野を網羅するパノラマ画像は、正距円筒投影により、二次元画像平面にマッピングされた球により表現できる。この場合、変換またはスケーリングを適用せずに、水平座標は経度と同等とみなすことができ、垂直座標は緯度と同等と考えることができる。図８に、単一視正距円筒パノラマピクチャを形成する処理を示す。カメラアレイまたは複数のレンズおよびセンサを有するカメラ装置からの、魚眼画像等の入力画像組８００が、球面画像上にクロスブレンドまたはつなぎ合わされる８１０（等距離投影）。球面画像は、さらに円筒（上面および下面なし）に投影８２０される。円筒は展開されて２次元投影されたフレーム８３０となる。実際には、上記のステップの１つまたは複数を組み合わせてもよい。例えば、入力画像は、球面上への中間投影を伴わずに円筒上に直接投影されてもよい。正距円筒パノラマ用の投影構造は、単一の表面を含む円筒と捉えることができる。同様に、立体視正距円筒のパノラマピクチャは、左眼および右眼の入力画像組から形成することができる。立体視正距円筒パノラマでは、パノラマの上部が左眼画像であり、パノラマの下部が右眼画像であってもよい。

正距円筒投影は、（正距円筒投影フォーマットの）投影ピクチャ内の任意のサンプル位置を座標系の角度座標に変換する処理として定義することができる。投影ピクチャ内のサンプルの位置は、サンプル内の正距円筒パノラマピクチャのそれぞれの幅および高さであるpictureWidthおよびpictureHeightに基づいて定義することができる。以下、水平および垂直軸に沿ったサンプル位置の中心点をそれぞれｉおよびｊとする。サンプル位置の角度座標（Φ、θ）（単位：度）は、以下の正距円筒マッピング方程式で求められる。

Φ =（ i ÷ pictureWidth - 0.5 ）* 360, θ =（ 0.5 - j ÷ pictureHeight ）* 180

通常、３６０度のコンテンツは、多面体（すなわち、例えば立方体またはピラミッドを含む、平坦な多角形面、直線的なエッジ、および鋭角の角または頂点を有する３次元立体オブジェクト）、円筒（上述のように、正距円筒投影にて球形の画像を円筒上に投影）、円筒（球への投影を経ずに直接）、円錐等の異なる様々な種類の立体幾何学構造にマッピングでき、その後二次元画像平面に展開できる。

場合によっては、水平視野は３６０度で、垂直視野が１８０度未満のパノラマコンテンツは、球の極領域が二次元画像平面上にマッピングされていない正距円筒投影の特殊例と考えられる。また、場合によって、パノラマ画像は、水平視野が３６０度未満で、垂直視野が最大で１８０度であってもよく、それ以外は正距円筒投影形式の特徴を有するものであってもよい。

球状領域は、球上の領域として定義されてもよく、球状領域を指定する手段によってさらに限定されてもよい。当該手段としては、領域を４つの大円または２つのヨー円と２つのピッチ円により指定することが含まれうるが、これに限定されない。大円は、球と、その球の中心点を通過する平面との交点と定義することができる。大円は、大円の弧（orthodrome）またはリーマン円とも呼ばれる。球と大円とは中心位置が同じである。ピッチ円は、ピッチ値が等しいすべての点を接続する球上の円として定義できる。ヨー円は、ヨー値が等しいすべての点を接続する球上の円として定義できる。球状領域は、同じパラメータ（例えば、同じ大円）で定義される他の球状領域と区別されるように、領域内の点、例えば領域の中心点をさらに要しうる。

品質ランキングは、品質ランキング値に関連付けられ、復号されたピクチャまたは球に関して指定される領域として定義されてもよい。２Ｄ領域は、復号されたピクチャ上の領域として定義されてもよく、さらに矩形に限定されてもよい。品質ランキング２Ｄ領域は、復号されたピクチャに対して指定された品質ランキング領域として定義されてもよい。品質ランキング球状領域は、球に関して指定された品質ランキング領域として定義されてもよい。

３６０度システムでは、座標系は、ヨー角（Φ）、ピッチ角（θ）、およびロール角を定義するために使用されうる直交座標軸Ｘ（横）、Ｙ（垂直、上向き）、Ｚ（後ろから前の軸、外向き）により定義できる。ヨーは、Ｙ軸を中心に回転、ピッチはＸ軸を中心に回転、ロールはＺ軸を中心に回転するものと定義できる。回転は、外部要因依存であり、すなわち、Ｘ、Ｙ、およびＺ固定基準軸の周りに定義されてもよい。原点から軸の正の端に向かって見ると、角度は時計回りに増加するように定義することができる。

グローバル座標軸は、上述した座標系に基づき、同じ取得位置を表し、一緒にレンダリングされるオーディオ、ビデオ、および画像に関連付けられた座標軸として定義することができる。グローバル座標軸の原点の位置は、通常、全方向性オーディオ／ビデオ取得のために使用されるデバイスまたはリグの中心点、ならびにオーディオおよびビデオトラックが存在する３次元空間における観察者の頭部の位置と同じである。初期視点メタデータがない場合、グローバル座標軸に対して（ヨー、ピッチ、ロール）の方向（０、０、０）を使用して再生を開始することが推奨される。

人間の眼では３６０度空間全体を見ることは不可能であり、最大水平および垂直視野（ＦｏＶ、人間の眼の水平視野（ＨＨＦｏＶ）、人間の眼の垂直視野（ＨＶＦｏｖ））に限定される。また、ＨＭＤデバイスは、技術的限界により、水平および垂直方向（デバイス水平視野（ＤＨＦｏＶ）、デバイス垂直視野（ＤＶＦｏＶ））で３６０度の空間全体のサブセットのみを見ることを可能にする。

任意の時点で、ＨＭＤ上のアプリケーションによってレンダリングされたビデオにより、３６０度ビデオの一部がレンダリングされる。このアプリケーションにおいて、当該部分は「ビューポート」と定義される。ビューポートは、レンダリングディスプレイを介して表示された全方位ビデオで表される３６０度世界におけるウィンドウである。ビューポートは、水平および垂直視野（ビューポート水平視野（ＶＨＦｏＶ）、ビューポート垂直視野（ＶＶＦｏＶ））によって特徴付けられる。以下、ＶＨＦｏＶおよびＶＶＦｏＶを、ＨＦｏＶおよびＶＦｏＶと略記する。

ビューポートのサイズは、アプリケーションに応じて、ＨＭＤ視野に対応してもよく、またはＨＭＤ視野よりも小さくても大きくてもよい。より分かりやすいよう、任意の時点でユーザが見る３６０度の空間の部分を「主ビューポート」と呼ぶ。

ＶＲビデオのストリーミングビットレートを低減する１つの方法として、ビューポート適応ストリーミング（ビューポート依存配信）が挙げられる。当該ストリーミングでは、主要ビューポートを網羅する３６０度ビデオコンテンツのサブセット（すなわち、現在のビューの向き）が最高品質／解像度で伝送され、３６０度ビデオの残りの部分は低品質／解像度で伝送される。ビューポート適応型ストリーミングには、一般に次の２つのアプローチが存在する。
（１）ビューポート固有の符号化およびストリーミング（ビューポート依存の符号化およびストリーミング、非対称投影、詰め込まれたＶＲビデオとも称される）。この手法では、３６０度の画像コンテンツは、主ビューポート上で強調（例えば、より大きな空間領域）され、同じフレームに詰め込まれる。詰め込まれたＶＲフレームは、単一のビットストリームに符号化される。例えば、立方体マップの前面を他の立方体面に比べて高い解像度でサンプリングし、立方体面を図９に示すように同じ詰め込まれたＶＲフレームにマッピングすることができる。
（２）ＶＲビューポートビデオ（タイルベースのエンコーディングおよびストリーミングとも称される）。このアプローチでは、３６０度コンテンツが符号化され、様々な符号化からビューポートが選択的にストリーミング可能なように提供される。例えば、各立方体の面を別々に符号化することができる。各立方体面に対して、例えばそれぞれ異なる空間分解能を有する２つ以上の符号化されたビットストリームが提供されてもよい。プレーヤは、現在の視聴方向に基づいて復号および再生されるビットストリームを選択することができる。現在の表示方向のレンダリングに使用される立方体面に対しては高解像度ビットストリームが選択され、残りの立方体面は低解像度ビットストリームから取得されてもよい。
別の例では、正距円筒パノラマコンテンツは、動きが制限されたタイルセットを使用して符号化される。異なる空間解像度および／または画質を有する、２つ以上の符号化されたビットストリームが提供されてもよい。動きが制限された各タイルセットは、それぞれのビットストリームで利用可能になる。プレーヤは、現在の視聴方向に基づいて復号および再生されるビットストリームを選択することができる。現在の主ビューポートを網羅するタイルセットに対して高解像度または高品質のビットストリームを選択し、３６０度のコンテンツの残りの領域は低解像度または低品質のビットストリームから取得してもよい。

上述のアプローチ（１）および（２）を組み合わせることができる。

３６０度の空間は、それぞれが所定の距離（例えば、単位は度である）で区切られた離散したビューポート組に分割されていると仮定することができるため、全方位空間を重複するビューポートのマップとして捉えることができ、ユーザがＨＭＤでコンテンツを見ながら自身の向きを変えると、主ビューポートが離散的に切り替わる。ビューポート間の重なりがゼロになると、ビューポートは、３６０度の空間内で隣接して重なっていないタイルとして捉えられうる。Ｈ．２６５ビデオコーデックは、当該状況（重複する場合、しない場合のいずれも）を実現するために使用されうるタイルの概念を実現するように構成されている。

ＶＲ領域では、同じ信号がＨＭＤを介して両眼にレンダリングされる場合、ビデオ信号がモノスコープであると定義される。両眼での両眼視による立体視効果（すなわち、奥行き感知）を実現できる場合、ビデオ信号は立体視として定義される。立体視は、両眼の間の両眼視差によって実現される。すなわち、眼の間の所定の距離により、奥行きが感知可能となる。立体信号は２つのデータストリームからなり、それぞれ右眼、左眼で見られるものとなる。当該ストリーム同士の差分は、上述のように両眼視差によって実現される。

人間の視覚システム（ＨＶＳ）は興味深い特性を持つ。すなわち、左右の眼に対して（ある限度まで）異なる品質でレンダリングされた立体映像信号でも、あたかも左と右の両方で最高品質であるかのように知覚される。このため、ＨＶＳは、低品質画像に関してマスキングフィルタを適用する。

ＨＶＳのいくつかの特性は数十年前から解明されているが、ＨＭＤ上のビデオレンダリング中にいくつかの種類の不均一性を利用した立体視ビデオに対するＨＶＳの反応の完全な解明はいまだなされておらず、多分に研究の余地がある。

今までの調査研究により、ビュー間の不均一な品質により、知覚されるビデオ品質が劣化せずに（知覚される品質が、より高品質のビューの品質に近いことによる）、システムに必要な帯域幅を低減するためのデジタル３６０度ビデオストリーミングシステムが実現できることが分かっている。

３６０度ステレオビデオの配信は、以下により詳細に説明される、いくつかのパラメータによって特徴付けられる。これらのパラメータは重要な役割を果たし、ストリーミング帯域幅の要件を軽減する目的で、不均一な立体映像３６０度ビデオストリーミング配信に利用できる。

最近、ＭＰＥＧ（Motion Picture Experts Group）は、立体映像を使用できる全方向性メディアフォーマット（Omnidirectional Media Format：ＯＭＡＦ）の最初の規格の定義に着手した。現在、不均一な３６０度ビデオの運用に対する規格は存在しない、またはその仕様が不十分である。本実施形態は、この現状の不満を解消し、およびＭＰＥＧ ＯＭＡＦまたは同様のシステムにおける不均一な３６０度ビデオのストリーミングを可能にするために必要とされる一連のパラメータを定義することを目標とする。

ビデオビットストリームの特性は、ビットストリーム内のビデオ使用可能性情報（ＶＵＩ）および／または補足拡張情報（ＳＥＩ）のような様々な手段によってシグナリングすることができるが、このようなシグナリングは３６０度ビデオの異なる球状領域の異なる特性を示すためには使用できない。

ＭＰＥＧ−ＤＡＳＨ等の現行のストリーミングシステムでは、ストリーミングクライアントは、ストリーミングマニフェストまたはプレゼンテーション記述に示されるコンテンツ特性に基づいて、ＭＰＥＧ−ＤＡＳＨの表現等のコンテンツピースを選択する。同様に、マルチメディアファイルがメディアコンテンツの複数の異なるビットストリームを含む場合、ビデオプレーヤは、マルチメディアファイルに示された特性に基づいて、使用に最適なビットストリームを選択する。

３６０度ビデオの再生では、コンテンツは様々な要因に基づいて選択可能であるとされている。当該要因の１つとして、ビューポート依存コンテンツ選択が挙げられる。これは、処理がより複雑でなくなるように、非可視領域の特性を犠牲にしながら、現在表示されているビューポートの高品質を提供するコンテンツを選択することを可能とするものである。別の要因としては、ディスプレイに依存するおよび／またはユーザの好みに基づく、左右のビューの特性の不均一性に対する限定が挙げられる。

ＨＥＶＣでは、領域的に入れ子状のＳＥＩメッセージは、ＳＥＩメッセージを画像の領域に関連付けるためのメカニズムを提供する。関連付けられたＳＥＩメッセージは、領域的に入れ子状のＳＥＩメッセージに含まれて伝達される。領域的に入れ子状のＳＥＩメッセージは、１つまたは複数のＳＥＩメッセージを含む。ＳＥＩメッセージが領域的に入れ子状のＳＥＩメッセージに含まれる場合、この含まれるＳＥＩメッセージは、領域に入れ子にされたＳＥＩメッセージと呼ばれる。領域的に入れ子状のＳＥＩメッセージ内の各領域に入れ子にされたＳＥＩメッセージにおいて、領域的に入れ子状のＳＥＩメッセージには１つ以上の領域が指定され、領域に入れ子にされたＳＥＩメッセージのセマンティックはこれらの各領域に適用されるものとして解釈される。

したがって、このメカニズムにより、ピクチャの領域の異なる特性および領域が指定できる。

３６０度ビデオにおける不均一性を実現する方法は、以下のとおり様々なものが存在する。すべての方法は、立体視３６０度ビデオの送信（例えば、ストリーミング）および／または格納について求められる帯域幅の低減という利点を実現しながら、視覚的品質を一定に保つことである。

信号対ノイズ比（Signal-to-Noise Ratio：ＳＮＲ）不均一では、あるビューがより高いＳＮＲ品質で（例えば、より低いＱＰを使用して）送信、レンダリングされ、別のビューがより低いＳＮＲ品質で（すなわち、より高いＱＰを使用して）送信、レンダリングされる。

空間的不均一では、あるビューがより高い空間解像度で送信、レンダリングされ、別のビューがより低い空間解像度で送信、レンダリングされる。

時間的不均一では、あるビューがより高い時間解像度（すなわち、より高いフレームレート）で送信、レンダリングされ、別のビューがより低い時間解像度（すなわち、より低いフレームレート）で送信、レンダリングされる。

ＦＯＶ不均一では、あるビューがより広い水平視野および／または垂直視野で送信、レンダリングされ、別のビューがより狭い水平視野および／または垂直視野で送信、レンダリングされる。

ビット深度では、一方の眼により高いビット深度で符号化されたビデオストリームが送信、レンダリングされ、他方の眼に、より低いビット深度で符号化されたビデオストリームが送信、レンダリングされる。より一般的には、サンプル値を表す値の範囲が、ビュー間で異なってもよい。例えば、１つのビューのサンプル値は０以上７６７以下の範囲内になるようにスケーリングされ、他のビューのサンプル値は０以上１０２３以下の範囲内とし、両方のビューは１０ビットのビットレートを使用し、２つの値の範囲の極値は同じ色に対応するものであってもよい。

クロマフォーマット不均一では、複数のビューは異なるクロマフォーマットを有し、例えばあるビューが４：２：０のクロマフォーマットを有し、別のビューが４：４：４のクロマフォーマットを有する。

色域不均一では、複数のビューは異なる色域を有し、例えばあるビューがＢＴ．７０９規格の色域を使用し、別のビューがＢＴ．２０２０規格の色域を使用する。

上述の方法を組み合わせることも可能である。

本技術は、立体視ビデオストリームの送信中に、上述の不均一手法の１つ以上が使用されていることを示す一連のインジケータ（例えばパラメータまたはフラグの形態をとる）の定義を含む。この一連のインジケータを以下に詳述する。

ＳＮＲ不均一インジケータのフラグが１に設定されると、複数のビューの内のあるビューがより高いＳＮＲ品質で実行され、別のビューがより低いＳＮＲ品質で実行されることを示す。これに加えて、どのビューがより高品質で実行されるかを記述するフィールドが標示される（左または右）。

空間的不均一インジケータのフラグが１に設定されると、複数のビューの内のあるビューがより高い空間解像度で実行され、別のビューがより低い空間解像度で実行されることを示す。これに加えて、どのビューがより高い空間解像度で実行されるかを記述するフィールドが標示される（左または右）。任意で、左右の空間解像度（すなわち、空間分解能）に関連する２つのフィールドが標示でき、適切な単位で表現された２つのビューの実際の空間解像度値を含むことができる。

時間的不均一インジケータのフラグが１に設定されると、複数のビューの内のあるビューがより高い時間解像度で実行され、別のビューがより低い時間解像度で実行されることを示す。これに加えて、どのビューがより高い時間解像度で実行されるかを記述するフィールドが標示される（左または右）。任意で、左右の時間解像度（すなわち、フレームレート）に関連する２つのフィールドが標示でき、適切な単位で表現された２つのビューの実際の時間解像度値を含むことができる。

ＦＯＶ不均一インジケータのフラグが１に設定されると、複数のビューの内のあるビューがより広い水平視野および／または垂直視野で実行され、別のビューがより狭い水平視野および／または垂直視野で実行されることを示す。これに加えて、どのビューがより広い水平視野および／または垂直視野を使用しているかを記述するフィールドが標示される（左または右）。さらに、左右の視野ビューに関連する２つのフィールドが標示でき、それぞれ適切な単位で表現された水平および垂直視野を含むことができる。

ビット深度不均一インジケータのフラグが１に設定されると、複数のビューの内のあるビューがより高いビット深度で実行され、別のビューがより低いビット深度で実行されることを示す。これに加えて、どのビューがより高いビット深度を使用しているかを記述するフィールドが標示される（左または右）。さらに、左右の視野ビューに関連する２つのフィールドが標示でき、それぞれ適切な単位で表現された各ビューのビット深度値を１つ含むことができる。

サンプル値範囲不均一インジケータのフラグが１に設定されると、あるビューのサンプル値は、別のビューのサンプル値とは異なる値の範囲を使用することを示す。

クロマフォーマット不均一インジケータのフラグが１に設定されると、複数のビューは異なるクロマフォーマットを有し、例えばあるビューが４：２：０のクロマフォーマットを有し、別のビューが４：４：４のクロマフォーマットを有することを示す。さらに、さらに、左右の視野ビューに関連する２つのフィールドが標示でき、それぞれ適切な単位で表現された各ビューのクロマフォーマット値を１つ含むことができる。

色域不均一インジケータのフラグが１に設定されると、複数のビューは異なる色域を有し、例えばあるビューがＢＴ．７０９規格の色域を使用し、別のビューがＢＴ．２０２０規格の色域を使用する。さらに、左右の視野ビューに関連する２つのフィールドが標示でき、それぞれ適切な単位で表現された各ビューの色域値を１つ含むことができる。

これらインジケータは、様々なレベルで適用されてもよい。例えば、インジケータは、ピクチャ全体（例えば、パノラマ３６０度ピクチャ）に適用することができる。あるいは、インジケータは、サブピクチャ（例えば、ピクチャ全体よりも小さい領域、例えば、限られた垂直および水平視野を表すタイル）に適用することができる。一実施形態では、パラメータは、１つまたは複数の球状領域に対して示される。球状領域は、球上のコンテンツ範囲のサブセットに対応してもよい。

パラメータは、基本ビデオビットストリームの一部として（例えば、ＳＥＩメッセージまたはＶＵＩとして）および／またはファイルフォーマットの一部（例えば、ＩＳＯベースのメディアファイルフォーマット）として組み込まれてもよく、さらに／あるいはトランスポートプロトコル（例えば、ＭＰＥＧ ＤＡＳＨプロトコルのＭＰＤに組み込まれる）により送信されてもよいし、または一般に、送信元エンティティ（クライアントまたはサーバ）から送信先エンティティ（クライアント）に、ＩＳＯ ＯＳＩレイヤの任意のプロトコルを介して送信されてもよい。

ＭＰＥＧ ＩＳＯＢＭＦＦでの実装例とＭＰＥＧ ＯＭＡＦでの使用例を以下に挙げる。

以下のシンタックスおよセマンティックにより、ＯＭＡＦのSphereRegionQualityRankingBoxが添付される。同様の拡張を、ＯＭＡＦの2DRegionQualityRankingBoxに対して指定してもよい。これらボックスは、サンプル エントリ内に存在する。

aligned(8) class SphereRegionQualityRankingBox extends FullBox('srqr', 0, 0) {
unsigned int(8) region_definition_type;
unsigned int(8) num_regions;
unsigned int(12) unequality_indicator_mask;
unsigned int(1) remaining_area_flag;
unsigned int(1) view_idc_present_flag;
if (view_idc_present_flag)
bit(2) reserved = 0;
else
unsigned int(2) default_view_idc;


for (i = 0; i < num_regions; i++) {
unsigned int(8) quality_ranking;
if (view_idc_present_flag) {
unsigned int(2) view_idc;
bit(6) reserved = 0;
}
if (i < num_regions - 1 || remaining_area_flag == 0)
SphereRegionStruct(1);
}
}

上述のシンタックス要素は、「unequality_indicator_mask」という要素が存在するが、現在ＯＭＡＦで指定されているものとを同一または同様である。

region_definition_typeが０であると、球状領域が４つの大円で指定されることを示す。region_definition_typeが１であると、球状領域が２つのヨー円と、２つのピッチ円により指定されることを示す。region_definition_typeのその他の値も存在する。

num_regionsは、該当ボックス内で、品質ランキング情報が与えられる品質ランキング領域の数を示す。

remaining_area_flagが０であると、すべての品質ランキング領域がSphereRegionStruct(1)で指定されることを示す。remaining_area_flagが１であると、第１のnum_regions - 1品質ランキング領域がSphereRegionStruct(1)構造で指定され、最後に残る品質ランキング領域が第１のnum_regions - 1 SphereRegionStruct(1)構造で定義される品質ランキング領域の組合せで網羅されない、網羅範囲内の球体領域であることを示す。

SphereRegionStruct（1）は、グローバル座標軸に対する品質ランク付け領域の球面位置およびサイズを指定し、region_definition_typeは品質ランク付け領域の形状を示す。

SphereRegionStructのシンタックスは、以下のように指定できる。

aligned(8) SphereRegionStruct(range_included_flag) {
signed int(32) center_yaw;
signed int(32) center_pitch;
singed int(32) center_roll;
if (range_included_flag) {
unsigned int(32) hor_range;
unsigned int(32) ver_range;
}
unsigned int(1) interpolate;
bit(7) reserved = 0;
}

center_yaw、center_pitch、およびcenter_rollは、２^−１６度単位でグローバル座標軸に対する球状領域の向きを指定する。center_yawおよびcenter_pitchは、球状領域の中心を示し、center_rollは、球状領域のロール角を示す。

hor_rangeおよびver_rangeが存在する場合は、これらはそれぞれ該当サンプルで指定された球状領域の水平および垂直の範囲をそれぞれ２^−１６度単位で指定する。hor_rangeおよびver_rangeは、球状領域の中心点を通る範囲を指定する。

品質ランク付け領域に対して、補間は０に等しくする必要がありうる。

view_idc_presence_flagが０であると、view_idcが存在しないことを示す。view_idc_presence_flagが１であると、view_idcが存在し、特定の（左右の一方または両方）ビューまたは単一視コンテンツに対する品質ランキング領域関連付けを示す。

default_view_idcが０であると、品質ランキング領域がモノスコープであることを示し、１であると、品質ランキング領域が立体視コンテンツの左ビューにあることを示し、２であると、品質ランキング領域が立体視コンテンツの右ビューにあることを示し、３であると、品質ランキング領域が立体視コンテンツの左右ビューの両方にあることを示す。

quality_rankingは、品質ランキング領域の品質ランキング値を指定する。quality_rankingが０であると、品質ランキング値が定義されていないことを示す。０以外の品質ランキング値は、品質ランキング領域の相対的品質順序を示す。品質ランキング値が０以外で、品質ランキング領域Ｂよりも低い品質ランキング領域Ａは、品質ランキング領域Ｂよりも品質が高い。品質ランキング値が０でなければ、指定された品質ランキング領域全体内のピクチャ品質は略一定である。

view_idcが０であると、品質ランキング領域が平坦であることを示し、１であると、品質ランキング領域が立体視コンテンツの左ビューにあることを示し、２であると、品質ランキング領域が立体視コンテンツの右ビューにあることを示し、３であると、品質ランキング領域が立体視コンテンツの左右ビューの両方にあることを示す。存在しないview_idcの値はdefault_view_idcの値と等しいと推定される。

シンタックス要素unequality_indicator_maskが、本技術の目的のために指定される。

unequality_indicator_maskにおける各ビット位置は、上述のように不均一インジケータに対応していてもよい。例えば、ビット位置０が空間的不均一インジケータに対応し、ビット位置２が時間的不均一インジケータに対応する等であってもよい。インジケータのその他順序も適用可能であることが理解されよう。

unequality_indicator_maskの値が０以外で、quality_rankingの値がビュー間および／または領域間で異なる場合、unequality_indicator_mask内の、ビットが１に等しいビット位置が、適用された不均一の種類を示す。

別の例では、ＩＳＯによるメディアファイルフォーマットのStereoVideoBoxが追加される。そのシンタックスは、現状以下のとおりになる。

aligned(8) class StereoVideoBox extends extends FullBox('stvi', version = 0, 0)
{
template unsigned int(30) reserved = 0;
unsigned int(2) single_view_allowed;
unsigned int(32) stereo_scheme;
unsigned int(32) length;
unsigned int(8)[length] stereo_indication_type;
Box[] any_box; // optional
}

例示的実施形態では、例えばUnequalityIndicatorBoxという名の新たなボックスがStereoVideoBoxに含まれるように指定され、ビュー間の不均一の種類についての情報を含む。例えば、UnequalityIndicatorBoxのシンタックスは以下のとおりに指定される。

aligned(8) class UnequalityIndicatorBox extends extends FullBox('uneq', version = 0, 0)
{
unsigned int(16) unequality_indicator_mask;
}

上述のunequality_indicator_maskのセマンティックは、ここでも適用できる。すなわち、unequality_indicator_maskが０でなければ、unequality_indicator_mask内のビットが１に等しいビット位置は、適用された不均一の種類を示す。

ある実施形態によると、UnequalityIndicatorBoxは、ビュー間の不均一を特徴付ける追加の性質を含んでもよく、例えば、主観的品質が高い方のビューが示される。あるいは、品質の差分を示すインジケータ値が利用されてもよい。これらの値は、それぞれ不均一の種類に固有のものであって、対応する不均一が示される場合にのみ存在するという条件であってもよい。例えば、ＳＮＲ不均一について、ビュー間の平均または近似ピークSNR差、および／またはビュー間の平均量子化パラメータ値の差が示されてもよい。

次に、ＭＰＥＧ ＤＡＳＨの実施例とＭＰＥＧ ＯＭＡＦにおける用例を挙げる。

ＤＡＳＨについての領域ごとの品質ランキング（Region-Wise Quality Ranking：ＲＷＱＲ）記述子のインジケータは、ＯＭＡＦの仕様において現在以下のように規定されている。

実施形態によっては、ＲＷＱＲ記述子は以下のように別記される。

ある実施形態において、上述の不均一インジケータを、複数のビュー間に適用することに加えて、またはこれに代えて、複数の球状領域および／または２Ｄ領域間に適用してもよい。例えば、同じビューの球状領域Ａおよび球状領域ＢがＳＮＲ不均一インジケータに対応付けられている場合、球状領域Ａと球状領域Ｂとは異なるＳＮＲを有する。同様に、同じビューの２Ｄ領域ＡおよびＢが空間的不均一インジケータに対応付けられている場合、これらの２Ｄ領域ＡおよびＢは２Ｄドメイン内で異なるサンプリング密度または間隔を有する。例えば、２Ｄ領域Ａは解像度８１９２×４０９６のＥＲＰピクチャから抽出され、２Ｄ領域Ｂは解像度４０９６×２０４８のＥＲＰピクチャから抽出されてもよい。

上述の例示的実施形態は、不均一インジケータを、複数のビュー間に適用することに加えて、またはこれに代えて、複数の球状領域および／または２Ｄ領域間に適用する際にも同様に当てはまる。例えば、SphereRegionQualityRankingBoxの例示的実施形態において、unequality_indicator_maskの値がゼロではなく、quality_ranking値が当該領域間で異なる場合、unequality_indicator_mask内で１に等しいビットを有するビット位置は、領域間に適用された不均一の種類を示す。ここで、当該領域は同じビュー内にあっても、異なるビュー内にあってもよい。

ある実施形態において、品質ランキングシグナリングの２つ以上の組（例えば、SphereRegionQualityRankingBox、2DRegionQualityRankingBox、ＲＷＱＲ記述子）が、不均一インジケータマスクの異なる組合せに対して存在してもよい。例えば、第１のSphereRegionQualityRankingBoxが空間的不均一に対して存在して、空間的不均一に応じた品質ランキング値を有し、第２のSphereRegionQualityRankingBoxがＳＮＲ不均一に対して存在して、ＳＮＲ不均一に応じた品質ランキング値を有することができる。

ある実施形態において、品質ランキングシグナリングの２つ以上の組の順序は、標示されているかまたはあらかじめ定められている。この順序により、第２のシグナリングレベルの品質ランキングは、第１のシグナリングレベルに同じ品質ランキングが存在するのであればそのランキングを有する複数の領域に対して適用されることを定義する。例えば、空間的不均一に対する品質ランキングにおいて、他の不均一は考慮されず、他の種類の不均一に対する品質ランキングにおいて、品質ランキング値は空間的不均一に対して同じ品質ランキング値を有する複数の領域間にのみ適用することが標示されているかあらかじめ定められている。このようなシグナリングであれば、現在のビューポートに対して好適な空間解像度を提供する一連のビットストリームまたは表現がまず選択され、その一連のビットストリームまたは表現から、例えば送信スループットおよび／または復号性能に最も合致するものが選択されてもよいという点で有利である。

一実施形態による符号化の方法が図１０のフローチャートに図示されている。この符号化方法では、図１０の方法に従ってビデオデータが生成され、図３に例示するＨＭＤに送信される。図９の例に示された方法は、メディアコンテンツのビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための一連のインジケータを符号化すること１０１０を含み、不均一の種類によって、第１のビューまたは領域のビデオストリームおよび第２のビューまたは領域のビデオストリームに対して異なる符号化パラメータを定義する。任意で、前記方法は、前記メディアコンテンツの前記ビットストリームの中にまたはこれに沿って、前記第１のビューまたは領域に関連付けられた第１の品質ランキング値および前記第２のビューまたは領域に関連付けられた第２の品質ランキング値を含めること１０２０をさらに含み、前記第１および第２の品質ランキング値の順序は、前記第１のビューまたは領域と前記第２のビューまたは領域との知覚される品質の順序を示す。任意で、前記方法は、前記メディアコンテンツの前記ビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための第２の一連のインジケータを含めること１０３０をさらに含み、前記第２の一連のインジケータは、同じ品質ランキング値を有する複数の領域中の不均一の種類を示す。

一実施形態による装置は、上述の方法を実施する手段を備える。例えば、この装置は、メディアコンテンツのビットストリームの中にまたはこれに沿って、１つ以上の不均一の種類を標示するための一連のインジケータを符号化する手段を備え、不均一の種類によって、第１のビューまたは領域のビデオストリームおよび第２のビューまたは領域のビデオストリームに対して異なる符号化パラメータを定義する。

ビットストリームの復号は、データを受信しビデオストリームを視聴者の両眼へと表示するＨＭＤによって実施されてもよい。

本実施形態により効果がもたらされる。例えば、視覚的品質を一定に保ち、メディアコンテンツ（立体視３６０度ビデオ等）の送信（例えばストリーミング）および／または格納に必要な帯域幅を低減することができる。送信帯域幅の低減は、例えばビューポートに応じてコンテンツを選択することにより実現されてもよく、現在視認可能なビューポートに対してより高品質を提供するコンテンツが選択されてもよく、一方で、例えば処理がより複雑でなくなるように非視認可能エリアの特性を落としてもよい。また、送信または再生されたコンテンツを、左右のビュー間で不均一の種類や制限についてのユーザの好みに合わせられることも効果として挙げられる。さらに、ビューポートに適応しうる高度な速度適応方法を使いやすくすることや、ビューおよび／または領域間の不均一を異なる種類のものを選択することにより知覚される品質を最適化しようとする試みも効果として挙げられる。

上述の一部の実施形態は、ＤＡＳＨまたはＭＰＥＧ−ＤＡＳＨとの関連で説明されている。実施形態は、その他同様の任意のストリーミングシステム、および／またはＤＡＳＨに使用されているのと同様の任意のプロトコル、および／またはＤＡＳＨに使用されているのと同様の任意のセグメントおよび／またはマニフェストフォーマット、および／またはＤＡＳＨクライアントと同様のクライアント操作によっても同様に実現されうることが理解されよう。例えば、一部の実施形態は、ＡｐｐｌｅのＨＴＴＰライブストリーミング（ＨＬＳ）のＭ３Ｕのマニフェストフォーマットによって実現されうる。

上述の一部の実施形態は、サンプルエントリ等にメタデータまたは標示を含むものとして説明されている。実施形態は、サンプルグループ等の動的なメタデータキャリッジ機構にメタデータまたは標示を含むことによっても同様に実現されうることが理解されよう。例えば、SphereRegionQualityRankingBoxがサンプルグループ記述エントリとして使用されてもよい。この種の複数のサンプルグループ記述エントリをSampleGroupDescriptionBoxに含めることができ、特定のメディアサンプル用に適用されるサンプルグループ記述エントリはSampleToGroupBoxで標示される。

ビットストリームに沿ったフレーズ（例えばビットストリームに沿った標示）が、請求項や記載された実施形態において、帯域外データをビットストリームに関連付ける形で帯域外送信、信号による伝達、または格納することを示すために用いられてもよい。例えば、ビットストリームに沿った標示を含むフレーズは、コンテナファイル（ビットストリームも含む）またはＤＡＳＨ ＭＰＤ等のビットストリームの記述内に標示を含めることを意味してもよい。ビットストリーム等に沿って復号するというフレーズは、ビットストリームに関連付けられた、上記帯域外データ（帯域外送信、信号による伝達、または格納から得られたものであってもよい）を復号することを指していてもよい。例えば、ビットストリームに沿って標示を復号するというフレーズは、コンテナファイル（ビットストリームも含む）またはＤＡＳＨ ＭＰＤ等のビットストリームの記述から標示を復号することを意味してもよい。

上述の一部の実施形態は、コンテナファイルの中にまたはこれに沿って、メタデータまたは標示を含め、および／またはメタデータおよび／または標示をコンテナファイルからまたはこれに沿って解析または復号するものとして説明されている。これに加えて、またはこれに代えて、標示またはメタデータを、例えばＳＥＩメッセージ（複数可）またはＶＵ Ｉ等のビデオビットストリームに符号化または含めてもよく、および／または例えばＳＥＩメッセージ（複数可）またはＶＵＩ等からビデオビットストリームに復号されてもよいことが理解されよう。例えば、上述のように、品質ランキング値および不均一インジケータマスクを備える品質ランキングＳＥＩメッセージが特定されてもよい。品質ランキングＳＥＩメッセージは、領域的に入れ子状のＳＥＩメッセージに含まれてもよく、当該領域的に入れ子状のＳＥＩメッセージ内の特定の領域は、例えば立体視フレームに詰め込まれたピクチャの１つの構成ピクチャを含んでもよい。さらに、これに加えて、またはこれに代えて、標示またはメタデータは、ＤＡＳＨのＭＰＤ等の、コンテナファイル、トラック、またはビットストリームのいずれかの記述に含まれてもよく、および／またはコンテナファイル、トラック、またはビットストリームのいずれかの記述から復号されてもよいことが理解されよう。

本発明の各種実施形態は、メモリ中に存在し、関連する装置に発明を実行させる、コンピュータプログラムコードにより実施可能である。例えば、デバイスは、データを処理、受信、送信する回路および電子機器と、メモリに保存されたコンピュータプログラムコードと、当該コンピュータプログラムコードを実行中に当該デバイスに実施形態の特徴を実行させるプロセッサとを備えてもよい。さらに、サーバのようなネットワークデバイスは、データを処理、受信、送信する回路および電子機器と、メモリに保存されたコンピュータプログラムコードと、当該コンピュータプログラムコードの実行中に当該ネットワークデバイスに実施形態の特徴を実行させるプロセッサを備えてもよい。

必要に応じて、本明細書に記載された異なる機能は、異なる順序で、および／または互いに同時に、実施されてもよい。さらに、必要に応じて、１つ以上の上述の機能や実施形態は任意であってもよく、これらを組み合わせてもよい。

実施形態の各種態様が独立請求項に規定されているが、その他の態様には、記載されている実施形態および／または独立請求項の特徴を有する従属請求項とは異なる組合せの特徴が含まれ、その組合せは請求項に明示的に規定されたものに限らない。

例示的実施形態を説明してきたが、これらの説明は限定的に解釈されない。添付の特許請求の範囲に記載されたような本開示の範囲から逸脱することなく、各種変更や変形が可能である。

Claims (6)

1. 第１のビューまたは領域に関する第１のビデオストリームの符号化が、第２のビューまたは領域に関する第２のビデオストリームの符号化とは異なることを示す一連のインジケータを、メディアコンテンツのビットストリームの中にまたはこれと一緒に符号化することを含む方法であって、
   前記一連のインジケータは、前記第１のビデオストリームのための符号化パラメータ及び前記第２のビデオストリームのための符号化パラメータが、それぞれ、異なる水平値又は垂直値に基づくことを示し、 前記方法は更に、前記メディアコンテンツの前記ビットストリームの中にまたはこれと一緒に、前記第１のビューまたは領域に関連付けられた第１の品質ランキング値および前記第２のビューまたは領域に関連付けられた第２の品質ランキング値を含めることをさらに含み、
   前記第１および第２の品質ランキング値の順序は、前記第１のビューまたは領域と前記第２のビューまたは領域との知覚される品質の順序を示し、
   前記第１および第２の品質ランキング値が０である場合は、品質ランキング値が定義されていないことを示す、方法。
2. 前記メディアコンテンツの前記ビットストリームの中にまたはこれと一緒に、第２の一連のインジケータを含めることをさらに含み、
   前記第２の一連のインジケータは、同じ品質ランキング値を有する複数の領域の間の、空間的又は時間的な解像度を示す、
   請求項１に記載の方法。
3. 前記メディアコンテンツは１つ以上の３６０度ピクチャを含む、請求項１又は２に記載の方法。
4. 前記一連のインジケータは、不均一インジケータマスクのそれぞれのビット位置に符号化される、請求項１から３のいずれかに記載の方法。
5. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含むメモリとを備える装置であって、前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって実行されると、請求項１から４のいずれかに記載の方法を前記装置に遂行させるように構成される、装置。
6. 装置の少なくとも１つのプロセッサによって実行されると、請求項１から４のいずれかに記載の方法を前記装置に遂行させるように構成されるコンピュータプログラムコードを含む、コンピュータプログラム。

Images