(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-15
(45)【発行日】2024-10-23
(54)【発明の名称】LUT更新の起動
(51)【国際特許分類】
H04N 19/52 20140101AFI20241016BHJP
H04N 19/105 20140101ALI20241016BHJP
H04N 19/157 20140101ALI20241016BHJP
H04N 19/176 20140101ALI20241016BHJP
H04N 19/58 20140101ALI20241016BHJP
【FI】
H04N19/52
H04N19/105
H04N19/157
H04N19/176
H04N19/58
【外国語出願】
(21)【出願番号】P 2023072498
(22)【出願日】2023-04-26
(62)【分割の表示】P 2021539078の分割
【原出願日】2020-01-10
【審査請求日】2023-04-28
(31)【優先権主張番号】PCT/CN2019/071214
(32)【優先日】2019-01-10
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】520476341
【氏名又は名称】北京字節跳動網絡技術有限公司
【氏名又は名称原語表記】Beijing Bytedance Network Technology Co., Ltd.
【住所又は居所原語表記】Room B-0035, 2/F, No.3 Building, No.30, Shixing Road, Shijingshan District Beijing 100041 China
(73)【特許権者】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】BYTEDANCE INC.
【住所又は居所原語表記】12655 West Jefferson Boulevard, Sixth Floor, Suite No. 137 Los Angeles, California 90066 United States of America
(74)【代理人】
【識別番号】110002000
【氏名又は名称】弁理士法人栄光事務所
(72)【発明者】
【氏名】ジャン リー
(72)【発明者】
【氏名】ジャン カイ
(72)【発明者】
【氏名】リウ ホンビン
(72)【発明者】
【氏名】ワン ユエ
【審査官】田中 純一
(56)【参考文献】
【文献】特表2022-507683(JP,A)
【文献】米国特許出願公開第2020/0169748(US,A1)
【文献】米国特許出願公開第2018/0192071(US,A1)
【文献】Jianle Chen, et al.,Algorithm description for Versatile Video Coding and Test Model 3 (VTM 3) [online], JVET-L JVET-L1002-v1,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L1002-v2.zip><JVET-L1002-v2.docx>,2018年12月24日,pp.1-48
【文献】Li Zhang, et al.,CE4-related: History-based Motion Vector Prediction [online], JVET-K JVET-K0104-v5,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/11_Ljubljana/wg11/JVET-K0104-v5.zip><JVET-K0104_r4.docx>,2018年07月18日,pp.1-7
【文献】Li Zhang, et al.,CE4: History-based Motion Vector Prediction (Test 4.4.7) [online], JVET-L JVET-L0266-v2,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L0266-v3.zip><JVET-L0266_r1.docx>,2018年10月04日,pp.1-6
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00 - 19/98
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
映像処理の方法であって、
1以上の動き候補テーブルを維持することであって、各動き候補テーブルは、1以上の動き候補を有し、少なくとも1つの動き候補テーブルは、少なくとも1つの前の映像ブロックから導出され、前記動き候補テーブルにおける前記動き候補の配置は、前記動き候補テーブルへの前記動き候補の追加の順序に基づく、ことと、
第1の映像ブロックに対する動き候補リストを導出するための動き候補リスト導出処理を実行することと、
前記動き候補リストに基づいて、前記第1の映像ブロックに対する動き情報を導出することと、
MMVD(Merge with Motion Vector Differences)ツールを用いて、前記動き情報を改良することと、
前記改良された動き情報に基づいて、前記第1の映像ブロックと、前記第1の映像ブロックを含む映像のビットストリームとの間の変換を実行することと、
前記MMVDツールによって改良された前記改良された動き情報を用いることにより、前記1以上の動き候補テーブルのうちの動き候補テーブルを更新することと、
を有し、
前記更新された動き候補テーブルにおける前記1以上の動き候補は、後続のブロックに対する動き候補リストを構築する間に、順にチェックされる、方法。
【請求項2】
前記第1の映像ブロックは、マージモードにてコーディングされる、請求項1に記載の方法。
【請求項3】
前記動き候補テーブルは、少なくとも1つの特定のモードに属する現在のブロックのコーディングモードに基づいて、更新対象が決定される、請求項1または2に記載の方法。
【請求項4】
前記少なくとも1つの特定のモードは、動きベクトル予測モードまたはマージモードの少なくとも一方を含む、請求項3に記載の方法。
【請求項5】
前記少なくとも1つの特定のモードは、サブブロックマージモードまたは矩形マージモードの少なくとも一方を除き、
前記動き候補テーブルは、前記サブブロックマージモードまたは前記矩形マージモードを用いるブロックから導出された動き情報を用いて更新されない、請求項3に記載の方法。
【請求項6】
前記動き候補テーブルは、HMVP(History Motion Vector Prediction)テーブルである、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記更新することは、
プルーニング動作を用いて前記動き候補テーブルを更新することであって、前記プルーニング動作は、前記動き候補テーブルにおける追加対象の新しい動き候補と、前記動き候補テーブルにおける少なくとも1つの動き候補とを比較し、前記動き候補テーブルから前記少なくとも1つの動き候補を削除するか否かを決定する、ことを有する、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記動き候補リストから導出された動き情報と関連付けられた新しい候補が、前記動き候補テーブルから前記動き候補リストへ追加された動き候補である場合、前記動き候補テーブルは、プルーニング動作を行うことなく並び替えられる、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記動き候補リストから導出された動き情報と関連付けられた新しい候補が、現在のピクチャとは異なるピクチャにおける前記第1の映像ブロックまたは時間的ブロックを有する前記現在のブロックにおける空間的近傍のブロックに関連付けられた動き候補である場合、前記動き候補テーブルは、プルーニング動作を行って更新される、請求項1から8のいずれか一項に記載の方法。
【請求項10】
動きベクトル予測モードにてコーディングされた第2の映像ブロックに対する動き候補リストを導出するための動き候補リスト導出処理を実行することと、
前記第2の映像ブロックに対して導出された前記動き候補リストに基づいて、前記第2の映像ブロックに対する動き情報を導出することと、
前記第2の映像ブロックに対して導出された前記動き情報に基づいて、前記第2の映像ブロックと、前記第2の映像ブロックを有する映像のビットストリームとの間の変換を実行することと、
改良なしで前記第2の映像ブロックに対して導出された前記動き情報を用いて、前記動き候補テーブルを更新することと、
を更に有する請求項1から9のいずれか一項に記載の方法。
【請求項11】
前記変換を実行することは、前記第1の映像ブロックに基づいて、前記ビットストリームを生成することを含む、請求項1から10のいずれか一項に記載の方法。
【請求項12】
前記変換を実行することは、前記第1の映像ブロックを前記ビットストリームから生成することを含む、請求項1から10のいずれか一項に記載の方法。
【請求項13】
プロセッサと、命令を有する非一時的メモリとを有する、映像データを処理するための装置であって、
前記命令は、前記プロセッサによって実行された際に、前記プロセッサに、
1以上の動き候補テーブルを維持することであって、各動き候補テーブルは、1以上の動き候補を有し、少なくとも1つの動き候補テーブルは、少なくとも1つの前の映像ブロックから導出され、前記動き候補テーブルにおける前記動き候補の配置は、前記動き候補テーブルへの前記動き候補の追加の順序に基づく、ことと、
第1の映像ブロックに対する動き候補リストを導出するための動き候補リスト導出処理を実行することと、
前記動き候補リストに基づいて、前記第1の映像ブロックに対する動き情報を導出することと、
MMVD(Merge with Motion Vector Differences)ツールを用いて、前記動き情報を改良することと、
前記改良された動き情報に基づいて、前記第1の映像ブロックと、前記第1の映像ブロックを含む映像のビットストリームとの間の変換を実行することと、
前記MMVDツールによって改良された前記改良された動き情報を用いることにより、前記1以上の動き候補テーブルのうちの動き候補テーブルを更新することと、
を実行させ、
前記更新された動き候補テーブルにおける前記1以上の動き候補は、後続のブロックに対する動き候補リストを構築する間に、順にチェックされる、装置。
【請求項14】
プロセッサに、
1以上の動き候補テーブルを維持することであって、各動き候補テーブルは、1以上の動き候補を有し、少なくとも1つの動き候補テーブルは、少なくとも1つの前の映像ブロックから導出され、前記動き候補テーブルにおける前記動き候補の配置は、前記動き候補テーブルへの前記動き候補の追加の順序に基づく、ことと、
第1の映像ブロックに対する動き候補リストを導出するための動き候補リスト導出処理を実行することと、
前記動き候補リストに基づいて、前記第1の映像ブロックに対する動き情報を導出することと、
MMVD(Merge with Motion Vector Differences)ツールを用いて、前記動き情報を改良することと、
前記改良された動き情報に基づいて、前記第1の映像ブロックと、前記第1の映像ブロックを含む映像のビットストリームとの間の変換を実行することと、
前記MMVDツールによって改良された前記改良された動き情報を用いることにより、前記1以上の動き候補テーブルのうちの動き候補テーブルを更新することと、
を実行させ、
前記更新された動き候補テーブルにおける前記1以上の動き候補は、後続のブロックに対する動き候補リストを構築する間に、順にチェックされる、命令を格納する非一時的コンピュータ可読記録媒体。
【請求項15】
映像のビットストリームを格納する
方法であって、
前記方法は、
1以上の動き候補テーブルを維持することであって、各動き候補テーブルは、1以上の動き候補を有し、少なくとも1つの動き候補テーブルは、少なくとも1つの前の映像ブロックから導出され、前記動き候補テーブルにおける前記動き候補の配置は、前記動き候補テーブルへの前記動き候補の追加の順序に基づく、ことと、
第1の映像ブロックに対する動き候補リストを導出するための動き候補リスト導出処理を実行することと、
前記動き候補リストに基づいて、前記第1の映像ブロックに対する動き情報を導出することと、
MMVD(Merge with Motion Vector Differences)ツールを用いて、前記動き情報を改良することと、
前記改良された動き情報に基づいて、前記ビットストリームを生成することと、
前記MMVDツールによって改良された前記改良された動き情報を用いることにより、前記1以上の動き候補テーブルのうちの動き候補テーブルを更新することと、
前記ビットストリームを非一時的なコンピュータ可読記憶媒体に格納することと、
を有し、
前記更新された動き候補テーブルにおける前記1以上の動き候補は、後続のブロックに対する動き候補リストを構築する間に、順にチェックされる、
方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、2019年1月10日出願の国際特許出願第PCT/CN2019/071214号の優先権および利益を主張する、2020年1月10日出願の国際特許出願第PCT/CN2020/071332号に基づく特願2021-539078の分割出願である。国際出願第PCT/CN2019/071214号の開示全体は、本明細書の開示の一部として参照により援用される。
【0002】
本特許明細書は、映像コーディング技術、デバイスおよびシステムに関する。
【背景技術】
【0003】
映像圧縮の進歩にもかかわらず、デジタル映像は、依然として、インターネット及び他のデジタル通信ネットワークにおいて最大の帯域幅の使用量を占めている。映像の受信及び表示が可能な接続されたユーザ機器の数が増加するにつれ、デジタル映像の使用に対する帯域幅需要は増大し続けることが予測される。
【発明の概要】
【0004】
本書は、動きベクトルのマージリストを使用してデジタル映像を符号化および復号化するための方法、システム、およびデバイスを開示する。
【0005】
一つの例示的な態様において、映像処理方法が開示される。この方法は、1つまたは複数の動き候補テーブルを維持することと、動き候補テーブルを用いたシーケンスにおける複数の映像処理動作を用いて、映像の現在の映像ブロックと前記現在の映像ブロックのコーディングされた表現との間の変換を実行することと、特定の処理動作が完了したことに起因して前記動き候補テーブルを更新することと、を含む。
【0006】
別の例示的な態様において、別の映像処理方法が開示される。この方法は、1つまたは複数の動き候補テーブルを維持することと、コーディングモード、寸法、映像処理データユニット、または低遅延チェックを含む現在の映像ブロックの特徴に基づいて、i)この1つまたは複数の動き候補テーブルの1つの動き候補テーブルを更新するかどうか、またはii)この動き候補テーブルをどのように更新するかの少なくとも一方を決定することと、前記決定に基づいて、映像の現在の映像ブロックと前記映像のコーディングされた表現との間の変換を実行することと、を含む。
【0007】
さらに別の例示的な態様において、本明細書で説明される映像符号化方法を実装する映像エンコーダデバイスが開示される。
【0008】
さらに別の代表的な態様では、本明細書で説明される様々な技法は、非一時的なコンピュータ可読媒体に記憶されるコンピュータプログラム製品として実施され得る。このコンピュータプログラム製品は、本明細書に記載の方法を実行するためのプログラムコードを含む。
【0009】
さらに別の代表的な態様において、映像デコーダ装置は、本明細書で説明されるような方法を実装してもよい。
【0010】
1つ以上の実装形態の詳細は、添付の添付ファイル、図面、および以下の説明に記載されている。他の特徴は、説明および図面、並びに特許請求の範囲の記載から明らかとなろう。
【図面の簡単な説明】
【0011】
【
図1】映像エンコーダの実装形態の例を示すブロック図である。
【
図2】H.264映像コーディング規格におけるマクロブロックの分割を示す。
【
図3】コーディングブロック(CB:Coding Block)を予測ブロック(PU:Prediction Block)に分割する例を示す。
【
図4】CTBをCBおよび変換ブロック(TB)に細分するための例示的な実装形態を示す。実線はCB境界を示し、点線はTB境界を示し、その分割を含むCTBの例、および対応する4分木を含む。
【
図5】映像データを分割するための4分木2分木(QTBT:Quad Tree Binary Tree)構造の一例を示す。
【
図9】マージ候補リスト構築のための導出処理の一例を示す。
【
図11】空間的マージ候補の冗長性チェックに考慮される候補対の例を示す。
【
図12】N×2Nおよび2N×N分割の第2のPUの位置の例を示す。
【
図13】時間的マージ候補のための動きベクトルのスケーリングを示す。
【
図14】時間的マージ候補の候補位置とその同一位置(co-located)のピクチャを示す。
【
図16】動きベクトル予測候補の導出処理の例を示す。
【
図17】空間的動きベクトル候補のための動きベクトルのスケーリングの例を示す。
【
図18】CUの動き予測のための例示的なATMVP(Alternative Temporal Motion Prediction)を示す。
【
図19】ソースブロックおよびソースピクチャの識別の一例を示す。
【
図20】4つのサブブロックおよび近傍のブロックを有する1つのCUの例を示す。
【
図23】FRUC(Frame Rate Up Conversion)におけるユニラテラル動き推定(ME:Motion Estimation)の例を示す。
【
図24】バイラテラルテンプレートマッチングに基づくDMVRの例を示す。
【
図25】空間的マージ候補を導出するために使用する空間的に近傍のブロックの例を示す。
【
図26】ルックアップテーブルの更新のための代表的な位置の選択方法の一例を示す。
【
図27A】新しい動き情報のセットでルックアップテーブルを更新する例を示す。
【
図27B】新しい動き情報のセットでルックアップテーブルを更新する例を示す。
【
図28A】本願に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実現するためのハードウェアプラットフォームの例を示す。
【
図28B】本願に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実現するためのハードウェアプラットフォームの例を示す。
【
図29】開示される技術のいくつかの実装形態に基づく、映像処理方法のフローチャートの一例である。
【
図30】開示される技術のいくつかの実装形態に基づく、映像処理方法のフローチャートの一例である。
【
図31】提案されたHMVP方法による復号化フローチャートの一例を示す。
【
図32】提案されたHMVP方法を用いたテーブルの更新の例を示す。
【
図33A】冗長性除去に基づくLUT更新方法(1つの冗長性動き候補を除去する)の例を示す。
【
図33B】冗長性除去に基づくLUT更新方法(1つの冗長性動き候補を除去する)の例を示す。
【
図34A】冗長性除去に基づくLUT更新方法(複数の冗長性動き候補を除去する)の例を示す。
【
図34B】冗長性除去に基づくLUT更新方法(複数の冗長性動き候補を除去する)の例を示す。
【発明を実施するための形態】
【0012】
映像の圧縮率を改良するために、研究者らは、映像を符号化する新しい技術を絶えず求めている。
【0013】
1.導入
【0014】
本明細書は、映像コーディング技術に関する。具体的には、映像コーディングにおける動き情報のコーディング(例えば、マージモード、AMVPモード)に関する。本発明は、HEVCのような既存の映像符号化規格またはファイナライズされるべき規格(Versatile Video Coding)に適用され得る。本発明は、将来の映像コーディング規格または映像コーデックにも適用可能である。
【0015】
簡単な説明
【0016】
映像コーディング規格は、主に周知のITU-T及びISO/IEC規格の開発によって発展してきた。ITU-TはH.261とH.263を、ISO/IECはMPEG-1とMPEG-4 Visualを、両団体はH.262/MPEG-2 VideoとH.264/MPEG-4 AVC(Advanced Video Coding)とH.265/HEVC規格を共同で作成した。H.262以来、映像コーディング規格は、時間的予測プラス変換コーディングが利用されるハイブリッド映像符号化構造に基づく。典型的なHEVCエンコーダフレームワークの一例を
図1に示す。
【0017】
2.1 分割構造
2.1.1 H.264/AVCにおける分割ツリー構造
【0018】
以前の規格におけるコーディング層のコアは、16×16ブロックの輝度サンプルを含み、また、通常の4:2:0カラーサンプリングの場合、2つの対応する8×8ブロックの彩度サンプル含むマクロブロックであった。
【0019】
イントラ符号化ブロックは、画素間の空間的相関を利用するために空間予測を使用する。2つの分割を規定する。16×16および4×4である。
【0020】
インター符号化ブロックは、ピクチャ間の動きを推定することで、空間的予測の代わりに時間予測を用いる。動きは、16×16マクロブロックまたはそのサブマクロブロック分割のいずれかに対して独立して推定できる。16×8、8×16、8×8、8×4、4×8、4×4(
図2参照)。1つのサブマクロブロック分割当たり1つの動きベクトル(MV:Motion Vector)のみが許可される。
【0021】
2.1.2 HEVCにおける分割ツリー構造
【0022】
HEVCにおいて、CTUは、様々な局所的特徴に適応するように、コーディングツリー(coding tree)と呼ばれる4分木構造を用いてCUに分割される。インターピクチャ(時間的)予測またはイントラピクチャ(空間的)予測を使用した、ピクチャ領域をコーディングするかどうかの決定は、CUレベルで行われる。各CUは、PU分割タイプに応じて1つ、2つまたは4つのPUに更に分割することができる。1つのPUの内部では、同じ予測処理が適用され、PU単位で関連情報がデコーダに送信される。PU分割タイプに基づく予測処理を適用して残差ブロックを得た後、CUのための符号化ツリーに類似した別の4分木構造に基づいて、CUを変換ユニット(TU:Transform Unit)に分割することができる。HEVC構造の重要な特徴の1つは、CU、PU、TUを含む複数の分割概念を有することである。
【0023】
以下、HEVCを使用したハイブリッド映像コーディングに関連する様々な特徴に焦点を当てる。
【0024】
1)コーディングツリーユニットおよびコーディングツリーブロック(CTB:Coding Tree Block)構造。HEVCにおける類似した構造は、コーディングツリーユニット(CTU:Coding Tree Unit)であり、このコーディングツリーユニットは、エンコーダによって選択されたサイズを有し、従来のマクロブロックよりも大きくてもよい。CTUは、輝度CTBと、対応する彩度CTBおよび構文要素とからなる。輝度CTBのサイズL×Lは、L=16、32、または64個のサンプルとして選択することができ、より大きいサイズは、一般的に、より優れた圧縮を有効にする。HEVCは、次いで、ツリー構造および4分木のような信号通知を使用して、CTBをより小さなブロックに分割することをサポートする。
【0025】
2)コーディングユニット(CU:Coding Unit)およびコーディングブロック(CB:Coding Block):CTUの4分木の構文は、その輝度および彩度のCBのサイズおよび位置を指定する。4分木のルートはCTUに関連付けられる。従って、輝度CTBのサイズは、輝度CBに対してサポートされる最大のサイズである。CTUを輝度CBおよび彩度CBに分割することは、共に信号通知されることである。1つの輝度CBおよび通常2つの彩度CBは、関連する構文と共に、1つのコーディングユニット(CU:Coding Unit)を形成する。CTBは、1つのCUのみを含んでもよく、または複数のCUを形成するように分割されてもよく、各CUは、それに関連付けられた予測ユニット(PU:Prediction Unit)への分割と、1つの変換ユニット(TU:Tree Unit)のツリーとを有する。
【0026】
3)予測ユニットおよび予測ブロック(PB:Prediction Block):インターピクチャまたはイントラピクチャ予測を使用してピクチャ領域をコーディングするかどうかの決定は、CUレベルで行われる。PUの分割構造は、そのルートがCUレベルにある。基本的な予測タイプの決定に基づいて、次に、輝度CBおよび彩度CBのサイズをさらに分割し、輝度および彩度予測ブロック(PB)から予測することができる。HEVCは、64×64から4×4までの可変PBサイズのサンプルをサポートする。
図3は、M×MのCUのための許可されたPBの例を示す。
【0027】
4)TUおよび変換ブロック:予測残差は、ブロック変換を使用してコーディングされる。TUツリー構造は、そのルートがCUレベルにある。この輝度CB残差は、輝度変換ブロック(TB)と同一であってもよいし、小さな輝度TBにさらに分割されてもよい。彩度TBについても同様である。正方形のTBサイズ4×4、8×8、16×16、および32×32に対して、離散コサイン変換(DCT)の整数基底関数に類似した整数基底関数が規定される。輝度イントラピクチャ予測残差の4×4変換のために、離散サイン変換(DST)の形式から導出される整数変換が代替的に指定される。
【0028】
図4は、CTBをCB[及び変換ブロック(TB)]に細分する例を示す。実線はCB境界を示し、点線はTB境界を示す。(a)CTBとその分割。(b)対応する4分木。
【0029】
2.1.2.1変換ブロックおよびユニットへのツリー構造の分割
【0030】
残差コーディングの場合、CBは、変換ブロック(TB)に再帰的に分割することができる。この分割は、残差4分木によって信号通知される。
図4に示すように、1つのブロックを再帰的に象限に分割することができるように、正方形のCBおよびTBの分割のみを指定する。サイズM×Mの所与の輝度CBに対して、フラグは、それがサイズM/2×M/2の4つのブロックに分割されるかどうかを信号通知する。さらなる分割が可能である場合、SPSに示される残留4分木の最大深さによって信号通知されるように、各象限には、それが4つの象限に分割されているかどうかを示すフラグが割り当てられる。残差4分木の結果得られる葉ノードブロックは、変換コーディングによってさらに処理される変換ブロックである。エンコーダは、それが使用することになる最大輝度TBサイズおよび最小輝度TBサイズを示す。CBサイズが最大TBサイズよりも大きい場合、分割は非明示的に行われる。分割により、示された最小値よりも小さい輝度TBサイズとなる場合、分割を行わないことが、非明示的に行われる。輝度TBサイズが4×4である場合を除き、彩度TBサイズは、各寸法において輝度TBサイズの半分であり、この場合、4つの4×4輝度TBによって覆われる領域には1つの4×4彩度TBが使用される。イントラピクチャ予測CUの場合、最近の近傍のTB(CB内またはCB外)の復号サンプルが、イントラピクチャ予測のための参照データとして用いられる。
【0031】
従来の規格とは対照的に、HEVC設計により、インターピクチャ予測CUのために1つのTBが複数のPBにまたがることが可能となり、4分木構造のTBの分割の潜在的なコーディング効率の利点が最大となる。
【0032】
2.1.2.2 親子ノード
【0033】
CTBは、4分木構造に基づいて分割され、そのノードはコーディングユニットである。4分木構造における複数のノードは、葉ノード及び非葉ノードを含む。葉ノードは、木構造内に子ノードを有していない(すなわち、葉ノードはそれ以上分割されていない)。非葉ノードは、ツリー構造のルートノードを含む。ルートノードは、映像データの最初の映像ブロック(例えば、CTB)に対応する。複数のノードのうちのそれぞれの非ルートノードごとに、それぞれの非ルートノードにおいて、それぞれの非ルートノードのツリー構造における親ノードに対応する映像ブロックのサブブロックである映像ブロックに対応する。複数の非葉ノードの各非葉ノードは、ツリー構造において1つ以上の子ノードを有する。
【0034】
2.1.3 JEMにおけるより大きいCTUを有する4分木+2分木ブロック構造
【0035】
HEVCを超えた将来の映像コーディング技術を探索するため、2015年には、VCEGとMPEGが共同でJVET(Joint Video Exploration Team)を設立した。それ以来、多くの新しい方法がJVETによって採用され、JEM(Joint Exploration Model)と呼ばれる参照ソフトウェアに組み込まれてきた。
【0036】
2.1.3.1 QTBTブロックの分割構造
【0037】
HEVCとは異なり、QTBT構造は、複数の分割タイプの概念を削除する。すなわち、CU、PU、TUのコンセプトの切り離しを取り除き、CU分割の形状の柔軟性を向上させる。QTBTブロック構造において、CUは正方形または長方形のいずれかを有することができる。
図5に示すように、まず、コーディングツリーユニット(CTU:Coding Tree Unit)を4分木構造で分割する。4分木の葉ノードは、2分木構造によってさらに分割される。2分木の分割には、対称水平分割と対称垂直分割の2つの分割タイプがある。2分木の葉ノードは、コーディングユニット(CU)と呼ばれ、このセグメント化は、それ以上の分割を行うことなく、予測及び変換処理に使用される。これは、QTBTコーディングブロック構造において、CU、PUおよびTUが同じブロックサイズを有することを意味する。JEMにおいて、CUは、異なる色成分のコーディングブロック(CB)からなり、例えば、4:2:0彩度フォーマットのPおよびBスライスの場合、1つのCUは1つの輝度CBおよび2つの彩度CBを含み、また、CUはしばしば単一の成分のCBからなり、例えば、1つのCUは、1つの輝度CBのみを含み、1つのCUは、1つの輝度CBのみ、またはIスライスの場合、2つの彩度CBのみを含む。
【0038】
QTBT分割スキームに対して以下のパラメータを規定する。
-CTUのサイズ:1つの4分木のルートノードのサイズ、HEVCと同じ概念
-MinQTSize:最小許容の4分木の葉ノードサイズ
-MaxBTSize:最大許容の2分木ルートノードサイズ
-MaxBTDepth:最大許容の2分木の深さ
-MinBTSize:最小許容の2分木の葉ノードのサイズ
【0039】
QTBTの分割構造の一例において、CTUのサイズを、2つの対応する64×64ブロックの彩度サンプルを有する128×128の輝度サンプルとして設定し、MinQTSizeを16×16として設定し、MaxBTSizeを64×64として設定し、MinBTSize(幅および高さの両方について)を4×4として設定し、MaxBTDepthを4として設定する。4分木分割は、まずCTUに適用され、4分木の葉ノードを生成する。4分木の葉ノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを有することが可能である。4分木の葉ノードが128×128である場合、サイズがMaxBTSize(すなわち、64×64)を超えるため、2分木によってさらに分割されない。そうでない場合、4分木の葉ノードは、2分木によってさらに分割されてもよい。従って、この4分木葉ノードは、2分木のルートノードでもあり、その2分木深さは0である。2分木の深さがMaxBTDepth(すなわち、4)に達した場合、それ以上の分割は考慮されない。2分木のノードの幅がMinBTSize(すなわち、4)に等しい場合、それ以上の水平分割は考慮されない。同様に、2分木のノードの高さがMinBTSizeに等しい場合、それ以上の垂直分割は考慮されない。2分木の葉ノードは、さらに分割することなく、予測および変換処理によってさらに処理される。JEMにおいて、最大CTUサイズは、256×256個の輝度サンプルである。
【0040】
図5(左)はQTBTを用いたブロックの分割の例を示し、
図5(右)は対応するツリー表現を示す。実線は4分木の分割を表し、点線は2分木の分割を表す。2分木の各分割(すなわち、非葉)ノードにおいて、1つのフラグが、どの分割タイプ(すなわち、水平または垂直)が使用されるかを示すために信号通知される。ここで、0は、水平分割を表し、1は、垂直分割を表す。4分木の分割の場合、4分木の分割は常にブロックを水平および垂直に分割し、等分したサイズの4つのサブブロックを生成するため、分割タイプを示す必要がない。
【0041】
さらに、QTBT方式は、輝度および彩度が別個のQTBC構造を有する能力をサポートする。現在、PおよびBスライスの場合、1つのCTUにおける輝度および彩度CTBは、同じQTBT構造を共有する。しかしながら、Iスライスの場合、輝度CTBはQTBT構造によってCUに分割され、彩度CTBは別のQTBT構造によって彩度CUに分割される。これは、Iスライスにおける1つのCUが1つの輝度成分のコーディングブロックまたは2つの彩度成分のコーディングロックからなり、PまたはBスライスにおける1つのCUが3つの色成分すべてのコーディングブロックからなることを意味する。
【0042】
HEVCにおいて、小さなブロックのためのインター予測は、動き補償のメモリアクセスを低減するために制限され、その結果、4×8および8×4ブロックのために双方向予測はサポートされず、4×4ブロックのためにインター予測はサポートされない。JEMのQTBTにおいて、これらの制限は取り除かれる。
【0043】
2.1.4 VVCの3分木
【0044】
4分木および2分木以外のツリータイプがサポートされる。本実装形態において、
図6(d)、(e)に示すように、3分木(TT)分割を2つ以上、すなわち、水平および垂直中心側の3分木を導入する。
【0045】
図6は、(a)4分木分割、(b)垂直2分木分割、(c)水平2分木分割、(d)垂直中心側3分木分割、(e)水平中心側3分木分割を示す。
【0046】
ツリーのレベルは2つあり、領域ツリー(4分木)と予測ツリー(2分木または3分木)である。CTUは、まず、領域ツリー(RT:Region Tree)によって分割される。RT葉は、予測ツリー(PT:Prediction Tree)によってさらに分割されてもよい。PT葉はまた、最大PT深さに達するまで、PTでさらに分割されてもよい。PT葉が基本コーディングユニットである。便宜上、ここでもCUと呼ぶ。1つのCUをさらに分割することはできない。予測および変換は両方ともJEMと同様にCUに適用される。分割構造全体を「マルチタイプツリー」と呼ぶ。
【0047】
2.1.5 分割構造
【0048】
この応答で使用されるツリー構造は、マルチツリータイプ(Multi-Tree Type:MTT)と呼ばれ、QTBTを一般化したものである。QTBTにおいて、
図5に示すように、コーディングツリーユニット(CTU:Coding Tree Unit)が、まず、4分木構造で分割される。4分木の葉ノードは、2分木構造によってさらに分割される。
【0049】
MTTの基本構造は、2つのタイプのツリーノードを構成する。
図7に示すように、領域ツリー(RT:Region Tree)および予測ツリー(PT:Prediction Tree)は、9つのタイプの分割をサポートする。
【0050】
図7は、(a)4分木分割、(b)垂直2分木分割、(c)水平2分木分割、(d)垂直3分木分割、(e)水平3分木分割、(f)水平上方非対称2分木分割、(g)水平下方非対称2分木分割、(h)垂直左非対称2分木分割、(i)垂直右非対称2分木分割を示す。
【0051】
領域ツリーは、1つのCTUを4×4サイズの領域ツリーの葉ノードになるように正方形のブロックに再帰的に分割することができる。領域ツリーにおける各ノードにおいて、予測ツリーは、2分木(BT:Bynary Tree)、3分木(TT:Ternary Tree)、および非対称2分木(ABT:Asymmetric Binary Tree)の3つのツリータイプのうちの1つから形成することができる。PT分割において、予測ツリーの枝に4分木の分割を有することは禁止される。JEMにおけるように、輝度ツリーおよび彩度ツリーは、I個のスライスに分けられる。RTおよびPTの信号通知方法を
図8に示す。
【0052】
2.2 HEVC/H.265におけるインター予測
【0053】
各インター予測されたPUは、1つまたは2つの参照ピクチャリストのための動きパラメータを有する。動きパラメータは、動きベクトル及び参照ピクチャインデックスを含む。2つの参照ピクチャリストのうちの1つの参照ピクチャリストの使用は、inter_pred_idcを使用して信号通知されてもよい。動きベクトルは、予測因子に対する差分として明確にコーディングされてもよく、このようなコーディングモードは、AMVPモードと呼ばれる。
【0054】
1つのCUがスキップモードでコーディングされる場合、1つのPUがこのCUに関連付けられ、有意な残差係数がなく、コーディングされた動きベクトル差分も参照ピクチャインデックスもない。マージモードを指定し、これにより、現在のPUのための動きパラメータを、空間的及び時間的候補を含む近傍のPUから取得する。マージモードは、スキップモードのためだけでなく、任意のインター予測されたPUに適用することができる。マージモードの代替としては、動きパラメータの明確な送信であり、各参照ピクチャリストおよび参照ピクチャリストの使用に対応する参照ピクチャインデックスに対応する動きベクトルをPUごとに明確に信号通知することである。
【0055】
2つの参照ピクチャリストのうちの1つを使用することを信号通知が示す場合、サンプルのうちの1つのブロックからPUが生成される。これを「単一予測」と呼ぶ。単一予測は、Pスライス及びBスライスの両方に利用可能である。
【0056】
両方の参照ピクチャリストを使用することを信号通知が示す場合、サンプルのうちの2つのブロックからPUが生成される。これを「双方向予測」と呼ぶ。Bスライスのみに双方向予測が利用可能である。
【0057】
以下、HEVCに規定されるインター予測モードについて詳細に説明する。まず、マージモードについて説明する。
【0058】
2.2.1 マージモード
【0059】
2.2.1.1 マージモードの候補の導出
【0060】
マージモードを使用してPUを予測する場合、ビットストリームからマージ候補リストにおけるエントリを指すインデックスを構文解析し、これを使用して動き情報を検索する。このリストの構成は、HEVC規格で規定されており、以下のステップのシーケンスにしたがってまとめることができる。
・ステップ1:初期候補導出
oステップ1.1:空間的候補の導出
oステップ1.2:空間的候補の冗長性チェック
oステップ1.3:時間的候補の導出
・ステップ2:追加候補の挿入
oステップ2.1:双方向予測候補の作成
oステップ2.2:動きゼロ候補の挿入
【0061】
これらのステップは
図9にも概略的に示されている。空間的マージ候補の導出のために、5つの異なる位置にある候補の中から最大4つのマージ候補を選択する。時間的マージ候補の導出のために、2つの候補の中から最大1つのマージ候補を選択する。デコーダ側ではPUごとに一定数の候補を想定しているので、候補数がスライスヘッダで信号通知されるマージ候補の最大数(MaxNumMergeCand)に達しない場合、追加候補が生成される。候補の数は一定であるので、最良マージ候補のインデックスは、短縮された単項2値化(TU:truncated Unary binarization)を使用してコーディングされる。CUのサイズが8に等しい場合、現在のCUのすべてのPUは、2N×2Nの予測ユニットのマージ候補リストと同じ1つのマージ候補リストを共有する。
【0062】
以下、上述したステップに関連付けられた動作を詳しく説明する。
【0063】
2.2.1.2 空間的候補の導出
【0064】
空間的マージ候補の導出において、
図10に示す位置にある候補の中から、最大4つのマージ候補を選択する。導出の順序はA
1、B
1、B
0、A
0、B
2である。位置A
1、B
1、B
0、A
0のいずれかのPUが利用可能でない場合(例えば、別のスライスまたはタイルに属しているため)、またはイントラ符号化された場合にのみ、位置B2が考慮される。位置A
1の候補を加えた後、残りの候補の追加は、冗長性チェックの対象となり、それにより、同じ動き情報を有する候補を確実にリストから排除でき、コーディング効率を向上させることができる。計算の複雑性を低減するために、前述の冗長性チェックにおいて、考えられる候補対のすべてを考慮することはしない。代わりに、
図11において矢印でリンクされた対のみを考慮し、冗長性チェックに使用される対応する候補が同じ動き情報を有していない場合にのみ、その候補をリストに加える。重複した動き情報の別のソースは、2N×2Nとは異なる分割に関連付けられた「第2のPU」である。一例として、
図12は、それぞれN×2Nおよび2N×Nの場合の第2のPUを示す。現在のPUをN×2Nに分割する場合、リスト構築に位置A
1の候補は考慮されない。実際、この候補を加えることにより、双方向予測ユニットが同じ動き情報を有するようになり、1つのコーディングユニットに1つのPUのみを有することは冗長である。同様に、現在のPUを2N×Nに分割する場合、位置B
1は考慮されない。
【0065】
2.2.1.3 時間的候補の導出
【0066】
このステップにおいて、1つの候補のみがリストに追加される。具体的には、この時間的マージ候補の導出において、所与の参照ピクチャリストにおける現在のピクチャとの間に最小のPOC差を有するピクチャに属する同一位置(co-located)PUに基づいて、スケーリングされた動きベクトルを導出する。スライスヘッダにおいて、同一位置PUの導出に使用される参照ピクチャリストが明確に信号通知される。
図13に点線で示すように、時間的マージ候補のスケーリングされた動きベクトルが得られる。これは、POC距離tb及びtdを利用して、同一位置PUの動きベクトルからスケーリングしたものである。tbは、現在のピクチャの参照ピクチャと現在のピクチャのPOC差として規定され、tdは、同一位置PUの参照ピクチャと同一位置ピクチャのPOC差として規定する。時間的マージ候補の参照ピクチャインデックスをゼロに等しく設定する。このスケーリング処理の実際的な実現については、HEVC仕様に記載されている。Bスライスの場合、2つの動きベクトル、すなわち、1つは参照ピクチャリスト0のためのもの、もう1つは参照ピクチャリスト1のためのもの、を取得し、これらを組み合わせることによって、双方向予測マージ候補を形成する。時間的マージ候補のための動きベクトルのスケーリングの説明。
【0067】
参照フレームに属する同一位置PU(Y)において、
図6に示すように、候補C
0と候補C
1との間で時間的候補の位置を選択する。位置C
0のPUが利用可能でない場合、イントラ符号化されている場合、または現在のCTUの外側にある場合、位置C
1が使用される。そうでない場合、位置C
0が時間的マージ候補の導出に使用される。
【0068】
2.2.1.4 追加候補の挿入
【0069】
空間的-時間的マージ候補の他に、2つの追加のタイプのマージ候補、すなわち、結合双方向予測マージ候補およびゼロマージ候補がある。空間的-時間的マージ候補を利用して、結合双方向予測マージ候補を生成する。結合双方向予測マージ候補は、Bスライスのみに使用される。最初の候補の第1の参照ピクチャリスト動きパラメータと別の候補の第2の参照ピクチャリスト動きパラメータとを組み合わせることで、結合双方向予測候補を生成する。これら2つのタプルが異なる動きの仮説を提供する場合、これらのタプルは、新しい双方向予測候補を形成する。一例として、
図15は、オリジナルリスト(左側)における、mvL0およびrefIdxL0、またはmvL1およびrefIdxL1を有する2つの候補を使用して、最終リスト(右側)に加えられる結合双方向予測マージ候補を生成する場合を示す。これらの追加のマージ候補を生成するために考慮される組み合わせについては、様々な規則が存在する。
【0070】
ゼロ動き候補を挿入し、マージ候補リストにおける残りのエントリを埋めることにより、MaxNumMergeCand容量にヒットする。これらの候補は、空間的変位がゼロであり、ゼロから始まり、新しいゼロ動き候補をリストに加える度に増加する参照ピクチャインデックスを有する。これらの候補が使用する参照フレームの数は、それぞれ、一方向予測の場合は1つ、双方向予測の場合は2つである。最終的には、これらの候補に対して冗長性チェックは行われない。
【0071】
2.2.1.5 並列処理のための動き推定領域
【0072】
符号化処理を高速化するために、動き推定を並列に行うことができ、それによって、所与の領域内のすべての予測ユニットの動きベクトルを同時に導出する。1つの予測ユニットは、その関連する動き推定が完了するまで、隣接PUから動きパラメータを導出することができないので、空間的近傍からのマージ候補の導出は、並列処理に干渉する可能性がある。コーディング効率と処理待ち時間との間のトレードオフを緩和するために、HEVCは、MER(Motion Estimation Region)を規定し、そのサイズは、「log2_parallel_merge_level_minus2」構文要素を使用してピクチャパラメータセットにおいて信号通知される。MERを規定する場合、同じ領域にあるマージ候補は利用不可能であるとしてマークされ、それゆえにリスト構築においては考慮されない。
【0073】
7.3.2.3 ピクチャパラメータセットRBSP構文
7.3.2.3.1 一般ピクチャパラメータセットRBSP構文
【0074】
【0075】
log2_parallel_merge_level_minus2+2は、8.5.3.2.2節で指定されたマージモードの輝度動きベクトルの導出処理と、8.5.3.2.3節で指定された空間的マージ候補の導出処理で使用される変数Log2ParMrgLevelの値を指定する。log2_parallel_merge_level_minus2の値は、0~CtbLog2SizeY-2を含む範囲内とする。変数Log2ParMrgLevelは、以下のように導出される。
Log2ParMrgLevel=log2_parallel_merge_level_minus2+2 (7-37)
注3:Log2ParMrgLevelの値は、マージ候補リストを並列に導出する組み込み能力を示す。例えば、Log2ParMrgLevelが6に等しい場合、64×64ブロックに含まれたすべての予測ユニット(PU)およびコーディングユニット(CU)のためのマージ候補リストを並列に導出することができる。
【0076】
2.2.2 AMVPモードにおける動きベクトル予測
【0077】
動きベクトル予測は、動きベクトルと近傍のPUとの間の空間的-時間的相関を利用し、これを動きパラメータの明確な伝送に用いる。まず、左側、上側の時間的に近傍のPU位置の可用性をチェックし、冗長な候補を取り除き、ゼロベクトルを加えることで、候補リストの長さを一定にすることにより、動きベクトル候補リストを構築する。次いで、エンコーダは、候補リストから最良の予測因子を選択し、選択された候補を示す対応するインデックスを送信することができる。マージインデックスの信号通知と同様に、最良の動きベクトル候補のインデックスは、短縮された単項を使用して符号化される。この場合の符号化対象の最大値は2である(例えば、
図2~
図8)。以下の章では、動きベクトル予測候補の導出処理の詳細を説明する。
【0078】
2.2.2.1 動きベクトル予測候補の導出
【0079】
図16に、動きベクトル予測候補の導出処理をまとめる。
【0080】
動きベクトル予測において、空間的動きベクトル候補と時間的動きベクトル候補という2つのタイプの動きベクトル候補が考慮される。空間的動きベクトル候補の導出のために、
図11に示したように、5つの異なる位置にある各PUの動きベクトルに基づいて、最終的には2つの動きベクトル候補を導出する。
【0081】
時間的動きベクトル候補の導出のために、2つの異なる同一位置に配置された位置に基づいて導出された2つの候補から1つの動きベクトル候補を選択する。空間的-時間的候補の最初のリストを作成した後、リストにおける重複した動きベクトル候補を除去する。可能性のある候補の数が2よりも多い場合、関連づけられた参照ピクチャリストにおける参照ピクチャインデックスが1よりも大きい動きベクトル候補をリストから削除する。空間的-時間的動きベクトル候補の数が2未満である場合は、追加のゼロ動きベクトル候補をリストに加える。
【0082】
2.2.2.2 空間的動きベクトル候補
【0083】
空間的動きベクトル候補の導出において、
図11に示したような位置にあるPUから導出された5つの可能性のある候補のうち、動きマージと同じ位置にあるものを最大2つの候補が考慮される。現在のPUの左側の導出の順序は、A
0、A
1、スケーリングされたA
0、スケーリングされたA
1として規定される。現在のPUの上側の導出の順序は、B
0、B
1、B
2、スケーリングされたB
0、スケーリングされたB
1、スケーリングされたB
2として規定される。そのため、辺ごとに、動きベクトル候補として使用できる場合が4つ、すなわち空間的スケーリングを使用する必要がない2つの場合と、空間的スケーリングを使用する2つの場合とがある。4つの異なる場合をまとめると、以下のようになる。
・空間的スケーリングなし
-(1)同じ参照ピクチャリスト、かつ、同じ参照ピクチャインデックス(同じPOC)
-(2)異なる参照ピクチャリスト、かつ、同じ参照ピクチャ(同じPOC)
・空間的スケーリング
-(3)同じ参照ピクチャリスト、かつ、異なる参照ピクチャ(異なるPOC)
-(4)異なる参照ピクチャリスト、かつ、異なる参照ピクチャ(異なるPOC)
【0084】
最初に非空間的スケーリングの場合をチェックし、次に空間的スケーリングを行う。参照ピクチャリストにかかわらず、POCが近傍のPUの参照ピクチャと現在のPUの参照ピクチャとで異なる場合、空間的スケーリングを考慮する。左側候補のすべてのPUが利用可能でないか、またはイントラ符号化されている場合、上側の動きベクトルのスケーリングは、左側及び上側MV候補の並列導出に役立つ。そうでない場合、上側の動きベクトルに対して空間的スケーリングは許可されない。
【0085】
空間的スケーリング処理において、
図17に示すように、時間的スケーリングと同様にして、近傍のPUの動きベクトルをスケーリングする。主な違いは、現在のPUの参照ピクチャリスト及びインデックスを入力として与え、実際のスケーリング処理は時間的スケーリングと同じであることである。
【0086】
2.2.2.3 時間的動きベクトル候補
【0087】
参照ピクチャインデックスを導出する以外は、時間的マージ候補を導出するための全ての処理は、空間的動きベクトル候補を導出するための処理と同じである(
図6等参照)。
参照ピクチャインデックスはデコーダに信号通知される。
【0088】
2.2.2.4 AMVP情報の信号通知
【0089】
AMVPモードの場合、ビットストリームにおいて、4つの部分、すなわち、予測方向、参照インデックス、MVD、およびmv予測因子候補インデックスを信号通知することができる。
構文テーブル:
【0090】
【0091】
7.3.8.9 動きベクトル差構文
【0092】
【0093】
2.3 JEM(Joint Exploration Model)における新しいインター予測方法
【0094】
2.3.1 サブCUに基づく動きベクトル予測
【0095】
QTBTを有するJEMにおいて、各CUは、各予測方向に対して最大1つの動きパラメータセットを有することができる。エンコーダにおいて、大きなCUをサブCUに分割し、大きなCUのすべてのサブCUの動き情報を導出することにより、2つのサブCUレベルの動きベクトル予測方法を考慮する。ATMVP(Alternative Temporal Motion Vector Prediction)方法により、各CUが、配列された参照ピクチャにおける現在のCUよりも小さい複数のブロックから複数の動き情報のセットをフェッチすることが可能となる。STMVP(Spatial-Temporal Motion Vector Prediction)方法において、時間的動きベクトル予測因子および空間的近傍動きベクトルを使用して、サブCUの動きベクトルを再帰的に導出する。
【0096】
サブCU動き予測のためにより正確な動きフィールドを維持するために、参照フレームの動き圧縮は現在無効にされている。
【0097】
2.3.1.1 代替の時間的動きベクトル予測
【0098】
ATMVP(Alternative Temporal Motion Vector Prediction)において、動きベクトルTMVP(Temporal Motion Vector Prediction)方法は、現在のCUより小さいブロックから動き情報の複数のセット(動きベクトル及び参照インデックスを含む)をフェッチすることで修正される。
図18に示すように、サブCUは、正方形のN×Nのブロックである(デフォルトでは、Nは4に設定される)。
【0099】
ATMVPは、CU内のサブCUの動きベクトルを2つのステップで予測する。第1のステップでは、参照ピクチャにおける対応するブロックを、いわゆる時間的ベクトルで特定する。この参照ピクチャをモーションソースピクチャと呼ぶ。第2のステップは、
図18に示すように、現在のCUをサブCUに分割し、各サブCUに対応するブロックから各サブCUの動きベクトルならびに参照インデックスを取得する。
【0100】
第1のステップにおいて、現在のCUの空間的に近傍のブロックの動き情報によって、参照ピクチャ及び対応するブロックを判定する。近傍のブロックの繰り返し走査処理を回避するために、現在のCUのマージ候補リストにおける最初のマージ候補を用いる。最初の利用可能な動きベクトル及びその関連する参照インデックスを、時間的ベクトル及び動きソースピクチャのインデックスに設定する。このように、ATMVPでは、TMVPに比べて、対応するブロックをより正確に特定することができ、対応するブロック(配列されたブロックと呼ばれることがある)は、常に現在のCUに対して右下または中心位置にある。1つの例において、最初のマージ候補が左側の近傍のブロック(すなわち、
図19のA1)からのものである場合、関連するMVおよび参照ピクチャを利用して、ソースブロックおよびソースピクチャを特定する。
【0101】
図19は、ソースブロックおよびソースピクチャの特定の例を示す。
【0102】
第2のステップにおいて、現在のCUの座標に時間的ベクトルを加えることにより、モーションソースピクチャにおける時間的ベクトルによって、サブCUの対応するブロックを特定する。サブCUごとに、その対応するブロックの動き情報(中心サンプルを覆う最小の動きグリッド)を使用して、サブCUの動き情報を導出する。対応するN×Nブロックの動き情報を特定した後、HEVCのTMVPと同様に、現在のサブCUの動きベクトル及び参照インデックスに変換され、動きスケーリングや他の手順が適用される。例えば、デコーダは、低遅延条件(すなわち、現在のピクチャのすべての参照ピクチャのPOCが現在のピクチャのPOCよりも小さい)が満たされているか否かをチェックし、場合によっては、動きベクトルMVx(参照ピクチャリストXに対応する動きベクトル)を使用して、各サブCUの動きベクトルMVy(Xが0または1に等しく、Yが1-Xに等しい)を予測する。
【0103】
2.3.1.2 空間的-時間的動きベクトル予測
【0104】
この方法において、サブCUの動きベクトルは、ラスタスキャンの順に沿って再帰的に導出される。
図20にこの概念を示す。4つの4×4のサブCU A、B、C、及びDを含む8×8のCUを考える。現在のフレームの近傍の4×4のブロックには、a、b、c、dというラベルが付けられている。
【0105】
サブCU Aの動きの導出は、その2つの空間的近傍を特定することで始まる。第1の近傍は、サブCU Aの上のN×Nのブロックである(ブロックc)。このブロックcが利用可能でないか、またはイントラ符号化されている場合、サブCU Aより上の他のN×Nのブロックをチェックする(ブロックcから始まり、左から右へ)。第2の近傍は、サブCU Aの左側のブロックである(ブロックb)。ブロックbが利用可能でないか、またはイントラ符号化されている場合、サブCU Aの左側の他のブロックをチェックする(ブロックbから始まり、上から下へ)。各リストの近傍のブロックから得られた動き情報を、所与のリストの第1の参照フレームにスケーリングする。次に、HEVCで規定されているTMVP(Temporal Motion Vector Predictor)導出と同じ手順に従って、サブブロックAのTMVPを導出する。位置Dの同一位置のブロックの動き情報をフェッチし、それに応じてスケーリングする。最後に、動き情報を検索し、スケーリングした後、参照リストごとにすべての利用可能な動きベクトル(最大3)を別個に平均する。この平均化された動きベクトルを現在のサブCUの動きベクトルとして割り当てる。
【0106】
図20は、4つのサブブロック(A~D)およびその近傍のブロック(a~d)を有する1つのCUの例を示す。
【0107】
2.3.1.3 サブCU動き予測モード信号通知
【0108】
サブCUモードは追加のマージ候補として有効とされ、モードを信号通知するために追加の構文要素は必要とされない。ATMVPモード及びSTMVPモードを表すように、各CUのマージ候補リストに2つの追加のマージ候補を加える。シーケンスパラメータセットがATMVP及びSTMVPが有効であることを示す場合、最大7つのマージ候補を使用する。追加のマージ候補の符号化ロジックは、HMにおけるマージ候補の場合と同じであり、つまり、PまたはBスライスにおける各CUについて、2つの追加のマージ候補に対して2回以上のRDチェックが必要となる。
【0109】
JEMにおいて、マージインデックスのすべてのビンは、CABACによってコーディングされたコンテキストである。一方、HEVCにおいては、最初のビンのみが符号化されたコンテキストであり、残りのビンはバイパスコーディングされたコンテキストである。
【0110】
2.3.2 適応動きベクトル差解像度
【0111】
HEVCにおいて、use_integer_mv_flagがスライスヘッダにおいて0であるとき、1/4輝度サンプルの単位で動きベクトル差分(MVD:Motion Vector Diefference)(動きベクトルとPUの予測動きベクトルとの間の差分)が信号通知される。JEMにおいて、LAMVR(Locally Adaptive Motion Vector Resolution)が導入される。JEMにおいて、MVDは、1/4輝度サンプル、整数輝度サンプル、または4つの輝度サンプルの単位でコーディングできる。MVD分解能はコーディングユニット(CU:Coding Unit)レベルで制御され、MVD解像度フラグは、少なくとも1つの非ゼロMVDモジュールを有する各CUに対して条件付きで信号通知される。
【0112】
少なくとも1つの非ゼロMVDの構成要素を有するCUの場合、1/4輝度サンプルMV精度がCUにおいて使用されるか否かを示すために、第1のフラグが信号通知される。第1のフラグ(1に等しい)が、1/4輝度サンプルMV精度が使用されていないことを示す場合、整数輝度サンプルMV精度が使用されるか、または4輝度サンプルMV精度が使用されるかを示すために、別のフラグが信号通知される。
【0113】
CUの第1のMVD解像度フラグがゼロであるか、またはCUに対してコーディングされていない(つまり、CUにおけるすべてのMVDがゼロである)場合、CUに対して1/4輝度サンプルMV解像度が使用される。CUが整数輝度サンプルMV精度または4輝度サンプルMV精度を使用する場合、CUのAMVP候補リストにおけるMVPを対応する精度に丸める。
【0114】
エンコーダにおいて、CUレベルのRDチェックは、どのMVD解像度をCUに用いるかを判定するために使用される。すなわち、MVD解像度ごとに3回、CUレベルのRDチェックを行う。エンコーダの速度を速めるために、JEMにおいては、以下の符号化方式が適用される。
【0115】
通常の1/4輝度サンプルMVD解像度を有するCUのRDチェック中、現在のCUの動き情報(整数輝度サンプル精度)が記憶される。整数輝度サンプル及び4輝度サンプルのMVD解像度を有する同じCUのRDチェック中に、記憶された動き情報(丸められた後)は、更なる小範囲の動きベクトル改良の開始点として使用されるので、時間がかかる動き推定処理が3回重複しない。
【0116】
4輝度サンプルMVD解像度を有するCUのRDチェックを条件付きで呼び出す。CUの場合、整数輝度サンプルMVD解像度のRDコストが1/4輝度サンプルMVD解像度のそれよりもはるかに大きい場合、CUのための4輝度サンプルMVD解像度のRDチェックはスキップされる。
【0117】
2.3.3 パターンマッチング動きベクトル導出
【0118】
PMMVD(Pattern Matched Motion Vector Derivation)モードは、FRUC(Frame-Rate Up Conversion)技術に基づく特殊マージモードである。このモードでは、ブロックの動き情報は信号通知されず、デコーダ側で導出される。
【0119】
そのマージフラグが真である場合、FRUCフラグは、CUに信号通知される。FRUCフラグが偽である場合、マージインデックスは信号通知され、通常のマージモードが使用される。FRUCフラグが真である場合、追加のFRUCモードフラグを信号通知して、どの方法(バイラテラルマッチングまたはテンプレートマッチング)を使用してブロックの動き情報を導出するかを示す。
【0120】
エンコーダ側では、CUのためにFRUCマージモードを使用するかどうかの決定は、通常のマージ候補に対して行われるのと同じように、RDコストの選択に基づく。つまり、RDコスト選択を使用して、CUに対して2つのマッチングモード(例えば、バイラテラルマッチングおよびテンプレートマッチング)を両方チェックする。最小コストに導くものが、更に、他のCUモードと比較される。FRUCマッチングモードが最も効率的なものである場合、CUに対してFRUCフラグを真に設定し、関連するマッチングモードを使用する。
【0121】
FRUCマージモードにおける動き導出処理は、2つのステップを有する。まず、CUレベルの動き探索を実行し、次に、サブCUレベルの動き改良を実行する。CUレベルでは、バイラテラルマッチングまたはテンプレートマッチングに基づいて、CU全体のための初期の動きベクトルを導出する。まず、MV候補のリストを生成し、最小マッチングコストに導く候補を、さらなるCUレベル改良の開始点として選択する。そして、開始点付近のバイラテラルマッチングまたはテンプレートマッチングに基づく局所検索を行い、最小マッチングコストとなるMV結果をCU全体のMVとする。続いて、導出されたCU動きベクトルを開始点として、サブCUレベルでの動き情報をさらに改良する。
【0122】
例えば、W×HのCU動き情報の導出のために、以下の導出処理を行う。第1のステージにおいて、W×HのCU全体のためのMVが導出される。第2のステージにおいて、CUは、M×MのサブCUにさらに分割される。Mの値は、(16)のように計算されるが、Dは、予め規定義された分割深さであり、JEMにおいてデフォルトで3に設定される。そして、各サブCUのMVを導出する。
【0123】
【0124】
図21に示すように、バイラテラルマッチングは、2つの異なる参照ピクチャにおける現在のCUの動き軌跡に沿った2つのブロック間の最も近いマッチングを見出すことにより、現在のCUの動き情報を導出するために用いられる。連続した動き軌跡を仮定すると、2つの参照ブロックを指す動きベクトルMV0およびMV1は、現在のピクチャと2つの参照ピクチャとの間の時間的距離、例えばTD0およびTD1に比例する。特殊なケースとしては、現在のピクチャが時間的に2つの参照ピクチャの間にあり、現在のピクチャと2つの参照ピクチャとの時間的な距離が同じである場合、バイラテラルマッチングはミラーに基づく双方向MVとなる。
【0125】
図22に示すように、現在のピクチャにおけるテンプレート(現在のCUの上側および/または左側の近傍のブロック)と、参照ピクチャにおけるブロック(テンプレートと同じサイズ)との間の最も近いマッチングを見出すことで、テンプレートマッチングを使用して、現在のCUの動き情報を導出する。前述のFRUCマージモード以外に、テンプレートマッチングは、AMVPモードにも適用される。JEMにおいて、HEVCと同様、AMVPは2つの候補を有する。テンプレートマッチング法を用いることで、新しい候補を導出する。テンプレートマッチングによって新規に導出された候補が、第1の既存のAMVP候補と異なる場合、AMVP候補リストの最初に挿入し、次に、リストサイズを2(第2の既存のAMVP候補を取り除くことを意味する)に設定する。AMVPモードに適用される場合、CUレベル検索のみが適用される。
【0126】
2.3.3.1 CUレベルMV候補セット
【0127】
CUレベルのMV候補セットは、以下からなる。
(i)現在のCUがAMVPモードになっている場合の元のAMVP候補
(ii)すべてのマージ候補、
(iii)補間MVフィールド内の複数のMV。
(iv)上と左の近傍の動きベクトル
【0128】
バイラテラルマッチングを使用する場合、マージ候補の各有効なMVを入力として使用して、バイラテラルマッチングを仮定してMV対を生成する。例えば、マージ候補の1つの有効なMVは、参照リストAにおいて(MVa,refa)である。そして、refaおよびrefbは、時間的に現在のピクチャの異なる側にあるように、その対をなすバイラテラルMVの参照ピクチャrefbが他の参照リストBにおいて見出される。参照リストBにおいてこのようなrefbが利用可能でない場合、refbをrefaとは異なる参照として決定し、現在のピクチャとの時間的距離はリストBにおける最小値である。refbを決定した後、現在のピクチャとrefa,refbとの時間距離に基づいてMVaをスケーリングすることによりMVbを導出する。
【0129】
補間されたMVフィールドからの4つのMVもCUレベル候補リストに追加する。具体的には、現在のCUの位置(0,0)、(W/2,0)、(0,H/2)、(W/2,H
/2)の補間されたMVを加算する。
【0130】
AMVPモードでFRUCを適用する場合、元のAMVP候補をCUレベルMV候補セットにも加える。
【0131】
CUレベルにおいて、AMVP CUのための最大15のMVおよびマージCUのための最大13のMVを候補リストに加える。
【0132】
2.3.3.2 サブCUレベルMV候補セット
【0133】
サブCUレベルのMV候補セットは、以下から構成される。
(i)CUレベルの検索から決定されたMV、
(ii)上、左、左上、右上の近傍のMV、
(iii)参照ピクチャから並置されたMVのスケーリングされたバージョン、
(iv)最大4つのATMVP候補、
(v)最大4つのSTMVP候補
【0134】
参照ピクチャからのスケーリングされたMVは、以下のように導出される。両方のリストにおける参照ピクチャをすべてトラバースする。参照ピクチャにおけるサブCUの配列位置にあるMVは、開始CUレベルMVの参照に対してスケーリングされる。
【0135】
ATMVPおよびSTMVPの候補は、最初の4つの候補に限定される
【0136】
サブCUレベルにおいて、最大17のMVが候補リストに追加される。
【0137】
2.3.3.3 補間MVフィールドの生成
【0138】
フレームをコーディングする前に、ユニラテラルMEに基づいてピクチャ全体に対して補間動きフィールドを生成する。そして、この動きフィールドは、後にCUレベルまたはサブCUレベルのMV候補として使用されてもよい。
【0139】
まず、両方の参照リストにおける各参照ピクチャの動きフィールドは、4×4ブロックレベルでトラバースされる。各4×4ブロックにおいて、(
図23に示すように)現在のピクチャの4×4ブロックを通過するブロックに関連する動きで、ブロックが補間動きをまだ割り当てられていない場合、時間的距離TD0およびTD1に基づいて(HEVCにおけるTMVPのMVスケーリングと同様に)、参照ブロックの動きを現在のピクチャにスケーリングし、スケーリングされた動きを現在のフレームのブロックに割り当てる。4×4ブロックにスケーリングされたMVが割り当てられていない場合、ブロックの動きは、補間された動きフィールドにおいて利用不可能であるとマークされる。
【0140】
2.3.3.4 補間およびマッチングコスト
【0141】
動きベクトルが分数のサンプル位置を指す場合、動き補償補間が必要である。複雑性を低減するために、通常の8タップHEVC補間の代わりに、バイラテラルマッチングおよびテンプレートマッチングの両方に双線形補間を使用する。
【0142】
マッチングコストの計算は、異なるステップでは少し異なる。CUレベルの候補セットから候補を選択する場合、マッチングコストは、バイラテラルマッチングまたはテンプレートマッチングの差分の絶対値の和(SAD)である。開始MVを決定した後、サブCUレベル検索におけるバイラテラルマッチングのマッチングコストCを以下のように算出する。
【0143】
【0144】
ここで、wは、経験的に4に設定された重み係数であり、MVおよびMVsは、それぞれ、現在のMVおよび開始MVを示す。SADは、依然として、サブCUレベル検索におけるテンプレートマッチングのマッチングコストとして使用される。
【0145】
FRUCモードにおいて、MVは、輝度サンプルのみを使用することによって導出される。導出された動きは、MCインター予測のために、輝度および彩度の両方に使用される。MVを決定した後、輝度用の8タップ補間フィルタおよび彩度用の4タップ補間フィルタを使用して、最終的なMCを行う。
【0146】
2.3.3.5 MVの改良
【0147】
MV改良は、バイラテラルマッチングコストまたはテンプレートマッチングコストの基準を有するパターンに基づくMV検索である。JEMにおいて、2つの検索パターン、すなわち、UCBDS(Unrestricted Center-Biased Diamond Search)およびCUレベルおよびサブCUレベルでのMV改良のための適応的横断検索をそれぞれサポートする。CUおよびサブCUレベルのMV改良の両方のために、MVは、1/4輝度サンプルMVの精度で直接検索され、これに続いて1/8輝度サンプルMVの改良が行われる。CUおよびサブCUステップのためのMV改良の検索範囲は、8つの輝度サンプルに等しく設定される。
【0148】
2.3.3.6 テンプレートマッチングFRUCマージモードにおける予測方向の選択
【0149】
バイラテラルマッチングマージモードにおいては、2つの異なる参照ピクチャにおける現在のCUの動き軌跡に沿った2つのブロック間の最も近いマッチングに基づいて、CUの動き情報を導出するために、双方向予測が常に適用される。テンプレートマッチングマージモードについては、そのような限定はない。テンプレートマッチングマージモードにおいて、エンコーダは、list0からの単一予測、list1からの単一予測、またはCUのための双方向予測のうちから選択することができる。選択は、テンプレートマッチングコストに基づいて、以下のように行う。
costBi<=factor*min(cost0,cost1)の場合
双方向予測を用いる。
そうでない場合、cost0<=cost1であれば、
list0からの単一予測を用いる。
そうでない場合、
list1からの単一予測を用いる。
【0150】
ここで、cost0はlist0テンプレートマッチングのSADであり、cost1はlist1テンプレートマッチングのSADであり、costBiは双方向予測テンプレートマッチングのSADである。factorの値が1.25である場合、選択処理が双方向予測に偏っていることを意味する。
このインター予測方向選択は、CUレベルのテンプレートマッチング処理にのみ適用される。
【0151】
2.3.4 デコーダ側動きベクトル改良
【0152】
双方向予測演算において、1つのブロック領域を予測するために、list0の動きベクトル(MV:Motion Vector)およびlist1のMVをそれぞれ使用して構成される双方向予測されたブロックを組み合わせ、1つの予測信号を形成する。DMVR(Decoder-side Motion Vector Refinement)方法において、バイラテラルテンプレートマッチング処理によって、双方向予測の2つの動きベクトルをさらに改良する。追加の動き情報を送信することなく改良されたMVを得るために、デコーダにおいてバイラテラルテンプレートマッチングを適用し、バイラテラルテンプレートと参照ピクチャにおける再構成サンプルとの間の歪みに基づく検索を行う。
【0153】
DMVRにおいて、
図23に示すように、list0の最初のMV0とlist1のMV1とから、それぞれ、2つの予測ブロックの重み付け結合(すなわち、平均)としてバイラテラルテンプレートを生成する。テンプレートマッチング動作は、生成されたテンプレートと参照ピクチャにおけるサンプル領域(最初の予測ブロックの付近)との間のコスト尺度を計算することからなる。2つの参照ピクチャの各々について、テンプレートコストが最小となるMVを、そのリストの更新されたMVと見なし、元のMVに置き換える。JEMにおいて、各リストに対して9つのMV候補を検索する。9つのMV候補は、元のMVと、水平または垂直方向のいずれかまたは両方向に元のMVに対してオフセットしている1つの輝度サンプルを有する8つの周囲のMVを含む。最後に、2つの新しいMV、すなわち、
図24に示すようなMV0’及びMV1’を使用して、最終的な双方向予測結果を生成する。差分の絶対値の和(SAD)をコスト尺度として使用する。
【0154】
DMVRは、追加の構文要素を送信することなく、過去の参照ピクチャからの1つのMVと、将来の参照ピクチャからの1つのMVとの間の双方向予測のマージモードに適用される。JEMにおいて、LIC、アフィン動き、FRUC、またはサブCUマージ候補がCUに対して有効である場合、DMVRは適用されない。
【0155】
2.3.5 バイラテラルマッチングの改良を伴うマージ/スキップモード
【0156】
まず、利用可能な候補の数が最大候補サイズである19に達するまで、空間的に近傍のブロックおよび時間的に近傍のブロックの動きベクトルおよび参照インデックスを冗長性チェック付き候補リストに挿入することで、マージ候補リストを構築する。マージ/スキップモードのマージ候補リストは、予め規定された挿入順に基づいて、HEVC(結合候補およびゼロ候補)に用いられる、空間的候補(
図11)、時間的候補、アフィン候補、ATMVP(Advanced Temporal MVP)候補、STMVP(Spatial Temporal MVP)候補、および追加候補を挿入することで構築される。
【0157】
-ブロック1~4の空間的候補
【0158】
-ブロック1~4の外挿アフィン候補
【0159】
-ATMVP
【0160】
-STMVP
【0161】
-仮想アフィン候補
【0162】
-空間的候補(ブロック5)(利用可能な候補の数が6よりも少ない場合にのみ使用される)。
【0163】
-外挿アフィン候補(ブロック5)
【0164】
-時間的候補(HEVCのように導出)
【0165】
-外挿アフィン候補に続く非隣接空間的候補(
図25に示すブロック6~49)
【0166】
-結合候補
【0167】
-ゼロ候補
【0168】
なお、ICフラグは、STMVPおよびアフィンを除き、マージ候補から継承される。また、最初の4つの空間的候補について、双方向予測のものを単一予測のものの前に挿入する。
【0169】
現在のブロックに接続されていないブロックにアクセスすることができる。非隣接ブロックが非イントラモードでコーディングされている場合、関連する動き情報を追加のマージ候補として追加してもよい。
【0170】
3.本明細書に開示される実施形態が解決しようとする課題の例
【0171】
現在のHEVC設計は、動き情報をより良くコーディングするために、現在のブロックの近傍のブロック(現在のブロックの隣)の相関をとることができる。しかしながら、近傍のブロックが、異なる動き軌跡を有する異なる対象に対応する可能性がある。この場合、その近傍のブロックからの予測は効率的ではない。
【0172】
非隣接ブロックの動き情報からの予測は、全ての動き情報(一般的には4×4レベル)をキャッシュに記憶するコストをかけることになり、付加的なコーディング利得をもたらし、ハードウェア実装の複雑性を大幅に増大させる。
【0173】
4.いくつかの例
【0174】
以下の例は、一般的な概念を説明するための例であると考えられるべきである。これらの例は狭義に解釈されるべきではない。さらに、これらの例は、任意の方法で組み合わせることができる。
【0175】
いくつかの実施形態において、1つのブロックの動き情報を予測するために、少なくとも1つの動き候補が記憶された1つ以上のルックアップテーブルを用いてもよい。実施形態は、動き候補を用いて、ルックアップテーブルに記憶された動き情報のセットを示すことができる。従来のAMVPまたはマージモードの場合、実施形態では、動き情報を記憶するためにAMVPまたはマージ候補を使用してもよい。
【0176】
以下の実施例は、一般的な概念を説明する。
【0177】
ルックアップテーブルの例
【0178】
例A1:各ルックアップテーブルは、各候補がその動き情報に関連付けられた1つ以上の動き候補を含んでもよい。
a.動き候補の動き情報は、予測方向、参照インデックス/ピクチャ、動きベクトル、LICフラグ、アフィンフラグ、MVD精度、MVD値の一部または全部を含んでもよい。
b.動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情報および/またはブロック形状をさらに含んでもよい。
【0179】
c.ルックアップテーブルごとにカウンタをさらに割り当ててもよい。
i.ピクチャ/スライス/LCU(CTU)行/タイルの符号化/復号化の開始時に、カウンタをゼロに初期化してもよい。
ii.一例において、カウンタは、CTU/CTB/CU/CB/PU/一定の領域サイズ(例えば、8×8または16×16)を符号化/復号化した後に更新されてもよい。
iii.一例において、1つの候補をルックアップテーブルに加える度に、カウンタを1つずつ増加させる。
iv.一例において、カウンタは、テーブルのサイズ(許容される動き候補の数)以下であるべきである。
v.代替的に、カウンタを使用して、いくつの動き候補をルックアップテーブルに追加しようとしたかを示してもよい(これらのうちのいくつかはルックアップテーブルに含まれていたが、後にテーブルから削除してもよい)。この場合、カウンタはテーブルのサイズよりも大きくてもよい。
【0180】
d.テーブルのサイズ(許可される動き候補の数)および/またはテーブルの数は、固定であってもよいし、適応的であってもよい。テーブルのサイズは、すべてのテーブルで同じであってもよいし、異なるテーブルで異なってもよい。
i.代替的に、異なるサイズを異なるルックアップテーブル(例えば、1または2)
に使用してもよい。
ii.一例において、テーブルのサイズおよび/またはテーブルの数は、予め規定されてもよい。
iii.一例において、テーブルのサイズおよび/またはテーブルの数は、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、スライスヘッダ、タイルヘッダ、CTU(Coding Tree Unit)、CTB(Coding Tree Block)、CU(Coding Unit)またはPU(Prediction Unit)、複数のCTU/CTB/CU/PUを含む領域で信号通知されてもよい。
iv.テーブルのサイズおよび/またはテーブルの数は、スライスタイプ、ピクチャの時間層インデックス、1つのスライスと最も近いイントラスライスとの間のPOC(Picture Order Count)距離に更に依存してもよい。
【0181】
e.コーディングスレッドに使用されるN個のテーブルが存在し、スライスをコーディングするためにN*P個のテーブルが必要とされ、ここで、Pは、LCU行の数またはタイルの数を示す。
i.代替的に、スライスをコーディングするためにP個のテーブルのみが必要とされてもよく、PはLCU行の数を示し、タイルが無効とされている場合、Nが1よりも大きくなる可能性がある場合でも、各LCU行は1つのルックアップテーブルのみを使用する。
【0182】
LUTの選択
【0183】
例B1:ブロックをコーディングする場合、1つのルックアップテーブルからの動き候補の一部または全部を順にチェックすることができる。ブロックをコーディングする間に1つの動き候補をチェックする場合、この動き候補を動き候補リスト(例えば、AMVP、マージ候補リスト)に加えてもよい。
a.代替的に、複数のルックアップテーブルからの動き候補を順にチェックしてもよい。
b.ルックアップテーブルインデックスは、CTU、CTB、CU若しくはPU、または複数のCTU/CTB/CU/PUを含む領域において信号通知されてもよい。
【0184】
例B2:ルックアップテーブルの選択は、ブロックの位置に依存してもよい。
a.それは、ブロックを含むCTUアドレスに依存してもよい。ここで、アイデアを説明するために、例として二つのルックアップテーブル(デュアルルックアップテーブル、DLUT)を挙げる。
i.ブロックがCTU行内の第1のM個のCTUのうちの1つに位置する場合、第1のルックアップテーブルをブロックのコーディングに利用してもよく、CTU行内の残りのCTUに位置するブロックの場合、第2のルックアップテーブルを利用してもよい。
ii.ブロックがCTU行内の第1のM個のCTUの1つに位置する場合、まず第1のルックアップテーブルの動き候補によってブロックをコーディングするかどうかをチェックし、第1のテーブルに十分な候補がない場合、第2のルックアップテーブルをさらに利用してよい。一方、CTU行の残りのCTUに位置するブロックに対して、第2のルックアップテーブルを利用してもよい。
iii.代替的に、CTU行の残りのCTUに位置するブロックについて、第2のルックアップテーブルの動き候補がまずブロックのコーディングについてチェックされ、第2のテーブルに十分な候補がない場合、第1のルックアップテーブルをさらに利用してよい。
【0185】
b.それは、ブロックの位置と、1つ以上のルックアップテーブルにおける1つの動き候補に関連付けられた位置との間の距離に依存してもよい。
iv.一例において、1つの動き候補がコーディング対象のブロックまでのより小さな距離に関連付けられている場合、別の動き候補と比較して早くチェックされてもよい。
【0186】
ルックアップテーブルの使用法
【0187】
例C1:チェック対象のルックアップテーブルにおける動き候補の総数は、予め規定されてもよい。
a.それは、コーディングされた情報、ブロックサイズ、ブロック形状等にさらに依存してもよい。例えば、AMVPモードの場合、m個の動き候補のみをチェックし、マージモードの場合、n個の動き候補をチェックしてもよい(例えば、m=2、n=44)。
b.一例において、チェック対象の動き候補の総数は、VPS(Video Parameter Set)、SPS(Sequence Paramter Set)、PPS(Picture Parameter Set)、スライスヘッダ、タイルヘッダ、CTU(Coding Tree Set)、CTB(Coding Tree Block)、CU(Coding Unit)またはPU(Prediction Unit)、複数のCTU/CTB/CU/PUを含む領域で信号通知されてもよい。
【0188】
例C2:ルックアップテーブルに含まれる1つ以上の動き候補は、1つのブロックによって直接継承されてもよい。
a.それらをマージモードコーディングに使用してもよく、すなわち、マージ候補リスト導出処理において動き候補をチェックしてもよい。
b.それらは、アフィンマージモードコーディングに使用してもよい。
i.アフィンフラグが1である場合、ルックアップテーブルにおける動き候補をアフィンマージ候補として加えることができる。
【0189】
c.以下の場合、ルックアップテーブルにおける動き候補のチェックを有効にしてもよい。
i.TMVP候補を挿入した後、マージ候補リストが満杯になっていない。
ii.空間的マージ候補導出のために特定の空間的に近傍のブロックをチェックした後、マージ候補リストが満杯になっていない。
iii.すべての空間的マージ候補の後、マージ候補リストに空きがある。
iv.双方向予測マージ候補の結合の後、マージ候補リストに空きがある。
v.他のコーディング方式(例えば、HEVCデザインのマージ導出処理、またはJEMデザイン)からマージ候補リストに入れられた空間的または時間的な(例えば、隣接空間および非隣接空間を含む、TMVP、STMVP、ATMVPなど)マージ候補の数が、最大許容マージ候補から、所与の閾値を引いた数よりも少ない場合。
1.一例において、閾値は、1または0に設定される。
2.代替的に、閾値は、SPS/PPS/シーケンス、ピクチャ、スライスヘッダ/タイルにおいて信号通知されてもよく、または予め規定されてもよい。
3.代替的に、閾値は、ブロックごとに適応的に変更されてもよい。例えば、それは、ブロックサイズ/ブロック形状/スライスタイプのようなコーディングされたブロック情報に依存してもよく、および/または利用可能な空間的または時間的マージ候補の数に依存してもよい。
4.他の例において、既にマージ候補リストに含まれていないある種のマージ候補の数が、最大許容マージ候補から、所与の閾値を引いた数未満である場合。「ある種のマージ候補」は、HEVCのような空間的候補であってもよいし、非隣接マージ候補であってもよい。
vi.マージ候補リストに動き候補を追加する前に、プルーニングを適用してもよい。
1.一例において、動き候補は、マージ候補リストの他のコーディング方法から利用可能な空間的または時間的(例えば、隣接空間および非隣接空間、TMVP、STMVP、ATMVP等を含む)マージ候補の全部または一部にプルーニングされてもよい。
2.動き候補は、サブブロックに基づく動き候補、例えば、ATMVP、STMVPにプルーニングされなくてもよい。
3.一例において、現在の動き候補は、マージ候補リストにおける利用可能な動き候補(現在の動き候補の前に挿入された)の全部または一部にプルーニングされてもよい。
4.動き候補に関連するプルーニング動作の数(つまり、動き候補をマージリストにおける他の候補と比較する必要がある回数)は、利用可能な空間的または時間的マージ候補の数に依存してもよい。例えば、新しい動き候補をチェックするとき、マージリストに利用可能な候補がM個ある場合、新しい動き候補を最初のK個(K<=M)の候補とのみ比較することができる。プルーニング関数が偽を返す(例えば、最初のK個の候補のいずれとも同一でない)場合、この新しい動き候補は、M個の候補のすべてと異なると見なされ、マージ候補リストに追加され得る。一例において、Kは、min(K,2)に設定される。
5.一例において、新しく付加された動き候補とマージ候補リストにおける第1のNの候補とを比較するだけである。例えば、N=3、4または5である。Nは、エンコーダからデコーダに信号通知されてもよい。
6.一例において、チェック対象の新しい動き候補は、マージ候補リストにおける最後のNの候補と比較されるのみである。例えば、N=3、4または5である。Nは、エンコーダからデコーダに信号通知されてもよい。
7.一例において、新しい動き候補と比較すべき、リストに以前追加された候補のテーブルからの選択方法は、前回追加された候補がどこから導出されたかに依存してもよい。
a.一例において、ルックアップテーブルにおける動き候補を、所与の時間的および/または空間的に近傍のブロックから導出された候補と比較してもよい。
b.一例において、ルックアップテーブルにおける動き候補の異なるエントリを、以前追加された異なる候補と比較してもよい(すなわち、異なる位置から導出された)。
【0190】
例C3:ルックアップテーブルに含まれる動き候補は、ブロックの動き情報をコーディングする予測因子として用いられてもよい。
a.それらをAMVPモードコーディングに使用してもよく、すなわち、AMVP候補リスト導出処理において動き候補をチェックしてもよい。
b.以下の場合、ルックアップテーブルにおける動き候補のチェックを有効にしてもよい。
i.TMVP候補を挿入した後、AMVP候補リストが満杯になっていない。
ii.AMVP候補リストは、空間的近傍から選択し、プルーニングした後で、TMVP候補を挿入する直前には、満杯になっていない。
iii.上側の近傍のブロックからのAMVP候補がスケーリング無しで存在しない場合、および/または、左側の近傍のブロックからのAMVP候補がスケーリング無しで存在しない場合。
iv.AMVP候補リストに動き候補を追加する前に、プルーニングを適用してもよい。
v.5.(3)(4)で述べたのと同様の規則をAMVPモードに適用してもよい。
【0191】
c.現在の参照ピクチャと同一の参照ピクチャを有する動き候補をチェックする。
i.代替的に、現在の参照ピクチャとは異なる参照ピクチャを有する動き候補も(MVスケーリングされた状態で)チェックする。
ii.代替的に、まず、現在の参照ピクチャと同一の参照ピクチャを有するすべての動き候補をチェックし、次に、現在の参照ピクチャとは異なる参照ピクチャを有する動き候補をチェックする。
iii.代替的に、マージした後、動き候補をチェックする。
【0192】
例C4:ルックアップテーブルにおける動き候補のチェック順序は、以下のように規定される(K(K>=1)個の動き候補をチェックすることができるとする):
a.ルックアップテーブルにおける最後のK個の動き候補は、例えば、LUTへのエントリインデックスの降順に配列される。
b.最初のK%L個の候補。Lは、K>=Lである場合のルックアップテーブルのサイズであり、例えば、LUTへのエントリインデックスの降順に配列される。
c.K>=Lである場合、順番に基づいて、ルックアップテーブルにおけるすべての候補(L個の候補)。一例において、テーブルにおける最初のK%L個の候補を、LUTへのエントリインデックスの降順にチェックし、次に、エントリインデックスの降順に最後の(L-K%L)個の候補をチェックする。
【0193】
d.代替的に、さらに、動き候補指標の降順に基づく。
e.代替的に、動き候補指標の昇順に基づいてもよい。
f.代替的に、動き候補に関連付けられた位置の距離や現在のブロックなどの候補情報に基づいて、K個の動き候補を選択する。
i.一例において、K個の最も近い動き候補を選択する。
ii.一例において、候補情報は、距離を算出する際に、ブロックの形状をさらに考慮してもよい。
【0194】
g.一例において、L個の候補を含むテーブルからの動き候補のKのチェック順序は、次のように規定されてもよい:a0、a0+T0、a0+T0+T1、a0+T0+T1+T2、...a0+T0+T1+T2+...+TK-1のインデックスを持つ候補を順に選択し、a0とTi(iは0...K-1である)が整数値である。
i.一例において、a0は、0(すなわち、テーブルにおける動き候補の最初のエントリに設定される)。代替的に、a0を(K-L/K)に設定する。演算「/」は、結果をゼロに切り捨てる整数除算として規定される。代替的に、a0は、0とL/Kとの間の任意の整数に設定される。
1.代替的に、a0の値は、現在のブロックおよび近傍ブロックのコーディング情報に依存してもよい。
ii.一例において、すべての間隔Ti(iは0...K-1である)は同じであり、例えばL/Kである。演算「/」は、結果をゼロに切り捨てる整数除算として規定される。
iii.一例において、(K,L,a0,Ti)は、(4,16,0,4)、または(4,12,0,3)、または(4,8,0,1)、または(4,16,3,4)、または(4,12,2,3)、または(4,8,1,2)に設定される。Tiはすべてのiについて同じである。
iv.このような方法は、KがLよりも小さい場合にのみ適用されてもよい。
v.代替的に、さらに、Kが閾値以上である場合、7.c.部を適用してもよい。この閾値は、Lとして規定されてもよく、またはKに依存してもよく、またはブロックごとに適応的に変更されてもよい。一例において、閾値は、ルックアップテーブルから新しい動き候補を追加する前のリストにおける利用可能な動き候補の数に依存してもよい。
【0195】
h.一例において、L個の候補を含むテーブルからの動き候補のKのチェック順序は、次のように規定されてもよい:a0、a0-T0、a0-T0-T1、a0-T0-T1-T2、...a0-T0-T1-T2-...-TK-1のインデックスを持つ候補を
順に選択し、a0とTi(iは0...K-1である)が整数値である。
i.一例において、a0は、L-1(すなわち、テーブルにおける動き候補の最後のエントリ)に設定される。代替的に、a0は、L-1-L/KとL-1との間の任意の整数に設定される。
ii.一例において、すべての間隔Ti(iは0...K-1である)は同じであり、例えばL/Kである。
iii.一例において、(K,L,a0,Ti)は、(4,16,L-1,4)、または(4,12,L-1,3)、または(4,8,L-1,1)、または(4,16,L-4,4)、または(4,12,L-3,3)、または(4,8,L-2,2)に設定される。Tiはすべてのiについて同じである。
iv.このような方法は、KがLよりも小さい場合にのみ適用されてもよい。
代替的に、さらに、Kが閾値以上である場合、7.c.部を適用してもよい。この閾値は、Lとして規定されてもよく、またはKに依存してもよく、またはブロックごとに適応的に変更されてもよい。一例において、閾値は、ルックアップテーブルから新しい動き候補を追加する前のリストにおける利用可能な動き候補の数に依存してもよい。
【0196】
i.ルックテーブルから動き候補を選択する数および/または方法は、コーディングされた情報、例えばブロックサイズ/ブロック形状に依存してもよい。
i.一例において、より小さいブロックサイズの場合、最後のK個の動き候補を選択する代わりに、(最後から始まらない)他のK個の動き候補を選択してもよい。
ii.一例において、コーディングされた情報は、AMVPモードであってもよいし、マージモードであってもよい。
iii.一例において、コーディングされた情報は、アフィンモードまたは非アフィンAMVPモードまたは非アフィンマージモードであってもよい。
iv.一例において、コーディングされた情報は、アフィンAMVP(インター)モードであっても、アフィンマージモードであっても、非アフィンAMVPモードであっても、または非アフィンマージモードであってもよい。
v.一例において、コーディングされた情報は、現在のピクチャ参照CPR(Current Picture Reference)モードであってもよいし、CPRモードでなくてもよい。
vi.代替的に、ルックアップテーブルから動き候補を選択する方法は、ルックアップテーブルにおける動き候補の数、および/または、ルックアップテーブルから新しい動き候補を追加する前のリストにおける利用可能な動き候補の数にさらに依存してよい。
【0197】
j.一例において、チェック対象のルックアップテーブル内の利用可能な動き候補の最大数(すなわち、マージ/AMVP候補リストに追加されてもよい)は、ルックアップテーブル内の利用可能な動き候補の数(NavaiMCinLUTによって示される)、および/または追加対象の最大許容動き候補の数(NUMmaxMCによって示される)(これは、予め規定されていてもよいし、信号通知されていてもよい)、および/またはルックアップテーブルからの候補をチェックする前の候補リスト内の利用可能な動き候補の数(NavaiCによって示される)に依存していてもよい。
i.一例において、チェック対象のルックアップテーブルにおける動き候補の最大数は、(NavaiMCinLUT,NUMmaxMC,NavaiC)の最小値に設定される。
ii.代替的に、チェック対象のルックアップテーブルにおける動き候補の最大数は、(NavaiMCinLUT,NUMmaxMC-NavaiC)の最小値に設定される。
iii.一例において、NavaiCは、空間的または時間的(隣接および/または
非隣接)な近傍のブロックから導出された挿入候補の数を示す。代替的に、サブブロック候補(AMTVP、STMVPなど)の数は、NavaiCに含まれていない。
iv.NUMmaxMCは、コーディングされたモード例えば、マージモードおよびAMVPモードに依存してもよく、NUMmaxMCは異なる値に設定されてもよい。一例において、マージモードの場合、NUMmaxMCは、4、6、8、10等に設定してもよく、AMVPモードの場合、NUMmaxMCは、1、2、4などに設定してもよい。
v.代替的に、NUMmaxMCは、ブロックサイズ、ブロック形状、スライスタイプ等のような他のコーディングされた情報に依存してもよい。
【0198】
k.異なるルックアップテーブルのチェック順序は、次のサブセクションのルックアップテーブルの使用法で規定されている。
l.一旦、マージ/AMVP候補リストが最大許容候補数に達すると、このチェック処理は終了する。
m.一旦、マージ/AMVP候補リストが、最大許容候補数から閾値(Th)を減算した値に達すると、このチェック処理は終了する。一例において、Thは、例えば、1、2、または3など、正の整数値として予め規定されてもよい。代替的に、Thは、ブロックごとに適応的に変更されてもよい。代替的に、Thは、SPS/PPS/スライスヘッダ等において信号通知されてもよい。代替的に、Thは、さらに、ブロック形状/ブロックサイズ/コーディングされたモードなどに依存してもよい。代替的に、Thは、LUTからの動き候補を追加する前の利用可能な候補の数に依存してもよい。
n.代替的に、追加された動き候補の数が最大許容動き候補数に達すると、終了する。最大許容動き候補数は、信号通知されてもよく、または予め規定されてもよい。代替的に、最大許容動き候補数は、ブロック形状/ブロックサイズ/コーディングされたモード等にさらに依存してもよい。
o.テーブルサイズを示す1つのシンタックス要素ならびにチェック対象の動き候補の数(すなわち、K=L)は、SPS、PPS、スライスヘッダ、タイルヘッダにおいて信号通知してもよい。
【0199】
例C5:1つのブロックの動き情報コーディングのためのルックアップテーブルの使用の有効/無効は、SPS、PPS、スライスヘッダ、タイルヘッダ、CTU、CTB、CU、またはPU、複数のCTU/CTB/CU/PUを含む領域において信号通知されてもよい。
【0200】
例C6:ルックアップテーブルからの予測を適用するかどうかは、さらにコーディングされた情報に依存してもよい。ブロックに適用しないと推測される場合、予測の指示の追加の信号通知はスキップされる。代替的に、ブロックに適用しないと推測される場合、ルックアップテーブルの動き候補にアクセスする必要はなく、関連する動き候補のチェックは省略される。
a.ルックアップテーブルからの予測を適用するかどうかは、ブロックサイズ/ブロック形状に依存してもよい。一例において、より小さなブロック、例えば、4TB、CU、またはPU、複数のCTU/CTB/CU/PUを含む領域において信号通知されてもよい。もよい。
b.ルックアップテーブルからの予測を適用するかどうかは、ブロックがAMVPモードでコーディングされているかマージモードでコーディングされているかに依存してもよい。一例において、AMVPモードの場合、ルックアップテーブルからの予測を行うことは許可されない。
c.ルックアップテーブルからの予測を適用するかどうかは、ブロックがアフィンの動きまたは他の種類の動き(例えば、並進的な動き)でコーディングされるかどうかに依存してもよい。一例において、アフィンモードの場合、ルックアップテーブルからの予測を行うことは許可されない。
【0201】
例C7:以前コーディングされたフレーム/スライス/タイルにおけるルックアップテーブルの動き候補を使用して、異なるフレーム/スライス/タイルにおけるブロックの動き情報を予測してもよい。
a.一例において、現在のブロックの参照ピクチャに関連付けられたルックアップテーブルのみを、現在のブロックをコーディングするために利用してもよい。
b.一例において、現在のブロックをコーディングするために、現在のブロックの同じスライスタイプおよび/または同じ量子化パラメータを有するピクチャに関連付けられたルックアップテーブルのみを利用してもよい。
【0202】
ルックアップテーブルの更新
【0203】
例D1:動き情報を有するブロックをコーディングした後(すなわち、IntraBCモード、インター符号化モード)に、1つ以上のルックアップテーブルを更新してもよい。
a.一例において、ルックアップテーブルを更新するかどうかは、ルックアップテーブルを選択する規則を再利用してもよく、例えば、現在のブロックを符号化/復号化するためにルックアップテーブルを選択することができる場合、ブロックを符号化/復号化した後、選択されたルックアップテーブルをさらに更新してもよい。
b.更新されるべきルックアップテーブルは、コーディングされた情報および/またはブロック/LCUの位置に基づいて選択されてもよい。
【0204】
c.ブロックが直接信号通知された動き情報でコーディングされる場合(例えば、AMVPモード、通常/アフィンインターモードのMMVDモード、通常/アフィンインターモードのAMVRモード)、ブロックの動き情報をルックアップテーブルに加えることができる。
i.代替的に、ブロックが、いかなる改良も伴わずに、空間的に近傍のブロックから直接継承された動き情報でコーディングされる場合(例えば、改良を伴わない空間的マージ候補)、ブロックの動き情報をルックアップテーブルに加えるべきではない。
ii.代替的に、ブロックが、改良を行って、空間的に近傍のブロックから直接継承された動き情報でコーディングされる場合(DMVR、FRUCなど)、ブロックの動き情報をいかなるルックアップテーブルにも加えるべきではない。
iii.代替的に、ブロックが、ルックアップテーブルに記憶された動き候補から直接継承された動き情報でコーディングされている場合は、ブロックの動き情報は、いかなるルックアップテーブルにも加えるべきではない。
iv.一例において、このような動き情報は、テーブルの最後のエントリまたは次の利用可能な動き候補を記憶するために用いられるエントリ等のように、ルックアップテーブルに直接加えられてもよい。
v.代替的に、このような動き情報は、プルーニングせずに、例えば、いかなるプルーニングもせずに、ルックアップテーブルに直接加えられてもよい。
vi.代替的に、このような動き情報は、ルックアップテーブルを再配列するために使用してもよい。
vii.代替的に、このような動き情報は、プルーニングが制限された状態で(例えば、ルックアップテーブルにおける最新のものと比較して)ルックアップテーブルを更新するために使用してもよい。
【0205】
d.ブロック内のM個の代表位置が選択され、その代表と関連付けられた動き情報がルックアップテーブルの更新に用いられる。
i.一例において、代表位置は、ブロック内の4つのコーナー位置(例えば、
図26のC0~C3)のうちの1つとして規定される。
ii.一例において、代表位置は、ブロック内の中心位置(例えば、
図26におけるCa~Cd)として規定される。
iii.ブロックに対してサブブロック予測が許可されない場合、Mは1に設定される。
iv.サブブロック予測がブロックに対して許可される場合、Mは、1、またはサブブロックの総数、または[1とサブブロックの数]の間の一意の値に排他的に設定され得る。
v.代替的に、ブロックのためにサブブロック予測を許可する場合、Mを1に設定することができ、代表的なサブブロックの選択は、以下に基づいて行われる。
1.利用される動き情報の頻度
2.双方向予測ブロックであるか否か
3.参照ピクチャインデックス/参照ピクチャに基づいて
4.他の動きベクトルと比較した動きベクトルの差(例えば、最大MV差を選択する)
5.他のコーディングされた情報
【0206】
e.M(M>=1)個の代表位置のセットを選択してルックアップテーブルを更新する場合、これらを更なる動き候補としてルックアップテーブルに加える前に、更なる条件がチェックされてもよい。
i.ルックアップテーブルにおける既存の動き候補に対して、新たな動き情報のセットをプルーニングしてもよい。
ii.一例において、動き情報の新しいセットは、ルックアップテーブルにおける既存の動き候補のいずれかまたは一部と同一であってはならない。
iii.代替的に、動き情報の新しいセットおよび1つの既存の動き候補からの同じ参照ピクチャの場合、MV差は、1/複数の閾値よりも小さくならないようにすべきである。例えば、MV差の水平および/または垂直モジュールは、1ピクセルの距離よりも大きくなければならない。
iv.代替的に、K>Lである場合、動き情報の新しいセットを、最後のK個の候補または最初のK%L個の既存の動き候補によってのみプルーニングし、古い動き候補を再びアクティブにすることができるようにする。
v.代替的に、プルーニングは適用しない。
【0207】
f.動き情報のMのセットがルックアップテーブルを更新するために用いられる場合、対応するカウンタをMだけ増加させるべきである。
g.更新対象のルックアップテーブルのカウンタをKとし、現在のブロックをコーディングする前に、(上記の方法で)選択された動き情報の1つのセットに対して、このブロックをコーディングした後、これを、K%Lに等しいインデックスを有する追加の動き候補として加える(ここで、Lはルックアップテーブルのサイズである)。その例を
図27Aおよび
図27Bに示す。
i.代替的に、それは、min(K+1,L-1)に等しいインデックスを有する追加の動き候補として追加される。代替的に、更に、K≧Lである場合、第1の動き候補(インデックスが0)をルックアップテーブルから取り除き、後続のK個の候補インデックスを1だけ減らす。
ii.上記両方の方法(K%Lに等しいエントリインデックスに新しい動き候補を加えるか、またはmin(K+1,L+1)に等しいインデックスを加える)の場合、同じ/類似した動き候補が存在するかどうかに関わらず、それらは、前のコーディングされたブロックからの動き情報の最新の数セットを維持しようとしている。
iii.代替的に、動き情報の新しいセットを動き候補としてLUTに追加する場合、まず冗長性チェックを行う。この場合、LUTは以前のコーディングされたブロックからの動き情報の最新のいくつかのセットを保持するが、LUTから冗長な動き情報を除去してもよい。このような方法を、冗長性除去型LUT更新方法(redundancy-removal based LUT updating method)と呼ぶ。
1.LUTに重複した動き候補が存在する場合、LUTに関連付けられたカウンタを増加させなくてもよいし、減少させてもよい。
2.この冗長チェックは、例えば、参照ピクチャ/参照ピクチャのインデックスが同じか否か、および、動きベクトルの差が範囲内にあるかまたは同一であるかをチェックすることなど、マージ候補リスト構築処理におけるプルーニング処理として規定されてもよい。
3.LUT内に冗長動き候補が見つかった場合、その冗長動き候補を現在の位置から最後のLUTに移動させる。
a.同様に、LUT内に冗長動き候補が見つかった場合、この冗長動き候補をLUTから取り除く。また、冗長動き候補の後にLUTに挿入されたすべての動き候補は、前方に移動し、除去された冗長動き候補のエントリを再び満たす。シフトした後、新しい動き候補をLUTに加える。
b.この場合、カウンタは変更されないままである。
c.LUTにおいて冗長動き候補を特定した後、冗長チェック処理を終了する。
4.複数の冗長動き候補を特定することができる。この場合、それらのすべてをLUTから削除する。また、残りの動き候補は、すべて順に前方に移動してもよい。
a.この場合、カウンタを(冗長動き候補の数-1)にて減少させる。
b.maxR個の冗長動き候補(maxRは正の整数の変数)を特定した後、冗長チェック処理を終了する。
5.冗長性チェック処理は、1つ目の動き候補から最後の動き候補まで(すなわち、LUTに付加された順に、動き情報のあるブロックの復号化処理の順に)行うことができる。
6.代替的に、LUTに冗長動き候補がある場合、冗長なものを1つまたは複数個取り除く代わりに、冗長なものから仮想動き候補を導出してもよく、この仮想動き候補を使用して冗長なものを置き換えてもよい。
a.仮想動き候補は、1つ以上の動きベクトルの水平および/または垂直の構成要素にオフセットを加えることで、または同じ参照ピクチャを指している場合には2つの動きベクトルの平均値を加えることで、冗長動き候補から導出されてもよい。代替的に、仮想動き候補は、ルックアップテーブルにおける動きベクトルを入力とする任意の関数から導出されてもよい。例示的な関数は以下の通りである。2つまたは複数の動きベクトルを足し合わせること。2つまたは複数の動きベクトルを平均すること。動きベクトルは、関数に入力される前にスケーリングされてもよい。
b.冗長動き候補と同じ位置に仮想動き候補を加えてもよい。
c.他のすべての動き候補の前に、仮想動き候補を追加してもよい(例えば、最小のエントリインデックス、例えば、ゼロから始まる)。
d.一例において、現在のLUTに空きがある場合など、特定の条件下でのみ適用される。
7.冗長性除去に基づくLUT更新方法は、以下のような特定の条件下で呼び出されてもよい。
a.現在のブロックはマージモードでコーディングされている。
b.現在のブロックはAMVPモードでコーディングされているが、MV差の少なくとも1つの構成要素が非ゼロである。
c.現在のブロックがサブブロックベースの動き予測/動き補償方法でコーディングされているか、またはコーディングされていない(例えば、アフィンモードでコーディングされていない)。
d.現在のブロックはマージモードでコーディングされ、動き情報はあるタイプ(例えば、空間的に近傍のブロックから、左の近傍のブロックから、時間的ブロックから)に関連付けられている。
【0208】
h.1つのブロックを符号化/復号化した後、1つ以上のルックアップテーブルは、動き情報のM個のセットをテーブルの末端に挿入するだけで、すなわち、既存の候補のすべての後に、更新されてもよい。
i.代替的に、さらに、テーブルにおける既存の動き候補をいくつか削除してもよい。
1.一例において、動き情報のM個のセットを挿入した後、テーブルが一杯である場合、動き候補の最初のいくつかのエントリをテーブルから削除してよい。
2.一例において、動き情報のM個のセットを挿入する前にテーブルに一杯である場合、動き候補の最初のいくつかのエントリをテーブルから削除してよい。
ii.代替的に、さらに、ブロックがテーブルからの動き候補でコーディングされている場合、選択された動き候補をテーブルの最後のエントリに入れるように、テーブルにおける動き候補を再配列してもよい。
【0209】
i.1つの例において、ブロックを符号化/復号化する前に、ルックアップテーブルには、HMVP0、HMVP1、HMVP2、...、HMVPK-1、HMVPK、HMVPK+1、...、HMVPL-1で示される動き候補が含まれていてもよく、HMVPiはルックアップテーブルのi番目のエントリを示す。ブロックがHMVPKから予測されている場合(Kが包含的に[0,L-1]の範囲内にある場合)、このブロックを符号化/復号化した後、ルックアップテーブルは、HMVP0、HMVP1、HMVP2、...、HMVPK-1、HMVPK、HMVPK+1、...、HMVPL-1、HMVPKにて再配列される。
【0210】
j.1つのイントラ制約ブロックをコーディングした後、ルックアップテーブルを空にしてもよい。
k.動き情報のエントリをルックアップテーブルに追加する場合、動き情報からの導出によって、動き情報のより多くのエントリをテーブルに追加してもよい。この場合、ルックアップテーブルに関連付けられたカウンタを1より大きい数だけ増加させることができる。
i.一例において、動き情報のエントリのMVは、スケーリングされ、テーブルに入れられる。
ii.一例において、動き情報のエントリのMVは、(dx,dy)だけ加算され、テーブルに入れられる。
iii.一例において、動き情報の2つ以上のエントリのMVの平均が計算され、テーブルに入れられる。
【0211】
例D2:1つのブロックが1つのピクチャ/スライス/タイルの境界に位置する場合、ルックアップテーブルの更新は常に許可されない。
【0212】
例D3:現在のLCU行をコーディングするために、上側のLCU行の動き情報を無効にしてもよい。
a.この場合、新しいスライス/タイル/LCU行の始まりにおいて、利用可能な動き候補の数を0にリセットしてよい。
【0213】
例D4:新しい時間層インデックスを使用してスライス/タイルをコーディングする開始時に、利用可能な動き候補の数を0にリセットしてよい。
【0214】
例D5:ルックアップテーブルは、同じ時間層インデックスを有する1つのスライス/タイル/LCUの行/スライスで連続的に更新されてもよい。
a.代替的に、ルックアップテーブルは、各S(S層インデックスを/CTB/CU/CBを符号化/復号化した後、または特定の領域(例えば、8クスを有する1つのスライス/タイル/LCUの行/スライスで連続的に更新されてもよい。
b.代替的に、ルックアップテーブルは、特定のモード(例えば、S個のインター符号化ブロック)を有する各S(Sライスで連続的に更新されてもよい。候補を再配列して復号化した後にのみ更新されてもよい。代替的に、ルックアップテーブルは、サブブロックに基づく動き予測/動き補償方法でコーディングされていない(例えば、アフィンおよび/またはATMVPモードでコーディングされていない)各S(S>=1)個のインター符号化ブロック(例えば、CU/CB)を符号化/復号化した後にのみ更新されてもよい。
c.代替的に、符号化/復号化されたブロックの左上座標が何らかの条件を満たす場合にのみ、ルックアップテーブルを更新してもよい。例えば、ルックアップテーブルは、(x&M==0)&&(y&M==0)の場合にのみ更新され、ここで、(x,y)は、符号化/復号化されたブロックの左上座標である。Mは、2、4、8、16、32、または64などの整数である。
d.代替的に、1つのルックアップテーブルは、最大許容カウンタに達すると、更新を停止してもよい。
e.一例において、カウンタは予め規定されてもよい。代替的に、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Paramter Set)、スライスヘッダ、タイルヘッダ、CTU(Coding Tree Unit)、CTB(Coding Tree Block)、CU(Coding Unit)またはPU(Prediction Unit)、複数のCTU/CTB/CU/PUをカバーする領域で信号通知される。
【0215】
例D6:ルックアップテーブル更新プロセスは、異なる手順内で呼び出されてもよい。
a.一例において、マージモードでコーディングされたブロックの場合、ルックアップテーブル更新プロセスは、マージ候補を復号化した後であってもよいし、マージリストを構築した後であってもよく、または動き情報を改良して、および/または改良せずに復号化した後であってもよい。
b.一例において、AMVPでコーディングされたブロックの場合、ルックアップテーブル更新プロセスは、動き情報を改良して、および/または改良せずに復号化した後であってもよい。
c.ルックアップテーブルをいつおよび/またはどのように更新するかは、コーディングされたモード、ブロック寸法、映像処理データユニット、低遅延チェック等に依存してよい。
i.一例において、1つのブロックがAMVPモードでコーディングされる場合、プルーニングせずに、ルックアップテーブルを直接更新してもよい。
ii.代替的に、1つのブロックがマージモードでコーディングされる場合、プルーニングによってルックアップテーブルを更新してもよい。
iii.代替的に、1つのブロックがマージモードでコーディングされ、その動き情報が空間的ブロックおよび/または時間的ブロックから導出される場合、ルックアップテーブルはプルーニングによって更新されてもよい。
iv.代替的に、1つのブロックがマージモードでコーディングされ、その動き情報がルックアップテーブルにおける動き候補から導出される場合、プルーニングせずにルックアップテーブルを再配列してもよい。
v.代替的に、1つのブロックがマージモードでコーディングされ、その動き情報がルックアップテーブルにおける仮想候補(例えば、組み合わされたバイ、ペア、ゼロ動きベクトル候補)から導出される場合、ルックアップテーブルは更新されなくてもよい。
vi.代替的に、1つのブロックがサブブロックマージモードおよび/または三角形マージモードでコーディングされる場合、ルックアップテーブルは更新されなくてもよい。
vii.代替的に、1つのブロックがMMVD(Merge with Motion Vector Differences)モードでコーディングされ、その動き情報が空間的ブロックおよび/または時間的ブロックから導出される場合、ルックアップテーブルを直接更新してもよい。
viii.一例において、1つのブロックが、照明補償(IC:Illumination Compensarion)モードおよび/またはOBMC(Overlapped Block Motion Compensation)モードおよび/またはDMVD(Decode-side Motion Vector Derivation)モードでコーディングされる場合、ルックアップテーブルは、更新されなくてもよい。代替的に、このようなモードで1つのブロックをコーディングする場合、ルックアップテーブルを更新してもよい。
【0216】
追加の例示的な実施形態
【0217】
HMVP(Histry-based MVP)方法が提案され、HMVP候補は、以前にコーディングされたブロックの動き情報として規定される。符号化/復号化処理中、複数のHMVP候補を有するテーブルが維持される。新しいスライスに遭遇した場合、テーブルは空になる。インター符号化されたブロックがあるときはいつでも、関連する動き情報を新しいHMVP候補としてテーブルの最後のエントリに加える。全体のコーディングフローを
図31に示す。
【0218】
一例において、テーブルサイズはL(例えば、L=16または6、または44)に設定され、これは、最大L個のHMVP候補をテーブルに追加することができることを示す。
【0219】
(例11.g.iに対応する)1つの実施形態において、以前にコーディングされたブロックからのL個よりも多いHMVP候補が存在する場合、テーブルが常に最新の以前にコーディングされたL個の動き候補を含むように、FIFO(First-In-First-Out)規則が適用される。
図32は、FIFO規則を適用してHMVP候補を除去し、提案される方法で使用されるテーブルに新しいものを追加する例を示す。
【0220】
(発明11.g.iiiに対応する)別の実施形態において、新しい動き候補を追加するときはいつでも(例えば、現在のブロックがインター符号化され、非アフィンモードであるなど)、まず、冗長性チェック処理を適用し、LUTに同じまたは類似した動き候補があるかどうかを識別する。
【0221】
いくつかの例を以下に示す。
【0222】
図33Aは、新しい動き候補を追加する前に、LUTに空きがない場合の例を示す。
【0223】
図33Bは、新しい動き候補を追加する前に、LUTに空きがある場合の例を示す。
【0224】
図33Aおよび
図33Bは、ともに、冗長性除去に基づくLUT更新方法(1つの冗長性動き候補を除去する)の例を示す。
【0225】
図34Aおよび
図34Bは、冗長性除去に基づくLUT更新方法(複数の冗長性動き候補を除去する、図では2つの候補を示す)の2つの場合の例示の実装形態を示す。
【0226】
図34Aは、新しい動き候補を追加する前に、LUTに空きがない場合の例を示す。
【0227】
図34Bは、新しい動き候補を追加する前に、LUTに空きがある場合の例を示す。
【0228】
HMVP候補は、マージ候補リスト構築処理において使用され得る。TMVP候補の後に、テーブルにおける最後のエントリから最初のエントリ(または、最後のK0個のHMVP、例えば、K0=16または6)までのすべてのHMVP候補を挿入する。HMVP候補に対してプルーニングを適用する。利用可能なマージ候補の総数が信号通知された最大許容マージ候補に達すると、マージ候補リスト構築処理を終了する。代替的に、追加された動き候補の総数が、所与の値に達すると、LUTからの動き候補のフェッチを終了する。
【0229】
同様に、HMVP候補は、AMVP候補リスト構築処理において使用されてもよい。TMVP候補の後に、テーブルにおける最後のK1個のHMVP候補の動きベクトルを挿入する。AMVP対象参照ピクチャと同じ参照ピクチャを有するHMVP候補のみを用いて、AMVP候補リストを構築する。HMVP候補に対してプルーニングを適用する。一例において、K1は4に設定される。
【0230】
参考文献
[1]“Overview of the High Efficiency Video Coding (HEVC) Standard”, Gary J.Sullivan, Jens-Rainer Ohm, Woo-Jin Han, and Thomas Wiegand, IEEE Transactions on Circuits and Systems for Video Technology, Vol.22, No.12, December 2012.
[2]“Overview of the H.264/AVC video coding standard”, Ajay Luthra, Pankaj Topiwala, Proceedings of SPIE Vol.5203 Applications of Digital Image Processing XXVI.
[3]J.Chen, E.Alshina, G.J.Sullivan, J.-R.Ohm, J.Boyce, “Algorithm description of Joint Exploration Test Model 7 (JEM7),” JVET-G1001, Aug.2017.
[4]JEM-7.0: https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/ HM-16.6-JEM-7.0.
[5]H.265/HEVC, https://www.itu.int/rec/T-REC-H.265
[6]“Multi-Type-Tree”, JVET-D0117
[7]国際公開公報WO2016/091161号明細書
[8]“Description of SDR, HDR and 360° video coding technology proposal by Qualcomm and Technicolor - low and high complexity versions”, JVET-J0021.
【0231】
図28Aは、映像処理装置2800のブロック図である。本明細書に記載の方法の1つ以上を実装するために、装置2800を使用してもよい。装置2800は、スマートフォン、タブレット、コンピュータ、IoT(Internet of Things)受信機等に実施されてもよい。装置2800は、1または複数の処理装置2802と、1または複数のメモリ2804と、映像処理ハードウェア2806と、を含んでもよい。プロセッサ2802は、本明細書に記載される1つ以上の方法を実装するように構成されてもよい。メモリ(複数可)2804は、本明細書で説明される方法及び技術を実装するために使用されるデータ及びコードを記憶するために使用してもよい。映像処理ハードウェア2806は、本明細書に記載される技術をハードウェア回路にて実装するために使用されてもよい。
【0232】
図28Bは、開示される技術が実施され得る映像処理システムのブロック図の別の例である。
図28Bは、本明細書で開示される様々な技術が実装され得る例示的な映像処理システム3100を示すブロック図である。様々な実装形態は、システム3100の構成要素の一部または全部を含んでもよい。システム3100は、映像コンテンツを受信するための入力ユニット3102を含んでもよい。映像コンテンツは、未加工または非圧縮フォーマット、例えば、8または10ビットのマルチコンポーネントの画素値で受信されてもよく、または圧縮または符号化のフォーマットで受信されてもよい。入力ユニット3102は、ネットワークインターフェース、周辺バスインターフェース、または記憶インターフェースを表してもよい。ネットワークインターフェースの例としては、イーサネット(登録商標)、PON(Passive Optical Network)等の有線インターフェース、及びWi-Fi(登録商標)またはセルラーインターフェース等の無線インターフェースが挙げられる。
【0233】
システム3100は、本明細書に記載される様々なコーディングまたは符号化方法を実装することができるコーディングコンポーネント3104を含んでもよい。コーディングコンポーネント3104は、入力3102からの映像の平均ビットレートをコーディングコンポーネント3104の出力に低減し、映像のコーディング表現を生成してもよい。従って、このコーディング技術は、映像圧縮または映像コード変換技術と呼ばれることがある。コーディングコンポーネント3104の出力は、コンポーネント3106によって表されるように、記憶されてもよいし、接続された通信を介して送信されてもよい。入力3102において受信された、記憶されたまたは通信された映像のビットストリーム(またはコーディングされた)表現は、コンポーネント3108によって使用され、表示インターフェース3110に送信される画素値または表示可能な映像を生成してもよい。ビットストリーム表現からユーザが見ることができる映像を生成する処理は、映像展開と呼ばれることがある。さらに、特定の映像処理動作を「コーディング(coding)」動作またはツールと呼ぶが、コーディングツールまたは動作はエンコーダによって用いられ、それに対応する、復号化の結果を逆にする復号化ツールまたは動作がデコーダによって行われることが理解されよう。
【0234】
周辺バスインターフェースユニットまたは表示インターフェースユニットの例は、USB(Universal Serial Bus)またはHDMI(High Definition Multimedia Interface)(登録商標)またはディスプレイポート等を含んでもよい。ストレージインターフェースの例は、SATA(Serial Advanced Technology Attachment)、PCI、IDEインターフェース等を含む。本明細書に記載される技術は、携帯電話、ノートパソコン、スマートフォン、またはデジタルデータ処理および/または映像表示を実施可能な他のデバイス等の様々な電子デバイスに実施されてもよい。
【0235】
いくつかの実施形態において、映像コーディング方法は、
図28Aまたは
図28Bを参照して説明したように、ハードウェアプラットフォームに実装される装置を使用して実施されてもよい。
【0236】
図29は、映像処理方法2900の一例のフローチャートである。方法2900は、ステップ2902において、1または複数の動き候補テーブルを維持することを含む。方法2900は、ステップ2904において、動き候補テーブルを用いたシーケンスにおける複数の映像処理動作を用いて、現在の映像ブロックと現在の映像ブロックのコーディングされた表現とを変換することをさらに含む。方法2900は、ステップ2906において、特定の処理動作が完了したことに起因して動き候補テーブルを更新することをさらに含む。
【0237】
図30は、映像処理方法3000の一例のフローチャートである。方法3000は、ステップ3002において、1つ以上の動き候補テーブルを維持することを含む。方法3000は、ステップ3004において、コーディングモード、寸法、映像処理データユニットまたは低遅延チェックを含む現在の映像ブロックの特徴に基づいて、i)動き候補テーブルの動き候補テーブルを更新するかどうか、またはii)動き候補テーブルをどのように更新するかの少なくとも一方を判定することを更に含む。方法3000は、さらに、ステップ3006において、判定に基づいて、映像の現在の映像ブロックと、映像のコーディングされた表現との間で変換を行うことと、を含む。
【0238】
方法2900および3000に対して、いくつかの実施形態において、動き情報は、予測方向、参照ピクチャインデックス、動きベクトル値、強度補償フラグ、アフィンフラグ、動きベクトル差精度または動きベクトル差分値のうち少なくとも1つを含む。さらに、動き情報は、動き情報がどこから来ているかを示すために、ブロック位置情報をさらに含んでもよい。いくつかの実施形態において、映像ブロックはCUまたはPUであり、映像の一部は1または複数の映像スライスまたは1または複数の映像ピクチャに対応することができる。
【0239】
いくつかの実施形態において、各LUTは、関連するカウンタを含み、このカウンタは、この映像のこの部分の最初においてゼロ値に初期化され、この映像のこの部分における各符号化された映像領域ごとに増加される。この映像領域は、コーディングツリーユニット、コーディングツリーブロック、コーディングユニット、コーディングブロック、または予測ユニットのうちの1つを含む。いくつかの実施形態において、カウンタは、対応するLUTに対して、該当するLUTから除去された動き候補の数を示す。いくつかの実施形態において、動き候補のセットはすべてのLUTに対して同じサイズを有していてもよい。いくつかの実施形態において、映像の一部は1つの映像スライスに対応し、LUTの数はN*Pに等しく、Nは1つの復号化スレッド当たりのLUTを表す整数であり、Pは1つの映像スライスにおける最大コーディングユニットの行の数またはタイルの数を表す整数である。方法2900および3000のさらなる詳細は、第4章に提供される実施例および以下に列挙される実施例に記載される。
【0240】
1.1つまたは複数の動き候補テーブルを維持することと、動き候補テーブルを用いたシーケンスにおける複数の映像処理動作を用いて、映像の現在の映像ブロックと前記現在の映像ブロックのコーディングされた表現との間の変換を実行することと、特定の処理動作が完了したことに起因して前記動き候補テーブルを更新すること、とを含む映像処理方法。
【0241】
2.特定の処理動作の同一性は、前記現在の映像ブロックのコーディング特性に依存する、例1に記載の方法。
【0242】
3.現在の映像ブロックはマージモードでコーディングされ、前記動き候補テーブルは、前記変換の一部である以下の動作:
(i)マージ候補の復号化、
(ii)前記マージ候補を含むマージリストの構築、
(iii)改良なしでの動き情報の復号化、または、
(iv)改良ありでの動き情報の復号化、
のうちの少なくとも1つの後に更新される、例1に記載の方法。
【0243】
4.前記現在の映像ブロックはマージモードでコーディングされ、前記動き候補テーブルは、DMVR(Decode-side Motion Vector Refinement)で改良される前に、復号化された動き情報を用いて更新される、例3に記載の方法。
【0244】
5.前記現在の映像ブロックをマージモードでコーディングし、前記動き候補テーブルは、MMVD(Merge with Motion Vector Differences)をマージして改良した後、復号化された動き情報を用いて更新される、例3の方法。
【0245】
6.現在の映像ブロックは、AMVP(Advanced Motion Vector Prediction)モードでコーディングされ、動き情報を改良ありまたは改良なしで復号化した後、動き候補テーブルを更新する、例1の方法。
【0246】
7.1つまたは複数の動き候補テーブルを維持することと、コーディングモード、寸法、映像処理データユニット、または低遅延チェックを含む現在の映像ブロックの特性に基づいて、i)1つまたは複数の動き候補テーブルの1つの動き候補テーブルを更新するかどうか、またはii)動き候補テーブルをどのように更新するかの少なくとも一方を判定することと、前記判定に基づいて、映像の現在の映像ブロックと前記映像のコーディングされた表現との間の変換を実行することとを含む、映像処理方法。
【0247】
8.前記現在の映像ブロックはAMVP(Advanced Motion Vector Prediction)モードでコーディングされ、前記動き候補テーブルは、プルーニングせずに更新される、例7に記載の方法。
【0248】
9.前記現在の映像ブロックはマージモードでコーディングされ、前記動き候補テーブルはプルーニングにより更新される、例7に記載の方法。
【0249】
10.前記プルーニングは、前記現在の映像ブロックに関連付けられた動き情報と、前記動き候補テーブルにおける少なくとも1つの動き候補とを比較することを含む、例8または9に記載の方法。
【0250】
11.前記現在の映像ブロックの動き情報は、空間的ブロックまたは時間的ブロックから導出される、例9に記載の方法。
【0251】
12.前記現在の映像ブロックはマージモードでコーディングされ、前記現在の映像ブロックの動き情報は前記動き候補テーブルにおける動き候補から導出され、前記動き候補テーブルはプルーニングすることなく並べ替えられる、例7に記載の方法。
【0252】
13.前記現在の映像ブロックはマージモードでコーディングされ、前記現在の映像ブロックの動き情報は前記動き候補テーブルにおける仮想候補から導出され、前記動き候補テーブルは更新されない、例7に記載の方法。
【0253】
14.前記現在の映像ブロックはサブブロックマージモードおよび/または三角形マージモードでコーディングされ、前記動き候補テーブルは更新されない、例7に記載の方法。
【0254】
15.現在の映像ブロックはMMVD(Merge withMotion Vector Differences)モードでコーディングされ、前記現在の映像ブロックの動き情報は空間的ブロックまたは時間的ブロックから導出され、前記動き候補テーブルは更新される、例7に記載の方法。
【0255】
16.前記現在の映像ブロックは、照明補償(IC:Illumication Compensation)モード、OBMC(Overlapped Block Motion Compensation)モード、またはDMVD(Decode-side Motion Vector Derivation)モードのうちの1つまたは複数のモードでコーディングされ、前記動き候補テーブルは更新されない、例7に記載の方法。
【0256】
17.前記現在の映像ブロックは、照明補償(IC:Illumication Compensation)モード、OBMC(Overlapped Block Motion Compensation)モード、またはDMVD(Decode-side Motion Vector Derivation)モードのうちの1つまたは複数のモードでコーディングされ、前記動き候補テーブルは更新される、例7に記載の方法。
【0257】
18.前記動き候補テーブルは、HMVP(History Motion Vector Prediction)テーブルである、例1~17のいずれか1つに記載の方法。
【0258】
19.前記変換を実行することは、前記現在の映像ブロックからコーディングされた表現を生成することを含む、例1~18のいずれかに記載の方法。
【0259】
20.前記変換を実行することは、前記コーディングされた表現から前記現在の映像ブロックを生成することを含む、例1~18のいずれかに記載の方法。
【0260】
21.プロセッサと、命令を搭載した非一時的メモリとを備える、映像システムにおける装置であって、前記命令は、前記プロセッサが実行することにより、前記プロセッサに、例1~20のいずれかに記載の前記方法を実行させる、装置。
【0261】
22.非一時的なコンピュータ可読媒体に記憶されたコンピュータプログラム製品であって、例1~20のいずれかに記載の前記方法を実行するためのプログラムコードを含む、コンピュータプログラム製品。
【0262】
以上、説明の目的で本開示の技術の特定の実施形態を説明したが、本発明の範囲から逸脱することなく様々な修正が可能であることは、理解されるであろう。従って、本開示の技術は、添付の特許請求の範囲による場合を除き、限定されない。
【0263】
本明細書に記載され、開示された、および他の実施形態、モジュール、および機能操作は、本明細書に開示された構造およびその構造的等価物を含め、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、若しくはハードウェアで実施されてもよく、またはそれらの1つ以上の組み合わせで実施されてもよい。開示された、および他の実施形態は、1つ以上のコンピュータプログラム製品、すなわち、データ処理装置によって実装されるため、またはデータ処理装置の動作を制御するために、コンピュータ可読媒体上に符号化されたコンピュータプログラム命令の1つ以上のコンポーネントとして実装することができる。このコンピュータ可読媒体は、機械可読記憶デバイス、機械可読記憶基板、メモリデバイス、機械可読伝播信号をもたらす物質の組成物、またはこれらの1つ以上の組み合わせであってもよい。「データ処理装置」という用語は、例えば、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサ若しくはコンピュータを含め、データを処理するためのすべての装置、デバイス、及び機械を含む。この装置は、ハードウェアの他に、当該コンピュータプログラムの実行環境を作るコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの1つ以上の組み合わせを構成するコードを含むことができる。伝播信号は、人工的に生成した信号、例えば、機械で生成した電気、光、または電磁信号であり、適切な受信装置に送信するための情報を符号化するように生成される。
【0264】
コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとも呼ばれる)は、コンパイルされた言語または解釈された言語を含む任意の形式のプログラミング言語で記述することができ、また、それは、スタンドアロンプログラムとして、またはコンピューティング環境で使用するのに適したモジュール、コンポーネント、サブルーチン、または他のユニットとして含む任意の形式で展開することができる。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータを保持するファイルの一部(例えば、マークアップ言語文書に格納された1つ以上のスクリプト)に記録されていてもよいし、当該プログラム専用の単一のファイルに記憶されていてもよいし、複数の調整ファイル(例えば、1つ以上のモジュール、サブプログラム、またはコードの一部を格納するファイル)に記憶されていてもよい。1つのコンピュータプログラムを、1つのサイトに位置する1つのコンピュータ、または複数のサイトに分散され通信ネットワークによって相互接続される複数のコンピュータで実行させるように展開することも可能である。
【0265】
本明細書に記載された処理及びロジックフローは、入力データ上で動作し、出力を生成することによって機能を行うための1つ以上のコンピュータプログラムの変換を行う1つ以上のプログラマブルプロセッサによって行うことができる。処理及びロジックフローはまた、特定用途のロジック回路、例えば、FPGA(Field Programmable Gate Array)またはASIC(Application Specific Intergrated Circuit)によって行うことができ、装置はまた、特定用途のロジック回路として実装することができる。
【0266】
コンピュータプログラムの実行に適したプロセッサは、例えば、汎用及び専用マイクロプロセッサの両方、並びに任意の種類のデジタルコンピュータの任意の1つ以上のプロセッサを含む。一般的に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリまたはその両方から命令及びデータを受信する。コンピュータの本質的な要素は、命令を行うためのプロセッサと、命令及びデータを記憶するための1つ以上のメモリデバイスである。一般的に、コンピュータは、データを記憶するための1つ以上の大容量記憶デバイス、例えば、磁気、光磁気ディスク、または光ディスクを含んでもよく、またはこれらの大容量記憶デバイスからデータを受信するか、またはこれらにデータを転送するように動作可能に結合されてもよい。しかしながら、コンピュータは、このようなデバイスを有する必要はない。コンピュータプログラム命令及びデータを記憶するのに適したコンピュータ可読媒体は、あらゆる形式の不揮発性メモリ、媒体、及びメモリデバイスを含み、例えば、EPROM、EEPROM、フラッシュメモリデバイス、磁気ディスク、例えば内部ハードディスクまたはリムーバブルディスク、光磁気ディスク、及びCD-ROM及びDVD-ROMディスク等の半導体メモリデバイスを含む。プロセッサ及びメモリは、特定用途のロジック回路によって補完されてもよく、または特定用途のロジック回路に組み込まれてもよい。
【0267】
本特許明細書は多くの詳細を含むが、これらは、任意の発明の範囲または特許請求の範囲を限定するものと解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明と解釈されるべきである。本特許明細書において別個の実施形態の文脈で説明されている特定の特徴は、1つの例において組み合わせて実装してもよい。逆に、1つの例の文脈で説明された様々な特徴は、複数の実施形態において別個にまたは任意の適切なサブコンビネーションで実装してもよい。さらに、特徴は、特定の組み合わせで作用するものとして上記に記載され、最初にそのように主張されていてもよいが、主張された組み合わせからの1つ以上の特徴は、場合によっては、組み合わせから抜粋されることができ、主張された組み合わせは、サブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。
【0268】
同様に、動作は図面において特定の順番で示されているが、これは、所望の結果を達成するために、このような動作が示された特定の順番でまたは連続した順番で実行されること、または示された全ての操作が実行されることを必要とするものと理解されるべきではない。また、本特許明細書に記載されている例における様々なシステムモジュールの分離は、全ての実施形態においてこのような分離を必要とするものと理解されるべきではない。
【0269】
いくつかの実装形態及び例のみが記載されており、本特許明細書に記載され図示されている内容に基づいて、他の実施形態、拡張及び変形が可能である。