特許 7254187 ビデオ復号用の方法、装置およびプログラム

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

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

(11)【特許番号】

(24)【登録日】2023-03-30

(45)【発行日】2023-04-07

(54)【発明の名称】ビデオ復号用の方法、装置およびプログラム

(51)【国際特許分類】

   H04N 19/96 20140101AFI20230331BHJP

   H04N 19/107 20140101ALI20230331BHJP

   H04N 19/136 20140101ALI20230331BHJP

   H04N 19/176 20140101ALI20230331BHJP

   H04N 19/70 20140101ALI20230331BHJP

【ＦＩ】

H04N19/96

H04N19/107

H04N19/136

H04N19/176

H04N19/70

【請求項の数】 9

(21)【出願番号】P 2021540568

(86)(22)【出願日】2020-06-04

(65)【公表番号】

(43)【公表日】2022-03-04

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

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

(87)【国際公開日】2020-12-10

【審査請求日】2021-07-13

(31)【優先権主張番号】62/858,891

(32)【優先日】2019-06-07

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

(31)【優先権主張番号】62/906,171

(32)【優先日】2019-09-26

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

(31)【優先権主張番号】16/891,966

(32)【優先日】2020-06-03

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】リャン・ジャオ

(72)【発明者】

【氏名】シン・ジャオ

(72)【発明者】

【氏名】シアン・リ

(72)【発明者】

【氏名】シャン・リュウ

【審査官】清山 昂平

(56)【参考文献】

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

【文献】Liang Zhao, et al.，Non-CE3: ISP extension to avoid small Chroma intra blocks，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-P0511，2019年09月25日

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

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

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

【請求項1】

デコーダにおけるビデオ復号用の方法であって、
符号化されたビデオシーケンスの一部である現在の画像における現在のブロックに対する予測情報を復号するステップであって、前記予測情報は、前記現在のブロックに対するパーティションタイプと、ブロックサイズとを示すステップと、
シングルパーティションツリーにおける小クロマイントラ予測ユニット（ＳＣＩＰＵ）領域のためのローカルパーティションツリーを生成するステップであって、前記ＳＣＩＰＵ領域のための前記ローカルパーティションツリーのツリー深さは、閾値と、前記ＳＣＩＰＵ領域がインター符号化されているか否かとに基づく、ステップと、
前記現在のブロックが前記ローカルパーティションツリーの親ノードであるか否かを、前記現在のブロックの前記パーティションタイプと前記ブロックサイズとに基づいて決定するステップと、
前記現在のブロックが前記ローカルパーティションツリーの前記親ノードであることに応じて、前記ローカルパーティションツリーに従って前記現在のブロックを分割するステップと、
前記現在のブロックの予測モードに基づいて、前記現在のブロックを再構築するステップと、を含む方法。

【請求項2】

前記現在のブロックの前記予測モードは、（ｉ）前記ブロックサイズが６４サンプルであり、前記ローカルパーティションツリーが四分木であること、または（ｉｉ）前記ブロックサイズが６４サンプルであり、前記ローカルパーティションツリーが三分木であること、または（ｉｉｉ）前記ブロックサイズが３２サンプルであり、前記ローカルパーティションツリーが二分木であることに基づいて、非インター予測モードであると判定される、請求項１に記載の方法。

【請求項3】

前記現在のブロックの前記予測モードは、前記予測情報に含まれる信号伝達されたフラグと、（ｉ）前記ブロックサイズが６４サンプルであり、前記ローカルパーティションツリーが二分木であること、または（ｉｉ）前記ブロックサイズが１２８サンプルであり、前記ローカルパーティションツリーが三分木であることとに基づいて、決定される、請求項１に記載の方法。

【請求項4】

前記閾値は、前記現在のブロックがインター符号化された場合、第１の閾値であり、前記現在のブロックが非インター符号化された場合、第２の閾値であり、前記第１の閾値は、前記第２の閾値よりも小さい、請求項１に記載の方法。

【請求項5】

前記現在のブロックが前記ローカルパーティションツリーの前記親ノードであることに基づいて、前記現在のブロックをＳＣＩＰＵであると判定するステップをさらに含む、請求項１に記載の方法。

【請求項6】

前記分割するステップは、
前記現在のブロックの前記予測モードが決定されているか否かに基づいて前記現在のブロックを分割するステップをさらに含む、請求項１に記載の方法。

【請求項7】

前記分割するステップは、
前記現在のブロックがインター符号化されているか否かに基づいて前記現在のブロックを分割するステップをさらに含む、請求項１に記載の方法。

【請求項8】

処理回路を含む、装置であって、
処理回路に請求項１～７のいずれか一項に記載の方法を実現させる、装置。

【請求項9】

コンピュータに請求項１～７のいずれか一項に記載の方法を実現させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０２０年６月３日に出願した米国特許出願第１６／８９１，９６６号「ビデオ符号化用の方法と装置」の優先権の利益を主張し、同米国特許出願は、２０１９年６月７日に出願した米国仮出願第６２／８５８，８９１号「小さなクロマブロックのサイズ制限」、および２０１９年９月２６日に出願した米国仮出願第６２／９０６，１７１号「ローカルデュアルツリーの改善」の優先権の利益を主張する。これらの先行出願の全開示内容は、参照により全体が本願に組み込まれる。

【0002】

本開示は、ビデオ符号化に関連する実施形態を説明する。

【背景技術】

【0003】

本明細書で提供される背景記述は、本開示の文脈を一般的に提示することを目的とする。この背景部分において記述される範囲で、本願において名前の記載がある発明者の研究、およびその他の点で出願時に先行技術として認められない明細書の態様は、本開示に対する先行技術として明示的にも暗黙的にも認められることができない。

【0004】

ビデオ符号化および復号は、動き補償を用いたインター画像予測を使用して実行されてもよい。非圧縮デジタルビデオは、一連の画像が含まれ、各画像が、例えば、１９２０×１０８０の輝度サンプルおよび関連するクロミナンスサンプルの空間次元を有する。前記の一連の画像は、例えば、６０画像／秒または６０Ｈｚの、固定または可変画像レート（非公式にはフレームレートとも呼ばれる）を有し得る。非圧縮ビデオは、相当数のビットレートを必要とする。例えば、サンプルあたり８ビットでの１０８０ｐ６０、４：２：０ビデオ（６０Ｈｚのフレームレートで１９２０ｘ１０８０の輝度サンプル解像度）は、１．５Ｇｂｉｔ／ｓに近い帯域が必要となる。１時間分のそのようなビデオは、６００ＧＢｙｔｅｓを超えるストレージスペースが必要となる。

【0005】

ビデオ符号化および復号の目的の１つは、圧縮によって入力ビデオ信号の冗長性が低減されることができる。圧縮は、前述の帯域幅またはストレージスペースの要求を、２桁以上も削減することができる場合もある。可逆圧縮および非可逆圧縮の両方、または、それらの組み合わせを用いてもよい。可逆圧縮は、圧縮された元の信号から、元の信号の正確なコピーを再構築する技術によるものである。非可逆圧縮を用いる場合、再構築された信号は、元の信号と同一ではないこともあるが、元の信号と再構築された信号との間の歪みは充分小さくで、意図する用途に用いることができる。ビデオの場合には、非可逆圧縮が広く使用されている。許容される歪みの量は、アプリケーションによって異なり、例えば、特定の消費者向けるストリーミングアプリケーションに対するユーザは、テレビ配信アプリケーションに対するユーザよりも高い歪みを許容する可能性がある。圧縮率の実現は、許される／許容できる歪みが大きいほど、より高い圧縮率になるとしもよい。

【0006】

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

【0007】

ビデオコーデック技術は、イントラコーディングとして知られている技術を含んでもよい。イントラコーディングにおいて、サンプル値は、以前に再構築された参照画像からのサンプルまたはその他のデータを参照しないように表される。一部のビデオコーデックにおいて、前記の画像は、サンプルのブロックに空間的に分割される。サンプルの全てのブロックがイントラモードで符号化されている場合、その画像はイントラ画像であってもよい。イントラ画像と、独立したデコーダリフレッシュ画像などのその派生物とは、デコーダの状態をリセットするために使用されてもよく、したがって、符号化されたビデオビットストリームおよびビデオセッションの最初の画像として、あるいは静止画像として使用されてもよい。イントラブロックにおけるサンプルは、変換にさらされてもよく、変換係数はエントロピーコーディングの前に量子化されてもよい。イントラ予測は、変換前ドメインのサンプル値を最小化する技術であり得る。場合によっては、変換後のＤＣ値が小さいほど、またＡＣ係数が小さいほど、エントロピーコーディング後にブロックを表現するために所定の量子化ステップサイズにおいて必要とされるビット数が少なくなる。

【0008】

例えばＭＰＥＧ－２世代のコーディング技術から知られるような従来のイントラコーディングは、イントラ予測を使用しない。しかしながら、新しいビデオ圧縮技術の中には、空間的に隣接し、復号順序において先行するデータブロックのエンコーディング／復号時に得られる、例えば周辺のサンプルデータやメタデータから試みる技術がある。このような技術を、以下、「イントラ予測」技術と呼ぶ。なお、少なくともいくつかの場合において、イントラ予測は、参照画像からではなく、再構築中の現在の画像からの参照データのみを使用している。

【0009】

イントラ予測には多くの異なる形態があり得る。特定のビデオ符号化技術において、このような技術から複数を使用することができる場合、使用される技術はイントラ予測モードで符号化されてもよい。場合によっては、モードにはサブモードおよび／またはパラメータがあり、それらは個別に符号化されたり、モードコードワードに含められてもよい。所定のモード／サブモード／パラメータの組み合わせに対して、いずれのコードワードを使用するかは、イントラ予測によるコーディング効率をどの程度向上させられるかを左右し、また、コードワードをビットストリームに変換する際に使用されるエントロピーコーディング技術も同様に影響する。

【0010】

特定のモードのイントラ予測が、Ｈ．２６４で導入され、Ｈ．２６５で改善され、またＪｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅｌ（ＪＥＭ）、Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＶＶＣ）、Ｂｅｎｃｈｍａｒｋ Ｓｅｔ（ＢＭＳ）などの新しいコーディング技術において、さらに改善された。予測変数ブロックは、すでに利用可能なサンプルに属する隣接するサンプル値を用いて形成されてもよい。隣接するサンプルのサンプル値は、方向に従って予測変数ブロックにコピーされる。使用される方向への参照は、ビットストリームに符号化されるか、またはそれ自体が予測されてもよい。

【0011】

図１Ａを参照すると、右下に描かれているのは、Ｈ．２６５の、可能性のある３３個の予測変数方向（３５のイントラモードのうちの３３個の角度モードに対応）から知られている９個の予測変数方向のサブセットである。矢印が収束する点（１０１）は、予測されているサンプルを表す。矢印は、サンプルが予測されている方向を表す。例えば、矢印（１０２）は、サンプル（１０１）が、右上、水平からの角度が４５度の位置にあるサンプルから予測されていることを示す。同様に、例えば、矢印（１０３）は、サンプル（１０１）が、サンプル（１０１）の左下、水平からの角度が２２．５度の位置にあるサンプルから予測されていることを示す。

【0012】

図１Ａをさらに参照すると、左上には、４×４サンプルの正方形ブロック（１０４）が描かれている（太い破線で示されている）。正方形ブロック（１０４）は、１６個のサンプルを含み、各サンプルは、「Ｓ」、そのＹ次元での位置（例えば、行インデックス）、およびそのＸ次元での位置（例えば、列インデックス）により分類されている。例えば、サンプルＳ２１は、Ｙ次元における（上から）２番目のサンプルであり、Ｘ次元における（左から）１番目のサンプルである。同様に、サンプルＳ４４は、ブロック（１０４）において、Ｙ次元およびＸ次元の両方において４番目のサンプルである。ブロックのサイズが４×４サンプルなので、Ｓ４４は右下に位置する。さらに、同様の番号付け構成に従った参照サンプルを示す。参照サンプルは、Ｒ、ブロック（１０４）に対するＹ位置（行インデックスなど）、Ｘ位置（列インデックス）により分類されている。Ｈ．２６４およびＨ．２６５において、ともに、予測サンプルは再構築中のブロックに隣接するため、負の値を用いる必要はない。

【0013】

イントラ画像予測は、信号伝達された予測方向により割り当てられた、隣接するサンプルから参照サンプル値をコピーすることにより機能する。ここで、例えば、符号化されたビデオビットストリームが、このブロックに対して、矢印（１０２）に一致する予測方向を示す信号伝達を含んでいると仮定する。すなわち、サンプルは、右上、水平から４５度の角度の位置にある予測サンプルから予測される。その場合、サンプルＳ４１、Ｓ３２、Ｓ２３、およびＳ１４は、同じ参照サンプルＲ０５から予測される。そして、サンプルＳ４４は、参照サンプルＲ０８から予測される。

【0014】

特定の場合おいて、参照サンプルを計算するために、多重参照サンプルの値は、特に方向が４５度ずつ均等に分割することができない場合、例えば補間によって結合してもよい。

【0015】

ビデオ符号化技術の発展に伴い、可能な方向の数は増加している。Ｈ．２６４（２００３年）では、９種類の方向を表すことが可能となった。それがＨ．２６５（２０１３年）では３３に増え、ＪＥＭ／ＶＶＣ／ＢＭＳは本開示の時点で最大９３方向をサポートすることができる。最も可能性の高い方向を特定するための実験が行われており、比較的に可能性の低い方向に関してはある程度の不利益は甘受して、それらの可能性の高い方向を少数のビットで表現するために、エントロピーコーディングにおける特定の技術が用いられている。さらに、方向そのものが、既に復号された隣接ブロックにおいて使用されている隣接方向から予測できる場合もある。

【0016】

図１Ｂは、ＪＥＭによる６５個のイントラ予測方向を描いた概略図（１０５）であり、時間の経過とともに予測方向の数が増加することを示す。

【0017】

方向を表す符号化されたビデオビットストリーム内のイントラ予測方向ビットのマッピングは、ビデオ符号化技術ごとに異なる場合があり、例えば、予測方向の単純な直接的なマッピング、イントラ予測モード、コードワード、最確のモードを伴う複雑な適応型スキーム、その他の類似技術などの範囲にまでおよぶ。しかしながら、いかなる場合でも、統計的に他の方向よりもビデオコンテンツにおいて発生する可能性が低い特定の方向が存在する可能性がある。ビデオ圧縮の目的は冗長性の削減であるため、適切に機能するビデオ符号化技術において、そのような可能性の低い方向は、可能性の高い方向よりも多くのビットで表現されることになる。

【0018】

動き補償は、非可逆圧縮技術であり得、また、以前に再構築された画像またはその一部（参照画像）からのサンプルデータのブロックが、動きベクトル（以降、ＭＶ）によって示される方向に空間的にシフトされた後、新たに再構築される画像または画像部分の予測のために用いられる技術に関連し得る。場合によっては、参照画像は、現在再構築中の画像と同じであり得る。ＭＶは、２つの次元ＸおよびＹを有するか、または３つの次元を有してもよく、第３の次元は使用中の参照画像を表示するものである（後者は、間接的には、時間次元であってもよい）。

【0019】

一部のビデオ圧縮技術において、サンプルデータの特定の領域に適用可能なＭＶは、他のＭＶ、例えば再構築中の領域に空間的に隣接し、復号の順においてそのＭＶに先行するサンプルデータの別の領域に関連するＭＶから予測することができる。そうすることにより、ＭＶのコーディングに必要なデータ量を大幅に減らし、これにより冗長性を除去し、圧縮率を高めることができる。ＭＶ予測が効果的に機能するのは、例えば、カメラから得られる入力ビデオ信号（自然ビデオとして知られている）を符号化する場合、１つのＭＶが適用できる領域よりも大きな領域は類似の方向に動くという統計的な可能性があり、したがって、場合によっては、隣接する領域のＭＶから導出される類似の動きベクトルを用いて予測することができるためである。その結果、ある特定の領域に対するＭＶは、周辺のＭＶから予測されるＭＶに類似するか、同じであるということが判明し、エントロピーコーディングの後、ＭＶを直接にコーディングした場合に用いられるよりも少ないビット数で表現することができるようになる。ＭＶ予測は、元の信号（すなわちサンプルストリーム）から得られる信号（すなわちＭＶ）の可逆圧縮の一例である場合がある。ＭＶ予測自体が、例えば、周囲の複数のＭＶから予測変数を計算する際の丸め誤差により、非可逆性である場合もある。

【0020】

様々なＭＶ予測メカニズムがＨ．２６５／ＨＥＶＣ（ＩＴＵ－Ｔ Ｒｅｃ． Ｈ．２６５，「高効率ビデオ符号化」、２０１６年１２月）に記載されている。Ｈ．２６５が提供する多くのＭＶ予測メカニズムのうち、本願においては、以降「空間マージ」と呼ぶ技術について述べる。

【0021】

図１Ｃを参照すると、現在のブロック（１１１）は、空間的にシフトされた同じサイズの先行するブロックから予測可能であることが動きサーチプロセス時にエンコーダにより判明したサンプルを含む。そのＭＶを直接に符号化する代わりに、Ａ０、Ａｌ、およびＢ０、Ｂｌ、Ｂ２（それぞれ１１２～１１６）と表記された周囲のサンプルのいずれかに関連付けられたＭＶを用いて、１つまたは複数の参照画像に関連付けられたメタデータから、例えば（エンコーディングの順において）最新の参照画像から、ＭＶを導出することができる。Ｈ．２６５において、ＭＶ予測に、隣接するブロックが使用しているのと同じ参照画像の予測変数を用いることができる。

【発明の概要】

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

【0022】

本開示の態様は、ビデオエンコーディング／復号用の方法および装置を提供する。一部の例において、ビデオ復号用の装置は、処理回路を含む。

【課題を解決するための手段】

【0023】

本開示の態様によれば、デコーダにおけるビデオ復号用の方法が提供される。本方法において、符号化されたビデオシーケンスの一部である現在の画像の現在のブロックの予測情報を復号する。予測情報は、現在のブロックに対するシングルパーティションツリー構造と、ブロックサイズとを示す。現在のブロックがローカルパーティションツリー構造の親ノードであるか否かは、シングルパーティションツリー構造と現在のブロックのブロックサイズとに基づいて決定される。ローカルパーティションツリー構造のツリー深さは閾値以下である。現在のブロックがローカルパーティションツリー構造の親ノードであることに応じて、現在のブロックはローカルパーティションツリー構造に従って分割される。この場合、現在のブロックは、現在のブロックの予測モードに基づいて再構築される。

【0024】

一実施形態において、現在のブロックの予測モードは、（ｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が四分木であること、または（ｉｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が三分木であること、または（ｉｉｉ）ブロックサイズが３２サンプルであり、ローカルパーティションツリー構造が二分木であることに基づいて、非インター予測であると判定される。

【0025】

一実施形態において、現在のブロックの予測モードの決定は、予測情報に含まれる信号伝達されたフラグに基づき、かつ、（ｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が二分木であることに基づいて、または（ｉｉ）ブロックサイズが１２８サンプルであり、ローカルパーティションツリー構造が三分木であることに基づいて、決定される。

【0026】

一実施形態において、閾値は、現在のブロックがインター符号化されていれば、第１の閾値であり、現在のブロックが非インター符号化されていれば、第２の閾値であり、ここで第１の閾値は第２の閾値とは異なる。

【0027】

一実施形態において、現在のブロックは、現在のブロックがローカルパーティションツリー構造の親ノードであることに基づいて、小クロマイントラ予測ユニット（ＳＣＩＰＵ）であると判定される。

【0028】

一実施形態において、現在のブロックは、現在のブロックの予測モードが決定されているか否かに基づいて分割される。

【0029】

一実施形態において、現在のブロックは、現在のブロックがインター符号化されているか否かに基づいて分割される。

【0030】

本開示の態様は、ビデオ復号の方法のいずれか１つまたはその組み合わせを実行するように構成された装置を提供する。一実施形態において、本装置は、符号化されたビデオシーケンスの一部である現在の画像内の現在のブロックに対する予測情報を復号する処理回路を含む。予測情報は、現在のブロックに対するシングルパーティションツリー構造およびブロックサイズを示す。処理回路は、現在のブロックがローカルパーティションツリー構造の親ノードであるか否かを、シングルパーティションツリー構造と現在のブロックのブロックサイズとに基づいて決定する。ローカルパーティションツリー構造のツリー深さが閾値以下である。処理回路は、現在のブロックがローカルパーティションツリー構造の親ノードであることに応じて、ローカルパーティションツリー構造に従って現在のブロックを分割する。処理回路は、現在のブロックの予測モードに基づいて、現在のブロックを再構築する。

【0031】

本開示の態様によれば、デコーダにおけるビデオ復号用の方法が提供される。本方法において、符号化されたビデオシーケンスの一部である現在の画像の現在のブロックの予測情報が復号される。予測情報は、現在のブロックのクロマサンプルに対するパーティションツリー構造を示す。現在のブロックのクロマサンプルは、パーティションツリー構造に基づいて、複数のサブブロックに分割される。複数のサブブロック内のサブブロックのクロマサンプルは、（ｉ）サブブロックの上方隣接サンプルおよび左隣接サンプルの少なくとも１つがサブブロックの予測に利用不可能であること、および（ｉｉ）サブブロックのブロックサイズがサイズ閾値以下であること、またはサブブロックの辺の長さが長さ閾値以下であることに応じて、クロマイントラ予測モードのサブセットに基づいて予測される。現在のブロックは、予測されたクロマサンプルに基づいて再構築される。

【0032】

一実施形態において、現在のブロックのブロックサイズはサイズ閾値よりも大きく、サブブロックのブロックサイズはサイズ閾値以下であるか、または現在のブロックの辺の長さは長さ閾値よりも大きく、サブブロックの辺の長さは長さ閾値以下である。

【0033】

一実施形態において、サイズ閾値は、２×２、２×４、４×２、およびルーマイントラ符号化された許容される最小のブロックのブロックサイズのいずれかを含み、長さ閾値は、２、４、およびルーマイントラ符号化された許容される最小のブロックの辺の長さのいずれかを含む。

【0034】

一実施形態において、クロマイントラ予測モードは、平面モード、ＤＣモード、水平モード、垂直モード、派生モード（ＤＭ）、左クロス成分リニアモード（Ｌ＿ＣＣＬＭ）、上方クロス成分リニアモード（Ｔ＿ＣＣＬＭ）、および左および上方クロス成分リニアモード（ＬＴ＿ＣＣＬＭ）を含む。

【0035】

一実施形態において、クロマイントラ予測モードのサブセットは、クロマイントラ予測モードのうちの１つまたは２つを含む。

【0036】

一実施形態において、クロマイントラ予測モードのサブセットは、サブブロックの上方隣接サンプルがサブブロックの予測に利用不可能であり、かつ現在のブロック内に位置することに基づいて、ＤＭ、Ｌ＿ＣＣＬＭ、および垂直モードのうちの少なくとも１つを含む。

【0037】

一実施形態において、クロマイントラ予測モードのサブセットは、サブブロックの左隣接サンプルがサブブロックの予測に利用不可能であり、かつ現在のブロック内に位置することに応じて、ＤＭ、Ｔ＿ＣＣＬＭ、および水平モードのうちの少なくとも１つを含む。

【0038】

一実施形態において、現在のブロックは、すべてのサブブロックが並列に再構築される並列処理可能領域（ＰＰＲ）である。

【0039】

本開示の態様は、ビデオ復号用の方法のいずれか１つまたはその組み合わせを実行するように構成された装置を提供する。一実施形態において、本装置は、符号化されたビデオシーケンスの一部である現在の画像の現在のブロックの予測情報を復号する処理回路を含む。予測情報は、現在のブロックのクロマサンプルのパーティションツリー構造を示す。処理回路は、現在のブロックのクロマサンプルを、パーティションツリー構造に基づいて、複数のサブブロックに分割する。処理回路は、複数のサブブロック内のサブブロックのクロマサンプルを、（ｉ）サブブロックの上方隣接サンプルおよび左隣接サンプルの少なくとも１つがサブブロックの予測に利用不可能であること、および（ｉｉ）サブブロックのブロックサイズがサイズ閾値以下であること、またはサブブロックの辺の長さが長さ閾値以下であることに応じて、クロマイントラ予測モードのサブセットに基づいて予測する。処理回路は、予測されたクロマサンプルに基づいて、現在のブロックを再構築する。

【0040】

また、本開示の実施態様は、ビデオ復号用のコンピュータによって実行されたとき、ビデオ復号用の方法のうちの任意の１つまたはそれらの組み合わせをコンピュータに実行させる命令を格納した非一時的なコンピュータ可読媒体を提供する。

【図面の簡単な説明】

【0041】

開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面から、より明らかになるものである。

【0042】

【図1A】イントラ予測モードの例示的なサブセットの概略図を示す図である。

【図1B】例示的なイントラ予測方向の説明を示す図である。

【図1C】一例における、現在のブロックおよびその周囲の空間マージ候補の概略図を示す図である。

【図2】一実施形態による通信システムの簡略化されたブロック図の概略図を示す図である。

【図3】一実施形態による通信システムの簡略化されたブロック図の概略図を示す図である。

【図4】一実施形態によるデコーダの簡略化されたブロック図の概略図を示す図である。

【図5】一実施形態によるエンコーダの簡略化されたブロック図の概略図を示す図である。

【図6】別の実施形態によるエンコーダのブロック図を示す図である。

【図7】別の実施形態によるデコーダのブロック図を示す図である。

【図8A】四分木プラス二分木（ＱＴＢＴ）分割構造とそれに対応するＱＴＢＴ構造とを用いたブロック分割の例を示す図である。

【図8B】四分木プラス二分木（ＱＴＢＴ）分割構造とそれに対応するＱＴＢＴ構造とを用いたブロック分割の例を示す図である。

【図9A】垂直センターサイド三分木（ＴＴ）分割の例を示す図である。

【図9B】水平センターサイドＴＴ分割の一例を示す図である。

【図10】一部の例における例示的なイントラ予測方向を示す図である。

【図11A】一実施形態による並列処理可能領域（ＰＰＲ）の例示的な形状を示す図である。

【図11B】一実施形態による並列処理可能領域（ＰＰＲ）の例示的な形状を示す図である。

【図11C】一実施形態による並列処理可能領域（ＰＰＲ）の例示的な形状を示す図である。

【図11D】一実施形態による並列処理可能領域（ＰＰＲ）の例示的な形状を示す図である。

【図11E】一実施形態による並列処理可能領域（ＰＰＲ）の例示的な形状を示す図である。

【図12】一実施形態による例示的なプロセスを概説するフローチャートを示す図である。

【図13A】一実施形態によるいくつかの例示的なサブパーティションを示す図である。

【図13B】一実施形態によるいくつかの例示的なサブパーティションを示す図である。

【図14】一実施形態による異なるＹＵＶフォーマットを示す図である。

【図15】一実施形態による例示的な多重参照線イントラ予測を示す図である。

【図16】一実施形態による例示的なプロセスを概説するフローチャートを示す図である。

【図17】一実施形態によるコンピュータシステムの概略図を示す図である。

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

【0043】

本開示は、１つまたは複数の小ブロックサイズと、ローカルデュアルツリーの実行とに向けられた実施形態を含む。実施形態は、小ブロック（例えば、小クロマブロック）の制約およびローカルデュアルツリーの使用を改善するための方法、装置、および非一時的なコンピュータ可読記憶媒体を含む。また、ブロックは、予測ブロック、コーディングブロック、またはコーディングユニットをいう場合がある。

【0044】

Ｉ．ビデオ符号化のためのエンコーダおよびデコーダ

【0045】

図２は、本開示の一実施形態による通信システム（２００）の簡略化したブロック図を示す。通信システム（２００）は、例えば、ネットワーク（２５０）を介して、互いに通信可能な複数の端末装置を含む。例えば、通信システム（２００）は、ネットワーク（２５０）を介して相互に接続された第１の対の端末装置（２１０）および（２２０）を含む。図２の例において、第１の対の端末装置（２１０）および（２２０）は、データの一方向送信を実行する。例えば、端末装置（２１０）は、ネットワーク（２５０）を介して他の端末装置（２２０）に送信するためにビデオデータ（例えば、端末装置（２１０）によりキャプチャされたビデオ画像のストリーム）をコーディングしてもよい。エンコード化されたビデオデータは、１つまたは複数の符号化されたビデオビットストリームの形態で送信されてもよい。端末装置（２２０）は、ネットワーク（２５０）から符号化されたビデオデータを受信し、符号化されたビデオデータを復号してビデオ画像を復元し、復元されたビデオデータに従ってビデオ画像を表示してもよい。データの一方向伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。

【0046】

別の例において、通信システム（２００）は、例えばビデオ会議中に発生し得る符号化されたビデオデータの双方向伝送を行う第２の対の端末装置（２３０）および（２４０）を含む。一例において、端末装置（２３０）および（２４０）の各端末装置は、データの双方向伝送のために、ネットワーク（２５０）を介して端末装置（２３０）および（２４０）のうちの他方の端末装置に送信するためにビデオデータ（例えば、端末装置によってキャプチャされたビデオ画像のストリーム）をコーディングしてもよい。また、端末装置（２３０）および（２４０）の各端末装置は、端末装置（２３０）および（２４０）の他の端末装置から送信された符号化されたビデオデータを受信し、符号化されたビデオデータを復号してビデオ画像を復元し、復元されたビデオデータに従ってアクセス可能な表示装置にビデオ画像を表示してもよい。

【0047】

図２の例では、端末装置（２１０）、（２２０）、（２３０）および（２４０）は、サーバ、パーソナルコンピュータおよびスマートフォンとして例示されていてもよいが、本開示の原理はそのようには限定されなくてもよい。本開示の各実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤーおよび／または専用のビデオ会議装置に適用することができる。ネットワーク（２５０）は、例えば有線（ワイアード）および／または無線通信ネットワークを含む端末装置（２１０）、（２２０）、（２３０）、（２４０）間で、符号化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク（２５０）は、回路スイッチおよび／またはパケットスイッチ型チャネルでデータを交換してもよい。代表的なネットワークには、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットが含まれる。本記述内容の範囲において、ネットワーク（２５０）のアーキテクチャおよびトポロジーは、以下で説明されていない限り、本開示の動作に関して重要ではない場合がある。

【0048】

図３は、開示された主題の適用の一例として、ストリーミング環境におけるビデオエンコーダとビデオデコーダとの配置を示したものである。開示された主題は、例えば、ビデオ会議、デジタルテレビ、およびＣＤ、ＤＶＤ、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの保存などを含む、他のビデオ対応用途にも同様に適用することができる。

【0049】

ストリーミングシステムは、キャプチャサブシステム（３１３）を含んでもよく、これは、例えばデジタルカメラなどのビデオソース（３０１）を含むことができ、例えば圧縮されていないビデオ画像のストリーム（３０２）を作成することができる。一例において、ビデオ画像のストリーム（３０２）は、デジタルカメラで撮影されたサンプルを含む。ビデオ画像のストリーム（３０２）は、エンコードされたビデオデータ（３０４）（または符号化されたビデオビットストリーム）に比してデータ量が多いことを強調するために太線により示されているが、ビデオソース（３０１）に接続されたビデオエンコーダ（３０３）を含む電子デバイス（３２０）によって処理されてもよい。ビデオエンコーダ（３０３）は、以下でより詳細に説明するように、開示された主題の態様を可能にする、または実行するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含んでもよい。ビデオ画像のストリーム（３０２）に比しデータ量が少ないことを強調するために細線で示されているエンコードされたビデオデータ（３０４）（またはエンコードされたビデオビットストリーム（３０４））は、将来の使用のためにストリーミングサーバ（３０５）に保存されてもよい。図３のクライアントサブシステム（３０６）および（３０８）などの１つまたは複数のストリーミングクライアントサブシステムは、ストリーミングサーバ（３０５）にアクセスして、エンコードされたビデオデータ（３０４）のコピー（３０７）および（３０９）を取得することができる。クライアントサブシステム（３０６）は、例えば、電子デバイス（３３０）にビデオデコーダ（３１０）を含んでもよい。ビデオデコーダ（３１０）は、エンコードされたビデオデータの入力されるコピー（３０７）を復号し、ディスプレイ（３１２）（例えば、表示画面）または他のレンダリングデバイス（図示せず）上でレンダリングできるビデオ画像の発信ストリーム（３１１）を作成する一部のストリーミングシステムにおいて、エンコードされたビデオデータ（３０４）、（３０７）、および（３０９）（例えば、ビデオビットストリーム）は、特定のビデオ符号化／圧縮規格に従ってエンコードされてもよい。ＩＴＵ－Ｔ推奨Ｈ．２６５はそれらの規格の一例である。一例として、非公式には多用途ビデオ符号化（ＶＶＣ）として知られているビデオ符号化規格が開発されつつある。本開示の主題は、ＶＶＣの文脈で使用されてもよい。

【0050】

なお、電子デバイス（３２０）および（３３０）は、他の構成要素（図示せず）を含んでもよい。例えば、電子デバイス（３２０）は、ビデオデコーダ（図示せず）を含んでよく、同様に電子デバイス（３３０）は、ビデオエンコーダ（図示せず）を含んでもよい。

【0051】

図４は、本開示の一実施形態によるビデオデコーダ（４１０）のブロック図を示す。ビデオデコーダ（４１０）は、電子デバイス（４３０）に含まれてもよい。電子デバイス（４３０）は、受信機（４３１）（例えば、受信回路）を含んでもよい。ビデオデコーダ（４１０）は、図３の例のビデオデコーダ（３１０）の代わりに用いてもよい。

【0052】

受信機（４３１）は、ビデオデコーダ（４１０）によって復号される１つまたは複数の符号化されたビデオシーケンスを受信してもよく、同じまたは別の実施形態においては、各符号化されたビデオシーケンスの復号が他の符号化されたビデオシーケンスから独立している場合、一度に１つの符号化されたビデオシーケンスを受信してもよい。符号化されたビデオシーケンスは、チャネル（４０１）から受信されてもよく、このチャネルは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであってもよい。受信機（４３１）は、エンコードされたビデオデータを、他のデータ、例えば、符号化された音声データおよび／または補助的なデータストリームとともに受信してもよく、それらは、それぞれを利用するエンティティ（図示せず）に転送されてもよい。受信機（４３１）は、符号化されたビデオシーケンスを他のデータから分離してもよい。ネットワークジッターに対処するために、バッファメモリ（４１５）が、受信機（４３１）とエントロピーデコーダ／パーサ（４２０）（以下、「パーサ（４２０）」）との間に接続されてもよい。特定のアプリケーションにおいて、バッファメモリ（４１５）は、ビデオデコーダ（４１０）の一部である。別のアプリケーションにおいて、それはビデオデコーダ（４１０）の外部にあってもよい（図示せず）。さらに他のアプリケーションにおいて、例えばネットワークジッターに対処するために、ビデオデコーダ（４１０）の外部にバッファメモリ（図示せず）があってもよく、さらに、例えばプレイアウトのタイミングに対処するために、ビデオデコーダ（４１０）の内部に別のバッファメモリ（４１５）があってもよい。受信機（４３１）が、充分な帯域幅と制御性を有するストア／転送デバイスから、または等時性ネットワークからデータを受信している場合には、バッファメモリ（４１５）は必要がないか、あるいは小さくてもよい。インターネットのようなベストエフォート型のパケットネットワークにおいて使用する場合、バッファメモリ（４１５）が必要とされることがあり、比較的大型であってもよく、適応的なサイズであれば有利であり、また、少なくとも部分的に、ビデオデコーダ（４１０）の外部のオペレーティングシステムまたは同様の要素（図示せず）において実行されてもよい。

【0053】

ビデオデコーダ（４１０）は、符号化されたビデオシーケンスからシンボル（４２１）を再構築するためにパーサ（４２０）を含んでもよい。それらのシンボルのカテゴリーには、ビデオデコーダ（４１０）の演算を管理するために使用される情報、および、場合によっては、図４に示すように、電子デバイス（４３０）の不可欠な部分ではないが、電子デバイス（４３０）に接続されてもよいレンダリングデバイス（４１２）（例えば、表示画面）などのレンダリングデバイスを制御するための情報が含まれる。レンダリングデバイスのための制御情報は、補足強化情報（ＳＥＩメッセージ）またはビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（図示せず）の形態であってもよい。パーサ（４２０）は、受信した符号化されたビデオシーケンスを構文解析／エントロピー復号してもよい。符号化されたビデオシーケンスのコーディングは、ビデオ符号化技術または規格に準拠していてもよく、可変長コーディング、ハフマンコーディング、文脈感度を伴う、または伴わない算術コーディングなどを含む様々な原理に則ってもよい。パーサ（４２０）は、符号化されたビデオシーケンスから、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダ内の画素のサブグループの少なくとも１つに対する一組のサブグループパラメータを抽出してもよい。サブグループは、画像群（ＧＯＰｓ）、画像、タイル、スライス、マクロブロック、コーディングユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）などを含んでもよい。また、パーサ（４２０）は、変換係数、量子化器パラメータ値、動きベクトルなどの情報を、符号化されたビデオシーケンスから抽出してもよい。

【0054】

パーサ（４２０）は、バッファメモリ（４１５）から受信したビデオシーケンスに対して、エントロピー復号／構文解析演算を実行し、シンボル（４２１）を作成してもよい。

【0055】

シンボル（４２１）の再構築には、符号化されたビデオ画像またはその一部のタイプ（例えば、インターおよびイントラ画像、インターおよびイントラブロック）などの要素に従って、複数の異なるユニットが関与してもよい。いずれのユニットが、どのように関与するかは、パーサ（４２０）によって符号化されたビデオシーケンスから構文解析されたサブグループ制御情報によって制御されてもよい。パーサ（４２０）と以下の複数のユニットとの間のこのようなサブグループ制御情報の流れは、煩雑さを避けるため、描かれていない。

【0056】

ビデオデコーダ（４１０）は、既に述べた機能ブロック以外にも、以下に説明するように概念的に複数の機能ユニットに分割されてもよい。商業的な制約の下で動作する実用的な実施において、これらのユニットの多くは互いに密接に作用し、少なくとも部分的に相互に組み込まれてもよい。しかしながら、開示された主題を説明するためには、以下の機能ユニットに概念的に分割することが適切である。

【0057】

第１のユニットは、スケーラ／逆変換ユニット（４５１）である。スケーラ／逆変換ユニット（４５１）は、量子化された変換係数に加えて、いずれの変換を使用するか、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどの制御情報を、シンボル（４２１）としてパーサ（４２０）から受信する。スケーラ／逆変換ユニット（４５１）は、アグリゲータ（４５５）に入力され得るサンプル値を含むブロックを出力してもよい。

【0058】

スケーラ／逆変換部（４５１）の出力サンプルは、イントラ符号化されたブロック、すなわち、以前に再構築された画像からの予測情報を使用していないが、現在の画像に先行して再構築された部分からの予測情報を使用し得るブロックに関連している場合がある。このような予測情報は、イントラ画像予測ユニット（４５２）によって提供されてもよい。イントラ画像予測ユニット（４５２）が、現在の画像バッファ（４５８）からフェッチされた、既に再構築された周囲の情報を使用して、再構築中のブロックと同じサイズおよび形状のブロックを生成する場合がある。現在の画像バッファ（４５８）は、例えば、部分的に再構築された現在の画像および／または完全に再構築された現在の画像をバッファリングする。アグリゲータ（４５５）は、場合によっては、イントラ予測ユニット（４５２）が生成した予測情報を、サンプルごとに、スケーラ／逆変換ユニット（４５１）が提供する出力サンプル情報に追加する。

【0059】

また、スケーラ／逆変換ユニット（４５１）の出力サンプルが、インター符号化された、また場合によっては動き補償されたブロックに関連する場合もある。このような場合、動き補償予測ユニット（４５３）は、参照画像メモリ（４５７）にアクセスして、予測に使用されるサンプルをフェッチしてもよい。ブロックに関連するシンボル（４２１）に従ってフェッチされたサンプルを動き補償した後、これらのサンプルは、アグリゲータ（４５５）によって、スケーラ／逆変換ユニット（４５１）の出力（この場合、残余サンプルまたは残余信号と呼ぶ）に追加され、出力サンプル情報を生成してもよい。動き補償予測ユニット（４５３）が予測サンプルをフェッチする参照画像メモリ（４５７）内のアドレスは、例えばＸ、Ｙ、および参照画像成分を有し得るシンボル（４２１）の形態で動き補償予測ユニット（４５３）に利用可能な動きベクトルによって制御されてもよい。また動き補償は、サブサンプルまで精度が保証された動きベクトルが使用されているとき、参照画像メモリ（４５７）からフェッチされたサンプル値の補間、および動きベクトル予測メカニズムなどを含んでもよい。

【0060】

アグリゲータ（４５５）の出力サンプルは、ループフィルタユニット（４５６）において、様々なループフィルタリング技術にかけられてもよい。ビデオ圧縮技術は、符号化されたビデオシーケンス（符号化されたビデオビットストリームとも呼ぶ）に含まれるパラメータによって制御され、パーサ（４２０）からシンボル（４２１）としてループフィルタユニット（４５６）が利用することのできるループ内フィルタ技術を含んでもよいが、符号化された画像または符号化されたビデオシーケンスの（復号順において）先行する部分の復号時に得られるメタ情報に応答してもよく、また、先行して再構築され、ループフィルタリングされたサンプル値に応答してもよい。

【0061】

ループフィルタユニット（４５６）の出力は、レンダリングデバイス（４１２）に出力されてもよく、また将来のインター画像予測に使用するために参照画像メモリ（４５７）に保存され得るサンプルストリームであってもよい。

【0062】

特定の符号化された画像は、一度完全に再構築されると、将来の予測のための参照画像として使用されてもよい。例えば、現在の画像に対応する符号化された画像が完全に再構築され、その符号化された画像が（例えばパーサ（４２０）によって）参照画像として識別されると、現在の画像バッファ（４５８）は参照画像メモリ（４５７）の一部となってもよく、次の符号化された画像の再構築を開始する前に、新たな現在の画像バッファが再割り当てされてもよい。

【0063】

ビデオデコーダ（４１０）は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの規格における所定のビデオ圧縮技術に従って復号動作を実行してもよい。
符号化されたビデオシーケンスは、符号化されたビデオシーケンスが、ビデオ圧縮技術または規格のシンタックスと、ビデオ圧縮技術または規格で文書化されたプロファイルとの両方を厳守するという意味で、使用されているビデオ圧縮技術または規格により指定されたシンタックスに準拠してもよい。具体的には、プロファイルは、ビデオ圧縮技術または規格で利用可能なすべてのツールの中から、特定のツールをそのプロファイルで利用可能な唯一のツールとして選択してもよい。また、規格に準拠するためには、符号化されたビデオシーケンスの計算量が、ビデオ圧縮技術または規格のレベルによって定義された範囲内であることが要求される。レベルにより、最大画像サイズ、最大フレームレート、最大再構築サンプルレート（例えば、メガサンプル／秒として測定）、最大参照画像サイズなどが制限される場合がある。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（ＨＲＤ）仕様および符号化されたシーケンスで伝達されたＨＲＤバッファ管理のためのメタデータによりさらに制限されることがある。

【0064】

一実施形態において、受信機（４３１）は、エンコードされたビデオを有する追加の（冗長な）データを受信してもよい。この追加データは、符号化されたビデオシーケンスの一部として含まれてもよい。この追加データは、データを適切に復号するため、および／または元のビデオデータをより正確に再構築するために、ビデオデコーダ（４１０）によって使用されてもよい。追加データは、例えば、時間的、空間的、または信号雑音比（ＳＮＲ）強化層、冗長スライス、冗長画像、順方向誤り訂正コードなどの形態であってもよい。

【0065】

図５は、本開示の一実施形態によるビデオエンコーダ（５０３）のブロック図である。ビデオエンコーダ（５０３）は、電子デバイス（５２０）に含まれる。電子デバイス（５２０）は、送信機（５４０）（例えば、送信回路）を含む。ビデオエンコーダ（５０３）は、図３の例のビデオエンコーダ（３０３）の代わりに使用されてもよい。

【0066】

ビデオエンコーダ（５０３）は、ビデオエンコーダ（５０３）によって符号化されるビデオ画像をキャプチャすることができるビデオソース（５０１）（図５の例において電子デバイス（５２０）の一部ではない）からビデオサンプルを受信してもよい。別の例において、ビデオソース（５０１）は、電子デバイス（５２０）の一部である。

【0067】

ビデオソース（５０１）は、ビデオエンコーダ（５０３）によって符号化されるソースビデオシーケンスを、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット、など）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、など）、および任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）を有し得るデジタルビデオサンプルストリームの形態で提供してもよい。メディアサービングシステムにおいて、ビデオソース（５０１）は、以前に作成されたビデオを保存する記憶装置であってもよい。ビデオ会議システムにおいて、ビデオソース（５０１）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであってもよい。ビデオデータは、連続して見たとき、動きを付与する複数の個々の画像として提供されてもよい。画像自体は、画素の空間アレイとして編成されてもよく、各画素は、使用時のサンプリング構造、色空間などに依存して、１つまたは複数のサンプルを含んでもよい。当業者であれば、画素とサンプルとの関係を容易に理解することができる。以下の記述において、サンプルを中心に説明する。

【0068】

一実施形態によれば、ビデオエンコーダ（５０３）は、ソースビデオシーケンスの画像を符号化し、リアルタイムで、またはアプリケーションが要求する他の時間制約の下で、符号化されたビデオシーケンス（５４３）に圧縮してもよい。適切なコーディング速度を課することは、コントローラ（５５０）の１つの機能である。一部の実施形態において、コントローラ（５５０）は、以下に述べるとおり他の機能ユニットを制御し、他の機能ユニットに機能的に接続されている。この接続は、煩雑さを避けるために、描かれていない。コントローラ（５５０）によって設定されるパラメータは、レート制御関連パラメータ（画像スキップ、量子化器、レート歪み最適化技術のラムダ値、など）、画像サイズ、画像群（ＧＯＰ）レイアウト、最大動きベクトル許容参照領域などを含んでもよい。コントローラ（５５０）は、あるシステム設計に最適化されたビデオエンコーダ（５０３）に関連する他の適切な機能を有するように構成されてもよい。

【0069】

一部の実施形態において、ビデオエンコーダ（５０３）は、コーディングループで動作するように構成されている。極端に簡略化して述べれば、一例として、コーディングループは、ソースコーダ（５３０）（例えば、符号化される入力画像と参照画像とに基づいて、シンボルストリームなどのシンボルを作成する機能を果たす）と、ビデオエンコーダ（５０３）に組み込まれた（ローカル）デコーダ（５３３）とを含んでもよい。デコーダ（５３３）は、（リモート）デコーダが作成するのと同様の方法で、サンプルデータを作成するためにシンボルを再構築する（これは、開示された主題で扱われているビデオ圧縮技術においては、シンボルと符号化されたビデオビットストリームとの間のいかなる圧縮も、可逆的であるためである）。再構築されたサンプルストリーム（サンプルデータ）は、参照画像メモリ（５３４）に入力される。シンボルストリームの復号は、デコーダの位置（ローカルまたはリモート）に依存しないビットパーフェクトな結果をもたらすため、参照画像メモリ（５３４）内のコンテンツも、ローカルエンコーダとリモートエンコーダとの間でビットパーフェクトである。換言すれば、エンコーダの予測部分は、デコーダが復号時に予測を用いるときに「見る」のと全く同一のサンプル値を、参照画像サンプルとして「見る」。この参照画像の同期性（および、例えばチャンネルエラーなどで同期性が維持できない場合は、結果的に発生するドリフト）の基本原理は、一部の関連技術においても用いられる。

【0070】

「ローカル」デコーダ（５３３）の演算は、図４を参照して既に詳細に述べたビデオデコーダ（４１０）などの「リモート」デコーダの演算と同じであり得る。しかしながら、ここで図４も簡単に参照しつつ説明すると、シンボルが利用可能であり、エントロピーコーダ（５４５）およびパーサ（４２０）による、符号化されたビデオシーケンスへのシンボルのエンコーディング／復号は可逆的であり得るため、バッファメモリ（４１５）およびパーサ（４２０）を含むビデオデコーダ（４１０）のエントロピーデコーダ部分は、ローカルデコーダ（５３３）において完全には実行されなくてもよい。

【0071】

この時点で言えることは、デコーダに存在する構文解析／エントロピー復号を除く任意のデコーダ技術は、必然的に、対応するエンコーダにおいても、実質的に同一の機能形態で存在するということである。このため、開示された主題は、デコーダの演算に焦点を当てている。デコーダ技術の説明は、包括的に説明されるエンコーダ技術の逆であるため、簡略化することができる。特定の領域においてのみ、より詳細な説明が必要であり、それに関して以下に述べる。

【0072】

動作時、一部の例において、ソースコーダ（５３０）は、「参照画像」として指定されたビデオシーケンスから、以前に符号化された１つ以上の画像を参照して入力画像を予測的に符号化する、動き補償された予測コーディングを実行してもよい。このようにして、コーディングエンジン（５３２）は、入力画像の画素ブロックと、入力画像に対する予測参照として選択され得る参照画像の画素ブロックとの間の差分を符号化する。

【0073】

ローカルビデオデコーダ（５３３）は、ソースコーダ（５３０）によって作成されたシンボルに基づいて、参照画像として指定され得る画像の符号化されたビデオデータを復号してもよい。コーディングエンジン（５３２）の演算は、非可逆処理であることが有利である。符号化されたビデオデータがビデオデコーダ（図５には示されていない）で復号されてもよい場合、再構築されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ（５３３）は、ビデオデコーダにより参照画像に対して実行され得る復号処理を複製し、再構築された参照画像を参照画像キャッシュ（５３４）に保存させてもよい。このようにして、ビデオエンコーダ（５０３）は、（伝送エラーがないという条件で）遠端のビデオデコーダによって取得される再構築された参照画像と共通の内容を有する再構築された参照画像のコピーをローカルに保存してもよい。

【0074】

予測器（５３５）は、コーディングエンジン（５３２）のために予測検索を行ってもよい。すなわち、新規の画像を符号化するため、予測器（５３５）は、新規の画像のための適切な予測参照として機能することができるサンプルデータ（候補参照画素ブロックとして）、または参照画像動きベクトル、ブロック形状などの特定のメタデータを参照画像メモリ（５３４）内で検索してもよい。予測器（５３５）は、適切な予測参照を求めるために、サンプルブロック、画素ブロック単位で動作してもよい。場合によっては、予測器（５３５）によって得られた検索結果によって決定されることであるが、入力画像は、参照画像メモリ（５３４）に保存された複数の参照画像から予測参照を引き出させてもよい。

【0075】

コントローラ（５５０）は、例えば、ビデオデータをエンコードするのに用いられるパラメータおよびサブグループパラメータの設定などを含む、ソースコーダ（５３０）のコーディング演算を管理してもよい。

【0076】

前述のすべての機能ユニットの出力には、エントロピーコーダ（５４５）においてエントロピーコーディングを施してもよい。エントロピーコーダ（５４５）は、ハフマンコーディング、可変長コーディング、算術コーディングなどの技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットによって生成されたシンボルを符号化されたビデオシーケンスに変換する。

【0077】

送信機（５４０）は、エントロピーコーダ（５４５）によって作成されたような符号化されたビデオシーケンスをバッファリングして、エンコードされたビデオデータを保存することになる記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル（５６０）を介した送信の準備をしてもよい。送信機（５４０）は、ビデオエンコーダ（５０３）からの符号化されたビデオデータを、例えば、符号化された音声データおよび／または補助データストリーム（ソースは図示せず）などの、送信される他のデータと統合してもよい。

【0078】

コントローラ（５５０）は、ビデオエンコーダ（５０３）の演算を管理してもよい。コーディング時、コントローラ（５５０）は、各符号化された画像に、それぞれの画像に適用され得るコーディング技術に影響を与える可能性がある特定の符号化された画像タイプを割り当ててもよい。例えば、画像は以下の画像タイプの１つとして割り当てられてもよいことが多い。

【0079】

その１つがイントラ画像（Ｉ画像）であり、これはシーケンスにおける他の画像を予測源として使用せずに符号化および復号することができる。ビデオコーデックによっては、例えば独立デコーダリフレッシュ（「ＩＤＲ」）画像を含む、異なるタイプのイントラ画像に対応できるものもある。当業者には、それらのＩ画像の変種ならびにそれぞれの用途および特徴は知られている。

【0080】

予測画像（Ｐ画像）は、各ブロックのサンプル値を予測するために、最大１つの動きベクトルおよび参照インデックスを使用し、イントラ予測またはインター予測を用いて符号化および復号され得るものであってもよい。

【0081】

双方向予測画像（Ｂ画像）は、各ブロックのサンプル値を予測するために、最大２つの動きベクトルおよび参照インデックスを使用し、イントラ予測またはインター予測を用いて符号化および復号され得るものであってもよい。同様に、マルチ予測画像は、単一のブロックの再構築に３つ以上の参照画像および関連するメタデータを用いることができる。

【0082】

ソース画像は一般に、空間的に複数のサンプルブロック（例えば、それぞれ４×４、８×８、４×８、または１６×１６のサンプルのブロック）に分割され、ブロックごとに符号化されてもよい。ブロックは、ブロックのそれぞれの画像に適用されるコーディング割り当てによって決定される、他の（すでに符号化された）ブロックを参照して予測的に符号化されてもよい。例えば、Ｉ画像のブロックは、非予測的に符号化されてもよいし、同じ画像の既に符号化されたブロックを参照して予測的に符号化されてもよい（空間予測またはイントラ予測）。Ｐ画像の画素ブロックは、以前に符号化された１つの参照画像を参照して、空間的予測または時間的予測によって予測的に符号化されてもよい。Ｂ画像のブロックは、以前に符号化された１つまたは２つの参照画像を参照して、空間的予測または時間的予測によって予測的に符号化されてもよい。

【0083】

ビデオデエンコーダ（５０３）は、所定のビデオ符号化技術またはＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの規格に従ってコーディング演算を実行してもよい。その演算において、ビデオエンコーダ（５０３）は、入力ビデオシーケンスの時間的および空間的な冗長性を利用する予測コーディング演算を含む様々な圧縮演算を行ってもよい。したがって、符号化されたビデオデータは、使用されているビデオ符号化技術または規格によって指定されたシンタックスに準拠してもよい。

【0084】

一実施形態において、送信機（５４０）は、エンコードされたビデオを有する追加のデータを送信してもよい。ソースコーダ（５３０）は、そのようなデータを、符号化されたビデオシーケンスの一部として含んでもよい。追加データは、時間／空間／ＳＮＲ強化層、冗長画像やスライスなどの他の形態の冗長データ、ＳＥＩメッセージ、ＶＵＩパラメータセットフラグメントなどを含んでもよい。

【0085】

ビデオは、時間的に連続した複数のソース画像（ビデオ画像）としてキャプチャされてもよい。イントラ画像予測（イントラ予測と略されることが多い）は、所与の画像の空間的な相関関係を利用し、インター画像予測は画像間の（時間的またはその他の）相関関係を利用する。一例として、現在の画像と呼ぶエンコーディング／復号中の特定の画像は、ブロックに分割されている。現在の画像内のブロックが、ビデオの、以前に符号化され、まだバッファリングされている参照画像内の参照ブロックに類似する場合、現在の画像内のブロックは、動きベクトルと呼ばれるベクトルによって符号化することができる。動きベクトルは、参照画像内の参照ブロックを指し、複数の参照画像が使用されている場合は、参照画像を識別する第３の次元を有してもよい。

【0086】

一部の実施形態において、インター画像予測に双予測技術を用いてもよい。双予測技術によれば、ビデオ内の現在の画像に復号の順序において先行する（ただし、表示順ではそれぞれ過去と未来にあってもよい）第１の参照画像および第２の参照画像などの２つの参照画像が用いられる。現在の画像内のブロックは、第１の参照画像内の第１の参照ブロックを指す第１の動きベクトルと、第２の参照画像内の第２の参照ブロックを指す第２の動きベクトルとによって符号化されてもよい。ブロックは、第１の参照ブロックと第２の参照ブロックとの組み合わせによって予測されてもよい。

【0087】

さらに、コーディングの効率を向上させるために、インター画像予測においてマージモード技術を用いてもよい。

【0088】

本開示の一部の実施形態によれば、インター画像予測およびイントラ画像予測などの予測は、ブロック単位で実行される。例えば、ＨＥＶＣ規格によれば、一連のビデオ画像内の１つの画像は、圧縮のためにコーディングツリーユニット（ＣＴＵ）に分割され、一画像内のＣＴＵは、６４×６４画素、３２×３２画素、または１６×１６画素などの同じサイズを有する。一般に、１つのＣＴＵは、１つのルーマＣＴＢおよび２つのクロマＣＴＢである３つのコーディングツリーブロック（ＣＴＢ）を含む。各ＣＴＵは、再帰的に１つまたは複数のコーディングユニット（ＣＵ）にクワッドツリー分割することができる。例えば、６４×６４画素のＣＴＵは、６４×６４画素の１つのＣＵ、または３２×３２画素の４つのＣＵ、または１６×１６画素の１６個のＣＵに分割することができる。一例において、各ＣＵが分析され、インター予測タイプやイントラ予測タイプなど、ＣＵの予測タイプが決定される。ＣＵは、時間的および／または空間的な予測可能性に従って、１つまたは複数の予測ユニット（ＰＵ）に分割される。一般に、各ＰＵは、１つのルーマ予測ブロック（ＰＢ）と、２つのクロマＰＢとを含む。一実施形態において、コーディング（エンコーディング／復号）における予測演算は、予測ブロックの単位で実行される。予測ブロックの一例として、ルーマ予測ブロックを用いると、予測ブロックは、８×８画素、１６×１６画素、８×１６画素、１６×８画素などの、画素に対する値（例えば、ルーマ値）のマトリクスを含む。

【0089】

図６は、本開示の別の実施形態によるビデオエンコーダ（６０３）を示す図である。ビデオエンコーダ（６０３）は、ビデオ画像のシーケンスにおける現在のビデオ画像内のサンプル値の処理ブロック（例えば、予測ブロック）を受信し、処理ブロックを、符号化されたビデオシーケンスの一部である符号化された画像へとエンコードするように構成されている。一例として、ビデオエンコーダ（６０３）は、図３の例のビデオエンコーダ（３０３）の代わりに使用されている。

【0090】

ＨＥＶＣの例において、ビデオエンコーダ（６０３）は、８×８サンプルの予測ブロックなどの処理ブロックに対するサンプル値のマトリクスを受信する。ビデオエンコーダ（６０３）は、処理ブロックがイントラモード、インターモード、または双予測モードを用いて最適に符号化されているか否かを、例えばレート歪み最適化処理を用いて判断する。処理ブロックがイントラモードで符号化される場合、ビデオエンコーダ（６０３）は、イントラ予測技術を用いて処理ブロックを符号化された画像にエンコードしてもよく、処理ブロックがインターモードまたは双予測モードで符号化される場合、ビデオエンコーダ（６０３）は、それぞれ、インター予測または双予測技術を用いて、処理ブロックを符号化された画像にエンコードしてもよい。特定のビデオ符号化技術において、マージモードは、動きベクトルが、予測器の範囲外にある符号化された動きベクトル成分の恩恵を受けずに、１つまたは複数の動きベクトル予測変数から導出されるインター画像予測サブモードであってもよい。他の特定のビデオ符号化技術においては、当該ブロックに適用可能な動きベクトル成分が存在してもよい。一例において、ビデオエンコーダ（６０３）は、処理ブロックのモードを決定するモード決定モジュール（図示せず）などの他の構成要素を含む。

【0091】

図６の例において、ビデオエンコーダ（６０３）は、図６に示すように接続されたインターエンコーダ（６３０）、イントラエンコーダ（６２２）、残余計算機（６２３）、スイッチ（６２６）、残余エンコーダ（６２４）、統括コントローラ（６２１）、およびエントロピーエンコーダ（６２５）を含む。

【0092】

インターエンコーダ（６３０）は、現在のブロック（例えば、処理ブロック）のサンプルを受信し、ブロックを参照画像内の１つまたは複数の参照ブロック（例えば、先行する画像および後続の画像内のブロック）と比較し、インター予測情報（例えば、インターエンコーディング技術による冗長情報の記述、動きベクトル、マージモード情報）を生成し、任意の適切な技術を用いて、インター予測情報に基づきインター予測結果（例えば、予測ブロック）を計算するように構成されている。一部の例において、参照画像は、エンコードされたビデオ情報に基づいて復号される復号された参照画像である。

【0093】

イントラエンコーダ（６２２）は、現在のブロック（例えば、処理ブロック）のサンプルを受信し、場合によってはブロックを同じ画像において既に符号化されたブロックと比較し、変換後の量子化係数を生成し、場合によってはイントラ予測情報（例えば、１つまたは複数のイントラエンコーディング技術によるイントラ予測方向情報）も生成するように構成されている。一例において、イントラエンコーダ（６２２）は、イントラ予測情報と同一画像内の参照ブロックとに基づいて、イントラ予測結果（例えば、予測ブロック）も計算する。

【0094】

統括コントローラ（６２１）は、統括制御データを決定し、統括制御データに基づいてビデオエンコーダ（６０３）の他の構成要素を制御するように構成されている。一例において、統括コントローラ（６２１）は、ブロックのモードを決定し、当該モードに基づいてスイッチ（６２６）に制御信号を提供する。例えば、モードがイントラモードである場合、統括コントローラ（６２１）は、スイッチ（６２６）を制御して、残余計算機（６２３）が使用するイントラモードの結果を選択し、エントロピーエンコーダ（６２５）を制御して、イントラ予測情報を選択し、かつビットストリームにイントラ予測情報を含め、モードがインターモードである場合、統括コントローラ（６２１）は、スイッチ（６２６）を制御して、残余計算機（６２３）が使用するインター予測結果を選択し、エントロピーエンコーダ（６２５）を制御して、インター予測情報を選択し、ビットストリームにインター予測情報を含める。

【0095】

残余計算機（６２３）は、受信したブロックと、イントラエンコーダ（６２２）またはインターエンコーダ（６３０）から選択された予測結果との間の差分（残余データ）を計算するように構成されている。残余エンコーダ（６２４）は、残余データに基づいて演算を実行し、残余データをエンコードして変換係数を生成するように構成されている。一例において、残余エンコーダ（６２４）は、残余データを空間領域から周波数領域に変換して、変換係数を生成するように構成されている。次に、変換係数が量子化処理を受けて、量子化された変換係数が得られる。また、様々な実施形態において、ビデオエンコーダ（６０３）は、残余デコーダ（６２８）を含む。残余デコーダ（６２８）は、逆変換を行い、復号された残余データを生成するように構成されている。復号された残余データは、イントラエンコーダ（６２２）およびインターエンコーダ（６３０）で好適に使用されてもよい。例えば、インターエンコーダ（６３０）は、復号された残余データおよびインター予測情報に基づいて復号されたブロックを生成し、イントラエンコーダ（６２２）は、復号された残余データおよびイントラ予測情報に基づいて復号されたブロックを生成することができる。復号されたブロックは好適に処理されて復号された画像を生成し、復号された画像はメモリ回路（図示せず）にバッファリングされ、一部の例において参照画像として用いられてもよい。

【0096】

エントロピーエンコーダ（６２５）は、エンコードされたブロックを含むようにビットストリームをフォーマットするように構成されている。エントロピーエンコーダ（６２５）は、ＨＥＶＣ規格などの適切な規格に従って、様々な情報を含むように構成されている。一例において、エントロピーエンコーダ（６２５）は、統括制御データ、選択された予測情報（例えば、イントラ予測情報またはインター予測情報）、残余情報、およびその他の適切な情報をビットストリームに含むように構成されている。なお、開示された主題によれば、インターモードまたは双予測モードのいずれかのマージサブモードでブロックを符号化する場合、残余情報は存在しない。

【0097】

図７は、本開示の別の実施形態によるビデオデコーダ（７１０）を示す図である。ビデオデコーダ（７１０）は、符号化されたビデオシーケンスの一部である符号化された画像を受信し、符号化された画像を復号して再構築画像を生成するように構成されている。一例として、ビデオデコーダ（７１０）は、図３の例のビデオデコーダ（３１０）の代わりに使用されている。

【0098】

図７の例において、ビデオデコーダ（７１０）は、図７に示すように接続された、エントロピーデコーダ（７７１）、インターデコーダ（７８０）、残余デコーダ（７７３）、再構築モジュール（７７４）、およびイントラデコーダ（７７２）を含む。

【0099】

エントロピーデコーダ（７７１）は、符号化された画像から、符号化された画像を構成するシンタックス要素を表す特定のシンボルを再構築するように構成されてもよい。そのようなシンボルは、例えば、ブロックが符号化されるモード（例えば、イントラモード、インターモード、双予測モード、およびマージサブモードまたは別のサブモードにおける後者２つ）、特定のサンプルを識別することができる予測情報（例えば、イントラ予測情報またはインター予測情報など）またはそれぞれイントラデコーダ（７７２）またはインターデコーダ（７８０）によって予測に使用されるメタデータ、例えば量子化された変換係数などの形態の残余情報、などを含むことができる。一例として、予測モードがインター予測モードまたは双予測モードである場合、インター予測情報がインターデコーダ（７８０）に提供され、予測タイプがイントラ予測タイプである場合、イントラ予測情報はイントラデコーダ（７７２）に提供される。残余情報は、逆量子化処理を受けてもよく、残余デコーダ（７７３）に提供される。

【0100】

インターデコーダ（７８０）は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成されている。

【0101】

イントラデコーダ（７７２）は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成されている。

【0102】

残余デコーダ（７７３）は、逆量子化を実行して、非量子化された変換係数を抽出し、非量子化された変換係数を処理して、周波数領域から空間領域に残余を変換するように構成される。また、残余デコーダ（７７３）は、特定の制御情報（量子化器パラメータ（ＱＰ）を含むように）を必要としてもよく、その情報は、エントロピーデコーダ（７７１）によって提供されてもよい（データパスは、これが低容量の制御情報のみである可能性があるため、描かれていない）。

【0103】

再構築モジュール（７７４）は、空間領域において、残余デコーダ（７７３）によって出力された残余と、予測結果（場合により、インターまたはイントラ予測モジュールによって出力されたもの）とを組み合わせて、再構築ブロックを形成するように構成されており、このブロックは、再構築画像の一部であってもよく、この再構築画像は再構築ビデオの一部であってもよい。なお、視覚的品質を向上させるために、デブロッキング演算などの他の適切な演算を実行してもよい。

【0104】

なお、ビデオエンコーダ（３０３）、（５０３）、（６０３）、およびビデオデコーダ（３１０）、（４１０）、（７１０）は、任意の適切な技術を用いて動作させることができる。一実施形態において、ビデオエンコーダ（３０３）、（５０３）、（６０３）、およびビデオデコーダ（３１０）、（４１０）、（７１０）は、１つまたは複数の集積回路を用いて動作させることができる。別の実施形態において、ビデオエンコーダ（３０３）、（５０３）、（６０３）、およびビデオデコーダ（３１０）、（４１０）、（７１０）は、ソフトウェア命令を実行する１つまたは複数のプロセッサを用いて動作させることができる。

【0105】

ＩＩ．ＨＥＶＣブロック分割構造

【0106】

ＨＥＶＣにおいて、様々なローカル特性に適合するため、ＣＴＵはコーディングツリーと呼ばれる四分木構造を用いてＣＵに区分される。インター画像（時間）予測またはイントラ画像（空間）予測のいずれにより画像領域を符号化するかは、ＣＵレベルで決定される。各ＣＵは、ＰＵ区分のタイプに従って、さらに１つ、２つ、または４つのＰＵに区分される。１つのＰＵ内では、同じ予測プロセスが適用され、関連する情報がＰＵベースでデコーダに送信される。ＰＵの区分タイプに基づいて予測プロセスを適用することによって、残余ブロックを得た後、ＣＵは、ＣＵのコーディングツリーのような別のＱＴ構造に従ってＴＵに分割されてもよい。

【0107】

ＨＥＶＣ構造の１つの重要な特徴は、ＣＵ、ＰＵ、ＴＵを含む多重分割の概念を有するということである。ＨＥＶＣにおいて、ＣＵやＴＵの形状は正方形のみであり、ＰＵはインター予測ブロックに関しては正方形または長方形の形状を有してもよい。提案されたイントラ予測および変換のための矩形状のＰＵは、拡張してＪｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅｌ（ＪＥＭ）に用いてもよい。

【0108】

ＨＥＶＣでは、画像の境界において、サイズが画像の境界に適合するまで四分木区分を続けるように、四分木区分が暗黙のうちに要求されている。

【0109】

ＩＩＩ．ＱＴＢＴを用いたブロック分割構造

【0110】

ＶＶＣ試験モデル（ＶＴＭ）において、四分木（ＱＴ）プラス二分木（ＢＴ）プラス三分木（ＴＴ）分割構造が適用される。四分木プラス二分木ツリー（ＱＴＢＴ）構造は、多重分割タイプの概念を取り除くものであり、すなわち ＣＵ、ＰＵ、ＴＵ の概念の分離を取り除き、ＣＵ 分割形状により柔軟にサポートする。

【0111】

ＱＴＴＢ構造において、ＣＵは正方形または矩形のいずれかの形状を有してもよい。図８Ａおよび８Ｂに示すように、ＣＴＵはまずＱＴ構造により分割される。ＱＴのリーフノードは、ＢＴ構造によってさらに分割される。ＢＴ区分には、対称的な水平区分と対称的な垂直区分の２つの区分タイプがある。ＢＴのリーフノードはＣＵであり、２つのＣＵ間のセグメント化は、さらに分割することなく、予測と変換処理に使用される。従って、ＱＴＢＴ構造において、ＣＵ、ＰＵ、ＴＵは同じブロックサイズを有してもよい。

【0112】

ＪＥＭにおいて、１つのＣＵは異なる色成分のＣＢを含んでもよく、例えば、４：２：０クロマフォーマットのＰおよびＢスライスの場合、１つのＣＵは１つのルーマＣＢと２つのクロマＣＢとを含んでもよい。あるいは、１つのＣＵは、単一成分のＣＢを含んでもよく、例えば、Ｉスライスの場合、１つのＣＵは、１つのルーマＣＢのみ、または２つのクロマＣＢのみを含むことができる。

【0113】

ＱＴＢＴ分割構成には、以下のパラメータが定義されている。
－ＣＴＵＳｉｚｅ：例えばＨＥＶＣにおける、ＱＴのルートノードサイズ
－ＭｉｎＱＴＳｉｚｅ：許容されるＱＴリーフノードサイズ最小値
－ＭａｘＢＴＳｉｚｅ：許容されるＢＴルートノードサイズ最大値
－ＭａｘＢＴＤｅｐｔｈ：許容されるＢＴ深さ最大値
－ＭｉｎＢＴＳｉｚｅ：許容されるＢＴリーフノードサイズ最小値

【0114】

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

【0115】

図８Ａは、ＱＴＢＴ分割構造（８２００）を用いたブロック分割（８１００）の一例を示し、図８Ｂは、対応するＱＴＢＴ構造（８２００）を示す。実線はＱＴ区分を示し、点線は二分木ＢＴ区分を示す。各非リーフＢＴ区分ノードにおいて、区分タイプ（すなわち、対称水平区分または対称垂直区分）を示すフラグが信号伝達される。例えば、図８Ｂの例において、「０」は対称水平区分を示し、「１」は対称垂直区分を示す。ただし、ＱＴ区分の場合、ＱＴ区分が、非リーフノードを水平方向および垂直方向に区分して同じサイズの、より小さい４つのブロックを生成することから、区分タイプフラグは表示されず、信号伝達もされない。

【0116】

図８Ｂを参照すると、ＱＴＢＴ構造（８２００）において、まずルートノード（８２０１）がＱＴ構造によってＱＴノード（８２１１）～（８２１４）に分割される。したがって、図８Ａに示すように、コーディングツリーブロック（８１０１）は、実線によって、サイズの等しい４つのブロック（８１１１）～（８１１４）に分割される。

【0117】

図８Ｂに戻ると、ＱＴノード（８２１１）および（８２１２）は、それぞれ、２つのＢＴ区分によりさらに区分される。上述したように、ＢＴ区分は、２つの区分タイプ、すなわち、対称水平区分と対称垂直区分とを含む。非リーフＱＴノード（８２１１）は、「１」と表示されているので、対称垂直区分を用いて、２つのノード（８２２１）および（８２２２）に区分されてもよい。非リーフＱＴノード（８２１２）は、「０」と表示されているので、対称水平方向の区分を用いて、２つのノード（８２２３）および（８２２４）に区分されてもよい。非リーフＱＴノード（８２１３）は、別のＱＴＢＴ構造によって４つのノード（８２２５）～（８２２８）にさらに区分される。ノード（８２１４）は、さらに分割されないため、リーフノードである。したがって、図８Ａに示すように、ブロック（８１１１）は垂直方向にサイズの等しい２つのブロック（８１２１）および（８１２２）に分割され、ブロック（８１１２）は水平方向にサイズの等しい２つのブロックに分割され、ブロック（８１１３）はサイズの等しい４つのブロックに分割され、ブロック（８１１４）はさらには分割されない。

【0118】

図８Ｂに戻ると、より深いレベルでは、ノードの一部、例えば、ノード（８２２１）～（８２２８）のようにさらに区分されるものもあれば、区分されないノードもある。例えば、非リーフＢＴノード（８２２１）は、対称垂直区分により、さらに２つのリーフノード（８２３１）および（８２３２）に区分されるのに対して、リーフノード（８２２２）は、さらには区分されない。したがって、図８Ａに示すように、ブロック（８１２１）は、サイズの等しい２つのブロック（８１３１）および（８１３２）に分割されるのに対し、ブロック（８１２２）はさらには分割されない。

【0119】

ＱＴＢＴ構造（８２００）の区分が完了した後、さらに区分されないリーフノードは、予測および変換処理に使用されるＣＵである。したがって、ＣＵと、ＣＵに関連付けられたＰＵと、ＣＵに関連付けられたＴＵとは、ＱＴＢＴ構造において同じブロックサイズを有してもよい。また、ＱＴＢＴ構造において、ＣＵは異なる色成分のＣＢを含んでもよい。例えば、４：２：０フォーマットにおいて、１つのＣＵは、ＰスライスまたはＢスライスに１つのルーマＣＢと２つのクロマＣＢとを含んでもよい。しかしながら、他の一部の実施形態において、ＣＵは、単一の成分にＣＢを含んでもよい。例えば、Ｉスライスにおいて、１つのＣＵは、１つのルーマＣＢまたは２つのクロマＣＢを含んでもよい。すなわち、ＱＴＢＴ構造は、ルーマとクロマとが異なる分割構造を有することをサポートする。

【0120】

さらに、ＱＴＢＴ構成は、ルーマとクロマが別々のＱＴＢＴ構造を有する柔軟性をサポートしている。現在、ＰおよびＢスライスでは、１つのＣＴＵ内のルーマおよびクロマのＣＴＢは、同じＱＴＢＴ構造を共有する。しかしながら、Ｉスライスに関して、ルーマＣＴＢはＱＴＢＴ構造によりＣＵに分割され、クロマＣＴＢは別のＱＴＢＴ構造によりクロマＣＵに分割される。したがって、ＩスライスのＣＵは、ルーマ成分のコーディングブロックまたは２つのクロマ成分のコーディングブロックを含み、ＰまたはＢスライスのＣＵは、３つの色成分すべてのコーディングブロックを含む。

【0121】

ＨＥＶＣにおいて、小ブロックのインター予測は動き補償のメモリアクセスを低減するために制限されているため、４×８および８×４ブロックに対しては双予測がサポートされず、４×４ブロックに対してはインター予測がサポートされない。ＪＥＭ－７．０で実行されたＱＴＢＴにおいて、これらの制限は解消されている。

【0122】

例えば、ＶＴＭ６において、コーディングツリー構成は、ルーマとクロマとが別々のブロックツリー構造を有することをサポートしている。一例として、ＰおよびＢのスライスに対して、１つのＣＴＵ内のルーマおよびクロマのＣＴＢは同じコーディングツリー構造を共有する必要がある。しかしながら、Ｉ スライスに関しては、ルーマおよびクロマは別々のブロックツリー構造を有してもよい。別々のブロックツリーモードが適用される場合、ルーマＣＴＢは１つのコーディングツリー構造によってＣＵに分割され、クロマＣＴＢは別のコーディングツリー構造によってクロマＣＵに分割される。すなわち、ＩスライスのＣＵには、ルーマ成分のコーディングブロックまたは２つのクロマ成分のコーディングブロックが含まれてもよく、ＰスライスやＢスライスのＣＵには、ビデオがモノクロでない限り、必ず３つの色成分すべてのコーディングブロックが含まれる。

【0123】

ＩＶ．トリプルツリーを用いたブロック分割構造

【0124】

上述のＱＴＢＴ構造に加えて、多重型ツリー（ＭＴＴ）構造と呼ぶ別の区分構造は、ＱＴＢＴ構造よりも柔軟性が高い。ＭＴＴでは、図９Ａおよび図９Ｂに示すように、ＱＴおよびＢＴ以外に、水平および垂直方向のセンターサイドＴＴが導入されている。

【0125】

図９Ａは、垂直方向のセンターサイドＴＴ分割の一例を示す。例えば、ブロック（９１０）は、サブブロック（９１２）がブロック（９１０）の中央に位置する３つのサブブロック（９１１）～（９１３）に垂直に区分される。

【0126】

図９Ｂは、水平方向のセンターサイドＴＴ分割の一例を示す。例えば、ブロック（９２０）は、サブブロック（９２２）がブロック（９２０）の中央に位置する３つのサブブロック（９２１）～（９２３）に水平に区分される。

【0127】

ＢＴ区分と同様に、ＴＴ区分において、区分タイプ（すなわち、対称水平区分または対称垂直区分）を示すフラグが信号伝達される。一例において、「０」は対称水平区分を示し、「１」は対称垂直区分を示す。

【0128】

ＴＴ分割の１つの利点は、ＴＴ分割がＱＴ分割やＢＴ分割を補完することができることである。例えば、ＴＴ分割がブロックセンターに位置するオブジェクトをキャプチャすることができるのに対し、ＱＴ分割とＢＴ分割とは常にブロックセンターに沿って区分する。ＴＴ分割のもう一つの利点は、ＴＴ分割による分割の幅と高さは常に２の累乗であるため、追加の変換が不要であることである。

【0129】

四分木、二分木、三分木の区分タイプを含むＭＴＴ構造は、ＱＴＢＴＴＴ構造と呼ばれる。ＱＴＢＴ構造と同様に、ＱＴＢＴＴＴ構造は、ルーマおよびクロマが異なる構造を有することもサポートしている。例えば、Ｉスライスにおいて、ルーマＣＴＢを分割するためのＱＴＢＴＴＴ構造は、クロマＣＴＢを分割するためのＱＴＢＴＴＴ構造とは異なってもよい。すなわち、分けられたツリー構造が有効な場合、１つのＣＵには１つのルーマＣＢまたは２つのクロマＣＢが含まれる。しかしながら、ＰまたはＢスライスにおいて、ルーマＣＴＢは１つのＣＴＵにおいてクロマＣＴＢと同じＱＴＢＴＴＴ構造を共有することができる。換言すれば、分けられたツリー構造が無効の場合、１つのＣＵには３つのＣＢすべて、すなわち１つのルーマＣＢと２つのクロマＣＢとが含まれる。

【0130】

ＶＶＣでは、Ｉ－ｓｌｉｃｅに対してデュアルツリーまたはセパレートツリーが使用される。すなわち、一方のツリーがルーマ成分に、他方のツリーはクロマ成分に使用される。ＢスライスおよびＰスライスに対して、１つのシングルツリーをルーマ成分とクロマ成分とが共有する。

【0131】

２つのレベルを有するツリーを設計するのは、主に計算量を軽減するためである。一例として、ツリーを横切ることに対する計算量はＴＤであり、Ｔは区分タイプの数、Ｄはツリーの深さを表す。

【0132】

Ｖ．ルーマ成分に対するイントラ予測

【0133】

図１０は、一部の例（例えば、ＶＶＣ）における例示的なイントラ予測方向を示す説明図である。図１０において、合計９５個のイントラ予測モード（モード-１４～８０）があり、そのうち、モード０は平面モード（ＩＮＴＲＡ＿ＰＬＡＮＡＲと表記）、モード１はＤＣモード（ＩＮＴＲＡ＿ＤＣと表記）、その他のモード（モード-１４～－１、モード２～８０）は角度（または方向）モード（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲとも表記）である。角度（または方向）モードのうち、モード１８（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ１８と表記）は水平モードであり、モード５０（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ５０と表記）は垂直モードであり、モード２（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ２と表記）は左下方向を指す対角線モードであり、モード３４（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ３４と表記）は左上方向を向いた対角線モード、モード６６（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ６６と表記）は右上方向を向いた対角線モードである。モード-１４～－１とモード６７～８０は広角イントラ予測（ＷＡＩＰ）モードと呼ぶ。

【0134】

ＶＩ．クロマ成分に対するイントラ予測

【0135】

イントラＰＵのクロマ成分（例えば、ＶＴＭにおいて）に対して、エンコーダは、平面モード、ＤＣモード、水平モード、垂直モード、ルーマ成分からのイントラ予測モード（ＤＭ）の直接のコピー、左および上方クロス成分リニアモード（ＬＴ＿ＣＣＬＭ）、左クロス成分リニアモード（Ｌ＿ＣＣＬＭ）、上方クロス成分リニアモード（Ｔ＿ＣＣＬＭ）を含む８つのモードの中から最適なクロマ予測モードを選択する。表１のクロマ予測モードインデックス４、５、６によりそれぞれ示されるＬＴ＿ＣＣＬＭ、Ｌ＿ＣＣＬＭ、Ｔ＿ＣＣＬＭは、クロス成分リニアモード（ＣＣＬＭ）のグループに分類されてもよい。

【0136】

表１は、ＣＣＬＭを有効にした場合のルーマモードからのクロマ予測モードの導出を例示したものである。平面モード、垂直モード、水平モード、ＤＣモード、ＬＴ＿ＣＣＬＭ、Ｌ＿ＣＣＬＭ、Ｔ＿ＣＣＬＭ、およびＤＭは、クロマ予測モードインデックス０～７で表される。対応するデフォルトのクロマイントラ予測方向は、ＤＭを除くこれらのクロマ予測モードに対して０、５０、１８、１、８１、８２、８３である。

【表1】

【0137】

表１において、クロマ成分に対応するクロマ予測モードインデックス番号が７の場合、クロマ成分のイントラ予測サンプル生成には、ルーマ成分のイントラ予測方向を用いてもよい。例えば、クロマ予測モードインデックス７（すなわちＤＭ）の場合、対応するルーマイントラ予測方向が５０（すなわち、垂直方向）であるとき、クロマイントラ予測方向も５０であり、したがって、クロマ成分には垂直モードが用いられることになる。

【0138】

表１において、クロマ成分に対するクロマ予測モードインデックス番号が７でない場合、クロマ成分のイントラ予測方向は、デフォルトのクロマイントラ予測方向が、対応するルーマイントラ予測と同一であるか否かに依存する場合がある。

【0139】

デフォルトのクロマイントラ予測方向が、対応するルーマイントラ予測と同一である場合、イントラ予測方向６６は、クロマ成分のイントラ予測サンプル生成に用いられてもよい。例えば、クロマ予測モードインデックス１（すなわち、垂直モード）に対しては、デフォルトのクロマイントラ予測方向は５０であり、イントラ予測方向６６は、対応するルーマイントラ予測方向も５０（すなわち、垂直方向）である場合に、クロマ成分のイントラ予測サンプル生成に用いられる。

【0140】

デフォルトのクロマイントラ予測方向が、対応するルーマイントラ予測方向と同一でない場合、デフォルトクロマイントラ予測方向は、クロマ成分のイントラ予測サンプル生成に用いられてもよい。例えば、クロマ予測モードインデックス１（すなわち、垂直モード）に対しては、デフォルトのクロマイントラ予測方向は５０であり、デフォルトクロマイントラ予測５０は、対応するルーマイントラ予測方向が５０でない場合（例えば、１８）、クロマ成分のイントラ予測サンプル生成に用いられてもよい。

【0141】

表２は、ＣＣＬＭが有効な場合のイントラクロマ予測モードの例示的な信号伝達（例えば、２値化）処理を示す。ＤＭ（すなわち、モード７）は、すべてのクロマイントラ予測モードの中で、最も少ないコードワードを有することが示されている。

【表2】

【0142】

ＶＩＩ．小ブロックサイズの制約

【0143】

２×２、２×４、４×２サンプルを含む小ブロックサイズは、デュアルツリーにおいて制限される。この制約は、４×４，２×８，８×２ブロックに対しては区分が許可されず、８×４，４×８ブロックに対しては三分木区分が許可されない、という区分禁止により実行される。

【0144】

シングルツリーの場合、クロマブロックのブロックサイズ（例えば、面積サイズまたはサンプル数）が閾値以上であり、クロマブロックの区分によってクロマブロックのサブブロックのサイズが閾値未満になる場合や、クロマブロックのさらなる区分が許可されない場合、クロマブロックは並列処理可能領域（ＰＰＲ）として扱われてもよい。閾値は、１６または３２などの任意の正の整数であってもよい。一例において、ＶＴＭの４倍の処理量という最悪の場合の処理を達成するために、閾値は１６サンプルに等しいものとして設定される。

【0145】

図１１Ａ～１１Ｅは、本開示の一実施形態によるＰＰＲの例示的な形状を示す。各ブロック（またはサブブロック）内に記された値は、そのブロック（またはサブブロック）内のサンプル数を示す。例えば、図１１Ａは、４×４クロマブロック（１６個のサンプル）が４つの２×２サブブロックに区分され、各サブブロックが４個のサンプルを有することを示す。この４×４クロマブロックは、１つのＰＰＲとみなすことができる。

【0146】

１６サンプルのＰＰＲ内のブロック（またはサブブロック）間のイントラ予測依存性は、ＰＰＲ内の複数のブロック（またはサブブロック）を、このＰＰＲに含まれるすべてのブロック（またはサブブロック）を予測することに「利用不可能」と記すことで解消することができる。なお、参照サンプルの置換は、隣接するブロックが利用不可能である場合に、ＶＶＣの参照置換プロセスによって自動的に行うことができる。また、この方法のために、イントラ予測の他の部分における変更が必要となることはない。

【0147】

ＶＩＩＩ．小ブロックサイズ制約の改善

【0148】

本開示の実施形態は、１つまたは複数の小ブロックサイズの使用を改善することができる。異なる色成分が同じブロック分割構造を共有するシングルツリーにおける小クロマブロック制限については、１つのＰＰＲ内の複数のブロック（またはサブブロック）が利用不可能と記されている可能性がある。例えば、図１１Ａ、図１１Ｂ、図１１Ｃのそれぞれ右下のブロック（１１０１）～（１１０３）のような、ＰＰＲ内の小クロマブロックについては、これらの小クロマブロックの左隣接サンプルおよび上方隣接サンプルの両方とも利用不可能と記されているものがある。しかしながら、これに関連して、表１に記載されたモードのようなすべてのクロマ予測モードが、ＰＰＲ内のすべてのブロック（またはサブブロック）を予測するのに許可されており、いくつかの冗長な信号伝達ビットにつながる場合もある。

【0149】

本開示の態様によれば、本方法は、１つまたは複数の小ブロックに適用することができる。小ブロックは、ブロックの面積サイズまたはブロックの辺の長さ（例えば、ブロックの高さまたはブロックの幅）によって特定することができる。１つまたは複数の小ブロックは、例えば、２の倍数であるサイズを有してもよい。一例において、１つまたは複数の小ブロックは、２×２ブロックを含んでもよい。別の例において、小ブロックは、２×２、２×４、および４×２ブロックを含んでもよい。

【0150】

１つまたは複数の小ブロックは、１つの固定されたサイズを有してもよい。例えば、小ブロックは、２×ＮおよびＮ×２ブロックを含んでもよく、ここでＮは正の整数である。すなわち、小ブロックの１辺は、２つのサンプルを有することに限定される。別の例において、小ブロックは、４×ＮおよびＮ×４クロマブロックを含んでもよく、ここでＮは正の整数である。すなわち、小ブロックの１辺は、４つのサンプルを有することに限定される。

【0151】

１つまたは複数の小ブロックは、ルーマイントラ符号化された最小のブロックサイズを有するルーマイントラ符号化されたブロックに基づいてもよい。例えば、ブロック面積サイズ、ブロック幅、および／またはブロック高さが、ルーマイントラ符号化された最小のブロックサイズを有するイントラ符号化されたブロックよりも小さい。すなわち、小ブロックの場合、小ブロックのブロックサイズは、ルーマイントラ符号化された最小のブロックのブロックサイズよりも小さく、および／または、小ブロックのブロック幅は、ルーマイントラ符号化された最小のブロックのブロック幅よりも小さく、および／または、ブロック高さは、ルーマイントラ符号化された最小のブロックのブロック高さよりも小さい。

【0152】

１つまたは複数の小ブロックは、閾値に基づいたものであってもよい。例えば、小ブロックは、２×ＮまたはＮ×２画素を含んでもよく、小ブロック内の画素数は、閾値ＴｈｒｅＰｉｘｅｌｓよりも小さく、ここで、Ｎは正の整数である。閾値ＴｈｒｅＰｉｘｅｌｓは、１６や３２などの所定の値に設定されてもよい。ＴｈｒｅＰｉｘｅｌｓは、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダなどのビットストリームで信号伝達されてもよい。

【0153】

本開示の態様によれば、１つの現在のＰＰＲ内のイントラ符号化されたクロマ（またはルーマ）ブロック（またはサブブロック）に対して、その上方隣接サンプルおよび／または左隣接サンプルが現在のブロックの予測に使用されていない（例えば、これらの隣接ブロックのうち少なくとも１つが「使用不可能」と記されている）場合、他のブロック（例えば、非小ブロック）に適用可能なすべてのクロマイントラ予測モードの代わりに、現在のブロックの予測に使用されてもよいのは特定のクロマイントラ予測モードのみである。

【0154】

例えば、１１Ａ～１１Ｃに示すように、４×４ブロックは３つの異なる分割パターンを用いて区分されてもよい。各分割パターンについて、４つのサンプルのみを有する、右下の２×２ブロックの上方隣接サンプルおよび左隣接サンプルは、「利用不可能」と記されてもよく、右下の２×２ブロックの予測に用いることはできない。

【0155】

本開示の態様によれば、一ブロックに対する許容されるクロマ予測モードは、利用可能なクロマ予測モードのサブセットに制約されてもよく、このサブセットは、例えば、表１に記載されたモードの１つまたは複数を含んでもよい。許容されるクロマ予測モードは、ブロックの上方隣接および／または左隣接サンプルの利用可能性に基づいて制約されてもよい。

【0156】

一実施形態において、１つの現在のＰＰＲにおける１つまたは任意の小クロマブロック（またはサブブロック）について、小クロマブロック（またはサブブロック）の上方隣接サンプルおよび／または左隣接サンプルが小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードは制約されてもよい。許容されるクロマ予測モードは、表１に記載されたモードのサブセットに限定されてもよい。例えば、許容されるクロマ予測モードは、１つのモード（例えば、ＤＭ）のみに制限されてもよい。１つのモードのみに制約された場合、現在のクロマブロックのクロマ予測モードを示すための信号伝達にビットを用いる必要はない。

【0157】

一実施形態において、１つの現在のＰＰＲにおける１つまたは任意の小クロマブロック（またはサブブロック）について、小クロマブロック（またはサブブロック）の上方隣接サンプルおよび／または左隣接サンプルが現在のＰＰＲ内にあり、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードは制約されてもよい。例えば、許容されるクロマ予測モードは、表１に記載されたモードの１つ（例えば、ＤＭ）などの、１つのモードのみに制限されてもよい。１つのモードのみに制約された場合、現在のクロマブロックのクロマ予測モードを示すための信号伝達にビットを用いる必要はない。

【0158】

一実施形態において、１つの現在のＰＰＲにおける１つまたは任意の小クロマブロック（またはサブブロック）について、小クロマブロック（またはサブブロック）上方隣接サンプルおよび／または左隣接サンプルが現在の画像（またはＣＴＵ行またはＣＴＵ、またはスライス、またはタイル、またはタイルグループ）の外側にある場合、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードは制約されてもよい。例えば、許容されるクロマ予測モードは、表１に記載されたモードの１つ（例えば、ＤＭ）などの、１つのモードのみに制限されてもよい。１つのモードのみに制約された場合、現在のクロマブロックのクロマ予測モードを示すための信号伝達にビットを用いる必要はない。

【0159】

本開示の態様によれば、１つの現在のＰＰＲにおける１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の上方隣接サンプルまたは左隣接サンプルが小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）の許容されるクロマ予測モードは、ＤＭおよびＬ＿ＣＣＬＭ（またはＴ＿ＣＣＬＭ）などの２つのモードのみに制約されてもよい。上方のサンプルおよび隣接するサンプルのいずれが利用不可能であるかによって、異なる制約が適用されてもよい。

【0160】

一実施形態において、１つの現在のＰＰＲ内の１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の上方隣接サンプルが現在のＰＰＲ内にあり、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードはＤＭおよび／またはＬ＿ＣＣＬＭモードのみに制約されてもよい。

【0161】

一実施形態において、１つの現在のＰＰＲ内の１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の左隣接サンプルが現在のＰＰＲ内にある場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードは、ＤＭモードおよび／またはＴ＿ＣＣＬＭモードのみに制約されてもよい。

【0162】

本開示の態様によれば、１つの現在のＰＰＲ内の１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の上方隣接サンプルまたは左隣接サンプルが現在のＰＰＲ内にあり、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）の許容されるクロマ予測モードは、ＤＭモードおよび垂直（または水平）モードなどの、２つのモードのみに制約されてもよい。上方のサンプルおよび隣接するサンプルのいずれが利用不可能であるかによって、異なる制約が適用されてもよい。

【0163】

一実施形態において、１つの現在のＰＰＲ内の１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の上方隣接サンプルが現在のＰＰＲ内にあり、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードはＤＭおよび／または水平モードのみに制約されてもよい。

【0164】

一実施形態において、１つの現在のＰＰＲ内の１つまたは任意の小クロマブロックについて、小クロマブロック（またはサブブロック）の左隣接サンプルが現在のＰＰＲ内にあり、小クロマブロック（またはサブブロック）の予測に利用不可能である場合、小クロマブロック（またはサブブロック）に対して許容されるクロマ予測モードはＤＭおよび／または垂直モードのみに制約されてもよい。

【0165】

本開示の態様によれば、本開示に示された上記の方法は、シングルツリーおよび／またはデュアルツリーの場合に適用されてもよい。すなわち、本方法は、クロマサンプルとルーマサンプルが同じパーティションツリー構造を使用するか否かにかかわらず用いられてもよい。

【0166】

ＩＸ．小ブロックサイズ制約改善のフローチャート

【0167】

図１２は、本開示の一実施形態による例示的なプロセス（１２００）を概説するフローチャートを示す。様々な実施形態において、プロセス（１２００）は、端末装置（２１０）、（２２０）、（２３０）および（２４０）内の処理回路、ビデオエンコーダ（３０３）の機能を実行する処理回路、ビデオデコーダ（３１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、イントラ予測モジュール（４５２）の機能を実行する処理回路、ビデオエンコーダ（５０３）の機能を実行する処理回路、予測器（５３５）の機能を実行する処理回路、イントラエンコーダ（６２２）の機能を実行する処理回路、イントラデコーダ（７７２）の機能を実行する処理回路、などの処理回路により実行される。一部の実施形態において、プロセス（１２００）はソフトウェア命令で実行され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（１２００）を実行する。

【0168】

プロセス（１２００）は、一般に、プロセス（１２００）が符号化されたビデオシーケンスの一部である現在の画像の現在のブロックの予測情報を復号するステップ（Ｓ１２１０）で開始されてもよい。予測情報は、現在のブロックのクロマサンプルに対するパーティションツリー構造を示してもよい。次に、プロセス（１２００）は、ステップ（Ｓ１２２０）に進む。

【0169】

ステップ（Ｓ１２２０）において、プロセス（１２００）は、現在のブロックのクロマサンプルを、パーティションツリー構造に基づいて、複数のサブブロックに分割する。次に、プロセス（１２００）は、ステップ（Ｓ１２３０）に進む。

【0170】

ステップ（Ｓ１２３０）において、プロセス（１２００）は、複数のサブブロック内のサブブロックのクロマサンプルを、以下の２つの条件、すなわち、（ｉ）サブブロックの上方隣接サンプルおよび左隣接サンプルの少なくとも１つがサブブロックの予測に利用不可能であること、および（ｉｉ）サブブロックのブロックサイズがサイズ閾値以下であること、またはサブブロックの辺の長さが長さ閾値以下であること、という条件が満たされた場合、クロマイントラ予測モードのサブセットに基づいて予測する。次に、プロセス（１２００）は、ステップ（Ｓ１２４０）に進む。

【0171】

ステップ（Ｓ１２４０）において、プロセス（１２００）は、予測されたクロマサンプルに基づいて、現在のブロックを再構築する。

【0172】

現在のブロックを再構築した後、プロセス（１２００）は終了する。

【0173】

一実施形態において、現在のブロックのブロックサイズは、サイズ閾値より大きく、サブブロックのブロックサイズは、サイズ閾値以下である。サイズ閾値は、２×２、２×４、および４×２のいずれかを含んでもよい。サイズ閾値は、ルーマイントラ符号化された許容される最小のブロックのブロックサイズを含んでもよい。

【0174】

一実施形態において、現在のブロックの辺の長さは長さ閾値より大きく、サブブロックの辺の長さは長さ閾値以下である。長さ閾値は、２および４のいずれか一方を含む。長さ閾値は、ルーマイントラ符号化された許容される最小のブロックの辺の長さを含んでもよい。

【0175】

一実施形態において、クロマイントラ予測モードは、平面モード、ＤＣモード、水平モード、垂直モード、派生モード（ＤＭ）、左クロス成分リニアモード（Ｌ＿ＣＣＬＭ）、上方クロス成分リニアモード（Ｔ＿ＣＣＬＭ）、ならびに左および上方クロス成分リニアモード（ＬＴ＿ＣＣＬＭ）を含む。

【0176】

一実施形態において、クロマイントラ予測モードのサブセットは、クロマイントラ予測モードの１つまたは２つを含む。 例えば、クロマイントラ予測モードのサブセットは、ＤＭのみを含む。

【0177】

一実施形態において、クロマイントラ予測モードのサブセットは、サブブロックの上方隣接サンプルがサブブロックの予測に利用不可能であり、かつ現在のブロック内に位置する場合、ＤＭ、Ｌ＿ＣＣＬＭ、および垂直モードのうちの少なくとも１つを含む。

【0178】

一実施形態において、クロマイントラ予測モードのサブセットは、サブブロックの左隣接サンプルがサブブロックの予測に利用不可能であり、かつ現在のブロック内に位置する場合、ＤＭ、Ｔ＿ＣＣＬＭ、および水平モードのうちの少なくとも１つを含む。

【0179】

一実施形態において、現在のブロックは、すべてのサブブロックが並列に再構築されるＰＰＲである。

【0180】

Ｘ．イントラサブパーティション（ＩＳＰ）コーディングモード

【0181】

イントラサブパーティション（ＩＳＰ）コーディングモードで符号化されたルーマコーディングブロックは、表３に示すように、ブロックのブロックサイズに依存して、垂直方向（垂直ＩＳＰモード）または水平方向（水平ＩＳＰモード）に複数のサブパーティション（例えば、２または４）に分割されてもよい。表３は、ブロックサイズに依存するサブパーティションの例を示す。

【表3】

【0182】

一部の例において、ＣＵを２つのサブパーティションに分割するか、４つのサブパーティションに分割するか否かは、ＣＵのブロックサイズに依存する。図１３Ａおよび１３Ｂは、一部の例示的なサブパーティションを示す。一部の例において、すべてのサブパーティションが、少なくとも１６個のサンプルを有するという条件を満たす。クロマ成分については、ＩＳＰモードを適用することはできない。一部の例において、最大で２つのビンがＩＳＰに関して信号伝達される。第１のビンは、ＩＳＰが使用されるか否かを示す。ＩＳＰが使用される場合、１つの方向しか利用することができない場合を除き、ＩＳＰの方向を示すために、第２のビンがさらに信号伝達される。

【0183】

図１３Ａは、本開示の一実施形態によるＩＳＰモードで符号化されるコーディングブロック（１３００）の例示的な水平方向のＩＳＰモードおよび例示的な垂直方向のＩＳＰモードを示す。図１３Ａの例において、コーディングブロック（１３００）のブロックサイズはＷ１×Ｈ１であり、これは例えば４×８または８×４サンプルのいずれかである。したがって、コーディングブロック（１３００）は、２つのサブパーティションに分割される。図１３に示すように、コーディングブロック（１３００）は、水平ＩＳＰモードの場合は、それぞれがＷ１×Ｈ１／２サンプルのサイズを有する２つのサブパーティション（１３１１）～（１３１２）に水平に分割され、垂直ＩＳＰモードの場合は、それぞれがＷ１／２×Ｈ１サンプルのサイズを有する２つのサブパーティション（１３２１）～（１３２２）に垂直に分割される。

【0184】

図１３Ｂは、本開示の一実施形態によるＩＳＰモードで符号化される別のコーディングブロック（１３５０）の例示的な水平方向のＩＳＰモードおよび例示的な垂直方向のＩＳＰモードを示す。図１３Ｂの例において、コーディングブロック（１３５０）のブロックサイズはＷ２ｘＨ２であり、これは例えば上記の４×８または８×４サンプルである。したがって、コーディングブロック（１３５０）は、４つのサブパーティションに分割される。図１３Ｂに示すように、コーディングブロック（１３５０）は、それぞれがＷ２×Ｈ２／４サンプルのサイズを有する４つのサブパーティション（１３６１）～（１３６４）に水平に分割されるか、または、それぞれがＷ２／４×Ｈ２サンプルのサイズを有する４つのサブパーティション（１３７１）～（１３７４）に垂直に分割される。

【0185】

一部の例において、これらのサブパーティションのそれぞれについて、エンコーダから送信された係数をエントロピー復号し、さらにその係数を逆量子化および逆変換することにより、残余信号が生成されてもよい。次に、現在のサブパーティションと呼んでもよいサブパーティションの１つについて、現在のサブパーティションにイントラ予測を行うことによって予測信号が生成されてもよい。最後に、現在のサブパーティションの再構築されたサンプルは、残余信号を予測信号に加えることにより得られてもよい。したがって、現在のサブパーティションの再構築されたサンプルは、例えば、現在のサブパーティションに隣接する別のサブパーティションを予測するために用いてもよい。このプロセスは、他のサブパーティションに対して繰り返してもよい。すべてのサブパーティションは、同じイントラモードを共有してもよい。

【0186】

一部の例において、ＩＳＰモードは、最確モード（ＭＰＭ）リストの一部であるイントラモードでのみ試験することができる。従って、ＣＵがＩＳＰモードで符号化される場合、ＭＰＭリストのＭＰＭフラグは、例えば、１すなわち真であると推論されてもよい。一部の例において、ＭＰＭリストは、ＤＣモードを除外し、水平ＩＳＰモードに対して水平イントラ予測モードを優先し、垂直ＩＳＰモードに対しては垂直イントラ予測モードを優先するように変更されてもよい。

【0187】

一部の例において、ＣＵの各サブパーティションは、変換および再構築は各サブパーティションに対して個別に実行してもよいため、サブＴＵとみなしてもよい。

【0188】

表４は、本開示の一実施形態によるＩＳＰモードを有するコーディングユニットの例示的な仕様を示す。

【表4A】

【表4B】

【表4C】

【0189】

表４において、変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ［ｘ０］［ｙ０］が１に等しい場合、それは、現在のイントラＣＵがＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓ［ｘ０］［ｙ０］矩形変換ブロックサブパーティションに分割されることを指定する。変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ［ｘ０］［ｙ０］が０に等しい場合、それは現在のイントラコーディングユニットが矩形変換ブロックサブパーティションに分割されないことを指定する。変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ［ｘ０］［ｙ０］が存在しない場合は、それは０に等しいと推論される。

【0190】

変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ［ｘ０］［ｙ０］は、イントラサブパーティションの区分タイプが水平か垂直かを指定する。変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ［ｘ０］［ｙ０］が存在しない場合は、以下のように推論される。
－ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹより大きい場合、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ［ｘ０］［ｙ０］は０に等しいと推論される。
－それ以外の場合、変数ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹより大きい場合、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ［ｘ０］［ｙ０］は１に等しいと推論される。

【0191】

変数ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅは、表５に示されるように、現在のルーマコーディングブロックに使用される区分タイプを指定する。表５は、ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅへの例示的な名前結合を示す。ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅは以下のように導出される。
－変数ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ［ｘ０］［ｙ０］が０に等しい場合、変数ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅは０に設定される。
－それ以外の場合、変数ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅは、１＋ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ［ｘ０］［ｙ０］に等しく設定される。

【表5】

【0192】

変数ＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓは、イントラルーマコーディングブロックがそへと分けられる変換ブロックサブパーティションの数を指定する。ＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓは以下のように導出される。
－変数ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅがＩＳＰ＿ＮＯ＿ＳＰＬＩＴに等しい場合、変数ＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓは１に等しく設定される。
－それ以外の場合、以下の条件のいずれかが真であれば、ＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓは２に等しく設定される。
－ｃｂＷｉｄｔｈは４に等しく、ｃｂＨｅｉｇｈｔは８に等しい、
－ｃｂＷｉｄｔｈは８に等しく、ｃｂＨｅｉｇｈｔは４に等しい。
－それ以外の場合、変数ＮｕｍＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓは４に等しく設定される。

【0193】

ＸＩ．スケーリングされた変換係数の変換プロセス

【0194】

スケーリングされた変換係数のための変換プロセスへの入力は、（ｉ）現在の画像の左上のルーマサンプルに対する現在のルーマ変換ブロックの左上のサンプルを指定するルーマロケーション（ｘＴｂＹ，ｙＴｂＹ）と、（ｉｉ）現在の変換ブロックの幅を指定する変数ｎＴｂＷと、（ｉｉｉ）現在の変換ブロックの高さを指定する変数ｎＴｂＨと、（ｉｖ）現在のブロックの色成分を指定する変数ｃＩｄｘと、（ｖ）ｘ＝０．．ｎＴｂＷ-１，ｙ＝０．．ｎＴｂＨ-１であるスケーリングされた変換係数の（ｎＴｂＷ）ｘ（ｎＴｂＨ）配列ｄ［ｘ］［ｙ］と、を含んでもよい。

【0195】

このプロセスの出力は、ｘ＝０．．ｎＴｂＷ－１，ｙ＝０．．ｎＴｂＨ－１である、残余サンプルの（ｎＴｂＷ）ｘ（ｎＴｂＨ）配列ｒ［ｘ］［ｙ］である。

【0196】

ｌｆｎｓｔ＿ｉｄｘ［ｘＴｂＹ］［ｙＴｂＹ］が０に等しくなく、ｎＴｂＷおよびｎＴｂＨの両方が４以上の場合、以下が成立する。
－変数ｐｒｅｄＭｏｄｅＩｎｔｒａ、ｎＬｆｎｓｔＯｕｔＳｉｚｅ、ｌｏｇ２ＬｆｎｓｔＳｉｚｅ、ｎＬｆｎｓｔＳｉｚｅ、およびｎｏｎＺｅｒｏＳｉｚｅが以下のように導出される。
ｐｒｅｄＭｏｄｅＩｎｔｒａ＝（ｃＩｄｘ＝＝０）？ＩｎｔｒａＰｒｅｄＭｏｄｅＹ［ｘＴｂＹ］［ｙＴｂＹ］：
ＩｎｔｒａＰｒｅｄＭｏｄｅＣ［ｘＴｂＹ］［ｙＴｂＹ］ 式（１）
ｎＬｆｎｓｔＯｕｔＳｉｚｅ＝（ｎＴｂＷ＞＝８＆＆ｎＴｂＨ＞＝８）？４８：１６ 式（２）
ｌｏｇ２ＬｆｎｓｔＳｉｚｅ＝（ｎＴｂＷ＞＝８＆＆ｎＴｂＨ＞＝８）？３：２ 式（３）
ｎＬｆｎｓｔＳｉｚｅ＝１＜＜ｌｏｇ２ＬｆｎｓｔＳｉｚｅ 式（４）
ｎｏｎＺｅｒｏＳｉｚｅ＝（（ｎＴｂＷ＝＝４＆＆ｎＴｂＨ＝＝４）｜｜（ｎＴｂＷ＝＝８＆＆ｎＴｂＨ＝＝８））？８：１６ 式（５）
－ｉｎｔｒａ＿ｍｉｐ＿ｆｌａｇ［ｘＴｂＣｏｍｐ］［ｙＴｂＣｏｍｐ］が１に等しく、ｃＩｄｘが０に等しい場合、ｐｒｅｄＭｏｄｅＩｎｔｒａはＩＮＴＲＡ＿ＰＬＡＮＡＲに等しく設定される。
－ｐｒｅｄＭｏｄｅＩｎｔｒａがＩＮＴＲＡ＿ＬＴ＿ＣＣＬＭ、ＩＮＴＲＡ＿Ｌ＿ＣＣＬＭ、またはＩＮＴＲＡ＿Ｔ＿ＣＣＬＭのいずれかに等しい場合、ｐｒｅｄＭｏｄｅＩｎｔｒａはＩｎｔｒａＰｒｅｄＭｏｄｅＹ［ｘＴｂＹ＋ｎＴｂＷ／２］［ｙＴｂＹ＋ｎＴｂＨ／２］に等しく設定される。
－広角イントラ予測モードマッピングプロセスは、ｐｒｅｄＭｏｄｅＩｎｔｒａ、ｎＴｂＷ、ｎＴｂＨおよびｃＩｄｘを入力として、および変更されたｐｒｅｄＭｏｄｅＩｎｔｒａを出力として、起動される。
－ｘ＝０．．ｎｏｎＺｅｒｏＳｉｚｅ－１であるリストｕ［ｘ］の値は、以下のように導出される。
ｘＣ＝ＤｉａｇＳｃａｎＯｒｄｅｒ［２］［２］［ｘ］［０］ 式（６）
ｙＣ＝ＤｉａｇＳｃａｎＯｒｄｅｒ［２］［２］［ｘ］［１］ 式（７）
ｕ［ｘ］＝ｄ［ｘＣ］［ｙＣ］ 式（８）
－一次元低周波非分離変換は、スケーリングされた変換係数の入力長ｎｏｎＺｅｒｏＳｉｚｅと、ｎＬｆｎｓｔＯｕｔＳｉｚｅに等しく設定された変換出力長ｎＴｒＳと、ｘ＝０．．ｎｏｎＺｅｒｏＳｉｚｅ-１であるスケーリングされた非ゼロ変換係数のリストｕ［ｘ］と、ＬＦＮＳＴセット選択のためのイントラ予測モードｐｒｅｄＭｏｄｅＩｎｔｒａと、入力として、選択されたＬＦＮＳＴセットにおける変換選択のためのＬＦＮＳＴインデックスｌｆｎｓｔ＿ｉｄｘ［ｘＴｂＹ］［ｙＴｂＹ］と、出力として、ｘ＝０．．ｎＬｆｎｓｔＯｕｔＳｉｚｅ－１であるリストｖ［ｘ］とにより起動される。
－ｘ＝０．．ｎＬｆｎｓｔＳｉｚｅ－１，ｙ＝０．．ｎＬｆｎｓｔＳｉｚｅ－１である配列ｄ［ｘ］［ｙ］は以下のように導出される。
－ｐｒｅｄＭｏｄｅＩｎｔｒａが３４以下の場合、以下が成立する。
ｄ［ｘ］［ｙ］＝（ｙ＜４）？ｖ［ｘ＋（ｙ＜＜ｌｏｇ２ＬｆｎｓｔＳｉｚｅ）］：（ｘ＜４）？Ｖ［３２＋Ｘ＋（（ｙ-４）＜＜２）］：ｄ［ｘ］［ｙ］） 式（９）
－それ以外の場合、以下のようになる。
ｄ［ｘ］［ｙ］＝（ｘ＜４）？ｖ［ｙ＋（ｘ＜＜ｌｏｇ２ＬｆｎｓｔＳｉｚｅ）］：（ｙ＜４）？ｖ［３２＋ｙ＋（（ｘ-４）＜＜２）］：ｄ［ｘ］［ｙ］） 式（１０）

【0197】

変数ｉｍｐｌｉｃｉｔＭｔｓＥｎａｂｌｅｄは以下のように導出される。
－ｓｐｓ＿ｍｔｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１であり、以下の条件のいずれかが真である場合、ｉｍｐｌｉｃｉｔＭｔｓＥｎａｂｌｅｄは１に設定される。
－ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅがＩＳＰ＿ＮＯ＿ＳＰＬＩＴに等しくない。
－ｃｕ＿ｓｂｔ＿ｆｌａｇが１に等しく、Ｍａｘ（ｎＴｂＷ，ｎＴｂＨ）が３２以下である。
－ｓｐｓ＿ｅｘｐｌｉｃｉｔ＿ｍｔｓ＿ｉｎｔｒａ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しく、ＣｕＰｒｅｄＭｏｄｅ［０］［ｘＴｂＹ］［ｙＴｂＹ］がＭＯＤＥ＿ＩＮＴＲＡに等しく、ｌｆｎｓｔ＿ｉｄｘ［ｘ０］［ｙ０］が０に等しく、ｉｎｔｒａ＿ｍｉｐ＿ｆｌａｇ［ｘ０］［ｙ０］が０に等しい。
－それ以外の場合、ｉｍｐｌｉｃｉｔＭｔｓＥｎａｂｌｅｄは０に設定される。

【0198】

水平方向の変換カーネルを指定する変数ｔｒＴｙｐｅＨｏｒと、垂直方向の変換カーネルを指定する変数ｔｒＴｙｐｅＶｅｒとは、以下のように導出される。
－ｃＩｄｘが０より大きい場合、ｔｒＴｙｐｅＨｏｒおよびｔｒＴｙｐｅＶｅｒは０に等しく設定される。
－それ以外の場合、ｉｍｐｌｉｃｉｔＭｔｓＥｎａｂｌｅｄが１に等しい場合、以下が成立する。
－ＩｎｔｒａＳｕｂＰａｒｔｉｔｉｏｎｓＳｐｌｉｔＴｙｐｅがＩＳＰ＿ＮＯ＿ＳＰＬＩＴに等しくないか、ｓｐｓ＿ｅｘｐｌｉｃｉｔ＿ｍｔｓ＿ｉｎｔｒａ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しく、ＣｕＰｒｅｄＭｏｄｅ［０］［ｘＴｂＹ］［ｙＴｂＹ］がＭＯＤＥ＿ＩＮＴＲＡにひとしい場合、ｔｒＴｙｐｅＨｏｒとｔｒＴｙｐｅＶｅｒは以下のように導出される。
ｔｒＴｙｐｅＨｏｒ＝（ｎＴｂＷ＞＝４＆＆ｎＴｂＷ＜＝１６）？１：０ 式（１１）
ｔｒＴｙｐｅＶｅｒ＝（ｎＴｂＨ＞＝４＆＆ｎＴｂＨ＜＝１６）？１：０ 式（１２）
－それ以外の場合（ｃｕ＿ｓｂｔ＿ｆｌａｇが１に等しい）、ｔｒＴｙｐｅＨｏｒおよびｔｒＴｙｐｅＶｅｒはｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇとｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇに依存する。
－それ以外の場合、ｔｒＴｙｐｅＨｏｒおよびｔｒＴｙｐｅＶｅｒはｔｕ＿ｍｔｓ＿ｉｄｘ［ｘＴｂＹ］［ｙＴｂＹ］に依存する。

【0199】

表６は、本開示の一実施形態による変換ツリーの例示的な仕様を示す。

【0200】

表７は、本開示の一実施形態による変換ユニットの例示的な仕様を示す。

【表6A】

【表6B】

【表7A】

【表7B】

【表7C】

【0201】

ＸＩＩ．小クロマイントラ予測ユニット（ＳＣＩＰＵ）

【0202】

最小イントラＣＵのサイズは、例えばＨＥＶＣにおいて８×８のルーマサンプルである。最小イントラＣＵのルーマ成分は、さらに４つの４×４ルーマイントラＰＵに区分することができるが、最小イントラＣＵのクロマ成分はさらに分割することはできない。そのため、４×４のクロマイントラブロックまたは４×４のルーマイントラブロックを処理する際に、ハードウェアの処理量が最悪になる可能性がある。

【0203】

ＶＴＭ５．０でのように、シングルコーディングツリーにおいて、クロマパーティションが、関連するルーマパーティションに続くため、また最小のイントラＣＵが４×４のルーマサンプルであるため、最小のクロマイントラＣＢは２×２となる。そのため、ＶＶＣ復号に関する最悪のハードウェア処理量は、ＨＥＶＣ復号の場合のわずか１／４となる。

【0204】

例えばＶＴＭ６．０におけるような小クロマイントラ予測ユニット（ＳＣＩＰＵ）は、シングルツリー中にローカルデュアルツリーを作成することにより、クロマサンプル数が１６よりも小さいクロマイントラＣＢの分割を禁止することを目的とする。ローカルデュアルツリーに入る前に、クロマパーティションは、関連するルーマパーティションと同じ区分を行う。すべてのＣＵは、イントラ符号化、インター符号化、ＩＢＣ符号化のいずれにするかを柔軟に決定することができる。ローカルデュアルツリーに入った後、すべてのＣＵはインター符号化されるか、非インター符号化（イントラまたはＩＢＣ）されるかのいずれかを実行する必要がある。現在のＣＵがインター符号化される場合、現在のＣＵのクロマ成分も、その関連するルーマブロックと同様の区分に従う。そうでない場合、現在のＣＵが非インター符号化される場合、ルーマブロックはさらに分割することができるが、関連するクロマイントラブロックはさらに分割することはできない。現在のＣＵがローカルデュアルツリーの親ノードであるか否かを判断するための例示的な条件には、以下が含まれる：ａ）ＣＵサイズが６４であり、現在のＣＵがさらにＱＴ区分されている、（ｂ）ＣＵサイズが６４であり、現在のＣＵがさらにＴＴ区分されている、（ｃ）ＣＵサイズが３２であり、現在のＣＵがさらにＢＴ区分されている、（ｄ）ＣＵサイズが６４であり、現在のＣＵがさらにＢＴ区分されている、（ｅ）ＣＵサイズが１２８であり、現在のＣＵがさらにＴＴ区分されている。

【0205】

上記条件の１つが真である場合、現在のＣＵはローカルデュアルツリーの親ノードとして判定される。また、条件（ａ）、（ｂ）または（ｃ）が成立する場合、この領域（すなわち現在のＣＵ）内のすべてのＣＵ（またはサブＣＵ）は、すべてイントラ符号化またはすべてＩＢＣ符号化されるように制約される。条件ｄ）またはｅ）が成立する場合、このエリア（すなわち、現在のＣＵ）内のすべてのＣＵ（またはサブＣＵ）がインター符号化されているか、または非インター符号化されているかを、さらにもう１つのフラグにより伝達することが必要となる。

【0206】

表８は、本開示の一実施形態によるＳＣＩＰＵモードの例示的な仕様を示す。

【表8A】

【表8B】

【表8C】

【表8D】

【0207】

変数ｍｏｄｅＴｙｐｅＣｏｎｄｉｔｉｏｎは以下のように導出される。
－以下の条件の１つが真であれば、ｍｏｄｅＴｙｐｅＣｏｎｄｉｔｉｏｎは０に等しく設定される。
－ｓｌｉｃｅ＿ｔｙｐｅ＝＝Ｉおよびｑｔｂｔｔ＿ｄｕａｌ＿ｔｒｅｅ＿ｉｎｔｒａ＿ｆｌａｇが１に等しいか、
－ｍｏｄｅＴｙｐｅＣｕｒｒがＭＯＤＥ＿ＴＹＰＥ＿ＡＬＬに等しくない。
－それ以外の場合、以下の条件の１つが真であれば、ｍｏｄｅＴｙｐｅＣｏｎｄｉｔｉｏｎは１に等しく設定される。
－ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４に等しく、ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇが１に等しいか、
－ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４に等しく、ＭｔｔＳｐｌｉｔＭｏｄｅ［ｘ０］［ｙ０］［ｍｔｔＤｅｐｔｈ］がＳＰＬＩＴ＿ＴＴ＿ＨＯＲまたはＳＰＬＩＴ＿ＴＴ＿ＶＥＲに等しいか、
－ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが３２に等しく、かつＭｔｔＳｐｌｉｔＭｏｄｅ［ｘ０］［ｙ０］［ｍｔｔＤｅｐｔｈ］がＳＰＬＩＴ＿ＢＴ＿ＨＯＲまたはＳＰＬＩＴ＿ＢＴ＿ＶＥＲに等しい。
－それ以外の場合、以下の条件の１つが真であれば、ｍｏｄｅＴｙｐｅＣｏｎｄｉｔｉｏｎは、１＋（ｓｌｉｃｅ＿ｔｙｐｅ！＝Ｉ？１：０）に等しく設定される。
－ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４に等しく、かつＭｔｔＳｐｌｉｔＭｏｄｅ［ｘ０］［ｙ０］［ｍｔｔＤｅｐｔｈ］がＳＰＬＩＴ＿ＢＴ＿ＨＯＲまたはＳＰＬＩＴ＿ＢＴ＿ＶＥＲに等しいか、
－ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが１２８に等しく、かつＭｔｔＳｐｌｉｔＭｏｄｅ［ｘ０］［ｙ０］［ｍｔｔＤｅｐｔｈ］がＳＰＬＩＴ＿ＴＴ＿ＨＯＲまたはＳＰＬＩＴ＿ＴＴ＿ＶＥＲに等しい。
－それ以外の場合、ｍｏｄｅＴｙｐｅＣｏｎｄｉｔｉｏｎは０に等しく設定される。

【0208】

変数ｍｏｄｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが０に等しい場合、それは、現在のコーディングツリーノード内のコーディングユニットが、インター予測コーディングモードのみを使用することができることを指定する。変数ｍｏｄｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しい場合、それは、現在のコーディングツリーノード内のコーディングユニットが、インター予測コーディングモードを使用することはできないことを指定する。

【0209】

ＸＩＩＩ．異なるカラーフォーマット

【0210】

図１４Ａ～１４Ｄは、異なるＹＵＶフォーマットのいくつかの例を示す。ＹＵＶ４：４：４フォーマットに関しては、ＵおよびＶ画像の幅および高さは、Ｙ画像のそれと同じである。ＹＵＶ４：２：２フォーマットに関しては、ＵおよびＶ画像の高さはＹ画像のそれと同じであるが、ＵとＶの画像の幅はＹ画像のそれの半分である。ＹＵＶ４：１：１フォーマットに関しては、ＵおよびＶ画像の高さはＹ画像のそれと同じであるが、ＵとＶの画像の幅はＹ画像のそれの１／４である。ＹＵＶ４：２：０フォーマットに関しては、ＵおよびＶ画像の幅および高さは、Ｙ画像のそれの半分である。

【0211】

ＸＩＶ．多重参照線イントラ予測

【0212】

図１５は、本開示の一実施形態による例示的な多重参照線イントラ予測を示す。多重参照線イントラ予測は、イントラ予測のためにより多くの参照線を使用することができ、エンコーダは、いずれの参照線がイントラ予測子を生成するために使用されるかを決定し、それを示す信号を送信することができる。一例において、参照線０、１、および／または３を使用することができ、参照線２は除外されてもよい。イントラ予測モードの前に参照線インデックスを信号伝達することができ、非ゼロ参照線インデックスが信号伝達されてもよい場合には、最確モードのみが許可される。図１５において、４つの参照線の例が描かれており、各参照線は、左上の参照サンプルとともに、６つのセグメント、すなわち、セグメントＡ～Ｆにより構成されている。さらに、セグメントＡとＦには、それぞれセグメントＢおよびＥから最も近いサンプルがパディングされている。

【0213】

ＸＶ．ローカルデュアルツリーの改善

【0214】

本開示の実施形態は、ローカルデュアルツリーの使用を改善することができる。いくつかの関連する例において、ＳＣＩＰＵは、シングルツリーにおいて２×２、２×４、４×２の小クロマブロックを回避するが、シングルツリーにおいてはローカルデュアルツリーを採用する。しかしながら、ローカルデュアルツリーは実行が難しい場合がある。したがって、ＳＣＩＰＵを変更しても、それに見合う恩恵が得られないことがある。

【0215】

本開示の態様によれば、１つのＳＣＩＰＵ領域内のツリー深さは、閾値Ｔ以下であることがあり、ここで、Ｔは０、１または２などの整数である。Ｔの値は、ＳＣＩＰＵ領域をさらに区分することができる回数を示す。例えば、Ｔが０に等しい場合、それは、ＳＣＩＰＵがさらに区分できないことを意味する。Ｔが１に等しい場合、それは、ＳＣＩＰＵを１回だけ区分してもよいことを意味する。

【0216】

一実施形態において、インター符号化されたＳＣＩＰＵ領域および非インター符号化されたＳＣＩＰＵ領域は、異なる閾値を有してもよい。現在のＳＣＩＰＵ領域内のすべてのＣＵがインター符号化されている場合、現在のＳＣＩＰＵ領域内のツリー深さは閾値Ｔ以下であってもよい。現在のＳＣＩＰＵ領域内のすべてのＣＵが非インター符号化されている場合（例えばイントラ符号化されているか、ＩＢＣ符号化されている）、現在のＳＣＩＰＵ領域内のツリー深さは、閾値Ｔよりも大きくてもよい。すなわち、非インター符号化されたＳＣＩＰＵのツリー深さは、閾値Ｔによって制約されない。この実施形態においては、Ｔは、１または２などの正の整数であることに留意されたい。

【0217】

ＸＶＩ．ローカルデュアルツリーの改善に関するフローチャート

【0218】

図１６は、本開示の一実施形態による例示的なプロセス（１６００）を概説するフローチャートである。様々な実施形態において、プロセス（１６００）は、端末装置（２１０）、（２２０）、（２３０）および（２４０）内の処理回路、ビデオエンコーダ（３０３）の機能を実行する処理回路、ビデオデコーダ（３１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、イントラ予測モジュール（４５２）の機能を実行する処理回路、ビデオエンコーダ（５０３）の機能を実行する処理回路、予測器（５３５）の機能を実行する処理回路、イントラエンコーダ（６２２）の機能を実行する処理回路、イントラデコーダ（７７２）の機能を実行する処理回路、などの処理回路により実行される。一部の実施形態において、プロセス（１６００）はソフトウェア命令で実行され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（１６００）を実行する。

【0219】

プロセス（１６００）は、一般に、プロセス（１６００）が、符号化されたビデオシーケンスの一部である現在の画像の現在のブロックの予測情報を復号するステップ（Ｓ１６１０）で開始されてもよい。予測情報は、現在のブロックに対するシングルパーティションツリー構造およびブロックサイズを示してもよい。次に、プロセス（１６００）は、ステップ（Ｓ１６２０）に進む。

【0220】

ステップ（Ｓ１６２０）において、処理回路（１６００）は、現在のブロックがローカルパーティションツリー構造の親ノードであるか否かを、シングルパーティションツリー構造と現在のブロックのブロックサイズとに基づいて判定する。ローカルパーティションツリー構造のツリー深さは閾値以下である。現在のブロックがローカルパーティションツリー構造の親ノードであると判定されると、プロセス（１６００）はステップ（Ｓ１６３０）に進む。

【0221】

ステップ（Ｓ１６３０）において、プロセス（１６００）は、現在のブロックがローカルパーティションツリー構造の親ノードであることに応じて、ローカルパーティションツリー構造に従って現在のブロックを分割する。一実施形態において、プロセス（１６００）は、現在のブロックがローカルパーティションツリー構造の親ノードであることと、およびツリー深さがある値（例えば０）であることとに応じて、ローカルパーティションツリー構造に従って現在のブロックを分割する。次に、プロセス（１６００）は、ステップ（Ｓ１６４０）に進む。

【0222】

ステップ（Ｓ１６４０）において、プロセス（１６００）は、現在のブロックの予測モードに基づいて現在のブロックを再構築する。

【0223】

現在のブロックを再構築した後、プロセス（１６００）は終了する。

【0224】

一実施形態において、現在のブロックの予測モードは、（ｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が四分木であること、または（ｉｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が三分木であること、および（ｉｉｉ）ブロックサイズが３２サンプルであり、ローカルパーティションツリー構造が二分木であることの３つの条件のうち、１つが満たされる場合、非インター予測であると判定される。

【0225】

一実施形態において、現在のブロックの予測モードの判定は、（ｉ）ブロックサイズが６４サンプルであり、ローカルパーティションツリー構造が二分木であることと、（ｉｉ）ブロックサイズが１２８サンプルであり、ローカルパーティションツリー構造が三分木であることとの２つの条件のうち、１つが満たされる場合、予測情報に含まれるシグナル伝達されたフラグに基づき判定される。

【0226】

一実施形態において、閾値は、現在のブロックがインター符号化されていれば第１の閾値であり、現在のブロックが非インター符号化されていれば第２の閾値である。第１の閾値は、第２の閾値とは異なってもよい。

【0227】

一実施形態において、プロセス（１６００）は、現在のブロックがローカルパーティションツリー構造の親ノードであると判定された場合、現在のブロックをＳＣＩＰＵであると判定する。

【0228】

一実施形態において、プロセス（１６００）は、現在のブロックの予測モードが判定されたか否かに基づいて、現在のブロックを分割する。例えば、表８に示す例示的な仕様に一条件を追加することで、閾値を１に設定することができる。追加された条件は、表９に示すように、「ｍｏｄｅＴｙｐｅＣｕｒｒ＝＝Ｍｏｄｅ＿ＴＹＰＥ＿ＡＬＬ」であってもよい。初期分割に対しては、現在のブロックの予測モードが判定されていないため、追加された条件「ｍｏｄｅＴｙｐｅＣｕｒｒ＝＝Ｍｏｄｅ＿ＴＹＰＥ＿ＡＬＬ」は満たすことができる。他の条件も満たされていれば、初期分割を実行してもよい。初期分割の後、現在のブロックの予測モードが判定されるため、追加された条件「ｍｏｄｅＴｙｐｅＣｕｒｒ＝＝Ｍｏｄｅ＿ＴＹＰＥ＿ＡＬＬ」は満たされない。他の条件は満たされているが、第２の分割を実行することはできない。したがって、追加された条件「ｍｏｄｅＴｙｐｅＣｕｒｒ＝＝Ｍｏｄｅ＿ＴＹＰＥ＿ＡＬＬ」の結果として、ローカルパーティションツリー構造のツリー深さが、１に設定されている閾値によって制約されることがある。

【0229】

一実施形態において、プロセス（１６００）は、現在のブロックがインター符号化されているか否かに基づいて、現在のブロックを分割する。例えば、表８に示す例示的な仕様に別の条件を追加することで、閾値を１に設定することができる。追加された条件は、表１０に示すように、「ｍｏｄｅＴｙｐｅＣｕｒｒ！＝Ｍｏｄｅ＿ＴＹＰＥ＿ＩＮＴＥＲ」であってもよい。初期分割に関しては、現在のブロックの予測モードが判定されていないため、追加された条件「ｍｏｄｅＴｙｐｅＣｕｒｒ！＝Ｍｏｄｅ＿ＴＹＰＥ＿ＩＮＴＥＲ」を満たすことができる。他の条件も満たされていれば、初期分割を行ってもよい。初期分割の後、現在のブロックの予測モードが判定される。現在のブロックの予測モードがインター予測であると判定された場合、「ｍｏｄｅＴｙｐｅＣｕｒｒ！＝Ｍｏｄｅ＿ＴＹＰＥ＿ＩＮＴＥＲ」という条件は満たされない。他の条件は満たされているが、第２の分割を行うことはできない。したがって、追加された条件「ｍｏｄｅＴｙｐｅＣｕｒｒ！＝Ｍｏｄｅ＿ＴＹＰＥ＿ＩＮＴＥＲ」の結果として、ローカルパーティションツリー構造のツリー深さは、現在のブロックの予測モードがインター予測の場合、１に設定された閾値によって制約されることがある。

【表9A】

【表9B】

【表9C】

【表9D】

【表10A】

【表10B】

【表10C】

【表10D】

【0230】

ＸＶＩＩ．コンピュータシステム

【0231】

本明細書において提示された方法は、別々に使用してもよいし、任意の順序で組み合わせてもよい。さらに、実施形態、エンコーダ、およびデコーダのそれぞれは、処理回路（例えば、１つまたは複数のプロセッサ、または１つまたは複数の集積回路）によって動作させてもよい。一例として、１つまたは複数のプロセッサは、非一時的なコンピュータ可読媒体に保存されたプログラムを実行する。

【0232】

上述の技術は、コンピュータ可読命令を用いた、１つ以上のコンピュータ可読媒体に物理的に保存されたコンピュータソフトウェアとして実行されてもよい。
例えば、図１７は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム（１７００）を示す。

【0233】

コンピュータソフトウェアは、任意の適切な機械コードまたはコンピュータ言語を使用して符号化されてもよく、それは、１つ以上のコンピュータ中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）などによって、直接、または、解釈、マイクロコードの実行などにより実行することができる命令を含むコードを作成するために、アセンブリ、コンパイル、リンクなどのメカニズムを施されてもよい。

【0234】

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

【0235】

コンピュータシステム（１７００）のための図１７に示す構成要素は、本質的に例示的なものであり、本開示の実施形態を実行するコンピュータソフトウェアの使用または機能の範囲に関して、いかなる制限の示唆も意図されていない。また、構成要素の構成は、コンピュータシステム（１７００）の例示的な実施形態に図示されている構成要素のいずれか１つまたはその組み合わせに関連する依存性または要求を有するものとは解釈されないものとする。

【0236】

コンピュータシステム（１７００）は、特定のヒューマンインターフェース入力デバイスを含んでもよい。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スワイプ、データグローブの動き）、音声入力（例えば、声、拍手）、視覚入力（例えばジェスチャー）、嗅覚入力（図示せず）などを介して、１人または複数の人間のユーザによる入力に反応するものであってもよい。ヒューマンインターフェースデバイスは、音声（スピーチ、音楽、周囲の音など）、画像（スキャンした画像、静止画カメラで撮影した写真画像など）、ビデオ（二次元ビデオ、立体ビデオを含む三次元ビデオなど）など、人間による意識的な入力に必ずしも直接に関係しない特定のメディアをキャプチャするために用いてもよい。

【0237】

入力用ヒューマンインターフェースデバイスは、キーボード（１７０１）、マウス（１７０２）、トラックパッド（１７０３）、タッチスクリーン（１７１０）、データグローブ（図示せず）、ジョイスティック（１７０５）、マイクロフォン（１７０６）、スキャナ（１７０７）、カメラ（１７０８）のうちの１つまたは複数（それぞれ１つのみが図示されている）を含んでもよい。

【0238】

また、コンピュータシステム（１７００）は、特定のヒューマンインターフェース出力デバイスを含んでもよい。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および匂い／味を介して、１人または複数の人間のユーザの感覚を刺激するものであってもよい。そのようなヒューマンインターフェース出力デバイスに含まれてもよいものとしては、触覚出力デバイス（例えば、タッチスクリーン（１７１０）による触覚フィードバック）、データグローブ（図示せず）、またはジョイスティック（１７０５）などであるが、入力デバイスとして機能しない触覚フィードバックデバイスもあってもよい）、音声出力装置（例えば、スピーカー（１７０９））、ヘッドフォン（図示せず）、視覚出力デバイス（ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンなどのスクリーン（１７１０）であって、それぞれタッチスクリーン入力機能を有する、または有しないもの、かつ触覚フィードバック機能を有する、または有しないもの、などであり、ここで、そのうちの一部は、二次元視覚出力、または立体画法出力などの手段による三次元以上の出力を出力することができてもよいもの、さらに仮想現実ゴーグル（描かれていない）、ホログラフィックディスプレイ、スモークタンク（描かれていない））、およびプリンタ（描かれていない）などがある。（スクリーン（１７１０）などの）これらの視覚出力デバイスは、グラフィックスアダプタ（１７５０）を介してシステムバス（１７４８）に接続されてもよい。

【0239】

また、コンピュータシステム（１７００）は、ＣＤ／ＤＶＤなどのメディア（１７２１）を備えたＣＤ／ＤＶＤ ＲＯＭ／ＲＷ（１７２０）を含む光学メディア、サムドライブ（１７２２）、リムーバブルハードドライブまたはソリッドステートドライブ（１７２３）、テープやフロッピーディスクなどのレガシー磁気メディア（描かれていない）、セキュリティドングル（描かれていない）などの特殊なＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイスなど、人間がアクセス可能な記憶装置およびそれらに関連付けられたメディアを含んでもよい。

【0240】

また、当業者には、本願において開示された主題に関連して使用される用語「コンピュータ可読媒体」が、伝送媒体、搬送波、または他の一過性の信号を包含しないことは周知のことである。

【0241】

また、コンピュータシステム（１７００）は、１つまたは複数の通信ネットワーク（１７５５）へのネットワークインターフェース（１７５４）を含んでもよい。１つ以上の通信ネットワーク（１７５５）は、例えば、無線式、有線式、光学式であってもよい。１つ以上の通信ネットワーク（１７５５）はさらに、ローカルエリア、ワイドエリア、メトロポリタン エリア、車両および産業用、実時間型、遅延耐性型などであってもよい。１つ以上の通信ネットワーク（１７５５）の例としては、イーサネットなどのローカルエリアネットワーク、無線ＬＡＮ、ならびにＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどのセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、地上波放送ＴＶなどのＴＶ有線または無線広域デジタルネットワーク、ＣＡＮＢｕｓなどの車両および産業用ネットワークなどが挙げられる。特定の汎用データポートまたは周辺バス（１７４９）（例えば、コンピュータシステム（１７００）のＵＳＢポート）に接続される外部ネットワークインターフェースアダプタを必要とするのが一般的である特定のネットワークがあり、また、後述のシステムバス（例えば、ＰＣコンピュータシステムに組み込まれるイーサネットインターフェースや、スマートフォンコンピュータシステムに組み込まれるセルラーネットワークインターフェースなど）に取り付けることでコンピュータシステム（１７００）のコアに組み込まれるのが一般的であるネットワークもある。これらのネットワークのいずれかを使用して、コンピュータシステム（１７００）は、他のエンティティと通信することができる。このような通信は、単一方向受信のみのもの（例えば、テレビ放送）、単一方向送信のみのもの（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、または、例えばローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムとの双方向性のものであってもよい。特定のプロトコルやプロトコルスタックは、前述のようにそれらのネットワークやネットワークインターフェースのそれぞれにおいて使用されてもよい。

【0242】

前述のヒューマンインターフェースデバイス、ヒューマンアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム（１７００）のコア（１７４０）に取り付けられてもよい。

【0243】

コア（１７４０）は、１つまたは複数の中央処理装置（ＣＰＵ）（１７４１）、グラフィックスプロセッシングユニット（ＧＰＵ）（１７４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）の形態の特殊なプログラム可能処理装置（１７４３）、特定のタスクのためのハードウェアアクセラレータ（１７４４）などを含んでもよい。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）（１７４５）、ランダムアクセスメモリ（１７４６）、ユーザがアクセスできない内蔵ハードドライブ、ＳＳＤなどの内蔵大容量記憶装置（１７４７）とともに、システムバス（１７４８）を介して接続されてもよい。一部のコンピュータシステムにおいて、システムバス（１７４８）は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするために、１つまたは複数の物理的なプラグの形でアクセス可能であってもよい。周辺機器は、コアのシステムバス（１７４８）に直接に、または周辺バス（１７４９）を介して取り付けることができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢなどを含む。

【0244】

ＣＰＵ（１７４１）、ＧＰＵ（１７４２）、ＦＰＧＡ（１７４３）、およびアクセラレータ（１７４４）は、組み合わされて前述のコンピュータコードを構成することができる特定の命令を実行してもよい。そのコンピュータコードは、ＲＯＭ（１７４５）またはＲＡＭ（１７４６）に格納されていてもよい。また、暫定的なデータは、ＲＡＭ（１７４６）に保存されてもよく、一方、永続的なデータは、例えば、内蔵大容量記憶装置（１７４７）に保存されてもよい。記憶装置のいずれかへの高速な記憶およびそれからの取り出しは、ＣＰＵ（１７４１）、ＧＰＵ（１７４２）、大容量記憶装置（１７４７）、ＲＯＭ（１７４５）、ＲＡＭ（１７４６）の少なくとも１つに密接に関連し得るキャッシュメモリの使用によって可能になり得る。

【0245】

コンピュータ可読媒体は、コンピュータが実行する様々な演算を実行するためのコンピュータコードを有してもよい。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってもよく、あるいはコンピュータソフトウェアの技術に精通した者によく知られ、かつ利用可能な種類のものであってもよい。

【0246】

非限定的な一例として、アーキテクチャ（１７００）、特にコア（１７４０）を有するコンピュータシステムは、プロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）が１つまたは複数の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行することによる機能性を提供することができる。このようなコンピュータ可読媒体は、上で紹介したようなユーザアクセス可能な大容量記憶装置、およびコア内部大容量記憶装置（１７４７）またはＲＯＭ（１７４５）などの、非一時的な性質を有するコア（１７４０）の特定の記憶装置に関連する媒体であってもよい。本開示の様々な実施形態を実行するソフトウェアは、そのようなデバイスに格納され、コア（１７４０）によって実行されてもよい。コンピュータ可読媒体は、特定のニーズに応じて、１つまたは複数のメモリデバイスまたはチップを含んでもよい。ソフトウェアは、コア（１７４０）および特にその中の処理装置（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ（１７４６）に保存されたデータ構造を定義すること、およびそのようなデータ構造をソフトウェアによって定義されたプロセスに従って変更することを含む、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。
追加または代替として、コンピュータシステムは、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアとともに動作することができる回路（例えば、アクセラレータ（１７４４））にハードワイヤードの方式で、またはその他の方式で具現化された論理の結果として機能性を提供することができる。ソフトウェアとは、論理を包含してもよく、また場合により、その逆であってもよい。本願において、コンピュータ可読媒体とは、実行のためのソフトウェアを格納した回路（集積回路（ＩＣ）など）、実行のための論理を具現化した回路、または場合によりその両方を含んでもよい。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含する。

【0247】

本開示では、一部の例示的な実施形態を説明してきたが、本開示の範囲内にある、変更、変形、および様々な代替的な等価物が存在する。したがって、当業者は、本明細書に明示的に示されていない、または記載されていないが、本開示の原理を具現化し、したがってその趣旨および範囲内にある多数のシステムおよび方法に想到することができることが理解されるであろう。

【0248】

付録Ａ：頭字語
ＡＭＶＰ：Ａｄｖａｎｃｅｄ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ （高度動きベクトル予測）
ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ－Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ（特定用途向け集積回路）
ＡＴＭＶＰ：Ａｌｔｅｒｎａｔｉｖｅ／Ａｄｖａｎｃｅｄ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ（代替／高度時間動きベクトル予測）
ＢＤＯＦ：Ｂｉ－ｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｃａｌ Ｆｌｏｗ（双方向オプティカルフロー）
ＢＤＰＣＭ（またはＲＤＰＣＭ）Ｒｅｓｉｄｕａｌ Ｄｉｆｆｅｒｅｎｃｅ Ｐｕｌｓｅ Ｃｏｄｅｄ Ｍｏｄｕｌａｔｉｏｎ（残余パルス符号化変調）
ＢＩＯ： Ｂｉ－ｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｃａｌ Ｆｌｏｗ（双方向オプティカルフロー）
ＢＭＳ： Ｂｅｎｃｈｍａｒｋ Ｓｅｔ（ベンチマークセット）
ＢＴ： Ｂｉｎａｒｙ Ｔｒｅｅ（二分木）
ＢＶ：Ｂｌｏｃｋ Ｖｅｃｔｏｒ（ブロックベクトル）
ＣＡＮＢｕｓ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｂｕｓ（コントローラエリアネットワークバス）
ＣＢ： Ｃｏｄｉｎｇ Ｂｌｏｃｋ（コーディングブロック）
ＣＢＦ：Ｃｏｄｅｄ Ｂｌｏｃｋ Ｆｌａｇ（符号化されたブロックフラグ）
ＣＣＬＭ：Ｃｒｏｓｓ－Ｃｏｍｐｏｎｅｎｔ Ｌｉｎｅａｒ Ｍｏｄｅ／Ｍｏｄｅｌ（クロス成分リニアモード／モデル）
ＣＤ： Ｃｏｍｐａｃｔ Ｄｉｓｃ （コンパクトディスク）
ＣＰＲ： Ｃｕｒｒｅｎｔ Ｐｉｃｔｕｒｅ Ｒｅｆｅｒｅｎｃｉｎｇ（現在画像参照）
ＣＰＵ： Ｃｕｒｒｅｎｔ Ｐｉｃｔｕｒｅ Ｒｅｆｅｒｅｎｃｉｎｇ（中央画像参照）
ＣＲＴ：Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ（陰極線管）
ＣＴＢ：Ｃｏｄｉｎｇ Ｔｒｅｅ Ｂｌｏｃｋ（コーディングツリーブロック）
ＣＴＵ： Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔｓ（コーディングツリーユニット）
ＣＵ： Ｃｏｄｉｎｇ Ｕｎｉｔ （コーディングユニット）
ＤＭ： Ｄｅｒｉｖｅｄ Ｍｏｄｅ（派生モード）
ＤＰＢ：Ｄｅｃｏｄｅｒ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒデコーダ画像バッファ
ＤＶＤ： Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ （デジタルビデオディスク）
ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｅａｓ（フィールドプログラマブルゲートエリア）
ＧＯＰ： Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ （画像群）
ＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（グラフィックスプロセッシングユニット）
ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（汎欧州デジタル移動電話方式）
ＨＤＲ：Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ（ハイダイナミックレンジ）
ＨＥＶＣ：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（高効率ビデオ符号化）
ＨＲＤ：Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ（仮想参照デコーダ）
ＩＢＣ： Ｉｎｔｒａ Ｂｌｏｃｋ Ｃｏｐｙ（イントラブロックコピー）
ＩＣ：Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ（集積回路）
ＩＳＰ：Ｉｎｔｒａ Ｓｕｂ－Ｐａｒｔｉｔｉｏｎｓ（イントラサブパーティション）
ＪＥＭ：Ｊｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅｌ（共同検証モデル）
ＪＶＥＴ： Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ（共同ビデオ検証チーム）
ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ローカルエリアネットワーク）
ＬＣＤ：Ｌｉｑｕｉｄ－Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ（液晶ディスプレイ）
ＬＦＮＳＴ：Ｌｏｗ Ｆｒｅｑｕｅｎｃｙ Ｎｏｎ－Ｓｅｐａｒａｂｌｅ Ｔｒａｎｓｆｏｒｍ（低周波非分離変換）
ＬＴＥ： Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ロングタームエボリューション））
Ｌ＿ＣＣＬＭ： Ｌｅｆｔ－Ｃｒｏｓｓ－Ｃｏｍｐｏｎｅｎｔ Ｌｉｎｅａｒ Ｍｏｄｅ／Ｍｏｄｅｌ（左クロス成分リニアモード／モデル）
ＬＴ＿ＣＣＬＭ： Ｌｅｆｔ ａｎｄ Ｔｏｐ Ｃｒｏｓｓ－Ｃｏｍｐｏｎｅｎｔ Ｌｉｎｅａｒ Ｍｏｄｅ／Ｍｏｄｅｌ（左／上方クロス成分リニアモード／モデル）
ＭＩＰ： Ｍａｔｒｉｘ ｂａｓｅｄ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ（マトリックスベースイントラ予測）
ＭＰＭ： Ｍｏｓｔ Ｐｒｏｂａｂｌｅ Ｍｏｄｅ（最確モード）
ＭＲＬＰ （または ＭＲＬ）： Ｍｕｌｔｉｐｌｅ Ｒｅｆｅｒｅｎｃｅ Ｌｉｎｅ Ｐｒｅｄｉｃｔｉｏｎ （多重参照線予測）
ＭＴＳ： マルチトランスフォームセレクション
ＭＶ：Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ（動きベクトル）
ＯＬＥＤ： Ｏｒｇａｎｉｃ Ｌｉｇｈｔ－Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ（有機発光ダイオード）
ＰＢｓ： Ｐｒｅｄｉｃｔｉｏｎ Ｂｌｏｃｋｓ（予測ブロック）
ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（周辺機器相互接続）
ＰＤＰＣ： Ｐｏｓｉｔｉｏｎ Ｄｅｐｅｎｄｅｎｔ Ｐｒｅｄｉｃｔｉｏｎ Ｃｏｍｂｉｎａｔｉｏｎ（位置依存予測組合せ）
ＰＬＤ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ（プログラマブルロジックデバイス）
ＰＰＲ： Ｐａｒａｌｌｅｌ－Ｐｒｏｃｅｓｓａｂｌｅ Ｒｅｇｉｏｎ（並列処理可能領域）
ＰＵ： Ｐｒｅｄｉｃｔｉｏｎ Ｕｎｉｔ（予測ユニット）
ＱＴ：Ｑｕａｄ－Ｔｒｅｅ（四分木）
ＲＡＭ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ランダムアクセスメモリ）
ＲＯＭ： Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ（リードオンリーメモリ
ＳＢＴ：Ｓｕｂ－ｂｌｏｃｋ Ｔｒａｎｓｆｏｒｍ（サブブロック変換）
ＳＣＣ：Ｓｃｒｅｅｎ Ｃｏｎｔｅｎｔ Ｃｏｄｉｎｇ（スクリーンコンテンツコーディング）
ＳＣＩＰＵ： Ｓｍａｌｌ Ｃｈｒｏｍａ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ Ｕｎｉｔ（小クロマイントラ予測ユニット）
ＳＤＲ：Ｓｔａｎｄａｒｄ Ｄｙｎａｍｉｃ Ｒａｎｇｅ（スタンダードダイナミックレンジ）
ＳＥＩ：Ｓｕｐｐｌｅｍｅｎｔａｒｙ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ（補足強化情報）
ＳＮＲ：Ｓｉｇｎａｌ Ｎｏｉｓｅ Ｒａｔｉｏ（シグナルノイズ比）
ＳＳＤ：Ｓｏｌｉｄ－ｓｔａｔｅ Ｄｒｉｖｅ（ソリッドステートドライブ）
ＴＴ： Ｔｅｒｎａｒｙ Ｔｒｅｅ（三分木）
ＴＵ： Ｔｒａｎｓｆｏｒｍ Ｕｎｉｔ（変換ユニット）
Ｔ＿ＣＣＬＭ： Ｔｏｐ Ｃｒｏｓｓ－Ｃｏｍｐｏｎｅｎｔ Ｌｉｎｅａｒ Ｍｏｄｅ／Ｍｏｄｅｌ（上方クロス成分リニアモード／モデル）
ＵＳＢ： Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ユニバーサルシリアルバス）
ＶＰＤＵ：Ｖｉｓｕａｌ Ｐｒｏｃｅｓｓ Ｄａｔａ Ｕｎｉｔ（ビジュアルプロセスデータユニット）
ＶＵＩ： Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ビデオユーザビリティ情報
ＶＶＣ：Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（多用途ビデオ符号化）
ＷＡＩＰ：Ｗｉｄｅ－Ａｎｇｌｅ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ（広角イントラ予測）

【符号の説明】

【0249】

１０１ 点
１０２ 矢印
１０３ 矢印
１０４ ブロック
１１１ ブロック
２００ 通信システム
２１０ 端末装置
２２０ 端末装置
２３０ 端末装置
２４０ 端末装置
２５０ 通信ネットワーク

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9A】

【図9B】

【図10】

【図11A】

【図11B】

【図11C】

【図11D】

【図11E】

【図12】

【図13A】

【図13B】

【図14】

【図15】

【図16】

【図17】