JP2015512222A - 変換係数コーディングのためのコンテキスト導出における走査ベーススライディングウィンドウ - Google Patents

Abstract

変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することを含むビデオコーディングプロセスである。本プロセスはまた、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することを含む。本プロセスはまた、判断されたコンテキストに基づいて複数の変換係数のうちの１つをコーディングすることを含む。

Description

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

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

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

[0004]ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間的予測および／または時間的予測を含む。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスはブロックに区分され得る。各ブロックはさらに区分され得る。イントラコード化（Ｉ）フレームまたはスライス中のブロックは、同じフレームまたはスライス中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化される。インターコード化（ＰまたはＢ）フレームまたはスライス中のブロックは、同じフレームまたはスライス中の隣接ブロック中の参照サンプルに対する空間的予測、あるいは他の参照フレーム中の参照サンプルに対する時間的予測を使用し得る。空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。

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

[0006]本開示の技法は、概して、ビデオデータをエントロピーコーディングすることに関する。たとえば、エントロピーコーディング中に、ビデオコーダは、変換係数についての情報を２値化された形態に変換し、それによって、１つまたは複数のビットまたは「ビン」を生成し得る。ビデオコーダは、次いで、ビンが所与の２進値を有する可能性を示し得る、各ビンの確率推定値を使用して変換係数の各ビンをコーディングし得る。確率推定値は、「コンテキストモデル」とも呼ばれる確率モデル内に含まれ得る。ビデオコーダは、ビンのコンテキストを判断することによってコンテキストモデルを選択し得る。シンタックス要素のビンについてのコンテキストは、他の変換係数に関連するシンタックス要素など、前にコーディングされたシンタックス要素の関係するビンの値に基づいて判断され得る。コンテキストが導出されるロケーションはコンテキスト導出近傍と呼ばれることがある（「コンテキストサポート近傍」または単に「サポート」と呼ばれることもある）。

[0007]本開示の態様は、概して、変換係数走査順序に基づくコンテキスト導出近傍に関する。たとえば、本開示の態様は、（ビデオエンコーダにおいて）変換係数の２次元アレイを変換係数の１次元アレイに直列化するために変換係数が走査されるか、または（ビデオデコーダにおいて）変換係数の１次元アレイから変換係数の２次元アレイを再構成するために逆走査される順序に基づいてサポートを判断することに関する。

[0008]一例では、本開示の態様は、変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することと、判断されたコンテキストに基づいて複数の変換係数のうちの１つをコーディングすることとを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングする方法に関する。

[0009]別の例では、本開示の態様は、変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することと、判断されたコンテキストに基づいて複数の変換係数のうちの１つをコーディングすることとを行うように構成された１つまたは複数のプロセッサを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置に関する。

[0010]別の例では、本開示の態様は、変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義するための手段と、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断するための手段と、判断されたコンテキストに基づいて複数の変換係数のうちの１つをコーディングするための手段とを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置に関する。

[0011]別の例では、本開示の態様は、実行されたとき、１つまたは複数のプロセッサに、変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することと、判断されたコンテキストに基づいて複数の変換係数のうちの１つをコーディングすることとを行わせる命令を備える非一時的コンピュータ可読媒体に関する。

[0012]本開示の１つまたは複数の態様の詳細を添付の図面および以下の説明に記載する。本開示で説明する技法の他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。

[0013]コンテキストを導出するための本開示の技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図。 [0014]コンテキストを導出するために本開示の技法を使用し得るビデオエンコーダ２０の一例を示すブロック図。 [0015]コンテキストを導出することを実行するための技法を実装し得るビデオデコーダ３０の一例を示すブロック図。 [0016]コーディング中にビデオデータのブロックに関連する変換係数を走査するための対角走査パターンを示す図。 コーディング中にビデオデータのブロックに関連する変換係数を走査するための対角走査パターンを示す図。 [0017]コンテキストを計算するためのコンテキスト導出近傍を示す図。 [0018]２つ以上のコンテキストを並行して計算するためのロケーションベースのコンテキスト導出近傍を示す図。 [0019]本開示の態様による、走査順序に基づく例示的なコンテキスト導出近傍スライディングウィンドウを示す図。 本開示の態様による、走査順序に基づく例示的なコンテキスト導出近傍スライディングウィンドウを示す図。 [0020]本開示の態様による、走査順序に基づき、２つのビンについてのコンテキストの並行した導出をサポートする例示的なコンテキスト導出近傍スライディングウィンドウを示す図。 [0021]本開示の態様による、例示的な初期コンテキスト導出近傍を示す図。 [0022]本開示の態様による、走査順序に基づくコンテキスト導出近傍を使用して変換係数をコーディングする技法を示す流れ図。 [0023]本開示の態様による、走査順序に基づくコンテキスト導出近傍を使用して変換係数をコーディングする技法を示す流れ図。

[0024]ビデオコーディングデバイスは、空間的冗長性と時間的冗長性とを利用することによってビデオデータを圧縮しようと試み得る。たとえば、ビデオエンコーダは、隣接する、前にコーディングされたブロックに対してブロックをコーディングすることによって空間的冗長性を利用し得る。同様に、ビデオエンコーダは、前にコーディングされたフレームのデータに対してブロックをコーディングすることによって時間的冗長性を利用し得る。具体的には、ビデオエンコーダは現在のブロックを、空間的隣接部分のデータから、または以前コーディングされたフレームのデータから予測し得る。次いでビデオエンコーダは、ブロックの実際のピクセル値とブロックの予測ピクセル値との間の差分としてブロックの残差を計算し得る。したがって、ブロックの残差は、ピクセル（または空間的）領域におけるピクセルごとの差分値を含み得る。

[0025]ビデオエンコーダは、次いで、残差の値に変換を適用して、ピクセル値のエネルギーを周波数領域における比較的小さい数の変換係数に圧縮し得る。ビデオエンコーダはまた、変換係数を量子化し得る。概して、「変換係数」という用語は、量子化されていることも量子化されていないこともある、残差ブロックのための変換領域における係数を指す。

[0026]ビデオエンコーダは、量子化変換係数を走査して、量子化変換係数の２次元行列を、量子化変換係数を含む１次元ベクトルに変換し得る。係数を走査するプロセスは、係数の直列化と呼ばれることがある。

[0027]ビデオエンコーダは、次いで、走査された変換係数、ならびにビデオデータを復号する際にビデオデコーダが使用するための符号化ビデオデータに関連する他のシンタックス要素をエントロピー符号化するためにエントロピーコーディングプロセスを適用し得る。例示的なエントロピーコーディングプロセスとしては、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは他のエントロピー符号化方法があり得る。以下でより詳細に説明するように、「変換係数」をエントロピーコーディングすることへの言及は、非量子化変換係数をエントロピーコーディングすること、ならびに量子化変換係数をエントロピーコーディングすることの両方を指すことがある。

[0028]概して、コンテキスト適応型コーディングは２値化値に対して実行される。したがって、ビデオエンコーダは、コーディングされている各値（たとえば、変換係数レベル、シンボル、シンタックス要素など）の絶対値を２値化形態に変換し得る。このようにして、コーディングされている各非ゼロ値は、たとえば、単項コーディングテーブルを使用して、または値を１つまたは複数のビットまたは「ビン」を有するコードワードに変換する他のコーディング方式を使用して、２値化され得る。

[0029]ビデオエンコーダは、次いで、ビデオデータのブロックに関連するシンボルをコーディングするために動作する確率モデルまたは「コンテキストモデル」を選択し得る。確率モデルは、ビンが所与の２進値（たとえば、「０」または「１」）を有する可能性を示す。したがって、エンコーダにおいて、確率モデルを使用することによってターゲットシンボルがコーディングされ得る。デコーダにおいて、確率モデルを使用することによってターゲットシンボルがパースされ得る。いずれの場合も、ビデオコーダは、ビンのコンテキストを判断することによって確率モデルを選択し得る。

[0030]シンタックス要素のビンのコンテキストは、前にコーディングされた隣接シンタックス要素の関係するビンの値を含み得る。一例として、現在のシンタックス要素のビンをコーディングするためのコンテキストは、たとえば、現在のシンタックス要素の上部および左側にある、前にコーディングされた隣接シンタックス要素の関係するビンの値を含み得る。コンテキストが導出されるロケーションはコンテキスト導出近傍と呼ばれることがある（「コンテキストサポート近傍」または単に「サポート」と呼ばれることもある）。たとえば、位置ベースのコンテキスト導出近傍は、現在コーディングされている変換係数に対する所定の変換係数ロケーションを含み得る。

[0031]一例では、説明のために、（たとえば、ビデオデータのブロックにおける非ゼロ変換係数のロケーションを示す）有効性マップのビンをコーディングするためのコンテキストモデルを定義するために５ポイントの位置ベースのサポートが使用され得る。５ポイントのサポートは、現在コーディングされている有効性フラグに隣接する５つの変換係数位置を含み得る。この例では、確率モデルはＣｔｘによって識別され、Ｃｔｘは、サポートのあらゆるポイント中の有効フラグの和として定義され得、ただし、有効性フラグは、以下の式（１）に示すように、対応する変換係数が非０である場合は「１」に設定され、対応する変換係数が０である場合は「０」に設定され、ただし、Ｓおよびｐは、サポート中の有効性フラグに対応する。

[0032]他の例では、コンテキストモデルは、前にコーディングされたサブブロックに関連する値（たとえば、前にコーディングされたサブブロック中の有効性フラグの数）に基づき得る。いずれの場合も、いくつかの例では、Ｃｔｘは、各々が特定の確率モデルに対応し得る複数の異なるコンテキストのうちの１つを選択するために適用されるインデックスまたはオフセットであり得る。したがって、いずれの場合も、一般に、コンテキストごとに異なる確率モデルが定義される。ビンをコーディングした後に、確率モデルは、ビンについての最新の確率推定値を反映するために、ビンの値に基づいてさらに更新される。たとえば、確率モデルは、有限状態機械における状態として維持され得る。各特定の状態は特定の確率値に対応し得る。確率モデルの更新に対応する次の状態は、現在のビン（たとえば、現在コーディングされているビン）の値に依存し得る。したがって、前にコーディングされたビンの値は、少なくとも部分的に、ビンが所与の値を有する確率を示すので、確率モデルの選択は、前にコーディングされたビンの値によって影響され得る。

[0033]いくつかの例によれば、ビデオブロック中の有効係数（すなわち、非０変換係数）の位置は、変換係数の「レベル」と呼ばれることがある、変換係数の値より前にコーディングされ得る。有効係数のロケーションをコーディングするプロセスは、有効性マップコーディングと呼ばれることがある。有効性マップ（ＳＭ：significance map）は、有効係数のロケーションを示す２進値の２次元アレイを含む。

[0034]たとえば、ビデオデータのブロックについてのＳＭは、１および０の２次元アレイを含み得、１は、ブロック内の有効変換係数の位置を示し、０は、ブロック内の非有効（０値）変換係数の位置を示す。１および０は「有効係数フラグ」と呼ばれる。さらに、いくつかの例では、ＳＭは１および０の別の２Ｄアレイを含み得、１は、ブロックに関連する走査順序に従うブロック内の最後有効係数の位置を示し、０は、ブロック内のすべての他の係数の位置を示す。この場合、１は、「最後有効係数フラグ」と呼ばれる。他の例では、最後有効係数フラグは使用されないことがある。むしろ、ブロック中の最後有効係数は、ＳＭの残りをコーディングする前に最初にコーディングされ得る。

[0035]２値化された変換係数の残りのビン（ならびにコンテキストコーディングされている任意の他のシンタックス要素）が、次いで、１つまたは複数の追加のコーディングパスでコーディングされ得る。たとえば、第１のパス中に、ビデオコーダがＳＭをエントロピーコーディングし得る。第２のパス中に、ビデオコーダは、変換係数レベルの第１のビンをエントロピーコーディングし得る。いくつかの例では、第１のビンは、係数レベルが１よりも大きいかどうかを示し得、第２のビンは、係数レベルが２よりも大きいかどうかを示し得る。第３のビンは、たとえば、レベル−３の値をコーディングする２よりも大きい係数のレベルの剰余値を示すために使用され得る。別のビンは、いくつかの例では、係数レベルの符号を示し得る。

[0036]ビデオコーダは、ブロックの変換係数に関連する情報のすべてがコーディングされるまで、コーディングパスを実行し続け得る。いくつかの例では、ビデオコーダは、コンテキスト適応型コーディングと非コンテキスト適応型コーディングとの組合せを使用してビデオデータのブロックのビンをコーディングし得る。たとえば、１つまたは複数のパスについて、ビデオコーダは、標準コンテキスト適応型算術コーディングプロセスをバイパスまたは省略するためにバイパスモードを使用し得る。そのような場合、バイパスコーディングされたビンをコーディングするために固定の等確率モデルが使用され得る。

[0037]いくつかの例では、効率を上げ、かつ／または実装を簡単にするために、変換係数のブロックは、コーディングのためにサブセットに分割され得る（このサブセットは複数のサブブロックという形態をとり得る）。たとえば、３２×３２または６４×６４のブロックなどの比較的大きいブロックをコーディングするときにソフトウェアまたはハードウェアビデオコーダが特定の走査（たとえば、ジグザグ、対角、水平、垂直など）を実装することは計算量的に非効率的であり得る。そのような例では、ビデオコーダは、所定のサイズの複数のより小さいサブブロック（たとえば、８×８のサブブロック）にブロックを分割し得る。ビデオコーダは、次いで、ブロック全体がコーディングされるまで順々に各サブセットを走査しコーディングし得る。

[0038]いずれの場合も、コンテキストを計算するために位置ベースのコンテキストサポート近傍を使用すると計算コストが比較的高くなり得る。上記で説明した５ポイントの位置ベースのサポートの例では、ビデオコーダは、位置（ｘ，ｙ）における各変換係数をコーディングするとき、位置（ｘ＋１，ｙ）、（ｘ，ｙ＋１）、（ｘ＋１，ｙ＋１）、（ｘ＋２，ｙ）および（ｘ，ｙ＋２）に位置する変換係数の有効性を判断しなければならない。さらに、ビデオコーダはまた、サポート中の変換係数の位置が、現在コーディングされている変換係数を含むブロックの内部に位置するのか、またはそれの外部に位置するのかを判断し得る。

[0039]位置ベースのサポートはまた、データアクセスに関連する複雑さを提示し得る。たとえば、上記で説明した５ポイントの位置ベースのサポートの例では、走査順序で連続する変換係数についてのコンテキストを計算するためのサポートは、第１の変換係数から次の変換係数までほとんどまたはまったく重複しないことを示し得る。すなわち、連続して走査され、コーディングされる２つの変換係数は、それらのそれぞれのサポート中で位置をほとんどまたはまったく共有しないことがある。したがって、ビデオコーダは、（たとえば、コンテキスト計算についてのデータを共有するのではなく）各コンテキストを計算するための最高５つの異なる変換係数にアクセスし得る。

[0040]説明のための一例では、変換係数のブロックが４×４のサブブロックに再分割されると仮定する。さらに、サブブロックがそれぞれ対角線方向の走査パターンを使用して走査されると仮定する。この例では、１つのサブブロック中で走査されている最終変換係数のサポートは、次のサブブロック中で走査されている第１の変換といかなるサポート位置も共有し得ない。したがって、ビデオコーダは、これらの位置についてのコンテキストを計算するために比較的大きいデータの量を取り出さなければならず、それは、コーディングプロセスを遅くし得る。

[0041]本開示の態様は、概して、変換係数走査順序に基づくコンテキスト導出近傍に関する。たとえば、上記で説明した、コンテキストを判断するために位置ベースのサポートを使用するのではなく、本開示の態様は、コーディング中に変換係数が走査される順序に基づくコンテキストを判断するためにサポートを使用することに関する。すなわち、本開示の態様によれば、サポートは、（ビデオエンコーダにおいて）変換係数の２次元アレイを変換係数の１次元アレイに直列化するために変換係数が走査されるか、または（ビデオデコーダにおいて）変換係数の１次元アレイから変換係数の２次元アレイを再構成するために逆走査される順序に基づいて判断される。

[0042]したがって、本開示の態様によれば、ビデオコーダ（たとえば、ビデオエンコーダまたはビデオデコーダ）は、走査順序で前の変換係数のセットに基づいて変換係数（たとえば、有効性、レベル、符号など）をコンテキストコーディングするためのコンテキストを導出するためのサポートを判断し得る。いくつかの例では、走査順序で前の変換係数のセットは、所定の数の走査順序で連続する変換係数（たとえば、３、４、５など）を含み得る。サポート中に含まれる変換係数のセットは、以下で説明するように、「スライディングウィンドウ」によって定義され得る。

[0043]説明のための一例では、ビデオデコーダは、走査順序で前の係数のセット（たとえば、ｎ＋ｉ〜ｎ＋ｊ、ただし、ｉはｊより前にコーディングされる）に基づいて第１の変換係数（ｎ）を復号するためのコンテキストを判断し得る。たとえば、ビデオデコーダは、走査順序で５つの前の変換係数のセット（ｎ＋１〜ｎ＋５）に基づいて第１の変換係数（ｎ）を復号するためのコンテキストを判断し得る。次に、ビデオデコーダは、所定の数の変換係数を含むウィンドウを走査順序で１つの位置だけスライドさせることによって第２の変換係数（ｎ−１）を復号するためのコンテキストを判断し得る。すなわち、本開示の態様によれば、スライディングウィンドウは、コンテキストを判断するために使用される変換係数を識別する。ウィンドウは、連続する変換係数がコーディングされるにつれて走査順序で「スライドする」かまたは移動する。

[0044]したがって、ビデオデコーダは、走査順序で５つの前の変換係数の新しいセット（ｎ〜ｎ＋４）に基づいて第２の変換係数（ｎ−１）を復号するためのコンテキストを判断し得る。５つの前の変換係数の新しいセットは、第１の変換係数（ｎ）を含み、第１のセットの最後の変換係数（ｎ＋５）を除去する。このようにして、コンテキストを判断するための変換係数のウィンドウが走査順序でスライドし続け、変換係数が走査される。上記の例はビデオデコーダに関して説明したが、ビデオエンコーダによって同じ技法が適用され得る。さらに、５つよりも多いまたは５つよりも少ない変換係数がウィンドウによって定義され得る。

[0045]いくつかの例では、ビデオコーダは、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、ビデオコーダは、ブロックまたはサブブロック中で第１の変換係数をコーディングするためのコンテキストを計算するときにサポートの新しいセットを用いて開始し得る。この例では、ビデオコーダは、走査順序に基づいて初期サポートを判断し得ない。むしろ、いくつかの例では、ビデオコーダは、ブロックまたはサブブロック中で第１の変換係数をコーディングするためのコンテキストを計算するための、上記で説明した位置ベースのサポートを実装し得る。次いで、ビデオコーダが、ブロックまたはサブブロック中で変換係数をコーディングし続けるにつれて、ビデオコーダは、コンテキストを計算するためにサポートのスライディングウィンドウに走査順序で変換係数をポピュレートし得る。

[0046]たとえば、ビデオコーダは、変換係数をコーディングしながら、サポートのスライディングウィンドウに一度に１つの変換係数をポピュレートし得る。したがって、ビデオコーダは、ブロックまたはサブブロックの１つまたは複数の変換係数のためのサポートを判断するために、初期サポートの変換係数と走査順序に基づく変換係数との混合を使用し得る。たとえば、ビデオコーダは、ブロックまたはサブブロックの第１の変換係数についてのコンテキストを判断するために初期の５ポイントのサポートを使用し得る。この例では、ビデオコーダは、初期サポートからの４つの変換係数と走査順序に基づく１つの変換係数とを使用して走査順序でブロックまたはサブブロックの第２の変換係数についてのコンテキストを判断し得る。同様に、ビデオコーダは、サポートのスライディングウィンドウに走査順序に基づいて変換係数が完全にポピュレートされるまで、初期サポートからの３つの変換係数と走査順序に基づく２つの変換係数とを使用して走査順序でブロックまたはサブブロックの第３の変換係数についてのコンテキストを判断し、以下同様に行い得る。

[0047]このようにして、本開示の技法はコンテキスト計算を簡略化し得る。たとえば、本開示の技法を実装すると、ビデオコーダは、変換係数についてのコンテキストを判断するために（変換係数のブロックまたはサブブロック中の）変換係数の相対ロケーションを判断する必要がない。さらに、本開示の技法は、コンテキストを判断するときにメモリからアクセスされるデータの量を低減させ得る。たとえば、ビデオコーダは、連続する係数についてのコンテキストを判断するときにデータの大部分を再利用し得る。すなわち、ビデオコーダは、説明したコンテキスト計算ウィンドウが１つの変換係数から次の変換係数にスライドするとき、１つの新しい変換係数に関連するデータのみを取り出す。さらに、ビデオコーダは、変換係数を走査するために使用されている走査の方向（たとえば、ジグザグ、対角、水平、垂直など）にかかわらず、コンテキストを判断するために同じ技法を適用し得る。

[0048]いくつかの事例では、コーディング効率を増加させるために並列処理が使用され得る。概して、並列処理は、概して、２つ以上の計算を同時に実行することを指す。ただし、いくつかの例では、並列処理は、２つのプロセスの厳密な時間的一致を含まないことがある。むしろ、並列処理は、そのようなプロセスが同時に実行されない重複または時間的進行を含み得る。並列処理は、並列ハードウェア処理コアによって実行されるか、または同じまたは異なる処理コア上で動作する並列ソフトウェアスレッドを用いて実行され得る。

[0049]いずれの場合も、変換係数コーディングに関して、２つ以上の変換係数についてのコンテキストを並行して計算するために並列処理が使用され得る。しかしながら、２つ以上の変換係数を並行して計算するために、サポート中の位置のすべてがコーディングのために利用可能でなければならない。たとえば、上記のように、有効性フラグをコーディングするためのコンテキストモデルは、サポート中の有効性フラグのすべてを合計することによって判断され得る。有効性フラグをコーディングするためのコンテキストモデルを判断するとき、サポート中の有効性フラグのすべてが合計のために利用可能であるようにするために、そのようなフラグは前にコーディング（判断）されていなければならない。

[0050]いくつかの事例では、特定のサポート中の１つまたは複数の有効性フラグは、コンテキストを判断するためにサポート中の他の有効性フラグに依存し得る。たとえば、第１の有効性フラグＡがそれのサポート中に隣接有効性フラグＢを含むと仮定する。したがって、有効性フラグＡのためのコンテキストモデルを判断するために、有効性フラグＢが利用可能でなければならない（コーディングされなければならない）。したがって、この例では、有効性フラグＡについてのコンテキストが有効性フラグＢに依存する（たとえば、有効性コンテキストがサポート内で依存的である）ので、有効性フラグＡおよびＢについてのコンテキストは並行してコーディングされ得ない。ビデオコーダは、有効性フラグＢがコーディングされるまで有効性フラグＡについてのコンテキストを計算するのを待たなければならず、それによって、並列コンテキスト計算が防げられ、コンテキストの並列処理に関連する効率利得が低減するかまたはなくなる。

[0051]上記で説明した並列コンテキスト計算プロセスは、コンテキスト判断プロセスに追加の複雑さをもたらし得る。たとえば、いくつかの事例では、ビデオコーダは、２つ以上の変換係数をコーディングするための２つ以上のコンテキストを並行して計算し得る（たとえば、２つのビン並列化、３つのビン並列化など）。そのような場合、コンテキストを計算するために位置ベースのサポートを使用すると、ビデオコーダは、上記のコンテキスト依存性を除去するためにサポートを変更し得る。そのような位置ベースのサポート変更は、複雑さを追加し得、コンテキスト計算プロセスを遅くし得る。

[0052]本開示の態様によれば、上記で説明したスライディングウィンドウ手法は、並列コンテキスト計算を簡略化し得る。たとえば、いくつかの事例では、走査順序で、コーディングされている変換係数とサポートの変換係数のセットとの間にギャップがもたらされ得る。すなわち、ビデオコーダは、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で１つまたは複数の変換係数をスキップし得る。コーディングされている変換係数とサポートの変換係数との間のギャップは、上記で説明したコンテキスト依存性を除去し得る。

[0053]説明のための一例では、ビデオデコーダは、走査順序で５つの前の変換係数のセット（ｎ+２〜ｎ＋６）に基づいて第１の変換係数（ｎ）を復号するためのコンテキストを判断し得る。ビデオデコーダはまた、走査順序で５つの前の変換係数のセット（ｎ+３〜ｎ＋７）に基づいて第２の変換係数（ｎ−１）を復号するためのコンテキストを判断し得る。第１の変換係数（ｎ）とサポート（ｎ＋２〜ｎ＋６）との間にギャップをもたらすと（たとえば、ｎ＋１をスキップすると）文脈依存性が除去され、したがって、ビデオデコーダは、第１の変換係数（ｎ）と第２の変換係数（ｎ＋１）とについてのコンテキストを並行して計算し得る。上記で説明したように、追加の変換係数がコーディングされるとき、サポートを定義するウィンドウは走査順序でスライドし得る。上記の例はビデオデコーダに関して説明したが、ビデオエンコーダによって同じ技法が適用され得る。さらに、５つよりも多いまたは５つよりも少ない変換係数がウィンドウによって定義され得る。

[0054]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、２つの変換係数のギャップにより３つのコンテキストを並行して計算することが可能になり得る。したがって、ビデオコーダは、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。

[0055]本開示の態様は、概して、変換係数についてのコンテキストを判断することに言及するが、変換係数が関連する有効性、レベル、符号などを含み得ることを理解されたい。したがって、本開示のいくつかの態様は、詳細には、変換係数に関連する有効性情報を含む有効性マップをコーディングするためのコンテキストを判断することに関係し得る。

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

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

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

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

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

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

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

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

[0064]本開示では、概して、ビデオエンコーダ２０が、ある情報をビデオデコーダ３０などの別のデバイスに「シグナリング」することに言及することがある。ただし、ビデオエンコーダ２０は、いくつかのシンタックス要素をビデオデータの様々な符号化部分に関連付けることによって情報をシグナリングし、それによって、コード化ビットストリーム内で情報をシグナリングし得ることを理解されたい。すなわち、ビデオエンコーダ２０は、いくつかのシンタックス要素をビデオデータの様々な符号化部分のヘッダに記憶することによってデータを「シグナリング」し得る。場合によっては、そのようなシンタックス要素は、ビデオデコーダ３０によって受信され、復号されるより前に、符号化され、記憶され（たとえば、コンピュータ可読媒体１６に記憶され）得る。したがって、「シグナリング」という用語は、通信がリアルタイムまたはほぼリアルタイムで行われるか、あるいは、符号化時にシンタックス要素を媒体に記憶し、次いで、この媒体に記憶された後の任意の時間にそのシンタックス要素が復号デバイスによって取り出され得るときなどに行われ得る、ある時間期間にわたって行われるかにかかわらず、概して、圧縮ビデオデータを復号するためのシンタックスまたは他のデータの通信を指し得る。

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

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

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

[0068]ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ １０、アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、ビデオ圧縮規格、またはそのような規格の拡張に従って動作し得る。ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、Ｊｏｉｎｔ Ｖｉｄｅｏ Ｔｅａｍ（ＪＶＴ）として知られる共同パートナーシップの成果として、ＩＳＯ／ＩＥＣ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）とともにＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）によって策定された。いくつかの態様では、本開示で説明する技法は、Ｈ．２６４規格に概して準拠するデバイスに適用され得る。Ｈ．２６４規格は、ＩＴＵ−Ｔ Ｓｔｕｄｙ Ｇｒｏｕｐによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４「Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｆｏｒ ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ」に記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ぶことがある。ビデオ圧縮規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。

[0069]ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。本開示の技法は、任意の特定のコーディング規格に限定されないが、本技法は、ＨＥＶＣ規格に関係し得る。以下でＨＥＶＣ ＷＤ９と呼ぶ、ＨＥＶＣの最新のワーキングドラフト（ＷＤ）、Ｂｒｏｓｓら、「Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ （ＨＥＶＣ） ｔｅｘｔ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｄｒａｆｔ ９」、は、２０１３年２月２１日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１１＿Ｓｈａｎｇｈａｉ／ｗｇ１１／ＪＣＴＶＣ−Ｋ１００３−ｖ１３．ｚｉｐから入手可能である。

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

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

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

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

[0074]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ：prediction unit）および変換ユニット（ＴＵ：transform unit）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルをもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。

[0075]ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が方形または非方形（たとえば、矩形）であり得る。

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

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

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

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

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

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

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

[0083]量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。

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

[0085]ビデオエンコーダ２０は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびピクチャグループ（ＧＯＰ：group of pictures）ベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送り得る。ＧＯＰシンタックスデータは、それぞれのＧＯＰ中のいくつかのフレームを記述し得、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化／予測モードを示し得る。

[0086]ビデオエンコーダ２０は、２値化値（たとえば、２値化された変換係数、シンボル、シンタックス要素など）に対してコンテキストベースのコーディング（たとえば、ＣＡＢＡＣ）を実行し得る。たとえば、各ビンに対して、ビデオエンコーダ２０は、ビデオデータのブロックに関連するシンボルをコーディングするためにコンテキスト上で動作する確率モデルまたは「コンテキストモデル」を選択し得る。確率モデルは、ビンが所与の２進値（たとえば、「０」または「１」）を有する可能性を示す。

[0087]ビデオエンコーダ２０は、ビンのコンテキストを判断することによって確率モデルを選択し得る。コンテキストが導出される位置はコンテキスト導出近傍と呼ばれることがある（「コンテキストサポート近傍」または単に「サポート」と呼ばれることもある）。

[0088]いくつかの例では、ビデオエンコーダ２０は、コンテキストモデルを定義するために位置ベースの５ポイントのサポート近傍を使用し得るが、より多いまたはより少ないサポート位置を用いる他のサイズのサポートが使用され得る。５ポイントのサポートは、現在コーディングされている有効性フラグに空間的に隣接する５つの変換係数位置を含み得る。サポートを使用することによって、ビデオエンコーダ２０は、確率モデルを、サポートのあらゆるポイントにおける有効性フラグの和として定義し得る。

[0089]ただし、コンテキストを計算するために位置ベースのコンテキストサポート近傍を使用すると計算コストが比較的高くなり得る。たとえば、上記で説明した５ポイントの位置ベースのサポートを使用するために、ビデオエンコーダ２０は、５つの異なるロケーションにおいて変換係数の有効性を判断しなければならない。ビデオエンコーダ２０はまた、サポート中の変換係数の位置が、現在コーディングされている変換係数を含むブロックの内部に位置するのか、またはそれの外部に位置するのかを判断し得る。さらに、ビデオエンコーダ２０は、連続するコンテキストを計算するときにサポートデータを再使用することができないことがある。むしろ、ビデオエンコーダ２０は、計算されているコンテキストごとに最大５つの変換係数に関連するデータにアクセスする必要があり得る。

[0090]本開示の態様は、概して、変換係数走査順序に基づくコンテキスト導出近傍に関する。たとえば、コンテキストを判断するために位置ベースのサポートを使用するのではなく、本開示の態様によれば、ビデオエンコーダ２０は、係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することによってビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数を符号化し得る。ビデオエンコーダ２０はまた、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断し得る。ビデオエンコーダ２０は、次いで、判断されたコンテキストに基づいて変換係数のうちの１つを符号化し得る。

[0091]係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義するために、ビデオエンコーダ２０は、走査順序で前の変換係数のセットを識別し得る。いくつかの例では、走査順序で前の変換係数のセットは、所定の数の走査順序で連続する変換係数（たとえば、３、４、５など）を含み得る。上記のように、サポートを定義するためにスライディングウィンドウが使用され得る。たとえば、コーディングされている連続する変換係数ごとに、ビデオエンコーダ２０は、ウィンドウに走査順序で新しい変換係数を追加し、前のサポートの相対終端から変換係数を除去し得る。このようにして、コンテキストを判断するための変換係数のウィンドウが走査順序でスライドし続け、変換係数が走査される。

[0092]いくつかの例では、ビデオエンコーダ２０は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、ビデオエンコーダ２０は、新しいサポートを用いてブロックまたはサブブロックごとに第１の変換係数についてのコンテキストを計算し始め得る。いくつかの例では、ビデオエンコーダ２０は、ブロックまたはサブブロック中の第１の変換係数をコーディングするためのコンテキストを計算するために、走査順序に基づいていないサポートを使用し得る。ビデオエンコーダ２０は、次いで、サポートのスライディングウィンドウに走査順序で変換係数をポピュレートすることによって、走査順序に基づくサポートに切り替わり得る。

[0093]このようにして、本開示の技法はコンテキスト計算を簡略化し得る。たとえば、ビデオエンコーダ２０は、変換係数についてのコンテキストを判断するために（変換係数のブロックまたはサブブロック中の）変換係数の相対ロケーションを判断する必要がない。さらに、ビデオエンコーダ２０は、コンテキストを判断するときにメモリからアクセスされるデータの量を低減させ得る。たとえば、ビデオエンコーダ２０は、説明したコンテキスト計算ウィンドウが１つの変換係数から次の変換係数にスライドするとき、１つの新しい変換係数に関連するデータのみを取り出す。さらに、ビデオエンコーダ２０は、変換係数を走査するために使用されている走査の方向（たとえば、ジグザグ、対角、水平、垂直など）にかかわらず、コンテキストを判断するために同じ技法を適用し得る。

[0094]いくつかの事例では、ビデオエンコーダ２０はまた、（２つ以上の変換係数についての）２つ以上のコンテキストを並行して判断するために本開示の技法を実装し得る。たとえば、上記のように、２つ以上の変換係数を並行して計算するために、サポート中の位置のすべてがコーディングのために利用可能でなければならない。しかしながら、いくつかの事例では、特定のサポート中の１つまたは複数の有効性フラグは、コンテキストを判断するためにサポート中の他の有効性フラグに依存し得る。

[0095]本開示の態様によれば、ビデオエンコーダ２０は、並列コンテキスト計算を実行するために上記で説明したスライディングウィンドウ手法を実装し得る。たとえば、ビデオエンコーダ２０は、コーディングされている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、ビデオエンコーダ２０は、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で１つまたは複数の変換係数をスキップし得る。ビデオエンコーダ２０は、上記で説明したコンテキスト依存性を除去するために変換係数間にギャップをもたらし得る。

[0096]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、ビデオエンコーダ２０は、２つのコンテキスト（たとえば、コーディングされている変換係数についてのコンテキストおよび走査順序で次の（スキップされる）変換係数）の並行した計算をサポートするために、コーディングされている変換係数とスライディングウィンドウとの間に１つの変換係数のギャップを挿入し得る。別の例では、ビデオエンコーダ２０は、３つのコンテキスト（たとえば、コーディングされている変換係数についてのコンテキストおよび走査順序で次の２つの（スキップされる）変換係数）の並行した計算をサポートするために、コーディングされている変換係数とスライディングウィンドウとの間に２つの変換係数のギャップを挿入し得る。ビデオエンコーダ２０は、より大きい並列化に適応するためにギャップを増加させ得る。このようにして、ビデオエンコーダ２０は、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。

[0097]ビデオデコーダ３０は、コード化されたビデオデータを受信すると、ビデオエンコーダ２０に関して説明した符号化パスとは概して逆の復号パスを実行し得る。概して逆であるが、ビデオデコーダ３０は、場合によっては、ビデオエンコーダ２０によって実行される技法と同様の技法を実行し得る。ビデオデコーダ３０はまた、ビデオエンコーダ２０に関して説明したデータを含む受信ビットストリーム中に含まれているシンタックス要素または他のデータに依拠し得る。

[0098]本開示の態様によれば、たとえば、ビデオデコーダ３０は、ビデオエンコーダ２０に関して上記で説明したように、係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することによって、ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数を復号し得る。ビデオデコーダ３０はまた、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断し得る。ビデオデコーダ３０は、次いで、判断されたコンテキストに基づいて変換係数のうちの１つを復号し得る。

[0099]本開示の態様は、概して、変換係数についてのコンテキストを判断することに言及するが、変換係数が関連する有効性、レベル、符号などを含み得ることを理解されたい。たとえば、０よりも大きいコーディングレベル、１よりも大きいレベル、２よりも大きいレベルなど、有効性およびレベルをコーディングするために複数の走査パスが使用され得る。一例では、以下の値をコーディングするために５つの異なるシンタックス要素が使用され得る。

０よりも大きいレベルの絶対値、
１よりも大きいレベルの絶対値、
２よりも大きいレベルの絶対値、
３よりも大きいレベルの絶対値、および
符号。

[0100]したがって、本開示のいくつかの態様は、詳細には、変換係数に関連する有効性情報を含む有効性マップをコーディングするためのコンテキストを判断することに関係し得る。もちろん、他のタイプのシンタックス要素および異なる数の走査パスも使用され得る。

[0101]図２は、コンテキストを導出するために本開示の技法を使用し得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０について、例示のためにＨＥＶＣコーディングのコンテキストにおいて説明するが、変換係数のコンテキスト適応型コーディングを必要とし得る他のコーディング規格または方法に関して限定するものではない。

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

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

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

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

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

[0107]動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または他のコード化ユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。

[0108]いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。

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

[0110]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。現在ビデオブロックのＰＵについての動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいて指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明するように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。

[0111]概して、動き推定ユニット４２はルーマ成分に対する動き推定を実行し、動き補償ユニット４４はクロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。

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

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

[0114]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。

[0115]変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。

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

[0117]量子化の後に、エントロピー符号化ユニット５６は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。

[0118]エントロピー符号化ユニット５６は、変換係数走査順序に基づくコンテキスト導出近傍を判断するために本開示の技法を実行し得る。たとえば、２値化された変換係数（たとえば、有効性、符号、レベルなど）のビンをエントロピー符号化するためのコンテキストを判断するために位置ベースのサポートを使用するのではなく、エントロピー符号化ユニット５６は、変換係数が符号化中に（たとえば、上記で説明した変換処理ユニット５２または量子化ユニット５４によって）走査される順序に基づくコンテキストを判断するためにサポートを使用し得る。

[0119]このようにして、エントロピー符号化ユニット５６は、コンテキスト計算を実行するためにサポートのスライディングウィンドウを使用し得る。たとえば、エントロピー符号化ユニット５６が走査順序で連続する変換係数を符号化するとき、エントロピー符号化ユニット５６は、コンテキストを判断するために使用されるサポートを走査順序でスライドする。すなわち、符号化されている連続する変換係数ごとに、エントロピー符号化ユニット５６は、サポートに変換係数を走査順序で追加する。さらに、エントロピー符号化ユニット５６は、サポートから（走査順序に対して）最後の変換係数を除去する。したがって、変換係数が走査順序で走査されるとき、サポートを定義するウィンドウが走査順序に沿ってスライドする。

[0120]エントロピー符号化ユニット５６は、走査順序で所定の数（たとえば、３、４、５など）の変換係数を含むコンテキストを計算するためのサポートを判断し得る。いくつかの例では、エントロピー符号化ユニット５６は、走査順序で連続する変換係数を有するサポートを判断し得る。

[0121]エントロピー符号化ユニット５６は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、エントロピー符号化ユニット５６は、いくつかの例では、走査順序に基づかないことがある新しいサポートを用いてブロックまたはサブブロックの１つまたは複数の変換係数についてのコンテキストを計算し始め得る。すなわち、いくつかの例では、エントロピー符号化ユニット５６は、ブロック中の１つまたは複数の変換係数についてのコンテキストを計算するために位置ベースのサポートを使用し得、ブロックまたはサブブロック中の１つまたは複数の他の変換係数についてのコンテキストを計算するために走査順序に基づいてサポートを使用し得る。そのような例では、エントロピー符号化ユニット５６は、ブロックまたはサブブロックの変換係数をコーディングしながら、サポートに変換係数を追加することによってサポートのスライディングウィンドウに変換係数をポピュレートし得る。

[0122]いくつかの例では、エントロピー符号化ユニット５６は、並列コンテキスト計算を実行するために上記で説明したサポートのスライディングウィンドウを実装し得る。たとえば、エントロピー符号化ユニット５６は、潜在的なコンテキスト計算依存性を除去するために、現在符号化されている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、エントロピー符号化ユニット５６は、現在符号化されている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で１つまたは複数の変換係数をスキップし得る。したがって、エントロピー符号化ユニット５６は、現在符号化されている変換係数についてのコンテキストならびにスキップされた変換係数についてのコンテキストを並行して計算し得る。エントロピー符号化ユニット５６は、並行して計算されているコンテキストの数に基づいて、符号化されている変換係数とサポートとの間のギャップを調整し得る（たとえば、より大きい並列化に適応するためにギャップを増加する）。

[0123]サポートを判断した後に、エントロピー符号化ユニット５６は、サポートを使用して変換係数のビンをコーディングするためのコンテキストを計算し得る。コンテキストを計算した後に、エントロピー符号化ユニット５６は、計算されたコンテキストに基づいてビンをコーディングするために、コンテキスト適応型バイナリ算術コーディングを適用し得る。すなわち、エントロピー符号化ユニット５６は、判断されたコンテキストに基づいてコンテキストモデルを判断し得、ビンを符号化するためにコンテキストモデルを適用し得る。エントロピー符号化ユニット５６によるエントロピーコーディングの後に、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。

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

[0125]このようにして、図２のビデオエンコーダ２０は、係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することと、判断されたコンテキストに基づいてそれらの変換係数のうちの１つをコーディングすることとを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするためのプロセスを実行するように構成されたビデオエンコーダの一例を表す。

[0126]図３は、コンテキストを導出するための技法を実装し得るビデオデコーダ３０の一例を示すブロック図である。図２に関して上述したように、ビデオデコーダ３０は、説明のためにＨＥＶＣコーディングのコンテキストで説明したが、本開示の技法は、このようにして限定されず、変換係数のコンテキスト適応型コーディングを必要とし得る他の現在のまたは将来のコーディング規格または方法を用いて実装され得る。

[0127]図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照ピクチャメモリ８２と、加算器８０とを含む。復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。エントロピー復号ユニット７０は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

[0128]たとえば、背景として、ビデオデコーダ３０は、ネットワークを介した、いわゆる「ネットワークアブストラクションレイヤユニット（network abstraction layer unit）」またはＮＡＬユニットへの送信のためにカプセル化された圧縮ビデオデータを受信し得る。各ＮＡＬユニットは、ＮＡＬユニットに記憶されるデータのタイプを識別するヘッダを含み得る。一般にＮＡＬユニットに記憶されるデータの２つのタイプがある。ＮＡＬユニットに記憶されるデータの第１のタイプはビデオコーディングレイヤ（ＶＣＬ：video coding layer）データであり、これは圧縮ビデオデータを含む。ＮＡＬユニットに記憶されるデータの第２のタイプは非ＶＣＬデータと呼ばれ、これは、多数のＮＡＬユニットに共通のヘッダデータを定義するパラメータセットなどの追加情報、および補足エンハンスメント情報（ＳＥＩ：supplemental enhancement information）を含む。たとえば、パラメータセットは、（たとえば、シーケンスパラメータセット（ＳＰＳ：sequence parameter set）中の）シーケンスレベルヘッダ情報と、（たとえば、ピクチャパラメータセット（ＰＰＳ）中の）まれに変化するピクチャレベルヘッダ情報とを含み得る。パラメータセット中に含まれている、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、それによりコーディング効率が改善される。さらに、パラメータセットの使用はヘッダ情報の帯域外送信を可能にし、それにより誤り耐性のための冗長送信の必要が回避される。

[0129]いくつかの例では、ビデオデコーダ３０は、（新生のＨＥＶＣ規格またはＨ．２６４／ＡＶＣなどの）ビデオコーディング規格の所定のプロファイルおよび／またはレベルに準拠し得る。たとえば、ビデオコーディング規格のコンテキストでは、プロファイルは、アルゴリズム、機能、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびマクロブロック（ＭＢ）処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはｐｒｏｆｉｌｅ＿ｉｄｃ（プロファイルインジケータ）値でシグナリングされ得、レベルはｌｅｖｅｌ＿ｉｄｃ（レベルインジケータ）値でシグナリングされ得る。

[0130]いずれの場合も、エントロピー復号ユニット７０は、受信された量子化変換係数ならびに他のシンタックス要素および／またはシンボルをエントロピー復号し得る。たとえば、エントロピー復号ユニット７０は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。

[0131]本開示の態様によれば、エントロピー復号ユニット７０は、変換係数走査順序に基づくコンテキスト導出近傍を判断するために本開示の技法を実行し得る。たとえば、２値化された変換係数（たとえば、有効性、符号、レベルなど）のビンをエントロピー復号するためのコンテキストを判断するために位置ベースのサポートを使用するのではなく、エントロピー復号ユニット７０は、変換係数が復号中に走査（たとえば、逆走査）される順序に基づくコンテキストを判断するためにサポートを使用し得る。

[0132]このようにして、エントロピー復号ユニット７０は、コンテキスト計算を実行するためにサポートのスライディングウィンドウを使用し得る。たとえば、エントロピー復号ユニット７０が走査順序で連続する変換係数を復号するとき、エントロピー復号ユニット７０は、コンテキストを判断するために使用されるサポートを走査順序でスライドする。すなわち、復号されている連続する変換係数ごとに、エントロピー復号ユニット７０は、サポートに変換係数を走査順序で追加する。さらに、エントロピー復号ユニット７０は、サポートから（走査順序に対して）最後の変換係数を除去する。したがって、変換係数が走査順序で走査されるとき、サポートを定義するウィンドウが走査順序に沿ってスライドする。

[0133]エントロピー復号ユニット７０は、走査順序で所定の数（たとえば、３、４、５など）の変換係数を含むコンテキストを計算するためのサポートを判断し得る。いくつかの例では、エントロピー復号ユニット７０は、走査順序で連続する変換係数を有するサポートを判断し得る。

[0134]エントロピー復号ユニット７０は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、エントロピー復号ユニット７０は、いくつかの例では、走査順序に基づかないことがある新しいサポートを用いてブロックまたはサブブロックの１つまたは複数の変換係数についてのコンテキストを計算し始め得る。すなわち、いくつかの例では、エントロピー復号ユニット７０は、ブロック中の１つまたは複数の変換係数についてのコンテキストを計算するために位置ベースのサポートを使用し得、ブロックまたはサブブロック中の１つまたは複数の他の変換係数についてのコンテキストを計算するために走査順序に基づいてサポートを使用し得る。そのような例では、エントロピー復号ユニット７０は、ブロックまたはサブブロックの変換係数をコーディングしながら、サポートに変換係数を追加することによってサポートのスライディングウィンドウに変換係数をポピュレートし得る。

[0135]いくつかの例では、エントロピー復号ユニット７０は、並列コンテキスト計算を実行するために上記で説明したスライディングウィンドウ手法を実装し得る。たとえば、エントロピー復号ユニット７０は、潜在的なコンテキスト計算依存性を除去するために、現在復号されている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、エントロピー復号ユニット７０は、現在復号されている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で１つまたは複数の変換係数をスキップし得る。したがって、エントロピー復号ユニット７０は、現在復号されている変換係数についてのコンテキストならびにスキップされた変換係数についてのコンテキストを並行して計算し得る。エントロピー復号ユニット７０は、並行して計算されているコンテキストの数に基づいて、復号されている変換係数とサポートとの間のギャップを調整し得る（たとえば、より大きい並列化に適応するためにギャップを増加する）。

[0136]サポートを判断した後に、エントロピー復号ユニット７０は、サポートを使用して変換係数のビンをコーディングするためのコンテキストを計算し得る。コンテキストを計算した後に、エントロピー復号ユニット７０は、計算されたコンテキストに基づいてビンを復号するために、コンテキスト適応型バイナリ算術コーディングを適用し得る。すなわち、エントロピー復号ユニット７０は、判断されたコンテキストに基づいてコンテキストモデルを判断し得、ビンを復号するためにコンテキストモデルを適用し得る。

[0137]ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。

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

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

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

[0141]逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット７０によって復号された量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を判断し、同様に、適用されるべき逆量子化の程度を判断するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ３０によって計算される量子化パラメータＱＰ_Yの使用を含み得る。

[0142]逆変換ユニット７８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。本開示の態様によれば、逆変換ユニット７８は、対応する非対称ＳＤＩＰパーティションと同じサイズ、したがって、互いに異なるサイズを有するＴＵを使用し得る。他の例では、ＴＵは、それぞれ互いに等しいサイズを有し、したがって、（ＴＵのうちの１つが対応する非対称ＳＤＩＰパーティションと同じサイズであり得るが）非対称ＳＤＩＰパーティションのサイズとは潜在的に異なり得る。いくつかの例では、ＴＵは、ＴＵのうちの１つまたは複数が現在のブロックの最小非対称ＳＤＩＰパーティションより小さいことを示し得る残差４分木（ＲＱＴ）を使用して表され得る。

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

[0144]このようにして、図３のビデオデコーダ３０は、係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの１つについてのコンテキストを判断することと、判断されたコンテキストに基づいてそれらの変換係数のうちの１つをコーディングすることとを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするためのプロセスを実行するように構成されたビデオデコーダの一例を表す。

[0145]図４Ａおよび図４Ｂに、概して、ビデオデータのブロックに関連する変換係数のブロックをサブブロックの形態のサブセットに分割することを示す。上記のように、いくつかの例では、（ビデオエンコーダ２０またはビデオデコーダ３０などの）ビデオコーダは、比較的大きいブロックを処理することに関連するハードウェアおよび／またはソフトウェア要件を低減させるために、図４Ａおよび図４Ｂに示すサブブロック構造を実装し得る。

[0146]図４Ａに関して、ビデオコーダは、ブロック１２０をコーディングしながら、ブロック１２０をサブブロック１２２Ａ、１２２Ｂ、１２２Ｃ、および１２２Ｄ（総称してサブブロック１２２）に分割し得る。図４Ａに示す例では、第１のサブブロック１２２Ａは、ブロック１２０の左上隅に位置する４×４ブロックの変換係数を含み、第２のサブブロック１２２Ｂは、ブロック１２０の左下隅に位置する４×４ブロックの変換係数を含み、第３のサブブロック１２２Ｃは、ブロック１２０の右上隅に位置する４×４ブロックの変換係数を含み、第４のサブブロック１２２Ｄは、ブロック１２０の右下隅に位置する４×４ブロックの変換係数を含む。

[0147]図４Ａに関して説明したのと同様の方法で、ビデオデコーダは、ブロック１２４をコーディングしながら、図４Ｂのブロック１２４をサブブロック１２６Ａ、１２６Ｂ、１２６Ｃ、および１２６Ｄに分割し得る。図４Ｂに示す例では、第１のサブブロック１２６Ａは、ブロック１２４の右下隅に位置する４×４ブロックの変換係数を含み、第２のサブブロック１２６Ｂは、ブロック１２４の右上隅に位置する４×４ブロックの変換係数を含み、第３のサブブロック１２６Ｃは、ブロック１２４の左下隅に位置する４×４ブロックの変換係数を含み、第４のサブブロック１２６Ｄは、ブロック１２４の左上隅に位置する４×４ブロックの変換係数を含む。

[0148]ビデオコーダは、サブブロック１２２および１２６を連続的にコーディングし得る。すなわち、図４Ａに関して、ビデオコーダは、別のサブブロックをコーディングする前に、１つのサブブロックのための変換係数（たとえば、有効性、符号およびレベル）に関連するすべての情報をコーディングし得る。この例では、ビデオコーダは、サブブロック１２２Ｂをコーディングする前にサブブロック１２２Ａに関連するすべてのビンをコーディングし得る。ビデオコーダは、次いで、サブブロック１２２Ｃおよび１２２Ｄをコーディングし得る。同様に、図４Ｂに関して、ビデオコーダは、サブブロック１２６Ｂと、サブブロック１２６Ｃと、サブブロック１２６Ｄとをコーディングする前にサブブロック１２６Ａに関連するすべてのビンをコーディングし得る。

[0149]他の例では、ビデオコーダは、別のビンをコーディングする前に、ブロック１２０および１２４全体についてのデータの各ビンをコーディングし得る。たとえば、図４Ａに関して、ビデオコーダは、サブブロック１２２の各々のための有効性マップをコーディングし得る。ビデオコーダは、次いで、サブブロック１２２の各々のための変換係数レベルの各ビンをコーディングし、以下同様に行い得る。同様に、図４Ｂに関して、ビデオコーダは、サブブロック１２６の各々のための有効性マップをコーディングし、その後、サブブロック１２６の各々のための変換係数レベルをコーディングし、以下同様に行い得る。

[0150]いくつかの例では、ビデオコーダは、変換係数を走査するために統一された走査を使用し得る。たとえば、図４Ａに関して、ビデオコーダは、同じ対角走査を使用して変換係数の有効性マップと係数レベルとをコーディングし得る。他の例では、ビデオコーダは、異なる方向を有する走査を使用して変換係数（たとえば、有効性、符号、レベルなど）の異なるビンをコーディングし得る。たとえば、ビデオコーダは、順方向の対角、垂直、水平、またはジグザグ走査を使用することによって、各方形（または矩形）８×８ブロックおよびそれ以上の変換係数レベルマップの絶対値を４×４サブブロックの順序セット（たとえば、ベクトル）上にマッピングし得る。ビデオコーダは、次いで、順方向走査と反対の方向を有する逆方向の対角、垂直、水平、またはジグザグ走査を使用して各４×４サブブロック内の変換係数レベルをコーディングし得る。図４Ｂに示す逆方向（または逆）走査を容易にするために、ビデオコーダは、最初に、ブロック１２４の最後有効係数を識別し得る。最後有効係数を識別した後に、ビデオコーダは、図４Ｂに示す走査を適用し得る。

[0151]したがって、４×４ブロックごとに、ビデオコーダは、ｃｏｄｅｄ＿ｓｕｂ＿ｂｌｏｃｋ＿ｆｌａｇをコーディングし得、サブブロック中に少なくとも１つの非ゼロ係数がある場合、このフラグは１に設定され、それ以外の場合、フラグは０に等しくなる。ｃｏｄｅｄ＿ｓｕｂ＿ｂｌｏｃｋ＿ｆｌａｇが非ゼロである場合、ビデオコーダは、各４×４サブブロックを走査し、係数の有効性ならびに変換係数レベルを示す係数ごとにｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｆｌａｇをコーディングし得る。明示的シグナリングの代わりに、隣接する４×４サブブロックフラグを使用してまたは４×４ブロックが最後の係数またはＤＣを含んでいる場合、ｃｏｄｅｄ＿ｓｕｂ＿ｂｌｏｃｋ＿ｆｌａｇが暗黙的に導出され得る。

[0152]本開示の態様によれば、（ビデオエンコーダ２０またはビデオデコーダ３０などの）ビデオコーダは、変換係数走査順序に基づくコンテキスト導出近傍を使用して、サブブロック１２２および１２６の変換係数をコンテキスト適応的にコーディングし得る。たとえば、ビデオコーダは、走査順序で前にコーディングされた変換係数のスライディングウィンドウを含むコンテキストを計算するためにサポートを使用し得る。ビデオコーダは、コーディングされているサブブロック１２２および１２６中の特定の変換係数のロケーションにかかわらず、同様の方法でサポートを判断し得る。

[0153]たとえば、図４Ａに関して、ビデオコーダは、そのうちのいくつかがサブブロック１２２Ａに位置し得る前の５つの変換係数を走査順序で含むサポートを使用して、サブブロック１２２Ｂの変換係数をコンテキスト適応的にコーディングするためのコンテキストを計算し得る。同様に、図４Ｂに関して、ビデオコーダは、そのうちのいくつかがサブブロック１２６Ｂに位置し得る前の５つの変換係数を走査順序で含むサポートを使用して、サブブロック１２６Ｃの変換係数をコンテキスト適応的にコーディングするためのコンテキストを計算し得る。

[0154]本開示の技法は、コンテキストコーディングに関連するデータアクセス要件を低減させ得る。たとえば、コンテキスト導出近傍を判断するためにスライディングウィンドウを使用すると、ビデオコーダは、変換係数についてのコンテキストを判断するためにサブブロック１２２または１２６中の変換係数の相対ロケーションを判断する必要がない。さらに、ビデオコーダは、説明したコンテキスト計算ウィンドウが１つの変換係数から次の変換係数にスライドするとき、１つの新しい変換係数に関連するデータのみを取り出す。

[0155]上記のように、ビデオコーダは、変換係数を走査するために使用されている走査の方向（たとえば、ジグザグ、対角、水平、垂直など）にかかわらず、サポートのスライディングウィンドウを使用してコンテキストを判断するために同じ技法を適用し得る。したがって、図４Ａおよび図４Ｂに示す例では、概して、対角走査パターンを示すが、本技法はまた、ジグザグパターン、適応型走査順序、水平パターン、垂直パターンなどを含む様々な他の走査パターンに適用可能である。

[0156]さらに、図４Ａおよび図４Ｂに示す例では、４×４サブブロックをもつ８×８ブロックの変換係数を示すが、本開示の技法は、他のサイズのブロック、ならびに他のサイズのサブブロックに適用され得ることを理解されたい。たとえば、上記で説明したコンテキスト導出のためのスライディングウィンドウはまた、水平方向の走査または垂直方向の走査のためにそれぞれ使用され得る２×８および／または８×２の矩形サブブロックのために使用され得る。そのような例では、初期サポートは、位置ベースのサポートであるか、または走査順序ベースのサポートであり得る。

[0157]ビデオコーダがフレーム（またはスライス）のすべてのＴＵに同じサブブロックサイズを使用する場合、そのサブブロックサイズを用いて得られる均一性によって、ハードウェアの実装形態において利益が得られ得る。しかしながら、均一なサブブロックサイズは、本開示の技法を実行するために必須ではない。

[0158]図５に、概して、コンテキストを計算するためのコンテキスト導出近傍を示す。たとえば、図５に、概して、コンテキスト導出近傍１３２Ａ、１３２Ｂ、１３２Ｃ、１３２Ｄ、および１３２Ｅ（総称して、サポート１３２）から導出されたコンテキストを使用して現在のまたは「ターゲット」の変換係数１３０をコーディングすることを示す。一例では、式（１）に関して上述したように、（ビデオエンコーダ２０またはビデオデコーダ３０などの）ビデオコーダは、サポート１３２のあらゆる位置における有効性フラグの和に基づいてコンテキストＣｔｘを判断し得、ただし、対応する変換係数が非ゼロである場合、有効性フラグは「１」である。図５に、第２のコンテキスト導出近傍１３６Ａ、１３６Ｂ、１３６Ｃ、１３６Ｄ、および１３６Ｅ（総称して、サポート１３６）を有する第２の変換係数１３４をも示す。

[0159]コンテキストを計算するためにサポート１３２を使用するために、ビデオコーダは、位置１３２Ａ、１３２Ｂ、１３２Ｃ、１３２Ｄ、および１３２Ｅにおける変換係数の各々に関連する値を判断し得る。係数ごとに５つの異なるロケーションに関連する値を判断することは比較的計算集約的であり得る。さらに、ビデオコーダは、位置１３２Ａ、１３２Ｂ、１３２Ｃ、１３２Ｄ、および１３２Ｅにおける変換係数が変換係数１３０と同じブロック内に位置するかどうかを識別し得る。そのブロックの外部の位置に関連する値は、より長いデータアクセス時間を必要とし得るか、または他の値に置換され得る。

[0160]さらに、第２の変換係数１３４がターゲット変換係数１３０に走査順序で続くが、サポート１３２および１３６は重複しない。したがって、サポート１３２および１３６を使用してコンテキストを計算するデータアクセス要件は比較的高くなり得る。たとえば、ターゲット変換係数１３０の直後に第２のターゲット変換係数１３４が走査順序で続く。ただし、サポート１３２は、サポート１３６とは完全に異なる変換係数のセットを含む。したがって、ビデオコーダは、２つの連続する変換係数をコーディングするためのコンテキストを計算するために、１０個の変換係数に関連するデータを取り出さなければならない。

[0161]本開示の態様によれば、ビデオコーダは、（変換係数１３０および１３４などの）変換係数をコーディングするためのコンテキストを判断するために走査順序ベースのサポートを使用し得る。したがって、図７Ａおよび図７Ｂに関してより詳細に説明するように、ビデオコーダは、同じ変換係数のうちの１つまたは複数を有するサポートを使用して変換係数１３０および１３４についてのコンテキストを判断し得る。したがって、本技法は、位置ベースのサポート１３２および１３６に関して上記で説明した計算およびデータアクセス費用を低減させ得る。

[0162]図６に、概して、２つ以上のコンテキストを並行して計算するためのロケーションベースのコンテキスト導出近傍を示す。図６に示した例では、現在のまたは「ターゲット」の変換係数１４０は、サポート１４２Ａ、１４２Ｂ、１４２Ｃ、および１４２Ｄ（総称して、サポート１４２）から導出されたコンテキストを使用してコーディングされ得る。さらに、コンテキスト依存性を解決するために、穴１４４がサポートにもたらされる。

[0163]たとえば、（図５に示すサポート１３２など）穴１４４を含むサポートは、コンテキストを計算するときにサポート中のすべてのデータが利用可能でなければならない（たとえば、すでにコーディングされていなければならない）ので、ブロックのいくつかのロケーションにおいて２つ以上の有効性フラグについてのコンテキストを並行して計算するビデオコーダ（ビデオエンコーダ２０またはビデオデコーダ３０など）の能力を妨げ得る。すなわち、特定の位置のための有効性コンテキストを計算するために、サポート内のすべての位置の有効性フラグをパースすることが必要であり得る。有効性フラグは走査順序で互いに隣接して配置され得るので、２つの係数の有効性コンテキストを並行して計算するという要件がある場合、そのような解析は遅延をもたらし得る。

[0164]説明のための一例では、ビデオコーダは、走査順序で前の位置における変換係数、すなわち、穴１４４の位置における変換係数を用いて、ターゲットの変換係数１４０をコーディングするためのコンテキストを並行して計算しようと試み得る。ただし、この例では、ターゲットの変換係数が穴１４４における変換係数の値に依存することになるので、ビデオコーダは、ターゲットの変換係数１４０についてのコンテキストを判断する前にコーディングを完了するために、穴１４４の位置における変換係数を待たなければならない。すなわち、穴１４４における変換係数の値は、値が、たとえば、式（１）に示すコンテキストモデル合計において使用されることができるようになる前に知られていなければならない（コーディングされていなければならない）。このコンテキスト依存性に関連する遅延は、コンテキストを効率的に並行して計算するビデオコーダの能力を低減させる。

[0165]したがって、位置ベースのサポートを使用する（ビデオエンコーダ２０またはビデオデコーダ３０などの）ビデオコーダは、サポート１４２からの位置を除去するためにサポート１４２に穴１４４をもたらし得る。この例では、穴１４４に関連する変換係数は、スキップされ、コンテキスト計算では考慮に入れられず（すなわち、０であると仮定され）、それによって、コンテキスト依存性を除去し得る。サポートにいわゆる穴をもたらす技法は、２０１３年１月１０日に出願の米国特許出願第１３／７３８，５６５号に記載されている。

[0166]しかしながら、並列コンテキスト計算で位置ベースのサポートに穴をもたらすことは、コンテキスト判断プロセスに複雑さをもたらし得る。たとえば、上記のように、ビデオコーダは、適切なサポートを選択するためにコーディングされている変換係数のロケーションならびに並行して計算されているコンテキストの数を判断する必要があり得る。より高度の並列化を実装すると、追加の複雑さが追加され得る。たとえば、２つのビンＣＡＢＡＣ並列化（たとえば、２つのコンテキストを並行して計算すること）では、ビデオコーダが各４×４サブブロック中の２つの位置のためのサポートを変更する必要があり得る。並列化を増加させることはまた、必要とされる穴をもつ異なるサポートの数を増加させ得る。

[0167]本開示の態様によれば、ビデオコーダは、コンテキスト導出のためにスライディングウィンドウを使用して、並列コンテキスト計算を実行し得る。たとえば、ビデオコーダは、走査順序で、コーディングされている変換係数とサポートの変換係数のセットとの間にギャップをもたらし得る。すなわち、ビデオコーダは、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で１つまたは複数の変換係数をスキップし得る。コーディングされている変換係数とサポートの変換係数との間のギャップは、上記で説明したコンテキスト依存性を除去し得る。

[0168]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、２つの変換係数のギャップにより３つのコンテキストを並行して計算することが可能になり得る。したがって、ビデオコーダは、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。

[0169]図７Ａおよび図７Ｂは、本開示の態様による、走査順序に基づく例示的なコンテキスト導出近傍スライディングウィンドウを示す図である。図７Ａの例は、サブブロック１５４Ａ〜１５４Ｄ（総称して、サブブロック１５４）を有する変換係数のブロック１５０と、サブブロック１５４Ａの第１の変換係数１５８（変換係数１５）と、第１の変換係数１５８についてのコンテキストを判断するための初期コンテキスト導出近傍（サポート）１６２とを含む。概して、サブブロック１５４Ａの番号（０〜１５）は、図６に示した走査順序などの逆対角走査順序に対応する。すなわち、ビデオコーダは、第１の変換係数１５８（変換係数１５）から変換係数０まで順々にサブブロック１５４Ａの変換係数を走査し得る。

[0170]本開示の態様によれば、ビデオコーダは、サブブロック１５４Ａの変換係数０〜１５をコーディングするためのコンテキストを判断するために、１つまたは複数の位置ベースのサポートと走査順序ベースのサポートとの組合せを使用し得る。たとえば、ビデオコーダは、第１の変換係数１５８（変換係数１５）についてのコンテキストを判断するために初期サポート１６２を使用し得る。初期サポート１６２は、位置ベースであり得る。すなわち、ビデオコーダは、第１の変換係数１５８に対する初期サポート１６２中に含まれる変換係数の相対位置に基づいて初期サポート１６２を選択し得る。

[0171]サブブロック１５４Ａの残りの変換係数についてのコンテキストを判断するために、ビデオコーダは、サポートのスライディングウィンドウをポピュレートし得る。たとえば、概して、ビデオコーダは、たとえば、ｎ＋ｉからｎ＋ｊまでの前に走査された係数に依存するサポートを使用して、所与の位置ｎにおける変換係数についてのコンテキストを計算し得、ただし、ｉはｊの前にコーディングされる。サポートに５つの変換係数が使用されると仮定すると、ビデオコーダは、前に走査された係数ｎ＋１〜ｎ＋５に依存するサポートを使用して、所与の位置ｎにおける変換係数についてのコンテキストを計算し得る。したがって、変換係数が走査順序位置ｎを有する場合、コンテキスト導出近傍は、走査順序位置ｎ＋１〜ｎ＋５における変換係数を備え得る。図７Ａおよび図７Ｂの例では、ｎ＋５が１５以下に等しいとき、コンテキストを判断するためのサポートは走査順序にのみ依存する。すなわち、図７Ｂに関して以下でより詳細に説明するように、ビデオコーダは、第１の５つの変換係数（変換係数１５〜１１）についてのコンテキストを計算するための初期サポート１６２からの少なくとも１つの変換係数を含み得る。ただし、ビデオコーダが各連続する変換係数についてのコンテキストを計算するとき、ビデオコーダは、サポートのスライディングウィンドウに変換係数を走査順序でポピュレートし、サポートのスライディングウィンドウの相対終端から初期サポート１６２からの変換係数のうちの１つを除去する。

[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]ビデオコーダはまた、コーディングされたビンが、変換係数のブロックまたはサブブロックの最終変換係数の最終ビンであったかどうかを判断し得る（２９２）。コーディングされたビンが、ブロックまたはサブブロック中の最終変換係数の最終ビンでなかった場合、ビデオコーダは、コーディングされている次のビンが、ブロックまたはサブブロック中の初期変換係数位置に関連付けられるかどうかを判断することに戻り得る（２８２）。コーディングされている次のビンが、ブロックまたはサブブロック中の初期変換係数位置に関連付けられる場合、ビデオコーダは、ステップ２８８に関して上記で説明した所定のサポートを使用してサポートをリセットし得る。コーディングされたビンが、ブロックまたはサブブロック中の最終変換係数の最終ビンであった場合、ビデオコーダは、変換係数の次のブロックまたはサブブロックに移動し得る（２９４）。

[0204]本開示のいくつかの態様について、説明のために開発中のＨＥＶＣ規格に関して説明した。ただし、本開示で説明する技法は、Ｈ．２６４または他の規格に従って定義されるビデオコーディングプロセスあるいはまだ開発されていないプロプライエタリビデオコーディングプロセスなど、他のビデオコーディングプロセスのために有用であり得る。

[0205]さらに、上記のいくつかの例について、変換係数（たとえば、符号、有効性、レベルなど）をコーディングすることに関して説明したが、本開示の態様は、他の値またはシンボルに関連するビンをコーディングすることに適用され得る。たとえば、サポートのセットを判断するための技法は、変換係数ならびに他のシンボルに関連するビンを含む、様々なビンをコーディングするための様々なコンテキスト適応型エントロピーコーディング方式に適用され得る。

[0206]さらに、初期５ポイントサポートへの言及は例として与えたものである。５つよりも多いまたは５つよりも少ない要素を有する他のサポートも、本明細書で説明する技法に従って使用され得る。

[0207]ビデオコーダは、本開示で説明するように、（たとえば、ビデオエンコーダ２０またはビデオデコーダ３０などの）ビデオエンコーダまたはビデオデコーダを指すことがある。同様に、ビデオコーディングユニットは、ビデオエンコーダまたはビデオデコーダを指すことがある。同様に、ビデオコーディングはビデオ符号化またはビデオ復号を指すことがある。

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

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

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

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

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

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

[0213]様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングする方法であって、
変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
を備える、方法。
［Ｃ２］
前記コンテキスト導出近傍を定義することが、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを備える、Ｃ１に記載の方法。
［Ｃ３］
前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動することをさらに備える、Ｃ２に記載の方法。
［Ｃ４］
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、Ｃ２に記載の方法。
［Ｃ５］
前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、Ｃ２に記載の方法。
［Ｃ６］
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、Ｃ１に記載の方法。
［Ｃ７］
前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義することが、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めることを備える、Ｃ１に記載の方法。
［Ｃ８］
前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、Ｃ７に記載の方法。
［Ｃ９］
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
をさらに備える、Ｃ１に記載の方法。
［Ｃ１０］
前記コンテキストが、ＣＡＢＡＣコンテキストであり、コーディングすることが、ＣＡＢＡＣプロセスを使用して前記複数の変換係数のうちの前記１つをコーディングすることを備える、Ｃ１に記載の方法。
［Ｃ１１］
前記複数の変換係数のうちの前記１つをコーディングすることが、前記複数の変換係数のうちの前記１つを復号することを備える、Ｃ１に記載の方法。
［Ｃ１２］
前記複数の変換係数のうちの前記１つをコーディングすることが、前記複数の変換係数のうちの前記１つを符号化することを備える、Ｃ１に記載の方法。
［Ｃ１３］
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
を行うように構成された１つまたは複数のプロセッサを備える装置。
［Ｃ１４］
前記コンテキスト導出近傍を定義するために、前記１つまたは複数のプロセッサが、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するように構成された、Ｃ１３に記載の装置。
［Ｃ１５］
前記１つまたは複数のプロセッサが、前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動するようにさらに構成された、Ｃ１４に記載の装置。
［Ｃ１６］
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、Ｃ１４に記載の装置。
［Ｃ１７］
前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、Ｃ１４に記載の装置。
［Ｃ１８］
前記１つまたは複数のプロセッサが、
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
を行うようにさらに構成され、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、Ｃ１３に記載の装置。
［Ｃ１９］
前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するために、前記１つまたは複数のプロセッサが、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めるように構成された、Ｃ１３に記載の装置。
［Ｃ２０］
前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、Ｃ１９に記載の装置。
［Ｃ２１］
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記１つまたは複数のプロセッサが、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
を行うようにさらに構成された、Ｃ１３に記載の装置。
［Ｃ２２］
前記コンテキストが、ＣＡＢＡＣコンテキストであり、コーディングするために、前記１つまたは複数のプロセッサが、ＣＡＢＡＣプロセスを使用して前記複数の変換係数のうちの前記１つをコーディングするように構成された、Ｃ１３に記載の装置。
［Ｃ２３］
前記複数の変換係数のうちの前記１つをコーディングするために、前記１つまたは複数のプロセッサが、前記複数の変換係数のうちの前記１つを復号するように構成された、Ｃ１３に記載の装置。
［Ｃ２４］
前記複数の変換係数のうちの前記１つをコーディングするために、前記１つまたは複数のプロセッサが、前記複数の変換係数のうちの前記１つを符号化するように構成された、Ｃ１３に記載の装置。
［Ｃ２５］
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義するための手段と、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断するための手段と、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングするための手段と
を備える装置。
［Ｃ２６］
前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するための手段を備える、Ｃ２５に記載の装置。
［Ｃ２７］
前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動するための手段をさらに備える、Ｃ２６に記載の装置。
［Ｃ２８］
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、Ｃ２６に記載の装置。
［Ｃ２９］
前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、Ｃ２６に記載の装置。
［Ｃ３０］
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義するための手段
をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、Ｃ２５に記載の装置。
［Ｃ３１］
前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めるための手段を備える、Ｃ２５に記載の装置。
［Ｃ３２］
前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、Ｃ３１に記載の装置。
［Ｃ３３］
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義するための手段であって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義するための手段と、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングするための手段と
をさらに備える、Ｃ２５に記載の装置。
［Ｃ３４］
前記複数の変換係数のうちの前記１つをコーディングするための前記手段が、前記複数の変換係数のうちの前記１つを復号するための手段を備える、Ｃ２５に記載の装置。
［Ｃ３５］
前記複数の変換係数のうちの前記１つをコーディングするための前記手段が、前記複数の変換係数のうちの前記１つを符号化するための手段を備える、Ｃ２５に記載の装置。
［Ｃ３６］
実行されたとき、１つまたは複数のプロセッサに、
変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
を行わせる命令を備える非一時的コンピュータ可読媒体。
［Ｃ３７］
前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを前記１つまたは複数のプロセッサに行わせる、Ｃ３６に記載のコンピュータ可読媒体。
［Ｃ３８］
前記１つまたは複数のプロセッサに、前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動することを行わせる命令をさらに備える、Ｃ３７に記載のコンピュータ可読媒体。
［Ｃ３９］
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、Ｃ３７に記載のコンピュータ可読媒体。
［Ｃ４０］
前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、Ｃ３７に記載のコンピュータ可読媒体。
［Ｃ４１］
前記１つまたは複数のプロセッサに、
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
を行わせる命令をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、Ｃ３６に記載のコンピュータ可読媒体。
［Ｃ４２］
前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めることを前記１つまたは複数のプロセッサに行わせる、Ｃ３６に記載のコンピュータ可読媒体。
［Ｃ４３］
前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、Ｃ４２に記載のコンピュータ可読媒体。
［Ｃ４４］
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記１つまたは複数のプロセッサに、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
を行わせる命令をさらに備える、Ｃ３６に記載のコンピュータ可読媒体。
［Ｃ４５］
前記複数の変換係数のうちの前記１つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記１つを復号することを前記１つまたは複数のプロセッサに行わせる、Ｃ３６に記載のコンピュータ可読媒体。
［Ｃ４６］
前記複数の変換係数のうちの前記１つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記１つを符号化することを前記１つまたは複数のプロセッサに行わせる、Ｃ３６に記載のコンピュータ可読媒体。

Claims (46)

1. ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングする方法であって、
   変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
   前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
   前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
   を備える、方法。
2. 前記コンテキスト導出近傍を定義することが、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを備える、請求項１に記載の方法。
3. 前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動することをさらに備える、請求項２に記載の方法。
4. 変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、請求項２に記載の方法。
5. 前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、請求項２に記載の方法。
6. 前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
   をさらに備え、
   前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、請求項１に記載の方法。
7. 前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義することが、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めることを備える、請求項１に記載の方法。
8. 前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、請求項７に記載の方法。
9. 前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
   前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
   前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
   をさらに備える、請求項１に記載の方法。
10. 前記コンテキストが、ＣＡＢＡＣコンテキストであり、コーディングすることが、ＣＡＢＡＣプロセスを使用して前記複数の変換係数のうちの前記１つをコーディングすることを備える、請求項１に記載の方法。
11. 前記複数の変換係数のうちの前記１つをコーディングすることが、前記複数の変換係数のうちの前記１つを復号することを備える、請求項１に記載の方法。
12. 前記複数の変換係数のうちの前記１つをコーディングすることが、前記複数の変換係数のうちの前記１つを符号化することを備える、請求項１に記載の方法。
13. ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
    変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
    前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
    前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
    を行うように構成された１つまたは複数のプロセッサを備える装置。
14. 前記コンテキスト導出近傍を定義するために、前記１つまたは複数のプロセッサが、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するように構成された、請求項１３に記載の装置。
15. 前記１つまたは複数のプロセッサが、前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動するようにさらに構成された、請求項１４に記載の装置。
16. 変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、請求項１４に記載の装置。
17. 前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、請求項１４に記載の装置。
18. 前記１つまたは複数のプロセッサが、
    前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
    を行うようにさらに構成され、
    前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、請求項１３に記載の装置。
19. 前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するために、前記１つまたは複数のプロセッサが、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めるように構成された、請求項１３に記載の装置。
20. 前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、請求項１９に記載の装置。
21. 前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
    前記１つまたは複数のプロセッサが、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
    前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
    を行うようにさらに構成された、請求項１３に記載の装置。
22. 前記コンテキストが、ＣＡＢＡＣコンテキストであり、コーディングするために、前記１つまたは複数のプロセッサが、ＣＡＢＡＣプロセスを使用して前記複数の変換係数のうちの前記１つをコーディングするように構成された、請求項１３に記載の装置。
23. 前記複数の変換係数のうちの前記１つをコーディングするために、前記１つまたは複数のプロセッサが、前記複数の変換係数のうちの前記１つを復号するように構成された、請求項１３に記載の装置。
24. 前記複数の変換係数のうちの前記１つをコーディングするために、前記１つまたは複数のプロセッサが、前記複数の変換係数のうちの前記１つを符号化するように構成された、請求項１３に記載の装置。
25. ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
    変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義するための手段と、
    前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断するための手段と、
    前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングするための手段と
    を備える装置。
26. 前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するための手段を備える、請求項２５に記載の装置。
27. 前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動するための手段をさらに備える、請求項２６に記載の装置。
28. 変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、請求項２６に記載の装置。
29. 前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、請求項２６に記載の装置。
30. 前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義するための手段
    をさらに備え、
    前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、請求項２５に記載の装置。
31. 前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めるための手段を備える、請求項２５に記載の装置。
32. 前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、請求項３１に記載の装置。
33. 前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
    前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義するための手段であって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義するための手段と、
    前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングするための手段と
    をさらに備える、請求項２５に記載の装置。
34. 前記複数の変換係数のうちの前記１つをコーディングするための前記手段が、前記複数の変換係数のうちの前記１つを復号するための手段を備える、請求項２５に記載の装置。
35. 前記複数の変換係数のうちの前記１つをコーディングするための前記手段が、前記複数の変換係数のうちの前記１つを符号化するための手段を備える、請求項２５に記載の装置。
36. 実行されたとき、１つまたは複数のプロセッサに、
    変換係数走査順序に基づいて複数の変換係数のうちの１つのためのコンテキスト導出近傍を定義することと、
    前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記１つについてのコンテキストを判断することと、
    前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記１つをコーディングすることと
    を行わせる命令を備える非一時的コンピュータ可読媒体。
37. 前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数走査順序で前記複数の変換係数のうちの前記１つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを前記１つまたは複数のプロセッサに行わせる、請求項３６に記載のコンピュータ可読媒体。
38. 前記１つまたは複数のプロセッサに、前記スライディングウィンドウが前記複数の変換係数のうちの前記１つを含むように、前記複数の変換係数のうちの前記１つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で１つの位置だけ移動することを行わせる命令をさらに備える、請求項３７に記載のコンピュータ可読媒体。
39. 変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、請求項３７に記載のコンピュータ可読媒体。
40. 前記複数の変換係数のうちの前記１つが、走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋ｉ〜ｎ＋ｊにおける変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋ｉ〜ｎ＋ｊの後に走査され、走査順序位置ｎ＋ｊが、走査順序位置ｎ＋ｉの後に走査される、請求項３７に記載のコンピュータ可読媒体。
41. 前記１つまたは複数のプロセッサに、
    前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
    を行わせる命令をさらに備え、
    前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、請求項３６に記載のコンピュータ可読媒体。
42. 前記複数の変換係数のうちの前記１つのための前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数のうちの前記１つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも１つの変換係数のギャップを含めることを前記１つまたは複数のプロセッサに行わせる、請求項３６に記載のコンピュータ可読媒体。
43. 前記変換係数が走査順序位置ｎを有し、前記コンテキスト導出近傍が、走査順序位置ｎ＋２〜ｎ＋６における変換係数を備え、走査順序位置ｎが、走査順序位置ｎ＋２〜ｎ＋６の後に走査される、請求項４２に記載のコンピュータ可読媒体。
44. 前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
    前記１つまたは複数のプロセッサに、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
    前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
    を行わせる命令をさらに備える、請求項３６に記載のコンピュータ可読媒体。
45. 前記複数の変換係数のうちの前記１つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記１つを復号することを前記１つまたは複数のプロセッサに行わせる、請求項３６に記載のコンピュータ可読媒体。
46. 前記複数の変換係数のうちの前記１つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記１つを符号化することを前記１つまたは複数のプロセッサに行わせる、請求項３６に記載のコンピュータ可読媒体。