JP2017512033A - ３ｄ−ｈｅｖｃのための簡略化された高度残差予測 - Google Patents

Abstract

本開示は、３Ｄビデオコーディングのための技法を説明する。特に、本開示は、３Ｄ−ＨＥＶＣにおける高度残差予測（ＡＲＰ）のための技法に関係する。本開示の１つの技法によれば、双方向予測ブロックについてインタービューＡＲＰを実施するとき、ビデオコーダは、第１の予測方向に関するＡＲＰを実施することの一部として、第１の対応するブロックに関する動きベクトルを決定し、第２の予測方向に関するＡＲＰを実施するとき、その決定された動きベクトルを再利用し得る。別の技法によれば、双方向予測ブロックについて、ビデオコーダは、ブロックのクロマ成分については一方向のみでＡＲＰを適用するが、ブロックのルーマ成分については二方向でＡＲＰを適用し得る。別の技法によれば、ビデオコーダは、ブロックサイズに基づいて、クロマ成分にＡＲＰを選択的に適用し得る。これらの簡略化、ならびに本開示に含まれる他の技法は、全体的なコーディング複雑さを低減し得る。

Description

[0001]本開示は、ビデオ符号化および復号に関する。

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

[0003]Ｈ．２６４／ＡＶＣを含む上述の規格のうちのいくつかの拡張は、ステレオまたは３次元（「３Ｄ」）ビデオを生成するために、マルチビュービデオコーディングのための技法を提供し得る。特に、マルチビューコーディングのための技法が、（Ｈ．２６４／ＡＶＣに対するスケーラブル拡張である）スケーラブルビデオコーディング（ＳＶＣ：scalable video coding）規格、および（Ｈ．２６４／ＡＶＣに対するマルチビュー拡張になっている）マルチビュービデオコーディング（ＭＶＣ：multi-view video coding）規格とともに、ＡＶＣにおいて使用するために提案されている。

[0004]一般に、ステレオビデオは、２つのビュー、たとえば、左ビューと右ビューとを使用して実現される。３次元ビデオ効果を実現するために、左ビューのピクチャは右ビューのピクチャと実質的に同時に表示され得る。たとえば、ユーザは、左ビューを右ビューからフィルタ処理する偏光パッシブ眼鏡（polarized, passive glasses）を着用し得る。代替的に、２つのビューのピクチャは高速で連続して示され得、ユーザは、同じ頻度で、ただし位相が９０度シフトして左眼と右眼とを迅速に閉じるアクティブ眼鏡を着用し得る。

[0005]概して、本開示は、３Ｄビデオコーディングのための技法を説明する。特に、本開示は、３Ｄ−ＨＥＶＣにおける高度残差予測（ＡＲＰ：advanced residual prediction）のための技法に関係する。

[0006]一例では、ビデオデータをコーディングする方法は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、ここにおいて、現在のブロックが双方向予測され、現在のブロックに関する第１のディスパリティ動きベクトル（a first disparity motion vector）および第２のディスパリティ動きベクトルを決定することと、第１のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックに関する第１の対応するブロックの位置を特定することと、第２のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックの第２の対応するブロックの位置を特定することと、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定することと、動きベクトルを使用して、第１のビュー中の現在のブロックの参照ブロック、第２のビュー中の第１の対応するブロックの参照ブロック、および第２のビュー中の第２の対応するブロックの参照ブロックを識別することと、第１の対応するブロックと、現在のブロックの参照ブロックと、第１の対応するブロックの参照ブロックとに基づいて、第１の予測ブロックを生成することと、第２の対応するブロックと、現在のブロックの参照ブロックと、第２の対応するブロックの参照ブロックとに基づいて、第２の予測ブロックを生成することとを含む。

[0007]別の例では、ビデオデータをコーディングする方法は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、ここにおいて、現在のブロックが双方向予測され、現在のブロックのルーマブロックについて、ルーマブロックの第１の予測ブロックを決定するために、第１の予測方向に関するＡＲＰを実施することと、現在のブロックのルーマブロックについて、ルーマブロックの第２の予測ブロックを決定するために、第２の予測方向に関するＡＲＰを実施することと、現在のブロックのクロマブロックについて、クロマブロックの第１の予測ブロックを決定するために、第１の予測方向または第２の予測方向のうちの１つのみに関するＡＲＰを実施することとを含む。

[0008]別の例では、ビデオデータをコーディングする方法は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、現在のブロックのルーマブロックについて、ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施することと、現在のブロックのクロマブロックについて、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定することとを含む。

[0009]別の例では、コンピュータ可読記憶媒体は、実行されたとき、上記の方法またはその方法の組合せを１つまたは複数のプロセッサに実施させる命令をその上に記憶する。

[0010]別の例では、ビデオをコーディングするためのデバイスは、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、ここにおいて、現在のブロックが双方向予測され、現在のブロックに関する第１のディスパリティ動きベクトルおよび第２のディスパリティ動きベクトルを決定することと、第１のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックに関する第１の対応するブロックの位置を特定することと、第２のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックの第２の対応するブロックの位置を特定することと、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定することと、動きベクトルを使用して、第１のビュー中の現在のブロックの参照ブロック、第２のビュー中の第１の対応するブロックの参照ブロック、および第２のビュー中の第２の対応するブロックの参照ブロックを識別することと、第１の対応するブロックと、現在のブロックの参照ブロックと、第１の対応するブロックの参照ブロックとに基づいて、第１の予測ブロックを生成することと、第２の対応するブロックと、現在のブロックの参照ブロックと、第２の対応するブロックの参照ブロックとに基づいて、第２の予測ブロックを生成することとを行うように構成されたビデオコーダを含む。

[0011]別の例では、ビデオをコーディングするためのデバイスは、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、ここにおいて、現在のブロックが双方向予測され、現在のブロックのルーマブロックについて、ルーマブロックの第１の予測ブロックを決定するために、第１の予測方向に関するＡＲＰを実施することと、現在のブロックのルーマブロックについて、ルーマブロックの第２の予測ブロックを決定するために、第２の予測方向に関するＡＲＰを実施することと、現在のブロックのクロマブロックについて、クロマブロックの第１の予測ブロックを決定するために、第１の予測方向または第２の予測方向のうちの１つのみに関するＡＲＰを実施することとを行うように構成されたビデオコーダを含む。

[0012]別の例では、ビデオをコーディングするためのデバイスは、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定することと、現在のブロックのルーマブロックについて、ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施することと、現在のブロックのクロマブロックについて、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定することとを行うように構成されたビデオコーダを含む。

[0013]別の例では、ビデオデータをコーディングするための装置は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定するための手段と、ここにおいて、現在のブロックが双方向予測され、現在のブロックのための第１のディスパリティ動きベクトルおよび第２のディスパリティ動きベクトルを決定するための手段と、第１のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックに関する第１の対応するブロックの位置を特定するための手段と、第２のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックの第２の対応するブロックの位置を特定するための手段と、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定するための手段と、動きベクトルを使用して、第１のビュー中の現在のブロックの参照ブロック、第２のビュー中の第１の対応するブロックの参照ブロック、および第２のビュー中の第２の対応するブロックの参照ブロックを識別するための手段と、第１の対応するブロックと、現在のブロックの参照ブロックと、第１の対応するブロックの参照ブロックとに基づいて、第１の予測ブロックを生成するための手段と、第２の対応するブロックと、現在のブロックの参照ブロックと、第２の対応するブロックの参照ブロックとに基づいて、第２の予測ブロックを生成するための手段とを含む。

[0014]別の例では、ビデオデータをコーディングするための装置は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定するための手段と、ここにおいて、現在のブロックが双方向予測され、現在のブロックのルーマブロックについて、ルーマブロックの第１の予測ブロックを決定するために、第１の予測方向に関するＡＲＰを実施するための手段と、現在のブロックのルーマブロックについて、ルーマブロックの第２の予測ブロックを決定するために、第２の予測方向に関するＡＲＰを実施するための手段と、現在のブロックのクロマブロックについて、クロマブロックの第１の予測ブロックを決定するために、第１の予測方向または第２の予測方向のうちの１つのみに関するＡＲＰを実施するための手段とを含む。

[0015]別の例では、ビデオデータをコーディングするための装置は、第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定するための手段と、現在のブロックのルーマブロックについて、ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施するための手段と、現在のブロックのクロマブロックについて、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定するための手段とを含む。

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

[0017]本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0018]例示的なマルチビュー復号順序を示す概念図。 [0019]マルチビューコーディングのための例示的な予測構造を示す概念図。 [0020]コーディングユニットに対する空間隣接ブロック（spatial neighboring blocks）の一例を示す図。 [0021]３Ｄ−ＨＥＶＣにおける高度残差予測（ＡＲＰ）のための例示的な予測構造を示す図。 [0022]マルチビュービデオコーディングにおける現在のブロックと、参照ブロックと、動き補償されたブロックとの間の例示的な関係を示す図。 [0023]インタービュー残差データについてのＡＲＰの一例を示す図。 [0024]ブロックレベル時間ＡＲＰ（block-level temporal ARP）の例示的な予測構造を示す図。 [0025]ブロックレベルインタービューＡＲＰの例示的な予測構造を示す図。 [0026]サブＰＵレベルインタービュー動き予測のための例示的な予測構造を示す図。 [0027]サブＰＵレベル時間ＡＲＰの例示的な予測構造を示す図。 [0028]サブＰＵレベルインタービューＡＲＰの例示的な予測構造を示す図。 [0029]３Ｄ−ＨＥＶＣにおける双方向インタービューＡＲＰのための参照ブロックアクセスの一例を示す図。 [0030]３Ｄ−ＨＥＶＣにおける時間ＡＲＰおよびインタービューＡＲＰのための例示的な参照ブロックアクセスを示す図。 [0031]双方向インタービューＡＲＰにおいて使用される単一の時間動きベクトルの一例を示す図。 [0032]本開示で説明する技法を実装するように構成されたビデオエンコーダの一例を示す図。 [0033]本開示で説明する技法を実装するように構成されたビデオデコーダの一例を示す図。 [0034]本開示の技法による、ビデオブロックを予測する例示的な方法を示す図。 [0035]本開示の技法による、ビデオブロックを予測する例示的な方法を示す図。 [0036]本開示の技法による、ビデオブロックを予測する例示的な方法を示す図。

[0037]本開示は、３Ｄ−ＨＥＶＣのための高度残差予測（ＡＲＰ）に関係する技法を導入する。本開示の技法は、ビデオエンコーダまたはビデオデコーダなど、ビデオコーダによって実施され得る。ＡＲＰでは、ビデオコーダは、すでにコード化された画像間の差に基づいて、残差予測子を生成する。ビデオコーダは、次いで、最終予測ブロックを生成するために、元の予測ブロックにこの残差予測子を加算する。残差予測子を含む最終予測ブロックは、元の予測子よりも、潜在的により良い予測子である、すなわち、予測されているブロックにより厳密に似ている。

[0038]概して、本開示では時間ＡＲＰおよびインタービューＡＲＰと呼ばれる、２つのタイプのＡＲＰがある。時間ＡＲＰでは、第１のビュー中の現在のブロックについて、ビデオコーダは、現在のブロックに関するディスパリティベクトルを使用して、第２のビュー中の対応するブロックの位置を特定する（locates）。本開示では、第２のビュー中のこの対応するブロックはベースブロックと呼ばれる。現在のブロックの時間動きベクトルを使用して、ビデオコーダは、第１のビューの異なるピクチャ中の現在のブロックの参照ブロックの位置を特定する。本開示では、このブロックは現在の参照ブロックと呼ばれる。現在の参照ブロックを識別するために使用される同じ時間動きベクトルを使用して、ビデオコーダは、第２のビューのピクチャ中のベースブロックの参照ブロックの位置を特定する。本開示では、このブロックは、参照ベースブロックと呼ばれる。ベースブロックとベース参照ブロックとの間の差は、残差予測子として計算され得る。ビデオコーダは、次いで、最終予測子を決定するために、現在の参照ブロックに、場合によっては（possibly）重み付け係数（a weighting factor）を用いて、残差予測子を加算する。

[0039]インタービューＡＲＰでは、第１のビュー中の現在のブロックについて、ビデオコーダは、現在のブロックに関するディスパリティ動きベクトルを使用して、第２のビュー中の対応するブロックの位置を特定する。ベースブロックの時間動きベクトルを使用して、ビデオコーダは、第２のビューの異なるピクチャ中のベースブロックの参照ベースブロックの位置を特定する。ベース参照ブロックを識別するために使用される同じ時間動きベクトルを使用して、ビデオコーダは、第１のビューのピクチャ中の現在のブロックの現在の参照ブロックを識別する。ビデオコーダは、現在の参照ブロックとベース参照ブロックとの間の差を計算し、計算された差を残差予測子として使用した。ビデオコーダは、次いで、最終予測子を決定するために、ベースブロックに、場合によっては重み付け係数を用いて、この残差予測子を加算する。

[0040]ビデオコーダがＡＲＰを使用して双方向予測されたブロックをコーディングするとき、ビデオコーダは２つの予測方向に関する追加の参照ブロックを査定し（assess）なければならず、全体的な複雑さを増加させる。ビデオコーダがＡＲＰを使用してブロックをコーディングするとき、ＡＲＰは、ブロックのクロマ成分とブロックのルーマ成分の両方をコーディングするために使用され得、全体的な複雑さをさらに増加させる。本開示は、知られているＡＲＰ技法にいくつかの潜在的簡略化を導入する。一例では、本開示の技法によれば、双方向予測されたブロックについてインタービューＡＲＰを実施するとき、ビデオコーダは、第１の予測方向に関するＡＲＰを実施することの一部として、第１の対応するブロックに関する動きベクトルを決定し、第２の予測方向に関するＡＲＰを実施するとき、その決定された動きベクトルを再利用し得る。別の例によれば、双方向予測されたブロックについて、ビデオコーダは、ブロックのクロマ成分については一方向のみでＡＲＰを適用するが、ブロックのルーマ成分については二方向でＡＲＰを適用し得る。別の例によれば、ビデオコーダは、ブロックサイズに基づいて、クロマ成分にＡＲＰを選択的に適用し得る。これらの簡略化、ならびに本開示に含まれる他の技法は、全体的なコーディング複雑さを低減し得る。

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

[0042]システム１０は、異なるビデオコーディング規格、プロプライエタリ規格、またはマルチビューコーディングの任意の他の方法に従って動作し得る。下記は、ビデオコーディング規格の数例を説明しており、限定と見なされるべきではない。ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６３と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌと、それのスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）拡張を含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４とを含む。ＭＶＣの最新のジョイントドラフトは、その内容全体が参照により本明細書に組み込まれる「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１０年３月に記載されている。ＭＶＣの別のジョイントドラフトは、その内容全体が参照により本明細書に組み込まれる「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１１年６月に記載されている。いくつかの追加のビデオコーディング規格は、ＡＶＣに基づく、ＭＶＣ＋Ｄおよび３Ｄ ＡＶＣを含む。さらに、新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）が、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）とのジョイントコラボレーションチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）によって開発されている。

[0043]単に説明の目的で、本開示で説明する技法は、３Ｄ−ＡＶＣなど、Ｈ．２６４規格よる例を用いて説明される。ただし、本開示で説明する技法は、これらの例示的な規格に限定されると見なされるべきではなく、マルチビューコーディングもしくは３Ｄビデオコーディングのための他のビデオコーディング規格（たとえば、３Ｄ−ＨＥＶＣ）、または必ずしも特定のビデオコーディング規格に基づくとは限らないマルチビューコーディングもしくは３Ｄビデオコーディングに関連する技法に拡張可能であり得る。たとえば、本開示で説明する技法は、マルチビューコーディングのためのビデオエンコーダ／デコーダ（コーデック）によって実装され、ここでマルチビューコーディングは、２つまたはそれ以上のビューのコーディングを含む。

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

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

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

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

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

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

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

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

[0052]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。たとえば、本開示で説明する技法は、装置またはデバイスの観点から説明されることがある。一例として、装置またはデバイスは、ビデオデコーダ３０（たとえば、ワイヤレス通信デバイスの一部としての宛先デバイス１４）を含み得、ビデオデコーダ３０は、本開示で説明する技法を実装する（たとえば、本開示で説明する技法に従ってビデオデータを復号する）ように構成された１つまたは複数のプロセッサを含み得る。別の例として、装置またはデバイスは、ビデオデコーダ３０を含むマイクロプロセッサまたは集積回路（ＩＣ）を含み得、マイクロプロセッサまたはＩＣは、宛先デバイス１４または別のタイプのデバイスの一部であり得る。同じことが、ビデオエンコーダ２０に当てはまり得る（すなわち、ソースデバイス１２のような装置またはデバイス、および／あるいはマイクロコントローラまたはＩＣは、ビデオエンコーダ２０を含み、ここで、ビデオエンコーダ２０は、本開示で説明する技法に従ってビデオデータを符号化するように構成される）。

[0053]本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体内に記憶し、本開示の技法を実施するために１つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。

[0054]ビデオシーケンスは、一般に、ビューからの一連のビデオピクチャを含む。ピクチャグループ（ＧＯＰ：group of pictures）は、概して、一連の１つまたは複数のビデオピクチャを備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ＧＯＰの１つまたは複数のピクチャのヘッダ中、または他の場所に含み得る。各ピクチャは、それぞれのピクチャのための符号化モードを記述するピクチャシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために、個々のビデオピクチャ内のビデオブロックに作用する。ビデオブロックは、Ｈ．２６４規格において規定されているように、マクロブロック、マクロブロックのパーティション、および場合によってはパーティションのサブブロックに対応し得る。ビデオブロックは、固定サイズまたは変動サイズを有し得、指定されたコーディング規格に応じてサイズが異なり得る。各ビデオピクチャは複数のスライスを含み得る。各スライスは複数のブロックを含み得る。

[0055]一例として、ＩＴＵ−Ｔ Ｈ．２６４規格は、ルーマ成分については１６×１６、８×８、または４×４、およびクロマ成分については８×８など、様々なブロックサイズのイントラ予測をサポートし、ならびにルーマ成分については１６×１６、１６×８、８×１６、８×８、８×４、４×８および４×４、およびクロマ成分については対応するスケーリングされたサイズなど、様々なブロックサイズのインター予測をサポートする。本開示では、「Ｎ×Ｎ（NxN）」と「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するブロックのピクセル寸法（pixel dimensions）（たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセル）を指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここで、Ｎは非負整数値を表す。ブロック中のピクセルは行および列に配列され得る。さらに、ブロックは、必ずしも、水平方向に垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。

[0056]ブロックがイントラモード符号化（たとえば、イントラ予測）されるとき、ブロックは、ブロックのためのイントラ予測モードを記述するデータを含み得る。別の例として、ブロックがインターモード符号化（たとえば、インター予測）されるとき、ブロックは、ブロックに関する動きベクトルを定義する情報を含み得る。この動きベクトルは、同じビュー中の参照ピクチャ（たとえば、時間動きベクトル）を指すか、または別のビュー中の参照ピクチャ（たとえば、ディスパリティ動きベクトル）を指す。ブロックに関する動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分と、動きベクトルの垂直成分と、動きベクトルの解像度（a resolution）（たとえば、１／４ピクセル精度または１／８ピクセル精度（one-quarter pixel precision or one-eighth pixel precision））とを記述する。さらに、インター予測されるとき、ブロックは、動きベクトルが指す参照ピクチャなどの参照インデックス情報、および／または動きベクトルのための参照ピクチャリスト（たとえば、ＲｅｆＰｉｃＬｉｓｔ０もしくはＲｅｆＰｉｃＬｉｓｔ１）を含み得る。

[0057]Ｈ．２６４規格では、イントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ２０はマクロブロックに関する残差データを計算する。残差データは、符号化されていないピクチャのピクセルと、Ｈ．２６４におけるマクロブロックに関する予測値との間のピクセル差分に対応し得る。

[0058]いくつかの例では、変換係数を生成するための任意の変換に続いて、ビデオエンコーダ２０は変換係数の量子化を実施する。量子化は、一般に、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度（bit depth）を低減する。たとえば、ｎビット値は、量子化中にｍビット値に切り捨てられ（rounded down）、ここで、ｎはｍよりも大きい。

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

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

[0061]ビデオデコーダ３０は、ビデオエンコーダ２０の技法の逆を実装する。たとえば、ビデオデコーダ３０は、符号化されたビデオビットストリームを復号し、逆量子化および逆変換によって残差ブロックを決定する。ビデオデコーダ３０は、ピクチャ内のブロックに関するピクセル値を決定するために、前に復号されたピクチャのブロックと残差ブロックとを合計する。

[0062]本開示で説明するいくつかの技法は、ビデオエンコーダ２０とビデオデコーダ３０の両方によって実施され得る。一例として、ビデオエンコーダ２０は、どのようにビデオデータのブロックを符号化すべきかを決定することの一部としてＡＲＰを実施し得、および／またはビデオエンコーダにおける復号ループの一部としてＡＲＰを実施し得る。ビデオデコーダ３０は、ビデオブロックを復号することの一部として、ビデオエンコーダ２０によって実施されるものと同じＡＲＰ技法を実施し得る。本開示は、時々、本開示で説明するいくつかのＡＲＰ技法を実施するビデオデコーダ３０を指し得る。ただし、別段に記載されていない限り、そのような技法は、ビデオエンコーダ２０によっても実施され得ることを理解されたい。

[0063]上記で説明したように、本開示で説明する技法は３ｄビデオコーディングを対象とする。本技法をよりよく理解するために、下記は、いくつかのＨ．２６４／ＡＶＣコーディング技法、Ｈ．２６４／ＭＶＣ拡張および高効率ビデオコーディング（ＨＥＶＣ）規格の観点からのマルチビュービデオコーディング、ならびに、３Ｄ−ＡＶＣ技法を説明する。

[0064]Ｈ．２６４／アドバンスビデオコーディング（ＡＶＣ）の場合、ビデオ符号化または復号（たとえば、コーディング）はマクロブロック上で実装され、ここで、マクロブロックは、インター予測またはイントラ予測（すなわち、インター予測符号化または復号あるいはイントラ予測符号化または復号）されるフレームの一部を表す。たとえば、Ｈ．２６４／ＡＶＣでは、各インターマクロブロック（ＭＢ）（たとえば、インター予測されたマクロブロック）は、４つの異なる方法、すなわち、１つの１６×１６ＭＢパーティション、２つの１６×８ＭＢパーティション、２つの８×１６ＭＢパーティション、または４つの８×８ＭＢパーティションに区分され得る。１つのＭＢにおける異なるＭＢパーティションは、各方向（すなわち、ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）について異なる基準インデックス値を有し得る。ＭＢが複数の（１よりも多い）ＭＢパーティションに区分されないとき、それは、各方向に、ＭＢパーティション全体のための１つの動きベクトルのみを有する。

[0065]ビデオコーディング（符号化または復号）の一部として、ビデオコーダ２０／３０は、ＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１と呼ばれる、１つまたは２つの参照ピクチャリストを構成するように構成され得る。（１つまたは複数の）参照ピクチャリストは、フレームまたはスライスのマクロブロックをインター予測するために使用され得る参照ピクチャを識別する。たとえば、ビデオエンコーダ２０は、参照インデックスおよび参照ピクチャリスト識別子をシグナリングし得る。ビデオデコーダ３０は、参照インデックスと参照ピクチャリスト識別子とを受信し、参照インデックスと参照ピクチャリスト識別子とから、現在のマクロブロックをインター予測復号するために使用されるべきである参照ピクチャを決定し得る。

[0066]ＭＢが４つの８×８ＭＢパーティションに区分されるとき、各８×８ＭＢパーティションはサブブロックにさらに区分され得る。８×８ＭＢパーティションから、サブブロック、すなわち、１つの８×８サブブロック、２つの８×４サブブロック、２つの４×８サブブロック、または４つの４×４サブブロックを得るための、４つの異なる方法がある。各サブブロックは、各方向において異なる動きベクトルを有することができるが、各方向について同じ参照ピクチャインデックスを共有する。８×８ＭＢパーティションがサブブロックに区分される様式は、サブブロックパーティションと称される。

[0067]本開示は、概して、ビデオデータの任意のブロックを指すために、ブロックという用語を使用する。たとえば、Ｈ．２６４コーディングおよびそれの拡張のコンテキストにおいて、ブロックは、マクロブロック、マクロブロックパーティション、サブブロック、または任意の他のタイプのブロックのいずれかを指し得る。ＨＥＶＣおよびそれの拡張のコンテキストにおいて、ブロックは、ＰＵ、ＴＵ、ＣＵ、または任意の他のタイプのブロックのいずれかを指し得る。本開示で使用するサブブロックは、概して、より大きいブロックの任意の部分を指す。サブブロックはまた、それ自体が単にブロックと呼ばれ得る。

[0068]マルチビュービデオコーディングの場合、複数の異なるビデオコーディング規格がある。混乱を回避するために、本開示が一般的にマルチビュービデオコーディングを説明するとき、本開示は「マルチビュービデオコーディング」という句を使用する。概して、マルチビュービデオコーディングでは、ベースビューおよび１つまたは複数の非ベースビューまたは依存ビュー（one or more non-base or dependent views）がある。ベースビューは、依存ビューのいずれかと無関係に十分に復号可能である（すなわち、ベースビューは、時間動きベクトルを用いてインター予測されるにすぎない）。これは、マルチビュービデオコーディングのために構成されないコーデックが、完全に復号可能である少なくとも１つのビューをなお受信することを可能にする（すなわち、ベースビューが抽出され、他のビューが破棄され得、マルチビュービデオコーディングのために構成されないデコーダが、３Ｄエクスペリエンスがないにもかかわらず、ビデオコンテンツをなお復号することを可能にする）。１つまたは複数の依存ビューは、ベースビューに関して、または別の依存ビューに関してインター予測され（すなわち、ディスパリティ補償予測され）、あるいは同じビュー中の他のピクチャに関してインター予測され（すなわち、動き補償予測され）得る。

[0069]「マルチビュービデオコーディング」が一般的に使用されるが、頭字語ＭＶＣはＨ．２６４／ＡＶＣの拡張に関連する。したがって、本開示が頭文字ＭＶＣを使用するとき、本開示は、特にＨ．２６４／ＡＶＣビデオコーディング規格の拡張を指している。Ｈ．２６４／ＡＶＣのＭＶＣ拡張は、時間動きベクトルに加えて、別のタイプの動きベクトルとして、ディスパリティ動きベクトルに依拠する。ＭＶＣプラス深度（ＭＶＣ＋Ｄ）と呼ばれる別のビデオコーディング規格も、ＪＣＴ−３ＶおよびＭＰＥＧによって開発されている。ＭＶＣ＋Ｄは、テクスチャと深度の両方についてＭＶＣの低レベルコーディングツールと同じ低レベルコーディングツールを適用し、深度の復号はテクスチャの復号に依存せず、その逆も同様である。たとえば、ＭＶＣでは、フレームは、テクスチャビューコンポーネントまたは単にテクスチャと呼ばれる、１つのビューコンポーネントのみによって表される。ＭＶＣ＋Ｄでは、２つのビューコンポーネント、すなわち、テクスチャビューコンポーネントおよび深度ビューコンポーネント、または単にテクスチャおよび深度がある。たとえば、ＭＶＣ＋Ｄでは、各ビューはテクスチャビューおよび深度ビューを含み、ここで、ビューは複数のビューコンポーネントを含み、テクスチャビューは複数のテクスチャビューコンポーネントを含み、深度ビューは複数の深度ビューコンポーネントを含む。

[0070]各テクスチャビューコンポーネントは、ビューのビューコンポーネントを形成するために、深度ビューコンポーネントに関連する。深度ビューコンポーネントは、テクスチャビューコンポーネントにおける対象（object）の相対深度を表す。ＭＶＣ＋Ｄでは、深度ビューコンポーネントおよびテクスチャビューコンポーネントは、別々に復号可能である。たとえば、ビデオデコーダ３０は、第１のコーデックがテクスチャビューコンポーネントを復号し、第２のコーデックが深度ビューコンポーネントを復号する、ＭＶＣコーデックの２つのインスタンスを実装し得る。これらの２つのコーデックは、テクスチャビューコンポーネントおよび深度ビューコンポーネントが別々に符号化されるので、互いから独立して実行することができる。

[0071]ＭＶＣ＋Ｄでは、深度ビューコンポーネントは、常に、関連する（たとえば、対応する）テクスチャビューコンポーネントの直後にきている。このようにして、ＭＶＣ＋Ｄはテクスチャ優先コーディング（texture-first coding）をサポートし、ここで、テクスチャビューコンポーネントは深度ビューコンポーネントより前に復号される。

[0072]テクスチャビューコンポーネントおよびそれの関連する（たとえば、対応する）深度ビューコンポーネントは、同じピクチャ順序カウント（ＰＯＣ）値およびｖｉｅｗ＿ｉｄを含み得る（すなわち、テクスチャビューコンポーネントおよびそれの関連する深度ビューコンポーネントのＰＯＣ値およびｖｉｅｗ＿ｉｄは同じである）。ＰＯＣ値は、テクスチャビューコンポーネントの表示順序を示し、ｖｉｅｗ＿ｉｄは、テクスチャビューコンポーネントおよび深度ビューコンポーネントが属するビューを示す。

[0073]図２に、一般的なＭＶＣ復号順序（すなわちビットストリーム順序）を示す。復号順序アレンジメント（decoding order arrangement）は時間優先コーディング（time-first coding）と呼ばれる。アクセスユニットの復号順序は出力または表示順序と同じでないことがあることに留意されたい。図２では、Ｓ０〜Ｓ７はそれぞれ、マルチビュービデオの異なるビューを指す。Ｔ０〜Ｔ８はそれぞれ、１つの出力時間インスタンスを表す。アクセスユニットは、１つの出力時間インスタンスについてのすべてのビューのコード化されたピクチャを含み得る。たとえば、第１のアクセスユニットは時間インスタンスＴ０についてのビューＳ０〜Ｓ７のすべてを含み得、第２のアクセスユニットは時間インスタンスＴ１についてのビューＳ０〜Ｓ７のすべてを含み得、以下同様である。

[0074]簡潔のために、本開示は以下の定義を使用し得る。
ビューコンポーネント：単一のアクセスユニット中のビューのコード化された表現。ビューがコード化されたテクスチャ表現とコード化された深度表現の両方を含むとき、ビューコンポーネントは、テクスチャビューコンポーネントと深度ビューコンポーネントとを含み得る。
テクスチャビューコンポーネント：単一のアクセスユニット中のビューのテクスチャのコード化された表現。
深度ビューコンポーネント：単一のアクセスユニット中のビューの深度のコード化された表現。

[0075]上記で説明したように、本開示のコンテキストでは、ビューコンポーネント、テクスチャビューコンポーネント、および深度バイドコンポーネントは一般にレイヤと呼ばれることがある。図２では、ビューの各々はピクチャのセットを含む。たとえば、ビューＳ０はピクチャ０、８、１６、２４、３２、４０、４８、５６、および６４のセットを含み、ビューＳ１はピクチャ１、９、１７、２５、３３、４１、４９、５７、および６５のセットを含み、以下同様である。各セットは２つのピクチャを含み、一方のピクチャはテクスチャビューコンポーネントと呼ばれ、他方のピクチャは深度ビューコンポーネントと呼ばれる。ビューのピクチャのセット内のテクスチャビューコンポーネントおよび深度ビューコンポーネントは、互いに対応すると見なされ得る。たとえば、ビューのピクチャのセット内のテクスチャビューコンポーネントは、そのビューのピクチャのセット内の深度ビューコンポーネントに対応すると見なされ、その逆も同様である（すなわち、深度ビューコンポーネントはセット中のそれのテクスチャビューコンポーネントに対応し、その逆も同様である）。本開示で使用する、深度ビューコンポーネントに対応するテクスチャビューコンポーネントは、テクスチャビューコンポーネントおよび深度ビューコンポーネントが単一のアクセスユニットの同じビューの一部であると見なされ得る。

[0076]テクスチャビューコンポーネントは、表示される実際の画像コンテンツを含む。たとえば、テクスチャビューコンポーネントは、ルーマ（Ｙ）成分と、クロマ（ＣｂおよびＣｒ）成分とを含み得る。深度ビューコンポーネントは、それの対応するテクスチャビューコンポーネント中のピクセルの相対深度を示し得る。１つの例示的なアナロジー（analogy）として、深度ビューコンポーネントは、ルーマ値のみを含むグレースケール画像のようである。言い換えれば、深度ビューコンポーネントは、画像コンテンツを搬送しないことがあるが、テクスチャビューコンポーネント中のピクセルの相対深度の測度（measure）を与え得る。

[0077]たとえば、深度ビューコンポーネント中の純白のピクセルは、対応するテクスチャビューコンポーネント中のそれの対応する１つまたは複数のピクセルが閲覧者から見てより近いことを示し、深度ビューコンポーネント中の純黒のピクセルは、対応するテクスチャビューコンポーネント中のそれの対応する１つまたは複数のピクセルが閲覧者から見てより遠いことを示す。黒と白との間にあるグレーの様々な濃淡（various shades）は、様々な深度レベルを示す。たとえば、深度ビューコンポーネント中の濃いグレーのピクセルは、テクスチャビューコンポーネント中のそれの対応するピクセルが、深度ビューコンポーネント中のより薄いグレーのピクセルよりも遠いことを示す。ピクセルの深度を識別するためにグレースケールのみが必要とされるので、深度ビューコンポーネントは、深度ビューコンポーネント用の色値（color values）がいかなる目的をも果たさないことがあるので、クロマ成分を含む必要がない。上記の説明は、深度画像をテクスチャ画像に関係付ける目的のためのアナロジーであるものとする。深度画像中の深度値は、実際にはグレーの濃淡を表すものではなく、実際には、８ビットまたは他のビットサイズの深度値を表す。

[0078]深度を識別するためにルーマ値（たとえば、輝度値（intensity values））のみを使用する深度ビューコンポーネントは説明のために与えられ、限定するものと見なされるべきではない。他の例では、テクスチャビューコンポーネント中のピクセルの相対深度を示すために任意の技法が利用され得る。

[0079]図３は、マルチビュービデオコーディングのための（各ビュー内のインターピクチャ予測と、ビュー間のインタービュー予測の両方を含む）一般的なＭＶＣ予測構造を示す。予測方向は矢印によって示され、矢印の終点のオブジェクトは、予測参照として矢印の始点のオブジェクトを使用する。ＭＶＣでは、Ｈ．２６４／ＡＶＣ動き補償のシンタックスを使用するが、異なるビュー中のピクチャが参照ピクチャとして使用されることを可能にするディスパリティ動き補償によって、インタービュー予測がサポートされる。

[0080]図３の例では、（ビューＩＤ「Ｓ０」〜「Ｓ７」を有する）８つのビューが示され、１２個の時間ロケーション（「Ｔ０」〜「Ｔ１１」）がビューごとに示されている。すなわち、図３中の各行はビューに対応し、各列は時間ロケーションを示す。

[0081]ＭＶＣがＨ．２６４／ＡＶＣデコーダによって復号可能であるいわゆるベースビューを有し、また、ステレオビューペアがＭＶＣによってサポートされ得るが、ＭＶＣの利点は、それが、３Ｄビデオ入力として３つ以上のビューを使用し、複数のビューによって表されるこの３Ｄビデオを復号する例をサポートすることができることである。ＭＶＣデコーダを有するクライアントのレンダラ（renderer）は、複数のビューを用いて３Ｄビデオコンテンツを予想し得る。

[0082]図３中のピクチャは、各行と各列との交点に示されている。Ｈ．２６４／ＡＶＣ規格は、ビデオの一部分を表すためにフレームという用語を使用し得る。本開示は、ピクチャという用語とフレームという用語とを互換的に使用し得る。

[0083]図３中のピクチャは、対応するピクチャがイントラコーディングされる（すなわち、Ｉピクチャである）か、あるいは一方向に（すなわち、Ｐピクチャとして）または複数の方向に（すなわち、Ｂピクチャとして）インターコーディングされるかを指定する、文字を含むブロックを使用して示されている。概して、予測は矢印によって示され、ここで矢印の終点のピクチャは、予測参照のために矢印の始点のピクチャを使用する。たとえば、時間ロケーションＴ０におけるビューＳ２のＰピクチャは、時間ロケーションＴ０におけるビューＳ０のＩピクチャから予測される。

[0084]シングルビュービデオ符号化の場合と同様に、マルチビュービデオコーディングのビデオシーケンスのピクチャは、異なる時間ロケーションにおけるピクチャに関して予測的に符号化され得る。たとえば、時間ロケーションＴ１におけるビューＳ０のｂピクチャは、時間ロケーションＴ０におけるビューＳ０のＩピクチャからそれに向けられた矢印を有し、その矢印は、ｂピクチャがＩピクチャから予測されることを示す。しかしながら、さらに、マルチビュービデオ符号化のコンテキストでは、ピクチャはインタービュー予測され得る。すなわち、ビューコンポーネントは、参照のために他のビュー中のビューコンポーネントを使用することができる。ＭＶＣでは、たとえば、別のビュー中のビューコンポーネントがインター予測参照であるかのように、インタービュー予測が実現される。潜在的なインタービュー参照は、シーケンスパラメータセット（ＳＰＳ：Sequence Parameter Set）ＭＶＣ拡張においてシグナリングされ、インター予測またはインタービュー予測参照のフレキシブルな順序付け（ordering）を可能にする参照ピクチャリスト構成プロセスによって変更され得る。インタービュー予測は、３Ｄ−ＨＥＶＣ（マルチビュー＋深度）を含むＨＥＶＣの提案されたマルチビュー拡張の特徴でもある。

[0085]図３は、インタービュー予測の様々な例を与える。図３の例では、ビューＳ１のピクチャは、ビューＳ１の異なる時間ロケーションにおけるピクチャから予測されるものとして、ならびに同じ時間ロケーションにおけるビューＳ０およびＳ２のピクチャからインタービュー予測されるものとして示されている。たとえば、時間ロケーションＴ１におけるビューＳ１のｂピクチャは、時間ロケーションＴ０およびＴ２におけるビューＳ１のＢピクチャの各々、ならびに時間ロケーションＴ１におけるビューＳ０およびＳ２のｂピクチャから予測される。

[0086]いくつかの例では、図３は、テクスチャビューコンポーネントを示すものと見なされ得る。たとえば、図２に示されているＩピクチャ、Ｐピクチャ、Ｂピクチャ、およびｂピクチャは、ビューの各々のためのテクスチャビューコンポーネントと見なされ得る。本開示で説明する技法によれば、図３に示されているテクスチャビューコンポーネントの各々について、対応する深度ビューコンポーネントがある。いくつかの例では、深度ビューコンポーネントは、対応するテクスチャビューコンポーネントについて図３に示されている様式と同様の様式で予測され得る。

[0087]２つのビューのコーディングもＭＶＣによってサポートされ得る。ＭＶＣの利点のうちの１つは、ＭＶＣエンコーダが３Ｄビデオ入力として３つ以上のビューをとり得、ＭＶＣデコーダがそのようなマルチビュー表現を復号し得ることである。したがって、ＭＶＣデコーダをもつどんなレンダラも、３つ以上のビューをもつ３Ｄビデオコンテンツを復号し得る。

[0088]上記で説明したように、ＭＶＣでは、（いくつかの事例では、同じ時間インスタンスをもつことを意味する）同じアクセスユニット中のピクチャ間でインタービュー予測が可能になる。非ベースビューのうちの１つの中のピクチャをコーディングするとき、ピクチャが異なるビュー中にあるが同じ時間インスタンス内にある場合、そのピクチャは参照ピクチャリストに追加され得る。インタービュー予測参照ピクチャは、任意のインター予測参照ピクチャとまったく同様に、参照ピクチャリストの任意の位置に入れられ得る。図３に示されているように、ビューコンポーネントは、参照のために他のビュー中のビューコンポーネントを使用することができる。ＭＶＣでは、別のビュー中のビューコンポーネントがインター予測参照であるかのように、インタービュー予測が実現される。

[0089]ＭＶＣでは、同じアクセスユニット中の（すなわち、同じ時間インスタンスをもつ）ピクチャの間でインタービュー予測が可能になる。非ベースビューのうちの１つの中のピクチャをコーディングするとき、ピクチャが異なるビュー中にあるが同じ時間インスタンスをもつ場合、そのピクチャは参照ピクチャリストに追加され得る。インタービュー予測参照ピクチャは、任意のインター予測参照ピクチャとまったく同様に、参照ピクチャリストの任意の位置に入れられ得る。

[0090]図３に示されているように、ビューコンポーネントは、参照のために他のビュー中のビューコンポーネントを使用することができる。これはインタービュー予測と呼ばれる。ＭＶＣでは、別のビュー中のビューコンポーネントがインター予測参照であるかのように、インタービュー予測が実現される。

[0091]マルチビュービデオコーディングのコンテキストでは、２種類の動きベクトルがあり、一方は、時間参照ピクチャを指す通常動きベクトルである。対応する時間インター予測は、動き補償された予測（ＭＣＰ：motion-compensated prediction）である。他方のタイプの動きベクトルは、異なるビュー中のピクチャ（すなわち、インタービュー参照ピクチャ）を指すディスパリティ動きベクトルである。対応するインター予測は、ディスパリティ補償された予測（ＤＣＰ：disparity-compensated prediction）である。

[0092]ビデオデコーダ３０は、複数のＨＥＶＣインターコーディングモードを使用してビデオを復号し得る。ＨＥＶＣ規格では、予測ユニット（ＰＵ）のために、それぞれ、マージモード（スキップはマージの特殊な場合と見なされる）および高度動きベクトル予測（ＡＭＶＰ）モードと称される２つのインター予測モードがある。ＡＭＶＰモードまたはマージモードのいずれかでは、ビデオデコーダ３０は、複数の動きベクトル予測子のための動きベクトル（ＭＶ）候補リストを維持する。現在のＰＵの（１つまたは複数の）動きベクトルならびにマージモードにおける参照インデックスは、ＭＶ候補リストから１つの候補をとることによって生成され得る。

[0093]ＭＶ候補リストは、たとえば、マージモードのための最高５つの候補とＡＭＶＰモードのための２つのみの候補とを含んでいる。マージ候補は、動き情報のセット、たとえば、参照ピクチャリスト（リスト０およびリスト１）と参照インデックスの両方に対応する動きベクトルを含んでいることがある。マージ候補がマージインデックスによって識別された場合、参照ピクチャは現在のブロックの予測のために使用され、ならびに、関連する動きベクトルが決定される。しかしながら、リスト０またはリスト１のいずれかからの各潜在的予測方向についてのＡＭＶＰモード下で、参照インデックスは、ＡＭＶＰ候補が動きベクトルのみを含んでいるので、ＭＶ候補リストへＭＶＰインデックスとともに明示的にシグナリングされる必要がある。ＡＭＶＰモードでは、選択された動きベクトルと、ＭＶＰインデックスに対応する動きベクトル予測子との間の動きベクトル差分がさらにシグナリングされる。上記でわかるように、マージ候補は動き情報のフルセットに対応し、ＡＭＶＰ候補は、特定の予測方向および参照インデックスのためのただ１つの動きベクトルを含んでいる。

[0094]上記で導入されるように、ビデオデコーダ３０は、ＨＥＶＣベース３Ｄビデオコーディング規格に従ってコーディングされたビデオを復号し得る。現在、ＶＣＥＧおよびＭＰＥＧのジョイントコラボレーションチームオン３Ｄビデオコーディング（ＪＣＴ−３Ｃ）は、ＨＥＶＣに基づく３ＤＶ規格を開発中であり、それのために、規格化作業の一部は、ＨＥＶＣに基づくマルチビュービデオコーデック（ＭＶ−ＨＥＶＣ）と、ＨＥＶＣに基づく３Ｄビデオコーディング（３Ｄ−ＨＥＶＣ）のための別の部分との規格化を含む。３Ｄ−ＨＥＶＣでは、コーディングユニット／予測ユニットレベルにおけるコーディングツールを含む新たなコーディングツールが、テクスチャビューと深度ビューの両方に関して含められ、サポートされ得る。３Ｄ−ＨＥＶＣのための最新のソフトウェア３Ｄ−ＨＴＭが以下のリンクからダウンロードされ得る。
［３Ｄ−ＨＴＭ ｖｅｒｓｉｏｎ９．０ｒ１］：
https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM-9.0r1/

[0095]最新の参照ソフトウェア記述が以下、すなわち、Ｌｉ Ｚｈａｎｇ、Ｇｅｒｈａｒｄ Ｔｅｃｈ、Ｋｒｚｙｓｚｔｏｆ Ｗｅｇｎｅｒ、Ｓｅｈｏｏｎ Ｙｅａ、「Test Model 6 of 3D-HEVC and MV-HEVC」、ＪＣＴ３Ｖ−Ｆ１００５、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３とＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１とのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、第６回会議、ジュネーブ、スイス、２０１３年１１月で入手可能である。それは、以下のリンクからダウンロードされ得る。
http://phenix.it-sudparis.eu/jct2/doc_end_user/current_document.php?id=1636

[0096]３Ｄ−ＨＥＶＣの最新のワーキングドラフトが以下、すなわち、Ｇｅｒｈａｒｄ Ｔｅｃｈ、Ｋｒｚｙｓｚｔｏｆ Ｗｅｇｎｅｒ、Ｙｉｎｇ Ｃｈｅｎ、Ｓｅｈｏｏｎ Ｙｅａ、「3D-HEVC Draft Text 2」、ＪＣＴ３Ｖ−Ｆ１００１、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３とＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１とのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、第６回会議、ジュネーブ、スイス、２０１３年１１月で入手可能である。それは、以下のリンクからダウンロードされ得る。
http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/6_Geneva/wg11/JCT3V-F1001-v4.zip

[0097]ＨＥＶＣ規格に従ってビデオを復号することの一部として、ビデオデコーダ３０は、隣接ブロックベースディスパリティベクトル導出（ＮＢＤＶ）を実施するように構成され得る。ＮＢＤＶは、すべてのビューについてテクスチャ優先コーディング順序を使用する３Ｄ−ＨＥＶＣにおけるディスパリティベクトル導出方法である。現在の３Ｄ−ＨＥＶＣの設計では、ＮＢＤＶから導出されたディスパリティベクトルは、参照ビューの深度マップから深度データを取り出すことによって、さらに改良され得る。

[0098]ビデオデコーダ３０は、２つのビュー間の変位の推定量（an estimator）として、ディスパリティベクトル（ＤＶ）を使用し得る。隣接ブロックが、ビデオコーディングにおいてほとんど同じ動き／ディスパリティ情報を共有するので、現在のブロックは、良好な予測子として、隣接ブロック中の動きベクトル情報を使用することができる。この考えに従って、ＮＢＤＶは、異なるビューにおけるディスパリティベクトルを推定するために、隣接ディスパリティ情報を使用する。

[0099]ＮＢＤＶを実施することの一部として、いくつかの空間隣接ブロックおよび時間隣接ブロックは、最初に定義される。ビデオデコーダ３０は、次いで、現在のブロックと候補ブロックとの間の相関の優先度によって決定されたあらかじめ定義された順序で、それらの各々を検査し得る。ディスパリティ動きベクトル（すなわち、動きベクトルはインタービュー参照ピクチャを指す）が候補中で発見されると、ディスパリティ動きベクトルはディスパリティベクトルに変換され、関連するビュー順序インデックスも返される。隣接ブロックの２つのセットが利用される。一方のセットは、空間隣接ブロックからのものであり、他方のセットは、時間隣接ブロックからのものである。

[00100]３Ｄ−ＨＥＶＣは、ＪＣＴ３Ｖ−Ａ００９７において提案されたＮＢＤＶ方法を最初に採用した。暗黙的ディスパリティベクトル（implicit disparity vector）が、ＪＣＴＶＣ−Ａ０１２６中に簡略化されたＮＢＤＶとともに含まれた。さらに、ＪＣＴ３Ｖ−Ｂ００４７では、ＮＢＤＶは、復号されたピクチャバッファに記憶された暗黙的ディスパリティベクトルを除去することによってさらに簡略化されるが、また、ＲＡＰピクチャ選択を用いてコーディング利得を改善した。以下のドキュメントは、３Ｄ−ＨＥＶＣおよびＮＤＢＶの態様を説明する。
・ ＪＣＴ３Ｖ−Ａ００９７：3D-CE5.h: Disparity vector generation results、Ｌ．Ｚｈａｎｇ、Ｙ．Ｃｈｅｎ、Ｍ．Ｋａｒｃｚｅｗｉｃｚ（Ｑｕａｌｃｏｍｍ）
・ ＪＣＴ３Ｖ−Ａ０１２６：3D-CE5.h: Simplification of disparity vector derivation for HEVC-based 3D video coding、Ｊ．Ｓｕｎｇ、Ｍ．Ｋｏｏ、Ｓ．Ｙｅａ（ＬＧ）
・ ＪＣＴ３Ｖ−Ｂ００４７：3D-CE5.h related: Improvements for disparity vector derivation、Ｊ．Ｋａｎｇ、Ｙ．Ｃｈｅｎ、Ｌ．Ｚｈａｎｇ、Ｍ．Ｋａｒｃｚｅｗｉｃｚ（Ｑｕａｌｃｏｍｍ）
・ ＪＣＴ３Ｖ−Ｄ０１８１：CE2: CU-based Disparity Vector Derivation in 3D-HEVC、Ｊ．Ｋａｎｇ、Ｙ．Ｃｈｅｎ、Ｌ．Ｚｈａｎｇ、Ｍ．Ｋａｒｃｚｅｗｉｃｚ（Ｑｕａｌｃｏｍｍ）

[00101]図４は、１つのコーディングユニットに対する空間動きベクトルネイバー（spatial motion vector neighbors）の一例を示す。ＮＢＤＶのいくつかの実装形態では、５つの空間隣接ブロックがディスパリティベクトル導出のために使用される。それらは、図４に示されているＡ０、Ａ１、Ｂ０、Ｂ１またはＢ２、すなわち、１つのコーディングユニットに対する空間動きベクトルネイバーによって示されている、現在の予測ユニット（ＰＵ）をカバーするコーディングユニット（ＣＵ）の左下ブロック、左ブロック、右上ブロック、上ブロック、および左上ブロックである。それらは、ＨＥＶＣにおけるＭＥＲＧＥ／ＡＭＶＰモードにおいて使用されるものと同じであることに留意されたい。したがって、追加のメモリアクセスが必要とされない。

[00102]時間隣接ブロックを検査するために、ビデオデコーダ３０は候補ピクチャリストの構成プロセスを実施する。現在のビューからの最高２つの参照ピクチャが、候補ピクチャとして扱われ得る。コロケートされた（co-located）参照ピクチャが最初に候補ピクチャリストに挿入され、候補ピクチャの残りが参照インデックスの昇順で続く。両方の参照ピクチャリスト中で同じ参照インデックスをもつ参照ピクチャが利用可能であるとき、コロケートされたピクチャの同じ参照ピクチャリスト中の参照ピクチャが、他の参照ピクチャに先行する。候補ピクチャリスト中の候補ピクチャごとに、時間隣接ブロックを導出するために３つの候補領域が決定される。

[00103]ブロックがインタービュー動き予測でコーディングされるとき、ビデオデコーダ３０は、異なるビュー中の対応するブロックを選択するために、ディスパリティベクトルを導出する。暗黙的ディスパリティベクトル（ＩＤＶ、または別名導出されたディスパリティベクトル）は、インタービュー動き予測において導出されたディスパリティベクトルを指す。ブロックが動き予測でコーディングされても、導出されたディスパリティベクトルは、後続のブロックをコーディングする目的のために破棄されない。

[00104]３Ｄ−ＨＴＭ７．０および３Ｄ−ＨＴＭの後のバージョンの現在の設計では、ＮＢＤＶプロセスは、時間隣接ブロック中のディスパリティ動きベクトルと、空間隣接ブロック中のディスパリティ動きベクトルと、次いでＩＤＶとを、順に検査する。ディスパリティ動きベクトルまたはＩＤＶが発見されると、プロセスは終了する。さらに、ＮＢＤＶプロセスにおいて検査される空間隣接ブロックの数は、さらに２に低減される。

[00105]ビデオデコーダ３０はまた、深度情報にアクセスすることを用いて、ＮＢＤＶの改良（ＮＢＤＶ−Ｒ）を実施し得る。１つのディスパリティベクトルがＮＢＤＶプロセスから導出されるとき、それは、参照ビューの深度マップから深度データを取り出すことによってさらに改良される。改良プロセスは、以下の２つのステップを含む。最初に、ビデオデコーダ３０は、ベースビューなど、前にコーディングされた参照深度ビュー中の導出されたディスパリティベクトルによって、対応する深度ブロックの位置を特定する。対応する深度ブロックのサイズは現在のＰＵのサイズと同じであり得る。ビデオデコーダ３０は、次いで、対応する深度ブロックの４つのコーナーピクセルから１つの深度値を選択し、それを、改良されたディスパリティベクトルの水平成分に変換する。ディスパリティベクトルの垂直成分は不変である。

[00106]いくつかの実装形態では、改良されたディスパリティベクトルは、たとえば、インタービュー動き予測のために使用され得、改良されていないディスパリティベクトルはインタービュー残差予測のために使用され得る。さらに、改良されたディスパリティベクトルは、それが後方ビュー合成予測モード（backward view synthesis prediction mode）を用いてコーディングされる場合、１つのＰＵの動きベクトルとして記憶され得る。いくつかの実装形態では、ベースビューの深度ビューコンポーネントは、常に、ＮＢＤＶプロセスから導出されたビュー順序インデックスの値にかかわらずアクセスされることになる。

[00107]ビデオデコーダ３０はまた、ビュー間の残差相関を活用するコーディングツールである、ＡＲＰを実施するように構成され得る。ＡＲＰでは、参照ビューにおける動き補償のために現在のビューにおける動き情報をアラインすること（aligning）によって残差予測子が生成される。さらに、ビュー間の品質差を補償するために、重み付け係数が導入される。１つのブロックについてＡＲＰが有効にされるとき、現在の残差と残差予測子との間の差がシグナリングされる。現在、ＡＲＰは、Ｐａｒｔ＿２Ｎ×２Ｎに等しいパーティションモードを用いたインターコーディングされたＣＵのみに適用され得る。ＡＲＰは、ルーマ（Ｙ）成分とクロマ（ＣｂおよびＣｒ）成分の両方について適用される。以下の説明では、１つのブロック（またはピクセル）に対する（加算、減算などの）演算は、ブロック（またはピクセル）中の各ピクセルの各成分（Ｙ、ＣｂおよびＣｒ）に対する演算を意味する。ルーマ成分およびクロマ成分のためのプロセスを区別する必要があるとき、ルーマ成分のためのプロセスはルーマＡＲＰ（サブＰＵ ＡＲＰ）と呼ばれ、クロマ成分のためのプロセスはクロマＡＲＰ（サブＰＵ ＡＲＰ）と呼ばれる。

[00108]図５は、ＪＣＴ３Ｖ−Ｄ０１７７において提案されている、第４回ＪＣＴ３Ｖ会議において採用された、３Ｄ−ＨＥＶＣにおける時間ＡＲＰのための例示的な予測構造を示す。図５は、マルチビュービデオコーディングにおける時間残差についてのＡＲＰの予測構造（すなわち、１つの参照ピクチャリスト中の現在の参照ピクチャが時間参照ピクチャである）を示す。

[00109]図５に示されているように、ビデオデコーダ３０は、コーディングされている現在のブロックの予測における後続のブロックを識別する。現在のブロックはＣｕｒｒ１５０として図５に示されている。Ｂａｓｅ１５１は、ディスパリティベクトル（ＤＶ１５２Ａ）によって導出された参照／ベースビュー中の参照ブロックを表す。ＣｕｒｒＴＲｅｆ１５３は、現在のブロックの時間動きベクトル（ＴＭＶ１５４Ａ）によって導出されたブロックＣｕｒｒ１５０と同じビュー中のブロックを表す。ＢａｓｅＴＲｅｆ１５５は、現在のブロックの時間動きベクトル（ＴＭＶ１５４Ｂ）によって導出されたブロックＢａｓｅ１５１と同じビュー中のブロックを表す。したがって、ＴＭＶ１５４ＡおよびＴＭＶ１５４Ｂは同じ動きベクトルに対応し、それらがｘ軸およびｙ軸に沿った同じ量の変位を識別することを意味する。ＢａｓｅＴＲｅｆ１５５とＣｕｒｒ１５０との間の相対ロケーションの差は、ＴＭＶ＋ＤＶのベクトルを用いて表され得る。ＣｕｒｒＴＲｅｆ１５３とＢａｓｅＴＲｅｆ１５５との間の相対ロケーションの差は、ディスパリティベクトルＤＶ１５２Ｂによって表され得る。ＴＭＶ＋ＤＶおよびＤＶ１５２Ｂは、様々なブロック間の関係を示すために図５中に与えられ、ビデオデコーダ３０によって導出または使用されるベクトルに必ずしも対応するとは限らない。

[00110]時間ＡＲＰを実施するとき、ビデオデコーダ３０はＢａｓｅＴＲｅｆ−Ｂａｓｅとして残差予測子を計算し得、ここで、減算演算は、示されたピクセルアレイの各ピクセルに適用される。ビデオデコーダ３０は、残差予測子に重み付け係数（ｗ）を乗算し得る。したがって、ビデオデコーダ３０によって決定された現在のブロックの最終予測子はＣｕｒｒＴＲｅｆ＋ｗ＊（Ｂａｓｅ−ＢａｓｅＴＲｅｆ）として示される。

[00111]図５の例は単方向予測の場合を示す。双方向予測の場合に拡張するとき、ビデオデコーダ３０は、各参照ピクチャリストのために上記のステップを適用し得る。したがって、双方向予測の場合、ビデオデコーダ３０は、２つの異なる予測ブロックのために２つの残差予測子を決定し得る。

[00112]図６は、現在のブロック１６０と、対応するブロック１６１と、動き補償されたブロック１６２との間の例示的な関係を示す。ビデオデコーダ３０は、最初にターゲット参照ビュー（Ｖ₀）を指すディスパリティベクトル（ＤＶ１６３）を取得することによって、ＡＲＰを実施し得る。ビデオデコーダ３０は、たとえば、現在の３Ｄ−ＨＥＶＣにおいて指定されている技法のいずれかを使用して、ＤＶ１６３を取得し得る。同じアクセスユニット内の参照ビューＶ₀のピクチャ中で、ビデオデコーダ３０は、ＤＶ１６３を使用して、対応するブロック１６１の位置を特定し得る。ビデオデコーダ３０は、参照ブロック１６１のための動き情報を導出するために、現在のブロック１６０の動き情報を再利用し得る。たとえば、ビデオデコーダ３０が、現在のブロック１６０を予測するために使用された動きベクトル１６４Ａを使用した場合、ビデオデコーダ３０は、対応するブロック１６１を予測するために、動きベクトル１６４Ｂを使用し得る。動きベクトル１６４Ａおよび動きベクトル１６４Ｂは、同じ動きベクトルの２つの異なるインスタンスを表すことを意図される。

[00113]ビデオデコーダ３０は、残差ブロックを導出するために、現在のブロック１６０をコーディングするために使用されるものと同じ動きベクトルと、参照ブロックのための参照ビュー中の導出された参照ピクチャとに基づいて、対応するブロック１６１のために動き補償を適用し得る。ビデオデコーダ３０は、現在のビュー（Ｖ_m）の参照ピクチャと同じＰＯＣ（ピクチャ順序カウント）値を有する参照ビュー（Ｖ₀）中の参照ピクチャを、対応するブロックの参照ピクチャとして選択する。ビデオデコーダ３０は、重み付けされた残差ブロックを得るために残差ブロックに重み付け係数を適用し、予測されたサンプルに重み付けされた残差ブロックの値を加算する。

[00114]ビデオデコーダ３０はまた、インタービューＡＲＰを実施するように構成され得る。時間ＡＲＰと同様に、現在の予測ユニットがインタービュー参照ピクチャを使用するとき、インタービュー残差の予測が有効にされる。最初に、異なるアクセスユニット内のインタービュー残差が計算され、次いで、計算された残差情報が、現在のブロックのインタービュー残差を予測するために使用され得る。この技法は、ＪＣＴ３Ｖ−Ｆ０１２３において提案され、３Ｄ−ＨＥＶＣに採用された。

[00115]図７は、インタービューＡＲＰのための例示的な予測構造を示す。図７に示されているように、インタービューＡＲＰの場合、ビデオデコーダ３０は、現在のブロック１７０のための３つの関係するブロックを識別する。Ｂａｓｅ１７１は、現在のブロック１７０のディスパリティ動きベクトル（ＤＭＶ１７２Ａ）によって位置を特定される参照ビュー中の参照ブロックを表す。ＢａｓｅＲｅｆ１７３は、時間動きベクトルｍｖＬＸ１７４Ａと、利用可能な場合、Ｂａｓｅ１７１によって含まれている参照インデックスとによって位置を特定される参照ビュー中のＢａｓｅ１７１の参照ブロックを表す。ＣｕｒｒＲｅｆ１７５は、Ｂａｓｅ１７１からの時間動き情報を再利用することによって識別される現在のビュー中の参照ブロックを表す。したがって、ビデオデコーダ３０は、ｍｖＬＸ１７４Ｂを使用してＣｕｒｒＲｅｆ１７５の位置を特定し得、ここで、ｍｖＬＸ１７４ＡおよびｍｖＬＸ１７４Ｂは、同じ動きベクトルの２つのインスタンスを表す。ＤＭＶ１７２Ｂは、Ｃｕｒｒ１７０とＢａｓｅ１７１との間のディスパリティがＣｕｒｒＲｅｆ１７５とＢａｓｅＲｅｆ１７３との間のディスパリティに等しいことを示すために図７に含まれているＤＭＶ１７２Ａに等しい。ＤＭＶ１７２Ｂは、実際は、ビデオデコーダ３０によって使用または生成されるディスパリティ動きベクトルに対応しないことがある。

[00116]識別された３つのブロックを用いて、ビデオデコーダ３０は、現在のＰＵ（すなわちＣｕｒｒ１７０）のための残差信号の残差予測子をＣｕｒｒＲｅｆとＢａｓｅＲｅｆとの間の差として計算し得る。さらに、インタービュー予測子は重み付け係数（ｗ）を乗算され得る。したがって、ビデオデコーダ３０によって決定された現在のブロック（Ｃｕｒｒ１７０）の最終予測子はＢａｓｅ＋ｗ＊（ＣｕｒｒＲｅｆ−ＢａｓｅＲｅｆ）として示される。

[00117]ビデオデコーダ３０は、時間残差予測のためのＡＲＰのいくつかの知られている設計の場合のように、３つの相対ブロックを生成するために双線形フィルタ処理（bi-linear filtering）を使用し得る。さらに、Ｂａｓｅ１７１によって含まれている時間動きベクトルが、現在のＰＵの第１の利用可能な時間参照ピクチャの異なるアクセスユニット中にある参照ピクチャを指すとき、ビデオデコーダ３０は、時間動きベクトルを第１の利用可能な時間参照ピクチャにスケーリングし得、スケーリングされた動きベクトルは、異なるアクセスユニット中の２つのブロックの位置を特定するために使用され得る。

[00118]ＡＲＰがインタービュー残差について適用されるとき、現在のＰＵはインタービューＡＲＰを使用しており、ＡＲＰが時間残差について適用されるとき、現在のＰＵは時間ＡＲＰを使用している。

[00119]以下の説明では、１つの参照ピクチャリストのための対応する参照が時間参照ピクチャであり、ＡＲＰが適用される場合、それは時間ＡＲＰとして示される。さもなければ、１つの参照ピクチャリストのための対応する参照がインタービュー参照ピクチャであり、ＡＲＰが適用される場合、それはインタービューＡＲＰとして示される。

[00120]上記で紹介したように、ビデオデコーダ３０は、残差予測子に重み付け係数を乗算し得る。一般に、３つの重み付け係数（すなわち、０、０．５、および１）がＡＲＰにおいて使用されるが、より多いまたはより少ない重み付け係数ならびに異なる重み付け係数も使用され得る。ビデオエンコーダ２０は、たとえば、現在のＣＵのための最小レートひずみコストにつながる重み付け係数を最終重み付け係数として選択し、ＣＵレベルでビットストリーム中で、対応する重み付け係数インデックス（それぞれ重み付け係数０、１、および０．５に対応する０、１および２）をシグナリングし得る。１つのＣＵにおけるすべてのＰＵ予測は同じ重み付け係数を共有し得る。重み付け係数が０に等しいとき、ＡＲＰは現在のＣＵのために使用されない。

[00121]ビデオデコーダ３０は、動きベクトルスケーリングを介して参照ピクチャ選択を実施するように構成され得る。ＪＣＴ３Ｖ−Ｃ００４９では、非０重み付け係数を用いてコーディングされた予測ユニットの参照ピクチャは、ブロックごとに異なり得る。したがって、参照ビューとは異なるピクチャが、対応するブロックの動き補償されたブロック（すなわち、図５中のＢａｓｅＴＲｅｆ）を生成するためにアクセスされる必要があり得る。重み付け係数が０に等しくないとき、時間残差の場合、現在のＰＵの動きベクトルは、残差生成プロセスと残差予測子生成プロセスの両方のために動き補償を実施する前に、固定ピクチャに向かって（towards a fixed picture）スケーリングされる。ＡＲＰがインタービュー残差に適用されるとき、参照ブロック（すなわち、図７中のＢａｓｅ）の時間動きベクトルは、残差生成プロセスと残差予測子生成プロセスの両方のために動き補償を実施する前に、固定ピクチャに向かってスケーリングされる。

[00122]両方の場合（すなわち、時間残差またはインタービュー残差）について、固定ピクチャは、各参照ピクチャリストの第１の利用可能な時間参照ピクチャとして定義される。復号された動きベクトルが固定ピクチャを指さないとき、それは、最初にスケーリングされ、次いでＣｕｒｒＴＲｅｆおよびＢａｓｅＴＲｅｆを識別するために使用される。

[00123]ＡＲＰのために使用されるそのような参照ピクチャはターゲットＡＲＰ参照ピクチャと呼ばれる。現在のスライスがＢスライスであるとき、ターゲットＡＲＰ参照ピクチャは参照ピクチャリストに関連することに留意されたい。したがって、２つのターゲットＡＲＰ参照ピクチャが利用され得る。

[00124]ビデオデコーダ３０は、ターゲットＡＲＰ参照ピクチャの利用可能性検査を実施し得る。１つの参照ピクチャリストＸ（Ｘは０または１である）に関連するターゲットＡＲＰ参照ピクチャは、ＲｐＲｅｆＰｉｃＬＸによって示され得、ＮＢＤＶプロセスから導出されたビュー順序インデックスに等しいビュー順序インデックス、およびＲｐＲｅｆＰｉｃＬＸの同じＰＯＣ値をもつビュー中のピクチャは、ＲｅｆＰｉｃＩｎＲｅｆＶｉｅｗＬＸによって示され得る。以下の条件のうちの１つが偽であるとき、ビデオデコーダ３０は、参照ピクチャリストＸについて無効にされるＡＲＰを無効にし得、（１）ＲｐＲｅｆＰｉｃＬＸが利用不可能である、（２）ＲｅｆＰｉｃＩｎＲｅｆＶｉｅｗＬＸが復号されたピクチャバッファ内に記憶されない、（３）ＲｅｆＰｉｃＩｎＲｅｆＶｉｅｗＬＸが、ＮＢＤＶプロセスからのＤＶまたは現在のブロックに関連するＤＭＶによって位置を特定された対応するブロック（すなわち、図５および図７中のＢａｓｅ）の参照ピクチャリストのいずれにも含まれず、ＡＲＰはこの参照ピクチャリストについて無効にされ得る。

[00125]ＡＲＰが適用されるとき、ビデオデコーダ３０は、残差および残差予測子を生成するとき、双線形フィルタを使用し得る。すなわち、ＡＲＰプロセスに関与する現在のブロックを除く３つのブロックが、双線形フィルタを使用して生成され得る。

[00126]ビデオデコーダ３０はまた、ブロックレベルＡＲＰを実施し得る。１つのＰＵ内のすべてのブロックが同じ動き情報を共有する上記の説明とは対照的に、ＰＵレベルＡＲＰと呼ばれることがある、ブロックレベルＡＲＰにおいて、ビデオデコーダ３０は１つのＰＵをいくつかの８×８ブロックに分割し、各８×８ブロックは、ＡＲＰを実施するためのそれ自体の動き情報を有する。時間またはインタービューのいずれかのブロックレベルＡＲＰが有効にされるとき、各ＰＵは、最初に、いくつかのブロックに分割され、各ブロックは現在のＰＵと同じ動き情報を共有する。しかしながら、導出された動きベクトル（すなわち、時間ＡＲＰにおけるディスパリティベクトルまたはインタービューＡＲＰにおける時間動きベクトル）は、８×８ブロックごとに更新され得る。

[00127]図８Ａは、ブロックレベル時間ＡＲＰの例示的な予測構造を示す。図８Ａの例では、Ｃｕｒｒ１８０は、図８Ａ中でＡ〜Ｄと標示された４つの８×８ブロックに分割されたＰＵを表す。Ｂａｓｅ１８１は、Ｃｕｒｒ１８０のディスパリティベクトルによって導出された参照／ベースビュー中の（Ａ’〜Ｄ’と標示された）４つの参照ブロックを表す。Ｂａｓｅｄ１８１のブロックＡ’は、（ＤＶ［０］として図８Ａに示された）ブロックＡのディスパリティベクトルを使用して識別され、ブロックＢ’は、（ＤＶ［１］として図８Ａに示された）ディスパリティベクトルを使用して識別される。図８Ａには明示的に示されていないが、ブロックＣ’およびＤ’は、ブロックＣおよびＤのディスパリティベクトルを使用して同様に識別され得る。

[00128]導出された動きベクトル（すなわち、時間ＡＲＰにおけるディスパリティベクトル）は８×８ブロックごとに更新され得る。時間ＡＲＰでは、（図８Ａにおいて、ｉ番目の８×８ブロックの場合、ＤＶ［ｉ］によって示される）デフォルトｄｅｒｉｖｅｄＭｖは、最初に、ＮＢＤＶプロセスからのＤＶであるように設定される。ＣｕｒｒＲｅｆ内のｉ番目の８×８ブロックの中心位置をカバーするブロックがディスパリティ動きベクトルを含んでいるとき、ＤＶ［ｉ］は、そのディスパリティ動きベクトルになるように更新される。したがって、図８Ａに示されているように、ブロックＡ’〜Ｄ’は、ブロックＡ〜Ｄが互いに対して配置されるのとは別様に、互いに対して配置され（be positioned）得る。ＣｕｒｒＲｅｆ１８３は、Ｃｕｒｒ１８０の（図８Ａ中でｍｖＬＸ１８４Ａとして示された）時間動きベクトルによって導出されたｃｕｒｒ１８０と同じビュー中の４つのブロック（Ａ_P〜Ｄ_P）を表す。ＢａｓｅＲｅｆ１８５は、現在のブロックの時間動きベクトル（ｍｖＬＸ１８４Ｂ）によって導出されたＢａｓｅ１８１と同じビュー中の４つのブロック（Ａ_R〜Ｄ_R）を表す。図８Ａの例では、ｍｖＬＸ１８４ＡおよびｍｖＬＸ１８４Ｂは、同じ動きベクトルの２つの異なる適用例を表すことを意図される。すなわち、ｍｖＬＸ１８４ＡおよびｍｖＬＸ１８４Ｂは同じｘ成分とｙ成分とを有する。

[00129]残差予測子は、図８Ａの例では、ＢａｓｅＲｅｆ−Ｂａｓｅとして示され、ここで、減算演算は、示されたピクセルアレイの各ピクセルに適用される。重み付け係数（ｗ）が残差予測子にさらに乗算される。したがって、ビデオデコーダ３０によって決定されたブロックＡ〜Ｄのための最終予測子は、ＣｕｒｒＲｅｆ［Ｎ_P］＋ｗ＊（Ｂａｓｅ［Ｎ’］−ＢａｓｅＲｅｆ［Ｎ_R］）として示され、ＮはＡ〜Ｄに対応する。

[00130]図８Ｂは、ブロックレベルインタービューＡＲＰの例示的な予測構造を示す。図８Ｂの例では、ビデオデコーダ３０は、現在のブロック１８２の３つの関係するブロックを識別する。Ｂａｓｅ１８６は、現在のブロック１８２のディスパリティ動きベクトル（ＤＭＶ１８８Ａ）によって位置を特定される参照ビュー中の４つの参照ブロック（Ａ〜Ｄ）を表す。ＢａｓｅＲｅｆ１８７は、時間動きベクトルｍｖＬＸ［Ｎ］と、利用可能な場合、Ｂａｓｅ１８６によって含まれている参照インデックスとによって位置を特定される参照ビュー中のＢａｓｅ１８６の４つの参照ブロック（Ａ’〜Ｄ’）を表し、ここで、ＮはブロックＡ〜Ｄに対応する。インタービューＡＲＰでは、（図８Ｂ中で、ｉ番目の８×８ブロックの場合、ｍｖＬＸ［ｉ］によって示される）デフォルトｄｅｒｉｖｅｄＭｖは、現在のＡＲＰの場合のように、Ｂａｓｅの中心位置をカバーするブロックに関連する時間動きベクトルに設定され得る。Ｂａｓｅ内のｉ番目の８×８ブロックの中心位置をカバーするブロックが時間動きベクトルを含んでいるとき、ｍｖＬＸ［ｉ］は、その時間動きベクトルになるように更新される。したがって、図８Ａに示されているように、ブロックＡ’〜Ｄ’は、ブロックＡ〜Ｄが互いに対して配置されるのとは別様に、互いに対して配置され得る。

[00131]ＣｕｒｒＲｅｆ１８９は、Ｂａｓｅ１８６からの時間動き情報を再利用することによって識別される現在のビュー中の４つの参照ブロック（Ａ_R〜Ｄ_R）を表す。したがって、たとえば、ビデオデコーダ３０は、ｍｖＬＸ［Ａ］を使用してＡ_Rの位置を特定し、ｍｖＬＸ［Ｂ］を使用してＢ_Rの位置を特定し、以下同様である。３つの識別されたブロックを用いて、ビデオデコーダ３０は、現在のＰＵの残差信号の残差予測子をＣｕｒｒＲｅｆ−ＢａｓｅＲｅｆ間の差として計算し得る。それは、異なるアクセスユニット中にあり得る。さらに、インタービュー予測子は重み付け係数（ｗ）を乗算され得る。したがって、ビデオデコーダ３０によって決定された現在のブロックの最終予測子はＢａｓｅ［Ｎ］＋ｗ＊（ＣｕｒｒＲｅｆ［Ｎ_R］−ＢａｓｅＲｅｆ［Ｎ’］）として示される。

[00132]上記のように、ブロックベース時間ＡＲＰとブロックベースインタービューＡＲＰの両方について、現在のＰＵの動きベクトルによって位置を特定された参照ブロックのブロックレベル（たとえば、８×８）動き情報のみが、最終残差予測子を生成するためにアクセスされる。

[00133]ビデオデコーダ３０はまた、サブＰＵレベルインタービュー動き予測を実施し得る。ＪＣＴ３Ｖ−Ｆ０１１０では、新しいマージング候補を生成するために、サブＰＵレベルインタービュー動き予測方法が提案されている。新しい候補がマージ候補リストに追加される。サブＰＵマージング候補と称される新しい候補は、以下の方法を使用してビデオデコーダ３０によって導出され得る。以下の説明では、現在のＰＵのサイズはｎＰＳＷ×ｎＰＳＨによって示され、シグナリングされたサブＰＵサイズはＮ×Ｎによって示され、最終サブＰＵサイズはｓｕｂＷ×ｓｕｂＨによって示される。ビデオデコーダ３０は、最初に、ＰＵサイズとシグナリングされたサブＰＵサイズとに応じて、現在のＰＵを１つまたは複数のサブＰＵに分割する。

[00134]ビデオデコーダ３０は、次に、各参照ピクチャリストについて、デフォルト動きベクトルｔｍｖＬＸを（０，０）に、および参照インデックスｒｅｆＬＸを−１に設定する（Ｘは０および１である）。ラスタ走査順序（raster scan order）における各サブＰＵについて、ビデオデコーダ３０は以下を行う。
○ 以下によって参照サンプルロケーション（ｘＲｅｆＳｕｂ，ｙＲｅｆＳｕｂ）を取得するために、ＤｏＮＢＤＶまたはＮＢＤＶプロセスからのＤＶを現在のサブＰＵの中間位置に加算する。

（ｘＲｅｆＳｕｂ，ｙＲｅｆＳｕｂ）をカバーする参照ビュー中のブロックは、現在のサブＰＵのための参照ブロックとして使用され得る。
○ 識別された参照ブロックについて、
− それが時間動きベクトルを使用してコーディングされる場合、以下が適用される。
・ 現在のサブＰＵのための候補動きパラメータとして、関連する動きパラメータが使用され得る。
・ ｔｍｖＬＸおよびｒｅｆＬＸが現在のサブＰＵの動き情報に更新される。
・ 現在のサブＰＵがラスタ走査順序において最初のサブＰＵでない場合、動き情報（ｔｍｖＬＸおよびｒｅｆＬＸ）はすべての前のサブＰＵによって継承される。
− そうでない場合（参照ブロックがイントラコーディングされる）、現在のサブＰＵの動き情報はｔｍｖＬＸおよびｒｅｆＬＸに設定され得る。

[00135]ビデオデコーダ３０はまた、サブＰＵレベルＡＲＰを実施するように構成され得る。サブＰＵレベルインタービュー動き予測が適用されるとき、ＰＵは複数のサブＰＵを含んでいることがあり、各サブＰＵはそれ自体の動き情報を有し、ＡＲＰは各サブＰＵについて実施され得る。異なるサブＰＵブロックサイズは、たとえば、４×４、８×８、および１６×１６が適用され得る。サブＰＵブロックのサイズはビューパラメータセット中に存在する。

[00136]図９は、サブＰＵレベルインタービュー動き予測の一例を示す。図９は、Ｖ１と呼ばれる現在のビュー、およびＶ０と呼ばれる参照ビューを示す。現在のＰＵ１９０は４つのサブＰＵ Ａ〜Ｄを含む。ビデオデコーダ３０は、４つの参照ブロックＡ_R〜Ｄ_Rを含む参照ブロック１９１の位置を特定するために、４つのサブＰＵ Ａ〜Ｄの各々のディスパリティベクトルを使用し得る。サブＰＵ Ａ〜Ｄのディスパリティベクトルは、ＭＶ［ｉ］として図９に示され、ここで、ｉはＡ〜Ｄに対応する。４つのサブＰＵの各々が一意のディスパリティベクトルを有するので、互いに対するサブＰＵ Ａ〜Ｄのロケーションは、互いに対する参照ブロックＡ_R〜Ｄ_Rのロケーションとは異なり得る。サブＰＵレベルインタービュー動き予測では、ビデオデコーダ３０は、サブＰＵを予測するために、参照ブロックの動きベクトルを使用し得る。参照ブロックＡ_R〜Ｄ_Rの動きベクトルは、ＭＶ［ｉ］として図９に示され、ここで、ｉはＡ〜Ｄに対応する。したがって、一例として、サブＰＵ Ａについて、ビデオデコーダ３０は、参照ブロックＡ_Rの位置を特定するためにＤＶ［Ａ］を使用し、参照ブロックＡ_RがＭＶ［Ａ］を使用してコーディングされたと決定し、サブＰＵ Ａのための予測ブロックの位置を特定するためにＭＶ［Ａ］を使用し得る。

[00137]図１０Ａは、サブＰＵレベル時間ＡＲＰのための例示的な予測構造を示す。図１０Ａの例では、ＰＵ（Ｃｕｒｒ２００）は（図１０Ａ中でＡ〜Ｄと標示された）４つのサブＰＵに分割される。サブＰＵレベル時間ＡＲＰの場合、ビデオデコーダ３０は、ＰＵレベルＡＲＰにおけるものと概して同じである、参照ビュー中の参照ブロック（Ｂａｓｅ２０１）を識別するために、Ｃｕｒｒ２００のすべてのサブＰＵのために同じディスパリティベクトル（ＤＶ２０２）を使用し得る。Ｂａｓｅ２０１は、サブＰＵ Ａ〜Ｄに対応するサブ参照ブロック（図１０Ａ中のＡ’〜Ｄ’）に再分割され（be sub-divided）得る。ビデオデコーダ３０は、たとえば、ＮＢＤＶ技法を使用して、ＤＶ２０２を導出し得る。ビデオデコーダ３０は、時間参照ブロック（図１０Ａ中のＡ_P〜Ｄ_P）を識別するために、サブＰＵ Ａ〜Ｄの各々の動き情報を使用する。サブＰＵ Ａ〜Ｄの動き情報は、ｉ番目のサブＰＵのためのＴＭＶ［ｉ］として図１０Ａに示され、ここで、ｉはＡ〜Ｄに対応する。ＴＭＶ［Ａ］は、たとえば、サブＰＵ Ａの時間動きベクトルを表し、ＴＭＶ［Ｃ］はサブＰＵ Ｃの動きベクトルを表す。図１０Ａに明示的に示されていないが、サブＰＵ ＢおよびサブＰＵ Ｄは、それぞれ、関連付けられた動きベクトルＴＭＶ［Ｂ］およびＴＭＶ［Ｄ］を同様に有することになる。

[00138]ビデオデコーダ３０は、図１０Ａ中でＢａｓｅＲｅｆ２０５として示されている、Ｂａｓｅ２０１の参照ブロックの位置を特定するために、サブＰＵ Ａ〜Ｄの動き情報（すなわち、ＴＭＶ［ｉ］、ｉ＝Ａ〜Ｄ）を再利用し得る。ＢａｓｅＲｅｆ２０５は４つのサブブロック（図１０Ａ中のＡ_R〜Ｄ_R）を含む。残差予測子は、図１０Ａの例では、ＢａｓｅＲｅｆ−Ｂａｓｅとして示され得、ここで、減算演算は、示されたピクセルアレイの各ピクセルに適用される。重み付け係数（ｗ）が残差予測子にさらに乗算される。したがって、ビデオデコーダ３０によって決定されたブロックＡ〜Ｄのための最終予測子は、ＣｕｒｒＲｅｆ［Ｎ_P］＋ｗ＊（Ｂａｓｅ［Ｎ’］−ＢａｓｅＲｅｆ［Ｎ_R］）として示され得、ＮはＡ〜Ｄに対応する。

[00139]図１０Ｂは、サブＰＵレベルインタービューＡＲＰの例示的な予測構造を示す。図１０Ｂの例では、ＰＵ（Ｃｕｒｒ２００）は（図１０Ｂ中でＡ〜Ｄと標示された）４つのサブＰＵに分割される。インタービューＡＲＰの場合、ビデオデコーダ３０は、参照ビュー中の参照ブロック（Ｂａｓｅ２０６）を識別するために、サブＰＵ Ａ〜Ｄの各々のディスパリティ動きベクトルを使用する。Ｂａｓｅ２０６は、図１０Ｂ中でＡ_P〜Ｄ_Pと標示された、４つのサブ参照ブロックを含む。サブＰＵ Ａ〜Ｄのディスパリティ動きベクトルは、ｉ番目のサブＰＵのためのＤＭＶ［ｉ］として図１０Ｂに示され、ここで、ｉはＡ〜Ｄに対応する。ＤＭＶ［Ａ］は、たとえば、サブＰＵ Ａのディスパリティ動きベクトルを表し、ＤＭＶ［Ｂ］はサブＰＵ Ｂのディスパリティ動きベクトルを表す。図１０Ｂに明示的に示されていないが、サブＰＵ ＣおよびサブＰＵ Ｄは、それぞれ、関連付けられたディスパリティ動きベクトルＤＭＶ［Ｃ］およびＤＭＶ［Ｄ］を同様に有することになる。

[00140]参照ブロック（すなわち、Ｂａｓｅ２０６）が（図１０Ｂ ｍｖＬＸ［ｉ］によって示された、ここで、ｉはＡ〜Ｄに対応する）時間動きベクトルを含んでいるとき、ビデオデコーダ３０は、参照ビュー中の現在のサブＰＵとそれの参照ブロックの両方のための時間参照ブロックを識別するために、時間動きベクトルを使用する。たとえば、ビデオデコーダ３０は、図１０Ｂ中のＡ_RであるＡ_Pのための参照ブロックの位置を特定するために、ならびに図１０Ｂ中のＡ’であるＡの参照ブロックの位置を特定するために、ｍｖＬＸ［Ａ］を使用する。ビデオデコーダ３０は、同様に、図１０Ｂ中のＣ_RであるＣ_Pのための参照ブロックの位置を特定するために、ならびに図１０Ｂ中のＣ’であるＣの参照ブロックの位置を特定するために、ｍｖＬＸ［Ｃ］を使用し得る。図１０Ｂには明示的に示されていないが、ビデオデコーダ３０は、同様に、Ｃ、Ｃ_P、Ｄ、およびＤ_Pのための参照ブロックの位置を特定し得る。

[00141]識別されたブロックを用いて、ビデオデコーダ３０は、ＣｕｒｒＲｅｆ［Ｎ’］−ＢａｓｅＲｅｆ［Ｎ_R］間の差として現在のＰＵ残差予測子を計算し得、ここで、ＮはＡ〜Ｄに対応する。さらに、インタービュー予測子は重み付け係数（ｗ）を乗算され得る。したがって、ビデオデコーダ３０によって決定された現在のブロックの最終予測子は、Ｂａｓｅ［Ｎ_P］＋ｗ＊（ＣｕｒｒＲｅｆ［Ｎ’］−ＢａｓｅＲｅｆ［Ｎ_R］）として示され得る。

[00142]ＡＲＰのいくつかの実装形態は、いくつかの潜在的問題を有する。一例として、ブロックが双予測されるいくつかのコーディングシナリオでは、ブロック（またはＰＵ、サブＰＵ）のために、４つの追加の参照ブロックが査定される必要があり得る。図１１によって示されている第１の例では、１つのブロックが双方向予測され、両方の予測方向がインタービュー参照ピクチャに対応するとき、インタービューＡＲＰは２回呼び出され、２つの追加の参照ブロックが各ＡＲＰのためにアクセスされる。

[00143]図１１は、３Ｄ−ＨＥＶＣにおける双方向インタービューＡＲＰのためにビデオデコーダ３０によってアクセスされる参照ブロックの一例を示す。図１１の例では、予測方向Ｘのディスパリティ動きベクトルは、ＤＭＶＸによって示され、ここで、Ｘ＝０または１である。予測方向Ｘの場合、現在のビュー中の参照ブロック（図１１中のＣｕｒｒＲｅｆＸ）が、参照ビュー中の参照ブロック（図１１中のＢａｓｅＸ）に関連する動き情報（図１１中のｍｖＢａｓｅＸ）によって識別され、ＤＭＶＸ＋ｍｖＢａｓｅＸによって識別される参照ビュー中のＢａｓｅＸの参照ブロック（図１１中のＢａｓｅＸＲｅｆ）が査定される。

[00144]図１２は、３Ｄ−ＨＥＶＣにおける時間ＡＲＰおよびインタービューＡＲＰのためにビデオデコーダ３０によってアクセスされる参照ブロックの一例を示す。図１２によって示されている第２の例では、一方のブロックが双方向予測され、１つの予測方向が時間参照ピクチャに対応し（時間動きベクトルがＴＭＶであり）、他方の予測方向がインタービュー参照ピクチャに対応する（ディスパリティ動きベクトルがＤＭＶである）とき、時間ＡＲＰとインタービューＡＲＰの両方が呼び出され、２つの追加の参照ブロックが、図１２に示されているように、各ＡＲＰのためにアクセスされる。

[00145]時間ＡＲＰでは、ＮＢＤＶプロセスを使用して導出されたＤＶによって識別される参照ビュー中の参照ブロック（図１２中のＢａｓｅ１）、およびＤＶ＋ＴＭＶによって識別される参照ビュー中のＢａｓｅ１の参照ブロック（図１２中のＢａｓｅ１ＴＲｅｆ）が査定される。インタービューＡＲＰでは、参照ビュー中の参照ブロック（図１２中のＢａｓｅ２）に関連する動き情報（図１２中のｍｖＢａｓｅ）によって識別される現在のビュー中の参照ブロック（図１２中のＣｕｒｒＲｅｆ）、およびＤＭＶ＋ｍｖＢａｓｅによって識別される参照ビュー中のＢａｓｅ２の参照ブロック（図１２中のＢａｓｅ２Ｒｅｆ）が査定される。

[00146]いくつかの知られている技法に従って、図１２のプロセスは、追加として査定される参照ブロックを低減するために、簡略化される。たとえば、時間ＡＲＰのための参照ビュー中の参照ブロック（すなわち、図１２中のＢａｓｅ１）を識別するために、ＮＢＤＶプロセスを使用して導出されるＤＶの代わりに、ＤＭＶが使用され得る。このようにして、ブロックＢａｓｅ１は、図１２中のブロックＢａｓｅ２と同じであり、Ｂａｓｅ１の追加の査定は必要とされない。したがって、第１の例において追加として査定される参照ブロックは、４から３に低減される。

[00147]しかしながら、上記の問題の第１の例では、査定すべき４つの追加の参照ブロックが依然としてある。これは、ＡＲＰ予測されるブロックのためにアクセスすることを必要とされるブロックの数が３から４に増加するというワーストケースをもたらす。

[00148]本開示は、追加として査定される参照ブロックを低減するために、ＡＲＰにおける上述の問題のうちのいくつかに対するソリューションを潜在的に提供する。一例として、第１のブロックが、（サブＰＵレベルＡＲＰを含む）ＡＲＰを用いてコーディングされ、双方向予測され、両方の予測方向が、インタービュー参照ピクチャである参照ピクチャを有するとき、ビデオデコーダ３０は、両方の予測方向（のインタービューＡＲＰ）のための現在のビュー中の現在のブロックの参照ブロックを識別するために、１つの単一の時間動きベクトルを使用し得ることが提案される。言い換えれば、両方の時間動きベクトル（たとえば、図１１に示されているｍｖＢａｓｅ０とｍｖＢａｓｅ１）は、ｍｖＢａｓｅであるように設定される。さらに、図１２中のＣｕｒｒＲｅｆ０とＣｕｒｒＲｅｆ１の両方とは対照的に、現在のブロックの１つの参照ブロックのみが決定される。この場合、図１３に示されているように、現在のビュー中の、２つの参照ブロックの代わりに、（図１３中にＣｕｒｒＲｅｆによって示されている）１つの参照ブロックのみが査定される。

[00149]図１３は、１つの単一の時間動きベクトルが双方向インタービューＡＲＰにおいてどのように使用され得るかの一例を示す。一例では、単一の時間動きベクトル（ｍｖＢａｓｅ）は、予測方向０のための参照ビュー中の参照ブロックに関連する時間動きベクトル（たとえば、ｍｖＢａｓｅ０）であるように設定され得る。さらに、ｍｖＢａｓｅ０が利用不可能であるとき、ＡＲＰは第１のブロックについて無効にされ得る。代替的に、ｍｖＢａｓｅ０が利用不可能であるとき、単一の動きベクトル（ｍｖＢａｓｅ）はゼロ動きベクトルであるように設定され得る。

[00150]図１３の例では、ビデオデコーダ３０は、２つの予測方向についてインタービューＡＲＰを実施し得る。予測方向０について、ビデオデコーダ３０は、Ｃｕｒｒのための第１のディスパリティ動きベクトル（ＤＭＶ０）、およびＣｕｒｒのための第２のディスパリティ動きベクトル（ＤＭＶ１）を決定する。ビデオデコーダ３０は、第１の対応するブロック（Ｂａｓｅ０）の位置を特定するためにＤＭＶ０を使用し、第２の対応するブロック（Ｂａｓｅ１）の位置を特定するためにＤＭＶ１を使用する。Ｂａｓｅ０およびＢａｓｅ１の動きベクトルから、ビデオデコーダ３０は、ＡＲＰのために使用すべき動きベクトル（ｍｖＢａｓｅ）を決定する。ビデオデコーダ３０がｍｖＢａｓｅを決定するために使用し得る様々なプロセスが、以下でさらに詳細に説明される。ｍｖＢａｓｅを使用して、ビデオデコーダ３０は、Ｃｕｒｒと同じビュー中の異なるピクチャ中の現在のブロックの参照ブロック（ＣｕｒｒＲｅｆ）を決定する。ｍｖＢａｓｅを使用して、ビデオデコーダ３０はまた、Ｂａｓｅ０のための参照ブロック（Ｂａｓｅ０Ｒｅｆ）、およびＢａｓｅ１のための参照ブロック（Ｂａｓｅ１Ｒｅｆ）を決定する。識別されたブロックを使用して、ビデオデコーダ３０は２つの予測子を生成する。第１の予測子はＢａｓｅ０＋ｗ＊（ＣｕｒｒＲｅｆ−Ｂａｓｅ０Ｒｅｆ）であり、第２の予測子はＢａｓｅ１＋ｗ＊（ＣｕｒｒＲｅｆ−Ｂａｓｅ１Ｒｅｆ）である。

[00151]ビデオデコーダ３０は、Ｂａｓｅ０のための動きベクトルが利用可能である場合、ｍｖＢａｓｅが、Ｂａｓｅ０に関連する時間動きベクトルであると決定し得るか、またはＢａｓｅ１のための動きベクトルが利用可能である場合、ｍｖＢａｓｅが、Ｂａｓｅ１に関連する時間動きベクトルであると決定し得る。ビデオデコーダ３０がｍｖＢａｓｅとしてＢａｓｅ０の動きベクトルを使用するように構成される場合、ＡＲＰは、Ｂａｓｅ０のための動きベクトルが利用不可能であるとき、第１のブロックについて無効にされ得る。代替的に、ビデオデコーダ３０がｍｖＢａｓｅとしてＢａｓｅ０の動きベクトルを使用するように構成される場合、ｍｖＢａｓｅは、Ｂａｓｅ０の動きベクトルが利用不可能であるとき、ゼロ動きベクトルであるように設定され得る。同様に、ビデオデコーダ３０がｍｖＢａｓｅとしてＢａｓｅ１の動きベクトルを使用するように構成される場合、ＡＲＰは、Ｂａｓｅ１のための動きベクトルが利用不可能であるとき、第１のブロックについて無効にされ得る。代替的に、ビデオデコーダ３０がｍｖＢａｓｅとしてＢａｓｅ１の動きベクトルを使用するように構成される場合、ｍｖＢａｓｅは、Ｂａｓｅ１の動きベクトルが利用不可能であるとき、ゼロ動きベクトルであるように設定され得る。

[00152]別の例では、ビデオデコーダ３０は、Ｂａｓｅ０のための動きベクトルが利用不可能である場合、ｍｖＢａｓｅをＢａｓｅ１の時間動きベクトルであるように設定し得るか、またはＢａｓｅ１のための動きベクトルが利用不可能である場合、ｍｖＢａｓｅをＢａｓｅ０の時間動きベクトルであるように設定し得る。Ｂａｓｅ１のための動きベクトルが利用不可能である場合、およびＢａｓｅ０のための動きベクトルが利用不可能である場合、ビデオデコーダは、ｍｖＢａｓｅをゼロ動きベクトルであるように設定し得る。Ｂａｓｅ１のための動きベクトルが利用不可能である場合、およびＢａｓｅ０のための動きベクトルが利用不可能である場合、ビデオデコーダはＡＲＰを無効にし得る。別の例では、ビデオデコーダ３０は、参照ビュー中の参照ブロックに関連する時間動きベクトルが予測方向Ｘについて利用可能でないとき、予測方向ＸについてインタービューＡＲＰを無効にし得る。

[00153]本開示の別の技法によれば、１つのブロックが（サブＰＵレベルＡＲＰを含む）ＡＲＰを用いてコーディングされ、双方向予測されるとき、ビデオデコーダ３０は、一方の予測方向（予測方向Ｘ）のみについてクロマＡＲＰを適用し、他方の予測方向（予測方向１−Ｘ）についてＡＲＰを無効にすることが提案され、ここで、Ｘは０または１のいずれかであり得る。（サブＰＵレベルＡＲＰを含む）ルーマＡＲＰは不変に保たれ得る。一例では、Ｘは０に等しい。ビデオデコーダ３０は、この技法を、あるいは上記で説明した単一動きベクトル技法と一緒に、またはそれとは無関係に使用し得る。

[00154]本開示の別の技法によれば、１つのブロックがＡＲＰを用いてコーディングされるとき、さらに、クロマ成分についてのＡＲＰは、現在のブロックの幅および高さがある範囲中にあることを意味する、ブロックサイズがある範囲中にあるときのみ、適用されることが提案される。一例では、ブロックサイズが８×８に等しい場合、クロマ成分についてのＡＲＰは無効にされ得る。別の例では、ブロックサイズが３２×３２よりも小さい場合、クロマ成分についてのＡＲＰは無効にされ得る。別の例では、クロマについてのサブＰＵレベルＡＲＰは、Ｎ×Ｎに等しいサイズをもつ任意のサブＰＵについて無効にされ得るが、クロマについてのＡＲＰは、Ｎ×Ｎに等しいサイズをもつＰＵについて有効にされる。ここで、Ｎは８、１６、３２、または６４であり得る。別の例では、クロマについてのサブＰＵレベルＡＲＰは、Ｎ×Ｎに等しいサイズをもつ任意のサブＰＵについて無効にされ得るが、クロマについてのＡＲＰは、Ｍ×Ｍに等しいサイズをもつＰＵについて有効にされる。ここで、ＭはＮよりも小さいことがあり、それらの両方は、ＭがＮよりも小さい限り、８、１６、３２、または６４であり得る。

[00155]本開示で説明する様々な技法は、独立してまたは一緒にのいずれかで実装され得ることが企図される。たとえば、上記で説明した単一動きベクトル技法は、上記で説明したクロマＡＲＰ技法とともに実装され得る。同様に、上記で説明したブロックサイズベースクロマＡＲＰ技法は、上記で説明した単一動きベクトル技法とともに実装され得ることも企図される。また、本開示で説明する様々な技法は、ＰＵレベルＡＲＰ、サブＰＵレベルＡＲＰ、およびブロックレベルＡＲＰのいずれかに適用され得ることが企図される。

[00156]図１５は、本開示で説明するＡＲＰ技法を実装し得るビデオエンコーダの一例を示すブロック図である。たとえば、図１５は、３Ｄ−ＡＶＣ準拠ビデオエンコーダまたは３Ｄ−ＨＥＶＣ準拠ビデオエンコーダのいずれかを表し得るビデオエンコーダ２０を示す。ビデオエンコーダ２０は、ＰＵ、ＴＵ、およびＣＵなど、あるＨＥＶＣ用語を使用して説明されるが、ビデオエンコーダ２０に関して説明する技法はまた、Ｈ．２６４規格に従ってコーディングされたビデオを用いて実施され得ることを理解されたい。

[00157]ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実施し得る。たとえば、ビデオエンコーダ２０は、インター予測符号化またはイントラ予測符号化を実施し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内の時間冗長性または異なるビュー中のピクチャ間の冗長性を低減または除去するために、時間予測またはインタービュー予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。

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

[00159]ビデオデータメモリ４０は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオデータメモリ４０内に記憶されるビデオデータは、たとえば、ビデオソース１８から取得され得る。参照ピクチャメモリ６４は、（たとえば、イントラ予測コーディングモードまたはインター予測コーディングモードとも呼ばれる、イントラコーディングモードまたはインターコーディングモードで）ビデオエンコーダ２０によってビデオデータを符号化する際に使用する参照ビデオデータを記憶する復号されたピクチャバッファ（ＤＰＢの一例である。ビデオデータメモリ４０および参照ピクチャメモリ６４は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ４０および参照ピクチャメモリ６４は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ４０は、ビデオエンコーダ２０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。

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

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

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

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

[00164]動きおよびディスパリティ推定ユニット４４は、ビデオブロックの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされた（インター予測コーディングされた）スライス中のビデオブロックに関する動きベクトルを計算する。参照ピクチャは、その各々が、参照ピクチャメモリ６４内に記憶された１つまたは複数の参照ピクチャを識別する、第１の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０）または第２の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ１）から選択され得る。動きおよびディスパリティ推定ユニット４４は、計算された動きベクトルをエントロピー符号化ユニット５６と動きおよびディスパリティ補償ユニット４６とに送る。

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

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

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

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

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

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

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

[00172]このようにして、ビデオエンコーダ２０は、本開示で説明する１つまたは複数の例示的な技法を実装するように構成され得るビデオエンコーダの一例である。たとえば、ビデオデータメモリ４０はビデオデータを記憶する。ビデオデータは、ビデオエンコーダ２０が、３Ｄ−ＡＶＣ準拠ビデオコーディングプロセスまたは３Ｄ−ＨＥＶＣ準拠ビデオコーディングプロセスにおいてその各々を符号化すべきである、依存ビューのテクスチャビデオコンポーネントおよびテクスチャビューコンポーネントに対応する深度ビューコンポーネントを含み得る。

[00173]本開示で説明する技法では、ビデオエンコーダ２０は、３Ｄ−ＡＶＣ準拠ビデオコーディングプロセスまたは３Ｄ−ＨＥＶＣ準拠ビデオコーディングプロセスにおいて、ビデオデータの依存ビューのテクスチャビューコンポーネントを符号化するように構成された１つまたは複数のプロセッサを含み得る。上記で説明したように、３Ｄ−ＡＶＣにおける各ビューは、テクスチャビューコンポーネントと深度ビューコンポーネントとを含む。３Ｄ−ＡＶＣでは、１つのベースビューおよび１つまたは複数の拡張または依存ビューがあり、ここで、１つまたは複数の拡張または依存ビューのテクスチャビューコンポーネントはインタービュー予測され得る。

[00174]テクスチャビューコンポーネントを符号化するために、ビデオエンコーダ２０は、少なくとも１つの隣接ブロックが、依存ビュー以外のビュー中のインタービュー参照ピクチャを指すディスパリティ動きベクトルを用いてインタービュー予測されるかどうかを決定するために、テクスチャビューコンポーネント中の現在のブロックの１つまたは複数の隣接ブロックの動き情報を評価するように構成され得る。ビデオエンコーダ２０は、隣接ブロックのうちの１つに関するディスパリティ動きベクトルに基づいて、現在のブロックに関するディスパリティベクトルを導出し得る。テクスチャ優先コーディングの場合、ビデオエンコーダ２０は、テクスチャビューコンポーネントを符号化することに続いて、テクスチャビューコンポーネントに対応する、ビデオデータの深度ビューコンポーネントを符号化し得る。

[00175]いくつかの例では、ビデオエンコーダ２０の予測処理ユニット４２は、本開示で説明する例を実装するように構成されたプロセッサの一例であり得る。いくつかの例では、予測処理ユニット４２以外のユニット（たとえば、１つまたは複数のプロセッサ）が、上記で説明した例を実装し得る。いくつかの例では、予測処理ユニット４２は、ビデオエンコーダ２０の１つまたは複数の他のユニットとともに、上記で説明した例を実装し得る。いくつかの例では、（図１５に示されていない）ビデオエンコーダ２０のプロセッサは、単独で、またはビデオエンコーダ２０の他のプロセッサとともに、上記で説明した例を実装し得る。

[00176]図１６は、本開示で説明するＡＲＰ技法を実装し得るビデオデコーダの一例を示すブロック図である。図１６は、本開示で説明する技法を実装し得るビデオデコーダの一例を示すブロック図である。たとえば、図１６は、３Ｄ−ＡＶＣ準拠ビデオデコーダまたは３Ｄ−ＨＥＶＣ準拠ビデオデコーダのいずれかを表し得る、ビデオデコーダ３０を示す。ビデオデコーダ３０は、ＰＵ、ＴＵ、およびＣＵなど、あるＨＥＶＣ用語を使用して説明するが、ビデオデコーダ３０に関して説明する技法はまた、Ｈ．２６４規格に従ってコーディングされたビデオを用いて実施され得ることを理解されたい。

[00177]ビデオデコーダ３０は、インター予測復号またはイントラ予測復号を実施し得る。図１６はビデオデコーダ３０を示す。図１６の例では、ビデオデコーダ３０は、ビデオデータメモリ６９と、エントロピー復号ユニット７０と、予測処理ユニット７１と、逆量子化処理ユニット７６と、逆変換処理ユニット７８と、加算器８０と、参照ピクチャメモリ８２とを含む。予測処理ユニット７１は、動きおよびディスパリティ補償ユニット７２と、イントラ予測ユニット７４とを含む。ビデオデコーダ３０は、いくつかの例では、図１５のビデオエンコーダ２０に関して説明した符号化パスとは概して逆の復号パスを実施し得る。

[00178]ビデオデータメモリ６９は、ビデオデコーダ３０の構成要素によって復号されるべき、符号化されたビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ６９内に記憶されたビデオデータは、たとえば、ストレージデバイス３４から、カメラなどのローカルビデオソースから、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介して、あるいは物理データ記憶媒体にアクセスすることによって得られ得る。ビデオデータメモリ６９は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶する、コード化されたピクチャバッファ（ＣＰＢ）を形成し得る。

[00179]参照ピクチャメモリ８２は、（たとえば、イントラコーディングモードまたはインターコーディングモードで）ビデオデコーダ３０によってビデオデータを復号する際に使用する参照ビデオデータを記憶する復号されたピクチャバッファ（ＤＰＢ）の一例である。ビデオデータメモリ６９および参照ピクチャメモリ８２は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ６９および参照ピクチャメモリ８２は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ６９は、ビデオデコーダ３０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。

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

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

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

[00183]動きおよびディスパリティ補償ユニット７２は、本開示で説明するＡＲＰ技法を実施するように構成され得る。一例として、ＡＲＰを使用してコーディングされた双方向予測された現在のブロックについて、動きおよびディスパリティ補償ユニット７２は、現在のブロックのための第１のディスパリティ動きベクトルを決定し、第１のディスパリティ動きベクトルを使用して、第２のビュー中の現在のブロックの第１の対応するブロックの位置を特定し得る。動きおよびディスパリティ補償ユニット７２はまた、現在のブロックに関する第２のディスパリティ動きベクトルを決定し、第２のディスパリティ動きベクトルを使用して、第３のビュー中の現在のブロックの第２の対応するブロックの位置を特定し得る。第１の対応するブロックおよび第２の対応するブロックの動き情報から、動きおよびディスパリティ補償ユニット７２は単一の動きベクトルを決定し得る。動きおよびディスパリティ補償ユニット７２は、現在のブロックの参照ブロック、第１の対応するブロックの参照ブロック、および第２の対応するブロックの参照ブロックを決定するために、この単一の動きベクトルを使用し得る。動きおよびディスパリティ補償ユニット７２は、第１の対応するブロック、現在のブロックの参照ブロック、および第１の対応するブロックの参照ブロックに基づいて、第１の予測ブロックを生成し、第２の対応するブロック、現在のブロックの参照ブロック、および第２の対応するブロックの参照ブロックに基づいて、第２の予測ブロックを生成し得る。

[00184]動きおよびディスパリティ補償ユニット７２は、さらに構成され得、たとえば、動きおよびディスパリティ補償ユニット７２は、第１のビューの現在のブロックが高度残差予測（ＡＲＰ）モードを使用してコーディングされ、現在のブロックが双方向予測されると決定し得る。現在のブロックのルーマブロックについて、動きおよびディスパリティ補償ユニット７２は、ルーマブロックの第１の予測ブロックを決定するために、第１の予測方向に関するＡＲＰを実施し、ルーマブロックの第２の予測ブロックを決定するために、第２の予測方向に関するＡＲＰを実施し得る。現在のブロックのクロマブロックについて、動きおよびディスパリティ補償ユニット７２は、クロマブロックの第１の予測ブロックを決定するために、第１の予測方向または第２の予測方向のうちの１つのみに関するＡＲＰを実施し得る。

[00185]動きおよびディスパリティ補償ユニット７２は、さらに構成され得、たとえば、動きおよびディスパリティ補償ユニット７２は、第１のビューの現在のブロックがＡＲＰモードを使用してコーディングされると決定し得る。現在のブロックのルーマブロックについて、動きおよびディスパリティ補償ユニット７２は、ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施し得る。現在のブロックのクロマブロックについて、動きおよびディスパリティ補償ユニット７２は、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定し得る。一例として、動きおよびディスパリティ補償ユニット７２は、クロマブロックのサイズが８×８であることに応答して、ＡＲＰを無効にし得る。別の例として、動きおよびディスパリティ補償ユニット７２は、クロマブロックのサイズが３２×３２よりも小さいことに応答して、ＡＲＰを無効にし得る。別の例として、動きおよびディスパリティ補償ユニット７２は、クロマブロックのサイズがＮ×Ｎに等しいこと、および現在のブロックがサブＰＵを備えることに応答して、ＡＲＰを無効にし得、ここにおいて、Ｎは８、１６、３２、または６４のうちの１つに等しい。別の例として、動きおよびディスパリティ補償ユニット７２は、クロマブロッキングのサイズがＮ×Ｎであること、および現在のブロックがＰＵを備えることに応答して、ＡＲＰを実施し得る。別の例として、動きおよびディスパリティ補償ユニット７２は、クロマブロックのサイズがＮ×Ｎに等しいこと、および現在のブロックがサブＰＵを備えることに応答して、ＡＲＰを無効にし、クロマブロッキングのサイズがＭ×Ｍであること、および現在のブロックがＰＵを備えることに応答して、ＡＲＰを実施し得、ここにおいて、ＮおよびＭは８、１６、３２、および６４のうちの１つに等しく、ここにおいて、ＭはＮよりも小さい。

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

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

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

[00189]このようにして、ビデオデコーダ３０は、本開示で説明する１つまたは複数の例示的な技法を実装するように構成され得るビデオデコーダの一例である。たとえば、ビデオデータメモリ６９はビデオデータを記憶する。ビデオデータは、ビデオエンコーダ２０が、３Ｄ−ＡＶＣ準拠ビデオコーディングプロセスまたは３Ｄ−ＨＥＶＣ準拠ビデオコーディングプロセスにおいてその各々を符号化された、依存ビューのテクスチャビデオコンポーネントおよびテクスチャビューコンポーネントに対応する深度ビューコンポーネントをビデオデコーダ３０がそれから復号することができる情報を含み得る。

[00190]本開示で説明する技法では、ビデオデコーダ３０は、３Ｄ−ＡＶＣ準拠ビデオコーディングプロセスまたは３Ｄ−ＨＥＶＣ準拠ビデオコーディングプロセスにおいて、ビデオデータの依存ビューのテクスチャビューコンポーネントを復号するように構成された１つまたは複数のプロセッサを含み得る。テクスチャビューコンポーネントを復号するために、ビデオデコーダ３０は、少なくとも１つの隣接ブロックが、依存ビュー以外のビュー中のインタービュー参照ピクチャを参照するディスパリティ動きベクトルを用いてインタービュー予測されるかどうかを決定するために、テクスチャビューコンポーネント中の現在のブロックの１つまたは複数の隣接ブロックの動き情報を評価するように構成され得る。ビデオデコーダ３０は、隣接ブロックのうちの１つに関するディスパリティ動きベクトルに基づいて、現在のブロックに関するディスパリティベクトルを導出し得る。テクスチャ優先コーディングのために、ビデオエンコーダ３０は、テクスチャビューコンポーネントを復号することに続いて、テクスチャビューコンポーネントに対応する、ビデオデータの深度ビューコンポーネントを復号し得る。

[00191]いくつかの例では、ビデオデコーダ３０の予測処理ユニット７１は、本開示で説明する例を実装するように構成されたプロセッサの一例であり得る。いくつかの例では、予測処理ユニット７１以外のユニット（たとえば、１つまたは複数のプロセッサ）が、上記で説明した例を実装し得る。いくつかの例では、予測処理ユニット７１は、ビデオデコーダ３０の１つまたは複数の他のユニットとともに、上記で説明した例を実装し得る。さらにいくつかの他の例では、（図１６に示されていない）ビデオデコーダ３０のプロセッサは、単独で、またはビデオデコーダ３０の他のプロセッサとともに、上記で説明した例を実装し得る。

[00192]図１６は、本開示の技法による、ビデオブロックを予測する例示的な方法を示す。図１６の技法は、たとえば、ビデオデコーダ３０の動きおよびディスパリティ補償ユニット７２によって、あるいはビデオエンコーダ２０の動きおよびディスパリティ推定ユニット４４または動きおよびディスパリティ補償ユニット４６によって実施され得る。図１６の技法によれば、ビデオコーダは、第１のビューの現在のブロックがＡＲＰモードを使用してコーディングされ、現在のブロックが双方向予測されると決定し得る（２５０）。ビデオコーダは、現在のブロックに関する第１のディスパリティ動きベクトルおよび第２のディスパリティ動きベクトルを決定し得る（２５２）。ビデオコーダは、第１のディスパリティ動きベクトルを用いて、第２のビュー中の現在のブロックの第１の対応するブロックの位置を特定し得る（２５４）。ビデオコーダはまた、第２のディスパリティ動きベクトルを用いて、第３のビュー中の現在のブロックの第２の対応するブロックの位置を特定し得る（２５６）。ビデオコーダは、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定し得る（２５８）。動きベクトルを使用して、ビデオコーダは、第１のビュー中の現在のブロックの参照ブロック、第２のビュー中の第１の対応するブロックの参照ブロック、および第３のビュー中の第２の対応するブロックの参照ブロックを識別し得る（２６０）。図１７の例では、第２のビューおよび第３のビューは、同じビューまたは異なるビューのいずれかであり得るが、一般に第１のビューとは異なることになる。

[00193]ビデオコーダは、第１の対応するブロックと、現在のブロックの参照ブロックと、第１の対応するブロックの参照ブロックとに基づいて、第１の予測ブロックを生成し得る（２６２）。ビデオコーダは、第２の対応するブロックと、現在のブロックの参照ブロックと、第２の対応するブロックの参照ブロックとに基づいて、第２の予測ブロックを生成し得る（２６４）。ビデオコーダは、たとえば、現在のブロックの参照ブロックと、第２の対応するブロックの参照ブロックとの間の差に対応する残差予測子を決定することによって、第２の予測ブロックを生成し得る。ビデオコーダは、予測ブロックを生成するために、第２の対応するブロックに残差予測子を加算し得、第２の対応するブロックに残差予測子を加算する前に、残差予測子に重み付け係数を適用し得る。

[00194]ビデオコーダは、たとえば、現在のブロックの第１の対応するブロックに関する動きベクトルが利用不可能であることに応答して、動きベクトルのためにゼロ動きベクトルを使用することによって、第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定し得る。別の例では、ビデオコーダは、現在のブロックの第１の対応するブロックに関する動きベクトルが利用不可能であることに応答して、動きベクトルとして現在のブロックの第２の対応するブロックに関する動きベクトルを使用することによって、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定し得る。別の例では、ビデオコーダは、現在のブロックの第１の対応するブロックに関する動きベクトルが利用不可能であること、および現在のブロックの第２の対応するブロックに関する動きベクトルが利用不可能であることに応答して、動きベクトルのためにゼロ動きベクトルを使用することによって、現在のブロックの第１の対応するブロックおよび現在のブロックの第２の対応するブロックのうちの少なくとも１つの動き情報から動きベクトルを決定し得る。

[00195]いくつかのコーディングシナリオの下で、ビデオコーダはＡＲＰを無効にし得る。たとえば、第２の現在のブロックの第１の対応するブロックに関する動きベクトルが利用不可能であることに応答して、ビデオコーダはＡＲＰを無効にし得る。別の例では、第２の現在のブロックの第１の対応するブロックに関する動きベクトルが利用不可能であること、および第２の現在のブロックの第２の対応するブロックに関する動きベクトルが利用不可能であることに応答して、ビデオコーダは第２の現在のブロックについてＡＲＰを無効にし得る。

[00196]図１７は、本開示の技法による、ビデオブロックを予測する例示的な方法を示す。図１７の技法は、たとえば、ビデオデコーダ３０の動きおよびディスパリティ補償ユニット７２によって、あるいはビデオエンコーダ２０の動きおよびディスパリティ推定ユニット４４または動きおよびディスパリティ補償ユニット４６によって実施され得る。図１７の技法によれば、ビデオコーダは、第１のビューの現在のブロックがＡＲＰモードを使用してコーディングされ、現在のブロックが双方向予測されると決定し得る（２７０）。現在のブロックのルーマブロックについて、ビデオコーダは、ルーマブロックの第１の予測ブロックを決定するために、第１の予測方向に関するＡＲＰを実施し得る（２７２）。現在のブロックのルーマブロックについて、ビデオコーダは、ルーマブロックの第２の予測ブロックを決定するために、第２の予測方向に関するＡＲＰを実施する（２７４）。現在のブロックのクロマブロックについて、ビデオコーダは、クロマブロックの第１の予測ブロックを決定するために、第１の予測方向または第２の予測方向のうちの１つのみに関するＡＲＰを実施し得る（２７６）。

[00197]図１８は、本開示の技法による、ビデオブロックを予測する例示的な方法を示す。図１８の技法は、たとえば、ビデオデコーダ３０の動きおよびディスパリティ補償ユニット７２によって、あるいはビデオエンコーダ２０の動きおよびディスパリティ推定ユニット４４または動きおよびディスパリティ補償ユニット４６によって実施され得る。図１８の技法によれば、ビデオコーダは、第１のビューの現在のブロックがＡＲＰモードを使用してコーディングされると決定し得る（２８０）。現在のブロックのルーマブロックについて、ビデオコーダは、ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施し得る（２８２）。現在のブロックのクロマブロックについて、ビデオコーダは、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定し得る。

[00198]一例では、ビデオコーダは、クロマブロックのサイズが８×８であることに応答して、ＡＲＰを無効にすることによって、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定し得る。別の例では、ビデオコーダは、クロマブロックのサイズが３２×３２よりも小さいことに応答して、ＡＲＰを無効にすることによって、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定し得る。別の例では、ビデオコーダは、クロマブロックのサイズがＮ×Ｎに等しいこと、および現在のブロックがサブＰＵを備えることに応答して、ＡＲＰを無効にすることによって、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうか、ならびにクロマブロッキングのサイズがＮ×Ｎであること、および現在のブロックがＰＵを備えることに応答して、ＡＲＰを実施すべきかどうか、を決定し得る。Ｎは、たとえば、８、１６、３２、または６４のうちの１つに等しいことがある。別の例では、ビデオコーダは、クロマブロックのサイズがＮ×Ｎに等しいこと、および現在のブロックがサブＰＵを備えることに応答して、ＡＲＰを無効にすることによって、ならびにクロマブロッキングのサイズがＭ×Ｍであること、および現在のブロックがＰＵを備えることに応答して、ＡＲＰを実施することによって、クロマブロックのサイズに基づいて、クロマブロックについてＡＲＰを実施すべきかどうかを決定し得る。ＮおよびＭは、たとえば、８、１６、３２、および６４のうちの１つに等しいことがあり、ＭはＮよりも小さいことがある。

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

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

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

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

[00203]様々な例が説明された。これらおよび他の例は以下の特許請求の範囲内に入る。

Claims (26)

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. ビデオデータをコーディングするための装置であって、前記装置は、
    第１のビューの現在のブロックが、高度残差予測（ＡＲＰ）モードを使用してコーディングされると決定するための手段と、
    前記現在のブロックのルーマブロックについて、前記ルーマブロックの予測ブロックを決定するために、ＡＲＰを実施するための手段と、
    前記現在のブロックのクロマブロックについて、前記クロマブロックのサイズに基づいて、前記クロマブロックについてＡＲＰを実施すべきかどうかを決定するための手段と
    を備える、装置。

Images