JP7492978B2 - ビデオエンコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム - Google Patents

ビデオエンコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム Download PDF

Info

Publication number
JP7492978B2
JP7492978B2 JP2021576016A JP2021576016A JP7492978B2 JP 7492978 B2 JP7492978 B2 JP 7492978B2 JP 2021576016 A JP2021576016 A JP 2021576016A JP 2021576016 A JP2021576016 A JP 2021576016A JP 7492978 B2 JP7492978 B2 JP 7492978B2
Authority
JP
Japan
Prior art keywords
image
bitstream
sub
coded
tile
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
JP2021576016A
Other languages
English (en)
Other versions
JP2022537576A (ja
Inventor
ミスカ ハヌクセラ
Original Assignee
ノキア テクノロジーズ オサケユイチア
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 ノキア テクノロジーズ オサケユイチア filed Critical ノキア テクノロジーズ オサケユイチア
Publication of JP2022537576A publication Critical patent/JP2022537576A/ja
Application granted granted Critical
Publication of JP7492978B2 publication Critical patent/JP7492978B2/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/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
    • 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
    • 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
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/139—Format conversion, e.g. of frame-rate or size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/194—Transmission of image 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/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • 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/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • 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/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • 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/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/187—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a scalable video layer
    • 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/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/1883—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit relating to sub-band structure, e.g. hierarchical level, directional tree, e.g. low-high [LH], high-low [HL], high-high [HH]
    • 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
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本発明は、ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラムに関する。
本項は、特許請求の範囲に記載の本発明の背景または状況を提供することを目的とする。本明細書には、実現可能な概念を含み得るものの、必ずしも従来から着想されているものでもなければ、成し遂げられているものでもない。したがって、本明細書における別段の指定のない限り、本項に記載の内容は、本願の明細書および特許請求の範囲の先行技術ではなく、本項への記載によって先行技術と認められるものでもない。
ビデオコーディングシステムは、入力ビデオを格納／伝送に適した圧縮表現へと変換するエンコーダと、圧縮されたビデオ表現を解凍して可視形態に戻すことができるデコーダと、を備え得る。エンコーダは、ビデオをよりコンパクトな形態で表現するため、たとえば、その他の場合に要するよりも低いビットレートでのビデオ情報の格納／伝送を可能とするため、元のビデオシーケンスに含まれる一部の情報を破棄する場合がある。
ビデオコーディングの規格および仕様では通常、エンコーダがコード化画像（ｃｏｄｅｄ ｐｉｃｔｕｒｅ）を部分集合へと分割（ｄｉｖｉｄｅ）すなわち分離（ｐａｒｔｉｔｉｏｎ）することができる。ビデオコーディングにおいては、画像または画像の小領域の各要素が厳密に部分集合（ブロック）のうちの１つに含まれるように、画像または画像の小領域の部分集合（ブロック）への分割として分離が規定され得る。たとえば、Ｈ．２６５／ＨＥＶＣでは、デフォルトで６４×６４ピクセルのサイズを有するコーディングツリー単位（ＣＴＵ）の概念を導入している。ＣＴＵは、単一のコーディング単位（ＣＵ）を含むことも可能であるし、四分木構造に基づいて、最低８×８ピクセルの複数のより小さなＣＵへと再帰的に分割することも可能である。また、Ｈ．２６５／ＨＥＶＣでは、長方形かつ整数個のＣＴＵを含むタイルと、タイルスキャンにおいて連続的に並べられ、単一のＮＡＬ単位に含まれる整数個のコーティングツリー単位を含むスライスセグメントに基づいて規定されたスライスと、を認識する。ＨＥＶＣ規格においては、タイルへの分離によって、（ＣＴＵにおける）タイル列幅のリストおよび（ＣＴＵにおける）タイル行高さのリストを特徴とし得るグリッドが形成される。タイルは、ビットストリームにおいて、タイルグリッドのラスタースキャンの順序で連続して並べられている。タイルには、整数個のスライスを含み得る。
イメージは、独立コーディングおよびデコーディング可能なイメージセグメントまたは画像領域（たとえば、スライス、タイル、またはタイル群）に分割可能である。このようなイメージセグメントは、並列処理を可能にし得る。本明細書において、「スライス」は、デフォルトのコーディングまたはデコーディング順序で処理される特定個数の基本コーディング単位で構成されたイメージセグメントを表し得る。一方、「タイル」は、長方形のイメージ領域として規定されたイメージセグメントを表し得る。タイル群は、一群の１つまたは複数のタイルとして規定され得る。イメージセグメントは、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおけるＶＣＬ ＮＡＬ単位等、ビットストリームにおける別個の単位としてコーディングされ得る。コード化イメージセグメントは、ヘッダおよびペイロードを含み得るが、このヘッダは、ペイロードのデコーディングに必要なパラメータ値を含む。
独立コード化画像領域を１つまたは複数のソースビットストリームから結合ビットストリームへと結合するには、パラメータ集合の書き換えが必要である。言い換えると、ソースビットストリーム中のパラメータ集合は、そのままでは適用不可能である。たとえば、結合ビットストリームにおける画像幅、画像高さ、ならびに／またはタイルおよびブリックへの画像分離は、ソースビットストリームのいずれとも異なる可能性がある。
上記問題を少なくとも軽減するため、本明細書においては、改良されたエンコーディング方法を導入する。いくつかの実施形態においては、ビデオコーディングおよびデコーディングのための方法、装置、およびコンピュータプログラム製品が提供される。
一実施形態において、独立デコーディング可能な画像領域を結合するクライアント機器は、独立デコーディング可能な画像領域を単一の（結合）ビットストリームとして結合するプレーヤまたはその他任意のエンティティと、結合ビットストリームをデコーディングするデコーダと、を備える。プレーヤは、結合ビットストリーム、たとえば、一度に１つのアクセス単位、一度に１つのコード化ビデオシーケンス、または一度にビットストリーム全体をデコーダに受け渡すようにしてもよい。
一実施形態において、利用可能な一連の独立デコーディング可能な画像領域から結合ビットストリームを生成するため、プレーヤは、以下を実行する。
プレーヤは、そのデコーディング機能に適した１つまたは複数のパラメータ集合を生成または受信する。１つまたは複数のパラメータ集合は、タイル、ブリック、および長方形スライス等のイメージセグメントへの画像の分離を示す。
プレーヤは、受信する独立デコーディング可能な画像領域シーケンスの部分集合を選択する。
プレーヤは、部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号を取得する。識別子番号は、たとえば長方形スライスの識別子番号であってもよく、識別子番号は、スライスのヘッダシンタックスに含まれる。
プレーヤは、結合ビットストリームにおいて、識別子番号が結合ビットストリームの各コード化画像に対して現れる順序で部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号のリストを含む別個のデータ単位を生成する。データ単位は、たとえばデコーディング制御ＮＡＬ単位であってもよい。
プレーヤは、選択した独立デコーディング可能な画像領域のＶＣＬ ＮＡＬ単位等のデータ単位を受信し、結合ビットストリームにおいて別個のデータ単位の後に、デコーディング順序で配置する。
選択から受信までの上記ステップは、たとえば視認方向の変化への応答として、独立デコーディング可能な画像領域の新たな選択が必要となった場合にいつでも繰り返すことができる。
一実施形態において、エンティティは、独立コード化画像領域を含むエンコードコンテンツをカプセル化および／または記述する。エンティティは、独立コード化画像領域を含む１つまたは複数のビットストリームをカプセル化したコンテナファイルを生成するファイル記述器（ｆｉｌｅ ｗｒｉｔｅｒ）であってもよい。別の実施形態において、エンティティは、１つもしくは複数のビットストリームを含むコンテナファイル中の情報ならびに／またはビットストリームそれ自体からストリーミングマニフェストを生成するストリーミングマニフェスト生成器である。
一実施形態において、エンティティは、以下のうちの１つまたは複数を実行する。
エンティティは、独立デコーディング可能な画像領域シーケンスを含む１つまたは複数のビットストリームを入力として取得する。
エンティティは、ビットストリームから独立デコーディング可能な画像領域シーケンスを抽出し、メディアプレゼンテーション記述において個々にアクセス可能とする。たとえば、ファイル記述器は、１つまたは複数のコンテナファイルにおける別個のトラックとして、独立デコーディング可能な各画像領域シーケンスをカプセル化可能であるが、この場合は、ＭｏｖｉｅＢｏｘおよびそれに含まれるすべてのボックス等のファイルメタデータをメディアプレゼンテーション記述と見なすことができる。別の例においては、ＤＡＳＨ ＭＰＤまたは同等のものにおけるＲｅｐｒｅｓｅｎｔａｔｉｏｎまたは同等のものとして、ストリーミングマニフェスト生成器が独立デコーディング可能な各画像領域シーケンスを発表する。さらに別の例において、ストリーミングマニフェスト生成器は、伝送セグメント（たとえば、ＤＡＳＨのＭｅｄｉａ Ｓｅｇｍｅｎｔ）の識別および／または要求に使用可能なＨＴＴＰ ＵＲＬ等のリソース識別子を示す情報をメディアプレゼンテーション記述に含める。
エンティティは、メディアプレゼンテーション記述において、独立デコーディング可能な画像領域シーケンスに識別子番号を割り当てる。
一例において、ファイル記述器は、独立コード化画像領域シーケンスの識別子番号を以下のコンテナのうちの１つまたは複数に含める。
サンプルエントリ
デコーダ設定レコード
サンプル群記述エントリ
別の例において、ストリーミングマニフェスト生成器は、以下のうちの１つまたは複数のように、独立コード化画像領域シーケンスの識別子番号を含める。
たとえばＲｅｐｒｅｓｅｎｔａｔｉｏｎまたはＳｕｂ－Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおける特定の属性の値として含める。
特定の記述子要素等の特定の要素において、たとえばＲｅｐｒｅｓｅｎｔａｔｉｏｎまたはＳｕｂ－Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおいて含める。
エンティティは、１つまたは複数のビットストリーム、たとえば、その中のパラメータ集合および／またはスライスヘッダから、独立コード化画像領域シーケンスの識別子番号を取得するようにしてもよい。
他の実施形態から独立した適用または他の実施形態と併せた適用が可能な一実施形態において、エンティティは、以下のうちの１つまたは複数を実行する。
エンティティは、目標画像サイズならびに／またはタイル、ブリック、および／もしくは長方形スライス等のイメージセグメントへの画像分離等、目標とする結合ビットストリームの特性を決定する。
エンティティは、目標とする結合ビットストリームごとにパラメータ集合を生成する。パラメータ集合は、ビデオデコーディングに直接適していてもよいし、ビデオデコーディングに適するように付加または記入する必要があるテンプレートであってもよい。たとえば、テンプレートのパラメータ集合からは、プロファイル階層レベル情報が省略されていてもよい。パラメータ集合は、画像のイメージセグメント（タイル、ブリック、および／または長方形スライス等）への分離を示すシンタックス要素を含み、パラメータ集合中のイメージセグメントの空間サイズが独立デコーディング可能な画像領域シーケンスの空間サイズに一致する。
パラメータ集合は、メディアプレゼンテーション記述において利用可能となるか、または、メディアプレゼンテーション記述を通じて利用可能となる。パラメータ集合が利用可能となる様態の選択肢としては、以下が挙げられるが、これらに限定されない。
ファイル生成器がコンテナファイルにおけるベーストラックを生成する。パラメータ集合は、ベーストラックの１つもしくは複数のサンプルエントリ、ベーストラックのサンプル、ならびに／またはベーストラックと関連付けられたパラメータ集合トラックに含まれる。結合ビットストリームに含まれる好適な独立コード化画像領域シーケンスを含むトラックは、トラック基準によって示され、以下の選択肢が挙げられるが、これらに限定されない。
独立コード化画像領域シーケンスを含むトラックのＩＤをトラッキングするベーストラックの特定のトラック基準であって、この特定のトラック基準は、パラメータ集合において示される独立コード化画像領域に利用可能な任意の場所における結合に対して、トラックＩＤにより識別されるトラックのいずれかが適することを示していてもよい。
コード化画像内のデコーディング順序の独立コード化画像領域にそれぞれ対応するトラックＩＤまたはトラック群ＩＤをトラッキングするベーストラックの特定のトラック基準であって、このトラック基準は、トラック群ＩＤにより識別されるトラック群から任意のトラックを選択した後、トラック基準においてリスト化された順序にて、識別または選択したトラックのサンプルを並べることにより、結合ビットストリーム中のコード化画像を生成可能であるものと規定する。
ストリーミングマニフェスト生成器は、ＤＡＳＨ ＭＰＤにおけるＰｒｅｓｅｌｅｃｔｉｏｎの主要なＡｄａｐｔａｔｉｏｎ Ｓｅｔを生成する。主要なＡｄａｐｔａｔｉｏｎ Ｓｅｔは、上記説明のようなベーストラックを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを含む。パラメータ集合は、（サンプルエントリ内の）ＲｅｐｒｅｓｅｎｔａｔｉｏｎのＩｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの特定の属性、および／またはＲｅｐｒｅｓｅｎｔａｔｉｏｎの特定の記述子要素等の特定の要素に含まれる。
第１の態様に係る方法は、
コード化ビデオシーケンスがビットストリームの特定の位置で開始になると決定することであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のネットワーク抽象化レイヤ（ＮＡＬ）単位を含む、決定することと、
アクセス単位デリミタにおいて、当該アクセス単位デリミタと関連付けられたＮＡＬ単位をコード化ビデオシーケンスの始端として処理するように指示することと、
を含む。
第２の態様に係る装置は、少なくとも１つのプロセッサおよびコンピュータプログラムコードを含む少なくとも１つのメモリを備え、メモリおよびコンピュータプログラムコードは、少なくとも１つのプロセッサによって、
コード化ビデオシーケンスがビットストリームの特定の位置で開始になると決定することであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のネットワーク抽象化レイヤ（ＮＡＬ）単位を含む、決定することと、
アクセス単位デリミタにおいて、当該アクセス単位デリミタと関連付けられたＮＡＬ単位をコード化ビデオシーケンスの始端として処理するように指示することと、
を少なくとも当該装置に実行させるように構成されている。
第３の態様に係るコンピュータプログラム製品は、少なくとも１つのプロセッサ上で実行された場合に、
コード化ビデオシーケンスがビットストリームの特定の位置で開始になると決定することであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のネットワーク抽象化レイヤ（ＮＡＬ）単位を含む、決定することと、
アクセス単位デリミタにおいて、当該アクセス単位デリミタと関連付けられたＮＡＬ単位をコード化ビデオシーケンスの始端として処理するように指示することと、
を装置またはシステムに行わせるように構成されたコンピュータプログラムコードを含む。
第４の態様に係る装置は、
コード化ビデオシーケンスがビットストリームの特定の位置で開始になると決定する手段であり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のネットワーク抽象化レイヤ（ＮＡＬ）単位を含む、決定する手段と、
アクセス単位デリミタにおいて、当該アクセス単位デリミタと関連付けられたＮＡＬ単位をコード化ビデオシーケンスの始端として処理するように指示する手段と、
を備える。
第５の態様に係る方法は、
アクセス単位デリミタからデコーディングすることであって、アクセス単位デリミタと関連付けられたネットワーク抽象化レイヤ（ＮＡＬ）単位をコード化ビデオシーケンスの始端として処理する、デコーディングすることであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のＮＡＬ単位を含む、デコーディングすることを含む。
第６の態様に係る装置は、少なくとも１つのプロセッサおよびコンピュータプログラムコードを含む少なくとも１つのメモリを備え、メモリおよびコンピュータプログラムコードは、少なくとも１つのプロセッサによって、
アクセス単位デリミタからデコーディングすることであって、アクセス単位デリミタと関連付けられたネットワーク抽象化レイヤ（ＮＡＬ）単位をコード化ビデオシーケンスの始端として処理する、デコーディングすることであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のＮＡＬ単位を含む、デコーディングすることを少なくとも当該装置に実行させるように構成されている。
第７の態様に係るコンピュータプログラム製品は、少なくとも１つのプロセッサ上で実行された場合に、
アクセス単位デリミタからデコーディングすることであって、アクセス単位デリミタと関連付けられたネットワーク抽象化レイヤ（ＮＡＬ）単位をコード化ビデオシーケンスの始端として処理する、デコーディングすることであり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のＮＡＬ単位を含む、デコーディングすることを装置またはシステムに行わせるように構成されたコンピュータプログラムコードを含む。
第８の態様に係る装置は、
アクセス単位デリミタからデコーディングする手段であって、アクセス単位デリミタと関連付けられたネットワーク抽象化レイヤ（ＮＡＬ）単位をコード化ビデオシーケンスの始端として処理する、デコーディングする手段であり、コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像であり、ビットストリームが、アクセス単位を含み、アクセス単位が、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含むとともに、１つまたは複数のＮＡＬ単位を含む、デコーディングする手段を備える。
その他の態様は、上記方法ならびにこれらと関連する実施形態のうちの１つもしくは複数を実行するように構成された装置およびコードが格納されたコンピュータ可読記憶媒体に関する。
以下、本発明のより深い理解を可能とするため、添付の図面を一例として参照する。
ＭＰＥＧ Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｅｄｉａ Ｆｏｒｍａｔ（ＯＭＡＦ）の一例を示した図である。 イメージのステッチング、投影、および領域単位のパッキングの一例を示した図である。 イメージのステッチング、投影、および領域単位のパッキングの別の例を示した図である。 単眼正距円筒パノラマ画像を形成するプロセスの一例を示した図である。 タイルベースの全方位ビデオストリーミングの一例を示した図である。 一実施形態に係る、サブ画像シーケンス単位のバッファリングを示した図である。 一実施形態に係る、基準サブ画像操作プロセスによるデコーディングプロセスを示した図である。 一例に係る、デリミタを使用する一例を示した図である。 一例に係る、レイヤ識別子番号を書き換える一例を示した図である。 一例に係る、品質の異なる２つのサブ画像シーケンスがサブ画像シーケンストラックにカプセル化されたタイルベースの全方位ビデオストリーミングの一例を示した図である。 ４つのサブ画像に分割された画像の一例を示した図である。 キューブマップコンテンツが「８Ｋ」、「６Ｋ」、「４Ｋ」、および「２Ｋ」の解像度でエンコーディングされた一例を示した図である。 ４Ｋデコーディング機能への使用に３×１１のタイルグリッドが選択された一例を示した図である。 クライアントが任意の方法により任意の解像度バージョンからタイルを選択可能な一例を示した図である。 提示の「６Ｋ」方法において、「６Ｋ」バージョンの３つ以上の立方体面、「４Ｋ」バージョンの３つ以上の立方体面、および「２Ｋ」バージョンの４つ以上の立方体面を網羅するタイルをクライアントが選択する一例を示した図である。 一実施形態に係る、独立コード化画像領域の選択を動的に変更した結合ビットストリームの一例を示した図である。 一実施形態に係る、パッチ生成の一例を示した図である。 画像をコーディングツリー単位（ＣＴＵ）、タイル、ブリック、およびスライスに分離するいくつかの例を示した図である。 画像をコーディングツリー単位（ＣＴＵ）、タイル、ブリック、およびスライスに分離するいくつかの例を示した図である。 画像をコーディングツリー単位（ＣＴＵ）、タイル、ブリック、およびスライスに分離するいくつかの例を示した図である。 一実施形態に係る、方法を示したフローチャートである。 別の実施形態に係る、方法を示したフローチャートである。 一実施形態に係る、装置を示した図である。
以下、あるビデオコーディング構成の状況において、複数の実施形態を説明する。ただし、本発明は、この特定の構成に限定されないことに留意するものとする。たとえば、本発明は、ストリーミングシステム、ＤＶＤ（デジタル多用途ディスク）プレーヤ、デジタルテレビ受像機、個人用ビデオレコーダ、パソコン上のシステムおよびコンピュータプログラム、携帯用コンピュータおよび通信機器等のビデオコーディングシステムのほか、トランスコーダおよびビデオデータが取り扱われるクラウドコンピューティング構成等のネットワーク要素に適用可能と考えられる。
以下、（デ）コーディングに言及する慣例によって複数の実施形態を説明するが、これは、実施形態がデコーディングおよび／またはエンコーディングに当てはまり得ることを示す。
Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ規格（ＡＶＣまたはＨ．２６４／ＡＶＣと略記可能）は、国際電気通信連合（ＩＴＵ－Ｔ）の電気通信標準化部門のビデオコーディング専門家グループ（ＶＣＥＧ）および国際標準化機構（ＩＳＯ）／国際電気標準会議（ＩＥＣ）の動画専門家グループ（ＭＰＥＧ）の合同ビデオチーム（ＪＶＴ）により策定されたものである。Ｈ．２６４／ＡＶＣ規格は、両所属標準化機関により発行されており、ＩＴＵ－Ｔ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６－１０と称されし、ＭＰＥＧ－４ Ｐａｒｔ １０ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）としても知られる。Ｈ．２６４／ＡＶＣ規格には複数のバージョンがあり、それぞれが新しい拡張や機能を仕様に組み込んでいる。これらの拡張には、ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）およびＭＶＣ（Ｍｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）を含む。
Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ規格（ＨＥＶＣまたはＨ．２６５／ＨＥＶＣと略記可能）は、ＶＣＥＧおよびＭＰＥＧの合同・共同ビデオコーディングチーム（ＪＣＴ－ＶＣ）により策定されたものである。この規格は、両所属標準化機関により発行されており、ＩＴＵ－Ｔ勧告Ｈ．２６５およびＩＳＯ／ＩＥＣ国際規格２３００８－２と称され、ＭＰＥＧ－Ｈ Ｐａｒｔ ２ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）としても知られる。Ｈ．２６５／ＨＥＶＣの拡張としては、スケーラブル、マルチビュー、３次元、および忠実度範囲の拡張があり、それぞれＳＨＶＣ、ＭＶ－ＨＥＶＣ、３Ｄ－ＨＥＶＣ、およびＲＥＸＴと称し得る。本明細書において、これらの規格仕様の定義、構造、または概念の理解を目的とするＨ．２６５／ＨＥＶＣ、ＳＨＶＣ、ＭＶ－ＨＥＶＣ、３Ｄ－ＨＥＶＣ、およびＲＥＸＴの参照は、別段の指定のない限り、本願の日付以前に入手可能であったこれら規格の最新版の参照であることが了解されるものとする。
Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ規格（ＶＶＣ、Ｈ．２６６、またはＨ．２６６／ＶＶＣ）は現在、ＩＳＯ／ＩＥＣ ＭＰＥＧおよびＩＴＵ－Ｔ ＶＣＥＧの共同である合同ビデオ専門家チーム（ＪＶＥＴ）が策定中である。
本項では、実施形態を実現可能なビデオエンコーダ、デコーダ、エンコーディング方法、デコーディング方法、およびビットストリーム構造の例として、Ｈ．２６４／ＡＶＣ、ＨＥＶＣ、およびそれらの拡張のうちの一部に関するいくつかの主要な定義、ビットストリームおよびコーディング構造、ならびに概念を説明する。Ｈ．２６４／ＡＶＣの主要な定義、ビットストリームおよびコーディング構造、ならびに概念の一部は、ＨＥＶＣ規格と同じであるため、以下では一体的に説明する。種々実施形態の態様は、Ｈ．２６４／ＡＶＣにもＨＥＶＣにも、それらの拡張にも限定されず、説明はむしろ、これらの実施形態の一部または全部を実現可能な１つの考え得る基礎に関して与える。
ビデオコーデックは、入力ビデオを格納／伝送に適した圧縮表現へと変換するエンコーダと、圧縮されたビデオ表現を解凍して可視形態に戻すことができるデコーダとを備え得る。圧縮表現は、ビットストリームまたはビデオビットストリームと称し得る。また、ビデオエンコーダおよび／またはビデオデコーダは、互いに別個であってもよい。すなわち。コーデックを構成する必要はない。エンコーダは、ビデオをよりコンパクトな形態（すなわち、低ビットレート）で表現するため、元のビデオシーケンスに含まれる一部の情報を破棄する場合がある。
ハイブリッドビデオコーデック、たとえば、ＩＴＵ－Ｔ Ｈ．２６４は、２段階でビデオ情報をエンコーディング可能である。まず、たとえば動き補償手段（コード化対象のブロックに密に対応するコード化ビデオフレームのうちの１つにおけるエリアを見つけて示す）または空間手段（特定の様態でコード化されるブロックの周りのピクセル値を使用する）によって、特定の画像エリア（または「ブロック」）のピクセル値が予測される。その後、予測誤差すなわちピクセルの予測ブロックとピクセルの元ブロックとの差がコード化される。これは、ピクセル値の差を特定の変換（たとえば、離散コサイン変換（ＤＣＴ）またはその変形）により変換し、係数を量子化し、量子化した係数をエントロピコーディングすることによって行われ得る。量子化プロセスの忠実度を変えることによって、エンコーダは、ピクセル表現の精度（画質）と結果としてのコード化ビデオ表現のサイズ（ファイルサイズまたは伝送ビットレート）とのバランスを制御することができる。
時間予測において、予測元は、デコード画像（基準画像としても知られる）である。ブロック内コピー（ｉｎｔｒａ ｂｌｏｃｋ，ＩＢＣ、ブロック内コピー予測または現画像参照としても知られる）においては、時間予測と同様に予測が適用されるものの、基準画像は現在の画像であり、予測プロセスではデコードサンプルのみ参照可能である。レイヤ間またはビュー間予測は時間予測と同様に適用され得るが、基準画像はそれぞれ、別のスケーラブルレイヤまたは別のビューからのデコード画像である。相互予測は、ある場合には時間予測のみを表す一方、他の場合には、時間予測ならびに時間予測と同一または同様のプロセスで実行されることを前提としたブロック内コピー、レイヤ間予測、およびビュー間予測のいずれかをまとめて表し得る。相互予測または時間予測は、動き補償または動き補償予測と称する場合がある。
内部予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）では、同じ画像内の隣り合うピクセルが相関する可能性が高い、という事実を利用する。内部予測は、空間または変換領域で実行可能である。すなわち、サンプル値または変換係数を予測可能である。内部予測は通常、相互予測（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ）が適用されない内部コーディング（ｉｎｔｒａ ｃｏｄｉｎｇ）において利用される。
コーディング手順の結果として、動きベクトルおよび量子化された変換係数等の一組のコーディングパラメータがある。多くのパラメータは、空間的または時間的に隣接するパラメータから初めて予測された場合、より効率的にエントロピコーディング可能である。たとえば、動きベクトルが空間的に隣り合う動きベクトルから予測されてもよく、動きベクトル予測子（ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ）に対する差異のみがコード化されるようになっていてもよい。コーディングパラメータの予測および内部予測は、画像内予測と総称し得る。
エントロピコーディング／デコーディングは、多くの方法で実行可能である。たとえば、コンテキストベースのコーディング／デコーディングが適用されるようになっていてもよく、エンコーダおよびデコーダの両者において、コード化／デコードのコーディングパラメータに基づいてコーディングパラメータのコンテキスト状態を修正する。コンテキストベースのコーディングは、たとえばコンテキスト適応二項演算コーディング（ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｂｉｎａｒｙ ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ，ＣＡＢＡＣ）であってもよいし、コンテキストベースの可変長コーディング（ｃｏｎｔｅｘｔ－ｂａｓｅｄ ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｃｏｄｉｎｇ，ＣＡＶＬＣ）であってもよいし、同様の如何なるエントロピコーディングであってもよい。この代替または追加として、エントロピコーディング／デコーディングは、ハフマンコーディング／デコーディングまたは指数ゴロム（Ｅｘｐ－Ｇｏｌｏｍｂ）コーディング／デコーディング等の可変長コーディング方式を用いて実行されるようになっていてもよい。エントロピコード化ビットストリームまたはコードワードからのコーディングパラメータのデコーディングは、パーシングと称し得る。
ビデオコーディング規格は、ビットストリームのシンタックスおよびセマンティクスのほか、エラーなしビットストリームのデコーディングプロセスを規定し得るが、エンコーディングプロセスは規定されない可能性もある。ただし、エンコーダは、適合するビットストリームを生成しさえすればよい。ビットストリームおよびデコーダの適合は、仮想基準デコーダ（Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ，ＨＲＤ）により確認可能である。これらの規格には、伝送エラーおよび損失に対処するためのコーディングツールを含んでいてもよいが、エンコーディングにおけるツールの使用は任意であり得、エラーありビットストリームに対するデコーディングプロセスは規定されていない可能性もある。
シンタックス要素（ｓｙｎｔａｘ ｅｌｅｍｅｎｔ）は、ビットストリームにおいて表されるデータの要素として定義可能である。シンタックス構造（ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅ）は、ビットストリームにおいて規定の順序で一体的に存在する０個以上のシンタックス要素として定義可能である。
エンコーダの入力およびデコーダの出力それぞれの基本単位は通常、画像である。また、エンコーダの入力として与えられた画像はソース画像と称し、デコーダによりデコーディングされた画像はデコード画像または再構成画像と称し得る。
ソース画像およびデコード画像はそれぞれ、以下の複数組のサンプルアレイのうちの１つ等、１つまたは複数のサンプルアレイで構成される。
輝度（ｌｕｍａ，Ｙ）のみ（白黒）
輝度および２つの彩度（ＹＣｂＣｒまたはＹＣｇＣｏ）
緑、青、および赤（ＧＢＲ、ＲＧＢとしても知られる）
規定されていない他の白黒または三刺激色サンプリングを表すアレイ（たとえば、ＹＺＸ、ＸＹＺとしても知られる）
以下では、これらのアレイを輝度（または、ＬもしくはＹ）および彩度と称し得るが、２つの彩度アレイは、使用する実際の色表現方法に関わらず、ＣｂおよびＣｒと称し得る。使用する実際の色表現方法は、たとえばＨＥＶＣまたは同等のもののビデオユーザビリティ情報（ＶＵＩ）シンタックスを使用して、たとえばコード化ビットストリームにおいて示すことができる。コンポーネント（ｃｏｍｐｏｎｅｎｔ）は、３つのサンプルアレイ（輝度および２つの彩度）のうちの１つまたは白黒フォーマットの画像を構成するアレイまたはアレイの単一のサンプルとして定義可能である。
画像（ｐｉｃｔｕｒｅ）は、フレームまたはフィールドとして定義可能である。フレームは、輝度サンプルおよび場合により対応する彩度サンプルから成る行列を含む。フィールドは、フレームの一組の交互サンプル行であり、ソース信号がインターレースされる場合に、エンコーダ入力として使用可能である。輝度サンプルアレイと比較して、彩度サンプルアレイは存在していなくてもよいし（これにより、白黒サンプリングが使用されてもよい）、サブサンプリングされるようになっていてもよい。
一部の彩度フォーマットは、以下のようにまとめることができる。
白黒サンプリングにおいては、名目上輝度アレイと考えられ得るサンプルアレイが１つだけ存在する。
４：２：０サンプリングにおいては、２つの彩度アレイがそれぞれ、輝度アレイの半分の高さおよび半分の幅を有する。
４：２：２サンプリングにおいては、２つの彩度アレイがそれぞれ、輝度アレイと同じ高さおよび半分の幅を有する。
別個の色平面が使用されない場合の４：４：４サンプリングにおいては、２つの彩度アレイがそれぞれ、輝度アレイと同じ高さおよび幅を有する。
コーディングフォーマットまたは規格によれば、ビットストリームにおいて、サンプルアレイを別個の色平面としてコーディング可能であるとともに、ビットストリームからコード化色平面をそれぞれ別々にデコーディング可能となり得る。別個の色平面が使用される場合は、白黒サンプリングの画像として、（エンコーダおよび／またはデコーダにより）それぞれが別々に処理される。
彩度サブサンプリングが使用される場合（たとえば、４：２：０または４：２：２彩度サンプリング）、輝度サンプルに対する彩度サンプルの場所は、エンコーダ側で（たとえば、前処理ステップまたはエンコーディングの一部として）決定され得る。輝度サンプル位置に対する彩度サンプル位置は、たとえばＨ．２６４／ＡＶＣまたはＨＥＶＣ等のコーディング規格で予め規定されていてもよいし、たとえばＨ．２６４／ＡＶＣまたはＨＥＶＣのＶＵＩの一部としてビットストリームに示されていてもよい。
一般的に、エンコーディングの入力として与えられるソースビデオシーケンスは、インターレースソースコンテンツまたはプログレッシブソースコンテンツを表し得る。インターレースソースコンテンツでは、逆パリティのフィールドが異なるタイミングで取り込まれている。プログレッシブソースコンテンツには、取り込まれたフレームを含む。エンコーダは、インターレースソースコンテンツのフィールドを以下２つの方法でエンコーディング可能である。すなわち、一対のインターレースフィールドがコード化フレームへとコーディングされるようになっていてもよいし、フィールドがコード化フィールドとしてコーディングされるようになっていてもよい。同様に、エンコーダは、プログレッシブソースコンテンツのフレームを以下２つの方法でエンコーディング可能である。すなわち、プログレッシブソースコンテンツのフレームがコード化フレームまたは一対のコード化フィールドへとコーディングされるようになっていてもよい。フィールド対または相補フィールド対は、デコーディングおよび／または出力の順序で互いに隣り合い、逆パリティを有し（すなわち、一方がトップフィールドでもう一方ボトムフィールド）、いずれも他の相補フィールド対に属さない２つのフィールドとして規定されていてもよい。一部のビデオコーディング規格または方式によれば、同じコード化ビデオシーケンスにおいて、コード化フレームおよびコード化フィールドを混合可能となる。さらに、コード化フレーム中のフィールドからコード化フィールドを予測すること、および／または、（フィールドとしてコーディングされた）相補フィールド対に対してコード化フレームを予測することがエンコーディングおよび／またはデコーディングにおいて有効となり得る。
分離（ｐａｒｔｉｔｉｏｎｉｎｇ）は、集合を部分集合に分割して、集合の各要素が厳密に部分集合のうちの１つにあるようにすることと定義可能である。ビデオコーディングにおいては、画像または画像の小領域の各要素が厳密に部分集合のうちの１つにあるように、画像または画像の小領域の部分集合への分割として分離が規定され得る。たとえば、ＨＥＶＣエンコーディングおよび／もしくはデコーディングならびに／またはＶＶＣエンコーディングおよび／もしくはデコーディングに関する分離においては、以下の用語を使用可能である。コーディングブロック（ｃｏｄｉｎｇ ｂｌｏｃｋ）は、コーディングツリーブロックのコーディングブロックへの分割が分離となるように、ある値Ｎについて、Ｎ×Ｎブロックのサンプルとして定義可能である。コーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ（ＣＴＢ））は、コンポーネントのコーディングツリーブロックへの分割が分離となるように、ある値Ｎについて、Ｎ×Ｎブロックのサンプルとして定義可能である。コーディングツリー単位（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ（ＣＴＵ））は、輝度サンプルのコーディングツリーブロック、３つのサンプルアレイを有する画像の彩度サンプルの対応する２つのコーディングツリーブロック、または白黒画像もしくはサンプルのコーディングに用いられる３つの別個の色平面およびシンタックス構造を用いてコーディングされた画像のサンプルのコーディングツリーブロックとして定義可能である。コーディング単位（ｃｏｄｉｎｇ ｕｎｉｔ（ＣＵ））は、輝度サンプルのコーディングブロック、３つのサンプルアレイを有する画像の彩度サンプルの対応する２つのコーディングブロック、または白黒画像もしくはサンプルのコーディングに用いられる３つの別個の色平面およびシンタックス構造を用いてコーディングされた画像のサンプルのコーディングブロックとして定義可能である。許容サイズが最大のＣＵは、ＬＣＵ（最大コーディング単位）またはコーディングツリー単位（ＣＴＵ）と称することができ、ビデオ画像は、重なり合わないＬＣＵに分割される。
ＨＥＶＣにおいて、ＣＵは、ＣＵ内のサンプルの予測プロセスを規定する１つまたは複数の予測単位（ＰＵ）と、前記ＣＵ内のサンプルの予測誤差コーディングプロセスを規定する１つまたは複数の変換単位（ＴＵ）と、から成る。通常、ＣＵは、所定の一組の考え得るＣＵサイズから選択可能なサイズのサンプルの正方形ブロックから成る。各ＰＵおよびＴＵは、それぞれ予測プロセスおよび予測誤差コーディングプロセスの粒度を上げるため、より小さなＰＵおよびＴＵへとさらに分割可能である。各ＰＵには、当該ＰＵ内のピクセルに対して適用すべき予測の種類を規定する予測情報（たとえば、相互予測ＰＵの場合の動きベクトル情報および内部予測ＰＵの場合の内部予測方向性情報）が関連付けられている。
各ＴＵは、当該ＴＵ内のサンプルに対する予測誤差デコーディングプロセスを記述した情報（たとえば、ＤＣＴ係数情報を含む）と関連付け可能である。各ＣＵに対して予測誤差コーディングが適用されるか否かについては通常、ＣＵレベルで示される。予測誤差の残差がＣＵと関連付けられていない場合は、前記ＣＵに対するＴＵが存在しないと考えられる。イメージのＣＵへの分割ならびにＣＵのＰＵおよびＴＵへの分割は通常、ビットストリームで示されるため、デコーダは、これらの単位の意図する構造を再現可能となる。
Ｈ．２６６／ＶＶＣのドラフト版では、以下のような分離が適用される。なお、規格が完成するまでのＨ．２６６／ＶＶＣの後続のドラフト版において、本明細書に記載の内容が進展する可能性もある。画像はＨＥＶＣと同様にＣＴＵへと分離されるが、ＣＴＵの最大サイズは、１２８×１２８に拡大されている。コーティングツリー単位（ＣＴＵ）はまず、四分木（ｑｕａｔｅｒｎａｒｙ ｔｒｅｅ（ｑｕａｄｔｒｅｅとしても知られる））構造により分離される。その後、四分木リーフノードは、多分木構造（ｍｕｌｔｉ－ｔｙｐｅ ｔｒｅｅ ｓｔｒｕｃｔｕｒｅ）によってさらに分離可能である。多分木構造には、垂直二項分割、水平二項分割、垂直三項分割、および水平三項分割の４つの分割タイプがある。多分木リーフノードは、コーディング単位（ＣＵ）と称する。ＣＵ、ＰＵ、およびＴＵは、ＣＵが最大変換長に対して大き過ぎなければ、同じブロックサイズを有する。ＣＴＵのセグメント化構造は、二項および三項分割を用いた入れ子の多分木を伴う四分木である。すなわち、最大変換長に対してサイズが大き過ぎるＣＵに必要な場合を除き、ＣＵ、ＰＵ、およびＴＵ別個の概念は使用されない。ＣＵは、正方形状または長方形状を有し得る。
ＶＶＣ等の一部のコーディングフォーマットのエンコーダの出力およびＶＶＣ等の一部のコーディングフォーマットのデコーダの入力の基本単位は、ネットワーク抽象化レイヤ（ＮＡＬ）単位である。パケット指向ネットワーク上の転送または構造化ファイルへの格納の場合、ＮＡＬ単位は、パケットまたは類似の構造にカプセル化されるようになっていてもよい。
フレーム構造を提供しない伝送または格納環境のＮＡＬ単位のストリームに対して、バイトストリームフォーマットが規定可能である。バイトストリームフォーマットでは、各ＮＡＬ単位の前に始端コードを付加することによって、ＮＡＬ単位を互いに分離する。ＮＡＬ単位境界の誤検出を防ぐため、エンコーダは、バイト指向の始端コードエミュレーション防止アルゴリズムを動作させる。これは、始端コードが発生すると考えられる場合に、エミュレーション防止バイトをＮＡＬ単位ペイロードに追加する。パケット指向システムとストリーム指向システムとの間の容易なゲートウェイ動作を可能とするため、バイトストリームフォーマットが使用されるか否かに関わらず、始端コードエミュレーション防止が常に実行されるようになっていてもよい。
ＮＡＬ単位（ＮＡＬ ｕｎｉｔ）は、後続のデータの種類の指標と、必要に応じてエミュレーション防止バイトを挟んだＲＢＳＰの形態の当該データを含むバイトと、を含むシンタックス構造として定義可能である。未加工バイトシーケンスペイロード（ｒａｗ ｂｙｔｅ ｓｅｑｕｅｎｃｅ ｐａｙｌｏａｄ（ＲＢＳＰ））は、ＮＡＬ単位でカプセル化された整数個のバイトを含むシンタックス構造として定義可能である。ＲＢＳＰは、空であるか、または、シンタックス要素を含むデータビットにＲＢＳＰ停止ビットと、０に等しい０個以上の後続ビットとが続く文字列の形態を有する。
ＮＡＬ単位は、ヘッダおよびペイロードから成る。ＮＡＬ単位のヘッダは、特にＮＡＬ単位の種類を示す。
ＮＡＬ単位は、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬ単位および非ＶＣＬ ＮＡＬ単位に分類可能である。ＶＣＬ ＮＡＬ単位は通常、コード化スライスＮＡＬ単位である。
非ＶＣＬ ＮＡＬ単位は、たとえばシーケンスパラメータ集合、画像パラメータ集合、補完拡張情報（ＳＥＩ）ＮＡＬ単位、アクセス単位デリミタ、シーケンスＮＡＬ単位の終端、ビットストリームＮＡＬ単位の終端、またはフィラーデータＮＡＬ単位といった種類のうちの１つであってよい。パラメータ集合がデコード画像の再構成に必要となる場合がある一方、その他の非ＶＣＬ ＮＡＬ単位の多くは、デコードサンプル値の再構成に必要ない。
一部のコーディングフォーマットでは、デコーディングまたはデコード画像の再構成に必要なパラメータ値を有し得るパラメータ集合を規定する。パラメータ（ｐａｒａｍｅｔｅｒ）は、パラメータ集合のシンタックス要素として定義可能である。パラメータ集合（ｐａｒａｍｅｔｅｒ ｓｅｔ）は、パラメータを含み、たとえば識別子の使用による別のシンタックス構造からの参照または別のシンタックス構造によるアクティブ化が可能なシンタックス構造として定義可能である。
以下、いくつかの種類のパラメータ集合を簡単に説明するが、他の種類のパラメータ集合が存在していてもよく、また、説明する種類のパラメータ集合に実施形態が適用され得るものの、これらには限定されないことが了解される必要がある。コード化ビデオシーケンスによって変化しないパラメータは、シーケンスパラメータ集合（ＳＰＳ）に含まれていてもよい。デコーディングプロセスに必要となり得るパラメータのほか、シーケンスパラメータ集合には任意選択として、バッファリング、画像出力タイミング、レンダリング、およびリソース予約に重要となり得るパラメータを含むビデオユーザビリティ情報（ＶＵＩ）を含んでいてもよい。画像パラメータ集合（ＰＰＳ）には、複数のコード化画像において不変となる可能性が高いそのようなパラメータを含む。画像パラメータ集合には、１つまたは複数のコード化画像のコード化イメージセグメントが参照し得るパラメータを含んでいてもよい。ヘッダパラメータ集合（ＨＰＳ）は、画像に基づいて変化し得るそのようなパラメータを含むように提案されている。
ビットストリーム（ｂｉｔｓｔｒｅａｍ）は、一連のビットとして定義可能であり、一部のコーディングフォーマットまたは規格においては、ＮＡＬ単位ストリームまたはバイトストリームの形態であってもよく、１つまたは複数のコード化ビデオシーケンスを構成するコード化画像および関連するデータの表現を構成する。同じファイルや通信プロトコルの同じ接続等、同じ論理チャネル内で第１のビットストリームに第２のビットストリームが続いていてもよい。（ビデオコーディングの状況における）基本ストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）は、一連の１つまたは複数のビットストリームとして定義可能である。一部のコーディングフォーマットまたは規格において、最初のビットストリームの終端は、特定のＮＡＬ単位により示されていてもよく、これは、ビットストリーム終端（ＥＯＢ）ＮＡＬ単位と称し得るものであり、ビットストリームの最後のＮＡＬ単位である。
部分ビットストリーム（ｂｉｔｓｔｒｅａｍ ｐｏｒｔｉｏｎ）は、ビットストリームの連続部分集合として定義可能である。ある状況では、部分ビットストリームが１つまたは複数のシンタックス構造全体からなり、不完全なシンタックス構造を含まないことが必要となり得る。他の状況では、部分ビットストリームがビットストリームの如何なる連続部分を含んでいてもよく、また、不完全なシンタックス構造を含んでいてもよい。
ビットストリームに伴う（たとえば、ビットストリームに伴って示す）表現またはビットストリームのコーディング単位に伴う（たとえば、コード化タイルに伴って示す）表現は、「帯域外」データがビットストリームまたはコード化単位とそれぞれ関連付けられる一方でこれらには含まれない様態での伝送、シグナリング、または格納を表すように、特許請求の範囲および記載の実施形態において使用され得る。ビットストリームまたはビットストリームのコード化単位等に伴うデコーディングという表現は、ビットストリームまたはコード化単位とそれぞれ関連付けられた参照帯域外データ（帯域外伝送、シグナリング、または格納から得られ得る）のデコーディングを表し得る。たとえば、ビットストリームがＩＳＯベースメディアファイルフォーマット（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）に準拠したファイル等のコンテナファイルに含まれ、ビットストリームを含むトラックのサンプルエントリのボックス、ビットストリームを含むトラックのサンプル群、またはビットストリームを含むトラックと関連付けられた時限メタデータトラック等のメタデータをビットストリームに関連付ける様態で特定のファイルメタデータがファイルに格納されている場合に、ビットストリームに伴う表現を使用可能である。
コード化ビデオシーケンス（ｃｏｄｅｄ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅ（ＣＶＳ））は、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像として定義可能である。この追加または代替として、コード化ビデオシーケンスは、シーケンス終端（ＥＯＳ）ＮＡＬ単位と称し得る特定のＮＡＬ単位がビットストリームに現れた場合に終端するように規定可能である。
イメージは、独立コーディングおよびデコーディング可能なイメージセグメント（たとえば、スライス、タイル、および／またはタイル群）に分割可能である。このようなイメージセグメントは、並列処理を可能にし得る。本明細書において、「スライス」は、デフォルトのコーディングまたはデコーディング順序で処理される特定個数の基本コーディング単位で構成されたイメージセグメントを表し得る。一方、「タイル」は、タイルグリッドに沿った長方形のイメージ領域として規定されたイメージセグメントを表し得る。タイル群（ｔｉｌｅ ｇｒｏｕｐ）は、一群の１つまたは複数のタイルとして定義可能である。イメージセグメントは、Ｈ．２６４／ＡＶＣ、ＨＥＶＣ、およびＶＶＣにおけるＶＣＬ ＮＡＬ単位等、ビットストリームにおける別個の単位としてコーディングされ得る。コード化イメージセグメントは、ヘッダおよびペイロードを含み得るが、このヘッダは、ペイロードのデコーディングに必要なパラメータ値を含む。スライスのペイロードは、スライスデータと称し得る。
ＨＥＶＣにおいては、長方形かつ整数個のＬＣＵを含むタイルへと画像を分離可能である。ＨＥＶＣにおいては、タイルへの分離によって規則的なグリッドが形成されるが、タイルの高さおよび幅は、最大で１ＬＣＵだけ互いに異なる。ＨＥＶＣにおいては、１つの独立スライスセグメントと、同じアクセス単位内で次の独立スライスセグメント（存在する場合）に先行するすべての後続従属スライスセグメント（存在する場合）と、に含まれる整数個のコーディングツリー単位としてスライスが定義される。ＨＥＶＣにおいては、タイルスキャンにおいて連続的に並べられ、単一のＮＡＬ単位に含まれる整数個のコーティングツリー単位として、スライスセグメントが定義される。各画像のスライスセグメントへの分割は、分離である。ＨＥＶＣにおいては、スライスセグメントヘッダのシンタックス要素の値が先行スライスセグメントの値から推測されないスライスセグメントとして、独立スライスセグメントが定義され、スライスセグメントヘッダの一部のシンタックス要素の値がデコーディング順序の先行独立スライスセグメントの値から推測されるスライスセグメントとして、従属スライスセグメントが定義される。ＨＥＶＣにおいては、現在のスライスセグメントである独立スライスセグメントまたは現在の従属スライスセグメントに先行する独立スライスセグメントのスライスセグメントヘッダとして、スライスヘッダが定義され、スライスセグメントで表される最初またはすべてのコーディングツリー単位に関するデータ要素を含むコード化スライスセグメントの一部として、スライスセグメントヘッダが定義される。ＣＵは、タイル内または画像内（タイルが使用されない場合）のＬＣＵのラスタースキャンの順序でスキャンされる。ＣＵは、ＬＣＵ内において特定のスキャン順序を有する。
以上から、ビデオコーディングの規格および仕様によれば、エンコーダは、コード化画像をコード化スライスまたは同等のものに分割可能となり得る。画像内予測は通常、スライス境界を跨ぐと無効になる。このため、スライスは、コード化画像を独立デコーディング可能な要素に分割する方法と見なすことができる。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて、画像内予測は、スライス境界を跨ぐと無効になる場合がある。これにより、スライスは、コード化画像を独立デコーディング可能な要素に分割する方法と見なすことができるため、伝送用の基本単位と見なされることが多い。多くの場合、エンコーダは、ビットストリームにおいて、スライス境界を跨いでオフとなる画像内予測の種類を示すことができ、デコーダの動作では、たとえば利用可能な予測元を決定する場合にこの情報を考慮する。たとえば、隣接ＣＵが異なるスライスに存在する場合は、隣接ＣＵからのサンプルを内部予測に利用できないものと見なされる場合がある。
ＶＶＣの最新のドラフト版すなわちＶＶＣ Ｄｒａｆｔ ５においては、画像のスライス、タイル、およびブリックへの分離が以下のように定義されている。
画像は、１つもしくは複数のタイル行ならびに１つもしくは複数のタイル列へと分割される。画像のタイルへの分離によって、（ＣＴＵにおける）タイル列幅のリストおよび（ＣＴＵにおける）タイル行高さのリストを特徴とし得るタイルグリッドが形成される。
タイルは、タイルグリッドの１つの「セル」すなわち画像の長方形領域を網羅する一連のコーディングツリー単位（ＣＴＵ）である。タイルは１つまたは複数のブリックに分割されるが、各ブリックは、タイル内の多数のＣＴＵ行から成る。複数のブリックに分離されていないタイルについてもブリックと称する。ただし、タイルの真の部分集合であるブリックについては、タイルと称しない。
スライスには、画像の多くのタイルまたはタイルの多くのブリックを含む。スライスは、ＶＣＬ ＮＡＬ単位であって、スライスヘッダおよびスライスデータを含む。
スライスの２つのモードすなわちラスタースキャンスライスモードおよび長方形スライスモードがサポートされている。ラスタースキャンスライスモードにおいて、スライスは、画像のタイルラスタースキャンに一連のタイルを含む。長方形スライスモードにおいて、スライスは、画像の長方形領域を全体として構成する画像の多くのブリックを含む。長方形スライス内のブリックは、スライスのブリックラスタースキャンの順序である。
ブリックスキャン（ｂｒｉｃｋ ｓｃａｎ）は、ＣＴＵがブリックのＣＴＵラスタースキャンにおいて連続的に並べられ、タイル内のブリックがタイルのブリックのラスタースキャンにおいて連続的に並べられ、画像のタイルが画像のタイルのラスタースキャンにおいて連続的に並べられた当該画像を分離するＣＴＵの特定の連続した順序として定義可能である。たとえば、コーディング規格においては、コード化スライスＮＡＬ単位がそれぞれの最初のＣＴＵについて、ブリックスキャン順序でＣＴＵアドレスが増加する順序となるようにすることが必要となる場合があり、このＣＴＵアドレス（ＣＴＵ ａｄｄｒｅｓｓ）は、画像内のＣＴＵラスタースキャンにおいて増加するものと定義可能である。ラスタースキャン（ｒａｓｔｅｒ ｓｃａｎ）は、長方形の２次元パターンを１次元パターンにマッピングするもので、１次元パターンの最初のエントリが２次元パターンの最上行を左から右へスキャンし、その後同様にパターンの２行目、３行目、・・・をそれぞれ左から右へ（下方に）スキャンするものとして定義可能である。
ＶＶＣ Ｄｒａｆｔ ５において、スライスヘッダは、ｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素を含むが、これは、スライスのスライスアドレスを直接的または間接的に示すものであり、スライスアドレスは、画像内の空間的な場所または位置と見なすことができる。ラスタースキャン順序のスライスが使用される場合、ｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素は、画像ラスタースキャン順序のタイルインデックスを示す。長方形スライスが使用され、ＰＰＳにおいて明示的なｓｌｉｃｅ＿ａｄｄｒｅｓｓ順序が指示されない場合、ｓｌｉｃｅ＿ａｄｄｒｅｓｓは、スライスの最初のブリックのスキャン順序におけるブリックインデックスを示す。長方形スライスが使用され、ＰＰＳにおいて明示的なｓｌｉｃｅ＿ａｄｄｒｅｓｓ順序が示される場合は、ＰＰＳにおいて、画像内のｓｌｉｃｅ＿ａｄｄｒｅｓｓ値のスライスの空間的な位置を示す所定のスキャン順序でｓｌｉｃｅ＿ａｄｄｒｅｓｓ値（スライスＩＤ値としても知られる）のリストが提供される。
図１３ａは、画像のラスタースキャンスライス分離の一例を示しており、この画像は、１２個のタイルおよび３つのラスタースキャンスライスに分割される。図１３ｂは、画像（１８×１２個のＣＴＵ）の長方形スライス分離の一例を示しており、この画像は、２４個のタイル（６つのタイル列および４つのタイル行）および９つの長方形スライスに分割される。図１３ｃは、タイル、ブリック、および長方形スライスに分離された画像の一例を示しており、この画像は、４つのタイル（２つのタイル列および２つのタイル行）、１１個のブリック（左上タイルが１つのブリックを含み、右上タイルが５つのブリックを含み、左下タイルが２つのブリックを含み、右下タイルが３つのブリックを含む）、および４つの長方形スライスに分割される。
ＶＶＣ Ｄｒａｆｔ ５においては、タイル、ブリック、および長方形スライスへの分離が画像パラメータ集合（ＰＰＳ）に規定されている。以下のシンタックスおよびセマンティクスは、さまざまな実施形態で使用可能なシンタックス要素の例を与える。一実施形態において、エンコーダは、タイル、ブリック、および長方形スライスへの分離を（たとえば、ＳＰＳにおける）シーケンスレベルまたは（たとえば、ＰＰＳにおける）画像レベルで含むことを決定するとともに、分離を含むシンタックス構造を（たとえば、ＳＰＳにおける）シーケンスレベルで示す。一実施形態において、デコーダは、（たとえば、ＳＰＳからの）シーケンスレベルのシンタックス構造から、タイル、ブリック、および長方形スライスへの分離を含むシンタックス構造の指定をデコーディングし、それに応じて、指定されたシーケンスレベル（たとえば、ＳＰＳ）または画像レベル（たとえば、ＰＰＳ）のシンタックス構造から、タイル、ブリック、および長方形スライスへの分離をデコーディングする。この指定は、たとえば後述のｓｐｓ＿ｔｉｌｅ＿ｂｒｉｃｋ＿ｒｅｃｔ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇと同様であってもよい。一実施形態において、エンコーダは、以下のシンタックスおよびセマンティクスに従って、ＰＰＳまたはその一部を生成し、および／またはデコーダは、以下のシンタックスおよびセマンティクスに従って、ＰＰＳまたはその一部をデコーディングするが、このＰＰＳは、タイル、ブリック、および長方形スライスへの分離を含む。一実施形態において、エンコーダは、以下のシンタックスおよびセマンティクスに従って、ＳＰＳまたはその一部を生成し、および／またはデコーダは、以下のシンタックスおよびセマンティクスに従って、ＳＰＳまたはその一部をデコーディングするが、このＳＰＳは、タイル、ブリック、および長方形スライスへの分離を含む。
Figure 0007492978000001
Figure 0007492978000002
Figure 0007492978000003
ｓｐｓ＿ｔｉｌｅ＿ｂｒｉｃｋ＿ｒｅｃｔ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、このＳＰＳを参照するＰＰＳにｔｉｌｅ＿ｂｒｉｃｋ＿ｒｅｃｔ＿ｓｌｉｃｅ（）が存在することを規定する。ｓｐｓ＿ｔｉｌｅ＿ｂｒｉｃｋ＿ｒｅｃｔ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ＳＰＳ ＲＢＳＰシンタックスにｔｉｌｅ＿ｂｒｉｃｋ＿ｒｅｃｔ＿ｓｌｉｃｅ（）が存在することを規定する。
Figure 0007492978000004
ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ＝１は、ＰＰＳを参照する各画像にタイルが１つだけ存在することを規定する。ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ＝０は、ＰＰＳを参照する各画像にタイルが２つ以上存在することを規定する。なお、タイル内でブリックがそれ以上分割されない場合は、タイル全体をブリックと称する。ブリックがそれ以上分割されないタイルを１つだけ含む画像は、単一ブリックと称する。ビットストリームの適合要件として、ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの値は、ＣＶＳ内でアクティブ化されたすべてのＰＰＳについて同じであるものとする。
ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１は、タイル列境界および同様にタイル行境界が画像全体で均一に分布し、シンタックス要素ｔｉｌｅ＿ｃｏｌｓ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１およびｔｉｌｅ＿ｒｏｗｓ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１によって示されることを規定する。ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝０は、タイル列境界および同様にタイル行境界が画像全体で均一に分布していても分布していなくてもよく、シンタックス要素ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１およびｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１ならびにシンタックス要素対のリストｔｉｌｅ＿ｃｏｌｕｍｎ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］およびｔｉｌｅ＿ｒｏｗ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］によって示されることを規定する。存在しない場合、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇの値は、１に等しいものと推測される。
ｔｉｌｅ＿ｃｏｌｓ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１＋１は、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１の場合の画像の右端のタイル列を除くタイル列の幅をＣＴＢの単位で規定する。ｔｉｌｅ＿ｃｏｌｓ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値は、０～ＰｉｃＷｉｄｔｈＩｎＣｔｂｓＹ－１の範囲であるものとする。存在しない場合、ｔｉｌｅ＿ｃｏｌｓ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値は、ＰｉｃＷｉｄｔｈＩｎＣｔｂｓＹ－１に等しいものと推測される。
ｔｉｌｅ＿ｒｏｗｓ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１＋１は、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１の場合の画像の下端のタイル行を除くタイル行の高さをＣＴＢの単位で規定する。ｔｉｌｅ＿ｒｏｗｓ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値は、０～ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓＹ－１の範囲であるものとする。存在しない場合、ｔｉｌｅ＿ｒｏｗｓ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値は、ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓＹ－１に等しいものと推測される。
ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１＋１は、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝０の場合の画像を分離するタイル列の数を規定する。ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１の値は、０～ＰｉｃＷｉｄｔｈＩｎＣｔｂｓＹ－１の範囲であるものとする。ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ＝１の場合、ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１の値は、０に等しいものと推測される。一方、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１の場合、ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１の値は、ＣＴＢラスタースキャン、タイルスキャン、およびブリックスキャンプロセスにおける規定の通りに推測される。
ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１＋１は、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝０の場合の画像を分離するタイル行の数を規定する。ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１の値は、０～ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓＹ－１の範囲であるものとする。ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ＝１の場合、ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１の値は、０に等しいものと推測される。一方、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１の場合、ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１の値は、ＣＴＢラスタースキャン、タイルスキャン、およびブリックスキャンプロセスにおける規定の通りに推測される。変数ＮｕｍＴｉｌｅｓＩｎＰｉｃは、（ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１＋１）＊（ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１＋１）に等しく設定される。ｓｉｎｇｌｅ＿ｔｉｌｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ＝０の場合、ＮｕｍＴｉｌｅｓＩｎＰｉｃは、１より大きいものとする。
ｔｉｌｅ＿ｃｏｌｕｍｎ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］＋１は、ｉ番目のタイル列の幅をＣＴＢの単位で規定する。
ｔｉｌｅ＿ｒｏｗ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］＋１は、ｉ番目のタイル行の高さをＣＴＢの単位で規定する。
ｂｒｉｃｋ＿ｓｐｌｉｔｔｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ＰＰＳを参照する画像の１つまたは複数のタイルが２つ以上のブリックに分割され得ることを規定する。ｂｒｉｃｋ＿ｓｐｌｉｔｔｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ＰＰＳを参照する画像のタイルが２つ以上のブリックに分割されないことを規定する。
ｂｒｉｃｋ＿ｓｐｌｉｔ＿ｆｌａｇ［ｉ］＝１は、ｉ番目のタイルが２つ以上のブリックに分割されることを規定する。ｂｒｉｃｋ＿ｓｐｌｉｔ＿ｆｌａｇ［ｉ］＝０は、ｉ番目のタイルが２つ以上のブリックに分割されないことを規定する。存在しない場合、ｂｒｉｃｋ＿ｓｐｌｉｔ＿ｆｌａｇ［ｉ］の値は、０に等しいものと推測される。
ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝１は、水平ブリック境界がｉ番目のタイル全体で均一に分布し、シンタックス要素ｂｒｉｃｋ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］によって示されることを規定する。ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝０は、水平ブリック境界がｉ番目のタイル全体で均一に分布していても分布していなくてもよく、シンタックス要素ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］およびシンタックス要素のリストｂｒｉｃｋ＿ｒｏｗ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］［ｊ］によって示されることを規定する。存在しない場合、ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］の値は、１に等しいものと推測される。
ｂｒｉｃｋ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］＋１は、ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝１の場合のｉ番目のタイルの下端のブリックを除くブリック行の高さをＣＴＢの単位で規定する。存在する場合、ｂｒｉｃｋ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値は、０～ＲｏｗＨｅｉｇｈｔ［ｉ］－２の範囲であるものとする。存在しない場合、ｂｒｉｃｋ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］の値は、ＲｏｗＨｅｉｇｈｔ［ｉ］－１に等しいものと推測される。
ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］＋１は、ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝０の場合のｉ番目のタイルを分離するブリックの数を規定する。存在する場合、ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］の値は、１～ＲｏｗＨｅｉｇｈｔ［ｉ］－１の範囲であるものとする。ｂｒｉｃｋ＿ｓｐｌｉｔ＿ｆｌａｇ［ｉ］＝０の場合、ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］の値は、０に等しいものと推測される。一方、ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝１の場合、ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］の値は、ＣＴＢラスタースキャン、タイルスキャン、およびブリックスキャンプロセスにおける規定の通りに推測される。
ｂｒｉｃｋ＿ｒｏｗ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］［ｊ］＋１は、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝０の場合のｉ番目のタイルのｊ番目のブリックの高さをＣＴＢの単位で規定する。
以下の変数が導出され、ｕｎｉｆｏｒｍ＿ｔｉｌｅ＿ｓｐａｃｉｎｇ＿ｆｌａｇ＝１の場合は、ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１およびｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１の値が推測され、０～ＮｕｍＴｉｌｅｓＩｎＰｉｃ－１の範囲の各ｉについて、ｕｎｉｆｏｒｍ＿ｂｒｉｃｋ＿ｓｐａｃｉｎｇ＿ｆｌａｇ［ｉ］＝１の場合は、ＣＴＢラスタースキャン、タイルスキャン、およびブリックスキャンプロセスの呼び出しによって、ｎｕｍ＿ｂｒｉｃｋ＿ｒｏｗｓ＿ｍｉｎｕｓ１［ｉ］の値が推測される。
リストＲｏｗＨｅｉｇｈｔ［ｊ］は、０～ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１の範囲のｊについて、ｊ番目のタイル行の高さをＣＴＢの単位で規定する。
リストＣｔｂＡｄｄｒＲｓＴｏＢｓ［ｃｔｂＡｄｄｒＲｓ］は、０～ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１の範囲のｃｔｂＡｄｄｒＲｓについて、画像のＣＴＢラスタースキャンにおけるＣＴＢアドレスからブリックスキャンにおけるＣＴＢアドレスへの変換を規定する。
リストＣｔｂＡｄｄｒＢｓＴｏＲｓ［ｃｔｂＡｄｄｒＢｓ］は、０～ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１の範囲のｃｔｂＡｄｄｒＢｓについて、ブリックスキャンにおけるＣＴＢアドレスから画像のＣＴＢラスタースキャンにおけるＣＴＢアドレスへの変換を規定する。
リストＢｒｉｃｋＩＤ［ｃｔｂＡｄｄｒＢｓ］は、０～ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１の範囲のｃｔｂＡｄｄｒＢｓについて、ブリックスキャンにおけるＣＴＢアドレスからブリックＩＤへの変換を規定する。
リストＮｕｍＣｔｕｓＩｎＢｒｉｃｋ［ｂｒｉｃｋＩｄｘ］は、０～ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ－１の範囲のｂｒｉｃｋＩｄｘについて、ブリックインデックスからブリック中のＣＴＵ数への変換を規定する。
リストＦｉｒｓｔＣｔｂＡｄｄｒＢｓ［ｂｒｉｃｋＩｄｘ］は、０～ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ－１の範囲のｂｒｉｃｋＩｄｘについて、ブリックＩＤからブリック中の最初のＣＴＢのブリックスキャンにけるＣＴＢアドレスへの変換を規定する。
ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇ＝１は、このＰＰＳを参照する各スライスが１つのブリックを含むことを規定する。ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇ＝０は、このＰＰＳを参照するスライスが２つ以上のブリックを含み得ることを規定する。存在しない場合、ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇの値は、１に等しいものと推測される。
ｒｅｃｔ＿ｓｌｉｃｅ＿ｆｌａｇ＝０は、各スライス内のブリックがラスタースキャンの順序であり、スライス情報がＰＰＳにおいて示されないことを規定する。ｒｅｃｔ＿ｓｌｉｃｅ＿ｆｌａｇ＝１は、各スライス内のブリックが画像の長方形領域を網羅し、スライス情報がＰＰＳにおいて示されることを規定する。ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇ＝１の場合、ｒｅｃｔ＿ｓｌｉｃｅ＿ｆｌａｇは、１に等しいものと推測される。
ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１＋１は、ＰＰＳを参照する各画像のスライス数を規定する。ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１の値は、０～ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ－１の範囲であるものとする。存在せず、ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇ＝１の場合、ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１の値は、ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ－１に等しいものと推測される。
ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］は、ｉ番目のスライスの左上隅に配置されたブリックのブリックインデックスを規定する。ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］の値は、ｊに等しくない如何なるｉについても、ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｊ］の値に等しくないものとする。存在しない場合、ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］の値は、ｉに等しいものと推測される。ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ））ビットである。
ｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｂｒｉｃｋ＿ｉｄｘ＿ｄｅｌｔａ［ｉ］は、ｉ番目のスライスの右下隅に配置されたブリックのブリックインデックスとｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］との差を規定する。ｓｉｎｇｌｅ＿ｂｒｉｃｋ＿ｐｅｒ＿ｓｌｉｃｅ＿ｆｌａｇ＝１の場合、ｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｂｒｉｃｋ＿ｉｄｘ＿ｄｅｌｔａ［ｉ］の値は、０に等しいものと推測される。ｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｂｒｉｃｋ＿ｉｄｘ＿ｄｅｌｔａ［ｉ］シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ－ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］））ビットである。
ビットストリームの適合要件として、スライスには、多くの完全タイルまたは１つのタイルの一連の完全ブリックのみを含むものとする。ｉ番目のスライスのブリック数およびブリックのスライスへのマッピングを規定する変数ＮｕｍＢｒｉｃｋｓＩｎＳｌｉｃｅ［ｉ］およびＢｒｉｃｋｓＴｏＳｌｉｃｅＭａｐ［ｊ］は、以下のように導出される。
ＮｕｍＢｒｉｃｋｓＩｎＳｌｉｃｅ［ｉ］＝０
ｂｏｔＲｉｇｈｔＢｋＩｄｘ＝ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］＋ｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｂｒｉｃｋ＿ｉｄｘ＿ｄｅｌｔａ［ｉ］
ｆｏｒ（ｊ＝０；ｊ＜ＮｕｍＢｒｉｃｋｓＩｎＰｉｃ；ｊ＋＋）｛
ｉｆ（ＢｒｉｃｋＣｏｌＢｄ［ｊ］＞＝ＢｒｉｃｋＣｏｌＢｄ［ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］］＆＆
ＢｒｉｃｋＣｏｌＢｄ［ｊ］＜＝ＢｒｉｃｋＣｏｌＢｄ［ｂｏｔＲｉｇｈｔＢｋＩｄｘ］＆＆
ＢｒｉｃｋＲｏｗＢｄ［ｊ］＞＝ＢｒｉｃｋＲｏｗＢｄ［ｔｏｐ＿ｌｅｆｔ＿ｂｒｉｃｋ＿ｉｄｘ［ｉ］］＆＆
ＢｒｉｃｋＲｏｗＢｄ［ｊ］＜＝ＢｒｉｃｋＣｏｌＢｄ［ｂｏｔＲｉｇｈｔＢｋＩｄｘ］）｛
ＮｕｍＢｒｉｃｋｓＩｎＳｌｉｃｅ［ｉ］＋＋
ＢｒｉｃｋｓＴｏＳｌｉｃｅＭａｐ［ｊ］＝ｉ
｝
｝
デコーダは、エンコーダと同様の予測手段を適用することにより、（エンコーダにより生成されて圧縮表現に格納された動きまたは空間情報を使用して）ピクセルブロックの予測表現を構成するとともに、（予測誤差コーディングの逆動作であり、空間ピクセル領域において量子化予測誤差信号を復元する）予測誤差デコーディングによって出力ビデオを再構成する。予測および予測誤差デコーディング手段を適用した後、デコーダは、予測および予測誤差信号（ピクセル値）を合計して、出力ビデオフレームを構成する。また、デコーダ（および、エンコーダ）は、付加的なフィルタリング手段の適用によって、表示用の受け渡しおよび／またはビデオシーケンスの後続フレームの予測基準としての格納前の出力ビデオの品質を向上させることも可能である。
フィルタリングには、たとえばデブロッキング、サンプル適応オフセット（ＳＡＯ）、および／または適応ループフィルタリング（ＡＬＦ）のうちの１つまたは複数を含んでいてもよい。
デブロッキングループフィルタには、量子化パラメータ値等の境界に隣り合うブロックの特徴および／またはエンコーダによってビットストリームに含められるシグナリングに基づいて適応的に選択可能な複数のフィルタリングモードまたは強度を含んでいてもよい。たとえば、デブロッキングループフィルタは、通常のフィルタリングモードおよび強いフィルタリングモードを含んでいてもよく、これらは、フィルタタップの数（すなわち、境界の両側でフィルタリングされるサンプルの数）および／またはフィルタタップ値に関して異なり得る。たとえば、境界の両側に沿った２つのサンプルのフィルタリングは、クリッピング操作の潜在的な影響を省略する場合、（３ ７ ９ －３）／１６のインパルス応答を有するフィルタにより実行されるようになっていてもよい。
動き情報は、ビデオコーデックにおける各動き補償イメージブロックと関連付けられた動きベクトルによって示し得る。これらの動きベクトルはそれぞれ、（エンコーダ側の）コード化対象画像もしくは（デコーダ側の）デコード対象画像中のイメージブロックならびにコード化もしくはデコード画像のうちの１つにおける予測元ブロックの変位を表す。これらは、動きベクトルを効率的に表すため、ブロック固有の予測動きベクトルに関して、異なるコーディングがなされていてもよい。予測動きベクトルは、たとえば隣り合うブロックのエンコードまたはデコード動きベクトルの中央値の計算等、所定の方法で生成されるようになっていてもよい。動きベクトル予測を生成する別の方法では、時間基準画像中の隣り合うブロックおよび／または同位置のブロックから予測候補のリストを生成し、選定した候補を動きベクトル予測子として示す。動きベクトル値の予測のほか、コード化／デコード画像の基準インデックスを予測可能である。基準インデックスは、時間基準画像中の隣り合うブロックおよび／または同位置のブロックから予測されるようになっていてもよい。さらに、高効率ビデオコーデックでは、付加的な動き情報コーディング／デコーディングメカニズム、マージング／マージモードと称することが多い、を採用するようにしてもよく、この場合は、一切の修正／補正なく、利用可能な基準画像リストごとの動きベクトルおよび対応する基準画像インデックスを含むすべての動きフィールド情報が予測・使用される。同様に、動きフィールドの予測は、時間基準画像中の隣り合うブロックおよび／または同位置のブロックの動きフィールド情報を用いて実行され、使用される動きフィールド情報は、利用可能な隣り合うブロック／同位置のブロックの動きフィールド情報で満たされた動きフィールド候補リストのリストから示される。
ビデオコーデックは、１つのソースイメージからの動き補償予測（一重予測）および２つのソースからの動き補償予測（二重予測）をサポートしていてもよい。一重予測の場合は単一の動きベクトルが適用される一方、二重予測の場合は２つの動きベクトルが示され、２つのソースからの動き補償予測が平均化されて最終的なサンプル予測が生成される。重み付け予測の場合は、２つの予測の相対的な重みを調整することも可能であるし、シグナリングオフセットを予測信号に追加することも可能である。
相互画像予測に対する動き補償の適用のほか、類似の手法を内部画像予測に適用可能である。この場合、変位ベクトルは、同じ画像からサンプルブロックをコピーしてコーディングまたはデコーディング対象のブロックの予測を構成可能な場所を示す。この種の内部ブロックコピー法によれば、テキストまたは他のグラフィックス等、フレーム内の繰り返し構造の存在下で実質的に、コーディング効率を向上可能となる。
動き補償または内部予測後の予測残差は、最初に変換カーネル（ＤＣＴ等）で変換された後、コーディングされるようになっていてもよい。その理由として、残差の間には何らかの相関が依然として存在することが多く、変換は多くの場合、この相関を低下させ、より効率的なコーディングを提供するのに役立ち得る。
ビデオエンコーダは、ラグランジュコスト関数を利用して、最適なコーディングモード、たとえば、所望のマクロブロックモードおよび関連する動きベクトルを見つけることができる。この種のコスト関数では、非可逆コーディング法による（正確または推定）イメージ歪みとイメージエリアのピクセル値の表現に必要な（正確または推定）情報量とを結びつける重み付け係数λを使用する。
Ｃ＝Ｄ＋λＲ （式１）
ここで、Ｃは最小化すべきラグランジュコスト、Ｄはモードおよび動きベクトルを考慮したイメージ歪み（たとえば、平均二乗誤差）、Ｒはデコーダにおけるイメージブロックの再構成に要するデータを表すのに必要なビット数（候補動きベクトルを表すためのデータ量を含む）である。
一部のコーデックでは、画像順序カウント（ＰＯＣ）の概念を使用する。ＰＯＣの値が画像ごとに導出されるが、これは、出力順序で画像位置が上昇しても低下しない。したがって、ＰＯＣは、画像の出力順序を示す。ＰＯＣは、たとえば動きベクトルの暗示的なスケーリングおよび基準画像リストの初期化のため、デコーディングプロセスに用いられるようになっていてもよい。さらに、ＰＯＣは、出力順序の適合確認に用いられるようになっていてもよい。
ビデオコーディング規格においては、エンコーダの出力に概念的に接続可能で、少なくともプリデコーダバッファ、デコーダ、および出力／表示ユニットから成る仮想の基準デコーダによって、準拠するビットストリームがデコーディング可能となる必要がある。この仮想デコーダは、仮想基準デコーダ（ＨＲＤ）またはビデオバッファリング確認器（ＶＢＶ）として知られている場合もある。ストリームは、バッファのオーバフロー、場合により、アンダーフローなしにＨＲＤによってデコーディング可能な場合に準拠する。バッファのオーバフローは、満杯のバッファにさらにビットを配置しようとする場合に発生する。バッファのアンダーフローは、デコーディング／再生のためにバッファから取り出そうとするビットがバッファに存在しない場合に発生する。ＨＲＤの目的として、実用的なデコーダ実装を取り扱えないほど大量のリソースを消費する、いわゆる有害なビットストリームを回避することが挙げられる。
ＨＲＤモデルには通常、瞬時デコーディングを含むが、ＨＲＤのコード化画像バッファ（ＣＰＢ）への入力ビットレートは、エンコーダおよびビットストリームにとってはコード化データのデコーディングレートに関する制約、デコーダにとっては処理レートに関する要求と見なすことができる。エンコーダは、バッファリング制約がエンコーディングにおいて順守されることを確認・制御するため、ＨＲＤに規定のようなＣＰＢを含んでいてもよい。また、デコーダの実施態様には、必ずしもその必要はないが、ＨＲＤに規定されたＣＰＢと同様または同一に動作し得るＣＰＢを有していてもよい。
エンコーダおよび／またはデコーダにおいては、デコード画像バッファ（ＤＰＢ）が用いられるようになっていてもよい。デコード画像のバッファリングには、相互予測における参照およびデコード画像の出力順序への並べ替えという２つの理由が考えられ得る。ＨＥＶＣ等の一部のコーディングフォーマットでは、基準画像のマーキングおよび出力の並べ替えの両者に大きな柔軟性があり、基準画像のバッファリングおよび出力画像のバッファリングに別個のバッファを使用すると、メモリリソースを浪費する可能性がある。そこで、ＤＰＢには、基準画像および出力並べ替え用の統合デコード画像バッファリングプロセスを含んでいてもよい。デコード画像は、もはや基準として使用されず、出力に不要となった場合、ＤＰＢから除去されるようになっていてもよい。また、ＨＲＤがＤＰＢを具備していてもよい。ＨＲＤのＤＰＢおよびデコーダ実施態様は、同じ動作であってもよいが、必ずしもその必要はない。
出力順序（ｏｕｔｐｕｔ ｏｒｄｅｒ）は、（デコード画像バッファからデコード画像が出力される場合の）デコード画像バッファからデコード画像が出力される順序として定義可能である。
デコーダおよび／またはＨＲＤには、画像出力プロセスを含んでいてもよい。出力プロセスは、デコーダがデコーディングプロセスの出力としてデコードおよびクロッピング画像を提供するプロセスと考えられる。出力プロセスは通常、仮想基準デコーダ仕様の一部としてのビデオコーディング規格の一部である。出力クロッピングにおいては、クロッピング長方形に従って、サンプルの線および／または列をデコード画像から除去することにより、出力画像を構成可能である。クロッピングされたデコード画像（ｃｒｏｐｐｅｄ ｄｅｃｏｄｅｄ ｐｉｃｔｕｒｅ）は、たとえば対応するコード化画像が参照するシーケンスパラメータ集合で規定された適合クロッピングウィンドウに基づいてデコード画像をクロッピングした結果として定義可能である。
ビデオコーディングシステムには、（デコード）基準画像マーキングのための１つまたは複数のシンタックス構造が存在していてもよい。エンコーダは、たとえば各コード化画像においてシンタックス構造のインスタンスを生成し、デコーダは、たとえば各コード化画像からシンタックス構造のインスタンスをデコーディングする。たとえば、シンタックス構造のデコーディングによって、画像に「参照使用」または「参照不使用」と適応マーキング可能となる。
ＨＥＶＣの基準画像集合（ＲＰＳ）シンタックス構造が基準画像マーキング用シンタックス構造の一例である。ある画像に対して有効またはアクティブな基準画像集合には、当該画像の参照として使用され得るすべての基準画像と、デコーディング順序の後続の任意の画像に対して「参照使用」とマーキングされ続けているすべての基準画像と、を含む。デコーディング順序の後続の任意の画像に対して「参照使用」とマーキングされ続けているものの、現在の画像またはイメージセグメントの基準画像として使用されていない基準画像は、非アクティブと考えられ得る。たとえば、これらは、最初の基準画像リストに含まれていない可能性もある。
一部のコーディングフォーマットおよびコーデックにおいては、いわゆる短期基準画像と長期基準画像とが区別されている。この区別は、動きベクトルスケーリング等の一部のデコーディングプロセスに影響を及ぼす可能性がある。基準画像をマーキングするシンタックス構造は、「長期参照使用」または「短期参照使用」としての画像のマーキングを示していてもよい。
一部のコーディングフォーマットにおいては、基準画像リストへのインデックスによって、相互予測の基準画像が示されるようになっていてもよい。一部のコーデックにおいては、二重予測（ｂｉ－ｐｒｅｄｉｃｔｉｖｅ）（Ｂ）スライスごとに２つの基準画像リスト（基準画像リスト０および基準画像リスト１）が生成され、相互コード化（ｉｎｔｅｒ－ｃｏｄｅｄ）（Ｐ）スライスごとに１つの基準画像リスト（基準画像リスト０）が形成される。
基準画像リスト０および基準画像リスト１等の基準画像リストが２ステップで構成されるようになっていてもよく、まず、最初の基準画像リストが生成される。最初の基準画像リストは、規格において予め規定されたアルゴリズムを用いて生成されるようになっていてもよい。このようなアルゴリズムでは、基準として、たとえばＰＯＣおよび／または時間的サブレイヤを使用するようにしてもよい。このアルゴリズムでは、「参照使用」等の特定のマーキングのある基準画像を処理し、他の基準画像を省略するようにしてもよい。すなわち、他の基準画像を最初の基準画像リストに挿入しないようにしてもよい。このような他の基準画像の一例として、「参照不使用」とマーキングされる一方、デコーダからの出力を待つデコード画像バッファに依然として存在する基準画像がある。第二に、最初の基準画像リストは、Ｈ．２６４／ＡＶＣの基準画像リスト並べ替え（ＲＰＬＲ）コマンドまたはＨＥＶＣの基準画像リスト修正シンタックス構造または任意の同等のもの、特定のシンタックス構造により並べ替えられるようになっていてもよい。さらに、アクティブな基準画像の数がリストごとに示されていてもよく、また、リスト中のアクティブ画像を超える相互予測の基準としての画像の使用は無効化される。基準画像リストの初期化および基準画像リストの修正の一方または両方では、「参照使用」または同等のマーキングが施された基準画像のうち、アクティブな基準画像のみを処理するようにしてもよい。
スケーラブルビデオコーディングは、１つのビットストリームが異なるビットレート、解像度、またはフレームレートのコンテンツの複数の表現を含み得るコーディング構造を表す。これらの場合、受信側は、その特性（たとえば、表示装置に最適な解像度）に応じて所望の表現を抽出可能である。あるいは、サーバまたはネットワーク要素は、たとえば受信側のネットワーク特性または処理機能に応じて、受信側に伝送されるビットストリームの一部を抽出可能である。スケーラブルビットストリームは、利用可能な最低品質のビデオを提供する「基本レイヤ」と、受信および下位レイヤと併せたデコーディングに際してビデオ品質を向上させる１つまたは複数の拡張レイヤと、を含んでいてもよい。拡張レイヤのコーディング効率を向上させるため、当該レイヤのコード化表現は、下位レイヤに依存していてもよい。たとえば、拡張レイヤの動き情報およびモード情報は、下位レイヤから予測可能である。同様に、下位レイヤのピクセルデータの使用により、拡張レイヤの予測を生成可能である。
品質スケーラビリティ（信号対雑音またはＳＮＲとしても知られる）および／または空間スケーラビリティのためのスケーラブルビデオコーデックが以下のように実装されていてもよい。基本レイヤに対しては、従来の非スケーラブルビデオエンコーダおよびデコーダが使用される。基本レイヤの再構成／デコード画像は、拡張レイヤの基準画像バッファに含まれる。Ｈ．２６４／ＡＶＣ、ＨＥＶＣ、および相互予測のための基準画像リストを使用する類似のコーデックにおいては、拡張レイヤのデコーディング基準画像と同様に、拡張レイヤの画像のコーディング／デコーディングのための基準画像リストに基本レイヤデコード画像が挿入されるようになっていてもよい。その結果、エンコーダは、基本レイヤ基準画像を相互予測基準として選定し、たとえばコード化ビットストリームの基準画像インデックスによって、その使用を示すようにしてもよい。デコーダは、ビットストリームから、たとえば、基準画像インデックスから、基本レイヤ画像が拡張レイヤの相互予測基準として使用されることをデコーディングする。デコーディングされた基本レイヤ画像は、拡張レイヤの予測基準として使用される場合、レイヤ間基準画像と称する。
スケーラビリティモードまたはスケーラビリティ次元としては、以下が挙げられるが、これらに限定されない。
品質スケーラビリティ：基本レイヤ画像は、拡張レイヤ画像よりも低い品質でコーディングされるが、これは、たとえば拡張レイヤよりも基本レイヤにおいて、より大きな量子化パラメータ値（すなわち、変換係数量子化のためのより大きな量子化ステップサイズ）を使用することにより実現可能と考えられる。
空間スケーラビリティ：基本レイヤ画像は、拡張レイヤ画像よりも低い解像度でコーティングされる（すなわち、サンプル数が少ない）。空間スケーラビリティおよび品質スケーラビリティは、同じ種類のスケーラビリティと考えられる場合がある。
ビット深度スケーラビリティ：基本レイヤ画像は、拡張レイヤ画像（たとえば、１０または１２ビット）よりも低いビット深度（たとえば、８ビット）でコーティングされる。
ダイナミックレンジスケーラビリティ：スケーラブルレイヤは、異なるダイナミックレンジ、異なるトーンマッピング関数を用いて得られたイメージ、および／または異なる光学的伝達関数を表す。
彩度フォーマットスケーラビリティ：基本レイヤ画像は、拡張レイヤ画像（たとえば、４：４：４フォーマット）よりも彩度サンプルアレイ（たとえば、４：２：０彩度フォーマットデコーディング）において、より低い空間解像度を提供する。
色域スケーラビリティ：拡張レイヤ画像は、基本レイヤ画像よりも豊富／広範な色表現範囲を有する。たとえば、拡張レイヤがＵＨＤＴＶ（ＩＴＵ－Ｒ ＢＴ．２０２０）の色域を有し、基本レイヤがＩＴＵ－Ｒ ＢＴ．７０９の色域を有していてもよい。
関心領域（ＲＯＩ）スケーラビリティ：拡張レイヤは、基本レイヤの空間的部分集合を表す。拡張レイヤが空間的部分集合に対してより高い主観的品質を提供するように、他種のスケーラビリティたとえば、品質または空間スケーラビリティと併せてＲＯＩスケーラビリティが用いられるようになっていてもよい。
ビュースケーラビリティ：マルチビューコーディングとも称し得る。基本レイヤが第１のビューを表す一方、拡張レイヤが第２のビューを表す。
深度スケーラビリティ：深度拡張コーディングとも称し得る。ビットストリームの１つまたは複数のレイヤがテクスチャビューを表す一方、他の１つまたは複数のレイヤが深度ビューを表していてもよい。
スケーラビリティに関する上記すべての場合において、基本レイヤ情報の使用により、付加的なビットレートオーバヘッドを最小にするように拡張レイヤをコーディングすることも可能である。
スケーラビリティは、２つの基本的な方法により有効化可能である。スケーラブル表現の下位レイヤからピクセル値またはシンタックスの予測を行う新たなコーディングモードを導入するか、または、下位レイヤの画像を上位レイヤの基準画像バッファ（デコード画像バッファ、ＤＰＢ）に配置する。第１の手法は、より柔軟であるため、ほとんどの場合により優れたコーディング効率を提供可能である。ただし、第２の基準フレームに基づくスケーラビリティ手法は、単一レイヤコーデックに対する最小限の変更で非常に効率良く実現可能でありつつ、可能なコーディング効率化の大部分を実現可能である。本質的に、基準フレームに基づくスケーラビリティコーデックは、すべてのレイヤに同じハードウェアまたはソフトウェア実装を利用し、ＤＰＢ管理のみを外部手段で行うことにより実現可能である。
送信側、ゲートウェイまたは同等のものがスケーラブルビデオビットストリームの伝送レイヤおよび／またはサブレイヤを選択するようにしてもよいし、同様に、受信側、クライアント、プレーヤまたは同等のものがスケーラブルビデオビットストリームの選択レイヤおよび／またはサブレイヤの伝送を要求するようにしてもよい。レイヤ抽出（ｌａｙｅｒ ｅｘｔｒａｃｔｉｏｎ）、レイヤの抽出（ｅｘｔｒａｃｔｉｏｎ ｏｆ ｌａｙｅｒｓ）、またはレイヤダウンスイッチング（ｌａｙｅｒ ｄｏｗｎ－ｓｗｉｔｃｈｉｎｇ）という用語は、ビットストリームで利用可能な数よりも少なくレイヤの伝送を表す。レイヤアップスイッチングは、レイヤアップスイッチングに先立って伝送されたものに対する付加的なレイヤの伝送、すなわち、レイヤダウンスイッチングの初期に伝送が中断された１つまたは複数のレイヤの伝送の再開を表し得る。レイヤダウンスイッチングおよび／またはアップスイッチングと同様に、時間的サブレイヤのダウンスイッチングおよび／またはアップスイッチングが実行されるようになっていてもよい。レイヤおよびサブレイヤダウンスイッチングおよび／またはアップスイッチングはいずれも、同様に実行されるようになっていてもよい。レイヤおよびサブレイヤダウンスイッチングおよび／またはアップスイッチングは、同じアクセス単位または同等のものにおいて（すなわち、仮想的に同時に）実行されるようになっていてもよいし、異なるアクセス単位または同等のものにおいて（すなわち、仮想的に異なるタイミングで）実行されるようになっていてもよい。レイヤアップスイッチングは、ランダムアクセス画像（たとえば、ＨＥＶＣのＩＲＡＰ画像）において生じ得る。サブレイヤアップスイッチングは、特定種類の画像（たとえば、ＨＥＶＣのＳＴＳＡまたはＴＳＡ画像）において生じ得る。
ＨＥＶＣ等の一部のコーディングフォーマットのエンコーダの出力およびＨＥＶＣ等の一部のコーディングフォーマットのデコーダの入力の基本単位は、ネットワーク抽象化レイヤ（ＮＡＬ）単位である。パケット指向ネットワーク上の転送または構造化ファイルへの格納の場合、ＮＡＬ単位は、パケットまたは類似の構造にカプセル化されるようになっていてもよい。
フレーム構造を提供しない伝送または格納環境のＮＡＬ単位のストリームに対して、バイトストリームフォーマットを規定可能である。バイトストリームフォーマットでは、各ＮＡＬ単位の前に始端コードを付加することによって、ＮＡＬ単位を互いに分離する。ＮＡＬ単位境界の誤検出を防ぐため、エンコーダは、バイト指向の始端コードエミュレーション防止アルゴリズムを動作させる。これは、始端コードが発生すると考えられる場合に、エミュレーション防止バイトをＮＡＬ単位ペイロードに追加する。パケット指向システムとストリーム指向システムとの間の容易なゲートウェイ動作を可能とするため、バイトストリームフォーマットが使用されるか否かに関わらず、始端コードエミュレーション防止が常に実行されるようになっていてもよい。
ＮＡＬ単位（ＮＡＬ ｕｎｉｔ）は、後続のデータの種類の指標と、必要に応じてエミュレーション防止バイトを挟んだ未加工バイトシーケンスペイロード（ＲＢＳＰ）の形態の当該データを含むバイトと、を含むシンタックス構造として定義可能である。ＲＢＳＰ（ｒａｗ ｂｙｔｅ ｓｅｑｕｅｎｃｅ ｐａｙｌｏａｄ）は、ＮＡＬ単位でカプセル化された整数個のバイトを含むシンタックス構造として定義可能である。ＲＢＳＰは、空であるか、または、シンタックス要素を含むデータビットにＲＢＳＰ停止ビットと、０に等しい０個以上の後続ビットとが続く文字列の形態を有する。
ＮＡＬ単位は、ヘッダおよびペイロードから成る。ＨＥＶＣにおいては、規定されたすべてのＮＡＬ単位タイプに対して２バイトのＮＡＬ単位ヘッダが使用される一方、他のコーデックにおいては、ＮＡＬ単位ヘッダがＨＥＶＣと類似していてもよい。
ＨＥＶＣにおいて、ＮＡＬ単位ヘッダは、１つの予約ビット、６ビットのＮＡＬ単位タイプ指標、時間的レベルまたはサブレイヤのための３ビットのｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１指標（１以上が必要な場合もある）、６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を含む。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１シンタックス要素は、ＮＡＬ単位の時間的識別子と見なすことができ、ゼロベースのＴｅｍｐｏｒａｌＩｄ変数は、ＴｅｍｐｏｒａｌＩｄ＝ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１－１のように導出可能である。略語ＴＩＤをＴｅｍｐｏｒａｌＩｄ変数と同じ意味で使用する場合がある。ＴｅｍｐｏｒａｌＩｄ＝０は、最低の時間的レベルに対応する。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値は、２つのＮＡＬ単位ヘッダバイトに関わる始端コードエミュレーションを回避するため、非ゼロとする必要がある。選択値以上のＴｅｍｐｏｒａｌＩｄを有するすべてのＶＣＬ ＮＡＬ単位を除外し、他のすべてのＶＣＬ ＮＡＬ単位を含むことにより生成されたビットストリームは、適合性を維持する。その結果、ＴｅｍｐｏｒａｌＩｄがｔｉｄ＿ｖａｌｕｅと等しい画像は、ｔｉｄ＿ｖａｌｕｅより大きなＴｅｍｐｏｒａｌＩｄを有する画像を相互予測基準として一切使用しない。サブレイヤ（ｓｕｂ－ｌａｙｅｒ）または時間的サブレイヤ（ｔｅｍｐｏｒａｌ ｓｕｂ－ｌａｙｅｒ）は、時間的スケーラブルビットストリームの時間的スケーラブルレイヤ（または、時間的レイヤＴＬ）として定義可能である。このような時間的スケーラブルレイヤは、ＴｅｍｐｏｒａｌＩｄ変数の特定の値を有するＶＣＬ ＮＡＬ単位および関連する非ＶＣＬ ＮＡＬ単位を含んでいてもよい。ｎｕｈ＿ｌａｙｅｒ＿ｉｄは、スケーラビリティレイヤ識別子として理解可能である。
ＮＡＬ単位は、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬ単位および非ＶＣＬ ＮＡＬ単位に分類可能である。ＶＣＬ ＮＡＬ単位は通常、コード化スライスＮＡＬ単位である。ＨＥＶＣにおいて、ＶＣＬ ＮＡＬ単位は、１つまたは複数のＣＵを表すシンタックス要素を含む。ＨＥＶＣにおいて、特定の範囲内のＮＡＬ単位タイプは、ＶＣＬ ＮＡＬ単位を示し、ＶＣＬ ＮＡＬ単位タイプは、画像タイプを示す。
イメージは、独立コーディングおよびデコーディング可能なイメージセグメント（たとえば、スライス、タイル、またはタイル群）に分割可能である。このようなイメージセグメントは、並列処理を可能にし得る。本明細書において、「スライス」は、デフォルトのコーディングまたはデコーディング順序で処理される特定個数の基本コーディング単位で構成されたイメージセグメントを表し得る。一方、「タイル」は、長方形のイメージ領域として規定されたイメージセグメントを表し得る。タイル群（ｔｉｌｅ ｇｒｏｕｐ）は、一群の１つまたは複数のタイルとして定義可能である。イメージセグメントは、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおけるＶＣＬ ＮＡＬ単位等、ビットストリームにおける別個の単位としてコーディングされ得る。コード化イメージセグメントは、ヘッダおよびペイロードを含み得るが、このヘッダは、ペイロードのデコーディングに必要なパラメータ値を含む。
独立コード化画像領域（ｉｎｄｅｐｅｎｄｅｎｔｌｙ ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｒｅｇｉｏｎ）は、独立コード化画像領域のデコーディングが、独立コード化画像領域外のサンプル値にも、同じコード化画像の他のコード化画像領域から導出された変数にも依存しないような画像領域として定義可能である。独立コード化画像領域は、基準画像中の他のコード化画像領域からではなく、基準画像中の各独立コード化画像領域から予測され得る。
独立コード化画像領域シーケンス（ｉｎｄｅｐｅｎｄｅｎｔｌｙ ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｒｅｇｉｏｎ ｓｅｑｕｅｎｃｅ）は、一連の各独立コード化画像領域として定義可能である。各独立コード化画像領域は、たとえばサブ画像シーケンス識別子または同等のものを用いて示されるものであってもよいし、たとえば画像シーケンス中の同位置のイメージシーケンスとして推測されるものであってもよい。
一部の状況において、独立コード化画像領域（ｉｎｄｅｐｅｎｄｅｎｔｌｙ ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｒｅｇｉｏｎ）という用語は、独立コード化画像領域シーケンスの一部である場合にのみ使用される。たとえば、ある長方形スライスを同じ画像の他の長方形スライスから独立してデコーディング可能であってもよいが、その長方形スライスは、基準画像中の対応する長方形スライス外のエリアのサンプル値を使用する場合、独立コード化画像領域と見なされない場合もある。
構成ビットストリーム（ｃｏｎｓｔｉｔｕｅｎｔ ｂｉｔｓｔｒｅａｍ）という用語は、独立コード化画像領域シーケンスに対して使用可能である。ただし、構成ビットストリームは、他の目的でも使用可能であり、たとえば、同じビットストリームに（たとえば、別個の独立レイヤとして）多重化されたテクスチャビデオビットストリームおよびデプスビデオビットストリームは、構成ビットストリームと見なすことができる。
独立デコーディング可能な画像領域（ｉｎｄｅｐｅｎｄｅｎｔｌｙ ｄｅｃｏｄａｂｌｅ ｐｉｃｔｕｒｅ ｒｅｇｉｏｎ）および独立コード化画像領域（ｉｎｄｅｐｅｎｄｅｎｔｌｙ ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｒｅｇｉｏｎ）という用語は、同じ意味で使用する場合がある。エンコーディングおよび／もしくはデコーディングにおいて独立コード化画像領域および／または独立コード化画像領域シーケンスを実現する方法は多数存在する可能性があるため、実施形態は単一の方法に限定されず、如何なる方法にも適用可能であることが了解される必要がある。以下の段落において、独立コード化画像領域および独立コード化画像領域シーケンスのいくつかの例を説明する。
動き制約タイル集合（ＭＣＴＳ）は、独立コード化画像領域の実現例であり、同様に、ＭＣＴＳシーケンスは、独立コード化画像領域シーケンスの一例である。動き制約タイル集合（ＭＣＴＳ）は、動き制約タイル集合外のサンプル値も、動き制約タイル集合外の１つまたは複数のサンプル値を用いて導出された部分サンプル位置におけるサンプル値も、動き制約タイル集合内の如何なるサンプルの相互予測にも使用されないように、エンコーディングにおいて相互予測プロセスが制約されているようになっている。また、ＭＣＴＳのエンコーディングは、ＭＣＴＳ外のブロックに由来する変数も如何なるデコーディング結果も、ＭＣＴＳ内の如何なるデコーディング処理にも使用されないように制約されている。たとえば、ＭＣＴＳのエンコーディングは、ＭＣＴＳ外のブロックから動きベクトル候補が導出されないように制約されている。これは、ＨＥＶＣの時間的動きベクトル予測をオフにするか、または、ＭＣＴＳの右下にある最後のタイル境界を除いて、ＭＣＴＳの右下タイル境界の真左に配置されたＰＵのマージまたはＡＭＶＰ候補リストにおいてＴＭＶＰ候補またはＴＭＶＰ候補に続く任意の動きベクトル予測候補をエンコーダが使用できないようにすることによって強制され得る。一般的に、ＭＣＴＳは、ＭＣＴＳ外にあるサンプル値および動きベクトル等のコード化データから独立したタイル集合として定義可能である。ＭＣＴＳシーケンス（ＭＣＴＳ ｓｅｑｕｅｎｃｅ）は、１つまたは複数のコード化ビデオシーケンスまたは同等のものにおける一連の各ＭＣＴＳとして定義可能である。場合によっては、長方形エリアの構成にＭＣＴＳが必要となり得る。状況により、ＭＣＴＳは、画像内のタイル集合または一連の画像中の各タイル集合を表し得ることが了解されるものとする。各タイル集合は、一連の画像において同位置であってもよいが、一般的には必ずしもその必要はない。動き制約タイル集合は、その他のタイル集合なしでデコーディング可能であることから、独立コード化タイル集合と見なすことができる。
当然のことながら、相互予測に使用されるサンプルの場所は、それ以外では画像外になる位置が飽和して画像の対応する境界サンプルを指すように、飽和していてもよい。そこで、いくつかの使用事例において、タイル境界が画像境界でもある場合、動きベクトルは、その境界を効果的に横切ることができ、また、サンプルの場所が境界上で飽和するため、その境界外の場所を参照する部分サンプル補間を効果的に生じ得る。他の使用事例において具体的に、画像境界に隣り合う位置にあるビットストリームから画像境界に隣り合わない位置にある別のビットストリームへとコード化タイルが抽出され得る場合、エンコーダは、任意のＭＣＴＳ境界と同様に、画像境界上の動きベクトルを制約することができる。
画像境界のように境界が処理される長方形スライスが独立コード化画像領域の別の実現例である。画像境界のようなスライス境界の処理には、以下のうちの１つまたは複数を含んでいてもよいが、これらに限定されない。
時間的輝度動きベクトル予測の導出プロセスにおいては、基準画像のスライス境界外の動きベクトルが利用できないものと考えられる。これは、たとえばプロセスに用いられる右側および下側の画像境界位置をそれぞれ、輝度サンプルの単位で、スライスの右側および下側の境界位置により置き換えることによって実現され得る。
輝度および彩度サンプル補間プロセスにおいては、従来スライス境界外のサンプル場所にあったサンプル値がスライス境界上のサンプル場所のサンプル値により置き換えられる。これは、たとえばプロセスに用いられる左側、右側、上側、および下側の画像境界位置をそれぞれ、スライスの左側、右側、上側、および下側の境界位置により置き換えることによって実現され得る。
本明細書において後述するサブ画像が独立コード化画像領域の別の実現例であり、それぞれ、サブ画像シーケンスは、独立コード化画像領域シーケンスの一例と見なすことができる。
ＭＣＴＳ等の特定の用語を参照して例および実施形態を説明可能であるが、これらは、如何なる種類の独立コード化画像領域にも同様に当てはまることが了解される必要がある。
ＨＥＶＣの時間的動き制約タイル集合ＳＥＩ（補完拡張情報）メッセージは、ビットストリーム中の動き制約タイル集合の有無を示すのに使用可能である。
非ＶＣＬ ＮＡＬ単位は、たとえばシーケンスパラメータ集合、画像パラメータ集合、補完拡張情報（ＳＥＩ）ＮＡＬ単位、アクセス単位デリミタ、シーケンスＮＡＬ単位の終端、ビットストリームＮＡＬ単位の終端、またはフィラーデータＮＡＬ単位といった種類のうちの１つであってよい。パラメータ集合がデコード画像の再構成に必要となる場合がある一方、その他の非ＶＣＬ ＮＡＬ単位の多くは、デコードサンプル値の再構成に必要ない。
一部のコーディングフォーマットでは、デコーディングまたはデコード画像の再構成に必要なパラメータ値を有し得るパラメータ集合を規定する。コード化ビデオシーケンスによって変化しないパラメータは、シーケンスパラメータ集合（ＳＰＳ）に含まれていてもよい。デコーディングプロセスに必要となり得るパラメータのほか、シーケンスパラメータ集合には任意選択として、バッファリング、画像出力タイミング、レンダリング、およびリソース予約に重要となり得るパラメータを含むビデオユーザビリティ情報（ＶＵＩ）を含んでいてもよい。画像パラメータ集合（ＰＰＳ）には、複数のコード化画像において不変となる可能性が高いパラメータを含む。画像パラメータ集合には、１つまたは複数のコード化画像のコード化イメージセグメントが参照し得るパラメータを含んでいてもよい。ヘッダパラメータ集合（ＨＰＳ）は、画像に基づいて変化し得るパラメータを含むように提案されている。
ビデオパラメータセット（ｖｉｄｅｏ ｐａｒａｍｅｔｅｒ ｓｅｔ（ＶＰＳ））は、０個以上のコード化ビデオシーケンス全体に適用されるシンタックス要素を含むシンタックス構造として定義可能である。ＶＰＳは、ビットストリーム中のレイヤの依存関係に関する情報のほか、コード化ビデオシーケンス全体のすべてのレイヤにわたるすべてのスライスに適用可能な他の多くの情報を提供し得る。ＨＥＶＣにおいて、ＶＰＳは、基本ＶＰＳおよび拡張ＶＰＳの２つの部分を含むと考えられ、拡張ＶＰＳは、任意選択として存在していてもよい。ビデオパラメータ集合ＲＢＳＰは、１つまたは複数のシーケンスパラメータ集合ＲＢＳＰが参照し得るパラメータを含んでいてもよい。
パラメータ集合は、たとえばその識別子を通じて参照された場合にアクティブ化されるようになっていてもよい。たとえば、スライスヘッダ等のイメージセグメントのヘッダには、そのイメージセグメントを含むコード化画像のデコーディングのためにアクティブ化されるＰＰＳの識別子を含んでいてもよい。ＰＰＳには、当該ＰＰＳのアクティブ化に際してアクティブ化されるＳＰＳの識別子を含んでいてもよい。特定種類のパラメータ集合のアクティブ化によって、同じ種類のアクティブ化済みのパラメータ集合が非アクティブ化され得る。
ＶＰＳ、ＳＰＳ、およびＰＰＳ間の関係および階層は、以下のように説明可能である。ＶＰＳは、パラメータ集合階層においてＳＰＳの１レベル上に存在する。ＶＰＳは、コード化ビデオシーケンス全体のすべてのレイヤにわたるすべてのイメージセグメントに共通するパラメータを含んでいてもよい。ＳＰＳは、コード化ビデオシーケンス全体の特定のレイヤのすべてのイメージセグメントに共通で、複数のレイヤにより共有され得るパラメータを含む。ＰＰＳは、コード化画像のすべてのイメージセグメントに共通で、複数のコード化画像のすべてのイメージセグメントにより共通される可能性が高いパラメータを含む。
異なる階層レベル（たとえば、シーケンスおよび画像）のパラメータ集合の代替または追加として、ビデオコーディングフォーマットには、シーケンスヘッダまたは画像ヘッダ等のヘッダシンタックス構造を含んでいてもよい。シーケンスヘッダは、ビットストリーム順序のコード化ビデオシーケンスの他の如何なるデータにも先行し得る。画像ヘッダは、ビットストリーム順序の画像の如何なるコード化ビデオデータにも先行し得る。
ビットストリームに伴う（たとえば、ビットストリームに伴って示す）表現またはビットストリームのコード化単位に伴う（たとえば、コード化タイルに伴って示す）表現は、「帯域外」データがビットストリームまたはコード化単位とそれぞれ関連付けられる一方でこれらには含まれない様態での伝送、シグナリング、または格納を表すように、特許請求の範囲および記載の実施形態において使用され得る。ビットストリームまたはビットストリームのコード化単位または同等のものに伴うデコーディングという表現は、ビットストリームまたはコード化単位とそれぞれ関連付けられた参照帯域外データ（帯域外伝送、シグナリング、または格納から得られ得る）のデコーディングを表し得る。たとえば、ビットストリームがＩＳＯベースメディアファイルフォーマットに準拠したファイル等のコンテナファイルに含まれ、ビットストリームを含むトラックのサンプルエントリのボックス、ビットストリームを含むトラックのサンプル群、またはビットストリームを含むトラックと関連付けられた時限メタデータトラック等のメタデータをビットストリームに関連付ける様態で特定のファイルメタデータがファイルに格納されている場合に、ビットストリームに伴う表現を使用可能である。
コード化画像は、画像のコード化表現である。
内部ランダムアクセスポイント（ｉｎｔｒａ ｒａｎｄｏｍ ａｃｃｅｓｓ ｐｏｉｎｔ，ＩＲＡＰ）画像とも称し得るランダムアクセスポイント（ＲＡＰ）画像は、内部コード化イメージセグメントのみを含んでいてもよい。さらに、ＲＡＰ画像は、デコーディング順序のＲＡＰ画像に先行する任意の画像のデコーディングプロセスの実行なく正確にデコーディング可能となるように、出力順序の後続画像を制約するようにしてもよい。
アクセス単位には、単一の時間インスタンスのコード化ビデオデータおよび関連する他のデータを含んでいてもよい。ＨＥＶＣにおいて、アクセス単位（ａｃｃｅｓｓ ｕｎｉｔ（ＡＵ））は、規定の分類規則に従って互いに関連付けられ、デコーディング順序が連続し、ｎｕｈ＿ｌａｙｅｒ＿ｉｄの任意特定の値を有する最大１つの画像を含む一組のＮＡＬ単位として定義可能である。コード化画像のＶＣＬ ＮＡＬ単位を含むほか、アクセス単位には、非ＶＣＬ ＮＡＬ単位も含み得る。前記特定の分類規則では、たとえば出力タイミングまたは画像出力カウント値が同じ画像を同じアクセス単位に関連付けるようにしてもよい。
アクセス単位内で、コード化画像が特定の順序で出現する必要があり得る。たとえば、ｎｕｈ＿ｌａｙｅｒ＿ｉｄがｎｕｈＬａｙｅｒＩｄＡに等しいコード化画像は、デコーディング順序にて、同じアクセス単位でｎｕｈ＿ｌａｙｅｒ＿ｉｄがｎｕｈＬａｙｅｒＩｄＡより大きなすべてのコード化画像に先行することが要求となり得る。
ビットストリーム（ｂｉｔｓｔｒｅａｍ）は、一連のビットとして定義可能であり、いくつかのコーディングフォーマットまたは規格においては、ＮＡＬ単位ストリームまたはバイトストリームの形態であってもよく、１つまたは複数のコード化ビデオシーケンスを構成するコード化画像および関連するデータの表現を構成する。同じファイルや通信プロトコルの同じ接続等、同じ論理チャネル内で第１のビットストリームに第２のビットストリームが続いていてもよい。（ビデオコーディングの状況における）基本ストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）は、一連の１つまたは複数のビットストリームとして定義可能である。いくつかのコーディングフォーマットまたは規格において、最初のビットストリームの終端は、特定のＮＡＬ単位により示されていてもよく、これは、ビットストリーム終端（ＥＯＢ）ＮＡＬ単位と称し得るものであり、ビットストリームの最後のＮＡＬ単位である。
コード化ビデオシーケンス（ｃｏｄｅｄ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅ（ＣＶＳ））は、独立デコーディング可能かつ別のコード化ビデオシーケンスまたはビットストリームの終端が後続するデコーディング順序の一連のコード化画像として定義可能である。この追加または代替として、コード化ビデオシーケンスは、シーケンス終端（ＥＯＳ）ＮＡＬ単位と称し得る特定のＮＡＬ単位がビットストリームに現れた場合に終端するように規定可能である。ＨＥＶＣにおいて、ｎｕｈ＿ｌａｙｅｒ＿ｉｄが０に等しいＥＯＳ ＮＡＬ単位は、コード化ビデオシーケンスを終端させる。
ビットストリームまたはコード化ビデオシーケンスは、以下のような時間的スケーラブルとなるようにエンコーディング可能である。各画像は、特定の時間的サブレイヤに割り当てられていてもよい。時間的サブレイヤは、たとえば０から数え上げることができる。最低の時間的サブレイヤであるサブレイヤ０は、独立してデコーディングされるようになっていてもよい。時間的サブレイヤ１における画像は、時間的サブレイヤ０および１における再構成画像から予測されるようになっていてもよい。時間的サブレイヤ２における画像は、時間的サブレイヤ０、１および２における再構成画像から予測されるようになっていてもよく、以下同様である。言い換えると、時間的サブレイヤＮにおける画像は、相互予測の基準として、Ｎより大きな時間的サブレイヤにおける如何なる画像も使用しない。選択サブレイヤ値以上のすべての画像を除外し、画像を含むことにより生成されたビットストリームは、適合性を維持する。
サブレイヤアクセス画像（ｓｕｂ－ｌａｙｅｒ ａｃｃｅｓｓ ｐｉｃｔｕｒｅ）は、サブレイヤのデコーディングを正しく開始可能な画像、すなわち、サブレイヤのすべての画像を正しくデコーディング可能な画像として定義可能である。ＨＥＶＣにおいては、時間的サブレイヤの切り替えポイントを示すのに使用可能な２つの画像タイプ、すなわち、時間的サブレイヤアクセス（ＴＳＡ）およびステップ単位時間的サブレイヤアクセス（ＳＴＳＡ）の画像タイプが存在する。ＴＳＡもしくはＳＴＳＡ画像（除外）ならびにＴＳＡもしくはＳＴＳＡ画像のＴｅｍｐｏｒａｌＩｄがＮ＋１に等しくなるまでにＴｅｍｐｏｒａｌＩｄが最大Ｎの時間的サブレイヤがデコードされていた場合、ＴＳＡまたはＳＴＳＡ画像は、ＴｅｍｐｏｒａｌＩｄがＮ＋１に等しくなった以降のすべての画像（デコーディング順序）のデコーディングを可能にする。ＴＳＡ画像タイプは、ＴＳＡ画像自体およびデコーディング順序のＴＳＡ画像に後続する同じサブレイヤ中のすべての画像に制約を課すようにしてもよい。これらの画像はいずれも、デコーディング順序のＴＳＡ画像に先行する同じサブレイヤ中の任意の画像からの相互予測を使用できない。ＴＳＡの定義では、デコーディング順序のＴＳＡ画像に後続する上位サブレイヤ中の画像に対して、制約をさらに課すようにしてもよい。これらの画像はいずれも、デコーディング順序のＴＳＡ画像に先行する画像がＴＳＡ画像と同じサブレイヤまたは上位のサブレイヤに属する場合、当該画像を参照できない。ＴＳＡ画像のＴｅｍｐｏｒａｌＩｄは、０より大きい。ＳＴＳＡはＴＳＡ画像に類似するものの、デコーディング順序のＳＴＳＡ画像に後続する上位サブレイヤ中の画像には制約を課さないため、ＳＴＳＡ画像が存在するサブレイヤにのみアップスイッチングを可能とする。
シンタックス要素のパーシングプロセスの規定には、以下が用いられるようになっていてもよい。
ｕ（ｎ）：ｎ個のビットを使用する符号なし整数。シンタックステーブルにおいてｎが「ｖ」の場合、ビット数は、他のシンタックス要素の値に応じて変化する。この記述子のパーシングプロセスは、符号なし整数のバイナリ表現として解釈されるビットストリームの次のｎビットにより規定され、最上位ビットが最初に書き込まれる。
ｕｅ（ｖ）：符号なし整数の指数ゴロムコーディング（ｅｘｐ－ゴロムコーディングとしても知られる）シンタックス要素であって、左側のビットが最初に書き込まれる。
指数ゴロムビット列は、たとえば以下の表によって、コード番号（ｃｏｄｅＮｕｍ）に変換され得る。
Figure 0007492978000005
利用可能なメディアファイルフォーマット規格としては、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６－１２、ＩＳＯＢＭＦＦと略記可能）、ＭＰＥＧ－４ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６－１４、ＭＰ４フォーマットとしても知られる）、ＮＡＬ単位構造化ビデオ用ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６－１５）、および３ＧＰＰファイルフォーマット（３ＧＰＰ ＴＳ ２６．２４４、３ＧＰフォーマットとしても知られる）が挙げられる。ＩＳＯファイルフォーマットは、前述のすべてのファイルフォーマットの導出基準である（ＩＳＯファイルフォーマット自体を除く）。これらのファイルフォーマット（ＩＳＯファイルフォーマット自体を含む）は一般的に、ファイルフォーマットのＩＳＯファミリと称する。
以下、実施形態が実現され得る基礎となるコンテナファイルフォーマットの一例として、ＩＳＯＢＭＦＦのいくつかの概念、構造、および仕様を説明する。本発明の態様は、ＩＳＯＢＭＦＦに限定されず、説明はむしろ、本発明の一部または全部を実現可能な１つの考え得る基礎に関して与える。
ＩＳＯベースメディアファイルフォーマットにおける基本的な構成ブロックをボックスと称する。各ボックスは、ヘッダおよびペイロードを有する。ボックスヘッダは、ボックスの種類と、バイト単位のボックスのサイズと、を示す。ボックスは他のボックスを包含していてもよく、ＩＳＯファイルフォーマットでは、特定タイプのボックスに許容されるボックスの種類を規定する。さらに、各ファイルにおいては、いくつかのボックスの存在が必須であり、他のボックスの存在は任意であってもよい。また、一部のボックスタイプについて、ファイルに２つ以上のボックスが存在することも許容され得る。このため、ＩＳＯベースメディアファイルフォーマットは、ボックスの階層構造を規定するものと考えられる。
ファイルフォーマットのＩＳＯファミリによれば、ファイルには、ボックスとしてカプセル化されたメディアデータおよびメタデータを含む。各ボックスは、４文字コード（４ＣＣ）により識別され、ボックスの種類およびサイズを知らせるヘッダから始まる。
ＩＳＯベースメディアファイルフォーマットに準拠したファイルにおいては、メディアデータがメディアデータ「ｍｄａｔ」ボックスで提供されてもよく、ムービー「ｍｏｏｖ」ボックスがメタデータの包含に使用されていてもよい。場合によっては、ファイルを操作可能となるように、「ｍｄａｔ」および「ｍｏｏｖ」の両ボックスの存在が必要となり得る。ムービー「ｍｏｏｖ」ボックスには１つまたは複数のトラックを含んでいてもよく、各トラックは、１つの対応するＴｒａｃｋＢｏｘ（「ｔｒａｋ」）に存在していてもよい。トラックは、メディア圧縮フォーマット（および、ＩＳＯベースメディアファイルフォーマットへのカプセル化）に従ってフォーマットされたサンプルを表すメディアトラック等、多くの種類のうちの１つであってもよい。トラックは、論理チャネルと見なすことができる。
ムービー断片は、たとえばＩＳＯファイルにコンテンツを記録する際、記録アプリケーションがクラッシュしたり、メモリ空間が不足したり、他の何らかの出来事が発生したりした場合にデータを失わないようにするために使用可能である。ムービー断片がなければ、ファイルフォーマットとして、すべてのメタデータ、たとえば、ムービーボックスをファイルの連続した１つのエリアに書き込むことが必要となり得るため、データ損失の発生の可能性がある。さらに、ファイルを記録する際、利用可能なストレージのサイズに対してムービーボックスをバッファリングするのに十分な量のメモリ空間（たとえば、ランダムアクセスメモリＲＡＭ）が存在しない場合もあり、ムービーを閉じる際のムービーボックスのコンテンツの再計算があまりにも遅くなる可能性がある。さらに、ムービー断片によれば、通常のＩＳＯファイルパーサーを用いたファイルの同時記録・再生が可能となり得る。さらには、プログレッシブダウンロード、たとえば、ムービー断片が使用され、ムービー断片を使用しない構造の同じメディアコンテンツを含むファイルと比較して初期ムービーボックスが小さい場合のファイルの同時受信・再生のため、初期バッファリングの継続時間をより短くすることが必要となり得る。
ムービー断片機能によって、ムービーボックス中に存在し得るメタデータを複数に分割可能となり得る。各メタデータは、トラックの特定の期間に対応していてもよい。言い換えると、ムービー断片機能によって、ファイルメタデータおよびメディアデータの交互配置が可能となり得る。その結果、ムービーボックスのサイズが制限され、前述の使用事例が実現され得る。
いくつかの例において、ムービー断片のメディアサンプルは、ｍｏｏｖボックスと同じファイルである場合、ｍｄａｔボックスに存在していてもよい。ただし、ムービー断片のメタデータについては、ｍｏｏｆボックスが提供されるようになっていてもよい。ｍｏｏｆボックスには、ｍｏｏｖボックスに存在していた特定の再生継続時間の情報を含んでいてもよい。ｍｏｏｖボックスは依然として、それ自体で有効なムービーを表し得るが、その追加として、ムービー断片が同じファイルで続くことを示すｍｖｅｘボックスを含んでいてもよい。ムービー断片は、ｍｏｏｖボックスに関連付けられたプレゼンテーションを時間的に延長するようにしてもよい。
ムービー断片内には、どこでも１トラック当たり０～複数個の一組のトラック断片が存在していてもよい。このトラック断片には、どこでも０～複数個のトラックラン（トラック断片ランとしても知られる）を含んでいてもよく、それぞれ、当該トラックのサンプルの連続したランである。これらの構造内においては、多くのフィールドが任意選択であり、デフォルトに設定可能である。ｍｏｏｆボックスに含まれ得るメタデータは、ｍｏｏｖボックスに含まれ得るメタデータの部分集合に限定されてもよく、場合によっては異なるコーディングがなされる可能性もある。ｍｏｏｆボックスに含まれ得るボックスに関する詳細は、ＩＳＯベースメディアファイルフォーマット仕様に記載されている。自己完結型のムービー断片は、ファイル順序で連続するｍｏｏｆボックスおよびｍｄａｔボックスから成るように規定可能であり、ｍｄａｔボックスには、（ｍｏｏｆボックスがメタデータを提供する）ムービー断片のサンプルを含む一方、その他任意のムービー断片（すなわち、その他任意のｍｏｏｆボックス）のサンプルは含まない。
トラック基準メカニズムの使用により、トラックを互いに関連付けることができる。ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘには、それぞれが包含トラックから一組の他のトラックに基準を与えるボックスを含む。これらの基準は、包含ボックスのボックスタイプ（すなわち、ボックスの４文字コード）によってラベリングされている。
ＴｒａｃｋＢｏｘに含まれるＴｒａｃｋＧｒｏｕｐＢｏｘによれば、各群が特定の特性を共有していたり、群内のトラックが特定の関係を有していたりするトラック群を示すことができる。ボックスには０個以上のボックスを含み、特定の特性または関係は、包含ボックスのボックスタイプによって示される。包含ボックスは、同じトラック群に属するトラックの決定に使用可能な識別子を含む。ＴｒａｃｋＧｒｏｕｐＢｏｘ内に同じ種類の包含ボックスを含み、これら包含ボックス内で同じ識別子番号を有するトラックは、同じトラック群に属する。
統一リソース識別子（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ））は、リソースの名称の識別に用いられる文字列として定義可能である。このような識別によれば、特定のプロトコルを用いることにより、ネットワークを介したリソースの表現との相互作用が可能となる。ＵＲＩは、当該ＵＲＩの具象シンタックスおよび関連するプロトコルを規定する方式によって定義される。統一リソース位置指定子（ＵＲＬ）および統一リソース名（ＵＲＮ）は、ＵＲＩの形態である。ＵＲＬは、ウェブリソースを識別するとともに、リソースの表現に対する作用または表現の取得を行う手段を指定するＵＲＩとして定義可能であり、その主要なアクセスメカニズムおよびネットワークの場所の両方を指定する。ＵＲＮは、特定の名称空間においてリソースを名称により識別するＵＲＩとして定義可能である。ＵＲＮは、その場所もアクセス方法も暗示することなく、リソースの識別に用いられるようになっていてもよい。
近年、動画ストリーミングアプリケーション等、インターネット上でリアルタイムにマルチメディアコンテンツを配信するため、ハイパーテキスト転送プロトコル（ＨＴＴＰ）が広く使用されている。ユーザデータグラムプロトコル（ＵＤＰ）上のリアルタイム転送プロトコル（ＲＴＰ）の使用と異なり、ＨＴＴＰは、設定が簡単で、通常はファイアウォールおよびネットワークアドレス変換器（ＮＡＴ）を通過することが認められており、マルチメディアストリーミングアプリケーションにとって魅力的なものとなっている。
Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、Ａｐｐｌｅ（登録商標）Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ、およびＡｄｏｂｅ（登録商標）Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ等、ＨＴＴＰ上の適応ストリーミングの商用ソリューションがいくつか発表されているほか、標準化プロジェクトも進められている。適応ＨＴＴＰストリーミング（ＡＨＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）のパケットスイッチングストリーミング（ＰＳＳ）サービスのＲｅｌｅａｓｅ ９（３ＧＰＰ ＴＳ ２６．２３４ Ｒｅｌｅａｓｅ ９："Transparent end-to-end packet-switched streaming service (PSS); protocol and codec"）で初めて標準化されたものである。ＭＰＥＧは、ＭＰＥＧ ＤＡＳＨ規格（ＩＳＯ／ＩＥＣ ２３００９－１："Dynamic adaptive streaming over HTTP (DASH)-Part 1: Media presentation description and segment formats", International Standard, 2nd Edition, , 2014）の起点として、３ＧＰＰ ＡＨＳ Ｒｅｌｅａｓｅ ９を採用している。３ＧＰＰは、ＭＰＥＧとの通信において適応ＨＴＴＰストリーミングを研究し続け、３ＧＰ－ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ；３ＧＰＰ ＴＳ ２６．２４７："Transparent end-to-end packet-switched streaming Service (PSS; Progressive download and dynamic adaptive Streaming over HTTP (3GP-DASH))"）を発表した。ＭＰＥＧ ＤＡＳＨおよび３ＧＰ－ＤＡＳＨは技術的に近いため、ＤＡＳＨと総称し得る。以下、実施形態を実現可能なビデオストリーミングシステムの一例として、ＤＡＳＨのいくつかの概念、フォーマット、および動作を説明する。本発明の態様は、ＤＡＳＨに限定されず、説明はむしろ、本発明の一部または全部を実現可能な１つの考え得る基礎に関して与える。
ＤＡＳＨにおいては、マルチメディアコンテンツがＨＴＴＰサーバに格納されてもよく、ＨＴＴＰにより配信され得る。コンテンツは、メディアプレゼンテーション記述（ＭＰＤ）（利用可能なコンテンツのマニフェスト、そのさまざまな選択肢、それらのＵＲＬアドレス、および他の特性を記述）およびセグメント（実際のマルチメディアビットストリームをチャンクの形態で単一のファイルまたは複数のファイルに含む）、という２つの部分に分けてサーバに格納可能である。ＭＤＰは、クライアントがＨＴＴＰ上で動的適応ストリーミングを構築する際に必要な情報を提供する。ＭＰＤは、各ＳｅｇｍｅｎｔのＨＴＴＰ統一リソース位置指定子（ＵＲＬ）等のメディアプレゼンテーションを記述した情報を含むことにより、ＧＥＴ Ｓｅｇｍｅｎｔリクエストを行う。コンテンツを再生するため、ＤＡＳＨクライアントは、たとえばＨＴＴＰ、電子メール、サムドライブ、ブロードキャスト、または他の転送方法を使用して、ＭＰＤを取得するようにしてもよい。ＭＰＤのパーシングによって、ＤＡＳＨクライアントは、プログラムのタイミング、メディアコンテンツの可用性、メディアの種類、解像度、最小および最大帯域幅、マルチメディアコンポーネントのさまざまなエンコーディング選択肢の存在、アクセシビリティ特性および必要なデジタル権利管理（ＤＲＭ）、ネットワーク上のメディアコンテンツの場所、ならびに他のコンテンツ特性を認識することができる。この情報を用いることにより、ＤＡＳＨクライアントは、適当なエンコーディング選択肢を選択し、たとえばＨＴＴＰ ＧＥＴリクエストを使用してセグメントを取り出すことによりコンテンツのストリーミングを開始することができる。ネットワークのスループット変化を可能にする適当なバッファリングの後、クライアントは、後続のセグメントの取り出しを継続するとともに、ネットワーク帯域幅の変動を監視することもできる。クライアントは、適切なバッファを維持するため、さまざまな選択肢のセグメントを（低ビットレートまたは高ビットレートで）取り出すことにより、利用可能な帯域幅への適用方法を決定するようにしてもよい。
ＤＡＳＨにおいては、階層データモデルの使用によって、以下のようにメディアプレゼンテーションを構造化する。メディアプレゼンテーションは、一連の１つまたは複数のＰｅｒｉｏｄから成り、各Ｐｅｒｉｏｄは、１つまたは複数のＧｒｏｕｐを含み、各Ｇｒｏｕｐは、１つまたは複数のＡｄａｐｔａｔｉｏｎ Ｓｅｔを含み、各Ａｄａｐｔａｔｉｏｎ Ｓｅｔは、１つまたは複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎを含み、各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、１つまたは複数のＳｅｇｍｅｎｔから成る。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、メディアコンテンツの選定のうちの１つまたはその部分集合であり、通常、たとえばビットレート、解像度、言語、コーデック等、エンコーディングの選定によって異なる。Ｓｅｇｍｅｎｔは、特定の持続時間のメディアデータと、包含メディアコンテンツをデコーディングして表示するメタデータと、を含む。Ｓｅｇｍｅｎｔは、ＵＲＩにより識別され、通常はＨＴＴＰ ＧＥＴリクエストにより要求可能である。Ｓｅｇｍｅｎｔは、ＭＰＤにより規定されたＨＴＴＰ－ＵＲＬおよび任意選択としてのバイト範囲と関連付けられたデータの単位として定義可能である。
ＤＡＳＨ ＭＰＤは、拡張マークアップ言語（ＸＭＬ）に準拠するため、ＸＭＬに規定の要素および属性によって規定される。
ＤＡＳＨにおいては、すべての記述子要素が同じ方法で構造化されている。すなわち、スキームを識別するＵＲＩを提供する＠ｓｃｈｅｍｅＩｄＵｒｉ属性と、任意選択的な属性＠ｖａｌｕｅおよび任意選択的な属性＠ｉｄと、を含む。要素のセマンティクスは、採用する方式に固有である。方式を識別するＵＲＩは、ＵＲＮであってもよいし、ＵＲＬであってもよい。
ＤＡＳＨにおいて、Ｉｎｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、その他任意の表現から独立して処理し得る表現として定義可能である。Ｉｎｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、独立したビットストリームまたはビットストリームの独立したレイヤを含むものと理解され得る。Ｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、そのＣｏｍｐｌｅｍｅｎｔａｒｙ ＲｅｐｒｅｓｅｎｔａｔｉｏｎからのＳｅｇｍｅｎｔが包含メディアコンテンツコンポーネントのプレゼンテーションおよび／またはデコーディングに必要となる表現として定義可能である。Ｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、たとえばスケーラブルビットストリームの予測レイヤを含むものと理解され得る。Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、少なくとも１つのＤｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを補完する表現として定義可能である。Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、Ｉｎｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎであってもよいし、Ｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎであってもよい。Ｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、＠ｄｅｐｅｎｄｅｎｃｙＩｄ属性を含むＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素により記述可能である。Ｄｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、デコーディングおよび／またはプレゼンテーションのために一組のＣｏｍｐｌｅｍｅｎｔａｒｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに依存することを除けば、通常のＲｅｐｒｅｓｅｎｔａｔｉｏｎと見なすことができる。＠ｄｅｐｅｎｄｅｎｃｙＩｄは、すべてのＣｏｍｐｌｅｍｅｎｔａｒｙ ＲｅｐｒｅｓｅｎｔａｔｉｏｎすなわちこのＤｅｐｅｎｄｅｎｔ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに含まれるメディアコンテンツコンポーネントのプレゼンテーションおよび／またはデコーディングに必要なＲｅｐｒｅｓｅｎｔａｔｉｏｎの＠ｉｄ属性の値を含む。
ＩＳＯＢＭＦＦのトラック基準は、＠ａｓｓｏｃｉａｔｉｏｎＩｄに１対１で与えられたＲｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ値のリストにマッピングされたＤＡＳＨ ＭＰＤの＠ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ属性における４文字コードのリストにおいて反映され得る。これらの属性は、メディアＲｅｐｒｅｓｅｎｔａｔｉｏｎのメタデータＲｅｐｒｅｓｅｎｔａｔｉｏｎとのリンクに用いられるようになっていてもよい。
ＤＡＳＨサービスは、オンデマンドサービスまたはライブサービスとして提供されるようになっていてもよい。前者においては、ＭＰＤが静的で、コンテンツ提供者がＭＰＤを発行した時点でメディアプレゼンテーションのすべてのＳｅｇｍｅｎｔが既に利用可能である。ただし、後者においては、ＭＰＤが採用するＳｅｇｍｅｎｔ ＵＲＬ構成方法に応じて、ＭＰＤが静的であってもよいし、動的であってもよく、コンテンツ提供者によってコンテンツが生成され、ＤＡＳＨクライアントに対して発行される際に、Ｓｅｇｍｅｎｔが連続的に生成される。Ｓｅｇｍｅｎｔ ＵＲＬ構成方法は、テンプレートベースのＳｅｇｍｅｎｔ ＵＲＬ構成方法であってもよいし、Ｓｅｇｍｅｎｔリスト生成方法であってもよい。前者においては、Ｓｅｇｍｅｎｔを要求する前にＭＰＤを更新することなく、ＤＡＳＨクライアントがＳｅｇｍｅｎｔ ＵＲＬを構成可能である。後者においては、ＤＡＳＨクライアントが更新されたＭＰＤを定期的にダウンロードして、Ｓｅｇｍｅｎｔ ＵＲＬを取得する必要がある。このため、ライブサービスの場合は、テンプレートベースのＳｅｇｍｅｎｔ ＵＲＬ構成方法がＳｅｇｍｅｎｔリスト生成方法よりも優れている。
Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔは、Ｍｅｄｉａ Ｓｅｇｍｅｎｔにカプセル化されたメディアストリームのプレゼンテーションに必要なメタデータを含むＳｅｇｍｅｎｔとして定義可能である。ＩＳＯＢＭＦＦベースのセグメントフォーマットにおいて、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔは、ＭｏｖｉｅＢｏｘ（「ｍｏｏｖ」）を含むが、これは、サンプルのメタデータを一切含まない場合もある。すなわち、サンプルの如何なるメタデータも、「ｍｏｏｆ」ボックスにおいて提供される。
Ｍｅｄｉａ Ｓｅｇｍｅｎｔは、通常の速度で再生するための特定の持続時間のメディアデータを含むが、このような持続時間をＭｅｄｉａ Ｓｅｇｍｅｎｔ持続時間またはＳｅｇｍｅｎｔ持続時間と称する。コンテンツ製作者またはサービス提供者は、サービスの所望の特性に応じて、Ｓｅｇｍｅｎｔ持続時間を選択するようにしてもよい。たとえば、ライブサービスにおいては、比較的短いＳｅｇｍｅｎｔ持続時間の使用により、エンドツーエンドのレイテンシを短縮することを実現するようにしてもよい。その理由として、ＳｅｇｍｅｎｔがＤＡＳＨのメディアデータを生成する個別の単位であるため、Ｓｅｇｍｅｎｔ持続時間は通常、ＤＡＳＨクライアントが知覚するエンドツーエンドのレイテンシの下限となる。コンテンツの生成は通常、メディアデータのＳｅｇｍｅｎｔ全体をサーバで利用可能にするような方法で行われる。さらに、多くのクライアント実装では、ＧＥＴリクエストの単位としてＳｅｇｍｅｎｔを使用する。したがって、ライブサービスの典型的な構成では、Ｍｅｄｉａ Ｓｅｇｍｅｎｔの持続時間全体が利用可能であるほか、Ｓｅｇｍｅｎｔにエンコーディングおよびカプセル化されている場合のみ、ＤＡＳＨクライアントがＳｅｇｍｅｎｔを要求可能である。オンデマンドサービスの場合は、Ｓｅｇｍｅｎｔ持続時間を選択する異なる方法が用いられるようになっていてもよい。
Ｓｅｇｍｅｎｔは、たとえば複数の部分でセグメントをダウンロードできるように、Ｓｕｂｓｅｇｍｅｎｔへとさらに分離されるようになっていてもよい。Ｓｕｂｓｅｇｍｅｎｔは、完全なアクセス単位を含むことが必要となる場合もある。Ｓｕｂｓｅｇｍｅｎｔは、各Ｓｕｂｓｅｇｍｅｎｔのプレゼンテーション時間範囲およびバイト範囲をマッピングするための情報を含むＳｅｇｍｅｎｔ Ｉｎｄｅｘボックス（ＳｅｇｍｅｎｔＩｎｄｅｘＢｏｘとしても知られる）によってインデックス化されていてもよい。また、Ｓｅｇｍｅｎｔ Ｉｎｄｅｘボックスは、持続時間およびバイトオフセットを示すことにより、セグメント中のサブセグメントおよびストリームアクセスポイントを記述するようにしてもよい。ＤＡＳＨクライアントは、Ｓｅｇｍｅｎｔ Ｉｎｄｅｘボックスから得られた情報を使用することにより、バイト範囲ＨＴＴＰリクエストを用いて特定のＳｕｂｓｅｇｍｅｎｔに対するＨＴＴＰ ＧＥＴリクエストを行うようにしてもよい。比較的長いＳｅｇｍｅｎｔ持続時間が用いられる場合は、Ｓｕｂｓｅｇｍｅｎｔの使用により、ビットレート適応に対してＨＴＴＰ応答のサイズを合理的かつ柔軟に保つようにしてもよい。セグメントのインデックス化情報は、当該セグメントの先頭にある単一のボックスに挿入されていてもよいし、セグメント中の多くのインデックス化ボックスに拡散していてもよい。階層、デイジーチェーン、ハイブリッド等のさまざまな拡散方法が可能である。この技術では、セグメントの先頭に大きなボックスを追加することを避け得る結果、初期ダウンロード遅延の可能性を抑えられ得る。
（Ｓｕｂ）ｓｅｇｍｅｎｔという表記は、ＳｅｇｍｅｎｔまたはＳｕｂｓｅｇｍｅｎｔを表す。Ｓｅｇｍｅｎｔ Ｉｎｄｅｘボックスが存在しない場合、（Ｓｕｂ）ｓｅｇｍｅｎｔという表記は、Ｓｅｇｍｅｎｔを表す。Ｓｅｇｍｅｎｔ Ｉｎｄｅｘボックスが存在する場合、（Ｓｕｂ）ｓｅｇｍｅｎｔという表記は、たとえばクライアントがＳｅｇｍｅｎｔに基づいてリクエストを発行するかＳｕｂｓｅｇｍｅｎｔに基づいてリクエストを発行するかに応じて、ＳｅｇｍｅｎｔまたはＳｕｂｓｅｇｍｅｎｔを表し得る。
ＭＰＥＧ－ＤＡＳＨは、ＩＳＯベースメディアファイルフォーマットおよびＭＰＥＧ－２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍの両者のセグメントコンテナフォーマットを定義する。他の仕様が他のコンテナフォーマットに基づいてセグメントフォーマットを規定していてもよい。たとえば、Ｍａｔｒｏｓｋａコンテナファイルフォーマットに基づくセグメントフォーマットが提案されている。
ＤＡＳＨは、変化するネットワーク帯域幅に合わせて、Ａｄａｐｔａｔｉｏｎ Ｓｅｔ内の異なるＲｅｐｒｅｓｅｎｔａｔｉｏｎから動的にＭｅｄｉａ Ｓｅｇｍｅｎｔを要求することによって、レート適応をサポートする。ＤＡＳＨクライアントがＲｅｐｒｅｓｅｎｔａｔｉｏｎを切り替えた場合は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ内のコーディング依存性を考慮する必要がある。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ切り替えは、Ｈ．２６４／ＡＶＣ等のビデオコーディング技術で一般的に使用されるランダムアクセスポイント（ＲＡＰ）で発生する場合がある。ＤＡＳＨにおいては、Ｓｔｒｅａｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ（ＳＡＰ）と称するより一般的な概念の導入によって、ＲｅｐｒｅｓｅｎｔａｔｉｏｎへのアクセスおよびＲｅｐｒｅｓｅｎｔａｔｉｏｎ間の切り替えのためのコーデックに依存しないソリューションを提供する。ＤＡＳＨにおいては、ＳＡＰがＲｅｐｒｅｓｅｎｔａｔｉｏｎ中の位置として規定され、その位置から始まるＲｅｐｒｅｓｅｎｔａｔｉｏｎデータに含まれる情報のみを用いてメディアストリームの再生を開始することができる（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ中のデータ（存在する場合）に先立って行われる）。このため、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの切り替えは、ＳＡＰにおいて実行可能である。
ＤＡＳＨにおいては、幅および高さ（＠ｗｉｄｔｈおよび＠ｈｅｉｇｈｔ）、フレームレート（＠ｆｒａｍｅＲａｔｅ）、ビットレート（＠ｂａｎｄｗｉｄｔｈ）、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ間の指示された品質順序（＠ｑｕａｌｉｔｙＲａｎｋｉｎｇ）に基づいて、同じＡｄａｐｔａｔｉｏｎ Ｓｅｔ中のＲｅｐｒｅｓｅｎｔａｔｉｏｎ間の自動選択が実行されている。＠ｑｕａｌｉｔｙＲａｎｋｉｎｇのセマンティクスは、同じＡｄａｐｔａｔｉｏｎ Ｓｅｔ中の他のＲｅｐｒｅｓｅｎｔａｔｉｏｎに対するＲｅｐｒｅｓｅｎｔａｔｉｏｎの品質ランキングを指定するように規定されている。低い値がより高品質のコンテンツを表す。存在しない場合は、ランキングが規定されない。
以下のような複数種類のＳＡＰが規定されている。ＳＡＰタイプ１は、いくつかのコーディング方式で「Ｃｌｏｓｅｄ ＧＯＰランダムアクセスポイント」として知られるものに対応し（デコーディング順序のすべての画像を正しくデコーディング可能であり、ギャップなく正しくデコーディングされた画像の連続した時間シーケンスとなる）、さらに、デコーディング順序の最初の画像は、プレゼンテーション順序の最初の画像でもある。ＳＡＰタイプ２は、いくつかのコーディング方式で「Ｃｌｏｓｅｄ ＧＯＰランダムアクセスポイント」として知られるものに対応し（デコーディング順序のすべての画像を正しくデコーディング可能であり、ギャップなく正しくデコーディングされた画像の連続した時間シーケンスとなる）、デコーディング順序の最初の画像は、プレゼンテーション順序の最初の画像ではない場合がある。ＳＡＰタイプ３は、いくつかのコーディング方式で「Ｏｐｅｎ ＧＯＰランダムアクセスポイント」として知られているものに対応し、デコーディング順序の画像の一部は、正しくデコーディングできず、ＳＡＰと関連付けられた内部コード化画像よりもプレゼンテーション時間が短い場合もある。
ＭＰＥＧ－２等の一部のビデオコーディング規格において、各内部画像は、コード化シーケンスにおけるランダムアクセスポイントである。Ｈ．２６４／ＡＶＣおよびＨ．２６５／ＨＥＶＣ等の一部ビデオコーディング規格においては、相互予測のために複数の基準画像を柔軟に使用する機能の結果として、内部画像ではランダムアクセスに不十分な場合がある。したがって、コーディングタイプからそのような機能を推測するのではなく、ランダムアクセスポイントの機能に関して画像がマーキングされ得る。たとえば、Ｈ．２６４／ＡＶＣ規格において規定されるＩＤＲ画像をランダムアクセスポイントとして使用可能である。Ｃｌｏｓｅｄ ＧＯＰは、すべての画像を正しくデコーディング可能な画像群である。たとえば、Ｈ．２６４／ＡＶＣにおいては、Ｃｌｏｓｅｄ ＧＯＰがＩＤＲアクセス単位を起点としていてもよい。
Ｏｐｅｎ ＧＯＰは、出力順序の最初の内部画像に先行する画像を正しくデコーディングできない可能性があるものの、出力順順序の最初の内部画像に後続する画像は正しくデコーディング可能である画像群である。このような最初の内部画像は、たとえばＨＥＶＣのＣＲＡ ＮＡＬ単位型を使用することにより、ビットストリームにおける指定および／またはビットストリームからの指定による決定がなされていてもよい。Ｏｐｅｎ ＧＯＰを開始する最初の内部画像に出力順序で先行し、最初の内部画像にデコーディング順序で後続する画像は、先行画像と称し得る。先行画像には、デコーディング可能およびデコーディング不可能の２種類が存在する。ＨＥＶＣのＲＡＤＬ画像のようにデコーディング可能な先行画像は、Ｏｐｅｎ ＧＯＰを開始する最初の内部画像をデコーディングの起点とする場合に正しくデコーディング可能なものである。言い換えると、デコーディング可能な先行画像は、相互予測における基準として、デコーディング順序の最初の内部画像またはその後続の画像のみを使用する。ＨＥＶＣのＲＡＳＬ画像のようにデコーディング不可能な先行画像は、Ｏｐｅｎ ＧＯＰを開始する最初の内部画像をデコーディングの起点とする場合に正しくデコーディングできないものである。
ＤＡＳＨ Ｐｒｅｓｅｌｅｃｔｉｏｎは、単一のデコーダインスタンスによる一体的な消費が予想されるＭＰＤのメディアコンポーネントの部分集合を規定するが、この消費には、デコーディングおよびレンダリングを含んでいてもよい。Ｐｒｅｓｅｌｅｃｔｉｏｎの主要なメディアコンポーネントを含むＡｄａｐｔａｔｉｏｎ Ｓｅｔは、主Ａｄａｐｔａｔｉｏｎ Ｓｅｔと称する。また、各Ｐｒｅｓｅｌｅｃｔｉｏｎは、１つまたは複数の部分的Ａｄａｐｔａｔｉｏｎ Ｓｅｔを含んでいてもよい。部分的Ａｄａｐｔａｔｉｏｎ Ｓｅｔは、主Ａｄａｐｔａｔｉｏｎ Ｓｅｔと組み合わせて処理することが必要となり得る。主Ａｄａｐｔａｔｉｏｎ Ｓｅｔおよび部分的Ａｄａｐｔａｔｉｏｎ Ｓｅｔは、Ｐｒｅｓｅｌｅｃｔｉｏｎ記述子およびＰｒｅｓｅｌｅｃｔｉｏｎ要素という２つの手段のうちの１つによって示され得る。
仮想現実は、急速に発展している技術分野であって、ユーザヘッドセット（ヘッドマウントディスプレイとしても知られる）等のユーザ機器にイメージまたはビデオコンテンツ（オーディオを伴う場合もある）が提供される。周知のように、ユーザ機器には、コンテンツ元からのライブまたは格納フィードが提供され、そのフィードは、ユーザ機器を通じた没入型出力のための仮想空間を表す。現在、多くの仮想現実用ユーザ機器では、いわゆる３自由度（３ＤｏＦ）を採用しており、これは、ヨー軸、ピッチ軸、およびロール軸における頭部の動きの測定によって、ユーザが見るものすなわち表示域を決定することを意味する。ユーザ機器の位置および位置の変化を考慮したレンダリングによって、没入感を高め得ることが知られている。そこで、３ＤｏＦをさらに増強したものが６自由度（６ＤｏＦ）仮想現実システムであって、ユーザは、ユークリッド空間を自由に移動できるほか、頭部をヨー軸、ピッチ軸、およびロール軸に回転可能である。６自由度仮想現実システムによれば、ボリュメトリックコンテンツの提供および消費が可能となる。ボリュメトリックコンテンツは、あらゆる角度から空間および／または物体を３次元表現したデータを含むため、ユーザは、空間および／または物体の周りを自由に移動して、あらゆる角度からそれらを視認可能となる。このようなコンテンツは、幾何学（たとえば、形状、サイズ、３次元空間における位置）を記述するデータならびに色、不透明度、および反射率等の属性によって規定され得る。また、データは、２次元ビデオのフレームと同様に、所与の時間インスタンスにおける形状および属性の時間的変化を規定することも可能である。
３６０°ビデオ（３６０－ｄｅｇｒｅｅ ｖｉｄｅｏ）または仮想現実（ＶＲ）ビデオ（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ （ＶＲ） ｖｉｄｅｏ）という用語は、同じ意味で使用する場合がある。これらは一般的に、表示構成における単一の時点にビデオの一部のみが表示されるような大きな視野（ＦＯＶ）を提供するビデオコンテンツを表し得る。たとえば、ＶＲビデオは、たとえばおよそ１００°の視野を表示可能なヘッドマウントディスプレイ（ＨＭＤ）上に表示され得る。表示されるＶＲビデオコンテンツの空間的部分集合は、ＨＭＤの方向に基づいて選択され得る。別の例においては、フラットパネル表示環境が想定されるが、この場合は、たとえば最大４０°の視野が表示され得る。このようなディスプレイで広視野コンテンツ（たとえば、魚眼）を表示する場合は、画像全体ではなく、空間的部分集合を表示するのが好ましいとされてもよい。
ＭＰＥＧ Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｅｄｉａ Ｆｏｒｍａｔ（ＩＳＯ／ＩＥＣ ２３０９０－２）は、仮想現実（ＶＲ）システムの規格である。ＯＭＡＦは、メディアフォーマット（ＩＳＯＢＭＦＦから派生したファイルフォーマットならびにＤＡＳＨおよびＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔのストリーミングフォーマットの両者を含む）を規定する。ＯＭＡＦバージョン１は、３６０°のビデオ、イメージ、オーディオ、および関連する時限テキストをサポートし、３自由度（３ＤｏＦ）のコンテンツ消費を容易化する。つまり、全方位コンテンツが網羅する任意の方位および仰角範囲ならびに傾斜角度で表示域を選択可能であるものの、コンテンツは視認位置の如何なる並進変化にも適応されない。以下に詳述する表示域に応じたストリーミングシナリオについても、３ＤｏＦに合わせて設計されているが、潜在的には異なる自由度数への適応も可能である。
図１を参照しつつ、ＯＭＡＦについて論じる。現実世界の視聴シーン（Ａ）は、オーディオセンサのほか、一組のカメラまたは複数のレンズおよびセンサを備えたカメラ機器によって取り込まれ得る（２２０）。取得の結果として、一組のデジタルイメージ／ビデオ（Ｂｉ）およびオーディオ（Ｂａ）信号が得られる。カメラ／レンズは、カメラ集合またはカメラ機器の中心点周りの全方向を網羅し得るため、３６０°ビデオと称する。
多くのさまざまなマイク構成によってオーディオを取り込み、チャネルベースの信号、静的もしくは動的（すなわち、３Ｄシーンの移動）物体信号、ならびにシーンベースの信号（たとえば、高次アンビソニックス）といった複数の異なるコンテンツフォーマットとして格納することができる。チャネルベースの信号は、ＣＩＣＰ（Ｃｏｄｉｎｇ－Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｄｅ－Ｐｏｉｎｔ）で定義されたスピーカレイアウトのうちの１つに準拠し得る。全方位メディアアプリケーションにおいては、ヘッドフォンを介したプレゼンテーション用として、レンダリングされた没入型オーディオプログラムのスピーカレイアウト信号がバイナリ化されていてもよい。
同じ時間インスタンスのイメージ（Ｂｉ）がパッキング画像（Ｄ）に対してステッチング、投影、およびマッピングされる（２２１）。
単眼３６０°ビデオの場合は、ある時間インスタンスの入力イメージのステッチングによって、あるビューを表す投影画像を生成するようにしてもよい。単眼コンテンツのイメージステッチング、投影、および領域単位のパッキングプロセスの一例を図３に示す。入力イメージ（Ｂｉ）がステッチングされ、３次元投影構造（たとえば、単位球であってもよい）上に投影される（２０２）。投影構造は、平面またはその一部等、１つまたは複数の表面を含むと考えられ得る。投影構造（ｐｒｏｊｅｃｔｉｏｎ ｓｔｒｕｃｔｕｒｅ）は、取り込まれたＶＲイメージ／ビデオコンテンツが投影され、各投影画像が形成され得る１つまたは複数の表面から成る３次元構造として定義可能である。投影構造上のイメージデータが２次元投影画像（左目用のＣＬ、右目用のＣＲ）上にさらに配置される（２０３）。投影（ｐｒｏｊｅｃｔｉｏｎ）という用語は、一組の入力イメージを投影画像に投影するプロセスとして定義可能である。たとえば、正距円筒投影（ＥＲＰ）フォーマットおよびキューブマップ投影（ＣＭＰ）フォーマット等、投影画像の所定の一組の表現フォーマットが存在し得る。投影画像は、球全体を網羅するものと考えられ得る。
その後、任意選択として、領域単位のパッキング（２０４）の適用により、投影画像２０３（Ｃ）がパッキング画像２０５（Ｄ）上にマッピングされる。領域単位のパッキングが適用されない場合は、パッキング画像が投影画像と同一であり、この画像が入力としてイメージ／ビデオエンコーディング２０６に与えられる。それ以外の場合は、パッキング画像（Ｄ）における各領域の場所、形状、およびサイズを示すことにより、投影画像（Ｃ）の領域がパッキング画像上にマッピングされ、このパッキング画像（Ｄ）が入力としてイメージ／ビデオデコーディングに与えられる。領域単位のパッキング（ｒｅｇｉｏｎ－ｗｉｓｅ ｐａｃｋｉｎｇ）という用語は、投影画像がパッキング画像にマッピングされるプロセスとして定義可能である。パッキング画像（ｐａｃｋｅｄ ｐｉｃｔｕｒｅ）という用語は、投影画像の領域単位のパッキングにより得られる画像として定義可能である。
立体視３６０°ビデオの場合は、ある時間インスタンスの入力イメージのステッチングによって、それぞれの目に１つずつ、２つのビュー（ＣＬ、ＣＲ）を表す投影画像を生成する。両ビュー（ＣＬ、ＣＲ）は、同じパッキング画像（Ｄ）にマッピングし、従来の２Ｄビデオエンコーダによりエンコーディングすることができる。あるいは、投影画像の各ビューは、それ自体のパッキング画像にマッピングすることも可能であり、その場合は、図２に示すように、画像のステッチング、投影、および領域単位のパッキングが実行される。左右いずれかのビューの一連のパッキング画像は、独立してコーディングすることも可能であるし、マルチビュービデオエンコーダを使用する場合は、その他のビューから予測することも可能である。
イメージのステッチング、投影、および領域単位のパッキングプロセスは、同じソースイメージに対して複数回実行することにより、たとえば投影構造の異なる方向に対して、同じコンテンツの異なるバージョンを生成可能である。同様に、領域単位のパッキングプロセスは、同じ投影画像から複数回実行することにより、エンコーディング対象の二組以上のパッキング画像を生成可能である。
３６０°パノラマコンテンツ（すなわち、イメージおよびビデオ）は、撮像機器の取り込み位置周りの全３６０°視野を水平方向に網羅する。垂直視野は異なっていてもよく、たとえば１８０°が可能である。水平方向３６０°および垂直方向１８０°の視野を網羅するパノラマイメージは、正距円筒投影（ＥＲＰ）によって２次元像面にマッピングされた球により表され得る。この場合は、水平座標が経度に相当し、垂直座標が緯度に相当すると考えられ得るが、変換やスケーリングは適用されない。単眼正距円筒パノラマ画像を構成するプロセスを図４に示す。カメラアレイまたは複数のレンズおよびセンサを備えたカメラ機器の魚眼画像等の一組の入力イメージ２１１が球状イメージ２１３にステッチングされる（２１２）。球状イメージが円筒２１５（上下面なし）に対してさらに投影される（２１４）。円筒の展開（２１６）によって、２次元投影画像２１７を構成する。実際には、提示のステップのうちの１つまたは複数が統合されるようになっていてもよい。たとえば、入力イメージは、中間の球面への投影なく、円筒に直接投影されるようになっていてもよい。正距円筒パノラマの投影構造は、単一の表面を含む円筒になると考えられ得る。
一般的には、多面体（すなわち、平らな多角形の面、直線状の縁部、ならびに鋭い角部もしくは頂点を含む３次元立体物、たとえば、立方体または錐体）、円筒（正距円筒投影に関して上述した通り、球状イメージを円筒に投影）、円筒（最初の球面への投影なく直接）、円錐等の異なる種類の立体幾何学構造に３６０°コンテンツをマッピングした後、２次元像面に展開することができる。
場合により、水平方向３６０°および垂直方向１８０°未満の視野のパノラマコンテンツは、球の極域が２次元像面にマッピングされていない正距円筒投影の特殊ケースと考えられ得る。場合により、パノラマイメージは、水平方向視野が３６０°未満、垂直方向視野が最大１８０°であってもよく、それ以外の場合は、正距円筒投影フォーマットの特性を有する。
領域単位のパッキング情報は、ビットストリーム中またはビットストリームとともに、メタデータとしてエンコーディングされるようになっていてもよい。たとえば、パッキング情報には、上述の通り、所定または指定のソースフォーマットからパッキング画像フォーマットへの、たとえば、投影画像からパッキング画像への領域単位のマッピングを含んでいてもよい。
長方形領域単位のパッキングメタデータは、以下のように記述され得る。
メタデータは、各領域について、投影画像中の長方形、パッキング画像中の各長方形、ならびに９０°、１８０°、もしくは２７０°の回転、水平方向ミラーリング、および／もしくは垂直方向ミラーリングの任意選択的な変換を規定する。長方形は、たとえば左上角部および右下角部の場所により示されていてもよい。マッピングには、再サンプリングを含んでいてもよい。投影画像とパッキング画像とでそれぞれの長方形のサイズが異なり得るため、このメカニズムによって、領域単位の再サンプリングが推測される。
特に、領域単位のパッキングは、以下のような使用シナリオのシグナリングを提供する。
１）表示域から独立した投影の追加圧縮は、異なる領域のサンプリングを高密度化して球全体でより均一性を高めることで実現される。たとえば、ＥＲＰの上部および下部がオーバサンプリングされ、領域単位のパッキングの適用によって、水平方向のダウンサンプリングが可能となる。
２）キューブマップ投影等の平面ベースの投影フォーマットの面を適応的に配置する。
３）表示域から独立した投影フォーマットを使用する表示域従属ビットストリームを生成する。たとえば、ＥＲＰの領域またはＣＭＰの面は、サンプリング密度が異なり得るため、その基礎となる投影構造の方向も異なり得る。
４）抽出器トラックにより表されるパッキング画像の領域を示す。これは、抽出器トラックが異なる解像度のビットストリームからタイルを収集する場合に必要となる。
ガードバンド（ｇｕａｒｄ ｂａｎｄ）は、パッキング画像中の非レンダリングエリアとして定義可能であるが、パッキング画像のレンダリング部を改良して継ぎ目等の視覚的アーチファクトを回避または軽減するのに使用可能である。
図１を再び参照して、ＯＭＡＦによれば、イメージのステッチング、投影、および領域単位のパッキングを省略して、イメージ／ビデオデータをそれぞれの取り込みフォーマットにてエンコーディングすることができる。この場合、イメージ（Ｄ）は、イメージ（Ｂｉ）と同じものと考えられ、時間インスタンス当たりにエンコーディングされる魚眼イメージの数は限られる。
オーディオの場合は、取り込まれる信号が本質的に没入型かつ全方位であることから、ステッチングプロセスは不要である。
ステッチイメージ（Ｄ）は、コード化イメージ（Ｅｉ）またはコード化ビデオビットストリーム（Ｅｖ）としてエンコーディングされる（２０６）。取り込まれたオーディオ（Ｂａ）は、オーディオビットストリーム（Ｅａ）としてエンコーディングされる（２２２）。コード化イメージ、ビデオ、および／またはオーディオはその後、特定のメディアコンテナファイルフォーマットに従って、ファイル再生（Ｆ）用のメディアファイルまたはストリーミング（Ｆｓ）用の一連の初期化セグメントおよびメディアセグメントとして合成される（２２４）。本明細書において、メディアコンテナファイルフォーマットは、ＩＳＯベースメディアファイルフォーマットである。また、ファイルカプセル化器２２４は、デコーディングされたパッキング画像のレンダリングを補助する投影および領域単位のパッキング情報等のメタデータをファイルまたはセグメントに含める。
ファイル中のメタデータには、以下を含んでいてもよい。
投影画像の投影フォーマット
魚眼ビデオパラメータ
パッキング画像が網羅する球面の面積
投影画像に対応する投影構造のグローバル座標軸に対する方向
領域単位のパッキング情報
領域単位の品質ランキング（任意）
領域単位のパッキング情報は、ビットストリーム中またはビットストリームとともに、たとえば領域単位のパッキングＳＥＩメッセージおよび／またはビットストリームを含むファイル中の領域単位のパッキングボックス等のメタデータとしてエンコーディングされるようになっていてもよい。たとえば、パッキング情報には、上述の通り、所定または指定のソースフォーマットからパッキング画像フォーマットへの、たとえば、投影画像からパッキング画像への領域単位のマッピングを含んでいてもよい。領域単位のマッピング情報には、たとえば各マッピング領域について、投影画像における開始長方形（投影領域としても知られる）およびパッキング画像における最終長方形（パッキング領域としても知られる）を含んでいてもよく、開始長方形内のサンプルは最終長方形にマッピングされ、長方形は、たとえば左上角部および右下角部の場所により示されていてもよい。マッピングには、再サンプリングを含んでいてもよい。この追加または代替として、パッキング情報には、座標系に対する３次元投影構造の方向、使用される投影フォーマットの表示、領域間ならびに／または第１および第２の空間領域シーケンス間の画質ランキングを示す領域単位の品質ランキング、９０、１８０、もしくは２７０°の回転、水平方向ミラーリング、ならびに垂直方向ミラーリング等の１つまたは複数の変換操作のうちの１つまたは複数を含んでいてもよい。パッキング情報のセマンティクスは、パッキング領域内の各サンプルの場所について、それぞれの球座標の場所であるデコード画像を示すように規定されていてもよい。
セマンティクス（Ｆｓ）は、配信メカニズムによってプレーヤに配信され得る（２２５）。
ファイルカプセル化器が出力するファイル（Ｆ）は、ファイル脱カプセル化器が入力するファイル（Ｆ’）と同一である。ファイル脱カプセル化器２２６は、ファイル（Ｆ’）または受信セグメント（Ｆ’ｓ）を処理して、コード化ビットストリーム（Ｅ’ａ、Ｅ’ｖ、および／またはＥ’ｉ）を抽出するとともに、メタデータをパーシングする。その後、オーディオ、ビデオ、および／またはイメージがデコード信号（オーディオの場合のＢ’ａおよびイメージ／ビデオの場合のＤ’）としてデコーディングされる（２２８）。デコーディングされたパッキング画像（Ｄ’）は、現在の視認方向もしくは表示域ならびにファイルからパーシングされた投影、球面網羅、投影構造の方向、および領域単位のパッキングメタデータに基づいて、ヘッドマウントディスプレイまたはその他任意の表示装置２３０の画面上に投影される（２２９）。同様に、デコードオーディオ（Ｂ’ａ）は、現在の視認方向に応じて、たとえばヘッドフォン２３１を通じてレンダリングされる（２２９）。現在の視認方向は、頭部追跡および場合により視線追跡の機能２２７によって決定される。デコードビデオおよびオーディオ信号の適当な部分のレンダリングのためにレンダラ２２９が使用するほか、現在の視認方向は、ビデオ・オーディオデコーダ２２８によるデコーディング最適化のために用いられるようになっていてもよい。
上述のプロセスは、ライブおよびオンデマンドの両使用事例に適用可能である。
アプリケーションによってＨＭＤまたは別の表示装置にレンダリングされたビデオは、いずれの時点においても、３６０°ビデオの一部をレンダリングする。この部分は、表示域として規定され得る。表示域は、レンダリング表示により表示された全方位ビデオにおいて表される３６０°世界上の窓として理解され得る。別の定義によれば、表示域は、現在表示されている球状ビデオの一部として規定され得る。表示域は、水平方向および垂直方向視野（ＦＯＶまたはＦｏＶ）を特徴としていてもよい。
視点は、点または空間として規定され、ユーザはそこからシーンを見ることができ、通例はカメラ位置に対応する。頭部のわずかな動きは、異なる視点を暗示しない。視認位置（ｖｉｅｗｉｎｇ ｐｏｓｉｔｉｏｎ）は、ユーザがシーンを見る際の起点となる視認空間内の位置として定義可能である。視認空間（ｖｉｅｗｉｎｇ ｓｐａｃｅ）は、イメージおよびビデオのレンダリングが可能で、ＶＲ体験が有効な視認位置の３Ｄ空間として定義可能である。
ボリュメトリックコンテンツの一般的な表現フォーマットとして、三角形メッシュ、点群（ｐｏｉｎｔ ｃｌｏｕｄ）、およびボクセルが挙げられる。コンテンツに関する時間的情報としては、個々の取り込みインスタンス、すなわち、フレームまたは時間の関数としての物体の位置が挙げられ得る。
演算リソースおよび３次元取得機器の進歩により、高精細なボリュメトリック表現の再構成が可能である。このようなコンテンツを構成可能な方法の例として、赤外線、レーザ、飛行時間、および構造化光技術がある。ボリュメトリックコンテンツの表現は、データの使用方法によって決まり得る。たとえば、ボリュメトリック医療イメージの表現には、高密度のボクセルアレイが用いられるようになっていてもよい。３次元グラフィックスにおいては、ポリゴンメッシュが多用される。一方、トポロジが必ずしも２次元表面でも多様体でもない現実世界のシーンの取り込み等の用途には、点群が最適である。別の方法では、一組のテクスチャおよび深度マップとして、３次元データをコーディングする。これと密接に関係しているのが標高地図や多層地形図の使用である。当然のことながら、本明細書の実施形態は、上記技術のいずれにも適用可能である。
３次元世界の「ボクセル」は、２次元世界のピクセルに対応する。ボクセルは、３次元グリッドレイアウトにて存在する。八分木は、３次元空間の分離に用いられるツリーデータ構造である。八分木は、四分木の３次元類似物である。スパースボクセル八分木（ＳＶＯ）は、さまざまなサイズの一組のソリッドボクセルを含む空間のボリュームを記述する。ボリューム内の空のエリアは、ツリーに存在しないため、「スパース」と称する。
シーンの３次元ボリュメトリック表現は、少なくとも１つのマルチカメラ機器の入力ストリームに基づいて、複数のボクセルとして決定され得る。このため、少なくとも１つ、好ましくは複数（すなわち、２、３、４、５つ以上）のマルチカメラ機器の使用により、シーンの３Ｄビデオ表現を取り込むことができる。マルチカメラ機器は、シーンに対して異なる場所に分布しているため、それぞれがシーンの異なる３Ｄビデオ表現を取り込む。各マルチカメラ機器により取り込まれた３Ｄビデオ表現は、シーンの３Ｄボリュメトリック表現を生成するための入力ストリームとして使用されるようになっていてもよく、前記３Ｄボリュメトリック表現は、複数のボクセルを含む。たとえば選択３Ｄ点について、ボクセル中の最大３Ｄ点数を超えることなく、当該選択３Ｄ点から所定の閾値内のすべての隣接３Ｄ点がボクセルに統合されるように、複数の３Ｄ点を含むボクセルへと３Ｄ点を統合することによって、取り込まれた３Ｄ点からボクセルが形成されるようになっていてもよい。
また、ボクセルは、スパースボクセル八分木の構成により形成されていてもよい。このようなツリーの各リーフは、世界空間におけるソリッドボクセルを表し、ツリーのルートノードは、世界の境界を表す。スパースボクセル八分木の構成は、１）各入力深度マップを世界空間点群にマッピングするステップ（深度マップの各ピクセルが１つまたは複数の３Ｄ点にマッピングされる）と、２）カメライメージおよび深度マップにおけるソースピクセルの近傍を調べることによって、色および表面法線ベクトル等のボクセル属性を決定するステップと、３）深度マップからの深度値と深度マップの解像度に基づいて、ボクセルのサイズを決定するステップと、４）世界境界に対するサイズの関数として、ソリッドボクセルのＳＶＯレベルを決定するステップと、５）世界境界に対する当該レベル上のボクセル座標を決定するステップと、６）決定したボクセル座標に到着するまで、新たなＳＶＯノードの生成および／または既存のＳＶＯノードのトラバースを行うステップと、７）ツリーのリーフとしてソリッドボクセルを挿入し、場合により上記座標に存在していたボクセルからの属性の置き換えまたは統合を行うステップと、を有していてもよい。それにも関わらず、シーンの３Ｄボリュメトリック表現内のボクセルのサイズは、互いに異なる場合がある。このため、３Ｄボリュメトリック表現のボクセルは、シーン内の空間的な場所を表す。
ボリュメトリックビデオフレームは、ビデオシーケンス中の特定時点における世界をモデル化した完全なスパースボクセル八分木と見なすことができる。ボクセルの属性には、色、不透明度、表面法線ベクトル、および表面材料特性等の情報を含む。これらは、スパースボクセル八分木において参照されるが（たとえば、ソリッドボクセルの色）、別個に格納することも可能である。
点群は通常、ボリュメトリックコンテンツを格納するデータ構造として使用される。点群と比較して、スパースボクセル八分木は、さまざまなサイズのソリッドボクセルによる有限体積の再帰的細分を表す一方、点群は、使用する座標値の精度によってのみ制限される組織化されていない一組の別個の点を表す。
高密度点群およびボクセルアレイ等の技術においては、数千万個あるいは数億個もの点が存在し得る。このようなコンテンツをＩＰネットワーク上のサーバおよびクライアント等のエンティティ間で格納・転送するには通例、圧縮が必要である。
ユーザの位置は、たとえばユーザが所与の仮想現実空間内で個々の物体または物体群の周りを自由に移動でき、現実世界におけるユーザの頭部の動き（たとえば、回転および場所）に応じて異なる角度から物体を見られるように、ボリュメトリック仮想現実コンテンツ内で提供されるコンテンツに対して検出可能である。また、いくつかの例において、ユーザは、複数の異なる仮想現実空間を見て探索し、ある仮想現実空間から別の仮想現実空間へと移動するようにしてもよい。
ヘッドマウントディスプレイ等のレンダリング配置によって観察可能または聴取可能な環境の角度的範囲は、視野（ＦＯＶ）と称し得る。ユーザが実際に観察または聴取するＦＯＶは、瞳孔間距離および仮想現実ヘッドセットのレンズとユーザの目との間の距離に依存するが、仮想現実ヘッドセットをユーザが装着している場合は、所与の表示装置のすべてのユーザに対して略同じであると考えることができる。
ボリュメトリックコンテンツを単一の視認位置から見る場合、コンテンツの一部（半分であることが多い）は、ユーザの反対側を向くため見えない。この部分は、「後向きコンテンツ」と称する場合がある。
ボリュメトリックイメージ／ビデオ配信システムは、ボリュメトリックシーンの一部を表す複数のパッチを提供するとともに、各パッチについて、パッチの前方表面が見える一組の方向を示すパッチ視認性情報を提供するようにしてもよい。ボリュメトリックイメージ／ビデオ配信システムはさらに、クライアント機器と関連付けられた１つまたは複数の視認位置を提供するとともに、１つまたは複数のパッチの前方表面が１つまたは複数の視認位置から見えることをパッチ視認性情報が示すかに応じて、パッチのうちの１つまたは複数を処理するようにしてもよい。
パッチ視認性情報は、ボリュメトリック空間においてパッチの前方表面が見られる場所を示すデータである。たとえば、パッチ視認性情報には視認性円錐を含んでいてもよく、これは、視認性円錐方向ベクトル（Ｘ，Ｙ，Ｚ）および開口角（Ａ）を含んでいてもよい。開口角（Ａ）は、パッチの前方表面が見られる一組の空間角度を規定する。別の例において、パッチ視認性メタデータには、全方位メディアフォーマット（ＯＭＡＦ）規格（ＩＳＯ／ＩＥＣ ２３０９０－２）により規定されたものと同一または同様の境界球面および球領域メタデータの定義を含んでいてもよい。境界球面は、たとえば球の中心の３次元位置および球の半径によって規定され得る。視認位置が境界球面と同位置である場合、パッチは、指定の球領域内において視認可能と考えられ得る。一般的に、境界面の形状は、円筒、立方体、または直方体等、球以外の形状であってもよい。境界面の中心の３次元位置が同じである一方、半径（または、３次元位置からの境界面の距離を示す情報）が異なる複数組のパッチ視認性メタデータが規定されていてもよい。オクルージョンの取り扱いのため、パッチ視認性メタデータを複数示すことが有効な場合もある。
ボリュメトリックイメージ／ビデオ配信システムは、１つまたは複数のパッチ選択モジュールを備えていてもよい。あるパッチ選択モジュールは、ユーザ機器、たとえば、ヘッドセットのレンダリングモジュールに伝送されるパッチを決定するように構成されていてもよい。別のパッチ選択モジュールは、デコーディングされるパッチを決定するように構成されていてもよい。第３のパッチ選択モジュールは、レンダリングされるデコーディングパッチを決定するように構成されていてもよい。ボリュメトリックイメージ／ビデオ配信または再生システムにおいては、パッチ選択モジュールの如何なる組み合わせが存在していてもよいし、アクティブであってもよい。パッチ選択では、パッチのパッチ視認性情報、現在の視認位置、現在の視認方向、予想される将来の視認位置、および／または予想される将来の視認方向を利用するようにしてもよい。
場合により、各ボリュメトリックパッチは、２次元の色（または、他の形態のテクスチャ）イメージおよび対応する深度イメージ（深度マップとしても知られる）に投影され得る。この変換によれば、両イメージを用いることにより、ヘッドセットのクライアントレンダリングモジュールにおいて、各パッチを変換してボリュメトリック形態に戻すことが可能となる。
場合によっては、点群フレーム等のボリュメトリックイメージのソースボリュームが１つまたは複数の投影面に投影されるようになっていてもよい。投影面上のパッチが決定されてもよく、１つまたは複数の２次元フレーム上に配置されるようになっていてもよい。上記の通り、テクスチャおよび深度パッチが同様に形成されていてもよく、ソースボリュームの投影面への投影およびスパース投影の修復を示す。言い換えると、メッシュ要素、点、および／またはボクセル等の幾何学的プリミティブを含む３次元（３Ｄ）シーンモデルが１つまたは複数の投影面に投影される。これらの投影面形状は、２Ｄ平面（通常、投影されたソースボリュームごとに２つの平面（一方がテクスチャ用、もう一方が深度用））に「展開」され得る。「展開」には、パッチの決定を含んでいてもよい。その後、２Ｄ平面は、標準的な２Ｄイメージまたはビデオ圧縮技術を用いてエンコーディングされるようになっていてもよい。関連する投影形状情報がエンコードビデオファイルと併せてデコーダに伝送されるようになっていてもよい。その後、デコーダは、コード化イメージ／ビデオシーケンスをデコーディングし、逆投影を実行して、任意所望の表現フォーマット、たとえば、元のメッシュモデルデータからの点群の再構成等、開始フォーマットと異なっていてもよいで３Ｄシーンモデル物体を再生成するようにしてもよい。
場合によっては、ボリュメトリックビデオまたはイメージの複数の点（たとえば、点群）が同じピクセル位置に投影される。このような場合は、２つ以上の「レイヤ」を生成することにより取り扱い可能である。点群圧縮等のボリュメトリックビデオにおけるレイヤの概念は、スケーラブルビデオコーディングにおけるレイヤの概念と異なる場合があることに留意する。したがって、ＰＣＣレイヤ（ＰＣＣレイヤ）またはボリュメトリックビデオレイヤ（ｖｏｌｕｍｅｔｒｉｃ ｖｉｄｅｏ ｌａｙｅｒ）等の用語は、スケーラブルビデオコーディングのレイヤと区別するために使用可能である。各ボリュメトリック（３Ｄ）パッチは、２つ以上の２Ｄパッチに投影され、同じ２Ｄ位置に投影された点等の視覚データの異なるレイヤを表し得る。パッチは、たとえば投影面までの距離の昇順に基づいて組織化されていてもよい。より正確に、以下の例示的なプロセスは、２つのレイヤの生成に使用可能であるが、他の数のレイヤにも一般化可能である。Ｈ（ｕ，ｖ）を同じピクセル（ｕ，ｖ）に投影される現在のパッチの一組の点とする。近傍レイヤとも称する第１の層は、最小深度Ｄ０でＨ（ｕ，ｖ）の点を格納する。遠方レイヤと称する第２のレイヤは、区間［Ｄ０，Ｄ０＋ｄ］内で最も深いＨ（ｕ，ｖ）の点を取り込む。ここで、ｄは、表面厚さを表すユーザ定義パラメータである。
ボリュメトリックイメージ／ビデオは、テクスチャおよび深度の追加または代替として、反射率、不透明度もしくは透明度（たとえば、アルファチャネルパッチ）、表面法線、アルベド、ならびに／または他の材料もしくは表面属性パッチ等、他の種類のパッチを含み得ることが了解されるものとする。
２次元形態のパッチが１つまたは複数のアトラスとしてパッキングされるようになっていてもよい。テクスチャアトラスは当技術分野において周知であり、サブイメージから成るイメージを含むが、このイメージは、グラフィックスハードウェアにより１つの単位として処理され、単一のイメージとして圧縮・伝送されることにより、後で識別・解凍可能である。形状アトラスは、テクスチャアトラスと同様に構成され得る。テクスチャおよび形状アトラスは、別個の画像として（かつ、ボリュメトリックビデオの場合は別個の画像シーケンスとして）処理されるようになっていてもよいし、たとえばフレームパッキングが従来から行われている方式と同様に、同じフレーム上にパッキングされるようになっていてもよい。アトラスは、イメージまたはビデオエンコーダによりフレームとしてエンコーディングされるようになっていてもよい。
また、アトラスにおけるサブイメージのレイアウトは、他の時空間単位とは独立してデコーディング可能な時空間単位として、類似の視認性情報を有するパッチまたは一組のパッチをエンコーディングできるように組織化されていてもよい。たとえば、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）の背景において理解されるように、タイルグリッドがエンコーディングのために選択されてもよく、類似の視認性情報を有するパッチまたはパッチ群が動き制約タイル集合（ＭＣＴＳ）としてエンコーディングされ得るように、アトラスが組織化されていてもよい。
場合によっては、ＩＳＯベースメディアファイルフォーマットの背景において理解されるか、または、任意の類似コンテナファイルフォーマット構造と同様に、１つまたは複数の（一式ではない）時空間単位がトラックとして提供・格納されるようになっていてもよい。このようなトラックは、パッチトラックと称し得る。パッチトラックは、たとえばＯＭＡＦの背景において理解されるようなサブ画像トラックであってもよいし、ＩＳＯ／ＩＥＣ １４４９６－１５の背景において理解されるようなタイルトラックであってもよい。
場合によっては、１つまたは複数のアトラスの複数のバージョンがエンコーディングされる。異なるバージョンとしては、同じ解像度での１つもしくは複数のアトラスの異なるビットレートバージョン、アトラスの異なる空間解像度、ならびに異なるランダムアクセス区間用の異なるバージョンのうちの１つまたは複数が挙げられるが、これらに限定されない。これらには、１つまたは複数の内部コード化アトラスを含んでいてもよい（すべての画像にランダムアクセス可能である）。
場合によっては、ＯＭＡＦおよび／またはＩＳＯ／ＩＥＣ １４４９６－１５の背景において理解されるように、抽出器トラック等のメタデータとして、テクスチャアトラスの異なるバージョンからのパッチの組み合わせが規定され、記述されるようになっていてもよい。
テクスチャアトラスならびに場合によっては各形状画像および／もしくは他の補助画像（存在する場合）の総サンプル数が、ビデオコーデックのレベル限界等の限界を超えた場合は、その制限に従うように規定が生成されるようになっていてもよい。たとえば、主観的な重要度に応じて、低解像度のテクスチャアトラスからパッチが選択されるようになっていてもよい。この選択は、視認位置に関係なく実行されるようになっていてもよい。上記規定には、従う制限を特徴付けるメタデータ、たとえば、従うコーデックレベルを伴っていてもよい。
規定は、視認性円錐（または、一般的に特定の視認性）に固有とされ、当該視認性円錐内で見えないパッチは除外していてもよい。規定が生成される視認性円錐の選択は、ある規定から別の規定への切り替えが頻繁に発生しないと予想されるように、合理的な回数に制限されていてもよい。規定の視認性円錐は、２つの規定間の交互の切り替えを回避するため、重なり合っていてもよい。この規定には、視認性円錐（または、一般的に視認性情報）を示すメタデータを伴っていてもよい。
規定では、独立した時空間単位の特定のグリッドまたはパターンを使用することができる。たとえば、規定では、特定のタイルグリッドを使用可能であるが、タイル境界はＭＣＴＳ境界でもある。この規定には、時空間的単位として好適な潜在的ソースを示すメタデータ（たとえば、トラック群、トラック、または表現）を伴っていてもよい。
場合によっては、パッチトラックがＤＡＳＨの背景におけるＲｅｐｒｅｓｅｎｔａｔｉｏｎを構成する。その結果、ＤＡＳＨ ＭＰＤのＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素は、パッチ視認性メタデータ等、パッチトラックと関連したパッチに関するメタデータを提供し得る。クライアントは、パッチ視認性メタデータに基づいて、パッチＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択するとともに、選択したＲｅｐｒｅｓｅｎｔａｔｉｏｎから（Ｓｕｂ）ｓｅｇｍｅｎｔを要求するようにしてもよい。
収集器トラック（ｃｏｌｌｅｃｔｏｒ ｔｒａｃｋ）は、ＭＣＴＳまたはサブ画像のコード化ビデオデータ等を他のトラックから暗示的または明示的にコード化ビデオデータを抽出するトラックとして定義可能である。ファイルリーダまたは同等のものによって分解されると、収集器トラックは、ビデオコーディング規格またはフォーマットに準拠したビットストリームになると考えられ得る。収集器トラックは、たとえばＭＣＴＳまたはサブ画像の抽出によって、ＭＣＴＳまたはサブ画像がグリッドに配置されたコード化画像シーケンスを構成するようにしてもよい。たとえば、収集器トラックが２つのＭＣＴＳまたはサブ画像を抽出した場合は、これらがＭＣＴＳまたはサブ画像の２×１グリッドとして配置されるようになっていてもよい。後述の通り、他のトラックからＭＣＴＳまたはサブ画像を抽出する抽出器トラックを収集器トラックと見なすことができる。後述するようなタイルベーストラックが収集器トラックの別の例である。収集器トラックは、収集トラックとも称し得る。収集器トラックに対する抽出の元となるトラックは、収集項目トラックと称し得る。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣに関してＩＳＯ／ＩＥＣ １４４９６－１５に規定された抽出器によれば、ＮＡＬ単位データを参照により抽出するトラックのコンパクトな構成が可能である。抽出器は、ＮＡＬ単位様構造である。ＮＡＬ単位様構造は、他のＮＡＬ単位のように、ＮＡＬ単位ヘッダおよびＮＡＬ単位ペイロードを含むように規定されていてもよいが、ＮＡＬ単位様構造においては、（ＮＡＬ単位に必要な）始端コードエミュレーションの防止が守られていない可能性もある。ＨＥＶＣに関して、抽出器は、１つまたは複数の構成器を含む。サンプル構成器は、参照により、別のトラックのサンプルからＮＡＬ単位データを抽出する。インライン構成器は、ＮＡＬ単位データを含む。インライン（ｉｎ－ｌｉｎｅ）という用語は、たとえばデータ単位との関連において、包含するシンタックス構造が（参照またはデータポインタによってデータ単位を含むのとは対照的に）データ単位を包含または保有することを示すように定義可能である。抽出器は、必要なファイルリーダによって処理される場合、包含構成器を出現順序で分解した結果のバイトで論理的に置き換えられる。入れ子の抽出は不可能であって、たとえばサンプル構成器が参照するバイトが抽出器を含まないものとする。抽出器は、直接的にも間接的にも、別の抽出器を参照しないものとする。抽出器は、現在のトラックまたは「ｓｃａｌ」タイプのトラック基準によって抽出器が存在するトラックにリンクされた別のトラックからデータを抽出する１つまたは複数の構成器を含んでいてもよい。分解された抽出器のバイトは、１つまたは複数のＮＡＬ単位全体を表していてもよい。分解された抽出器は、有効な長さフィールドおよびＮＡＬ単位ヘッダから始まる。サンプル構成器のバイトは、指定の「ｓｃａｌ」トラック基準を通じて参照されるトラックにおける単一の識別サンプルからのみコピーされる。位置合わせは、デコーディング時間に合わせて、すなわち、時間対サンプルテーブルのみを使用した後、サンプル番号のオフセットをカウントする。抽出器は、メディアレベルの概念であるため、任意の編集リストを考慮する前の最終トラックに当てはまる（ただし、通常は、２つのトラックの編集リストが同一になるものと予想される）。
表示域に応じたストリーミング（表示域適応ストリーミング（ＶＡＳ）または表示域固有ストリーミングとも称し得る）において、表示域（すなわち、現在の視認方向）を網羅する３６０°ビデオコンテンツの部分集合は、３６０°ビデオのその他の部分の品質および／または解像度よりも良い品質および／または高い解像度で伝送される。表示域に応じた全方位ビデオストリーミングの実現には、複数の選択肢がある。タイルベースの表示域に応じたストリーミングでは、動き制約タイル集合（ＭＣＴＳ）または同等のものとしてコーディングされたタイルへと投影画像が分離される。同じＭＣＴＳ分離を用いることにより、複数のバージョンのコンテンツが異なるビットレートまたは品質でエンコーディングされる。各ＭＣＴＳシーケンスは、ＤＡＳＨ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ等と同様に、ストリーミングに利用可能となる。プレーヤは、ＭＣＴＳに基づいて、受信するビットレートまたは品質を選択する。
Ｈ．２６４／ＡＶＣには、タイルの概念を含まないが、領域をスライスとして垂直に配置し、ＭＣＴＳのエンコーディングと同様にエンコーディングを制限することによって、ＭＣＴＳのような動作を実現可能である。簡素化のため、本明細書においては、タイルおよびＭＣＴＳという用語を使用するが、これらは、Ｈ．２６４／ＡＶＣにも限定的に当てはまることが了解されるものとする。一般的に、タイルおよびＭＣＴＳという用語は、任意のコーディングフォーマットまたは仕様における類似の概念に当てはまることが了解されるものとする。
タイルベースの表示域に応じたストリーミング方式の考え得る細分として、以下が挙げられる。
領域単位の混合品質（ＲＷＭＱ）３６０°ビデオ：同じ解像度、同じタイルグリッド、および異なるビットレート／画質で複数のバージョンのコンテンツがコーディングされる。プレーヤは、表示域に対して高品質ＭＣＴＳを選定する。
表示域＋３６０°ビデオ：低解像度／低品質の全方位ビデオ全体の１つまたは複数のビットレートおよび／または解像度バージョンがエンコーディングされ、ストリーミングに利用可能となる。また、ＭＣＴＳベースのエンコーディングが実行され、ＭＣＴＳシーケンスがストリーミングに利用可能となる。プレーヤは、低解像度／低品質の全方位ビデオ全体を受信し、表示域を網羅する高解像度のＭＣＴＳを選択して受信する。
領域単位の混合解像度（ＲＷＭＲ）３６０°ビデオ：ＭＣＴＳが複数の解像度でエンコーディングされる。プレーヤは、表示域を網羅する高解像度ＭＣＴＳおよびその他のエリアに対する低解像度ＭＣＴＳの組み合わせを選択する。
タイルベースの表示域に応じたストリーミング方法をカテゴリに細分する方法は、上記以外にもあり得ることを理解する必要がある。さらに、上述の細分は、網羅的ではない場合もある。すなわち、上記カテゴリのいずれにも属さないタイルベースの表示域に応じたストリーミング方法の場合もある。
上述の表示域に応じたストリーミング手法のすべてにおいて、タイルもしくＭＣＴＳ（または、タイルもしくＭＣＴＳのガードバンド）は、前処理またはエンコーディングにおいて選択された量だけ、球の範囲で重なり合っていてもよい。
上述の表示域に応じたストリーミング手法はすべて、クライアント主導のビットストリーム書き換え（後期バインディングとしても知られる）または製作者主導のＭＣＴＳ結合（初期バインディング（ｅａｒｌｙ ｂｉｎｄｉｎｇ）としても知られる）により実現されるようになっていてもよい。後期バインディングにおいて、プレーヤは、受信するＭＣＴＳシーケンスを選択し、受信したＭＣＴＳを単一のビットストリームに結合する必要に応じて、受信したビデオデータの一部を選択的に書き換え（たとえば、パラメータ集合およびスライスセグメントヘッダの書き換えが必要となり得る）、この単一のビットストリームをデコーディングする。初期バインディングは、受信したビデオデータの一部を必要に応じて書き換えたり、ＭＣＴＳを単一のビットストリームに結合してデコーディングしたり、場合によっては受信するＭＣＴＳシーケンスを選択したりするための製作者主導の情報の使用を表す。初期バインディングと後期バインディングとの間の手法があってもよく、たとえば製作者のガイドなく、受信するＭＣＴＳシーケンスをプレーヤに選択させる一方、ＭＣＴＳ結合およびヘッダ書き換えには、製作者主導の手法を用いることが可能となり得る。初期バインディング手法には、後述する抽出器主導手法およびタイルトラック手法を含む。
タイルトラック手法においては、１つまたは複数の動き制約タイル集合シーケンスがビットストリームから抽出され、抽出された各動き制約タイル集合シーケンスがタイルトラック（たとえば、ＨＥＶＣタイルトラック）としてファイルに格納される。タイルベーストラック（たとえば、ＨＥＶＣタイルベーストラック）が生成され、ファイルに格納されるようになっていてもよい。タイルベーストラックは、タイルトラックから動き制約タイル集合を暗示的に収集することによって、ビットストリームを表す。受信側では、ストリーミングされるタイルトラックが視認方向に基づいて選択されるようになっていてもよい。クライアントは、全方位コンテンツ全体を網羅するタイルトラックを受信するようにしてもよい。現在の表示域については、その他の３６０°ビデオを網羅する品質または解像度と比較して、より良い品質または高解像度のタイルトラックが受信されるようになっていてもよい。タイルベーストラックがタイルトラックに対するトラック基準を含むこと、および／または、タイルトラックがタイルベーストラックに対するトラック基準を含むことが可能である。たとえば、ＨＥＶＣにおいては、「ｓａｂｔ」トラック基準の使用により、タイルベーストラックからタイルトラックを参照し、タイル順序は、「ｓａｂｔ」トラック基準に含まれるタイルトラックの順序によって示される。さらに、ＨＥＶＣにおいては、タイルトラックがタイルベーストラックに対する「ｔｂａｓ」トラック基準を有する。
抽出器主導手法においては、１つまたは複数の動き制約タイル集合シーケンスがビットストリームから抽出され、抽出された各動き制約タイル集合シーケンスは、それ自体の適合ビットストリーム（たとえば、ＨＥＶＣビットストリーム）となるように修正され、（ＨＥＶＣに対する未変換サンプルエントリタイプ「ｈｖｃ１」の）サブ画像トラックとしてファイルに格納される。１つまたは複数の抽出器トラック（たとえば、ＨＥＶＣ抽出器トラック）が生成され、ファイルに格納されるようになっていてもよい。抽出器トラックは、サブ画像トラックから動き制約タイル集合を（たとえば、ＨＥＶＣ抽出器によって）明示的に抽出することによって、ビットストリームを表す。受信側では、ストリーミングされるサブ画像トラックが視認方向に基づいて選択されるようになっていてもよい。クライアントは、全方位コンテンツ全体を網羅するサブ画像トラックを受信するようにしてもよい。現在の表示域については、その他の３６０°ビデオを網羅する品質または解像度と比較して、より良い品質または高解像度のサブ画像トラックが受信されるようになっていてもよい。
製作者主導のＭＣＴＳ結合に基づく一方、ビットレートバージョン間のクライアント主導の決定を可能にする手法では、同位置の動き制約タイル集合を選択肢として提供可能であり、クライアントは、その中から現行のネットワークスループットおよび表示域に適したビットレートバージョンを選択することができる。後期バインディングが使用される場合、クライアントは、デコーディング可能なビットストリームに結合可能な任意の動き制約タイル集合を選択することができる。
独立コード化画像領域の数は、比較的多くすることができる。一例として、９６個の領域（立方体面ごとに４×４個の領域）が挙げられることが多い。ストリーミングアプリケーションにおいては、同じコンテンツを複数の解像度およびビットレートで作成することが珍しくない。たとえば、半ダースの選択肢を用意し、そこからストリーミングクライアントが動的に選定できるようにすることも可能である。
結合ビットストリームの目標とする画像サイズは、たとえば好適なビデオコーディングレベルに応じて選択されるようになっていてもよい。結合ビットストリームに適用されるイメージセグメントまたは独立コード化画像領域への画像の分離（タイルおよびブリック分離等）は、利用可能なソースビットストリーム中のイメージセグメントまたは独立コード化画像領域の幅および高さに応じて選択されるようになっていてもよい。異なるクライアント戦略および視認条件（たとえば、視野）に柔軟に対応するために、イメージセグメントおよび／または独立コード化画像領域の幅および高さは、利用可能なすべてのソースビットストリームと同一になるように選択可能である。
図１１ａは、キューブマップコンテンツが「８Ｋ」、「６Ｋ」、「４Ｋ」、および「２Ｋ」の解像度でエンコーディングされた一例を示しており、これに対して、赤道上の輝度サンプルの数は、それぞれ８１９２個、６１４４個、４０９６個、および２０４８個である。すべてのバージョンにおいて、タイルの幅および高さは、同一になるように選択される（５１２個の輝度サンプル）。各タイルは、独立コード化画像領域としてエンコーディングされる。
図１１ｂは、４Ｋデコーディング機能への使用に３×１１のタイルグリッドが選択された一例を示している。
図１１ｃは、クライアントが任意の方法により任意の解像度バージョンからタイルを選択可能な一例を示している。本例において、クライアントは、「８Ｋ」キューブマップから可能な限り多くのタイルを選定し、予想外の視認方向変化に対するバックアップとして、「２Ｋ」キューブマップ全体を維持する。
図１１ｄは、提示の「６Ｋ」方法において、「６Ｋ」バージョンの３つ以上の立方体面、「４Ｋ」バージョンの３つ以上の立方体面、および「２Ｋ」バージョンの４つ以上の立方体面を網羅するタイルをクライアントが選択する一例を示しており、視認方向が変化した場合の段階的な画質変動を目的としている。
タイルトラック手法および抽出器主導手法は、具体的にＨＥＶＣの背景で詳細に説明されているにも関わらず、他のコーデックおよびタイルトラックまたは抽出器と同様の概念にも当てはまることを理解する必要がある。さらには、タイルトラック手法および抽出器主導手法の組み合わせまたは混合も可能である。たとえば、このような混合は、タイルトラック手法に基づくことも可能であるが、この場合、タイルベーストラックは、クライアントの書き換え操作のガイダンスを含むことも可能である。たとえば、タイルベーストラックは、書き換えられたスライスまたはタイル群ヘッダを含むことも可能である。
ＭＣＴＳベースのコンテンツエンコーディングの代替として、タイルベースの表示域に応じたストリーミングのコンテンツ生成は、後述のサブ画像ベースのコンテンツ生成により実現されるようになっていてもよい。（エンコーディングに先立つ）前処理には、未圧縮画像のサブ画像への分離を含む。たとえば同じ解像度の一方、異なる品質およびビットレートにおいて、同じ未圧縮サブ画像シーケンスの複数のサブ画像ビットストリームがエンコーディングされる。エンコーディングは、全方位ビデオを表す適合ビットストリームへのコード化サブ画像ビットストリームの結合が可能となるように制限されていてもよい。たとえば、画像外のサンプルの場所が相互予測プロセスにおいて参照されないように動きベクトルを選択することによって、デコード画像境界外のサンプルに対する依存がエンコーディングにおいて回避されるようになっていてもよい。各サブ画像ビットストリームがサブ画像トラックとしてカプセル化され得るとともに、異なるサブ画像の場所のサブ画像トラックを結合した１つまたは複数の抽出器トラックが追加で形成されるようになっていてもよい。タイルトラックベースの手法を対象とする場合は、各サブ画像ビットストリームがＭＣＴＳシーケンスとなるように修正され、タイルトラックとしてファイルに格納されるとともに、タイルトラックに対して１つまたは複数のタイルベーストラックが生成される。
タイルベースの表示域に応じたストリーミング手法は、単一のデコーダインスタンスまたはＭＣＴＳシーケンス当たり１つのデコーダインスタンス（または、場合によりその中間、たとえば、同じ解像度のＭＣＴＳ当たり１つのデコーダインスタンス）を実行することによって、たとえばプレーヤが動作している機器およびオペレーティングシステムの機能に応じて実現されるようになっていてもよい。単一のデコーダインスタンスの使用は、後期バインディングまたは初期バインディングによって有効となり得る。複数のデコーダインスタンスを容易化するため、抽出器主導手法では、修正なくコーディングフォーマットまたは規格に準拠するサブ画像トラックを使用するようにしてもよい。他の手法では、クライアント側でのイメージセグメントヘッダ、パラメータ集合、および／または類似の情報の書き換えによって適合するビットストリームを構成すること、または、他のコード化ビデオデータがなくてもＭＣＴＳシーケンスをデコーディング可能なデコーダを実装することが必要となり得る。
タイルトラック手法および抽出器主導手法のそれぞれにおいて、タイルトラックまたはサブ画像トラックをカプセル化して参照するための少なくとも２つの手法が存在し得る。
タイルベーストラックまたは抽出器トラックからのトラック識別子の参照。
タイルベーストラックまたは抽出器トラックからのタイル群識別子の参照（タイル群識別子により識別されるタイル群には、抽出の選択肢である同位置のタイルトラックまたはサブ画像トラックを含む）。
ＲＷＭＱ法においては、各画像サイズおよび各タイルグリッドごとに１つの抽出器トラックで十分である。３６０°＋表示域ビデオおよびＲＷＭＲビデオでは、各個別の視認方向に対して１つの抽出器トラックが必要となり得る。
次に、上述のタイルベースの表示域に応じたストリーミング手法と同様の手法（タイル長方形ベースのエンコーディングおよびストリーミングと称し得る）について説明する。この手法は、ＨＥＶＣと同様のタイルがコーデックで利用できない場合または動き制約タイル集合または同等のものがエンコーダに実装されていない場合であっても、任意のビデオコーデックで使用可能である。タイル長方形ベースのエンコーディングにおいては、エンコーディングの前に、ソースコンテンツがタイル長方形シーケンスに分割される。各タイル長方形シーケンスは、完全パノラマコンテンツ等のソースコンテンツの空間的エリアの部分集合を網羅するが、これは、たとえば正距円筒投影フォーマットであってもよい。その後、各タイル長方形シーケンスは、単一レイヤビットストリームとして互いに独立してエンコーディングされる。たとえば異なるビットレートに対して、同じタイル長方形シーケンスから複数のビットストリームがエンコーディングされるようになっていてもよい。各タイル長方形ビットストリームは、それ自体のトラック（または、類似物）としてファイルにカプセル化され、ストリーミングに利用可能となり得る。受信側では、ストリーミングされるトラックが視認方向に基づいて選択されるようになっていてもよい。クライアントは、全方位コンテンツ全体を網羅するトラックを受信するようにしてもよい。現在の表示域については、その他の現時点で見えない表示域を網羅する品質または解像度と比較して、より良い品質または高解像度のトラックが受信されるようになっていてもよい。一例において、各トラックは、別個のデコーダインスタンスによりデコーディングされるようになっていてもよい。
表示域適応ストリーミングにおいては、主表示域（すなわち、現在の視認方向）が良好な品質／解像度で伝送される一方、３６０°ビデオのその他の部分は、低い品質／解像度で伝送される。視認方向が変化した場合、たとえば、ヘッドマウントディスプレイでコンテンツを見る際にユーザが頭部の向きを変えた場合は、新たな視認方向に合わせた別のバージョンのコンテンツのストリーミングが必要となる。一般的に、この新たなバージョンは、通常（Ｓｕｂ）ｓｅｇｍｅｎｔと位置合わせされたストリームアクセスポイント（ＳＡＰ）を始点として要求可能である。単一レイヤビデオビットストリームにおいて、ＳＡＰは、ランダムアクセス画像に対応し、内部コーディングされているため、レート歪み性能の点でコスト高となる。このため従来は、秒オーダの比較的長いＳＡＰ区間ひいては比較的長い（Ｓｕｂ）ｓｅｇｍｅｎｔ持続時間が通常使用される。このため、視認方向の変化（たとえば、頭部の向きの変更）後の品質向上の遅延（ここでは、表示域品質更新遅延と称する）は、従来は秒オーダであるため、明らかに顕著で煩わしいものである。
通常の視認状況においては、視認方向が徐々に変化するため、独立コード化画像領域については、一部の場所だけ画質が変化する。たとえば、正距円筒投影に４×２のＭＣＴＳグリッドが用いられる場合は、半分のＭＣＴＳで画質が変化する可能性が高い。ランダムアクセス画像から始まるＳｅｇｍｅｎｔですべてのＭＣＴＳ位置を更新することは、ストリーミングレート歪み性能の点で非効率であり、ビットレートの大きな変動が発生する。これにより、再バッファリングのために再生が中断される可能性もあるし、十分に長い初期バッファリング遅延によって補償することも可能である。
独立コード化画像領域の部分集合のみがＩＲＡＰ画像に由来するように、結合ビットストリームの同じコード化画像中の異なる種類のコード化画像（たとえば、非ＩＲＡＰおよびＩＲＡＰ画像）に由来する独立コード化画像領域によって、表示域に応じた３６０°ストリーミングにおける視認方向の変化を取り扱い可能となり得ることが提案されている。これをサポートするため、ＶＶＣ Ｄｒａｆｔ ５では、ＩＤＲ画像のスライスヘッダに基準画像リストを示すことによって、使用事例を有効化する際にクライアントがＩＤＲ ＮＡＬ単位タイプをＴＲＡＩＬ ＮＡＬ単位タイプに変更できるようにする。
上記説明の通り、ＭＰＥＧ ＯＭＡＦに準拠し得る表示域に応じたストリーミングにおける表示域の切り替えは、内部コーディングひいては同じ品質で各相互コード化画像と比較して大きなビットレートを伴うストリームアクセスポイントにおいて有効化される。このため、ストリームアクセスポイント区間とレート歪み性能との妥協点がエンコーディング設定において選定される。
以下では、ＭＣＴＳを含む等解像度ＨＥＶＣビットストリームの表示域適応ストリーミングを一例として説明する。動き制約タイル集合を用いることにより、同じ全方位ソースコンテンツの複数のＨＥＶＣビットストリームが同じ解像度の一方、異なる品質およびビットレートでエンコーディングされるようになっていてもよい。すべてのビットストリーム中のＭＣＴＳグリッドは、同一である。異なる元のビットストリームから受信したＭＣＴＳからビットストリームを再構成するためにクライアントが同じタイルベーストラックを使用できるようにするため、各ビットストリームは、それ自身のファイルにカプセル化され、これらすべてのファイルにおいて、同じタイルグリッド位置の各タイルトラックに同じトラック識別子が使用される。ＨＥＶＣタイルトラックは、各動き制約タイル集合シーケンスから形成され、タイルベーストラックも追加で形成される。クライアントは、タイルベーストラックのパーシングによって、タイルトラックからビットストリームを暗示的に再構成するようにしてもよい。再構成ビットストリームは、適合するＨＥＶＣデコーダによってデコーディング可能である。
クライアントは、受信する各ＭＣＴＳのバージョンを選定可能である。異なるビットストリームからのＭＣＴＳを組み合わせる場合は、各タイルトラックで同じトラック識別子が使用されることから、同じタイルベーストラックで十分である。
図５は、タイルベースの全方位ビデオストリーミングに同じ解像度のタイルトラックを使用可能な方法の一例を示している。動き制約タイル集合の構成には、４×２タイルグリッドを使用している。同じソースコンテンツに由来する２つのＨＥＶＣビットストリームが異なる画質およびビットレートでエンコーディングされる。各ビットストリームは、それ自体のファイルにカプセル化されるようになっていてもよく、各動き制約タイル集合シーケンスが１つのタイルトラックに含まれ、タイルベーストラックも同様に含まれる。クライアントは、視認方向に基づいて、各タイルトラックを受信する品質を選定するようにしてもよい。本例において、クライアントは、特定の品質でタイルトラック１、２、５、および６を受信し、別の品質でタイルトラック３、４、７、および８を受信する。タイルベーストラックは、ＨＥＶＣデコーダによってデコーディング可能なビットストリームへと受信タイルトラックデータを並べるのに用いられる。
独立コード化画像領域を１つまたは複数のソースビットストリームから結合ビットストリームへと結合するには、パラメータ集合の書き換えが必要である。言い換えると、ソースビットストリーム中のパラメータ集合は、そのままでは適用不可能である。たとえば、結合ビットストリームにおける画像幅、画像高さ、ならびに／またはタイルおよびブリックへの画像分離は、ソースビットストリームのいずれとも異なる可能性がある。パラメータ集合の書き換えの結果として、以下が挙げられる。
デコーダ外のエンティティ（たとえば、プレーヤ）は、抽出および結合と関係のない部分を含めて、完全なパラメータ集合のパーシングおよび／または書き換えを行う必要がある。エンティティは、選択されたソースビットストリームからパラメータ集合を基準として取得し、パーシングを行い、パラメータ集合内の選択されたシンタックス要素の値を修正し、これらの修正によって、結合ビットストリーム中または結合ビットストリームに伴うパラメータ集合を書き換える可能性もある。
さらに、パラメータ集合は、結合ビットストリームにおいてサイズが変化した場合、ＨＲＤに影響を及ぼすとともに、（ＳＰＳおよびバッファリング期間ＳＥＩメッセージにおいて）ＨＲＤバッファリングパラメータを無効化する可能性もある。その結果、パラメータ集合の書き換えが規範的に規定されていない場合は、ＨＲＤ挙動に対する結合の影響を予測できない可能性もある。
ＩＤＲおよび非ＩＤＲ画像からの独立コード化領域を結合する場合、デコーダは、このような「混合画像」が基準画像マーキングに対する非ＩＤＲ画像のように処理されるものと決定する必要がある。ある手法においては、「混合画像指標」がＰＰＳにおいて提供される。ただし、混合が起こっているものでなく他の画像にＰＰＳが用いられる場合、この手法では、新たなＰＰＳを生成するとともに、スライスヘッダのＰＰＳ ＩＤ値を書き換える必要がある。別の手法においては、デコーディングプロセスにおける外部制御変数の使用によって「混合画像」を示す。ただし、このような外部変数に対するデコーダＡＰＩは、存在していない可能性もあるし、動作環境に応じて異なる可能性もある。
たとえば領域単位でパッキングされた３６０°ビデオおよび／またはボリュメトリックビデオ（３ＤｏＦ＋、６ＤｏＦ、および点群ビデオ）のレンダリングには、画像同期メタデータが必要となる可能性もある。たとえば、パッチメタデータおよび／または領域単位のパッキングが画像に基づいて変化し得る。一部のオペレーティングシステムおよび／またはデバイスアーキテクチャにおいては、プレーヤがメタデータを画像同期してレンダリングプロセスに受け渡せない可能性もあり、むしろ、ビデオデコーダのみがこれを実行可能な場合もある。これは、任意のビデオ（非暗号化および暗号化の両者）に適用される可能性もあるし、暗号化ビデオにのみ適用される可能性もある。ただし、一般的にはこれが決まっておらず、ビデオデコーダが画像同期してデコード画像とともに出力として受け渡すべきメタデータ（たとえば、ＳＥＩメッセージ）には制御が及ばない。メタデータの一部は、ビデオデコーディング仕様の第１のバージョンでは規定されていない可能性もあるが、それにも関わらず、第１のバージョンに係るデコーダは、デコード画像と併せてメタデータを出力として受け渡し可能であるものとする。現在、ビデオコーディング規格は、デコード画像の出力のみを規定している。メタデータの出力については、規範的に規定されていない。
特定の時間インスタンスにおける視覚コンテンツを複数の部分に分割可能であり、各部分がサブ画像を用いて表される。異なる時間インスタンスにおけるそれぞれのサブ画像がサブ画像シーケンスを構成する。この「それぞれ（ｒｅｓｐｅｃｔｉｖｅ）」の定義は、状況によって決まり得るが、たとえば一連の画像中の画像エリアの同じ空間的部分または同じ取得位置、方向、および投影面等の同じ設定で取得されたコンテンツが挙げられる。特定の時間インスタンスにおける画像は、当該特定の時間インスタンスにおけるすべてのサブ画像の集まりとして規定され得る。各サブ画像は、従来のビデオエンコーダによってコーディングされ、サブ画像シーケンスに対応する再構成サブ画像メモリに再構成サブ画像が格納される。特定のサブ画像シーケンスにおけるサブ画像を予測するため、エンコーダは、同じサブ画像シーケンスの再構成サブ画像を予測の基準として使用することができる。コード化サブ画像は、別個の単位（たとえば、ＶＣＬ ＮＡＬ単位）として同じビットストリームに含まれる。
デコーダは、コード化ビデオデータ（たとえば、ビットストリーム）を受信する。従来のビデオデコーダを使用することにより、他のサブ画像とは別個の単位としてサブ画像がデコーディングされる。デコードサブ画像は、デコード画像バッファリングプロセスによってバッファリングされるようになっていてもよい。デコード画像バッファリングプロセスは、特定のサブ画像シーケンスのデコードサブ画像をデコーダに与え、デコーダは、デコードサブ画像を予測の基準として使用することにより、同じサブ画像シーケンスにおいてサブ画像を予測するようにしてもよい。
１つもしくは複数の基準サブ画像またはその中の領域のサブ画像パッキングには、（エンコーダにより情報の一部として示される）以下のうちの１つまたは複数を含んでいてもよいが、これらに限定されない。
回転、たとえば、０、９０、１８０、または２７０°
ミラーリング、たとえば、水平または垂直
再サンプリング（たとえば、幅および／または高さの再スケーリング）
操作基準サブ画像のエリア内の位置
操作基準サブ画像の指定エリア（たとえば、操作基準サブ画像に配置済みのサブ画像または領域が占有する）内に既に存在するサンプルとの重ね合わせ（すなわち、上書き）または混ぜ合わせ。上書きは、サブ画像のうちの１つ／一部が高品質にコーディングされる場合に有用となり得る。
３６０°ビデオの形状パディングには、たとえばサブ画像中の立方体面と同じ平面上に投影された隣接立方体面からの立方体面パディングを含んでいてもよい。
ボリュメトリックビデオコーディング（たとえば、点群コーディング）においては、イメージパディング要素によって形状イメージおよび／またはテクスチャイメージがパディングされるようになっていてもよい。パディングは、パッチ間の空スペースを満たして、ビデオ圧縮に適した滑らかな分割イメージを生成することを目的とする。イメージパディング要素は、圧縮を高く維持することのほか、元の占有状態マップ（ＯＯＭ）と比較して十分な精度での占有状態マップの推定（ＥＯＭ）を可能にすることを考慮し得る。
一手法によれば、以下のパディング方法を使用可能である。
Ｔ×Ｔ（たとえば、１６×１６）の各ブロックが独立して処理される。ブロックが空の場合（すなわち、そのすべてのピクセルが空スペースに属する場合）は、ラスター順序の先行Ｔ×Ｔブロックの最後の行または列のコピーによって、ブロックのピクセルが充足される。ブロックが充足されている場合（すなわち、空ピクセルがない場合）は、何も実行されない。ブロックが空ピクセルおよび充足ピクセルの両者を有する場合は、空ピクセルがそれぞれの空ではない隣接ピクセルの平均値によって反復的に充足される。
生成されたイメージ／レイヤは、ビデオフレームとして格納され、圧縮されるようになっていてもよい。たとえば、パディング形状イメージおよびパディングテクスチャイメージがビデオ圧縮要素に提供されてパディング形状イメージおよびパディングテクスチャイメージを圧縮し、圧縮形状イメージおよび圧縮テクスチャイメージは、たとえば入力データを圧縮ビットストリームとして多重化する多重化器に提供される。
また、圧縮形状イメージおよび圧縮テクスチャイメージは、たとえば推定占有状態マップを生成する占有状態マップ推定器に提供される。
このステップにおいては、形状イメージおよび／またはテクスチャイメージの境界を見つけるアルゴリズムが用いられるようになっていてもよい。なお、境界は一般的に、エンコーディングに先立って互いに位置合わせされている。ただし、おそらくエンコーディング後は、縁部のビット位置がずれるが、これは、元の占有状態マップに基づいて後続ステップで補正され得る。
占有状態マップは、グリッドの各セルについて、空スペースに属するか点群に属するかを示すバイナリマップから成っていてもよい。イメージ生成プロセスにおいては、２Ｄグリッドの１つのセルが１ピクセルを生成することになる。
推定占有状態生成ステップにおいては、パディングステップにおいて用いられる実施形態に基づいて、各パディング形状のＹ、Ｕ、および／またはＶコンポーネント間の異なるプロセスが考えられ得る。このようなプロセスに基づいて、縁部の推定（すなわち、占有状態マップを規定する輪郭）が生成されることになる。このような推定は、占有状態マップの推定に２つ以上のコンポーネント／イメージが使用される場合に微調整されるようになっていてもよい。
縁部検出アルゴリズムの一例は、マルチスケール縁部検出アルゴリズムであるが、これは、ウェーブレット領域ベクトル隠れマルコフツリーモデルに基づく。ただし、この背景においては、他の何らかのアルゴリズムが適用されるようになっていてもよい。
パディングにおいては、操作基準サブ画像のパディングエリアのコンテンツが他のサブ画像から生成されるようになっていてもよい。たとえば、関心領域コーディングにおいて、第１のサブ画像が第２のサブ画像よりも大きなエリアを表し得る場合、第２のサブ画像の操作基準は、第１のサブ画像中のコンテンツを用いてパディングされるようになっていてもよい。
基準パッチ再投影においては、基準サブ画像が３Ｄ点群パッチとして解釈され、３Ｄ点群パッチが２Ｄ相互予測に適した平面に再投影されるようになっていてもよい。
ＭＰＥＧ規格の場合は、点群圧縮に対するテストモデルが開発されている。ＭＰＥＧ Ｗ１７２４８は、ＭＰＥＧ点群コーディングに対するテストモデルを開示することにより、動的な点群圧縮の標準化方法を提供している。ＭＰＥＧ Ｗ１７２４８テストモデルにおいては、動きイメージ、テクスチャイメージ、および深度／属性イメージという３つのイメージデータに関して、２Ｄ投影３Ｄ体積表面が決定される。
点群再サンプリングブロックにおいて、入力３Ｄ点群フレームは、基準点群フレームに基づいて再サンプリングされる。フレーム間エンコーディング／デコーディングプロセスにおいては、３Ｄ動き補償ブロックが使用される。これは、基準点群およびその変形バージョンの位置の差を演算する。得られる動きフィールドは、基準フレームの点と関連付けられた３Ｄ動きベクトル｛ＭＶ＿ｉ（ｄｘ，ｄｙ，ｄｚ）｝＿ｉから成る。基準フレームの３Ｄから２Ｄへのマッピングによって、ｄｘをＹ、ｄｙをＵ、ｄｚをＶとして格納することにより動きフィールドが２Ｄイメージに変換されるが、この２Ｄイメージを動きイメージと称し得る。また、動きイメージの各ブロックの倍率を与えるスケールマップがエンコーディングされる。
イメージ生成プロセスでは、パッキングプロセスにおいて演算された３Ｄから２Ｄへのマッピングを利用することにより、点群の形状／テクスチャ／動きをイメージとして格納する。これらのイメージは、ビデオフレームとして格納され、ＨＥＶＣエンコーダ等のビデオエンコーダにより圧縮される。生成されるビデオは、以下のような特性を有し得る。
形状：Ｗ×Ｈ ＹＵＶ４２０－８ビット
テクスチャ：Ｗ×Ｈ ＹＵＶ４２０－８ビット
動き：Ｗ×Ｈ ＹＵＶ４４４－１０ビット
１つまたは複数のテクスチャおよび深度ビューを表すサブ画像から、ビュー合成（深度イメージベースのレンダリングとしても知られる）が実行されるようになっていてもよい。
深度イメージベースのレンダリング（ＤＩＢＲ）すなわちビュー合成は、１つまたは複数の既存／受信ビューに基づく新規ビューの生成を表す。深度イメージは、仮想ビューの補正合成の補助として使用可能である。詳細には異なるが、ビュー合成アルゴリズムのほとんどは、明示的な形状すなわち深度イメージに基づく３Ｄワーピングを利用し、通常、各テクスチャピクセルは、カメラからテクスチャピクセルがサンプリングされた物体までの距離またはＺ値を示す深度ピクセルと関連付けられている。ある既知の手法では、３Ｄワーピングの非ユークリッド公式を用いるが、これは、カメラパラメータが未知またはカメラ校正が不十分な条件下で効率的である。ただし、さらに他の既知の手法では、取得およびビュー補間のためのカメラパラメータが既知であることを前提として、ユークリッド公式に厳密に従う。さらに、他の手法において、ビュー合成の目的は、カメラで撮影したようなビューを推定することではなく、主観的に好ましいコンテンツの表現を提供することであり、異なる物体に対する非線形視差調整を含む場合がある。
オクルージョン、ピンホール、および再構成誤差が３Ｄワーピングプロセスにおいて導入される最も一般的なアーチファクトである。これらのアーチファクトは、物体の縁部でより頻繁に発生するが、その縁部では、深度レベルの異なるピクセルが仮想イメージの同じピクセル位置にマッピングされている場合もある。これらのピクセルを平均化することにより、仮想イメージのピクセル位置の最終ピクセル値を再構成する場合には、アーチファクトが発生する可能性もある。深度レベルの異なるピクセルは通例、異なる物体に属するためである。
補助深度マップビデオストリームの使用を含めて、深度画像シーケンスを表す多くの手法が提案されている。単一ビューの深度マップビデオシーケンスは、通常の単色ビデオストリームと見なすことができ、任意のビデオコーデックによりコーディング可能である。たとえばＭＰＥＧ－Ｃ Ｐａｒｔ ３規格に従ってフォーマット化されたメッセージにおいて、世界座標における最小および最大深度等、深度マップストリームの一部の特性を示すことができる。
ビュー合成アルゴリズムの詳細な動作は、テクスチャビューおよび深度画像シーケンスに使用された表現フォーマットによって決まる。
再サンプリングは、（より高い解像度への切り替えのための）アップサンプリングであってもよいし、（より低い解像度への切り替えのための）ダウンサンプリングであってもよい。再サンプリングは、以下の使用事例のうちの１つまたは複数に使用され得るが、これらに限定されない。
適応解像度変更であって、この場合は、画像に通常、１つのサブ画像しか含まない。
混合解像度マルチビュービデオまたはイメージコーディングであって、この場合は、サブ画像シーケンスがビューに対応する。ビュー間予測は、（第１のサブ画像シーケンスの）第１のサブ画像から（第２のサブ画像シーケンスの）第２のサブ画像への予測を有効化することにより実行可能であり、第１および第２のサブ画像は、同じ時間インスタンスのものであってよい。場合によっては、（たとえば、出力画像合成においてサブ画像を左右または上下に配置するために）ビューのうちの１つを回転させることが有益となり得る。このため、再サンプリングには（たとえば、９０、１８０、または２７０°の）回転を伴う場合もある。
色域変換：たとえば、ソースとして用いられるあるサブ画像がＩＴＵ－Ｒ ＢＴ．７０９等の第１の色域またはフォーマットにより表され、操作基準サブ画像がＩＴＵ－Ｒ ＢＴ．２０２０等の第２の色域またはフォーマットで表される場合、このソースとして用いられるサブ画像は、プロセスの一部として、第２の色域またはフォーマットに変換されるようになっていてもよい。
ダイナミックレンジ変換および／または色マッピング変換：色マッピングは、サンプル値の線形光表現へのマッピングを表し得る。操作基準サブ画像を生成するソースとして用いられる再構成サブ画像は、目標ダイナミックレンジおよび色マッピングに変換されるようになっていてもよい。
ビット深度変換において、操作基準サブ画像を生成するソースとして用いられる再構成サブ画像は、操作基準サブ画像のビット深度に変換されるようになっていてもよい。
彩度フォーマット変換：たとえば、操作基準サブ画像が彩度フォーマットＹＵＶ ４：４：４を有する一方、操作基準サブ画像を生成するソースとして用いられる少なくとも一部の再構成サブ画像は、彩度フォーマット４：２：０を有していてもよい。本例において、ソースとして用いられるサブ画像は、プロセスの一部としてＹＵＶ ４：４：４へとアップサンプリングされるようになっていてもよい。
投影変換：たとえば、あるサブ画像がＥＲＰ等の第１の投影で、操作サブ画像がＣＭＰの第２の投影である場合、このサブ画像は、基準として使用され、第２の投影へと変換されるようになっていてもよい。使用事例としては、全３６０°コンテンツが低解像度でＥＲＰフォーマットにコーディングされてもよく、表示域コンテンツが高解像度でＣＭＰフォーマットにコーディングされるようになっていてもよい。
フレームレート変換：たとえば、あるサブ画像が第１のフレームレートでコーディングされ、第２のサブ画像が第２のフレームレートでコーディングされ得る場合、上記サブ画像は、基準として使用され、時間領域において第２のサブ画像の時間インスタンスに合わせて補間されるようになっていてもよい。使用事例としては、立体視ストリーミングにおいて、主要ビューが高いフレームレートで伝送されてもよく、補助ビューが低いフレームレートで伝送されるようになっていてもよい。
以下の定義は、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ規格に関するものであってもよいが、他のコーデックにも適用可能である。独立レイヤは、直接的な基準レイヤを持たないレイヤである。すなわち、レイヤ間予測が行われない。非ベースレイヤは、すべてのＶＣＬ ＮＡＬ単位が０より大きな同じｎｕｈ＿ｌａｙｅｒ＿ｉｄ値を有するレイヤである。独立非ベースレイヤは、独立レイヤかつ非ベースレイヤである。
以下では、サブビットストリーム抽出プロセスの一例について簡単に説明する。ビットストリームｉｎＢｉｔｓｔｒｅａｍの独立非ベースレイヤから、以下のようにビットストリームｏｕｔＢｉｔｓｔｒｅａｍを生成可能である。ビットストリームｏｕｔＢｉｔｓｔｒｅａｍは、ビットストリームｉｎＢｉｔｓｔｒｅａｍと同一になるように設定される。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＳＰＳ＿ＮＵＴ、ＰＰＳ＿ＮＵＴ、およびＥＯＢ＿ＮＵＴに等しくなく、ｎｕｈ＿ｌａｙｅｒ＿ｉｄがａｓｓｉｇｎｅｄＢａｓｅＬａｙｅｒＩｄに等しくないＮＡＬ単位は、ｏｕｔＢｉｔｓｔｒｅａｍから除去される。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＳＰＳ＿ＮＵＴまたはＰＰＳ＿ＮＵＴにも等しく、ｎｕｈ＿ｌａｙｅｒ＿ｉｄが０にもａｓｓｉｇｎｅｄＢａｓｅＬａｙｅｒＩｄにも等しくないＮＡＬ単位は、ｏｕｔＢｉｔｓｔｒｅａｍから除去される。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＶＰＳ＿ＮＵＴに等しいＮＡＬ単位は、ｏｕｔＢｉｔｓｔｒｅａｍから除去される。ＴｅｍｐｏｒａｌＩＤがｔＩｄＴａｒｇｅｔよりも大きなＮＡＬ単位はすべて、ｏｕｔＢｉｔｓｔｒｅａｍから除去される。ｏｕｔＢｉｔｓｔｒｅａｍの各ＮＡＬ単位においては、ｎｕｈ＿ｌａｙｅｒ＿ｉｄが０に等しく設定される。ビットストリームｏｕｔＢｉｔｓｔｒｅａｍは、ＨＥＶＣデコーディングプロセスによってデコーディング可能である。
以下では、レイヤ特性を示すＨＥＶＣのビデオパラメータ集合（ＶＰＳ）の一例について簡単に説明する。ビデオパラメータ集合は、拡張部を含むが、その一部を以下に示す。
Figure 0007492978000006
ＨＥＶＣのビデオパラメータ集合は、レイヤに使用されるスケーラビリティの種類を示すスケーラビリティマスクを規定する。
ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ＿ｆｌａｇ［ｉ］＝１は、表Ｆ．１のｉ番目のスケーラビリティ次元に対応するｄｉｍｅｎｓｉｏｎ＿ｉｄシンタックス要素が存在することを示す。ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ＿ｆｌａｇ［ｉ］＝０は、ｉ番目のスケーラビリティ次元に対応するｄｉｍｅｎｓｉｏｎ＿ｉｄシンタックス要素が存在しないことを示す。
Figure 0007492978000007
ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］は、ｉ番目のレイヤのＶＣＬ ＮＡＬ単位のｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素の値を規定する。ｉが０より大きい場合、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］は、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ－１］より大きいものとする。０～ＭａｘＬａｙｅｒｓＭｉｎｕｓ１の範囲のｉの任意の値に関して、存在しない場合、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］の値は、ｉに等しいものと推測される。
０～ＭａｘＬａｙｅｒｓＭｉｎｕｓ１のｉに関して、変数ＬａｙｅｒＩｄｘＩｎＶｐｓ［ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］］は、ｉに等しく設定される。
ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］は、ｉ番目のレイヤのｊ番目に存在するスケーラビリティ次元の種類の識別子を規定する。ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］の表現に用いられるビットの数は、ｄｉｍｅｎｓｉｏｎ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１［ｊ］＋１ビットである。
ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇに応じて、以下が適用される。ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが１に等しい場合、０～ＭａｘＬａｙｅｒｓＭｉｎｕｓ１のｉおよび０～ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ－１のｊについて、ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］は、（（ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］＆（（１＜＜ｄｉｍＢｉｔＯｆｆｓｅｔ［ｊ＋１］）－１））＞＞ｄｉｍＢｉｔＯｆｆｓｅｔ［ｊ］）に等しいものと推測される。ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが１に等しくない場合（ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが０に等しい場合）、０～ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ－１のｊについて、ｄｉｍｅｎｓｉｏｎ＿ｉｄ［０］［ｊ］は、０に等しいものと推測される。
ｉ番目のレイヤのｓｍＩｄｘ番目のスケーラビリティ次元の種類の識別子を規定する変数ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［ｓｍＩｄｘ］ならびにｎｕｈ＿ｌａｙｅｒ＿ｉｄがｌＩｄに等しいレイヤの深度フラグ、ビュー順序インデックス、空間／品質スケーラビリティ識別子、および補助識別子をそれぞれ指定する変数ＤｅｐｔｈＬａｙｅｒＦｌａｇ［ｌＩｄ］、ＶｉｅｗＯｒｄｅｒＩｄｘ［ｌＩｄ］、ＤｅｐｅｎｄｅｎｃｙＩｄ［ｌＩｄ］、およびＡｕｘＩｄ［ｌＩｄ］は、以下のように導出されるようになっていてもよい。
ＮｕｍＶｉｅｗｓ＝１
ｆｏｒ（ｉ＝０；ｉ＜＝ＭａｘＬａｙｅｒｓＭｉｎｕｓ１；ｉ＋＋）｛
ｌＩｄ＝ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］
ｆｏｒ（ｓｍＩｄｘ＝０，ｊ＝０；ｓｍＩｄｘ＜１６；ｓｍＩｄｘ＋＋）｛
ｉｆ（ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ＿ｆｌａｇ［ｓｍＩｄｘ］）
ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［ｓｍＩｄｘ］＝ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ＋＋］
ｅｌｓｅ
ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［ｓｍＩｄｘ］＝０
｝
ＤｅｐｔｈＬａｙｅｒＦｌａｇ［ｌＩｄ］＝ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［０］
ＶｉｅｗＯｒｄｅｒＩｄｘ［ｌＩｄ］＝ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［１］
ＤｅｐｅｎｄｅｎｃｙＩｄ［ｌＩｄ］＝ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［２］ （Ｆ－３）
ＡｕｘＩｄ［ｌＩｄ］＝ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［３］
ｉｆ（ｉ＞０）｛
ｎｅｗＶｉｅｗＦｌａｇ＝１
ｆｏｒ（ｊ＝０；ｊ＜ｉ；ｊ＋＋）
ｉｆ（ＶｉｅｗＯｒｄｅｒＩｄｘ［ｌＩｄ］＝＝ＶｉｅｗＯｒｄｅｒＩｄｘ［ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｊ］］）
ｎｅｗＶｉｅｗＦｌａｇ＝０
ＮｕｍＶｉｅｗｓ＋＝ｎｅｗＶｉｅｗＦｌａｇ
｝
｝
出力レイヤ集合（ｏｕｔｐｕｔ ｌａｙｅｒ ｓｅｔ（ＯＬＳ））は、１つまたは複数のレイヤが出力レイヤとして規定される一組のレイヤとして定義可能である。（出力レイヤ集合の）出力レイヤは、当該出力レイヤ集合がデコーディングされる場合に出力されるレイヤとして規定されていてもよい。出力レイヤの画像は、それに対して指定または推測される出力フラグが１に等しい場合、デコーダによって出力される。その他の場合は、画像がデコーダにより出力されない場合がある。出力レイヤ集合は、ＶＰＳにおいて規定されていてもよい。
サブビットストリーム抽出プロセス（ｓｕｂ－ｂｉｔｓｔｒｅａｍ ｅｘｔｒａｃｔｉｏｎ ｐｒｏｃｅｓｓ）は、たとえば目標ＯＬＳインデックスおよび目標最高ＴｅｍｐｏｒａｌＩｄによって決まる目標集合に属さないビットストリーム中のＮＡＬ単位がビットストリームから除去され、出力サブビットストリームが、目標集合に属するビットストリーム中のＮＡＬ単位から成る規定の処理として定義可能である。
特定の時間インスタンスにおける視覚コンテンツが複数の部分に分割され、各部分がサブ画像を用いて表される。異なる時間インスタンスにおけるそれぞれのサブ画像がサブ画像シーケンスを構成する。この「それぞれ（ｒｅｓｐｅｃｔｉｖｅ）」の定義は、状況によって決まり得るが、たとえば一連の画像中の画像エリアの同じ空間的部分または同じ取得位置、方向、および投影面等の同じ設定で取得されたコンテンツが挙げられる。特定の時間インスタンスにおける画像は、当該特定の時間インスタンスにおけるすべてのサブ画像の集まりとして規定され得る。各サブ画像は、従来のビデオエンコーダによってコーディングされ、サブ画像シーケンスに対応する再構成サブ画像メモリに再構成サブ画像が格納される。特定のサブ画像シーケンスにおけるサブ画像を予測するため、エンコーダは、同じサブ画像シーケンスの再構成サブ画像を予測の基準として使用することができる。コード化サブ画像は、別個の単位（たとえば、ＶＣＬ ＮＡＬ単位）として同じビットストリームに含まれる。
デコーダは、コード化ビデオデータ（たとえば、ビットストリーム）を受信する。従来のビデオデコーダを使用することにより、他のサブ画像とは別個の単位としてサブ画像がデコーディングされる。デコードサブ画像は、デコード画像バッファリングプロセスによってバッファリングされるようになっていてもよい。デコード画像バッファリングプロセスは、特定のサブ画像シーケンスのデコードサブ画像をデコーダに与え、デコーダは、デコードサブ画像を予測の基準として使用することにより、同じサブ画像シーケンスにおいてサブ画像を予測するようにしてもよい。
図６は、デコーダの一例を示している。デコーダは、コード化ビデオデータ（たとえば、ビットストリーム）を受信する。デコーディングプロセス６１０においては、従来のビデオデコーダを使用することにより、他のサブ画像とは別個の単位としてサブ画像がデコーディングされる。デコードサブ画像は、デコード画像バッファリングプロセスによってバッファリングされるようになっていてもよい（６２０）。デコード画像バッファリングプロセスは、特定のサブ画像シーケンスのデコードサブ画像をデコーディングプロセス６１０に与えてもよく、デコーダは、デコードサブ画像を予測の基準として使用することにより、同じサブ画像シーケンスにおいてサブ画像を予測するようにしてもよい。
デコード画像バッファリングプロセス６２０は、サブ画像シーケンス単位バッファリング６３０を含んでいてもよく、これは、再構成サブ画像の「参照使用」または「参照不使用」としてのマーキングのほか、再構成サブ画像がデコーダから出力されたかの記録をとることを含んでいてもよい。サブ画像シーケンスのバッファリングは、互いに独立していてもよいし、以下の方法のうちの一方または両方において同期されるようになっていてもよい。
同じ時間インスタンスのすべての再構成サブ画像の出力が同期して実行されるようになっていてもよい。
同じ時間インスタンスの再構成サブ画像の基準画像マーキングが同期して実行されるようになっていてもよい。
デコード画像バッファリングプロセスは、画像合成データを入力として取得し、再構成サブ画像を出力画像として配置する出力画像合成プロセスを含んでいてもよい。図６は、２つのサブ画像シーケンスに関する従来例を引き継ぎ、時間合わせされた再構成サブ画像を出力画像として左右に配置する。この例は、高さが同じで幅が異なる２つのサブ画像シーケンスのデコーディングを示している。サブ画像シーケンスの数および／またはサブ画像の寸法が異なる選定も可能であり、これらの選定があくまで一例に過ぎないことを理解する必要がある。
一例によれば、デコーダからの出力には、異なる別個のデコードサブ画像の集まりを含む。
図７に示す別の例によれば、デコーディングプロセス８１０からの出力画像（上記の追加または代替として、デコード画像とも称し得る）は、異なる別個のサブ画像の集まりである。別の例によれば、出力画像は、再構成サブ画像を２次元（２Ｄ）画像として配置することにより構成される。本例では、（時間インスタンス当たり）単一の出力画像に関する従来の設計をビデオデコーダの出力として維持するため、システムへの組み込みが容易となり得る。デコードサブ画像は、デコードサブ画像バッファリング８１２に提供される。その後、デコーディングプロセス８１０では、後続画像をデコーディングする基準として、バッファリングサブ画像を使用するようにしてもよい。このデコーディングプロセスでは、操作サブ画像を生成するソースとして使用されるデコードサブ画像を指定するようにしてもよいし、推測するようにしてもよい。これらのサブ画像は、基準サブ画像操作プロセス８１６に提供される（８１４）。その後、操作基準サブ画像は、デコードサブ画像バッファリング８１２に提供され（８１８）、バッファリングされる。その後、サブ画像および操作基準サブ画像は、画像合成データを入力として取得し、再構成サブ画像を出力画像として配置する出力画像合成プロセス８２０により使用されるようになっていてもよい。エンコーダは、画像合成データをビットストリーム中またはビットストリームとともにエンコーディングするが、この画像個合成データは、出力画像を構成する２Ｄ画像として再構成サブ画像が配置される方式を示す。デコーダは、ビットストリームから、または、ビットストリームに伴う画像合成データをデコーディングし、このデコード画像合成データに従って、再構成サブ画像および／または操作基準サブ画像から出力画像を構成する（８２０）。デコーディングまたは画像合成データは、出力画像合成プロセス８２０の一部として発生するようになっていてもよいし、任意選択として、出力画像合成プロセス８２０とつながっていてもよい。これにより、従来のビデオデコーディングプロセスで画像合成データをデコーディングする。
一例によれば、画像合成データは、サブ画像のビットストリームもしくはデコーディング順序ならびにサブ画像の寸法を用いて、ビットストリーム中のエンコーディングもしくはビットストリームに伴うエンコーディングならびに／またはビットストリームからのデコーディングもしくはビットストリームに伴うデコーディングが行われる。エンコーダおよび／またはデコーダにおいては、画像エリア内のサブ画像の位置決めのアルゴリズムが後続するが、このアルゴリズムには、サブ画像がそれぞれのビットストリームまたはデコーディング順序で入力される。一例によれば、画像エリア内のサブ画像の位置決めのアルゴリズムは、以下の通りである。すなわち、画像が複数のサブ画像を含み、画像のエンコーディングおよび／またはコード化画像のデコーディングが開始となった場合は、再構成またはデコード画像中の各ＣＴＵ位置が占有されていないものとしてマーキングされる。ビットストリームまたはデコーディング順序の各サブ画像について、このサブ画像は、画像境界内にサブ画像を収めるのに十分な大きさの画像内において、ＣＴＵラスタースキャン順序の次のそのような未占有位置を取得する。
一例によれば、エンコーダは、ビットストリーム中またはビットストリームに伴って、
デコーダが異なる別個のデコードサブ画像の集まりを出力しようとしているか、
デコーダが画像合成データに従って出力画像を生成しようとしているか、
デコーダが上記選択肢のいずれかを実行可能であるか、
を示す。
一例によれば、デコーダは、ビットストリームから、または、ビットストリームに伴って、
デコーダが異なる別個のデコードサブ画像の集まりを出力しようとしているか、
デコーダが画像合成データに従って出力画像を生成しようとしているか、
デコーダが上記選択肢のいずれかを実行可能であるか、
をデコーディングする。
デコーダは、上記デコード意図または許可に適合するように、その動作を適応させる。
一例によれば、デコーダは、異なる別個のデコードサブ画像の集まりの出力または画像合成データに応じた出力画像の生成を少なくとも選択するインターフェースを具備する。デコーダは、インターフェースを通じて示された内容に適合するように、その動作を適応させる。
一例によれば、画像は、サブ画像、タイル群、およびタイルに分割される。タイルは、ＨＥＶＣタイルと同様に規定され得るため、画像の長方形領域を網羅する一連のＣＴＵとして定義可能である。上述の通り、ラスタースキャン順序のタイル群および長方形タイル群等、複数種類のタイル群がコーディングフォーマットで利用可能であってもよく、エンコーダは、使用する種類を選択するようにしてもよい。ラスタースキャン順序のタイル群は、サブ画像内のタイルラスタースキャンにおける一連のタイルとして定義可能である。長方形タイル群は、サブ画像内の長方形のタイル群として定義可能である。ＶＣＬ ＮＡＬ単位には厳密に１つのタイル群を含むこと、すなわち、１つのタイル群が厳密に１つのＶＣＬ ＮＡＬ単位に含まれることが規定されていてもよい。サブ画像は、長方形の一組の１つまたは複数のタイル群全体として定義可能である。一例によれば、画像は、サブ画像に分離される。すなわち、画像全体がサブ画像に占有されるため、画像内に未占有エリアは存在しない。別の例によれば、画像は、サブ画像ならびに１つもしくは複数の未占有エリアを含む。
一例によれば、サブ画像の１つまたは複数のタイル分離を示す情報は、エンコーダによるビットストリーム中のエンコーディングもしくはビットストリームに伴うエンコーディングならびに／またはデコーダによるビットストリームからのデコーディングもしくはビットストリームに伴うデコーディングが行われる。タイル分離は、たとえばタイル列およびタイル行それぞれの幅および高さとして規定されたタイルグリッドであってもよい。特定のサブ画像またはサブ画像シーケンスに適用されるタイル分離は、エンコーダによるビットストリーム中のエンコーディングもしくはビットストリームに伴うエンコーディングならびに／またはデコーダによるビットストリームからのデコーディングもしくはビットストリームに伴うデコーディングが行われる。一例によれば、タイル分離を記述したシンタックス要素は、画像パラメータ集合へのエンコーディングおよび／または画像パラメータ集合からのデコーディングが行われ、たとえばタイルグループヘッダ中のＰＰＳ識別子によって、ＰＰＳがサブ画像に対してアクティブ化される。各サブ画像は、それ自体のＰＰＳを表し得るため、それ自体のタイル分離を有していてもよい。たとえば、図１０は、４つのサブ画像に分割された画像を示している。各サブ画像は、それ自体のタイルグリッドを有していてもよい。本例においては、幅および高さの等しい３×２タイルのグリッドにサブ画像１が分割され、ＣＴＵの高さが３および５の２×１タイルにサブ画像２が分割される。サブ画像３および４はそれぞれ、タイルを１つだけ有する。サブ画像１は、それぞれ１つ、３つ、および２つのタイルを含む３つのタイル群を有する。サブ画像２、３、および４はそれぞれ、タイル群を１つ有する。
また、図１０は、画像エリア内でサブ画像を位置決めする上述のアルゴリズムを示している。サブ画像１は、デコーディング順序の最初であるため、画像エリアの左上隅に配置されている。サブ画像２は、デコーディング順序の２番目であるため、ラスタースキャン順序の次の未占有位置に配置されている。このアルゴリズムは、デコーディング順序の３番目および４番目のサブ画像すなわちサブ画像３および４についてもそれぞれ同様に動作する。サブ画像のデコーディング順序は、画像境界外の番号（１、２、３、４）により示される。
一例によれば、サブ画像内の１つまたは複数のタイル位置を示す情報は、たとえばタイル群ヘッダ等のイメージセグメントヘッダにおいて、エンコーダによるビットストリーム中のエンコーディングおよび／またはデコーダによるビットストリームからのデコーディングが行われる。たとえば、イメージセグメントまたはタイル群のうち、デコーディング順序の最初のタイルのタイル位置のエンコーディングおよび／またはデコーディングが行われるようになっていてもよい。一例によれば、デコーダは、イメージセグメントまたはタイル群の最初のタイルがサブ画像の左上タイルである場合（たとえば、タイルのラスタースキャン順序において、０に等しいタイルアドレスまたはタイルインデックスを有する場合）、現在のイメージセグメントまたはタイル群がサブ画像の最初のイメージセグメントまたはタイル群であるものと決定する。一例によれば、最初のイメージセグメントまたはタイル群の決定に関して、デコーダは、新たなアクセス単位が開始となるかを判定する。一例によれば、画像順序カウント値または画像順序カウントと関連するシンタックス要素値（画像順序カウントの最下位ビット）が先行サブ画像と異なる場合は、新たなアクセスが開始になるものと判定される。
一例によれば、デコード画像バッファリングは、サブ画像ではなく画像に基づいて実行される。エンコーダおよび／またはデコーダは、画像合成データを用いて、同じアクセス単位または時間インスタンスのデコードサブ画像から基準画像を生成する。基準画像の生成は、出力画像を生成する他の例での説明と同一または同様に実行される。サブ画像のエンコーディングおよび／またはデコーディングにおいて基準画像が参照される場合は、デコード画像バッファ中の基準画像から、現在のサブ画像と同位置のエリアを抽出することによって、サブ画像をエンコーディングおよび／またはデコーディングするための基準サブ画像が生成される。このため、デコーディングプロセスでは、他の例と同様に、デコード画像バッファリングプロセスから基準サブ画像を取得するとともに、他の例と同様に動作するようになっていてもよい。
一例によれば、エンコーダは、（画像内の）現在のサブ画像と同じ場所および現在のサブ画像と同じ寸法（幅および高さ）を有するサブ画像を基準画像が含むように、現在のサブ画像を予測するための基準画像を選択する。エンコーダは、（画像内の）現在のサブ画像と同じ場所または現在のサブ画像と同じ寸法を有するサブ画像を基準画像が含まない場合、現在のサブ画像を予測するための基準画像の選択を回避する。一例によれば、同じアクセス単位または時間インスタンスのサブ画像は、ランダムアクセスサブ画像および非ランダムアクセスサブ画像等、ＮＡＬ単位タイプおよび／または画像タイプに関して上述したものと同様に規定された異なる種類を有することができる。エンコーダは、第１の場所およびサイズのランダムアクセスサブ画像ならびに第２の場所およびサイズの非ランダムアクセスサブ画像の両者を含む第１のアクセス単位と、デコーディング順序の第１のアクセス単位に先行する基準画像が回避されるように制約された第１の場所およびサイズのサブ画像ならびに第２の場所およびサイズの別のサブ画像を含むデコーディング順序の後続のアクセス単位とを、デコーディング順序の第１のアクセス単位に先行する基準画像を予測の基準として使用することによりエンコーディングする。
一例として、現在のサブ画像のエンコーディングおよび／またはデコーディングの場合、エンコーダおよび／またはデコーダは、（画像内の）現在のサブ画像と同じ場所および現在のサブ画像と同じ寸法（幅および高さ）を有するサブ画像を含む初期基準画像リストに対して、上記のような基準画像のみを含める。（画像内の）現在のサブ画像と同じ場所または現在のサブ画像と同じ寸法（幅および高さ）を有するサブ画像を含まない基準画像は、現在のサブ画像をエンコーディングおよび／またはデコーディングする初期基準画像リストの生成に対して省略または除外される。一例によれば、同じアクセス単位または時間インスタンスのサブ画像は、ランダムアクセスサブ画像および非ランダムアクセスサブ画像等、ＮＡＬ単位タイプおよび／または画像タイプに関して上述したものと同様に規定された異なる種類を有し得る。エンコーダおよび／またはデコーダにおける基準画像リスト初期化プロセスまたはアルゴリズムでは、デコーディング順序の先行ランダムアクセスサブ画像および後続サブ画像のみを初期基準画像リストに含み、デコーディング順序の先行ランダムアクセスサブ画像に先行するサブ画像については、省略または除外する。
一例によれば、第２のサブ画像シーケンスにおけるサブ画像は、第１のサブ画像シーケンスの１つまたは複数のサブ画像から予測される。第１のサブ画像シーケンスの１つまたは複数のサブ画像に関するサブ画像の空間的関係は、エンコーダによるビットストリーム中もしくはビットストリームに伴う推測もしくは指定ならびに／またはデコーダによるビットストリームからのデコーディングもしくはビットストリームに伴うデコーディングが行われる。ビットストリーム中またはビットストリームに伴う、このような空間的関係の情報がなければ、エンコーダおよび／またはデコーダは、サブ画像が同位置にある、すなわち、厳密に重なり合い、予測において空間的に対応するものと推測し得る。空間的関係の情報は、画像合成データから独立している。たとえば、サブ画像は、出力画像において互いに重なり合うように（上下パッキング配置にて）構成されていてもよく、一方、予測のために同位置にあると考えられる。
一例によれば、エンコーダは、サブ画像シーケンス識別子がＶＣＬ ＮＡＬ単位等のコード化ビデオデータ単位と関連付けられるように、ビットストリーム中またはビットストリームに伴うサブ画像シーケンス識別子または同等のものを示す。一例によれば、デコーダは、サブ画像シーケンス識別子がコード化ビデオデータ単位および／または各再構成サブ画像と関連付けられるように、ビットストリームから、または、ビットストリームに伴うサブ画像シーケンス識別子または同等のものをデコーディングする。サブ画像シーケンス識別子および関連付けメカニズムを含むシンタックス構造は、以下のうちの１つまたは複数を含んでいてもよいが、これらに限定されない。
ＮＡＬ単位ヘッダに含まれ、ＮＡＬ単位と関連付けられたサブ画像シーケンス識別子。
タイル群ヘッダまたはスライスヘッダ等のＶＣＬ ＮＡＬ単位のヘッダに含まれ、各イメージセグメント（たとえば、タイル群またはスライス）と関連付けられたサブ画像シーケンス識別子。
サブ画像デリミタ、画像ヘッダ、または類似のシンタックス構造に含まれ、コード化ビデオデータが暗示的に参照するサブ画像シーケンス識別子（サブ画像デリミタは、たとえば新たなサブ画像を開始させる特定のＮＡＬ単位であってもよい。暗示的な参照は、たとえばデコーディングまたはビットストリーム順序の先行するシンタックス構造（たとえば、サブ画像デリミタまたは画像ヘッダ）が参照され得ることを意味していてもよい）。
ヘッダパラメータ集合、画像パラメータ集合、または類似のシンタックス構造に含まれ、コード化ビデオデータが明示的に参照するサブ画像シーケンス識別子（明示的な参照は、たとえばタイトル群ヘッダまたはスライスヘッダ等のコード化ビデオデータに基準パラメータ集合の識別子が含まれることを意味していてもよい）。
一例によれば、サブ画像シーケンス識別子番号は、ビットストリームの所定の部分集合内において有効であり（これを「有効性期間」または「有効性部分集合」と称し得る）、以下のうちの１つが挙げられ得るが、これらに限定されない。
単一のアクセス単位すなわち単一の時間インスタンスのコード化ビデオデータ。
コード化ビデオシーケンス。
閉じたランダムアクセス・アクセス単位（これを含む）から次の閉じたランダムアクセス・アクセス単位（これを含まない）またはビットストリームの終端まで。閉じたランダムアクセス・アクセス単位（ｃｌｏｓｅｄ ｒａｎｄｏｍ－ａｃｃｅｓｓ ａｃｃｅｓｓ ｕｎｉｔ）は、その内部およびそれ以降に存在するすべてのサブ画像シーケンスが閉じたランダムアクセスサブ画像で開始となるアクセス単位として定義可能である。閉じたランダムアクセスサブ画像（ｃｌｏｓｅｄ ｒａｎｄｏｍ－ａｃｃｅｓｓ ｓｕｂ－ｐｉｃｔｕｒｅ）は、内部コード化サブ画像として定義可能であり、同じサブ画像シーケンス中のデコーディング順序の内部コード化サブ画像に先行する任意のサブ画像を参照する同じサブ画像シーケンスにおいては、デコーディング順序の同じようなサブ画像が後続することはない。一例によれば、閉じたランダムアクセスサブ画像は、内部コード化サブ画像であってもよいし、外部の基準サブ画像と関連付けられ、それのみから予測されるサブ画像であってもよく（以下に詳述する例参照）、それ以外は上述のような制約を受ける。
ビットストリーム全体。
一例によれば、サブ画像シーケンス識別子番号は、ビットストリームの指定部分集合内において有効である。エンコーダは、たとえば特定のＮＡＬ単位をビットストリームに含めてもよく、このＮＡＬ単位は、これより早い期間のサブ画像シーケンス識別子と関連しないサブ画像シーケンス識別子の新たな期間を示す。
一例によれば、特定のサブ画像シーケンス識別子番号を伴うサブ画像は、同じサブ画像シーケンス識別子番号を有するデコーディング順序の先行サブ画像とともに、サブ画像シーケンス識別子の同じ有効性期間内にある場合、先行サブ画像と同じサブ画像シーケンス内にあるものと決定される。２つの画像がサブ画像シーケンス識別子の異なる有効性期間上にある場合または異なるサブ画像シーケンス識別子を有する場合、これらは異なるサブ画像シーケンスと決定される。
一例によれば、サブ画像シーケンス識別子は、長さ固定のコードワードである。長さ固定のコードワード中のビット数は、ビットストリーム中もしくはビットストリームに伴って、たとえばビデオパラメータ集合もしくはシーケンスパラメータ集合におけるエンコーディング、ならびに／または、ビットストリームから、もしくは、ビットストリームに伴って、たとえばビデオパラメータ集合もしくはシーケンスパラメータ集合からのデコーディングが行われるようになっていてもよい。
一例によれば、サブ画像シーケンス識別子は、指数ゴロムコードまたは同等の可変長コードワードである。
一例によれば、エンコーダは、たとえばビデオパラメータ集合、シーケンスパラメータ集合、または画像パラメータ集合において、ビットストリーム中またはビットストリームに伴う、サブ画像またはサブ画像シーケンスに対するデコーディング順序のＶＣＬ ＮＡＬ単位またはイメージセグメントのマッピングを示す。同様に、一例によれば、一例によれば、デコーダは、ビットストリームから、または、ビットストリームに伴う、サブ画像またはサブ画像シーケンスに対するデコーディング順序のＶＣＬ ＮＡＬ単位またはイメージセグメントのマッピングをデコーディングする。マッピングには、一度に１つの時間インスタンスまたはアクセス単位が関与し得る。
一例によれば、たとえば単一のコンテナシンタックス構造において複数のマッピングが提供され、各マッピングは、たとえば識別子番号でインデックス化または明示的な識別がなされている。
一例によれば、エンコーダは、ビットストリーム、たとえば、アクセス単位ヘッダまたはデリミタにおいて、画像パラメータ集合、ヘッダパラメータ集合、画像ヘッダ、イメージセグメント（たとえば、タイル群またはスライス）のヘッダを示すが、このマッピングは、特定のアクセス単位または時間インスタンスに適用される。同様に、一例によれば、デコーダは、ビットストリームから、特定のアクセス単位または時間インスタンスに適用されるマッピングをデコーディングする。一例によれば、適用されるマッピングの指定は、（たとえば、シーケンスパラメータ集合において規定される）複数のマッピングのリストへのインデックスまたは（たとえば、シーケンスパラメータ集合において規定される）一組の複数のマッピングへの識別子である。別の例において、適用されるマッピングの指定には、たとえばマッピングと関連付けられたアクセス単位に含まれるデコーディング順序のＶＣＬ ＮＡＬ単位のサブ画像シーケンス識別子のリストとして、マッピングそれ自体を含む。
一例によれば、デコーダは、ＶＣＬ ＮＡＬ単位またはイメージセグメントのサブ画像またはサブ画像シーケンスを以下のように決定する。
アクセス単位の始端は、たとえばコーディング仕様に規定されたものとして決定される。あるいは、新たな時間インスタンスの開始は、パケット化またはコンテナファイル仕様に規定されたものとして決定される。
アクセス単位または時間インスタンスに適用されるマッピングは、任意の前例に従って決定される。
各サブ画像シーケンスまたはサブ画像は、デコーディング順序のＶＣＬ ＮＡＬ単位またはイメージセグメントごとに、マッピングから決定される。
以下の設計上の決定により、一例を以下に示す。
マッピングは、シーケンスパラメータ集合に規定される。
マッピングは、ＶＣＬ ＮＡＬ単位をサブ画像シーケンスにマッピングするように規定される。
特定のアクセス単位または時間インスタンスに対して適用されるマッピングの指定は、タイル群ヘッダにおいて行われる。
他の設計上の決定、たとえば、コンテナシンタックス構造、ＶＣＬ ＮＡＬ単位ではなくイメージセグメントに対するマッピング、およびサブ画像シーケンスではなくサブ画像に対するマッピングによっても同様に、他の例を実現可能であることが了解されるものとする。
一例によれば、サブ画像が通常の単一ビュー２Ｄビデオの画像全体であってもよく、この場合、各画像がサブ画像を１つだけ有し、ビデオの各部（タイルとして知られている場合もある）、（非対称）マルチビューまたは立体視ビデオの各ビュー、マルチレイヤ（スケーラブル）ビデオの各レイヤ、多面３６０°投影（たとえば、キューブマップ）の各面、ビデオの多重解像度パッキング（たとえば、多重解像度ＥＲＰまたはＣＭＰ）の各部、または点群の各部が表面に投影される（テクスチャまたは深度）。
サブ画像シーケンスの結合に際して、識別子番号がクラッシュする可能性もある。これが起こり得る原因として、コンテンツの異なる部分のエンコーディングに異なるエンコーダが使用されている可能性がある。たとえば、ＰＣＣコンテンツまたはオーバレイ・背景ビデオのテクスチャおよび形状ビットストリームのコーディングに異なるエンコーダが使用されている可能性がある。サブ画像シーケンスがエンコーディングの時点で把握すらされていない可能性もあるため、エンコーダは、サブ画像シーケンス識別子の使用またはビットストリームの使用を制御するための十分な設定インターフェースを提供していない可能性もある。このため、サブ画像シーケンスとして用いられるビットストリームが同じサブ画像シーケンス識別子を使用する可能性もあるし、サブ画像シーケンス識別子のエンコーディングが完全に不可能となっている可能性もある。また、サブ画像シーケンスとして用いられるビットストリームが異なるコンテンツの基準パラメータ集合に対して、同じパラメータ集合識別子を使用する可能性も考えられ得る。
サブ画像シーケンスには、異なるシーケンスレベルパラメータの使用が必要となる可能性もある。たとえば、テクスチャビットストリームが４：２：０彩度フォーマットを使用する一方、対応する深度ビットストリームが４：０：０彩度フォーマットを使用する可能性もある。使用する彩度フォーマットは、シーケンスパラメータ集合においてコーディングされる。Ｈ．２６４／ＡＶＣにおいてはコード化ビデオシーケンス当たり、ＨＥＶＣにおいてはコード化レイヤ単位のビデオシーケンス（ＣＬＶＳ）当たり、シーケンスパラメータ集合が１つだけアクティブ化される。ＣＬＶＳは、デコーディング順序において、特定種類のランダムアクセス画像（ＨＥＶＣにおいては、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇが１に等しいＩＲＡＰ画像）に、特定種類の次のランダムアクセス画像（ＨＥＶＣにおいては、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇが１に等しい次のＩＲＡＰ画像）までの（これを除く）すべてのコード化画像（存在する場合）が後続する同じレイヤ識別子番号（すなわち、ＨＥＶＣの同じｎｕｈ＿ｌａｙｅｒ＿ｉｄ値）を含む一連のコード化画像として定義可能である。
識別番号のクラッシュは、サブ画像シーケンスの結合に際して識別番号を書き換えることにより回避することも可能である。ただし、このような書き換えは、特にｕｅ（ｖ）ｅｘｐ－ゴロムコード等の可変長コードワードで識別子がコーディングされている場合、始端コードエミュレーション防止バイトの影響を受ける可能性があるビット位置に識別子が現れる場合、可変長コード化シンタックス要素が識別子に先行する場合、識別子自体が始端コードエミュレーション防止バイトを推測する場合（たとえば、値０）、および／またはコンテンツが暗号化され、識別子がコンテンツの暗号化部分の一部である場合に脆弱となり得る。
レイヤ識別子および／またはサブ画像シーケンス識別子の値範囲およびビットレートは、比較的大きくすることが必要となる可能性もある。以下、サブシーケンス結合を利用し得る多様な使用事例の一部の例を簡単に一覧化する。
３ＤｏＦ ３６０°ビデオの表示域に応じたストリーミングのサブ画像数は、比較的多くすることが必要となる可能性もある。たとえば、３ＤｏＦ ３６０°ビデオの表示域に応じた配信を実現するには、９６個ものサブ画像を使用することが好都合となり得る。
ビデオベースの点群コーディングまたは３ＤｏＦ＋ビデオコーディング等のボリュメトリックビデオコーディングにおいても、サブ画像の数を多くすることが有益となる可能性もある。ボリュメトリックビデオコーディングにおいては、３Ｄコンテンツが２Ｄパッチ上に投影されるようになっていてもよく、これは、たとえば類似の視認円錐に基づいてサブ画像上に配置されていてもよい。さらに、ボリュメトリックビデオコーディングにおいては、テクスチャ、形状、占有状態、および異なる種類の属性等、複数種類のビデオがコーディングされるようになっていてもよい。
プレノプティックまたはサブアパーチャイメージ／ビデオコーディングであって、サブアパーチャイメージ当たり１つのサブ画像がコーディングされるようになっていてもよい。
スーパーマルチビューまたはウィンドウ付き６ＤｏＦビデオコーディングであって、コンテンツが数十台のカメラで取り込まれる。
３６０°背景に重なり合う１つまたは複数の２Ｄ ３６０°またはボリュメトリックビデオクリップであって、表示域に応じた配信のためサブ画像でコーディングされていてもよい。
たとえば異なるビットレート、空間解像度、画像レート、ビット深度、ダイナミックレンジ、および／または色域に関して、コンテンツのさまざまなバージョンがコーディングされる可能性もある。たとえば表示域に応じた配信および／またはレート適応に関しては、さまざまなバージョンによるサブ画像シーケンスの結合が好ましい可能性もあるため、これらは潜在的に、さまざまなサブ画像シーケンス識別子と関連付けられるものとする。
たとえば選択されたサブ画像シーケンスに対して選択的な拡張機能を提供するため、スケーラブルビデオコーディングの拡張レイヤが有益となる可能性もある。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいては、レイヤ識別子または同等のものがＮＡＬ単位ヘッダにおいてエンコーディングされる。レイヤ識別子および／またはサブ画像シーケンス識別子の比較的大きな値範囲は、ビットレートに対して比較的コスト高である。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいては、固定長コードワードが使用されている。多種多様な使用事例をサポートするため、たとえば８～１２ビットがサブ画像シーケンス識別子に対して、たとえば４～６ビットがレイヤ識別子に対して予約される可能性もある。両者を単一の識別子番号として組み合わせることも可能と考えられる（たとえば、１０～１６ビットの長さ）。ただし、ＮＡＬ単位ヘッダに含まれる場合、識別子番号は、サブ画像およびレイヤをサポートしないコーディングシステムと比較して、ＮＡＬ単位当たり２バイトの付加的なストレージを必要とする可能性もある。たとえば、これは、６０Ｈｚレートで９６個のサブ画像の場合、９０ｋｂｐｓ超に相当することになる。
ＨＥＶＣでは６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄ値を使用し、レイヤが独立した非ベースレイヤであってもよい。ＨＥＶＣ規格には具体的に記載されていないものの、任意のレイヤに対して、０に等しいすべてのスケーラビリティ次元識別子にマーキングすることが可能と考えられる。すなわち、レイヤが同じビューのコード化テクスチャであり、補助レイヤではなく、品質または空間拡張レイヤもないことを示し得ると考えられる。これにより、レイヤがサブ画像シーケンスに用いられることを示し得る。ただし、６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄしか使用されないため、多くの使用事例（たとえば、表示域に応じた３６０°ストリーミングに対する９６個のサブ画像）においては、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に対してサブ画像シーケンスを一意にマッピングすることができない。同時にデコーディングされるサブ画像シーケンスの数は、６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に可能な数より少なくなる可能性がある。
一例においては、デリミタがデリミタＮＡＬ単位であり、たとえばサブ画像シーケンスデリミタＮＡＬ単位またはデコーディング制御ＮＡＬ単位と称し得る。実施形態は、デリミタの呼称に関わらず適用されることを理解する必要がある。サブ画像シーケンスデリミタＮＡＬ単位は、サブ画像関連指標または制御の搬送に特有であり得る（必ずしもこれらに限定されない）。一方、デリミタＮＡＬ単位またはデコーディング制御ＮＡＬ単位等のより一般的な呼称は、同じくサブ画像関連指標または制御を含む任意の目的に使用可能である。ビットストリームシンタックスにおける基本単位がＮＡＬ単位である場合は、デリミタがＮＡＬ単位であってもよい。実施形態は、デリミタがＮＡＬ単位であることに限定されないが、ビデオビットストリームにおいては、アクセス単位ヘッダまたは同等のものまたはその一部のような任意のシンタックス構造も可能である。デリミタ（ｄｅｌｉｍｉｔｅｒ）、デリミタＮＡＬ単位（ｄｅｌｉｍｉｔｅｒ ＮＡＬ ｕｎｉｔ）、サブ画像シーケンスデリミタ（ｓｕｂ－ｐｉｃｔｕｒｅ ｓｅｑｕｅｎｃｅ ｄｅｌｉｍｉｔｅｒ）、およびデコーディング制御ＮＡＬ単位（ｄｅｃｏｄｉｎｇ ｃｏｎｔｒｏｌ ＮＡＬ ｕｎｉｔ）といった用語は、同じ意味で使用する。
アクセス単位デリミタＮＡＬ単位は、デリミタＮＡＬ単位の一例である。ＶＶＣ規格のドラフト版は、以下のシンタックスでアクセス単位デリミタ（ＡＵＤ）ＮＡＬ単位に含まれるアクセス単位デリミタ（ＡＵＤ）ＲＢＳＰを規定する。
Figure 0007492978000008
ＶＶＣ規格のドラフト版において、ＡＵデリミタ（ＡＵＤ）は、アクセス単位（ＡＵ）の始端、ＡＵがＩＲＡＰであるか漸次デコーディングリフレッシュ（ＧＤＲ）ＡＵであるか、およびＡＵデリミタＮＡＬ単位を含むＡＵ中のコード化画像に存在するスライスの種類を示すのに用いられる。ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇ＝１は、ＡＵデリミタを含むＡＵがＩＲＡＰまたはＧＤＲ ＡＵであることを規定する。ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇ＝０は、ＡＵデリミタを含むＡＵがＩＲＡＰでもＧＤＲ ＡＵでもないことを規定する。コード化ビデオシーケンスは、ＩＲＡＰまたはＧＤＲ ＡＵで開始となることが必要となり得る。ＩＲＡＰ ＡＵは、すべてのレイヤが存在してＩＲＡＰ画像を含むＡＵとして定義可能である。ＧＤＲ ＡＵは、すべてのレイヤが存在してＧＤＲ画像を含むＡＵとして定義可能である。ａｕｄ＿ｐｉｃ＿ｔｙｐｅは、Ｉ（ｉｎｔｒａ－ｃｏｄｅｄ，内部コード化）、Ｐ（ｉｎｔｅｒ－ｃｏｄｅｄ ｗｉｔｈ ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎ，一重予測の相互コード化）、およびＢ（Ｉｎｔｅｒ－ｃｏｄｅｄ ｗｉｔｈ ｂｉ－ｐｒｅｄｉｃｔｉｏｎ，二重予測の相互コード化）スライスのうちの可能なスライスタイプを指定する。
一例によれば、すべてのサブ画像シーケンスに関連するように所定のサブ画像シーケンス識別子番号（たとえば、０）が規定される。たとえば、すべてのサブ画像シーケンスに適用されるパラメータ集合ＮＡＬ単位に先行するように、サブ画像シーケンス識別子が０に等しいサブ画像シーケンスデリミタが用いられるようになっていてもよい。たとえば、同じエンコーディング設定を有する同じエンコーダによりエンコーディングが実行され、すべてのサブ画像が同じ幅および高さを有する場合、これらは、同じシーケンスパラメータ集合（ＳＰＳ）および画像パラメータ集合（ＰＰＳ）を共有するようにしてもよい。
他の実施形態との併用または他の実施形態から独立した使用が可能な一実施形態によれば、任意特定のレイヤに固有ではない情報に対して、特定のレイヤ識別子番号が予約され、ビットストリーム全体もしくはすべてのレイヤならびに／または任意特定のレイヤに対する割り当てが意味をなさないＮＡＬ単位（または、類似物）に適用される。ＶＣＬ ＮＡＬ単位（または、このようなコード化ビデオデータ）は、このレイヤ識別子に割り当てられない。たとえば、ビットストリームＮＡＬ単位および／またはアクセス単位デリミタＮＡＬ単位の終端を上記特定のレイヤ識別子に割り当てることも可能である。他の実施形態に記載のようなデコーディング制御ＮＡＬ単位を上記特定のレイヤ識別子に割り当てることも可能であるし、デコーディング制御ＮＡＬ単位において搬送される制御が任意特定のレイヤに固有でない場合は、ビットストリーム全体またはすべてのレイヤに適用することも可能である。たとえば、識別子番号のクラッシュを回避するため、（独立コード化画像領域シーケンス等の部分を単一のビットストリームに対して結合可能な）レイヤおよび／またはビットストリームで共有されるパラメータ集合ＮＡＬ単位が上記特定のレイヤ識別子に割り当てられていてもよい。
一実施形態によれば、サブ画像シーケンスデリミタは、他の情報をデコーダに受け渡すために使用される。このような他の情報には、以下のうちの１つまたは複数を含んでいてもよいが、これらに限定されない。
システムにおいて本質的に保持される情報（たとえば、ファイルフォーマット、メディアプレゼンテーション、および／または通信プロトコル）。
クライアント機器、プレーヤアプリケーション、または類似のエンティティにより制御または使用される情報（デコーディングプロセスに影響を及ぼす可能性がある）。
クライアント機器、プレーヤアプリケーション、または類似のエンティティにより制御または使用される情報としては、以下が挙げられるが、これらに限定されない。
関連するＮＡＬ単位またはコード化画像をコード化ビデオシーケンスの始端として処理する旨の指示であって、これは、たとえばＯｐｅｎ ＧＯＰ内部画像（たとえば、ＨＥＶＣのＣＲＡ画像）からデコーディングが開始（再開）される場合に、Ｏｐｅｎ ＧＯＰ内部画像と併用され得る。たとえば、ＨＥＶＣデコーディングプロセスでは、外部制御フラグＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇを入力するが、これは、デリミタＮＡＬ単位に含めることも可能である。
関連するＮＡＬ単位またはコード化画像を新たな構成ビットストリームの始端として処理する旨の指示。
関連するＮＡＬ単位またはコード化画像をレイヤアップスイッチング後の予想レイヤのデコーディングの始端として処理する旨の指示。
コード化ビデオシーケンスの終端の指定であって、この場合は、デリミタＮＡＬ単位が如何なる後続ＮＡＬ単位にも関連する必要がない。
構成ビットストリームの終端の指定であって、この場合は、デリミタＮＡＬ単位が如何なる後続ＮＡＬ単位にも関連する必要がない。
（たとえば、レイヤダウンスイッチングによる）予測レイヤの終端の指定であって、この場合は、デリミタＮＡＬ単位が如何なる後続ＮＡＬ単位にも関連する必要がない。
情報が関連付けられた画像のデコーディングに出力時間が後続する（サブ画像シーケンスの）画像を出力しない旨の指示であって、この機能は、ＨＥＶＣにおいてｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ＝１により実現される機能と類似する。
一部の手法は、構成ビットストリームのエンコーディング後の結合ビットストリームへの新たなデータ単位（たとえば、デリミタＮＡＬ単位）の追加に基づく。構成ビットストリームに対してバッファリングパラメータ（たとえば、ＨＲＤパラメータ）が生成されるようになっていてもよく、これらのパラメータは、追加のデータ単位を考慮に入れない。一例においては、バッファリングモデルがデータ単位の種類を確認するように規定される。データ単位が結合ビットストリームへの追加または追加可能であるもののうちの１つである場合（たとえば、デリミタＮＡＬ単位の場合）、バッファリングモデルは、これをコード化画像バッファまたは同等のものに含めない。それ以外の場合、データ単位が結合ビットストリームへの追加または追加可能なもののうちの１つでなければ、バッファリングモデルは、このデータ単位をコード化画像バッファまたは同等のものに追加する。
一実施形態によれば、クライアント機器、プレーヤアプリケーション、または類似のエンティティ（たとえば、エッジネットワーク上のエンティティ）の動作には、以下のステップを含む。
多くのビットストリーム９００から、２つ以上のビットストリームが選択される（図８ａ）。ビットストリームは、サブ画像シーケンスであってもよい。選択されたビットストリームは、構成ビットストリームと称し得る。ビットストリームの選択には、たとえばビットストリームを搬送する（コンテナファイル内の）トラックの選択およびパーシングを含んでいてもよい。この代替または追加として、選択には、ビットストリームを搬送するトラックに対応するＭｅｄｉａ ＤｅｓｃｒｉｐｔｉｏｎのＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することであって、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎはビットストリームを搬送するトラックに対応する、選択することと、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの（Ｓｕｂ）ｓｅｇｍｅｎｔまたはデータ単位等のデータをサーバから要求することと、要求データを受信することと、を含んでいてもよい。
ビットストリームは、単一の結合ビットストリーム９０２または結合データ単位ストリームとして結合される。結合プロセスの一部として、デリミタ９０４が結合ビットストリーム９０２に書き込まれ得るが、これらのデリミタ９０４は、当該デリミタと関連付けられたデータ単位が割り当てられるビットストリームを示す。デリミタは、たとえばデリミタＮＡＬ単位またはサブ画像ヘッダ等のデリミタデータ単位であってもよいし、レイヤ識別子９０８であってもよい（図８ｂ）。デリミタデータ単位の手法は、たとえばコーディングシステムが本質的に、レイヤまたはサブ画像シーケンスを使用可能にできない場合に用いられるようになっていてもよい。レイヤ識別子の手法においては、たとえばＮＡＬ単位ヘッダにレイヤ識別子が存在していてもよい。この手法は、たとえばコーディングシステムがＨＥＶＣと同様に、独立した非ベースレイヤを使用可能にできる場合に用いられるようになっていてもよい。
エッジネットワーク上のエンティティは、上述のステップを実行する場合、ＤＡＳＨストリーミングセッションのクライアント等、セッションの終点として作用し得る。デコーダエンティティとエッジネットワーク上のエンティティとの間には、別のセッションが存在していてもよく、この場合は、異なる一組の通信プロトコルが使用されるようになっていてもよい。
データ単位ストリーム中のデータ単位は、ＮＡＬ単位、コード化画像、画像群のうちの１つであってもよいが、これらに限定されない。
図９は、品質の異なる２つのサブ画像シーケンス９５０がサブ画像シーケンストラック９５４としてカプセル化され（９５２）、たとえばクライアント機器またはクラウドサービスに配信される（９５６）構成を示している。（下線付き太字の数字を含む正方形として図の下部に示した）２つ目のサブ画像シーケンストラックのサブ画像は、（太字でも下線付きでもない数字を含む正方形として図の上部に示した）１つ目のサブ画像シーケンストラックのサブ画像とは異なる品質（品質２）を有する。クライアント機器は、選択されたサブ画像シーケンスから単一のデータ単位ストリームを生成し（９５８）、デリミタを適当な場所に含める。単一のデータ単位ストリームのデータ単位が複数のデコードサブ画像シーケンス９６２としてデコーディングされる（９６０）。デコードサブ画像シーケンス９６２は、混合品質を有する出力画像シーケンス９６６として合成される（９６４）。図９におけるこれら出力画像シーケンス９６６の表示において、２つ目のサブ画像シーケンストラックに由来するサブ画像シーケンスは、下線付き太字の数字を含む正方形として示している。
一実施形態によれば、エンコーダは、構成ビットストリーム内にデリミタデータ単位を生成する。別の実施形態によれば、受信側等の別のエンティティが他の実施形態に記載の通り、デリミタデータ単位のコンテンツを書き換える。
以下、結合ビットストリームの同じコード化画像における異なる種類のコード化画像（たとえば、非ＩＲＡＰおよびＩＲＡＰ画像）に由来する独立コード化画像領域を示す例示的な一実施形態を提供する。
一実施形態において、プレーヤは、関連するコード化画像が、異なる種類のコード化画像（たとえば、非ＩＲＡＰおよびＩＲＡＰ画像）に由来する独立コード化画像領域を含むか、または、ＴＲＡＩＬおよび任意のＩＲＡＰ ＮＡＬ単位タイプ等の異なる種類のＶＣＬ ＮＡＬ単位を含むか、に関する指標をデコーディング制御ＮＡＬ単位等の結合ビットストリームの別個のデータ単位に含める。この指標は、混合画像タイプ指標と称し得る。異なる種類の画像に由来する独立コード化画像領域または異なる種類のＶＣＬ ＮＡＬ単位を有するコード化画像を示す混合画像タイプ指標と関連付けられたコード化画像は、混合画像タイプ特性との関連付けが完了または進行中と考えられ得る。
一実施形態において、デコーダは、前記別個のデータ単位から上記指標をデコーディングし、この指標が与える情報を使用して、たとえば以下のように、前記別個のデータ単位のデコーディングをさらに制御する。
一実施形態において、コード化画像が混合画像タイプ特性を有するものと上記指標が示す場合、デコーダは、コード化画像がトレーリング画像のようにデコーディングされる旨をデコーディングする。このため、デコーダは後で、コード化画像をトレーリング画像のようにデコーディングし得る。
一実施形態において、コード化画像が混合画像タイプ特性を有するものと上記指標が示す場合、デコーダは、コード化画像の画像順序カウント（ＰＯＣ）がトレーリング画像のようにデコーディングされ、コード化画像のＰＯＣが時間的サブレイヤ０における先行基準画像のＰＯＣに対する所定のアルゴリズムで導出される旨をデコーディングする。このため、デコーダは後で、コード化画像をトレーリング画像のようにデコーディングし得るとともに、時間的サブレイヤ０における先行基準画像のＰＯＣに対する所定のアルゴリズムでＰＯＣを導出する。
一実施形態において、コード化画像が混合画像タイプ特性を有さないものと上記指標が示す場合、デコーダは、前記別個のデータ単位から、コード化画像のスライス等の任意のイメージセグメントに包含または参照される基準画像リスト構造および／または基準画像集合構造に従って、基準画像マーキングが実行される旨をデコーディングする。これは、ＩＤＲ ＮＡＬ単位タイプによる「参照不使用」としてのすべての基準画像のマーキング等、従来から基準画像の特定のマーキングの起点となっている種類のイメージセグメントにも同様に当てはまることに留意するものとする。
一実施形態によれば、サブ画像シーケンスデリミタもしくはアクセス単位デリミタ等のデリミタまたはデコーディング制御ＮＡＬ単位がビットストリームスケーラビリティ特性のデコーダへの受け渡しに使用され、以下のうちの１つまたは複数が挙げられるが、これらに限定されない。
デリミタの範囲内の画像の最も高い時間的サブレイヤの指定。
デリミタの範囲内のすべての画像がＩＲＡＰおよび／またはＧＤＲ画像であるかの指標。
デリミタの範囲内に存在するレイヤまたは存在し得るレイヤの指定。
ビットストリームが表す出力レイヤ集合の指定であって、この指定の出力レイヤ集合に存在しないレイヤは、ビットストリーム中にも存在しない。
一実施形態において、ＩＲＡＰまたはＧＤＲ ＡＵにおけるアクセス単位デリミタの範囲は、ＡＵＤで始まるコード化ビデオシーケンスとなるように規定される。
デリミタまたはデコーディング制御ＮＡＬ単位内のビットストリームスケーラビリティ特性をデコーダに受け渡す利点として、以下のうちの１つまたは複数が挙げられるが、これらに限定されない。
デコーダインターフェースは、ビットストリームスケーラビリティ特性をアプリケーションからデコーダに受け渡す特定の手段を提供せず、ビデオビットストリームを受け渡すインターフェースのみを提供する可能性がある。このため、ビットストリームスケーラビリティ特性をビットストリーム内に含めることのみがデコーダへの受け渡し手段となる可能性がある。
受信側への転送前に、メディアミキサ等のネットワークエンティティがビットストリームからレイヤまたはサブレイヤを削除するようにしてもよい。ネットワークエンティティは、転送ビットストリームのビットストリームスケーラビリティ特性を示す受信側デコーダとの帯域外インターフェースを有さない可能性もある。このため、ビットストリームスケーラビリティ特性をビットストリーム内に含めることのみがネットワークエンティティからデコーダへの受け渡し手段となる可能性がある。
ＶＰＳにおいて指定可能なサブレイヤ、レイヤ、および／またはＯＬＳの全部ではないが一部をデコーダがデコーディング可能な場合は、ビットストリームが表すサブレイヤ、レイヤ、および／またはＯＬＳに関する情報によって、ビットストリームのデコーダへの受け渡し前にサブビットストリーム抽出が必要となるかをアプリケーションが決定可能となる。一部のデコーダは、指定されたＯＬＳおよび指定された最も高い時間的サブレイヤを厳密に表すのに、入力として与えられたビットストリームを必要とする場合がある。
サブビットストリーム抽出プロセスでは、目標ＯＬＳを入力として取得するとともに、目標ＯＬＳの出力レイヤにおいて画像をデコーディングするのに必要ない画像を非出力レイヤから除去するようにしてもよい。後続のサブビットストリーム抽出は、（一部のレイヤがビットストリーム中に存在しなくなったため）不可能となっている可能性もあるし、（先行サブビットストリーム抽出において多くの時間的サブレイヤが除去されたため）望ましいビットストリームにならない可能性もある。したがって、ビットストリームが表すＯＬＳおよび最も高い時間的サブレイヤに関する情報によれば、入力として特定の目標ＯＬＳおよび最も高い時間的サブレイヤを含むサブビットストリーム抽出が可能かつ妥当であるかを決定可能となる。
デコーダ動作は、ビットストリームが表すレイヤもしくはＯＬＳならびに／またはビットストリーム中に存在する最も高いサブレイヤを把握する恩恵を受け得る。デリミタまたはデコーディング制御ＮＡＬ単位内の各ビットストリームスケーラビリティ特性をデコーダに受け渡す結果として、以下の利点のうちの１つまたは複数が得られる。同様に、ビットストリームスケーラビリティ特性をデコーディングするとともに、以下の項目のうちのいずれか１つまたは複数に記載のような各デコーダ動作を推測する実施形態が規定される。
ビットストリームが表すＯＬＳに関する情報によって、デコーディングプロセスでは、出力レイヤであるために正しい画像を出力するレイヤを決定することができる。
画像格納バッファ（ｐｉｃｔｕｒｅ ｓｔｏｒａｇｅ ｂｕｆｆｅｒ）は、あるデコード画像をＤＰＢに格納するのに用いられるメモリ空間として定義可能である。すべての画像格納バッファが同じ幅および高さ（サンプルに関して）、同じビット深度、ならびに／または同じ彩度フォーマットを有することが規定され得る。異なるレイヤ中の画像が異なる幅（サンプル）、高さ（サンプル）、ビット深度、または彩度フォーマットを有する場合は、画像格納バッファがＯＬＳ中のレイヤのうちの最大値で予約されることが規定され得る。ビットストリームが表すＯＬＳに関する情報によって、デコーダは、ＤＰＢの画像格納バッファに対して予約される幅、高さ、ビット深度、および／または彩度フォーマットを決定することができる。
初期バッファリング遅延等のＨＲＤパラメータは、ビットストリームが表すＯＬＳおよび／または存在するサブレイヤによって決まり得る。ビットストリームが表すＯＬＳおよび／またはビットストリーム中に存在するサブレイヤに関する情報によって、デコーダは、ビットストリームに適用可能なＨＲＤパラメータを選択することができる。その結果、デコーダは、初期バッファリング遅延等の指定されたＨＲＤパラメータを使用することにより、当該デコーダで使用されるＣＰＢおよび／またはＤＰＢを制御するようにしてもよい。
以下、アクセス単位デリミタＮＡＬ単位の例示的な一実施形態を提供する。以下のシンタックスが用いられるようになっていてもよい。
Figure 0007492978000009
ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇおよびａｕｄ＿ｐｉｃ＿ｔｙｐｅのセマンティクスについては、上述の通りである。他のシンタックス要素のセマンティクスは、以下のように規定され得る。
ａｕｄ＿ｈｔｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１がＡＵＤ ＮＡＬ単位に存在しないことを規定する。ａｕｄ＿ｈｔｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１がＡＵＤ ＮＡＬ単位に存在することを規定する。
ａｕｄ＿ｏｌｓ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘがＡＵＤ ＮＡＬ単位に存在しないことを規定する。ａｕｄ＿ｏｌｓ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘがＡＵＤ ＮＡＬ単位に存在することを規定する。
ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１＝０は、ＡＵＤ ＮＡＬ単位で始まるＣＶＳ中のすべての画像がｐｈ＿ｒｅｃｏｖｅｒｙ＿ｐｏｃ＿ｃｎｔ＝０のＩＲＡＰ画像またはＧＤＲ画像であることを規定する。ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１＞０は、ＡＵＤ ＮＡＬ単位で始まるＣＶＳ中のすべての画像のＴｅｍｐｏｒａｌＩｄがａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１未満であることを規定する。
ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘは、ＡＵＤ ＮＡＬ単位で始まるＣＶＳが、ＯＬＳインデックスがａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘに等しいＯＬＳに含まれる以外の如何なるレイヤも含まないことを規定する。
他の例示的な実施形態も同様に導出可能であることを理解する必要がある。たとえば、２つのゲーティングフラグ（ａｕｄ＿ｈｔｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇおよびａｕｄ＿ｏｌｓ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）が単一のゲーティングフラグにより置き換えられてもよいし（ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１およびａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘの両方をゲーティング）、完全に除去されてもよい（ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇ＝１の場合に、ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１およびａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘを存在させる）。別の例においては、最も高い時間的サブレイヤまたはＯＬＳシグナリングのみ（両方ではない）がシンタックスに含まれる。さらに別の例においては、ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１の代わりにシンタックス要素ａｕｄ＿ｃｖｓ＿ｈｔｉｄが使用され、ＡＵＤ ＮＡＬ単位で始まるＣＶＳ中のすべての画像のＴｅｍｐｏｒａｌＩｄがａｕｄ＿ｃｖｓ＿ｈｔｉｄ以下であることを規定する。また、シンタックス要素のデータ型が例示的な実施形態に示すものでなくてもよいことに留意する必要がある。たとえば、ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘに対して、ｕｅ（ｖ）の代わりにｕ（８）を使用することも可能である。さらに、シンタックス要素のセマンティクスが例として提供され、実施形態が他の類似セマンティクスにも同様に当てはまることを理解する必要がある。たとえば、ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘは、規定のサブビットストリーム抽出プロセスを用いて入力ビットストリームからビットストリームを生成するのに使用されたＯＬＳインデックスとなるように規定されていてもよい。
一実施形態において、サブビットストリーム抽出プロセスでは、ビットストリームｉｎＢｉｔｓｔｒｅａｍのほか、目標ＯＬＳインデックスｔａｒｇｅｔＯｌｓＩｄｘおよび／または目標最大ＴｅｍｐｏｒａｌＩｄ値ｔＩｄＴａｒｇｅｔを入力し、サブビットストリームｏｕｔＢｉｔｓｔｒｅａｍを出力するようにしてもよい。サブビットストリーム抽出プロセスでは、アクセス単位デリミタ等のデリミタまたはｏｕｔＢｉｔｓｔｒｅａｍ中のデコーディング制御ＮＡＬ単位に対して、プロセスの入力として与えられたｔａｒｇｅｔＯｌｓＩｄｘおよび／または最大ＴｅｍｐｏｒａｌＩｄを挿入する。
一実施形態において、サブビットストリーム抽出プロセスでは、ビットストリームｉｎＢｉｔｓｔｒｅａｍ、目標ＯＬＳインデックスｔａｒｇｅｔＯｌｓＩｄｘ、および目標最大ＴｅｍｐｏｒａｌＩｄ値ｔＩｄＴａｒｇｅｔを入力し、サブビットストリームｏｕｔＢｉｔｓｔｒｅａｍを出力するとともに、以下のステップのうちの１つまたは複数を含むことによって、出力サブビットストリームＯｕｔＢｉｔｓｔｒｅａｍを導出してもよい。
ビットストリームｏｕｔＢｉｔｓｔｒｅａｍは、ビットストリームｉｎＢｉｔｓｔｒｅａｍと同一になるように設定される。
ＴｅｍｐｏｒａｌＩｄがｔＩｄＴａｒｇｅｔより大きなすべてのＮＡＬ単位をｏｕｔＢｉｔｓｔｒｅａｍから除去する。
ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＶＰＳ＿ＮＵＴ、ＤＣＩ＿ＮＵＴ、ＡＵＤ＿ＮＵＴ、およびＥＯＢ＿ＮＵＴのいずれにも等しくなく、ｎｕｈ＿ｌａｙｅｒ＿ｉｄが目標ＯＬＳに含まれないすべてのＮＡＬ単位をｏｕｔＢｉｔｓｔｒｅａｍから除去する。
目標ＯＬＳの出力レイヤに存在せず、（ＯＬＳ中の他のレイヤに対して、ＩＲＡＰ画像のみがレイヤ間基準画像として使用される場合の）非ＩＲＡＰ画像であるか、または、（特定のサブレイヤまでがレイヤ間予測の基準として使用される場合に）レイヤ間予測の基準として使用されないサブレイヤ中に存在するすべてのＶＣＬ ＮＡＬ単位をｏｕｔＢｉｔｓｔｒｅａｍから除去する。
上記いずれかの導出ステップによってＡＵのすべてのＶＣＬ ＮＡＬ単位が除去され、ＡＵＤ ＮＡＬ単位がＡＵに存在する場合、ＡＵＤ ＮＡＬ単位をｏｕｔＢｉｔｓｔｒｅａｍから除去する。
ｏｕｔＢｉｔｓｔｒｅａｍ中のＡＵのすべての画像単位（ＰＵ）がＧＤＲ ＰＵまたはＩＲＡＰ ＰＵである場合、以下を適用する。
複数のレイヤが存在または存在可能であり（たとえば、ｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０より大きい）、ｏｕｔＢｉｔｓｔｒｅａｍ中のＡＵがＡＵＤ ＮＡＬ単位を含まない場合は、ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇ ＝１の状態で、ＡＵの最初のＮＡＬ単位としてＡＵＤ ＮＡＬ単位をｏｕｔＢｉｔｓｔｒｅａｍに追加する。
それ以外で、ｏｕｔＢｉｔｓｔｒｅａｍ中のＡＵがＡＵＤ ＮＡＬ単位を含む場合、ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａｇの値は、ＡＵＤ ＮＡＬ単位において１に等しく設定される。
ａｕｄ＿ｉｒａｐ＿ｏｒ＿ｇｄｒ＿ａｕ＿ｆｌａ＝１の各ＡＵＤ ＮＡＬ単位のシンタックス要素値を以下のように設定する（使用されるシンタックス選択肢に応じて、同様の設定をする）。
ａｕｄ＿ｈｔｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、１に等しく設定される。
ａｕｄ＿ｏｌｓ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、１に等しく設定される。
ａｕｄ＿ｃｖｓ＿ｈｔｉｄ＿ｐｌｕｓ１は、ｔＩｄＴａｒｇｅｔ＋１に等しく設定される。
ａｕｄ＿ｃｖｓ＿ｏｌｓ＿ｉｄｘは、ｔａｒｇｅｔＯｌｓＩｄｘに等しく設定される。
以下、デコーディング制御ＮＡＬ単位の例示的な一実施形態を提供する。
一実施形態において、デコーディング制御ＮＡＬ単位のシンタックスは、同じデコーディング制御ＮＡＬ単位および／または制御シンタックス要素における各制御シンタックス要素の有無に関するゲーティングフラグを少なくとも含む。制御シンタックス要素としては、ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄ、ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ、ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇ、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ、および／またはｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｃｅ＿ｉｄ＿ｆｌａｇのうちの１つまたは複数が挙げられるが、これらに限定されない。
一実施形態によれば、これらの制御シンタックス要素のセマンティクスは、以下の通りであってもよい。
ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄは、デコーディング対象のレイヤの識別子である。
デコーディング対象のＯＬＳの出力レイヤ集合インデックスである。
ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄは、デコーディング対象の最も高いサブレイヤの識別子である。
ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇは、ＣＬＶＳを開始する画像として、関連する画像（たとえば、ＣＲＡまたはＧＲＡ画像）が処理されるかを示す。
ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ＝１は、関連するＩＤＲ画像のデコーディング時間に対して出力時間が先行する画像が出力されないことを規定する。
ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ＝０は、ｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素（または、スライスヘッダ内のスライスの識別子もしくはスライスヘッダ等のヘッダ内の独立コード化画像領域の識別子を規定する任意の類似シンタックス要素）が０で始まり、デコーディング順序のコード化画像内のスライスごとに１だけインクリメントすることを規定する。ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ＝１の場合は、デコーディング順序のｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素の値が規定される。ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ＝１の場合は、ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１、ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１、およびｓｌｉｃｅ＿ｉｄ［ｉ］といったシンタックス要素が追加で存在する。
一実施形態によれば、これら付加的な制御シンタックス要素のセマンティクスは、以下の通りであってもよい。
ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１は、ｓｌｉｃｅ＿ｉｄ［ｉ］固定長コード化シンタックス要素の長さを示す。
ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１は、画像内の長方形スライスの数を示す。
画像の長方形スライスごとに存在し、Ｉでインデックス化されたｓｌｉｃｅ＿ｉｄ［ｉ］は、デコーディング順序のｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素の値を含む。
本実施形態においては、以下のシンタックスが用いられるようになっていてもよい。シンタックスは、実施形態に含まれる制御シンタックス要素に応じて、同様に調整され得ることを理解する必要がある。また、ゲーティングフラグおよび制御シンタックス要素は、異なる順序で選択し得ることを理解する必要がある。たとえば、ゲーティングフラグは、シンタックスにおいて、各制御シンタックス要素の直前に先行することも可能である。本実施形態は、提示のシンタックスおよびセマンティクスの部分集合、たとえば、スライスと関連する部分集合のみで実現され得ることを理解する必要がある。また、独立デコーディング可能な画像領域を実現する手段として、（境界が画像境界のように処理される）長方形スライスに関して例示的な実施形態を説明するが、シンタックスおよびセマンティクスは、サブ画像等の他の手段にも同様に適用可能であることを理解する必要がある。たとえば、特定の順序（たとえば、サブ画像の左上位置の画像ラスタースキャン順序）のサブ画像識別子番号は、デコーディング制御ＮＡＬ単位において示すことも可能である。
Figure 0007492978000010
ゲーティングフラグは、各制御シンタックス要素の有無を規定する。ゲーティングフラグのセマンティクスは、以下のように規定され得る。
ｔａｒｇｅｔ＿ｌｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄが存在しないことを規定し、ｔａｒｇｅｔ＿ｌｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄが存在することを規定する。
ｈｉｇｈｅｓｔ＿ｔｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄが存在しないことを規定し、ｈｉｇｈｅｓｔ＿ｔｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄが存在することを規定する。
ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇが存在しないことを規定し、ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇが存在することを規定する。
ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが存在しないことを規定し、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが存在することを規定する。
ｓｌｉｃｅ＿ｉｄ＿ｓｉｇｎａｌｌｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇが存在しないことを規定し、ｓｌｉｃｅ＿ｉｄ＿ｓｉｇｎａｌｌｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇが存在することを規定する。
ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝０は、ｍｉｘｅｄ＿ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅｓ＿ｆｌａｇが存在しないことを規定し、ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１は、ｍｉｘｅｄ＿ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅｓ＿ｆｌａｇが存在することを規定する。
ｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ＝０は、デコーディング制御ＲＢＳＰシンタックス構造中にｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素が存在しないことを規定する。ｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ＝１は、デコーディング制御ＲＢＳＰシンタックス構造中にｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素が存在することを規定する。
制御シンタックス要素のセマンティクスは、以下のように規定され得る。セマンティクスにおいて、このデコーディング制御ＮＡＬ単位と関連付けられたコード化画像は、このデコーディング制御ＮＡＬ単位を含むとともに、このデコーディング制御ＮＡＬ単位と同じＮｕｈＬａｙｅｒＩｄ値を有するアクセス単位に含まれるコード化画像である。
ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄは（存在する場合）、このデコーディング制御ＲＢＳＰを含むアクセス単位から、ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄを有するデコーディング制御ＮＡＬ単位を含むデコーディング順序の次のアクセス単位まで、その単位は除いて適用されるＴａｒｇｅｔＬａｙｅｒＩｄの値を規定する。ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄを有するデコーディング制御ＮＡＬ単位がビットストリームの最初のアクセス単位に存在しない場合は、ビットストリームの先頭から、ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄを有するデコーディング制御ＮＡＬ単位を含むデコーディング順序の最初のアクセス単位まで、その単位は除いて、ＴａｒｇｅｔＬａｙｅｒＩｄがｖｐｓ＿ｉｎｃｌｕｄｅｄ＿ｌａｙｅｒ＿ｉｄ［０］に等しく設定される。アクセス単位の複数のデコーディング制御ＮＡＬ単位に存在する場合は、アクセス単位中のすべてのｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄ値が同じであるものとする。ｔａｒｇｅｔ＿ｌａｙｅｒ＿ｉｄを有するデコーディング制御ＮＡＬ単位は、ＣＶＳＳアクセス単位ではないアクセス単位に存在しないものとする。
ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄは（存在する場合）、このデコーディング制御ＲＢＳＰを含むアクセス単位から、ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄを有するデコーディング制御ＮＡＬ単位を含むデコーディング順序の次のアクセス単位まで、その単位は除いて適用されるＨｉｇｈｅｓＴｉｄの値を規定する。ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄを有するデコーディング制御ＮＡＬ単位がビットストリームの最初のアクセス単位に存在しない場合は、ビットストリームの先頭から、ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄを有するデコーディング制御ＮＡＬ単位を含むデコーディング順序の最初のアクセス単位まで、その単位は除いて、ＨｉｇｈｅｓＴｉｄがｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１に等しく設定される。アクセス単位の複数のデコーディング制御ＮＡＬ単位に存在する場合は、アクセス単位中のすべてのｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄ値が同じであるものとする。ｈｉｇｈｅｓｔ＿ｔｅｍｐｏｒａｌ＿ｉｄを有するデコーディング制御ＮＡＬ単位は、ＣＶＳＳアクセス単位ではないアクセス単位に存在しないものとする。
ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇは（存在する場合）、このデコーディング制御ＮＡＬ単位と関連付けられたコード化画像のＨａｎｄｌｅＡｓＣｖｓＳｔａｒｔＦｌａｇの値を規定する。このデコーディング制御ＮＡＬ単位と関連付けられたコード化画像がＩＲＡＰ画像でもＧＲＡ画像でもない場合は、ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇが存在しないものとする。ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇを含み、ＮｕｈＬａｙｅｒＩｄの同じ値を有する複数のデコーディング制御ＮＡＬ単位がアクセス単位に存在する場合は、これらのデコーディング制御ＮＡＬ単位中のすべてのｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇ値が同じであるものとする。ｈａｎｄｌｅ＿ａｓ＿ｃｖｓ＿ｓｔａｒｔ＿ｆｌａｇ＝１のデコーディング制御ＮＡＬ単位がコード化画像と関連付けられていない場合は、当該コード化画像に対して、ＨａｎｄｌｅＡｓＣｖｓＳｔａｒｔＦｌａｇが０に等しく設定される。
ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇは（存在する場合）、このデコーディング制御ＮＡＬ単位と関連付けられたコード化画像のＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇの値を規定する。このデコーディング制御ＮＡＬ単位と関連付けられたコード化画像がＩＤＲ画像でない場合は、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが存在しないものとする。ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇを含み、ＮｕｈＬａｙｅｒＩｄの同じ値を有する複数のデコーディング制御ＮＡＬ単位がアクセス単位に存在する場合は、これらのデコーディング制御ＮＡＬ単位中のすべてのｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ値が同じであるものとする。
特定のＮｕｈＬａｙｅｒＩｄ値を有するデコーディング制御ＮＡＬ単位においてｓｌｉｃｅ＿ｉｄ＿ｓｉｇｎａｌｌｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１の場合は、このデコーディング制御ＮＡＬ単位を含むアクセス単位から、同じ特定のＮｕｈＬａｙｅｒＩｄ値を有し、ｓｌｉｃｅ＿ｉｄ＿ｓｉｇｎａｌｌｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１のデコーディング制御ＮＡＬ単位を含むデコーディング順序の次のアクセス単位まで、その単位は除いて、またはＣＬＶＳの終端のうち、デコーディング順序でいずれか早い方まで、当該特定のＮｕｈＬａｙｅｒＩｄ値を有するコード化画像に対して、ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ、ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１（存在する場合）、ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１（存在する場合）、およびｓｌｉｃｅ＿ｉｄ［ｉ］（存在する場合）が適用される。そして、以下のセマンティクスが適用される。
ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ＝０は、ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１、ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１、およびｓｌｉｃｅ＿ｉｄ［ｉ］が存在しないことを規定する。ｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｆｌａｇ＝１は、ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１、ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１、およびｓｌｉｃｅ＿ｉｄ［ｉ］が存在することを規定する。
ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１は、シンタックス要素ｓｌｉｃｅ＿ｉｄ［ｉ］を表すのに用いられるビットの数を規定する。ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値は、０～１５の範囲であるものとする。コード化画像と関連付けられたｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値は、同じコード化画像に対してアクティブなＳＰＳまたはＰＰＳ中のｓｉｇｎａｌｌｅｄ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１に等しいものとする。
ｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１＋１は、ｓｌｉｃｅ＿ｉｄ［ｉ］シンタックス要素の数を規定する。コード化画像と関連付けられたｄｅｃｏ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１の値は、同じコード化画像に対してアクティブなＳＰＳまたはＰＰＳ中のｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１に等しいものとする。
ｓｌｉｃｅ＿ｉｄ［ｉ］は、ｉ番目のスライスのスライスＩＤを規定する。ｓｌｉｃｅ＿ｉｄ［ｉ］シンタックス要素の長さは、ｄｅｃｏ＿ｓｌｉｃｅ＿ｉｄ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１ビットである。存在しない場合、ｓｌｉｃｅ＿ｉｄ［ｉ］の値は、０～ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１の範囲の各ｉについて、ｉに等しいものと推測される。
ｍｉｘｅｄ＿ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅｓ＿ｆｌａｇは、変数ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇの導出に用いられる。ＣｕｒｒＰｉｃのすべてのＶＣＬ ＮＡＬ単位が同じＮａｌＵｎｉｔＴｙｐｅ値を有すること（０に等しい場合）、または、関連するコード化画像のＶＣＬ ＮＡＬ単位が異なるＮａｌＵｎｉｔＴｙｐｅ値を有し得ることを識別する変数ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇは、以下のように規定される。
ＣｕｒｒＰｉｃを含むアクセス単位において、ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ＝１のデコーディング制御ＮＡＬ単位が存在する場合、変数ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇは、デコーディング制御ＮＡＬ単位のｍｉｘｅｄ＿ｖｃｌ＿ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅｓ＿ｆｌａｇの値に等しく設定される。その他の場合、ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇは、０に等しく設定される。
ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇは、デコーディングプロセスにおいて、以下のように処理されるようになっていてもよい。
ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇ＝１の場合は、ＮａｌＵｎｉｔＴｙｐｅ値に関わらず、現在の画像をＴＲＡＩＬ画像として処理することにより、画像順序カウントに関する変数および関数が導出される。これは、画像の最初のスライスに対してのみ呼び出される必要がある。
ｍｉｘｅｄＶｃｌＮａｌＵｎｉｔＴｙｐｅｓＦｌａｇ＝０の場合は、基準画像マーキングのデコーディングプロセスが呼び出され、基準画像が「参照不使用」または「長期参照使用」とマーキングされるようになっていてもよい。これは、画像の最初のスライスに対してのみ呼び出される必要がある。基準画像マーキングプロセスでは、スライスヘッダに包含または参照される基準画像リストに含まれるすべての画像を「参照使用」として維持するとともに、（基準画像リストに含まれない）その他すべての画像を「参照不使用」とマーキングするようにしてもよい。
ｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、如何なる値であってもよい。デコーダは、すべてのｃｏｎｔｒｏｌ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素を無視するようにしてもよい。
以上、アクセス単位デリミタおよび異なるシンタックス要素を含むデコーディング制御ＮＡＬ単位について、実施形態を提示した。上記例示的な実施形態のいずれかのシンタックス要素の如何なる組み合わせにおいても、実施形態を同様に実現可能であることを理解する必要がある。
一実施形態において、デコーディング制御ＮＡＬ単位のシンタックスは、以下のうちの１つまたは複数を含む。
タイプシンタックス要素（たとえば、ｃｏｎｔｒｏｌ＿ｔｙｐｅと称する）であって、このＮＡＬ単位に含まれるデコーディング制御の種類をそれぞれ規定する規定値を有する。
指定タイプの制御の値を有するシンタックス要素、たとえば、ｃｏｎｔｒｏｌ＿ｖａｌｕｅと称するであって、このタイプ値によりシンタックス要素のデータ型が規定されていてもよい。
拡張ビットであって、たとえばｃｏｎｔｒｏｌ＿ｖａｌｕｅシンタックス要素の所定長の拡張に使用可能である。
本実施形態においては、以下のシンタックスが用いられるようになっていてもよい。
Figure 0007492978000011
すべてのソースビットストリームのエンコーディングは、ソースビットストリームからの独立コード化画像領域の抽出および同じ結合ビットストリームへの結合を可能にするように実行され得る。結果として、エンコーディングにより、以下を除いて、すべてのソースビットストリームのＳＰＳおよびＰＰＳが同一になり得る。
レベル（たとえば、ＳＰＳ）、
画像の幅および高さ（たとえば、ＳＰＳ）、
タイル／ブリック分離等、画像のイメージセグメントへの分離（たとえば、ＰＰＳ）、
長方形スライスが独立コード化画像領域として使用される場合の長方形スライス位置およびサイズ情報等、独立コード化画像領域の位置決めおよびサイズ（たとえば、ＰＰＳ）、
長方形スライスが独立コード化画像領域として使用される場合のスライスＩＤ割り当て等、たとえばＩＤを用いた独立コード化画像領域の指定位置への割り当て（たとえば、ＰＰＳ）。
スライスＩＤの長方形スライスへの割り当て（ＰＰＳ）は、独立コード化画像領域の位置決め情報として使用することも可能な１つの有効な選択肢と見なされる。ただし、その寄与は一般的に、独立コード化画像領域の空間的な場所の指定ならびに／またはスライスＩＤ、サブ画像ＩＤ、もしくは任意の類似シンタックス要素の値と空間的な場所との関連付けを可能にする如何なる種類の位置決め情報にも当てはまる。
以下、いくつかの実施形態に係る、ＳＰＳまたはＰＰＳ中のタイル、ブリック、および長方形スライスへの画像の分離の一部詳細を提供する。
一実施形態において、ＳＰＳシンタックスには、画像をタイル、ブリック、および長方形スライスに分離するシンタックス要素を含むが、これはゲーティングフラグによって調節される。この分離は、ＳＰＳにおいて規定されている場合、ＰＰＳには存在しない。この分離は、ＳＰＳにおいて規定されていない場合、ＰＰＳに存在する。
本実施形態においては、上記の表１、２、および３または同等のものに示したシンタックスおよびセマンティクスを使用可能である。
以下、エンコーディング、ストリーミングに対するコンテンツの可用化、および独立デコーディング可能な画像領域の結合の一例を提供する。
提示の例は、本明細書で先に提示した例の続きである。
本例において、独立コード化画像領域は、エンコーディングおよびデコーディングにおいて境界が画像境界のように処理される長方形スライスである。本例は、独立コード化画像領域の他の実現に対しても同様に実装可能であることを理解する必要がある。
エンコーダは、境界が画像境界のように処理される長方形スライスとして、各ソースビットストリームにおける（すなわち、コンテンツの各解像度・ビットレートバージョンにおける）独立コード化画像領域がエンコーディングされるように、エンコーディングを実行するようにしてもよい。
すべてのビットレート・解像度バージョンのエンコーディングは、任意のソースビットストリームからの独立コード化画像領域の同じ結合ビットストリームへの結合を可能にするように実行される。すべてのソースビットストリーム（たとえば、さまざまな解像度バージョン）のＳＰＳおよびＰＰＳは、画像の幅および高さ、画像のタイルおよび／もしくはブリックへの分離、長方形スライスの位置およびサイズ、ならびに長方形スライスのスキャン順序または位置へのスライスＩＤ値の割り当てに関するシンタックス要素を除いて、同一であってもよい。
ソースビットストリーム（すなわち、すべてのビットレート・解像度バージョン）のエンコーディングは、ビットストリームのｓｌｉｃｅ＿ａｄｄｒｅｓｓ値が重なり合わず、ｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素の長さがすべてのソースビットストリームにおいて同じになるように実行される。
一連の独立コード化画像領域は、受信する領域をクライアントが選択できるように、ストリーミングに対して利用可能とされる。たとえば、各独立コード化画像領域は、ＯＭＡＦに規定されるようなサブ画像トラックとしてカプセル化されていてもよい。
利用可能な一連の独立コード化画像領域から結合ビットストリームを生成するため、クライアント（または、クライアント内のプレーヤ）は、以下のステップを実行する。
プレーヤは、そのデコーディング能力に適した１つまたは複数のパラメータ集合を生成または受信する。たとえば、プレーヤは、「４Ｋ」デコーディング能力に適した１つまたは複数のパラメータ集合を生成するが、これは、最大画像サイズを「４Ｋ」（８ ９１２ ８９６輝度サンプル等）に制限すること、および／または、たとえば特定の画像レート（たとえば、６０Ｈｚ）での「４Ｋ」デコーディングに対応するように最大サンプルレートを制限することであってもよく、本例では、１秒当たり６０×８ ９１２ ８９６輝度サンプルに相当することになる。「４Ｋ」デコーディング能力の場合は、図１１ｂに記載のようなタイル分離がパラメータ集合においてエンコーディングされるようになっていてもよく、各タイルがそれ自体の長方形スライスに包含される。本例において、プレーヤは、４Ｋデコーディング能力を有するものと仮定する。一般的には、目標とするデコーディング能力の使用によって、結合ビットストリームの画像の幅および高さ、タイル／ブリック分離、長方形スライスの位置およびサイズ情報を選択することができる。
プレーヤは、受信する独立デコーディング可能な画像領域シーケンスの部分集合を選択するとともに、部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号を取得する。本例において、識別子番号は、長方形スライスのｓｌｉｃｅ＿ｉｄ（または、同等物としてのｓｌｉｃｅ＿ａｄｄｒｅｓｓ）値であり、識別子番号は、スライスのヘッダシンタックスに含まれる。
プレーヤは、選択した独立コード化画像領域のｓｌｉｃｅ＿ｉｄ値を含むデコーディング制御ＮＡＬ単位を生成する。
プレーヤは、選択した独立コード化画像領域のＶＣＬ ＮＡＬ単位を受信し、デコーディング制御ＮＡＬ単位の後に、デコーディング順序で配置する。
部分集合の選択からＶＣＬ ＮＡＬ単位の受信までの上記ステップは、たとえば視認方向の変化への応答として、独立コード化画像領域の新たな選択が必要となった場合にいつでも繰り返すことができる。
結合ビットストリームのほか、プレーヤが実行するステップを図１２ａに示す。
他の実施形態との併用または他の実施形態から独立した使用が可能な一実施形態によれば、デコーダは、
ビットストリームから、または、ビットストリームに伴う、デコーディング制御ＮＡＬ単位等の別個のデータ単位からのコード化画像シーケンスの画像上の独立コード化画像領域の順序をデコーディングし、
デコーディング順序の独立コード化画像領域を受信し、
次に受信した独立コード化画像領域が上記順序に従うかを調べ、
次に受信した独立コード化画像領域が上記順序に従わないことに応答して、当該順序の次の独立コード化画像領域と同位置の未コーディングの独立コード化画像領域をデコーディングする。
一実施形態において、未コード化の独立コード化画像領域のデコーディングまたは再構成は、たとえばコーディング規格において予め規定されている。このデコーディングでは、たとえば予測誤差なく参照使用とマーキングされた（ＰＯＣ差が）最も近い基準画像からのゼロ動きベクトルの相互予測等、特定の所定モードを使用するようにしてもよい。
一実施形態においては、所定の一定サンプル値での画像領域全体の再構成によって、未コード化の独立コード化画像領域がデコーディングされる。
未コード化の独立コード化画像領域のデコーディングまたは再構成によれば、未コード化の独立コード化画像領域が（３６０°ビデオの）表示域に現れない場合あるいは表示の必要がない場合に、再生の中断を回避可能となり得る。
一実施形態において、デコーダは、ＩＲＡＰ画像に由来する同位置の独立コード化画像領域が受信されるまで、後続画像における同位置の未コード化の独立コード化画像領域の挿入および／またはデコーディングを行うようにしてもよい。
以下、ビデオデコーダの出力として同期メタデータが提供されるべきかを示す一例を提供する。
他の実施形態との併用または他の実施形態から独立した使用が可能な一実施形態によれば、エンコーダ等のエンティティは、ビットストリームに含まれる第１のシンタックス構造において、当該第１のシンタックス構造に含まれるメタデータがデコーダによって出力されるべきかを示す。第１のシンタックス構造に含まれるメタデータは、たとえば第１のシンタックス構造全体または第１のシンタックス構造に含まれる第２のシンタックス構造を出力することにより出力されるようになっていてもよい。第１のシンタックス構造は、以下のいずれかであってもよいが、これらに限定されない。
ＳＥＩメッセージ
ＳＥＩ ＮＡＬ単位
デコーディング制御ＮＡＬ単位
ビデオユーザビリティ情報またはそれに含まれるシンタックス構造
第１のシンタックス構造における指標は、出力および／またはタイプ値の特定範囲を制御するフラグであってもよいが、これに限定されない。
出力を制御するフラグは、たとえば０に等しい場合に、第１のシンタックス構造に含まれるメタデータが出力されないことがあり、１に等しい場合に、第１のシンタックス構造に含まれるメタデータがデコーダによって出力されるべきであることを示すようにしてもよい。
タイプ値の特定範囲は、たとえばコーディング規格に規定のＳＥＩメッセージペイロードタイプ値の特定範囲がデコーダの出力となるように実装されていてもよい。
出力を制御するフラグを含むＳＥＩメッセージの例示的な一実施形態においては、以下のシンタックスが用いられるようになっていてもよい。
Figure 0007492978000012
一実施形態によれば、ｓｅｉ＿ｏｕｔｐｕｔ＿ｆｌａｇ＝１は、ＳＥＩメッセージが関連付けられたコード化画像をデコーディングした結果としてのデコーディング・クロッピング画像とともにＳＥＩメッセージが出力されることを規定する。ｓｅｉ＿ｏｕｔｐｕｔ＿ｆｌａｇ＝０は、ＳＥＩメッセージが関連付けられたコード化画像をデコーディングした結果としてのデコーディング・クロッピング画像とともにＳＥＩメッセージが出力されてもよいし、出力されなくてもよいことを規定する。
一実施形態において、デコーダ等のエンティティは、ビットストリームに含まれる第１のシンタックス構造から、当該第１のシンタックス構造に含まれるメタデータがデコーダによって出力されるべきかをデコーディングする。
一実施形態において、画像が出力される場合、デコーダ等のエンティティは、ｓｅｉ＿ｏｕｔｐｕｔ＿ｆｌａｇ＝１かつ画像と関連付けられたＳＥＩメッセージを（画像を伴って）出力する。
第１のシンタックス構造を含むコード化画像をデコーディングした結果としてのデコード画像に伴う、第１のシンタックス構造に含まれるメタデータが受け渡されるか、あるいは、第１のシンタックス構造の範囲のすべてのデコード画像に伴う、第１のシンタックス構造に含まれるメタデータが受け渡されるかが、たとえばコーディング規格において予め規定されていてもよいし、シンタックス要素における指定またはシンタックス要素からのデコーディングが行われるようになっていてもよい。
一実施形態において、エンティティは、時間的範囲を第１のシンタックス構造においてエンコーディングする。一実施形態において、エンティティは、時間的範囲を第１のシンタックス構造からデコーディングする。時間的範囲としては、単一のＶＣＬ ＮＡＬ単位、単一のコード化画像、アクセス単位（潜在的に複数のコード化画像を含む）（同じ種類のコンテンツを含む次のデリミタＮＡＬ単位またはコード化ビデオシーケンスの終端（いずれか早い方））、コード化ビデオシーケンス、ビットストリームが挙げられるが、これらに限定されない。
一実施形態において、エンティティは、レイヤ単位の範囲を第１のシンタックス構造においてエンコーディングする。一実施形態において、エンティティは、レイヤ単位の範囲を第１のシンタックス構造からデコーディングする。レイヤ単位の範囲は、第１のシンタックス構造に含まれるメタデータの範囲にあるレイヤを示す。
一実施形態において、結合ビットストリームを生成するプレーヤ等のエンティティは、独立コード化画像領域シーケンスの部分集合のレンダリングを示す第１のシンタックス構造を結合ビットストリームにおいて生成する。第１のシンタックス構造は、独立コード化画像領域シーケンスの空間的位置を追加で示していてもよい。たとえば、エンティティは、投影画像上の独立コード化画像領域の場所を示すＨＥＶＣの領域単位のパッキングＳＥＩメッセージまたは類似のシンタックス構造を生成するようにしてもよい。エンティティは、ｓｅｉ＿ｏｕｔｐｕｔ＿ｆｌａｇ＝１または類似の指標によって、第１のシンタックス構造の範囲のデコード画像とともに第１のシンタックス構造中のメタデータが出力されるべきものと示すようにしてもよい。
一実施形態によれば、ＨＲＤ管理のためにＮＡＬ単位がＣＰＢに含まれるかが示される。たとえば、デコーディング制御ＮＡＬ単位および／またはＳＥＩ ＮＡＬ単位シンタックスには、ＮＡＬ単位がＣＰＢに含まれるかを規定したシンタックス要素を含んでいてもよい。一実施形態において、プレーヤまたは同等のものは、デコーディング制御ＮＡＬ単位および／またはＳＥＩ ＮＡＬ単位をビットストリームにおいて生成し、ＮＡＬ単位がＣＰＢに含まれないことを示すようにシンタックス要素を設定する。
本発明は、任意特定の種類の構成ビットストリームに限定されないことが了解されるものとする。たとえば、構成ビットストリームは、以下のうちのいずれかを表し得る。
ビデオの時空間分離の区分（すなわち、サブ画像シーケンス）
立体視またはマルチビュービデオのビュー
３６０°投影の投影構造の表面（多面３６０°投影（たとえば、キューブマップ）の各面等）
領域単位のパッキング情報により示されるようなパッキング領域
ビデオの多重解像度パッキングの空間的に連続する単一解像度部分（たとえば、多重解像度ＥＲＰまたはＣＭＰ）
表面に投影された点群の部分またはパッチ（テクスチャまたは深度）、サブ画像シーケンスが各パッチを後続の時間インスタンスに含んでいてもよい、複数のパッチが単一のサブ画像に集約されていてもよい
サブ画像としてコード化された１つまたは複数の関心領域
サブ画像シーケンスとしての異なるソース（たとえば、異なるカメラ）からのコード化ビデオ、たとえば、多地点ビデオ会議に用いられるようになっていてもよい
他の設計上の決定たとえば、コンテナシンタックス構造、ＶＣＬ ＮＡＬ単位ではなくイメージセグメントに対するマッピング、およびサブ画像シーケンスではなくサブ画像に対するマッピングによっても同様に、他の実施形態を実現可能であることが了解されるものとする。
以下、たとえば表示域に応じた３６０°ビデオストリーミング、スケーラブルなマルチビュー立体視ビデオのコーディング、重なり合う多面コンテンツのコーディング、点群コンテンツのコーディングの観点から、サブ画像ベースの（デ）コーディングを用いたいくつかの例示的な実施形態について論じる。
表示域に応じた３６０°ビデオストリーミング
一例によれば、コード化サブ画像シーケンスがコンテナファイルのトラックにカプセル化されてもよく、トラックがＳｅｇｍｅｎｔおよび／またはＳｕｂｓｅｇｍｅｎｔに分離されてもよく、ストリーミングマニフェスト（たとえば、ＭＰＥＧ－ＤＡＳＨ ＭＰＤ）におけるＲｅｐｒｅｓｅｎｔａｔｉｏｎの生成によって、リクエストにより（Ｓｕｂ）ｓｅｇｍｅｎｔが利用可能にされるとともに、コード化サブ画像シーケンスの特性が発表されるようになっていてもよい。前文のプロセスは、コード化サブ画像シーケンスそれぞれに実行されるようになっていてもよい。
一例によれば、クライアント装置は、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎのマニフェスト情報からおよびマニフェストから、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎそれぞれの球状領域をパーシングするように構成されていてもよい。また、クライアント装置は、球状領域の品質を示すマニフェスト値ならびに／または球状領域もしくはそれぞれの２Ｄ投影の解像度情報からパーシングを行うようにしてもよい。クライアント装置は、その使用に適したＲｅｐｒｅｓｅｎｔａｔｉｏｎを決定する。たとえば、クライアント装置は、ヘッドマウントディスプレイ使用時の頭部の方向を検出するとともに、他の領域に関して選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎよりも高い品質で表示域を網羅するＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択する手段を具備していてもよい。選択の結果として、クライアント装置は、選択したＲｅｐｒｅｓｅｎｔａｔｉｏｎの（Ｓｕｂ）ｓｅｇｍｅｎｔを要求するようにしてもよい。
一例によれば、コード化画像またはファイルフォーマットサンプルのデコーディング順序が分解される。選択したＲｅｐｒｅｓｅｎｔａｔｉｏｎの受信（Ｓｕｂ）ｓｅｇｍｅｎｔから、時間合わせされたコード化画像またはファイルフォーマットサンプルがパーシングされる。時間合わせされたコード化画像またはファイルフォーマットサンプルのデコーディング順序の決定には、マージベーストラックが用いられるようになっていてもよい。デリミタが結合ビットストリームに書き込まれるが、これらのデリミタは、当該デリミタと関連付けられたデータ単位が由来するＲｅｐｒｅｓｅｎｔａｔｉｏｎを示す。そして、結合ビットストリームがデコーディングのために受け渡される。
一例によれば、サブ画像シーケンスを用いて、同じコンテンツが複数の解像度および／またはビットレートでコーディングされる。たとえば、３６０°コンテンツの異なる部分が異なる表面に投影されてもよく、投影面が異なる解像度へとダウンサンプリングされるようになっていてもよい。たとえば、現在の表示域にない面が低い解像度へとダウンサンプリングされるようになっていてもよい。各面は、サブ画像としてコーディングされるようになっていてもよい。
一例によれば、サブ画像シーケンスを用いて、同じコンテンツが異なるランダムアクセス区間でコーディングされる。
上述の実施形態を補完するとともに、これらの実施形態内で使用することも可能な一例によれば、視認方向の変化によって、以前と一部異なるＲｅｐｒｅｓｅｎｔａｔｉｏｎの選択が要求される。サブ画像シーケンスが別個のレイヤとして表される場合は、サブ画像シーケンスを搬送する適当なレイヤに対して、デリミタが先行するＥＯＳ ＮＡＬ単位が具体的に書き込まれることで、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの受信および／またはデコーディングの中断が選択されたことを示すようにしてもよい。要求される新たなＲｅｐｒｅｓｅｎｔａｔｉｏｎは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにおいて搬送されたサブ画像シーケンス内の次のランダムアクセス位置から要求されるようになっていてもよいし、それぞれのデコーディングが開始されるようになっていてもよい。複数のランダムアクセス区間でサブ画像シーケンスが利用可能とされた場合は、ランダムアクセス位置が少ない各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎから、ランダムアクセス位置を含む類似品質の次の（Ｓｕｂ）ｓｅｇｍｅｎｔが入手可能となるまで、視認方向の変化に対する応答として、ランダムアクセス位置が多いＲｅｐｒｅｓｅｎｔａｔｉｏｎが要求されるようになっていてもよい。視認方向の変化への応答として変化する必要のないＲｅｐｒｅｓｅｎｔａｔｉｏｎは、ランダムアクセス位置を有する必要もない。上述の通り、サブ画像は、さまざまなサブ画像タイプまたはＮＡＬ単位タイプを有することが許可されていてもよい。たとえば、特定のアクセス単位または時間インスタンスのサブ画像がランダムアクセスタイプである一方、同じ特定のアクセス単位または時間インスタンスの別のサブ画像は、非ランダムアクセスタイプであってもよい。このように、ランダムアクセス区間が異なるビットストリームのサブ画像を組み合わせることができる。
表示域に応じた３６０°ストリーミングに本発明を使用する利益として、以下が挙げられる。
表示域に応じたストリーミングにおいては、ＭＣＴＳの結合に抽出器トラックもタイルベーストラックも一切不要である。サブ画像シーケンスは、どの組のサブ画像シーケンスがデコーディングのために受信また受け渡しされるかに関わらず、修正なしにデコーディング可能なためである。これにより、コンテンツ生成負荷が軽減され、クライアントの動作が簡素化される。
後期バインディング（ｌａｔｅ ｂｉｎｄｉｎｇ）に基づく表示域に応じたストリーミングにおいては、ＶＣＬ ＮＡＬ単位を変更する必要がない。サブ画像シーケンスは、どの組のサブ画像シーケンスがデコーディングのために受信また受け渡しされるかに関わらず、修正なしにデコーディング可能なためである。これにより、クライアント実装の複雑性が低減される。
画像サイズは、ピクセルに関して一定でなくてもよい。この利点は、共有コード化サブ画像の使用に際して明らかとなり、共有コード化サブ画像を含む時間インスタンスにおいては、他の時間インスタンスよりも多くのピクセルがデコーディングされ得る。
表示域のサイズおよび頭部の動きの範囲に応じて、サブ画像の数を柔軟に選定可能である。従来技術の一部の方法では、サブ画像トラックのコンテンツを単一のビットストリームとして結合する抽出器トラックの生成に際して、サブ画像トラックの数が予め規定されていた。
デコーディング能力および／または受信データの可用性に応じて、サブ画像の数を柔軟に選定可能である。たとえばリソースを共有するマルチプロセスまたはマルチタスクシステムにおいて、デコードサブ画像の数は、利用可能なデコーディング能力に応じて動的に選定可能である。特定の時間インスタンスのコード化データは、それに対して要求された一部のサブ画像が未受信であっても、デコーディングのために受け渡し可能である。このため、サブ画像シーケンスの部分集合のみに関する配信遅延によって、他のサブ画像シーケンスのデコーディングおよび再生が行き詰まることはない。
任意の共有コード化サブ画像および／またはランダムアクセスサブ画像において、ビットレートおよび受信サブ画像の切り替えが発生し得る。共有コード化サブ画像および／またはランダムアクセスサブ画像の異なる区間において、複数のバージョンのコンテンツをエンコーディング可能である。デコーディングビットストリームにおいては、共有コード化サブ画像および／またはランダムアクセスサブ画像がすべてのサブ画像シーケンスにおいて位置合わせされる必要がないため、切り替え時に、および／またはランダムアクセス特性が上記サブ画像シーケンスにのみある場合、必要に応じて良好なレート歪み効率の実現が可能である。
上述の通り、使用事例に応じて、用語「サブ画像（ｓｕｂ－ｐｉｃｔｕｒｅ）」は、さまざまな使用事例および／または投影の種類を表し得る。次に、これらの使用事例のうちの一部の観点から、サブ画像のコーディングに関連する例について論じる。
重なり合う多面コンテンツのコーディング
一例によれば、３６０°コンテンツの異なる部分が異なる表面に投影されてもよく、投影面が重なり合うコンテンツを有していてもよい。別の実施形態においては、コンテンツが重なり合う複数の領域（たとえば、タイル）へとコンテンツが分割されるようになっていてもよい。各面または領域は、サブ画像としてコーディングされるようになっていてもよい。各サブ画像は、他のサブ画像の一部を基準フレームとして使用するようにしてもよく、これは、２つの例に関する図１２ａおよび図１２ｂにおいて、重なり合わないコンテンツを白色ボックスで示し、重なり合うエリアを灰色で示し、サブ画像中の対応する部分を破線の長方形で示した通りである。サブ画像と他のサブ画像とが空間的に関連する様式を示すのに、空間的関係の情報を使用することも可能である。
点群コンテンツのコーディング
一例によれば、点群コンテンツの各部が表面に投影されて、パッチが生成される。各パッチは、サブ画像としてコーディングされるようになっていてもよい。異なるパッチが冗長データを有していてもよい。各サブ画像が他のサブ画像を使用して、この冗長を補償するようにしてもよい。図１２ｂの例においては、点群の異なる部分が表面１および表面２に投影されて、それぞれパッチ１およびパッチ２が生成されている。各パッチは、サブ画像としてコーディングされる。本例においては、ｃ、ｄ、ｅで示される点群コンテンツの部分が２つの表面に対して冗長に投影されているため、対応するコンテンツがパッチ１およびパッチ２において冗長となっている。図１２ｂにおいては、サブ画像１から予測可能なサブ画像２の部分を破線ボックスで示している。再構成サブ画像の集まりが出力画像を構成していてもよい。あるいは、再構成サブ画像が２Ｄ出力画像として配置されていてもよい。
エンコーディングの一例によれば、第２のＰＣＣレイヤのパッチが第２のサブ画像としてコーディングされ、第１のＰＣＣレイヤの各パッチの再構成サブ画像と予測される。同様に、デコーディングの一実施形態によれば、第２のＰＣＣレイヤのパッチを表す第２のサブ画像がデコーディングされるが、このデコーディングには、第１のＰＣＣレイヤの各パッチを表す再構成サブ画像からの予測を含む。
一例によれば、異なる画像レートおよび／または異なる数のサブレイヤにおいて、サブ画像シーケンスのエンコーディング、要求、送信、受信、および／またはデコーディングが意図的に行われる。本実施形態は、たとえば特定の時間におけるレンダリングにコンテンツの一部のみを要する場合に適用可能である。たとえば、３６０°ビデオにおいては、特定の時間におけるレンダリングに表示域のみが必要とされ、点群コーディングおよびボリュメトリックビデオにおいては、レンダリングに必要な部分が視認位置および視認方向によって決まり得る。レンダリングに必要なサブ画像シーケンスの画像レートおよび／またはサブレイヤ数は、（エンコーディング、要求、送信、受信、および／またはデコーディングにおいて）レンダリングに不要なサブ画像シーケンスよりも大きく選択すること、ならびに／または、（たとえば、視認方向の変化に対応するため）直ちにレンダリングに必要となる可能性が低くなるように選択することが行われるようになっていてもよい。上記構成により、必要となるデコーディング能力および電力消費が削減され得る。あるいは、たとえば実時間再生よりも高速になるように、配信および／またはデコーディングの高速化が実現され得る。より多くのサブレイヤにおけるサブ画像シーケンスのデコーディングが望まれる場合は（たとえば、視認方向の変化に対応するため）、ＨＥＶＣのＴＳＡおよび／またはＳＴＳＡ画像等のサブレイヤアクセス画像の使用によって、サブレイヤのエンコーディング、要求、送信、受信、および／またはデコーディングを再開するようにしてもよい。
一例によれば、他のサブ画像シーケンスから予測されないサブ画像シーケンスの最も低いサブレイヤにおいて、ＴＳＡサブ画像または同等のものをエンコーディング可能である。このＴＳＡサブ画像は、このＴＳＡ画像を起点としてサブ画像シーケンスのすべてのサブレイヤが予測可能であることを示す。一実施形態によれば、他のサブ画像シーケンスから予測されないサブ画像シーケンスの最も低いサブレイヤから、ＴＳＡサブ画像または同等のものがデコーディングされる。一実施形態においては、このＴＳＡサブ画像を起点として、最も低いサブレイヤ上の任意のサブレイヤの要求、送信、受信、および／またはデコーディングを開始可能であり、その結果として、このような要求、送信、受信、および／またはデコーディングが発生するものと判定される。
本実施形態は、いくつかの利点を提供し得る。結合ビットストリームの生成に際しては、独立コード化画像領域のスライスヘッダを書き換える必要がない。結合ビットストリームに対しては、一組のパラメータ集合だけが必要であり、ソースビットストリームのパラメータ集合を１対１で照合する。コンテンツ製作者は、メディアプレゼンテーション記述において、潜在的な結合ビットストリームのパラメータ集合を提供可能であり、このため、クライアントは、パラメータ集合を生成する必要もなければ、書き換える必要もない。独立コード化画像領域の位置決め情報は、別個のデータ単位（デコーディング制御ＮＡＬ単位等）ではなく、パラメータ集合シンタックスに含めることも可能である。ただし、このような手法は、以下に分析するように、最適ではない。
独立コード化画像領域の位置決め情報がＳＰＳに存在する場合、一般的には、独立コード化画像領域の部分集合のみがＩＲＡＰ画像に由来するように、異なるＶＣＬ ＮＡＬ単位タイプの同じコード化画像での結合によって、表示域に応じた３６０°ストリーミングにおける視認方向の変化を取り扱い可能となり得ることはない。独立コード化画像領域の位置決め情報がＳＰＳに存在する場合は、結合ビットストリーム中のＩＲＡＰ画像においてのみ、独立コード化画像領域の新たな選択をアクティブ化可能である。
独立コード化画像領域の位置決め情報がＰＰＳに存在する場合、クライアントは、独立コード化画像領域の新たな選択がなされるたびに、ＰＰＳを書き換える必要がある。この書き換えには、位置決め情報と関連しないシンタックス要素、可変長コードワード、ならびにシンタックス要素値に応じて条件付きで存在するコードワードもしくはアクティブなＳＰＳから導出された変数のパーシング等、ソースビットストリームからのＰＰＳ全体のパーシングが必要となる。
一般事項
上述の実施形態は、ビデオベースの点群コーディング、パッチベースのボリュメトリックビデオコーディング、複数の投影面を伴う３６０°ビデオコーディング等、多くのビデオベースの目的に対してコアビデオ（デ）コーディングプロセスおよびビットストリームフォーマットを汎用的に使用するメカニズムおよびアーキテクチャを提供する。
上述の実施形態は、単一レイヤ２Ｄビデオコーデックを追加の機能と相互作用させるのに適する。
図１４ａは、一実施形態に係る、方法を示したフローチャートである。この方法は、コード化ビデオコンテンツを表す独立デコーディング可能な画像領域シーケンスの部分集合を選択することを含む（図１４ａのブロック１５１）。そして、部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号が取得される（１５２）。コード化画像シーケンスの画像上の独立デコーディング可能な画像領域の順序が決定される（１５３）。この順序が別個のデータ単位として、ビットストリームにおいてエンコーディングされる（１５４）。データ単位には、部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号のリストを含む。コード化画像シーケンスは、別個のデータ単位の後に、ビットストリームに含まれる（１５５）。
図１４ｂは、別の実施形態に係る、方法を示したフローチャートである。この方法は、コード化ビデオコンテンツを表す独立デコーディング可能な画像領域シーケンスを取得することを含む（図１４ｂのブロック１５６）。そして、独立デコーディング可能な画像領域シーケンスの識別子番号が取得される（１５７）。その後、独立デコーディング可能な画像領域を個々にアクセス可能とすることにより、メディアプレゼンテーション記述が生成され（１５８）、メディアプレゼンテーション記述において、識別子番号が独立デコーディング可能な画像領域シーケンスに割り当てられる（１５９）。
一実施形態に係る装置は、少なくとも１つのプロセッサおよびコンピュータプログラムコードを含む少なくとも１つのメモリを備え、メモリおよびコンピュータプログラムコードは、少なくとも１つのプロセッサによって、
コード化ビデオコンテンツを表す独立デコーディング可能な画像領域シーケンスの部分集合を選択することと、
部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号を取得することと、
コード化画像シーケンスの画像上の独立デコーディング可能な画像領域の順序を決定することと、
部分集合の独立デコーディング可能な画像領域シーケンスの識別子番号のリストを含む別個のデータ単位として、上記順序をビットストリームにおいてエンコーディングすることと、
コード化画像シーケンスを別個のデータ単位の後に、ビットストリームに含めることと、
を少なくとも当該装置に実行させるように構成されている。
装置１２００、たとえば、エンコーディングおよび／またはデコーディングのための装置の一例を図１５に示す。システムの機能ブロックに従って、装置の一般化構造を説明する。単一の物理デバイスによって、複数の機能を実行可能である。たとえば、すべての計算手順を必要に応じて、単一のプロセッサで実行可能である。図１５の一例に係る装置のデータ処理システムは、主処理ユニット１００、メモリ１０２、記憶装置１０４、入力装置１０６、出力装置１０８、およびグラフィックスサブシステム１１０を備え、これらがすべて、データバス１１２を介して互いに接続されている。
主処理ユニット１１０は、データ処理システム内のデータを処理するように構成された従来の処理ユニットであってもよい。主処理ユニット１００は、１つもしくは複数のプロセッサまたはプロセッサ回路を備えていてもよいし、１つもしくは複数のプロセッサまたはプロセッサ回路として実装されていてもよい。メモリ１０２、記憶装置１０４、入力装置１０６、および出力装置１０８は、当業者が認識する従来のコンポーネントを含んでいてもよい。メモリ１０２および記憶装置１０４は、データ処理システム１００中のデータを格納する。コンピュータプログラムコードがメモリ１０２に存在して、たとえば実施形態に係る方法を実現する。入力装置１０６がデータをシステムに入力する一方、出力装置０８は、データ処理システムからデータを受信し、たとえばディスプレイにデータを転送する。データバス１１２は、従来のデータバスであり、単一の線として示しているが、プロセッサバス、ＰＣＩバス、グラフィカルバス、ＩＳＡバスの如何なる組み合わせであってもよい。したがって、当業者には、コンピュータ機器、パソコン、サーバコンピュータ、携帯電話、スマートフォン、またはインターネットアクセス機器、たとえば、インターネットタブレットコンピュータ等、上記装置が如何なるデータ処理機器であってもよいことが容易に認識される。
いくつかの実施形態によれば、サブ画像シーケンスのエンコーディングは、ビットストリームのエンコーディング等の従来のように、すなわち、他のサブ画像シーケンスとの結合を考慮することなく実行可能である。
デリミタデータ単位を用いた実施形態では、サブ画像シーケンス識別子（または、レイヤ識別子）のエンコーディングが不要である。これは、少なくとも以下のような利益をもたらし得る。第一に、エンコーディングに異なるエンコーダが使用される場合であっても、同じサブシーケンス識別子の使用によるクラッシュの危険がなく、第二に、サブ画像シーケンス識別子を伝送するビットレートの節約になる。
レイヤ識別子を書き換える実施形態において、サブ画像シーケンスの数は、レイヤ識別子の値範囲制限が許可するレイヤ数よりも多くなり得る。たとえば、ＨＥＶＣの６ビットｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴う表示域に応じた３６０°ビデオストリーミングには、９６個のサブ画像シーケンスを使用することも可能である。
さらに、コード化サブ画像シーケンスを単一のビットストリームとして結合する場合には、ＶＣＬ ＮＡＬ単位ならびに大抵もしくは全部の非ＶＣＬ ＮＡＬ単位のペイロードの書き換えが不要である。
サブ画像シーケンスまたは独立レイヤまたは同等のものをＭＣＴＳまたは同等のものと併用可能であることに留意するものとする。デコーダの実施態様ならびに／またはコーディングプロファイルもしくはレベルでは、サブ画像シーケンスまたは独立レイヤまたは同等のものの数が制限されていてもよい。用途または使用事例により、大量の独立デコーディング可能な時空間単位が必要な場合は、サブ画像シーケンスまたは独立レイヤまたは同等のものに２つ以上のＭＣＴＳを含むのが妥当と考えられる。
メモリに存在して、関連する装置に上記方法を実行させるコンピュータプログラムコードによって、種々実施形態を実装可能である。たとえば、機器は、データの取り扱い、受信、および送信を行う回路および電子機器と、メモリ中のコンピュータプログラムコードと、コンピュータプログラムコードを実行した場合に、一実施形態の特徴を当該機器に実行させるプロセッサと、を含んでいてもよい。さらに、サーバ等のネットワーク機器は、データの取り扱い、受信、および送信を行う回路および電子機器と、メモリ中のコンピュータプログラムコードと、コンピュータプログラムコードを実行した場合に、一実施形態の特徴を当該ネットワーク機器に実行させるプロセッサと、を含んでいてもよい。コンピュータプログラムコードは、１つまたは複数の動作特性を含む。前記動作特性は、前記プロセッサの種類に基づいて、前記コンピュータによる設定により規定されており、システムは、バスによって前記プロセッサに接続可能であり、システムのプログラム可能な動作特性には、第１のビットストリームおよび第２のビットストリームへと論理的に分離されたデータ単位を受信することと、第１のビットストリームおよび第２のビットストリームを結合ビットストリームとして結合することと、を含み、この結合には、結合ビットストリームにおいてデリミタと関連付けられた１つまたは複数のデータ単位が、第１および第２のビットストリームのどちらに割り当てられるのかを示すデリミタを結合ビットストリームに書き込むことを含む。
本明細書に記載のさまざまな機能は、必要に応じて、異なる順序での実行および／または他の機能との同時実行が行われるようになっていてもよい。さらに、上述の機能および実施形態のうちの１つまたは複数が必要に応じて任意選択であってもよいし、組み合わされていてもよい。
上記では、エンコーダを参照して例示的な実施形態を説明したが、結果としてのビットストリームおよびデコーダが対応する要素をそれぞれに有していてもよいことを理解する必要がある。
同様に、デコーダを参照して例示的な実施形態を説明したが、デコーダによりデコーディングされるビットストリームを生成する構造および／またはコンピュータプログラムをエンコーダが有していてもよいことを理解する必要がある。
上記では、シンタックスおよびセマンティクスを参照して例示的な実施形態を説明したが、これらシンタックスおよびセマンティクスに従ってビットストリーム部を出力するエンコーダを実施形態が同様に網羅することを理解する必要がある。同様に、上記実施形態は、シンタックスおよびセマンティクスに従ってビットストリーム部をデコーディングするデコーダを網羅する。
上述の本発明の実施形態は、別個のエンコーダ・デコーダ装置の観点でコーデックを説明することにより、それに伴うプロセスの理解を助けるものである。ただし、当然のことながら、上記装置、構造、および動作は、単一のエンコーダ・デコーダ装置／構造／動作として実装されていてもよい。さらに、コーダおよびデコーダは、一部または全部の共通要素を共有することも可能である。
本発明のいくつかの実施形態は、装置内のコーデック動作を記載するが、当然のことながら、特許請求の範囲に規定の本発明は、如何なるシステムまたは環境内の如何なるビデオコーデックの一部として実現されていてもよい。したがって、たとえば、本発明の実施形態は、固定または有線通信経路上でビデオコーディングを実装し得るビデオコーデックにおいて実現されていてもよい。
実施形態の種々態様を独立請求項に記載するが、他の態様として、特許請求の範囲に明示的に記載する組み合わせのみならず、上記実施形態および／または従属請求項による特徴と独立請求項による特徴との他の組み合わせが挙げられる。

Claims (15)

  1. ビデオビットストリームのシンタックス構造において、コード化ビデオシーケンスの実際の最も高い時間的サブレイヤを指定する手段であり、前記コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたは前記ビットストリームの終端が後続するデコーディング順序の一連のコード化画像である、指定する手段を備えた装置。
  2. 前記シンタックス構造において、前記コード化ビデオシーケンスにより表される出力レイヤ集合を指定する手段であり、前記出力レイヤ集合が、デコーダによる出力が意図される出力レイヤとして１つまたは複数のレイヤが規定された一組のレイヤを含み、前記ビットストリームが、任意数の出力レイヤ集合を規定し得る、指定する手段をさらに備えた、請求項１に記載の装置。
  3. ビデオビットストリームのシンタックス構造から、コード化ビデオシーケンスの実際の最も高い時間的サブレイヤをデコーディングする手段であり、前記コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたは前記ビットストリームの終端が後続するデコーディング順序の一連のコード化画像である、デコーディングする手段を備えた装置。
  4. 前記シンタックス構造から、前記コード化ビデオシーケンスにより表される出力レイヤ集合をデコーディングする手段であり、前記出力レイヤ集合が、デコーダによる出力が意図される出力レイヤとして１つまたは複数のレイヤが規定された一組のレイヤを含み、前記ビットストリームが、任意数の出力レイヤ集合を規定し得る、デコーディングする手段をさらに備えた、請求項３に記載の装置。
  5. 前記コード化ビデオシーケンスにより表されるデコーディングされた前記出力レイヤ集合から、出力レイヤを決定する手段と、前記決定した出力レイヤのみから、デコード画像を出力する手段と、をさらに備えた、請求項４に記載の装置。
  6. デコード画像の格納に用いられる画像格納バッファの画像幅、画像高さ、ビット深度、および彩度フォーマットのうちの１つまたは複数を決定する手段をさらに備えた、請求項４に記載の装置。
  7. 前記実際の最も高い時間的サブレイヤに基づいて使用される仮想基準デコーダパラメータを選択する手段をさらに備えた、請求項３に記載の装置。
  8. デコーディングされた前記出力レイヤ集合に基づいて使用される仮想基準デコーダパラメータを選択する手段をさらに備えた、請求項４に記載の装置。
  9. ビデオビットストリームのシンタックス構造において、コード化ビデオシーケンスの実際の最も高い時間的サブレイヤを指定することであり、前記コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたは前記ビットストリームの終端が後続するデコーディング順序の一連のコード化画像である、指定することを含む方法。
  10. 前記シンタックス構造において、前記コード化ビデオシーケンスにより表される出力レイヤ集合を指定することであり、前記出力レイヤ集合が、デコーダによる出力が意図される出力レイヤとして１つまたは複数のレイヤが規定された一組のレイヤを含み、前記ビットストリームが、任意数の出力レイヤ集合を規定し得る、指定することをさらに含む、請求項９に記載の方法。
  11. ビデオビットストリームのシンタックス構造から、コード化ビデオシーケンスの実際の最も高い時間的サブレイヤをデコーディングすることであり、前記コード化ビデオシーケンスが、独立デコーディング可能かつ別のコード化ビデオシーケンスまたは前記ビットストリームの終端が後続するデコーディング順序の一連のコード化画像である、デコーディングすることを含む方法。
  12. 前記シンタックス構造から、前記コード化ビデオシーケンスにより表される出力レイヤ集合をデコーディングすることであり、前記出力レイヤ集合が、デコーダによる出力が意図される出力レイヤとして１つまたは複数のレイヤが規定された一組のレイヤを含み、前記ビットストリームが、任意数の出力レイヤ集合を規定し得る、デコーディングすることをさらに含む、請求項１１に記載の方法。
  13. 前記コード化ビデオシーケンスにより表されるデコーディングされた前記出力レイヤ集合から、出力レイヤを決定することと、前記決定した出力レイヤのみから、デコード画像を出力することと、をさらに含む、請求項１２に記載の方法。
  14. デコード画像の格納に用いられる画像格納バッファの画像幅、画像高さ、ビット深度、および彩度フォーマットのうちの１つまたは複数を決定することを含む、請求項１２に記載の方法。
  15. 前記実際の最も高い時間的サブレイヤに基づいて使用される仮想基準デコーダパラメータを選択することを含む、請求項１１に記載の方法。
JP2021576016A 2019-06-20 2020-05-20 ビデオエンコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム Active JP7492978B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962864371P 2019-06-20 2019-06-20
US62/864,371 2019-06-20
PCT/FI2020/050340 WO2020254720A1 (en) 2019-06-20 2020-05-20 An apparatus, a method and a computer program for video encoding and decoding

Publications (2)

Publication Number Publication Date
JP2022537576A JP2022537576A (ja) 2022-08-26
JP7492978B2 true JP7492978B2 (ja) 2024-05-30

Family

ID=74036972

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021576016A Active JP7492978B2 (ja) 2019-06-20 2020-05-20 ビデオエンコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム

Country Status (10)

Country Link
US (1) US20220239949A1 (ja)
EP (1) EP3987816A4 (ja)
JP (1) JP7492978B2 (ja)
KR (1) KR20220024721A (ja)
CN (1) CN114009053A (ja)
BR (1) BR112021025875A2 (ja)
CA (1) CA3143885A1 (ja)
MX (1) MX2021016004A (ja)
WO (1) WO2020254720A1 (ja)
ZA (1) ZA202200585B (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3782366A4 (en) * 2019-07-03 2021-10-20 Beijing Xiaomi Mobile Software Co., Ltd. METHOD AND DEVICE FOR CODING, DECODING AND STORAGE MEDIA
CN114073073B (zh) * 2019-07-08 2023-06-06 华为技术有限公司 一种支持混合nal单元的编解码方法和编解码器
US20220286710A1 (en) * 2019-07-12 2022-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Signaling of access unit delimiter
CN113039799B (zh) 2019-08-23 2023-08-01 苹果公司 图像信号编码/解码方法及其设备
US11245899B2 (en) * 2019-09-22 2022-02-08 Tencent America LLC Method and system for single loop multilayer coding with subpicture partitioning
WO2021061033A1 (en) * 2019-09-23 2021-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Segment position signalling with subpicture slice position deriving
CN114342399A (zh) * 2019-10-01 2022-04-12 英特尔公司 基于对象的体积视频编码
WO2021134055A1 (en) 2019-12-27 2021-07-01 Bytedance Inc. Subpicture signaling in parameter sets
CN114946174A (zh) 2020-01-09 2022-08-26 字节跳动有限公司 层间参考图片的存在的信令通知
JP7490797B2 (ja) * 2020-03-09 2024-05-27 エルジー エレクトロニクス インコーポレイティド 長方形スライスのサイズ情報を選択的に符号化する画像符号化／復号化方法及び装置、並びにビットストリームを伝送する方法
US11838485B2 (en) * 2020-04-16 2023-12-05 Electronics And Telecommunications Research Institute Method for processing immersive video and method for producing immersive video
US11558630B2 (en) 2020-05-20 2023-01-17 Tencent America LLC Techniques for random access point indication and picture output in coded video stream
CN115699747A (zh) 2020-05-22 2023-02-03 字节跳动有限公司 视频子比特流提取过程中的可缩放嵌套sei消息处理
CN115668936A (zh) * 2020-06-09 2023-01-31 弗劳恩霍夫应用研究促进协会 时间运动向量预测、层间参考和时间子层指示的视频编码方面
US20230300350A1 (en) * 2020-06-10 2023-09-21 Lg Electronics Inc. Image encoding/decoding method and apparatus for performing sub-bitstream extraction process on basis of maximum time identifier, and computer-readable recording medium storing bitstream
CN115769571A (zh) * 2020-06-17 2023-03-07 字节跳动有限公司 视频编解码中的解码的图片缓冲器管理和子图片
EP4016464A1 (en) * 2020-11-26 2022-06-22 Ricoh Company, Ltd. Apparatus, system, method, and carrier means
US11711506B2 (en) 2021-01-05 2023-07-25 Samsung Electronics Co., Ltd. V3C video component track alternatives
JP2024513459A (ja) * 2021-04-08 2024-03-25 北京字節跳動網絡技術有限公司 マルチビュー取得情報補足拡張情報
CN117296317A (zh) * 2021-04-19 2023-12-26 Lg 电子株式会社 媒体文件处理方法及其设备
CN113271464B (zh) * 2021-05-11 2022-11-18 北京奇艺世纪科技有限公司 视频编码方法、解码方法及相关装置
US11785239B2 (en) * 2021-06-29 2023-10-10 Tencent America LLC Independent coded region output supplementary enhancement information message
EP4145832A1 (en) * 2021-09-02 2023-03-08 Nokia Technologies Oy An apparatus, a method and a computer program for volumetric video
WO2023148730A1 (en) * 2022-02-06 2023-08-10 Yoom.Com Ltd Material segmentation
US11849173B1 (en) * 2022-03-28 2023-12-19 Amazon Technologies, Inc. Computer-implemented methods for quality of service optimization using a content adaptive slate image
WO2024077637A1 (zh) * 2022-10-14 2024-04-18 浙江大学 一种编解码方法、装置、编码器、解码器及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014010192A1 (ja) 2012-07-09 2014-01-16 パナソニック株式会社 画像符号化方法、画像復号方法、画像符号化装置及び画像復号装置
WO2015137237A1 (ja) 2014-03-14 2015-09-17 シャープ株式会社 画像復号装置
JP2016518763A (ja) 2013-04-07 2016-06-23 ドルビー・インターナショナル・アーベー 出力レイヤセットにおける信号化の変化

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736476B2 (en) * 2012-04-27 2017-08-15 Qualcomm Incorporated Full random access from clean random access pictures in video coding
US9351005B2 (en) * 2012-09-24 2016-05-24 Qualcomm Incorporated Bitstream conformance test in video coding
US9930342B2 (en) * 2014-06-20 2018-03-27 Qualcomm Incorporated Systems and methods for signaling hypothetical reference decoder parameters in a parameter set

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014010192A1 (ja) 2012-07-09 2014-01-16 パナソニック株式会社 画像符号化方法、画像復号方法、画像符号化装置及び画像復号装置
JP2016518763A (ja) 2013-04-07 2016-06-23 ドルビー・インターナショナル・アーベー 出力レイヤセットにおける信号化の変化
WO2015137237A1 (ja) 2014-03-14 2015-09-17 シャープ株式会社 画像復号装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BROSS, Benjamin et al.，Versatile Video Coding (Draft 5)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 14th Meeting: Geneva, CH, 19-27 Mar. 2019, [JVET-N1001-v10]，JVET-N1001 (version 10)，ITU-T，2019年07月02日，＜URL:https://jvet-experts.org/doc_end_user/documents/14_Geneva/wg11/JVET-N1001-v10.zip＞: JVET-N1001-v10.docx: pp.2,127-128,352-355
FUJIBAYASHI, A. and TAN, TK，MaxDpbSize setting based on the picture size，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 10th Meeting: Stockholm, SE, 11-20 July 2012, [JCTVC-J0210_r2]，JCTVC-J0210 (version 3)，ITU-T，2013年01月12日，＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J0210-v3.zip＞: JCTVC-J0210_r2.doc: pp.1-8
HANNUKSELA, Miska M. et al.，AHG12: Sub-picture layers for realizing independently coded picture regions，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 14th Meeting: Geneva, CH, 19-27 March 2019, [JVET-N0045]，JVET-N0045 (version 1)，ITU-T，2019年03月13日，＜URL:https://jvet-experts.org/doc_end_user/documents/14_Geneva/wg11/JVET-N0045-v1.zip＞: JVET-N0045.docx: pp.1-13

Also Published As

Publication number Publication date
MX2021016004A (es) 2022-06-16
KR20220024721A (ko) 2022-03-03
ZA202200585B (en) 2023-07-26
US20220239949A1 (en) 2022-07-28
WO2020254720A1 (en) 2020-12-24
EP3987816A4 (en) 2023-06-21
BR112021025875A2 (pt) 2022-03-03
EP3987816A1 (en) 2022-04-27
CA3143885A1 (en) 2020-12-24
CN114009053A (zh) 2022-02-01
JP2022537576A (ja) 2022-08-26

Similar Documents

Publication Publication Date Title
JP7492978B2 (ja) ビデオエンコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム
US11778171B2 (en) Apparatus, a method and a computer program for video coding and decoding
US12022117B2 (en) Apparatus, a method and a computer program for video coding and decoding
CN110870302B (zh) 用于全向视频的装置、方法和计算机程序
KR102170550B1 (ko) 미디어 콘텐츠를 인코딩하는 방법, 장치 및 컴퓨터 프로그램
CN113170238B (zh) 用于视频编码和解码的装置、方法和计算机程序
EP3614674A1 (en) An apparatus, a method and a computer program for volumetric video
EP3777185A1 (en) An apparatus, a method and a computer program for volumetric video
EP3818716A1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2020141260A1 (en) An apparatus, a method and a computer program for video coding and decoding
EP3734977A1 (en) An apparatus, a method and a computer program for volumetric video
WO2019141907A1 (en) An apparatus, a method and a computer program for omnidirectional video
WO2019243663A1 (en) An apparatus, a method and a computer program for volumetric video
CN112153391B (zh) 视频编码的方法、装置、电子设备及存储介质
EP3886439A1 (en) An apparatus and method for omnidirectional video
EP4085646A1 (en) An apparatus, a method and a computer program for omnidirectional video
WO2018115572A2 (en) An apparatus, a method and a computer program for video coding and decoding
WO2019197722A1 (en) An apparatus, a method and a computer program for volumetric video
EP3673665A1 (en) An apparatus, a method and a computer program for omnidirectional video
RU2784900C1 (ru) Устройство и способ для кодирования и декодирования видео
WO2019234290A1 (en) An apparatus, a method and a computer program for volumetric video

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220221

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220221

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230324

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230406

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230706

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20231016

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240216

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

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20240227

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: 20240513

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240520

R150 Certificate of patent or registration of utility model

Ref document number: 7492978

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150