JP2022523287A - 通常コード化ビンの数の削減 - Google Patents

Abstract

ＣＡＢＡＣで符号化するために、非２値構文要素の値が、２値化処理を介して、２値シーケンス（ビン文字列）にマッピングされる。２値算術コーディングエンジンは、通常の（コンテキストベースの）モードとバイパスモードでビンを符号化または復号化する。【選択図】図１１Ａ

Description

本実施形態は、概して、ビデオ符号化または復号のための方法および装置、より具体的には、エントロピー符号化および復号における通常のコード化ビンの数を削減する方法および装置に関する。

高い圧縮効率を達成するために、画像およびビデオのコーディングスキームは、通常、予測および変換を用いて、ビデオコンテンツの空間的および時間的冗長性を活用する。一般に、イントラまたはインター予測は、イントラまたはインターピクチャ相関を活用するために使用され、次いで、元のブロックと予測ブロックとの間の差、多くの場合、予測誤差または予測残差と称される差が、変換され、量子化され、エントロピーコード化される。ビデオを再構築するために、圧縮データは、エントロピーコーディング、量子化、変換、および予測に対応する逆処理によって復号される。

一実施形態によれば、ビデオ復号の方法が提供され、方法は、ビットストリームから複数の２値シンボルを復号することであって、複数の２値シンボルの第１の２値シンボルは、コンテキストベースのモードを使用してエントロピー復号され、第１の２値シンボルに続く各２値シンボルは、バイパスモードでエントロピー復号される、復号することと、２値化スキームに対応する、複数の２値シンボルによって表されるインデックスを取得することと、２つの予測因子の重み付け和としてブロックの予測を形成することであって、インデックスは、重み付け和を形成するときに２つの予測因子の重み付けに使用されるそれぞれの重み係数を示す、形成することと、を含む。

一実施形態によれば、ビデオ符号化の方法が提供され、方法は、符号化されるブロックにアクセスすることと、２つの予測因子の重み付け和としてブロックの予測を形成することと、重み付け和を形成するときに２つの予測因子の重み付けに使用されるそれぞれの重み係数を示すためのインデックスを符号化することと、を含み、インデックスは、２値化スキームを使用して、複数の２値シンボルに２値化され、複数の２値シンボルの第１の２値シンボルは、コンテキストベースのモードを使用してエントロピー符号化され、第１の２値シンボルに続く各２値シンボルは、バイパスモードでエントロピー符号化される。

別の実施形態によれば、１つ以上のプロセッサを含むビデオ復号のための装置が提供され、この１つ以上のプロセッサは、ビットストリームから複数の２値シンボルを復号することであって、複数の２値シンボルの第１の２値シンボルが、コンテキストベースのモードを使用してエントロピー復号され、第１の２値シンボルに続く各２値シンボルが、バイパスモードでエントロピー復号される、復号することと、２値化スキームに対応する、複数の２値シンボルによって表されるインデックスを取得することと、２つの予測因子の重み付け和としてブロックの予測を形成することであって、インデックスは、重み付け和を形成するときに２つの予測因子の重み付けに使用されるそれぞれの重み係数を示す、形成することと、を行うように構成されている。

別の実施形態によれば、１つ以上のプロセッサを含むビデオ符号化のための装置が提供され、１つ以上のプロセッサが、符号化されるブロックにアクセスし、２つの予測因子の重み付け和としてブロックの予測を形成し、重み付け和を形成するときに、２つの予測因子の重み付けに使用されるそれぞれの重み係数を示すためにインデックスを符号化するように構成され、インデックスは、２値化スキームを使用して、複数の２値シンボルに２値化され、複数の２値シンボルの第１の２値シンボルが、コンテキストベースのモードを使用してエントロピー符号化され、第１の２値シンボルに続く各２値シンボルが、バイパスモードでエントロピー符号化される。

別の実施形態によれば、ビデオ復号の装置が提供され、装置は、ビットストリームから複数の２値シンボルを復号する手段であって、複数の２値シンボルの第１の２値シンボルは、コンテキストベースのモードを使用してエントロピー復号され、第１の２値シンボルに続く各２値シンボルは、バイパスモードでエントロピー復号される、復号する手段と、２値化スキームに対応する、複数の２値シンボルによって表されるインデックスを取得する手段と、２つの予測因子の重み付け和としてブロックの予測を形成する手段であって、インデックスは、重み付け和を形成するときに２つの予測因子の重み付けに使用されるそれぞれの重み係数を示す、形成する手段と、を含む。

別の実施形態によれば、ビデオ符号化の装置が提供され、装置は、符号化されるブロックにアクセスする手段と、２つの予測因子の重み付け和としてブロックの予測を形成する手段と、重み付け和を形成するときに２つの予測因子の重み付けに使用されるそれぞれの重み係数を示すためのインデックスを符号化する手段とを含み、インデックスは、２値化スキームを使用して、複数の２値シンボルに２値化され、複数の２値シンボルの第１の２値シンボルは、コンテキストベースのモードを使用してエントロピー符号化され、第１の２値シンボルに続く各２値シンボルは、バイパスモードでエントロピー符号化される。

ビデオ符号化器の一実施形態のブロック図を示す。 圧縮されたＨＥＶＣピクチャを表すためのコーディングツリーユニットおよびコーディングツリーの概念を示す図解例である。 コーディングツリーユニットの、コーディングユニット、予測ユニット、および変換ユニットへの分割を示す図解例である。 ビデオ復号器の一実施形態のブロック図を示す。 ＣＡＢＡＣ復号処理を示す。 ＣＡＢＡＣ符号化処理を示す。 クアッドツリープラスバイナリツリー（ＱＴＢＴ）のＣＴＵ表現を示す図解例である。 コーディングユニットの分割モードを示す図解例である。 ＶＶＣドラフト４でのＧＢｉインデックスのコーディング処理を示す。 ＶＶＣドラフト４でのＧＢｉインデックスの解析処理を示す。 一実施形態によるＧＢｉインデックスのコーディング処理を示し、図１１Ａは、別の実施形態によるＧＢｉインデックスのコーディング処理を示す。 一実施形態によるＧＢｉインデックスの解析処理を示し、図１２Ａは別の実施形態によるＧＢｉインデックスの解析処理を示し、図１２Ｂおよび図１２Ｃは、それぞれ非低遅延モードおよび低遅延モードで、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘの２値化およびコーディング／解析処理を示し、図１２Ｄは、デフォルトのＧＢＩモードを信号通知する第１のビンが０に等しい場合のツリーを示す。 ＡＭＶＰモードでの動きベクトル予測因子候補リストの構築を示す図解例である。 ＡＭＶＰ候補リストを構築するために考慮される空間的および時間的動きベクトル予測候補を示す図解例である。 ＶＶＣドラフト４のＡＭＶＰにおける動きベクトル予測インデックスのＣＡＢＡＣコーディングを示す。 一実施形態による、ｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇ構文要素のバイパスコーディング処理を示す。 ＶＶＣドラフト５のＳＢＴツールの原理を示す。 ＶＶＣドラフト５でのＩＮＴＥＲコーディングユニットのＳＢＴモードの復号処理を示す。 一実施形態によるＳＢＴモード復号処理を示し、図１９Ｂは、別の実施形態によるＳＢＴモード復号処理を示す。 ４ｘ８および８ｘ４のＩＮＴＲＡコーディングユニットに対して許容されるＩＳＰ分割を示し、図２０Ｂは、４ｘ８または８ｘ４とは異なるサイズのＩＮＴＲＡコーディングユニットに対して許容されるＩＳＰ分割を示す。 複数の基準線イントラ予測の原理を示す。 ＶＶＣドラフト５での「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」構文要素の解析処理を示す。 一実施形態による、「Ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」構文要素の簡略化された解析処理を示す。 本実施形態の態様を実装することができる、システムのブロック図を示す。

図１は、高効率ビデオコーディング（ＨＥＶＣ）符号化器などのビデオ符号化器１００の例を示している。図１はまた、ＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ）によって開発中のＶＶＣ（バーサタイルビデオコーディング）符号化器などの、ＨＥＶＣ規格を改良した符号化器またはＨＥＶＣに類似した技術を採用した符号化器を示すことができる。

本出願では、「再構築された（ｒｅｃｏｎｓｔｒｕｃｔｅｄ）」および「復号された（ｄｅｃｏｄｅｄ）」という用語は、互換的に使用することができ、「符号化された（ｅｎｃｏｄｅｄ）」または「コード化された（ｃｏｄｅｄ）」という用語は、互換的に使用することができ、「画像（ｉｍａｇｅ）」、「ピクチャ（ｐｉｃｔｕｒｅ）」、および「フレーム（ｆｒａｍｅ）」という用語は、互換的に使用することができる。必須ではないが、通常は、「再構築された」という用語は、符号化器側において使用される一方で「復号された」は、復号器側において使用される。

符号化される前に、ビデオシーケンスは事前符号化処理（１０１）、例えば、入力色ピクチャに色変換（例えば、ＲＧＢ４：４：４からＹＣｂＣｒ４：２：０への変換）を適用すること、または、（例えば、色成分のうちの１つのヒストグラム等化を使用して）圧縮に対してより復元力のある信号分布を得るために、入力ピクチャ成分の再マッピングを実行することを経る場合がある。メタデータは、事前処理に関連付けることができ、ビットストリームに添付することができる。

１つ以上のピクチャでビデオシーケンスを符号化するために、ピクチャは、例えば、各スライスが１つ以上のスライスセグメントを含むことができる１つ以上のスライスに区切られる（１０２）。ＨＥＶＣでは、スライスセグメントは、コーディングユニットと、予測ユニットと、変換ユニットと、に編成される。ＨＥＶＣ仕様は、「ブロック」と「ユニット」とを区別し、ここで「ブロック」は、サンプルアレイの特定の領域（例えば、輝度、Ｙ）をアドレス指定し、「ユニット」は、すべての符号化された色成分（Ｙ、Ｃｂ、Ｃｒ、またはモノクロ）、構文要素、およびブロックに関連付けられている予測データ（例えば、動きベクトル）の併置されたブロックを含む。

図２に示されているような、ＨＥＶＣに従うコーディングでは、ピクチャは、構成可能サイズ（通常、６４×６４、１２８×１２８、または２５６×２５６ピクセル）を有する正方形のコード化ツリーブロック（ＣＴＢ）に区切られ、コード化ツリーブロックの連続したセットは、スライスにグループ化される。コーディングツリーユニット（ＣＴＵ）は、符号化された色成分のＣＴＢを包含する。ＣＴＢは、図３に示すように、コーディングブロック（ＣＢ）へのクアッドツリーパーティショニングのルートであり、コーディングブロックは、１つ以上の予測ブロック（ＰＢ）に区切ることができ、変換ブロック（ＴＢ）へのクアッドツリーパーティションのルートを形成する。コーディングブロック、予測ブロック、および変換ブロックに対応して、コード化ユニット（ＣＵ）は、予測ユニット（ＰＵ）と、変換ユニット（ＴＵ）のツリー構造セットと、を含み、ＰＵは、すべての色成分の予測情報を含み、ＴＵは、各色成分の残差コード化構文構造を含む。輝度成分のＣＢ、ＰＢ、およびＴＢのサイズは、対応するＣＵ、ＰＵ、およびＴＵに適用される。本出願では、「ブロック（ｂｌｏｃｋ）」という用語は、例えば、ＣＴＵ、ＣＵ、ＰＵ、ＴＵ、ＣＢ、ＰＢ、およびＴＢのいずれかを指すために使用することができる。加えて、「ブロック」は、Ｈ．２６４／ＡＶＣまたは他のビデオコーディング規格で指定されているマクロブロックおよびパーティションを指すためにも使用することができ、より一般的には、様々なサイズのデータのアレイを指すために使用することができる。

符号化器１００では、以下に説明されているように、ピクチャが、符号化器要素によって符号化される。符号化されるピクチャは、例えば、ＣＵのユニットで処理される。各コーディングユニットは、イントラモードまたはインターモードのいずれかを使用して符号化される。コーディングユニットがイントラモードで符号化される場合、イントラ予測を実行する（１６０）。インターモードでは、動き推定（１７５）および動き補償（１７０）が行われる。符号化器は、イントラモードまたはインターモードのどちらをコーディングユニットの符号化に使用するかを決定し（１０５）、予測モードフラグによってイントラ／インター決定を示す。予測残差は、元の画像ブロックから予測されたブロックを減算することにより計算される（１１０）。

次いで、予測残差が変換され（１２５）、量子化される（１３０）。量子化された変換係数に加えて、動きベクトルおよび他の構文要素は、ビットストリームを出力するためにエントロピーコード化される（１４５）。非限定的な例として、コンテキストベースの適応型２値算術コーディング（ＣＡＢＡＣ）を使用して、構文要素をビットストリームに符号化することができる。

ＣＡＢＡＣで符号化するために、非２値構文要素の値は、２値化処理を介して、ビン文字列と呼ばれる２値シーケンスにマッピングされる。ビンの場合、コンテキストモデルが選択される。「コンテキストモデル」は、１つ以上のビンの確率モデルであり、直近のコード化されたシンボルの統計に応じて、一連の利用可能なモデルから選ばれる。各ビンのコンテキストモデルは、コンテキストモデルインデックス（「コンテキストインデックス」としても使用される）によって識別され、異なるコンテキストインデックスが異なるコンテキストモデルに対応する。コンテキストモデルは、各ビンが「１」または「０」である確率を記憶し、適応型または静的型とすることができる。静的モデルは、ビン「０」および「１」に対して等しい確率でコーディングエンジンをトリガする。適応コーディングエンジンでは、ビンの実際のコード化値に基づいてコンテキストモデルが更新される。適応モデルおよび静的モデルに対応する動作モードは、それぞれ、通常モードおよびバイパスモードと呼ばれる。コンテキストに基づいて、２値算術コーディングエンジンは、対応する確率モデルにしたがってビンを符号化または復号する。

符号化器はまた、変換をスキップし、例えば、４×４ＴＵベースで非変換残差信号に直接量子化を適用することができる。符号化器はまた、変換および量子化の双方をバイパスすることもでき、すなわち、残差は、変換または量子化処理を適用せずに直接コード化される。直接ＰＣＭコーディングでは、予測は適用されず、コード化ユニットサンプルは、ビットストリームに直接コード化される。

符号化器は、符号化されたブロックを復号して、さらに予測するための参照を提供する。量子化された変換係数は非量子化され（１４０）、逆変換され（１５０）、予測残差を復号する。復号された予測残差と予測されたブロックとを組み合わせて（１５５）、画像ブロックが再構築される。ループ内フィルタ（１６５）は、再構築されたピクチャに適用され、例えば、デブロッキング／ＳＡＯ（サンプル適合オフセット）フィルタリングを実行し、符号化アーティファクトを低減する。フィルタリングされた画像は、参照ピクチャバッファ（１８０）に記憶される。

図４は、ＨＥＶＣ復号器のような例示的なビデオ復号器２００のブロック図を示している。復号器２００では、以下に説明されているように、ビットストリームが、復号器要素によって復号される。ビデオ復号器２００は、全般的に、図１で説明されたような符号化パスの逆の復号パスを実行し、これは、ビデオデータの符号化の一部として、ビデオ復号を実行する。図４はまた、ＶＶＣ復号器のようなＨＥＶＣ規格を改良した復号器またはＨＥＶＣに類似した技術を採用した復号器を示すことができる。

特に、復号器の入力は、ビデオ符号化器１００によって生成され得るビデオビットストリームを含む。ビットストリームは、まずエントロピー復号され（２３０）、変換係数、動きベクトル、ピクチャパーティショニング情報、および他のコード化された情報が得られる。エントロピーコーディングにＣＡＢＡＣが使用される場合、コンテキストモデルは、符号化器コンテキストモデルと同じ方法で初期化され、構文要素は、コンテキストモデルに基づいてビットストリームから復号される。

図５は、入力コード化ビットストリームが与えられた場合の構文要素のＣＡＢＡＣ復号処理を示している。これは、図６の構文要素コーディング処理の逆の処理である。

図５の処理への入力は、コード化されたビットストリームを含み、典型的には、ＨＥＶＣまたはＶＶＣのようなビデオ圧縮規格に準拠している。復号処理の任意の時点で、復号器は次に復号される構文要素を認識する。これは、標準化されたビットストリーム構文および復号処理で完全に指定される。さらに、復号する現在の構文要素がどのように２値化されるか（つまり、それぞれが「１」または「０」に等しいビンと呼ばれる２値シンボルのシーケンスとして表される）、およびビン文字列の各ビンがどのように符号化されているかも認識される。

したがって、ＣＡＢＡＣ復号処理の第１段階（図５の左側）は、一連のビンを復号する。復号器は、ビンごとに、ビンがバイパスモードまたは通常モードのどちらに従って符号化されているかを認識する。バイパスモードは、ビットストリーム内のビットをシンプルに読み取り、そのようにして取得したビット値を現在のビンに割り当てることで構成される。このモードには、単純であるため高速であるという利点がある。これは通常効率的であるため、統計的分布が均一なビン、つまり「１」または「０」に等しくなる確率が等しいビンに使用される。

反対に、現在のビンがバイパスモードでコード化されていない場合は、いわゆる通常モードで、つまりコンテキストベースの算術コーディングによってコード化されていることを意味する。その場合、考慮されるビンの復号は次のように進められる。最初に、コンテキストモデラーモジュールを使用して、現在のビンを復号するためのコンテキストが取得される。コンテキストの目標は、コンテキスト情報または事前情報Ｘが与えられた場合に、現在のビンの値が「０」である条件付き確率を取得することである。ここでの事前Ｘは、現在のビンが復号された時点で、符号化器側と復号器側の両方で同期的に使用可能な、すでに復号されている構文要素の値であり得る。

通常、ビンの復号に使用される事前Ｘは標準で指定されており、復号する現在のビンと統計的に相関しているために選択される。このコンテキスト情報を使用する利点は、ビンのコーディングのレートコストを削減することである。これは、ビンとＸの相関が高い場合、Ｘが与えられた場合のビンの条件付きエントロピーが低くなるという事実に基づいている。情報理論では、Ｈ（ｂｉｎ│Ｘ）＜Ｈ（ｂｉｎ）という関係がよく知られている。

これは、ビンとＸが統計的に相関している場合、Ｘを知っているビンの条件付きエントロピーがビンのエントロピーよりも低いことを意味する。したがって、コンテキスト情報Ｘは、ビンが「０」または「１」である確率を取得するために使用される。これらの条件付き確率が与えられると、通常の復号エンジンは２値ビンの算術復号を実行する。次に、ビンの値を使用して、現在のコンテキスト情報Ｘを認識し、現在のビンに関連付けられた条件付き確率の値を更新する。これはコンテキストモデルの更新と呼ばれる。ビンが復号（またはコード化）されている限り、各ビンのコンテキストモデルを更新すると、各２値要素のコンテキストモデリングを段階的に改良できる。したがって、ＣＡＢＡＣ復号器は、通常符号化された各ビンの統計的動作を段階的に学習する。コンテキストモデラーとコンテキストモデルの更新ステップは、符号化器側と復号器側で厳密に同じ動作であることに留意されたい。

現在のビンの通常の算術復号またはそのバイパス復号は、コード化方法に応じて、一連の復号されたビンにつながる。

次に、図５の右側に示されているＣＡＢＡＣ復号の第２のフェーズでは、この一連の２値シンボルを構文要素に変換する。構文要素はフラグの形式をとり得、その場合、現在復号されているビンの値を直接取得する。他方、現在の構文要素の２値化が、考慮されている標準仕様にしたがっていくつかのビンのセットに対応する場合、２値コードワードから構文要素への変換が行われる。

これにより、符号化器によって実行された２値化の逆のステップが進められる。したがって、ここで実行される逆変換は、それぞれの復号された２値化バージョンに基づいて、これらの構文要素の値を取得する。

例えば、最後の有意な係数位置のプレフィックスコードとマージインデックス（マージ候補のリスト内の候補の位置を示す）に対応する構文要素は、トランケートされたライス（ｔｒｕｎｃａｔｅｄ Ｒｉｃｅ）２値化を使用して２値化される。最後の有意係数位置フラグの場合、すべてのビンは通常モードで符号化され、マージインデックスの場合、第１のビンは通常モードで符号化され、他のビンはバイパスモードで符号化される。

ピクチャパーティショニング情報は、ピクチャが区切られる方法、例えば、ＣＴＵのサイズ、およびＣＴＵがＣＵに、および適用可能な場合はＰＵに分割される方法を示す。したがって、復号器は、復号されたピクチャパーティショニング情報にしたがって、例えば、ピクチャをＣＴＵに分割し（２３５）、各ＣＴＵをＣＵに分割することができる。変換係数は、予測残差を復号するために、非量子化され（２４０）、かつ逆変換される（２５０）。

復号された予測残差と予測されたブロックとを組み合わせて（２５５）、画像ブロックが再構築される。予測ブロックは、イントラ予測（２６０）または動き補償予測（すなわち、インター予測）（２７５）から取得することができる（２７０）。ループ内フィルタ（２６５）は、再構築された画像に適用される。フィルタリングされた画像は、参照ピクチャバッファ（２８０）に記憶される。

復号されたピクチャは、事後復号処理（２８５）、例えば、逆色変換（例えば、ＹＣｂＣｒ ４：２：０からＲＧＢ ４：４：４への変換）または事前符号化処理（１０１）で行われる再マッピング処理の逆を実行する逆再マッピングをさらに経ることができる。事後復号処理は、事前符号化処理において導出され、かつビットストリームで信号通知された、メタデータを使用することができる。

最近、圧縮ドメインでより柔軟な方法でピクチャデータを表現するために、圧縮ドメインでの新しいコーディングツリーユニット表現を含む新興のビデオ圧縮ツールが提案されている。コーディングツリーのより柔軟な表現により、ＨＥＶＣ規格のＣＵ／ＰＵ／ＴＵアレンジメントと比較して圧縮効率を向上させ得る。

一例では、クアッドツリープラスバイナリツリー（ＱＴＢＴ）コーディングツールは、柔軟性を向上させる新しいツールである。ＱＴＢＴコーディングツリーは、コーディングユニットをクアッドツリー方式およびバイナリツリー方式の両方で分割することができる。ＱＴＢＴテクノロジでは、ＣＵは、正方形または長方形の形状を有する。コーディングユニットのサイズは、常に２の累乗であり、通常は、４～１２８である。コーディングツリーユニットを表すＱＴＢＴコーディングツリーの例を図７に示す。

コーディングユニットの分割は、符号化器側で、最低レート歪みコストでＣＴＵのＱＴＢＴ表現を決定することによって実行され得る、レート歪み最適化手順を経て決定される。ＣＴＵのＱＴＢＴ分解は、２つの段階で構成され、実線がクアッドツリー分解フェーズを表し、破線がクアッドツリーリーフに空間的に埋め込まれた２値分解を表す、図７に例示されるように、最初にＣＴＵがクアッドツリー方式で分割され、次に、各クアッドツリーリーフをさらに２値方式で分割することができる。イントラスライスでは、輝度ブロックと彩度ブロックのパーティショニング構造が分離され、独立して決定される。

予測ユニットまたは変換ユニットへのＣＵパーティショニングは採用されない。言い換えると、各コーディングユニットは体系的に、単一の予測ユニット（２Ｎ×２Ｎ予測ユニットパーティションタイプ）と単一の変換ユニット（変換ツリーへの分割なし）で構成されている。

水平または垂直トリプルツリー分割モード（ＨＯＲ＿ＴＲＩＰＬＥ、ＶＥＲ＿ＴＲＩＰＬＥ）と呼ばれる、ＶＶＣ（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）ビデオ圧縮規格で採用されている追加のＣＵ分割モードは、コーディングユニット（ＣＵ）を３つのサブコーディングユニット（サブＣＵ）に分割することからなり、それぞれのサイズは、図８に示すように、考慮される空間分割の方向で親ＣＵサイズの１／４、１／２、および１／４に等しい。

本実施形態は、構文要素の符号化と復号を対象とする。いくつかの実施形態において、複雑さを低減するために、いくつかのイントラまたはインター予測パラメータのエントロピーコーディングが変更される。

上記のように、多くの２値シンボル（またはビン）は、コンテキスト適応型２値算術コーディング処理によってコード化および復号される。この処理には、ビンをコード化する、通常モードおよびバイパスモードの、２つの方法が伴う。バイパスコーディングモードは、通常のコーディングモードよりもはるかに複雑ではない。したがって、バイパスコーディングと比較して通常のコーディングモードでコーディング効率の改善がまったくまたはほとんど得られない場合、通常のコーディング処理をバイパスコーディング処理に置き換えることは有利である。

一実施形態では、バイパスコーディング処理は、一般化されたバイ予測インデックスを表すビン文字列の第１の１つ以上のビンに信号を送るために使用される。別の実施形態では、通常のコーディング処理の代わりにバイパスコーディング処理を使用して、ＡＭＶＰモードにてコード化されたコーディングユニット（ＣＵ）の動きベクトルを符号化するためにどの動きベクトル予測因子が使用されるかを信号で伝える。

実際、これらの構文要素で符号化するビンの条件付きエントロピーは、現在のＶＶＣコーディングシステムでこれらのビンにコンテキストベースの算術コーディングを使用しているにもかかわらず、１ビットの情報に近いことが検出されている。さらに、実験結果は、提案されたバイパスコーディングを使用することによるＶＶＣ圧縮性能への影響がごくわずかであることを示している。

以下では、一般化されたバイ予測インデックスと動きベクトル予測因子のシグナリングについてさらに詳しく説明する。

一般化されたバイ予測インデックスのシグナリング
ＶＶＣドラフト４の一般化されたバイ予測
ＶＶＣドラフト４（「Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（Ｄｒａｆｔ ４）」、Ｂ．Ｂｒｏｓｓ ｅｔ ａｌ．、１３^ｔｈＪＶＥＴ ｍｅｅｔｉｎｇ、Ｊａｎｕａｒｙ ９－１８，２０１９，Ｍａｒｒａｋｅｃｈを参照）においては、インターＣＵがいわゆる一般化されたバイ予測（ＧＢｉ）の使用を介して一時的に予測され得る。一般化されたバイ予測において、バイ予測ブロックの時間予測は、次の式に従って、２つの参照ブロックの重み付け平均として計算される。
Ｐ_{ｂｉｐｒｅｄ}＝（（８－ｗ）×Ｐ_０＋ｗ×Ｐ_１＋４）＞＞３
Ｐ_０およびＰ_１は時間的予測因子であり、そしてｗは、以下のセットで選択される。
－低遅延画像（過去のすべての参照画像がある）の場合、ｗ ∈｛－２、３、４、５、１０｝である。非低遅延画像（少なくとも１つの過去と１つの将来の参照画像がある）の場合、ｗ∈｛３、４、５｝である。
－ＧＢｉの重みｗは、符号化器側のレート歪み最適化処理に基づいて選択され、ビットストリームで信号通知される。ＧＢｉは、アフィン動き補償や適応動きベクトル解像度など、ＶＶＣのさまざまな動き補償ツールとも組み合わされている。

ＣＵの予測に使用されるＧＢｉの重みを信号通知する構文要素は、ＧＢｉインデックスと呼ばれる。

ＶＶＣドラフト４（符号化器）でのＧＢｉインデックスのコーディング
ＶＶＣドラフト４では、ＧＢｉインデックスは最初に別のインデックスｇｂｉＣｏｄｉｎｇＩｎｄｅｘに変換される。デフォルトの重み（等しい重み）を使用するかどうかを示すフラグが決定される。フラグは、デフォルト重みｗ＝４（予測因子Ｐ_０およびＰ_１の両方について等しい重み）については１に、および他の重みについては０に設定される。残りのｇｂｉＣｏｄｉｎｇＩｎｄｅｘは、トランケートされたライス（トランケートされた単項）ビン文字列を使用して２値化される。トランケートされたライスビン文字列のフラグまたは各ビンは、専用のＣＡＢＡＣコンテキストを使用してＣＡＢＡＣで符号化される。特に、フラグは、コンテキストモデルＩＤ０でコンテキストベースにコード化されている（つまり、通常モードを使用している）。ビンである、ビン１、ビン２、およびビン３は、それぞれコンテキストモデルＩＤ４、５、および６でコンテキストベースにコード化されている。

表１は、低遅延モードのＧＢｉインデックス（ＧＢｉＩｄｘ）コーディングを示しており、ＧＢｉモードの数はｎｕｍＧＢｉＭｏｄｅｓ＝５に設定されており、第１のビンに加えてビンの最大数はｎｕｍＢｉｎｓ＝３に設定されている。

表２は、非低遅延モードのＧＢｉインデックスコーディングを示しており、ＧＢｉモードの数はｎｕｍＧＢｉＭｏｄｅｓ＝３に設定されており、第１のビンに加えてビンの最大数はｎｕｍＢｉｎｓ＝１に設定されている。

表１と表２に示されているフラグとビン文字列の連結は、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘのトランケートされたライス２値化と直接見なすことができることに注意されたい。つまり、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘは、トランケートされたライス（トランケートされた単項）ビン文字列を使用して２値化される。各ビンは専用のＣＡＢＡＣコンテキストを用いて、ＣＡＢＡＣで符号化されている。特に、第１のビン、ビン０は、コンテキストモデルＩＤ０でコンテキストベースにコード化されている（つまり、通常モードを使用している）。第１のビンは、デフォルトの重みｗ＝４（予測因子Ｐ_０およびＰ_１の両方で等しい重み）の場合は１に設定され、その他の重みの場合は０に設定されることに注意されたい。したがって、第１のビンは、デフォルトの重みを使用するか否かを示すフラグと見なすこともできる。次に、後続のビンである、ビン１、ビン２、およびビン３は、それぞれコンテキストモデルＩＤ４、５、および６でコンテキストベースにコード化される。

図９は、ＶＶＣドラフト４におけるようなＧＢｉインデックスのコーディングを示している。ステップ９１０で、変数Ｉｄｘが０に設定される。ステップ９２０で、現在のＣＵに関連付けられたＧＢｉＩｄｘ値は、表１および表２の列「ｇｂｉＣｏｄｉｎｇＩｎｄｅｘ」によって定義されたテーブルＧｂｉＣｏｄｉｎｇＯｒｄｅｒを介して、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘに変換される。ステップ９３０で、フラグ（ｇｂｉＣｏｄｉｎｇＩｎｄｅｘ＝＝０）が符号化され、これは、値ｇｂｉＣｏｄｉｎｇＩｎｄｅｘがゼロに等しいかどうかを示す。ゼロ値は、現在のＣＵのＧＢｉＩｄｘ値がＧＢＩ＿ＤＥＦＡＵＬＴに等しい場合に対応し、これは、デフォルトのバイ予測モード、つまり、ｗ＝４の場合に対応する。ｇｂｉＣｏｄｉｎｇＩｎｄｅｘの値がゼロ（９４０）の場合、処理は終了する。

それ以外の場合、符号化器はスライスが低遅延タイプであるかどうかをチェックする（９４５）。スライスが低遅延タイプの場合、ｎｕｍＧｂｉＭｏｄｅｓは５に設定され（９５０）、スライスが低遅延タイプでない場合、ｎｕｍＧｂｉＭｏｄｅｓは３に設定される（９５５）。ステップ９６０で、Ｉｄｘは１に設定される。ステップ９６５で、コンテキストモデルＩＤｃｏｎｔｅｘｔＩｄが４に設定される。ステップ９７０で、ｎｕｍＢｉｎｓは、ｎｕｍＧｂｉＭｏｄｅｓ－２に設定される。ｇｂｉＣｏｄｉｎｇＩｎｄｅｘは、ｂｉｎ文字列に２値化される。次に、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘを表すビンは、すべてのビンが符号化される（９９０）まで、対応するｃｏｎｔｅｘｔＩｄを使用して（９８５）、１つずつ符号化される（９８０）。処理はステップ９９９で終了する。

図１０は、ＶＶＣドラフト４におけるようなＧＢｉインデックスの解析を示している。復号器は、ビットストリームから値「Ｉｄｘ」を復号し、復号された値ＩｄｘとＣＵレベルのＧＢｉＩｄｘパラメータをリンクするマッピングテーブルＧｂｉＰａｒｓｉｎｇＯｒｄｅｒを使用して、「Ｉｄｘ」を入力ＣＵに関連付けられた実際のＧＢｉＩｄｘに変換する。

より具体的には、ステップ１０１０で、変数Ｉｄｘが０に設定される。ステップ１０２０で、値ｇｂｉＣｏｄｉｎｇＩｎｄｅｘがゼロ（ｇｂｉＣｏｄｉｎｇＩｄｘ＝＝０）に等しいかどうかを示すフラグが、コンテキストＩｄ＝０を使用して復号される。ゼロ値は、現在のＣＵのＧＢｉＩｄｘ値がＧＢＩ＿ＤＥＦＡＵＬＴに等しい場合に対応し、これは、デフォルトのバイ予測モード、つまり、ｗ＝４の場合に対応する。復号されたシンボルが１の場合、復号器はステップ１０９０に進む。

それ以外の場合、フラグが１の場合（１０２５）、ステップ１０３０でＩｄｘが１に設定される。ステップ１０３５で、コンテキストモデルＩＤｃｏｎｔｅｘｔＩｄが４に設定される。復号器は、スライスが低遅延タイプであるかどうかをチェックする（１０４０）。スライスが低遅延タイプの場合、ｎｕｍＧｂｉＭｏｄｅｓは５に設定され（１０４５）、スライスが低遅延タイプでない場合、ｎｕｍＧｂｉＭｏｄｅｓは３に設定される（１０５０）。ステップ１０６０において、ｎｕｍＢｉｎｓはｎｕｍＧｂｉＭｏｄｅｓ－２に設定される。次に、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘを表すビンは、１に等しいビンシンボルが見つかるか、ｎｕｍＢｉｎｓビンが解析されるまで（１０８５）、対応するｃｏｎｔｅｘｔＩｄを使用して（１０８０）１つずつ反復的に復号される（１０７０）。各反復で、変数Ｉｄｘがインクリメントされる。ステップ１０９０で、「Ｉｄｘ」はテーブルＧｂｉＰａｒｓｉｎｇＯｒｄｅｒを介してＧＢｉインデックスに変換される。処理はステップ１０９９で終了する。

提案されたＧＢｉインデックスコーディング処理（符号化器）
表３と表４は、それぞれ低遅延モードと非低遅延モードのＧＢｉインデックス（ＧＢｉＩｄｘ）コーディングに対する提案された変更を示している。この提案された方法では、第１のビンはバイパスモード（表では「ｂ」として表される）で符号化され、他のビンは通常モードで符号化される。

図１１は、一実施形態による、提案されたＧＢｉＩｄｘパラメータコーディング処理を示す。ステップ１１６５で、ｃｏｎｔｅｘｔＩｄは５に設定される。ステップ１１７０で、表３または表４のトランケートされたライスビン文字列の第１のビンは、コンテキストベースの算術コーディングモードの代わりに、バイパスモードで符号化される。他のビンは、もしあれば、図９に記載されたものと同様に、通常モードで符号化される。この提案された実施形態の利点は、ＣＵレベルのＧＢｉＩｄｘパラメータを符号化する際の複雑さが軽減されることである。

提案されたＧＢｉ解析処理（復号器）
図１２は、一実施形態による、ＧＢｉＩｄｘパラメータ解析処理に対する提案された変更を示す。見てわかるように、提案されたＧＢｉＩｄｘ解析処理の第１のステップは、図１０に記載されたものと同じである。次に、最初に復号されたシンボルが０（ＧＢＩ＿ＤＥＦＡＵＬＴベースではない）に等しい場合、トランケートされたライスの２値化された文字列を表す一連のビンが解析される。提案された実施形態によれば、この文字列の第１のビンは、コンテキストベースの算術復号モードの代わりに、バイパスモードを使用して解析される。他のビンは、従来技術と同じ方法で復号される。この提案された実施形態の利点は、ＧＢｉＩｄｘ ＣＵレベルパラメータを解析する際の複雑さが軽減されることである。

上記では、インデックスが複数のビンで表されている場合、第１のビンはバイパスモードでコード化され、残りのビンは通常モードで符号化される。より一般的には、２つ以上のビン（ビン文字列の先頭）をバイパスモードで符号化でき、残りのビンは通常モードで符号化される。また、トランケートされたライス２値化は上記の例で説明されているが、提案されたコーディング方法は他の２値化スキームに適用できることに注意されたい。加えて、ＧＢｉインデックスは、上記の構文要素の例として使用される。ただし、上記の方法は他の構文要素に適用できる。

それ以外の構文要素を符号化する場合、例えば、前述のようにマージインデックスを符号化する場合は、バイパスモードと通常モードの両方が使用されることに注意されたい。特に、マージインデックスを符号化するには、第１のビンを通常モードで符号化し、これは、おそらくコンテキスト情報を使用して符号化する方が効率的であるためである。残りのビンでは、確率がよりランダムに分散される場合があり、等しい確率に対応するバイパスモードも同様に機能し得る。そのような符号化は、第１のビンがバイパスモードで符号化され、残りのビンが通常モードで符号化される、本実施形態で提案されるものと反対であることに留意されたい。

別の実施形態によれば、デフォルトＧＢｉインデックス（ＧＢＩ＿ＤＥＦＡＵＬＴ）が重み係数ｗ＝４に対応するどうかを示す、第１のフラグのみが、通常モードで符号化される。この実施形態では、そのフラグに続くトランケートされたライスビン文字列のすべてのビンは、バイパスモードで符号化される。この実施形態の利点は、ＧＢｉインデックスのコーディングおよび構文解析の複雑さがさらに軽減されることであるが、コーディング効率がわずかに低下するという犠牲を払う可能性がある。図１１Ａは、この実施形態による、提案されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘコーディング処理を示す。ステップ１１８０で、表３または表４のトランケートされたライスビン文字列のビンは、コンテキストベースの算術コーディングモードの代わりに、バイパスモードで連続的に符号化される。この提案された実施形態の利点は、ビデオ圧縮効率の点でペナルティなしに、ＣＵレベルのＧＢｉＩｄｘパラメータを符号化する際の複雑さをさらに軽減することである。

図１２Ａは、この実施形態による、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘ解析処理に対する提案された変更を示す。見てわかるように、提案されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘ解析処理の第１のステップは、図１０で説明したものと同じである。次に、最初に復号されたシンボルが０に等しい場合（非ＧＢＩ＿ＤＥＦＡＵＬＴの場合）、トランケートされたライス２値化された文字列を表す一連のビンが解析される。提案された実施形態によれば、この文字列のビンは、コンテキストベースの算術復号モードの代わりに、バイパスモードを使用して解析される（１２８０）。

表４Ａは、この提案された実施形態（図１１Ａ、図１２Ａに記載される）をｇｂｉＣｏｄｉｎｇＩｎｄｅｘコーディングに使用した場合のＶＴＭ－４．０の圧縮性能を、図１０のｇｂｉＣｏｄｉｎｇＩｎｄｅｘ解析方法と結合される、図９のｇｂｉＣｏｄｉｎｇＩｎｄｅｘコーディング方法によるＶＴＭ－４．０の性能と比較して示す。表に提示されている数値は、同じ客観的なビデオ品質での、提案された方法の平均ビットレート削減に対応している。したがって、負の数はビットレートの削減、したがってコーディング効率の向上を示し、正の数はビットレートの増加、したがってコーディング効率の低下を示す。Ｙ、Ｕ、およびＶ列はそれぞれ、輝度、彩度Ｃｂ、および彩度Ｃｒの成分に対応する。この実施形態は、図９の方法と比較して、輝度において平均ビットレート変更をもたらさず、したがって、より多くのバイパスコード化ビンの使用による複雑さの低減にもかかわらず、ビデオ圧縮効率にペナルティを導入しないことが分かる。

以下では、提案されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘコーディングおよび解析方法がコーディング効率を損なわない理由、つまり、トランケートされたライス（ＴＲ）ビン文字列から発行されたビンのバイパスコーディングがこれらのビンの算術コーディングと同じくらい効率的である理由を説明する。

算術コーディングは、シャノン限界に非常に近いビットレート、つまりそれが符号化するシンボルのエントロピーを達成することが知られているため、最適またはほぼ最適なエントロピーコーディング方法である。

処理のバイパスコーディング部分の最適性は、ｇｂｉＣｏｄｉｎｇＩｎｄｅｘのコード化に使用される２値化がハフマンツリーに密接に対応していることを意味する。これは、バイパスモードでｇｂｉＣｏｄｉｎｇＩｎｄｅｘのビンをコード化するためのＴＲ２値化が、ハフマンツリーに対応することを意味する。ハフマンコーディングは、最適な可変長コーディング方法である。さらに、ハフマンコーディングは、特定の条件が満たされた場合に、信号通知されたビンのエントロピーに等しい平均コード長を生成することが知られている。特に、ハフマンツリーの各ブランチに関連付けられた確率がダイアディックである場合、つまり、負の２の累乗、すなわち１／２^ｎ（ここで、ｎは正の整数値である）に等しい場合、ハフマンコーディングが最適である。

図１２Ｂおよび図１２Ｃの２つのツリーは、それぞれ、非低遅延モードおよび低遅延ピクチャ間コーディング構成での、提案された解決策から生じるｇｂｉＣｏｄｉｎｇＩｎｄｅｘの２値化およびコーディング／解析処理を示している。埋められたノードは通常の（コンテキストベースの）コード化されたビンに対応し、埋められていないノードはバイパスコード化されたビンに対応する。ｘを、コンテキストベースのコード化されたビンが０に等しい確率とする。図１２Ｂおよび図１２Ｃのツリーの各エッジに関連付けられた値は、２値化されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘのビンが１または０に等しい確率に対応する。例えば、２値化されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘの第２のビンが０に等しい確率は

であり、このビンが１に等しい確率も

である。図１２Ｄは、デフォルトのＧＢＩモードを信号で伝える第１のビンが０に等しいことを知っている、２値化されたｇｂｉＣｏｄｉｎｇＩｎｄｅｘのバイパスコード化されたビンのコーディング／構文解析に対応するツリーを示す。すでに説明したように、これらのビンのバイパスコーディングの最適性は、図１２Ｄのツリーが、最適であり、したがってダイアディックに関連付けられた確率値を有するハフマンコーディングツリーであることを示している。

構文要素のトランケートされたライス（ＴＲ）２値化から生じるビン文字列の確率は、常にダイアディックであるとは限らない。例えば、ＶＶＣ仕様には、トランケートされたライス２値化に続いて２値化され、構文要素ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘやｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘなど、すべてのビンがコンテキストベースでコード化されている他の構文要素がいくつかある。これらの２つのパラメータはトランケートされたライス２値化され、すべてのビンはコンテキストベースでコード化される。それらの一部をバイパスコーディングすると、圧縮効率が低下し、これは、バイパスコード化されたビンのダイアディック確率分布を伴う、対応するバイパスコーディングが最適なハフマンコーディング処理に対応していないことを示す。

この実施形態では、ＴＲ２値化後のｇｂｉＣｏｄｉｎｇＩｎｄｅｘのビン文字列の確率がダイアディックに近く、したがってバイパスコーディングパスを適用することは、最適なハフマンコーディング処理に対応する一方で、通常モードにおける算術コーディングよりも計算の複雑さが低いことを認識する。

動きベクトル予測因子のシグナリング
ＶＶＣドラフト４のＡＭＶＰモードでの動きベクトル予測コーディング
ＡＭＶＰ動きベクトルコーディングモードは、次の要素を使用してＣＵの動きベクトルをコーディングすることに関連している。
－インター予測方向であり、現在のＣＵを予測するためにバイ予測またはユニ予測が使用されているかどうかを示し、ユニ予測の場合はどの参照ピクチャリストが使用されているかを示す。
－参照ピクチャインデックス（複数可）であり、関与する各参照ピクチャリストで、どの参照ピクチャ（複数可）が現在のＣＵを予測するために使用されているのかを示す。
－動きベクトル予測因子であり、現在のＣＵを予測するために使用される各参照ピクチャについて、現在のＣＵの実際の動きベクトルを予測するために使用される。このＭＶ予測因子（またはＭＶＰ、またはＡＭＶＰ候補）は、２つの候補を含むＭＶ予測因子リストの符号化器によって選択される。どのＭＶ候補が選択されたかは、関連する参照ピクチャリストＬ０およびＬ１ごとに、それぞれｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇと記されたフラグを介して信号通知される。
－動きベクトルであり、各参照ピクチャリストＬ０およびＬ１ごとに、現在のＣＵの実際の動きベクトルとそれぞれの動きベクトル予測因子との間の差である。

ＡＭＶＰ動きベクトル予測候補リストの構成を図１３および図１４に示す。この処理は基本的に、現在のＣＵの周囲の５つの空間位置から最大２つの空間候補を選択し、それらを剪定して最大２つを維持することで構成される。次に、現在のスライスのいわゆる併置されたスライスにおいて、右下の位置Ｈに対応する空間位置で、または利用できない場合は中心位置「中心」で、時間的ＭＶ予測候補が求められる。次に、剪定処理が空間候補と時間候補の間に適用され、リストは全体で最大２つの要素までゼロの動きベクトルで埋められる。最終的に、ＡＭＶＰ候補リストには正確に２つの動きベクトル予測候補が含まれる。

したがって、それぞれｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇと記された単一のフラグがビットストリームで信号通知され、復号器側で解析されて、ＡＭＶＰリストに含まれる２つの要素のうちどのＡＭＶＰ候補が、各参照ピクチャリストＬ０およびＬ１における現在のＣＵの動きベクトルを予測するために使用されるかを示す。

考慮される参照ピクチャリストＬ０またはＬ１に応じて、フラグｍｖｐ＿ｌ０＿ｆｌａｇまたはｍｖｐ＿ｌ１＿ｆｌａｇを解析する処理が図１５に示されている。これは、２値シンボル「シンボル」のコンテキストベースの算術復号（１５１０）で構成される。これは、単一のＣＡＢＡＣコンテキストを採用している。考慮される参照ピクチャリスト内の現在のＰＵまたはＣＵのＭＶ予測因子インデックスには、復号されたシンボルの値が与えられる（ＰＵは、ＨＥＶＣにて使用されているように、現在のＣＵ内の動きパーティションであり得、ＶＶＣドラフト４において、ＰＵパーティショニングが使用されないので、ＰＵはＣＵに対応する）（１５２０）。

提案されている方法：バイパスモードにおけるｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇのコーディング

複数のコード化されたビデオシーケンスにわたって、ｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇ構文要素を信号通知する、ＣＡＢＡＣに使用される平均エントロピーが１ビットの情報に非常に近いことが測定されているが、これは、単純なバイパスコーディング処理と比較して、これらのフラグのＣＡＢＡＣコーディングによって利益がもたらされないことを意味する。

したがって、本実施形態では、バイパスコーディングモードを介してこれらのフラグを符号化および解析することが提案される。図１６は、１つの所与の参照ピクチャリストについて、１つのＣＵまたはＰＵのＭＶ予測因子インデックスを復号する（１６１０、１６２０）ために提案された解析処理を示している。図１５の処理との違いは、関係するビンのＣＡＢＡＣ復号が、このビンのバイパス復号によって置き換えられることである（１６１０）。符号化器側では、ｍｖｐ＿ｌ０＿ｆｌａｇまたはｍｖｐ＿ｌ１＿ｆｌａｇを表す２値シンボルがバイパスモードで符号化される。この実施形態の利点は、コーディング効率への影響はほとんどなく、ＶＶＣのコーディングおよび解析処理の複雑さが軽減されることである。

さらなる実施形態によれば、ｍｖｐ＿ｌ０＿ｆｌａｇは、考慮されるＣＵがＳＭＶＤ（対称動きベクトル差）モードでコード化されているか否かに応じて、異なる方法でコード化され得る。ＶＶＣのＳＭＶＤ動きベクトルコーディング処理は、第１の参照ピクチャリストＬ０に関して所与のＣＵの動きベクトル差をコード化することからなる。次に、他の参照ピクチャリスト（Ｌ１）において考慮されたＣＵの動きベクトル差が、Ｌ０の動きベクトル差から導き出される。実際、このモードにおいては、２つの動きベクトルは対称である。Ｌ１動きベクトルは、両方の成分でＬ０動きベクトルの反対に等しくなる。この実施形態では、ＳＭＶＤの場合のＭＶＰ候補は、通常モードで符号化され得、一方、従来のＡＭＶＰ動きベクトルコーディングモードのＭＶＰ候補は、バイパスモードでコード化され得る。これは、古典的なｍｖｐ＿ｌ０＿ｆｌａｇとｓｍｖｄ＿ｍｖｐ＿ｌ０ｆｌａｇの２つの別個の構文要素を指定できることを意味し、後者は、ＳＭＶＤモードでＣＵの動きベクトルを予測するために使用されるＭＶを指定するために使用される。

別の実施形態によれば、古典的なｍｖｐ＿ｌ０＿ｆｌａｇは通常モードでコード化され得、一方、ｓｍｖｄ＿ｍｖｐ＿ｌ０ｆｌａｇはバイパスモードでコード化され得る。変形によれば、古典的なｍｖｐ＿ｌ０＿ｆｌａｇは通常モードでコード化され得、ｓｍｖｄ＿ｍｖｐ＿ｌ０ｆｌａｇは、通常モードでもコード化されるが、通常のｍｖｐ＿ｌ０＿ｆｌａｇのコード化に使用されるＣＡＢＡＣコンテキストとは別個のコンテキストを用いる場合がある。

表５に、ＶＶＣドラフト４構文を例として使用して、上記で提案した方法によって構文に加えられた変更の例を示す。特に、構文要素ｍｖｐ＿ｌ０＿ｆｌａｇおよびｍｖｐ＿ｌ１＿ｆｌａｇの記述子がａｅ（ｖ）からｕ（１）に変更されており、ここで、ａｅ（ｖ）はコンテキスト適応型算術エントロピーコード化構文要素を示し、ｕ（ｎ）はｎビットを使用した符号なし整数を示す。

表６は、上記で提案した複雑さの軽減の面で得られた性能結果を示している。提案された簡略化による圧縮効率の変化がほとんどないことがわかる。

上記では、ＶＶＣドラフト４に関する例が説明されている。以下では、サブブロック間変換のシグナリング、イントラサブパーティション（ＩＳＰ）コーディングモード、複数の基準線イントラ予測、およびツール間のＳＭＶＤ（対称動きベクトル差）を含むいくつかの例について、ＶＶＣドラフト５に関して説明されている（「ＶｅｒｓａｔｉｌｅＶｉｄｅｏ Ｃｏｄｉｎｇ（Ｄｒａｆｔ ５）」、Ｂ．Ｂｒｏｓｓ ｅｔ ａｌ．、１４ｔｈ ＪＶＥＴ ｍｅｅｔｉｎｇ、Ｍａｒｃｈ１９－２７， ２０１９、Ｇｅｎｅｖａ，ＣＨを参照）。

サブブロック変換のシグナリング
ＶＶＣドラフト５のサブブロック変換（ＳＢＴ）
非ゼロの残差ブロックとして信号通知されるインター予測されたＣＵの場合、ＳＢＴツールはＣＵを２値方式で２つの変換ユニット（ＴＵ）に分割する。結果として得られる２つのＴＵの一方は非ゼロの残差を有し、他方はゼロの残差データのみを有する。適用される２値分割は、対称または非対称であり得る。対称分割の場合、結果として得られる２つのＴＵは等しいサイズを有し、これは、分割の方向においてＣＵのサイズの半分である。非対称２値分割の場合、一方のＴＵのサイズは分割方向に沿った１／４または親ＣＵに等しく、他方のＴＵサイズは分割方向に沿ったＣＵのサイズの３／４である。

空間分割に加えて、残差が非ゼロのＴＵは、推定適応変換でコード化される。使用される１Ｄ変換は、図１７に示されるように、非ゼロ残差ＴＵの位置に依存し、ここで、部分「Ａ」は、非ゼロ残差データを有するＴＵであり、他のＴＵは、ゼロ残差データのみを有する。

考慮されるコーディングユニットのＴＵ分割は、３つのフラグを介して信号通知される。まず、ｃｕ＿ｓｂｔ＿ｆｌａｇは、考慮されるＣＵにＳＢＴを使用することを示している。次に、ＳＢＴを使用する場合、ＳＢＴタイプおよびＳＢＴ位置情報が信号通知される。これは、次の３つのコード化されたフラグの形式を取る。
－ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇは、非対称２値分割の使用を示す。現在のＣＵで対称分割と非対称分割の両方が許容されている場合にコード化される。
－ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇは、２値分割の方向を示す。現在のＣＵ、および以前に信号通知されたＳＢＴ分割タイプ（非対称か否か）に対して、ホットゾーン分割と垂直分割の両方が許容されている場合にコード化される。
－ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇは、考慮されるＣＵのテクスチャデータをコード化するために使用される非ゼロの残差ＴＵの位置を示す。

ＶＶＣドラフト５では、上記の４つのフラグはコンテキストベースでコード化されている。この態様に対応するＶＶＣ仕様の部分を表７に示す。

図１８は、ＶＶＣドラフト５で指定されたＳＢＴモードの復号処理を示している。ステップ１８１０で、ｃｕ＿ｓｂｔ＿ｆｌａｇを復号するためのコンテキストＩＤは、ｃｔｘＩｄ＝（幅＊高さ）＜＝２５６？１：０として取得される。次に、ステップ１８２０で、２値シンボルｃｕ＿ｓｂｔ＿ｆｌａｇは、コンテキストｃｔｘＩｄによりＣＡＢＡＣ復号される。ｃｕ＿ｓｂｔ＿ｆｌａｇが０に等しい場合（１８３０）、サブブロック変換ツールは使用されない。それ以外の場合、ｃｕ＿ｓｂｔ＿ｆｌａｇが０でない場合、２値シンボルｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇは、ステップ１８４０において、コンテキストｃｔｘＩｄ＝０によりＣＡＢＡＣ復号される。ステップ１８５０で、復号器は、現在のＣＵに対して垂直および水平分割が許容されているか否かをチェックする。はいの場合、ステップ１８６０にて、ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇを復号するコンテキストｉｄはｃｔｘＩｄ＝（ｃｕＷｉｄｔｈ＝＝ｃｕＨｅｉｇｈｔ）？ ０：（ｃｕＷｉｄｔｈ＜ｃｕＨｅｉｇｈｔ？１：２）として取得される。次に、ステップ１８７０にて、２値シンボルｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇは、コンテキストｃｔｘＩｄによりＣＡＢＡＣ復号される。ステップ１８８０にて、２値シンボルｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇは、コンテキストｃｔｘＩｄ＝０によりＣＡＢＡＣ復号される。処理はステップ１８９９において終了する。

ＳＢＴモードの簡略化されたコーディング
提案された実施形態によれば、「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」は、通常の（コンテキストベースの）ＣＡＢＡＣモードの代わりにバイパスモードでコード化される。実際、「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」のこの簡略化されたコーディングは、エントロピーコーディングを簡略化しながら、コーデックのコーディング効率全体にほとんど影響を与えない。

別の実施形態によれば、「ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ」は、通常モードではなくバイパスモードでコード化される。この簡略化も、コーデックの性能にほとんど影響を与えない。

別の実施形態によれば、「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」および「ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ」の両方が、通常モードではなくバイパスモードでコード化される。

別の実施形態によれば、「ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇ」は、通常モードではなくバイパスモードでコード化される。この簡略化も、コーデックの性能にほとんど影響を与えない。

別の実施形態によれば、３つのフラグ「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」、「ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ」、および「ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇ」は、通常モードではなくバイパスモードでコード化される。表８のシミュレーション結果に示されているように、この全体的な変更から生じるコーディング効率の損失はほとんどない。

図１９Ａは、「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」および「ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ」の両方がバイパスモードでコード化される（１９４０、１９８０）実施形態による復号処理を示す。図１９Ｂは、３つのフラグ「ｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇ」、「ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ」および「ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇ」がバイパスモードでコード化される実施形態による復号処理を示す。

ＶＶＣドラフト５の標準構文仕様は、表１０に示すように変更できる。特に、構文要素ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇおよびｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇの記述子は、ａｅ（ｖ）からｕ（１）に変更される。

イントラサブパーティションコーディングモードのシグナリング
ＶＶＣドラフト５におけるイントラサブパーティション
ＶＶＣドラフト５で指定されているイントラサブパーティション（ＩＳＰ）コーディングモードは、ＩＮＴＲＡ ＣＵを水平または垂直に２つまたは４つのサブパーティションに分割できる。表１１に示すように、分割はブロックサイズによって異なる。基本的に、４ｘ４ＣＵをさらに分割することはできない。サイズ４ｘ８または８ｘ４のＣＵは、２つのＴｕ（つまり、サブパーティション）に分割される。他のＣＵは４つのＴｕに分割される。

図２０Ａは、４ｘ８および８ｘ４のＩＮＴＲＡコーディングユニットに対して許容されるＩＳＰ分割を示し、図２０Ｂは、４ｘ８または８ｘ４とは異なるサイズのＩＮＴＲＡコーディングユニットに対して許容されるＩＳＰ分割を示す。ＩＳＰモードでコード化されたＣＵの内部では、ＴＵは順次復号され、ＣＵレベルで信号通知される同じイントラ予測モードを使用してＴＵからＴＵへイントラ予測される。最後に、残りのコーディングもサブパーティション内のサイズに応じて適合される。実際、サブパーティションはサイズ１ｘＮ、Ｎｘ１、２ｘＮ、またはＮｘ２であり得、サイズ１ｘ１６、１ｘ１、２ｘ１６、または１６ｘ２のコーディンググループがこれらのそれぞれの場合に使用される。

ＩＳＰコーディングモードは、ＶＶＣドラフト５の２つの連続するフラグを介して信号通知される。
－ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇは、所与のイントラＣＵにＩＳＰモードを使用することを示す。
－ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇは、イントラサブパーティションへの分割の方向を示す。

上記の２つのフラグは、以下のように、考慮されるＣＵに関連付けられた「ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅ」の値を復号するために使用される。
ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅ＝ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ＝＝０？０：（１＋ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ）
「ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅ」値の意味を表１２に示す。

これらの２つのフラグは、表１３に示すように、ＶＶＣドラフト５に従ってコンテキストベースでコード化されている。

ＩＳＰモードの簡略化されたコーディング
一実施形態では、ビン「ｉｎｔｒａ＿ｓｕｂｐａｒｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」、すなわち、ＣＵのＩＳＰモードをコード化するために使用される第２のフラグは、バイパスモードでコード化される。この実施形態に関連するＶＶＣドラフト５仕様への変更は、表１４および表１５に示されている。特に、構文要素「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」の記述子がａｅ（ｖ）からｕ（１）に変更される。

複数の基準線イントラ予測のシグナリング
ＶＶＣドラフト５の複数の基準線イントラ予測
ＶＶＣドラフト５のＩＮＴＲＡ ＣＵで使用される複数の基準線イントラ予測は、３つの基準線から選択された現在のＣＵの左上の１つの基準線と列に属する再構築された参照サンプルに基づいて輝度ブロックの角度イントラ予測を実行する。イントラ予測に使用される基準線は、構文要素「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」を介してビットストリームで信号通知される。各基準線は、図２１に示すように、そのインデックスによって識別される。ＶＶＣドラフト５で実際に使用される基準は、図２１に示される線０、線１、および線３である。この構文要素は、イントラ予測モードの前に信号通知される。基準線が線０と異なる場合、つまりＣＵに最も近い線の場合。

「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」は次のようにコード化されている。トランケートされたライスビン文字列として２値化される。これは、１に等しい一連の通常のＣＡＢＡＣビンによってコード化され、０に等しい通常のＣＡＢＡＣビンで終了することを意味する。全体として、最大３つのビンが信号通知される。

ＶＶＣドラフト５による「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」の復号処理を図２２に示す。図２２では、最大４本の基準線を伴う一般的な処理が使用されている。配列ｌｉｎｅＩＤｘ［．］は、４つの線基準インデックスで構成され、値「ＭａｘＮｕｍＲｅｆＬＩｎｅｓ」は、イントラ予測で許容される基準線の最大数を表す。「ＭａｘＮｕｍＲｅｆＬＩｎｅｓ」はＶＶＣの場合は３に等しく、配列ｌｉｎｅＩｄｘは以下の要素で構成される。
ｌｉｎｅＩｄｘ＝｛０、１、３｝。

構文要素「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」のＶＶＣ復号処理は以下のように進められる。処理の出力は、復号されたｍｕｌｔｉＲｅｆＩｄｘである。特に、ステップ２２１０において、それは、現在のＣＵに対して複数の基準線が許容されているか否かをチェックする。はいの場合、出力値ｍｕｌｔｉＲｅｆＩｄｘは０に初期化される（２２２０）。ＭａｘＮｕｍＲｅｆＬｉｎｅｓが１より大きくない場合（２２２５）、処理は終了する。それ以外の場合、ステップ２２３０で、ＣＡＢＡＣ通常ビンがインデックス０の単一のＣＡＢＡＣコンテキストで解析される。０に等しい場合、ｍｕｌｔｉＲｅｆＩｄｘ値は変更されず、処理は終了する。それ以外の場合、ｍｕｌｔｉＲｅｆＩｄｘは、ｌｉｎｅＩｄｘ［１］と等しく設定される。

ＭａｘＮｕｍＲｅｆＬｉｎｅｓが２よりも厳密に高い場合（２２５０）、ステップ２２５５で、第２の通常のＣＡＢＡＣビンは、識別子１の単一のコンテキストで復号される。復号されたビンが０の場合、ｍｕｌｔｉＲｅｆＩｄｘは変更されず、処理は終了する。それ以外の場合、ｍｕｔｉＲｅｆＩｄｘはｌｉｎｅＩｄｘ［２］と等しく設定される（２２６０）。ＭａｘＮｕｍＲｅｆＬｉｎｅｓが３よりも厳密に高い場合（２２７０）、第３の通常のＣＡＢＡＣビンが識別子２の単一のコンテキストで復号される（２２８０）。復号されたビンが０の場合、ｍｕｌｔｉＲｅｆＩｄｘは変更されず、処理は終了する（２２９９）。それ以外の場合、ｍｕｔｉＲｅｆＩｄｘはｌｉｎｅＩｄｘ［３］と等しく設定される（２２９０）。ＶＶＣドラフト５用に選択された設計では、上述したように最大３つの基準線を使用できるため、実際には、このステップはＶＶＣドラフト５仕様に従って行われないことに留意されたい。したがって、条件付きの「ＭａｘＮｕｍＲｅｆＬｉｎｅｓ＞３」は、ＶＶＣドラフト５の範囲では常に誤りである。

すでに説明され、表１６に示されているように、ＶＶＣドラフト５のｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ構文要素を信号通知するように、２つの通常のコード化されたビンが使用されて、各ビンは単一のＣＡＢＡＣコンテキストを使用する。

複数の基準線インデックスの簡略化されたコーディング
一実施形態では、「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ」構文要素のコーディングは簡略化され、この構文要素の第１のビンのみが通常モードでコード化される。この構文要素に対して提案された変更された構文解析処理が図２３に示されている。特に、ステップ２３５５および２３８０において、第２のビンおよび第３のビンは、バイパスモードで復号される。他のステップは、図２２に示されるものと同様である。

この実施形態にしたがって、ＶＶＣドラフト５仕様は表１７に示すように変更できる。

ＳＭＶＤフラグのシグナリング
ＶＶＣドラフト５のＳＭＶＤフラグ
ｓｙｍ＿ｍｖｄ＿ｆｌａｇ構文要素は、ＩＮＴＥＲコーディングユニットに対称的な動きベクトル差を使用することを示す。ＶＶＣのＳＭＶＤ動きベクトルコーディング処理は、第１の参照ピクチャリストＬ０に関して所与のＣＵの動きベクトル差をコード化する。次に、他の参照ピクチャリスト（Ｌ１）において考慮されたＣＵの動きベクトル差が、Ｌ０の動きベクトル差から導き出される。実際、このモードでは、２つの動きベクトルの差は対称的である。Ｌ１動きベクトル差は、ｘ成分とｙ成分の両方で、Ｌ０動きベクトル差の反対に等しくなる。ＶＶＣドラフト５では、このｓｙｍ＿ｍｖｄ＿ｆｌａｇは、単一のＣＡＢＡＣコンテキストを使用する通常のＣＡＢＡＣモードでコード化および復号される。

ＳＭＶＤフラグの簡略化されたコーディング
一実施形態では、バイパスモードでこのフラグを符号化および復号することが提案されている。提案された簡略化は、ＶＶＣの圧縮効率に影響を与えない。この実施形態によれば、ＶＶＣドラフト５構文仕様は、表１８に示されるように変更することができる。特に、ｓｖｍ＿ｍｖｄ＿ｆｌａｇの記述子がａｅ（ｖ）からｕ（１）に変更される。

様々な方法が、本明細書に記載されており、それらの方法のそれぞれは、説明された方法を達成するための１つ以上のステップまたは行為を含む。本方法の正しい動作のために特定の順序のステップまたは行為が必要でない限り、特定のステップおよび／または行為の順序および／または使用は、変更されてもよく、または組み合わせられてもよい。

本出願に説明されている様々な方法および他の態様を使用して、図１および図４に示されるように、モジュール、例えば、ビデオ符号化器１００および復号器２００のエントロピー符号化および復号モジュール（１４５、２３０）を変更することができる。さらに、本態様は、ＶＶＣまたはＨＥＶＣに限定されるものではなく、例えば、他の標準規格および推奨、ならびに任意のそのような標準規格および推奨の拡張版に適用することができる。特に指示されていない限り、または技術的に除外されていない限り、本出願で説明される態様は、個別にまたは組み合わせて使用することができる。

本出願では様々な数値が使用され、例えば、コンテキストモデルＩＤが使用されている。特定の値は、例示的な目的のためであり、記載された態様は、これらの特定の値に限定されるものではない。

図２４は、様々な態様および実施形態が実装されるシステムの一例のブロック図を示す。システム２４００は、以下で説明される様々な構成要素を含む装置として具体化することができ、本出願で説明される態様の１つ以上を実行するように構成される。そのような装置の例は、これらに限定されるものではないが、パーソナルコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、デジタルマルチメディアセットトップボックス、デジタルテレビ受像機、パーソナルビデオ録画システム、コネクテッド家電、およびサーバなどの様々な電子装置を含む。システム２４００の要素は、単独でも組み合わせでも、単一の集積回路、複数のＩＣ、および／または別個の構成要素に具体化することができる。例えば、少なくとも１つの実施形態において、システム２４００の処理および符号化器／復号器要素は、複数のＩＣおよび／または個別の構成要素にわたって分散している。様々な実施形態において、システム２４００は、他のシステムに、または他の電子装置に、例えば、通信バスを介して、または専用の入力および／または出力ポートを通して、通信可能に結合される。様々な実施形態において、システム２４００は、本出願に記載の態様のうちの１つ以上を実装するように構成される。

システム２４００は、例えば、本出願に記載の様々な態様を実装するために、そこにロードされる命令を実行するように構成された少なくとも１つのプロセッサ２４１０を含む。プロセッサ２４１０は、埋め込みメモリ、入力出力インターフェース、および当該技術分野において知られているような他の様々な回路を含むことができる。システム２４００は、少なくとも１つのメモリ２４２０（例えば、揮発性メモリ装置、および／または不揮発性メモリ装置）を含む。システム２４００は、これらに限定されるものではないが、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、フラッシュ、磁気ディスクドライブ、および／または光ディスクドライブを含む、不揮発性メモリおよび／または揮発性メモリを含むことができる記憶装置２４４０を含む。記憶装置２４４０は、非限定的な例として、内部記憶装置、付属記憶装置、および／またはネットワークアクセス可能記憶装置を含むことができる。

システム２４００は、例えば、符号化されたビデオまたは復号されたビデオを提供するようにデータを処理するように構成された符号化器／復号器モジュール２４３０を含み、符号化器／復号器モジュール２４３０は、独自のプロセッサおよびメモリを含むことができる。符号化器／復号器モジュール２４３０は、符号化および／または復号機能を実行する装置に含まれ得るモジュール（複数可）を表す。公知であるように、装置は、符号化モジュールおよび復号モジュールの一方または両方を含むことができる。さらに、符号化器／復号器モジュール２４３０は、システム２４００の別個の要素として実装されてもよく、または、当業者にとって公知のハードウェアとソフトウェアとの組み合わせとしてプロセッサ２４１０内に組み込まれてもよい。

本出願に記載の様々な態様を実行するようにプロセッサ２４１０または符号化器／復号器２４３０にロードされることになるプログラムコードは、記憶装置２４４０に記憶され、続いて、プロセッサ２４１０による実行のためにメモリ２４２０上にロードされ得る。様々な実施形態によれば、プロセッサ２４１０、メモリ２４２０、記憶装置２４４０、および符号化器／復号器モジュール２４３０のうちの１つ以上は、本出願に記載の処理の実行中、様々な項目のうちの１つ以上を記憶することができる。そのような記憶される項目は、これらに限定されるものではないが、入力ビデオ、復号されたビデオまたは復号されたビデオの一部、ビットストリーム、行列、変数、ならびに方程式、式、演算、および演算ロジックの処理からの中間結果または最終結果を含むことができる。

いくつかの実施形態において、プロセッサ２４１０および／または符号化器／復号器モジュール２４３０内のメモリは、命令を記憶し、符号化または復号中に必要となる処理のためのワーキングメモリを提供するために使用される。しかしながら、他の実施形態において、処理装置（例えば、処理装置は、プロセッサ２４１０または符号化器／復号器モジュール２４３０のいずれかとすることができる）の外部のメモリは、これらの機能のうちの１つ以上のために使用される。外部メモリは、メモリ２４２０および／または記憶装置２４４０とすることができ、例えば、ダイナミック揮発性メモリおよび／または不揮発性フラッシュメモリとすることができる。いくつかの実施形態において、テレビのオペレーティングシステムを記憶するために外部不揮発性フラッシュメモリが使用される。少なくとも１つの実施形態において、ＭＰＥＧ－２、ＨＥＶＣ、またはＶＶＣなど、ビデオコーディングおよび復号動作のために、ＲＡＭなどの高速外部ダイナミック揮発性メモリがワーキングメモリとして使用される。

システム２４００の要素への入力は、ブロック２４０５に示されるような様々な入力装置を介して提供され得る。そのような入力装置は、これらに限定されるものではないが、（ｉ）例えば、ブロードキャスタによって無線を介して送信されたＲＦ信号を受信するＲＦ部、（ｉｉ）コンポジット入力端子、（ｉｉｉ）ＵＳＢ入力端子、および／または（ｉｖ）ＨＤＭＩ入力端子を含む。

様々な実施形態において、ブロック２４０５の入力装置は、当技術分野で周知であるような関連するそれぞれの入力処理要素を有する。例えば、ＲＦ部は、（ｉ）所望の周波数を選択する（信号を選択する、またはある周波数帯域に信号を帯域制限する、とも称される）こと、（ｉｉ）選択された信号をダウンコンバートすること、（ｉｉｉ）（例えば）ある特定の実施形態ではチャネルと称される場合がある信号周波数帯域を選択するように、より狭い周波数帯域に再び帯域制限すること、（ｉｖ）ダウンコンバートされて帯域制限された信号を復調すること、（ｖ）誤り訂正を実行すること、および（ｖｉ）逆多重化して所望のデータパケットストリームを選択することに適した要素に関連付けることができる。様々な実施形態のＲＦ部は、これらの機能を実行する１つ以上の要素、例えば、周波数セレクタ、信号セレクタ、帯域リミッタ、チャネルセレクタ、フィルタ、ダウンコンバータ、復調器、誤り訂正器、およびデマルチプレクサを含む。ＲＦ部は、例えば、受信された信号をより低い周波数に（例えば、中間周波数またはベースバンドに近い周波数）、またはベースバンドにダウンコンバートすることを含む、様々なこれらの機能を実行するチューナを含むことができる。１つのセットトップボックスの実施形態において、ＲＦ部およびその関連付けられた入力処理要素は、有線（例えば、ケーブル）媒体経由で送信されたＲＦ信号を受信し、フィルタリングし、ダウンコンバートし、所望の周波数帯域に再びフィルタリングすることによって、周波数選択を実行する。様々な実施形態は、上記（および他の）要素の順序を並べ替え、これらの要素のうちのいくつかを取り除き、および／または同様もしくは異なる機能を実行する他の要素を追加する。要素を追加することは、既存の要素間に要素を挿入すること、例えば、増幅器およびアナログ－デジタル変換器を挿入することを含むことができる。様々な実施形態において、ＲＦ部は、アンテナを含む。

さらに、ＵＳＢおよび／またはＨＤＭＩ端子は、ＵＳＢおよび／またはＨＤＭＩ接続にわたって他の電子装置にシステム２４００を接続するためのそれぞれのインターフェースプロセッサを含むことができる。入力処理の様々な態様、例えば、リード・ソロモン誤り訂正を、例えば、必要に応じて、別個の入力処理ＩＣ内またはプロセッサ２４１０内に実装できることを理解されたい。同様に、ＵＳＢまたはＨＤＭＩインターフェース処理の態様を、必要に応じて、別個のインターフェースＩＣ内またはプロセッサ２４１０内に実装できる。復調され、誤り訂正され、かつ逆多重化されたストリームは、例えば、プロセッサ２４１０と、出力装置上での表示用に、必要に応じてデータストリームを処理するためにメモリおよび記憶要素と組み合わせて動作する符号化器／復号器２４３０と、を含む様々な処理要素に提供される。

システム２４００の様々な要素は、一体型ハウジング内に提供することができ、一体型ハウジング内では、様々な要素が相互接続され、好適な接続配置２４１５、例えば、Ｉ２Ｃバス、配線、およびプリント回路基板を含む、当該技術分野において知られているような内部バスを使用して、それらの間でデータを送信することができる。

システム２４００は、通信チャネル２４９０を介して他の装置との通信を可能にする通信インターフェース２４５０を含む。通信インターフェース２４５０は、これに限定されるものではないが、通信チャネル２４９０経由でデータを送受信するように構成されたトランシーバを含むことができる。通信インターフェース２４５０は、これらに限定されるものではないが、モデムまたはネットワークカードを含むことができ、通信チャネル２４９０は、例えば、有線および／または無線媒体内に実装することができる。

様々な実施形態において、データは、ＩＥＥＥ８０２．１１などのＷｉ－Ｆｉネットワークを使用して、システム２４００にストリーミングされる。これらの実施形態のＷｉ－Ｆｉ信号は、Ｗｉ－Ｆｉ通信に適合された通信チャネル２４９０および通信インターフェース２４５０を介して受信される。これらの実施形態の通信チャネル２４９０は、アプリケーションをストリーミングすることおよび他のオーバー・ザ・トップ通信を可能にするインターネットを含む外部ネットワークへのアクセスを提供するアクセス点またはルータに通常接続される。他の実施形態は、入力ブロック２４０５のＨＤＭＩ接続経由でデータを配信するセットトップボックスを使用して、ストリーミングされたデータをシステム２４００に提供する。さらに他の実施形態は、入力ブロック２４０５のＲＦ接続を使用して、ストリーミングされたデータをシステム２４００に提供する。

システム２４００は、ディスプレイ２４６５、スピーカ２４７５、および他の周辺装置２４８５を含む、様々な出力装置に出力信号を提供することができる。他の周辺装置２４８５には、様々な実施形態例において、スタンドアローンＤＶＲ、ディスクプレーヤ、ステレオシステム、照明システム、およびシステム２４００の出力に基づき、機能を提供する他の装置のうちの１つ以上が含まれる。様々な実施形態において、システム２４００と、ディスプレイ２４６５、スピーカ２４７５、または他の周辺装置２４８５との間で、ＡＶリンク、ＣＥＣ、またはユーザの介入の有無に関わらず、デバイス・ツー・デバイス制御を可能にする他の通信プロトコルなどの信号通知を使用して、制御信号が伝送される。出力装置は、それぞれのインターフェース２４６０、２４７０、および２４８０による専用接続を介してシステム２４００に通信可能に結合することができる。あるいは、出力装置は、通信インターフェース２４５０を介して、通信チャネル２４９０を使用してシステム２４００に接続することができる。ディスプレイ２４６５およびスピーカ２４７５は、例えば、テレビなどの電子装置内のシステム２４００の他の構成要素と、単一のユニット内に一体化することができる。様々な実施形態において、ディスプレイインターフェース２４６０には、ディスプレイドライバ、例えば、タイミングコントローラ（Ｔ Ｃｏｎ）チップが含まれる。

ディスプレイ２４６５およびスピーカ２４７５は、例えば、入力２４０５のＲＦ部が別個のセットトップボックスの一部である場合、他の構成要素のうちの１つ以上から代替的に分離することができる。ディスプレイ２４６５およびスピーカ２４７５が外部構成要素である様々な実施形態において、例えば、ＨＤＭＩポート、ＵＳＢポート、またはＣＯＭＰ出力を含む、専用出力接続を介して出力信号を提供することができる。

一実施形態によれば、ビデオ復号の方法が提供され、方法は、ビットストリームから複数の２値シンボルを復号することであって、複数の２値シンボルの第１の２値シンボルは、エントロピー復号エンジンのバイパスモードを使用して復号される、復号することと、２値化スキームに基づいて、複数の２値シンボルに応答する構文要素の値を生成することとを含む。

一実施形態によれば、ビデオ符号化の方法が提供され、構文要素の値を示す複数の２値シンボルにアクセスすることと、複数の２値シンボルを符号化することとを含み、複数の２値シンボルの第１の２値シンボルは、エントロピー符号化エンジンのバイパスモードを使用して符号化される。

別の実施形態によれば、１つ以上のプロセッサを含むビデオ復号のための装置が提供され、１つ以上のプロセッサは、ビットストリームから複数の２値シンボルを復号することであって、複数の２値シンボルの第１の２値シンボルは、エントロピー復号エンジンのバイパスモードを使用して復号される、２値シンボルを復号し２値化スキームに基づいて、複数の２値シンボルに応答する構文要素の値を生成するように構成される。装置は、さらに、１つ以上のプロセッサに結合された１つ以上のメモリを備えることができる。

別の実施形態によれば、１つ以上のプロセッサを含むビデオ符号化のための装置が提供され、１つ以上のプロセッサは、構文要素の値を示す複数の２値シンボルにアクセスし、複数の２値シンボルを符号化するように構成され、複数の２値シンボルの第１の２値シンボルは、エントロピー符号化エンジンのバイパスモードを使用して符号化される。

別の実施形態によれば、ビデオ復号の装置が提供され、ビットストリームから複数の２値シンボルを復号するための手段であって、複数の２値シンボルの第１の２値シンボルは、エントロピー復号エンジンのバイパスモードを使用して復号される、復号するための手段と、２値化スキームに基づいて、複数の２値シンボルに応答する構文要素の値を生成するための手段とを含む。

別の実施形態によれば、ビデオ符号化の装置が提供され、構文要素の値を示す複数の２値シンボルにアクセスするための手段と、複数の２値シンボルを符号化するための手段とを含み、複数の２値シンボルの第１の２値シンボルは、エントロピー符号化エンジンのバイパスモードを使用して符号化される。

別の実施形態によれば、符号化されたビデオを含む信号が、構文要素の値を示す複数の２値シンボルにアクセスすることと、複数の２値シンボルを符号化することとを実行することによって形成され、複数の２値シンボルの第１の２値シンボルは、エントロピー復号エンジンのバイパスモードを使用して符号化される。

一実施形態によれば、複数の２値シンボルの１つ以上の他の２値シンボルは、バイパスモードを使用して復号または符号化される。

一実施形態によれば、複数の２値シンボルの残りは、コンテキストベースで復号または符号化される。複数の２値シンボルの残りの各２値シンボルは、異なるコンテキストモデルを使用し得る。別の実施形態では、複数の２値シンボルのすべての２値シンボルは、バイパスモードを使用して復号または符号化される。

一実施形態によれば、２値フラグは、コンテキストベースの符号化または復号され、構文要素の値は、２値フラグにさらに応答して生成される。

一実施形態では、フラグは、ブロックの２つの時間的予測因子の重み付け平均を生成する際に等しい重みが適用されるか否かを示す。

一実施形態によれば、構文要素は、ブロックの２つの時間的予測因子の重み付け平均を生成する際に使用される重みのインデックスを示す。

一実施形態では、構文要素は、ブロックの動きベクトルを符号化または復号するためにどの動きベクトル予測因子が使用されるかを示す。

一実施形態では、ＳＭＶＤ（対称動きベクトル差）がブロックに適用されるかどうかが決定され、バイパスモードは、ＳＭＶＤがブロックに適用される場合にのみ使用される。

一実施形態では、トランケートされたライス２値化が２値化スキームとして使用される。

一実施形態にいて、サブブロック変換が使用される場合に、現在のコーディングユニットのテクスチャデータをコード化するために使用される非ゼロ残差変換ユニットの位置を示す構文要素が、バイパスモードで符号化および復号される。

一実施形態では、非対称２値分割がサブブロック変換で使用されるか否かを示す構文要素は、バイパスモードで符号化および復号される。

一実施形態では、サブブロック変換で使用される２値分割の方向を示す構文要素は、バイパスモードで符号化および復号される。

一実施形態では、現在のコーディングユニットをサブパーティション内に分割する方向を示す構文要素は、バイパスモードで符号化および復号される。

一実施形態では、どの基準線がイントラ予測に使用されるかを示す構文要素を表すために使用される第１のビンは、通常モードで符号化および復号され、構文要素を表すために使用される１つ以上の残りのビンは、バイパスモードで符号化および復号される。

一実施形態において、対称動きベクトル差コーディングモードが現在のコーディングユニットに使用されるか否かを示す構文要素は、バイパスモードで符号化および復号される。

実施形態は、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、上述した実施形態のいずれかに従う符号化方法または復号方法を実行させる命令を含むコンピュータプログラムを提供する。本実施形態のうちの１つ以上はまた、上述した方法のいずれかに従ってビデオデータを符号化または復号する命令を記憶したコンピュータ可読記憶媒体を提供する。１つ以上の実施形態はまた、上述した方法に従って生成されたビットストリームを記憶したコンピュータ可読記憶媒体を提供する。１つ以上の実施形態はまた、上述した方法に従って生成されたビットストリームを送信または受信する方法および装置を提供する。

様々な実装形態は、復号を伴う。本出願で使用される「復号」は、例えば、表示に適した最終出力を生成するために、受信した符号化されたシーケンスで実行される処理のすべてまたは一部を包含することができる。様々な実施形態では、そのような処理は、復号器によって通常実行される処理のうちの１つ以上、例えば、エントロピー復号、逆量子化、逆変換、および差分復号を含む。「復号処理」という句が、具体的に動作のサブセットを指すことを意図しているか、または概してより広い復号処理を指すことを意図しているかは、特定の説明の文脈に基づいて明確になり、当業者によって十分に理解されると考えられる。

様々な実装形態は、符号化を伴う。「復号」に関する上記の考察と同様に、本出願で使用される「符号化」は、例えば、符号化されたビットストリームを生成するために入力ビデオシーケンスで実行される処理のすべてまたは一部を包含することができる。

本明細書で使用される構文要素、例えば、ＧＢｉインデックスを特徴付けるために使用される構文は、説明的な用語であることに留意されたい。したがって、それらは、他の構文要素名の使用を排除するものではない。

本明細書で説明された実装形態および態様は、例えば、方法もしくは処理、装置、ソフトウェアプログラム、データストリーム、または信号に実装することができる。単一の実装形態の文脈でのみ考察される（例えば、方法としてのみ考察される）場合であっても、考察される特徴の実装はまた、他の形態（例えば、装置またはプログラム）で実装されてもよい。装置は、例えば、適切なハードウェア、ソフトウェア、およびファームウェアで実装することができる。この方法は、例えば、装置、例えば、コンピュータ、マイクロプロセッサ、集積回路、またはプログラマブルロジック装置を含む、一般に処理装置を指す、例えば、プロセッサに実装することができる。プロセッサはまた、通信装置、例えば、コンピュータ、携帯電話、ポータブル／パーソナルデジタルアシスタンス（「ＰＤＡ」）、およびエンドユーザ間の情報の伝達を容易にする他の装置も含む。

「１つの実施形態」もしくは「一実施形態」、または「１つの実装形態」もしくは「一実装形態」、ならびにそれらの他の変形への言及は、実施形態に関連して説明された特定の特徴、構造、特性などが、少なくとも１つの実施形態に含まれることを意味する。したがって、本出願全体にわたって様々な箇所においてみられる、「１つの実施形態では」もしくは「一実施形態では」または「１つの実装形態では」もしくは「一実装形態では」という句、ならびに任意の他の変形の出現は、必ずしもすべてが同じ実施形態を指しているわけではない。

さらに、本出願は、情報の様々な部分を「判断する」ことに言及する場合がある。情報を決定することは、例えば、情報を推定すること、情報を計算すること、情報を予測すること、またはメモリから情報を検索することのうちの１つ以上を含むことができる。

さらに、本出願は、情報の様々な部分に「アクセスする」ことに言及する場合がある。情報にアクセスすることは、例えば、情報を受信すること、情報を検索すること（例えば、メモリから）、情報を記憶すること、情報を移動させること、情報をコピーすること、情報を計算すること、情報を決定すること、情報を予測すること、または情報を推定することのうちの１つ以上を含むことができる。

さらに、本出願は、情報の様々な部分を「受信する」ことに言及する場合がある。受信することは、「アクセスすること」と同様に、広義の用語であることが意図されている。情報を受信することは、例えば、情報にアクセスすること、または（例えば、メモリから）情報を検索することのうちの１つ以上を含むことができる。さらに、「受信すること」は、典型的には、何らかの方法で、動作中に、例えば、情報を記憶すること、情報を処理すること、情報を送信すること、情報を移動させること、情報をコピーすること、情報を消去すること、情報を計算すること、情報を決定すること、情報を予測すること、または情報を推定することを伴う。

例えば、「Ａ／Ｂ」、「Ａおよび／またはＢ」、ならびに「ＡおよびＢのうちの少なくとも１つ」の場合、次の「／」、「および／または」、ならびに「のうちの少なくとも１つ」のいずれかの使用は、最初に挙げた選択肢（Ａ）のみの選択、または２番目に挙げた選択肢（Ｂ）のみの選択、または両方の選択肢（ＡおよびＢ）の選択を網羅することを意図していることが分かるはずである。さらなる例として、「Ａ、Ｂ、および／またはＣ」ならびに「Ａ、Ｂ、およびＣのうちの少なくとも１つ」の場合、そのような言い回しは、最初に挙げた選択肢（Ａ）のみの選択、または２番目に挙げた選択肢（Ｂ）のみの選択、または３番目に挙げた選択肢（Ｃ）のみの選択、または最初および２番目に挙げた選択肢（ＡおよびＢ）のみの選択、または最初および３番目に挙げた選択肢（ＡおよびＣ）のみの選択、または２番目および３番目に挙げた選択肢（ＢおよびＣ）のみの選択、または３つすべての選択肢（ＡおよびＢおよびＣ）の選択、を網羅することを意図している。これは、当業者にとって明らかなように、挙げられる項目の数だけ拡張され得る。

また、本明細書で使用される場合、「信号通知する」という単語は、とりわけ、対応する復号器に何かを指示することを指す。例えば、特定の実施形態では、符号化器は、区分的線形モデル内の区分の数を復号器に信号通知する。このようにして、実施形態では、同じパラメータが、符号化器側および復号器側の両方で使用される。したがって、例えば、符号化器は、特定のパラメータを復号器に送信することができ（明示的な信号通知）、その結果、復号器は、同じ特定のパラメータを使用することができる。逆に、復号器が既に特定のパラメータならびに他のパラメータを有する場合、信号通知は、送信（暗黙的な信号通知）を行わずに使用されて、復号器が簡単に特定のパラメータを認識して選択するのを可能にすることができる。任意の実際の機能の送信を回避することによって、ビットの節約が、様々な実施形態で実現される。信号通知は、様々な方法で達成できることが分かるはずである。例えば、１つ以上の構文要素、フラグなどが、様々な実施形態で、対応する復号器に情報を信号通知するために使用される。上記は、「信号通知する」という単語の動詞形に関するものであるが、「信号通知」という単語はまた、本明細書では、名詞として使用することもできる。

当業者にとって明らかであるように、実装形態は、例えば、記憶または送信することができる情報を搬送するようにフォーマットされる多種多様な信号を生成することができる。情報は、例えば、方法を実行する命令、または説明される実装形態のうちの１つにより生成されるデータを含むことができる。例えば、信号は、説明された実施形態のビットストリームを搬送するようにフォーマットされてもよい。そのような信号は、例えば、電磁波（例えば、スペクトルの無線周波数部分を使用して）として、またはベースバンド信号としてフォーマットされてもよい。フォーマットすることは、例えば、データストリームを符号化することと、搬送波を符号化データストリームで変調することと、を含むことができる。信号が搬送する情報は、例えば、アナログ情報またはデジタル情報とすることができる。信号は、既知のように、多種多様な異なる有線リンクまたは無線リンクを介して送信され得る。信号は、プロセッサ可読媒体に保存されてもよい。

Claims (28)

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. 前記複数の２値シンボルの前記第３の２値シンボルは、前記重み付け和を形成するときに重み係数３が前記２つの予測因子のうちの１つに適用されるか否かを示す、請求項２２～２７のいずれか一項に記載の装置。
    

Images