JP6874169B2 - コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング - Google Patents

コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング Download PDF

Info

Publication number
JP6874169B2
JP6874169B2 JP2019571692A JP2019571692A JP6874169B2 JP 6874169 B2 JP6874169 B2 JP 6874169B2 JP 2019571692 A JP2019571692 A JP 2019571692A JP 2019571692 A JP2019571692 A JP 2019571692A JP 6874169 B2 JP6874169 B2 JP 6874169B2
Authority
JP
Japan
Prior art keywords
regions
region
video data
virtual reality
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019571692A
Other languages
English (en)
Other versions
JP2020526958A (ja
Inventor
ワン、イェ−クイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2020526958A publication Critical patent/JP2020526958A/ja
Priority to JP2021024259A priority Critical patent/JP2021100256A/ja
Application granted granted Critical
Publication of JP6874169B2 publication Critical patent/JP6874169B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G06T17/10—Constructive solid geometry [CSG] using solid primitives, e.g. cylinders, cubes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T19/00—Manipulating 3D models or images for computer graphics
    • G06T19/003—Navigation within 3D models or images
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T19/00—Manipulating 3D models or images for computer graphics
    • G06T19/006—Mixed reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/167—Position within a video image, e.g. region of interest [ROI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H04N23/698—Control of cameras or camera modules for achieving an enlarged field of view, e.g. panoramic image capture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2200/00—Indexing scheme for image data processing or generation, in general
    • G06T2200/04—Indexing scheme for image data processing or generation, in general involving 3D image data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10016—Video; Image sequence
    • G06T2207/10021—Stereoscopic video; Stereoscopic image sequence

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Graphics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Geometry (AREA)
  • Databases & Information Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

[0001] 本願は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ISO based media file format）および／またはＩＳＯＢＭＦＦから導出されたファイルフォーマットのような、１つまたは複数のメディアファイルフォーマットにおける仮想現実（ＶＲ：virtual reality）ビデオコンテンツのストレージに関する。例えば、本願は、いくつかの例では１つまたは複数のＶＲビデオの具体的な詳細を含むＶＲビデオコンテンツの識別子を、後方互換性のある方法でシグナリングするための方法およびシステムに関する。
[0002] ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、ＳＶＣ（Scalable Video Coding）として知られているそれのスケーラブルビデオコーディングとＭＶＣ（Multiview Video Coding）拡張であるそれのマルチビュービデオコーディング拡張とを含むＩＴＵ−Ｔ Ｈ．２６４またはＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣ、並びに、それのスケーラブルコーディング拡張（すなわち、スケーラブル高効率ビデオコーディング、ＳＨＶＣ）とマルチビュー拡張（すなわち、マルチビュー高効率ビデオコーディング、ＭＶ−ＨＥＶＣ）を含むＩＴＵ−Ｔ Ｈ．２６５およびＩＳＯ／ＩＥＣ ２３００８−２としても知られている高効率ビデオコーディング（ＨＥＶＣ）を含む。
[0003] 仮想現実（ＶＲ）は、一見リアルなまたは物理的な方法で相互作用することができる、コンピュータによって生成された３次元の環境を表す。仮想現実プレゼンテーションは、３６０度のビューを包含するビデオを含むことができる。様々な例では、利用可能な３６０度の領域は、特別な意味を持つものとして指定され示されることができる。例えば、コンテンツクリエイターは、閲覧者が注目すべき領域（例えば、ビデオの「ディレクターズカット」）を定義することができる。別の例では、ある領域が統計的に最も頻繁に閲覧されたものとして示されることができる。
[0004] 様々な実装では、推奨ビューポート（recommend viewport）のソースおよび性質、並びに複数の推奨ビューポート間の優先度のような領域情報を指定するためのシステムおよび方法が提供される。様々な実装では、コンピュータで実施される方法を含む、方法、装置、および／または非一時的コンピュータ可読媒体は、仮想現実ビデオデータを処理するための技法を実装することができる。これらの技法は、仮想現実ビデオデータを取得することを含むことができ、ここで、仮想現実ビデオデータは、仮想環境の３６０度ビューを表現する。技法は、仮想現実ビデオデータの領域を決定することをさらに含むことができ、ここで、領域は、３６０度ビューのサブセクションを含む。技法は、領域のためのデータ構造を生成することをさらに含むことができ、データ構造は、領域を記述するパラメータを含み、ここにおいて、パラメータは、領域に関連付けられたソースを示すパラメータを含む。技法は、仮想現実ビデオデータを記憶するためのファイルを生成することをさらに含むことができる。技法は、ファイルに仮想現実ビデオデータを記憶することをさらに含むことができる。技法は、ファイルにデータ構造を記憶することをさらに含むことができる。
[0005] いくつかの態様では、領域は、仮想現実ビデオデータを閲覧しているとき、ビューポートとして使用されることができる。
[0006] いくつかの態様では、ファイルは、コンテナファイルであり、ここで、コンテナファイルは、フォーマットに従って編成され、データ構造は、フォーマットによって記述されたボックス構造に記憶される。いくつかの態様では、ボックス構造中の領域数の値（a number of regions value）は、１より大きくなることが可能である。これらの態様では、仮想現実ビデオデータが１より多い領域を含むとき、領域および１より多い領域のためのパラメータは、同じタイムドメタデータトラック（timed metadata track）に記憶されることができる。いくつかの態様では、ボックス構造中の領域数の値は、１に限定される。これらの態様は、仮想現実ビデオデータが１より多い領域を含むとき、１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される。
[0007] いくつかの態様では、仮想現実ビデオデータは、符号化されたビットストリームとしてファイルに記憶される。これらの態様では、データ構造は、符号化されたビットストリームのメッセージ要素に記憶される。
[0008] いくつかの態様では、領域に関連付けられたソースは、コンテンツクリエイターである。いくつかの態様では、領域に関連付けられたソースは、領域が仮想現実ビデオデータの最も多く閲覧された（most viewed）領域であることを示す。
[0009] 本発明の例示的な実施形態が、以下の図面を参照して下記に詳細に説明される。
[0010] 図１は、符号化デバイスおよび復号デバイスを含むシステムの例を図示するブロック図である。 [0011] 図２は、ビデオプレゼンテーションのためのデータおよびメタデータを含むＩＳＯベースメディアファイルの例を図示する。 [0012] 図３は、３６０度ビデオフレームの３次元図と、４つの大円によって指定された３６０度ビデオフレームの球領域（sphere region）とを含む。 [0013] 図４は、３６０度ビデオフレームの３次元図と、２つのヨー円（yaw circles）および２つのピッチ円（pitch circles）によって指定された３６０度ビデオフレームの球領域とを含む。 [0014] 図５は、仮想現実ビデオデータを処理するプロセスの例を図示するフローチャートである。 [0015] 図６は、例となる符号化デバイスを図示するブロック図である。 [0016] 図７は、例となる復号デバイスを図示するブロック図である。
詳細な説明
[0017] 本開示のある特定の態様および実装が以下に提供される。当業者に明らかであるように、これらの態様および実装のうちのいくつかは、単独で適用され得、それらのうちのいくつかは、組み合わせて適用され得る。以下の記述では、具体的な詳細が、説明を目的として本発明の実装の完全な理解を提供するために記載されている。しかしながら、様々な実装がこれらの具体的な詳細なしに実施され得ることは明らかであろう。これら図面および記述は、限定的なものではない。
[0018] 以下の記述は、例示的な実装のみを提供しており、本開示の範囲、適用可能性、または構成を限定することを意図しない。むしろ、例示的な実装の以下の記述は、例示的な実装を実施するために使用可能な記述を当業者に提供する。添付の特許請求の範囲に記載された本発明の趣旨および範囲から逸脱することなく、要素の機能および配置に様々な変更がなされ得ることを理解されたい。
[0019] 以下の記述では、複数の例の完全な理解を提供するために具体的な詳細が与えられる。しかしながら、それら例は、これらの具体的な詳細なしに実施され得ることが当業者によって理解されるだろう。例えば、回路、システム、ネットワーク、プロセス、および他の構成要素は、不要な詳細で例を曖昧にしないために、ブロック図形式の構成要素として示され得る。他の例では、周知の回路、プロセス、アルゴリズム、構造、および技法が、例を曖昧にすることを避けるために、不要な詳細なしで示され得る。
[0020] また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として描かれるプロセスとして記述され得ることに留意されたい。フローチャートは、動作を逐次的なプロセスとして記述し得るが、動作の多くは並列してまたは同時に行われることができる。加えて、動作の順序は並べ換えることができる。プロセスは、その動作が完了したときに終了するが、図面には含まれていない追加のステップを含んでもよい。処理は、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合には、その終了は、その関数を呼び出し関数または主関数に戻すことに対応付けることができる。
[0021] 「コンピュータ可読媒体」という用語は、ポータブルまたは非ポータブル記憶デバイス、光記憶デバイス、並びに命令および／またはデータを記憶、収容、または搬送することが可能な様々な他の媒体を含むが、それらに限定されない。コンピュータ可読媒体は、データが記憶されることができ、かつワイヤレスにまたはワイヤード接続を介して伝搬する搬送波および／または一時的電子信号を含まない、非一時的媒体を含み得るが、それらに限定されない。非一時的な媒体の例は、磁気ディスクまたはテープ、コンパクトディスク（ＣＤ）またはデジタル多目的ディスク（ＤＶＤ）のような光記憶媒体、フラッシュメモリ、メモリまたはメモリデバイスを含み得る。コンピュータ可読媒体は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、またはプログラムステートメントの任意の組み合わせを表現し得るコードおよび／または機械実行可能命令を記憶し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを渡すことおよび／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合され得る。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信、または同様のものを含む、任意の適切な手段を介して渡され、転送され、または送信され得る。
[0022] さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、または任意のそれらの組み合わせによって実装され得る。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実装されるとき、必要なタスクを行うためのプログラムコードまたはコードセグメント（例えば、コンピュータプログラム製品）は、コンピュータ可読または機械可読媒体中に記憶され得る。プロセッサは、必要なタスクを行い得る。
[0023] 仮想現実（ＶＲ）は、一見リアルなまたは物理的な方法で相互作用することができる、３次元のコンピュータによって生成された環境を表す。一般に、仮想現実環境を経験しているユーザは、頭部装着型ディスプレイ（ＨＭＤ：head-mounted display）またオプションで衣服（例えば、センサに適したグローブ）のような電子機器を、仮想空間と相互作用するために使用する。ユーザが実世界で動くと、仮想環境内でユーザが動いているという認識をそのユーザに与える、仮想環境中のレンダリングされたイメージもまた変化する。いくつかのケースでは、仮想環境は、特定の方向またはソースからサウンドが発生しているという印象をそのユーザに与える、ユーザの動きと相互に関連したサウンドを含む。仮想現実ビデオは、非常に高い品質でキャプチャおよびレンダリングされることができ、完全没入型仮想現実経験を潜在的に提供する。仮想現実アプリケーションは、ゲーミング、トレーニング、教育、スポーツビデオ、およびオンラインショッピングなどを含む。
[0024] ファイルフォーマット規格は、ＶＲビデオまたは他のタイプのビデオのような１つまたは複数のファイルにビデオ（場合によってはオーディオ）データをパッキングおよびアンパッキングするためのフォーマットを定義することができる。ファイルフォーマット規格は、動画専門家グループ（ＭＰＥＧ：Motion Picture Experts Group）ＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５で定義される）、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））ファイルフォーマット（３ＧＰＰ ＴＳ２６．２４４で定義される）、並びに、Ａｄｖａｎｃｅｄビデオコーディング（ＡＶＣ）のためのファイルフォーマットおよび高効率ビデオコーディング（ＨＥＶＣ）ファミリのビデオコーデック（両方ともＩＳＯ／ＩＥＣ１４４９６−１５で定義される）を含む、国際標準化機構（ＩＳＯ：International Organization for Standardization）ベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２で定義された、ＩＳＯＢＭＦＦ）およびＩＳＯＢＭＦＦから導出された他のファイルフォーマットを含む。ＩＳＯ／ＩＥＣ１４４９６−１２および１４４９６−１５の最新版のドラフトテキストは、それぞれ、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zip 、およびhttp://wg11.sc29.org/doc_end_user/documents/115_Geneva/wg11/w16169-v2-w16169.zipにおいて利用可能である。
[0025] ＩＳＯＢＭＦＦは、多くのコーデックカプセル化フォーマット（例えば、ＡＶＣファイルフォーマットまたは任意の他の適切なコーデックカプセル化フォーマット）、並びに、多くのマルチメディアコンテナフォーマット（例えば、ＭＰＥＧ−４ファイルフォーマット、３ＧＰＰファイルフォーマット（３ＧＰ）、ＤＶＢファイルフォーマット、または任意の他の適切なマルチメディアコンテナフォーマット）の基準として使用される。ＩＳＯＢＭＦＦベースファイルフォーマットは、ストリーミングメディアとも呼ばれる、連続的なメディアに使用されることができる。
[0026] 連続的なメディア（例えば、オーディオおよびビデオ）に加えて、静的メディア（例えば、画像）およびメタデータは、ＩＳＯＢＭＦＦに適合するファイルに記憶されることができる。ＩＳＯＢＭＦＦに従って構造化されたファイルは、受信したリアルタイムメディアストリームの記録のための、または他の用途のための、ストリーミングされるべきコンテンツのためのコンテナとして（その場合、コンテナはパケット化命令を含む）、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）のためのセグメントとして、ローカルメディアファイル再生、遠隔ファイルの漸進的ダウンロードを含む、多くの目的のために使用され得る。
[0027] ボックスは、ＩＳＯＢＭＦＦにおける基本のシンタックス構造である。ボックスは、４文字のコーディングボックスタイプ、ボックスのバイトカウント、およびペイロードを含む。ＩＳＯＢＭＦＦファイルは、一連のボックスを含み、ボックスは、他のボックスを含み得る。ムービーボックス（「ｍｏｏｖ」）は、ファイル中に存在する連続的なメディアストリームについてのメタデータを含み、それら各々がトラックとしてファイル中に表現される。トラックについてのメタデータは、トラックボックス（「ｔｒａｋ」）中に封入され、一方トラックのメディアコンテンツは、メディアデータボックス（「ｍｄａｔ」）に封入されるか、または直接別個のファイルに封入される。トラックについてのメディアコンテンツは、オーディオまたはビデオアクセスユニットのような、一連のサンプルを含む。
[0028] ＩＳＯＢＭＦＦは、以下のタイプのトラック：基本のメディアストリームを含むメディアトラック、メディア送信命令を含むかあるいは受信されたパケットストリームを表現するかのいずれかであるヒントトラック、および時間同期メタデータを備えるタイムドメタデータトラック、を指定する。
[0029] 当初はストレージのために設計されたものであるが、ＩＳＯＢＭＦＦは、（例えば漸進的なダウンロードまたはＤＡＳＨのための）ストリーミングに非常に有用であることが分かった。ストリーミングを目的として、ＩＳＯＢＭＦＦで定義されたムービーフラグメントが使用されることができる。
[0030] 各トラックについてのメタデータは、サンプル記述エントリのリストを含み、各々がそのトラック中で使用されるコーディングまたはカプセル化フォーマット、およびそのフォーマットを処理するのに必要な初期化データを提供する。各サンプルは、トラックのサンプル記述エントリのうちの１つに関連する。
[0031] ＩＳＯＢＭＦＦは、様々なメカニズムを用いてサンプル固有のメタデータを特定することを可能にする。サンプルテーブルボックス（「ｓｔｂｌ」）内の特定のボックスは、共通のニーズに答えるよう規格化されている。例えば、Ｓｙｎｃサンプルボックス（「ｓｔｓｓ」）は、トラックのランダムアクセスサンプルをリスト化するために使用される。サンプルグルーピングメカニズムは、ファイル中にサンプルグループ記述エントリとして指定された同じプロパティを共有するサンプルのグループへの４文字のグルーピングタイプに従ったサンプルのマッピングを可能にする。いくつかのグルーピングタイプがＩＳＯＢＭＦＦ中で指定される。
[0032] より多くのデバイスおよびシステムがデジタルビデオデータを消費する能力を消費者に提供するにつれて、効率的なビデオコーディング技法に対する必要性がより重要になる。ビデオコーディングは、デジタルビデオデータ中に存在する大量のデータを処理するのに必要なストレージおよび送信要件を低減する必要がある。様々なビデオコーディング技法は、高いビデオ品質を維持しつつ、より低いビットレートを使用する形式にビデオデータを圧縮するために使用され得る。
[0033] 図１は、符号化デバイス１０４と復号デバイス１１２とを含む、システム１００の例を図示するブロック図である。符号化デバイス１０４はソースデバイスの一部であり得、復号デバイス１１２は受信デバイスの一部であり得る。ソースデバイスおよび／または受信デバイスは、モバイルまたは固定の電話ハンドセット（例えば、スマートフォン、セルラ電話、または同様のもの）、デスクトップコンピュータ、ラップトップまたはノートブックコンピュータ、タブレットコンピュータ、セットトップボックス、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレイヤ、ビデオゲーム機、ビデオストリーミングデバイスのような電子デバイス、または任意の他の適切な電子デバイスを含み得る。いくつかの例では、ソースデバイスおよび受信デバイスは、ワイヤレス通信のための１つまたは複数のワイヤレストランシーバを含み得る。本明細書で説明されるコーディング技法は、（例えば、インターネットを介した）ストリーミングビデオ送信、テレビ放送または送信、データ記憶媒体上での記憶のためのデジタルビデオの符号化、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションを含む、様々なマルチメディアアプリケーションにおけるビデオコーディングに適用可能である。いくつかの例では、システム１００は、ビデオ会議、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、ゲーミング、および／またはビデオ電話などのアプリケーションをサポートするために、一方向または双方向のビデオ送信をサポートすることができる。
[0034] 符号化デバイス１０４（またはエンコーダ）は、符号化されたビデオビットストリームを生成するために、ビデオコーディング規格またはプロトコルを使用して、仮想現実ビデオデータを含むビデオデータを符号化するために使用されることができる。ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、並びに、それぞれ、ＳＶＣおよびＭＶＣとして知られているそれのスケーラブルビデオコーディング拡張とマルチビュービデオコーディング拡張とを含むＩＴＵ−Ｔ Ｈ．２６４（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）を含むより最近のビデオコーディング規格、高効率ビデオコーディング（ＨＥＶＣ）は、ＩＴＵ−Ｔビデオコーディング専門家グループ（ＶＣＥＧ：Video Coding Experts Group）およびＩＳＯ／ＩＥＣ動画専門家グループ（ＭＰＥＧ）のビデオコーディング共同研究部会（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）により完成した。ＨＥＶＣへの様々な拡張は、マルチレイヤビデオコーディングに対応し、かつＪＣＴ−ＶＣによっても開発されており、ＭＶ−ＨＥＶＣと呼ばれるＨＥＶＣへのマルチビュー拡張、およびＳＨＶＣと呼ばれるＨＥＶＣへのスケーラブル拡張、または任意の他の適切なコーディングプロトコルを含む。
[0035] 本明細書に記述される実装は、ＨＥＶＣ規格またはその拡張を使用して、複数の例を記述する。しかしながら、本明細書に記述される技法およびシステムはまた、ＡＶＣ、ＭＰＥＧ、その拡張のような他のコーディング規格、あるいは、既に利用可能なまたはまだ利用可能ではない、または開発されていない他の適切なコーディング規格にも適用可能であり得る。従って、本明細書に記述される技法およびシステムは、特定のビデオコーディング規格を参照して記述され得るが、当業者であれば、その記述がその特定の規格にのみ適用されるものと解釈されるべきではないことを理解するだろう。
[0036] ビデオソース１０２は、符号化デバイス１０４にビデオデータを提供し得る。ビデオソース１０２は、ソースデバイスの一部であり得、またはソースデバイス以外のデバイスの一部であり得る。ビデオソース１０２は、ビデオキャプチャデバイス（例えば、ビデオカメラ、カメラフォン、ビデオフォン、または同様のもの）、記憶されたビデオを含むビデオアーカイブ、ビデオデータを提供するビデオサーバまたはコンテンツプロバイダ、ビデオサーバまたはコンテンツプロバイダからのビデオを受信するビデオフィードインターフェース、コンピュータグラフィックビデオデータを生成するためのコンピュータグラフィックシステム、このようなソースの組み合わせ、または任意の他の適切なビデオソースを含み得る。ビデオソース１０２の一例は、インターネットプロトコルカメラ（ＩＰカメラ）を含むことができる。ＩＰカメラは、監視、ホームセキュリティ、または他の適切なアプリケーションのために使用されることができる、デジタルビデオカメラの一種である。アナログ閉回路テレビ（ＣＣＴＶ：closed circuit television）カメラとは異なり、ＩＰカメラは、コンピュータネットワークおよびインターネットを介してデータを送受信することができる。
[0037] ビデオソース１０２からのビデオデータは、１つまたは複数の入力ピクチャまたはフレームを含み得る。ピクチャまたはフィルムは、ビデオの一部である静止画像である。符号化デバイス１０４のエンコーダエンジン１０６（すなわち、エンコーダ）は、符号化されたビデオビットストリームを生成するためにビデオデータを符号化する。いくつかの例では、符号化されたビデオビットストリーム（すなわち、「ビデオビットストリーム」または「ビットストリーム」）は、一連の１つまたは複数のコーディングされたビデオシーケンスである。コーディングされたビデオシーケンス（ＣＶＳ）は、ある特定の特性を有しかつベースレイヤ中にランダムアクセスポイントピクチャを有するアクセスユニット（ＡＵ）から開始し、ある特定の特性を有しかつベースレイヤ中にランダムアクセスポイントピクチャを有する次のＡＵまででありかつそれを含まない、一連のＡＵを含む。例えば、ＣＶＳを開始するランダムアクセスポイントピクチャのある特定の特性は、１に等しいＲＡＳＬフラグ（例えば、NoRaslOutputFlag）を含み得る。そうでなければ、（０に等しいＲＡＳＬフラグを有する）ランダムアクセスポイントピクチャは、ＣＶＳを開始しない。アクセスユニット（ＡＵ）は、１つまたは複数のコーディングされたピクチャと、同じ出力時間を共有するコーディングされたピクチャに対応する制御情報とを含む。複数のピクチャのコーディングスライスは、ビットストリームレベルで、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットと呼ばれるデータユニットにカプセル化される。例えば、ＨＥＶＣビデオビットストリームは、ＮＡＬユニットを含む１つまたは複数のＣＶＳを含み得る。ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとを含む、２つの種類のＮＡＬユニットがＨＥＶＣ規格に存在する。ＶＣＬ ＮＡＬユニットは、コーディングされたピクチャデータの１つのスライスまたはスライスセグメント（以下で説明される）を含み、非ＶＣＬ ＮＡＬユニットは、１つまたは複数のコーディングされたピクチャに関連する制御情報を含む。
[0038] ＮＡＬユニットは、ビデオ中のピクチャのコーディングされた表現のような、ビデオデータのコーディングされた表現を形成する一連のビット（例えば、符号化されたビデオビットストリーム、ビットストリームのＣＶＳ、または同様のもの）を含み得る。エンコーダエンジン１０６は、各ピクチャを複数のスライスに分割することによって、ピクチャのコーディングされた表現を生成する。スライスは次いで、ルーマサンプルおよびクロマサンプルのコーディングツリーブロック（ＣＴＢ：coding tree blocks）に分割される。ルーマサンプルのＣＴＢおよびクロマサンプルの１つまたは複数のＣＴＢは、サンプルのためのシンタックスと共に、コーディングツリーユニット（ＣＴＵ：coding tree unit）と呼ばれる。ＣＴＵは、ＨＥＶＣ符号化のための基本処理ユニットである。ＣＴＵは、可変サイズの複数のコーディングユニット（ＣＵ：coding units）に分けられ得る。ＣＵは、コーディングブロック（ＣＢ：coding blocks）と呼ばれるルーマおよびクロマサンプル配列を含む。
[0039] ルーマおよびクロマＣＢは、予測ブロック（ＰＢ：prediction blocks）にさらに分けられることができる。ＰＢは、インター予測のために同じ動きパラメータを使用するルーマまたはクロマ成分のサンプルのブロックである。ルーマＰＢおよび１つまたは複数のクロマＰＢは、関連するシンタックスと共に、予測ユニット（ＰＵ：prediction unit）を形成する。動きパラメータのセットは、ＰＵごとにビットストリーム中でシグナリングされ、ルーマＰＢおよび１つまたは複数のクロマＰＢのインター予測のために使用される。ＣＢはまた、１つまたは複数の変換ブロック（ＴＢ：transform blocks）に分割され得る。ＴＢは、予測残差信号をコーディングするために同じ２次元変換が適用される、色成分のサンプルの正方形ブロックを表現する。変換ユニット（ＴＵ：transform unit）は、ルーマおよびクロマサンプルのＴＢと、対応するシンタックス要素とを表現する。
[0040] ＣＵのサイズは、コーディングノードのサイズに対応し、形状が正方形であり得る。例えば、ＣＵのサイズは、８×８サンプル、１６×１６サンプル、３２×３２サンプル、６４×６４サンプル、または対応するＣＴＵのサイズまでの任意の他の適切なサイズであり得る。「Ｎ×Ｎ」というフレーズは、本明細書では、縦および横の寸法の観点から、ビデオブロックのピクセル寸法（例えば、８ピクセル×８ピクセル）を指すために使用される。ブロック中のピクセルは、行および列に配置され得る。いくつかの実施形態では、ブロックは、横方向に、縦方向と同じ数のピクセルを有していない可能性がある。ＣＵに関連付けられたシンタックスデータは、例えば、１つまたは複数のＰＵへのＣＵの分割を記述し得る。分割モードは、ＣＵがイントラ予測モード符号化されたか、またはインター予測モード符号化されたかの間で異なり得る。ＰＵは、形状が非正方形に分割され得る。ＣＵに関連付けられたシンタックスデータは、例えば、ＣＴＵに従った１つまたは複数のＰＵへのＣＵの分割も記述し得る。ＴＵは、形状が正方形または非正方形であり得る。
[0041] ＨＥＶＣ規格によると、変換ユニット（ＴＵ）を使用して変換が行われ得る。ＴＵは、ＣＵによって変わり得る。ＴＵは、所与のＣＵ内のＰＵのサイズに基づいて、サイジングされ得る。ＴＵは、ＰＵと同じサイズであるかそれより小さくなり得る。いくつかの例では、ＣＵに対応する残差サンプルは、残差４分木（ＲＱＴ：residual quad tree）として知られている４分木構造を使用して、より小さいユニットに細分され（subdivided）得る。ＲＱＴのリーフノードは、ＴＵに対応し得る。ＴＵに関連付けられたピクセル差分値は、変換係数を作成するために変換され得る。変換係数は次いで、エンコーダエンジン１０６によって量子化され得る。
[0042] 一旦ビデオデータのピクチャがＣＵに分割されると、エンコーダエンジン１０６は、予測モードを使用して各ＰＵを予測する。予測は次いで、残差を得るために当初のビデオデータから差し引かれる（以下で説明される）。各ＣＵについて、予測モードは、シンタックスデータを使用してビットストリームの内部でシグナリングされ得る。予測モードは、イントラ予測（またはイントラピクチャ予測）、あるいはインター予測（またはインターピクチャ予測）を含み得る。イントラ予測を使用して、各ＰＵは、例えば、ＰＵの平均値を発見するためのＤＣ予測、平面をＰＵに合わせるための平面予測、隣接するデータから外挿するための方向予測、または任意の他の適切なタイプの予測を使用して、同じピクチャ中の隣接するイメージデータから予測される。インター予測を使用すると、各ＰＵは、（出力順に現在のピクチャの前または後の）１つまたは複数の参照ピクチャ中のイメージデータからの動き補償予測を使用して予測される。ピクチャエリアを、インターピクチャ予測を使用してコーディングするか、またはイントラピクチャ予測を使用してコーディングするかの決定は、例えば、ＣＵレベルにおいて行われ得る。いくつかの例では、ピクチャの１つまたは複数のスライスは、スライスタイプを割り当てられる。スライスタイプは、Ｉスライス、Ｐスライス、およびＢスライスを含む。Ｉスライス（イントラフレーム、単独で復号可能）は、イントラ予測によってのみコーディングされるピクチャのスライスであり、従って、Ｉスライスが、フレーム内のデータのみを要求してスライスの任意のブロックを予測するため、単独で復号可能である。Ｐスライス（一方向性の予測フレーム）は、イントラ予測で、および一方向性のインター予測でコーディングされ得るピクチャのスライスである。Ｐスライス内の各ブロックは、イントラ予測またはインター予測のいずれかでコーディングされる。インター予測が適用されるとき、ブロックは、１つの参照ピクチャによってのみ予測され、従って、参照サンプルは、１つのフレームの１つの参照領域からのみとなる。Ｂスライス（双方向性の予測フレーム）は、イントラ予測およびインター予測でコーディングされ得るピクチャのスライスである。Ｂスライスのブロックは、２つの参照ピクチャから双方向で予測され得、ここで、各ピクチャは、１つの参照領域に寄与し、２つの参照領域のサンプルセットは、双方向性の予測ブロックの予測信号を作成するために、重み付け（例えば、等しい重みで）される。上述されたように、１つのピクチャのスライスは、単独でコーディングされる。いくつかのケースでは、ピクチャは、単に１つのスライスとしてコーディングされ得る。
[0043] ＰＵは、予測プロセスに関するデータを含み得る。例えば、ＰＵがイントラ予測を使用して符号化されたとき、ＰＵは、ＰＵのためのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインター予測を使用して符号化されたとき、ＰＵは、ＰＵのための動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（例えば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルのための参照ピクチャリスト（例えば、リスト０、リスト１、またはリストＣ）を記述し得る。
[0044] 符号化デバイス１０４は次いで、変換および量子化を行い得る。例えば、予測に続いて、エンコーダエンジン１０６は、ＰＵに対応する残差値を算出し得る。残差値は、ピクセル差分値を備え得る。予測が行われた後に残り得る任意の残差データは、ブロック変換を使用して変換され、これは、離散コサイン変換、離散サイン変換、整数変換、ウェーブレット変換、または他の適切な変換関数に基づき得る。いくつかのケースでは、１つまたは複数のブロック変換（例えば、サイズ３２×３２、１６×１６、８×８、４×４、または同様のもの）が、各ＣＵ中の残差データに適用され得る。いくつかの実施形態では、ＴＵは、エンコーダエンジン１０６によって実装される変換および量子化プロセスのために使用され得る。１つまたは複数のＰＵを有する所与のＣＵは、１つまたは複数のＴＵも含み得る。以下でさらに詳細に説明されるように、残差値は、ブロック変換を使用して変換係数へと変換され得、次いで、エントロピーコーディングのための直列化された変換係数（serialized transform coefficients）を作成するために、ＴＵを使用して量子化およびスキャンされ得る。
[0045] いくつかの実施形態では、ＣＵのＰＵを使用するイントラ予測またはインター予測コーディングに続いて、エンコーダエンジン１０６は、ＣＵのＴＵについての残差データを算出し得る。ＰＵは、空間領域（またはピクセル領域）中のピクセルデータを備え得る。ＴＵは、ブロック変換の適用後の変換領域中の係数を備え得る。前述されたように、残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分値に対応し得る。エンコーダエンジン１０６は、ＣＵのための残差データを含むＴＵを形成し得、次いで、ＣＵのための変換係数を作成するためにＴＵを変換し得る。
[0046] エンコーダエンジン１０６は、変換係数の量子化を行い得る。量子化は、係数を表現するために使用されるデータの量を低減するために、変換係数を量子化することによって、さらなる圧縮を提供する。例えば、量子化は、係数のいくつかまたは全てに関連付けられたビット深度を低減し得る。一例では、ｎビットの値を有する係数は、量子化中にｍビットの値に切り捨てられ得、ｎは、ｍよりも大きい。
[0047] 一旦量子化が行われると、コーディングされたビットストリームは、量子化された変換係数、予測情報（例えば、予測モード、動きベクトル、または同様のもの）、分割情報、および他のシンタックスデータのような任意の他の適切なデータを含む。コーディングされたビデオビットストリームの異なる要素は次いで、エンコーダエンジン１０６によってエントロピー符号化され得る。いくつかの例では、エンコーダエンジン１０６は、エントロピー符号化されることができる直列化されたベクトルを作成するために、量子化された変換係数をスキャンするための予め定義されたスキャン順序を利用し得る。いくつかの例では、エンコーダエンジン１０６は、適応スキャンを実行し得る。ベクトル（例えば、１次元ベクトル）を形成するために、量子化された変換係数をスキャンした後、エンコーダエンジン１０６は、ベクトルをエントロピー符号化し得る。例えば、エンコーダエンジン１０６は、コンテキスト適応可変長コーディング、コンテキスト適応バイナリ算術コーディング、シンタックスベースコンテキスト適応バイナリ算術コーディング、確率間隔分割エントロピーコーディング、または別の適切なエントロピー符号化技法を使用し得る。
[0048] 符号化デバイス１０４の出力部１１０は、通信リンク１２０を介して、符号化されたビデオビットストリームデータを構成するＮＡＬユニットを受信デバイスの復号デバイス１１２に送り得る。復号デバイス１１２の入力部１１４は、ＮＡＬユニットを受信し得る。通信リンク１２０は、ワイヤレスネットワーク、ワイヤードネットワーク、またはワイヤードネットワークとワイヤレスネットワークとの組み合わせによって提供されたチャネルを含み得る。ワイヤレスネットワークは、任意のワイヤレスインターフェースまたは複数のワイヤレスインターフェースの組み合わせを含み得、かつ任意の適切なワイヤレスネットワーク（例えば、インターネットまたは他のワイドエリアネットワーク、パケットベースネットワーク、ＷｉＦｉ（登録商標）、無線周波数（ＲＦ）、ＵＷＢ、ＷｉＦｉ−Ｄｉｒｅｃｔ、セルラ、ロングタームエボリューション（ＬＴＥ（登録商標））、ＷｉＭａｘ（登録商標）、または同様のもの）を含み得る。ワイヤードネットワークは、任意のワイヤードインターフェース（例えば、ファイバー、イーサネット（登録商標）、電力線イーサネット、同軸ケーブルを介するイーサネット、デジタル信号線（ＤＳＬ）、または同様のもの）を含み得る。ワイヤードおよび／またはワイヤレスネットワークは、基地局、ルータ、アクセスポイント、ブリッジ、ゲートウェイ、スイッチ、または同様のもののような様々な機器を使用して実装され得る。符号化されたビデオビットストリームデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、受信デバイスに送信され得る。
[0049] いくつかの例では、符号化デバイス１０４は、符号化されたビデオビットストリームデータをストレージ１０８に記憶し得る。出力部１１０は、エンコーダエンジン１０６から、またはストレージ１０８から、符号化されたビデオビットストリームデータを検索し得る。ストレージ１０８は、様々な分散されたまたはローカルにアクセスされたデータ記憶媒体のうちの任意のものを含み得る。例えば、ストレージ１０８は、ハードドライブ、ストレージディスク、フラッシュメモリ、揮発性または不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体を含み得る。
[0050] 復号デバイス１１２の入力部１１４は、符号化されたビデオビットストリームデータを受信し、デコーダエンジン１１６に、またはデコーダエンジン１１６によって後に使用するためにストレージ１１８に、ビデオビットストリームデータを提供し得る。デコーダエンジン１１６は、（例えば、エントロピーデコーダを使用して）エントロピー復号し、符号化されたビデオデータを構成する１つまたは複数のコーディングされたビデオシーケンスの要素を抽出することによって、符号化されたビデオビットストリームデータを復号し得る。デコーダエンジン１１６は次いで、符号化されたビデオビットストリームデータを再スケーリング（rescale）し、それに対して逆変換を行い得る。残差データは次いで、デコーダエンジン１１６の予測ステージに渡される。デコーダエンジン１１６は次いで、ピクセルのブロック（例えば、ＰＵ）を予測する。いくつかの例では、予測は、逆変換の出力（残差データ）に追加される。
[0051] 復号デバイス１１２は、復号されたビデオをビデオ宛先デバイス１２２に出力し得、それは、復号されたビデオデータをコンテンツの消費者に表示するためのディスプレイまたは他の出力デバイスを含み得る。いくつかの態様では、ビデオ宛先デバイス１２２は、復号デバイス１１２を含む受信デバイスの一部であり得る。いくつかの態様では、ビデオ宛先デバイス１２２は、受信デバイス以外の別個のデバイスの一部であり得る。
[0052] ＳＥＩ（Supplemental Enhancement Information）メッセージは、ビデオビットストリームに含められ得る。例えば、ＳＥＩメッセージは、復号デバイス１１２によってビットストリームを復号するために、重要ではない情報（例えば、メタデータ）を搬送するために使用され得る。この情報は、復号された出力の表示または処理を改善する際に有益である（例えば、このような情報が、コンテンツの視認性を改善するためにデコーダ側エンティティによって使用される可能性がある）。
[0053] いくつかの実施形態では、ビデオ符号化デバイス１０４および／またはビデオ復号デバイス１１２は、それぞれ、オーディオ符号化デバイスおよびオーディオ復号デバイスと一体化され得る。ビデオ符号化デバイス１０４および／またはビデオ復号デバイス１１２はまた、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェアまたはこれらの任意の組み合わせのような、上述されたコーディング技法を実装するのに必要な他のハードウェアまたはソフトウェアを含み得る。ビデオ符号化デバイス１０４およびビデオ復号デバイス１１２は、それぞれのデバイスにおいて、複合エンコーダ／デコーダ（コーデック）の一部として一体化され得る。
[0054] ＨＥＶＣ規格への拡張は、ＭＶ−ＨＥＶＣと呼ばれるマルチビュービデオコーディング拡張と、ＳＨＶＣと呼ばれるスケーラブルビデオコーディング拡張とを含む。ＭＶ−ＨＥＶＣおよびＳＨＶＣ拡張は、レイヤードコーディングの概念を共有しており、異なるレイヤが、符号化されたビデオビットストリーム中に含まれる。コーディングされたビデオシーケンス中の各レイヤは、一意のレイヤ識別子（ＩＤ）によってアドレスされる。レイヤＩＤは、ＮＡＬユニットが関連付けられているレイヤを識別するために、ＮＡＬユニットのヘッダ中に存在し得る。ＭＶ−ＨＥＶＣでは、異なるレイヤは、通常、ビデオビットストリーム中の同じシーンの異なるビューを表現することができる。ＳＨＶＣでは、異なる空間解像度（またはピクチャ解像度）で、または異なる再構成忠実度でビデオビットストリームを表現する異なるスケーラブルレイヤが提供される。スケーラブルレイヤは、（レイヤＩＤ＝０を有する）ベースレイヤと、（レイヤＩＤ＝１，２，．．．ｎを有する）１つまたは複数のエンハンスメントレイヤと、を含み得る。ベースレイヤは、ＨＥＶＣの最初のバーションのプロファイルに適合し得、ビットストリーム中の最下位の利用可能なレイヤを表現する。エンハンスメントレイヤは、ベースレイヤと比較して増大した空間解像度、時間解像度またはフレームレート、および／または再構成忠実度（または品質）を有している。エンハンスメントレイヤは、階層的に編成され、下位レイヤに依存することも（またはしないことも）あり得る。いくつかの例では、異なるレイヤは、単一規格化コーデックを使用してコーディングされ得る（例えば、全てのレイヤが、ＨＥＶＣ、ＳＨＶＣ、または他のコーディング規格を使用して符号化される）。いくつかの例では、異なるレイヤは、多規格コーデックを使用してコーディングされ得る。例えば、ベースレイヤは、ＡＶＣを使用してコーディングされ得、一方、１つまたは複数のエンハンスメントレイヤは、ＨＥＶＣ規格に対するＳＨＶＣおよび／またはＭＶ−ＨＥＶＣ拡張を使用してコーディングされ得る。通常、レイヤはＶＣＬ ＮＡＬユニットのセットと、対応する非ＶＣＬ ＮＡＬユニットのセットとを含む。ＮＡＬユニットは、特定のレイヤＩＤ値を割り当てられる。レイヤが下位レイヤに依存するという意味では、レイヤは階層的であることができる。
[0055] 前述されたように、ＨＥＶＣビットストリームは、ＶＣＬ ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットを含む、ＮＡＬユニットのグループを含む。非ＶＣＬ ＮＡＬユニットは、他の情報に加えて、符号化されたビデオビットストリームに関する高いレベルの情報を有するパラメータセットを含み得る。例えば、パラメータセットは、ビデオパラメータセット（ＶＰＳ：video parameter set）、シーケンスパラメータセット（ＳＰＳ：sequence parameter set）、およびピクチャパラメータセット（ＰＰＳ：picture parameter set）を含み得る。パラメータセットの目的の例は、ビットレート効率、エラー耐性、およびシステムレイヤインターフェースの提供を含む。各スライスは、復号デバイス１１２がスライスを復号するために使用し得る情報にアクセスするために、単一のアクティブなＰＰＳ、ＳＰＳ、およびＶＰＳを参照する。識別子（ＩＤ）は、ＶＰＳ ＩＤ、ＳＰＳ ＩＤ、およびＰＰＳ ＩＤを含む、各パラメータセットのためにコーディングされ得る。ＳＰＳは、ＳＰＳ ＩＤおよびＶＰＳ ＩＤを含む。ＰＰＳは、ＰＰＳ ＩＤおよびＳＰＳ ＩＤを含む。各スライスヘッダは、ＰＰＳ ＩＤを含む。ＩＤを使用して、アクティブなパラメータセットが所与のスライスに対して識別されることができる。
[0056] ＶＣＬ ＮＡＬユニットは、コーディングされたビデオビットストリームを形成するコーディングされたピクチャデータを含む。ＨＥＶＣ規格において様々なタイプのＶＣＬ ＮＡＬユニットが定義される。シングルレイヤビットストリームでは、最初のＨＥＶＣ規格で定義されているように、ＡＵに含まれるＶＣＬ ＮＡＬユニットは同じＮＡＬユニットタイプ値を有し、ＮＡＬユニットタイプ値が、ＡＵのタイプと、ＡＵ内のコーディングされたピクチャのタイプとを定義する。例えば、特定のＡＵのＶＣＬ ＮＡＬユニットは、瞬時復号リフレッシュ（ＩＤＲ：instantaneous decoding refresh）ＮＡＬユニット（値１９）を含み得、そのＡＵをＩＤＲ ＡＵにし、かつＡＵのコーディングされたピクチャをＩＤＲピクチャにする。ＶＣＬ ＮＡＬユニットの所与のタイプは、ＶＣＬ ＮＡＬユニット中に含まれる、ピクチャまたはその一部に関連する（例えば、ＶＣＬ ＮＡＬユニット中のピクチャのスライスまたはスライスセグメント）。ＨＥＶＣ規格において、先頭ピクチャ、後端ピクチャ、およびイントラランダムアクセス（ＩＲＡＰ）ピクチャ（「ランダムアクセスピクチャ」とも呼ばれる）を含む、ピクチャの３つの種類が定義される。マルチレイヤビットストリームにおいて、ＡＵ内のピクチャのＶＣＬ ＮＡＬユニットは、同じＮＡＬユニットタイプ値と、同じタイプのコーディングされたピクチャとを有する。例えば、タイプＩＤＲのＶＣＬ ＮＡＬユニットを含むピクチャは、ＡＵにおけるＩＤＲピクチャであると言われる。別の例では、ＡＵがベースレイヤ（０に等しいレイヤＩＤ）においてＩＲＡＰピクチャであるピクチャを含むとき、ＡＵはＩＲＡＰ ＡＵである。
[0057] 上述されるような符号化されたビデオビットストリームは、符号化デバイス１０４から復号デバイス１１２にビットストリームを転送するために、１つまたは複数のファイルに書き込みまたはパッキングされることができる。例えば、出力部１１０は、ファイル書き込みエンジンを含み得、ビットストリームを含む１つまたは複数のファイルを生成するように構成される。出力部１１０は、１つまたは複数のファイルを通信リンク１２０上でデコーダデバイス１１２に送信することができる。代替的にまたは追加的に、１つまたは複数のファイルは、後に復号デバイス１１２に送信するために、記憶デバイス（例えば、テープ、磁気ディスク、またはハードドライブ、または何らかの他の媒体）上に記憶され得る。
[0058] デコーダデバイス１１２は、例えば、入力部１１４、ファイル解析エンジン（file parsing engine）を含むことができる。ファイル解析エンジンは、通信リンク１２０を介してまたは記憶媒体から受信したファイルを読み取ることができる。ファイル解析エンジンはさらに、ファイルからサンプルを抽出し、デコーダエンジン１１６によって復号するためにビットストリームを再構成することができる。いくつかのケースでは、再構成されたビットストリームは、エンコーダエンジン１０６によって生成されたビットストリームと同じであることができる。いくつかのケースでは、エンコーダエンジン１０６は、ビットストリームを復号するためのいくつかの可能なオプションを用いてビットストリームを生成している可能性があり、このケースでは、再構成されたビットストリームは、唯一の、または全てよりも少ない、可能なオプションを含み得る。
[0059] 上述されるような符号化されたビデオビットストリームは、ＩＳＯＢＭＦＦ、ＩＳＯＢＭＦＦから導出されたファイルフォーマット、何らかの他のファイルフォーマット、および／またはＩＳＯＢＭＦＦを含むファイルフォーマットの組み合わせ、を使用して、１つまたは複数のファイルに書き込みまたはパッケージングされることができる。１つまたは複数のファイルは、ビデオプレイヤデバイスを使用して再生されることができ、送信され次いで表示される、および／または記憶されることができる。
[0060] 図２は、ＩＳＯＢＭＦＦに従ってフォーマット化された、ビデオプレゼンテーションのためのデータおよびメタデータを含むＩＳＯベースメディアファイル２００の例を図示する。ＩＳＯＢＭＦＦは、メディアの交換、管理、編集、およびプレゼンテーションを容易にする、柔軟かつ拡張可能なフォーマットにタイムドメディア情報（timed media information）を含むように設計される。メディアのプレゼンテーションは、そのプレゼンテーションを含むシステムに対して「ローカル」であり得るか、あるいはプレゼンテーションは、ネットワークまたは他のシステム搬送メカニズムを介し得る。
[0061] ＩＳＯＢＭＦＦ規格で定義されるような「プレゼンテーション」は、多くの場合、ビデオキャプチャデバイスによって連続してキャプチャされたことによって関連している、または何らかの他の理由で関連している、一連のピクチャである。本明細書では、プレゼンテーションはまた、ムービープレゼンテーションまたはビデオプレゼンテーションとも呼ばれ得る。プレゼンテーションは、オーディオを含み得る。単一のプレゼンテーションは、１つまたは複数のファイルに含まれ得、１つのファイルが全体のプレゼンテーションのためのメタデータを含んでいる。メタデータは、タイミングおよびフレーミングデータなどの情報、記述子、ポインタ、パラメータ、およびプレゼンテーションを記述する他の情報を含む。メタデータは、ビデオおよび／またはオーディオデータ自体を含まない。メタデータを含むファイル以外のファイルは、ＩＳＯＢＭＦＦに従ってフォーマット化される必要はなく、メタデータによってこれらのファイルが参照されることができるようにフォーマット化されるだけでよい。
[0062] ＩＳＯベースメディアファイルのファイル構造は、オブジェクト指向型であり、ファイル中の個々のオブジェクトの構造は、オブジェクトのタイプから直接推測されることができる。ＩＳＯベースメディアファイル中のオブジェクトは、ＩＳＯＢＭＦＦ規格により「ボックス」と呼ばれる。ＩＳＯベースメディアファイルは、一連のボックスとして構造化され、それは、他のボックスを含むことができる。ボックスは一般に、ボックスに関するサイズおよびタイプを提供するヘッダを含む。サイズは、ヘッダ、ファイル、およびそのボックス内に含まれる全てのボックスを含む、ボックスの全体のサイズを記述する。プレイヤデバイスによって認識されないタイプを有するボックスは通常、無視またはスキップされる。
[0063] 図２の例によって図示されるように、ＩＳＯベースメディアファイル２００は、ファイルの上位レベルに、ファイルタイプボックス２１０、ムービーボックス２２０、および１つまたは複数のムービーフラグメントボックス２３０ａ、２３０ｎを含むことができる。このレベルに含まれることができるがこの例で表現されていない他のボックスは、フリースペースボックス、メタデータボックス、およびメディアデータボックスなどを含む。
[0064] ＩＳＯベースメディアファイルは、ボックスタイプ「ｆｔｙｐ」によって識別される、ファイルタイプボックス２１０を含むことができる。ファイルタイプボックス２１０は、ファイルを解析するのに最も適したＩＳＯＢＭＦＦ規格を識別する。この例における「最も（most）」とは、ＩＳＯベースメディアファイル２００が、特定のＩＳＯＢＭＦＦ規格に従ってフォーマット化されているが、この規格の他の後継（iterations）と互換性があり得ることを意味する。この最も適した規格は、メジャーブランド（major brand）と呼ばれる。プレイヤデバイスは、そのデバイスがファイルのコンテンツを復号および表示できるかどうかを決定するために、メジャーブランドを使用することができる。ファイルタイプボックス２１０はまた、ＩＳＯＢＭＦＦ規格のバージョンを示すために使用され得る、バージョン番号を含むことができる。ファイルタイプボックス２１０はまた、ファイルが互換性のある他のブランドのリストを含む、互換性のあるブランドのリストも含むことができる。ＩＳＯベースメディアファイルは、１より多くのメジャーブランドとの互換性があり得る。
[0065] ＩＳＯベースメディアファイル２００がファイルタイプボックス２１０を含むとき、１つのファイルタイプボックスのみが存在する。ＩＳＯベースメディアファイル２００は、より古いプレイヤデバイスと互換性を持たせるために、ファイルタイプボックス２１０を省略し得る。ＩＳＯベースメディアファイル２００がファイルタイプボックス２１０を含んでいないとき、プレイヤデバイスは、デフォルトのメジャーブランド（例えば、「ｍｐ４１」）、マイナーバージョン（例えば、「０」）、および互換性のあるブランド（例えば、「ｍｐ４１」）を想定することができる。ファイルタイプボックス２１０は通常、ＩＳＯベースメディアファイル２００中にできる限り早く配置される。
[0066] ＩＳＯベースメディアファイルは、プレゼンテーションのためのメタデータを含む、ムービーボックス２２０をさらに含むことができる。ムービーボックス２２０は、ボックスタイプ「ｍｏｏｖ」によって識別される。ＩＳＯ／ＩＥＣ１４４９６−１２は、プレゼンテーションが、１つのファイル中に含まれようと、複数のファイル中に含まれようと、１つのムービーボックス２２０のみを含み得ると規定している。しばしば、ムービーボックス２２０は、ＩＳＯベースメディアファイルの始端付近にある。ムービーボックス２２０は、ムービーヘッダボックス２２２を含み、かつ１つまたは複数のトラックボックス２２４、並びに他のボックスを含むことができる。
[0067] ボックスタイプ「ｍｖｈｄ」によって識別されるムービーヘッダボックス２２２はメディア独立型（media-independent）でありかつ全体としてプレゼンテーションに関する情報を含むことができる。例えば、ムービーヘッダボックス２２２は、プレゼンテーションについての作成時間、修正時間、タイムスケール、および／または持続期間などのような情報を含むことができる。ムービーヘッダボックス２２２はまた、プレゼンテーションにおける次のトラックを識別する識別子を含むことができる。例えば、識別子は、図示された例中のムービーボックス２２０によって含まれるトラックボックス２２４を指すことができる。
[0068] ボックスタイプ「ｔｒａｋ」によって識別されるトラックボックス２２４は、プレゼンテーションのためのトラックについての情報を含むことができる。プレゼンテーションは、１つまたは複数のトラックを含むことができ、ここで、各トラックは、プレゼンテーション中の他のトラックに依存しない。各トラックは、トラック中のコンテンツに特有の時間的および空間的情報を含むことができ、各トラックは、メディアボックスに関連付けられることができる。トラック中のデータはメディアデータであることができ、その場合、トラックはメディアトラックであるか、あるいは、そのデータはストリーミングプロトコルのためのパケット化情報であることができ、その場合、トラックはヒントトラックである。メディアデータは、例えば、ビデオおよびオーディオデータを含む。図示された例では、例示的なトラックボックス２２４は、トラックヘッダボックス２２４ａとメディアボックス２２４ｂとを含む。トラックボックスは、トラック参照ボックス、トラックグループボックス、エディットボックス、ユーザデータボックス、メタボックスなどのような他のボックスを含むことができる。
[0069] ボックスタイプ「ｔｋｈｄ」によって識別されるトラックヘッダボックス２２４ａは、トラックボックス２２４中に含まれるトラックの特性を指定することができる。例えば、トラックヘッダボック２２４ａは、トラックの作成時間、修正時間、持続期間、トラック識別子、レイヤ識別子、グループ識別子、ボリューム、幅、および／または高さなどを含むことができる。メディアトラックに関して、トラックヘッダボックス２２４ａは、トラックが有効であるかどうか、トラックがプレゼンテーションの一部分として再生されるべきか、またはトラックがプレゼンテーションをプレビューするために使用されることができるか、などをさらに識別することができる。トラックのプレゼンテーションは一般に、プレゼンテーションの始端にあると見なされる。トラックボックス２２４は、ここでは図示されていないが、明示的なタイムラインマップを含むことができる、エディットリストボックスを含むことができる。タイムラインマップは、特に、トラックのためのオフセット時間を指定することができ、ここで、オフセットは、トラックに対して、プレゼンテーションの始端の後の、開始時間（start time）を示す。
[0070] 図示された例では、トラックボックス２２４はまた、ボックスタイプ「ｍｄｉａ」によって識別される、メディアボックス２２４ｂも含む。メディアボックス２２４ｂは、トラック中のメディアデータについての情報およびオブジェクトを含むことができる。例えば、メディアボックス２２４ｂは、ハンドラ参照ボックスを含むことができ、それは、トラックのメィデアタイプおよびトラック中のメディアが提示されるプロセスを識別することができる。別の例として、メディアボックス２２４ｂは、メディア情報ボックスを含むことができ、それは、トラック中のメディアの特性を指定することができる。メディア情報ボックスは、サンプルの表をさらに含むことができ、ここで、各サンプルは、例えば、サンプルのためのデータのロケーションを含むメディアデータ（例えば、ビデオまたはオーディオデータ）のチャンクを記述する。サンプルのためのデータは、以下でさらに説明されるメディアデータボックス中に記憶される。多くの他のボックスと同様に、メディアボックス２２４ｂもまた、メディアヘッダボックスを含むことができる。
[0071] 図示された例では、例示的なＩＳＯベースメディアファイル２００はまた、プレゼンテーションの複数のフラグメント２３０ａ、２３０ｂ、２３０ｃ、２３０ｎも含む。フラグメント２３０ａ、２３０ｂ、２０３ｃ、２３０ｎは、ＩＳＯＢＭＦＦボックスではなく、ムービーフラグメントボックス２３２と、ムービーフラグメントボックス２３２によって参照されるメディアデータボックス２３８とを記述する。ムービーフラグメントボックス２３２およびメディアデータボックス２３８は最上位のボックスであるが、ここでは、ムービーフラグメントボックス２３２とメディアデータボックス２３８との間の関係を示すためにグループ化されている。
[0072] ボックスタイプ「ｍｏｏｆ」によって識別されるムービーフラグメントボックス２３２は、別の方法でムービーボックス２２０に記憶された追加の情報を含むことによって、プレゼンテーションを拡張することができる。ムービーフラグメントボックス２３２を使用して、プレゼンテーションが増分的に（incrementally）構築されることができる。ムービーフラグメントボックス２３２は、ムービーフラグメントヘッダボックス２３４、トラックフラグメントボックス２３６、並びに、ここでは図示されない他のボックスを含むことができる。
[0073] ボックスタイプ「ｍｆｈｄ」によって識別される、ムービーフラグメントヘッダボックス２３４は、シーケンス番号を含むことができる。プレイヤデバイスは、プレゼンテーションのためのデータの次のピースをフラグメント２３０ａが含むことを確認（verify）するためにシーケンス番号を使用することができる。いくつかのケースでは、ファイルのコンテンツ、またはプレゼンテーションのための複数のファイルが、順不同でプレイヤデバイスに提供されることがある。例えば、ネットワークパケットは、しばしば、パケットが当初に送信された順序以外の順序で到来することがある。これらのケースでは、シーケンス番号は、フラグメントにとって正しい順序を決定する際に、プレイヤデバイスを支援することができる。
[0074] ムービーフラグメントボックス２３２はまた、ボックスタイプ「ｔｒａｆ」によって識別される、１つまたは複数のトラックフラグメントボックス２３６を含むことができる。ムービーフラグメントボックス２３２は、トラックごとにゼロまたはそれより多くのトラックフラグメントのセットを含むことができる。トラックフラグメントは、ゼロまたはそれより多くのトラックラン（track runs）を含むことができ、それらの各々が、トラックについてのサンプルの連続的なラン（a contiguous run of samples）を記述する。トラックフラグメントは、トラックにサンプルを追加することに加えて、トラックに空の時間（empty time）を追加するために使用されることができる。
[0075] ボックスタイプ「ｍｄａｔ」によって識別される、メディアデータボックス２３８は、メディアデータを含む。ビデオトラックでは、メディアデータボックス２３８は、ビデオフレームを含み得る。メディアデータボックスは、代替的にまたは追加的に、オーディオデータを含むことができる。プレゼンテーションは、１つまたは複数の個々のファイルに含まれた、ゼロまたはそれより多くのメディアデータボックスを含むことができる。メディアデータは、メタデータによって記述される。図示された例では、メディアデータボックス２３８中のメディアデータは、トラックフラグメントボックス２３６に含まれるメタデータによって記述されることができる。他の例では、メディアデータボックス中のメディアデータは、ムービーボックス２２０中のメタデータによって記述されることができる。メタデータは、メディアデータボックス２３８内のメディアデータヘッダおよび／またはフリースペースがスキップされることができるように、ファイル２００内の絶対オフセット（absolute offset）によって特定のメディアデータを参照することができる。
[0076] ＩＳＯベースメディアファイル２００中の他のフラグメント２３０ｂ、２３０ｃ、２３０ｎは、第１のフラグメント２３０ａについて図示されたものに類似したボックスを含むことができる、および／または他のボックスを含むことができる。
[0077] ＩＳＯＢＭＦＦは、メディアのローカル再生をサポートすることに加えて、ネットワーク上でメディアデータをストリーミングするためのサポートを含む。１つのムービープレゼンテーションを含む１つまたは複数のファイルは、ヒントトラックと呼ばれる追加のトラックを含むことができ、それは、パケットとして１つまたは複数のファイルを形成および送信する際に、ストリーミングサーバを支援することができる命令を含む。これらの命令は、例えば、サーバが送るべきデータ（例えば、ヘッダ情報）、またはメディアデータのセグメントへの参照を含むことができる。ファイルは、異なるストリーミングプロトコルのための別個のヒントトラックを含むことができる。ヒントトラックはまた、ファイルを再フォーマットする必要なく、ファイルに追加されることができる。
[0078] メディアデータをストリーミングするための１つの方法は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介した動的アダプティブストリーミング（Dynamic Adaptive Streaming over Hypertext Transfer Protocol）、すなわち、ＤＡＳＨ（ＩＳＯ／ＩＥＣ ２３００９−１：２０１４で定義される）である。ＤＡＳＨは、ＭＰＥＧ−ＤＡＳＨとしても知られており、従来のＨＴＴＰウェブサーバを使用してメディアコンテンツの高品質なストリーミングを可能にするアダプティブビットレートストリーミング技法である。ＤＡＳＨは、メディアコンテンツを一連の小さなＨＴＴＰベースファイルセグメントに区切ること（breaking）によって動作し得、ここで、各セグメントは、コンテンツの短い時間間隔を含む。ＤＡＳＨを使用して、サーバは、異なるビットレートでメディアコンテンツを提供することができる。メディアを再生しているクライアントデバイスは、次のセグメントをダウンロードしているときに、代替のビットレートから選択することができるため、ネットワーク条件の変化に適合することができる。ＤＡＳＨは、ワールドワイドウェブ（World Wide Web）上でコンテンツを搬送するために、インターネットのＨＴＴＰウェブサーバインフラストラクチャを使用する。ＤＡＳＨは、メディアコンテンツを符号化および復号するために使用されるコーデックに依存しないため、Ｈ．２６４およびＨＥＶＣなどのようなコーデックを用いて動作する。
[0079] ＩＳＯＢＭＦＦ規格は、ＤＡＳＨとともに使用するための６つのタイプのストリームアクセスポイント（ＳＡＰ：Stream Access Points）を指定する。第１の２つのＳＡＰタイプ（タイプ１および２）は、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおける瞬時デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャに対応する。例えば、ＩＤＲピクチャは、デコーダにおける復号プロセスを完全にリフレッシュまたは再初期化するイントラピクチャ（Ｉ−ピクチャ）であり、新規のコーディングされたビデオシーケンスを開始する。いくつかの例では、１つのＩＤＲピクチャおよび復号順序でそのＩＤＲピクチャに後続する任意のピクチャは、復号順でＩＤＲピクチャの前に来るいずれのピクチャにも依存し得ない。
[0080] 第３のＳＡＰタイプ（タイプ３）は、オープンＧＯＰ（Group of Pictures）ランダムアクセスポイント、従って、ＨＥＶＣにおけるリンク切れアクセス（ＢＬＡ：broken link access）またはクリーンランダムアクセス（ＣＲＡ：clean random access）ピクチャに対応する。例えば、ＣＲＡピクチャもまた、Ｉ−ピクチャである。ＣＲＡピクチャは、デコーダをリフレッシュしなくてもよく、かつ新規のＣＶＳを開始しなくてもよく、ＣＲＡピクチャの先頭ピクチャが復号順でＣＲＡピクチャの前に来るピクチャに依存することを許可する。ＣＲＡピクチャ、復号順でＣＲＡピクチャの前に来るいずれのピクチャにも依存しないＣＲＡピクチャに関連付けられた先頭ピクチャ、並びに復号順および出力順の両方でＣＲＡに後続する全ての関連したピクチャを復号することによって、ＣＲＡピクチャにおいてランダムアクセスが行われ得る。いくつかのケースでは、ＣＲＡピクチャは、関連した先頭ピクチャを有していない可能性がある。いくつかの実施形態では、マルチレイヤのケースにおいて、レイヤＩＤが０よりも大きいレイヤに属するＩＤＲまたはＣＲＡピクチャは、Ｐ−ピクチャまたはＢ−ピクチャであり得るが、これらのピクチャは、ＩＤＲまたはＣＲＡピクチャと同じアクセスユニットに属しており、かつＩＤＲまたはＣＲＡピクチャを含むレイヤよりもレイヤＩＤが小さい他のピクチャからのインターレイヤ予測しか使用することができない。
[0081] 第４のＳＡＰタイプ（タイプ４）は、ＧＤＲ（gradual decoding refresh）ランダムアクセスポイントに対応する。
[0082] ＩＳＯＢＭＦＦは、様々なタイプのメディアを記憶および送信するためにフレキシブルかつ拡張可能におよび幅広く使用される一方、仮想現実ビデオを記憶する、または仮想現実コンテンツを含める際にＩＳＯベースメディアファイルのコンテンツを識別するためのメカニズムを含んでいない。よって、プレイヤデバイスは、ファイルのコンテンツが仮想現実ビデオを含むと決定することができない可能性がある。仮想現実コンテンツを表示することができないプレイヤデバイスは、とりあえずコンテンツを表示しようとする可能性があり、歪んだプレゼンテーションをもたらす。
[0083] 仮想現実（ＶＲ）は、自然および／または合成のイメージ並びにサウンドのレンダリングによって作り出され、かつユーザが非物理世界と相互作用することを可能にする没入したユーザ（immersed user）の動作によって相互に関連付けられた、非物理世界にバーチャルに存在する能力である。頭部装着型ディスプレイ（ＨＭＤ）およびＶＲビデオ（３６０度ビデオと呼ばれることも多い）生成物などの、レンダリングデバイスにおいてなされた最近の進歩によって、高品質な経験が与えられることができる。ＶＲアプリケーションは、ゲーミング、トレーニング、教育、スポーツビデオ、オンラインショッピング、アダルトエンターテインメントなどを含む。
[0084] 仮想現実システムは、ビデオキャプチャデバイスおよび表示デバイスを含むことができ、場合によっては、サーバ、データストレージおよびデータ送信機器のような、他の媒介デバイスも含むことができる。ビデオキャプチャデバイスは、カメラセット、すなわち、複数のカメラのセットを含み、各々が異なる方向を指すまたは向いており、異なるビューをキャプチャする。カメラセットのカメラは、理想的には、そのカメラセットの周囲の全ての地点を集合的にカバーすることができる。例えば、６つのカメラは、そのカメラセットのロケーションを中心とした完全な３６０度ビューをキャプチャするために使用され得る。いくつかのビデオキャプチャデバイスは、例えば、最初に左右のビューをキャプチャするビデオキャプチャデバイスのような、少数のカメラを使用し得る。
[0085] シームレスな３６０度ビューを提供するために、カメラセット中のカメラの各々によってキャプチャされたビデオは通常、イメージ張り合わせ（image stitching）を経験し、ここで、複数の個々のカメラによって撮影されたビデオピクチャは、時間領域において同期されかつ空間領域において張り合わせられて、球面ビデオ（spherical video）となるが、エクイレクタングラー（例えば、世界地図など）、キューブマップ、または他のマップのように、長方形フォーマットにマッピングされる。いくつかのケースでは、３６０度のビデオ生成のケースにおいてイメージを張り合わせることは、ビデオフレームがオーバーラップ、またはそうでなければ接し得るエリアにおいて、隣接するカメラからのビデオフレームを組み合わせるまたは統合することを含むことができる。この結果は、ほぼ球のフレームとなり得るが、メルカトル図法と同様に、統合されたデータは、平面的な方法で表示されることができる。例えば、統合されたビデオフレーム中のピクセルは、立方体の平面上、または何らかの他の３次元の平面形状（例えば、三角錐、八面体、十面体など）にマッピングされ得る。ビデオキャプチャおよびビデオ表示デバイスは一般に、ラスター原理（raster principle）で動作し―ビデオフレームがピクセルのグリッドとして扱われることを意味する―、よって、球面の環境を表すために正方形または長方形が使用されることができる。
[0086] 平面表現にマッピングされた仮想現実ビデオフレームは、記憶および／または送信のために符号化（または圧縮）されることができる。符号化および／または圧縮は、ビデオコーデックを使用して達成されることができ（例えば、Ｈ．２６５／ＨＥＶＣ適合コーデック、Ｈ．２６４／ＡＶＣ適合コーデック、または他の適切なコーデック）、圧縮されたビデオビットストリームまたはビットストリームのグループをもたらす。ビデオコーデックを使用するビデオデータの符号化が、本明細書でさらに詳細に説明される。
[0087] 符号化されたビデオビットストリームは、メディアフォーマットまたはファイルフォーマットに記憶および／またはカプセル化されることができる。記憶されたビットストリームは、例えばネットワークを介して、表示のためのビデオを復号およびレンダリングすることができる受信機デバイスに送信されることができる。このような受信機デバイスは、ビデオディスプレイデバイス、プレイヤデバイス、デコーダデバイス、または他の適切なデバイスであり得る。例えば、仮想現実システムは、（例えば、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマットおよび／または導出されたファイルフォーマットを使用して）符号化されたビデオデータからのカプセル化されたファイルを生成することができる。例えば、ビデオコーデックはビデオデータを符号化することができ、カプセル化エンジンは、１つまたは複数のＩＳＯフォーマットメディアファイル中のビデオデータをカプセル化することによって、メディアファイルを生成することができる。代替的にまたは追加的に、記憶されたビットストリームは、記憶媒体から受信機デバイスに直接提供されることができる。
[0088] 受信機デバイスはまた、符号化されたビデオビットストリームを復号および／または解凍するためのコーデックを実装することができる。受信機デバイスは、ファイル（複数を含む）にビデオビットストリームをパッキングするために使用されたメディアまたはファイルフォーマットをサポートし、符号化されたビデオデータを生成するために、ビデオ（および場合によってはオーディオを）抽出することができる。例えば、受信機デバイスは、符号化されたビデオデータを生成するために、カプセル化されたビデオデータを用いてメディアファイルを解析することができ、受信機デバイス中のコーデックは、符号化されたビデオデータを復号することができる。
[0089] 受信機デバイスは次いで、復号されたビデオ信号をレンダリングデバイス（例えば、ビデオディスプレイデバイス）に送ることができる。レンダリングデバイスは、例えば、頭部装着型ディスプレイ（ＨＭＤ）、仮想現実テレビジョン、および／または他の１８０度または３６０度ディスプレイデバイスを含む。一般に、頭部装着型ディスプレイは、着用者の頭部の動きおよび／または着用者の目の動きを追跡することができる。頭部装着型ディスプレイは、着用者が見ている方向に対応する３６０度ビデオの部分をレンダリングするために追跡情報を使用し、これにより装着者は、その人が現実世界を体験するのと同じ方法で、仮想環境を実世界で経験することができる。レンダリングデバイスは、ビデオがキャプチャされたのと同じフレームレートで、または異なるフレームレートで、ビデオをレンダリングし得る。
[0090] ＭＰＥＧによって発展した全方位メディアアプリケーションフォーマット（ＯＭＡＦ：Omnidirectional Media Application Format）は、３６０度ビデオおよび関連するオーディオを用いた仮想現実アプリケーションのような全方位メディアアプリケーションを可能にする、メディアアプリケーションフォーマットを定義している。特に、ＯＭＡＦは、球面または３６０度ビデオを２次元の長方形ビデオに変換するために使用されることができる投影方法のリスト、並びに、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）を使用して全方位メディアおよび関連するメタデータをどのように記憶するかの方法についての記述を指定する。加えて、ＯＭＡＦは、ＨＴＴＰを介する動的適応ストリーミング（ＤＡＳＨ）を使用して、全方位メディアをどのようにカプセル化、シグナリング（例えば、フラグを立てる（flag）または示す）、およびストリーミングするかを指定した。ＯＭＡＦはまた、全方位メディア信号の圧縮および再生のために使用されることができる、ビデオおよびオーディオコーデック並びにメディアコーディング構成を指定する。
[0091] ＯＭＡＦは、ＩＳＯ／ＩＥＣ２３０９０−２として採用されることが提案され、ドラフトの規格は、以下において利用可能である。
http://wg11.sc29.org/doc_end_user/documents/119_Torino/wg11/m40849-v1-m40849_OMAF_text_Berlin_output.zip
[0092] ＯＭＡＦ規格は、領域メタデータ（regional metadata）をシグナリングするためのフォーマットを記述するが、コンテナファイルのための規格は、シグナリング領域データについての記述を提供することが欠如している可能性がある。
[0093] ＯＭＡＦ規格は、第７．４節において領域メタデータシグナリングの規格を含んでいる。このコンテキストでは、シグナリングは、フォーマットに従って構成された符号化ビットストリームまたはファイルのような、構造化されたデータのセット中の情報のインジケーションを指す。例えば、以下の例で図示されるように、第７．４節は、３６０度ビデオの領域についての情報を示すために使用されることができるデータ構造を記述している。これらの領域はまた、本明細書では球領域とも呼ばれ、全体が３６０度未満のビデオデータを表現することができる。第７．４節は、推奨ビューポートのタイムドメタデータ（recommended viewport timed metadata）を含む、タイムドメタデータトラックを使用する球領域のシグナリングのようなものについての規格を提供する。推奨ビューポートのタイムドメタデータトラックは、ユーザが閲覧している方位を制御していないとき、または閲覧している方位の制御を解除したときに表示されるべきビューポートを示すことができる。例えば、推奨ビューポートのタイムドメタデータトラックは、ディレクターズカットを表現するために使用されることができる。
[0094] ＯＭＡＦ規格の第７．４．２節では、球領域のタイムドメタデータトラックのサンプルエントリ規定、シンタックス、およびセマンティクスは、以下のように指定される：
[0095] １つのSphereRegionConfigBoxだけが、サンプルエントリ中に表されるものとする。SphereRegionConfigBoxは、サンプルによって指定される球領域の形状を指定する。サンプル中の球領域の水平および垂直範囲が変化しないとき、それらは、サンプルエントリ中で示されることができる。
Figure 0006874169
[0096] ０に等しいshape_typeは、図３に図示されるような４つの大円によって球領域が指定されること（４つの大円によって指定された球領域）を指定する。
[0097] １に等しいshape_typeは、図４に図示されるような２つのヨー円と２つのピッチ円とによって球領域が指定されること（２つのヨー円と２つのピッチ円とによって指定された球領域）を指定する。
[0098] １よりも大きいshape_type値は予備である（reserved）。
[0099] ０に等しいdynamic_range_flagは、このサンプルエントリを参照する全てのサンプルにおいて、球領域の垂直および水平領域が不変のままであることを指定する。１に等しいdynamic_range_flagは、サンプルフォーマット中に球領域の水平および垂直範囲が示されることを指定する。
[0100] static_hor_rangeおよびstatic_ver_rangeは、それぞれ、２−１６度の単位でこのサンプルエントリを参照するサンプルごとの球領域の水平および垂直範囲を指定する。static_hor_rangeおよびstatic_ver_rngeは、図３または図４で図示されるような、球領域の中心点を通る領域を指定する。static_hor_rangeは、０〜７２０＊２１６までの範囲内にあるものとする。static_ver_rangeは、０〜１８０＊２１６までの範囲内にあるものとする。static_hor_rangeとstatic_ver_rangeとの両方が０に等しいとき、このサンプルエントリを参照するサンプルごとの球領域は、球面上のある一点となる。
[0101] num_regionsは、このサンプルエントリを参照するサンプル中の球領域の数を指定する。num_regionsは１に等しいものとする。num_regionsの他の値は予備である。
[0102] ＯＭＡＦ規格の第７．４．３節では、球領域のタイムドメタデータトラックのサンプル規定、シンタックス、およびセマンティクスは、以下のように指定される：
[0103] 各サンプルは、球領域を指定する。SphereRegionSample構造は、導出されたトラックフォーマット中で拡張され得る。
Figure 0006874169
[0104] SphereRegionStruct()がSphereRegionSample()structure中に含まれるとき、以下が適用となる：
[0105] center_yaw、center_pitch、およびcenter_rollは、グローバル座標軸に対して２−１６度の単位でビューポート方位を指定する。center_yawおよびcenter_pitchは、ビューポートの中心を示し、center_rollは、ビューポートのロール角を示す。center_yawは、−１８０＊２１６から１８０＊２１６−１までの範囲内にあるものとする。center_pitchは、−９０＊２１６から９０＊２１６までの範囲内にあるものとする。center_rollは、−１８０＊２１６から１８０＊２１６−１までの範囲内にあるものとする。
[0106] 存在する場合、hor_rangeおよびver_rangeは、それぞれ、２−１６度の単位でこのサンプルによって指定された球領域の水平および垂直範囲を指定する。hor_rangeおよびver_rangeは、図３または図４に図示されるような、球領域の中心点を通る範囲を指定する。hor_rangeは、０から７２０＊２１６までの範囲内にあるものとする。ver_rangeは、０から１８０＊２１６までの範囲内にあるものとする。
[0107] このサンプルによって指定される球領域は、以下のように導出される：
[0108] ― hor_rangeとver_rangeとの両方が０に等しい場合、このサンプルによって指定された球領域は、球面上のある一点である。
[0109] ― そうでなければ、球領域は、以下のように導出される変数cYaw1、cYaw2、cPitch1、およびcPitch2を使用して定義される：
Figure 0006874169
球領域は、以下のように定義される：
[0110] ― shape_typeが０に等しいとき、球領域は、図３に示されるような、４つの点cYaw1、cYaw2、cPitch1、cPitch2によって定義される４つの大円、並びに、center_pitchおよびcenter_yawによって定義される中心点によって指定される。
[0111] ― shape_typeが１に等しいとき、球領域は、図４に示されるような、４つの点cYaw1、cYaw2、cPitch1、cPitch2によって定義される２つのヨー円および２つのピッチ円、並びに、center_pitchおよびcenter_yawによって定義される中心点によって指定される。
[0112] ターゲットメディアサンプルを、このサンプルの構成時間以上の、および次のサンプルの構成時間未満の構成時間を有する、参照メデイアトラック中のメディアサンプルとする。
[0113] ０に等しいinterpolateは、このサンプル中のcenter_yaw、center_pitch、center_roll、hor_range（ある場合）、およびver_range（ある場合）の値がターゲットメディアサンプルに適用されることを指定する。１に等しいinterpolateは、ターゲットメディアサンプルに適用するcenter_yaw、center_pitch、center_roll、hor_range（ある場合）、およびver_range（ある場合）の値が、このサンプルおよび前のサンプル中の対応するフィールドの値から線形補間されることを指定する。
[0114] ｓｙｎｃサンプルのためのinterpolateの値、トラックの第１のサンプルの値、およびトラックフラグメントの第１のサンプルは、０に等しいものとする。
[0115] ＯＭＡＦ規格の第７．４．５節では、推奨ビューポートのタイムドメタデータトラックは、以下の通りである：
[0116] 推奨ビューポートのタイムドメタデータトラックは、ユーザが閲覧している方位の制御を有していないとき、または閲覧している方位の制御を解除したときに表示されるべきビューポートを示す。
[0117] 備考：推奨ビューポートのタイムドメタデータトラックは、ディレクターズカットを示すために使用され得る。
[0118] サンプルエントリタイプ‘rcvp’が使用されるものとする。
[0119] SphereRegionSampleのサンプルシンタクスが使用されるものとする。
[0120] shape_typeは、サンプルエントリのSphereRegionConfigBoxにおいて０に等しいものとする。
[0121] 存在する場合、static_hor_rangeおよびstatic_ver_rangeは、あるいは存在する場合、hor_rangeおよびver_rangeは、それぞれ、推奨ビューポートの水平および垂直の視点（fields of view）を示す。
[0122] center_yawおよびcenter_pitchは、推奨ビューポートの中心点を示す。center_rollは、推奨ビューポートのロール角を示す。
[0123] ＭＰＥＧ文書ｍ４０７８３の第１３項は、ＯＭＡＦのコンテキストにおいて以下に記載されるような、いわゆる最も多く閲覧されたビューポート領域メタデータを提示する：
[0124] 最も多く閲覧されたビューポートタイムドメタデータトラックは、ピクチャごとに、最も多く閲覧されたビューポートを示す。
[0125] サンプルエントリタイプ‘mvvp'が使用されるものとする。
[0126] RegionOnSphereSampleのサンプルシンタックスが使用されるものとする。
[0127] shape_typeは、サンプルエントリのRegionOnSphereConfigBoxにおいて０に等しいものとする。
[0128] 存在する場合、static_hor_rangeおよびstatic_ver_rangeは、あるいは存在する場合、hor_rangeおよびver_rangeは、それぞれ、最も多く閲覧されたビューポートの水平および垂直の視点を示す。
[0129] center_yawおよびcenter_pitchは、最も多く閲覧されたビューポートの中心点を示す。center_rollは、最も多く閲覧されたビューポートのロール角を示す。
[0130] 「Berlin OMAF AHG meeting agenda and minutes」と題されたＭＰＥＧ文書ｍ４０８０５において、例えば、（１）ディレクターズカットごと、（２）統計的に最も多く閲覧されたビューポートごと、（３）特定の人物またはユーザごとなどの、メタデータのソースおよび性質を示すために使用されることができる推奨ビューポートシグナリングに何らかのインジケーションを追加することが提案されたことに留意されたい。
[0131] ビデオ符号化規格は、ビデオビットストリーム中の領域メタデータをシグナリングするための記述を提供することが欠如している可能性がある。
[0132] ＪＣＴＶＣ−ＡＡ１００５（http://phenix.int-evry.fr/jct/doc_end_user/documents/27_Hobart/ wg11/JCTVC-AA1005-v1.zipにおいて利用可能）は、（ＪＣＴＶＣ−ＡＡ１００５のＤ．２．４２節およびＤ．３．４２節において）全方位ビューポートＳＥＩメッセージを指定する。ＳＥＩメッセージのシンタックスおよびセマンティクスは以下の通りであり、ここで、ＣＬＶＳは、コーディングされたレイヤビデオシーケンスを表す：
[0133] シンタックス
Figure 0006874169
[0134] セマンティクス
[0135] 全方位ビューポートＳＥＩメッセージは、球面座標ジオメトリの１つまたは複数の領域の座標を指定し、４つの大円によって境界を示され、表示のための推奨されるビューポートに対応する。全方位ビューポートＳＥＩメッセージのために使用される参照球面座標システムは、０に等しいomni_projection_typeを有する全方位投影インジケーションＳＥＩメッセージについてと同じである。
[0136] omni_viewport_idは、１つまたは複数の推奨ビューポート領域の目的を識別するために使用され得る識別番号を含む。
[0137] ０から５１１までのomni_viewport_idの値は、アプリケーションによって決定されるものとして使用され得る。５１２から１０２３のomni_viewport_idの値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによって将来使用するための予備である。５１２から１０２３までの範囲内のomni_viewport_idの値に遭遇するデコーダは、それを無視するものとする。
[0138] １に等しいomni_viewport_cancel_flagは、ＳＥＩメッセージが、出力順で任意の前の全方位ビューポートＳＥＩメッセージの持続をキャンセルすることを示す。０に等しいomni_viewport_cancel_flagは、全方位ビューポート情報が後続することを示す。
[0139] omni_viewport_persistence_flagは、現在のレイヤについての全方位ビューポートＳＥＩメッセージの持続を指定する。
[0140] ０に等しいomni_viewport_persistence_flagは、全方位ビューポートＳＥＩメッセージが現在の復号ピクチャのみに適用されることを指定する。
[0141] ｐｉｃＡを現在のピクチャとする。１に等しいomni_viewport_persistence_flagは、全方位ビューポートＳＥＩメッセージが、以下の条件のうちの１つまたは複数が真となるまで、出力順で現在のレイヤのために持続することを指定する：
[0142] ― 現在レイヤの新規のＣＬＶＳが始まる。
[0143] ― ビットストリームが終了する。
[0144] ― 現在レイヤに適用可能な全方位ビューポートＳＥＩメッセージを含むアクセスユニット中の現在レイヤにおけるピクチャｐｉｃＢは、どのPicOrderCnt( picB )がPicOrderCnt( picA )よりも大きいかについて出力され、ここで、PicOrderCnt( picB )およびPicOrderCnt( picA )は、それぞれ、ｐｉｃＢのためのピクチャ順序カウントについての復号プロセスの呼び出しの直後の、ｐｉｃＢおよびｐｉｃＡのPicOrderCntVal値である。
[0145] ０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージが、現在ピクチャに適用されるＣＬＶＳ中に存在せず、かつ復号順で全方位ビューポートＳＥＩメッセージに先行するとき、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージは、現在ピクチャに適用されるＣＬＶＳ中に存在しないものとする。デコーダは、現在ピクチャに適用されるＣＬＶＳ中の０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージに復号順で後続しない、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージを無視するものとする。
[0146] omni_viewport_cnt_minus1は、ＳＥＩメッセージによって示される推奨ビューポート領域の数を指定する。
[0147] omni_viewport_yaw_center[ i ]は、２−１６度の単位でアップベクトル（up vector）周辺のｉ番目の推奨ビューポート領域の中心を示す。omni_viewport_yaw_center[ i ]の値は、−１８０＊２１６（すなわち、−１１７９６４８０）から１８０＊２１６−１（すなわち、１１７９６４７９）までの範囲内にあるものとする。
[0148] omni_viewport_pitch_center[ i ]は、２−１６度単位で、omni_viewport_yaw_centerの周辺、すなわち、ヨー回転の後の右ベクトルの、ｉ番目の推奨ビューポート領域の中心を示す。omni_viewport_pitch_center[ i ]の値は、−９０＊２１６（すなわち、−５８９８２４０）から９０＊２１６（すなわち、５８９８２４０）までの範囲内にあるものとする。
[0149] omni_viewport_roll_center[ i ]は、２−１６度単位で、omni_viewport_pitch_centerの周辺、すなわち、ヨーおよびピッチ回転の後の前方方向ベクトルの、ｉ番目の推奨ビューポート領域の中心を示す。omni_viewport_roll_center[ i ]の値は、−１８０＊２１６（すなわち、−１１７９６４８０）から２１６−１（すなわち、１１７９６４７９）までの範囲内にあるものとする。
[0150] omni_viewport_yaw_range[ i ]は、２−１６度の単位でヨーの値の範囲でプロジェクションマッピングされた復号ピクチャのｉ番目の推奨ビューポート領域のサイズを示す。omni_viewport_yaw_range[ i ]の値は、１から３６０＊２１６（すなわち、２３５９２９６０）までの範囲内にあるものとする。
[0151] omni_viewport_pitch_range[ i ]は、２−１６度の単位でピッチの値の範囲でプロジェクションマッピングされた復号ピクチャのｉ番目の推奨ビューポート領域のサイズを示す。omni_viewport_pitch_range[ i ]の値は、１から１８０＊２１６（すなわち、１１７９６４８０）までの範囲内にあるものとする。
[0152] 上述されるような領域メタデータは、３６０度または全方位ビデオにおける関心領域（regions of interest ）をコンテンツクリエイターが指定することを可能にすることができる。関心領域は、コンテンツクリエイターが何らかの理由で強調することを希望する、３６０度ビデオの一部であり得る。例えば、閲覧者がビデオを受動的に観察している（例えば、閲覧者が閲覧者の目の前にあるビデオの一部を制御しない）とき、関心領域は、閲覧者の主要ビューポート（例えば、閲覧者のすぐ目の前にあるビューポート）で提示されることができる。ここで、「関心領域」、「球領域」、および「推奨ビューポート」という用語は、置き換えて使用される。
[0153] ３６０度ビデオがどのように記録されることができるかを記述する様々な規格は、全方位ビデオの領域メタデータをシグナリングするための規格が欠如している。例えば、球領域（例えば、場合によっては、なぜその球領域が関心領域であるかを含む、球領域の記述）、または推奨ビューポートのタイムドメタデータのソースおよび性質のシグナリングのためのコンテナファイルフォーマットまたはビデオビットストリーム符号化規格のいずれにも、十分に定義され許容された規格は存在しない。別の例では、各サンプルが１よりも多い球領域を指定する（例えば、各球領域が推奨ビューポートである）とき、任意の２つの球領域間で、いずれが比較的重要か、または他方よりもより推奨されるかは、未知である。別の例では、推奨ビューポートがディレクターズカットであるまたは統計的に最も多く閲覧されたということに加えて、推奨ビューポートのソースおよび性質は、多くのソースおよび記述を含むことができる。例えば、推奨ビューポートは、有名なまたは特定のウェブサイトによって指定されている可能性がある、特定のコンテキストにおいて重要であり得る、および／または他の理由で推奨され得る。この例では、推奨ビューポートのソースおよび性質を正確に指定することは負担かつ不要であり得、ディレクターズカットまたは統計的に最も多く閲覧されたもの以外のソースおよび性質をシグナリングするためのシンプルなアプローチが適用されるべきである。
[0154] 推奨ビューポートのソースおよび性質、並びに複数の推奨ビューポート間の優先度のような領域情報を指定するためのシステムおよび方法が提供される。方法のいくつかまたは全ては単独で適用され、方法のいくつかまたは全ては組み合わせて適用され得る。
[0155] 第１の例として、規格は、推奨ビューポートに関連付けられたソースおよび性質、並びに推奨ビューポートのタイムドメタデータをシグナリングするために提供され得、コンテナファイルおよび／またはビデオビットストリームに適用されることができる。この例では、規格は、上述されたSphereRegionConfigBox中で、球領域のソースを示すために、（例えば、サンプルエントリが適用されるサンプルによって指定される）球領域ごとに１つずつ、フィールドのループを追加することを含むことができる。推奨ビューポートのコンテキストでは（例えば、サンプルエントリタイプが‘rcvp’であるとき）、このフィールドの値は、（例えば、値が０に等しいとき）ディレクターズカットを、（例えば、値が１に等しいとき）統計により最も多く閲覧されたものを、または別のソースおよび性質を示し得る。いくつかの例では、SphereRegionConfigBox中のnum_regionsフィールドの値は、１よりも大きくなることが可能である。このような例では、異なる球領域は、同じタイムドメタデータトラック中で搬送されることができる。いくつかの例では、num_regionsフィールドの値は、未だ１に等しくなることが必要とされ得る。これらの例では、異なる球領域は、異なるタイムドメタデータトラック中で搬送され得る。
[0156] 代替的にまたは追加的に、第１の例では、ビューポートのソースおよび性質を示すために、ビューポートごとに１つの全方位ビューポートＳＥＩメッセージシンタックスに、フィールドが追加されることができる。このフィールドの値は、（例えば、値が０に等しいとき）ディレクターズカットを、（例えば、値が１に等しいとき）統計による最も多く閲覧されたものを、または別のソースおよび性質を示し得る。
[0157] 第２の例として、規格は、複数の球領域のうちのいずれが他のものよりも重要であるかを指定するために提供されることができる。この例では、規格は、SphereRegionConfigBox中で、球領域の優先度を示すために、（例えば、サンプルエントリが適用されるサンプルによって指定される）球領域ごとに１つずつ、フィールドのループを追加することを含むことができる。推奨ビューポートのコンテキストでは（すなわち、サンプルエントタイプが‘rcvp’であるとき）、例として、ビューポートに関する低い優先度値は、ビューポートのための推奨度がより高いことを示す。例えば、いくつかのケースでは、優先度値０を有するビューポートが、最も推奨されるビューポートである。
[0158] 代替的にまたは追加的に、第２の例では、ビューポートの優先度を示すために、ビューポートごとに１つの全方位ビューポートＳＥＩメッセージシンタックスに、フィールドが追加されることができる。一例では、ビューポートに関する低い優先度値は、ビューポートについてより高い推奨度を示すことができる。例えば、いくつかのケースでは、優先度値０を有するビューポートが、最も推奨されるビューポートである。
[0159] 第３の例では、規格は、推奨ビューポートの理由（例えば、ディレクターズカットまたは統計的に最も多く閲覧されたビューポートであるビューポート以外のソースおよび性質）を示すために提供されることができる。この例では、規格は、上記の第１の例で説明されるように、球領域のソースを示すために、SphereRegionConfigBoxシンタックス中で、球領域ごとに（ソースフィールドと呼ばれ得る）フィールドのループを追加することを含むことができる。この例では、ソースフィールドが特定の値（例えば、２）であるとき、別のフィールドは、ユニバーサルリソース識別子（ＵＲＩ）を示すために、SphereRegionConfigBoxに追加されることができる。この例では、ＵＲＩは、球領域情報を生成するために使用される方法のユニークネームを提供することができる。
[0160] 代替的にまたは追加的に、第３の例では、ソースフィールドの値が特定の値（例えば、２）に等しいとき、フィールドは、全方位ビューポートＳＥＩメッセージシンタックスに追加されることができる。この例では、追加のフィールドは、ビューポート情報を生成するために使用される方法の記述のＵＲＩを提供するＵＲＩを示すことができる。
[0161] いくつかのケースでは、上述された第１、第２、および第３の例と組み合わせてまたはそれらに代わって、第４の例では、新規のＳＥＩメッセージ（例えば、全方位ＣＬＶＳビューポートＳＥＩメッセージまたは別の適切な名称で呼ばれる）を定義する規格が提供されることができる。この例では、新規のＳＥＩメッセージは、推奨ビューポートについての情報をシグナリングすることができ、この情報は、全体が符号化されたレイヤビデオシーケンス（ＣＬＶＳ：coded layer video sequence）にわたって静的であることができる。いくつかの例では、上記の第１、第２、および第３の例に記述されるようなシグナリングされた情報は、代わりに新規のＳＥＩメッセージ中でシグナリングされることができる。加えて、いくつかの例では、omni_viewport_idシンタックス要素は、全方位ビューポートＳＥＩメッセージから削除され得る。さらに、いくつかのケースでは、omni_viewport_cnt_minus1シンタックス要素は、全方位ビューポートＳＥＩメッセージと（新規のＳＥＩメッセージ中の異なるシンタックス要素名を有する）新規のＳＥＩメッセージとの両方でシグナリングされ得る。omni_viewport_cnt_minus1シンタックス要素が新規のＳＥＩメッセージ中でのみシグナリングされるケースと比較して、これは、新規のＳＥＩメッセージにおける全方位ビューポートＳＥＩメッセージのシンタックス解析依存を回避する。この方法で、静的情報の多くは、ＣＬＶＳ中のピクチャにわたって各球領域の動的位置およびサイズを搬送する全方位ビューポートＳＥＩメッセージ中で繰り返されることを必要としない。
[0162] いくつかのケースでは、上述される第１、第２、および第３の例と組み合わせてまたはそれらに代わって、第５の例では、規格は、ＯＭＡＦ中の推奨ビューポートをシグナリングするために提供されることができる。この例では、SphereRegionConfigBoxのシンタックスを変更することに代わって、新規のボックスが同じ情報を含むように定義され、この新規のボックスは、サンプルエントリタイプが‘rcvp’であるとき、同じエントリシンタックスに直接含まれる。
[0163] 上述された第４および第５の例についての例となる実施形態がここで提供される。これらの実施形態は、これらの例についての例示的な実装としてのみ提供されるものであり、他の実装が可能である。
第４の例の例示的な実施形態
[0164] 上述された第４の例についての例となる詳細な実施形態が例示のために提供される。
[0165] この例では全方位ＣＬＶＳビューポートＳＥＩメッセージと呼ばれる、新規のＳＥＩメッセージのシンタックスおよびセマンティクスは、以下の通りである：
[0166] シンタックス
Figure 0006874169
[0167] セマンティクス
[0168] 全方位ＣＬＶＳビューポートＳＥＩメッセージは、ＣＬＶＳ中の全方位ビューポートＳＥＩメッセージによって指定される全てのビューポートに適用される情報を指定する。
[0169] ０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージが、現在ピクチャに適用されるＣＬＶＳ中に存在せず、かつ復号順で全方位ＣＬＶＳビューポートＳＥＩメッセージに先行するとき、全方位ＣＬＶＳビューポートＳＥＩメッセージは、現在ピクチャに適用されるＣＬＶＳ中に存在しないものとする。デコーダは、現在ピクチャに適用されるＣＬＶＳ中の０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージに復号順で後続しない、方位ＣＬＶＳビューポートＳＥＩメッセージを無視するものとする。
[0170] 現在の全方位プロジェクションインジケーションＳＥＩメッセージを、現在ピクチャに適用されるＣＬＶＳ中の０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージとする。全方位ＣＬＶＳビューポートＳＥＩメッセージ中の情報は、復号順で、現在ピクチャから現在の全方位プロジェクションインジケーションＳＥＩメッセージが適用される、ＣＬＶＳ中の最後のピクチャまで、持続する。
[0171] ocv_reserved_zero_4bitsは、この規格のこのバージョンに適合するビットストリーム中で０に等しいものとする。ocv_reserved_zero_4bitsについての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来使用するための予備である。デコーダは、ocv_reserved_zero_4bitsの値を無視するものとする。
[0172] omni_clvs_viewport_cnt_minus1プラス１は、全方位ＣＬＶＳビューポートＳＥＩメッセージおよび関連する全方位ビューポートＳＥＩメッセージによって示される推奨ビューポート領域の数を指定する。全方位ＣＬＶＳビューポートＳＥＩメッセージの関連する全方位ビューポートＳＥＩメッセージは、全方位ＣＬＶＳビューポートＳＥＩメッセージが適用されるＣＬＶＳのピクチャの同じセットに適用する０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージである。
[0173] omni_clvs_viewport_priority[ i ]は、このＳＥＩメッセージおよび関連する全方位ビューポートＳＥＩメッセージによって指定されるｉ番目のビューポート領域の優先度を示す。omni_clvs_viewport_priority[ i ]のより低い値は、ビューポートについてより高い推奨度を示す。優先度値０を有するビューポートは、最も推奨されるビューポートである。
[0174] omni_clvs_viewport_source[ i ]は、このＳＥＩメッセージおよび下記の表のような関連する全方位ビューポートＳＥＩメッセージによって指定されたｉ番目のビューポート領域のソースを指定する：
Figure 0006874169
[0175] omni_clvs_viewport_source[ i ]の値は、この規格のこのバージョンに適合する、０から２までの範囲内にあるものとする。omni_clvs_viewport_source[ i ]についての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによって将来使用するための予備である。デコーダは、３以上のomni_clvs_viewport_source[ i ]の値がシンタックス中に現れることを可能にするものとし、かつ３以上のomni_clvs_viewport_source[ i ]の値を無視するものとする。
[0176] viewport_generating_uri[ i ][ ViewportGeneratingUriIdx ]は、ＵＴＦ−８キャラクタに符号化されたヌル終端ストリングのViewportGeneratingUriIdx番目のバイトであり、このＳＥＩメッセージおよび関連する全方位ビューポートＳＥＩメッセージによって指定されたｉ番目のビューポート領域を生成するために使用される方法の記述のユニバーサルリソース識別子（ＵＲＩ）を指定する。
[0177] 全方位ビューポートＳＥＩメッセージのシンタックスおよびセマンティクスが、以下のように変更される（ここで、シンタックスおよびセマンティクスに対する追加が「<insert>」シンボルと「<insertend>」シンボルとの間に示され（例えば、「<insert>追加されたテキスト<insertend>」）、削除は、「<delete>」シンボルと「<deleteend>」シンボルとの間に示される（例えば、「<delete>削除されたテキスト<deleteend>」））：
Figure 0006874169
[0178] 全方位ビューポートＳＥＩメッセージは、球面座標ジオメトリの１つまたは複数の領域の座標を指定し、４つの大円によって境界を示され、表示のための推奨されるビューポートに対応する。全方位ビューポートＳＥＩメッセージのために使用される参照球面座標システムは、０に等しいomni_projection_typeを有する全方位投影インジケーションＳＥＩメッセージについてと同じである。
[0179] <delete>omni_viewport_idは、１つまたは複数の推奨ビューポート領域の目的を識別するために使用され得る識別番号を含む。
[0180] ０から５１１までのomni_viewport_idの値は、アプリケーションによって決定されるものとして使用され得る。５１２から１０２３のomni_viewport_idの値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによって将来使用するための予備である。５１２から１０２３までの範囲内のomni_viewport_idの値に遭遇するデコーダは、それを無視するものとする。<deleteend>
[0181] １に等しいomni_viewport_cancel_flagは、ＳＥＩメッセージが、出力順で任意の前の全方位ビューポートＳＥＩメッセージの持続をキャンセルすることを示す。０に等しいomni_viewport_cancel_flagは、全方位ビューポート情報が後続することを示す。
[0182] omni_viewport_persistence_flagは、現在のレイヤについての全方位ビューポートＳＥＩメッセージの持続を指定する。
[0183] ０に等しいomni_viewport_persistence_flagは、全方位ビューポートＳＥＩメッセージが現在の復号ピクチャのみに適用されることを指定する。
[0184] ｐｉｃＡを現在のピクチャとする。１に等しいomni_viewport_persistence_flagは、全方位ビューポートＳＥＩメッセージが、以下の条件のうちの１つまたは複数が真となるまで、出力順で現在のレイヤのために持続することを指定する：
[0185] ― 現在レイヤの新規のＣＬＶＳが始まる。
[0186] ― ビットストリームが終了する。
[0187] ― 現在レイヤに適用可能な全方位ビューポートＳＥＩメッセージを含むアクセスユニット中の現在レイヤにおけるピクチャｐｉｃＢは、どのPicOrderCnt( picB )がPicOrderCnt( picA )よりも大きいかについて出力され、ここで、PicOrderCnt( picB )およびPicOrderCnt( picA )は、それぞれ、ｐｉｃＢのためのピクチャ順序カウントについての復号プロセスの呼び出しの直後の、ｐｉｃＢおよびｐｉｃＡのPicOrderCntVal値である。
[0188] <insert>全方位ＣＬＶＳビューポートＳＥＩメッセージが、現在ピクチャに適用されるＣＬＶＳ中に存在せず、かつ復号順で全方位ビューポートＳＥＩメッセージに先行するとき、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージは、現在ピクチャに適用されるＣＬＶＳ中に存在しないものとする。デコーダは、現在ピクチャに適用されるＣＬＶＳ中の全方位ＣＬＶＳビューポートＳＥＩメッセージに復号順で後続しない、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージを無視するものとする。<insertend>
[0189] <delete>０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージが、現在ピクチャに適用するＣＬＶＳ中に存在せず、復号順で全方位ビューポートＳＥＩメッセージに先行するとき、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージは、現在ピクチャに適用されるＣＬＶＳ中に存在しないものとする。デコーダは、現在ピクチャに適用されるＣＬＶＳ中の０に等しいomni_projection_information_cancel_flagを有する全方位プロジェクションインジケーションＳＥＩメッセージに復号順で後続しない、０に等しいomni_viewport_cancel_flagを有する全方位ビューポートＳＥＩメッセージを無視するものとする。<deleteend>
[0190] <insert>ov_reserved_zero_2bitsは、この規格のこのバージョンに適合するビットストリーム中で０に等しいものとする。ov_reserved_zero_2bitsについての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来使用するための予備である。デコーダは、ov_reserved_zero_2bitsの値を無視するものとする。<insertend>
[0191] omni_viewport_cnt_minus1<insert>プラス１<insertend>は、ＳＥＩメッセージによって示される推奨ビューポート領域の数を指定する。<insert>omni_viewport_cnt_minus1の値は、ＣＬＶＳ中の全方位ＣＬＶＳビューポートＳＥＩメッセージのomni_clvs_viewport_cnt_minus1に等しいものとする。<insertend>
第５の例の例示的な実施形態
[0192] 上述された第５の例についての例となる詳細な実施形態が例示のために提供される。
[0193] ＯＭＡＦのセマンティクスが、以下のように変更される（ここで、シンタックスおよびセマンティクスに対する追加が「<insert>」シンボルと「<insertend>」シンボルとの間に示され（例えば、「<insert>追加されたテキスト<insertend>」）、削除は、「<delete>」シンボルと「<deleteend>」シンボルとの間に示される（例えば、「<delete>削除されたテキスト<deleteend>」））：
[0194] num_regionsは、このサンプルエントリを参照するサンプル中の球領域の数を指定する。<delete>num_regionsは１に等しいものとする。num_regionsの他の値は予備である。<deleteend>
[0195] 最新のＯＭＡＦドラフト規格の第７．４．５節における推奨ビューポートの定義は、以下のように変更される（ここで、黄色のハイライトは追加箇所であり、赤字の取り消し線は削除箇所であり、他の部分は変更なしである）：
[0196] 推奨ビューポートのタイムドメタデータトラックは、ユーザが閲覧している方位の制御を有していないとき、または閲覧している方位の制御を解除したときに表示されるべきビューポートを示す。
[0197] 備考：推奨ビューポートのタイムドメタデータトラックは、ディレクターズカット、<insert>統計による最も多く閲覧されたビューポート、またはＵＲＩによって指定された他の手段によって生成されたもの<insertend>を示すために使用され得る。
[0198] サンプルエントリタイプ‘rcvp’が使用されるものとする。
[0199] <insert>このサンプルエントリタイプのサンプルエントリは、以下のように指定される：
Figure 0006874169
[0200] region_priority[i]は、ｉ番目の推奨ビューポートの優先度を示す。低い値は、推奨ビューポートについてのより高い推奨度を示す。region_priority[i]の値０を有する推奨ビューポートは、最も推奨されるものである。
[0201] region_source[i]は、以下の表のような、ｉ番目の推奨ビューポートのソースを指定する：
Figure 0006874169
[0202] region_generating_uri[i]は、ｉ番目の推奨ビューポートを生成するために使用される方法の記述のＵＲＩを提供する。<insertend>
[0203] SphereRegionSampleのサンプルシンタクスが使用されるものとする。
[0204] shape_typeは、サンプルエントリのSphereRegionConfigBoxにおいて０に等しいものとする。
[0205] 存在する場合、static_hor_rangeおよびstatic_ver_rangeは、あるいは存在する場合、hor_rangeおよびver_rangeは、それぞれ、推奨ビューポートの水平および垂直の視点を示す。
[0206] center_yawおよびcenter_pitchは、推奨ビューポートの中心点を示す。center_rollは、推奨ビューポートのロール角を示す。
[0207] 図５は、仮想現実ビデオデータを処理するためのプロセス５００の例を図示するフローチャートである。例示的なプロセス５００は、図１に図示されるシステムのようなビデオコーディングシステムによって実装されることができる。
[0208] ステップ５０２において、図６のプロセス５００は、仮想現実ビデオデータを取得することを含み、ここにおいて、仮想現実ビデオデータは、仮想環境の３６０度ビューを表現する。いくつかの例では、仮想現実ビデオデータ中のビデオフレームは、形状が球として表現されることができ、それによって、各ビデオフレームは、完全な３６０度のデータを含むことができる。いくつかの例では、仮想現実ビデオデータは、２次元の長方形フォーマットにマッピングされることができ、それは、２次元ビデオデータを処理するように構成されたシステムによってより容易に処理されることができる。
[0209] ステップ５０４において、プロセス５００は、仮想現実ビデオデータの領域を決定することを含み、ここにおいて、領域は、３６０度ビューのサブセクションを含む。いくつかの例では、領域は、仮想現実ビデオデータを閲覧しているとき、ビューポートとして使用されることができる。
[0210] いくつかの例では、領域は、４つの大円を使用して指定されることができる。このコンテキストでは、大円は、仮想現実ビデオデータの球表現の周囲に描かれた線であり、ここで、この線は、球の円周を包含する。領域を指定するために、第１の線と第２の線とは、第１の線と第２の線との間のエリアがその領域に含まれることができるように、２点で交差し、かつその交点間の全ての点から等距離にあることができる。第３の線と第４の線は、領域をさらに描くために使用されることができる。第３の線と第４の線もまた、２点で交差しており、交点間の全ての点で等距離にあることができる。第３の線と第４の線は、第１の線と第２の線との間のエリアと、第３の線と第４の線との間のエリアがオーバーラップするように方向付けされることができる。よって、オーバーラップしているエリアは、領域を形成することができる。例えば、第１および第２の線と、第３および第４の線とは、オーバーラップしているエリアがほぼ長方形の形状となるように、第１の線と第２の線とが互いから最も遠く離れており、かつ第３の線と第４の線とが互いから最も遠く離れている場所でオーバーラップすることができる。別の方法を記載すると、第１および第２の線が交差する点は、４本の線の交差によって形成されるエリアが領域を形成するように、第３および第４の線が交差する場所から９０度になることができる。
[0211] いくつかの例では、領域は、２つのヨー円および２つのピッチ円を使用して指定されることができる。例えば、仮想現実ビデオデータの球表現上の第１の点と、第１の点から１８０度の第２の点とが与えられると、第１のヨー円は、第１の点から第２の点へと球を外接し、そして第１の点へと戻ることができる。第２のヨー円はまた、第１のヨー円と第２のヨー円との間に空間が形成されるように、第１のヨー円からの（例えば、ヨー値によって定義される）オフセットにおいて球を外接することができる。この例では、第１のピッチ円は、第１の点を第１のピッチ円の中心として、球の表面に描かれることができ、ここで、ピッチ値は、第１の点から第１のピッチ円までの角度を示すことができる。第２のピッチ円は、第１の点を第１のピッチ円の中心として、およびより大きいピッチ値で球の表面上に描かれることができる。この例では、２つのヨー円および２つのピッチ円の交差によって形成されるエリアが領域となることができる。
[0212] ステップ５０６において、プロセス５００は、領域のためのデータ構造を生成することを含み、データ構造は、領域を記述するパラメータを含み、ここにおいて、パラメータは、領域に関連付けられたソースを示すパラメータを含む。データ構造は、例えば、オブジェクト指向のプログラミング言語を使用して指定されるオブジェクトクラスである。別の例では、データ構造は、プログラミング言語を使用して定義された構造であることができる。別の例として、データ構造は、ビデオエンコーダ規格によって使用されるようなシンタックスデータ構造であることができる。
[0213] いくつかのケースでは、デコーダは、指定された領域のソースに基づいて、異なる方法で領域を扱うことができる。いくつかの例では、領域に関連付けられたソースは、コンテンツクリエイターである。これらの例では、例えば、閲覧者がビューポートを制御していないか、またはシステムにビューポートの制御を譲るとき、ディスプレイデバイスは、領域を優先度付けし（give priority）得る。領域に関連付けられたソースは、領域が仮想現実ビデオデータの最も多く閲覧された領域であることを示す。例えば、ディスプレイデバイスは、ビデオデータの閲覧者によって最も多く閲覧されたビューポートを記録することができる。この情報は次いで、関心領域として最も頻繁に閲覧されたビューポートを指定するために使用される。
[0214] ステップ５０８において、プロセス５００は、仮想現実ビデオデータを記憶するためのファイルを生成することを含む。ファイルは、仮想現実データを記憶および／または転送するために使用されることができる。いくつかの例では、ファイルは、仮想現実ビデオデータを表示するために、ビデオコーディングデバイスによってさらに処理されることができる。
[0215] ステップ５１０において、プロセス５００は、ファイルに仮想現実ビデオデータを記憶することを含む。例えば、仮想現実ビデオデータからのフレームは、ファイルへと書き込むことができる。いくつかの例では、ビデオフレームは、ファイルに書き込まれる前に、３次元表現から２次元表現にマッピングされ得る。いくつかの例では、ビデオフレームは、ファイルに書き込まれる前に符号化されることができる。
[0216] ステップ５１２において、プロセス５００は、ファイルにデータ構造を記憶することを含む。例えば、データ構造は、ファイルにメタデータとして記憶されることができ、そのファイルから読み取られ、ビデオディスプレイデバイスによって解釈されることができる。
[0217] いくつかの例では、ファイルは、コンテナファイルであり、フォーマットに従って編成されることができる。例えば、コンテナファイルは、ＩＳＯＢＭＦＦファイルフォーマット規格または別のファイルフォーマット規格に従ってフォーマット化されることができる。この例および他の例では、データ構造は、フォーマットによって説明されるボックス構造に記憶されることができる。例えば、データ構造は、メディアデータボックスに記憶されることができる。いくつかの例では、ボックス構造中の領域数の値は、１より大きくなることが可能である。これらの例では、仮想現実ビデオデータが１より多い領域を含むとき、複数の領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる。いくつかの例では、ボックス構造中の領域数の値は、１に限定される。これらの例は、仮想現実ビデオデータが１より多い領域を含むとき、１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される。
[0218] いくつかの例では、仮想現実ビデオデータは、符号化されたビットストリームとしてファイルに記憶される。これらの例では、データ構造は、ＳＥＩメッセージのような符号化されたビットストリームのメッセージ要素に記憶されることができる。
[0219] 符号化デバイス１０４および復号デバイス１１２の具体的な詳細は、それぞれ図６および図７に示されている。図６は、この開示に記述される技法のうちの１つまたは複数を実装し得る実例的な符号化デバイス１０４を図示するブロック図である。符号化デバイス１０４は、例えば、本明細書に記述されるシンタックス構造（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳ、または他のシンタックス要素のシンタックス構造）を生成し得る。符号化デバイス１０４は、ビデオスライス内のビデオブロックのイントラ予測およびインター予測コーディングを行い得る。前述されたように、イントラコーディングは、所与のビデオフレームまたはピクチャ内の空間的冗長性を低減または削除するために、空間的予測に少なくとも部分的に依存する。インターコーディングは、ビデオシーケンスの隣接するまたは周囲のフレーム内の時間的冗長性を低減または削除するために、時間的予測に少なくとも部分的に依存する。イントラモード（Ｉモード）は、いくつかの空間ベースの圧縮モードのうちの任意のものを指し得る。単一方向予測（Ｐモード）または双予測（Ｂモード）のようなインターモードは、いくつかの時間ベースの圧縮モードのうちの任意のものを指し得る。
[0220] 符号化デバイス１０４は、分割ユニット３５、予測処理ユニット４１、フィルタユニット６３、ピクチャメモリ６４、加算器５０、変換処理ユニット５２、量子化ユニット５４、およびエントロピー符号化ユニット５６を含む。予測処理ユニット４１は、動き推定ユニット４２、動き補償ユニット４４、およびイントラ予測処理ユニット４６を含む。ビデオブロック再構成のために、符号化デバイス１０４はまた、逆量子化ユニット５８、逆変換処理ユニット６０、および加算器６２を含む。フィルタユニット６３は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ：adaptive loop filter）、およびサンプル適応オフセット（ＳＡＯ：sample adaptive offset）フィルタなどの１つまたは複数のループフィルタを表現するよう意図されている。フィルタユニット６３は、インループフィルタとして図６に示されているが、他の構成では、フィルタユニット６３は、ポストループフィルタとして実装され得る。後処理デバイス５７が、符号化デバイス１０４によって生成される符号化されたビデオデータ上で追加の処理を行い得る。本開示の技法は、いくつかの事例では、符号化デバイス１０４によって実装され得る。しかしながら、他の事例では、本開示の技法のうちの１つまたは複数は、後処理デバイス５７によって実装され得る。
[0221] 図６に示されているように、符号化デバイス１０４は、ビデオデータを受信し、分割ユニット３５は、データをビデオブロックに分割する。分割はまた、スライス、スライスセグメント、タイル、または他のより大きいユニットへの分割、並びに、例えば、ＬＣＵおよびＣＵの４分木構造に従ったビデオブロック分割を含み得る。符号化デバイス１０４は、一般に、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を図示する。スライスは、複数のビデオブロックに（場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。予測処理ユニット４１は、エラー結果（例えば、コーディングレートおよび歪みのレベル、または同様のもの）に基づいて、現在ビデオブロックのために、複数のイントラ予測コーディングモードのうちの１つ、または複数のインター予測コーディングモードのうちの１つのような、複数の可能なコーディングモードのうちの１つを選択し得る。予測処理ユニット４１は、結果として生じるイントラまたはインターコーディングブロックを、残差ブロックデータを生成するために加算器５０に、参照ピクチャとしての使用のための符号化ブロックを再構成するために加算器６２に提供し得る。
[0222] 予測処理ユニット４１内のイントラ予測処理ユニット４６は、空間的圧縮を提供するためにコード化されるべき現在ブロックと同じフレームまたはスライス中の１つまたは複数の近隣ブロックに対して、現在ビデオブロックのイントラ予測コーディングを行い得る。予測処理ユニット４１内の動き推定ユニット４２および動き補償ユニット４４は、時間的圧縮を提供するために、１つまたは複数の参照ピクチャ中の１つまたは複数の予測ブロックに対して、現在ビデオブロックのインター予測コーディングを行う。
[0223] 動き推定ユニット４２は、ビデオシーケンスについての所定のパターンに従って、ビデオスライスに対するインター予測モードを決定するように構成され得る。所定のパターンは、Ｐスライス、Ｂスライス、またはＧＰＢスライスとして、シーケンス中のビデオスライスを指定し得る。動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別個に図示されている。動き推定ユニット４２によって行われる動き推定は、ビデオブロックのための動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックの予測ユニット（ＰＵ）の変位を示し得る。
[0224] 予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、二乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分の観点でコーディングされるべきビデオブロックのＰＵと密接に一致するように発見されるブロックである。いくつかの例では、符号化デバイス１０４は、ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置についての値を算出し得る。例えば、符号化デバイス１０４は、参照ピクチャの４分の１ピクセル位置、８分の１ピクセル位置、または他の分数ピクセル位置の値を補間し得る。従って、動き推定ユニット４２は、フルピクセル位置および分数ピクセル位置に対する動き検索を行い、分数ピクセル精度を有する動きベクトルを出力し得る。
[0225] 動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵのための動きベクトルを算出する。参照ピクチャは、その各々がピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得る。動き推定ユニット４２は、算出された動きベクトルを、エントロピー符号化ユニット５６および動き補償ユニット４４に送る。
[0226] 動き補償ユニット４４によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて、予測ブロックをフェッチすることまたは生成ことを伴い得、場合によっては、サブ画素精度への補間を行う。現在ビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、参照ピクチャリストにおいて動きベクトルが指し示す予測ブロックを位置指定し得る。符号化デバイス１０４は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。画素差分値は、このブロックについての残差データを形成し、ルーマおよびクロマの両方の差分成分を含み得る。加算器５０は、この減算オペレーションを行う１つまたは複数の構成要素を表現する。動き補償ユニット４４はまた、ビデオスライスのビデオブロックを復号する際に、復号デバイス１１２によって使用するための、ビデオブロックとビデオスライスとに関連付けられたシンタックス要素を生成し得る。
[0227] イントラ予測処理ユニット４６は、上述したように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測処理ユニット４６は、現在ブロックを符号化するために使用するイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット４６は、例えば、別個の符号化パスの間に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット処理４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。例えば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードに関するレート歪み分析を使用してレート歪み値を算出し得、テストされたモードの中で最良のレート歪み特性を有するイントラ予測モードを選択し得る。レート歪み分析は、一般に、符号化されたブロックと、符号化されたブロックを作成するために符号化した元の符号化されていないブロックとの間の歪み（または、誤差）の量、並びに符号化されたブロックを作成するために使用されるビットレート（すなわち、ビットの個数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックのための最良のレート歪み値を示すのかを決定するために、様々な符号化されたブロックの歪みおよびレートから比を算出することができる。
[0228] いずれのケースでも、ブロックのためのイントラ予測モードを選択した後、イントラ予測処理ユニット４６は、エントロピー符号化ユニット５６にブロックのための選択されたイントラ予測モードを示す情報を提供し得る。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。符号化デバイス１０４は、様々なブロックのための符号化コンテキストの定義、並びに最も可能性のあるイントラ予測モードのインジケーション、イントラ予測モードインデックステーブル、およびコンテキストごとに使用すべき修正されたイントラ予測モードインデックステーブルを、送信されたビットストリーム構成データ中に含み得る。ビットストリーム構成データは、複数のイントラ予測モードインデックステーブルと、複数の修正されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）とを含み得る。
[0229] 予測処理ユニット４１が、インター予測またはイントラ予測のいずれかを介して、現在ビデオブロックのための予測ブロックを生成した後、符号化デバイス１０４は、現在ビデオブロックから予測ブロックを減算することによって、残差ビデオブロックを形成する。残差ブロック内の残差ビデオデータは、１つまたは複数のＴＵに含まれ、変換処理ユニット５２に適用され得る。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ：discrete cosine transform）のような変換または概念的に同様の変換を使用して、残差ビデオデータを残差変換係数へと変換する。変換処理ユニット５２は、残差ビデオデータをピクセル領域から周波数領域のような変換領域にコンバートし得る。
[0230] 変換処理ユニット５２は、結果として生じる変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数の一部またはすべてに関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化された変換係数を含む行列のスキャンを行い得る。代替的に、エントロピー符号化ユニット５６がスキャンを行い得る。
[0231] 量子化に続いて、エントロピー符号化ユニット５６は、量子化された変換係数をエントロピー符号化する。例えば、エントロピー符号化ユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率間隔分割エントロピーコーディング（ＰＩＰＥ）、コーディング、または別のエントロピーコーディング技法を行い得る。エントロピー符号化ユニット５６によるエントロピー符号化に続いて、符号化されたビットストリームは、復号デバイス１１２に送信されるか、または復号デバイス１１２による後の送信または検索のためにアーカイブされ得る。エントロピー符号化ユニット５６はまた、コーディングされる現在ビデオスライスのために他のシンタックス要素および動きベクトルをエントロピー符号化し得る。
[0232] 逆量子化ユニット５８および逆変換処理ユニット６０は、参照ピクチャの参照ブロックとしての後の使用のために、ピクセル領域内で残差ブロックを再構成するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット４４は、参照ピクチャリスト内の参照ピクチャのうちの１つの予測ブロックに残差ブロックを加算することによって、参照ブロックを算出し得る。動き補償ユニット４４はまた、動き推定での使用のためにサブ整数ピクセル値を算出するために、１つまたは複数の補間フィルタを再構成された残差ブロックに適用し得る。加算器６２は、ピクチャメモリ６４中での記憶のための参照ブロックを作成するために、動き補償ユニット４４によって作成された動き補償された予測ブロックに、再構成された残差ブロックを加算する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。
[0233] このように、図６の符号化デバイス１０４は、符号化されたビデオビットストリームについてのシンタックスを生成するように構成されたビデオエンコーダの例を表している。符号化デバイス１０４は、例えば、上述されたように、ＶＰＳ、ＳＰＳ、およびＰＰＳパラメータセットを生成し得る。符号化デバイス１０４は、図６および図７に関して上述されたプロセスを含む、本明細書に記述される技法のうちの任意のものを行い得る。本開示の技法は、一般に、符号化デバイス１０４に関して記述されているが、上述されたように、本開示の技法のうちのいくつかはまた、後処理デバイス５７によって実装され得る。
[0234] 図７は、例示的な復号デバイス１１２を図示するブロック図である。復号デバイス１１２は、エントロピー復号ユニット８０、予測処理ユニット８１、逆量子化ユニット８６、逆変換処理ユニット８８、加算器９０、フィルタユニット９１、およびピクチャメモリ９２を含む。予測処理ユニット８１は、動き補償ユニット８２およびイントラ予測処理ユニット８４を含む。復号デバイス１１２は、いくつかの例では、図６からの符号化デバイス１０４に関して記述される符号化パスとは一般に逆の復号パスを行い得る。
[0235] 復号プロセス中、復号デバイス１１２は、符号化デバイス１０４によって送られた符号化されたビデオスライスのビデオブロックと、関連するシンタックス要素とを表現する符号化されたビデオビットストリームを受信する。いくつかの実施形態では、復号デバイス１１２は、符号化デバイス１０４から符号化されたビデオビットストリームを受信し得る。いくつかの実施形態では、復号デバイス１１２は、サーバ、媒体認識ネットワーク要素（ＭＡＮＥ）、ビデオエディタ／スプライサ、または上述された技法のうちの１つまたは複数を実装するように構成された他のそのようなデバイスなどの、ネットワークエンティティ７９から符号化されたビデオビットストリームを受信し得る。ネットワークエンティティ７９は、符号化デバイス１０４を含むことも含まないこともあり得る。本開示に記述される技法のうちのいくつかは、ネットワークエンティティ７９が、符号化されたビデオビットストリームを復号デバイス１１２に送信する前に、ネットワークエンティティ７９によって実装され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ７９および復号デバイス１１２は、別個のデバイスの一部であり得、一方、他の事例では、ネットワークエンティティ７９に関して記述された機能は、復号デバイス１１２を備えるものと同じデバイスによって実行され得る。
[0236] 復号デバイス１１２のエントロピー復号ユニット８０は、量子化された係数、動きベクトル、および他のシンタックス要素を生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット８０は、動きベクトルおよび他のシンタックス要素を予測処理ユニット８１に転送する。復号デバイス１１２は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。エントロピー復号ユニット８０は、ＶＰＳ、ＳＰＳ、およびＰＰＳのような、１つまたは複数のパラメータセット中の固定長シンタックス要素と可変長シンタックス要素との両方を処理および解析し得る。
[0237] ビデオスライスがイントラコード化された（Ｉ）スライスとしてコード化されるとき、予測処理ユニット８１のイントラ予測処理ユニット８４は、シグナリングされたイントラ予測モードおよびデータに基づいて現在フレームまたはピクチャの前に復号されたブロックから現在ビデオスライスのビデオブロックについての予測データを生成し得る。ビデオフレームがインターコーディングされた（すなわち、Ｂ、ＰまたはＧＰＢ）スライスとしてコーディングされるとき、予測処理ユニット８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックについての予測ブロックを作成する。予測ブロックは、参照ピクチャリスト内の参照ピクチャのうちの１つから作成され得る。復号デバイス１１２は、ピクチャメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト０およびリスト１を構成し得る。
[0238] 動き補償ユニット８２は、動きベクトルと他のシンタックス要素とを解析することによって現在ビデオスライスのビデオブロックのための予測情報を決定し、復号されている現在ビデオブロックの予測ブロックを作成するために、その予測情報を使用する。例えば、動き補償ユニット８２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（例えば、イントラまたはインター予測）と、インター予測スライスタイプ（例えば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）と、スライスのための１つまたは複数の参照ピクチャリストのための構成情報と、スライスの各インター符号化されたビデオブロックのための動きベクトルと、スライスの各インターコーディングされたビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報と、を決定するためにパラメータセット中の１つまたは複数のシンタックス要素を使用し得る。
[0239] 動き補償ユニット８２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット８２は、参照ブロックのサブ整数ピクセルについての補間された値を算出するために、ビデオブロックの符号化中に符号化デバイス１０４によって使用されるような補間フィルタを使用し得る。このケースでは、動き補償ユニット８２は、受信されたシンタックス要素から、符号化デバイス１０４によって使用された補間フィルタを決定し得、予測ブロックを作成するために、補間フィルタを使用し得る。
[0240] 逆量子化ユニット８６は、ビットストリーム中で提供され、かつエントロピー復号ユニット８０によって復号された、量子化された変換係数を逆量子化（inverse quantizes）、すなわち逆量子化（de-quantizes）する。逆量子化プロセスは、量子化の程度、および同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライス中の各ビデオブロックについて、符号化デバイス１０４によって算出された量子化パラメータの使用を含み得る。逆変換処理ユニット８８は、ピクセル領域における残差ブロックを作成するために、変換係数に、逆変換（例えば、逆ＤＣＴまたは他の適切な逆変換）、逆整数変換、または概念的に同様の逆変換プロセスを適用する。
[0241] 動き補償ユニット８２が、動きベクトルおよび他のシンタックス要素に基づいて現在ビデオブロックのための予測ブロックを生成した後、復号デバイス１１２は、逆変換処理ユニット８８からの残差ブロックを動き補償ユニット８２によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器９０は、この加算オペレーションを行う１つまたは複数の構成要素を表現する。所望される場合、ループフィルタ（コーディングループ中またはコーディングループ後のいずれか）もまた、ピクセル遷移を平滑化するために、またはそうでなければビデオ品質を改善するために使用され得る。フィルタユニット９１は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ）、およびサンプル適応オフセット（ＳＡＯ）フィルタなどの１つまたは複数のループフィルタを表現するよう意図されている。フィルタユニット９１は、インループフィルタとして図７に示されているが、他の構成では、フィルタユニット９１は、ポストループフィルタとして実装され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは次いで、後続の動き補償のために使用される参照ピクチャを記憶するピクチャメモリ９２に記憶される。ピクチャメモリ９２はまた、図１に示されるビデオ宛先デバイス１２２のようなディスプレイデバイス上での後のプレゼンテーションのための復号されたビデオを記憶する。
[0242] 上記の記述では、本願の態様がその特定の実施形態に関して記述されているが、当業者は、本発明がそれに限定されないことを理解するだろう。よって、本願の例示的な実施形態が本明細書で詳細に記述されているが、発明の概念は、他の方法で様々に具現化および用いられ得ること、および添付の特許請求の範囲が先行技術によって限定される場合を除き、そのような変形を含むように解釈されるよう意図されていることが理解されるべきである。上述された発明の様々な特徴および態様は、個々にまたは一緒に使用され得る。さらに、実施形態は、本明細書のより広範な趣旨および範囲から逸脱することなく、本明細書に記述されたものを超える任意のいくつかの環境および用途において利用することができる。従って、本明細書および図面は、限定的なものではなく、例示的なものと見なされるべきである。例示を目的として、方法が特定の順序で記述された。代替の実施形態では、方法は、記述されたものとは異なる順序で行われ得ることが理解されるべきである。
[0243] 構成要素が特定の動作を行う「ように構成される」ものとして記述される場合、そのような構成は、例えば、動作を行うように電子回路または他のハードウェアを設計することによって、動作を行うようにプログラマブル電子回路（例えば、マイクロプロセッサ、または他の適した電子回路）をプログラミングすることによって、またはそれらの任意の組み合わせで、達成されることができる。
[0244] 本明細書に開示されている実施形態に関連して記述された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組み合わせとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に例示するために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、上記では一般にそれらの機能に関して記述された。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定のアプリケーションおよび全体的なシステムに課される設計制約に依存する。当業者は、記述した機能を特定のアプリケーションごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈されるべきではない。
[0245] 本明細書に記述される技法は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせで実装され得る。このような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、または、ワイヤレス通信デバイスハンドセットおよび他のデバイスへのアプリケーションを含む複数の用途を有する集積回路デバイスのような、様々なデバイスの任意のもので実装され得る。モジュールまたは構成要素として記述された任意の特徴は、集積論理デバイスに一緒に、または個別であるが相互運用可能な論理デバイスとして別々に実装され得る。ソフトウェアで実装された場合、技法は、実行されると、上述される方法のうちの１つまたは複数を行う命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体（computer-readable data storage medium）によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含み得るコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）のようなランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュメモリ、磁気または光学データ記憶媒体などのような、メモリまたはデータ記憶媒体を備え得る。技法は、追加または代替として、伝搬信号または電波のような、命令またはデータ構造の形態でプログラムコードを搬送または通信し、コンピュータによってアクセスされ、読み取られ、および／または実行されることができるコンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
[0246] プログラムコードは、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の同等の集積回路またはディスクリート論理回路のような、１つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。このようなプロセッサは、本開示で記述される技法のうちの任意のものを行うように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。プロセッサは、コンピューティングデバイスの組み合わせ、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成としても実装され得る。従って、本明細書で使用される「プロセッサ」という用語は、前述の構造、前述の構造の任意の組み合わせ、または本明細書に記述された技法の実装に適切な任意の他の構造または装置のいずれかを指し得る。加えて、いくつかの態様では、本明細書に記述された機能は、符号化および復号のために構成された専用のソフトウェアまたはハードウェアモジュール内に提供され得るか、または複合ビデオエンコーダ−デコーダ（コーデック）に組み込まれ得る。
[0247] 本明細書に記述されたコーディング技法は、例となるビデオ符号化および復号システムにおける実施形態であり得る。システムは、宛先デバイスによって後で復号されるべき符号化されたビデオデータを提供するソースデバイスを含む。具体的には、ソースデバイスは、コンピュータ可読媒体を介してビデオデータを宛先デバイスに提供する。ソースデバイスおよび宛先デバイスは、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレイヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。いくつかのケースでは、ソースデバイスおよび宛先デバイスは、ワイヤレス通信に対応し得る。
[0248] 宛先デバイスは、コンピュータ可読媒体を介して、復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体は、符号化されたビデオデータをソースデバイスから宛先デバイスに移動することが可能な、任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体は、ソースデバイスが符号化されたビデオデータを宛先デバイスにリアルタイムで直接送信するのを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイスに送信され得る。通信媒体は、無線周波（ＲＦ）スペクトルあるいは１つまたは複数の物理送信線などの、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイスから宛先デバイスへの通信を容易にするために有用であり得る、ルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0249] いくつかの例では、符号化データは、出力インターフェースからストレージデバイスへ出力され得る。同様に、符号化データは、ストレージデバイスから入力インターフェースによってアクセスされ得る。記憶デバイスは、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは、符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような、様々な分散型のまたは局所的にアクセスされるデータ記憶媒体のうちの任意のものを含み得る。さらなる例では、記憶デバイスは、ソースデバイスによって生成された符号化されたビデオを記憶することができるファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイスは、ストリーミングまたはダウンロードを介して、記憶デバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶でき、符号化されたビデオデータを宛先デバイスに送信できる、任意のタイプのサーバであり得る。例示的なファイルサーバは、（例えば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワークアタッチドストレージ（ＮＡＳ：network attached storage）デバイス、またはローカルディスクドライブを含む。宛先デバイスは、インターネット接続を含む任意の標準データ接続を介して、符号化されたビデオデータにアクセスし得る。これは、ファイルサーバ上に記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデムなど）、またはその両方の組み合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組み合わせであり得る。
[0250] 本開示の技法は、ワイヤレスアプリケーションまたはワイヤレス設定に必ずしも限定されるものではない。本技法は、無線テレビジョンブロードキャスト、ケーブルテレビジョン送信、衛星テレビジョン送信、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションなどの、様々なマルチメディアアプリケーションのいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システムは、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオ電話のようなアプリケーションをサポートするために一方向または両方向のビデオ送信をサポートするように構成され得る。
[0251] 一例では、ソースデバイスは、ビデオソース、ビデオエンコーダ、および出力インターフェースを含む。宛先デバイスは、入力インターフェース、ビデオデコーダ、およびディスプレイデバイスを含み得る。ソースデバイスのビデオエンコーダは、本明細書で説明される技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または配列を含み得る。例えば、ソースデバイスは、外部カメラのような外部のビデオソースからのビデオデータを受信し得る。同様に、宛先デバイスは、統合されたディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースし得る。
[0252] 上記の例示的なシステムは単に一例に過ぎない。同時にビデオデータを処理するための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって行われ得る。一般に、本開示の技法は、ビデオ符号化デバイスによって行われるが、これらの技法はまた、通常は「コーデック（ＣＯＤＥＣ）」と呼ばれるビデオエンコーダ／デコーダによっても行われ得る。さらに、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイスおよび宛先デバイスは、ソースデバイスが、宛先デバイスに送信するためのコーディングされたビデオデータを生成するこのようなコーディングデバイスの例に過ぎない。いくつかの例では、ソースおよび宛先デバイスは、デバイスの各々がビデオ符号化および復号構成要素を含むように、実質的に対称の方法で動作し得る。故に、例示的なシステムは、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のためのビデオデバイス間の一方向または双方向のビデオ送信をサポートし得る。
[0253] ビデオソースは、ビデオカメラのようなビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソースは、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組み合わせを生成し得る。いくつかのケースでは、ビデオソースがビデオカメラである場合、ソースデバイスおよび宛先デバイスは、いわゆるカメラ付き電話またはビデオ付き電話を形成し得る。しかしながら、上述されたように、本開示で説明される技法は、一般にビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。各ケースでは、キャプチャされたビデオ、前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダによって符号化され得る。符号化されたビデオ情報は次いで、出力インターフェースによってコンピュータ可読媒体上で出力され得る。
[0254] 記載されるように、コンピュータ可読媒体は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいは、ハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Ｂｌｕ−ｒａｙディスク、または他のコンピュータ可読媒体のような記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、例えば、ネットワーク送信を介して、ソースデバイスから符号化されたビデオデータを受信し、宛先デバイスに符号化されたビデオデータを提供し得る。同様に、ディスクスタンピング設備などの媒体製造設備のコンピューティングデバイスは、ソースデバイスから符号化されたビデオデータを受信し、符号化されたビデオデータを含むディスクを作成し得る。従って、コンピュータ可読媒体は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解され得る。
[0255] 宛先デバイスの入力インターフェースは、コンピュータ可読媒体から情報を受け取る。コンピュータ可読媒体の情報は、ブロックおよび他のコード化された単位、例えば、ピクチャグループ（ＧＯＰ：group of pictures）の特性および／または処理を記述するシンタックス要素を含む、ビデオエンコーダによって定義されるシンタックス情報を含み得、これは、ビデオデコーダによっても使用される。ディスプレイデバイスは、復号されたビデオデータをユーザに表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような様々なディスプレイデバイスのうちの任意のものを備え得る。本発明の様々な実施形態が説明された。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
仮想現実ビデオデータを処理する方法であって、
前記仮想現実ビデオデータを取得することと、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、
前記仮想現実ビデオデータの領域を決定することと、ここにおいて、前記領域は、前記３６０度ビューのサブセクションを含み、
前記領域のためのデータ構造を生成することと、前記データ構造は、前記領域を記述するパラメータを含み、ここにおいて、前記パラメータは、前記領域に関連付けられたソースを示すパラメータを含み、
前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
前記ファイルに前記仮想現実ビデオデータを記憶することと、
前記ファイルに前記データ構造を記憶することと
を備える、方法。
［Ｃ２］
前記領域は、前記仮想現実ビデオデータを閲覧しているとき、ビューポートとして使用されることができる、Ｃ１に記載の方法。
［Ｃ３］
前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、Ｃ１に記載の方法。
［Ｃ４］
前記ボックス構造中の領域数の値は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、Ｃ３に記載の方法。
［Ｃ５］
前記ボックス構造中の領域数の値は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、Ｃ３に記載の方法。
［Ｃ６］
前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、Ｃ１に記載の方法。
［Ｃ７］
前記領域に関連付けられた前記ソースは、コンテンツクリエイターである、Ｃ１に記載の方法。
［Ｃ８］
前記領域に関連付けられた前記ソースは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す、Ｃ１に記載の方法。
［Ｃ９］
仮想現実ビデオデータを処理するための装置であって、
ビデオデータを記憶するように構成されたメモリと、
プロセッサと
を備え、前記プロセッサは、
前記仮想現実ビデオデータを取得することと、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、
前記仮想現実ビデオデータの領域を決定することと、ここにおいて、前記領域は、前記３６０度ビューのサブセクションを含み、
前記領域のためのデータ構造を生成することと、前記データ構造は、前記領域を記述するパラメータを含み、ここにおいて、前記パラメータは、前記領域に関連付けられたソースを示すパラメータを含み、
前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
前記ファイルに前記仮想現実ビデオデータを記憶することと、
前記ファイルに前記データ構造を記憶することと
を行うように構成される、装置。
［Ｃ１０］
前記領域は、前記仮想現実ビデオデータを閲覧しているとき、ビューポートとして使用されることができる、Ｃ９に記載の装置。
［Ｃ１１］
前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、Ｃ９に記載の装置。
［Ｃ１２］
前記ボックス構造中の領域数の値は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、Ｃ１１に記載の装置。
［Ｃ１３］
前記ボックス構造中の領域数の値は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、Ｃ１１に記載の装置。
［Ｃ１４］
前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、Ｃ９に記載の装置。
［Ｃ１５］
前記領域に関連付けられた前記ソースは、コンテンツクリエイターである、Ｃ９に記載の装置。
［Ｃ１６］
前記領域に関連付けられた前記ソースは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す、Ｃ９に記載の装置。
［Ｃ１７］
プロセッサによって実行されたとき、前記プロセッサに、仮想現実ビデオデータを処理するための動作を行わせる命令を記憶した非一時的コンピュータ可読媒体であって、前記動作は、
前記仮想現実ビデオデータの領域を決定することと、ここにおいて、前記領域は、前記３６０度ビューのサブセクションを含み、
前記領域のためのデータ構造を生成することと、前記データ構造は、前記領域を記述するパラメータを含み、ここにおいて、前記パラメータは、前記領域に関連付けられたソースを示すパラメータを含み、
前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
前記ファイルに前記仮想現実ビデオデータを記憶することと、
前記ファイルに前記データ構造を記憶することと
を含む、非一時的コンピュータ可読媒体。
［Ｃ１８］
前記領域は、前記仮想現実ビデオデータを閲覧しているとき、ビューポートとして使用されることができる、Ｃ１７に記載の非一時的コンピュータ可読媒体。
［Ｃ１９］
前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、Ｃ１７に記載の非一時的コンピュータ可読媒体。
［Ｃ２０］
前記ボックス構造中の領域数の値は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、Ｃ１９に記載の非一時的コンピュータ可読媒体。
［Ｃ２１］
前記ボックス構造中の領域数の値は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、Ｃ１９に記載の非一時的コンピュータ可読媒体。
［Ｃ２２］
前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、Ｃ１７に記載の非一時的コンピュータ可読媒体。
［Ｃ２３］
前記領域に関連付けられた前記ソースは、コンテンツクリエイターである、Ｃ１７に記載の非一時的コンピュータ可読媒体。
［Ｃ２４］
前記領域に関連付けられた前記ソースは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す、Ｃ１７に記載の非一時的コンピュータ可読媒体。
［Ｃ２５］
仮想現実ビデオデータを処理するための装置であって、
前記仮想現実ビデオデータを取得するための手段と、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、
前記仮想現実ビデオデータの領域を決定するための手段と、ここにおいて、前記領域は、前記３６０度ビューのサブセクションを含み、
前記領域のためのデータ構造を生成するための手段と、前記データ構造は、前記領域を記述するパラメータを含み、ここにおいて、前記パラメータは、前記領域に関連付けられたソースを示すパラメータを含み、
前記仮想現実ビデオデータを記憶するためのファイルを生成するための手段と、
前記ファイルに前記仮想現実ビデオデータを記憶するための手段と、
前記ファイルに前記データ構造を記憶するための手段と
を備える、装置。

Claims (21)

  1. 仮想現実ビデオデータを処理する方法であって、
    前記仮想現実ビデオデータを取得すること、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、と、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、前記３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記複数の領域のうちの前記第１の領域のための第１のソースまたは前記複数の領域のうちの前記第２の領域のための第２のソースのうちの少なくとも１つは、コンテンツクリエイターによって指定されたソースであることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を備える、方法。
  2. 仮想現実ビデオデータを処理する方法であって、
    前記仮想現実ビデオデータを取得すること、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、と、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、前記３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を備える、方法。
  3. 前記第１の領域および前記第２の領域は、前記仮想現実ビデオデータが閲覧されるとき、ビューポートとして使用されるように構成される、請求項１または２に記載の方法。
  4. 前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、請求項１または２に記載の方法。
  5. 前記ボックス構造中の領域数は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、請求項４に記載の方法。
  6. 前記ボックス構造中の領域数は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、請求項４に記載の方法。
  7. 前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、請求項１または２に記載の方法。
  8. 仮想現実ビデオデータを処理するための装置であって、
    ビデオデータを記憶するように構成されたメモリと、
    プロセッサと
    を備え、前記プロセッサは、
    前記仮想現実ビデオデータを取得すること、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、と、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、前記３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記複数の領域のうちの前記第１の領域のための第１のソースまたは前記複数の領域のうちの前記第２の領域のための第２のソースのうちの少なくとも１つは、コンテンツクリエイターによって指定されたソースであることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を行うように構成される、装置。
  9. 仮想現実ビデオデータを処理するための装置であって、
    ビデオデータを記憶するように構成されたメモリと、
    プロセッサと
    を備え、前記プロセッサは、
    前記仮想現実ビデオデータを取得すること、ここにおいて、前記仮想現実ビデオデータは、仮想環境の３６０度ビューを表現し、と、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、前記３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を行うように構成される、装置。
  10. 前記第１の領域および前記第２の領域は、前記仮想現実ビデオデータが閲覧されるとき、ビューポートとして使用されるように構成される、請求項８または９に記載の装置。
  11. 前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、請求項８または９に記載の装置。
  12. 前記ボックス構造中の領域数は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、請求項１１に記載の装置。
  13. 前記ボックス構造中の領域数は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、請求項１１に記載の装置。
  14. 前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、請求項８または９に記載の装置。
  15. プロセッサによって実行されたとき、前記プロセッサに、仮想現実ビデオデータを処理するための動作を行わせる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記動作は、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記複数の領域のうちの前記第１の領域のための第１のソースまたは前記複数の領域のうちの前記第２の領域のための第２のソースのうちの少なくとも１つは、コンテンツクリエイターによって指定されたソースであることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を含む、非一時的コンピュータ可読記憶媒体。
  16. プロセッサによって実行されたとき、前記プロセッサに、仮想現実ビデオデータを処理するための動作を行わせる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記動作は、
    前記仮想現実ビデオデータの複数の領域を決定すること、ここにおいて、前記複数の領域のうちの第１の領域は、３６０度ビューの第１のサブセクションを含み、前記複数の領域のうちの第２の領域は、前記３６０度ビューの第２のサブセクションを含み、と、
    前記複数の領域に関して、前記複数の領域を記述するパラメータを含むデータ構造を生成すること、ここにおいて、前記パラメータは、前記複数の領域のうちの前記第１の領域に関連付けられたソースを示す第１のパラメータと、前記複数の領域のうちの前記第２の領域に関連付けられたソースを示す第２のパラメータとを含み、前記第１のパラメータのための第１の数値または、前記第２のパラメータのための第２の数値のうちの少なくとも１つは、前記領域が前記仮想現実ビデオデータの最も多く閲覧された領域であることを示す固有の数値であり、ここにおいて、前記第１の数値、及び第２の数値は位置を示さない、と、
    前記仮想現実ビデオデータを記憶するためのファイルを生成することと、
    前記ファイルに前記仮想現実ビデオデータを記憶することと、
    前記ファイルに前記データ構造を記憶することと
    を含む、非一時的コンピュータ可読記憶媒体。
  17. 前記第１の領域および前記第２の領域は、前記仮想現実ビデオデータが閲覧されるとき、ビューポートとして使用されるように構成される、請求項１５または１６に記載の非一時的コンピュータ可読記憶媒体。
  18. 前記ファイルは、コンテナファイルであり、前記コンテナファイルは、フォーマットに従って編成され、前記データ構造は、前記フォーマットによって記述されたボックス構造に記憶される、請求項１５または１６に記載の非一時的コンピュータ可読記憶媒体。
  19. 前記ボックス構造中の領域数は、１より大きくなることが可能であり、前記仮想現実ビデオデータが１より多い領域を含むとき、前記領域および前記１より多い領域のためのパラメータは、同じタイムドメタデータトラックに記憶されることができる、請求項１８に記載の非一時的コンピュータ可読記憶媒体。
  20. 前記ボックス構造中の領域数は、１に限定され、前記仮想現実ビデオデータが１より多い領域を含むとき、前記１より多い領域のためのパラメータは、異なるタイムドメタデータトラックに記憶される、請求項１８に記載の非一時的コンピュータ可読記憶媒体。
  21. 前記仮想現実ビデオデータは、符号化されたビットストリームとして前記ファイルに記憶され、前記データ構造は、前記符号化されたビットストリームのメッセージ要素に記憶される、請求項１５または１６に記載の非一時的コンピュータ可読記憶媒体。
JP2019571692A 2017-07-05 2018-07-03 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング Active JP6874169B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2021024259A JP2021100256A (ja) 2017-07-05 2021-02-18 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762528926P 2017-07-05 2017-07-05
US62/528,926 2017-07-05
US16/025,801 US10679415B2 (en) 2017-07-05 2018-07-02 Enhanced signaling of regions of interest in container files and video bitstreams
US16/025,801 2018-07-02
PCT/US2018/040748 WO2019010198A1 (en) 2017-07-05 2018-07-03 ENHANCED SIGNALING OF INTERESTING REGIONS IN CONTAINER FILES AND VIDEO BIT TRAINS

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021024259A Division JP2021100256A (ja) 2017-07-05 2021-02-18 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング

Publications (2)

Publication Number Publication Date
JP2020526958A JP2020526958A (ja) 2020-08-31
JP6874169B2 true JP6874169B2 (ja) 2021-05-19

Family

ID=64902840

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2019571692A Active JP6874169B2 (ja) 2017-07-05 2018-07-03 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング
JP2021024259A Withdrawn JP2021100256A (ja) 2017-07-05 2021-02-18 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2021024259A Withdrawn JP2021100256A (ja) 2017-07-05 2021-02-18 コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング

Country Status (9)

Country Link
US (1) US10679415B2 (ja)
EP (1) EP3649555B1 (ja)
JP (2) JP6874169B2 (ja)
KR (1) KR102185811B1 (ja)
CN (1) CN110809758B (ja)
AU (1) AU2018298046B2 (ja)
BR (1) BR112019027833A2 (ja)
TW (1) TWI712309B (ja)
WO (1) WO2019010198A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190052129A (ko) 2016-10-04 2019-05-15 김기백 영상 데이터 부호화/복호화 방법 및 장치
US20190238888A1 (en) * 2017-07-17 2019-08-01 Ki Baek Kim Image data encoding/decoding method and apparatus
CN110073662B (zh) * 2016-11-17 2023-07-18 英特尔公司 全景视频的建议视口指示方法及装置
WO2018131813A1 (en) * 2017-01-10 2018-07-19 Samsung Electronics Co., Ltd. Method and apparatus for generating metadata for 3d images
TWI681662B (zh) * 2017-08-18 2020-01-01 聯發科技股份有限公司 用於減少基於投影的圖框中的偽影的方法和裝置
US10827159B2 (en) * 2017-08-23 2020-11-03 Mediatek Inc. Method and apparatus of signalling syntax for immersive video coding
WO2020256615A1 (en) * 2019-06-21 2020-12-24 Telefonaktiebolaget Lm Ericsson (Publ) Video coding layer up-switching indication
CN112423108B (zh) * 2019-08-20 2023-06-30 中兴通讯股份有限公司 码流的处理方法、装置、第一终端、第二终端及存储介质
US11816757B1 (en) * 2019-12-11 2023-11-14 Meta Platforms Technologies, Llc Device-side capture of data representative of an artificial reality environment
CN115336273A (zh) 2020-03-19 2022-11-11 字节跳动有限公司 用于图片编解码的帧内随机访问点
US11601655B2 (en) 2020-05-21 2023-03-07 Alibaba Group Holding Limited Tile and slice partitioning in video processing
WO2021237129A1 (en) 2020-05-22 2021-11-25 Bytedance Inc. Indication of end of sequence in coded video
JPWO2021251185A1 (ja) * 2020-06-11 2021-12-16
EP4176587A1 (en) * 2020-07-03 2023-05-10 Telefonaktiebolaget LM ERICSSON (PUBL) Media content insertion in a virtual enviroment
KR20220010907A (ko) 2020-07-20 2022-01-27 삼성전자주식회사 3d(ar) 미디어 랜덤 액세스를 위한 방법 및 장치
CN115686182B (zh) * 2021-07-22 2024-02-27 荣耀终端有限公司 增强现实视频的处理方法与电子设备

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090164883A1 (en) * 2007-12-19 2009-06-25 Apple Inc. Multi-Source Web Clips
JP2012505569A (ja) * 2008-10-07 2012-03-01 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 多視点メディアデータ
US10440329B2 (en) 2009-05-22 2019-10-08 Immersive Media Company Hybrid media viewing application including a region of interest within a wide field of view
KR20200045013A (ko) 2013-07-15 2020-04-29 소니 주식회사 상호작용성을 위한 모션-구속된 타일 세트들 sei 메시지의 확장들
JP6467680B2 (ja) * 2014-01-10 2019-02-13 パナソニックＩｐマネジメント株式会社 ファイル生成方法およびファイル生成装置
WO2015126144A1 (ko) * 2014-02-18 2015-08-27 엘지전자 주식회사 파노라마 서비스를 위한 방송 신호 송수신 방법 및 장치
EP3162074A1 (en) * 2014-06-27 2017-05-03 Koninklijke KPN N.V. Determining a region of interest on the basis of a hevc-tiled video stream
US9799143B2 (en) * 2014-08-15 2017-10-24 Daqri, Llc Spatial data visualization
US9997199B2 (en) 2014-12-05 2018-06-12 Warner Bros. Entertainment Inc. Immersive virtual reality production and playback for storytelling content
US20160373771A1 (en) 2015-06-18 2016-12-22 Qualcomm Incorporated Design of tracks and operation point signaling in layered hevc file format
EP3362991A1 (en) 2015-10-17 2018-08-22 Arivis AG Direct volume rendering in virtual and/or augmented reality
US11019257B2 (en) * 2016-05-19 2021-05-25 Avago Technologies International Sales Pte. Limited 360 degree video capture and playback
BR112019003605A2 (pt) * 2016-08-25 2019-05-21 Lg Electronics Inc. método para transmitir vídeo omnidirecional, método para receber vídeo omnidirecional, aparelho para transmitir vídeo omnidirecional, e aparelho para receber vídeo omnidirecional
US10623635B2 (en) * 2016-09-23 2020-04-14 Mediatek Inc. System and method for specifying, signaling and using coding-independent code points in processing media contents from multiple media sources
US10580167B1 (en) * 2017-01-24 2020-03-03 Amazon Technologies, Inc. Excluding masked regions of virtual reality (VR) frames from encoder processing
US11532128B2 (en) * 2017-03-23 2022-12-20 Qualcomm Incorporated Advanced signaling of regions of interest in omnidirectional visual media

Also Published As

Publication number Publication date
US20190012839A1 (en) 2019-01-10
EP3649555B1 (en) 2023-06-28
TWI712309B (zh) 2020-12-01
JP2020526958A (ja) 2020-08-31
WO2019010198A1 (en) 2019-01-10
KR20200027480A (ko) 2020-03-12
AU2018298046A1 (en) 2019-12-19
KR102185811B1 (ko) 2020-12-03
BR112019027833A2 (pt) 2020-07-07
CN110809758A (zh) 2020-02-18
EP3649555A1 (en) 2020-05-13
TW201907706A (zh) 2019-02-16
CN110809758B (zh) 2023-11-24
JP2021100256A (ja) 2021-07-01
US10679415B2 (en) 2020-06-09
AU2018298046B2 (en) 2021-02-11

Similar Documents

Publication Publication Date Title
JP6874169B2 (ja) コンテナファイルおよびビデオビットストリームにおける関心領域の発展型シグナリング
US11062738B2 (en) Signalling of video content including sub-picture bitstreams for video coding
US10389999B2 (en) Storage of virtual reality video in media files
JP6799159B2 (ja) 関心領域のシグナリングのシステムおよび方法
US11532128B2 (en) Advanced signaling of regions of interest in omnidirectional visual media
JP2019517212A (ja) バーチャル・リアリティにおける円周魚眼ビデオ
CN110178379B (zh) 以文件格式用信号表示重要视频信息的方法和设备
KR102105804B1 (ko) 비디오를 위한 개선된 제약 스킴 설계

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200709

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200709

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20200709

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20201008

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201020

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201130

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20210105

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210218

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20210218

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20210301

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20210302

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210323

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210421

R150 Certificate of patent or registration of utility model

Ref document number: 6874169

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150