JP2021530937A - １つまたは複数のルックアップテーブルを使用して、以前符号化された動き情報を順に記憶させてそれらを後続のブロックの符号化に使用する概念関連出願の相互参照 - Google Patents

Abstract

動き情報を記憶し、後続のブロックを処理するために、１つ以上のテーブルを使用して映像を処理するためのデバイス、システム、および方法が説明される。１つの態様において、映像処理方法が提供され、この方法は、１つのテーブルのセットを維持することを含み、各テーブルは、映像データにおける第１の映像ブロックの前に復号化された、以前復号化された映像ブロックから導出された動き候補を含み、第１の映像ブロックのビットストリーム表現と第１の映像ブロックとの間で変換を行うことと、変換に基づいて、この１つのテーブルのセットにおける１つまたは複数のテーブルを更新することと、を含む。【選択図】図３０

Description

パリ条約に基づく適用可能な特許法および／または規則に基づいて、本願は、２０１８年６月２９日出願の国際特許出願ＰＣＴ／ＣＮ２０１８／０９３６６３号、２０１８年９月１２日出願の国際特許出願ＰＣＴ／ＣＮ２０１８／１０５１９３号、２０１８年７月２日出願の国際特許出願ＰＣＴ／ＣＮ２０１８／０９３９８７号の優先権および利益を適時に主張することを目的とする。米国の法律の下、あらゆる目的のために、国際特許出願ＰＣＴ／ＣＮ２０１８／０９３６６３号、国際特許出願第ＰＣＴ／ＣＮ２０１８／１０５１９３号、および国際特許出願第ＰＣＴ／ＣＮ２０１８／０９３９８７号の開示の全文は、本願の開示の一部として参照により援用される。

本特許明細書は、映像符号化およびデコーディング技術、デバイスおよびシステムに関する。

映像圧縮の進歩にもかかわらず、デジタル映像は、依然として、インターネットおよび他のデジタル通信ネットワークにおいて最大の帯域幅の使用量を占めている。映像の受信および表示が可能な接続されたユーザ機器の数が増加するにつれ、デジタル映像の使用に対する帯域幅需要は増大し続けることが期待される。

本明細書は、１つ以上のルックアップテーブルを使用してデジタル映像を符号化および復号化するための方法、システム、およびデバイスを開示する。

１つの態様において、映像処理方法が提供され、この方法は、１つのテーブルのセットを維持することを含み、各テーブルは、映像データにおける第１の映像ブロックの前に復号化された、以前復号化された映像ブロックから導出された動き候補を含み、第１の映像ブロックのビットストリーム表現と第１の映像ブロックとの間で変換を行うことと、変換に基づいて、この１つのテーブルのセットにおける１つまたは複数のテーブルを更新することと、を含む。

別の態様において、映像処理方法が提供され、この方法は、映像データの第１のブロックのビットストリーム表現を受信することと、テーブルのセットに基づいてこのビットストリーム表現を処理することと、映像データの第１のブロックを生成することと、を含み、このテーブルのセットは、符号化候補を含む。

さらに別の代表的な態様において、上記方法は、処理装置が実行可能なコードの形式で実施され、コンピュータ可読プログラム媒体に記憶される。

さらに別の代表的な態様において、上述した方法を行うように構成された、または動作可能なデバイスが開示される。この装置は、この方法を実装するようにプログラムされた処理装置を含んでもよい。

さらに別の代表的な態様において、ビデオデコーダ装置は、本明細書で説明されるような方法を実装してもよい。

開示される技術の上記および他の態様および特徴は、図面、説明および特許請求の範囲でより詳細に説明される。

典型的な高効率映像符号化（ＨＥＶＣ）ビデオエンコーダおよびデコーダの例示的なブロック図を示す。 Ｈ．２６４／ＡＶＣにおけるマクロブロック（ＭＢ）パーティションの例を示す。 コーディングブロック（ＣＢ）を予測ブロック（ＰＢ）に分割する例を示す。 コーディングツリーブロック（ＣＴＢ）をＣＢおよび変換ブロック（ＴＢ）にそれぞれ細分化の例および対応する４分木をそれぞれ示す。 コーディングツリーブロック（ＣＴＢ）をＣＢおよび変換ブロック（ＴＢ）にそれぞれ細分化の例および対応する４分木をそれぞれ示す。 最大符号化ユニット（ＬＣＵ）のための細分化および対応する４分木プラス２分木（ＱＴＢＴ）の例を示す。 最大符号化ユニット（ＬＣＵ）のための細分化および対応する４分木プラス２分木（ＱＴＢＴ）の例を示す。 符号化ブロックをパーティショニングする例を示す。 符号化ブロックをパーティショニングする例を示す。 符号化ブロックをパーティショニングする例を示す。 符号化ブロックをパーティショニングする例を示す。 符号化ブロックをパーティショニングする例を示す。 ＱＴＢＴに基づくＣＢの細分化の例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。 ツリー型信号通知の例を示す。 マージ候補リストの構築例を示す。 空間的候補の位置の例を示す。 空間的マージ候補の冗長性チェックの対象となる候補ペアの例を示す。 現在のブロックのサイズおよび形状に基づく第２の予測ユニット（ＰＵ）の位置の例を示す。 現在のブロックのサイズおよび形状に基づく第２の予測ユニット（ＰＵ）の位置の例を示す。 時間的マージ候補のための動きベクトルのスケーリングの例を示す。 時間的マージ候補の候補位置の例を示す。 結合双予測マージ候補を生成する例を示す。 動きベクトル予測候補の導出処理の例を示す。 動きベクトル予測候補の導出処理の例を示す。 空間的動きベクトル候補のための動きベクトルのスケーリングの例を示す。 符号化ユニット（ＣＵ）のために代替時間的動きベクトル予測（ＡＴＭＶＰ）アルゴリズムを使用する動き予測の例を示す。 ソースブロックおよびソースピクチャの特定の例を示す。 空間的−時間的動きベクトル予測（ＳＴＭＶＰ）アルゴリズムで使用されるサブブロックおよび近傍のブロックを有するコーディングユニット（ＣＵ）の例を示す。 フレームレートアップ変換（ＦＲＵＣ）アルゴリズムに基づく特殊なマージモードである、パターンマッチング動きベクトル導出（ＰＭＭＶＤ）モードにおけるバイラテラルマッチングの例を示す。 ＦＲＵＣアルゴリズムにおけるテンプレートマッチングの例を示す。 ＦＲＵＣアルゴリズムにおける片側動き推定の例を示す。 バイラテラルテンプレートマッチングに基づくデコーダ側動きベクトル改良（ＤＭＶＲ）アルゴリズムの一例を示す。 照明補償（ＩＣ）パラメータを導出するために使用される近傍のサンプルの例を示す。 空間的マージ候補を導出するための近傍のブロックの例を示す。 提案される６７個のイントラ予測モードの例を示す。 最大確率モード導出のための近傍のブロックの例を示す。 ＱＴＢＴ構造を有するＩスライスにおける対応する輝度およびクロマサブブロックを示す。 ＱＴＢＴ構造を有するＩスライスにおける対応する輝度およびクロマサブブロックを示す。 １つのブロックの後に更新されるＬＵＴに基づくＭＶＰ／イントラモード予測／ＩＣパラメータの例のための符号化フローを示す。 １つの領域の後に更新されるＬＵＴに基づくＭＶＰ／イントラモード予測／ＩＣパラメータの例のための符号化フローを示す。 提案されるＨＭＶＰ方法による復号化フローチャートの一例を示す。 提案されるＨＭＶＰ方法を用いたテーブルの更新例を示す。 冗長性除去に基づくＬＵＴ更新方法（１つの冗長性動き候補を除去する）の例を示す。 冗長性除去に基づくＬＵＴ更新方法（１つの冗長性動き候補を除去する）の例を示す。 冗長性除去に基づくＬＵＴ更新方法（複数の冗長性動き候補を除去する）の例を示す。 冗長性除去に基づくＬＵＴ更新方法（複数の冗長性動き候補を除去する）の例を示す。 開示された技術による映像処理のための例示的な方法のフローチャートを示す。 開示された技術による映像処理のための例示的な方法のフローチャートを示す。 本明細書に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実装するためのハードウェアプラットフォームの一例を示すブロック図である。

より高い解像度の映像の需要が増大しているため、近代技術において、映像符号化法および技術は、遍在している。ビデオコーデックは、一般的に、デジタル映像を圧縮または展開する電子回路またはソフトウェアを含み、より高い符号化効率を提供するように絶えず改良されている。ビデオコーデックは、非圧縮映像を圧縮フォーマットに変換する、またはその逆である。映像の品質、映像を表現するために使用されるデータの数（ビットレートで決まる）、エンコーディングおよびデコーディングアルゴリズムの複雑性、データの損失およびエラーに対する敏感さ、編集のしやすさ、ランダムアクセス、およびエンドツーエンドの遅延（待ち時間）の間には複雑な関係がある。この圧縮フォーマットは、通常、標準的な映像圧縮仕様、例えば、高効率映像符号化（ＨＥＶＣ）規格（Ｈ．２６５またはＭＰＥＧ−Ｈ Ｐａｒｔ ２としても知られている）、完成させるべき汎用映像符号化規格、または他の現在のおよび／または将来の映像符号化基準に準拠する。

開示される技術の実施形態は、圧縮性能を向上させるために、既存の映像符号化規格（例えば、ＨＥＶＣ、Ｈ．２６５）および将来の規格に適用されてもよい。本明細書では、説明の可読性を向上させるために章の見出しを使用しており、説明または実施形態（および／または実装形態）をそれぞれの章のみに限定するものではない。

１． 映像符号化の例示的な実施形態
図１は、典型的なＨＥＶＣビデオエンコーダおよびデコーダの例示的なブロック図を示す（参照［１］）。ＨＥＶＣに準拠したビットストリームを生成するエンコーディングアルゴリズムは、一般的に、以下のように進む。各ピクチャはブロック状の領域に分割され、正確なブロックのパーティショニングがデコーダに伝達される。映像シーケンスの第１のピクチャ（および各クリーンなランダムアクセスポイントにおける映像シーケンスへの第１のピクチャ）は、イントラピクチャ予測（同じピクチャ内の領域から領域へのデータの何らかの予測を使用するが、他のピクチャに依存しない）のみを使用してコーディングされる。シーケンスの残りのすべてのピクチャに対して、またはランダムアクセスポイント間で、インターピクチャ時間予測コーディングモードが、一般的に、ほとんどのブロックに対して使用される。インターピクチャ予測のためのエンコーディング処理は、選択された参照ピクチャと、各ブロックのサンプルを予測するために適用される動きベクトル（ＭＶ）とを備える動きデータを選択することからなる。エンコーダおよびデコーダは、ＭＶおよびモード決定データを使用して動き補償（ＭＣ）を行うことで、同一のインターピクチャ予測信号を生成し、これらをサイド情報として送信する。

元のブロックとその予測との差である、イントラ、またはインターピクチャ予測の残差信号は、線形空間的変換によって変換される。そして、変換係数をスケーリング、量子化、エントロピーコーディングし、予測情報とともに送信する。

エンコーダは、デコーダ処理ループを複製し（図１の灰色がかった四角形を参照）、両方が後続のデータに対して同じ予測を生成するようにする。そこで、逆スケーリングにより量子化変換係数を構築し、逆変換することにより、残差信号の復号近似を複製する。次に、この残差をこの予測に加え、この加算の結果を１つまたは２つのループフィルタに供給し、ブロック単位の処理および量子化によって引き起こされたアーチファクトを平滑化することができる。最後のピクチャ表現（すなわち、デコーダの出力の複製）は、後続のピクチャの予測に使用されるように、符号化されたピクチャバッファに記憶される。一般的に、ピクチャの符号化または復号化処理の順序は、ソースからピクチャが到着する順序と異なることが多く、デコーダにとって、復号化順序（すなわち、ビットストリームの順序）と出力順序（すなわち、表示順序）とを区別することが必要となる。

ＨＥＶＣによってエンコードされるべき映像素材は、一般的に、プログレッシブスキャンイメージとして入力されることが期待される（そのフォーマットに由来するソース映像によるものであるか、代替的に、エンコーディングの前にデインターレースすることに起因する）。ＨＥＶＣ設計において、インターレース走査の使用をサポートするための明確なコーディング機能は存在せず、インターレース走査は、もはや表示に使用されず、配信にあまり用いられなくなってきている。しかしながら、ＨＥＶＣにおいてメタデータ構文が提供され、エンコーダは、インターレース映像の各フィールド（即ち、各映像フレームの偶数または奇数番目のライン）を別個のピクチャとして符号化することによって、インターレース走査された映像が送信されたこと、または、各インターレースフレームをＨＥＶＣ符号化ピクチャとして符号化することによって送信されたことを示すことができる。これは、デコーダに負担をかけることなく、そのために特別な符号化処理をサポートする必要がある、インターレース映像を符号化する効率的な方法を提供する。

１．１． Ｈ．２６４／ＡＶＣにおける分割ツリー構造の例
以前の規格におけるコーディング層のコアは、１６×１６ブロックの輝度サンプルを含む、また、通常の４：２：０カラーサンプリングの場合、２つの対応する８×８ブロックのクロマサンプル含むマクロブロックであった。

イントラコーディングされたブロックは、画素間の空間的相関を利用するために空間予測を使用する。２つのパーティションを規定する。１６×１６および４×４である。

インターコーディングされたブロックは、ピクチャ間の動きを推定することで、空間的予測の代わりに時間予測を用いる。動きは、１６×１６マクロブロックまたはそのサブマクロブロックパーティションのいずれかに対して独立して推定できる。図２に示す１６×８、８×１６、８×８、８×４、４×８、４×４である（参照［２］）。１つのサブマクロブロックパーティション当たり１つの動きベクトル（ＭＶ）のみが許可される。

１．２ ＨＥＶＣにおけるパーティションツリー構造の例
ＨＥＶＣにおいて、コーディングツリーユニット（ＣＴＵ）は、コーディングツリーと呼ばれる４分木構造を利用してコーディングユニット（ＣＵ）に分けられ、様々な局所的特徴に適応する。インターピクチャ（時間的）予測またはイントラピクチャ（空間的）予測を使用した、ピクチャ領域をコーディングするかどうかの決定は、ＣＵレベルで行われる。各ＣＵは、ＰＵ分割タイプに基づいて、１つ、２つまたは４つの予測ユニット（ＰＵ）にさらに分割されてもよい。１つのＰＵの内部では、同じ予測処理が適用され、ＰＵ単位で関連情報がデコーダに送信される。ＰＵ分割タイプに基づく予測処理を適用して残差ブロックを得た後、ＣＵのためのコーディングツリーに類似した別の４分木構造に基づいて、ＣＵを変換ユニット（ＴＵ）に分割することができる。ＨＥＶＣ構造の重要な特徴の１つは、ＣＵ、ＰＵ、ＴＵを含む複数のパーティション概念を有することである。

ＨＥＶＣを使用するハイブリッド映像符号化に関与する特定の特徴は、以下を含む。

（１）コーディングツリーユニット（ＣＴＵ）およびコーディングツリーブロック（ＣＴＢ）構造：ＨＥＶＣにおける類似した構造は、符号化ツリーユニット（ＣＴＵ）であり、この符号化ツリーユニットは、エンコーダによって選択されたサイズを有し、従来のマクロブロックよりも大きくてもよい。ＣＴＵは、輝度ＣＴＢと、対応するクロマＣＴＢおよび構文要素とからなる。輝度ＣＴＢのサイズＬ×Ｌは、Ｌ＝１６、３２、または６４個のサンプルとして選択することができ、より大きいサイズは、一般的に、より優れた圧縮を有効にする。ＨＥＶＣは、次いで、ツリー構造および４分木様の信号通知を使用して、ＣＴＢをより小さなブロックにパーティショニングすることをサポートする。

（２）コーディングユニット（ＣＵ）およびコーディングブロック（ＣＢ）：ＣＴＵの４分木の構文は、その輝度およびクロマＣＢのサイズおよび位置を指定する。４分木のルートはＣＴＵに関連付けられる。従って、輝度ＣＴＢのサイズは、輝度ＣＢに対してサポートされる最大のサイズである。ＣＴＵを輝度ＣＢおよびクロマＣＢに分割することは、共に信号通知されることである。１つの輝度ＣＢおよび通常２つのクロマＣＢは、関連する構文と共に、１つのコーディングユニット（ＣＵ）を形成する。ＣＴＢは、１つのＣＵのみを含んでもよく、または複数のＣＵを形成するように分割されてもよく、各ＣＵは、それに関連付けられた予測ユニット（ＰＵ）へのパーティショニングと、１つの変換ユニットのツリー（ＴＵ）とを有する。

（３）予測ユニットおよび予測ブロック（ＰＢ）：インターピクチャまたはイントラピクチャ予測を使用してピクチャ領域をコーディングするかどうかの決定は、ＣＵレベルで行われる。ＰＵのパーティショニング構造は、そのルートがＣＵレベルにある。基本的な予測タイプの決定に基づいて、次に、ルマ度およびクロマＣＢのサイズをさらに分割し、輝度およびクロマ予測ブロック（ＰＢ）から予測することができる。ＨＥＶＣは、６４×６４個のサンプルから４×４個のサンプルまでの可変ＰＢサイズをサポートする。図３は、Ｍ×Ｍ個のＣＵのための許可されたＰＢの例を示す。

（４）変換ユニット（Ｔｕｓ）および変換ブロック：予測残差は、ブロック変換を使用してコーディングされる。ＴＵツリー構造は、そのルートがＣＵレベルにある。この輝度ＣＢ残差は、輝度変換ブロック（ＴＢ）と同一であってもよいし、小さな輝度ＴＢにさらに分割されてもよい。クロマＴＢについても同様である。正方形ＴＢサイズ４×４、８×８、１６×１６、および３２×３２に対して、離散コサイン変換（ＤＣＴ）の整数基底関数に類似した整数基底関数が規定される。輝度イントラピクチャ予測残差の４×４変換のために、離散正弦変換（ＤＳＴ）の形式から導出される整数変換が代替的に指定される。

１．２．１． ＴＢとＴＵへのツリー構造の分割の例
残差コーディングの場合、ＣＢは、変換ブロック（ＴＢ）に再帰的に分割することができる。このパーティショニングは、残差４分木によって信号通知される。図４に示すように、１つのブロックを再帰的に象限に分割することができるように、正方形のＣＢおよびＴＢのパーティショニングのみを指定する。サイズＭ×Ｍの所与の輝度ＣＢに対して、フラグは、それがサイズＭ／２×Ｍ／２の４つのブロックに分割されるかどうかを信号通知する。さらなる分割が可能である場合、シーケンスパラメータセット（ＳＰＳ）に示される残差４分木の最大深さによって信号通知されるように、各象限には、それが４つの象限に分割されているかどうかを示すフラグが割り当てられる。残差４分木の結果得られるリーフノードブロックは、変換コーディングによってさらに処理される変換ブロックである。エンコーダは、それが使用することになる最大輝度ＴＢサイズおよび最小ルマ度ＴＢサイズを示す。ＣＢサイズが最大ＴＢサイズよりも大きい場合、分割は非明示的に行われる。分割により、示された最小値よりも小さい輝度ＴＢサイズとなる場合、分割を行わないことが、非明示的に行われる。輝度ＴＢサイズが４×４である場合を除き、クロマＴＢサイズは、各次元において輝度ＴＢサイズの半分であり、この場合、４つの４×４ルマＴＢによって覆われる領域には１つの４×４クロマＴＢが使用される。イントラピクチャ予測ＣＵの場合、最近の近傍のＴＢ（ＣＢ内またはＣＢ外）の復号サンプルを、イントラピクチャ予測のための参照データとして用いる。

従来の規格とは対照的に、ＨＥＶＣ設計により、１つのＴＢがインターピクチャ予測ＣＵのために複数のＰＢにまたがることを可能となり、４分木構造のＴＢのパーティショニングの潜在的なコーディング効率の利点が最大となる。

１．２．２． 親子ノード
ＣＴＢは、４分木構造に基づいて分割され、そのノードはコーディングユニットである。４分木構造における複数のノードは、リーフノードおよび非リーフノードを含む。リーフノードは、ツリー構造内に子ノードを持たない（すなわち、リーフノードはそれ以上分割されない）。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、映像データの最初の映像ブロック（例えば、ＣＴＢ）に対応する。複数のノードのうちのそれぞれの非ルートノードごとに、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応する映像ブロックのサブブロックである映像ブロックに対応する。複数の非リーフノードのそれぞれの非リーフノードは、ツリー構造において１つ以上の子ノードを有する。

１．３． ＪＥＭにおけるより大きいＣＴＵを有する４分木＋２分木ブロック構造の例
いくつかの実施形態において、将来の映像符号化技術（参照「３」）は、共同探索モデル（ＪＥＭ）（参照「４」として知られる参照ソフトウェアを使用して探索される。ＪＥＭは、２分木構造に加え、４分木＋２分木（ＱＴＢＴ）および３分木（ＴＴ）構造を記述している。

１．３．１． ＱＴＢＴブロック分割構造の例
ＨＥＶＣ（参照「５」）とは対照的に、ＱＴＢＴ構造は、複数のパーティションタイプの概念を削除する。すなわち、ＣＵ、ＰＵ、ＴＵのコンセプトの切り離しを取り除き、ＣＵパーティションの形状の柔軟性を向上させる。ＱＴＢＴブロック構造において、ＣＵは正方形または長方形のいずれかを有することができる。図５Ａに示すように、まず、コーディングツリーユニット（ＣＴＵ）を４分木構造で分割する。４分木のリーフノードは、２分木構造によってさらに分割される。２分木の分割には、対称水平分割と対称垂直分割の２つの分割タイプがある。２分木のリーフノードは、コーディングユニット（ＣＵ）と呼ばれ、このセグメント化は、それ以上のパーティショニングを行うことなく、予測および変換処理に使用される。これは、ＱＴＢＴコーディングされたブロック構造において、ＣＵ、ＰＵおよびＴＵが同じブロックサイズを有することを意味する。ＪＥＭにおいて、ＣＵは、異なる色成分のコーディングされたブロック（ＣＢ）からなることがある。例えば、４：２：０クロマフォーマットのＰおよびＢスライスの場合、１つのＣＵは１つの輝度ＣＢおよび２つのクロマＣＢを含み、時には、単一の成分のＣＢからなる。例えば、１つのＣＵは、１つの輝度ＣＢのみを含み、またはＩスライスの場合、２つのクロマＣＢのみを含む。

ＱＴＢＴパーティショニング方式に対して以下のパラメータを規定する。
−−ＣＴＵのサイズ：１つの４分木のルートノードのサイズ、ＨＥＶＣと同じ概念
−−ＭｉｎＱＴＳｉｚｅ：最小許容４分木のリーフノードサイズ
−−Ｍａ×ＢＴＳｉｚｅ：最大許容２分木のルートノードサイズ
−−Ｍａ×ＢＴＤｅｐｔｈ：最大許容２分木の深さ
−−ＭｉｎＢＴＳｉｚｅ：最小限に許容される２分木のリーフノードのサイズ

ＱＴＢＴのパーティショニング構造の一例において、ＣＴＵのサイズを、２つの対応する６４×６４ブロックのクロマサンプルを有する１２８×１２８の輝度サンプルとして設定し、ＭｉｎＱＴＳｉｚｅを１６×１６として設定し、Ｍａ×ＢＴＳｉｚｅを６４×６４として設定し、ＭｉｎＢＴＳｉｚｅ（幅および高さの両方について）を４×４として設定し、Ｍａ×ＢＴＤｅｐｔｈを４として設定する。４分木のパーティショニングは、まずＣＴＵに適用され、４分木のリーフノードを生成する。４分木のリーフノードのサイズは、１６×１６（即ち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（即ち、ＣＴＵサイズ）までが可能である。４分木のリーフノードが１２８×１２８である場合、サイズがＭａ×ＢＴＳｉｚｅ（すなわち、６４×６４）を超えるため、２分木によってさらに分割されない。そうでない場合、４分木のリーフノードは、２分木によってさらに分割されてもよい。従って、この４分木のリーフノードは、２分木のルートノードでもあり、その２分木の深さは０である。２分木の深さがＭａ×ＢＴＤｅｐｔｈ（すなわち、４）に達した場合、それ以上の分割は考慮されない。２分木のノードの幅がＭｉｎＢＴＳｉｚｅに等しい（すなわち、４である）場合、それ以上の水平分割は考慮されない。同様に、２分木のノードの高さがＭｉｎＢＴＳｉｚｅに等しい場合、それ以上の垂直分割は考慮されない。２分木のリーフノードは、さらにパーティショニングすることなく、予測および変換処理によってさらに処理される。ＪＥＭにおいて、最大ＣＴＵサイズは、２５６×２５６個の輝度サンプルである。

図５ＡはＱＴＢＴを用いたブロックのパーティショニングの例を示し、図５Ｂは対応するツリー表現を示す。実線は４分木の分割を表し、点線は２分木の分割を表す。２分木の各分割（即ち、非リーフ）ノードにおいて、１つのフラグが、どの分割タイプ（即ち、水平または垂直）が使用されるかを示すために信号通知される。ここで、０は、水平分割を表し、１は、垂直分割を表す。４分木の分割の場合、４分木の分割は常にブロックを水平および垂直に分割し、等分したサイズの４つのサブブロックを生成するため、分割タイプを示す必要がない。

さらに、ＱＴＢＴ方式は、輝度およびクロマが別個のＱＴＢＴ構造を有する能力をサポートする。現在、ＰおよびＢスライスの場合、１つのＣＴＵにおける輝度およびクロマＣＴＢは、同じＱＴＢＴ構造を共有する。しかしながら、Ｉスライスの場合、輝度ＣＴＢはＱＴＢＴ構造によってＣＵに分割され、クロマＣＴＢは別のＱＴＢＴ構造によってクロマＣＵに分割される。これは、１つのＩスライスにおける１つのＣＵが１つの輝度成分の１つのコーディングされたブロックまたは２つのクロマ成分の１つのコーディングされたブロックからなり、１つのＰまたはＢスライスにおける１つのＣＵが３つの色成分すべてのコーディングされたブロックからなることを意味する。

ＨＥＶＣにおいて、小さなブロックのためのインター予測は、動き補償のメモリアクセスを低減するために制限され、その結果、４×８および８×４ブロックのために双予測はサポートされず、４×４ブロックのためにインター予測はサポートされない。ＪＥＭのＱＴＢＴにおいて、これらの制限は取り除かれる。

１．４． 汎用映像符号化（ＶＶＣ）のための３分木（ＴＴ）
図６Ａは、４分木（ＱＴ）のパーティショニングの例を示し、図６Ｂおよび図６Ｃは、それぞれ、垂直および水平２分木（ＢＴ）のパーティショニングの例を示す。いくつかの実施形態において、４分木および２分木に加え、３分木（ＴＴ）のパーティショニング、例えば、水平および垂直中心側３分木（図６Ｄおよび図６Ｅに示す）がサポートされる。

いくつかの実装形態において、２つのレベルの木、即ち、領域ツリー（４分木）および予測ツリー（２分木または３分木）がサポートされる。ＣＴＵは、まず、領域ツリー（ＲＴ）によって分割される。ＲＴリーフは、予測ツリー（ＰＴ）によってさらに分割されてもよい。ＰＴリーフはまた、最大ＰＴ深さに達するまで、ＰＴでさらに分割されてもよい。ＰＴリーフが基本コーディングユニットである。便宜上、ここでもＣＵと呼ぶ。１つのＣＵをさらに分割することはできない。予測および変換は両方ともＪＥＭと同様にＣＵに適用される。パーティション構造全体を「マルチタイプツリー」と呼ぶ。

１．５． 代替映像符号化技術における分割構造の例
いくつかの実施形態において、ＱＴＢＴを一般化したマルチツリータイプ（ＭＴＴ）と呼ばれるツリー構造が支援される。ＱＴＢＴにおいて、図７に示すように、コーディングツリーユニット（ＣＴＵ）が、まず、４分木構造で分割される。４分木のリーフノードは、２分木構造によってさらに分割される。

ＭＴＴの構造は、２つのタイプのツリーノードを構成する。図８に示すように、領域ツリー（ＲＴ）および予測ツリー（ＰＴ）は、９つのタイプのパーティションをサポートする。１つの領域ツリーは、１つのＣＴＵを４×４サイズの領域ツリーのリーフノードになるように正方形のブロックに再帰的に分割することができる。領域ツリーにおける各ノードにおいて、予測ツリーは、２分木、３分木、および非対称２分木の３つのツリータイプのうちの１つから形成することができる。ＰＴ分割において、予測ツリーの枝に４分木のパーティションを有することは禁止される。ＪＥＭにおけるように、輝度ツリーおよびクロマツリーは、Ｉ個のスライスに分けられる。ＲＴおよびＰＴの信号通知方法を図９Ａに示す。

２． ＨＥＶＣ／Ｈ．２６５におけるインター予測の例
映像符号化規格は、長年にわたって大幅に改善され、現在、部分的には、高いコーディング効率を実現し、より高い解像度をサポートする。ＨＥＶＣおよびＨ．２６５などの最近の規格は、時間予測プラス変換コーディングが利用されるハイブリッド映像符号化構造に基づく。

２．１ 予測モードの例
各インター予測されたＰＵ（予測ユニット）は、１つまたは２つの参照ピクチャリストのための動きパラメータを有する。いくつかの実施形態において、動きパラメータは、動きベクトルおよび参照ピクチャインデックスを含む。他の実施例において、２つの参照ピクチャリストのうちの１つの参照ピクチャリストの使用は、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃを用いて通知されてもよい。さらに他の実施形態において、動きベクトルは、予測子に対するデルタ（ｄｅｌｔａ）として明確にコーディングされてもよい。

１つのＣＵがスキップモードでコーディングされる場合、１つのＰＵがこのＣＵに関連付けられ、有意な残差係数がなく、コーディング動きベクトルデルタも参照ピクチャインデックスもない。マージモードを指定し、これにより、現在のＰＵのための動きパラメータを、空間的および時間的候補を含む近傍のＰＵから取得する。マージモードは、スキップモードのためだけでなく、任意のインター予測されたＰＵに適用することができる。マージモードの代替としては、動きパラメータの明確な送信があり、ＰＵごとに、各参照ピクチャリストおよび参照ピクチャリストの使用に対応する参照ピクチャインデックスである、動きベクトルを明確に信号通知する。

２つの参照ピクチャリストのうちの１つを使用することを信号通知が示す場合、１つのサンプルのブロックからＰＵを生成する。これを「単一予測」と呼ぶ。ＰスライスおよびＢスライスの両方に対して単一予測が利用可能である。

両方の参照ピクチャリストを使用することを信号通知が示す場合、２つのサンプルのブロックからＰＵを生成する。これを「双予測」と呼ぶ。Ｂスライスのみに双予測が利用可能である。

２．１．１ マージモードの候補を構築する実施形態
マージモードを使用してＰＵを予測する場合、ビットストリームからマージ候補リストにおけるエントリを指すインデックスを構文解析し、これを使用して動き情報を検索する。このリストの構成は、以下のステップのシーケンスに基づいてまとめることができる。

ステップ１：初期候補導出
ステップ１．１：空間的候補導出
ステップ１．２：空間的候補の冗長性チェック
ステップ１．３：時間的候補導出
ステップ２：追加候補挿入
ステップ２．１：双予測候補の作成
ステップ２．２：動きゼロ候補の挿入

図９Ｂは、上記ステップのシーケンスに基づいてマージ候補リストを構築する例を示す。空間的マージ候補導出のために、５つの異なる位置にある候補の中から最大４つのマージ候補を選択する。時間的マージ候補導出のために、２つの候補の中から最大１つのマージ候補を選択する。デコーダ側ではＰＵごとに一定数の候補を想定しているので、候補数がスライスヘッダで信号通知されるマージ候補（ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ）の最大数に達しない場合、追加の候補を生成する。候補の数は一定であるので、短縮された単項２値化（ＴＵ）を使用して最良マージ候補のインデックスをエンコードする。ＣＵのサイズが８に等しい場合、現在のＣＵのすべてのＰＵは、２Ｎ×２Ｎ予測ユニットのマージ候補リストと同じ１つのマージ候補リストを共有する。

２．１．２ 空間的マージ候補の構築
空間的マージ候補の導出において、図１０に示す位置にある候補の中から、最大４つのマージ候補を選択する。導出の順序はＡ_１、Ｂ_１、Ｂ_０、Ａ_０、Ｂ_２である。位置Ａ_１、Ｂ_１、Ｂ_０、Ａ_０のいずれかのＰＵが利用可能でない場合（例えば、別のスライスまたはタイルに属しているため）、またはイントラコーディングされた場合にのみ、位置Ｂ_２が考慮される。位置Ａ_１の候補を加えた後、残りの候補を加えると、冗長性チェックを受け、それにより、同じ動き情報を有する候補を確実にリストから排除でき、コーディング効率を向上させることができる。

計算の複雑性を低減するために、前述の冗長性チェックにおいて、考えられる候補対のすべてを考慮することはしない。代わりに、図１１において矢印でリンクされた対のみを考慮し、冗長性チェックに使用される対応する候補が同じ動き情報を有していない場合にのみ、その候補をリストに加える。重複した動き情報の別のソースは、２Ｎ×２Ｎとは異なるパーティションに関連付けられた「第２のＰＵ」である。一例として、図１２Ａおよび図１２Ｂは、それぞれＮ×２Ｎおよび２Ｎ×Ｎの場合の第２のＰＵを示す。現在のＰＵをＮ×２Ｎに分割する場合、リスト構築に位置Ａ１の候補は考慮されない。いくつかの実施形態において、この候補を加えることにより、２つの予測ユニットが同じ動き情報を有するようになり、１つのコーディングユニットに１つのＰＵのみを有することは冗長である。同様に、現在のＰＵを２Ｎ×Ｎに分割する場合、位置Ｂ１は考慮されない。

２．１．３ 時間的マージ候補の構築
このステップにおいて、１つの候補のみがリストに追加される。具体的には、この時間的マージ候補の導出において、所与の参照ピクチャリストにおける現在のピクチャとの間に最小のＰＯＣ差を有するピクチャに属する同一位置ＰＵに基づいて、スケーリングされた動きベクトルを導出する。スライスヘッダにおいて、同一位置ＰＵの導出に用いられる参照ピクチャリストが明確に信号通知される。

図１３は、時間的マージ候補のスケーリングされた動きベクトルを導出する例（点線）を示す。これは、ＰＯＣ距離ｔｂ、ｔｄを利用して、同一位置ＰＵの動きベクトルからスケーリングしたものである。ｔｂは、現在のピクチャの参照ピクチャと現在のピクチャのＰＯＣ差として規定し、ｔｄは、同一位置ＰＵの参照ピクチャと同一位置ピクチャのＰＯＣ差として規定する。時間的マージ候補の参照ピクチャインデックスをゼロに等しく設定する。Ｂスライスの場合、２つの動きベクトル、即ち、１つは参照ピクチャリスト０のためのもの、もう１つは参照ピクチャリスト１のためのものを取得し、これらを組み合わせることによって、双予測マージ候補を形成する。

参照フレームに属する同一位置ＰＵ（Ｙ）において、図１４に示すように、候補Ｃ_０と候補Ｃ_１との間で時間的候補の位置を選択する。位置Ｃ_０のＰＵが利用可能でない場合、イントラコーディングされている場合、または現在のＣＴＵの外側にある場合、位置Ｃ_１が使用される。そうでない場合、位置Ｃ_０が時間的マージ候補の導出に使用される。

２．１．４ 追加タイプのマージ候補の構築
時空間的マージ候補の他に、２つの追加のタイプのマージ候補、すなわち、結合双予測マージ候補およびゼロマージ候補がある。時空間的マージ候補を利用して、結合双予測マージ候補を生成する。結合双予測マージ候補は、Ｂスライスのみに使用される。最初の候補の第１の参照ピクチャリスト動きパラメータと別の候補の第２の参照ピクチャリスト動きパラメータとを組み合わせることで、結合双予測候補を生成する。これら２つのタプルが異なる動き仮説を提供する場合、これらのタプルは、新しい双予測候補を形成する。

図１５は、この処理の一例を示し、ここで、オリジナルリスト（１５１０、左側）における、ｍｖＬ０、ｒｅｆＩｄｘＬ０またはｍｖＬ１、ｒｅｆＩｄｘＬ１を有する２つの候補を使用して、最終リスト（１５２０、右側）に加えられる結合双予測マージ候補を生成する。

動きゼロ候補を挿入し、マージ候補リストにおける残りのエントリを埋めることにより、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ容量にヒットする。これらの候補は、空間的変位がゼロであり、新しいゼロ動き候補をリストに加える度にゼロから始まり増加する参照ピクチャインデックスを有する。これらの候補が使用する参照フレームの数は、それぞれ、一方向予測の場合は１つ、双方向予測の場合は２つである。いくつかの実施形態において、これらの候補に対して冗長性チェックは行われない。

２．１．５ 並列処理のための動き推定領域の例
エンコーディング処理を高速化するために、動き推定を並列に行うことができ、それによって、所与の領域内のすべての予測ユニットの動きベクトルを同時に導出する。１つの予測ユニットは、その関連する動き推定が完了するまで、隣接するＰＵから動きパラメータを導出することができないので、空間的近傍からのマージ候補の導出は、並列処理に干渉する可能性がある。コーディング効率と処理待ち時間との間のトレードオフを緩和するために、動き推定領域（ＭＥＲ）を規定することができる。「ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２」構文要素を使用して、ピクチャパラメータ集合（ＰＰＳ）においてＭＥＲのサイズを信号通知してもよい。１つのＭＥＲを規定するとき、同じ領域にあるマージ候補は使用不可としてマークされ、それゆえにリスト構築においては考慮されない。

ピクチャパラメータ集合（ＰＰＳ）のローバイトシーケンスペイロード（ＲＢＳＰ）構文を表１に示す。表１において、ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２＋２は、既存の映像符号化規格に規定されるように、マージモードのための輝度動きベクトルの導出処理及び空間的マージ候補の導出処理に用いられる変数Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌの値を指定する。ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２の値は、０〜ＣｔｂＬｏｇ２ＳｉｚｅＹ＿２を含む範囲内とする。

変数Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌは、以下のように導出される。
Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌ＝ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２＋２

なお、Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌの値は、マージ候補リストを並列に導出する組み込み能力を示す。例えば、Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌが６に等しい場合、６４×６４ブロックに含まれたすべての予測ユニット（ＰＵ）およびコーディングユニット（ＣＵ）のためのマージ候補リストを並列に導出することができる。

２．２ ＡＭＶＰモードにおける動きベクトル予測の実施形態
動きベクトル予測は、動きベクトルと近傍のＰＵとの間の空間−時間的相関を利用し、これを動きパラメータの明確な伝送に用いる。まず、左側、上側の時間的に近傍のＰＵ位置の可用性をチェックし、冗長な候補を取り除き、ゼロベクトルを加えることで、候補リストの長さを一定にすることで、動きベクトル候補リストを構築する。次いで、エンコーダは、候補リストから最良の予測子を選択し、選択された候補を示す対応するインデックスを送信することができる。マージインデックスの信号通知と同様に、最良の動きベクトル候補のインデックスは、短縮された単項を使用してエンコードされる。

２．２．１ 動きベクトル予測候補の構築例
図１６Ａおよび１６Ｂは、動きベクトル予測候補の導出処理をまとめたものであり、ｒｅｆｉｄｘを入力として、各参照ピクチャリストに対して実装されてもよい。

動きベクトル予測において、空間的動きベクトル候補と時間的動きベクトル候補という２つのタイプの動きベクトル候補が考えられる。空間的動きベクトル候補を導出するために、先に図１０に示したように、５つの異なる位置にある各ＰＵの動きベクトルに基づいて、最終的には２つの動きベクトル候補を導出する。

時間的動きベクトル候補を導出するために、２つの異なる同じ場所に配置された位置に基づいて導出された２つの候補から１つの動きベクトル候補を選択する。第１の時空間的候補リストを作成した後、リストにおける重複した動きベクトル候補を除去する。候補の数が２よりも多い場合、関連づけられた参照ピクチャリストにおける参照ピクチャインデックスが１よりも大きい動きベクトル候補をリストから削除する。空間的―時間的動きベクトル候補の数が２未満である場合は、追加のゼロ動きベクトル候補をリストに加える。

２．２．２ 空間的動きベクトル候補の構築
空間的動きベクトル候補の導出において、先に図１０に示したような位置にあるＰＵから導出された５つの潜在的な候補のうち、動きマージと同じ位置にあるものを最大２つの候補を考慮する。現在のＰＵの左側のための導出の順序は、Ａ_０、Ａ_１、スケーリングされたＡ_０、スケーリングされたＡ_１として規定される。現在のＰＵの上側のための導出の順序は、Ｂ_０、Ｂ_１、Ｂ_２、スケーリングされたＢ_０、スケーリングされたＢ_１、スケーリングされたＢ_２として規定される。そのため、辺ごとに、動きベクトル候補として使用できる場合は４つ、すなわち空間的スケーリングを使用する必要がない２つの場合と、空間的スケーリングを使用する２つの場合とがある。４つの異なる場合をまとめると、以下のようになる。

−−空間的スケーリングなし
（１）同じ参照ピクチャリスト、および同じ参照ピクチャインデックス（同じＰＯＣ）
（２）異なる参照ピクチャリストであるが、同じ参照ピクチャ（同じＰＯＣ）
−−空間的スケーリング
（３）同じ参照ピクチャリストであるが、異なる参照ピクチャ（異なるＰＯＣ）
（４）異なる参照ピクチャリスト、および異なる参照ピクチャ（異なるＰＯＣ）

まず、非空間的スケーリングの場合をチェックし、次に、空間的スケーリングを可能にする場合をチェックする。参照ピクチャリストにかかわらず、ＰＯＣが近傍のＰＵの参照ピクチャと現在のＰＵの参照ピクチャとで異なる場合、空間的スケーリングを考慮する。左側候補のすべてのＰＵが利用可能でないか、またはイントラコーディングされている場合、上側の動きベクトルのスケーリングは、左側および上側ＭＶ候補の並列導出に役立つ。そうでない場合、上側の動きベクトルに対して空間的スケーリングは許可されない。

図１７の例に示すように、空間的スケーリングの場合、時間的スケーリングと同様にして、近傍のＰＵの動きベクトルをスケーリングする。１つの違いは、現在のＰＵの参照ピクチャリストおよびインデックスを入力として与え、実際のスケーリング処理は時間的スケーリングと同じであることである。

２．２．３ 時間的動きベクトル候補の構築
参照ピクチャインデックスを導出する以外は、時間的マージ候補を導出するための処理は、すべて、空間的動きベクトル候補を導出するための処理と同じである（図１４の例に示す）。いくつかの実施形態において、参照ピクチャインデックスはデコーダに信号通知される。

２．２．４ マージ／ＡＭＶＰ情報の信号通知
ＡＭＶＰモードの場合、ビットストリームにおいて、４つの部分、例えば、予測方向、参照インデックス、ＭＶＤ、およびｍｖ予測子候補インデックスを信号通知することができ、これらの部分は、表２−４に示される構文の文脈で説明している。一方、マージモードの場合、マージインデックスのみを信号通知すればよい。

対応するセマンティクスは、以下を含む。
ｆｉｖｅ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄスライスでサポートされるマージＭＶＰ候補の最大数を５から減算することを指定します。ＭＶＰ候補をマージする最大数ＭａｘＮｕｍＭｅｒｇｅＣａｎｄは、以下のように導出される。
ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ＝５−ｆｉｖｅ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ
ＭａｘＮｕｍＭｅｒｇｅＣａｎｄの値は、１〜５の範囲内である。
ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］は、現在の予測ユニットにおけるインター予測パラメータを隣接するインター予測区間から推測するかどうかを指定する。配列インデックスｘ０，ｙ０は、ピクチャの左上輝度サンプルに対する、考慮される予測ブロックの左上輝度サンプルの位置（ｘ０，ｙ０）を指定する。

ｍｅｒｇｅ＿ＦＬａｇ［ｘ０］［ｙ０］が存在しない場合、次のように推論される。
−−ＣｕＰｒｅｄＭｏｄｅ［ｘ０］［ｙ０］がＭＯＤＥ＿ＳＫＩＰに等しい場合、ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］は１に等しいと推測される。
−−そうでない場合、ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］は０に等しいと推測される。

ｍｅｒｇｅ＿ｉｄｘ［ｘ０］［ｙ０］は、マージ候補リストのマージ候補インデックスを指定し、ここで、ｘ０，ｙ０は、ピクチャの左上の輝度サンプルに対する、想定される予測ブロックの左上の輝度サンプルの位置（ｘ０，ｙ０）を指定する。

３． 共同探索モデル（Ｊｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅｌ：ＪＥＭ）におけるインター予測方法の例
いくつかの実施形態において、将来の映像符号化技術は、共同探索モデル（ＪＥＭ）として知られる参照ソフトウェアを使用して探索される。ＪＥＭでは、サブブロックベースの予測は、アフィン予測、代替時間的動きベクトル予測（ＡＴＭＶＰ）、空間的−時間的動きベクトル予測（ＳＴＭＶＰ）、双方向オプティカルフロー（ＢＩＯ）、フレームレートアップ変換（ＦＲＵＣ）、ローカル適応型動きベクトル解像度（ＬＡＭＶＲ）、オーバーラップブロック動き補償（ＯＢＭＣ）、ローカル照明補償（ＬＩＣ）、デコーダ側動きベクトル改良（ＤＭＶＲ）などの、いくつかの符号化ツールで適用されている。

３．１ サブＣＵに基づく動きベクトル予測の例
４分木に２分木を加えたＪＥＭ（ＱＴＢＴ）において、各ＣＵは、各予測方向に対して最大１つの動きパラメータのセットを有することができる。いくつかの実施形態において、エンコーダにおいて、ラージＣＵをサブＣＵに分割し、ラージＣＵのすべてのサブＣＵの動き情報を導出することにより、２つのサブＣＵレベルの動きベクトル予測方法を考慮する。代替的な時間的動きベクトル予測（ＡＴＭＶＰ）方法により、各ＣＵが、配列された参照ピクチャにおける現在のＣＵよりも小さい複数のブロックから複数の動き情報のセットをフェッチすることが可能となる。空間的−時間的動きベクトル予測（ＳＴＭＶＰ）法において、時間的動きベクトル予測子および空間的近傍動きベクトルを使用して、サブＣＵの動きベクトルを再帰的に導出する。いくつかの実施形態において、サブＣＵ動き予測のためにより正確な動きフィールドを維持するために、参照フレームの動き圧縮は無効にされてもよい。

３．１．１ 代替の時間的動きベクトル予測（ＡＴＭＶＰ）の例
ＡＴＭＶＰ法において、時間的動きベクトル予測（ＴＭＶＰ）法は、現在のＣＵより小さいブロックから複数セットの動き情報（動きベクトルおよび参照インデックスを含む）を取り出すことで修正される。

図１８は、ＣＵ１８００のためのＡＴＭＶＰ動き予測処理の一例を示す。ＡＴＭＶＰ方法は、ＣＵ１８００内のサブＣＵ１８０１の動きベクトルを２つのステップで予測する。第１のステップは、参照ピクチャ１８５０における対応するブロック１８５１を時間的ベクトルで特定することである。参照ピクチャ１８５０は、モーションソースピクチャとも呼ばれる。第２のステップは、現在のＣＵ１８００をサブＣＵ１８０１に分割し、各サブＣＵに対応するブロックから各サブＣＵの動きベクトルならびに参照インデックスを得る。

第１のステップにおいて、現在のＣＵ１８００の空間的に近傍のブロックの動き情報によって、参照ピクチャ１８５０および対応するブロックを決定する。近傍のブロックの繰り返し走査処理を回避するために、現在のＣＵ１８００のマージ候補リストにおける第１のマージ候補を用いる。第１の利用可能な動きベクトルおよびその関連する参照インデックスを、時間的ベクトルおよびモーションソースピクチャのインデックスに設定する。このように、ＴＭＶＰに比べて、対応するブロックをより正確に特定することができ、対応するブロック（配列されたブロックと呼ばれることがある）は、常に現在のＣＵに対して右下または中心位置にある。

１つの例において、第１のマージ候補が左側の近傍のブロック（即ち、図１９のＡ１）からのものである場合、関連するＭＶおよび参照ピクチャを利用して、ソースブロックおよびソースピクチャを特定する。

第２のステップにおいて、現在のＣＵの座標に時間ベクトルを加えることで、モーションソースピクチャ１８５０における時間的ベクトルによって、サブＣＵ１８５１の対応するブロックを特定する。サブＣＵごとに、その対応するブロックの動き情報（例えば、中心サンプルを覆う最小の動きグリッド）を使用して、サブＣＵの動き情報を導出する。対応するＮ×Ｎブロックの動き情報を特定した後、ＨＥＶＣのＴＭＶＰと同様に、現在のサブＣＵの動きベクトルおよび参照インデックスに変換され、動きスケーリングや他の手順が適用される。例えば、デコーダは、低遅延条件（例えば、現在のピクチャのすべての参照ピクチャのＰＯＣが現在のピクチャのＰＯＣよりも小さい）が満たされているかどうかをチェックし、場合によっては、動きベクトルＭＶｘ（例えば、参照ピクチャリストｘに対応する動きベクトル）を使用して、各サブＣＵの動きベクトルＭＶｙ（例えば、Ｘが０または１に等しく、Ｙが１−Ｘに等しい）を予測する。

３．１．２ 空間的−時間的動きベクトル予測（ＳＴＭＶＰ）の例
ＳＴＭＶＰ法において、サブＣＵの動きベクトルは、ラスタスキャンの順に沿って再帰的に導出される。図２０は、４つのサブブロックおよび近傍のブロックを有する１つのＣＵの例を示す。４つの４×４個のサブＣＵ、Ａ（２００１）、Ｂ（２００２）、Ｃ（２００３）、Ｄ（２００４）を含む８×８個のＣＵ２０００を考える。現在のフレームにおける近傍の４×４ブロックには、ａ（２０１１）、ｂ（２０１２）、ｃ（２０１３）、ｄ（２０１４）というラベルが付けられる。

サブＣＵのＡの動きの導出は、その２つの空間的近傍を特定することで始まる。第１の近傍は、サブＣＵのＡ ２００１の上のＮ×Ｎブロックである（ブロックｃ ２０１３）。このブロックｃ（２０１３）が利用可能でないか、またはイントラコーディングされている場合、サブＣＵ Ａ（２００１）より上の他のＮ×Ｎ個のブロックをチェックする（ブロックｃ２０１３から始まり、左から右へ）。第２の近傍は、サブＣＵのＡ２００１の左側のブロックである（ブロックｂ２０１２）。ブロックｂ（２０１２）が利用可能でないか、またはイントラコーディングされている場合、サブＣＵのＡ２００１の左側の他のブロックをチェックする（ブロックｂ２０１２を中心に、上から下へ）。各リストの近傍のブロックから得られた動き情報を、所与のリストの第１の参照フレームにスケーリングする。次に、ＨＥＶＣに規定されているＴＭＶＰ導出と同様の手順に従って、サブブロックＡ２００１の時間的動きベクトル予測子（ＴＭＶＰ）を導出する。ブロックＤ２００４における配列されたブロックの動き情報をフェッチし、それに応じてスケーリングする。最後に、動き情報を検索し、スケーリングした後、参照リストごとにすべての利用可能な動きベクトルを別々に平均する。この平均化された動きベクトルを現在のサブＣＵの動きベクトルとする。

３．１．３ サブＣＵの動き予測モード信号通知の例
いくつかの実施形態において、サブＣＵモードは追加のマージ候補として有効とされ、モードを信号通知するために追加の構文要素は必要とされない。ＡＴＭＶＰモードおよびＳＴＭＶＰモードを表すように、各ＣＵのマージ候補リストに２つの追加のマージ候補を加える。他の実施形態において、シーケンスパラメータセットがＡＴＭＶＰおよびＳＴＭＶＰが有効であることを示す場合、７個までのマージ候補を使用してもよい。追加のマージ候補のエンコーディングロジックは、ＨＭにおけるマージ候補の場合と同じであり、つまり、ＰまたはＢスライスにおける各ＣＵについて、２つの追加のマージ候補に対して２回以上のＲＤチェックが必要となる可能性がある。いくつかの実施形態において、例えばＪＥＭのように、マージインデックスのすべての２値（ｂｉｎ）はコンテキストベースの適応型バイナリ算術コーディング（ＣＡＢＡＣ）によりコンテキストコーディングされる。他の実施形態、例えばＨＥＶＣにおいては、第１の２値のみがコンテキストコーディングされ、残りの２値はコンテキストバイパスコーディングされる。

３．２ 適応型動きベクトル差解像度の例
本発明の実施例中において、ｕｓｅ＿ｉｎｔｅｇｅｒ＿ｍｖ＿ｆｌａｇがスライスヘッダにおいて０であるとき、４分の１輝度サンプルの単位で動きベクトルの差（ＭＶＤ）（動きベクトルとＰＵの予測動きベクトルとの差）を信号通知される。ＪＥＭにおいて、ローカル適応型動きベクトル解像度（ＬＡＭＶＲ）が導入される。ＪＥＭにおいて、ＭＶＤは、１／４輝度サンプル、整数輝度サンプルまたは４つの輝度サンプルの単位でコーディングできる。ＭＶＤ分解能はコーディングユニット（ＣＵ）レベルで制御され、ＭＶＤ解像度フラグは、少なくとも１つのノンゼロＭＶＤモジュールを有する各ＣＵに対して条件付きで信号通知される。

少なくとも１つのノンゼロＭＶＤモジュールを有するＣＵの場合、１／４輝度サンプルＭＶ精度がＣＵにおいて使用されるかどうかを示すために、第１のフラグが信号通知される。第１のフラグ（１に等しい）が、１／４輝度サンプルＭＶ精度が使用されていないことを示す場合、整数輝度サンプルＭＶ精度が使用されるかまたは４輝度サンプルＭＶ精度が使用されるかを示すために、別のフラグが信号通知される。

ＣＵの第１のＭＶＤ解像度フラグがゼロであるか、またはＣＵに対してコーディングされていない（つまり、ＣＵにおけるすべてのＭＶＤがゼロである）場合、ＣＵに対して１／４輝度サンプルＭＶ解像度が使用される。ＣＵが整数輝度サンプルＭＶ精度または４輝度サンプルＭＶ精度を使用する場合、ＣＵのＡＭＶＰ候補リストにおけるＭＶＰを対応する精度に丸める。

エンコーダにおいて、ＣＵレベルのＲＤチェックは、どのＭＶＤ解像度をＣＵに用いるかを決定するために用いられる。すなわち、１つのＭＶＤ解像度ごとに３回、ＣＵレベルのＲＤチェックを行う。エンコーダの速度を速めるために、ＪＥＭにおいては、以下の符号化方式が適用される。
−−通常の１／４輝度サンプルＭＶＤ解像度を有するＣＵのＲＤチェック中、現在のＣＵの動き情報（整数輝度サンプル精度）が記憶される。整数輝度サンプルおよび４輝度サンプルのＭＶＤ解像度を有する同じＣＵのＲＤチェック中に、記憶された動き情報（丸められた後）は、更なる小範囲動きベクトル改良の開始点として使用されるので、時間がかかる動き推定処理が３回重複しない。
−−４輝度サンプルＭＶＤ解像度を有するＣＵのＲＤチェックを条件付きで呼び出す。ＣＵの場合、整数輝度サンプルＭＶＤ解像度のＲＤコストが１／４輝度サンプルＭＶＤ解像度のそれよりもはるかに大きい場合、ＣＵのための４輝度サンプルＭＶＤ解像度のＲＤチェックは省略される。

３．２．１ ＡＭＶＰ候補リストの構築例
ＪＥＭにおいて、この手順はＨＥＶＣ設計に類似している。しかしながら、現在のブロックがより低い精度のＭＶ（例えば、整数精度）を選択する場合、丸め操作が適用されてもよい。本実装において、空間的位置から２つの候補を選択した後、両方が利用可能である場合、これら２つの候補を丸め、プルーニングする。

３．３ パターンマッチング動きベクトル導出（ＰＭＭＶＤ）の例
ＰＭＭＶＤモードは、フレームレートアップ変換（ＦＲＵＣ）法に基づく特殊マージモードである。このモードでは、ブロックの動き情報は信号通知されず、デコーダ側で導出される。

ＦＲＵＣフラグは、そのマージフラグが真である場合、ＣＵに信号通知され得る。ＦＲＵＣフラグが偽である場合、マージインデックスを信号通知することができ、通常のマージモードが使用される。ＦＲＵＣフラグが真である場合、追加のＦＲＵＣモードフラグを信号通知して、どの方法（例えば、バイラテラルマッチングまたはテンプレートマッチング）を使用してブロックの動き情報を導出するかを示すことができる。

エンコーダ側では、ＣＵのためにＦＲＵＣマージモードを使用するかどうかの決定は、通常のマージ候補に対して行われるのと同じように、ＲＤコストの選択に基づく。例えば、ＲＤコスト選択を使用して、１つのＣＵに対して複数のマッチングモード（例えば、バイラテラルマッチングおよびテンプレートマッチング）をチェックする。最小コストに導くものが、他のＣＵモードと比較される。ＦＲＵＣマッチングモードが最も効率的なものである場合、ＣＵに対してＦＲＵＣフラグを真に設定し、関連するマッチングモードを使用する。

一般的に、ＦＲＵＣマージモードにおける動き導出処理では、まずＣＵレベルの動き探索が行われ、次にサブＣＵレベルの動き改良を行うという２つのステップを有する。ＣＵレベルでは、バイラテラルマッチングまたはテンプレートマッチングに基づいて、ＣＵ全体のための初期の動きベクトルを導出する。まず、ＭＶ候補のリストを生成し、最小マッチングコストに導く候補を、さらなるＣＵレベル改善の開始点として選択する。そして、開始点付近でのバイラテラルマッチングまたはテンプレートマッチングに基づく局所検索を行う。最小マッチングコストにおけるＭＶの結果を、ＣＵ全体のＭＶとする。続いて、導出されたＣＵ動きベクトルを開始点として、サブＣＵレベルでの動き情報をさらに改良する。

例えば、Ｗ×Ｈ ＣＵ動き情報導出のために、以下の導出処理を行う。第１のステージにおいて、Ｗ×Ｈ ＣＵ全体のためのＭＶが導出される。第２のステージにおいて、ＣＵは、Ｍ×Ｍ個のサブＣＵにさらに分割される。Ｍの値は、式（３）のように計算されるが、Ｄは、予め規定された分割深さであり、ＪＥＭにおいてデフォルトで３に設定される。そして、各サブＣＵのＭＶを導出する。

図２１は、フレームレートアップ変換（ＦＲＵＣ）法に用いられるバイラテラルマッチングの例を示す。このバイラテラルマッチングは、２つの異なる参照ピクチャ（２１１０、２１１１）における現在のＣＵ（２１００）の動き軌跡に沿った２つのブロック間の最も近いマッチングを見出すことで、現在のＣＵの動き情報を導出するために用いられる。連続した動き軌跡を仮定すると、２つの参照ブロックを指す動きベクトルＭＶ０（２１０１）、ＭＶ１（２１０２）は、現在のピクチャと２つの参照ピクチャとの間の時間的距離、例えばＴＤ０（２１０３）、ＴＤ１（２１０４）に比例する。いくつかの実施形態において、現在のピクチャ２１００が時間的に２つの参照ピクチャ（２１１０，２１１１）の間にあり、現在のピクチャと２つの参照ピクチャとの時間的な距離が同じである場合、バイラテラルマッチングはミラーに基づく双方向ＭＶとなる。

図２２に、フレームレートアップ変換（ＦＲＵＣ）法に用いられるテンプレートマッチングの例を示す。現在のピクチャにおけるテンプレート（例えば、現在のＣＵの上側および／または左側の近傍のブロック）と、参照ピクチャ２２１０におけるブロック（例えば、テンプレートと同じサイズ）との間の最も近いマッチングを見出すことで、テンプレートマッチングを使用して、現在のＣＵ ２２００の動き情報を導出することができる。前述のＦＲＵＣマージモード以外に、テンプレートマッチングは、ＡＭＶＰモードにも適用できる。ＪＥＭおよびＨＥＶＣの両方において、ＡＭＶＰは２つの候補を有する。テンプレートマッチング法を用いることで、新しい候補を導出することができる。テンプレートマッチングによって新規に導出された候補が、第１の既存のＡＭＶＰ候補と異なる場合、ＡＭＶＰ候補リストの最初に挿入し、次に、（例えば、第２の既存のＡＭＶＰ候補を取り除くことによって）リストサイズを２に設定する。ＡＭＶＰモードに適用される場合、ＣＵレベル検索のみが適用される。

ＣＵレベルのＭＶ候補セットは、以下を含むことができる。（１）現在のＣＵがＡＭＶＰモードにある場合、元のＡＭＶＰ候補、（２）すべてのマージ候補、（３）補間されたＭＶフィールド内の複数のＭＶ（後述）、および左上の近傍の動きベクトル。

バイラテラルマッチングを使用する場合、マージ候補の各有効なＭＶを入力として使用して、バイラテラルマッチングを仮定してＭＶ対を生成することができる。例えば、マージ候補の１つの有効なＭＶは、参照リストＡにおいて（ＭＶａ，ｒｅｆ_ａ）であり、そして、その対をなすバイラテラルＭＶの参照ピクチャｒｅｆ_ｂが他の参照リストＢにおいて見出され、ｒｅｆ_ａおよびｒｅｆ_ｂは、時間的に現在のピクチャの異なる側にある。参照リストＢにおいてこのようなｒｅｆ_ｂが利用可能でない場合、ｒｅｆ_ｂをｒｅｆ_ａとは異なる参照として決定し、現在のピクチャとの時間的距離はリストＢにおける最小値である。ｒｅｆ_ｂを決定した後、現在のピクチャとｒｅｆ_ａ，ｒｅｆ_ｂとの時間距離に基づいてＭＶａをスケーリングすることでＭＶｂを導出する。

いくつかの実装形態において、補間されたＭＶフィールドからの４つのＭＶをＣＵレベル候補リストに追加してもよい。具体的には、現在のＣＵの（０，０）、（Ｗ／２，０）、（０，Ｈ／２）、（Ｗ／２，Ｈ／２）の位置の補間ＭＶを加算する。ＡＭＶＰモードでＦＲＵＣを適用する場合、元のＡＭＶＰ候補をＣＵレベルＭＶ候補セットにも加える。いくつかの実装形態において、ＣＵレベルにおいて、ＡＭＶＰ ＣＵのための１５個のＭＶおよびマージＣＵに対し、１３個のＭＶを候補リストに加えることができる。

サブＣＵレベルのＭＶ候補セットは、ＣＵレベルの検索によって決定されたＭＶと、（２）上、左、左上、右上の近傍のＭＶと、（３）参照ピクチャからの配列されたＭＶのスケーリングされたバージョンと、（４）１つ以上（例えば、４つまで）のＡＴＭＶＰ候補と、（５）１つ以上（例えば、４つまで）のＳＴＭＶＰ候補とを含む。参照ピクチャからのスケーリングされたＭＶは、以下のように導出される。両方のリストにおける参照ピクチャをトラバースする。参照ピクチャにおけるサブＣＵの配列位置にあるＭＶは、開始ＣＵレベルＭＶの参照に対してスケーリングされる。ＡＴＭＶＰおよびＳＴＭＶＰの候補は、最初の４つの候補であってもよい。サブＣＵレベルにおいて、１つ以上（例えば、最大１７個）のＭＶが候補リストに追加される。

補間ＭＶフィールドの生成 あるフレームをコーディングする前に、片側ＭＥに基づいてピクチャ全体に対して補間動きフィールドを生成する。そして、この動きフィールドを後にＣＵレベルまたはサブＣＵレベルのＭＶ候補として使用してもよい。

いくつかの実施形態において、両方の参照リストにおける各参照ピクチャの動きフィールドは、４×４ブロックレベルでトラバースされる。図２３は、ＦＲＵＣ方法における片側動き推定（ＭＥ）２３００の例を示す。各４×４ブロックにおいて、現在のピクチャの４×４ブロックを通過するブロックに関連する動きで、補間動きがまだ割り当てられていない場合、時間距離ＴＤ０およびＴＤ１に基づいて（ＨＥＶＣにおけるＴＭＶＰのＭＶスケーリングと同様に）、参照ブロックの動きを現在のピクチャにスケーリングし、スケーリングされた動きを現在のフレームのブロックに割り当てる。４×４ブロックにスケーリングされたＭＶが割り当てられていない場合、ブロックの動きは、補間された動きフィールドにおいて利用不可能であるとマークされる。

補間およびマッチングコスト １つの動きベクトルが１つの小数のサンプル位置を指す場合、動き補償補間が必要である。複雑性を低減するために、通常の８タップＨＥＶＣ補間の代わりに、バイラテラルマッチングおよびテンプレートマッチングの両方に双線形補間を使用できる。

マッチングコストの計算は、異なるステップでは少し異なる。ＣＵレベルの候補セットから候補を選択する場合、マッチングコストは、バイラテラルマッチングまたはテンプレートマッチングの絶対和差（ＳＡＤ）であってもよい。開始ＭＶを決定した後、サブＣＵレベル検索におけるバイラテラルマッチングのマッチングコストＣを以下のように算出する。

ここで、ｗは重み係数である。いくつかの実施形態において、ｗは経験的に４に設定されてもよい。ＭＶおよびＭＶは、それぞれ、現在のＭＶおよび開始ＭＶを示す。ＳＡＤは、依然として、サブＣＵレベル検索におけるテンプレートマッチングのマッチングコストとして使用されてもよい。

ＦＲＵＣモードにおいて、ＭＶは、輝度サンプルのみを使用することによって導出される。導出された動きは、ＭＣインター予測のために、輝度およびクロマの両方に使用される。ＭＶを決定した後、輝度用の８タップ補間フィルタおよびクロマ用の４タップ補間フィルタを使用して、最終的なＭＣを行う。

ＭＶ改良は、バイラテラルマッチングコストまたはテンプレートマッチングコストの基準を有するパターンに基づくＭＶ検索である。ＪＥＭでは、２つの検索パターン、即ち、無制限中心バイアス菱形検索（ＵＣＢＤＳ）およびＣＵレベルおよびサブＣＵレベルでのＭＶ改良のための適応クロス検索をそれぞれサポートする。ＣＵおよびサブＣＵレベルのＭＶ改善の両方のために、ＭＶは、１／４輝度サンプルＭＶの正確度で直接検索され、これに続いて１／８輝度サンプルＭＶの改良が行われる。ＣＵおよびサブＣＵステップのためのＭＶ改良の検索範囲は、８つの輝度サンプルに等しく設定される。

バイラテラルマッチングマージモードにおいては、双予測が適用される。なぜなら、２つの異なる参照ピクチャにおける現在のＣＵの動き軌跡に沿った２つのブロック間の最も近いマッチングに基づいて、ＣＵの動き情報を導出するからである。テンプレートマッチングマージモードにおいて、エンコーダは、ｌｉｓｔ０からの単一予測、ｌｉｓｔ１からの単一予測、またはＣＵのための双予測のうちから選択することができる。選択は、テンプレートマッチングコストに基づいて、以下のように行うことができる。

ｃｏｓｔＢｉ＜＝ｆａｃｔｏｒ＊ｍｉｎ（ｃｏｓｔ０，ｃｏｓｔ１）の場合
双予測を用いる。
それ以外の場合でｃｏｓｔ０＜＝ｃｏｓｔ１の場合
ｌｉｓｔ０からの単一予測を用いる。
それ以外の場合、
ｌｉｓｔ１からの単一予測を用いる。

ここで、ｃｏｓｔ０はｌｉｓｔ０テンプレートマッチングのＳＡＤであり、ｃｏｓｔ１はｌｉｓｔ１テンプレートマッチングのＳＡＤであり、ｃｏｓｔＢｉは双予測テンプレートマッチングのＳＡＤである。例えば、ｆａｃｔｏｒの値が１．２５である場合、選択処理が双予測に偏っていることを意味する。このインター予測方向選択は、ＣＵレベルのテンプレートマッチング処理に適用することができる。

３．４ デコーダ側動きベクトル改良（ＤＭＶＲ）の例
双予測操作において、１つのブロック領域を予測するために、ｌｉｓｔ０の動きベクトル（ＭＶ）およびｌｉｓｔ１のＭＶをそれぞれ使用して構成される２つの予測ブロックを組み合わせ、１つの予測信号を形成する。デコーダ側動きベクトル改良（ＤＭＶＲ）方法において、バイラテラルテンプレートマッチング処理によって、双予測の２つの動きベクトルをさらに改良する。追加の動き情報を送信することなく改良されたＭＶを得るために、デコーダにおいてバイラテラルテンプレートマッチングを適用し、バイラテラルテンプレートと参照ピクチャにおける再構成サンプルとの間で歪みに基づく検索を行う。

ＤＭＶＲにおいて、図２４に示すように、ｌｉｓｔ０の最初のＭＶ０とｌｉｓｔ１のＭＶ１とから、それぞれ２つの予測ブロックの重み付け結合（すなわち、平均）としてバイラテラルテンプレートを生成する。テンプレートマッチング操作は、生成されたテンプレートと参照ピクチャにおけるサンプル領域（最初の予測ブロックの付近）との間のコスト尺度を計算することからなる。２つの参照ピクチャの各々について、テンプレートコストが最小となるＭＶを、そのリストの更新されたＭＶと見なし、元のＭＶに置き換える。ＪＥＭにおいて、各リストに対して９つのＭＶ候補を検索する。９つのＭＶ候補は、元のＭＶと、水平または垂直方向のいずれかまたは両方向に元のＭＶに対してオフセットしている１つの輝度サンプルを有する８つの周囲のＭＶを含む。最後に、２つの新しいＭＶ、即ち、図２４に示すようなＭＶ０’およびＭＶ１’を使用して、最終的な双予測結果を生成する。絶対差の合計（ＳＡＤ）をコスト尺度として使用する。

ＤＭＶＲは、追加の構文要素を送信することなく、過去の参照ピクチャからの１つのＭＶと、将来の参照ピクチャからの１つのＭＶとの間の双予測のマージモードに適用される。ＪＥＭにおいて、ＣＵに対してＬＩＣ、アフィン動き、ＦＲＵＣまたはサブＣＵマージ候補が有効である場合、ＤＭＶＲは適用されない。

３．５ 局所照明補償
ローカル照明補償（ＩＣ）は、倍率ａおよびオフセットｂを使用して、照明変化の線形モデルに基づく。そして、各インターモードコーディングユニット（ＣＵ）に対して適応的に有効または無効とされる。

ＩＣがＣＵに適用される場合、最小二乗誤差法が使用され、現在のＣＵの近傍のサンプルおよびそれらに対応する基準サンプルを使用することによって、パラメータａおよびｂを導出する。具体的には、図２５に示すように、ＣＵのサブサンプリング（２：１サブサンプリング）された近傍のサンプルと、参照ピクチャにおける対応するサンプル（現在のＣＵまたはサブＣＵの動き情報によって特定される）とを用いる。ＩＣパラメータは、各予測方向に対して別々に導出され、適用される。

ＣＵがマージモードでコーディングされる場合、ＩＣフラグは、マージモードにおける動き情報のコピーと同様に、近傍のブロックからコピーされ、そうでない場合、ＩＣフラグがＣＵに信号通知され、ＬＩＣが適用されるかどうかを示す。

ＩＣが１つのｐｃｉｔｕｒｅに対して有効である場合、あるＣＵに対してＬＩＣが適用されるかどうかを決定するために追加のＣＵレベルＲＤチェックが必要である。ＩＣがＣＵのために有効である場合、整数画素動き探索および小数画素動き探索それぞれのために、ＳＡＤおよびＳＡＴＤの代わりに、絶対拡散の平均除去和（ＭＲ−ＳＡＤ）および絶対アダマール変換差の平均除去和（ＭＲ−ＳＡＴＤ）を使用する。

エンコーディングの複雑性を低減するために、ＪＥＭにおいては、以下のエンコーディング方式が適用される。現在のピクチャとその参照ピクチャとの間に明瞭な照度変化がない場合、ＩＣはピクチャ全体に対して向こうとされる。この状況を特定するために、エンコーダにおいて、現在のピクチャおよび現在のピクチャのすべての参照ピクチャのヒストグラムを計算する。現在のピクチャと現在のピクチャのすべての参照ピクチャとの間のヒストグラム差が所与の閾値よりも小さい場合、現在のピクチャに対してＩＣを無効とし、そうでない場合、現在のピクチャに対してＩＣを有効とする。

３．６ バイラテラルマッチングの改良を伴うマージ／スキップモードの例
まず、利用可能な候補の数が最大候補サイズ１９に達するまで、空間的に近傍のブロックおよび時間的に近傍のブロックの動きベクトルおよび参照インデックスを冗長性チェック付き候補リストに挿入することで、マージ候補リストを構築する。マージ／スキップモードのマージ候補リストは、予め規定された挿入順に基づいて、ＨＥＶＣ（結合候補およびゼロ候補）に用いられる空間的候補、時間的候補、アフィン候補、高度な時間的ＭＶＰ（ＡＴＭＶＰ）候補、空間的時間的ＭＶＰ（ＳＴＭＶＰ）候補、および追加候補を挿入することで、図２５に示す番号付きブロックのコンテキストにおいて、構築される。

（１）ブロック１〜４の空間的候補
（２）ブロック１〜４の外挿アフィン候補
（３）ＡＴＭＶＰ
（４）ＳＴＭＶＰ
（５）仮想アフィン候補
（６）空間的候補（ブロック５）（利用可能な候補の数が６よりも少ない場合にのみ使用される）。
（７）外挿アフィン候補（ブロック５）。
（８）時間的候補（ＨＥＶＣのように導出）
（９）非隣接空間的候補の後にアフィン候補を外挿する（ブロック６〜４９）。
（１０）結合候補
（１１）ゼロ候補

なお、ＩＣフラグは、ＳＴＭＶＰおよびアフィンを除き、マージ候補から継承される。また、最初の４つの空間的候補について、双予測のものを単一予測のものの前に挿入する。

いくつかの実装形態において、現在のブロックに接続されていないブロックにアクセスすることができる。非隣接ブロックが非イントラモードでコーディングされている場合、関連する動き情報を追加のマージ候補として追加してもよい。

４． ２値化法およびマージインデックス符号化の例
いくつかの実施形態において、いくつかの２値化法を選択することができる。１つの構文要素の場合、まず分布に基づいて関連値を２値化して２値列にする。各２値に対して、コンテキストコーディング法またはバイパスコーディング法でコーディングされてもよい。

４．１ 例示的な単純および短縮された単純（ＴＵ）２値化処理
各符号なし整数値のシンボルｘ≧０の場合、ＣＡＢＡＣにおける単項コードワードは、ｘ個の「１」ビットに終端「０」ビットを加えたものからなる。短縮された単項（ＴＵ）コードは、０≦ｘ≦Ｓのｘに対してのみ規定され、ここで、ｘ＜Ｓの場合、コードは単項コードによって与えられ、ｘ＝Ｓの場合、終端の「０」ビットは無視され、ｘ＝ＳのＴＵコードは、ｘ「１」ビットのみからなるコード名によって与えられる。

４．２ 例示的なＫ次のＥｘｐ−Ｇｏｌｏｍｂ（ＥＧｋ）二値化処理
ＥＧｋ二値化の場合、ｋ＋２・ｌ（ｘ）＋１という同じ符号長を有するシンボルの数は、幾何学的に増加している。理想的な符号長と符号確率との間のシャノンの関係を逆にすることによって、例えば、ＥＧ０が、ｐｄｆｐ（ｘ）＝１／２・（ｘ＋１）−２ ｗｉｔｈ ｘ≧０のための最適な符号であると容易に推論することができる。このことは、適切に選択されたパラメータｋに対して、ＥＧｋ符号は、典型的に見られるｐｄｆｓの末端のための理想的なプレフィックスフリー符号のかなり良好な１次近似を表すことを非明示的に示す。

４．３ 例示的な短縮ライス（ＴＲ）２値化処理
この処理には、ＴＲの２値化、ｃＭａｘ、およびｃＲｉｃｅＰａｒａｍの請求が入力される。

この処理の出力は、各値ｓｙｍｂｏｌＶａｌを対応する２値列に関連付けるＴＲの２値化である。

ＴＲ２値列は、プレフィックス２値列と、存在する場合には、サフィックス２値列とを連結したものである。

プレフィックス２値列を導出するために、以下を適用する。
−−ｓｙｍｂｏｌＶａｌのプレフィックス値ｐｒｅｆｉｘＶａｌは、以下のように導出される。
ｐｒｅｆｉｘＶａｌ＝ｓｙｍｂｏｌＶａｌ＞＞ｃＲｉｃｅＰａｒａｍ
−−ＴＲ２値列のプレフィックスは、以下のように指定される。
ｐｒｅｆｉｘＶａｌがｃＭａｘ＞＞ｃＲｉｃｅＰａｒａｍ未満である場合、プレフィックス２値列は、長さｐｒｅｆｉｘＶａｌ＋１にｂｉｎＩｄｘを付けたビット列である。ｂｉｎＩｄｘ＜ｐｒｅｆｉｘＶａｌの２値は、１に等しい。ｂｉｎＩｄｘがｐｒｅｆｉｘＶａｌに等しい２値は、０に等しい。

ｃＭａｘがｓｙｍｂｏｌＶａｌより大きく、ｃＲｉｃｅＰａｒａｍが０より大きい場合、ＴＲ２値列のサフィックスが存在し、それは以下のように導出される。
−−サフィックス値ｓｕｆｆｉｘＶａｌは、以下のように導出される。
ｓｕｆｆｉｘＶａｌ＝ｓｙｍｂｏｌＶａｌ−（（ｐｒｅｆｉｘＶａｌ）＜＜ｃＲｉｃｅＰａｒａｍ）
−−ＴＲ２値列のサフィックスは、ｓｕｆｆｉｘＶａｌの固定長（ＦＬ）２値化処理を呼び出すことによって指定され、ｃＭａｘ値は（１＜＜ｃＲｉｃｅＰａｒａｍ）−１に等しい。

なお、入力パラメータｃＲｉｃｅＰａｒａｍ＝０の場合、ＴＲの２値化は、正確には短縮された単項２値化であり、常に、復号される構文要素の最大可能値に等しいｃＭａｘ値で呼び出される。

４．４ 例示的な固定長（ＦＬ）２値化処理
この処理への入力は、ＦＬの２値化およびｃＭａｘの要求である。

この処理の出力は、各値ｓｙｍｂｏｌＶａｌを対応する２値列に関連付けるＦＬの２値化である。

ＦＬの２値化は、シンボル値ｓｙｍｂｏｌＶａｌのｆｉｘｅｄＬｅｎｇｔｈビットの符号なし整数２値列を使用することによって構築され、ここで、ｆｉｘｅｄＬｅｎｇｔｈ＝Ｃｅｉｌ（Ｌｏｇ２（ｃＭａｘ＋１））である。ＦＬの２値化のための２値ンのインデックス付けは、ｂｉｎＩｄｘ＝０が最上位ビットに関係し、ｂｉｎＩｄｘの値が最下位ビットに向かって増加するように行われる。

４．５ ｍｅｒｇｅ＿ｉｄｘの例示的な符号化
ＨＥＶＣ仕様に規定されているように、まず、許容されるマージ候補の総数が１よりも大きい場合、マージインデックスを２値列に２値化する。

ｃＲｉｃｅＰａｒａｍが０に等しいＴＲ、すなわちＴＵが使用される。ｍｅｒｇｅ＿ｉｄｘの第１のビンは、１つのコンテキストで符号化され、残りのビンが存在する場合、バイパスで符号化される。

５． ＪＥＭにおけるイントラ予測の例示的な実施形態
５．１ ６７個のイントラ予測モードを有するイントラモード符号化の例
自然映像に表される任意のエッジ方向をキャプチャするために、指向性イントラモードの数は、ＨＥＶＣで使用されるように、３３から６５に拡張される。追加の指向性モードは、図２７において薄い灰色の点線の矢印で示され、平面モードとＤＣモードは同じままである。これらのより密度の高い指向性イントラ予測モードは、すべてのブロックサイズ、および輝度およびクロマイントラ予測の両方に適用される。

５．２ 輝度イントラモード符号化の例
ＪＥＭにおいて、イントラ予測モードの総数は、ＨＥＶＣでは３５から６７に増加している。図２７は、６７個のイントラ予測モードの例を示す。

増加した数の指向性イントラモードに適応するために、６つの最大確率モード（ＭＰＭ）を有するイントラモードコーディング法が使用される。２つの主な技術的態様が含まれている。１）６ＭＰＭの導出、および２）６ＭＰＭおよび非ＭＰＭモードのエントロピーコーディング。

ＪＥＭにおいて、ＭＰＭリストに含まれるモードは、次の３つのグループに分類される。
−−近傍のイントラモード
−−導出イントラモード
−−デフォルトのイントラモード

５つの近傍のイントラ予測モードを使用してＭＰＭリストを形成する。５つの近傍のブロックの位置は、マージモードで使用される位置と同じであり、即ち、図２８に示すように、左（Ｌ）、上（Ａ）、下−左（ＢＬ）、上−右（ＡＲ）、および上−左（ＡＬ）である。最初のＭＰＭリストは、５つの隣接するイントラモードおよびプレーナおよびＤＣモードをＭＰＭリストに挿入することで形成される。プルーニング処理を使用して、重複したモードを除去し、唯一のモードをＭＰＭリストに含めることができる。初期モードが含まれる順番は、左、上、平面、ＤＣ、左下、右上、左上である。

ＭＰＭリストが満杯でない（即ち、リストに６つ未満のＭＰＭ候補がある）場合、導出モードを追加し、これらのイントラモードは、ＭＰＭリストに既に含まれている角度モードに−１または＋１を加えることによって得られる。このような追加の導出モードは、非角度モード（ＤＣまたは平面モード）からは生成されない。

最後に、ＭＰＭリストがまだ完成していない場合、デフォルトモードは、垂直、水平、モード２、および対角モードの順に追加される。この処理の結果、６つのＭＰＭモードのユニークなリストが生成される。

６つのＭＰＭを使用する、選択されたモードのエントロピーコーディングのために、短縮された単項２値化が使用される。最初の３つの２値は、現在信号通知されている２値に関連するＭＰＭモードに依存するコンテキストでコーディングされる。ＭＰＭモードは、３つのカテゴリ、即ち、（ａ）主に水平であるモード（即ち、ＭＰＭモード数が対角線方向のモード数以下である）、（ｂ）主に垂直であるモード（即ち、ＭＰＭモードが対角線方向のモード数よりも大きい）、および（ｃ）非角（ＤＣおよび平面）クラスのうちの１つに分類される。従って、３つのコンテキストを使用して、この分類に基づいてＭＰＭインデックスを信号通知する。

残りの６１個の非ＭＰＭを選択するためのコーディングは、以下のように行われる。６１個の非ＭＰＭは、まず、選択されたモードセットと選択されていないモードセットとの２つのセットに分けられる。選択されたモードセットは１６個のモードを含み、選択されていないモードセットには休止（４５個のモード）が割り当てられる。現在のモードが属するモードセットは、フラグ付きビットストリームに示される。表示されるべきモードが選択されたモードセット内にある場合、選択されたモードに４ビットの固定長コードを信号で信号通知し、表示されるべきモードが非選択のセットからのものである場合、選択されたモードに短縮された２進コードを信号で信号通知する。選択されたモードセットは、６１個の非ＭＰＭモードをサブサンプリングすることによって、以下のように生成される。
−−選択したモードを設定する＝｛０，４，８，１２，１６，２０…６０｝
−−未選択モードセット＝｛１，２，３，５，６，７，９，１０…５９｝

エンコーダ側では、ＨＭの類似した２ステージのイントラモード決定処理が使用される。第１のステージ、すなわちイントラモード前選択ステージにおいて、より複雑性の低い絶対変換差の合計（ＳＡＴＤ）コストを使用して、すべての利用可能なイントラモードからＮ個のイントラ予測モードを前選択する。第２のステージにおいて、より複雑性の高いＲ−Ｄコスト選択をさらに適用し、Ｎ個の候補から１つのイントラ予測モードを選択する。しかしながら、６７個のイントラ予測モードが適用される場合、利用可能なモードの総数はおよそ２倍になるので、同じＨＭのエンコーダモード決定処理を直接使用すると、イントラモード前選択ステージの複雑性もまた増大する。エンコーダの複雑性の増加を最小限に抑えるために、２ステップのイントラモード前選択処理が行われる。第１のステップにおいて、絶対変換差（ＳＡＴＤ）測度に基づいて、元の３５個のイントラ予測モード（図２７に黒い実線の矢印で示す）からＮ個（Ｎはイントラ予測ブロックのサイズに依存する）のモードを選択する。第２のステップにおいて、選択されたＮ個のモードの直接近傍（図２７に薄い灰色の点線の矢印で示すような追加のイントラ予測方向）をＳＡＴＤによってさらに検査し、選択されたＮモードのリストを更新する。最後に、まだ含まれていない場合、第１のＭ個のＭＰＭをＮ個のモードに加え、第２ステージのＲ−Ｄコスト検査のために、候補イントラ予測モードの最終リストを生成する。これはＨＭと同様に行われる。ＨＭにおける元の設定値に基づいて、Ｍの値を１だけ増加させ、Ｎは、以下の表１０に示すように、若干減少する。

５．３ クロマイントラモード符号化の例
ＪＥＭでは、クロマＣＢコーディングのために合計１１のイントラモードが許可されている。これらのモードには、５つの伝統的なイントラモードと６つの構成要素共通の線形モデルモードが含まれる。クロマモード候補のリストには、以下の３つの部分が含まれる。

●ＣＣＬＭ ｍｏｄｅｓ
●ＤＭ ｍｏｄｅｓ、現在のクロマブロックの配列された５つの位置をカバーする輝度ＣＢに導出されるイントラ予測モード
〇検査されるべき５つの位置は、Ｉスライスのための現在のクロマブロックの対応する輝度ブロック内の中心（ＣＲ）、左上（ＴＬ）、右上（ＴＲ）、左下（ＢＬ）、右下（ＢＲ）４×４ブロックである。ＰおよびＢスライスの場合、これらの５つのサブブロックは同じモードインデックスを有するので、これらの５つのサブブロックのうちの１つのみをチェックする。５つの配列された輝度位置の例を図２９Ａおよび２９Ｂに示す。
●空間的に近傍のブロックからのクロマ予測モード。
〇５つのクロマ予測モード：左、上、下、左、上、右、左上の空間的に近傍のブロック
〇平面モードとＤＣモード
〇導出モードを追加し、これらのイントラモードは、リストに既に含まれている角度モードに−１または＋１を加えることによって得られる。
〇垂直、水平、モード２

候補リストに新しいクロマイントラモードを追加する度に、プルーニング処理を適用する。次に、非ＣＣＬＭクロマイントラモード候補リストサイズを５にトリミングする。モード信号通知のために、まず、ＣＣＬＭモードの１つまたは従来のクロマイントラ予測モードの１つを使用するかどうかを示すように、１つのフラグを信号通知する。次に、現在のクロマＣＢに使用される正確なクロマ予測モードを指定するために、さらに２、３のフラグが続けられてもよい。

６． 既存の実装形態の例
現在のＨＥＶＣ設計は、動き情報をよりよくコーディングするために、現在のブロックの近傍のブロック（現在のブロックの隣）の相関をとることができる。しかしながら、近傍のブロックが、異なる動き軌跡を有する異なる対象に対応する可能性がある。この場合、その近傍のブロックからの予測は効率的ではない。

非隣接ブロックの動き情報からの予測は、全ての動き情報（一般的には４×４レベル）をキャッシュに記憶するコストをかけることになり、付加的なコーディング利得をもたらし、ハードウェア実装の複雑性を大幅に増大させる。

許容されるマージ候補の数が少ないほど、非２値化法は優れた効果を奏する。しかしながら、許容される候補の総数が大きくなると、単項２値化は次善のものとなり得る。

ＡＭＶＰ候補リスト構築処理のＨＥＶＣ設計は、２つの空間的ＡＭＶＰ候補間のプルーニングのみを呼び出す。制限されたプルーニングによるコーディング損失が無視できるほど小さいので、完全プルーニング（利用可能な候補の各々を他のすべての候補と比較する）は利用されない。しかしながら、より多くのＡＭＶＰ候補が利用可能である場合、プルーニングが重要になる。また、ＬＡＭＶＲが有効である場合、ＡＶＭＰ候補リストの構築方法を検討することが必要である。

７． ＬＵＴに基づく動きベクトル予測の例示的な方法
本開示の技術の実施形態は、既存の実装の欠点を克服し、それにより、より高い符号化効率を有する映像符号化を提供する。開示される技術に基づいたＬＵＴに基づく動きベクトル予測は、既存のおよび将来の映像符号化規格の両方を向上させることができ、様々な実装形態のために以下の例で解明される。ＬＵＴに基づく動きベクトル予測方法において、以前にコーディングされたブロックからの動き情報を有する１つまたは複数のテーブルは、エンコーディング／デコーディング処理時に維持される。１つのブロックの符号化／復号化の間、ＬＵＴにおける関連付けられた動き情報を動き候補リストに追加して、１つのブロックを符号化／復号化した後に、ＬＵＴを使用してもよい。以下に提供される開示される技術の例は、一般的な概念を説明するものであり、限定するものと解釈されるべきではない。一例において、明確に示されていない限り、逆に示されていない限り、これらの例に記載されている様々な特徴を組み合わせることができる。

用語に関して、以下の例は、ＬＵＴのエントリが動き候補である。用語「動き候補」は、ルックアップテーブルに記憶された動き情報のセットを示すためのものである。従来のＡＭＶＰまたはマージモードでは、動き情報を記憶するためにＡＭＶＰまたはマージ候補が用いられる。後述するように、且つ非限定的な例において、動きベクトル予測のための動き候補を有するＬＵＴの概念は、イントラモード符号化のためのイントラ予測モードを有するＬＵＴに拡張されるか、またはＩＣパラメータ符号化のための照明補償パラメータを有するＬＵＴに拡張されるか、またはフィルタパラメータを有するＬＵＴに拡張される。動き候補のためのＬＵＴに基づく方法は、本特許明細書、既存のおよび将来の映像符号化規格に記載されるように、他のタイプのコーディング情報にも拡張され得る。

ルックアップテーブルの例
例Ａ１：各ルックアップテーブルは、各候補がその動き情報に関連付けられた１つ以上の動き候補を含んでもよい。
ａ．動き候補の動き情報は、予測方向、参照インデックス／ピクチャ、動きベクトル、ＬＩＣフラグ、アフィンフラグ、ＭＶＤ精度、ＭＶＤ値の一部または全部を含んでもよい。
ｂ．動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情報および／またはブロック形状をさらに含んでもよい。

ＬＵＴの選択
例Ｂ１：１つのブロックをコーディングする場合、１つのルックアップテーブルからの動き候補の一部または全部を順にチェックすることができる。１つのブロックをコーディングする間に１つの動き候補をチェックするとき、この動き候補を動き候補リスト（例えば、ＡＭＶＰ、マージ候補リスト）に加えてもよい。

ａ．代替的に、複数のルックアップテーブルからの動き候補を順にチェックしてもよい。

ｂ．ルックアップテーブルインデックスは、ＣＴＵ、ＣＴＢ、ＣＵ若しくはＰＵ、または複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域において信号通知されてもよい。

ＬＵＴ規定の例
例Ｃ１：異なる役割を有する複数のＬＵＴを構築してもよい。

（ａ）一例において、１つのＬＵＴ（第１のＬＵＴ）は、ＡＭＶＰ符号化されたブロックからの純粋な動き情報を有する動き候補を含んでもよく、別のＬＵＴ（第２のＬＵＴ）は、ＡＭＶＰ符号化されたブロックおよびマージ符号化されたブロックの両方からの動き情報を含んでもよい。

（ｂ）一例において、１つのＬＵＴ（第１のＬＵＴ）は、純粋に単一予測を伴う動き候補を含んでもよく、別のＬＵＴ（第２のＬＵＴ）は、双予測を伴う動き候補を含んでもよい。

（ｃ）ブロックを符号化する場合、ＬＵＴの検査順序を規定することができる。各ＬＵＴに対して、まず、複数の動き候補をチェックした後、第２のＬＵＴにアクセスすることができる。一例において、上記の場合、１つのブロックを符号化する場合には、まず、第２のＬＵＴからの動き候補をチェックし、次に第１のＬＵＴからの動き候補をチェックする、またはその逆を行う。

ＬＵＴの更新例
例Ｄ１：動き情報を有するブロックを符号化した後（すなわち、ブロックコピーモード、インター符号化モード）に、１つ以上のルックアップテーブルを更新してもよい。

（ａ）現在のブロックを符号化するためにルックアップテーブルを選択することができる場合、ブロックを符号化／復号化した後、選択されたルックアップテーブルをさらに更新してもよい。

（ｂ）更新されるべきルックアップテーブルは、符号化情報および／またはブロック／ＬＣＵの位置に基づいて選択されてもよい。

（ｃ）ブロックが直接信号通知される動き情報（例えば、ＡＭＶＰモード）で符号化される場合、ブロックの動き情報をルックアップテーブルに加えてもよい。

例Ｄ２：一例において、ブロック内コピーモードでブロックを符号化／復号化した後は、すべてのＬＵＴが更新されない。

ＬＵＴの使用例
例Ｅ１：１つのブロックをマージまたはＡＭＶＰモードで符号化する場合、１つのＬＵＴを使用してもよい。

例Ｅ２：一例において、ブロックがブロック内コピーモードで符号化される場合、ＬＵＴは使用しなくてもよい。

８． ＬＵＴに基づく動きベクトル予測のための追加の実施形態
ＬＵＴに基づく予測方法のための符号化フローの例を図３０に示す。いくつかの実装形態において、更新処理は、領域を復号化した後に行われる。ＬＵＴを頻繁に更新することを回避するために、図３１に一例を示す。

９． 追加の例示的な実施形態
以前コーディングされたブロックの動き情報としてＨＭＶＰ候補を規定する、履歴に基づくＭＶＰ（ＨＭＶＰ）方法が提案される。エンコーディング／デコーディング処理中、複数のＨＭＶＰ候補を有するテーブルが維持される。新しいスライスに遭遇した場合、テーブルは空になる。インターコーディングされたブロックがあるときはいつでも、関連する動き情報を新しいＨＭＶＰ候補としてテーブルの最後のエントリに加える。全体の符号化フローを図３２に示す。

一例において、テーブルサイズはＬ（例えば、Ｌ＝１６または６、または４４）に設定され、これは、Ｌ個までのＨＭＶＰ候補をテーブルに追加することができることを示す。

１つの実施形態において、以前符号化されたブロックからのＬ個よりも多いＨＭＶＰ候補が存在する場合、テーブルが常に最新の以前符号化されたＬ個の動き候補を含むように、先入れ先出し（ＦＩＦＯ）規則が適用される。図３３は、ＦＩＦＯ規則を適用してＨＭＶＰ候補を除去し、提案される方法で使用されるテーブルに新しいものを追加する例を示す。

別の実施形態において、新しい動き候補を追加するときはいつでも（例えば、現在のブロックがインター符号化、および非アフィンモードであるなど）、まず、冗長性チェック処理を適用し、ＬＵＴに同じまたは類似した動き候補があるかどうかを識別する。

いくつかの例を以下に示す。

図３４Ａは、新しい動き候補を追加する前に、ＬＵＴが満杯であった場合の例を示す。

図３４Ｂは、新しい動き候補を追加する前に、ＬＵＴが満杯でなかった場合の例を示す。

図３４Ａおよび図３４Ａは、ともに、冗長性除去に基づくＬＵＴ更新方法（１つの冗長性動き候補を除去する）の例を示す。

図３５Ａおよび図３５Ｂは、冗長性除去に基づくＬＵＴ更新方法（複数の冗長性動き候補を除去する、図では２つの候補を示す）の２つの場合の例示の実装形態を示す。

図３５Ａは、新しい動き候補を追加する前に、ＬＵＴが満杯であった場合の例を示す。

図３５Ｂは、新しい動き候補を追加する前に、ＬＵＴが満杯でなかった場合の例を示す。

ＨＭＶＰ候補は、マージ候補リスト構築処理において使用され得る。ＴＭＶＰ候補の後に、テーブルにおける最後のエントリから最初のエントリ（または最後のＫ０ＨＭＶＰ、例えば、Ｋ０＝１６または６）までのすべてのＨＭＶＰ候補を挿入する。ＨＭＶＰ候補に対してプルーニングを適用する。利用可能なマージ候補の総数が信号通知された最大許容マージ候補に達すると、マージ候補リスト構築処理を終了する。代替的に、加算された動き候補の総数が、所与の値に達すると、ＬＵＴからの動き候補の取り出しを終了する。

同様に、ＨＭＶＰ候補は、ＡＭＶＰ候補リスト構築処理において使用されてもよい。ＴＭＶＰ候補の後に、テーブルにおける最後のＫ１個のＨＭＶＰ候補の動きベクトルを挿入する。ＡＭＶＰ対象参照ピクチャと同じ参照ピクチャを有するＨＭＶＰ候補のみを用いて、ＡＭＶＰ候補リストを構築する。ＨＭＶＰ候補に対してプルーニングを適用する。一例において、Ｋ１は４に設定される。

上述した例は、以下に説明する方法、例えば、方法３６１０および３６２０に関連して組み込まれてもよく、この方法は、ビデオデコーダおよび／またはビデオエンコーダにおいて実装してもよい。

図３６Ａおよび３６Ｂは、映像処理方法の一例を示すフローチャートである。図３６Ａにおいて、方法３６１０は、ステップ３６１２において、ルックアップテーブル（ＬＵＴ）のセットを維持することを含み、各ＬＵＴは、映像データにおける第１の映像ブロックの前に復号化された以前復号化された映像ブロックから導出された動き候補を含む。方法３６００は、ステップ３６１４において、第１の映像ブロックのビットストリーム表現と第１の映像ブロックとの間で変換を行うことをさらに含む。方法３６１０は、ステップ３６１６において、変換に基づいて、ＬＵＴのセットにおけるＬＵＴの１つまたは複数を更新することをさらに含む。

図３６Ｂにおいて、方法３６２０は、ステップ３６２２において、映像データの第１のブロックのビットストリーム表現を受信することを含む。方法３６２０は、ステップ３６２４において、ルックアップテーブル（ＬＵＴ）のセットに基づいてビットストリーム表現を処理して、映像データの第１のブロックを生成することを含み、ＬＵＴのセットは、符号化候補を含む。

上述した方法／技術の特徴および実施形態を、項目に基づくフォーマットを使用して以下に説明する。

１． 映像処理方法が提供され、この方法は、テーブルのセットを維持することを含み、各テーブルは、映像データにおける第１の映像ブロックの前に復号化された、以前復号化された映像ブロックから導出された動き候補を含み、第１の映像ブロックのビットストリーム表現と第１の映像ブロックとの間で変換を行うことと、変換に基づいて、このテーブルのセットにおける１つまたは複数のテーブルを更新することと、を含む、映像処理方法（図３６Ａに示すような方法３６１０）。

２． １つまたは複数のテーブルを更新することは、変換に基づいて、１つまたは複数のテーブルを更新するかどうかを決定することを含む、第１項に記載の方法。

３． 第１の映像ブロックは、異なるピクチャからの参照サンプルを使用するインター符号化モードを使用して符号化される、第１項に記載の方法。

４． 第１の映像ブロックは、第１の映像ブロックを含む現在のピクチャからの参照サンプルを使用するイントラブロックコピーモードを使用して符号化される、第１項に記載の方法。

５． 第１の映像ブロックは、映像データのスライス、ピクチャ、またはタイルに含まれる、第１項に記載の方法。

６． 変換は、テーブルのセットに基づいて再構築された第１の映像ブロックを取得するために行われ、テーブルの１つまたは複数は、再構築された第１の映像ブロックを用いて更新される、第１項に記載の方法。

７． 変換は、テーブルのセットを使用せずに再構築された第１の映像ブロックを取得するために行われ、テーブルの１つ以上は、再構築された第１の映像ブロックを用いて更新される、第１項に記載の方法。

８． 変換は、テーブルのセットに基づいて再構築された第１の映像ブロックを取得するために行われ、テーブルは、いずれも再構築された第１の映像ブロックを用いて更新されない、第１項に記載の方法。

９． 更新されたテーブルのセットに基づいて、映像データにおける第２の映像ブロックのビットストリーム表現と第２の映像ブロックとの間で変換を行うことをさらに含む、第１項に記載の方法。

１０． 変換を行うことは、第１の映像ブロックまたは第２の映像ブロックからビットストリーム表現を生成することを含む、第１〜９項に記載の方法。

１１． 変換を行うことは、ビットストリーム表現から第１の映像ブロックまたは第２の映像ブロックを生成することを含む、第１〜９項に記載の方法。

１２． 第２の映像ブロックは、第１の映像ブロックが生成された後に生成される、第１１項に記載の方法。

１３． 第２の映像ブロックを生成するために利用されるテーブルの１つは、第１の映像ブロックから導出される動き候補を含む、第１１項に記載の方法。

１４． １つまたは複数のテーブルを更新することは、１つまたは複数のテーブルに第１の映像ブロックの動き情報を追加することを含む、第１項に記載の方法。

１５． テーブルのセットにおける動き候補の１つは、第１の映像ブロックの近傍の第３の映像ブロックから導出される、第１項に記載の方法。

１６． テーブルのセットにおける動き候補の１つは、第１の映像ブロックの近傍ではない第４の映像ブロックから導出される、第１項に記載の方法。

１７． テーブルのセットにおける第１の動き候補は、第１の映像ブロックの近傍の第３の映像ブロックから導出され、テーブルにおける第２の動き候補は、第１の映像ブロックの近傍ではない第４の映像ブロックから導出される、第１項に記載の方法。

１８． 動き情報は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む、第１項に記載の方法。

１９． 動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含む、第１項に記載の方法。

２０． 動き情報は、動き情報がどこから来ているかを示すために、ブロック形状情報をさらに含む、請求項１に記載の方法。

２１． 変換を行うことは、１つのテーブルから順に動き候補の一部または全部をチェックすることを含む、第１項に記載の方法。

２２． 変換を行うことは、複数のテーブルから順に動き候補をチェックすることを含む、第１項に記載の方法。

２３． 変換を行うことは、第１の映像ブロックを復号化するために動き候補をチェックする選択されたテーブルインデックスを信号通知することを含む、第１項に記載の方法。

２４． 信号通知することは、符号化ツリーユニット（ＣＴＵ）、符号化ツリーブロック（ＣＴＢ）、符号化ユニット（ＣＵ）、予測ユニット（ＰＵ）、または複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域のレベルで行われる、第２３項の方法。

２５． 特定の規則に従って、テーブルのセットにおける１つのテーブルを更新する、第１項に記載の方法。

２６． テーブルのセットのうちの第１のテーブルは、高度動きベクトル予測（ＡＭＶＰ）の符号化ブロックのみからの動き情報によって更新され、テーブルのセットのうちの第２のテーブルは、ＡＭＶＰおよびマージ符号化ブロックからの動き情報によって更新される、第２５項記載の方法。

２７． テーブルのセットのうちの第１のテーブルは、インター符号化ブロックのみからの動き情報によって更新され、テーブルのセットのうちの第２のテーブルは、ブロック内コピーモードで符号化ブロックからの動き情報によって更新される、第２６項記載の方法。

２８． テーブルのセットのうちの第１のテーブルは、単一予測動き情報のみで更新され、テーブルのセットのうちの第２のテーブルは、双予測動き情報のみで動き候補によって更新される、第２６項に記載の方法。

２９． 第１のテーブルにおける動き候補をチェックする前に、第２のテーブルにおける動き候補をチェックする、請求項２６または２８に記載の方法。

３０． 第１のテーブルにおける動き候補をチェックする後に、第２のテーブルにおける動き候補をチェックする、請求項２８または２９に記載の方法。

３１． 映像データの第１のブロックのビットストリーム表現を受信することと、テーブルのセットに基づいてこのビットストリーム表現を処理することと、映像データの第１のブロックを生成することと、を含み、このテーブルのセットは、符号化候補を含む、映像処理方法（例えばズ３６Ｂに示す方法３６２０）。

３２． 符号化候補は、動き候補を含む、第３１項に記載の方法。

３３． テーブルのセットのうちの第１のテーブルは、高度動きベクトル予測（ＡＭＶＰ）の符号化ブロックのみからの動き情報を有する動き候補を含み、テーブルのセットのうちの第２のテーブルは、ＡＭＶＰおよびマージ符号化ブロックからの動き情報を有する動き候補を含む、第３２項記載の方法。

３４． テーブルのセットのうちの第１のテーブルは、単一予測のみを伴う動き候補を含み、テーブルのセットの第２のテーブルは、双予測のみを伴う動き候補を含む、第３２項に記載の方法。

３５． テーブルのセットのうちの第１のテーブルは、インター符号化された動き候補を含み、テーブルの第２のテーブルは、イントラブロックコピーモードによって符号化された動き候補を含む、第３２項に記載の方法。

３６． 第１のテーブルにおける動き候補をチェックする前に、第２のテーブルにおける動き候補をチェックする、第３３〜３５項のいずれか１項に記載の方法。

３７． 第１のテーブルにおける動き候補をチェックする後に、第２のテーブルにおける動き候補をチェックする、第３３〜３５項のいずれか１項に記載の方法。

３８． テーブルは、映像データの第２のブロックの動き情報を予測するために用いられる、第３１項に記載の方法。

３９． 符号化候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む動き情報を含む、第３１項に記載の方法。

４０． 符号化候補は、動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含む動き情報を含む、第３１項に記載の方法。

４１． 符号化候補は、動き情報がどこから来ているかを示すために、ブロック形状情報をさらに含む動き情報を含む、第３１項に記載の方法。

４２． 処理することは、映像データの第１のブロックのビットストリーム表現を復号化することを含む、第３１項に記載の方法。

４３． 動き候補は、イントラモード符号化のためのイントラ予測モードの動き候補に対応する、第１〜３０、３２〜３４、３６、および３７項のいずれか１項に記載の方法。

４４． 前記動き候補が、ＩＣパラメータ符号化のための照明補償パラメータを含む動き候補に対応する、請求項１〜３０、３２〜３４、３６、および３７のいずれか１項に記載の方法。

４５． 動き候補の動き情報は、フィルタパラメータを含む、第１４、１８〜２０、２６〜２８、３３、３５および３８〜４１項に記載の方法。

４６． 処理装置と、その処理装置に命令が記憶された非一時的メモリとを備える装置であって、命令が処理装置によって実装されることにより、処理装置に、第１項から第４６項のいずれか１項に記載の方法を実施させる装置。

４７． 非一時的なコンピュータ可読媒体に記憶されたコンピュータプログラム製品であって、第１〜４６項のいずれか１項に記載の方法を実行するためのプログラムコードを含む、コンピュータプログラム製品。

９． 開示される技術の例示的な実装形態
図３７は、映像処理装置３７００のブロック図である。装置３７００は、本明細書に記載の方法の１つ以上を実装するために使用してもよい。装置３７００は、スマートフォン、タブレット、コンピュータ、モノのインターネット（ＩｏＴ）受信機等に実施されてもよい。装置３７００は、１つ以上の処理装置３７０２と、１つ以上のメモリ３７０４と、映像処理ハードウェア３７０６と、を含んでもよい。１つまたは複数の処理装置３７０２は、本明細書に記載される１つ以上の方法（方法３６１０および３６２０を含むが、これに限定されない）を実装するように構成されてもよい。メモリ（複数可）３７０４は、本明細書で説明される方法および技術を実装するために使用されるデータおよびコードを記憶するために使用してもよい。映像処理ハードウェア３７０６は、本明細書に記載される技術をハードウェア回路にて実装するために使用してもよい。

いくつかの実施形態において、映像符号化法は、図３７を参照して説明したように、ハードウェアプラットフォームに実装される装置を使用して実施してもよい。

以上、説明の目的で本開示の技術の特定の実施形態を説明したが、本発明の範囲から逸脱することなく様々な修正が可能であることは、理解されるであろう。従って、本開示の技術は、添付の特許請求の範囲による場合を除き、限定されない。

本特許明細書に記載された主題および機能操作の実装形態は、本明細書に開示された構造およびその構造的等価物を含め、様々なシステム、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、若しくはハードウェアで実施されてもよく、またはそれらの１つ以上の組み合わせで実施してもよい。本明細書に記載された主題の実施形態は、１つ以上のコンピュータプログラム製品、すなわち、データ処理装置によって実行されるため、またはデータ処理装置の操作を制御するために、有形で非可搬性のコンピュータ可読媒体上に符号化されたコンピュータプログラム命令の１つ以上のモジュールとして実施することができる。このコンピュータ可読媒体は、機械可読記憶装置、機械可読記憶基板、記憶装置、機械可読伝播信号をもたらす物質の組成物、またはこれらの１つ以上の組み合わせであってもよい。「データ処理ユニット」または「データ処理装置」という用語は、例えば、プログラマブル処理装置、コンピュータ、または複数の処理装置若しくはコンピュータを含め、データを処理するためのすべての装置、デバイス、および機械を含む。この装置は、ハードウェアの他に、当該コンピュータプログラムの実行環境を作るコード、例えば、処理装置ファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１つ以上の組み合わせを構成するコードを含んでもよい。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとも呼ばれる）は、コンパイルされた言語または解釈された言語を含む任意の形式のプログラミング言語で記述することができ、それは、スタンドアロンプログラムとして、またはコンピューティング環境で使用するのに適したモジュール、コンポーネント、サブルーチン、または他のユニットとして、も含む任意の形式で展開することができる。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータを保持するファイルの一部（例えば、マークアップ言語文書に格納された１つ以上のスクリプト）に記録されていてもよいし、当該プログラム専用の単一のファイルに記憶されていてもよいし、複数の調整ファイル（例えば、１つ以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）に記憶されていてもよい。１つのコンピュータプログラムを、１つのサイトに位置する１つのコンピュータ、または複数のサイトに分散され通信ネットワークによって相互接続される複数のコンピュータで実行させるように展開可能である。

本明細書に記載されたプロセスおよびロジックフローは、入力データ上で動作し、出力を生成することによって機能を実行するための１つ以上のコンピュータプログラムを実行する１つ以上のプログラマブル処理装置によって行うことができる。プロセスおよびロジックフローはまた、特別目的のロジック回路、例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）によって実行することができ、装置はまた、特別目的のロジック回路として実装することができる。

コンピュータプログラムの実行に適した処理装置は、例えば、汎用および専用マイクロ処理装置の両方、並びに任意の種類のデジタルコンピュータの任意の１つ以上の処理装置を含む。一般的に、処理装置は、読み出し専用メモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの本質的な要素は、命令を実行するための処理装置と、命令およびデータを記憶するための１つ以上の記憶装置とである。一般的に、コンピュータは、データを記憶するための１つ以上の大容量記憶デバイス、例えば、磁気、光磁気ディスク、または光ディスクを含んでもよく、またはこれらの大容量記憶デバイスからデータを受信するか、またはこれらにデータを転送するように動作可能に結合されてもよい。しかしながら、コンピュータは、このようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを記憶するのに適したコンピュータ可読媒体は、あらゆる形式の不揮発性メモリ、媒体、および記憶装置を含み、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ記憶装置等の半導体記憶装置を含む。処理装置およびメモリは、専用ロジック回路によって補完されてもよく、または専用ロジック回路に組み込まれてもよい。

本明細書は、図面とともに、例示のみを目的とするものであり、例示的とは例を意味することが意図される。本明細書で使用される場合、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈からそうでないことが明確に示されていない限り、複数形も含むことが意図される。さらに、文脈からそうでないことが明確に示されていない限り、「または」の使用は、「および／または」を含むことが意図される。

本特許明細書は多くの詳細を含むが、これらは、任意の発明の範囲または特許請求の範囲を限定するものと解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明と解釈されるべきである。本特許明細書において別の実施形態の文脈で説明されている特定の特徴は、１つの例において組み合わせて実装してもよい。逆に、単一の例の文脈で説明された様々な特徴は、複数の実施形態において別個にまたは任意の適切なサブコンビネーションで実装してもよい。さらに、特徴は、特定の組み合わせで作用するものとして上記に記載され、最初にそのように主張されていてもよいが、主張された組み合わせからの１つ以上の特徴は、場合によっては、組み合わせから抜粋されることができ、主張された組み合わせは、サブ組み合わせまたはサブ組み合わせのバリエーションに向けられてもよい。

同様に、動作は図面において特定の順番で示されているが、これは、所望の結果を達成するために、このような動作が示された特定の順番でまたは連続した順番で実行されること、または示された全ての操作が実行されることを必要とするものと理解されるべきではない。また、本特許明細書に記載されている例における様々なシステムモジュールの分離は、全ての実施形態においてこのような分離を必要とするものと理解されるべきではない。

いくつかの実装形態および例のみが記載されており、本特許明細書に記載され図示されている内容に基づいて、他の実施形態、拡張および変形が可能である。

Claims (47)

1. テーブルのセットを維持することを含み、各テーブルは、映像データにおける第１の映像ブロックの前に復号化された、以前復号化された映像ブロックから導出された動き候補を含み、
   第１の映像ブロックのビットストリーム表現と前記第１の映像ブロックとの間で変換を行うことと、
   前記変換に基づいて、前記テーブルのセットにおける１つまたは複数のテーブルを更新することと、を含む、映像処理方法。
2. 前記１つまたは複数のテーブルを更新することは、前記変換に基づいて、前記１つまたは複数のテーブルを更新するかどうかを決定することを含む、請求項１に記載の方法。
3. 前記第１の映像ブロックは、異なるピクチャからの参照サンプルを使用するインター符号化モードを使用して符号化される、請求項１に記載の方法。
4. 前記第１の映像ブロックは、前記第１の映像ブロックを含む現在のピクチャからの参照サンプルを使用するイントラブロックコピーモードを使用して符号化される、請求項１に記載の方法。
5. 前記第１の映像ブロックは、前記映像データのスライス、ピクチャ、またはタイルに含まれる、請求項１に記載の方法。
6. 前記変換は、前記テーブルのセットに基づいて再構築された第１の映像ブロックを取得するために行われ、テーブルの前記１つまたは複数は、前記再構築された第１の映像ブロックを用いて更新される、請求項１に記載の方法。
7. 前記変換は、前記テーブルのセットを使用せずに再構築された第１の映像ブロックを取得するために行われ、前記テーブルの１つ以上は、前記再構築された第１の映像ブロックを用いて更新される、請求項１に記載の方法。
8. 前記変換は、前記テーブルのセットに基づいて再構築された第１の映像ブロックを取得するために行われ、前記テーブルは、いずれも前記再構築された第１の映像ブロックを用いて更新されない、請求項１に記載の方法。
9. 前記更新されたテーブルのセットに基づいて、前記映像データにおける前記第２の映像ブロックのビットストリーム表現と第２の映像ブロックとの間で変換を行うことをさらに含む、請求項１に記載の方法。
10. 前記変換を行うことは、前記第１の映像ブロックまたは前記第２の映像ブロックから前記ビットストリーム表現を生成することを含む、請求項１または９に記載の方法。
11. 前記変換を行うことは、前記ビットストリーム表現から前記第１の映像ブロックまたは前記第２の映像ブロックを生成することを含む、請求項１または９に記載の方法。
12. 前記第２の映像ブロックは、前記第１の映像ブロックが生成された後に生成される、請求項１１に記載の方法。
13. 前記第２の映像ブロックを生成するために利用される前記テーブルの１つは、前記第１の映像ブロックから導出される動き候補を含む、請求項１１に記載の方法。
14. 前記１つまたは複数のテーブルを前記更新することは、前記１つまたは複数のテーブルに前記第１の映像ブロックの動き情報を追加することを含む、請求項１に記載の方法。
15. 前記テーブルのセットにおける前記動き候補の１つは、前記第１の映像ブロックの近傍の第３の映像ブロックから導出される、請求項１に記載の方法。
16. 前記テーブルのセットにおける前記動き候補の１つは、前記第１の映像ブロックの近傍ではない第４の映像ブロックから導出される、請求項１に記載の方法。
17. 前記テーブルのセットにおける第１の動き候補は、前記第１の映像ブロックの近傍の第３の映像ブロックから導出され、前記テーブルにおける第２の動き候補は、前記第１の映像ブロックの近傍ではない第４の映像ブロックから導出される、請求項１に記載の方法。
18. 前記動き情報は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む、請求項１に記載の方法。
19. 前記動き情報は、前記動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含む、請求項１に記載の方法。
20. 動き情報は、動き情報がどこから来ているかを示すために、ブロック形状情報をさらに含む、請求項１に記載の方法。
21. 前記変換を行うことは、１つのテーブルから順に動き候補の一部または全部をチェックすることを含む、請求項１に記載の方法。
22. 前記変換を行うことは、複数のテーブルから順に動き候補をチェックすることを含む、請求項１に記載の方法。
23. 前記変換を行うことは、前記第１の映像ブロックを復号化するために動き候補をチェックする選択されたテーブルインデックスを信号通知することを含む、請求項１に記載の方法。
24. 前記信号通知することは、符号化ツリーユニット（ＣＴＵ）、符号化ツリーブロック（ＣＴＢ）、符号化ユニット（ＣＵ）、予測ユニット（ＰＵ）、または複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域の前記レベルで行われる、請求項２３に記載の方法。
25. 特定の規則に従って、前記テーブルのセットにおける１つのテーブルを更新する、請求項１に記載の方法。
26. 前記テーブルのセットのうちの第１のテーブルは、高度動きベクトル予測（ＡＭＶＰ）の符号化ブロックのみからの動き情報によって更新され、前記テーブルのセットのうちの第２のテーブルは、ＡＭＶＰおよびマージ符号化ブロックからの動き情報によって更新される、請求項２５に記載の方法。
27. 前記テーブルのセットのうちの第１のテーブルは、インター符号化ブロックのみからの動き情報で更新され、前記テーブルのセットのうちの第２のテーブルは、ブロック内コピーモードで符号化されたブロックからの動き情報で更新される、請求項２６に記載の方法。
28. テーブルのセットのうちの第１のテーブルは、単一予測動き情報のみで更新され、前記テーブルのセットのうちの第２のテーブルは、双予測動き情報のみで動き候補によって更新される、請求項２６に記載の方法。
29. 前記第１のテーブルにおける前記動き候補をチェックする前に、前記第２のテーブルにおける前記動き候補をチェックする、請求項２６または２８に記載の方法。
30. 前記第１のテーブルにおける前記動き候補をチェックした後に、前記第２のテーブルにおける前記動き候補をチェックする、請求項２８または２９に記載の方法。
31. 映像処理方法であって、
    映像データの第１のブロックのビットストリーム表現を受信することと、
    テーブルのセットに基づいてビットストリーム表現を処理して、映像データの第１のブロックを生成することを含み、テーブルのセットは、符号化候補を含む、映像処理の方法。
32. 前記符号化候補は、動き候補を含む、請求項３１に記載の方法。
33. 前記テーブルのセットのうちの第１のテーブルは、高度動きベクトル予測（ＡＭＶＰ）の符号化ブロックのみからの動き情報を有する動き候補を含み、前記テーブルのセットのうちの第２のテーブルは、ＡＭＶＰおよびマージ符号化ブロックからの動き情報を有する動き候補を含む、請求項３２に記載の方法。
34. 前記テーブルのセットのうちの第１のテーブルは、単一予測のみを伴う動き候補を含み、前記テーブルのセットの第２のテーブルは、双予測のみを伴う動き候補を含む、請求項３２に記載の方法。
35. 前記テーブルのセットのうちの第１のテーブルは、インター符号化された動き候補を含み、前記テーブルのセット第２のテーブルは、イントラブロックコピーモードによって符号化された動き候補を含む、請求項３２に記載の方法。
36. 前記第１のテーブルにおける前記動き候補をチェックする前に、前記第２のテーブルにおける前記動き候補をチェックする、請求項３３〜３５のいずれか１項に記載の方法。
37. 前記第１のテーブルにおける前記動き候補をチェックした後に、前記第２のテーブルにおける前記動き候補をチェックする、請求項３３〜３５のいずれか１項に記載の方法。
38. 前記テーブルは、映像データの第２のブロックの動き情報を予測するために用いられる、請求項３１に記載の方法。
39. 符号化候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む動き情報を含む、請求項３１に記載の方法。
40. 符号化候補は、動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含む動き情報を含む、請求項３１に記載の方法。
41. 符号化候補は、動き情報がどこから来ているかを示すために、ブロック形状情報をさらに含む動き情報を含む、請求項３１に記載の方法。
42. 前記処理することは、映像データの前記第１のブロックの前記ビットストリーム表現を復号化することを含む、請求項３１に記載の方法。
43. 前記動き候補は、イントラモード符号化のためのイントラ予測モードの動き候補に対応する、請求項１〜３０、３２〜３４、３６、および３７のいずれか１項に記載の方法。
44. 前記動き候補が、ＩＣパラメータ符号化のための照明補償パラメータを含む動き候補に対応する、請求項１〜３０、３２〜３４、３６、および３７のいずれか１項に記載の方法。
45. 前記動き候補の動き情報は、フィルタパラメータを含む、請求項１４、１８〜２０、２６〜２８、３３、３５および３８〜４１に記載の方法。
46. 処理装置と、命令を搭載した非一時的メモリとを備え、前記処理装置が実行すると、前記命令は、前記処理装置に、請求項１〜４５のいずれか１つ以上に記載の前記方法を実装させる、装置。
47. 非一時的なコンピュータ可読媒体に記憶されたコンピュータプログラム製品であって、前記コンピュータプログラム製品は、請求項１〜４６のいずれか１つ以上に記載の前記方法を実行するためのプログラムコードを含む、コンピュータプログラム製品。

Images