特表 2021-530941 イントラ予測モードを有するルックアップテーブルおよび非隣接ブロックからのイントラモード予測

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

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

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

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

(54)【発明の名称】イントラ予測モードを有するルックアップテーブルおよび非隣接ブロックからのイントラモード予測

(51)【国際特許分類】

   H04N 19/11 20140101AFI20211015BHJP

   H04N 19/70 20140101ALI20211015BHJP

   H04N 19/176 20140101ALI20211015BHJP

【ＦＩ】

   H04N19/11

   H04N19/70

   H04N19/176

【審査請求】有

【予備審査請求】未請求

【全頁数】73

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

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

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

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

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

(87)【国際公開日】20200109

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

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

(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

【Ｆターム（参考）】

5C159MA04

5C159MA21

5C159MC11

5C159ME01

5C159PP04

5C159RC12

5C159TA31

5C159TB08

5C159TC41

5C159TC42

5C159TC43

5C159TD07

5C159TD10

5C159TD15

5C159UA02

5C159UA05

5C159UA31

(57)【要約】

デジタル映像を符号化および復号化するためのデバイス、システム、および方法が記載される。代表的な態様において、映像処理方法は、映像の１つ以上の以前の映像ブロックに基づいて、イントラ予測モード候補の１つ以上のテーブルを維持することと、１つまたは複数のイントラ予測モード候補の１つ以上のテーブルを使用して、映像の現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことと、を含む。
【選択図】図４５

【特許請求の範囲】

【請求項1】

映像処理方法であって、
映像の１つまたは複数の前の映像ブロックに基づいて、イントラ予測モード候補の１つ以上のテーブルを維持することと、
イントラ予測モード候補の前記１つ以上のテーブルを使用して、前記映像の現在の映像ブロックと前記映像のビットストリーム表現との間で変換を行うことと、を含む、方法。

【請求項2】

イントラ予測モード候補の前記１つ以上のテーブルにおける、各テーブルのサイズは同一である、請求項１に記載の方法。

【請求項3】

各テーブルの前記サイズが、前記イントラ予測モード候補のサポートされるタイプの総数に等しい、請求項２に記載の方法。

【請求項4】

カウンタを、各タイプの前記イントラ予測モード候補に割り当てることをさらに含み、前記カウンタは、以前符号化されたブロックにおいて前記対応するタイプが使用された回数を示す、請求項１〜３のいずれか１項に記載の方法。

【請求項5】

前記１つ以上のテーブルのうちの１つが前記対応するタイプのイントラ予測モード候補に更新された場合、前記カウンタを変更することを含む、請求項４に記載の方法。

【請求項6】

前記現在の映像ブロックに基づいてイントラ予測モード候補の前記１つ以上のテーブルを更新することを含む、請求項１〜５のいずれか１項に記載の方法。

【請求項7】

前記更新されたイントラ予測モード候補の１つ以上のテーブルを使用して、前記映像の後続の映像ブロックと前記映像の前記ビットストリーム表現との間で第２の変換を行うことをさらに含む、請求項６に記載の方法。

【請求項8】

映像処理方法であって、
映像の映像ブロックの非隣接ブロックのイントラ予測モードに基づいて、イントラ予測モード予測子のセットを決定することと、
前記イントラ予測モード予測子のセットを使用して、前記映像ブロックと前記映像の前記ビットストリーム表現との間で変換を行うことと、を含む、方法。

【請求項9】

予測モード候補の前記１つ以上のテーブルまたは前記非隣接ブロックの前記イントラ予測モードのうちの少なくとも１つに基づいて、最大確率モード（ＭＰＭ）リストを構築することを含む、請求項１〜８のいずれかに記載の方法。

【請求項10】

予測モード候補の１つ以上のテーブルまたは前記非隣接ブロックの前記イントラ予測モードの前記２つのうちの前記少なくとも１つに基づく、非最大確率モード（ＭＰＭ）イントラ予測モードの再配列することをさらに含む、請求項９に記載の方法。

【請求項11】

処理装置と、命令を搭載した非一時的メモリとを備え、前記処理装置が実行すると、前記命令は、前記処理装置に、請求項１〜１０のいずれか１つ以上に記載の前記方法を実装させる、映像システムにおける装置。

【請求項12】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

この特許文献は、映像符号化技術、デバイスおよびシステムに関する。

【背景技術】

【0003】

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

【発明の概要】

【0004】

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

【0005】

１つの代表的な態様において、開示される技術を使用して映像処理の方法を提供することができる。この方法は、映像の映像データの第１のブロックとこの映像のビットストリーム表現との間で変換を行うことと、映像データの第１のブロックの符号化特性に基づいて、第１のブロックに関連付けられた動き情報を使用して動き候補のテーブルを更新することとを含む。

【0006】

別の代表的な態様において、開示される技術は、映像を処理する方法を提供するために使用できる。この方法は、現在の映像ブロックと映像のビットストリーム表現との間での変換中に、動き候補の１つ以上のテーブルを維持することと、現在の映像ブロックに関連付けられた動き候補と、１つ以上のテーブルにおけるエントリの数とを比較することと、この比較に基づいて、この１つ以上のテーブルを更新することと、を含む。

【0007】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、映像の映像ブロックと映像のビットストリーム表現との間の変換を行うことと、変換における動き候補の１つ以上のテーブルを維持することと、映像ブロックにおける現在の映像ブロックの符号化特性に基づいて、現在の映像ブロックと映像のビットストリーム表現との間で変換を行うための動き候補の１つ以上のテーブルを用いる適合性を決定することと、適合性に基づいて、現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことと、現在の映像ブロックに関連付けられた動き候補を使用して、動き候補の１つ以上のテーブルを選択的に更新することを含む。

【0008】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、現在の映像ブロックと現在の映像ブロックを含む映像のビットストリーム表現との間での変換中に、動き候補の１つ以上のテーブルを維持することと、現在の映像ブロックがマージモードまたは高度動きベクトル予測（ＡＭＶＰ）モードを使用して符号化されていると決定することと、この決定に基づいて、１つ以上の動き候補のテーブルを使用して、現在の映像ブロックと映像のビットストリーム表現との間で変換を行うこととを含む。

【0009】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、動き候補１つ以上のテーブルと、１つ以上の非隣接ブロックからの非隣接候補のセットとを組み合わせることによって、１つの映像データのブロックにおける動き候補のリストを決定することを含む。この方法は、動き候補のリストを使用して、映像データのブロックと映像のビットストリーム表現との間で変換を行うことも含む。

【0010】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、複数の利用可能な動きベクトル精度から選択されたＭ−画素またはサブ画素の動きベクトル精度を有する映像の映像ブロックと映像のビットストリーム表現との間での変換のための高度動きベクトル予測（ＡＭＶＰ）候補リストを維持することを含む。Ｍは正の整数である。この方法は、映像ブロックに関連付けられた各利用可能な高度動きベクトル予測（ＡＭＶＰ）候補に対して、ＡＭＶＰ候補を丸めることと、丸められたＡＭＶＰ候補をＡＭＶＰ候補リストにおける既存の候補と比較することと、丸められたＡＭＶＰ候補が既存の候補と異なると決定することと、ＡＭＶＰ候補をＡＭＶＰ候補リストに追加することと、を行うことを含む。この方法は、ＡＭＶＰ候補リストと動き候補の１つ以上のテーブルからの１つ以上の動き候補とを組み合わせて、組み合わせリストを取得することと、この組み合わせリストに基づいて変換を行うことも含む。

【0011】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、複数の利用可能な動きベクトル精度から選択されたＭ−画素またはサブ画素の動きベクトル精度を有する映像の映像ブロックと映像のビットストリーム表現との間での変換のための高度動きベクトル予測（ＡＭＶＰ）候補リストを維持することを含み、Ｍは、正の整数である。この方法は、また、映像ブロックに関連付けられたＡＭＶＰ候補とＡＭＶＰ候補リストにおける既存のＡＭＶＰ候補とを比較することと、ＡＭＶＰ候補が既存の候補と異なると決定されると、ＡＭＶＰ候補をＡＭＶＰ候補リストに追加することと、ＡＭＶＰ候補リストに基づいて変換を行うことと、を含む。

【0012】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、マージインデックスを使用して、映像の映像データのブロックと映像のビットストリーム表現との間で変換を行うことを含む。このビットストリーム表現は、変換のためのマージ候補を示すマージインデックスを備える。マージインデックスは、第１の部分と第２の部分とに分割される。第１の部分は第１の２値化法を使用してコーディングされ、第２の部分は第１の２値化法とは異なる第２の２値化法を使用してコーディングされる。

【0013】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、映像の１つ以上の前の映像ブロックに基づいて、イントラ予測モード候補の１つ以上のテーブルを維持することと、１つ以上のイントラ予測モード候補のテーブルを使用して、映像の現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことと、を含む。

【0014】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、映像の映像ブロックの非隣接ブロックのイントラ予測モードに基づいて、イントラ予測モード予測子のセットを決定することと、このイントラ予測モード予測子のセットを使用して、映像ブロックと映像のビットストリーム表現との間で変換を行うことと、を含む。

【0015】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、映像の１つ以上の前の映像ブロックに基づいて、照明補償（ＩＣ）パラメータの１つ以上のテーブルを維持することと、１つ以上のＩＣパラメータのテーブルを使用して、映像の現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことと、を含む。

【0016】

別の代表的な態様において、開示される技術は、映像処理の方法を提供するために使用できる。この方法は、現在の映像ブロックの非隣接ブロックのＩＣパラメータに基づいて、映像の現在の映像ブロックの照明補償（ＩＣ）パラメータを導出することと、導出されたＩＣパラメータを使用して、現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことと、を含む。

【0017】

別の代表的な態様において、開示される技術は、映像符号化の方法を提供するために使用してもよい。この方法は、映像データの第１のブロックのビットストリーム表現を受信することと、ルックアップテーブル（ＬＵＴ）のセットに基づいてこのビットストリーム表現を処理することと、映像データの第１のブロックを生成することと、を含み、このＬＵＴのセットは、符号化候補を含む。

【0018】

別の代表的な態様において、開示される技術は、映像符号化の別の方法を提供するために使用してもよい。この方法は、映像データのブロックのビットストリーム表現を受信することと、非隣接ブロックからのコーディング候補に基づいて、ビットストリーム表現を処理することと、を含み、コーディング候補は、非動き候補である。

【0019】

さらに別の代表的な態様において、開示される技術は、映像符号化の別の方法を提供するために使用してもよい。この方法は、映像データのブロックのビットストリーム表現を受信することと、複数の動きベクトル（ＭＶ）精度を使用して、そして、高度動きベクトル予測（ＡＭＶＰ）候補リストに基づいて、映像データのブロックを生成するためのビットストリーム表現を処理することと、を含み、この映像データのブロックは、ＭＶ精度が低く、各ＡＭＶＰ候補が、ＡＭＶＰ候補リストへの挿入される前に利用可能なＡＭＶ候補で丸められ、プルーニングされる。

【0020】

さらに別の代表的な態様において、開示される技術は、映像符号化の別の方法を提供するために使用してもよい。この方法は、映像データのブロックのビットストリーム表現を受信することと、マージインデックスコーディングを使用してこのビットストリーム表現を処理してこの映像データのブロックを生成することとを含み、このビットストリーム表現は、第１の部分と第２の部分とに分割されるマージインデックスを含み、第１の部分は第１の２値化法によって処理され、第２の部分は第１の２値化法とは異なる第２の２値化法によって処理される。

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【図面の簡単な説明】

【0025】

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

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

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

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

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

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

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

【図6A】４分木（ＱＴ）の分割の例を示す。

【図6B】垂直２分木（ＢＴ）の分割の例を示す。

【図6C】水平２分木（ＢＴ）の分割の例を示す。

【図6D】垂直３分木（ＴＴ）の分割の例を示す。

【図6E】水平３分木（ＴＴ）の分割の例を示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図30】非隣接ブロックおよびルックアップテーブル（ＬＵＴ）からの候補を繰り返し挿入する例を示す。

【図31】非隣接ブロックおよびＬＵＴからの候補を優先的に挿入する例を示す。

【図32】非隣接ブロックおよびＬＵＴからの候補を優先的に挿入する他の例を示す。

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

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

【図35】本開示の技術による映像符号化のための例示的な方法のフローチャートを示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【表2】

【0086】

【表3】

【0087】

【表4】

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

【数1】

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

【数2】

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

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

【0136】

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

【0137】

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

【0138】

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

【0139】

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

【0140】

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

【0141】

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

【0142】

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

【0143】

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

【0144】

【表5】

【0145】

【表6】

【0146】

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

【0147】

【表7】

【0148】

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

【0149】

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

【0150】

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

【0151】

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

【0152】

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

【0153】

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

【0154】

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

【0155】

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

【0156】

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

【0157】

【表8】

【0158】

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

【0159】

【表9】

【0160】

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

【0161】

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

【0162】

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

【0163】

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

【0164】

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

【0165】

５つの近傍のイントラ予測モードを使用してＭＰＭリストを形成する。５つの近傍のブロックの位置は、マージモードで使用される位置と同じであり、即ち、図２８に示すように、左（Ｌ）、上（Ａ）、下−左（ＢＬ）、上−右（ＡＲ）、および上−左（ＡＬ）である。最初のＭＰＭリストは、５つの隣接するイントラモードおよびプレーナおよびＤＣモードをＭＰＭリストに挿入することで形成される。プルーニング処理を使用して、重複したモードを除去し、唯一のモードをＭＰＭリストに含めることができる。初期モードが含まれる順番は、左、上、平面、ＤＣ、左下、右上、左上である。例えば、プルーニングは、（ａ）既存のエントリと一意性を比較することと、（ｂ）一意である場合、リストに追加することと、（ｃ）一意でない場合、（ｃ１）追加しない、または（ｃ２）合致した既存のエントリを追加して削除することの操作を含んでもよく、追加後、エントリの数が増加しない。

【0166】

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

【0167】

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

【0168】

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

【0169】

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

【0170】

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

【0171】

【表10】

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

【表11】

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

いくつかの実施形態において、前記チェックすることは、前記非隣接候補のセットから非隣接候補をチェックし、前記非隣接候補に関連付けられた非隣接ブロックの符号化特性に基づいて、前記非隣接候補と前記動き候補の１つ以上のテーブルからの動き候補とを置換することを含む。いくつかの実施形態において、前記非隣接ブロックの符号化特性は、前記非隣接ブロックが予め規定された範囲外に位置することを示す。予め規定された範囲は、最大の符号化ユニットの現在の行を含むことができる。いくつかの実施形態において、前記非隣接ブロックの符号化特性は前記非隣接ブロックがイントラ符号化されるかあるいはイントラブロックコピー符号化されることを示す。

【0253】

いくつかの実施形態において、前記非隣接候補のセットは前記動き候補の１つ以上のテーブルよりも高い優先順位を有する。この結合は、動き候補のテーブルのセットをチェックする前に、非隣接候補のセットからすべての候補をチェックすることを含むことができる。いくつかの実施形態において、動き候補の１つ以上のテーブルは、非隣接候補のセットよりも高い優先順位を有する。この結合は、非隣接候補のセットをチェックする前に、動き候補のテーブルのセットからすべての候補をチェックすることを含むことができる。

【0254】

いくつかの実施形態において、前記動き候補のリストは、特定された動き予測方法により生成された候補をさらに結合することにより得られる。特定動き予測方法は、時間的動きベクトル予測子（ＴＭＶＰ）法を含んでもよい。

【0255】

いくつかの実施形態において、動き候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む動き情報に関連付けられる。いくつかの実施形態において、動き候補のリストは、マージ符号化されたブロックに用いられる複数のマージ候補を含む。いくつかの実施形態において、動き候補のリストは、イントラ符号化されたブロックに用いられるイントラ予測モードを含む。いくつかの実施形態において、動き候補のリストは、ＩＣ符号化されたブロックに用いられる複数の照明補償（ＩＣ）パラメータを含む。いくつかの実施形態において、動き候補のリストは、選別過程で用いられる選別パラメータを含む。

【0256】

いくつかの実施形態において、前記映像データのブロックはマージモードを利用して符号化され、前記非隣接候補のセットは複数のマージ候補を含む。いくつかの実施形態において、映像データのブロックは、高度動きベクトル予測（ＡＭＶＰ）モードを利用して符号化され、非隣接候補のセットは、複数のＡＭＶＰ候補を含む。

【0257】

図４２は、本開示の技術による映像処理のための例示的な方法４２００のフローチャートである。方法４２００は、操作４２０２において、複数の利用可能な動きベクトル精度から選択されたＭ−画素またはサブ画素の動きベクトル精度で、映像の映像ブロックと映像のビットストリーム表現との間での変換のための高度動きベクトル予測（ＡＭＶＰ）候補リストを維持することを含む。Ｍは正の整数である。方法４２００は、操作４２０４において、映像ブロックに関連付けられたそれぞれの利用可能な高度動きベクトル予測（ＡＭＶＰ）候補について、ＡＭＶＰ候補を丸めることを行い、丸められたＡＭＶＰ候補をＡＭＶＰ候補リストにおける既存の候補と比較することと、丸められたＡＭＶＰ候補が既存の候補と異なると決定されると、ＡＭＶＰ候補をＡＭＶＰ候補リストに加えることと、を含む。方法４２００は、操作４２０６において、ＡＭＶＰ候補リストと動き候補の１つ以上のテーブルからの動き候補を結合し、結合リストを得ることを含む。方法４２００は、操作４２０８において、結合リストに基づいて変換を行うことも含む。

【0258】

いくつかの実施形態において、各利用可能なＡＭＶＰ候補は、映像ブロックの空間的または時間的に近傍のブロックから導出される。いくつかの実施形態において、前記結合は、ＡＭＶＰ候補リストにおける複数の候補が予め規定された閾値より小さい場合に行われる。

【0259】

いくつかの実施形態において、前記方法は、前記結合する前に１つ以上の動き候補の各々を丸めることを含む。いくつかの実施形態において、前記結合することは、１つ以上の動き候補の各々に対して、ＡＭＶＰ候補リストにおける既存のＡＭＶＰ候補と動き候補を比較し、動き候補が既存のＡＭＶＰ候補と異なると決定されると、前記動き候補を前記結合リストに加えることを含む。

【0260】

いくつかの実施形態において、動き候補は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも１つを含む動き情報に関連付けられる。いくつかの実施形態において、前記動き候補は、マージコーディングされたブロックに用いられる複数のマージ候補を含む。いくつかの実施形態において、動き候補は、イントラコーディングされたブロックに用いられるイントラ予測モードを含む。いくつかの実施形態において、前記動き候補は、ＩＣコーディングされたブロックに用いられる複数の照明補償（ＩＣ）パラメータを含む。いくつかの実施形態において、前記動き候補は前記フィルタリング過程に用いられるフィルタパラメータを含む。いくつかの実施形態において、前記方法は、前記変換を行った後、前記映像ブロックの動き情報により１つ以上のテーブルを更新することを含む。いくつかの実施形態において、この方法は、さらに、更新されたテーブルに基づいて、映像の後続の映像ブロックと映像のビットストリーム表現との間で変換を行うことを含む。

【0261】

図４３は、本開示の技術による映像処理のための例示的な方法４３００のフローチャートである。方法４３００は、操作４３０２において、複数の利用可能な動きベクトル精度から選択されたＭ−画素または画素の動きベクトル精度で、映像の映像ブロックと映像のビットストリーム表現との間で変換するための高度動きベクトル予測（ＡＭＶＰ）候補リストを維持することを含む。Ｍは正の整数である。方法４３００は、操作４３０４において、映像ブロックに関連付けられたＡＭＶＰ候補と、ＡＭＶＰ候補リストにおける既存のＡＭＶＰ候補とを比較することを含む。方法４３００は、操作４３０６において、ＡＭＶＰ候補が既存の候補と異なると決定されると、ＡＭＶＰ候補をＡＭＶＰ候補リストに加えることを含む。方法４３００は、操作４３０８において、ＡＭＶＰ候補リストに基づいて変換を行うことをさらに含む。

【0262】

いくつかの実施形態において、前記方法は、ＡＭＶＰ候補と既存のＡＭＶＰ候補とを比較する前に、ＡＭＶＰ候補を丸めることを含む。いくつかの実施形態において、前記方法は、ＡＭＶＰ候補を前記リストに加えた後、ＡＭＶＰ候補リストにおけるすべての候補を丸めることを含む。いくつかの実施形態において、この方法は、ＡＭＶＰ候補リストにおけるすべての候補をプルーニングして、重複したエントリを削除することを含む。

【0263】

図４４は、本開示の技術による映像処理のための例示的な方法４４００のフローチャートである。方法４４００は、操作４４０２において、マージインデックスを使用して、映像の映像データのブロックと映像のビットストリーム表現との間で変換を行うことを含む。このビットストリーム表現は、変換のためのマージ候補を示すマージインデックスを備える。マージインデックスは、第１の部分と第２の部分とに分割される。第１の部分は第１の２値化法を使用してコーディングされ、第２の部分は第１の２値化法とは異なる第２の２値化法を使用してコーディングされる。

【0264】

いくつかの実施形態において、第１の２値化法は単項２値化法である。いくつかの実施形態において、第２の２値化法は固定長（ＦＬ）２値化法である。代替的に、第２の２値化法は、ｋ次のＥｘｐ−Ｇｏｌｏｍｂ（ＥＧｋ）２値化法であってもよい。いくつかの実施形態において、マージインデックスは予め規定されたまたは信号通知された閾値より大きいので、マージインデックスを第１の部分と第２の部分に分ける。

【0265】

図４５は、本開示の技術による映像処理のための例示的な方法４５００のフローチャートである。方法４５００は、操作４５０２において、映像の１つまたは複数の前の映像ブロックに基づいて、イントラ予測モード候補の１つ以上のテーブルを維持することを含む。方法４５００は、操作４５０４において、イントラ予測モード候補の１つ以上のテーブルを使用して、映像の現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことを含む。

【0266】

いくつかの実施形態において、イントラ予測モード候補の１つ以上のテーブルにおける各テーブルのサイズは同一である。いくつかの実施形態において、各テーブルのサイズはイントラ予測モード候補のサポートされるタイプの総数に等しい。

【0267】

いくつかの実施形態において、前記方法は、各タイプのイントラ予測モード候補にカウンタを割り当てることを含む。カウンタは、以前符号化されたブロックにおいて対応するタイプが使用された回数を示す。いくつかの実施形態において、前記方法は、１つ以上のテーブルのうちの１つが対応するタイプのイントラ予測モード候補に更新された場合、カウンタを変更することを含む。

【0268】

いくつかの実施形態において、前記方法は、現在の映像ブロックに基づいてイントラ予測モード候補の１つ以上のテーブルを更新することを含む。いくつかの実施形態において、前記方法は、更新されたイントラ予測モード候補の１つ以上のテーブルを使用して、前記映像の後続の映像ブロックと前記映像のビットストリーム表現との間で第２変換を行うことを更に含む。

【0269】

図４６は、本開示の技術による映像処理のための例示的な方法４６００のフローチャートである。方法４６００は、操作４６０２において、映像の映像ブロックの非隣接ブロックのイントラ予測モードに基づいて、イントラ予測モード予測子のセットを決定することを含む。方法４６００は、操作４６０４において、イントラ予測モード予測子のセットを使用して、映像ブロックと映像のビットストリーム表現との間で変換を行うことを含む。

【0270】

いくつかの実施形態において、上記方法４５００および４６００は、予測モード候補の１つ以上のテーブルまたは非隣接ブロックのイントラ予測モードのうちの少なくとも１つに基づいて、最大確率モード（ＭＰＭ）リストを構築することを含む。いくつかの実施形態において、前記方法は、予測モード候補のテーブルまたは前記非隣接ブロックのイントラ予測モードのうち１つ以上のテーブルに基づいて、非最大確率モード（ＭＰＭ）イントラ予測モードを再配列することを含む。

【0271】

図４７は、本開示の技術による映像処理のための例示的な方法４７００のフローチャートである。方法４７００は、操作４７０２において、映像の１つ以上の以前の映像ブロックに基づいて、１つまたは複数の照明補償（ＩＣ）パラメータの１つ以上のテーブルを維持することを含む。方法４７００は、操作４７０２において、ＩＣパラメータの１つ以上のテーブルを使用して、映像の現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことを含む。

【0272】

いくつかの実施形態において、現在の映像ブロックはＩＣ符号化される。いくつかの実施形態において、前記方法は、映像データの符号化領域の変換を行う前に、前記ＩＣパラメータの１つ以上のテーブルを初期化することを含む。符号化領域は、ピクチャ、スライス、または最大の符号化ユニット行を含んでもよい。

【0273】

いくつかの実施形態において、前記方法は、現在の映像ブロックのＩＣパラメータに基づいて前記ＩＣパラメータの１つ以上のテーブルを更新することを含む。いくつかの実施形態において、この方法は、複数のＩＣパラメータの更新された１つ以上のテーブルを使用して、映像の後続の映像ブロックと映像のビットストリーム表現との間で第２の変換を行うことを含む。後続の映像データのブロックは、照明補償ＩＣ符号化されてもよい。

【0274】

図４８は、本開示の技術による映像処理のための例示的な方法４８００のフローチャートである。方法４８００は、操作４８０２において、現在の映像ブロックの非隣接ブロックのＩＣパラメータに基づいて、映像の現在の映像ブロックの照明補償（ＩＣ）パラメータを導出することを含む。方法４８００は、操作４８０４において、導出されたＩＣパラメータを使用して、現在の映像ブロックと映像のビットストリーム表現との間で変換を行うことを含む。

【0275】

いくつかの実施形態において、上記方法４７００および４８００は、各ＩＣ候補が対応するＩＣパラメータに関連付けられるＩＣ候補のリストを構築することを含む。ＩＣ候補にインデックスを割り当てることができる。ビットストリーム表現における映像ブロックのために、ＩＣ候補のインデックスを信号通知することができる。

【0276】

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

【0277】

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

【0278】

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

【0279】

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

【0280】

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

【0281】

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

【0282】

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

【0283】

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

【0284】

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

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図7】

【図8A】

【図8B】

【図8C】

【図8D】

【図8E】

【図8F】

【図8G】

【図8H】

【図8I】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29A】

【図29B】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【手続補正書】

【提出日】2021年2月5日

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

映像データを符号化する方法であって、
１つ以上のテーブルを、映像の１つ以上の以前の映像ブロックに基づいて維持すること、ここで、各テーブルは、その各々が１つのイントラ予測モードに対応するイントラ予測モード候補を含み、
前記１つ以上のテーブルを使用して、前記映像の現在の映像ブロックと前記映像のビットストリーム表現の間で変換を行うこと、を含む方法。

【請求項2】

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

【請求項3】

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

【請求項4】

各テーブルのサイズが、イントラ予測モードのサポートされるタイプの総数に等しい、請求項１に記載の方法。

【請求項5】

前記イントラ予測モード候補は、以前符号化された映像ブロックにおいて前記対応するイントラ予測モードが使用された回数を示す変数を含む、請求項１に記載の方法。

【請求項6】

前記１つ以上のテーブルのうちの１つのテーブルが、前記対応するイントラ予測モードに基づいて更新される場合、前記イントラ予測モード候補の前記変数が修正される、請求項５に記載の方法。

【請求項7】

前記現在の映像ブロックの前記イントラ予測モードに基づいて、前記１つ以上のテーブルを更新することを含む、請求項１に記載の方法。

【請求項8】

前記更新された１つ以上のテーブルを使用して、前記映像の後続の映像ブロックと、前記映像の前記ビットストリーム表現との間で第２の変換を行うことをさらに含む、請求項７に記載の方法。

【請求項9】

前記変換を行うことは、
前記１つ以上のテーブルに基づいて前記現在の映像ブロックのイントラ予測モードを決定することと、
前記決定したイントラ予測モードに基づいて前記変換を行うことと、を含む、請求項１に記載の方法。

【請求項10】

前記変換を行うことは、
前記１つ以上のテーブルに基づいて候補リストを構築することと、
前記候補リストに基づいて前記変換を行うことと、を含む、請求項１に記載の方法。

【請求項11】

前記候補リストは、最大確率モード（ＭＰＭ）リストである、請求項１０に記載の方法。

【請求項12】

前記変換を行うことは、
非最大確率モード（ＭＰＭ）イントラ予測モードを前記１つ以上のテーブルのイントラ予測モード候補に基づいて再配列することと、
前記再配列されたＭＰＭイントラ予測モードに基づいて前記変換を行うことと、を含む、請求項１に記載の方法。

【請求項13】

前記１つ以上の以前の映像ブロックは、前記現在の映像ブロックの隣接していない映像ブロックを含む、請求項１に記載の方法。

【請求項14】

前記より多くのテーブルの各テーブルのサイズが同一である、請求項１に記載の方法。

【請求項15】

処理装置と、命令が記憶された非一時的メモリとを備える、映像データを処理する装置であって、
前記命令が前記処理装置によって実行されると、前記処理装置に、
１つ以上のテーブルを、映像の１つ以上の以前の映像ブロックに基づいて維持すること、ここで、各テーブルは、その各々が１つのイントラ予測モードに対応するイントラ予測モード候補を含み、
前記１つ以上のテーブルを使用して、前記映像の現在の映像ブロックと前記映像のビットストリーム表現の間で変換を行うこと、を行わせる装置。

【請求項16】

処理装置に次のことを実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体であって、
前記命令は、前記処理装置に、
１つ以上のテーブルを、映像の１つ以上の以前の映像ブロックに基づいて維持すること、ここで、各テーブルは、その各々が１つのイントラ予測モードに対応するイントラ予測モード候補を含み、
前記１つ以上のテーブルを使用して、前記映像の現在の映像ブロックと前記映像のビットストリーム表現の間で変換を行うこと、を行わせる、非一時的なコンピュータ可読記憶媒体。

【請求項17】

映像処理装置で行われる方法で生成されたビットストリーム表現を記憶する非一時的なコンピュータ可読記録媒体であって、
前記方法は、
１つ以上のテーブルを、映像の１つ以上の以前の映像ブロックに基づいて維持すること、ここで、各テーブルは、その各々が１つのイントラ予測モードに対応するイントラ予測モード候補を含み、
前記１つ以上のテーブルを使用して、前記現在の映像ブロックから前記ビットストリーム表現を生成すること、を含む、非一時的なコンピュータ可読記録媒体。

【国際調査報告】