JP6419808B2 - ビデオコーディングのための照明補償を処理すること - Google Patents

Description

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

[0002]本開示は、ビデオコーディングに関する。

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

[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去する（remove）ための空間（イントラピクチャ（intra-picture））予測および／または時間（インターピクチャ（inter-picture））予測を含む。ブロックベースビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス（an intra-coded (I) slice）中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプル（reference samples）に対する空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス（an inter-coded (P or B) slice）中のビデオブロックは、同じピクチャの中の隣接ブロック中の参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャ（reference pictures）は参照フレームと呼ばれることがある。

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

[0006]概して、本開示では、ビデオデータの現在ブロックのための予測モードをコーディングすること（たとえば、そのモードを示す信号をシグナリングおよび受信すること）に関係する技法について説明する。インター予測ブロック（an inter-predicted block）は、時間インター予測（temporal inter-prediction）、ビュー間予測（inter-view prediction）、高度残差予測（advanced residual prediction）、または照明補償（illumination compensation）を使用して予測され得る。しかしながら、照明補償および高度残差予測は一緒に使用されない。したがって、本開示では、現在ブロックのために高度残差予測が使用されることを効果的に示す、高度残差予測重み付け係数（an advanced residual prediction weighting factor）が０でない値を有するとき、現在ブロックのために照明補償が使用されるかどうかを示すシンタックス要素（たとえば、フラグ）がシグナリングされないことを提案する。

[0007]一例では、ビデオデータを復号する方法は、現在ブロックの高度残差予測（ＡＲＰ：advanced residual prediction）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素の復号をスキップすることと、現在ブロックを復号することとを含む。本方法は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素を復号することと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックを復号することとをさらに含み得る。

[0008]別の例では、ビデオデータを符号化する方法は、現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素の符号化をスキップすることと、現在ブロックを符号化することとを含む。本方法は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素を符号化することと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックを符号化することとをさらに含み得る。

[0009]別の例では、ビデオデータをコーディング（たとえば、符号化または復号）するためのデバイスは、ビデオデータを記憶するように構成されたメモリと、ビデオデータの現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、現在ブロックをコーディングすることとを行うように構成されたビデオコーダとを含む。本ビデオコーダは、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素をコーディングすることと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックをコーディングすることとを行うようにさらに構成され得る。

[0010]別の例では、ビデオデータをコーディングするためのデバイスは、現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定するための手段と、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素のコーディングをスキップするための手段と、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックをコーディングするための手段とを含む。本デバイスは、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素をコーディングするための手段と、ＡＲＰ重み付け係数の値が０に等しいとき、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックをコーディングするための手段とをさらに含み得る。

[0011]別の例では、コンピュータ可読記憶媒体（たとえば、非一時的コンピュータ可読記憶媒体）は、命令を記憶しており、その命令は、実行されたとき、現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、現在ブロックをコーディングすることとを、ビデオデータをコーディングするためのデバイスのプロセッサに行わせる。本コンピュータ可読記憶媒体は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素をコーディングすることと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックをコーディングすることとをプロセッサに行わせる命令をさらに含み得る。

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

[0013]照明補償をシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0014]照明補償をシグナリングするための技法を実装し得るビデオエンコーダの一例を示すブロック図。 [0015]照明補償をシグナリングするための技法を実装し得るビデオデコーダの一例を示すブロック図。 [0016]例示的なＭＶＣ予測パターンを示す概念図。 [0017]現在予測ユニット（ＰＵ：prediction unit）とそれの空間隣接ＰＵとの間の関係を示す概念図。 [0018]出力順序でのビデオフレームの予測構造を示す概念図。 [0019]高効率ビデオコーディング（ＨＥＶＣ）によるネットワークアブストラクションレイヤ（ＮＡＬ：network abstraction layer）ユニットヘッダの概念図。 [0020]照明補償パラメータの導出のために使用され得る隣接サンプルを示す概念図。 [0021]高度残差予測（ＡＲＰ）のための技法を示す概念図。 [0022]双方向予測の場合の、現在ブロックと参照ブロックと動き補償ブロックとの間の関係を示す概念図。 [0023]ＡＲＰのさらなる改善を示す概念図。 [0024]本開示の技法による、ブロックを符号化するための例示的な方法を示すフローチャート。 [0025]本開示の技法による、ブロックを復号するための例示的な方法を示すフローチャート。

詳細な説明

[0026]本開示の技法は、概して、たとえば、３Ｄ−ＨＥＶＣ（高効率ビデオコーディング）コーデックを用いた２つまたはそれ以上のビューのコーディングを含む、アドバンストコーデックに基づくマルチレイヤ（たとえば、マルチビュー）ビデオコーディングに関する。たとえば、本開示では、高度残差予測モードのシグナリングとともに照明補償モードのシグナリングに関する技法について説明する。

[0027]概して、ビデオコーディング（符号化または復号）は、ビットストリームを圧縮するために、ビデオデータの個々のピクチャ内の、およびそのデータの別個のピクチャ間の冗長性を利用することを伴う。たとえば、空間予測とも呼ばれるイントラ予測は、隣接する、前にコーディングされたブロックのピクセルを使用してピクチャのブロックを予測することを伴う。時間インター予測は、前にコーディングされたピクチャの参照ブロックを使用してピクチャのブロックを予測することを伴う。レイヤ間予測（inter-layer prediction）は、ビットストリームがビデオデータの複数のレイヤを含むと仮定して、異なるレイヤ中の前にコーディングされたピクチャのデータを使用してピクチャのブロックを予測することを伴う。マルチビュービデオデータの場合、別個のレイヤは、異なるビューに、たとえば、ビューアのための３次元効果を生成するために使用され得るシーンのカメラ・パースペクティブ（camera perspectives）のための異なる水平ロケーションに、対応し得る。

[0028]ビデオデータのブロックを予測するために様々なレイヤ間予測技法が使用され得る。たとえば、ビデオデータのブロックは、レイヤ間参照ピクチャ（an inter-layer reference picture）中の参照ブロックを識別する視差（disparity）動きベクトルを使用して予測され得る。照明補償は、ビュー間予測を伴う別の技法である。概して、照明補償は、現在ブロックに隣接するサンプル（ピクセル）と、参照ブロックに隣接するサンプルとに基づいて線形方程式のパラメータが決定されるその線形方程式を使用して視差動きベクトルによって識別される参照ブロックのピクセル値を操作することを伴う。

[0029]また別の例として、高度残差予測は、現在ブロックを予測するとき、視差ベクトル（または視差動きベクトル）と時間動きベクトルの両方を利用する技法である。概して、視差ベクトルは、参照ビュー中のブロックを識別し、時間動きベクトルは、現在ビュー中の参照ブロックを識別するために現在ブロックに適用されるとともに、参照ビュー中の第２の参照ブロックを識別するために参照ビュー中のブロックに適用される。代替的に、第２の参照ブロックは、第１の参照ブロックに視差ベクトルを適用することによって識別され得る。ビデオコーダは、第２の参照ブロックと参照ビュー中のブロックとの間の差に重み付け係数を適用し、ここで、重み付け係数は０．５または１の値であり得、次いで、現在ブロックのための予測されたブロックを生成するために、第１の参照ブロックに（ピクセルごとに）この重み付けされた値を加算し得る。重み付け係数が０に等しいとき、すべての重み付けされた値は０の値を割り当てられるので、高度残差予測は現在ブロックを予測するために使用されない。第１の参照ブロックと第２の参照ブロックの両方は、重み付け係数が０に等しくないと仮定すると、現在ブロックのための予測されたブロックを計算するために使用される。

[0030]以下でより詳細に説明するように、本開示では、概して、現在ブロックの予測に関係するデータをシグナリングするための技法について説明する。たとえば、現在ブロックが、たとえば、従来のビュー間予測、高度残差予測、または照明補償を使用して予測されるかどうかを示すフラグまたは他のシンタックス要素が、現在ブロックのためにコーディングされ得る。より詳細には、本開示は、高度残差予測が、現在ブロックを予測するために使用されない場合、照明補償のみが現在ブロックのために実行されることを認識している。いくつかの例では、現在ブロックのために照明補償が実行されるべきであるかどうかを示すフラグは、高度残差予測のための重み付け係数が０に等しい場合、現在ブロックのためにコーディング（たとえば、シグナリング）されるのみである。言い換えれば、いくつかの例では、現在ブロックのために照明補償が実行されるべきであるかどうかを示すフラグは、高度残差予測のための重み付け係数が０に等しくない場合、現在ブロックのためにコーディング（たとえば、シグナリング）されない。

[0031]上記で説明したように、０に等しい重み付け係数値は、高度残差予測が使用されないことを示し、したがって、高度残差予測のための重み付け係数値が０に等しい場合、現在ブロックを予測するために照明補償が使用され得る。重み付け係数値のための０でない値（たとえば、０．５または１．０の値）は、照明補償フラグがシグナリングされない（したがって、コーディングされるべきでない）ことを示し得る。したがって、高度残差予測の重み付け係数のための０でない値は、照明補償フラグがビットストリーム中に存在しないことを示し得る。

[0032]したがって、本開示の技法によれば、ビデオコーダ（たとえば、ビデオエンコーダまたはビデオデコーダ）は、現在ブロックのための高度残差予測の重み付け係数の値を決定するように構成され得る。重み付け係数が０の値を有する場合、ビデオエンコーダは、照明補償シンタックス要素の値が、ビデオエンコーダが照明補償を使用して現在ブロックを符号化することを決定したかどうかを示すように、現在ブロックのための照明補償シンタックス要素のための値を符号化することを決定し得る。すなわち、ビデオエンコーダが、（ＡＲＰ重み付け係数が０の値を有するように）符号化されているブロックを予測するためにＡＲＰを使用しないことを決定したとき、ビデオエンコーダは照明補償シンタックス要素を符号化し得る。同様に、ビデオデコーダは、現在ブロックのための重み付け係数が０の値を有するとき、照明補償シンタックス要素がシグナリングされると決定し得、したがって、照明補償シンタックス要素に基づいて現在ブロックを予測するために照明補償を使用すべきかどうかを決定し得る。一方、重み付け係数が０でない値を有する場合、ビデオエンコーダは、照明補償シンタックス要素がビットストリームの一部を形成しないように、照明補償シンタックス要素の符号化をスキップし得る。すなわち、ビデオエンコーダが、（ＡＲＰ重み付け係数が０でない値を有するように）ＡＲＰを使用して符号化されているブロックを予測することを選択したとき、ビデオエンコーダは照明補償シンタックス要素の符号化をスキップし得る。同様に、ビデオデコーダは、重み付け係数が０でない値を有するとき、照明補償シンタックス要素が現在ブロックのためのビットストリーム中に存在しないと決定し、したがって、現在ブロックを予測するために照明補償が使用されないと推論（すなわち、明示的シグナリングを受信することなしに決定）し得る。

[0033]ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６３と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌと、それのスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）拡張を含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４とを含む。Ｈ．２６４のＭＶＣ拡張は、「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１０年３月に記載されている。

[0034]概して、２Ｄビデオコーディング（ビデオ符号化またはビデオ復号など）技法はブロックベースコーディング技法を含む。ブロックベースコーディングは、（時間予測とも呼ばれる）インター予測によるのか、（空間予測とも呼ばれる）イントラ予測によるのかにかかわらず、ブロックを予測することを含む。イントラ予測では、ビデオコーダ（たとえば、ビデオエンコーダまたはビデオデコーダ）は、（「サンプル」とも呼ばれる）隣接する、前にコーディングされたピクセルから現在ブロックを予測する。インター予測では、ビデオコーダは、（１つまたは複数のそれぞれの動きベクトルを含み得る）動きパラメータの１つまたは複数のセットを使用して、前にコーディングされたピクチャから現在ブロックを予測する。

[0035]ＨＥＶＣでは、動きパラメータの予測のための２つのモードがあり、一方はマージモードであり、他方は高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）である。マージモードでは、動きパラメータ（予測方向、参照ピクチャ、および動きベクトル）の候補リストが構成され、ここで、候補は空間隣接ブロックおよび時間隣接ブロックから選択され得る。ビデオエンコーダは、候補リストへのインデックスを送信することによって、選択された動きパラメータをシグナリングし得る。デコーダ側において、インデックスが復号されると、インデックスが指す対応するブロックのすべての動きパラメータは、現在ブロックのために継承される。

[0036]ＡＭＶＰでは、各動き仮定（motion hypothesis）のための動きベクトル予測子（motion vector predictors）の候補リストは、コード化参照インデックス（coded reference index）に基づいて導出される。このリストは、同じ参照インデックスに、ならびに時間参照ピクチャ中のコロケートされたブロックの隣接ブロックの動きパラメータに基づいて導出される時間動きベクトル予測子に、関連付けられた隣接ブロックの動きベクトルを含む。選択された動きベクトルは、候補リストへのインデックスを送信することによってシグナリングされる。さらに、参照インデックス値および動きベクトル差分もシグナリングされる。動きデータ圧縮方法について、以下でより詳細に説明する。

[0037]動きベクトルはまた、時間動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）を使用して予測され得る。現在ブロックの動きベクトルのための時間動きベクトル予測子を取得するために、ビデオコーダは、最初に、現在ブロックを含む現在ピクチャにコロケートされたピクチャを識別し得る。現在ピクチャがＢスライスである（すなわち、スライスが双方向予測ブロック（bi-directionally predicted blocks）を含む）場合、コロケートされたピクチャがＲｅｆＰｉｃＬｉｓｔ０からのものであるのか、またはＲｅｆＰｉｃＬｉｓｔ１からのものであるのかを示すために、ｃｏｌｌｏｃａｔｅｄ＿ｆｒｏｍ＿ｌ０＿ｆｌａｇが、現在ブロックを含むスライスのスライスヘッダ中でシグナリングされ得る。さらに、Ｂスライスの場合、最終参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１）が構成された後、合成リスト（ＲｅｆＰｉｃＬｉｓｔＣ）が構成され得る。合成リスト（combined list）は、参照ピクチャリスト変更シンタックス（reference picture list modification syntax）が合成リストのために存在する場合、さらに変更され得る。

[0038]ビデオコーダが参照ピクチャリストを識別した後、ビデオコーダは、リスト中のピクチャ中のピクチャを識別するために、スライスヘッダ中でシグナリングされる、ｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｉｄｘを使用し得る。ビデオコーダは、次いで、コロケートされたピクチャを検査することによって、コロケートされたＰＵを識別し得る。コロケートされたＰＵの右下ＰＵの動き、またはコロケートされたＰＵの中心ＰＵの動きのいずれかが、ＴＭＶＰのために予測子として使用される。

[0039]ビデオコーダが、ＡＭＶＰまたはマージモードのための動き候補を生成するために上記プロセスによって識別された動きベクトルを使用するとき、ビデオコーダは、（ピクチャ順序カウント（ＰＯＣ：a picture order count）値によって反映される）時間ロケーションに基づいて動き候補の動きベクトル予測子をスケーリングし得る。

[0040]ＨＥＶＣでは、ピクチャパラメータセット（ＰＰＳ：a picture parameter set）は、フラグｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇを含む。０に等しいｔｅｍｐｏｒａｌ＿ｉｄをもつ特定のピクチャが、０に等しいｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇを有するＰＰＳを参照するとき、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）中のすべての参照ピクチャは、「時間動きベクトル予測のために使用されない」とマークされ、復号順序でその特定のピクチャの前のピクチャからの動きベクトルは、特定のピクチャまたは復号順序で特定のピクチャの後のピクチャの復号中に時間動きベクトル予測子として使用されないことになる。

[0041]本開示の技法は、概して、３Ｄ−ＨＥＶＣにおける照明補償モードをシグナリングすることに関するが、これらの技法は、他のビデオコーディング規格および／または他のビデオコーディング規格の拡張において実装され得る。３Ｄ−ＨＥＶＣにおける照明補償モードについて、図７〜１０に関して以下でより詳細に説明する。本開示より前の３Ｄ−ＨＥＶＣにおける照明補償モードは、以下の問題を有し得る。
− ＡＲＰの設計では、コーディングユニット（ＣＵ）がＡＲＰを用いてコーディングされる（すなわち、０に等しくない値をもつＡＲＰ重み付け係数をシグナリングする）とき、照明補償の存在（ｉｃ＿ｆｌａｇ）は、たとえば、現在ＣＵがビュー間参照ピクチャ（an inter-view reference picture）によって予測されないことがあるので、冗長であり得る。
− ＡＲＰはまた、２０１３年６月２１日に出願された米国仮出願第６１／８３８，２０８、および２０１３年７月１４日に出願された米国仮出願第６１／８４６，０３６の場合のように、ビュー間予測に適用され得る。この場合、ＡＲＰ重み付け係数とｉｃ＿ｆｌａｇとの間の関係は考慮されず、したがって、ｉｃ＿ｆｌａｇは、存在するとき、冗長であり得る。
− 照明補償の使用の制御はスライスレベルにおいて行われる。したがって、全シーケンスが照明補償を使用しないとき、複数のビットが浪費され得る。

[0042]さらに、本開示は、概して、ＡＲＰと照明補償が一緒に（すなわち、同じブロック上で一緒に）実行されないことを認識している。したがって、ＡＲＰが実行されるとき（たとえば、ＡＲＰ重み付け係数が０でない値を有するとき）、照明補償シンタックス要素はシグナリングされる必要がない。同様に、ＡＲＰが実行されないとき（たとえば、ＡＲＰ重み付け係数が０の値を有するとき）、照明補償シンタックス要素はシグナリングされ得る。

[0043]本開示の例による技法は、実装されると、照明補償（ＩＣ）が視差動き補償において適用されるとき、およびＡＲＰが現在ブロック（たとえば、現在ＣＵ）に適用可能であるかどうかを考えるとき、これらの問題のいずれかまたはすべてを克服し得る。本開示の技法の各態様は、別個に使用されるか、または何らかの他の態様と組み合わせて使用され得る。

[0044]図１は、照明補償をシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示すように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、タブレット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。ソースデバイス１２および宛先デバイス１４は、ビデオデータを記憶するためのメモリ、たとえば、ビデオエンコーダ２０およびビデオデコーダ３０内のそれぞれのメモリ、ならびに／あるいは（ソースデバイス１２のための）生の、コーディングされていないデータまたは（宛先デバイス１４のための）復号データを記憶するためのバッファおよびコード化ピクチャバッファ（ＣＰＢ：a coded picture buffer）など、ビデオエンコーダ２０およびビデオデコーダ３０の外部のメモリ、を含み得る。

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

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

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

[0048]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、照明補償をシグナリングするための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなど、外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。

[0049]図１の図示されたシステム１０は一例にすぎない。照明補償をシグナリングするための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスまたはビデオ復号デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。さらに、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオテレフォニーのための、ビデオデバイス１２とビデオデバイス１４との間の一方向または二方向ビデオ送信をサポートし得る。

[0050]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せ、を生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４はいわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。

[0051]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Ｂｌｕ−ｒａｙディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、ソースデバイス１２から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス１４に与え得る。同様に、ディスクスタンピング設備（a disc stamping facility）など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。

[0052]宛先デバイス１４の入力インターフェース２８はコンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰ、の特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、ユーザに復号ビデオデータを表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

[0053]ビデオエンコーダ２０およびビデオデコーダ３０は、高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。ビデオエンコーダ２０およびビデオデコーダ３０はまた、スケーラブルビデオコーディングおよび／またはマルチビュービデオコーディング拡張、たとえば、スケーラブルＨＥＶＣ（ＳＨＶＣ：scalable HEVC）、３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ：three-dimensional HEVC）、またはマルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ：multiview HEVC）など、ビデオコーディング規格への１つまたは複数の拡張に従って動作し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、またはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例としては、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれ、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。

[0054]ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、ジョイントビデオチーム（ＪＶＴ）として知られる共同パートナーシップの成果として、ＩＳＯ／ＩＥＣムービングピクチャエキスパートグループ（ＭＰＥＧ：Moving Picture Experts Group）とともにＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）によって策定された。いくつかの態様では、本開示で説明する技法は、Ｈ．２６４規格に概して準拠するデバイスに適用され得る。Ｈ．２６４規格は、ＩＴＵ−Ｔ Ｓｔｕｄｙ Ｇｒｏｕｐによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４「Advanced Video Coding for generic audiovisual services」に記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ばれることがある。ジョイントビデオチーム（ＪＶＴ）は、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣへの拡張に取り組み続けている。

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

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

[0057]概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding units）（「コーディングツリーユニット」とも呼ばれる）に分割され得ることを記述する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割される場合、ＣＵに対応するノードは４つのリーフノードを含み、その各々はサブＣＵのうちの１つに対応する。

[0058]４分木データ構造の各ノードは、対応するＣＵのためのシンタックスデータを与え得る。たとえば、４分木中のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示すスプリットフラグを含み得る。ＣＵのためのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、それはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵはリーフＣＵとも呼ばれる。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、その１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵはリーフＣＵとも呼ばれる。

[0059]ＣＵは、ＣＵがサイズ差異（a size distinction）を有しないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、（サブＣＵとも呼ばれる）４つの子ノードに分割され得、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックが分割され得る最大回数（a maximum number of times）を定義し得、また、コーディングノードの最小サイズを定義し得る。したがって、ビットストリームはまた、最小コーディングユニット（ＳＣＵ：smallest coding unit）を定義し得る。本開示では、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵ、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。

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

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

[0062]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのためのデータは、ＰＵに対応するＴＵのためのイントラ予測モードを記述するデータを含み得る残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）を記述し得る。

[0063]１つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上記で説明したように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグ（a split flag）は、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらなるサブＴＵにさらに分割され得る。ＴＵがさらに分割されないとき、それはリーフＴＵと呼ばれることがある。概して、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは、同じイントラ予測モードを共有する。すなわち、同じイントラ予測モードが、概して、リーフＣＵのすべてのＴＵのための予測値を計算するために適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵは、ＰＵよりも大きいことも小さいこともある。イントラコーディングの場合、ＰＵは、同じＣＵの対応するリーフＴＵとコロケートされ（collocated）得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。

[0064]その上、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。概して、本開示では、別段に明記されていない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。

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

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

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

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

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

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

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

[0072]本開示の技法によれば、ビデオエンコーダ２０またはビデオデコーダ３０などのビデオコーダは、改善された照明補償を実行するように構成され得る。一例では、ＡＲＰと照明補償の両方が１つのスライスのために有効化され、現在コーディングユニット（ＣＵ）がインターコーディングされる（inter-coded）とき、ｉｃ＿ｆｌａｇのシグナリングは、ＡＲＰのためにシグナリングされる重み付け係数の値に依存し得る。ｉｃ＿ｆｌａｇがシグナリングされないとき、ビデオコーダは、照明補償が現在ＣＵのために無効化されると常に仮定し得る。ｉｃ＿ｆｌａｇがスライスのどのＣＵのためにもシグナリングされないとき、ビデオコーダは、現在スライスのための照明補償を無効化し得、したがって、現在ピクチャがイントラランダムアクセスピクチャ（ＩＲＡＰ：an intra random access picture）であるかどうかなど、スライスまたはより高いレベルにおいてシンタックス要素を検査することによって、上記事実が決定される場合、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇはシグナリングされる必要がないことがある。

[0073]一例では、ビデオエンコーダ２０またはビデオデコーダ３０などのビデオコーダは、概して、現在ＣＵなどの現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定する。ビデオエンコーダ２０は、たとえば、ＡＲＰがＣＵの少なくとも一部分（たとえば、ＰＵ）を符号化するために使用されるべきであるかどうかを決定し得る。たとえば、ビデオエンコーダ２０は、ＣＵの一部分を符号化するとき、ＡＲＰがベースレートひずみメトリック（base rate-distortion metric）を生じるかどうかを決定するために、レートひずみ分析を実行し得、ベースレートひずみメトリックを生じる場合、ＡＲＰを使用してＣＵのその部分を符号化し得る。ＡＲＰを使用してＣＵのその部分を符号化することは、ＡＲＰ重み付け係数に０でない値、たとえば、０．５または１．０を割り当てることを含み得る。別の例として、ビデオデコーダ３０は、現在ＣＵのＡＲＰ重み付け係数のためのシグナリングされる値を決定し、ＡＲＰ重み付け係数の値に基づいて、照明補償シンタックス要素がビットストリーム中に存在するかどうか（すなわち、照明補償シンタックスが受信されるかどうか）を決定し得る。

[0074]ビデオコーダは、現在ＣＵのための照明補償シンタックス要素（たとえば、ｉｃ＿ｆｌａｇ）をコーディングし、ＡＲＰ重み付け係数の値が０に等しいとき、照明補償シンタックス要素の値（または、より一般的には、ＡＲＰが現在ＣＵを予測するために使用されるかどうか）に少なくとも部分的に基づいて現在ＣＵをコーディングし得る。本明細書で説明するように、照明補償およびＡＲＰは一般に一緒に実行されない。すなわち、ビデオコーダが、ＡＲＰを使用してブロックをコーディングする場合、ビデオコーダは、おそらく、ブロックをコーディングするために照明補償をも使用することはなく、同様に、ビデオコーダが、照明補償を使用してブロックをコーディングする場合、ビデオコーダは、おそらく、ブロックをコーディングするためにＡＲＰをも使用することはない。したがって、（たとえば、ＡＲＰ重み付け係数のための０の値によって証明されるように）ＡＲＰがブロックをコーディングするために使用されない場合、ビデオコーダは、照明補償が使用されるかどうかを示す、ｉｃ＿ｆｌａｇなどの照明補償シンタックス要素をコーディング（たとえば、シグナリングまたは復号）し得る。同様に、（たとえば、ＡＲＰ重み付け係数のための０でない値によって証明されるように）ＡＲＰが使用される場合、ビデオコーダは、照明補償シンタックス要素をコーディングすることを省略する（すなわち、コーディングすることを実行しないかまたは控える）ことがある。

[0075]たとえば、ＡＲＰが使用されないとき（たとえば、ＡＲＰ重み付け係数が０の値を有するとき）、ビデオエンコーダ２０は照明補償シンタックス要素のための値を符号化し得る。ビデオエンコーダ２０が（たとえば、上記で説明したようにレートひずみメトリックに基づいて）ブロックをコーディングするために照明補償を使用することを決定した場合、ビデオエンコーダ２０は、照明補償が使用されることを示す照明補償シンタックス要素のための値をシグナリングし得、その上、ビデオエンコーダ２０は、照明補償を使用してブロックを符号化し得る。同様に、ビデオデコーダ３０は、ＡＲＰ重み付け係数が０の値を有するとき、照明補償シンタックス要素がビットストリーム中に存在すると決定し得る。

[0076]一方、ＡＲＰ重み付け係数の値が０に等しくない場合、ビデオコーダは現在ブロックのための照明補償シンタックス要素のコーディングをスキップし、たとえば、ＡＲＰを使用して現在ブロックをコーディングし得る。ビデオエンコーダ２０は、たとえば、ビットストリーム中に照明補償シンタックス要素を挿入しないことによって照明補償シンタックス要素の符号化をスキップし得る。ビデオデコーダ３０は、同様に、ブロックのためのＡＲＰ重み付け係数が０でない値（たとえば、０．５または１．０の値）を有するとき、照明補償シンタックス要素がブロックのためのビットストリーム中に存在しないと決定し得る。

[0077]一例では、ビデオコーダは、現在ＣＵのＡＲＰ重み付け係数が０に等しくないとき、ｉｃ＿ｆｌａｇをシグナリング／復号しない。一例では、ｉｃ＿ｆｌａｇは、以下の条件のすべてが真の場合のみif and only ifシグナリングされる。
ａ．現在ＣＵのＡＲＰのためにシグナリングされる重み付け係数が０に等しい。および
ｂ．以下の少なくとも１つが真である（ｉｃＥｎａｂｌｅＦｌａｇが現在の３Ｄ−ＨＥＶＣにおいて１に等しいことに相当する）。
ｉ．（２Ｎ×２Ｎを用いてコーディングされる）現在ＰＵがマージモードを用いてコーディングされ、および（ｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇが０に等しいか、またはマージインデックスが０に等しくない）、または
ｉｉ．（２Ｎ×２Ｎを用いてコーディングされる）現在ＰＵがＡＭＶＰモードを用いてコーディングされ、ＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１に対応する参照インデックスのいずれかがビュー間参照ピクチャに対応する。
ｃ．代替的に、または追加として、現在ピクチャはＩＲＡＰピクチャである。

[0078]一例では、ビデオコーダは、ＡＲＰ重み付け係数と、現在ピクチャがＩＲＡＰピクチャであるかどうかとに基づいて、ただし、現在ＣＵが、マージを用いてコーディングされるのか、ＡＭＶＰを用いてコーディングされるのかに基づかないで、およびマージインデックスに基づかないで、ｉｃ＿ｆｌａｇをシグナリング／復号する。様々な例としては以下がある。
ａ．現在コーディングユニット（ＣＵ）のＡＲＰ重み付け係数が０に等しく、現在ピクチャがＩＲＡＰピクチャである場合のみ、ｉｃ＿ｆｌａｇは、エンコーダによってシグナリングされ、デコーダによって復号される。
ｂ．代替的に、現在コーディングユニット（ＣＵ）のＡＲＰ重み付け係数が０に等しく、現在ピクチャが１に等しいｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇを有する場合のみ、ｉｃ＿ｆｌａｇは、エンコーダによってシグナリングされ、デコーダによって復号される。
ｃ．代替的に、現在コーディングユニット（ＣＵ）のＡＲＰ重み付け係数が０に等しく、現在ＣＵがスキップモードを用いてコーディングされる場合のみ、照明補償シンタックス要素は、エンコーダによってシグナリングされ、デコーダによって復号される。
ｄ．代替的に、現在コーディングユニット（ＣＵ）のＡＲＰ重み付け係数が０に等しく、現在ＣＵが１つのパーティションのみ（すなわち、ＰＡＲＴ＿２Ｎ×２Ｎに等しいパーティションモード）を有する場合のみ、照明補償シンタックス要素は、エンコーダによってシグナリングされ、デコーダによって復号される。

[0079]一例では、ビデオコーダは、現在ＣＵのＡＲＰ重み付け係数が０に等しい場合のみ、ｉｃ＿ｆｌａｇをシグナリング／復号する。この場合、現在ピクチャがＩＲＡＰピクチャであり、ＡＲＰ重み付け係数がシグナリングされないとき、ＡＲＰ重み付け係数は現在ＣＵのために０であると推論され得る。

[0080]代替的に、または追加として、ＡＲＰ重み付け係数はＩＲＡＰピクチャのためにもシグナリング／復号され得る。したがって、この重み付け係数が０に等しくないとき、それは照明補償モードの無効化を示し、ｉｃ＿ｆｌａｇはシグナリングされる必要がない。しかしながら、この場合、ＡＲＰ重み付け係数が非０であっても、復号プロセスが適切な動きベクトル、視差ベクトルまたは視差動きベクトルを見つけないか、または適切な関連するピクチャを見つけない場合、高度残差予測は現在ＰＵのために無効化され得る。したがって、ＰＵは、ＡＲＰ重み付け係数が０に等しい場合と同様の方法で復号され得る。したがって、ここで、ＡＲＰ重み付け係数をシグナリングすることの主要な目的は、ｉｃ＿ｆｌａｇのシグナリングを無効化することであり得る。

[0081]各レイヤのための、またはすべてのレイヤのためのＩＣの使用を示すために、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、および／またはピクチャパラメータセット（ＰＰＳ）中にフラグが追加され得る。

[0082]本開示の技法について、表１〜４に関して以下でより詳細に説明する。現在の３Ｄ−ＨＥＶＣワーキングドラフトと比較した削除は、［ｒｅｍｏｖｅｄ：“”］を使用して識別されており、新たに追加された部分はイタリック体にされている。表１は、コーディングユニットのための変更シンタックステーブルの例を表す。

[0083]表２は、コーディングユニットのための変更シンタックステーブルの代替例を表す。

[0084]追加または代替として、一般的なスライスヘッダシンタックスは、以下の表３に示されているように変更され得、ここで、照明補償はＩＲＡＰピクチャのためにのみ適用され得る。

[0085]この例では、表３の以下のセマンティクスは、以下に示されているように変更され得る。

[0086]［ｒｅｍｏｖｅｄ：“１に等しいｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは、ｍｅｒｇｅ＿ｆｌａｇが１に等しく、コーディングユニットの第１の予測ユニットのｍｅｒｇｅ＿ｉｄｘが０に等しいとき、ｉｃ＿ｆｌａｇが現在スライスのコーディングユニット中に存在しないことを指定する。０に等しいｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは、ｍｅｒｇｅ＿ｆｌａｇが１に等しく、コーディングユニットの第１の予測ユニットのｍｅｒｇｅ＿ｉｄｘが０に等しいとき、ｉｃ＿ｆｌａｇが現在スライスのコーディングユニット中に存在し得ることを指定する。存在しないとき、ｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは０に等しいと推論される。［Ｅｄ．（ＧＴ）：第１の予測ユニットという用語を置き換える］”］。

[0087]さらに、または代替として、表３に示された変更に対して、コーディングユニットシンタックスおよびセマンティクスは、以下で表４に関して説明するように変更され得る。

[0088]表４のシンタックス要素のセマンティクスは、以下で説明するように変更され得、ここで、「（Ｈ−＃）」は３Ｄ−ＨＥＶＣのセクションを指す。
［ｒｅｍｏｖｅｄ：“可変ｉｃＥｎａｂｌｅＦｌａｇは０に等しく設定されて、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇが１に等しく、ＰａｒｔＭｏｄｅが２Ｎ×２Ｎに等しく、ＰｒｅｄＭｏｄｅ［ｘ０］［ｙ０］がＭＯＤＥ＿ＩＮＴＲＡに等しくないとき、以下が適用される。
− ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］が１に等しい場合、以下が適用される。

− 他の場合（ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］が０に等しい）、以下が適用される。
− Ｘが０および１によって置き換えられる場合、変数ｒｅｆＶｉｅｗＩｄｘＬＸは、ＲｅｆＰｉｃＬｉｓｔＬＸ［ｒｅｆ＿ｉｄｘ＿ｌＸ［ｘ０］［ｙ０］］のビュー順序インデックスに等しく設定される。
− フラグｉｃＥｎａｂｌｅＦｌａｇは、以下において指定されているように導出される。

[0089]ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれ、適用可能な場合、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組合せなど、様々な好適なエンコーダまたはデコーダ回路のいずれかとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれもが合成ビデオエンコーダ／デコーダ（ＣＯＤＥＣ：a combined video encoder/decoder）の一部として組み込まれ得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。

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

[0091]図２に示されているように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、パーティションユニット４８とを含む。ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。再構成されたビデオからブロッキネスアーティファクト（blockiness artifacts）を除去するために、ブロック境界をフィルタ処理するための（図２に示されていない）デブロッキングフィルタも含まれ得る。必要な場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタ処理する。（ループ中またはループ後の）追加のフィルタもデブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために図示していないが、必要な場合、（ループ内フィルタとして）加算器５０の出力をフィルタ処理し得る。

[0092]符号化プロセス中に、ビデオエンコーダ２０はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対して受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は、代替的に、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。

[0093]その上、パーティションユニット４８は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、パーティションユニット４８は、最初にフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、さらに、ＬＣＵのサブＣＵへの区分を示す４分木データ構造を生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと１つまたは複数のＴＵとを含み得る。

[0094]モード選択ユニット４０は、たとえば、（たとえば、レートひずみメトリックを使用して評価される）誤差結果に基づいて、コーディングモードのうちの１つ、イントラまたはインターを選択し、得られたイントラまたはインターコード化ブロックを、残差ブロックデータを生成するために加算器５０に与え、参照フレームとして使用するための符号化ブロックを再構成するために加算器６２に与え得る。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報など、シンタックス要素をエントロピー符号化ユニット５６に与える。

[0095]動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム（または他のコード化ユニット）内でコーディングされている現在ブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位（displacement）を示し得る。予測ブロックは、絶対差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置（fractional pixel positions）の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対して動き探索を実行し、分数ピクセル精度をもつ動きベクトルを出力し得る。

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

[0097]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴い得る。同じく、動き推定ユニット４２および動き補償ユニット４４は、いくつかの例では、機能的に統合され得る。現在ビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいてそれを指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明するように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のための、ルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。

[0098]動き補償ユニット４４は、様々な技法を使用して動き補償を実行するように構成され得る。たとえば、動き補償ユニット４４は、実質的に上記で説明したように、現在ブロックのための一般的な時間動き補償を実行し得る。さらに、動き補償ユニット４４は、高度残差予測（ＡＲＰ）を実行するように構成され得る。すなわち、動き補償ユニット４４は、現在ブロックを予測するために、時間動きベクトルを使用して取得された、現在ブロックのための第１の予測子と、視差ベクトルと時間動きベクトルの両方を使用して取得された、現在ブロックのための第２の予測子の両方を使用し得る。さらに、動き補償ユニット４４はまた、照明補償を実行するように構成され得る。以下でより詳細に説明するように、照明補償は、概して、予測されたブロックに隣接するサンプル／ピクセル、および／または現在ブロックに隣接するサンプル／ピクセルに基づいて、予測されたブロックのサンプル（すなわち、ピクセル）値に１つまたは複数の線形方程式を適用することを伴う。

[0099]イントラ予測ユニット４６は、上記で説明したように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。

[0100]たとえば、イントラ予測ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの間で最も良好なレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット４６は、どのイントラ予測モードがブロックのための最も良好なレートひずみ値を呈するかを決定するために、様々な符号化ブロックのためのひずみおよびレートから比を計算し得る。

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

[0102]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、概念的にＤＣＴと同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。

[0103]いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化プロセスは「スケーリング」プロセスと呼ばれることもあり、したがって、量子化変換係数は「スケーリングされた変換係数」と呼ばれることもある。量子化（またはスケーリング）の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、エントロピー符号化ユニット５６は、次いで、量子化変換係数を含む行列の走査を実行し得る。

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

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

[0106]モード選択ユニット４０は、ブロックのための符号化モードを最終的に選択するために、ブロックのための様々なモード間で符号化結果を比較し得る。たとえば、モード選択ユニット４０は、時間動き補償と、ビュー間動き補償と、高度残差予測と、照明補償とを含むモードのためのレートひずみメトリックを比較し得る。モード選択ユニット４０は、現在ブロックのための最も良好なレートひずみメトリックを生じるコーディングモードを選択し得る。

[0107]モード選択ユニット４０がブロックのためのコーディングモードとしてＡＲＰを選択したとき、モード選択ユニット４０は、さらに、ＡＲＰ中に適用されるべき重み付け係数を決定し得る。この場合も、モード選択ユニット４０は、様々な潜在的重み付け係数、たとえば、０．５と１．０、の間でレートひずみメトリックを比較し、最良のレートひずみメトリックを生じる重み付け係数を選択し得る。エントロピー符号化ユニット５６は、ブロックのためにモード選択ユニット４０によって選択された重み付け係数を表す重み付け係数シンタックス要素のための値を符号化し得る。モード選択ユニット４０がＡＲＰ以外のモードを選択したとき、エントロピー符号化ユニット５６は、ＡＲＰ重み付け係数が０の値を有することを示す重み付け係数シンタックス要素のための値を符号化し得る。

[0108]本開示の技法によれば、ＡＲＰ重み付け係数が０の値を有するとき、エントロピー符号化ユニット５６は、さらに、対応するブロックが照明補償を使用して符号化されるかどうかを示す照明補償シンタックス要素（たとえば、ｉｃ＿ｆｌａｇ）のための値を符号化し得る。たとえば、モード選択ユニット４０が、ＡＲＰを使用してブロックを符号化するのではなく、代わりに照明補償を使用してブロックを符号化することを決定した場合、エントロピー符号化ユニット５６は、ブロックが照明補償を使用して符号化されることを示す照明補償シンタックス要素のための値を符号化し得る。同様に、モード選択ユニット４０が、ＡＲＰを使用して、および照明補償を使用せずにブロックを符号化するのではなく、異なるモードを使用してブロックを符号化することを決定した場合、エントロピー符号化ユニット５６は、ブロックが照明補償を使用して符号化されないことを示す照明補償シンタックス要素のための値を符号化し得る。１つまたは複数の別個のシンタックス要素は、次いで、ブロックを符号化するために使用される実際のコーディングモードを示し得る。

[0109]さらに、ＡＲＰ重み付け係数が０でない値を有するとき、エントロピー符号化ユニット５６は照明補償シンタックス要素の符号化をスキップし得る。すなわち、ビデオエンコーダ２０は、符号化ビデオデータを含む得られたビットストリーム中に照明補償シンタックス要素のための値を挿入することを回避するように構成され得る。いくつかの例では、ビデオエンコーダ２０はまた、ブロックレベル照明補償有効化シンタックス要素（a block-level illumination compensation enabled syntax element）、たとえば、ｉｃＥｎａｂｌｅＦｌａｇを符号化し得る。ビデオエンコーダ２０は、ブロックレベル照明補償有効化シンタックス要素が、ブロックのために照明補償が有効化されることを示すときのみ、（照明補償がブロックのために実際に使用されるかどうかを示す）ブロックレベル照明補償シンタックス要素のための値をコーディングするようにさらに構成され得る。

[0110]追加または代替として、いくつかの例では、ビデオエンコーダ２０は、スライスレベル照明補償シンタックス要素（a slice-level illumination compensation syntax element）、たとえば、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを符号化し得る。ビデオエンコーダ２０は、スライスレベル照明補償シンタックス要素が、対応するブロックを含むスライスのために照明補償が有効化されることを示すときのみ、ブロックレベル照明補償シンタックス要素のための値をコーディングするようにさらに構成され得る。ビデオエンコーダ２０が、スライスのブロックのいずれかのために照明補償を使用することを決定することなしにスライス全体のブロックを符号化するとき、ビデオエンコーダ２０は、スライスのために照明補償が無効化されることを示すようにスライスレベル照明補償シンタックス要素の値を設定し得る。

[0111]ＡＲＰおよび照明補償はインター予測技法である。したがって、いくつかの例では、ビデオエンコーダ２０は、対応するブロックがインター予測されるとき、ＡＲＰ重み付け係数および／または照明補償シンタックス要素のための値を符号化するだけである。イントラ予測ブロックのために、ビデオエンコーダ２０は、ＡＲＰ重み付け係数および照明補償シンタックス要素の符号化をスキップし得る。

[0112]このようにして、図２のビデオエンコーダ２０は、ビデオデータの現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素のコーディング（すなわち、符号化）をスキップすることと、現在ブロックをコーディングすることとを行うように構成されたビデオエンコーダの一例を表す。図２のビデオエンコーダ２０の例は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素をコーディングすることと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックをコーディングすることとを行うようにさらに構成される。別段に規定されていない限り、ビデオエンコーダ２０に関して使用される「コーディングする（code）」および「コーディングすること」は、「符号化する（encode）」および「符号化すること」として理解されるべきものである。しかしながら、「コーディングする」および「コーディングすること」は、たとえば、図１、図３のビデオデコーダ３０に関して使用されるとき、「復号する（decode）」および「復号すること」を指すこともあることを理解されたい。

[0113]図３は、照明補償をシグナリングするための技法を実装し得るビデオデコーダ３０の一例を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照ピクチャメモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明した符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。

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

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

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

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

[0118]本開示の技法によれば、エントロピー復号ユニット７０は、現在ブロックのＡＲＰ重み付け係数のための値をエントロピー復号し得る。ＡＲＰ重み付け係数が０でない値を有する場合、エントロピー復号ユニット７０は、照明補償シンタックス要素（たとえば、ｉｃ＿ｆｌａｇ）がビットストリーム中に含まれず、したがって、ビットストリームの後続のビットが照明補償シンタックス要素とは異なるシンタックス要素を表すと決定し得る。一方、ＡＲＰ重み付け係数が０の値を有する場合、エントロピー復号ユニット７０は、照明補償シンタックス要素がビットストリーム中に存在すると決定し、さらに、照明補償シンタックス要素のための値を復号し得る。

[0119]ＡＲＰ重み付け係数が０でない値（たとえば、０．５または１．０）を有するとき、動き補償ユニット７２は、対応するブロックを復号するためにＡＲＰを使用し得る。たとえば、以下でより詳細に説明するように、動き補償ユニット７２は、時間動きベクトルを使用して第１の予測子を決定し、視差ベクトルと時間動きベクトルとを使用して第２の予測子を決定し、第２の予測子にＡＲＰ重み付け係数を適用し、第１の予測子と、ＡＲＰ重み付け係数がそれに適用された第２の予測子とから現在ブロックのための予測子を計算し得る。

[0120]ＡＲＰ重み付け係数が０の値を有するとき、エントロピー復号ユニット７０は、現在ブロックが照明補償を使用してコーディングされるかどうかを示す現在ブロックのための照明補償シンタックス要素のための値を復号し得る。照明補償シンタックス要素が、照明補償を使用して現在ブロックがコーディングされることを示す場合、動き補償ユニット７２は、照明補償を使用して現在ブロックを予測し得る。一方、照明補償シンタックス要素が、照明補償を使用して現在ブロックがコーディングされないことを示す場合、動き補償ユニット７２は、異なる予測モード、たとえば、時間予測またはビュー間予測を使用して現在ブロックを予測し得る。

[0121]いくつかの例では、ビデオデコーダ３０はまた、ブロックレベル照明補償有効化シンタックス要素、たとえば、ｉｃＥｎａｂｌｅＦｌａｇを復号し得る。ビデオデコーダ３０は、ブロックレベル照明補償有効化シンタックス要素が、ブロックのために照明補償が有効化されることを示すときのみ、（照明補償がブロックのために実際に使用されるかどうかを示す）ブロックレベル照明補償シンタックス要素のための値を復号するようにさらに構成され得る。

[0122]追加または代替として、いくつかの例では、ビデオデコーダ３０は、スライスレベル照明補償シンタックス要素、たとえば、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを復号し得る。ビデオデコーダ３０は、スライスレベル照明補償シンタックス要素が、対応するブロックを含むスライスのために照明補償が有効化されることを示すときのみ、ブロックレベル照明補償シンタックス要素のための値を復号するようにさらに構成され得る。ビデオデコーダ３０のスライスレベル照明補償シンタックス要素が、スライスのために照明補償が無効化されることを示すとき、ビデオデコーダ３０は、照明補償シンタックス要素がスライスのブロックのいずれかのためのビットストリーム中に存在しないと決定し得る。

[0123]ＡＲＰおよび照明補償はインター予測技法である。したがって、いくつかの例では、ビデオデコーダ３０は、対応するブロックがインター予測されるとき、ＡＲＰ重み付け係数および／または照明補償シンタックス要素のための値を復号するだけである。ビデオデコーダ３０は、ＡＲＰ重み付け係数および照明補償シンタックス要素がイントラ予測ブロックのために存在しないと決定し得る。

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

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

[0126]このようにして、図３のビデオデコーダ３０は、ビデオデータの現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素のコーディング（すなわち、復号）をスキップすることと、現在ブロックをコーディングすることとを行うように構成されたビデオデコーダの一例を表す。図３のビデオデコーダ３０の例は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素をコーディングすることと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックをコーディングすることとを行うようにさらに構成される。ビデオデコーダ３０に関する「コーディングする」および「コーディングすること」という単語は、別段に規定されていない限り、復号することという意味であると意図される。

[0127]図４は、例示的なＭＶＣ予測パターンを示す概念図である。マルチビュービデオコーディング（ＭＶＣ：Multi-view video coding）は、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣの拡張である。同様の技法が、ＨＥＶＣに適用され得る。図４の例では、（ビューＩＤ「Ｓ０」〜「Ｓ７」を有する）８つのビューが示され、１２個の時間ロケーション（「Ｔ０」〜「Ｔ１１」）がビューごとに示されている。すなわち、図４中の各行はビューに対応し、各列は時間ロケーションを示す。

[0128]図４に、マルチビュービデオコーディングのための（各ビュー内のピクチャ間予測（inter-picture prediction）とビュー間予測（inter-view prediction）の両方を含む）一般的なＭＶＣ予測構造が示され、ここで、予測は矢印によって示され、矢印の終点のオブジェクト（pointed-to object）は予測参照のために矢印の始点のオブジェクト（point-from object）を使用する。ＭＶＣでは、ビュー間の相関を除去するために、同じアクセスユニットの（すなわち、同じ時間インスタンスをもつ）異なるビュー中でキャプチャされたピクチャの間でビュー間予測が実行される。ビュー間予測を用いてコーディングされたピクチャは、他の非ベースビュー（non-base views）のビュー間予測用の参照ピクチャリスト中に追加され得る。

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

[0130]一般的なＭＶＣ復号順序構成は時間優先コーディング（time-first coding）と呼ばれる。アクセスユニットは、１つの出力時間インスタンスのためのすべてのビューのコード化ピクチャを含み得る。たとえば、時間Ｔ０のピクチャの各々は共通アクセスユニット中に含まれ得、時間Ｔ１のピクチャの各々は第２の共通アクセスユニット中に含まれ得、以下同様である。復号順序は、出力順序または表示順序と必ずしも同一とは限らない。

[0131]図４中のフレームは、対応するフレームがイントラコーディングされる（すなわち、Ｉフレームである）のか、一方向に（すなわち、Ｐフレームとして）インターコーディングされるのか、複数の方向に（すなわち、Ｂフレームとして）インターコーディングされるのかを指定する、文字を含む影付きブロックを使用して、図４中の各行と各列との交差部において示されている。ｂフレーム（すなわち、小文字の「ｂ」をもつフレーム）として指定されたフレームはまた、複数の方向にインターコーティングされ、概して、ビューまたは時間次元中のコーディング階層中でＢフレーム（すなわち、大文字の「Ｂ」をもつフレーム）よりも低いフレームを指し得る。概して、予測は矢印によって示され、ここで、矢印の終点のフレーム（pointed-to frame）は予測参照のために矢印の始点のオブジェクトを使用する。たとえば、時間ロケーションＴ０におけるビューＳ２のＰフレームは、時間ロケーションＴ０におけるビューＳ０のＩフレームから予測される。

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

[0133]ビュー間予測参照ピクチャは、インター予測参照ピクチャと同様の方法で、参照ピクチャリストの任意の位置に置かれ得る。いくつかの例では、ビュー間参照ピクチャを長期参照ピクチャとして標示することと、時間参照ピクチャを短期参照ピクチャとして標示することとによって、ビュー間参照ピクチャが時間参照ピクチャと区別される。マルチビュービデオコーディングのコンテキストでは、２種類の動きベクトルがある。１つは、時間参照ピクチャを指す通常動きベクトルである。時間動きベクトルのための対応する時間インター予測モードは、動き補償予測（ＭＣＰ：motion-compensated prediction）と呼ばれる。他のタイプの動きベクトルは、異なるビュー中のピクチャ（すなわち、ビュー間参照ピクチャ）を指す視差動きベクトル（ＤＭＶ：a disparity motion vector）である。ＤＭＶのための対応するインター予測モードは、視差補償予測（ＤＣＰ：disparity-compensated prediction）と呼ばれる。

[0134]図５は、現在予測ユニット（a current prediction unit）（ＰＵ）９０とそれの空間隣接ＰＵとの間の関係を示す概念図である。空間隣接ＰＵは、図５の例においてＡ０、Ａ１、Ｂ０、Ｂ１、およびＢ２と標示され、マージモードとＡＭＶＰモードの両方のための候補動きベクトルを決定するために使用され得る。いくつかのシンボルは以下のように定義されるものとする。
− ルーマロケーション（ｘＰ，ｙＰ）は、現在ピクチャの左上サンプルに対する現在予測ユニット（ＰＵ）９０の左上ルーマサンプルを指定するために使用される。
− 変数ｎＰＳＷおよびｎＰＳＨは、ルーマについてのＰＵの幅および高さを示す。
− 現在ピクチャの左上サンプルに対する現在予測ユニットＮの左上ルーマサンプルは（ｘＮ，ｙＮ）である。

[0135]これらの例示的な定義を仮定すれば、（ｘＮ，ｙＮ）（Ｎは、図５によれば、Ａ₀、Ａ₁、Ｂ₀、Ｂ₁、またはＢ₂によって置き換えられる）は、それぞれ、（ｘＰ−１，ｙＰ＋ｎＰＳＨ）、（ｘＰ−１，ｙＰ＋ｎＰＳＨ−１）、（ｘＰ＋ｎＰＳＷ，ｙＰ−１）、（ｘＰ＋ｎＰＳＷ−１，ｙＰ−１）または（ｘＰ−１，ｙＰ−１）と定義され得る。いくつかの例では、照明補償は、ＰＵのための動き情報がマージモードを使用して予測されるときに使用され得る。図５は、ＰＵのための動き情報のマージモードコーディング中に使用され得る動きベクトル予測子候補を示す。

[0136]図６は、出力順序でのビデオフレームの予測構造を示す概念図である。ＨＥＶＣにおけるネットワークアブストラクションレイヤ（ＮＡＬ：a network abstraction layer）ユニットタイプによって識別され得る４つのピクチャタイプがある。これらは、瞬時復号リフレッシュ（ＩＤＲ：instantaneous decoding refresh）ピクチャ、クリーンランダムアクセス（ＣＲＡ：clean random access）ピクチャ、時間レイヤアクセス（ＴＬＡ：temporal layer access）ピクチャ、およびＩＤＲピクチャ、ＣＲＡピクチャ、またはＴＬＡピクチャでないコード化ピクチャである。いくつかの例では、照明補償は、ブロックがＩＤＲピクチャまたはＣＲＡピクチャなどのＩＲＡＰピクチャ中に含まれるときに使用され得る。

[0137]ＩＤＲピクチャおよびコード化ピクチャは、Ｈ．２６４／ＡＶＣ仕様から継承されたピクチャタイプである。ＣＲＡピクチャタイプおよびＴＬＡピクチャタイプは、ＨＥＶＣにおいて新しく、Ｈ．２６４／ＡＶＣ仕様において利用可能でない。ＣＲＡピクチャは、ＩＤＲピクチャを挿入することよりも効率的である、ビデオシーケンスの中央の任意のランダムアクセスポイントから始まる復号を容易にするピクチャタイプである。ＨＥＶＣでは、これらのＣＲＡピクチャから開始するビットストリームも適合ビットストリーム（a conforming bitstream）である。ＴＬＡピクチャは、有効な時間レイヤ切替えポイントを示すために使用され得るピクチャタイプである。

[0138]ブロードキャスティングおよびストリーミングなどの、ビデオ適用例では、ユーザが、最小遅延で、異なるチャネルの間で切り替え、ビデオの特定の部分にジャンプするための重要な特徴が必要とされる。この特徴は、ビデオビットストリーム中で一定の間隔でランダムアクセスピクチャを有することによって可能にされ得る。Ｈ．２６４／ＡＶＣとＨＥＶＣの両方において指定されるＩＤＲピクチャは、ランダムアクセスのために使用され得る。しかしながら、ＩＤＲピクチャが、コード化ビデオシーケンスを開始し、復号ピクチャバッファ（ＤＰＢ）を常にクリーンにするので、復号順序でＩＤＲに後続するピクチャは、そのＩＤＲピクチャより前に復号されたピクチャを参照として使用することができない。したがって、ランダムアクセスのためにＩＤＲピクチャに依拠するビットストリームは、著しくより低いコーディング効率（たとえば、６％）を有することがある。コーディング効率を改善するために、ＨＥＶＣにおけるＣＲＡピクチャは、復号順序でＣＲＡピクチャに後続するが、出力順序でＣＲＡピクチャに先行するピクチャが、そのＣＲＡピクチャの前に復号されたピクチャを参照として使用することを可能にする。

[0139]ＣＲＡピクチャの周りの一般的な予測構造が図６に示されており、（２４のＰＯＣ値をもつ）ＣＲＡピクチャは、復号順序でＣＲＡピクチャに後続するが、出力順序でＣＲＡピクチャに先行する、他のピクチャ（ＰＯＣ値１７〜２３）を含んでいるピクチャグループ（ＧＯＰ）に属する。これらのピクチャは、ＣＲＡピクチャのリーディングピクチャと呼ばれ、現在のＣＲＡピクチャの前のＩＤＲピクチャまたはＣＲＡピクチャから復号が開始する場合に正しく復号され得る。しかしながら、リーディングピクチャは、このＣＲＡピクチャからのランダムアクセスが行われたときに正しく復号されないことがあり、したがって、これらのリーディングピクチャは一般にランダムアクセス復号中に廃棄される。

[0140]復号がどこで開始するかに応じて利用可能でないことがある参照ピクチャからの誤り伝搬を防ぐために、復号順序と出力順序の両方でＣＲＡピクチャに後続する、図６に示されている次のＧＯＰ中のすべてのピクチャは、（リーディングピクチャを含む）復号順序または出力順序のいずれかでＣＲＡピクチャに先行するいかなるピクチャをも参照として使用しないものとする。

[0141]同様のランダムアクセス機能がリカバリポイントＳＥＩメッセージとともにＨ．２６４／ＡＶＣにおいてサポートされる。Ｈ．２６４／ＡＶＣデコーダ実装形態が、その機能をサポートすることもしないこともある。ＨＥＶＣでは、ＣＲＡピクチャから開始するビットストリームは適合ビットストリームと見なされる。ビットストリームがＣＲＡピクチャから開始するとき、ＣＲＡピクチャのリーディングピクチャは、利用不可能な参照ピクチャを参照し得、したがって正しく復号されないことがある。しかしながら、ＨＥＶＣは、開始ＣＲＡピクチャのリーディングピクチャが出力されないことを規定しており、したがって、「クリーンランダムアクセス」という名称がある。ビットストリームコンフォーマンス要件の確立のために、ＨＥＶＣは、非出力（non-output）リーディングピクチャの復号のために利用不可能な参照ピクチャを生成するための復号プロセスを規定している。しかしながら、適合デコーダ実装形態は、復号プロセスがビットストリームの開始から実行されるときと比較して、それが同等の出力を生成することができる限り、その復号プロセスに従う必要はない。ＨＥＶＣでは、適合ビットストリームは、ＩＤＲピクチャをまったく含んでいないことがあり、したがって、コード化ビデオシーケンスのサブセットまたは不完全なコード化ビデオシーケンスを含んでいることがある。

[0142]ＩＤＲピクチャおよびＣＲＡピクチャのほかに、他のタイプのランダムアクセスポイントピクチャ、たとえば、切断リンクアクセス（ＢＬＡ：broken link access）がある。ランダムアクセスポイントピクチャの主要なタイプの各々について、ランダムアクセスポイントピクチャがシステムによってどのように潜在的に扱われ得るかに応じて、サブタイプがあり得る。ランダムアクセスポイントピクチャの各サブタイプは、異なるネットワークアブストラクションレイヤ（ＮＡＬ）ユニットタイプを有する。

[0143]ＨＥＶＣにおいて、ＩＲＡＰ（イントラランダムアクセスポイント（intra random access point)）ピクチャ、すなわち、各ＶＣＬＮＡＬユニットが、両端値を含むＢＬＡ＿Ｗ＿ＬＰ〜ＲＳＶ＿ＩＲＡＰ＿ＶＣＬ２３の範囲内のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅをそれのために有する、コード化ピクチャも定義されている。ＩＲＡＰピクチャは、Ｉスライスのみを含んでおり、ＢＬＡピクチャ、ＣＲＡピクチャ、またはＩＤＲピクチャであり得る。復号順序でビットストリーム中の第１番目のピクチャ（the first picture）はＩＲＡＰピクチャでなければならない。必要なパラメータセットが、それらがアクティブ化される必要があるときに利用可能であるという条件で、ＩＲＡＰピクチャおよび復号順序で後続のすべての非ＲＡＳＬピクチャは、復号順序でＩＲＡＰピクチャに先行する任意のピクチャの復号プロセスを実行することなしに正しく復号され得る。ＩＲＡＰピクチャでないＩスライスのみを含んでいるピクチャがビットストリーム中にあり得る。

[0144]図７は、ＨＥＶＣによるＮＡＬユニットヘッダ１００の概念図である。この設計が、以下で手短に説明するように、ＨＥＶＣスケーラブルおよび３Ｄビデオコーディング（３ＤＶ）拡張、ならびに他の将来の拡張をサポートするのに十分であるという予期で、ＨＥＶＣでは、２バイトのＮＡＬユニットヘッダが導入された。

[0145]図７に示されているように、ＨＥＶＣ ＮＡＬユニットヘッダの第１番目のバイト（the first byte）は、Ｈ．２６４／ＡＶＣ ＮＡＬユニットヘッダと同様である。特に、ＮＡＬユニットヘッダ１００は、Ｆ−ビット１０２と、ＮＡＬユニットタイプフィールド１０４と、予約済みビット（reserved bits）１０６と、時間識別子プラスワン（ＴＩＤＰ：temporal identifier plus one）フィールド１０８とを含む。

[0146]ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ（Ｆ）ビット１０２は、ＭＰＥＧ−２システムレガシー環境においてスタートコードエミュレーション（start code emulations）を防ぐために、０の値を有しなければならない。

[0147]Ｈ．２６４／ＡＶＣでは、ｎａｌ＿ｒｅｆ＿ｉｄｃ（ＮＲＩ）は２ビット固定コードワードであった。２ビットのための主要なモチベーションは、データ区分をサポートするための異なるトランスポート優先度シグナリング（transport priority signaling）のサポートであった。データ区分の除去は、ＮＲＩがＨＥＶＣに対して１つの１ビットだけ低減されることを可能にした。さらに、いくつかの参照ピクチャがＮＡＬユニットのために有効化されるかどうかを示すために、ＮＡＬユニットタイプが使用され得る。したがって、ＮＲＩは、ＨＥＶＣにおけるＮＡＬユニットヘッダから完全に除去され、このことは、（図７中でＮＡＬタイプフィールド１０４として表される）ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅのサイズが５ビットから６ビットに増加することを可能にし、Ｈ．２６４／ＡＶＣと比較して２倍の数のＮＡＬユニットタイプを与える。

[0148]ＨＥＶＣ ＮＡＬユニットヘッダの第２番目の部分は、２つのシンタックス要素、すなわち、（６ビットを含む、図７中で予約済みビット１０６によって表される）ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓと、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１（３ビットを含む、図７中のＴＩＤＰフィールド１０８）とを含む。（両端値を含む０から６にわたる時間識別子を用いて）時間スケーラビリティをサポートするために、ＴＩＤＰフィールド１０８が使用され得る。ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットは、より大きいＴｅｍｐｏｒａｌＩｄ値を有する任意のＮＡＬユニットにアクセスすることなしに正常に復号され得る。

[0149]現在ピクチャは、復号されているとき、現在ピクチャ、または（将来の）現在ピクチャに後続するピクチャのいずれかによって参照のために使用され得るすべてのピクチャを含む参照ピクチャセットを有する。ビデオコーディングデバイスは、現在ピクチャのための参照として使用され得るピクチャと、将来のピクチャのための参照ピクチャとしてのみ使用され得るピクチャとを区別することができる。参照ピクチャリストは、現在ピクチャのために使用され得る参照ピクチャセット（すなわち「現在のためのＲＰＳ」）中のピクチャに基づいて、したがって、将来のピクチャのための参照としてのみ使用され得るピクチャに基づかずに構成される。現在ＲＰＳ中のピクチャは、２つの参照ピクチャリスト、すなわち、ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１のいずれか中にあることもないこともある。

[0150]現在、ＶＣＥＧおよびＭＰＥＧのジョイントコラボレーションチームオン３Ｄビデオコーディング（ＪＣＴ−３Ｃ）は、ＨＥＶＣに基づく３ＤＶ規格を開発中であり、それのために、規格化作業の一部は、ＨＥＶＣに基づくマルチビュービデオコーデック（ＭＶ−ＨＥＶＣ）と、ＨＥＶＣに基づく３Ｄビデオコーディング（３Ｄ−ＨＥＶＣ）のための別の部分との規格化を含む。３Ｄ−ＨＥＶＣでは、コーディングユニット／予測ユニットレベルのコーディングツールを含む新たなコーディングツールが、テクスチャビューと深度ビューの両方に関して含められ、サポートされ得る。３Ｄ−ＨＥＶＣのための３Ｄ−ＨＴＭソフトウェアのバージョン７．０は、以下のリンク、すなわち、https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM-7.0/からダウンロードされ得る。このソフトウェアは、http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/4_Incheon/wg11/JCT3V-D1005-v1.zipで入手可能な、Ｇｅｒｈａｒｄ Ｔｅｃｈ、Ｋｒｚｙｓｚｔｏｆ Ｗｅｇｎｅｒ、Ｙｉｎｇ Ｃｈｅｎ、Ｓｅｈｏｏｎ Ｙｅａの、「3D-HEVC Test Model 4」、ＪＣＴ３Ｖ−Ｄ１００５、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ２９／ＷＧ１１のジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、第３回会議、仁川、韓国、２０１３年４月に、３Ｄ−ＨＥＶＣのワーキングドラフトとともに記載されている。

[0151]図８は、照明補償パラメータの導出のために使用され得る隣接サンプルを示す概念図である。特に、図８は、現在ＰＵ１２２を含む現在コーディングユニット（ＣＵ）１２０と、参照ＰＵ１２８を含む参照ＣＵ１２６とを示す。図８はまた、現在ＣＵ１２０に隣接するサンプル（ピクセル）１２４、ならびに参照ＣＵ１２６に隣接するサンプル１３０を示す。

[0152]マルチビュービデオコーディングにおける照明補償（ＩＣ）は、各カメラが光源に対して異なる露出を有し得るので、異なるビュー間の照明不一致（illumination discrepancy）を補償するために使用され得る。一般に、重み係数および／またはオフセットは、異なるビュー中のコード化ブロックと予測ブロックとの間の差を補償するために使用される。パラメータはデコーダに明示的に送信されることもされないこともある。

[0153]照明補償は、http://phenix.it-sudparis.eu/jct2/doc_end_user/current_document.php?id=234で入手可能な、Ｌｉｕらの、「3D-CE2.h : Results of Illumination Compensation for Inter-View Prediction」、ＩＴＵ−Ｔ ＳＧ１６、ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ２９／ＷＧ１１のジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、ＪＣＴ３Ｖ−Ｂ００４５、上海、中国、２０１２年１０月１３〜１９日に記載されている。ＪＣＴ３Ｖ−Ｂ００４５では、照明補償はコーディングユニットレベルにおいてシグナリングされ、パラメータは、現在ＣＵ１２０に隣接するサンプル１２４と参照ＣＵ１２６に隣接するサンプル１３０とから導出される。後に、モードのシグナリングは、http://phenix.it-sudparis.eu/jct2/doc_end_user/current_document.php?id=744で入手可能な、Ｉｋａｉの、「3D-CE5.h related: Removal of parsing dependency in illumination compensation」、ＩＴＵ−Ｔ ＳＧ１６、ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ２９／ＷＧ１１のジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、ＪＣＴ３Ｖ−Ｄ００６０、仁川、韓国、２０１３年４月２０〜２６日に記載されているように変更された。

[0154]したがって、照明補償は、ビュー間参照ピクチャから予測されるブロックについてコーディング効率を改善するために導入された。このモードは、ビュー間参照ピクチャを使用して予測されるブロックのみに適用され得る。

[0155]隣接サンプル１２４は、ＣＵ１２０に対して上に隣接する行および左に隣接する列におけるサンプル（ピクセル）を含む。隣接サンプル１２４は、参照ＣＵ１２６に隣接する対応するサンプル１３０とともに、最小２乗解（a least squares solution）によってスケーリングファクタａおよびオフセットｂを導出し得る、線形モデルのための入力パラメータとして使用され得る。参照ビュー中の対応する隣接サンプル１３０は、図８に示されているように、現在ＰＵの視差動きベクトルによって識別され得る。特に、図８は、ＰＵ１２２を含む非ベースビュー中の現在ピクチャ１３２と、（図８のベースビューピクチャ１３４内で「ＰＵｒｅｆ」と標示された）参照ＰＵ１２８を含むベースビューピクチャ１３４とを示す。

[0156]ビュー間参照からの動き補償の後、ビデオコーダ（たとえば、ビデオエンコーダ２０またはビデオデコーダ３０）は、現在ＰＵ１２２のための予測信号を更新するために、参照ブロック１２８の各値に線形モデルを適用し得る。参照ブロックの各値は、図８に示されているように、さらにａによってスケーリングされ、さらにｂに加算され得る。すなわち、参照ＰＵ１２８の各サンプル値（ピクセル値）は、式「ａ＊（参照ＰＵ１２８のサンプル値）＋ｂ」に従って変更され得る。照明補償におけるＡＭＶＰモードおよびマージモードは、余剰ビットおよび不要な計算を低減するために、スライスレベルで適応的に有効化または無効化され得る。

[0157]照明補償（ＩＣ）の有効化は、フラグ、たとえば、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇによってスライスヘッダ中でシグナリングされ得る。他のフラグと同様に、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇが０に等しい場合、ＩＣモードはスライスのすべてのＣＵのために無効化され、他の場合、ＣＵは、ＣＵレベルでシグナリングされるフラグ（ｉｃ＿ｆｌａｇ）に応じてこのモードを使用することもしないこともある。

[0158]上記のＪＣＴ３Ｖ−Ｂ００４５において提案された１つの設計では、ｉｃ＿ｆｌａｇは、ＣＵが、ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１からのビュー間参照ピクチャから予測される少なくとも１つのＰＵを有するときのみシグナリングされる。しかしながら、上記条件は、ＣＵ中のＰＵのすべての参照インデックスの導出を必要とする。これは、すべてのＰＵシンタックス要素のパージング（parsing）と、マージモードを用いてコーディングされた各ＰＵのためのマージ候補リスト構成の完了とを必要とする。概して、特に復号プロセスに（たとえば、マージ候補リスト構成に）基づく、パージングの遅延は、ビデオコーデックにおいて望ましくない。

[0159]したがって、ＩＣモードシグナリングは、上記のＪＣＴ３Ｖ−Ｄ００６０において提案されているように変更された。ＪＣＴ３Ｖ−Ｄ００６０の変更は、２つの部分、すなわち２Ｎ×２Ｎ以外のパーティションサイズと、スライスヘッダ中の追加のフラグｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇとを用いてコーディングされるＣＵのためのＩＣモードの無効化と、ＩＣモードを示すフラグがマージモードに関する特殊な場合においてシグナリングされるか否かを制御することと、を含む。ＪＣＴ３Ｖ−Ｄ００６０によれば、ｉｃ＿ｆｌａｇは、（現在インター予測ＰＵがマージまたはＡＭＶＰを用いてコーディングされることを示す）ｍｅｒｇｅ＿ｆｌａｇの後に常にシグナリングされる。

[0160]同様に、ＪＣＴ３Ｖ−Ｄ００６０によれば、（２Ｎ×２Ｎを用いてコーディングされる）現在ＰＵがマージモードを用いてコーディングされるとき、ｉｃ＿ｆｌａｇは、ｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇが０に等しいか、またはマージインデックスが０に等しくないときのみ、シグナリングされる。さらに、ＪＣＴ３Ｖ−Ｄ００６０によれば、（２Ｎ×２Ｎを用いてコーディングされる）現在ＰＵがＡＭＶＰモードを用いてコーディングされるとき、ＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１に対応する参照インデックスが知られる。ＪＣＴ３Ｖ−Ｄ００６０によれば、それらのいずれかがビュー間参照ピクチャに対応するときのみ、ｉｃ＿ｆｌａｇはシグナリングされる。

[0161]２０１３年７月３日に出願された米国仮出願第６１／８４２，８３４号に記載されている技法によると、現在ピクチャがランダムアクセスピクチャであるか否かを確認することによって、ｉｃ＿ｆｌａｇは簡単に置き換えられ得ることに留意されたい。

[0162]図９は、高度残差予測（ＡＲＰ）のための技法を示す概念図である。高度残差予測（ＡＲＰ）は、Ｐａｒｔ＿２Ｎ×２Ｎに等しいパーティションモードをもつＣＵに適用され得、http://phenix.it-sudparis.eu/jct3v/doc_end_user/current_document.php?id=862tで入手可能な、Ｚｈａｎｇらの、「CE4: Advanced residual prediction for multiview coding」、ＪＣＴ３Ｖ−Ｄ０１７７、２０１３年４月２０〜２６日において提案されたように、第４回ＪＣＴ３Ｖ会議において採用された。

[0163]図９は、マルチビュービデオコーディングにおけるＡＲＰの予測構造を示す。図９に示されているように、現在ブロックの予測において以下のブロックが呼び出される。
１．現在ピクチャ１５０の現在ブロック１５２
２．視差ベクトル（ＤＶ）１６８によって導出される参照／ベースビューピクチャ１５８中の参照ブロック１６０
３．現在ブロック１５２の（ＴＭＶとして示された）時間動きベクトル１６６によって導出される現在ブロックと同じビュー中のピクチャ１５４のブロック１５６。
４．参照ブロック１６０に現在ブロック１５２の時間動きベクトル１６６を適用することによって導出される参照ブロック１６０と同じビュー中のピクチャ１６２のブロック１６４。ブロック１６４は、現在ブロック１５２に対する時間動きベクトル１６６と視差ベクトル１６８とを組み合わせることから得られるベクトル１７０によって識別される。

[0164]残差予測子はＢａｓｅＴＲｅｆ−Ｂａｓｅ（すなわち、ブロック１６４ マイナス ブロック１６０）として示され、ここにおいて、減算演算が、示されたピクセルアレイの各ピクセルに適用される。重み付け係数ｗが残差予測子にさらに乗算される。したがって、現在ブロックの最終予測子は、ＣｕｒｒＴＲｅｆ＋ｗ＊（ＢａｓｅＴＲｅｆ−Ｂａｓｅ）、すなわち、ブロック１５６＋ｗ＊（ブロック１６４ マイナス ブロック１６０）として示される。重み付け係数ｗは、たとえば、０．５または１．０の値を有し得る。

[0165]時間動きベクトル１６６および１６６’は、値が等しいが、異なるブロックに適用されることを理解されたい。この例では、時間動きベクトル１６６は、参照ブロック１５６を識別するためにブロック１５２に適用され、時間動きベクトル１６６’は、ブロック１６４を識別するためにブロック１６０に適用され得る。同様に、視差ベクトル１６８および１６８’は、値が等しいが、異なるブロックに適用される。この例では、視差ベクトル１６８は、ブロック１６０を識別するためにブロック１５２に適用され得、視差ベクトル１６８’は、ブロック１６４を識別するためにブロック１５６に適用され得る。

[0166]図１０は、双方向予測の場合の、現在ブロックと参照ブロックと動き補償ブロックとの間の関係を示す概念図である。図９の上記の説明は、単方向予測が適用されるという仮定に基づく。図１０に示されているように、双方向予測の場合に拡張されるとき、図９に関して説明した上記のステップは各参照ピクチャリストのために適用され得る。現在ブロックが１つの参照ピクチャリストのための（異なるビュー中の）ビュー間参照ピクチャを使用するとき、残差予測プロセスは無効化され得る。

[0167]デコーダ側における提案するＡＲＰの主要なプロシージャについて以下のように説明することができる。
１．ターゲット参照ビューを指す、現在の３Ｄ−ＨＥＶＣにおいて指定されている視差ベクトルを取得する。次いで、同じアクセスユニット内の参照ビューのピクチャ中で、対応するブロックが視差ベクトルによって位置を特定される。
２．参照ブロックのための動き情報を導出するために、現在ブロックの動き情報を再利用する。残差ブロックを導出するために、現在ブロックの同じ動きベクトルと、参照ブロックのための参照ビュー中の導出された参照ピクチャと基づいて、対応するブロックのための動き補償を適用する。現在ブロックと、対応するブロックと、動き補償ブロックとの間の関係が図４に示されている。現在ビュー（Ｖｍ）の参照ピクチャと同じＰＯＣ（ピクチャ順序カウント（Picture Order Count)）値を有する参照ビュー（Ｖ０）中の参照ピクチャが、対応するブロックの参照ピクチャとして選択される。
３．重み付けされた残差ブロックを得るために残差ブロックに重み付け係数を適用し、予測されたサンプルに重み付けされた残差ブロックの値を加算する。

[0168]一例では、３つの重み付け係数、すなわち０、０．５、および１がＡＲＰにおいて使用される。ビデオエンコーダ、たとえば、ビデオエンコーダ２０は、現在ＣＵのための最小レートひずみコストにつながる重み付け係数を最終重み付け係数として選択し得、対応する重み付け係数インデックス（たとえば、それぞれ重み付け係数０、１、および０．５に対応し得る０、１および２）がＣＵレベルでビットストリーム中で送信され得る。１つのＣＵにおけるすべてのＰＵ予測は同じ重み付け係数を共有し得る。重み付け係数が０に等しいとき、ＡＲＰは現在ＣＵのために使用されない。

[0169]http://phenix.int-evry.fr/jct3v/doc_end_user/current_document.php?id=487で入手可能な、Ｚｈａｎｇらの、「3D-CE4: Advanced residual prediction for multiview coding」、ＪＣＴ３Ｖ−Ｃ００４９、ジュネーブ、スイス、２０１３年１月１７〜２３日では、非０の重み付け係数を用いてコーディングされる予測ユニットの参照ピクチャはブロックごとに異なり得る。したがって、参照ビューとは異なるピクチャが、対応するブロックの動き補償ブロック（図９ではブロック１６４）を生成するためにアクセスされる必要があり得る。ＪＣＴ３Ｖ−Ｃ００４９は、重み付け係数が０に等しくないとき、残差生成プロセスのための動き補償を実行する前に、固定ピクチャへ現在ＰＵの復号動きベクトルをスケーリングすることを提案した。

[0170]ＪＣＴ３Ｖ−Ｄ０１７７では、固定ピクチャは、それが同じビューからのものである場合、各参照ピクチャリストの第１番目の参照ピクチャとして定義される。復号動きベクトルが固定ピクチャを指さないとき、動きベクトルは、最初にスケーリングされ、次いでＣｕｒｒＴＲｅｆおよびＢａｓｅＴＲｅｆを識別するために使用される。ＡＲＰのために使用されるそのような参照ピクチャはターゲットＡＲＰ参照ピクチャと呼ばれる。

[0171]ＪＣＴ３Ｖ−Ｃ００４９では、双線形フィルタ（a bi-linear filter）が、対応するブロックおよびそれの予測ブロックの補間プロセス中に適用される。非ベースビュー中の現在ＰＵの予測ブロックのために、従来の８／４タップフィルタが適用される。ＪＣＴ３Ｖ−Ｄ０１７７は、ＡＲＰが適用されるとき、ブロックがベースビュー中にあるのか非ベースビュー中にあるのかにかかわらず、双線形フィルタを常に採用することを提案した。

[0172]参照ビューは、ＮＢＤＶプロセスから返されるビュー順序インデックスによって識別される。３Ｄ−ＨＴＭバージョン７．０におけるＡＲＰの設計では、１つの参照ピクチャリスト中の１つのＰＵの参照ピクチャが現在ビューの異なるビューからのものであるとき、ＡＲＰはこの参照ピクチャリストについて無効化される。

[0173]図１１は、ＡＲＰのさらなる改善を示す概念図である。ＪＣＴ３Ｖ−Ｄ０１７７に記載されているＡＲＰは時間予測にのみ適用され得、すなわち、現在ブロックの現在動きベクトルは同じビュー中の参照ピクチャを指す。２０１３年６月２１日に出願された米国仮出願第６１／８３８，２０８号、および２０１３年７月１４日に出願された米国仮出願第６１／８４６，０３６号では、ビュー間予測のためにＡＲＰを適用するためのソリューション（すなわち、現在ブロックの現在動きベクトルが、異なるビュー中の参照ピクチャを指す）について説明した。これらの２つの仮出願によれば、
ＡＲＰにおいて、異なるアクセスユニットにおいて計算されるビュー間残差が、［図１１］に示されているように、現在ブロックの残差を予測するために使用され得ることが提案される。現在ブロック（Ｃｕｒｒ）の動きベクトルが視差動きベクトル（ＤＭＶ）であり、（ＤＭＶによって識別される）参照ビュー中の参照ブロック（Ｂａｓｅ）が少なくとも１つの時間動きベクトルを含んでいるとき、参照ビュー中の参照ブロック（Ｂａｓｅ）の時間動きベクトルは、ＤＭＶとともに、参照ビュー中の時間参照ブロック（ＢａｓｅＴＲｅｆ）を識別するために使用され、時間動きベクトルは、現在ビュー中の時間参照ブロック（ＣｕｒｒＴＲｅｆ）を識別するために使用される。したがって、異なるアクセスユニット中のビュー間残差予測子は、これらの２つの後者のブロック間の差、すなわち、ＣｕｒｒＴＲｅｆ−ＢａｓｅＴＲｅｆとして計算され得る。ビュー間残差予測子として示された差分信号は、現在ブロックの残差を予測するために使用され得る。現在ブロックの予測信号は、ビュー間予測子（Ｂａｓｅ）と、重み付け係数ｗを用いた、異なるアクセスユニット中の予測されたビュー間残差との和、すなわち、Ｂａｓｅ＋ｗ＊（ＣｕｒｒＴＲｅｆ−ＢａｓｅＴＲｅｆ）である。

[0174]より詳細には、図１１は、現在ブロック１８２を含む現在ピクチャ１８０と、ブロック１８６を含むピクチャ１８４と、ブロック１９０を含む異なるビュー中のピクチャ１８８と、ブロック１９４を含むピクチャ１９２とを示す。図１１の例では、ブロック１９０は、視差動きベクトル１９８によって示されるように、現在ブロック１８２のための参照ブロックとして使用され得る。ブロック１９０は、ブロック１９０のための参照ブロックとしてブロック１９４を識別する時間動きベクトル１９６のためのデータをさらに含み得る。時間動きベクトル１９６は、ブロック１８６を識別するために現在ブロック１８２に適用され得る（時間動きベクトル１９６’）。重み付け係数がそれに適用され得る、ブロック１８６とブロック１９４との間の残差（ピクセルごとの差）は、現在ブロック１８２のための残差予測子として使用され得る。言い換えれば、現在ブロック１８２のための予測子は、ブロック１９０＋ｗ＊（ブロック１８６ マイナス ブロック１９４）に等しいことがあり、ここで、予測子およびブロックは予測子およびブロックのピクセルサンプルを指す。

[0175]以下の表５は、照明補償およびＡＲＰ関連シンタックス要素を含む、ビデオパラメータセット拡張を示す。以下の表５〜表７の各々の関連するシンタックス要素のためのセマンティクスは、表７の下で与えられる。

[0176]以下の表６は、概略的なスライスヘッダシンタックス要素を示す。

[0177]以下の表７は、概略的なコーディングユニットシンタックス要素を示す。

[0178]表５〜表７のいくつかの関連するシンタックス要素のための例示的なセマンティクスについて以下で説明する。これらのセマンティクスは例であり、他の例では異なる様式で定義され得ることを理解されたい。たとえば、０および１の値のためのセマンティクスはスワップされ得る。同様に、推論値は変更され得る。

[0179]ｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｆｌａｇ［ｌａｙｅｒＩｄ］は、ｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄをもつレイヤの復号プロセス中でビュー間残差予測が使用されるかどうかを示す。０に等しいｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｆｌａｇ［ｌａｙｅｒＩｄ］は、ｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄをもつレイヤのためにビュー間残差予測が使用されないことを指定する。１に等しいｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｆｌａｇ［ｌａｙｅｒＩｄ］は、ｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄをもつレイヤのためにビュー間残差予測が使用され得ることを指定する。存在しないとき、ｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｆｌａｇ［ｌａｙｅｒＩｄ］の値は０に等しいと推論されるものとする。

[0180]ｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｗｅｉｇｈｔ＿ｉｄｘは、残差予測のために使用される重み付け係数のインデックスを指定する。０に等しいｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｗｅｉｇｈｔ＿ｉｄｘは、現在コーディングユニットのために残差予測が使用されないことを指定する。０に等しくないｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｗｅｉｇｈｔ＿ｉｄｘは、現在コーディングユニットのために残差予測が使用されることを指定する。存在しないとき、ｉｖ＿ｒｅｓ＿ｐｒｅｄ＿ｗｅｉｇｈｔ＿ｉｄｘの値は０に等しいと推論される。

[0181]変数ｉｃＥｎａｂｌｅＦｌａｇは０に等しく設定され、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇが１に等しく、ＰａｒｔＭｏｄｅが２Ｎ×２Ｎに等しく、ＰｒｅｄＭｏｄｅ［ｘ０］［ｙ０］がＭＯＤＥ＿ＩＮＴＲＡに等しくないとき、以下が適用される。
・ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］が１に等しい場合、以下が適用される。

・他の場合（ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］が０に等しい）、以下が適用される。
○Ｘが０および１によって置き換えられる場合、変数ｒｅｆＶｉｅｗＩｄｘＬＸは、ＲｅｆＰｉｃＬｉｓｔＬＸ［ｒｅｆ＿ｉｄｘ＿ｌＸ［ｘ０］［ｙ０］］のビュー順序インデックスに等しく設定される。
○フラグｉｃＥｎａｂｌｅＦｌａｇは、以下において指定されているように導出される。

[0182]１に等しいｉｃ＿ｆｌａｇは、現在コーディングユニットのために照明補償が使用されることを指定する。０に等しいｉｃ＿ｆｌａｇは、現在コーディングユニットのために照明補償が使用されないことを指定する。存在しないとき、ｉｃ＿ｆｌａｇは０に等しいと推論される。

[0183]１に等しいｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇは、現在スライスのために照明補償が有効化されることを指定する。０に等しいｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇは、現在スライスのために照明補償が無効化されることを指定する。存在しないとき、ｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇは０に等しいと推論される。

[0184]１に等しいｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは、ｍｅｒｇｅ＿ｆｌａｇが１に等しく、コーディングユニットの第１の予測ユニットのｍｅｒｇｅ＿ｉｄｘが０に等しいとき、ｉｃ＿ｆｌａｇが現在スライスのコーディングユニット中に存在しないことを指定する。０に等しいｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは、ｍｅｒｇｅ＿ｆｌａｇが１に等しく、コーディングユニットの第１の予測ユニットのｍｅｒｇｅ＿ｉｄｘが０に等しいとき、ｉｃ＿ｆｌａｇが現在スライスのコーディングユニット中に存在し得ることを指定する。存在しないとき、ｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇは０に等しいと推論される。

[0185]図１２は、本開示の技法による、ブロックを符号化するための例示的な方法を示すフローチャートである。説明の目的で、図１２の方法についてビデオエンコーダ２０に関して説明するが、他のデバイスが図１２の方法を実行するように構成され得ることを理解されたい。

[0186]最初に、この例では、ビデオエンコーダ２０が、現在ブロック、たとえば、現在コーディングユニット（ＣＵ）の現在予測ユニット（ＰＵ）、を受信する（２５０）。次いで、ビデオエンコーダ２０のモード選択ユニット４０が、現在ブロックのための予測モードを決定する（２５２）。たとえば、モード選択ユニット４０は、時間インター予測、ビュー間予測、高度残差予測（ＡＲＰ）、および照明補償など、様々な予測モードのためのレートひずみメトリックを決定し得る。

[0187]モード選択ユニット４０が現在ブロックのための予測モードとしてＡＲＰを選択した場合（２５４の「はい」分岐）、ビデオエンコーダ２０は現在ブロックのための非０のＡＲＰ重み付け係数をシグナリングする（２５８）。たとえば、モード選択ユニット４０は、この場合もレートひずみメトリックに基づき得る、０．５または１．０のＡＲＰ重み付け係数を使用すべきかどうかを決定し得る。特に、この場合、ＡＲＰ重み付け係数が非０であることにより、予測モードは、ＡＲＰであり、照明補償でないと推論され得るので、ビデオエンコーダ２０は照明補償シンタックス要素（たとえば、ｉｃ＿ｆｌａｇ）をシグナリングする必要はない。

[0188]次いで、ビデオエンコーダ２０は、ＡＲＰを使用して現在ブロックを予測する（２６０）。たとえば、動き補償ユニット４４は、現在ブロックの時間動きベクトルまたは視差動きベクトルのいずれかを使用して参照ブロックを決定し得る。動き推定ユニット４２は、時間動きベクトルまたは視差動きベクトルを計算し得る。動き補償ユニット４４は、図９および図１１に関して上記で説明したように、たとえば、（視差ベクトルによって識別される）参照ビュー中のブロックまたは（時間動きベクトルによって識別される）現在ビュー中のブロックのいずれかと、（現在ブロックの位置に対する視差ベクトルまたは視差動きベクトルと時間動きベクトルとの組合せによって示される）ベースビュー参照ブロックとの間の差として、残差予測子をさらに計算し得る。

[0189]予測モードがＡＲＰでないとき（２５４の「いいえ」分岐）、および予測モードが照明補償であるとき（２５６の「はい」分岐）、ビデオエンコーダ２０は、ＡＲＰ重み付け係数（ＷＦ）のための０の値、およびｉｃ＿ｆｌａｇなどの照明補償シンタックス要素のための真の値（たとえば、１）をシグナリングし得る（２６２）。すなわち、ビデオエンコーダ２０は、現在ブロックのために照明補償が使用されることを示す照明補償シンタックス要素のための値をシグナリングする。さらに、ビデオエンコーダ２０は、照明補償を使用して現在ブロックを予測し得る（２６４）。すなわち、図８に関して上記で説明したように、ビデオエンコーダ２０は、視差動きベクトルを使用して現在ブロックのための参照ブロックを決定し、現在ブロックに隣接するピクセル（図８中の隣接ピクセル１２４）と参照ブロックに隣接するピクセル（図８中の隣接ピクセル１３０）とに基づいて参照ブロックのピクセルを線形的に変更するために使用されるべき値を決定し得る。

[0190]予測モードがＡＲＰでないとき（２５４の「いいえ」分岐）、および予測モードが照明補償でないとき（２５６の「いいえ」分岐）、ビデオエンコーダ２０は、ＡＲＰ重み付け係数（ＷＦ）のための０の値、およびｉｃ＿ｆｌａｇなどの照明補償シンタックス要素のための偽の値（たとえば、０）をシグナリングし得る（２６６）。すなわち、ビデオエンコーダ２０は、現在ブロックのために照明補償が使用されないことを示す照明補償シンタックス要素のための値をシグナリングする。ビデオエンコーダ２０は、さらに、実際の予測モードを示す１つまたは複数のシンタックス要素をシグナリングし得る（２６８）。代替的に、予測モードはインター予測であると推論され得、現在ブロックのためにシグナリングされる動きパラメータは、追加のシンタックス要素がシグナリングされる必要がないように、予測モードが時間インター予測であるのかビュー間予測であるのかを本質的に示し得る。さらに、ビデオエンコーダ２０は、シグナリングされた（またはデフォルトの）予測モードを使用して現在ブロックをさらに予測し得る（２７０）。

[0191]現在ブロックを予測した後、ビデオエンコーダ２０は現在ブロックのための残差ブロックを計算し得る（２７２）。予測されたブロックを計算するために使用されるモードにかかわらず、ビデオエンコーダ２０は、現在ブロックと予測されたブロックとの間のピクセルごとの差を計算することによって残差ブロックを計算し得る。次いで、ビデオエンコーダ２０は残差ブロックを変換し、量子化し、エントロピー符号化し得る（２７４）。より詳細には、変換処理ユニット５２は、たとえば、離散コサイン変換（ＤＣＴ）を使用して残差ブロックを変換し、量子化ユニット５４は得られた変換係数を量子化し、エントロピー符号化ユニット５６は量子化変換係数をエントロピー符号化する。もちろん、エントロピー符号化ユニット５６は、他のシンタックス要素、たとえば、ＡＲＰ重み付け係数および（シグナリングされる場合）照明補償シンタックス要素、ならびに現在ブロックのための動きパラメータをもエントロピー符号化し得る。

[0192]このようにして、図１２の方法は、現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素の符号化をスキップすることと、現在ブロックを符号化することとを含む、ビデオデータを符号化する方法の例を表す。図１２の例示的な方法は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素を符号化することと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックを符号化することとをさらに含む。

[0193]図１３は、本開示の技法による、ブロックを復号するための例示的な方法を示すフローチャートである。説明の目的で、図１３の方法についてビデオデコーダ３０に関して説明するが、他のデバイスが図１３の方法を実行するように構成され得ることを理解されたい。

[0194]最初に、ビデオデコーダ３０が現在ブロックを受信する（２８０）。より詳細には、ビデオデコーダ３０は現在ブロックのためのエントロピー符号化シンタックス要素を受信する。ビデオデコーダ３０は各シンタックス要素を個々に復号し得る。ＡＲＰ重み付け係数シンタックス要素に達すると、ビデオデコーダ３０は、ＡＲＰ重み付け係数が現在ブロックのために０の値を有するかどうかを決定し得る（２８２）。

[0195]ＡＲＰ重み付け係数が０でない値を有する場合（２８２の「いいえ」分岐）、ビデオデコーダ３０は、ＡＲＰが現在ブロックを予測するために使用されると決定し得る。したがって、エントロピー復号ユニット７０は、この照明補償シンタックス要素がビットストリーム中に含まれないという暗示に基づいて、現在ブロックのための照明補償シンタックス要素を復号することを試みることをスキップし得る。したがって、ビデオデコーダ３０は、ＡＲＰを使用して現在ブロックを予測し得る（２８６）。たとえば、図９および図１１に関して上記で説明したように、動き補償ユニット７２は、たとえば、（視差ベクトルによって識別される）参照ビュー中のブロックまたは（時間動きベクトルによって識別される）現在ビュー中のブロックのいずれかと、（現在ブロックの位置に対する視差ベクトルまたは視差動きベクトルと時間動きベクトルとの組合せによって示される）ベースビュー参照ブロックとの間の差として、残差予測子を計算し、残差予測子にＡＲＰ重み付け係数を適用し得る。動き補償ユニット７２はまた、視差動きベクトルまたは時間動きベクトルのいずれかを使用して現在ブロックのための予測子を計算し、現在ブロックのための予測されたブロックを生成するために予測子を（ＡＲＰ重み付け係数によって変更された）残差予測子と組み合わせ得る。

[0196]しかしながら、ＡＲＰ重み付け係数が０に等しい場合（２８２の「はい」分岐）、ビデオデコーダ３０は、照明補償シンタックス要素が現在ブロックのためのビットストリーム中でシグナリングされると決定し得る。したがって、エントロピー復号ユニット７０は、照明補償シンタックス要素（たとえば、ｉｃ＿ｆｌａｇ）のための値を復号し得、ビデオデコーダ３０は、照明補償シンタックス要素が真の値（たとえば、１）を有するのか、偽の値（たとえば、０）を有するのかを決定し得（２８４）、ここで、真の値または１は、照明補償が使用されることを示し、偽または０は、照明補償が使用されないことを示すと仮定する。

[0197]照明補償シンタックス要素が真の値を有するとき（２８４の「はい」分岐）、ビデオデコーダ３０は、照明補償を使用して現在ブロックを予測し得る（２８８）。すなわち、図８に関して上記で説明したように、ビデオデコーダ３０は、視差動きベクトルを使用して現在ブロックのための参照ブロックを決定し、現在ブロックに隣接するピクセル（図８中の隣接ピクセル１２４）と参照ブロックに隣接するピクセル（図８中の隣接ピクセル１３０）とに基づいて参照ブロックのピクセルを線形的に変更するために使用されるべき値を決定し得る。

[0198]照明補償シンタックス要素が偽の値を有するとき（２８４の「いいえ」分岐）、ビデオデコーダ３０は、現在ブロックのための実際の予測モードを決定し（２９０）、その予測モードを使用して現在ブロックを予測し得る（２９２）。たとえば、現在ブロックがインター予測ブロックであり、予測モードがＡＲＰでも照明補償でもないとき、ビデオデコーダ３０は、予測モードが、たとえば、現在ブロックのための動きパラメータによって示される、ビュー間予測または時間インター予測のいずれかであり得る、インター予測であると推論し得る。すなわち、参照ピクチャが現在ピクチャと同じＰＯＣ値を有する場合、予測モードはビュー間予測であるが、参照ピクチャが現在ピクチャとは異なるＰＯＣ値を有する場合、予測モードは時間インター予測である。動き補償ユニット７２は、現在ブロックのための動きベクトル（時間または視差）を復号し、動きベクトルを使用して現在ブロックを予測するために、動きパラメータを使用し得る。

[0199]次いで、ビデオデコーダ３０は、現在ブロックのための残差ブロックを逆量子化し、逆変換し得る（２９４）。すなわち、逆量子化ユニット７６は、残差ブロックのための変換係数を再生するために残差ブロックのためのエントロピー復号データを逆量子化し得、逆変換ユニット７８は、残差ブロックを再生するために変換係数を逆変換し得る。次いで、ビデオデコーダ３０は、現在ブロックを復号するために残差ブロックと予測されたブロックとを組み合わせ得る（２９６）。すなわち、ビデオデコーダ３０は、現在ブロックを再生するために残差ブロックと予測されたブロックとの間のピクセルごとの加算を実行し得る。

[0200]このようにして、図１３の方法は、現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、ＡＲＰ重み付け係数の値が０に等しくないとき、現在ブロックのための照明補償シンタックス要素の復号をスキップすることと、現在ブロックを復号することとを含む、ビデオデータを復号する方法の例を表す。図１３の方法は、ＡＲＰ重み付け係数の値が０に等しいとき、現在ブロックのための照明補償シンタックス要素を復号することと、照明補償シンタックス要素の値に少なくとも部分的に基づいて現在ブロックを復号することとをさらに含む。

[0201]上記例に応じて、本明細書で説明した技法のうちのいずれかのいくつかの行為またはイベントが、異なるシーケンス中で実行され得、全体的に追加、結合、または除外され得る（たとえば、すべての説明した行為またはイベントが本技法の実施のために必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実行され得る。

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

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

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

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

[0206]様々な例について説明してきた。これらおよび他の例は以下の特許請求の範囲内に入る。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオデータをコーディングする方法であって、前記方法は、
現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、
前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、
前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、
前記現在ブロックをコーディングすることと
を備える方法。
［Ｃ２］
前記ＡＲＰ重み付け係数の前記値が０に等しいとき、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとをさらに備える、Ｃ１に記載の方法。
［Ｃ３］
前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、Ｃ２に記載の方法。
［Ｃ４］
前記照明補償シンタックス要素をコーディングすることは、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを備える、Ｃ２に記載の方法。
［Ｃ５］
前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングすることをさらに備え、ここにおいて、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることは、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを備える、Ｃ２に記載の方法。
［Ｃ６］
前記スライスレベル照明補償シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを備える、Ｃ５に記載の方法。
［Ｃ７］
前記照明補償シンタックス要素をコーディングすることは、前記ＡＲＰ重み付け係数が０に等しい値を有し、（ａ）または（ｂ）のうちの少なくとも１つが真である場合のみ、前記照明補償シンタックス要素をコーディングすることを備え、ここで、（ａ）は、前記現在ブロックが、マージモードを用いてコーディングされること、および（ｉ）または（ｉｉ）のうちの少なくとも１つであり、ここで、（ｉ）は、前記現在ブロックを含むスライスのためのスライスヘッダ中のシンタックス要素が、現在スライスのために照明補償モードが有効化されることを示す値を有することであり、ここで、（ｉｉ）は、前記現在ブロックのためのマージインデックスが０でない値を有することであり、ここで、（ｂ）は、前記現在ブロックが高度動きベクトル予測（ＡＭＶＰ）モードを用いてコーディングされること、および前記現在ブロックのための少なくとも１つの参照インデックスがビュー間参照ピクチャに対応することである、Ｃ２に記載の方法。
［Ｃ８］
前記スライスのための前記スライスヘッダ中の前記シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇを備える、Ｃ７に記載の方法。
［Ｃ９］
前記照明補償シンタックス要素をコーディングすることは、前記現在ブロックを含む現在ピクチャがイントラランダムアクセスピクチャ（ＩＲＡＰ）であるとき、前記照明補償シンタックス要素をコーディングすることを備える、Ｃ２に記載の方法。
［Ｃ１０］
照明補償がマルチレイヤビデオデータの少なくとも１つのレイヤのために使用されるかどうかを示す少なくとも１つのシンタックス要素をコーディングすることをさらに備える、Ｃ２に記載の方法。
［Ｃ１１］
前記照明補償シンタックス要素の前記値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることは、前記照明補償シンタックス要素の前記値が、前記現在ブロックが照明補償を使用してコーディングされるべきであることを示すとき、照明補償を使用して前記現在ブロックをコーディングすることを備える、Ｃ２に記載の方法。
［Ｃ１２］
前記ＡＲＰ重み付け係数の前記値が０に等しいとき、前記照明補償シンタックス要素の前記値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることは、前記照明補償シンタックス要素の前記値が、前記現在ブロックが、照明補償を使用して、ＡＲＰを使用せずに、ＡＲＰを使用せずにコーディングされるべきでないことを示すとき、照明補償を使用せずに前記現在ブロックをコーディングすることを備える、Ｃ２に記載の方法。
［Ｃ１３］
前記ＡＲＰ重み付け係数の前記値を決定することより前に、
前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、
前記現在ブロックがインターコーディングされるかどうかを決定することとをさらに備え、
ここにおいて、前記ＡＲＰ重み付け係数の前記値を決定することは、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記値を決定することを備える、
Ｃ１に記載の方法。
［Ｃ１４］
前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックをコーディングすることが、前記ＡＲＰ重み付け係数の前記値に基づいてＡＲＰを使用して前記現在ブロックをコーディングすることを備える、Ｃ１に記載の方法。
［Ｃ１５］
前記照明補償シンタックス要素のコーディングをスキップすることが、前記照明補償シンタックス要素の復号をスキップすることを備え、前記現在ブロックをコーディングすることが、前記現在ブロックを復号することを備える、Ｃ１に記載の方法。
［Ｃ１６］
前記照明補償シンタックス要素のコーディングをスキップすることが、前記照明補償シンタックス要素のシグナリングをスキップすること備え、前記現在ブロックをコーディングすることが、前記現在ブロックを符号化することを備える、Ｃ１に記載の方法。
［Ｃ１７］
ビデオデータをコーディングするためのデバイスであって、前記デバイスは、ビデオデータを記憶するように構成されたメモリと、前記ビデオデータの現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップことと、前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックをコーディングすることとを行うように構成されたビデオコーダとを備えるデバイス。
［Ｃ１８］
前記ビデオコーダは、前記ＡＲＰ重み付け係数の前記値が０に等しいとき、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとを行うようにさらに構成された、Ｃ１７に記載のデバイス。
［Ｃ１９］
前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、Ｃ１８に記載のデバイス。
［Ｃ２０］
前記ビデオコーダは、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを行うように構成された、Ｃ１８に記載のデバイス。
［Ｃ２１］
前記ビデオコーダは、前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングするようにさらに構成され、前記ビデオコーダは、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングするように構成された、Ｃ１８に記載のデバイス。
［Ｃ２２］
前記スライスレベル照明補償シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを備える、Ｃ２１に記載のデバイス。
［Ｃ２３］
前記ビデオコーダは、前記ＡＲＰ重み付け係数の前記値を決定することより前に、前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、前記現在ブロックがインターコーディングされるかどうかを決定することとを行うようにさらに構成され、前記ビデオコーダは、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記値を決定するように構成された、Ｃ１７に記載のデバイス。
［Ｃ２４］
ビデオデータをコーディングするためのデバイスであって、前記デバイスは、
現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定するための手段と、
前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップするための手段と、
前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックをコーディングするための手段と
を備えるデバイス。
［Ｃ２５］
命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、
現在ブロックの高度残差予測（ＡＲＰ）重み付け係数のための値を決定することと、
前記ＡＲＰ重み付け係数の前記値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、前記現在ブロックをコーディングすることと
をビデオデータをコーディングするためのデバイスのプロセッサに行わせる、コンピュータ可読記憶媒体。
［Ｃ２６］
前記ＡＲＰ重み付け係数の前記値が０に等しいとき、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとを前記プロセッサに行わせる命令をさらに備える、Ｃ２５に記載のコンピュータ可読記憶媒体。
［Ｃ２７］
前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、Ｃ２６に記載のコンピュータ可読記憶媒体。
［Ｃ２８］
前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる前記命令は、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを前記プロセッサに行わせる命令を備える、Ｃ２６に記載のコンピュータ可読記憶媒体。
［Ｃ２９］
前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる命令をさらに備え、ここにおいて、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる前記命令は、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる命令を備える、Ｃ２６に記載のコンピュータ可読記憶媒体。
［Ｃ３０］
前記ＡＲＰ重み付け係数の前記値を決定することより前に、
前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、
前記現在ブロックがインターコーディングされるかどうかを決定することと
を前記プロセッサに行わせる命令をさらに備え、
ここにおいて、前記ＡＲＰ重み付け係数の前記値を決定することを前記プロセッサに行わせる前記命令は、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記値を決定することを前記プロセッサに行わせる命令を備える、
Ｃ２５に記載のコンピュータ可読記憶媒体。

Claims (29)

1. ビデオデータをコーディングする方法であって、前記方法は、
   高度残差予測（ＡＲＰ）処理のＡＲＰ重み付け係数のための第１の値を決定することと、前記ＡＲＰ重み付け係数は、現在ブロックのためのものであり、ここにおいて、前記現在ブロックは、現在ビューの現在ピクチャ中に含まれ、前記ＡＲＰ重み付け係数は、参照ビュー中の第１のビュー間参照ピクチャの第１の参照ブロックと前記参照ビュー中の第２のビュー間参照ピクチャの第２の参照ブロックとの間のピクセルごとの差に適用されるべき重み値を備え、前記現在ビューは、前記参照ビューとは異なる、
   前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないと決定することに応答して、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、
   前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないと決定することに応答して、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングすることと
   を備え、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングすることは、
   重み付けされたピクセル差分を生成するために、前記第１の参照ブロックと前記第２の参照ブロックとの間の前記ピクセルごとの差に前記重み値を適用することと、
   前記重み付けされたピクセル差分を使用して前記現在ブロックを予測することと
   を備える、方法。
2. 前記ＡＲＰ重み付け係数の前記第１の値が０に等しいと決定することに応答して、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとをさらに備える、請求項１に記載の方法。
3. 前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、請求項２に記載の方法。
4. 前記照明補償シンタックス要素をコーディングすることは、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを備える、請求項２に記載の方法。
5. 前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングすることをさらに備え、ここにおいて、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることは、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを備える、請求項２に記載の方法。
6. 前記スライスレベル照明補償シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを備える、請求項５に記載の方法。
7. 前記照明補償シンタックス要素をコーディングすることは、前記ＡＲＰ重み付け係数が０に等しい値を有し、（ａ）または（ｂ）のうちの少なくとも１つが真である場合のみ、前記照明補償シンタックス要素をコーディングすることを備え、ここで、（ａ）は、前記現在ブロックが、マージモードを用いてコーディングされること、および（ｉ）または（ｉｉ）のうちの少なくとも１つであり、ここで、（ｉ）は、前記現在ブロックを含むスライスのためのスライスヘッダ中のシンタックス要素が、現在スライスのために照明補償モードが有効化されることを示す値を有することであり、ここで、（ｉｉ）は、前記現在ブロックのためのマージインデックスが０でない値を有することであり、ここで、（ｂ）は、前記現在ブロックが高度動きベクトル予測（ＡＭＶＰ）モードを用いてコーディングされること、および前記現在ブロックのための少なくとも１つの参照インデックスが前記第１のビュー間参照ピクチャまたは前記第２のビュー間参照ピクチャのうちの１つを備えるビュー間参照ピクチャに対応することである、請求項２に記載の方法。
8. 前記スライスのための前記スライスヘッダ中の前記シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｄｉｓａｂｌｅ＿ｍｅｒｇｅ＿ｚｅｒｏ＿ｉｄｘ＿ｆｌａｇを備える、請求項７に記載の方法。
9. 前記照明補償シンタックス要素をコーディングすることは、前記現在ブロックを含む現在ピクチャがイントラランダムアクセスピクチャ（ＩＲＡＰ）であるとき、前記照明補償シンタックス要素をコーディングすることを備える、請求項２に記載の方法。
10. 照明補償がマルチレイヤビデオデータの少なくとも１つのレイヤのために使用されるかどうかを示す少なくとも１つのシンタックス要素をコーディングすることをさらに備える、請求項２に記載の方法。
11. 前記照明補償シンタックス要素の前記値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることは、前記照明補償シンタックス要素の前記値が、前記現在ブロックが照明補償を使用してコーディングされるべきであることを示すとき、照明補償を使用して前記現在ブロックをコーディングすることを備える、請求項２に記載の方法。
12. 前記ＡＲＰ重み付け係数の前記第１の値が０に等しいとき、前記照明補償シンタックス要素の前記値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることは、前記照明補償シンタックス要素の前記値が、前記現在ブロックが、照明補償を使用して、ＡＲＰを使用せずに、コーディングされるべきでないことを示すとき、照明補償を使用せずに前記現在ブロックをコーディングすることを備える、請求項２に記載の方法。
13. 前記ＡＲＰ重み付け係数の前記第１の値を決定することより前に、
    前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、
    前記現在ブロックがインターコーディングされるかどうかを決定することとをさらに備え、
    ここにおいて、前記ＡＲＰ重み付け係数の前記第１の値を決定することは、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記第１の値を決定することを備える、請求項１に記載の方法。
14. 前記照明補償シンタックス要素のコーディングをスキップすることが、前記照明補償シンタックス要素の復号をスキップすることを備え、前記現在ブロックをコーディングすることが、前記現在ブロックを復号することを備える、請求項１に記載の方法。
15. 前記照明補償シンタックス要素のコーディングをスキップすることが、前記照明補償シンタックス要素のシグナリングをスキップすること備え、前記現在ブロックをコーディングすることが、前記現在ブロックを符号化することを備える、請求項１に記載の方法。
16. ビデオデータをコーディングするためのデバイスであって、前記デバイスは、
    ビデオデータを記憶するように構成されたメモリと、
    回路において実装され、
    高度残差予測（ＡＲＰ）処理のＡＲＰ重み付け係数のための第１の値を決定することと、前記ＡＲＰ重み付け係数は、前記ビデオデータの現在ブロックのためのものであり、ここにおいて、前記現在ブロックは、現在ビューの現在ピクチャ中に含まれ、前記ＡＲＰ重み付け係数は、参照ビュー中の第１のビュー間参照ピクチャの第１の参照ブロックと前記参照ビュー中の第２のビュー間参照ピクチャの第２の参照ブロックとの間のピクセルごとの差に適用されるべき重み値を備え、前記現在ビューは、前記参照ビューとは異なる、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングすることと
    を行うように構成されたビデオコーダと
    を備え、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングするために、前記ビデオコーダは、
    重み付けされたピクセル差分を生成するために、前記第１の参照ブロックと前記第２の参照ブロックとの間の前記ピクセルごとの差に前記重み値を適用することと、
    前記重み付けされたピクセル差分を使用して前記現在ブロックを予測することと
    を行うように構成される、デバイス。
17. 前記ビデオコーダは、前記ＡＲＰ重み付け係数の前記第１の値が０に等しいとき、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとを行うようにさらに構成された、請求項１６に記載のデバイス。
18. 前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、請求項１７に記載のデバイス。
19. 前記ビデオコーダは、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを行うように構成された、請求項１７に記載のデバイス。
20. 前記ビデオコーダは、前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングするようにさらに構成され、前記ビデオコーダは、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングするように構成された、請求項１７に記載のデバイス。
21. 前記スライスレベル照明補償シンタックス要素がｓｌｉｃｅ＿ｉｃ＿ｅｎａｂｌｅ＿ｆｌａｇを備える、請求項２０に記載のデバイス。
22. 前記ビデオコーダは、前記ＡＲＰ重み付け係数の前記第１の値を決定することより前に、前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、前記現在ブロックがインターコーディングされるかどうかを決定することとを行うようにさらに構成され、前記ビデオコーダは、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記第１の値を決定するように構成された、請求項１６に記載のデバイス。
23. ビデオデータをコーディングするためのデバイスであって、前記デバイスは、
    高度残差予測（ＡＲＰ）処理のＡＲＰ重み付け係数のための第１の値を決定するための手段と、前記ＡＲＰ重み付け係数は、現在ブロックのためのものであり、ここにおいて、前記現在ブロックは、現在ビューの現在ピクチャ中に含まれ、前記ＡＲＰ重み付け係数は、参照ビュー中の第１のビュー間参照ピクチャの第１の参照ブロックと前記参照ビュー中の第２のビュー間参照ピクチャの第２の参照ブロックとの間のピクセルごとの差に適用されるべき重み値を備え、前記現在ビューは、前記参照ビューとは異なる、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップするための手段と、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングするための手段と
    を備え、前記ＡＲＰ処理を使用して前記現在ブロックを前記コーディングするための手段は、
    重み付けされたピクセル差分を生成するために、前記第１の参照ブロックと前記第２の参照ブロックとの間の前記ピクセルごとの差に前記重み値を適用するための手段と、
    前記重み付けされたピクセル差分を使用して前記現在ブロックを予測するための手段とを備える、デバイス。
24. 命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令は、実行されたとき、
    高度残差予測（ＡＲＰ）処理のＡＲＰ重み付け係数のための第１の値を決定することと、前記ＡＲＰ重み付け係数は、現在ブロックのためのものであり、ここにおいて、前記現在ブロックは、現在ビューの現在ピクチャ中に含まれ、前記ＡＲＰ重み付け係数は、参照ビュー中の第１のビュー間参照ピクチャの第１の参照ブロックと前記参照ビュー中の第２のビュー間参照ピクチャの第２の参照ブロックとの間のピクセルごとの差に適用されるべき重み値を備え、前記現在ビューは、前記参照ビューとは異なる、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記現在ブロックのための照明補償シンタックス要素のコーディングをスキップすることと、
    前記ＡＲＰ重み付け係数の前記第１の値が０に等しくないとき、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングすることと
    をビデオデータをコーディングするためのデバイスのプロセッサに行わせ、前記ＡＲＰ処理を使用して前記現在ブロックをコーディングすることを前記プロセッサに行わせる前記命令は、
    重み付けされたピクセル差分を生成するために、前記第１の参照ブロックと前記第２の参照ブロックとの間の前記ピクセルごとの差に前記重み値を適用することと、
    前記重み付けされたピクセル差分を使用して前記現在ブロックを予測することと
    を前記プロセッサに行わせる命令を備える、非一時的コンピュータ可読記憶媒体。
25. 前記ＡＲＰ重み付け係数の前記第１の値が０に等しいとき、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることと、前記照明補償シンタックス要素の値に少なくとも部分的に基づいて前記現在ブロックをコーディングすることとを前記プロセッサに行わせる命令をさらに備える、請求項２４に記載の非一時的コンピュータ可読記憶媒体。
26. 前記照明補償シンタックス要素がｉｃ＿ｆｌａｇシンタックス要素を備える、請求項２５に記載の非一時的コンピュータ可読記憶媒体。
27. 前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる前記命令は、前記現在ブロックのために照明補償が有効化されるかどうかを決定することと、前記現在ブロックのために照明補償が有効化されるときのみ、前記照明補償シンタックス要素をコーディングすることとを前記プロセッサに行わせる命令を備える、請求項２５に記載の非一時的コンピュータ可読記憶媒体。
28. 前記現在ブロックを含むスライスのために照明補償が有効化されるかどうかを示すスライスレベル照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる命令をさらに備え、ここにおいて、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる前記命令は、前記スライスレベル照明補償シンタックス要素が、前記スライスのために照明補償が有効化されることを示すときのみ、前記現在ブロックのための前記照明補償シンタックス要素をコーディングすることを前記プロセッサに行わせる命令を備える、請求項２５に記載の非一時的コンピュータ可読記憶媒体。
29. 前記ＡＲＰ重み付け係数の前記第１の値を決定することより前に、
    前記現在ブロックを含むスライスのためにＡＲＰが有効化されるかどうかを決定することと、
    前記現在ブロックがインターコーディングされるかどうかを決定することとを前記プロセッサに行わせる命令をさらに備え、
    ここにおいて、前記ＡＲＰ重み付け係数の前記第１の値を決定することを前記プロセッサに行わせる前記命令は、ＡＲＰが有効化されるとき、および前記現在ブロックがインターコーディングされるとき、前記ＡＲＰ重み付け係数の前記第１の値を決定することを前記プロセッサに行わせる命令を備える、請求項２４に記載の非一時的コンピュータ可読記憶媒体。