特許 7485803 ルマおよびクロマブロックパーティショニング

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

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

(11)【特許番号】

(24)【登録日】2024-05-08

(45)【発行日】2024-05-16

(54)【発明の名称】ルマおよびクロマブロックパーティショニング

(51)【国際特許分類】

   H04N 19/119 20140101AFI20240509BHJP

   H04N 19/136 20140101ALI20240509BHJP

   H04N 19/176 20140101ALI20240509BHJP

   H04N 19/186 20140101ALI20240509BHJP

【ＦＩ】

H04N19/119

H04N19/136

H04N19/176

H04N19/186

【請求項の数】 14

【外国語出願】

(21)【出願番号】P 2023009973

(22)【出願日】2023-01-26

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

【原出願日】2019-03-05

(65)【公開番号】P2023052640

(43)【公開日】2023-04-11

【審査請求日】2023-02-07

(31)【優先権主張番号】62/660,121

(32)【優先日】2018-04-19

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

(31)【優先権主張番号】62/732,675

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

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

(73)【特許権者】

【識別番号】503433420

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

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

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャオ，イン

(72)【発明者】

【氏名】ヤーン，ハイタオ

(72)【発明者】

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

(72)【発明者】

【氏名】フゥ，ジアリー

【審査官】岩井 健二

(56)【参考文献】

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

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

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

【文献】Sri Nitchith Akula, et al.，Description of SDR, HDR and 360° video coding technology proposal considering mobile application scenario by Samsung, Huawei, GoPro, and HiSilicon，Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-J0024_v2，10th Meeting: San Diego, US，2018年04月，pp.36-40

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

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

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

【請求項1】

ビデオ符号化方法であって、前記方法は、
ビデオフレームをスライスにパーティションするステップと、
前記スライスのうちの少なくとも1つのスライスを符号化木単位にパーティションするステップであって、前記符号化木単位のうちの各符号化木単位は、ルマサンプルとクロマサンプルを含む、ステップと、
前記符号化木単位のうちの現在符号化木単位がイントラ予測（I）スライスの中にあるかどうかを決定するステップであって、現在符号化木単位は第1符号化木ノードと第2符号化木ノードを含む、ステップと、
前記現在符号化木単位が前記Iスライスの中にあると決定すると、
前記第1符号化木ノードのサイズが閾値を超えるとき、前記現在符号化木単位の前記第1符号化木ノードの中のルマサンプルとクロマサンプルを共通符号化木によりパーティションするステップと、
前記第2符号化木ノードのサイズが前記閾値以下であるとき、前記現在符号化木単位の前記第2符号化木ノードの中のルマサンプルを、ルマ符号化部分木によりパーティションするステップと、
前記第2符号化木ノードのサイズが前記閾値以下であるとき、前記現在符号化木単位の前記第2符号化木ノードの中のクロマサンプルを、クロマ符号化部分木によりパーティションするステップと、
前記現在符号化木単位のパーティション情報をビットストリームに符号化するステップと、
を含む方法。

【請求項2】

前記閾値は、4096ピクセル、又は2を基数とする対数領域の6である、請求項1に記載の方法。

【請求項3】

前記現在符号化木単位は、イントラ予測（I）ピクチャ／フレーム内にある、請求項1～2のいずれかに記載の方法。

【請求項4】

前記現在符号化木単位の前記クロマサンプルは青色差分クロマ(Cb)サンプル及び赤色差分クロマ(Cr)サンプルを含み、前記Cbサンプル及びCrサンプルは、共通クロマ符号化部分木によりパーティションされる、請求項1～3のいずれかに記載の方法。

【請求項5】

前記方法は、
前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示すluma_chroma_separateフラグをビットストリーム内に符号化するステップ、
を更に含む請求項1～4のいずれかに記載の方法。

【請求項6】

前記方法は、
前記ビットストリームを送信するステップ、
を更に含む請求項1～5のいずれかに記載の方法。

【請求項7】

エンコーダであって、
1つ以上のプロセッサと、
前記プロセッサによる実行のための命令を格納するメモリと、
を含み、前記命令は、前記プロセッサにより実行されると、前記エンコーダに、
ビデオフレームをスライスにパーティションするステップと、
前記スライスのうちの少なくとも1つのスライスを符号化木単位にパーティションするステップであって、前記符号化木単位のうちの各符号化木単位は、ルマサンプルとクロマサンプルを含む、ステップと、
前記符号化木単位のうちの現在符号化木単位がイントラ予測（I）スライスの中にあるかどうかを決定するステップであって、現在符号化木単位は第1符号化木ノードと第2符号化木ノードを含む、ステップと、
前記現在符号化木単位が前記Iスライスの中にあると決定すると、
前記第1符号化木ノードのサイズが閾値を超えるとき、前記現在符号化木単位の前記第1符号化木ノードの中のルマサンプルとクロマサンプルを共通符号化木によりパーティションするステップと、
前記第2符号化木ノードのサイズが前記閾値以下であるとき、前記現在符号化木単位の前記第2符号化木ノードの中のルマサンプルを、ルマ符号化部分木によりパーティションするステップと、
前記第2符号化木ノードのサイズが前記閾値以下であるとき、前記現在符号化木単位の前記第2符号化木ノードの中のクロマサンプルを、クロマ符号化部分木によりパーティションするステップと、
前記現在符号化木単位のパーティション情報をビットストリームに符号化するステップと、
を実行させる、エンコーダ。

【請求項8】

前記エンコーダは、
デコーダへ向けて前記ビットストリームを送信するよう構成される送信機、
を更に含む請求項7に記載のエンコーダ。

【請求項9】

前記閾値は、4096ピクセル、又は2を基数とする対数領域の6である、請求項7又は8に記載のエンコーダ。

【請求項10】

前記現在符号化木単位は、イントラ予測（Ｉ）ピクチャ／フレーム内にある、請求項7～9のいずれかに記載のエンコーダ。

【請求項11】

前記現在符号化木単位の前記クロマサンプルは青色差分クロマ(Cb)サンプル及び赤色差分クロマ(Cr)サンプルを含み、前記Cbサンプル及びCrサンプルは、共通クロマ符号化部分木によりパーティションされる、請求項7～10のいずれかに記載のエンコーダ。

【請求項12】

前記命令は、前記プロセッサにより実行されると、前記エンコーダに、
前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示すluma_chroma_separateフラグを前記ビットストリーム内に符号化するステップ、
を更に実行させる、請求項7～11のいずれかに記載のエンコーダ。

【請求項13】

請求項1～6のいずれか一項に記載の方法を実行する回路を含むエンコーダ。

【請求項14】

ビットストリームの形式でビデオデータを格納する装置であって、
前記ビットストリームを格納する記憶媒体であって、前記ビットストリームは、請求項1～6のいずれかに記載の方法を実行することにより得られる、記憶媒体と、
ソース装置から前記ビットストリームを受信するよう、及び／又は前記ビットストリームに含まれるパーティション情報に基づき前記ビットストリームを復号させるために宛先装置に向けて前記ビットストリームを送信するよう構成される通信インタフェースと、
を含む装置。

【発明の詳細な説明】

【技術分野】

【0001】

［技術分野］
本開示は、概して、ビデオ符号化に関し、具体的には、ビデオ符号化におけるルマおよびクロマ符号化ブロックのパーティショニングのための符号化木の生成に関する。

【背景技術】

【0002】

比較的短いビデオでも描写するために必要なビデオデータの量は相当なものになり得る。これは、データが限られた帯域幅能力を有する通信ネットワークに渡りストリーミングされるまたは通信されるとき、困難をもたらすことがある。したがって、ビデオデータは、通常、今日の通信ネットワークに渡り通信される前に、圧縮される。ビデオが記憶装置に格納されるとき、メモリリソースが限られていることがあるので、ビデオのサイズも問題になり得る。ビデオ圧縮装置は、送信または記憶の前に、ソースにおいてビデオデータを符号化するためにソフトウェアおよび／またはハードウェアを度々使用し、それによりデジタルビデオ画像を表現するために必要なデータの量を削減する。圧縮されたデータは、次に、ビデオデータを復号するビデオ復元装置により宛先において受信される。限られたネットワークリソースおよびより高いビデオ品質の増え続ける要求に伴い、画像品質を僅かしかまたは全く犠牲にせずに圧縮率を向上する改良された圧縮および復元技術が望ましい。

【発明の概要】

【0003】

一実施形態では、本開示は、ビデオ符号化装置に実装される方法を含む。前記方法は、前記ビデオ符号化装置のプロセッサにより、符号化木ノードを含む符号化木単位を取得するステップを含む。前記方法は、前記プロセッサにより、第1符号化木ノードのサイズが閾値を超えるとき、共通符号化木に従い、前記符号化木単位の第1符号化木ノードの中のルマサンプルおよびクロマサンプルをパーティショニングするステップを更に含む。前記方法は、前記プロセッサにより、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の第2符号化木ノードの中の前記ルマサンプルをルマ符号化部分木によりパーティショニングするステップを更に含む。前記方法は、前記プロセッサにより、第2符号化木ノードの前記サイズが前記閾値以下であるとき前記符号化木単位の前記第2符号化木ノードの中の前記クロマサンプルをクロマ符号化部分木によりパーティショニングするステップを更に含む。本実施形態では、より大きな(例えば、閾値より大きい)ブロックでは、同じ符号化木がルマおよびクロマサンプルの両方に使用され、一方で、より小さな(例えば、前記閾値以下の)ブロックでは、異なる符号化木(例えば、部分木)に分割する。別個の木は、ルマおよびクロマサンプルについて、異なるパーティショニングを可能にし、したがって、全体の符号化効率を向上するために調整できる。しかしながら、単一の木の代わりに別個の木を使用することは、より多くの処理リソースを要し、最終的な符号化においてより多くのメモリ空間の使用をもたらす。共通符号化木を、閾値より小さい異なる部分木に分割することは、ルマブロックからの全体木をクロマブロックの大部分のために再利用させることができ(例えば、複雑性およびメモリ使用を低減する)、一方で、より小さなルマおよびクロマブロックに部分木を調整する(例えば、符号化効率を向上する)。

【0004】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記閾値は、4096ピクセル、または2を基数とする対数領域の6であることを提供する。

【0005】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記符号化木単位がイントラ予測(I)フレームであることを提供する。

【0006】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、クロマサンプルは青色差分クロマ(Cb)サンプルおよび赤色差分クロマ(Cr)サンプルを含み、前記CbサンプルおよびCrサンプルは、共通クロマ符号化部分木によりパーティショニングされることを提供する。

【0007】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記ビデオ符号化装置がエンコーダであることを提供する。前記方法は、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示すluma_chroma_separateフラグをビットストリーム内に符号化するステップ、を更に含む。前記luma_chroma_separateフラグは、異なるルマおよびクロマ符号化部分木が使用されることを前記デコーダに示すメカニズムを提供する。

【0008】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記ビデオ符号化装置がデコーダであることを提供する。前記方法は、ビットストリームからluma_chroma_separateフラグを受信するステップを更に含む。前記luma_chroma_separateフラグは、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示す。前記ルマサンプルおよびクロマサンプルは、前記luma_chroma_separateフラグの値に基づき、別個の符号化部分木によりパーティショニングされる。前記luma_chroma_separateフラグは、異なるルマおよびクロマ符号化部分木が使用されることを前記デコーダに示すメカニズムを提供する。

【0009】

一実施形態では、本開示は、符号化木ノードを含む符号化木単位を取得するよう構成されるプロセッサを含むビデオエンコーダを含む。前記プロセッサは、第1符号化木ノードのサイズが閾値を超えるとき、共通符号化木に従い、前記符号化木単位の前記第1符号化木ノードの中の前記ルマサンプルおよび前記クロマサンプルをパーティショニングするよう更に構成される。前記プロセッサは、第2符号化木ノードのサイズが閾値以下であるとき、前記符号化木単位の前記第2符号化木ノードの中の前記ルマサンプルをルマ符号化部分木によりパーティショニングするよう更に構成される。前記プロセッサは、第2符号化木ノードの前記サイズが前記閾値以下であるとき、前記符号化木単位の前記第2符号化木ノードの中の前記クロマサンプルをクロマ符号化部分木によりパーティショニングするよう更に構成される。前記プロセッサは、前記共通符号化木、前記ルマ符号化部分木、および前記クロマ符号化部分木に基づき、前記クロマサンプルおよび前記ルマサンプルをビットストリームに符号化するよう更に構成される。前記ビデオエンコーダは、前記プロセッサに結合される送信機を更に含む。前記送信機は、ビデオデコーダによる表示のために前記クロマサンプルおよび前記ルマサンプルの再構成をサポートするために、前記ビットストリームを送信するよう構成される。本実施形態では、より大きな(例えば、閾値より大きい)ブロックでは、同じ符号化木がルマおよびクロマサンプルの両方に使用され、一方で、より小さな(例えば、前記閾値以下の)ブロックでは、異なる符号化木(例えば、部分木)に分割する。別個の木は、ルマおよびクロマサンプルについて、異なるパーティショニングを可能にし、したがって、全体の符号化効率を向上するために調整できる。しかしながら、単一の木の代わりに別個の木を使用することは、より多くの処理リソースを要し、最終的な符号化においてより多くのメモリ空間の使用をもたらす。共通符号化木を、閾値より小さい異なる部分木に分割することは、ルマからの全体木をクロマの大部分のために再利用させることができ(例えば、複雑性およびメモリ使用を低減する)、一方で、より小さなルマおよびクロマブロックに部分木を調整する(例えば、符号化効率を向上する)。

【0010】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記閾値は、4096ピクセル、または2を基数とする対数領域の6であることを提供する。

【0011】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記符号化木単位がIフレーム内にあることを提供する。

【0012】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、クロマサンプルはCbサンプルおよびCrサンプルを含み、前記CbサンプルおよびCrサンプルは、共通クロマ符号化部分木によりパーティショニングされることを提供する。

【0013】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記プロセッサは、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示すために、luma_chroma_separateフラグを前記ビットストリームに符号化するよう更に構成されることを提供する。前記luma_chroma_separateフラグは、異なるルマおよびクロマ符号化部分木が使用されることを前記デコーダに示すメカニズムを提供する。

【0014】

一実施形態では、本開示は、ルマデータおよびクロマデータを含む符号化木単位を含むビットストリームを受信する受信機を含むビデオデコーダを含む。前記ビデオデコーダは、前記受信機に結合されるプロセッサを更に含む。前記プロセッサは、第1符号化木ノードのサイズが閾値を超えるとき、前記ルマデータおよび前記クロマデータを共通符号化木によりパーティショニングするよう構成される。前記プロセッサは、第2符号化木ノードのサイズが前記閾値以下であるとき、ルマ符号化部分木により前記ルマデータをパーティショニングするよう更に構成される。前記プロセッサは、第3符号化木ノードのサイズが前記閾値以下であるとき、クロマ符号化部分木により前記クロマデータをパーティショニングするよう更に構成され、前記ルマ符号化部分木は、前記クロマ符号化部分木と異なる分割モードのセットを含む。前記プロセッサは、前記共通符号化木、前記ルマ符号化部分木、および前記クロマ符号化部分木に基づき、前記クロマデータおよび前記ルマデータをビデオフレームのスライスへと再構成するよう更に構成される。前記プロセッサは、前記ビデオフレームをディスプレイへ向けて転送するよう更に構成される。本実施形態では、より大きな(例えば、閾値より大きい)ブロックでは、同じ符号化木がルマおよびクロマサンプルの両方に使用され、一方で、より小さな(例えば、前記閾値以下の)ブロックでは、異なる符号化木(例えば、部分木)に分割する。別個の木は、ルマおよびクロマサンプルについて、異なるパーティショニングを可能にし、したがって、全体の符号化効率を向上するために調整できる。しかしながら、単一の木の代わりに別個の木を使用することは、より多くの処理リソースを要し、最終的な符号化においてより多くのメモリ空間の使用をもたらす。共通符号化木を、閾値より小さい異なる部分木に分割することは、ルマからの全体木をクロマの大部分のために再利用させることができ(例えば、複雑性およびメモリ使用を低減する)、一方で、より小さなルマおよびクロマブロックに部分木を調整する(例えば、符号化効率を向上する)。

【0015】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記閾値は、4096ピクセル、または2を基数とする対数領域の6であることを提供する。

【0016】

任意で、上述の態様のいずれかにおいて、本態様の別の実装では、ルマデータおよびクロマデータは、前記符号化木単位がビデオフレーム内のIタイプスライスに含まれるとき、異なる符号化部分木によりパーティショニングされることを提供する。

【0017】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、クロマデータはCbデータおよびCrデータを含み、前記CbデータおよびCrデータは、共通クロマ符号化部分木によりパーティショニングされることを提供する。

【0018】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記プロセッサは、luma_chroma_separateフラグを前記ビットストリームから取得するよう更に構成され、前記luma_chroma_separateフラグは、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示し、前記ルマデータおよびクロマデータは、前記luma_chroma_separateフラグの値に基づき異なる符号化部分木によりパーティショニングされることを提供する。前記luma_chroma_separateフラグは、異なるルマおよびクロマ符号化部分木が使用されることを前記デコーダに示すメカニズムを提供する。

【0019】

一実施形態では、本開示は、ビデオ符号化装置による使用のためのコンピュータプログラムプロダクトを含む非一時的コンピュータ可読媒体であって、前記コンピュータプログラムプロダクトは、プロセッサにより実行されると前記ビデオデコーダに前述の態様のいずれかの方法を実行させる、前記非一時的コンピュータ可読媒体に記憶されたコンピュータ実行可能命令を含む、非一時的コンピュータ可読媒体を含む。

【0020】

一実施形態では、本開示は、符号化木ノードを含む符号化木単位を取得するフェッチ手段を含むビデオ符号化装置を含む。前記ビデオ符号化装置は、第1符号化木ノードのサイズが閾値を超えるとき、共通符号化木に従い、前記符号化木単位の前記第1符号化木ノードの中のルマサンプルおよびクロマサンプルをパーティショニングする共通木パーティショニング手段を更に含む。前記ビデオ符号化装置は、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の前記第2符号化木ノードの中のルマサンプルをルマ符号化部分木によりパーティショニングするルマ符号化部分木パーティショニング手段を更に含む。前記ビデオ符号化装置は、第2符号化木ノードの前記サイズが前記閾値以下であるとき前記符号化木単位の前記第2符号化木ノードの中の前記クロマサンプルをクロマ符号化部分木によりパーティショニングするクロマ符号化部分木パーティショニング手段を更に含む。本実施形態では、より大きな(例えば、閾値より大きい)ブロックでは、同じ符号化木がルマおよびクロマサンプルの両方に使用され、一方で、より小さな(例えば、前記閾値以下の)ブロックでは、異なる符号化木(例えば、部分木)に分割する。別個の木は、ルマおよびクロマサンプルについて、異なるパーティショニングを可能にし、したがって、全体の符号化効率を向上するために調整できる。しかしながら、単一の木の代わりに別個の木を使用することは、より多くの処理リソースを要し、最終的な符号化においてより多くのメモリ空間の使用をもたらす。共通符号化木を、閾値より小さい異なる部分木に分割することは、ルマからの全体木をクロマの大部分のために再利用させることができ(例えば、複雑性およびメモリ使用を低減する)、一方で、より小さなルマおよびクロマブロックに部分木を調整する(例えば、符号化効率を向上する)。

【0021】

任意で、前述の態様のいずれかにおいて、本態様の別の実装は、前記フェッチ手段、前記共通木パーティショニング手段、前記ルマ部分木パーティショニング手段、および前記クロマ部分木パーティショニング手段は、さらに前述の態様のいずれかの方法を実行するためのものであることを提供する。

【0022】

一実施形態では、本開示は、符号化木単位がIフレーム内にあることを決定するステップを含む方法を含む。前記符号化木単位に対応する符号化木の第1符号化木ノードが閾値より大きいサイズを有するとき、前記第1符号化木ノードに関連するルマサンプルの符号化ブロックおよびクロマサンプルの符号化ブロックを、共通符号化木により分割する。前記符号化木の第2符号化木ノードが前記閾値以下のサイズを有するとき、前記第2符号化木ノードに関連するルマサンプルの符号化ブロックをルマ符号化木により分割し、および前記第2符号化木ノードに関連するクロマサンプルの符号化ブロックをクロマ符号化木により分割する。

【0023】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記閾値が4096ルマサンプルまたは2048ルマサンプルであることを提供する。

【0024】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記共通符号化木が4分木分割であることを提供する。

【0025】

任意で、前述の態様のいずれかにおいて、本態様の別の実装は、前記第1符号化木ノードの分割モードは、前記符号化木ノードが閾値より大きいサイズを有するとき暗に示されることを提供する。

【0026】

任意で、上述の態様のいずれかにおいて、本態様の別の実装は、前記サイズがlog2CbSizeにより表され、前記閾値が6に等しいことを提供する。

【0027】

一実施形態では、本開示は、前述の態様のいずれかを実行するよう構成されるプロセッサを含むビデオ符号化装置を含む。

【0028】

明確さを目的として、前述の実施形態のうちのいずれか1つは、他の前述の実施形態のうちの任意の1つ以上と結合されて、本開示の範囲内にある新しい実施形態を生成してよい。

【0029】

これら、および他の特徴は、添付の図面および請求の範囲と関連して取り入れられる以下の詳細な説明から一層明確に理解されるだろう。

【図面の簡単な説明】

【0030】

本開示のより完全な理解のために、ここで、添付の図面および詳細な説明と関連して以下の簡単な説明を参照する。ここで同様の参照符号は同様の部分を表す。

【0031】

【図1】ビデオ信号を符号化する例示的な方法のフローチャートである。

【0032】

【図2】ビデオ符号化のための例示的な符号化および復号(コーデック)システムの概略図である。

【0033】

【図3】ルマおよびクロマブロックをパーティショニングし得る例示的なビデオエンコーダを示す概略図である。

【0034】

【図4】ルマおよびクロマブロックをパーティショニングし得る例示的なビデオデコーダを示す概略図である。

【0035】

【図5】ルマ符号化ブロック(coding block(CB))およびクロマCBを含む符号化単位(coding unit(CU))に、符号化木単位(coding tree unit(CTU))をパーティショニングする例示的なメカニズムを示す概略図である。

【0036】

【図6】CTUに適用されるような例示的な符号化木を示す。

【0037】

【図7】符号化木において利用される例示的な分割モードセットを示す概略図である。

【0038】

【図8】閾値サイズより上のCBについて共通符号化木により、閾値サイズ以下のCBについて分割部分木により、CTUをパーティショニングする例示的な方法のフローチャートである。

【0039】

【図9】例示的なビデオ符号化装置の概略図である。

【0040】

【図10】閾値サイズより上のCBについて共通符号化木により、閾値サイズ以下のサイズを有するCBについて分割部分木により、CTUをパーティショニングする例示的なシステムの概略図である。

【0041】

【図11】閾値サイズより上のCBについて共通符号化木により、閾値サイズ以下のCBについて分割部分木により、CTUをパーティショニングする例示的な方法のフローチャートである。

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

【0042】

初めに理解されるべきことに、1つ以上の実施形態の説明的実装が以下に提供されるが、開示のシステムおよび／または方法は、現在知られているかまたは既存かに関わらず、任意の数の技術を用いて実装されてよい。本開示は、ここに図示され説明される例示的な設計および実装を含む以下に説明する説明的実装、図面、および技術に決して限定されるべきではないが、添付の請求の範囲の範囲内で、それらの均等物の全範囲と共に、変更されてよい。

【0043】

ビデオ符号化は、ビデオフレームのブロックへのパーティショニング、およびビデオファイルのサイズを圧縮するためのイントラ予測およびインター予測によるブロックの符号化を含む。本開示は、パーティショニング処理の向上に関連する。ビデオフレームは、先ず、符号化木単位(coding tree unit(CTU))にパーティショニングされる。CTUは、ルマサンプル(例えば、明るい値と暗い値)およびクロマ値(例えば、色)として表現されるピクセルデータを含む。CTUは、符号化ブロック(coding block(CB))を生成するために、1つ以上の符号化木によりパーティショニングされる。符号化ブロックは次に符号化され得る(例えば、エンコーダにおいて符号化されるとき、またはデコーダにおいて復号されるとき)。幾つかのシステムでは、ルマおよびクロマサンプルの両方をパーティショニングするために、単一の符号化木が利用される。このようなシステムに伴う問題は、CTU内のルマサンプルおよびCTU内のクロマサンプルが有意に異なるパターンを含み得ることである。したがって、ルマ成分の効率的符号化をサポートする符号化木は、クロマ成分の非効率な符号化をもたらすことがあり、逆も同様である。したがって、このようなシステムは、準最適な符号化効率(例えば、低下した圧縮、およびより大きなファイルサイズ)により圧縮ビデオファイルを生成することがある。

【0044】

代替のシステムでは、ルマサンプルおよびクロマサンプルのために異なる符号化木が使用される。このようなシステムは、ブロック符号化の向上した符号化効率をもたらす。しかしながら、CTU毎に別個のルマ符号化木およびクロマ符号化木を決定することは、符号化処理の複雑性を有意に増大する。例えば、このようなアプローチは、2倍の数の符号化木が選択されるので、符号化のパーティショニング部分の間に利用される処理リソースの量を倍増させ得る。さらに、選択された符号化木は、パーティションデータとしてビットストリームに符号化される。したがって、CTU毎に別個のルマ符号化木およびクロマ符号化木を利用することは、符号化の際に格納されるパーティションデータの量を増加させ得る(例えば、符号化される木の数を倍増する)。これは、ブロック符号化により得られる符号化効率の一部を相殺する。

【0045】

CTUパーティショニングを向上するメカニズムが、ここに開示される。対応するCBが所定の閾値(例えば、4096ピクセル)より大きい限り、ルマサンプルおよびクロマサンプルの両方を符号化するために共通符号化木が使用される。閾値サイズ以下であるルマCBおよびクロマCBは、それぞれ、ルマ符号化部分木およびクロマ符号化部分木によりパーティショニングされる。ルマ符号化部分木およびクロマ符号化部分木は異なり得る。したがって、部分木は、ルマサンプルとクロマサンプルとの間の変動に基づき符号化効率を向上するよう選択できる。さらに、分割ルマ符号化部分木およびクロマ符号化部分木を有する共通符号化木は、2つの完全に別個の符号化木より少ないデータを利用する。したがって、分割部分木を有する符号化木は、別個の符号化木に渡り符号化効率を向上する。さらに、分割部分木を有する符号化木を選択することは、2つの別個の符号化木を選択するより複雑性が少なく、したがって、より少ない処理リソースしか利用しない。例えば、分割部分木を有する符号化木を選択する処理は、CTUについて符号化木のペアを選択する処理よりも迅速に生じ得る。ここに開示される分割部分木メカニズムは、ビデオフレームの中のイントラ予測(I)スライス(例えば、Iタイプのスライス)に適用されてよい。分割部分木メカニズムは、予測(P)および双方向予測(B)スライス(例えば、それぞれPタイプおよびBタイプにおけるスライス)にも適用されてよい。一例では、分割部分木メカニズムは、推測でき、したがって(例えばIスライスで)一般的に利用できる。別の例では、分割部分木が対応するCTUについて利用されるか否かを示すために、luma_chroma_separateフラグが、ビットストリームの中のCTU関連シンタックス内に設定できる。したがって、ここに記載される分割部分木メカニズムは、符号化のためにCTUをパーティショニングするときにエンコーダにより、および復号のためにCTUをパーティショニングするときに対応するデコーダにより、利用できる。

【0046】

図1は、ビデオ信号の符号化の例示的な動作方法100のフローチャートである。具体的に、ビデオ信号はエンコーダで符号化される。符号化処理は、ビデオファイルサイズを削減するために、種々のメカニズムを利用することにより、ビデオ信号を圧縮する。小さなファイルサイズほど、関連する帯域幅オーバヘッドを削減しながら、ユーザに向けて圧縮されたビデオファイルを送信することを可能にする。デコーダは、次に、エンドユーザに表示するために、圧縮されたビデオファイルを復号して元のビデオ信号を再構成する。復号処理は、通常、符号化処理のミラーであり、デコーダがビデオ信号を矛盾無く再構成することを可能にする。

【0047】

ステップ101で、ビデオ信号はエンコーダに入力される。例えば、ビデオ信号は、メモリに格納された非圧縮ビデオファイルであってよい。別の例として、ビデオファイルは、ビデオカメラのようなビデオキャプチャ装置によりキャプチャされ、ビデオのライブストリーミングをサポートするために符号化されてよい。ビデオファイルは、オーディオコンポーネントおよびビデオコンポーネントの両方を含んでよい。ビデオコンポーネントは、シーケンスの中で閲覧されるとき、動きの視覚的印象を与える一連の画像フレームを含む。フレームは、ここではルマ成分(またはルマサンプル)と呼ばれる光、およびクロマ成分(またはクロマサンプル)と呼ばれる色、の観点で表現されるピクセルを含む。幾つかの例では、フレームは、3次元表示をサポートするために、深さ値も含んでよい。

【0048】

ステップ103で、ビデオはブロックにパーティショニングされる。パーティショニングは、圧縮のために、各フレーム内のピクセルを正方形および／または長方形ブロックに細分化することを含む。例えば、高効率ビデオ符号化(High Efficiency Video Coding(HEVC))(H.265およびMPEG－H Part2としても知られる)では、フレームは、先ず、所定のサイズ(例えば、64ピクセル×64ピクセル)のブロックである符号化木単位(coding tree unit(CTU))に分割できる。CTUは、ルマおよびクロマサンプルの両方を含む。符号化木は、CTUをブロックに分割し、次に、更なる符号化をサポートする構成が達成されるまで、ブロックを繰り返し細分化するために利用されてよい。例えば、フレームのルマ成分は、個々のブロックが比較的同種の光の値を含むまで、細分化されてよい。さらに、フレームのクロマ成分は、個々のブロックが比較的同種の色の値を含むまで、細分化されてよい。したがって、パーティショニングメカニズムは、ビデオフレームの内容に依存して変化する。

【0049】

ステップ105で、ステップ103でパーティショニングされた画像ブロックを圧縮するために、種々の圧縮メカニズムが利用される。例えば、インター予測および／またはイントラ予測が利用されてよい。インター予測は、共通のシーンの中のオブジェクトは連続フレームで現れる傾向があるという事実を利用するよう設計される。したがって、参照フレーム内のオブジェクトを描写するブロックは、隣接フレーム内で繰り返し示される必要がない。具体的には、テーブルのようなオブジェクトは、複数のフレームに渡り、一定の位置に留まってよい。したがって、テーブルは一度示され、隣接フレームは参照フレームに戻り参照できる。複数のフレームに渡りオブジェクトを一致させるために、パターンマッチングメカニズムが利用されてよい。さらに、例えばオブジェクトの動きまたはカメラの動きにより、動くオブジェクトが複数のフレームに渡り表示されてよい。特定の例として、ビデオは、複数のフレームに渡りスクリーンを横切って移動する自動車を示してよい。このような動きを示すために、動きベクトルが利用できる。動きベクトルは、フレーム内のオブジェクトの座標から参照フレーム内の該オブジェクトの座標へのオフセットを提供する2次元ベクトルである。したがって、インター予測は、現在フレーム内の画像ブロックを、参照フレーム内の対応するブロックからのオフセットを示す動きベクトルのセットとして、符号化できる。

【0050】

イントラ予測は、共通フレーム内のブロックを符号化する。イントラ予測は、ルマおよびクロマ成分がフレーム内で密集する傾向があるという事実を利用する。例えば、木の一部の緑のパッチは、同様の緑のパッチに隣接して位置する傾向がある。イントラ予測は、複数の方向予測モード(例えば、HEVCでは33個)、平面モード、および直流(direct current(DC))モードを利用する。方向モードは、現在ブロックが対応する方向の近隣ブロックのサンプルと同様／同じであることを示す。平面モードは、行／列(例えば、平面)に沿う一連のブロックが行の端にある近隣ブロックに基づき補間できることを示す。平面モードは、事実上、変化する値の比較的一定の勾配を利用することにより、行／列に渡る光／色の円滑な遷移を示す。DCモードは、境界円滑化のために利用され、ブロックが方向予測モードの角度方向に関連する全部の近隣ブロックのサンプルに関連する平均値と同様／同じであることを示す。したがって、イントラ予測ブロックは、実際の値の代わりに、種々の関係予測モード値として、画像ブロックを表すことができる。さらに、インター予測ブロックは、実際の値の代わりに、動きベクトル値として、画像ブロックを表すことができる。いずれの場合にも、予測ブロックは、幾つかの場合に画像ブロックを正確に表さないことがある。任意の差分が残差ブロックに格納される。ファイルを更に圧縮するために、変換が残差ブロックに適用されてよい。

【0051】

ステップ107で、種々のフィルタリング技術が適用されてよい。HEVCでは、フィルタは、インループフィルタリング方式に従い適用される。上述のブロックに基づく予測は、デコーダにおいて濃淡のむらのある画像の生成をもたらし得る。さらに、ブロックに基づく予測方式は、ブロックを符号化し、次に、参照ブロックとして後に使用するために、符号化したブロックを再構成し得る。インループフィルタリング方式は、ノイズ抑制フィルタ、デブロッキングフィルタ、適応型ループフィルタ、およびサンプル適応型オフセット(sample adaptive offset(SAO))フィルタをブロック／フレームに繰り返し適用する。これらのフィルタは、このような濃淡のむらのアーチファクトを緩和し、その結果、符号化されたファイルは正確に再構成できる。さらに、これらのフィルタは、再構成された参照ブロック内のアーチファクトを緩和し、その結果、再構成された参照ブロックに基づき符号化される後のブロック内で追加アーチファクトを生じる可能性が低い。

【0052】

ビデオ信号がパーティショニングされ、圧縮され、およびフィルタリングされると、結果として生じるデータは、ステップ109でビットストリーム内に符号化される。ビットストリームは、上述のデータ、およびデコーダにおける適正なビデオ信号再構成をサポートするための任意の所望のシグナリングデータを含む。例えば、このようなデータは、パーティションデータ、予測データ、残差ブロック、およびデコーダに符号化指示を提供する種々のフラグを含んでよい。ビットストリームは、要求によりデコーダへ向けて送信するために、メモリに格納されてよい。ビットストリームは、複数のデコーダへ向けてブロードキャストおよび／またはマルチキャストされてもよい。ビットストリームの生成は反復処理である。したがって、ステップ101、103、105、107、および109は、多数のフレームおよびブロックに渡り連続しておよび／または同時に生じてよい。図1に示す順序は明確さおよび議論の容易さのために提示され、ビデオ符号化処理を特定の順序に限定することを意図しない。

【0053】

ステップ111で、デコーダは、ビットストリームを受信し、復号処理を開始する。具体的に、デコーダは、エントロピー復号方式を利用して、ビットストリームを対応するシンタックスおよびビデオデータに変換する。ステップ111で、デコーダは、ビットストリームからのシンタックスを利用して、フレームのパーティションを決定する。パーティショニングは、ステップ103におけるブロックパーティショニングの結果と一致するべきである。ステップ111で利用されるようなエントロピー符号化／復号は、以下に説明される。エンコーダは、圧縮処理の間に、入力画像内の値の空間的位置に基づき幾つかの可能な選択肢からブロックパーティショニング方式を選択するような、多くの選択肢を生成する。正確な選択肢をシグナリングすることは、膨大な数のビンを利用し得る。ここで使用されるように、ビンは、変数として扱われる2進値である(例えば、コンテキストに依存して変化し得るビット値)。エントロピー符号化は、許容可能な選択肢のセットを残して、エンコーダが特定の場合に明らかに実行可能ではない任意の選択肢を廃棄することを可能にする。各々の許容可能な選択肢は、次にコードワードを割り当てられる。コードワードの長さは、許容可能な選択肢の数に基づく(例えば、2個の選択肢に対して1つのビン、3～4個の選択肢に対して2つのビン、等)。エンコーダは、次に、選択された選択肢についてコードワードを符号化する。この方式は、全ての可能な選択肢の潜在的に大きな集合からの選択をユニークに示すのとは反対に、コードワードが可能な選択肢の小さな部分集合からの選択をユニークに示すために望ましい程度の大きさなので、コードワードのサイズを削減する。デコーダは、次に、エンコーダと同様の方法で許容可能な選択肢の集合を決定することにより、選択を復号する。許容可能な選択肢の集合を決定することにより、デコーダは、コードワードを読み出し、エンコーダにより行われた選択を決定できる。

【0054】

ステップ113で、デコーダは、ブロック復号を実行する。具体的に、デコーダは、逆変換を利用して残差ブロックを生成する。次に、デコーダは、残差ブロックおよび対応する予測ブロックを利用して、パーティショニングに従い画像ブロックを再構成する。予測ブロックは、エンコーダにおいてステップ105で生成されたイントラ予測ブロックおよびインター予測ブロックの両方を含んでよい。再構成画像ブロックは、次に、ステップ111で決定されたパーティショニングデータに従い再構成ビデオ信号のフレームへと位置付けられる。ステップ113のシンタックスも、上述のようなエントロピー符号化によりビットストリームの中でシグナリングされてよい。

【0055】

ステップ115で、エンコーダにおけるステップ107と同様の方法で、再構成ビデオ信号のフレームに対してフィルタリングが実行される。例えば、ノイズ抑制フィルタ、デブロッキングフィルタ、適応型ループフィルタ、およびSAOフィルタが、ブロッキングアーチファクトを除去するためにフレームに適用されてよい。フレームがフィルタリングされると、ビデオ信号は、エンドユーザによる閲覧のためにステップ117においてディスプレイへと出力できる。

【0056】

本開示は、CTUをパーティショニングするときの向上した符号化効率(例えば、ファイルサイズ低減)および／または低減した符号化複雑性(例えば、低減したプロセッサリソース使用)を提供するための変形に関連する。したがって、本開示は、エンコーダでのステップ103におけるブロックパーティショニングおよびデコーダでのステップ111におけるパーティショニングの決定の機能を向上する。具体的に、ステップ103および111では、対応するCBが閾値より大きい大きさのものである限り、CTU内のルマサンプルおよびクロマサンプルの両方をパーティショニングするために、共通符号化木が使用される。閾値以下のCBでは、符号化木は、それぞれサブ閾値ルマCBおよびクロマCBに対して異なるパーティショニングを実行できるルマ符号化部分木およびクロマ符号化部分木に分割される。

【0057】

図2は、ビデオ符号化のための例示的な符号化および復号(コーデック)システム200の概略図である。具体的に、コーデックシステム200は、動作方法100の実装をサポートするための機能を提供する。コーデックシステム200は、エンコーダおよびデコーダの両方の中で利用されるコンポーネントを示すために一般化される。コーデックシステム200は、パーティショニングされたビデオ信号201を生じる、動作方法100におけるステップ101および103に関して上述したビデオ信号を受信しパーティショニングする。コーデックシステム200は、次に、方法100におけるステップ105、107、および109に関して上述したエンコーダとして動作するとき、パーティショニングされたビデオ信号201を符号化ビットストリームへと圧縮する。デコーダとして動作するとき、コーデックシステム200は、動作方法100におけるステップ111、113、115、および117に関して上述したようにビットストリームから出力ビデオ信号を生成する。コーデックシステム200は、汎用コーダ制御コンポーネント211、変換スケーリングおよび量子化コンポーネント213、イントラピクチャ推定コンポーネント215、イントラピクチャ予測コンポーネント217、動き補償コンポーネント219、動き推定コンポーネント221、スケーリングおよび逆変換コンポーネント229、フィルタ制御分析コンポーネント227、インループフィルタコンポーネント225、復号ピクチャバッファコンポーネント223、およびヘッダフォーマットおよびコンテキスト適応型2進算術符号化(context adaptive binary arithmetic coding(CABAC))コンポーネント231を含む。このようなコンポーネントは図示のように結合される。図2では、黒線は符号化／復号されるべきデータの動きを示し、一方で、破線は他のコンポーネントの動作を制御する制御データの動きを示す。コーデックシステム200のコンポーネントは、エンコーダ内に全て存在してよい。デコーダは、コーデックシステム200のコンポーネントの一部を含んでよい。例えば、デコーダは、イントラピクチャ予測コンポーネント217、動き補償コンポーネント219、スケーリングおよび逆変換コンポーネント229、インループフィルタコンポーネント225、および復号ピクチャバッファコンポーネント223を含んでよい。これらのコンポーネントはここで説明される。

【0058】

パーティショニングされたビデオ信号201は、符号化木によりピクセルのブロックへとパーティショニングされた、キャプチャされたビデオシーケンスである。符号化木は、種々の分割モードを利用して、ピクセルのブロックをより小さなピクセルのブロックへと細分化する。これらのブロックは、次に、より小さなブロックへと更に細分化できる。ブロックは、符号化木上のノードと呼ばれてよい。より大きな親ノードは、より小さな子ノードへと分割される。ノードが細分化される回数は、ノード／符号化木の深さと呼ばれる。分割されたブロックは、幾つかの場合には符号化単位(coding unit(CU))に含まれ得る。例えば、CUは、ルマブロック、赤色差分クロマ(Cr)ブロック、および青色差分クロマ(Cb)ブロック、ならびにCUの対応するシンタックス命令を含むCTUの副部分であり得る。分割モードは、利用される分割モードに依存して変化する形状のそれぞれ2、3、または4個の子ノードにノードをパーティショニングするために利用される2分木(binary tree(BT))、3分木(triple tree(TT))、および4分木(quad tree(QT))を含んでよい。パーティショニングされたビデオ信号201は、汎用コーダ制御コンポーネント211、変換スケーリングおよび量子化コンポーネント213、イントラピクチャ推定コンポーネント215、フィルタ制御分析コンポーネント227、および動き推定コンポーネント221へと圧縮のために転送される。

【0059】

汎用コーダ制御コンポーネント211は、アプリケーション制約に従いビットストリームへのビデオシーケンスの画像の符号化に関連する決定を行うよう構成される。例えば、汎用コーダ制御コンポーネント211は、再構成品質に対するビットレート／ビットストリームサイズの最適化を管理する。このような決定は、記憶空間／帯域幅の利用可能性、および画像解像度要求に基づき行われてよい。汎用コーダ制御コンポーネント211は、また、バッファアンダーランおよびオーバラン問題を緩和するために、変換速度の観点でバッファ利用を管理する。これらの問題に対応するために、汎用コーダ制御コンポーネント211は、他のコンポーネントによるパーティショニング、予測、およびフィルタリングを管理する。例えば、汎用コーダ制御コンポーネント211は、解像度を増大するために圧縮複雑性を動的に増大させ、解像度および帯域幅使用を低減するために帯域幅使用を増大しまたは圧縮複雑性を減少させてよい。したがって、汎用コーダ制御コンポーネント211は、コーデックシステム200の他のコンポーネントを制御して、ビデオ信号再構成品質とビットレート関心事とのバランスをとる。汎用コーダ制御コンポーネント211は、他のコンポーネントの動作を制御する制御データを生成する。制御データも、デコーダにおける復号のためのパラメータをシグナリングするためにビットストリーム内に符号化されるようヘッダフォーマットおよびCABACコンポーネント231へ転送される。

【0060】

パーティショニングされたビデオ信号201は、インター予測のために、動き推定コンポーネント221および動き補償コンポーネント219へも送信される。パーティショニングされたビデオ信号201のフレームまたはスライスは、複数のビデオブロックに分割されてよい。動き推定コンポーネント221および動き補償コンポーネント219は、1つ以上の参照フレームの中の1つ以上のブロックに関連して、受信したビデオブロックのインター予測符号化を実行し、一時的予測を提供する。コーデックシステム200は、例えばビデオデータの各ブロックについて適切な符号化モードを選択するために、複数の符号化パスを実行してよい。

【0061】

動き推定コンポーネント221および動き補償コンポーネント219は、高度に統合されてよいが、概念的目的のために別個に示される。動き推定コンポーネント221により実行される動き推定は、ビデオブロックについて動きを推定する動きベクトルを生成する処理である。動きベクトルは、例えば、予測ブロックに関連して符号化オブジェクトの配置を示してよい。予測ブロックは、ピクセル差分の観点で、符号化されるべきブロックに厳密に一致すると分かったブロックである。予測ブロックは、参照ブロックとも呼ばれてよい。このようなピクセル差分は、絶対値差分の和(sum of absolute difference(SAD))、平方差分の和(sum of square difference(SSD))、または他の差分メトリックにより決定されてよい。HEVCは、CTU、符号化木ブロック(coding tree block(CTB))、およびCUを含む幾つかの符号化オブジェクトを利用する。例えば、CTUは、CTBに分割でき、CTBは次にCUに含むためにCBに分割できる。CUは、予測データを含む予測単位(prediction unit(PU))および／またはCUの変換された残差データを含む変換単位(transform unit(TU))として符号化できる。動き推定コンポーネント221は、レート歪み最適化処理の部分としてレート歪み分析を用いて、動きベクトル、PUおよびTUを生成する。例えば、動き推定コンポーネント221は、現在ブロック／フレームについて複数の参照ブロック、複数の動きベクトル、等を決定してよく、最適なレート歪み特性を有する参照ブロック、動きベクトル、等を選択してよい。最適なレート歪み特性は、ビデオ再構成の品質(例えば、圧縮によるデータ損失の量)および符号化効率(例えば、最終的な符号化のサイズ)の両方のバランスをとる。

【0062】

幾つかの例では、コーデックシステム200は、復号ピクチャバッファコンポーネント223に格納された参照ピクチャのサブ整数ピクセル位置の値を計算してよい。例えば、ビデオコーデックシステム200は、参照ピクチャの4分の1ピクセル位置、8分の1ピクセル位置、または他の分数ピクセル位置の値を補間してよい。したがって、動き推定コンポーネント221は、完全ピクセル位置および分数ピクセル位置に関連して動き探索を実行し、分数ピクセル精度で動きベクトルを出力してよい。動き推定コンポーネント221は、PUの位置を参照ピクチャの予測ブロックの位置と比較することにより、インター符号化スライスの中のビデオブロックのPUについて、動きベクトルを計算する。動き推定コンポーネント221は、計算した動きベクトルを動きデータとして、符号化のためにヘッダフォーマットおよびCABACコンポーネント231へ、動きを動き補償コンポーネント219へ出力する。

【0063】

動き補償コンポーネント219により実行される動き補償は、動き推定コンポーネント221により決定された動きベクトルに基づき、予測ブロックをフェッチするまたは生成することを含んでよい。ここでも、動き推定コンポーネント221および動き補償コンポーネント219は、幾つかの例では機能的に統合されてよい。現在ビデオブロックのPUの動きベクトルを受信すると、動き補償コンポーネント219は、動きベクトルの指す予測ブロックの位置を特定してよい。次に、符号化されている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算してピクセル差分値を形成することにより、残差ビデオブロックが形成される。一般に、動き推定コンポーネント221は、ルマ成分に関連して動き推定を実行し、動き補償コンポーネント219は、クロマ成分およびルマ成分の両方についてルマ成分に基づき計算された動きベクトルを使用する。予測ブロックおよび残差ブロックは、変換スケーリングおよび量子化コンポーネント213へ転送される。

【0064】

パーティショニングされたビデオ信号201は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217へも送信される。動き推定コンポーネント221および動き補償コンポーネント219と同様に、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は、高度に統合されてよいが、概念的目的のために別個に示される。上述のようなフレーム間の動き推定コンポーネント221および動き補償コンポーネント219により実行されるインター予測の代わりに、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は、現在フレーム内のブロックに関連して現在ブロックをイントラ予測する。特に、イントラピクチャ推定コンポーネント215は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定する。幾つかの例では、イントラピクチャ推定コンポーネント215は、複数のテストされたイントラ予測モードから、現在ブロックを符号化するための適切なイントラ予測モードを選択する。選択したイントラ予測モードは、次に、符号化のためにヘッダフォーマットおよびCABACコンポーネント231へ転送される。

【0065】

例えば、イントラピクチャ推定コンポーネント215は、種々のテストされたイントラ予測モードについてレート歪み分析を用いてレート歪み値を計算し、テストしたモードの中で最適なレート歪み特性を有するイントラ予測モードを選択する。レート歪み分析は、一般に、符号化ブロックと、符号化されて該符号化ブロックを生成した元の未符号化ブロックとの間の歪み(または誤差)の量、並びに符号化ブロックを生成するために使用されたビットレート(例えば、ビット数)を決定する。イントラピクチャ推定コンポーネント215は、種々の符号化ブロックについて歪みおよびレートから比を計算して、ブロックについて、どのイントラ予測モードが最適なレート歪み値を示すかを決定する。さらに、イントラピクチャ推定コンポーネント215は、レート歪み最適化(rate－distortion optimization(RDO))に基づき、深さモデル化モード(depth modeling mode(DMM))を用いて深さマップの深さブロックを符号化するよう構成されてよい。

【0066】

イントラピクチャ予測コンポーネント217は、エンコーダに実装されるとき、イントラピクチャ推定コンポーネント215により決定された、選択されたイントラ予測モードに基づき、予測ブロックから残差ブロックを生成し、または、デコーダに実装されるとき、ビットストリームから残差ブロックを読み出してよい。残差ブロックは、行列として表現される、予測ブロックと元のブロックとの間の値の差分を含む。残差ブロックは、次に、変換スケーリングおよび量子化コンポーネント213へ転送される。イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は、ルマおよびクロマ成分の両方に対して動作してよい。

【0067】

変換スケーリングおよび量子化コンポーネント213は、残差ブロックを更に圧縮するよう構成される。変換スケーリングおよび量子化コンポーネント213は、離散コサイン変換(discrete cosine transform(DCT))、離散サイン変換(discrete sine transform(DST))、または概念的に類似する変換のような変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生成する。ウェーブレット変換、整数変換、サブバンド変換、または他の種類の変換も使用され得る。変換は、残差情報を、ピクセル値ドメインから周波数ドメインのような変換ドメインへと変換してよい。変換スケーリングおよび量子化コンポーネント213は、また、例えば周波数に基づき、変換された残差情報をスケーリングするよう構成される。このようなスケーリングは、倍率を残差情報に適用することを含む。その結果、異なる周波数情報は異なる粒度で量子化され、これは再構成ビデオの最終的な視覚的品質に影響を与え得る。変換スケーリングおよび量子化コンポーネント213は、また、ビットレートを更に低減するために、変換係数を量子化するよう構成される。量子化処理は、係数の一部または全部に関連するビット深さを低減してよい。量子化の程度は、量子化パラメータを調整することにより、変更されてよい。幾つかの例では、変換スケーリングおよび量子化コンポーネント213は、次に、量子化された変換係数を含む行列のスキャンを実行してよい。量子化された変換係数は、ビットストリーム内に符号化されるために、ヘッダフォーマットおよびCABACコンポーネント231へ転送される。

【0068】

スケーリングおよび逆変換コンポーネント229は、動き推定をサポートするために、変換スケーリングおよび量子化コンポーネント213の逆処理を適用する。スケーリングおよび逆変換コンポーネント229は、逆スケーリング、変換、および／または量子化を適用して、例えば別の現在ブロックのための予測ブロックになり得る参照ブロックとして後に使用するために、ピクセルドメインの残差ブロックを再構成する。動き推定コンポーネント221および／または動き補償コンポーネント219は、後のブロック／フレームの動き推定で使用するために、残差ブロックを対応する予測ブロックに加算して戻すことにより、参照ブロックを計算してよい。スケーリング、量子化、および変換の間に生成されたアーチファクトを低減するために、再構成された参照ブロックにフィルタが適用される。このようなアーチファクトは、そうでなければ、後続のブロックが予測されるときに不正確な予測を生じ(および追加アーチファクトを生成し)得る。

【0069】

フィルタ制御分析コンポーネント227およびインループフィルタコンポーネント225は、残差ブロックにおよび／または再構成画像ブロックにフィルタを適用する。例えば、スケーリングおよび逆変換コンポーネント229からの変換された残差ブロックは、元の画像ブロックを再構成するために、イントラピクチャ予測コンポーネント217および／または動き補償コンポーネント219からの対応する予測ブロックと結合されてよい。フィルタは、次に、再構成画像ブロックに適用されてよい。幾つかの例では、フィルタは、代わりに、残差ブロックに適用されてよい。図2の他のコンポーネントと同様に、フィルタ制御分析コンポーネント227およびインループフィルタコンポーネント225は、高度に統合され一緒に実装されてよいが、概念的目的のために別個に示される。再構成された参照ブロックに適用されるフィルタは、特定の空間領域に適用され、このようなフィルタがどのように適用されるかを調整するための複数のパラメータを含む。フィルタ制御分析コンポーネント227は、再構成された参照ブロックを分析して、このようなフィルタが適用されるべき場合を決定し、対応するパラメータを設定する。このようなデータは、ヘッダフォーマットおよびCABACコンポーネント231へ、符号化のためのフィルタ制御データとして転送される。インループフィルタコンポーネント225は、フィルタ制御データに基づき、このようなフィルタを適用する。フィルタは、デブロッキングフィルタ、ノイズ抑制フィルタ、SAOフィルタ、および適応型ループフィルタを含んでよい。このようなフィルタは、例に依存して、(例えば、再構成されたピクセルブロック上の)空間／ピクセルドメインにおいて、または周波数ドメインにおいて、適用されてよい。

【0070】

エンコーダとして動作するとき、フィルタリングされた再構成画像ブロック、残差ブロック、および／または予測ブロックは、上述のように動き推定において後に使用するために、復号ピクチャバッファコンポーネント223に格納される。デコーダとして動作するとき、復号ピクチャバッファコンポーネント223は、出力ビデオ信号の部分として、再構成されフィルタリングされたブロックを格納しディスプレイへ向けて転送する。復号ピクチャバッファコンポーネント223は、予測ブロック、残差ブロック、および／または再構成画像ブロックを格納することの可能な任意のメモリ装置であってよい。

【0071】

ヘッダフォーマットおよびCABACコンポーネント231は、コーデックシステム200の種々のコンポーネントからデータを受信し、デコーダへ向けて送信するためにこのようなデータを符号化ビットストリームに符号化する。具体的に、ヘッダフォーマットおよびCABACコンポーネント231は、一般制御データおよびフィルタ制御データのような制御データを符号化するために種々のヘッダを生成する。さらに、イントラ予測および動きデータを含む予測データ、ならびに量子化された変換係数データの形式の残差データは、全てビットストリーム内に符号化される。最終的なビットストリームは、元のパーティショニングされたビデオ信号201を再構成するためにデコーダにより所望される全ての情報を含む。このような情報は、イントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)、種々のブロックの符号化コンテキストの定義、最も有望なイントラ予測モードの指示、パーティション情報の指示、等も含んでよい。このようなデータは、エントロピー符号化を利用することにより、符号化されてよい。例えば、情報は、コンテキスト適応型可変長符号化(context adaptive variable length coding(CAVLC))、CABAC、シンタックスに基づくコンテキスト適応型2進算術符号化(syntax－based context－adaptive binary arithmetic coding(SBAC))、確率間隔パーティショニングエントロピー(probability interval partitioning entropy(PIPE))符号化、または別のエントロピー符号化技術を利用することにより、符号化されてよい。エントロピー符号化に従い、符号化されたビットストリームは、別の装置(例えば、ビデオデコーダ)へ送信され、または後の送信または読み出しのために保存されてよい。

【0072】

本開示は、CTUをパーティショニングするときの向上した符号化効率(例えば、ファイルサイズ低減)および／または低減した符号化複雑性(例えば、低減したプロセッサリソース使用)を提供するための変形を含む。したがって、本開示は、例に依存してコーデックシステム200の残りの部分による符号化および／または復号のためにパーティショニングされたビデオ信号201を生成するときのコーデックシステム200の機能を向上する。具体的に、パーティショニングされたビデオ信号201を生成するとき、対応するCBが閾値より大きい大きさのものである限り、CTU内のルマサンプルおよびクロマサンプルの両方をパーティショニングするために、共通符号化木が使用される。閾値以下のCBでは、符号化木は、それぞれサブ閾値ルマCBおよびクロマCBに対して異なるパーティショニングを実行できるルマ符号化部分木およびクロマ符号化部分木に分割される。

【0073】

図3は、ルマおよびクロマブロックをパーティショニングし得る例示的なビデオエンコーダ300を示すブロック図である。ビデオエンコーダ300は、コーデックシステム200の符号化機能を実装するために、および／または動作方法100のステップ101、103、105、107および／または109を実装するために、利用されてよい。エンコーダ300は、入力ビデオ信号をパーティショニングして、実質的にパーティショニングされたビデオ信号201と同様であるパーティショニングされたビデオ信号301を生じる。パーティショニングされたビデオ信号301は、次に、エンコーダ300のコンポーネントにより圧縮されビットストリームに符号化される。

【0074】

具体的に、パーティショニングされたビデオ信号301は、イントラ予測のためにイントラピクチャ予測コンポーネント317へ転送される。イントラピクチャ予測コンポーネント317は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217と実質的に同様であってよい。パーティショニングされたビデオ信号301は、復号ピクチャバッファコンポーネント323の中の参照ブロックに基づくインター予測のために動き補償コンポーネント321へも転送される。動き補償コンポーネント321は、動き推定コンポーネント221および動き補償コンポーネント219と実質的に同様であってよい。イントラピクチャ予測コンポーネント317および動き補償コンポーネント321からの予測ブロックおよび残差ブロックは、残差ブロックの変換および量子化のために、変換および量子化コンポーネント313へ転送される。変換および量子化コンポーネント313は、変換スケーリングおよび量子化コンポーネント213と実質的に同様であってよい。変換され量子化された残差ブロックおよび対応する予測ブロックは(関連する制御データと一緒に)、ビットストリームへの符号化のためにエントロピー符号化コンポーネント313へ転送される。エントロピー符号化コンポーネント331は、ヘッダフォーマットおよびCABACコンポーネント231と実質的に同様であってよい。

【0075】

変換され量子化された残差ブロックおよび／または対応する予測ブロックは、また、動き補償コンポーネント321による使用のために参照ブロックへと再構成するために、変換および量子化コンポーネント313から逆変換および量子化コンポーネント329へ転送される。逆変換および量子化コンポーネント329は、スケーリングおよび逆変換コンポーネント229と実質的に同様であってよい。インループフィルタコンポーネント325の中のインループフィルタも、例に依存して、残差ブロックおよび／または再構成された参照ブロックに適用される。インループフィルタコンポーネント325は、フィルタ制御分析コンポーネント227およびインループフィルタコンポーネント225と実質的に同様であってよい。インループフィルタコンポーネント325は、インループフィルタコンポーネント225に関して議論したような複数のフィルタを含んでよい。フィルタリングされたブロックは、次に、動き補償コンポーネント321により参照ブロックとして使用するために、復号ピクチャバッファコンポーネント323に格納される。復号ピクチャバッファコンポーネント323は、復号ピクチャバッファコンポーネント223と実質的に同様であってよい。

【0076】

ビデオエンコーダ300は、上述のように他のコンポーネントによる更なる圧縮のために、一連のビデオフレームを受信し、パーティショニングされたビデオ信号301にパーティショニングする。ビデオフレームはスライスに分割される。具体的に、フレームの部分は、動き補償コンポーネント321による単方向インター予測のために選択され、1つ以上のPスライスに含まれる。フレームの他の部分は、動き補償コンポーネント321による両方向インター予測のために選択され、1つ以上のBスライスに含まれる。フレームのまた他の部分は、イントラピクチャ予測コンポーネント317によるイントラ予測のために選択され、1つ以上のIスライスに含まれる。開示のメカニズムはPおよびBスライスについて動作可能であるが、多くの例において、符号化効率はIスライスについて最も有意に向上する。したがって、開示のメカニズムは、主にIスライスを参照して説明される。

【0077】

ビデオフレーム内のスライスは、CTUに更に細分化される。CTUは、ルマおよびクロマサンプルの両方を含む。符号化木は、次に、各CTUについて選択され、適用される。CTUは、パーティショニング目的で、CTBと呼ばれ得る。CTBの符号化木は、選択した分割モードを適用して、CTBをルマCBに分割する。CTBの符号化木は、次に、選択した分割モードを適用して、CTBをクロマCBに分割する。ルマCBおよび対応するクロマCB(例えば、CrおよびCbの両方)は、それぞれ、対応するシンタックス情報と共にCUに含まれる。CUはパーティショニングされたビデオ信号301を形成し、これは、動き補償コンポーネント321、イントラピクチャ予測コンポーネント317、および／または変換および量子化コンポーネント313へ圧縮のために転送される。

【0078】

開示のメカニズムは、同じ符号化木(ここでは共通符号化木とも呼ばれる)を、CTU内の全部のサンプルに適用する。しかしながら、エンコーダシステム300は、CTUに符号化木を適用するための閾値を利用する。閾値を超えるサイズのルマ符号化ブロックおよびクロマ符号化ブロックは、同じ符号化木により分割され、したがって、同じ分割モードにより分割されて、結果として同じパーティションを生じる。符号化木は、閾値以下のサイズの、それぞれルマおよびクロマ符号化ブロックのためのルマ符号化部分木およびクロマ符号化部分木に分割される。したがって、ルマブロックの最終的なパーティションは、閾値に達するまで、クロマブロックのものと同じである。次に、パーティションは分岐する。これは、ルマサンプルとクロマサンプルとの間の差分を考慮することにより、符号化効率を最適化するために、符号化部分木が分割モードを選択することを可能にする。この方法では、全体の符号化効率は、CTU内の全てのサンプルについて単一の符号化木を使用するより向上する。さらに、共有符号化木は、CTUについて一度だけ計算され、(例えば、ビットストリーム内のシンタックスに)一度だけ格納される。部分木は、別個に計算され、(例えば、部分木の間の差分として)別個に格納される。しかしながら、異なる部分木の計算複雑性および符号化サイズの増大は、別個の符号化木の複雑性および符号化サイズより有意に小さい。したがって、開示のメカニズムは、最終的なビットストリームのファイルサイズを削減し並びに複雑性、およびしたがってプロセッサリソース使用を他のパーティショニングメカニズムに比べて低減することにより、全体の符号化効率を向上する。

【0079】

図4は、ルマおよびクロマブロックをパーティショニングし得る例示的なビデオデコーダ400を示すブロック図である。ビデオエンコーダ400は、コーデックシステム200の復号機能を実装するために、および／または動作方法100のステップ111、113、115および／または117を実装するために、利用されてよい。デコーダ400は、例えばエンコーダ300からビットストリームを受信し、エンドユーザに表示するためにビットストリームに基づき再構成された出力ビデオ信号を生成する。

【0080】

ビットストリームは、エントロピー復号コンポーネント433により受信される。エントロピー復号コンポーネント433は、CAVLC、CABAC、SBAC、PIPE符号化のようなエントロピー復号方式、または他のエントロピー符号化技術を実装するよう構成される。例えば、エントロピー復号コンポーネント433は、ビットストリーム内にコードワードとして符号化された追加データを解釈するために、ヘッダ情報を利用してコンテキストを提供してよい。復号された情報は、一般制御データ、フィルタ制御データ、パーティション情報、動きデータ、予測データ、および残差ブロックからの量子化された変換係数のような、ビデオ信号を復号するための任意の所望の情報を含む。量子化された変換係数は、残差ブロックへと再構成するために、逆変換および量子化コンポーネント429へ転送される。逆変換および量子化コンポーネント429は、逆変換および量子化コンポーネント329と同様であってよい。

【0081】

再構成された残差ブロックおよび／または予測ブロックは、イントラ予測動作に基づき画像ブロックへと再構成するために、イントラピクチャ予測コンポーネント417へ転送される。イントラピクチャ予測コンポーネント417は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217と同様であってよい。具体的に、イントラピクチャ予測コンポーネント417は、フレーム内の参照ブロックの位置を特定するために予測モードを利用し、結果に残差ブロックを適用して、イントラ予測された画像ブロックを再構成する。再構成されたイントラ予測された画像ブロックおよび／または残差ブロック、および対応するインター予測データは、それぞれ復号ピクチャバッファコンポーネント223およびインループフィルタコンポーネント225と実質的に同様であってよいインループフィルタコンポーネント425を介して復号ピクチャバッファコンポーネント423へ転送される。インループフィルタコンポーネント425は、再構成画像ブロック、残差ブロック、および／または予測ブロックをフィルタリングし、そのような情報は復号ピクチャバッファコンポーネント423に格納される。復号ピクチャバッファコンポーネント423からの再構成画像ブロックは、インター予測のために動き補償コンポーネント421へ転送される。動き補償コンポーネント421は、動き推定コンポーネント221および／または動き補償コンポーネント219と実質的に同様であってよい。具体的に、動き補償コンポーネント421は、参照ブロックからの動きベクトルを利用して、予測ブロックを生成し、結果に残差ブロックを提供して、画像ブロックを再構成する。結果として生じた再構成ブロックは、インループフィルタコンポーネント425を介して、復号ピクチャバッファコンポーネント423へ転送されてもよい。復号ピクチャバッファコンポーネント423は、パーティション情報によりフレームへと再構成できる、追加再構成画像ブロックを格納し続ける。このようなフレームは、シーケンス内に配置されてもよい。シーケンスは、再構成された出力ビデオ信号としてディスプレイに向けて出力される。

【0082】

ビデオエンコーダ300と同様に、ビデオデコーダ400は、閾値より上のサイズを有するルマブロックおよびクロマブロックに対して共通符号化木を適用し、閾値以下のサイズを有するルマブロックおよびクロマブロックに対して分割符号化部分木を適用することにより、パーティショニングを実行する。具体的に、デコーダ400のエントロピー復号コンポーネント433は、共通符号化木、ルマ符号化部分木、およびクロマ符号化部分木を、CTUのシンタックスから取得する。各CTUについて、共通符号化木が適用されて、閾値に達するまで、ルマサンプルをルマ符号化ブロックへと分割する。次に、ルマ符号化部分木が適用されて、ルマ符号化ブロックを、閾値以下のサイズに細分化する。さらに、共通符号化木が適用されて、閾値に達するまで、クロマサンプルをクロマ符号化ブロックへと分割する。次に、クロマ符号化部分木が適用されて、クロマ符号化ブロックを、閾値以下のサイズに細分化する。同じ符号化木およびクロマ符号化部分木が、CrおよびCbサンプルの両方に適用できる。結果として生じる符号化ブロックは、CUへと結合され、動き補償コンポーネント421、イントラピクチャ予測コンポーネント417、および／または逆変換および量子化コンポーネント429へ、出力ビデオ信号の部分としてユーザに表示するために最終的なビデオフレームへと復号するために転送され得る。

【0083】

共通符号化木および分割部分木を使用することは、ビットストリームのファイルサイズを低減し、したがって、エンコーダシステム300におけるようにデコーダシステム400において符号化効率を向上する。さらに、共通符号化木がルマサンプルおよびクロマサンプルの両方に閾値に達するまで適用されるので、複雑性の低減も達成され得る。これは、別個の符号化木を適用するよりも少ない処理リソースしか必要としなくてもよい。共通符号化木および分割部分木を利用するパーティショニングメカニズムは、方法100、コーデックシステム200、エンコーダシステム300、およびエンコーダシステム400で使用されるように、以下の図を参照して更に詳細に議論される。

【0084】

図5は、ルマCBおよびクロマCBを含む符号化単位(coding units(CU))に、CTUをパーティショニングする例示的なメカニズム500を示す概略図である。メカニズム500は、ビデオフレームをパーティショニングするとき、方法100、コーデックシステム200、エンコーダシステム300、および／またはデコーダシステム400により利用されてよい。

【0085】

ビデオフレームは、受信され、1つ以上のスライス540へとパーティショニングされる。スライス540は、同じフレーム内の他の領域と別個に符号化される、該フレームの空間的に異なる領域である。フレームの領域は、対応する領域について、割り当てられた符号化メカニズムに基づき、スライス540に割り当てられる。単方向インター予測および両方向インター予測のために指定されたフレームの領域は、それぞれPおよびBスライス540に割り当てられる。イントラ予測のために指定されたフレームの領域は、Iスライス541に割り当てられる。

【0086】

スライス540は、CTU541に分割される。CTU541は、完全符号化木547の適用を受け入れ可能なピクセルの最大ブロックである(例えば、符号化木547は、通常、CTU541境界に跨がって広がらない)。CTU541サイズは、シンタックスにより定められ、例えば64ピクセル×64ピクセル、32ピクセル×32ピクセル、16ピクセル×16ピクセル等であってよい。CTU541は、幾つかの例では長方形であってもよい。CTU541は、ルマサンプル542およびクロマサンプル544の両方を含む。ルマサンプル542は光値であり、クロマサンプル544は色値である。クロマサンプル544は、Cb値およびCr値の両方を含んでよい。留意すべきことに、ルマサンプル542およびクロマサンプル544は、幾つかのコンテキストでは、それぞれルマデータおよびクロマデータとも呼ばれ得る。

【0087】

符号化木547、ルマ符号化部分木548、およびクロマ符号化部分木550は、ルマサンプル542およびクロマサンプル544に、閾値549に基づき適用される。符号化木547は、子および／または親関係により関連付けられた決定ノードのリストである。各ノードは、対応するサンプルをパーティショニングする分割モードに関連付けられる。符号化木547の第1ノード(例えば、ルートノード)は、分割モードを適用して、ルマサンプル542またはクロマサンプル544を対応するブロックにパーティショニングする。子ノードは、符号化木547の枝に達するまで、更なる分割モードを繰り返し適用して、ブロックの対応する部分をより小さいブロックに細分化する。

【0088】

上述のように、符号化木547は、対応するブロックが閾値549により示されるサイズに分割されるまで、ルマサンプル542およびクロマサンプル544の両方に適用される。閾値549は、定められた数値のサイズ値である。例えば、閾値549は、4096ピクセル、2048ピクセル、1024ピクセル、等であってよい。閾値549は、幾つかの例では、log2Cbsizeのような対数に基づく値としても表現されてよい。ここで、log2Cbsizeは、log2を符号化ブロックサイズ(例えば6ピクセル)により乗算したものであり、4096ピクセルに等しい。

【0089】

ルマ符号化部分木548およびクロマ符号化部分木550は、閾値549以下のサイズに分割される符号化ブロックに適用される。具体的に、ルマ符号化ブロック543およびクロマ符号化ブロック545は、CTU541のルマサンプル542およびクロマサンプル544の部分集合をそれぞれ含む。したがって、ルマ符号化部分木548およびクロマ符号化部分木550は、ルマ符号化ブロック543およびクロマ符号化ブロック545に適用されて、それらのブロックのサイズが閾値より小さいとき、ルマサンプル542およびクロマサンプル544をそれぞれ更にパーティショニングする。符号化部分木は、符号化木547の子であるルートノードを有する符号化木である。符号化部分木は、ルマサンプル542に適用するためのルマ符号化部分木548、およびクロマサンプル544に適用するためのクロマ符号化部分木550を含む。ルマ符号化部分木548およびクロマ符号化部分木550は、異なり得る。これは、ルマサンプル542およびクロマサンプル544の両方により大きなパーティションが共有されるが、ルマサンプル542およびクロマサンプル544に対して異なるサブパーティションを可能にする。したがって、ルマサンプル542およびクロマサンプル544は、閾値549に達するまで、符号化木547に従い同じ分割モードにより分割される。次に、符号化木547により生成されたルマブロックおよびクロマブロックは、異なるルマ符号化部分木548およびクロマ符号化部分木550に基づき異なる分割モードの影響を受ける。

【0090】

符号化木547およびルマ符号化部分木548は、ルマサンプル542をルマ符号化ブロック543に分割する。符号化木547およびクロマ符号化部分木550は、クロマサンプル544をクロマ符号化ブロック545に分割する。ルマ符号化ブロック543は、更なる圧縮のために指定されたルマサンプル542のパーティショニングされたグループである。クロマ符号化ブロック545は、更なる圧縮のために指定されたクロマサンプル544のパーティショニングされたグループである。ルマ符号化ブロック543および関連するクロマ符号化ブロック545は、符号化単位546に割り当てられてよい。符号化単位546は、ビデオ圧縮のためにインター予測および／またはイントラ予測を介して転送される、関連するピクセルサンプル値のグループである。スライス540がIスライス540であるとき、符号化単位546は、イントラ予測のために転送される。スライス540がPスライス540またはBスライス540であるとき、符号化単位546は、インター予測のために転送される。符号化単位546は、単一のルマ符号化ブロック543と、Crサンプル値を有するCrクロマ符号化ブロック551およびCbサンプル値を有するCbクロマ符号化ブロック552を含むクロマ符号化ブロック545と、を含んでよい。

【0091】

図6は、それぞれCTU541および符号化木547と実質的に同様であってよい、CTUに適用される例示的な符号化木600を示す。したがって、符号化木600は、ビデオフレームをパーティショニングするとき、方法100、コーデックシステム200、エンコーダシステム300、デコーダシステム400、および／またはメカニズム500により利用されてよい。例えば、符号化木600は、ルマおよび／またはクロマ符号化部分木614を有する共通符号化木613を含んでよく、これは符号化木547、ルマ符号化部分木548、および／またはクロマ符号化部分木550を実装してよい。

【0092】

符号化木600は、CTUを、CUを構成するCBにパーティショニングするために利用される。符号化木600は、図示の例では例えばルートノード611、第2層ノード615、第3層ノード617、および第4層ノード619を含む複数のノードを含む。留意すべきことに、4層のノードが示されるが、CTUサイズおよび最小ブロックサイズに依存して、任意の数の層が利用されてよい。ノード611、615、617、および619は、黒い点として図6に示される。符号化木600ノードは、ここで使用されるように、ブロックをピクセルの複数のより小さいブロックにパーティショニングするために分割モードが適用可能な対応するサイズのピクセルのブロックである。図示の例では、ノードは、対応するブロックを4個のより小さいブロックに分割する4分木分割モードを利用する。この処理は、所定の条件に達するまで継続し得る。このような所定の条件は、最小ブロックサイズおよび／またはブロックの信号特性(例えば、周波数ドメインにおけるブロック内のデータの係数)を含み得る。例えば、ルートノード611において、ブロック、この場合にはCTUを、より小さいブロックにパーティショニングするために、分割モードが適用され得る。対応するパーティションによる分割モードは、異なる値を有するピクセルを異なるブロックに分けるために、および同様の値を有するピクセルを共通ブロックにグループ化するために、選択される。ルートノード611においてパーティショニングされたブロックは、第2層ノード615を生じる。各ノードにおいて、ブロックは、信号特性およびブロックサイズをチェックされる。信号特性が、ブロックが比較的同様の値のピクセルを含むと示すとき、ブロックはもはや分割されなくてよい。また、ブロックが最小サイズに達すると、ブロックはもはや分割されなくてよい。図示の例では、第2層ノード615のうちの3個は、対応するパーティションを有する追加分割モードを適用することにより、更に分割されて、第3層ノード617を生じる。本例では、第2層ノード615のうちの1個は、例えばブロック内のサンプルに関連する信号特性(例えば、周波数ドメインにおける係数)がブロックは比較的同様の値のピクセルを含むと示すために、もはや分割されない。同様に第3層ノード617は、次に、本例では第4層ノード619に分割できる。

【0093】

したがって、符号化木600がCTUに適用されると、符号化木600は、対応する分割モードを有するルートノード611を、CTU全体に適用して、CTUをブロックにパーティショニングする。符号化木600は、次に、最小ブロックサイズおよび信号特性制約の下で、次第に小さなサイズのノード615、617、および／または619を適用して、各層のブロックをより小さなブロックへと繰り返しパーティショニングする。図6に4分木分割モードが示されるが、後述するように多くの分割モードが利用できる。

【0094】

上述のように、ルマ成分およびクロマ成分の信号特性は、有意に異なってよい。したがって、ルマブロックの効率的分割モードは、同じ位置にあるクロマブロックの効率的分割モードと異なってよい。したがって、共通符号化木613が、閾値より大きいノード611および615並びに対応するブロックに対して利用できる。別個のルマおよびクロマ符号化部分木614は、閾値以下のノードおよび対応するブロックを分割するために、この場合には第3層ノード617を第4層ノード619に分割するために、利用できる。符号化部分木614は、共通符号化木613の子であるルートノードを有する符号化木である。共通符号化木613は実線で示され、符号化部分木614は破線で示される。具体的に、ノード611および615が閾値より大きいサイズに関連するとき、ノード611および615は、共通符号化木613上に位置する。ノード617および619が閾値以下であるとき、ノード617および619は、符号化部分木614上に位置する。ルマ符号化部分木614のために選択されたノードおよび対応する分割モードは、クロマ符号化部分木614を決定するとき、異なるノードおよび／または分割モードで置き換えることができる。この場合、ルマ符号化部分木の中のノード617は、クロマ符号化部分木の中のノード617と異なる分割モードを利用でき、結果として異なる符号化部分木614の異なるノード619を生じる。これは、異なる細かい粒度のパーティションを利用しながら、ルマ符号化ブロックおよびクロマ符号化ブロックが、全体的に同様のパーティションを維持することを可能にする。

【0095】

図7は、符号化木547、ルマ符号化部分木548、クロマ符号化部分木550、符号化木600、共通符号化木613、および符号化部分木614のような符号化木で利用される分割モード700の例示的なセットを示す概略図である。したがって、分割モード700のセットは、ビデオフレームをパーティショニングするために方法100、コーデックシステム200、エンコーダシステム300、および／またはデコーダシステム400を動作させるとき、メカニズム500で利用できる。分割モード700のセットは、4分木(quad tree(QT))701、垂直2分木(vertical binary tree(VBT))703、水平2分木(horizontal binary tree(HBT))705、垂直3分木(vertical triple tree(VTT))707、および水平3分木(horizontal triple tree(HTT))709を含む。符号化木の各ノード(および符号化部分木の中の各ノード)は、分割モード700のセットのうちの1つをサンプルのブロックに適用する。したがって、符号化木／部分木の中の親ノードは、サンプルのグループに分割モードを適用して、(分割モードに依存して)2、3、または4個のブロックを生成する。次に、子ノードは、更なる分割モードを適用して、親ノードにより生成されたブロックを更に分割する。子ノードの子ノードは、符号化木／部分木の終わりに達するまで、このようなブロックを更に細分化できる。特定ノードの分割モードは、(例えば、エンコーダにおけるRDO処理により)分割モード700のセットから選択されて、イントラ予測および／またはインター予測による効率的な圧縮をサポートするために、同様の値を有するサンプルをグループ化する。デコーダにおいて、符号化木、部分木、および分割モードは、例えばスライス、CTU、および／または対応する符号化単位のパラメータセットの中のシンタックスに格納されたビットストリームから決定できる。

【0096】

QT701は、符号化ブロックを4個の等しいサブブロックに分割する分割モードである。したがって、QT701は、ルマサンプルのブロックを、等しいサイズの、ルマサンプルの4個のブロックに分割する。したがって、QT701は、クロマサンプルのブロックを、等しいサイズの、クロマサンプルの4個のより小さいブロックに分割する。

【0097】

VBT703は、符号化ブロックを等しいサイズの2個のサブブロックに分割する分割モードである。このようなサブブロックは、元の符号化ブロックと同じ高さおよび半分の幅を有する。したがって、VBT703は、ルマサンプルの親ブロックを、ルマサンプルの親ブロックと同じ高さおよび半分の幅を有する等しいサイズの、ルマサンプルの2個の子ブロックに分割する。さらに、VBT703は、クロマサンプルの親ブロックを、クロマサンプルの親ブロックと同じ高さおよび半分の幅を有する等しいサイズの、クロマサンプルの2個の子ブロックに分割する。

【0098】

HBT705は、符号化ブロックを等しいサイズの2個のサブブロックに分割する分割モードである。このようなサブブロックは、元の符号化ブロックと同じ幅および半分の高さを有する。したがって、HBT705は、ルマサンプルの親ブロックを、ルマサンプルの親ブロックと同じ幅および半分の高さを有する等しいサイズの、ルマサンプルの2個の子ブロックに分割する。さらに、HBT705は、クロマサンプルの親ブロックを、クロマサンプルの親ブロックと同じ幅および半分の高さを有する等しいサイズの、クロマサンプルの2個の子ブロックに分割する。

【0099】

VTT707は、符号化ブロックを3個のサブブロックに分割する分割モードである。このようなサブブロックは、元の符号化ブロックと同じ高さを有する。サブブロックのうちの1個は、元の符号化ブロックの半分の幅を有し、サブブロックのうちの2個は、元の符号化ブロックの4分の1の幅を有する。したがって、VTT707は、ルマサンプルの親ブロックを、ルマサンプルの親ブロックと同じ高さを有し、ルマサンプルの親ブロックのそれぞれ4分の1、半分、および4分の1の幅を有する、ルマサンプルの3個の子ブロックに分割する。さらに、VTT707は、クロマサンプルの親ブロックを、クロマサンプルの親ブロックと同じ高さを有し、クロマサンプルの親ブロックのそれぞれ4分の1、半分、および4分の1の幅を有する、クロマサンプルの3個の子ブロックに分割する。

【0100】

HTT709は、符号化ブロックを3個のサブブロックに分割する分割モードである。このようなサブブロックは、元の符号化ブロックと同じ幅を有する。サブブロックのうちの1個は、元の符号化ブロックの半分の高さを有し、サブブロックのうちの2個は、元の符号化ブロックの4分の1の高さを有する。したがって、HTT709は、ルマサンプルの親ブロックを、ルマサンプルの親ブロックと同じ幅を有し、ルマサンプルの親ブロックのそれぞれ4分の1、半分、および4分の1の高さを有する、ルマサンプルの3個の子ブロックに分割する。さらに、HTT709は、クロマサンプルの親ブロックを、クロマサンプルの親ブロックと同じ幅を有し、クロマサンプルの親ブロックのそれぞれ4分の1、半分、および4分の1の高さを有する、クロマサンプルの3個の子ブロックに分割する。

【0101】

図8は、閾値549のような閾値サイズより大きな符号化木ノードについて、符号化木547および／または613のような共通符号化木により、および、閾値サイズ以下のサイズを有する符号化木ノードについて、ルマ符号化部分木548、クロマ符号化部分木550および／または符号化部分木614のような分割部分木により、CTU541のようなCTUをパーティショニングする例示的な方法800のフローチャートである。方法800は、分割モード700のセットを利用することにより、メカニズム500を実施するために利用されてよい。方法800は、ビデオフレームからのサンプルを符号化ブロックにパーティショニングするために、方法100、コーデックシステム200、エンコーダシステム300、および／またはデコーダシステム400において利用できる。

【0102】

任意的ステップ801は、方法800がデコーダで利用されるとき、生じてよい。幾つかの例では、共通符号化木および分割ルマ／クロマ符号化部分木によるパーティショニングは任意である。このような例では、エンコーダは、luma_chroma_separateフラグを符号化できる。luma_chroma_separateフラグは、ルマ符号化ブロックおよびクロマ符号化ブロックのために別個の符号化部分木が利用されることを示すために(例えば1に)設定できる。luma_chroma_separateフラグは、ルマおよびクロマブロックが別個の符号化部分木を使用しないことを示すために未設定であり得る(例えば、0に設定される)。したがって、幾つかの例では、デコーダは、パーティショニングのために別個の符号化部分木が使用されるべきか否かを決定するために、ビットストリームからluma_chroma_separateフラグを取得／受信できる。luma_chroma_separateフラグがルマ符号化部分木とクロマ符号化部分木との間の分割を示すとき、デコーダは、luma_chroma_separateフラグの値に基づき、異なる符号化部分木によりルマサンプルおよびクロマサンプルをパーティショニングするよう準備できる。他の例では、方法800は、Iスライスの中の全てのCTUに適用される。このような例では、ルマサンプルおよびクロマサンプルは、符号化木単位がビデオフレーム内のIスライスに含まれるとき、異なる符号化部分木によりパーティショニングされる。このような場合には、ステップ801は、このような例において分割部分木の使用が暗黙的であるので、省略されてよい。

【0103】

ステップ803で、符号化木単位が取得される。上述のように、符号化木単位は、ルマサンプルおよびクロマサンプルの両方を含む。エンコーダで動作するとき、符号化木単位は、メモリから取得され、および／またはビデオフレームのスライスから取得される。デコーダで動作するとき、符号化木単位は、エンコーダから受信したビットストリームから取得される。

【0104】

ステップ805で、ルマサンプルおよびクロマサンプルは、閾値を超えるサイズを有する符号化木ノード(例えば、第1符号化木ノード)について、共通符号化木に従いパーティショニングされる。符号化木ノードサイズは、対応する符号化木ノードにおいて細分化されている現在符号化ブロックのサイズである。閾値は、シンタックスに格納される、または予め定められてよい。例えば、閾値は、4096ピクセル、2048ピクセル、1024ピクセル、等であってよい。留意すべきことに、ステップ805は、議論の明確さのために、ステップ807および809から分割される。例示的な実装では、ステップ805およびステップ807がルマサンプルに対して実行され、次に、ステップ805およびステップ809がクロマサンプルに対して実行される。したがって、ステップ順序は、議論の明確さのために含まれ、限定と考えられるべきではない。

【0105】

ステップ807で、閾値以下のサイズを有する符号化木ノード(例えば、第2符号化木ノード)に関連するルマサンプルは、ルマ符号化部分木によりパーティショニングされる。ステップ809で、閾値以下のサイズを有する符号化木ノード(例えば、第3符号化木ノード)に関連するクロマサンプルは、クロマ符号化部分木によりパーティショニングされる。ステップ807のルマ符号化部分木は、ステップ809のクロマ符号化部分木と異なるパーティショニングを含む。したがって、ルマブロックおよびクロマブロックの全体のパーティション(例えば、より大きな／親パーティション)は、ステップ805で共通符号化木を使用するために、同様である。しかしながら、ルマ符号化ブロックおよびクロマブロックのより小さい／子パーティションは異なり、クロマブロックは、符号化効率の向上のために、ルマ信号およびクロマ信号の差分に合わせることができる。これは、ステップ807のルマ符号化部分木とステップ809のクロマ符号化部分木との間の差分に起因する。留意すべきことに、クロマサンプルはCbサンプルとCrサンプルの両方を含んでよい。CbサンプルとCrサンプルは、ステップ809で共通クロマ符号化部分木によりパーティショニングされる。

【0106】

任意的ステップ811は、エンコーダまたはデコーダにおいて利用できる。方法800がエンコーダで動作するとき、パーティショニングの結果生じたルマ符号化ブロックおよびクロマ符号化ブロックは、例えば符号化単位として圧縮され、ビットストリームに符号化される。符号化木、ルマ符号化部分木、およびクロマ符号化部分木も、ビットストリームに符号化される。例えば、共通符号化木は、ビットストリーム内にTREE_L_Cとして符号化でき、ルマ符号化部分木はビットストリーム内にTREE_Lとして符号化でき、クロマ符号化部分木はビットストリーム内にTREE_Cとして符号化できる。ビットストリームは、次に、ビデオデコーダにおける表示のためにクロマ符号化ブロックおよびルマ符号化ブロックの再構成をサポートするために、デコーダへ向けて送信される。

【0107】

さらに、別個のルマ符号化部分木およびクロマ符号化部分木がエンコーダの裁量で選択される例では、ステップ811で、エンコーダは、デコーダにルマ符号化部分木とクロマ符号化部分木との間の分割を示すために、luma_chroma_separateフラグをビットストリームに(シンタックスとして)符号化できる。Iスライスからの全てのCTUに対して分割部分木が使用される場合には、luma_chroma_separateフラグは省略できる。

【0108】

方法800がデコーダで利用されるとき、デコーダは、ステップ811において、ルマブロックおよびクロマブロックを(例えば、イントラ予測またはインター予測により)再構成する。復号されたブロックは、次に、共通符号化木、ルマ符号化部分木、およびクロマ符号化部分木に基づき、ビデオフレームのスライスへと構成できる。スライスはビデオフレームへと配置でき、ビデオフレームは次にビデオシーケンスに含まれことができる。ビデオフレーム／ビデオシーケンスは、次に、エンドユーザに表示するためにディスプレイへ向けて転送される。

【0109】

以下の表1は、IスライスCTUについて分割符号化部分木の使用が暗黙的であるとき、方法800を実装するシンタックスの例である。
表1

【表1】

【0110】

Coding_tree_unitは、残りのコードが符号化木単位に特有であることを示す。スライスのタイプ(type_slice)がIスライスであり、qtbtt_dual_tree_intra_flagが設定されるとき、dual_tree_implicit_qt_split関数により示されるように、符号化木単位は分割符号化木を暗黙的に使用する。qtbtt_dual_tree_intra_flagは、Iスライスについて、各CTUが暗黙的4分木分割を用いて64×64ルマサンプルを有する符号化単位に分割されること、およびこれらの符号化単位がルマおよびクロマの2個の別個のcoding_quadtreeシンタックス構造のルートであること、を指定するために設定される。dual_tree_implicit_qt_split関数は、log2Cbsizeが6より大きいとき(例えば、4096ピクセル)、共通ルマ／クロマ符号化木(TREE_L_C状態として示される)を生成する関数を使用する。具体的に、符号化ブロックXは、子符号化ブロックに分割される。符号化ブロックXは、log2CbSizeとして示される、符号化ブロックXのサイズに基づき位置付けられた左上サンプル(x0,y0)および右下サンプル(x1,y1)の位置に基づき分割される。子符号化ブロックは、log2CbSize－1,のサイズであってよい。これは、符号化ブロックXのサイズの半分である。これは、符号化ブロックサイズがlog2で表現され、したがって、log2CbSize－1がlog2CbSizeの半分のサイズであるからである。dual_tree_implicit_qt_split関数は、条件チェックに依存して1～4回呼び出し可能な再帰的関数であり、結果として1～4個の子符号化ブロックを生じる。dual_tree_implicit_qt_split関数は先ず、子ブロックのサイズlog2CbSize－1および左上サンプル(x0,y0)に基づき呼び出されて、左上子符号化ブロックを生成する。右下サンプルx1の水平位置が、pic_width_in_luma_samplesにより示されるようにピクチャ内にある場合、dual_tree_implicit_qt_split関数は、子ブロックのサイズlog2CbSize－1および右上サンプル(x1,y0)に基づき呼び出されて、右上子符号化ブロックを生成する。左下サンプルy1の垂直位置が、pic_height_in_luma_samplesにより示されるようにピクチャ内にある場合、dual_tree_implicit_qt_split関数は、子ブロックのサイズlog2CbSize－1および左下サンプル(x0,y1)に基づき呼び出されて、左下子符号化ブロックを生成する。右下サンプルx1の水平位置および左下サンプルy1の垂直位置が、pic_width_in_luma_samplesおよびpic_height_in_luma_samplesにより示されるようにピクチャ内にある場合、dual_tree_implicit_qt_split関数は、子ブロックのサイズlog2CbSize－1および右下サンプル(x1,y1)に基づき呼び出されて、右下子符号化ブロックを生成する。例えば、右下サンプル(x1,y1)が、ピクチャの右境界または下境界の近くにある符号化ブロックXの位置により、ピクチャの外側で選択されると、4個より少ない子符号化ブロックが生成される(例えば、2個の子符号化ブロック)。その他の場合、4個の子符号化ブロックが生成される。dual_tree_implicit_qt_split関数は、親符号化ブロックのcqtDepthに基づき生成された各子符号化ブロックについて、4分木深さ(cqtDepth)をインクリメントすることにより、符号化木の現在深さを追跡する。

【0111】

log2Cbsize(符号化ブロックXのサイズ)が6より大きくない(例えば、その他)場合、ルマ符号化部分木(DUAL_TREE_LUMA)はルマブロックのために使用され、クロマ符号化部分木(DUAL_TREE_CHROMA)はクロマブロックのために使用される。具体的に、coding_quadtree関数が呼び出され、それぞれ、左上サンプル(x0,y0)、符号化ブロックサイズlog2CbSizeおよび対応するルマ符号化部分木またはクロマ符号化部分木DUAL_TREE_LUMAまたはDUAL_TREE_CHROMAに基づき符号化ブロックXを分割する。coding_quadtree関数も、上述のようにcqtDepth値を有する符号化ブロック深さを追跡する。

【0112】

以下の表2は、エンコーダについて分割符号化部分木の使用が自由裁量であるとき、方法800を実装するシンタックスの例である。
表2

【表2】

【0113】

表2で、coding_tree_node(x,y,w,h,tree_status)は、現在ノードのパーティショニング情報を記述するシンタックス構造である。ここで、xおよびyは、それぞれ現在ノードの左上角の座標であり、wおよびhは、それぞれ現在ノードの幅および高さであり、tree_statusは現在ノードの木状態である。別の例として、wおよびhはlog2(w)およびlog2(h)により置き換えることもできることに留意する。同様に、coding_unit(x,y,w,h,tree_status)は、予測情報、変換情報、等のような符号化単位情報を記述するシンタックス構造である。左の列で、ae(v)は、シンタックス要素がコンテキスト適応型2進算術符号化(Context－Adaptive Binary Arithmetic Coding(CABAC))により符号化されることを示す。

【0114】

現在ノードのtree_statusがTREE_L_Cであり、ノードが閾値Tより大きいとき、ノードはTREE_L_C状態を使用する。この場合、luma_chorma_separateフラグは、ビットストリーム内に存在せず、その値は0として導出される。現在ノードのtree_statusがTREE_L_Cであり、ノードが閾値Tより大きいとき、luma_chroma_separateフラグはビットストリーム内でシグナリングされる。Tree_statusがTREE_L_Cではないとき、luma_chroma_separateフラグは0として導出される。

【0115】

luma_chroma_separateが0のとき、(シンタックス要素split_modeにより示されるように)1つの分割モードのみがパースされる。分割モードに従い、ノードは、CUとして決定され、またはN個の子ノードに分割される。ここで、derive_child_node(split_mode,N,x_c,y_c,w_c,h_c)は、N個の子ノードの座標、幅、および高さを分割モードに基づき導出する処理を示す。子ノードは、現在ノードの木状態を受け継ぐ。

【0116】

luma_chroma_separateが1のとき、現在ノードの中のルマブロックおよびクロマブロックのパーティショニングは分離され、(シンタックス要素split_modeおよびsplit_mode_2ndにより示されるように)2個の分割モードがパースされる。一方の分割モードはルマブロックをパーティショニングするために使用され、他方は2個のクロマブロックをパーティショニングするために使用される。ルマブロックの子ノードの木状態はTREE_Lに変更され、一方で、クロマブロックの子ノードの木状態はTREE_Cに変更される。木状態も、ルマブロックおよび／または2個のクロマブロックが符号化単位に含まれるか否かを示すために、符号化単位に渡される。

【0117】

図9は、例示的なビデオ符号化装置900の概略図である。ビデオ符号化装置900は、ここに説明したような開示の例／実施形態を実施するのに適する。ビデオ符号化装置900は、ダウンストリームポート920、アップストリームポート950、および／または、ネットワークを介してデータアップストリームおよび／またはダウンストリームを通信する送信機および／または受信機を含むトランシーバユニット(Tx/Rx)910を含む。ビデオ符号化装置900は、データを処理する論理ユニットおよび／または中央処理ユニット(central processing unit(CPU))を含むプロセッサ930、およびデータを格納するメモリ932も含む。ビデオ符号化装置900は、光－電気(optical－to－electrical(OE))コンポーネント、電気－光(electrical－to－optical(EO))コンポーネント、および／または、光または無線通信ネットワークを介するデータの通信のためにアップストリームポート950および／またはダウンストリームポート920に結合される無線通信コンポーネント、も含んでよい。ビデオ符号化装置900は、データをユーザにおよびユーザから通信する入力および／または出力(input and/or output(I/O))装置960も含んでよい。I/O装置960は、ビデオデータを表示するディスプレイ、オーディオデータを出力するスピーカ、等のような出力装置を含んでよい。I/O装置960は、キーボード、マウス、トラックボール、等のような入力装置、および／または、そのような出力装置とインタフェースする対応するインタフェースも含んでよい。

【0118】

プロセッサ930は、ハードウェアおよびソフトウェアにより実装される。プロセッサ930は、1つ以上のCPUチップ、コア(例えば、マルチコアプロセッサ)、フィールドプログラマブルゲートアレイ(field－programmable gate array(FPGA))、特定用途向け集積回路(application specific integrated circuit (ASIC))、およびデジタル信号プロセッサ(digital signal processor(DSP))として実装されてよい。プロセッサ930は、ダウンストリームポート920、Tx/Rx910、アップストリームポート950、およびメモリ932と通信する。プロセッサ930は、符号化モジュール914を含む。符号化モジュール914は、符号化木600、分割モード700のセット、および／またはここに記載した任意の他の方法／メカニズムを利用する、方法100および800並びにメカニズム500のような上述の開示の実施形態を実装する。さらに、符号化モジュール914は、コーデックシステム200、エンコーダ300、および／またはデコーダ400を実装してよい。例えば、符号化モジュール914は、符号化木単位をパーティショニングするために利用できる。具体的に、符号化モジュール914は、閾値より大きいブロック内のルマサンプルおよびクロマサンプルに共通符号化木を適用できる。符号化モジュール914は閾値以下のサイズのルマブロックおよびクロマブロックにそれぞれ異なるルマ符号化部分木およびクロマ符号化部分木を適用することもできる。したがって、符号化モジュール914は、ビデオ符号化装置900に、より高い符号化効率で動作させ、および／またはより少ない処理リソースを用いて符号化木単位をパーティショニングさせる。したがって、符号化モジュール914は、ビデオ符号化装置900の機能を向上し、並びに、ビデオ符号化技術に特有の問題を解決する。さらに、符号化モジュール914は、ビデオ符号化装置900の異なる状態への変換を実施する。代替として、符号化モジュール914は、メモリ932に格納されプロセッサ930により実行される命令として(例えば、非一時的媒体に格納されたコンピュータプログラムプロダクトとして)実装できる。

【0119】

メモリ932は、ディスク、テープドライブ、個体ドライブ、読み出し専用メモリ(read only memory(ROM))、ランダムアクセスメモリ(random access memory(RAM))、フラッシュメモリ、三値連想メモリ(ternary content－addressable memory(TCAM))、静的ランダムアクセスメモリ(static random－access memory (SRAM))、等のような1つ以上のメモリ種類を含む。メモリ932は、プログラムが実行のために選択されるとき該プログラムを格納するため、およびプログラムの実行中に読み出される命令およびデータを格納するための、オーバフローデータ記憶装置として使用されてよい。

【0120】

図10は、閾値サイズより上の符号化ブロックについて共通符号化木により、閾値サイズ以下のサイズの符号化ブロックについて分割部分木により、CTUをパーティショニングする例示的なシステム1000の概略図である。システム1000は、動作方法100、メカニズム500、方法800、コーデックシステム200、エンコーダ300、デコーダ400、および／またはビデオ符号化装置900を実装できる、ビデオエンコーダ1002およびビデオデコーダ1010を含む。さらに、ビデオエンコーダ1002およびビデオデコーダ1010は、分割モード700のセットを利用することにより、符号化木613および符号化部分木614によりパーティショニングを実行できる。

【0121】

ビデオエンコーダ1002は、符号化木ノードを含む符号化木単位を取得するフェッチモジュール1001を含む。ビデオ符号化装置は、第1符号化木ノードが閾値を超えるときルマサンプルおよびクロマサンプルを共通符号化木によりパーティショニングする共通木パーティショニングモジュール1003も含む。ビデオ符号化装置は、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の第2符号化木ノードの中のルマサンプルをルマ符号化部分木によりパーティショニングするルマ符号化部分木パーティショニングモジュール1005も含む。ビデオ符号化装置は、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の第2符号化木ノードの中のクロマサンプルをクロマ符号化部分木によりパーティショニングするクロマ符号化部分木パーティショニングモジュール1007も含む。上述のように、ルマ符号化部分木は、クロマ符号化部分木と異なるパーティショニング、およびしたがって異なる分割モードを含み得る。クロマサンプルおよびルマサンプルは、共通符号化木、ルマ符号化部分木、およびクロマ符号化部分木に基づき、ビットストリームに符号化される。ビデオエンコーダ1002は、ビデオデコーダ1010における表示のためにクロマサンプルおよびルマサンプルの再構成をサポートするために、ビットストリームを送信する送信機1009も含む。

【0122】

ビデオデコーダ1010は、ルマデータおよびクロマデータを含む符号化木単位を含むビットストリームを受信する受信機1017を含む。ビデオデコーダ1010は、符号化木ノードを含む符号化木単位を取得するフェッチモジュール1011も含む。ビデオデコーダ1010は、第1符号化木ノードが閾値を超えるときルマデータおよびクロマデータを共通符号化木によりパーティショニングする共通木パーティショニングモジュール1013も含む。ビデオデコーダ1010は、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の第2符号化木ノードの中のルマデータをルマ符号化部分木によりパーティショニングするルマ部分木パーティショニングモジュール1015も含む。ビデオデコーダ1010は、第2符号化木ノードのサイズが閾値以下であるとき符号化木単位の第2符号化木ノードの中のクロマデータをクロマ符号化部分木によりパーティショニングするクロマ部分木パーティショニングモジュール1019も含む。上述のように、ルマ符号化部分木は、クロマ符号化部分木と異なるパーティショニング、およびしたがって異なる分割モードを含む。ビデオデコーダ1010は、次に、共通符号化木、ルマ符号化部分木、およびクロマ符号化部分木に基づき、クロマデータおよびルマデータをビデオフレームのスライスへと再構成できる。ビデオデコーダ1010は、また、ビデオフレームをディスプレイへ向けて転送できる。

【0123】

図11は、閾値549のような閾値サイズより上のCBについて、符号化木547および／または613のような共通符号化木により、および、閾値サイズ以下のサイズを有するCBについて、ルマ符号化部分木548、クロマ符号化部分木550および／または符号化部分木614のような分割部分木により、CTU541のようなCTUをパーティショニングする例示的な方法1100のフローチャートである。方法1100は、分割モード700のセットを利用することにより、メカニズム500を実施するために利用されてよい。方法1100は、ビデオフレームからのサンプルを符号化ブロックにパーティショニングするために、方法100、コーデックシステム200、エンコーダシステム300、および／またはデコーダシステム400において利用できる。

【0124】

方法1100は、ステップ1101で、符号化木単位がIスライス内にあると決定するステップを含む。例えば、デコーダは、ルマサンプルおよびクロマサンプルを含む符号化木単位をルマブロックおよびクロマブロックにそれぞれパーティショニングするために適用されるべき分割モードについて、符号化木、ルマ符号化部分木、および／またはクロマ符号化部分木をパースできる。方法1100は、次に、符号化木単位がビデオフレームのIスライスに含まれる場合／とき、適用されてよい。

【0125】

ステップ1103で、符号化木の第1符号化木ノードが閾値より大きいサイズを有するとき、第1符号化木ノードに関連するルマサンプルの符号化ブロックおよびクロマサンプルの符号化ブロックは、共通符号化木により分割される。例えば、閾値は、4096ルマサンプルまたは2048ルマサンプルであってよい。分割モードは、符号化木ノードが閾値より大きいサイズを有するとき、4分木分割であってよい。幾つかの例では、分割モードは、符号化木ノードが閾値より大きいサイズを有するとき、暗黙的にシグナリングできる。

【0126】

ステップ1107で、符号化木の第2符号化木ノードが閾値以下のサイズを有するとき、符号化木単位の且つ第2符号化木ノードに関連するルマサンプルの符号化ブロックは、ルマ符号化木に従い分割できる。ルマ符号化部分木は、幾つかのコンテキストではルマ符号化木とも呼ばれてよい。さらに、符号化木の第2符号化木ノードが閾値以下のサイズを有するとき、符号化木単位の且つ第2符号化木ノードに関連するクロマサンプルの符号化ブロックは、クロマ符号化木に従い分割できる。留意すべきことに、YUV4:2:0データでは、64×64ルマ符号化ブロックは、32×32Cbクロマ符号化ブロックおよび32×32Crクロマ符号化ブロックに対応する。しかしながら、符号化木ノードのサイズを示すとき、符号化木ノードはルマサンプルを用いて測定されてよい。例えば、2個の32×32クロマブロックのみを含む符号化木ノードは、サイズ64×64の符号化木ノードとして測定されてよい。

【0127】

方法1100は、以下のシンタックスに従い実装できる。

【数1】

閾値がlog2CbSize>6により表される場合、DUAL_TREE_LUMAはルマ符号化木を示し、DUAL_TREE_CHROMAはクロマ符号化木を示す。

【0128】

第1コンポーネントと第2コンポーネントとの間に線、トレース、または別の媒体を除き仲介コンポーネントが存在しないとき、第1コンポーネントは、第2コンポーネントに直接的に結合される。第1コンポーネントと第2コンポーネントとの間に線、トレース、または別の媒体以外の仲介コンポーネントが存在するとき、第1コンポーネントは、第2コンポーネントに間接的に結合される。用語「結合される」およびその変形は、直接的結合および間接的結合の両方を含む。用語「約」の使用は、特に断りのない限り、後続の数値の±10％を含む範囲を意味する。

【0129】

本発明の例は、説明のためであり限定的ではないと考えられるべきであり、ここに与えられた詳細事項に限定されることを意図しない。例えば、種々の要素またはコンポーネントは、結合され、または別のシステムに統合されてよく、或いは、特定の特徴は、省略されまたは実施されなくてよい。

【0130】

さらに、種々の実施形態において個別または別個として説明され示された技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、コンポーネント、技術、または方法と結合されまたは統合されてよい。

【0131】

本発明は、以下の実施形態も提供する。

【0132】

実施形態1。ビデオ符号化装置において実施される方法であって、前記方法は、
前記ビデオ符号化装置のプロセッサにより、符号化木ノードを含む符号化木単位を取得するステップと、
前記プロセッサにより、第1符号化木ノードのサイズが閾値を超えるとき、共通符号化木に従い、前記符号化木単位の前記第1符号化木ノードの中のルマサンプルおよびクロマサンプルをパーティショニングするステップと、
前記プロセッサにより、第2符号化木ノードのサイズが前記閾値以下であるとき、ルマ符号化部分木により前記符号化木単位の前記第2符号化木ノードの中の前記ルマサンプルをパーティショニングするステップと、
前記プロセッサにより、第2符号化木ノードの前記サイズが前記閾値以下であるとき、クロマ符号化部分木により前記符号化木単位の前記第2符号化木ノードの中の前記クロマサンプルをパーティショニングするステップと、
を含む方法。

【0133】

実施形態2。前記閾値は、4096ピクセル、または2を基数とする対数領域の6である、実施形態1に記載の方法。

【0134】

実施形態3。前記符号化木単位は、イントラ予測(Ｉ)ピクチャ／フレーム内にある、実施形態1乃至2のいずれかに記載の方法。

【0135】

実施形態4。クロマサンプルは青色差分クロマ(Cb)サンプルおよび赤色差分クロマ(Cr)サンプルを含み、前記CbサンプルおよびCrサンプルは、共通クロマ符号化部分木によりパーティショニングされる、実施形態1乃至3のいずれかに記載の方法。

【0136】

実施形態5。前記ビデオ符号化装置はエンコーダであり、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示すluma_chroma_separateフラグをビットストリーム内に符号化するステップ、を更に含む実施形態1乃至4のいずれかに記載の方法。

【0137】

実施形態6。前記ビデオ符号化装置はデコーダであり、ビットストリームからluma_chroma_separateフラグを受信するステップであって、前記luma_chroma_separateフラグは、前記ルマ符号化部分木と前記クロマ符号化部分木との間の分割を示し、前記ルマサンプルおよびクロマサンプルは、前記luma_chroma_separateフラグの値に基づき別個の符号化部分木によりパーティショニングされる、ステップ、を更に含む実施形態1乃至4のいずれかに記載の方法。

【0138】

実施形態7。ビデオ符号化装置による使用のためのコンピュータプログラムプロダクトを含む非一時的コンピュータ可読媒体であって、前記コンピュータプログラムプロダクトは、プロセッサにより実行されると前記ビデオデコーダに実施形態1乃至6のいずれかに記載の方法を実行させる、前記非一時的コンピュータ可読媒体に記憶されたコンピュータ実行可能命令を含む、非一時的コンピュータ可読媒体。

【0139】

実施形態8。ビデオ符号化装置であって、
符号化木ノードを含む符号化木単位を取得するフェッチ手段と、
第1符号化木ノードのサイズが閾値を超えるとき、共通符号化木に従い、前記符号化木単位の前記第1符号化木ノードの中のルマサンプルおよびクロマサンプルをパーティショニングする共通木パーティショニング手段と、
第2符号化木ノードのサイズが前記閾値以下であるとき、ルマ符号化部分木により前記符号化木単位の前記第2符号化木ノードの中の前記ルマサンプルをパーティショニングするルマ符号化部分木パーティショニング手段と、
第2符号化木ノードの前記サイズが前記閾値以下であるとき、クロマ符号化部分木により前記符号化木単位の前記第2符号化木ノードの中の前記クロマサンプルをパーティショニングするクロマ符号化部分木パーティショニング手段と、
を含むビデオ符号化装置。

【0140】

実施形態9。前記フェッチ手段、前記共通木パーティショニング手段、前記ルマ部分木パーティショニング手段、および前記クロマ部分木パーティショニング手段は、さらに実施形態1乃至6のいずれかに記載の方法を実行するためのものである、実施形態8に記載の符号化装置。

【0141】

実施形態10。方法であって、
符号化木単位がイントラ予測(I)ピクチャ／フレーム内にあることを決定するステップと、
前記符号化木単位に対応する符号化木の第1符号化木ノードが閾値より大きいサイズを有するとき、前記第1符号化木ノードに関連するルマサンプルの符号化ブロックおよびクロマサンプルの符号化ブロックを、共通符号化木により分割するステップと、
前記符号化木の第2符号化木ノードが前記閾値以下であるサイズを有するとき、前記第2符号化木ノードに関連するルマサンプルの符号化ブロックをルマ符号化木により分割し、前記第2符号化木ノードに関連するクロマサンプルの符号化ブロックをクロマ符号化木により分割するステップと、
を含む方法。

【0142】

実施形態11。前記閾値は、4096ルマサンプル、または2048ルマサンプルである、実施形態10に記載の方法。

【0143】

実施形態12。前記共通符号化木は4分木分割である、実施形態10乃至11のいずれかに記載の方法。

【0144】

実施形態13。前記第1符号化木ノードの分割モードは、前記符号化木ノードが閾値より大きいサイズを有するとき、暗に示される、実施形態10乃至12のいずれかに記載の方法。

【0145】

実施形態14。前記サイズは、log2CbSizeにより表され、前記閾値は6に等しい、実施形態10乃至13のいずれかに記載の方法。

【0146】

実施形態15。ビデオ符号化装置であって、
プロセッサを含み、前記プロセッサは、
符号化木単位がイントラ予測(I)ピクチャ／フレーム内にあることを決定し、
前記符号化木単位に対応する符号化木の第1符号化木ノードが閾値より大きいサイズを有するとき、前記第1符号化木ノードに関連するルマサンプルの符号化ブロックおよびクロマサンプルの符号化ブロックを、共通符号化木により分割し、
前記符号化木の第2符号化木ノードが前記閾値以下であるサイズを有するとき、前記第2符号化木ノードに関連するルマサンプルの符号化ブロックをルマ符号化木により分割し、前記第2符号化木ノードに関連するクロマサンプルの符号化ブロックをクロマ符号化木により分割する、
よう構成される、ビデオ符号化装置。

【0147】

実施形態16。前記閾値は、4096ルマサンプル、または2048ルマサンプルである、実施形態15に記載のビデオ符号化装置。

【0148】

実施形態17。前記共通符号化木は4分木分割である、実施形態15乃至16のいずれかに記載のビデオ符号化装置。

【0149】

実施形態18。前記第1符号化木ノードの分割モードは、前記符号化木ノードが閾値より大きいサイズを有するとき、暗に示される、実施形態15乃至17のいずれかに記載のビデオ符号化装置。

【0150】

実施形態19。前記サイズは、log2CbSizeにより表され、前記閾値は6に等しい、実施形態15乃至18のいずれかに記載のビデオ符号化装置。

【符号の説明】

【0151】

５４０ スライス
５４１ CTU
５４７ 符号化木
５４８ ルマ符号化部分木
５４９ 閾値
５５０ クロマ符号化部分木

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】