JP7163183B2 - ビデオコード化のためのマルチタイプツリーフレームワーク - Google Patents

Description

関連出願

[0001]本願は、２０１６年１月１５日に出願された米国仮特許出願第６２／２７９，２３３号の利益を主張し、この全内容は、参照によりここに組み込まれる。

[0002]本開示は、ビデオ符号化およびビデオ復号に関する。

[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲーム機、セルラ式または衛星無線電話、いわゆる「スマートフォン」、ビデオテレビ会議デバイス、ビデオストリーミングデバイス、および同様のものを含む、広範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４，パート１０，アドバンスドビデオコーディング（ＡＶＣ）によって定義されている規格、高効率ビデオコーディング（ＨＥＶＣ）規格、およびそのような規格の拡張で説明されているもののようなビデオコーディング技法をインプリメントする。ビデオデバイスは、そのようなビデオコーディング技法をインプリメントすることで、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。

[0004]ビデオコーディング技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を含む。ブロックベースのビデオコード化の場合、ビデオスライス（例えば、ビデオピクチャ／フレームまたはビデオピクチャの一部）は、ツリーブロック、コード化単位（ＣＵ）および／またはコード化ノードとも呼ばれ得る、ビデオブロックへと区分化され得る。ピクチャは、フレームと呼ばれ得る。参照ピクチャは、参照フレームと呼ばれ得る。

[0005]空間または時間予測は、コード化されることとなるブロックについての予測ブロックをもたらす。残差データは、コード化されることとなる元のブロックと予測ブロックとの間の画素差を表す。さらなる圧縮のために、残差データが画素ドメインから変換ドメインに変換され得、これは、残差変換係数をもたらし、これは、その後、量子化され得る。エントロピーコード化は、さらなる圧縮を達成するために適用され得る。

[0006]本開示は、マルチタイプツリー（ＭＴＴ）フレームワークを使用してビデオデータのブロックを区分化するための技法を説明する。本開示の技法は、ツリー構造の様々なノードにおいて複数の区分化技法のうちの１つを決定することを含む。複数の区分化技法の例には、ブロックの中心を通ってブロックを対称的に分割する区分化技法に加え、ブロックの中心が分割されないようにブロックを対称的にまたは非対称的に分割する区分化技法が含まれ得る。このように、ビデオブロックの区分化は、より効率的なコード化につながる方法で実行されることができ、これは、ブロックの中心にあるビデオデータ中のオブジェクトをより良好にキャプチャする区分化を含む。

[0007]本開示は、ビデオデータの特定のピクチャがどのように区分化されるかを示すシンタックス要素をシグナリングするための技法をさらに説明する。ブロック区分化は一般に、ビデオデータのピクチャがどのように様々なサイズのブロックへと分割、そして再分割、されるかを説明する。ビデオデコーダは、ブロック区分化を再構築するためにそのようなシンタックス要素を使用し得る。本開示の他の例は、本開示のＭＴＴ区分化技法を使用して、区分化されたビデオデータのブロックに対して変換を実行することを対象としている。

[0008]本開示の一例では、ビデオデータを復号する方法は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定することと、ビデオデータのフレームの複数のブロックを再構築することとを備える。

[0009]本開示の別の例では、ビデオデータを符号化する方法は、ビデオデータのピクチャを受信することと、３つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化することと、ビデオデータのピクチャの複数のブロックを符号化することとを備える。

[0010]本開示の別の例では、ビデオデータを復号するように構成された装置は、ビデオデータを記憶するように構成されたメモリと、ビデオデータのピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定することと、ビデオデータのフレームの複数のブロックを再構築することとを行うように構成されたビデオ復号回路とを備える。

[0011]本開示の別の例では、ビデオデータを復号するように構成された装置は、ビデオデータのコード化されたピクチャを形成するビットのシーケンスを含むビットストリームを受信するための手段と、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定するための手段と、ビデオデータのフレームの複数のブロックを再構築するための手段とを備える。

[0012]１つまたは複数の例の詳細は、添付の図面および以下の説明で示される。他の特徴、目的、および利点は、本説明、図面、および請求項から明らかになるであろう。

図１は、本開示の技法をインプリメントするように構成された例となるビデオ符号化および復号システムを例示するブロック図である。 図２は、高効率ビデオコーディング（ＨＥＶＣ）におけるコード化単位（ＣＵ）構造を例示する概念図である。 図３は、インター予測モードの場合の例となる区分タイプを例示する概念図である。 図４Ａは、四分木二分木（ＱＴＢＴ）構造を使用したブロック区分化の例を例示する概念図である。 図４Ｂは、図４ＡのＱＴＢＴ構造を使用したブロック区分化に対応する例となるツリー構造を例示する概念図である。 図５Ａは、例となる水平三分木区分タイプを例示する概念図である。 図５Ｂは、例となる水平三分木区分タイプを例示する概念図である。 図６Ａは、四分木区分化を例示する概念図である。 図６Ｂは、垂直二分木区分化を例示する概念図である。 図６Ｃは、水平二分木区分化を例示する概念図である。 図６Ｄは、垂直センタ－サイド木区分化を例示する概念図である。 図６Ｅは、水平センタ－サイド木区分化を例示する概念図である。 図７は、本開示技法に係る、コード化ツリー単位（ＣＴＵ）区分化の例を例示する概念図である。 図８は、ビデオエンコーダの例を例示するブロック図である。 図９は、ビデオデコーダの例を例示するブロック図である。 図１０Ａは、本開示の技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。 図１０Ｂは、本開示の技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。 図１１は、本開示の別の例となる技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。 図１２は、本開示の別の例となる技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。

発明の詳細な説明

[0032]本開示は、ブロックベースのビデオコード化におけるビデオデータのブロックの区分化および／または編成（例えば、コード化単位）に関する。本開示の技法は、ビデオコーディング規格において適用され得る。以下で説明する様々な例では、本開示の技法は、３つ以上の異なる区分構造を使用してビデオデータのブロックを区分化することを含む。いくつかの例では、３つ以上の異なる区分構造が、コード化ツリー構造の各深度で使用され得る。そのような区分化技法は、マルチタイプツリー（ＭＴＴ）区分化と呼ばれ得る。ＭＴＴ区分化を使用することで、ビデオデータは、より柔軟に区分化され得るため、より大きなコード化効率を可能にする。

[0033]図１は、ビデオデータのブロックを区分化することと、区分タイプをシグナリングおよび解析することと、変換およびさらなる変換区分を適用することとを行うための本開示の技法を利用し得る例となるビデオ符号化および復号システム１０を例示するブロック図である。図１に示されるように、システム１０は、宛先デバイス１４によって後の時間に復号されることとなる符号化されたビデオデータを供給するソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを供給する。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、タブレットコンピュータ、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイス、または同様のものを含む、広範囲のデバイスのうちの任意のものを備え得る。いくつかのケースでは、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。ゆえに、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信デバイスであり得る。ソースデバイス１２は、例となるビデオ符号化デバイス（すなわち、ビデオデータを符号化するためのデバイス）である。宛先デバイス１４は、例となるビデオ復号デバイス（例えば、ビデオデータを復号するためのデバイスまたは装置）である。

[0034]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオデータを記憶するように構成された記憶媒体２０と、ビデオエンコーダ２２と、出力インターフェース２４とを含む。宛先デバイス１４は、入力インターフェース２６と、符号化されたビデオデータを記憶するように構成された記憶媒体２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。他の例では、ソースデバイス１２および宛先デバイス１４は、他の構成要素または配列を含む。例えば、ソースデバイス１２は、外部カメラのような外部ビデオソースからビデオデータを受信し得る。同様に、宛先デバイス１４は、統合されたディスプレイデバイスを含むよりむしろ外部ディスプレイデバイスとインターフェース接続し得る。

[0035]図１の例示されるシステム１０は一例に過ぎない。ビデオデータを処理するための技法は、任意のデジタルビデオ符号化および／または復号デバイスあるいは装置によって実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスおよびビデオ復号デバイスによって実行されるが、本技法は、典型的に「ＣＯＤＥＣ」と呼ばれる複合ビデオエンコーダ／デコーダによっても実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４への送信のために符号化されたビデオデータを生成するそのようなコード化デバイスの例に過ぎない。いくつかの例では、ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２および宛先デバイス１４の各々がビデオ符号化および復号構成要素を含むような略対称的な方法で動作する。それゆえに、システム１０は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ソースデバイス１２と宛先デバイス１４との間での単方向または双方向のビデオ送信をサポートし得る。

[0036]ソースデバイス１２のビデオソース１８は、ビデオカメラのようなビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオデータを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてコンピュータグラフィックベースのデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。ソースデバイス１２は、ビデオデータを記憶するように構成された１つまたは複数のデータ記憶媒体（例えば、記憶媒体２０）を備え得る。本開示で説明される技法は一般に、ビデオコード化に適用可能であり得、ワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。いずれのケースでも、キャプチャされた、前にキャプチャされた、またはコンピュータ生成されたビデオは、ビデオエンコーダ２２によって符号化され得る。出力インターフェース２４は、符号化されたビデオ情報をコンピュータ可読媒体１６に出力し得る。

[0037]宛先デバイス１４は、コンピュータ可読媒体１６を介して、復号されることとなる符号化されたビデオデータを受信し得る。コンピュータ可読媒体１６は、符号化されたビデオデータをソースデバイス１２から宛先デバイス１４に移動させる能力がある任意のタイプの媒体またはデバイスを備え得る。いくつかの例では、コンピュータ可読媒体１６は、ソースデバイス１２が符号化されたビデオデータをリアルタイムに直接宛先デバイス１４に送信することを可能にするための通信媒体を備える。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線のような任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットのようなグローバルネットワークといった、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を容易にするのに有益であり得る任意の他の機器を含み得る。宛先デバイス１４は、符号化されたビデオデータおよび復号されたビデオデータを記憶するように構成された１つまたは複数のデータ記憶媒体を備え得る。

[0038]いくつかの例では、符号化されたデータ（例えば、符号化されたビデオデータ）は、出力インターフェース２４から記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェース２６によって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、ＤＶＤ、ＣＤ－ＲＯＭ、フラッシュメモリ、揮発性または非揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような様々な分散型または局所的にアクセスされるデータ記憶媒体のうちの任意のものを含み得る。さらなる例では、記憶デバイスは、ファイルサーバ、またはソースデバイス１２によって生成された符号化されたビデオを記憶し得る別の中間記憶デバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、記憶デバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶するおよび符号化されたビデオデータを宛先デバイス１４に送信する能力がある任意のタイプのサーバであり得る。例となるファイルサーバは、（例えば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続記憶（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む任意の標準的なデータ接続を通して、符号化されたビデオデータにアクセスし得る。これは、ワイヤレスチャネル（例えば、Ｗｉ－Ｆｉ接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデム、等）、またはファイルサーバに記憶されている符号化されたビデオデータにアクセスするのに適切な両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。

[0039]本開示の技法は、無線テレビ放送、ケーブルテレビ送信、衛星テレビ送信、ＨＴＴＰを介した動的適応型ストリーミング（ＤＡＳＨ）のようなインターネットストリーミングビデオ送信、データ記憶媒体上で符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、様々なマルチメディアアプリケーションのうちの任意のものをサポートして、ビデオコード化に適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、および／またはビデオ電話のようなアプリケーションをサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。

[0040]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信のような一時的な媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体のような記憶媒体（すなわち、非一時的な記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示されない）は、ソースデバイス１２から符号化されたビデオデータを受信し、例えば、ネットワーク送信を介して、符号化されたビデオデータを宛先デバイス１４に供給し得る。同様に、ディスクスタンピング設備のような媒体製造設備（medium production facility）のコンピューティングデバイスは、符号化されたビデオデータをソースデバイス１２から受信し、符号化されたビデオデータを含むディスクを作り出し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形式の１つまたは複数のコンピュータ可読媒体を含むと理解され得る。

[0041]宛先デバイス１４の入力インターフェース２６は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ブロックおよび他のコード化された単位、例えば、ピクチャグループ（ＧＯＰ）、の処理および／または特性を説明するシンタックス要素を含む、ビデオエンコーダ２２のビデオエンコーダ２２によって定義されるシンタックス情報を含み得、これは、ビデオデコーダ３０によっても使用される。記憶媒体２８は、入力インターフェース２６によって受信される、符号化されたビデオデータを記憶し得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに表示する。ディスプレイデバイス３２は、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのうちの任意のものを備え得る。

[0042]ビデオエンコーダ２２およびビデオデコーダ３０は各々、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せのような、様々な適切なエンコーダまたはデコーダ回路のうちの任意のものとしてインプリメントされ得る。本技法がソフトウェアで部分的にインプリメントされる場合、デバイスは、このソフトウェアのための命令を、適切な非一時的なコンピュータ可読媒体に記憶し得、本開示の技法を実行するために、１つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行し得る。ビデオエンコーダ２２およびビデオデコーダ３０の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのいずれもが、それぞれのデバイスにおいて複合エンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合され得る。

[0043]いくつかの例では、ビデオエンコーダ２２およびビデオデコーダ３０は、ビデオコーディング規格に従って動作し得る。例となるビデオコーディング規格には、ＩＴＵ－Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ－１ビジュアル、ＩＴＵ－Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ－２ビジュアル、ＩＴＵ－Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ビジュアル、および（ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ ＡＶＣとしても知られている）ＩＴＵ－Ｔ Ｈ．２６４に加え、そのＳＶＣ（Scalable Video Coding）およびＭＶＣ（Multi-View Video）拡張が含まれるがそれらに限られない。ビデオコーディング規格である高効率ビデオコーディング（ＨＥＶＣ）すなわちＩＴＵ－Ｔ Ｈ．２６５、なお、その範囲およびスクリーンコンテンツコード化拡張、３Ｄビデオコーディング（３Ｄ－ＨＥＶＣ）およびマルチビュー拡張（ＭＶ－ＨＥＶＣ）およびスケーラブル拡張（ＳＨＶＣ）を含む、は、ＩＴＵ－Ｔ ＶＣＥＧ（Video Coding Experts Group）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（Motion Picture Experts Group）のＪＣＴ－ＶＣ（Joint Collaboration Team on Video Coding）によって開発されている。

[0044]ＨＥＶＣおよび他のビデオコーディング仕様では、ビデオシーケンスは典型的に、一連のピクチャを含む。ピクチャは、「フレーム」とも呼ばれ得る。ピクチャは、Ｓ_Ｌ、Ｓ_Ｃｂ、およびＳ_Ｃｒと表される３つのサンプルアレイを含み得る。Ｓ_Ｌは、ルーマサンプルの二次元アレイ（すなわち、ブロック）である。Ｓ_Ｃｂは、Ｃｂクロミナンスサンプルの二次元アレイである。Ｓ_Ｃｒは、Ｃｒクロミナンスサンプルの二次元アレイである。クロミナンスサンプルは、ここでは、「クロマ」サンプルとも呼ばれ得る。他の事例では、ピクチャは、モノクロであり得、ルーマサンプルのアレイのみを含み得る。

[0045]さらに、ＨＥＶＣおよび他のビデオコーディング仕様では、ピクチャの符号化表現を生成するために、ビデオエンコーダ２２が、コード化ツリー単位（ＣＴＵ）のセットを生成し得る。ＣＴＵの各々は、ルーマサンプルのコード化ツリーブロックと、クロマサンプルの２つの対応するコード化ツリーブロックと、これらのコード化ツリーブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは３つの別個の色平面を有するピクチャでは、ＣＴＵは、単一のコード化ツリーブロックと、このコード化ツリーブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。コード化ツリーブロックは、サンプルのＮｘＮブロックであり得る。ＣＴＵは、「ツリーブロック」または「最大コード化単位」（ＬＣＵ）とも呼ばれ得る。ＨＥＶＣのＣＴＵは、Ｈ．２６４／ＡＶＣのような他の規格のマクロブロックに大まかに類似し得る。しかしながら、ＣＴＵは、必ずしも、特定のサイズに制限されるわけではなく、１つまたは複数のコード化単位（ＣＵ）を含み得る。１つのスライスは、ラスター走査順に連続して並べられた整数の数のＣＴＵを含み得る。

[0046]ＨＥＶＣに従って動作する場合、コード化されたＣＴＵを生成するために、ビデオエンコーダ２２は、ＣＴＵのコード化ツリーブロックに対して四分木区分化を再帰的に実行してこれらのコード化ツリーブロックをコード化ブロックへと分割し得、これが、「コード化ツリー単位」と呼ばれるゆえんである。コード化ブロックは、サンプルのＮｘＮブロックである。ＣＵは、ルーマサンプルのコード化ブロックと、ルーマサンプルアレイ、Ｃｂサンプルアレイ、およびＣｒサンプルアレイを有するピクチャのクロマサンプルの２つの対応するコード化ブロックと、これらのコード化ブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは３つの別個の色平面を有するピクチャでは、ＣＵは、単一のコード化ブロックと、このコード化ブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。

[0047]ビットストリーム内のシンタックスデータは、ＣＴＵのためのサイズも定義し得る。１つのスライスは、コード化順に連続する複数のＣＴＵを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスへと区分化され得る。上述したように、各ツリーブロックは、四分木に従ってコード化単位（ＣＵ）へと分割され得る。一般に、四分木データ構造は、ルートノードがツリーブロックに対応する状態で１つのＣＵにつき１つのノードを含む。ＣＵが４つのサブＣＵへと分割される場合、ＣＵに対応するノードは、４つのリーフノードを含み、それらの各々がサブＣＵのうちの１つに対応する。

[0048]四分木データ構造の各ノードは、対応するＣＵにシンタックスデータを供給し得る。例えば、四分木におけるノードは、このノードに対応するＣＵがサブＣＵへと分割されるかどうかを示す分割フラグを含み得る。ＣＵに関するシンタックス要素は再帰的に定義され得、ＣＵがサブＣＵへと分割されるかどうかに依存し得る。ＣＵがこれ以上分割されない場合、それはリーフＣＵと呼ばれる。ＣＵのブロックがさらに分割される場合、それは一般に、非リーフＣＵと呼ばれ得る。本開示のいくつかの例では、リーフＣＵの４つのサブＣＵは、元のリーフＣＵの明示的な分割が存在しない場合であっても、リーフＣＵと呼ばれ得る。例えば、１６ｘ１６のサイズのＣＵがこれ以上分割されない場合、１６ｘ１６のＣＵは一度も分割されていないが、４つの８ｘ８のサブＣＵもリーフＣＵと呼ばれ得る。

[0049]ＣＵは、ＣＵがサイズ区別（size distinction）を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、（サブＣＵとも呼ばれる）４つの子ノードへと分割され得、各子ノードが次に親ノードになり、別の４つの子ノードへと分割され得る。四分木のリーフノードと呼ばれる、最終の分割されていない子ノードは、リーフＣＵとも呼ばれるコード化ノードを備える。コード化されたビットストリームに関連付けられたシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、コード化ノードの最小サイズも定義し得る。したがって、ビットストリームもまた、最小コード化単位（ＳＣＵ）を定義し得る。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵのうちの任意のもの、または、他の規格のコンテキストにおける同様のデータ構造（例えば、Ｈ．２６４／ＡＶＣにおけるそれのマクロブロックおよびサブブロック）を指すために「ブロック」という用語を使用する。

[0050]ＣＵは、コード化ノードと、このコード化ノードに関連付けられた変換単位（ＴＵ）および予測単位（ＰＵ）とを含む。ＣＵのサイズは、コード化ノードのサイズに対応し、いくつかの例では、形状が正方形であり得る。ＨＥＶＣの例では、ＣＵのサイズは、８ｘ８画素から、最大６４ｘ６４画素またはそれより大きいツリーブロックのサイズまでの範囲であり得る。各ＣＵは、１つまたは複数のＰＵおよび１つまたは複数のＴＵを含み得る。ＣＵに関連付けられたシンタックスデータは、例えば、１つまたは複数のＰＵへのＣＵの区分化を説明し得る。区分モードは、ＣＵが、スキップまたはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、インター予測モード符号化されるかで異なり得る。ＰＵは、形状が非正方形になるように区分化され得る。ＣＵに関連付けられたシンタックスデータはまた、例えば、四分木にしたがった１つまたは複数のＴＵへのＣＵの区分化を説明し得る。ＴＵは、形状が正方形または非正方形（例えば、長方形）であることができる。

[0051]ＨＥＶＣ規格は、ＴＵにしたがった変換を可能にする。ＴＵは、ＣＵごとに異なり得る。ＴＵは通常、区分化されたＬＣＵのために定義された所与のＣＵ中のＰＵのサイズに基づいてサイズ変更されるが、これは、常に当てはまるわけではないであろう。ＴＵは通常、ＰＵと同じサイズであるかそれより小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差四分木」（ＲＱＴ）と呼ばれることがある四分木構造を使用してより小さい単位へと再分割され得る。ＲＱＴのリーフノードは、ＴＵと呼ばれ得る。ＴＵに関連付けられた画素差分値は、量子化され得る変換係数を作り出すために変換され得る。

[0052]リーフＣＵは、１つまたは複数のＰＵを含み得る。一般に、ＰＵは、対応するＣＵの全体または一部に対応する空間エリアを表し、このＰＵについての参照サンプルを取り出すためのデータを含み得る。さらに、ＰＵは、予測に関連するデータを含む。例えば、ＰＵがイントラモード符号化されるとき、ＰＵのためのデータは、ＲＱＴに含まれ得、これは、このＰＵに対応するＴＵのためのイントラ予測モードを説明するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、このＰＵについての１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵについての動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度（例えば、４分の１画素精度または８分の１画素精度）、動きベクトルが指し示す参照ピクチャ、および／または動きベクトルについての参照ピクチャリスト（例えば、リスト０、リスト１、またはリストＣ）を説明し得る。

[0053]１つまたは複数のＰＵを有するリーフＣＵもまた、１つまたは複数のＴＵを含み得る。ＴＵは、上で述べたように、ＲＱＴ（ＴＵ四分木構造とも呼ばれ得る）を使用して指定され得る。例えば、分割フラグは、リーフＣＵが４つの変換単位へと分割されるかを示し得る。いくつかの例では、各変換単位は、さらなるサブＴＵへとさらに分割され得る。ＴＵがこれ以上分割されないとき、それはリーフＴＵと呼ばれ得る。一般に、イントラコード化の場合、リーフＣＵに属するすべてのリーフＴＵが、同じイントラ予測モードから作り出された残差データを含む。すなわち、リーフＣＵのすべてのＴＵにおいて変換されることとなる予測値を算出するために、同じイントラ予測モードが一般に適用される。イントラコード化の場合、ビデオエンコーダ２２は、ＴＵに対応するＣＵの部分と元のブロックとの間の差分として、イントラ予測モードを使用して各リーフＴＵの残差値を算出し得る。ＴＵは、必ずしもＰＵのサイズに制限されるわけではない。ゆえに、ＴＵは、ＰＵより大きい場合も小さい場合もある。イントラコード化の場合、ＰＵは、同じＣＵについて対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。

[0054]さらに、リーフＣＵのＴＵは、それぞれのＲＱＴ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵへと区分化されるかを示す四分木を含み得る。ＴＵ四分木のルートノードは一般に、リーフＣＵに対応し、ＣＵ四分木のルートノードは一般に、ツリーブロック（または、ＬＣＵ）に対応する。

[0055]上で述べたように、ビデオエンコーダ２２は、ＣＵのコード化ブロックを１つまたは複数の予測ブロックへと区分化し得る。予測ブロックは、同じ予測が適用されるサンプルの長方形（すなわち、正方形または非正方形）ブロックであり得る。ＣＵのＰＵは、ルーマサンプルの予測ブロックと、クロマサンプルの２つの対応する予測ブロックと、これらの予測ブロックを予測するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは３つの別個の色平面を有するピクチャでは、ＰＵは、単一の予測ブロックと、この予測ブロックを予測するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ２２は、ＣＵの各ＰＵの予測ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ予測ブロック）についての予測ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ予測ブロック）を生成し得る。

[0056]ビデオエンコーダ２２は、ＰＵについての予測ブロックを生成するためにイントラ予測またはインター予測を使用し得る。ビデオエンコーダ２２が、ＰＵの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ２２は、ＰＵを含むピクチャの復号されたサンプルに基づいて、ＰＵの予測ブロックを生成し得る。

[0057]ビデオエンコーダ２２が、ＣＵの１つまたは複数のＰＵについての予測ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ予測ブロック）を生成した後、ビデオエンコーダ２２は、このＣＵについての１つまたは複数の残差ブロックを生成し得る。例えば、ビデオエンコーダ２２は、ＣＵについてのルーマ残差ブロックを生成し得る。ＣＵのルーマ残差ブロック中の各サンプルは、ＣＵの予測ルーマブロックのうちの１つ中のルーマサンプルと、ＣＵの元のルーマコード化ブロック中の対応するサンプルとの間の差分を示す。加えて、ビデオエンコーダ２２は、ＣＵについてのＣｂ残差ブロックを生成し得る。ＣＵのＣｂ残差ブロック中の各サンプルは、ＣＵの予測Ｃｂブロックのうちの１つ中のＣｂサンプルと、ＣＵの元のＣｂコード化ブロック中の対応するサンプルとの間の差分を示し得る。ビデオエンコーダ２２はまた、ＣＵについてのＣｒ残差ブロックを生成し得る。ＣＵのＣｒ残差ブロック中の各サンプルは、ＣＵの予測Ｃｒブロックのうちの１つ中のＣｒサンプルと、ＣＵの元のＣｒコード化ブロック中の対応するサンプルとの間の差分を示し得る。

[0058]さらに、上で述べたように、ビデオエンコーダ２２は、ＣＵの残差ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ残差ブロック）を１つまたは複数の変換ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ変換ブロック）へと分解するために四分木区分化を使用し得る。変換ブロックは、同じ変換が適用されるサンプルの長方形（例えば、正方形または非正方形）ブロックであり得る。ＣＵの変換単位（ＴＵ）は、ルーマサンプルの変換ブロックと、クロマサンプルの２つの対応する変換ブロックと、これらの変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。ゆえに、ＣＵの各ＴＵは、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロックを有し得る。ＴＵのルーマ変換ブロックは、ＣＵのルーマ残差ブロックのサブブロックであり得る。Ｃｂ変換ブロックは、ＣＵのＣｂ残差ブロックのサブブロックであり得る。Ｃｒ変換ブロックは、ＣＵのＣｒ残差ブロックのサブブロックであり得る。モノクロのピクチャまたは３つの別個の色平面を有するピクチャでは、ＴＵは、単一の変換ブロックと、この変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。

[0059]ビデオエンコーダ２２は、ＴＵについての係数ブロックを生成するために、ＴＵの変換ブロックに１つまたは複数の変換を適用し得る。例えば、ビデオエンコーダ２２は、ＴＵについてのルーマ係数ブロックを生成するために、ＴＵのルーマ変換ブロックに１つまたは複数の変換を適用し得る。係数ブロックは、変換係数の二次元アレイであり得る。変換係数は、スカラー量であり得る。ビデオエンコーダ２２は、ＴＵについてのＣｂ係数ブロックを生成するために、ＴＵのＣｂ変換ブロックに１つまたは複数の変換を適用し得る。ビデオエンコーダ２２は、ＴＵについてのＣｒ係数ブロックを生成するために、ＴＵのＣｒ変換ブロックに１つまたは複数の変換を適用し得る。

[0060]いくつかの例では、ビデオエンコーダ２２は、変換ブロックへの変換の適用を省略する。そのような例では、ビデオエンコーダ２２は、変換係数と同じ方法で残差サンプル値を扱い得る。ゆえに、ビデオエンコーダ２２が変換の適用を省略する例では、変換係数および係数ブロックの以下の考察が、残差サンプルの変換ブロックに適用可能であり得る。

[0061]係数ブロック（例えば、ルーマ係数ブロック、Ｃｂ係数ブロック、またはＣｒ係数ブロック）を生成した後、ビデオエンコーダ２２は、係数ブロックを表すために使用されるデータ量を可能な限り低減する、恐らくはさらなる圧縮を提供する、ために、係数ブロックを量子化し得る。量子化は一般に、ある範囲の値が単一の値に圧縮されるプロセスを指す。例えば、量子化は、値を定数で除算し、その後、最も近い整数に端数を丸める（round）ことで行われ得る。係数ブロックを量子化するために、ビデオエンコーダ２２は、係数ブロックの変換係数を量子化し得る。ビデオエンコーダ２２が係数ブロックを量子化した後、ビデオエンコーダ２２は、量子化された変換係数を示すシンタックス要素をエントロピー符号化し得る。例えば、ビデオエンコーダ２２は、量子化された変換係数を示すシンタックス要素に対してコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）または他のエントロピーコーディング技法を実行し得る。

[0062]ビデオエンコーダ２２は、コード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームおよび関連するデータを出力し得る。ゆえに、ビットストリームは、ビデオデータの符号化表現を備える。ビットストリームは、ネットワーク抽象化レイヤ（ＮＡＬ）単位のシーケンスを備え得る。ＮＡＬ単位は、ＮＡＬ単位中のデータのタイプを示すインジケーションと、必要に応じてエミュレーション防止ビットが組み入れられている生バイトシーケンスペイロード（ＲＢＳＰ）の形式でそのデータを含むバイトとを含むシンタックス構造である。ＮＡＬ単位の各々は、ＮＡＬ単位ヘッダを含み得、ＲＢＳＰをカプセル化し得る。ＮＡＬ単位ヘッダは、ＮＡＬ単位タイプコードを示すシンタックス要素を含み得る。ＮＡＬ単位のＮＡＬ単位ヘッダによって指定されるＮＡＬ単位タイプコードは、ＮＡＬ単位のタイプを示す。ＲＢＳＰは、ＮＡＬ単位内にカプセル化される整数の数のバイトを含むシンタックス構造であり得る。いくつかの事例では、ＲＢＳＰはゼロビットを含む。

[0063]ビデオデコーダ３０は、ビデオエンコーダ２２によって生成されたビットストリームを受信し得る。ビデオデコーダ３０は、ビデオデータのピクチャを再構築するために、ビットストリームを復号し得る。ビットストリームを復号することの一部として、ビデオデコーダ３０は、ビットストリームからシンタックス要素を取得するためにビットストリームを解析し得る。ビデオデコーダ３０は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築し得る。ビデオデータを再構築するためのプロセスは、一般に、ビデオエンコーダ２２によって実行されるプロセスとは概ね逆である。例えば、ビデオデコーダ３０は、現在のＣＵのＰＵについての予測ブロックを決定するために、ＰＵの動きベクトルを使用し得る。加えて、ビデオデコーダ３０は、現在のＣＵのＴＵの係数ブロックを逆量子化し得る。ビデオデコーダ３０は、現在のＣＵのＴＵの変換ブロックを再構築するために、係数ブロックに対して逆変換を実行し得る。ビデオデコーダ３０は、現在のＣＵのＰＵについての予測ブロックのサンプルを、現在のＣＵのＴＵの変換ブロックの対応するサンプルに加えることで、現在のＣＵのコード化ブロックを再構築し得る。ピクチャの各ＣＵについてのコード化ブロックを再構築することで、ビデオデコーダ３０は、ピクチャを再構築し得る。

[0064]ＨＥＶＣの共通概念および特定の設計態様が、ブロック区分のための技法に焦点を当てて、以下に説明される。ＨＥＶＣでは、スライス中の最大コード化単位は、ＣＴＢと呼ばれる。ＣＴＢは、四分木構造に従って分割され、それのノードは、コード化単位である。四分木構造における複数のノードは、リーフノードと非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない（すなわち、リーフノードは、これ以上分割されない）。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロック（例えば、ＣＴＢ）に対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において１つまたは複数の子ノードを有する。

[0065]ＣＴＢのサイズは、（厳密には、８ｘ８のＣＴＢサイズはサポートされることができるが）ＨＥＶＣメインプロファイルにおいて１６ｘ１６から６４ｘ６４までの範囲である。Ｗ．Ｊ．Ｈａｎ等による「Improved Video Compression Efficiency Through Flexible Unit Representation and Corresponding Extension of Coding Tools」，IEEE Transaction on Circuits and Systems for Video Technology，vol. 20，no. 12，pp. 1709-1720，２０１０年１２月、で説明されているように、および図２に示されるように、ＣＴＢは、四分木方法でＣＵへと再帰的に分割され得る。図２に示されるように、区分化の各レベルは、４つのサブブロックへの四分木分割である。黒いブロックは、リーフノード（すなわち、これ以上分割されないブロック）の例である。

[0066]いくつかの例では、ＣＵは、ＣＴＢのサイズと同じサイズであり得るが、ＣＵは、８ｘ８ほどの小ささであることができる。各ＣＵは、例えば、イントラコード化モードまたはインターコード化モードであり得る１つのコード化モードでコード化される。スクリーンコンテンツ用のコード化モード（例えば、イントラブロックコピーモード、パレットベースコード化モード、等）を含む、他のコード化モードも可能である。ＣＵがインターコード化される（すなわち、インターモードが適用される）とき、ＣＵは、予測単位（ＰＵ）へとさらに区分化され得る。例えば、ＣＵは、２つまたは４つのＰＵへと区分化され得る。別の例では、さらなる区分化が適用されない場合、ＣＵ全体が単一のＰＵとして扱われる。ＨＥＶＣの例では、１つのＣＵに２つのＰＵが存在するとき、それらは、ハーフサイズの長方形であるか、ＣＵの１／４または３／４のサイズを有する２つの長方形のサイズであることができる。

[0067]ＨＥＶＣでは、図３に示されるように、インター予測モードでコード化されたＣＵに対して８つの区分モード、すなわち、ＰＡＲＴ＿２Ｎｘ２Ｎ、ＰＡＲＴ＿２ＮｘＮ、ＰＡＲＴ＿Ｎｘ２Ｎ、ＰＡＲＴ＿ＮｘＮ、ＰＡＲＴ＿２ＮｘｎＵ、ＰＡＲＴ＿２ＮｘｎＤ、ＰＡＲＴ＿ｎＬｘ２Ｎ、およびＰＡＲＴ＿ｎＲｘ２Ｎが存在する。図３に示されるように、区分モードＰＡＲＴ＿２Ｎｘ２Ｎでコード化されたＣＵは、これ以上分割されない。すなわち、ＣＵ全体が単一のＰＵ（ＰＵ０）として扱われる。区分モードＰＡＲＴ＿２ＮｘＮでコード化されたＣＵは、２つのＰＵ（ＰＵ０とＰＵ１）へと対称的に水平に分割される。区分モードＰＡＲＴ＿Ｎｘ２Ｎでコード化されたＣＵは、２つのＰＵへと対称的に垂直に分割される。区分モードＰＡＲＴ＿ＮｘＮでコード化されたＣＵは、４つの等しいサイズのＰＵ（ＰＵ０、ＰＵ１、ＰＵ２、ＰＵ３）へと対称的に分割される。

[0068]区分モードＰＡＲＴ＿２ＮｘｎＵでコード化されたＣＵは、ＣＵのサイズの１／４を有する１つのＰＵ０（上部ＰＵ）およびＣＵのサイズの３／４を有する１つのＰＵ１（下部ＰＵ）へと非対称的に水平に分割される。区分モードＰＡＲＴ＿２ＮｘｎＤでコード化されたＣＵは、ＣＵのサイズの３／４を有する１つのＰＵ０（上部ＰＵ）およびＣＵのサイズの１／４を有する１つのＰＵ１（下部ＰＵ）へと非対称的に水平に分割される。区分モードＰＡＲＴ＿ｎＬｘ２Ｎでコード化されたＣＵは、ＣＵのサイズの１／４を有する１つのＰＵ０（左のＰＵ）およびＣＵのサイズの３／４を有する１つのＰＵ１（右のＰＵ）へと非対称的に垂直に分割される。区分モードＰＡＲＴ＿ｎＲｘ２Ｎでコード化されたＣＵは、ＣＵのサイズの３／４を有する１つのＰＵ０（左のＰＵ）およびＣＵの１／４のサイズを有する１つのＰＵ１（右のＰＵ）へと非対称的に垂直に分割される。

[0069]ＣＵがインターコード化されるとき、各ＰＵに対して、動き情報（例えば、動きベクトル、予測方向、および参照ピクチャ）の１つのセットが存在する。加えて、各ＰＵは、動き情報のセットを導出するために、一意的なインター予測モードでコード化される。しかしながら、２つのＰＵが一意的にコード化されても、それらが状況次第で同じ動き情報を有し得ることは理解されるべきである。

[0070]Ｊ．Ａｎ等による、「Block partitioning structure for next generation video coding」，国際電気通信連合，ＣＯＭ１６－Ｃ９６６，２０１５年９月（以下、「ＶＣＥＧ proposal ＣＯＭ１６－Ｃ９６６」）では、四分木二分木（ＱＴＢＴ）区分化技法が、ＨＥＶＣを越える将来のビデオコーディング規格のために提案された。シミュレーションは、提案されたＱＴＢＴ構造が、使用されるＨＥＶＣにおける四分木構造より効率的であることを示している。

[0071]ＶＣＥＧ proposal ＣＯＭ１６－Ｃ９６６の提案されたＱＴＢＴ構造では、最初に四分木分割技法を使用してＣＴＢが区分化され、ここでは、１つのノードの四分木分割は、このノードが最小の許容四分木リーフノードサイズに達するまで反復されることができる。最小の許容四分木リーフノードサイズは、シンタックス要素ＭｉｎＱＴＳｉｚｅの値によってビデオデコーダに示され得る。四分木リーフノードサイズが（例えば、シンタックス要素ＭａｘＢＴＳｉｚｅによって表される）最大の許容二分木ルートノードサイズより大きくない場合、四分木リーフノードは、二分木区分化を使用してさらに区分化されることができる。１つのノードの二分木区分化は、このノードが（例えば、シンタックス要素ＭｉｎＢＴＳｉｚｅによって表されるような）最小の許容二分木リーフノードサイズまたは（例えば、シンタックス要素ＭａｘＢＴＤｅｐｔｈによって表されるような）最大の許容二分木深度に達するまで反復されることができる。ＶＣＥＧ proposal ＣＯＭ１６－Ｃ９６６は、二分木リーフノードを指すために「ＣＵ」という用語を使用する。ＶＣＥＧ proposal ＣＯＭ１６－Ｃ９６６では、ＣＵは、これ以上の区分化なしに変換および予測（例えば、イントラ予測、インター予測、等）に対して使用される。一般に、ＱＴＢＴ技法によれば、対称水平分割および対称垂直分割という２つの分割タイプが二分木分割のために存在する。いずれのケースでも、ブロックは、このブロックを、水平または垂直のいずれかに、真ん中で半分に（down the middle）分割することで分割される。

[0072]ＱＴＢＴ区分構造の一例では、ＣＴＵサイズは１２８ｘ１２８（例えば、１２８ｘ１２８のルーマブロックと２つの対応する６４ｘ６４のクロマブロック）として設定され、ＭｉｎＱＴＳｉｚｅは、１６ｘ１６として設定され、ＭａｘＢＴＳｉｚｅは、６４ｘ６４として設定され、（幅と高さの両方についての）ＭｉｎＢＴＳｉｚｅは、４として設定され、ＭａｘＢＴＤｅｐｔｈは、４として設定される。四分木リーフノードを生成するために、最初に四分木区分化がＣＴＵに適用される。四分木リーフノードは、１６ｘ１６（すなわち、ＭｉｎＱＴＳｉｚｅは１６ｘ１６である）から１２８ｘ１２８（すなわち、ＣＴＵサイズ）までのサイズを有し得る。ＱＴＢＴ区分化の一例によれば、リーフ四分木ノードが１２８ｘ１２８である場合、リーフ四分木ノードは、リーフ四分木ノードのサイズがＭａｘＢＴＳｉｚｅ（すなわち、６４ｘ６４）を超えるため、二分木によってこれ以上分割されることはできない。そうでなければ、リーフ四分木ノードは、二分木によってさらに区分化される。したがって、四分木リーフノードは、二分木のためのルートノードでもあり、０の二分木深度を有する。ＭａｘＢＴＤｅｐｔｈ（例えば、４）に達する二分木深度は、これ以上の分割がないことを暗示する。ＭｉｎＢＴＳｉｚｅ（例えば、４）に等しい幅を有する二分木ノードは、これ以上の水平分割がないことを暗示する。同様に、ＭｉｎＢＴＳｉｚｅに等しい高さを有する二分木ノードは、これ以上の垂直分割がないことを暗示する。二分木（ＣＵ）のリーフノードは、これ以上の区分化なしに（例えば、予測プロセスおよび変換プロセスを実行することで）さらに処理される。

[0073]図４Ａは、ＱＴＢＴ区分化技法を使用して区分化されたブロック５０（例えば、ＣＴＢ）の例を例示する。図４Ａに示されるように、ＱＴＢＴ区分技法を使用して、結果として得られるブロックの各々は、各ブロックの中心を通って対称的に分割される。図４Ｂは、図４Ｂのブロック区分化に対応するツリー構造を例示する。図４Ｂ中の実線は四分木分割を示し、点線は二分木分割を示す。一例では、二分木の各分割（すなわち、非リーフ）ノードにおいて、シンタックス要素（例えば、フラグ）が、実行される分割のタイプ（例えば、水平または垂直）を示すためにシグナリングされ、ここで、０は、水平分割を示し、１は、垂直分割を示す。四分木分割の場合、四分木分割が常に、同じサイズの４つのサブブロックへと水平および垂直にブロックを分割するため、分割タイプを示す必要はない。

[0074]図４Ｂに示されるように、ノード７０において、ブロック５０は、ＱＴ区分化を使用して、図４Ａに示される４つのブロック５１、５２、５３、および５４へと分割される。ブロック５４はこれ以上分割されないため、リーフノードである。ノード７２において、ブロック５１は、ＢＴ区分化を使用して２つのブロックへとさらに分割される。図４Ｂに示されるように、ノード７２は、垂直分割を示す１がマーク付けされる。このように、ノード７２における分割は、ブロック５７と、ブロック５５および５６の両方を含むブロックとをもたらす。ブロック５５および５６は、ノード７４におけるさらなる垂直分割によって作られる。ノード７６において、ブロック５２は、ＢＴ区分化を使用して２つのブロック５８および５９へとさらに分割される。図４Ｂに示されるように、ノード７６は、水平分割を示す１がマーク付けされる。

[0075]ノード７８において、ブロック５３は、ＱＴ区分化を使用して４つの等しいサイズのブロックへと分割される。ブロック６３および６６は、このＱＴ区分化から作られるものであり、これ以上分割されない。ノード８０において、左上のブロックは、垂直二分木分割を使用して最初に分割され、ブロック６０と、右縦ブロック（right vertical block）をもたらす。その後、右縦ブロックは、水平二分木分割を使用してブロック６１および６２へと分割される。ノード７８における四分木分割から作られた右下ブロックは、ノード８４において水平二分木分割を使用してブロック６４および６５へと分割される。

[0076]上で説明したＱＴＢＴ構造は、ＨＥＶＣで使用される四分木構造より優れたコーディング性能を示すが、ＱＴＢＴ構造は、柔軟性に欠ける。例えば、上で説明したＱＴＢＴ構造では、四分木ノードは、二分木でさらに分割されることができるが、二分木ノードは、四分木でさらに分割されることはできない。別の例では、四分木および二分木の両方は、均一分割（すなわち、ブロックの真ん中で半分に（down the center）分割すること）のみを達成することができるが、これは、オブジェクトが、分割されることとなるブロックの中心にあるとき、効率的でない。したがって、ＱＴＢＴのコーディング性能が、将来のビデオコーディング規格に不足しているであろう。

[0077]上述した問題に対処するために、以下の技法が提案される。以下の技法は、個々に適用され得る。他の例では、以下に説明する技法の任意の組合せはまとめて適用され得る。

[0078]ＣＴＵのためのより柔軟な区分化を達成するために、ＱＴ、ＢＴ、および／またはＱＴＢＴベースのＣＵ構造に取って代わるＭＴＴベースのＣＵ構造が提案される。本開示のＭＴＴ区分構造は、依然として、再帰的ツリー構造である。しかしながら、複数の異なる区分構造（例えば、３つ以上）が使用される。例えば、本開示のＭＴＴ技法によれば、３つ以上の異なる区分構造が、ツリー構造の各深度において使用され得る。このコンテキストにおいて、ツリー構造におけるノードの深度は、このノードからツリー構造のルートまでの経路の長さ（例えば、分割数）を指し得る。本開示で使用されるように、区分構造は一般に、１つのブロックがいくつの異なるブロックへと分割され得るかを指し得る。例えば、四分木区分構造は、１つのブロックを４つのブロックへと分割し得、二分木区分構造は、１つのブロックを２つのブロックへと分割し得、三分木区分構造は、１つのブロックを３つのブロックへと分割し得る。区分構造は、以下でより詳細に説明するように、複数の異なる区分タイプを有し得る。区分タイプは、対称または非対称区分化、均一または非均一区分化、および／または水平または垂直区分化を含む、ブロックがどのように分割されるかを追加的に定義し得る。

[0079]本開示の技法に係る一例では、ビデオエンコーダ２２は、ビデオデータのピクチャを受信し、３つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化し、ビデオデータのピクチャの複数のブロックを符号化するように構成され得る。同様に、ビデオデコーダ３０は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信し、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定し、ビデオデータのコード化されたピクチャの複数のブロックを再構築するように構成され得る。一例では、ビデオデータのフレームを区分化することは、３つ以上の異なる区分構造を使用してビデオデータのフレームを複数のブロックへと区分化することを備え、ここにおいて、３つ以上の異なる区分構造のうちの少なくとも３つが、ビデオデータのフレームがどのように区分化されるかを表すツリー構造の各深度において使用され得る。一例では、３つ以上の異なる区分構造は、三分木区分構造を含み、ビデオエンコーダ２２および／またはビデオデコーダ３０は、三分木区分構造の三分木区分タイプを使用してビデオデータの複数のブロックのうちの１つを区分化するように構成され得、ここにおいて、三分木区分構造は、中心を通って複数のブロックのうちの１つを分割することなく複数のブロックのうちの１つを３つのサブブロックへと分割する。本開示のさらなる例では、３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。

[0080]ゆえに、一例では、ビデオエンコーダ２２は、ビデオデータの初期ビデオブロック（例えば、コード化ツリーブロックまたはＣＴＵ）の符号化表現を生成し得る。初期ビデオブロックの符号化表現を生成することの一部として、ビデオエンコーダ２２は、複数のノードを備えるツリー構造を決定する。例えば、ビデオエンコーダ２２は、本開示のＭＴＴ区分構造を使用してツリーブロックを区分化し得る。

[0081]ＭＴＴ区分構造中の複数のノードは、複数のリーフノードと、複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造において親ノードに対応するビデオブロックのサブブロックであるビデオブロック（例えば、コード化ブロック）に対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において１つまたは複数の子ノードを有する。いくつかの例では、ピクチャ境界にある非リーフノードは、強制的な分割による1つの子ノードのみを有し得、子ノードのうちの１つは、ピクチャ境界の外側のブロックに対応する。

[0082]本開示の技法によれば、ツリー構造の各深度レベルにおけるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターン（例えば、区分構造）が存在する。例えば、ツリー構造の各深度に対して許容される３つ以上の区分構造が存在し得る。ビデオエンコーダ２２は、複数の許容可能な区分構造のうちの１つに従って、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化するように構成され得る。複数の許容区分構造の各それぞれの許容区分構造は、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応し得る。さらに、この例では、ビデオエンコーダ２２は、ビデオデータの符号化表現を備えるビットストリーム中に初期ビデオブロックの符号化表現を含め得る。

[0083]同様の例では、ビデオデコーダ３０は、複数のノードを備えるツリー構造を決定し得る。前の例にあるように、複数のノードは、複数のリーフノードと複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造において親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において１つまたは複数の子ノードを有する。ツリー構造の各深度レベルにおけるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターンが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの１つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容分割パターンの各それぞれの許容分割パターンは、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応する。さらに、この例では、ツリー構造の各（または少なくとも１つの）それぞれのリーフノードについて、ビデオデコーダ３０は、それぞれのリーフノードに対応するビデオブロックを再構築する。

[0084]いくつかのこのような例では、ルートノード以外のツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードのための複数の許容分割パターン（例えば、区分構造）は、それに従ってそれぞれの非リーフノードの親ノードに対応するビデオブロックがそれぞれの非リーフノードの親ノードの子ノードに対応するビデオブロックへと区分化される区分構造から独立している。

[0085]本開示の他の例では、ツリー構造の各深度において、ビデオエンコーダ２２は、さらに３つの区分構造のうちの１つの中からの特定の区分タイプを使用して、サブツリーをさらに分割するように構成され得る。例えば、ビデオエンコーダ２２は、ＱＴ、ＢＴ、三分木（ＴＴ）および他の区分構造から特定の区分タイプを決定するように構成され得る。一例では、ＱＴ区分構造は、正方形四分木および長方形四分木区分タイプを含み得る。ビデオエンコーダ２２は、正方形ブロックを４つの等しいサイズの正方形ブロックへと、水平および垂直の両方に真ん中で半分に分割することで、正方形四分木区分化を使用してこのブロックを区分化し得る。同様に、ビデオエンコーダ２２は、長方形（例えば、非正方形）ブロックを４つの等しいサイズの長方形ブロックへと、水平および垂直の両方に真ん中で半分に分割することで、長方形の四分木区分を使用してこの長方形ブロックを区分化し得る。

[0086]ＢＴ区分構造は、水平対称二分木、垂直対称二分木、水平非対称二分木、および垂直非対称二分木区分タイプを含み得る。水平対称二分木区分タイプの場合、ビデオエンコーダ２２は、ブロックを、同じサイズの２つの対称的なブロックへとこのブロックの真ん中で半分に水平に分割するように構成され得る。垂直対称二分木区分タイプの場合、ビデオエンコーダ２２は、ブロックを、同じサイズの２つの対称的なブロックへとこのブロックの真ん中で半分に垂直に分割するように構成され得る。水平非対称二分木区分タイプの場合、ビデオエンコーダ２２は、ブロックを、異なるサイズの２つのブロックへと水平に分割するように構成され得る。例えば、図３のＰＡＲＴ＿２ＮｘｎＵまたはＰＡＲＴ＿２ＮｘｎＤ区分タイプにあるように、一方のブロックは、親ブロックのサイズの１／４であり得、他方のブロックは、親ブロックのサイズの３／４であり得る。垂直非対称二分木区分タイプの場合、ビデオエンコーダ２２は、ブロックを、異なるサイズの２つのブロックへと垂直に、分割するように構成され得る。例えば、図３のＰＡＲＴ＿ｎＬｘ２ＮまたはＰＡＲＴ＿ｎＲｘ２Ｎ区分タイプにあるように、一方のブロックは、親ブロックのサイズの１／４であり得、他方のブロックは、親ブロックのサイズの３／４であり得る。

[0087]他の例では、非対称二分木区分タイプは、親ブロックを異なるサイズのフラクション（fraction）へと分割し得る。例えば、一方のサブブロックは、親ブロックの３／８であり得、他方のサブブロックは、親ブロックの５／８であり得る。当然ながら、このような区分タイプは、垂直または水平のいずれかであり得る。

[0088]ＴＴ区分構造は、ＴＴ区分構造がブロックの真ん中で半分に分割しない点で、ＱＴまたはＢＴ構造のものとは異なり得る。ブロックの中心領域は、全体が（together）同じサブブロックに留まる。４つのブロックを作り出すＱＴまたは２つのブロックを作り出す二分木とは異なり、ＴＴ区分構造に従って分割すると、３つのブロックを作り出す。ＴＴ区分構造にしたがった例となる区分タイプには、（水平および垂直の両方の）対称区分タイプおよび（水平および垂直の両方の）非対称区分タイプが含まれる。さらに、ＴＴ区分構造にしたがった対称区分タイプは、非一様／不均一または一様／均一であり得る。本開示のＴＴ区分構造にしたがった非対称区分タイプは、非一様／不均一である。本開示の一例では、ＴＴ区分構造は、水平一様／均一対称三分木、垂直一様／均一対称三分木、水平非一様／不均一対称三分木、垂直非一様／不均一対称三分木、水平非一様／不均一非対称三分木、および垂直非一様／不均一非対称三分木区分タイプという区分タイプを含み得る。

[0089]一般に、非一様／不均一対称三分木区分タイプは、ブロックの中心線を中心にして対称であるが、結果として得られるブロック３つのブロックのうちの少なくとも１つは、その他の２つとは同じサイズではない区分タイプである。１つの好ましい例は、サイドブロックがブロックの１／４のサイズであり、センタブロックが、ブロックのサイズの１／２である場合である。一様／均一対称三分木区分タイプは、ブロックの中心線を中心にして対称であり、結果として得られるブロックはすべて同じサイズである区分タイプである。このような区分は、ブロックの高さまたは幅が、垂直または水平分割に依存して、３の倍数である場合に可能である。非一様／不均一非対称三分木区分タイプは、ブロックの中心線を中心にして対称ではなく、結果として得られるブロックのうちの少なくとも１つがその他の２つと同じサイズではない区分タイプである。

[0090]図５Ａは、例となる水平三分木区分タイプを例示する概念図である。図５Ｂは、例となる垂直三分木区分タイプを例示する概念図である。図５Ａおよび図５Ｂの両方において、ｈは、ルーマまたはクロマサンプル中のブロックの高さを表し、ｗは、ルーマまたはクロマサンプル中のブロックの幅を表す。図５Ａおよび図５Ｂにおける三分木区分の各々のそれぞれの「中心線」がブロックの境界を表さない（すなわち、三分木区分は、この中心線を通ってブロックを分割しない）ことに留意されたい。むしろ、中心線は、特定の区分タイプが元のブロックの中心線に対して対称または非対称であるか否かを描写するために示される。描写されている中心線はまた、分割の方向に沿っている。

[0091]図５Ａに示されるように、ブロック７１は、水平一様／均一対称区分タイプで区分化される。水平一様／均一対称区分タイプは、ブロック７１の中心線に対して対称的な上半分および下半分を作り出す。水平一様／均一対称区分タイプは、各々ｈ／３の高さおよびｗの幅を有する、サイズが等しい３つのサブブロックを作り出す。水平一様／均一対称区分タイプは、ブロック７１の高さが３で割り切れるときに可能である。

[0092]ブロック７３は、水平非一様／不均一対称区分タイプで区分化される。水平非一様／不均一対称区分タイプは、ブロック７３の中心線に対して対称的な上半分および下半分を作り出す。水平非一様／不均一対称区分タイプは、サイズが等しい２つのブロック（例えば、ｈ／４の高さを有する上ブロックおよび底部ブロック）と、異なるサイズのセンタブロック（例えば、ｈ／２の高さを有するセンタブロック）を作り出す。本開示の一例では、水平非一様／不均一対称区分タイプに従って、センタブロックの面積は、上ブロックと底部ブロックとを合わせた面積に等しい。いくつかの例では、水平非一様／不均一対称区分タイプは、２の累乗（例えば、２，４，８，１６，３２，等）である高さを有するブロックに対して好ましいであろう。

[0093]ブロック７５は、水平非一様／不均一非対称区分タイプで区分化される。水平非一様／不均一非対称区分タイプは、ブロック７５の中心線に対して対称的な上半分および下半分を作り出さない（すなわち、上半分と下半分は非対称である）。図５Ａの例では、水平非一様／不均一非対称区分タイプは、ｈ／４の高さを有する上ブロックと、３ｈ／８の高さを有するセンタブロックと、３ｈ／８の高さを有する底部ブロックとを作り出す。当然ながら、他の非対称配置が使用され得る。

[0094]図５Ｂに示されるように、ブロック７７は、垂直一様／均一対称区分タイプで区分化される。垂直一様／均一対称区分タイプは、ブロック７７の中心線に対して対称的な左半分および右半分を作り出す。垂直一様／均一対称区分タイプは、各々ｗ／３の幅およびｈの高さを有する、サイズが等しい３つのサブブロックを作り出す。垂直一様／均一対称区分タイプは、ブロック７７の幅が３で割り切れるときに可能である。

[0095]ブロック７９は、垂直非一様／不均一対称区分タイプで区分化される。垂直非一様／不均一対称区分タイプは、ブロック７９の中心線に対して対称的な左半分および右半分を作り出す。垂直非一様／不均一対称区分タイプは、７９の中心線に関して対称的な左半分および右半分を作り出す。垂直非一様／不均一対称区分タイプは、サイズが等しい２つのブロック（例えば、ｗ／４の幅を有する左ブロックおよび右ブロック）と、異なるサイズのセンタブロック（例えば、ｗ／２の幅を有するセンタブロック）とを作り出す。本開示の一例では、垂直非一様／不均一対称区分タイプに従って、センタブロックの面積は、左ブロックと右ブロックとを合わせた面積に等しい。いくつかの例では、垂直非一様／不均一対称区分タイプは、２の累乗（例えば、２，４，８，１６，３２，等）である幅を有するブロックに対して好ましいであろう。

[0096]ブロック８１は、垂直非一様／不均一非対称区分タイプで区分化される。垂直非一様／不均一非対称区分タイプは、ブロック８１の中心線に対して対称的な左半分および右半分を作り出さない（すなわち、左半分と右半分は非対称である）。図５Ｂの例では、垂直非一様／不均一非対称区分タイプは、ｗ／４の幅を有する左ブロックと、３ｗ／８の幅を有するセンタブロックと、３ｗ／８の幅を有する底部ブロックとを作り出す。当然ながら、他の非対称配置が使用され得る。

[0097]（例えば、サブツリーノードにおける）ブロックが非対称三分木区分タイプに分割される例では、ビデオエンコーダ２２および／またはビデオデコーダ３０は、３つの区分のうちの２つが同じサイズを有するという制約（restriction）を適用し得る。そのような制約は、ビデオデータを符号化するときにビデオエンコーダ２２が準拠しなければならない制限に対応し得る。さらに、いくつかの例では、ビデオエンコーダ２２およびビデオデコーダ３０は、非対称三分木区分タイプに従って分割するとき、２つの区分の面積の合計が残りの区分の面積に等しくなる制約を適用し得る。例えば、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードが、第１の子ノード、第２の子ノード、および第３の子ノードを有すること、ここで、第２の子ノードが、第１の子ノードに対応するビデオブロックと第３の子ノードに対応するビデオブロックとの間のビデオブロックに対応し、第１および第３の子ノードに対応するビデオブロックが同じサイズを有し、第１および第３の子ノードに対応するビデオブロックのサイズの合計が、第２の子ノードに対応するビデオブロックのサイズに等しい、を規定する制約に適合する初期ビデオブロックの符号化表現を、ビデオエンコーダ２２は生成し得、または、ビデオデコーダ３０は受信し得る。

[0098]本開示のいくつかの例では、ビデオエンコーダ２２は、ＱＴ、ＢＴ、およびＴＴ区分構造の各々について、前述の区分タイプのすべての中から選択するように構成され得る。他の例では、ビデオエンコーダ２２は、前述の区分タイプのサブセットの中から区分タイプのみを決定するように構成され得る。例えば、上で述べた区分タイプ（または、他の区分タイプ）のサブセットは、特定のブロックサイズにまたは四分木構造の特定の深度に対して使用され得る。サポートされる区分タイプのサブセットは、ビデオデコーダ３０による使用のためにビットストリームにおいてシグナリングされ得るか、ビデオエンコーダ２２およびビデオデコーダ３０がシグナリングなしにサブセットを決定し得るようにあらかじめ定義され得る。

[0099]他の例では、サポートされる区分タイプの数は、すべてのＣＴＵ中のすべての深度に対して固定であり得る。すなわち、ビデオエンコーダ２２およびビデオデコーダ３０は、ＣＴＵのいずれの深度に対しても同じ数の区分タイプを使用するようにあらかじめ構成され得る。他の例では、サポートされる区分タイプの数は変化し得、深度、スライスタイプ、または他の前にコード化された情報に依存し得る。一例では、ツリー構造の深度０または深度１において、ＱＴ区分構造のみが使用される。１より大きい深度において、ＱＴ、ＢＴ、およびＴＴ区分構造の各々が使用され得る。

[0100]いくつかの例では、ビデオエンコーダ２２および／またはビデオデコーダ３０は、ビデオピクチャの特定の領域またはＣＴＵの領域に対する重複区分化を避けるために、サポートされる区分タイプに対して、あらかじめ構成された制約を適用し得る。一例では、ブロックが非対称区分タイプで分割されるとき、ビデオエンコーダ２２および／またはビデオデコーダ３０は、現在ブロックから分割された最大サブブロックをこれ以上分割しないように構成され得る。例えば、正方形ブロックが非対称区分タイプ（例えば、図３のＰＡＲＴ＿２ＮｘｎＵ区分タイプ）に従って分割されるとき、すべてのサブブロックの中の最大サブブロックは（例えば、図３のＰＡＲＴ＿２ＮｘｎＵ区分タイプのＰＵ１）、述べたリーフノードであり、これ以上分割されることができない。しかし、小さい方のサブブロック（例えば、図３のＰＡＲＴ＿２ＮｘｎＵ区分タイプのＰＵ０）は、さらに分割されることができる。

[0101]特定の領域に対する重複区分化を避けるために、サポートされる区分タイプに対する制約が適用され得る別の例として、ブロックが非対称区分タイプで分割されるとき、現在ブロックから分割された最大サブブロックは、同じ方向にはこれ以上分割されることができない。例えば、正方形ブロックが、分割された非対称区分タイプ（例えば、図３のＰＡＲＴ＿２ＮｘｎＵ区分タイプ）であるとき、ビデオエンコーダ２２および／またはビデオデコーダ３０は、すべてのサブブロックの中でも大きいサブブロック（例えば、図３のＰＡＲＴ＿２ＮｘｎＵ区分タイプのＰＵ１）を水平方向には分割しないように構成され得る。しかしながら、ビデオエンコーダ２２および／またはビデオデコーダ３０は、この例では、ＰＵ１を再び垂直方向には分割し得る。

[0102]さらなる分割の困難さを避けるために、サポートされる区分タイプに対する制約が適用され得る別の例として、ビデオエンコーダ２２および／またはビデオデコーダ３０は、ブロックの幅／高さが２のべき乗ではない（例えば、幅の高さが、２、４、８、１６、等でない）とき、ブロックを水平にも垂直にも分割しないように構成され得る。

[0103]上の例は、本開示の技法に従ってＭＴＴ区分化を実行するためにビデオエンコーダ２２がどのように構成され得るかを説明する。その後、ビデオデコーダ３０もまた、ビデオエンコーダ２２によって実行されたのと同じＭＴＴ区分化を適用し得る。いくつかの例では、ビデオデータのピクチャがビデオエンコーダ２２によってどのように区分化されたかは、ビデオデコーダ３０において、あらかじめ定義されたルールの同じセットを適用することで決定され得る。しかしながら、多くの状況では、ビデオエンコーダ２２は、コード化されているビデオデータの特定のピクチャに対するレート歪み基準に基づいて、使用すべき特定の区分構造および区分タイプを決定し得る。このように、ビデオデコーダ３０が特定のピクチャのための区分化を決定するために、ビデオエンコーダ２２は、ピクチャおよびピクチャのＣＴＵがどのように区分化されるべきかを示すシンタックス要素を、符号化されたビットストリームにおいてシグナリングし得る。ビデオデコーダ３０は、そのようなシンタックス要素を解析し、それに従ってピクチャおよびＣＴＵを区分化し得る。

[0104]本開示の一例では、ビデオエンコーダ２２は、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ、適応型パラメータセット（ＡＰＳ）、または任意の他の高レベルシンタックスパラメータセットにおいて、サポートされる区分タイプの特定のサブセットを高レベルシンタックス要素としてシグナリングするように構成され得。例えば、区分タイプの最大数およびどのタイプがサポートされるかは、あらかじめ定義され得るか、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、または任意の他の高レベルシンタックスパラメータセットにおいて、高レベルシンタックス要素として、ビットストリームにおいてシグナリングされ得る。ビデオデコーダ３０は、使用する区分タイプの特定のサブセットおよび／またはサポートされる区分構造（例えば、ＱＴ、ＢＴ、ＴＴ、等）の最大数およびタイプを決定するためにそのようなシンタックス要素を受信し、解析するように構成され得る。

[0105]いくつかの例では、各深度において、ビデオエンコーダ２２は、ツリー構造のその深度において使用される選択された区分タイプを示すインデックスをシグナリングするように構成され得る。さらに、いくつかの例では、ビデオエンコーダ２２は、各ＣＵにおいてそのような区分タイプのインデックスを適応的にシグナリングし得る。すなわち、インデックスは、ＣＵごとに異なり得る。例えば、ビデオエンコーダ２２は、１つまたは複数のレート歪み算出に基づいて、区分タイプのインデックスを設定し得る。一例では、特定の条件が満たされる場合、区分タイプ（例えば、区分タイプのインデックス）のシグナリングは省略され得る。例えば、ビデオエンコーダ２２は、特定の深度に関連付けられたサポートされる区分タイプが１つしか存在しないとき、区分タイプのシグナリングを省略し得る。この例では、ピクチャ境界に接近すると、コード化されることとなる領域は、ＣＴＵより小さいであろう。その結果として、この例では、ＣＴＵは、ピクチャ境界に収まるように強制的に分割され得る。一例では、強制的な分割に対して対称二分木のみが使用され得、いずれの区分タイプもシグナリングされない。いくつかの例では、特定の深度において、区分タイプは、スライスタイプ、ＣＴＵ深度、ＣＵ位置のような、前にコード化された情報に基づいて、導出され得る。

[0106]本開示の別の例では、ＣＵ（リーフノード）ごとに、ビデオエンコーダ２２は、同じサイズのＣＵに対して変換が実行されるべきか否かを示すためにシンタックス要素（例えば、１ビットのtransform_splitフラグ）をシグナリングするようにさらに構成され得る（すなわち、フラグは、ＴＵが、ＣＵのサイズと同じサイズであるかどうかまたはさらに分割されるかどうかを示す）。transform_splitフラグが真としてシグナリングされるケースでは、ビデオエンコーダ２２は、ＣＵの残差（residual）を複数のサブブロックへとさらに分割するように構成され得、変換が各サブブロックに対して行われる。ビデオデコーダ３０は、逆のプロセスを実行し得る。

[0107]一例では、transform_splitフラグが真としてシグナリングされるとき、以下が実行される。ＣＵが正方形ブロックに対応する（すなわち、ＣＵが正方形である）場合、ビデオエンコーダ２２は、四分木分割を使用して残差を４つの正方形サブブロックへと分割し、各正方形サブブロックに対して変換が実行される。ＣＵが非正方形ブロック、例えばＭｘＮ、に対応する場合、ビデオエンコーダ２２は、残差を２つのサブブロックへと分割し、サブブロックサイズは、Ｍ＞Ｎであるとき０．５ＭｘＮであり、Ｍ＜Ｎであるとき、Ｍｘ０．５Ｎである。別の例として、transform_splitフラグが真としてシグナリングされ、かつ、ＣＵが非正方形ブロック、例えばＭｘＮ、に対応する（すなわち、ＣＵが非正方形である）とき、ビデオエンコーダ２２は、残差をサイズＫｘＫのサブブロックへと分割するように構成され得、ＫｘＫ正方形変換が各サブブロックに対して使用され、ここで、Ｋは、ＭおよびＮの最大係数に等しい。別の例として、ＣＵが正方形ブロックであるとき、transform_splitフラグはシグナリングされない。

[0108]いくつかの例では、分割フラグはシグナリングされず、１つの導出されたサイズを有する変換のみが、予測後のＣＵ中に残余（residue）があるときに使用される。例えば、ＭｘＮに等しいサイズを有するＣＵ、ＫｘＫ二乗変換が使用され、ここで、Ｋは、ＭおよびＮの最大係数に等しい。ゆえに、この例では、サイズが１６ｘ８のＣＵの場合、同じ８ｘ８変換が、ＣＵの残差データの２つの８ｘ８サブブロックに適用され得る。「分割フラグ」は、ツリー構造におけるノードがツリー構造において子ノードを有することを示すシンタックス要素である。

[0109]いくつかの例では、各ＣＵについて、ＣＵが正方形四分木、または対称二分木に分割されない場合、ビデオエンコーダ２２は、区分サイズ（例えば、ＣＵのサイズ）に等しくなるように変換サイズを常に設定するように構成される。

[0110]シミュレーション結果は、ＪＥＭ－３．１参照ソフトウェアと比較して、本開示のＭＴＴ技法を使用したコーディング性能が、ランダムアクセスのケースにおいて、改善を示したことを示している。平均で、シミュレーションは、本開示のＭＴＴ技法が、適度な符号化時間の増加のみで、３．１８％のビットレート－歪み（ＢＤ）レート低減をもたらしたことを示している。シミュレーションは、本開示のＭＴＴ技法が、より高い解像度に対して良好な性能、例えば、クラスＡ１およびクラスＡ２テストに対して４．２０％および４．８９％のルーマＢＤレート低減、を提供することを示している。クラスＡ１およびクラスＡ２は、例となる４Ｋ解像度テストシーケンスである。

[0111]ビデオエンコーダ２２を参照して説明した上の例の各々について、ビデオデコーダ３０が、逆のプロセスを実行するように構成され得ることは理解されるべきである。シンタックス要素をシグナリングすることに関して、ビデオデコーダ３０は、そのようなシンタックス要素を受信および解析し、それに従って関連するビデオデータを区分化および復号するように構成され得る。

[0112]本開示の１つの特定の例では、ビデオデコーダは、３つの異なる区分構造（ＱＴ、ＢＴ、およびＴＴ）に従ってビデオブロックを区分化するように構成され得、ここで、５つの異なる区分タイプが各深度において許容される。区分タイプには、図５Ａ～図５Ｅに示されるように、四分木区分化（ＱＴ区分構造）、水平二分木区分化（ＢＴ区分構造）、垂直二分木区分化（ＢＴ区分構造）、水平センタ－サイド三分木区分化（ＴＴ区分構造）、および垂直センタ－サイド三分木区分化（ＴＴ区分構造）が含まれる。

[0113]５つの区分タイプの定義は以下の通りである。正方形が長方形の特別なケースとみなされることに留意されたい。
・四分木区分化：１つのブロックが、４つの同じサイズの長方形ブロックへとさらに分割される。図６Ａは、四分木分区分化の例を示す。
・垂直二分木区分化：１つのブロックが、２つの同じサイズの長方形ブロックへと垂直に分割される。図６Ｂは、垂直二分木区分化の例である。
・水平二分木区分化：１つのブロックが、２つの同じサイズの長方形ブロックへと水平に分割される。図６Ｃは、水平二分木区分化の例である。
・垂直センタ－サイド三分木区分化：２つのサイドブロックが同じサイズを共有しつつ、センタブロックのサイズがこれら２つのサイドブロックの合計になるように、１つのブロックが、３つの長方形ブロックへと垂直に分割される。図６Ｄは、垂直センタ－サイド三分木区分化の例である。
・水平センタ－サイド三分木区分化：２つのサイドブロックが同じサイズを共有しつつ、センタブロックのサイズがこれら２つのサイドブロックの合計になるように、１つのブロックが、３つの長方形ブロックへと水平に分割される。図６Ｅは、水平センタ－サイド三分木区分化の例である。

[0114]特定の深度に関連付けられたブロックについて、ビデオエンコーダ２２は、どの区分タイプ（これ以上の分割がないことを含む）が使用されるかを決定し、決定された区分タイプを明示的または暗示的にビデオデコーダ３０にシグナリングする（例えば、区分タイプは、所定のルールから導出され得る）。ビデオエンコーダ２２は、異なる区分タイプを使用してブロックのためのレート歪みコストをチェックすることに基づいて、使用すべき区分タイプを決定し得る。レート歪みコストを得るために、ビデオエンコーダ２２は、ブロックについての可能な区分タイプを再帰的にチェックする必要があり得る。

[0115]図７は、コード化ツリー単位（ＣＴＵ）区分化の例を示す概念図である。換言すると、図７は、ＣＴＵに対応するＣＴＢ９１の区分化を例示する。図７の別の例では、
・深度０において、ＣＴＢ９１（すなわち、ＣＴＢ全体）が、（破線が一点で区切られている線９３で示されるように）水平二分木区分化で２つのブロックへと分割される。
・深度１において：
・上部ブロックは、（小破線の線９５および８６で示されるように）垂直センタ－サイド三分木区分化で３つのブロックへと分割される。
・底部ブロックは、（破線が二点で区切られている線８８および９０で示されるように）四分木区分化で４つのブロックへと分割される。
・深度２において：
・深度１における上部ブロックの左側ブロックは、（長い破線が短い破線で区切られている線９２および９４で示されるように）水平センタ－サイド三分木区分化で３つのブロックへと分割される。
・深度１における上部ブロックのセンタブロックおよび右ブロックに対してはこれ以上の分割はない。
・深度１における底部ブロックの４つのブロックに対してはこれ以上の分割はない。

[0116]図７の例から明らかなように、４つの異なる区分タイプ（水平二分木区分化、垂直センタ－サイド三分木区分化、四分木区分化、および水平センタ－サイド三分木区分化）を有する３つの異なる区分構造（ＢＴ、ＱＴ、およびＴＴ）が使用される。

[0117]別の例では、追加の制約が、特定の深度にあるまたは一定のサイズのブロックに適用され得る。例えば、ブロックの高さ／幅が１６画素より小さい場合、このブロックは、４画素より小さい高さ／幅を有するブロックを避けるために、垂直／水平センタ－サイド木で分割されることができない。

[0118]様々な例が説明されてきた。本開示の特定の例は、別個にまたは互いと組み合わせて使用され得る。

[0119]図８は、本開示の技法をインプリメントし得る例となるビデオエンコーダ２２を例示するブロック図である。図８は、説明の目的のために提供されており、本開示で広く実証および説明される技法を限定するものとみなされるべきではない。本開示の技法は、様々なコーディング規格または方法に適用可能であり得る。

[0120]図８の例では、ビデオエンコーダ２２は、予測処理ユニット１００と、ビデオデータメモリ１０１と、残差生成ユニット１０２と、変換処理ユニット１０４と、量子化ユニット１０６と、逆量子化ユニット１０８と、逆変換処理ユニット１１０と、再構築ユニット１１２と、フィルタユニット１１４と、復号ピクチャバッファ１１６と、エントロピー符号化ユニット１１８とを含む。予測処理ユニット１００は、インター予測処理ユニット１２０と、イントラ予測処理ユニット１２６とを含む。インター予測処理ユニット１２０は、動き推定ユニットと、動き補償ユニットとを含み得る（図示されない）。

[0121]ビデオデータメモリ１０１は、ビデオエンコーダ２２の構成要素によって符号化されるべきビデオデータを記憶するように構成され得る。ビデオデータメモリ１０１に記憶されたビデオデータは、例えば、ビデオソース１８から取得され得る。復号ピクチャバッファ１１６は、例えば、イントラまたはインターコード化モードで、ビデオエンコーダ２２がビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）、磁気ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスを含むＤＲＡＭのような、様々なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ１０１は、ビデオエンコーダ２２の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。ビデオデータメモリ１０１は、図１の記憶媒体２０と同じまたはその一部であり得る。

[0122]ビデオエンコーダ２２は、ビデオデータを受信する。ビデオエンコーダ２２は、このビデオデータのピクチャのスライス中の各ＣＴＵを符号化し得る。ＣＴＵの各々は、等しいサイズのルーマコード化ツリーブロック（ＣＴＢ）およびピクチャの対応するＣＴＢに関連付けられ得る。ＣＴＵを符号化することの一部として、予測処理ユニット１００は、ＣＴＵのＣＴＢを漸進的に小さいブロックへと分割するために区分化を実行し得る。より小さいブロックは、ＣＵのコード化ブロックであり得る。例えば、予測処理ユニット１００は、ツリー構造に従って、ＣＴＵに関連付けられたＣＴＢを区分化し得る。本開示の１つまたは複数の技法に従って、ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターンが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの１つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。一例では、予測処理ユニット１００またはビデオエンコーダ２２の別の処理ユニットは、上で説明したＭＴＴ区分化技法の任意の組合せを実行するように構成され得る。

[0123]ビデオエンコーダ２２は、ＣＵの符号化表現（すなわち、コード化されたＣＵ）を生成するために、ＣＴＵのＣＵを符号化し得る。ＣＵを符号化することの一部として、予測処理ユニット１００は、ＣＵの１つまたは複数のＰＵの間でＣＵに関連付けられたコード化ブロックを区分化し得る。本開示の技法に従って、ＣＵは、単一のＰＵのみを含み得る。すなわち、本開示のいくつかの例では、ＣＵが別々の予測ブロックへと分割されるのではなく、むしろ、予測プロセスが、このＣＵ全体に対して実行される。ゆえに、各ＣＵは、ルーマ予測ブロックおよび対応するクロマ予測ブロックに関連付けられ得る。ビデオエンコーダ２２およびビデオデコーダ３０は、様々なサイズを有するＣＵをサポートし得る。上に示したように、ＣＵのサイズは、ＣＵのルーマコード化ブロックのサイズ、そしてルーマ予測ブロックのサイズを指し得る。上で述べたように、ビデオエンコーダ２２およびビデオデコーダ３０は、上で説明した例となるＭＴＴ区分化タイプの任意の組合せによって定義されるＣＵサイズをサポートし得る。

[0124]インター予測処理ユニット１２０は、ＣＵの各ＰＵに対してインター予測を実行することで、ＰＵについての予測データを生成し得る。上述したように、本開示のいくつかのＭＴＴの例では、ＣＵは、単一のＰＵのみを含み得、すなわち、ＣＵおよびＰＵは同義であり得る。ＰＵについての予測データは、ＰＵの予測ブロックおよびＰＵのための動き情報を含み得る。インター予測処理ユニット１２０は、ＰＵが、Ｉスライス中にあるか、Ｐスライス中にあるか、Ｂスライス中にあるかに依存して、ＰＵまたはＣＵのために異なる動作を実行し得る。Ｉスライスでは、すべてのＰＵがイントラ予測される。そのため、ＰＵがＩスライス中にある場合、インター予測処理ユニット１２０は、ＰＵに対してインター予測を実行しない。ゆえに、Ｉモードで符号化されるブロックの場合、予測されたブロックは、同じピクチャ内の前に符号化された隣接ブロックからの空間予測を使用して形成される。ＰＵがＰスライス中にある場合、インター予測処理ユニット１２０は、ＰＵの予測ブロックを生成するために、単方向性インター予測を使用し得る。ＰＵがＢスライス中にある場合、インター予測処理ユニット１２０は、ＰＵの予測ブロックを生成するために、単方向性または双方向性インター予測を使用し得る。

[0125]イントラ予測処理ユニット１２６は、ＰＵに対してイントラ予測を実行することで、ＰＵの予測データを生成し得る。ＰＵについての予測データは、ＰＵの予測ブロックおよび様々なシンタックス要素を含み得る。イントラ予測処理ユニット１２６は、Ｉスライス、Ｐスライス、およびＢスライス中のＰＵに対してイントラ予測を実行し得る。

[0126]ＰＵに対してイントラ予測を実行するために、イントラ予測処理ユニット１２６は、ＰＵについての予測データの複数のセットを生成するために、複数のイントラ予測モードを使用し得る。イントラ予測処理ユニット１２６は、ＰＵについての予測ブロックを生成するために、隣接するＰＵのサンプルブロックからサンプルを使用し得る。隣接するＰＵは、ＰＵ、ＣＵ、およびＣＴＵに対して左から右、上から下の符号化順序を前提として、ＰＵの上、右上、左上、または左にあり得る。イントラ予測処理ユニット１２６は、様々な数のイントラ予測モード、例えば、３３個の指向性イントラ予測モードを使用し得る。いくつかの例では、イントラ予測モードの数は、ＰＵに関連付けられた領域のサイズに依存し得る。

[0127]予測処理ユニット１００は、ＰＵについてのインター予測処理ユニット１２０によって生成された予測データまたはＰＵについてのイントラ予測処理ユニット１２６によって生成された予測データの中から、ＣＵのＰＵについての予測データを選択し得る。いくつかの例では、予測処理ユニット１００は、予測データのセットのレート／歪みメトリックに基づいて、ＣＵのＰＵについての予測データを選択する。選択された予測データの予測ブロックは、ここでは、選択された予測ブロックと呼ばれ得る。

[0128]残差生成ユニット１０２は、ＣＵについてのコード化ブロック（例えば、ルーマ、Ｃｂ、およびＣｒコード化ブロック）と、ＣＵのＰＵについての選択された予測ブロック（例えば、予測ルーマ、Ｃｂ、およびＣｒブロック）とに基づいて、ＣＵについての残差ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ残差ブロック）を生成し得る。例えば、残差生成ユニット１０２は、残差ブロック中の各サンプルが、ＣＵのコード化ブロック中のサンプルと、ＣＵのＰＵの対応する選択された予測ブロック中の対応するサンプルとの間の差分に等しい値を有するように、ＣＵの残差ブロックを生成し得る。

[0129]変換処理ユニット１０４は、ＣＵに関連付けられた残差ブロックをＣＵのＴＵに関連付けられた変換ブロックに区分化するために四分木区分化を実行し得る。ゆえに、ＴＵは、１つのルーマ変換ブロックと、２つのクロマ変換ブロックとに関連付けられ得る。ＣＵのＴＵのルーマおよびクロマ変換ブロックのサイズおよび位置は、ＣＵのＰＵの予測ブロックのサイズおよび位置に基づく場合も基づかない場合もある。「残余四分木」（ＲＱＴ）として知られている四分木構造は、領域の各々に関連付けられたノードを含み得る。ＣＵのＴＵは、ＲＱＴのリーフノードに対応し得る。他の例では、変換処理ユニット１０４は、上で説明したＭＴＴ技法に従ってＴＵを区分化するように構成され得る。例えば、ビデオエンコーダ２２は、ＲＱＴ構造を使用して、ＣＵをＴＵへとこれ以上分割することができない。このように、一例では、ＣＵは、単一のＴＵを含む。

[0130]変換処理ユニット１０４は、ＴＵの変換ブロックに１つまたは複数の変換を適用することで、ＣＵのＴＵごとに変換係数ブロックを生成し得る。変換処理ユニット１０４は、ＴＵに関連付けられた変換ブロックに様々な変換を適用し得る。例えば、変換処理ユニット１０４は、変換ブロックに、離散コサイン変換（ＤＣＴ）、方向性変換、または概念的に類似した変換を適用し得る。いくつかの例では、変換処理ユニット１０４は、変換ブロックに変換を適用しない。そのような例では、変換ブロックは、変換係数ブロックとして扱われ得る。

[0131]量子化ユニット１０６は、係数ブロックにおける変換係数を量子化し得る。量子化プロセスは、これら変換係数のうちのいくつかまたはすべてに関連付けられたビット深度を低減し得る。例えば、ｎビット変換係数は、量子化中、ｍビット変換係数へと端数が切り捨てられ得、ここで、ｎは、ｍより大きい。量子化ユニット１０６は、ＣＵに関連付けられた量子化パラメータ（ＱＰ）値に基づいて、ＣＵのＴＵに関連付けられた係数ブロックを量子化し得る。ビデオエンコーダ２２は、ＣＵに関連付けられたＱＰ値を調整することで、ＣＵに関連付けられた係数ブロックに適用される量子化の程度を調整し得る。量子化は、情報の損失を引き起こし得る。ゆえに、量子化された変換係数は、元のものより低い精度を有し得る。

[0132]逆量子化ユニット１０８および逆変換処理ユニット１１０は、係数ブロックから残差ブロックを再構築するために、それぞれ、係数ブロックに逆量子化および逆変換を適用し得る。再構築ユニット１１２は、ＴＵに関連付けられた再構築された変換ブロックを作り出すために、再構築された残差ブロックを、予測処理ユニット１００によって生成された１つまたは複数の予測ブロックからの対応するサンプルに加算し得る。このようにしてＣＵのＴＵごとに変換ブロックを再構築することで、ビデオエンコーダ２２は、ＣＵのコード化ブロックを再構築し得る。

[0133]フィルタユニット１１４は、ＣＵに関連付けられたコード化ブロック中のブロッキングアーティファクトを低減するために、１つまたは複数のデブロッキング動作を実行し得る。復号ピクチャバッファ１１６は、フィルタユニット１１４が再構築されたコード化ブロックに対して１つまたは複数のデブロッキング動作を実行した後に、再構築されたコード化ブロックを記憶し得る。インター予測処理ユニット１２０は、他のピクチャのＰＵに対してインター予測を実行するために、再構築されたコード化ブロックを含む参照ピクチャを使用し得る。加えて、イントラ予測処理ユニット１２６は、ＣＵと同じピクチャ中の他のＰＵに対してイントラ予測を実行するために、復号ピクチャバッファ１１６中の再構築されたコード化ブロックを使用し得る。

[0134]エントロピー符号化ユニット１１８は、ビデオエンコーダ２２の他の機能構成要素からデータを受け取り得る。例えば、エントロピー符号化ユニット１１８は、量子化ユニット１０６から係数ブロックを受け取り得、予測処理ユニット１００からシンタックス要素を受け取り得る。エントロピー符号化ユニット１１８は、エントロピー符号化済みデータを生成するために、データに対して１つまたは複数のエントロピー符号化動作を実行し得る。例えば、エントロピー符号化ユニット１１８は、データに対して、ＣＡＢＡＣ動作、コンテキスト適応型可変長コード（ＣＡＶＬＣ）動作、Ｖ２Ｖ（variable-to-variable）長コード化動作、シンタックスベースコンテキスト適応型バイナリ算術コード化（ＳＢＡＣ）動作、確立間隔区分化エントロピー（ＰＩＰＥ）コード化動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作を実行し得る。ビデオエンコーダ２２は、エントロピー符号化ユニット１１８によって生成されたエントロピー符号化済みデータを含むビットストリームを出力し得る。例えば、ビットストリームは、本開示の技法に従ってＣＵのための区分構造を表すデータを含み得る。

[0135]図９は、本開示の技法をインプリメントするように構成された例となるビデオデコーダ３０を例示するブロック図である。図９は、説明の目的のために提供されており、本開示で広く実証および説明される技法を限定するものではない。説明の目的のために、本開示は、ＨＥＶＣコード化のコンテキストでビデオデコーダ３０を説明する。しかしながら、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。

[0136]図９の例では、ビデオデコーダ３０は、エントロピー復号ユニット１５０と、ビデオデータメモリ１５１と、予測処理ユニット１５２と、逆量子化ユニット１５４と、逆変換処理ユニット１５６と、再構築ユニット１５８と、フィルタユニット１６０と、復号ピクチャバッファ１６２とを含む。予測処理ユニット１５２は、動き補償ユニット１６４と、イントラ予測処理ユニット１６６とを含む。他の例では、ビデオデコーダ３０は、より多い数の、より少ない数の、または異なる機能構成要素を含み得る。

[0137]ビデオデータメモリ１５１は、ビデオデコーダ３０の構成要素によって復号されることとなる、符号化されたビデオビットビットストリームのような符号化されたビデオデータを記憶し得る。ビデオデータメモリ１５１に記憶されたビデオデータは、例えば、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介してまたは物理データ記憶媒体にアクセスすることで、コンピュータ可読媒体１６から、例えば、カメラのようなローカルビデオソースから、取得され得る。ビデオデータメモリ１５１は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶するコード化ピクチャバッファ（ＣＰＢ）を形成し得る。復号ピクチャバッファ１６２は、例えば、イントラまたはインターコード化モードで、ビデオデコーダ３０がビデオデータを復号する際に使用するためのまたは出力のための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ１５１および復号ピクチャバッファ１６２は、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）、磁気ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスを含むＤＲＡＭのような、様々なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ１５１および復号ピクチャバッファ１６２は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ１５１は、ビデオデコーダ３０の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。ビデオデータメモリ１５１は、図１の記憶媒体２８と同じまたはその一部であり得る。

[0138]ビデオデータメモリ１５１は、ビットストリームの符号化されたビデオデータ（例えば、ＮＡＬ単位）を受け取り、記憶する。エントロピー復号ユニット１５０は、ビデオデータメモリ１５１から符号化されたビデオデータ（例えば、ＮＡＬ単位）を受け取り、シンタックス要素を取得するためにこのＮＡＬ単位を解析し得る。エントロピー復号ユニット１５０は、ＮＡＬ単位中のエントロピー符号化されたシンタックス要素をエントロピー復号し得る。予測処理ユニット１５２、逆量子化ユニット１５４、逆変換処理ユニット１５６、再構築ユニット１５８、およびフィルタユニット１６０は、ビットストリームから抽出されたシンタックス要素に基づいて、復号されたビデオデータを生成し得る。エントロピー復号ユニット１５０は、エントロピー符号化ユニット１１８のプロセスとは概ね逆のプロセスを実行し得る。

[0139]本開示のいくつかの例に従って、エントロピー復号ユニット１５０、またはビデオデコーダ３０の別の処理ユニットは、ビットストリームからシンタックス要素を取得することの一部としてツリー構造を決定し得る。ツリー構造は、ＣＴＢのような初期ビデオブロックがコード化単位のようなより小さいビデオブロックへとどのように区分化されるかを指定し得る。本開示の１つまたは複数の技法に従って、ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの１つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。

[0140]ビットストリームからシンタックス要素を取得することに加えて、ビデオデコーダ３０は、非区分化ＣＵに対して再構築動作を実行し得る。ＣＵに対して再構築動作を実行するために、ビデオデコーダ３０は、ＣＵの各ＴＵに対して再構築動作を実行し得る。ＣＵの各ＴＵに対して再構築動作を実行することで、ビデオデコーダ３０は、ＣＵの残差ブロックを再構築し得る。上で述べたように、本開示の一例では、ＣＵは、単一のＴＵを含む。

[0141]ＣＵのＴＵに対して再構築動作を実行することの一部として、逆量子化ユニット１５４は、ＴＵに関連付けられた係数ブロックを逆量子化（inverse quantize）、すなわち逆量子化（de-quantize）し得る。逆量子化ユニット１５４が係数ブロックを逆量子化した後、逆変換処理ユニット１５６は、ＴＵに関連付けられた残差ブロックを生成するために、この係数ブロックに１つまたは複数の逆変換を適用し得る。例えば、逆変換処理ユニット１５６は、係数ブロックに、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向性変換、または別の逆変換を適用し得る。

[0142]ＣＵまたはＰＵがイントラ予測を使用して符号化される場合、イントラ予測処理ユニット１６６は、ＰＵの予測ブロックを生成するために、イントラ予測を実行し得る。イントラ予測処理ユニット１６６は、ブロックに空間的に隣接するサンプルに基づいて、ＰＵの予測ブロックを生成するために、イントラ予測モードを使用し得る。イントラ予測処理ユニット１６６は、ビットストリームから取得された１つまたは複数のシンタックス要素に基づいて、ＰＵのためのイントラ予測モードを決定し得る。

[0143]ＰＵがインター予測を使用して符号化される場合、エントロピー復号ユニット１５０は、ＰＵについての動き情報を決定し得る。動き補償ユニット１６４は、ＰＵの動き情報に基づいて、１つまたは複数の参照ブロックを決定し得る。動き補償ユニット１６４は、１つまたは複数の参照ブロックに基づいて、ＰＵについての予測ブロック（例えば、予測ルーマ、Ｃｂ、およびＣｒブロック）を生成し得る。上で述べたように、ＭＴＴ区分化を使用する本開示の一例では、ＣＵは、単一のＰＵのみを含み得る。すなわち、ＣＵは、複数のＰＵへと分割されないであろう。

[0144]再構築ユニット１５８は、ＣＵについてのコード化ブロック（例えば、ルーマ、Ｃｂ、およびＣｒコード化ブロック）を再構築するために、ＣＵのＴＵのための変換ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ変換ブロック）およびＣＵのＰＵの予測ブロック（例えば、ルーマ、Ｃｂ、およびＣｒブロック）、すなわち、適用可能な場合、イントラ予測データまたはインター予測データのいずれかを使用し得る。例えば、再構築ユニット１５８は、ＣＵのコード化ブロック（例えば、ルーマ、Ｃｂ、およびＣｒコード化ブロック）を再構築するために、変換ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ変換ブロック）のサンプルを、予測ブロック（例えば、ルーマ、Ｃｂ、およびＣｒ予測ブロック）の対応するサンプルに加算し得る。

[0145]フィルタユニット１６０は、ＣＵのコード化ブロックに関連付けられたブロッキングアーティファクトを低減するためにデブロッキング動作を実行し得る。ビデオデコーダ３０は、ＣＵのコード化ブロックを復号ピクチャバッファ１６２に記憶し得る。復号ピクチャバッファ１６２は、後続の動き補償、イントラ予測、および、図１のディスプレイデバイス３２のようなディスプレイデバイス上での提示のために、参照ピクチャを提供し得る。例えば、ビデオデコーダ３０は、復号ピクチャバッファ１６２中のブロックに基づいて、他のＣＵのＰＵのためにイントラ予測またはインター予測動作を実行し得る。

[0146]図１０Ａは、本開示の技法に係る、ビデオエンコーダ２２の例となる動作を例示するフローチャートである。図１０Ａの例では、ビデオエンコーダ２２は、ビデオデータの初期ビデオブロック（例えば、コード化ツリーブロック）の符号化表現を生成し得る（２００）。初期ビデオブロックの符号化表現を生成することの一部として、ビデオエンコーダ２２は、複数のノードを備えるツリー構造を決定する。複数のノードは、複数のリーフノードおよび複数の非リーフノードを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロック（例えば、コード化ブロック）に対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において１つまたは複数の子ノードを有する。ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して３つ以上の区分構造（例えば、ＢＴ、ＱＴ、およびＴＴ区分構造）の複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な区分タイプのうちの１つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容区分タイプの各それぞれの許容区分タイプは、それぞれの非リーフノードに対応するビデオブロックをそれぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応し得る。さらに、この例では、ビデオエンコーダ２２は、ビデオデータの符号化表現を備えるビットストリーム中に初期ビデオブロックの符号化表現を含め得る（２０２）。

[0147]図１０Ｂは、本開示の技法に係る、ビデオデコーダ３０の例となる動作を例示するフローチャートである。図１０Ｂの例では、ビデオデコーダ３０は、複数のノードを備えるツリー構造を決定し得る（２５０）。複数のノードは、複数のリーフノードと、複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において１つまたは複数の子ノードを有する。ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して３つ以上の区分構造（例えば、ＢＴ、ＱＴ、およびＴＴ区分構造）の複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な区分タイプのうちの１つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容区分タイプの各それぞれの許容区分タイプは、それぞれの非リーフノードに対応するビデオブロックをそれぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応する。さらに、この例では、ツリー構造の各（または少なくとも１つの）それぞれのリーフノードについて、ビデオデコーダ３０は、それぞれのリーフノードに対応するビデオブロックを再構築する（２５２）。

[0148]図１０Ａおよび図１０Ｂの例では、ルートノード以外のツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対する複数の許容区分タイプは、それに従ってそれぞれの非リーフノードの親ノードに対応するビデオブロックがそれぞれの非リーフノードの親ノードの子ノードに対応するビデオブロックへと区分化される分割パターンから独立しているであろう。例えば、VCEG proposal COM16-C966とは異なり、特定のノードのビデオブロックが二分木分割パターンに従って分割される場合、特定のノードの子ノードのビデオブロックは、四分木分割パターンに従って分割され得る。

[0149]さらに、図１０Ａおよび図１０Ｂの例では、ツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対する複数の許容分割パターンは、正方形四分木分割パターン、長方形四分木分割パターン、対称二分木分割パターン、非対称二分木分割パターン、対称三分木分割パターン、または非対称三分木分割パターンのうちの２つ以上を含み得る。

[0150]さらに、上に示したように、前述した区分タイプのサブセットのみが使用される。サポートされる区分タイプのサブセットは、ビットストリームにおいてシグナリングされるか、あらかじめ定義されているであろう。ゆえに、いくつかの例では、ビデオデコーダ３０は、複数のサポートされる分割パターンを示すシンタックス要素を、ビットストリームから、取得し得る。同様に、ビデオエンコーダ２２は、複数のサポートされる分割パターンを、ビットストリームにおいて、シグナリングし得る。これらの例では、ツリー構造の各それぞれの非リーフノードについて、複数のサポートされる分割パターンは、それぞれの非リーフノードに対する複数の許容分割パターンを含み得る。これらの例では、複数のサポートされる分割パターンを示すシンタックス要素は、例えば、シーケンスパラメータセット（ＳＰＳ）またはピクチャパラメータセット（ＰＰＳ）またはスライスヘッダにおいて、ビットストリームから取得（および、それにおいてシグナリング）され得る。

[0151]上に示したように、いくつかの例では、サブツリーが非対称三分木に分割されるとき、これら３つの区分のうちの２つが同じサイズを有するという制約が適用される。したがって、いくつかの例では、ビデオデコーダ３０は、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードの２つの子ノードに対応するビデオブロックが同じサイズを有することを規定する、制約に適合する初期ビデオブロックの符号化表現を受信し得る。同様に、ビデオエンコーダ２２は、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードの２つの子ノードに対応するビデオブロックが同じサイズを有することを規定する制約に適合するように、初期ビデオブロックの符号化表現を生成し得る。

[0152]上に示したように、いくつかの例では、サポートされる区分タイプの数は、すべてのＣＴＵにおいてすべての深度に対して固定であり得る。例えば、ツリー構造の各非リーフノードに対する複数の許容分割パターン中の許容分割パターンは同じ数であり得る。追加的に、上に示したように、他の例では、サポートされる区分タイプの数は、深度、スライスタイプ、ＣＴＵタイプ、または他の前にコード化された情報に依存し得る。例えば、ツリー構造の少なくとも１つの非リーフノードについて、非リーフノードに対する複数の許容分割パターン中の許容分割パターンの数は、ツリー構造における非リーフノードの深度、ツリー構造における非リーフノードに対応するビデオブロックのサイズ、スライスタイプ、または前にコード化された情報、のうちの少なくとも１つに依存する。

[0153]いくつかの例では、ブロックが非対称区分タイプ（例えば、ＰＡＲＴ＿２ＮｘｎＵ、ＰＡＲＴ ２ＮｘｎＤ、ＰＡＲＴ＿ｎＬｘ２Ｎ、ＰＡＲＴ＿ｎＲｘ２Ｎを含む、図３に示される非対称二分木区分タイプ）で分割されるとき、現在ブロックから分割された最大サブブロックは、これ以上分割されることはできない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、ツリー構造の任意の非リーフノードに対応するビデオブロックが非対称分割パターンに従って複数のサブブロックへと分割されるとき、複数のサブブロックのうちの最大サブブロックがツリー構造のリーフノードに対応することを必要とし得る。

[0154]いくつかの例では、ブロックが非対称区分タイプで分割されるとき、現在ブロックから分割された最大サブブロックは、同じ方向にはこれ以上分割されることができない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、ツリー構造の任意の非リーフノードに対応するビデオブロックが非対称分割パターンに従って複数のサブブロックへと第１の方向に分割されるとき、ツリー構造が、複数のサブブロックのうちの最大サブブロックから第１の方向に分割された複数のサブブロックのうちの最大サブブロックのサブブロックに対応するノードを含むことができないことを必要とし得る。

[0155]いくつかの例では、ブロックの幅／高さが２の累乗ではないとき、これ以上の水平／垂直分割は許容されない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、高さまたは幅が２の累乗ではないビデオブロックに対応するツリー構造のノードがリーフノードであることを必要とし得る。

[0156]いくつかの例では、各深度において、選択された区分タイプのインデックスがビットストリームにおいてシグナリングされる。ゆえに、いくつかの例では、ビデオエンコーダ２２は、それに従ってツリー構造の非リーフノードに対応するビデオブロックが非リーフノードの子ノードに対応するビデオブロックへと分割される分割パターンのインデックスを、ビットストリーム中に、含め得る。同様に、いくつかの例では、ビデオデコーダ３０は、それに従ってツリー構造の非リーフノードに対応するビデオブロックが非リーフノードの子ノードに対応するビデオブロックへと分割される分割パターンのインデックスを、ビットストリームから、取得し得る。

[0157]いくつかの例では、ＣＵ（リーフノード）ごとに、ＣＵと同じサイズを有する変換が行われるか否かを示すために、１ビットのtransform_splitフラグがさらにシグナリングされる。transform_splitフラグが真としてシグナリングされるケースでは、ＣＵの残差は、複数のサブブロックへとさらに分割され、各サブブロックに対して変換が行われる。したがって、一例では、ツリー構造の少なくとも１つのリーフノードについて、ビデオエンコーダ２２は、ビットストリーム中にシンタックス要素を含め得る。この例では、第１の値を有するシンタックス要素は、リーフノードに対応するビデオブロックと同じサイズを有する変換がリーフノードに対応するビデオブロックの残差データに適用されることを示し、第２の値を有するシンタックス要素は、リーフノードに対応するビデオブロックより小さいサイズを有する複数の変換がリーフノードに対応するビデオブロックの残差データのサブブロックに適用されることを示す。同様の例では、ツリー構造の少なくとも１つのリーフノードについて、ビデオデコーダ３０は、ビットストリームからこのシンタックス要素を取得し得る。

[0158]いくつかの例では、いずれの分割フラグもシグナリングされず、１つの導出されたサイズを有する変換のみが、ＣＵに残余があるときに対して使用される。例えば、ツリー構造の少なくとも１つのリーフノードについて、ビデオエンコーダ２２は、残差データをサンプルドメインから変換ドメインに変換するために、リーフノードに対応するビデオブロックに対応する残差データの異なる部分に同じ変換（例えば、離散コサイン変換、離散サイン変換、等）を適用し得る。サンプルドメインでは、残差データは、サンプル（例えば、画素の成分）の値を単位として表される。変換ドメインでは、残差データは、周波数係数を単位として表され得る。同様に、ツリー構造の少なくとも１つのリーフノードについて、ビデオデコーダ３０は、残差データを変換ドメインからサンプルドメインに変換するために、リーフノードに対応するビデオブロックに対応する残差データの異なる部分に同じ変換（すなわち、逆離散コサイン変換、逆サイン変換、等）を適用し得る。

[0159]いくつかの例では、各ＣＵについて、このＣＵが正方形四分木または対称二分木に分割されない場合、変換サイズは、常に、区分サイズのサイズに等しく設定される。例えば、正方形四分木分割パターンまたは対称二分木分割パターンに従って区分化されたビデオブロックに対応するツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードの子ノードに対応するビデオブロックの残差データに適用される変換の変換サイズは、常に、それぞれの非リーフノードの子ノードに対応するビデオブロックのサイズに常に等しく設定される。

[0160]図１１は、本開示の別の例となる技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。予測処理ユニット１００を含む、ビデオエンコーダ２２の１つまたは複数の構造要素は、図１１の技法を実行するように構成され得る。

[0161]本開示の一例では、ビデオエンコーダ２２は、ビデオデータのピクチャを受信すること（３００）と、３つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化すること（３０２）と、ビデオデータのピクチャの複数のブロックを符号化すること（３０４）とを行うように構成され得る。本開示の一例では、ビデオエンコーダ２２は、３つ以上の異なる区分構造を使用して複数のブロックへとビデオデータのピクチャを区分化するように構成され得、ここにおいて、３つ以上の異なる区分構造のうちの少なくとも３つは、ビデオデータのピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る。一例では、３つ以上の異なる区分構造は、三分木区分構造を含み、ビデオエンコーダ２２は、三分木区分構造の三分木区分タイプを使用してビデオデータの特定のブロックを区分化するようにさらに構成され、ここにおいて、三分木区分構造は、特定のブロックの中心を通って特定のブロックを分割することなく特定のブロックを３つのサブブロックへと分割し、３つのサブブロックのうちのセンタブロックは、３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、３つのサブブロックのうちの他の２つのブロックは、同じサイズを有する。

[0162]本開示の別の例では、３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。本開示の別の例では、四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む。

[0163]本開示の別の例では、ビデオエンコーダ２２は、３つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームにおいて、生成するようにさらに構成される。一例では、ビットストリームからシンタックス要素を生成することは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数においてシンタックス要素を生成することを含む。

[0164]本開示の別の例では、ビデオエンコーダ２２は、ビデオデータのピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を生成することと、特定のブロックの２つのサブブロックが同じサイズを有するように、ビデオデータのピクチャの特定のブロックを区分化することとを行うようにさらに構成される。

[0165]本開示の別の例では、複数のブロックは、リーフノードに対応する特定のブロックを含み、ビデオエンコーダ２２は、ビットストリームにおいてシンタックス要素を生成することと、ここで、第１の値を有するシンタックス要素は、リーフノードに対応するビデオデータのピクチャの特定のブロックと同じサイズを有する変換がリーフノードに対応する特定のブロックの残差データに適用されることを示し、第２の値を有するシンタックス要素は、リーフノードに対応する特定のビデオより小さいサイズを有する複数の変換がリーフノードに対応する特定のブロックの残差データのサブブロックに適用されることを示す、シンタックス要素に従って、ビデオデータの特定のブロックの残差データに１つまたは複数の変換を適用することとを行うようにさらに構成される。

[0166]図１２は、本開示の別の例となる技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。エントロピー復号ユニット１５０および／または予測処理ユニット１５２を含む、ビデオデコーダ３０の１つまたは複数の構造要素は、図１２の技法を実行するように構成され得る。

[0167]本開示の一例では、ビデオデコーダ３０は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信すること（４００）と、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定すること（４０２）と、ビデオデータのコード化されたピクチャの複数のブロックを再構築すること（４０４）とを行うように構成される。一例では、ビデオデコーダ３０は、３つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定するように構成され、ここにおいて、３つ以上の異なる区分構造のうちの少なくとも３つは、ビデオデータのコード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る。一例では、３つ以上の異なる区分構造は、三分木区分構造を含み、ビデオデコーダ３０は、三分木区分構造の三分木区分タイプを使用したビデオデータの特定のブロックの区分化を決定するようにさらに構成され、ここにおいて、三分木区分構造は、特定のブロックの中心を通って特定のブロックを分割することなく特定のブロックを３つのサブブロックへと分割し、３つのサブブロックのうちのセンタブロックは、３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、３つのサブブロックのうちの他の２つのブロックは、同じサイズを有する。

[0168]本開示の別の例では、３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。別の例では、四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む。

[0169]本開示の別の例では、ビデオデコーダ３０は、３つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームから、受信することと、受信されたシンタックス要素に基づいて、ビデオデータのコード化されたピクチャの区分化を決定することとを行うようにさらに構成される。本開示の別の例では、ビデオデコーダ３０は、ビットストリームからシンタックス要素を受信するようにさらに構成され、これは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数においてシンタックス要素を受信することを含む。

[0170]本開示の別の例では、ビデオデコーダ３０は、ビデオデータのコード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、特定のブロックの２つのサブブロックが同じサイズを有するようなビデオデータのコード化されたピクチャの特定のブロックの区分化を決定することとを行うようにさらに構成される。

[0171]本開示の別の例では、複数のブロックは、リーフノードに対応する特定のブロックを含み、ビデオデコーダ３０は、ビットストリームからシンタックス要素を受信することと、ここで、第１の値を有するシンタックス要素は、リーフノードに対応するビデオデータのコード化されたピクチャの特定のブロックと同じサイズを有する変換がリーフノードに対応する特定のブロックの残差データに適用されることを示し、第２の値を有するシンタックス要素は、リーフノードに対応する特定のブロックより小さいサイズを有する複数の変換がリーフノードに対応する特定のブロックの残差データのサブブロックに適用されることを示す、シンタックス要素に従って、ビデオデータの特定のブロックに１つまたは複数の変換を適用することとを行うようにさらに構成される。

[0172]本開示の特定の態様は、例示の目的でＨＥＶＣ規格の拡張に関連して説明されている。しかしながら、本開示で説明された技法は、未だ開発されていない他の標準的なまたは所有権を有するビデオコード化プロセスを含む、他のビデオコード化プロセスに有益であり得る。

[0173]本開示で説明したように、ビデオコーダは、ビデオエンコーダまたはビデオデコーダを指し得る。同様に、ビデオコード化ユニットは、ビデオエンコーダまたはビデオデコーダを指し得る。同じく、ビデオコード化は、適用可能な場合、ビデオ符号化またはビデオ復号を指し得る。本開示では、「～に基づいて」という表現は、～のみに基づいて、～に少なくとも部分的に基づいて、または～に何らかの方法で基づいて、を示し得る。本開示は、１つまたは複数のサンプルブロックのサンプルをコード化するために使用される１つまたは複数のサンプルブロックおよびシンタックス構造を指すために「ビデオ単位」または「ビデオブロック」または「ブロック」という用語を使用し得る。例となるタイプのビデオ単位には、ＣＴＵ、ＣＵ、ＰＵ、変換単位（ＴＵ）、マクロブロック、マクロブロック区分、等が含まれ得る。いくつかのコンテキストでは、ＰＵについての考察は、マクロブロックまたはマクロブロック区分についての考察と置き換えられ得る。例となるタイプのビデオブロックには、コード化ツリーブロック、コード化ブロック、およびビデオデータの他のタイプのブロックが含まれ得る。

[0174]例によっては、ここで説明した技法のうちの任意のものの特定の動作（act）またはイベントが、異なる順序で実行されることができ、追加、混合、または完全に省略され得る（例えば、説明したすべての動作またはイベントが本技法の実施に必要なわけではない）ことは認識されるべきである。さらに、特定の例では、動作またはイベントは、連続というよりはむしろ、例えば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、コンカレントに実行され得る。

[0175]１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せでインプリメントされ得る。ソフトウェアでインプリメントされる場合、これらの機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体に記憶されるか、またはコンピュータ可読媒体を通して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの移送を容易にする任意の媒体を含む通信媒体またはデータ記憶媒体のような有体の媒体に対応するコンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は一般に、（１）非一時的である有形のコンピュータ可読記憶媒体または（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法のインプリメンテーションのための命令、コードおよび／またはデータ構造を取り出すために、１つまたは複数のコンピュータまたは１つまたは複数のプロセッサによってアクセス可能な任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。

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

[0177]命令は、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の同等の集積またはディスクリート論理回路のような１つまたは複数のプロセッサによって実行され得る。したがって、ここで使用される場合、「プロセッサ」という用語は、前述の構造またはここで説明された技法のインプリメンテーションに適切な任意の他の構造のうちの任意のものを指し得る。加えて、いくつかの態様では、ここで説明された機能性は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に提供され得るか、複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理素子において十分にインプリメントされ得る。

[0178]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置においてインプリメントされ得る。様々な構成要素、モジュール、またはユニットは、本開示では、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するように説明されているが、必ずしも、異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上で説明したように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられるか、適切なソフトウェアおよび／またはファームウェアと併せて、上で説明したような１つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。

[0179]様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオデータを復号する方法であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を備える、方法。
［Ｃ２］
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記３つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することを備え、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る、
［Ｃ１］に記載の方法。
［Ｃ３］
前記３つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを３つのサブブロックへと分割し、前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
［Ｃ２］に記載の方法。
［Ｃ４］
前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
［Ｃ３］に記載の方法。
［Ｃ５］
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
［Ｃ４］に記載の方法。
［Ｃ６］
前記３つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
をさらに備える、［Ｃ１］に記載の方法。
［Ｃ７］
前記シンタックス要素を受信することは、前記ビットストリームから前記シンタックス要素を受信することを備え、これは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を受信することを含む、
［Ｃ６］に記載の方法。
［Ｃ８］
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの２つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの区分化を決定することと
をさらに備える、［Ｃ１］に記載の方法。
［Ｃ９］
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、
前記ビットストリームからシンタックス要素を受信すること、第１の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第２の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに１つまたは複数の変換を適用することと
をさらに備える、［Ｃ１］に記載の方法。
［Ｃ１０］
ビデオデータを符号化する方法であって、
前記ビデオデータのピクチャを受信することと、
３つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを複数のブロックへと区分化することと、
前記ビデオデータの前記ピクチャの前記複数のブロックを符号化することと
を備える、方法。
［Ｃ１１］
前記ビデオデータの前記ピクチャを区分化することは、前記３つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを前記複数のブロックに区分化することを備え、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記ピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る、
［Ｃ１０］に記載の方法。
［Ｃ１２］
前記３つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用して前記ビデオデータの前記特定のブロックを区分化することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを３つのサブブロックへと分割し、前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
［Ｃ１１］に記載の方法。
［Ｃ１３］
前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
［Ｃ１２］に記載の方法。
［Ｃ１４］
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
［Ｃ１３］に記載の方法。
［Ｃ１５］
前記３つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームにおいて、生成すること
をさらに備える、［Ｃ１０］に記載の方法。
［Ｃ１６］
前記シンタックス要素を生成することは、ビットストリームから前記シンタックス要素を生成することを備え、これは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を生成することを含む、
［Ｃ１５］に記載の方法。
［Ｃ１７］
前記ビデオデータの前記ピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を生成することと、
前記特定のブロックの２つのサブブロックが同じサイズを有するように、前記ビデオデータの前記ピクチャの前記特定のブロックを区分化することと
をさらに備える、［Ｃ１０］に記載の方法。
［Ｃ１８］
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、
ビットストリームにおいてシンタックス要素を生成すること、第１の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記ピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第２の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のビデオより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、前記ビデオデータの前記特定のブロックの前記残差データに１つまたは複数の変換を適用することと
をさらに備える、［Ｃ１０］に記載の方法。
［Ｃ１９］
ビデオデータを復号するように構成された装置であって、
前記ビデオデータを記憶するように構成されたメモリと、
ビデオ復号回路と
を備え、前記ビデオ復号回路は、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を行うように構成される、装置。
［Ｃ２０］
前記ビデオ復号回路は、前記３つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するようにさらに構成され、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る、
［Ｃ１９］に記載の装置。
［Ｃ２１］
前記３つ以上の異なる区分構造は、三分木区分構造を含み、前記ビデオ復号回路は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するようにさらに構成され、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを３つのサブブロックへと分割し、前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
［Ｃ２０］に記載の装置。
［Ｃ２２］
前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
［Ｃ２１］に記載の装置。
［Ｃ２３］
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
［Ｃ２２］に記載の装置。
［Ｃ２４］
前記ビデオ復号回路は、
前記３つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
を行うようにさらに構成される、［Ｃ１９］に記載の装置。
［Ｃ２５］
前記ビデオ復号回路は、前記ビットストリームから前記シンタックス要素を受信するようにさらに構成され、これは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を受信することを含む、
［Ｃ２４］に記載の装置。
［Ｃ２６］
前記ビデオ復号回路は、
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの２つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの前記区分化を決定することと
を行うようにさらに構成される、［Ｃ１９］に記載の装置。
［Ｃ２７］
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記ビデオ復号回路は、
ビットストリームからシンタックス要素を受信することと、ここで、第１の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第２の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに１つまたは複数の変換を適用することと
を行うようにさらに構成される、［Ｃ１９］に記載の装置。
［Ｃ２８］
ビデオデータを復号するように構成された装置であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信するための手段と、
３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定するための手段と、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築するための手段と
を備える装置。
［Ｃ２９］
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための前記手段は、前記３つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための手段を備え、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得る、
［Ｃ２８］に記載の装置。
［Ｃ３０］
前記３つ以上の異なる区分構造は、三分木区分構造を含み、前記装置は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するための手段をさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを３つのサブブロックへと分割し、前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
［Ｃ２９］に記載の装置。

Claims (25)

1. ビデオデータを復号する方法であって、
   前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
   ３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、ここにおいて、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得、前記少なくとも３つの異なる区分構造は、三分木区分構造を含み、前記三分木区分構造は前記ツリー構造の前記少なくとも１つの深度における１つのブロックに対し使用され、四分木区分構造または二分木区分構造が前記少なくとも１つの深度における別の１つのブロックに対し使用され、
   前記三分木区分構造の三分木区分タイプを使用した前記少なくとも１つの深度における前記１つのブロックの前記区分化を決定することと、ここにおいて、前記三分木区分構造は、前記１つのブロックの中心線を通って前記１つのブロックを分割することなく前記１つのブロックを３つのサブブロックへと分割し、
   前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと、
   を備え、
   前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも１つの深度に対する前記少なくとも３つの異なる区分構造に対応する複数のサポートされる区分タイプを示す第１のシンタックス要素に基づき、前記コード化されたピクチャの前記区分化を決定することを備え、
   前記少なくとも１つの深度における前記１つのブロックの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも１つの深度における前記１つのブロックが前記三分木区分構造の前記三分木区分タイプを使用して区分化されることを示す第２のシンタックス要素に基づく、方法。
2. 前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
   請求項１に記載の方法。
3. 前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
   請求項１に記載の方法。
4. 前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
   前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
   前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
   請求項３に記載の方法。
5. 前記第１および第２のシンタックス要素を含むシンタックス要素を、前記ビットストリームから、受信すること、
   をさらに備える、請求項１に記載の方法。
6. 前記シンタックス要素を受信することは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を受信することを含む、
   請求項５に記載の方法。
7. 前記第２のシンタックス要素は、前記少なくとも１つの深度における前記１つのブロックが、対称三分木区分タイプを有する前記三分木区分構造を使用して区分化されることを示し、
   前記１つのブロックの２つのサブブロックが同じサイズを有するように前記１つのブロックの前記区分化が決定される、
   請求項１に記載の方法。
8. 前記複数のブロックは、リーフノードに対応するブロックを含み、前記方法は、
   前記ビットストリームから第３のシンタックス要素を受信すること、第１の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックと同じサイズを有する変換が前記リーフノードに対応する前記ブロックの残差データに適用されることを示し、第２の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記ブロックの前記残差データのサブブロックに適用されることを示す、と、
   前記第３のシンタックス要素に従って、前記リーフノードに対応する前記ブロックに１つまたは複数の変換を適用することと
   をさらに備える、請求項１に記載の方法。
9. ビデオデータを符号化する方法であって、
   前記ビデオデータのピクチャを受信することと、
   ３つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを複数のブロックへと区分化することと、ここにおいて、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記ピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得、前記少なくとも３つの異なる区分構造は、三分木区分構造を含み、前記三分木区分構造は前記ツリー構造の前記少なくとも１つの深度における１つのブロックに対し使用され、四分木区分構造または二分木区分構造が前記少なくとも１つの深度における別の１つのブロックに対し使用され、
   前記三分木区分構造の三分木区分タイプを使用した前記少なくとも１つの深度における前記１つのブロックを区分化することと、ここにおいて、前記三分木区分構造は、前記１つのブロックの中心線を通って前記１つのブロックを分割することなく前記１つのブロックを３つのサブブロックへと分割し、
   前記ビデオデータの前記ピクチャの前記複数のブロックを符号化することと、
   前記少なくとも１つの深度に対する前記少なくとも３つの異なる区分構造に対応する複数のサポートされる区分タイプを示す第１のシンタックス要素と、前記少なくとも１つの深度における前記１つのブロックが、前記三分木区分構造の前記三分木区分タイプを使用して区分化されることを示す第２のシンタックス要素と、を含むシンタックス要素をビットストリームにおいて生成することと、
   を備える、方法。
10. 前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
    請求項９に記載の方法。
11. 前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
    請求項９に記載の方法。
12. 前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
    前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
    前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
    請求項１１に記載の方法。
13. 前記シンタックス要素を生成することは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を生成することを含む、
    請求項９に記載の方法。
14. 前記第２のシンタックス要素は、前記少なくとも１つの深度における前記１つのブロックが、対称三分木区分タイプを有する前記三分木区分構造を使用して区分化されることを示し、
    前記１つのブロックの２つのサブブロックが同じサイズを有するように、前記１つのブロックの区分化が決定される、
    請求項９に記載の方法。
15. 前記複数のブロックは、リーフノードに対応するブロックを含み、前記方法は、
    ビットストリームにおいて第３のシンタックス要素を生成すること、第１の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第２の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記ブロックの前記残差データのサブブロックに適用されることを示す、と、
    前記第３のシンタックス要素に従って、前記リーフノードに対応する前記ブロックの前記残差データに１つまたは複数の変換を適用することと
    をさらに備える、請求項９に記載の方法。
16. ビデオデータを復号するように構成された装置であって、
    前記ビデオデータを記憶するように構成されたメモリと、
    ビデオ復号回路と、
    を備え、前記ビデオ復号回路は、
    前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
    ３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、ここにおいて、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得、前記少なくとも３つの異なる区分構造は、三分木区分構造を含み、前記三分木区分構造は前記ツリー構造の前記少なくとも１つの深度における１つのブロックに対し使用され、四分木区分構造または二分木区分構造が前記少なくとも１つの深度における別の１つのブロックに対し使用され、
    前記三分木区分構造の三分木区分タイプを使用した前記少なくとも１つの深度における前記１つのブロックの前記区分化を決定することと、ここにおいて、前記三分木区分構造は、前記１つのブロックの中心線を通って前記１つのブロックを分割することなく前記１つのブロックを３つのサブブロックへと分割し、
    前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと、
    を行うように構成され、
    前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも１つの深度に対する前記少なくとも３つの異なる区分構造に対応する複数のサポートされる区分タイプを示す第１のシンタックス要素に基づき、前記コード化されたピクチャの前記区分化を決定することを備え、
    前記少なくとも１つの深度における前記１つのブロックの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも１つの深度における前記１つのブロックが前記三分木区分構造の前記三分木区分タイプを使用して区分化されることを示す第２のシンタックス要素に基づく、装置。
17. 前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
    請求項１６に記載の装置。
18. 前記３つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
    請求項１６に記載の装置。
19. 前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの１つまたは複数を含み、
    前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの１つまたは複数を含み、
    前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの１つまたは複数を含む、
    請求項１８に記載の装置。
20. 前記ビデオ復号回路は、
    前記第１及び第２のシンタックス要素を含むシンタックス要素を、前記ビットストリームから、受信すること、
    を行うようにさらに構成される、請求項１６に記載の装置。
21. 前記ビットストリームから前記シンタックス要素を受信することは、適応型パラメータセット（ＡＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはスライスヘッダのうちの１つまたは複数において前記シンタックス要素を受信することを含む、
    請求項２０に記載の装置。
22. 前記第２のシンタックス要素は、前記少なくとも１つの深度における前記１つのブロックが、対称三分木区分タイプを有する前記三分木区分構造を使用して区分化されることを示し、
    前記１つのブロックの２つのサブブロックが同じサイズを有するように前記１つのブロックの前記区分化が決定される、
    請求項１６に記載の装置。
23. 前記複数のブロックは、リーフノードに対応するブロックを含み、前記ビデオ復号回路は、
    前記ビットストリームから第３のシンタックス要素を受信すること、第１の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックと同じサイズを有する変換が前記リーフノードに対応する前記ブロックの残差データに適用されることを示し、第２の値を有する前記第３のシンタックス要素は、前記リーフノードに対応する前記ブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記ブロックの前記残差データのサブブロックに適用されることを示す、と、
    前記第３のシンタックス要素に従って、前記リーフノードに対応する前記ブロックに１つまたは複数の変換を適用することと
    を行うようにさらに構成される、請求項１６に記載の装置。
24. ビデオデータを復号するように構成された装置であって、
    前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信するための手段と、
    ３つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定するための手段と、ここにおいて、前記３つ以上の異なる区分構造のうちの少なくとも３つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも１つの深度に対して使用され得、前記少なくとも３つの異なる区分構造は、三分木区分構造を含み、前記三分木区分構造は前記ツリー構造の前記少なくとも１つの深度における１つのブロックに対し使用され、四分木区分構造または二分木区分構造が前記少なくとも１つの深度における別の１つのブロックに対し使用され、
    前記三分木区分構造の三分木区分タイプを使用した前記少なくとも１つの深度における前記１つのブロックの区分化を決定するための手段と、ここにおいて、前記三分木区分構造は、前記１つのブロックの中心線を通って前記１つのブロックを分割することなく前記１つのブロックを３つのサブブロックへと分割し、
    前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築するための手段と、
    を備え、
    前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための手段は、前記ビットストリームから受信される、前記少なくとも１つの深度に対する前記少なくとも３つの異なる区分構造に対応する複数のサポートされる区分タイプを示す第１のシンタックス要素に基づき、前記コード化されたピクチャの前記区分化を決定するための手段を備え、
    前記少なくとも１つの深度における前記１つのブロックの前記区分化を決定するための手段は、前記ビットストリームから受信される、前記少なくとも１つの深度における前記１つのブロックが前記三分木区分構造の前記三分木区分タイプを使用して区分化されることを示す第２のシンタックス要素に基づき、前記１つのブロックの前記区分化を決定するための手段を備える、装置。
25. 前記３つのサブブロックのうちのセンタブロックは、前記３つのサブブロックのうちの他の２つのブロックのサイズの合計に等しいサイズを有し、前記３つのサブブロックのうちの前記他の２つのブロックは、同じサイズを有する、
    請求項２４に記載の装置。

Images