特許 7405925 ビデオ・エンコーダ、ビデオ・デコーダ及び対応する方法

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

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

(11)【特許番号】

(24)【登録日】2023-12-18

(45)【発行日】2023-12-26

(54)【発明の名称】ビデオ・エンコーダ、ビデオ・デコーダ及び対応する方法

(51)【国際特許分類】

   H04N 19/119 20140101AFI20231219BHJP

   H04N 19/136 20140101ALI20231219BHJP

   H04N 19/167 20140101ALI20231219BHJP

   H04N 19/176 20140101ALI20231219BHJP

   H04N 19/70 20140101ALI20231219BHJP

【ＦＩ】

H04N19/119

H04N19/136

H04N19/167

H04N19/176

H04N19/70

【請求項の数】 22

【外国語出願】

(21)【出願番号】P 2022151192

(22)【出願日】2022-09-22

(62)【分割の表示】P 2021512205の分割

【原出願日】2019-09-03

(65)【公開番号】P2022188121

(43)【公開日】2022-12-20

【審査請求日】2022-10-21

(31)【優先権主張番号】62/726,423

(32)【優先日】2018-09-03

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

(31)【優先権主張番号】62/818,996

(32)【優先日】2019-03-15

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

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ガオ，ハン

(72)【発明者】

【氏名】エセンリク，セミ

(72)【発明者】

【氏名】チェン，ジエンローァ

(72)【発明者】

【氏名】ジャオ，ジージエ

(72)【発明者】

【氏名】コトラ，アナンド メハー

(72)【発明者】

【氏名】ワーン，ビヤオ

【審査官】岩井 健二

(56)【参考文献】

【文献】Han Gao, et al.，CE1-2.0.11: Picture Boundary Handling，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K0287-v1，11th Meeting: Ljubljana, SI，2018年07月，pp.1-7

【文献】Benjamin Bross, Jianle Chen, and Shan Liu，Versatile Video Coding (Draft 2)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K1001 (version 4)，11th Meeting: Ljubljana, SI，2018年08月，pp.17-19,23,25,33-37

【文献】Jianle Chen, Yan Ye, and Seung Hwan Kim，Algorithm description for Versatile Video Coding and Test Model 2 (VTM 2)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K1002-v1，11th Meeting: Ljubljana, SI，2018年08月，pp.1-8

【文献】Han Gao, et al.，Non-CE1: Relation Between QT/BT/TT Split Constraint Syntax Elements，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-L0217，12th Meeting: Macao, CN，2018年10月，pp.1-3

【文献】Han Gao, et al.，Non-CE1: Overriding QT/BT/TT Split Constraint Syntax Elements，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-L0218，12th Meeting: Macao, CN，2018年10月，pp.1-2

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

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

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

【請求項1】

コーディング方法であって、
現在ブロックのそのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するステップ；
前記現在ブロックのサイズが前記最小許容四分木リーフ・ノード・サイズより大きくないという条件の下で、最大許容三分木ルート・ノード・サイズに基づいて、三分木分割を前記現在ブロックに適用するステップであって、前記最大許容三分木ルート・ノード・サイズは、前記最小許容四分木リーフ・ノード・サイズに基づいて決定され、前記最小許容四分木リーフ・ノード・サイズは、前記最大許容三分木ルート・ノード・サイズより大きくない、ステップ；
を含むコーディング方法。

【請求項2】

請求項１に記載の方法において、前記現在ブロックは非境界ブロックである、方法。

【請求項3】

請求項１又は２に記載の方法において、
画像をブロックに分割するステップであって、前記ブロックは前記現在ブロックを含む、ステップを更に含み、
前記三分木分割を前記現在ブロックに適用するステップは、
最終的な最大マルチタイプ・ツリー深度を有する、前記ブロックの前記現在ブロックに、三分木分割を適用するステップであって、前記最終的な最大マルチタイプ・ツリー深度は、少なくとも最大マルチタイプ・ツリー深度と最大マルチタイプ・ツリー深度オフセットとの合計である、ステップ；
を含む、方法。

【請求項4】

請求項３に記載の方法において、前記最大マルチタイプ・ツリー深度オフセットは０である、方法。

【請求項5】

請求項３又は４に記載の方法において、前記最大マルチタイプ・ツリー深度は０より大きい、方法。

【請求項6】

請求項１ないし５のうちの何れか１項に記載の方法において、前記方法は符号化デバイスにより実行され、前記方法は、更に：
前記現在ブロックをビットストリームに符号化するステップ；
を含む方法。

【請求項7】

請求項６に記載の方法において、前記方法は、更に：
第１のシンタックス要素と第２のシンタックス要素を前記ビットストリームに符号化するステップであって、前記第１のシンタックス要素は前記最小許容四分木リーフ・ノード・サイズを導出するために使用され、前記第２のシンタックス要素は前記最大許容三分木ルート・ノード・サイズを導出するために使用される、ステップ；
を含む方法。

【請求項8】

請求項７に記載の方法において、前記第１のシンタックス要素と前記第２のシンタックス要素は、シーケンス・パラメータ・セット（SPS）でシグナリングされる、方法。

【請求項9】

請求項６ないし８のうちの何れか１項に記載の方法において、前記方法は、更に：
前記ビットストリームを送信するステップ；
を含む方法。

【請求項10】

請求項１ないし５のうちの何れか１項に記載の方法において、前記方法は復号化デバイスにより実行され、前記方法は、更に：
１つ以上の画像の符号化されたデータと、第１のシンタックス要素と、第２のシンタックス要素とを含むビットストリームを受信するステップ；
を含む方法。

【請求項11】

請求項１０に記載の方法において、前記方法は、更に：
前記ビットストリームからの前記第１のシンタックス要素を解析するステップ；
前記第１のシンタックス要素に基づいて、前記最小許容四分木リーフ・ノード・サイズを導出するステップ；
を含む方法。

【請求項12】

請求項１０又は１１に記載の方法において、前記方法は、更に：
前記ビットストリームからの前記第２のシンタックス要素を解析するステップ；
前記第２のシンタックス要素に基づいて、前記最大許容三分木ルート・ノード・サイズを導出するステップ；
を含む方法。

【請求項13】

請求項１０ないし１２のうちの何れか１項に記載の方法において、前記方法は、更に：
表示のために再構成されたビデオを生成するために、前記第１のシンタックス要素と前記第２のシンタックス要素に基づいて前記ビットストリームを復号化するステップ；
を含む方法。

【請求項14】

請求項１ないし１３のうちの何れか１項に記載の方法を実行する処理回路を含むコーディング・デバイス。

【請求項15】

コーディング・デバイスにおいて：
１つ以上のプロセッサ；及び
前記１つ以上のプロセッサに結合され且つ前記１つ以上のプロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体であって、前記プログラミングは、前記１つ以上のプロセッサにより実行される場合に、請求項１－１３のうちの何れか１項に記載の方法を実行するように前記コーディング・デバイスを構成する、記憶媒体；
含むコーディング・デバイス。

【請求項16】

コンピュータ又はプロセッサにおいて実行された場合に請求項１－１３のうちの何れか１項に記載の方法を実行するためのプログラム・コードを含むコンピュータ・プログラム。

【請求項17】

コンピュータ・デバイスにより実行された場合に請求項１－１３のうちの何れか１項に記載の方法を前記コンピュータ・デバイスに実行させるプログラム・コードを記憶する非一時的なコンピュータ読み取り可能な記憶媒体。

【請求項18】

ビデオ・ビットストリームを復号化する装置であって、前記装置は：
現在ブロックのそのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するように構成された決定ユニット；
前記現在ブロックのサイズが前記最小許容四分木リーフ・ノード・サイズより大きくないという条件の下で、最大許容三分木ルート・ノード・サイズに基づいて、三分木分割を前記現在ブロックに適用するように構成された分割ユニットであって、前記最大許容三分木ルート・ノード・サイズは、前記最小許容四分木リーフ・ノード・サイズに基づいて決定され、前記最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない、分割ユニット；
を含む装置。

【請求項19】

請求項１８に記載の装置において、前記装置は、請求項２ないし５及び１０ないし１３のうちの何れか１項に記載の方法を実行するように更に構成されている、装置。

【請求項20】

ビデオ・ビットストリームを符号化する装置であって、前記装置は：
現在ブロックのそのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するように構成された決定ユニット；
前記現在ブロックのサイズが前記最小許容四分木リーフ・ノード・サイズより大きくないという条件の下で、最大許容三分木ルート・ノード・サイズに基づいて、三分木分割を前記現在ブロックに適用するように構成された分割ユニットであって、前記最大許容三分木ルート・ノード・サイズは、前記最小許容四分木リーフ・ノード・サイズに基づいて決定され、前記最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない、分割ユニット；
を含む装置。

【請求項21】

請求項２０に記載の装置において、前記装置は、請求項２ないし９のうちの何れか１項に記載の方法を実行するように更に構成されている、装置。

【請求項22】

ビデオ又は画像ビットストリームを記憶及び復号化するデバイスであって、通信インターフェースと、プロセッサと、記憶媒体とを含み、前記通信インターフェースは、ビットストリームを受信及び／又は送信するように構成されており、前記記憶媒体は、前記ビットストリームを記憶するように構成されており、前記ビットストリームは、１つ以上の画像の符号化されたデータと、最小許容四分木リーフ・ノード・サイズを導出するための第１のシンタックス要素と、前記最小許容四分木リーフ・ノード・サイズに基づいて最大許容三分木ルート・ノード・サイズを導出するための第２のシンタックス要素とを含んでおり；前記最小許容四分木リーフ・ノード・サイズは、前記最大許容三分木ルート・ノード・サイズより大きくはなく、
前記プロセッサは、前記ビットストリームを復号化して前記第１のシンタックス要素と第２のシンタックス要素を取得し、
前記プロセッサは、更に、前記第１のシンタックス要素に基づいて最小許容四分木リーフ・ノード・サイズを導出し、前記第２のシンタックス要素と前記最小許容四分木リーフ・ノード・サイズとに基づいて最大許容三分木ルート・ノード・サイズを導出し、
前記プロセッサは、更に、現在ブロックのサイズが前記最小許容四分木リーフ・ノード・サイズより大きくないという条件の下で、前記最大許容三分木ルート・ノード・サイズに基づいて、三分木分割を前記現在ブロックに適用する、デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本願の実施態様は、一般に、ビデオ・コーディングの分野に関連し、より具体的にはコーディング・ユニット分割及びパーティショニングに関連する。

【背景技術】

【0002】

ビデオ・コーディング（ビデオ符号化及び復号化）は、幅広いデジタル・ビデオ・アプリケーションにおいて、例えば放送用デジタルＴＶ、インターネットやモバイル・ネットワークを介したビデオ伝送、ビデオ・チャットのようなリアルタイム会話アプリケーション、ビデオ会議、ＤＶＤ及びブルーレイ・ディスク、ビデオ・コンテンツ捕捉編集システム、及びセキュリティ・アプリケーションのカムコーダにおいて使用される。

【0003】

１９９０年のＨ．２６１規格におけるブロック・ベースのハイブリッド・ビデオ・コーディング・アプローチの開発により、新たなビデオ・コーディング技術及びツールが開発されており、新たなビデオ・コーディング規格の基礎を築いている。更なるビデオ・コーディング規格は、ＭＰＥＧ－１ビデオ、ＭＰＥＧ－２ビデオ、ＩＴＵ－Ｔ Ｈ．２６２／ＭＰＥＧ－２、ＩＴＵ－Ｔ Ｈ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４ Ｐａｒｔ１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）、ＩＴＵ－Ｔ Ｈ．２６５／高効率ビデオ・コーディング（ＨＥＶＣ）、ＩＴＵ－Ｔ Ｈ．２６６／汎用ビデオ・コーディング（ＶＶＣ）及び拡張、例えばそのような規格のスケーラビリティ及び／又は三次元（３Ｄ）拡張を含む。ビデオの制作及び利用が益々普及するにつれて、ビデオ・トラフィックは、通信ネットワーク及びデータ・ストレージにとって最大の負担であり、従って、多くのビデオ・コーディング規格の目的の１つは、以前のものと比較して、画質を犠牲にすることなくビット・レート削減を達成することであった。最新の高効率ビデオ・コーディング（ＨＥＶＣ）は、画質を犠牲にすることなく、ＡＶＣの約２倍でビデオを圧縮することが可能であるが、それでも、ＨＥＶＣと比較してビデオを更に圧縮するための新たな技術が熱望されている。

【0004】

比較的短いビデオでさえ描写するために必要とされるビデオ・データの量は、相当なものである可能性があり、データが、限られた帯域幅容量を有する通信ネットワークを介してストリーミングされるか又は別の方法で通信される場合には、困難を生じる可能性がある。従って、ビデオ・データは、一般に、今日の電気通信ネットワークを介して通信される前に圧縮される。また、ビデオがストレージ・デバイスに記憶される場合には、メモリ・リソースが制限される可能性があるので、ビデオのサイズも問題となる可能性がある。ビデオ圧縮デバイスは、しばしば、伝送又は記憶の前にビデオ・データをコーディング化するためにソースにおいてソフトウェア及び/又はハードウェアを使用し、それによってデジタル・ビデオ画像を表すのに必要なデータ量を減少させる。次いで、圧縮されたデータは、ビデオ・データを復号化するビデオ非圧縮デバイスによって宛先で受信される。限られたネットワーク・リソース及びより高いビデオ品質の絶え間なく増進する要請により、画像品質にほとんど犠牲を払わずに圧縮率を改善する改良された圧縮及び非圧縮技術が望まれる。

【発明の概要】

【0005】

本願(又は本開示)の実施形態は、独立請求項により符号化及び復号化するための装置及び方法を提供する。上記及び他の目的は、独立請求項の対象事項によって達成される。更なる実装形式は、従属請求項、明細書及び図面から明らかである。

【0006】

第１態様によれば、本発明は、ビデオ復号化方法に関連する。方法は復号化デバイスによって実行される。方法は、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するステップと、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用するステップとを含み、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない。

【0007】

現在ブロックは、画像又はコーディング・ツリー・ユニット（ＣＴＵ）を分割することによって取得されることが可能である。

【0008】

方法は2つのケースを含む可能性がある：１）treeTypeがSINGLE_TREE又はDUAL_TREE_LUMAに等しいこと；２）treeTypeがDUAL_TREE_CHROMAに等しいこと。ケース1）の場合、現在ブロックはルマ・ブロックであり、ケース2）の場合、現在ブロックはクロマ・ブロックである。

【0009】

最大許容二分木ルート・ノード・サイズは、二分木分割を使用して分割することが可能なルマ・コーディング・ルート・ブロックのルマ・サンプルにおける最大ルマ・サイズであってもよい。

【0010】

最大許容三分木ルート・ノード・サイズは、三分木分割を使用して分割することが可能なルマ・コーディング・ルート・ブロックのルマ・サンプルにおける最大ルマ・サイズであってもよい。

【0011】

最小許容四分木リーフ・ノード・サイズは、四分木分割から生じるルマ・リーフ・ブロックのルマ・サンプルにおける最小ルマ・サイズであってもよい。

【0012】

このアプローチは、画像／ビデオ・ブロックに対する分割パラメータの効率的な分割又はシグナリングを促す。

【0013】

更に、第1態様による方法の可能な実装形式において、方法は、ピクチャの現在ブロックが境界ブロックであるかどうかを決定するステップを更に含む。現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用するステップは、現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、二分割を現在ブロックに適用するステップを含む。この場合、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズより大きくないことに留意されたい。従って、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくなく、現在ブロックのサイズが最大許容二分木ルート・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用する上述したステップは、現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、二分割を現在ブロックに適用するステップを含む。

【0014】

方法は、二分割を現在ブロックに適用することから直接的又は間接的に取得されるブロックの再構成されたブロックを取得するステップを更に含むことが可能である。

【0015】

二分割をもたらすことは、画像/ビデオ・フレーム境界におけるブロック、例えば境界によってカットされるブロックに対して特に有益である可能性がある。従って、幾つかの実装において、このアプローチを境界ブロックには適用するが、それを残りのブロックには適用しないことは、有益であるかもしれない。しかしながら、本開示はこれに限定されず、上述のように、二分割を適用するこのアプローチは、非境界ブロックにも適用され、効率的にシグナリングされる。

【0016】

第1態様又は上述の実施形態による方法の可能な実装形式において、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズよりも大きくなく、最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズよりも大きくない。

【0017】

第1態様又は上記の実施形態による方法の可能な実装形式において、マルチタイプ・ツリー分割を現在ブロックに適用するステップは、三分割を現在ブロックに適用するステップ、又は二分割を現在ブロックに適用するステップを含んでもよい。しかしながら、本開示はそれに限定されず、一般に、マルチタイプ・ツリー分割は、更なる又は他の異なる種類の分割も含む可能性がある。

【0018】

第1態様又は上述の実施形態による方法の可能な実装形式において、方法は、最小許容四分木リーフ・ノード・サイズに基づいて、最大許容二分木ルート・ノード・サイズを決定するステップを更に含んでもよい。これは、パラメータの効率的なシグナリング/記憶を促す。例えば、最大許容二分木ルート・ノード・サイズは、最小許容四分木リーフ・ノード・サイズに等しいと考えられてもよい。別の例に関し、最大許容二分木ルート・ノード・サイズの下限値は、最小許容四分木リーフ・ノード・サイズに等しいと考えられてもよく、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズの妥当性を決定するために使用されることが可能である。しかしながら、本開示は、それに限定されず、最大許容二分木ルート・ノード・サイズを導出するために、別の関係が仮定される可能性がある。

【0019】

例示的な実施形態によれば、第１態様又は上述の実施形態に追加的又は代替的に、方法は、画像をブロックに分割するステップであって、ブロックは現在ブロックを含む、ステップを更に含むことが可能である。二分割を現在ブロックに適用するステップは、最大境界マルチタイプ・パーティション深度を有する境界ブロックに二分割を適用するステップを含み、最大境界マルチタイプ・パーティション深度は、少なくとも最大マルチタイプ・ツリー・深度と最大マルチタイプ・ツリー深度オフセットとの合計であり、最大マルチタイプ・ツリー深度は０より大きい。更に、幾つかの実装において、二分割を境界ブロックに適用する場合に、最大マルチタイプ・ツリー深度は０より大きい。

【0020】

第1態様又は上述の実施形態による方法の可能な実装形式においては、画像をブロックに分割するステップを更に含むことが可能である（ブロックは現在ブロックを含む）。マルチタイプ・ツリー分割を現在ブロックに適用するステップは、最終的な最大マルチタイプ・ツリー深度を有するブロックの現在ブロックにマルチタイプ・ツリー分割を適用するステップを含み、最終的な最大マルチタイプ・ツリー深度は、少なくとも最大マルチタイプ・ツリー深度と最大マルチタイプ・ツリー深度オフセットとの合計であり、最大マルチタイプ・ツリー深度は、最小許容四分木リーフ・ノード・サイズのＬｏ２値から、最小許容変換ブロック・サイズのＬｏ２値を減算したもの以上であるか、又は最大マルチタイプ・ツリー深度は、最小許容四分木リーフ・ノード・サイズのＬｏ２値から、最小許容コーディング・ブロック・サイズのＬｏ２値を減算したもの以上である。これは、より大きなパーティション深度に対してさえ更なる分割を促す。

【0021】

現在ブロックは非境界ブロックであってもよい。最大マルチタイプ・ツリー深度オフセットは、０であってもよい。現在ブロックは、代替的に又は追加的に、境界ブロックであってもよく、マルチタイプ・ツリー分割は二分割である。マルチタイプ・ツリー分割は、三分割であってもよいし、それを含んでもよい。

【0022】

第２態様によれば、本発明は符号化のための方法に関連し、方法は符号化デバイスにより実行される。方法は、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するステップと、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用するステップとを含み、最小許容四分木リーフ・ノード・サイズは最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは最大許容三分木ルート・ノード・サイズより大きくない。

【0023】

符号化方法は、復号化方法に関して説明された上述の任意の規則及び制約を適用することができる。エンコーダ側とデコーダ側はビットストリームを共有しなければならないので、特に、符号化側は、上述のパーティショニングから生じるパーティションをコーディングした後に、ビットストリームを生成する一方、復号化側は、ビットストリームを解析し、それに従って復号化されたパーティションを再構成する。以下において説明される符号化デバイス(エンコーダ)及び復号化デバイス(デコーダ)に関する実施形態についても同じことが適用される。

【0024】

第３態様によれば、本発明は回路を含む復号化デバイスに関連し、回路は、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定し、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用するように構成されており、最小許容四分木リーフ・ノード・サイズは最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは最大許容三分木ルート・ノード・サイズより大きくない。現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定することは、復号化側でビットストリームにおけるシグナリングに基づいて実行されてもよいことに留意されたい。

【0025】

第４態様によれば、本発明は回路を含む符号化デバイスに関連し、回路は、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定し、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用するように構成されており、最小許容四分木リーフ・ノード・サイズは最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは最大許容三分木ルート・ノード・サイズより大きくない。

【0026】

本発明の第１態様による方法は、本発明の第３態様による装置又はデバイスによって実行されることが可能である。本発明の第３態様による方法の更なる特徴及び実装形式は、本発明の第１態様による装置の特徴及び実装形式に対応する。

【0027】

本発明の第２態様による方法は、本発明の第４態様による装置又はデバイスによって実行されることが可能である。本発明の第４態様による方法の更なる特徴及び実装形式は、本発明の第２態様による装置の特徴及び実装形式に対応する。

【0028】

第５態様によれば、本発明は、プロセッサ及びメモリを含むビデオ・ストリームを復号化するための装置に関連する。メモリは、第１態様による方法をプロセッサに実行させる命令を記憶している。

【0029】

第６態様によれば、本発明は、プロセッサ及びメモリを含むビデオ・ストリームを符号化するための装置に関連する。メモリは、第２態様による方法をプロセッサに実行させる命令を記憶している。

【0030】

第７態様によれば、実行された場合に、ビデオ・データをコーディングするように構成された１つ以上のプロセッサを動作させる命令を記憶したコンピュータ読み取り可能な記憶媒体が提案される。命令は、第１若しくは第２態様又は第１若しくは第２態様の任意の可能な実施形態による方法を１つ以上のプロセッサに実行させる。

【0031】

第８態様によれば、本発明は、コンピュータ上で実行された場合に、第１若しくは第２態様又は第１若しくは第２態様の任意の可能な実施形態による方法を実行するためのプログラム・コードを含むコンピュータ・プログラムに関連する。

【0032】

第９態様によれば、処理回路による実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体が提供され、プログラミングは、処理回路によって実行されると、上記の任意の方法を実行するように処理回路を構成する。

【0033】

明確性の目的に関し、本願で開示される任意の１つの実施形態は、本開示の範囲内で新たな実施形態を生み出すように、任意の１つ以上の他の実施形態と組み合わせられることが可能である。

【0034】

１つ以上の実施形態の詳細は、以下、添付の図面及び明細書で明らかにされる。他の特徴、目的、及び利点は、明細書、図面、及び特許請求の範囲から明らかであろう。

【図面の簡単な説明】

【0035】

以下、添付図面及び図を参照しながら本発明の実施形態がより詳細に説明される。

【図1A】本発明の実施形態を実現するように構成されたビデオ・コーディング・システムの一例を示すブロック図である。

【図1B】本発明の実施形態を実現するように構成されたビデオ・コーディング・システムの別の例を示すブロック図である。

【図2】本発明の実施形態を実現するように構成されたビデオ・エンコーダの一例を示すブロック図である。

【図3】本発明の実施形態を実現するように構成されたビデオ・デコーダの例示的な構造を示すブロック図である。

【図4】符号化装置又は復号化装置の一例を示すブロック図である。

【図5】符号化装置又は復号化装置の別の例を示すブロック図である。

【図6】四分木二分木（ＱＴＢＴ）構造を用いたブロック・パーティショニングの一例の例示的な図である。

【図7】図６のＱＴＢＴ構造を用いたブロック・パーティショニングに対応するツリー構造の一例の例示的な図である。

【図8】水平三分木のパーティション・タイプの一例の説明図である。

【図9】垂直三分木のパーティション・タイプの一例の説明図である。

【図10】Ａ－ＦはＶＶＣにおける様々なＣＵ分割モードを示す。

【図11A】ＨＤ（１９２０×１０８０）の下境界ＣＴＵ（１２８×１２８）の強制的なＱＴパーティションを示す。

【図11B】本開示の実施形態によるＨＤ（１９２０×１０８０）の下境界ＣＴＵ（１２８×１２８）の強制的なＢＴパーティションを示す。

【図12】例示的な境界定義を示す。

【図13A】本開示の実施形態によるコーナー・ケースの強制的なＱＴＢＴパーティションの一例を示す。

【図13B】本開示の実施形態によるコーナーに配置されたブロックに対する強制的なＱＴＢＴパーティションの一例を示す。

【図14】境界定義の実施形態を示す。

【図15】本発明の実施形態を実現するように構成されるビデオ・エンコーダの一例を示すブロック図である。

【図16】本発明の実施形態を実現するように構成されるビデオ・デコーダの構造例を示すブロック図である。

【図17】コンテンツ配信サービスを実現するコンテンツ供給システム３１００の構造例を示すブロック図である。

【図18】端末デバイスの一例の構造を示すブロック図である。

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

【0036】

以下の説明において、本開示の一部を成し、例示として本発明の実施形態の特定の態様又は本発明の実施形態が使用される可能性のある特定の態様を示す添付図面に対する参照が行われる。本発明の実施形態は、他の態様で使用される可能性があり、添付図面に示されていない構造的又は論理的な変更を含む可能性があることが理解される。従って、以下の詳細な説明は、限定する意味にとられるべきではなく、本発明の範囲は、添付の特許請求の範囲によって定められる。

【0037】

例えば、説明される方法に関連する開示は、方法を実行するように構成された対応するデバイス又はシステムにも当てはまる可能性があり、その逆も可能であることが理解される。例えば、１つ以上の特定の方法ステップが説明される場合、対応するデバイスは、説明された１つ以上の方法ステップを実行するための機能ユニットのような１つ以上のユニット（例えば、１つ以上のステップを実行する１つのユニット、又は複数のステップのうちの１つ以上を各々が実行する複数のユニット）を、たとえそのような１つ以上のユニットが図面において明示的に説明も図示もされていなかったとしても、含む可能性がある。一方、例えば、機能ユニットのような１つ以上のユニットに基づいて、特定の装置が説明される場合、対応する方法は、１つ以上のユニットの機能を実行するための１つのステップ（例えば、１つ以上のユニットの機能を実行するための１つのステップ、又は複数のユニットのうちの１つ以上の機能を各々が実行する複数のステップ）を、たとえそのような１つ以上のステップが図面において明示的に説明も図示もされていなかったとしても、含む可能性がある。更に、本願で説明される様々な例示的な実施形態及び／又は態様の特徴は、特に指定されない限り、互いに組み合わせられる可能性があることは理解される。

【0038】

ビデオ・コーディングは、典型的には、ビデオ又はビデオ・シーケンスを形成する一連のピクチャの処理を示す。ビデオ・コーディングの分野において、用語「ピクチャ」の代わりに、用語「フレーム」又は「画像」が同義語として使用されてもよい。本願（又は本開示）で使用されるビデオ・コーディングは、ビデオ符号化又はビデオ復号化を示す。ビデオ符号化は、ソース側で実行され、典型的には、ビデオ・ピクチャを表すのに必要なデータ量を減らすために（より効率的な記憶及び／又は伝送のために）オリジナル・ビデオ・ピクチャを（例えば、圧縮により）処理することを含む。ビデオ復号化は、宛先側で実行され、典型的には、ビデオ・ピクチャを再構成するために、エンコーダと比較して逆の処理を含む。ビデオ・ピクチャ（又は、以下で説明されるように、一般的にはピクチャ）の「コーディング」に対する実施形態は、ビデオ・シーケンスに関する「符号化」又は「復号化」に関連するように理解されるものとする。符号化の部分及び復号化の部分の組み合わせはまた、ＣＯＤＥＣ（Coding and Decoding）と言及される。

【0039】

ロスレス・ビデオ・コーディングの場合、オリジナル・ビデオ・ピクチャを再構成することが可能であり、即ち、再構成されたビデオ・ピクチャはオリジナル・ビデオ・ピクチャと同じ質を有する（記憶及び伝送の間に、伝送ロス又は他のデータ・ロスは発生しないことを仮定している）。ロスレスでないビデオ・コーディングの場合、ビデオ・ピクチャを表現するデータ量を減らすために、例えば量子化によって更なる圧縮が実行され、ビデオ・ピクチャはデコーダ側で完全には再構成することができず、即ち、再構成されたビデオ・ピクチャの質は、オリジナル・ビデオ・ピクチャの質より低い又は悪い。

【0040】

Ｈ．２６１以降の幾つかのビデオ・コーディング規格は、「ロスレスでないハイブリッド・ビデオ・コーデックス」のグループに属する（即ち、サンプル・ドメインにおける空間的及び時間的な予測と、変換ドメインにおいて量子化を適用するための２Ｄ変換コーディングとを組み合わせる）。ビデオ・シーケンスの各ピクチャは、典型的には、重複しないブロックのセットに区分けされ、コーディングは、典型的には、ブロック・レベルで実行される。換言すれば、エンコーダ側において、ビデオは、例えば空間（イントラ・ピクチャ）予測及び時間（インター・ピクチャ）予測を用いて予測ブロックを生成すること、現在ブロック（現在の処理済み／処理されるべきブロック）から予測ブロックを減算して残差ブロックを取得すること、残差ブロックを変換すること、変換ドメインにおいて残差ブロックを量子化して、伝送されるべきデータ量を減少させること（圧縮）により、典型的にはブロック（ビデオ・ブロック）レベルで処理され、即ち符号化され、デコーダ側では、エンコーダと比較して逆の処理が、符号化又は圧縮されたブロックに部分的に適用され、表現のために現在ブロックを再構成する。更に、エンコーダは、デコーダの処理ループを繰り返し、その結果、両者は、以後のブロックを処理する、即ちコーディングするために、同じ予測（例えば、イントラ及びインター予測）及び／又は再構成を生成するであろう。

【0041】

ここで使用されるように、「ブロック」という用語は、ピクチャ又はフレームの一部であってもよい。説明を容易にするために、本発明の実施形態は、ＩＴＵ－Ｔビデオ・コーディング・エキスパート・グループ（ＶＣＥＧ）及びＩＳＯ／ＩＥＣ動画エキスパート・グループ（ＭＰＥＧ）のビデオ・コーディングに関する共同研究チーム（ＪＣＴ－ＶＣ）によって開発された汎用ビデオ・コーディング（ＶＶＣ）のリファレンス・ソフトウェア又は高効率ビデオ・コーディング（ＨＥＶＣ）を参照して説明される。当業者は、本発明の実施形態がＨＥＶＣ又はＶＶＣに限定されないことを理解するであろう。これはＣＵ（coding units）、ＰＵ（prediction units）又はＴＵ（transform units）を示す可能性がある。ＨＥＶＣにおいて、ＣＴＵ（coding tree unit）は、コーディング・ツリーとして示される四分木構造を使用することによって、複数のＣＵに分割される。インター・ピクチャ（時間的）又はイントラ・ピクチャ（空間的）予測を利用してピクチャをコーディングするかどうかの決定は、ＣＵレベルで行われる。各ＣＵは更に、ＰＵ分割タイプに従って、１つ、２つ、又は４つのＰＵに分割されることが可能である。１つのＰＵの中で、同じ予測プロセスが適用され、関連情報はＰＵに基づいてデコーダに送信される。ＰＵ分割タイプに基づいて予測プロセスを適用することにより、残差ブロックを取得した後に、ＣＵは、ＣＵに対するコーディング・ツリーに類似する別の四分木構造に従って、変換ユニット（ＴＵ）に分割されることが可能である。最新のビデオ圧縮技術の開発では、コーディング・ブロックを分割するために、四分木及び二分木（ＱＴＢＴ）パーティショニング・フレームが使用される。ＱＴＢＴブロック構造では、ＣＵは正方形又は長方形であるとすることが可能である。例えば、コーディング・ツリー・ユニット（ＣＴＵ）は先ず四分木構造によって区分けされる。四分木リーフ・ノードは二分木構造によって更に区分けされる。二分木リーフ・ノードはコーディング・ユニット（ＣＵ）と言及され、そのセグメンテーションは、更なる如何なるパーティショニングもなしに予測及び変換処理のために使用される。これは、ＣＵ、ＰＵ、ＴＵがＱＴＢＴコーディング・ブロック構造において同じブロック・サイズを有することを意味する。と同時に、複数パーティション、例えば三分木（ＴＴ）パーティションもＱＴＢＴブロック構造とともに使用されるように提案された。用語「デバイス」はまた「装置」、「デコーダ」又は「エンコーダ」であってもよい。

【0042】

以下、エンコーダ２０、デコーダ３０、及びコーディング・システム１０の実施形態を、図１－３に基づいて説明する。

【0043】

図１Ａは、例示的なコーディング・システム１０、例えば本願（本開示）の技術を使用することが可能なビデオ・コーディング・システム１０を示す概念的又は概略的なブロック図である。ビデオ・コーディング・システム１０のエンコーダ２０（例えば、ビデオ・エンコーダ２０）及びデコーダ３０（例えば、ビデオ・デコーダ３０）は、本願で説明される種々の例による技術を実行するように構成される可能性があるデバイス例を表す。図１Ａに示すように、コーディング・システム１０は、例えば符号化されたピクチャ１３のような符号化されたデータ１３を、例えば符号化されたデータ１３を復号化する宛先デバイス１４へ提供するように構成されたソース・デバイス１２を含む。

【0044】

ソース・デバイス１２は、エンコーダ２０を含み、追加的に、即ちオプションとして、ピクチャ・ソース１６、例えばピクチャ前処理ユニット１８のような前処理ユニット１８、及び、通信インターフェース又は通信ユニット２２を含む可能性がある。

【0045】

ビデオ・ソース１６は、例えば実世界のピクチャを捕捉するような任意の種類のピクチャ捕捉デバイス、及び／又は、例えばピクチャ又はコメント生成デバイス（スクリーン・コンテンツ・コーディングの場合には、スクリーン上の何らかのテキストもまた、符号化対象のピクチャ又は画像の一部と考えられる）、例えば、コンピュータ・アニメーション・ピクチャを生成するコンピュータ・グラフィックス・プロセッサ、又は、実世界のピクチャ又はコンピュータ・アニメーション・ピクチャを取得及び／又は提供する任意の種類のデバイス（例えば、スクリーン・コンテンツ又はバーチャル・リアリティ（ＶＲ）ピクチャ）、及び／又は、それらの任意の組み合わせ（例えば、拡張現実（ＡＲ）ピクチャ）を含んでもよいし、又はそれらであってもよい。ピクチャ・ソースは、上記の任意のピクチャを記憶する任意の種類のメモリ又はストレージである可能性がある。

【0046】

（デジタル）ピクチャは、強度値を有するサンプルの２次元アレイ又はマトリクスであるか、又はそのように考えることが可能である。アレイ中のサンプルは、ピクセル（ピクチャ要素の短縮形）又はペルと呼ばれてもよい。アレイ又はピクチャの水平及び垂直方向（又は軸）におけるサンプルの量は、ピクチャのサイズ及び／又は解像度を規定する。色の表現には、典型的には、３つの色成分が使用され、即ち、ピクチャは、３つのサンプル・アレイで表現されてもよいし、又はそれを含んでもよい。ＲＢＧフォーマット又は色空間において、ピクチャは対応する赤、緑、及び青のサンプル・アレイを含む。しかしながら、ビデオ・コーディングにおいては、各ピクセルは、典型的には、ルミナンス／クロミナンス・フォーマット又は色空間、例えばＹＣｂＣｒで表現され、ＹＣｂＣｒは、Ｙで示されるルミナンス成分（時にはそれに代えてＬが使用される）とＣｂ及びＣｒで示される２つのクロミナンス成分とを含む。ルミナンス（又は略称、ルマ）成分Ｙは、輝度又はグレー・レベル強度を（例えば、グレー・スケール・ピクチャでのように）表し、２つのクロミナンス（又は略称、クロマ）成分Ｃｂ及びＣｒはクロミナンス又は色情報成分を表す。従って、ＹＣｂＣｒフォーマットにおけるピクチャは、ルミナンス・サンプル値（Ｙ）のルミナンス・サンプル・アレイと、クロミナンス値（Ｃｂ及びＣｒ）の２つのクロミナンス・サンプル・アレイとを含む。ＲＧＢフォーマットのピクチャは、ＹＣｂＣｒフォーマットにコンバート又は変換されることが可能であり、その逆も可能であり、そのプロセスは色変換又はコンバージョンとしても知られている。ピクチャがモノクロである場合、ピクチャはルミナンス・サンプル・アレイのみを含む可能性がある。

【0047】

ピクチャ・ソース１６（例えば、ビデオ・ソース１６）は、例えば、ピクチャを捕捉するカメラ、例えば、事前に捕捉された若しくは生成されたピクチャを包含又は記憶するピクチャ・メモリのようなメモリ、及び／又はピクチャを取得若しくは受信するための任意の種類の（内部又は外部）インターフェースであってもよい。カメラは、例えば、ソース・デバイスに一体化されたローカルな又は一体化されたカメラであってもよく、メモリは、例えばソース・デバイスに一体化されたローカルな又は一体化されたメモリであってもよい。インターフェースは、例えば外部ビデオ・ソースからピクチャを受信するための外部インターフェース、例えばカメラ、外部メモリ、又は外部ピクチャ生成デバイスのような外部ピクチャ捕捉デバイス、例えば外部コンピュータ・グラフィックス・プロセッサ、コンピュータ又はサーバーであってもよい。インターフェースは、任意のプロプライエタリ又は標準化されたインターフェース・プロトコルに従う任意の種類のインターフェース、例えば有線又は無線インターフェース、光インターフェースであるとすることが可能である。ピクチャ・データ１７を取得するためのインターフェースは、通信インターフェース２２と同じインターフェースであってもよいし、又はその一部であってもよい。

【0048】

前処理ユニット１８及び前処理ユニット１８により実行される処理とは異なり、ピクチャ及びピクチャ・データ１７（例えば、ビデオ・データ１６）はまた、未処理ピクチャ又は未処理ピクチャ・データ１７と呼ばれてもよい。

【0049】

前処理ユニット１８は、（未処理）ピクチャ・データ１７を受信し、ピクチャ・データ１７に関して前処理を実行して、前処理されたピクチャ１９又は前処理されたピクチャ・データ１９を取得するように構成されている。前処理ユニット１８によって実行される前処理は、例えば、トリミング、カラー・フォーマット変換（例えば、ＲＧＢからＹＣｂＣｒへ）、色補正、又はノイズ低減を含む可能性がある。前処理ユニット１８はオプションの構成要素であってもよいことを理解することは可能である。

【0050】

エンコーダ２０（例えば、ビデオ・エンコーダ２０）は、前処理されたピクチャ・データ１９を受信し、符号化ピクチャ・データ２１を提供するように構成される（更なる詳細は、例えば以下において図２又は図４に基づいて説明されるであろう）。

【0051】

ソース・デバイス１２の通信インターフェース２２は、符号化されたピクチャ・データ２１を受信し、符号化されたピクチャ・データ２１（又はそれを更に処理した任意のバージョン）を通信チャネル１３を介して他のデバイスへ、例えば宛先デバイス１４又は任意の他のデバイスへ、記憶又は直接的な再構成のために送信するように構成されることが可能である。

【0052】

ソース・デバイス１２の通信インターフェース２２は、符号化されたピクチャ・データ２１を受信し、それを他のデバイスへ、例えば宛先デバイス１４又は任意の他のデバイスへ、記憶又は直接的な再構成のために送信し、又は符号化されたデータ１３を記憶すること、及び／又は符号化されたデータ１３を他のデバイスへ、例えば宛先デバイス１４又は任意の他のデバイスへ復号化又は記憶のために送信すること、の前にそれぞれ符号化されたピクチャ・データ２１を処理するように構成されることが可能である。

【0053】

宛先デバイス１４は、デコーダ３０（例えば、ビデオ・デコーダ３０）を含み、追加的に、即ちオプションとして、通信インターフェース又は通信ユニット２８、後処理ユニット３２、及び表示デバイス３４を含む可能性がある。

【0054】

宛先デバイス１４の通信インターフェース２８は、符号化されたピクチャ・データ２１（又はそれを更に処理した任意のバージョン）を、例えばソース・デバイス１２から直接的に、又は任意の他のソースから、例えばソース・デバイスから、例えば符号化されたピクチャ・データのストレージ・デバイスから受信し、符号化されたピクチャ・データ２１をデコーダ３０に提供するように構成される。

【0055】

宛先デバイス１４の通信インターフェース２８は、符号化されたピクチャ・データ２１又は符号化されたデータ１３を、例えばソース・デバイス１２から直接的に、又は任意の他のソースから、例えばストレージ・デバイスから、例えば符号化ピクチャ・データ・ストレージ・デバイスから受信するように構成される。

【0056】

通信インターフェース２２及び通信インターフェース２８は、ソース・デバイス１２と宛先デバイス１４との間の直接的な通信リンク、例えば直接的な有線又は無線接続を介して、又は任意の種類のネットワーク、例えば有線若しくは無線ネットワーク又はそれらの任意の組み合わせ、又は任意の種類の私的な及び公のネットワーク、又はそれらの任意の組み合わせを介して、符号化されたピクチャ・データ２１又は符号化されたデータ１３を送信又は受信するように構成されることが可能である。

【0057】

通信インターフェース２２は、例えば、符号化されたピクチャ・データ２１を、例えばパケットのような適切なフォーマットにパッケージングし、及び／又は、通信リンク若しくは通信ネットワークを介する伝送のための任意の種類の伝送符号化又は処理を使用して、符号化されたピクチャ・データを処理するように構成されることが可能である。

【0058】

通信インターフェース２２の対応部分を形成する通信インターフェース２８は、例えば、符号化されたデータ１３を非パッケージ化して符号化されたピクチャ・データ２１を取得するように構成されることが可能である。

【0059】

通信インターフェース２２の対応部分を形成する通信インターフェース２８は、例えば、送信されたデータを受信し、符号化されたピクチャ・データ２１を取得するために任意の種類の対応する伝送復号化又は処理及び／又は非パッケージ化を使用して、送信データを処理する。

【0060】

通信インターフェース２２及び通信インターフェース２８の両方は、図１Ａにおいてソース・デバイス１２から宛先デバイス１４へ向かう符号化されたピクチャ・データ１３に関する矢印により示される一方向通信インターフェース、又は双方向通信インターフェースとして構成されることが可能であり、例えばメッセージを送信及び受信するように、例えば接続を設定するように、通信リンク及び／又は例えば符号化されたピクチャ・データ伝送のようなデータ伝送に関連する他の任意の情報を確認及び交換するように、構成されることが可能である。

【0061】

デコーダ３０は、符号化されたピクチャ・データ２１を受信し、復号化されたピクチャ・データ３１又は復号化されたピクチャ３１を提供するように構成される（更なる詳細は、例えば図３又は図５に基づいて、以下において説明されるであろう）。

【0062】

宛先デバイス１４の後処理プロセッサ３２は、例えば復号化されたピクチャ３１のような復号化されたピクチャ・データ３１（再構成されたピクチャ・データとも呼ばれる）を後処理して、後処理されたピクチャ３３のような後処理ピクチャ・データ３３を取得するように構成される。後処理ユニット３２によって実行される後処理は、例えばカラー・フォーマット変換（例えば、ＹＣｂＣｒからＲＧＢへ）、色補正、トリミング、リサンプリング、又は、例えば表示デバイス３４による表示のための例えば復号化されたピクチャ・データ３１を準備するための他の任意の処理を含む可能性がある。

【0063】

宛先デバイス１４の表示デバイス３４は、後処理ピクチャ・データ３３を受信して、ピクチャを、例えばユーザー又はビューアに表示するように構成されている。表示デバイス３４は、再構成されたピクチャを表現する任意の種類のディスプレイ、例えば一体化された又は外部のディスプレイ又はモニタであってもよいし、又はそれらを含んでもよい。ディスプレイは、例えば、液晶ディスプレイ（ＬＣＤ）、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、プラズマ・ディスプレイ、プロジェクタ、マイクロＬＥＤディスプレイ、液晶オン・シリコン（ＬＣｏＳ）、デジタル光プロセッサ（ＤＬＰ）、又は任意の他の種類のディスプレイを含む可能性がある。

【0064】

図１Ａは、ソース・デバイス１２と宛先デバイス１４とを別々のデバイスとして描いているが、デバイスの実施形態はまた、双方又は双方の機能、ソース・デバイス１２又は対応する機能と宛先デバイス１４又は対応する機能とを含む可能性がある。そのような実施形態では、ソース・デバイス１２又は対応する機能と宛先デバイス１４又は対応する機能とは、同じハードウェア及び／又はソフトウェアを使用して、又は別個のハードウェア及び／又はソフトウェア、又はそれらの任意の組み合わせにより実現されてもよい。

【0065】

明細書に基づいて当業者には明らかであるように、図１Ａに示すソース・デバイス１２及び／又は宛先デバイス１４における機能又は様々なユニットの機能の存在及び（厳密な）分割は、実際のデバイス及び用途によって異なる可能性がある。

【0066】

エンコーダ２０（例えば、ビデオ・エンコーダ２０）及びデコーダ３０（例えば、ビデオ・デコーダ３０）は、それぞれ、種々の任意の適切な回路、例えば１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディスクリート・ロジック、ハードウェア、又はそれらの任意の組み合わせとして実現されることが可能である。技術がソフトウェアで部分的に実現される場合、デバイスは、ソフトウェアの命令を、適切な非一時的なコンピュータ読み取り可能な記憶媒体に記憶することが可能であり、本開示の技術を実行するために１つ以上のプロセッサを使用して、ハードウェアで命令を実行することが可能である。（ハードウェア、ソフトウェア、ハードウェアとソフトウェアの組み合わせ等を含む）上記の何れも、１つ以上のプロセッサであると考えられてもよい。ビデオ・エンコーダ２０及びビデオ・デコーダ３０は、それぞれ、１つ以上のエンコーダ又はデコーダに含まれる可能性があり、何れも個々のデバイス内の組み合わされたエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合されてもよい。

【0067】

エンコーダ２０は、図２のエンコーダ２０及び／又は本願で説明される任意の他のエンコーダ・システム又はサブシステムに関して説明したように、種々のモジュールを具体化するように、処理回路４６により実現されてもよい。デコーダ３０は、図３のデコーダ３０及び／又は本願で説明される任意の他のデコーダ・システム又はサブシステムに関して説明されるように、種々のモジュールを具体化するために、処理回路４６を介して実装されてもよい。処理回路は、後述するように、種々の動作を実行するように構成されることが可能である。図５に示すように、技術が部分的にソフトウェアで実現される場合、デバイスは、適切な一時的でないコンピュータ読み取り可能な記憶媒体にソフトウェアの命令を記憶し、本開示の技術を実行するために１つ以上のプロセッサを使用して、命令をハードウェアで実行することができる。ビデオ・エンコーダ２０とビデオ・デコーダ３０の何れかは、例えば図１Ｂに示すように、単一のデバイス内の組み合わされたエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合されてもよい。

【0068】

ソース・デバイス１２は、ビデオ符号化デバイス又はビデオ符号化装置と言及されてもよい。宛先デバイス１４は、ビデオ復号化デバイス又はビデオ復号化装置と言及されてもよい。ソース・デバイス１２及び宛先デバイス１４はビデオ・コーディング・デバイス又はビデオ・コーディング装置の一例とすることが可能である。

【0069】

ソース・デバイス１２及び宛先デバイス１４は、任意の種類のハンドヘルド又はステーショナリ・デバイスを含む広範囲に及ぶ任意のデバイス、例えば、ノートブック又はラップトップ・コンピュータ、携帯電話、スマートフォン、タブレット又はタブレット・コンピュータ、カメラ、デスクトップ・コンピュータ、セット・トップ・ボックス、テレビ、表示デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイス（コンテンツ・サービス・サーバー又はコンテンツ配信サーバー等）、放送受信デバイス、放送送信デバイス等を含む可能性があり、任意の種類のオペレーティング・システムを使用してもよいし、又は使用しなくてもよい。

【0070】

場合によっては、ソース・デバイス１２及び宛先デバイス１４は無線通信用に装備されてもよい。従って、ソース・デバイス１２及び宛先デバイス１４は、無線通信デバイスであってもよい。

【0071】

場合によっては、図１Ａに示すビデオ・コーディング・システム１０は単なる一例に過ぎず、本願の技術は、符号化デバイスと復号化デバイスとの間で如何なるデータ通信も含む必要のないビデオ・コーディング設定（例えば、ビデオ符号化又はビデオ復号化）に適用される可能性がある。他の例において、データは、ローカル・メモリから検索され、ネットワークを介してストリーミング等される。ビデオ符号化デバイスは、データを符号化してメモリに格納することが可能であり、及び／又はビデオ復号化デバイスは、データをメモリから検索して復号化することが可能である。幾つかの例では、符号化及び復号化は、互いに通信しないが、メモリへのデータを符号化し及び／又はメモリからデータを検索して復号化するだけのデバイスによって実行される。

【0072】

説明の便宜上、本発明の実施形態は、例えば高効率ビデオ・コーディング（ＨＥＶＣ）又は汎用ビデオ・コーディング（ＶＶＣ）、ＩＴＵ－Ｔビデオ・コーディング・エキスパート・グループ（ＶＣＥＧ）及びＩＳＯ／ＩＥＣ動画エキスパート・グループ（ＭＰＥＧ）のビデオ・コーディングに関する共同研究チーム（ＪＣＴ－ＶＣ）によって開発された次世代ビデオ・コーディング規格の参照ソフトウェアを参照することによりここでは説明される。当業者は、本発明の実施形態がＨＥＶＣ又はＶＶＣに限定されないことを理解するであろう。ビデオ・エンコーダ２０に関連して説明された上記の例の各々に関し、ビデオ・デコーダ３０は逆のプロセスを実行するように構成されることが可能であることが、理解されるはずである。シンタックス要素をシグナリングすることに関し、ビデオ・デコーダ３０は、そのようなシンタックス要素を受信して解析し、それに応じて関連するビデオ・データを復号化するように構成されることが可能である。幾つかの例において、ビデオ・エンコーダ２０は、１つ以上のせを、符号化されたビデオ・ビットストリームにエントロピー符号化することができる。このような例では、ビデオ・デコーダ３０は、このようなシンタックス要素を解析し、それに応じて関連するビデオ・データを復号化することができる。

【0073】

図１Ｂは、例示的な実施形態による図２のエンコーダ２０及び／又は例示的実施形態による図３のデコーダ３０を含む別の例示的なビデオ・コーディング・システム４０の例示的な図である。システム４０は、本願で説明される種々の例に従って技術を実現することが可能である。図示された実装では、ビデオ・コーディング・システム４０は、撮像装置４１、ビデオ・エンコーダ１００、ビデオ・デコーダ３０（及び／又は、処理ユニット４６の論理回路４７により実現されるビデオ・コーダー）、アンテナ４２、１つ以上のプロセッサ４３、１つ以上のメモリ・ストア４４、及び／又は、表示デバイス４５を含むことが可能である。

【0074】

図示されているように、撮像装置４１、アンテナ４２、処理ユニット４６、論理回路４７、ビデオ・エンコーダ２０、ビデオ・デコーダ３０、プロセッサ４３、メモリ・ストア４４、及び／又は表示デバイス４５は、互いに通信することが可能である。上述したように、ビデオ・エンコーダ２０及びビデオ・デコーダ３０の双方とともに図示されているが、ビデオ・コーディング・システム４０は、種々の例においてはビデオ・エンコーダ２０のみ又はビデオ・デコーダ３０のみを含む可能性がある。

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

実施形態では、例えば、汎用ビデオ・コーディング（ＶＶＣ）と呼ばれる現在発展中の最新のビデオ・コーディング規格によれば、例えば二分木及び三分木セグメンテーション構造を使用する組み合わせ四分木ネスト・マルチタイプ・ツリーが、コーディング・ツリー・ユニットを区分けするために使用される。コーディング・ツリー・ユニットにおけるコーディング・ツリー構造では、ＣＵは正方形又は長方形の何れかの形状を有することができる。例えば、コーディング・ツリー・ユニット（ＣＴＵ）は、先ず四分木によって区分けされる。次いで、四分木リーフ・ノードは、マルチタイプ・ツリー構造によって更に区分けされることが可能である。マルチタイプ・ツリー構造には、垂直二分割（SPLIT_BT_VER）、水平二分割（SPLIT_BT_HOR）、垂直三分割（SPLIT_TT_VER）、水平三分割（SPLIT_TT_HOR）の４つの分割タイプがある。マルチタイプ・ツリー・リーフ・ノードは、コーディング・ユニット（ＣＵ）と呼ばれ、ＣＵが最大変換長に対して大きすぎない限り、このセグメンテーションは、更なる如何なるパーティショニングもなしに、予測及び変換処理に使用される。これは、ほとんどの場合、ＣＵ、ＰＵ、及びＴＵが、ネストされたマルチタイプ・ツリー・コーディング・ブロック構造を有する四分木において同じブロック・サイズを有することを意味する。例外は、サポートされる最大変換長がＣＵのカラー成分の幅又は高さよりも小さい場合に発生する。ＶＶＣは、ネストされたマルチタイプ・ツリー・コーディング・ツリー構造を有する四分木におけるパーティション分割情報の固有のシグナリング・メカニズムを開発している。シグナリング・メカニズムでは、コーディング・ツリー・ユニット（ＣＴＵ）は四分木のルートとして扱われ、先ず四分木構造によって区分けされる。各々の四分木リーフ・ノード（それを許容する程度に十分に大きい場合）は、次いで、マルチタイプ・ツリー構造によって更に区分けされる。マルチタイプ・ツリー構造では、第１フラグ（mtt_split_cu_flag）は、ノードが更に区分けされているかどうかを示すためにシグナリングされ、ノードが更に区分けされる場合には、第２フラグ（mtt_split_cu_vertical_flag）が、分割方向を示すためにシグナリングされ、次いで、第３フラグ（mtt_split_cu_binary_flag）が、分割は二分割であるか又は三分割であるかを示すためにシグナリングされる。mtt_split_cu_vertical_flag及びmtt_split_cu_binary_flagの値に基づいて、ＣＵのマルチタイプ・ツリー分割モード（MttSplitMode）は、予め定義されたルール又はテーブルに基づいてデコーダによって導出されることが可能である。特定の設計、例えばＶＶＣハードウェア・デコーダにおける６４×６４ルマ・ブロック及び３２×３２クロマ・パイプライン設計では、図６に示すように、ルマ・コーディング・ブロックの幅又は高さのうちの何れかが６４より大きい場合に、ＴＴ分割は禁止されることに留意すべきである。ＴＴ分割は、クロマ・コーディング・ブロックの幅又は高さが３２を超える場合にも禁止される。パイプライン設計は、ピクチャを仮想パイプライン・データ・ユニット（ＶＰＤＵ）に分割し、これはピクチャ内の重複しないユニットとして定義される。ハードウェア・デコーダでは、連続するＶＰＤＵが複数のパイプライン・ステージによって同時に処理される。ＶＰＤＵサイズは、ほとんどのパイプライン・ステージのバッファ・サイズに大まかに比例するので、ＶＰＤＵサイズを小さく保つことは重要である。ほとんどのハードウェア・デコーダでは、ＶＰＤＵサイズは最大変換ブロック（ＴＢ）サイズに設定されることが可能である。しかしながら、ＶＶＣでは、三分木（ＴＴ）及び二分木（ＢＴ）パーティションは、ＶＰＤＵサイズの増加を招く可能性がある。更に、ツリー・ノード・ブロックの一部が下又は右のピクチャ境界を超える場合、ツリー・ノード・ブロックは、すべてのコーディングされるＣＵのすべてのサンプルがピクチャ境界内に配置されるまで、強制的に分割されることに留意すべきである。

【0118】

一例として、イントラ・サブ・パーティション（ＩＳＰ）ツールは、ブロック・サイズに依存して、ルマ・イントラ予測ブロックを縦方向又は横方向に、２つ又は４つのサブ・パーティションに分割することができる。

【0119】

一例では、ビデオ・エンコーダ２０のモード選択ユニット２６０は、本願で説明されるパーティショニング技術の任意の組み合わせを実行するように構成されることが可能である。上述したように、エンコーダ２０は、一組の（あらかじめ決定された）予測モードから、最良の又は最適な予測モードを決定又は選択するように構成される。予測モードのセットは、例えば、イントラ予測モード及び／又はインター予測モードを含む可能性がある。

【0120】

イントラ予測モードのセットは、３５個の異なるイントラ予測モード、例えばＤＣ（又は平均）モード及び平面モードのような非方向モード、又は例えばＨ．２６５で規定されているような方向モードを含むことが可能であり、又は、６７個の異なるイントラ予測モード、例えばＤＣ（又は平均）モード及び平面モードのような非方向モード、又は例えばＶＶＣで規定されているような方向モードを含むことが可能である。一例として、幾つかの従来の角度イントラ予測モードが、例えばＶＶＣで規定されるように、非正方形ブロックのための広角イントラ予測モードで適応的に置換される。別の例として、ＤＣ予測のための分割演算を回避するために、長辺のみが、非正方形ブロックに対する平均を計算するために使用される。また、プレーナ・モードのイントラ予測の結果は，位置依存イントラ予測結合（ＰＤＰＣ）法によって更に修正されることが可能である。イントラ予測ユニット２５４は、イントラ予測モードのセットのイントラ予測モードに従って、同一の現在ピクチャの隣接ブロックの再構成されたサンプルを使用して、イントラ予測ブロック２６５を生成するように構成される。

【0121】

イントラ予測ユニット２５４（又は、一般に、モード選択ユニット２６０）は、符号化されたピクチャ・データ２１に含めるためのシンタックス要素２６６の形式で、エントロピー符号化ユニット２７０にイントラ予測パラメータ（又は、一般的には、ブロックに対する選択されたイントラ予測モードを示す情報）を出力するように更に構成され、その結果、例えばビデオ・デコーダ３０は、復号化のために予測パラメータを受信して使用することができる。

【0122】

一組の（又は可能性のある）イントラ予測モードは、利用可能な参照ピクチャ（即ち、少なくとも部分的に復号化された以前のピクチャ、例えばＤＢＰ２３０に格納されているもの）及び他のインター予測パラメータ、例えば参照ピクチャの全体又は一部のみ、例えば参照ピクチャの、現在ブロックのエリア周辺のサーチ・ウィンドウ・エリアが、最良に合致する参照ブロックを探索するために使用されるかどうか、及び／又は、例えばハーフ／セミ・ペル、クォーター・ペル、及び／又は１／１６ペル補間のようなピクセル補間が適用されるかどうか等に依存する。

【0123】

上記の予測モードに加えて、スキップ・モード、ダイレクト・モード、及び／又は他のインター予測モードが適用されてもよい。

【0124】

例えば、拡張マージ予測、このようなモードのマージ候補リストは、次の５つのタイプの候補：空間的な隣接ＣＵからの空間的ＭＶＰ、同じ位置にあるＣＵからの時間的なＭＶＰ、ＦＩＦＯテーブルからの履歴ベースＭＶＰ、ペアワイズ平均ＭＶＰ及びゼロＭＶを、順に含めることによって構成される。また、マージ・モードのＭＶの精度を高めるために、バイラテラル・マッチング・ベースのデコーダ側の動きベクトル精密化（ＤＭＶＲ）が適用されてもよい。ＭＶＤを伴うマージ・モード（ＭＭＶＤ）は、動きベクトル差分を伴うマージ・モードに由来する。ＭＭＶＤフラグは、スキップ・フラグとマージ・フラグを送信した直後に、ＭＭＶＤモードがＣＵに使用されるかどうかを指定するためにシグナリングされる。そして、ＣＵレベル適応動きベクトル分解（ＡＭＶＲ）方式が適用されてもよい。ＡＭＶＲは、ＣＵのＭＶＤが、異なる精度で復号化されることを許容する。現在のＣＵの予測モードに依存して、現在のＣＵのＭＶＤは適応的に選択されることが可能である。ＣＵがマージ・モードで符号化される場合に、結合されたインター／イントラ予測（ＣＩＩＰ）モードは、現在のＣＵに適用されることが可能である。ＣＩＩＰ予測を得るために、インター及びイントラ予測信号の加重平均が実行される。アフィン動き補償予測、ブロックのアフィン・モーション・フィールドは、２制御点（４パラメータ）又は３制御点動きベクトル（６パラメータ）の動き情報によって記述される。サブブロック・ベースの時間的動きベクトル予測（ＳｂＴＭＶＰ）は、ＨＥＶＣにおける時間的動きベクトル予測（ＴＭＶＰ）に類似しているが、現在のＣＵにおけるサブＣＵの動きベクトルを予測する。以前はＢＩＯと呼ばれていた双方向オプティカル・フロー（ＢＤＯＦ）は、特に乗算の数及び乗算器のサイズに関してはるかに少ない計算量を必要とする、より簡易なバージョンである。三角パーティション・モードのようなモードでは、ＣＵは、対角分割又は反対角分割の何れかを使用して、２つの三角形パーティションに均等に分割される。加えて、双方向予測モードは、単純な平均を越えて拡張され、２つの予測信号の重み付け平均を可能にする。

【0125】

上記の予測モードに加えて、スキップ・モード及び／又はダイレクト・モードが適用されてもよい。

【0126】

予測処理ユニット２６０は、更に、ブロック２０３を、より小さなブロック・パーティション又はサブブロックに、例えば四分木パーティション（ＱＴ）、二分パーティション（ＢＴ）、三分パーティション（ＴＴ）又はそれらの組み合わせを反復的に使用することで区分けし、例えばブロック・パーティション又はサブブロックの各々について予測を実行するように構成されることが可能であり、モード選択は、区分けされたブロック２０３のツリー構造と、ブロック・パーティション又はサブブロック各々に適用される予測モードとの選択を含む。

【0127】

インター予測ユニット２４４は、動き推定（ＭＥ）ユニット（図２には示されていない）及び動き補償（ＭＣ）ユニット（図２には示されていない）を含むことが可能である。動き推定ユニットは、動き推定のために、ピクチャ・ブロック２０３（現在のピクチャ２０１の現在のピクチャ・ブロック２０３）及び復号化されたピクチャ２３１、又は少なくとも１つ又は複数の以前に再構成されたブロック、例えば１つ又は複数の他の／異なる以前に復号化されたピクチャ２３１の再構成ブロックを受信又は取得するように構成される。例えば、ビデオ・シーケンスは、現在のピクチャと以前に復号化されたピクチャ２３１とを含む可能性があり、又は換言すれば、現在のピクチャと以前に復号化されたピクチャ２３１とは、ビデオ・シーケンスを形成するピクチャの一部であってもよいし、又はピクチャのシーケンスを形成してもよい。

【0128】

エンコーダ２０は、例えば、複数の他のピクチャの同じ又は異なるピクチャの複数の参照ブロックから参照ブロックを選択し、参照ピクチャ（又は参照ピクチャ・インデックス、．．．）及び／又は参照ブロックの位置（ｘ，ｙ座標）と現在ブロックの位置との間のオフセット（空間オフセット）とを、インター予測パラメータとして動き推定ユニット（図２には示されていない）へ提供するように構成されてもよい。このオフセットも動きベクトル（ＭＶ）と呼ばれる。

【0129】

動き補償ユニットは、インター予測パラメータを取得して、例えば受信して、インター予測パラメータに基づいて又はそれを使用してインター予測を実行し、インター予測ブロック２６５を取得するように構成される。動き補償ユニットによって実行される動き補償は、動き推定によって決定される動き／ブロック・ベクトルに基づいて予測ブロックをフェッチ又は生成すること、可能性としてサブピクセル精度まで補間を実行することを包含することが可能である。補間フィルタリングは、既知のピクセル・サンプルから追加のピクセル・サンプルを生成することができ、従って潜在的に、ピクチャ・ブロックをコーディングするために使用されることが可能な候補予測ブロックの数を増加させる。現在のピクチャ・ブロックのＰＵに対する動きベクトルを受信すると、動き補償ユニットは、参照ピクチャ・リストのうちの１つにおいて動きベクトルが指し示す予測ブロックを突き止めることができる。

【0130】

イントラ予測ユニット２５４は、ピクチャ・ブロック２０３（現在のピクチャ・ブロック）及び同じピクチャの、１つ又は複数の以前に再構成されたブロック、例えば再構成された隣接ブロックをイントラ推定のために取得する、例えば受信するように構成される。エンコーダ２０は、例えば複数の（所定の）イントラ予測モードからイントラ予測モードを選択するように構成されことが可能である。

【0131】

エンコーダ２０の実施形態は、最適化基準、例えば最小残差（例えば、イントラ予測モードは現在のピクチャ・ブロック２０３に最も類似する予測ブロック２５５を提供する）又は最小レート歪に基づいて、イントラ予測モードを選択するように構成されてもよい。

【0132】

イントラ予測ユニット２５４は、イントラ予測パラメータ、例えば選択されたイントラ予測モード、イントラ予測ブロック２５５に基づいて決定するように更に構成される。何れにせよ、ブロックに対するイントラ予測モードを選択した後、イントラ予測部２５４は、イントラ予測パラメータ、即ちブロックに対して選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット２７０に提供するようにも構成される。一例において、イントラ予測ユニット２５４は、後述するイントラ予測技術の任意の組み合わせを実行するように構成されてもよい。

【0133】

エントロピー符号化ユニット２７０は、エントロピー符号化アルゴリズム又はスキーム（例えば、可変長コーディング（ＶＬＣ）スキーム、コンテキスト適応ＶＬＣスキーム（ＣＡＬＶＣ）、算術コーディング・スキーム、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックス・ベースのコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率区間パーティショニング・エントロピー（ＰＩＰＥ）コーディング、又は他のエントロピー符号化方法又は技術）を、量子化残差係数２０９、インター予測パラメータ、イントラ予測パラメータ、及び／又はループ・フィルタ・パラメータに適用し、個々に又は一緒に（又は全てではない）、出力２７２により出力されることが可能な符号化されたピクチャ・データ２１を、例えば符号化されたビットストリーム２１の形式で取得するように構成される。符号化されたビットストリーム２１は、ビデオ・デコーダ３０に送信されてもよいし、後の送信又はビデオ・デコーダ３０による検索のために保存されてもよい。エントロピー符号化ユニット２７０は、符号化される現在のビデオ・スライスのための他のシンタックス要素をエントロピー符号化するように更に構成されることが可能である。

【0134】

ビデオ・エンコーダ２０の他の構造的変形は、ビデオ・ストリームを符号化するために使用されることが可能である。例えば、非変換ベースのエンコーダ２０は、特定のブロック又はフレームについて、変換処理ユニット２０６なしに残差信号を直接的に量子化することが可能である。別の実装において、エンコーダ２０は、量子化ユニット２０８と逆量子化ユニット２１０とを単一のユニットに結合させることが可能である。

【0135】

図３は、本願の実現を実装するように構成された例示的なビデオ・デコーダ３０を示す。ビデオ・デコーダ３０は、符号化されたピクチャ・データ（例えば符号化されたビットストリーム）２１、例えばエンコーダ１００によって符号化されたものを受信して、復号化されたピクチャ１３１を得るように構成される。復号化プロセスの間に、ビデオ・デコーダ３０は、ビデオ・データ、例えば符号化されたビデオ・スライス及び関連するシンタックス要素のピクチャ・ブロックを表す符号化されたビデオ・ビットストリームを、ビデオ・エンコーダ１００から受信する。

【0136】

図３の例では、デコーダ３０は、エントロピー復号化ユニット３０４、逆量子化ユニット３１０、逆変換処理ユニット３１２、再構成ユニット３１４（例えば、加算器３１４）、バッファ３１６、ループ・フィルタ３２０、復号化されたピクチャのバッファ３３０、及び予測処理ユニット３６０を含む。予測処理ユニット３６０は、インター予測ユニット３４４と、イントラ予測ユニット３５４と、モード選択ユニット３６２とを含んでもよい。ビデオ・デコーダ３０は、幾つかの例において、図２によりビデオ・エンコーダ１００に関して説明した符号化パスと概ね逆の復号化パスを実行することが可能である。

【0137】

エンコーダ２０に関して説明したように、逆量子化ユニット２１０、逆変換処理ユニット２１２、再構成ユニット２１４、ループ・フィルタ２２０、復号化されたピクチャのバッファ（ＤＰＢ）２３０、インター予測ユニット３４４、及びイントラ予測ユニット３５４も、ビデオ・エンコーダ２０の「内蔵デコーダ」を形成するものとして言及される。従って、逆量子化ユニット３１０は、逆量子化ユニット１１０と機能的に同一であってもよく、逆変換処理ユニット３１２は、逆変換処理ユニット２１２と機能的に同一であってもよく、再構成ユニット３１４は、再構成ユニット２１４と機能的に同一であってもよく、ループ・フィルタ３２０は、ループ・フィルタ２２０と機能的に同一であってもよく、復号化されたピクチャのバッファ３３０は、復号化されたピクチャのバッファ２３０と機能的に同一であってもよい。従って、ビデオ・エンコーダ２０の各ユニット及び機能に対して行われた説明は、ビデオ・デコーダ３０の各ユニット及び機能に、対応して適用される。

【0138】

エントロピー復号化ユニット３０４は、符号化されたピクチャ・データ２１に対するエントロピー復号化を実行して、例えば量子化係数３０９及び／又は復号化されたコーディング・パラメータ（図３には示されていない）、例えば（復号化された）インター予測パラメータ、イントラ予測パラメータ、ループ・フィルタ・パラメータ、及び／又は他のシンタックス要素の何れか又は全てを取得するように構成される。エントロピー復号化ユニット３０４は、更に、インター予測パラメータ、イントラ予測パラメータ、及び／又は他のシンタックス要素を、予測処理ユニット３６０に転送するように構成される。ビデオ・デコーダ３０は、ビデオ・スライス・レベル及び／又はビデオ・ブロック・レベルでシンタックス要素を受信することができる。

【0139】

エントロピー復号化ユニット３０４は、ビットストリーム２１（又は一般的には符号化されたピクチャ・データ２１）を解析し、例えば符号化されたピクチャ・データ２１に対するエントロピー復号化を実行して、例えば量子化係数３０９及び／又は復号化されたコーディング・パラメータ（図３には示されていない）、例えばインター予測パラメータ（例えば、参照ピクチャ・インデックス及び動きベクトル）、イントラ予測パラメータ（例えば、イントラ予測モード又はインデックス）、変換パラメータ、量子化パラメータ、ループ・フィルタ・パラメータ、及び／又は他のシンタックス要素の何れか又は全てを取得するように構成される。エントロピー復号化ユニット３０４は、エンコーダ２０のエントロピー符号化ユニット２７０に関して説明したような符号化スキームに対応する復号化アルゴリズム又はスキームを適用するように構成されることが可能である。エントロピー復号化ユニット３０４は、更に、インター予測パラメータ、イントラ予測パラメータ及び／又は他のシンタックス要素をモード適用ユニット３６０に提供し、他のパラメータをデコーダ３０の他のユニットに提供するように更に構成されてもよい。ビデオ・デコーダ３０は、ビデオ・スライス・レベル及び／又はビデオ・ブロック・レベルでシンタックス要素を受信することができる。スライス及びそれぞれのシンタックス要素に追加的に又は代替として、タイル・グループ及び／又はタイル及びそれぞれのシンタックス要素が受信及び／又は使用されてもよい。

【0140】

逆量子化ユニット３１０は、逆量子化ユニット１１０と機能的に同一であってもよく、逆変換処理ユニット３１２は、逆変換処理ユニット１１２と機能的に同一であってもよく、再構成ユニット３１４は、機能的に同一であってもよく、バッファ３１６は、バッファ１１６と機能的に同一であってもよく、ループ・フィルタ３２０は、ループ・フィルタ１２０と機能的に同一であってもよく、復号化されたピクチャのバッファ３３０は、復号化されたピクチャのバッファ１３０と機能的に同一であってもよい。

【0141】

デコーダ３０の実施形態は、パーティショニング・ユニット（図３には示されていない）を含んでもよい。一例では、ビデオ・デコーダ３０の予測処理ユニット３６０は、上述したパーティショニング技術の任意の組み合わせを実行するように構成されてもよい。

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

J. An et al.， “Block partitioning structure for next generation video coding”， International Telecommunication Union， COM16-C966， September 2015 (hereinafter， “VCEG proposal COM16-C966”)，
においては、四分木二分木（ＱＴＢＴ）パーティショニング技術が、ＨＥＶＣを越える将来のビデオ・コーディング規格に対して提案されていた。シミュレーションは、提案されているＱＴＢＴ構造が、使用されているＨＥＶＣにおける四分木構造よりも効率的であることを示している。ＨＥＶＣでは、動き補償のメモリ・アクセスを低減するために、小さなブロックに対するインター予測は制限され、４×４ブロックに対してインター予測はサポートされていない。ＪＥＭのＱＴＢＴでは、これらの制約は取り除かれている。

【0174】

ＱＴＢＴでは、ＣＵは正方形又は長方形の何れかの形状を有することができる。図６に示すように、符号化ツリー・ユニット（ＣＴＵ）は、先ず四分木構造によって区分けされる。四分木リーフ・ノードは、二分木構造によって更に区分けされることが可能である。二分木分割では、対称的な水平分割及び対称的な垂直分割の２つの分割タイプが存在する。それぞれの場合において、ノードは、ノードの中央から水平又は垂直に分けることによって分割される。二分木リーフ・ノードは、コーディング・ユニット（ＣＵ）と呼ばれ、そのセグメンテーションは、更なる如何なるパーティショニングもなしに予測及び変換処理に使用される。これは、ＣＵ、ＰＵ、ＴＵがＱＴＢＴコーディング・ブロック構造において同じブロック・サイズを有することを意味する。ＣＵは、しばしば、異なる色成分のコーディング・ブロック（ＣＢ）から構成され、例えば４：２：０のクロマ・フォーマットのＰ及びＢスライスの場合に、１つのＣＵは１つのルマＣＢと２つのクロマＣＢを含み、またしばしば単一成分のＣＢから構成されることもあり、例えばＩスライスの場合に、１つのＣＵは唯１つのルマＣＢ、又は２つのクロマＣＢのみを含む。

【0175】

以下のパラメータがＱＴＢＴパーティショニング・スキームのために定義される。
－ CTU size：四分木のルート・ノード・サイズであり、ＨＥＶＣと同じ概念である。
－ MinQTSize：最小許容四分木リーフ・ノード・サイズ
－ MaxBTSize：最大許容二分木ルート・ノード・サイズ
－ MaxBTDepth：最大許容二分木深度
－ MinBTSize：最小許容二分木リーフ・ノード・サイズ

【0176】

ＱＴＢＴパーティショニング構造の一例では、四分木ノードがMinQTSize以下のサイズを有する場合、更なる四分木は考慮されない。サイズ（MinQTSize）はMaxBTSizeを超えないので、二分木によって更には分割されないであろう。そうでない場合、リーフ四分木ノードは、二分木によって更に区分けされることが可能である。従って、四分木リーフ・ノードは、二分木のルート・ノードでもあり、それは二分木の深度０（ゼロ）を有する。二分木の深度がMaxBTDepth（即ち４）に達した場合、更なる分割は考慮されない。二分木ノードがMinBTSizeに等しい幅（即ち４）を有する場合、更なる水平分割は考慮されない。同様に、二分木ノードのがMinBTSizeに等しい高さを有する場合、更なる垂直分割は考慮されない。二分木のリーフ・ノードは、更なる如何なるパーティショニングもなしに、予測及び変換処理によって更に処理される。ＪＥＭでは、最大ＣＴＵサイズは２５６×２５６ルマ・サンプルである。二分木（ＣＵ）のリーフ・ノードは、更なる如何なるパーティショニングもなしに（例えば、予測プロセス及び変換プロセスを実行することによって）更に処理されてもよい。

【0177】

図６は、ＱＴＢＴパーティショニング技術を用いて区分けされたブロック３０（例えば、ＣＴＢ）の一例を示す。図６に示すように、ＱＴＢＴパーティション技術を用いて、各ブロックは、各ブロックの中心を通って対称的に分割される。図７は、図６のブロック・パーティショニングに対応するツリー構造を示す。図７の実線は四分木分割を示し、点線は二分木分割を示す。一例では、二分木の各分割（即ち、非リーフ）ノードにおいて、シンタックス要素（例えば、フラグ）が、実行される分割のタイプ（例えば、水平又は垂直）を示すためにシグナリングされ、０は水平分割を示し、１は垂直分割を示す。四分木分割の場合、四分木分割は、ブロックを水平及び垂直に、等しいサイズの４つのサブブロックに常に分割するので、分割タイプを指定する必要はない。

【0178】

図７に示されるように、ノード５０において、ブロック３０（ルート５０に対応する）は、ＱＴパーティショニングを用いて、図６に示される４つのブロック３１、３２、３３、及び３４に分割される。ブロック３４は更には分割されず、従ってリーフ・ノードである。ノード５２において、ブロック３１は、ＢＴパーティショニングを用いて２つのブロックに更に分割される。図７に示すように、ノード５２は、垂直分割を示す１でマークされている。従って、ノード５２における分割は、ブロック３７と、ブロック３５及び３６の両方を含むブロックとを生じる結果となる。ブロック３５及び３６は、ノード５４における更なる垂直分割によって生成される。ノード５６において、ブロック３２は、ＢＴパーティショニングを用いて２つのブロック３８及び３９に更に分割される。

【0179】

ノード５８において、ブロック３３は、ＱＴパーティショニングを使用して４つの等しいサイズのブロックに分割される。ブロック４３及び４４は、このＱＴパーティショニングから生成され、更には分割されない。ノード６０において、左上ブロックは、先ず垂直二分木分割を使用して分割され、ブロック４０と右垂直ブロックとを生じる結果となる。右垂直ブロックは、次いで、水平二分木分割を用いてブロック４１及び４２に分割される。ノード５８で四分木分割から作成される右下ブロックは、ノード６２において、水平二分木分割を用いてブロック４５及び４６に分割される。図７に示すように、ノード６２は、水平分割を示す０でマークされている。

【0180】

ＱＴＢＴに加えて、マルチタイプ・ツリー（ＭＴＴ）と名付けられたブロック・パーティショニング構造は、ＱＴＢＴベースのＣＵ構造においてＢＴを置き換えるために提案され、これは、先ずＣＴＵがＱＴパーティショニングによって分割されてＣＴＵのブロックを取得する可能性があること、次いでブロックがＭＴＴパーティショニングによって二次的に分割される可能性があることを意味する。

【0181】

ＭＴＴパーティショニング構造は依然として再帰的ツリー構造である。ＭＴＴでは、複数の異なるパーティション構造（例えば、２つ以上）が用いられる。例えば、ＭＴＴ技術によれば、２つ以上の異なるパーティション構造が、ツリー構造の各深度において、ツリー構造の各自各々の非リーフ・ノードに対して使用される可能性がある。ツリー構造におけるノードの深度は、ノードからツリー構造のルートまでのパスの長さ（例えば、分割の数）を示すことが可能である。

【0182】

ＭＴＴでは、ＢＴパーティショニングと三分木（ＴＴ）パーティショニングの２つのパーティション・タイプがある。パーティション・タイプは、ＢＴパーティショニング及びＴＴパーティショニングから選択されることが可能である。ＴＴパーティション構造は、ＴＴパーティション構造は中心からブロックを分割しない点で、ＱＴやＢＴ構造のものとは異なる。ブロックの中心領域は、同じサブブロック内に一緒に残る。４つのブロックを生成するＱＴ、又は２つのブロックを生成する二分木とは異なり、ＴＴパーティション構造による分割は、３つのブロックを生成する。ＴＴパーティション構造による例示的なパーティション・タイプは、対称パーティション・タイプ（水平及び垂直の両方）に加えて、非対称パーティション・タイプ（水平及び垂直の両方）を含む。更に、ＴＴパーティション構造による対称パーティション・タイプは、不均一／非一様又は均一／一様であってもよい。ＴＴパーティション構造による非対称パーティション・タイプは、不均一／非一様である。一例において、ＴＴパーティション構造は、以下のパーティション・タイプ：水平均一／一様対称三分木、垂直均一／一様対称三分木、水平不均一／非一様対称三分木、垂直不均一／非一様対称三分木、水平不均一／非一様非対称三分木、又は垂直不均一／非一様非対称三分木のパーティション・タイプのうちの少なくとも１つを含むことができる。

【0183】

一般に、不均一／非一様対称三分木パーティション・タイプは、ブロックの中心線に関して対称的なパーティション・タイプであるが、この場合において、結果の３ブロックのうちの少なくとも１つは他の２つと同じサイズではない。１つの好ましい例は、側方ブロックがブロックの１／４のサイズであり、中央ブロックがブロックの１／２サイズである場合である。均一／一様対称三分木パーティション・タイプは、ブロックの中心線に関して対称的なパーティション・タイプであり、結果のブロックはすべて同じサイズである。そのようなパーティションは、垂直又は水平分割に依存して、ブロックの高さ又は幅が３の倍数である場合に可能である。不均一／非一様非対称三分木パーティション・タイプは、ブロックの中心線に関して対称的ではないパーティション・タイプであり、この場合において、結果のブロックの少なくとも１つは他の２つと同じサイズではない。

【0184】

図８は、オプションの例示的な水平三分木パーティション・タイプを示す概念図である。図９は、オプションの例示的な垂直三分木パーティション・タイプを示す概念図である。図８及び図９の両方において、ｈは、ルマ又はクロマ・サンプルにおけるブロックの高さを表し、ｗは、ルマ又はクロマ・サンプルにおけるブロックの幅を表す。ブロックのそれぞれの中心線は、ブロックの境界を表していないこと（即ち、三分木パーティションは中心線を通ってブロックを分割していないこと）に留意されたい。むしろ、中心線＼は、特定のパーティション・タイプがオリジナル・ブロックの中心線に対して対称であるか又は非対称であるかを表すために使用される。また、中心線は分割の方向に沿っている。

【0185】

図８に示すように、ブロック７１は、水平均一／一様対称パーティション・タイプで区分けされる。水平均一／一様対称パーティション・タイプは、ブロック７１の中心線に対して対称的な上及び下半分を生成する。水平均一／一様対称パーティション・タイプは、等しいサイズの３つのサブブロックを生成し、各々はｈ／３の高さとｗの幅とを有する。ブロック７１の高さが均等に３で割り切れる場合、水平均一／一様対称パーティション・タイプが可能である。

【0186】

ブロック７３は、水平不均一／非一様対称パーティション・タイプで区分けされる。水平不均一／非一様対称パーティション・タイプは、ブロック７３の中心線に対して対称的な上及び下半分を生成する。水平不均一／非一様対称パーティション・タイプは、等しいサイズの２つのブロック（例えば、ｈ／４の高さを有する上及び下ブロック）と、異なるサイズの中央ブロック（例えば、ｈ／２の高さを有する中央ブロック）とを生成する。一例では、水平不均一／非一様対称パーティション・タイプによれば、中央ブロックの面積は、上及び下ブロックの合計面積に等しい。幾つかの例において、水平不均一／非一様対称パーティション・タイプは、２の冪乗（例えば、２、４、８、１６、３２など）である高さを有するブロックに対して好ましいかもしれない。

【0187】

ブロック７５は、水平不均一／非一様非対称パーティション・タイプで区分けされる。水平不均一／非一様非対称パーティション・タイプは、ブロック７５の中心線に対して対称的な上及び下半分を生成しない（即ち、上及び下半分は非対称である）。図８の例では、水平不均一／非一様非対称パーティション・タイプは、ｈ／４の高さを有する上ブロックと、３ｈ／８の高さを有する中央ブロックと、３ｈ／８の高さを有する下ブロックとを生成する。もちろん、他の非対称な配置が使用されてもよい。

【0188】

図９に示すように、ブロック８１は、垂直均一／一様対称パーティション・タイプで区分けされる。垂直均一／一様対称パーティション・タイプは、ブロック８１の中心線に対して対称的な左及び右半分を生成する。垂直均一／一様対称パーティション・タイプは、等しいサイズの３つのサブブロックを生成し、各々はｗ／３の幅とｈの高さとを有する。ブロック８１の幅が均等に３で割り切れる場合、垂直均一／一様対称パーティション・タイプが可能である。

【0189】

ブロック８３は、垂直不均一／非一様対称パーティション・タイプで区分けされる。垂直不均一／非一様対称パーティション・タイプは、ブロック８３の中心線に対して対称的な左及び右半分を生成する。垂直不均一／非一様対称パーティション・タイプは、８３の中心線に対して対称的な左及び右半分を生成する。垂直不均一／非一様対称パーティション・タイプは、等しいサイズの２つのブロック（例えば、ｗ／４の幅を有する左及び右ブロック）と、異なるサイズの中央ブロック（例えば、ｗ／２の幅を有する中央ブロック）とを生成する。一例では、垂直不均一／非一様対称パーティション・タイプによれば、中央ブロックの面積は、左及び右ブロックの合計面積に等しい。幾つかの例において、垂直不均一／非一様対称パーティション・タイプは、２の冪乗（例えば、２、４、８、１６、３２など）である幅を有するブロックに対して好ましいかもしれない。

【0190】

ブロック８５は、垂直不均一／非一様非対称パーティション・タイプで区分けされる。垂直不均一／非一様非対称パーティション・タイプは、ブロック８５の中心線に対して対称的な左及び右半分を生成しない（即ち、左及び右半分は非対称である）。図９の例では、垂直不均一／非一様非対称パーティション・タイプは、ｗ／４の幅を有する左ブロックと、３ｗ／８の幅を有する中央ブロックと、３ｗ／８の幅を有する右ブロックとを生成する。もちろん、他の非対称な配置が使用されてもよい。

【0191】

上記で規定したＱＴＢＴのパラメータに加えて（又は代替的に）、ＭＴＴパーティショニング・スキームのために以下のパラメータが規定される：
－ MaxBTSize：最大許容二分木ルート・ノード・サイズ
－ MinBtSize：最小許容二分木ルート・ノード・サイズ
－ MaxMttDepth：最大マルチタイプ・ツリー深度
－ MaxMttDepth offset：最大マルチタイプ・ツリー深度オフセット
－ MaxTtSize：最大許容三分木ルート・ノード・サイズ
－ MinTtSize：最小許容三分木ルート・ノード・サイズ
－ MinCbSize：最小許容コーディング・ブロック・サイズ

【0192】

本開示の実施形態は、本願の実施形態による図２のビデオ・エンコーダ２０又は図３のビデオ・デコーダ３０のようなビデオ・エンコーダ又はビデオ・デコーダによって実現されることが可能である。パーティション・ユニットを含むビデオ・エンコーダ２０又はビデオ・デコーダ３０の１つ以上の構造要素は、開示の実施形態の技術を実行するように構成されることが可能である。

【0193】

開示の実施形態において：
JVET-K1001-v4では、log2_ctu_size_minus2，log2_min_qt_size_intra_slices_minus2及びlog2_min_qt_size_inter_slices_minus2は、ＳＰＳで（シンタックス要素として）シグナリングされる。

【0194】

パラメータlog2_ctu_size_minus2 plus 2は、各ＣＴＵのルマ・コーディング・ツリー・ブロック・サイズを指定する。特に：
CtbLog2SizeY = log2_ctu_size_minus2 + 2 (7-5)
CtbSizeY = 1 << CtbLog2SizeY (7-6)

【0195】

言い換えると、CtbLog2SizeYは、ルマ（Ｙ）に対するコーディング・ツリー・ブロック（ＣＴＢ）サイズに対応するＣＴＵサイズCtbSizeYのlog2値を指定する。

【0196】

更なる設定が以下の通り提供される：
MinCbLog2SizeY = 2 (7-7)
MinCbSizeY = 1 << MinCbLog2SizeY (7-8)
MinTbSizeY = 4 (7-9)
MaxTbSizeY = 64 (7-10)

【0197】

パラメータlog2_min_qt_size_intra_slices_minus2 plus 2は、２（Ｉ）に等しいslice_typeを有するスライス、即ちイントラ・スライスにおけるＣＴＵの四分木分割から生じるリーフ・ブロックの最小ルマ・サイズを指定する。log2_min_qt_size_intra_slices_minus2の値は、0ないしCtbLog2SizeY － 2の両端を含むレンジ内にあるものとする。
MinQtLog2SizeIntraY = log2_min_qt_size_intra_slices_minus2 + 2 (7-22)

【0198】

パラメータlog2_min_qt_size_inter_slices_minus2 plus 2は、０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライス、即ちインター・スライスにおけるＣＴＵの四分木分割から生じるリーフ・ブロックの最小ルマ・サイズを指定する。log2_min_qt_size_inter_slices_minus2の値は、0ないしCtbLog2SizeY － 2の両端を含むレンジ内にあるものとする。
MinQtLog2SizeInterY = log2_min_qt_size_inter_slices_minus2 + 2 (7-23)

【0199】

MinQtSizeYは（７－３０）で規定され、これはルマ・サンプルにおける最小許容四分木分割サイズを意味する。コーディング・ブロック・サイズがMinQtSizeY以下である場合、四分木分割は許容されない。更なる設定が以下の通り提供される：
MinQtLog2SizeY = ( slice_type = = I ) ? MinQtLog2SizeIntraY : MinQtLog2SizeInterY (7-25)
MaxBtLog2SizeY = CtbLog2SizeY － log2_diff_ctu_max_bt_size (7-26)
MinBtLog2SizeY = MinCbLog2SizeY (7-27)
MaxTtLog2SizeY = ( slice_type = = I ) ? 5 : 6 (7-28)
MinTtLog2SizeY = MinCbLog2SizeY (7-29)
MinQtSizeY = 1 << MinQtLog2SizeY (7-30)
MaxBtSizeY = 1 << MaxBtLog2SizeY (7-31)
MinBtSizeY = 1 << MinBtLog2SizeY (7-32)
MaxTtSizeY = 1 << MaxTtLog2SizeY (7-33)
MinTtSizeY = 1 << MinTtLog2SizeY (7-34)
MaxMttDepth = ( slice_type = = I ) ? max_mtt_hierarchy_depth_intra_slices :
max_mtt_hierarchy_depth_inter_slices (7-35)

【0200】

パラメータmax_mtt_hierarchy_depth_intra_slices及びmax_mtt_hierarchy_depth_inter_slicesはそれぞれイントラ及びインター・スライスに対するＭＴＴタイプ分割の最大階層深度を示す。

【0201】

log2_min_qt_size_intra_slices_minus2及びlog2_min_qt_size_inter_slices_minus2のセマンティックに基づいて、log2_min_qt_size_intra_slices_minus2及び log2_min_qt_size_inter_slices_minus2のレンジは、0からCtbLog2SizeY － 2である。
ここで、CtbLog2SizeYはlog2_ctu_size_minus2のセマンティックで規定され、これは各ＣＴＵのルマ・コーディング・ツリー・ブロック・サイズのlog2値を意味し、VTM2.0におけるCtbLog2SizeYは７に等しい。

【0202】

（７－２２）及び（７－２３）に基づいて、MinQtLog2SizeIntraY及びMinQtLog2SizeInterYのレンジは、2からCtbLog2SizeYである。

【0203】

（７－２５）に基づいて、MinQtLog2SizeYのレンジは、2からCtbLog2SizeYである。

【0204】

（７－３０）に基づいて、MinQtSizeYのレンジは、JVET-K1001-v4においては（1<<2）から（1<<CtbLog2SizeY）であり、VTM2.0においてレンジは（1<<2）から（1<<7）であり、これは４から１２８に等しい。

【0205】

JVET-K1001-v4では、log2_diff_ctu_max_bt_sizeはスライス・ヘッダで条件付きでシグナリングされる。

【0206】

パラメータlog2_diff_ctu_max_bt_sizeは、二分割を使用して分割されることが可能なコーディング・ブロックの最大ルマ・サイズ（幅又は高さ）及びルマＣＴＢサイズの間の差分を指定する。log2_diff_ctu_max_bt_sizeの値は、0ないしCtbLog2SizeY － MinCbLog2SizeYの両端を含むレンジ内にあるものとする。

【0207】

log2_diff_ctu_max_bt_sizeが存在しない場合、log2_diff_ctu_max_bt_sizeの値は２に等しいと推定される。

【0208】

MinCbLog2SizeYは（７－７）で規定され、これは最小許容コーディング・ブロック・サイズを意味している。

【0209】

log2_diff_ctu_max_bt_sizeのセマンティックに基づいて、log2_diff_ctu_max_bt_sizeのレンジは、0からCtbLog2SizeY － MinCbLog2SizeYである。

【0210】

（７－２６）に基づいて、MaxBtLog2SizeYのレンジは、CtbLog2SizeYからMinCbLog2SizeYである。

【0211】

（７－３１）に基づいて、MaxBtSizeYのレンジは、(1<< CtbLog2SizeY )から (1<< MinCbLog2SizeY)である。

【0212】

（７－７）に基づいて、MaxBtSizeYのレンジは、JVET-K1001-v4においては、(1<< CtbLog2SizeY )から(1<< 2)であり、VTM2.0においてCtbLog2SizeYは7に等しいので、VTM2.0におけるMaxBtSizeYのレンジは１２８から４に等しい。

【0213】

従って、MinQtSizeYは4から(1<<CtbLog2SizeY)、VTM2.0では４から１２８のレンジを有し、MaxBtSizeYは(1<<CtbLog2SizeY)から4、VTM2.0では１２８から４のレンジを有する。

【0214】

従って、MinQtSizeYはMaxBtSizeYより大きい可能性がある。

【0215】

更に、ＶＶＣ２．０における現在の境界の処理に基づいて、ＱＴ及びＢＴパーティショニングのみが、境界に位置するブロックに対して許容される（ＴＴは許可されず、非分割は許可されない）。

【0216】

現在のコーディング・ブロックが境界上にあり、且つ現在のコーディング・ブロック・サイズcbSizeYが条件：
MinQtSizeY > cbSizeY > MaxBtSizeY
を満たす場合、現在のコーディング・ブロックに対してＱＴ分割もＢＴ分割も可能でない。従って、現在ブロックに対して利用可能なパーティション・モードは存在しない。

【0217】

実施形態１
境界ケースの問題を含む上記の課題の解決策（本発明の実施形態）が以下でより詳細に説明される。

【0218】

実施形態によれば、上記の問題を解決するために、MaxBtSizeYの下限はMinQtSizeYに制限されるべきであり、MaxBtSizeYがMinQtSizeYより小さくないことを確実にする。特に、MaxBtSizeYの下限は、MinQtSizeYに等しい可能性があり、従ってMaxBtSizeYのレンジは、(1<< CtbLog2SizeY)から (1<< MinQtLog2SizeY)であるべきであり、従って、MaxBtLog2SizeYのレンジは、CtbLog2SizeYから MinQtLog2SizeYであるべきであり、従って、log2_diff_ctu_max_bt_sizeのレンジは、0からCtbLog2SizeY - MinQtLog2SizeYであるべきである。従って、MinQtSizeYの情報はMaxBtSizeYの妥当性を決定するために使用されてもよい。換言すれば、MaxBtSizeYはMinQtSizeYの情報に基づいて決定されることが可能である。

【0219】

（ビデオ規格の）ドラフト・テキストにおける対応する変更は、log2_diff_ctu_max_bt_sizeのセマンティックにおいて以下のとおりである：
log2_diff_ctu_max_bt_sizeは、二分割を使用して分割されることが可能なコーディング・ブロックの最大ルマ・サイズ（幅又は高さ）及びルマＣＴＢサイズの間の差分を指定する。log2_diff_ctu_max_bt_sizeの値は、0ないしCtbLog2SizeY － MinQtLog2SizeYの両端を含むレンジ内にあるものとする。

【0220】

コーディング・デバイス（デコーダ又はエンコーダ）によって実現されるコーディングの対応する方法は、以下のようにすることができる：
ピクチャの現在ブロックが境界ブロックであるかどうかを決定する；
現在ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定する；
現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に、二分割を現在ブロックに適用する；最小許容四分木リーフ・ノード・サイズ（MinQtSizeY）は最大許容二分木ルート・ノード・サイズ（MaxBtSizeY）より大きくない。
この場合において、二分割を現在ブロックに適用することは、強制的な二分割を現在ブロックに適用することを含む可能性がある。ここで、コーディングは画像、ビデオ、又は動画コーディングに対応する。

【0221】

境界ブロックであることは、画像／フレーム境界がブロックをカットすること、即ち換言すればブロックが画像／フレーム境界であることを意味する。上記の実施形態では、現在ブロックが境界ブロックであり（条件１）、そのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合に（条件２）、二分割が現在ブロックに適用される。幾つかの実施形態では、二分割の代わりに三分割又は他の分割が使用されてもよいことに留意されたい。更に、幾つかの実施形態では、条件１によらず、条件２の下で二分割が適用されてもよい。換言すれば、条件１は評価されることを要しない。現在ブロックのサイズが、実際に、最小許容四分木リーフ・ノード・サイズよりも大きい場合（即ち、条件２が満たされない場合）、四分木分割が適用されてもよい。

【0222】

二分割が境界ブロックに限って使用される（条件１）実施形態が存在することに留意されたい。非境界ブロックの場合、四分木分割が、使用される唯一の分割である可能性がある。画像／フレームの境界に二（又は三）分割を適用することは、例えば水平境界における水平二／三分割、及び垂直境界における垂直二／三分割のような、潜在的により効率的な分割の利点を提供する。

【0223】

コーディング・デバイス（デコーダ又はエンコーダ）によって実現されるコーディングの別の対応する方法は、以下のようにすることができる：境界ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定し、境界ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きくはなく、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズ（例えば、規格の仕様によるもの）より大きくはない場合に、二分割が境界ブロックに適用される。

【0224】

オプションとして、境界ブロックはコーナー・ブロックを含まない可能性がある。換言すれば、垂直及び水平画像／フレーム境界の両方でカットされるコーナー・ブロックは、上記の条件１の目的に関して境界ブロックとは考えられない。

【0225】

実施形態２
開示の他の実施形態（上述の実施形態と組み合わせることが可能である）が以下に説明される。

【0226】

JVET-K1001-v4では、max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesはＳＰＳでシグナリングされる。換言すれば、max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesはシンタックス要素であり、それらの値は、符号化された画像又はビデオも含むビットストリームに含まれることを意味する。

【0227】

特に、max_mtt_hierarchy_depth_inter_slicesは、０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_inter_slicesの値は、0 ないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。

【0228】

max_mtt_hierarchy_depth_intra_slicesは、２（Ｉ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_intra_slicesの値は、0ないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。

【0229】

MinTbSizeYは（７－９）で規定され、これは４に固定され、従ってMinTbLog2SizeY = log2 MinTbSizeYであり、これは２に固定される。

【0230】

MaxMttDepthが規定され、これはマルチタイプ・ツリー・パーティションの最大許容深度を意味する。現在のマルチタイプ・ツリー・パーティション深度がMaxMttDepth以上である場合には、マルチタイプ・ツリー・パーティションは許容（適用）されない。

【0231】

max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesのセマンティックに基づいて、max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesのレンジは、0からCtbLog2SizeY － MinTbLog2SizeYである。

【0232】

（７－３５）に基づいて、MaxMttDepthのレンジは0からCtbLog2SizeY － MinTbLog2SizeYである。VTM2.0ではCtbLog2SizeYは７に等しいので、MaxMttDepthのレンジは０から５である。

【0233】

従って、MaxMttDepthは0からCtbLog2SizeY － MinTbLog2SizeY、ＶＴＭ２．０では０から５のレンジを有する。

【0234】

ＶＶＣ２．０における現在の境界の処理に基づいて、ＱＴ及びＢＴパーティショニングのみが、境界に位置するブロックに対して許容される（ＴＴは許可されず、非分割は許可されない）。

【0235】

上記の第１の問題が解決されるならば（MaxBtSizeY >= MinQtSizeY）、更に以下の条件が充足される：
cbSizeY <= MinQtSizeY
MaxMttDepth =0

【0236】

境界処理に対して十分なレベルのＢＴ（一般的には、ＴＴを含む任意のＭＴＴ）パーティションは存在しない。

【0237】

例えば、MinQtSizeYは１６に等しく、MinTbSizeYは４に等しく、MaxMttDepthは０である。

【0238】

境界ブロックがcbSizeY =16を有し、ペアレント・パーティションがＱＴであり、このブロックが依然として境界に位置する場合、現在のブロックのMttdepthがMaxMttDepthに到達するので、更なるパーティションを実行することはできない。

【0239】

境界ケースのこの問題の解決策（本発明の実施形態）：上記の問題を解決するため、MaxMttDepthの下限は１に制限され（言い換えると、ゼロの値をとることができない）、ＱＴパーティションの後に、境界ケースに対して十分なレベルのマルチタイプ・ツリー・パーティションが存在することを確実にするべきである。あるいは、更に、MaxMttDepthの下限は（MinQtLog2SizeY- MinTbLog2SizeY）に制限され、ＱＴパーティションの後に、境界及び非境界の両方のケースに十分なレベルのマルチタイプ・ツリー・パーティションが存在することを確実にするべきである。

【0240】

（規格の）ドラフト・テキストにおける対応する変更は、max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesのセマンティックにおいて以下のとおりである：
max_mtt_hierarchy_depth_inter_slicesは、０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_inter_slicesの値は、1ないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。
max_mtt_hierarchy_depth_intra_slicesは、２（Ｉ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_intra_slicesの値は、1ないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。
あるいは、
max_mtt_hierarchy_depth_inter_slicesは、０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_inter_slicesの値は、MinQtLog2SizeY- MinTbLog2SizeYないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。
max_mtt_hierarchy_depth_intra_slicesは、２（Ｉ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_intra_slicesの値は、MinQtLog2SizeY- MinTbLog2SizeYないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。

【0241】

コーディング・デバイス（デコーダ又はエンコーダ）によって実現されるコーディングの対応する方法は、以下のようにすることができる：
画像をブロックに分割し、ブロックは境界ブロックを含む。最大境界マルチタイプ・パーティション深度を有する境界ブロックに二分割を適用する。最大境界マルチタイプ・パーティション深度は、少なくとも最大マルチタイプ・ツリー深度と最大マルチタイプ・ツリー深度オフセットとの合計であり、最大マルチタイプ・ツリー深度は、０より大きい。この実施形態は、実施形態１と組み合わせてもよいし、実施形態１によらずに適用されてもよい。

【0242】

オプションとして、境界ブロックに二分割を適用する場合、最大マルチタイプ・ツリー深度は０より大きい。

【0243】

オプションとして、境界ブロックはコーナー・ブロックを含まない可能性がある。

【0244】

実施形態３
開示の別の実施形態：

【0245】

JVET-K1001-v4において、MinQtSizeY>MaxBtSizeY及びMinQtSizeY> MaxTtSizeYの場合に

【0246】

cbSize = MinQtsizeYの場合には、可能性のある利用可能なパーティション・モードは存在しないので、パーティションはMinCbSizeYに到達することはできない（MinTbSizeY及びMinCbsizeYは固定され、４に等しい）。

【0247】

非境界又は境界のケースのこの問題の解決策：上記の問題を解決するため、MaxBtSizeYの下限はMinQtSizeYに制限され、MaxBtSizeYがMinQtSizeYより小さくないことを確実にするべきである。あるいは、MaxTtSizeYの下限はMinQtSizeYに制限され、MaxTtSizeYがMinQtSizeYより小さくないことを確実にするべきである。

【0248】

ドラフト・テキストにおける対応する変更はセマンティックにおいて
log2_diff_ctu_max_bt_sizeは、二分割を使用して分割されることが可能なコーディング・ブロックの最大ルマ・サイズ（幅又は高さ）とルマＣＴＢサイズとの間の差分を指定する。log2_diff_ctu_max_bt_sizeの値は、0ないしCtbLog2SizeY － MinQtLog2SizeYの両端を含むレンジ内にあるものとする。
及び／又は
log2_min_qt_size_intra_slices_minus2 plus 2は、２（Ｉ）に等しいslice_typeを有するスライスにおけるＣＴＵの四分木分割から生じるリーフ・ブロックの最小ルマ・サイズを指定する。log2_min_qt_size_intra_slices_minus2の値は、0ないしMaxTtLog2SizeY － 2の両端を含むレンジ内にあるものとする。
log2_min_qt_size_inter_slices_minus2 plus 2は、０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライスにおけるＣＴＵの四分木分割から生じるリーフ・ブロックの最小ルマ・サイズを指定する。log2_min_qt_size_inter_slices_minus2の値は、0ないし MaxTtLog2SizeY － 2の両端を含むレンジ内にあるものとする。

【0249】

コーディング・デバイス（デコーダ又はエンコーダ）によって実現されるコーディングの対応する方法は、以下のようにすることができる：
現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定する；
現在ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きくない場合に、マルチタイプ・ツリー分割を現在ブロックに適用する；
この場合において、最小許容四分木のリーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない。

【0250】

オプションとして、最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズより大きくなく、最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない。

【0251】

オプションとして、現在ブロックにマルチタイプ・ツリー分割を適用することは、現在ブロックに三分割を適用すること、又は現在ブロックに二分割を適用することを含む。

【0252】

オプションとして、境界ブロックはコーナー・ブロックを含まない可能性がある。

【0253】

実施形態４
開示の別の実施形態において：

【0254】

MaxBtSizeY >= MinQtSizeY， MinQtSizeY> MinTbLog2SizeY及びMaxMttDepth < (MinQtLog2SizeY- MinTbLog2SizeY)の場合に、
cbSize = MinQtsizeYの場合には、十分なレベルの許容されるマルチタイプ・ツリー・パーティションが存在しないので、パーティションはMinCbSizeYに到達することはできない。

【0255】

非境界のケース又は境界のケースのこの問題の解決策：上記の問題を解決するため、MaxMttDepthの下限は（MinQtLog2SizeY- MinTbLog2SizeY）に限定され、ＱＴパーティションの後に、境界及び非境界の両方のケースに十分なレベルのマルチタイプ・ツリー・パーティションが存在することを確実にするべきである。

【0256】

ドラフト・テキストにおける対応する変更は、max_mtt_hierarchy_depth_inter_slices及びmax_mtt_hierarchy_depth_intra_slicesのセマンティックにおいて以下のとおりである：
max_mtt_hierarchy_depth_inter_slicesは０（Ｂ）又は１（Ｐ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_inter_slicesの値は、MinQtLog2SizeY- MinTbLog2SizeYないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。
max_mtt_hierarchy_depth_intra_slicesは２（Ｉ）に等しいslice_typeを有するスライスにおける四分木リーフのマルチタイプ・ツリー分割から生じるコーディング・ユニットに対する最大階層深度を指定する。max_mtt_hierarchy_depth_intra_slicesの値は、MinQtLog2SizeY- MinTbLog2SizeYないしCtbLog2SizeY － MinTbLog2SizeYの両端を含むレンジ内にあるものとする。

【0257】

コーディング・デバイス（デコーダ又はエンコーダ）によって実現されるコーディングの対応する方法は、以下のようにすることができる：
画像をブロックに分割する；
最終的な最大マルチタイプ・ツリー深度を有するブロックのうちのブロックにマルチタイプ・ツリー分割を適用する。最終的な最大マルチタイプ・ツリー深度は、少なくとも最大マルチタイプ・ツリー深度と最大マルチタイプ・ツリー深度オフセットとの合計である。最大マルチタイプ・ツリー深度は、最小許容四分木リーフ・ノード・サイズのＬｏｇ２値から、最小許容変換ブロック・サイズのＬｏｇ２値を減算したもの以上であるか、又は最大マルチタイプ・ツリー深度は、最小許容四分木リーフ・ノード・サイズのＬｏｇ２値から、最小許容コーディング・ブロック・サイズのＬｏｇ２値を減算したもの以上である。

【0258】

オプションとして、ブロックは非境界ブロックである。

【0259】

オプションとして、最大マルチタイプ・ツリー深度オフセットは０である。

【0260】

オプションとして、ブロックは境界ブロックであり、マルチタイプ・ツリー分割は二分割である。

【0261】

オプションとして、マルチタイプ・ツリー分割は三分割である（又はそれを含む）。

【0262】

オプションとして、境界ブロックはコーナー・ブロックを含まない可能性がある。

【0263】

実施形態１ないし４は、画像／フレームをコーディング・ユニットに分割するため、及びコーディング・ユニットをコーディングするためにエンコーダ側で適用されることが可能である。実施形態１ないし４は、画像／フレーム、即ちコーディング・ユニットのパーティションを提供するため、及びそれに応じてコーディング・ユニットを復号化する（例えば、コーディング・ユニットをストリームから正しく解析し、それらを復号化する）ために、デコーダ側で適用されることが可能である。

【0264】

幾つかの実施形態によれば、１つ以上のプロセッサと、プロセッサに結合され、プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを含むデコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態１ないし４に関連して上述した任意の方法を実行するようにデコーダを構成する。

【0265】

更に、１つ以上のプロセッサと、プロセッサに結合され、プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを含むエンコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態１ないし４に関連して上述した任意の方法を実行するようにエンコーダを構成する。

【0266】

境界パーティショニングに関連する更なる実施形態
ＶＶＣでは、マルチタイプ（二分／三分／四分）ツリー（ＢＴ／ＴＴ／ＱＴ又は二分木／三分木／四分木）セグメンテーション構造は、複数のパーティション・ユニット・タイプの概念を置換するものとするか、又は置換することが可能であり、即ち、最大変換長に対して大きすぎるサイズを有するＣＵに対して必要とされる場合を除いて、ＣＵ、ＰＵ、及びＴＵの概念の区別を除去し、ＣＵパーティション形状に対して、より柔軟性をサポートする。［Ｊ］

【0267】

図１０Ａ－Ｆは、一例として、現在ＶＴＭで使用されているパーティション・モードを示す。図１０Ａは、非分割ブロック（分割なし）を示し、図１０Ｂは、四分又は四分木（ＱＴ）パーティショニングを示し、図１０Ｃは、水平二分又は二分木（ＢＴ）パーティショニングを示し、図１０Ｄは、垂直二分又は二分木（ＢＴ）パーティショニングを示し、図１０Ｅは、水平三分又は三分木（ＴＴ）パーティショニングを示し、図１０Ｆは、ＣＵ又はＣＴＵなどのブロックの垂直三分又は三分木（ＴＴ）パーティショニングを示す。実施形態は、図１０Ａないし１０Ｆに示すように、パーティション・モードを実現するように構成されてもよい。

【0268】

実施形態では、以下のパラメータが、ＢＴ／ＴＴ／ＱＴコーディング・ツリー・スキームのためのシーケンス・パラメータ・セット（ＳＰＳ）シンタックス要素によって規定及び指定されることが可能である：
－ CTU size：四分木のルート・ノード・サイズ
－ MinQTSize：最小許容四分木リーフ・ノード・サイズ
－ MaxBTTSize：最大許容二分及び三分木ルート・ノード・サイズ
－ MaxBTTDepth：最大許容二分及び三分木深度、及び
－ MinBTTSize：最小許容二分及び三分木リーフ・ノード・サイズ

【0269】

他の実施形態では、最小許容四分木リーフ・ノード・サイズMinQTSizeパラメータは、他のヘッダ又はセット、例えばスライス・ヘッダ（ＳＨ）又はピクチャ・パラメータ・セット（ＰＰＳ）に含まれる可能性もある。

【0270】

ＨＥＶＣ規格では、スライス／ピクチャ境界上に位置するコーディング・ツリー・ユニット（ＣＴＵ）又はコーディング・ユニット（ＣＵ）は、リーフ・ノードの右下サンプルがスライス／ピクチャ境界内に位置するまで、四分木（ＱＴ）を用いて強制的に分割されるであろう。強制的なＱＴパーティション又はパーティショニングは、エンコーダ及びデコーダの両方、例えばビデオ・エンコーダ２０及びビデオ・デコーダ３０の両方が、強制的なＱＴを適用する時を知っているので、ビットストリームでシグナリングされることを要しない。強制的なパーティションの目的は、ビデオ・エンコーダ２０／ビデオ・デコーダ３０によって境界ＣＴＵ／ＣＵを可能にすることである。

【0271】

国際特許公開番号ＷＯ２０１６／０９０５６８は、ＱＴＢＴ（四分木プラス二分木）構造を開示しており、またＶＴＭ１．０において、境界ＣＴＵ／ＣＵの強制的なパーティショニング・プロセスがＨＥＶＣから継承される。これは、フレーム境界上に位置するＣＴＵ／ＣＵが、現在のＣＵ全体がピクチャ境界内に入るまで、レート歪（ＲＤ）最適化を考慮せずに、四分木（ＱＴ）構造によって強制的に区分けされることを意味する。これらの強制的なパーティションは、ビットストリームでシグナリングされない。

【0272】

図１１Ａは、強制的なＱＴによって区分けされる高解像度（ＨＤ）（１９２０×１０８０ピクセル）の下境界ＣＴＵ（１２８×１２８）の強制的なパーティション例を示す。図１１において、ＨＤピクチャは１９２０×１０８０ピクセルを有するか、又はそれであり、ＣＴＵは１２８×１２８ピクセルを有するか、又はそれである。

【0273】

サンディエゴ会議（04.2018）［JVET-J1021におけるＣＥ１（パーティショニング）のＳｕｂＣＥ２（ピクチャ境界処理）において、１５個のテストが、ＢＴ、ＴＴ又はＡＢＴ（非対称ＢＴ）を使用するピクチャ境界処理のために提案された。例えば、ＪＶＥＴ－Ｋ０２８０及びＪＶＥＴ－Ｋ０３７６では、境界は図１２に示されるように規定される。図１２は、ドット・ハッシュ線によるピクチャの境界、及び直線における境界ケースのエリア、即ち、下境界ケース、コーナー境界ケース、及び右境界ケースを示す。下境界は、水平な強制的なＢＴ又は強制的なＱＴにより区分けされることが可能であり、右境界は、垂直な強制的なＢＴ又は強制的なＱＴにより区分けされることが可能であり、コーナー・ケースは、強制的なＱＴによってのみ分割されることが可能であり、ここで、何れの強制的なＢＴ又は強制的なＱＴパーティショニングを使用するかの決定は、レート歪最適化基準に基づいており、ビットストリームでシグナリングされる。強制的なパーティショニングは、ブロックが区分けされなければならないことを意味し、例えば、強制的なパーティショニングは、図１０Ａに示されるように「非分割」を使用して、コーディングされない可能性がある境界ブロックに適用される。

【0274】

強制的なＱＴ分割が、強制的な境界パーティショニングで使用される場合、MinQTSizeのパーティショニング制約は無視される。例えば、図１３Ａにおいて、MinQTSizeがＳＰＳにおいて３２としてシグナリングされる場合、境界を、強制的なＱＴ方法と一致させるために、ブロック・サイズ８ｘ８まで落とすＱＴ分割が必要となるであろう。これは、３２であるMinQTSizeの制約を無視する。

【0275】

本開示の実施形態によれば、強制的なＱＴがピクチャ境界パーティショニングのために使用される場合、強制的なＱＴ分割は、例えばＳＰＳでシグナリングされる分割制約に従う、例えば無視しない。更に強制的な分割が必要な場合には、強制的なＢＴのみが使用され、これは組み合わせて強制的なＱＴＢＴとも呼ばれてもよい。本開示の実施形態では、例えば、パーティション制約MinQTSizeは、ピクチャ境界における強制的なＱＴパーティショニングに対して考慮され、強制的なＢＴパーティショニングのための追加のシグナリングは必要とされない。また、実施形態は、通常（非境界）ブロック及び境界ブロックに関するパーティショニングを調和させることを可能にする。例えば、従来の解決策では、通常ブロック・パーティショニングに対して１つ、及び境界ブロック・パーティショニングに対してもう１つという２つの「MinQTSize」パラメータが必要とされる。実施形態は、通常ブロック及び境界のブロックのパーティショニングの両方について１つの共通の「MinQTSize」パラメータを必要とするだけであり、これは、例えば１つの「MinQTSize」パラメータをシグナリングすることによって、エンコーダとデコーダとの間で柔軟に設定されることが可能である。更に、実施形態は、例えば強制的なＱＴよりも少ないパーティションを必要とする。

【0276】

下境界ケース及び右境界ケースに対する解決策
下及び右境界のケースでは、ブロック・サイズがMinQTSizeより大きい場合、ピクチャ境界パーティショニングのためのパーティション・モードは、例えばＲＤＯ（レート歪最適化）に基づいて、強制的なＢＴパーティショニングと強制的なＱＴパーティショニングとの間で選択されることが可能である。そうでない場合（即ち、ブロック・サイズがMinQTSize以下である場合）、強制的なＢＴパーティショニングのみがピクチャ境界パーティショニングに使用され、より具体的には、ピクチャの下境界に位置する境界ブロックそれぞれに対する下境界に、水平な強制的なＢＴが使用され、ピクチャの右境界に位置する境界ブロックそれぞれに対する右境界に、垂直な強制的なＢＴが使用される。

【0277】

強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションがピクチャの下境界に位置するまで、水平な強制的な境界パーティショニングによって、現在ブロックを再帰的に区分けし、リーフ・ノードがピクチャの右境界に完全に位置するまで、垂直な強制的な境界パーティショニングによって、サブ・パーティションを再帰的に区分けすることを含む可能性がある。代替的に、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、垂直な強制的な境界パーティショニングによって、現在ブロックを再帰的に区分けし、リーフ・ノードが右境界に完全に位置するまで、水平な強制的な境界パーティショニングによって、サブ・パーティションを再帰的に区分けすることを含む可能性がある。MinQTSizeは非境界ブロックのパーティショニングを制御するためにも適用される可能性がある。

【0278】

例えば、図１１Ａに示されるケースにおいて、MinQTSizeは３２であるか、又は３２として制限され、ピクチャ境界と一致するために８サンプルの高さ又は幅の矩形（非正方形）ブロックのサイズが必要とされる場合、境界が位置する３２×３２ブロックを区分けするために、強制的なＢＴパーティショニングが使用されるであろう。ＢＴパーティションは、同じタイプの強制的なＢＴパーティショニングを用いて更に区分けされることが可能であり、例えば、強制的な垂直ＢＴパーティショニングが適用されているケースでは、更に、強制的な垂直ＢＴパーティショニングのみが適用され、強制的な水平ＢＴパーティショニングが適用されているケースでは、更に、強制的な水平ＢＴパーティショニングのみが適用される。強制的なＢＴパーティショニングは、リーフ・ノードが完全にピクチャ内に入るまで継続される。

【0279】

図１１Ｂは、本発明の実施形態による、１２８×１２８サンプルのサイズを有する下境界ＣＴＵの例示的なパーティショニングを示す。パーティショニング・ツリーのルート・ブロック又はルート・ノードを形成する下境界ＣＴＵは、より小さなパーティション、例えば正方形又は長方形サイズのより小さなブロックに区分けされる。これらのより小さなパーティション又はブロックは、更に、より小さなパーティション又はブロックに区分けされることが可能である。図１１Ｂにおいて、ＣＴＵは、先ず４つの正方形ブロック７１０、７２０、７３０、及び７４０に四分木分割され、各々が６４×６４サンプルのサイズを有する。これらのブロックのうち、ブロック７１０及び７２０は、再び下境界ブロックであるが、ブロック７３０及び７４０は、ピクチャの外側にあり（それぞれ、ピクチャの外側に位置し）、処理されない。

【0280】

ブロック７１０は、４つの正方形ブロック７５０、７６０、７７０、及び７８０に区分けする四分木を使用して更に区分けされ、各々が３２×３２サンプルのサイズを有する。ブロック７５０及び７６０は、ピクチャの内側に位置するが、ブロック７７０及び７８０は、再び下境界ブロックを形成する。ブロック７７０のサイズは、例えば３２であるMinQTSizeよりも大きくないので、再帰的な水平な強制的な二分パーティショニングがブロック７７０に、リーフ・ノードが完全にピクチャ内にあるか、又は完全にピクチャ内に位置するまで、例えばリーフ・ノード・ブロック７７２、３２×１６サンプルを有する矩形の非正方形ブロックが、ピクチャ内にあるまで（１つの水平二分割の後）、又はリーフ・ノード・ブロック７７４、ピクチャの下境界に位置し且つ３２×８サンプルを有する矩形の非正方形ブロックが、ピクチャ内にあるまで（２つの水平二分割の後）、適用される。同じことがブロック７８０に適用される。

【0281】

本開示の実施形態は、ピクチャ内に完全に位置する通常ブロックのためのパーティショニングと境界ブロックのパーティショニングとを調和させることを可能にする。境界ブロックは、完全にピクチャ内にはなく、完全にピクチャ外にもないブロックである。言い換えると、境界ブロックは、ピクチャ内に位置する部分と、ピクチャ外に位置する部分とを含むブロックである。更に、本開示の実施形態は、MinQTSize以下での強制的なＢＴパーティショニングはシグナリングされる必要がないので、シグナリングを低減させることを許容する。

【0282】

コーナー・ケースに対する解決策
コーナー・ケースでは、幾つかのアプローチは強制的なＱＴ分割のみを許容し、これもMinQTSizeの制約を無視する。本開示の実施形態は、コーナー・ケースに対する２つの解決策を提供する。コーナー・ケースは、現在処理されているブロックがピクチャのコーナーにある場合に生じる。これは、現在ブロックが２つのピクチャ境界（垂直及び水平）によって交差するか、又は隣接する場合である。

【0283】

解決策１：
コーナー・ケースは、下境界のケース又は右境界のケースと考えられる。図１４は、境界定義の実施形態を示す。図１４は、ピクチャの境界をドット・ハッシュ線で示し、境界ケースのエリアを直線で示す。図示されるように、コーナー・ケースは下境界ケースとして定義される。従って、解決策は上述の下境界ケースと右境界ケースに関して説明されたものと同じである。言い換えると、先ず、ブロック又はパーティションが完全にピクチャ内になるまで（垂直方向で）、水平パーティショニングが（下境界のケースに関して説明したように）適用され、次いで、リーフ・ノードが完全にピクチャ内になるまで（水平方向で）、垂直パーティショニングが（右境界のケースに関して説明したように）適用される。境界ケースは境界ブロックであってもよい。

【0284】

解決策２：
境界ケースの定義は、現状のまま保たれる。強制的なＱＴがMinQTSizeによって制約される場合（現在ブロック・サイズはMinQTSize以下である）、水平な強制的なＢＴを用いて下境界に一致させ、下境界が一致する場合は、垂直な強制的なＢＴを用いて右境界に一致させる。

【0285】

例えば、ピクチャのコーナーに位置するブロックについて強制的なＱＴＢＴの実施形態を示す図１３Ａでは、MinQTSizeが、コーナー・ケースの強制的なＱＴパーティションに対して３２であるか、又はそのように制限される場合、強制的なパーティションが終了するまで、３２ｘ３２ブロックのパーティションの後に、更なるＢＴパーティションが使用されるであろう。

【0286】

図１３Ｂは、本発明の実施形態によるピクチャのコーナーにおいて又はその中で境界ＣＴＵの例示的なパーティショニングの更なる詳細を示し、ＣＴＵは１２８×１２８サンプルのサイズを有する。ＣＴＵは先ず４つの正方形ブロックに四分木区分けされ、各々は６４×６４サンプルのサイズを有する。これらのブロックのうち、上左ブロック９１０のみが境界ブロックであり、他の３つは、ピクチャの外側（完全に外側）に位置し、更には処理されない。ブロック９１０は、４つの正方形ブロック９２０、９３０、９４０、及び９５０に区分けする四分木を使用して更に区分けされ、各々が３２×３２サンプルのサイズを有する。ブロック９２０はピクチャの内側に位置し、ブロック９３０、９４０及び９５０は再び境界ブロックを形成する。これらのブロック９３０、９４０、及び９５０のサイズは、３２であるMinQTSizeより大きくないので、強制的な二分割がブロック９３０、９４０、及び９５０に適用される。

【0287】

ブロック９３０は、右境界に位置し、リーフ・ノードがピクチャ内に入るまで、例えば（ここでは、２つの垂直二分割の後に）ブロック９３２がピクチャの右境界に位置するまで、再帰的な垂直な強制的な二分割を用いて区分けされる。

【0288】

ブロック９４０は、下境界に位置し、リーフ・ノードがピクチャ内に入るまで、例えば（ここでは、２つの水平二分割の後に）ブロック９４２がピクチャの右境界に位置するまで、再帰的な水平な強制的な二分割を用いて区分けされる。

【0289】

ブロック９５０は、コーナー境界に位置し、サブ・パーティション又はブロック、ここではブロック９５２が、（ここでは、２つの水平二分割の後に）ピクチャの下境界に位置するまで、第１の再帰的な水平な強制的な二分割を用いて区分けされ、次いで、リーフ・ノード又はブロック、例えばブロック９５４が、（ここでは、２つの垂直二分割の後に）ピクチャの右境界に位置するまで、又はそれぞれリーフ・ノードがピクチャ内に位置するまで、垂直な強制的な境界パーティショニングによりサブ・パーティションを再帰的に区分けする。

【0290】

上記のアプローチは、復号化及び符号化の両方に適用されてもよい。復号化の場合、MinQTSizeはＳＰＳにより受信される可能性がある。符号化の場合、MinQTSizeはＳＰＳにより送信される可能性がある。実施形態は、図１２又は図１４に示すような境界定義、又は他の境界定義を使用してもよい。

【0291】

本開示の更なる実施形態は、以下に提供される。以下のセクションで使用される番号は、前のセクションで使用された番号に必ずしも従う必要はないことに留意すべきである。
実施形態１：パーティショニング方法であって：
ピクチャの現在ブロックが境界ブロックであるかどうかを決定するステップと、
現在ブロックが境界ブロックである場合に、現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するステップと、
現在ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きくない場合に、強制的な二分木分割を現在ブロックに適用するステップとを含む方法。

【0292】

実施形態２：実施形態１のパーティショニング方法において、強制的な二分木パーティショニングは、現在ブロックがピクチャの下境界に位置する場合には再帰的な水平な強制的な二分割であるか、又は現在ブロックがピクチャの右境界に位置する場合には再帰的な垂直な強制的な境界パーティショニングである。

【0293】

実施形態３：実施形態１又は２のパーティショニング方法において、強制的な二分割は、現在ブロックのサブ・パーティションがピクチャの下境界に直接的に位置するまで、水平な強制的な境界パーティショニングによって、現在ブロックを再帰的に区分けし、リーフ・ノードがピクチャの右境界に直接的に完全に位置するまで、又はその逆になるまで、垂直な強制的な境界パーティショニングによって、サブ・パーティションを再帰的に区分けすることを含む。

【0294】

実施形態４：実施形態１－３のうちの何れか１つのパーティショニング方法において、最小許容四分木リーフ・ノード・サイズは、非境界ブロックのパーティショニングを制御するためにも適用される最小許容四分木リーフ・ノード・サイズである。

【0295】

実施形態５：実施形態１－４のうちの何れか１つのパーティショニング方法に従ってブロックを区分けすることにより、ブロックを復号化する復号化方法。

【0296】

実施形態６：実施形態５の復号化方法において、最小許容四分木リーフ・ノード・サイズは、ＳＰＳにより受信される。

【0297】

実施形態７：実施形態１－４のうちの何れか１つのパーティショニング方法に従ってブロックを区分けすることにより、ブロックを符号化する符号化方法。

【0298】

実施形態８：実施形態７の符号化方法において、最小許容四分木リーフ・ノード・サイズは、ＳＰＳにより送信される。

【0299】

実施形態９：実施形態５又は６の何れか１つの方法を実行するように構成された論理回路を含む復号化デバイス。

【0300】

実施形態１０：実施形態７又は８の何れか１つの方法を実行するように構成された論理回路を含む符号化デバイス。

【0301】

実施形態１１：プロセッサにより実行された場合に、実施形態１－８による方法のうちの何れか１つをプロセッサに実行させる命令を記憶する非一時的な記憶媒体。

【0302】

装置は、メモリ要素と、メモリ要素に結合され、ピクチャの現在ブロックが境界ブロックであるかどうかを決定し、現在ブロックが境界ブロックである場合に、現在ブロックのサイズが最小許容四分木（ＱＴ）リーフ・ノード・サイズ（MinQTSize）より大きいかどうかを決定し、現在ブロックのサイズがMinQTSizeより大きくない場合に、強制的な二分木（ＢＴ）パーティショニングを現在ブロックに適用するように構成されたプロセッサ要素とを含む。

【0303】

要約すると、本願（又は本開示）の実施形態は、符号化及び復号化のための装置及び方法を提供する。

【0304】

第１態様は、ピクチャの現在ブロックが境界ブロックであるかどうか、及び、現在ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きいかどうかを決定するステップと、現在ブロックが境界ブロックであり、且つ現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズ（MinQTSize）より大きくない場合に、強制的な二分木（ＢＴ）パーティショニングを現在ブロックに適用するステップとを含むパーティショニング方法に関する。

【0305】

このような第１態様による方法の第１実装形式において、強制的な二分木パーティショニングは、現在ブロックがピクチャの下境界に位置する場合には再帰的な水平な強制的な二分割、又は現在ブロックがピクチャの右境界に位置する場合には再帰的な垂直な強制的な境界パーティショニングである。

【0306】

このような第１態様又は第１態様の任意の先行する実装形式による方法の第２実装形式において、強制的な二分木分割は、リーフ・ノード・ブロックがピクチャ内に入るまで継続される。

【0307】

このような第１態様又は第１態様の任意の先行する実装形式による方法の第３実装形式において、強制的な二分割は、現在ブロックのサブ・パーティションがピクチャの下境界に位置するまで、水平な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードがピクチャの右境界に完全に位置するまで、垂直な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0308】

このような第１態様又は第１態様の任意の先行する実装形式による方法の第４実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、垂直な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、水平な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0309】

このような第１態様又は第１態様の任意の先行する実装形式による方法の第５実装形式において、方法は、非境界ブロックのパーティショニングを制御するために、最小許容四分木リーフ・ノード・サイズを適用するステップを更に含む。

【0310】

このような第１態様又は第１態様の任意の先行する実装形式による方法の第６実装形式において、境界ブロックは、完全にピクチャ内にはなく、完全にピクチャ外にもないブロックである。

【0311】

第２態様は、このような第１態様又は第１態様の任意の先行する実装形式に従ってブロックを区分けすることによってブロックを復号化するための復号化方法に関連する。

【0312】

このような第２態様による方法の第１実装形式において、方法は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、最小許容四分木リーフ・ノード・サイズを受信するステップを更に含む。

【0313】

第３態様は、このような第１態様又は第１態様の任意の先行する実装形式に従ってブロックを区分けすることによってブロックを符号化するための符号化方法に関連する。

【0314】

このような第３態様による方法の第１実装形式において、方法は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、最小許容四分木リーフ・ノード・サイズを送信するステップを更に含む。

【0315】

第４態様は、このような第１態様又は第１態様の任意の先行する実装形式のパーティショニング方法に従ってブロックを区分けすることによってブロックを復号化するように構成された論理回路を含む復号化デバイスに関連する。

【0316】

このような第４態様による復号化デバイスの第１実装形式において、論理回路は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、最小許容四分木リーフ・ノード・サイズを受信するように更に構成されている。

【0317】

第５態様は、このような第１態様又は第１態様の任意の先行する実装形式のパーティショニング方法に従ってブロックを区分けすることによってブロックを符号化するように構成された論理回路を含む符号化デバイスに関連する。

【0318】

このような第５態様による復号化デバイスの第１実装形式において、論理回路は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、最小許容四分木リーフ・ノード・サイズを送信するように更に構成されている。

【0319】

第６態様は、プロセッサによって実行される場合に、このような任意の第１、第２、第３態様又は第１、第２、第３態様の任意の先行する実装形式をプロセッサに実行させる命令を記憶するための非一時的な記憶媒体に関連する。

【0320】

第７態様は、ピクチャの現在ブロックが境界ブロックであること、及び、現在ブロックのサイズが、最小許容四分木（ＱＴ）リーフ・ノード・サイズ（MinQTSize）以下であること判断するステップと、判断に応じて、強制的な二分木（ＢＴ）パーティショニングを現在ブロックに適用するステップとを含む方法に関する。

【0321】

このような第７態様による方法の第１実装形式において、現在ブロックはピクチャの下境界に位置し、強制的ＢＴパーティショニングは再帰的な水平な強制的なＢＴパーティショニングである。

【0322】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第２実装形式において、現在ブロックはピクチャの右境界に位置し、強制的なＢＴパーティショニングは再帰的な垂直な強制的なＢＴパーティショニングである。

【0323】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第３実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、水平な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、垂直な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0324】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第４実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、垂直な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、水平な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0325】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第５実装形式において、方法は、非境界ブロックのパーティショニングを制御するためにＭｉｎＱＴＳｉｚｅを適用するステップを更に含む。

【0326】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第６実装形式において、方法は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、ＭｉｎＱＴＳｉｚｅを受信するステップを更に含む。

【0327】

このような第７態様又は第７態様の任意の先行する実装形式による方法の第７実装形式において、方法は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、ＭｉｎＱＴＳｉｚｅを送信するステップを更に含む。

【0328】

第８態様は、メモリと、メモリに結合され、ピクチャの現在ブロックが境界ブロックであるかどうかを決定し、現在ブロックが境界ブロックである場合に、現在ブロックのサイズが、最小許容四分木（ＱＴ）リーフ・ノード・サイズ（MinQTSize）より大きいかどうかを決定し、現在ブロックのサイズがMinQTSizeより大きくない場合に、強制的な二分木（ＢＴ）パーティショニングを現在ブロックに適用するように構成されたプロセッサとを含む装置に関連する。

【0329】

このような第８態様による装置の第１実装形式において、強制的なＢＴパーティショニングは、現在ブロックがピクチャの下境界に位置する場合には再帰的な水平な強制的なＢＴパーティショニング、又は現在ブロックがピクチャの右境界に位置する場合には再帰的な垂直な強制的なＢＴパーティショニングである。

【0330】

このような第８態様又は第８態様の任意の先行する実装形式による装置の第２実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、水平な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、垂直な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0331】

このような第８態様又は第８態様の任意の先行する実装形式による装置の第３実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、垂直な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、水平な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0332】

このような第８態様又は第８態様の任意の先行する実装形式による装置の第４実装形式において、プロセッサは、非境界ブロックのパーティショニングを制御するためにMinQTSizeを適用するように更に構成されている。

【0333】

このような第８態様又は第８態様の任意の先行する実装形式による装置の第５実装形式において、装置は、プロセッサに結合され、シーケンス・パラメータ・セット（ＳＰＳ）を介して、MinQTSizeを受信するように構成された受信機を更に含む。

【0334】

このような第８態様又は第８態様の任意の先行する実装形式による装置の第６実装形式において、装置は、プロセッサに結合され、シーケンス・パラメータ・セット（ＳＰＳ）を介して、MinQTSizeを送信するように構成された送信機を更に含む。

【0335】

第９態様は、非一時的な媒体に記憶されたコンピュータ実行可能命令を含むコンピュータ・プログラム製品に関連し、命令は、プロセッサにより実行されると、ピクチャの現在ブロックが境界ブロックであるかどうかを決定し、現在ブロックが境界ブロックである場合に、現在ブロックのサイズが、最小許容四分木（ＱＴ）リーフ・ノード・サイズ（MinQTSize）より大きいかどうかを決定し、現在ブロックのサイズがMinQTSizeより大きくない場合に、強制的な二分木（ＢＴ）パーティショニングを現在ブロックに適用することを装置に行わせる。

【0336】

このような第８態様による装置の第１実装形式において、強制的なＢＴパーティショニングは、現在ブロックがピクチャの下境界に位置する場合には再帰的な水平な強制的なＢＴパーティショニング、又は現在ブロックがピクチャの右境界に位置する場合には再帰的な垂直な強制的なＢＴパーティショニングである。

【0337】

このような第９態様又は第９態様の任意の先行する実装形式による装置の第２実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、水平な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、垂直な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0338】

このような第９態様又は第９態様の任意の先行する実装形式による装置の第３実装形式において、強制的なＢＴパーティショニングは、現在ブロックのサブ・パーティションが下境界に位置するまで、垂直な強制的な境界パーティショニングによって現在ブロックを再帰的に区分けするステップと、リーフ・ノードが右境界に完全に位置するまで、水平な強制的な境界パーティショニングによってサブ・パーティションを再帰的に区分けするステップとを含む。

【0339】

このような第９態様又は第９態様の任意の先行する実装形式による装置の第４実装形式において、命令は、非境界ブロックのパーティショニングを制御するためにMinQTSizeを適用することを装置に更に行わせる。

【0340】

このような第９態様又は第９態様の任意の先行する実装形式による装置の第５実装形式において、命令は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、MinQTSizeを受信することを装置に更に行わせる。

【0341】

このような第９態様又は第９態様の任意の先行する実装形式による装置の第６実装形式において、命令は、シーケンス・パラメータ・セット（ＳＰＳ）を介して、MinQTSizeを送信することを装置に更に行わせる。

【0342】

幾つかの実施形態によれば、１つ以上のプロセッサと、プロセッサに結合され、プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを含むデコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態１ないし４に関連して上述した任意の方法を実行するようにデコーダを構成する。

【0343】

更に、１つ以上のプロセッサと、プロセッサに結合され、プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを含むエンコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態１ないし４に関連して上述した任意の方法を実行するようにエンコーダを構成する。

【0344】

以下は、上述した実施形態で示されるような復号化方法と同様な符号化方法、及びそれを使用するシステムの適用の説明である。

【0345】

図１７は、コンテンツ配信サービスを実現するためのコンテンツ供給システム３１００を示すブロック図である。このコンテンツ供給システム３１００は、捕捉デバイス３１０２と、端末デバイス３１０６とを含み、オプションとしてディスプレイ３１２６を含む。捕捉デバイス３１０２は、通信リンク３１０４を介して端末デバイス３１０６と通信する。通信リンクは、上述の通信チャネル１３を含んでもよい。通信リンク３１０４は、ＷＩＦＩ、イーサーネット、ケーブル、無線（３Ｇ／４Ｇ／５Ｇ）、ＵＳＢ、又はそれらの任意の種類の組み合わせ等を含むが、これらに限定されない。

【0346】

捕捉デバイス３１０２は、データを生成し、上記の実施形態に示されるように、符号化方法によってデータを符号化してもよい。あるいは、捕捉デバイス３１０２は、ストリーミング・サーバー（不図示）にデータを分配することが可能であり、サーバーは、データを符号化し、符号化されたデータを端末デバイス３１０６に送信する。捕捉デバイス３１０２は、カメラ、スマートフォン又はパッド、コンピュータ又はラップトップ、ビデオ会議システム、ＰＤＡ、車載デバイス、又はそれら任意の組み合わせ等を含むが、これらに限定されない。例えば、捕捉デバイス３１０２は、上述のようにソース・デバイス１２を含んでもよい。データがビデオを含む場合、捕捉デバイス３１０２に含まれるビデオ・エンコーダ２０は、実際にビデオ符号化処理を実行することができる。データがオーディオ（即ち、声）を含む場合、捕捉デバイス３１０２に含まれるオーディオ・エンコーダは、実際にオーディオ符号化処理を実行することができる。幾つかの実際的なシナリオでは、捕捉デバイス３１０２は、符号化されたビデオ及びオーディオ・データを、それらを一緒に多重化することによって分配する。他の実際的なシナリオ、例えばビデオ会議システムにおいては、符号化されたオーディオ・データ及び符号化されたビデオ・データは多重化されない。捕捉デバイス３１０２は、符号化されたオーディオ・データ及び符号化されたビデオ・データを別々に端末デバイス３１０６に分配する。

【0347】

コンテンツ供給システム３１００では、端末デバイス３１０は、符号化されたデータを受信及び再生する。端末デバイス３１０６は、スマートフォン又はパッド３１０８、コンピュータ又はラップトップ３１１０、ネットワーク・ビデオ・レコーダ（ＮＶＲ）／デジタル・ビデオ・レコーダ（ＤＶＲ）３１１２、ＴＶ３１１４、セット・トップ・ボックス（ＳＴＢ）３１１６、ビデオ会議システム３１１８、ビデオ監視システム３１２０、携帯デジタル・アシスタント（ＰＤＡ）３１２２、車載デバイス３１２４、又はこれらの任意の組み合わせ、又は上述した符号化されたデータを復号化することができるもののような、データ受信及び復元能力を有するデバイスであるとすることが可能である。例えば、端末デバイス３１０６は、上述したような宛先デバイス１４を含んでもよい。符号化されたデータがビデオを含む場合、端末デバイスに含まれるビデオ・デコーダ３０は、ビデオ復号化を実行するように優先される。符号化されたデータがオーディオを含む場合、端末デバイスに含まれるオーディオ・デコーダは、オーディオ復号化処理を実行するように優先される。

【0348】

ディスプレイを有する端末デバイス、例えば、スマートフォン又はパッド３１０８、コンピュータ又はラップトップ３１１０、ネットワーク・ビデオ・レコーダ（ＮＶＲ）／デジタル・ビデオ・レコーダ（ＤＶＲ）３１１２、ＴＶ３１１４、パーソナル・デジタル・アシスタント（ＰＤＡ）３１２２、又は車載デバイス３１２４の場合、端末デバイスは、復号化されたデータをそのディスプレイに供給することができる。例えば、ＳＴＢ３１１６、ビデオ会議システム３１１８、又はビデオ監視システム３１２０のようなディスプレイを備えない端末デバイスについては、復号化されたデータを受信及び表示するために、外部ディスプレイ３１２６がそこに付けられる。

【0349】

このシステムにおける各デバイスが符号化又は復号化を実行する場合に、上記の実施形態に示されるように、ピクチャ符号化デバイス又はピクチャ復号化デバイスを使用することができる。

【0350】

図１８は、端末デバイス３１０６の一例の構成を示す図である。端末デバイス３１０６が捕捉デバイス３１０２からストリームを受信した後に、プロトコル処理ユニット３２０２は、ストリームの送信プロトコルを分析する。プロトコルは、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ＨＴＴＰライブ・ストリーミング・プロトコル（ＨＬＳ）、ＭＰＥＧ－ＤＡＳＨ、リアル・タイム転送プロトコル（ＲＴＰ）、リアル・タイム・メッセージング・プロトコル（ＲＴＭＰ）、又はそれらの任意の種類の組み合わせ等を含むが、これらに限定されない。

【0351】

プロトコル処理ユニット３２０２がストリームを処理した後に、ストリーム・ファイルが生成される。ファイルは、逆多重化ユニット３２０４に出力される。逆多重化ユニット３２０４は、多重化されたデータを、符号化されたオーディオ・データ及び符号化されたビデオ・データに分離することができる。上述したように、幾つかの実際的なシナリオに関し、例えばビデオ会議システムにおいて、符号化されたオーディオ・データ及び符号化されたビデオ・データは多重化されない。この状況では、符号化されたデータは、逆多重化ユニット３２０４を介することなく、ビデオ・デコーダ３２０６及びオーディオ・デコーダ３２０８に送信される。

【0352】

逆多重化処理により、ビデオ要素ストリーム（ＥＳ）、オーディオＥＳ、及びオプションとして字幕が生成される。上述の実施形態で説明したようなビデオ・デコーダ３０を含むビデオ・デコーダ３２０６は、上述の実施形態で示されるような復号化方法によってビデオＥＳを復号化してビデオ・フレームを生成し、このデータを同期ユニット３２１２へ送る。オーディオ・デコーダ３２０８は、オーディオＥＳを復号化してオーディオ・フレームを生成し、このデータを同期ユニット３２１２へ送る。代替的に、ビデオ・フレームは、それを同期ユニット３２１２へ供給する前に、バッファ（図１８では示されていない）に格納してもよい。同様に、オーディオ・フレームは、それを同期ユニット３２１２へ供給する前に、バッファ（図１８では示されていない）に格納してもよい。

【0353】

同期ユニット３２１２は、ビデオ・フレーム及びオーディオ・フレームを同期させ、ビデオ／オーディオをビデオ／オーディオ・ディスプレイ３２１４に供給する。例えば、同期ユニット３２１２は、ビデオ及びオーディオ情報の提示を同期させる。情報は、コーディングされたオーディオ及びビジュアル・データの提示に関するタイムスタンプとデータ・ストリーム自体の配信に関するタイムスタンプとを使用して、シンタックスでコーディングしてもよい。

【0354】

字幕がストリームに含まれる場合、字幕デコーダ３２１０は、字幕を復号化し、それをビデオ・フレーム及びオーディオ・フレームと同期させ、ビデオ／オーディオ／字幕をビデオ／オーディオ／字幕ディスプレイ３２１６に供給する。

【0355】

本発明は、上述のシステムには限定されず、上述の実施形態におけるピクチャ符号化デバイス又はピクチャ復号化デバイスの何れかが、他のシステム、例えば車両システムに組み込まれることが可能である。

【0356】

本発明の実施形態は、主にビデオ・コーディングに基づいて説明されてきたが、コーディング・システム１０、エンコーダ２０及びデコーダ３０（及び対応するシステム１０）の実施形態、並びに本願で説明される他の実施形態はまた、静止画の処理又はコーディング、即ちビデオ・コーディングにおけるように、任意の先行する又は連続するピクチャから独立した個々のピクチャの処理又はコーディングのために構成されてもよいことに留意すべきである。一般に、ピクチャ処理コーディングが単一のピクチャ１７に限定される場合、インター予測ユニット２４４（エンコーダ）及び３４４（デコーダ）のみが利用できない可能性がある。ビデオ・エンコーダ２０及びビデオ・デコーダ３０の他の全ての機能（ツール又は技術とも呼ばれる）は、静止画処理、例えば残差計算２０４／３０４、変換２０６、量子化２０８、逆量子化２１０／３１０、（逆）変換２１２／３１２、パーティショニング２６２／３６２、イントラ予測２５４／３５４、及び／又はループ・フィルタリング２２０、３２０、及びエントロピー・コーディング２７０及びエントロピー復号化３０４に関して同様に使用することが可能である。

【0357】

例えば、エンコーダ２０及びデコーダ３０の実施形態、並びに例えばエンコーダ２０及びデコーダ３０に関連して本願で説明される機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせで実現されることが可能である。ソフトウェアで実現される場合、機能は、コンピュータ読み取り可能な媒体に記憶されるか、１つ以上の命令又はコードとして通信媒体を介して伝送され、ハードウェア・ベースの処理ユニットによって実行されることが可能である。コンピュータ読み取り可能な媒体は、データ記憶媒体のような有形媒体に対応するコンピュータ読み取り可能な記憶媒体、又は、例えば通信プロトコルに従って、ある場所から他の場所へのコンピュータ・プログラムの転送を促す任意の媒体を含む通信媒体を含んでもよい。このように、コンピュータ読み取り可能な媒体は、一般に、（１）非一時的である有形のコンピュータ読み取り可能な記憶媒体、又は（２）信号又は搬送波のような通信媒体に対応する可能性がある。データ記憶媒体は、本開示で説明される技術の実施のための命令、コード及び／又はデータ構造を取り出すために、１つ以上のコンピュータ又は１つ以上のプロセッサによってアクセスされることが可能な任意の利用可能な媒体である可能性がある。コンピュータ・プログラム製品は、コンピュータ読み取り可能な媒体を含む可能性がある。

【0358】

１つ以上の例において、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせで実現される可能性がある。ソフトウェアで実現される場合、機能は、コンピュータ読み取り可能な媒体における１つ以上の命令又はコードとして記憶され又は伝送され、ハードウェア・ベースの処理ユニットによって実行されてもよい。コンピュータ読み取り可能な媒体は、データ記憶媒体のような有形媒体に対応するコンピュータ読み取り可能な記憶媒体、又は、例えば通信プロトコルに従って、ある場所から他の場所へのコンピュータ・プログラムの転送を促す任意の媒体を含む通信媒体を含んでもよい。このように、コンピュータ読み取り可能な媒体は、一般に、（１）非一時的である有形のコンピュータ読み取り可能な記憶媒体、又は（２）信号又は搬送波のような通信媒体に対応する可能性がある。データ記憶媒体は、本開示で説明される技術の実施のための命令、コード及び／又はデータ構造を取り出すために、１つ以上のコンピュータ又は１つ以上のプロセッサによってアクセスされることが可能な任意の利用可能な媒体である可能性がある。コンピュータ・プログラム製品は、コンピュータ読み取り可能な媒体を含む可能性がある。

【0359】

例えば、限定ではないが、このようなコンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ又は他の光ディスク・ストレージ、磁気ディスク・ストレージ、又は他の磁気ストレージ・デバイス、フラッシュ・メモリ、又は、任意の他の媒体であって命令又はデータ構造の形式で所望のプログラム・コードを記憶するために使用することが可能であり且つコンピュータによってアクセスされることが可能な媒体を含むことが可能である。また、任意の接続が、コンピュータ読み取り可能な媒体と適宜呼ばれる。例えば、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波のような無線技術を用いて、ウェブサイト、サーバー、又は他のリモート・ソースから、命令が送信される場合、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、ＤＳＬ、又は赤外線、無線、及びマイクロ波のような無線技術は、媒体の定義に含まれる。しかしながら、コンピュータ読み取り可能な記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時的な媒体を含まず、むしろ非一時的な有形の記憶媒体に向けられることが理解されるはずである。ディスク及びディスクは、本願で使用されるように、コンパクト・ディスク（ＣＤ）、レーザー・ディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー・ディスク及びブルーレイ・ディスクを含み、ディスクは、通常、磁気的にデータを再生し、ディスクは光学的にレーザーでデータを再生する。上記の組み合わせもまた、コンピュータ読み取り可能な媒体の範囲内に含まれるはずである。

【0360】

命令は、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル論理アレイ（ＦＰＧＡ）、又は他の同等な集積又は個別論理回路のような１つ以上のプロセッサによって実行されることが可能である。従って、本願で使用されるような「プロセッサ」という用語は、前述の構造の何れか、又は本願で説明される技術の実装に適した他の任意の構造を指す可能性がある。更に、幾つかの態様において、本願で説明される機能は、符号化及び復号化のために構成される専用ハードウェア及び／又はソフトウェアモジュール内で提供されてもよいし、又は組み合わせられたコーデックに組み込まれてもよい。また、技術は１つ以上の回路又は論理素子で完全に実装されることが可能である。

【0361】

本開示の技術は、ワイヤレス・ハンドセット、集積回路（ＩＣ）、又は一組のＩＣ（例えば、チップ・セット）を含む広く様々なデバイス又は装置で実現されことが可能である。開示される技術を実行するように構成されるデバイスの機能的側面を強調するために、種々のコンポーネント、モジュール、又はユニットが本開示で説明されているが、必ずしも異なるハードウェア・ユニットによる実現を必要としていない。むしろ、上述のように、種々のユニットは、コーデック・ハードウェア・ユニット内で組み合わされてもよく、又は、適切なソフトウェア及び／又はファームウェアと共に、上述のような１つ以上のプロセッサを含む、相互運用可能なハードウェア・ユニットの集合によって提供されてもよい。

【0362】

以下の論理演算子又は数学演算子は次のように定義される。
本願で使用される数学演算子は、Ｃプログラミング言語で使用されるものに類似している。しかしながら、整数除算及び算術シフト演算の結果は、より正確に定義され、指数化や実数値除算などの追加的な演算が規定される。番号付け及びカウントの規則は一般に０から始まり、例えば、“第１”は０番目と同等であり、“第２”は１番目と同等、等々である。

【0363】

算術演算子
以下の算術演算子は次のように規定される：

【表1】

【0364】

論理演算子
以下の論理演算子は次のように規定される：
ｘ＆＆ｙ ｘ及びｙのブール論理“ａｎｄ”
ｘ｜｜ｙ ｘ及びｙのブール論理“ｏｒ”
！ ブール論理“ｎｏｔ”
ｘ？ｙ：ｚ ｘがＴＲＵＥであるか又は０に等しくない場合には、ｙの値を評価し、そうでなければｚの値を評価する。

【0365】

関係演算子
以下の関係演算子は次のように規定される：
＞ より大きい
＞＝ より大きい又は等しい
＜ より小さい
＜＝ より小さい又は等しい
＝＝ に等しい
！＝ に等しくない

関係演算子が、値“ｎａ”（適用可能でない）を指定されているシンタックス要素又は変数に適用される場合、値“ｎａ”はそのシンタックス要素又は変数の別個の値として扱われる。値“ｎａ”は他の如何なる値にも等しくないと考えられる。

【0366】

ビット・ワイズ演算子
以下のビット・ワイズ演算子は次のように規定される：
＆ ビット・ワイズ“ａｎｄ”。整数引数に関して作用する場合、整数値の２の補数表現に関して作用する。他の引数より少ないビットを含む二進引数に関して作用する場合、より短い引数は、０に等しい更なる上位ビットを加えることによって拡張される。
｜ ビット・ワイズ“ｏｒ”。整数引数に関して作用する場合、整数値の２の補数表現に関して作用する。他の引数より少ないビットを含む二進引数に関して作用する場合、より短い引数は、０に等しい更なる上位ビットを加えることによって拡張される。
＾ ビット・ワイズ“排他的ｏｒ”。整数引数に関して作用する場合、整数値の２の補数表現に関して作用する。他の引数より少ないビットを含む二進引数に関して作用する場合、より短い引数は、０に等しい更なる上位ビットを加えることによって拡張される。
ｘ＞＞ｙ ｘの２の補数整数表現をｙという二進数だけ算術右シフトしたもの。この関数はｙの非負の整数値についてのみ規定される。右シフトの結果として最上位ビット（ＭＳＢ）にシフトされたビットは、シフト操作前のｘのＭＳＢに等しい。
ｘ＜＜ｙ ｘの２の補数整数表現をｙという二進数だけ算術左シフトしたもの。この関数はｙの非負の整数値についてのみ規定される。左シフトの結果として最下位ビット（ＬＳＢ）にシフトされたビットは、０に等しい値を有する。

【0367】

代入演算子
以下の代入演算子は次のように規定される：
＝ 代入演算子
＋＋ インクリメント。即ち、ｘ＋＋はｘ＝ｘ＋１に等しい。配列インデックスで使用される場合、インクリメント演算前の変数の値を評価する。
－－ デクリメント。即ち、ｘ－－はｘ＝ｘ－１に等しい。配列インデックスで使用される場合、デクリメント演算前の変数の値を評価する。
＋＝ 指定された量によるインクリメント。即ち、ｘ＋＝３はｘ＝ｘ＋３に等しい。ｘ＋＝（－３）はｘ＝ｘ＋（－３）に等しい。
－＝ 指定された量によるデクリメント。即ち、ｘ－＝３はｘ＝ｘ－３に等しい。ｘ－＝（－３）はｘ＝ｘ－（－３）に等しい。

【0368】

レンジ表記
以下の表記が値のレンジを指定するために使用される：
ｘ＝ｙ．．ｚ ｘはｙから始まってｚまでの両端を含む整数値をとり、ｘ、ｙ及びｚは整数であり、ｚはｙより大きい。

【0369】

数学関数
以下の数学関数が規定される：

【表2】

【0370】

演算優先順序
括弧を利用することによって表式で優先順位が明示的に指定されていない場合、以下のルールを適用する：
－ より高い優先順位の演算は、より低い優先順位の如何なる演算よりも前に評価される。
－ 同じ優先順位の演算は、左から右へ順に評価される。

【0371】

以下の表は、最高から最低までの演算の優先順位を示し、表中でより高い位置は、より高い優先順位を示す。

【0372】

Ｃプログラミング言語でも使用されている演算子に関し、本明細書で使用される優先順位は、Ｃプログラミング言語で使用されるものと同じである
表：最高（表の上）から最低（表の下）までの演算優先順位

【表3】

【0373】

論理演算子のテキスト記述
テキストにおいて、以下の形式：
if( condition 0 )
statement 0
else if( condition 1 )
statement 1
...
else /* informative remark on remaining condition */
statement n
で数学的に記述されるような論理演算子のステートメントは、以下の方法で記述されることが可能である：
…as follows／...the following applies：
－ If condition 0， statement 0
－ Otherwise， if condition 1， statement 1
－ ...
－ Otherwise (informative remark on remaining condition)， statement n

【0374】

テキストにおける各々の“If ... Otherwise， if ... Otherwise， ...”ステートメントは、“If...”の直後に続く“... as follows”又は“... the following applies”とともに導入される。“If ... Otherwise， if ... Otherwise， ...”の最後の条件は、常に“Otherwise， ...”である。交互の“If ... Otherwise， if ... Otherwise， ...”ステートメントは、“... as follows”又は“... the following applies”を末尾の“Otherwise， ...”と一致させることによって確認することが可能である。

【0375】

テキストにおいて、以下の形式：
if( condition 0a && condition 0b )
statement 0
else if( condition 1a ｜｜ condition 1b )
statement 1
...
else
statement n
で数学的に記述されるような論理演算子のステートメントは、以下の方法で記述されることが可能である：
... as follows / ... the following applies:
－ If all of the following conditions are true， statement 0:
－condition 0a
－condition 0b
－ Otherwise， if one or more of the following conditions are true， statement 1:
－condition 1a
－condition 1b
－ ...
－ Otherwise， statement n

【0376】

テキストにおいて、以下の形式：
if( condition 0 )
statement 0
if( condition 1 )
statement 1
で数学的に記述されるような論理演算子のステートメントは、以下の方法で記述されることが可能である：
condition 0である場合には、statement 0
condition 1である場合には、statement 1

【0377】

要約すると、本開示は、画像又はビデオ信号の符号化及び復号化のために使用される方法及びデバイスに関連する。これらは、現在ブロックのサイズが、最小許容四分木リーフ・ノード・サイズより大きいかどうかの決定を含む。現在ブロックのサイズが最小許容四分木リーフ・ノード・サイズより大きくない場合、マルチタイプ・ツリー分割が現在ブロックに適用される。最小許容四分木リーフ・ノード・サイズは、最大許容二分木ルート・ノード・サイズより大きくないか、又は最小許容四分木リーフ・ノード・サイズは、最大許容三分木ルート・ノード・サイズより大きくない。

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13A】

【図13B】

【図14】

【図15】

【図16】

【図17】

【図18】