[0024]ビデオコーディングデバイスは、空間的冗長性と時間的冗長性とを利用することによってビデオデータを圧縮しようと試み得る。たとえば、ビデオエンコーダは、隣接する、前にコーディングされたブロックに対してブロックをコーディングすることによって空間的冗長性を利用し得る。同様に、ビデオエンコーダは、前にコーディングされたフレームのデータに対してブロックをコーディングすることによって時間的冗長性を利用し得る。具体的には、ビデオエンコーダは現在のブロックを、空間的隣接部分のデータから、または以前コーディングされたフレームのデータから予測し得る。次いでビデオエンコーダは、ブロックの実際のピクセル値とブロックの予測ピクセル値との間の差分としてブロックの残差を計算し得る。したがって、ブロックの残差は、ピクセル(または空間的)領域におけるピクセルごとの差分値を含み得る。
[0025]ビデオエンコーダは、次いで、残差の値に変換を適用して、ピクセル値のエネルギーを周波数領域における比較的小さい数の変換係数に圧縮し得る。ビデオエンコーダはまた、変換係数を量子化し得る。概して、「変換係数」という用語は、量子化されていることも量子化されていないこともある、残差ブロックのための変換領域における係数を指す。
[0026]ビデオエンコーダは、量子化変換係数を走査して、量子化変換係数の2次元行列を、量子化変換係数を含む1次元ベクトルに変換し得る。係数を走査するプロセスは、係数の直列化と呼ばれることがある。
[0027]ビデオエンコーダは、次いで、走査された変換係数、ならびにビデオデータを復号する際にビデオデコーダが使用するための符号化ビデオデータに関連する他のシンタックス要素をエントロピー符号化するためにエントロピーコーディングプロセスを適用し得る。例示的なエントロピーコーディングプロセスとしては、たとえば、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは他のエントロピー符号化方法があり得る。以下でより詳細に説明するように、「変換係数」をエントロピーコーディングすることへの言及は、非量子化変換係数をエントロピーコーディングすること、ならびに量子化変換係数をエントロピーコーディングすることの両方を指すことがある。
[0028]概して、コンテキスト適応型コーディングは2値化値に対して実行される。したがって、ビデオエンコーダは、コーディングされている各値(たとえば、変換係数レベル、シンボル、シンタックス要素など)の絶対値を2値化形態に変換し得る。このようにして、コーディングされている各非ゼロ値は、たとえば、単項コーディングテーブルを使用して、または値を1つまたは複数のビットまたは「ビン」を有するコードワードに変換する他のコーディング方式を使用して、2値化され得る。
[0029]ビデオエンコーダは、次いで、ビデオデータのブロックに関連するシンボルをコーディングするために動作する確率モデルまたは「コンテキストモデル」を選択し得る。確率モデルは、ビンが所与の2進値(たとえば、「0」または「1」)を有する可能性を示す。したがって、エンコーダにおいて、確率モデルを使用することによってターゲットシンボルがコーディングされ得る。デコーダにおいて、確率モデルを使用することによってターゲットシンボルがパースされ得る。いずれの場合も、ビデオコーダは、ビンのコンテキストを判断することによって確率モデルを選択し得る。
[0030]シンタックス要素のビンのコンテキストは、前にコーディングされた隣接シンタックス要素の関係するビンの値を含み得る。一例として、現在のシンタックス要素のビンをコーディングするためのコンテキストは、たとえば、現在のシンタックス要素の上部および左側にある、前にコーディングされた隣接シンタックス要素の関係するビンの値を含み得る。コンテキストが導出されるロケーションはコンテキスト導出近傍と呼ばれることがある(「コンテキストサポート近傍」または単に「サポート」と呼ばれることもある)。たとえば、位置ベースのコンテキスト導出近傍は、現在コーディングされている変換係数に対する所定の変換係数ロケーションを含み得る。
[0031]一例では、説明のために、(たとえば、ビデオデータのブロックにおける非ゼロ変換係数のロケーションを示す)有効性マップのビンをコーディングするためのコンテキストモデルを定義するために5ポイントの位置ベースのサポートが使用され得る。5ポイントのサポートは、現在コーディングされている有効性フラグに隣接する5つの変換係数位置を含み得る。この例では、確率モデルはCtxによって識別され、Ctxは、サポートのあらゆるポイント中の有効フラグの和として定義され得、ただし、有効性フラグは、以下の式(1)に示すように、対応する変換係数が非0である場合は「1」に設定され、対応する変換係数が0である場合は「0」に設定され、ただし、Sおよびpは、サポート中の有効性フラグに対応する。
[0032]他の例では、コンテキストモデルは、前にコーディングされたサブブロックに関連する値(たとえば、前にコーディングされたサブブロック中の有効性フラグの数)に基づき得る。いずれの場合も、いくつかの例では、Ctxは、各々が特定の確率モデルに対応し得る複数の異なるコンテキストのうちの1つを選択するために適用されるインデックスまたはオフセットであり得る。したがって、いずれの場合も、一般に、コンテキストごとに異なる確率モデルが定義される。ビンをコーディングした後に、確率モデルは、ビンについての最新の確率推定値を反映するために、ビンの値に基づいてさらに更新される。たとえば、確率モデルは、有限状態機械における状態として維持され得る。各特定の状態は特定の確率値に対応し得る。確率モデルの更新に対応する次の状態は、現在のビン(たとえば、現在コーディングされているビン)の値に依存し得る。したがって、前にコーディングされたビンの値は、少なくとも部分的に、ビンが所与の値を有する確率を示すので、確率モデルの選択は、前にコーディングされたビンの値によって影響され得る。
[0033]いくつかの例によれば、ビデオブロック中の有効係数(すなわち、非0変換係数)の位置は、変換係数の「レベル」と呼ばれることがある、変換係数の値より前にコーディングされ得る。有効係数のロケーションをコーディングするプロセスは、有効性マップコーディングと呼ばれることがある。有効性マップ(SM:significance map)は、有効係数のロケーションを示す2進値の2次元アレイを含む。
[0034]たとえば、ビデオデータのブロックについてのSMは、1および0の2次元アレイを含み得、1は、ブロック内の有効変換係数の位置を示し、0は、ブロック内の非有効(0値)変換係数の位置を示す。1および0は「有効係数フラグ」と呼ばれる。さらに、いくつかの例では、SMは1および0の別の2Dアレイを含み得、1は、ブロックに関連する走査順序に従うブロック内の最後有効係数の位置を示し、0は、ブロック内のすべての他の係数の位置を示す。この場合、1は、「最後有効係数フラグ」と呼ばれる。他の例では、最後有効係数フラグは使用されないことがある。むしろ、ブロック中の最後有効係数は、SMの残りをコーディングする前に最初にコーディングされ得る。
[0035]2値化された変換係数の残りのビン(ならびにコンテキストコーディングされている任意の他のシンタックス要素)が、次いで、1つまたは複数の追加のコーディングパスでコーディングされ得る。たとえば、第1のパス中に、ビデオコーダがSMをエントロピーコーディングし得る。第2のパス中に、ビデオコーダは、変換係数レベルの第1のビンをエントロピーコーディングし得る。いくつかの例では、第1のビンは、係数レベルが1よりも大きいかどうかを示し得、第2のビンは、係数レベルが2よりも大きいかどうかを示し得る。第3のビンは、たとえば、レベル−3の値をコーディングする2よりも大きい係数のレベルの剰余値を示すために使用され得る。別のビンは、いくつかの例では、係数レベルの符号を示し得る。
[0036]ビデオコーダは、ブロックの変換係数に関連する情報のすべてがコーディングされるまで、コーディングパスを実行し続け得る。いくつかの例では、ビデオコーダは、コンテキスト適応型コーディングと非コンテキスト適応型コーディングとの組合せを使用してビデオデータのブロックのビンをコーディングし得る。たとえば、1つまたは複数のパスについて、ビデオコーダは、標準コンテキスト適応型算術コーディングプロセスをバイパスまたは省略するためにバイパスモードを使用し得る。そのような場合、バイパスコーディングされたビンをコーディングするために固定の等確率モデルが使用され得る。
[0037]いくつかの例では、効率を上げ、かつ/または実装を簡単にするために、変換係数のブロックは、コーディングのためにサブセットに分割され得る(このサブセットは複数のサブブロックという形態をとり得る)。たとえば、32×32または64×64のブロックなどの比較的大きいブロックをコーディングするときにソフトウェアまたはハードウェアビデオコーダが特定の走査(たとえば、ジグザグ、対角、水平、垂直など)を実装することは計算量的に非効率的であり得る。そのような例では、ビデオコーダは、所定のサイズの複数のより小さいサブブロック(たとえば、8×8のサブブロック)にブロックを分割し得る。ビデオコーダは、次いで、ブロック全体がコーディングされるまで順々に各サブセットを走査しコーディングし得る。
[0038]いずれの場合も、コンテキストを計算するために位置ベースのコンテキストサポート近傍を使用すると計算コストが比較的高くなり得る。上記で説明した5ポイントの位置ベースのサポートの例では、ビデオコーダは、位置(x,y)における各変換係数をコーディングするとき、位置(x+1,y)、(x,y+1)、(x+1,y+1)、(x+2,y)および(x,y+2)に位置する変換係数の有効性を判断しなければならない。さらに、ビデオコーダはまた、サポート中の変換係数の位置が、現在コーディングされている変換係数を含むブロックの内部に位置するのか、またはそれの外部に位置するのかを判断し得る。
[0039]位置ベースのサポートはまた、データアクセスに関連する複雑さを提示し得る。たとえば、上記で説明した5ポイントの位置ベースのサポートの例では、走査順序で連続する変換係数についてのコンテキストを計算するためのサポートは、第1の変換係数から次の変換係数までほとんどまたはまったく重複しないことを示し得る。すなわち、連続して走査され、コーディングされる2つの変換係数は、それらのそれぞれのサポート中で位置をほとんどまたはまったく共有しないことがある。したがって、ビデオコーダは、(たとえば、コンテキスト計算についてのデータを共有するのではなく)各コンテキストを計算するための最高5つの異なる変換係数にアクセスし得る。
[0040]説明のための一例では、変換係数のブロックが4×4のサブブロックに再分割されると仮定する。さらに、サブブロックがそれぞれ対角線方向の走査パターンを使用して走査されると仮定する。この例では、1つのサブブロック中で走査されている最終変換係数のサポートは、次のサブブロック中で走査されている第1の変換といかなるサポート位置も共有し得ない。したがって、ビデオコーダは、これらの位置についてのコンテキストを計算するために比較的大きいデータの量を取り出さなければならず、それは、コーディングプロセスを遅くし得る。
[0041]本開示の態様は、概して、変換係数走査順序に基づくコンテキスト導出近傍に関する。たとえば、上記で説明した、コンテキストを判断するために位置ベースのサポートを使用するのではなく、本開示の態様は、コーディング中に変換係数が走査される順序に基づくコンテキストを判断するためにサポートを使用することに関する。すなわち、本開示の態様によれば、サポートは、(ビデオエンコーダにおいて)変換係数の2次元アレイを変換係数の1次元アレイに直列化するために変換係数が走査されるか、または(ビデオデコーダにおいて)変換係数の1次元アレイから変換係数の2次元アレイを再構成するために逆走査される順序に基づいて判断される。
[0042]したがって、本開示の態様によれば、ビデオコーダ(たとえば、ビデオエンコーダまたはビデオデコーダ)は、走査順序で前の変換係数のセットに基づいて変換係数(たとえば、有効性、レベル、符号など)をコンテキストコーディングするためのコンテキストを導出するためのサポートを判断し得る。いくつかの例では、走査順序で前の変換係数のセットは、所定の数の走査順序で連続する変換係数(たとえば、3、4、5など)を含み得る。サポート中に含まれる変換係数のセットは、以下で説明するように、「スライディングウィンドウ」によって定義され得る。
[0043]説明のための一例では、ビデオデコーダは、走査順序で前の係数のセット(たとえば、n+i〜n+j、ただし、iはjより前にコーディングされる)に基づいて第1の変換係数(n)を復号するためのコンテキストを判断し得る。たとえば、ビデオデコーダは、走査順序で5つの前の変換係数のセット(n+1〜n+5)に基づいて第1の変換係数(n)を復号するためのコンテキストを判断し得る。次に、ビデオデコーダは、所定の数の変換係数を含むウィンドウを走査順序で1つの位置だけスライドさせることによって第2の変換係数(n−1)を復号するためのコンテキストを判断し得る。すなわち、本開示の態様によれば、スライディングウィンドウは、コンテキストを判断するために使用される変換係数を識別する。ウィンドウは、連続する変換係数がコーディングされるにつれて走査順序で「スライドする」かまたは移動する。
[0044]したがって、ビデオデコーダは、走査順序で5つの前の変換係数の新しいセット(n〜n+4)に基づいて第2の変換係数(n−1)を復号するためのコンテキストを判断し得る。5つの前の変換係数の新しいセットは、第1の変換係数(n)を含み、第1のセットの最後の変換係数(n+5)を除去する。このようにして、コンテキストを判断するための変換係数のウィンドウが走査順序でスライドし続け、変換係数が走査される。上記の例はビデオデコーダに関して説明したが、ビデオエンコーダによって同じ技法が適用され得る。さらに、5つよりも多いまたは5つよりも少ない変換係数がウィンドウによって定義され得る。
[0045]いくつかの例では、ビデオコーダは、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、ビデオコーダは、ブロックまたはサブブロック中で第1の変換係数をコーディングするためのコンテキストを計算するときにサポートの新しいセットを用いて開始し得る。この例では、ビデオコーダは、走査順序に基づいて初期サポートを判断し得ない。むしろ、いくつかの例では、ビデオコーダは、ブロックまたはサブブロック中で第1の変換係数をコーディングするためのコンテキストを計算するための、上記で説明した位置ベースのサポートを実装し得る。次いで、ビデオコーダが、ブロックまたはサブブロック中で変換係数をコーディングし続けるにつれて、ビデオコーダは、コンテキストを計算するためにサポートのスライディングウィンドウに走査順序で変換係数をポピュレートし得る。
[0046]たとえば、ビデオコーダは、変換係数をコーディングしながら、サポートのスライディングウィンドウに一度に1つの変換係数をポピュレートし得る。したがって、ビデオコーダは、ブロックまたはサブブロックの1つまたは複数の変換係数のためのサポートを判断するために、初期サポートの変換係数と走査順序に基づく変換係数との混合を使用し得る。たとえば、ビデオコーダは、ブロックまたはサブブロックの第1の変換係数についてのコンテキストを判断するために初期の5ポイントのサポートを使用し得る。この例では、ビデオコーダは、初期サポートからの4つの変換係数と走査順序に基づく1つの変換係数とを使用して走査順序でブロックまたはサブブロックの第2の変換係数についてのコンテキストを判断し得る。同様に、ビデオコーダは、サポートのスライディングウィンドウに走査順序に基づいて変換係数が完全にポピュレートされるまで、初期サポートからの3つの変換係数と走査順序に基づく2つの変換係数とを使用して走査順序でブロックまたはサブブロックの第3の変換係数についてのコンテキストを判断し、以下同様に行い得る。
[0047]このようにして、本開示の技法はコンテキスト計算を簡略化し得る。たとえば、本開示の技法を実装すると、ビデオコーダは、変換係数についてのコンテキストを判断するために(変換係数のブロックまたはサブブロック中の)変換係数の相対ロケーションを判断する必要がない。さらに、本開示の技法は、コンテキストを判断するときにメモリからアクセスされるデータの量を低減させ得る。たとえば、ビデオコーダは、連続する係数についてのコンテキストを判断するときにデータの大部分を再利用し得る。すなわち、ビデオコーダは、説明したコンテキスト計算ウィンドウが1つの変換係数から次の変換係数にスライドするとき、1つの新しい変換係数に関連するデータのみを取り出す。さらに、ビデオコーダは、変換係数を走査するために使用されている走査の方向(たとえば、ジグザグ、対角、水平、垂直など)にかかわらず、コンテキストを判断するために同じ技法を適用し得る。
[0048]いくつかの事例では、コーディング効率を増加させるために並列処理が使用され得る。概して、並列処理は、概して、2つ以上の計算を同時に実行することを指す。ただし、いくつかの例では、並列処理は、2つのプロセスの厳密な時間的一致を含まないことがある。むしろ、並列処理は、そのようなプロセスが同時に実行されない重複または時間的進行を含み得る。並列処理は、並列ハードウェア処理コアによって実行されるか、または同じまたは異なる処理コア上で動作する並列ソフトウェアスレッドを用いて実行され得る。
[0049]いずれの場合も、変換係数コーディングに関して、2つ以上の変換係数についてのコンテキストを並行して計算するために並列処理が使用され得る。しかしながら、2つ以上の変換係数を並行して計算するために、サポート中の位置のすべてがコーディングのために利用可能でなければならない。たとえば、上記のように、有効性フラグをコーディングするためのコンテキストモデルは、サポート中の有効性フラグのすべてを合計することによって判断され得る。有効性フラグをコーディングするためのコンテキストモデルを判断するとき、サポート中の有効性フラグのすべてが合計のために利用可能であるようにするために、そのようなフラグは前にコーディング(判断)されていなければならない。
[0050]いくつかの事例では、特定のサポート中の1つまたは複数の有効性フラグは、コンテキストを判断するためにサポート中の他の有効性フラグに依存し得る。たとえば、第1の有効性フラグAがそれのサポート中に隣接有効性フラグBを含むと仮定する。したがって、有効性フラグAのためのコンテキストモデルを判断するために、有効性フラグBが利用可能でなければならない(コーディングされなければならない)。したがって、この例では、有効性フラグAについてのコンテキストが有効性フラグBに依存する(たとえば、有効性コンテキストがサポート内で依存的である)ので、有効性フラグAおよびBについてのコンテキストは並行してコーディングされ得ない。ビデオコーダは、有効性フラグBがコーディングされるまで有効性フラグAについてのコンテキストを計算するのを待たなければならず、それによって、並列コンテキスト計算が防げられ、コンテキストの並列処理に関連する効率利得が低減するかまたはなくなる。
[0051]上記で説明した並列コンテキスト計算プロセスは、コンテキスト判断プロセスに追加の複雑さをもたらし得る。たとえば、いくつかの事例では、ビデオコーダは、2つ以上の変換係数をコーディングするための2つ以上のコンテキストを並行して計算し得る(たとえば、2つのビン並列化、3つのビン並列化など)。そのような場合、コンテキストを計算するために位置ベースのサポートを使用すると、ビデオコーダは、上記のコンテキスト依存性を除去するためにサポートを変更し得る。そのような位置ベースのサポート変更は、複雑さを追加し得、コンテキスト計算プロセスを遅くし得る。
[0052]本開示の態様によれば、上記で説明したスライディングウィンドウ手法は、並列コンテキスト計算を簡略化し得る。たとえば、いくつかの事例では、走査順序で、コーディングされている変換係数とサポートの変換係数のセットとの間にギャップがもたらされ得る。すなわち、ビデオコーダは、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で1つまたは複数の変換係数をスキップし得る。コーディングされている変換係数とサポートの変換係数との間のギャップは、上記で説明したコンテキスト依存性を除去し得る。
[0053]説明のための一例では、ビデオデコーダは、走査順序で5つの前の変換係数のセット(n+2〜n+6)に基づいて第1の変換係数(n)を復号するためのコンテキストを判断し得る。ビデオデコーダはまた、走査順序で5つの前の変換係数のセット(n+3〜n+7)に基づいて第2の変換係数(n−1)を復号するためのコンテキストを判断し得る。第1の変換係数(n)とサポート(n+2〜n+6)との間にギャップをもたらすと(たとえば、n+1をスキップすると)文脈依存性が除去され、したがって、ビデオデコーダは、第1の変換係数(n)と第2の変換係数(n+1)とについてのコンテキストを並行して計算し得る。上記で説明したように、追加の変換係数がコーディングされるとき、サポートを定義するウィンドウは走査順序でスライドし得る。上記の例はビデオデコーダに関して説明したが、ビデオエンコーダによって同じ技法が適用され得る。さらに、5つよりも多いまたは5つよりも少ない変換係数がウィンドウによって定義され得る。
[0054]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、2つの変換係数のギャップにより3つのコンテキストを並行して計算することが可能になり得る。したがって、ビデオコーダは、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。
[0055]本開示の態様は、概して、変換係数についてのコンテキストを判断することに言及するが、変換係数が関連する有効性、レベル、符号などを含み得ることを理解されたい。したがって、本開示のいくつかの態様は、詳細には、変換係数に関連する有効性情報を含む有効性マップをコーディングするためのコンテキストを判断することに関係し得る。
[0056]図1は、コンテキストを導出するための本開示の技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示すように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを与えるソースデバイス12を含む。特に、ソースデバイス12は、コンピュータ可読媒体16を介してビデオデータを宛先デバイス14に与える。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備され得る。
[0057]宛先デバイス14は、コンピュータ可読媒体16を介して復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化されたビデオデータを移動させることができる任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が、符号化ビデオデータを宛先デバイス14にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルあるいは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0058]いくつかの例では、符号化されたデータは、出力インターフェース22からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス12によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介してストレージデバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi−Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0059]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH:dynamic adaptive streaming over HTTP)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0060]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、簡略化されたデブロッキング決定を実行するための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなど、外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
[0061]図1の図示のシステム10は一例にすぎない。本開示に従ってコンテキストを導出するための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。さらに、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオテレフォニーのための、ビデオデバイス12とビデオデバイス14との間の一方向または双方向のビデオ送信をサポートし得る。
[0062]ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16上に出力され得る。
[0063]コンピュータ可読媒体16は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)は、たとえば、ネットワーク送信を介して、ソースデバイス12から符号化されたビデオデータを受信し、宛先デバイス14に符号化されたビデオデータを与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化されたビデオデータを受信し、その符号化されたビデオデータを含んでいるディスクを生成し得る。したがって、様々な例では、コンピュータ可読媒体16は、様々な形態の1つまたは複数のコンピュータ可読媒体を含むと理解され得る。
[0064]本開示では、概して、ビデオエンコーダ20が、ある情報をビデオデコーダ30などの別のデバイスに「シグナリング」することに言及することがある。ただし、ビデオエンコーダ20は、いくつかのシンタックス要素をビデオデータの様々な符号化部分に関連付けることによって情報をシグナリングし、それによって、コード化ビットストリーム内で情報をシグナリングし得ることを理解されたい。すなわち、ビデオエンコーダ20は、いくつかのシンタックス要素をビデオデータの様々な符号化部分のヘッダに記憶することによってデータを「シグナリング」し得る。場合によっては、そのようなシンタックス要素は、ビデオデコーダ30によって受信され、復号されるより前に、符号化され、記憶され(たとえば、コンピュータ可読媒体16に記憶され)得る。したがって、「シグナリング」という用語は、通信がリアルタイムまたはほぼリアルタイムで行われるか、あるいは、符号化時にシンタックス要素を媒体に記憶し、次いで、この媒体に記憶された後の任意の時間にそのシンタックス要素が復号デバイスによって取り出され得るときなどに行われ得る、ある時間期間にわたって行われるかにかかわらず、概して、圧縮ビデオデータを復号するためのシンタックスまたは他のデータの通信を指し得る。
[0065]宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、ブロックおよび他のコード化ユニット、たとえば、GOPの特性および/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
[0066]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、適用可能なとき、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、1つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを備え得る。
[0067]図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびデコーダと統合され得、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0068]ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG−4、Part 10、アドバンストビデオコーディング(AVC)と呼ばれるITU−T H.264規格など、ビデオ圧縮規格、またはそのような規格の拡張に従って動作し得る。ITU−T H.264/MPEG−4(AVC)規格は、Joint Video Team(JVT)として知られる共同パートナーシップの成果として、ISO/IEC Moving Picture Experts Group(MPEG)とともにITU−T Video Coding Experts Group(VCEG)によって策定された。いくつかの態様では、本開示で説明する技法は、H.264規格に概して準拠するデバイスに適用され得る。H.264規格は、ITU−T Study Groupによる2005年3月付けのITU−T勧告H.264「Advanced Video Coding for generic audiovisual services」に記載されており、本明細書ではH.264規格またはH.264仕様、あるいはH.264/AVC規格または仕様と呼ぶことがある。ビデオ圧縮規格の他の例には、MPEG−2およびITU−T H.263がある。
[0069]JCT−VCは、HEVC規格の開発に取り組んでいる。本開示の技法は、任意の特定のコーディング規格に限定されないが、本技法は、HEVC規格に関係し得る。以下でHEVC WD9と呼ぶ、HEVCの最新のワーキングドラフト(WD)、Brossら、「High Efficiency Video Coding (HEVC) text specification draft 9」、は、2013年2月21日現在、http://phenix.int−evry.fr/jct/doc_end_user/documents/11_Shanghai/wg11/JCTVC−K1003−v13.zipから入手可能である。
[0070]HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。HMは、たとえば、ITU−T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、H.264は9つのイントラ予測符号化モードを与えるが、HMは35個ものイントラ予測符号化モードを与え得る。
[0071]概して、HMの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット(LCU)に分割され得ることを記述する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるLCUのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に分割され得る。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割された場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
[0072]4分木データ構造の各ノードは、対応するCUのシンタックスデータを与え得る。たとえば、4分木のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含み得る。CUのシンタックス要素は、再帰的に定義され得、CUがサブCUに分割されるかどうかに依存し得る。CUがさらに分割されない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的分割が存在しない場合でも、リーフCUの4つのサブCUをリーフCUとも呼ぶ。たとえば、16×16サイズのCUがさらに分割されない場合、この16×16CUが決して分割されなくても、4つの8×8サブCUをリーフCUとも呼ぶ。
[0073]CUは、CUがサイズ差異を有しないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、4つの子ノード(サブCUとも呼ばれる)に分割され得、各子ノードは、今度は親ノードとなり、別の4つの子ノードに分割され得る。4分木のリーフノードと呼ばれる、最終的な分割されていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大CU深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット(SCU:smallest coding unit)をも定義し得る。本開示では、HEVCのコンテキストにおけるCU、PU、またはTU、あるいは他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれのサブブロック)のいずれかを指すために「ブロック」という用語を使用する。
[0074]CUは、コーディングノードと、コーディングノードに関連する予測ユニット(PU:prediction unit)および変換ユニット(TU:transform unit)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。CUのサイズは、8×8ピクセルから最大64×64以上のピクセルをもつツリーブロックのサイズまでに及び得る。各CUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。
[0075]CUに関連するシンタックスデータは、たとえば、CUを1つまたは複数のPUに区分することを記述し得る。区分モードは、CUが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。PUは、形状が非方形になるように区分され得る。CUに関連するシンタックスデータは、たとえば、4分木に従って、CUを1つまたは複数のTUに区分することも記述し得る。TUは、形状が方形または非方形(たとえば、矩形)であり得る。
[0076]HEVC規格は、CUごとに異なり得るTUに従う変換を可能にする。TUは、一般に、区分されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。TUは、一般に、PUと同じサイズであるかまたはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用してより小さいユニットに再分割され得る。RQTのリーフノードは変換ユニット(TU)と呼ばれることがある。TUに関連するピクセル差分値は、量子化され得る変換係数を生成するために変換され得る。
[0077]リーフCUは、1つまたは複数の予測ユニット(PU)を含み得る。概して、PUは、対応するCUの全部または一部分に対応する空間的エリアを表し、そのPUの参照サンプルを取り出すためのデータを含み得る。その上、PUは、予測に関係するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUについてのデータは、PUに対応するTUについてのイントラ予測モードを記述するデータを含み得る残差4分木(RQT)中に含まれ得る。別の例として、PUがインターモード符号化されるとき、PUは、PUのための1つまたは複数の動きベクトルを定義するデータを含み得る。PUの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度もしくは1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルの参照ピクチャリスト(たとえば、リスト0、リスト1、もしくはリストC)を記述し得る。
[0078]1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換ユニット(TU)を含み得る。変換ユニットは、上記で説明したように、(TU4分木構造とも呼ばれる)RQTを使用して指定され得る。たとえば、分割フラグは、リーフCUが4つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらに、さらなるサブTUに分割され得る。TUがさらに分割されないとき、そのTUはリーフTUと呼ばれることがある。概して、イントラコーディングの場合、リーフCUに属するすべてのリーフTUは同じイントラ予測モードを共有する。すなわち、概して、リーフCUのすべてのTUの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフTUの残差値を、TUに対応するCUの一部と元のブロックとの間の差分として計算し得る。TUは、必ずしもPUのサイズに制限されるとは限らない。したがって、TUは、PUよりも大きいことも小さいこともある。イントラコーディングの場合、PUは、同じCUの対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
[0079]その上、リーフCUのTUはまた、残差4分木(RQT)と呼ばれる、それぞれの4分木データ構造に関連付けられ得る。すなわち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含み得る。TU4分木のルートノードは概してリーフCUに対応し、CU4分木のルートノードは概してツリーブロック(またはLCU)に対応する。分割されないRQTのTUはリーフTUと呼ばれる。概して、本開示では、特に明記しない限り、リーフCUおよびリーフTUに言及するためにそれぞれCUおよびTUという用語を使用する。
[0080]HMは、パーティションモードとも呼ばれる様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズでのイントラ予測をサポートし、2N×2N、2N×N、N×2N、またはN×Nの対称的なPUサイズでのインター予測をサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、または「Right」という表示によって示される。したがって、たとえば、「2N×nU」は、上部の2N×0.5N PUと下部の2N×1.5N PUとで水平方向に区分された2N×2N CUを指す。
[0081]CUのPUを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ20は、CUのTUのための残差データを計算し得る。PUは、(ピクセル領域とも呼ばれる)空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、TUは、たとえば、残差ビデオデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換などの変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、TUを変換して、CUの変換係数を生成し得る。
[0082]変換係数を生成するための任意の変換の後に、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にnビット値がmビット値に切り捨てられ得、ただし、nはmよりも大きい。
[0083]量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む2次元行列から1次元ベクトルを生成し得る。走査は、より高いエネルギー(したがってより低い周波数)の係数をアレイの前方に配置し、より低いエネルギー(したがってより高い周波数)の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は適応走査を実行し得る。
[0084]量子化変換係数を走査して1次元ベクトルを形成した後に、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC:context-adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context-adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための、符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
[0085]ビデオエンコーダ20は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびピクチャグループ(GOP:group of pictures)ベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはGOPヘッダ中でビデオデコーダ30に送り得る。GOPシンタックスデータは、それぞれのGOP中のいくつかのフレームを記述し得、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化/予測モードを示し得る。
[0086]ビデオエンコーダ20は、2値化値(たとえば、2値化された変換係数、シンボル、シンタックス要素など)に対してコンテキストベースのコーディング(たとえば、CABAC)を実行し得る。たとえば、各ビンに対して、ビデオエンコーダ20は、ビデオデータのブロックに関連するシンボルをコーディングするためにコンテキスト上で動作する確率モデルまたは「コンテキストモデル」を選択し得る。確率モデルは、ビンが所与の2進値(たとえば、「0」または「1」)を有する可能性を示す。
[0087]ビデオエンコーダ20は、ビンのコンテキストを判断することによって確率モデルを選択し得る。コンテキストが導出される位置はコンテキスト導出近傍と呼ばれることがある(「コンテキストサポート近傍」または単に「サポート」と呼ばれることもある)。
[0088]いくつかの例では、ビデオエンコーダ20は、コンテキストモデルを定義するために位置ベースの5ポイントのサポート近傍を使用し得るが、より多いまたはより少ないサポート位置を用いる他のサイズのサポートが使用され得る。5ポイントのサポートは、現在コーディングされている有効性フラグに空間的に隣接する5つの変換係数位置を含み得る。サポートを使用することによって、ビデオエンコーダ20は、確率モデルを、サポートのあらゆるポイントにおける有効性フラグの和として定義し得る。
[0089]ただし、コンテキストを計算するために位置ベースのコンテキストサポート近傍を使用すると計算コストが比較的高くなり得る。たとえば、上記で説明した5ポイントの位置ベースのサポートを使用するために、ビデオエンコーダ20は、5つの異なるロケーションにおいて変換係数の有効性を判断しなければならない。ビデオエンコーダ20はまた、サポート中の変換係数の位置が、現在コーディングされている変換係数を含むブロックの内部に位置するのか、またはそれの外部に位置するのかを判断し得る。さらに、ビデオエンコーダ20は、連続するコンテキストを計算するときにサポートデータを再使用することができないことがある。むしろ、ビデオエンコーダ20は、計算されているコンテキストごとに最大5つの変換係数に関連するデータにアクセスする必要があり得る。
[0090]本開示の態様は、概して、変換係数走査順序に基づくコンテキスト導出近傍に関する。たとえば、コンテキストを判断するために位置ベースのサポートを使用するのではなく、本開示の態様によれば、ビデオエンコーダ20は、係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することによってビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数を符号化し得る。ビデオエンコーダ20はまた、コンテキスト導出近傍に基づいて複数の変換係数のうちの1つについてのコンテキストを判断し得る。ビデオエンコーダ20は、次いで、判断されたコンテキストに基づいて変換係数のうちの1つを符号化し得る。
[0091]係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義するために、ビデオエンコーダ20は、走査順序で前の変換係数のセットを識別し得る。いくつかの例では、走査順序で前の変換係数のセットは、所定の数の走査順序で連続する変換係数(たとえば、3、4、5など)を含み得る。上記のように、サポートを定義するためにスライディングウィンドウが使用され得る。たとえば、コーディングされている連続する変換係数ごとに、ビデオエンコーダ20は、ウィンドウに走査順序で新しい変換係数を追加し、前のサポートの相対終端から変換係数を除去し得る。このようにして、コンテキストを判断するための変換係数のウィンドウが走査順序でスライドし続け、変換係数が走査される。
[0092]いくつかの例では、ビデオエンコーダ20は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、ビデオエンコーダ20は、新しいサポートを用いてブロックまたはサブブロックごとに第1の変換係数についてのコンテキストを計算し始め得る。いくつかの例では、ビデオエンコーダ20は、ブロックまたはサブブロック中の第1の変換係数をコーディングするためのコンテキストを計算するために、走査順序に基づいていないサポートを使用し得る。ビデオエンコーダ20は、次いで、サポートのスライディングウィンドウに走査順序で変換係数をポピュレートすることによって、走査順序に基づくサポートに切り替わり得る。
[0093]このようにして、本開示の技法はコンテキスト計算を簡略化し得る。たとえば、ビデオエンコーダ20は、変換係数についてのコンテキストを判断するために(変換係数のブロックまたはサブブロック中の)変換係数の相対ロケーションを判断する必要がない。さらに、ビデオエンコーダ20は、コンテキストを判断するときにメモリからアクセスされるデータの量を低減させ得る。たとえば、ビデオエンコーダ20は、説明したコンテキスト計算ウィンドウが1つの変換係数から次の変換係数にスライドするとき、1つの新しい変換係数に関連するデータのみを取り出す。さらに、ビデオエンコーダ20は、変換係数を走査するために使用されている走査の方向(たとえば、ジグザグ、対角、水平、垂直など)にかかわらず、コンテキストを判断するために同じ技法を適用し得る。
[0094]いくつかの事例では、ビデオエンコーダ20はまた、(2つ以上の変換係数についての)2つ以上のコンテキストを並行して判断するために本開示の技法を実装し得る。たとえば、上記のように、2つ以上の変換係数を並行して計算するために、サポート中の位置のすべてがコーディングのために利用可能でなければならない。しかしながら、いくつかの事例では、特定のサポート中の1つまたは複数の有効性フラグは、コンテキストを判断するためにサポート中の他の有効性フラグに依存し得る。
[0095]本開示の態様によれば、ビデオエンコーダ20は、並列コンテキスト計算を実行するために上記で説明したスライディングウィンドウ手法を実装し得る。たとえば、ビデオエンコーダ20は、コーディングされている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、ビデオエンコーダ20は、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で1つまたは複数の変換係数をスキップし得る。ビデオエンコーダ20は、上記で説明したコンテキスト依存性を除去するために変換係数間にギャップをもたらし得る。
[0096]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、ビデオエンコーダ20は、2つのコンテキスト(たとえば、コーディングされている変換係数についてのコンテキストおよび走査順序で次の(スキップされる)変換係数)の並行した計算をサポートするために、コーディングされている変換係数とスライディングウィンドウとの間に1つの変換係数のギャップを挿入し得る。別の例では、ビデオエンコーダ20は、3つのコンテキスト(たとえば、コーディングされている変換係数についてのコンテキストおよび走査順序で次の2つの(スキップされる)変換係数)の並行した計算をサポートするために、コーディングされている変換係数とスライディングウィンドウとの間に2つの変換係数のギャップを挿入し得る。ビデオエンコーダ20は、より大きい並列化に適応するためにギャップを増加させ得る。このようにして、ビデオエンコーダ20は、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。
[0097]ビデオデコーダ30は、コード化されたビデオデータを受信すると、ビデオエンコーダ20に関して説明した符号化パスとは概して逆の復号パスを実行し得る。概して逆であるが、ビデオデコーダ30は、場合によっては、ビデオエンコーダ20によって実行される技法と同様の技法を実行し得る。ビデオデコーダ30はまた、ビデオエンコーダ20に関して説明したデータを含む受信ビットストリーム中に含まれているシンタックス要素または他のデータに依拠し得る。
[0098]本開示の態様によれば、たとえば、ビデオデコーダ30は、ビデオエンコーダ20に関して上記で説明したように、係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することによって、ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数を復号し得る。ビデオデコーダ30はまた、コンテキスト導出近傍に基づいて複数の変換係数のうちの1つについてのコンテキストを判断し得る。ビデオデコーダ30は、次いで、判断されたコンテキストに基づいて変換係数のうちの1つを復号し得る。
[0099]本開示の態様は、概して、変換係数についてのコンテキストを判断することに言及するが、変換係数が関連する有効性、レベル、符号などを含み得ることを理解されたい。たとえば、0よりも大きいコーディングレベル、1よりも大きいレベル、2よりも大きいレベルなど、有効性およびレベルをコーディングするために複数の走査パスが使用され得る。一例では、以下の値をコーディングするために5つの異なるシンタックス要素が使用され得る。
0よりも大きいレベルの絶対値、
1よりも大きいレベルの絶対値、
2よりも大きいレベルの絶対値、
3よりも大きいレベルの絶対値、および
符号。
[0100]したがって、本開示のいくつかの態様は、詳細には、変換係数に関連する有効性情報を含む有効性マップをコーディングするためのコンテキストを判断することに関係し得る。もちろん、他のタイプのシンタックス要素および異なる数の走査パスも使用され得る。
[0101]図2は、コンテキストを導出するために本開示の技法を使用し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20について、例示のためにHEVCコーディングのコンテキストにおいて説明するが、変換係数のコンテキスト適応型コーディングを必要とし得る他のコーディング規格または方法に関して限定するものではない。
[0102]ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。
[0103]図2に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照ピクチャメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピーエンコーディングユニット56とを含む。モード選択ユニット40は、今度は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、パーティションユニット48とを含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ(図2に図示せず)も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器62の出力をフィルタ処理することになる。また、デブロッキングフィルタに加えて追加のフィルタ(ループ内またはループ後)が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理し得る。
[0104]符号化プロセス中に、ビデオエンコーダ20はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間圧縮を行うために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対して受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は、代替的に、空間圧縮を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
[0105]さらに、パーティションユニット48は、前のコーディングパスにおける前の区分方式の評価に基づいてビデオデータのブロックをサブブロックに区分し得る。たとえば、パーティションユニット48は、初めにフレームまたはスライスをLCUに区分し、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブCUに区分し得る。モード選択ユニット40は、LCUをサブCUに区分することを示す4分木データ構造をさらに生成し得る。4分木のリーフノードCUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。
[0106]モード選択ユニット40は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの1つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器50に与え、参照フレームとして使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器62に与え得る。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット56に与える。
[0107]動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(または他のコード化ユニット)内でコーディングされている現在のブロックに対する参照フレーム(または他のコード化ユニット)内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。予測ブロックは、絶対値差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。
[0108]いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0109]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライスにおけるビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの参照ピクチャリストの各々は、参照ピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56と動き補償ユニット44とに送る。
[0110]動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット42と動き補償ユニット44とは機能的に統合され得る。現在ビデオブロックのPUについての動きベクトルを受信すると、動き補償ユニット44は、動きベクトルが参照ピクチャリストのうちの1つにおいて指す予測ブロックの位置を特定し得る。加算器50は、以下で説明するように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。
[0111]概して、動き推定ユニット42はルーマ成分に対する動き推定を実行し、動き補償ユニット44はクロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
[0112]イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを判断し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
[0113]たとえば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を判断する。イントラ予測ユニット46は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを判断するために、様々な符号化ブロックのひずみおよびレートから比率を計算し得る。
[0114]ビデオエンコーダ20は、コーディングされている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。
[0115]変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。
[0116]変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
[0117]量子化の後に、エントロピー符号化ユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピーコーディング技法を実行し得る。
[0118]エントロピー符号化ユニット56は、変換係数走査順序に基づくコンテキスト導出近傍を判断するために本開示の技法を実行し得る。たとえば、2値化された変換係数(たとえば、有効性、符号、レベルなど)のビンをエントロピー符号化するためのコンテキストを判断するために位置ベースのサポートを使用するのではなく、エントロピー符号化ユニット56は、変換係数が符号化中に(たとえば、上記で説明した変換処理ユニット52または量子化ユニット54によって)走査される順序に基づくコンテキストを判断するためにサポートを使用し得る。
[0119]このようにして、エントロピー符号化ユニット56は、コンテキスト計算を実行するためにサポートのスライディングウィンドウを使用し得る。たとえば、エントロピー符号化ユニット56が走査順序で連続する変換係数を符号化するとき、エントロピー符号化ユニット56は、コンテキストを判断するために使用されるサポートを走査順序でスライドする。すなわち、符号化されている連続する変換係数ごとに、エントロピー符号化ユニット56は、サポートに変換係数を走査順序で追加する。さらに、エントロピー符号化ユニット56は、サポートから(走査順序に対して)最後の変換係数を除去する。したがって、変換係数が走査順序で走査されるとき、サポートを定義するウィンドウが走査順序に沿ってスライドする。
[0120]エントロピー符号化ユニット56は、走査順序で所定の数(たとえば、3、4、5など)の変換係数を含むコンテキストを計算するためのサポートを判断し得る。いくつかの例では、エントロピー符号化ユニット56は、走査順序で連続する変換係数を有するサポートを判断し得る。
[0121]エントロピー符号化ユニット56は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、エントロピー符号化ユニット56は、いくつかの例では、走査順序に基づかないことがある新しいサポートを用いてブロックまたはサブブロックの1つまたは複数の変換係数についてのコンテキストを計算し始め得る。すなわち、いくつかの例では、エントロピー符号化ユニット56は、ブロック中の1つまたは複数の変換係数についてのコンテキストを計算するために位置ベースのサポートを使用し得、ブロックまたはサブブロック中の1つまたは複数の他の変換係数についてのコンテキストを計算するために走査順序に基づいてサポートを使用し得る。そのような例では、エントロピー符号化ユニット56は、ブロックまたはサブブロックの変換係数をコーディングしながら、サポートに変換係数を追加することによってサポートのスライディングウィンドウに変換係数をポピュレートし得る。
[0122]いくつかの例では、エントロピー符号化ユニット56は、並列コンテキスト計算を実行するために上記で説明したサポートのスライディングウィンドウを実装し得る。たとえば、エントロピー符号化ユニット56は、潜在的なコンテキスト計算依存性を除去するために、現在符号化されている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、エントロピー符号化ユニット56は、現在符号化されている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で1つまたは複数の変換係数をスキップし得る。したがって、エントロピー符号化ユニット56は、現在符号化されている変換係数についてのコンテキストならびにスキップされた変換係数についてのコンテキストを並行して計算し得る。エントロピー符号化ユニット56は、並行して計算されているコンテキストの数に基づいて、符号化されている変換係数とサポートとの間のギャップを調整し得る(たとえば、より大きい並列化に適応するためにギャップを増加する)。
[0123]サポートを判断した後に、エントロピー符号化ユニット56は、サポートを使用して変換係数のビンをコーディングするためのコンテキストを計算し得る。コンテキストを計算した後に、エントロピー符号化ユニット56は、計算されたコンテキストに基づいてビンをコーディングするために、コンテキスト適応型バイナリ算術コーディングを適用し得る。すなわち、エントロピー符号化ユニット56は、判断されたコンテキストに基づいてコンテキストモデルを判断し得、ビンを符号化するためにコンテキストモデルを適用し得る。エントロピー符号化ユニット56によるエントロピーコーディングの後に、符号化ビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。
[0124]逆量子化ユニット58および逆変換ユニット60は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定において使用するためのサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ64に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
[0125]このようにして、図2のビデオエンコーダ20は、係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの1つについてのコンテキストを判断することと、判断されたコンテキストに基づいてそれらの変換係数のうちの1つをコーディングすることとを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするためのプロセスを実行するように構成されたビデオエンコーダの一例を表す。
[0126]図3は、コンテキストを導出するための技法を実装し得るビデオデコーダ30の一例を示すブロック図である。図2に関して上述したように、ビデオデコーダ30は、説明のためにHEVCコーディングのコンテキストで説明したが、本開示の技法は、このようにして限定されず、変換係数のコンテキスト適応型コーディングを必要とし得る他の現在のまたは将来のコーディング規格または方法を用いて実装され得る。
[0127]図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。エントロピー復号ユニット70は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット70は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0128]たとえば、背景として、ビデオデコーダ30は、ネットワークを介した、いわゆる「ネットワークアブストラクションレイヤユニット(network abstraction layer unit)」またはNALユニットへの送信のためにカプセル化された圧縮ビデオデータを受信し得る。各NALユニットは、NALユニットに記憶されるデータのタイプを識別するヘッダを含み得る。一般にNALユニットに記憶されるデータの2つのタイプがある。NALユニットに記憶されるデータの第1のタイプはビデオコーディングレイヤ(VCL:video coding layer)データであり、これは圧縮ビデオデータを含む。NALユニットに記憶されるデータの第2のタイプは非VCLデータと呼ばれ、これは、多数のNALユニットに共通のヘッダデータを定義するパラメータセットなどの追加情報、および補足エンハンスメント情報(SEI:supplemental enhancement information)を含む。たとえば、パラメータセットは、(たとえば、シーケンスパラメータセット(SPS:sequence parameter set)中の)シーケンスレベルヘッダ情報と、(たとえば、ピクチャパラメータセット(PPS)中の)まれに変化するピクチャレベルヘッダ情報とを含み得る。パラメータセット中に含まれている、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、それによりコーディング効率が改善される。さらに、パラメータセットの使用はヘッダ情報の帯域外送信を可能にし、それにより誤り耐性のための冗長送信の必要が回避される。
[0129]いくつかの例では、ビデオデコーダ30は、(新生のHEVC規格またはH.264/AVCなどの)ビデオコーディング規格の所定のプロファイルおよび/またはレベルに準拠し得る。たとえば、ビデオコーディング規格のコンテキストでは、プロファイルは、アルゴリズム、機能、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、H.264規格によって定義される「プロファイル」は、H.264規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびマクロブロック(MB)処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはprofile_idc(プロファイルインジケータ)値でシグナリングされ得、レベルはlevel_idc(レベルインジケータ)値でシグナリングされ得る。
[0130]いずれの場合も、エントロピー復号ユニット70は、受信された量子化変換係数ならびに他のシンタックス要素および/またはシンボルをエントロピー復号し得る。たとえば、エントロピー復号ユニット70は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピーコーディング技法を実行し得る。
[0131]本開示の態様によれば、エントロピー復号ユニット70は、変換係数走査順序に基づくコンテキスト導出近傍を判断するために本開示の技法を実行し得る。たとえば、2値化された変換係数(たとえば、有効性、符号、レベルなど)のビンをエントロピー復号するためのコンテキストを判断するために位置ベースのサポートを使用するのではなく、エントロピー復号ユニット70は、変換係数が復号中に走査(たとえば、逆走査)される順序に基づくコンテキストを判断するためにサポートを使用し得る。
[0132]このようにして、エントロピー復号ユニット70は、コンテキスト計算を実行するためにサポートのスライディングウィンドウを使用し得る。たとえば、エントロピー復号ユニット70が走査順序で連続する変換係数を復号するとき、エントロピー復号ユニット70は、コンテキストを判断するために使用されるサポートを走査順序でスライドする。すなわち、復号されている連続する変換係数ごとに、エントロピー復号ユニット70は、サポートに変換係数を走査順序で追加する。さらに、エントロピー復号ユニット70は、サポートから(走査順序に対して)最後の変換係数を除去する。したがって、変換係数が走査順序で走査されるとき、サポートを定義するウィンドウが走査順序に沿ってスライドする。
[0133]エントロピー復号ユニット70は、走査順序で所定の数(たとえば、3、4、5など)の変換係数を含むコンテキストを計算するためのサポートを判断し得る。いくつかの例では、エントロピー復号ユニット70は、走査順序で連続する変換係数を有するサポートを判断し得る。
[0134]エントロピー復号ユニット70は、各ブロックまたはサブブロックの始めにサポートをリセットし得る。たとえば、エントロピー復号ユニット70は、いくつかの例では、走査順序に基づかないことがある新しいサポートを用いてブロックまたはサブブロックの1つまたは複数の変換係数についてのコンテキストを計算し始め得る。すなわち、いくつかの例では、エントロピー復号ユニット70は、ブロック中の1つまたは複数の変換係数についてのコンテキストを計算するために位置ベースのサポートを使用し得、ブロックまたはサブブロック中の1つまたは複数の他の変換係数についてのコンテキストを計算するために走査順序に基づいてサポートを使用し得る。そのような例では、エントロピー復号ユニット70は、ブロックまたはサブブロックの変換係数をコーディングしながら、サポートに変換係数を追加することによってサポートのスライディングウィンドウに変換係数をポピュレートし得る。
[0135]いくつかの例では、エントロピー復号ユニット70は、並列コンテキスト計算を実行するために上記で説明したスライディングウィンドウ手法を実装し得る。たとえば、エントロピー復号ユニット70は、潜在的なコンテキスト計算依存性を除去するために、現在復号されている変換係数とサポート中に含まれる変換係数のセットとの間にギャップをもたらし得る。すなわち、エントロピー復号ユニット70は、現在復号されている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で1つまたは複数の変換係数をスキップし得る。したがって、エントロピー復号ユニット70は、現在復号されている変換係数についてのコンテキストならびにスキップされた変換係数についてのコンテキストを並行して計算し得る。エントロピー復号ユニット70は、並行して計算されているコンテキストの数に基づいて、復号されている変換係数とサポートとの間のギャップを調整し得る(たとえば、より大きい並列化に適応するためにギャップを増加する)。
[0136]サポートを判断した後に、エントロピー復号ユニット70は、サポートを使用して変換係数のビンをコーディングするためのコンテキストを計算し得る。コンテキストを計算した後に、エントロピー復号ユニット70は、計算されたコンテキストに基づいてビンを復号するために、コンテキスト適応型バイナリ算術コーディングを適用し得る。すなわち、エントロピー復号ユニット70は、判断されたコンテキストに基づいてコンテキストモデルを判断し得、ビンを復号するためにコンテキストモデルを適用し得る。
[0137]ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。
[0138]ビデオフレームがインターコーディングされた(すなわち、B、PまたはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
[0139]動き補償ユニット72は、動きベクトルと他のシンタックス要素とをパースすることによって現在ビデオスライスのビデオブロックのための予測情報を判断し、その予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスの参照ピクチャリストのうちの1つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを判断するために、受信されたシンタックス要素のいくつかを使用する。
[0140]動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。
[0141]逆量子化ユニット76は、ビットストリーム中で与えられ、エントロピー復号ユニット70によって復号された量子化変換係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を判断し、同様に、適用されるべき逆量子化の程度を判断するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ30によって計算される量子化パラメータQPYの使用を含み得る。
[0142]逆変換ユニット78は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。本開示の態様によれば、逆変換ユニット78は、対応する非対称SDIPパーティションと同じサイズ、したがって、互いに異なるサイズを有するTUを使用し得る。他の例では、TUは、それぞれ互いに等しいサイズを有し、したがって、(TUのうちの1つが対応する非対称SDIPパーティションと同じサイズであり得るが)非対称SDIPパーティションのサイズとは潜在的に異なり得る。いくつかの例では、TUは、TUのうちの1つまたは複数が現在のブロックの最小非対称SDIPパーティションより小さいことを示し得る残差4分木(RQT)を使用して表され得る。
[0143]動き補償ユニット72が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、(コーディングループ内またはコーディングループ後の)他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ82に記憶される。参照ピクチャメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。
[0144]このようにして、図3のビデオデコーダ30は、係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することと、コンテキスト導出近傍に基づいて複数の変換係数のうちの1つについてのコンテキストを判断することと、判断されたコンテキストに基づいてそれらの変換係数のうちの1つをコーディングすることとを含むビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするためのプロセスを実行するように構成されたビデオデコーダの一例を表す。
[0145]図4Aおよび図4Bに、概して、ビデオデータのブロックに関連する変換係数のブロックをサブブロックの形態のサブセットに分割することを示す。上記のように、いくつかの例では、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、比較的大きいブロックを処理することに関連するハードウェアおよび/またはソフトウェア要件を低減させるために、図4Aおよび図4Bに示すサブブロック構造を実装し得る。
[0146]図4Aに関して、ビデオコーダは、ブロック120をコーディングしながら、ブロック120をサブブロック122A、122B、122C、および122D(総称してサブブロック122)に分割し得る。図4Aに示す例では、第1のサブブロック122Aは、ブロック120の左上隅に位置する4×4ブロックの変換係数を含み、第2のサブブロック122Bは、ブロック120の左下隅に位置する4×4ブロックの変換係数を含み、第3のサブブロック122Cは、ブロック120の右上隅に位置する4×4ブロックの変換係数を含み、第4のサブブロック122Dは、ブロック120の右下隅に位置する4×4ブロックの変換係数を含む。
[0147]図4Aに関して説明したのと同様の方法で、ビデオデコーダは、ブロック124をコーディングしながら、図4Bのブロック124をサブブロック126A、126B、126C、および126Dに分割し得る。図4Bに示す例では、第1のサブブロック126Aは、ブロック124の右下隅に位置する4×4ブロックの変換係数を含み、第2のサブブロック126Bは、ブロック124の右上隅に位置する4×4ブロックの変換係数を含み、第3のサブブロック126Cは、ブロック124の左下隅に位置する4×4ブロックの変換係数を含み、第4のサブブロック126Dは、ブロック124の左上隅に位置する4×4ブロックの変換係数を含む。
[0148]ビデオコーダは、サブブロック122および126を連続的にコーディングし得る。すなわち、図4Aに関して、ビデオコーダは、別のサブブロックをコーディングする前に、1つのサブブロックのための変換係数(たとえば、有効性、符号およびレベル)に関連するすべての情報をコーディングし得る。この例では、ビデオコーダは、サブブロック122Bをコーディングする前にサブブロック122Aに関連するすべてのビンをコーディングし得る。ビデオコーダは、次いで、サブブロック122Cおよび122Dをコーディングし得る。同様に、図4Bに関して、ビデオコーダは、サブブロック126Bと、サブブロック126Cと、サブブロック126Dとをコーディングする前にサブブロック126Aに関連するすべてのビンをコーディングし得る。
[0149]他の例では、ビデオコーダは、別のビンをコーディングする前に、ブロック120および124全体についてのデータの各ビンをコーディングし得る。たとえば、図4Aに関して、ビデオコーダは、サブブロック122の各々のための有効性マップをコーディングし得る。ビデオコーダは、次いで、サブブロック122の各々のための変換係数レベルの各ビンをコーディングし、以下同様に行い得る。同様に、図4Bに関して、ビデオコーダは、サブブロック126の各々のための有効性マップをコーディングし、その後、サブブロック126の各々のための変換係数レベルをコーディングし、以下同様に行い得る。
[0150]いくつかの例では、ビデオコーダは、変換係数を走査するために統一された走査を使用し得る。たとえば、図4Aに関して、ビデオコーダは、同じ対角走査を使用して変換係数の有効性マップと係数レベルとをコーディングし得る。他の例では、ビデオコーダは、異なる方向を有する走査を使用して変換係数(たとえば、有効性、符号、レベルなど)の異なるビンをコーディングし得る。たとえば、ビデオコーダは、順方向の対角、垂直、水平、またはジグザグ走査を使用することによって、各方形(または矩形)8×8ブロックおよびそれ以上の変換係数レベルマップの絶対値を4×4サブブロックの順序セット(たとえば、ベクトル)上にマッピングし得る。ビデオコーダは、次いで、順方向走査と反対の方向を有する逆方向の対角、垂直、水平、またはジグザグ走査を使用して各4×4サブブロック内の変換係数レベルをコーディングし得る。図4Bに示す逆方向(または逆)走査を容易にするために、ビデオコーダは、最初に、ブロック124の最後有効係数を識別し得る。最後有効係数を識別した後に、ビデオコーダは、図4Bに示す走査を適用し得る。
[0151]したがって、4×4ブロックごとに、ビデオコーダは、coded_sub_block_flagをコーディングし得、サブブロック中に少なくとも1つの非ゼロ係数がある場合、このフラグは1に設定され、それ以外の場合、フラグは0に等しくなる。coded_sub_block_flagが非ゼロである場合、ビデオコーダは、各4×4サブブロックを走査し、係数の有効性ならびに変換係数レベルを示す係数ごとにsignificant_coeff_flagをコーディングし得る。明示的シグナリングの代わりに、隣接する4×4サブブロックフラグを使用してまたは4×4ブロックが最後の係数またはDCを含んでいる場合、coded_sub_block_flagが暗黙的に導出され得る。
[0152]本開示の態様によれば、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、変換係数走査順序に基づくコンテキスト導出近傍を使用して、サブブロック122および126の変換係数をコンテキスト適応的にコーディングし得る。たとえば、ビデオコーダは、走査順序で前にコーディングされた変換係数のスライディングウィンドウを含むコンテキストを計算するためにサポートを使用し得る。ビデオコーダは、コーディングされているサブブロック122および126中の特定の変換係数のロケーションにかかわらず、同様の方法でサポートを判断し得る。
[0153]たとえば、図4Aに関して、ビデオコーダは、そのうちのいくつかがサブブロック122Aに位置し得る前の5つの変換係数を走査順序で含むサポートを使用して、サブブロック122Bの変換係数をコンテキスト適応的にコーディングするためのコンテキストを計算し得る。同様に、図4Bに関して、ビデオコーダは、そのうちのいくつかがサブブロック126Bに位置し得る前の5つの変換係数を走査順序で含むサポートを使用して、サブブロック126Cの変換係数をコンテキスト適応的にコーディングするためのコンテキストを計算し得る。
[0154]本開示の技法は、コンテキストコーディングに関連するデータアクセス要件を低減させ得る。たとえば、コンテキスト導出近傍を判断するためにスライディングウィンドウを使用すると、ビデオコーダは、変換係数についてのコンテキストを判断するためにサブブロック122または126中の変換係数の相対ロケーションを判断する必要がない。さらに、ビデオコーダは、説明したコンテキスト計算ウィンドウが1つの変換係数から次の変換係数にスライドするとき、1つの新しい変換係数に関連するデータのみを取り出す。
[0155]上記のように、ビデオコーダは、変換係数を走査するために使用されている走査の方向(たとえば、ジグザグ、対角、水平、垂直など)にかかわらず、サポートのスライディングウィンドウを使用してコンテキストを判断するために同じ技法を適用し得る。したがって、図4Aおよび図4Bに示す例では、概して、対角走査パターンを示すが、本技法はまた、ジグザグパターン、適応型走査順序、水平パターン、垂直パターンなどを含む様々な他の走査パターンに適用可能である。
[0156]さらに、図4Aおよび図4Bに示す例では、4×4サブブロックをもつ8×8ブロックの変換係数を示すが、本開示の技法は、他のサイズのブロック、ならびに他のサイズのサブブロックに適用され得ることを理解されたい。たとえば、上記で説明したコンテキスト導出のためのスライディングウィンドウはまた、水平方向の走査または垂直方向の走査のためにそれぞれ使用され得る2×8および/または8×2の矩形サブブロックのために使用され得る。そのような例では、初期サポートは、位置ベースのサポートであるか、または走査順序ベースのサポートであり得る。
[0157]ビデオコーダがフレーム(またはスライス)のすべてのTUに同じサブブロックサイズを使用する場合、そのサブブロックサイズを用いて得られる均一性によって、ハードウェアの実装形態において利益が得られ得る。しかしながら、均一なサブブロックサイズは、本開示の技法を実行するために必須ではない。
[0158]図5に、概して、コンテキストを計算するためのコンテキスト導出近傍を示す。たとえば、図5に、概して、コンテキスト導出近傍132A、132B、132C、132D、および132E(総称して、サポート132)から導出されたコンテキストを使用して現在のまたは「ターゲット」の変換係数130をコーディングすることを示す。一例では、式(1)に関して上述したように、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、サポート132のあらゆる位置における有効性フラグの和に基づいてコンテキストCtxを判断し得、ただし、対応する変換係数が非ゼロである場合、有効性フラグは「1」である。図5に、第2のコンテキスト導出近傍136A、136B、136C、136D、および136E(総称して、サポート136)を有する第2の変換係数134をも示す。
[0159]コンテキストを計算するためにサポート132を使用するために、ビデオコーダは、位置132A、132B、132C、132D、および132Eにおける変換係数の各々に関連する値を判断し得る。係数ごとに5つの異なるロケーションに関連する値を判断することは比較的計算集約的であり得る。さらに、ビデオコーダは、位置132A、132B、132C、132D、および132Eにおける変換係数が変換係数130と同じブロック内に位置するかどうかを識別し得る。そのブロックの外部の位置に関連する値は、より長いデータアクセス時間を必要とし得るか、または他の値に置換され得る。
[0160]さらに、第2の変換係数134がターゲット変換係数130に走査順序で続くが、サポート132および136は重複しない。したがって、サポート132および136を使用してコンテキストを計算するデータアクセス要件は比較的高くなり得る。たとえば、ターゲット変換係数130の直後に第2のターゲット変換係数134が走査順序で続く。ただし、サポート132は、サポート136とは完全に異なる変換係数のセットを含む。したがって、ビデオコーダは、2つの連続する変換係数をコーディングするためのコンテキストを計算するために、10個の変換係数に関連するデータを取り出さなければならない。
[0161]本開示の態様によれば、ビデオコーダは、(変換係数130および134などの)変換係数をコーディングするためのコンテキストを判断するために走査順序ベースのサポートを使用し得る。したがって、図7Aおよび図7Bに関してより詳細に説明するように、ビデオコーダは、同じ変換係数のうちの1つまたは複数を有するサポートを使用して変換係数130および134についてのコンテキストを判断し得る。したがって、本技法は、位置ベースのサポート132および136に関して上記で説明した計算およびデータアクセス費用を低減させ得る。
[0162]図6に、概して、2つ以上のコンテキストを並行して計算するためのロケーションベースのコンテキスト導出近傍を示す。図6に示した例では、現在のまたは「ターゲット」の変換係数140は、サポート142A、142B、142C、および142D(総称して、サポート142)から導出されたコンテキストを使用してコーディングされ得る。さらに、コンテキスト依存性を解決するために、穴144がサポートにもたらされる。
[0163]たとえば、(図5に示すサポート132など)穴144を含むサポートは、コンテキストを計算するときにサポート中のすべてのデータが利用可能でなければならない(たとえば、すでにコーディングされていなければならない)ので、ブロックのいくつかのロケーションにおいて2つ以上の有効性フラグについてのコンテキストを並行して計算するビデオコーダ(ビデオエンコーダ20またはビデオデコーダ30など)の能力を妨げ得る。すなわち、特定の位置のための有効性コンテキストを計算するために、サポート内のすべての位置の有効性フラグをパースすることが必要であり得る。有効性フラグは走査順序で互いに隣接して配置され得るので、2つの係数の有効性コンテキストを並行して計算するという要件がある場合、そのような解析は遅延をもたらし得る。
[0164]説明のための一例では、ビデオコーダは、走査順序で前の位置における変換係数、すなわち、穴144の位置における変換係数を用いて、ターゲットの変換係数140をコーディングするためのコンテキストを並行して計算しようと試み得る。ただし、この例では、ターゲットの変換係数が穴144における変換係数の値に依存することになるので、ビデオコーダは、ターゲットの変換係数140についてのコンテキストを判断する前にコーディングを完了するために、穴144の位置における変換係数を待たなければならない。すなわち、穴144における変換係数の値は、値が、たとえば、式(1)に示すコンテキストモデル合計において使用されることができるようになる前に知られていなければならない(コーディングされていなければならない)。このコンテキスト依存性に関連する遅延は、コンテキストを効率的に並行して計算するビデオコーダの能力を低減させる。
[0165]したがって、位置ベースのサポートを使用する(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、サポート142からの位置を除去するためにサポート142に穴144をもたらし得る。この例では、穴144に関連する変換係数は、スキップされ、コンテキスト計算では考慮に入れられず(すなわち、0であると仮定され)、それによって、コンテキスト依存性を除去し得る。サポートにいわゆる穴をもたらす技法は、2013年1月10日に出願の米国特許出願第13/738,565号に記載されている。
[0166]しかしながら、並列コンテキスト計算で位置ベースのサポートに穴をもたらすことは、コンテキスト判断プロセスに複雑さをもたらし得る。たとえば、上記のように、ビデオコーダは、適切なサポートを選択するためにコーディングされている変換係数のロケーションならびに並行して計算されているコンテキストの数を判断する必要があり得る。より高度の並列化を実装すると、追加の複雑さが追加され得る。たとえば、2つのビンCABAC並列化(たとえば、2つのコンテキストを並行して計算すること)では、ビデオコーダが各4×4サブブロック中の2つの位置のためのサポートを変更する必要があり得る。並列化を増加させることはまた、必要とされる穴をもつ異なるサポートの数を増加させ得る。
[0167]本開示の態様によれば、ビデオコーダは、コンテキスト導出のためにスライディングウィンドウを使用して、並列コンテキスト計算を実行し得る。たとえば、ビデオコーダは、走査順序で、コーディングされている変換係数とサポートの変換係数のセットとの間にギャップをもたらし得る。すなわち、ビデオコーダは、コーディングされている変換係数とサポートを定義するスライディングウィンドウ中の変換係数との間で1つまたは複数の変換係数をスキップし得る。コーディングされている変換係数とサポートの変換係数との間のギャップは、上記で説明したコンテキスト依存性を除去し得る。
[0168]本開示の態様によれば、コーディングされている変換係数と関連するサポートとの間のギャップ中の変換係数の数は、追加の並列コンテキスト計算に適応するために増加され得る。たとえば、2つの変換係数のギャップにより3つのコンテキストを並行して計算することが可能になり得る。したがって、ビデオコーダは、並行して計算されているコンテキストの数に従って特殊な位置ベースのサポートを判断する必要がない。
[0169]図7Aおよび図7Bは、本開示の態様による、走査順序に基づく例示的なコンテキスト導出近傍スライディングウィンドウを示す図である。図7Aの例は、サブブロック154A〜154D(総称して、サブブロック154)を有する変換係数のブロック150と、サブブロック154Aの第1の変換係数158(変換係数15)と、第1の変換係数158についてのコンテキストを判断するための初期コンテキスト導出近傍(サポート)162とを含む。概して、サブブロック154Aの番号(0〜15)は、図6に示した走査順序などの逆対角走査順序に対応する。すなわち、ビデオコーダは、第1の変換係数158(変換係数15)から変換係数0まで順々にサブブロック154Aの変換係数を走査し得る。
[0170]本開示の態様によれば、ビデオコーダは、サブブロック154Aの変換係数0〜15をコーディングするためのコンテキストを判断するために、1つまたは複数の位置ベースのサポートと走査順序ベースのサポートとの組合せを使用し得る。たとえば、ビデオコーダは、第1の変換係数158(変換係数15)についてのコンテキストを判断するために初期サポート162を使用し得る。初期サポート162は、位置ベースであり得る。すなわち、ビデオコーダは、第1の変換係数158に対する初期サポート162中に含まれる変換係数の相対位置に基づいて初期サポート162を選択し得る。
[0171]サブブロック154Aの残りの変換係数についてのコンテキストを判断するために、ビデオコーダは、サポートのスライディングウィンドウをポピュレートし得る。たとえば、概して、ビデオコーダは、たとえば、n+iからn+jまでの前に走査された係数に依存するサポートを使用して、所与の位置nにおける変換係数についてのコンテキストを計算し得、ただし、iはjの前にコーディングされる。サポートに5つの変換係数が使用されると仮定すると、ビデオコーダは、前に走査された係数n+1〜n+5に依存するサポートを使用して、所与の位置nにおける変換係数についてのコンテキストを計算し得る。したがって、変換係数が走査順序位置nを有する場合、コンテキスト導出近傍は、走査順序位置n+1〜n+5における変換係数を備え得る。図7Aおよび図7Bの例では、n+5が15以下に等しいとき、コンテキストを判断するためのサポートは走査順序にのみ依存する。すなわち、図7Bに関して以下でより詳細に説明するように、ビデオコーダは、第1の5つの変換係数(変換係数15〜11)についてのコンテキストを計算するための初期サポート162からの少なくとも1つの変換係数を含み得る。ただし、ビデオコーダが各連続する変換係数についてのコンテキストを計算するとき、ビデオコーダは、サポートのスライディングウィンドウに変換係数を走査順序でポピュレートし、サポートのスライディングウィンドウの相対終端から初期サポート162からの変換係数のうちの1つを除去する。
[0172]たとえば、上記の5ポイントのサポートを仮定すると、ビデオコーダは、初期サポート162からの4つの変換係数と走査順序からの1つの変換係数(変換係数15)とを使用して、サブブロック154Aの走査順序で第2の変換係数についてのコンテキストを判断し得る。同様に、ビデオコーダは、初期サポート162からの3つの変換係数と走査順序からの2つの変換係数(変換係数14および15)とを使用して、サブブロック154Aの走査順序で第3の変換係数についてのコンテキストを判断し、スライディングウィンドウが完全にポピュレートされるまで以下同様に行い得る。
[0173]いくつかの例では、ビデオコーダは、各ブロックまたはサブブロックをコーディングした後にサポートをリセットし得る。たとえば、(上記で説明した逆方向走査を仮定して)サブブロック154Cをコーディングした後、ビデオコーダは、サブブロック154Aをコーディングする前にサポートをリセットし得る。ビデオコーダは、初期サポート(初期サポート162など)を判断することによって、位置ベースであり得るサポートをリセットし得る。したがって、サブブロックの始端における、すなわち、サブブロック中の第1の係数のための初期ウィンドウは、図5に示した近傍などの従来のコンテキスト近傍を使用し得る。
[0174]図7Bに、より詳細にコンテキスト導出近傍スライディングウィンドウを示す。たとえば、図7Bに、図7Aに示した同様に番号付けされた変換係数に対応する変換係数164A〜164Nの列を示す。列164Aに、初期サポート162を用いて第1の変換係数158をコーディングすることを示す。各連続する列164B〜164Nに、連続する変換係数コーディング演算を示す。すなわち、列164Bに、サブブロック154Aの走査順序で第2の変換係数168(変換係数14)をコーディングすることを示す。さらに、列164Cに、サブブロック154Aの走査順序で第3の変換係数170(変換係数13)をコーディングすることを示し、列164Nに、サブブロック154Aの走査順序で最終変換係数172(変換係数0)をコーディングすることを示す。
[0175]図7Bに示すように、スライディングウィンドウ176は、たとえば、適用可能な場合、エントロピーコーディングユニット56またはエントロピー復号ユニット70によるCABACのための有効性コーディングまたはレベルコーディングのために、それぞれの列164A〜164Nの変換係数についてのコンテキストを計算するためのサポートを定義する。たとえば、図7Aに関して上述したように、ビデオコーダは、初期サポート162を使用して初期変換係数158についてのコンテキストを計算する。次に、列164Bによって示されるように、ビデオコーダは、第2の変換係数168を処理し、変換係数15〜19を含むサポートを判断する。すなわち、ビデオコーダは、サポート中に変換係数15(前にコーディングされた変換係数)を含めるとともに、サポートから変換係数20を除去しもするために、スライディングウィンドウ176を1つの位置だけ移動する。
[0176]同様に、列164Cによって示されるように、ビデオコーダは、第3の変換係数170を処理し、変換係数14〜18を含むサポートを判断する。すなわち、ビデオコーダは、サポート中に変換係数14(前にコーディングされた変換係数)を含めるとともに、サポートから変換係数190を除去しもするために、スライディングウィンドウ176を1つの位置だけ移動する。ビデオコーダは、ブロック全体がコーディングされるまで、このようにサブブロック154Aの変換係数をコーディングし続け得る。たとえば、列164Nによって示されるように、ビデオコーダは、最終変換係数172を処理し、変換係数1〜5を含むサポートを判断する。
[0177]変換係数位置n+5が15よりも小さいとき、スライディングウィンドウ176によって定義されるサポートは、走査順序にのみ依存し、(走査順序による以外の形で、たとえば、空間ネイバー位置に基づいて選択され得る)初期サポート162の変換係数を含まない。すなわち、図7Bに示した例では、変換係数11をコーディングした後に、スライディングウィンドウ176は、走査順序にのみ基づいて変換係数(変換係数11〜15)を含む。
[0178]このようにして、本開示の技法は、変換係数をコーディングするためのサポートを定義するためにスライディングウィンドウを使用することを含む。本開示の技法は、他のコンテキスト計算方式と比較して、コンテキストのより容易な計算を提供し得る。たとえば、ビデオコーダはコーディングされている連続する変換係数ごとに1つの新しい変換係数に関連するデータしか取り出さないので、データアクセス要件を低減する。さらに、ビデオコーダは、コーディングされている変換係数の特定のロケーションまたは走査の方向に基づいてサポートが定義される方法を変更しない。
[0179]さらに、ビデオコーダはまた、相対的に低い計算コストでコンテキストコーディングするためのサポートのサイズを増加させ得る。たとえば、サポートの1−Dベクトルのサイズが増加するにもかかわらず、走査順序での各変換係数位置においてサポート中で1つの新しい変換係数しか考慮されないので、コンテキストごとの計算は同様である。このようにして、サポート中に含まれる変換係数の数は、比較的低い計算コストで5からより大きい数に増加され得る。対照的に、(たとえば、位置ベースのサポートの場合のように)2次元ロケーションに基づいてサポート中の変換係数の数を増加させることは、確認される条件の数およびメモリアクセス要件のために、コストの比較的著しい増加を必要とする。
[0180]したがって、図7Aおよび図7Bに示す例に、概して、5つの値を含むサポートを示すが、他の例では、サポートは、本開示の技法から逸脱することなく、5よりもより多いまたは5よりも少ない値を含み得る。図7Aおよび図7Bに示すデータは、処理の速度を上げるために1−D順序で記憶され、処理され得る。上記のように、コンテキストを判断するために位置ベースのサポートと走査順序ベースのサポートとの組合せが使用され得るが、別の例は、厳密な走査順序ベースの手法を含み得る。そのような例では、ビデオコーダは、初期サポートにあらかじめ定義された値をポピュレートし得る。
[0181]図8は、本開示の態様による、走査順序に基づき、2つのビンについてのコンテキストの並行した導出をサポートする例示的なコンテキスト導出近傍スライディングウィンドウを示す図である。たとえば、図8は、変換係数200のブロックと、第1の変換係数202(変換係数15)と、第1の変換係数202についてのコンテキストを判断するための初期コンテキスト導出近傍(サポート)206(影付きの変換係数17〜21)とを含む。概して、変換係数の番号(0〜15)は、図7Aおよび図7Bに関して上記で説明したように、逆対角走査順序に対応する。
[0182]さらに、図8は、ブロック200の同様に番号付けされた変換係数に対応する変換係数210Aおよび210Bの列を含む。列210Aに、初期サポート206を用いて第1の変換係数202をコーディングすることを示す。列210Bに、ブロック200の走査順序で第2の変換係数214(変換係数14)をコーディングすることを示す。
[0183]スライディングウィンドウ218は、たとえば、適用可能な場合、エントロピーコーディングユニット56またはエントロピー復号ユニット70によるCABACのための有効性コーディングまたはレベルコーディングのために、それぞれの列210Aおよび210Bの変換係数についてのコンテキストを計算するためのサポートを定義する。たとえば、ビデオコーダは、変換係数17〜21を含む初期サポート206を使用して第1の変換係数202についてのコンテキストを計算する。次に、列210Bによって示されるように、ビデオコーダは、第2の変換係数214を処理し、変換係数16〜20を含むサポートを判断する。すなわち、ビデオコーダは、サポート中に変換係数16(前にコーディングされた変換係数)を含めるとともに、サポートから変換係数21を除去しもするために、スライディングウィンドウ218を1つの位置だけ移動する。
[0184]本開示の態様によれば、ビデオコーダは、コンテキスト依存性を除去するために、コーディングされている変換係数とスライディングウィンドウ218との間にギャップ222を挿入し得る。たとえば、図8に、2つのビンの並列コンテキスト計算のための構成を示す。すなわち、ギャップ222を導入することによって、ビデオコーダは、走査順序で前の変換係数に関するコンテキスト依存性を除去する。したがって、(スライディングウィンドウ218によって定義された)第2の変換係数214のためのサポートは第1の変換係数202に依存しないので、ビデオコーダは、たとえば、第1の変換係数202と並行して第2の変換係数214をコーディングするためのコンテキストを計算し得る。
[0185]したがって、図8に示すように、2つのビン並列化では、現在の変換係数をコーディングするためのサポートは、走査順序で前にコーディングされた変換係数を含まない。ビデオコーダは、ギャップ222を調整することによって並行して計算され得るコンテキストの数を調整し得る。たとえば、3つのビン並列化では、現在の変換係数をコーディングするためのサポートは、走査順序で前の2つの変換係数を含まない。すなわち、ビデオコーダは、1つの変換係数から2つの変換係数にギャップ222の幅を増加させ得る。したがって、ビデオコーダは、現在の変換係数ならびに走査順序で前の2つの変換係数(ギャップ222に関連する変換係数)についてのコンテキストを並行して計算し得る。並列コンテキスト計算能力は、ギャップ222中の変換係数の数を増加させることによって追加され得る。
[0186]このようにして、本開示の態様によれば、ビデオコーダは、並列コンテキスト計算を実行するときに、変換係数位置ごとに特殊なサポートを定義する必要がない。さらに、並行して計算されるコンテキストの数を増加させるときに、サポート導出に関連する追加の計算負担がない。
[0187]図9は、本開示の態様による、例示的な初期コンテキスト導出近傍を示す概念図である。いくつかの例では、以下でより詳細に説明するように、図9に示す初期コンテキスト導出近傍は、コンテキストコーディングに関連するメモリ使用量を最小化し得る。
[0188]図9の例は、サブブロック240A〜240D(総称して、サブブロック240)を有する変換係数のブロック238と、サブブロック240Aの第1の変換係数242(変換係数15)と、第1の変換係数242についてのコンテキストを判断するための初期コンテキスト導出近傍(サポート)244(影付きの変換係数16〜20)とを含む。概して、サブブロック240Aの番号(0〜15)は、図6に示した走査順序などの逆対角走査順序に対応する。すなわち、ビデオコーダは、第1の変換係数242(変換係数15)から変換係数0まで順々にサブブロック240Aの変換係数を走査し得る。
[0189]初期サポート244は、コンテキストコーディングのために(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダによって記憶されるデータの量を最小化し得る。たとえば、図9に示すように、初期サポート244は、周囲のサブブロック240B〜240Dの1行および1列だけからの位置に位置する変換係数を含む。したがって、ビデオコーダは、コンテキスト導出のために周囲のサブブロック240B〜240Dの1行および1列からのデータのみを記憶する。
[0190]このようにして、ビデオコーダは、より多くの行および列にある位置を有するコンテキスト導出近傍を使用することと比較したときメモリの節約を実現し得る。たとえば、図5に示したサポート132および136は、周囲の変換係数の2行および2列にある位置を含む。そのようなサポート132および136は、コンテキスト導出のために、両方の行および両方の列からのデータを記憶する必要がある。したがって、1行および1列だけのデータしか記憶する必要がないので、初期サポート244はメモリ要件が低減する。
[0191]図9の初期サポート244は、一例として与えたものにすぎない。他の例では、ビデオコーダは、メモリ消費量をさらに低減させるために、初期サポートが導出されるロケーションをさらに制限し得る。
[0192]図10は、本開示の態様による、走査順序に基づくコンテキスト導出近傍を使用して変換係数をコーディングする技法を示す流れ図である。図10に示す例は、概して、ビデオコーダによって実行されるものとして説明する。いくつかの例では、図10の方法は、ビデオエンコーダ20(図1および図2)、ビデオデコーダ(図1および図3)、または様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコーディングユニットなどによって行われ得ることを理解されたい。
[0193]さらに、図10では、概して、変換係数に関して説明するが、データの複数のビンを有する2値化された変換係数をコーディングするために、図10(ならびに本開示の他の場所)に関して説明する技法が適用され得ることを理解されたい。したがって、上記で説明したように、変換係数のコンテキストコーディングされたビンのすべてがコーディングされるまで、本技法が再帰的に実行され得る。さらに、図10ではコンテキストコーディングに関して説明するが、変換係数の1つまたは複数のビンは上記で説明したように、バイパスコーディングされ得ることを理解されたい。
[0194]図10の例では、ビデオコーダは、走査順序に基づく変換係数をコーディングするためのコンテキスト導出近傍(サポート)を定義する(260)。たとえば、本開示の態様によれば、ビデオコーダは、サポートを判断するためにスライディングウィンドウを使用し得る。スライディングウィンドウは、現在コーディングされている変換係数に前にコーディングされた変換係数の所定のセットを走査順序で含み得る。すなわち、ブロックまたはサブブロック中の位置(n)を有する現在コーディングされている変換係数について、スライディングウィンドウは、位置(n+1)〜(n+m)中に変換係数を含み得、ただし、mは、非ゼロ整数であり、位置(n)中の変換係数は、位置(n+1)〜(n+m)中の変換係数の後にコーディングされる。
[0195]ビデオコーダは、次いで、変換係数をコーディングするためのコンテキストを判断し得る(262)。上記のように、ビデオコーダは、サポートの位置中の有効性フラグの和を判断することによって、一例では、有効性フラグをコーディングするためのコンテキストを計算し得る。ビデオコーダが2つ以上の変換係数についてのコンテキストを並行して計算する例では、ビデオコーダはまた、現在の変換係数フラグについてのコンテキストを用いて他の変換係数についてのコンテキストを並行して計算し得る。本開示の態様によれば、ビデオコーダは、図8に関して上記で説明したように、そのような並列コンテキスト計算を可能にするために、コーディングされている変換係数とサポートとの間にギャップを挿入し得る。
[0196]ビデオコーダはまた、判断されたコンテキストに基づいて変換係数をコーディングする(264)。たとえば、ビデオコーダは、変換係数をCABACコーディングし得る。したがって、ビデオコーダは、変換係数をエントロピーコーディングするためのコンテキストモデルを識別するために、判断されたコンテキストを使用し得る。(ビデオエンコーダ20などの)ビデオエンコーダにおいて、ビデオエンコーダは、変換係数をエントロピー符号化するためにそのコンテキストモデルを使用し、それによって、符号化ビットストリーム中に変換係数の関係するビンの値の指示を含め得る。(ビデオデコーダ30などの)ビデオデコーダにおいて、ビデオデコーダは、変換係数のビンをエントロピー復号するためにそのコンテキストモデルを使用し、それによって、符号化ビットストリームからビンをパースし得る。
[0197]図11は、本開示の態様による、走査順序に基づくコンテキスト導出近傍を使用して変換係数をコーディングする技法を示す流れ図である。図11に示す例は、概して、ビデオコーダによって実行されるものとして説明する。いくつかの例では、図11の方法は、ビデオエンコーダ20(図1および図2)、ビデオデコーダ(図1および図3)、または様々な他のプロセッサ、処理ユニット、エンコーダ/デコーダ(コーデック)などのハードウェアベースのコーディングユニットなどによって行われ得ることを理解されたい。
[0198]図11の例では、ビデオコーダは、現在コーディングされているビンがビデオデータのブロックまたはサブブロック中の初期変換係数位置に関連付けられるかどうかを判断する(282)。すなわち、ビデオコーダは、現在コーディングされているビンがビデオデータのブロックまたはサブブロック中で走査されている第1の変換係数に関連付けられるかどうかを判断し得る。
[0199]ビンが初期変換係数に関連付けられない場合、ビデオコーダは、走査順序に少なくとも部分的に基づくビンをコーディングするためのコンテキスト導出近傍(サポート)を定義する(284)。たとえば、本開示の態様によれば、ビデオコーダは、初期変換係数以外の変換係数のビンをコーディングするためのサポートを判断するためにスライディングウィンドウを使用し得る。上記のように、スライディングウィンドウは、現在コーディングされている変換係数に前にコーディングされた変換係数の所定のセット(ならびに、いくつかの例では、初期の所定のサポートからの1つまたは複数の変換係数)を走査順序で含み得る。すなわち、ビデオコーダは、初期の所定のサポートから変換係数を除去しもしながら、1つの変換係数ずつスライディングウィンドウに変換係数を走査順序でポピュレートし得る。
[0200]ビデオコーダは、次いで、ビンをコーディングするためのコンテキストを判断し得る(286)。上記のように、ビデオコーダは、サポートの位置中の有効性フラグの和を判断することによって、一例では、有効性フラグをコーディングするためのコンテキストを計算し得る。
[0201]コーディングされているビンがブロックまたはサブブロック中の初期変換係数に関連付けられる場合、ビデオコーダは、ビンをコーディングするために所定の、位置ベースのサポートを使用し得る(288)。たとえば、ビデオコーダは、コーディングされている変換係数の相対ロケーションに対して所定のロケーション中に所定の数の変換係数を含むサポートを使用し得る。いくつかの例では、この初期サポートは、図9に関して上記で説明したように、所定のサポートのために記憶されるデータの量を最小化するように形成され得る。ビデオコーダは、次いで、ビンをコーディングするためのコンテキストを判断し得る(286)。
[0202]ビデオコーダはまた、判断されたコンテキストに基づいてビンをコーディングする(290)。たとえば、ビデオコーダは、変換係数をCABACコーディングし得る。したがって、ビデオコーダは、ビンをエントロピーコーディングするためのコンテキストモデルを識別するために、判断されたコンテキストを使用し得る。(ビデオエンコーダ20などの)ビデオエンコーダにおいて、ビデオエンコーダは、ビンをエントロピー符号化するためにそのコンテキストモデルを使用し、それによって、符号化ビットストリーム中にビンの値の指示を含め得る。(ビデオデコーダ30などの)ビデオデコーダにおいて、ビデオデコーダは、ビンをエントロピー復号するためにそのコンテキストモデルを使用し、それによって、符号化ビットストリームからビンをパースし得る。さらに、ビンは、変換係数の最終ビンである場合、ビデオデコーダはビンに関連する変換係数の値を判断するためにビンを2値化(再構成)し得る。
[0203]ビデオコーダはまた、コーディングされたビンが、変換係数のブロックまたはサブブロックの最終変換係数の最終ビンであったかどうかを判断し得る(292)。コーディングされたビンが、ブロックまたはサブブロック中の最終変換係数の最終ビンでなかった場合、ビデオコーダは、コーディングされている次のビンが、ブロックまたはサブブロック中の初期変換係数位置に関連付けられるかどうかを判断することに戻り得る(282)。コーディングされている次のビンが、ブロックまたはサブブロック中の初期変換係数位置に関連付けられる場合、ビデオコーダは、ステップ288に関して上記で説明した所定のサポートを使用してサポートをリセットし得る。コーディングされたビンが、ブロックまたはサブブロック中の最終変換係数の最終ビンであった場合、ビデオコーダは、変換係数の次のブロックまたはサブブロックに移動し得る(294)。
[0204]本開示のいくつかの態様について、説明のために開発中のHEVC規格に関して説明した。ただし、本開示で説明する技法は、H.264または他の規格に従って定義されるビデオコーディングプロセスあるいはまだ開発されていないプロプライエタリビデオコーディングプロセスなど、他のビデオコーディングプロセスのために有用であり得る。
[0205]さらに、上記のいくつかの例について、変換係数(たとえば、符号、有効性、レベルなど)をコーディングすることに関して説明したが、本開示の態様は、他の値またはシンボルに関連するビンをコーディングすることに適用され得る。たとえば、サポートのセットを判断するための技法は、変換係数ならびに他のシンボルに関連するビンを含む、様々なビンをコーディングするための様々なコンテキスト適応型エントロピーコーディング方式に適用され得る。
[0206]さらに、初期5ポイントサポートへの言及は例として与えたものである。5つよりも多いまたは5つよりも少ない要素を有する他のサポートも、本明細書で説明する技法に従って使用され得る。
[0207]ビデオコーダは、本開示で説明するように、(たとえば、ビデオエンコーダ20またはビデオデコーダ30などの)ビデオエンコーダまたはビデオデコーダを指すことがある。同様に、ビデオコーディングユニットは、ビデオエンコーダまたはビデオデコーダを指すことがある。同様に、ビデオコーディングはビデオ符号化またはビデオ復号を指すことがある。
[0208]例によっては、本明細書で説明した技法のうちいずれかの、いくつかの作用またはイベントは、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る(たとえば、すべての説明した作用またはイベントが、本技法の実施のために必要であるとは限らない)ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、同時に実行され得る。
[0209]1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
[0210]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
[0211]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)などの1つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明した技法の実装に好適な他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素中に十分に実装され得る。
[0212]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明した1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
[0213]様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングする方法であって、
変換係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記1つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記1つをコーディングすることと
を備える、方法。
[C2]
前記コンテキスト導出近傍を定義することが、前記変換係数走査順序で前記複数の変換係数のうちの前記1つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを備える、C1に記載の方法。
[C3]
前記スライディングウィンドウが前記複数の変換係数のうちの前記1つを含むように、前記複数の変換係数のうちの前記1つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で1つの位置だけ移動することをさらに備える、C2に記載の方法。
[C4]
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、C2に記載の方法。
[C5]
前記複数の変換係数のうちの前記1つが、走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+i〜n+jにおける変換係数を備え、走査順序位置nが、走査順序位置n+i〜n+jの後に走査され、走査順序位置n+jが、走査順序位置n+iの後に走査される、C2に記載の方法。
[C6]
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、C1に記載の方法。
[C7]
前記複数の変換係数のうちの前記1つのための前記コンテキスト導出近傍を定義することが、前記変換係数のうちの前記1つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも1つの変換係数のギャップを含めることを備える、C1に記載の方法。
[C8]
前記変換係数が走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+2〜n+6における変換係数を備え、走査順序位置nが、走査順序位置n+2〜n+6の後に走査される、C7に記載の方法。
[C9]
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
をさらに備える、C1に記載の方法。
[C10]
前記コンテキストが、CABACコンテキストであり、コーディングすることが、CABACプロセスを使用して前記複数の変換係数のうちの前記1つをコーディングすることを備える、C1に記載の方法。
[C11]
前記複数の変換係数のうちの前記1つをコーディングすることが、前記複数の変換係数のうちの前記1つを復号することを備える、C1に記載の方法。
[C12]
前記複数の変換係数のうちの前記1つをコーディングすることが、前記複数の変換係数のうちの前記1つを符号化することを備える、C1に記載の方法。
[C13]
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
変換係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記1つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記1つをコーディングすることと
を行うように構成された1つまたは複数のプロセッサを備える装置。
[C14]
前記コンテキスト導出近傍を定義するために、前記1つまたは複数のプロセッサが、前記変換係数走査順序で前記複数の変換係数のうちの前記1つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するように構成された、C13に記載の装置。
[C15]
前記1つまたは複数のプロセッサが、前記スライディングウィンドウが前記複数の変換係数のうちの前記1つを含むように、前記複数の変換係数のうちの前記1つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で1つの位置だけ移動するようにさらに構成された、C14に記載の装置。
[C16]
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、C14に記載の装置。
[C17]
前記複数の変換係数のうちの前記1つが、走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+i〜n+jにおける変換係数を備え、走査順序位置nが、走査順序位置n+i〜n+jの後に走査され、走査順序位置n+jが、走査順序位置n+iの後に走査される、C14に記載の装置。
[C18]
前記1つまたは複数のプロセッサが、
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
を行うようにさらに構成され、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、C13に記載の装置。
[C19]
前記複数の変換係数のうちの前記1つのための前記コンテキスト導出近傍を定義するために、前記1つまたは複数のプロセッサが、前記変換係数のうちの前記1つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも1つの変換係数のギャップを含めるように構成された、C13に記載の装置。
[C20]
前記変換係数が走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+2〜n+6における変換係数を備え、走査順序位置nが、走査順序位置n+2〜n+6の後に走査される、C19に記載の装置。
[C21]
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記1つまたは複数のプロセッサが、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
を行うようにさらに構成された、C13に記載の装置。
[C22]
前記コンテキストが、CABACコンテキストであり、コーディングするために、前記1つまたは複数のプロセッサが、CABACプロセスを使用して前記複数の変換係数のうちの前記1つをコーディングするように構成された、C13に記載の装置。
[C23]
前記複数の変換係数のうちの前記1つをコーディングするために、前記1つまたは複数のプロセッサが、前記複数の変換係数のうちの前記1つを復号するように構成された、C13に記載の装置。
[C24]
前記複数の変換係数のうちの前記1つをコーディングするために、前記1つまたは複数のプロセッサが、前記複数の変換係数のうちの前記1つを符号化するように構成された、C13に記載の装置。
[C25]
ビデオコーディングプロセスにおいて残差ビデオデータに関連する変換係数をコーディングするための装置であって、
変換係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義するための手段と、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記1つについてのコンテキストを判断するための手段と、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記1つをコーディングするための手段と
を備える装置。
[C26]
前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数走査順序で前記複数の変換係数のうちの前記1つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義するための手段を備える、C25に記載の装置。
[C27]
前記スライディングウィンドウが前記複数の変換係数のうちの前記1つを含むように、前記複数の変換係数のうちの前記1つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で1つの位置だけ移動するための手段をさらに備える、C26に記載の装置。
[C28]
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、C26に記載の装置。
[C29]
前記複数の変換係数のうちの前記1つが、走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+i〜n+jにおける変換係数を備え、走査順序位置nが、走査順序位置n+i〜n+jの後に走査され、走査順序位置n+jが、走査順序位置n+iの後に走査される、C26に記載の装置。
[C30]
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義するための手段
をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、C25に記載の装置。
[C31]
前記複数の変換係数のうちの前記1つのための前記コンテキスト導出近傍を定義するための前記手段が、前記変換係数のうちの前記1つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも1つの変換係数のギャップを含めるための手段を備える、C25に記載の装置。
[C32]
前記変換係数が走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+2〜n+6における変換係数を備え、走査順序位置nが、走査順序位置n+2〜n+6の後に走査される、C31に記載の装置。
[C33]
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義するための手段であって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義するための手段と、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングするための手段と
をさらに備える、C25に記載の装置。
[C34]
前記複数の変換係数のうちの前記1つをコーディングするための前記手段が、前記複数の変換係数のうちの前記1つを復号するための手段を備える、C25に記載の装置。
[C35]
前記複数の変換係数のうちの前記1つをコーディングするための前記手段が、前記複数の変換係数のうちの前記1つを符号化するための手段を備える、C25に記載の装置。
[C36]
実行されたとき、1つまたは複数のプロセッサに、
変換係数走査順序に基づいて複数の変換係数のうちの1つのためのコンテキスト導出近傍を定義することと、
前記コンテキスト導出近傍に基づいて前記複数の変換係数のうちの前記1つについてのコンテキストを判断することと、
前記判断されたコンテキストに基づいて前記複数の変換係数のうちの前記1つをコーディングすることと
を行わせる命令を備える非一時的コンピュータ可読媒体。
[C37]
前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数走査順序で前記複数の変換係数のうちの前記1つより前に走査された変換係数のセットを含むスライディングウィンドウに基づいて前記コンテキスト導出近傍を定義することを前記1つまたは複数のプロセッサに行わせる、C36に記載のコンピュータ可読媒体。
[C38]
前記1つまたは複数のプロセッサに、前記スライディングウィンドウが前記複数の変換係数のうちの前記1つを含むように、前記複数の変換係数のうちの前記1つをコーディングした後に前記スライディングウィンドウを前記変換係数走査順序で1つの位置だけ移動することを行わせる命令をさらに備える、C37に記載のコンピュータ可読媒体。
[C39]
変換係数の前記セットが、前記係数走査順序で連続する変換係数のセットを備える、C37に記載のコンピュータ可読媒体。
[C40]
前記複数の変換係数のうちの前記1つが、走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+i〜n+jにおける変換係数を備え、走査順序位置nが、走査順序位置n+i〜n+jの後に走査され、走査順序位置n+jが、走査順序位置n+iの後に走査される、C37に記載のコンピュータ可読媒体。
[C41]
前記1つまたは複数のプロセッサに、
前記変換係数走査順序に基づいて前記複数の変換係数の他の変換係数のためのコンテキスト導出近傍を定義すること
を行わせる命令をさらに備え、
前記コンテキスト導出近傍の各々が、コーディングされるべき前記それぞれの係数に対する前記走査順序に沿ってスライディングウィンドウに対応する、C36に記載のコンピュータ可読媒体。
[C42]
前記複数の変換係数のうちの前記1つのための前記コンテキスト導出近傍を定義するために、前記命令が、前記変換係数のうちの前記1つと前記コンテキスト導出近傍に関連する変換係数との間に少なくとも1つの変換係数のギャップを含めることを前記1つまたは複数のプロセッサに行わせる、C36に記載のコンピュータ可読媒体。
[C43]
前記変換係数が走査順序位置nを有し、前記コンテキスト導出近傍が、走査順序位置n+2〜n+6における変換係数を備え、走査順序位置nが、走査順序位置n+2〜n+6の後に走査される、C42に記載のコンピュータ可読媒体。
[C44]
前記複数の変換係数が、変換係数のサブブロックに関連付けられ、
前記1つまたは複数のプロセッサに、前記複数の変換係数の初期変換係数のための前記走査順序に基づかない初期コンテキスト導出近傍を定義することであって、前記初期変換係数が、前記変換係数走査順序で前記サブブロック中で最初に走査される、定義することと、
前記初期コンテキスト導出近傍に基づいて前記初期変換係数をコーディングすることと
を行わせる命令をさらに備える、C36に記載のコンピュータ可読媒体。
[C45]
前記複数の変換係数のうちの前記1つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記1つを復号することを前記1つまたは複数のプロセッサに行わせる、C36に記載のコンピュータ可読媒体。
[C46]
前記複数の変換係数のうちの前記1つをコーディングするために、前記命令が、前記複数の変換係数のうちの前記1つを符号化することを前記1つまたは複数のプロセッサに行わせる、C36に記載のコンピュータ可読媒体。