特許 7578330 適応カーネルオプションを用いた二次変換の方法および装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-28

(45)【発行日】2024-11-06

(54)【発明の名称】適応カーネルオプションを用いた二次変換の方法および装置

(51)【国際特許分類】

   H04N 19/12 20140101AFI20241029BHJP

   H04N 19/136 20140101ALI20241029BHJP

   H04N 19/159 20140101ALI20241029BHJP

   H04N 19/176 20140101ALI20241029BHJP

   H04N 19/61 20140101ALI20241029BHJP

【ＦＩ】

H04N19/12

H04N19/136

H04N19/159

H04N19/176

H04N19/61

【請求項の数】 20

(21)【出願番号】P 2023528040

(86)(22)【出願日】2022-08-29

(65)【公表番号】

(43)【公表日】2023-11-29

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

(87)【国際公開番号】W WO2023034225

(87)【国際公開日】2023-03-09

【審査請求日】2023-05-10

(31)【優先権主張番号】63/238,635

(32)【優先日】2021-08-30

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/897,815

(32)【優先日】2022-08-29

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ペリンガッセリー クリシュナン，マドゥ

(72)【発明者】

【氏名】ジャオ，シン

(72)【発明者】

【氏名】リウ，シャン

【審査官】田中 純一

(56)【参考文献】

【文献】特表２０１９－５１７２２１（ＪＰ，Ａ）

【文献】国際公開第２０２１／０５１１５６（ＷＯ，Ａ１）

【文献】特表２０２２－５１１８６０（ＪＰ，Ａ）

【文献】特表２０２２－５４８４４８（ＪＰ，Ａ）

【文献】国際公開第２０２０／１１６９６１（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１２

Ｈ０４Ｎ １９／００ － １９／９８

ＩＥＥＥ Ｘｐｌｏｒｅ

(57)【特許請求の範囲】

【請求項1】

エンコーディングされたビデオストリームにおけるビデオブロックを処理する方法であって、
前記エンコーディングされたビデオストリームを解析し、かつ、処理するステップであり、
前記ビデオブロックの二次変換係数のセット、
前記ビデオブロックに関連付けられたイントラ予測モード、および、
二次変換カーネルのグループへのカーネルインデックス、
を生成する、ステップと、
前記イントラ予測モードに基づいて、二次変換カーネルの前記グループを識別するステップと、
二次変換係数の前記セットの逆二次変換を実行するステップであり、
前記カーネルインデックスによって識別される二次変換カーネルの前記グループのうち、二次変換カーネルに基づいて、前記ビデオブロックの一次変換係数を生成する、
ステップと、を含み、
二次変換カーネルの前記グループ内のカーネルの数は、
前記ビデオブロックに関連付けられた前記イントラ予測モード、
前記ビデオブロックのサイズ、または、
前記ビデオブロックに関連付けられた一次変換タイプ、
のうち少なくとも１つに依存しており、
二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックに関連付けられた前記一次変換タイプに依存する、
方法。

【請求項2】

二次変換カーネルの前記グループ内のカーネルの数は、
前記一次変換タイプが前記ビデオブロックの垂直ディメンションおよび水平ディメンションの両方についてＡＤＳＴである場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負の整数である、
請求項１に記載の方法。

【請求項3】

二次変換カーネルの前記グループ内のカーネルの数は、
前記ビデオブロックのサイズが事前決定された閾値より小さい場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負の整数である、
請求項１に記載の方法。

【請求項4】

前記事前決定された閾値は、前記ビデオブロックの水平ディメンションまたは垂直ディメンションのいずれかに対して８×８または８である、
請求項３に記載の方法。

【請求項5】

二次変換カーネルの前記グループ内のカーネルの数は、
前記ビデオブロックが、イントラ予測モードの事前定義されたサブセットのいずれか１つ、一次変換タイプの事前定義されたサブセットのいずれか１つ、および、ブロックサイズの事前定義されたサブセットのいずれか１つによって、特徴付けられる場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負の整数である、
請求項１に記載の方法。

【請求項6】

二次変換カーネルの前記グループ内のカーネルの数は、
前記ビデオブロックが、垂直、水平、スムーズ水平、およびスムーズ垂直のイントラ予測モード、垂直ディメンションおよび水平ディメンションの両方におけるADST_ADST一次変換モード、および、事前定義されたサイズ閾値より小さいブロックサイズ、のうち１つによって特徴付けられる場合にはＮであり、かつ、
そうでない場合にはＫである、
請求項５に記載の方法。

【請求項7】

二次変換カーネルの前記グループが、Ｎ個またはＫ個の二次変換カーネルのみを含む場合に、前記エンコーディングされたビデオストリームにおける前記カーネルインデックスの信号化スキームは、Ｎ個またはＮ個までのインデックスオプションのみをサポートする、
請求項５に記載の方法。

【請求項8】

二次変換カーネルの前記グループ内のカーネルの数がＮであり、かつ、二次変換カーネルの前記グループ内のカーネルの数がＫである場合に、異なるコンテキストモデルを使用して、前記エンコーディングされたビデオストリーム内で前記カーネルインデックスがエントロピーコーディングされる、
請求項５に記載の方法。

【請求項9】

前記エンコーディングされたビデオストリーム内の異なるビデオブロックについて使用される二次変換カーネルの前記グループ内のカーネルの数が異なる場合に、異なるカーネルの数を有する二次変換カーネルの前記グループへの前記カーネルインデックスの二値化コードワードのエントロピーコーディングは、前記二値化コードワードの少なくとも１つのビンについてコンテキストモデリングを共有する、
請求項１に記載の方法。

【請求項10】

イントラ予測ビデオブロックを処理する方法であって、
少なくとも１つの一次変換カーネルを使用してイントラ予測ビデオブロックの残差ブロックを変換するステップであり、一次変換係数のセットを生成する、ステップと、
二次変換カーネルのグループ内で現在の二次変換カーネルを選択するステップであり、二次変換カーネルの前記グループ内のカーネルの数は、
前記イントラ予測ビデオブロックのイントラ予測モード、
前記イントラ予測ビデオブロックのサイズ、または、
前記少なくとも１つの一次変換カーネルの一次変換タイプ、
のうち少なくとも１つに依存する、ステップと、
二次変換カーネルの前記グループ内の前記現在の二次変換カーネルのカーネルインデックスを決定するステップと、
前記一次変換係数のセットを変換するステップであり、前記現在の二次変換カーネルを使用して二次変換係数のセットを生成する、ステップと、
前記カーネルインデックスおよび前記二次変換係数のセットを、前記イントラ予測ビデオブロックに関連付けられたエンコーディングされたビデオストリームへとエンコーディングするステップと、
を含み、
二次変換カーネルの前記グループ内のカーネルの数は、前記イントラ予測ビデオブロックに関連付けられた前記一次変換タイプに依存する、
方法。

【請求項11】

二次変換カーネルの前記グループ内のカーネルの数は、
前記一次変換タイプが前記イントラ予測ビデオブロックの垂直ディメンションおよび水平ディメンションの両方についてＡＤＳＴである場合にはＮであり、かつ、双でない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負の整数である、
請求項１０に記載の方法。

【請求項12】

二次変換カーネルの前記グループ内のカーネルの数は、
前記イントラ予測ビデオブロックのサイズが事前決定された閾値より小さい場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負整数である、
請求項１０に記載の方法。

【請求項13】

前記事前決定されたサイズ閾値が、前記イントラ予測ビデオブロックの水平ディメンションまたは垂直ディメンションのいずれかに対して８×８または８である、
請求項１２に記載の方法。

【請求項14】

二次変換カーネルの前記グループ内のカーネルの数は、
前記イントラ予測ビデオブロックが、イントラ予測モードの事前定義されたサブセットのいずれか１つ、一次変換タイプの事前定義されたサブセットのいずれか１つ、および、ブロックサイズの事前定義されたサブセットのいずれか１つによって特徴付けられる場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負整数である、
請求項１０に記載の方法。

【請求項15】

二次変換カーネルの前記グループ内のカーネルの数は、
前記イントラ予測ビデオブロックが、垂直、水平、スムーズ水平、およびスムーズ垂直のイントラ予測モード、垂直ディメンションおよび水平ディメンションの両方におけるADST_ADST一次変換モード、および、事前定義されたサイズ閾値より小さいブロックサイズ、のうち１つによって特徴付けられる場合にはＮであり、かつ、
そうでない場合にはＫである、
請求項１４に記載の方法。

【請求項16】

二次変換カーネルの前記グループが、Ｎ個またはＫ個の二次変換カーネルのみを含む場合に、前記エンコーディングされたビデオストリームにおける前記カーネルインデックスの信号化スキームは、Ｎ個またはＮ個までのインデックスオプションのみをサポートする、
請求項１４に記載の方法。

【請求項17】

二次変換カーネルの前記グループ内のカーネルの数がＮであり、かつ、二次変換カーネルの前記グループ内のカーネルの数がＫである場合に、異なるコンテキストモデルを使用して、前記エンコーディングされたビデオストリーム内で前記カーネルインデックスがエントロピーコーディングされる、
請求項１４に記載の方法。

【請求項18】

前記エンコーディングされたビデオストリーム内の異なるビデオブロックについて使用される二次変換カーネルの前記グループ内のカーネルの数が異なる場合に、異なるカーネルの数を有する二次変換カーネルの前記グループへの前記カーネルインデックスの二値化コードワードのエントロピーコーディングは、前記二値化コードワードの少なくとも１つのビンについてコンテキストモデリングを共有する、
請求項１０に記載の方法。

【請求項19】

一式の命令を保管するメモリと、
前記命令を実行して、請求項１乃至１８いずれか一項に記載の方法を実行するためのプロセッサと、
を含む、ビデオ処理装置。

【請求項20】

コンピュータで実行可能な一式の命令を含むコンピュータプログラムであって、
前記命令が、ビデオ処理装置のプロセッサによって実行されると、請求項１乃至１８いずれか一項に記載の方法を前記ビデオ処理装置に実施させる、
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一連の高度なビデオコーディング技術を説明する。より具体的に、開示される技術は、適応カーネルオプションを用いた二次変換を含む。

【0002】

本出願は、2022年8月29日に出願された米国特許出願No.17/897,815について優先権の利益を主張するものであり、これは、2021年8月30日に出願された米国仮出願No.63/238,635について優先権の利益を主張している。両方のタイトルは、“ETHOD AND APPARATUS FOR SECONDARY TRANSFORM WITH ADAPTIVE KERNEL OPTIONS”である。これらの先行特許出願は、その全体が参照により組み込まれている。

【背景技術】

【0003】

ここにおいて提供されるこの背景説明は、本開示のコンテキストを一般的に提示するためのものである。現在指名されている発明者の研究は、その研究がこの背景セクションに記載されている範囲において、並びに、そうでなければ、この出願の出願時に先行技術として適格でないかもしれない説明の態様において、本開示に対する先行技術として明示的にも暗示的にも認められるものではない。

【0004】

ビデオコーディング（video coding）およびデコーディング（decoding）は、動き補償（motion compensation）を伴うインターピクチャ予測（inter-picture prediction）を使用して実行され得る。非圧縮ディジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば、1920×1080のルマ（luminance）サンプル、および、関連するフルまたはサブサンプリングされたクロマ（chrominance）サンプルに係る空間的ディメンションを有している。一連のピクチャは、例えば、毎秒60ピクチャまたは毎秒60フレームの、固定または可変ピクチャレート(代替的に、フレームレートと称されるもの)を有し得る。非圧縮ビデオは、ストリーミングまたはデータ処理のために特定のビットレート要件を有している。例えば、1920×1080のピクセル解像度、60フレーム／秒のフレームレート、およびカラーチャネル当たり8ビット/ピクセルでの4:2:0のクロマサブサンプリングであるビデオは、1.5Gbit/sに近い帯域幅を必要とする。そうしたビデオの1時間は、600Gバイト以上のストレージ領域を必要とする。

【0005】

ビデオコーディングおよびデコーディングの１つの目的は、圧縮を通じた、非圧縮入力ビデオ信号の冗長性の低減であり得る。圧縮は、場合によって、2桁以上の大きさで、前述の帯域幅及び／又はストレージ領域の要件を低減するのに役立ち得る。可逆圧縮および可逆圧縮の両方、並びに、それらの組み合わせが採用され得る。可逆圧縮とは、オリジナル信号の正確なコピーが、デコーディングプロセスを介して圧縮されたオリジナル信号から再構成され得る技術を指す。非可逆圧縮とは、オリジナルのビデオ情報が、コーディングの最中に完全には保持されず、かつ、デコーディングの最中に完全には回復できないコーディング／デコーディングプロセスを指す。非可逆を使用する場合、再構成された信号は、オリジナル信号と同一ではないかもしれない。しかし、オリジナル信号と再構成された信号の間の歪みは、いくらかの情報損失があるとはいえ、再構成された信号が意図されたアプリケーションのために有用にするのに十分に小さくされる。ビデオの場合、非可逆圧縮は、多くのアプリケーションで広く使用されている。許容される歪み量はアプリケーションに依存している。例えば、所定の消費者ビデオストリーミングアプリケーションのユーザは、映画またはテレビジョン放送アプリケーションのユーザよりも高い歪みを許容し得る。特定のコーディングアルゴリズムによって達成可能な圧縮比は、様々な歪み許容度を反映するように選択または調整することができる。より高い許容可能な歪みは、一般的に、より高い損失およびより高い圧縮比をもたらすコーディングアルゴリズムを可能にする。

【0006】

ビデオエンコーダおよびデコーダは、例えば、動き補償、フーリエ変換、量子化、およびエントロピーコーディング（entropy coding）を含む、いくつかの広範なカテゴリおよびステップからの技術を利用することができる。

【0007】

ビデオコーデック技術は、イントラ（intra）コーディングとして知られる技術を含むことができる。イントラコーディングにおいて、サンプル値は、以前に再構成された参照ピクチャからのサンプルまたは他のデータを参照することなく表現される。いくつかのビデオコーデックにおいて、ピクチャは、空間的にサンプルのブロックへと分割される。サンプルの全てのブロックがイントラモードでコード化（coded）されている場合、そのピクチャは、イントラピクチャと称され得る。イントラピクチャ、および、独立デコーダリフレッシュピクチャといったそれらの派生物は、デコーダ状態をリセットするために使用することができ、そして、従って、コード化ビデオビットストリームおよびビデオセッションにおける第１（the first）ピクチャとして、または、静止ピクチャとして使用することができる。イントラ予測後のブロックのサンプルは、次いで、周波数領域へと変換することができ、そして、そのように生成された変換係数は、エントロピーコーディングの前に量子化することができる。イントラ予測は、変換前領域（pre-transform domain）におけるサンプル値を最小化する技術を表している。場合によっては、変換後のDC値が小さく、かつ、AC係数が小さいほど、エントロピーコーディング後のブロックを表すための所与の量子化ステップサイズで必要とされるビット数がより少なくなる。

【0008】

例えば、MPEG-2世代のコーディング技術から知られているといった伝統的なイントラコーディングは、イントラ予測を使用しない。しかしながら、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に隣接するものエンコーディング及び／又はデコーディングの最中に獲得され、かつ、イントラコーディングまたはデコーディングされるデータのデコーディングされる順序において先行する、周囲のサンプルデータ及び／又はメタデータに基づいて、ブロックのコーディング／デコーディングを試みる技術を含む。そうした技術は、今後「イントラ予測（“intra prediction”）」技法と呼ばれる。少なくともいくつかの場合に、イントラ予測は、再構成中の現在ピクチャからだけ、かつ、他の参照ピクチャからではなく、参照データを使用することに留意すること。

【0009】

多くの異なる形式のイントラ予測が存在している。所与のビデオコーディング技術において、そうした技術のうち１つ以上が利用可能である場合、使用されている技術は、イントラ予測モードと称することができる。１つ以上のイントラ予測モードが、特定のコーデックにおいて提供され得る。所定の場合に、モードは、サブモードを有することができ、かつ／あるいは、様々なパラメータに関連することができ、そして、ビデオのブロックに対するモード／サブモード情報およびイントラコーディングパラメータは、個別に、または、集合的にモードコードワードないに含まれ得る。所与のモード、サブモード、及び／又は、パラメータの組み合わせについてどのコードワードを使用するかは、イントラ予測を通じて、コーディング効率ゲインに影響を及ぼし、かつ、コードワードをビットストリームへと変換するために使用されるエントロピーコーディング技術も同様であり得る。

【0010】

イントラ予測に係る所定のモードは、H.264で導入され、H.265で改良され、そして、共同探索モデル(JEM)、バーサタイルビデオコーディング(VVC)、およびベンチマークセット(BMS)といった、より新しいコーディング技術において、さらに改良されている。一般的に、イントラ予測について、予測子ブロック（predictor block）は、利用可能になった隣接するサンプル値を使用して形成され得る。例えば、所定の方向及び／又はラインに沿って隣接するサンプルの特定のセットに係る利用可能な値は、予測子ブロックへとコピーされ得る。使用中の方向に対する参照は、ビットストリームでコード化することができ、または、それ自体が予測され得る。

【0011】

図1Aを参照すると、右下に示されているのは、H.265の33個の可能なイントラ予測方向(H.265で指定される35個のモードのうち33個の角度モードに対応している)において指定された9個の予測子方向のサブセットである。矢印が収束する点(101)は、予測されているサンプルを表している。矢印は、101におけるサンプルを予測するために隣接するサンプルが使用される方向を表している。例えば、矢印(102)は、サンプル(101)が、水平方向から45度の角度で、隣接するサンプル（sample or samples）から右上に予測されることを示している。同様に、矢印(103)は、サンプル(101)が、水平方向から22.5度の角度で、隣接するサンプルからサンプル(101)の左下に予測されることを示している。

【0012】

さらに図1Aを参照すると、左上には、4×4サンプルの正方形ブロック(104)が示されている(破線の太線で示される)。正方形ブロック(104)は、16個のサンプルを含み、各サンプルは「S」でラベル付けされており、Yディメンションにおけるその位置(例えば、行（row）インデックス)、および、Xディメンションにおけるその位置(例えば、列（column）インデックス)を含む。例えば、サンプルS21は、Yディメンションにおいて(上から)第２サンプルであり、かつ、Xディメンションにおいて(左から)第１サンプルである。同様に、サンプルS44は、YおよびXディメンションの両方において、ブロック(104)の第４サンプルである。ブロックのサイズが4×4サンプルなので、S44は右下にある。さらに、同様のナンバリングスキームに従う、例示的な参照サンプルが示されている。参照サンプルは、Rと、ブロック(104)に対するそのY位置(例えば、行インデックス)およびX位置(列インデックス)を用いてラベル付けされている。H.264とH.265の両方においては、再構成中のブロックに隣接する予測サンプルが使用される。

【0013】

ブロック104のイントラピクチャ予測は、信号化予測方向（signaled prediction direction）に従って、隣接するサンプルから参照サンプル値をコピーすることによって開始することができる。例えば、コード化ビデオビットストリームが、このブロック104に対して、矢印(102)の予測方向を示している信号を含むと仮定する。すなわち、サンプルは、水平方向から45度の角度で、予測サンプルから右上に予測される。そうした場合、サンプルS41、S32、S23、S14は、同じ参照サンプルR05から予測される。次いで、サンプルS44は、参照サンプルR08から予測される。

【0014】

所定の場合、特には、方向が45度で均一に割り切れない場合には、参照サンプルを計算するために、例えば補間（interpolation）によって、複数の参照サンプルの値が組み合わされ得る。

【0015】

ビデオコーディング技術の開発が進むにつれて、可能な方向の数が増えてきている。例えば、H.264(2003年)では、9個の異なる方向がイントラ予測について利用可能である。これは、H.265(2013年)では33個に増加し、そして、本開示の時点で、JEM/VVC/BMSは、65子の方向をサポートすることができる。実験研究は、最も適切なイントラ予測方向を特定するのを助けるために実施されてきており、そして、エントロピーコーディングにおける所定の技術は、それらの最も適切な方向を少数のビットでエンコーディングするために使用されてよく、方向について所定のビットペナルティを受け入れている。さらに、方向それ自体が、デコーディングされた隣接ブロックのイントラ予測において使用される隣接方向から、ときどき、予測することができる。

【0016】

図1Bは、JEMに従って、65個のイントラ予測方向を描く概略図(180)を示しており、時間にわたり開発された様々なエンコーディング技術における予測方向の数の増加を示している。

【0017】

コード化ビデオビットストリームにおける予測方向に対するイントラ予測方向を表すビットのマッピング方法は、ビデオコーディング技術ごとに様々であり得る。そして、例えば、予測方向の単純な直接マッピングから、イントラ予測モード、コードワード、最も可能性の高いモードを含む複雑な適応スキーム、および類似の技術まで、多岐にわたり得る。しかしながら、全ての場合に、ビデオコンテンツの中で、所定の他の方向よりも統計的により発生しにくい、イントラ予測の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減なので、上手く設計されたビデオコーディング技術において、よりありそうな方向よりも、より多くのビット数によって、よりありそうでない方向が表和され得る。

【0018】

インターピクチャ予測（inter picture prediction）、またはインター予測は、動き補償（motion compensation）に基づいてよい。動き補償において、以前に再構成されたピクチャまたはその一部(参照ピクチャ)からのサンプルデータは、動きベクトル(以下、MV)によって示される方向において空間的にシフトされた後で、新しく再構成されたピクチャまたはピクチャ部分(例えば、ブロック)の予測のために使用され得る。場合によって、参照ピクチャは、現在再構成中のピクチャと同じであり得る。MVは、2個のディメンションXおよびY、または、3個のディメンションを有してよく、第３ディメンションは、(時間ディメンションに類似した)使用中の参照ピクチャの表示である。

【0019】

いくつかのビデオ圧縮技術において、サンプルデータの所定の領域に対して適用可能な現在MVは、他のMVから、例えば、再構成中の領域に空間的に隣接し、かつ、デコーディング順序において現在MVに先行する、サンプルデータの他の領域に関連する他のMVから、予測することができる。そうすることは、相関するMVにおける冗長性の除去に依存することにより、MVをコーディングするために必要とされるデータの全体量を実質的に減少させることができ、それによって、圧縮効率を増加させている。MV予測は、例えば、カメラから導出された入力ビデオ信号(ナチュラルビデオ（natural video）として知られている)をコーディングするときに、単一のMVが適用される領域よりも大きい領域がビデオシーケンスにおける同様の方向に移動する統計的可能性があり、従って、ある場合には、隣接領域のMVから導出された同様な動きベクトルを用いて予測することができるので、効果的に機能することができる。その結果、所与の領域について実際のMVは、周囲のMVから予測されたMVと類似または同一になる。そうしたMVは、次に、エントロピーコーディングの後、MVが隣接するMVから予測されるのではなく、直接的にコード化される場合に使用されるよりも、より少ない数のビットで表現され得る。場合によって、MV予測は、オリジナル信号(すなわち、サンプルストリーム)から導出された信号(すなわち、MV)の可逆圧縮の例であり得る。他の場合に、MV予測それ自体は、例えば、いくつかの周囲のMVから予測子を計算する際の丸め誤差のために、非可逆的であり得る。

【0020】

様々なMV予測メカニズムが、H.265/HEVC(ITU-T Rec.H.265,“High Efficiency Video Coding”,December 2016)において説明されている。H.265が規定する多くのMV予測メカニズムのうち、後述されるのは「空間的マージ（“spatial merge”）」と呼ばれる技術である。

【0021】

具体的には、図2を参照すると、現在ブロック(201)は、空間的にシフトされた同じサイズの以前のブロックから予測可能であると動き探索（motion search）プロセスの最中の処理中にエンコーダによって見出されたサンプルを含んでいる。そのMVを直接的にコーディングする代わりに、MVは、１つ以上の参照ピクチャに関連付けられたメタデータから、例えば、A0、A1、およびB0、B1、B2(それぞれ202から206)と示される5個の周囲のサンプルのいずれかに関連付けられたMVを使用して、(デコーディング順序において)最新の参照ピクチャから導出することができる。H.265において、MV予測は、隣接ブロックが使用するのと同じ参照ピクチャからの予測子を使用することができる。

【発明の概要】

【発明が解決しようとする課題】

【0022】

本開示の態様は、適応カーネルオプションを用いた二次変換のための方法および装置を提供する。

【0023】

いくつかの実装において、エンコーディングされたビデオストリームにおけるビデオブロックを処理する方法が開示される。本方法は、前記エンコーディングされたビデオストリームを解析し、かつ、処理するステップであり、前記ビデオブロックの二次変換係数のセット、前記ビデオブロックに関連付けられたイントラ予測モード、および、二次変換カーネルのグループへのカーネルインデックス、を生成するステップを含み得る。本方法は、さらに、前記イントラ予測モードに基づいて、二次変換カーネルの前記グループを識別するステップと、二次変換係数の前記セットの逆二次変換を実行するステップであり、前記カーネルインデックスによって識別される二次変換カーネルの前記グループのうち、二次変換カーネルに基づいて、前記ビデオブロックの一次変換係数を生成する、ステップと、を含み得る。二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックに関連付けられた前記イントラ予測モード、前記ビデオブロックのサイズ、または、前記ビデオブロックに関連付けられた一次変換タイプのうち少なくとも１つに依存している。

【0024】

他のいくつかの実装において、イントラ予測ビデオブロックを処理する別の方法が開示されている。本方法は、少なくとも１つの一次変換カーネルを使用してイントラ予測ビデオブロックの残差ブロックを変換するステップであり、一次変換係数のセットを生成するステップと、二次変換カーネルのグループ内で現在の二次変換カーネルを選択するステップであり、二次変換カーネルの前記グループ内のカーネルの数は、前記イントラ予測ビデオブロックのイントラ予測モード、前記イントラ予測ビデオブロックのサイズ、または、前記少なくとも１つの一次変換カーネルの一次変換タイプのうち少なくとも１つに依存する、ステップと、を含み得る。本方法は、さらに、二次変換カーネルの前記グループ内の前記現在の二次変換カーネルのカーネルインデックスを決定するステップと、前記一次変換係数のセットを変換するステップであり、前記現在の二次変換カーネルを使用して二次変換係数のセットを生成するステップと、前記カーネルインデックスおよび前記二次変換係数のセットを、前記イントラ予測ビデオブロックに関連付けられたエンコーディングされたビデオストリームへとエンコーディングするステップと、を含み得る。

【0025】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックに関連付けられた前記一次変換タイプに依存している。

【0026】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数は、前記一次変換タイプが前記ビデオブロックの垂直ディメンションおよび水平ディメンションの両方についてＡＤＳＴである場合にはＮであり、かつ、そうでない場合にはＫであり、ＮおよびＫは、０と６の間の異なる非負の整数である。

【0027】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックのサイズが事前決定された閾値より小さい場合にはＮであり、かつ、そうでない場合にはＫであり、ＮおよびＫは、０と６の間の異なる非負の整数である。

【0028】

上記の実装のいずれかにおいて、前記事前決定された閾値は、前記ビデオブロックの水平ディメンションまたは垂直ディメンションのいずれかに対して８×８または８である。

【0029】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックが、イントラ予測モードの事前定義されたサブセットのいずれか１つ、一次変換タイプの事前定義されたサブセットのいずれか１つ、および、ブロックサイズの事前定義されたサブセットのいずれか１つによって、特徴付けられる場合にはＮであり、かつ、そうでない場合にはＫであり、
ＮおよびＫは、０と６の間の異なる非負の整数である。

【0030】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数は、前記ビデオブロックが、垂直、水平、スムーズ水平、およびスムーズ垂直のイントラ予測モード、垂直ディメンションおよび水平ディメンションの両方におけるADST_ADST一次変換モード、および、事前定義されたサイズ閾値より小さいブロックサイズ、のうち１つによって特徴付けられる場合にはＮであり、かつ、そうでない場合にはＫである。

【0031】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループが、Ｎ個またはＫ個の二次変換カーネルのみを含む場合に、前記エンコーディングされたビデオストリームにおける前記カーネルインデックスの信号化スキームは、Ｎ個またはＮ個までのインデックスオプションのみをサポートする。

【0032】

上記の実装のいずれかにおいて、二次変換カーネルの前記グループ内のカーネルの数がＮであり、かつ、二次変換カーネルの前記グループ内のカーネルの数がＫである場合に、異なるコンテキストモデルを使用して、前記エンコーディングされたビデオストリーム内で前記カーネルインデックスがエントロピーコーディングされる。

【0033】

上記の実装のいずれかにおいて、前記エンコーディングされたビデオストリーム内の異なるビデオブロックについて使用される二次変換カーネルの前記グループ内のカーネルの数が異なる場合に、異なるカーネルの数を有する二次変換カーネルの前記グループへの前記カーネルインデックスの二値化コードワードのエントロピーコーディングは、前記二値化コードワードの少なくとも１つのビンについてコンテキストモデリングを共有する。

【0034】

他のいくつかの実装において、ビデオ情報を処理するための装置が開示される。本装置は、上記の方法の実装のいずれかを実行するように構成された回路を含み得る。

【0035】

本開示の態様は、また、命令を保管している非一時的コンピュータ可読媒体を提供する。ビデオのデコーディング及び／又はエンコーディングのために、本命令が、コンピュータによって実行されると、コンピュータに、ビデオのデコーディング及び／又はエンコーディングのための方法を実行させる。

【図面の簡単な説明】

【0036】

開示される技術的事項（subject matter）のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるだろう。

【図1A】図1Aは、イントラ予測方向モードに係る例示的なサブセットの概略図を示している。

【図1B】図1Bは、例示的なイントラ予測方向の説明図を示している。

【図2】図2は、一つの例における動きベクトル予測のための現在ブロック、および、その周囲の空間的マージ候補の概略図を示している。

【図3】図3は、一つの例示的な実施形態に従って、通信システム(300)の簡略化されたブロックダイアグラムの概略図を示している。

【図4】図4は、一つの例示的な実施形態に従って、通信システム(400)の簡略化されたブロックダイアグラムの概略図を示している。

【図5】図5は、一つの例示的な実施形態に従って、ビデオデコーダの簡略化されたブロックダイアグラムの概略図を示している。

【図6】図6は、一つの例示的な実施形態に従って、ビデオエンコーダの簡略化されたブロックダイアグラムの概略図を示している。

【図7】図7は、別の例示的な実施形態に従って、ビデオエンコーダのブロックダイアグラムを示している。

【図8】図8は、別の例示的な実施形態に従って、ビデオデコーダのブロックダイアグラムを示している。

【図9】図9は、本開示の例示的な実施形態に従って、コーディングブロックパーティション分割に係るスキームを示している。

【図10】図10は、本開示の例示的な実施形態に従って、コーディングブロックパーティション分割に係る別のスキームを示している。

【図11】図11は、本開示の例示的な実施形態に従って、コーディングブロックパーティション分割に係る別のスキームを示している。

【図12】図12は、一つの例示的なパーティション分割スキームに従って、ベースブロックのコーディングブロックへのパーティション分割の一例を示している。

【図13】図13は、一つの例示的な三元パーティション分割（ternary partitioning）スキームを示している。

【図14】図14は、一つの例示的な四分木バイナリ（quadtree binary tree）コーディングブロックパーティション分割スキームを示している。

【図15】図15は、本開示の例示的な実施形態に従って、コーディングブロックを複数の変換ブロックへとパーティション分割すること、および、変換ブロックのコーディング順序に対するスキームを示している。

【図16】図16は、本開示の例示的な実施形態に従って、コーディングブロックを複数の変換ブロックへとパーティション分割すること、および、変換ブロックのコーディング順序に対するスキームを示している。

【図17】図17は、本開示の例示的な実施形態に従って、コーディングブロックを複数の変換ブロックへとパーティション分割するための別のスキームを示している。

【図18】図18は、方向イントラ予測における微小角度の例を示している。

【図19】図19は、方向イントラ予測におけるノミナル（nominal）角度を示している。

【図20】図20は、ブロックのPAETHモードについて上、左、左上の位置を示している。

【図21】図21は、再帰的イントラフィルタリングモードの例を示している。

【図22】図22は、ブロックについて４参照ライン（four-reference line）イントラコーディングの例を示している。

【図23】図23は、本開示の例示的な実施形態に従って、変換ブロックパーティション分割およびイントラ予測ブロックのスキャンを示している。

【図24】図24は、本開示の例示的な実施形態に従って、変換ブロックパーティション分割およびインター予測ブロックのスキャンを示している。

【図25】図25は、本開示の例示的な実施形態に従って、低周波非分離変換プロセスを示している。

【図26】図26は、本開示の一つの例示的な実施形態に従って、フローチャートを示している。

【図27】図27は、本開示の別の例示的な実施形態に従って、フローチャートを示している。

【図28】図28は、本開示の例示的な実施形態に従って、コンピュータシステムの概略図を示している。

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

【0037】

図3は、本開示の一つの例示的な実施形態に従って、通信システム(300)の簡略化されたブロックダイアグラムを示している。通信システム(300)は、例えば、ネットワーク(350)を介して、互いに通信することができる複数の端末装置を含んでいる。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された端末装置の第１ペア(310)および(320)を含む。図3の例において、端末装置の第１ペア(310)および(320)は、データの一方向送信を行うことができる。例えば、端末装置(310)は、ネットワーク(350)を介して他の端末装置(320)に送信するために、ビデオデータ(例えば、端末装置(310)によってキャプチャされるビデオピクチャのストリーム)をコード化（code）することができる。エンコード化ビデオデータは、１つ以上のコード化ビデオビットストリームの形態で送信することができる。端末装置(320)は、ネットワーク(350)からコード化ビデオデータを受信し、コード化ビデオデータをデコーディングして、ビデオピクチャを回復し、そして、回復したビデオデータに従ってビデオピクチャを表示することができる。一方向データ伝送は、媒体提供アプリケーション、等において実施され得る。

【0038】

別の例において、通信システム(300)は、例えば、ビデオ会議アプリケーションの最中に、実装され得るコード化ビデオデータの双方向伝送を実行する端末装置の第２ペア(330)および(340)を含む。データの双方向伝送のために、一つの例において、端末装置(330)および(340)の各端末装置は、ネットワーク(350)を介して端末装置(330)および(340)の他方の端末装置に伝送するために、ビデオデータ(例えば、端末装置によってキャプチャされるビデオピクチャのストリーム)をコード化することができる。端末装置(330)および(340)の各端末装置は、また、端末装置(330)および(340)の他方の端末装置によって送信されたコード化ビデオデータを受信し、ビデオピクチャを回復するためにコード化ビデオデータをデコーディングし、そして、回復したビデオデータに従って、アクセス可能な表示装置でビデオピクチャを表示することができる。

【0039】

図3の例において、端末装置(310)、(320)、(330)、および(340)は、サーバ、パーソナルコンピュータ、およびスマートフォンとして実装され得るが、本開示の基本原理（underlying principles）の適用性は、そのように限定されるものではない。本開示の実施形態は、であるクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、ウェアラブルコンピュータ、専用のビデオ会議装置、及び／又は、類似のものにおいて実施され得る。ネットワーク(350)は、例えば、有線及び／又は無線通信ネットワークを含む、端末装置(310)、(320)、(330)、および(340)の間でコード化ビデオデータを搬送する、任意の数またはタイプのネットワークを表している。通信ネットワーク(350)は、回線交換（circuit-switched）、パケット交換（packet-switched）、及び／又は、他のタイプのチャネルにおいてデータを交換することができる。代表的なネットワークは、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又は、インターネットを含む。本説明の目的のために、ネットワーク(350)のアーキテクチャおよびトポロジーは、ここにおいて明示的に説明されない限り、本開示の動作に対して重要ではない場合がある。

【0040】

図4は、開示される技術的事項のためのアプリケーションについて一つの例として、ビデオストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示している。開示される技術的事項は、例えば、ビデオ会議、デジタルTV放送、ゲーム、バーチャルリアリティ、CD、DVD、メモリスティック、等を含むデジタルメディア上の圧縮ビデオの記憶ストレージ、などを含む他のビデオアプリケーションに対しても同様に適用可能である。

【0041】

ビデオストリーミングシステムは、非圧縮のビデオピクチャまたはピクチャのストリーム(402)を生成するためのビデオソース(401)、例えば、デジタルカメラ、を含むことができるビデオキャプチャサブシステム(413)を含み得る。一つの例において、ビデオピクチャのストリーム(402)は、ビデオソース401のデジタルカメラによって記録されるサンプルを含む。ビデオピクチャのストリーム(402)は、エンコード化ビデオデータ(404)(または、コード化ビデオビットストリーム)と比較した場合に、高いデータ量を強調するために太い線として描かれており、ビデオソース(401)に結合されたビデオエンコーダ(403)を含む電子デバイス(420)によって処理することができる。ビデオエンコーダ(403)は、ハードウェア、ソフトウェア、または、それらの組み合わせを含むことができ、以下でより詳細に説明されるように、開示される技術的事項の態様を可能にし、または実施する。エンコード化ビデオデータ(404)(または、エンコード化ビデオビットストリーム(404)は、非圧縮ビデオピクチャ(402)のストリームと比較した場合に、より低いデータ量を強調するために細いラインとして描かれており、将来の使用のため、または、直接的にビデオデバイス(図示なし)にダウンストリームするためにストリーミングサーバ(405)に保管することができる。１つ以上のストリーミングクライアントサブシステム、図4のクライアントサブシステム(406)および(408)といったものは、エンコード化ビデオデータ(404)のコピー(407)および(409)を取り出すために、ストリーミングサーバ(405)にアクセスすることができる。クライアントサブシステム(406)は、例えば、電子デバイス(430)内にビデオデコーダ(410)を含むことができる。ビデオデコーダ(410)は、エンコード化ビデオデータの入力コピー(407)をデコーディングし、そして、非圧縮であり、かつ、ディスプレイ(412)(例えば、ディスプレイスクリーン)または他のレンダリング装置(図示なし)上でレンダリングできる、ビデオピクチャの送信（outgoing）ストリーム(411)を生成する。ビデオデコーダ410は、本開示において説明される様々な機能の一部または全部を実行するように構成され得る。いくつかのストリーミングシステムにおいて、エンコード化ビデオデータ(404)、(407)、および(409)(例えば、ビデオビットストリーム)は、所定のビデオコーディング／圧縮標準に従ってエンコーディングすることができる。これらの標準の例は、ITU-T勧告（Recommendation）H.265を含む。一つの例において、開発中のビデオコーディング規格は、バーサタイルビデオコーディング(VVC)として非公式に知られている。開示される技術的事項は、VVC、および、他のビデオコーディング標準のコンテキストにおいて使用され得る。

【0042】

電子デバイス(420)および(430)は、他の構成要素(図示なし)を含むことができることに留意されたい。例えば、電子デバイス(420)は、ビデオデコーダ(図示なし)を含むことができ、そして、電子デバイス(430)は、同様に、ビデオエンコーダ(図示なし)も含むことができる。

【0043】

図5は、以下の本開示の任意の実施形態に従って、ビデオデコーダ(510)のブロックダイアグラムを示している。ビデオデコーダ(510)は、電子デバイス(530)に含まれ得る。電子デバイス(530)は、受信器(531)(例えば、受信回路)を含むことができる。ビデオデコーダ(510)が、図4の例におけるビデオデコーダ(410)の代わりに使用され得る。

【0044】

受信器(531)は、ビデオデコーダ(510)によってデコーディングされるべき１つ以上のコード化ビデオシーケンスを受信することができる。同一または別の実施形態においては、１つのコード化ビデオシーケンスが一度にデコーディングされ得る。ここで、各コード化ビデオシーケンスのデコーディングは、他のコード化ビデオシーケンスから独立している。各ビデオシーケンスは、複数のビデオフレームまたはピクチャに関連付けされ得る。コード化ビデオシーケンスは、チャネル(501)から受信され得る。チャネルは、エンコード化ビデオデータを保管するストレージ装置へのハードウェア／ソフトウェアリンク、または、エンコード化ビデオデータを送信するストリーミングソースであってよい。受信器(531)は、コード化音声データ及び／又は補助的なデータストリームといった、他のデータと共にエンコード化ビデオデータを受信することができ、それらのそれぞれの処理回路（図示なし）に転送され得る。受信器(531)は、コード化ビデオシーケンスを他のデータから分離することができる。ネットワークジッタと闘う（combat）ために、バッファメモリ(515)が、受信器(531)とエントロピーデコーダ／パーサ(520)(以降で、「パーサ(520)」)との間に配置されてよい。所定のアプリケーションにおいて、バッファメモリ(515)は、ビデオデコーダ(510)の一部として実装され得る。他のアプリケーションにおいては、ビデオデコーダ(510)(図示なし)の外側にあり、かつ、ビデオデコーダ(510)から分離してよい。さらに他のアプリケーションにおいて、例えば、ネットワークジッタと闘う目的で、ビデオデコーダ(510)の外側にバッファメモリ(図示なし)が存在し得る。そして、例えば、再生（playback）タイミングを処理するために、ビデオデコーダ(510)の内側に別のバッファメモリ(515)が存在し得る。受信器(531)が、十分な帯域幅および制御可能性があるストア／フォワード装置から、または、アイソクロナス（isosynchronous）ネットワークからデータを受信している場合、バッファメモリ(515)は必要とされず、または、小さくてよい。インターネットといったベストエフォート（best-effort）・パケットネットワークにおける使用のためには、十分なサイズのバッファメモリ(515)が必要とされ得る。そして、そのサイズは比較的に大きい。そうしたバッファメモリは、適応サイズで実装され得る。そして、少なくとも部分的には、オペレーティングシステムまたはビデオデコーダ(510)の外側の類似の要素(図示なし)において実装され得る。

【0045】

ビデオデコーダ(510)は、コード化ビデオシーケンスからシンボル(521)を再構成するためのパーサ(520)を含んでよい。これらのシンボルのカテゴリは、ビデオデコーダ(510)の動作を管理するために使用される情報、および、図5に示されるように、電子デバイス(530)の一体部分であっても、または、なくてもよいが、電子デバイス(530)に結合され得る、ディスプレイ(512)(例えば、表示スクリーン)といったレンダリング装置を制御するための潜在的な情報を含む。レンダリング装置の制御情報は、補足拡張情報(Supplemental Enhancement Information、SEI message)、または、ビデオユーザビリティ情報(Video Usability Information、VUI)パラメータセットフラグメント(図示なし)の形式であってよい。パーサ(520)は、パーサ(520)によって受信されるコード化ビデオシーケンスを解析（parse）／エントロピー復号（entropy-decode）することができる。コード化ビデオシーケンスのエントロピーコーディング、ビデオコーディング技術または標準に従うことができ、そして、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わないコーディング、などを含む、様々な原理に従うことができる。パーサ(520)は、サブグループに対応する少なくとも１つのパラメータに基づいて、コード化ビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループのうち少なくとも１つに対するサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)、などを含むことができる。パーサ(520)は、また、コード化ビデオシーケンス情報から、変換係数(例えば、フーリエ変換係数)、量子化パラメータ値、動きベクトル、などといったものを抽出し得る。

【0046】

パーサ(520)は、シンボル(521)を生成するように、バッファメモリ(515)から受信したビデオシーケンスにおいてエントロピー復号／シンタックス解析オペレーションを実行することができる。

【0047】

シンボル(521)の再構成は、コード化ビデオピクチャまたはその部分のタイプ(インターおよびイントラピクチャ、インターおよびイントラブロック、といったもの)および他の要因に応じて、複数の異なる処理または機能ユニットを含むことができる。関与するユニット、および、それらがどのように関与するかは、パーサ(520)によってコード化ビデオシーケンスからシンタックス解析されたサブグループ制御情報によって制御され得る。パーサ(520)と、以下の複数の処理または機能ユニットとの間のそうしたサブグループ制御情報のフローは、単純化のために描かれていない。

【0048】

既に述べた機能ブロックの他に、ビデオデコーダ(510)は、概念的に、以下に説明されるように、いくつかの機能ユニット（functional unit）へと分割することができる。商業的制約の下で動作する実用的な実装において、これらの機能ユニットの多くは、相互に密接に相互作用し、そして、少なくとも部分的には、相互に統合され得る。しかしながら、開示される技術的事項の様々な機能を明確に説明する目的で、機能ユニットへの概念的な細分化が以下の開示において採用されている。

【0049】

第１ユニットは、スケーラ／逆変換ユニット(551)を含んでよい。スケーラ／逆変換ユニット(551)は、量子化された変換係数、並びに、使用すべき逆変換のタイプ、ブロックサイズ、量子化係数／パラメータ、量子化スケーリング行列、および、パーサ(520)からのシンボル(521)としての位置（lie）を示している情報を含む、制御情報を受信し得る。スケーラ／逆変換ユニット(551)は、アグリゲータ(555)へと入力され得るサンプル値を含むブロックを出力することができる。

【0050】

場合によって、スケーラ／逆変換(551)の出力サンプルは、イントラコード化ブロックに関係することができる。すなわち、以前に再構成されたピクチャからの予測情報を使用しないが、現在ピクチャの以前に再構成された部分からの予測情報を使用することができるブロックである。そうした予測情報は、イントラピクチャ予測ユニット(552)によって提供され得る。場合によって、イントラピクチャ予測ユニット(552)は、既に再構成され、そして、現在ピクチャバッファ(558)に保管されている周囲のブロック情報を使用して、再構成されるブロックの同じサイズおよび形状のブロックを生成し得る。現在ピクチャバッファ(558)は、例えば、部分的に再構成された現在ピクチャ及び／又は完全に再構成された現在ピクチャをバッファする。アグリゲータ(555)は、いくつかの実装において、サンプル毎に、イントラ予測ユニット(552)が生成した予測情報を、スケーラ／逆変換ユニット(551)によって提供されるように、出力サンプル情報に加えることができる。

【0051】

他の場合には、スケーラ／逆変換ユニット(551)の出力サンプルは、インターコード化（inter coded）、および、潜在的に動き補償ブロックに関係することができる。そうした場合、動き補償予測ユニット553は、インターピクチャ予測に使用されるサンプルを取り出すために参照ピクチャメモリ557にアクセスすることができる。ブロックに関係するシンボル(521)に従ってフェッチされたサンプルの動き補償の後で、これらのサンプルは、出力サンプル情報を生成するたように、アグリゲータ(555)によって、スケーラ／逆変換ユニット(551)の出力(ユニット551の出力は残差サンプルまたは残差信号と称され得る)に追加され得る。動き補償予測ユニット(553)が、そこから予測サンプルをフェッチする、参照ピクチャメモリ(557)内のアドレスは、例えば、X、Y成分(シフト)、および、参照ピクチャ成分(時間)を有することができる、シンボル(521)の形式で動き補償予測ユニット(553)に利用可能な、動きベクトルによって制御され得る。動き補償は、また、サブサンプルの正確な動きベクトルが使用されている場合、参照ピクチャメモリ(557)からフェッチされるサンプル値の補間を含んでよい。そして、また、動きベクトル予測メカニズム、などに関連付けされてよい。

【0052】

アグリゲータ(555)の出力サンプルは、ループフィルタユニット(556)における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、コード化ビデオシーケンス(コード化ビデオビットストリームとも称される)に含まれるパラメータによって制御され、かつ、パーサ(520)からシンボル(521)としてループフィルタユニット(556)に利用可能にされる、インループフィルタ技術を含むことができる。しかし、また、コード化ピクチャまたはコード化ビデオシーケンスの以前の部分(デコーディング順序で)のデコーディングの最中に獲得されたメタ情報に応答することができ、同様に、以前に再構成され、かつ、ループフィルタリングされたサンプル値に応答することができる、ループ内フィルタ技術を含むことができる。いくつかのタイプのループフィルタが、以下でさらに詳細に説明するように、様々な順序でループフィルタユニット556の一部として含まれてよい。

【0053】

ループフィルタユニット(556)の出力は、レンダリング装置(512)に出力され、同様に、将来のインターピクチャ予測で使用するために参照ピクチャメモリ(557)に保管され得る、サンプルストリームであり得る。

【0054】

所定のコード化ピクチャは、いったん完全に再構成されると、将来のインターピクチャ予測のための参照ピクチャとして使用され得る。例えば、現在ピクチャに対応するコード化ピクチャが完全に再構成され、そして、コード化ピクチャが参照ピクチャとして(例えば、パーサ(520)によって)識別されると、現在ピクチャバッファ(558)は、参照ピクチャメモリ(557)の一部となり得る。そして、フレッシュな（fresh）現在ピクチャバッファは、次のコード化ピクチャの再構成を開始する前に再割当てされ得る。

【0055】

ビデオデコーダ(510)は、ITU-T Rec. H.265といった、標準において採用されている事前決定されたビデオ圧縮技術に従って、デコーディングオペレーションを実行することができる。コード化ビデオシーケンスは、コード化ビデオシーケンスが、ビデオ圧縮技術または標準のシンタックス、および、ビデオ圧縮技術または標準に文書化されているプロファイルの両方に従うという意味で、使用されているビデオ圧縮技術または標準によって指定されたシンタックスに適合し得る。具体的に、プロファイルは、そのプロファイルの下での使用に利用可能な唯一のツールとして、ビデオ圧縮技術または標準において利用可能な全てのツールから、所定のツールを選択することができる。標準に準拠するために、コード化ビデオシーケンスの複雑さは、ビデオ圧縮技術または標準のレベルによって定義される範囲内にあってよい。場合によって、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート(例えば、毎秒メガサンプルで測定される)、最大参照ピクチャサイズ、などを制限する。レベルによって設定される制限値は、場合によって、仮想参照デコーダ(Hypothetical Reference Decoder、HRD)仕様、および、コード化ビデオシーケンスにおいて信号化されたHRDバッファ管理のためのメタデータを通して、さらに制限され得る。

【0056】

いくつかの例示的な実施形態において、受信器(531)は、コード化ビデオと共に追加(冗長な)データを受信することができる。追加データは、コード化ビデオシーケンスの一部として含まれ得る。追加データは、データを適切にデコーディングするため、かつ／あるいは、元のビデオデータをより正確に再構成するために、ビデオデコーダ(510)によって使用され得る。追加データは、例えば、時間的、空間的、または、信号雑音比（SNR）エンハンスメント層、冗長スライス、冗長ピクチャ、前方エラー補正コード、などの形式であり得る。

【0057】

図6は、本開示の一つの例示的な実施形態に従って、ビデオエンコーダ(603)のブロックダイアグラムを示している。ビデオエンコーダ(603)は、電子デバイス(620)内に含まれてよい。電子デバイス(620)は、さらに、送信器(640)(例えば、送信回路)を含んでよい。ビデオエンコーダ(603)が、図4の例におけるビデオエンコーダ(403)の代わりに使用され得る。

【0058】

ビデオエンコーダ(603)は、ビデオエンコーダ(603)によってコード化されるべきビデオイメージをキャプチャすることができる、ビデオソース(601)から(図6の例において電子デバイス(620)の一部ではない)、ビデオサンプルを受け取ることができる。別の例において、ビデオソース(601)は、電子デバイス(620)の一部として実装され得る。

【0059】

ビデオソース(601)は、任意の適切なビット深さ(例えば、8ビット、10ビット、12ビット、...)、任意の色空間(例えば、BT.601 YCrCb、RGB、XYZ...)、および、任意の適切なサンプリング構造(例えば、YCrCb 4:2:0、YCrCb 4:4:4)であり得る、デジタルビデオサンプルストリームの形式で、ビデオエンコーダ(603)によってコード化されるソースビデオシーケンスを提供することができる。メディア配信システムにおいて、ビデオソース(601)は、以前に準備されたビデオを保管することができるストレージ装置であり得る。ビデオ会議システムにおいて、ビデオソース(601)は、ローカルイメージセンサ情報をビデオシーケンスとしてキャプチャするカメラであってよい。ビデオデータは、順番に観察されるときに動きを伝える、複数の個々のピクチャまたはイメージとして提供されてよい。ピクチャ自体は、ピクセルの空間的アレイとして構成されてよい。ここで、各ピクセルは、使用されているサンプリング構造、色空間、などに応じて、１つ以上のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。

【0060】

いくつかの例示的な実施形態によれば、ビデオエンコーダ(603)は、ソースビデオシーケンスのピクチャを、リアルタイムで、または、アプリケーションによって要求される任意の他の時間制約の下で、コード化ビデオシーケンス(643)へとコード化および圧縮することができる。適切なコーディング速度を実現することは、コントローラ(650)の１つの機能を構成する。いくつかの実施形態において、コントローラ(650)は、以下で説明されるように、他の機能ユニットに機能的に結合されてよく、そして、制御することができる。この結合（coupling）は、単純化のために示されていない。コントローラ(650)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ（lambda）値、...)、ピクチャサイズ、ピクチャグループレ（GOP）イアウト、最大動きベクトル探索範囲、などを含むことができる。コントローラ(650)は、所定のシステム設計のために最適化された、ビデオエンコーダ(603)に関係する他の適切な機能を有するように構成することができる。

【0061】

いくつかの例示的な実施形態において、ビデオエンコーダ(603)は、コーディングループにおいて動作するように構成され得る。過剰に単純化された説明として、一つの例において、コーディングループは、ソースコーダ(630)(例えば、コード化されるべき入力ピクチャおよび参照ピクチャに基づいて、シンボルストリームといった、シンボルを生成する責任を負うもの)、および、ビデオエンコーダ(603)に埋め込まれた(ローカル)デコーダ(633)を含み得る。デコーダ(633)は、たとえ埋め込みデコーダ633がエントロピーコーディングなしでソースコーダ630によってコード化ビデオストリームを処理するとしても(エントロピーコーディングにおいてシンボルとコード化ビデオビットストリームとの間の任意の圧縮は、開示される技術的事項において考慮されるビデオ圧縮技術において可逆であり得るため)、(リモート)デコーダと同様の方法でサンプルデータを生成するためにシンボルを再構成する。再構成されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームのデコーディングは、デコーダ位置(ローカルまたはリモート)に依存しないビット正確（bit-exact）な結果をもたらすので、参照ピクチャメモリ(634)内のコンテンツも、また、ローカルエンコーダとリモートエンコーダとの間でビット正確である。別の言葉で言えば、エンコーダの予測部は、参照ピクチャサンプルとして、デコーディングの最中に予測を使用するときに、デコーダが「見る（“see”）」であろうものと全く同じサンプル値を「見る」。参照ピクチャ同期性のこの基本原理(および、例えば、チャネルエラーのせいで、同期性が維持できない場合に、結果として生じるドリフト)は、コーディング品質を改善するために使用される。

【0062】

「ローカル（“local”）」デコーダ(633)のオペレーションは、ビデオデコーダ(510)といった、「リモート（“remote”）」デコーダと同じであり得る。これは、既に図5に関連して上記で詳細に説明されている。しかしながら、また、図5も簡単に参照すると、シンボルが利用可能であり、かつ、エントロピーコーダ(645)およびパーサ(520)によるコード化ビデオシーケンスへのシンボルのエンコーディング／デコーディングが可逆であり得るので、バッファメモリ(515)を含む、ビデオデコーダ(510)のエントロピー復号部分、および、パーサ(520)は、エンコーダ内のローカルデコーダ(633)において完全には実装されなくてよい。

【0063】

この時点で行うことができる観察は、デコーダ内にだけ存在し得る解析／エントロピー復号を除く任意のデコーダ技術が、また、対応するエンコーダにおいて、実質的に同一の機能形式で、存在する必要があり得ることである。この理由のために、開示される技術的事項は、時には、エンコーダのデコーダ部分と関連する、デコーダオペレーションにフォーカスし得る。従って、エンコーダ技術の記述は、包括的に記述されたデコーダ技術の逆であるので、省略することができる。所定の領域または態様においてだけ、エンコーダのより詳細な説明が以下に提供される。

【0064】

いくつかの例示的な実装におけるオペレーションの最中に、ソースコーダ(630)は、「参照ピクチャ（“reference picture”）」として指定されたビデオシーケンスからの１つ以上の以前にコード化されたピクチャに関して入力ピクチャを予測的にコード化する、動き補償予測コーディングを実行することができる。このようにして、コーディングエンジン(632)は、入力ピクチャのピクセルブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャのピクセルブロックとの間のカラーチャネルにおける差異(または残差)をコード化する。

【0065】

ローカルビデオデコーダ(633)は、ソースコーダ(630)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコード化ビデオデータをデコーディングすることができる。コーディングエンジン(632)のオペレーションは、有利なことに、損失プロセスであり得る。コード化ビデオデータがビデオデコーダ（図６に図示なし）でデコーディングされ得る場合、再構成されたビデオシーケンスは、典型的に、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ(633)は、参照ピクチャ上でビデオデコーダによって実行され、そして、再構成された参照ピクチャを参照ピクチャキャッシュ(634)に保管させ得る、デコーディング処理を複製（replicate）する。このようにして、ビデオエンコーダ(603)は、遠端(リモート)のビデオデコーダによって獲得される、再構成された参照ピクチャとして、共通のコンテンツを有する、再構成された参照ピクチャのコピーをローカルに保管することができる。

【0066】

予測器(635)は、コーディングエンジン(632)について予測探索を実行することができる。すなわち、コード化されるべき新しいピクチャについて、予測器(635)は、参照ピクチャメモリ(634)を、サンプルデータ(参照ピクセルブロックの候補として)、または、参照ピクチャ動きベクトル、ブロック形状、等といった所定のメタデータについて検索することができ、これらは、新しいピクチャに対する適切な予測参照として役立ち得る。予測器(635)は、適切な予測参照を見出すために、サンプルブロック毎に動作し得る。場合によっては、予測器(635)により獲得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(634)に保管された複数の参照ピクチャから引き出された予測参照を有し得る。

【0067】

コントローラ(650)は、例えば、ビデオデータをエンコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ソースコーダ(630)のコーディングオペレーションを管理することができる。

【0068】

全ての前述された機能ユニットの出力は、エントロピーコーダ(645)においてエントロピーコーディングを受けることができる。エントロピーコーダ(645)は、ハフマン（Huffman）コーディング、可変長コーディング、算術コーディング、などの技術に従ったシンボルの可逆圧縮によって、様々な機能ユニットによって生成されたシンボルをコード化ビデオシーケンスへと変換する。

【0069】

送信器(640)は、エントロピーコーダ(645)によって生成された際に、通信チャネル(660)を介した送信の準備のために、コード化ビデオシーケンスをバッファし得る。通信チャネルは、コード化ビデオデータを保管するストレージ装置へのハードウェア／ソフトウェアリンクであってよい。送信器(640)は、ビデオコーダ(603)からのコード化ビデオデータを、例えば、コード化音声データ及び／又は補助的なデータストリーム(ソースの図示なし)などの、送信される他のデータとマージすることができる。

【0070】

コントローラ(650)は、ビデオエンコーダ(603)のオペレーションを管理することができる。コーディングの最中に、コントローラ(650)は、各コード化ピクチャに対して、所定のコード化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、ピクチャは、しばしば、以下のピクチャタイプの１つとして割り当てられ得る。

【0071】

イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内のあらゆる他のピクチャを使用することなくコーディングおよびデコーディングされ得るもの、であってよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(「IDR」)ピクチャを含む、イントラピクチャの異なるタイプを許容する。当業者でれば、Iピクチャのこうした変形、および、それらそれぞれのアプリケーションおよび特徴を知っている。

【0072】

予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で１つの動きベクトルおよび参照インデックスを使用する、イントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るもの、であってよい。

【0073】

双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2個の動きベクトルおよび参照インデックスを使用する、イントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るもの、であってよい。同様に、複数の予測ピクチャは、単一ブロックの再構成のために、2個以上の参照ピクチャおよび関連するメタデータを使用することができる。

【0074】

ソースピクチャは、通常、空間的に複数のサンプルコーディングブロック(例えば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック)へと分割され、そして、ブロック毎にコード化される。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように、他の(既にコード化された)ブロックを参照して予測的にコード化され得る。例えば、Iピクチャのブロックは、非予測的にコード化されてよく、または、それらは、同じピクチャの既にコード化されたブロック(空間的予測またはイントラ予測)を参照して予測的にコード化され得る。Pピクチャのピクセルブロックは、１つの以前にコード化された参照ピクチャを参照して、空間的予測を介して、または、時間的予測を介して予測的に符号化され得る。Bピクチャのブロックは、１つまたは2つの以前にコード化参照ピクチャを参照して、予測的に、空間的予測を介して、または時間的予測を介して、コード化され得る。ソースピクチャまたは中間処理されたピクチャは、他の目的のために、他のタイプのブロックへと細分化され得る。コーディングブロックおよび他のタイプのブロックの分割は、以下でさらに詳細に説明されるように、同じ方法に従ってよく、または、従わなくてよい。

【0075】

ビデオエンコーダ(603)は、ITU-T Rec.H.265.といった、事前決定されたビデオコーディング技術または標準に従って、コーディングオペレーションを実行することができる。そのオペレーションにおいて、ビデオエンコーダ(603)は、入力ビデオシーケンスにおける時間的および空間的冗長性を利用する予測コーディングオペレーションを含む、様々な圧縮オペレーションを実行することができる。コード化ビデオデータは、このように、使用されているビデオコーディング技術または標準によって指定されたシンタックスに従うことができる。

【0076】

いくつかの例示的な実施形態において、送信器(640)は、エンコード化ビデオと共に追加データを送信し得る。ソースコーダ(630)は、コード化ビデオシーケンスの一部として、そうしたデータを含むことができる。追加データは、時間的／空間的／SNR強調層、冗長ピクチャおよびスライス、SEIメッセージ、VUIパラメータセットフラグメント、などといった他の形式の冗長データ、を含み得る。

【0077】

ビデオは、時間シーケンスにおいて複数のソースピクチャ(ビデオピクチャ)としてキャプチャされ得る。イントラピクチャ予測(しばしば、イントラピクチャ予測と略される)は、所与のピクチャにおける空間的相関を利用し、そして、インターピクチャ予測は、ピクチャ間の時間的または他の相関を利用する。例えば、現在ピクチャと称される、エンコーディング／デコーディング中の特定のピクチャは、ブロックへとパーティション分割されてよい。現在ピクチャ内のブロックは、ビデオ内で以前にコード化され、かつ、依然としてバッファされている参照ピクチャにおける参照ブロックに類似する場合、動きベクトルと称されるベクトルによってコード化され得る。動きベクトルは、参照ピクチャ内の参照ブロックを指し、そして、複数の参照ピクチャが使用されている場合には、参照ピクチャを識別する第３ディメンションを有し得る。

【0078】

いくつかの例示的な実施形態において、インターピクチャ予測のために双予測（bi-prediction）技術が使用され得る。そうした両予測技術に従って、2個の参照ピクチャが使用される。第１参照ピクチャおよび第２参照ピクチャといったものであり、両方が、デコーディング順序で(しかい、それぞれ、過去または将来において、表示順序で)ビデオ内の現在ピクチャを進める。現在ピクチャ内のブロックは、第１参照ピクチャ内の第１基準ブロックを指し示す第１動きベクトル、および、第２参照ピクチャ内の第２基準ブロックを指し示す第２動きベクトルによって、コード化され得る。ブロックは、第１基準ブロックと第２基準ブロックの組み合わせによって、同時に予測され得る。

【0079】

さらに、コーディング効率を改善するために、インターピクチャ予測においてマージモード技術が使用され得る。

【0080】

本開示のいくつかの例示的実施形態に従って、インターピクチャ予測およびイントラピクチャ予測といった、予測は、ブロックのユニットにおいて実行される。例えば、ビデオピクチャのシーケンス内のピクチャは、圧縮のためにコーディングツリーユニット（CTU）へとパーティション分割され、ピクチャにおけるCTUは、64×64ピクセル、32×32ピクセル、または16×16ピクセルといった、同じサイズを有し得る。一般的に、CTUは、3つの並列コーディングツリーブロック(CTB)を含むことができる：１個のルマCTBと2個のクロマCTB。各CTUは、１つまたは複数のコーディングユニット(CU)に再帰的に四分木分割することができる。例えば、64×64ピクセルのCTUは、64×64ピクセルの１個のCU、または32×32ピクセルの4個のCUに分割することができる。32×32ブロックの１つ以上は、さらに16×16ピクセルの4CUに分割することができる。いくつかの例示的な実施形態において、各CUは、エンコーディングの最中に分析されて、インター予測タイプまたはイントラ予測タイプといった様々な予測タイプの中でCUの予測タイプを決定することができる。CUは、時間的及び／又は空間的予測可能性に依存して、１つ以上の予測ユニット(PU)へと分割され得る。一般的に、各PUは、ルマ予測ブロック(PB)と2つのクロマPBを含む。一つの実施形態において、コーディング(エンコーディング／デコーディング)における予測オペレーションは、予測ブロックのユニットにおいて実行される。CUのPU(または異なるカラーチャネルのPB)への分割は、様々な空間的パターンで実行され得る。ルマまたはクロマPBは、例えば、8×8ピクセル、16×16ピクセル、8×16ピクセル、16×8サンプルなどといった、サンプルの値(例えば、ルマ値)の行列を含んでよい。

【0081】

図7は、本開示の別の例示的実施形態に従って、ビデオエンコーダ(703)のダイアグラムを示している。ビデオエンコーダ(703)は、ビデオピクチャのシーケンスにおける現在ビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、そして、処理ブロックをコード化ビデオシーケンスの一部である、コード化ピクチャへとエンコーディングするように構成されている。例示的なビデオエンコーダ(703)は、図4の例におけるビデオエンコーダ(403)の代わりに使用することができる。

【0082】

例えば、ビデオエンコーダ(703)は、8×8サンプルの予測ブロックなど、といった処理ブロックのサンプル値の行列を受信する。次いで、ビデオエンコーダ(703)は、処理ブロックが、例えば、レート歪み最適化(RDO)を使用して、イントラモード、インターモード、または双予測モードを使用して、最良にコード化されるか否かを決定する。処理ブロックがイントラモードでコード化されると決定された場合、ビデオエンコーダ703は、処理ブロックをコード化ピクチャへとエンコーディングするためにイントラ予測技術を使用してよく、そして、処理ブロックがインターモードまたは双予測モードでエンコーディングされると決定された場合、ビデオエンコーダ703は、処理ブロックをコード化ピクチャへとエンコーディングするために、それぞれ、インター予測技術または双予測技術を使用してよい。いくつかの例示的な実施形態において、マージモードは、予測器の外側のコード化動きベクトル成分の利益を伴うことなく、動きベクトルが１つ以上の動きベクトル予測器から導出される、インターピクチャ予測のサブモードとして使用されてよい。いくつかの他の例示的な実施形態において、対象ブロック（subject block）に対して適用可能な動きベクトル構成要素が存在し得る。従って、ビデオエンコーダ(703)は、処理ブロックのパーティションモードを決定するために、モード決定モジュールといった、図7に明示的に示されていない構成要素を含んでよい。

【0083】

図7の例において、ビデオエンコーダ(703)は、インターエンコーダ(730)、イントラエンコーダ(722)、残差計算器(723)、スイッチ(726)、残差エンコーダ(724)、汎用コントローラ(721)、および、図7の例の構成で示されるように一緒に結合されたエントロピーエンコーダ(725)を含んでいる。

【0084】

インターエンコーダ(730)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、ブロックを参照ピクチャ内の１つ以上の参照ブロック(例えば、表示順序で以前のピクチャおよび後のピクチャにおけるブロック)と比較し、インター予測情報(例えば、インターエンコーディング技術に従った冗長情報の記述、動きベクトル、マージモード情報)を生成し、そして、任意の適切な技術を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成されている。いくつかの例において、参照ピクチャは、図6の例示的なエンコーダ620に埋め込まれたデコーディングユニット633を使用して(以下でさらに詳細に説明するように、図7の残差デコーダ728として示される)、エンコーディングされたビデオ情報に基づいてデコーディングされる、デコーディングされた参照ピクチャである。

【0085】

イントラエンコーダ(722)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、そのブロックを同じピクチャ内で既にコード化されたブロックと比較し、かつ、変換後に量子化された係数を生成し、そして、場合によっては、イントラ予測情報(例えば、１つ以上のイントラエンコーディング技術に従ったイントラ予測方向情報)も生成するように構成されている。イントラエンコーダ(722)は、同じピクチャ内のイントラ予測情報および参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)を計算することができる。

【0086】

汎用コントローラ(721)は、一般的制御データを決定し、そして、一般的制御データに基づいてビデオエンコーダ(703)の他の構成要素を制御するように構成することができる。一つの例において、汎用コントローラ(721)は、ブロックの予測モードを決定し、そして、予測モードに基づいて、スイッチ(726)に制御信号を供給する。例えば、予測モードがイントラモードである場合、汎用コントローラ721は、スイッチ726を制御して、残差計算器723による使用のためのイントラモード結果を選択し、そして、エントロピーエンコーダ725を制御して、イントラ予測情報を選択し、かつ、ビットストリームにイントラ予測情報を含める。そして、ブロックの予測モードがインターモードである場合、汎用コントローラ721は、スイッチ726を制御して、残差計算器723による使用のためのインター予測結果を選択し、エントロピーエンコーダ725を制御して、インター予測情報を選択し、かつ、ビットストリームにインター予測情報を含める。

【0087】

残差計算器(723)は、イントラエンコーダ(722)またはインターエンコーダ(730)から選択されたブロックについて、受信されたブロックと予測結果との差異(残差データ)を計算するように構成することができる。残差エンコーダ(724)は、変換係数を生成するために、残差データをエンコーディングするように構成することができる。例えば、残差エンコーダ(724)は、残差データを空間ドメインから周波数ドメインに変換して、変換係数を生成するように構成することができる。次いで、変換係数は、量子化処理にかけられ、量子化された変換係数を獲得する。様々な例示的な実施形態において、ビデオエンコーダ(703)は、また、残差デコーダ(728)も含んでいる。残差デコーダ(728)は、逆変換を実行し、そして、デコーディングされた残差データを生成するように構成されている。デコーディングされた残差データは、イントラエンコーダ(722)およびインターエンコーダ(730)によって適切に使用することができる。例えば、インターエンコーダ(730)は、デコーディングされた残差データおよびインター予測情報に基づいてデコーディングされたブロックを生成することができ、そして、イントラエンコーダ(722)は、デコーディングされた残差データおよびイントラ予測情報に基づいてデコーディングされたブロックを生成することができる。デコーディングされたブロックは、デコーディングされたピクチャを生成するために適切に処理され、そして、デコーディングされたピクチャは、メモリ回路(図示なし)においてバッファリングされ、かつ、参照ピクチャとして使用され得る。

【0088】

エントロピーエンコーダ(725)は、エンコーディングされたブロックを含むようにビットストリームをフォーマットし、そして、エントロピーコーディングを実行するように構成することができる。エントロピーエンコーダ(725)は、ビットストリーム内に様々な情報を含むように構成されている。例えば、エントロピーエンコーダ(725)は、一般的な制御データ、選択された予測情報(例えば、イントラ予測情報またはインター予測情報)、残差情報、および、ビットストリーム内の他の適切な情報を含むように構成することができる。インターモードまたは双予測モードいずれかのマージサブモードでブロックをコーディングする場合、残差情報は存在しなくてよい。

【0089】

図8は、本開示の別の実施形態に従って、例示的なビデオデコーダ(810)のダイアグラムを示している。ビデオデコーダ(810)は、コード化ビデオシーケンスの一部であるコード化ピクチャを受信し、そして、コード化ピクチャをデコーディングして、再構成されたピクチャを生成するように構成されている。一つの実施形態においては、図4の実施形態でのビデオデコーダ(410)の代わりに、ビデオデコーダ(810)が使用され得る。

【0090】

図8の例において、ビデオデコーダ(810)は、エントロピーデコーダ(871)、インターデコーダ(880)、残差デコーダ(873)、再構成モジュール(874)、および、図8の例示の構成に示されるように一緒に結合されたイントラデコーダ(872)を含んでいる。

【0091】

エントロピーデコーダ(871)は、コード化ピクチャから、そのコード化ピクチャが構成されるシンタックス要素を表す特所定のシンボルを再構成するように構成することができる。そうしたシンボルは、例えば、ブロックがコード化されるモード(例えば、イントラモード、インターモード、双予測モード、マージサブモード、または他のサブモード)、イントラデコーダ(872)またはインターデコーダ(880)によって予測のために使用される所定のサンプルまたはメタデータを識別することができる予測情報(例えば、イントラ予測情報またはインター予測情報)、例えば、量子化された変換係数の形式の残差情報、などを含むことができる。一つの例として、予測モードがインターまたは双予測モードである場合、インター予測情報がインターデコーダ(880)に提供され、そして、予測タイプがイントラ予測タイプである場合、イントラ予測情報がイントラデコーダ(872)に提供される。残差情報は、逆量子化を受けることができ、そして、残差デコーダ(873)に提供される。

【0092】

インターデコーダ(880)は、インター予測情報を受信し、そして、インター予測情報に基づいてインター予測結果を生成するように構成することができる。

【0093】

イントラデコーダ(872)は、イントラ予測情報を受信し、そして、イントラ予測情報に基づいて予測結果を生成するように構成することができる。

【0094】

残差デコーダ(873)は、逆量子化変換係数を抽出するために逆量子化を実行し、そして、脱量子化（de-quantized）変換係数を処理して、残差を周波数領域から空間領域に変換するように構成することができる。残差デコーダ(873)は、また、エントロピーデコーダ(871)によって提供され得る、所定の制御情報(量子化器パラメータ(Quantizer Parameter、QP)を含む)を利用することもできる(データ経路は、低データ量制御情報だけであり得るので、図示されてない)。

【0095】

再構成モジュール(874)は、空間領域において、残差デコーダ(873)による出力としての残差と、予測結果(場合によっては、インターまたはイントラ予測モジュールによる出力としてのもの)とを組み合わせて、再構成ビデオの一部として再構成されたピクチャの一部を形成する再構成されたブロックを形成するように構成することができる。デブロッキングオペレーション、等の他の適切なオペレーションも、また、視覚品質を改善するために実施することができることに留意されたい。

【0096】

ビデオエンコーダ(403)、(603)、および(703)、並びに、ビデオデコーダ(410)、(510)、および(810)は、任意の適切な技術を使用して実施することができることに留意すること。いくつかの例示的な実施形態において、ビデオエンコーダ(403)、(603)、および(703)、並びに、ビデオデコーダ(410)、(510)、および(810)は、１つ以上の集積回路を使用して実施することができる。別の実施形態において、ビデオエンコーダ(403)、(603)、および(603)、並びに、ビデオデコーダ(410)、(510)、および(810)は、ソフトウェア命令を実行する１つ以上のプロセッサを使用して実施することができる。

【0097】

コーディングおよびデコーディングのためのブロックパーティション分割に目を向けると、一般的な分割はベースブロックから開始して、事前定義されたルールセット、特定のパターン、パーティションツリー、または、任意のパーティション構造またはスキームに従うことができる。パーティション分割は、階層的かつ再帰的である。以下に説明されるパーティション分割プロシージャまたは他のプロシージャの例、または、それらの組み合わせに従って、ベースブロックを分割またはパーティション分割した後で、最終的なパーティションまたはコーディングブロックのセットを得ることができる。これらの各パーティションは、パーティション階層内の様々なパーティションレベルのいずれかにあり、そして、様々な形状であり得る。各パーティションは、コーディングブロック(CB)として称され得る。以下でさらに説明される様々なパーティション分割の実装の例において、結果として得られる各CBは、許容されるサイズおよびパーティション分割レベルのいずれかであり得る。そうしたパーティションは、コーディングブロックと称される。なぜなら、呼ばれます。いくつかの基本的なコーディング/デコーディング決定が行われ、そして、コーディング/デコーディングパラメータが最適化され、決定され、かつ、エンコーディングされたビデオビットストリームで信号化され得る、ユニットを形成する可能性があるからである。最終的なパーティションの最上位または最深レベルは、ツリーのコーディングブロックパーティション分割構造の深さを表している。コーディングブロックは、ルマコーディングブロックまたはクロマコーディングブロックであり得る。各色のCBツリー構造は、コーディングブロックツリー(CBT)として称され得る。

【0098】

全てのカラーチャネルのコーディングブロックは、まとめてコーディングユニット(CU)として称され得る。全てのカラーチャネルの階層構造は、まとめてコーディングツリーユニット(CTU)として称され得る。CTU内の様々なカラーチャネルについてパーティション分割パターンまたは構造は、同じであってよく、または、そうでなくてよい。

【0099】

いくつかの実装において、ルマチャネルおよびクロマチャネルに使用されるパーティション分割ツリースキームまたは構造は、同じである必要がない場合がある。別段の定めがない限り、ルマチャネルおよびクロマチャネルは、別々のコーディングツリー構造またはパターンを有し得る。さらに、ルマチャネルおよびクロマチャネルが同じまたは異なるコーディングパーティションツリー構造を使用するか否か、および、実際に使用されるコーディングパーティションツリー構造は、コード化されるスライスがP、B、またはIスライスであるか否かに依存し得る。例えば、Iスライスについて、クロマチャネルおよびルマチャネルは、別々のコーディングパーティションツリー構造またはコーディングパーティションツリー構造モードを有し得るが、一方で、PまたはBスライスについて、ルマチャネルおよびクロマチャネルは、同じコーディングパーティションツリー構造を共有し得る。別々のコーディングパーティションツリー構造またはモードが適用される場合、ルマチャネルは、1個のコーディングパーティションツリー構造によってCBへとパーティション分割され、そして、クロマチャネルは、別のコーディングパーティションツリー構造によってクロマCBへとパーティション分割され得る。

【0100】

いくつかの実装例において、事前に決められた分割パターンをベースブロックに適用することができる。図9に示されるように、4方向（4-way）パーティションツリーの例では、第１事前定義されたレベル(例えば、基本ブロックサイズとして64×64ブロックレベルまたは他のサイズ)から開始し、そして、ベースブロックを、事前定義された最下位レベル(例えば、4×4レベル)まで階層的にパーティション分割することができる。例えば、ベースブロックは、902、904、906、および908で示される4個の事前定義されたパーティションオプションまたはパターンの対象となり、Rとして指定されたパーティションは、図9に示されるのと同じパーティションオプションを最下位レベル(例えば、4×4レベル)まで下位スケールで繰り返すことができるという再帰的パーティション分割が許される。いくつかの実装において、図9のパーティションスキームに追加の制限が適用され得る。図9の実装においては、長方形パーティション(例えば、1:2/2:1の長方形パーティション)が許されるが、再帰的にはできない。一方で、正方形パーティションは再帰的にすることができる。図9に続く再帰を伴うパーティション分割は、必要に応じて、コーディングブロックの最終セットを生成する。ルートノードまたはルートブロックからの分割の深さを示すために、コーディングツリーの深さを、さらに定義することができる。例えば、64×64ブロックのルートノードまたはルートブロックについてコーディングツリーの深さが0に設定されてよく、そして、図9に続いてルートブロックをさらに１回分割した後で、コーディングツリーの深さを１だけ増やすことができる。64×64ベースブロックから4×4の最小パーティションまでの最大または最も深いレベルは、上記のスキームでは4(レベル0から開始)になる。そうしたパーティション分割スキームは、１つ以上のカラーチャネルに適用され得る。各カラーチャネルは、図9のスキームに従って独立してパーティション分割することができる(例えば、事前定義されたパターン間の分割パターンまたはオプションは、各階層レベルのカラーチャネルごとに独立して決定され得る)。代替的に、２つ以上のカラーチャネルは、図9の同じ階層パターンツリーを共有することができる(例えば、各階層レベルの２つ以上のカラーチャネルについて、事前定義されたパターンの中から同じ分割パターンまたはオプションを選択することができる)。

【0101】

図10は、再帰的なパーティショニングがパーティション分割ツリーを形成するのを可能にする別の例の事前定義された分割パターンを示している。図10に示されるように、例示的な10個のパーティション分割構造またはパターンを事前定義され得る。ルートブロックは、事前定義されたレベル(例えば、128×128レベル、または64×64レベルでのベースブロック)から開始し得る。図10の例示的なパーティション分割構造は、様々な2:1/1:2および4:1/1:4の矩形パーティションを含んでいる。なお、図10の第２行に示されている3個のサブパーティションを有するパーティションタイプは、「T型（“T-type”）」パーティションと称され得る。「T型」パーティション1002、1004、1006、および1008は、左T型（Left T-Type）、上T型（Top T-Type）、右T型（Right T-Type）、下T型（Bottom T-Type）と称され得る。いくつかの例示的な実装において、図10の矩形パーティションのいずれも、さらに細分化することは許されない。ルートノードまたはルートブロックからの分割深さを示すために、コーディングツリーの深さが、さらに定義されてよい。例えば、ルートノードまたはルートブロック、例えば、128×128ブロック、コーディングツリー深さ、は、0に設定されてよく、そして、ルートブロックが図10に続いてさらに分割された後で、コーディングツリー深さは、1だけ増加される。いくつかの実装においては、図10のパターンに従って、パーティション分割ツリーの次のレベルへと再帰的なパーティション分割するために、1010のオールスクェア（all-square）パーティションのみが許可されてよい。別の言葉で言えば、T型パターン1002、1004、1006、および1006を有する正方形パーティションに対して、再帰パーティションが許可されないことがある。再帰を伴う図10に続くパーティション分割プロシージャは、必要であれば、コーディングブロックの最終セットを生成する。そうしたスキームは、１つ以上のカラーチャネルに適用され得る。いくつかの実装においては、8×8レベル以下のパーティションの使用に対して、より多くの柔軟性が追加され得る。例えば、2×2クロマインター予測が所定のケースで使用され得る。

【0102】

コーディングブロック分割について他のいくつかの実装例において、ベースブロックまたは中間ブロックを四分木パーティションへと分割するために四分木構造が使用され得る。そうした四分木分割（quadtree splitting）は、任意の正方形のパーティションに階層的かつ再帰的に適用され得る。ベースブロック、または中間ブロック、もしくはパーティションのいずれがさらに四分木分割であるかは、ベースブロックまたは中間ブロック/パーティションの様々なローカル特性に適応させることができる。ピクチャ境界での四分木パーティション分割が、さらに適応され得る。例えば、ピクチャ境界で黙示的な四分木分割が実行されてよく、その結果、ブロックは、サイズがピクチャ境界に合うまで四分木分割を維持する。

【0103】

いくつかの他の実装例においては、ベースブロックから階層的バイナリパーティション分割を使用することができる。そうしたスキームについて、ベースブロックまたは中間レベルブロックは、2個のパーティションへとパーティション分割することができる。バイナリパーティション分割は、水平または垂直のいずれかであり得る。例えば、水平バイナリパーティション分割は、ベースブロックまたは中間ブロックを均等な左右のパーティションへと分割することができる。同様に、垂直バイナリパーティション分割は、ベースブロックまたは中間ブロックを均等な上下のパーティションへと分割することができる。そうしたバイナリパーティションは、階層的で、かつ、再帰的であり得る。ベースブロックまたは中間ブロックのそれぞれで、バイナリパーティション分割スキームを継続するか否か、そして、スキームがさらに継続する場合は、水平または垂直のバイナリパーティション分割を使用するか否かの決定がなされ得る。いくつかの実装において、さらなるパーティション分割は、事前定義された最小のパーティションサイズ(一方または両方のディメンション)で停止し得る。代替的には、一旦、事前定義された分割レベルまたはベースブロックからの深さに達すると、さらなるパーティション分割が停止し得る。いくつかの実装において、パーティションの縦横比が制限され得る。例えば、パーティションの縦横比は、1:4より小さく(または、4:1より大きく)することはできない。かくして、水平に対する垂直の縦横比が4:1である垂直ストリップパーティションは、さらに、水平に対する垂直の縦横比がそれぞれ2:1である上部パーティションおよび下部パーティションへと垂直にバイナリパーティション分割されるだけである。

【0104】

さらにいくつかの他の例では、図13に示されるように、ベースブロックまたは任意の中間ブロックを分割するために、三項（ternary）パーティション分割スキームを使用することができる。三項パターンは、図13の1302に示されるように、垂直に、または、図13の1304に示されるように、水平に実装することができる。図13における例示的な分割比は、垂直または水平で、1:2:1と示されているが、他の比率が事前定義されてよう。いくつかの実装においては、２つ以上の異なる比率が事前定義されてよい。そうした三項分割スキームは、四分木またはバイナリのパーティション分割構造を補完するために使用することができる。そうした三項分割は、1個の連続したパーティション内のブロックセンターに位置するオブジェクトをキャプチャすることができるが、四分木およびバイナリは常にブロックセンターに沿って分割されるため、オブジェクトを別々のパーティションへと分割する。いくつかの実装においては、追加の変換を避けるために、例示的な3分木（triple tree）のパーティションの幅と高さは、常に2の累乗である。

【0105】

上記のパーティション分割スキームは、異なる分割レベルにおいて任意の方法で組み合わせることができる。一例として、上記の四分木およびバイナリのパーティション分割スキームを組み合わせて、ベースブロックを四分木バイナリ(quadtree-binary-tree、QTBT)構造へと分割することができる。そうしたスキームにおいて、ベースブロックまたは中間ブロック/パーティションは、指定されている場合、一連の事前定義された条件に従って、四分木分割またはバイナリのいずれかであり得る。特定の例が図14に示されている。図14の例において、ベースブロックは、1402、1404、1406、および1408で示されるように、4個のパーティションへと分割された第１四分木である。それ以降、結果として得られるパーティションそれぞれは、4個のさらなるパーティションへと四分木パーティション分割されるか(1408のように)、次のレベルで2個のさらなるパーティションへとバイナリ分割されるか(例えば、1402または1406のように、水平方向または垂直方向のいずれかで、両方とも対称である)、分割されないか(1404のように)のいずれかである。バイナリまたは四分木の分割は、1410の全体的な例の分割パターンおよび1420の対応するツリー構造/表現に示されているように、正方形のパーティションに対して再帰的に許可されてよく、そこで、実線は四分木分割を表し、そして、破線は、バイナリ分割を表している。バイナリ分割が水平または垂直のいずれかを示すために、各バイナリ分割ノード(非リーフバイナリパーティション)についてフラグを使用することができる。例えば、1420に示されるように、1410のパーティション分割構造と一致して、フラグ「0」は水平バイナリ分割を表し、そして、フラグ「1」は垂直バイナリ分割を表すことができる。四分木分割パーティションの場合、四分木分割は常にブロックまたはパーティションを水平および垂直に分割して、同じサイズの4個のサブブロック/パーティションを生成するので、分割の種類を示す必要はない。いくつかの実装において、フラグ「1」は水平方向のバイナリ分割を表し、そして、フラグ「0」は垂直方向のバイナリ分割を表すことができる。

【0106】

QTBTのいくつかの実装例において、四分木およびバイナリ分割のルールセットは、次の事前定義されたパラメータ及びそれに関連付けられた対応する機能によって表され
得る。
－CTUサイズ：四分木のルートノードのサイズ(ベースブロックのサイズ)
－MinQTSize：四分木リーフノードの最小許容サイズ
－MaxBTSize：バイナリツリールートノードの最大許容サイズ
－MaxBTDepth：バイナリツリーの最大許容深さ
－MinBTSize：バイナリツリーリーフノードの最小許容サイズ
QTBTパーティション分割構造のいくつかの実装例において、CTUサイズは、対応する2つの64×64ブロックのクロマサンプル(クロマサブサンプリングの例を考慮して使用する場合)で128×128ルマサンプルとして設定され、MinQTSizeは16×16、MaxBTSizeは64×64、MinBTSize(幅および高さの両方)は4×4、MaxBTDepthは4として設定され得る。四分木リーフノードを生成するために、最初に、四分木パーティショニングがCTUに適用され得る。四分木リーフノードは、最小許容サイズの16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを有し得る。ノードが128×128である場合、サイズがMaxBTSize(すなわち、64×64)を超えるので、バイナリツリーによって最初に分割されることはない。そうでなければ、MaxBTSizeを超えないノードがバイナリツリーによって分割され得る。図14の例において、ベースブロックは128×128である。基本ブロックは、事前定義されたルールセットに従って、四分木分割のみが可能である。基本ブロックは、パーティション分割の深さが0である。結果として得られる4個のパーティションそれぞれは、64×64であり、MaxBTSizeを超えず、レベル1でさらに四分木またはバイナリツリーに分割することができる。プロセスは、続行される。バイナリツリーの深さがMaxBTDepth (すなわち、4)に達すると、それ以上の分割は考慮されなくなる。バイナリツリーノードがMinBTSize (すなわち4)と等しい幅を有すると、それ以上の水平分割は考慮されなくなる。同様に、バイナリツリーノードがMinBTSizeと等しい高さを有すると、それ以上の垂直分割は考慮されない。

【0107】

いくつかの実装例において、上のQTBTスキームは、ルマおよびクロマが同じQTBT構造または別々のQTBT構造を持つ柔軟性をサポートするように構成され得る。例えば、PスライスおよびBスライスについて、１つのCTU内のルマおよびクロマのCTBは、同じQTBT構造を共有し得る。しかしながら、Iスライスについて、ルマのCTBはQTBT構造によってCBに分割され、そして、クロマのCTBは別のQTBT構造によってクロマのCTBへとパーティション分割され得る。これは、CUがIスライス内の異なるカラーチャネルを参照するために使用され得ることを意味する。例えば、Iスライスはルマ成分のコーディングブロックまたは2個のクロマ成分のコーディングブロックで構成され、そして、PまたはBスライス内のCUは3個のカラー成分全てのコーディングブロックで構成され得る。

【0108】

他のいくつかの実装において、QTBTスキームは、前述の三項スキーム（ternary scheme）を用いて補足され得る。そうした実装は、マルチタイプツリー(MTT)構造として称され得る。例えば、ノードのバイナリ分割に加えて、図13の三項分割パターンの１つを選択することができる。いくつかの実装においては、四角ノードのみが三項分割の対象となり得る。追加のフラグを使用して、三項分割が水平か垂直か示すことができる。

【0109】

QTBT実装、および、三項分割によって補完されるQTBT実装といった、2レベルまたはマルチレベルのツリーの設計は、主に複雑さの軽減によって動機付けられ得る。理論的には、ツリーを横断する複雑さはT^Dであり、ここで、Tは分割タイプ型の数を示し、そして、Dはツリーの深さである。深さ(D)を減らしながら、複数のタイプ(T)を使用することによって、トレードオフがなされ得る。

【0110】

いくつかの実装において、CBはさらにパーティション分割され得る。例えば、CBは、コーディングおよびデコーディングプロセスの最中のイントラフレームまたはインターフレーム予測の目的のために、複数の予測ブロック（PB）へとさらにパーティション分割されてよい。別の言葉で言えば、CBは、異なるサブパーティションへとさらに分割され、そこで、個々の予測決定／構成が行われ得る。並行して、CBは、ビデオデータの変換または逆変換が実行されるレベルを表現する目的のために、複数の変換ブロックへとさらにパーティション分割される。PBおよびTBへのCBのパーティション分割スキームは、同じであってよく、または、そうでなくてよい。例として、各パーティション分割スキームは、例えば、ビデオデータの様々な特性に基づいて、それ自身のプロシージャを使用して実行されてよい。PBおよびTBのパーティション分割スキームは、いくつかの例示的な実装において、独立し得る。PBおよびTBのパーティション分割スキームおよび境界は、いくつかの他の例示的な実装において相関させることができる。いくつかの実装において、例えば、TBは、PBパーティション分割の後でパーティション分割されてよく、そして、特に、各PBは、コーディングブロックの次のパーティションが決定された後、１つ以上のTBへとさらに分割され得る。例えば、いくつかの実装において、PBは１個、2個、4個、または他の個数のTBへと分割され得る。

【0111】

いくつかの実装において、ベースブロックを、コーディングブロへと、そして、さらに予測ブロック及び／又は変換ブロックへとパーティション分割するために、ルマチャネルおよびクロマチャネルは、異なって処理されてよい。例えば、いくつかの実装において、コーディングブロックの予測ブロック及び／又は変換ブロックへのパーティション分割がルマチャネルについて許可されてよいが、一方、そうしたコーディングブロックの予測ブロック及び／又は変換ブロックへのパーティション分割がクロマチャネルについて許可されなくてよい。そうした実装において、ルマブロックの変換及び／又は予測は、従って、コーディングブロックレベルでのみ実行され得る。別の例において、ルマチャネルとおよびクロマチャネルの最小変換ブロックサイズは、異なってよい。例えば、ルマチャネルのコーディングブロックは、クロマチャネルよりも小さな変換ブロック及び／又は予測ブロックへとパーティション分割されることが許容され得る。さらに別の例において、コーディングブロックの変換ブロック及び／又は予測ブロックへのパーティション分割の最大深さは、ルマチャネルおよびクロマチャネルとの間で異なってよい。例えば、ルマチャネルのコーディングブロックは、クロマチャネルよりも深い変換及び／又は予測ブロックへとパーティション分割されることが許容され得る。特定の例において、ルマコーディングブロックは、最大2レベルまで下がる再帰的なパーティションによって表現され得る、複数のサイズの変換ブロックへと分割されてよく、そして、正方形といった変換ブロック形状、2:1/1:2、および4:1/1:4、そして、4×4から64×64への変換ブロックサイズが許可され得る。しかしながら、クロマブロックについては、ルマブロックに対して指定された最大の可能な変換ブロックのみが許可され得る。

【0112】

コーディングブロックをPBへとパーティション分割するためのいくつかの例示的な実装において、PBパーティション分割の深さ、形状、及び／又は、他の特性は、PBがイントラコード化であるか、または、インターコード化であるかに依存し得る。

【0113】

コーディングブロック(または予測ブロック)の変換ブロックへのパーティション分割は、これらに限定されるわけではないが、再帰的または非再帰的に、そして、コーディングブロックまたは予測ブロックの境界での変換ブロックについて追加的に考慮した、四分木分割および所定のパターン分割を含む、様々な例示的なスキームで実装され得る。一般的に、結果として生じる変換ブロックは、異なる分割レベルであってよく、同じサイズでなくてよく、そして、正方形の形状である必要がなくてよい(例えば、それらは、許容されるサイズおよびアスペクト比を有する矩形であり得る)。さらなる例は、図15、16、および17に関連して、以下でさらに詳細に説明される。

【0114】

しかしながら、いくつかの他の実装では、上記のパーティション分割スキームのいずれかを介して獲得されたCBを、予測及び／又は変換のために基本または最小のコーディングブロックとして使用することができる。別の言葉で言えば、インター予測/イントラ予測の目的、及び／又は、変換の目的で、それ以上の分割は行われない。例えば、上記のQTBTスキームから獲得されたCBは、予測を実行するためのユニットとして直接的に使用され得る。具体的に、そうしたQTBT構造は、複数のパーティションのタイプの概念を削除する。つまり、CU、PU、およびTUの分離を削除し、そして、上記のようにCU/CBパーティション形状について、より多くの柔軟性をサポートする。そうしたQTBTブロック構造において、CU/CBは、正方形または長方形いずれかの形状を有することができる。そうしたQTBTのリーフノードは、それ以上パーティション分割することなく、予測および変換処理のユニットとして使用される。これは、そうした例示的なQTBTコーディングブロック構造において、CU、PU、およびTUのブロックサイズが、同じであることを意味する。

【0115】

上記の様々なCB分割スキーム、および、PB及び／又はTBへのCBのさらなるパーティション分割(PB/TBパーティション分割なしを含む)は、任意の方法で組み合わせることができる。以下の特定の実装は、非制限的な例として提供されている。

【0116】

コーディングブロックおよび変換ブロックのパーティション分割の具体的な例示的な実装が以下で説明される。そうした例示的な実装において、ベースブロックは、上述した再帰的四分木分割、または事前定義された分割パターン（図9および図10におけるものなど）を使用してコーディングブロックへと分割され得る。各レベルにおいて、特定のパーティションの更なる四分木分割を継続すべきか否かは、ローカルビデオデータ特性によって決定され得る。結果として生じるCBは、様々なサイズの、そして、様々な四分木分割レベルであり得る。インターピクチャ(時間的)またはイントラピクチャ(空間的)予測を使用してピクチャ領域をコード化するか否かの決定は、CBレベル(または、CUレベル、全ての3カラーチャネルについて)で行うことができる。各CBは、事前定義されたPB分割タイプに従って、１個、2個、4個、または他の個数のPBへと、さらに分割され得る。１つのPBの内部では、同じ予測プロセスが適用されてよく、そして、関連情報がPBベースでデコーダに送信され得る。PBの分割タイプに基づいて予測プロセスを適用することによって残差ブロックを獲得した後、CBが、CBのコーディングツリーに類似した別の四分木構造に従ってTBへとパーティション分割され得る。この特定な実装において、CBまたはTBは、正方形に限定され得るが、必ずしも限定される必要はない。さらに、この特定な実装において、PBは、インター予測のために正方形または長方形の形状であってよく、そして、イントラ予測のために正方形だけであってよい。コーディングブロックは、例えば、4個の正方形のTBへと、分割され得る。各TBは、再帰的に(四分木分割を使用して)より小さなTB、残差四分木（Residual Quad-Tree、RQT)と称されるもの、へと、さらに分割され得る。

【0117】

ベースブロックをCB、および、他のPB及び／又はTBへとパーティション分割するための別の例示的な実装が、以下でさらに説明される。例えば、図9または図10に示されているものといった、複数のパーティションユニットタイプを使用するのではなく、むしろ、バイナリ（binary）分割および三項（ternary）分割セグメンテーション構造（例えば、QTBTまたは上記のように三項分割を用いるQTBT）を使用する、ネストされたマルチタイプのツリーを有する四分木を使用することができる。CB、PB、およびTBの概念の分離(すなわち、CBをPB及び／又はTBへとパーティション分割すること、および、PBをTBへとパーティション分割すること)は、最大変換長に対して大き過ぎるサイズを有するCBについて必要とされる場合を除き、放棄されることがあり、そうしたCBは、さらなる分割を必要とし得る。この例示的なパーティション分割スキームは、予測および変換の両方が、さらなる分割なしにCBレベルで実行され得るように、CBのパーティション分割形状に対してよりフレキシビリティをサポートするように設計され得る。そうしたコーディングツリー構造において、CBは、正方形または長方形のいずれかの形状を有し得る。具体的には、コーディングツリーブロック(CTB)は、最初に、四分木構造によって分割される。次いで、四分木リーフノードは、ネストされたマルチタイプツリー構造によってさらにパーティション分割され得る。バイナリ分割また三項分割を使用するネストされたマルチタイプツリー構造の一つの例が図11に示されている。具体的には、図11の例示的なマルチタイプツリー構造は、4個の分割タイプを含んでいる。垂直バイナリ分割(SPLIT_BT_VER)(1102)、水平バイナリ分割(SPLIT_BT_HOR)(1104)、垂直三項分割(SPLIT_TT_VER)(1106)、水平三項分割(SPLIT_TT_HOR)(1108)と称されるものである。CBは、次いで、マルチタイプツリーのリーフに対応する。この例示的な実装においては、CBが最大変換長に対して大き過ぎなければ、このセグメンテーションは、任意のさらなるパーティション分割なしで、予測および変換処理の両方について使用される。このことは、ほとんどの場合、CB、PB、およびTBが、ネストされたマルチタイプのツリーコーディングブロック構造を持つ四分木において、同じブロックサイズを有することを意味する。例外は、サポートされる変換長の最大値がCBのカラー成分の幅または高さよりも小さい場合に発生する。いくつかの実装では、バイナリ分割または三項分割に加えて、図11のネストされたパターンは、さらに、四分木分割を含み得る。

【0118】

１つのCTBに対するブロックパーティションのネストされたマルチタイプのツリーコーディングブロック構造を有する四分木について一つの特定の例が図12に示されている（四分木分割、バイナリ分割、または三項分割のオプションを含んでいる）。より詳細には、図12は、ベースブロック1200が4個の正方形パーティション1202、1204、1206、および1208へと四分木分割されていることを示している。さらなる分割のために図11のマルチタイプツリー構造および四分木をさらに使用する決定が、四分木分割パーティションそれぞれに対して行われる。図12の例において、パーティション1204は、それ以上分割されない。パーティション1202および1208は、それぞれ、別の四分木分割を採用する。パーティション1202について、第２レベルの四分木分割された左上（top-left）、右上（top-right）、左下（bottom-left）、および右下（bottom-right）のパーティションは、それぞれに、四分木、図11の水平バイナリ分割1104、非分割、および図11の水平三項分割1108である、第3レベルの分割を採用している。パーティション1208は、別の四分木分割を採用しており、そして、第２レベルの四分木分割の左上、右上、左下、および右下パーティションは、それぞれに、図11の垂直三項分割1106、非分割、および図11の水平バイナリ分割1104である、第3レベルの分割を採用している。1208の第3レベルの左上のパーティションの2個のサブパーティションは、図11の水平バイナリ分割1104および水平三項分割1108に従ってさらに分割されている。パーティション1206は、2つのパーティションへの図11の垂直バイナリ分割1102に続く第２レベル分割パターンを採用し、図11の水平三項分割1108および垂直バイナリ分割1102に従って第3レベルにおいてさらに分割される。第4のレベル分割が、さらに、図11の水平バイナリ分割1104に従って、それらのうち１つに適用される。

【0119】

上記の特定な例において、最大ルマ変換サイズは64×64であってよく、そして、サポートされる最大クロマ変換サイズは、例えば、32×32で、ルマと異なり得る。図12の上記の例のCBは、一般的に、より小さなPB及び／又はTBへとさらに分割されていないが、ルマコーディングブロックまたはクロマコーディングブロックの幅または高さが、最大変換幅または高さよりも大きい場合、ルマコーディングブロックまたはクロマコーディングブロックは、その方向における変換サイズの制限を満たすように、自動的に水平方向及び／又は垂直方向において分割される。

【0120】

ベースブロックを上記のCBへとパーティション分割する特定の例において、そして、上述のように、コーディングツリースキームは、ルマとクロマが別々のブロックツリー構造を有する能力をサポートすることができる。例えば、PおよびBスライスについて、１つのCTUにおけるルマCTBおよびクロマCTBは、同じコーディングツリー構造を共有することができる。例えば、Iスライスについて、ルマおよびクロマは、別個のコーディングブロックツリー構造を有し得る。個別のブロックツリー構造が適用される場合、ルマCTBは、１つのコーディングツリー構造によってルマCBへとパーティション分割され、そして、クロマCTBは、別のコーディングツリー構造によってクロマCBへとパーティション分割される。このことは、IスライスのCUが、ルマ成分のコーディングブロック、または、2個のクロマ成分のコーディングブロックで構成されている可能性があり、そして、PまたはBスライスにおけるCUは、ビデオがモノクロでなければ、常に、3個のカラー成分全てのコーディングブロックで構成されていることを意味する。

【0121】

コーディングブロックがさらに複数の変換ブロックへと分割される場合、その中の変換ブロックは、様々な順序またはスキャン方法に従ってビットストリーム内で順序付けされ得る。コーディングブロックまたは予測ブロックを変換ブロックへと分割するための例示的な実装、および、変換ブロックのコーディング順序が、以下でさらに詳細に説明される。いくつかの例示的な実装において、上述のように、変換パーティション分割は、複数形状の変換ブロック、例えば、1:1(正方形)、1:2/2:1、および1:4/4:1、をサポートすることができ、変換ブロックサイズは、例えば、4×4から64×64までの範囲である。いくつかの実装において、コーディングブロックが64×64以下である場合、変換ブロックパーティション分割は、ルマ成分にのみ適用可能であり、クロマブロックについて、変換ブロックサイズはコーディングブロックのサイズと同一である。そうでなければ、コーディングブロックの幅または高さが64より大きい場合には、ルマおよびクロマコーディングブロックの両方が、それぞれに、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)変換ブロックの複数個へと暗黙的に分割され得る。

【0122】

変換ブロックのパーティション分割に係るいくつかの例示的な実装において、イントラおよびインターコーディングブロックの両方について、コーディングブロックは、事前定義された数のレベル(例えば、2レベル)までのパーティション分割深さを有する複数の変換ブロックへと、さらに分割され得る。変換ブロックパーティション分割の深さおよびサイズは、関連し得る。いくつかの例示的な実装について、現在深さの変換サイズ（Transform size of current depth）から次の深さの変換サイズ（Transform size of next depth）へのマッピングが表1に示されている。

【表1】

表１：変換パーティションサイズ設定

【0123】

表1の例示的なマッピングに基づいて、1:1正方形ブロックについて、次のレベル変換分割は、4個の1:1の正方形サブ変換ブロックを生成し得る。変換パーティションは、例えば4×4で停止してよい。従って、現在深さ4×4の変換サイズは、次の深さ4×4の同じサイズに対応する。表1の例において、1:2/2:1の非正方形ブロックについて、次のレベル変換分割は、2個の1:1正方形サブ変換ブロックを生成し得るが、一方で、1:4/4:1の非正方形ブロックについて、次のレベル変換分割は、2個の1:2/2:1のサブ変換ブロックを生成し得る。

【0124】

いくつかの例示的な実装において、イントラコード化ブロックのルマ成分について、変換ブロックのパーティション分割に関して追加の制限が適用され得る。例えば、変換パーティション分割の各レベルについて、全てのサブ変換ブロックは、等しいサイズを有するように制限され得る。例えば、32×16のコーディングブロックについて、レベル1の変換分割は2個の16×16のサブ変換ブロックを作成し、レベル2の変換分割は8個の8×8のサブ変換ブロックを作成する。別の言葉で言えば、第２レベルの分割は、変換ユニットを等しいサイズに維持するために、全ての第１レベルサブブロックに適用されなければならない。表1に続くイントラコード化正方形ブロックに対する変換ブロックパーティション分割の一つの例が、矢印によって示されるコーディング順序と共に、図15に示されている。具体的に、1502は、正方形コーディングブロックを示している。表1に従った、4個の等しいサイズの変換ブロックへの第１レベルの分割は、矢印で示されたコーディング順序で1504に示されている。表1に従った、全ての第１レベルの等しいサイズのブロックの16個の等しいサイズの変換ブロックへの第２レベルの分割は、矢印で示されたコーディング順序で1506に示されている。

【0125】

いくつかの例示的な実装において、インターコード化ブロックのルマ成分について、イントラコーディングに対する上記の制限は適用されなくてよい。例えば、変換分割の第１レベルの後で、サブ変換ブロックのいずれか１つが、もう１つのレベルで独立してさらに分割されてよい。結果として生じた変換ブロックは、従って、同じサイズであっても、または、なくてもよい。コーディング順序を用いた変換ブロックへのインターコード化ブロックの例示的な分割が図16に示されている。図16の例において、インターコード化ブロック1602は、表1に従って、2つのレベルで変換ブロックへと分割される。第１レベルにおいて、インターコード化ブロックは等しいサイズの4個の変換ブロックへと分割される。次いで、4個の変換ブロックのうちの１つだけ(全てではない)が、さらに4個のサブ変換ブロックへと分割され、1604で示されるように、2つの異なるサイズを有する合計7個の変換ブロックを結果として生じる。これら7個の変換ブロックの例示的なコーディング順序が、図16の1604において矢印で示されている。

【0126】

いくつかの例示的な実装において、クロマ成分について、変換ブロックに対するいくつかの追加の制限が適用され得る。例えば、クロマ成分について、変換ブロックサイズは、コーディングブロックサイズと同じ大きさであってよいが、事前定義されたサイズ、例えば、8×8より小さくはない。

【0127】

いくつかの他の例示的な実装において、幅(W)または高さ(H)のいずれかが64より大きいコーディングブロックについて、ルマおよびクロマの両方のコーディングブロックは、それぞれに、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)変換ユニットの複数個へと暗黙的に分割され得る。ここで、本開示において、「min(a,b)」は、aおよびbの間でより小さい値を返すことができる。

【0128】

図17は、さらに、コーディングブロックまたは予測ブロックを変換ブロックへとパーティション分割するための代替の例示的なスキームを示している。図17に示されるように、再帰的な変換パーティション分割を使用する代わりに、コーディングブロックの変換タイプに従って、パーティション分割タイプの事前定義されたセットが、コーディングブロックに適用され得る。図17に示される特定の例においては、コーディングブロックを様々な数の変換ブロックへと分割するために6個の例示的なパーティション分割タイプの１つが適用され得る。変換ブロックのパーティション分割を生成するそうしたスキームは、コーディングブロックまたは予測ブロックのいずれかに適用され得る。

【0129】

より詳細には、図17のパーティション分割スキームは、図15に示されるように、任意の所与の変換タイプについて（変換タイプは、例えば、ADST等といった、一次変換のタイプを指す）最大6個の例示的なパーティション分割タイプを提供する。このスキームにおいて、全てのコーディングブロックまたは予測ブロックは、例えば、レート歪みコストに基づいて、変換パーティション分割タイプが割り当てられてよい。一つの例において、コーディングブロックまたは予測ブロックに割り当てられる変換パーティション分割タイプは、コーディングブロックまたは予測ブロックの変換タイプに基づいて決定され得る。特定の変換パーティション分割タイプは、図17に示される6個の変換パーティション分割タイプによって示されるように、変換ブロック分割サイズおよびパターン(またはパーティション分割タイプ)に対応し得る。様々な変換タイプと様々な変換パーティション分割タイプとの間の対応関係は、事前定義され得る。一つの例示的な対応が以下に示されており、大文字のラベルは、レート歪みコストに基づいてコーディングブロックまたは予測ブロックに割り当てることができる変換パーティション分割タイプを示している。
・PARTITION_NONE:ブロックサイズに等しい変換サイズを割り当てる。
・PARTITION_SPLIT:ブロックサイズの幅の1/2、かつ、ブロックサイズの高さの1/2の変換サイズを割り当てる。
・PARTITION_HORZ:ブロックサイズと同じ幅、かつ、ブロックサイズの高さの1/2の変換サイズを割り当てる。
・PARTITION_VERT:ブロックサイズの幅の1/2、かつ、ブロックサイズと同じ高さの変換サイズを割り当てる。
・PARTITION_HORZ4:ブロックサイズと同じ幅、かつ、ブロックサイズの高さの1/4の変換サイズを割り当てる。
・PARTITION_VERT4:ブロックサイズの幅の1/4、かつ、ブロックサイズと同じ高さの変換サイズを割り当てる。

【0130】

上記の例において、図17に示されるような変換パーティション分割タイプは全て、パーティション分割された変換ブロックについて均一な変換サイズを含んでいる。これは単なる例示であって、限定ではない。いくつかの他の実装においては、ミックスされた変換ブロックサイズが、特定のパーティション分割タイプ(または、パターン)でパーティション分割された変換ブロックについて使用されてよい。

【0131】

ビデオブロック(PBまたはCB、複数の予測ブロックにさらに分割されていない場合はPBとも称される)は、直接的にエンコーディングされるのではなく、様々な方法で予測されてよく、これによって、圧縮効率を向上させるためにビデオデータ内の様々な相関関係と冗長性を利用する。それに応じて、そうした予測は様々なモードで実行され得る。例えば、ビデオブロックは、イントラ予測またはインター予測を介して予測され得る。特にインター予測モードにおいて、ビデオブロックは、１つ以上の他の参照ブロックまたは１つ以上の他のフレームからのインター予測ブロックによって、単一参照（single-reference）または複合参照（compound-reference）いずれかのインター予測を介して予測され得る。インター予測の実装について、参照ブロックは、そのフレーム識別子(参照ブロックの時間的位置)、および、エンコーディングまたはデコーディングされている現在ブロックと参照ブロック(参照ブロックの空間的位置)との間の空間オフセットを示している動きベクトルによって指定され得る。参照フレーム識別および動きベクトルは、ビットストリームにおいて信号化され得る。空間ブロックオフセットとしての動きベクトルは、直接的に信号化されてよく、または、別の参照動きベクトルまたは予測動きベクトルによってそれ自体が予測され得る。例えば、現在の動きベクトルは、(例えば、候補隣接ブロックの)参照動きベクトルによって直接的に予測されてよく、または、参照動きベクトル、および、現在の動きベクトルと参照動きベクトルとの間の動きベクトル差異(motion vector difference、MVD)の組み合わせによって予測され得る。後者は、動きベクトル差異を用いるマージモード（merge mode with motion vector difference、MMVD)として称され得る。参照動きベクトルは、ビットストリーム内で、例えば、空間的に隣接するブロック、または、一時的に隣接するが空間的に併置（collocated）された現在ブロックへのポインタとして識別される。

【0132】

イントラ予測プロセスに戻ると、そこでは、ブロック(例えば、ルマまたはクロマ予測ブロック、または、予測ブロックへとさらに分割されていない場合はコーディングブロック)内のサンプルが、隣接、次の隣接、または、他のラインまのサンプル、もしくは、それらの組み合わせによって予測され、予測ブロックを生成する。コード化されている実際のブロックと予測ブロックとの間の残差が、次いで、変換とそれに続く量子化によって処理され得る。様々なイントラ予測モードが利用可能になり、そして、イントラモード選択に関連するパラメータおよび他のパラメータがビットストリームにおいて信号化され得る。様々なイントラ予測モードは、例えば、サンプルを予測するためのライン位置、それに沿って予測するラインから予測サンプルが選択される方向、および、他の特別なイントラ予測モードに関係し得る。

【0133】

例えば、一連のイントラ予測モード(互換的に「イントラモード（“intra mode”）」とも称される)は、事前定義された数の方向性イントラ予測モードを含み得る。図1の実装例に関連して前述したように、これらのイントラ予測モードは、特定のブロック内で予測されるサンプルの予測としてブロック外サンプルが選択される、事前定義された数の方向に対応し得る。別の特定の実装例では、水平軸に対して45度から207度の角度に対応する8個の主方向モードがサポートされ、そして、事前定義され得る。

【0134】

イントラ予測の他のいくつかの実装において、方向性テクスチャにおけるより多様な空間的冗長性をさらに活用するために、方向性イントラモードは、より細かい粒度で設定された角度へ、さらに拡張され得る。例えば、上記の8個の角度の実装は、図19に示されるように、V_PRED、H_PRED、D45_PRED、D135_PRED、D113_PRED、D157_PRED、D203_PRED、およびD67_PREDと称される、8個のノミナル角度を提供するように構成することができ、そして、各ノミナル角度に対して、事前定義された数(例えば、7)のより細かい角度を追加することができる。そうした拡張を用いて、事前定義された同じ数の方向性イントラモードに対応して、より大きな合計数(例えば、この例では56)の方向角がイントラ予測のために利用可能であり得る。予測角度は、ノミナルイントラ角に角度デルタを足す（plus）することで、表すことができる。各ノミナル角度に対してより細かい7個の角度方向を伴う上記の特定の例について、角度デルタは、3度のステップサイズに-3から3までを掛けたものであり得る。65個の異なる予測角を伴う図18に示されるように、角度スキームとしていくつかを使用することができる。

【0135】

いくつかの実装において、上記の方向イントラモードの代替または追加として、事前定義された数の非方向イントラ予測モードも、また、事前定義され、そして、利用可能にされ得る。例えば、スムーズイントラ予測モードと称される5個の非方向イントラモードを指定することができる。これらの非方向イントラモード予測モードは、特に、DC、PAETH、SMOOTH、SMOOTH_V、およびSMOOTH_Hイントラモードと称され得る。これらの例の非方向モード下における特定ブロックのサンプルの予測が、図20に示されている。一例として、図20は、上隣接ライン及び／又は左隣接ラインからのサンプルによって予測される4×4ブロック2002を示している。ブロック2002の特定のサンプル2010は、ブロック2002の上隣接ラインのサンプル2010の直接上のサンプル2004、上隣接ラインと左隣接ラインの交点としてのサンプル2010の左上のサンプル2006、および、ブロック2002の左隣接ラインのサンプル2010の直接左のサンプル2008に対応し得る。DCイントラ予測モードの例では、左および上隣接サンプル2008および2004の平均をサンプル2010の予測子（predictor）として使用することができる。PAETHイントラ予測モードの例では、上、左、および左上の参照サンプル2004、2008、および2006がフェッチされ、そして、次いで、これらの3個の参照サンプルのうち(上＋左－左上)に最も近い値がサンプル2010の予測子として設定され得る。SMOOTH_Vイントラ予測モードの例では、左上隣接サンプル200および左隣接サンプル2008の垂直方向の二次補間（quadratice interpolation）によってサンプル2010が予測され得る。SMOOTH_Hイントラ予測モードの例では、左上隣接サンプル2006および上隣接サンプル2004の水平方向の二次補間によってサンプル2010が予測され得る。SMOOTHイントラ予測モードの例では、垂直方向および水平方向の二次補間の平均によってサンプル2010が予測され得る。上記の無方向性イントラモードの実装は、非制限の例として単に示されているだけである。他の隣接ライン、およびサンプルの他の無方向性選択、および予測ブロック内の特定のサンプルを予測するための予測サンプルを組み合わせる方法も、また、考慮されている。

【0136】

様々なコーディングレベル(ピクチャ、スライス、ブロック、ユニット、等)での上記の方向性モードまたは無方向性モードからのエンコーダによる特定のイントラ予測モードの選択が、ビットストリームにおいて信号化され得る。いくつかの実装例において、5個の非角度（non-angular）スムーズモード(合計13個のオプション)と共に、例示的な8個のノミナル方向モードが、最初に信号化され得る。次いで、信号モードが8個のノミナル角イントラモードのうち１つである場合、選択された角度デルタを対応する信号化ノミナル角に対して示すために、インデックスがさらに信号化される。他のいくつかの実装例においては、シグナリングのために、全てのイントラ予測モードが全て一緒にインデックス付けされ得る(例えば、56個の方向性モードに5個の非方向性モードを足して61個のイントラ予測モードを生成する)。

【0137】

いくつかの実装例において、例示的な56個または他の数の方向性イントラ予測モードは、ブロックの各サンプルを参照サブサンプルの場所に投影し、そして、2タップのバイリニアフィルタ（bilinear filter）によって参照サンプルを補間する、統一された方向性予測子を用いて実装され得る。

【0138】

いくつかの実装においては、エッジ上で参照との減衰する空間的相関をキャプチャするために、フィルタイントラ（FILTER INTRA）モードと称される追加のフィルタモードが設計され得る。これらのモードでは、ブロック内のいくつかのパッチのイントラ予測参照サンプルとして、ブロック外（out-of-block）のサンプルに加えてブロック内の予測サンプルが使用され得る。これらのモードは、例えば、事前定義され、そして、少なくともルマブロック(または、ルマブロックだけ)のイントラ予測に利用可能にされ得る。事前定義された数(例えば、5)のフィルタイントラモードが事前に設計されてよく、それぞれは、例えば、4×2パッチ内のサンプルと、それに隣接するn個の隣接するサンプルとの間の相関関係を反映しているnタップフィルタ(例えば、7タップフィルタ)のセットによって表され得る。別の言葉で言えば、nタップフィルタの重み付け係数は、位置に依存し得る。8×8ブロック、4×2パッチ、および7タップフィルタリングを例に取ると、図21に示されるように、8×8ブロック2002は、8個の4×2パッチへと分割され得る。これらのパッチは、図21において、B0、B1、B2、B3、B4、B5、B6、およびB7で示されている。各パッチについて、図21でR0からR7で示されている、7個の隣接を使用して、現在のパッチにおけるサンプルを予測することができる。パッチB0について、全ての隣接ノードが既に再構築されていてよい。しかし、他のパッチについては、いくつかの隣接ノードが現在ブロック内にあり、そして、従って、再構築されていない可能性があるため、次いで、直近の隣接ノードの予測値が参照として使用される。例えば、図21に示されているパッチB7の全ての隣接ノードは再構築されないので、隣接ノードの予測サンプルが代わりに使用される。

【0139】

イントラ予測のいくつかの実装では、１つ以上の他のカラー成分を使用して、1個のカラー成分が予測され得る。カラー成分は、YCrCb、RGB、XYZ色空間などにおけるいずれか１つの成分である。例えば、ルマ成分(例えば、ルマ参照サンプル)からのクロマ成分(例えば、クロマブロック)の予測、ルマからのクロマまたはCfLと称されるもの、を実装することができる。いくつかの実装例において、クロスカラー予測の多くは、ルマからクロマまでしか許可されない。例えば、クロマブロック内のクロマサンプルは、一致再構成ルマサンプル（coincident reconstructed luma sample）の線形関数としてモデル化され得る。CfL予測は、以下のように実装され得る。

【数1】

（式１）

【0140】

ここで、L^ACはルマ成分のAC寄与を示し、αは線形モデルのパラメータを示し、そして、DCはクロマ成分のDC寄与を示している。AC成分は、例えば、ブロックの各サンプルに対して獲得されるが、DC成分は、ブロック全体に対して獲得される。具体的には、再構築されたルマサンプルがクロマ解像度へとサブサンプリングされ、そして、次いで、平均ルマ値(ルマのDC)が各ルマ値から減算されて、ルマのAC寄与が形成され得る。ルマのAC寄与は、次いで、式（１）の線形モードにおいて使用される、クロマ成分のAC値を予測する。ルマAC寄与からクロマAC成分を近似または予測するためには、スケーリングパラメータを計算するようデコーダに要求する代わりに、CfL実装の一例では、元のクロマサンプルに基づいてパラメータαを決定し、そして、ビットストリーム内でそれらを信号化することができる。これにより、デコーダの複雑さが軽減され、そして、より正確な予測が得られる。クロマ成分のDC寄与に関しては、いくつかの実装例において、クロマ成分内のイントラDCモードを使用して計算され得る。

【0141】

イントラ予測における参照ライン（reference line）のいくつかの実装例においては、マルチラインイントラ予測が使用され得る。これらの実装では、イントラ予測における選択のために１つ以上の参照ラインが利用可能であり、そして、エンコーダは、イントラ予測を生成するためにどの参照ラインが使用されるかを決定して、信号化する。参照ラインインデックスは、イントラ予測モードの前に信号化されてよく、そして、非ゼロ参照ラインインデックスが信号化される場合は、最も可能性の高い予測モードのみが許可される。図22を参照すると、4個の参照ラインの例が示されており(参照ライン0から参照ライン3まで)、ここで、各参照ラインは、左上の基準サンプルと共に、6個のセグメント、つまり、セグメントAからFまで(2202-2212で示される)、で構成されている。さらに、セグメントAおよびFは、それぞれに、セグメントBおよびEから最も近いサンプルを用いてパディングされ得る。マルチ参照ラインイントラ予測は、方向性および非方向性内予測と共に使用され得る。

【0142】

イントラ予測ブロックまたはインター予測ブロックのいずれかの残差の変換が、次いで、実装されて、変換係数の量子化が後に続く。変換を実行する目的で、イントラコード化ブロックおよびインターコード化ブロックの両方を、変換の前に複数の変換ブロック(「ユニット（“unit”）」という用語は、通常、3カラーチャネルの集合を表すために使用されるが、ときどき、「変換ユニット（“transform unit”）」として互換的に使用され得る。例えば、「コーディングユニット」は、ルマコーディングブロックおよびクロマコーディングブロックを含むだろう)へと、さらに分割することができる。いくつかの実装において、コード化ブロック(または、予測ブロック)の最大分割深度を指定することができる(「コード化ブロック（“coded block”）」という用語は「コーディングブロック（“coding block”）」と同じ意味で使用され得る)。例えば、そうした分割は、2レベルを超えることはできない。予測ブロックの変換ブロックへの分割は、イントラ予測ブロックとインター予測ブロックとの間で異なる方法で処理され得る。いくつかの実装においては、しかしながら、そうした分割は、イントラ予測ブロックとインター予測ブロックとの間で類似し得る。

【0143】

いくつかの実装例において、および、イントラコード化ブロックについて、変換パーティションは、全ての変換ブロックが同じサイズを有し、そして、変換ブロックがラスタースキャン順にコード化される方法で行うことができる。イントラコード化ブロックのそうした変換ブロック分割の一例が図23に示されている。具体的には、図23は、2306で示されているように、コード化ブロック2302が、中間レベルの四分木分割2304を介して、同じブロックサイズの16個の変換ブロックへと分割されることを示している。コーディングのための例示的なラスタースキャン順序が、図23における順序付けられた矢印によって示されている。

【0144】

いくつかの実装例において、および、インターコード化ブロックについて、変換ユニットのパーティション分割は、事前定義された数のレベル(例えば、2レベル)までの分割の深さを用いて再帰的な方法で行われ得る。分割は、図23に示されるように、任意のサブパーティションおよび任意のレベルで再帰的に停止または継続することができる。特に、図24は、ブロック2402が4個の四分木サブブロック2404へと分割され、そして、サブブロックのうち１つがさらに4個の第２レベルの変換ブロックへと分割され、一方で、他のサブブロックの分割は第１レベルの後で停止し、2個の異なるサイズの合計で7個の変換ブロックが生成される、一例を示している。コーディングのためのラスタースキャン順序の例が、図24の順序付き矢印によってさらに示されている。図24は、最大2レベルの正方形の変換ブロックの四分木分割の実装例を示しているが、いくつかの世代（generation）の実装において、変換パーティション分割は、4×4から64×64までの範囲の1:1
(正方形)、1:2/2:1、および1:4/4:1の変換ブロックの形状およびサイズをサポートすることができる。いくつかの実装例において、コーディングブロックが64×64以下である場合、変換ブロックパーティション分割は、ルマコンポーネントだけに適用され得る(別の言葉で言えば、クロマ変換ブロックは、その条件下でのコーディングブロックと同じであろう)。そうでなければ、コーディングブロックの幅または高さが64より大きい場合、ルマコーディングブロックおよびクロマコーディングブロックの両方は、それぞれに、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)の倍数の変換ブロックへと暗黙的に分割され得る。

【0145】

上記の変換ブロックそれぞれは、次いで、一次変換の対象となり得る。一次変換は、本質的に、変換ブロック内の残差を空間領域から周波数領域に移動する。実際の一次変換のいくつかの実装においては、上記の例示的な拡張コーディングブロックのパーティションをサポートするために、複数の変換サイズ(二次元の各次元に対して4ポイントから64ポイントの範囲)、および、変換形状(正方形、縦横比2:1/1:2、および4:1/1:4の長方形)が許可され得る。

【0146】

実際の一次変換に目を向けると、いくつかの実装例において、二次元（2-D）変換プロセスは、ハイブリッド変換カーネル(例えば、コード化残差変換ブロックの各次元について異なる1-D変換で構成され得る)の使用を含み得る。一次元（1-D）変換カーネルの例は、ａ）4ポイント、8ポイント、16ポイント、32ポイント、64ポイントのDCT-2、b）4ポイント、8ポイント、16ポイントの非対称DST(DST-4、DST-7)およびその反転（flipped）バージョン、c)4ポイント、8ポイント、16ポイント、32ポイントの恒等変換（identity transform）を含み得るが、これらに限定されない。各次元について使用される変換カーネルの選択は、レート歪み(RD)基準に基づいてよい。例えば、実装され得るDCT-2および非対称DSTの基底関数（basis function）が表2にリストされている。

【表2】

表２：例示的な一次変換基底関数(N点入力についてDCT-2、DST-4、DST-7)

【0147】

いくつかの実装例において、特定の一次変換実装のハイブリッド変換カーネルの可用性は、変換ブロックサイズおよび予測モードに基づいてよい。依存関係の一例が表3に示されている。この表は、AV1ハイブリッド変換カーネルの例、および、予測モードおよびブロックサイズに基づくその可用性を示している。ここで、→および↓は、水平方向と垂直方向のディメンションを表している。「レ」および「x」（チェックマーク）は、そのブロックサイズおよび予測モード（prediction mode）についてカーネルの可用性を示している。クロマ成分について、変換タイプの選択は、暗黙的な方法で実行され得る。例えば、イントラ予測残差については、表4で指定されるように、イントラ予測モードに従って変換タイプ（transform type）を選択することができる。インター予測残差について、クロマブロックの変換タイプは、併置された（co-located）ルマブロックの変換タイプの選択に従って選択することができる。従って、クロマ成分について、ビットストリームにおける変換タイプのシグナリングは存在しない。

【表3】

表３：予測モードおよびブロックサイズに基づくAV1ハイブリッド変換カーネル及びその可用性

【表4】

表４：クロマ成分イントラ予測残差に対する変換タイプ選択

【0148】

いくつかの実装において、一次変換係数において二次変換が実行され得る。例えば、縮小二次変換（reduced secondary transform）として知られる、LFNST(low-frequency non-separable transform)が、図25に示されるように、順方向（forward）一次変換と（エンコーダでの）量子化との間、および、逆量子化と(デコーダ側での)逆一次変換との間に適用されてよく、一次変換係数をさらに相関解除（decorrelate）することができる。本質的に、LFNSTは、一次変換係数の一部、例えば、低周波部分(従って、変換ブロックの一次変換係数の完全なセットから「削減された（“reduced”）」もの)を獲得して、二次変換に進むことができる。LFNSTの一例では、変換ブロックサイズに応じて、4×4非分離変換または8×8非分離変換が適用され得る。例えば、4×4のLFNSTは、小さな変換ブロック(例えば、min(幅,高さ)<8)に適用され得るが、一方で、8×8のLFNSTは、大きな変換ブロック(例えば、(幅,高さ)>8)に適用され得る。例えば、8×8変換ブロックが4×4のLFNSTの対象となる場合には、8×8一次変換係数の低周波数4×4部分のみが、さらに二次変換を受ける。

【0149】

図25に具体的に示されているように、変換ブロックは8×8(または、16×16)であり得る。従って、変換ブロックの順方向一次変換2502は、8×8(または16×16)の一次変換係数行列2504を生成し、ここで、各正方形（square）ユニットは2×2(または、4×4)の部分を表している。例えば、順方向LFNSTへの入力は、8×8(または16×16)の一次変換係数全体ではなくてよい。例えば、4×4(または8×8)のLFNSTを二次変換に使用することができる。かくして、網掛け部分(左上)2506に示されているように、一次変換係数行列2504の4×4(または、8×8)の低周波一次変換共効果（coeffect）のみをLFNSTへの入力として使用され得る。一次変換係数行列の残りの部分は、二次変換の対象にならなくてよい。かくして、二次変換の後で、LFNSTの対象となる一次変換係数の部分は二次変換係数になるが、LFNSTの対象とならない残りの部分(例えば、行列2504の網掛けされていない部分)は、対応する一次変換係数を維持する。いくつかの実装例において、二次変換の対象とならない残りの部分は、全て0係数に設定され得る。

【0150】

LFNSTで使用される非分離変換の適用のための一例が、以下に示されている。例示的な4×4 LFNSTを適用するためには、4×4入力ブロックX(例えば、図25の一次変換行列1404の網掛け部分2506といった一次変換係数ブロックの4×4低周波部分を表している)を次のように表すことができる。

【数2】

（式２）

【0151】

この2-D入力行列は、最初に、一つの例示的な順序でベクトル

【数3】

に線形化され、または、スキャンされる。

【数4】

（式２）

【0152】

4×4 LFNSTの非分離変換は、次いで、

【数5】

として計算できる。

【数6】

は、出力変換係数ベクトルを示し、そして、Tは、16×16の変換行列である。結果として生じる16×1の係数ベクトル

【数7】

は、その後、そのブロックのスキャン順序を使用して4×4ブロックとして逆スキャンされる(例えば、水平、垂直、または対角線)。小さいインデックスを伴う係数は、4×4係数ブロックのより小さいスキャンインデックスで配置することができる。このようにして、一次変換係数Xの冗長性は、第２変換Tを介して、さらに活用され得る。それによって、追加的なの圧縮強化が提供される。

【0153】

上記の例示的なLFNSTは、複数の反復なしで単一のパス（pass）で実装されるように、非分離変換を適用するための直接行列乗算アプローチに基づいている。いくつかのさらなる実装例では、例示的な4×4 LFNSTの非分離変換行列（T）のディメンションをさらに削減して、計算の複雑さ及び変換係数を保管するためのメモリ空間要件を最小限に抑えることができる。そうした実装は、縮小非分離変換(reduced non-separate transform、RST)と称され得る。より詳細には、RSTの主なアイデアは、Ｎ(Ｎは、上記の例では4×4=16であるが、8×8ブロックについては64と等しくてよい)次元ベクトル（dimensional vector）を別の空間のＲ次元ベクトルにマップすることであり、ここで、Ｎ／Ｒ（Ｒ＜Ｎ）はディメンション縮小係数を表している。従って、Ｎ×Ｎ変換行列の代わりに、RST行列は、以下のようなＲ×Ｎ行列になる。

【数8】

（式４）

【0154】

ここで、変換行列のＲ行は、Ｎ次元空間の縮小Ｒ基底である。本変換は、このように、Ｎ次元の入力ベクトルを縮小Ｒ次元の出力ベクトルに変換する。かくして、かつ、図25に示されるように、一次係数2506から変換された二次変換係数2508は、ディメンションにおいて係数またはＮ／Ｒによって縮小される。図25における2508の周囲の3個の正方形は、ゼロでパディングされ得る。

【0155】

RTSの逆変換行列は、その順方向変換の転置であり得る。例示的な8×8 LFNST(上記の4×4 LFNSTとは対照的に、ここでは、より多様な説明をする)の場合、例示的な縮小係数（reduction factor）の4が適用され得る。そして、従って、64×64の直接非分離変換行列は、それに応じて16×64の直接行列に縮小される。さらに、いくつかの実装において、入力一次係数の全体ではなく一部は、LFNSTの入力ベクトルへと線形化され得る。例えば、例示的な8×8入力一次変換係数の一部だけが、上記のXベクトルへと線形化され得る。特定の例については、8×8の一次変換係数行列の4個の4×4象限（quadrant）のうち、右下(高周波係数)が省略されてよく、そして、他の3個の象限だけが、64×1ベクトルではなく、事前定義されたスキャン順序を使用して48×1ベクトルへと線形化される。そうした実装において、非分離変換行列は16×64から16×48へ、さらに縮小され得る。

【0156】

従って、デコーダ側で縮小された48×16逆RST行列の一例が使用され、8×8コア(一次)変換係数の左上、右上、左下の4×4象限を生成することができる。具体的には、同じ変換セット構成の16×64 RSTの代わりに、さらに縮小された16×48 RST行列が適用される場合、非分離二次変換は、右下4×4ブロックを除く8×8一次係数ブロックの3個の4×4象限ブロックからベクトル化された48個の行列要素を入力として受け取る。そうした実装において、省略された右下4×4一次変換係数は、二次変換で無視されるだろう。このさらに縮小された変換は、48×1のベクトルを16×1の出力ベクトルに変換し、図25の2508を埋めるように、これを逆スキャンして4×4行列にする。2508を囲む二次変換係数の3個の正方形は、ゼロ埋めにすることができる。

【0157】

そうしたRSTにおけるディメンション縮小の助けを借りて、全てのLFNST行列を保管するためのメモリ使用量が削減される。上記の例において、メモリ使用量は、例えば、10KBから8KBに削減することができ、ディメンション縮小のない実装と比較して、パフォーマンスの低下がかなり小さい。

【0158】

いくつかの実装においては、複雑さを軽減するために、LFNSTの対象となる一次変換係数の部分以外の全ての係数(例えば、図25における1404の2506部分の外側)が重要でない場合にのみ適用されるように、さらに制限され得る。従って、LFNSTが適用される場合、全ての一次のみの変換係数(例えば、図25の一次係数行列2504の網掛けされていない部分)が0に近くあり得る。そうした制限は、最終有効位置（last-significant position）におけるLFNSTインデックスシグナリングの条件付け（conditioning）を可能にし、そして、従って、この制限が適用されない場合に特定の位置で有効な係数をチェックするために必要となり得る、追加の係数スキャニングを回避する。いくつかの実装において、LFNSTの最悪ケースの処理は(ピクセルあたりの乗算に関して)、4×4および8×8ブロックについての分離変換を、それぞれに、8×16および8×48変換に制限し得る。そうしたケースにおいて、LFNSTが適用されている場合、16未満の他のサイズについては、最終有効スキャン位置が8未満である必要がある。4×NおよびN×4でN>8の形状であるブロックについて、上記の制限は、今やLFNSTが左上の4×4領域に一度だけ適用されるようになったことを意味する。LFNSTが適用される場合に一次のみの係数は全て0であるため、そうしたケースでは一次変換に必要とされる操作の数は削減される。エンコーダの観点からは、LFNST変換がテストされる場合、係数の量子化を簡略化することができる。レート歪み最適化量子化(rate-distortion optimized quantization、RDO)は、最大で(スキャン順において)最初の16個の係数に対して実行される必要があり、残りの係数は0に実施されてよい。

【0159】

いくつかの実装例において、利用可能なRSTカーネルは、各変換セットが多くの非分離可能変換行列を含んでいる数多くの変換セットとして指定され得る。例えば、LFNSTで使用される変換セットごとに、合計4個の変換セットおよび2個の非分離可能変換行列(カーネル)が存在し得る。これらのカーネルは、オフラインで事前にトレーニングされてよく、従って、データ駆動型（data driven）である。オフラインでトレーニングされた変換カーネルは、エンコーディング/デコーディングの最中に使用するために、メモリに保管され、または、エンコーディングまたはデコーディングデバイスにおいてハードコーディングされ得る。エンコーディングまたはデコーディングプロセスの最中の変換セットの選択は、イントラ予測モードによって決定され得る。イントラ予測モードから変換セットへのマッピングは、事前定義され得る。そうした事前定義されたマッピングの一例が表5に示されている。例えば、表5に示されるように、現在ブロック(すなわち、81<=predModeIntra<=83)について、3個のクロスコンポーネント線形モデル（Cross-Component Linear Model、CCLM)モード(INTRA_LT_CCLM、INTRA_T_CCLM、またはINTRA_L_CCLM)のうち１つが使用されている場合、現在のクロマブロックについて変換セット0が選択され得る。各変換セットについて、選択された非分離可能二次変換候補は、明示的に信号化されたLFNSTインデックスによってさらに指定され得る。例えば、変換係数の後で、イントラCUごとに１回、インデックスがビットストリームで信号化され得る。

【表5】

表５：変換選択テーブル

【0160】

LFNSTは、上記の実装例で最初の係数サブグループまたは部分の外側にある全ての係数が非有意（non-significant）である場合にのみ、適用できるように制限されているため、LFNSTインデックスコーディングは、最終有効係数の位置に依存する。加えて、LFNSTインデックスは、コンテキストコード化され得るが、イントラ予測モードには依存せず、そして、最初のビンのみがコンテキストコード化され得る。さらに、LFNSTは、イントラスライスおよびインタースライスの両方におけるイントラCUについて、および、ルマおよびクロマの両方について、適用され得る。デュアルツリーがイネーブルされている場合、ルマおよびクロマのLFNSTインデックスは、別々に信号化され得る。インタースライス(デュアルツリーがディセーブルされている)の場合、単一のLFNSTインデックスが信号化され、そして、ルマおよびクロマの両方について使用され得る。

【0161】

いくつかの実装例において、実行可能な全てのパーティションブロックにRSTが適用されてもパフォーマンスの向上はわずかである可能性が高いため、イントラサブパーティション分割（Intra Sub-Partitioning、ISP)モードが選択されている場合には、LFNSTがディセーブルされ、そして、RSTインデックスは信号化されなくてよい。さらに、ISP予測残差に対してRSTをディセーブルすると、エンコーディングの複雑さが軽減され得る。いくつかのさらなる実装では、多重線形回帰イントラ予測(Multiple linear regression Intra Prediction、MIP)モードが選択されている場合に、LFNSTも、また、ディセーブルされ、そして、RSTインデックスは信号化されなくてよい。

【0162】

既存の最大変換サイズ制限(例えば、64×64)のせいで、64×64(または、最大変換ブロックサイズを表す他の事前定義されたサイズ)を超える大きなCUが暗黙的に分割(例えば、TUタイリング)されることを考慮すると、LFNSTインデックス検索は、所定の数のデコードパイプラインステージについてデータバッファリングを4倍に増やすことができるだろう。従って、いくつかの実装において、LFNSTが許可される最大サイズは、例えば、64×64に制限され得る。いくつかの実装において、LFNSTは、DCT2を用いて一次変換としてのみイネーブルされ得る。

【0163】

他のいくつかの実装において、ルマコンポーネントに対して、例えば、各セットに3個のカーネルを用いて、12セットの二次変換を定義することによって、イントラ二次変換(IST)が提供されている。変換セットの選択のために、イントラモード依存インデックスが使用され得る。セット内のカーネル選択は、信号化されたシンタックス要素に基づき得る。ISTは、DCT2またはADSTのいずれかが水平および垂直の両方の一次変換として使用されている場合にイネーブルされ得る。

【0164】

いくつかの実装においては、ブロックサイズに従って、4×4非分離変換または8×8非分離変換を選択することができる。min(tx_width,tx_height,tx_width,tx_height)<8である場合、4×4のISTを選択することができる。より大きなブロックについては、8×8のISTを使用することができる。ここで、tx_widthおよびtx_heightは、それぞれに、変換ブロックの幅および高さに対応している。ISTに対する入力は、ジグザグスキャン順序における低周波一次変換係数であり得る。

【0165】

他のいくつかの実装例においては、制限なく、カーネルセットの数は、12以外であり得る。例えば、14個の二次変換カーネルが存在し得る。二次カーネルセットと様々なイントラ予測モードとの間のマッピングは、事前決定されてよく、または、事前に設定されてよい。例えば、特定のイントラ予測モードは、12または14セットのうち１つにマッピングされ得る。カーネルセットそれぞれは、3以外の数の二次カーネルが含まれ得る。例えば、各二次変換カーネルセットに6個の二次カーネルが存在し得る。各セット内のカーネルの数は、二次カーネルの数を増やすことに伴うオーバーヘッドと、潜在的な追加のコーディングゲインとの間のトレードオフに基づいて決定され得る。いくつかの実装において、各カーネルセット内のカーネルの数は3から6であり得る。各カーネルセット内に6個のオプションの二次変換カーネルを有することを超えるコーディングゲインは、実用的および統計的な観点から、コーディングオーバーヘッドの増加に比べて十分に小さくなり得る。

【0166】

分離可能な二次変換または非分離可能な二次変換のいずれかの従来の実装では(方向性テクスチャパターンをよりよくキャプチャするために)、しかしながら、カーネルセットマッピング(イントラ予測モード、一次変換タイプ、ブロックサイズのいくつかの組み合わせに対応している)に対するイントラ予測モードによって事前決定された各二次カーネルセットで利用可能な二次変換カーネルオプション(または、候補)の数は固定されてよく、そして、適応的ではない。カーネルの使用状況に関するいくつかの統計的研究は、イントラ予測モード、一次変換タイプ、ブロックサイズ、および、他のパラメータの所定の組み合わせについて、二次変換のカーネルオプション(または、候補)の数を減らすことだけが、方向性情報をキャプチャするために必要であることを示してきた。カーネルオプション(または、候補)のそうした削減は、提案されたスキームの信号化オーバーヘッドを削減することができる。以下の様々な実装例は、イントラ予測モード、一次変換タイプ、ブロックサイズ、および他の潜在的に関連するパラメータの組み合わせに従って、適応二次カーネルオプションのスキームを提供している。

【0167】

これらの実装例は、個別に、または、任意の順序で組み合わされて使用され得る。さらに、各実装または各実装の組み合わせは、二次変換カーネルを決定すること、および、様々なコーディングレベル(ブロック、マクロブロック、スライス、画像、フレーム、など)でカーネルセットおよびカーネルセットからの二次カーネルの選択を信号化することにおいて、エンコーダに適用することができる。各実装または各実装の組み合わせは、また、エンコーディングされたビットストリーム内の様々なシグナリング情報に基づいて、二次変換カーネルセット、および、各変換ブロックについてカーネルセットから選択された二次変換カーネルを識別するためのデコーダにも適用することができる。開示された方法を採用するエンコーダおよびデコーダは、処理回路(例えば、１つ以上のプロセッサまたは１つ以上の集積回路)によって実装することができる。一例において、１つ以上のプロセッサは、非一時的コンピュータ可読媒体に保管されたプログラムを実行する。以下では、ブロックという用語は、変換ブロック(TU)として解釈され得る。しかしながら、以下に開示される基本的な原則は、予測ブロック、コーディングブロック、またはコーディングユニット、すなわちCUを含むが、それに限定されない、他のレベルのビデオブロックに適用される。さらに、以下の開示において、ブロックサイズという用語は、ブロック幅、ブロック高さ、ブロック縦横比、ブロック面積サイズ、ブロックの幅および高さのうち大きい方、ブロックの幅および高さのうち小さい方、等しい場合(正方形)のブロックの幅および高さ、のうちいずれか１つまたは組み合わせを指すために使用される。さらに、イントラ予測モードがスムーズモードではなく、かつ、所与の予測方向に従った予測サンプルに依存する場合、そのイントラ予測モードは、角度モードまたは方向モードと称され得る。

【0168】

いくつかの一般的な実装例において、選択のために利用可能ないくつかの二次変換カーネルは、イントラ予測モード、一次変換タイプ、ブロックサイズを含むが、それに限定されないコーディング特性のいずれかまたは組み合わせに従って、適応可能である。特定のブロック(変換ブロックといったもの)については、対応する二次変換カーネルセットの間で選択された最終候補が、二次変換カーネルインデックスを使用して、エンコーディングされたビットストリーム内でstxIdxによって示される対応するカーネルセット(代替的に「カーネルインデックス（“kernel index”）」、または「インデックス（“index”）」とも称される)へと信号化される。いくつかの実装において、可能なstxIdx値の１つは、二次変換が実行されず、そして、従って、二次変換カーネルが選択されないことを示すことができる。他のいくつかの実装において、特定のブロックが二次変換を受けるか否かは、別のシグナリングによって示されてよく、そして、かくして、対応する二次カーネルセットの中の実際のカーネルが特定のブロックに使用される場合にのみ、stxIdxが使用され、そして、信号化され得る。

【0169】

いくつかの実装において、これらのコーディング特性の様々な組み合わせ(例えば、イントラ予測モード、一次変換タイプ、およびブロックサイズ)と二次変換カーネルセットとの間のマッピングが事前決定され得る。カーネルセットそれぞれにおける二次カーネルは、事前にトレーニングされてよい。それらは、事前定義され、かつ、エンコーダおよびデコーダに知られてよく、そして、従って、信号化される必要がなくてよい。他のいくつかの実装において、それらは、ビットストリームにおいて信号化され得る。二次変換カーネルセットは、選択について利用可能な二次変換カーネルの数に関して互いに異なり得るが、様々な二次変換カーネルセット間で実際にトレーニングされた二次変換カーネルは、オーバーラップしてよく、または、オーバーラップしなくてもよい。「オーバーラップ（“overlap”）」という用語は、同じ数または異なる数のオプションカーネルを有している、2個の異なる二次変換カーネルセットが、少なくとも１つの事前トレーニングされた二次変換カーネルを共有し得ることを示すために使用されている。

【0170】

いくつかの特定の実装例において、ブロックをエンコーディングするための二次変換またはブロックのデコーディングにおける逆二次変換について、ブロックに関連付けられているイントラ予測モードに依存して、適応可能な数の変換カーネル(または、候補)が、ブロックのコーディングおよびデコーディングにおいて選択され得る。非限定的な例として、イントラ予測モードが、垂直モード (V_PRED)、水平モード(H_PRED)、スムーズ水平モード(SMOOOTH_H_PRED)、またはスムーズ垂直モード(SMOOTH_V_PRED)のいずれか１つである場合に、対応する二次変換カーネルセットは、選択のために利用可能なN個の変換カーネル(または、候補)を含み得る。一方で、他の全てのイントラ予測モードについて、対応する二次変換カーネルセットは、選択のために利用可能なK個の変換カーネル(または、候補)を含み得る。ここで、NおよびKは、異なる非負（non-negative）の整数である。例えば、NとKは、0、1、2、3、4、5、6を含むが、これらに限定されない、非負の整数のいずれか１つであり得る。各二次変換カーネルセットにおける実際の二次変換カーネルは、事前にトレーニングされ得る。それらは、事前定義されてよく、または、ビットストリームで信号化されてよい。いくつかの実装例において、各イントラコード化ブロックについて、特定の二次変換カーネルが選択され、かつ、対応する二次変換カーネルセットから使用され、そして、特定のカーネルの選択がビットストリーム内のstxIdxによって信号化され得る。上記の例では、2個のオプションカーネルの適応数を有している二次変換カーネルセットを提供しているが、根底にある原則は、3個以上のオプションカーネルの異なる適応数を有しているカーネルセットに拡張され得る。

【0171】

他のいくつかの特定の実装では、特定のブロックの一次変換タイプに依存して、対応する二次変換カーネルセットで選択のために利用可能な変換カーネル(または、候補)の数は、適応的であり得る。例えば、一次変換タイプがADST_ADST(垂直および水平ディメンションの両方でADST)である場合、対応する二次変換カーネルセットではN個の変換カーネル(または、候補)のみが利用可能である。一方で、他の全ての一次変換タイプについて、K個の変換カーネル(または、候補)が利用可能であり、ここで、NとKは、異なる非負の整数値であり得る。例えば、NとKは、0、1、2、3、4、5、6を含むが、それに限定されない、非負の整数のいずれか１つであり得る。各二次変換カーネルセットにおける実際の二次変換カーネルは、事前にトレーニングされ得る。それらは、事前定義されてよく、または、ビットストリームで信号化されてよい。いくつかの実装例において、各イントラコード化ブロックについて、特定の二次変換カーネルが選択され、かつ、対応する二次変換カーネルセットから使用され、そして、特定のカーネルの選択がビットストリーム内のstxIdxによって信号化され得る。上記の例では、2個のオプションカーネルの適応数を有している二次変換カーネルセットを提供しているが、根底にある原則は、3個以上のオプションカーネルの異なる適応数を有しているカーネルセットに拡張され得る。

【0172】

他のいくつかの実装例において、ブロックサイズに依存して、対応する二次変換カーネルセットで選択のために利用可能な変換カーネル(または、候補)の数は、適応的であり得る。例えば、変換ブロックサイズが事前決定されたブロックサイズ閾値未満である場合、N個の変換カーネル(または、候補)のみが利用可能である。一方で、ブロックサイズ閾値以上の変換ブロックサイズの場合は、K個の変換カーネル(または、候補)が利用可能であり、ここで、NとKは、異なる非負の整数値であり得る。例えば、NとKは、0、1、2、3、4、5、6を含むが、それに限定されない、非負の整数のいずれか１つであり得る。ブロックサイズは、幅ディメンションのブロックサイズ、高さディメンションのブロックサイズ、ブロック領域サイズ、幅ディメンションと高さディメンションの大きい方、幅ディメンションと高さディメンションの小さい方、などのいずれか１つであり得る。例えば、ブロックサイズの閾値は、高さで8として指定され得る。別の例として、ブロックサイズの閾値は、幅で8として指定され得る。別の例として、ブロックサイズの閾値は、幅および高さで8として指定され得る。別の例として、ブロックサイズの閾値は、領域(例えば、64ピクセル)として指定され得る。別の例として、ブロックサイズの閾値は、W×H(例えば、8×8)として指定され得る。そうしたブロックサイズの閾値は、Wより小さいブロック幅が閾値を下回ること、または、Hより小さい高さを伴うブロックが閾値を下回ること、または、Wより小さい幅およびHより小さい高さを伴うブロックが閾値を下回ること、または、Wより小さい幅がまたはHより小さい高さを伴うブロックが閾値を下回ること、もしくは、W×Hピクセルより小さい領域を伴うブロックが閾値を下回ることを意味し得る。さらに、各二次変換カーネルセット内の実際の二次変換カーネルは、事前にトレーニングされてよい。それらは事前定義されてよく、または、ビットストリームで信号化されてよい。いくつかの実装例において、各イントラコード化ブロックについて、特定の二次変換カーネルが選択され、かつ、対応する二次変換カーネルセットから使用され、そして、特定のカーネルの選択がビットストリーム内のstxIdxによって信号化され得る。上記の例では、2個のオプションカーネルの適応数を有している二次変換カーネルセットを提供しているが、根底にある原則は、3個以上のオプションカーネルの異なる適応数を有しているカーネルセットに拡張され得る。

【0173】

他のいくつかの実装例において、上記の様々なコーディングパラメータの任意の１つまたはいくつかの組み合わせに対して、変換カーネル(または、候補)の適応数が、選択のために利用可能であり得る。例えば、イントラ予測モードが垂直モード(V_PRED)、水平モード(H_PRED)、スムーズ水平モード(SMOOTH_H_PRED)、またはスムーズ垂直モード(SMOOTH_V_PRED)のいずれか１つであり、一次変換タイプがADST_ADSTであり、かつ、変換ブロックサイズがボックサイズ閾値以上(または、それより小さい)である場合、N個の変換カーネル(または、候補)のみが利用可能であるが、一方で、他の全ての組み合わせについて、K個の変換カーネル(または、候補)が利用可能であり、ここで、NとKは異なる非負の整数値であり得る。例えば、NとKは、0、1、2、3、4、5、6を含むが、それに限定されない、非負の整数のいずれか１つであり得る。ブロックサイズおよびサイズ閾値という用語は、上記の他の実装と同様の意味を伝達することができる。この例では、2個のオプションカーネルの適応数を有している二次変換カーネルセットを提供しているが、根底にある原則は、3個以上のオプションカーネルの異なる適応数を有しているカーネルセットに拡張され得る。これらのコーディングパラメータの任意の組み合わせに従って、利用可能なカーネルの数を適応的に割り当てる方スキーム式も、また、考えられる。

【0174】

他のいくつかの実装においては、上記の例のいずれかについて、N(またはK)個の変換カーネル(または、候補)のみが対応する二次変換カーネルセットを有するブロックについて利用可能な場合、stxIdxの信号化は、N(またはK)個までの変換カーネル(または、候補)のみをサポートする必要があり得る。そうした特定のコーディングパラメータまたはその組み合わせ(例えば、イントラ予測モード、一次変換モード、ブロックサイズ、など)に対する可能なstxIdxの削減は、ビットストリームの信号化オーバーヘッドの改善に役立つ。

【0175】

他のいくつかの実装において、上記の例のいずれかについて、異なる数の二次変換カーネル(または、候補)が異なるカーネルセットに使用されている場合、異なるコンテキストモデリングがエントロピーコーディングstxIdxについて適用される。別の言葉で言えば、第１数の候補カーネルを有しているカーネルセット間のインデックス化のために使用されるstxIdxは、第１コンテキストモデルまたは第１確率分布に基づいてエントロピーコーディングされ得る。一方で、第１数とは異なる第２数の候補カーネルを有しているカーネルセット間のインデックス化のために使用されるstxIdxは、第１コンテキストモデルとは異なる第２コンテキストモデルに基づいてエントロピーコーディングされ得る。このことは、2個の異なる数のカーネルセットについてstxIdxの確率分布が異なる可能性に基づいてよい。

【0176】

他のいくつかの実装において、上記の例のいずれかについて、異なる数の二次変換カーネル(または、候補)が、異なる二次カーネルセットに対して適応的に使用される場合、stxIdxが最初にバイナリ化され、そして、第１のM個のビン（M bins）のコンテキストモデリングが、異なる数の候補二次変換カーネルを有するカーネルセットのstxIdx間で共有され得る。

【0177】

特定の例について、第１カーネルセットについてN=3であり、かつ、第２カーネルセットについてK=4である場合、stxIdxは、表6のようにバイナリ化され得る。第１の2個のビンのエントロピーコーディングのために使用されるコンテキストモデリングは、N=3およびK=4である場合に使用されるコードワード（codeword）について共有され得る。

【表6】

表６

【0178】

図26は、上記の実装の根底にある原則に従う例示的なフローチャート2600を示している。例示的なフローは、S2601で開始する。S2610では、エンコーディングされたビデオストリームが解析され、かつ、処理されて、ビデオブロックの二次変換係数のセット、ビデオブロックに関連付けられたイントラ予測モード、および二次変換カーネルのグループへのカーネルインデックスが生成される。S2620では、イントラ予測モードに基づく二次変換カーネルのグループが識別される。S2630では、カーネルインデックスによって識別される二次変換カーネルのグループのうち二次変換カーネルに基づくビデオブロックの一次変換係数を生成するために、二次変換係数のセットの逆二次変換が実行される。ここで、二次変換カーネルのグループにおけるカーネルの数は、ビデオブロックに関連付けられたイントラ予測モード、ビデオブロックのサイズ、または、ビデオブロックに関連付けられた一次変換タイプのうち少なくとも１つに依存する。プロセスは、S2699で終了する。

【0179】

図27は、上記の実装の根底にある原則に従う別の例示的な方法のフローチャート2700を示している。例示的な方法のフローはS2701で開始する。S2710においては、イントラ予測ビデオブロックの残差ブロックが、少なくとも１つの一次変換カーネルを使用して変換されて、一次変換係数のセットを生成する。S2720では、現在の二次変換カーネルが、二次変換カーネルのグループの中から選択される。ここで、二次変換カーネルのグループにおけるカーネルの数は、イントラ予測ビデオブロックのイントラ予測モード、イントラ予測ビデオブロックのサイズ、または、少なくとも１つの一次変換カーネルの一次変換タイプのうち少なくとも１つに依存する。S2730では、二次変換カーネルのグループにおける現在の二次変換カーネルのカーネルインデックスが決定される。S2740では、一次変換係数のセットが変換され、現在の二次変換カーネルを使用して二次変換係数のセットが生成される。S2750では、カーネルインデックスおよび二次変換係数のセットが、イントラ予測ビデオブロックに関連付けられたエンコーディングされたビデオストリームへとエンコーディングされる。プロセスは、S2799で終了する。

【0180】

本開示の実施形態は、別々に、または、任意の順序で組み合わされて、使用され得る。さらに、本方法(または実施形態)それぞれ、エンコーダ、およびデコーダは、処理回路(例えば、１つ以上のプロセッサ、または、１つ以上の集積回路)によって実装され得る。一つの例において、１つ以上のプロセッサは、非一時的コンピュータ読取り可能な媒体に保管されたプログラムを実行する。本開示における実施形態は、ルマブロックまたはクロマブロックに適用することができる。

【0181】

上述の技術は、コンピュータ読取り可能な命令を使用してコンピュータソフトウェアとして実装され、そして、１つ以上のコンピュータ読取り可能な媒体に物理的に保管され得る。例えば、図28は、開示される技術的事項の所定の実施形態を実施するのに適したコンピュータシステム(2800)を示している。

【0182】

コンピュータソフトウェアは、任意の適切なマシンコードまたはコンピュータ言語を使用してコード化され得る。アセンブル、コンパイル、リンク、もしくは、１つ以上のコンピュータ中央処理装置（CPU）、グラフィックス処理装置(GPU),
などによって、直接的、または、インタープリタ、マイクロコード実行、などを通して実行され得る命令を含むコードを作成するための類似のメカニズムの対象となり得るものである。

【0183】

命令は、様々なタイプのコンピュータまたはその構成要素上で実行され得る。例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット、等を含むものである。

【0184】

コンピュータシステム(2800)のための図28に示される構成要素は、本質的に例示的なものであり、そして、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能性の範囲について、いかなる制限も示唆するように意図されたものではない。また、構成要素の構成は、コンピュータシステム(2800)の例示的な実施形態において示される構成要素の任意の１つまたは組み合わせに関して、いかなる従属性または要件も有するものとして解釈されてはならない。

【0185】

コンピュータシステム(2800)は、所定のヒューマンインターフェイス入力デバイスを含み得る。そうしたヒューマンインターフェイス入力装置は、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き、といったもの)、音声入力(声、拍手、といったもの)、視覚入力(ジェスチャ、といったもの)、嗅覚入力(図示なし)を通じて、一人以上の人間ユーザによる入力に対して応答し得る。ヒューマンインターフェイス装置は、また、オーディオ(スピーチ、音楽、環境音、といったもの)、画像(スキャンされた画像、静止画像カメラから獲得した写真画像、といったもの)、ビデオ(2次元ビデオ、立体映像を含む3次元ビデオといったもの)といった、人間による意識的入力に必ずしも直接的に関係しない所定の媒体をキャプチャするためにも使用され得る。

【0186】

入力ヒューマンインターフェイスデバイスは、キーボード(2801)、マウス(2802)、トラックパッド(2803)、タッチスクリーン(2810)、データグローブ(図示なし)、ジョイスティック(2805)、マイクロフォン(2806)、スキャナ(2807)、カメラ(2808)の１つ以上を含み得る（それぞれ１つだけが描かれている）。

【0187】

コンピュータシステム(2800)は、また、所定のヒューマンインターフェイス出力デバイスを含み得る。そうしたヒューマンインターフェイス出力装置は、例えば、触覚出力、音、光、および嗅覚／味覚を通して、一人以上の人間ユーザの感覚を刺激することができる。そうしたヒューマンインターフェイス出力装置は、触覚出力装置(例えば、タッチスクリーン(2810)、データグローブ(図示なし)、またはジョイスティック(2805)、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在する)、オーディオ出力装置(スピーカ(2809)、ヘッドフォン(図示なし)といったもの)、視覚出力装置(CRTスクリーン、LCDスクリーン、プラズマスクリーンを含むスクリーン(2810）といったものであり、それぞれがタッチスクリーン入力能力を有し又は有さず、それぞれが触覚フィードバック能力を有し又は有さない。－そのうちいくつかは、立体画法（stereographic）出力といった手段、仮想現実メガネ(図示なし)、ホログラフィックディスプレイおよびスモーク（smoke）タンク(図示なし)、およびプリンタ(図示なし)、を介して、2次元の視覚出力または3次元以上の出力を出力することができる。)を含み得る。

【0188】

コンピュータシステム(2800)は、また、人間がアクセス可能な記憶装置およびそれらの関連媒体を含むことができる。CD/DVD等の媒体(2821)を伴うCD/DVD ROM/RW(2820)を含む光媒体、サムドライブ（thumb-drive）(2822)、リムーバブルハードドライブまたはソリッドステートドライブ(2823)、テープおよびフロッピー（登録商標）ディスク(図示なし)といった従来の磁気媒体、セキュリティドングル（security dongle）(図示なし)といった特殊化されたROM/ASIC/PLDベースの装置など、といったものである。

【0189】

当業者は、また、現在開示されている技術的事項（subject matter）に関連して使用される用語「コンピュータ読取可能媒体（“computer readable media”）」は、伝送媒体、搬送波、または他の過渡信号を包含しないことも理解すべきである。

【0190】

コンピュータシステム(2800)は、また、１つ以上の通信ネットワーク(2855)へのインターフェイス(2854)も含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性、等であり得る。ネットワークの例は、イーサネットといったローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、および地上放送TVを含むTVワイドエリアまたはワイドエリアデジタルネットワーク、CANバスを含む車両および工業など、を含む。所定のネットワークは、一般的に、所定の汎用データポートまたはペリフェラルバス(2849)に接続される外部ネットワークインターフェイスアダプタ(例えば、コンピュータシステム(2800)のUSBポート、といったもの)を必要とする。他のものは、一般的に、以下で説明するように、システムバスへの取付け（attachment）によって、コンピュータシステム(2800)のコアに統合される(例えば、PCコンピュータシステムへのイーサネットインターフェイス、または、スマートフォンコンピュータシステムへのセルラーネットワークインターフェイス)。これらのネットワークのいずれかを使用して、コンピュータシステム(2800)は、他のエンティティと通信することができる。そうした通信は、単指向性、受信専用(例えば、放送テレビ)、単指向性送信専用(例えば、所定のCANバスデバイスへのCANバス)、または、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの双指向性、であり得る。所定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェイスそれぞれで使用され得る。

【0191】

前述のヒューマンインターフェイスデバイス、人がアクセス可能なストレージデバイス、およびネットワークインターフェイスは、コンピュータシステム(2800)のコア(2840)に取付けることができる。

【0192】

コア(2840)は、１つ以上の中央処理装置(CPU)(2841)、グラフィックス処理装置(GPU)(2842)、フィールドプログラマブルゲートアレイ(FPGA)(2843)の形式の特殊なプログラマブル処理装置、所定のタスクのためのハードウェアアクセラレータ(2844)、グラフィックアダプタ(2850)、などを含むことができる。これらの装置は、リードオンリーメモリ(ROM)(2845)、ランダムアクセスメモリ(2846)、内部非ユーザクセス可能ハードドライブといった内部大容量ストレージ、SSD、等(2847)と共に、システムバス(2848)を介して接続され得る。いくつかのコンピュータシステムにおいて、システムバス(2848)は、追加のCPU、GPUなどによる拡張を可能にするために、１つ以上の物理的プラグの形式でアクセス可能である。周辺装置は、コアのシステムバス(2848)に直接的に接続されるか、または、ペリフェラルバス(2849)を介して接続され得る。一つの例において、スクリーン(2810)をグラフィックアダプタ(2850)に接続することができる。ペリフェラルバスのアーキテクチャは、PCI、USB、などを含む。

【0193】

CPU(2841)、GPU(2842)、FPGA(2843)、およびアクセラレータ(2844)は、組み合わせて、上述のコンピュータコードを構成することができる、所定の命令を実行することができる。そのコンピュータコードは、ROM(2845)またはRAM(2846)に保管することができる。移行データも、また、RAM(2846)に保管することができるが、一方で、永久データは、例えば、内部大容量ストレージ(2847)に保管することができる。１つ以上のCPU(2841)、GPU(2842)、大容量ストレージ(2847)、ROM(2845)、RAM(2846)、などと密接に関連付けることができる、キャッシュメモリの使用を通じて、メモリデバイスのいずれかへの高速ストレージおよび取出し可能にすることができる。

【0194】

コンピュータ読取可能媒体は、様々なコンピュータ実装されたオペレーションを実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計され、かつ、構築されたものであってよく、または、コンピュータソフトウェア技術の当業者に周知であり、かつ、利用可能な種類のものであってよい。

【0195】

非限定的な例として、アーキテクチャ(2800)を有するコンピュータシステム、および、特にコア(2840)は、１つ以上の有形で、コンピュータ読取可能媒体において具現化されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ、などを含む)の結果として機能性を提供することができる。そうしたコンピュータ読取可能媒体は、上述のようにユーザがアクセス可能な大容量ストレージ、並びに、コア-内部大容量ストレージ(2847)またはROM(2845)といった、非一時的な性質のコア(2840)に係る措定のストレージ、に関連する媒体であってよい。本開示の様々な実施形態を実装するソフトウェアは、そうしたデバイスに保管され、そして、コア(2840)によって実行され得る。コンピュータ読取可能媒体は、特定のニーズに従って、１つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア(2840)、および、具体的にはその中のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM(2846)に保管されたデータ構造を定義すること、および、ソフトウェアによって定義されたプロセスに従って、そうしたデータ構造を修正することを含む、ここにおいて説明された特定のプロセス、または、特定のプロセスの特定部分を実行させることができる。加えて又は代替として、コンピュータシステムは、回路(例えば、アクセラレータ(2844)内で配線され（hardwired）、または他の方法で具現化されたロジックの結果として機能性を提供することができる。これは、ここにおいて説明される特定のプロセスまたは特定のプロセスの特定部分を実行するためのソフトウェアの代わりに、またはソフトウェアと共に動作することができる。ソフトウェアへの参照は、論理を含み、そして、必要に応じて、その逆も同様である。コンピュータ読取可能媒体への参照は、実行のためのソフトウェアを保管する回路（集積回路（IC）といったもの）、実行のためのロジックを具体化する回路、または、必要に応じて、両方を含むことができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含している。

【0196】

本開示は、いくつかの例示的な実施形態を説明してきたが、変更、順列、および様々な代替同等物が存在しており、これらは本開示の範囲内にある。従って、当業者であれば、本開示において明示的には示されていない、または、記述されていないが、本開示の原則を具体化し、そして、従って、その精神および範囲内にある多数のシステムおよび方法を考案することができるであろうことが正しく理解されるだろう。

【0197】

付録Ａ:頭字語
JEM:共同探索モデル
VVC:バーサタイルビデオコーディング
BMS:ベンチマークセット
MV:動きベクトル
HEVC:高効率ビデオコーディング
SEI:補足拡張情報
VUI:ビデオユーザビリティ情報
GOP:ピクチャグループ
TU:変換ユニット
PU:予測ユニット
CTU:コーディングツリーユニット
CTB:コーディングツリーブロック
PBs:予測ブロック
HRD:仮想参照デコーダ
SNR:信号雑音比
CPU:中央処理装置
GPU:グラフィックス処理装置
CRT:ブラウン管
LCD:液晶ディスプレイ
OLED:有機発光ダイオード
CD:コンパクトディスク
DVD:デジタルビデオディスク
ROM:リードオンリーメモリ
RAM:ランダムアクセスメモリ
ASIC:特定用途向け集積回路
PLD:プログラマブルロジックデバイス
LAN:ローカルエリアネットワーク
GSM:モバイル通信のためのグローバルシステム
LTE:ロングタームエボリューション
CANBus:コントローラエリアネットワークバス
USB:ユニバーサルシリアルバス
PCI:周辺機器相互接続
FPGA:フィールドプログラマブルゲートアレイ
SSD:ソリッドステートドライブ
IC:集積回路
HDR:ハイダイナミックレンジ
SDR:標準ダイナミックレンジ
JVET:共同ビデオ探索チーム
MPM:最確モード
WAIP:広角イントラ予測
CU:コーディングユニット
PU:予測ユニット
TU:変換ユニット
CTU:コーディングツリーユニット
PDPC:位置依存の予測組み合わせ
ISP:イントラサブパーティション
SPS:シーケンスパラメータ設定
PPS:ピクチャパラメータセット
APS:適応パラメータセット
VPS:ビデオパラメータセット
DPS:デコーディングパラメータセット
ALF:適応ループフィルタ
SAO:サンプル適応オフセット
CC-ALF:クロスコンポーネント適応ループフィルタ
CDEF:制約付き方向性拡張フィルタ
CCSO:クロスコンポーネントサンプルオフセット
LSO:ローカルサンプルオフセット
LR:ループ復元フィルタ
AV1:AOMediaビデオ1
AV2:AOMediaビデオ2
LFNST:低周波非分離変換
IST:イントラ二次変換

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】