特表 2021-530938 更新されるべき若しくは更新しない何れかのＬＵＴ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2021-530938(P2021-530938A)

(43)【公表日】2021年11月11日

(54)【発明の名称】更新されるべき若しくは更新しない何れかのＬＵＴ

(51)【国際特許分類】

   H04N 19/109 20140101AFI20211015BHJP

   H04N 19/105 20140101ALI20211015BHJP

   H04N 19/70 20140101ALI20211015BHJP

   H04N 19/174 20140101ALI20211015BHJP

【ＦＩ】

   H04N19/109

   H04N19/105

   H04N19/70

   H04N19/174

【審査請求】有

【予備審査請求】未請求

【全頁数】49

(21)【出願番号】特願2021-523113(P2021-523113)

(86)(22)【出願日】2019年7月1日

(85)【翻訳文提出日】2021年2月24日

(86)【国際出願番号】IB2019055588

(87)【国際公開番号】WO2020003280

(87)【国際公開日】20200102

(31)【優先権主張番号】PCT/CN2018/093663

(32)【優先日】2018年6月29日

(33)【優先権主張国】CN

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JO,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT

(71)【出願人】

【識別番号】520476341

【氏名又は名称】北京字節跳動網絡技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

(71)【出願人】

【識別番号】520477474

【氏名又は名称】バイトダンス インコーポレイテッド

【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．

(74)【代理人】

【識別番号】110002000

【氏名又は名称】特許業務法人栄光特許事務所

(72)【発明者】

【氏名】ジャン リー

(72)【発明者】

【氏名】ジャン カイ

(72)【発明者】

【氏名】リウ ホンビン

(72)【発明者】

【氏名】ワン ユエ

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159MA05

5C159MA21

5C159MC11

5C159ME01

5C159NN10

5C159NN11

5C159PP04

5C159RC12

5C159TA26

5C159TA65

5C159TB06

5C159TB08

5C159TC35

5C159TC41

5C159TC42

5C159TD07

5C159TD15

5C159UA31

(57)【要約】

映像復号化方法は、多数のテーブルを維持することであって、各テーブルは、動き候補のセットを含み、各動き候補は、以前符号化された映像ブロックから導出された対応する動き情報に関連付けられる、維持することと、現在の映像ブロックと映像領域における現在の映像ブロックのビットストリーム表現との間で変換を行うことと、更新規則に基づいて１つ以上のテーブルを更新することと、を含む。
【選択図】図２９

【特許請求の範囲】

【請求項1】

多数のテーブルを維持することであって、各テーブルは、動き候補のセットを含み、各動き候補は、以前に符号化した映像ブロックから導出した対応する動き情報に関連付けられる、維持することと、
現在の映像ブロックと映像領域における前記現在の映像ブロックのビットストリーム表現との間で変換を行うことと、
更新規則に基づいて前記１つ以上のテーブルを更新することと、を含む、
方法。

【請求項2】

前記更新規則は、前記現在の映像ブロックの符号化情報を含む、
請求項１に記載の方法。

【請求項3】

前記符号化情報は、符号化モードを含む、
請求項２に記載の方法。

【請求項4】

前記符号化モードは、異なるピクチャにおける参照サンプルに従って前記映像ブロックを予測するインター符号化モードを含む、
請求項３に記載の方法。

【請求項5】

前記符号化モードは、同じピクチャにおける参照サンプルに従って前記映像ブロックを予測するイントラブロックコピー符号化モードを含む、
請求項３に記載の方法。

【請求項6】

前記更新規則は、前記映像領域における前記映像ブロックの位置を含む、
請求項１に記載の方法。

【請求項7】

前記映像ブロックの位置は、前記映像ブロックを含む符号化ツリーユニット（ＣＴＵ）アドレスを含む、
請求項６に記載の方法。

【請求項8】

前記更新規則は、テーブル使用情報を含む、
請求項１に記載の方法。

【請求項9】

さらに、
１つのテーブルのセットをチェックすることであって、各テーブルは１つ以上の動き候補を含み、各動き候補は前記動き候補の動き情報に関連付けられている、チェックすることと、
１つ以上のテーブルに基づいて前記映像ブロックの動き情報を処理することと、
処理により生成された前記映像ブロックに基づいて前記１つ以上のテーブルを更新することと、を含む、
請求項１に記載の方法。

【請求項10】

現在の映像ブロックと映像領域における前記現在の映像ブロックのビットストリーム表現との間の前記変換処理において、１つのテーブルを用いる場合、同じテーブルを更新する、
請求項１に記載の方法。

【請求項11】

前記現在の映像ブロックから導出された動き情報を前記選択されたテーブルに加えることによって、前記選択されたテーブルを更新する、
請求項１〜１０のいずれかに記載の方法。

【請求項12】

動き候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む動き情報に関連付けられる、
請求項１〜１１のいずれかに記載の方法。

【請求項13】

１つの動き候補が、イントラ符号化されたブロックに使用されるイントラ予測モードに関連付けられる、
請求項１〜１２のいずれかに記載の方法。

【請求項14】

１つの動き候補が、ＩＣ（照明補償）符号化されたブロックに使用される複数の照明補償（ＩＣ）パラメータに関連付けられる、
請求項１〜１３のいずれかに記載の方法。

【請求項15】

動き候補は、フィルタリング処理に用いられるフィルタパラメータに関連付けられる、
請求項１〜１３のいずれかに記載の方法。

【請求項16】

請求項１〜１５の１項以上に記載の方法を実装するように構成された処理装置を備える、
映像復号化装置。

【請求項17】

請求項１〜１５の１項以上に記載の方法を実装するように構成された処理装置を備える映像符号化装置。

【請求項18】

コードが記憶されたコンピュータ読み取り可能なプログラム媒体であって、
前記コードは、処理装置により実行された場合、前記処理装置に請求項１〜１５の１項以上に記載の方法を実装させる命令を含む、
プログラム媒体。

【請求項19】

本明細書に記載される方法、システムまたは装置。

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

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

【背景技術】

【0003】

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

【発明の概要】

【0004】

本明細書は、動きベクトルのマージリストを使用してデジタル映像を符号化および復号化するための方法、システム、およびデバイスを開示する。

【0005】

１つの例示的な態様において、映像復号化方法が開示される。この方法は、多数のテーブルを維持することであって、各テーブルは、動き候補のセットを含み、各動き候補は、以前符号化された映像ブロックから導出された対応する動き情報に関連付けられる、維持することと、現在の映像ブロックと映像領域における現在の映像ブロックのビットストリーム表現との間で変換を行うことと、更新規則に基づいて１つ以上のテーブルを更新することと、を含む。

【0006】

別の例示的な態様において、別の映像復号化方法が開示される。この方法は、テーブルのセットをチェックすることを含み、各テーブルは、１つ以上の動き候補を含み、各動き候補が動き候補の動き情報に関連付けられており、１つ以上のテーブルに基づいてこの映像ブロックの動き情報を処理することと、処理によって生成された映像ブロックに基づいて１つ以上のテーブルを更新することと、を含む。

【0007】

さらに別の例示的な態様において、別の映像デコーディング方法が開示される。この方法は、テーブルのセットをチェックすることを含み、各テーブルは、１つ以上の動き候補を含み、各動き候補が動き候補の動き情報に関連付けられており、ピクチャ内の映像ブロックの位置に基づいて１つ以上のテーブルを選択することと、選択された１つ以上のテーブルに基づいてこの映像ブロックの動き情報を処理することと、処理によって生成された映像ブロックに基づいて選択されたテーブルを更新することと、を含む。

【0008】

さらに別の例示的な態様において、別の映像デコーディング方法が開示される。この方法は、テーブルのセットをチェックすることを含み、各テーブルは、１つ以上の動き候補を含み、各動き候補が動き候補の動き情報に関連付けられており、映像ブロックと、１つ以上のテーブル内の動き候補のうちの１つとの間の距離に基づいて１つ以上のテーブルを選択することと、選択された１つ以上のテーブルに基づいて、画像ブロックの動き情報を処理することと、処理によって生成された映像ブロックに基づいて選択されたテーブルを更新することと、を含む。

【0009】

さらに別の例示的な態様において、本明細書で説明される映像符号化方法を実装するビデオエンコーダデバイスが開示される。

【0010】

さらに別の代表的な態様では、本明細書で説明される様々な技法は、非一時的なコンピュータ可読媒体に記憶されるコンピュータプログラム製品として実施され得る。このコンピュータプログラム製品は、本明細書に記載の方法を実行するためのプログラムコードを含む。

【0011】

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

【0012】

１つ以上の実装形態の詳細は、添付の添付ファイル、図面、および以下の説明に記載されている。他の特徴は、説明および図面、並びに特許請求の範囲の記載から明らかとなろう。

【図面の簡単な説明】

【0013】

【図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】映像ビットストリーム処理の別の例示的な方法のフローチャートである。

【発明を実施するための形態】

【0014】

映像の圧縮率を改善するために、研究者らは、映像をコーディングする新しい技術を絶えず求めている。

【0015】

１． 導入

【0016】

本明細書は、映像符号化技術に関する。具体的には、映像符号化における動き情報のコーディング（例えば、マージモード、ＡＭＶＰモード）に関する。ＨＥＶＣのような既存の映像符号化規格に適用してもよいし、規格（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）を確定させるために適用してもよい。本発明は、将来の映像符号化規格またはビデオコーデックにも適用可能である。

【0017】

簡単な説明

【0018】

映像符号化規格は、主に周知のＩＴＵ−ＴおよびＩＳＯ／ＩＥＣ規格の開発によって発展してきた。ＩＴＵ−ＴはＨ．２６１とＨ．２６３を、ＩＳＯ／ＩＥＣはＭＰＥＧ−１とＭＰＥＧ−４ Ｖｉｓｕａｌを、両団体はＨ．２６２／ＭＰＥＧ−２ ＶｉｄｅｏとＨ．２６４／ＭＰＥＧ−４ 高度映像符号化（ＡＶＣ）とＨ．２６５／ＨＥＶＣ規格を共同で作成した。映像符号化規格、Ｈ．２６２は、時間予測プラス変換コーディングが利用されるハイブリッド映像符号化構造に基づく。典型的なＨＥＶＣエンコーダフレームワークの一例を図１に示す。
２．１ パーティション構造
２．１．１ Ｈ．２６４／ＡＶＣにおけるパーティションツリー構造

【0019】

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

【0020】

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

【0021】

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

【0022】

２．１．２ ＨＥＶＣにおけるパーティションツリー構造

【0023】

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

【0024】

以下、ＨＥＶＣを使用したハイブリッド映像符号化に関連する様々な特徴に焦点を当てる。

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

図４は、ＣＴＢをＣＢ［及び変換ブロック（ＴＢ）］に細分する例を示す。実線はＣＢ境界を示し、点線はＴＢ境界を示す。（ａ）ＣＴＢとその分割（ｂ）対応する４分木。

【0030】

２．１．２．１ 変換ブロックおよびユニットへのツリー構造の分割

【0031】

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

【0032】

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

【0033】

２．１．２．２ 親子ノード

【0034】

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

【0035】

２．１．３ ＪＥＭにおけるより大きいＣＴＵを有する４分木＋２分木ブロック構造

【0036】

ＨＥＶＣを超えた将来の映像符号化技術を探索するため、２０１５年には、ＶＣＥＧとＭＰＥＧが共同で共同映像探索チーム（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ：ＪＶＥＴ）を設立した。それ以来、多くの新しい方法がＪＶＥＴによって採用され、共同探索モデル（ＪＥＭ）と呼ばれる参照ソフトウェアに組み込まれてきた。

【0037】

２．１．３．１ ＱＴＢＴブロックの分割構造

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

２．１．４ ＶＶＣの３分木

【0045】

いくつかの実施形態において、４分木および２分木以外のツリータイプがサポートされる。本実装形態において、図６（ｄ）、（ｅ）に示すように、３分木（ＴＴ）パーティションを２つ以上、すなわち、水平および垂直中心側の３分木を導入する。

【0046】

図６は、（ａ）４分木分割（ｂ）垂直２分木分割（ｃ）水平２分木分割（ｄ）垂直中心側３分木分割（ｅ）水平中心側３分木分割（ｅ）水平中心側３分木分割を示す。

【0047】

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

【0048】

２．１．５ 分割構造

【0049】

この応答で使用されるツリー構造は、マルチツリータイプ（Ｍｕｌｔｉ−Ｔｒｅｅ Ｔｙｐｅ：ＭＴＴ）と呼ばれ、ＱＴＢＴを一般化したものである。ＱＴＢＴにおいて、図５に示すように、まず、コーディングツリーユニット（ＣＴＵ）を４分木構造で分割する。４分木のリーフノードは、２分木構造によってさらに分割される。

【0050】

ＭＴＴの基本構造は、２つのタイプのツリーノードを構成する。図７に示すように、領域ツリー（ＲＴ）および予測ツリー（ＰＴ）は、９つのタイプのパーティションをサポートする。

【0051】

ＦＩＧ．７は、（ａ）４分木分割（ｂ）垂直２分木分割（ｃ）水平２分木分割（ｄ）垂直３分木分割（ｅ）水平３分木分割（ｆ）水平上方非対称２分木分割（ｇ）水平下方非対称２分木分割（ｈ）垂直左非対称２分木分割（ｉ）垂直右非対称２分木分割を示す。

【0052】

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

【0053】

２．２ ＨＥＶＣ／Ｈ．２６５におけるインター予測

【0054】

各インター予測ＰＵは、１つまたは２つの参照ピクチャリストのための動きパラメータを有する。動きパラメータは、動きベクトルおよび参照ピクチャインデックスを含む。２つの参照ピクチャリストのうちの１つの参照ピクチャリストの使用は、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃを使用して信号通知されてもよい。動きベクトルは、予測子に対してデルタとして明確にコーディングされてもよく、このようなコーディングモードは、ＡＭＶＰモードと呼ばれる。

【0055】

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

【0056】

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

【0057】

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

【0058】

以下、ＨＥＶＣに規定されるインター予測モードについて詳細に説明する。まず、マージモードについて説明する。

【0059】

２．２．１ マージモード

【0060】

２．２．１．１ マージモードの候補の導出

【0061】

マージモードを使用してＰＵを予測する場合、ビットストリームからマージ候補リストにおけるエントリを指すインデックスを構文解析し、これを使用して動き情報を検索する。このリストの構成は、ＨＥＶＣ規格で規定されており、以下のステップのシーケンスに基づいてまとめることができる。
・ ステップ１：初期候補導出
ｏ ステップ１．１：空間的候補導出
ｏ ステップ１．２：空間的候補の冗長性チェック
ｏ ステップ１．３：時間的候補導出
・ ステップ２：追加候補挿入
ｏ ステップ２．１：双予測候補の作成
ｏ ステップ２．２：動きゼロ候補の挿入

【0062】

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

【0063】

以下、上述したステップに関連付けられた動作を詳しく説明する。

【0064】

２．２．１．２ 空間的候補導出

【0065】

空間的マージ候補の導出において、図１０に示す位置にある候補の中から、最大４つのマージ候補を選択する。導出の順序はＡ１、Ｂ１、Ｂ０、Ａ０、Ｂ２である。位置Ａ１、Ｂ１、Ｂ０、Ａ０のいずれかのＰＵが利用可能でない場合（例えば、別のスライスまたはタイルに属しているため）、またはイントラコーディングされた場合にのみ、位置Ｂ２が考慮される。位置Ａ１の候補を加えた後、残りの候補を加えると、冗長性チェックを受け、それにより、同じ動き情報を有する候補を確実にリストから排除でき、コーディング効率を向上させることができる。計算の複雑性を低減するために、前述の冗長性チェックにおいて、考えられる候補対のすべてを考慮することはしない。代わりに、図１１において矢印でリンクされた対のみを考慮し、冗長性チェックに使用される対応する候補が同じ動き情報を有していない場合にのみ、その候補をリストに加える。重複した動き情報の別のソースは、２Ｎ×２Ｎとは異なるパーティションに関連付けられた「第２のＰＵ」である。一例として、図１２は、それぞれＮ×２Ｎおよび２Ｎ×Ｎの場合の第２のＰＵを示す。現在のＰＵをＮ×２Ｎに分割する場合、リスト構築に位置Ａ１の候補は考慮されない。実際、この候補を加えることにより、双予測ユニットが同じ動き情報を有するようになり、１つのコーディングユニットに１つのＰＵのみを有することは冗長である。同様に、現在のＰＵを２Ｎ×Ｎに分割する場合、位置Ｂ１は考慮されない。

【0066】

２．２．１．３ 時間的候補導出

【0067】

このステップにおいて、１つの候補のみがリストに追加される。具体的には、この時間的マージ候補の導出において、所与の参照ピクチャリストにおける現在のピクチャとの間に最小のＰＯＣ差を有するピクチャに属するコロケーションＰＵに基づいて、スケーリングされた動きベクトルを導出する。スライスヘッダにおいて、コロケーションＰＵの導出に用いられる参照ピクチャリストが明確に信号通知される。図１３に点線で示すように、時間的マージ候補のスケーリングされた動きベクトルが得られる。これは、ＰＯＣ距離ｔｂおよびｔｄを利用して、コロケーションＰＵの動きベクトルからスケーリングしたものである。ｔｂは、現在のピクチャの参照ピクチャと現在のピクチャのＰＯＣ差として規定し、ｔｄは、コロケーションＰＵの参照ピクチャとコロケーションピクチャのＰＯＣ差として規定する。時間的マージ候補の参照ピクチャインデックスをゼロに等しく設定する。このスケーリング処理の実際的な実現については、ＨＥＶＣ仕様に記載されている。Ｂスライスの場合、２つの動きベクトル、即ち、１つは参照ピクチャリスト０のためのもの、もう１つは参照ピクチャリスト１のためのものを取得し、これらを組み合わせることによって、双予測マージ候補を形成する。時間的マージ候補のための動きベクトルのスケーリングの説明。

【0068】

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

【0069】

２．２．１．４ 追加候補挿入

【0070】

時空間的マージ候補の他に、２つの追加のタイプのマージ候補、すなわち、結合双予測マージ候補およびゼロマージ候補がある。時空間的マージ候補を利用して、結合双予測マージ候補を生成する。結合双予測マージ候補は、Ｂスライスのみに使用される。最初の候補の第１の参照ピクチャリスト動きパラメータと別の候補の第２の参照ピクチャリスト動きパラメータとを組み合わせることで、結合双予測候補を生成する。これら２つのタプルが異なる動き仮説を提供する場合、これらのタプルは、新しい双予測候補を形成する。一例として、図１５は、オリジナルリスト（左側）における、ｍｖＬ０、ｒｅｆＩｄｘＬ０またはｍｖＬ１、ｒｅｆＩｄｘＬ１を有する２つの候補を用いて、最終リスト（右側）に加えられる結合双予測マージ候補を生成する場合を示す。これらの追加のマージ候補を生成するために考慮される組み合わせについては、様々な規則が存在する。

【0071】

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

【0072】

２．２．１．５ 並列処理のための動き推定領域

【0073】

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

【0074】

【表1】

【0075】

ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２ ｐｌｕｓ ２は、８．５．３．２．２．２節で指定されたマージモードの輝度動きベクトルの導出処理と、８．５．３．２．３節で指定された空間的マージ候補の導出処理で使用される変数Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌの値を指定する。ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２の値は、０〜ＣｔｂＬｏｇ２ＳｉｚｅＹ＿２を含む範囲内とする。
変数Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌは、以下のように導出される。
Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌ＝ｌｏｇ２＿ｐａｒａｌｌｅｌ＿ｍｅｒｇｅ＿ｌｅｖｅｌ＿ｍｉｎｕｓ２＋２ （７−３７）
注３：Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌの値は、マージ候補リストを並列に導出する組み込み能力を示す。例えば、Ｌｏｇ２ＰａｒＭｒｇＬｅｖｅｌが６に等しい場合、６４×６４ブロックに含まれたすべての予測ユニット（ＰＵ）およびコーディングユニット（ＣＵ）のためのマージ候補リストを並列に導出することができる。

【0076】

２．２．２ ＡＭＶＰモードにおける動きベクトル予測

【0077】

動きベクトル予測は、動きベクトルと近傍のＰＵとの間の空間−時間的相関を利用し、これを動きパラメータの明確な伝送に用いる。まず、左側、上側の時間的に近傍のＰＵ位置の可用性をチェックし、冗長な候補を取り除き、ゼロベクトルを加えることで、候補リストの長さを一定にすることで、動きベクトル候補リストを構築する。次いで、エンコーダは、候補リストから最良の予測子を選択し、選択された候補を示す対応するインデックスを送信することができる。マージインデックスの信号通知と同様に、最良の動きベクトル候補のインデックスは、短縮された単項を使用してエンコードされる。この場合のエンコーディング対象の最大値は２である（例えば、図２〜図８）。以下の章では、動きベクトル予測候補の導出処理の詳細を説明する。

【0078】

２．２．２．１ 動きベクトル予測候補の導出

【0079】

図１６に、動きベクトル予測候補の導出処理をまとめる。

【0080】

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

【0081】

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

【0082】

２．２．２．２ 空間的動きベクトル候補

【0083】

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

【0084】

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

【0085】

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

【0086】

２．２．２．３ 時間的動きベクトル候補

【0087】

参照ピクチャインデックスを導出する以外は、時間的マージ候補を導出するための処理は、すべて、空間的動きベクトル候補を導出するための処理と同じである（図６参照）。参照ピクチャインデックスはデコーダに信号通知される。

【0088】

２．２．２．４ ＡＭＶＰ情報の信号通知

【0089】

ＡＭＶＰモードの場合、ビットストリームにおいて、４つの部分、すなわち、予測方向、参照インデックス、ＭＶＤ、およびｍｖ予測子候補インデックスを信号通知することができる。

構文テーブル：

【0090】

【表2】

７．３．８．９ 動きベクトル差構文

【0091】

【表3】

【0092】

２．３ 共同探索モデル（ＪＥＭ）における新しいインター予測方法

【0093】

２．３．１ サブＣＵに基づく動きベクトル予測

【0094】

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

【0095】

サブＣＵ動き予測のためにより正確な動きフィールドを維持するために、参照フレームの動き圧縮は現在無効にされている。

【0096】

２．３．１．１ 代替の時間的動きベクトル予測

【0097】

代替的な時間的動きベクトル予測（ＡＴＭＶＰ）において、動きベクトル時間的動きベクトル予測（ＴＭＶＰ）法は、現在のＣＵより小さいブロックから複数セットの動き情報（動きベクトルおよび参照インデックスを含む）を取り出すことで修正される。図１８に示すように、サブＣＵは、Ｎ×Ｎ個のブロックの正方形である（デフォルトでは、Ｎは４に設定される）。

【0098】

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

【0099】

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

【0100】

図１９は、ソースブロックおよびソースピクチャの特定の例を示す。

【0101】

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

【0102】

２．３．１．２ 空間的−時間的動きベクトル予測

【0103】

この方法において、サブＣＵの動きベクトルは、ラスタスキャンの順に沿って再帰的に導出される。図２０にこの概念を示す。４つの４×４サブＣＵ、Ａ、Ｂ、Ｃ、およびＤを含む８×８ＣＵを考える。現在のフレームの近傍の４×４ブロックには、ａ、ｂ、ｃ、ｄというラベルが付けられている。

【0104】

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

【0105】

図２０は、４つのサブブロック（Ａ−Ｄ）およびその近傍のブロックを有する１つのＣＵの例を示す。

【0106】

２．３．１．３ サブＣＵ動き予測モード信号通知

【0107】

サブＣＵモードは追加のマージ候補として有効とされ、モードを信号通知するために追加の構文要素は必要とされない。ＡＴＭＶＰモードおよびＳＴＭＶＰモードを表すように、各ＣＵのマージ候補リストに２つの追加のマージ候補を加える。シーケンスパラメータセットがＡＴＭＶＰおよびＳＴＭＶＰが有効であることを示す場合、７個までのマージ候補を使用する。追加のマージ候補のエンコーディングロジックは、ＨＭにおけるマージ候補の場合と同じであり、つまり、ＰまたはＢスライスにおける各ＣＵについて、２つの追加のマージ候補に対して２回以上のＲＤチェックが必要となる。

【0108】

ＪＥＭにおいて、マージインデックスのすべてのビンは、ＣＡＢＡＣによってコンテキストコーディングされる。一方、ＨＥＶＣにおいては、第１のビンのみがコンテキストコーディングされ、残りのビンはコンテキストバイパスコーディングされる。

【0109】

２．３．２ 適応型動きベクトル差解像度

【0110】

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

【0111】

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

【0112】

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

【0113】

エンコーダにおいて、ＣＵレベルのＲＤチェックは、どのＭＶＤ解像度をＣＵに用いるかを決定するために用いられる。すなわち、１つのＭＶＤ解像度ごとに３回、ＣＵレベルのＲＤチェックを行う。エンコーダの速度を速めるために、ＪＥＭにおいては、以下の符号化方式が適用される。

【0114】

通常の１／４輝度サンプルＭＶＤ解像度を有するＣＵのＲＤチェック中、現在のＣＵの動き情報（整数輝度サンプル精度）が記憶される。整数輝度サンプルおよび４輝度サンプルのＭＶＤ解像度を有する同じＣＵのＲＤチェック中に、記憶された動き情報（丸められた後）は、更なる小範囲動きベクトル改良の開始点として使用されるので、時間がかかる動き推定処理が３回重複しない。

【0115】

４輝度サンプルＭＶＤ解像度を有するＣＵのＲＤチェックを条件付きで呼び出す。ＣＵの場合、整数輝度サンプルＭＶＤ解像度のＲＤコストが１／４輝度サンプルＭＶＤ解像度のそれよりもはるかに大きい場合、ＣＵのための４輝度サンプルＭＶＤ解像度のＲＤチェックは省略される。

【0116】

２．３．３ パターンマッチング動きベクトル導出

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

【数1】

【0123】

図２１に示すように、このバイラテラルマッチングは、２つの異なる参照ピクチャにおける現在のＣＵの動き軌跡に沿った２つのブロック間の最も近いマッチングを見出すことで、現在のＣＵの動き情報を導出するために用いられる。連続した動き軌跡を仮定すると、２つの参照ブロックを指す動きベクトルＭＶ０、ＭＶ１は、現在のピクチャと２つの参照ピクチャとの間の時間的距離、例えばＴＤ０、ＴＤ１に比例する。特殊なケースとしては、現在のピクチャが時間的に２つの参照ピクチャの間にあり、現在のピクチャと２つの参照ピクチャとの時間的な距離が同じである場合、バイラテラルマッチングはミラーに基づく双方向ＭＶとなる。

【0124】

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

【0125】

２．３．３．１ ＣＵレベルＭＶ候補セット

【0126】

ＣＵレベルのＭＶ候補セットは、以下からなる。
（ｉ） 現在のＣＵがＡＭＶＰモードになっている場合の元のＡＭＶＰ候補
（ｉｉ） すべてのマージ候補、
（ｉｉｉ） 補間ＭＶフィールド内の複数のＭＶ。
（ｉｖ） 左上の近傍の動きベクトル

【0127】

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

【0128】

補間されたＭＶフィールドからの４つのＭＶもＣＵレベル候補リストに追加する。具体的には、現在のＣＵの（０，０）、（Ｗ／２，０）、（０，Ｈ／２）、（Ｗ／２，Ｈ／２）の位置の補間ＭＶを加算する。

【0129】

ＡＭＶＰモードでＦＲＵＣを適用する場合、元のＡＭＶＰ候補をＣＵレベルＭＶ候補セットにも加える。

【0130】

ＣＵレベルにおいて、ＡＭＶＰ ＣＵのための１５個のＭＶおよびマージＣＵに対し、１３個までのＭＶを候補リストに加える。

【0131】

２．３．３．２ サブＣＵレベルＭＶ候補セット

【0132】

サブＣＵレベルのＭＶ候補セットは、以下からなる。
（ｉ） ＣＵレベルの検索から決定されたＭＶ、
（ｉｉ） 左上、右上の近傍のＭＶ、
（ｉｉｉ） 参照ピクチャから並置されたＭＶのスケーリングされたバージョン、
（ｉｖ） 最大４つのＡＴＭＶＰ候補、
（ｖ） 最大４つのＳＴＭＶＰ候補

【0133】

参照ピクチャからのスケーリングされたＭＶは、以下のように導出される。両方のリストにおける参照ピクチャをすべてトラバースする。参照ピクチャにおけるサブＣＵの配列位置にあるＭＶは、開始ＣＵレベルＭＶの参照に対してスケーリングされる。

【0134】

ＡＴＭＶＰおよびＳＴＭＶＰの候補は、最初の４つの候補に限定される

【0135】

サブＣＵレベルにおいて、最大１７個のＭＶが候補リストに追加される。

【0136】

２．３．３．３ 補間ＭＶフィールドの生成

【0137】

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

【0138】

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

【0139】

２．３．３．４ 補間およびマッチングコスト

【0140】

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

【0141】

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

【0142】

【数2】

【0143】

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

【0144】

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

【0145】

２．３．３．５ ＭＶの改良

【0146】

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

【0147】

２．３．３．６ テンプレートマッチングＦＲＵＣマージモードにおける予測方向の選択

【0148】

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

【0149】

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

【0150】

２．３．４ デコーダ側動きベクトル改良

【0151】

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

【0152】

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

【0153】

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

【0154】

２．３．５ バイラテラルマッチングの改良を伴うマージ／スキップモードの例

【0155】

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

【0156】

−ブロック１〜４の空間的候補

【0157】

−ブロック１〜４の外挿アフィン候補

【0158】

−ＡＴＭＶＰ

【0159】

−ＳＴＭＶＰ

【0160】

−仮想アフィン候補

【0161】

−空間的候補（ブロック５）（利用可能な候補の数が６よりも少ない場合にのみ使用される）

【0162】

−外挿アフィン候補（ブロック５）

【0163】

−時間的候補（ＨＥＶＣのように導出）

【0164】

−非隣接空間的候補の後にアフィン候補を外挿する（図２５に示すブロック６〜４９）

【0165】

−結合候補

【0166】

−ゼロ候補

【0167】

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

【0168】

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

【0169】

３． 本明細書に開示される実施形態が解決しようとする課題の例

【0170】

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

【0171】

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

【0172】

４． いくつかの例

【0173】

既存の実装形態の欠点を克服するために、様々な実施形態において、ブロックの動き情報を予測するために、少なくとも１つの動き候補が記憶された１つ以上のルックアップテーブルを使用するＬＵＴに基づく動きベクトル予測技術を実装し、より高いコーディング効率を有する映像符号化を提供することができる。各ＬＵＴは、それぞれが対応する動き情報に関連付けられた１つ以上の動き候補を含んでもよい。動き候補の動き情報は、予測方向、参照インデックス／ピクチャ、動きベクトル、ＬＩＣフラグ、アフィンフラグ、動きベクトル導出（ＭＶＤ）精度、および／またはＭＶＤ値の一部または全部を含んでもよい。動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含んでもよい。

【0174】

開示される技術に基づいたＬＵＴに基づく動きベクトル予測は、既存のおよび将来の映像符号化規格の両方を向上させることができ、様々な実装形態のために以下の例で解明される。ＬＵＴは、履歴データ（例えば、既に処理されたブロック）に基づいてエンコーディング／デコーディング処理を行うことを可能にするため、ＬＵＴに基づく動きベクトル予測は、履歴ベースの動きベクトル予測（ＨＭＶＰ）法と呼ぶこともできる。ＬＵＴに基づく動きベクトル予測方法において、以前にコーディングされたブロックからの動き情報を有する１つまたは複数のテーブルは、エンコーディング／デコーディング処理時に維持される。１つのブロックの符号化／復号化の間、ＬＵＴにおける関連付けられた動き情報を動き候補リストに追加して、１つのブロックを符号化／復号化した後に、ＬＵＴを使用してもよい。以下の実施例は、一般的な概念を説明するための例であると考えられるべきである。これらの例は狭い意味で解釈されるべきではない。さらに、これらの例は、任意の方法で組み合わせることができる。

【0175】

一部の実施形態において、１つのブロックの動き情報を予測するために、少なくとも１つの動き候補が記憶された１つ以上のルックアップテーブルを用いてもよい。実施形態は、動き候補を用いて、ルックアップテーブルに記憶された動き情報のセットを示すことができる。従来のＡＭＶＰまたはマージモードの場合、実施形態では、動き情報を記憶するためにＡＭＶＰまたはマージ候補を使用してもよい。

【0176】

以下の実施例は、一般的な概念を説明する。

【0177】

ルックアップテーブルの例

【0178】

例Ａ１：各ルックアップテーブルは、各候補がその動き情報に関連付けられた１つ以上の動き候補を含んでもよい。
ａ． 動き候補の動き情報は、予測方向、参照インデックス／ピクチャ、動きベクト
ル、ＬＩＣフラグ、アフィンフラグ、ＭＶＤ精度、ＭＶＤ値の一部または全部
を含んでもよい。
ｂ． 動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情
報をさらに含んでもよい。
ｃ． ルックアップテーブルごとに１つのカウンタをさらに割り当ててもよい。
ｉ． ピクチャ／スライス／ＬＣＵ（ＣＴＵ）行／タイルの符号化／復号化の
開始時に、カウンタをゼロに初期化してもよい。
ｉｉ． 一例において、前記カウンタは、ＣＴＵ／ＣＴＢ／ＣＵ／ＣＢ／ＰＵ／
一定の領域サイズ（例えば、８×８または１６×１６）を符号化／復号
化した後に更新されてもよい。
ｉｉｉ．一例において、１つの候補をルックアップテーブルに加える度に、カウ
ンタを１つずつ増加させる。
ｉｖ． 一例において、カウンタは、テーブルのサイズ（許容される動き候補の
数）以下であるべきである。
ｖ． 代替的に、このカウンタを使用して、いくつの動き候補をルックアップ
テーブルに追加しようとしたかを示してもよい（これらのうちのいくつ
かはルックアップテーブルに含まれていたが、後にテーブルから削除し
てもよい）。この場合、カウンタはテーブルのサイズよりも大きくても
よい。
ｄ． テーブルのサイズ（許可される動き候補の数）および／またはテーブルの数
は、固定であってもよいし、適応的であってもよい。テーブルのサイズは、
すべてのテーブルで同じであってもよいし、異なるテーブルで異なってもよ
い。
ｉ． 代替的に、異なるサイズを異なるルックアップテーブル（例えば、１ま
たは２）に使用してもよい。
ｉｉ． 一例において、テーブルのサイズおよび／またはテーブルの数は、予め
規定されてもよい。
ｉｉｉ．一例において、テーブルのサイズおよび／またはテーブルの数は、映像
パラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、
ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ、タイルヘッダ、
符号化ツリーユニット（ＣＴＵ）、符号化ツリーブロック（ＣＴＢ）、符
号化ユニット（ＣＵ）または予測ユニット（ＰＵ）、複数のＣＴＵ／ＣＴ
Ｂ／ＣＵ／ＰＵを含む領域で信号通知されてもよい。
ｉｖ． テーブルのサイズおよび／または数は、スライスタイプ、ピクチャの時
間層インデックス、１つのスライスと最も近いイントラスライスとの間
のピクチャ順序カウント（ＰＯＣ）距離に更に依存してもよい。
ｅ． １つの符号化スレッドに使用されるＮ個のテーブルが存在し、１つのスライ
スを符号化するためにＮ＊Ｐ個のテーブルが必要とされ、ここで、Ｐは、Ｌ
ＣＵ行の数またはタイルの数を示す。
ｉ． 代替的に、１つのスライスを符号化するためにＰ個のテーブルのみが必要
とされてもよく、ＰはＬＣＵ行の数を示し、各ＬＣＵ行は１つのルックア
ップテーブルのみを使用し、タイルが無効とされている場合、Ｎ個でも１
よりも大きくてもよい。

【0179】

ＬＵＴの選択

【0180】

例Ｂ１：１つのブロックをコーディングする場合、１つのルックアップテーブルからの動き候補の一部または全部を順にチェックすることができる。１つのブロックをコーディングする間に１つの動き候補をチェックするとき、この動き候補を動き候補リスト（例えば、ＡＭＶＰ、マージ候補リスト）に加えてもよい。
ａ． 代替的に、複数のルックアップテーブルからの動き候補を順にチェックしても
よい。
ｂ． ルックアップテーブルインデックスは、ＣＴＵ、ＣＴＢ、ＣＵ若しくはＰＵ、
または複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域において信号通知され
てもよい。

【0181】

例Ｂ２：ルックアップテーブルの選択は、ブロックの位置に依存してもよい。
ａ． それはブロックを含むＣＴＵアドレスに依存してもよい。ここで、アイデアを
説明するために、例えばデュアルルックアップテーブル（ＤＬＵＴ）を挙げる
。
ｉ． ブロックがＣＴＵ行内の第１のＭ個のＣＴＵのうちの１つに位置する場合
、第１のルックアップテーブルをブロックの符号化に利用してもよく、Ｃ
ＴＵ行内の残りのＣＴＵに位置するブロックの場合、第２のルックアップ
テーブルを利用してもよい。
ｉｉ． ブロックがＣＴＵ行内の第１のＭ個のＣＴＵの１つに位置する場合、まず
第１のルックアップテーブルの動き候補によってブロックを符号化する
かどうかをチェックし、第１のテーブルに十分な候補がない場合、第２の
ルックアップテーブルをさらに利用することができる。一方、ＣＴＵ行の
残りのＣＴＵに位置するブロックに対して、第２のルックアップテーブル
を利用してもよい。
ｉｉｉ．代替的に、ＣＴＵ行の残りのＣＴＵに位置するブロックについて、第２の
ルックアップテーブルの動き候補がまずブロックの符号化についてチェ
ックされ、第２のテーブルに十分な候補がない場合、第１のルックアップ
テーブルをさらに利用してもよい。

ｂ． それは、１つ以上のルックアップテーブルにおけるブロックの位置と１つの
動き候補に関連付けられた位置との間の距離に依存してもよい。
ｉｖ． 一例において、１つの動き候補が符号化対象のブロックまでのより小さな
距離に関連付けられている場合、別の動き候補と比較して早くチェックされ てもよい。

【0182】

ルックアップテーブルの使用法

【0183】

例Ｃ１：チェック対象のルックアップテーブルにおける動き候補の総数は、予め規定されてもよい。
ａ． それは、符号化情報、ブロックサイズ、ブロック形状等にさらに依存してもよ
い。例えば、ＡＭＶＰモードの場合、ｍ個の動き候補のみをチェックし、マー
ジモードの場合、ｎ個の動き候補をチェックしてもよい（例えば、ｍ＝２、ｎ
＝４４）。
ｂ． 一例において、チェック対象の動き候補の総数は、映像パラメータセット（Ｖ
ＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（
ＰＰＳ）、スライスヘッダ、タイルヘッダ、符号化ツリーユニット（ＣＴＵ）、
符号化ツリーブロック（ＣＴＢ）、符号化ユニット（ＣＵ）または予測ユニッ
ト（ＰＵ）、複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域で信号通知されて
もよい。

【0184】

例Ｃ２：１つのルックアップテーブルに含まれる１つ以上の動き候補は、１つのブロックによって直接継承されてもよい。
ａ． それらをマージモード符号化に使用してもよい。すなわち、マージ候補リスト
導出処理において動き候補をチェックしてもよい。
ｂ． これらは、アフィンマージモード符号化に使用してもよい。
ｉ． アフィンフラグが１である場合、ルックアップテーブルにおける動き候補
をアフィンマージ候補として加えることができる。
ｃ． 以下の場合、ルックアップテーブルにおける動き候補のチェックを有効にして
もよい。
ｉ． ＴＭＶＰ候補を挿入した後、マージ候補リストに空きがある。
ｉｉ． 空間的マージ候補導出のために特定の空間的に近傍のブロックをチェック
した後、マージ候補リストに空きがある。
ｉｉｉ．すべての空間的マージ候補の後、マージ候補リストに空きがある。
ｉｖ． 結合双予測マージ候補の後、マージ候補リストに空きがある。
ｖ． マージ候補リストに動き候補を追加する前に、プルーニングを適用しても
よい。

【0185】

例Ｃ３：ルックアップテーブルに含まれる動き候補は、ブロックの動き情報をコーディングする予測モジュールとして用いられてもよい。
ａ． それらをＡＭＶＰモード符号化に使用してもよい。すなわち、ＡＭＶＰ候補リ
スト導出処理において動き候補をチェックしてもよい。
ｂ． 以下の場合、ルックアップテーブルにおける動き候補のチェックを有効にして
もよい。
ｉ． ＴＭＶＰ候補を挿入した後、ＡＭＶＰ候補リストに空きがある。
ｉｉ． ＡＭＶＰ候補リストは、空間的近傍から選択し、プルーニングした後で、
ＴＭＶＰ候補を挿入する直前には、空きがある。
ｉｉｉ． 上位隣接ブロックからのＡＭＶＰ候補がスケーリング無しで存在しない
場合、および／または左側の近傍のブロックからのＡＭＶＰ候補がスケー
リング無しで存在しない場合。
ｉｖ． ＡＭＶＰ候補リストに動き候補を追加する前に、プルーニングを適用して
もよい。
ｃ． 現在の参照ピクチャと同一の参照ピクチャを有する動き候補をチェックする。
ｉ． 代替的に、現在の参照ピクチャとは異なる参照ピクチャを有する動き候補
も（ＭＶスケーリングされた状態で）チェックする。
ｉｉ． 代替的に、まず、現在の参照ピクチャと同一の参照ピクチャを有するすべ
ての動き候補をチェックし、次に、現在の参照ピクチャとは異なる参照ピ
クチャを有する動き候補をチェックする。
ｉｉｉ．代替的に、マージした後、動き候補をチェックする。

【0186】

例Ｃ４：ルックアップテーブルにおける動き候補のチェック順序は、以下のように規定される（Ｋ（Ｋ＞＝１）個の動き候補をチェックすることができるとする）：
ａ． ルックアップテーブルにおける最後のＫ個の動き候補は、例えば、ＬＵＴへの
エントリインデックスの降順に配列される。
ｂ． 第１のＫ％Ｌ候補。Ｌは、Ｋ＞＝Ｌである場合のルックアップテーブルのサイ
ズであり、例えば、ＬＵＴへのエントリインデックスの降順に配列される。
ｃ． Ｋ＞＝Ｌである場合、ルックアップテーブルにおけるすべての候補（Ｌ個の候
補）。
ｄ． 代替的に、さらに、動き候補指標の降順に基づく。
ｅ． 代替的に、候補情報に基づいて、動き候補に関連付けられた位置の距離や現在
のブロックなど、Ｋ個の動き候補を選択する。
ｆ． 異なるルックアップテーブルのチェック順序は、次のサブセクションのルック
アップテーブルの使用法で規定されている。
ｇ． 一旦マージ／ＡＭＶＰ候補リストが最大許容候補数に達すると、このチェック
処理は終了する。
ｈ． 代替的に、追加された動き候補の数が最大許容動き候補数に達すると、終了す
る。
ｉ． テーブルサイズを示す１つのシンタックス要素ならびにチェック対象の動き候
補の数（すなわち、Ｋ＝Ｌ）は、ＳＰＳ、ＰＰＳ、スライスヘッダ、タイルヘ
ッダにおいて信号通知してもよい。

【0187】

例Ｃ５：１つのブロックの動き情報符号化のためのルックアップテーブルの使用の有効／無効は、ＳＰＳ、ＰＰＳ、スライスヘッダ、タイルヘッダ、ＣＴＵ、ＣＴＢ、ＣＵ、またはＰＵ、複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵを含む領域において信号通知されてもよい。

【0188】

例Ｃ６：ルックアップテーブルからの予測を適用するかどうかは、さらに符号化情報に依存してもよい。１つのブロックに適用しないと推測される場合、予測の指示の追加の信号通知はスキップされる。代替的に、１つのブロックに適用しないと推測される場合、ルックアップテーブルの動き候補にアクセスする必要はなく、関連する動き候補のチェックは省略される。
ａ． ルックアップテーブルからの予測を適用するかどうかは、ブロックサイズ／ブ
ロック形状に依存してもよい。一例において、より小さなブロック、例えば、
４×４、８×４または４×８ブロックについては、ルックアップテーブルから
の予測を実行することを許可されない。
ｂ． ルックアップテーブルからの予測を適用するかどうかは、ブロックがＡＭＶＰ
で符号化されているかマージモードで符号化されているかに依存してもよい。
一例において、ＡＭＶＰモードの場合、ルックアップテーブルからの予測を行
うことは許可されない。
ｃ． ルックアップテーブルからの予測を適用するかどうかは、ブロックがアフィン
の動きまたは他の種類の動き（例えば、並進的な動き）で符号化されるかどう
かに依存してもよい。一例において、アフィンモードの場合、ルックアップテ
ーブルからの予測を行うことは許可されない。

【0189】

例Ｃ７：以前符号化されたフレーム／スライス／タイルにおけるルックアップテーブルの動き候補を使用して、異なるフレーム／スライス／タイルにおけるブロックの動き情報を予測してもよい。
ａ． 一例において、現在のブロックの参照ピクチャに関連付けられたルックアップテーブルのみを、現在のブロックを符号化するために利用してもよい。
ｂ． 一例において、現在のブロックを符号化するために、現在のブロックの同じスライスタイプおよび／または同じ量子化パラメータを有するピクチャに関連付けられたルックアップテーブルのみを利用してもよい。

【0190】

ルックアップテーブルの更新

【0191】

例Ｄ１：動き情報を有するブロックをコーディングした後（すなわち、ＩｎｔｒａＢＣモード、インターコーディングモード）に、１つ以上のルックアップテーブルを更新してもよい。
ａ． 一例において、ルックアップテーブルを更新するかどうかは、ルックアップテ
ーブルを選択するための規則を再利用してもよい。
ｂ． ルックアップテーブルは、符号化情報および／またはブロック／ＬＣＵの位置
に基づいて更新されてもよい。
ｃ． ブロックが直接信号通知される動き情報（例えば、ＡＭＶＰモード）で符号化
される場合、ブロックの動き情報をルックアップテーブルに加えてもよい。
ｉ． 代替的に、ブロックが、いかなる改良も伴わずに、空間的に近傍のブロッ
クから直接継承された動き情報でコーディングされる場合（例えば、改良
を伴わない空間的マージ候補）、ブロックの動き情報をルックアップテー
ブルに加えるべきではない。
ｉｉ． 代替的に、ブロックが、改良を行って、空間的に近傍のブロックから直接
継承された動き情報でコーディングされる場合（ＤＭＶＲ、ＦＲＵＣなど
）、ブロックの動き情報をいかなるルックアップテーブルにも加えるべき
ではない。
ｉｉｉ．代替的に、ブロックが、ルックアップテーブルに記憶された動き候補から
直接継承された動き情報でコーディングされている場合は、ブロックの動
き情報は、いかなるルックアップテーブルにも加えるべきではない。
ｄ． ブロック内のＭ（Ｍ＞＝１）個の代表位置を選択し、この代表位置に関連付け
られた動き情報を使用してルックアップテーブルを更新する。
ｉ． 一例において、代表位置は、ブロック内の４つのコーナー位置（例えば、
図２６のＣ０〜Ｃ３）のうちの１つとして規定される。
ｉｉ． 一例において、代表位置は、ブロック内の中心位置（例えば、図２６にお
けるＣａ＿Ｃｄ）として規定される。
ｉｉｉ．ブロックに対してサブブロック予測が許可されない場合、Ｍは１に設定
される。
ｉｖ． サブブロック予測がブロックに対して許可される場合、Ｍは、１又はサブ
ブロックの総数、又は１とサブブロックの数の間の一意の値に排他的に設
定され得る。
ｖ． 代替的に、ブロックのためにサブブロック予測を許可する場合、Ｍを１に
設定することができ、代表的なサブブロックの選択は、に基づいて行われる。
１． 利用される動き情報の周波数
２． 双予測ブロックであるかどうか
３． 参照ピクチャインデックス／参照ピクチャに基づいて
４． 他の動きベクトルと比較した動きベクトルの差（例えば、最大ＭＶ差を
選択する）
５． 他のコーディング情報
ｅ． Ｍ（Ｍ＞＝１）個の代表位置のセットを選択してルックアップテーブルを更新
する場合、更なる条件をチェックした後、これらを更なる動き候補としてルッ
クアップテーブルに加えてもよい。
ｉ． ルックアップテーブルにおける既存の動き候補に対して、新たな動き情報
のセットをプルーニングしてもよい。
ｉｉ． 一例において、新しい動き情報のセットは、ルックアップテーブルにおけ
る既存の動き候補のいずれかまたは一部と同一であってはならない。
ｉｉｉ．代替的に、新しい動き情報のセットおよび１つの既存の動き候補からの同
じ参照ピクチャの場合、ＭＶの差は、１／複数の閾値よりも小さくてはな
らない。例えば、ＭＶ差の水平および／または垂直モジュールは、１ピク
セルの距離よりも大きくなければならない。
ｉｖ． 代替的に、Ｋ＞Ｌである場合、新しい動き情報のセットを、最後のＫ個の
候補または最初のＫ％Ｌ個の既存の動き候補によってのみプルーニング
し、古い動き候補を再びアクティブにすることができるようにする。
ｖ． 代替的に、プルーニングは適用しない。
ｆ． Ｍ個の動き情報のセットがルックアップテーブルを更新するために用いられる
場合、対応するカウンタをＭだけ増加させるべきである。
ｇ． 現在のブロックをコーディングする前に、１つの（上記の方法で）選択された
動き情報のセットに対して、更新されるべきルックアップテーブルのカウンタ
をＫとし、このブロックをコーディングした後、これを、Ｋ％Ｌに等しいイン
デックスを有する追加の動き候補として加える（ここで、Ｌはルックアップテ
ーブルのサイズである）。その例を図２７に示す。
ｉ． 代替的に、それは、ｍｉｎ（Ｋ＋１，Ｌ−１）に等しいインデックスを有
する追加の動き候補として追加される。代替的に、Ｋ＞＝Ｌである場合、
第１の動き候補（インデックス＝０）をルックアップテーブルから取り除
き、後続のＫ個の候補インデックスを１だけ減らす。
ｈ． １つのイントラ制約ブロックをコーディングした後、ルックアップテーブルを
空にしてもよい。
ｉ． 動き情報のエントリをルックアップテーブルに追加する場合、動き情報から導
出することによって、より多くの動き情報のエントリをテーブルに追加しても
よい。この場合、ルックアップテーブルに関連付けられたカウンタを１より大
きい数だけ増加させることができる。
ｉ． 一例において、動き情報のエントリのＭＶをスケーリングし、テーブルに
入れる。
ｉｉ． 一例において、動き情報のエントリのＭＶは、（ｄｘ，ｄｙ）だけ加算さ
れ、テーブルに入れられる。
ｉｉｉ．一例において、２つ以上の動き情報のエントリのＭＶの平均を計算し、テー ブルに入れる。

【0192】

例Ｄ２：１つのブロックが１つのピクチャ／スライス／タイルの境界に位置する場合、ルックアップテーブルの更新は常に許可されない。

【0193】

例Ｄ３：現在のＬＣＵ行をコーディングするために、上記ＬＣＵ行の動き情報を無効にしてもよい。
ａ． この場合、新しいスライス／タイル／ＬＣＵ行の始まりにおいて、利用可能な
動き候補の数を０にリセットしてもよい。

【0194】

例Ｄ４：新しい時間層インデックスを使用してスライス／タイルをコーディングする開始時に、利用可能な動き候補の数を０にリセットすることができる。

【0195】

例Ｄ５：ルックアップテーブルは、同じ時間層インデックスを有する１つのスライス／タイル／ＬＣＵの行／スライスで連続的に更新されてもよい。
ａ． 代替的に、ルックアップテーブルは、各Ｓ（Ｓ＞＝１）個のＣＴＵ／ＣＴＢ／
ＣＵ／ＣＢをコーディング／デコーディングした後、または特定の領域（例え
ば、８×８または１６×１６に等しいサイズ）をコーディング／デコーディン
グした後にのみ更新されてもよい。
ｂ． 代替的に、１つのルックアップテーブルは、最大許容カウンタに達すると、更
新を停止してもよい。
ｃ． 一例において、カウンタは予め規定されてもよい。代替的に、映像パラメータ
セット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメー
タセット（ＰＰＳ）、スライスヘッダ、タイルヘッダ、コーディングツリーユ
ニット（ＣＴＵ）、コーディングツリーブロック（ＣＴＢ）、コーディングユニ
ット（ＣＵ）または予測ユニット（ＰＵ）、複数のＣＴＵ／ＣＴＢ／ＣＵ／Ｐ
Ｕをカバーする領域で信号通知される。

【0196】

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

【0197】

図２９は、映像デコーディング方法２９００の例のフローチャートである。この方法２９００は、多数のテーブル（例えばルックアップテーブル：ＬＵＴ）を維持すること（２９０２）を含み、各テーブルは、動き候補のセットを含み、各動き候補は、以前符号化された映像ブロックから導出された対応する動き情報に関連付けられ、現在の映像ブロックと映像領域における現在の映像ブロックのビットストリーム表現との間で変換を行うこと（２９０４）と、更新規則に基づいて１つ以上のテーブルを更新すること（２９０６）と、を含む。

【0198】

図３０は、映像復号化方法３０００の例のフローチャートである。この方法３０００は、テーブルのセット（例えばルックアップテーブル；ＬＵＴ）をチェックすること（３００２）を含み、各テーブルは、１つ以上の動き候補を含み、各動き候補が動き候補の動き情報に関連付けられており、１つ以上のテーブルに基づいてこの映像ブロックの動き情報を処理すること（３００４）と、処理によって生成された映像ブロックに基づいて１つ以上のテーブルを更新すること（３００６）と、を含む。

【0199】

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

【0200】

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

【0201】

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

【0202】

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

【0203】

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

【0204】

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

【0205】

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

【0206】

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

【図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】

【手続補正書】

【提出日】2021年2月24日

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

映像データを符号化する方法であって、
１つ又は複数のテーブルを維持することであって、前記テーブルは符号化された１つ以上の映像ブロックから導出した１つ以上の動き候補を含み、前記テーブル内の前記動き候補の配置は、前記テーブルへ前記動き候補を追加するシーケンスに基づく、維持することと、
現在の映像ブロックのための動き候補リストを構築することであって、前記構築中に、前記１つ又は複数のテーブルのうち、少なくとも１つの動き候補を選択的に順にチェックする、構築することと、
前記動き候補リストを使用して、前記現在の映像ブロックの動き情報を決定することと、
前記決定された動き情報に基づいて前記現在の映像ブロックを符号化することと、
を含む、方法。

【請求項2】

前記１つ又は複数のテーブルのうちの前記テーブルは、前記テーブルにおける許可された動き候補の数を示すサイズを有する、
請求項１に記載の方法。

【請求項3】

新しい動き候補を前記テーブルに加える前に前記テーブルにおける動き候補の数が前記テーブルの前記サイズに達している場合、前記テーブルに前記新しい動き候補を加えられることによって、前記テーブルにおける１つの候補が削除される、
請求項２に記載の方法。

【請求項4】

前記テーブルの前記サイズの値は、予め規定された値又は構文要素において信号通知される値のうちの一方である、
請求項２に記載の方法。

【請求項5】

前記構文要素は、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、ピクチャヘッダ、及びスライスヘッダのうちの少なくとも１つにおいて信号通知される、
請求項４に記載の方法。

【請求項6】

前記テーブルのためのカウンタを維持することであって、前記カウンタは前記テーブルにおける動き候補の数を表し、前記カウンタは前記テーブルの前記サイズ以下である、維持すること、をさらに含む、
請求項２に記載の方法。

【請求項7】

前記複数のテーブルのサイズが同じである、
請求項２に記載の方法。

【請求項8】

前記複数のテーブルのうち少なくとも２つのサイズが異なる可能性がある、
請求項２に記載の方法。

【請求項9】

前記テーブルの前記サイズは、スライスタイプ、ピクチャの時間層インデックス、１つのスライスと最も近いイントラスライスとの間のピクチャオーダカウント（ＰＯＣ）距離、のうちの少なくとも１つに基づく、
請求項２に記載の方法。

【請求項10】

前記テーブルは、複数の映像ブロックを含む新しい領域の符号化の開始時にリセットされる、
請求項１に記載の方法。

【請求項11】

前記新しい領域は、新しい符号化ツリーユニット（ＣＴＵ行）、新しいタイル又は新しいスライスである、
請求項１０に記載の方法。

【請求項12】

前記リセットすることは、前記テーブルにおける前記動き候補の数をゼロにリセットすることを含む、
請求項１０に記載の方法。

【請求項13】

前記テーブルの数が予め規定される、
請求項１に記載の方法。

【請求項14】

前記１つ又は複数のテーブルは、Ｎ個のテーブルを含み、
Ｎは、Ｋ＊Ｐに等しく、
Ｋは、前記映像データの１つのスライスのＣＴＵ行又はタイルに対応する１つの符号化スレッド当たりのテーブルの数を表す整数であり、
Ｐは、前記スライスにおけるＣＴＵ行の数又はタイルの数を表す整数である、
請求項１に記載の方法。

【請求項15】

前記映像データの１つのスライス又は１つのスライスのタイルのＣＴＵ行が１つのテーブルを使用し、且つＰが前記スライスにおけるＣＴＵ行の数又はタイルの数を表す整数であるときに、ＮがＰに等しい場合、前記１つ又は複数のテーブルは、Ｎ個のテーブルを含む、
請求項１に記載の方法。

【請求項16】

前記１つ又は複数のテーブルの数は、スライスタイプ、ピクチャの時間層インデックス、１つのスライスと最も近いイントラスライスとの間のピクチャオーダカウント（ＰＯＣ）距離、のうちの少なくとも１つに基づく、
請求項１に記載の方法。

【請求項17】

前記テーブルの中の動き候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度又は動きベクトル差分値、のうち少なくとも１つを含む動き情報に関連付けられる、
請求項１に記載の方法。

【請求項18】

前記動き候補リストは、動きベクトル予測リスト又はマージ候補リストのうちの１つである、
請求項１に記載の方法。

【請求項19】

前記チェックの結果に基づいて、前記動き候補リストに１つ以上のチェック済み候補を加える、
請求項１に記載の方法。

【請求項20】

前記符号化することは、前記現在の映像ブロックをビットストリームに符号化することを含む、
請求項１〜１９のいずれか１項に記載の方法。

【請求項21】

前記符号化することは、ビットストリームから前記現在の映像ブロックを復号化することを含む、
請求項１〜１９のいずれか１項に記載の方法。

【請求項22】

処理装置と、この処理装置に命令を記憶させた非一時的メモリとを備える、映像データを符号化する装置であって、
前記処理装置が実行する前記命令によって、前記処理装置に、
１つ又は複数のテーブルを維持することであって、前記テーブルは符号化された１つ以上の映像ブロックから導出した１つ以上の動き候補を含み、前記テーブル内の前記動き候補の配置は、前記テーブルへ前記動き候補を追加するシーケンスに基づく、維持することと、
現在の映像ブロックのための動き候補リストを構築することであって、前記構築中に、前記１つ又は複数のテーブルのうち、少なくとも１つの動き候補を選択的に順にチェックする、構築することと、
前記動き候補リストを使用して、前記現在の映像ブロックの動き情報を決定することと、
前記決定された動き情報に基づいて、前記現在の映像ブロックを符号化することと、
を行わせる装置。

【請求項23】

処理装置に次のことを実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体であって、
前記命令は、処理装置に、
１つ又は複数のテーブルを維持することであって、前記テーブルは符号化された１つ以上の映像ブロックから導出した１つ以上の動き候補を含み、前記テーブル内の前記動き候補の配置は、前記テーブルへ前記動き候補を追加するシーケンスに基づく、維持することと、
現在の映像ブロックのための動き候補リストを構築することであって、前記構築中に、前記１つ又は複数のテーブルのうち、少なくとも１つの動き候補を選択的に順にチェックする、構築することと、
前記動き候補リストを使用して、前記現在の映像ブロックの動き情報を決定することと、
前記決定された動き情報に基づいて、前記現在の映像ブロックを符号化することと、
を行わせる非一時的なコンピュータ可読記憶媒体。

【請求項24】

映像処理装置で行われる方法で生成されたビットストリームの表現を記憶する非一時的なコンピュータ可読記録媒体であって、前記方法は、
１つ又は複数のテーブルを維持することであって、前記テーブルは符号化された１つ以上の映像ブロックから導出した１つ以上の動き候補を含み、前記テーブル内の前記動き候補の配置は、前記テーブルへ前記動き候補を追加するシーケンスに基づく、維持することと、
現在の映像ブロックのための動き候補リストを構築することであって、前記構築中に、前記１つ又は複数のテーブルのうち、少なくとも１つの動き候補を選択的に順にチェックする、構築することと、
前記動き候補リストを使用して、前記現在の映像ブロックの動き情報を決定することと、
前記決定された動き情報に基づいて、前記現在の映像ブロックから前記ビットストリームを生成することと、
を含む、非一時的なコンピュータ可読記録媒体。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】削除

【補正の内容】

【国際調査報告】