(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-28
(45)【発行日】2023-05-11
(54)【発明の名称】ビデオ復号の方法および装置、並びにプログラム
(51)【国際特許分類】
H04N 19/119 20140101AFI20230501BHJP
H04N 19/136 20140101ALI20230501BHJP
H04N 19/176 20140101ALI20230501BHJP
H04N 19/436 20140101ALI20230501BHJP
H04N 19/70 20140101ALI20230501BHJP
【ＦＩ】
H04N19/119
H04N19/136
H04N19/176
H04N19/436
H04N19/70
【請求項の数】
8
(21)【出願番号】P 2021536694
(86)(22)【出願日】2020-03-20
(65)【公表番号】
(43)【公表日】2022-02-22
(86)【国際出願番号】 US2020023829
(87)【国際公開番号】W WO2020197996
(87)【国際公開日】2020-10-01
【審査請求日】2021-06-22
(31)【優先権主張番号】62/822,757
(32)【優先日】2019-03-22
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/824,440
(32)【優先日】2020-03-19
(33)【優先権主張国・地域又は機関】US
【前置審査】
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】シン・ジャオ
(72)【発明者】
【氏名】シアン・リ
(72)【発明者】
【氏名】シャン・リュウ
【審査官】岩井 健二
(56)【参考文献】
【文献】国際公開第２０２０／２３５５１１（ＷＯ，Ａ１）
【文献】国際公開第２０２０／２３５５１０（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０２０／００３７００２（ＵＳ，Ａ１）
【文献】Chih-Wei Hsu et al.，CE1-related: Constraint for binary and ternary partitions，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K0556-v2，11th Meeting: Ljubljana, SI，2018年07月，pp.1-3
【文献】Xin Zhao, Xiang Li, and Shan Liu，CE6-related: Configurable max transform size in VVC，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-N0362，14th Meeting: Geneva, CH，2019年03月13日，pp.1-8
【文献】Ling Li, et al.，Maximum transform size signaling in HLS，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-N0227-v1，14th Meeting: Geneva, CH，2019年03月19日，pp.1-3
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ １９／００ － １９／９８
(57)【特許請求の範囲】
【請求項1】
ビデオデコーダにおけるビデオ復号の方法であって、Ｗピクセルの幅、及びＨピクセルの高さを有する符号化ブロックを受信するステップと、
前記符号化ブロックをサブ処理ユニット（ＳＰＵ）に分割するステップであって、各サブ処理ユニットは、ＷまたはＫピクセルのうちの小さい方の幅、及びＨまたはＫピクセルのうちの小さい方の高さを有し、Ｋは、Ｋ×Ｋピクセルのエリアを有する仮想パイプラインデータユニット（ＶＰＤＵ）のディメンションである、ステップと、
各ＳＰＵを変換ユニットに分割するステップであって、各変換ユニットはＭピクセルの最大許容変換ユニットサイズを有し、ＭはＫよりも小さい、ステップと、
Ｍピクセルの前記最大許容変換ユニットサイズを示すビットストリームにおける構文要素を受信するステップであって、前記最大許容変換ユニットサイズは制御可能である、ステップと、
を含む方法。
【請求項2】
ＳＰＵ処理順序に従って前記ＳＰＵの変換ユニットを処理するステップ、をさらに含む、請求項１に記載の方法。
【請求項3】
前記ＳＰＵを処理するための前記ＳＰＵ処理順序は、ラスタースキャン順序、垂直スキャン順序、ジグザグ順序、または対角スキャン順序のうちの１つである、請求項２に記載の方法。
【請求項4】
各ＳＰＵ内の前記変換ユニットを処理するための順序は、ラスタースキャン順序、垂直スキャン順序、ジグザグ順序、または対角スキャン順序のうちの１つである、請求項２に記載の方法。
【請求項5】
前記ＳＰＵ処理順序、及び各ＳＰＵ内の前記変換ユニットを処理するための順序は両方ともラスタースキャン順序である、請求項２に記載の方法。
【請求項6】
Ｋは６４であり、Ｍは３２である、請求項１～５のいずれか１項に記載の方法。
【請求項7】
回路を備えるビデオ復号の装置であって、前記回路は、請求項１～６のいずれか１項に記載の方法を実行するように構成される装置。
【請求項8】
コンピュータに、請求項１～６のいずれか１項に記載の方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本出願は、２０２０年３月１９日に出願され、「ビデオ符号化のための方法および装置」と題された、米国特許出願第１６／８２４,４４０号の優先権の利益を主張し、当該出願は、２０１９年３月２２日に出願され、「ＶＰＤＵ互換最大変換制御」と題された、米国仮出願第６２／８２２,７５７号の優先権の利益を主張する。先行の出願の開示は、参照することによりその全体として本出願に組み込まれる。
本出願は、２０２０年３月１９日に出願され、「ビデオ符号化のための方法および装置」と題された、米国特許出願第１６／８２４,４４０号の優先権の利益を主張し、当該出願は、２０１９年３月２２日に出願され、「ＶＰＤＵ互換最大変換制御」と題された、米国仮出願第６２／８２２,７５７号の優先権の利益を主張する。先行の出願の開示は、参照することによりその全体として本出願に組み込まれる。
【0002】
本開示は、一般にビデオ符号化に関連する実施形態を説明する。
【背景技術】
【0003】
本明細書中に提供される「背景技術」の記述は、開示の文脈を一般的に提供するのを目的としている。出願時に先行技術としての資格を有しない記述の態様は勿論のこと、現在指名されている発明者の成果は、本背景技術セクションにおいて記述されている程度において、本開示に対する先行技術として明示的にも黙示的にも認められてはいない。
【0004】
ビデオの符号化と復号は、動き補償を伴うインターピクチャ予測を使用して実行できる。非圧縮デジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば、１９２０×１０８０の輝度サンプルおよび関連するクロミナンスサンプルの空間寸法を有する。一連のピクチャは、例えば、毎秒６０枚または６０Ｈｚの固定または可変のピクチャレート（非公式にはフレームレートとも呼ぶ）を持つことができる。非圧縮ビデオには、重要なビットレート要件がある。例えば、サンプルあたり８ビットの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚのフレームレートで１９２０×１０８０の輝度サンプル解像度）には、１．５Ｇｂｉｔ／ｓに近い帯域幅が必要である。１時間分の当該ビデオは、６００ＧＢｙｔｅｓを超えるストレージスペースを必要とする。
【0005】
ビデオの符号化と復号の目的の１つは、圧縮によって入力ビデオ信号の冗長性を減らすことである。圧縮は、前述の帯域幅またはストレージスペースの要件を、場合によっては２桁以上低減するのに役立つ。可逆圧縮と非可逆圧縮の両方、およびそれらの組み合わせを使用することができる。可逆圧縮とは、圧縮された元の信号から元の信号の正確なコピーを再構成できる手法を指す。非可逆圧縮を使用する場合、再構成された信号は元の信号と同一ではない場合があるが、元の信号と再構成された信号の間の歪みは、再構成された信号を意図されたアプリケーションに役立てる程度に小さい。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量はアプリケーションによって異なる。例えば、特定のコンシューマストリーミングアプリケーションのユーザは、テレビ配信アプリケーションのユーザよりも高い歪みを許容できる。達成可能な圧縮率は、受け入れ可能／許容可能な歪みが大きいほど、圧縮率が高くなることを反映することができる。
【0006】
ビデオエンコーダおよびデコーダは、例えば、動き補償、変換、量子化、およびエントロピー符号化を含む、いくつかの広いカテゴリーからの手法を利用することができる。
【0007】
ビデオ符号化技術には、イントラ符号化と呼ぶ手法を含めることができる。イントラ符号化では、サンプル値は、以前に再構成された参照ピクチャからのサンプルまたは他のデータを参照せずに表される。一部のビデオ符号化では、ピクチャはサンプルのブロックに空間的に細分される。サンプルのブロックがすべてイントラモードで符号化される場合、そのピクチャはイントラピクチャである可能性がある。イントラピクチャおよび独立したデコーダリフレッシュピクチャなどのそれらの派生物は、デコーダの状態をリセットするために使用できるため、符号化されたビデオビットストリームおよびビデオセッションの最初のピクチャとして、または静止ピクチャとして使用できる。イントラブロックのサンプルは変換にさらされることができ、変換係数はエントロピー符号化の前に量子化されることができる。イントラ予測は、変換前の領域のサンプル値を最小化する手法であり得る。場合によっては、変換後のＤＣ値が小さく、かつＡＣ係数が小さいほど、エントロピー符号化後のブロックを表すために所定の量子化ステップサイズで必要なビットが少なくなる。
【0008】
例えば、ＭＰＥＧ－２世代の符号化技術から知られているような従来のイントラ符号化は、イントラ予測を使用しない。しかしながら、一部の新しいビデオ圧縮技術は、例えば、周囲のサンプルデータおよび／または空間的に隣接しデコード順で先行するデータのブロックの符号化／復号中に取得されたメタデータから試みる手法を含む。このような手法は、以降「イントラ予測」手法と呼ぶ。なお、少なくとも一部の場合では、イントラ予測は再構成中の現在のピクチャからの参照データのみを使用し、参照ピクチャからは使用しない。
【0009】
イントラ予測にはさまざまな形式がある。所定のビデオ符号化技術で使用され得るそのような手法が複数ある場合、使用されている手法は、イントラ予測モードで符号化できる。場合によっては、モードにサブモードおよび／またはパラメータが含まれることがあり、それらを個別に符号化することも、モードコードワードに含ませることもできる。所定のモード／サブモード／パラメータの組み合わせに用いられるコードワードは、イントラ予測による符号化効率の向上に影響を与えることができ、コードワードをビットストリームに変換するために使用されるエントロピー符号化技術も同様である。
【0010】
イントラ予測の特定のモードはＨ．２６４で導入され、Ｈ．２６５で改良され、さらにジョイント探索モデル（ＪＥＭ）、多用途ビデオ符号化（ＶＶＣ）、ベンチマークセット（ＢＭＳ）などの新しい符号化技術で改良される。予測ブロックは、すでに利用可能なサンプルに属する隣接サンプル値を使用して形成できる。隣接サンプルのサンプル値は、方向に従って予測ブロックにコピーされる。使用中の方向への参照は、ビットストリームに符号化されてもよく、それ自体予測されてもよい。
【0011】
動き補償は非可逆圧縮手法であることができ、以前に再構成されたピクチャまたはその一部（参照ピクチャ）からのサンプルデータのブロックが、動きベクトル（以降、ＭＶ）によって示される方向に空間的にシフトされた後、新しく再構成されたピクチャまたはピクチャ部分の予測に使用される手法に関連することができる。場合によっては、参照ピクチャは現在再構成中のピクチャと同じである可能性がある。ＭＶは、２次元のＸとＹ、または３次元を持つことができ、３番目は使用中の参照ピクチャを示す（後者は間接的に時間ディメンションにすることができる）。
【0012】
一部のビデオ圧縮手法では、サンプルデータのある領域に適用可能なＭＶは、他のＭＶから、例えば再構成中の領域に空間的に隣接し、デコード順でそのＭＶよりも前であるサンプルデータの別の領域に関連するＭＶから予測されることができる。そうすることで、ＭＶの符号化に必要なデータ量を大幅に減らすことができ、これにより冗長性を取り除き、圧縮を強化する。例えば、カメラから取得された入力ビデオ信号（「ナチュラルビデオ」と呼ぶ）を符号化する際に、単一のＭＶが適用される領域より大きい領域が同様の方向に移動する統計的可能性があるため、ＭＶ予測は有効に働くことができる。したがって、場合によっては、隣接領域のＭＶから導出された類似の動きベクトルを用いて予測することができる。その結果、所定の領域に対して発見されたＭＶは、周囲のＭＶから予測されたＭＶと類似または同一であり、逆に、エントロピー符号化後、ＭＶを直接符号化する場合よりも少ないビット数で表されることができる。場合によっては、ＭＶ予測は、元の信号（即ち、「サンプルストリーム」）に由来する信号（即ち、「ＭＶ」）の可逆圧縮の一例になってもよい。他の場合では、例えばいくつかの周囲のＭＶから予測子を計算するときの丸め誤差のために、ＭＶ予測自体は非可逆になる可能性がある。
【0013】
Ｈ．２６５／ＨＥＶＣ（ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５、「高効率ビデオ符号化」、２０１６年１２月）には、様々なＭＶ予測メカニズムが記載されている。Ｈ．２６５が提供する多くのＭＶ予測メカニズムのうち、ここで説明するのは、以降、「空間的マージ」と呼ぶ手法である。
【0014】
図１を参照すると、現在ブロック（１０１）は、空間的にシフトされた同じサイズの以前のブロックから予測可能であるとエンコーダによって動き検出プロセスにおいて発見されたサンプルを含む。そのＭＶを直接符号化する代わりに、Ａ０、Ａ１、およびＢ０、Ｂ１、Ｂ２（それぞれ１０２から１０６）で示される５つの周囲のサンプルのいずれか１つに関連付けられるＭＶを用いて、１つ以上の参照ピクチャに関連付けられるメタデータから、例えば最新の（デコード順で）参照ピクチャから、ＭＶを導出することができる。Ｈ．２６５では、ＭＶ予測は、隣接ブロックが使用しているのと同じ参照ピクチャからの予測子を使用することができる。
【発明の概要】
【課題を解決するための手段】
【0015】
本開示の態様は、ビデオ符号化／復号のための方法および装置を提供する。一部の例では、ビデオ復号のための装置は、受信回路および処理回路を含む。処理回路は、Ｗピクセルの幅、及びＨピクセルの高さを有する符号化ブロックを受信し、前記符号化ブロックをサブ処理ユニット（ＳＰＵ）に分割するように構成され、各サブ処理ユニットは、ＷまたはＫピクセルのうちの小さい方の幅、及びＨまたはＫピクセルのうちの小さい方の高さを有し、Ｋは、Ｋ×Ｋピクセルのエリアを有する仮想パイプラインデータユニット（ＶＰＤＵ）のディメンション（ｄｉｍｅｎｓｉｏｎ）である。各ＳＰＵは、変換ユニットに分割され、各変換ユニットはＭピクセルの最大許容変換ユニットサイズを有する。
【0016】
一実施形態では、構文要素は、Ｍピクセルの前記最大許容変換ユニットサイズを示すビットストリームにおいて受信されることができる。前記ＳＰＵの前記変換ユニットは、ＳＰＵ処理順序に従って処理されることができる。一例では、前記ＳＰＵを処理するための前記ＳＰＵ処理順序は、ラスタースキャン順序、垂直スキャン順序、ジグザグ順序、または対角スキャン順序のうちの１つである。さらに、各ＳＰＵ内の前記変換ユニットを処理するための順序は、ラスタースキャン順序、垂直スキャン順序、ジグザグ順序、または対角スキャン順序のうちの１つである。一例では、前記ＳＰＵ処理順序および各ＳＰＵ内の前記変換ユニットを処理するための順序は両方ともラスタースキャン順序である。さらに、一実施形態では、Ｋは６４であり、Ｍは３２である。
【0017】
本開示の態様はまた、ビデオ復号のためにコンピュータによって実行されると、コンピュータにビデオ復号のための方法を実行させる命令を格納する非一時的なコンピュータ可読媒体を提供する。
【図面の簡単な説明】
【0018】
開示される主題のさらなる特徴、性質、およびさまざまな利点は、以下の詳細な説明および添付の図面からさらに明らかになるであろう。
【0019】
【図1】一例における現在ブロックおよびその周囲の空間マージ候補の概略図である。
【図2】一実施形態による通信システム（２００）の簡略化されたブロック図の概略図である。
【図3】一実施形態による通信システム（３００）の簡略化されたブロック図の概略図である。
【図4】一実施形態によるデコーダの簡略化されたブロック図の概略図である。
【図5】一実施形態によるエンコーダの簡略化されたブロック図の概略図である。
【図6】別の実施形態によるエンコーダのブロック図を示す。
【図7】別の実施形態によるデコーダのブロック図を示す。
【図8A】四分木プラス二分木（ＱＴＢＴ）構造（８２０）で分割されるＣＴＵを示す。
【図8B】ＱＴＢＴ構造（８２０）を示す。
【図9A】水平中央側三分木を示す。
【図9B】垂直中央側三分木を示す。
【図10A】それぞれ、４点、８点、１６点、および３２点ＤＣＴ－２変換の変換コア行列を示す。
【図10B】それぞれ、４点、８点、１６点、および３２点ＤＣＴ－２変換の変換コア行列を示す。
【図10C】それぞれ、４点、８点、１６点、および３２点ＤＣＴ－２変換の変換コア行列を示す。
【図10D】それぞれ、４点、８点、１６点、および３２点ＤＣＴ－２変換の変換コア行列を示す。
【図11A】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図11B】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図11C】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図11D】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図11E】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図12】適応多重変換（ＡＭＴ）の選択された離散正弦変換（ＤＳＴ）／離散余弦変換（ＤＣＴ）の変換基底関数を示す。
【図13】ｍｔｓ＿ｉｄｘ値とそれぞれの水平または垂直変換との間のマッピング関係を示す表（１３００）を示す。
【図14A】ＤＳＴ－７変換の変換コア行列を示す。
【図14B】ＤＳＴ－７変換の変換コア行列を示す。
【図14C】ＤＳＴ－７変換の変換コア行列を示す。
【図14D】ＤＳＴ－７変換の変換コア行列を示す。
【図15A】ＤＣＴ－８変換の変換コア行列を示す。
【図15B】ＤＣＴ－８変換の変換コア行列を示す。
【図15C】ＤＣＴ－８変換の変換コア行列を示す。
【図15D】ＤＣＴ－８変換の変換コア行列を示す。
【図16】ブロックサイズに応じたサブパーティションの数を示す。
【図17】ブロックが２つのサブパーティションに分割されるシナリオを示す。
【図18】ブロックが４つのサブパーティションに分割されるシナリオを示す。
【図19A】イントラサブパーティション（ＩＳＰ）符号化モードのために信号を送られる関連する構文要素を含む例示的な構文テーブル（１９００）を示す。
【図19B】イントラサブパーティション（ＩＳＰ）符号化モードのために信号を送られる関連する構文要素を含む例示的な構文テーブル（１９００）を示す。
【図20A】サブブロック変換（ＳＢＴ）でサポートされるサブブロックタイプ、サイズ、および位置を示す。
【図20B】サブブロック変換（ＳＢＴ）でサポートされるサブブロックタイプ、サイズ、および位置を示す。
【図20C】サブブロック変換（ＳＢＴ）でサポートされるサブブロックタイプ、サイズ、および位置を示す。
【図20D】サブブロック変換（ＳＢＴ）でサポートされるサブブロックタイプ、サイズ、および位置を示す。
【図21A】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21B】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21C】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21D】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21E】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21F】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21G】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21H】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図21I】ＳＢＴが使用される場合のビデオ符号化規格の仕様テキストへの変更を示す。
【図22】一部の実施形態で使用される異なるＹＵＶフォーマット（例えば、４：４：４、４：２：２、４：１：１、および４：２：０）を示す。
【図23】許容されない三分木（ＴＴ）と二分木（ＢＴ）の分割の例を示す。
【図24】１２８×６４サンプルのサイズを有する符号化ブロック（２４１０）を示す。
【図25】１２８×３２サンプルのサイズを有する符号化ブロック（２５１０）を示す。
【図26】１２８×３２サンプルのサイズを有する符号化ブロック（２６１０）を示す。
【図27】本開示の一実施形態による、変換ブロック分割および処理プロセス（２７００）を概説するフローチャートを示す。
【図28】一実施形態によるコンピュータシステムの概略図である。
【発明を実施するための形態】
【0020】
Ｉ．ビデオ符号化のためのエンコーダおよびデコーダ
図２は、本開示の一実施形態による通信システム（２００）の簡略化されたブロック図を示す。通信システム（２００）は、例えばネットワーク（２５０）を介して互いに通信可能な複数の端末装置を含む。例えば、通信システム（２００）は、ネットワーク（２５０）を介して相互接続された第１の対の端末装置（２１０）および（２２０）を含む。図２の例では、第１の対の端末装置（２１０）および（２２０）は、データの単方向送信を実行する。例えば、端末装置（２１０）は、ネットワーク（２５０）を介して他方の端末装置（２２０）へ送信するためにビデオデータ（例えば、端末装置（２１０）によってキャプチャされたビデオピクチャのストリーム）を符号化し得る。エンコードされたビデオデータは、１つ以上の符号化されたビデオビットストリームの形態で送信されることができる。端末装置（２２０）は、ネットワーク（２５０）から符号化ビデオデータを受信し、符号化ビデオデータをデコードしてビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャを表示することができる。単方向のデータ送信は、メディア供給アプリケーションなどで一般的であり得る。
図２は、本開示の一実施形態による通信システム（２００）の簡略化されたブロック図を示す。通信システム（２００）は、例えばネットワーク（２５０）を介して互いに通信可能な複数の端末装置を含む。例えば、通信システム（２００）は、ネットワーク（２５０）を介して相互接続された第１の対の端末装置（２１０）および（２２０）を含む。図２の例では、第１の対の端末装置（２１０）および（２２０）は、データの単方向送信を実行する。例えば、端末装置（２１０）は、ネットワーク（２５０）を介して他方の端末装置（２２０）へ送信するためにビデオデータ（例えば、端末装置（２１０）によってキャプチャされたビデオピクチャのストリーム）を符号化し得る。エンコードされたビデオデータは、１つ以上の符号化されたビデオビットストリームの形態で送信されることができる。端末装置（２２０）は、ネットワーク（２５０）から符号化ビデオデータを受信し、符号化ビデオデータをデコードしてビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャを表示することができる。単方向のデータ送信は、メディア供給アプリケーションなどで一般的であり得る。
【0021】
他の例では、通信システム（２００）は、例えばビデオ会議中に発生し得る符号化ビデオデータの双方向送信を実行する第２の対の端末装置（２３０）および（２４０）を含む。データの双方向送信の場合、一例では、端末装置（２３０）および（２４０）のそれぞれは、ネットワーク（２５０）を介して端末装置（２３０）および（２４０）のうちの他方の端末装置へ送信するためにビデオデータ（例えば、端末装置によってキャプチャされたビデオピクチャのストリーム）を符号化し得る。端末装置（２３０）および（２４０）の一方は、端末装置（２３０）および（２４０）の他方から送信された符号化ビデオデータを受信し、符号化ビデオデータをデコードしてビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャをアクセス可能な表示装置に表示することができる。
【0022】
図２の例では、端末装置（２１０）、（２２０）、（２３０）および（２４０）は、サーバ、パーソナルコンピュータおよびスマートフォンとして示され得るが、本開示の原理はこれに制限されることはない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤー、および／または専用のビデオ会議機器に適用可能である。ネットワーク（２５０）は、例えば有線および／または無線通信ネットワークを含む、端末装置（２１０）、（２２０）、（２３０）および（２４０）間で符号化ビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク（２５０）は、回線交換および／またはパケット交換チャネルでデータを交換することができる。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットを含む。本議論の目的のために、ネットワーク（２５０）のアーキテクチャおよびトポロジーは、以下で説明されない限り、本開示の動作にとって重要でないかもしれない。
【0023】
図３は、開示された主題の適用の例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示している。開示された主題は、例えば、ビデオ会議、デジタルＴＶ、および、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの記憶など、を含む他のビデオ対応アプリケーションに等しく適用可能である。
【0024】
ストリーミングシステムは、例えば非圧縮のビデオピクチャ（３０２）のストリームを作成するデジタルカメラのようなビデオソース（３０１）を含むことができるキャプチャサブシステム（３１３）を含んでもよい。一例では、ビデオピクチャ（３０２）のストリームは、デジタルカメラによって取得されたサンプルを含む。エンコードされたビデオデータ（３０４）（または符号化されたビデオビットストリーム）と比較して高データ量を強調するために太線で示されたビデオピクチャ（３０２）のストリームは、ビデオソース（３０１）に結合されたビデオエンコーダ（３０３）を含む電子デバイス（３２０）によって処理されることができる。ビデオエンコーダ（３０３）は、以下でより詳細に説明されるように、開示された主題の態様を可能にするか或いは実施するためのハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。ビデオピクチャ（３０２）のストリームと比較してより低いデータ量を強調するために細い線で示された、エンコードされたビデオデータ（３０４）（またはエンコードされたビデオビットストリーム（３０４））は、将来使うためにストリーミングサーバ（３０５）に記憶されることができる。図３のクライアントサブシステム（３０６）および（３０８）のような１つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ（３０５）にアクセスして、エンコードされたビデオデータ（３０４）のコピー（３０７）および（３０９）を検索することができる。クライアントサブシステム（３０６）は、例えば電子デバイス（３３０）におけるビデオデコーダ（３１０）を含むことができる。ビデオデコーダ（３１０）は、エンコードされたビデオデータの入り方向コピー（３０７）をデコードし、ディスプレイ（３１２）（例えば、表示画面）または他のレンダリングデバイス（描画せず）でレンダリングできるビデオピクチャ（３１１）の出方向ストリームを作成する。一部のストリーミングシステムにおいて、エンコードされたビデオデータ（３０４）、（３０７）、および（３０９）（例えば、ビデオビットストリーム）は、特定のビデオ符号化／圧縮規格に従ってエンコードされることができる。これらの規格の例は、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。一例では、開発中のビデオ符号化規格は、非公式的にバーサタイルビデオ符号化（ＶＶＣ）として知られている。開示された主題は、ＶＶＣのコンテキストに使用されてもよい。
【0025】
なお、電子デバイス（３２０）および（３３０）は、他の構成要素（図示せず）を含むことができる。例えば、電子デバイス（３２０）は、ビデオデコーダ（図示せず）を含むことができ、電子デバイス（３３０）は、ビデオエンコーダ（図示せず）も含むことができる。
【0026】
図４は、本開示の一実施形態によるビデオデコーダ（４１０）のブロック図を示す。ビデオデコーダ（４１０）は、電子デバイス（４３０）に含まれることができる。電子デバイス（４３０）は、受信機（４３１）（例えば、受信回路）を含むことができる。ビデオデコーダ（４１０）は、図３の例におけるビデオデコーダ（３１０）の代わりに使用されることができる。
【0027】
受信機（４３１）は、ビデオデコーダ（４１０）によってデコードされる１つ以上の符号化ビデオシーケンスを受信することができ、同一または別の一実施形態では、一度に１つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスのデコードは、他の符号化ビデオシーケンスから独立している。符号化ビデオシーケンスは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得るチャネル（４０１）から受信されることができる。受信機（４３１）は、それぞれの使用エンティティ（描画せず）に転送され得る他のデータ、例えば、符号化オーディオデータおよび／または補助データストリームとともに、エンコードされたビデオデータを受信し得る。受信機（４３１）は、符号化ビデオシーケンスを他のデータから分離することができる。ネットワークジッタを防止するために、バッファメモリ（４１５）は、受信機（４３１）とエントロピーデコーダ／パーサ（４２０）（以降、「パーサ（４２０）」）の間に結合されてもよい。特定のアプリケーションでは、バッファメモリ（４１５）は、ビデオデコーダ（４１０）の一部である。他の場合、ビデオデコーダ（４１０）（描画せず）の外部に存在し得る。さらに他の場合、例えば、ネットワークジッタを防止するためにビデオデコーダ（４１０）の外部にバッファメモリ（描画せず）が存在し、さらに、例えば、再生タイミングを取り扱うためにビデオデコーダ（４１０）の内部に別のバッファメモリ（４１５）が存在し得る。受信機（４３１）が十分な帯域幅および可制御性を有する記憶／転送装置から、または等同期ネットワークからデータを受信する際に、バッファメモリ（４１５）は必要とされないことがあり、または小さくされることがある。インターネットのようなベストエフォートパケットネットワークで用いるために、バッファメモリ（４１５）が必要になる場合があり、比較的大きいことがあり、有利には適応サイズであることができ、ビデオデコーダ（４１０）の外部のオペレーティングシステムまたは類似の要素（描画せず）に少なくとも部分的に実現されてもよい。
【0028】
ビデオデコーダ（４１０）は、符号化ビデオシーケンスからシンボル（４２１）を再構成するパーサ（４２０）を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ（４１０）の操作を管理するための情報、および、電子デバイス（４３０）の不可欠な部分ではないが、図４に示すように電子デバイス（４３０）に結合され得るレンダリングデバイス（４１２）（例えば、表示画面）のようなレンダリングデバイスを制御する潜在的情報を含む。レンダリングデバイスのための制御情報は、補助強化情報（ＳＥＩメッセージ）またはビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（描画せず）の形態であってよい。パーサ（４２０）は、受信される符号化ビデオシーケンスを構文解析／エントロピーデコードすることができる。符号化ビデオシーケンスの符号化は、ビデオ符号化技術または規格に合わせることができ、可変長符号化、ハフマン符号化、文脈感受性を有するもしくは有さない算術符号化などを含む様々な原理に従うことができる。パーサ（４２０）は、グループに対応する少なくとも１つのパラメータに基づいて、符号化ビデオシーケンスからビデオデコーダ内のピクセルの少なくとも１つのサブグループのためのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャ群（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）などを含むことができる。パーサ（４２０）は、符号化ビデオシーケンスから変換係数、量子化パラメータ値、動きベクトルなどのような情報をも抽出してもよい。
【0029】
パーサ（４２０）は、シンボル（４２１）を作成するために、バッファメモリ（４１５）から受信されたビデオシーケンスに対してエントロピーデコード／構文解析操作を実行してもよい。
【0030】
シンボル（４２１）の再構成は、符号化ビデオピクチャまたはその一部のタイプ（例えば、インターおよびイントラピクチャ、インターおよびイントラブロック）、および他の要因に応じて、複数の異なるユニットが関与することができる。どのユニットが、どのように関与するかは、パーサ（４２０）によって符号化ビデオシーケンスから構文解析されたサブグループ制御情報によって制御されることができる。パーサ（４２０）と以下の複数のユニットとの間のサブグループ制御情報の流れは、明確にするために示されていない。
【0031】
すでに述べた機能ブロックに加え、ビデオデコーダ（４１０）は、以下で説明されるように複数の機能ユニットに概念的に細分されることができる。商業的な制約の下で実際の実施にあたっては、これらのユニットの多くは互いに密接に相互作用し、少なくとも一部は互いに統合することができる。しかしながら、開示された主題の説明の目的で、以下の機能ユニットへの概念的な細分は、適切に行われる。
【0032】
第１のユニットは、スケーラ／逆変換ユニット（４５１）である。スケーラ／逆変換ユニット（４５１）は、使用する変換、ブロックサイズ、量子化因子、量子化スケーリング行列などを含む制御情報と、量子化された変換係数をシンボル（４２１）としてパーサ（４２０）から受信する。スケーラ／逆変換ユニット（４５１）は、アグリゲータ（４５５）に入力可能なサンプル値を含むブロックを出力することができる。
【0033】
場合によっては、スケーラ／逆変換（４５１）の出力サンプルは、イントラ符号化ブロック、すなわち、予め再構成されたピクチャからの予測情報を用いていないが、現在ピクチャの予め再構成された部分からの予測情報を使用できるブロックに関係することがある。このような予測情報は、イントラピクチャ予測ユニット（４５２）によって提供されることができる。場合によっては、イントラピクチャ予測ユニット（４５２）は、現在ピクチャバッファ（４５８）から取り出された周囲の既に再構成された情報を用いて、再構成中のブロックの同じサイズおよび形状のブロックを生成する。現在ピクチャバッファ（４５８）は、例えば、一部再構成された現在ピクチャおよび／または完全に再構成された現在ピクチャをバッファリングする。アグリゲータ（４５５）は、場合によっては、サンプルごとに、イントラ予測ユニット（４５２）が生成した予測情報を、スケーラ／逆変換ユニット（４５１）によって提供される出力サンプル情報に追加する。
【0034】
他の場合では、スケーラ／逆変換ユニット（４５１）の出力サンプルは、インター符号化された、潜在的に動き補償されたブロックに関係することがある。このような場合、動き補償予測ユニット（４５３）は、参照ピクチャメモリ（４５７）にアクセスして、予測に使用されるサンプルを取り出すことができる。取り出されたサンプルをブロックに関係するシンボル（４２１）に従って動き補償した後、出力サンプル情報を生成するように、これらのサンプルは、アグリゲータ（４５５）によってスケーラ／逆変換ユニット（４５１）の出力に追加されることができる（この場合、残差サンプルまたは残差信号と呼ぶ）。動き補償予測ユニット（４５３）が予測サンプルを取り出す参照ピクチャメモリ（４５７）内のアドレスは、例えば、Ｘ、Ｙ、および参照ピクチャ成分を有し得るシンボル（４２１）の形態で動き補償予測ユニット（４５３）に利用可能な動きベクトルによって制御されることができる。動き補償は、サブサンプル正確動きベクトルが使用中であるときに参照ピクチャメモリ（４５７）から取り出されたサンプル値の補間、動きベクトル予測メカニズムなどを含むこともできる。
【0035】
アグリゲータ（４５５）の出力サンプルは、ループフィルタユニット（４５６）において様々なループフィルタリング手法を受けられる。ビデオ圧縮技術は、符号化ビデオシーケンス（符号化されたビデオビットストリームとも呼ぶ）に含まれる、パーサ（４２０）からのシンボル（４２１）としてループフィルタユニット（４５６）に利用可能とされたパラメータによって制御されることができ、それに、符号化ピクチャまたは符号化ビデオシーケンスの（デコード順で）前の部分のデコード中に取得されたメタ情報に応じるとともに、予め再構成されループフィルタリングされたサンプル値に応じることもできるループ内フィルタ技術を含むことができる。
【0036】
ループフィルタユニット（４５６）の出力は、レンダリングデバイス（４１２）へ出力されることができるとともに、将来のインターピクチャ予測で用いるために参照ピクチャメモリ（４５７）に記憶されることができるサンプルストリームであり得る。
【0037】
特定の符号化ピクチャは、完全に再構成されると、将来の予測のために参照ピクチャとして使用されることができる。例えば、現在ピクチャに対応する符号化ピクチャが完全に再構成され、符号化ピクチャが（例えば、パーサ（４２０）によって）参照ピクチャとして識別されると、現在ピクチャバッファ（４５８）は、参照ピクチャメモリ（４５７）の一部になることができ、次の符号化ピクチャの再構成を開始する前に新しい現在ピクチャバッファが再割当てされることができる。
【0038】
ビデオデコーダ（４１０）は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５のような規格での所定のビデオ圧縮技術に従ってデコード操作を実行することができる。符号化ビデオシーケンスが、ビデオ圧縮技術または規格のシンタックスと、ビデオ圧縮技術または規格で文書化されたプロファイルとの両方に準拠しているという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術または規格によって指定されるシンタックスに準拠し得る。具体的には、プロファイルは、ビデオ圧縮技術または規格で利用可能なすべてのツールから、特定のツールをそのプロファイルで使用できる唯一のツールとして選択することができる。符号化ビデオシーケンスの複雑さがビデオ圧縮技術または規格のレベルで定義される範囲内にあることも、コンプライアンスに必要である。場合によっては、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、１秒あたりのメガサンプルで測定される）、最大参照ピクチャサイズなどがレベルによって制限される。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（ＨＲＤ）仕様および符号化ビデオシーケンスでシグナリングされたＨＲＤバッファ管理のためのメタデータによってさらに制限され得る。
【0039】
一実施形態では、受信機（４３１）は、エンコードされたビデオとともに追加の（冗長な）データを受信することができる。追加のデータは、符号化ビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードし、および／または、元のビデオデータをより正確に再構成するためにビデオデコーダ（４１０）によって使用され得る。追加のデータは、例えば、時間的、空間的、または信号対雑音比（ＳＮＲ）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方向誤り訂正コードなどの形態にされることができる。
【0040】
図５は、本開示の一実施形態によるビデオエンコーダ（５０３）のブロック図を示す。ビデオエンコーダ（５０３）は、電子デバイス（５２０）に含まれる。電子デバイス（５２０）は、送信機（５４０）（例えば、送信回路）を含む。図３の例におけるビデオエンコーダ（３０３）の代わりにビデオエンコーダ（５０３）を用いることができる。
【0041】
ビデオエンコーダ（５０３）は、ビデオエンコーダ（５０３）によって符号化されるビデオ画像をキャプチャし得るビデオソース（５０１）（図５の例では電子デバイス（５２０）の一部ではない）からビデオサンプルを受信することができる。他の例では、ビデオソース（５０１）は、電子デバイス（５２０）の一部である。
【0042】
ビデオソース（５０１）は、ビデオエンコーダ（５０３）によって符号化されるソースビデオシーケンスを、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット、・・・）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、・・・）および任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であり得るデジタルビデオサンプルストリームの形態で提供し得る。メディア供給システムでは、ビデオソース（５０１）は、予め準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース（５０１）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、順番に見られるときに動きが与えられる複数の個別のピクチャとして提供されてもよい。ピクチャそのものは、ピクセルの空間アレイとして編成されてもよく、各ピクセルは、使用中のサンプリング構造、色空間などに応じて１つ以上のサンプルを含むことができる。当業者は、ピクセルとサンプルとの関係を容易に理解することができる。以下の説明ではサンプルを中心に説明する。
【0043】
一実施形態によれば、ビデオエンコーダ（５０３）は、リアルタイムでまたはアプリケーションが要求する任意の他の時間制約の下でソースビデオシーケンスのピクチャを符号化し、符号化ビデオシーケンス（５４３）に圧縮することができる。適切な符号化速度を実行することは、コントローラ（５５０）の機能の１つである。一部の実施形態では、コントローラ（５５０）は、以下で説明される他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。分かりやすくするために、カップリングは示されていない。コントローラ（５５０）によって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化、レート歪み最適化手法のラムダ値、・・・）、ピクチャサイズ、ピクチャ群（ＧＯＰ）レイアウト、最大動きベクトル検索範囲などを含むことができる。コントローラ（５５０）は、あるシステム設計に対して最適化されたビデオエンコーダ（５０３）に関する他の適切な機能を有するように構成されてもよい。
【0044】
一部の実施形態では、ビデオエンコーダ（５０３）は、符号化ループで動作するように構成される。過度に簡略化した説明として、一例では、符号化ループは、ソースコーダ（５３０）（例えば、符号化対象となる入力ピクチャおよび参照ピクチャに基づくシンボルストリームなどのシンボルの作成を担当する）、およびビデオエンコーダ（５０３）に埋め込まれた（ローカル）デコーダ（５３３）を含むことができる。デコーダ（５３３）は、シンボルを再構成して、（リモート）デコーダが作成するのと同様な方法でサンプルデータを作成する（シンボルと符号化されたビデオビットストリーム間の如何なる圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるためである）。再構成されたサンプルストリーム（サンプルデータ）は参照ピクチャメモリ（５３４）に入力される。シンボルストリームのデコードにより、デコーダの位置（ローカルまたはリモート）に関係なくビット正確な結果が得られるため、参照ピクチャメモリ（５３４）のコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えれば、エンコーダの予測部分は、参照ピクチャサンプルとして、デコード中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を「見る」。参照ピクチャの同期性の該基本原理（および例えばチャネルエラーに起因して同期性を維持できない場合に生じるドリフト）は、いくつかの関連分野にも使用されている。
【0045】
「ローカル」デコーダ（５３３）の動作は、前文で図４に関連して既に詳細に説明された、ビデオデコーダ（４１０）のような「リモート」デコーダの動作と同様であり得る。しかしながら、図４も簡単に参照し、シンボルが使用可能であり、エントロピーコーダ（５４５）およびパーサ（４２０）による符号化ビデオシーケンスへのシンボルのエンコード／デコードが可逆であり得るので、バッファメモリ（４１５）、およびパーサ（４２０）を含むビデオデコーダ（４１０）のエントロピーデコード部分は、ローカルデコーダ（５３３）では完全に実現されない場合がある。
【0046】
これで分かるように、デコーダに存在する構文解析／エントロピーデコード以外の如何なるデコーダ技術も、対応するエンコーダに実質的に同一の機能的形態で必ず存在する必要がある。このため、開示された主題は、デコーダの動作に焦点を合わせている。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略できる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。
【0047】
動作中、一部の例では、ソースコーダ（５３０）は、「参照ピクチャ」として指定されたビデオシーケンスからの１つ以上の予め符号化されたピクチャを参照して入力ピクチャを予測的に符号化する動き補償予測符号化を実行してもよい。このようにして、符号化エンジン（５３２）は、入力ピクチャのピクセルブロックと、入力ピクチャへの予測基準として選択され得る参照ピクチャのピクセルブロックとの差異を符号化する。
【0048】
ローカルビデオデコーダ（５３３）は、ソースコーダ（５３０）で作成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャの符号化ビデオデータをデコードすることができる。符号化エンジン（５３２）の動作は、有利には非可逆プロセスであり得る。符号化ビデオデータがビデオデコーダ（図５に示されていない）でデコードされ得るとき、再構成されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ（５３３）は、ビデオデコーダによって参照ピクチャに対して実行され得るデコードプロセスを再現し、再構成された参照ピクチャを参照ピクチャキャッシュ（５３４）に記憶させることができる。このようにして、ビデオエンコーダ（５０３）は、遠端ビデオデコーダによって取得される再構成された参照ピクチャと共通するコンテンツ（送信エラー無し）を有する再構成された参照ピクチャのコピーをローカルに記憶し得る。
【0049】
予測器（５３５）は、符号化エンジン（５３２）の予測検索を実行することができる。つまり、符号化対象となる新しいピクチャについて、予測器（５３５）は、（候補の参照ピクセルブロックとしての）サンプルデータ、または、参照ピクチャの動きベクトル、ブロック形状など、新しいピクチャの適切な予測基準として機能し得る特定のメタデータを参照ピクチャメモリ（５３４）で検索することができる。予測器（５３５）は、適切な予測基準を見つけるために、サンプルブロック/ピクセルブロックごとに動作することができる。場合によっては、予測器（５３５）で取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（５３４）に記憶された複数の参照ピクチャから引き出された予測基準を有してもよい。
【0050】
コントローラ（５５０）は、例えば、ビデオデータをエンコードするためのパラメータおよびサブグループパラメータの設定を含む、ソースコーダ（５３０）の符号化動作を管理することができる。
【0051】
前述のすべての機能ユニットの出力は、エントロピーコーダ（５４５）においてエントロピー符号化を受けられる。エントロピーコーダ（５４５）は、例えば、ハフマン符号化、可変長符号化、算術符号化などの技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
【0052】
送信機（５４０）は、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル（５６０）を介した送信の準備のために、エントロピーコーダ（５４５）によって作成された符号化ビデオシーケンスをバッファリングすることができる。送信機（５４０）は、ビデオコーダ（５０３）からの符号化ビデオデータを、送信されるべき他のデータ、例えば、符号化オーディオデータおよび／または補助データストリーム（ソースは示されていない）とマージすることができる。
【0053】
コントローラ（５５０）は、ビデオエンコーダ（５０３）の動作を管理し得る。符号化中、コントローラ（５５０）は、各符号化ピクチャに特定の符号化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得る符号化手法に影響を及ぼし得る。例えば、ピクチャは、多くの場合、次のピクチャタイプのいずれかとして割り当てられ得る。
【0054】
イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内の他のいかなるピクチャを使用せずに符号化および復号され得るものであり得る。一部のビデオコーデックは、例えば、インディペンデントデコーダリフレッシュ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ、「ＩＤＲ」）ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Ｉピクチャの変形、並びに、それらのそれぞれの用途および特徴を知っている。
【0055】
予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために多くとも１つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測により符号化および復号され得るものであり得る。
【0056】
双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために多くとも２つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測により符号化および復号され得るものであり得る。同様に、多重予測ピクチャは、単一のブロックの再構成のために２つを超えた参照ピクチャおよび関連メタデータを用いることができる。
【0057】
ソースピクチャは、一般に、複数のサンプルブロック（例えば、それぞれ、４×４、８×８、４×８、または１６×１６サンプルのブロック）に空間的に細分され、ブロック単位で符号化され得る。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定された他の（既に符号化された）ブロックを参照して予測的に符号化され得る。例えば、Ｉピクチャのブロックは、非予測的に符号化されてもよく、或いは、同一のピクチャの既に符号化されたブロック（空間的予測またはイントラ予測）を参照して予測的に符号化されてもよい。Ｐピクチャのピクセルブロックは、１つの予め符号化された参照ピクチャを参照して、空間的予測を介してまたは時間的予測を介して予測的に符号化され得る。Ｂピクチャのブロックは、１つまたは２つの予め符号化された参照ピクチャを参照して、空間的予測を介してまたは時間的予測を介して予測的に符号化され得る。
【0058】
ビデオエンコーダ（５０３）は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの予め設定されたビデオ符号化技術または規格に従って、符号化動作を実行することができる。動作中、ビデオエンコーダ（５０３）は、入力ビデオシーケンスの時間的および空間的冗長性を利用する予測符号化操作を含む、様々な圧縮操作を実行することができる。したがって、符号化ビデオデータは、使用されているビデオ符号化技術または規格によって指定されたシンタックスに準拠することができる。
【0059】
一実施形態では、送信機（５４０）は、エンコードされたビデオとともに追加のデータを送信することができる。ソースコーダ（５３０）は、このようなデータを符号化ビデオシーケンスの一部として含んでもよい。追加のデータは、時間的／空間的／ＳＮＲエンハンスメントレイヤ、冗長なピクチャやスライスなどの他の形態での冗長データ、ＳＥＩメッセージ、ＶＵＩパラメータセットフラグメントなどを含んでもよい。
【0060】
ビデオは、時系列で複数のソースピクチャ（ビデオピクチャ）としてキャプチャされ得る。イントラピクチャ予測（「イントラ予測」と略されることが多い）は、所定のピクチャにおける空間相関を利用し、インターピクチャ予測は、ピクチャ間の（時間的または他の）相関を利用する。一例では、現在ピクチャと呼ぶエンコード／デコード中の特定のピクチャは、ブロックに分割される。現在ピクチャにおけるブロックが、ビデオにおける予め符号化され、まだバッファリングされている参照ピクチャの参照ブロックに類似している場合、現在ピクチャにおけるブロックは、動きベクトルと呼ぶベクトルによって符号化されることができる。動きベクトルは、参照ピクチャの参照ブロックを指し、複数の参照ピクチャが使用されている場合、参照ピクチャを識別する第３次元を有することができる。
【0061】
一部の実施形態では、インターピクチャ予測において双予測手法を用いることができる。双予測手法によれば、ビデオにおける現在ピクチャよりもデコード順序がそれぞれ前である（ただし、表示順序でそれぞれ過去および未来にあり得る）第１の参照ピクチャおよび第２の参照ピクチャのような２つの参照ピクチャを用いる。現在ピクチャ内のブロックは、第１の参照ピクチャ内の第１の参照ブロックを指す第１の動きベクトル、および第２の参照ピクチャ内の第２の参照ブロックを指す第２の動きベクトルによって符号化されることができる。ブロックは、第１の参照ブロックと第２の参照ブロックとの組み合わせによって予測されることができる。
【0062】
さらに、マージモード手法をインターピクチャ予測に適用して、符号化効率を向上させることができる。
【0063】
本開示の一部の実施形態によれば、インターピクチャ予測およびイントラピクチャ予測などの予測は、ブロック単位で実行される。例えば、ＨＥＶＣ規格によれば、一連のビデオピクチャ内のピクチャは、圧縮のために符号化ツリーユニット（ＣＴＵ）に分割され、ピクチャにおけるＣＴＵは、６４×６４ピクセル、３２×３２ピクセル、または１６×１６ピクセルなど、同一のサイズを有する。一般に、ＣＴＵは、１つのルマＣＴＢと２つのクロマＣＴＢである３つの符号化ツリーブロック（ＣＴＢ）を含む。各ＣＴＵは、１つまたは複数の符号化ユニット（ＣＵ）に再帰的に四分木分割されることができる。例えば、６４×６４ピクセルのＣＴＵは、１つの６４×６４ピクセルのＣＵ、４つの３２×３２ピクセルのＣＵ、または１６つの１６×１６ピクセルのＣＵに分割されることができる。一例では、各ＣＵを解析して、インター予測タイプまたはイントラ予測タイプなど、ＣＵの予測タイプを決定する。ＣＵは、時間的および／または空間的予測可能性に応じて、１つ以上の予測ユニット（ＰＵ）に分割される。通常、各ＰＵは、１つのルマ予測ブロック（ＰＢ）と２つのクロマＰＢを含む。一実施形態では、符号化（エンコード／デコード）における予測操作は、予測ブロックの単位で実行される。ルマ予測ブロックを予測ブロックの例として用いて、予測ブロックは、８×８ピクセル、１６×１６ピクセル、８×１６ピクセル、１６×８ピクセルなどのピクセルの値（例えば、ルマ値）の行列を含む。
【0064】
図６は、本開示の他の実施形態によるビデオエンコーダ（６０３）の図を示す。ビデオエンコーダ（６０３）は、一連のビデオピクチャ内の現在ビデオピクチャにおけるサンプル値の処理ブロック（例えば、予測ブロック）を受信し、処理ブロックを、符号化ビデオシーケンスの一部である符号化ピクチャにエンコードするように構成される。一例では、図３の例におけるビデオエンコーダ（３０３）の代わりにビデオエンコーダ（６０３）を用いる。
【0065】
ＨＥＶＣの例では、ビデオエンコーダ（６０３）は、８×８サンプルのような予測ブロックなどの処理ブロックのサンプル値の行列を受信する。ビデオエンコーダ（６０３）は、例えばレート歪み最適化を用いて、処理ブロックがイントラモード、インターモード、または双予測モードにより最も良く符号化されるか否かを決定する。処理ブロックがイントラモードで符号化されようとする場合、ビデオエンコーダ（６０３）は、イントラ予測手法を用いて処理ブロックを符号化ピクチャにエンコードすることができる。また、処理ブロックがインターモードまたは双予測モードで符号化されようとする場合、ビデオエンコーダ（６０３）は、それぞれインター予測または双予測手法を用いて、処理ブロックを符号化ピクチャにエンコードすることができる。特定のビデオ符号化技術では、マージモードは、予測子外の符号化動きベクトル成分の利便を介することなく、１つ以上の動きベクトル予測子から動きベクトルが導出されるインターピクチャ予測サブモードであり得る。特定の他のビデオ符号化技術では、対象ブロックに適用可能な動きベクトル成分が存在し得る。一例では、ビデオエンコーダ（６０３）は、処理ブロックのモードを決定するためのモード決定モジュール（図示せず）などの他のコンポーネントを含む。
【0066】
図６の例では、ビデオエンコーダ（６０３）は、図６に示すように互いに結合されたインターエンコーダ（６３０）、イントラエンコーダ（６２２）、残差算出部（６２３）、スイッチ（６２６）、残差エンコーダ（６２４）、統括制御部（６２１）およびエントロピーエンコーダ（６２５）を含む。
【0067】
インターエンコーダ（６３０）は、現在ブロック（例えば、処理ブロック）のサンプルを受信し、該ブロックを参照ピクチャ内の１つ以上の参照ブロック（例えば、前のピクチャおよび後のピクチャ内のブロック）と比較し、インター予測情報（例えば、インターエンコード手法による冗長情報の記述、動きベクトル、マージモード情報）を生成し、インター予測情報に基づいて任意の適切な手法を用いてインター予測結果（例えば、予測ブロック）を算出するように構成される。一部の例では、参照ピクチャは、エンコードされたビデオ情報に基づいてデコードされるデコード参照ピクチャである。
【0068】
イントラエンコーダ（６２２）は、現在ブロック（例えば、処理ブロック）のサンプルを受信し、場合によっては該ブロックを同一のピクチャで既に符号化されたブロックと比較し、変換後に、量子化された係数を生成し、場合によってはイントラ予測情報（例えば、１つ以上のイントラエンコード手法によるイントラ予測方向情報）をも生成するように構成される。一例では、イントラエンコーダ（６２２）は、イントラ予測情報および同一のピクチャ内の参照ブロックに基づいてイントラ予測結果（例えば、予測ブロック）も算出する。
【0069】
統括制御部（６２１）は、統括制御データを決定し、統括制御データに基づいてビデオエンコーダ（６０３）の他のコンポーネントを制御するように構成される。一例では、統括制御部（６２１）は、ブロックのモードを決定し、モードに基づいて制御信号をスイッチ（６２６）に提供する。例えば、モードがイントラモードである場合、統括制御部（６２１）は、残差算出部（６２３）用のイントラモード結果を選択するようにスイッチ（６２６）を制御するとともに、イントラ予測情報を選択してイントラ予測情報をビットストリームに含ませるようにエントロピーエンコーダ（６２５）を制御する。また、モードがインターモードである場合、統括制御部（６２１）は、残差算出部（６２３）用のインター予測結果を選択するようにスイッチ（６２６）を制御するとともに、インター予測情報を選択してインター予測情報をビットストリームに含ませるようにエントロピーエンコーダ（６２５）を制御する。
【0070】
残差算出部（６２３）は、受信されたブロックとイントラエンコーダ（６２２）またはインターエンコーダ（６３０）から選択された予測結果との差（残差データ）を算出するように構成される。残差エンコーダ（６２４）は、残差データに基づいて動作し、残差データをエンコードして変換係数を生成するように構成される。一例では、残差エンコーダ（６２４）は、残差データを空間領域から周波数領域へと変換し、変換係数を生成するように構成される。その後、変換係数は量子化処理を受けて、量子化された変換係数が得られる。様々な実施形態では、ビデオエンコーダ（６０３）は、残差デコーダ（６２８）をも含む。残差デコーダ（６２８）は、逆変換を実行し、デコード残差データを生成するように構成される。デコード残差データは、イントラエンコーダ（６２２）およびインターエンコーダ（６３０）によって適切に使用されることができる。例えば、インターエンコーダ（６３０）は、デコード残差データおよびインター予測情報に基づいて、デコードブロックを生成することができ、イントラエンコーダ（６２２）は、デコード残差データおよびイントラ予測情報に基づいて、デコードブロックを生成することができる。一部の例では、デコードブロックは、デコードピクチャを生成するように適切に処理され、デコードピクチャは、メモリ回路（図示せず）にバッファリングされ、参照ピクチャとして使用されることができる。
【0071】
エントロピーエンコーダ（６２５）は、エンコードブロックを含めるようにビットストリームをフォーマットするように構成される。エントロピーエンコーダ（６２５）は、ＨＥＶＣ規格などの適切な規格に従って様々な情報をビットストリームに含ませるように構成される。一例では、エントロピーエンコーダ（６２５）は、統括制御データ、選択された予測情報（例えば、イントラ予測情報またはインター予測情報）、残差情報、および他の適切な情報をビットストリームに含ませるように構成される。開示された主題によれば、インターモードまたは双予測モードのマージサブモードでブロックを符号化する場合、残差情報はないことに留意されたい。
【0072】
図７は、本開示の他の実施形態によるビデオデコーダ（７１０）の図を示す。ビデオデコーダ（７１０）は、符号化ビデオシーケンスの一部である符号化ピクチャを受信し、符号化ピクチャをデコードして、再構成ピクチャを生成するように構成される。一例では、図３の例におけるビデオデコーダ（３１０）の代わりにビデオデコーダ（７１０）を用いる。
【0073】
図７の例では、ビデオデコーダ（７１０）は、図７に示されるように互いに結合されたエントロピーデコーダ（７７１）、インターデコーダ（７８０）、残差デコーダ（７７３）、再構成モジュール（７７４）、およびイントラデコーダ（７７２）を含む。
【0074】
エントロピーデコーダ（７７１）は、符号化ピクチャから、符号化ピクチャを構成するシンタックス要素を表す特定のシンボルを再構成するように構成されることができる。このようなシンボルは、例えば、ブロックが符号化されるモード（例えば、イントラモード、インターモード、双予測モード、後の２つのマージサブモードまたは他のサブモード）、それぞれイントラデコーダ（７７２）またはインターデコーダ（７８０）による予測に使用される特定のサンプルまたはメタデータを識別できる予測情報（例えば、イントラ予測情報またはインター予測情報）、例えば、量子化された変換係数の形態での残差情報などを含むことができる。一例では、予測モードがインターまたは双予測モードであれば、インター予測情報は、インターデコーダ（７８０）に提供される。また、予測タイプがイントラ予測タイプであれば、イントラ予測情報は、イントラデコーダ（７７２）に提供される。残差情報は、逆量子化を施されることができ、残差デコーダ（７７３）に提供される。
【0075】
インターデコーダ（７８０）は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成される。
【0076】
イントラデコーダ（７７２）は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成される。
【0077】
残差デコーダ（７７３）は、逆量子化を実行することで、逆量子化された変換係数を抽出し、逆量子化された変換係数を処理して残差を周波数領域から空間領域に変換するように構成される。残差デコーダ（７７３）は、（量子化器パラメータ（ＱＰ）を含めるように）特定の制御情報をも必要とする場合があり、この情報は、エントロピーデコーダ（７７１）によって提供されてもよい（データパスは、低ボリューム制御情報のみであり得るため、示されていない）。
【0078】
再構成モジュール（７７４）は、空間領域において、残差デコーダ（７７３）によって出力される残差と、（場合によってはインターまたはイントラ予測モジュールによって出力される）予測結果とを組み合わせて、再構成ビデオの一部となり得る再構成ピクチャの一部であり得る再構成ブロックを形成するように構成される。なお、視覚的品質を改善するために、デブロッキング操作などの他の適切な操作を実行することができる。
【0079】
なお、ビデオエンコーダ（３０３）、（５０３）および（６０３）とビデオデコーダ（３１０）、（４１０）および（７１０）は、任意の適切な手法を用いて実現されることができる。一実施形態では、ビデオエンコーダ（３０３）、（５０３）および（６０３）とビデオデコーダ（３１０）、（４１０）および（７１０）は、１つ以上の集積回路を用いて実現されることができる。他の実施形態では、ビデオエンコーダ（３０３）、（５０３）および（６０３）とビデオデコーダ（３１０）、（４１０）および（７１０）は、ソフトウェア命令を実行する１つ以上のプロセッサを用いて実現されることができる。
【0080】
ＩＩ、変換処理手法
１、四分木ブロック分割構造
ブロック分割構造は、符号化ツリーと呼ぶ。一部の実施形態では、四分木構造を使用することによって、符号化ツリーユニット（ＣＴＵ）が符号化ユニット（ＣＵ）にスプリットされて、さまざまな局所特性に適応するようにする。インターピクチャ（時間的）またはイントラピクチャ（空間的）予測を用いてピクチャ領域を符号化するかどうかの決定は、ＣＵレベルで行われる。各ＣＵは、ＰＵスプリッチングタイプに応じて、さらに１つ、２つ、または４つの予測ユニット（ＰＵ）にスプリットされることができる。１つのＰＵ内で、同じ予測プロセスが適用され、関連情報がＰＵベースでデコーダに送信される。
１、四分木ブロック分割構造
ブロック分割構造は、符号化ツリーと呼ぶ。一部の実施形態では、四分木構造を使用することによって、符号化ツリーユニット（ＣＴＵ）が符号化ユニット（ＣＵ）にスプリットされて、さまざまな局所特性に適応するようにする。インターピクチャ（時間的）またはイントラピクチャ（空間的）予測を用いてピクチャ領域を符号化するかどうかの決定は、ＣＵレベルで行われる。各ＣＵは、ＰＵスプリッチングタイプに応じて、さらに１つ、２つ、または４つの予測ユニット（ＰＵ）にスプリットされることができる。１つのＰＵ内で、同じ予測プロセスが適用され、関連情報がＰＵベースでデコーダに送信される。
【0081】
ＰＵスプリッチングタイプに基づいて予測プロセスを適用して残差ブロックを取得した後、ＣＵを別の四分木構造に従って変換ユニット（ＴＵ）に分割できる。これでわかるように、ＣＵ、ＰＵ、およびＴＵを含む複数の分割の概念がある。一部の実施形態では、ＣＵまたはＴＵは正方形状のみであり得、一方、ＰＵは正方形状または長方形状であり得る。一部の実施形態では、１つの符号化ブロックはさらに４つの正方形のサブブロックにスプリットされてもよく、変換は各サブブロック、すなわちＴＵに対して実行される。各ＴＵは、残差四分木（ＲＱＴ）と呼ぶ四分木構造を用いて、より小さなＴＵにさらに再帰的にスプリットされてもよい。
【0082】
ピクチャ境界では、一部の実施形態では、サイズがピクチャ境界に合うまでブロックが四分木スプリッチングを維持するように、暗黙的な四分木スプリットが使用されることができる。
【0083】
２、四分木プラス二分木（ＱＴＢＴ）ブロック分割構造
一部の実施形態では、四分木プラス二分木（ＱＴＢＴ）構造が使用される。ＱＴＢＴ構造は、複数の分割タイプの概念（ＣＵ、ＰＵ、およびＴＵの概念）を排除し、ＣＵ分割形状のより高い柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは正方形または長方形のいずれかの形状にすることができる。
一部の実施形態では、四分木プラス二分木（ＱＴＢＴ）構造が使用される。ＱＴＢＴ構造は、複数の分割タイプの概念（ＣＵ、ＰＵ、およびＴＵの概念）を排除し、ＣＵ分割形状のより高い柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは正方形または長方形のいずれかの形状にすることができる。
【0084】
図８Ａは、図８Ｂに示されるＱＴＢＴ構造（８２０）を用いて分割されるＣＴＵ（８１０）を示す。ＣＴＵ（８１０）は、最初に四分木構造によって分割される。四分木リーフノードは、二分木構造または四分木構造によってさらに分割される。二分木スプリッチングには、対称水平スプリッチングと対称垂直スプリッチングとの２つのスプリッチングタイプがあることができる。二分木リーフノードはＣＵと呼ばれ、さらに分割することなく予測と変換処理に使用されることができる。したがって、ＣＵ、ＰＵ、およびＴＵは、ＱＴＢＴ符号化ブロック構造において同じブロックサイズを有する。
【0085】
一部の実施形態では、ＣＵは、異なる色成分の符号化ブロック（ＣＢ）を含んでもよい。例えば、４：２：０のクロマフォーマットのＰとＢスライスの場合、１つのＣＵには１つのルマＣＢと２つのクロマＣＢとが含まれる。ＣＵには、単一の色成分のＣＢが含まれても良い。例えば、Ｉスライスの場合、１つのＣＵには、１つのみのルマＣＢ、または、２つのみのクロマＣＢが含まれる。
【0086】
一部の実施形態では、以下のパラメータは、ＱＴＢＴ分割スキームのために定義される。
【0087】
ＣＴＵサイズ：四分木のルートノードサイズ、例えば、ＨＥＶＣと同じ概念。
【0088】
ＭｉｎＱＴＳｉｚｅ：許容される最小の四分木リーフノードサイズ。
【0089】
ＭａｘＢＴＳｉｚｅ：許容される最大の二分木ルートノードサイズ。
【0090】
ＭａｘＢＴＤｅｐｔｈ：許容される最大の二分木の深さ。
【0091】
ＭｉｎＢＴＳｉｚｅ：許容される最小の二分木リーフノードサイズ。
【0092】
ＱＴＢＴ分割構造の一例では、ＣＴＵサイズは、２つの対応する６４×６４クロマサンプルのブロックを有する１２８×１２８のルマサンプルとして設定され、ＭｉｎＱＴＳｉｚｅは１６×１６に設定され、ＭａｘＢＴＳｉｚｅは６４×６４に設定され、ＭｉｎＢＴＳｉｚｅ（幅と高さの両方）は４×４に設定され、ＭａｘＢＴＤｅｐｔｈは４に設定される。四分木分割は、最初にＣＴＵに適用されて四分木リーフノードが生成される。四分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを持つことができる。四分木リーフノードが１２８×１２８の場合、サイズがＭａｘＢＴＳｉｚｅ（すなわち、６４×６４）を超えるため、二分木によってさらにスプリットされることはない。それ以外の場合、四分木リーフノードは二分木によってさらに分割される可能性がある。したがって、四分木リーフノードは二分木のルートノードでもあり、二分木の深さが０である。
【0093】
二分木の深さがＭａｘＢＴＤｅｐｔｈ（すなわち、４）に達すると、それ以上のスプリッチングは考慮されない。二分木ノードの幅がＭｉｎＢＴＳｉｚｅ（すなわち、４）に等しい場合、それ以上の水平スプリッチングは考慮されない。同様に、二分木ノードの高さがＭｉｎＢＴＳｉｚｅに等しい場合、それ以上の垂直スプリッチングは考慮されない。二分木のリーフノードは、さらに分割することなく、予測および変換処理によってさらに処理される。一実施形態では、最大のＣＴＵサイズは２５６×２５６のルマサンプルである。
【0094】
図８Ａおよび８Ｂにおいて、実線は四分木スプリッチングを示し、点線は二分木スプリッチングを示す。二分木の各スプリッチング（すなわち、非リーフ）ノードでは、どのスプリッチングタイプ（すなわち、水平または垂直）が使用されるかを示すように１つのフラグがシグナリングされる。例えば、０は水平スプリッチングを示し、１は垂直スプリッチングを示す。四分木スプリッチングの場合、四分木スプリッチングが常にブロックを水平方向と垂直方向の両方にスプリットして、同じサイズの４つのサブブロックを生成するため、スプリッチングタイプを示す必要がない。
【0095】
一部の実施形態では、ＱＴＢＴスキームは、ルマおよびクロマが別個のＱＴＢＴ構造を有するための柔軟性をサポートする。例えば、ＰとＢスライスの場合、１つのＣＴＵにおけるルマとクロマブロックは同じＱＴＢＴ構造を共有する。しかし、Ｉスライスの場合、ルマＣＴＢはＱＴＢＴ構造によってＣＵに分割され、クロマブロックは別のＱＴＢＴ構造によってクロマＣＵに分割される。したがって、ＩスライスのＣＵは、ルマ成分の符号化ブロックまたは２つのクロマ成分の符号化ブロックで構成され、ＰまたはＢスライスのＣＵは、すべての３つの色成分の符号化ブロックで構成される。
【0096】
一部の実施形態では、小さなブロックのインター予測は、動き補償のメモリアクセスを減らすように制限される。例えば、双予測は４×８および８×４のブロックではサポートされず、インター予測は４×４のブロックではサポートされない。
【0097】
３、三分木（ＴＴ）ブロック分割構造
一部の実施形態では、マルチタイプツリー（ＭＴＴ）構造は、ピクチャを分割するために使用される。ＭＴＴ構造は、ＱＴＢＴ構造よりも柔軟なツリー構造である。ＭＴＴでは、四分木と二分木に加えて、それぞれ図９Ａと図９Ｂに示す水平中央側三分木と垂直中央側三分木とが使用される。三分木分割は、四分木および二分木分割を補完することができる。例えば、三分木分割はブロック中心にあるオブジェクトをキャプチャできるが、四分木と二分木とはブロック中心を横切ってスプリットする。三分木による分割の幅と高さは２の累乗であり、追加の変換分割は必要とされない。
一部の実施形態では、マルチタイプツリー（ＭＴＴ）構造は、ピクチャを分割するために使用される。ＭＴＴ構造は、ＱＴＢＴ構造よりも柔軟なツリー構造である。ＭＴＴでは、四分木と二分木に加えて、それぞれ図９Ａと図９Ｂに示す水平中央側三分木と垂直中央側三分木とが使用される。三分木分割は、四分木および二分木分割を補完することができる。例えば、三分木分割はブロック中心にあるオブジェクトをキャプチャできるが、四分木と二分木とはブロック中心を横切ってスプリットする。三分木による分割の幅と高さは２の累乗であり、追加の変換分割は必要とされない。
【0098】
４、一次変換の例
一部の実施形態では、４点、８点、１６点、および３２点ＤＣＴ－２変換が一次変換として用いられる。図１０Ａ～１０Ｄは、それぞれ４点、８点、１６点、および３２点ＤＣＴ－２の変換コア行列を示す。これらの変換コア行列の要素が８ビット整数を用いて表されることができるため、これらの変換コア行列は８ビット変換コアと呼ぶ。示されているように、より小さいＤＣＴ－２の変換コア行列は、より大きいＤＣＴ－２の変換コア行列の一部である。
一部の実施形態では、４点、８点、１６点、および３２点ＤＣＴ－２変換が一次変換として用いられる。図１０Ａ～１０Ｄは、それぞれ４点、８点、１６点、および３２点ＤＣＴ－２の変換コア行列を示す。これらの変換コア行列の要素が８ビット整数を用いて表されることができるため、これらの変換コア行列は８ビット変換コアと呼ぶ。示されているように、より小さいＤＣＴ－２の変換コア行列は、より大きいＤＣＴ－２の変換コア行列の一部である。
【0099】
ＤＣＴ－２コア行列は対称性／非対称性の特性を示す。したがって、いわゆる「部分的バタフライ（partial butterfly）」実装は、動作カウント（乗算、加算／減算、シフト）の数を減らすようにサポートされ得る。部分的バタフライ実装を用いることにより、行列乗算の同じ結果を得ることができる。
【0100】
５、追加の一次変換例
一部の実施形態では、上記の４点、８点、１６点、および３２点ＤＣＴ－２変換に加えて、追加の２点および６４点ＤＣＴ－２が用いられる。図１１Ａ～１１Ｅは、６４点ＤＣＴ－２変換の６４×６４の変換コア行列を示す。
一部の実施形態では、上記の４点、８点、１６点、および３２点ＤＣＴ－２変換に加えて、追加の２点および６４点ＤＣＴ－２が用いられる。図１１Ａ～１１Ｅは、６４点ＤＣＴ－２変換の６４×６４の変換コア行列を示す。
【0101】
一部の実施形態では、ＤＣＴ－２および４×４のＤＳＴ－７変換に加えて、適応多重変換（ＡＭＴ）（拡張多重変換（ＥＭＴ）または多重変換選択（ＭＴＳ）とも呼ぶ）は、インターおよびイントラの両方の符号化ブロックの残差符号化に使用される。ＡＭＴは、ＤＳＴ－７の変換コア行列またはＤＣＴ－８変換などのＤＣＴ－２変換に加えて、離散余弦変換（ＤＣＴ）／離散正弦変換（ＤＳＴ）ファミリから選択された複数の変換を使用する。図１２は、選択されたＤＳＴ／ＤＣＴ変換の変換基底関数を示す。
【0102】
一部の実施形態では、ＡＭＴで使用されるＤＳＴ／ＤＣＴ変換コア行列は、８ビット表現で表される。一部の実施形態では、ＡＭＴは、幅および高さの両方が３２以下であるＣＵに適用される。ＡＭＴを適用するかどうかは、ｍｔｓ＿ｆｌａｇで示されるフラグによって制御されることができる。例えば、ｍｔｓ＿ｆｌａｇが０に等しい場合、ＤＣＴ－２のみが残差ブロックの符号化に適用される。ｍｔｓ＿ｆｌａｇが１に等しい場合、ｍｔｓ＿ｉｄｘで示されるインデックスは、使用されるべき水平および垂直変換を指定するように、２つのビンを用いてさらにシグナリングされることができる。
【0103】
図１３は、ｍｔｓ＿ｉｄｘ値とそれぞれの水平または垂直変換との間のマッピング関係を示す表（１３００）を示す。値が－１のｍｔｓ＿ｉｄｘを持つ行（１３０１）は、ｍｔｓ＿ｆｌａｇが０に等しいシナリオに対応し、ＤＣＴ－２変換が使用される。値が０、１、２、または３のｍｔｓ＿ｉｄｘを持つ行（１３０２）～（１３０５）は、ｍｔｓ＿ｆｌａｇが１に等しいシナリオに対応する。表（１３００）の右側の２列において、０はＤＣＴ－２の変換タイプを表し、１はＤＳＴ－７の変換タイプを表し、２はＤＣＴ８の変換タイプを表す。
【0104】
【0105】
６、イントラサブパーティション（ＩＳＰ）符号化モード
一部の実施形態では、イントラサブパーティション（ＩＳＰ）符号化モードが使用される。ＩＳＰ符号化モードでは、ルマイントラ予測ブロックは、垂直または水平に２つまたは４つのサブパーティションに分割されることができる。サブパーティションの数は、ブロックのサイズによって異なることができる。図１６は、ブロックサイズに応じたサブパーティションの数を示す。図１７は、ブロックが２つのサブパーティションに分割されるシナリオを示す。図１８は、ブロックが４つのサブパーティションに分割されるシナリオを示す。一例では、すべてのサブパーティションは少なくとも１６個のサンプルを持つという条件を満たす。一例では、ＩＳＰはクロマ成分に適用されない。
一部の実施形態では、イントラサブパーティション（ＩＳＰ）符号化モードが使用される。ＩＳＰ符号化モードでは、ルマイントラ予測ブロックは、垂直または水平に２つまたは４つのサブパーティションに分割されることができる。サブパーティションの数は、ブロックのサイズによって異なることができる。図１６は、ブロックサイズに応じたサブパーティションの数を示す。図１７は、ブロックが２つのサブパーティションに分割されるシナリオを示す。図１８は、ブロックが４つのサブパーティションに分割されるシナリオを示す。一例では、すべてのサブパーティションは少なくとも１６個のサンプルを持つという条件を満たす。一例では、ＩＳＰはクロマ成分に適用されない。
【0106】
一例では、符号化ブロックから分割されたサブパーティションのそれぞれについて、残差信号は、エンコーダから送信されたそれぞれの係数をエントロピー復号し、次にそれらを逆量子化および逆変換することによって、生成される。次に、サブパーティションの最初の１つがイントラ予測され、予測信号が生成される。予測信号が第１のサブパーティションのそれぞれの残差信号に追加され、対応する再構成されたサンプルが取得される。その後、第１のサブパーティションの再構成されたサンプル値を利用して、サブパーティションのうちの第２のサブパーティションの予測を生成することができる。このプロセスは、符号化ブロックからのすべてのサブパーティションが再構成されるまで、サブパーティションごとに繰り返される。一例では、すべてのサブパーティションが同じイントラモードを共有する。
【0107】
一実施形態では、ＩＳＰ符号化モードは、最も可能性の高いモード（ＭＰＭ）リストの一部であるイントラモードでのみテストされる。したがって、ブロックがＩＳＰを使用する場合、ＭＰＭフラグは１つであると推測され得る。さらに、ＩＳＰが特定のブロックに使用されると、それぞれのＭＰＭリストが変更され、ＤＣモードが除外され、ＩＳＰ水平スプリットの水平イントラモード、及び垂直スプリットの垂直イントラモードが優先される。
【0108】
ＩＳＰ符号化モードでは、変換と再構成がサブパーティションごとに個別に実行されるため、各サブパーティションはサブＴＵと見なすことができる。
【0109】
図１９Ａ～１９Ｂは、ＩＳＰ符号化モードのためにシグラリングされる関連構文要素を含む例示的な構文テーブル（１９００）を示す。フレーム（１９１０）に示されているように、構文要素ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇは、ＩＳＰが使用されるかどうかを示す。構文要素ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇは、分割方向（垂直または水平）を示す。
【0110】
７、サブブロック変換（ＳＢＴ）
一部の実施形態では、空間的変化変換（ＳＶＴ）とも呼ぶサブブロック変換（ＳＢＴ）が使用される。ＳＢＴは、インター予測残差に適用できる。例えば、符号化ブロックはサブブロックに分割されることができ、サブブロックの一部のみが残差ブロックで処理される。サブブロックの残りの部分については、ゼロ残差であると想定される。したがって、残差ブロックは符号化ブロックよりも小さく、ＳＢＴの変換サイズは符号化ブロックサイズよりも小さくなる。残差ブロックでカバーされていない領域については、変換処理は実行されない。
一部の実施形態では、空間的変化変換（ＳＶＴ）とも呼ぶサブブロック変換（ＳＢＴ）が使用される。ＳＢＴは、インター予測残差に適用できる。例えば、符号化ブロックはサブブロックに分割されることができ、サブブロックの一部のみが残差ブロックで処理される。サブブロックの残りの部分については、ゼロ残差であると想定される。したがって、残差ブロックは符号化ブロックよりも小さく、ＳＢＴの変換サイズは符号化ブロックサイズよりも小さくなる。残差ブロックでカバーされていない領域については、変換処理は実行されない。
【0111】
図２０Ａ～２０Ｄは、サブブロックタイプ（ＳＶＴ－Ｈ、ＳＶＴ－Ｖ）（例えば、垂直または水平に分割される）、ＳＢＴでサポートされるサイズおよび位置（例えば、左半分、左１／４、右半分、右１／４、上半分、上１／４、下半分、下１／４）を示す。文字「Ａ」でラベル付けされた影付きの領域は、変換ありの残差ブロックであり、他の領域は、変換なしのゼロ残差であると想定される。
【0112】
一例として、図２１Ａ～２１Ｉは、ＳＢＴが使用される場合に、ジョイントビデオエキスパートチーム（ＪＶＥＴ）によって開発されているビデオ符号化規格（例えば、ＶＶＣ）の仕様テキストへの変更を示す。追加されたテキストは、（２１０１）から（２１１３）までのフレームに示される。示されているように、追加の構文要素ｃｕ＿ｓｂｔ＿ｆｌａｇ、ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ、ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇ、およびｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇは、それぞれサブブロックタイプ（水平または垂直）、サイズ（半分または１／４）、および位置（左または右、上または下）を示すようにシグナリングされる。
【0113】
８、ＹＵＶフォーマット
図２２は、一部の実施形態で使用される異なるＹＵＶフォーマット（例えば、４：４：４、４：２：２、４：１：１、および４：２：０）を示す。一例では、クロス成分線形モデルイントラ予測（cross component linear model intra prediction）は４：２：０フォーマットに用いられる。図２２に示すように、６タップ補間フィルタを適用して、クロマサンプルに対応するダウンサンプリングされたルマサンプルを取得することができる。公式的に、ダウンサンプリングされたルマサンプルＲｅｃ’Ｌ［ｘ，ｙ］は、近くの再構成されたルマサンプル（ＲｅｃＬ［ｘ，ｙ］で表される）から次の方法で計算されてもよい。
図２２は、一部の実施形態で使用される異なるＹＵＶフォーマット（例えば、４：４：４、４：２：２、４：１：１、および４：２：０）を示す。一例では、クロス成分線形モデルイントラ予測（cross component linear model intra prediction）は４：２：０フォーマットに用いられる。図２２に示すように、６タップ補間フィルタを適用して、クロマサンプルに対応するダウンサンプリングされたルマサンプルを取得することができる。公式的に、ダウンサンプリングされたルマサンプルＲｅｃ’Ｌ［ｘ，ｙ］は、近くの再構成されたルマサンプル（ＲｅｃＬ［ｘ，ｙ］で表される）から次の方法で計算されてもよい。
【0114】
【数1】
仮想パイプラインデータユニット（ＶＰＤＵ）は、ピクチャ内で非重複ユニットとして定義される。ハードウェアデコーダでは、連続するＶＰＤＵは複数のパイプラインステージによって同時に処理される。ＶＰＤＵサイズは、ほとんどのパイプラインステージでバッファサイズにほぼ比例する。ＶＰＤＵを特定のサイズ（例えば、６４×６４以下）に維持することが望ましい。最大変換ブロック（ＴＢ）のサイズは、一部のハードウェアデコーダによって必要とされるＶＰＤＵサイズに一致するように、ビデオ符号化規格で指定されてもよい。しかし、一部の例では、三分木（ＴＴ）および二分木（ＢＴ）分割を特定の制限なしで使用すると、結果の変換ブロックは、意図された最大変換ブロックサイズ（例えば、６４×６４）またはＶＰＤＵサイズと整合しないことがある。
【0115】
ＶＰＤＵサイズを６４×６４のルマサンプルとして維持するために、一部の実施形態では、以下の規範的な分割制限（構文シグナリング変更を伴う）が適用される。
- ＴＴスプリットは、幅または高さのいずれか、または幅と高さの両方が１２８に等しいＣＵでは許容されない。
- Ｎ≦６４（すなわち、幅が１２８に等しく、高さが１２８より小さい）の１２８×ＮのＣＵの場合、水平ＢＴは許容されない。
- Ｎ≦６４（すなわち、高さが１２８に等しく、幅が１２８より小さい）のＮ×１２８のＣＵの場合、垂直ＢＴは許容されない。
-
- ＴＴスプリットは、幅または高さのいずれか、または幅と高さの両方が１２８に等しいＣＵでは許容されない。
- Ｎ≦６４（すなわち、幅が１２８に等しく、高さが１２８より小さい）の１２８×ＮのＣＵの場合、水平ＢＴは許容されない。
- Ｎ≦６４（すなわち、高さが１２８に等しく、幅が１２８より小さい）のＮ×１２８のＣＵの場合、垂直ＢＴは許容されない。
-
【0116】
図２３は、許容されないＴＴおよびＢＴ分割の例を示す。
【0117】
ＩＩＩ、変換ブロック分割および処理手法
一部の実施形態では、一定の最大許容変換ユニット（ＴＵ）サイズ（例えば、６４×６４ピクチャまたはサンプル）が使用される。例えば、ツリー構造に基づく分割を実行することにより、ピクチャまたはスライスを符号化ブロックに分割して、イントラまたはインター予測処理を行うことができる。変換処理について、符号化ブロックが最大許容ＴＵサイズよりも大きい場合（例えば、辺の長さが６４サンプルよりも大きい場合、または幅と高さの両方が６４サンプルよりも大きい場合）、結果のサブブロックのサイズが最大許容ＴＵサイズと一致するように、符号化ブロックをさらにサブブロックに分割することができる。
一部の実施形態では、一定の最大許容変換ユニット（ＴＵ）サイズ（例えば、６４×６４ピクチャまたはサンプル）が使用される。例えば、ツリー構造に基づく分割を実行することにより、ピクチャまたはスライスを符号化ブロックに分割して、イントラまたはインター予測処理を行うことができる。変換処理について、符号化ブロックが最大許容ＴＵサイズよりも大きい場合（例えば、辺の長さが６４サンプルよりも大きい場合、または幅と高さの両方が６４サンプルよりも大きい場合）、結果のサブブロックのサイズが最大許容ＴＵサイズと一致するように、符号化ブロックをさらにサブブロックに分割することができる。
【0118】
使用される一定の最大許容ＴＵサイズがビデオ符号化規格で指定されることができるため、ハードウェアエンコーダまたはデコーダでマルチステージパイプラインを介して処理されるＶＰＤＵのサイズは決定されることができる。最大許容ＴＵサイズに応じた変換ブロック分割により、パイプライン化されたエンコーダまたはデコーダによって必要とされるＶＰＤＵサイズと一致するサイズの変換ブロックが生成される。
【0119】
対照的に、一部の実施形態では、制御可能または構成可能な最大許容ＴＵサイズが使用される。例えば、６４×６４サンプルのサイズの他に、最大ＴＵサイズは、３２×３２サンプル、１６×１６サンプルなどの他のサイズであり得る。最大ＴＵサイズは、エンコーダ側で決定され、デコーダ側にシグナリングされることができる。最大許容ＴＵサイズの当該柔軟性は、エンコーダ実装（例えば、パイプライン中間バッファサイズ、乗算器の数など）のハードウェアの複雑さに影響を与え、ハードウェアエンコーダのパフォーマンスを潜在的に向上させることができるため、望ましい。
【0120】
制御可能な最大許容ＴＵサイズが使用される場合、最大ＴＵサイズ（例えば、１６×１６サンプル）がＶＰＤＵサイズ（例えば、６４×６４サンプル）よりも小さい可能性がある。そのようなシナリオの下で、一部の実施形態では、特定の変換ブロック分割手法を用いて、符号化ブロックを変換ブロックに分割する。それらの変換ブロックは、最大許容ＴＵサイズを有する。同時に、それらの変換ブロックの分割はＶＰＤＵサイズと互換性がある。または、言い換えると、結果の変換ブロックは、ＶＰＤＵサイズに基づくパイプライン処理の要件と互換性がある。
【0121】
さらに、一部の実施形態では、それらの変換ブロックは、処理されたブロックがパイプライン処理に適したＶＰＤＵに組み合わせられることができるように、特定の順序に従って処理される。例えば、デコーダでのそれらの変換ブロックの処理は、例えば、エントロピー復号、逆量子化、逆変換などを含んでもよい。パイプライン処理は、例えば、ブロック再構成、デブロッキング、サンプル適応オフセット（ＳＡＯ）処理、適応ループフィルタ（ＡＬＦ）処理などを含んでもよい。
【0122】
１、例Ａ
一例では、最大許容ＴＵサイズは、Ｍサンプル（例えば、Ｍ×Ｍサンプルのサイズ）に設定される。ＶＰＤＵサイズはＫサンプル（例えば、Ｋ×Ｋサンプルのサイズ）に設定される。符号化ブロック（またはＣＵ）の幅はＷサンプル、高さはＨサンプルである。符号化ブロックは、ＶＰＤＵサイズＫと最大許容ＴＵサイズＭとに基づいて、次の方法で分割されてもよい。まず、Ｗ×Ｈサンプルのサイズの符号化ブロックはサブ処理ユニット（ＳＰＵ）と呼ぶ複数のサブブロックに分割されることができ、各サブブロックのサイズはＭｉｎ（Ｗ，Ｋ）×Ｍｉｎ（Ｈ，Ｋ）サンプルである。次に、各ＳＰＵは、Ｍ×Ｍサンプルのサイズを持つ変換ブロック（またはＴＵ）にさらに分割される。それらの変換ブロックは、サブＴＵと呼ぶことがある。
一例では、最大許容ＴＵサイズは、Ｍサンプル（例えば、Ｍ×Ｍサンプルのサイズ）に設定される。ＶＰＤＵサイズはＫサンプル（例えば、Ｋ×Ｋサンプルのサイズ）に設定される。符号化ブロック（またはＣＵ）の幅はＷサンプル、高さはＨサンプルである。符号化ブロックは、ＶＰＤＵサイズＫと最大許容ＴＵサイズＭとに基づいて、次の方法で分割されてもよい。まず、Ｗ×Ｈサンプルのサイズの符号化ブロックはサブ処理ユニット（ＳＰＵ）と呼ぶ複数のサブブロックに分割されることができ、各サブブロックのサイズはＭｉｎ（Ｗ，Ｋ）×Ｍｉｎ（Ｈ，Ｋ）サンプルである。次に、各ＳＰＵは、Ｍ×Ｍサンプルのサイズを持つ変換ブロック（またはＴＵ）にさらに分割される。それらの変換ブロックは、サブＴＵと呼ぶことがある。
【0123】
さらに、一例では、ＳＰＵはそれぞれＶＰＤＵとして扱われ、それらのＶＰＤＵはマルチステージパイプラインを通ることができる。ＳＰＵは、第１の順序に従って処理できる。ＳＰＵを処理するための第１の順序に基づいて、サブＴＵを処理する順序を決定することができる。例えば、第１と第２のＳＰＵは、マルチステージパイプラインを介して連続して処理される。したがって、第１のＳＰＵにおけるサブＴＵは、最初に処理され（例えば、エントロピー復号、逆量子化、および逆変換）、そしてマルチステージパイプラインに入力される。続いて、第２のＳＰＵにおけるサブＴＵが処理され、マルチステージパイプラインに入力される。サブＰＵをこの順序で処理することにより、ＶＰＤＵに基づくパイプライン処理の要件を満たすことができる。
【0124】
さらに、各ＳＰＵ内で、サブＴＵは、第２の順序に従って処理できる。
【0125】
さまざまな実施形態において、ＳＰＵを処理するための第１の順序およびＳＰＵ内のサブＴＵを処理するための第２の順序は、ラスタースキャン順序、垂直スキャン順序（例えば、ＳＰＵまたはサブＴＵを列方向に左から右に、またはその逆にスキャンする）、ジグザグ順序、対角線スキャン（diagonal scan）順序などのうちの１つであり得る。
【0126】
第１の順序および第２の順序は、異なる実施形態において同じであっても異なっていてもよい。例えば、一実施形態では、ＳＰＵを処理するための第１の順序およびＳＰＵ内のサブＴＵを処理するための第２の順序は両方ともラスタースキャン順序である。
【0127】
２、例Ｂ
図２４は、Ｗ＝１２８、およびＨ＝６４であるＷ×Ｈサンプルのサイズを有する符号化ブロック（またはＣＵ）（２４１０）を示す。Ｍ＝３２サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。変換ブロックをＶＰＤＵと整合させるために、符号化ブロック（２４１０）は最初に左側の６４×６４のＳＰＵ（２４２０）と右側の６４×６４のＳＰＵ（２４３０）とにスプリットされる。次に、左側のＳＰＵ（２４２０）と右側のＳＰＵ（２４３０）とは、それぞれ３２×３２サンプルのサイズを有するサブＴＵ（０から７のラベルが付けられる）にさらに分割されることができる。０、１、２、および３でラベル付けされたサブＴＵは、第１のＳＰＵ（２４２０）に含まれ、４、５、６、および７でラベル付けされたサブＴＵは、第２のＳＰＵ（２４３０）に含まれる。
図２４は、Ｗ＝１２８、およびＨ＝６４であるＷ×Ｈサンプルのサイズを有する符号化ブロック（またはＣＵ）（２４１０）を示す。Ｍ＝３２サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。変換ブロックをＶＰＤＵと整合させるために、符号化ブロック（２４１０）は最初に左側の６４×６４のＳＰＵ（２４２０）と右側の６４×６４のＳＰＵ（２４３０）とにスプリットされる。次に、左側のＳＰＵ（２４２０）と右側のＳＰＵ（２４３０）とは、それぞれ３２×３２サンプルのサイズを有するサブＴＵ（０から７のラベルが付けられる）にさらに分割されることができる。０、１、２、および３でラベル付けされたサブＴＵは、第１のＳＰＵ（２４２０）に含まれ、４、５、６、および７でラベル付けされたサブＴＵは、第２のＳＰＵ（２４３０）に含まれる。
【0128】
設定されたまたはデフォルトの順序に従って、左側のＳＰＵ（２４２０）を最初に処理し、次に右側のＳＰＵ（２４３０）を処理することができる。各ＳＰＵ（２４２０）または（２４３０）内で、結果のサブＴＵ（０から７のラベルが付けられる）を処理するためのラスタースキャン順序を指定（またはデフォルト）することができる。したがって、０から７までのラベルが付けられたサブＴＵは、矢印（２４５１）によって示される順序に従って処理される。
【0129】
３、例Ｃ
図２５は、Ｗ＝１２８、およびＨ＝３２であるＷ×Ｈサンプルのサイズを有する符号化ブロック（２５１０）を示す。Ｍ＝１６サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。ＷとＫの小さい方は６４で、ＨとＫの小さい方は３２である。したがって、変換ブロックをＶＰＤＵと整合させるために、ＳＰＵのサイズを６４×３２サンプルと決定することができる。符号化ブロック（２５１０）は、それぞれ６４×３２サンプルのサイズを有する左側のＳＰＵ（２５２０）および右側のＳＰＵ（２５３０）に分割されることができる。２つのＳＰＵ（２５２０）と（２５３０）は、左から右の順序で処理できる。
図２５は、Ｗ＝１２８、およびＨ＝３２であるＷ×Ｈサンプルのサイズを有する符号化ブロック（２５１０）を示す。Ｍ＝１６サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。ＷとＫの小さい方は６４で、ＨとＫの小さい方は３２である。したがって、変換ブロックをＶＰＤＵと整合させるために、ＳＰＵのサイズを６４×３２サンプルと決定することができる。符号化ブロック（２５１０）は、それぞれ６４×３２サンプルのサイズを有する左側のＳＰＵ（２５２０）および右側のＳＰＵ（２５３０）に分割されることができる。２つのＳＰＵ（２５２０）と（２５３０）は、左から右の順序で処理できる。
【0130】
２つのＳＰＵ（２５２０）と（２５３０）のそれぞれは、それぞれが最大許容ＴＵサイズである１６×１６サンプルを持つサブＴＵ（０から１５のラベルが付けられる）にさらにスプリットされることができる。示されているように、左側のＳＰＵ（２５２０）は０から７のラベルが付けられたサブＴＵに分割され、右側のＳＰＵ（２５３０）は８から１５のラベルが付けられたサブＴＵに分割される。各ＳＰＵ（２５２０）および（２５３０）内で、サブＴＵをラスタースキャン順序で処理することができる。したがって、０から１５までのラベルが付けられたサブＴＵは、矢印（２５５１）によって示される順序で実行されることができる。
【0131】
４、例Ｄ
図２６は、Ｗ＝１２８、およびＨ＝３２であるＷ×Ｈサンプルのサイズを有する符号化ブロック（２６１０）を示す。Ｍ＝１６サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。図２５の例と同様の方法で、符号化ブロック（２６１０）は、２つのＳＰＵ（２６２０）および（２６３０）に分割されることができ、それぞれのＳＰＵは、０から１５までのラベルが付けられたサブＴＵにさらに分割されることができる。ＳＰＵ（２６２０）および（２６３０）は、図２５と同じ順序で左から右に処理されることができる。しかしながら、図２５の例とは異なり、各ＳＰＵ（２６２０）および（２６３０）内のサブＴＵは、ジグザグスキャン順序で処理される。
図２６は、Ｗ＝１２８、およびＨ＝３２であるＷ×Ｈサンプルのサイズを有する符号化ブロック（２６１０）を示す。Ｍ＝１６サンプルの最大許容ＴＵサイズは、エンコーダからデコーダにシグナリングされる。ＶＰＤＵサイズはＫ＝６４サンプルとして指定される。図２５の例と同様の方法で、符号化ブロック（２６１０）は、２つのＳＰＵ（２６２０）および（２６３０）に分割されることができ、それぞれのＳＰＵは、０から１５までのラベルが付けられたサブＴＵにさらに分割されることができる。ＳＰＵ（２６２０）および（２６３０）は、図２５と同じ順序で左から右に処理されることができる。しかしながら、図２５の例とは異なり、各ＳＰＵ（２６２０）および（２６３０）内のサブＴＵは、ジグザグスキャン順序で処理される。
【0132】
５、例Ｅ
図２７は、本開示の一実施形態による、変換ブロック分割および処理プロセス（２７００）を概説するフローチャートを示す。プロセス（２７００）は、イントラモードまたはインターモードで符号化されたブロックの再構成に使用される。さまざまな実施形態では、プロセス（２７００）は、端末デバイス（２１０）、（２２０）、（２３０）、および（２４０）の処理回路、ビデオデコーダ（３１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路などの処理回路によって実行される。一部の実施形態では、プロセス（２７００）はソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（２７００）を実行する。プロセスは（Ｓ２７０１）から始まり、（Ｓ２７１０）に進む。
図２７は、本開示の一実施形態による、変換ブロック分割および処理プロセス（２７００）を概説するフローチャートを示す。プロセス（２７００）は、イントラモードまたはインターモードで符号化されたブロックの再構成に使用される。さまざまな実施形態では、プロセス（２７００）は、端末デバイス（２１０）、（２２０）、（２３０）、および（２４０）の処理回路、ビデオデコーダ（３１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路などの処理回路によって実行される。一部の実施形態では、プロセス（２７００）はソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（２７００）を実行する。プロセスは（Ｓ２７０１）から始まり、（Ｓ２７１０）に進む。
【0133】
（Ｓ２７１０）では、Ｍの最大許容ＴＵサイズを示す構文要素をビットストリームから受信することができる。例えば、制御可能な最大許容ＴＵサイズが用いられる。最大許容ＴＵサイズは、エンコーダで決定され、デコーダにシグナリングされる。
【0134】
（Ｓ２７２０）では、Ｗピクセルの幅、及びＨピクセルの高さを有する符号化ブロックをデコーダで受信できる。例えば、上記幅と高さを有する符号化ブロックを示す構文要素は、デコーダでビットストリームから受信されることができる。
【0135】
（Ｓ２７３０）では、符号化ブロックはＳＰＵに分割される。例えば、Ｋ×Ｋサンプル（またはピクセル）のＶＰＤＵサイズをデコーダに事前設定することができる。ＶＰＤＵサイズと符号化ブロックのサイズとに基づいて、ＳＰＵのサイズを決定することができる。例えば、ＳＰＵの幅はＷまたはＫピクセルの小さい方にすることができ、ＳＰＵの高さはＨまたはＫピクセルの小さい方にすることができる。したがって、符号化ブロックは、それぞれが決定された幅および高さを有するＳＰＵに分割されることができる。
【0136】
（Ｓ２７４０）では、各ＳＰＵはサブＴＵに分割され、各サブＴＵはＭの最大許容ＴＵサイズを有する。
【0137】
（Ｓ２７５０）では、ＳＰＵのサブＴＵはＳＰＵ処理順序に従って処理される。例えば、ＳＰＵ処理順序は、例えばマルチステージパイプラインを介してＳＰＵを処理するために事前定義できる。各ＳＰＵ内で、サブＴＵは事前定義された順序に従って処理できる。あるいは、ＳＰＵまたはサブＴＵを処理するための順序は、制御可能にされ、デコーダからシグナリングされてもよい。
【0138】
例えば、各ＳＰＵ内のＳＰＵ処理順序およびサブＴＵ処理順序に従って、各サブＴＵの残差信号は、一連の復号動作（例えば、変換係数のエントロピー復号、逆量子化、逆変換など）によって取得されることができる。一例では、残差信号を組み合わせて、ＳＰＵごとにマルチステージパイプラインに入力することができる。上記プロセスは（Ｓ２７９９）に進み、（Ｓ２７９９）で終了できる。
【0139】
ＩＶ、コンピュータシステム
以上で説明された技術は、コンピュータ読取可能な命令を用いるコンピュータソフトウェアとして実現され、１つ以上のコンピュータ読取可能な媒体に物理的に記憶されることができる。例えば、図２８は、開示された主題のある実施形態を実施することに適したコンピュータシステム（２８００）を示す。
以上で説明された技術は、コンピュータ読取可能な命令を用いるコンピュータソフトウェアとして実現され、１つ以上のコンピュータ読取可能な媒体に物理的に記憶されることができる。例えば、図２８は、開示された主題のある実施形態を実施することに適したコンピュータシステム（２８００）を示す。
【0140】
コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、またはそのようなメカニズムを施されて、１つ以上のコンピュータ中央処理装置（ＣＰＵ）、グラフィックスプロセッシングユニット（ＧＰＵ）などによって直接、または解釈、マイクロコード実行などによって実行されることができる命令を含むコードを作成する任意の適切な機械コードまたはコンピュータ言語を用いて符号化されることができる。
【0141】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはそのコンポーネント上で実行されることができる。
【0142】
コンピュータシステム（２８００）について、図２８に示されるコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関していかなる限定を示唆することも意図しない。コンポーネントの構成は、コンピュータシステム（２８００）の例示的な実施形態で示されるコンポーネントのうちのいずれか１つまたは組み合わせに関する任意の依存性または必要性を有するとして解釈されるべきではない。
【0143】
コンピュータシステム（２８００）は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（音声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（描画せず）によって、１人以上のユーザによる入力に応答することができる。ヒューマンインターフェースデバイスは、オーディオ（音声、音楽、環境音など）、画像（走査画像、静止画像カメラから取得される写真画像など）、ビデオ（２次元ビデオ、立体ビデオを含む３次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係しない特定のメディアをキャプチャすることにも使用できる。
【0144】
入力ヒューマンインターフェースデバイスは、キーボード（２８０１）、マウス（２８０２）、トラックパッド（２８０３）、タッチスクリーン（２８１０）、データグローブ（図示せず）、ジョイスティック（２８０５）、マイクロフォン（２８０６）、スキャナ（２８０７）、カメラ（２８０８）（それぞれ１つのみ示されている）のうちの１つ以上を含み得る。
【0145】
コンピュータシステム（２８００）は、特定のヒューマンインターフェース出力デバイスをも含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音声、光、および嗅覚／味覚を介して１人以上のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（２８１０）、データグローブ（図示せず）、またはジョイスティック（２８０５）による触覚フィードバックがあるが、入力デバイスとして機能しない触覚フィードバックデバイスであってもよい）、オーディオ出力デバイス（スピーカ（２８０９）、ヘッドホン（描画せず）など）、視覚出力デバイス（ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン（２８１０）（それぞれタッチスクリーン入力能力を有するかもしくは有せず、それぞれ触覚フィードバック能力を有するかもしくは有しない。それらの一部は、ステレオグラフィック出力などの手段を介して、２次元の視覚出力または３次元以上の出力を出力することができる）、仮想現実眼鏡（示されていない）、ホログラフィックディスプレイおよびスモークタンク（示されていない）など）、およびプリンタ（示されていない）を含み得る。
【0146】
コンピュータシステム（２８００）は、人間がアクセス可能な記憶装置およびそれらの関連する媒体、例えば、ＣＤ／ＤＶＤなどの媒体（２８２１）付きのＣＤ／ＤＶＤ ＲＯＭ／ＲＷ（２８２０）を含む光学媒体、サムドライブ（２８２２）、リムーバブルハードドライブまたはソリッドステートドライブ（２８２３）、テープやフロッピーディスクなどの従来の磁気媒体（描画せず）、セキュリティドングルなどの専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイス（描画せず）などをも含むことができる。
【0147】
ここで開示された主題に関連して使用される「コンピュータ読取可能な媒体」という用語は、送信媒体、搬送波、または他の一時的な信号を包含しないことをも当業者が理解するべきである。
【0148】
コンピュータシステム（２８００）は、１つ以上の通信ネットワークへのインターフェースをさらに含むことができる。ネットワークは、例えば、無線、有線、光学的であり得る。ネットワークは、さらに、ローカル、広域、大都市圏、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネット、無線ＬＡＮなどのローカルエリアネットワーク、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、および地上放送ＴＶを含むＴＶ有線または無線広域デジタルネットワーク、ＣＡＮＢｕｓを含む車両用や産業用などを含む。特定のネットワークは、一般に、特定の汎用データポートまたは周辺バス（２８４９）（例えば、コンピューターシステム（２８００）のＵＳＢポートなど）に接続された外部ネットワークインターフェースアダプターを必要とする。他のものは一般に、以下で説明するようにシステムバスに接続することにより、コンピュータシステム（２８００）のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワークのいずれかを用いて、コンピュータシステム（２８００）は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ（例えば、放送ＴＶ）、単方向の送信のみ（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、または双方向、例えばローカルまたはワイドエリアデジタルネットワークを用いる他のコンピュータシステムへの送信であり得る。特定のプロトコルおよびプロトコルスタックを上述したこれらのネットワークおよびネットワークインターフェースのそれぞれで用いることができる。
【0149】
前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム（２８００）のコア（２８４０）に接続されることができる。
【0150】
コア（２８４０）は、１つ以上の中央処理装置（ＣＰＵ）（２８４１）、グラフィックスプロセッシングユニット（ＧＰＵ）（２８４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）（２８４３）の形態での専用プログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ（２８４４）などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）（２８４５）、ランダムアクセスメモリ（２８４６）、非ユーザアクセス可能な内部ハードドライブ、ＳＳＤなどの内部大容量記憶装置（２８４７）とともに、システムバス（２８４８）を介して接続されてもよい。一部のコンピュータシステムでは、システムバス（２８４８）は、１つ以上の物理プラグの形態でアクセスでき、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にする。周辺機器は、コアのシステムバス（２８４８）に直接、または周辺バス（２８４９）を介して接続されることができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢなどを含む。
【0151】
ＣＰＵ（２８４１）、ＧＰＵ（２８４２）、ＦＰＧＡ（２８４３）、およびアクセラレータ（２８４４）は、組み合わせて、前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ（２８４５）またはＲＡＭ（２８４６）に記憶されることができる。推移データはＲＡＭ（２８４６）にも記憶できるが、永続データは、例えば、内部大容量ストレージ（２８４７）に記憶されることができる。１つ以上のＣＰＵ（２８４１）、ＧＰＵ（２８４２）、大容量ストレージ（２８４７）、ＲＯＭ（２８４５）、ＲＡＭ（２８４６）などと密接に関連付けることができるキャッシュメモリを用いることにより、任意のメモリデバイスへの高速保存および検索が可能になる。
【0152】
コンピュータ読取可能な媒体は、様々なコンピュータ実施操作を実行するためのコンピュータコードを備えることができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、もしくは、それらは、コンピュータソフトウェア技術の当業者に周知であって利用可能な種類のものであり得る。
【0153】
限定ではなく、一例として、アーキテクチャを有するコンピュータシステム（２８００）、特にコア（２８４０）は、１つ以上の有形のコンピュータ読取可能な媒体に組み込まれたソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）の結果としての機能性を提供することができる。このようなコンピュータ読取可能な媒体は、以上で説明したようにユーザがアクセス可能な大容量ストレージ、および、コア内部大容量ストレージ（２８４７）またはＲＯＭ（２８４５）などの非一時的な性質を持つコア（２８４０）の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実行するソフトウェアは、このようなデバイスに記憶され、コア（２８４０）によって実行されることができる。コンピュータ読取可能な媒体は、特定の必要に応じて、１つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア（２８４０）、具体的にはその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ（２８４６）に記憶されたデータ構造を定義すること、および、ソフトウェアで定義されたプロセスに従ってこのようなデータ構造を変更する言を含む、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または、代替として、コンピュータシステムは、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりにまたは一緒に動作することができる回路（例えば、アクセラレータ（２８４４））に有線接続されたまたは組み込まれたロジックの結果としての機能性を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを含むことができ、その逆も同様である。コンピュータ読取可能な媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（ＩＣ）など）、実行のためのロジックを具現化する回路、またはその両方を含むことができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを含む。
【0154】
付録Ａ：頭字語
ＡＳＩＣ：特定用途向け集積回路
ＢＭＳ：ベンチマークセット
ＣＡＮＢｕｓ：コントローラエリアネットワークバス
ＣＢＦ：符号化されたブロックフラグ
ＣＤ：コンパクトディスク
ＣＰＵ：中央処理装置
ＣＲＴ：陰極線管
ＣＴＢ：符号化ツリーブロック
ＣＴＵ：符号化ツリーユニット
ＣＵ：符号化ユニット
ＤＶＤ：デジタルビデオディスク
ＦＰＧＡ：フィールドプログラマブルゲートエリア
ＧＯＰ：ピクチャグループ
ＧＰＵ：グラフィックス処理装置
ＧＳＭ：グローバルモバイル通信システム
ＨＥＶＣ：高効率ビデオ符号化
ＨＲＤ：仮想参照デコーダ
ＩＳＰ：イントラサブパーティション
ＩＣ：集積回路
ＪＥＭ：共同探索モデル
ＬＡＮ：ローカルエリアネットワーク
ＬＣＤ：液晶ディスプレイ
ＬＴＥ：長期的な進化
ＭＰＭ：最も可能性の高いモード
ＭＶ：動きベクトル
ＯＬＥＤ：有機発光ダイオード
ＰＢ：予測ブロック
ＰＣＩ：周辺構成要素相互接続
ＰＬＤ：プログラマブルロジックデバイス
ＰＵ：予測ユニット
ＲＡＭ：ランダムアクセスメモリ
ＲＯＭ：読み取り専用メモリ
ＳＢＴ：サブブロック変換
ＳＥＩ：補助強化情報
ＳＮＲ：信号対雑音比
ＳＳＤ：ソリッドステートドライブ
ＴＵ：変換ユニット
ＵＳＢ：ユニバーサルシリアルバス
ＶＰＤＵ：仮想パイプラインデータユニット
ＶＵＩ：ビデオユーザビリティ情報
ＶＶＣ：多用途ビデオ符号化
ＡＳＩＣ：特定用途向け集積回路
ＢＭＳ：ベンチマークセット
ＣＡＮＢｕｓ：コントローラエリアネットワークバス
ＣＢＦ：符号化されたブロックフラグ
ＣＤ：コンパクトディスク
ＣＰＵ：中央処理装置
ＣＲＴ：陰極線管
ＣＴＢ：符号化ツリーブロック
ＣＴＵ：符号化ツリーユニット
ＣＵ：符号化ユニット
ＤＶＤ：デジタルビデオディスク
ＦＰＧＡ：フィールドプログラマブルゲートエリア
ＧＯＰ：ピクチャグループ
ＧＰＵ：グラフィックス処理装置
ＧＳＭ：グローバルモバイル通信システム
ＨＥＶＣ：高効率ビデオ符号化
ＨＲＤ：仮想参照デコーダ
ＩＳＰ：イントラサブパーティション
ＩＣ：集積回路
ＪＥＭ：共同探索モデル
ＬＡＮ：ローカルエリアネットワーク
ＬＣＤ：液晶ディスプレイ
ＬＴＥ：長期的な進化
ＭＰＭ：最も可能性の高いモード
ＭＶ：動きベクトル
ＯＬＥＤ：有機発光ダイオード
ＰＢ：予測ブロック
ＰＣＩ：周辺構成要素相互接続
ＰＬＤ：プログラマブルロジックデバイス
ＰＵ：予測ユニット
ＲＡＭ：ランダムアクセスメモリ
ＲＯＭ：読み取り専用メモリ
ＳＢＴ：サブブロック変換
ＳＥＩ：補助強化情報
ＳＮＲ：信号対雑音比
ＳＳＤ：ソリッドステートドライブ
ＴＵ：変換ユニット
ＵＳＢ：ユニバーサルシリアルバス
ＶＰＤＵ：仮想パイプラインデータユニット
ＶＵＩ：ビデオユーザビリティ情報
ＶＶＣ：多用途ビデオ符号化
【0155】
本開示は一部の例示的な実施形態を説明してきたが、本開示の範囲内に含まれる変更、置換、およびさまざまな代替の均等物が存在する。したがって、当業者は、本明細書では明示的に示されていないか、または記載されていないが、本開示の原理を具現化し、その思想および範囲内に含まれるさまざまなシステムおよび方法を考案できることが理解されよう。
【符号の説明】
【0156】
２００ 通信システム
２１０ 端末装置
２２０ 端末装置
２３０ 端末装置
２４０ 端末装置
２５０ 通信ネットワーク
２１０ 端末装置
２２０ 端末装置
２３０ 端末装置
２４０ 端末装置
２５０ 通信ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9A】
【図9B】
【図10A】
【図10B】
【図10C】
【図10D】
【図11A】
【図11B】
【図11C】
【図11D】
【図11E】
【図12】
【図13】
【図14A】
【図14B】
【図14C】
【図14D】
【図15A】
【図15B】
【図15C】
【図15D】
【図16】
【図17】
【図18】
【図19A】
【図19B】
【図20A】
【図20B】
【図20C】
【図20D】
【図21A】
【図21B】
【図21C】
【図21D】
【図21E】
【図21F】
【図21G】
【図21H】
【図21I】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】