IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ クゥアルコム・インコーポレイテッドの特許一覧

特開2022-50614ビデオコード化のためのマルチタイプツリーフレームワーク
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022050614
(43)【公開日】2022-03-30
(54)【発明の名称】ビデオコード化のためのマルチタイプツリーフレームワーク
(51)【国際特許分類】
   H04N 19/70 20140101AFI20220323BHJP
   H04N 19/96 20140101ALI20220323BHJP
【FI】
H04N19/70
H04N19/96
【審査請求】有
【請求項の数】1
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022003573
(22)【出願日】2022-01-13
(62)【分割の表示】P 2018536795の分割
【原出願日】2017-01-13
(31)【優先権主張番号】62/279,233
(32)【優先日】2016-01-15
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/404,634
(32)【優先日】2017-01-12
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】595020643
【氏名又は名称】クゥアルコム・インコーポレイテッド
【氏名又は名称原語表記】QUALCOMM INCORPORATED
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100158805
【弁理士】
【氏名又は名称】井関 守三
(74)【代理人】
【識別番号】100112807
【弁理士】
【氏名又は名称】岡田 貴志
(72)【発明者】
【氏名】シャン・リ
(72)【発明者】
【氏名】リ・ジャン
(72)【発明者】
【氏名】ウェイ-ジュン・チェン
(72)【発明者】
【氏名】ジャンレ・チェン
(72)【発明者】
【氏名】シン・ジャオ
(72)【発明者】
【氏名】マルタ・カルチェビチ
(57)【要約】      (修正有)
【課題】マルチタイプツリー(MTT)区分化を使用することで大きなコード化効率を可能にするビデオデータ復号方法及び符号化方法を提供する。
【解決手段】ビデオデータを復号する方法は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、ビデオデータのコード化されたピクチャを区分化することと、ビデオデータのコード化されたピクチャの複数のブロックを再構築することと、を含む。ビデオデータのコード化されたピクチャを区分化することは、3つ以上の異なる区分構造を使用して複数のブロックへとビデオデータのコード化されたピクチャを区分化することを含む。ここにおいて、3つ以上の異なる区分構造のうちの少なくとも3つは、ビデオデータのコード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の各深度において使用される。
【選択図】図11
【特許請求の範囲】
【請求項1】
ビデオデータを復号する方法であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を備える、方法。
【請求項2】
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することを備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
請求項1に記載の方法。
【請求項3】
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
請求項2に記載の方法。
【請求項4】
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
請求項3に記載の方法。
【請求項5】
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
請求項4に記載の方法。
【請求項6】
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
をさらに備える、請求項1に記載の方法。
【請求項7】
前記シンタックス要素を受信することは、前記ビットストリームから前記シンタックス要素を受信することを備え、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を受信することを含む、
請求項6に記載の方法。
【請求項8】
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの2つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの区分化を決定することと
をさらに備える、請求項1に記載の方法。
【請求項9】
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、
前記ビットストリームからシンタックス要素を受信すること、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに1つまたは複数の変換を適用することと
をさらに備える、請求項1に記載の方法。
【請求項10】
ビデオデータを符号化する方法であって、
前記ビデオデータのピクチャを受信することと、
3つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを複数のブロックへと区分化することと、
前記ビデオデータの前記ピクチャの前記複数のブロックを符号化することと
を備える、方法。
【請求項11】
前記ビデオデータの前記ピクチャを区分化することは、前記3つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを前記複数のブロックに区分化することを備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記ピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
請求項10に記載の方法。
【請求項12】
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用して前記ビデオデータの前記特定のブロックを区分化することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
請求項11に記載の方法。
【請求項13】
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
請求項12に記載の方法。
【請求項14】
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
請求項13に記載の方法。
【請求項15】
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームにおいて、生成すること
をさらに備える、請求項10に記載の方法。
【請求項16】
前記シンタックス要素を生成することは、ビットストリームから前記シンタックス要素を生成することを備え、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を生成することを含む、
請求項15に記載の方法。
【請求項17】
前記ビデオデータの前記ピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を生成することと、
前記特定のブロックの2つのサブブロックが同じサイズを有するように、前記ビデオデータの前記ピクチャの前記特定のブロックを区分化することと
をさらに備える、請求項10に記載の方法。
【請求項18】
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、
ビットストリームにおいてシンタックス要素を生成すること、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記ピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のビデオより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、前記ビデオデータの前記特定のブロックの前記残差データに1つまたは複数の変換を適用することと
をさらに備える、請求項10に記載の方法。
【請求項19】
ビデオデータを復号するように構成された装置であって、
前記ビデオデータを記憶するように構成されたメモリと、
ビデオ復号回路と
を備え、前記ビデオ復号回路は、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を行うように構成される、装置。
【請求項20】
前記ビデオ復号回路は、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するようにさらに構成され、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
請求項19に記載の装置。
【請求項21】
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記ビデオ復号回路は、前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するようにさらに構成され、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
請求項20に記載の装置。
【請求項22】
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
請求項21に記載の装置。
【請求項23】
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
請求項22に記載の装置。
【請求項24】
前記ビデオ復号回路は、
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
を行うようにさらに構成される、請求項19に記載の装置。
【請求項25】
前記ビデオ復号回路は、前記ビットストリームから前記シンタックス要素を受信するようにさらに構成され、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を受信することを含む、
請求項24に記載の装置。
【請求項26】
前記ビデオ復号回路は、
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの2つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの前記区分化を決定することと
を行うようにさらに構成される、請求項19に記載の装置。
【請求項27】
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記ビデオ復号回路は、
ビットストリームからシンタックス要素を受信することと、ここで、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに1つまたは複数の変換を適用することと
を行うようにさらに構成される、請求項19に記載の装置。
【請求項28】
ビデオデータを復号するように構成された装置であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信するための手段と、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定するための手段と、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築するための手段と
を備える装置。
【請求項29】
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための前記手段は、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための手段を備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
請求項28に記載の装置。
【請求項30】
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記装置は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するための手段をさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
請求項29に記載の装置。
【発明の詳細な説明】
【関連出願】
【0001】
[0001]本願は、2016年1月15日に出願された米国仮特許出願第62/279,233号の利益を主張し、この全内容は、参照によりここに組み込まれる。
【技術分野】
【0002】
[0002]本開示は、ビデオ符号化およびビデオ復号に関する。
【背景技術】
【0003】
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲーム機、セルラ式または衛星無線電話、いわゆる「スマートフォン」、ビデオテレビ会議デバイス、ビデオストリーミングデバイス、および同様のものを含む、広範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4,パート10,アドバンスドビデオコーディング(AVC)によって定義されている規格、高効率ビデオコーディング(HEVC)規格、およびそのような規格の拡張で説明されているもののようなビデオコーディング技法をインプリメントする。ビデオデバイスは、そのようなビデオコーディング技法をインプリメントすることで、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および/または記憶し得る。
【0004】
[0004]ビデオコーディング技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間(イントラピクチャ)予測および/または時間(インターピクチャ)予測を含む。ブロックベースのビデオコード化の場合、ビデオスライス(例えば、ビデオピクチャ/フレームまたはビデオピクチャの一部)は、ツリーブロック、コード化単位(CU)および/またはコード化ノードとも呼ばれ得る、ビデオブロックへと区分化され得る。ピクチャは、フレームと呼ばれ得る。参照ピクチャは、参照フレームと呼ばれ得る。
【0005】
[0005]空間または時間予測は、コード化されることとなるブロックについての予測ブロックをもたらす。残差データは、コード化されることとなる元のブロックと予測ブロックとの間の画素差を表す。さらなる圧縮のために、残差データが画素ドメインから変換ドメインに変換され得、これは、残差変換係数をもたらし、これは、その後、量子化され得る。エントロピーコード化は、さらなる圧縮を達成するために適用され得る。
【発明の概要】
【0006】
[0006]本開示は、マルチタイプツリー(MTT)フレームワークを使用してビデオデータのブロックを区分化するための技法を説明する。本開示の技法は、ツリー構造の様々なノードにおいて複数の区分化技法のうちの1つを決定することを含む。複数の区分化技法の例には、ブロックの中心を通ってブロックを対称的に分割する区分化技法に加え、ブロックの中心が分割されないようにブロックを対称的にまたは非対称的に分割する区分化技法が含まれ得る。このように、ビデオブロックの区分化は、より効率的なコード化につながる方法で実行されることができ、これは、ブロックの中心にあるビデオデータ中のオブジェクトをより良好にキャプチャする区分化を含む。
【0007】
[0007]本開示は、ビデオデータの特定のピクチャがどのように区分化されるかを示すシンタックス要素をシグナリングするための技法をさらに説明する。ブロック区分化は一般に、ビデオデータのピクチャがどのように様々なサイズのブロックへと分割、そして再分割、されるかを説明する。ビデオデコーダは、ブロック区分化を再構築するためにそのようなシンタックス要素を使用し得る。本開示の他の例は、本開示のMTT区分化技法を使用して、区分化されたビデオデータのブロックに対して変換を実行することを対象としている。
【0008】
[0008]本開示の一例では、ビデオデータを復号する方法は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定することと、ビデオデータのフレームの複数のブロックを再構築することとを備える。
【0009】
[0009]本開示の別の例では、ビデオデータを符号化する方法は、ビデオデータのピクチャを受信することと、3つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化することと、ビデオデータのピクチャの複数のブロックを符号化することとを備える。
【0010】
[0010]本開示の別の例では、ビデオデータを復号するように構成された装置は、ビデオデータを記憶するように構成されたメモリと、ビデオデータのピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定することと、ビデオデータのフレームの複数のブロックを再構築することとを行うように構成されたビデオ復号回路とを備える。
【0011】
[0011]本開示の別の例では、ビデオデータを復号するように構成された装置は、ビデオデータのコード化されたピクチャを形成するビットのシーケンスを含むビットストリームを受信するための手段と、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定するための手段と、ビデオデータのフレームの複数のブロックを再構築するための手段とを備える。
【0012】
[0012]1つまたは複数の例の詳細は、添付の図面および以下の説明で示される。他の特徴、目的、および利点は、本説明、図面、および請求項から明らかになるであろう。
【図面の簡単な説明】
【0013】
図1図1は、本開示の技法をインプリメントするように構成された例となるビデオ符号化および復号システムを例示するブロック図である。
図2図2は、高効率ビデオコーディング(HEVC)におけるコード化単位(CU)構造を例示する概念図である。
図3図3は、インター予測モードの場合の例となる区分タイプを例示する概念図である。
図4A図4Aは、四分木二分木(QTBT)構造を使用したブロック区分化の例を例示する概念図である。
図4B図4Bは、図4AのQTBT構造を使用したブロック区分化に対応する例となるツリー構造を例示する概念図である。
図5A図5Aは、例となる水平三分木区分タイプを例示する概念図である。
図5B図5Bは、例となる水平三分木区分タイプを例示する概念図である。
図6A図6Aは、四分木区分化を例示する概念図である。
図6B図6Bは、垂直二分木区分化を例示する概念図である。
図6C図6Cは、水平二分木区分化を例示する概念図である。
図6D図6Dは、垂直センタ-サイド木区分化を例示する概念図である。
図6E図6Eは、水平センタ-サイド木区分化を例示する概念図である。
図7図7は、本開示技法に係る、コード化ツリー単位(CTU)区分化の例を例示する概念図である。
図8図8は、ビデオエンコーダの例を例示するブロック図である。
図9図9は、ビデオデコーダの例を例示するブロック図である。
図10A図10Aは、本開示の技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。
図10B図10Bは、本開示の技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。
図11図11は、本開示の別の例となる技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。
図12図12は、本開示の別の例となる技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。
【発明の詳細な説明】
【0014】
[0032]本開示は、ブロックベースのビデオコード化におけるビデオデータのブロックの区分化および/または編成(例えば、コード化単位)に関する。本開示の技法は、ビデオコーディング規格において適用され得る。以下で説明する様々な例では、本開示の技法は、3つ以上の異なる区分構造を使用してビデオデータのブロックを区分化することを含む。いくつかの例では、3つ以上の異なる区分構造が、コード化ツリー構造の各深度で使用され得る。そのような区分化技法は、マルチタイプツリー(MTT)区分化と呼ばれ得る。MTT区分化を使用することで、ビデオデータは、より柔軟に区分化され得るため、より大きなコード化効率を可能にする。
【0015】
[0033]図1は、ビデオデータのブロックを区分化することと、区分タイプをシグナリングおよび解析することと、変換およびさらなる変換区分を適用することとを行うための本開示の技法を利用し得る例となるビデオ符号化および復号システム10を例示するブロック図である。図1に示されるように、システム10は、宛先デバイス14によって後の時間に復号されることとなる符号化されたビデオデータを供給するソースデバイス12を含む。特に、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを供給する。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、タブレットコンピュータ、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイス、または同様のものを含む、広範囲のデバイスのうちの任意のものを備え得る。いくつかのケースでは、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備され得る。ゆえに、ソースデバイス12および宛先デバイス14は、ワイヤレス通信デバイスであり得る。ソースデバイス12は、例となるビデオ符号化デバイス(すなわち、ビデオデータを符号化するためのデバイス)である。宛先デバイス14は、例となるビデオ復号デバイス(例えば、ビデオデータを復号するためのデバイスまたは装置)である。
【0016】
[0034]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオデータを記憶するように構成された記憶媒体20と、ビデオエンコーダ22と、出力インターフェース24とを含む。宛先デバイス14は、入力インターフェース26と、符号化されたビデオデータを記憶するように構成された記憶媒体28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。他の例では、ソースデバイス12および宛先デバイス14は、他の構成要素または配列を含む。例えば、ソースデバイス12は、外部カメラのような外部ビデオソースからビデオデータを受信し得る。同様に、宛先デバイス14は、統合されたディスプレイデバイスを含むよりむしろ外部ディスプレイデバイスとインターフェース接続し得る。
【0017】
[0035]図1の例示されるシステム10は一例に過ぎない。ビデオデータを処理するための技法は、任意のデジタルビデオ符号化および/または復号デバイスあるいは装置によって実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスおよびビデオ復号デバイスによって実行されるが、本技法は、典型的に「CODEC」と呼ばれる複合ビデオエンコーダ/デコーダによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14への送信のために符号化されたビデオデータを生成するそのようなコード化デバイスの例に過ぎない。いくつかの例では、ソースデバイス12および宛先デバイス14は、ソースデバイス12および宛先デバイス14の各々がビデオ符号化および復号構成要素を含むような略対称的な方法で動作する。それゆえに、システム10は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ソースデバイス12と宛先デバイス14との間での単方向または双方向のビデオ送信をサポートし得る。
【0018】
[0036]ソースデバイス12のビデオソース18は、ビデオカメラのようなビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオデータを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてコンピュータグラフィックベースのデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。ソースデバイス12は、ビデオデータを記憶するように構成された1つまたは複数のデータ記憶媒体(例えば、記憶媒体20)を備え得る。本開示で説明される技法は一般に、ビデオコード化に適用可能であり得、ワイヤレスおよび/またはワイヤードアプリケーションに適用され得る。いずれのケースでも、キャプチャされた、前にキャプチャされた、またはコンピュータ生成されたビデオは、ビデオエンコーダ22によって符号化され得る。出力インターフェース24は、符号化されたビデオ情報をコンピュータ可読媒体16に出力し得る。
【0019】
[0037]宛先デバイス14は、コンピュータ可読媒体16を介して、復号されることとなる符号化されたビデオデータを受信し得る。コンピュータ可読媒体16は、符号化されたビデオデータをソースデバイス12から宛先デバイス14に移動させる能力がある任意のタイプの媒体またはデバイスを備え得る。いくつかの例では、コンピュータ可読媒体16は、ソースデバイス12が符号化されたビデオデータをリアルタイムに直接宛先デバイス14に送信することを可能にするための通信媒体を備える。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理伝送線のような任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットのようなグローバルネットワークといった、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするのに有益であり得る任意の他の機器を含み得る。宛先デバイス14は、符号化されたビデオデータおよび復号されたビデオデータを記憶するように構成された1つまたは複数のデータ記憶媒体を備え得る。
【0020】
[0038]いくつかの例では、符号化されたデータ(例えば、符号化されたビデオデータ)は、出力インターフェース24から記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェース26によって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、DVD、CD-ROM、フラッシュメモリ、揮発性または非揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような様々な分散型または局所的にアクセスされるデータ記憶媒体のうちの任意のものを含み得る。さらなる例では、記憶デバイスは、ファイルサーバ、またはソースデバイス12によって生成された符号化されたビデオを記憶し得る別の中間記憶デバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、記憶デバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶するおよび符号化されたビデオデータを宛先デバイス14に送信する能力がある任意のタイプのサーバであり得る。例となるファイルサーバは、(例えば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続記憶(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準的なデータ接続を通して、符号化されたビデオデータにアクセスし得る。これは、ワイヤレスチャネル(例えば、Wi-Fi接続)、ワイヤード接続(例えば、DSL、ケーブルモデム、等)、またはファイルサーバに記憶されている符号化されたビデオデータにアクセスするのに適切な両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【0021】
[0039]本開示の技法は、無線テレビ放送、ケーブルテレビ送信、衛星テレビ送信、HTTPを介した動的適応型ストリーミング(DASH)のようなインターネットストリーミングビデオ送信、データ記憶媒体上で符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、様々なマルチメディアアプリケーションのうちの任意のものをサポートして、ビデオコード化に適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、および/またはビデオ電話のようなアプリケーションをサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。
【0022】
[0040]コンピュータ可読媒体16は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信のような一時的な媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体のような記憶媒体(すなわち、非一時的な記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示されない)は、ソースデバイス12から符号化されたビデオデータを受信し、例えば、ネットワーク送信を介して、符号化されたビデオデータを宛先デバイス14に供給し得る。同様に、ディスクスタンピング設備のような媒体製造設備(medium production facility)のコンピューティングデバイスは、符号化されたビデオデータをソースデバイス12から受信し、符号化されたビデオデータを含むディスクを作り出し得る。したがって、コンピュータ可読媒体16は、様々な例において、様々な形式の1つまたは複数のコンピュータ可読媒体を含むと理解され得る。
【0023】
[0041]宛先デバイス14の入力インターフェース26は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロックおよび他のコード化された単位、例えば、ピクチャグループ(GOP)、の処理および/または特性を説明するシンタックス要素を含む、ビデオエンコーダ22のビデオエンコーダ22によって定義されるシンタックス情報を含み得、これは、ビデオデコーダ30によっても使用される。記憶媒体28は、入力インターフェース26によって受信される、符号化されたビデオデータを記憶し得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示する。ディスプレイデバイス32は、ブラウン管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのうちの任意のものを備え得る。
【0024】
[0042]ビデオエンコーダ22およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せのような、様々な適切なエンコーダまたはデコーダ回路のうちの任意のものとしてインプリメントされ得る。本技法がソフトウェアで部分的にインプリメントされる場合、デバイスは、このソフトウェアのための命令を、適切な非一時的なコンピュータ可読媒体に記憶し得、本開示の技法を実行するために、1つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行し得る。ビデオエンコーダ22およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれ得、それらのいずれもが、それぞれのデバイスにおいて複合エンコーダ/デコーダ(CODEC)の一部として統合され得る。
【0025】
[0043]いくつかの例では、ビデオエンコーダ22およびビデオデコーダ30は、ビデオコーディング規格に従って動作し得る。例となるビデオコーディング規格には、ITU-T H.261、ISO/IEC MPEG-1ビジュアル、ITU-T H.262またはISO/IEC MPEG-2ビジュアル、ITU-T H.263、ISO/IEC MPEG-4ビジュアル、および(ISO/IEC MPEG-4 AVCとしても知られている)ITU-T H.264に加え、そのSVC(Scalable Video Coding)およびMVC(Multi-View Video)拡張が含まれるがそれらに限られない。ビデオコーディング規格である高効率ビデオコーディング(HEVC)すなわちITU-T H.265、なお、その範囲およびスクリーンコンテンツコード化拡張、3Dビデオコーディング(3D-HEVC)およびマルチビュー拡張(MV-HEVC)およびスケーラブル拡張(SHVC)を含む、は、ITU-T VCEG(Video Coding Experts Group)およびISO/IEC MPEG(Motion Picture Experts Group)のJCT-VC(Joint Collaboration Team on Video Coding)によって開発されている。
【0026】
[0044]HEVCおよび他のビデオコーディング仕様では、ビデオシーケンスは典型的に、一連のピクチャを含む。ピクチャは、「フレーム」とも呼ばれ得る。ピクチャは、S、SCb、およびSCrと表される3つのサンプルアレイを含み得る。Sは、ルーマサンプルの二次元アレイ(すなわち、ブロック)である。SCbは、Cbクロミナンスサンプルの二次元アレイである。SCrは、Crクロミナンスサンプルの二次元アレイである。クロミナンスサンプルは、ここでは、「クロマ」サンプルとも呼ばれ得る。他の事例では、ピクチャは、モノクロであり得、ルーマサンプルのアレイのみを含み得る。
【0027】
[0045]さらに、HEVCおよび他のビデオコーディング仕様では、ピクチャの符号化表現を生成するために、ビデオエンコーダ22が、コード化ツリー単位(CTU)のセットを生成し得る。CTUの各々は、ルーマサンプルのコード化ツリーブロックと、クロマサンプルの2つの対応するコード化ツリーブロックと、これらのコード化ツリーブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは3つの別個の色平面を有するピクチャでは、CTUは、単一のコード化ツリーブロックと、このコード化ツリーブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。コード化ツリーブロックは、サンプルのNxNブロックであり得る。CTUは、「ツリーブロック」または「最大コード化単位」(LCU)とも呼ばれ得る。HEVCのCTUは、H.264/AVCのような他の規格のマクロブロックに大まかに類似し得る。しかしながら、CTUは、必ずしも、特定のサイズに制限されるわけではなく、1つまたは複数のコード化単位(CU)を含み得る。1つのスライスは、ラスター走査順に連続して並べられた整数の数のCTUを含み得る。
【0028】
[0046]HEVCに従って動作する場合、コード化されたCTUを生成するために、ビデオエンコーダ22は、CTUのコード化ツリーブロックに対して四分木区分化を再帰的に実行してこれらのコード化ツリーブロックをコード化ブロックへと分割し得、これが、「コード化ツリー単位」と呼ばれるゆえんである。コード化ブロックは、サンプルのNxNブロックである。CUは、ルーマサンプルのコード化ブロックと、ルーマサンプルアレイ、Cbサンプルアレイ、およびCrサンプルアレイを有するピクチャのクロマサンプルの2つの対応するコード化ブロックと、これらのコード化ブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは3つの別個の色平面を有するピクチャでは、CUは、単一のコード化ブロックと、このコード化ブロックのサンプルをコード化するために使用されるシンタックス構造とを備え得る。
【0029】
[0047]ビットストリーム内のシンタックスデータは、CTUのためのサイズも定義し得る。1つのスライスは、コード化順に連続する複数のCTUを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスへと区分化され得る。上述したように、各ツリーブロックは、四分木に従ってコード化単位(CU)へと分割され得る。一般に、四分木データ構造は、ルートノードがツリーブロックに対応する状態で1つのCUにつき1つのノードを含む。CUが4つのサブCUへと分割される場合、CUに対応するノードは、4つのリーフノードを含み、それらの各々がサブCUのうちの1つに対応する。
【0030】
[0048]四分木データ構造の各ノードは、対応するCUにシンタックスデータを供給し得る。例えば、四分木におけるノードは、このノードに対応するCUがサブCUへと分割されるかどうかを示す分割フラグを含み得る。CUに関するシンタックス要素は再帰的に定義され得、CUがサブCUへと分割されるかどうかに依存し得る。CUがこれ以上分割されない場合、それはリーフCUと呼ばれる。CUのブロックがさらに分割される場合、それは一般に、非リーフCUと呼ばれ得る。本開示のいくつかの例では、リーフCUの4つのサブCUは、元のリーフCUの明示的な分割が存在しない場合であっても、リーフCUと呼ばれ得る。例えば、16x16のサイズのCUがこれ以上分割されない場合、16x16のCUは一度も分割されていないが、4つの8x8のサブCUもリーフCUと呼ばれ得る。
【0031】
[0049]CUは、CUがサイズ区別(size distinction)を有さないことを除いて、H.264規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、(サブCUとも呼ばれる)4つの子ノードへと分割され得、各子ノードが次に親ノードになり、別の4つの子ノードへと分割され得る。四分木のリーフノードと呼ばれる、最終の分割されていない子ノードは、リーフCUとも呼ばれるコード化ノードを備える。コード化されたビットストリームに関連付けられたシンタックスデータは、最大CU深度と呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、コード化ノードの最小サイズも定義し得る。したがって、ビットストリームもまた、最小コード化単位(SCU)を定義し得る。本開示は、HEVCのコンテキストにおけるCU、PU、またはTUのうちの任意のもの、または、他の規格のコンテキストにおける同様のデータ構造(例えば、H.264/AVCにおけるそれのマクロブロックおよびサブブロック)を指すために「ブロック」という用語を使用する。
【0032】
[0050]CUは、コード化ノードと、このコード化ノードに関連付けられた変換単位(TU)および予測単位(PU)とを含む。CUのサイズは、コード化ノードのサイズに対応し、いくつかの例では、形状が正方形であり得る。HEVCの例では、CUのサイズは、8x8画素から、最大64x64画素またはそれより大きいツリーブロックのサイズまでの範囲であり得る。各CUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。CUに関連付けられたシンタックスデータは、例えば、1つまたは複数のPUへのCUの区分化を説明し得る。区分モードは、CUが、スキップまたはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、インター予測モード符号化されるかで異なり得る。PUは、形状が非正方形になるように区分化され得る。CUに関連付けられたシンタックスデータはまた、例えば、四分木にしたがった1つまたは複数のTUへのCUの区分化を説明し得る。TUは、形状が正方形または非正方形(例えば、長方形)であることができる。
【0033】
[0051]HEVC規格は、TUにしたがった変換を可能にする。TUは、CUごとに異なり得る。TUは通常、区分化されたLCUのために定義された所与のCU中のPUのサイズに基づいてサイズ変更されるが、これは、常に当てはまるわけではないであろう。TUは通常、PUと同じサイズであるかそれより小さい。いくつかの例では、CUに対応する残差サンプルは、「残差四分木」(RQT)と呼ばれることがある四分木構造を使用してより小さい単位へと再分割され得る。RQTのリーフノードは、TUと呼ばれ得る。TUに関連付けられた画素差分値は、量子化され得る変換係数を作り出すために変換され得る。
【0034】
[0052]リーフCUは、1つまたは複数のPUを含み得る。一般に、PUは、対応するCUの全体または一部に対応する空間エリアを表し、このPUについての参照サンプルを取り出すためのデータを含み得る。さらに、PUは、予測に関連するデータを含む。例えば、PUがイントラモード符号化されるとき、PUのためのデータは、RQTに含まれ得、これは、このPUに対応するTUのためのイントラ予測モードを説明するデータを含み得る。別の例として、PUがインターモード符号化されるとき、PUは、このPUについての1つまたは複数の動きベクトルを定義するデータを含み得る。PUについての動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度(例えば、4分の1画素精度または8分の1画素精度)、動きベクトルが指し示す参照ピクチャ、および/または動きベクトルについての参照ピクチャリスト(例えば、リスト0、リスト1、またはリストC)を説明し得る。
【0035】
[0053]1つまたは複数のPUを有するリーフCUもまた、1つまたは複数のTUを含み得る。TUは、上で述べたように、RQT(TU四分木構造とも呼ばれ得る)を使用して指定され得る。例えば、分割フラグは、リーフCUが4つの変換単位へと分割されるかを示し得る。いくつかの例では、各変換単位は、さらなるサブTUへとさらに分割され得る。TUがこれ以上分割されないとき、それはリーフTUと呼ばれ得る。一般に、イントラコード化の場合、リーフCUに属するすべてのリーフTUが、同じイントラ予測モードから作り出された残差データを含む。すなわち、リーフCUのすべてのTUにおいて変換されることとなる予測値を算出するために、同じイントラ予測モードが一般に適用される。イントラコード化の場合、ビデオエンコーダ22は、TUに対応するCUの部分と元のブロックとの間の差分として、イントラ予測モードを使用して各リーフTUの残差値を算出し得る。TUは、必ずしもPUのサイズに制限されるわけではない。ゆえに、TUは、PUより大きい場合も小さい場合もある。イントラコード化の場合、PUは、同じCUについて対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
【0036】
[0054]さらに、リーフCUのTUは、それぞれのRQT構造に関連付けられ得る。すなわち、リーフCUは、リーフCUがどのようにTUへと区分化されるかを示す四分木を含み得る。TU四分木のルートノードは一般に、リーフCUに対応し、CU四分木のルートノードは一般に、ツリーブロック(または、LCU)に対応する。
【0037】
[0055]上で述べたように、ビデオエンコーダ22は、CUのコード化ブロックを1つまたは複数の予測ブロックへと区分化し得る。予測ブロックは、同じ予測が適用されるサンプルの長方形(すなわち、正方形または非正方形)ブロックであり得る。CUのPUは、ルーマサンプルの予測ブロックと、クロマサンプルの2つの対応する予測ブロックと、これらの予測ブロックを予測するために使用されるシンタックス構造とを備え得る。モノクロのピクチャまたは3つの別個の色平面を有するピクチャでは、PUは、単一の予測ブロックと、この予測ブロックを予測するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ22は、CUの各PUの予測ブロック(例えば、ルーマ、Cb、およびCr予測ブロック)についての予測ブロック(例えば、ルーマ、Cb、およびCr予測ブロック)を生成し得る。
【0038】
[0056]ビデオエンコーダ22は、PUについての予測ブロックを生成するためにイントラ予測またはインター予測を使用し得る。ビデオエンコーダ22が、PUの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ22は、PUを含むピクチャの復号されたサンプルに基づいて、PUの予測ブロックを生成し得る。
【0039】
[0057]ビデオエンコーダ22が、CUの1つまたは複数のPUについての予測ブロック(例えば、ルーマ、Cb、およびCr予測ブロック)を生成した後、ビデオエンコーダ22は、このCUについての1つまたは複数の残差ブロックを生成し得る。例えば、ビデオエンコーダ22は、CUについてのルーマ残差ブロックを生成し得る。CUのルーマ残差ブロック中の各サンプルは、CUの予測ルーマブロックのうちの1つ中のルーマサンプルと、CUの元のルーマコード化ブロック中の対応するサンプルとの間の差分を示す。加えて、ビデオエンコーダ22は、CUについてのCb残差ブロックを生成し得る。CUのCb残差ブロック中の各サンプルは、CUの予測Cbブロックのうちの1つ中のCbサンプルと、CUの元のCbコード化ブロック中の対応するサンプルとの間の差分を示し得る。ビデオエンコーダ22はまた、CUについてのCr残差ブロックを生成し得る。CUのCr残差ブロック中の各サンプルは、CUの予測Crブロックのうちの1つ中のCrサンプルと、CUの元のCrコード化ブロック中の対応するサンプルとの間の差分を示し得る。
【0040】
[0058]さらに、上で述べたように、ビデオエンコーダ22は、CUの残差ブロック(例えば、ルーマ、Cb、およびCr残差ブロック)を1つまたは複数の変換ブロック(例えば、ルーマ、Cb、およびCr変換ブロック)へと分解するために四分木区分化を使用し得る。変換ブロックは、同じ変換が適用されるサンプルの長方形(例えば、正方形または非正方形)ブロックであり得る。CUの変換単位(TU)は、ルーマサンプルの変換ブロックと、クロマサンプルの2つの対応する変換ブロックと、これらの変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。ゆえに、CUの各TUは、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロックを有し得る。TUのルーマ変換ブロックは、CUのルーマ残差ブロックのサブブロックであり得る。Cb変換ブロックは、CUのCb残差ブロックのサブブロックであり得る。Cr変換ブロックは、CUのCr残差ブロックのサブブロックであり得る。モノクロのピクチャまたは3つの別個の色平面を有するピクチャでは、TUは、単一の変換ブロックと、この変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。
【0041】
[0059]ビデオエンコーダ22は、TUについての係数ブロックを生成するために、TUの変換ブロックに1つまたは複数の変換を適用し得る。例えば、ビデオエンコーダ22は、TUについてのルーマ係数ブロックを生成するために、TUのルーマ変換ブロックに1つまたは複数の変換を適用し得る。係数ブロックは、変換係数の二次元アレイであり得る。変換係数は、スカラー量であり得る。ビデオエンコーダ22は、TUについてのCb係数ブロックを生成するために、TUのCb変換ブロックに1つまたは複数の変換を適用し得る。ビデオエンコーダ22は、TUについてのCr係数ブロックを生成するために、TUのCr変換ブロックに1つまたは複数の変換を適用し得る。
【0042】
[0060]いくつかの例では、ビデオエンコーダ22は、変換ブロックへの変換の適用を省略する。そのような例では、ビデオエンコーダ22は、変換係数と同じ方法で残差サンプル値を扱い得る。ゆえに、ビデオエンコーダ22が変換の適用を省略する例では、変換係数および係数ブロックの以下の考察が、残差サンプルの変換ブロックに適用可能であり得る。
【0043】
[0061]係数ブロック(例えば、ルーマ係数ブロック、Cb係数ブロック、またはCr係数ブロック)を生成した後、ビデオエンコーダ22は、係数ブロックを表すために使用されるデータ量を可能な限り低減する、恐らくはさらなる圧縮を提供する、ために、係数ブロックを量子化し得る。量子化は一般に、ある範囲の値が単一の値に圧縮されるプロセスを指す。例えば、量子化は、値を定数で除算し、その後、最も近い整数に端数を丸める(round)ことで行われ得る。係数ブロックを量子化するために、ビデオエンコーダ22は、係数ブロックの変換係数を量子化し得る。ビデオエンコーダ22が係数ブロックを量子化した後、ビデオエンコーダ22は、量子化された変換係数を示すシンタックス要素をエントロピー符号化し得る。例えば、ビデオエンコーダ22は、量子化された変換係数を示すシンタックス要素に対してコンテキスト適応型バイナリ算術コーディング(CABAC)または他のエントロピーコーディング技法を実行し得る。
【0044】
[0062]ビデオエンコーダ22は、コード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームおよび関連するデータを出力し得る。ゆえに、ビットストリームは、ビデオデータの符号化表現を備える。ビットストリームは、ネットワーク抽象化レイヤ(NAL)単位のシーケンスを備え得る。NAL単位は、NAL単位中のデータのタイプを示すインジケーションと、必要に応じてエミュレーション防止ビットが組み入れられている生バイトシーケンスペイロード(RBSP)の形式でそのデータを含むバイトとを含むシンタックス構造である。NAL単位の各々は、NAL単位ヘッダを含み得、RBSPをカプセル化し得る。NAL単位ヘッダは、NAL単位タイプコードを示すシンタックス要素を含み得る。NAL単位のNAL単位ヘッダによって指定されるNAL単位タイプコードは、NAL単位のタイプを示す。RBSPは、NAL単位内にカプセル化される整数の数のバイトを含むシンタックス構造であり得る。いくつかの事例では、RBSPはゼロビットを含む。
【0045】
[0063]ビデオデコーダ30は、ビデオエンコーダ22によって生成されたビットストリームを受信し得る。ビデオデコーダ30は、ビデオデータのピクチャを再構築するために、ビットストリームを復号し得る。ビットストリームを復号することの一部として、ビデオデコーダ30は、ビットストリームからシンタックス要素を取得するためにビットストリームを解析し得る。ビデオデコーダ30は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築し得る。ビデオデータを再構築するためのプロセスは、一般に、ビデオエンコーダ22によって実行されるプロセスとは概ね逆である。例えば、ビデオデコーダ30は、現在のCUのPUについての予測ブロックを決定するために、PUの動きベクトルを使用し得る。加えて、ビデオデコーダ30は、現在のCUのTUの係数ブロックを逆量子化し得る。ビデオデコーダ30は、現在のCUのTUの変換ブロックを再構築するために、係数ブロックに対して逆変換を実行し得る。ビデオデコーダ30は、現在のCUのPUについての予測ブロックのサンプルを、現在のCUのTUの変換ブロックの対応するサンプルに加えることで、現在のCUのコード化ブロックを再構築し得る。ピクチャの各CUについてのコード化ブロックを再構築することで、ビデオデコーダ30は、ピクチャを再構築し得る。
【0046】
[0064]HEVCの共通概念および特定の設計態様が、ブロック区分のための技法に焦点を当てて、以下に説明される。HEVCでは、スライス中の最大コード化単位は、CTBと呼ばれる。CTBは、四分木構造に従って分割され、それのノードは、コード化単位である。四分木構造における複数のノードは、リーフノードと非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない(すなわち、リーフノードは、これ以上分割されない)。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロック(例えば、CTB)に対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において1つまたは複数の子ノードを有する。
【0047】
[0065]CTBのサイズは、(厳密には、8x8のCTBサイズはサポートされることができるが)HEVCメインプロファイルにおいて16x16から64x64までの範囲である。W.J.Han等による「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,2010年12月、で説明されているように、および図2に示されるように、CTBは、四分木方法でCUへと再帰的に分割され得る。図2に示されるように、区分化の各レベルは、4つのサブブロックへの四分木分割である。黒いブロックは、リーフノード(すなわち、これ以上分割されないブロック)の例である。
【0048】
[0066]いくつかの例では、CUは、CTBのサイズと同じサイズであり得るが、CUは、8x8ほどの小ささであることができる。各CUは、例えば、イントラコード化モードまたはインターコード化モードであり得る1つのコード化モードでコード化される。スクリーンコンテンツ用のコード化モード(例えば、イントラブロックコピーモード、パレットベースコード化モード、等)を含む、他のコード化モードも可能である。CUがインターコード化される(すなわち、インターモードが適用される)とき、CUは、予測単位(PU)へとさらに区分化され得る。例えば、CUは、2つまたは4つのPUへと区分化され得る。別の例では、さらなる区分化が適用されない場合、CU全体が単一のPUとして扱われる。HEVCの例では、1つのCUに2つのPUが存在するとき、それらは、ハーフサイズの長方形であるか、CUの1/4または3/4のサイズを有する2つの長方形のサイズであることができる。
【0049】
[0067]HEVCでは、図3に示されるように、インター予測モードでコード化されたCUに対して8つの区分モード、すなわち、PART_2Nx2N、PART_2NxN、PART_Nx2N、PART_NxN、PART_2NxnU、PART_2NxnD、PART_nLx2N、およびPART_nRx2Nが存在する。図3に示されるように、区分モードPART_2Nx2Nでコード化されたCUは、これ以上分割されない。すなわち、CU全体が単一のPU(PU0)として扱われる。区分モードPART_2NxNでコード化されたCUは、2つのPU(PU0とPU1)へと対称的に水平に分割される。区分モードPART_Nx2Nでコード化されたCUは、2つのPUへと対称的に垂直に分割される。区分モードPART_NxNでコード化されたCUは、4つの等しいサイズのPU(PU0、PU1、PU2、PU3)へと対称的に分割される。
【0050】
[0068]区分モードPART_2NxnUでコード化されたCUは、CUのサイズの1/4を有する1つのPU0(上部PU)およびCUのサイズの3/4を有する1つのPU1(下部PU)へと非対称的に水平に分割される。区分モードPART_2NxnDでコード化されたCUは、CUのサイズの3/4を有する1つのPU0(上部PU)およびCUのサイズの1/4を有する1つのPU1(下部PU)へと非対称的に水平に分割される。区分モードPART_nLx2Nでコード化されたCUは、CUのサイズの1/4を有する1つのPU0(左のPU)およびCUのサイズの3/4を有する1つのPU1(右のPU)へと非対称的に垂直に分割される。区分モードPART_nRx2Nでコード化されたCUは、CUのサイズの3/4を有する1つのPU0(左のPU)およびCUの1/4のサイズを有する1つのPU1(右のPU)へと非対称的に垂直に分割される。
【0051】
[0069]CUがインターコード化されるとき、各PUに対して、動き情報(例えば、動きベクトル、予測方向、および参照ピクチャ)の1つのセットが存在する。加えて、各PUは、動き情報のセットを導出するために、一意的なインター予測モードでコード化される。しかしながら、2つのPUが一意的にコード化されても、それらが状況次第で同じ動き情報を有し得ることは理解されるべきである。
【0052】
[0070]J.An等による、「Block partitioning structure for next generation video coding」,国際電気通信連合,COM16-C966,2015年9月(以下、「VCEG proposal COM16-C966」)では、四分木二分木(QTBT)区分化技法が、HEVCを越える将来のビデオコーディング規格のために提案された。シミュレーションは、提案されたQTBT構造が、使用されるHEVCにおける四分木構造より効率的であることを示している。
【0053】
[0071]VCEG proposal COM16-C966の提案されたQTBT構造では、最初に四分木分割技法を使用してCTBが区分化され、ここでは、1つのノードの四分木分割は、このノードが最小の許容四分木リーフノードサイズに達するまで反復されることができる。最小の許容四分木リーフノードサイズは、シンタックス要素MinQTSizeの値によってビデオデコーダに示され得る。四分木リーフノードサイズが(例えば、シンタックス要素MaxBTSizeによって表される)最大の許容二分木ルートノードサイズより大きくない場合、四分木リーフノードは、二分木区分化を使用してさらに区分化されることができる。1つのノードの二分木区分化は、このノードが(例えば、シンタックス要素MinBTSizeによって表されるような)最小の許容二分木リーフノードサイズまたは(例えば、シンタックス要素MaxBTDepthによって表されるような)最大の許容二分木深度に達するまで反復されることができる。VCEG proposal COM16-C966は、二分木リーフノードを指すために「CU」という用語を使用する。VCEG proposal COM16-C966では、CUは、これ以上の区分化なしに変換および予測(例えば、イントラ予測、インター予測、等)に対して使用される。一般に、QTBT技法によれば、対称水平分割および対称垂直分割という2つの分割タイプが二分木分割のために存在する。いずれのケースでも、ブロックは、このブロックを、水平または垂直のいずれかに、真ん中で半分に(down the middle)分割することで分割される。
【0054】
[0072]QTBT区分構造の一例では、CTUサイズは128x128(例えば、128x128のルーマブロックと2つの対応する64x64のクロマブロック)として設定され、MinQTSizeは、16x16として設定され、MaxBTSizeは、64x64として設定され、(幅と高さの両方についての)MinBTSizeは、4として設定され、MaxBTDepthは、4として設定される。四分木リーフノードを生成するために、最初に四分木区分化がCTUに適用される。四分木リーフノードは、16x16(すなわち、MinQTSizeは16x16である)から128x128(すなわち、CTUサイズ)までのサイズを有し得る。QTBT区分化の一例によれば、リーフ四分木ノードが128x128である場合、リーフ四分木ノードは、リーフ四分木ノードのサイズがMaxBTSize(すなわち、64x64)を超えるため、二分木によってこれ以上分割されることはできない。そうでなければ、リーフ四分木ノードは、二分木によってさらに区分化される。したがって、四分木リーフノードは、二分木のためのルートノードでもあり、0の二分木深度を有する。MaxBTDepth(例えば、4)に達する二分木深度は、これ以上の分割がないことを暗示する。MinBTSize(例えば、4)に等しい幅を有する二分木ノードは、これ以上の水平分割がないことを暗示する。同様に、MinBTSizeに等しい高さを有する二分木ノードは、これ以上の垂直分割がないことを暗示する。二分木(CU)のリーフノードは、これ以上の区分化なしに(例えば、予測プロセスおよび変換プロセスを実行することで)さらに処理される。
【0055】
[0073]図4Aは、QTBT区分化技法を使用して区分化されたブロック50(例えば、CTB)の例を例示する。図4Aに示されるように、QTBT区分技法を使用して、結果として得られるブロックの各々は、各ブロックの中心を通って対称的に分割される。図4Bは、図4Bのブロック区分化に対応するツリー構造を例示する。図4B中の実線は四分木分割を示し、点線は二分木分割を示す。一例では、二分木の各分割(すなわち、非リーフ)ノードにおいて、シンタックス要素(例えば、フラグ)が、実行される分割のタイプ(例えば、水平または垂直)を示すためにシグナリングされ、ここで、0は、水平分割を示し、1は、垂直分割を示す。四分木分割の場合、四分木分割が常に、同じサイズの4つのサブブロックへと水平および垂直にブロックを分割するため、分割タイプを示す必要はない。
【0056】
[0074]図4Bに示されるように、ノード70において、ブロック50は、QT区分化を使用して、図4Aに示される4つのブロック51、52、53、および54へと分割される。ブロック54はこれ以上分割されないため、リーフノードである。ノード72において、ブロック51は、BT区分化を使用して2つのブロックへとさらに分割される。図4Bに示されるように、ノード72は、垂直分割を示す1がマーク付けされる。このように、ノード72における分割は、ブロック57と、ブロック55および56の両方を含むブロックとをもたらす。ブロック55および56は、ノード74におけるさらなる垂直分割によって作られる。ノード76において、ブロック52は、BT区分化を使用して2つのブロック58および59へとさらに分割される。図4Bに示されるように、ノード76は、水平分割を示す1がマーク付けされる。
【0057】
[0075]ノード78において、ブロック53は、QT区分化を使用して4つの等しいサイズのブロックへと分割される。ブロック63および66は、このQT区分化から作られるものであり、これ以上分割されない。ノード80において、左上のブロックは、垂直二分木分割を使用して最初に分割され、ブロック60と、右縦ブロック(right vertical block)をもたらす。その後、右縦ブロックは、水平二分木分割を使用してブロック61および62へと分割される。ノード78における四分木分割から作られた右下ブロックは、ノード84において水平二分木分割を使用してブロック64および65へと分割される。
【0058】
[0076]上で説明したQTBT構造は、HEVCで使用される四分木構造より優れたコーディング性能を示すが、QTBT構造は、柔軟性に欠ける。例えば、上で説明したQTBT構造では、四分木ノードは、二分木でさらに分割されることができるが、二分木ノードは、四分木でさらに分割されることはできない。別の例では、四分木および二分木の両方は、均一分割(すなわち、ブロックの真ん中で半分に(down the center)分割すること)のみを達成することができるが、これは、オブジェクトが、分割されることとなるブロックの中心にあるとき、効率的でない。したがって、QTBTのコーディング性能が、将来のビデオコーディング規格に不足しているであろう。
【0059】
[0077]上述した問題に対処するために、以下の技法が提案される。以下の技法は、個々に適用され得る。他の例では、以下に説明する技法の任意の組合せはまとめて適用され得る。
【0060】
[0078]CTUのためのより柔軟な区分化を達成するために、QT、BT、および/またはQTBTベースのCU構造に取って代わるMTTベースのCU構造が提案される。本開示のMTT区分構造は、依然として、再帰的ツリー構造である。しかしながら、複数の異なる区分構造(例えば、3つ以上)が使用される。例えば、本開示のMTT技法によれば、3つ以上の異なる区分構造が、ツリー構造の各深度において使用され得る。このコンテキストにおいて、ツリー構造におけるノードの深度は、このノードからツリー構造のルートまでの経路の長さ(例えば、分割数)を指し得る。本開示で使用されるように、区分構造は一般に、1つのブロックがいくつの異なるブロックへと分割され得るかを指し得る。例えば、四分木区分構造は、1つのブロックを4つのブロックへと分割し得、二分木区分構造は、1つのブロックを2つのブロックへと分割し得、三分木区分構造は、1つのブロックを3つのブロックへと分割し得る。区分構造は、以下でより詳細に説明するように、複数の異なる区分タイプを有し得る。区分タイプは、対称または非対称区分化、均一または非均一区分化、および/または水平または垂直区分化を含む、ブロックがどのように分割されるかを追加的に定義し得る。
【0061】
[0079]本開示の技法に係る一例では、ビデオエンコーダ22は、ビデオデータのピクチャを受信し、3つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化し、ビデオデータのピクチャの複数のブロックを符号化するように構成され得る。同様に、ビデオデコーダ30は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信し、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定し、ビデオデータのコード化されたピクチャの複数のブロックを再構築するように構成され得る。一例では、ビデオデータのフレームを区分化することは、3つ以上の異なる区分構造を使用してビデオデータのフレームを複数のブロックへと区分化することを備え、ここにおいて、3つ以上の異なる区分構造のうちの少なくとも3つが、ビデオデータのフレームがどのように区分化されるかを表すツリー構造の各深度において使用され得る。一例では、3つ以上の異なる区分構造は、三分木区分構造を含み、ビデオエンコーダ22および/またはビデオデコーダ30は、三分木区分構造の三分木区分タイプを使用してビデオデータの複数のブロックのうちの1つを区分化するように構成され得、ここにおいて、三分木区分構造は、中心を通って複数のブロックのうちの1つを分割することなく複数のブロックのうちの1つを3つのサブブロックへと分割する。本開示のさらなる例では、3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。
【0062】
[0080]ゆえに、一例では、ビデオエンコーダ22は、ビデオデータの初期ビデオブロック(例えば、コード化ツリーブロックまたはCTU)の符号化表現を生成し得る。初期ビデオブロックの符号化表現を生成することの一部として、ビデオエンコーダ22は、複数のノードを備えるツリー構造を決定する。例えば、ビデオエンコーダ22は、本開示のMTT区分構造を使用してツリーブロックを区分化し得る。
【0063】
[0081]MTT区分構造中の複数のノードは、複数のリーフノードと、複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造において親ノードに対応するビデオブロックのサブブロックであるビデオブロック(例えば、コード化ブロック)に対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において1つまたは複数の子ノードを有する。いくつかの例では、ピクチャ境界にある非リーフノードは、強制的な分割による1つの子ノードのみを有し得、子ノードのうちの1つは、ピクチャ境界の外側のブロックに対応する。
【0064】
[0082]本開示の技法によれば、ツリー構造の各深度レベルにおけるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターン(例えば、区分構造)が存在する。例えば、ツリー構造の各深度に対して許容される3つ以上の区分構造が存在し得る。ビデオエンコーダ22は、複数の許容可能な区分構造のうちの1つに従って、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化するように構成され得る。複数の許容区分構造の各それぞれの許容区分構造は、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応し得る。さらに、この例では、ビデオエンコーダ22は、ビデオデータの符号化表現を備えるビットストリーム中に初期ビデオブロックの符号化表現を含め得る。
【0065】
[0083]同様の例では、ビデオデコーダ30は、複数のノードを備えるツリー構造を決定し得る。前の例にあるように、複数のノードは、複数のリーフノードと複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造において親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において1つまたは複数の子ノードを有する。ツリー構造の各深度レベルにおけるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターンが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの1つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容分割パターンの各それぞれの許容分割パターンは、それぞれの非リーフノードに対応するビデオブロックを、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応する。さらに、この例では、ツリー構造の各(または少なくとも1つの)それぞれのリーフノードについて、ビデオデコーダ30は、それぞれのリーフノードに対応するビデオブロックを再構築する。
【0066】
[0084]いくつかのこのような例では、ルートノード以外のツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードのための複数の許容分割パターン(例えば、区分構造)は、それに従ってそれぞれの非リーフノードの親ノードに対応するビデオブロックがそれぞれの非リーフノードの親ノードの子ノードに対応するビデオブロックへと区分化される区分構造から独立している。
【0067】
[0085]本開示の他の例では、ツリー構造の各深度において、ビデオエンコーダ22は、さらに3つの区分構造のうちの1つの中からの特定の区分タイプを使用して、サブツリーをさらに分割するように構成され得る。例えば、ビデオエンコーダ22は、QT、BT、三分木(TT)および他の区分構造から特定の区分タイプを決定するように構成され得る。一例では、QT区分構造は、正方形四分木および長方形四分木区分タイプを含み得る。ビデオエンコーダ22は、正方形ブロックを4つの等しいサイズの正方形ブロックへと、水平および垂直の両方に真ん中で半分に分割することで、正方形四分木区分化を使用してこのブロックを区分化し得る。同様に、ビデオエンコーダ22は、長方形(例えば、非正方形)ブロックを4つの等しいサイズの長方形ブロックへと、水平および垂直の両方に真ん中で半分に分割することで、長方形の四分木区分を使用してこの長方形ブロックを区分化し得る。
【0068】
[0086]BT区分構造は、水平対称二分木、垂直対称二分木、水平非対称二分木、および垂直非対称二分木区分タイプを含み得る。水平対称二分木区分タイプの場合、ビデオエンコーダ22は、ブロックを、同じサイズの2つの対称的なブロックへとこのブロックの真ん中で半分に水平に分割するように構成され得る。垂直対称二分木区分タイプの場合、ビデオエンコーダ22は、ブロックを、同じサイズの2つの対称的なブロックへとこのブロックの真ん中で半分に垂直に分割するように構成され得る。水平非対称二分木区分タイプの場合、ビデオエンコーダ22は、ブロックを、異なるサイズの2つのブロックへと水平に分割するように構成され得る。例えば、図3のPART_2NxnUまたはPART_2NxnD区分タイプにあるように、一方のブロックは、親ブロックのサイズの1/4であり得、他方のブロックは、親ブロックのサイズの3/4であり得る。垂直非対称二分木区分タイプの場合、ビデオエンコーダ22は、ブロックを、異なるサイズの2つのブロックへと垂直に、分割するように構成され得る。例えば、図3のPART_nLx2NまたはPART_nRx2N区分タイプにあるように、一方のブロックは、親ブロックのサイズの1/4であり得、他方のブロックは、親ブロックのサイズの3/4であり得る。
【0069】
[0087]他の例では、非対称二分木区分タイプは、親ブロックを異なるサイズのフラクション(fraction)へと分割し得る。例えば、一方のサブブロックは、親ブロックの3/8であり得、他方のサブブロックは、親ブロックの5/8であり得る。当然ながら、このような区分タイプは、垂直または水平のいずれかであり得る。
【0070】
[0088]TT区分構造は、TT区分構造がブロックの真ん中で半分に分割しない点で、QTまたはBT構造のものとは異なり得る。ブロックの中心領域は、全体が(together)同じサブブロックに留まる。4つのブロックを作り出すQTまたは2つのブロックを作り出す二分木とは異なり、TT区分構造に従って分割すると、3つのブロックを作り出す。TT区分構造にしたがった例となる区分タイプには、(水平および垂直の両方の)対称区分タイプおよび(水平および垂直の両方の)非対称区分タイプが含まれる。さらに、TT区分構造にしたがった対称区分タイプは、非一様/不均一または一様/均一であり得る。本開示のTT区分構造にしたがった非対称区分タイプは、非一様/不均一である。本開示の一例では、TT区分構造は、水平一様/均一対称三分木、垂直一様/均一対称三分木、水平非一様/不均一対称三分木、垂直非一様/不均一対称三分木、水平非一様/不均一非対称三分木、および垂直非一様/不均一非対称三分木区分タイプという区分タイプを含み得る。
【0071】
[0089]一般に、非一様/不均一対称三分木区分タイプは、ブロックの中心線を中心にして対称であるが、結果として得られるブロック3つのブロックのうちの少なくとも1つは、その他の2つとは同じサイズではない区分タイプである。1つの好ましい例は、サイドブロックがブロックの1/4のサイズであり、センタブロックが、ブロックのサイズの1/2である場合である。一様/均一対称三分木区分タイプは、ブロックの中心線を中心にして対称であり、結果として得られるブロックはすべて同じサイズである区分タイプである。このような区分は、ブロックの高さまたは幅が、垂直または水平分割に依存して、3の倍数である場合に可能である。非一様/不均一非対称三分木区分タイプは、ブロックの中心線を中心にして対称ではなく、結果として得られるブロックのうちの少なくとも1つがその他の2つと同じサイズではない区分タイプである。
【0072】
[0090]図5Aは、例となる水平三分木区分タイプを例示する概念図である。図5Bは、例となる垂直三分木区分タイプを例示する概念図である。図5Aおよび図5Bの両方において、hは、ルーマまたはクロマサンプル中のブロックの高さを表し、wは、ルーマまたはクロマサンプル中のブロックの幅を表す。図5Aおよび図5Bにおける三分木区分の各々のそれぞれの「中心線」がブロックの境界を表さない(すなわち、三分木区分は、この中心線を通ってブロックを分割しない)ことに留意されたい。むしろ、中心線は、特定の区分タイプが元のブロックの中心線に対して対称または非対称であるか否かを描写するために示される。描写されている中心線はまた、分割の方向に沿っている。
【0073】
[0091]図5Aに示されるように、ブロック71は、水平一様/均一対称区分タイプで区分化される。水平一様/均一対称区分タイプは、ブロック71の中心線に対して対称的な上半分および下半分を作り出す。水平一様/均一対称区分タイプは、各々h/3の高さおよびwの幅を有する、サイズが等しい3つのサブブロックを作り出す。水平一様/均一対称区分タイプは、ブロック71の高さが3で割り切れるときに可能である。
【0074】
[0092]ブロック73は、水平非一様/不均一対称区分タイプで区分化される。水平非一様/不均一対称区分タイプは、ブロック73の中心線に対して対称的な上半分および下半分を作り出す。水平非一様/不均一対称区分タイプは、サイズが等しい2つのブロック(例えば、h/4の高さを有する上ブロックおよび底部ブロック)と、異なるサイズのセンタブロック(例えば、h/2の高さを有するセンタブロック)を作り出す。本開示の一例では、水平非一様/不均一対称区分タイプに従って、センタブロックの面積は、上ブロックと底部ブロックとを合わせた面積に等しい。いくつかの例では、水平非一様/不均一対称区分タイプは、2の累乗(例えば、2,4,8,16,32,等)である高さを有するブロックに対して好ましいであろう。
【0075】
[0093]ブロック75は、水平非一様/不均一非対称区分タイプで区分化される。水平非一様/不均一非対称区分タイプは、ブロック75の中心線に対して対称的な上半分および下半分を作り出さない(すなわち、上半分と下半分は非対称である)。図5Aの例では、水平非一様/不均一非対称区分タイプは、h/4の高さを有する上ブロックと、3h/8の高さを有するセンタブロックと、3h/8の高さを有する底部ブロックとを作り出す。当然ながら、他の非対称配置が使用され得る。
【0076】
[0094]図5Bに示されるように、ブロック77は、垂直一様/均一対称区分タイプで区分化される。垂直一様/均一対称区分タイプは、ブロック77の中心線に対して対称的な左半分および右半分を作り出す。垂直一様/均一対称区分タイプは、各々w/3の幅およびhの高さを有する、サイズが等しい3つのサブブロックを作り出す。垂直一様/均一対称区分タイプは、ブロック77の幅が3で割り切れるときに可能である。
【0077】
[0095]ブロック79は、垂直非一様/不均一対称区分タイプで区分化される。垂直非一様/不均一対称区分タイプは、ブロック79の中心線に対して対称的な左半分および右半分を作り出す。垂直非一様/不均一対称区分タイプは、79の中心線に関して対称的な左半分および右半分を作り出す。垂直非一様/不均一対称区分タイプは、サイズが等しい2つのブロック(例えば、w/4の幅を有する左ブロックおよび右ブロック)と、異なるサイズのセンタブロック(例えば、w/2の幅を有するセンタブロック)とを作り出す。本開示の一例では、垂直非一様/不均一対称区分タイプに従って、センタブロックの面積は、左ブロックと右ブロックとを合わせた面積に等しい。いくつかの例では、垂直非一様/不均一対称区分タイプは、2の累乗(例えば、2,4,8,16,32,等)である幅を有するブロックに対して好ましいであろう。
【0078】
[0096]ブロック81は、垂直非一様/不均一非対称区分タイプで区分化される。垂直非一様/不均一非対称区分タイプは、ブロック81の中心線に対して対称的な左半分および右半分を作り出さない(すなわち、左半分と右半分は非対称である)。図5Bの例では、垂直非一様/不均一非対称区分タイプは、w/4の幅を有する左ブロックと、3w/8の幅を有するセンタブロックと、3w/8の幅を有する底部ブロックとを作り出す。当然ながら、他の非対称配置が使用され得る。
【0079】
[0097](例えば、サブツリーノードにおける)ブロックが非対称三分木区分タイプに分割される例では、ビデオエンコーダ22および/またはビデオデコーダ30は、3つの区分のうちの2つが同じサイズを有するという制約(restriction)を適用し得る。そのような制約は、ビデオデータを符号化するときにビデオエンコーダ22が準拠しなければならない制限に対応し得る。さらに、いくつかの例では、ビデオエンコーダ22およびビデオデコーダ30は、非対称三分木区分タイプに従って分割するとき、2つの区分の面積の合計が残りの区分の面積に等しくなる制約を適用し得る。例えば、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードが、第1の子ノード、第2の子ノード、および第3の子ノードを有すること、ここで、第2の子ノードが、第1の子ノードに対応するビデオブロックと第3の子ノードに対応するビデオブロックとの間のビデオブロックに対応し、第1および第3の子ノードに対応するビデオブロックが同じサイズを有し、第1および第3の子ノードに対応するビデオブロックのサイズの合計が、第2の子ノードに対応するビデオブロックのサイズに等しい、を規定する制約に適合する初期ビデオブロックの符号化表現を、ビデオエンコーダ22は生成し得、または、ビデオデコーダ30は受信し得る。
【0080】
[0098]本開示のいくつかの例では、ビデオエンコーダ22は、QT、BT、およびTT区分構造の各々について、前述の区分タイプのすべての中から選択するように構成され得る。他の例では、ビデオエンコーダ22は、前述の区分タイプのサブセットの中から区分タイプのみを決定するように構成され得る。例えば、上で述べた区分タイプ(または、他の区分タイプ)のサブセットは、特定のブロックサイズにまたは四分木構造の特定の深度に対して使用され得る。サポートされる区分タイプのサブセットは、ビデオデコーダ30による使用のためにビットストリームにおいてシグナリングされ得るか、ビデオエンコーダ22およびビデオデコーダ30がシグナリングなしにサブセットを決定し得るようにあらかじめ定義され得る。
【0081】
[0099]他の例では、サポートされる区分タイプの数は、すべてのCTU中のすべての深度に対して固定であり得る。すなわち、ビデオエンコーダ22およびビデオデコーダ30は、CTUのいずれの深度に対しても同じ数の区分タイプを使用するようにあらかじめ構成され得る。他の例では、サポートされる区分タイプの数は変化し得、深度、スライスタイプ、または他の前にコード化された情報に依存し得る。一例では、ツリー構造の深度0または深度1において、QT区分構造のみが使用される。1より大きい深度において、QT、BT、およびTT区分構造の各々が使用され得る。
【0082】
[0100]いくつかの例では、ビデオエンコーダ22および/またはビデオデコーダ30は、ビデオピクチャの特定の領域またはCTUの領域に対する重複区分化を避けるために、サポートされる区分タイプに対して、あらかじめ構成された制約を適用し得る。一例では、ブロックが非対称区分タイプで分割されるとき、ビデオエンコーダ22および/またはビデオデコーダ30は、現在ブロックから分割された最大サブブロックをこれ以上分割しないように構成され得る。例えば、正方形ブロックが非対称区分タイプ(例えば、図3のPART_2NxnU区分タイプ)に従って分割されるとき、すべてのサブブロックの中の最大サブブロックは(例えば、図3のPART_2NxnU区分タイプのPU1)、述べたリーフノードであり、これ以上分割されることができない。しかし、小さい方のサブブロック(例えば、図3のPART_2NxnU区分タイプのPU0)は、さらに分割されることができる。
【0083】
[0101]特定の領域に対する重複区分化を避けるために、サポートされる区分タイプに対する制約が適用され得る別の例として、ブロックが非対称区分タイプで分割されるとき、現在ブロックから分割された最大サブブロックは、同じ方向にはこれ以上分割されることができない。例えば、正方形ブロックが、分割された非対称区分タイプ(例えば、図3のPART_2NxnU区分タイプ)であるとき、ビデオエンコーダ22および/またはビデオデコーダ30は、すべてのサブブロックの中でも大きいサブブロック(例えば、図3のPART_2NxnU区分タイプのPU1)を水平方向には分割しないように構成され得る。しかしながら、ビデオエンコーダ22および/またはビデオデコーダ30は、この例では、PU1を再び垂直方向には分割し得る。
【0084】
[0102]さらなる分割の困難さを避けるために、サポートされる区分タイプに対する制約が適用され得る別の例として、ビデオエンコーダ22および/またはビデオデコーダ30は、ブロックの幅/高さが2のべき乗ではない(例えば、幅の高さが、2、4、8、16、等でない)とき、ブロックを水平にも垂直にも分割しないように構成され得る。
【0085】
[0103]上の例は、本開示の技法に従ってMTT区分化を実行するためにビデオエンコーダ22がどのように構成され得るかを説明する。その後、ビデオデコーダ30もまた、ビデオエンコーダ22によって実行されたのと同じMTT区分化を適用し得る。いくつかの例では、ビデオデータのピクチャがビデオエンコーダ22によってどのように区分化されたかは、ビデオデコーダ30において、あらかじめ定義されたルールの同じセットを適用することで決定され得る。しかしながら、多くの状況では、ビデオエンコーダ22は、コード化されているビデオデータの特定のピクチャに対するレート歪み基準に基づいて、使用すべき特定の区分構造および区分タイプを決定し得る。このように、ビデオデコーダ30が特定のピクチャのための区分化を決定するために、ビデオエンコーダ22は、ピクチャおよびピクチャのCTUがどのように区分化されるべきかを示すシンタックス要素を、符号化されたビットストリームにおいてシグナリングし得る。ビデオデコーダ30は、そのようなシンタックス要素を解析し、それに従ってピクチャおよびCTUを区分化し得る。
【0086】
[0104]本開示の一例では、ビデオエンコーダ22は、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、スライスヘッダ、適応型パラメータセット(APS)、または任意の他の高レベルシンタックスパラメータセットにおいて、サポートされる区分タイプの特定のサブセットを高レベルシンタックス要素としてシグナリングするように構成され得。例えば、区分タイプの最大数およびどのタイプがサポートされるかは、あらかじめ定義され得るか、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、または任意の他の高レベルシンタックスパラメータセットにおいて、高レベルシンタックス要素として、ビットストリームにおいてシグナリングされ得る。ビデオデコーダ30は、使用する区分タイプの特定のサブセットおよび/またはサポートされる区分構造(例えば、QT、BT、TT、等)の最大数およびタイプを決定するためにそのようなシンタックス要素を受信し、解析するように構成され得る。
【0087】
[0105]いくつかの例では、各深度において、ビデオエンコーダ22は、ツリー構造のその深度において使用される選択された区分タイプを示すインデックスをシグナリングするように構成され得る。さらに、いくつかの例では、ビデオエンコーダ22は、各CUにおいてそのような区分タイプのインデックスを適応的にシグナリングし得る。すなわち、インデックスは、CUごとに異なり得る。例えば、ビデオエンコーダ22は、1つまたは複数のレート歪み算出に基づいて、区分タイプのインデックスを設定し得る。一例では、特定の条件が満たされる場合、区分タイプ(例えば、区分タイプのインデックス)のシグナリングは省略され得る。例えば、ビデオエンコーダ22は、特定の深度に関連付けられたサポートされる区分タイプが1つしか存在しないとき、区分タイプのシグナリングを省略し得る。この例では、ピクチャ境界に接近すると、コード化されることとなる領域は、CTUより小さいであろう。その結果として、この例では、CTUは、ピクチャ境界に収まるように強制的に分割され得る。一例では、強制的な分割に対して対称二分木のみが使用され得、いずれの区分タイプもシグナリングされない。いくつかの例では、特定の深度において、区分タイプは、スライスタイプ、CTU深度、CU位置のような、前にコード化された情報に基づいて、導出され得る。
【0088】
[0106]本開示の別の例では、CU(リーフノード)ごとに、ビデオエンコーダ22は、同じサイズのCUに対して変換が実行されるべきか否かを示すためにシンタックス要素(例えば、1ビットのtransform_splitフラグ)をシグナリングするようにさらに構成され得る(すなわち、フラグは、TUが、CUのサイズと同じサイズであるかどうかまたはさらに分割されるかどうかを示す)。transform_splitフラグが真としてシグナリングされるケースでは、ビデオエンコーダ22は、CUの残差(residual)を複数のサブブロックへとさらに分割するように構成され得、変換が各サブブロックに対して行われる。ビデオデコーダ30は、逆のプロセスを実行し得る。
【0089】
[0107]一例では、transform_splitフラグが真としてシグナリングされるとき、以下が実行される。CUが正方形ブロックに対応する(すなわち、CUが正方形である)場合、ビデオエンコーダ22は、四分木分割を使用して残差を4つの正方形サブブロックへと分割し、各正方形サブブロックに対して変換が実行される。CUが非正方形ブロック、例えばMxN、に対応する場合、ビデオエンコーダ22は、残差を2つのサブブロックへと分割し、サブブロックサイズは、M>Nであるとき0.5MxNであり、M<Nであるとき、Mx0.5Nである。別の例として、transform_splitフラグが真としてシグナリングされ、かつ、CUが非正方形ブロック、例えばMxN、に対応する(すなわち、CUが非正方形である)とき、ビデオエンコーダ22は、残差をサイズKxKのサブブロックへと分割するように構成され得、KxK正方形変換が各サブブロックに対して使用され、ここで、Kは、MおよびNの最大係数に等しい。別の例として、CUが正方形ブロックであるとき、transform_splitフラグはシグナリングされない。
【0090】
[0108]いくつかの例では、分割フラグはシグナリングされず、1つの導出されたサイズを有する変換のみが、予測後のCU中に残余(residue)があるときに使用される。例えば、MxNに等しいサイズを有するCU、KxK二乗変換が使用され、ここで、Kは、MおよびNの最大係数に等しい。ゆえに、この例では、サイズが16x8のCUの場合、同じ8x8変換が、CUの残差データの2つの8x8サブブロックに適用され得る。「分割フラグ」は、ツリー構造におけるノードがツリー構造において子ノードを有することを示すシンタックス要素である。
【0091】
[0109]いくつかの例では、各CUについて、CUが正方形四分木、または対称二分木に分割されない場合、ビデオエンコーダ22は、区分サイズ(例えば、CUのサイズ)に等しくなるように変換サイズを常に設定するように構成される。
【0092】
[0110]シミュレーション結果は、JEM-3.1参照ソフトウェアと比較して、本開示のMTT技法を使用したコーディング性能が、ランダムアクセスのケースにおいて、改善を示したことを示している。平均で、シミュレーションは、本開示のMTT技法が、適度な符号化時間の増加のみで、3.18%のビットレート-歪み(BD)レート低減をもたらしたことを示している。シミュレーションは、本開示のMTT技法が、より高い解像度に対して良好な性能、例えば、クラスA1およびクラスA2テストに対して4.20%および4.89%のルーマBDレート低減、を提供することを示している。クラスA1およびクラスA2は、例となる4K解像度テストシーケンスである。
【0093】
[0111]ビデオエンコーダ22を参照して説明した上の例の各々について、ビデオデコーダ30が、逆のプロセスを実行するように構成され得ることは理解されるべきである。シンタックス要素をシグナリングすることに関して、ビデオデコーダ30は、そのようなシンタックス要素を受信および解析し、それに従って関連するビデオデータを区分化および復号するように構成され得る。
【0094】
[0112]本開示の1つの特定の例では、ビデオデコーダは、3つの異なる区分構造(QT、BT、およびTT)に従ってビデオブロックを区分化するように構成され得、ここで、5つの異なる区分タイプが各深度において許容される。区分タイプには、図5A図5Eに示されるように、四分木区分化(QT区分構造)、水平二分木区分化(BT区分構造)、垂直二分木区分化(BT区分構造)、水平センタ-サイド三分木区分化(TT区分構造)、および垂直センタ-サイド三分木区分化(TT区分構造)が含まれる。
【0095】
[0113]5つの区分タイプの定義は以下の通りである。正方形が長方形の特別なケースとみなされることに留意されたい。
・四分木区分化:1つのブロックが、4つの同じサイズの長方形ブロックへとさらに分割される。図6Aは、四分木分区分化の例を示す。
・垂直二分木区分化:1つのブロックが、2つの同じサイズの長方形ブロックへと垂直に分割される。図6Bは、垂直二分木区分化の例である。
・水平二分木区分化:1つのブロックが、2つの同じサイズの長方形ブロックへと水平に分割される。図6Cは、水平二分木区分化の例である。
・垂直センタ-サイド三分木区分化:2つのサイドブロックが同じサイズを共有しつつ、センタブロックのサイズがこれら2つのサイドブロックの合計になるように、1つのブロックが、3つの長方形ブロックへと垂直に分割される。図6Dは、垂直センタ-サイド三分木区分化の例である。
・水平センタ-サイド三分木区分化:2つのサイドブロックが同じサイズを共有しつつ、センタブロックのサイズがこれら2つのサイドブロックの合計になるように、1つのブロックが、3つの長方形ブロックへと水平に分割される。図6Eは、水平センタ-サイド三分木区分化の例である。
【0096】
[0114]特定の深度に関連付けられたブロックについて、ビデオエンコーダ22は、どの区分タイプ(これ以上の分割がないことを含む)が使用されるかを決定し、決定された区分タイプを明示的または暗示的にビデオデコーダ30にシグナリングする(例えば、区分タイプは、所定のルールから導出され得る)。ビデオエンコーダ22は、異なる区分タイプを使用してブロックのためのレート歪みコストをチェックすることに基づいて、使用すべき区分タイプを決定し得る。レート歪みコストを得るために、ビデオエンコーダ22は、ブロックについての可能な区分タイプを再帰的にチェックする必要があり得る。
【0097】
[0115]図7は、コード化ツリー単位(CTU)区分化の例を示す概念図である。換言すると、図7は、CTUに対応するCTB91の区分化を例示する。図7の別の例では、 ・深度0において、CTB91(すなわち、CTB全体)が、(破線が一点で区切られている線93で示されるように)水平二分木区分化で2つのブロックへと分割される。
・深度1において:
・上部ブロックは、(小破線の線95および86で示されるように)垂直センタ-サイド三分木区分化で3つのブロックへと分割される。
・底部ブロックは、(破線が二点で区切られている線88および90で示されるように)四分木区分化で4つのブロックへと分割される。
・深度2において:
・深度1における上部ブロックの左側ブロックは、(長い破線が短い破線で区切られている線92および94で示されるように)水平センタ-サイド三分木区分化で3つのブロックへと分割される。
・深度1における上部ブロックのセンタブロックおよび右ブロックに対してはこれ以上の分割はない。
・深度1における底部ブロックの4つのブロックに対してはこれ以上の分割はない。
【0098】
[0116]図7の例から明らかなように、4つの異なる区分タイプ(水平二分木区分化、垂直センタ-サイド三分木区分化、四分木区分化、および水平センタ-サイド三分木区分化)を有する3つの異なる区分構造(BT、QT、およびTT)が使用される。
【0099】
[0117]別の例では、追加の制約が、特定の深度にあるまたは一定のサイズのブロックに適用され得る。例えば、ブロックの高さ/幅が16画素より小さい場合、このブロックは、4画素より小さい高さ/幅を有するブロックを避けるために、垂直/水平センタ-サイド木で分割されることができない。
【0100】
[0118]様々な例が説明されてきた。本開示の特定の例は、別個にまたは互いと組み合わせて使用され得る。
【0101】
[0119]図8は、本開示の技法をインプリメントし得る例となるビデオエンコーダ22を例示するブロック図である。図8は、説明の目的のために提供されており、本開示で広く実証および説明される技法を限定するものとみなされるべきではない。本開示の技法は、様々なコーディング規格または方法に適用可能であり得る。
【0102】
[0120]図8の例では、ビデオエンコーダ22は、予測処理ユニット100と、ビデオデータメモリ101と、残差生成ユニット102と、変換処理ユニット104と、量子化ユニット106と、逆量子化ユニット108と、逆変換処理ユニット110と、再構築ユニット112と、フィルタユニット114と、復号ピクチャバッファ116と、エントロピー符号化ユニット118とを含む。予測処理ユニット100は、インター予測処理ユニット120と、イントラ予測処理ユニット126とを含む。インター予測処理ユニット120は、動き推定ユニットと、動き補償ユニットとを含み得る(図示されない)。
【0103】
[0121]ビデオデータメモリ101は、ビデオエンコーダ22の構成要素によって符号化されるべきビデオデータを記憶するように構成され得る。ビデオデータメモリ101に記憶されたビデオデータは、例えば、ビデオソース18から取得され得る。復号ピクチャバッファ116は、例えば、イントラまたはインターコード化モードで、ビデオエンコーダ22がビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ101および復号ピクチャバッファ116は、同期動的ランダムアクセスメモリ(SDRAM)、磁気RAM(MRAM)、抵抗性RAM(RRAM(登録商標))、または他のタイプのメモリデバイスを含むDRAMのような、様々なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ101および復号ピクチャバッファ116は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ101は、ビデオエンコーダ22の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。ビデオデータメモリ101は、図1の記憶媒体20と同じまたはその一部であり得る。
【0104】
[0122]ビデオエンコーダ22は、ビデオデータを受信する。ビデオエンコーダ22は、このビデオデータのピクチャのスライス中の各CTUを符号化し得る。CTUの各々は、等しいサイズのルーマコード化ツリーブロック(CTB)およびピクチャの対応するCTBに関連付けられ得る。CTUを符号化することの一部として、予測処理ユニット100は、CTUのCTBを漸進的に小さいブロックへと分割するために区分化を実行し得る。より小さいブロックは、CUのコード化ブロックであり得る。例えば、予測処理ユニット100は、ツリー構造に従って、CTUに関連付けられたCTBを区分化し得る。本開示の1つまたは複数の技法に従って、ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容分割パターンが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの1つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。一例では、予測処理ユニット100またはビデオエンコーダ22の別の処理ユニットは、上で説明したMTT区分化技法の任意の組合せを実行するように構成され得る。
【0105】
[0123]ビデオエンコーダ22は、CUの符号化表現(すなわち、コード化されたCU)を生成するために、CTUのCUを符号化し得る。CUを符号化することの一部として、予測処理ユニット100は、CUの1つまたは複数のPUの間でCUに関連付けられたコード化ブロックを区分化し得る。本開示の技法に従って、CUは、単一のPUのみを含み得る。すなわち、本開示のいくつかの例では、CUが別々の予測ブロックへと分割されるのではなく、むしろ、予測プロセスが、このCU全体に対して実行される。ゆえに、各CUは、ルーマ予測ブロックおよび対応するクロマ予測ブロックに関連付けられ得る。ビデオエンコーダ22およびビデオデコーダ30は、様々なサイズを有するCUをサポートし得る。上に示したように、CUのサイズは、CUのルーマコード化ブロックのサイズ、そしてルーマ予測ブロックのサイズを指し得る。上で述べたように、ビデオエンコーダ22およびビデオデコーダ30は、上で説明した例となるMTT区分化タイプの任意の組合せによって定義されるCUサイズをサポートし得る。
【0106】
[0124]インター予測処理ユニット120は、CUの各PUに対してインター予測を実行することで、PUについての予測データを生成し得る。上述したように、本開示のいくつかのMTTの例では、CUは、単一のPUのみを含み得、すなわち、CUおよびPUは同義であり得る。PUについての予測データは、PUの予測ブロックおよびPUのための動き情報を含み得る。インター予測処理ユニット120は、PUが、Iスライス中にあるか、Pスライス中にあるか、Bスライス中にあるかに依存して、PUまたはCUのために異なる動作を実行し得る。Iスライスでは、すべてのPUがイントラ予測される。そのため、PUがIスライス中にある場合、インター予測処理ユニット120は、PUに対してインター予測を実行しない。ゆえに、Iモードで符号化されるブロックの場合、予測されたブロックは、同じピクチャ内の前に符号化された隣接ブロックからの空間予測を使用して形成される。PUがPスライス中にある場合、インター予測処理ユニット120は、PUの予測ブロックを生成するために、単方向性インター予測を使用し得る。PUがBスライス中にある場合、インター予測処理ユニット120は、PUの予測ブロックを生成するために、単方向性または双方向性インター予測を使用し得る。
【0107】
[0125]イントラ予測処理ユニット126は、PUに対してイントラ予測を実行することで、PUの予測データを生成し得る。PUについての予測データは、PUの予測ブロックおよび様々なシンタックス要素を含み得る。イントラ予測処理ユニット126は、Iスライス、Pスライス、およびBスライス中のPUに対してイントラ予測を実行し得る。
【0108】
[0126]PUに対してイントラ予測を実行するために、イントラ予測処理ユニット126は、PUについての予測データの複数のセットを生成するために、複数のイントラ予測モードを使用し得る。イントラ予測処理ユニット126は、PUについての予測ブロックを生成するために、隣接するPUのサンプルブロックからサンプルを使用し得る。隣接するPUは、PU、CU、およびCTUに対して左から右、上から下の符号化順序を前提として、PUの上、右上、左上、または左にあり得る。イントラ予測処理ユニット126は、様々な数のイントラ予測モード、例えば、33個の指向性イントラ予測モードを使用し得る。いくつかの例では、イントラ予測モードの数は、PUに関連付けられた領域のサイズに依存し得る。
【0109】
[0127]予測処理ユニット100は、PUについてのインター予測処理ユニット120によって生成された予測データまたはPUについてのイントラ予測処理ユニット126によって生成された予測データの中から、CUのPUについての予測データを選択し得る。いくつかの例では、予測処理ユニット100は、予測データのセットのレート/歪みメトリックに基づいて、CUのPUについての予測データを選択する。選択された予測データの予測ブロックは、ここでは、選択された予測ブロックと呼ばれ得る。
【0110】
[0128]残差生成ユニット102は、CUについてのコード化ブロック(例えば、ルーマ、Cb、およびCrコード化ブロック)と、CUのPUについての選択された予測ブロック(例えば、予測ルーマ、Cb、およびCrブロック)とに基づいて、CUについての残差ブロック(例えば、ルーマ、Cb、およびCr残差ブロック)を生成し得る。例えば、残差生成ユニット102は、残差ブロック中の各サンプルが、CUのコード化ブロック中のサンプルと、CUのPUの対応する選択された予測ブロック中の対応するサンプルとの間の差分に等しい値を有するように、CUの残差ブロックを生成し得る。
【0111】
[0129]変換処理ユニット104は、CUに関連付けられた残差ブロックをCUのTUに関連付けられた変換ブロックに区分化するために四分木区分化を実行し得る。ゆえに、TUは、1つのルーマ変換ブロックと、2つのクロマ変換ブロックとに関連付けられ得る。CUのTUのルーマおよびクロマ変換ブロックのサイズおよび位置は、CUのPUの予測ブロックのサイズおよび位置に基づく場合も基づかない場合もある。「残余四分木」(RQT)として知られている四分木構造は、領域の各々に関連付けられたノードを含み得る。CUのTUは、RQTのリーフノードに対応し得る。他の例では、変換処理ユニット104は、上で説明したMTT技法に従ってTUを区分化するように構成され得る。例えば、ビデオエンコーダ22は、RQT構造を使用して、CUをTUへとこれ以上分割することができない。このように、一例では、CUは、単一のTUを含む。
【0112】
[0130]変換処理ユニット104は、TUの変換ブロックに1つまたは複数の変換を適用することで、CUのTUごとに変換係数ブロックを生成し得る。変換処理ユニット104は、TUに関連付けられた変換ブロックに様々な変換を適用し得る。例えば、変換処理ユニット104は、変換ブロックに、離散コサイン変換(DCT)、方向性変換、または概念的に類似した変換を適用し得る。いくつかの例では、変換処理ユニット104は、変換ブロックに変換を適用しない。そのような例では、変換ブロックは、変換係数ブロックとして扱われ得る。
【0113】
[0131]量子化ユニット106は、係数ブロックにおける変換係数を量子化し得る。量子化プロセスは、これら変換係数のうちのいくつかまたはすべてに関連付けられたビット深度を低減し得る。例えば、nビット変換係数は、量子化中、mビット変換係数へと端数が切り捨てられ得、ここで、nは、mより大きい。量子化ユニット106は、CUに関連付けられた量子化パラメータ(QP)値に基づいて、CUのTUに関連付けられた係数ブロックを量子化し得る。ビデオエンコーダ22は、CUに関連付けられたQP値を調整することで、CUに関連付けられた係数ブロックに適用される量子化の程度を調整し得る。量子化は、情報の損失を引き起こし得る。ゆえに、量子化された変換係数は、元のものより低い精度を有し得る。
【0114】
[0132]逆量子化ユニット108および逆変換処理ユニット110は、係数ブロックから残差ブロックを再構築するために、それぞれ、係数ブロックに逆量子化および逆変換を適用し得る。再構築ユニット112は、TUに関連付けられた再構築された変換ブロックを作り出すために、再構築された残差ブロックを、予測処理ユニット100によって生成された1つまたは複数の予測ブロックからの対応するサンプルに加算し得る。このようにしてCUのTUごとに変換ブロックを再構築することで、ビデオエンコーダ22は、CUのコード化ブロックを再構築し得る。
【0115】
[0133]フィルタユニット114は、CUに関連付けられたコード化ブロック中のブロッキングアーティファクトを低減するために、1つまたは複数のデブロッキング動作を実行し得る。復号ピクチャバッファ116は、フィルタユニット114が再構築されたコード化ブロックに対して1つまたは複数のデブロッキング動作を実行した後に、再構築されたコード化ブロックを記憶し得る。インター予測処理ユニット120は、他のピクチャのPUに対してインター予測を実行するために、再構築されたコード化ブロックを含む参照ピクチャを使用し得る。加えて、イントラ予測処理ユニット126は、CUと同じピクチャ中の他のPUに対してイントラ予測を実行するために、復号ピクチャバッファ116中の再構築されたコード化ブロックを使用し得る。
【0116】
[0134]エントロピー符号化ユニット118は、ビデオエンコーダ22の他の機能構成要素からデータを受け取り得る。例えば、エントロピー符号化ユニット118は、量子化ユニット106から係数ブロックを受け取り得、予測処理ユニット100からシンタックス要素を受け取り得る。エントロピー符号化ユニット118は、エントロピー符号化済みデータを生成するために、データに対して1つまたは複数のエントロピー符号化動作を実行し得る。例えば、エントロピー符号化ユニット118は、データに対して、CABAC動作、コンテキスト適応型可変長コード(CAVLC)動作、V2V(variable-to-variable)長コード化動作、シンタックスベースコンテキスト適応型バイナリ算術コード化(SBAC)動作、確立間隔区分化エントロピー(PIPE)コード化動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作を実行し得る。ビデオエンコーダ22は、エントロピー符号化ユニット118によって生成されたエントロピー符号化済みデータを含むビットストリームを出力し得る。例えば、ビットストリームは、本開示の技法に従ってCUのための区分構造を表すデータを含み得る。
【0117】
[0135]図9は、本開示の技法をインプリメントするように構成された例となるビデオデコーダ30を例示するブロック図である。図9は、説明の目的のために提供されており、本開示で広く実証および説明される技法を限定するものではない。説明の目的のために、本開示は、HEVCコード化のコンテキストでビデオデコーダ30を説明する。しかしながら、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。
【0118】
[0136]図9の例では、ビデオデコーダ30は、エントロピー復号ユニット150と、ビデオデータメモリ151と、予測処理ユニット152と、逆量子化ユニット154と、逆変換処理ユニット156と、再構築ユニット158と、フィルタユニット160と、復号ピクチャバッファ162とを含む。予測処理ユニット152は、動き補償ユニット164と、イントラ予測処理ユニット166とを含む。他の例では、ビデオデコーダ30は、より多い数の、より少ない数の、または異なる機能構成要素を含み得る。
【0119】
[0137]ビデオデータメモリ151は、ビデオデコーダ30の構成要素によって復号されることとなる、符号化されたビデオビットビットストリームのような符号化されたビデオデータを記憶し得る。ビデオデータメモリ151に記憶されたビデオデータは、例えば、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介してまたは物理データ記憶媒体にアクセスすることで、コンピュータ可読媒体16から、例えば、カメラのようなローカルビデオソースから、取得され得る。ビデオデータメモリ151は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶するコード化ピクチャバッファ(CPB)を形成し得る。復号ピクチャバッファ162は、例えば、イントラまたはインターコード化モードで、ビデオデコーダ30がビデオデータを復号する際に使用するためのまたは出力のための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ151および復号ピクチャバッファ162は、同期動的ランダムアクセスメモリ(SDRAM)、磁気RAM(MRAM)、抵抗性RAM(RRAM)、または他のタイプのメモリデバイスを含むDRAMのような、様々なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ151および復号ピクチャバッファ162は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ151は、ビデオデコーダ30の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。ビデオデータメモリ151は、図1の記憶媒体28と同じまたはその一部であり得る。
【0120】
[0138]ビデオデータメモリ151は、ビットストリームの符号化されたビデオデータ(例えば、NAL単位)を受け取り、記憶する。エントロピー復号ユニット150は、ビデオデータメモリ151から符号化されたビデオデータ(例えば、NAL単位)を受け取り、シンタックス要素を取得するためにこのNAL単位を解析し得る。エントロピー復号ユニット150は、NAL単位中のエントロピー符号化されたシンタックス要素をエントロピー復号し得る。予測処理ユニット152、逆量子化ユニット154、逆変換処理ユニット156、再構築ユニット158、およびフィルタユニット160は、ビットストリームから抽出されたシンタックス要素に基づいて、復号されたビデオデータを生成し得る。エントロピー復号ユニット150は、エントロピー符号化ユニット118のプロセスとは概ね逆のプロセスを実行し得る。
【0121】
[0139]本開示のいくつかの例に従って、エントロピー復号ユニット150、またはビデオデコーダ30の別の処理ユニットは、ビットストリームからシンタックス要素を取得することの一部としてツリー構造を決定し得る。ツリー構造は、CTBのような初期ビデオブロックがコード化単位のようなより小さいビデオブロックへとどのように区分化されるかを指定し得る。本開示の1つまたは複数の技法に従って、ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な分割パターンのうちの1つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。
【0122】
[0140]ビットストリームからシンタックス要素を取得することに加えて、ビデオデコーダ30は、非区分化CUに対して再構築動作を実行し得る。CUに対して再構築動作を実行するために、ビデオデコーダ30は、CUの各TUに対して再構築動作を実行し得る。CUの各TUに対して再構築動作を実行することで、ビデオデコーダ30は、CUの残差ブロックを再構築し得る。上で述べたように、本開示の一例では、CUは、単一のTUを含む。
【0123】
[0141]CUのTUに対して再構築動作を実行することの一部として、逆量子化ユニット154は、TUに関連付けられた係数ブロックを逆量子化(inverse quantize)、すなわち逆量子化(de-quantize)し得る。逆量子化ユニット154が係数ブロックを逆量子化した後、逆変換処理ユニット156は、TUに関連付けられた残差ブロックを生成するために、この係数ブロックに1つまたは複数の逆変換を適用し得る。例えば、逆変換処理ユニット156は、係数ブロックに、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT)、逆回転変換、逆方向性変換、または別の逆変換を適用し得る。
【0124】
[0142]CUまたはPUがイントラ予測を使用して符号化される場合、イントラ予測処理ユニット166は、PUの予測ブロックを生成するために、イントラ予測を実行し得る。イントラ予測処理ユニット166は、ブロックに空間的に隣接するサンプルに基づいて、PUの予測ブロックを生成するために、イントラ予測モードを使用し得る。イントラ予測処理ユニット166は、ビットストリームから取得された1つまたは複数のシンタックス要素に基づいて、PUのためのイントラ予測モードを決定し得る。
【0125】
[0143]PUがインター予測を使用して符号化される場合、エントロピー復号ユニット150は、PUについての動き情報を決定し得る。動き補償ユニット164は、PUの動き情報に基づいて、1つまたは複数の参照ブロックを決定し得る。動き補償ユニット164は、1つまたは複数の参照ブロックに基づいて、PUについての予測ブロック(例えば、予測ルーマ、Cb、およびCrブロック)を生成し得る。上で述べたように、MTT区分化を使用する本開示の一例では、CUは、単一のPUのみを含み得る。すなわち、CUは、複数のPUへと分割されないであろう。
【0126】
[0144]再構築ユニット158は、CUについてのコード化ブロック(例えば、ルーマ、Cb、およびCrコード化ブロック)を再構築するために、CUのTUのための変換ブロック(例えば、ルーマ、Cb、およびCr変換ブロック)およびCUのPUの予測ブロック(例えば、ルーマ、Cb、およびCrブロック)、すなわち、適用可能な場合、イントラ予測データまたはインター予測データのいずれかを使用し得る。例えば、再構築ユニット158は、CUのコード化ブロック(例えば、ルーマ、Cb、およびCrコード化ブロック)を再構築するために、変換ブロック(例えば、ルーマ、Cb、およびCr変換ブロック)のサンプルを、予測ブロック(例えば、ルーマ、Cb、およびCr予測ブロック)の対応するサンプルに加算し得る。
【0127】
[0145]フィルタユニット160は、CUのコード化ブロックに関連付けられたブロッキングアーティファクトを低減するためにデブロッキング動作を実行し得る。ビデオデコーダ30は、CUのコード化ブロックを復号ピクチャバッファ162に記憶し得る。復号ピクチャバッファ162は、後続の動き補償、イントラ予測、および、図1のディスプレイデバイス32のようなディスプレイデバイス上での提示のために、参照ピクチャを提供し得る。例えば、ビデオデコーダ30は、復号ピクチャバッファ162中のブロックに基づいて、他のCUのPUのためにイントラ予測またはインター予測動作を実行し得る。
【0128】
[0146]図10Aは、本開示の技法に係る、ビデオエンコーダ22の例となる動作を例示するフローチャートである。図10Aの例では、ビデオエンコーダ22は、ビデオデータの初期ビデオブロック(例えば、コード化ツリーブロック)の符号化表現を生成し得る(200)。初期ビデオブロックの符号化表現を生成することの一部として、ビデオエンコーダ22は、複数のノードを備えるツリー構造を決定する。複数のノードは、複数のリーフノードおよび複数の非リーフノードを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロック(例えば、コード化ブロック)に対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において1つまたは複数の子ノードを有する。ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して3つ以上の区分構造(例えば、BT、QT、およびTT区分構造)の複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な区分タイプのうちの1つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容区分タイプの各それぞれの許容区分タイプは、それぞれの非リーフノードに対応するビデオブロックをそれぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応し得る。さらに、この例では、ビデオエンコーダ22は、ビデオデータの符号化表現を備えるビットストリーム中に初期ビデオブロックの符号化表現を含め得る(202)。
【0129】
[0147]図10Bは、本開示の技法に係る、ビデオデコーダ30の例となる動作を例示するフローチャートである。図10Bの例では、ビデオデコーダ30は、複数のノードを備えるツリー構造を決定し得る(250)。複数のノードは、複数のリーフノードと、複数の非リーフノードとを含む。リーフノードは、ツリー構造において子ノードを有さない。非リーフノードは、ツリー構造のルートノードを含む。ルートノードは、ビデオデータの初期ビデオブロックに対応する。複数のノードの各それぞれの非ルートノードについて、それぞれの非ルートノードは、それぞれの非ルートノードのツリー構造における親ノードに対応するビデオブロックのサブブロックであるビデオブロックに対応する。複数の非リーフノードの各それぞれの非リーフノードは、ツリー構造において1つまたは複数の子ノードを有する。ツリー構造の各深度レベルにあるツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対して3つ以上の区分構造(例えば、BT、QT、およびTT区分構造)の複数の許容区分タイプが存在し、それぞれの非リーフノードに対応するビデオブロックは、複数の許容可能な区分タイプのうちの1つに従って、それぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化される。複数の許容区分タイプの各それぞれの許容区分タイプは、それぞれの非リーフノードに対応するビデオブロックをそれぞれの非リーフノードの子ノードに対応するビデオブロックへと区分化する異なる方法に対応する。さらに、この例では、ツリー構造の各(または少なくとも1つの)それぞれのリーフノードについて、ビデオデコーダ30は、それぞれのリーフノードに対応するビデオブロックを再構築する(252)。
【0130】
[0148]図10Aおよび図10Bの例では、ルートノード以外のツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対する複数の許容区分タイプは、それに従ってそれぞれの非リーフノードの親ノードに対応するビデオブロックがそれぞれの非リーフノードの親ノードの子ノードに対応するビデオブロックへと区分化される分割パターンから独立しているであろう。例えば、VCEG proposal COM16-C966とは異なり、特定のノードのビデオブロックが二分木分割パターンに従って分割される場合、特定のノードの子ノードのビデオブロックは、四分木分割パターンに従って分割され得る。
【0131】
[0149]さらに、図10Aおよび図10Bの例では、ツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードに対する複数の許容分割パターンは、正方形四分木分割パターン、長方形四分木分割パターン、対称二分木分割パターン、非対称二分木分割パターン、対称三分木分割パターン、または非対称三分木分割パターンのうちの2つ以上を含み得る。
【0132】
[0150]さらに、上に示したように、前述した区分タイプのサブセットのみが使用される。サポートされる区分タイプのサブセットは、ビットストリームにおいてシグナリングされるか、あらかじめ定義されているであろう。ゆえに、いくつかの例では、ビデオデコーダ30は、複数のサポートされる分割パターンを示すシンタックス要素を、ビットストリームから、取得し得る。同様に、ビデオエンコーダ22は、複数のサポートされる分割パターンを、ビットストリームにおいて、シグナリングし得る。これらの例では、ツリー構造の各それぞれの非リーフノードについて、複数のサポートされる分割パターンは、それぞれの非リーフノードに対する複数の許容分割パターンを含み得る。これらの例では、複数のサポートされる分割パターンを示すシンタックス要素は、例えば、シーケンスパラメータセット(SPS)またはピクチャパラメータセット(PPS)またはスライスヘッダにおいて、ビットストリームから取得(および、それにおいてシグナリング)され得る。
【0133】
[0151]上に示したように、いくつかの例では、サブツリーが非対称三分木に分割されるとき、これら3つの区分のうちの2つが同じサイズを有するという制約が適用される。したがって、いくつかの例では、ビデオデコーダ30は、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードの2つの子ノードに対応するビデオブロックが同じサイズを有することを規定する、制約に適合する初期ビデオブロックの符号化表現を受信し得る。同様に、ビデオエンコーダ22は、ツリー構造のノードに対応するビデオブロックが非対称三分木パターンに従って区分化されるとき、このノードの2つの子ノードに対応するビデオブロックが同じサイズを有することを規定する制約に適合するように、初期ビデオブロックの符号化表現を生成し得る。
【0134】
[0152]上に示したように、いくつかの例では、サポートされる区分タイプの数は、すべてのCTUにおいてすべての深度に対して固定であり得る。例えば、ツリー構造の各非リーフノードに対する複数の許容分割パターン中の許容分割パターンは同じ数であり得る。追加的に、上に示したように、他の例では、サポートされる区分タイプの数は、深度、スライスタイプ、CTUタイプ、または他の前にコード化された情報に依存し得る。例えば、ツリー構造の少なくとも1つの非リーフノードについて、非リーフノードに対する複数の許容分割パターン中の許容分割パターンの数は、ツリー構造における非リーフノードの深度、ツリー構造における非リーフノードに対応するビデオブロックのサイズ、スライスタイプ、または前にコード化された情報、のうちの少なくとも1つに依存する。
【0135】
[0153]いくつかの例では、ブロックが非対称区分タイプ(例えば、PART_2NxnU、PART 2NxnD、PART_nLx2N、PART_nRx2Nを含む、図3に示される非対称二分木区分タイプ)で分割されるとき、現在ブロックから分割された最大サブブロックは、これ以上分割されることはできない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、ツリー構造の任意の非リーフノードに対応するビデオブロックが非対称分割パターンに従って複数のサブブロックへと分割されるとき、複数のサブブロックのうちの最大サブブロックがツリー構造のリーフノードに対応することを必要とし得る。
【0136】
[0154]いくつかの例では、ブロックが非対称区分タイプで分割されるとき、現在ブロックから分割された最大サブブロックは、同じ方向にはこれ以上分割されることができない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、ツリー構造の任意の非リーフノードに対応するビデオブロックが非対称分割パターンに従って複数のサブブロックへと第1の方向に分割されるとき、ツリー構造が、複数のサブブロックのうちの最大サブブロックから第1の方向に分割された複数のサブブロックのうちの最大サブブロックのサブブロックに対応するノードを含むことができないことを必要とし得る。
【0137】
[0155]いくつかの例では、ブロックの幅/高さが2の累乗ではないとき、これ以上の水平/垂直分割は許容されない。例えば、初期ビデオブロックがどのように符号化されるかに対する制約は、高さまたは幅が2の累乗ではないビデオブロックに対応するツリー構造のノードがリーフノードであることを必要とし得る。
【0138】
[0156]いくつかの例では、各深度において、選択された区分タイプのインデックスがビットストリームにおいてシグナリングされる。ゆえに、いくつかの例では、ビデオエンコーダ22は、それに従ってツリー構造の非リーフノードに対応するビデオブロックが非リーフノードの子ノードに対応するビデオブロックへと分割される分割パターンのインデックスを、ビットストリーム中に、含め得る。同様に、いくつかの例では、ビデオデコーダ30は、それに従ってツリー構造の非リーフノードに対応するビデオブロックが非リーフノードの子ノードに対応するビデオブロックへと分割される分割パターンのインデックスを、ビットストリームから、取得し得る。
【0139】
[0157]いくつかの例では、CU(リーフノード)ごとに、CUと同じサイズを有する変換が行われるか否かを示すために、1ビットのtransform_splitフラグがさらにシグナリングされる。transform_splitフラグが真としてシグナリングされるケースでは、CUの残差は、複数のサブブロックへとさらに分割され、各サブブロックに対して変換が行われる。したがって、一例では、ツリー構造の少なくとも1つのリーフノードについて、ビデオエンコーダ22は、ビットストリーム中にシンタックス要素を含め得る。この例では、第1の値を有するシンタックス要素は、リーフノードに対応するビデオブロックと同じサイズを有する変換がリーフノードに対応するビデオブロックの残差データに適用されることを示し、第2の値を有するシンタックス要素は、リーフノードに対応するビデオブロックより小さいサイズを有する複数の変換がリーフノードに対応するビデオブロックの残差データのサブブロックに適用されることを示す。同様の例では、ツリー構造の少なくとも1つのリーフノードについて、ビデオデコーダ30は、ビットストリームからこのシンタックス要素を取得し得る。
【0140】
[0158]いくつかの例では、いずれの分割フラグもシグナリングされず、1つの導出されたサイズを有する変換のみが、CUに残余があるときに対して使用される。例えば、ツリー構造の少なくとも1つのリーフノードについて、ビデオエンコーダ22は、残差データをサンプルドメインから変換ドメインに変換するために、リーフノードに対応するビデオブロックに対応する残差データの異なる部分に同じ変換(例えば、離散コサイン変換、離散サイン変換、等)を適用し得る。サンプルドメインでは、残差データは、サンプル(例えば、画素の成分)の値を単位として表される。変換ドメインでは、残差データは、周波数係数を単位として表され得る。同様に、ツリー構造の少なくとも1つのリーフノードについて、ビデオデコーダ30は、残差データを変換ドメインからサンプルドメインに変換するために、リーフノードに対応するビデオブロックに対応する残差データの異なる部分に同じ変換(すなわち、逆離散コサイン変換、逆サイン変換、等)を適用し得る。
【0141】
[0159]いくつかの例では、各CUについて、このCUが正方形四分木または対称二分木に分割されない場合、変換サイズは、常に、区分サイズのサイズに等しく設定される。例えば、正方形四分木分割パターンまたは対称二分木分割パターンに従って区分化されたビデオブロックに対応するツリー構造の各それぞれの非リーフノードについて、それぞれの非リーフノードの子ノードに対応するビデオブロックの残差データに適用される変換の変換サイズは、常に、それぞれの非リーフノードの子ノードに対応するビデオブロックのサイズに常に等しく設定される。
【0142】
[0160]図11は、本開示の別の例となる技法に係る、ビデオエンコーダの例となる動作を例示するフローチャートである。予測処理ユニット100を含む、ビデオエンコーダ22の1つまたは複数の構造要素は、図11の技法を実行するように構成され得る。
【0143】
[0161]本開示の一例では、ビデオエンコーダ22は、ビデオデータのピクチャを受信すること(300)と、3つ以上の異なる区分構造を使用してビデオデータのピクチャを複数のブロックへと区分化すること(302)と、ビデオデータのピクチャの複数のブロックを符号化すること(304)とを行うように構成され得る。本開示の一例では、ビデオエンコーダ22は、3つ以上の異なる区分構造を使用して複数のブロックへとビデオデータのピクチャを区分化するように構成され得、ここにおいて、3つ以上の異なる区分構造のうちの少なくとも3つは、ビデオデータのピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る。一例では、3つ以上の異なる区分構造は、三分木区分構造を含み、ビデオエンコーダ22は、三分木区分構造の三分木区分タイプを使用してビデオデータの特定のブロックを区分化するようにさらに構成され、ここにおいて、三分木区分構造は、特定のブロックの中心を通って特定のブロックを分割することなく特定のブロックを3つのサブブロックへと分割し、3つのサブブロックのうちのセンタブロックは、3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、3つのサブブロックのうちの他の2つのブロックは、同じサイズを有する。
【0144】
[0162]本開示の別の例では、3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。本開示の別の例では、四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む。
【0145】
[0163]本開示の別の例では、ビデオエンコーダ22は、3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームにおいて、生成するようにさらに構成される。一例では、ビットストリームからシンタックス要素を生成することは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数においてシンタックス要素を生成することを含む。
【0146】
[0164]本開示の別の例では、ビデオエンコーダ22は、ビデオデータのピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を生成することと、特定のブロックの2つのサブブロックが同じサイズを有するように、ビデオデータのピクチャの特定のブロックを区分化することとを行うようにさらに構成される。
【0147】
[0165]本開示の別の例では、複数のブロックは、リーフノードに対応する特定のブロックを含み、ビデオエンコーダ22は、ビットストリームにおいてシンタックス要素を生成することと、ここで、第1の値を有するシンタックス要素は、リーフノードに対応するビデオデータのピクチャの特定のブロックと同じサイズを有する変換がリーフノードに対応する特定のブロックの残差データに適用されることを示し、第2の値を有するシンタックス要素は、リーフノードに対応する特定のビデオより小さいサイズを有する複数の変換がリーフノードに対応する特定のブロックの残差データのサブブロックに適用されることを示す、シンタックス要素に従って、ビデオデータの特定のブロックの残差データに1つまたは複数の変換を適用することとを行うようにさらに構成される。
【0148】
[0166]図12は、本開示の別の例となる技法に係る、ビデオデコーダの例となる動作を例示するフローチャートである。エントロピー復号ユニット150および/または予測処理ユニット152を含む、ビデオデコーダ30の1つまたは複数の構造要素は、図12の技法を実行するように構成され得る。
【0149】
[0167]本開示の一例では、ビデオデコーダ30は、ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信すること(400)と、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定すること(402)と、ビデオデータのコード化されたピクチャの複数のブロックを再構築すること(404)とを行うように構成される。一例では、ビデオデコーダ30は、3つ以上の異なる区分構造を使用した複数のブロックへのビデオデータのコード化されたピクチャの区分化を決定するように構成され、ここにおいて、3つ以上の異なる区分構造のうちの少なくとも3つは、ビデオデータのコード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る。一例では、3つ以上の異なる区分構造は、三分木区分構造を含み、ビデオデコーダ30は、三分木区分構造の三分木区分タイプを使用したビデオデータの特定のブロックの区分化を決定するようにさらに構成され、ここにおいて、三分木区分構造は、特定のブロックの中心を通って特定のブロックを分割することなく特定のブロックを3つのサブブロックへと分割し、3つのサブブロックのうちのセンタブロックは、3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、3つのサブブロックのうちの他の2つのブロックは、同じサイズを有する。
【0150】
[0168]本開示の別の例では、3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む。別の例では、四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む。
【0151】
[0169]本開示の別の例では、ビデオデコーダ30は、3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームから、受信することと、受信されたシンタックス要素に基づいて、ビデオデータのコード化されたピクチャの区分化を決定することとを行うようにさらに構成される。本開示の別の例では、ビデオデコーダ30は、ビットストリームからシンタックス要素を受信するようにさらに構成され、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数においてシンタックス要素を受信することを含む。
【0152】
[0170]本開示の別の例では、ビデオデコーダ30は、ビデオデータのコード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、特定のブロックの2つのサブブロックが同じサイズを有するようなビデオデータのコード化されたピクチャの特定のブロックの区分化を決定することとを行うようにさらに構成される。
【0153】
[0171]本開示の別の例では、複数のブロックは、リーフノードに対応する特定のブロックを含み、ビデオデコーダ30は、ビットストリームからシンタックス要素を受信することと、ここで、第1の値を有するシンタックス要素は、リーフノードに対応するビデオデータのコード化されたピクチャの特定のブロックと同じサイズを有する変換がリーフノードに対応する特定のブロックの残差データに適用されることを示し、第2の値を有するシンタックス要素は、リーフノードに対応する特定のブロックより小さいサイズを有する複数の変換がリーフノードに対応する特定のブロックの残差データのサブブロックに適用されることを示す、シンタックス要素に従って、ビデオデータの特定のブロックに1つまたは複数の変換を適用することとを行うようにさらに構成される。
【0154】
[0172]本開示の特定の態様は、例示の目的でHEVC規格の拡張に関連して説明されている。しかしながら、本開示で説明された技法は、未だ開発されていない他の標準的なまたは所有権を有するビデオコード化プロセスを含む、他のビデオコード化プロセスに有益であり得る。
【0155】
[0173]本開示で説明したように、ビデオコーダは、ビデオエンコーダまたはビデオデコーダを指し得る。同様に、ビデオコード化ユニットは、ビデオエンコーダまたはビデオデコーダを指し得る。同じく、ビデオコード化は、適用可能な場合、ビデオ符号化またはビデオ復号を指し得る。本開示では、「~に基づいて」という表現は、~のみに基づいて、~に少なくとも部分的に基づいて、または~に何らかの方法で基づいて、を示し得る。本開示は、1つまたは複数のサンプルブロックのサンプルをコード化するために使用される1つまたは複数のサンプルブロックおよびシンタックス構造を指すために「ビデオ単位」または「ビデオブロック」または「ブロック」という用語を使用し得る。例となるタイプのビデオ単位には、CTU、CU、PU、変換単位(TU)、マクロブロック、マクロブロック区分、等が含まれ得る。いくつかのコンテキストでは、PUについての考察は、マクロブロックまたはマクロブロック区分についての考察と置き換えられ得る。例となるタイプのビデオブロックには、コード化ツリーブロック、コード化ブロック、およびビデオデータの他のタイプのブロックが含まれ得る。
【0156】
[0174]例によっては、ここで説明した技法のうちの任意のものの特定の動作(act)またはイベントが、異なる順序で実行されることができ、追加、混合、または完全に省略され得る(例えば、説明したすべての動作またはイベントが本技法の実施に必要なわけではない)ことは認識されるべきである。さらに、特定の例では、動作またはイベントは、連続というよりはむしろ、例えば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、コンカレントに実行され得る。
【0157】
[0175]1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せでインプリメントされ得る。ソフトウェアでインプリメントされる場合、これらの機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体に記憶されるか、またはコンピュータ可読媒体を通して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの移送を容易にする任意の媒体を含む通信媒体またはデータ記憶媒体のような有体の媒体に対応するコンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は一般に、(1)非一時的である有形のコンピュータ可読記憶媒体または(2)信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法のインプリメンテーションのための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセス可能な任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【0158】
[0176]限定ではなく例として、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、フラッシュメモリ、またはデータ構造もしくは命令の形式で所望のプログラムコードを記憶もしくは搬送するために使用可能でありかつコンピュータによってアクセス可能な任意の他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ可読媒体と称される。例えば、命令が、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、電波、およびマイクロ波のようなワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、電波、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的な媒体を含むのではなく、代わりに、非一時的な有形の記憶媒体を対象としていることは理解されるべきである。ここで使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ここで、ディスク(disk)は、通常磁気的にデータを再生し、ディスク(disc)は、レーザーを用いて光学的にデータを再生する。上記の組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
【0159】
[0177]命令は、1つまたは複数のデジタルシグナルプロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の同等の集積またはディスクリート論理回路のような1つまたは複数のプロセッサによって実行され得る。したがって、ここで使用される場合、「プロセッサ」という用語は、前述の構造またはここで説明された技法のインプリメンテーションに適切な任意の他の構造のうちの任意のものを指し得る。加えて、いくつかの態様では、ここで説明された機能性は、符号化および復号のために構成された専用ハードウェアおよび/またはソフトウェアモジュール内に提供され得るか、複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理素子において十分にインプリメントされ得る。
【0160】
[0178]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(例えば、チップセット)を含む、幅広い種類のデバイスまたは装置においてインプリメントされ得る。様々な構成要素、モジュール、またはユニットは、本開示では、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するように説明されているが、必ずしも、異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上で説明したように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられるか、適切なソフトウェアおよび/またはファームウェアと併せて、上で説明したような1つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。
【0161】
[0179]様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。
図1
図2
図3
図4A
図4B
図5A
図5B
図6A
図6B
図6C
図6D
図6E
図7
図8
図9
図10A
図10B
図11
図12
【手続補正書】
【提出日】2022-01-18
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオデータを復号する方法であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、ここにおいて、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得、前記少なくとも3つの異なる区分構造は、三分木区分構造を含み、
前記三分木区分構造の三分木区分タイプを使用した前記少なくとも1つの深度における1つのブロックの前記区分化と、四分木区分構造または二分木区分構造を使用した前記少なくとも1つの深度における別の1つのブロックの前記区分化と、を決定することと、ここにおいて、前記三分木区分構造は、前記1つのブロックの中心線を通って前記1つのブロックを分割することなく前記1つのブロックを3つのサブブロックへと分割し、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと、
を備え、
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも1つの深度に対する前記少なくとも3つの異なる区分構造に対応する複数のサポートされる区分タイプを示す第1のシンタックス要素に基づき、前記コード化されたピクチャの前記区分化を決定することを備え、
前記少なくとも1つの深度における前記1つのブロックの前記区分化を決定することは、前記ビットストリームから受信される、前記少なくとも1つの深度における前記1つのブロックが前記三分木区分構造の前記三分木区分タイプを使用して区分化されることを示す第2のシンタックス要素に基づく、方法。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0161
【補正方法】変更
【補正の内容】
【0161】
[0179]様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビデオデータを復号する方法であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を備える、方法。
[C2]
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することは、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することを備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
[C1]に記載の方法。
[C3]
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
[C2]に記載の方法。
[C4]
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
[C3]に記載の方法。
[C5]
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
[C4]に記載の方法。
[C6]
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
をさらに備える、[C1]に記載の方法。
[C7]
前記シンタックス要素を受信することは、前記ビットストリームから前記シンタックス要素を受信することを備え、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を受信することを含む、
[C6]に記載の方法。
[C8]
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの2つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの区分化を決定することと
をさらに備える、[C1]に記載の方法。
[C9]
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、 前記ビットストリームからシンタックス要素を受信すること、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに1つまたは複数の変換を適用することと
をさらに備える、[C1]に記載の方法。
[C10]
ビデオデータを符号化する方法であって、
前記ビデオデータのピクチャを受信することと、
3つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを複数のブロックへと区分化することと、
前記ビデオデータの前記ピクチャの前記複数のブロックを符号化することと
を備える、方法。
[C11]
前記ビデオデータの前記ピクチャを区分化することは、前記3つ以上の異なる区分構造を使用して前記ビデオデータの前記ピクチャを前記複数のブロックに区分化することを備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記ピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
[C10]に記載の方法。
[C12]
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記方法は、
前記三分木区分構造の三分木区分タイプを使用して前記ビデオデータの前記特定のブロックを区分化することをさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
[C11]に記載の方法。
[C13]
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
[C12]に記載の方法。
[C14]
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
[C13]に記載の方法。
[C15]
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、ビットストリームにおいて、生成すること
をさらに備える、[C10]に記載の方法。
[C16]
前記シンタックス要素を生成することは、ビットストリームから前記シンタックス要素を生成することを備え、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を生成することを含む、
[C15]に記載の方法。
[C17]
前記ビデオデータの前記ピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を生成することと、 前記特定のブロックの2つのサブブロックが同じサイズを有するように、前記ビデオデータの前記ピクチャの前記特定のブロックを区分化することと
をさらに備える、[C10]に記載の方法。
[C18]
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記方法は、 ビットストリームにおいてシンタックス要素を生成すること、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記ピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のビデオより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、と、
前記シンタックス要素に従って、前記ビデオデータの前記特定のブロックの前記残差データに1つまたは複数の変換を適用することと
をさらに備える、[C10]に記載の方法。
[C19]
ビデオデータを復号するように構成された装置であって、
前記ビデオデータを記憶するように構成されたメモリと、
ビデオ復号回路と
を備え、前記ビデオ復号回路は、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信することと、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定することと、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築することと
を行うように構成される、装置。
[C20]
前記ビデオ復号回路は、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するようにさらに構成され、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
[C19]に記載の装置。
[C21]
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記ビデオ復号回路は、 前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するようにさらに構成され、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
[C20]に記載の装置。
[C22]
前記3つ以上の異なる区分構造は、四分木区分構造および二分木区分構造をさらに含む、
[C21]に記載の装置。
[C23]
前記四分木区分構造の区分タイプは、正方形四分木区分タイプまたは長方形四分木区分タイプのうちの1つまたは複数を含み、
前記二分木区分構造の区分タイプは、対称二分木区分タイプまたは非対称二分木区分タイプのうちの1つまたは複数を含み、
前記三分木区分構造のための区分タイプは、対称三分木区分タイプまたは非対称三分木区分タイプのうちの1つまたは複数を含む、
[C22]に記載の装置。
[C24]
前記ビデオ復号回路は、
前記3つ以上の異なる区分構造の複数のサポートされる区分タイプを示すシンタックス要素を、前記ビットストリームから、受信することと、
前記受信されたシンタックス要素に基づいて、前記ビデオデータの前記コード化されたピクチャの前記区分化を決定することと
を行うようにさらに構成される、[C19]に記載の装置。
[C25]
前記ビデオ復号回路は、前記ビットストリームから前記シンタックス要素を受信するようにさらに構成され、これは、適応型パラメータセット(APS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数において前記シンタックス要素を受信することを含む、
[C24]に記載の装置。
[C26]
前記ビデオ復号回路は、
前記ビデオデータの前記コード化されたピクチャの特定のブロックが、対称三分木区分タイプを有する三分木区分構造を使用して区分化されることを示すシンタックス要素を受信することと、
前記特定のブロックの2つのサブブロックが同じサイズを有するような前記ビデオデータの前記コード化されたピクチャの前記特定のブロックの前記区分化を決定することと を行うようにさらに構成される、[C19]に記載の装置。
[C27]
前記複数のブロックは、リーフノードに対応する特定のブロックを含み、前記ビデオ復号回路は、
ビットストリームからシンタックス要素を受信することと、ここで、第1の値を有する前記シンタックス要素は、前記リーフノードに対応する前記ビデオデータの前記コード化されたピクチャの前記特定のブロックと同じサイズを有する変換が前記リーフノードに対応する前記特定のブロックの残差データに適用されることを示し、第2の値を有する前記シンタックス要素は、前記リーフノードに対応する前記特定のブロックより小さいサイズを有する複数の変換が前記リーフノードに対応する前記特定のブロックの前記残差データのサブブロックに適用されることを示す、
前記シンタックス要素に従って、ビデオデータの前記特定のブロックに1つまたは複数の変換を適用することと
を行うようにさらに構成される、[C19]に記載の装置。
[C28]
ビデオデータを復号するように構成された装置であって、
前記ビデオデータのコード化されたピクチャの表現を形成するビットのシーケンスを含むビットストリームを受信するための手段と、
3つ以上の異なる区分構造を使用した複数のブロックへの前記ビデオデータの前記コード化されたピクチャの区分化を決定するための手段と、
前記ビデオデータの前記コード化されたピクチャの前記複数のブロックを再構築するための手段と
を備える装置。
[C29]
前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための前記手段は、前記3つ以上の異なる区分構造を使用した前記複数のブロックへの前記ビデオデータの前記コード化されたピクチャの前記区分化を決定するための手段を備え、前記3つ以上の異なる区分構造のうちの少なくとも3つは、前記ビデオデータの前記コード化されたピクチャの特定のブロックがどのように区分化されるかを表すツリー構造の少なくとも1つの深度に対して使用され得る、
[C28]に記載の装置。
[C30]
前記3つ以上の異なる区分構造は、三分木区分構造を含み、前記装置は、
前記三分木区分構造の三分木区分タイプを使用した前記ビデオデータの前記特定のブロックの前記区分化を決定するための手段をさらに備え、
前記三分木区分構造は、前記特定のブロックの中心を通って前記特定のブロックを分割することなく前記特定のブロックを3つのサブブロックへと分割し、前記3つのサブブロックのうちのセンタブロックは、前記3つのサブブロックのうちの他の2つのブロックのサイズの合計に等しいサイズを有し、前記3つのサブブロックのうちの前記他の2つのブロックは、同じサイズを有する、
[C29]に記載の装置。
【外国語明細書】