特表 2021-530939 ＬＵＴ更新条件

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

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

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

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

(54)【発明の名称】ＬＵＴ更新条件

(51)【国際特許分類】

   H04N 19/513 20140101AFI20211015BHJP

   H04N 19/58 20140101ALI20211015BHJP

   H04N 19/593 20140101ALI20211015BHJP

   H04N 19/70 20140101ALI20211015BHJP

【ＦＩ】

   H04N19/513

   H04N19/58

   H04N19/593

   H04N19/70

【審査請求】有

【予備審査請求】未請求

【全頁数】67

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

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

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

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

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

(87)【国際公開日】20200102

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

(32)【優先日】2018年7月2日

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

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

(32)【優先日】2018年7月7日

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

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

(32)【優先日】2018年8月18日

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

(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

【Ｆターム（参考）】

5C159KK13

5C159MA04

5C159MA05

5C159ME01

5C159NN11

5C159NN21

5C159NN28

5C159RC11

5C159RC16

5C159RC38

5C159UA02

5C159UA05

5C159UA33

(57)【要約】

映像を処理するためのデバイス、システム、および方法が記載される。代表的な態様において、テーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられ、テーブルに基づいて第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、変換を行った後に、更新規則に基づいて、ゼロ以上のテーブルを更新することを含む映像処理方法が提供される。
【選択図】図３６

【特許請求の範囲】

【請求項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】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

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

【背景技術】

【0003】

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

【発明の概要】

【0004】

符号化候補を含むテーブルのセットを使用してデジタル映像を符号化および復号化することに関連するデバイス、システム、および方法を説明する。記載された方法は、既存の映像符号化規格（例えば、高効率映像符号化（ＨＥＶＣ））および将来の映像符号化規格またはビデオコーデックの両方に適用され得る。

【0005】

１つの代表的な態様において、開示された技術を使用して、映像処理方法を提供してもよく、この方法は、テーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられ、テーブルに基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、変換を行った後に、更新規則に基づいて、ゼロ以上のテーブルを更新することを含む。

【0006】

別の代表的な態様において、テーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられ、テーブルに基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、変換を行った後に、更新終了判定基準に達するまで、映像の中の１つ以上の映像領域に基づいて、１つ以上のテーブルを更新することを含む。

【0007】

１つの代表的な態様において、開示された技術を使用して、別の映像処理方法を提供してもよく、この方法は、動き候補を含む１つ以上のテーブルを維持することを含み、各動き候補は、対応する動き情報に関連付けられ、１つ以上のテーブルのうちの少なくとも１つにおいて動き候補の再配列をすることと、少なくとも１つのテーブルの再配列した動き候補に基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、を含む。

【0008】

さらに別の代表的な態様において、開示された技術を使用して、別の映像処理方法を提供してもよく、この方法は、動き候補を含む１つ以上のテーブルを維持することを含み、各動き候補は、対応する動き情報に関連付けられ、１つ以上のテーブルに基づいて、少なくとも１つ以上のテーブルを使用して、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間の変換を行うことと、第１の映像ブロックの変換に基づいてテーブルに追加の動き候補を追加することによって１つ以上のテーブルを更新することと、テーブル内の動き候補を再配列することを含む。

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【図面の簡単な説明】

【0013】

【図1】典型的な高効率映像符号化（ＨＥＶＣ）ビデオエンコーダおよびデコーダの例示的なブロック図を示す。

【図2】Ｈ．２６４／ＡＶＣにおけるマクロブロック（ＭＢ）パーティションの例を示す。

【図3】コーディングブロック（ＣＢ）を予測ブロック（ＰＢ）に分割する例を示す。

【図4A】コーディングツリーブロック（ＣＴＢ）をＣＢおよび変換ブロック（ＴＢ）にそれぞれ細分化の例および対応する４分木をそれぞれ示す。

【図4B】コーディングツリーブロック（ＣＴＢ）をＣＢおよび変換ブロック（ＴＢ）にそれぞれ細分化の例および対応する４分木をそれぞれ示す。

【図5A】最大符号化ユニット（ＬＣＵ）のための細分化および対応する４分木プラス２分木（ＱＴＢＴ）の例を示す。

【図5B】最大符号化ユニット（ＬＣＵ）のための細分化および対応する４分木プラス２分木（ＱＴＢＴ）の例を示す。

【図6A】符号化ブロックをパーティショニングする例を示す。

【図6B】符号化ブロックをパーティショニングする例を示す。

【図6C】符号化ブロックをパーティショニングする例を示す。

【図6D】符号化ブロックをパーティショニングする例を示す。

【図6E】符号化ブロックをパーティショニングする例を示す。

【図7】ＱＴＢＴに基づくＣＢの細分化の例を示す。

【図8A】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8B】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8C】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8D】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8E】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8F】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8G】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8H】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図8I】ＱＴＢＴの一般化であるマルチツリータイプ（ＭＴＴ）に対応したＣＢのパーティションの例を示す。

【図9A】ツリー型信号通知の例を示す。

【図9B】マージ候補リストの構築例を示す。

【図10】空間的候補の位置の例を示す。

【図11】空間的マージ候補の冗長性チェックの対象となる候補ペアの例を示す。

【図12A】現在のブロックのサイズおよび形状に基づく第２の予測ユニット（ＰＵ）の位置の例を示す。

【図12B】現在のブロックのサイズおよび形状に基づく第２の予測ユニット（ＰＵ）の位置の例を示す。

【図13】時間的マージ候補のための動きベクトルのスケーリングの例を示す。

【図14】時間的マージ候補の候補位置の例を示す。

【図15】結合双予測マージ候補を生成する例を示す。

【図16A】動きベクトル予測候補の導出処理の例を示す。

【図16B】動きベクトル予測候補の導出処理の例を示す。

【図17】空間的動きベクトル候補のための動きベクトルのスケーリングの例を示す。

【図18A】符号化ユニット（ＣＵ）のために代替時間的動きベクトル予測（ＡＴＭＶＰ）アルゴリズムを使用する動き予測の例を示す。

【図18B】符号化ユニット（ＣＵ）のために代替時間的動きベクトル予測（ＡＴＭＶＰ）アルゴリズムを使用する動き予測の例を示す。

【図19】ソースブロックおよびソースピクチャの特定の例を示す。

【図20】は、空間的−時間的動きベクトル予測（ＳＴＭＶＰ）アルゴリズムで使用されるサブブロックおよび近傍のブロックを有するコーディングユニット（ＣＵ）の例を示す。

【図21】フレームレートアップ変換（ＦＲＵＣ）アルゴリズムに基づく特殊なマージモードである、パターンマッチング動きベクトル導出（ＰＭＭＶＤ）モードにおけるバイラテラルマッチングの例を示す。

【図22】ＦＲＵＣアルゴリズムにおけるテンプレートマッチングの例を示す。

【図23】ＦＲＵＣアルゴリズムにおける片側動き推定の例を示す。

【図24】バイラテラルテンプレートマッチングに基づくデコーダ側動きベクトル改良（ＤＭＶＲ）アルゴリズムの一例を示す。

【図25】照明補償（ＩＣ）パラメータを導出するために使用される近傍のサンプルの例を示す。

【図26】空間的マージ候補を導出するための近傍のブロックの例を示す。

【図27】提案される６７個のイントラ予測モードの例を示す。

【図28】最大確率モード導出のための近傍のブロックの例を示す。

【図29A】ＱＴＢＴ構造を有するＩスライスにおける対応する輝度およびクロマサブブロックを示す。

【図29B】ＱＴＢＴ構造を有するＩスライスにおける対応する輝度およびクロマサブブロックを示す。

【図30】ルックアップテーブル更新のための代表的な位置の選択方法の一例を示す。

【図31A】新しい動き情報のセットでルックアップテーブルを更新する例を示す。

【図31B】新しい動き情報のセットでルックアップテーブルを更新する例を示す。

【図32】提案されるＨＭＶＰ方法による復号化フローチャートの一例を示す。

【図33】提案されるＨＭＶＰ方法を用いたテーブルの更新例を示す。

【図34A】冗長性除去に基づくＬＵＴ更新方法（１つの冗長性動き候補を除去する）の例を示す。

【図34B】冗長性除去に基づくＬＵＴ更新方法（１つの冗長性動き候補を除去する）の例を示す。

【図35A】冗長性除去に基づくＬＵＴ更新方法（複数の冗長性動き候補を除去する）の例を示す。

【図35B】冗長性除去に基づくＬＵＴ更新方法（複数の冗長性動き候補を除去する）の例を示す。

【図36】１つのブロックの後に更新されるＬＵＴに基づくＭＶＰ／イントラモード予測／ＩＣパラメータの例のための符号化フローを示す。

【図37】１つの領域の後に更新されるＬＵＴに基づくＭＶＰ／イントラモード予測／ＩＣパラメータの例のための符号化フローを示す。

【図38A】本開示の技術による映像処理のための例示的な方法のフローチャートを示す。

【図38B】本開示の技術による映像処理のための例示的な方法のフローチャートを示す。

【図38C】本開示の技術による映像処理のための例示的な方法のフローチャートを示す。

【図38D】本開示の技術による映像処理のための例示的な方法のフローチャートを示す。

【図39】本明細書に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実装するためのハードウェアプラットフォームの一例を示すブロック図である。

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

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

【表1】

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

【表2】

【0075】

【表3】

【0076】

【表4】

【0077】

対応するセマンティクスは、以下を含む。

【0078】

ｆｉｖｅ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄスライスでサポートされるマージＭＶＰ候補の最大数を５から減算することを指定します。ＭＶＰ候補をマージする最大数ＭａｘＮｕｍＭｅｒｇｅＣａｎｄは、以下のように導出される。
ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ＝５−ｆｉｖｅ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ
ＭａｘＮｕｍＭｅｒｇｅＣａｎｄの値は、１〜５の範囲内である。

【0079】

ｍｅｒｇｅ＿ｆｌａｇ［ｘ０］［ｙ０］は、現在の予測ユニットにおけるインター予測パラメータを隣接するインター予測区間から推測するかどうかを指定する。配列インデックスｘ０，ｙ０は、ピクチャの左上輝度サンプルに対する、考慮される予測ブロックの左上輝度サンプルの位置（ｘ０，ｙ０）を指定する。

【0080】

ｍｅｒｇｅ＿ＦＬａｇ［ｘ０］［ｙ０］が存在しない場合、次のように推論される。

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

【数1】

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

【数2】

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

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

【0136】

【表5】

【0137】

【表6】

【0138】

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

【0139】

【表7】

【0140】

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

【0141】

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

【0142】

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

【0143】

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

【0144】

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

【0145】

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

【0146】

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

【0147】

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

【0148】

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

【表8】

【0149】

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

【0150】

【表9】

【0151】

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

【0152】

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

【0153】

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

【0154】

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

【0155】

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

【0156】

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

【0157】

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

【0158】

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

【0159】

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

【0160】

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

【0161】

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

【表10】

【0162】

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

【0163】

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

【0164】

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

【0165】

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

【0166】

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

【0167】

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

【0168】

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

【0169】

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

【0170】

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

【0171】

開示される技術に基づいたＬＵＴに基づく動きベクトル予測は、既存のおよび将来の映像符号化規格の両方を向上させることができ、様々な実装形態のために以下の例で解明される。以下に提供される開示される技術の例は、一般的な概念を説明するものであり、限定するものと解釈されるべきではない。一例において、明確に示されていない限り、逆に示されていない限り、これらの例に記載されている様々な特徴を組み合わせることができる。

【0172】

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

【0173】

ルックアップテーブルの例
例Ａ：各ルックアップテーブルは、各候補がその動き情報に関連付けられた１つ以上の動き候補を含んでもよい。

【0174】

一例において、テーブルサイズ（例えば、動き候補の最大許容エントリ数）および／またはテーブル数は、シーケンス解像度、最大コーディングユニットサイズ、マージ候補リストのサイズに依存してもよい。

【0175】

ルックアップテーブルの更新
例Ｂ１：動き情報を有するブロックをコーディングした後（すなわち、ＩｎｔｒａＢＣモード、インターコーディングモード）に、１つ以上のルックアップテーブルを更新してもよい。

【0176】

ａ． 一例において、ルックアップテーブルを更新するかどうかは、ルックアップテーブルを選択する規則を再利用してもよく、例えば、現在のブロックを符号化／復号化するためにルックアップテーブルを選択することができる場合、ブロックを符号化／復号化した後、選択されたルックアップテーブルをさらに更新してもよい。

【0177】

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

【0178】

ｃ． ブロックが直接信号通知された動き情報で符号化される場合（例えば、ＡＭＶＰモード、通常／アフィンインターモードのＭＭＶＤモード、通常／アフィンインターモードのＡＭＶＲモード）、ブロックの動き情報をルックアップテーブルに加えることができる。
ｉ． 代替的に、ブロックが、いかなる改良も伴わずに、空間的に近傍のブロックから直接継承された動き情報でコーディングされる場合（例えば、改良を伴わない空間的マージ候補）、ブロックの動き情報をルックアップテーブルに加えるべきではない。
ｉｉ． 代替的に、ブロックが、改良を行って、空間的に近傍のブロックから直接継承された動き情報でコーディングされる場合（ＤＭＶＲ、ＦＲＵＣなど）、ブロックの動き情報をいかなるルックアップテーブルにも加えるべきではない。
ｉｉｉ． 代替的に、ブロックが、ルックアップテーブルに記憶された動き候補から直接継承された動き情報でコーディングされている場合は、ブロックの動き情報は、いかなるルックアップテーブルにも加えるべきではない。
ｉｖ． 一例において、このような動き情報は、テーブルの最後のエントリまたは次の利用可能な動き候補を記憶するために用いられるエントリ等のように、ルックアップテーブルに直接加えられてもよい。
ｖ． 代替的に、このような動き情報は、プルーニングせずに、例えば、いかなるプルーニングもせずに、ルックアップテーブルに直接加えられてもよい。
ｖｉ． 代替的に、このような動き情報は、ルックアップテーブルを再配列するために使用してもよい。
ｖｉｉ． 代替的に、このような動き情報を使用して、プルーニングが制限された状態で（例えば、ルックアップテーブルにおける最新のものと比較して）ルックアップテーブルを更新してもよい。

【0179】

ｄ． ブロック内のＭ（Ｍ≧１）個の代表位置を選択し、この代表位置に関連付けられた動き情報を使用してルックアップテーブルを更新する。
ｉ． 一例において、代表位置は、ブロック内の４つのコーナー位置（例えば、図３０のＣ０〜Ｃ３）のうちの１つとして規定される。
ｉｉ． 一例において、代表位置は、ブロック内の中心位置（例えば、図３０におけるＣａ＿Ｃｄ）として規定される。
ｉｉｉ． ブロックに対してサブブロック予測が許可されない場合、Ｍは１に設定される。
ｉｖ． サブブロック予測がブロックに対して許可される場合、Ｍは、１又はサブブロックの総数、又は１とサブブロックの数の間の一意の値に排他的に設定され得る。
ｖ． 代替的に、ブロックのためにサブブロック予測を許可する場合、Ｍを１に設定することができ、代表的なサブブロックの選択は、に基づいて行われる。
１． 利用される動き情報の周波数
２． 双予測ブロックであるかどうか
３． 参照ピクチャインデックス／参照ピクチャに基づいて
４． 他の動きベクトルと比較した動きベクトルの差（例えば、最大ＭＶ差を選択する）
５． 他のコーディング情報

【0180】

ｅ． Ｍ（Ｍ＞＝１）個の代表位置のセットを選択してルックアップテーブルを更新する場合、更なる条件をチェックした後、これらを更なる動き候補としてルックアップテーブルに加えてもよい。
ｉ． ルックアップテーブルにおける既存の動き候補に対して、新たな動き情報のセットをプルーニングしてもよい。
ｉｉ． 一例において、新しい動き情報のセットは、ルックアップテーブルにおける既存の動き候補のいずれかまたは一部と同一であってはならない。
ｉｉｉ． 代替的に、新しい動き情報のセットおよび１つの既存の動き候補からの同じ参照ピクチャの場合、ＭＶの差は、１／複数の閾値よりも小さくてはならない。例えば、ＭＶ差の水平および／または垂直モジュールは、１ピクセルの距離よりも大きくなければならない。
ｉｖ． 代替的に、Ｋ＞Ｌである場合、新しい動き情報のセットを、最後のＫ個の候補または最初のＫ％Ｌ個の既存の動き候補によってのみプルーニングし、古い動き候補を再びアクティブにすることができるようにする。
ｖ． 代替的に、プルーニングは適用しない。

【0181】

ｆ． Ｍ個の動き情報のセットがルックアップテーブルを更新するために用いられる場合、対応するカウンタをＭだけ増加させるべきである。

【0182】

ｇ． 現在のブロックをコーディングする前に、１つの（上記の方法で）選択された動き情報のセットに対して、更新されるべきルックアップテーブルのカウンタをＫとし、このブロックをコーディングした後、これを、Ｋ％Ｌに等しいインデックスを有する追加の動き候補として加える（ここで、Ｌはルックアップテーブルのサイズである）。その例を図３１Ａおよび３１Ｂに示す。
ｉ． 代替的に、それは、ｍｉｎ（Ｋ＋１，Ｌ−１）に等しいインデックスを有する追加の動き候補として追加される。代替的に、Ｋ≧Ｌである場合、第１の動き候補（インデックス＝０）をルックアップテーブルから取り除き、後続のＫ個の候補インデックスを１だけ減らす。
ｉｉ． 上記両方の方法（Ｋ％Ｌに等しいエントリインデックスに新しい動き候補を加えるか、またはｍｉｎ（Ｋ＋１，Ｌ−１）に等しいインデックスを加える）の場合、同じ／類似した動き候補が存在するかどうかに関わらず、彼らは、前に符号化されたブロックからの動き情報の最新の数セットを保持しようとしている。
ｉｉｉ． 代替的に、動き情報を動き候補としてＬＵＴに追加する場合、まず冗長性チェックを行う。この場合、ＬＵＴは以前に符号化されたブロックからの最新のいくつかのセットの動き情報を保持するが、ＬＵＴから冗長な動き情報を除去してもよい。このような方法を、冗長性除去型ＬＵＴ更新方法と呼ぶ。
１． ＬＵＴに重複した動き候補が存在する場合、ＬＵＴに関連付けられたカウンタを増加させてもよいし、減少させてもよい。
２． この冗長チェックは、例えば、参照ピクチャ／参照ピクチャのインデックスが同じであり、且つ動きベクトルの差が範囲内にあるかまたは同一であるかをチェックすることなど、マージ候補リスト構築処理におけるプルーニング処理として規定されてもよい。
３． ＬＵＴ内に冗長動き候補が見つかった場合、その冗長動き候補を現在の位置から最後のＬＵＴに移動させる。
ａ． 同様に、ＬＵＴ内に冗長動き候補が見つかった場合、この冗長動き候補をＬＵＴから取り除く。また、冗長動き候補の後にＬＵＴに挿入されたすべての動き候補は、前方に移動し、除去された冗長動き候補のエントリを再び満たす。シフトした後、新しい動き候補をＬＵＴに加える。
ｂ． この場合、カウンタは変更されないままである。
ｃ． ＬＵＴにおいて冗長動き候補を特定した後、冗長チェック処理を終了する。
４． 複数の冗長動き候補を特定することができる。この場合、それらのすべてをＬＵＴから削除する。また、残りの動き候補は、すべて順に前方に移動してもよい。
ａ． この場合、カウンタを（冗長動き候補の数−１）だけ減少させる。
ｂ． ｍａｘＲ個の冗長動き候補（ｍａｘＲは正の整数変数）を特定した後、冗長チェック処理を終了する。
５． 冗長性チェック処理は、１つ目の動き候補から最後の動き候補まで（即ち、ＬＵＴに付加された順に、動き情報のあるブロックの復号化処理の順に）行うことができる。
６． 代替的に、ＬＵＴに冗長動き候補がある場合、冗長なものを１つまたは複数個取り除く代わりに、冗長なものから仮想動き候補を導出し、この仮想動き候補を使用して冗長なものを置き換えてもよい。
ａ． 仮想動き候補は、１つ以上の動きベクトルの水平および／または垂直モジュールにオフセットを加えることで、または同じ参照ピクチャを指している場合には２つの動きベクトルの平均値を加えることで、冗長動き候補から導出されてもよい。代替的に、仮想動き候補は、ルックアップテーブルにおける動きベクトルを入力とする任意の関数から導出されてもよい。例示的な機能は以下の通りである。２つまたは複数の動きベクトルを足し合わせ、２つまたは複数の動きベクトルを平均する。動きベクトルは、関数に入力される前にスケーリングされてもよい。
ｂ． なお、冗長動き候補と同じ位置に仮想動き候補を加えてもよい。
ｃ． 他のすべての動き候補の前に、仮想動き候補を追加してもよい（例えば、最小のエントリインデックスから始まり、例えば、ゼロ）。
ｄ． 一例において、現在のＬＵＴが満杯でない場合など、特定の条件下でのみ適用される。
７． 冗長性除去に基づくＬＵＴ更新方法は、以下のような特定の条件下で呼び出されてもよい。
ａ． 現在のブロックはマージモードで符号化されている。
ｂ． 現在のブロックはＡＭＶＰモードで符号化されているが、ＭＶ差の少なくとも１つのモジュールが非ゼロである。
ｃ． 現在のブロックがサブブロックベースの動き予測／動き補償方法で符号化されているか、または符号化されていない（例えば、アフィンモードで符号化されていない）。
ｄ． 現在のブロックはマージモードで符号化され、動き情報はあるタイプ（例えば、空間的に近傍のブロックから、左の近傍のブロックから、時間的ブロックから）に関連付けられている。

【0183】

ｈ． １つのブロックを符号化／復号化した後、１つ以上のルックアップテーブルは、Ｍ個の動き情報のセットをテーブルの末端に挿入するだけで、すなわち、既存の候補のすべての後に、更新されてもよい。
ｉ． 代替的に、さらに、テーブルにおける既存の動き候補をいくつか削除してもよい。
１． 一例において、Ｍ個の動き情報のセットを挿入した後、テーブルが満杯である場合、最初のいくつかの動き候補のエントリをテーブルから削除することができる。
２． 一例において、Ｍ個の動き情報のセットを挿入する前にテーブルが満杯である場合、最初のいくつかの動き候補のエントリをテーブルから削除することができる。
ｉｉ． さらに、代替的に、ブロックがテーブルからの動き候補で符号化されている場合、選択された動き候補をテーブルの最後のエントリに入れるように、テーブルにおける動き候補を再配列してもよい。

【0184】

ｉ． １つの例において、ブロックを符号化／復号化する前に、ルックアップテーブルには、ＨＭＶＰ_０，ＨＭＶＰ_１，ＨＭＶＰ_２，．．．、ＨＭＶＰ_Ｋ−１，ＨＭＶＰ_Ｋ，ＨＭＶＰ_Ｋ＋１，．．．、ＨＭＶＰ_Ｌ−１で示される動き候補が含まれていてもよく、ＨＭＶＰ_ｉはルックアップテーブルのｉ番目のエントリを示す。ブロックがＨＭＶＰ_Ｋから予測されている場合（Ｋが包含的に［０，Ｌ−１］の範囲内にある場合）、このブロックを符号化／復号化した後、ルックアップテーブルは次のように再配列される。ＨＭＶＰ_０，ＨＭＶＰ_１、ＨＭＶＰ_２、・・・、ＨＭＶＰ_Ｋ−１、ＨＭＶＰ_Ｋ、ＨＭＶＰ_Ｋ＋１、・・・、ＨＭＶＰ_Ｌ−１、ＨＭＶＰ_Ｋ

【0185】

ｊ． １つのイントラ制約ブロックをコーディングした後、ルックアップテーブルを空にしてもよい。

【0186】

ｋ． 動き情報のエントリをルックアップテーブルに追加する場合、動き情報から導出することによって、より多くの動き情報のエントリをテーブルに追加してもよい。この場合、ルックアップテーブルに関連付けられたカウンタを１より大きい数だけ増加させることができる。
ｉ． 一例において、動き情報のエントリのＭＶをスケーリングし、テーブルに入れる。
ｉｉ． 一例において、動き情報のエントリのＭＶは、（ｄｘ，ｄｙ）だけ加算され、テーブルに入れられる。
ｉｉｉ． 一例において、２つ以上の動き情報のエントリのＭＶの平均を計算し、テーブルに入れる。

【0187】

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

【0188】

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

【0189】

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

【0190】

例Ｂ５：ルックアップテーブルは、同じ時間層インデックスを有する１つのスライス／タイル／ＬＣＵの行／スライスで連続的に更新されてもよい。
ａ． 代替的に、ルックアップテーブルは、各Ｓ（Ｓ≧１）個のＣＴＵ／ＣＴＢ／ＣＵ／ＣＢをコーディング／デコーディングした後、または特定の領域（例えば、８×８または１６×１６に等しいサイズ）をコーディング／デコーディングした後にのみ更新されてもよい。
ｂ． 代替的に、ルックアップテーブルは、特定のモード（例えば、Ｓ個のインター符号化ブロック）を有する各Ｓ（Ｓ≧１）個のブロック（例えば、ＣＵ／ＣＢ）を符号化／復号化した後にのみ更新されてもよい。代替的に、ルックアップテーブルは、サブブロックに基づく動き予測／動き補償方法で符号化されていない（例えば、アフィンおよび／またはＡＴＭＶＰモードで符号化されていない）各Ｓ（Ｓ≧１）個のインター符号化ブロック（例えば、ＣＵ／ＣＢ）を符号化／復号化した後にのみ更新されてもよい。
ｃ． 代替的に、符号化／復号化されたブロックの左上座標が何らかの条件を満たす場合にのみ、ルックアップテーブルを更新してもよい。例えば、ルックアップテーブルは、（ｘ＆Ｍ＝＝０）＆＆（ｙ＆Ｍ＝＝０）の場合にのみ更新され、ここで、（ｘ，ｙ）は、符号化／復号化されたブロックの左上座標である。Ｍは、２、４、８、１６、３２、または６４などの整数である。
ｄ． 代替的に、１つのルックアップテーブルは、最大許容カウンタに達すると、更新を停止してもよい。
ｅ． 一例において、カウンタは予め規定されてもよい。代替的に、映像パラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ、タイルヘッダ、コーディングツリーユニット（ＣＴＵ）、コーディングツリーブロック（ＣＴＢ）、コーディングユニット（ＣＵ）または予測ユニット（ＰＵ）、複数のＣＴＵ／ＣＴＢ／ＣＵ／ＰＵをカバーする領域で信号通知される。

【0191】

例Ｂ６：ＬＵＴは、ブロックがマージまたはＡＭＶＰモードで符号化されるとき、ブロックに関連付けられた動き情報で更新されてもよい。

【0192】

例Ｂ７：コーディングされたブロックから得られた動き候補を加算してＬＵＴを更新する前に、プルーニングを適用してもよい。

【0193】

例Ｂ８：ＬＵＴは、定期的に更新されてもよい。

【0194】

例Ｃ：ＬＵＴにおける動き候補の並び替えを適用してもよい。
（ａ）一例において、１つのブロックをコーディングした後、このブロックから新しい動き候補を取得してもよい。それはまずＬＵＴに加えられ、次に再順序付けが適用されてもよい。この場合、サブシーケンスブロックのために、再配列されたＬＵＴを利用する。例えば、この並べ替えは、あるユニット（例えば、１つのＬＣＵ、１つのＬＣＵ行、複数のＬＣＵ等）のコーディングを終えた後に行われる。

【0195】

（ｂ）一例において、ＬＵＴにおける動き候補は、再配列されない。しかしながら、１つのブロックをコーディングする場合、まず動き候補の再配列を適用し、その後、チェックし、マージ／ＡＭＶＰまたは他の種類の動き情報候補リストに挿入することができる。

【0196】

例Ｄ：動きベクトル予測のための動き候補を有するＬＵＴの使用と同様に、１つまたは複数のＬＵＴを構築することができ、且つ／または更新して、以前コーディングされたブロックからのイントラ予測モードを記憶し、且つＬＵＴを使用してイントラコーディングされたブロックをコーディング／デコーディングしてもよい。

【0197】

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

【0198】

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

【0199】

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

【0200】

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

【0201】

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

【0202】

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

【0203】

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

【0204】

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

【0205】

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

【0206】

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

【0207】

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

【0208】

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

【0209】

同様に、ＨＭＶＰ候補は、ＡＭＶＰ候補リスト構築処理において使用されてもよい。ＴＭＶＰ候補の後に、テーブルにおける最後のＫ１個のＨＭＶＰ候補の動きベクトルを挿入する。ＡＭＶＰ対象参照ピクチャと同じ参照ピクチャを有するＨＭＶＰ候補のみを用いて、ＡＭＶＰ候補リストを構築する。ＨＭＶＰ候補に対してプルーニングを適用する。一例では、Ｋ１は４にセットされる。ＬＵＴに基づく予測方法のための符号化フローの例を図３６に示す。周期的な更新のコンテキストにおいて、更新処理は、領域を復号化した後に行われる。ＬＵＴを頻繁に更新することを回避するために、図３７に一例を示す。

【0210】

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

【0211】

図３８Ａは、例示的な映像処理方法のフローチャートを示す。方法３８１０は、ステップ３８１２でテーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられる。方法３８１０は、さらに、ステップ３８１４において、テーブルに基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、を含む。方法３８１０は、ステップ３８１６において、変換を行った後、更新規則に基づいて０個以上のテーブルを更新することをさらに含む。

【0212】

図３８Ｂは、例示的な映像処理方法の別のフローチャートを示す。方法３８２０は、ステップ３８２２でテーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられる。方法３８２０は、さらに、ステップ３８２４において、テーブルに基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、を含む。方法３８２０は、ステップ３８２６において、変換を行った後、映像における１つ以上の映像領域に基づいて、更新終了判定基準が満たされるまで、１つ以上のテーブルを更新することをさらに含む。

【0213】

図３８Ｃは、例示的な映像処理方法の別のフローチャートを示す。方法３８３０は、ステップ３８３２において、動き候補を含む１つ以上のテーブルを維持し、各動き候補は、対応する動き情報に関連付けられる。方法３８３０は、ステップ３８３４において、少なくとも１つのテーブルにおける動き候補を再配列することをさらに含む。方法３８３０は、ステップ３８３６において、１つ以上の再配列されたテーブルに基づいて、１つ以上のテーブルを使用して、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間の変換を行うことをさらに含む。

【0214】

図３８Ｄは、映像処理のための例示的な方法の別のフローチャートを示す。方法３８４０は、ステップ３８４２において、動き候補を含む１つ以上のテーブルを維持し、各動き候補は、対応する動き情報に関連付けられる。方法３８４０は、ステップ３８４４において、１つ以上の再配列されたテーブルに基づいて、１つ以上のテーブルを使用して、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことをさらに含む。方法３８４０は、ステップ３８４６において、第１の映像ブロックの変換およびテーブルにおける動き候補の並び替えに基づいて、テーブルに追加の動き候補を追加することで、１つ以上のテーブルを更新することをさらに含む。

【0215】

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

【0216】

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

【0217】

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

【0218】

１． テーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられ、テーブルに基づいて第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、変換を行った後に、更新規則に基づいて、ゼロ以上のテーブルを更新することを含む映像処理方法。

【0219】

２． 前記更新規則は、前記映像の１つのピクチャまたは１つのスライスまたは１つのタイルの境界に位置する映像ブロックのテーブルを更新することを許可しない、第１項に記載の方法。

【0220】

３． テーブルを維持することを含み、各テーブルは、動き候補のセットを含み、各動き候補は、対応する動き情報に関連付けられ、テーブルに基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、変換を行った後に、更新終了判定基準に達するまで、映像の中の１つ以上の映像領域に基づいて、１つ以上のテーブルを更新することを含む、映像処理方法。

【0221】

４． テーブルは、スライス、タイル、（最大符号化ユニット（ＬＣＵ）行、または同じ時間層インデックスを有するスライス内でのみテーブルを更新する、第１〜３項に記載の方法。

【0222】

５． Ｓ個の映像領域に対して変換を行った後、または一定のサイズの映像領域に対して変換を行った後、テーブルを更新し、Ｓは整数である、第１項または第３項に記載の方法。

【0223】

６． 更新中のテーブルに関連付けられたカウンタが最大許容数に達した場合、更新終了判定基準が満たされる、第３項に記載の方法。

【0224】

７． 更新中のテーブルに関連付けられたカウンタが予め規定された値に達した場合、更新終了判定基準が満たされる、第３項に記載の方法。

【0225】

８． 前記予め規定された値は、映像パラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ、タイルヘッダ、符号化ツリーユニット（ＣＴＵ）、符号化ツリーブロック（ＣＴＢ）、符号化ユニット（ＣＵ）、または予測ユニット（ＰＵ）、または複数のＣＴＵ、複数のＣＴＢ、複数のＣＵ、または複数のＰＵに広がる映像領域において信号通知される、第７項に記載の方法。

【0226】

９． 前記更新規則は、前記第１の映像ブロックの左上座標（ｘ，ｙ）が、前記更新規則に規定された一定の条件を満たす場合、テーブルを更新する、第１項または第３項に記載の方法。

【0227】

１０． （ｘ＆Ｍ＝＝０）＆＆（ｙ＆Ｍ＝＝０）の場合、テーブルが更新され、Ｍは、２、４、８、１６、３２、または６４である、第９項に記載の方法。

【0228】

１１． 前記更新規則は、Ｓ個の映像ブロックに対して変換を行った後、テーブルを更新し、Ｓが１以上の整数である、第１項または第３項に記載の方法。

【0229】

１２． Ｓ個の映像ブロックがインター符号化ブロックである、第１１項に記載の方法。

【0230】

１３． 前記Ｓ個の映像ブロックは、サブブロックに基づく動き予測またはサブブロックに基づく動き補償方法で符号化されない、第１１項に記載の方法。

【0231】

１４． 前記Ｓ個の映像ブロックは、アフィンモードまたは代替時間的動きベクトル予測（ＡＴＭＶＰ）モードで符号化されない、第１１項に記載の方法。

【0232】

１５． 動き候補を含む１つ以上のテーブルを維持することを含み、各動き候補は、対応する動き情報に関連付けられ、１つ以上のテーブルのうちの少なくとも１つにおいて動き候補の再配列をすることと、少なくとも１つのテーブルの再配列した動き候補に基づいて、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間で変換を行うことと、を含む。映像処理方法

【0233】

１６． 前記変換に基づいて、１つ以上のテーブルを更新することをさらに含む、第１５項に記載の方法。

【0234】

１７． 動き候補を含む１つ以上のテーブルを維持することを含み、各動き候補は、対応する動き情報に関連付けられ、１つ以上のテーブルに基づいて、少なくとも１つ以上のテーブルを使用して、第１の映像ブロックと、第１の映像ブロックを含む映像のビットストリーム表現との間の変換を行うことと、第１の映像ブロックの変換に基づいてテーブルに追加の動き候補を追加することによって１つ以上のテーブルを更新することと、テーブル内の動き候補を再配列することを含む、映像処理方法。

【0235】

１８． 前記順序変更されたテーブルに基づいて、前記映像の後続の映像ブロックと前記映像のビットストリーム表現との間で変換を行うことをさらに含む、第１５項または第１７項に記載の方法。

【0236】

１９． 前記再配列は、最大符号化ユニット（ＬＣＵ）、ＬＣＵ行、複数のＬＣＵのうちの少なくとも１つを含む映像ユニットに対して前記変換を行った後に行われる、第１７項に記載の方法。

【0237】

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

【0238】

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

【0239】

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

【0240】

２３． １つ以上のテーブルを更新することは、変換を行った後、第１の映像ブロックの動き情報に基づく１つ以上のテーブルを更新することを含む、第１〜１４項、および１６〜２２項のいずれか１項に記載の方法。

【0241】

２４． 更新されたテーブルに基づいて、映像の後続の映像ブロックとその映像のビットストリーム表現との間で変換を行うことをさらに含む、第２３項に記載の方法。

【0242】

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

【0243】

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

【0244】

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

【0245】

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

【0246】

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

【0247】

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

【0248】

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

【0249】

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

【0250】

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

【0251】

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

【0252】

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

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図7】

【図8A】

【図8B】

【図8C】

【図8D】

【図8E】

【図8F】

【図8G】

【図8H】

【図8I】

【図9A】

【図9B】

【図10】

【図11】

【図12A】

【図12B】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図17】

【図18A】

【図18B】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29A】

【図29B】

【図30】

【図31A】

【図31B】

【図32】

【図33】

【図34A】

【図34B】

【図35A】

【図35B】

【図36】

【図37】

【図38A】

【図38B】

【図38C】

【図38D】

【図39】

【手続補正書】

【提出日】2021年2月24日

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

映像データを符号化する方法であって、
既に符号化された１つ又は複数のテーブルを保持することであって、各テーブルは符号化された１つ以上の映像ブロックから導出した１つ以上の動き候補を含み、前記テーブル内の前記動き候補の配置は、前記テーブルへ前記動き候補を追加するシーケンスに基づく、保持することと、
現在の映像ブロックの動き候補リストを構築することと、
前記動き候補リストを使用して、前記現在の映像ブロックの動き情報を判定することと、
前記判定された動き情報に基づいて前記現在の映像ブロックを符号化することと、を含み、
前記判定された動き情報が前記１つ又は複数のテーブルのうちの１つのテーブルを更新するために使用されるかどうかは、前記現在の映像ブロックの符号化された情報に基づいており、前記更新されたテーブルは、サブシーケンス映像ブロックの動き候補リストを構築するために使用される、方法。

【請求項2】

前記符号化された情報は、前記現在の映像ブロックの符号化モード、前記現在の映像ブロックの位置、又は前記現在の映像ブロックのサイズのうちの少なくとも１つを含む、請求項１に記載の方法。

【請求項3】

少なくとも１つの条件が満たされている場合、前記判定された動き情報を使用して前記１つ又は複数のテーブルのうちの１つのテーブルを更新するか、又は少なくとも１つの条件が満たされていない場合、前記判定された動き情報を使用しないで、前記１つ又は複数のテーブルのうちの１つのテーブルを更新し、前記少なくとも１つの条件は前記符号化された情報に基づく、請求項１に記載の方法。

【請求項4】

前記少なくとも１つの条件は、
少なくとも１つの特定モードに属する前記現在の映像ブロックの符号化モードと、
サイズ要件を満たす前記現在の映像ブロックのサイズを含む、請求項３に記載の方法。

【請求項5】

前記少なくとも１つの特定モードは、イントラブロックコピー（ＩＢＣ）モード又はインター符号化モードのうちの少なくとも１つを含む、請求項４に記載の方法。

【請求項6】

前記少なくとも１つの特定のモードは、サブブロックに基づくインター符号化モードを除外する、請求項４に記載の方法。

【請求項7】

前記サブブロックに基づくインター符号化モードは、アフィンモード又は代替時間的動きベクトル予測（ＡＴＭＶＰ）モードのうちの少なくとも１つを含む、請求項６に記載の方法。

【請求項8】

前記映像ブロックの前記位置は、前記現在の映像ブロックの左上座標（ｘ，ｙ）を含む、請求項２に記載の方法。

【請求項9】

前記符号化された情報は、前記テーブルを使用して前記動き候補リストを構築するかどうかを含む、請求項１に記載の方法。

【請求項10】

前記決定された動き情報を使用して前記１つ又は複数のテーブルのうちの１つのテーブルを更新する場合、更新されるべき前記テーブルは、前記現在の映像ブロックの前記動き候補リストを構築するためにどのテーブルを使っているか、前記現在の映像ブロックの位置、前記現在の映像ブロックを含む符号化ツリーユニット（ＣＴＵ）の位置に基づいて選択され、又は、前記判定された動き情報を使用して前記１つ又は複数のテーブルのうちの１つのテーブルを更新する場合、前記更新されるべきテーブルは、前記現在の映像ブロックの前記動き候補リストを構築するために使用するものと同じである、請求項１に記載の方法。

【請求項11】

前記判定された動き情報が前記１つ又は複数のテーブルのうちの１つのテーブルを更新するために使用される場合、前記テーブルは、前記現在の映像ブロックから導出された動き情報を前記テーブルに加えることで更新される、請求項１に記載の方法。

【請求項12】

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

【請求項13】

前記テーブルを使用して前記動き候補リストを構成することは、
動き候補リストの構築時に、前記テーブルにおける１つ以上の候補を確認すること含む、請求項１に記載の方法。

【請求項14】

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

【請求項15】

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

【請求項16】

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

【請求項17】

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

【国際調査報告】