特許7119232デコーダが実行するビデオデコーディングのための方法及び装置、並びにエンコーダが実行するビデオエンコーディングのための方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-08-05
(45)【発行日】2022-08-16
(54)【発明の名称】デコーダが実行するビデオデコーディングのための方法及び装置、並びにエンコーダが実行するビデオエンコーディングのための方法
(51)【国際特許分類】
H04N 19/122 20140101AFI20220808BHJP
H04N 19/156 20140101ALI20220808BHJP
H04N 19/18 20140101ALI20220808BHJP
H04N 19/436 20140101ALI20220808BHJP
【ＦＩ】
H04N19/122
H04N19/156
H04N19/18
H04N19/436
【請求項の数】
21
(21)【出願番号】P 2021536074
(86)(22)【出願日】2020-03-20
(65)【公表番号】
(43)【公表日】2022-02-14
(86)【国際出願番号】 US2020023752
(87)【国際公開番号】W WO2020197957
(87)【国際公開日】2020-10-01
【審査請求日】2021-06-21
(31)【優先権主張番号】62/822,787
(32)【優先日】2019-03-22
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/823,831
(32)【優先日】2020-03-19
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジャオ，シン
(72)【発明者】
【氏名】リ，シアン
(72)【発明者】
【氏名】リィウ，シャン
【審査官】久保 光宏
(56)【参考文献】
【文献】特表２０２２－５２２７７４（ＪＰ，Ａ）
【文献】特表２０２０－５３３８２２（ＪＰ，Ａ）
【文献】特表２０２２－５１５７９９（ＪＰ，Ａ）
【文献】Chih-Wei Hsu, et al.，"CE1-related: Constraint for binary and ternary partitions"，JVET-K0556 (version 2)，[online], Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2018年07月16日，Pages 1-3，[令和4年6月27日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=4086> and <URL: https://jvet-experts.org/doc_end_user/documents/11_Ljubljana/wg11/JVET-K0556-v2.zip>.
【文献】Jianle Chen, et al.，"Algorithm description for Versatile Video Coding and Test Model 4 (VTM 4)"，JVET-M1002 (version 2)，[online], Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2019年03月19日，Pages 1-14，[令和4年6月27日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=5756> and <URL: https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M1002-v2.zip>.
【文献】C. Rosewarne, et al.，"CE1: Transform tiling for pipelined processing of CTUs (Test 1.2.1)"，JVET-M0236 (version 1)，[online], Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2019年01月02日，Pages 1-4，[令和4年6月27日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=5043> and <URL: https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M0236-v1.zip>.
【文献】村上 篤道（外２名）編，「高効率映像符号化技術 HEVC/H.265とその応用」，第１版，日本，株式会社オーム社，2013年02月25日，第85～88,136～139頁，ISBN: 978-4-274-21329-8.
【文献】大久保 榮 監修，「インプレス標準教科書シリーズ H.265/HEVC教科書」，初版，日本，株式会社インプレスジャパン，2013年10月21日，第108～114頁，ISBN: 978-4-8443-3468-2.
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ１９／００－１９／９８
ＣＳＤＢ（日本国特許庁）
ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）
(57)【特許請求の範囲】
【請求項1】
デコーダが実行するビデオデコーディングのための方法であって、コーディングされたビデオビットストリームからピクチャ内のコーディングブロック（ＣＢ）のコーディングされた情報をデコーディングするステップであり、該コーディングされた情報は前記ＣＢのＷ個のサンプルの幅及びＨ個のサンプルの高さを示す、前記デコーディングするステップと、
前記ＣＢを、Ｗ及びＫのうちの最小な一方である幅と、Ｈ及びＫのうちの最小な一方である高さとを有するサブ処理ユニット（ＳＰＵ）に分割するステップであり、前記ＣＢの幅Ｗ及び高さＨのうちの少なくとも一方は処理データユニットサイズＫよりも大きい、前記分割するステップと、
前記ＳＰＵの幅及び高さと、Ｍ個のサンプルの最大変換ユニット（ＴＵ）サイズとに基づいて、前記ＳＰＵを更に分割するためのパーティショニング構造を決定するステップであり、前記ＳＰＵの幅及び高さのうちの少なくとも一方はＭよりも大きい、前記決定するステップと、
前記決定されたパーティショニング構造に基づいて前記ＳＰＵの夫々をＭ×ＭのＴＵに分割するステップと
を有する方法。
【請求項2】
前記ＳＰＵの幅及び高さは、Ｍよりも大きく、前記パーティショニング構造を決定するステップは、前記パーティショニング構造を四分木パーティショニング構造であると決定するステップを含み、
前記ＳＰＵを前記ＴＵに分割するステップは、前記四分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割するステップを含む、
請求項１に記載の方法。
【請求項3】
前記ＳＰＵの幅は、Ｍよりも大きく、前記ＳＰＵの高さは、Ｍに等しく、前記パーティショニング構造を決定するステップは、前記パーティショニング構造を垂直二分木パーティショニング構造であると決定するステップを含み、
前記ＳＰＵを前記ＴＵに分割するステップは、前記垂直二分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割するステップを含む、
請求項１に記載の方法。
【請求項4】
前記ＳＰＵの高さ、Ｍよりも大きく、前記ＳＰＵの幅は、Ｍに等しく、前記パーティショニング構造を決定するステップは、前記パーティショニング構造を水平二分木パーティショニング構造であると決定するステップを含み、
前記ＳＰＵを前記ＴＵに分割するステップは、前記水平二分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割するステップを含む、
請求項１に記載の方法。
【請求項5】
前記ＳＰＵを前記ＴＵに分割するステップは、前記パーティショニング構造に基づいて前記ＳＰＵの中の１つを再帰的に前記ＴＵに分割するステップを含む、請求項１乃至４のうちいずれか一項に記載の方法。
【請求項6】
第１スキャン順序に従って前記ＳＰＵを処理するステップと、第２スキャン順序に従って前記ＳＰＵの夫々における前記ＴＵを処理するステップと
を更に有する、請求項１乃至５のうちいずれか一項に記載の方法。
【請求項7】
前記第１スキャン順序及び前記第２スキャン順序のうちの少なくとも一方は、（ｉ）ラスタスキャン順序、（ｉｉ）垂直スキャン順序、（ｉｉｉ）ジグザグ順序、及び（ｉｖ）対角スキャン順序、のうちの１つである、請求項６に記載の方法。
【請求項8】
前記第１スキャン順序及び前記第２スキャン順序は、前記ラスタスキャン順序である、請求項７に記載の方法。
【請求項9】
Ｗは１２８であり、Ｈは６４であり、Ｋは６４であり、Ｍは３２であり、前記第１スキャン順序は、左か右であり、
前記第２スキャン順序は、ラスタスキャン順序である、
請求項６に記載の方法。
【請求項10】
前記処理データユニットサイズＫは、仮想パイプラインデータユニット（ＶＰＤＵ）のサイズを示し、前記ピクチャにおいて、前記ＳＰＵの中の第１ＳＰＵは第１ＶＰＤＵに含まれ、前記ＳＰＵの中の第２ＳＰＵは第２ＶＰＤＵに含まれ、
当該方法は、多段階パイプラインの第１段階で前記第１ＶＰＤＵを処理した後、前記多段階パイプラインの第２段階で前記第１ＶＰＤＵを、及び前記第１段階で前記第２ＶＰＤＵを同時に処理するステップを更に含む、
請求項１乃至９のうちいずれか一項に記載の方法。
【請求項11】
ビデオデコーディングのための装置であって、コーディングされたビデオビットストリームからピクチャ内のコーディングブロック（ＣＢ）のコーディングされた情報をデコーディングし、該コーディングされた情報は前記ＣＢのＷ個のサンプルの幅及びＨ個のサンプルの高さを示し、
前記ＣＢを、Ｗ及びＫのうちの最小な一方である幅と、Ｈ及びＫのうちの最小な一方である高さとを有するサブ処理ユニット（ＳＰＵ）に分割し、前記ＣＢの幅Ｗ及び高さＨのうちの少なくとも一方は処理データユニットサイズＫよりも大きく、
前記ＳＰＵの幅及び高さと、Ｍ個のサンプルの最大変換ユニット（ＴＵ）サイズとに基づいて、前記ＳＰＵを更に分割するためのパーティショニング構造を決定し、前記ＳＰＵの幅及び高さのうちの少なくとも一方はＭよりも大きく、
前記決定されたパーティショニング構造に基づいて前記ＳＰＵの夫々をＭ×ＭのＴＵに分割する
よう構成された処理回路を有する装置。
【請求項12】
前記ＳＰＵの幅及び高さは、Ｍよりも大きく、前記処理回路は、
前記パーティショニング構造を四分木パーティショニング構造であると決定し、
前記四分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割する
よう更に構成される、
請求項１１に記載の装置。
【請求項13】
前記ＳＰＵの幅は、Ｍよりも大きく、前記ＳＰＵの高さは、Ｍに等しく、前記処理回路は、
前記パーティショニング構造を垂直二分木パーティショニング構造であると決定し、
前記垂直二分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割する
よう更に構成される、
請求項１１に記載の装置。
【請求項14】
前記ＳＰＵの高さ、Ｍよりも大きく、前記ＳＰＵの幅は、Ｍに等しく、前記処理回路は、
前記パーティショニング構造を水平二分木パーティショニング構造であると決定し、
前記水平二分木パーティショニング構造に基づいて前記ＳＰＵを前記ＴＵに分割する
よう更に構成される
請求項１１に記載の装置。
【請求項15】
前記処理回路は、前記パーティショニング構造に基づいて前記ＳＰＵの中の１つを再帰的に前記ＴＵに分割するよう更に構成される、請求項１１乃至１４のうちいずれか一項に記載の装置。
【請求項16】
前記処理回路は、第１スキャン順序に従って前記ＳＰＵを処理し、
第２スキャン順序に従って前記ＳＰＵの夫々における前記ＴＵを処理する
よう更に構成される、
請求項１１乃至１５のうちいずれか一項に記載の装置。
【請求項17】
前記第１スキャン順序及び前記第２スキャン順序のうちの少なくとも一方は、（ｉ）ラスタスキャン順序、（ｉｉ）垂直スキャン順序、（ｉｉｉ）ジグザグ順序、及び（ｉｖ）対角スキャン順序、のうちの１つである、請求項１６に記載の装置。
【請求項18】
前記第１スキャン順序及び前記第２スキャン順序は、前記ラスタスキャン順序である、請求項１７に記載の装置。
【請求項19】
Ｗは１２８であり、Ｈは６４であり、Ｋは６４であり、Ｍは３２であり、前記第１スキャン順序は、左か右であり、
前記第２スキャン順序は、ラスタスキャン順序である、
請求項１６に記載の装置。
【請求項20】
前記処理データユニットサイズＫは、仮想パイプラインデータユニット（ＶＰＤＵ）のサイズを示し、前記ピクチャにおいて、前記ＳＰＵの中の第１ＳＰＵは第１ＶＰＤＵに含まれ、前記ＳＰＵの中の第２ＳＰＵは第２ＶＰＤＵに含まれ、
前記処理回路は、多段階パイプラインの第１段階で前記第１ＶＰＤＵを処理した後、前記多段階パイプラインの第２段階で前記第１ＶＰＤＵを、及び前記第１段階で前記第２ＶＰＤＵを同時に処理するよう更に構成される、
請求項１１乃至１９のうちいずれか一項に記載の装置。
【請求項21】
エンコーダが実行するビデオエンコーディングのための方法であって、ビデオビットストリームをエンコーディングするステップと、
前記コーディングされたビデオビットストリームからピクチャ内のコーディングブロック（ＣＢ）のコーディングされた情報をデコーディングするステップであり、該コーディングされた情報は前記ＣＢのＷ個のサンプルの幅及びＨ個のサンプルの高さを示す、前記デコーディングするステップと、
前記ＣＢを、Ｗ及びＫのうちの最小な一方である幅と、Ｈ及びＫのうちの最小な一方である高さとを有するサブ処理ユニット（ＳＰＵ）に分割するステップであり、前記ＣＢの幅Ｗ及び高さＨのうちの少なくとも一方は処理データユニットサイズＫよりも大きい、前記分割するステップと、
前記ＳＰＵの幅及び高さと、Ｍ個のサンプルの最大変換ユニット（ＴＵ）サイズとに基づいて、前記ＳＰＵを更に分割するためのパーティショニング構造を決定するステップであり、前記ＳＰＵの幅及び高さのうちの少なくとも一方はＭよりも大きい、前記決定するステップと、
前記決定されたパーティショニング構造に基づいて前記ＳＰＵの夫々をＭ×ＭのＴＵに分割するステップと
を有する方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ビデオコーディングに概して関係がある実施形態について記載する。
【背景技術】
【0002】
本明細書中で与えられている背景の説明は、本開示の背景を一般的に提示することを目的とするものである。現在指名されている発明者の研究は、その研究がこの背景の項で説明されている範囲で、及び出願時に先行技術としてさもなければ適格でない可能性がある説明の側面は、本開示に対する先行技術として明示的にも暗黙的にも認められない。
【0003】
ビデオコーディング及びデコーディングは、動き補償を伴ったインターピクチャ予測を用いて実行可能である。圧縮されていないデジタルビデオは、ピクチャの連続を含むことができ、各ピクチャは、例えば、１９２０×１０８０のルミナンスサンプル及び関連するクロミナンスサンプルの空間寸法を有する。ピクチャの連続は、例えば、毎秒６０ピクチャ、つまり６０Ｈｚの固定又は可変のピクチャレート（俗にフレームレートとして知られている。）を有することができる。圧縮されていないビデオは、有意なビットレート要件を有している。例えば、サンプル当たり８ビットでの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚのフレームレートでの１９２０×１０８０のルミナンスサンプル解像度）は、１．５Ｇビット／ｓに近いバンド幅を必要とする。そのようなビデオの１時間は、６００Ｇバイト超の記憶空間を必要とする。
【0004】
ビデオコーディング及びデコーディングの１つの目的は、圧縮による入力ビデオ信号の冗長性の低減であることができる。圧縮は、いくつかの場合に２桁以上、上記のバンド幅又は記憶空間要件を減らすことを助けることができる。可逆及び不可逆圧縮の両方並びにそれらの組み合わせが用いられ得る。可逆圧縮は、原信号の厳密なコピーが圧縮された原信号から再構成可能である技術を指す。不可逆圧縮を使用する場合に、再構成された信号は、原信号と同じでない場合があるが、原信号と再構成された信号との間のひずみは、再構成された信号を、意図された用途にとって有用なものとするほど十分に小さい。ビデオの場合には、不可逆圧縮が広く用いられている。許容されるひずみの量は用途に依存し、例えば、特定の消費者ストリーミング用途のユーザは、テレビジョン配信用途のユーザよりも高いひずみを許容し得る。達成可能な圧縮比は、より高い許容可能な／受け入れ可能なひずみがより高い圧縮比をもたらし得ることを反映することができる。
【0005】
ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化、及びエントロピコーディングを含むいくつかの広いカテゴリからの技術を利用することができる。
【0006】
ビデオコーデック技術は、イントラコーディングとして知られている技術を含むことができる。イントラコーディングでは、サンプル値は、前に再構成された参照ピクチャからのサンプル又は他のデータを参照せずに表現される。いくつかのビデオコーデックでは、ピクチャは、空間的にサンプルのブロックに細分される。サンプルの全てのブロックがイントラモードでコーディングされる場合に、そのピクチャはイントラピクチャであることができる。イントラピクチャ及びそれらの派生物、例えば、独立したデコーダリフレッシュピクチャは、デコーダ状態をリセットするために使用され得るので、コーディングされたビデオビットストリーム及びビデオセッションの最初のピクチャとして、又は静止画像として使用され得る。イントラブロックのサンプルは、変換を受けることができ、変換係数は、エントロピコーディング前に量子化され得る。イントラ予測は、変換前領域でサンプル値を最小限にする技術であることができる。いくつかの場合に、変換後のＤＣ値が小さければ小さいほど、かつ、ＡＣ係数が小さければ小さいほど、エントロピコーディング後にブロックを表すために所与の量子化ステップサイズで必要とされるビットはますます少ない。
【0007】
例えば、ＭＰＥＧ－２世代のコーディング技術から知られているような、従来のイントラコーディングは、イントラ予測を使用しない。しかし、より新しいビデオ圧縮技術は、例えば、データの空間的に隣接しかつデコーディング順序において先行するブロックのエンコーディング／デコーディング中に得られた周囲サンプルデータ及び／又はメタデータから試みる技術を含む。かような技術は、以降「イントラ予測」技術と呼ばれる。少なくともいくつかの場合に、イントラ予測は、再構成中の現在のピクチャからのみ参照データを使用し、参照ピクチャからは使用しない点に留意されたい。
【0008】
多種多様な形態のイントラ予測が存在し得る。かような技術の１つよりも多くが所与のビデオコーディング技術で使用され得る場合に、使用中の技術はイントラ予測モードでコーディングされ得る。特定の場合に、モードは、サブモード及び／又はパラメータを有することができ、それらは、独立してコーディングされ得るか、又はモードコードワードに含まれ得る。所与のモード／サブモード／パラメータ組み合わせのためにどのコードワードを使用すべきは、イントラ予測を通してコーディング効率利得に影響を及ぼし得るので、エントロピコーディング技術が、コードワードをビットストリームに変換するために使用され得る。
【0009】
特定のモードのイントラ予測が、Ｈ．２６４により導入され、Ｈ．２６５で洗練され、Joint Exploration Model（ＪＥＭ）、Versatile Video Coding（ＶＶＣ）、及びBenchmark Set（ＢＭＳ）などのより新しいコーディング技術で更に洗練された。予測子ブロックは、既に利用可能なサンプルに属する隣接サンプル値を用いて形成され得る。隣接サンプルのサンプル値は、方向に応じて予測子ブロック内にコピーされる。使用中の方向の参照は、ビットストリームでコーディングされ得るか、又はそれ自体予測されてもよい。
【0010】
図１Ａを参照すると、右下には、Ｈ．２６５の３３個のとり得る予測子方向（３５個のイントラモードのうちの３３個の角度モードに対応）から知られている９つの予測子方向のサブセットが表されている。矢印が集まる点（１０１）は、予測中のサンプルに相当する。矢印は、サンプルが予測されている方向に相当する。例えば、矢印（１０２）は、サンプル（１０１）が、水平から４５度の角度で右上にある１つ又は複数のサンプルから予測される、ことを示す。同様に、矢印（１０３）は、サンプル（１０１）が、水平から２２．５度の角度でサンプル（１０１）の左下にある１つ又は複数のサンプルから予測される、ことを示す。
【0011】
依然として図１Ａを参照して、左上には、４×４個のサンプル（太破線によって示される。）の正方形ブロック（１０４）が表されている。正方形ブロック（１０４）は１６個のサンプルを含み、各サンプルは、「Ｓ」、Ｙ次元でのその位置（例えば、行インデックス）、及びＸ次元でのその位置（例えば、列インデックス）で標記される。例えば、サンプルＳ２１は、Ｙ次元で（上から）２番目のサンプルかつＸ次元で（左から）１番目のサンプルである。同様に、サンプルＳ４４は、Ｙ及びＸの両方の次元でブロック（１０４）内の４番目のサンプルである。ブロックはサイズが４×４サンプルであるということで、Ｓ４４は右下にある。更には、類似した番号付け方式に従う参照サンプルが示されている。参照サンプルは、ブロック（１０４）に対して、「Ｒ」、そのＹ位置（例えば行インデックス）及びＸ位置（列インデックス）で標記される。Ｈ．２６４及びＨ．２６５の両方で、予測サンプルは、再構成中のブロックに隣接し、従って、負値が使用される必要はない。
【0012】
イントラピクチャ予測は、信号により伝えられた予測方向によって必要に応じて隣接サンプルから参照サンプル値をコピーすることによって、働くことができる。例えば、コーディングされたビデオビットストリームが、このブロックについて、矢印（１０２）と一致する予測方向を示す、すなわち、サンプルが水平から４５度の角度で右上にある１つ以上の予測サンプルから予測される、とのシグナリングを含む、とする。その場合に、サンプルＳ４１、Ｓ３２、Ｓ２３、及びＳ１４は、同じ参照サンプルＲ０５から予測される。それから、サンプルＳ４４は、参照サンプルＲ０８から予測される。
【0013】
特定の場合に、複数の参照サンプルの値は、参照サンプルを計算するために、特に、方向が４５度で等しく分割可能でない場合に、例えば、補間を通じて、組み合わされてよい。
【0014】
とり得る方向の数は、ビデオコーディング技術が発展するとともに増えている。Ｈ．２６４（２００３年）では、９つの異なる方向が表現可能であった。それは、Ｈ．２６５（２０１３年）では３３個にまで増え、そして、ＪＥＭ／ＶＶＣ／ＢＭＳは、本開示の時点で、最大６５個の方向をサポートすることができる。最もありそうな方向を識別するために実験が行われており、エントロピコーディングにおける特定の技術が、可能性が低い方向に対する若干のペナルティを受け入れながら、少数のビットでそれらのありそうな方向を表現するために使用されている。更に、方向それ自体は、時々、隣接する、既にデコーディングされたブロックで使用された隣接方向から予測され得る。
【0015】
図１Ｂは、時間とともに増大する予測方向の数を説明するために、ＪＥＭによる６５個のイントラ予測方向を表す概略図（１８０）を示す。
【0016】
方向を表すコーディングされたビデオビットストリーム内のイントラ予測方向ビットのマッピングは、ビデオコーディング技術ごとに異なる可能性があり、例えば、予測方向の単純な直接マッピングから、イントラ予測モードまで、コードワードまで、最確モードを含む複雑な適応スキーム、及び同様の技術まで及び得る。全ての場合で、しかしながら、特定の他の方向よりも統計的にビデオコンテンツで起こる可能性が低い特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるということで、それらの可能性が低い方向は、上手く働くビデオコーディング技術では、よりありそうな方向よりも多いビット数によって表現されることになる。
【0017】
動き補償は、不可逆圧縮技術であることができ、前に再構成されたピクチャ又はその部分（参照ピクチャ）からのサンプルデータのブロックが、動きベクトル（以降ＭＶ）によって示された方向において空間的にシフトされた後に、新たに再構成されるピクチャ又はピクチャ部分の予測のために使用される技術に関係があり得る。いくつかの場合に、参照ピクチャは、現在再構成中のピクチャと同じであることができる。ＭＶは２つの次元Ｘ及びＹ、又は３つの次元を有することができ、３番目の次元は、使用中の参照ピクチャの指示である（後者は、間接的に、時間次元であることができる。）。
【0018】
いくつかのビデオ圧縮技術では、サンプルデータの特定のエリアに適用可能なＭＶは、他のＭＶから、例えば、再構成中のエリアに空間的に隣接するサンプルデータの他のエリアに関係があり、デコーディング順序においてそのＭＶに先行するものから、予測され得る。そうすることで、ＭＶをコーディングするために必要なデータの量を大幅に減らすことができ、それによって、冗長性を取り除きかつ圧縮を高める。例えば、カメラから得られた入力ビデオ信号（ナチュラルビデオとして知られる。）をコーディングする場合に、単一のＭＶが適用可能であるエリアよりも大きいエリアが同様の方向に移動するという統計的可能性があり、従って、いくつかの場合には、隣接するエリアのＭＶから導出された同様の動きベクトルを用いて予測可能であるということで、ＭＶ予測は有効に働くことができる。その結果、所与のエリアについて求められるＭＶは、周囲のＭＶから予測されたＭＶと類似又は同じであり、エントロピコーディング後に、ＭＶを直接コーディングする場合に使用されることになるビット数よりも少ないビットで表され得る。いくつかの場合に、ＭＶ予測は、原信号（すなわち、サンプルストリーム）から導出された信号（すなわち、ＭＶ）の可逆圧縮の例であることができる。他の場合には、ＭＶ予測それ自体は、例えば、いくつかの周囲のＭＶから予測子を計算するときの丸め誤差のために、不可逆であり得る。
【0019】
様々なＭＶ予測メカニズムがＨ．２６５／ＨＥＶＣ（ＩＴＵ－Ｔ Ｒｅｃ． Ｈ２６５，“High Efficiency Video Coding”，２０１６年１２月）で説明されている。Ｈ．２６５が提案する多くのＭＶ予測メカニズムの中から、本明細書では、以降「空間マージ」と呼ばれる技術が説明される。
【0020】
図２を参照すると、現在のブロック（２０１）は、空間的にシフトされた同じサイズの前のブロックから予測可能であると動き探索プロセス中にエンコーダによって認められたサンプルを有する。そのＭＶを直接にコーディングする代わりに、ＭＶは、１つ以上の参照ピクチャと関連付けられたメタデータから、例えば、（デコーディング順序において）最も最近の参照ピクチャから、Ａ０、Ａ１及びＢ０、Ｂ１、Ｂ２（夫々、２０２から２０６）と表されている５つの周囲サンプルのうちのいずれか１つと関連付けられたＭＶを用いて導出され得る。Ｈ．２６５では、ＭＶ予測は、隣接するブロックが使用している同じ参照ピクチャからの予測子を使用することができる。
【発明の概要】
【0021】
開示の態様は、ビデオエンコーディング／デコーディングのための方法及び装置を提供する。いくつかの例で、ビデオデコーディングのための装置は処理回路を含む。処理回路は、コーディングされたビデオビットストリームからピクチャ内のコーディングブロック（ＣＢ）のコーディングされた情報をデコーディングするよう構成される。コーディングされた情報は、ＣＢのＷ個のサンプルの幅及びＨ個のサンプルの高さを示す。処理回路は、ＣＢを、Ｗ及びＫのうちの最小な一方である幅と、Ｈ及びＫのうちの最小な一方である高さとを有するサブ処理ユニット（ＳＰＵ）に分割することができる。ＣＢの幅Ｗ及び高さＨのうちの少なくとも一方は処理データユニットサイズＫよりも大きい。処理回路は、ＳＰＵの幅及び高さと、Ｍ個のサンプルの最大変換ユニット（ＴＵ）サイズとに基づいて、ＳＰＵを更に分割するためのパーティショニング構造を決定することができる。ＳＰＵの幅及び高さのうちの少なくとも一方はＭよりも大きい。処理回路は、決定されたパーティショニング構造に基づいてＳＰＵの夫々をＭ×ＭのＴＵに分割することができる。
【0022】
実施形態において、ＳＰＵの幅及び高さは、Ｍよりも大きい。処理回路は、パーティショニング構造を四分木パーティショニング構造であると決定することができる。処理回路は、四分木パーティショニング構造に基づいてＳＰＵを記ＴＵに分割することができる。
【0023】
実施形態において、ＳＰＵの幅は、Ｍよりも大きく、ＳＰＵの高さは、Ｍに等しい。処理回路は、パーティショニング構造を垂直二分木パーティショニング構造であると決定することができる。処理回路は、垂直二分木パーティショニング構造に基づいてＳＰＵをＴＵに分割することができる。
【0024】
実施形態において、ＳＰＵの高さ、Ｍよりも大きく、ＳＰＵの幅は、Ｍに等しい。処理回路は、パーティショニング構造を水平二分木パーティショニング構造であると決定することができる。処理回路は、水平二分木パーティショニング構造に基づいてＳＰＵをＴＵに分割することができる。
【0025】
実施形態において、処理回路は、パーティショニング構造に基づいてＳＰＵの中の１つを再帰的にＴＵに分割することができる。
【0026】
実施形態において、処理回路は、第１スキャン順序に従ってＳＰＵを処理し、第２スキャン順序に従ってＳＰＵの夫々におけるＴＵを処理することができる。例において、第１スキャン順序及び第２スキャン順序のうちの少なくとも一方は、（ｉ）ラスタスキャン順序、（ｉｉ）垂直スキャン順序、（ｉｉｉ）ジグザグ順序、及び（ｉｖ）対角スキャン順序、のうちの１つである。例において、第１スキャン順序及び第２スキャン順序は、ラスタスキャン順序である。例において、Ｗは１２８であり、Ｈは６４であり、Ｋは６４であり、Ｍは３２である。第１スキャン順序は、左か右であり、第２スキャン順序は、ラスタスキャン順序である。
【0027】
実施形態において、処理データユニットサイズＫは、仮想パイプラインデータユニット（ＶＰＤＵ）のサイズを示す。ピクチャにおいて、ＳＰＵの中の第１ＳＰＵは第１ＶＰＤＵに含まれ、ＳＰＵの中の第２ＳＰＵは第２ＶＰＤＵに含まれる。多段階パイプラインの第１段階で第１ＶＰＤＵを処理した後、処理回路は、多段階パイプラインの第２段階で第１ＶＰＤＵを、及び第１段階で前記第２ＶＰＤＵを同時に処理することができる。
【0028】
開示されている対象の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
【図面の簡単な説明】
【0029】
【図1A】イントラ予測モードの例示的なサブセットの概略図である。
【図1B】例示的なイントラ予測方向の説明図である。
【図2】一例における現在のブロック及びその周囲の空間マージ候補の概略図である。
【図3】実施形態に従う通信システム（３００）の略ブロック図の概略図である。
【図4】実施形態に従う通信システム（４００）の略ブロック図の概略図である。
【図5】実施形態に従うデコーダの略ブロック図の概略図である。
【図6】実施形態に従うエンコーダの略ブロック図の概略図である。
【図7】他の実施形態に従うエンコーダのブロック図を示す。
【図8】他の実施形態に従うデコーダのブロック図を示す。
【図9A】四分木プラス二分木（ＱＴＢＴ）構造（９１０）により分割されるＣＴＵを示す。
【図9B】ＱＴＢＴ構造（９２０）を示す。
【図9C】水平センター－サイド三分木を示す。
【図9D】垂直センター－サイド三分木を示す。
【図10A】４点ＤＣＴ－２変換の変換コア行列を示す。
【図10B】８点ＤＣＴ－２変換の変換コア行列を示す。
【図10C】１６点ＤＣＴ－２変換の変換コア行列を示す。
【図10D】３２点ＤＣＴ－２変換の変換コア行列を示す。
【図11A】６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【図12】適応多重変換（ＡＭＴ）の選択された離散サイン変換（ＤＳＴ）／離散コサイン変換（ＤＣＴ）変換の変換基本関数を示す。
【図13】ｍｔｓ＿ｉｄｘ値と各々の水平又は垂直変換との間のマッピング関係を表す表（１３００）を示す。
【図14A】４点ＤＳＴ－７変換の変換コア行列を示す。
【図14B】８点ＤＳＴ－７変換の変換コア行列を示す。
【図14C】１６点ＤＳＴ－７変換の変換コア行列を示す。
【図14D】３２点ＤＳＴ－７変換の変換コア行列を示す。
【図15A】４点ＤＣＴ－８変換の変換コア行列を示す。
【図15B】８点ＤＣＴ－８変換の変換コア行列を示す。
【図15C】１６点ＤＣＴ－８変換の変換コア行列を示す。
【図15D】３２点ＤＣＴ－８変換の変換コア行列を示す。
【図16】ブロックサイズに依存したサブパーティションの数を示す。
【図17】イントラサブパーティション（ＩＳＰ）の例を示す。
【図18】ＩＳＰの例を示す。
【図19A】ＩＳＰコーディングモードのためのシンタックス要素（１９００）の例を示す。
【図20A】サブブロック変換（ＳＢＴ）の例を示す。
【図20B】サブブロック変換（ＳＢＴ）の例を示す。
【図20C】サブブロック変換（ＳＢＴ）の例を示す。
【図20D】サブブロック変換（ＳＢＴ）の例を示す。
【図21A】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21B】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21C】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21D】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21E】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21F】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21G】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図21H】ＳＢＴが使用される場合のビデオコーディング規格の仕様テキストの例を示す。
【図22】いくつかの実施形態で使用される種々のＹＵＶフォーマットを示す。
【図23】認められない三分木（ＴＴ）及び二分木（ＢＴ）パーティショニングの例を示す。
【図24】変換ツリーシンタックスの例を示す。
【図25】１２８×６４サンプルのサイズを有するコーディングブロック（２５１０）を示す。
【図26A】１２８×３２サンプルのサイズを有するコーディングブロック（２６１０Ａ）を示す。
【図26B】１２８×３２サンプルのサイズを有するコーディングブロック（２６１０Ｂ）を示す。
【図27】開示の実施形態に従うプロセス（２７００）を説明するフローチャートを示す。
【図28】実施形態に従うコンピュータシステムの概略図である。
【発明を実施するための形態】
【0030】
［Ｉ．ビデオコーディングエンコーダ及びデコーダ］
図３は、本開示の実施形態に従う通信システム（３００）の略ブロック図を表す。通信システム（３００）は、例えば、ネットワーク（３５０）を介して、互いと通信することができる複数の端末デバイスを含む。例えば、通信システム（３００）は、ネットワーク（３５０）を介して相互接続されている端末デバイス（３１０）及び（３２０）の第１対を含む。図３では、端末デバイス（３１０）及び（３２０）の第１対は、データの一方向伝送を実行する。例えば、端末デバイス（３１０）は、ネットワーク（３５０）を介した他の端末デバイス（３２０）への伝送のためにビデオデータ（例えば、端末デバイス（３１０）によって捕捉されるビデオデータのストリーム）をコーディングしてよい。エンコーディングされたビデオデータは、１つ以上のコーディングされたビデオビットストリームの形で伝送可能である。端末デバイス（３２０）は、コーディングされたビデオデータをネットワーク（３５０）から受信し、コーディングされたビデオデータをデコーディングしてビデオピクチャを回復し、回復されたビデオデータに従ってビデオピクチャを表示してよい。一方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。
図３は、本開示の実施形態に従う通信システム（３００）の略ブロック図を表す。通信システム（３００）は、例えば、ネットワーク（３５０）を介して、互いと通信することができる複数の端末デバイスを含む。例えば、通信システム（３００）は、ネットワーク（３５０）を介して相互接続されている端末デバイス（３１０）及び（３２０）の第１対を含む。図３では、端末デバイス（３１０）及び（３２０）の第１対は、データの一方向伝送を実行する。例えば、端末デバイス（３１０）は、ネットワーク（３５０）を介した他の端末デバイス（３２０）への伝送のためにビデオデータ（例えば、端末デバイス（３１０）によって捕捉されるビデオデータのストリーム）をコーディングしてよい。エンコーディングされたビデオデータは、１つ以上のコーディングされたビデオビットストリームの形で伝送可能である。端末デバイス（３２０）は、コーディングされたビデオデータをネットワーク（３５０）から受信し、コーディングされたビデオデータをデコーディングしてビデオピクチャを回復し、回復されたビデオデータに従ってビデオピクチャを表示してよい。一方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。
【0031】
他の例では、通信システム（３００）は、例えば、ビデオ会議中に、現れ得るコーディングされたビデオデータの双方向伝送を実行する端末デバイス（３３０）及び（３４０）の第２対を含む。データの双方向伝送のために、例において、端末デバイス（３３０）及び（３４０）の各端末デバイスは、ネットワーク（３５０）を介した端末デバイス（３３０）及び（３４０）のうちの他方の端末デバイスへの伝送のためにビデオデータ（例えば、その端末デバイスによって捕捉されるビデオピクチャのストリーム）をコーディングしてよい。端末デバイス（３３０）及び（３４０）の各端末デバイスはまた、端末デバイス（３３０）及び（３４０）のうちの他方の端末デバイスによって送信されたコーディングされたビデオデータを受信してよく、コーディングされたビデオデータをデコーディングしてビデオピクチャを回復してよく、回復されたビデオデータに従って、アクセス可能な表示デバイスでビデオピクチャを表示してよい。
【0032】
図３の例では、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）は、サーバ、パーソナルコンピュータ、及びスマートフォンとして表され得るが、本開示の原理はそのように限定され得ない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤー、及び／又は専用のビデオ会議装置により用途を見出す。ネットワーク（３５０）は、例えば、ワイヤライン（有線）及び／又はワイヤレス通信ネットワークを含む、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）の間でコーディングされたビデオデータを伝達する任意数のネットワークに相当する。通信ネットワーク（３５０）は、回路交換及び／又はパケット交換チャネルにおいてデータを交換し得る。代表的なネットワークには、電気通信網、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又はインターネットがある。本議論のために、ネットワーク（３５０）のアーキテクチャ及びトポロジは、以降で説明されない限りは本開示の動作に無関係であり得る。
【0033】
図４は、開示されている対象の応用例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を表す。開示されている対象は、例えば、ビデオ会議と、デジタルＴＶと、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタル媒体上での圧縮されたビデオの記憶と、などを含む他のビデオ対応用途に同様に適用可能であることができる。
【0034】
ストリーミングシステムは、例えば、圧縮されていないビデオピクチャのストリーム（４０２）を生成するビデオソース（４０１）、例えば、デジタルカメラ、を含むことができる捕捉サブシステム（４１３）を含んでよい。例において、ビデオピクチャのストリーム（４０２）は、デジタルカメラによって撮影されるサンプルを含む。ビデオピクチャのストリーム（４０２）は、エンコーディングされたビデオデータ（４０４）（又はコーディングされたビデオビットストリーム）と比較して高いデータボリュームを強調するために太線で表されており、ビデオソース（４０１）へ結合されたビデオエンコーダ（４０３）を含む電子デバイス（４２０）によって処理され得る。ビデオエンコーダ（４０３）は、以下で更に詳細に記載されるように、開示されている対象の態様を可能にする又は実装するためのハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。エンコーディングされたビデオデータ（４０４）（又はエンコーディングされたビデオビットストリーム（４０４））は、ビデオピクチャのストリーム（４０２）と比較してより低いデータボリュームを強調するために細線で表されており、将来の使用のためにストリーミングサーバ（４０５）に記憶され得る。図４のクライアントサブシステム（４０６）及び（４０８）などの１つ以上のストリーミングクライアントサブシステムは、エンコーディングされたビデオデータ（４０４）のコピー（４０７）及び（４０９）を読み出すためにストリーミングサーバ（４０５）にアクセスすることができる。クライアントサブシステム（４０６）は、例えば、電子デバイス（４３０）において、ビデオデコーダ（４１０）を含むことができる。ビデオデコーダ（４１０）は、エンコーディングされたビデオデータの入来するコピー（４０７）をデコーディングし、ディスプレイ（４１２）（例えば、表示スクリーン）又は他のレンダリングデバイス（図示せず。）でレンダリングされ得るビデオピクチャの送出ストリーム（４１１）を生成する。いくつかのストリーミングシステムにおいて、エンコーディングされたビデオデータ（４０４）、（４０７）、及び（４０９）（例えば、ビデオビットストリーム）は、特定のビデオコーディング／圧縮規格に従ってエンコーディングされ得る。そのような規格の例には、ＩＴＵ－Ｔ推奨Ｈ．２６５がある。例において、開発中のビデオコーディング規格は、Versatile Video Coding（ＶＶＣ）として俗に知られている。開示されている対象は、ＶＶＣに関連して使用されてもよい。
【0035】
電子デバイス（４２０）及び（４３０）は、他のコンポーネント（図示せず。）を含むことができることが知られる。例えば、電子デバイス（４２０）は、ビデオデコーダ（図示せず。）を含むことができ、電子デバイス（４３０）は、ビデオエンコーダ（図示せず。）を同様に含むことができる。
【0036】
図５は、本開示の実施形態に従うビデオデコーダ（５１０）のブロック図を示す。ビデオデコーダ（５１０）は、電子デバイス（５３０）に含まれ得る。電子デバイス（５３０）は、受信器（５３１）（例えば、受信回路）を含むことができる。ビデオデコーダ（５１０）は、図４の例のビデオデコーダ（４１０）の代わりに使用され得る。
【0037】
受信器（５３１）は、ビデオデコーダ（５１０）によってデコーディングされるべき１つ以上のコーディングされたビデオシーケンスを、同じ又は他の実施形態では、一度に１つのコーディングされたビデオシーケンスを、受信してよい。ここで、夫々のコーディングされたビデオシーケンスのデコーディングは、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、チャネル（５０１）から受信されてよく、チャネルは、エンコーディングされたビデオデータを記憶している記憶デバイスへのハードウェア／ソフトウェアリンクであってよい。受信器（５３１）は、エンコーディングされたビデオデータを他のデータ、例えば、コーディングされたオーディオデータ及び／又は補助的なデータストリームとともに受信してよく、それらは、それらの各々の使用エンティティ（図示せず。）へ転送されてよい。受信器（５３１）は、コーディングされたビデオシーケンスを他のデータから分離してよい。ネットワークジッタに対抗するために、バッファメモリ（５１５）が受信器（５３１）とエントロピデコーダ／パーサ（５２０）（以降「パーサ（５２０）」）との間に結合されてよい。特定の用途では、バッファメモリ（５１５）は、ビデオデコーダ（５１０）の部分である。他では、それは、ビデオデコーダ（５１０）の外にあることができる（図示せず。）。更に他では、例えば、ネットワークジッタに対抗するための、ビデオデコーダ（５１０）の外にあるバッファメモリ（図示せず。）と、加えて、例えば、再生タイミングを操作するための、ビデオデコーダ（５１０）内のもう１つのバッファメモリ（５１５）とが存在することができる。受信器（５３１）が十分なバンド幅及び可制御性の記憶／転送デバイスから、又はアイソシンクロナス（isosynchronous）ネットワークからデータを受信しているときに、バッファメモリ（５１５）は必要とされなくてもよく、あるいは、小さくてよい。インターネットなどのベストエフォートのパケットネットワークでの使用のために、バッファメモリ（５１５）は必要とされる場合があり、比較的に大きくかつ有利なことには適応サイズであることができ、ビデオデコーダ（５１０）の外のオペレーティングシステム又は同様の要素（図示せず。）に少なくとも部分的に実装され得る。
【0038】
ビデオデコーダ（５１０）は、コーディングされたビデオシーケンスからシンボル（５２１）を再構成するためのパーサ（５２０）を含んでよい。それらのシンボルのカテゴリは、ビデオデコーダ（５１０）の動作を管理するために使用される情報と、潜在的に、電子デバイス（５３０）の必須部分でないが、図５に示されたように、電子デバイス（５３０）へ結合され得るレンダーデバイス（５１２）（例えば、表示スクリーン）などのレンダリングデバイスを制御するための情報とを含む。レンダリングデバイスのための制御情報は、Supplementary Enhancement Information（ＳＥＩ）メッセージ又はVideo Usability Information（ＶＵＩ）パラメータセットフラグメント（図示せず。）の形をとってよい。パーサ（５２０）は、受信されるコーディングされたビデオシーケンスをパース／エントロピデコーディングしてよい。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術又は規格に従うことができ、可変長コーディング、ハフマンコーディング、文脈依存による又はよらない算術コーディング、などを含む様々な原理に従うことができる。パーサ（５２０）は、コーディングされたビデオシーケンスから、ビデオデコーダにおけるピクセルのサブグループのうちの少なくとも１つについてのサブグループパラメータの組を、そのグループに対応する少なくとも１つのパラメータに基づいて抽出し得る。サブグループは、グループ・オブ・ピクチャ（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）、などを含むことができる。パーサ（５２０）はまた、変換係数などのコーディングされたビデオシーケンス情報から、量子化パラメータ値、動きベクトル、なども抽出し得る。
【0039】
パーサ（５２０）は、シンボル（５２１）を生成するために、バッファメモリ（５１５）から受信されたビデオシーケンスに対してエントロピデコーディング／パーシング動作を実行してよい。
【0040】
シンボル（５２１）の再構成は、コーディングされたビデオピクチャ又はその部分（例えば、インター及びイントラピクチャ、インター及びイントラブロック）のタイプ及び他の因子に応じて多種多様なユニットを有することができる。どのユニットがどのように含まれるかは、コーディングされたビデオシーケンスからパーサ（５２０）によってパースされたサブグループ制御情報によって制御され得る。パーサ（５２０）と以下の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明りょうさのために表されていない。
【0041】
既に述べられた機能ブロックを超えて、ビデオデコーダ（５１０）は、概念的に、以下で説明される多数の機能ユニットに細分され得る。商業上の制約の下で動作する実際の実施では、それらのユニットの多くが互いに密に相互作用し、少なくとも部分的に互いに組み込まれ得る。しかし、開示されている対象を説明することを目的として、以下での機能ユニットへの概念的細分は適切である。
【0042】
第１ユニットは、スケーラ／逆変換ユニット（５５１）である。スケーラ／逆変換ユニット（５５１）は、パーサ（５２０）からシンボル（５２１）として、量子化された変換係数とともに、使用するために変換するもの、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報を受信する。スケーラ／逆変換ユニット（５５１）は、アグリゲータ（５５５）へ入力することができるサンプル値を含むブロックを出力することができる。
【0043】
いくつかの場合に、スケーラ／逆変換器（５５１）の出力サンプルは、イントラコーディングされたブロック、すなわち、前に再構成されたピクチャからの予測情報を使用しておらず、現在のピクチャの前に再構成された部分からの予測情報を使用することができるブロック、に関係することができる。かような予測情報は、イントラピクチャ予測ユニット（５５２）によって供給され得る。いくつかの場合に、イントラピクチャ予測ユニット（５５２）は、現在ピクチャバッファ（５５８）からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックと同じサイズ及び形状のブロックを生成する。現在ピクチャバッファ（５５８）は、例えば、部分的に再構成された現在のピクチャ及び／又は完全に再構成された現在のピクチャをバッファリングする。アグリゲータ（５５５）は、いくつかの場合に、サンプルごとに、イントラ予測ユニット（５５２）が生成した予測情報を、スケーラ／逆変換ユニット（５５１）によって供給される出力サンプル情報に加える。
【0044】
他の場合では、スケーラ／逆変換ユニット（５５１）の出力サンプルは、インターコーディングされた、そして潜在的に動き補償されたブロックに関係することができる。かような場合に、動き補償予測ユニット（５５３）は、予測のために使用されるサンプルをフェッチするよう参照ピクチャメモリ（５５７）にアクセスすることができる。ブロックに関係するシンボル（５２１）に従って、フェッチされたサンプルを動き補償した後に、それらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（５５５）によって、スケーラ／逆変換ユニット（５５１）の出力（この場合に、残差サンプル又は残差信号と呼ばれる。）に加えられ得る。動き補償予測ユニット（５５３）が予測サンプルをフェッチする参照ピクチャメモリ（５５７）内のアドレスは、例えば、Ｘ、Ｙ及び参照ピクチャコンポーネントを有することができるシンボル（５２１）の形で動き補償予測ユニット（５５３）が利用することができる動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ（５５７）からフェッチされるサンプル値の補間や、動きベクトル予測メカニズムなどを含むことができる。
【0045】
アグリゲータ（５５５）の出力サンプルは、ループフィルタユニット（５５６）において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタ技術を含むことができる。この技術は、コーディングされたビデオシーケンス（コーディングされたビデオビットストリームとも呼ばれる。）に含まれており、パーサ（５２０）からのシンボル（５２１）としてループフィルタユニット（５５６）に利用可能にされたパラメータによって制御されるが、コーディングされたピクチャ又はコーディングされたビデオシーケンスの（デコーディング順序において）前の部分のデコーディング中に得られたメタ情報にも応答することができ、更には、前に構成されたループフィルタ処理されたサンプル値に応答することができる。
【0046】
ループフィルタユニット（５５６）の出力は、レンダーデバイス（５１２）へ出力され、更には、将来のインターピクチャ予測における使用のために参照ピクチャメモリ（５５７）に記憶され得るサンプルストリームであることができる。
【0047】
特定のコーディングされたピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用され得る。例えば、現在のピクチャに対応するコーディングされたピクチャが完全に再構成され、コーディングされたピクチャが（例えば、パーサ（５２０）によって）参照ピクチャとして識別されると、現在ピクチャバッファ（５５８）は、参照ピクチャメモリ（５５７）の部分になることができ、未使用の現在ピクチャバッファが、後続のコーディングされたピクチャの再構成を開始する前に再割り当てされ得る。
【0048】
ビデオデコーダ（５１０）は、ＩＴＵ－Ｔ推奨Ｈ．２６５などの規格における所定のビデオ圧縮技術に従ってデコーディング動作を実行してよい。コーディングされたビデオシーケンスは、そのコーディングされたビデオシーケンスが、ビデオ圧縮技術又は規格のシンタックス及びビデオ圧縮技術又は規格において文書化されているプロファイルの両方に従うという意味で、使用中のビデオ圧縮技術又は規格によって規定されたシンタックスに従い得る。具体的には、プロファイルは、ビデオ圧縮技術又は規格で利用可能な全てのツールからそのプロファイルの下での使用のために利用可能な最適なツールとして特定のツールを選択することができる。また、コーディングされたビデオシーケンスの複雑さは、ビデオ圧縮技術又は規格のレベルによって定義された境界内にあることが、順守のために必要である。いくつかの場合に、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、メガサンプル／秒で測定される。）、最大参照ピクチャサイズ、などを制限する。レベルによって設定される制限は、いくつかの場合に、Hypothetical Reference Decoder（ＨＲＤ）仕様と、コーディングされたビデオシーケンスにおいて通知されるＨＲＤバッファ管理のためのメタデータとを通じて更に制限され得る。
【0049】
実施形態において、受信器（５３１）は、エンコーディングされたビデオとともに、追加の（冗長な）データを受信してもよい。追加のデータは、コーディングされたビデオシーケンスの部分としても含まれてもよい。追加のデータは、ビデオデコーダ（５１０）によって、データを適切にデコーディングするために及び／又は原ビデオデータをより正確に再構成するために使用されてよい。追加のデータは、例えば、時間、空間、又は信号対雑音比（ＳＮＲ）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正符号、などの形をとることができる。
【0050】
図６は、本開示の実施形態に従うビデオエンコーダ（６０３）のブロック図を示す。ビデオエンコーダ（６０３）は、電子デバイス（６２０）に含まれている。電子デバイス（６２０）は、送信器（６４０）（例えば、送信回路）を含む。ビデオエンコーダ（６０３）は、図４の例のビデオエンコーダ（４０３）の代わりに使用され得る。
【0051】
ビデオエンコーダ（６０３）は、ビデオエンコーダ（６０３）によってコーディングされるべきビデオ画像を捕捉し得るビデオソース（６０１）（図６の例では電子デバイス（６２０）の部分ではない。）からビデオサンプルを受信してよい。他の例では、ビデオソース（６０１）は、電子デバイス（６２０）の部分である。
【0052】
ビデオソース（６０１）は、任意の適切なビットデプス（例えば、８ビット、１０ビット、１２ビットなど）、任意の色空間（例えば、ＢＴ．６０１ ＹＣｒＣＢ、ＲＧＢなど）、及び任意の適切なサンプリング構造（例えば、ＹＣｒＣｂ ４：２：０、ＹＣｒＣｂ ４：４：４）であることができるデジタルビデオサンプルストリームの形で、ビデオエンコーダ（６０３）によってコーディングされるべきソースビデオシーケンスを供給してよい。メディアサービングシステムでは、ビデオソース（６０１）は、前に準備されたビデオを記憶している記憶デバイスであってよい。ビデオ会議システムでは、ビデオソース（６０１）は、ローカル画像情報をビデオシーケンスとして捕捉するカメラであってよい。ビデオデータは、順に見られる場合に動きを授ける複数の個別ピクチャとして供給されてもよい。ピクチャ自体は、ピクセルの空間アレイとして編成されてよく、各ピクセルは、使用中のサンプリング構造、色空間、などに依存する１つ以上のサンプルを有することができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。本明細書は、以下、サンプルに焦点を当てる。
【0053】
実施形態に従って、ビデオエンコーダ（６０３）は、実時間において又は用途によって必要とされる任意の他の時間制約の下で、ソースビデオシーケンスのピクチャを、コーディングされたビデオシーケンス（６４３）へとコーディング及び圧縮してよい。適切なコーディング速度を強いることは、コントローラ（６５０）の一機能である。いくつかの実施形態において、コントローラ（６５０）は、以下で記載されるような他の機能ユニットを制御し、それらのユニットへ機能的に結合される。結合は明りょうさのために表されていない。コントローラ（６５０）によってセットされるパラメータには、レート制御に関連したパラメータ（ピクチャスキップ、量子化器、レートひずみ最適化技術のラムダ値、など）、ピクチャサイズ、グループ・オブ・ピクチャ（ＧＯＰ）レイアウト、最大動きベクトル探索範囲、などが含まれ得る。コントローラ（６５０）は、特定のシステム設計のために最適化されたビデオエンコーダ（６０３）に関係する他の適切な機能を有するよう構成され得る。
【0054】
いくつかの実施形態において、ビデオエンコーダ（６０３）は、コーディングループで動作するよう構成される。過度に単純化された記載として、例において、コーディングループは、ソースコーダ（６３０）（例えば、コーディングされるべき入力ピクチャと、参照ピクチャとに基づいて、シンボルストリームなどのシンボルを生成することに関与する。）と、ビデオエンコーダ（６０３）に埋め込まれた（ローカル）デコーダ（６３３）とを含むことができる。デコーダ（６３３）は、（シンボルとコーディングされたビデオストリームとの間の如何なる圧縮も、開示されている対象で考えられているビデオ圧縮技術において可逆であるということで）（遠隔の）デコーダも生成することになるのと同様の方法でサンプルデータを生成するようにシンボルを再構成する。その再構成されたサンプルストリーム（サンプルデータ）は、参照ピクチャメモリ（６３４）へ入力される。シンボルストリームのデコーディングは、デコーダの場所（ローカル又は遠隔）に依存しないビットパーフェクト（bit-exact）な結果をもたらすので、参照ピクチャメモリ（６３４）内のコンテンツも、ローカルのエンコーダと遠隔のエンコーダとの間でビットパーフェクトである。すなわち、エンコーダの予測部分は、デコーダがデコーディング中に予測を使用するときに“見る”ことになるのとまさに同じサンプル値を参照ピクチャサンプルとして“見る”。参照ピクチャのシンクロニシティ（及び、例えば、チャネルエラーのために、シンクロニシティが維持され得ない場合に、結果として生じるドリフト）のこの基本原理は、いくつかの関連技術でも使用されている。
【0055】
“ローカル”のデコーダ（６３３）の動作は、図５とともに先に詳細に既に説明されている、ビデオデコーダ（５１０）などの“遠隔”のデコーダと同じであることができる。一時的に図５も参照すると、しかしながら、シンボルが利用可能であり、エントロピコーダ（６４５）及びパーサ（５２０）によるコーディングされたビデオシーケンスへのシンボルのエンコーディング／デコーディングが可逆であることができるということで、バッファメモリ（５１５）及びパーサ（５２０）を含むビデオデコーダ（５１０）のエントロピデコーディング部分は、ローカルのデコーダ（６３３）において完全には実装されなくてもよい。
【0056】
この時点で行われ得る観察は、デコーダに存在するパーシング／エントロピデコーディングを除く如何なるデコーダ技術も、対応するエンコーダにおいて、実質的に同じ機能形態で、必ずしも存在する必要がないことである。この理由により、開示されている対象は、デコーダの動作に焦点を当てる。エンコーダ技術の説明は、それらが、包括的に記載されるデコーダ技術の逆であるということで、省略され得る。特定の範囲においてのみ、より詳細な説明が必要とされ、以下で与えられている。
【0057】
動作中、ソースコーダ（６３０）は、動き補償された予測コーディングを実行してよい。これは、「参照ピクチャ」として指定されたビデオシーケンスからの１つ以上の前にコーディングされたピクチャを参照して予測的に入力ピクチャをコーディングする。このようにして、コーディングエンジン（６３２）は、入力ピクチャに対する予測参照として選択され得る参照ピクチャのピクセルブロックと入力ピクチャのピクセルブロックとの間の差をコーディングする。
【0058】
ローカルのビデオデコーダ（６３３）は、ソースコーダ（６３０）によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコーディングされたビデオデータをデコーディングしてよい。コーディングエンジン（６３２）の動作は、有利なことに、不可逆プロセスであってよい。コーディングされたビデオデータがビデオデコーダ（図６には図示せず。）でデコーディングされ得るとき、再構成されたビデオシーケンスは、通常は、いくらかのエラーを伴ったソースビデオシーケンスの複製であり得る。ローカルのビデオデコーダ（６３３）は、参照ピクチャに対してビデオデコーダによって実行され得るデコーディングプロセスを再現し、再構成された参照ピクチャを参照ピクチャキャッシュ（６３４）に格納されるようにしてよい。このように、ビデオエンコーダ（６０３）は、（伝送エラーなしで）遠端のビデオデコーダによって取得されることになる再構成された参照ピクチャと共通の内容を有している再構成された参照ピクチャのコピーをローカルで記憶し得る。
【0059】
予測器（６３５）は、コーディングエンジン（６３２）のための予測探索を実行してよい。すなわち、新しいピクチャがコーディングされるために、予測器（６３５）は、その新しいピクチャのための適切な予測基準となり得る参照ピクチャ動きベクトル、ブロック形状、などの特定のメタデータ又は（候補参照ピクセルブロックとしての）サンプルデータを参照ピクチャメモリ（６３４）から探してよい。予測器（６３５）は、適切な予測基準を見つけるためにサンプルブロック・バイ・ピクセルブロックベース（sample block-by-pixel block basis）で動作してよい。いくつかの場合に、予測器（６３５）によって取得された探索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（６３４）に記憶されている複数の参照ピクチャから引き出された予測基準を有してよい。
【0060】
コントローラ（６５０）は、例えば、ビデオデータをエンコーディングするために使用されるパラメータ及びサブグループパラメータの設定を含め、ソースコーダ（６３０）のコーディング動作を管理してよい。
【0061】
上記の全ての機能ユニットの出力は、エントロピコーダ（６４５）においてエントロピコーディングを受けてよい。エントロピコーダ（６４５）は、ハフマンコーディング、可変長コーディング、算術コーディングなどの技術に従ってシンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを、コーディングされたビデオシーケンスへと変換する。
【0062】
送信器（６４０）は、エントロピコーダ（６４５）によって生成されたコーディングされたビデオシーケンスを、通信チャネル（６６０）を介した伝送のために準備するようにバッファリングしてよい。通信チャネル（６６０）は、エンコーディングされたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアリンクであってよい。送信器（６４０）は、ビデオコーダ（６０３）からのコーディングされたビデオデータを、送信されるべき他のデータ、例えば、コーディングされたオーディオデータ及び／又は補助的なデータストリーム（ソースは図示せず）とマージしてもよい。
【0063】
コントローラ（６５０）は、ビデオエンコーダ（６０３）の動作を管理してよい。コーディング中、コントローラ（６５０）は、各々のピクチャに適用され得るコーディング技術に影響を及ぼす可能性がある特定のコーディングされたピクチャタイプを夫々のコーディングされたピクチャに割り当ててよい。例えば、ピクチャはしばしば、次のピクチャタイプのうちの１つとして割り当てられてよい。
【0064】
イントラピクチャ（Intra Picture）（Ｉピクチャ）は、予測のソースとしてシーケンス内の如何なる他のピクチャも使用せずにコーディング及びデコーディングされ得るピクチャであってよい。いくつかのビデオコーデックは、例えば、独立したデコーダリフレッシュ（Independent Decoder Refresh，ＩＤＲ）ピクチャを含む種々のタイプのイントラピクチャを許容する。当業者であれば、Ｉピクチャのそのような変形並びにそれらの各々の応用及び特徴に気づく。
【0065】
予測ピクチャ（Predictive Picture）（Ｐピクチャ）は、各ブロックのサンプル値を予測するために多くても１つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測によりコーディング及びデコーディングされ得るピクチャであってよい。
【0066】
双方向予測ピクチャ（Bi-directionally Predictive Picture）（Ｂピクチャ）は、各ブロックのサンプル値を予測するために多くても２つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測によりコーディング及びデコーディングされ得るピクチャであってよい。同様に、多重予測ピクチャ（multiple-predictive picture(s)）は、単一のブロックの再構成のために２つよりも多い参照ピクチャ及び関連するメタデータを使用することができる。
【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】
ＰＵ分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後、ＣＵは、他の四分木構造に従って変換ユニット（ＴＵ）に分割され得る。明らかなように、ＣＵ、ＰＵ及びＴＵを含む多数のパーティション概念が存在する。いくつかの実施形態では、ＣＵ又はＴＵは正方形形状であることしかできず、一方、ＰＵは正方形又は長方形形状であってよい。いくつかの実施形態では、１つのコーディングブロックは、４つの正方形サブブロックに更に分割されてよく、変換は、各ブロック、すなわち、ＴＵに対して実行される。各ＴＵは、残差四分木（Residual Quad-Tree）（ＲＱＴ）と呼ばれる四分木構造を用いて、より小さいＴｕｓに再帰的に更に分割され得る。
【0092】
ピクチャ境界で、いくつかの実施形態では、暗黙的な四分木分割が用いられ得、それにより、ブロックは、サイズがピクチャ境界に合うまで四分木分割し続けることになる。
【0093】
［２．四分木プラス二分木（ＱＴＢＴ）ブロックパーティショニング構造］
いくつかの実施形態では、四分木プラス二分木（Quad-Tree plus Binary Tree）（ＱＴＢＴ）構造が用いられる。ＱＴＢＴ構造は、複数のパーティションタイプの概念（ＣＴ、ＰＵ、及びＴＵ概念）を取り払い、ＣＵパーティション形状のための更なる柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは正方形又は長方形のどちらかの形状を有することができる。
いくつかの実施形態では、四分木プラス二分木（Quad-Tree plus Binary Tree）（ＱＴＢＴ）構造が用いられる。ＱＴＢＴ構造は、複数のパーティションタイプの概念（ＣＴ、ＰＵ、及びＴＵ概念）を取り払い、ＣＵパーティション形状のための更なる柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは正方形又は長方形のどちらかの形状を有することができる。
【0094】
図９Ａは、図９Ｂに示されるＱＴＢＴ構造（９２０）を使用することによって分割されるＣＴＵ（９１０）を示す。ＣＴＵ（９１０）は、最初に、四分木構造によって分割される。四分木リーフノードは、二分木構造又は四分木構造によって更に分割される。二分木分割には、対称水平分割及び対称垂直分割の２つの分割タイプがある。二分木リーフノードはＣＵと呼ばれ、これは、これ以上のパーティショニングなしで予測及び変換処理のために使用され得る。従って、ＣＵ、ＰＵ、及びＴＵは、ＱＴＢＴコーディングブロック構造では同じブロックサイズを有している。
【0095】
いくつかの実施形態では、ＣＵは、異なる色成分のコーディングブロック（ＣＢ）を含むことができる。例えば、１つのＣＵは、４：２：０クロマフォーマットのＰ及びＢスライスの場合に、１つのルーマＣＢと、２つのクロマＣＢとを含む。ＣＵは、単一の色成分のＣＢを含むことができる。例えば、１つのＣＵは、Ｉスライスの場合に、ただ１つのルーマＣＢ、又はたった２つのクロマＣＢを含む。
【0096】
次のパラメータが、いくつかの実施形態でＱＴＢＴパーティショニングスキームのために定義される：
・ＣＴＵｓｉｚｅ：四分木の根ノードサイズ、例えば、ＨＥＶＣで見られるのと同じ概念。
・ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ。
・ＭａｘＢＴＳｉｚｅ：最大許容二分木根ノードサイズ。
・ＭａｘＢＴＤｅｐｔｈ：最大許容二分木デプス。
・ＭｉｎＢＴＳｉｚｅ：最小許容二分木リーフノードサイズ。
・ＣＴＵｓｉｚｅ：四分木の根ノードサイズ、例えば、ＨＥＶＣで見られるのと同じ概念。
・ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ。
・ＭａｘＢＴＳｉｚｅ：最大許容二分木根ノードサイズ。
・ＭａｘＢＴＤｅｐｔｈ：最大許容二分木デプス。
・ＭｉｎＢＴＳｉｚｅ：最小許容二分木リーフノードサイズ。
【0097】
ＱＴＢＴパーティショニング構造の一例では、ＣＴＵｓｉｚｅは、クロマサンプルの２つの対応する６４×６４ブロックとともに１２８×１２８ルーマサンプルとしてセットされ、ＭｉｎＱＴＳｉｚｅは１６×１６としてセットされ。ＭａｘＢＴＳｉｚｅは６４×６４としてセットされ、ＭｉｎＢＴＳｉｚｅ（幅及び高さの両方について）は４×４としてセットされ、ＭａｘＢＴＤｅｐｔｈは４としてセットされる。四分木パーティショニングが、四分木リーフノードを生成するよう最初にＣＴＵに適用される。四分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵｓｉｚｅ）までのサイズを有する可能性がある。四分木リーフノードが１２８×１２８である場合に、サイズがＭａｘＢＴＳｉｚｅ（すなわち、６４×６４）を越えるので、それは更に二分木によって分割されることはない。そうでない場合には、四分木リーフノードは二分木によって更に分割され得る。従って、四分木リーフノードは、二分木のための根ノードでもあり、それは二分木デプスを０として有している。
【0098】
二分木デプスがＭａｘＢＴＳｉｚｅ（すなわち、４）に達すると、これ以上の分割は考えられない。二分木ノードがＭｉｎＢＴＳｉｚｅに等しい幅（すなわち、４）を有している場合には、これ以上の水平分割は考えられない。同様に、二分木ノードがＭｉｎＢＴＳｉｚｅに等しい高さを有している場合には、これ以上の垂直分割は考えられない。二分木のリーフノードは、これ以上の分割なしで予測及び変換処理によって更に処理される。実施形態において、最大ＣＴＵサイズは２５６×２５６ルーマサンプルである。
【0099】
図９Ａ及び９Ｂにおいて、実線は四分木分割を示し、破線は二分木分割を示す。二分木の各分割（すなわち、非リーフ）ノードでは、どの分割タイプ（すなわち、水平又は垂直）が使用されるかを示すために、１つのフラグが通知される。例えば、０は水平分割を示し、１は垂直分割を示す。四分木分割については、四分木分割が、等しいサイズの４つのサブブロックを生成するよう常に水平及び垂直の両方でブロックを分割するので、分割タイプを示す必要がない。
【0100】
いくつかの実施形態では、ＱＴＢＴスキームは、別個のＱＴＢＴ構造を有するようルーマ及びクロマに対する柔軟性をサポートする。例えば、Ｐ及びＢスライスについては、１つのＣＴＵ内のルーマ及びクロマブロックは、同じＱＴＢＴ構造を共有する。しかし、Ｉスライスについては、ルーマＣＴＢは、ＱＴＢＴ構造によってＣＵに分割され、クロマブロックは、他のＱＴＢＴ構造によってクロマＣＵに分割される。よって、ＩスライスにおけるＣＵは、ルーマ成分のコーディングブロック又は２つのクロマ成分のコーディングブロックから成り、Ｐ又はＢスライスにおけるＣＵは、３つ全ての色成分のコーディングブロックから成る。
【0101】
いくつかの実施形態では、小さいブロックに対するインター予測は、動き補償のメモリアクセスを低減するよう制限される。例えば、双予測は、４×８及び８×４ブロックに対してサポートされず、インター予測は、４×４ブロックに対してサポートされない。
【0102】
［３．三分木（ＴＴ）ブロックパーティショニング構造］
いくつかの実施形態では、マルチタイプツリー（Multi-Type-Tree）（ＭＴＴ）構造が、ピクチャを分割するために使用される。ＭＴＴ構造は、ＱＴＢＴ構造よりも柔軟な木構造である。ＭＴＴでは、四分木及び二分木に加えて、図９Ｃ及び図９Ｄに夫々示される水平センター－サイド三分木及び垂直センター－サイド三分木が用いられる。三分木分割は、四分木及び二分木パーティショニングを補完することができる。例えば、三分木分割は、ブロック中心に位置している対象を捕捉することができるが、四分木及び二分木は、ブロック中心を横断して分割することができる。三分木によるパーティションの幅及び高さは、２の累乗であり、それにより、追加の変換パーティションは不要である。
いくつかの実施形態では、マルチタイプツリー（Multi-Type-Tree）（ＭＴＴ）構造が、ピクチャを分割するために使用される。ＭＴＴ構造は、ＱＴＢＴ構造よりも柔軟な木構造である。ＭＴＴでは、四分木及び二分木に加えて、図９Ｃ及び図９Ｄに夫々示される水平センター－サイド三分木及び垂直センター－サイド三分木が用いられる。三分木分割は、四分木及び二分木パーティショニングを補完することができる。例えば、三分木分割は、ブロック中心に位置している対象を捕捉することができるが、四分木及び二分木は、ブロック中心を横断して分割することができる。三分木によるパーティションの幅及び高さは、２の累乗であり、それにより、追加の変換パーティションは不要である。
【0103】
例において、２段階ツリーの設計は、主に複雑性の低減が動機となる。例えば、ツリーの横断の複雑さはＴＤであり、ここで、Ｔは分割タイプの数を表し、Ｄはツリーの深さである。
【0104】
［４．一次変換の例］
いくつかの実施形態では、例えば、ＨＥＶＣで見られるように、４点（4-point）、８点（8-point）、１６点（16-point）、及び３２点（32-point）ＤＣＴ－２変換が一次変換（primary transforms）として使用される。図１０Ａ～１０Ｄは夫々、４点、８点、１６点、及び３２点ＤＣＴ－２の変換コア行列を示す。それらの変換コア行列の要素は、８ビット整数を用いて表現可能であり、よって、それらの変換コア行列は、８ビット変換コアと呼ばれる。示されるように、より小さいＤＣＴ－２の変換コア行列は、より大きいＤＣＴ－２のそれの部分である。
いくつかの実施形態では、例えば、ＨＥＶＣで見られるように、４点（4-point）、８点（8-point）、１６点（16-point）、及び３２点（32-point）ＤＣＴ－２変換が一次変換（primary transforms）として使用される。図１０Ａ～１０Ｄは夫々、４点、８点、１６点、及び３２点ＤＣＴ－２の変換コア行列を示す。それらの変換コア行列の要素は、８ビット整数を用いて表現可能であり、よって、それらの変換コア行列は、８ビット変換コアと呼ばれる。示されるように、より小さいＤＣＴ－２の変換コア行列は、より大きいＤＣＴ－２のそれの部分である。
【0105】
ＤＣＴ－２コア行列は、対称性／反対称性特徴を示す。従って、いわゆる「部分バタフライ」（partial butterfly）実施が、演算カウント（乗算、加算／減算、シフト）の数を減らすようサポートされ得る。行列乗算の同じ結果が、部分バタフライ実施を用いて求められ得る。
【0106】
［５．更なる一次変換の例］
いくつかの実施形態では、上記の４点、８点、１６点、及び３２点ＤＣＴ－２変換に加えて、更なる２点及び６４点ＤＣＴ－２変換が使用される。図１１Ａ～１１Ｅは、６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
いくつかの実施形態では、上記の４点、８点、１６点、及び３２点ＤＣＴ－２変換に加えて、更なる２点及び６４点ＤＣＴ－２変換が使用される。図１１Ａ～１１Ｅは、６４点ＤＣＴ－２変換の６４×６４変換コア行列を示す。
【0107】
いくつかの実施形態では、ＤＣＴ－２及び４×４ＤＳＴ－７変換に加えて、適応多重変換（Adaptive Multiple Transform）（ＡＭＴ）（エンハンスド多重変換（Enhanced Multiple Transform）（ＥＭＴ）又は多重変換選択（multiple Transform Selection）（ＭＴＳ）としても知られる。）が、インター及びインターコーディングされたブロックの両方の残差コーディングのために使用される。ＡＭＴは、ＤＣＴ－２変換に加えて離散コサイン変換（ＤＣＴ）／離散サイン変換（ＤＳＴ）ファミリーからの複数の選択された変換、例えば、ＤＳ－７又はＤＣＴ－８変換の変換コア行列を使用する。図１２は、選択されたＤＳＴ／ＤＣＴ変換の変換基本関数を示す。
【0108】
いくつかの実施形態では、ＡＭＴで使用されるＤＳＴ／ＤＣＴ変換コア行列は、８ビット表現で表される。いくつかの実施形態では、ＡＭＴは、幅及び高さの両方が３２以下であるＣＵに適用される。ＡＭＴを適用すべきか否かは、フラグ（例えば、ｍｔｓ＿ｆｌａｇ）によって制御され得る。例えば、ｍｔｓ＿ｆｌａｇが０に等しいときには、ＤＣＴ－２しか、残差ブロックをコーディングするために適用されない。ｍｔｓ＿ｆｌａｇが１に等しいときには、インデックス（例えば、ｍｔｓ＿ｉｄｘ）が、使用されるべき水平及び垂直変換を指定するよう２つのビンを用いて更に通知され得る。
【0109】
図１３は、インデックス（例えば、ｍｔｓ＿ｉｄｘ）の値と各々の水平又は垂直変換との間のマッピング関係を表す表（１３００）を示す。ｍｔｓ＿ｉｄｘの値が－１である行（１３０１）は、フラグ（例えば、ｍｔｓ＿ｆｌａｇ）が０に等しいシナリオに対応し、ＤＣＴ－２変換が使用される。ｍｔｓ＿ｉｄｘの値が０、１、２又は３である行（１３０２）～（１３０５）は、ｍｔｓ＿ｆｌａｇが１に等しいシナリオに対応する。表（１３００）の右２つの列では、０は、ＤＣＴ－２の変換タイプを表し、１は、ＤＳＴ－７の変換タイプを表し、２は、ＤＣＴ－８の変換タイプを表す。
【0110】
【0111】
［６．イントラサブパーティション（ＩＳＰ）コーディングモード］
いくつかの実施形態では、イントラサブパーティション（Intra Sub-Partition）（ＩＳＰ）コーディングモードが用いられる。ＩＳＰコーディングモードにおいて、ルーマイントラ予測ブロックは、垂直又は水平に２つ又は４つのサブパーティションに分割され得る。サブパーティションの数は、ブロックのサイズに依存し得る。図１６は、ブロックサイズに依存したサブパーティションの数を示す。図１７は、４×８又は８×４のブロックが２つのサブパーティションに分割される例を示す。図１８は、４×８又は８×４よりも大きいサイズを有するブロックが４つのサブパーティションに分割される例を示す。例において、全てのサブパーティションは、少なくとも１６個のサンプルを有しているという条件を満たす。例において、ＩＳＰは、クロマ成分に適用されない。
いくつかの実施形態では、イントラサブパーティション（Intra Sub-Partition）（ＩＳＰ）コーディングモードが用いられる。ＩＳＰコーディングモードにおいて、ルーマイントラ予測ブロックは、垂直又は水平に２つ又は４つのサブパーティションに分割され得る。サブパーティションの数は、ブロックのサイズに依存し得る。図１６は、ブロックサイズに依存したサブパーティションの数を示す。図１７は、４×８又は８×４のブロックが２つのサブパーティションに分割される例を示す。図１８は、４×８又は８×４よりも大きいサイズを有するブロックが４つのサブパーティションに分割される例を示す。例において、全てのサブパーティションは、少なくとも１６個のサンプルを有しているという条件を満たす。例において、ＩＳＰは、クロマ成分に適用されない。
【0112】
例において、コーディングブロックから分割されサブパーティションの夫々について、エンコーダから送られた各々の係数をエントロピデコーディングし、次いでそれらを逆量子化及び逆変換することによって、残差信号が生成される。次いで、サブパーティションの中の第１サブパーティションが、予測信号を生成するようイントラ予測される。予測信号は、対応する再構成されたサンプルを得るよう第１サブパーティションの各自の残差信号に加えられる。その後に、第１サブパーティションの再構成されたサンプル値は、サブパーティションの中の第２サブパーティションの予測を生成するために利用可能である。このプロセスは、コーディングブロックからの全てのサブパーティションが再構成されるまで、サブパーティション単位で繰り返され得る。例において、全てのサブパーティションは同じイントラモードを共有する。
【0113】
実施形態において、ＩＳＰコーディングモードは、最確モード（Most Probable Mode）（ＭＰＭ）リストの部分であるイントラモードによってのみ試験される。従って、ブロックがＩＳＰを使用する場合に、ＭＰＭフラグは１であると推測され得る。その上、ＩＳＰが特定のブロックに使用されるとき、次いで、各々のＭＰＭリストは、ＤＣモードを除き、ＩＳＰ水平分割のためには水平イントラモードを、及びＩＳＰ垂直分割のためには垂直イントラモードを優先するために、変更されることになる。
【0114】
ＩＳＰコーディングモードでは、変換及び再構成がサブパーティションごとに個別に実行されるので、各サブパーティションはＴＵと見なされ得る。
【0115】
図１９Ａ～１９Ｂは、ＩＳＰコーディングモードのために通知されるシンタックス要素（１９００）の例を示す。枠（１９１０）内に示されるように、シンタックス要素、例えば、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇは、ＩＳＰが使用されるか否かを示す。シンタックス要素、例えば、ｉｎｔｒａ＿ｓａｂｕｐａｒｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇは、パーティション方向（垂直又は水平）を示す。
【0116】
［７．サブブロック変換（ＳＢＴ）］
いくつかの実施形態では、空間的に変化する変換（Spatially Varying Transform）（ＳＶＴ）とも呼ばれるサブブロック変換（Sub-Block Transform）（ＳＢＴ）が用いられる。ＳＢＴは、インター予測残差に適用され得る。いくつかの例では、残差ブロックは、コーディングブロックに含まれ、コーディングブロックよりも小さい。よって、ＳＢＴでの変換サイズは、コーディングブロックサイズよりも小さい。残差ブロックによってカバーされない領域については、ゼロ残差が仮定され得、よって、変換処理は実行されない。
いくつかの実施形態では、空間的に変化する変換（Spatially Varying Transform）（ＳＶＴ）とも呼ばれるサブブロック変換（Sub-Block Transform）（ＳＢＴ）が用いられる。ＳＢＴは、インター予測残差に適用され得る。いくつかの例では、残差ブロックは、コーディングブロックに含まれ、コーディングブロックよりも小さい。よって、ＳＢＴでの変換サイズは、コーディングブロックサイズよりも小さい。残差ブロックによってカバーされない領域については、ゼロ残差が仮定され得、よって、変換処理は実行されない。
【0117】
図２０Ａ～２０Ｄは、ＳＢＴでサポートされるサブブロックタイプ（ＳＶＴ－Ｈ、ＳＶＴ－Ｖ）（例えば、水平又は垂直分割）、サイズ及びパーティション（例えば、左半分、左４分の１、右半分、右４分の１、上半分、上４分の１、下半分、下４分の１）を示す。文字「Ａ」によって表記されている影付き領域は、変換ありの残差ブロックであり、残りの領域は、変換なしのゼロ残差であると仮定される。
【0118】
例として、図２１Ａ～２１Ｉは、ＳＢＴが使用される場合のビデオコーディング規格（例えば、ＶＶＣ）の仕様テキストに対する変更を示す。追加されたテキストは、（２１０１）から（２１１３）までの枠内に示されている。示されるように、追加のシンタックス要素、例えば、追加のオーバーヘッドビットｃｕ＿ｓｂｔ＿ｆｌａｇ、ｃｕ＿ｓｂｔ＿ｑｕａｄ＿ｆｌａｇ、ｃｕ＿ｓｂｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｆｌａｇ、及びｃｕ＿ｓｂｔ＿ｐｏｓ＿ｆｌａｇは、サブブロックタイプ（水平又は垂直）、サイズ（半分又は４分の１）、及び位置（左、右、上又は下）を夫々示すよう通知され得る。
【0119】
［８．ＹＵＶフォーマット］
図２２は、いくつかの実施形態で使用される種々のＹＵＶフォーマット（例えば、４：４：４、４：２：２、４：１：１、及び４：２：０）を示す。例において、交差成分線形モデルイントラ予測が４：２：０フォーマットに対して使用される。６タップ補間フィルタは、図２２に示されるように、クロマサンプルに対応するダウンサンプリングされたルーマサンプルに適用され得る。例において、ダウンサンプリングされたルーマサンプルＲｅｃ’Ｌ［ｘ，ｙ］は、次のように、すぐ近くの再構成されたルーマサンプル（ＲｅｃＬ［ｘ，ｙ］によって表される。）から計算され得る：
ダウンサンプリングされたルーマサンプルＲｅｃ’Ｌ［ｘ，ｙ］は、公差成分線形モデルモードを用いてクロマサンプルを予測するために使用され得る。
図２２は、いくつかの実施形態で使用される種々のＹＵＶフォーマット（例えば、４：４：４、４：２：２、４：１：１、及び４：２：０）を示す。例において、交差成分線形モデルイントラ予測が４：２：０フォーマットに対して使用される。６タップ補間フィルタは、図２２に示されるように、クロマサンプルに対応するダウンサンプリングされたルーマサンプルに適用され得る。例において、ダウンサンプリングされたルーマサンプルＲｅｃ’Ｌ［ｘ，ｙ］は、次のように、すぐ近くの再構成されたルーマサンプル（ＲｅｃＬ［ｘ，ｙ］によって表される。）から計算され得る：
【数1】
【0120】
［９．仮想パイプラインデータユニット（ＶＰＤＵ）］
仮想パイプラインデータユニット（Virtual Pipeline Data Units）（ＶＰＤＵ）は、ピクチャ内の重なり合わないＭ×Ｍ－ルーマ（Ｌ）／Ｎ×Ｎ－クロマ（Ｃ）ユニットとして定義され得る。いくつかのハードウェアデコーダ実施では、連続したＶＰＤＵが複数のパイプライン段によって同時に処理される。異なる段は異なるＶＰＤＵを同時に処理する。ＶＰＤＵサイズは、パイプライン段におけるバッファサイズにおおよそ比例することができ、それにより、ＶＰＤＵを特定のサイズ（例えば、６４×６４以下）に保つことが望ましい。特定のデコーダでは、ＶＰＤＵサイズは最大変換ユニット（ＴＵ）サイズにセットされる。最大ＴＵサイズをＨＥＶＣでの３２×３２－Ｌ／１６×１６－Ｃから現在のＶＶＣでの６４×６４－Ｌ／３２×３２－Ｃまで広げることは、コーディングゲインをもたらすことができ、これは、ＨＥＶＣと比較してＶＰＤＵサイズを４倍にすると期待される。しかし、更なるコーディングゲインを達成するためにＶＶＣで採用されているＢＴ及びＴＴ構造は、再帰的に１２８×１２８－Ｌ／６４×６４－Ｃコーディングツリーブロックに適用可能であり、ＨＥＶＣと比較して１６倍のＶＰＤＵサイズ（１２８×１２８－Ｌ／６４×６４－Ｃ）をもたらす。
仮想パイプラインデータユニット（Virtual Pipeline Data Units）（ＶＰＤＵ）は、ピクチャ内の重なり合わないＭ×Ｍ－ルーマ（Ｌ）／Ｎ×Ｎ－クロマ（Ｃ）ユニットとして定義され得る。いくつかのハードウェアデコーダ実施では、連続したＶＰＤＵが複数のパイプライン段によって同時に処理される。異なる段は異なるＶＰＤＵを同時に処理する。ＶＰＤＵサイズは、パイプライン段におけるバッファサイズにおおよそ比例することができ、それにより、ＶＰＤＵを特定のサイズ（例えば、６４×６４以下）に保つことが望ましい。特定のデコーダでは、ＶＰＤＵサイズは最大変換ユニット（ＴＵ）サイズにセットされる。最大ＴＵサイズをＨＥＶＣでの３２×３２－Ｌ／１６×１６－Ｃから現在のＶＶＣでの６４×６４－Ｌ／３２×３２－Ｃまで広げることは、コーディングゲインをもたらすことができ、これは、ＨＥＶＣと比較してＶＰＤＵサイズを４倍にすると期待される。しかし、更なるコーディングゲインを達成するためにＶＶＣで採用されているＢＴ及びＴＴ構造は、再帰的に１２８×１２８－Ｌ／６４×６４－Ｃコーディングツリーブロックに適用可能であり、ＨＥＶＣと比較して１６倍のＶＰＤＵサイズ（１２８×１２８－Ｌ／６４×６４－Ｃ）をもたらす。
【0121】
図２３は、認められない特定のＴＴ及びＢＴパーティショニングを示す。
【0122】
ＶＰＤＵサイズを６４×６４ルーマサンプルに保つために、特定のパーティション制限（シンタックスシグナリング変更を伴う。）がいくつかの実施形態では適用される：
・ＴＴ分割は、幅若しくは高さのどちらか一方、又は幅及び高さの両方が１２８に等しいＣＵに対して許可されない。
・Ｎ≦６４として、１２８×ＮのＣＵ（幅が１２８に等しく、高さが１２８よりも小さい。）については、水平ＢＴは許可されない。
・Ｎ≦６４として、Ｎ×１２８のＣＵ（高さが１２８に等しく、幅が１２８よりも小さい。）については、垂直ＢＴは許可されない。
・ＴＴ分割は、幅若しくは高さのどちらか一方、又は幅及び高さの両方が１２８に等しいＣＵに対して許可されない。
・Ｎ≦６４として、１２８×ＮのＣＵ（幅が１２８に等しく、高さが１２８よりも小さい。）については、水平ＢＴは許可されない。
・Ｎ≦６４として、Ｎ×１２８のＣＵ（高さが１２８に等しく、幅が１２８よりも小さい。）については、垂直ＢＴは許可されない。
【0123】
［ＩＩＩ．変換ブロックパーティショニング及び処理技術］
いくつかの実施形態では、固定の最大許容変換ユニット（ＴＵ）サイズ又は最大ＴＵサイズ（例えば、６４×６４ピクセル又はサンプル）が使用される。いくつかの実施形態では、最大ＴＵサイズが、例えば、エンコーダ実施について、ハードウェア複雑性（例えば、パイプライン中間バッファサイズ、乗算器の数、など）に影響を及ぼす可能性があるので、制御可能な又は設定可能な最大ＴＵサイズが用いられる。例えば、６４×６４サンプルのサイズに加えて、最大ＴＵサイズは、３２×３２サンプル、１６×１６サンプル、などのような他のサイズであることができる。
いくつかの実施形態では、固定の最大許容変換ユニット（ＴＵ）サイズ又は最大ＴＵサイズ（例えば、６４×６４ピクセル又はサンプル）が使用される。いくつかの実施形態では、最大ＴＵサイズが、例えば、エンコーダ実施について、ハードウェア複雑性（例えば、パイプライン中間バッファサイズ、乗算器の数、など）に影響を及ぼす可能性があるので、制御可能な又は設定可能な最大ＴＵサイズが用いられる。例えば、６４×６４サンプルのサイズに加えて、最大ＴＵサイズは、３２×３２サンプル、１６×１６サンプル、などのような他のサイズであることができる。
【0124】
特定のビデオ規格では、ＳＢＴ及びＩＳＰが使用され得る。例えば、ＳＢＴでは、最大ＳＢＴサイズが３２長さ又は６４長さであるかどうかを示すために、ＳＰＳフラグ、例えば、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが通知される。ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが真であり（すなわち、最大ＳＢＴサイズが６４長さである。）、最大ＴＵサイズが３２点であるとき、エンコーダクラッシュがトリガされ得る。一般に、Ｌ長さ（L-length）又はＬ点（L-point）は、ＣＵ、ＴＵ、ＣＢ、ＴＢ、ＶＰＤＵ、などの最大寸法を指す。例えば、最大ＴＵサイズが３２点又は３２長さであるとき、ＴＵの幅及び高さは３２以下である。
【0125】
いくつかの実施形態では、ＩＳＰモードは様々なＣＵサイズに対して許可されるが、最大ＴＵサイズが６４よりも小さくセットされる場合に、暗黙的な変換分割が実行されるのか、それとも、シグナリングによるＩＳＰを使用した明示的な変換分割が実行されるのかという衝突が起こり得る。例えば、最大ＴＵサイズが１６であるとき、例えば、６４×１６ＣＵについては、ＩＳＰによらないと、ＣＵは、４つの１６×１６ＴＵに暗黙的に分割され得る。ＩＳＰによれば、６４×１６ＣＵは垂直ＩＳＰにより分割されてよく、よって、４つの１６×１６ＴＵに分割され得るが、シグナリングを使用する。
【0126】
最大ＴＵが６４×６４よりも小さいとき、ＴＵ処理順序は、ＶＰＤＵの実施と整列することを必要とされる。
【0127】
本明細書で説明される実施形態は、別々に使用されても、又は如何なる順序でも組み合わされてもよい。更に、実施形態は、処理回路（例えば、１つ以上のプロセッサ又は１つ以上の集積回路）によって、エンコーダやデコーダなどで実装されてよい。一例では、１つ以上のプロセッサは、非一時的なコンピュータ可読媒体に記憶されているプログラムを実行する。
【0128】
本開示では、ハイレベルシンタックス（High-Level Syntax）（ＨＬＳ）要素は、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ、タイルヘッダ、タイルグループヘッダ、などを指し得る。ＣＴＵヘッダは、例えば、ヘッダ情報として、ＣＵＴについて通知されたシンタックス要素を指し得る。例において、ＣＴＵサイズは最大ＣＵサイズである。
【0129】
一般に、特定のユニット（例えば、ＴＵ、ＣＵ）のルーマサイズ（ルーマサンプルによって表される。）が知られているとき、クロマサンプルの数によって指定される対応するクロマサイズが取得され得る。例において、ＹＵＶフォーマットは、４：２：０が使用され、ＣＵは、６４×６４ルーマサンプル（すなわち、６４×６４－Ｌ）のＣＵサイズを有する。従って、ＣＵは、３２×３２クロマサンプル（すなわち、３２×３２－Ｃ）のＣＵサイズを有する。ＣＵサイズは、６４×６４－Ｌ、３２×３２－Ｃ、又は６４×６４－Ｌ／３２×３２－Ｃと呼ばれ得る。同様に、ＴＵは、６４×６４ルーマサンプル（すなわち、６４×６４－Ｌ）のＴＵサイズを有する。従って、ＴＵは、３２×３２クロマサンプル（すなわち、３２×３２－Ｃ）のＴＵサイズを有する。ＴＵサイズは、６４×６４－Ｌ、３２×３２－Ｃ、又は６４×６４－Ｌ／３２×３２－Ｃと呼ばれ得る。例えば、ＴＵは、１つのルーマ変換ブロック（ＴＢ）及び２つのクロマＴＢを含む。ルーマＴＢは、６４×６４－Ｌのサイズを有し、クロマＴＢの夫々は、３２×３２－Ｃのサイズを有する。一般に、ＣＵ又はＴＵについて説明されている実施形態及び方法は、ＣＢ及びＴＢに夫々適切に適応され得る。
【0130】
ＣＵは、６４×６４－Ｌのルーマブロックと、３２×３２－Ｃの２つのクロマブロックとを含むことができる。以下の記載では、ＴＵサイズは、ＴＵ内のルーマサンプルを用いて表現される。例えば、Ｍ個のサンプルの最大ＴＵサイズは、Ｍ個のルーマサンプルの最大ＴＵサイズを指す。同様に、ＶＰＤＵサイズ及びＣＵサイズなどの他のサイズも、ＶＰＤＵ及びＣＵなどの対応するユニット内の各々のルーマサンプルを用いて夫々表現される。当然、ＴＵサイズ、ＶＰＤＵサイズ、ＣＵサイズなどは、クロマサンプル又はルーマ及びクロマサンプルの組み合わせを用いて表現可能である。
【0131】
ユニットサイズは、ユニットの幅、高さ、又は面積を指すことがある。例えば、最大ＴＵサイズは、最大のＴＵの幅、高さ、又は面積を指し得る。一般に、ＴＵ、ＣＵ、ＶＰＤＵなどは、長方形形状、正方形形状、‘Ｌ’字型、又は任意の適切な形状を含む如何なる適切な形状も有することができる。‘Ｌ’字型などのように、ユニットの形状が不規則であるとき、ユニットサイズはユニットの面積を特定することができる。
【0132】
いくつかの実施形態では、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、コーディングされたビデオビットストリームで、例えば、ＳＰＳ及びＰＰＳで、通知され得る。上述されたように、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、ルーマサンプルに関して通知され得る。代替的に、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、クロマサンプルに関して通知され得る。
【0133】
いくつかの実施形態では、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、エンコーダ及び／又はデコーダで保存され得るから、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは通知されない。一例では、ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、プロファイル及び／又はレベル定義で保存され得る。ＶＰＤＵサイズ及び／又は最大ＴＵサイズは、ルーマ又はクロマサンプルに関して保存され得る。
【0134】
いくつかの実施形態では、ＶＰＤＵは、同じサイズを共有するが、異なる形状を有してよい。例えば、ＶＰＤＵサイズがルーマサンプルに関して４０９６であるとき、ＶＰＤＵは、６４×６４の正方形形状又は３２×１２８の長方形形状を有することができる。ＶＰＤＵは、ＶＰＤＵサイズがルーマサンプルに関して４０９６である限りは、Ｌ字型などの他の形状を有することもできる。上記の説明は、特定のＴＵにも適用可能である。
【0135】
［１．例Ａ］
開示の態様に従って、最大許容ＴＵサイズ（最大ＴＵサイズとも呼ばれる。）はＭ個のサンプル（例えば、Ｍ×Ｍサンプルのサイズ）である。例において、ＴＵの最大幅及び最大高さはＭである。例において、ＴＵの最大面積はＭ×Ｍである。処理データユニットサイズ（例えば、ＶＰＤＵサイズ）はＫ個のサンプル（例えば、Ｋ×Ｋサンプルのサイズ）である。例において、処理データユニットサイズの最大幅及び最大高さはＫである。例において、処理データユニットサイズの最大面積はＫ×Ｋである。Ｗ×ＨのＣＵは、Ｗ個のサンプルの幅及びＨ個のサンプルの高さを有する。ＣＵは、ＣＵサイズ及び処理データユニットサイズＫに基づいて、サブ処理ユニット（ＳＰＵ）と呼ばれる複数のサブユニットに分割され得る。ＣＵは、ＱＴＢＴ、ＱＴ、ＢＴ、ＴＴ、又はそれらの組み合わせなどの任意の適切なパーティショニング構造又は任意の適切なパーティショニング構造の組み合わせを用いてＳＰＵに分割され得る。ＳＰＵは、同じサイズ又は異なるサイズを有してよい。
開示の態様に従って、最大許容ＴＵサイズ（最大ＴＵサイズとも呼ばれる。）はＭ個のサンプル（例えば、Ｍ×Ｍサンプルのサイズ）である。例において、ＴＵの最大幅及び最大高さはＭである。例において、ＴＵの最大面積はＭ×Ｍである。処理データユニットサイズ（例えば、ＶＰＤＵサイズ）はＫ個のサンプル（例えば、Ｋ×Ｋサンプルのサイズ）である。例において、処理データユニットサイズの最大幅及び最大高さはＫである。例において、処理データユニットサイズの最大面積はＫ×Ｋである。Ｗ×ＨのＣＵは、Ｗ個のサンプルの幅及びＨ個のサンプルの高さを有する。ＣＵは、ＣＵサイズ及び処理データユニットサイズＫに基づいて、サブ処理ユニット（ＳＰＵ）と呼ばれる複数のサブユニットに分割され得る。ＣＵは、ＱＴＢＴ、ＱＴ、ＢＴ、ＴＴ、又はそれらの組み合わせなどの任意の適切なパーティショニング構造又は任意の適切なパーティショニング構造の組み合わせを用いてＳＰＵに分割され得る。ＳＰＵは、同じサイズ又は異なるサイズを有してよい。
【0136】
実施形態において、ＣＵは、幅Ｗ又は高さＨがＫよりも大きい場合にＳＰＵに分割される。例において、ＳＰＵは、同じサイズ（すなわち、ＳＰＵサイズ）を有し、各ＳＰＵは、Ｍｉｎ（Ｗ，Ｋ）×Ｍｉｎ（Ｈ，Ｋ）サンプルのサイズを有する。よって、各ＳＰＵの幅は、Ｗ及びＫのうちの最小な方であり、そのＳＰＵの高さは、Ｈ及びＫのうちの最小な方である。いくつかの例では、ＣＵを分割する前に、ＣＵを分割すべきかどうかが、ＣＵのサイズ及び処理データユニットサイズＫに基づいて決定され得る。
【0137】
ＣＵ内のＳＰＵは、例えば、Ｍ×Ｍサンプルのサイズを有している、ＴＵに更に分割され得る。いくつかの例では、ＳＰＵは、Ｍｉｎ（Ｗ，Ｋ，Ｍ）×Ｍｉｎ（Ｈ，Ｋ，Ｍ）のサイズを有するＴＵに分割され得る。いくつかの例では、ＳＰＵを分割する前に、ＳＰＵを分割すべきかどうかが、ＳＰＵのサイズ及び最大ＴＵサイズＭに基づいて決定され得る。ＳＰＵは、ＱＴＢＴ、ＱＴ、ＢＴ、ＴＴ、又はそれらの組み合わせなどの任意の適切なパーティショニング構造又は任意の適切なパーティショニング構造の組み合わせを用いて分割され得る。開示の態様に従って、ＳＰＵを分割するための１つ以上のパーティショニング構造は、ＳＰＵのサイズ及び最大ＴＵサイズＭに基づいて決定され得る。例において、ＳＰＵは、決定された１つ以上のパーティショニング構造を用いてＴＵに再帰的に分割され得る。
【0138】
例において、ＳＰＵの幅及び高さが最大ＴＵサイズＭよりも大きいとき、ＳＰＵは、四分木パーティショニング構造を用いてＭ×ＭのＴＵに分割される。ＳＰＵは、四分木パーティショニング構造を用いてＴＵに再帰的に分割され得る。
【0139】
例において、ＳＰＵの幅がＭよりも大きく、ＳＰＵの高さがＭに等しいとき、ＳＰＵは、垂直二分木パーティショニング構造を用いてＭ×ＭのＴＵに分割される。例えば、Ｍは３２であり、ＳＰＵは６４×３２のサイズを有する。よって、ＳＰＵの幅は６４であり、ＳＰＵの高さは３２である。従って、垂直二分木パーティショニング構造が、ＳＰＵを３２×３２の２つのＴＵに分割するために使用され得る。ＳＰＵは、垂直二分木パーティショニング構造を用いてＴＵに再帰的に分割され得る。
【0140】
例において、ＳＰＵの幅がＭよりも大きく、ＳＰＵの高さがＭよりも小さいとき、ＳＰＵは、垂直二分木パーティショニング構造を用いてＴＵに分割され得、このとき、ＴＵの幅はＭであり、ＴＵの高さはＳＰＵの高さに等しい。
【0141】
例において、ＳＰＵの高さがＭよりも大きく、ＳＰＵの幅がＭに等しいとき、ＳＰＵは、水平二分木パーティショニング構造を用いてＭ×ＭのＴＵに分割される。ＳＰＵは、水平二分木パーティショニング構造を用いてＴＵに再帰的に分割され得る。例えば、Ｍは３２であり、ＳＰＵは３２×６４のサイズを有する。よって、ＳＰＵの幅は３２であり、ＳＰＵの高さは６４である。従って、水平二分木パーティショニング構造は、ＳＰＵを３２×３２の２つのＴＵに分割するために使用され得る。
【0142】
例において、ＳＰＵの高さがＭよりも大きく、ＳＰＵの幅がＭよりも小さいとき、ＳＰＵは、水平二分木パーティショニング構造を用いてＴＵに分割され得、このとき、ＴＵの高さはＭであり、ＴＵの幅はＳＰＵの幅に等しい。
【0143】
図２４の変換ツリーシンタックスは、ＳＰＵの分割及びＴＵを処理するために使用される処理順序の例を示す。
【0144】
例において、Ｗ×ＨのＣＵは、２つのステップで分割され得る。第１ステップでは、ＣＵがＳＰＵに分割され、このとき、各ＳＰＵはＭｉｎ（Ｗ，Ｋ）×Ｍｉｎ（Ｈ，Ｋ）のサイズを有する。続いて、第２ステップでは、各ＳＰＵがＴＵに更に分割され、このとき、各ＴＵはＭ×Ｍのサイズを有する。
【0145】
ＣＵ内のＴＵを処理するとき、ＣＵ内のＳＰＵは、第１スキャン順序（第１順序とも呼ばれる。）でスキャン及び処理され得る。更に、ＳＰＵの夫々の中で、ＴＵは、第２スキャン順序（第２順序とも呼ばれる。）でスキャン及び処理され得る。
【0146】
様々な実施形態において、ＳＰＵを処理する第１順序は、ラスタスキャン順序、垂直スキャン順序（例えば、ＳＰＵを列ごとに左から右へ又はその逆にスキャンする。）、ジグザグ順序、対角スキャン順序、などであることができる。
【0147】
様々な実施形態において、各ＳＰＵ内でＴＵを処理する第２順序は、ラスタスキャン順序、垂直スキャン順序（例えば、ＴＵを列ごとに左から右へ又はその逆にスキャンする。）、ジグザグ順序、対角スキャン順序、などであることができる。
【0148】
第１順序及び第２順序は、異なる実施形態において同じ又は異なることができる。例えば、ＳＰＵを処理する第１順序及び各ＳＰＵ内でＴＵを処理する第２順序は、ある実施形態では両方ともラスタスキャン順序である。
【0149】
［２．例Ｂ］
図２５は、Ｗ＝１２８及びＨ＝６４であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２５１０）を示す。最大ＴＵサイズＭは３２個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。ＣＵ（２５１０）は、最初に、第１の６４×６４ＳＰＵ（２５２０）及び第２の６４×６４ＳＰＵ（２５３０）に分割される。第１ＳＰＵ（２５２０）及び第２ＳＰＵ（２５３０）は、次いで、Ｍ×Ｍサンプルのサイズを夫々が有するＴＵ０～７に更に分割され得る。ＴＵ０～３は、第１ＳＰＵ（２５２０）に含まれ、ＴＵ４×７は、第２ＳＰＵ（２５３０）に含まれる。
図２５は、Ｗ＝１２８及びＨ＝６４であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２５１０）を示す。最大ＴＵサイズＭは３２個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。ＣＵ（２５１０）は、最初に、第１の６４×６４ＳＰＵ（２５２０）及び第２の６４×６４ＳＰＵ（２５３０）に分割される。第１ＳＰＵ（２５２０）及び第２ＳＰＵ（２５３０）は、次いで、Ｍ×Ｍサンプルのサイズを夫々が有するＴＵ０～７に更に分割され得る。ＴＵ０～３は、第１ＳＰＵ（２５２０）に含まれ、ＴＵ４×７は、第２ＳＰＵ（２５３０）に含まれる。
【0150】
第１順序に従って、第１ＳＰＵ（２５２０）が最初に処理され、続いて第２ＳＰＵ（２５３０）が処理され得る。第１ＳＰＵ（２５２０）又は第２ＳＰＵ（２５３０）内で、ＴＵ０～３又は４～７を処理するために使用される第２順序は、ラスタスキャン順序である。従って、ＴＵ０～７は、矢印（２５５１）によって示される順序に従って処理される。第１順序及び／又は第２順序は、明示的に（例えば、エンコーダからデコーダへのシグナリングを介して）、又は暗黙的に決定され得る。
【0151】
いくつかの例では、上述されたように、ＣＵをＳＰＵに分割し、各ＳＰＵがＴＵを更に含むことは、コーディング効率を改善する。図２５を参照すると、例において、第１ＳＰＵ（２５２０）は第１ＶＰＤＵであり、第２ＳＰＵ（２５３０）は第２ＶＰＤＵである。第１ＶＰＤＵ（又は第１ＳＰＵ（２５２０））及び第２ＶＰＤＵ（又は第２ＳＰＵ（２５３０））は、第１段階（例えば、エントロピデコーディング）、第２段階（例えば、逆量子化）、第３段階（逆変換）、及び／又は同様のものを含む多段階パイプラインを順次通ることができる。図２５に示される第１順序に従って、第１ＳＰＵ（２５２０）は第２ＳＰＵ（２５３０）の前に処理されるべきであるから、第１ＳＰＵ（２５２０）は、第１段階によって処理され、次いで第２段階に進む。例において、第１ＳＰＵ（２５２０）が第２段階によって処理されるとき、コーディング効率を改善するために、第２ＳＰＵ（２５３０）は第１段階によって処理される。続いて、第１ＳＰＵ（２５２０）は第３段階に進み、第２ＳＰＵ（２５３０）は第２段階へ移動することができる。第１ＳＰＵ（２５２０）が第３段階によって処理されるとき、第２ＳＰＵ（２５３０）は第２段階によって処理され得る。上記の説明は、ＶＰＤＵ及び多段階パイプラインを例として用いて与えられ、他のアーキテクチャ又はビデオコーディング方法に適切に適応され得る。上記の説明は、第１ＳＰＵ（２５２０）が第１ＶＰＤＵに含まれ、第２ＳＰＵ（２５３０）が第２ＶＰＤＵに含まれる場合に適応され得る。異なる段階でのＳＰＵの処理の少なくとも一部は、同時に実行される。
【0152】
上述されたように、ＳＰＵサイズがＴＵサイズよりも大きいとき、ＣＵ内の複数のＴＵは、ＳＰＵ（又はＶＰＤＵ）などの処理データユニットにグループ化され得、ＳＰＵが、連続したＳＰＵの並列処理（又は同時処理）を可能にする多段階パイプラインで処理され得る。いくつかの例では、説明は次のように変更され得る：ＣＵは第１ユニットに分割される。更に、第１ユニットの夫々は、第２ユニットに分割され得る。第２ユニットの夫々は、第３ユニットに分割されてもよい。例において、第１ユニットサイズは、第２ユニットのサイズよりも大きく、第２ユニットのサイズは、第３ユニットのサイズよりも大きい。かようなパーティショニングは、第１の多段階パイプラインが第２の多段階パイプライン内に入れ子にされる場合に有利であり得る。
【0153】
［３．例Ｃ］
図２６Ａは、Ｗ＝１２８及びＨ＝３２であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２６１０Ａ）を示す。最大ＴＵサイズＭは１６個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。Ｗ及びＫのうちの最小な方は６４であり、一方、Ｈ及びＫのうちの最小の方は３２である。よって、ＳＰＵのサイズは、例えば、変換ブロックをＶＰＤＵと整列させるために、６４×３２サンプルであるよう決定され得る。ＣＵ（２６１０Ａ）は、６４×３２サンプルのサイズを夫々が有する左ＳＰＵ（２６２０Ａ）及び右ＳＰＵ（２６３０Ａ）に分割され得る。２つのＳＰＵ（２６２０Ａ）及び（２６３０Ａ）は、左から右の順序でスキャン及び処理され得る。
図２６Ａは、Ｗ＝１２８及びＨ＝３２であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２６１０Ａ）を示す。最大ＴＵサイズＭは１６個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。Ｗ及びＫのうちの最小な方は６４であり、一方、Ｈ及びＫのうちの最小の方は３２である。よって、ＳＰＵのサイズは、例えば、変換ブロックをＶＰＤＵと整列させるために、６４×３２サンプルであるよう決定され得る。ＣＵ（２６１０Ａ）は、６４×３２サンプルのサイズを夫々が有する左ＳＰＵ（２６２０Ａ）及び右ＳＰＵ（２６３０Ａ）に分割され得る。２つのＳＰＵ（２６２０Ａ）及び（２６３０Ａ）は、左から右の順序でスキャン及び処理され得る。
【0154】
２つのＳＰＵ（２６２０Ａ）及び（２６３０Ａ）の夫々は、１６×１６サンプルである最大ＴＵサイズを夫々が有するＴＵに更に分割され得る。示されるように、左ＳＰＵ（２６２０Ａ）は、ＴＵ０～７に分割され、一方、右ＳＰＵ（２６３０Ａ）はＴＵ８～１５に分割される。ＳＰＵ（２６２０Ａ）では、ＴＵ０～７がラスタスキャン順序で処理され得る。ＳＰＵ（２６３０Ａ）では、ＴＵ８～１５がラスタスキャン順序で処理され得る。従って、ＴＵ０～１５は、矢印（２６５１Ａ）によって示される順序でスキャン及び処理され得、このとき、ＴＵ０は最初に処理され、ＴＵ１５は、ＴＵ０～１５が処理された後に処理される。
【0155】
［４．例Ｄ］
図２６Ｂは、Ｗ＝１２８及びＨ＝３２であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２６１０Ｂ）を示す。最大ＴＵサイズＭは１６個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。図２５の例と同様の方法で、ＣＵ（２６１０Ｂ）は、２つのＳＰＵ（２６２０Ｂ）及び（２６３０Ｂ）に分割され得、各ＳＰＵはＴＵに更に分割され得る。ＳＰＵ（２６２０Ｂ）及び（２６３０Ｂ）は、図２５と同じ順序で左から右に処理され得る。しかし、図２５の例とは異なって、ＳＰＵ（２６２０Ｂ）内のＴＵ０～７は、ジグザグ順序で処理され、ＳＰＵ（２６３０Ｂ）内のＴＵ８～１５は、ジグザグ順序で処理される。
図２６Ｂは、Ｗ＝１２８及びＨ＝３２であるとして、Ｗ×Ｈサンプルのサイズを有するＣＵ（２６１０Ｂ）を示す。最大ＴＵサイズＭは１６個のサンプルである。ＶＰＤＵサイズなどの処理データユニットサイズＫは６４個のサンプルである。図２５の例と同様の方法で、ＣＵ（２６１０Ｂ）は、２つのＳＰＵ（２６２０Ｂ）及び（２６３０Ｂ）に分割され得、各ＳＰＵはＴＵに更に分割され得る。ＳＰＵ（２６２０Ｂ）及び（２６３０Ｂ）は、図２５と同じ順序で左から右に処理され得る。しかし、図２５の例とは異なって、ＳＰＵ（２６２０Ｂ）内のＴＵ０～７は、ジグザグ順序で処理され、ＳＰＵ（２６３０Ｂ）内のＴＵ８～１５は、ジグザグ順序で処理される。
【0156】
［５．例Ｅ］
図２７は、開示の実施形態に従う変換ブロックパーティショニング及び処理プロセス（２７００）を説明するフローチャートを示す。プロセス（２７００）は、イントラモード又はインターモードでコーディングされたブロックの再構成において使用され得る。様々な実施形態において、プロセス（２７００）は、端末デバイス（２１０）、（２２０）、（２３０）及び（２４０）内の処理回路、ビデオエンコーダ（４０３）の機能を実行する処理回路、ビデオデコーダ（５１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、ビデオエンコーダ（６０３）の機能を実行する処理回路、などのような処理回路によって実行される。いくつかの実施形態では、プロセス（２７００）は、ソフトウェア命令で実施されるので、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス（２７００）を実行する。プロセスは（Ｓ２７０１）から開始し、（Ｓ２７１０）へ進む。
図２７は、開示の実施形態に従う変換ブロックパーティショニング及び処理プロセス（２７００）を説明するフローチャートを示す。プロセス（２７００）は、イントラモード又はインターモードでコーディングされたブロックの再構成において使用され得る。様々な実施形態において、プロセス（２７００）は、端末デバイス（２１０）、（２２０）、（２３０）及び（２４０）内の処理回路、ビデオエンコーダ（４０３）の機能を実行する処理回路、ビデオデコーダ（５１０）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、ビデオエンコーダ（６０３）の機能を実行する処理回路、などのような処理回路によって実行される。いくつかの実施形態では、プロセス（２７００）は、ソフトウェア命令で実施されるので、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス（２７００）を実行する。プロセスは（Ｓ２７０１）から開始し、（Ｓ２７１０）へ進む。
【0157】
（Ｓ２７１０）で、ピクチャ内のＣＵのコーディングされた情報が、コーディングされたビデオビットストリームからデコーディングされ得る。コーディングされた情報は、ＣＵのＷ個のサンプルの幅及びＨ個のサンプルの高さを示すことができる。
【0158】
（Ｓ２７２０）で、例えば、ＣＵの幅Ｗ及び高さＨのうちの少なくとも一方が、図２４～２６を参照して説明されたように、処理データユニットサイズＫよりも大きいときに、ＣＵはＳＰＵに分割され得る。処理データユニットサイズＫ及びＣＵのサイズに基づいて、ＳＰＵのサイズが決定され得る。ＳＰＵの幅は、Ｗ及びＫのうちの最小な方であることができ、ＳＰＵの高さは、Ｈ及びＫの最小な方であることができる。従って、ＣＵは、決定された幅及び高さを夫々が有するＳＰＵに分割され得る。例えば、Ｗが１２８であり、Ｈが６４であり、Ｋが６４である場合に、ＣＵは、６４×６４の第１ＳＰＵ及び６４×６４の第２ＳＰＵに分割され得る。例えば、処理データユニットはＶＰＤＵであることで木、よって、ＫはＶＰＤＵサイズであることができる。
【0159】
（Ｓ２７３０）で、ＳＰＵの夫々を分割するための１つ以上のパーティショニング構造が、例えば、ＳＰＵの幅及び高さの一方又は組み合わせと、Ｍ個のサンプルの最大ＴＵサイズとに基づいて、決定され得る。例において、ＳＰＵの幅及び高さの少なくとも一方はＭよりも大きい。
【0160】
上述されたように、如何なる適切なパーティショニング構造も、ＳＰＵの夫々を区分け又は分割するために使用され得る。例において、ＳＰＵの幅及び高さがＭよりも大きいとき、１つ以上のパーティショニング構造は、四分木パーティショニング構造であるよう決定される。例において、ＳＰＵの幅がＭよりも大きく、ＳＰＵの高さがＭよりも大きくないとき、１つ以上のパーティショニング構造は、垂直二分木パーティショニング構造であるよう決定される。例において、ＳＰＵの高さがＭよりも大きく、ＳＰＵの幅がＭよりも大きくないとき、１つ以上のパーティショニング構造は、水平二分木パーティショニング構造であるよう決定される。
【0161】
（Ｓ２７４０）で、ＳＰＵの夫々は、決定された１つ以上のパーティショニング構造に基づいてＴＵに分割され得る。例において、各々のＳＰＵは、決定された１つ以上のパーティショニング構造を用いてＴＵに再帰的に分割され得る。
【0162】
（Ｓ２７５０）で、ＳＰＵのＴＵは、処理順序に従って処理される。例えば、上述されたように、ＳＰＵは、第１順序に従って処理され得、ＳＰＵの夫々におけるＴＵは、第２順序に従って処理され得る。各ＴＵの残差データは、様々なデコーディング動作（例えば、変換係数のエントロピデコーディング、逆量子化若しくは量子化解除、逆変換、及び／又は同様のもの）によって決定され得る。プロセス（２７００）は、（Ｓ２７９９）へ進んで終了することができる。
【0163】
プロセス（２７００）は、ＣＵを例として用いて説明されている。プロセス（２７００）は、ルーマブロック、クロマブロックなどのようなＣＢに対して適切に適応され得る。簡潔さのために、ＣＢについての説明は省略される。
【0164】
プロセス（２７００）は、適切に適応され得る。例えば、１つ以上のステップは、変更、省略、又は結合され得る。例えば、ステップ（Ｓ２７３０）及び（Ｓ２７４０）は単一のステップにまとめられ得る。追加のステップも加えられ得る。プロセス（２７００）が実行される順序も変更可能である。
【0165】
［ＩＶ．コンピュータシステム］
上記の技術は、コンピュータ読み出し可能な命令を使用しかつ１つ以上のコンピュータ可読媒体に物理的に記憶されているコンピュータソフトウェアとして実装可能である。例えば、図２８は、開示されている対象の特定の実施形態を実装することに適したコンピュータシステム（２８００）を示す。
上記の技術は、コンピュータ読み出し可能な命令を使用しかつ１つ以上のコンピュータ可読媒体に物理的に記憶されているコンピュータソフトウェアとして実装可能である。例えば、図２８は、開示されている対象の特定の実施形態を実装することに適したコンピュータシステム（２８００）を示す。
【0166】
コンピュータソフトウェアは、１つ以上の中央演算処理装置（ＣＰＵ）、グラフィクス処理ユニット（ＧＰＵ）などによって直接に又は解釈、マイクロコード実行などを通じて実行され得る命令を含むコードを生成するようにアセンブリ、コンパイル、リンキングなどのメカニズムに従い得る如何なる適切な機械コード又はコンピュータ言語によってもコーディング可能である。
【0167】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネット（Internet of Things）のためのデバイス、などを含む様々なタイプのコンピュータ又はその構成要素で実行可能である。
【0168】
コンピュータシステム（２８００）に関して図２８に示される構成要素は、本質的に例示であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関して如何なる限定も示唆することを意図しない。構成要素の構成は、コンピュータシステム（２８００）の例示的な実施形態において説明される構成要素のうちのいずれか１つ又は組み合わせに関して何らかの依存又は要件も有するものとして解釈されるべきではない。
【0169】
コンピュータシステム（２８００）は、特定のヒューマンインターフェース入力デバイスを含んでよい。かようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（例えば、キーボード、スワイプ、データグロープ動作）、音声入力（例えば、声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず。）を通じた一人以上のユーザによる入力に反応してよい。ヒューマンインターフェースデバイスはまた、音声（例えば、発話、音楽、周囲音）、画像（例えば、スキャンされた画像、静止画カメラから取得された写真画像）、映像（例えば、二次元映像、立体視映像を含む三次元映像）などの、人による意識的な入力に必ずしも直接には関係しない特定のメディアを捕捉するためにも使用され得る。
【0170】
入力ヒューマンインターフェースデバイスは、キーボード（２８０１）、マウス（２８０２）、トラックパッド（２８０３）、タッチスクリーン（２８１０）、データグローブ（図示せず。）、ジョイスティック（２８０５）、マイク（２８０６）、スキャナ（２８０７）、カメラ（２８０８）（各１つしか表されていない。）のうちの１つ以上を含んでよい。
【0171】
コンピュータシステム（２８００）は、特定のヒューマンインターフェース出力デバイスも含んでよい。かようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音響、光、及び匂い／味を通じて一人以上のユーザの感覚を刺激し得る。かようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（２８１０）、データグローブ（図示せず。）、又はジョイスティック（２８０５）による触覚フィードバック、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る。）、音声出力デバイス（例えば、スピーカ（２８０９）、ヘッドホン（図示せず。））、視覚出力デバイス（例えば、夫々タッチスクリーン入力機能の有無によらず、夫々触覚フィードバック機能の有無によらず、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含み、それらのうちのいくつかは、立体視出力、仮想現実メガネ（図示せず。）、ホログラフィックディスプレイ及びスモークタンク（図示せず。）などの手段により二次元視覚出力又は三次元よりも多い次元の出力を出力可能なスクリーン（２８１０））、及びプリンタ（図示せず。）を含んでよい。
【0172】
コンピュータシステム（２８００）は、人がアクセス可能な記憶デバイス及びそれらの関連する媒体、例えば、ＣＤ／ＤＶＤ又は同様の媒体（２８２１）を伴ったＣＤ／ＤＶＤ ＲＯＭ／ＲＷ（２８２０）、サムドライブ（２８２２）、リムーバブルハードディスク又はソリッドステートドライブ（２８２３）、レガシー磁気媒体、例えば、テープ及びフロッピー（登録商標）ディスク（図示せず。）、専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースデバイス、例えば、セキュリティドングル（図示せず。）、なども含むことができる。
【0173】
当業者であれば、目下開示されている対象に関連して使用されている「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、又は他の一時的な信号を含まないことも理解するはずである。
【0174】
コンピュータシステム（２８００）は、１つ以上の通信ネットワークへのインターフェースも含むことができる。ネットワークは、例えば、ワイヤレス、ワイヤライン、光であることができる。ネットワークは更に、ローカル、ワイドエリア、メトロポリタン、車両及び工業、実時間、遅延耐性、などであることができる。ネットワークの例には、イーサネット（登録商標）などのローカルエリアネットワーク、ワイヤレスＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上放送ＴＶを含むＴＶワイヤライン又はワイヤレス広域デジタルネットワーク、ＣＡＮバスを含む車両及び工場ネットワーク、などがある。特定のネットワークは、一般に、特定の汎用デジタルポート又はペリフェラルバス（２８４９）（例えば、コンピュータシステム（２８００）のＵＳＢポートなど）に取り付けられた外付けネットワークインターフェースアダプタを必要とする。他は、一般に、後述されるようなシステムバスへの取り付け（例えば、ＰＣコンピュータシステムへのイーサネットネットワーク、又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）によってコンピュータシステム（２８００）のコアに組み込まれる。これらのネットワークのいずれかを使用して、コンピュータシステム（２８００）は他のエンティティと通信することができる。そのような通信は、単方向の受信専用（例えば、ブロードキャストＴＶ）又は単方向の送信専用（例えば、特定のＣＡＮバスデバイスへのＣＡＮバス）であることができ、あるいは、例えば、ローカル若しくは広域デジタルネットワークを使用して他のコンピュータシステムに対して双方向であることができる。特定のプロトコル又はプロトコルスタックが、上述されたようなネットワーク及びネットワークインターフェースの夫々で使用可能である。
【0175】
上記のヒューマンインターフェースデバイス、人がアクセス可能な記憶デバイス、及びネットワークインターフェースは、コンピュータシステム（２８００）のコア（２８４０）へ取り付けられ得る。
【0176】
コア（２８４０）は、１つ以上の中央演算処理装置（ＣＰＵ）（２８４１）、グラフィクス処理ユニット（ＧＰＵ）（２８４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）（２８４３）の形をとる専用のプログラム可能処理ユニット、特定のタスクのためのハードウェアアクセラレータ（２８４４）、などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）（２８４５）、ランダムアクセスメモリ（ＲＡＭ）（２８４６）、内部のユーザアクセス不能ハードドライブなどの内蔵大容量記憶装置、ＳＳＤ、など（２８４７）とともに、システムバス（２８４８）を通じて接続されてよい。いくつかのコンピュータシステムでは、システムバス（２８４８）は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするように、１つ以上の物理プラグの形でアクセス可能であることができる。コアのシステムバス（２８４８）へ直接に又はペリフェラルバス（２８４９）を通じて、周辺機器が取り付けられ得る。ペリフェラルバスのためのアーキテクチャには、ＰＣＩ、ＵＳＢなどがある。
【0177】
ＣＰＵ（２８４１）、ＧＰＵ（２８４２）、ＦＰＧＡ（２８４３）、及びアクセラレータ（２８４４）は、組み合わせて上記のコンピュータコードを構成することができる特定の命令を実行可能である。そのコンピュータコードは、ＲＯＭ（２８４５）又はＲＡＭ（２８４６）に記憶され得る。一時データもＲＡＭ（２８４６）に記憶可能であり、一方、永続性データは、例えば、内蔵大容量記憶装置（２８４７）に記憶可能である。メモリデバイスのいずれかへの高速な格納及び読み出しは、キャッシュメモリの使用により可能にされ得る。キャッシュメモリは、１つ以上のＣＰＵ（２８４１）、ＧＰＵ（２８４２）、大容量記憶装置（２８４７）、ＲＯＭ（２８４５）、ＲＡＭ（２８４６）などと密接に関連し得る。
【0178】
コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構成されたものであることができ、あるいは、それらは、コンピュータソフトウェア技術で通常の知識を有する者によく知られており利用可能である種類のものであることができる。
【0179】
例として、限定としてではなく、アーキテクチャ（２８００）、具体的にはコア（２８４０）を有するコンピュータシステムは、１つ以上の有形なコンピュータ可読媒体において具現されているソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ、などを含む。）の結果として機能を提供することができる。かようなコンピュータ可読媒体は、コア内蔵大容量記憶装置（２８４７）又はＲＯＭ（２８４５）などの、非一時的な性質であるコア（２８４０）の特定の記憶装置に加えて、先に紹介されたユーザアクセス可能な大容量記憶装置に関連した媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア（２８４０）によって実行可能である。コンピュータ可読媒体には、特定のニーズに応じて、１つ以上のメモリデバイス又はチップが含まれ得る。ソフトウェアは、コア（２８４０）、及び、具体的には、その中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む。）に、ＲＡＭ（２８４６）に記憶されているデータ構造を定義することと、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することとを含め、本明細書で説明されている特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。追加的に、又は代替案として、コンピュータシステムは、本明細書で説明されている特定のプロセス又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はそれとともに動作することができる、回路内でハードウェアにより実現されるか又は別なふうに具現されるロジック（例えば、アクセラレータ（２８４４））の結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶している回路（例えば、集積回路（ＩＣ））、実行のためのロジックを具現する回路、又は両方を包含することができる。本開示は、ハードウェア及びソフトウェアの如何なる適切な組み合わせも包含する。
【0180】
付録Ａ：頭字語
ＡＳＩＣ：Application-Specific Integrated Circuit
ＢＭＳ：benchmark set
ＣＡＮＢｕｓ：Controller Area Network Bus
ＣＢＦ：Coded Block Flag
ＣＤ：Compact Disc
ＣＰＵ：Central Processing Unit(s)
ＣＲＴ：Cathode Ray Tube
ＣＴＢ：Coding Tree Block(s)
ＣＴＵ：Coding Tree Unit(s)
ＣＵ：Coding Unit
ＤＶＤ：Digital Video Disc
ＦＰＧＡ：Field Programmable Gate Area(s)
ＧＯＰ：Group of Picture(s)
ＧＰＵ：Graphics Processing Unit(s)
ＧＳＭ：Global System for Mobile communications
ＨＥＶＣ：High Efficiency Video Coding
ＨＲＤ：Hypothetical Reference Decoder
ＩＳＰ：Intra Sub-Partitions
ＩＣ：Integrated Circuit
ＪＥＭ：Joint Exploration Model
ＬＡＮ：Local Area Network
ＬＣＤ：Liquid-Crystal Display
ＬＴＥ：Long-Term Evolution
ＭＰＭ：Most Probable Mode
ＭＶ：Motion Vector
ＯＬＥＤ：Organic Light-Emitting Diode
ＰＢ：Prediction Block(s)
ＰＣＩ：Peripheral Component Interconnect
ＰＬＤ：Programmable Logic Device
ＰＵ：Prediction Unit(s)
ＲＡＭ：Random Access Memory
ＲＯＭ：Read-Only Memory
ＳＢＴ：Sub-Block Transform
ＳＥＩ：Supplementary Enhancement Information
ＳＮＲ：Signal Noise Ratio
ＳＳＤ：Solid-State Drive
ＴＵ：Transform Unit(s)
ＵＳＢ：Universal Serial Bus
ＶＰＤＵ：Virtual Pipeline Data Unit
ＶＵＩ：Video Usability Information
ＶＶＣ：Versatile Video Coding
ＡＳＩＣ：Application-Specific Integrated Circuit
ＢＭＳ：benchmark set
ＣＡＮＢｕｓ：Controller Area Network Bus
ＣＢＦ：Coded Block Flag
ＣＤ：Compact Disc
ＣＰＵ：Central Processing Unit(s)
ＣＲＴ：Cathode Ray Tube
ＣＴＢ：Coding Tree Block(s)
ＣＴＵ：Coding Tree Unit(s)
ＣＵ：Coding Unit
ＤＶＤ：Digital Video Disc
ＦＰＧＡ：Field Programmable Gate Area(s)
ＧＯＰ：Group of Picture(s)
ＧＰＵ：Graphics Processing Unit(s)
ＧＳＭ：Global System for Mobile communications
ＨＥＶＣ：High Efficiency Video Coding
ＨＲＤ：Hypothetical Reference Decoder
ＩＳＰ：Intra Sub-Partitions
ＩＣ：Integrated Circuit
ＪＥＭ：Joint Exploration Model
ＬＡＮ：Local Area Network
ＬＣＤ：Liquid-Crystal Display
ＬＴＥ：Long-Term Evolution
ＭＰＭ：Most Probable Mode
ＭＶ：Motion Vector
ＯＬＥＤ：Organic Light-Emitting Diode
ＰＢ：Prediction Block(s)
ＰＣＩ：Peripheral Component Interconnect
ＰＬＤ：Programmable Logic Device
ＰＵ：Prediction Unit(s)
ＲＡＭ：Random Access Memory
ＲＯＭ：Read-Only Memory
ＳＢＴ：Sub-Block Transform
ＳＥＩ：Supplementary Enhancement Information
ＳＮＲ：Signal Noise Ratio
ＳＳＤ：Solid-State Drive
ＴＵ：Transform Unit(s)
ＵＳＢ：Universal Serial Bus
ＶＰＤＵ：Virtual Pipeline Data Unit
ＶＵＩ：Video Usability Information
ＶＶＣ：Versatile Video Coding
【0181】
本開示は、いくつかの例示的な実施形態について記載してきたが、本開示の範囲内にある代替、交換、及び様々な置換均等物が存在する。よって、明らかなように、当業者であれば、たとえ本明細書で明示的に図示又は説明されていないとしても、本開示の原理を具現し、よって、その精神及び範囲の中にある多数のシステム及び方法に想到可能である。
【0182】
［参照による援用］
本開示は、「Modified VPDU Compatible Max Transform Control」と題されて２０１９年３月２２日付けで出願された米国特許仮出願第６２／８２２７８７号の優先権の利益を主張して「Method and Apparatus for Video Coding」と題されて２０２０年３月１９日付けで出願された米国特許出願第１６／８２３８３１号の優先権の利益を主張するものである。これらの先願の全開示は、その全文を参照により本願に援用される。
本開示は、「Modified VPDU Compatible Max Transform Control」と題されて２０１９年３月２２日付けで出願された米国特許仮出願第６２／８２２７８７号の優先権の利益を主張して「Method and Apparatus for Video Coding」と題されて２０２０年３月１９日付けで出願された米国特許出願第１６／８２３８３１号の優先権の利益を主張するものである。これらの先願の全開示は、その全文を参照により本願に援用される。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図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】
【図26A】
【図26B】
【図27】
【図28】
