JP2014526193A

JP2014526193A - 内部ビュー動き予測（ｉｖｍｐ）モードをサポートするｍｖｃベースの３ｄｖｃコーデック

Info

Publication number: JP2014526193A
Application number: JP2014522912A
Authority: JP
Inventors: チェン、イン; ジャン、リ; カークゼウィックズ、マルタ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2011-07-22
Filing date: 2012-07-20
Publication date: 2014-10-02
Also published as: TW201320754A; CN103748882A; WO2013016231A1; RU2014106666A; EP2735152B1; CA2842569A1; HUE040195T2; JP6141386B2; JP2016067009A; US20130188013A1; BR112014001247A2; US20160301936A1; KR101628582B1; ES2686936T3; EP2735152A1; KR20140043483A

Abstract

本開示は、３次元（３Ｄ）ビデオコーディングに適用可能な特徴および技法について説明する。一例では、技法は、テクスチャビュービデオブロックをコーディングすることと、深度ビュービデオブロックをコーディングすることであり、深度ビュービデオブロックがテクスチャビュービデオブロックに関連付けられることとを含み得る。深度ビュービデオブロックをコーディングすることは、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含み得る。

Description

本出願は、各々の内容全体がその全体の中に参照により組み込まれる、
２０１１年１１月１８日に出願された米国仮特許出願第６１／５６１，８００号、
２０１１年１１月２６日に出願された米国仮特許出願第６１／５６３，７７１号、
２０１１年８月１１日に出願された米国仮特許出願第６１／５２２，５５９号、
２０１１年７月２２日に出願された米国仮特許出願第６１／５１０，７３８号、
２０１１年８月１１日に出願された米国仮特許出願第６１／５２２，５８４号、
２０１１年１１月２６日に出願された米国仮特許出願第６１／５６３，７７２号、および
２０１２年４月１３日に出願された米国仮特許出願第６１／６２４，０３１号の利益を主張する。

本開示は、３次元（３Ｄ）ビデオコーディングに関する。

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−ＴＨ．２６３、ＩＴＵ−ＴＨ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法などの、ビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。

ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を実行する。ブロックベースのビデオコーディングでは、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部）はビデオブロックに区分され得、これらのビデオブロックはまた、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることもある。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック内の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック内の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコード化ブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて、残差変換係数が得られ得、その残差変換係数は、次いで量子化され得る。量子化変換係数は、最初は２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するために、エントロピーコーディングが適用され得る。

３次元（３Ｄ）ビデオは、様々な適用例に極めて望ましいが、３Ｄビデオコーディングは、多数の課題をもたらす。

本開示は、３次元（３Ｄ）ビデオコーディングに適用可能な特徴および技法について説明する。一例では、技法は、テクスチャビュービデオブロックをコーディングすることと、深度ビュービデオブロックをコーディングすることであり、深度ビュービデオブロックがテクスチャビュービデオブロックに関連付けられる、コーディングすることとを含み得る。深度ビュービデオブロックをコーディングすることは、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含み得る。

説明する技法は、本明細書では内部ビュー動き予測（ＩＭＶＰ：inside view motion prediction）モードと呼ぶコーディングモードに対応し得る。この場合、深度ビュー構成要素（たとえば、深度ビュービデオブロック）は、その動き情報に関するいかなる追加のデルタ値を含まなくてもよく、代わりに、テクスチャビュー構成要素の動き情報を、その動き情報として採用し得る。テクスチャビューの動き情報を深度ビューの動き情報として完全に採用するモードを定義することによって、そのような動き情報に関するデルタ値のいかなるシグナリングもなしに、改善された圧縮が達成され得る。

別の例では、本開示は、３Ｄビデオデータをコーディングするデバイスについて説明し、このデバイスは、テクスチャビュービデオブロックをコーディングすることと、深度ビュービデオブロックをコーディングすることであり、深度ビュービデオブロックがテクスチャビュービデオブロックに関連付けられる、コーディングすることとを行うように構成された、１つまたは複数のプロセッサを備える。深度ビュービデオブロックをコーディングすることは、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む。

別の例では、本開示は、記憶された命令を備えるコンピュータ可読記憶媒体について説明し、これらの命令は、実行すると、１つまたは複数のプロセッサに、テクスチャビュービデオブロックをコーディングすることと、深度ビュービデオブロックをコーディングすることであり、深度ビュービデオブロックがテクスチャビュービデオブロックに関連付けられる、コーディングすることとを行わせる。深度ビュービデオブロックをコーディングすることは、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む。

別の例では、本開示は、３Ｄビデオデータをコーディングするように構成されたデバイスについて説明し、このデバイスは、テクスチャビュービデオブロックをコーディングするための手段と、深度ビュービデオブロックをコーディングするための手段であり、深度ビュービデオブロックがテクスチャビュービデオブロックに関連付けられる、コーディングするための手段とを備え、深度ビュービデオブロックをコーディングするための手段が、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングするための手段を含む。

１つまたは複数の例の詳細を添付の図面および以下の説明に記載する。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。

本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図。本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図。１つのアクセスユニットの内部のビュー構成要素のビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットのビットストリーム順序を示す概念図。深度ビューの４番目のピクチャ中の識別されたマクロブロックと、テクスチャビューの４番目のピクチャ中のコロケート（co-located）ＭＢの動きベクトルとが、深度ビュー構成要素中で再使用される、ビデオシーケンスを形成するピクチャのシーケンスの概念図。３次元ビデオコーディング（３ＤＶＣ）コーデックによって使用され得る予測構造を示す概念図。深度ビュー構成要素についてのビュー間予測を可能にしない、３ＤＶＣコーデックの予測構造を示す概念図。左ビュー（ＶＬ）と右ビュー（ＶＲ）の両方が半分の幅をもつ、非対称ビュー間予測の一例を示す概念図。本開示に一致する、ビデオエンコーダによって実行され得る技法を示す流れ図。本開示に一致する、ビデオデコーダによって実行され得る技法を示す流れ図。

詳細な説明

本開示の技法は、ＩＴＵ−ＴＨ．２６４／ＡＶＣ規格と、ＩＴＵ−ＴＨ．２６４／ＡＶＣ規格のＡｎｎｅｘＨなど、マルチビューコーディング（ＭＶＣ）をサポートする１つまたは複数の拡張とに基づく、３次元（３Ｄ）ビデオコーディングに関する。しかしながら、これらの技法はまた、現在開発中の新生のＨＥＶＣ規格、ＩＴＵ−ＴＨ．２６４／ＡＶＣ規格もしくは新生のＨＥＶＣ規格の拡張、または、Ｏｎ２ＶＰ６／ＶＰ７／ＶＰ８などのプロプライエタリなビデオコーディング技法など、他のビデオコーディング規格または技法にも適用され得る。

３Ｄビデオコーディングでは、しばしば、３Ｄビデオプレゼンテーションを定義するために集合的に使用される、複数の異なるビューがある。その上、異なるビューの各々は、テクスチャビュー構成要素と深度ビュー構成要素の両方を含み得る。テクスチャビュー構成要素は、「ビデオブロック」と呼ばれ、Ｈ．２６４コンテキストでは一般に「マクロブロック」と呼ばれる、ビデオデータのブロック中でコーディングされ得る。同様に、深度ビュー構成要素もまた、「ビデオブロック」としてコーディングされ、Ｈ．２６４規格では一般に「マクロブロック」と呼ばれる。各テクスチャビデオブロックは、対応する深度ビューブロックを有し得る。異なるビデオブロック（テクスチャおよび深度）は、しかしながら、通常、別々にコーディングされる。他のビデオコーディング規格は、ビデオブロックをツリーブロックまたはコーディングユニット（ＣＵ）と呼ぶことがある。

インターコーディングの場合、動きベクトル（または、動きベクトル予測子に対する動きベクトル差分値）が、予測ブロックを定義するために使用され得、予測ブロックが次いで、コード化ビデオブロックの値を予測するために使用される。この場合、いわゆる「残差値」または「差分値」は、対応する予測ブロックを識別する動きベクトル（または、動きベクトル予測子に対する動きベクトル差分値）とともに、符号化ビットストリーム中に含まれる。デコーダは、動きベクトルと残差値とを受信し、動きベクトルを使用して、前に復号されたビデオデータから予測ブロックを識別する。符号化ビデオブロックを再構成するために、デコーダは、残差値を、動きベクトルによって識別された対応する予測ブロックと組み合わせる。

３Ｄビデオコーディングに関する多数の潜在的な問題が存在する。たとえば、マルチビュービデオデータをコーディングするとき、効率的なコーデックを作成するために、以下の問題が解決される必要があり得る。

１．１つまたは複数のビューのためのテクスチャ構成要素および深度構成要素のジョイントコーディングのための能力を提供する、
２．テクスチャと深度との間の動き冗長性を利用するための能力を提供する、
３．簡単かつ効率的な方法でカメラパラメータを送信するための能力を提供する、
４．ビュー適応（view adaptation）では、ビュー構成要素が、出力のために使用されているビューに属していない場合、そのビュー構成要素を破棄するために、ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇが使用され得る。しかしながら、非対称３ＤＶの場合、このフラグが０に等しい場合でも、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットがなお、異なる解像度をもつビューの予測のために必要とされ得る。

上記の問題を解決するために、以下を含むいくつかの技法が使用され得る。

１．深度ビューおよびテクスチャビューのジョイントコーディングをサポートするためのフレームワーク。

２．新しい内部ビュー動き予測（ＩＶＭＰ）モードが、深度ビューとテクスチャビューとの間の動きベクトルの再使用を可能にするために、マクロブロック（または、他のビデオブロックもしくはＣＵ）レベルで使用され得る。ＩＶＭＰモードの態様については、本開示で詳細に説明する。

３．カメラパラメータおよび深度範囲が、シーケンスパラメータセット（ＳＰＳ）に、または新しい補足エンハンスメント情報（ＳＥＩ：supplemental enhancement information）メッセージとして追加され得、そのようなパラメータがピクチャ単位で変わる場合、ＶＰＳ（ビューパラメータセット）またはＳＥＩメッセージが追加され得る。

４．異なる解像度をもつビューのために破棄可能でないビュー構成要素が、同じ解像度をもつビューのためにも破棄可能であるかどうかを示すために、ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇのセマンティクス（semantics）が修正され得るか、または、新しいシンタックス要素がネットワークアブストラクションレイヤ（ＮＡＬ）ユニットヘッダ中で定義され得る。

５．深度ビュー構成要素によって使用されるべきｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ（たとえば、２１）に加えて、一例は、Ｈ．２６４／ＭＶＣと互換性がないテクスチャビュー構成要素のための、新しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ（たとえば、２２）をさらに含む。

本開示は、以下の定義を使用し得る。

ビュー構成要素：単一のアクセスユニット中のビューのコード化表現。ビューが、コード化テクスチャ表現とコード化深度表現の両方を含むとき、ビュー構成要素は、テクスチャビュー構成要素および深度ビュー構成要素からなる。

テクスチャビュー構成要素：単一のアクセスユニット中のビューのテクスチャのコード化表現。

深度ビュー構成要素：単一のアクセスユニット中のビューの深度のコード化表現。

深度ビュー構成要素中のコード化ビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットは、特に深度ビュー構成要素のための新しいタイプのコード化スライス拡張として、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ２１を割り当てられ得る。テクスチャビュー構成要素および深度ビュー構成要素はまた、本明細書では、テクスチャビュービデオブロックおよび深度ビュービデオブロックと呼ぶこともある。

次に、例示的なビットストリーム順序について説明する。いくつかの例では、各ビュー構成要素において、深度ビュー構成要素の（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ２１をもつ）いかなるコード化スライスＮＡＬユニットも、テクスチャビュー構成要素のすべてのコード化スライスＮＡＬユニットの後にこなければならない。簡単のために、本開示は、深度ビュー構成要素のコード化スライスＮＡＬユニットを、深度ＮＡＬユニットと称することがある。

深度ＮＡＬユニットは、２０に等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅをもつＮＡＬユニットと同じＮＡＬユニットヘッダ構造を有し得る。図４は、１つのアクセスユニットの内部のビュー構成要素のＶＣＬＮＡＬユニットのビットストリーム順序を示す概念図である。

図４に示すように、本開示によれば、アクセスユニットは、複数のビュー構成要素とともに複数のＮＡＬユニットを含む。各ビュー構成要素は、１つのテクスチャビュー構成要素および１つの深度ビュー構成要素からなり得る。０に等しいビュー順序インデックス（ＶＯＩｄｘ：view order index）をもつ、ベースビューのテクスチャビュー構成要素は、（１４に等しいＮＡＬユニットタイプをもつ）１つのプレフィックスＮＡＬユニットと、（たとえば、１または５に等しいＮＡＬユニットタイプをもつ）１つまたは複数のＡＶＣＶＣＬＮＡＬユニットとを含む。他のビュー中のテクスチャビュー構成要素は、（２０に等しいＮＡＬユニットタイプをもつ）ＭＶＣＶＣＬＮＡＬユニットのみを含む。ベースビューと非ベースビューの両方において、深度ビュー構成要素は、２１に等しいＮＡＬユニットタイプをもつ深度ＮＡＬユニットを含む。いかなるビュー構成要素においても、深度ＮＡＬユニットは、復号／ビットストリーム順序において、テクスチャビュー構成要素のＮＡＬユニットの後にくる。

テクスチャビュー構成要素、およびその関連付けられた深度ビュー構成要素は、同様のオブジェクトシルエットを有するので、それらは一般に、同様のオブジェクト境界と動きとを有する。したがって、それらの動きフィールド（motion field）に冗長性がある。テクスチャビューブロックおよび深度ビューブロックは、それらが同じＮＡＬユニット中に存在する場合、かつ／または、それらが３Ｄビデオデータの同じ（もしくは、重複する）空間および／もしくは時間インスタンスに対応する場合、「関連付け」られ得る。本開示の技法は、いわゆる「マージ」モードと同様の方法で、深度ビュー構成要素が関連付けられたテクスチャビュー構成要素の動き情報を完全に採用するモードを可能にすることによって、この冗長性をかなりの程度まで活用し得る。この場合、深度ビュー構成要素は、その動き情報に関するいかなる追加のデルタ値を含まなくてもよく、代わりに、テクスチャビュー構成要素の動き情報を、その動き情報として採用し得る。テクスチャビューの動き情報を深度ビューの動き情報として完全に採用するモードを定義することによって、そのような動き情報に関するデルタ値のいかなるシグナリングもなしに、改善された圧縮が達成され得る。

特に、テクスチャビュー構成要素から、関連付けられた深度ビュー構成要素への動き予測は、テクスチャビューの動き情報を深度ビューの動き情報としてマージする新しいモードに従って可能にされ得る。いくつかの例では、このいわゆる内部ビュー動き予測（ＩＶＭＰ）モードは、深度ビュー構成要素をもつインターコード化ＭＢに対してのみ有効にされ得る。ＩＶＭＰモードでは、テクスチャビュー構成要素中のコロケートＭＢのｍｂ＿ｔｙｐｅと、ｓｕｂ＿ｍｂ＿ｔｙｐｅと、参照インデックスと、動きベクトルとを含む動き情報が、同じビューの深度ビュー構成要素によって再使用される。各ＭＢ中で、それがＩＶＭＰモードを使用するかどうかを示すために、フラグがシグナリングされ得る。言い換えれば、フラグは、ビデオブロックレベル、たとえば、マクロブロックレベルで定義され得る。フラグは、深度ビデオブロック（たとえば、深度マクロブロック）とともに含まれ得る。図５に示すように、フラグは、深度ビューの４番目のピクチャ中の識別されたＭＢについて真であり得、（４番目のピクチャとして識別された）テクスチャビューの４番目のピクチャ中のコロケートＭＢの動きベクトルが、深度ビュー構成要素中で強調されたＭＢのために再使用される。いくつかの例では、ＩＶＭＰモードは、非アンカーピクチャのみに適用されることに留意されたい。

この場合も、別のビューの動きに基づいて、あるビューのための動きベクトルを予測する技法と比較して、本開示の技法は、さらなる圧縮を達成し得る。たとえば、いくつかのスケーラブルビデオコーディング（ＳＶＣ）技法は、ベースビューの動き情報に基づいてエンハンスメントビューの動き予測を可能にし得、場合によっては、ベースビューはテクスチャビューであり得、エンハンスメントビューは深度ビューであり得る。そのような場合、しかしながら、エンハンスメントビューを予測するためにベースビューが使用されることを示す、予測情報（または、フラグ）に加えて、動きベクトル差分データ（たとえば、デルタ）が常にコーディングされる。対照的に、本開示の技法は、デルタ情報（たとえば、動きベクトル差分値）がコーディングまたは可能にされない、ＩＶＭＰモードを利用し得る。代わりに、ＩＶＭＰモードの場合、テクスチャビューの動き情報が、深度ビューの動き情報として採用される。

テクスチャビューの動き情報が、深度ビューの動き情報として採用されるとき、デコーダは、テクスチャビュー（たとえば、テクスチャブロック）の動き情報を使用して、深度ビュー（たとえば、対応する深度ブロック）についての任意の他の動き情報を受信または復号することなしに、深度ビューを復号し得る。特に、デコーダは、このようにして、ＩＶＭＰフラグを解釈するように構成され得る。このようにして、動き情報は、ＩＶＭＰフラグが有効にされるとき、深度ビデオブロックから除外され得、デコーダは、深度ビデオブロックについての動き情報が対応するテクスチャビデオブロックから取得され得ることを、有効にされたＩＶＭＰフラグが意味することを、知るように構成され得る。

本開示に一致するエンコーダは、一般に、ビューが１つずつ符号化される、ジョイントマルチビュービデオコーディング（ＪＭＶＣ：joint multiview video coding）エンコーダ方式に準拠し得る。各ビューの内部で、テクスチャシーケンスが第１に符号化され、深度シーケンスが次いで符号化される。

テクスチャビュー構成要素符号化中に、ＩＶＭＰモードが有効にされるとき、各テクスチャビュー構成要素の動きフィールドが動きファイルに書き込まれ、その名前が構成ファイル中で指定され得る。同じビューの関連付けられた深度シーケンスを符号化するとき、動きファイルが参照のために読み取られ得る。

デコーダは、ＪＭＶＣデコーダと同様であり得、いくつかの態様では、ビューごとに深度シーケンスの復号および出力をも行う修正がある。ＩＶＭＰモードが有効にされるとき、各テクスチャビュー構成要素の動きが記憶され、各対応する深度ビューの動きとして採用される。ＩＶＭＰモードが無効にされるいかなるブロックについても、深度ビューは、それ自体の動き情報を含み得、または、どこでそのそれぞれの動き情報を取得、予測かつ／もしくは採用するべきかを識別するために、いくつかの他のシンタックス要素を含み得る。ＩＶＭＰモードが有効にされる場合、しかしながら、深度ビューは、それ自体の動き情報を含まず、動き情報は、対応するテクスチャビュー構成要素からデコーダによって取得される。このようにして、ＩＶＭＰモードが有効にされるとき、深度ビュービデオブロックは、深度ビュービデオブロックがそれ自体の動き情報を含まないように、対応するテクスチャビュービデオブロックの動き情報を採用する。

以下の図１、図２、および図３の説明は、本開示のＭＶＣベースの３ＤＶＣ技法が使用され得る、いくつかの例示的なシナリオについて説明する。

図１は、本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示すように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを生成するソースデバイス１２を含む。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。

宛先デバイス１４は、リンク１６を介して復号されるべき符号化ビデオデータを受信し得る。リンク１６は、ソースデバイス１２から宛先デバイス１４に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、リンク１６は、ソースデバイス１２が、符号化ビデオデータをリアルタイムで宛先デバイス１４に直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。

代替的に、符号化データは、出力インターフェース２２からストレージデバイス３２に出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイス３２からアクセスされ得る。ストレージデバイス３２は、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散したまたはローカルでアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス３２は、ソースデバイス１２によって生成された符号化ビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイス３２から、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することと、その符号化ビデオデータを宛先デバイス１４に送信することとが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。ストレージデバイス３２からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。

本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、単方向または二方向のビデオ送信をサポートするように構成され得る。

図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。場合によっては、出力インターフェース２２は、変調器／復調器（モデム）および／または送信機を含み得る。ソースデバイス１２において、ビデオソース１８は、たとえばビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および／またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、あるいはそのようなソースの組合せを含み得る。一例として、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き携帯電話またはビデオ電話を形成し得る。ただし、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。

キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ１２によって符号化され得る。符号化ビデオデータは、ソースデバイス２０の出力インターフェース２２を介して宛先デバイス１４に直接送信され得る。符号化ビデオデータは、さらに（または代替として）、復号および／または再生のための宛先デバイス１４または他のデバイスによる後のアクセスのためにストレージデバイス３２上に記憶され得る。

宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３１とを含む。場合によっては、入力インターフェース２８は、受信機および／またはモデムを含み得る。宛先デバイス１４の入力インターフェース２８は、リンク１６を介して符号化ビデオデータを受信する。リンク１６を介して通信され、またはストレージデバイス３２上に与えられた符号化ビデオデータは、ビデオデータを復号する際に、ビデオデコーダ３０など、ビデオデコーダが使用するためのビデオエンコーダ２０によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体上に記憶されるか、またはファイルサーバ上に記憶される符号化ビデオデータとともに含まれ得る。

ディスプレイデバイス３１は、宛先デバイス１４と一体化されるかまたはその外部にあり得る。いくつかの例では、宛先デバイス１４は、一体型ディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス１４はディスプレイデバイスであり得る。概して、ディスプレイデバイス３１は、復号ビデオデータをユーザに対して表示し、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオ圧縮規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ：HEVC Test Model）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−ＴＨ．２６４規格など、他のプロプライエタリまたは業界標準、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例は、ＭＰＥＧ−２およびＩＴＵ−ＴＨ．２６３を含む。Ｏｎ２ＶＰ６／ＶＰ７／ＶＰ８と呼ばれるものなど、プロプライエタリなコーディング技法もまた、本明細書で説明する技法のうちの１つまたは複数を実施し得る。

図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、いくつかの例では、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵＨ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。

ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法がソフトウェアで部分的に実施されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。

ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−ＴＨ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。

概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding unit）に分割され得ることを記載している。ツリーブロックは、Ｈ．２６４規格のマクロブロックと同様の目的を有する。スライスは、コーディング順序でいくつかの連続的なツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。たとえば、４分木のルートノードとしてのツリーブロックは、４つの子ノードに分割され得、各子ノードは、次に、親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードとしての、最終的な、分割されていない子ノードは、コーディングノード、すなわち、コード化ビデオブロックを備える。コード化ビットストリームに関連するシンタックスデータは、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズをも定義し得る。ツリーブロックは、いくつかの例では、ＬＣＵと呼ばれることがある。

ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルをもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が方形または非方形であり得る。

ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従う変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用してより小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、変換されて変換係数が生成され得、その変換係数は量子化され得る。

一般に、ＰＵは、予測プロセスに関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵは、ＰＵについてのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、そのＰＵについての動きベクトルを定義するデータを含み得る。ＰＵについての動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）を記述し得る。

概して、ＴＵは、変換プロセスと量子化プロセスとのために使用される。１つまたは複数のＰＵを有する所与のＣＵは、１つまたは複数の変換ユニット（ＴＵ）をも含み得る。予測の後に、ビデオエンコーダ２０は、ＰＵに対応する残差値を計算し得る。残差値は、エントロピーコーディングのためのシリアル化変換係数（serialized transform coefficient）を生成するために、ＴＵを使用して変換係数に変換され、量子化され、走査され得るピクセル差分値を備える。本開示では、一般に、ＣＵのコーディングノードを指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合において、本開示では、コーディングノードならびにＰＵおよびＴＵを含む、ツリーブロック、すなわち、ＬＣＵまたはＣＵを指す「ビデオブロック」という用語も使用し得る。

ビデオシーケンスは、一般的に、一連のビデオフレームまたはピクチャを含む。ピクチャのグループ（ＧＯＰ）は、一般に、一連の１つまたは複数のビデオピクチャを備える。ＧＯＰは、ＧＯＰ内に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、１つまたは複数のピクチャのヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に応じてサイズが異なり得る。

一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば「２Ｎ×ｎＵ」は、上部に２Ｎ×０．５ＮＰＵと下部に２Ｎ×１．５ＮＰＵとで水平方向に区分される２Ｎ×２ＮＣＵを指す。

本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ただし、Ｎは非負整数値を表す。ブロック中のピクセルは行と列とに構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ただし、Ｍは必ずしもＮに等しいとは限らない。

ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域においてピクセルデータを備え得、ＴＵは、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換などの変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。

変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、この場合、ｎはｍよりも大きい。

いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。

ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルの可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢（more probable）シンボルに対応し、より長いコードが劣勢（less probable）シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率判断は、シンボルに割り当てられるコンテキストに基づき得る。

図２は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ２０を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモードは、いくつかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測（Ｐモード）または双予測（Ｂモード）などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。

図２の例では、ビデオエンコーダ２０は、区分ユニット３５と、予測モジュール４１と、参照ピクチャメモリ６４と、加算器５０と、変換モジュール５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。予測モジュール４１は、動き推定ユニット４２と、動き補償ユニット４４と、イントラ予測モジュール４６とを含む。ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換モジュール６０と、加算器６２とを含む。再構成されたビデオからブロッキネスアーティファクト（blockiness artifacts）を除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ（図２に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタ処理することになる。また、デブロッキングフィルタに加えて追加のループフィルタ（ループ内またはループ後）が使用され得る。

図２に示すように、ビデオエンコーダ２０はビデオデータを受信し、区分ユニット３５はデータをビデオブロックに区分する。この区分は、たとえば、ＬＣＵおよびＣＵの４分木構造に応じて、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分をも含み得る。ビデオエンコーダ２０は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに（および、場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。予測モジュール４１は、誤り結果（たとえば、コーディングレートおよびひずみレベル）に基づいて現在のビデオブロックのために、複数のイントラコーディングモードのうちの１つ、または複数のインターコーディングモードのうちの１つなど、複数の可能なコーディングモードのうちの１つを選択し得る。予測モジュール４１は、得られたイントラコード化ブロックまたはインターコード化ブロックを、残差ブロックデータを生成するために加算器５０に与え、参照ピクチャとして使用するための符号化ブロックを再構成するために加算器６２に与え得る。

予測モジュール４１内のイントラ予測モジュール４６は、空間圧縮を提供するために、コーディングされるべき現在のブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対する現在のビデオブロックのイントラ予測コーディングを実行し得る。予測モジュール４１内の動き推定ユニット４２および動き補償ユニット４４は、時間圧縮を提供するために、１つまたは複数の参照ピクチャ中の１つまたは複数の予測ブロックに対する現在のビデオブロックのインター予測コーディングを実行する。

動き推定ユニット４２は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを判断するように構成され得る。所定のパターンは、シーケンス中のビデオスライスをＰスライス、Ｂスライス、またはＧＰＢスライスに指定し得る。動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。

予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるべきビデオブロックのＰＵにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。

動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵについての動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得、それらの参照ピクチャリストの各々は、参照ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。

動き補償ユニット４４によって実行される動き補償は、動き推定によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを伴い得る。現在のビデオブロックのＰＵについての動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいて指す予測ブロックの位置を特定し得る。ビデオエンコーダ２０は、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって残差ビデオブロックを形成する。ピクセル差分値は、ブロックの残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。動き補償ユニット４４はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するための、ビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。

イントラ予測モジュール４６は、上記で説明したように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測モジュール４６は、現在のブロックを符号化するために使用すべきイントラ予測モードを判断し得る。いくつかの例では、イントラ予測モジュール４６は、たとえば、別々の符号化パス（passes）中に、様々なイントラ予測モードを使用して現在のブロックを符号化し得、イントラ予測モジュール４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。たとえば、イントラ予測モジュール４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を判断する。イントラ予測モジュール４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを判断するために、様々な符号化ブロックについてのひずみおよびレートから比率を計算し得る。

場合によっては、予測モジュール４１は、１つまたは複数の深度ビデオブロックをコーディングするためにＩＶＭＰモードを選択し得る。この場合、対応するテクスチャビデオブロックについての動き情報が、本明細書で説明するように、深度ブロックのために採用され得る。深度ブロックおよびテクスチャブロックは、同じＮＡＬユニットにコーディングされ得、デコーダが、対応するテクスチャビュービデオブロックの動き情報を再使用することによって、深度ビデオブロックを適切に復号することができるように、ＩＶＭＰフラグが符号化され得る。

いずれの場合も、あるブロックについてのイントラ予測モードを選択した後、イントラ予測モジュール４６は、エントロピー符号化ユニット５６にブロックについての選択されたイントラ予測モードを示す情報を提供し得る。エントロピー符号化ユニット５６は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを含み得る。

予測モジュール４１が、インター予測またはイントラ予測のいずれかを介して、現在のビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ２０は、現在のビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、１つまたは複数のＴＵ中に含まれ、変換モジュール５２に適用され得る。変換モジュール５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換モジュール５２は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。

変換モジュール５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。

量子化の後、エントロピー符号化ユニット５６は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピー符号化方法または技法を実行し得る。エントロピー符号化ユニット５６によるエントロピー符号化の後に、符号化ビットストリームは、ビデオデコーダ３０に送信されるか、あるいはビデオデコーダ３０が後で送信するかまたは取り出すためにアーカイブされ得る。エントロピー符号化ユニット５６はまた、コーディングされている現在のビデオスライスのための動きベクトルと他のシンタックス要素とをエントロピー符号化し得る。

逆量子化ユニット５８および逆変換モジュール６０は、それぞれ逆量子化および逆変換を適用して、参照ピクチャの参照ブロックとして後で使用するためにピクセル領域において残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックを参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するためのサブ整数ピクセル値を計算し得る。加算器６２は、再構成された残差ブロックを動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ６４に記憶するための参照ブロックを生成する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。

図３は、本開示で説明する技法を実装し得る例示的なビデオデコーダ３０を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット８０と、予測モジュール８１と、逆量子化ユニット８６と、逆変換ユニット８８と、加算器９０と、参照ピクチャメモリ９２とを含む。予測モジュール８１は、動き補償ユニット８２と、イントラ予測モジュール８４とを含む。ビデオデコーダ３０は、いくつかの例では、図２のビデオエンコーダ２０に関して説明した符号化パスとは概して逆の復号パスを実行し得る。

復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット８０は、量子化係数と、動きベクトルと、他のシンタックス要素とを生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット８０は、予測モジュール８１に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、予測モジュール８１のイントラ予測モジュール８４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（すなわち、Ｂ、ＰまたはＧＰＢ）スライスとしてコーディングされるとき、予測モジュール８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト０およびリスト１を構成し得る。

動き補償ユニット８２は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックについての予測情報を判断し、予測情報を使用して、復号されている現在のビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット８２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数についての構成情報と、スライスの各インター符号化ビデオブロックについての動きベクトルと、スライスの各インターコード化ビデオブロックについてのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを判断するために、受信されたシンタックス要素のいくつかを使用する。

場合によっては、予測モジュール８１は、ＮＡＬユニット中のフラグを解釈し、ＮＡＬユニットの１つまたは複数の深度ビデオブロックを復号するためのＩＶＭＰモードを選択し得る。この場合、対応するテクスチャビデオブロックについての動き情報が、本明細書で説明するように、深度ブロックのために採用され得る。深度ブロックおよびテクスチャブロックは、同じＮＡＬユニットにコーディングされ得、ビデオデコーダ３０が対応するテクスチャビュービデオブロックの動き情報を再使用することによって、深度ビデオブロックを適切に復号することができるように、ＩＶＭＰフラグがビットストリームから復号され得る。

動き補償ユニット８２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット８２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット８２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。

逆量子化ユニット８６は、ビットストリーム中で与えられ、エントロピー復号ユニット８０によって復号された量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、ビデオスライス中の各ビデオブロックについてビデオエンコーダ２０によって計算される量子化パラメータを使用して量子化の程度を判断し、同様に、適用すべき逆量子化の程度を判断することを含み得る。逆変換モジュール８８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。

予測モジュール８１が、インター予測またはイントラ予測のいずれかに基づいて現在のビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換モジュール８８からの残差ブロックを予測モジュール８１によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ９２に記憶される。参照ピクチャメモリ９２はまた、図１００のディスプレイデバイス３１などのディスプレイデバイス上での後の提示のために、復号されたビデオを記憶する。

３Ｄビデオコーディングでは、テクスチャビュー構成要素、およびその関連付けられた深度ビュー構成要素は、同様のオブジェクトシルエットを有し得、これらの異なるビュー構成要素は、同様のオブジェクト境界と動きとを有し得る。したがって、関連付けられたテクスチャビュー構成要素および深度ビュー構成要素の動きフィールドに冗長性がある。本開示の技法は、いわゆる「マージ」モードと同様の方法で、深度ビュー構成要素がテクスチャビュー構成要素の動き情報を完全に採用するモードを可能にすることによって、この冗長性を従来の技法よりも大きい程度まで活用し得る。この場合、深度ビュー構成要素は、その動き情報に関するいかなる追加のデルタ値を含まなくてもよく（すなわち、いかなる動きベクトル差分値をも含まなくてもよく）、代わりに、テクスチャビュー構成要素の動き情報を、その動き情報として採用し得る。

特に、テクスチャビュー構成要素から、関連付けられた深度ビュー構成要素への動き予測は、テクスチャビューの動き情報を深度ビューの動き情報としてマージする新しいモードに従って可能にされ得る。いくつかの例では、このいわゆるＩＶＭＰモードは、深度ビュー構成要素をもつインターコード化ＭＢに対してのみ有効にされ得る。ＩＶＭＰモードでは、テクスチャビュー構成要素中のコロケートＭＢのｍｂ＿ｔｙｐｅと、ｓｕｂ＿ｍｂ＿ｔｙｐｅと、参照インデックスと、動きベクトルとを含む動き情報が、同じビューの深度ビュー構成要素によって再使用される。各ＭＢ中で、それがＩＶＭＰモードを使用するかどうかを示すために、フラグがシグナリングされ得る。図５に示すように、フラグは、深度ビューの４番目のピクチャ中の識別されたＭＢについて真であり得、（４番目のピクチャとして識別された）テクスチャビューの４番目のピクチャ中のコロケートＭＢの動きベクトルが、深度ビュー構成要素中で強調されたＭＢのために再使用される。いくつかの例では、ＩＶＭＰモードは、非アンカーピクチャのみに適用されることに留意されたい。「アンカーピクチャ」という用語は、瞬時復号リフレッシュ（ＩＤＲ：instantaneous decoding refresh）ピクチャとは異なる任意のランダムアクセスポイント（ＲＡＰ）として定義され得る。

上述のように、別のビューの動きに基づいて、あるビューのための動きベクトルを予測する従来の技法と比較して、本開示の技法は、さらなる圧縮を達成し得る。たとえば、いくつかの従来のスケーラブル技法は、ベースビューの動き情報に基づいてエンハンスメントビューの動き予測を可能にし得、場合によっては、ベースビューはテクスチャビューであり得、エンハンスメントビューは深度ビューであり得る。そのような場合、しかしながら、エンハンスメントビューを予測するためにベースビューが使用されることを示す、予測情報（または、フラグ）に加えて、動きベクトル差分値（たとえば、デルタ）が常にコーディングされる。対照的に、本開示の技法は、デルタ情報がコーディングまたは可能にされない、ＩＶＭＰモードを利用し得る。代わりに、ＩＶＭＰモードの場合、テクスチャビューの動き情報が、深度ビューの動き情報として採用される。

圧縮されたビデオデータをシグナリングするための、様々なシグナリング技法の追加の詳細について、次に説明する。ビューパラメータセット（ＶＰＳ）は、パラメータセットがコード化ピクチャに関連付けられ、１つのチャネルまたはセッション中で一緒に送信されることを意味する、「インバンド」としてシグナリングされ得る。ビットストリームの時間インスタンスのコード化表現である、アクセスユニット（ＡＵ）中に存在する場合、ＶＰＳは、いかなるＶＣＬＮＡＬユニットにも先行する必要があり得る。複数のフレームは、回復力をもたらすために、重複した等しいＶＰＳを有し得る。

いくつかの例では、本開示の技法は、ｉｎｖｅｒ＿ｖｉｅｗ＿ｆｌａｇを扱い得、ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇのセマンティクスを拡張し得る。一例では、０に等しいｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇは、現在のビュー構成要素が、同じまたは異なる空間解像度をもつ現在のアクセスユニット中の他のいかなるビュー構成要素によってもビュー間予測のために使用されないことを指定する。この例では、１に等しいｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇは、現在のビュー構成要素が、現在のアクセスユニット中の他のビュー構成要素によってビュー間予測のために使用され得ることを指定し得る。

ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇの値は、ビュー構成要素のすべてのＶＣＬＮＡＬユニットについて同じであり得る。

一例では、左ビューおよび右ビューはハーフ解像度であり、中央ビューはフル解像度である。非対称３ＤＶプロファイルでは、このフラグは、たとえば、右ビューについて、１に設定され得る。しかしながら、ＭＶＣサブビットストリームが抽出される場合、このフラグが１である必要はない。

ｉｎｔｅｒ＿ａｓｙ＿ｖｉｅｗ＿ｆｌａｇと呼ばれるフラグを、次のように定義する。

いくつかの例では、０に等しいｉｎｔｅｒ＿ａｓｙ＿ｖｉｅｗ＿ｆｌａｇは、現在のビュー構成要素が、異なる空間解像度をもつ現在のアクセスユニット中の他のいかなるビュー構成要素によってもビュー間予測のために使用されないことを指定する。１に等しいｉｎｔｅｒ＿ａｓｙ＿ｖｉｅｗ＿ｆｌａｇは、現在のビュー構成要素が、現在のアクセスユニット中の異なる空間解像度をもつ他のビュー構成要素によってビュー間予測のために使用され得ることを指定する。

上記の例では、左ビューについて、ＮＡＬユニットは、１に等しいｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇと、１に等しいｉｎｔｅｒ＿ａｓｙ＿ｖｉｅｗ＿ｆｌａｇとを有し得る。右ビューについて、ＮＡＬユニットは、０に等しいｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇと、１に等しいｉｎｔｅｒ＿ａｓｙ＿ｖｉｅｗ＿ｆｌａｇとを有し得、中央ビューについて、すべてのＮＡＬユニットは、０に等しいこれらの２つのフラグを有し得る。

本開示は、ＭＰＥＧによって発行された３Ｄビデオコーディング上でＣａｌｌｆｏｒＰｒｏｐｏｓａｌ（ＣｆＰ）に応答を与え得る。この提案は、複数のビューのためのテクスチャおよび深度のジョイントコーディングを組み込み得る、いくつかのエンハンスメントと追加とをもつＨ．２６４／ＭＶＣ参照ソフトウェアＪＭＶＣに基づく。本開示の提案は、テクスチャおよび深度のジョイントコーディングと、ビュー内のテクスチャから深度への予測と、異なる解像度をもつビュー構成要素の非対称コーディングとを含み得る。この提案では、ＭＰＥＧビュー合成ソフトウェアが、いかなる修正もなしにビュー生成のために使用され得る。

ＪＭＶＣ８．３．１アンカーと比較して、ビットレートが２つのビューのテクスチャと深度の両方の総ビットレートであり、ピーク信号対雑音比（ＰＳＮＲ）値が２つの復号テクスチャビューの平均ＰＳＮＲ値であるとき、２ビューの場合では、本開示の提案は、最大２２．６％まで（平均では１１．７％）のレート低減を達成し得、３ビューの場合では、最大１５．８％まで（平均では７．３％）のレート低減を達成し得る。

２ビューの場合では、合成ビューの総ビットレート対ＰＳＮＲ値が使用される場合、ＢＤレート低減は最大２４．７％まで（および、平均では１３．９％）であり、３ビューの場合では、２つの合成ビューの総ビットレート対平均ＰＳＮＲ値が使用される場合、ＢＤレート低減は最大１９．０％まで（および、平均では１５．０％）である。

本開示は、以下を提供し得る。

・Ｈ．２６４／ＡＶＣハイプロファイルとＨ．２６４／ＭＶＣステレオハイプロファイルの両方、および潜在的にマルチビューハイプロファイルとの互換性、
・マルチビューシーケンスのためのテクスチャおよび深度のジョイントコーディング、
・各ビューのテクスチャビュー構成要素および深度ビュー構成要素のための対称的な空間解像度および時間解像度、
・異なるビューのための非対称空間解像度。

Ｈ．２６４／ＭＶＣコーデックに加えて追加のコーデック修正はまた、以下をも含み得る。

・テクスチャビュー構成要素および深度ビュー構成要素のジョイントコーディングをサポートするためのハイレベルシンタックス、
・テクスチャビュー構成要素と深度ビュー構成要素との間の動きベクトル予測、および、深度ビュー動きが、関連付けられたテクスチャビュー動きから採用されるモード。

本開示はまた、異なる解像度におけるビュー構成要素間の予測と、テクスチャビュー構成要素から対応する深度ビュー構成要素へのスライスヘッダの予測とを可能にするツールなど、他のツールについても説明する。テクスチャビュー構成要素および深度ビュー構成要素は、アクセスユニット中の１つのビューのコード化ピクチャである、ビュー構成要素を形成し得る。したがって、技法は、説明するＩＶＭＰモードに従った動き情報の採用、または、テクスチャビューに対する深度ビューについての動き情報の（デルタを含む）予測を可能にし得る。両方のツールは、コーディングの柔軟性を可能にし得るが、最良の圧縮は、これらのツールをある程度まで制限することによって達成され得る。たとえば、本明細書で説明するＩＶＭＰモードは、非アンカーピクチャに制限され得る。

本書の全体を通して、ＡＶＣは、Ｈ．２６４／ＡＶＣハイプロファイルを指す。任意の他のＨ．２６４／ＡＶＣプロファイルまたは修正が言及されている場合、その修正またはプロファイル名が明示的に指定されるようになる。たとえば、Ｈ．２６４／ＭＶＣまたはＭＶＣは、Ｈ．２６４／ＡＶＣのマルチビュー拡張を指す。しかしながら、Ｈ．２６４／ＡＶＣのいかなる修正またはプロファイルもＡＶＣファミリーに属しており、したがって、提案するコーデックは、ＭＶＣステレオハイプロファイルと互換性がある場合、それはＡＶＣステレオハイプロファイルとも互換性がある。

次に、コーデック記述を提供する。このセクションでは、提案する３ＤＶＣコーデックについて、２つの態様であるハイレベルフレームワークおよび低レベルコーディング技法から説明する。潜在的に異なる適用例に対応する２ビュー構成と３ビュー構成とを有し得る３ＤＶフォーマットを定義することが望ましい場合、３ビューの場合の技法は、２ビューの場合の技法のスーパーセットを形成し得る。したがって、このセクションでは、両方の場合に適用可能なハイレベルフレームワークについて第１に説明し、後に３ビューの場合に適用可能である２ビューの場合の技法のコーデック記述が続き、次いで、３ビューの場合のみに使用される技法について説明する。

ハイレベルフレームワークは、以下の定義を使用し得る。

深度ビュー構成要素中のコード化ＶＣＬＮＡＬユニットは、特に深度ビュー構成要素のための新しいタイプのコード化スライス拡張として、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ２１を割り当てられ得る。

次に、ビットストリーム順序について説明する。各ビュー構成要素において、深度ビュー構成要素の（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ２１をもつ）いかなるコード化スライスＮＡＬユニットも、テクスチャビュー構成要素のすべてのコード化スライスＮＡＬユニットの後にくる必要があり得る。簡単のために、本開示は、深度ビュー構成要素のコード化スライスＮＡＬユニットを、深度ＮＡＬユニットと称する。

深度ＮＡＬユニットは、２０に等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅをもつＮＡＬユニットと同じＮＡＬユニットヘッダ構造を有する。図４は、１つのアクセスユニットの内部のビュー構成要素のＶＣＬＮＡＬユニットの例示的なビットストリーム順序を示す。

図４に示すように、１つの例示的な３Ｄビデオコーデックでは、アクセスユニットは、複数のビュー構成要素を含み、その各々が、１つのテクスチャビュー構成要素および１つの深度ビュー構成要素からなる。０に等しいビュー順序インデックス（ＶＯＩｄｘ）をもつ、ベースビューのテクスチャビュー構成要素は、（１４に等しいＮＡＬユニットタイプをもつ）１つのプレフィックスＮＡＬユニットと、（たとえば、１または５に等しいＮＡＬユニットタイプをもつ）１つまたは複数のＡＶＣＶＣＬＮＡＬユニットとを含む。他のビュー中のテクスチャビュー構成要素は、（２０に等しいＮＡＬユニットタイプをもつ）ＭＶＣＶＣＬＮＡＬユニットのみを含む。ベースビューと非ベースビューの両方において、深度ビュー構成要素は、２１に等しいＮＡＬユニットタイプをもつ深度ＮＡＬユニットを含む。いかなるビュー構成要素においても、深度ＮＡＬユニットは、復号／ビットストリーム順序において、テクスチャビュー構成要素のＮＡＬユニットの後にくる。

２ビューの場合、本開示は、左ビューと右ビューの両方に対してハーフ解像度符号化を採用し得る。提案するコーデックの特性は、以下を含み得る。

・ハーフ水平またはハーフ垂直空間解像度、
・各ビューのテクスチャビュー構成要素および深度ビュー構成要素のための同じ解像度、
・ＡＶＣハイプロファイル互換ハーフ解像度ベースビュー（テクスチャのみ）、
・ＡＶＣステレオハイプロファイル互換ハーフ解像度立体ビュー（テクスチャのみ）、
・ベースビューの深度ビュー構成要素から非ベースビューの深度ビュー構成要素へのビュー間予測、
・ビュー構成要素の内部のテクスチャから深度の予測。

ハーフ空間解像度ＭＶＣに、以下で言及し、以下のテーブル１で説明する。すべてのシーケンスは、ハーフ空間解像度でコーディングされ得る。Ｈ．２６４／ＡＶＣフレーム互換コーディングと比較して、ハーフ空間解像度ＭＶＣは、より効率的であり、以下の要件を満たすためにより好都合である。

・前方互換性：そのような２ビュー３ＤＶＣビットストリームは、ＭＶＣサブビットストリームを含み、ＭＶＣサブビットストリームは、ＡＶＣサブビットストリームをさらに含む。したがって、提案するコーデックは、この要件、特に、「このモードに準拠するすべての圧縮ビットストリームは、既存のＡＶＣデコーダが、ビットストリームからのモノビューおよびステレオビューからサンプルを再構成することを可能にするものとする」を満たす。

・ステレオ／モノ互換性：ＶＣＬＮＡＬユニットは、単に、ＭＶＣまたはＡＶＣサブビットストリームを得るためにＮＡＬユニットタイプをチェックすることによって、抽出され得る。したがって、提案するコーデックは、この要件、特に、「圧縮データフォーマットは、ステレオ出力およびモノ出力のためのビットストリームの簡単な抽出を可能にするモードを含み、ステレオビデオの左ビューおよび右ビューからのサンプルの高忠実度の再構成をサポートするものとする」を満たす。

ハーフ空間解像度シーケンスは、テクスチャシーケンスと深度シーケンスの両方について、ＭＰＥＧ１３タップのダウンサンプリングフィルタ（［２，０，−４，−３，５，１９，２６，１９，５，−３，−４，０，２］／６４）によって取得され得る。より良い品質を達成するために、ダウンサンプリングは、水平または垂直のいずれかに適用され得る。優位な水平高周波成分をもつシーケンスでは、ハーフ垂直解像度が使用され得る。いくつかの例では、ただ１つのシーケンスが、このカテゴリー、すなわち「Ｐｏｚｎａｎ＿Ｈａｌｌ２」に属すると考えられる。他のシーケンスは、優位な垂直高周波成分を有すると考えられ、ハーフ水平解像度シーケンスを取得するために、水平ダウンサンプリングが適用される。

テクスチャおよび深度のための対称解像度が使用され得る。深度ビュー構成要素は、同じビューのテクスチャビュー構成要素と同じ解像度をもつ８ビットモノシーケンスとしてコーディングされ得る。そのような設定では、テクスチャビュー構成要素から深度ビュー構成要素への予測は、たとえば、マクロブロック（ＭＢ）中のピクセルまたは動きベクトルなどをスケーリングすることなしに実行され得る。

深度ビュー構成要素についてのビュー間予測がサポートされ得る。深度ビュー構成要素は、ＭＶＣにおけるビュー間予測と同じ方法で、同じアクセスユニット中の他の深度ビュー構成要素によって予測され得る。深度ビュー構成要素は、サブセットシーケンスパラメータセット（ＳＰＳ）を参照し、サブセットＳＰＳは、ＳＰＳＭＶＣ拡張においてシグナリングされるビュー依存性を有する。

典型的には、深度ビュー構成要素の予測依存性は、図６に示すように、テクスチャビュー構成要素の同じビュー依存性を共有する。いくつかのシーケンスは、深度ビュー間のビュー間予測から利益を得られないことにも留意されたい。したがって、深度ビューについてのビュー間予測は、そのような場合には単に無効にされ得る。図６は、３ＤＶＣコーデックの予測構造を示す。（クロスハッチングを用いて示す）深度ビュー構成要素は、（陰影なしで示す）テクスチャビュー構成要素と同じ予測構造を有する。

したがって、深度ビューについてのビュー間予測を無効または有効にするために、フラグ（ｄｉｓａｂｌｅ＿ｄｅｐｔｈ＿ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇ）がＳＰＳ中でシグナリングされ得る。２ビューの場合と３ビューの場合の両方のためのより詳細なＳＰＳ設計については、以下でより詳細に説明する。ビュー間予測から利益を得ることができる深度マップシーケンスでは、深度ビュー構成要素は、図６に示すように、テクスチャビュー構成要素と同じインター予測構造とビュー間予測構造とを有する。

図７は、深度ビュー構成要素についてのビュー間予測を可能にしない、３ＤＶＣコーデックの予測構造を示す。陰影なしで図７に示す構成要素は、テクスチャビューを示し、クロスハッチ陰影は、深度ビューを示す。図７に示すように、ビュー間予測は、テクスチャビュー構成要素に対して有効にされ得るが、深度ビュー構成要素に対しては完全に無効にされ得る。そのような場合、深度ビュー構成要素は、対応するテクスチャビュー構成要素とは異なるスライスタイプを有し得る。

次に、テクスチャから深度への動き予測について説明する。テクスチャビュー構成要素、およびその関連付けられた深度ビュー構成要素は、同様のオブジェクトシルエットを有するので、同様のオブジェクト境界と動きとを有し、したがって、それらの動きフィールドに冗長性がある。

本開示によれば、テクスチャビュー構成要素から、関連付けられた深度ビュー構成要素への動き予測は、提案するコーデックにおける新しいモードとして有効にされ得る。いくつかの例では、内部ビュー動き予測（ＩＶＭＰ）モードが、深度ビュー構成要素においてのみ、インターコード化ＭＢに対して有効にされる。ＩＶＭＰモードでは、テクスチャビュー構成要素中のコロケートＭＢのｍｂ＿ｔｙｐｅと、ｓｕｂ＿ｍｂ＿ｔｙｐｅと、参照インデックスと、動きベクトルとを含む動き情報が、同じビューの深度ビュー構成要素によって再使用される。各ＭＢ中で、それがＩＶＭＰモードを使用するかどうかを示すために、フラグがシグナリングされ得る。図５に一致して、フラグは、深度ビューの４番目のピクチャについて真であり得、（４番目のピクチャと標示された）テクスチャビューの４番目のピクチャ中のコロケートＭＢの動きベクトルが、深度ビュー構成要素中のＭＢのために再使用される。いくつかの例では、ＩＶＭＰモードは、非アンカーピクチャのみに適用される。

次に、スライスヘッダ予測について説明する。各ビュー構成要素について、深度ビュー構成要素のスライスヘッダとテクスチャビュー構成要素のスライスヘッダとの間に冗長性があり得る。したがって、テクスチャビュー構成要素のスライスヘッダが与えられれば、同じアクセスユニットの同じビュー内の深度ビュー構成要素は、そのスライスヘッダ情報の大部分がすでに判断されている。

本開示によれば、深度ビュー構成要素は、対応するテクスチャビュー構成要素のスライスヘッダシンタックス要素の大部分を共有する。様々なシンタックス要素は、ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄと、ｓｌｉｃｅ＿ｑｐ＿ｄｅｌｔａと、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１、および参照ピクチャリスト修正シンタックステーブルを含む、参照ピクチャリスト構成に関する潜在的なシンタックス要素とを含み得る。

深度ビュー構成要素のスライスヘッダは、スライスヘッダ深度拡張においてシグナリングされ得る。ｐｒｅｄ＿ｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄｅｐｔｈ＿ｉｄｃは、シーケンスパラメータセット中でシグナリングされ得ることに留意されたい。いくつかの例では、エンコーダは、常に１になるようにそれを設定し得る。

例示的なスライスヘッダ深度拡張シンタックスは、以下のテーブル１の例に準拠し得る。

次に、３ビューの場合について説明する。本開示の技法は、左ビューと右ビューの両方に対してハーフ解像度符号化と、中央ビューに対してフル解像度とを採用し得る。２ビューの場合に有効にされるコーディング方法は、３ビューの場合のコーデックについてもサポートされ得る。コーデックは、３ビューの場合について以下の特性を含み得る。

・異なるビューにおける非対称空間解像度、
・低解像度ビューから高解像度ビューへのビュー間予測、
・低解像度ビューのテクスチャビュー構成要素を含むサブビットストリームは、Ｈ．２６４／ＭＶＣステレオハイプロファイルと互換性がある。

・高解像度ビューについてのビュー間予測依存性のシグナリング。

次に、非対称３ＤＶＣコーデックにおけるビュー間予測について説明する。再構成された低解像度ビューから高解像度ビューへの予測は、テクスチャビュー構成要素間と深度ビュー構成要素間の両方で可能にされ得る。

より詳細には、３ビューの場合、左ビューおよび右ビューはハーフ解像度でコーディングされ得、中央ビューはフル解像度でコーディングされ得る。ハーフ解像度ビュー構成要素からフル解像度（テクスチャまたは深度）ビュー構成要素へのビュー間予測が生じるとき、ハーフ解像度ビュー構成要素の復号ピクチャは、ビュー間予測のために使用されるべきである場合、ＡＶＣ６タップフィルタ［１，−５，２０，２０，−５，１］／３２を用いてアップサンプリングされる。この場合、（出力のために必要とされる）低解像度ピクチャと、またアップサンプリングされたピクチャの両方が、バッファ中で時間的に共存する必要があり得る。左ビューおよび右ビューからのアップサンプリングされたピクチャは、次いで、同じアクセスユニット中の中央ビューのビュー構成要素の参照ピクチャリストに入れられ得る。

非対称ビュー間予測を図８に示し、左ビュー（ＶＬ）と右ビュー（ＶＲ）の両方が半分の幅をもつ。ビュー依存性は、左ビュー（ＶＬ）および右ビュー（ＶＲ）が中央ビュー（ＶＣ）のためのビュー間参照として使用されることを可能にするので、左ビュー（ＶＬ）および右ビュー（ＶＲ）はともに、中間ピクチャへとアップサンプリングされる。

簡潔のために、（テクスチャのみを考える場合）ＭＶＣ互換性のある低解像度ビューは、「ＭＶＣビュー」がテクスチャ部分のみを指すか、テクスチャ部分と深度部分の両方を指すかにかかわらず、ＭＶＣビューと呼ばれる。フル解像度をもつ他のビューは、追加のビューと呼ばれる。そのため、３ビューの場合、それらは２つのＭＶＣビューおよび１つの追加のビューである。各ＭＶＣビューは、追加のビューの解像度の半分である同じ解像度におけるテクスチャと深度の両方を含む。

次に、シーケンスパラメータセット設計について説明する。本開示のいくつかの態様では、新しいＳＰＳ拡張が導入され得る。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｄａｔａ（）中に示されたプロファイルが３ＤＶに関係する場合、新しいＳＰＳ拡張がサブセットＳＰＳに追加される。本開示によれば、２つの異なる場合について、２つの潜在的なプロファイル、「３ＤＶプロファイル」と「非対称３ＤＶプロファイル」とが検討される。言い換えれば、３ＤＶプロファイルが２ビューの場合に適用され、非対称３ＤＶプロファイルが３ビューの場合に適用される。

ＭＶＣでは、新しいシーケンスレベルパラメータセット、すなわち、ＳＰＳＭＶＣ拡張が、サブセットＳＰＳ中で導入され、シグナリングされ得る。ＭＶＣは、新たに追加されたプロファイルのいずれにおいても、基礎仕様と見なされるので、サブセットＳＰＳは、ＳＰＳＭＶＣ拡張に加えて、シーケンスパラメータセット３ＤＶＣ拡張をシグナリングするようにさらに拡張される。

１つの提案するコーデックでは、新しいＳＰＳ拡張、すなわち、シーケンスパラメータセット３ＤＶＣ拡張は、非対称３ＤＶプロファイルのための高解像度ビューについてのビュー間依存性、ならびに、３ＤＶプロファイルと非対称３ＤＶプロファイルの両方に適用可能である深度ビュー構成要素についてのビュー間依存性をさらにシグナリングするための、シンタックスを含む。

３ＤＶ関連の適用例では、他のシンタックス要素、たとえば、カメラパラメータおよび深度範囲および／または深度量子化に関するものもまた、ＳＰＳ中でシグナリングされ得る。しかしながら、１つの提案するコーデックでは、この情報は、利用可能であると見なされ得、したがって、コード化ビットストリーム中で送信されなくてもよい。

テーブル２は、サブセットシーケンスパラメータセットローバイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）シンタックスの例を示す。

テーブル３は、シーケンスパラメータセット３ＤＶＣ拡張シンタックスの例を示す。

１つの提案する３ＤＶＣコーデックでは、カメラパラメータならびに深度範囲は、復号ビューに標準的影響を及ぼさないので、ビットストリーム中に含まれなくてもよい。しかしながら、カメラパラメータならびに深度範囲は、ビュー合成、および、たとえば、特定のモードとしてビュー合成を使用する潜在的なコーディングツールのために有用であり得る。カメラパラメータまたは深度範囲が、特定のコーディングツールのために必要とされる場合、カメラパラメータまたは深度範囲は、ＳＰＳ、ピクチャパラメータセット（ＰＰＳ）、または、さらには、そのような情報がフレームごとの単位で変わり得る場合、新しいタイプのパラメータセット、すなわち、ビューパラメータセット（ＶＰＳ）などのパラメータセット内で、標準的かつ強制的な方法で送信され得る。カメラパラメータまたは深度範囲が、いかなる送信されたテクスチャまたは深度の復号のためにも必要でない場合、カメラパラメータまたは深度範囲は、ＳＥＩメッセージ（シーケンスレベルまたはピクチャレベル）中でシグナリングされ得る。

このセクションは、上記の情報がビットストリーム中でどのようにシグナリングされ得るかについての理解を与える。カメラパラメータおよび深度範囲のシグナリングは、ソフトウェアにおいて実施され得るが、ビットストリームの生成のために利用可能にされなくてもよい。

テーブル４は、ＳＰＳ３ＤＶＣ拡張におけるカメラパラメータおよび深度範囲の例を示す。

このカメラパラメータシンタックステーブルでは、浮動小数点値Ｖは、Ｖ＝Ｉ＊１０^Pであるような、小数点の前または後の桁数であるそれの精度Ｐと、整数値Ｉとを用いて表され得る。Ｖの符号は、Ｉの符号と同じであり得る。そのような提案する表現は、カメラパラメータおよび深度範囲のために十分に正確であり得、それは浮動小数点値を解析し、構成することが比較的容易であり得る。

本開示では、ＣｆＰに示されるように「カメラのジオメトリおよび色の不整合を回避するために、ソースビデオデータが訂正されるべきである」という要件が与えられれば、複数のビューが、同じ内部パラメータと、水平変換（horizontal translation）を除いて外部パラメータの大部分とを共有すると仮定され得る。

テーブル５およびその後に続く段落は、例示的なカメラパラメータシンタックスおよびセマンティクスを示す。

テーブル５では、１に等しいｃａｍ＿ｐａｒａｍ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、カメラパラメータがこのＳＰＳ中でシグナリングされることを示し得る。０に等しいｃａｍ＿ｐａｒａｍ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、カメラパラメータがこのＳＰＳ中でシグナリングされないことを示し得る。

テーブル５では、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｐｒｅｃｉｓｉｏｎは、すべてのカメラのｘ座標焦点距離およびｙ座標焦点である、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘおよびｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｙの値の精度を指定する。

テーブル５では、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘ＿Ｉは、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘの値の整数部分を指定する。

ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘ＝ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘ＿Ｉ＊１０^{focal_length_precision}
テーブル５では、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｙ＿Ｉ＿ｄｉｆｆ＿ｘ＋ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘ＿Ｉは、ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｙの値の整数部分を指定する。

ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｙ＝（ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｘ＿Ｉ+ｆｏｃａｌ＿ｌｅｎｇｔｈ＿ｙ＿Ｉ＿ｄｉｆｆ＿ｘ）＊１０^{focal_length_precision}
テーブル５では、ｐｒｉｎｃｉｐａｌ＿ｐｒｅｃｉｓｉｏｎは、すべてのカメラのｘ座標主点およびｙ座標主点である、ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘおよびｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｙの値の精度を指定する。

テーブル５では、ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘ＿Ｉは、ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘの値の整数部分を指定する。

ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘ＝ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘ＿Ｉ＊１０^{principal_precision}
テーブル５では、ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｙ＿Ｉ＿ｄｉｆｆ＿ｘ＋ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘは、ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｙの値の整数部分を指定する。

ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｙ＝
（ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｘ＿Ｉ＋ｐｒｉｎｃｉｐａｌ＿ｐｏｉｎｔ＿ｙ＿Ｉ＿ｄｉｆｆ＿ｘ）＊１０^{principal_precision}
各カメラの回転行列Ｒは、次のように表され得る。

テーブル５では、ｒｏｔａｔｉｏｎ＿ｋｌ＿ｈａｌｆ＿ｐｉは、ｘｙ、ｙｚ、またはｘｚに等しいｋｌをもつ回転行列Ｒの対角要素を示し、Ｒ_kl＝（−１）^{rotation_kl_half_pi}である。０に等しいこのフラグは、Ｒ_kl＝１を示し、１に等しいこのフラグは、Ｒ_kl＝−１を示す。

テーブル５では、ｔｒａｎｓｌａｔｉｏｎ＿ｐｒｅｃｉｓｉｏｎは、すべてのビューの変換（translation）の値の精度を指定する。変換値の精度は、このＳＰＳを参照するビューのすべての変換値に適用される。

テーブル５では、ｎｕｍＶｉｅｗｓＭｉｎｕｓ１は、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１＋ｎｕｍ＿ａｄｄ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１＋１として導出される。

テーブル５では、ａｎｃｈｏｒ＿ｖｉｅｗ＿ｉｄは、他のビューの変換を計算するためのアンカーとしてその変換が使用される、ビューのｖｉｅｗ＿ｉｄを指定する。

テーブル５では、１に等しいｚｅｒｏ＿ｔｒａｎｓｌａｔｉｏｎ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ａｎｃｈｏｒ＿ｖｉｅｗ＿ｉｄに等しいｖｉｅｗ＿ｉｄをもつビューの変換が０であることを示し、０に等しいこの値は、ａｎｃｈｏｒ＿ｖｉｅｗ＿ｉｄに等しいｖｉｅｗ＿ｉｄをもつビューの変換がシグナリングされることを示す。

テーブル５では、ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉは、アンカービューの変換の整数部分を指定する。アンカービューの変換を、ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗと示す。ｚｅｒｏ＿ｔｒａｎｓｌａｔｉｏｎ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが０に等しいとき、ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗは０に等しく、そうでない場合、変換は次のように計算される。

テーブル５では、
ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗ＝ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ＊１０^{translation_precision}
テーブル５では、ｔｒａｎｓｌａｔｉｏｎ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ［ｉ］＋ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉは、ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ＿Ｉ［ｉ］として示された、ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューの変換の整数部分を指定する。

ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューの変換を、ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ［ｉ］と示す。

ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ［ｉ］＝
（ｔｒａｎｓｌａｔｉｏｎ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ［ｉ］＋ｔｒａｎｓｌａｔｉｏｎ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ）＊１０^{translation_precision}
テーブル６およびその後に続く段落は、例示的な深度範囲シンタックスおよびセマンティクスを示す。

テーブル６では、１に等しいｄｅｐｔｈ＿ｒａｎｇｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、すべてのビューについての深度範囲がこのＳＰＳ中でシグナリングされることを示し、０に等しいｄｅｐｔｈ＿ｒａｎｇｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、深度範囲がこのＳＰＳ中でシグナリングされないことを示す。

テーブル６では、ｚ＿ｎｅａｒ＿ｐｒｅｃｉｓｉｏｎは、ｚ＿ｎｅａｒ値の精度を指定する。このＳＰＳにおいて指定されているｚ＿ｎｅａｒの精度は、このＳＰＳを参照するビューのすべてのｚ＿ｎｅａｒ値に適用される。

テーブル６では、ｚ＿ｆａｒ＿ｐｒｅｃｉｓｉｏｎは、ｚ＿ｆａｒ値の精度を指定する。このＳＰＳにおいて指定されているｚ＿ｆａｒの精度は、このＳＰＳを参照するビューのすべてのｚ＿ｆａｒ値に適用される。

テーブル６では、０に等しいｄｉｆｆｅｒｅｎｔ＿ｄｅｐｔｈ＿ｒａｎｇｅ＿ｆｌａｇは、すべてのビューの深度範囲が同じであり、両端値を含むｚ＿ｎｅａｒおよびｚ＿ｆａｒの範囲内であることを示す。１に等しいｄｉｆｆｅｒｅｎｔ＿ｄｅｐｔｈ＿ｒａｎｇｅ＿ｆｌａｇは、すべてのビューの深度範囲が異なり得、すなわち、ｚ＿ｎｅａｒおよびｚ＿ｆａｒがアンカービューのための深度範囲であり、ｚ＿ｎｅａｒ［ｉ］およびｚ＿ｆａｒ［ｉ］が、ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューの深度範囲として、このＳＰＳにおいてさらに指定されることを示す。

テーブル６では、ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒは、ｚ＿ｎｅａｒの値の整数部分を指定する。ｚ＿ｎｅａｒ＝ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒ＊１０^{z_near_precision}
テーブル６では、ｚ＿ｆａｒ＿ｉｎｔｅｇｅｒは、ｚ＿ｆａｒの値の整数部分を指定する。ｚ＿ｆａｒ＝ｚ＿ｆａｒ＿ｉｎｔｅｇｅｒ＊１０^{z_far_precision}
テーブル６では、ｚ＿ｎｅａｒ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ＋ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒは、ｚ＿ｎｅａｒ＿Ｉ［ｉ］として示された、ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューの最も近い深度値の整数部分を指定する。

ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューのｚ＿ｎｅａｒを、ｚ＿ｎｅａｒ［ｉ］と示す。

ｚ＿ｎｅａｒ［ｉ］＝（ｚ＿ｎｅａｒ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ［ｉ］＋ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒ）＊１０^{z_near_precision}
テーブル６では、ｚ＿ｆａｒ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ＋ｚ＿ｆａｒ＿Ｉｎｔｅｇｅｒは、ｚ＿ｆａｒ＿Ｉ［ｉ］として示された、ｖｉｅｗ＿ｉｄ［ｉ］に等しいｖｉｅｗ＿ｉｄをもつビューの最も遠い深度値の整数部分を指定する。

ｚ＿ｆａｒ［ｉ］＝（ｚ＿ｆａｒ＿ｄｉｆｆ＿ａｎｃｈｏｒ＿ｖｉｅｗ＿Ｉ［ｉ］＋ｚ＿ｆａｒ＿ｉｎｔｅｇｅｒ）^*１０^{z_far_precision}
テーブル７は、例示的なビューパラメータセットＲＢＳＰシンタックスを示す。

このビューパラメータセットＲＢＳＰを含むＮＡＬユニットは、新しいＮＡＬユニットタイプ、たとえば、１６を割り当てられ得る。

テーブル８およびその後に続く段落は、例示的なビューパラメータセットシンタックスおよびセマンティクスを示す。

深度範囲およびカメラの変換はピクチャ単位で変化し得る。更新された深度範囲またはカメラパラメータは、現在のＶＰＳに続く新しいＶＰＳが、関係するビューについてのそれらの値を更新するまで、ビットストリーム中の現在のアクセスユニットのビュー構成要素と後続のビュー構成要素とに適用可能であり得る。

簡単のために、シンタックス要素のセマンティクスは与えられない。各ビューの変換または深度範囲について、新しい値と、（ｓｅｑ＿ｐａｒａ＿ｓｅｔ＿ｉｄに等しい識別子をもつ）ＳＰＳ中でシグナリングされた値との間の差分の整数部分は、このＶＰＳ中でシグナリングされ得る。変換および深度範囲の更新値は、次のように計算され得る。

ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ［ｉ］＝
（ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ＿ｉｎｔｅｇｅｒ［ｉ］＋ｔｒａｎｓｌａｔｉｏｎ＿ｕｐｄａｔｅ＿ｖｉｅｗ＿Ｉ［ｉ］）＊１０^{translation_precision}
ｚ＿ｎｅａｒ［ｉ］＝
（ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒ［ｉ］＋ｚ＿ｎｅａｒ＿ｕｐｄａｔｅ＿ｖｉｅｗ＿Ｉ［ｉ］）＊１０^{z_near_precision}
ｚ＿ｆａｒ［ｉ］＝（ｚ＿ｆａｒ＿ｉｎｔｅｇｅｒ［ｉ］＋ｚ＿ｆａｒ＿ｕｐｄａｔｅ＿ｖｉｅｗ＿Ｉ［ｉ］）＊１０^{z_far_precision}
ただし、ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ［ｉ］、ｚ＿ｎｅａｒ［ｉ］、およびｚ＿ｆａｒ［ｉ］の値の整数部分である、ｔｒａｎｓｌａｔｉｏｎ＿ｖｉｅｗ＿ｉｎｔｅｇｅｒ［ｉ］、ｚ＿ｎｅａｒ＿ｉｎｔｅｇｅｒ［ｉ］、およびｚ＿ｆａｒ＿ｉｎｔｅｇｅｒ［ｉ］は、ＳＰＳ中のシグナリングに基づいて計算される。

本開示の技法のうちの１つまたは複数は、圧縮および／または品質に関して、コーディングの改善を提供するために使用され得る。符号化の時間および複雑さもまた、本開示の技法のうちの１つまたは複数を使用して改善され得る。復号の時間および複雑さもまた改善され得る。加えて、エンコーダおよびデコーダにおけるメモリ使用量が、他の技法と比較して改善または低減され得る。

いくつかの例では、エンコーダとデコーダの両方が、ＪＭＶＣエンコーダおよびデコーダと同じレベルのメモリ消費量を有し得る。したがって、メモリ使用量は、たとえば、アクセスユニット中の、ビュー構成要素の数に比例すると考えられ得る。深度ビュー構成要素が、同じ数のビューとともに、常に４：０：０として記憶される場合、提案する解決策は、エンコーダまたはデコーダのいずれかのためにＪＭＶＣによって使用されるメモリのほぼ５／３（約６７％増加）を消費し得る。たとえば、深度マップを閲覧し、それらをビュー合成のために使用する動作を簡単にするために、エンコーダおよびデコーダはなお、４：２：０クロマサンプリングフォーマットにおける深度ファイルを取り、出力し得ることに留意されたい。

次に、デコーダの複雑さの特性について説明する。いくつかの例では、本開示の技法に一致するエンコーダとデコーダの両方が、ＪＭＶＣエンコーダおよびデコーダと同じレベルの複雑さを有し得る。ＪＭＶＣと比較したとき、本開示に一致するコーデックの計算複雑さは、ビューの数および各ビューの空間解像度に関係し得る。言い換えれば、本開示に一致するコーデックは、本開示に一致するコーデックとＪＭＶＣコーデックの両方が同じピクセル数をもつ同じビデオを取る限り、ＪＭＶＣコーデックと同じ計算量を必要とし得る。

デコーダ側では、標準的ピクチャレベルアップサンプリングが、非対称３ＤＶプロファイルのために必要とされ得る。しかしながら、そのような復号プロセスは、高解像度ビュー構成要素の復号のための他の復号プロセスよりも複雑でないと考えられ得るので、複雑さの特性はなお、たとえば、毎秒いくつのＭＢが処理されるべきであるかによって示され得るようになる。

本明細書で説明する技法に一致するエンコーダは、ビューが１つずつ符号化される現在のＪＭＶＣエンコーダ方式に従い得る。各ビューの内部で、テクスチャシーケンスが第１に符号化され、深度シーケンスが次いで符号化される。

テクスチャビュー構成要素符号化中に、ＩＶＭＰモードが有効にされるとき、各テクスチャビュー構成要素の動きフィールドが動きファイルに書き込まれ、その名前が構成ファイル中で指定され得る。同じビューの関連付けられた深度シーケンスを符号化するとき、動きファイルが参照のために読み取られる。

エンコーダは、以下の追加の項目とともにＪＭＶＣと同じ構成を使用し得る。

ＭｏｔｉｏｎＦｉｌｅ
Ｓｔｒｉｎｇ，ｄｅｆａｕｌｔ： “ｍｏｔｉｏｎ”
生成されるべき動きシーケンスの（．ｄａｔなしの）ファイル名を指定する。このシーケンスは、ＩＶＭＰモードのために提供される。ｍｏｔｉｏｎ＿０．ｄａｔ、ｍｏｔｉｏｎ＿１．ｄａｔなどは、自動的にエンコーダによって作成されることになる。

ＨａｌｆＳｉｚｅＤｉｍｅｎｓｉｏｎ
ＵｎｓｉｇｎｅｄＩｎｔ，ｄｅｆａｕｌｔ：０
非対称空間解像度が使用されるかどうか、および、それが使用される場合、サブサンプリング寸法を示す。以下の値がサポートされる：
０−すべてのビューが、同じ空間解像度で符号化される。

１−非対称空間解像度が使用され、ハーフ解像度ビューは、他のビューの半分の幅を有する。

２−非対称空間解像度が使用され、ハーフ解像度ビューは、他のビューの半分の高さを有する。

ＢａｓｉｓＱＰ＿ｔｅｘｔｕｒｅ
Ｄｏｕｂｌｅ，ｄｅｆａｕｌｔ：２６
ハーフ空間解像度をもつテクスチャビュー構成要素の基本量子化パラメータを指定する。

ＢａｓｉｓＱＰ＿ｄｅｐｔｈ
Ｄｏｕｂｌｅ，ｄｅｆａｕｌｔ：２６
ハーフ空間解像度をもつ深度ビュー構成要素の基本量子化パラメータを指定する。

ＢａｓｉｓＱＰ＿ｔｅｘｔｕｒｅ＿ｄｅｌｔａ
ＵｎｓｉｇｎｅｄＩｎｔ，ｄｅｆａｕｌｔ：０
ハーフ空間解像度をもつテクスチャビュー構成要素の基本量子化パラメータと比較して、フル空間解像度をもつテクスチャビュー構成要素の基本量子化パラメータのための基本量子化パラメータオフセットを指定する。フル空間解像度をもつテクスチャビュー構成要素の基本量子化パラメータは、ＢａｓｉｓＱＰ＿ｔｅｘｔｕｒｅ（フル空間解像度）＝ＢａｓｉｓＱＰ＿ｔｅｘｔｕｒｅ＋ＢａｓｉｓＱＰ＿ｔｅｘｔｕｒｅ＿ｄｅｌｔａによって計算される。

ＢａｓｉｓＱＰ＿ｄｅｐｔｈ＿ｄｅｌｔａ
ＵｎｓｉｇｎｅｄＩｎｔ，ｄｅｆａｕｌｔ：０
ハーフ空間解像度をもつ深度ビュー構成要素の基本量子化パラメータと比較して、フル空間解像度をもつ深度ビュー構成要素の基本量子化パラメータのための基本量子化パラメータオフセットを指定する。フル空間解像度をもつ深度ビュー構成要素の基本量子化パラメータは、ＢａｓｉｓＱＰ＿ｄｅｐｔｈ（フル空間解像度）＝ＢａｓｉｓＱＰ＿ｄｅｐｔｈ＋ＢａｓｉｓＱＰ＿ｄｅｐｔｈ＿ｄｅｌｔａによって計算される。

ＮｏＤｅｐｔｈＩｎｔｅｒＶｉｅｗＦｌａｇ
Ｆｌａｇ（０ｏｒ１），ｄｅｆａｕｌｔ：０
ビュー間予測が任意の深度ビュー構成要素に対して有効にされるかどうかを指定する。ＮｏＤｅｐｔｈＩｎｔｅｒＶｉｅｗＦｌａｇが０に等しいとき、ビュー間予測が有効にされる。ＮｏＤｅｐｔｈＩｎｔｅｒＶｉｅｗＦｌａｇが１に等しいとき、ビュー間予測が無効にされる。

ＨａｌｆＲｅｓ
Ｆｌａｇ（０ｏｒ１），ｄｅｆａｕｌｔ：０
この値は、ビュー依存性部分中でシグナリングされた各参照ビューのプロパティの一部として、Ｖｉｅｗ＿ＩＤ値に関連付けられる。

Ｖｉｅｗ＿ＩＤによって識別されたビューがハーフ空間解像度であるかどうかを指定する。ＨａｌｆＲｅｓが０に等しいとき、それはフル空間解像度ビューである。ＨａｌｆＲｅｓが１に等しいとき、それはハーフ空間解像度ビューである。

エンコーダは、ビットストリームを生成するために使用され得る。例示的なエンコーダ呼出しを、以下の例に示す。

ここでは、ｍｃｆｇは、構成ファイルのファイル名を表す。構成ファイルは、エンコーダ呼出しごとに指定され得る。要素ｖｉｅｗ＿ｉｄは、符号化されるべきであるビューを表す。要素ｃｏｍｐｏｎｅｎｔ＿ｉｄｘは、符号化されるべき現在のシーケンスが、特定のビューのテクスチャであるか（ｃｏｍｐｏｎｅｎｔ＿ｉｄｘが１に等しいとき）、深度であるか（ｃｏｍｐｏｎｅｎｔ＿ｉｄｘが０に等しいとき）を示す。エンコーダは、符号化されるべきである各ビューのビュー構成要素ごとに実行され得る。

デコーダは、ＪＭＶＣデコーダと同様であり得、ビューごとに深度シーケンスをも復号および出力する主要な修正がある。非対称３ＤＶプロファイルにおいて、追加のビュー（中央）の予測のためにＭＶＣビュー（左または右）を高解像度に変換するために、アップサンプリングが必要とされる。

アセンブラは、重複パラメータセットＮＡＬユニットを破棄するための極めて小さい修正を有し得、複雑さはＪＭＶＣアセンブラと同じである。

ビュー合成器に関して、ＪＭＶＣに関係する修正は必要とされなくてもよい。

提案のすべての「ものとする（shall）」要件を満たすことができる、Ｈ．２６４／ＭＶＣベースの３ＤＶＣコーデックについてのいくつかの特徴について説明しており、これらの特徴は、比較的少量の追加のコーディング方法とともに、良好なコーディング性能を提供し得る。これらの方法は、テクスチャおよび深度のジョイントコーディングと、ビュー構成要素の内部のテクスチャから深度への予測と、非対称空間解像度をもつテクスチャビュー構成要素または深度ビュー構成要素間のビュー間予測とのための、ハイレベルフレームワークを含む。

ＭＶＣベースの３ＤＶコーデックは、短期の市場のニーズのために標準化され得、本開示の提案する特徴は、そのような３ＤＶコーデックの参照ソフトウェアおよび作業草案の基礎であり得る。

図９は、本開示に一致する、ビデオエンコーダによって実行され得る技法を示す流れ図である。他のビデオエンコーダも使用され得るが、図９について、図２のビデオエンコーダ２０の観点から説明する。図９に示すように、予測モジュール４１が、３Ｄビデオ、たとえば、３Ｄ表現を表すビデオブロックを受信する（９０１）。３Ｄビデオは、テクスチャビュービデオブロックと、関連付けられた深度ビュービデオブロックとを含む（９０１）。予測モジュール４１が、テクスチャビュービデオブロックを符号化する（９０２）。加えて、予測モジュール４１が、深度ビュービデオブロックを符号化する（９０３）。

本開示によれば、予測モジュール４１は、ＩＶＭＰモードをサポートする。特に、予測モジュール４１が、深度ビューについての動き情報がテクスチャビューから採用されるかどうかを示すための、シンタックス要素を生成する（９０３）。このようにして、ＩＭＶＰモードが有効にされる場合、深度ビュー構成要素は、その動き情報に関するいかなる追加のデルタ値を含まなくてもよく、代わりに、テクスチャビュー構成要素の動き情報を、その動き情報として採用し得る。特に、ＩＭＶＰモードの場合、深度ビュー構成要素は、いかなる動きベクトル差分値を含まなくてもよいが、対応するテクスチャビュー構成要素の動きベクトルを完全に採用し得る。テクスチャビューの動き情報を深度ビューの動き情報として完全に採用するモードを定義することによって、そのような動き情報に関する動きベクトルデルタ値のいかなるシグナリングもなしに、改善された圧縮が達成され得る。

テクスチャビュービデオブロックおよび深度ビュービデオブロックは、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニット中で一緒にコーディングされ得、シンタックス要素は、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すために、ＮＡＬユニット中にフラグを備え得る。この場合、シンタックス要素が、テクスチャビュービデオブロックに関連付けられた動き情報が深度ビュービデオブロックに関連付けられた動き情報として採用されることを示す場合、深度ビュービデオブロックは、深度ビュービデオブロックに関連付けられた動き情報に関するいかなる追加のデルタをも含まない。ＮＡＬユニットは、ビデオデータをコーディングするために使用される１つの特定のタイプのアクセスユニットであり、これらの技法はまた、他のタイプのビデオユニットとともに使用され得る。

より詳細には、シンタックス要素は、ＩＶＭＰモードが有効にされるかどうかを示す１つまたは複数のビットを備え得る。ＩＶＭＰモードが無効にされる場合、テクスチャビュービデオブロックに関連付けられた動き情報が、ＮＡＬユニット中に含まれ、深度ビュービデオブロックに関連付けられた動き情報が、別個にＮＡＬユニット中に含まれる。代替的に、ＩＶＭＰモードが有効にされる場合、テクスチャビュービデオブロックに関連付けられた動き情報が、ＮＡＬユニット中に含まれ、テクスチャビュービデオブロックに関連付けられた動き情報が、深度ビュービデオブロックに関連付けられた動き情報として採用される。したがって、ＩＶＭＰモードが有効にされる場合、深度ビュービデオブロックは、深度ビュービデオブロックに関連付けられた動き情報に関するいかなる追加のデルタをも含まない。いくつかの例では、ＩＶＭＰモードは、非アンカーピクチャにのみ適用され、アンカーピクチャに適用されない。

図１０は、本開示に一致する、ビデオデコーダによって実行され得る技法を示す流れ図である。他のビデオデコーダも使用され得るが、図１０について、図３のビデオデコーダ３０の観点から説明する。図１０に示すように、予測モジュール８１が、３Ｄビデオ、たとえば、３Ｄビデオデータを表すビデオブロックを受信する（１００１）。３Ｄビデオは、テクスチャビュービデオブロックと、関連付けられた深度ビュービデオブロックとを含む（１００１）。予測モジュール４１が、テクスチャビュービデオブロックを復号する（１００２）。加えて、予測モジュール４１が、深度ビュービデオブロックを復号する（１００３）。

本開示によれば、予測モジュール８１は、ＩＶＭＰモードをサポートする。特に、予測モジュール８１が、深度ビューについての動き情報がテクスチャビューから採用されるかどうかを示すための、シンタックス要素を復号する（１００３）。シンタックス要素は、深度ビューの動き情報がテクスチャビューから採用されるかどうかを示すものとして、デコーダによって解釈され得る。ＩＭＶＰモードが有効にされる場合、深度ビュー構成要素は、その動き情報に関するいかなる追加のデルタ値を含まなくてもよく、代わりに、テクスチャビュー構成要素の動き情報を、その動き情報として採用し得る。この場合も、テクスチャビューの動き情報を深度ビューの動き情報として完全に採用するモードを定義することによって、そのような動き情報に関するデルタ値のいかなるシグナリングもなしに、改善された圧縮が達成され得る。

１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。

限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備え得る。同様に、いかなる接続も適切にコンピュータ可読媒体と称される。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明した技法の実装に好適な他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。

本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。

さらに他の例では、本開示は、その上にデータ構造を記憶するコンピュータ可読記憶媒体を対象とし得る。データ構造は、テクスチャビューに関連して深度ビューをコーディングするためにＩＶＭＰモードを使用することによってなど、本明細書で説明する方法で圧縮される３Ｄビデオデータを含み得る。

様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。

様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］３次元（３Ｄ）ビデオデータをコーディングするための方法であって、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を備え、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、方法。
［２］前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、［１］に記載の方法。
［３］前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［２］に記載の方法。
［４］前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、［２］に記載の方法。
［５］前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、［４］に記載の方法。
［６］前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［５］に記載の方法。
［７］コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、［１］に記載の方法。
［８］コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、［１］に記載の方法。
［９］３次元（３Ｄ）ビデオデータをコーディングするデバイスであって、前記デバイスは、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を行うように構成された１つまたは複数のプロセッサを備え、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、デバイス。
［１０］前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、［９］に記載のデバイス。
［１１］前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［１０］に記載のデバイス。
［１２］前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、［１０］に記載のデバイス。
［１３］前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、［１２］に記載のデバイス。
［１４］前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［１３］に記載のデバイス。
［１５］コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、［９］に記載のデバイス。
［１６］コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、［９］に記載のデバイス。
［１７］前記デバイスがワイヤレスハンドセットを備える、［９］に記載のデバイス。
［１８］前記デバイスが、
デジタルテレビジョン、
デジタルダイレクトブロードキャストシステムにおけるデバイス、
ワイヤレスブロードキャストシステムにおけるデバイス、
携帯情報端末（ＰＤＡ）、
ラップトップコンピュータ、
デスクトップコンピュータ、
タブレットコンピュータ、
電子ブックリーダー、
デジタルカメラ、
デジタル記録デバイス、
デジタルメディアプレーヤ、
ビデオゲームデバイス、
ビデオゲームコンソール、
セルラー無線電話、
衛星無線電話
スマートフォン、
ビデオ遠隔会議デバイス、および
ビデオストリーミングデバイス
のうちの１つまたは複数を備える、［９］に記載のデバイス。
［１９］記憶された命令を備えるコンピュータ可読記憶媒体であって、前記命令は、実行すると、１つまたは複数のプロセッサに、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を行わせ、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、コンピュータ可読記憶媒体。
［２０］前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、［１９］に記載のコンピュータ可読記憶媒体。
［２１］前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［２０］に記載のコンピュータ可読記憶媒体。
［２２］前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、［２０］に記載のコンピュータ可読記憶媒体。
［２３］前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、［２２］に記載のコンピュータ可読記憶媒体。
［２４］前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［２３］に記載のコンピュータ可読記憶媒体。
［２５］コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、［１９］に記載のコンピュータ可読記憶媒体。
［２６］コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、［１９］に記載のコンピュータ可読記憶媒体。
［２７］３次元（３Ｄ）ビデオデータをコーディングするように構成されたデバイスであって、前記デバイスは、
テクスチャビュービデオブロックをコーディングするための手段と、
深度ビュービデオブロックをコーディングするための手段であり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングするための手段と
を備え、
前記深度ビュービデオブロックをコーディングするための前記手段が、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングするための手段を含む、デバイス。
［２８］前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、［２７］に記載のデバイス。
［２９］前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［２８］に記載のデバイス。
［３０］前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、［２８］に記載のデバイス。
［３１］前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、［３０］に記載のデバイス。
［３２］前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、［３１］に記載のデバイス。
［３３］コーディングするための前記手段が、符号化するための手段を備え、前記シンタックス要素をコーディングするための前記手段が、前記シンタックス要素を生成するための手段を備える、［２７］に記載のデバイス。
［３４］コーディングするための前記手段が、復号するための手段を備え、前記シンタックス要素をコーディングするための前記手段が、符号化ビットストリームから前記シンタックス要素を復号するための手段を備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、［２７］に記載のデバイス。

Claims

３次元（３Ｄ）ビデオデータをコーディングするための方法であって、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を備え、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、方法。
前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、請求項１に記載の方法。
前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項２に記載の方法。
前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、請求項２に記載の方法。
前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、請求項４に記載の方法。
前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項５に記載の方法。
コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、請求項１に記載の方法。
コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、請求項１に記載の方法。
３次元（３Ｄ）ビデオデータをコーディングするデバイスであって、前記デバイスは、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を行うように構成された１つまたは複数のプロセッサを備え、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、デバイス。
前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、請求項９に記載のデバイス。
前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項１０に記載のデバイス。
前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、請求項１０に記載のデバイス。
前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、請求項１２に記載のデバイス。
前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項１３に記載のデバイス。
コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、請求項９に記載のデバイス。
コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、請求項９に記載のデバイス。
前記デバイスがワイヤレスハンドセットを備える、請求項９に記載のデバイス。
前記デバイスが、
デジタルテレビジョン、
デジタルダイレクトブロードキャストシステムにおけるデバイス、
ワイヤレスブロードキャストシステムにおけるデバイス、
携帯情報端末（ＰＤＡ）、
ラップトップコンピュータ、
デスクトップコンピュータ、
タブレットコンピュータ、
電子ブックリーダー、
デジタルカメラ、
デジタル記録デバイス、
デジタルメディアプレーヤ、
ビデオゲームデバイス、
ビデオゲームコンソール、
セルラー無線電話、
衛星無線電話
スマートフォン、
ビデオ遠隔会議デバイス、および
ビデオストリーミングデバイス
のうちの１つまたは複数を備える、請求項９に記載のデバイス。
記憶された命令を備えるコンピュータ可読記憶媒体であって、前記命令は、実行すると、１つまたは複数のプロセッサに、
テクスチャビュービデオブロックをコーディングすることと、
深度ビュービデオブロックをコーディングすることであり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングすることと
を行わせ、
前記深度ビュービデオブロックをコーディングすることが、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングすることを含む、コンピュータ可読記憶媒体。
前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、請求項１９に記載のコンピュータ可読記憶媒体。
前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項２０に記載のコンピュータ可読記憶媒体。
前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、請求項２０に記載のコンピュータ可読記憶媒体。
前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、請求項２２に記載のコンピュータ可読記憶媒体。
前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項２３に記載のコンピュータ可読記憶媒体。
コーディングすることが、符号化することを備え、前記シンタックス要素をコーディングすることが、前記シンタックス要素を生成することを備える、請求項１９に記載のコンピュータ可読記憶媒体。
コーディングすることが、復号することを備え、前記シンタックス要素をコーディングすることが、符号化ビットストリームから前記シンタックス要素を復号することを備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、請求項１９に記載のコンピュータ可読記憶媒体。
３次元（３Ｄ）ビデオデータをコーディングするように構成されたデバイスであって、前記デバイスは、
テクスチャビュービデオブロックをコーディングするための手段と、
深度ビュービデオブロックをコーディングするための手段であり、前記深度ビュービデオブロックが前記テクスチャビュービデオブロックに関連付けられる、コーディングするための手段と
を備え、
前記深度ビュービデオブロックをコーディングするための前記手段が、前記テクスチャビュービデオブロックに関連付けられた動き情報が前記深度ビュービデオブロックに関連付けられた動き情報として採用されるかどうかを示すための、シンタックス要素をコーディングするための手段を含む、デバイス。
前記テクスチャビュービデオブロックおよび前記深度ビュービデオブロックが、アクセスユニット中で一緒にコーディングされ、前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されるかどうかを示すために、ビデオブロックレベルで定義されたフラグを備える、請求項２７に記載のデバイス。
前記シンタックス要素が、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が前記深度ビュービデオブロックに関連付けられた前記動き情報として採用されることを示す場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項２８に記載のデバイス。
前記シンタックス要素が、内部ビュー動き予測（ＩＶＭＰ）モードが有効にされるかどうかを定義する、請求項２８に記載のデバイス。
前記ＩＶＭＰモードが無効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記深度ビュービデオブロックに関連付けられた前記動き情報が、別個に前記アクセスユニット中に含まれ、
前記ＩＶＭＰモードが有効にされる場合、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記アクセスユニット中に含まれ、前記テクスチャビュービデオブロックに関連付けられた前記動き情報が、前記深度ビュービデオブロックに関連付けられた前記動き情報として採用される、請求項３０に記載のデバイス。
前記ＩＶＭＰモードが有効にされる場合、前記深度ビュービデオブロックが、前記深度ビュービデオブロックに関連付けられた前記動き情報に関するいかなるデルタをも含まない、請求項３１に記載のデバイス。
コーディングするための前記手段が、符号化するための手段を備え、前記シンタックス要素をコーディングするための前記手段が、前記シンタックス要素を生成するための手段を備える、請求項２７に記載のデバイス。
コーディングするための前記手段が、復号するための手段を備え、前記シンタックス要素をコーディングするための前記手段が、符号化ビットストリームから前記シンタックス要素を復号するための手段を備え、前記シンタックス要素が、前記符号化ビットストリーム中に含まれる、請求項２７に記載のデバイス。