JP2015518338A - ビデオコーディング方法および装置 - Google Patents

ビデオコーディング方法および装置 Download PDF

Info

Publication number
JP2015518338A
JP2015518338A JP2015507569A JP2015507569A JP2015518338A JP 2015518338 A JP2015518338 A JP 2015518338A JP 2015507569 A JP2015507569 A JP 2015507569A JP 2015507569 A JP2015507569 A JP 2015507569A JP 2015518338 A JP2015518338 A JP 2015518338A
Authority
JP
Japan
Prior art keywords
view component
view
depth
texture
component
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.)
Granted
Application number
JP2015507569A
Other languages
English (en)
Other versions
JP5916266B2 (ja
Inventor
ミスカ・マティアス ハンヌクセラ
ミスカ・マティアス ハンヌクセラ
ドミートロ ルサノフスキー
ドミートロ ルサノフスキー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of JP2015518338A publication Critical patent/JP2015518338A/ja
Application granted granted Critical
Publication of JP5916266B2 publication Critical patent/JP5916266B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Stored Programmes (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分が取得される、方法、装置およびコンピュータプログラム製品が開示される。アクセスユニットにおいて、テクスチャビュー成分および深度ビュー成分の順序が決定され、この順序に関する少なくとも1つの標示が符号化される。ビュー成分の符号化は、この順序に基づいて適応する。第1のタイプの少なくとも1つの符号化ビュー成分および第2のタイプの少なくとも1つの符号化ビュー成分が受取られる、方法、装置およびコンピュータプログラム製品も開示される。このビュー成分の順序に関する少なくとも1つの符号化された標示も受取られる。この少なくとも1つの符号化された標示が復号され、ビュー成分の復号はその順序に基づいて適応する。【選択図】図７

Description

本出願は概して、ビデオを符号化するおよび復号する装置，方法およびコンピュータプログラムに関する。
背景
本節では、特許請求の範囲で記載される本発明の背景や関連について説明する。本願での説明は追求されうる概念を含むこともあるが、必ずしも既に着想または追求されてきたものだけを含むわけではない。したがって、本願中で特段の指示がない限り、本節で記述される内容は、本願の明細書および特許請求の範囲に対する先行技術ではなく、本節で記述されていることのみをもって先行技術と認定してはならない。
ビデオコーディングシステムは、入力されたビデオを保存／伝送に適した圧縮表現に変換するエンコーダと、その圧縮表現を可視形態に戻す復元を行えるデコーダを備えてもよい。エンコーダは、ビデオをよりコンパクトな形態で表現するために、例えば、必要とされるよりも低いビットレートでビデオ情報を保存／伝送できるようにするために、元のビデオシーケンスの情報の一部を切り捨ててもよい。
スケーラブルビデオ符号化とは、コンテンツに関してビットレートや解像度、フレームレート、および／または他のタイプの拡張性が異なる複数の表現を1つのビットストリームが格納できるような符号化構造を表わす。スケーラブルビットストリームは、利用可能な最低品質ビデオを提供する1層の基本レイヤ（base layer）と、下位レイヤと共に受信・復号されるとビデオ品質を高める1層以上の拡張レイヤ（enhancement layer）から構成されてもよい。拡張レイヤに対する符号化効率を高めるために、レイヤの符号化表現は下位レイヤに依存してもよい。各レイヤは、それぞれの全ての従属レイヤと合わせて、特定の空間分解能、時間分解能、品質レベル、および／または他のタイプの拡張性に関する操作点におけるビデオ信号の1つの表現となる。
現在、3次元（3D）ビデオコンテンツを提供する様々な技術が研究・開発されている。特に、1組のステレオビデオだけを特定のビューポイントから見たり、別の1組のステレオビデオを別のビューポイントから見たりできる様々なマルチビューアプリケーションに関して集中的に研究されている。こうしたマルチビューアプリケーションに対する最も実現可能なアプローチの一つは、限定された入力ビュー数だけ、例えば、モノラルまたはステレオビデオと付加データだけがデコーダ側に提供され、必要なビューが全てディスプレイに表示されるように、デコーダによってローカルにレンダリング（すなわち、合成）されるというものだと理解される。
3Dビデオコンテンツの符号化では、アドバンスドビデオ符号化（Advanced Video Coding）規格H.264/AVCやH.264/AVCのマルチビュービデオ符号化（Multiview Video Coding；MVC）拡張といったビデオ圧縮システムを用いることができる。
摘要
アクセスユニットにおけるテクスチャビュー成分および深度ビュー成分の順序に関する標示がビットストリームに提供され符号化されることを考慮することで、種々の実施形態が提供される。このテクスチャビュー成分および深度ビュー成分の符号化は、このテクスチャビュー成分および深度ビュー成分の順序に基づいて適応してもよい。
本発明の種々の態様は、詳細な説明に提示されている。
本発明の第1の態様によれば、次の方法が提示される。この方法は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を含む。
本発明の第2の態様によれば、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置が提供される。前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサを用いて、前記装置に：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を遂行させるように構成される。
本発明の第3の態様によれば、1つ以上の命令の1つ以上のシーケンスを含むコンピュータプログラム製品が提供される。前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、装置に少なくとも次のこと：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を遂行させる。
本発明の第4の態様によれば、次の装置が提供される。この装置は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得する手段と；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定する手段と；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化する手段と；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させる手段
を備える。
本発明の第5の態様によれば、次の方法が提供される。この方法は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を含む。
本発明の第6の態様によれば、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置が提供される。前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサを用いて、前記装置に：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を遂行させる。
本発明の第7の態様によれば、1つ以上の命令の1つ以上のシーケンスを含むコンピュータプログラム製品が提供される。前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、装置に少なくとも次のこと：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を遂行させる。
本発明の第8の態様によれば、次の装置が提示される。この装置は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取る手段と；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取る手段と；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号する手段と；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させる手段
を備える。
本発明の例示的実施形態をより詳細に理解するために、次の添付図面と合わせて以下の説明を参照されたい。
本発明の実施形態を採用する電子デバイスを概略的に示す。 本発明の実施形態に適したユーザ装置を概略的に示す。 本発明の実施形態を採用し、無線および有線ネットワーク接続を用いて接続される複数の電子デバイスも概略的に示す。 エンコーダ内に組込まれる本発明の実施形態を概略的に示す。 本発明の実施形態に従うインター予測器の実施形態を概略的に示す。 DIBRベースの3DVシステムの簡易モデルを示す。 立体カメラセットアップの簡易2次元モデルを示す。 アクセスユニットの定義および符号化順序の実施例を示す。 テクスチャビューおよび深度ビューを符号化できるエンコーダに関する実施形態の高水準スローチャートを示す。 テクスチャビューおよび深度ビューを復号できるデコーダに関する実施形態の高水準スローチャートを示す。 エンコーダ内の深度マップ符号化の例示的処理フローを示す。 エンコーダのインループ実装を用いた2つの深度マップの符号化例を示す。 アンカーピクチャの統合マルチビュービデオ・深度符号化の実施例を示す。 非アンカーピクチャの統合マルチビュービデオ・深度符号化の実施例を示す。 方向別動きベクトル予測の例示的方法に関するフローチャートを示す。 イントラ予測用候補である、現符号化ブロックの空間的隣接を示す。 イントラ予測用候補である、現符号化ブロックの時間的隣接を示す。 Pスライスのスキップモードに対する深度ベース動き補償の例示的方法に関するフローチャートを示す。 Bスライスのダイレクトモードに対する深度ベース動き補償の例示的方法に関するフローチャートを示す。
実施形態の詳細説明
本発明の複数の実施形態を、ビデオコーディング構成を背景にして以下で説明する。ただし、本発明はこうした特定の構成に限定されるものではないことに留意されたい。実際に、リファレンスピクチャの取扱いの改良が要求される環境下において、様々な実施形態を幅広く適用できる。例えば、本発明はストリーミングシステム等のビデオコーディングシステムやDVDプレーヤー、デジタルテレビ受像機、パーソナルビデオレコーダーやシステム、パーソナルコンピュータや携帯コンピュータ、通信デバイスで実行されるコンピュータプログラムに対して適用可能でもよい。さらに、ビデオデータを取扱うトランスコーダやクラウドコンピューティング構成などのネットワーク要素に対して適用可能でもよい。
H.264/AVC規格は、ITU-T（国際電気通信連合の電気通信標準化部門）のビデオ符号化専門家グループ（VCEG）およびISO（国際標準化機構）／IEC（国際電気標準会議）の動画専門家グループ（MPEG）による統合ビデオチーム（JVT）によって開発された。H.264/AVC規格はその元となる両標準化機構によって公開されており、ITU-T勧告H.264およびISO/IEC国際規格14496-10と呼ばれる。ISO/IEC14496-10はMPEG-4パート10アドバンスドビデオ符号化（Advanced Video Coding；AVC）として知られている。H.264/AVC規格には複数のバージョンがあり、それぞれが規格に新たな拡張や仕様を統合している。こうした拡張には、スケーラブルビデオ符号化（Scalable Video Coding；SVC）とマルチビュービデオ符号化（Multiview Video Coding；MVC）が含まれる。
また現在では、VCEGとMPEGの共同研究開発チーム（JCT-VC）によって高効率ビデオ符号化（High Efficiency Video Coding；HEVC）の標準化プロジェクトが進められている。
本節では、H.264/AVCおよびHEVCの重要な定義やビットストリーム、コーディング構造、概念の一部が、ビデオのエンコーダやデコーダ、符号化方法、復号方法、ビットストリーム構造の例として説明される。本発明の実施形態はこうした例に実装されてもよい。H.264/AVCの重要な定義やビットストリーム、コーディング構造、概念の中には、HEVCドラフト規格にあるものと同一のものもある。したがって、以下ではこれらも一緒に説明される。本発明の態様はH.264/AVCやHEVCに限定されるものではない。本明細書は、本発明の一部または全部が実現される上での可能な原理を説明するためのものである。
数ある従来のビデオコーディング規格と同様にH.264/AVCとHEVCでも、エラーの無いビットストリームの復号処理だけでなくビットストリームの構文と意味についても規定されている。符号化処理は規定されていないが、エンコーダは必ずビットストリームの確認を行わなくてはならない。ビットストリームとデコーダの適合性は、仮想リファレンスデコーダ（Hypothetical Reference Decoder；HRD）を用いて検証できる。標準規格は伝送エラーや伝送損失対策を助けるコーディングツールを含む。しかし、こうしたツールを符号化で使用するのは任意選択であって、誤ったビットストリームに対する復号処理は何も規定されていない。
H.264/AVCまたはHEVCのエンコーダへの入力およびH.264/AVCまたはHEVCのデコーダからの出力のための基本単位はそれぞれピクチャである。H.264/AVCおよびHEVCでは、ピクチャはフレームまたはフィールドの何れかでもよい。フレームは輝度（luma）サンプルと対応する色差（chroma）サンプルの行列を含む。フィールドはフレームの代替サンプル行の組であり、ソース信号がインターレースである場合、エンコーダ入力として用いられてもよい。色差ピクチャは、輝度ピクチャと比較されるときにサブサンプリングされてもよい。例えば4:2:0サンプリングパターンでは、色差ピクチャの空間解像度は両座標軸で輝度ピクチャの半分である。
H.264/AVCでは、16×16ブロックの輝度サンプルと対応する色差サンプルのブロックがマクロブロックである。例えば4:2:0サンプリングパターンでは、マクロブロックは各色差成分で8×8ブロックの色差サンプルを含む。H.264/AVCでは、ピクチャは1つ以上のスライスグループに分割（パーティショニング）され、スライスグループは1つ以上のスライスを含む。H.264/AVCでは、スライスは整数のマクロブロックから成り、特定のスライスグループ内でラスタースキャンの順で連続している。
HEVCドラフト規格では、ビデオピクチャは、ピクチャ領域を覆う複数の符号化単位（CU）に分割される。CUは1つ以上の予測単位（PU）と1つ以上の変換単位（TU）から成る。PUはCU内のサンプルに対する予測処理を規定し、TUはCUのサンプルに対する予測誤差の符号化処理を規定する。通常CUは、正方形のサンプルブロックから成り、既定されている可能なCUサイズのセットから選択可能なサイズを持つ。最大許容サイズのCUは通常、LCU（最大符号化単位）と呼ばれ、ビデオピクチャは重なり合わないLCUに分割される。LCUは、例えば、LCUと分割の結果得られるCUを再帰的に分割することによって更に小さいCUの組合せに分割されることもある。分割の結果得られる各CUは通常、少なくとも1つのPUとそれに関連する少なくとも1つのTUを有する。PUとTUはそれぞれ、予測処理と予測誤差符号化処理の粒度を上げるために、更に小さい複数のPUとTUに分割されることもある。PU分割は、CUを同じサイズの4つの正方形PUに分割することで行われてもよい。あるいは、対称的または非対称的方法でCUを縦または横で2つの長方形PUに分割することで行われてもよい。ピクチャをCUに分割し、CUをPUとTUに分割することは通常、デコーダがこうした単位から目的の構造を再生できるようにビットストリーム信号で伝えられる。
HEVCドラフト規格では、ピクチャはタイルに分割される。タイルは長方形で、整数のLCUを含む。HEVCドラフト規格では、タイル分割（パーティショニング）は正規グリッド（regular grid）を形成し、タイルの高さと幅は最大のLCUによって互いに異なる。HEVCドラフトでは、スライスは整数のCUから成る。CUは、タイル内、またはタイルが使われない場合はピクチャ内でLCUのラスタースキャン順にスキャンされる。LCU内では、CUは特定のスキャン順序を持つ。
HEVCのワーキングドラフト（WD）5では、ピクチャのパーティショニングに関する主要既定と概念が次のように定義されている。パーティショニングとは、1つのセットの各要素が正確にサブセットの1つであるように、そのセットを複数のサブセットに分割することとして定義される。
HEVC WD5の基本符号化単位はツリーブロックである。ピクチャのツリーブロックは、N×Nブロックの輝度サンプルと対応する2ブロックの色差サンプルという3つのサンプル配列持つ。あるいは、モノクロピクチャや3つの別々の色平面を用いて符号化されるピクチャに関するN×Nブロックのサンプルである。ツリーブロックは、別々の符号化および復号処理用に分割されてもよい。ツリーブロック分割（パーティショニング）は、ピクチャのツリーブロック分割によって得られる1ブロックの輝度サンプルと対応する2ブロックの色差サンプルという3つのサンプル配列持つ。あるいは、モノクロピクチャや3つの別々の色平面を用いて符号化されるピクチャのツリーブロック分割によって得られるに関する1ブロックの輝度サンプルである。各ツリーブロックには、イントラまたはインター予測符号化用のブロックサイズと変換符号化用ブロックサイズを識別するパーティション信号が割当てられる。パーティショニングは再帰的4分木パーティショニングである。4分木の根はツリーブロックに関連付けられる。4分木は、符号化ノードとも呼ばれる葉ノードに到達するまで分割される。符号化ノードは、予測ツリーと変換ツリーの2つのツリーの根ノードである。予測ツリーは予測ブロックの位置とサイズを特定する。予測ツリーと関連する予測データは予測単位と呼ばれる。変換ツリーは変換ブロックの位置とサイズを特定する。変換ツリーと関連する変換データは変換単位と呼ばれる。輝度および色差の分割情報は予測ツリーでは同一であるが、変換ツリーでは同一でも異なっていてもどちらでもよい。符号化ノードと関連する予測単位・変換単位は合わせて符号化単位を形成する。
HEVC WD5では、ピクチャはスライスとタイルに分割される。スライスはツリーブロックのシーケンスでもよいが、（いわゆる高精細スライスと呼ばれる場合は）ツリーブロック内の変換単位と予測単位が一致する場所に境界があってもよい。スライス内のツリーブロックは、ラスタースキャン順序で符号化され復号される。最初の符号化ピクチャに対して、各ピクチャをスライスに分割することがパーティショニングである。
HEVC WD5では、タイルは、1つの列または行に存在する整数のツリーブロックとして定義され、このツリーブロックはタイル内でラスタースキャン順に連続している。最初の符号化ピクチャに対して、各ピクチャをタイルに分割することもパーティショニングである。タイルはピクチャ内でラスタースキャン順に連続している。スライスはそこでラスタースキャン順に連続するツリーブロックを含むが、こうしたツリーブロックがピクチャ内でラスタースキャン順に連続している必要はない。また、スライスとタイルは同一のツリーブロック列を含む必要はない。タイルは複数のスライスに含まれるツリーブロックを含んでもよい。同様に、1つのスライスが複数のスライスに含まれるツリーブロックを含んでもよい。
H.264/AVCおよびHEVCでは、ピクチャ内でスライス境界を跨ぐ予測が無効でもよい。したがって、スライスは符号化ピクチャを独立して復号される部分に分割する方法だと考えられることもあり、それ故しばしば、伝送の基本単位と見做される。多くの場合、エンコーダは、ピクチャ内予測のどの種類がスライス境界を跨ぐ際に止められているかをビットストリームで示してもよい。この情報は、デコーダの動作によって、どの予測ソースが利用可能であるかを決定する際などで考慮される。例えば、隣接するマクロブロックやCUが別のスライスに存在する場合、その隣接するマクロブロックやCUからのサンプルはイントラ予測には利用できないと見做されてもよい。
シンタックス要素はビットストリームで表わされるデータの要素として定義される。シンタックス構造は、特定の順序のビットストリームで表わされる0以上のデータの要素として定義される。
H.264/AVCまたはHEVCのエンコーダからの出力およびH.264/AVCまたはHEVCのデコーダへの入力のための基本単位はそれぞれ、ネットワーク抽象化層（Network Abstraction Layer；NAL）ユニットである。パケット指向ネットワークでの伝送や構造化ファイルへの格納に対して、NALユニットはパケットや同様の構造にカプセル化されてもよい。H.264/AVCおよびHEVCでは、フレーム構造を提供しない伝送や格納の環境に対してバイトストリーム・フォーマットが特定されている。バイトストリーム・フォーマットは、各NALユニットの先頭に開始コードを付与することによってNALユニット同士を分離する。NALユニット境界の誤検出を防止するために、エンコーダはバイト指向開始コードエミュレーション防止アルゴリズムを実行する。これは、開始コードが別の形で生じた場合にNALユニットペイロードにエミュレーション防止バイトを追加する。パケット指向システムとストリーム指向システムとの間の直接的なゲートウェイ動作を可能とするために、バイトストリーム・フォーマットが使用されているか否かに関係なく常に開始コードエミュレーション防止が行われてもよい。NALユニットは、後続データの種類の標示を含むシンタックス構造と、RBSP（raw byte sequence payload）の形態で必要に応じてエミュレーション・プリベンション（emulation prevention）バイトと一緒に散在するデータを含む複数バイトとして定義されてもよい。RBSPは、NALユニットにカプセル化される整数値を含むシンタックス構造として定義されてもよい。RBSPは空であるか、RBSPストップビットおよび0に等しいシーケンスビット0個以上に続くシンタックス構造要素を含むデータビット列の形態を持つかの何れかである。
NALユニットはヘッダとペイロードから成る。H.264/AVCおよびHEVCでは、NALユニットヘッダはNALユニットの種類と、NALユニットに含まれる符号化スライスがリファレンスピクチャであるか非リファレンスピクチャであるかを示す。
H.264/AVC NALユニットヘッダは2ビットのシンタックス要素nal_ref_idcを含み、これが0のときはNALユニットに含まれる符号化スライスが非リファレンスピクチャの一部であることを示し、0を超えるときはNALユニットに含まれる符号化スライスがリファレンスピクチャの一部であることを示す。HEVCドラフト規格は1ビットのシンタックス要素nal_ref_idcを含み、nal_ref_flagとも呼ばれる。これが0のときはNALユニットに含まれる符号化スライスが非リファレンスピクチャの一部であることを示し、1のときはNALユニットに含まれる符号化スライスがリファレンスピクチャの一部であることを示す。SVCおよびMVCのNALユニットヘッダは、拡張性とマルチビュー階層の関連する様々な標示を追加で含んでもよい。
HEVCドラフト規格では、規定されるNALユニットタイプの全てに対して2バイトのNALユニットヘッダが使用される。NALユニットヘッダの最初の1バイトは、1ビットの予約ビットと、1ビットのnal_ref_flag標示、6ビットのNALユニットタイプ標示を含む。nal_ref_flagは主に、このアクセスユニットで伝えられるピクチャがリファレンスピクチャか非リファレンスピクチャかを示す。NALユニットヘッダの残りの1バイトは、時間レベルを示す3ビットのtemporal_idと、5ビットの予約フィールド（reserved_one_5bitsと呼ばれる）を含む。HEVCドラフト規格では、この予約フィールドの値は1と規定されている。temporal_idシンタックス要素はNALユニットの時間識別子と見做されてもよい。5ビットの予約フィールドは将来のスケーラブル・3Dビデオ拡張といった拡張機能で使用されるものと想定されている。この5ビットは拡張性階層に関する情報を伝えるものと想定される。こうした拡張性階層は例えば、quality_idまたは同種の識別子、dependency_idまたは同種の識別子、他のタイプのレイヤ識別子、ビュー順序インデクスまたは同種のインデクス、ビュー識別子、SVCのpriority_idのような識別子などである。priority_idは、特定の識別値を超える全てのNALユニットがビットストリームから削除された場合に有効なサブビットストリームの抽出を示す。例示的実施形態によっては、一般性を失わずに、 変数LayerIdがreserved_one_5bitsの値から次のように算出される：LayerId = reserved_one_5bits - 1。
NALユニットはビデオ符号化層（Video Coding Layer；VCL）NALユニットと非VCL-NALユニットに分類できる。VCL-NALユニットは通常、符号化スライスNALユニットである。H.264/AVCでは、符号化スライスNALユニットは1つ以上の符号化マクロブロックを表わすシンタックス要素を含み、それぞれが非圧縮ピクチャのサンプルブロックに対応する。HEVCでは、符号化スライスNALユニットは1つ以上のCUを表わすシンタックス要素を含む。H.264/AVCおよびHEVCでは、符号化スライスNALユニットは瞬時復号リフレッシュ（Instantaneous Decoding Refresh；IDR）ピクチャの符号化スライスまたは非IDRピクチャの符号化スライスであると示されることもある。HEVCでは、符号化スライスNALユニットはクリーン復号リフレッシュ（Clean Decoding Refresh；CDR）ピクチャ（クリーン・ランダムアクセス（Clean Random Access）ピクチャまたはCRAピクチャとも呼ばれる）の符号化スライスであると示されることもある。
非VCL-NALユニットは例えば、次のタイプの1つでもよい：シーケンスパラメータセット；ピクチャパラメータセット；補助拡張情報（supplemental enhancement information；SEI）NALユニット；アクセスユニット区切り；シーケンスNALユニットの一部；ストリームNALユニットの一部；または補充データNALユニット。パラメータセットは復号ピクチャの再構成に必要であってもよいが、他の非VCL-NALユニットの多くは、復号サンプル値の再構成には必要ない。
符号化ビデオシーケンスで不変のパラメータがシーケンスパラメータセットに含まれてもよい。復号処理に必要なパラメータに加え、シーケンスパラメータセットがビデオユーザビリティ情報（video usability information；VUI）を含んでもよい。これは、バッファリングやピクチャ出力タイミング、レンダリング、リソース予約に重要なパラメータを含む。H.264/AVCでは、シーケンスパラメータセットを含む3つのNALユニットが規定されている。シーケンスパラメータセットNALユニットは、H.264/AVCのVCL-NALユニット用データ全てをシーケンスに含む。シーケンスパラメータセット拡張NALユニットは補助符号化ピクチャ用データを含む。サブセットシーケンスパラメータセットNALユニットはMVCとSVCのVCL-NALユニット用である。ピクチャパラメータセットは、複数の符号化ピクチャで不変であるようなパラメータを含む。
HEVCドラフトでは、適応パラメータセット（Adaptation Parameter Set；APS）と呼ばれる第3のタイプのパラメータセットがある。これは、複数の符号化ピクチャで不変であるが、例えばピクチャ毎または幾つかのピクチャ毎では変化しうるようなパラメータを含む。HEVCドラフトでは、APSシンタックス構造は、量子化マトリクス（quantization matrix；QM）や適応サンプルオフセット（adaptive sample offset；SAO），適応ループフィルタリング（adaptive loop filtering；ALF），デブロッキングフィルタリングに関連するパラメータまたはシンタックス要素を含む。HEVCドラフトでは、APSは他のNALユニットから参照または予測されずに符号化されるNALユニットである。シンタックス要素aps_idと呼ばれる識別子はAPS-NALユニットに含まれる。これはスライスヘッダにも含まれ、特定のAPSを表わすために用いられる。
H.264/AVCおよびHEVCのシンタックスは様々なパラメータインスタンスを許容し、各インスタンスは固有の識別子で識別される。パラメータセットに必要なメモリ使用量を制限するために、パラメータセット識別値域は制限されている。H.264/AVCおよびHEVCドラフト規格では、各スライスヘッダは、そのスライスを含むピクチャの復号に対してアクティブなピクチャパラメータセットの識別子を含む。各ピクチャパラメータセットは、アクティブなシーケンスパラメータセットの識別子を含む。HEVC規格では、スライスヘッダは追加的にAPS識別子を含む。その結果、ピクチャとシーケンスパラメータセットの伝送がスライスの伝送と正確に同期されている必要がない。実際に、アクティブシーケンスとピクチャパラメータセットはそれらが参照される前までに受取られていれば十分であり、スライスデータ用のプロトコルよりも高い信頼性のある伝送機構を使って「帯域外」でパラメータセットを伝送することが可能になる。例えば、パラメータセットはリアルタイム転送プロトコル（Real-time Transport Protocol；RTP）セッション用のセッション記述でのパラメータとして含まれてもよい。パラメータセットは、帯域内で伝送される場合、エラー耐性を高めるために繰り返されることもある。
SEI-NALユニットは1つ以上のSEIメッセージを含んでもよい。これらは出力ピクチャの復号には必要ないが、ピクチャ出力タイミングやエラー検出、エラー隠蔽、リソース予約などの関連処理を補助してもよい。複数のSEIメッセージがH.264/AVCおよびHEVCで規定され、ユーザデータのSEIメッセージによって組織や企業が独自に使用するSEIメッセージを規定できる。H.264/AVCおよびHEVCは、規定されたSEIメッセージのシンタックスと意味を含むが、受信側でメッセージを取扱う処理については何も定義されない。その結果、エンコーダはSEIメッセージを作成する際、H.264/AVC規格やHEVC規格に従い、デコーダもそれぞれH.264/AVC規格やHEVC規格に準拠する必要がある。しかし、SEIメッセージを出力規定に準じて処理する必要はない。H.264/AVCおよびHEVCでSEIメッセージのシンタックスと意味を含める理由の1つは、異なるシステム仕様でも補助情報を同じ様に解釈し相互運用を可能にすることである。システム仕様は符号化側と復号側の両方で特定のSEIメッセージを使用できるように要求するものであり、受信側で特定のSEIメッセージを取扱う処理も規定されてもよい。
符号化ピクチャはピクチャの符号化された表現である。H.264/AVCでの符号化ピクチャは、ピクチャの復号に必要なVCL-NALユニットを含む。H.264/AVCでは、符号化ピクチャはプライマリ符号化ピクチャまたは冗長符号化ピクチャである。プライマリ符号化ピクチャは有効なビットストリームの復号処理で使用される。一方、冗長符号化ピクチャは、プライマリ符号化ピクチャが正しく復号されない場合にだけ復号される冗長表現である。HEVCドラフトでは、冗長符号化ピクチャは規定されていない。
H.264/AVCおよびHEVCでは、アクセスユニットがプライマリ符号化ピクチャとそれに関連付けられるNALユニットを含む。H.264/AVCでは、アクセスユニット内でのNALユニットの出現順序が次のように制限されている。追加アクセスユニット区切りのNALユニットは、アクセスユニットの起点を示すことができる。この後に0以上のSEI-NALユニットが続く。プライマリ符号化ピクチャの符号化スライスが次に現われる。H.264/AVCでは、プライマリ符号化ピクチャの符号化スライスの後に0以上の冗長符号化ピクチャの符号化スライスが続いてもよい。冗長符号化ピクチャは、ピクチャまたはピクチャの一部の符号化された表現である。冗長符号化ピクチャは、伝送損失や物理記憶媒体でのデータ破損などによってデコーダがプライマリ符号化ピクチャを受取れない場合に復号されてもよい。
H.264/AVCでは、アクセスユニットは補助符号化ピクチャを含んでもよい。これは、プライマリ符号化ピクチャを補助／補完し、表示処理などで使用できるピクチャである。補助符号化ピクチャは例えば、復号ピクチャのサンプルの透過レベルを特定するアルファチャンネルやアルファ面として使用されてもよい。アルファチャンネルまたはアルファ面は、レイヤ成分やレンダリングシステムで使用されてもよい。出力ピクチャは、互いに表面で少なくとも一部が透過しているピクチャを重ね合わせることで作成される。補助符号化ピクチャは、モノクロ冗長符号化ピクチャとして同一のシンタックスと意味の制限がある。H.264/AVCでは、補助符号化ピクチャはプライマリ符号化ピクチャと同数のマクロブロックを含む。
符号化ビデオシーケンスは、連続するアクセスユニットのシーケンスとして定義される。このシーケンスは復号処理の順序であって、IDRアクセスユニットを含んでそこから、次のIDRアクセスユニットを含まずその直前かビットストリームの最後のうち先に出現するところまでの順序である。
ピクチャーグループ（GOP）とその特性は次のように定義されてもよい。GOPは、その前のピクチャが復号されたどうかに関係なく復号される。オープンGOPとは、復号処理がその最初のイントラピクチャから開始する場合に、出力順で最初のイントラピクチャより先のピクチャが正しく復号できない様なピクチャーグループである。換言すれば、オープンGOPのピクチャは、その前のGOPに属するピクチャを（インター予測で）参照してもよい。H.264/AVCデコーダは、H.264/AVCビットストリームでのリカバリポイントのSEIメッセージによって、オープンGOPの始めのイントラピクチャを認識できる。HEVCデコーダはオープンGOPの始めのイントラピクチャを認識できる。これは、符号化スライスに対して特別なNALユニットタイプであるCRA-NALユニットタイプが使用されるからである。クローズドGOPとは、復号処理がその最初のイントラピクチャから開始する場合に、全ピクチャが正しく復号される様なピクチャーグループである。換言すれば、クローズドGOPではその前のGOPに属するピクチャを参照するピクチャは存在しない。H.264/AVCおよびHEVCでは、クローズドGOPはIDRアクセスユニットから始まる。その結果、クローズドGOPの構造はオープンGOPの構造よりも高いエラー回復能力を持つ。しかし、圧縮効率を減らす可能性があるという代償を伴う。オープンGOPの符号化構造は、リファレンスピクチャの選択における高い柔軟性によって、より効率的な圧縮を可能にする。
H.264/AVCおよびHEVCのビットストリームシンタックスは、特定のピクチャが別のピクチャのイントラ予測のためのリファレンスピクチャであるかを示す。任意の符号化タイプ（I，P，B）のピクチャは、H.264/AVCおよびHEVCのリファレンスピクチャまたは非リファレンスピクチャであり得る。NALユニットヘッダはNALユニットの種類と、NALユニットに含まれる符号化スライスがリファレンスピクチャであるか非リファレンスピクチャであるかを示す。
H.264/AVCおよびHEVCを含む多くのハイブリッドビデオコーデックは、ビデオ情報を2段階で符号化する。第1段階では、特定のピクチャ領域または「ブロック」のピクセル値またはサンプル値が予測される。こうしたピクセル値またはサンプル値は、例えば動き補償機構によって予測できる。この機構には、符号化されるブロックに近くて対応する、先に符号化されたビデオフレームの1つにある領域の検索と標示が含まれる。加えて、ピクセル値またはサンプル値は、空間領域の関係性の検索と標示を含む空間機構によって予測されてもよい。
先に符号化された画像からの画像情報を用いた予測アプローチは、インター予測法とも呼ばれ、また、時間予測および動き補償とも呼ばれる。同一画像内の画像情報を用いた予測アプローチは、イントラ予測法とも呼ばれる。
第2段階は、ピクセルまたはサンプルの予測ブロックとそのピクセルまたはサンプルの元のブロックとの間の誤差の符号化の1つである。これは、特定の変換を用いてピクセル値またはサンプル値の差を変換することによって達成されてもよい。この変換は、離散コサイン変換（Discrete Cosine Transform；DCT）やその変形でもよい。差の変換後、変換された差は量子化されエントロピー符号化される。
量子化処理の忠実性を変えることによって、エンコーダはピクセルまたはサンプル表現の正確性（すなわち、ピクチャの視覚的品質）と結果として得られる符号化ビデオ表現のサイズ（すなわち、ファイルサイズや伝送ビットレート）との間のバランスを制御できる。
デコーダは、予測されたピクセルまたはサンプルのブロック表現を形成して予測誤差を復号するために、エンコーダが用いたのと同様の予測機構を適用することによって出力ビデオを再構成する（ここで、予測表現の形成は、エンコーダが作成し、画像の圧縮表現に格納された動き情報や空間情報を使用し、予測誤差の復号は、空間領域で量子化された予測誤差信号を回復する、予測誤差符号化の逆操作を使用して行われる）。
ピクセルまたはサンプルの予測および誤差復号処理の後、デコーダは、出力ビデオフレームを形成するために、予測信号と予測誤差信号（ピクセル値またはサンプル値）を合成する。
デコーダ（およびエンコーダ）は、出力ビデオをディスプレイに送る、および／またはビデオシーケンスにおける後続ピクチャ用の予測リファレンスとして格納する前に、出力ビデオの品質を向上するために追加のフィルタリング処理を適用してもよい。
H.264/AVCおよびHEVCを含む多くのビデオコーデックでは、動き情報は、動き補償された画像ブロックのそれぞれに関連する動きベクトルによって示される。こうした動きベクトルはそれぞれ、（エンコーダで）符号化されるピクチャまたは（デコーダで）復号されるピクチャの画像ブロックと、先に符号化または復号された画像（またはピクチャ）の1つにおける予測元ブロックとの間の移動量を表わす。H.264/AVCおよびHEVCは、その他多くのビデオ圧縮規格と同様にピクチャを長方形のメッシュに分割する。これらの長方形のそれぞれに対し、リファレンスピクチャの1つにある同じブロックがインター予測用に示される。予測ブロックの位置は、符号化されるブロックに対する予測ブロックの相対位置を示す動きベクトルとして符号化される。
インター予測処理は、次のファクタの1つ以上によって特徴付けられてもよい。
動きベクトル表現の正確さ
例えば、動きベクトルは1/4ピクセル精度や1/2ピクセル精度、1ピクセル精度であって、分数ピクセルの位置でのサンプル値は、有限インパルス応答（finite impulse response；FIR）フィルタを用いて得られてもよい。
インター予測用のブロック分割（パーティショニング）
H.264/AVCおよびHEVCを含む多くの符号化規格では、エンコーダでの動き補償予測用に適用される動きベクトルのためにブロックのサイズと形状を選択でき、エンコーダで行われた動き補償予測をデコーダが再構成できるように、選択されたサイズと形状をビットストリームで示すことができる。
インター予測用リファレンスピクチャの数
インター予測の元データは、先に復号されたピクチャである。H.264/AVCおよびHEVCを含む多くの符号化規格では、インター予測用に複数のリファレンスピクチャを格納し、ブロックバイアスに応じて使用されるリファレンスピクチャを選択できる。例えば、リファレンスピクチャは、H.264/AVCでのマクロブロックまたはマクロブロックパーティションのバイアスや、HEVCのPUまたはCUのバイアスに関して選択されてもよい。H.264/AVCおよびHEVCなどの多くの符号化規格は、デコーダが1つ以上のリファレンスピクチャ・リストを作成できるシンタックス構造をビットストリームに含む。リファレンスピクチャ・リストを示すリファレンスピクチャ・インデクスは、複数のリファレンスピクチャの中のどれが特定のブロックに対するインター予測用として使用されるかを示すのに使われてもよい。リファレンスピクチャ・インデクスは、エンコーダによって何らかのインター符号化法でビットストリームに符号化されてもよく、あるいは、他のインター符号化法によって、隣接ブロック等を使って（エンコーダおよびデコーダによって）引出されてもよい。
動きベクトル予測
動きベクトルをビットストリームに効率よく表現するために、動きベクトルは、ブロック毎の予測動きベクトルに関して差動符号化されてもよい。多くのビデオコーデックでは、予測動きベクトルは所定の方法、例えば、隣接ブロックの符号化／復号動きベクトルの中央値を計算することによって生成される。動きベクトル予測を行う別の方法は、時間軸上のリファレンスピクチャにおける隣接ブロックおよび／または同位置のブロックから予測候補のリストを作成し、選択された候補を動きベクトルの予測として信号で伝えるものである。動きベクトルの値の予測に加え、先に符号化／復号されたピクチャのリファレンスインデクスが予測されてもよい。リファレンスインデクスは通常、時間軸上のリファレンスピクチャにおける隣接ブロックおよび／または同位置のブロックから予測される。動きベクトルの差動符号化は通常、スライス境界を跨ぐときは無効にされる。
多仮説動き補償予測
H.264/AVCおよびHEVCでは、Pスライスで単一の予測ブロックを使用できる（このため、Pスライスは単予測スライスと呼ばれる）。また、Bスライスとも呼ばれる双予測スライスに対しては2つの動き補償予測ブロックの線形結合を使用できる。Bスライスの個別ブロックは双予測や単予測，イントラ予測されたものでもよく、Pスライスの個別ブロックは単予測またはイントラ予測されたものでもよい。双予測ピクチャ用のリファレンスピクチャは、出力順で後続ピクチャと先行ピクチャに限定しなくてもよく、任意のリファレンスピクチャが使用されてもよい。H.264/AVCおよびHEVCなどの多くの符号化規格では、リファレンスピクチャ・リスト0と呼ばれる特定のリファレンスピクチャ・リストがPスライス用に構成され、2つのリファレンスピクチャ・リストであるリスト0およびリスト1がBスライス用に構成される。Bスライスに関して、前方予測はリファレンスピクチャ・リスト0のリファレンスピクチャからの予測のことであり、後方予測はリファレンスピクチャ・リスト1のリファレンスピクチャからの予測のことである。ここで、予測用リファレンスピクチャは互いに、または現ピクチャに関連する復号処理や出力順序を持っていてもよい。
加重予測
多くの符号化規格は、インター（P）ピクチャの予測ブロックに対して予測重み1、Bピクチャの各予測ブロックに対して予測重み0.5を（結果として平均するのに）用いる。H.264/AVCでは、PとBの両スライスで加重予測を行える。陰加重予測では、重みはピクチャ順序カウント（picture order count）に比例し、陽加重予測では、予測の重みは明示的に示される。
多くのビデオコーデックでは、動き補償後の予測残差は最初に（DCTのような）変換カーネルで変換され、次に符号化される。これは、通常残差間にも相関があり、こうした変換が多くの場合でこのような相関を小さくするのに役立ち、より高い効率での符号化を可能にするからである。
HEVCドラフトでは、各PUは、それぞれのPU内のピクセルに適用される予測の種類を定義する、それぞれのPUに関連した予測情報（例えば、インター予測されたPUに対しては動きベクトルの情報、イントラ予測されたPUに対してはイントラ予測の方向情報など）を持つ。同様に、各TUは、それぞれのTU内のサンプルに対する予測誤差復号処理を記述する情報（DCT係数情報なども含む）に関連付けられる。各CUに対して予測誤差符号化が適用されるか否かがCUレベルで伝達されてもよい。CUに関連する予測誤差の残差がない場合、そのCUに対するTUが存在しないと見做される。
符号化フォーマットやコーデックによっては、いわゆる短期リファレンスピクチャと長期リファレンスピクチャとが区別される。こうした区別は、時間ダイレクトモードや陰加重予測における動きベクトルのスケーリングとして一部の復号処理に影響を与えることもある。時間ダイレクトモードに使われるリファレンスピクチャが両方とも短期リファレンスピクチャである場合、予測で使われる動きベクトルは、現ピクチャと各リファレンスピクチャとの間のピクチャ順序カウント（POC）の差に応じてスケールされてもよい。しかし、時間ダイレクトモード用の少なくとも1つのリファレンスピクチャが長期リファレンスピクチャである場合、デフォルトの動きベクトルスケーリングが使用されてもよく、例えば、動きを半分にスケールしてもよい。同様に、陰加重予測で短期リファレンスピクチャが使われる場合、予測の重みは、現ピクチャのPOCとリファレンスピクチャのPOCのPOC差に応じてスケールされてもよい。しかし、陰加重予測で長期リファレンスピクチャが使われる場合、デフォルトの予測重みが使用されてもよく、双予測ブロックに対する陰加重予測では0.5などでもよい。
H.264/AVC等のビデオ符号化フォーマットでは、シンタックス要素frame_numを含み、複数のリファレンスピクチャに関連する様々な復号処理に使用される。H.264/AVCでは、IDRピクチャのframe_num値は0である。非IDRピクチャのframe_num値は0復号順で先のリファレンスピクチャのframe_numに1を加えた値に等しい（モジュロ（modulo）演算の場合、frame_num値は、その最大値の次が0に戻る（ラップアラウンドする））。
H.264/AVCおよびHEVCはピクチャ順序カウント（POC）の概念を含む。POC値は各ピクチャに与えられ、出力におけるピクチャの順番が増えても減ることはない。したがって、POCはピクチャの出力順序を示す。POCは復号処理で使用されてもよく、例えば、双予測スライスの時間ダイレクトモードでの動きベクトルの陰スケーリングや加重予測で陰に生成される重み，リファレンスピクチャ・リストの初期化などに使用される。また、POCは出力順序適合性の検証に使用されてもよい。H.264/AVCでは、POCは先のIDRピクチャや、全てのピクチャを「リファレンスに未使用」とマークするメモリ管理制御操作を含むピクチャに関連して特定される。
H.264/AVCは、デコーダでのメモリ消費を制御するために、復号リファレンスピクチャのマーキング処理を特定する。インター予測に用いるリファレンスピクチャの数の最大値はMで表わし、シーケンスパラメータセットで決定される。リファレンスピクチャは、復号されるときに「リファレンスに使用済」とマークされる。リファレンスピクチャの復号で「リファレンスに使用済」とマークされるピクチャの数がMを超える場合、少なくとも1つのピクチャは「リファレンスに未使用」とマークされる。復号リファレンスピクチャのマーキング動作には適応メモリ制御とスライディングウィンドウの2種類がある。復号リファレンスピクチャのマーキング動作モードはピクチャに基づいて選択される。適応メモリ制御は、どのピクチャが「リファレンスに未使用」とマークされているかを明示的に信号で伝えられ、短期リファレンスピクチャに長期インデクスを割当ててもよい。適応メモリ制御は、ビットストリームにメモリ管理制御操作（memory management control operation；MMCO）パラメータの存在を要求してもよい。MMCOパラメータは、復号リファレンスピクチャ・マーキングのシンタックス要素に含まれてもよい。スライディングウィンドウ動作モードが使われ、M枚のピクチャが「リファレンスに使用済」とマークされている場合、「リファレンスに使用済」とマークされている短期リファレンスピクチャの中で最初に復号された短期リファレンスピクチャは「リファレンスに未使用」とマークされる。換言すれば、スライディングウィンドウ動作モードは、短期リファレンスピクチャに対して先入れ先出し（first-in-first-out）バッファ動作となる。
H.264/AVCのメモリ管理制御操作によっては、現ピクチャ以外の全てのリファレンスピクチャを「リファレンスに未使用」とマークする。瞬時復号リフレッシュ（IDR）ピクチャはイントラ符号化スライスのみを含み、リファレンスピクチャに対する同一「リセット」を行う。
HEVCドラフト規格では、リファレンスピクチャ・マーキングのシンタックス構造と関連する復号処理は使用されない。その代わり、リファレンスピクチャセット（reference picture set；RPS）のシンタックス構造と復号処理が同じ目的で使用される。特定のピクチャに有効またはアクティブなリファレンスピクチャセットは、そのピクチャに対するリファレンスとして使われる全てのリファレンスピクチャと、復号順で後続の任意のピクチャに対して「リファレンスに使用済」とマークされたままである全てのリファレンスピクチャを含む。リファレンスピクチャセットには6つのサブセットがあり、それぞれRefPicSetStCurr0，RefPicSetStCurr1，RefPicSetStFoll0，RefPicSetStFoll1，RefPicSetLtCurr，およびRefPicSetLtFollと呼ばれる。この6つのサブセットの表記法は次の通りである。「Curr」は現ピクチャのリファレンスピクチャ・リストに含まれるリファレンスピクチャを表わす。このため、現ピクチャに対するインター予測リファレンスとして使用されてもよい。「Foll」は現ピクチャのリファレンスピクチャ・リストに含まれないリファレンスピクチャを表わす。ただし、復号順で後続のピクチャではリファレンスピクチャとして使用されてもよい。「St」は短期リファレンスピクチャを表わし、通常、POC値の特定数の最下位ビットで識別される。「Lt」は長期リファレンスピクチャを表わし、特定の方法で識別される。通常、現ピクチャに対するPOC値の差は、前述した特定数の最下位ビットによって表わされるものよりも大きい。「0」は現ピクチャのPOC値よりも小さいPOC値を持つリファレンスピクチャを表わす。「1」は現ピクチャのPOC値よりも大きいPOC値を持つリファレンスピクチャを表わす。RefPicSetStCurr0，RefPicSetStCurr1，RefPicSetStFoll0およびRefPicSetStFoll1はまとめて、リファレンスピクチャセットの短期サブセットと呼ばれる。RefPicSetLtCurrおよびRefPicSetLtFollはまとめて、リファレンスピクチャセットの長期サブセットと呼ばれる。
HEVCドラフト規格では、リファレンスピクチャセットは、シーケンスパラメータセットで特定され、リファレンスピクチャセットへのインデクスを介してスライスヘッダ用に取込まれてもよい。リファレンスピクチャセットはスライスヘッダで特定されてもよい。リファレンスピクチャセットの長期サブセットは通常スライスヘッダでのみ特定されるが、同じリファレンスピクチャセットの短期サブセットはピクチャパラメータセットで特定されてもよく、スライスヘッダで特定されてもよい。リファレンスピクチャセットは独立して符号化されてもよく、別のリファレンスピクチャセットから予測されてもよい（インターRPS予測と呼ばれる）。リファレンスピクチャセットが独立して符号化される場合、シンタックス構造はタイプの異なるリファレンスピクチャの繰り返しを3ループまで含める。こうしたリファレンスピクチャとは、現ピクチャより小さいPOC値を持つ短期リファレンスピクチャと現ピクチャより大きいPOC値を持つ短期リファレンスピクチャ、長期リファレンスピクチャである。各ループエントリは、「リファレンスに使用済」とマークされるピクチャを特定する。一般に、ピクチャは異なるPOC値で特定される。インターRPS予測は、現ピクチャのリファレンスピクチャセットが先に復号済みのピクチャのリファレンスピクチャセットから予測可能であるという事実を利用する。これは、現ピクチャの全てのリファレンスピクチャは、前のピクチャのリファレンスピクチャであるか、先に復号済みのピクチャそのものであるかの何れかであるからである。したがって、これらのピクチャの中のどれがリファレンスピクチャであり、現ピクチャの予測に用いられるかを示すことだけが必要となる。リファレンスピクチャセット符号化の両方の種類で、各リファレンスピクチャに対してフラグ（used_by_curr_pic_X_flag)が追加で送信される。このフラグは、そのリファレンスピクチャがリファレンスとして現ピクチャに用いられるか（*Curr listに含まれる）、そうでないか（*Foll listに含まれる）を示す。現在のスライス（現スライス）が使うリファレンスピクチャセットに含まれるピクチャは「リファレンスに使用済」とマークされ、現スライスが使うリファレンスピクチャセットに含まれないピクチャは「リファレンスに未使用」とマークされる。現ピクチャがIDRピクチャである場合、RefPicSetStCurr0，RefPicSetStCurr1，RefPicSetStFoll0，RefPicSetStFoll1，RefPicSetLtCurr，およびRefPicSetLtFollは全て空に設定される。
復号ピクチャバッファ（Decoded Picture Buffer；DPB）はエンコーダおよび／またはデコーダで使用されてもよい。復号ピクチャをバッファする理由は2つある。一つはインター予測で参照するためで、もう一つは復号ピクチャを出力順に並べ直すためである。H.264/AVCおよびHEVCはリファレンスピクチャのマーキングと出力の並べ換えの両方で相当な柔軟性を与えるため、リファレンスピクチャのバッファリングと出力ピクチャのバッファリングで別々のバッファを使うことはメモリリソースを浪費する可能性がある。このためDPBは、リファレンスピクチャと出力並び替えのための統合された復号ピクチャバッファリング処理を備えてもよい。復号ピクチャは、リファレンスとして使用されず出力される必要がなくなると、DPBから削除されてもよい。
H.264/AVCおよびHEVC等の多くの符号化モードでは、インター予測用リファレンスピクチャはリファレンスピクチャ・リストへのインデクスで示される。このインデクスは可変長符号化で符号化されてもよい。可変長符号化によって多くの場合、インデクスを小さくして対応するシンタックス要素に対してより小さい値を持つことができる。H.264/AVCおよびHEVCでは、双予測（B）スライスにはそれぞれ2つのリファレンスピクチャ・リスト（リファレンスピクチャ・リスト0およびリファレンスピクチャ・リスト1）が作成され、インター予測（P）スライスにはそれぞれ1つのリファレンスピクチャ・リスト（リファレンスピクチャ・リスト0）が形成される。加えて、HEVCのBスライスでは、最終リファレンスピクチャ・リスト（リスト0およびリスト1）が作成された後に統合リスト（リストC）が作成される。統合リストはBスライス内での単予測（単方向予測とも呼ばれる）に用いられてもよい。
リファレンスピクチャ・リスト0およびリファレンスピクチャ・リスト1等のリファレンスピクチャ・リストは通常、2つのステップで作成される。第1ステップでは、初期リファレンスピクチャ・リストが作成される。初期リファレンスピクチャ・リストは例えば、frame_numやPOC，temporal_id，GOP構造などの予測階層に関する情報、またはこれらの組合せに基づいて作成されてもよい。第2ステップでは、リファレンスピクチャ・リスト並び替え（reference picture list reordering；RPLR）命令によって初期リファレンスピクチャ・リストが並び替えられてもよい。RPLR命令はリファレンスピクチャ・リスト変更シンタックス構造とも呼ばれ、スライスヘッダに含まれてもよい。RPLR命令は、各リファレンスピクチャ・リストの先頭に並べられるピクチャを示す。第2ステップはリファレンスピクチャ・リスト変更処理とも呼ばれ、RPLR命令がリファレンスピクチャ・リスト変更シンタックス構造に含まれてもよい。リファレンスピクチャセットが用いられる場合、リファレンスピクチャ・リスト0はRefPicSetStCurr0，RefPicSetStCurr1，RefPicSetLtCurrをこの順序で含むように初期化されてもよい。リファレンスピクチャ・リスト1はRefPicSetStCurr1，RefPicSetStCurr0をこの順序で含むように初期化されてもよい。初期リファレンスピクチャ・リストはリファレンスピクチャ・リスト変更シンタックス構造を通じて変更されてもよい。初期リファレンスピクチャ・リストのピクチャはリストに対するエントリインデクスを通じて識別されてもよい。
HEVCの統合リストは次のように作成されてもよい。統合リストの変更フラグがゼロである場合、統合リストは特定の暗黙的機構で作成される。そうでない場合、ビットストリームに含まれるリファレンスピクチャ統合命令によって作成される。この暗黙的機構では、リストCのリファレンスピクチャは、リスト0とリスト1からのリファレンスピクチャにマッピングされる。このマッピングは、リスト0の最初のエントリから始まってリスト1の最初のエントリが続くといったインターリーブ方式で行われる。既にリストCにマッピング済みのリファレンスピクチャが再度マッピングされることはない。明示的機構では、リストCのエントリ数が信号で伝えられ、次にリスト0またはリスト1のエントリからリストCのエントリへのマッピングが行われる。加えて、リスト0とリスト1が同一である場合は、エンコーダはref_pic_list_combination_flagを0に設定するオプションを備える。これは、リスト1からリファレンスピクチャがマッピングされておらず、リストCがリスト0と等価であることを示す。HEVCドラフトコーデック等の典型的な高効率ビデオコーデックでは追加的な動き情報符号化／復号機構を用い、通常、マージング処理／機構またはマージモード処理／機構と呼ばれる。これにより、ブロック／PUの全ての動き情報が予測され、変更／修正をせずに使用される。PUに対する前述の動き情報は次のものを含む：1）PUがリファレンスピクチャ・リスト0のみを用いて単予測されるか、PUがリファレンスピクチャ・リスト1のみを用いて単予測されるか、またはPUがリファレンスピクチャ・リスト0およびリファレンスピクチャ・リスト1の両方を用いて単予測されるかに関する情報；2）リファレンスピクチャ・リスト0に対応する動きベクトル値；3）リファレンスピクチャ・リスト0におけるリファレンスピクチャ・インデクス；4）リファレンスピクチャ・リスト1に対応する動きベクトル値；5）リファレンスピクチャ・リスト1におけるリファレンスピクチャ・インデクス。同様に、動き情報の予測は、時間軸上のリファレンスピクチャにおける隣接ブロックおよび／または同位置のブロックの動き情報を用いて行われる。通常、利用可能な隣接／同位置ブロックに関連する動き予測候補を含めることによってマージリストと呼ばれるリストが構成され、リスト中で選択された動き予測候補のインデクスが信号で伝えられる。こうして、選択された候補の動き情報は現PUの動き情報にコピーされる。CU全体でマージ機構が用いられ、CU用予測信号が再構成信号として使用される場合、すなわち、予測残差が処理されない場合、CUに対するこの種の符号化／復号は通常、スキップモードやマージベース・スキップモードと呼ばれる。各PUに対しては、スキップモードに加えてマージ機構も使用され、この場合、予測の質を向上させるために予測残差が利用されてもよい。この種の予測モードは通常、インターマージモードと呼ばれる。
復号リファレンスピクチャ・マーキング用シンタックス構造がビデオ符号化システムに存在してもよい。例えば、ピクチャの復号が完了したとき、復号リファレンスピクチャのマーキングシンタックス構造が存在する場合には、それが「リファレンスに未使用」または「長期リファレンスに使用済」としてピクチャを適応的にマークするのに用いられてもよい。復号リファレンスピクチャのマーキングシンタックス構造が存在せず、「リファレンスに使用済」とマークされたピクチャの数がそれ以上増えることがない場合、スライディングウィンドウのリファレンスピクチャ・マーキングが用いられてもよい。これは基本的には、（復号順で）最初に復号されたリファレンスピクチャをリファレンスに未使用としてマークする。
スケーラブルビデオ符号化とは、コンテンツに関してビットレートや解像度、および／またはフレームレートが異なる複数の表現を1つのビットストリームが格納できるような符号化構造を表わす。このような場合、受信側は、その特定（例えば、装置のディスプレイの解像度に最適な解像度）に応じて望ましい表現を抽出できる。あるいは、サーバまたはネットワーク要素が、ネットワーク特性や受信側の処理能力等に応じて受信側に送信されるように、ビットストリームの一部を抽出することもできる。
スケーラブルビットストリームは、利用可能な最低品質ビデオを提供する1層の基本レイヤと、下位レイヤと共に受信・復号されるとビデオ品質を高める1層以上の拡張レイヤから構成されてもよい。拡張レイヤは時間分解能（すなわち、フレームレート）や空間分解能を上げたり、別のレイヤやその一部によって表わされるビデオコンテンツの品質を単に上げたりしてもよい。拡張レイヤに対する符号化効率を高めるために、レイヤの符号化表現は下位レイヤに依存してもよい。例えば、拡張レイヤの動き情報およびモード情報が下位レイヤから予測されてもよい。同様に、拡張レイヤ予測を作成するために、下位レイヤのピクセルデータを用いることもできる。
各スケーラブルレイヤは、それぞれの全ての従属レイヤと合わせて、特定の空間分解能，時間分解能および品質レベルでのビデオ信号の一表現となる。本願では、全ての従属レイヤを伴うスケーラブルレイヤを「スケーラブルレイヤ表現」と呼ぶ。特定の忠実度で元の信号表現を生成するために、スケーラブルレイヤ表現に対応するスケーラブルビットストリームの一部が抽出され復号される。
場合によっては、特定の位置または任意の位置の後で拡張レイヤのデータが切り捨てられてもよい。ここで切り捨て位置はそれぞれ、視覚的品質を高めて表現する追加データを含んでもよい。こうしたスケーラビリティは細粒度スケーラビリティ（fine-grained/granularity scalability；FGS）と呼ばれる。FGSはSVC規格のドラフトバージョンの一部に含まれていたが、最終版SVC規格からは除外された。よって以降では、FGSはSVC規格のドラフトバージョンの一部を背景として説明される。切り捨てされない拡張レイヤによって提供されるスケーラビリティは、粗粒度スケーラビリティ（coarse-grained/granularity scalability；CGS）と呼ばれる。これは、従来の品質（SNR）スケーラビリティと空間スケーラビリティを合わせて含む。SVC規格はいわゆる中粒度スケーラビリティ（medium-grained/granularity scalability；MGS）をサポートする。MGSでは、高品質ピクチャがSNRスケーラブルレイヤピクチャと同様に符号化されるが、FGSレイヤピクチャと同じ高水準シンタックス要素を用いて、シンタックス要素quality_idが0を超えることによって示される。
SVCはレイヤ間予測機構を用い、現在再構成済みのレイヤ以外のレイヤまたは次の下位レイヤから特定の情報を予測できる。レイヤ間予測できた情報は、イントラテクスチャと動き，残差のデータを含む。レイヤ間動き予測は、ブロック符号化モードやヘッダ情報などの予測を含み、下位レイヤからの動きが上位レイヤの予測に用いられてもよい。イントラ符号化の場合、下位レイヤの周囲マクロブロックや同位置のマクロブロックからの予測が可能である。こうした予測技術は先に符号化済みのアクセスユニットからの情報を使わないため、イントラ予測技術と呼ばれる。また、下位レイヤからの残差データも現レイヤの予測に用いることができる。
SVCは単一ループ復号と呼ばれる概念を特定する。これは制約テクスチャ内予測モードを用いることで可能となる。レイヤ間テクスチャ内予測はマクロブロック（MB）であって、そのMB内にベースレイヤの対応するブロックが位置するMBに対して適用可能である。同時に、ベースレイヤにおけるこうしたイントラMBは、制約イントラ予測を使用する（例えば、シンタックス要素"constrained_intra_pred_flag"が1に等しい）。単一ループ復号では、デコーダは再生に望ましいスケーラブルレイヤ（「希望レイヤ」または「ターゲットレイヤ」と呼ばれる）に対してだけ動き補償および完全ピクチャ再構成を遂行する。こうして、復号における複雑さを大幅に減らせる。希望レイヤ以外の全てのレイヤは完全に復号される必要がない。これは、レイヤ間予測（レイヤ間テクスチャ内予測，レイヤ間動き予測またはレイヤ間残差予測）に使用されないMBデータの全てまたは一部が希望レイヤの再構成に必要ないからである。
単一復号ループは殆どのピクチャの復号に必要であるが、第2の復号ループはベース表現を再構成するために選択的に適用される。このベース表現は、予測リファレンスとして必要であるが、出力または表示される必要はないので、いわゆるキーピクチャ（"store_ref_base_pic_flag"が1に等しい）に対してのみ再構成される。
SVCドラフトにおけるスケーラビリティ構造は"temporal_id"，"dependency_id"，"quality_id"の3つのシンタックス要素で特徴付けられる。シンタックス要素"temporal_id"は、時間スケーラビリティ階層または間接的にはフレームレートを示すのに用いられる。"temporal_id"の最大値が小さいピクチャを含むスケーラブルレイヤ表現のフレームレートは、"temporal_id"の最大値が大きいピクチャを含むスケーラブルレイヤ表現のフレームレートよりも低い。所与の時間レイヤは通常、下位時間レイヤ（すなわち、"temporal_id"がより小さい値の時間レイヤ）に依存するが、どの上位時間レイヤにも依存しない。シンタックス要素"dependency_id"は、CGSレイヤ間符号化依存階層を示すのに用いられる（前述の通り、SNRと空間スケーラビリティの両方を含む）。どの時間レベル位置でも、"dependency_id"値が小さいピクチャは、"dependency_id"値が大きいピクチャの符号化におけるレイヤ間予測に用いられてもよい。シンタックス要素"quality_id"は、FGSまたはMGSレイヤの品質レベル階層を示すのに用いられる。どの時間レベル位置でも、同一の"dependency_id"値であれば、"quality_id"値がQLに等しいピクチャは"quality_id"値がQL-1に等しいピクチャをレイヤ間予測に使用する。0を超える"quality_id"を持つ符号化スライスは、切り捨て可能なFGSスライスまたは切り捨て不可能なMGSスライスの何れかとして符号化されてもよい。
単純化するために、同一の"dependency_id"値を持つアクセスユニットにおける全てのデータユニット（SVCの場合、ネットワーク抽象化層ユニット／NALユニットなど）は、依存ユニットまたは依存表現と呼ばれる。1依存ユニット内では、同一の"quality_id"値を持つ全てのデータユニットは、品質ユニットまたはレイヤ表現と呼ばれる。
復号ベースピクチャとも呼ばれるベース表現は、"quality_id"値が0に等しい依存ユニットにおけるビデオ符号化レイヤ（VCL）NALユニットの復号結果から得られる復号ピクチャで、"store_ref_base_pic_flag"が1に設定される。復号ピクチャとも呼ばれる拡張表現は通常の復号処理結果から得られ、最大依存表現に対して存在する全てのレイヤ表現が復号される。
前述の通り、CGSは空間スケーラビリティとSNRスケーラビリティの両方を含む。空間スケーラビリティは最初に、解像度の異なるビデオ表現をサポートするように設計される。各時間インスタンスに対して、VCL-NALユニットは同一アクセスユニットで符号化され、これらのVCL-NALユニットが別々の解像度に対応している。復号中、低解像度VCL-NALユニットは動きフィールドおよび残差を提供する。これらは、高解像度ピクチャの最終復号および再構成によって引き継がれてもよい。従来のビデオ圧縮規格と比較した場合、SVCの空間スケーラビリティは、ベースレイヤが拡張レイヤをクロップおよびズームしたバージョンとなれるように一般化されている。
MGS品質レイヤはFGS品質レイヤと同様に"quality_id"で示される。各依存ユニット（同一の"dependency_id"を持つ）に対して、"quality_id"が0に等しいレイヤが存在し、"quality_id"が0を超える他のレイヤも存在し得る。"quality_id"が0を超えるこうしたレイヤは、スライスが切り捨て可能スライスとして符号化されたかどうかに応じてMGSレイヤまたはFGSレイヤの何れかである。
FGS拡張レイヤの基本形では、レイヤ間予測のみが使用される。したがって、FGS拡張レイヤは、復号シーケンスで誤差を伝播させず自由に切り捨てできる。しかし、FGSの基本形は圧縮効率が低くなる。この問題は、インター予測リファレンスに低品質ピクチャのみが使用されることで生じる。したがって、インター予測リファレンスとしてFGS拡張ピクチャの使用が提案されている。しかしこうした提案でも、FGSデータの一部が捨てられる際、ドリフトと呼ばれる符号化・復号間の不整合が生じ可能性がある。
SVCドラフト規格の特徴はFGS-NALユニットが自由にドロップされたり、切り捨てられたりできるが、SVCV規格の特徴は、MGS-NALユニットがビットストリームの適合性を損なわず自由にドロップされることができる（しかし、切り捨てられることはできない）。前述の通り、符号化時にこうしたFGSまたはMGSデータがインター予測リファレンスに対して使用される場合、データのドロップまたは切り捨てはデコーダ側とエンコーダ側との間で復号ピクチャの不整合を生じさせる。この不整合がドリフトと呼ばれる。
FGSまたはMGSデータのドロップまたは切り捨てによるドリフトを制御するために、SVCは次の解決方法を適用してきた。特定の依存ユニットにおいて、（"quality_id"が0に等しいCGSピクチャのみの復号とそれに依存する全ての下位レイヤデータによる）ベース表現は復号ピクチャバッファに格納される。同一の"dependency_id"値を持つ次の依存ユニットを符号化する際、FGS-NALまたはMGS-NALユニットを含む全てのNALユニットはインター予測リファレンス用にベース表現を使用する。その結果、先のアクセスユニットにおけるFGS／MGS-NALユニットのドロップまたは切り捨てによるドリフトは全て、このアクセスユニットで止められる。同一の"dependency_id"値を持つ他の依存ユニットに対して、全てのNALユニットは、高い符号化効率のために、インター予測リファレンス用にこの復号ピクチャを使用する。
NALユニットはそれぞれのNALユニットヘッダにシンタックス要素"use_ref_base_pic_flag"を含む。この要素の値が1に等しい場合、NALユニットの復号ではインター予測処理時にリファレンスピクチャのベース表現を使用する。シンタックス要素"store_ref_base_pic_flag"は、後のピクチャに対してインター予測用に現ピクチャのベース表現を格納するか（値が1の場合）否か（値が0の場合）を特定する。
"quality_id"が0を超えるNALユニットはリファレンスピクチャ・リスト作成および加重予測に関するシンタックス要素を含まない。すなわち、シンタックス要素"num_ref_active_lx_minus1"（xは0または1）やリファレンスピクチャ・リスト並び替えシンタックステーブル，加重予測シンタックステーブルは存在しない。その結果、MGSまたはFGSレイヤは、必要に応じて同一の依存ユニットにおける"quality_id"が0に等しいNALユニットからこうしたシンタックス要素を引き継がなくてはならない。
SVCでは、リファレンスピクチャ・リストはベース表現のみ（"use_ref_base_pic_flag"が1の場合）または「ベース表現」とマークされていない復号ピクチャのみ（"use_ref_base_pic_flag"が0の場合）の何れかから構成され、同時に両方から構成されることはない。
H.264/AVCビットストリームにおいて、符号化ビデオシーケンスの符号化ピクチャは同一のシーケンスパラメータセットを用い、復号処理中の任意の時点で、1つのシーケンスパラメータセットのみがアクティブになる。SVCでは、それぞれのスケーラブルレイヤからの符号化ピクチャが別々のシーケンスパラメータセットを使用してもよい。別々のシーケンスパラメータセットが使用される場合、復号処理中の任意時点で、アクティブなシーケンスピクチャパラメータセットが複数あってもよい。SVC規格では、最上位レイヤのものをアクティブ・シーケンスピクチャパラメータセットと呼ばれ、残りのものはレイヤアクティブ・シーケンスピクチャパラメータセットと呼ばれる。所定のアクティブシーケンスパラメータセットは何れも、そのアクティブシーケンスパラメータセットが参照されるレイヤにある符号化ビデオシーケンス全体で不変である。
品質スケーラビリティ（信号対ノイズ比またはSN比とも呼ばれる）および／または空間スケーラビリティ対応スケーラブルビデオエンコーダは、次のように実装されてもよい。基本レイヤに対しては、従来の非スケーラブルビデオエンコーダおよびデコーダが使用されてもよい。基本レイヤの再構成／復号ピクチャは、拡張レイヤに対して、リファレンスピクチャ・バッファおよび／またはリファレンスピクチャ・リストに含められる。空間スケーラビリティの場合、再構成／復号基本レイヤピクチャは、拡張レイヤピクチャに対してリファレンスピクチャ・リストに挿入される前に、アップサンプリング（upsample）されてもよい。基本レイヤ復号ピクチャは、拡張レイヤの復号リファレンスピクチャと同様に、拡張レイヤピクチャの符号化／復号のため、リファレンスピクチャ・リストに挿入されてもよい。その結果、エンコーダはインター予測リファレンスとして基本レイヤリファレンスピクチャを選択し、その使用を、リファレンスピクチャ・インデクスを用いて符号化ビットストリームに示してもよい。デコーダはビットストリームから、例えばリファレンスピクチャ・インデクスから、基本レイヤピクチャが拡張レイヤ用インター予測リファレンスとして使用されることを復号する。復号基本レイヤピクチャは、拡張レイヤ用予測リファレンスとして使用される場合、レイヤ間リファレンスピクチャと呼ばれる。
前段では1層の拡張レイヤと1層の基本レイヤという2層のスケーラビリティレイヤを持つスケーラブルビデオコーデックを記述したが、こうした記述は2層を超えるレイヤを持つスケーラビリティ階層における任意の2層のレイヤと一般化されてもよいことに留意する必要がある。この場合、第2の拡張レイヤは符号化および／または復号処理で第1の拡張レイヤに依存してもよく、その結果、第1の拡張レイヤは、第2の拡張レイヤの符号化および／または復号に対する基本レイヤと呼ばれてもよい。さらに、拡張レイヤ用リファレンスピクチャ・バッファまたはリファレンスピクチャ・リストの複数レイヤからレイヤ間リファレンスピクチャが取出され、このレイヤ間リファレンスピクチャの各々が、符号化および／または復号される拡張レイヤに対する基本レイヤまたはリファレンスレイヤに存在するものと見做されてもよいことにも留意する必要がある。
前に示した通り、MVCはH.264/AVCの拡張である。H.264/AVCの定義や概念，シンタックス構造，意味，復号処理の多くはそのまま、または特定の一般化や制約を伴ってMVCにも適用される。MVCの定義や概念，シンタックス構造，意味，復号処理の一部は以下で説明される。
MVCのアクセスユニットは、復号順に連続するNALユニットのセットと定義され、1つ以上のビュー成分から成る単一のプライマリ符号化ピクチャを含む。アクセスユニットは、プライマリ符号化ピクチャの他に1つ以上の冗長符号化ピクチャや補助符号化ピクチャ，符号化ピクチャのスライスまたはスライスデータパーティションを含む他のNALユニットを含んでもよい。アクセスユニットの復号の結果、復号誤差やビットストリーム誤差，復号に影響を及ぼす可能性のある他の誤差が生じなければ、1つ以上の復号ビュー成分から成る1つの復号ピクチャが得られる。換言すれば、MVCのアクセスユニットは、1つの出力時間インスタンスに対して複数のビューのビュー成分を含む。
MVCのビュー成分は単一アクセスユニットにおけるビューの符号化表現とも呼ばれる。
MVCではビュー間予測が使用されてもよく、同一アクセスユニットにおける別々のビュー成分の復号サンプルからビュー成分の予測を参照する。MVCでは、ビュー間予測はインター予測と同様にして実現される。例えば、ビュー間リファレンスピクチャはインター予測用リファレンスピクチャとして同一の（1つまたは複数の）リファレンスピクチャ・リストに配置され、動きベクトルだけでなくリファレンスインデクスも、ビュー間およびリファレンスピクチャ間で同様に符号化または推定される。
アンカーピクチャは符号化ピクチャであって、その中の全スライスが同一アクセスユニット内のスライスのみを参照できる。すなわち、ビュー間予測が使用可能であるが、インター予測は使用されず、出力順で後になる全ての符号化ピクチャは、復号順で符号化ピクチャの前のどのピクチャからもインター予測を使用しない。ビュー間予測は、非ベースビューの一部であるIDRビュー成分に使用されてもよい。MVCのベースビューは、符号化ビデオシーケンスでビュー順序インデクスの最大値を持つビューである。ベースビューは他のビューとは独立して復号でき、ビュー間予測を使用しない。ベースビューは、H.264/AVCのベースプロファイル（Baseline Profile）やハイプロファイル（High Profile）などの単一ビュープロファイルのみをサポートするH.264/AVCデコーダによって復号可能である。
MVC規格では、MVC復号処理のサブ処理の多くは、H.264/AVC規格のサブ処理の仕様にある「ピクチャ」，「フレーム」，「フィールド」という語句をそれぞれ「ビュー成分」，「フレームビュー成分」，「フィールドビュー成分」と置き換えることによって、H.264/AVC規格の各サブ処理を利用できる。これと同様に以下では、「ピクチャ」，「フレーム」，「フィールド」という語句がそれぞれ「ビュー成分」，「フレームビュー成分」，「フィールドビュー成分」を意味するものとして頻繁に用いられる。
MVCでは、それぞれのビューからの符号化ピクチャが別々のシーケンスパラメータセットを使用してもよい。MVCのSPSは、ビュー間予測用のビュー依存情報を含むことができる。これは例えば、ビュー依存ツリーを構築するために、信号アウェア・メディアゲートウェイにより使用されてもよい。
マルチビュービデオ符号化の状況においては、ビュー順序インデクスは、アクセスユニットのビュー成分の復号順序またはビットストリーム順序を示すインデクスとして定義されてもよい。MVCでは、ビュー間依存関係はシーケンスパラメータセットMVC拡張に示される。シーケンスパラメータセットMVC拡張はシーケンスパラメータセットに含まれる。MVC規格に従えば、符号化ビデオシーケンスにより参照される全てのシーケンスパラメータセットMVC拡張は同一であると規定される。シーケンスパラメータセットMVC拡張からの次の抜粋は、ビュー間依存関係がMVCで示されるようになるための詳細情報を提供する。
Figure 2015518338
MVC復号処理において、変数VOIdxはview_idで識別されたビューのビュー順序インデクスを表わすことができる（view_idは復号される符号化スライスのMVC NALユニットヘッダから取得される）。VOIdxは、シーケンスパラメータセットにおける参照されたサブセットに含まれるシンタックス要素view_id[ i ]がview_idに等しいとき、値iに設定されてもよい。
シーケンスパラメータセットMVC拡張の意味は次のように規定されてもよい。num_views_minus1 + 1（"num_views_minus1"は原文では太字であり、ビットストリームのシンタックス要素である）は、符号化ビデオシーケンスにおける符号化ビューの最大数を規定する。符号化ビデオシーケンスにおける実際のビュー数は、num_views_minus1 + 1よりも少なくてもよい。view_id[ i ] （"view_id"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しいビューのview_idを規定する。num_anchor_refs_l0[ i ] （" num_anchor_refs_l0"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しいアンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList0にあるビュー間予測用ビュー成分の数を規定する。anchor_ref_l0[ i ][ j ] （"anchor_refs_l0"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しいアンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList0にあるビュー間予測用ビュー成分の中のj番目要素のview_idを規定する。num_anchor_refs_l1[ i ] （"num_anchor_refs_l1"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しいアンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList1にあるビュー間予測用ビュー成分の数を規定する。anchor_ref_l1[ i ][ j ] （"anchor_ref_l1"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しいアンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList1にあるビュー間予測用ビュー成分の中のj番目要素のview_idを規定する。num_non_anchor_refs_l0[ i ] （"num_non_anchor_refs_l0"は原文では太字であり、ビットストリームのシンタックス要素である） は、VOIdxがiに等しい非アンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList0にあるビュー間予測用ビュー成分の数を規定する。non_anchor_ref_l0[ i ][ j ] （"non_anchor_ref_l0"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しい非アンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList0にあるビュー間予測用ビュー成分の中のj番目要素のview_idを規定する。num_non_anchor_refs_l1[ i ] （"num_non_anchor_refs_l1"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しい非アンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList1にあるビュー間予測用ビュー成分の数を規定する。non_anchor_ref_l1[ i ][ j ] （"non_anchor_ref_l1"は原文では太字であり、ビットストリームのシンタックス要素である）は、VOIdxがiに等しい非アンカービュー成分の復号において、最初のリファレンスピクチャ・リストRefPicList1にあるビュー間予測用ビュー成分の中のj番目要素のview_idを規定する。view_idがvId1でありVOIdxがvOIdx1である任意特定のビューと、view_idがvId2でありVOIdxがvOIdx2である別のビューに対し、vId2が、0を超えnum_non_anchor_refs_l0[ vOIdx1 ]未満の範囲にある全てのjに対するnon_anchor_ref_l0[ vOIdx1 ][ j ]のある1つの値と等しい、または、0を超えnum_non_anchor_refs_l1[ vOIdx1 ]未満の範囲にある全てのjに対するnon_anchor_ref_l1[ vOIdx1 ][ j ]のある1つの値と等しい場合、vId2はまた、0を超えnum_anchor_refs_l0[ vOIdx1 ]未満の範囲にある全てのjに対するanchor_ref_l0[ vOIdx1 ][ j ]のある1つの値と等しい、または、0を超えnum_anchor_refs_l1[ vOIdx1 ]未満の範囲にある全てのjに対するanchor_ref_l1[ vOIdx1 ][ j ]のある1つの値と等しくなくてはならない。非アンカービュー成分に対するビュー間依存は、アンカービュー成分に対するビュー間依存の一部である。
スケーラブル・マルチビュー符号化では、同一ビットストリームが複数のビューの符号化ビュー成分を含んでもよく、符号化ビュー成分の少なくとも一部は品質および／または空間スケーラビリティを用いて符号化されてもよい。
テクスチャビューは通常のビデオコンテンツを示すビューを指す。これは例えば、普通のカメラで撮影されたもので、通常ディスプレイへのレンダリングに適している。テクスチャビューは通常、1つの輝度成分と2つの色差の3つの成分を持つピクチャを含む。以下では、テクスチャピクチャは通常、輝度テクスチャピクチャと色差テクスチャピクチャという語句などで示されない限り、その成分のピクチャまたはカラー成分の全てを含む。
深度拡張ビデオは、1つ以上の深度ビューを持つ深度ビデオに関連する1つ以上のビューを持つテクスチャビデオを指す。深度拡張ビデオに関する様々なアプローチが用いられてもよく、ビデオ＋深度（video plus depth；V+D）やマルチビュービデオ＋深度（multiview video plus depth；MVD），レイヤ深度ビデオ（layered depth video；LDV）の使用を含む。ビデオ＋深度（V+D）表現では、単一のテクスチャビューと個別の深度ビューがそれぞれ、テクスチャピクチャと深度ピクチャのシーケンスとして表現される。MVDは複数のテクスチャビューとそれぞれの深度ビューを含む。LDV表現では、中央ビューのテクスチャと深度が従来通りに表現されるが、他のビューのテクスチャと深度は部分的に表現され、中間ビューの正確なビュー合成に関しては遮蔽されていない領域のみをカバーする。
テクスチャビュー成分は、単一アクセスユニットにおけるビューのテクスチャの符号化表現として規定されてもよい。深度拡張ビデオビットストリームにおけるテクスチャビュー成分は、シングルビューのテクスチャビットストリームまたはマルチビューのテクスチャビットストリームと互換性のある方式で符号化されてもよい。これにより、シングルビューまたはマルチビューのデコーダは、深度ビューを復号できない場合でもテクスチャビューを復号することができる。例えば、H.264/AVCデコーダは、深度拡張H.264/AVCビットストリームからシングルテクスチャビューを復号できる。あるいは、深度ベースのコーディングツールが使われているという理由等から、H.264/AVCまたはMVCのデコーダ等、シングルビューまたはマルチビューのテクスチャを復号できるデコーダではテクスチャビュー成分の復号が不可能であるような方式で、テクスチャビュー成分が符号化されてもよい。深度ビュー成分は、単一アクセスユニットにおけるビューの深度の符号化表現として規定されてもよい。ビュー成分ペアは、同一アクセスユニット内の同一ビューに関するテクスチャビュー成分および深度ビュー成分として規定されてもよい。
深度拡張ビデオは、テクスチャと深度が互いに独立して符号化される方式で符号化されてもよい。例えば、テクスチャビューはMVCビットストリームとして符号化され、深度ビューは別のMVCビットストリームとして符号化されてもよい。深度拡張ビデオはまた、テクスチャと深度が一緒に符号化される方式で符号化されてもよい。テクスチャおよび深度ビューの統合符号化が深度拡張ビデオ表現に適用される場合、テクスチャピクチャの復号サンプルの一部またはテクスチャピクチャの復号用データ要素の一部は、深度ピクチャの復号サンプルの一部または深度ピクチャの復号処理で得られたデータ要素の一部から予測または導出される。あるいは、または加えて、深度ピクチャの復号サンプルの一部または深度ピクチャの復号用データ要素の一部は、テクスチャピクチャの復号サンプルの一部またはテクスチャピクチャの復号処理で得られたデータ要素の一部から予測または導出される。別のオプションでは、テクスチャの符号化ビデオデータおよび深度の符号化ビデオデータは、一方から他方が予測されず、または、一方が他方に基づいて符号化／復号されないこともある。しかし、符号化テクスチャ・深度ビューは、符号化では同一ビットストリームに多重化（multiplex）され、復号ではそのビットストリームから逆多重化（demultiplex）されてもよい。さらに別の選択肢では、テクスチャの符号化ビデオデータが、後述するスライスレイヤ等における深度の符号化ビデオデータから予測されないが、テクスチャビューおよび深度ビューの上位符号化構造の一部が相互に共有または予測されてもよい。例えば、符号化深度スライスのスライスヘッダが符号化テクスチャのスライスヘッダから予測されてもよい。さらに、パラメータセットの一部が符号化テクスチャビューと符号化深度ビューの両方で使用されてもよい。
マルチビュー3次元ビデオ（3DV）アプリケーションに対するソリューションは、限定された入力ビュー数だけ、例えば、モノラルまたはステレオビューと付加データだけを持ち、必要なビューの全てをデコーダでローカルにレンダリング（すなわち、合成）するというものだと理解される。幾つかの利用可能なビューレンダリング技術から、深度イメージベース・レンダリング（depth image-based rendering；DIBR）は競合代替技術であると見られている。
DIBRベースの3DVシステムの簡易モデルを図5に示す。3Dビデオコーデックの入力は、立体ビデオと立体ベースラインb0と共に対応する深度情報を含む。3Dビデオコーデックは、ベースライン（bi < b0）と共に、2つの入力ビュー間の複数の仮想ビューを合成する。DIBRアルゴリズムは2つの入力ビュー間だけでなく、その外側のビューを外挿することもできる。同様に、DIBRアルゴリズムは単一のテクスチャビューと個別の深度ビューからビューを合成することもできる。しかし、DIBRベースのマルチビューレンダリングを可能にするために、テクスチャデータが対応する深度データと共にデコーダ側で利用可能であるべきである。
こうした3DVシステムでは、各ビデオフレームに対して深度情報が（深度マップと呼ばれる）深度ピクチャの形式で、エンコーダ側で作成される。深度マップは、ピクセル毎の深度情報を伴う画像である。深度マップの各サンプルは、カメラが配置された面からそれぞれのテクスチャサンプルまでの距離を表わす。換言すれば、z軸がカメラの撮影方向に沿う（したがって、カメラが配置された面に対して直交する）場合、深度マップのサンプルはz軸の値を表わす。
深度情報は様々な手段で取得することができる。例えば、3Dシーンの深度は、撮影するカメラによって記録される視差から計算されてもよい。深度推定アルゴリズムは、立体ビューを入力として受取り、そのビューに関する2つのオフセット画像間のローカルな視差を計算する。各画像は重複ブロックでピクセル毎に処理され、各ピクセルブロックに対してオフセット画像において一致するブロックが水平方向でローカルに探索される。ピクセル方向の視差が計算されると、対応する深度の値zが式（1）によって計算される。

z = （f・b）／（d + Δd） ... 式（１）

ここで、fはカメラの焦点距離、bはカメラ間のベースライン距離であり、図6に示されている。さらに、dは2つのカメラの間で観測される視差を表わし、カメラオフセットΔdは2つのカメラの光学中心に関して生じ得る水平方向の位置のずれを示す。ただし、アルゴリズムはブロックの一致に基づくため、深度を通じた視差推定の質はコンテンツに依存し、殆どの場合正確ではない。例えば、質感がなく非常に滑らかな領域や高いノイズレベルを含む画像部分に対しては、直接深度推定を行うことは不可能である。
ISO/IEC国際規格23002-3で既定されるparallax mapのような格差／視差マップは、深度マップと同様に処理されてもよい。深度と視差には直接的な対応関係があり、数学的方程式を介して一方から他方を算出することができる。
テクスチャビューと深度ビューは、テクスチャビューの一部がH.264/AVCおよび／またはMVC等の1つ以上のビデオ規格に準拠した単一ビットストリームに符号化されてもよい。換言すれば、デコーダはこうしたビットストリームのテクスチャビューの一部を復号でき、残りのテクスチャビューと深度ビューを除外できてもよい。
こうした背景では、1つ以上のテクスチャ・深度ビューを単一のH.264/AVCおよび／またはMVC準拠ビットストリームに符号化するエンコーダは、3DV-ATMエンコーダとも呼ばれる。こうしたエンコーダによって生成されたビットストリームは、3DV-ATMビットストリームと呼ぶことができる。3DV-ATMビットストリームはH.264/AVCおよび／またはMVCデコーダが復号できない一部のテクスチャビューと深度ビューを含んでもよい。3DV-ATMビットストリームからのビュー全てを復号できるデコーダは3DV-ATMデコーダと呼ぶこともできる。
3DV-ATMビットストリームはAVC/MVC準拠テクスチャビューを選択された数だけ含むことができる。AVC/MVC準拠テクスチャビューに対する深度ビューは、テクスチャビューから予測されてもよい。残りのテクスチャビューは拡張テクスチャ符号化を利用し、深度ビューが深度符号化を利用してもよい。
3DV-ATMビットストリームのシンタックスと意味、3DV-ATMビットストリームに対する復号処理の実施例は、『深度マップを含むMVC拡張のワーキングドラフト2』（ "Working Draft 2 of MVC extension for inclusion of depth maps"）という文献MPEG N12544に見られる。これは、MVC互換であるテクスチャビューを少なくとも2つ必要とする。3DV-ATMビットストリームのシンタックスと意味、3DV-ATMビットストリームに対する復号処理の実施例は、『深度情報を伴うAVC互換ビデオのワーキングドラフト1』（ "Working Draft 1 of AVC compatible video with depth information"）という文献MPEG N12545にも見られる。これは、AVC互換であるテクスチャビューを少なくとも1つと、MVC互換でもよい追加テクスチャビューを必要とする。前述の文献で規定されるビットストリームのフォーマットと復号処理は、次に記載されるように互換性を持つ。『深度マップを含むMVC拡張』のワーキングドラフト（MPEG N12544）に対応する3DV-ATM構成は、「3D High」と呼ばれる。『深度情報を伴うAVC互換ビデ』のワーキングドラフト（MPEG N12545）に対応する3DV-ATM構成は、「3次元拡張ハイ（3D Extended High / 3D Enhanced High）」と呼ばれる。3次元拡張ハイ構成は、3次元ハイ構成の上位構成である。つまり、3次元拡張ハイ構成対応のデコーダは、3次元ハイ構成で作成されたビットストリームも復号可能でなくてはならない。
3DV-ATMでは、文献MPEG N12544およびN12545で規定されるように、ビュー間依存順序がテクスチャビューではなく深度ビューに関して同一である。つまり、シーケンスパラメータセットMVC拡張の中身は、全てのアクティブシーケンスパラメータセットで同一である。また3DV-ATMにおいて、ビュー順序インデクスはアクセスユニットのテクスチャまたは深度成分の復号順序を示すが、深度ビュー成分に関連するテクスチャビュー成分の復号順序は示さない。
図10は、3DV-ATM等での深度マップ符号化の例示的処理フローを示す。
深度マップは、例えばインループ統合ビュー間深度フィルタ（Joint inter-View Depth Filtering；JVDF）を用いて次のように一緒にフィルタされてもよい。現在処理中のビューVcの深度マップは、深度空間（Z空間）に変換される。
Figure 2015518338
次に、他の利用可能なビュー(Va1, Va2)の深度マップイメージが深度空間に変換され、現在処理中のビューVcに投影される。この投影は複数の深度予測値を生成する。これらの深度予測値を平均してデノイズ（denoise）深度予測値としてもよい。現在ビューVcのフィルタ済深度値
Figure 2015518338
は、利用可能なビューVa から現在処理中のビューVcまで投影された深度予測値の加重平均
Figure 2015518338
から得られてもよい。
Figure 2015518338
ここで、 {w1, w2} はそれぞれのビューまたはビュー投影の深度値に対する加重ファクタまたはフィルタ係数である。
深度予測値が特定の信頼区間にある場合、換言すれば、予測値の差の絶対値が特定の閾値（Th）未満である場合に、フィルタ処理が適用されてもよい。例えば、
|za→c - zc |<Thであれば、w1=w2=0.5であり、
そうでなければ、w1 = 1, w2 = 0である。
パラメータThは例えば、シーケンスパラメータセットでデコーダに伝送されてもよい。
図11は、JVDFのインループ実装を用いた2つの深度マップの符号化例を示す。黒の破線でマークされた箱1100には、H.264/AVC等の従来のビデオ符号化アルゴリズムが描かれている。JVDFは実線の箱1102に描かれている。
統合マルチビュービデオ・プラス・深度符号化（JMVDC）と呼ばれるコーディングツールでは、マルチビューテクスチャビデオと関連する深度ビューシーケンスとの間の相関が利用される。テクスチャビデオとその深度マップシーケンスとの間ではピクセル値がかなり異なるが、そのテクスチャビデオと深度マップシーケンスにおける対象のシルエットと動きは通常同じである。提案されているJMVDC方式は、MVCとSVCの符号化方式を組合せて実現されてもよい。具体的には、SVCのレイヤ間動き予測機構をMVCの予測処理の構成に実装することにより、JMVDCが実現されてもよい。各ビューは符号化され、2層表現と見做されることもある。ここで、テクスチャは基本レイヤにあり、深度は拡張レイヤにあって、レイヤ間動き予測のみを許容するSVCの粗粒度スケーラビリティ（coarse granular scalability；CGS）を用いて符号化されてもよい。加えて、基本ビュー以外に対しては、基本レイヤ（テクスチャ）と拡張レイヤ（深度）の両方でビュー間予測が可能である。JMVDCのレイヤ間動き予測は基本レイヤに用いられる任意のビュー間予測構造に適用できるが、エンコーダおよびデコーダは、ビュー間予測がIDRとアンカーアクセスユニットのみで現われるような方式で実現されてもよい。こうしてエンコーダおよびデコーダでは、JMVDCの複雑さと圧縮効率との間で合理的な妥協がなされ、JMVDCの実装を容易にする効果がもたらされる。次に、ビュー間予測がIDR／アンカーアクセスユニットでのみ許容され、非IDR／非アンカーアクセスユニットでは許容されない場合におけるIDR／アンカーおよび非アンカーアクセスユニットに対するJMVDC方式を説明する。
IDRおよびアンカーピクチャに対して、JMVDC方式は次のように適用される。ビュー間予測に用いられる動きベクトルは視差ベクトル（disparity vector）と呼ばれる。図12に示すように、マルチビューテクスチャビデオの視差ベクトルは、レイヤ間動き予測処理においてマルチビュー深度マップの視差ベクトルを導出するための予測リファレンスとして使用される。特定の例示的符号化方式では、この予測機構はレイヤ間視差予測と呼ばれる。JMVDCで非IDR／非アンカーピクチャを符号化するために、インター予測用深度動きベクトルは、それぞれのテクスチャ動きベクトルからレイヤ間動き予測を用いて予測されてもよい。これは図13に描かれている。
拡張レイヤマクロブロックに対するモード決定処理は、アンカーピクチャと非アンカーピクチャの両方で同一でもよい。モード決定処理に基本モードが追加されてもよく、基本レイヤで同位置のマクロブロックの動き／視差ベクトルが各拡張レイヤマクロブロックに対する動き／視差ベクトル予測器として選択されてもよい。
深度ビューを基本レイヤと見做し、それぞれのテクスチャビューを拡張レイヤと見做す構成でJMVDCツールが使用されてもよい。さらに、符号化および復号が前述以外の方法で行われてもよい。
インサイドビュー動き予測（inside-view motion prediction；IVMP）と呼ばれるコーディングツールが次のように動作してもよい。IVMPモードでは、テクスチャビュー成分における同位置のマクロブロックのmb_typeやsub_mb_type、参照インデクス、動きベクトルを含む動き情報は、同一ビューの深度ビュー成分で再利用されてもよい。各マクロブロックまたはマクロブロックパーティションにおいて、IVMPモードを使用するかどうかを示すフラグが伝達されてもよい。深度ビュー成分の空間分解能がテクスチャビュー成分のものと異なる場合、深度ビュー成分の動きベクトルは、テクスチャビュー成分における同位置のブロックまたはマクロブロックの動きベクトルとして用いられるとき、テクスチャビュー成分の空間分解能と深度ビュー成分の空間分解能の比に比例してスケールされてもよい。
インループビュー合成予測（View Synthesis Prediction；VSP）は次のように行われてもよい。深度マップ（d）から視差（D）への変換を行い、元ピクチャs(x,y)のピクセルを合成ターゲットイメージt(x+D,y)における新しいピクセル位置にマッピングすることで、ビュー合成が実装されてもよい。
Figure 2015518338
テクスチャピクチャの投影の場合、s(x,y)はテクスチャイメージのサンプルであり、d(s(x,y))はs(x,y)に関連する深度マップの値である。
合成に用いられるリファレンスフレームが4:2:0の場合、色差成分は、例えば次のようなサンプル値を繰り返して4:4:4までアップアンプリングされてもよい：
Figure 2015518338
ここで、s'chroma(・,・)はフル解像度での色差サンプル値であり、schroma(・,・) は半解像度での色差サンプル値である。
深度マップ値の投影の場合、s(x,y)=d(x,y)であり、このサンプルはそれ自身の値d(s(x,y))= d(x,y)を用いて投影される。
合成フレームをワーピング（warping）およびダウンサンプリングして元の解像度に戻す前に、リファレンスフレームについてアップサンプリングすることで、サブピクセル精度でワーピングが行われてもよい。
ビュー合成処理は前方ワーピング（forward warping）および穴埋め（hole filling）の2つの概念ステップを含んでもよい。前方ワーピングでは、リファレンスイメージの各ピクセルが合成イメージにマッピングされる。リファレンスフレームからの複数のピクセルが合成ビューにおける同一のサンプル位置にマッピングされる場合、このマッピング競合では深度値が大きい方（カメラに近い方）のピクセルが選択されてもよい。全ピクセルをワーピングした後、リファレンスフレームからマッピングされるサンプル値を持たない穴ピクセルが残る場合がある。こうした穴ピクセルは、例えばラインベースの指向性穴埋めで埋められてもよい。ここで「穴」とは、水平線上で2つの穴でないピクセルに間にある連続する穴ピクセルと定義される。穴ピクセルは、深度サンプル値が小さい（カメラから遠い）、隣接する穴でない2つのピクセルのうちの1つで埋められてもよい。
VSPから結果として得られる合成ピクチャは、例えば後続の時間的ビュー間リファレンスフレームに対して、最初のリファレンスピクチャ・リストList0およびList1に含められてもよい。しかし、リファレンスピクチャ・リスト修正シンタックス（RPLR命令等）はVSPリファレンスピクチャをサポートするように拡張されてもよい。こうして、エンコーダがリファレンスピクチャ・リストを任意の順序に並べられ、RPLRを用いて最終的な順序をビットストリームに示し、デコーダが同一の最終順序でリファレンスピクチャ・リストを再構成することができる。
符号化および復号の構成によっては、VSPがイントラ符号化やインター符号化、ビュー間符号化、その他の符号化のモードとは別のモードとして使用されてもよい。例えば、VSPスキップ／ダイレクトモードを用いるブロックに対して、動きベクトルの差がビットストリームに符号化されなくてもよいが、エンコーダおよびデコーダは、動きベクトルの差が0である、および／または動きベクトルが0であると推測してもよい。また、VSPスキップ／ダイレクトモードは、VSPスキップ／ダイレクトモードを用いるブロックに対して変換符号化残差ブロックが符号化されると推測してもよい。
深度ベース動きベクトル予測（Depth-based motion vector prediction；D-MVP）は、利用可能な深度マップデータを使用し、関連する深度マップのテクスチャデータの符号化／復号に対してそれを利用するコーディングツールである。このコーディングツールは、ビューのテクスチャビュー成分の前に符号化／復号される同一ビューの深度ビュー成分を必要としてもよい。D-MVPツールは、スキップモードおよびダイレクトモードに対して、方向分離MVPおよび深度ベースMV競合の2つのパートを含んでもよい。
方向分離MVPは次のように記述できる。全ての利用可能な隣接ブロックは、その予測（時間予測やビュー間予測、ビュー合成予測等）の方向に従って分類される。図15aを参照すると、現ブロックCbがビュー間リファレンスピクチャを使用する場合、ビュー間予測を利用しない全ての隣接ブロックは、MVPで利用不可とマークされ、H.264/AVCのMVPのように、従来の動きベクトル予測では考慮されない。同様に、現ブロックCbが時間予測を使用する場合、ビュー間リファレンスフレームを利用する隣接ブロックは、MVPで利用不可とマークされる。この処理のフローチャートは図14に描かれている。フローチャートと以下の説明は、時間予測およびビュー間予測の方向しか考慮しないが、他の予測方向も同様にカバーするよう拡張できる。こうした予測は例えば、ビュー合成予測や、時間予測およびビュー間予測の一方または両方の方向が、他の予測方向で同様に置き換えられる。
隣接ブロックから動きベクトル候補が利用できない場合、ビュー間予測に対するデフォルトの「ゼロMV」MVP (mvy=0, mvx=0)がmvy=0 および
Figure 2015518338
で置換されてもよい。
Figure 2015518338
は現テクスチャCbに関連する平均視差であり、次式で計算できる：
Figure 2015518338
ここで、i は現ブロックCb内のピクセルのインデクスであり、Nは現ブロックCbの総ピクセル数である。
スキップおよびダイレクトモードに対する深度ベースMV競合は、3DV-ATMを背景とした場合、次のように記述される。スキップモードおよびダイレクトモードで提案されている深度ベース動き競合（Depth-based Motion Competition；DMC）の処理のフローチャートは、それぞれ図16aおよび16bに示されている。スキップモードでは、テクスチャデータブロック{A, B, C}の動きベクトル{mvi}は、時間予測およびビュー間予測に対してそれぞれグループ1およびグループ2を形成する予測方向に従ってグループ化される。DMC処理は図16aの灰色ブロックで詳述され、各グループに対して独立で行われてもよい。
所定グループ内の各動きベクトルmviに対して、動き補償深度ブロックd(cb,mvi)が最初に導出されてもよい。ここで、動きベクトルmviは、mvi.で示されるリファレンス深度マップから深度ブロックを取得するために、d(cb)の位置に対して相対的に適用される。次に、d(cb) およびd(cb,mvi)の類似度が次式で見積もられる：
Figure 2015518338
現グループ内での絶対差の総和（sum of absolute differences；SAD）の最小値を与えるmviは、特定の方向（mvpdir）に対する最適予測因子として選択されてもよい。
Figure 2015518338
これに続いて、時間方向（mvptmp）の予測因子はビュー間方向（mvpinter）の予測因子と競わされる。最小SADを与える予測因子は次式によって得られる：
Figure 2015518338
最後に、別のビュー（ビュー間予測）を参照する
Figure 2015518338
が、次のサニティチェック（sanity check）を受けてもよい。「ゼロMV」が利用される場合、「視差MV」予測因子はmvy=0 および
Figure 2015518338
に置換される。
Figure 2015518338
は、前述のように導出されてもよい。
Bスライスのダイレクトモードに対するMVPは図16bに示され、スキップモードと同様でもよい。しかし、（灰色ブロックで示される）DMCは両方のリファレンスピクチャ・リスト（リスト0およびリスト1）で独立して行われてもよい。こうして、各予測方向（時間またはビュー間）に対して、DMCはリスト0およびリスト1用に2つの予測因子（mvp0dirおよびmvp1dir）をそれぞれ作成する。次に、mvp0dirおよびmvp1dirから導出される双方向補償ブロックが次のように計算されてもよい：
Figure 2015518338
この双方向補償ブロックとCbとの間のSAD値は、各方向に対して独立に計算されてもよい。ダイレクトモードに対してMVPは、スキップモードについて前述したように利用可能なmvpinterおよびmvptmpから選択されてもよい。スキップモードと同様に、各リファレンスリストの「ゼロMV」は、mvpoptが別のビュー（ビュー間予測）を表わす場合、「視差MV」で置換されてもよい。
マルチビュー符号化（multi-view coding；MVC）や深度拡張ビデオ符号化（depth-enhanced video coding）、マルチビュー＋深度（multiview+depth；MVD）符号化、インループビュー合成を用いたマルチビュー符号化（multi-view with in-loop view synthesis；MVC-VSP）のための、テクスチャビューに対する深度／視差ベースのイントラ予測は、次のように記述されてもよい。テクスチャの深度／視差ベースイントラ予測は、テクスチャデータの現ブロック（cb）に対する深度または視差情報（Di）の利用に基づく一連の新しいイントラ予測機構を含むように考慮されてもよい。テクスチャデータの現ブロック（cb）に対する深度または視差情報（Di）は、符号化された深度または視差情報の復号を介して利用可能であるか、現テクスチャブロックの復号前に復号側で推測可能であり、この情報がイントラ予測で利用されるものと仮定する。
以下では、テクスチャブロックは主としてテクスチャピクチャの単色成分サンプルのブロック、すなわち、テクスチャピクチャの輝度または色差成分のうちの1成分のサンプルのブロックを言及する。
エンコーダは、イントラ符号化テクスチャブロックを符号化する次の動作の1つ以上を備えてもよい。ここで、復号側でイントラ符号化テクスチャブロックを復号する場合にも同様の原理が適用可能であることに留意しなくてはならない。テクスチャに対する深度ベースイントラ予測は、深度を参照して記述されるが、深度の代わりに視差（disparity／parallax）も同様に用いられることを理解すべきである。以下の記述ではブロックという用語に言及するが、これは例えば、H.264/AVCで用いられるようなマクロブロックやHEVC-WDで用いられるようなツリーブロック、その他これに類するものでもよい。
深度境界検出
エンコーダは、次のような深度境界検出を適用してもよい。深度境界は、深度エッジや深度断絶、深度輪郭とも呼ばれる。エンコーダでは、関連する（再構成された／復号された）深度ブロックが深度境界を含むか含まないかで分類される。同一の深度境界検出アルゴリズムがデコーダで実行され、エンコーダとデコーダの両方が再構成／復号深度ピクチャに対して同じ深度境界検出を行ってもよい。検出された深度境界は、以下に記述された動作の1つ以上で使用されてもよい。
エンコーダおよびデコーダは、例えばエッジまたは境界検出アルゴリズムを用いて、ピクチャまたはブロック内に存在し得るエッジや他の境界の検出を試みてもよい。適用可能なアルゴリズムは多数存在する。例えば、深度境界分類は次のように行われてもよい。こうした分類は、勾配イメージGを得るために次のような3×3カーネルを用いるソーベル演算子（Sobel operator）を利用してもよい。
Figure 2015518338
ここで、Aは元のイメージ（再構成深度イメージ）である。
シーケンスはGのサンプル値に関して異なるダイナミックレンジを持ちうるため、ヒストグラム均一化を用いてGがイメージG'に変換されてもよい。ヒストグラム均一化では、G'の最小値および最大値はそれぞれ0および255に設定されてもよい。また、第1の閾値T1および第2の閾値T2が適切な値に設定されてもよい。エンコーダまたはデコーダは、G'(x, y) > T1であるかを調べてもよい。そうであれば、点(x, y)は境界点に分類される。現ブロックに対してヒストグラム均一化が行われた場合、ブロック内の境界点の数が第2の閾値T2を超えるかどうかを決定するために、現ブロックにおいて可能な境界点の数が調べられてもよい。ブロック内の境界点の数が第2の閾値T2を超えれば、このブロックは深度境界を含むと分類される。
エンコーダは、前述の閾値T1およびT2の何れかの値を、例えば、その閾値の別の値でブロックを符号化し、ラグランジュレート歪み最適化方程式（Lagrangian rate-distortion optimization equation）に従う最適な閾値を選択することに基づいて決定してもよい。エンコーダは、閾値T1および／またはT2の決定値をビットストリームに示してもよい。これは例えば、決定値をシーケンスパラメータセットやピクチャパラメータセット、スライスパラメータセット、ピクチャヘッダ等の1つ以上のシンタックス要素として、マクロブロックシンタックス構造やこれに類するものの中で符号化することで示してもよい。デコーダは、閾値T1および／またはT2の値を示す1つ以上のコードワードといった、ビットストリームに符号化されている情報に基づいて、閾値T1および／またはT2を決定してもよい。
テクスチャブロックは、深度境界を格納する、またはカバーする、含む、有する。あるいは、テクスチャブロックと同じ場所の深度ブロックが深度境界を格納する場合、テクスチャブロックは深度境界と一緒にあってもよい。深度は、テクスチャとは異なる空間分解能で符号化されてもよい。したがって、テクスチャブロックがどの時点で深度境界を含むまたはカバーするかの決定において、空間分解能に比例するスケーリングが考慮されてもよい。
深度ベースピクチャ分割（パーティショニング）
エンコーダは、深度情報に基づいてピクチャを分割してもよい。エンコーダは、ピクチャをビットストリームに分割するように符号化してもよい。あるいは、デコーダが深度情報に基づいてピクチャを分割してもよい。エンコーダおよびデコーダは、符号化／復号順序で特定のピクチャ分割が別のピクチャ分割のブロックより先になるように、ピクチャパーティショニングに従ってブロック符号化／復号順序を変更してもよい。
深度境界を含まないテクスチャブロックが最初にラスタースキャン順等で符号化または復号され、深度境界を含むテクスチャブロックが飛ばされた後で符号化または復号されるように、ブロック符号化順序と対応する復号順序が変更されてもよい。深度境界を含むテクスチャブロックは、符号化および／または復号において、深度境界を含まないブロックに対する予測には利用不可であるとマークされてもよい。
深度境界を含むテクスチャブロックが最初にラスタースキャン順等で符号化または復号され、深度境界を含まないテクスチャブロックは深度境界を含むテクスチャブロックの後、ラスタースキャン順等で符号化または復号されるように、ブロック符号化順序と対応する復号順序が変更されてもよい。深度境界を含まないテクスチャブロックは、符号化および／または復号において、深度境界を含むブロックに対する予測には利用不可であるとマークされてもよい。
深度ベースピクチャパーティショニングにおいて、エンコーダは、H.264/AVCの柔軟なマクロブロック順序であるslice_group_map_type 6を使用してもよい。これは、マクロブロックからスライスグループへのマクロブロック的なマッピングを可能にする。分類された深度エッジマクロブロック、すなわち特定のスライスグループに属する深度エッジを含まないと分類された全てのマクロブロックと、別のスライスグループに属する深度エッジを持つマクロブロックに基づいて、スライスグループの作成が行われてもよい。
エンコーダおよびデコーダは、再構成／復号深度ビュー成分の深度境界分類に基づいて、スライスグループのマッピングを推測してもよい。例えば、深度エッジを含まないと分類された全てのマクロブロックは特定のスライスグループに属し、深度エッジを持つマクロブロックは別のスライスグループに属する。
別の実施例では、同一の深度範囲にある全てのマクロブロックは、符号化および／または復号において特定のスライスグループを形成するように分類され、深度エッジを含むマクロブロックは、符号化および／または復号においてそれら自体のスライスグループを形成するように分類されてもよい。
深度境界を含むと分類されたマクロブロックを含むスライスグループは、他のスライスグループの後で符号化または復号されてもよい。あるいは、深度境界を含むと分類されたマクロブロックを含むスライスグループが、他のスライスグループより先に符号化または復号されてもよい。
マクロブロックはラスタースキャン順やその他所定の順序で符号化または復号される。あるいは、深度エッジを含むマクロブロックが飛ばされ、同じスライスの他の全てのマクロブロックの後で符号化または復号されてもよい。あるいはまた、深度エッジを含むマクロブロックが同じスライスの他の全てのマクロブロックより先に符号化または復号されてもよい。
深度ベースブロック分割（パーティショニング）
エンコーダは、深度情報に基づいてテクスチャブロックを分割してもよい。エンコーダは、特定のブロックパーティションの組が深度境界を含み、別のブロックパーティションの組が深度境界を含まないようにブロック分割を行ってもよい。エンコーダは、所定の基準を用いてブロックパーティションを選択してもよい。例えば、エンコーダは深度境界を含まないブロックのサイズが最大限となるように選択してもよい。デコーダも同様のブロック分割アルゴリズムを実行してもよい。あるいは、エンコーダが従来のH.264/AVCブロック分割シンタックス要素を使用しているといった、使用するブロック分割をデコーダに伝えてもよい。
イントラ符号化輝度テクスチャマクロブロックは、イントラ予測用に16×16や8×8、4×4に分割されてもよい。当然ながら、これら以外の適用可能なサイズでもよい。また、ブロックは正方形ブロックである必要はなく、他の形状も適用できる。一般的に、ブロックサイズは
Figure 2015518338
を用いてM×Nで表現できる。
深度ブロックのブロック分割は、個別のまたは同じ位置にあるテクスチャブロックに対するブロック分割として使用されてもよい。
ビットストリームで符号化されたり示されたりするブロック分割がなくてもよい。それ故、エンコーダおよびデコーダは同一の深度ベースブロック分割を行ってもよい。
ブロック分割に関する情報がエンコーダからデコーダに伝送される際には多様な選択肢が在りうる。例えば、ブロック分割に関する情報はビットストリームにエントロピー符号化されてもよい。ブロック分割のエントロピー符号化は様々な方法で行われてもよい。例えば、エンコーダがH.264/AVCブロック分割の（1または複数の）シンタックス要素を使用しているといった、使用されるブロック分割をデコーダに伝えてもよい。ブロック分割はビットストリームに符号化されてもよい。しかし、深度ベースブロック分割は、符号化方式のコンテキスト状態を変更するためにエンコーダとデコーダの両方で適用される。こうした符号化方式は、コンテキスト適応型二値算術符号化（context adaptive binary arithmetic coding；CABAC）やコンテキストベース可変長符号化（context-based variable length coding）、または、深度ベースブロック分割法で選択されたブロック分割が少ない符号化データビット数を使用する同種のエントロピー符号化である。実際には、深度ベースブロック分割の導入によって推定されるブロック分割の尤度は、エントロピー符号化および復号で増える。
ブロック分割はビットストリームに符号化されてもよいが、ブロック分割コードワードで用いられる符号化表または二値化表は、深度ベースブロック分割の結果に依存してもよい。
使用されたブロック分割方式は、例えばレート歪み最適化を通じてエンコーダにて選択されてもよく、符号化ビットストリームの1または複数のシンタックス要素やシンタックス要素値としてエンコーダにて示されてもよい。（1または複数の）シンタックス要素は、例えばシーケンスパラメータセットやピクチャパラメータセット、適応パラメータセット、ピクチャヘッダ、スライスヘッダ等にあってもよい。
エンコーダは例えば、レート歪み最適化等を用いて従来型ブロック分割の選択を行ってもよい。従来型ブロック分割におけるレート歪みコストが深度ベースブロック分割のそれよりも小さい場合、エンコーダは従来型ブロック分割を使用することを選択し、ビットストリームのスライスヘッダやマクロブロックシンタックス、ブロックシンタックス等に従来型ブロック分割を使用すると標示してもよい。
デコーダは、ブロック分割方式に関する（1または複数の）シンタックス要素を復号し、標示されたブロック分割方式および関連するシンタックス要素を用いてビットストリームを復号してもよい。
ブロック内のサブブロックまたはブロックパーティションの符号化順序または復号順序は、1または複数の深度境界に基づいて決定されてもよい。例えば、H.264/AVCベースの符号化または復号では、マクロブロック内のブロック分割に従うブロック符号化順序が、1または複数の深度境界に基づいて決定されてもよい。深度境界を持たないブロックは、深度境界を持つブロックよりも先に符号化または復号されてもよい。
例えば、H.264/AVCベースの符号化／復号方式で深度境界を含むテクスチャマクロブロックを符号化または復号するために、深度境界を含まない8×8ブロックが（存在する場合）最初に符号化または復号されてもよい。それに続いて、（深度境界を含む8×8ブロック内に存在する）深度境界を含まない4×4ブロックが符号化または復号されてもよい。最後に、深度境界を含む4×4ブロックが、双方向インター予測モード等を用いて符号化または復号されてもよい。
H.264/AVCベースの符号化／復号方式の別の実施例では、深度境界を含む4×4テクスチャブロックが最初に符号化または復号される。次に、テクスチャマクロブロックの残りのサンプルは、隣接するテクスチャマクロブロックの境界サンプルと、再構成／復号された、深度境界を含む4×4テクスチャブロックから予測される。
ブロック分割は、サブブロック位置での正規グリッド（regular grid）を用いて従来方式で行われる。例えばH.264/AVCでは、マクロブロックは、そのマクロブロック内の4×4正規グリッドで4×4またはそれより大きいブロックに分割されてもよい。テクスチャブロックのブロック分割は、サブブロック位置の座標の少なくとも1つがサブブロック位置の正規グリッドとは異なるように適用されてもよい。深度境界を持つサブブロックの選択において、例えば、垂直方向座標は4×4正規グリッドに合っているが、水平方向座標は、例えば深度境界を持つ4×4サブブロックの数を最小にするように選択される、というように深度境界を持つサブブロックが選択されてもよい。
テクスチャブロックのインター予測に使用されるブロック分割は、同一のテクスチャブロックの予測誤差符号化または復号に使用されるブロック分割とは異なっていてもよい。例えば、テクスチャブロックのインター予測用ブロック分割を決定するために、深度境界の検出に基づいて上記の何れかの方式が使用されてもよい。そして、変換符号化された予測誤差を符号化または復号するために、別のブロック分割が使用されてもよい。エンコーダおよび／またはデコーダは、同じ場所の若しくは個別の再構成深度や復号深度に基づいて、テクスチャのインター予測に用いられるブロック分割を推定してもよい。エンコーダは、イントラ符号化されたテクスチャブロックの予測誤差符号化用のブロック分割をビットストリームに符号化してもよい。そしてデコーダは、イントラ符号化されたテクスチャブロックの予測誤差復号に用いられるブロック分割をビットストリームから復号してもよい。エンコーダは、イントラ予測および予測誤差符号化／復号が同一のブロック分割を使用するか否かを選択するとき、例えばレート歪み最適化を用いてもよい。
深度ベースイントラ予測モードの決定
エンコーダおよび／またはデコーダは、深度情報を用いてイントラ予測モードを決定してもよい。符号化または復号される現テクスチャブロックの深度は、隣接するテクスチャブロックの深度や、隣接するテクスチャブロックと同じ場所または対応する深度ブロックの境界サンプルと比較されてもよい。そして、この比較に基づいて、現テクスチャブロックのイントラ予測モードが決定されてもよい。例えば、現テクスチャブロックの深度が境界サンプルの深度と比べて非常に小さい場合、DC予測が推定されてもよい。別の実施例では、現深度ブロックで深度境界が検出され、現テクスチャブロックに対して双方向イントラ予測が推定されてもよい。
イントラ予測モードはエンコーダおよびデコーダで推定されてもよいため、符号化されるシンタックス要素がなくてもよく、ビットレートを減らすことができる。使用される深度ベースイントラ予測モードの決定は、スライスヘッダ等で伝えられてもよい。そしてエンコーダは、深度ベースの予測モード決定と従来のイントラ予測モード決定を比較するレート歪み最適化決定法と、シンタックス要素符号化を用いて、深度ベースイントラ予測モードに入ってもよい。
深度ブロックのイントラ予測モードは、個別のまたは同じ位置にあるテクスチャブロックに対して（エンコーダおよびデコーダの両方で）使用されてもよい。
符号化または復号される現テクスチャブロックの深度は、隣接するテクスチャブロックの深度や、隣接するテクスチャブロックと同じ場所または対応する深度ブロックの境界サンプルと比較されてもよい。そして、この比較に基づいて、現テクスチャブロックのイントラ予測モードが決定されてもよい。例えば、現テクスチャブロックの深度が境界サンプルの深度と比べて非常に小さい場合、DC予測が推定されてもよく、従来型イントラ予測モードの伝達が推定されてもよい。別の実施例では、現深度ブロックで深度境界が検出され、現テクスチャブロックに対して双方向イントラ予測が推定されてもよい。
ブロック分割と同様に、イントラ予測モードのエントロピー符号化にも複数のオプションがあり、次のものを含む。双方向イントラ予測モードは、ブロック内に深度境界が存在するときに推定され、それ以外では従来型イントラ予測がそのブロックに用いられてもよい。ここで、エンコーダはイントラ予測モードを決定し、ビットストリームでそれを標示する。イントラ予測モードはエンコーダおよびデコーダの両方で推定されるため、符号化されるシンタックス要素はない。
別のオプションでは、イントラ予測モードはビットストリームに符号化されてもよい。しかし、イントラ予測モードの深度ベース予測は、符号化方式のコンテキスト状態を変更するためにエンコーダとデコーダの両方で適用される。こうした符号化方式は、CABACやコンテキストベース可変長符号化（context-based variable length coding）、または、深度ベースアルゴリズムで選択されたイントラ予測モードが少ない符号化データビット数を使用する同種のエントロピー符号化である。実際には、深度ベースアルゴリズムによって推定されるイントラ予測モードの尤度は、エントロピー符号化および復号で増えることがある。
また別のオプションでは、イントラ予測モードはビットストリームに符号化されてもよいが、イントラ予測モードのコードワードで用いられる符号化表または二値化表は、深度ベースアルゴリズムの結果に依存してもよい。
使用される深度ベースイントラ予測モードの決定は、スライスヘッダやマクロブロックシンタックス、ブロックシンタックス等で伝えられてもよい。そしてエンコーダは、深度ベースの予測モード決定と従来のイントラ予測モード決定を比較するレート歪み最適化決定法を用いて、深度ベースイントラ予測モードに入ってもよい。
エンコーダは例えば、レート歪み最適化等を用いて従来型イントラ予測モードの選択を行ってもよい。従来型イントラ予測におけるレート歪みコストが深度ベースイントラ予測モードの選択よりも小さい場合、エンコーダは従来型イントラ予測モードの使用を選択し、ビットストリームのスライスヘッダやマクロブロックシンタックス、ブロックシンタックス等に従来型イントラ予測の使用を標示してもよい。
デコーダは、イントラ予測モードに関する（1または複数の）シンタックス要素を復号し、標示されたイントラ予測モードおよび関連するシンタックス要素を用いてビットストリームを復号してもよい。
イントラ予測に対する深度ベースサンプルの利用可能性
エンコーダおよび／またはデコーダは、イントラ予測用サンプルが1つ以上存在するかを決定してもよい。予測されるサンプル（被予測サンプル）と同一の対象に属するようにエンコーダおよび／またはデコーダで分類されるサンプルのみが、予測元として使用されてもよい。同一対象への分類は、例えば深度サンプル値の比較を通じて行われてもよい。例えば、サンプルであって、深度サンプル値が同一対象に属する他のものと比べて互いに十分近いようなサンプルの位置のみを考慮することで、こうした分類が行われてもよい。
例示的実装では、エンコーダおよび／またはデコーダにおいて、テクスチャブロックに対するイントラ予測モードの決定だけでなく、イントラ符号化モードとマクロブロック分割の決定も、それぞれの深度ピクチャで独立に行われてもよい。ただし、イントラ予測に対するテクスチャサンプル情報の利用可能性は、利用可能な深度情報に応じて変更されてもよい。
深度境界を含むブロックに対する双方向イントラ予測
エンコーダおよびデコーダは、深度境界を含むテクスチャブロックに対して双方向イントラ予測を使用できる。双方向イントラ予測は、深度成分がテクスチャ成分より先に符号化および復号されるときにより高い効果をもたらす。このため、現ブロックに対して可能な全ての隣接ブロックの深度成分は、現ブロックのテクスチャ成分を符号化または復号するときに利用可能でもよい。
符号化または復号されるテクスチャブロックは、2つ以上の深度領域に分割されてもよい。隣接するテクスチャブロックの境界サンプルは、符号化および／または復号において等価な2つ以上の深度領域に分類されてもよい。符号化または復号されるブロックにおける特定の深度領域内のサンプルは次に、隣接ブロックの各境界サンプルからに限って予測されてもよい。領域毎に異なる予測方向またはイントラ予測モードが選択されてもよい。
深度境界を含むテクスチャブロックの双方向または多方向イントラ予測に関して、以下のステップの1つ以上が実行されてもよい。
（a）以下に規定される通常のイントラモードに加えて、双方向イントラ予測に対する新規イントラ予測モードが規定される。
（b）エンコーダは、この新規双方向イントラ予測モードを検証済モードの1つとして含めることにより、マクロブロック分割やツリーブロック分割等のブロック分割および使用される符号化モードをレート歪み最適化を通じて決定する。一般に、イントラ予測は双方向より多くすることができ、三方向イントラ予測等も可能である。一般に、nを正の整数としてn方向イントラ予測が可能である。
（c）テクスチャブロック（任意サイズで16×16や8×8、4×4等の形状）が深度境界を含む場合、隣接ブロックのブロック境界サンプルの利用可能性が決定されてもよい。ブロックまたはマクロブロックの符号化・復号順序は変更可能でもよい。そして被予測ブロックは、隣接ブロックにおける利用可能なブロック境界サンプルにより最大4辺まで囲われることになる。
（d）隣接するテクスチャブロックにおける利用可能なブロック境界サンプルが深度領域の異なる深度サンプルと同じ場所に在る場合、双方向イントラ予測モードがエンコーダおよび／またはデコーダで利用可能でもよい。
双方向イントラ予測モードの利用可能性は、エントロピー符号化の調整に用いられてもよい。これは例えば、CABACでは双方向イントラモードの確率を0に設定したり、双方向イントラ予測モードが利用できない場合にはコンテキスト適応型可変長符号化（context-adaptive variable-length coding）で双方向イントラモードを除外するコード表を選択したりすることで行われてもよい。
（e）エンコーダおよび／またはデコーダで、隣接ブロックにおける利用可能なブロック境界深度サンプル、および符号化されるテクスチャブロックと同じ位置に在る深度ブロックから最も突出した2つの深度領域が選択されてもよい。例えば、深度ブロックで最大サンプルを持つ2つの深度領域が選択され、その隣接ブロックにおけるブロック境界深度サンプルも利用可能になってもよい。
（f）深度ブロックの各サンプルは、この2つの最突出深度領域のうちの1つにマッピングされてもよい。例えば、深度領域の深度値の中央値または平均値に対する差の絶対値が小さい方にマッピングされてもよい。その結果、符号化されるテクスチャブロックの各サンプルは何れかの深度領域にマッピングされる。ここで、深度領域は深度領域0または深度領域1と表わす。
ステップeおよびfは、例えば次のように実行されてもよい。テクスチャブロックと同じ位置に在る再構成深度ブロックにおける最大値および最小値をそれぞれDmaxおよびDminとする。閾値をDThres = ( Dmax + Dmin) / 2とする。深度領域0のサンプルは深度がDThres以下である。深度領域1のサンプルは深度がDThresを超える。
深度領域は接触していると決定されてもよい。例えば、エンコーダおよびデコーダの両方でウェッジレット（Wedgelet）分割が使用されてもよい。ウェッジレット分割では、直線で分けられた2つの領域が定義される。この分割線は始点Sと終点Eで決まり、この両点はそれぞれブロックの異なる境界に位置する。分割線は直線の方程式で表現されてもよい。ウェッジレット分割の始点および終点は例えば、次のコスト関数を最小化することで決定されてもよい。SおよびPに対してそれぞれ別々の可能性が検証され、それぞれのコストが導出される。例えば、SおよびPに対する全ての可能な組合せが検証されてもよい。SおよびPの各組に対して、領域0および1の代表値が最初に決定される。例えば、領域0および1のそれぞれの深度サンプル値を平均することで決定されてもよい。次にコストが計算されてもよい。例えば、領域0および1の代表値に対する各深度サンプル値の差の絶対値の和を計算し、深度サンプルがSおよびPで分割された際の領域に依存して計算されてもよい。ウェッジレット分割に対するコストを最小にするSおよびPの値が選択される。
深度領域が接触していると決定されるが、直線で分けられる必要がないこともある。
（g）テクスチャブロックに関するイントラ予測は、深度領域0および深度領域1で別々に行われてもよい。深度領域0のイントラ予測では、深度領域1とは異なる方向が選択されてもよい。予測方向はエンコーダおよびデコーダの両方で推定されてもよい。あるいは、予測方向がエンコーダで決定され、ビットストリームで伝えられてもよい。後者の場合、2つの予測方向コードワードが符号化され、その一方は深度領域0用でもう一方は深度領域1用である。
イントラ予測へのサンプル利用可能性は、前述したような深度ベースであってもよい。同様の別の代替例では、領域0または領域1に対するイントラ予測に使用可能な隣接ブロックのサンプルに対して、その深度値を閾値DThresと比較することでサンプルを分類する。領域0に分類された隣接ブロックからのサンプルは、符号化または復号される現ブロックの領域0のサンプルの予測に用いられてもよい。そして、領域1に分類された隣接ブロックからのサンプルは、符号化または復号される現ブロックの領域0のサンプルの予測に用いられない。符号化または復号される現ブロックの領域1も同様に処理されてもよい。
ブロックまたはマクロブロックの符号化／復号順序は変更可能でもよい。そして被予測ブロックは、隣接ブロックにおける利用可能なブロック境界サンプルにより最大4辺まで囲われることになる。これにより、隣接ブロックで用いられるイントラ予測モードおよびブロック境界サンプルは、現在H.264/AVCやHEVC、その他同種の符号化または復号方式のシステムで用いられるものとは異なることもある。例えば、H.264/AVCイントラ予測モードは次のように変更されてもよい。
DCモードでは、領域0／1は、現ブロックを任意の方向から取り囲む、領域0／1内の隣接ブロックにおけるサンプルの平均値と設定される。
水平／垂直モードでは、現ブロックの両側からのブロックの境界サンプルが利用可能である場合、その境界サンプルは、被予測サンプルに対するユークリッド空間距離に従って重み付けされる。例えば、予測サンプルp1の水平座標がx1=7、予測サンプルp2の水平座標がx2=16、被予測サンプルの水平座標がx=10で、水平方向予測が用いられる場合、予測サンプルはm=(x2-x1)=9から次式の通りとなる： ((m-(x-x1))*p1 + (m-(x2-x))*p2) / m = ((9-(10-7))*p1 + (9-(16-10))*p2) / 9 = (6*p1 + 3*p2) / 9。境界サンプルが1つしか利用可能でないときは、それ自体が予測サンプルとして用いられる。利用可能な境界サンプルが無いときは、DC予測を通じて得られた値が利用されてもよい。
深度加重イントラ予測
エンコーダおよびデコーダは、イントラ予測で重み付けするために深度情報を使用してもよい。テクスチャのイントラ予測に対する深度ベース重みは分数値等、二値でない値でもよく、被予測テクスチャサンプルの深度と予測サンプルの深度との差に基づいてもよい。
1つのサンプルを予測するために複数のサンプルが予測用に使用されてもよい。また二値重みが用いられてもよい。すなわち、予測サンプルが被予測サンプルとして異なる深度領域に属すると分類される場合、重み0が用いられてもよい。あるいは、全ての予測サンプルに等しい重みが用いられてもよい。場合によっては、予測サンプルと被予測サンプルのユークリッド空間距離に基づいて、追加の倍数重みが決定されていてもよい。
深度ベース重みが分数値等の二値でない場合もある。こうした重みは、例えば次のように導出されてもよい。被予測サンプルの深度値をdと表わす。予測サンプルをpi、予測サンプルの深度値をdiと表わす。ここでiは予測サンプルのインデクスである。予測サンプルの深度は複数の深度サンプルから得られる値を含んでもよい。こうした値は例えば、被予測サンプルの深度と同じ深度領域に属すると分類される隣接深度ブロックの全ての境界サンプルの平均でもよい。Σabs(di-D)をSとする。ここで、Σはiが1からnまでの全ての値に対する和であり、nは予測サンプルの数である。各予測に対し、(S-Σabs(dj-D))/Sをwiとする。ここでΣは、jがiを除く1からnまでの全ての値に対する和である。予測サンプルpは、Σ(wi*pi)として得られる。ここでΣは、iが1からnまでの全ての値に対する和である。
多様なコーディングツールが 3DV-ATMといった特定のコーデックを背景として記述されてきたが、こうしたツールがHEVCの深度拡張マルチビュービデオ符号化拡張等その他のコーデック構成にも適用されうることに留意されたい。
テクスチャビューおよび深度ビューを符号化できるエンコーダ200の実施形態の高レベルフローチャートを図8に示し、テクスチャビューおよび深度ビューを復号できるデコーダ210を図9に示す。これらの図で、実線は一般的なデータフローを表わし、破線は制御情報信号を表わす。エンコーダ200は、テクスチャエンコーダ202で符号化されるテクスチャ成分201と深度エンコーダ204で符号化される深度マップ成分203を受取ってもよい。エンコーダ200がAVC/MVCに従ってテクスチャ成分を符号化中は、第1のスイッチ205がオフに切替えられてもよい。エンコーダ200が拡張テクスチャ成分を符号化中は、深度エンコーダ204が生成する情報がテクスチャエンコーダ202に提供されるように、第1のスイッチ205がオンに切替えられてもよい。この実施例のエンコーダは、次のように制御される第2のスイッチ206も備える。第2のスイッチ206は、エンコーダがAVC/MVCビューの深度情報を符号化中はオンに切替えられ、エンコーダが拡張テクスチャビューの深度情報を符号化中はオフに切替えられる。エンコーダ200は符号化ビデオ情報を含むビットストリーム207を出力してもよい。
デコーダ210は、少なくとも一部が逆順である以外は同様に動作してもよい。デコーダ210は符号化ビデオ情報を含むビットストリーム207を受信してもよい。デコーダ210は、テクスチャ情報を復号するテクスチャデコーダ211と深度情報を復号する深度デコーダ212を備える。第3のスイッチ213は深度デコーダ212からテクスチャデコーダ211への情報配信を制御するために提供されてもよく、第4のスイッチ214はテクスチャデコーダ211から深度デコーダ212への情報配信を制御するために提供されてもよい。デコーダ210がAVC/MVCテクスチャビューを復号する際は、第3のスイッチ213がオフに切替えられてもよく、デコーダ210が拡張テクスチャビューを復号する際は、第3のスイッチ213がオンに切替えられてもよい。デコーダ210がAVC/MVCテクスチャビューの深度を復号する際は、第4のスイッチ214がオンに切替えられてもよく、デコーダ210が拡張テクスチャビューの深度を復号する際は、第4のスイッチ214がオフに切替えられてもよい。デコーダ210は再構成テクスチャ成分215および再構成深度マップ成分216を出力してもよい。
多くのビデオエンコーダは、レート歪み最適符号化モード、例えば、希望マクロブロックモードと関連する動きベクトルを探索するために、ラグランジュコスト関数（Lagrangian cost function）を利用する。この種のコスト関数は、非可逆符号化法による正確なまたは推定された画像歪みと、画像領域のピクセル／サンプル値を表現するのに必要である正確なまたは推定された情報量を一緒に固定するために、加重ファクタまたはλを用いる。ラグランジュコスト関数は次式で表わすことができる：
C=D+λR
ここで、Cは最小化すべきラグランジュコスト、Dはこのモードと現在考慮される動きベクトルによる画像歪み（例えば、元の画像ブロックと符号化画像ブロックとの間のピクセル／サンプル値の平均二乗誤差）、λはラグランジュ係数、Rはデコーダで画像ブロックを再構成するために要求されるデータ（候補の動きベクトルを表わすためのデータ量を含む）を表わすのに必要なビット数である。
符号化規格は、サブビットストリーム抽出処理を含んでもよく、こうした処理はSVCやMVC、HEVC等で特定されている。サブビットストリーム抽出処理は、NALユニットを削除してビットストリームをサブビットストリームに変換することに関連する。サブビットストリームもまた、規格に準拠している。例えばHEVCドラフト規格では、選択された値以上のtemporal_idを持つ全てのVCL-NALユニットを除外し、それ以外の全てのVCL-NALユニットを含めることによって、生成されたビットストリームも準拠している。その結果、TIDと等しいtemporal_idを持つピクチャは、TIDを超えるtemporal_idを持つどのピクチャもインター予測リファレンスとして使用しない。
図1は例示的実施形態に従うビデオ符号化システムのブロック図を示す。このブロック図は、本発明の実施形態に従うコーデックを組込む例示的装置または例示的電子デバイス50の概略を示すブロック図として示されている。図2は、例示的実施形態に従う装置のレイアウトを示す。図1および2の各要素は以下で説明される。
電子デバイス50は例えば、移動端末や無線通信システムにおけるユーザ機器であってもよい。ただし、本発明の実施形態は、符号化および復号、またはビデオ画像の符号化や復号を要する任意の電子デバイスや装置に実装できることを理解されたい。
装置50は、デバイスを組込んで保護するハウジング30を備えてもよい。装置50はまた、液晶表示の形態でディスプレイ32を備えてもよい。本発明の他の実施形態では、ディスプレイは画像やビデオを表示するのに適した任意適当なディスプレイ技術によるものでもよい。装置50はまた、キーパッド34を備えてもよい。本発明の他の実施形態では、任意適当なデータインタフェースやユーザインタフェースの機構が用いられてもよい。例えば、ユーザインタフェースはタッチセンサ式ディスプレイに属する仮想キーボードやデータ入力システムとして実装されてもよい。装置はマイクロフォン36や、デジタルまたはアナログ信号の任意適当な音声入力を備えてもよい。装置50はまた、音声出力デバイスを備えてもよく、本発明の実施形態では次の何れか1つでもよい：イヤホン38，スピーカ，アナログ音声またはデジタル音声出力接続。装置50はまた、バッテリ40を備えてもよい（または、本発明の他の実施形態では、太陽電池や燃料電池，時計仕掛けの発電機などの任意適当な携帯エネルギー装置によって電源供給されてもよい）。装置はまた、他のデバイスと短可視距離通信するための赤外線ポート42を備えてもよい。他の実施形態では、装置50はさらに、ブルートゥース無線通信やUSB／FireWire有線接続などの任意適当な短距離通信ソリューションを備えてもよい。
装置50は、装置50を制御するコントローラ56またはプロセッサを備えてもよい。コントローラ56はメモリ58に接続されてもよい。本発明の実施形態では、メモリは、画像形態におけるデータと音声データの両方を格納してもよく、および／または、コントローラ56に実装される命令を格納してもよい。また、コントローラ56はコーデック回路54に接続されてもよい。コーデック回路は、音声および／またはビデオデータの符号化・復号の遂行や、コントローラ56が遂行する符号化・復号を補助するのに適している。
装置50はまた、カードリーダー48とスマートカード46を備えてもよい。例えば、ユーザ情報を提供し、ネットワークでユーザ認証および認可のための認証情報を提供するのに適したUICCおよびUICCリーダーを備えてもよい。
装置50は、コントローラに接続され、無線通信信号を生成するのに適した無線インタフェース回路52を備えてもよい。無線通信は例えば、携帯通信ネットワークや無線通信システム，無線ローカルエリアネットワークでの通信である。また、装置50は無線インタフェース回路52に接続されたアンテナ44を備えてもよい。アンテナは、無線インタフェース回路52で生成された無線信号を他の（1または複数の）装置へ送信し、無線信号を他の（1または複数の）装置から受信する。
本発明の実施形態によっては、装置50は個別のフレームを記録または検出できるカメラを備え、このフレームは処理用のコーデック54またはコントローラに渡される。本発明の実施形態によっては、装置は、別のデバイスから処理用ビデオ画像データを、送信および／または格納する前に受信してもよい。本発明の実施形態によっては、装置50は、符号化用／復号用画像を無線または有線の何れかで受信してもよい。
図3は、例示的実施形態に従う複数の装置，ネットワークおよびネットワーク要素を含むビデオ符号化構成を示す。図3では、本発明の実施形態において利用可能なシステムの実施例が示されている。システム10は、1つ以上のネットワークを通じて通信できる複数の通信デバイスを含む。システム10は任意の無線または有線ネットワークの組合せを含んでよく、無線携帯電話ネットワーク（GSM（登録商標）やUMTS，CDMAネットワーク等）やIEEE 802.xの何れかの規格で規定される無線ローカルエリアネットワーク（WLAN），ブルートゥース・パーソナルエリアネットワーク，イーサネット（登録商標）ローカルエリアネットワーク，トークンリング・ローカルエリアネットワーク，広域ネットワーク，インターネットを含んでもよい。ただし、これらに限定されない。
システム10は無線・有線両方の通信デバイスを含んでもよく、本発明の実施形態を実装するのに適した装置50を含んでもよい。例えば、図3に示すシステムは、携帯電話ネットワーク11とインターネット28を表わす表現を示している。インターネット28への接続は長距離無線接続や短距離無線接続，様々な有線接続を含んでもよいが、これらに限定されない。有線接続には電話回線やケーブル線，電力線，その他同様の通信線が含まれるが、これらに限定されない。
システム10に示される例示的通信デバイスは電子デバイスや装置50，携帯情報端末（PDA）16，PDAと携帯電話14の組合せ，統合通信デバイス（integrated messaging device; IMD）18，デスクトップコンピュータ20，ノート型コンピュータ22を含んでもよい。ただし、これらに限定されない。装置50は固定型でもよく、移動する人が持ち運べる携帯型でもよい。また、装置50は移動手段に配置されてもよい。こうした移動手段には自動車やトラック，タクシー，バス，列車，船／ボート，飛行機，自転車，バイク，その他同様の適切な移動手段が含まれるが、これらに限定されない。
さらに装置によっては、電話・メッセージの送受信に加え、基地局24への無線接続25を通じたサービスプロバイダとの通信が可能でもよい。基地局24は、携帯電話ネットワーク11とインターネット28間の通信を可能にするネットワークサーバ26に接続されてもよい。システムは、付加的な通信デバイスと様々な種類の通信デバイスを含んでもよい。
通信デバイスは様々な伝送技術を用いて通信してもよく、こうした技術には符号分割多元接続（CDMA）やGSM（登録商標），ユニバーサル携帯電話システム（UMTS），時分割多元接続（TDMA），周波数分割多元接続（FDMA），TCP-IP（transmission control protocol-internet protocol），ショートメッセージサービス（SMS），マルチメディアメッセージサービス（MMS），電子メール，IMS（instant messaging service），ブルートゥース， IEEE 802.11，その他類似の無線通信技術を含む。ただし、これらに限定されない。本発明の様々な実施形態への実装に含まれる通信デバイスは、様々な媒体を介して通信できる。こうした媒体として、無線，赤外線，レーザー，ケーブル接続，その他適切な接続が含まれるが、これらに限定されない。
図4aおよび4bは、例示的実施形態に従うビデオ符号化・復号のブロック図を示す。
図4aは、ピクセル予測器302と予測誤差エンコーダ303，予測誤差デコーダ304を備えるようなエンコーダを示す。図4aはまた、インター予測器306とイントラ予測器308，モードセレクタ310，フィルタ316，リファレンスフレームメモリ318を備えるようなピクセル予測器302の実施形態を示す。この実施形態では、モードセレクタ310はブロックプロセッサ381とコスト評価器382を備える。エンコーダはまた、ビットストリームのエントロピー符号化を行うエントロピーエンコーダ330を備えてもよい。
図4bはインター予測器306の実施形態を示す。インター予測器306は、1または複数のリファレンスフレームを選択するリファレンスフレームセレクタ360と動きベクトル定義器361，予測リスト作成器363，動きベクトルセレクタ364を備える。こうした構成要素またはその一部は、予測プロセッサ362の一部であってもよく、他の手段で実装されてもよい。
ピクセル予測器302は、インター予測器306とイントラ予測器308の両方で符号化される画像300を受信する（インター予測器306はこの画像と動き補償リファレンスフレーム318との間の差を決定し、イントラ予測器308は現フレームまたはピクチャで処理済みの部分のみに基づいて画像ブロックの予測を決定する）。インター予測器とイントラ予測器の両方からの出力はモードセレクタ310に送られる。インター予測器306とイントラ予測器308の両方とも、複数のイントラ予測モードを持っていてよい。したがって、インター予測とイントラ予測は各モードで遂行され、予測信号がモードセレクタ310に提供されてもよい。モードセレクタ310も画像300のコピーを受信する。
モードセレクタ310は現ブロックの符号化に使用する符号化モードの種類を決定する。モードセレクタ310は、インター予測モードの使用を決定すると、インター予測器306の出力をモードセレクタ310の出力に送る。モードセレクタ310は、イントラ予測モードの使用を決定すると、イントラ予測モードの1つに関する出力をモードセレクタ310の出力に送る。
モードセレクタ310は、符号化モードとそのパラメータ値を選択するために、コスト評価器ブロック382では例えばラグランジュコスト関数を用いてもよい。ここでパラメータ値とは、通常ブロックに基づく動きベクトルやリファレンスインデクス，イントラ予測の向き等である。この種のコスト関数は、非可逆符号化法による（正確なまたは推定された）画像歪みと、画像領域のピクセル／サンプル値を表現するのに必要である（正確なまたは推定された）情報量を一緒に固定するために、加重ファクタλを用いる。

C = D + λ × R

ここで、Cは最小化すべきラグランジュコスト、Dはこのモードとそのパラメータによる画像歪み（平均二乗誤差など）、Rはデコーダで画像ブロックを再構成するために要求されるデータ（候補の動きベクトルを表わすためのデータ量を含んでもよい）を表わすのに必要なビット数である。
モードセレクタの出力は第1の加算器321に送られる。第1の加算器は、予測誤差エンコーダ303への入力である第1の予測誤差信号320を生成するために、画像300からピクセル予測器302の出力を引いてもよい。
ピクセル予測器302はさらに、画像ブロック312の予測表現と予測誤差デコーダ304の出力338の合成を仮再構成器339から受取る。仮再構成器された画像314は、イントラ予測器308とフィルタ316に送られてもよい。仮表現を受取るフィルタ316は、その仮表現をフィルタリングし、リファレンスフレームメモリ318に保存される最終再構成画像340を出力する。リファレンスフレームメモリ318は、後の画像300がインター予測動作で比較されるためのリファレンス画像として使用されるように、インター予測器306に接続されてもよい。多くの実施形態では、リファレンスフレームメモリ318は複数の復号ピクチャを格納できる。そうした復号ピクチャの1つ以上は、後の画像300がインター予測動作で比較されるためのリファレンスピクチャとして、インター予測器306で使用されてもよい。場合によっては、リファレンスフレームメモリ318は復号ピクチャバッファとも呼ばれる。
ピクセル予測器302の動作は、本技術分野で周知のあらゆるピクセル予測アルゴリズムを遂行するように構成されてもよい。
ピクセル予測器302はまた、予測値をピクセル予測器302から出力する前にフィルタリングするフィルタ385を備えてもよい。
予測誤差エンコーダ302および予測誤差デコーダ304の動作は以降で詳述される。次の実施例では、エンコーダは、画像を16×16ピクセルのマクロブロック単位で生成する。こうした画像はフル画像またはピクチャを形成するようになる。ただし、図4aは16×16のブロックサイズに限定されるものではなく、任意のサイズおよび形状のブロックが一般に使用できることに留意されたい。同様に、図4aはピクチャのマクロブロック分割に限定されるものではなく、その他任意のピクチャ分割によって符号化単位として使用可能なブロックに分割されてもよいことにも留意されたい。したがって、以下の実施例に関して、ピクセル予測器302は16×16ピクセルサイズの予測マクロブロック列を出力し、第1の加算器321は、画像300の第1のマクロブロックと予測マクロブロック（ピクセル予測器302の出力）との間の差を表わす16×16ピクセルの残差データマクロブロック列を出力する。
予測誤差エンコーダ303は、変換ブロック342と量子化器344を備える。変換ブロック342は第1の予測誤差信号320を変換ドメインに変換する。この変換は例えば、DCT変換やその異型である。量子化器344は、量子化係数を得るために、DCT係数などの変換ドメイン信号を量子化する。
予測誤差デコーダ304は予測誤差エンコーダ303からの出力を受取り、復号予測誤差信号338を生成する。復号予測誤差信号は第2の加算器339で画像ブロック312の予測表現と合成され、仮再構成画像314を生成する。予測誤差デコーダは、近似的に変換信号を再構成するために、DCT係数などの量子化係数値を逆量子化（dequantize）する逆量子化器（dequantizer）346と、再構成された変換信号に対して逆変換を行う逆変換ブロック348を備えるように構成されてもよい。逆変換ブロック348の出力は、（1つまたは複数の）再構成ブロックを含む。予測誤差デコーダはまた、さらに復号された情報とフィルタパラメータに従って再構成マクロブロックをフィルタリングできるマクロブロックフィルタを備えてもよい（図示せず）。
次に、インター予測器306の例示的実施形態の動作を詳述する。インター予測器306はインター予測用に現ブロックを受取る。ここで現ブロックに対して、1つ以上の符号化済み隣接ブロックが既に存在し、それに関する動きベクトルも定義済みであると仮定する。例えば、現ブロックの左側のブロックおよび／または上側のブロックがそうしたブロックであってもよい。現ブロックに対する空間動きベクトルの予測は、例えば、同一スライスまたはフレームの符号化済み隣接ブロックおよび／または非隣接ブロックの動きベクトルを用いて行うことができる。または、空間動きベクトル予測の線形関数または非線型関数を用いたり、様々な空間動きベクトル予測器を線形動作または非線形動作で組合せたり、あるいは、時間リファレンス情報を使用しない任意適切な手段によって予測が行われてもよい。また、1つ以上の符号化ブロックの空間予測と時間予測の両方の情報を組合せて動きベクトル予測器を構成することも可能である。この種の動きベクトル予測器は、時空間（spatio-temporal）動きベクトル予測器とも呼ばれる。
符号化で使用されるリファレンスフレームはリファレンスフレームメモリに格納されてもよい。各リファレンスフレームは、1つ以上のリファレンスピクチャ・リストに含まれてもよい。リファレンスピクチャ・リスト内では、各エントリがリファレンスフレームを識別するリファレンスインデクスを持つ。リファレンスフレームは、リファレンスとしてもう使用されない場合、リファレンスフレームメモリから削除されてもよく、「リファレンスに未使用」とマークされたり、そのリファレンスフレームの格納位置が新規のリファレンスフレームによって占有されて非リファレンスフレームとなったりしてもよい。
前述の通り、アクセスユニットは別の成分タイプ（例えば、主テクスチャ成分や冗長テクスチャ成分，補助成分，深度／視差成分）や別のビュー，別のスケーラブルレイヤのスライスを含んでもよい。成分ピクチャは、依存表現やレイヤ表現、テクスチャビュー成分、深度ビュー成分、深度マップ、またそのようなものに対する集合名として定義されてもよい。複数の成分ピクチャは成分ピクチャ区切りNALユニットで互いに分けられ、成分ピクチャの符号化スライスの復号に使用される共通のシンタックス要素値を有してもよい。アクセスユニットは比較的多数の成分ピクチャで構成できる。これは、依存表現やレイヤ表現だけでなく符号化されたテクスチャ・深度ビュー成分等である。一部の成分ピクチャの符号化サイズは比較的小さいこともある。これは例えば、基本ビューや基本レイヤに対する差分を表現するものと見做されるためであったり、深度成分が比較的圧縮し易いためであったりすることが理由である。ビットストリームに成分ピクチャ区切りNALユニットが存在する場合、成分ピクチャは、成分ピクチャ区切りNALユニットと後続の複数の符号化スライスNALユニットとして定義されてもよい。ただし、後続の符号化スライスNALユニットは、アクセスユニットの最後または次の成分ピクチャ区切りNALユニットのうち復号順で早い方のユニットまでに続いている符号化スライスNALユニットであって、最後または次の区切りNALユニットは除く。
インター成分予測は、復号処理で用いられるシンタックス要素値やサンプル値、変数値、または特定のタイプの成分ピクチャから別のタイプの成分ピクチャまでのあらゆるものの予測を含むように定義されてもよい。例えば、インター成分予測は、深度ビュー成分からテクスチャビュー成分を予測すること、またはその逆を含んでもよい。
従来通りに、スライスヘッダに含まれていたシンタックス要素の少なくとも1つのサブセットがエンコーダによってGOS（スライス群）パラメータセットに含められることも提案されている。エンコーダはGOSパラメータセットをNALユニットとして符号化してもよい。GOSパラメータセットのNALユニットは、符号化スライスNALユニットなどと共にビットストリームに含まれてもよいが、前述した他のパラメータセットの場合と同様に帯域外で伝送されてもよい。
GOSパラメータセットのシンタックス構造は識別子を含み、例えば、スライスヘッダや別のGOSパラメータセットから特定のGOSパラメータセットインスタンスを参照する際に使用されてもよい。あるいは、GOSパラメータセットのシンタックス構造が識別子を含まず、エンコーダおよびデコーダの両方が、例えば、GOSパラメータセットのシンタックス構造に関するビットストリームの順序と既定の番号付けスキームを用いて識別子を推定してもよい。
エンコーダおよびデコーダは、符号化済みまたは復号済みであるか、ビットストリームに既存の他のシンタックス構造からGOSパラメータセットの内容やインスタンスを推定してもよい。例えば、ベースビューのテクスチャビューにおけるスライスヘッダからGOSパラメータセットが暗黙的に作成されてもよい。エンコーダおよびデコーダは、こうした推定GOSパラメータセットに対して識別値を推定してもよい。例えば、ベースビューのテクスチャビューにおけるスライスヘッダから作成されたGOSパラメータセットが0に等しい識別値を持つと推定されてもよい。
GOSパラメータセットはそれに関連する特定のアクセスユニット内で有効でもよい。例えば、GOSパラメータセットのシンタックス構造が特定のアクセスユニットに関するNALユニットシーケンスに含まれ、そのシーケンスは復号順またはビットストリームの順で、GOSパラメータセットはその出現位置からアクセスユニットの最後まで有効であってもよい。あるいは、GOSパラメータセットは様々なアクセスユニットで有効でもよい。
エンコーダは、1つのアクセスユニットに対して様々なGOSパラメータセットを符号化してもよい。スライスヘッダで符号化されるシンタックス要素の値の少なくとも1つのサブセットが後続のスライスヘッダと同一であることが分かっている場合、または予測／推定される場合、エンコーダはGOSパラメータセットを符号化すると決定してもよい。
GOSパラメータセット識別子には、限られた番号付けスペースが使用される。例えば、固定長符号が使用されたり、特定の範囲内の符号なし整数値として判断されたりしてもよい。エンコーダは、最初のGOSパラメータセットに対して特定のGOSパラメータセット識別値を使用してもよい。次に、最初のGOSパラメータセットが、例えば何れのスライスヘッダやGOSパラメータセットによっても参照されない場合には、2番目のGOSパラメータセットに対しても同じGOSパラメータセット識別値を使用してもよい。エンコーダは、例えば伝送エラーに対する高い頑健性を得るために、ビットストリーム内でGOSパラメータセットのシンタックス構造を繰り返してもよい。
GOSパラメータセットに含まれうるシンタックス構造は、概念的に複数のシンタックス要素のセットにまとめられてもよい。GOSパラメータセットのシンタックス要素セットは、例えば次の原則の1つ以上に基づいて形成されてもよい：
− スケーラブルレイヤおよび／または他のスケーラブル特性を示すシンタックス要素；
− ビューおよび／または他のマルチビュー特性を示すシンタックス要素；
− 深度／視差など特定の成分タイプに関連するシンタックス要素；
− アクセスユニット識別や復号順序および／または出力順序および／またはアクセスユニットの全スライスに対して不変である他のシンタックス要素に関連するシンタックス要素；
− ビュー成分の全スライスで不変であるシンタックス要素；
− リファレンスピクチャ・リスト変更に関連するシンタックス要素；
− 使用されるリファレンスピクチャのセットに関連するシンタックス要素；
− 復号リファレンスピクチャ・マーキングに関連するシンタックス要素；
− 加重予測用の予測重みテーブルに関連するシンタックス要素；
− デブロッキングフィルタリングを制御するシンタックス要素；
− 適応ループフィルタリングを制御するシンタックス要素；
− サンプル適応オフセットを制御するシンタックス要素；
− 上記セットの任意の組合せ。
各シンタックス要素セットに対して、エンコーダはGOSパラメータセットを符号化する際に次のオプションの1つ以上を持っていてもよい：
− シンタックス要素セットはGOSパラメータセットのシンタックス構造に符号化されてもよい。すなわち、シンタックス要素セットの符号化されたシンタックス要素の値は、GOSパラメータセットのシンタックス構造に含められてもよい。
− シンタックス要素セットは、参照によってGOSパラメータセットに含められてもよい。この参照は、識別子として別のGOSパラメータセットに与えられてもよい。エンコーダは、シンタックス要素セット毎に別々のリファレンスGOSパラメータセットを使用してもよい。
− シンタックス要素セットは、GOSパラメータセットに存在しないことが示されてもよく、推定されてもよい。
エンコーダがGOSパラメータセットを符号化する際、特定のシンタックス要素セットに対して選択可能なオプションは、そのシンタックス要素セットの種類に依存してもよい。例えば、スケーラブルレイヤに関連するシンタックス要素セットはGOSパラメータセットに常時存在してもよい。一方、ビュー成分の全スライスで不変なシンタックス要素のセットは、参照によって包含されるように利用可能ではなく、オプションとしてGOSパラメータセットに存在していてもよい。加えて、リファレンスピクチャ・リスト変更に関連するシンタックス要素は、参照によって含められるか、直接そのままで含められてもよく、あるいはGOSパラメータセットのシンタックス構造に存在しなくてもよい。エンコーダは、GOSパラメータセットのシンタックス構造などのビットストリームにあって、符号化に使用されたオプションの種類を示す標示を符号化してもよい。符号化テーブルおよび／またはエントロピー符号化は、シンタックス要素の種類に依存してもよい。デコーダは、復号されるシンタックス要素の種類に基づいて、エンコーダで使用された符号化テーブルおよび／またはエントロピー符号化に位置する符号化テーブルおよび／またはエントロピー復号を使用してもよい。
エンコーダは、シンタックス要素セットとそのシンタックス要素セットの値に対して元々使用されたGOSパラメータセットとの間の関連を示す複数の手段を備えていてもよい。例えば、エンコーダはシンタックス要素のループを符号化してもよい。こうしたループの各エントリは、参照として使用されたGOSパラメータセットの識別値を示し、参照GOPパラメータセットからコピーされるシンタックス要素セットを識別するシンタックス要素として符号化される。別の実施例では、エンコーダは複数のシンタックス要素でそれぞれがGOSパラメータセットを示すシンタックス要素を符号化してもよい。特定のシンタックス要素セットを含むループにおける最後のGOSパラメータセットは、エンコーダが現在ビットストリームに符号化しているときのGOSパラメータセットにあるシンタックス要素セットに対するリファレンスである。デコーダは、ビットストリームから符号化GOSパラメータセットを解析し、エンコーダと同一のGOSパラメータセットを再生するようにする。
適応パラメータセット（APS）NALユニットのサイズを減らし、APS-NALユニット伝達用ビットレートの低減を目的としたAPS用部分更新機構を持つことも提案されている。適応パラメータセット（APS）はスライスレベルで共通のピクチャ適応情報を共有する効果的な方法を提供するが、APSのパラメータが先行するAPSの1つ以上と比べて一部だけ変更している場合、APS-NALユニットを独立で符号化することが次善の方法となりうる。
グループパラメータセット（GPS）は、文献JCTVC-H0505（http://phenix.int-evry.fr/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-H0505-v2.zip）で提案された。GPSはパラメータセット識別子（ID）を集め、識別子自体を含む（自己参照）。具体的には、GPSはPPS-IDと0以上のAPS-IDを含む。復号処理中は任意の時点で最大1つのGPSがアクティブとなる。GPSがまだアクティブGPSでなく、復号される符号化スライスNALユニットで参照される場合、そのGPSはアクティブ化される。符号化スライスNALユニットはPPS-IDおよび1または複数のAPS-IDの代わりにGPS-IDを含んでもよい。
ビデオパラメータセット（VPS）は、文献JCTVC-H0388（http://phenix.int-evry.fr/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-H0388-v4.zip）で提案された。VPSとSPS、PPS間の関係および階層は次のように記述できる。VPSは、スケーラビリティおよび／または3DVの背景では、パラメータセット階層でSPSの1段上に位置する。VPSは、全ての（スケーラブルまたはビュー）レイヤに亘って全スライスに共通なパラメータを符号化ビデオシーケンス全体に含む。SPSは、特定の（スケーラブルまたはビュー）レイヤにおける全スライスに共通なパラメータを符号化ビデオシーケンス全体に含み、複数の（スケーラブルまたはビュー）レイヤで共有されてもよい。PPSは、特定のレイヤ表現（特定のアクセスユニットにおける特定のスケーラブルまたはビューレイヤの表現）における全スライスに共通なパラメータを含み、複数のレイヤ表現における全スライスで共有されるものである。VPSは、全ての（スケーラブルまたはビュー）レイヤに亘って全スライスに適用可能なその他多くの情報を符号化ビデオシーケンス全体に提供しうるが、さらにレイヤの依存表現に関する情報をビットストリームに提供してもよい。HEVCのスケーラブル拡張では、VPSは例えば、NALユニットヘッダから得られるLayerId値を1つ以上のスケーラビリティ次元の値にマッピングすることを含んでもよい。こうした値は例えば、SVCおよびMVCと同様に定義されるレイヤに関するdependency_id、quality_id、view_id、およびdepth_flagに対応してもよい。VPSは1つ以上のレイヤに関するプロファイルおよびレベル情報を含んでもよく、さらに、レイヤ表現の1つ以上の時間軸サブレイヤ（特定のtemporal_id値以下のVCL-NALユニットから成る）に関するプロファイルおよび／またはレベルを含んでもよい。VPSは次のようにアクティブ化されてもよい。VPSは同時に最大1つまでアクティブとなる。VPSがまだアクティブでなく、復号されるIDRアクセスユニットにおける特定のレイヤの符号化スライスNALユニットで参照される場合、そのVPSはアクティブ化される。VPSは一旦アクティブ化されると、符号化ビデオシーケンス全体に適用される。換言すれば、アクティブVPSは1つのIDRアクセスユニットに限って変更される。
3次元ビデオ符号化フォーマット・方式の中には、テクスチャビューが深度ビューとは異なるseq_parameter_set_3dvc_extensionや同種のパラメータセットを使わなくてはならないという基本制約がある場合もある。また、シングルビューまたは（深度拡張のない）マルチビュープロファイルと互換性のあるテクスチャビューは、深度拡張を利用するテクスチャビューとは異なるシーケンスパラメータセットを用いてもよい。符号化フォーマットおよび方式の中には、シーケンスパラメータセット識別子がリファレンスとしてピクチャパラメータセットに提供され、それにより必要なピクチャパラメータセットの数が、少なくともシーケンスパラメータセットの数と同じになるものもある。シーケンスパラメータセットおよびピクチャパラメータセットの主要部分は、各シンタックス要素に対して同じ値を共有してもよい。こうした3次元ビデオ符号化で用いるパラメータセットの数の削減は、圧縮性能の向上だけでなく、符号化、復号、および／または伝送を簡素化するのに有益となり得る。
3次元ビデオ符号化フォーマット・方式の中には、seq_parameter_set_3dvc_extensionまたは同種のパラメータセットが特定のコーディングツールのオン／オフを制御するものもある。例えば3DV-ATMでは、seq_parameter_set_3dvc_extensionがJVDFとスライスヘッダ予測、IVMP、VSPのオン／オフを制御してもよい。ただし、こうした多数のツールの利用可能性や使用は、アクセスユニット内のテクスチャ・深度ビュー成分の順序に依存してもよい。例えば、スライスヘッダ予測およびIVMPは、ビュー成分順序で各テクスチャビュー成分の後に続く深度ビューに対してのみ利用可能でもよい。ビュー合成のソースとして用いられるテクスチャビュー成分に対する深度ビュー成分が、VSPリファレンスが用いられるテクスチャビュー成分よりもビュー成分順序で先にある場合に限り、VSPが利用可能でもよい。
ビュー成分毎にそれぞれ異なるコーディングツール／方式／アルゴリズムが使用されてもよい。例えば、3DV-ATMビットストリームでは、ベースビューの深度ビュー成分はビュー成分順序で各テクスチャビュー成分の後に続き、スライスヘッダ予測およびIVMPを用いてもよい。ただし、非ベースビューの深度ビュー成分は各深度ビュー成分に先行することもあり、スライスヘッダ予測およびIVMPは利用できない。
例示的実施形態では、H.264/AVCやHEVCドラフト等で規定されているような算術演算子や論理演算子，関係演算子，二値演算子，代入演算子，範囲表記といった共通表記が用いられてもよい。また、H.264/AVCやHEVCドラフト等で規定されているような共通の数学的関数が用いられてもよい。演算の優先順位・実行順序に関する共通規則は、H.264/AVCやHEVCドラフト等で規定されているように使用されてもよい。
例示的実施形態では、各シンタックス要素の解析処理を規定するために、次の記述子が用いられる。
− b(8)：任意パターンのビット列を持つバイト（8ビット）。
− se(v)：左ビットを先頭とする符号付き整数型の指数ゴロム（Exp-Golomb）符号化シンタックス要素。
− u(n)：nビットの符号無し整数。シンタックステーブルでnが"v"であるときは、ビット数が他のシンタックス要素の値に依存して変化する。この記述子に対する解析処理は、最初に記述された最上位ビットを伴う符号無し整数の2進表現として解釈されたビットストリームから、次のnビットによって規定される。
− ue(v)：左ビットを先頭とする符号無し整数型のExp-Golomb符号化シンタックス要素。
Exp-Golombビット列は、例えば、次の表を用いて符号番号（codeNum）に変換されてもよい。
Figure 2015518338
Exp-Golombビット列に対応する符号番号は、例えば、次の表を用いてse(v)に変換されてもよい。
Figure 2015518338
例示的実施形態では、シンタックス構造とシンタックス要素の意味、復号処理は次のように規定されてもよい。ビットストリーム中のシンタックス要素は太字体で表わされる。各シンタックス要素はそれぞれの名前（下線文字を伴い全て小文字）で記述され、1または2のシンタックスカテゴリーが使用されたり、符号化表現方法として1または2の記述子が使用されたりすることもある。復号処理はシンタックス要素の値と先に復号済みのシンタックス要素の値に従って行われる。シンタックス要素の値は、シンタックステーブルまたはテキストで使用される際は通常の（太字でない）書式で表わされる。場合によっては、シンタックステーブルはシンタックス要素値から派生する他の変数の値を用いてもよい。こうした変数は、下線文字を伴わず小文字と大文字を用いてシンタックステーブルまたはテキストに表わされる。大文字で始まる変数は、現在のシンタックス構造とそれに従属する全てのシンタックス構造の復号用に生成される。大文字で始まる変数は、その変数の元のシンタックス構造を示さずに後のシンタックス構造用として復号処理に使用されてもよい。小文字で始まる変数は、その変数が生成されたコンテキスト内でも使用される。場合によっては、シンタックス要素値または変数値の数値と変換可能な「ニーモニック」名も使用される。「ニーモニック」名は数値とは無関係に使用されることもある。数値と名前の関連はテキストに規定されている。名前は下線文字で分けられた1つ以上の文字列で構成される。各文字列は大文字で始まり、途中で大文字を含んでもよい。
例示的実施形態では、シンタックス構造は次のように規定されてもよい。丸括弧内の一連の文は複文であり、機能的には単文として扱われる。"while"構文は、条件が真であるかどうかの判断を規定し、条件が真であれば、その条件が真でなくなるまで、単文（または複文）の評価を繰り返し指定する。"do…while"構文は、一旦文の評価を規定した後、条件が真であるかどうかの判断が続き、条件が真であれば、その条件が真でなくなるまで、文の評価を繰り返し指定する。"if…else"構文は、条件が真であるかどうかの判断を規定し、条件が真であれば最初の文の評価を指定し、そうでなければ、代替文の評価を指定する。この構文の"else"節と関連する代替文は、代替文の評価が不要であれば省略できる。"for"構文は、初期値文の評価を指定し、条件判断が続き、条件が真であれば、その条件が真でなくなるまで、最初の文と後に続く文の評価を繰り返し指定する。
種々の実施形態において、エンコーダは次のステップの中に1つ以上を実行してもよい。
１．テクスチャビューおよび深度ビューのビュー間予測階層を決定し、そのビュー間予測階層の標示をビットストリームに符号化すること。
２．アクセスユニット内のビュー成分順序を決定すること。この順序はAUビュー成分順序とも呼ばれる。
３．AUビュー成分順序の1つ以上の標示をビットストリームに符号化すること。
４．AUビュー成分順序に基づいて、1つ以上のコーディングツールの使用、コーディングツールのモード、および／または符号化パラメータを推定すること。
種々の実施形態において、デコーダは次のステップの中に1つ以上を実行してもよい。
１．テクスチャビューおよび深度ビューのビュー間予測階層の標示をビットストリームから受取り、復号すること。
２．AUビュー成分順序の1つ以上の標示をビットストリームから受取り、復号すること。
３．AUビュー成分順序に基づいて、復号処理で使用されるべき1つ以上のコーディングツールの使用、コーディングツールのモード、および／または符号化パラメータを推定すること。
テクスチャビューおよび深度ビューのビュー間予測階層の決定はエンコーダで行われ、例えば次のように行われてもよい。
実施形態によっては、エンコーダは、テクスチャビューおよび深度ビューに対して同一のビュー間依存順序を選択するように構成されてもよい。あるいは、または加えて、エンコーダは、同一のビュー間依存順序がレート歪み指標等の他のものよりも高い性能を持つ最適化処理を行ってもよい。
実施形態によっては、エンコーダは、テクスチャビューに関するビュー間依存順序を深度ビューから選択することもある。例えばエンコーダは、テクスチャビューおよび深度ビューに対して特定のビュー間依存順序を選択するように構成されてもよい。あるいは、または加えて、エンコーダは、テクスチャビューおよび深度ビューに対して特定のビュー間依存順序がレート歪み指標等の他のものよりも高い性能を持つ最適化処理を行ってもよい。
ビットストリームにおけるビュー間予測階層の符号化標示は、例えばビデオパラメータセットおよび／またはシーケンスパラメータセットの標示を符号化することで行われてもよい。その際、例えばシーケンスパラメータセットMVC拡張のシンタックスやこれに類するものを用いて行われてもよい。エンコーダは、パラメータセット標示子を符号化ビデオNALユニットに符号化することで、どのビデオパラメータセットまたはシーケンスパラメータセットが使用中であるかを示してもよい。こうして、符号化ビデオNALユニットは、ビュー間予測階層記述を含むパラメータセットをアクティブ化できる。
実施形態によっては、AUビュー成分順序とも呼ばれる、アクセスユニット内のビュー成分順序を決定することは、次のように行われてもよい。
アクセスユニット内のテクスチャおよび深度ビュー成分に関する符号化および復号順序は、符号化ビュー成分のデータが他の符号化ビュー成分によってインターリーブされないようになっていてもよく、アクセスユニット用データもビットストリームまたは復号順で他のアクセスユニットによってインターリーブされない。例えば、図7に示すように、別々のアクセスユニット（t, t+1, t+2）に2組のテクスチャ・深度ビュー（T0t, T1t, T0t+1, T1t+1, T0t+2, T1t+2, D0t, D1t, D0t+1, D1t+1, D0t+2, D1t+2）が存在してもよい。ここで、テクスチャ・深度ビュー成分（T0t,T1t, D0t,D1t）から成るアクセスユニットtは、ビットストリームおよび復号順でテクスチャ・深度ビュー成分（T0t+1,T1t+1, D0t+1,D1t+1）から成るアクセスユニットt+1よりも先である。
アクセスユニット内のビュー成分の符号化および復号順序は、符号化フォーマットに従ってもよく、エンコーダによって決定されてもよい。決定されたビュー間予測階層は、符号化および復号順序を制限してもよい。同一アクセスユニットのテクスチャビュー成分は、ビュー依存順序で符号化され、ビュー順序インデクスで示されてもよい。同様に、同一アクセスユニットの深度ビュー成分がビュー依存順序で符号化されてもよい。
テクスチャビュー成分は、同一ビューの関連する深度ビュー成分よりも先に符号化されてもよい。それ故、こうした深度ビュー成分が同一ビューの関連するテクスチャビュー成分から予測されてもよい。こうしたテクスチャビュー成分は例えば、MVCエンコーダで符号化され、MVCデコーダで復号されてもよい。拡張テクスチャビュー成分は本願では、同一ビューの関連する深度ビュー成分の後に符号化されるテクスチャビュー成分を表わす。したがって、関連する深度ビュー成分から予測されてもよい。例えば、深度ベース動きベクトル予測（depth-based motion vector prediction；D-MVP）は拡張テクスチャビュー成分で用いられてもよい。実施形態によっては、深度ビュー成分は、同一ビューの関連するテクスチャビュー成分よりも先に符号化されてもよい。それ故、こうしたテクスチャビュー成分が同一ビューの関連する深度ビュー成分から予測されてもよい。したがってエンコーダは、使用するよう決定した成分間予測ツールに基づいて、符号化とビットストリーム、同一ビューにおける深度ビュー成分およびテクスチャビュー成分の復号順序を選択してもよい。こうした決定は、例えば次の1つ以上に基づいてもよい：
− 符号化ビットストリームが、シングルビューまたはマルチビューのテクスチャビデオを復号できるデコーダと互換性を持つように望まれる場合、エンコーダは、選択された複数のテクスチャビューに対して深度ベーステクスチャコーディングツールを使用しないことと決定し、その結果、各深度ビューよりも先にテクスチャビューを符号化してもよい。
− エンコーダは、成分間コーディングツールとAUビュー成分順序がレート歪み指標等の他のものよりも高い性能を持つ最適化処理を行ってもよい。
− エンコーダは、AUビュー成分順序に制約を課す特定のコーディングツール、符号化モード、および／または符号化パラメータを使用するように構成されてもよく、使用すると決定してもよい。例えば、VSPが前述のように使用される場合、ビュー合成予測のリファレンスとして用いられるビューのテクスチャビュー成分と深度ビュー成分の両方は、符号化／復号され、かつ合成リファレンス成分が取出されるテクスチャビュー成分よりもAUビュー成分順序で先でなくてはならない。
実施形態によっては、成分間コーディングツールに加え、テクスチャビューおよび深度ビューのビュー間依存順序も合わせて、AUビュー成分順序の決定に影響を及ぼしてもよい。例えば、3つのビューが符号化され、エンコーダは、テクスチャビューT0、T1、T2（中央ビューはベースビューで他の2つのビューは非ベースビューである）に対してそれぞれPIPビュー間予測階層を用い、深度ビューD0、D1、D2（左側ビューはベースビューであり、右側ビューは左側ビューから予測されてもよく、中央ビューは左側ビューおよび／または右側ビューから予測されてもよい）に対してそれぞれIBPビュー間予測階層を用いると決定し、さらにエンコーダは、非ベースビューテクスチャ符号化にD-MVPコーディングツールまたはその他の深度ベーステクスチャコーディングツールを用いると決定し、テクスチャのベースビューには成分間予測ツールが使われない場合、エンコーダでは、AUビュー成分順序に対して次の制約が推定されてもよい。T1はD0、D1、D2とは独立して符号化されるため、これらに対して任意の順序を持つことができる。T0は復号前にD0を必要とし、同じく、T2は復号前にD2を必要とする。 D0とD2の復号サンプル値はそれぞれ、T0とT2を復号するためにD-MVPツールで使用されるためである。D1はT1（またはその他のテクスチャビュー）に対する成分間予測リファレンスとして使用されない。そのため、AUビュー成分順序におけるその位置は、深度のビュー間依存順序のみに支配される。その結果、可能なAUビュー成分順序は、例えば次の通りである：(T1, D0, D2, D1, T0, T2); (T1, D0, T0, D2, T2, D1); (T1, D0, D2, D1, T0, T2); (D0, D2, D1, T1, T0, T2)。
実施形態によっては、シーケンスパラメータセットMVC拡張は、深度ビュー成分の内容とテクスチャビュー成分の内容が同一である必要がなく、テクスチャビューに対するビュー間依存順序が深度ビューのそれと異なっていてもよい。
実施形態によっては、深度ビューは、テクスチャビューのアクティブなシーケンスパラメータセットとは異なるアクティブシーケンスパラメータセットを用いてもよい。また、特定の深度ビューが別の深度ビューとは異なるシーケンスパラメータセットを用いてもよい（すなわち、アクティブ化してもよい）。同様に、特定のテクスチャビューが別のテクスチャビューとは異なるシーケンスパラメータセットを用いてもよい（すなわち、アクティブ化してもよい）。
実施形態によっては、エンコーダは、例えば複数のプロセッサおよび／またはプロセッシングコアやグラフィック・プロセッシング・ユニット（GPU）、その他同様のものを通じて並列処理が可能であってもよい。エンコーダは、符号化するためにテクスチャおよび深度ビュー成分を別々の並列処理ユニットに割当ててもよい。例えば、ビュー間予測階層および成分間予測階層で決められた順序で行われ、成分間予測階層は例えば、使用される成分間予測ツールに従って決定されてもよい。符号化用にビュー成分を並列処理ユニットに割当てる際、エンコーダは、別の並列処理ユニットで符号化の完了を待つために中断される処理が無いことを保証しなくてはならない。ビュー成分の符号化が完了する順序は、それらビュー成分が符号化されるために別々の並列処理ユニットに割当てられた順序と同一である必要はない。例えば、符号化構成によっては、深度ビュー成分がテクスチャビュー成分よりも低い空間分解能を持つこともある。それ故、深度ビュー成分の符号化は、テクスチャビュー成分と比べて処理時間が少なくて済むこともある。並列処理ユニットは、符号化スライスまたはビュー成分をそれらが完了した順にビットストリームに出力するように構成されてもよい。その結果、実施形態によっては、AUビュー成分順序は1つ以上の並列処理ユニットでビュー成分の符号化が完了した順序により決定されてもよい。
種々の実施形態において、符号化フォーマットは、アクセスユニットのテクスチャおよび深度ビュー成分の持つ順序について、ビュー間予測階層および成分間予測階層の両方に従う限り、互いに任意の順序を許容する。換言すれば、受信ビットストリームを受取った順序で、例えばビットストリームでNALユニットを受取った順序で復号できるような制約を、多くの符号化フォーマットは持っている。つまり、受信ビュー成分は、ビットストリームで先に現われたデータに対して依存関係があってもよく、ビットストリームで後から現われるデータと依存関係を持つことは許容されないことになる。エンコーダは、ビュー成分をそれぞれの順序で符号化し、および／または符号化データをバッファに格納することで、ビットストリームでこうした制約に従うように保証してもよい。さらに、この制約に従ってバッファデータの順序を並び替え、ビットストリームに並べ直して書き出すことで保証してもよい。
実施形態によっては、AUビュー成分順序の1つ以上の標示をビットストリームに符号化することは、次の方法または他の同様の方法の何れかで実行されてもよい。
ビデオパラメータセットやシーケンスパラメータセット、またはそれに類するもののシンタックス構造が追加されてもよい。あるいは、AUビュー成分順序を記述するシンタックス要素を含むように、スケーラビリティやビュー、成分間の関係を示す新たなNALユニットタイプが規定されてもよい。例えば、次のシンタックスが例示的実施形態で使用されてもよい：
Figure 2015518338
前述のシンタックス要素の意味は次のように規定されてもよい。num_view_components（"num_view_components"は原文では太字であり、ビットストリームのシンタックス要素である）は、アクセスユニットに存在しうるテクスチャおよび深度ビュー成分の最大数を規定する。au_vc_order_depth_flag[ i ]（"au_vc_order_depth_flag"は原文では太字であり、ビットストリームのシンタックス要素である）は、0または1でありそれぞれ、アクセスユニット内における復号順序でi番目のビュー成分がテクスチャビュー成分であるか、深度ビュー成分であるかを規定する。au_vc_order_voidx[ i ] （"au_vc_order_voidx"は原文では太字であり、ビットストリームのシンタックス要素である）は、アクセスユニット内におけるテクスチャまたは深度ビュー成分の復号順序でのビュー順序インデクスを規定する。アクセスユニットに実際に存在するビュー成分の数はnum_view_components未満となりうるが、このときビュー成分の順序はこのシンタックスにおけるN個の第1のループアイテムと同じである。ここで、Nはアクセスユニットに実際に存在するビュー成分の数である。ビュー順序インデクスの代わりに、view_id等その他の識別子がこのシンタックスで使用されてもよい。
AUビュー成分順序がシーケンスパラメータセットに存在するか、同一の符号化ビデオに対して複数のインスタンスがアクティブ化されるその他のシンタックス要素に存在する場合、標示されるAUビュー成分順序はこうしたアクティブなシンタックス構造の全てで同一であると規定されてもよい。
実施形態によっては、シーケンスパラメータセットやその他同種のシンタックス構造は、AUビュー成分順序を標示する部分を含んでもよい。シンタックス構造が深度ビュー成分を表わす場合に限り、これが条件付きで適用される。例えば、3次元拡張シンタックス構造のシーケンスパラメータセットが規定されてもよい。深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す方法で、AUビュー成分順序がシンタックス構造に規定されてもよい。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。例えば、次のシンタックスまたはこれに類するものが使用されてもよい：
Figure 2015518338
前述のシンタックス要素の意味は次のように規定されてもよい。num_view_depth_components（"num_view_depth_components"は原文では太字であり、ビットストリームのシンタックス要素である）は、アクセスユニットに存在しうる深度ビュー成分の最大数を規定する。au_vc_order_texture_voidx[ i ] （"au_vc_order_texture_voidx"は原文では太字であり、ビットストリームのシンタックス要素である）は、AUビュー成分順序でビュー順序インデクスがiである深度ビュー成分に続くテクスチャビュー成分のビュー順序インデクスを規定する。テクスチャビュー成分のビュー順序インデクスも、アクセスユニット内でのそれぞれの復号順序を規定する。テクスチャビュー成分に対するau_vc_order_texture_voidx[ i ]の値がビュー順序インデクスの最大値を超える場合、ビュー順序インデクスがiである深度ビュー成分がAUビュー成分順序で最後のテクスチャビュー成分に続く。au_vc_order_texture_voidx[ i ]が値iを超える場合、それぞれの深度ビュー成分はAUビュー成分順序でビュー順序インデクスiの昇順である。
実施形態によっては、AUビュー成分順序は、例えばピクチャパラメータセットや適応パラメータセット、アクセスユニット区切りにおいてアクセスユニットのレベルで標示されてもよい。実施形態によっては、AUビュー成分順序は、GOSパラメータセットやピクチャヘッダ、成分ピクチャ区切り、成分ピクチャヘッダ、スライスヘッダ等アクセスユニットより下のレベルで標示されてもよい。そしてAUビュー成分順序は、同一アクセスユニットで有効な全てのシンタックス構造で同一であると規定されてもよい。AUビュー成分順序を標示するシンタックスは、前述したものと同様でもよい。
実施形態によっては、ビデオパラメータセットやシーケンスパラメータセット等のパラメータセットにおいて、前述したものと同様のシンタックスを用いる等して複数のAUビュー成分順序が規定されることもある。各順序は特定の識別子に関連付けられていてもよい。こうした識別子は例えば、0から始まる整数値で、パラメータセットで規定されるAUビュー成分順序に合わせて1ずつ増えるものでもよい。AUビュー成分順序識別値は、例えば符号化ビデオシーケンスやGOP、アクセスユニットに対してAUビュー成分順序が使用されることを示すために、それぞれ符号化ビデオシーケンスやGOP、アクセスユニットレベルに含められてもよい。AUビュー成分順序識別子は、ピクチャパラメータセットやGOSパラメータセット、アクセスユニット区切り、ピクチャヘッダ、成分ピクチャ区切り、成分ピクチャヘッダ、スライスヘッダ等に含められてもよい。AUビュー成分順序とその識別値は、同一アクセスユニットで有効な全てのシンタックス構造で同一であることが規定されてもよい。
実施形態によっては、別々のAUビュー成分順序がビットストリームに用いられ、その結果符号化および復号でも用いられることを許容するシンタックスと意味を使って、パラメータセットや前述したような他のシンタックス構造等にAUビュー成分順序が規定されることもある。例えば、AUビュー成分順序で特定のテクスチャビュー成分より先の深度ビュー成分を特定すること等を標示できる制約のリストまたは配列を用いて、AUビュー成分順序が規定されてもよい。制約リストまたは配列の項目は、制約の種類と関連する深度およびテクスチャ成分の標示を含んでもよい。例えば、制約の種類は、深度ビュー成分がAUビュー成分順序で特定のテクスチャビュー成分よりも前に現われなくてはならないことを示してもよい。さらに、深度ビュー成分（そのビュー順序インデクス値等）やテクスチャビュー成分のビュー順序インデクス値等の範囲やリストを含んでもよい。また例えば、ステレオ深度拡張ビットストリームでは、アクセスユニットで両方の深度ビュー成分（D0およびD1）が非ベーステクスチャビュー成分（T1）よりも先に現われることと規定されてもよい。この制約は、(D0, D1, T0, T1) および (T0, D0, D1, T1)という2つのAUビュー成分順序に適合し、またそれらを許容することになる。
実施形態によっては、AUビュー成分順序は、ビュー成分の順序がビットストリームに現われることで暗黙的に示されることもある。
デコーダは、テクスチャビューおよび深度ビューのビュー間予測階層の標示をビットストリームから受取り、復号してもよく、例えば次のように行ってもよい。デコーダは、例えば復号される1つ以上の符号化スライスシンタックス構造に含まれる1つ以上のパラメータセット識別子に基づいて、アクティブビデオパラメータセットや同様のもの、（1または複数の）アクティブなシーケンスパラメータセットや同様のもの、（1または複数の）アクティブピクチャパラメータセットや同様のもの、（1または複数の）アクティブ適応パラメータセットや同様のもののなかの1つ以上を決定してもよい。ビュー間予測階層がこうしたパラメータセット構造に存在してもよい。実施形態によっては、深度ビューのビュー間予測階層とは異なるテクスチャビューのビュー間予測階層を持つことが許容されることもある。その結果、デコーダは、ビュー間依存階層が復号されることで、テクスチャおよび深度ビューから別のパラメータセットまたはパラメータセットの別の部分が参照されると決定してもよい。実施形態によっては、テクスチャおよび深度ビューのビュー間予測階層がアクセスユニットおよび／または符号化スライスで標示されることもある。これは例えば、アクセスユニット区切りや成分ピクチャ区切り、スライスヘッダ、その他これに類するものに存在しうるビュー順序インデクスとして示され、デコーダは、例えばこのビュー順序インデクスのシンタックス要素や同様のものからビュー間予測階層情報を解析してもよい。実施形態によっては、ビュー間予測階層は、アクセスユニット内のテクスチャまたは深度ビュー成分の復号／ビットストリーム順序により暗黙的に示されることもある。
デコーダは、AUビュー成分順序の1つ以上の標示をビットストリームから受取り、復号してもよく、例えば次のように行ってもよい。AUビュー成分順序の標示は前述したものの何れかまたは同様の標示でもよい。デコーダは例えば、AUビュー成分順序を示すアクティブパラメータセットの中のどの部分がアクティブで復号されるパラメータセットであるかを決定してもよい。実施形態によっては、デコーダは、例えばピクチャパラメータセットから、使用すべきAUビュー成分順序のインデクスを復号し、そのインデクスを用いて、アクティブビデオパラメータセットに含まれるAUビュー成分順序やシーケンスパラメータのどの部分がピクチャパラメータセットを参照するアクセスユニットに対して使用されるかを決定してもよい。
実施形態によっては、デコーダは、伝送エラーや記憶媒体の大量破損、その他以下に記述するような事態に対するエラー回復のために、復号または決定されたAUビュー成分順序を用いることもある。デコーダは、例えば前のスライスのビュー順序インデクスおよび／または別のビュー成分タイプ（深度またはテクスチャ等）とは異なるインデクスおよび／またはタイプを示す成分ピクチャ区切りNALユニットや成分ピクチャヘッダ、スライスヘッダをビットストリームが含む場合、新たな／次のビュー成分の復号が開始されると決定してもよい。デコーダは、ビュー成分タイプおよびビュー順序インデクス等のビュー成分の識別子を、次のビュー成分に対してAUビュー成分順序が推定するものと比較してもよい。ビュー成分タイプおよびビュー成分の標示子の両方がAUビュー成分順序に基づいて予測されるものと一致する場合、デコーダはビュー成分全体の中で欠損が生じなかったと決定してもよい。ビュー成分タイプおよびビュー成分の標示子の何れかまたは両方がAUビュー成分順序に基づいて予測されるものと一致しない場合、デコーダはビュー成分全体の中での欠損を決定してもよい。実施形態によっては複数のAUビュー成分順序が可能なこともあり、そのためデコーダは、次のビュー成分が可能なAUビュー成分順序の何れかに適合するかを調べてもよい。実施形態によっては、デコーダへのビットストリーム入力に対してビットストリーム抽出または刈込（pruning）が行われていることもあるが、AUビュー成分順序の標示が刈込前にビットストリームに反映してもよい。例えば実施形態によっては、ビットストリームから全ての深度ビュー成分の削除が可能で、残りのビットストリームが検証される、すなわち復号されてもよい。実施形態によっては、デコーダは、例えば成分間コーディングツールが使用されたかどうかや、どのビューに対してそれが使用されたかまたはされうるかという標示に基づいて、ビュー成分の欠損が在るか／それが意図されうるものであるか、または意図されたものか／偶発的なものであるかを決定してもよい。最初のビュー成分が、別のビュー成分の符号化／復号に用いたコーディングツールに対して必須である、または必須となりうるとデコーダが決定する場合、デコーダは、最初のビュー成分の欠損が偶発的であると決定してもよい。
実施形態によっては、同じビューがテクスチャビュー成分および深度ビュー成分で表現され、各テクスチャビュー成分に対して深度ビュー成分が在り、両方ともその同じビューを表現していることもある。実施形態によっては、深度ビュー成分がテクスチャビュー成分よりも少なく、現在の深度ビュー成分が現テクスチャビュー成分の一部による表現と同じビューを表現することもある。
次の段落から、エンコーダおよび／またはデコーダでAUビュー成分順序に基づいて、1つ以上のコーディングツールの使用、コーディングツールのモード、および／または符号化パラメータを推定する例示的実施形態を示す。
実施形態によっては、ビューの深度ビュー成分がAUで同一ビューのテクスチャビュー成分よりも先である場合、基本レイヤの深度と拡張レイヤのテクスチャで深度からテクスチャの成分間依存を用いる1つ以上のコーディングツールが符号化および復号で使用されることもある。こうしたコーディングツールは、D-MVPやテクスチャの深度ベースイントラ予測、JMVDC等でもよい。実施形態によっては、ビューの深度ビュー成分がAUで同一ビューのテクスチャビュー成分よりも先である場合、基本レイヤの深度と拡張レイヤのテクスチャで深度からテクスチャの成分間依存を用いる1つ以上のコーディングツールの使用をエンコーダがビットストリームに標示し、一方ビューの深度ビュー成分がAUで同一ビューのテクスチャビュー成分に続く場合、深度からテクスチャの成分間依存を用いる1つ以上のコーディングツールの使用をエンコーダがビットストリームに標示しなくてもよい。こうしたコーディングツールは、D-MVPやテクスチャの深度ベースイントラ予測、JMVDC等でもよい。デコーダは、復号AUビュー成分順序から、D-MVP等深度からテクスチャの成分間依存を用いる1つ以上のコーディングツールの標示がビットストリームに存在するかを決定し、存在する場合、ビットストリームからそれを復号し、決定または復号された深度ベーステクスチャコーディングツールの使用に基づいて符号化ビデオデータを復号する。
実施形態によっては、ビューのテクスチャビュー成分がAUで同一ビューの深度ビュー成分よりも先である場合、JMVDC等、基本レイヤのテクスチャと拡張レイヤの深度でテクスチャから深度の成分間依存を用いる1つ以上のコーディングツールが符号化および復号で使用されることもある。実施形態によっては、ビューの深度ビュー成分がAUで同一ビューのテクスチャビュー成分に続く場合、JMVDC等、基本レイヤのテクスチャと拡張レイヤの深度でテクスチャから深度の成分間依存を用いる1つ以上のコーディングツールの使用をエンコーダがビットストリームに標示し、一方ビューの深度ビュー成分がAUで同一ビューのテクスチャビュー成分よりも先である場合、テクスチャから深度の成分間依存を用いる1つ以上のコーディングツールの使用をエンコーダがビットストリームに標示しなくてもよい。デコーダは、復号AUビュー成分順序から、テクスチャから深度の成分間依存を用いる1つ以上のコーディングツールの標示がビットストリームに存在するかを決定し、存在する場合、ビットストリームからそれを復号し、決定または復号されたテクスチャベース深度コーディングツールの使用に基づいて符号化ビデオデータを復号する。
実施形態によっては、エンコーダおよびデコーダは、AUビュー成分順序で連続する深度ビュー成分が少なくとも2つ存在する場合、こうしたAUビュー成分順序で連続する深度ビュー成分の最後の深度ビュー成分を再構成または復号した後、JVDF処理または他のマルチビュー深度フィルタリングが行われてもよい。AUビュー成分順序で連続する深度ビュー成分の最後までの再構成または復号された深度ビュー成分の全ては、JVDF処理または同様の処理に加えられてもよい。その結果、同じピクセルまたはサンプルの位置に投影またはワープされる深度サンプルの数は、深度ビュー成分が再構成または復号された後、その各々少ない数に対してJVDF処理または他のマルチビュー深度フィルタリングが適用された場合、その結果よりも多くてもよい。同じピクセル位置にマッピングされる深度サンプルの数が増えるほど、フィルタ処理が成功し易い。例えば、ピクセル位置にマッピングされる深度／視差値の多くがその深度／視差値の信頼区間に収まる場合、加重平均が適用され、その結果、深度／視差の外れ値が除外されてもよい。
実施形態によっては、エンコーダは、コーディングツールに関連するまたはツールで伝えられるビュー成分順序が満たされるとき、そのコーディングツールが用いられることをビットストリームの標示で示してもよい。そうでなければ、コーディングツールは使用されなくてもよい。換言すれば、特定のビュー成分がビットストリームに符号化され、アクセスユニット内で順序が先のビュー成分が特定のコーディングツールの使用を可能にし、そのコーディングツールの使用が標示によりオンにされる場合、エンコーダはその特定のビュー成分を符号化するためにそのコーディングツールを使用することができる。例えば、深度ビュー成分が符号化されるところで、その深度ビュー成分と同じビューの符号化されるべきテクスチャビュー成分が既に符号化済みであり、シーケンスパラメータセットや同様のものでIVMPが有効であった場合、エンコーダは現深度ビュー成分を符号化するのにIVMPを使用してもよい。デコーダは、エンコーダに合わせてコーディングツールの使用を決定してもよい。つまり、特定のビュー成分がビットストリームから復号されるところで、アクセスユニット内で順序が先のビュー成分が特定のコーディングツールの使用を可能にし、そのコーディングツールの使用がビットストリームに標示されている場合、デコーダはその特定のビュー成分を復号するためにそのコーディングツールを使用することができる。例えば、深度ビュー成分が復号されるところで、その深度ビュー成分と同じビューの復号されるべきテクスチャビュー成分が既に復号済みであり、シーケンスパラメータセットや同様のものでIVMPが有効であった場合、デコーダは現深度ビュー成分を復号するのにIVMPを使用してもよい。実施形態によっては、特定のコーディングツールが使用されるという、ビットストリームでの（1または複数の）標示は、特定の標示されたビュー成分や特定の標示されたビュー成分の組に固有であることもある。一方、特定のコーディングツールが使用されるという（1または複数の）標示は、標示されたビュー成分に対してそのコーディングツールに関連するまたはそのツールで伝えられるビュー成分順序が満たされるときに限り有効であってもよい。
次に、3DV-ATMに関連する例示的実施形態を説明する。3DV-ATMのNALユニットのシンタックスは次のように規定される。深度ビュー成分および3DVCテクスチャビュー成分の全ての符号化スライスがNALユニットタイプ21を使用してもよい。深度ビュー成分の符号化スライスは、3バイトのNALユニットヘッダMVC拡張または2バイトのNALユニットヘッダ3DVC拡張の何れかを用いてもよい。3DVCテクスチャビュー成分の符号化スライスは、2バイトのNALユニットヘッダ3DVC拡張を用いてもよい。NALユニットヘッダ3DVC拡張は、svc_extension_flagが1のときNALユニットタイプ21用に使用されると規定されてもよい。
Figure 2015518338
NALユニットヘッダ3DVC拡張は次のように規定されてもよい。view_idxは、NALユニットのビュー順序インデクスを規定してもよい。
Figure 2015518338
シーケンスパラメータセットのシンタックス（または具体的にsubset_seq_parameter_set_rbspシンタックス）は次のように規定されてもよい。profile_idcが138のときは、3次元ハイ構成に使用され、profile_idcが139のときは、3次元拡張ハイ構成に使用されてもよい。
Figure 2015518338
サブセットシーケンスパラメータセットRBSPは、全ての深度ビューとH.264/AVCのシングルビュープロファイルと互換性があるとマークされる必要のないテクスチャビュー成分に対して、同じサブセットシーケンスパラメータセットRBSPの使用を可能にしてもよい。例えば、テクスチャビュー成分との関連で、深度ビュー成分のビットストリーム／符号化順序が標示されてもよい。これにより、アクセスユニット内のテクスチャまたは深度ビュー成分のビュー成分（復号／ビットストリーム）順序を引出すことができる。テクスチャ（スライスヘッダ予測およびIVMP）に対してテクスチャベースのコーティングツールをオン／オフするフラグは、各テクスチャビューが先にある深度ビューにだけ適用してもよい。
seq_parameter_set_3dvc_extensionは次のように規定されてもよい：
Figure 2015518338
seq_parameter_set_3dvc_extensionのシンタックス要素の一部に関する意味は次のように規定されてもよい。
depth_info_present_flag（"depth_info_present_flag"は原文では太字であり、ビットストリームのシンタックス要素である）は0のとき、このサブセットシーケンスパラメータセットRBSPがアクティブである符号化ビデオシーケンスに深度ビュー成分が存在しないことを規定する。depth_info_present_flagは1のとき、このサブセットシーケンスパラメータセットRBSPがアクティブである符号化ビデオシーケンスに深度ビュー成分が存在することを規定する。
texture_voidx_delta[ i ]（"texture_voidx_delta"は原文では太字であり、ビットストリームのシンタックス要素である）は、テクスチャビュー成分と関連する深度ビュー成分の復号順序を規定する。変数ViewCompOrderDepthFlag[ idx ]およびViewCompOrderVOIdx[ idx ]は次のように規定される。
textureVOIdx = 0
depthVOIdx = 0
for( idx = 0; idx < (num_views_minus_1 + 1) * 2; ) {
for( idx2 = idx; idx2 < idx + texture_voidx_delta[ depthVOIdx ]; idx2++ ) {
ViewCompOrderDepthFlag[ idx2 ] = 0
ViewCompOrderVOIdx[ idx2 ] = textureVOIdx
textureVOIdx++
}
idx += texture_voidx_delta[ depthVOIdx ]
ViewCompOrderDepthFlag[ idx ] = 1
ViewCompOrderVOIdx[ idx ] = depthVOIdx
depthVOIdx++
idx++
}
texture_voidx_delta[ i ]は、次の制約条件が真であるような値を持つ。DepthFlagがViewCompOrderDepthFlag[ earlierIdx ]でありビュー順序インデクスがViewCompOrderVOIdx[ earlierIdx ]である任意のビュー成分が、DepthFlagがViewCompOrderDepthFlag[ laterIdx ]でビュー順序インデクスがViewCompOrderVOIdx[ laterIdx ]である任意のビュー成分より復号順序で先である。ただし、これら比較されるビュー成分は両方ともビットストリームに存在するときであって、earlierIdxは0以上num_views_minus1 * 2以下の任意の値、laterIdxはearlierIdx + 1以上num_views_minus1 * 2 +1以下の任意の値である。
関数ViewCompOrder( depthFlag, vOIdx )は、ViewCompOrderDepthFlag[ idx ]がdepthFlagに等しく、ViewCompOrderVOIdx[ idx ]がvOIdxに等しいときのidxの値を返すように規定される。
slice_header_prediction_idc（"slice_header_prediction_idc"は原文では太字であり、ビットストリームのシンタックス要素である）は0のとき、テクスチャビュー成分から深度ビュー成分へのスライスヘッダ予測、またその逆の予測が拒否されることを示す。slice_header_prediction_idcが1または2のとき、svc_extension_flagが1に等しく、ViewCompOrder( 0, vOIdx)がViewCompOrder( 1, vOIdx)よりも小さいときのビュー順序インデクスvOIdxを持つ深度ビュー成分に対して、その予測が使用されることを示す。
inside_view_mvp_flag（"inside_view_mvp_flag"は原文では太字であり、ビットストリームのシンタックス要素である）は1のとき、svc_extension_flagが1に等しく、ViewCompOrder( 0, vOIdx)がViewCompOrder( 1, vOIdx)よりも小さいときのビュー順序インデクスvOIdxを持つ深度ビュー成分に対して、ビュー内動き予測が有効であることを示す。inside_view_mvp_flagが0のとき、現在のシーケンスパラメータセットを参照する全てのビュー成分に対して、ビュー内動き予測が無効であることを示す。
スライスヘッダには、テクスチャビューおよび深度ビュー間の特定のビュー成分順序に依存するコーディングツールに関連する標示が、そのビュー成分順序がコーディングツールに適合するビュー成分に対してのみ存在してもよい。例えば3DV-ATMでは、スライスヘッダ予測機構は、NALユニットヘッダ3DVC拡張を使用し（svc_extension_flagが1である）、各テクスチャビュー成分が先行する深度ビュー成分に対してのみ利用可能でもよい。また、D-MVPツールの使用を示すdmvp_flagは、各深度ビュー成分が先行する3DVCテクスチャビュー成分に対してのみ存在してもよい。各スライスヘッダのシンタックスは次のように表せる。
Figure 2015518338
3DV-ATMでは、mb_ivmp_flagが存在する場合、変数IvmpEnabledFlagがmacroblock_layerシンタックスで制御するために使用されてもよい。mb_ivmp_flagは、IVMPが（macroblock_layerシンタックス構造によりその符号化形態に規定される）現マクロブロックに対して使用されるか否かを示してもよい。IvmpEnabledFlagの値の導出は次のように行われてもよい。IvmpEnabledFlagは、次の条件の全てが満たされるとき1に設定される：
− inside_view_mvp_flagが1である（ビュー内動き予測が有効である）；
− 現在のビュー成分が深度ビュー成分である；
− ViewCompOrder( 0, view_idx )がViewCompOrder( 1, view_idx )よりも小さい；
− svc_extension_flagが1である；
− 現在のピクチャが非アンカーピクチャであり、スライスタイプがIスライスまたはSIスライスでない。
これ以外ではIvmpEnabledFlagは0に設定される。
前述では、特定タイプのパラメータセットに関連して実施形態が説明されている。しかし、こうした実施形態は、ビットストリームにおける任意タイプのパラメータセットやその他のシンタックス構造を用いて実現されうることを理解する必要がある。
前述では、特定タイプの成分ピクチャ、すなわち深度ビュー成分およびテクスチャビュー成分に関連して実施形態が説明されている。しかし、こうした実施形態は、ビットストリームに存在しうる任意タイプの成分ピクチャを、テクスチャおよび深度ビュー成分の代替としてまたはこれに追加して実現されうることを理解する必要がある。例えば実施形態によっては、成分ピクチャは赤外線ビュー成分や、人が知覚可能なイメージを表現するのに用いられる従来の無線スペクトラムの範囲に入らない他のイメージ表現を含むこともできる。
前述では、深度ベーステクスチャ符号化／復号または予測ツール等、成分間依存を持つ符号化／復号の方法またはツールに関連して実施形態が説明されている。しかし、こうした実施形態は説明された符号化／復号方法に特化したものでなく、同様の符号化／復号の方法またはツールで実現されうることを理解する必要がある。
前述の例示的実施形態は、ビットストリームのシンタックスを用いて記述されていた。しかし、対応する構成および／またはコンピュータプログラムがビットストリームを生成するエンコーダおよび／またはビットストリームを復号するデコーダに存在できることも理解されるべきである。同様に、エンコーダを参照して例示的実施形態が記述されていたことに対して、結果として得られるビットストリームとデコーダに対応する要素が備わることも理解されるべきである。同様に、デコーダを参照して例示的実施形態が記述されていたことに対して、デコーダによって復号されるビットストリームを生成する構成および／またはコンピュータプログラムをエンコーダが備えることも理解されるべきである。
前述の実施例は電子デバイスのコーデックにおいて動作する本発明の実施形態を記述しているが、以下で記述されるように本発明が任意のビデオコーデックの一部として実装され得ることを理解されたい。したがって例えば、本発明の実施形態は、固定または有線の通信経路を通じてビデオ符号化を実装し得るビデオコーデックに実装されてもよい。
そしてユーザ装置は、前述の本発明の実施形態に記述されるこうしたビデオコーデックを備えてもよい。「ユーザ機器」との語句は、如何なる種類の無線ユーザ機器を表してもよく、例えば携帯電話やポータブルデータ処理装置、ポータブルＷｅｂブラウザであってもよい。
さらに、地上波公共移動通信ネットワーク（public land mobile network；PLMN）が、前述のビデオコーデックを含んでもよい。
一般に、様々な実施形態が、ハードウェアまたは特定用途向け回路、ソフトウェア、ロジック、またはそれらの組み合わせで実装されてもよい。例えば、ある場合ではハードウェアで実装されてもよく、一方別の場合では、コントローラやマイクロプロセッサ等のコンピュータデバイスによって実行されるファームウェアやソフトウェアで実装されてもよい。本発明の種々の形態はブロック図，フローチャート，または他の図的記述を使用して記述ないし図示される。これらのブロック，装置，システム，技術，またはここで記述される方法は、非限定的な例として、ハードウェア，ソフトウェア，ファームウェア，特定用途向け回路やロジック，汎用ハードウェア，コントローラや他のコンピュータデバイス，またはそれらの組み合わせで実装されてもよいと理解されるべきである。
そして本発明の実施形態は、移動デバイスのデータプロセッサによって実行可能なコンピュータソフトウェア，ハードウェア，またはソフトウェアとハードウェアの組合せによって実装されてもよい。またこの点に関して、添付する図面に示される論理フローの任意のブロックが、プログラムのステップや相互接続された論理回路・ブロック・機能、またはプログラムのステップ、論理回路・ブロック・機能の組合せを表現してもよいことに留意されたい。ソフトウェアは、メモリチップ等の物理メディアやプロセッサ内に実装されるメモリブロック，ハードディスクやフレキシブルディスク等の磁気メディア，DVDやそのデータ異形態であるCD等の光学式メディアに格納されてもよい。
本発明の様々な実施形態は、メモリに存在するコンピュータプログラムコードを用いて実装でき、関連する装置に本発明を遂行させられる。例えば、端末装置は、データの処理・送受信を行う回路および電子装置と、メモリにコンピュータプログラムコードと、プロセッサを備えてもよい。プロセッサは、コンピュータプログラムコードを実行すると、端末装置に本実施形態の構成を遂行させる。また更に、ネットワーク装置は、データの処理・送受信を行う回路および電子装置と、メモリにコンピュータプログラムコードと、プロセッサを備えてもよい。プロセッサは、コンピュータプログラムコードを実行すると、ネットワーク装置に本実施形態の構成を遂行させる。
メモリは、ローカルな技術環境に適したあらゆる種類のものであってよい。例えば、半導体ベースのメモリデバイス，磁気メモリデバイス・システム，光学式メモリデバイス・システム，固定式・移動式メモリ等の様々な適合するデータ格納技術を用いて実装されてもよい。-データプロセッサは、ローカルな技術環境に適したあらゆる種類のものであってよく、非限定的な例として、一つ以上の汎用コンピュータ，特定用途向けコンピュータ，マイクロプロセッサ，デジタル信号プロセッサ（DSP），マルチコアプロセッサ・アーキテクチャに基づくプロセッサを含んでもよい。--
本発明の実施形態は、集積回路モジュールのような、様々な要素で実施されることもできる集積回路の設計は多くは自動化されたプロセスである。論理レベルの設計を、半導体基板上にエッチング・形成するための半導体回路設計に変換する複雑で強力なソフトウェアツールが利用可能である。
カリフォルニア州マウンテンビューのSynopsys, Incや、カリフォルニア州サンノゼのCadence Designのような業者が提供するプログラムは、定評のある設計ルールと実績のある設計モジュールのライブラリに基づいて、半導体チップ上に導電経路や要素を配する。-半導体回路の設計が完了すると、それは、OpusやGDSII等の標準的な電子フォーマットの形で半導体製造設備または、いわゆるfabに送られる。
前述の説明は、本発明の非限定的な実施例を十分かつ詳細に記述している。しかし、こうした前述の説明を、添付する図面および特許請求の範囲と併せて考慮すれば、種々の変更および適応が可能であることは、本願に関連する技術分野の当業者には明らかであろう。さらに、本発明が教示するこうした事項の全ておよび同様の変形は、その全てが本発明の範囲内にある。
さらに、幾つかの実施例を以下に示す。
第1の実施例によれば、次の方法が提示され、この方法は：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を含む。
実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記適応させることは符号化のために次の：
・ 符号化ツールのセットから1つの符号化ツール；
・ 符号化モードのセットから1つの符号化モード；
・ 1つ以上の符号化パラメータ
の少なくとも1つの選択を含む。
実施形態によっては、前記ビュー成分順序がアクセスユニットレベルで標示される。
実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記ビュー成分順序が前記アクセスユニットレベルの下位レベルで標示される。
実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記順序に関する少なくとも1つの標示は、次の：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて符号化されてもよい。
実施形態によっては、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分が取得され、前記方法は更に、前記ビュー成分に対するビュー順序インデクスを規定することを含む。
実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記方法が、
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を規定することと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を符号化すること
を含む。
実施形態によっては、深度ビュー成分が、同じビューの各テクスチャビュー成分より先に符号化される。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記符号化を適応させることは：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
の少なくとも1つを含む。
実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記符号化を適応させることは：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を符号化することと；
・ 基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
の少なくとも1つを含む。
第2の実施例によれば、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置が提供される。前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサを用いて、前記装置に：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を遂行させる。
前記装置の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記装置の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に符号化のために次の：
・ 符号化ツールのセットから1つの符号化ツール；
・ 符号化モードのセットから1つの符号化モード；
・ 1つ以上の符号化パラメータ
の少なくとも1つを選択させる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、前記ビュー成分順序をアクセスユニットレベルに標示させる。
前記装置の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示させる。
前記装置の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記装置の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、次のこと：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて、前記順序に関する少なくとも1つの標示を符号化させる。
前記装置の実施形態によっては、前記少なくとも1つのメモリおよび前記メモリに格納されるコードは、前記少なくとも1つのプロセッサによって実行されると、前記装置に更に、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得させ、前記ビュー成分に対するビュー順序インデクスを規定させる。
前記装置の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を規定することと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を符号化すること
を遂行させる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、深度ビュー成分を同じビューの各テクスチャビュー成分より先に符号化させる。
前記装置の実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
の少なくとも1つを遂行させる。
前記装置の実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を符号化することと；
・ 基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
の少なくとも1つを遂行させる。
前記装置の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記装置は移動局の要素である。
第3の実施例によれば、1つ以上の命令の1つ以上のシーケンスを含むコンピュータプログラム製品が提供される。前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、装置に少なくとも次のこと：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得することと；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定することと；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させること
を遂行させる。
前記コンピュータプログラム製品の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記コンピュータプログラム製品の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、装置に少なくとも符号化のために次の：
・ 符号化ツールのセットから1つの符号化ツール；
・ 符号化モードのセットから1つの符号化モード；
・ 1つ以上の符号化パラメータ
の少なくとも1つを選択させる。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、装置に前記ビュー成分順序をアクセスユニットレベルに標示させる。
前記コンピュータプログラム製品の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、装置に前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示させる。
前記コンピュータプログラム製品の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記コンピュータプログラム製品の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて、前記順序に関する少なくとも1つの標示を符号化させる。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得させ、前記ビュー成分に対するビュー順序インデクスを規定させる。
前記コンピュータプログラム製品の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、装置に：
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を規定することと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を符号化すること
を遂行させる。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に深度ビュー成分を同じビューの各テクスチャビュー成分より先に符号化させる。
前記コンピュータプログラム製品の実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
の少なくとも1つを遂行させる。
前記コンピュータプログラム製品の実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を符号化することと；
・ 基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
の少なくとも1つを遂行させる。
前記コンピュータプログラム製品の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記コンピュータプログラム製品は移動局のソフトウェア要素である。
第4の実施例によれば、次の装置が提供され、この装置は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を取得する手段と；
・ アクセスユニットにおいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序を決定する手段と；
・ 前記ビュー成分順序に関する少なくとも1つの標示を符号化する手段と；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の符号化を適応させる手段
を備える。
前記装置の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記装置の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記装置は符号化のために次の：
・ 符号化ツールのセットから1つの符号化ツール；
・ 符号化モードのセットから1つの符号化モード；
・ 1つ以上の符号化パラメータ
の少なくとも1つを選択する手段を備える。
実施形態によっては、前記装置は前記ビュー成分順序をアクセスユニットレベルに標示する手段を備える。
前記装置の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記装置は前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示する手段を備える。
前記装置の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記装置の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記装置は：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて、前記順序に関する少なくとも1つの標示を符号化する手段を備える。
実施形態によっては、前記装置は、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得する手段と、前記方法は更に、前記ビュー成分に対するビュー順序インデクスを規定する手段を備える。
前記装置の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記方法は：
・ パラメータセットにビュー成分順序のセットを規定する手段と；
・ 前記パラメータセットの各ビュー成分に対して識別値を規定する手段と；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を符号化する手段
を備える。
実施形態によっては、前記装置が、深度ビュー成分を同じビューの各テクスチャビュー成分より先に符号化する手段を備える。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記装置は：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
の少なくとも1つを遂行する手段を備える。
実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記装置は：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を符号化することと；
・ 基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
の少なくとも1つを遂行する手段を備える。
前記装置の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記装置は移動局の要素である。
第5の実施例によれば、次の方法が提供され、この方法は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を含む。
実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記復号を適応させることは復号のために次の：
・ 復号ツールのセットから1つの復号ツール；
・ 復号モードのセットから1つの復号モード；
・ 1つ以上の復号パラメータ
の少なくとも1つを選択することを含む。
実施形態によっては、前記ビュー成分順序がアクセスユニットレベルで標示される。
実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記ビュー成分順序が前記アクセスユニットレベルの下位レベルで標示される。
実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記順序に関する少なくとも1つの標示は、次の：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて復号される。
実施形態によっては、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分が取得され、前記方法は更に、前記ビュー成分に対するビュー順序インデクスを復号することを含む。
実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記方法は：
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を受取ることと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を復号すること
を含む。
実施形態によっては、深度ビュー成分が、同じビューの各テクスチャビュー成分より先に復号される。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記復号を適応させることは：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを含む。
実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記復号を適応させることは：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を復号することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを含む。
実施形態によっては、前記方法は、アクセスユニットにおける前記テクスチャビュー成分および深度ビュー成分の順序を前記復号された標示に基づいて決定することを含む。
第6の実施例によれば、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置が提供される。前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサを用いて、前記装置に：
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を遂行させる。
前記装置の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記装置の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に復号のために次の：
・ 復号ツールのセットから1つの復号ツール；
・ 復号モードのセットから1つの復号モード；
・ 1つ以上の復号パラメータ
の少なくとも1つを選択させる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、前記ビュー成分順序をアクセスユニットレベルに標示させる。
前記装置の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示させる。
前記装置の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記装置の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、次のこと：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて前記順序の少なくとも1つの標示を復号させる。
前記装置の実施形態によっては、前記少なくとも1つのメモリおよび前記メモリに格納されるコードは、前記少なくとも1つのプロセッサによって実行されると、前記装置に更に、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得させ、前記ビュー成分に対するビュー順序インデクスを復号させる。
前記装置の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を受取ることと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を復号すること
を遂行させる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、深度ビュー成分を同じビューの各テクスチャビュー成分より先に復号させる。
前記装置の実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行させる。
前記装置の実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を復号することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行させる。
前記装置の実施形態によっては、前記コードを格納する少なくとも1つのメモリは、前記少なくとも1つのプロセッサによって実行されると前記装置に更に、アクセスユニットにおける前記テクスチャビュー成分および深度ビュー成分の順序を前記復号された標示に基づいて決定させる。
前記装置の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記装置は移動局の要素である。
第7の実施例によれば、1つ以上の命令の1つ以上のシーケンスを含むコンピュータプログラム製品が提供される。前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、装置に少なくとも、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取ることと；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取ることと；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号することと；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させること
を遂行させる。
前記コンピュータプログラム製品の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記コンピュータプログラム製品の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、前記装置に更に符号化のために次の：
・ 復号ツールのセットから1つの復号ツール；
・ 復号モードのセットから1つの復号モード；
・ 1つ以上の復号パラメータ
の少なくとも1つを選択させる。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、前記装置に更に前記ビュー成分順序をアクセスユニットレベルに標示させる。
前記コンピュータプログラム製品の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、前記装置に更に前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示させる。
前記コンピュータプログラム製品の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記コンピュータプログラム製品の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて前記順序の少なくとも1つの標示を復号させる。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得させ、前記ビュー成分に対するビュー順序インデクスを復号させる。
前記コンピュータプログラム製品の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記コンピュータプログラム製品は、1つ以上の命令の1つ以上のシーケンスであって、1つ以上のプロセッサによって実行されると、前記装置に更に：
・ パラメータセットにビュー成分順序のセットを規定することと；
・ 前記パラメータセットの各ビュー成分に対して識別値を受取ることと；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を復号すること
を遂行させる。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に深度ビュー成分を同じビューの各テクスチャビュー成分より先に復号させる。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行させる。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を復号することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行させる。
実施形態によっては、前記コンピュータプログラム製品は1つ以上の命令の1つ以上のシーケンスを含み、前記1つ以上の命令の1つ以上のシーケンスは、1つ以上のプロセッサによって実行されると、前記装置に更に、アクセスユニットにおける前記テクスチャビュー成分および深度ビュー成分の順序を前記復号された標示に基づいて決定させる。
前記コンピュータプログラム製品の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記コンピュータプログラム製品は移動局のソフトウェア要素である。
第8の実施例によれば、次の装置が提示され、この装置は、
・ ビューの第1のタイプの少なくとも1つのビュー成分および第2のタイプの少なくとも1つのビュー成分を受取る手段と；
・ 前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分のビュー成分順序に関する少なくとも1つの符号化された標示を受取る手段と；
・ 前記ビュー成分順序に関する少なくとも1つの符号化された標示を復号する手段と；
・ 前記ビュー成分順序に基づいて、前記第1のタイプの少なくとも1つのビュー成分および前記第2のタイプの少なくとも1つのビュー成分の一方または両方の復号を適応させる手段
を備える。
前記装置の実施形態によっては、前記第1のタイプはテクスチャビュー成分であり、前記第2のタイプは深度ビュー成分である。
前記装置の実施形態によっては、前記第1のタイプは赤外線ビュー成分である。
実施形態によっては、前記装置は符号化のために次の：
・ 復号ツールのセットから1つの復号ツール；
・ 復号モードのセットから1つの復号モード；
・ 1つ以上の復号パラメータ
の少なくとも1つを選択する手段を備える。
実施形態によっては、前記装置は前記ビュー成分順序をアクセスユニットレベルに標示する手段を備える。
前記装置の実施形態によっては、前記アクセスユニットレベルは次の：
・ ピクチャパラメータセット；
・ 適応パラメータセット；
・ アクセスユニット区切り
の1つである。
実施形態によっては、前記装置は前記ビュー成分順序をアクセスユニットレベルの下位レベルに標示する手段を備える。
前記装置の実施形態によっては、前記アクセスユニットレベルの下位レベルは次の：
・ スライス群パラメータセット；
・ ピクチャヘッダ；
・ 成分ピクチャ区切り；
・ 成分ピクチャヘッダ；
・ スライスヘッダ
の1つである。
前記装置の実施形態によっては、前記ビュー成分順序が同じアクセスユニットに対する全てのシンタックス構造で同一である。
実施形態によっては、前記装置は：
・ スライス群パラメータセットのシンタックス構造；
・ ビデオパラメータセット；
・ シーケンスパラメータセット
の少なくとも1つにおいて前記順序の少なくとも1つの標示を復号する手段を備える。
実施形態によっては、前記装置は、複数のビューに対して複数のテクスチャビュー成分および深度ビュー成分を取得する手段と、前記方法は更に、前記ビュー成分に対するビュー順序インデクスを復号する手段を備える。
前記装置の実施形態によっては、前記少なくとも1つの標示が、深度ビュー成分がテクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す。ここで、テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる。
実施形態によっては、前記方法は：
・ パラメータセットにビュー成分順序のセットを規定する手段と；
・ 前記パラメータセットの各ビュー成分に対して識別値を受取る手段と；
・ 前記選択されたビュー成分順序に対応するアクティブ識別値を復号する手段
を備える。
実施形態によっては、前記装置が、深度ビュー成分を同じビューの各テクスチャビュー成分より先に復号する手段を備える。
実施形態によっては、特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記装置は：
・ 前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する標示を符号化することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行する手段を備える。
実施形態によっては、特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記装置は：
・ 前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
・ 前記選択された符号化ツールに関する第2の標示を復号することと；
・ 基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
の少なくとも1つを遂行する手段を備える。
実施形態によっては、前記装置は、アクセスユニットにおける前記テクスチャビュー成分および深度ビュー成分の順序を前記復号された標示に基づいて決定する手段を備える。
前記装置の実施形態によっては、前記ビュー成分はマルチビュービデオに属する。
実施形態によっては、前記装置は移動局の要素である。

Claims (40)

  1. 第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を取得することと；
    アクセスユニットにおいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序を決定することと；
    前記ビュー成分順序に関する少なくとも１つの標示を符号化することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の符号化を適応させることであって、前記適応させることは符号化のために次の：
    符号化ツールのセットから１つの符号化ツール；
    符号化モードのセットから１つの符号化モード；
    １つ以上の符号化パラメータ
    の少なくとも１つを選択することを含む、前記適応させること
    を含む、方法。
  2. 前記ビュー成分順序に関する少なくとも１つの標示は、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つにおいて符号化される、請求項１に記載の方法。
  3. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項１または２に記載の方法。
  4. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記符号化を適応させることは：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する標示を符号化することと；
    基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
    の少なくとも１つを含む、請求項３に記載の方法。
  5. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記符号化を適応させることは：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する第２の標示を符号化することと；
    基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
    の少なくとも１つを含む、請求項３に記載の方法。
  6. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備える装置であって、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサと共に、前記装置に：
    第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を取得することと；
    アクセスユニットにおいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序を決定することと；
    前記ビュー成分順序に関する少なくとも１つの標示を符号化することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の符号化を適応させることであって、該適応させることは符号化のために次の：
    符号化ツールのセットから１つの符号化ツール；
    符号化モードのセットから１つの符号化モード；
    １つ以上の符号化パラメータ
    の少なくとも１つを選択することによる、前記適応させること
    を遂行させるように構成される、装置。
  7. 前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つにおいて、前記ビュー成分順序に関する少なくとも１つの標示を符号化させる、請求項６に記載の装置。
  8. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項６または７に記載の装置。
  9. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する標示を符号化することと；
    基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
    の少なくとも１つを遂行させる、請求項８に記載の装置。
  10. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する第２の標示を符号化することと；
    基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
    の少なくとも１つを遂行させる、請求項８に記載の装置。
  11. １つ以上の命令の１つ以上のシーケンスを含むコンピュータプログラム製品であって、１つ以上のプロセッサにより実行されると、装置に少なくとも次のこと：
    第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を取得することと；
    アクセスユニットにおいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序を決定することと；
    前記ビュー成分順序に関する少なくとも１つの標示を符号化することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の符号化を適応させることであって、該適応させることは符号化のために次の：
    符号化ツールのセットから１つの符号化ツール；
    符号化モードのセットから１つの符号化モード；
    １つ以上の符号化パラメータ
    の少なくとも１つの選択を含む、前記適応させること
    を遂行させる、コンピュータプログラム製品。
  12. 前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つにおいて、前記ビュー成分順序に関する少なくとも１つの標示を符号化させる、請求項１１に記載のコンピュータプログラム製品。
  13. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項１１または１２に記載のコンピュータプログラム製品。
  14. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する標示を符号化することと；
    基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
    の少なくとも１つを遂行させる、請求項１３に記載のコンピュータプログラム製品。
  15. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する第２の標示を符号化することと；
    基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
    の少なくとも１つを遂行させる、請求項１３に記載のコンピュータプログラム製品。
  16. 第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を取得する手段と；
    アクセスユニットにおいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序を決定する手段と；
    前記ビュー成分順序に関する少なくとも１つの標示を符号化する手段と；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の符号化を適応させる手段であって、前記適応させる手段は符号化のために次の：
    符号化ツールのセットから１つの符号化ツール；
    符号化モードのセットから１つの符号化モード；
    １つ以上の符号化パラメータ
    の少なくとも１つを選択する手段を含む、前記適応させる手段
    を備える、装置。
  17. 前記装置は、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つにおいて、前記ビュー成分順序に関する少なくとも１つの標示を符号化する手段を備える、請求項１６に記載の装置。
  18. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項１６または１７に記載の装置。
  19. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記符号化を適応させる手段は：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する標示を符号化することと；
    基本レイヤに前記深度ビュー成分を提供し、拡張レイヤに前記テクスチャビュー成分を提供すること
    の少なくとも１つを遂行する手段を備える、請求項１８に記載の装置。
  20. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記符号化を適応させる手段は：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる符号化ツールを選択することと；
    前記選択された符号化ツールに関する第２の標示を符号化することと；
    基本レイヤに前記テクスチャビュー成分を提供し、拡張レイヤに前記深度ビュー成分を提供すること
    の少なくとも１つを遂行させる手段を備える、請求項１８に記載の装置。
  21. 第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を受取ることと；
    前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序に関する少なくとも１つの符号化された標示を受取ることと；
    前記ビュー成分順序に関する少なくとも１つの符号化された標示を復号することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の復号を適応させることであって、前記適応させることは復号のために次の：
    復号ツールのセットから１つの復号ツール；
    復号モードのセットから１つの復号モード；
    １つ以上の復号パラメータ
    の少なくとも１つを選択することを含む、前記適応させること
    を含む、方法。
  22. 前記ビュー成分順序に関する少なくとも１つの標示は、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つにおいて復号される、請求項２１に記載の方法。
  23. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項２１または２２に記載の方法。
  24. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記復号を適応させることは：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する標示を符号化することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを含む、請求項２３に記載の方法。
  25. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記復号を適応させることは：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する第２の標示を復号することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを含む、請求項２３に記載の方法。
  26. 少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備える装置であって、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサと共に、前記装置に：
    第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を受取ることと；
    前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序に関する少なくとも１つの符号化された標示を受取ることと；
    前記ビュー成分順序に関する少なくとも１つの符号化された標示を復号することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の復号を適応させることであって、該適応させることは復号のために次の：
    復号ツールのセットから１つの復号ツール；
    復号モードのセットから１つの復号モード；
    １つ以上の復号パラメータ
    の少なくとも１つを選択することによる、前記適応させること
    を遂行させるように構成される、装置。
  27. 前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つから、前記ビュー成分順序に関する少なくとも１つの標示を復号させる、請求項２６に記載の装置。
  28. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項２６または２７に記載の装置。
  29. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する標示を符号化することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行させる、請求項２８に記載の装置。
  30. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する第２の標示を復号することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行させる、請求項２８に記載の装置。
  31. １つ以上の命令の１つ以上のシーケンスを含むコンピュータプログラム製品であって、１つ以上のプロセッサにより実行されると、装置に少なくとも次のこと：
    第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を受取ることと；
    前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序に関する少なくとも１つの符号化された標示を受取ることと；
    前記ビュー成分順序に関する少なくとも１つの符号化された標示を復号することと；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の復号を適応させることであって、該適応させることは復号のために次の：
    復号ツールのセットから１つの復号ツール；
    復号モードのセットから１つの復号モード；
    １つ以上の復号パラメータ
    の少なくとも１つの選択を含む、前記適応させること
    を遂行させる、コンピュータプログラム製品。
  32. 前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つから、前記ビュー成分順序に関する少なくとも１つの標示を復号させる、請求項３１に記載のコンピュータプログラム製品。
  33. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項３１または３２に記載のコンピュータプログラム製品。
  34. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する標示を符号化することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行させる、請求項３３に記載のコンピュータプログラム製品。
  35. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記コードを格納する少なくとも１つのメモリは、前記少なくとも１つのプロセッサによって実行されると前記装置に更に：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する第２の標示を復号することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行させる、請求項３３に記載のコンピュータプログラム製品。
  36. 第１のタイプの少なくとも１つのビュー成分および第２のタイプの少なくとも１つのビュー成分を受取る手段と；
    前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分のビュー成分順序に関する少なくとも１つの符号化された標示を受取る手段と；
    前記ビュー成分順序に関する少なくとも１つの符号化された標示を復号する手段と；
    前記ビュー成分順序に基づいて、前記第１のタイプの少なくとも１つのビュー成分および前記第２のタイプの少なくとも１つのビュー成分の一方または両方の復号を適応させる手段であって、前記適応させる手段は復号のために次の：
    復号ツールのセットから１つの復号ツール；
    復号モードのセットから１つの復号モード；
    １つ以上の復号パラメータ
    の少なくとも１つを選択する手段を含む、前記適応させる手段
    を備える、装置。
  37. 前記装置は、次のこと：
    スライス群パラメータセットのシンタックス構造；
    ビデオパラメータセット；
    シーケンスパラメータセット
    の少なくとも１つから、前記ビュー成分順序に関する少なくとも１つの標示を復号する手段を備える、請求項３６に記載の装置。
  38. 前記第２のタイプは深度ビュー成分であり、前記第１のタイプはテクスチャビュー成分であり、前記少なくとも１つの標示は、前記深度ビュー成分が前記テクスチャビュー成分と関連してどのように配置またはインターリーブされるかを示す、ただし、前記テクスチャビュー成分はそのビュー順序インデクスで決まる順序でアクセスユニットに現われる、請求項３６または３７に記載の装置。
  39. 特定のビューの深度ビュー成分は、前記ビュー成分順序で前記特定のビューのテクスチャビュー成分に先行し、前記装置は：
    前記深度ビュー成分から前記テクスチャビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する標示を符号化することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行する手段を備える、請求項３８に記載の装置。
  40. 特定のビューの深度ビュー成分は、アクセスユニットのビュー成分順序で前記特定のビューのテクスチャビュー成分に続き、前記装置は：
    前記テクスチャビュー成分から前記深度ビュー成分への成分間依存を用いる復号ツールを選択することと；
    前記選択された復号ツールに関する第２の標示を復号することと；
    基本レイヤで前記深度ビュー成分を受取り、拡張レイヤで前記テクスチャビュー成分を受取ること
    の少なくとも１つを遂行する手段を備える、請求項３８に記載の装置。
JP2015507569A 2012-04-25 2013-04-25 ビデオコーディング方法および装置 Expired - Fee Related JP5916266B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261637976P 2012-04-25 2012-04-25
US61/637,976 2012-04-25
PCT/FI2013/050466 WO2013160559A1 (en) 2012-04-25 2013-04-25 Method and apparatus for video coding

Publications (2)

Publication Number Publication Date
JP2015518338A true JP2015518338A (ja) 2015-06-25
JP5916266B2 JP5916266B2 (ja) 2016-05-11

Family

ID=49477257

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015507569A Expired - Fee Related JP5916266B2 (ja) 2012-04-25 2013-04-25 ビデオコーディング方法および装置

Country Status (9)

Country Link
US (1) US20130287093A1 (ja)
EP (1) EP2842329A4 (ja)
JP (1) JP5916266B2 (ja)
KR (1) KR101630564B1 (ja)
CN (1) CN104641642A (ja)
BR (1) BR112014026695A2 (ja)
CA (1) CA2871143A1 (ja)
SG (1) SG11201406920PA (ja)
WO (1) WO2013160559A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019124248A1 (ja) * 2017-12-21 2019-06-27 株式会社ソニー・インタラクティブエンタテインメント 画像処理装置、コンテンツ処理装置、コンテンツ処理システム、および画像処理方法
US10616584B2 (en) 2013-07-19 2020-04-07 Huawei Technologies Co., Ltd. Method and apparatus for encoding and decoding a texture block using depth based block partitioning
JP2021517423A (ja) * 2018-03-29 2021-07-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 双方向イントラ予測のシグナリング

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7983835B2 (en) 2004-11-03 2011-07-19 Lagassey Paul J Modular intelligent transportation system
US11496760B2 (en) 2011-07-22 2022-11-08 Qualcomm Incorporated Slice header prediction for depth maps in three-dimensional video codecs
US9521418B2 (en) 2011-07-22 2016-12-13 Qualcomm Incorporated Slice header three-dimensional video extension for slice header prediction
US9288505B2 (en) * 2011-08-11 2016-03-15 Qualcomm Incorporated Three-dimensional video with asymmetric spatial resolution
US9485503B2 (en) 2011-11-18 2016-11-01 Qualcomm Incorporated Inside view motion prediction among texture and depth view components
KR20130098122A (ko) * 2012-02-27 2013-09-04 세종대학교산학협력단 영상 부호화/복호화 장치 및 영상을 부호화/복호화하는 방법
WO2013129822A1 (ko) * 2012-02-27 2013-09-06 세종대학교산학협력단 영상 부호화와 복호화 장치 및 영상을 부호화와 복호화하는 방법
CA2878206C (en) * 2012-07-02 2016-05-17 Samsung Electronics Co., Ltd. Method and apparatus for encoding video and method and apparatus for decoding video determining inter-prediction reference picture list depending on block size
TWI637625B (zh) * 2012-08-29 2018-10-01 Ｖｉｄ衡器股份有限公司 可調整視訊編碼移動向量預測的方法及裝置
CN104662910B (zh) * 2012-09-21 2018-04-10 寰发股份有限公司 3d视频编码中的虚拟深度值的方法和装置
US9351005B2 (en) * 2012-09-24 2016-05-24 Qualcomm Incorporated Bitstream conformance test in video coding
US9992490B2 (en) 2012-09-26 2018-06-05 Sony Corporation Video parameter set (VPS) syntax re-ordering for easy access of extension parameters
JP2014082541A (ja) * 2012-10-12 2014-05-08 National Institute Of Information & Communication Technology 互いに類似した情報を含む複数画像のデータサイズを低減する方法、プログラムおよび装置
US9900609B2 (en) 2013-01-04 2018-02-20 Nokia Technologies Oy Apparatus, a method and a computer program for video coding and decoding
US9503723B2 (en) 2013-01-11 2016-11-22 Futurewei Technologies, Inc. Method and apparatus of depth prediction mode selection
US10129550B2 (en) 2013-02-01 2018-11-13 Qualcomm Incorporated Inter-layer syntax prediction control
WO2014166349A1 (en) * 2013-04-10 2014-10-16 Mediatek Inc. Method and apparatus of disparity vector derivation for three-dimensional and multi-view video coding
GB2540440A (en) * 2013-06-04 2017-01-18 Mitsubishi Electric Corp Image encoding device, image analysis device, image encoding method and image analysis method
US9288507B2 (en) * 2013-06-21 2016-03-15 Qualcomm Incorporated More accurate advanced residual prediction (ARP) for texture coding
GB2516222B (en) * 2013-07-02 2015-12-02 Canon Kk Intra video coding in error prone environments
WO2015005749A1 (ko) * 2013-07-12 2015-01-15 삼성전자 주식회사 인터 레이어 비디오 복호화 및 부호화 장치 및 방법을 위한 블록 기반 디스패리티 벡터 예측 방법
JP2016526853A (ja) * 2013-07-12 2016-09-05 サムスン エレクトロニクス カンパニー リミテッド 深さ基盤ディスパリティベクトルを利用するインターレイヤビデオ復号化方法及びその装置、並びに深さ基盤ディスパリティベクトルを利用するインターレイヤビデオ符号化方法及びその装置
US10075735B2 (en) * 2013-07-14 2018-09-11 Sharp Kabushiki Kaisha Video parameter set signaling
CA2909550C (en) * 2013-07-15 2018-04-24 Mediatek Singapore Pte. Ltd. Method of disparity derived depth coding in 3d video coding
US9906768B2 (en) * 2013-07-26 2018-02-27 Qualcomm Incorporated Use of a depth condition in 3DV codec
US9648333B2 (en) * 2013-10-11 2017-05-09 Vid Scale, Inc. High level syntax for HEVC extensions
WO2015103462A1 (en) * 2014-01-02 2015-07-09 Vidyo, Inc. Overlays using auxiliary pictures
MX360947B (es) 2014-01-03 2018-10-29 Arris Entpr Llc Sintaxis de extensión condicionalmente analizada para procesamiento de extensión hevc.
CN106256128B (zh) * 2014-01-03 2021-06-29 艾锐势有限责任公司 一种解码多个图片的方法
WO2015103747A1 (en) * 2014-01-08 2015-07-16 Mediatek Singapore Pte. Ltd. Motion parameter hole filling
US20150264404A1 (en) * 2014-03-17 2015-09-17 Nokia Technologies Oy Method and apparatus for video coding and decoding
CA2943121C (en) 2014-03-18 2020-09-08 Arris Enterprises Llc Scalable video coding using reference and scaled reference layer offsets
WO2015168581A1 (en) * 2014-05-01 2015-11-05 Arris Enterprises, Inc. Reference layer and scaled reference layer offsets for scalable video coding
CA2950749C (en) 2014-05-30 2019-02-19 Arris Enterprises Llc Reference layer offset parameters for inter-layer prediction in scalable video coding
US10063867B2 (en) * 2014-06-18 2018-08-28 Qualcomm Incorporated Signaling HRD parameters for bitstream partitions
US10506230B2 (en) * 2017-01-04 2019-12-10 Qualcomm Incorporated Modified adaptive loop filter temporal prediction for temporal scalability support
CN116193109A (zh) * 2017-01-16 2023-05-30 世宗大学校产学协力团 影像编码/解码方法
CN109005412B (zh) * 2017-06-06 2022-06-07 北京三星通信技术研究有限公司 运动矢量获取的方法及设备
WO2019039322A1 (en) * 2017-08-22 2019-02-28 Panasonic Intellectual Property Corporation Of America IMAGE ENCODER, IMAGE DECODER, IMAGE ENCODING METHOD, AND IMAGE DECODING METHOD
CN107623848B (zh) * 2017-09-04 2019-11-19 浙江大华技术股份有限公司 一种视频编码方法及装置
JP7145943B2 (ja) * 2017-10-04 2022-10-03 グーグル エルエルシー 単一のカメラを使用した深度の推定
WO2019073112A1 (en) * 2017-10-09 2019-04-18 Nokia Technologies Oy APPARATUS, METHOD, AND COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING
KR102362513B1 (ko) * 2017-12-04 2022-02-14 주식회사 케이티 타임 슬라이스 영상을 생성하는 서버, 방법 및 사용자 단말
EP3579553B1 (en) * 2018-06-05 2020-05-20 Axis AB A method, controller, and system for encoding a sequence of video frames
US10645380B2 (en) * 2018-07-09 2020-05-05 Tencent America LLC Method and apparatus for video coding
US11528509B2 (en) 2018-09-07 2022-12-13 Lg Electronics Inc. Video transmission method, video transmission device, video receiving method and video receiving device
BR112021013512A2 (pt) 2019-01-09 2021-09-14 Huawei Technologies Co., Ltd. Codificador de vídeo, decodificador de vídeo e métodos correspondentes
WO2020171647A1 (ko) * 2019-02-21 2020-08-27 엘지전자 주식회사 영상 코딩 시스템에서 인트라 예측을 사용하는 영상 디코딩 방법 및 그 장치
CN117499644A (zh) * 2019-03-14 2024-02-02 北京字节跳动网络技术有限公司 环路整形信息的信令和语法
MX2021015847A (es) * 2019-06-21 2022-02-03 Huawei Tech Co Ltd Derivacion de ponderacion de muestra croma para modo de particion geometrica.
US11303935B2 (en) * 2019-07-10 2022-04-12 Qualcomm Incorporated Deriving coding system operational configuration
EP4070552A1 (en) * 2019-12-05 2022-10-12 InterDigital VC Holdings France, SAS Intra sub partitions for video encoding and decoding combined with multiple transform selection, matrix weighted intra prediction or multi-reference-line intra prediction
KR20220114557A (ko) * 2019-12-26 2022-08-17 바이트댄스 아이엔씨 코딩된 픽처 내에서 디코딩 순서를 구현하기 위한 기술들

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010043773A1 (en) * 2008-10-17 2010-04-22 Nokia Corporation Sharing of motion vector in 3d video coding
JP2010514353A (ja) * 2006-12-21 2010-04-30 トムソン ライセンシング 多視点映像符号化及び復号化用の、ハイレベルシンタックスを使用した改善されたシグナリングのための方法及び装置
WO2010096189A1 (en) * 2009-02-19 2010-08-26 Thomson Licensing 3d video formats
WO2010126613A2 (en) * 2009-05-01 2010-11-04 Thomson Licensing Inter-layer dependency information for 3dv
JP2011509631A (ja) * 2008-01-11 2011-03-24 トムソン ライセンシング ビデオおよび奥行きの符号化
JP2011519226A (ja) * 2008-04-25 2011-06-30 トムソン ライセンシング 奥行きを用いた視点間スキップモード

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7671894B2 (en) * 2004-12-17 2010-03-02 Mitsubishi Electric Research Laboratories, Inc. Method and system for processing multiview videos for view synthesis using skip and direct modes
KR100763178B1 (ko) * 2005-03-04 2007-10-04 삼성전자주식회사 색 공간 스케일러블 비디오 코딩 및 디코딩 방법, 이를위한 장치
CN101292538B (zh) * 2005-10-19 2012-11-28 汤姆森特许公司 使用可缩放的视频编码的多视图视频编码
KR20110003549A (ko) * 2008-04-25 2011-01-12 톰슨 라이센싱 깊이 신호의 코딩
CN102055982B (zh) * 2011-01-13 2012-06-27 浙江大学 三维视频编解码方法及装置
US9565449B2 (en) * 2011-03-10 2017-02-07 Qualcomm Incorporated Coding multiview video plus depth content

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010514353A (ja) * 2006-12-21 2010-04-30 トムソン ライセンシング 多視点映像符号化及び復号化用の、ハイレベルシンタックスを使用した改善されたシグナリングのための方法及び装置
JP2011509631A (ja) * 2008-01-11 2011-03-24 トムソン ライセンシング ビデオおよび奥行きの符号化
JP2011519226A (ja) * 2008-04-25 2011-06-30 トムソン ライセンシング 奥行きを用いた視点間スキップモード
WO2010043773A1 (en) * 2008-10-17 2010-04-22 Nokia Corporation Sharing of motion vector in 3d video coding
WO2010096189A1 (en) * 2009-02-19 2010-08-26 Thomson Licensing 3d video formats
WO2010126613A2 (en) * 2009-05-01 2010-11-04 Thomson Licensing Inter-layer dependency information for 3dv

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JPN6016003657; Ｃｈｒｉｓｔｉａｎ Ｂａｒｔｎｉｋ ｅｔ．ａｌ．: 'ＨＥＶＣ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ Ｍｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ａｎｄ Ｍｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ ｐｌｕｓ Ｄｅｐｔｈ Ｃｏｄｉｎｇ' ＩＴＵ - Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ ＳＴＵＤＹ ＧＲＯＵＰ １６ Ｑｕｅｓｔｉｏｎ ６ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ＶＣＥＧ-ＡＲ１３, 201202, ｐｐ．１-４２, ４４ｎｄ Ｍｅｅｔｉｎｇ： Ｓａｎ Ｊｏｓｅ， ＣＡ， &#xFF3 *
JPN6016003663; Ｄｍｙｔｒｏ　Ｒｕｓａｎｏｖｓｋｙｙ　ｅｔ　ａｌ．: 'Ｓｕｇｇｅｓｔｉｏｎ　ｆｏｒ　ａ　ｄｅｐｔｈ-ｅｎｈａｎｃｅｄ　ｍｕｌｔｉｖｉｅｗ　ｖｉｄｅｏ　ｃｏｄｉｎｇ　ｅｘｔｅｎｓｉｏｎ　ｔｏ　Ｈ．２６４　Ａｎｎｅｘ　Ａ：　Ｎｏｋｉａ　３ＤＶ　Ｔｅｓｔ　Ｍｏ' ＩＴＵ　-　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ　Ｓｅｃｔｏｒ　ＳＴＵＤＹ　ＧＲＯＵＰ　１６　Ｑｕｅｓｔｉｏｎ　６　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ ＶＣＥＧ-ＡＲ１４-ＡｎｎｅｘＡ, 201202, ｐｐ．１-１４, ４ *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10616584B2 (en) 2013-07-19 2020-04-07 Huawei Technologies Co., Ltd. Method and apparatus for encoding and decoding a texture block using depth based block partitioning
US11234002B2 (en) 2013-07-19 2022-01-25 Huawei Technologies Co., Ltd. Method and apparatus for encoding and decoding a texture block using depth based block partitioning
WO2019124248A1 (ja) * 2017-12-21 2019-06-27 株式会社ソニー・インタラクティブエンタテインメント 画像処理装置、コンテンツ処理装置、コンテンツ処理システム、および画像処理方法
US11503267B2 (en) 2017-12-21 2022-11-15 Sony Interactive Entertainment Inc. Image processing device, content processing device, content processing system, and image processing method
JP2021517423A (ja) * 2018-03-29 2021-07-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 双方向イントラ予測のシグナリング
US11323695B2 (en) 2018-03-29 2022-05-03 Huawei Technologies Co., Ltd. Bidirectional intra prediction signaling
JP7086208B2 (ja) 2018-03-29 2022-06-17 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 双方向イントラ予測のシグナリング

Also Published As

Publication number Publication date
JP5916266B2 (ja) 2016-05-11
KR101630564B1 (ko) 2016-06-14
CN104641642A (zh) 2015-05-20
CA2871143A1 (en) 2013-10-31
EP2842329A1 (en) 2015-03-04
EP2842329A4 (en) 2016-01-06
BR112014026695A2 (pt) 2017-06-27
KR20150016256A (ko) 2015-02-11
WO2013160559A1 (en) 2013-10-31
SG11201406920PA (en) 2014-11-27
US20130287093A1 (en) 2013-10-31

Similar Documents

Publication Publication Date Title
JP5916266B2 (ja) ビデオコーディング方法および装置
JP6057395B2 (ja) ビデオ符号化方法および装置
US10397610B2 (en) Method and apparatus for video coding
JP6787667B2 (ja) ビデオコーディングのための方法と装置
JP6169273B2 (ja) ビデオ符号化・復号装置、方法及びコンピュータプログラム
KR101967398B1 (ko) 모션 정보를 시그널링하기 위한 구문을 수반하는 비디오 코딩을 위한 방법 및 장치
KR101658324B1 (ko) 비디오 코딩을 위한 방법 및 장치
KR101678321B1 (ko) 비디오 코딩을 위한 방법 및 장치
KR101662963B1 (ko) 3d 비디오 코딩을 위한 장치, 방법 및 컴퓨터 프로그램
US20140218473A1 (en) Method and apparatus for video coding and decoding
US20150245063A1 (en) Method and apparatus for video coding
US20140098883A1 (en) Method and apparatus for video coding
US20140092978A1 (en) Method and apparatus for video coding
US20140085415A1 (en) Method and apparatus for video coding
US20140003505A1 (en) Method and apparatus for video coding

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20151112

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151222

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160216

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160315

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160404

R150 Certificate of patent or registration of utility model

Ref document number: 5916266

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees