(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024096982
(43)【公開日】2024-07-17
(54)【発明の名称】デカップリング変換パーティション分割
(51)【国際特許分類】
H04N 19/119 20140101AFI20240709BHJP
【ＦＩ】
H04N19/119
【審査請求】未請求
【請求項の数】1
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024067913
(22)【出願日】2024-04-19
(62)【分割の表示】P 2022563423の分割
【原出願日】2022-01-18
(31)【優先権主張番号】17/564,566
(32)【優先日】2021-12-29
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/157,516
(32)【優先日】2021-03-05
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジャオ，シン
(72)【発明者】
【氏名】ジャオ，リアン
(72)【発明者】
【氏名】ペリンガセリー，クリシュナン マドゥ
(72)【発明者】
【氏名】リウ，シャン
(57)【要約】 （修正有）
【課題】ビデオデコーディングにおける変換ブロックのパーティション分割方法、装置及びコンピュータ読取り可能記憶媒体を提供する。
【解決手段】方法は、ルマブロックがクロマブロックと共配置されているコード化ビデオビットストリームを受信し、ルマコーディングブロックパーティション分割ツリーを獲得するために、ルマブロックをパーティション分割するステップと、クロマコーディングブロックパーティション分割ツリーを獲得するために、クロマブロックをパーティション分割するステップと、複数のルマ変換ブロックを獲得するために、ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割するステップと、少なくとも１つの複数のクロマ変換ブロックを獲得するために、クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割するステップと、を含む。
【選択図】図１７
【解決手段】方法は、ルマブロックがクロマブロックと共配置されているコード化ビデオビットストリームを受信し、ルマコーディングブロックパーティション分割ツリーを獲得するために、ルマブロックをパーティション分割するステップと、クロマコーディングブロックパーティション分割ツリーを獲得するために、クロマブロックをパーティション分割するステップと、複数のルマ変換ブロックを獲得するために、ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割するステップと、少なくとも１つの複数のクロマ変換ブロックを獲得するために、クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割するステップと、を含む。
【選択図】図１７
【特許請求の範囲】
【請求項1】
ビデオデコーディングにおいて変換ブロックのパーティション分割のための方法であって、前記方法は、
命令を保管しているメモリ、および、前記メモリと通信するプロセッサを含むデバイスによって、ルマブロックおよびクロマブロックについてコード化ビデオビットストリームを受信するステップであり、前記ルマブロックは前記クロマブロックと共配置されている、ステップと、
ルマコーディングブロックパーティション分割ツリーを獲得するために、前記デバイスによって、前記ルマブロックをパーティション分割するステップと、
クロマコーディングブロックパーティション分割ツリーを獲得するために、前記デバイスによって、前記クロマブロックをパーティション分割するステップと、
複数のルマ変換ブロックを獲得するために、前記デバイスによって、前記ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割するステップと、
少なくとも１つの複数のクロマ変換ブロックを獲得するために、前記デバイスによって、前記クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割するステップと、
を含む、方法。
命令を保管しているメモリ、および、前記メモリと通信するプロセッサを含むデバイスによって、ルマブロックおよびクロマブロックについてコード化ビデオビットストリームを受信するステップであり、前記ルマブロックは前記クロマブロックと共配置されている、ステップと、
ルマコーディングブロックパーティション分割ツリーを獲得するために、前記デバイスによって、前記ルマブロックをパーティション分割するステップと、
クロマコーディングブロックパーティション分割ツリーを獲得するために、前記デバイスによって、前記クロマブロックをパーティション分割するステップと、
複数のルマ変換ブロックを獲得するために、前記デバイスによって、前記ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割するステップと、
少なくとも１つの複数のクロマ変換ブロックを獲得するために、前記デバイスによって、前記クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割するステップと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ビデオコーディング及び／又はデコーディング技術に関する。そして、特には、デカップリング変換パーティション分割（decoupled transform partitioning）の改良された設計および信号化に関する。
【0002】
本出願は、2021年3月5日に出願された米国仮出願第63/157,516号および2021年12月29日に出願された米国非仮出願第１7/564,566号に基づき、かつ、それらの優先権の利益を主張するものであり、いずれもその全体が参照によりここにおいて組み込まれている。
【背景技術】
【0003】
ここにおいて提供されるこの背景説明は、本開示のコンテキストを一般的に提示するためのものである。現在指名されている発明者の研究は、その研究がこの背景セクションに記載されている範囲において、並びに、そうでなければ、この出願の出願時に先行技術として適格でないかもしれない説明の態様において、本開示に対する先行技術として明示的にも暗示的にも認められるものではない。
【0004】
ビデオコーディング（video coding）およびデコーディング（decoding）は、動き補償（motion compensation）を伴うインターピクチャ予測（inter-picture prediction）を使用して実行され得る。非圧縮ディジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば、1920×1080のルマ（luminance）サンプル、および、関連するフルまたはサブサンプリングされたクロマ（chrominance）サンプルに係る空間的ディメンションを有している。一連のピクチャは、例えば、毎秒60ピクチャまたは毎秒60フレームの、固定または可変ピクチャレート(代替的に、フレームレートと称されるもの)を有し得る。非圧縮ビデオは、ストリーミングまたはデータ処理のために特定のビットレート要件を有している。例えば、1920×1080のピクセル解像度、60フレーム／秒のフレームレート、およびカラーチャネル当たり8ビット/ピクセルでの4:2:0のクロマサブサンプリングであるビデオは、1.5Gbit/sに近い帯域幅を必要とする。そうしたビデオの1時間は、600Gバイト以上のストレージ領域を必要とする。
【0005】
ビデオコーディングおよびデコーディングの１つの目的は、圧縮を通じた、非圧縮入力ビデオ信号の冗長性の低減であり得る。圧縮は、場合によって、2桁以上の大きさで、前述の帯域幅及び／又はストレージ領域の要件を低減するのに役立ち得る。可逆圧縮および可逆圧縮の両方、並びに、それらの組み合わせが採用され得る。可逆圧縮とは、オリジナル信号の正確なコピーが、デコーディングプロセスを介して圧縮されたオリジナル信号から再構成され得る技術を指す。非可逆圧縮とは、オリジナルのビデオ情報が、コーディングの最中に完全には保持されず、かつ、デコーディングの最中に完全には回復できないコーディング／デコーディングプロセスを指す。非可逆を使用する場合、再構成された信号は、オリジナル信号と同一ではないかもしれない。しかし、オリジナル信号と再構成された信号の間の歪みは、いくらかの情報損失があるとはいえ、再構成された信号が意図されたアプリケーションのために有用にするのに十分に小さくされる。ビデオの場合、非可逆圧縮は、多くのアプリケーションで広く使用されている。許容される歪み量はアプリケーションに依存している。例えば、所定の消費者ビデオストリーミングアプリケーションのユーザは、映画またはテレビジョン放送アプリケーションのユーザよりも高い歪みを許容し得る。特定のコーディングアルゴリズムによって達成可能な圧縮比は、様々な歪み許容度を反映するように選択または調整することができる。より高い許容可能な歪みは、一般的に、より高い損失およびより高い圧縮比をもたらすコーディングアルゴリズムを可能にする。
【0006】
ビデオエンコーダおよびデコーダは、例えば、動き補償、フーリエ変換、量子化、およびエントロピー符号化（entropy coding）を含む、いくつかの広範なカテゴリおよびステップからの技術を利用することができる。
【0007】
ビデオコーデック技術は、イントラ（intra）コーディングとして知られる技術を含むことができる。イントラコーディングにおいて、サンプル値は、以前に再構成された参照ピクチャからのサンプルまたは他のデータを参照することなく表現される。いくつかのビデオコーデックにおいて、ピクチャは、空間的にサンプルのブロックへと分割される。サンプルの全てのブロックがイントラモードでコード化（coded）されている場合、そのピクチャは、イントラピクチャと称され得る。イントラピクチャ、および、独立デコーダリフレッシュピクチャといったそれらの派生物は、デコーダ状態をリセットするために使用することができ、そして、従って、コード化ビデオビットストリームおよびビデオセッションにおける第１（the first）ピクチャとして、または、静止ピクチャとして使用することができる。イントラ予測後のブロックのサンプルは、次いで、周波数領域へと変換することができ、そして、そのように生成された変換係数は、エントロピー符号化の前に量子化することができる。イントラ予測は、変換前領域（pre-transform domain）におけるサンプル値を最小化する技術を表している。場合によっては、変換後のDC値が小さく、かつ、AC係数が小さいほど、エントロピー符号化後のブロックを表すための所与の量子化ステップサイズで必要とされるビット数がより少なくなる。
【0008】
例えば、MPEG-2世代のコーディング技術から知られているといった伝統的なイントラコーディングは、イントラ予測を使用しない。しかしながら、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に隣接するもののエンコーディング及び／又はデコーディングの最中に獲得され、かつ、イントラコーディングまたはデコーディングされるデータのデコーディングされる順序において先行する、周囲のサンプルデータ及び／又はメタデータに基づいて、ブロックのコーディング／デコーディングを試みる技術を含む。そうした技術は、今後「イントラ予測（“intra prediction”）」技法と呼ばれる。少なくともいくつかの場合に、イントラ予測は、再構成中の現在ピクチャからだけ、かつ、他の参照ピクチャからではなく、参照データを使用することに留意すること。
【0009】
多くの異なる形式のイントラ予測が存在している。所与のビデオコーディング技術において、そうした技術のうち１つ以上が利用可能である場合、使用されている技術は、イントラ予測モードと称することができる。１つ以上のイントラ予測モードが、特定のコーデックにおいて提供され得る。所定の場合に、モードは、サブモードを有することができ、かつ／あるいは、様々なパラメータに関連することができ、そして、ビデオのブロックに対するモード／サブモード情報およびイントラコーディングパラメータは、個別に、または、集合的にモードコードワードないに含まれ得る。所与のモード、サブモード、及び／又は、パラメータの組み合わせについてどのコードワードを使用するかは、イントラ予測を通じて、コーディング効率ゲインに影響を及ぼし、かつ、コードワードをビットストリームへと変換するために使用されるエントロピー符号化技術も同様であり得る。
【0010】
イントラ予測に係る所定のモードは、H.264で導入され、H.265で改良され、そして、共同探査モデル(JEM)、バーサタイルビデオコーディング(VVC)、およびベンチマークセット(BMS)といった、より新しいコーディング技術において、さらに改良されている。一般的に、イントラ予測について、予測子ブロック（predictor block）は、利用可能になった隣接するサンプル値を使用して形成され得る。例えば、所定の方向及び／又はラインに沿って隣接するサンプルの特定のセットに係る利用可能な値は、予測子ブロックへとコピーされ得る。使用中の方向に対する参照は、ビットストリームでコード化することができ、または、それ自体が予測され得る。
【0011】
図1Aを参照すると、右下に示されているのは、H.265の33個の可能なイントラ予測子方向(H.265で指定される35個のモードのうち33個の角度モードに対応している)において指定された9個の予測子方向のサブセットである。矢印が収束する点(101)は、予測されているサンプルを表している。矢印は、101におけるサンプルを予測するために隣接するサンプルが使用される方向を表している。例えば、矢印(102)は、サンプル(101)が、水平方向から45度の角度で、隣接するサンプル（sample or samples）から右上に予測されることを示している。同様に、矢印(103)は、サンプル(101)が、水平方向から22.5度の角度で、隣接するサンプルからサンプル(101)の左下に予測されることを示している。
【0012】
さらに図1Aを参照すると、左上には、4×4サンプルの正方形ブロック(104)が示されている(破線の太線で示される)。正方形ブロック(104)は、16個のサンプルを含み、各サンプルは「S」でラベル付けされており、Yディメンションにおけるその位置(例えば、行（row）インデックス)、および、Xディメンションにおけるその位置(例えば、列（column）インデックス)を含む。例えば、サンプルS21は、Yディメンションにおいて(上から)第２サンプルであり、かつ、Xディメンションにおいて(左から)第１サンプルである。同様に、サンプルS44は、YおよびXディメンションの両方において、ブロック(104)の第４サンプルである。ブロックのサイズが4×4サンプルなので、S44は右下にある。さらに、同様のナンバリングスキームに従う、例示的な参照サンプルが示されている。参照サンプルは、Rと、ブロック(104)に対するそのY位置(例えば、行インデックス)およびX位置(列インデックス)を用いてラベル付けされている。H.264とH.265の両方においては、再構成中のブロックに隣接する予測サンプルが使用される。
【0013】
ブロック104のイントラピクチャ予測は、信号化予測方向（signaled prediction direction）に従って、隣接するサンプルから参照サンプル値をコピーすることによって開始することができる。例えば、コード化ビデオビットストリームが、このブロック104に対して、矢印(102)の予測方向を示している信号を含むと仮定する。すなわち、サンプルは、水平方向から45度の角度で、予測サンプルから右上に予測される。そうした場合、サンプルS41、S32、S23、S14は、同じ参照サンプルR05から予測される。次いで、サンプルS44は、参照サンプルR08から予測される。
【0014】
所定の場合、特には、方向が45度で均一に割り切れない場合には、参照サンプルを計算するために、例えば補間（interpolation）によって、複数の参照サンプルの値が組み合わされ得る。
【0015】
ビデオコーディング技術の開発が進むにつれて、可能な方向の数が増えてきている。例えば、H.264(2003年)では、9個の異なる方向がイントラ予測について利用可能である。これは、H.265(2013年)では33個に増加し、そして、本開示の時点で、JEM/VVC/BMSは、65子の方向をサポートすることができる。実験研究は、最も適切なイントラ予測方向を特定するのを助けるために実施されてきており、そして、エントロピー符号化における所定の技術は、それらの最も適切な方向を少数のビットでエンコーディングするために使用されてよく、方向について所定のビットペナルティを受け入れている。さらに、方向それ自体が、デコーディングされた隣接ブロックのイントラ予測において使用される隣接方向から、ときどき、予測することができる。
【0016】
図1Bは、JEMに従って、65個のイントラ予測方向を描く概略図(180)を示しており、時間にわたり開発された様々なエンコーディング技術における予測方向の数の増加を示している。
【0017】
コード化ビデオビットストリームにおける予測方向に対するイントラ予測方向を表すビットのマッピング方法は、ビデオコーディング技術ごとに様々であり得る。そして、例えば、予測方向の単純な直接マッピングから、イントラ予測モード、コードワード、最も可能性の高いモードを含む複雑な適応スキーム、および類似の技術まで、多岐にわたり得る。しかしながら、全ての場合に、ビデオコンテンツの中で、所定の他の方向よりも統計的により発生しにくい、イントラ予測の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減なので、上手く設計されたビデオコーディング技術において、よりありそうな方向よりも、より多くのビット数によって、よりありそうでない方向が表和され得る。
【0018】
インターピクチャ予測（inter picture prediction）、またはインター予測は、動き補償（motion compensation）に基づいてよい。動き補償において、以前に再構成されたピクチャまたはその一部(参照ピクチャ)からのサンプルデータは、動きベクトル(以下、MV)によって示される方向において空間的にシフトされた後で、新しく再構成されたピクチャまたはピクチャ部分(例えば、ブロック)の予測のために使用され得る。場合によって、参照ピクチャは、現在再構成中のピクチャと同じであり得る。MVは、2個のディメンションXおよびY、または、3個のディメンションを有してよく、第３ディメンションは、(時間ディメンションに類似した)使用中の参照ピクチャの表示である。
【0019】
いくつかのビデオ圧縮技術において、サンプルデータの所定の領域に対して適用可能な現在MVは、他のMVから、例えば、再構成中の領域に空間的に隣接し、かつ、デコーディング順序において現在MVに先行する、サンプルデータの他の領域に関連する他のMVから、予測することができる。そうすることは、相関するMVにおける冗長性の除去に依存することにより、MVをコーディングするために必要とされるデータの全体量を実質的に減少させることができ、それによって、圧縮効率を増加させている。MV予測は、例えば、カメラから導出された入力ビデオ信号(ナチュラルビデオ（natural video）として知られている)をコーディングするときに、単一のMVが適用される領域よりも大きい領域がビデオシーケンスにおける同様の方向に移動する統計的可能性があり、従って、ある場合には、隣接領域のMVから導出された同様な動きベクトルを用いて予測することができるので、効果的に機能することができる。その結果、所与の領域について実際のMVは、周囲のMVから予測されたMVと類似または同一になる。そうしたMVは、次に、エントロピー符号化の後、MVが隣接するMVから予測されるのではなく、直接的にコード化される場合に使用されるよりも、より少ない数のビットで表現され得る。場合によって、MV予測は、オリジナル信号(すなわち、サンプルストリーム)から導出された信号(すなわち、MV)の可逆圧縮の例であり得る。他の場合に、MV予測それ自体は、例えば、いくつかの周囲のMVから予測子を計算する際の丸め誤差のために、非可逆的であり得る。
【0020】
様々なMV予測メカニズムが、H.265/HEVC(ITU-T Rec.H.265,“High Efficiency Video Coding”,December 2016)において説明されている。H.265が規定する多くのMV予測メカニズムのうち、後述されるのは「空間的マージ（“spatial merge”）」と呼ばれる技術である。
【0021】
具体的には、図2を参照すると、現在ブロック(201)は、空間的にシフトされた同じサイズの以前のブロックから予測可能であると動き探索（motion search）プロセスの最中の処理中にエンコーダによって見出されたサンプルを含んでいる。そのMVを直接的にコーディングする代わりに、MVは、１つ以上の参照ピクチャに関連付けられたメタデータから、例えば、A0、A1、およびB0、B1、B2(それぞれ202から206)と示される5個の周囲のサンプルのいずれかに関連付けられたMVを使用して、(デコーディング順序において)最新の参照ピクチャから導出することができる。H.265において、MV予測は、隣接ブロックが使用するのと同じ参照ピクチャからの予測子を使用することができる。
【発明の概要】
【0022】
本開示は、ビデオエンコーディング及び／又はデコーディングのための方法、装置、および、コンピュータ読取り可能な記憶媒体の様々な実施形態を説明する。
【0023】
一つの態様に従って、本開示の実施形態は、ビデオデコーディングにおける変換ブロックパーティション分割（partitioning）のための方法を提供する。本方法は、ルマブロックおよびクロマブロッククロマブロックに対するコード化ビデオビットストリームを、デバイスによって、受信するステップを含み、ルマブロックは、クロマブロックと共配置（co-located）されている。デバイスは、命令を保管するメモリ、および、メモリと通信するプロセッサを含む。本方法は、また、ルマコーディングブロックパーティション分割ツリーを獲得するために、デバイスによって、クロマブロックをパーティション分割するステップと、クロマコーディングブロックパーティション分割ツリーを獲得するために、デバイスによって、ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割するステップと、少なくとも１つの複数のクロマ変換ブロックを獲得するために、デバイスによって、クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割するステップと、を含む。
【0024】
別の態様に従って、本開示の実施形態は、ビデオエンコーディング及び／又はデコーディングのための装置を提供する。装置は、命令を保管するメモリ、および、メモリと通信するプロセッサを含む。プロセッサが命令を実行すると、プロセッサは、ビデオデコーディング及び／又はエンコーディングのための上記方法を装置に実行させるように構成されている。
【0025】
別の態様に従って、本開示の実施形態は、命令を保管する非一時的コンピュータ読取り可能な媒体を提供する。命令は、ビデオデコーディング及び／又はエンコーディングのためにコンピュータによって実行されると、ビデオデコーディング及び／又はエンコーディングのための上記方法をコンピュータに実施させる。
【0026】
上記および他の態様、および、それらの実装は、図面、明細書、および請求項において詳細に説明される。
【図面の簡単な説明】
【0027】
開示される技術的事項（subject matter）のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるだろう。
【発明を実施するための形態】
【0028】
これから、本発明が、添付図面を参照して、以降で詳細に説明される。図面は、本発明の一部を形成し、かつ、実例として、実施形態の特定の例を示している。しかしながら、本発明は、様々な異なる形態において実施することができ、そして、従って、カバーされ、または、請求される技術的事項は、以下で明らかにされる実施形態のいずれにも限定されないものとして解釈されるように意図されていることに留意されたい。また、本発明は、方法、デバイス、構成要素、またはシステムとして実施することができることにも留意されたい。従って、本発明の実施形態は、例えば、ハードウェア、ソフトウェア、ファームウェア、または、それらの任意の組み合わせの形態をとることができる。
【0029】
明細書および請求項の全体を通して、用語は、明示的に記述された意味を超えて、コンテキストにおいて示唆され、または、暗示されたニュアンス付きの意味を有することがある。ここにおいて使用されるフレーズ「一つの実施形態において（“in one embodiment”）」または「いくつかの実施形態において（“in some embodiments”）」は、必ずしも同じ実施形態を指すものではなく、そして、ここにおいて使用されるフレーズ「別の実施形態において（“in another embodiment”）」または「他の実施形態において（“in other embodiment”）」は、必ずしも異なる実施形態を指すものではない。同様に、ここにおいて使用されるフレーズ「一つの実装において（“in one implementation”）」または「いくつかの実装において（“in some implementations”）」は、必ずしも同じ実装を指すものではなく、そして、ここにおいて使用されるフレーズ「別の実装において（“in another implementation”）」または「他の実装において（“in other implementation”）」は、必ずしも異なる実装を指すものではない。例えば、請求された主題事項は、例示的な実施形態／実装形態の全体または一部の組み合わせを含むことが意図されている。
【0030】
一般的に、用語は、コンテキストにおける用法から、少なくとも部分的に理解され得る。例えば、用語、「および（“and”）」、「または（“or”）」、または「及び／又は（“and/or”）」といったものは、ここにおいて使用される場合、そうした用語が使用されるコンテキストに少なくとも部分的に依存し得る、様々な意味を含み得る。典型的には、「または」は、A、BまたはCといった、リストを関連付けるために使用される場合、ここで包括的な意味で使用されるA、B、およびC、並びに、ここで排他的な意味で使用されるA、B、またはCを意味するように意図されている。加えて、ここにおいて使用される用語「１つ以上（“one or more”）」または「少なくとも１つ（“at least one”）」は、少なくとも部分的にコンテキストに依存して、単数の意味で任意の特徴、構造、または特徴を説明するために使用されてよく、もしくは、複数の意味で特徴、構造、または特徴の組み合わせを説明するために使用されてよい。同様に、用語、「一つの（“a”、“an”、または“the”）」といったものは、少なくとも部分的にはコンテキストに依存して、単数の使用を伝えるか、または、複数の使用を伝えるものと理解され得る。加えて、用語「基づいて（“based on”）」または「によって決定された（“determined by”）」は、必ずしも排他的な一連の要因を伝えるように意図されたものではなく、かつ、その代わり、必ずしも明示的に記述されていない、再度、少なくとも部分的にコンテキストに依存して、追加の要因の存在を許容することができる。
【0031】
図3は、本開示の一つの例示的な実施形態に従って、通信システム(300)の簡略化されたブロックダイアグラムを示している。通信システム(300)は、例えば、ネットワーク(350)を介して、互いに通信することができる複数の端末装置を含んでいる。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された端末装置の第１ペア(310)および(320)を含む。図3の例において、端末装置の第１ペア(310)および(320)は、データの一方向送信を行うことができる。例えば、端末装置(310)は、ネットワーク(350)を介して他の端末装置(320)に送信するために、ビデオデータ(例えば、端末装置(310)によってキャプチャされるビデオピクチャのストリーム)をコード化（code）することができる。エンコード化ビデオデータは、１つ以上のコード化ビデオビットストリームの形態で送信することができる。端末装置(320)は、ネットワーク(350)からコード化ビデオデータを受信し、コード化ビデオデータをデコーディングして、ビデオピクチャを回復し、そして、回復したビデオデータに従ってビデオピクチャを表示することができる。一方向データ伝送は、媒体提供アプリケーション、等において実施され得る。
【0032】
別の例において、通信システム(300)は、例えば、ビデオ会議アプリケーションの最中に、実装され得るコード化ビデオデータの双方向伝送を実行する端末装置の第２ペア(330)および(340)を含む。データの双方向伝送のために、一つの例において、端末装置(330)および(340)の各端末装置は、ネットワーク(350)を介して端末装置(330)および(340)の他方の端末装置に伝送するために、ビデオデータ(例えば、端末装置によってキャプチャされるビデオピクチャのストリーム)をコード化することができる。端末装置(330)および(340)の各端末装置は、また、端末装置(330)および(340)の他方の端末装置によって送信されたコード化ビデオデータを受信し、ビデオピクチャを回復するためにコード化ビデオデータをデコーディングし、そして、回復したビデオデータに従って、アクセス可能な表示装置でビデオピクチャを表示することができる。
【0033】
図3の例において、端末装置(310)、(320)、(330)、および(340)は、サーバ、パーソナルコンピュータ、およびスマートフォンとして実装され得るが、本開示の基本原理（underlying principles）の適用性は、そのように限定されるものではない。本開示の実施形態は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、ウェアラブルコンピュータ、専用のビデオ会議装置、及び／又は、類似のものにおいて実施され得る。ネットワーク(350)は、例えば、有線及び／又は無線通信ネットワークを含む、端末装置(310)、(320)、(330)、および(340)の間でコード化ビデオデータを搬送する、任意の数またはタイプのネットワークを表している。通信ネットワーク(350)は、回線交換（circuit-switched）、パケット交換（packet-switched）、及び／又は、他のタイプのチャネルにおいてデータを交換することができる。代表的なネットワークは、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又は、インターネットを含む。本説明の目的のために、ネットワーク(350)のアーキテクチャおよびトポロジーは、ここにおいて明示的に説明されない限り、本開示の動作に対して重要ではない場合がある。
【0034】
図4は、開示される技術的事項のためのアプリケーションについて一つの例として、ビデオストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示している。開示される技術的事項は、例えば、ビデオ会議、デジタルTV放送、ゲーム、バーチャルリアリティ、CD、DVD、メモリスティック、等を含むデジタルメディア上の圧縮ビデオの記憶ストレージ、などを含む他のビデオアプリケーションに対しても同様に適用可能である。
【0035】
ビデオストリーミングシステムは、非圧縮のビデオピクチャまたはピクチャのストリーム(402)を生成するためのビデオソース(401)、例えば、デジタルカメラ、を含むことができるビデオキャプチャサブシステム(413)を含み得る。一つの例において、ビデオピクチャのストリーム(402)は、ビデオソース401のデジタルカメラによって記録されるサンプルを含む。ビデオピクチャのストリーム(402)は、エンコード化ビデオデータ(404)(または、コード化ビデオビットストリーム)と比較した場合に、高いデータ量を強調するために太い線として描かれており、ビデオソース(401)に結合されたビデオエンコーダ(403)を含む電子デバイス(420)によって処理することができる。ビデオエンコーダ(403)は、ハードウェア、ソフトウェア、または、それらの組み合わせを含むことができ、以下でより詳細に説明されるように、開示される技術的事項の態様を可能にし、または実施する。エンコード化ビデオデータ(404)(または、エンコード化ビデオビットストリーム(404))は、非圧縮ビデオピクチャ(402)のストリームと比較した場合に、より低いデータ量を強調するために細いラインとして描かれており、将来の使用のため、または、直接的にビデオデバイス(図示なし)にダウンストリームするためにストリーミングサーバ(405)に保管することができる。１つ以上のストリーミングクライアントサブシステム、図4のクライアントサブシステム(406)および(408)といったものは、エンコード化ビデオデータ(404)のコピー(407)および(409)を取り出すために、ストリーミングサーバ(405)にアクセスすることができる。クライアントサブシステム(406)は、例えば、電子デバイス(430)内にビデオデコーダ(410)を含むことができる。ビデオデコーダ(410)は、エンコード化ビデオデータの入力コピー(407)をデコーディングし、そして、非圧縮であり、かつ、ディスプレイ(412)(例えば、ディスプレイスクリーン)または他のレンダリング装置(図示なし)上でレンダリングできる、ビデオピクチャの送信（outgoing）ストリーム(411)を生成する。ビデオデコーダ410は、本開示において説明される様々な機能の一部または全部を実行するように構成され得る。いくつかのストリーミングシステムにおいて、エンコード化ビデオデータ(404)、(407)、および(409)(例えば、ビデオビットストリーム)は、所定のビデオコーディング／圧縮標準に従ってエンコーディングすることができる。これらの標準の例は、ITU-T勧告（Recommendation）H.265を含む。一つの例において、開発中のビデオコーディング規格は、バーサタイルビデオコーディング(VVC)として非公式に知られている。開示される技術的事項は、VVC、および、他のビデオコーディング標準のコンテキストにおいて使用され得る。
【0036】
電子デバイス(420)および(430)は、他の構成要素(図示なし)を含むことができることに留意されたい。例えば、電子デバイス(420)は、ビデオデコーダ(図示なし)を含むことができ、そして、電子デバイス(430)は、同様に、ビデオエンコーダ(図示なし)も含むことができる。
【0037】
図5は、以下の本開示の任意の実施形態に従って、ビデオデコーダ(510)のブロックダイアグラムを示している。ビデオデコーダ(510)は、電子デバイス(530)に含まれ得る。電子デバイス(530)は、受信器(531)(例えば、受信回路)を含むことができる。ビデオデコーダ(510)が、図4の例におけるビデオデコーダ(410)の代わりに使用され得る。
【0038】
受信器(531)は、ビデオデコーダ(510)によってデコーディングされるべき１つ以上のコード化ビデオシーケンスを受信することができる。同一または別の実施形態においては、１つのコード化ビデオシーケンスが一度にデコーディングされ得る。ここで、各コード化ビデオシーケンスのデコーディングは、他のコード化ビデオシーケンスから独立している。各ビデオシーケンスは、複数のビデオフレームまたはピクチャに関連付けされ得る。コード化ビデオシーケンスは、チャネル(501)から受信され得る。チャネルは、エンコード化ビデオデータを保管するストレージ装置へのハードウェア／ソフトウェアリンク、または、エンコード化ビデオデータを送信するストリーミングソースであってよい。受信器(531)は、コード化音声データ及び／又は補助的なデータストリームといった、他のデータと共にエンコード化ビデオデータを受信することができ、それらのそれぞれの処理回路（図示なし）に転送され得る。受信器(531)は、コード化ビデオシーケンスを他のデータから分離することができる。ネットワークジッタと闘う（combat）ために、バッファメモリ(515)が、受信器(531)とエントロピーデコーダ／パーサ(520)(以降で、「パーサ(520)」)との間に配置されてよい。所定のアプリケーションにおいて、バッファメモリ(515)は、ビデオデコーダ(510)の一部として実装され得る。他のアプリケーションにおいては、ビデオデコーダ(510)(図示なし)の外側にあり、かつ、ビデオデコーダ(510)から分離してよい。さらに他のアプリケーションにおいて、例えば、ネットワークジッタと闘う目的で、ビデオデコーダ(510)の外側にバッファメモリ(図示なし)が存在し得る。そして、例えば、再生（playback）タイミングを処理するために、ビデオデコーダ(510)の内側に別のバッファメモリ(515)が存在し得る。受信器(531)が、十分な帯域幅および制御可能性があるストア／フォワード装置から、または、アイソクロナス（isosynchronous）ネットワークからデータを受信している場合、バッファメモリ(515)は必要とされず、または、小さくてよい。インターネットといったベストエフォート（best-effort）・パケットネットワークにおける使用のためには、十分なサイズのバッファメモリ(515)が必要とされ得る。そして、そのサイズは比較的に大きい。そうしたバッファメモリは、適応サイズで実装され得る。そして、少なくとも部分的には、オペレーティングシステムまたはビデオデコーダ(510)の外側の類似の要素(図示なし)において実装され得る。
【0039】
ビデオデコーダ(510)は、コード化ビデオシーケンスからシンボル(521)を再構成するためのパーサ(520)を含んでよい。これらのシンボルのカテゴリは、ビデオデコーダ(510)の動作を管理するために使用される情報、および、図5に示されるように、電子デバイス(530)の一体部分であっても、または、なくてもよいが、電子デバイス(530)に結合され得る、ディスプレイ(512)(例えば、表示スクリーン)といったレンダリング装置を制御するための潜在的な情報を含む。レンダリング装置の制御情報は、補足拡張情報(Supplemental Enhancement Information、SEI message)、または、ビデオユーザビリティ情報(Video Usability Information、VUI)パラメータセットフラグメント(図示なし)の形式であってよい。パーサ(520)は、パーサ(520)によって受信されるコード化ビデオシーケンスを解析（parse）／エントロピー復号（entropy-decode）することができる。コード化ビデオシーケンスのエントロピー符号化、ビデオコーディング技術または標準に従うことができ、そして、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わないコーディング、などを含む、様々な原理に従うことができる。パーサ(520)は、サブグループに対応する少なくとも１つのパラメータに基づいて、コード化ビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループのうち少なくとも１つに対するサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャのグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)、などを含むことができる。パーサ(520)は、また、コード化ビデオシーケンス情報から、変換係数(例えば、フーリエ変換係数)、量子化パラメータ値、動きベクトル、などといったものを抽出し得る。
【0040】
パーサ(520)は、シンボル(521)を生成するように、バッファメモリ(515)から受信したビデオシーケンスにおいてエントロピー復号／構文解析オペレーションを実行することができる。
【0041】
シンボル(521)の再構成は、コード化ビデオピクチャまたはその部分のタイプ(インターおよびイントラピクチャ、インターおよびイントラブロック、といったもの)および他の要因に応じて、複数の異なる処理または機能ユニットを含むことができる。関与するユニット、および、それらがどのように関与するかは、パーサ(520)によってコード化ビデオシーケンスから構文解析されたサブグループ制御情報によって制御され得る。パーサ(520)と、以下の複数の処理または機能ユニットとの間のそうしたサブグループ制御情報のフローは、単純化のために描かれていない。
【0042】
既に述べた機能ブロックの他に、ビデオデコーダ(510)は、概念的に、以下に説明されるように、いくつかの機能ユニット（functional unit）へと分割することができる。商業的制約の下で動作する実用的な実装において、これらの機能ユニットの多くは、相互に密接に相互作用し、そして、少なくとも部分的には、相互に統合され得る。しかしながら、開示される技術的事項の様々な機能を明確に説明する目的で、機能ユニットへの概念的な細分化が以下の開示において採用されている。
【0043】
第１ユニットは、スケーラ／逆変換ユニット(551)を含んでよい。スケーラ／逆変換ユニット(551)は、量子化された変換係数、並びに、使用すべき逆変換のタイプ、ブロックサイズ、量子化係数／パラメータ、量子化スケーリング行列、および、パーサ(520)からのシンボル(521)としての位置（lie）を示している情報を含む、制御情報を受信し得る。スケーラ／逆変換ユニット(551)は、アグリゲータ(555)へと入力され得るサンプル値を含むブロックを出力することができる。
【0044】
場合によって、スケーラ／逆変換(551)の出力サンプルは、イントラコード化ブロックに関係することができる。すなわち、以前に再構成されたピクチャからの予測情報を使用しないが、現在ピクチャの以前に再構成された部分からの予測情報を使用することができるブロックである。そうした予測情報は、イントラピクチャ予測ユニット(552)によって提供され得る。場合によって、イントラピクチャ予測ユニット(552)は、既に再構成され、そして、現在ピクチャバッファ(558)に保管されている周囲のブロック情報を使用して、再構成されるブロックの同じサイズおよび形状のブロックを生成し得る。現在ピクチャバッファ(558)は、例えば、部分的に再構成された現在ピクチャ及び／又は完全に再構成された現在ピクチャをバッファする。アグリゲータ(555)は、いくつかの実装において、サンプル毎に、イントラ予測ユニット(552)が生成した予測情報を、スケーラ／逆変換ユニット(551)によって提供されるように、出力サンプル情報に加えることができる。
【0045】
他の場合には、スケーラ／逆変換ユニット(551)の出力サンプルは、インターコード化（inter coded）、および、潜在的に動き補償ブロックに関係することができる。そうした場合、動き補償予測ユニット553は、インターピクチャ予測に使用されるサンプルを取り出すために参照ピクチャメモリ557にアクセスすることができる。ブロックに関係するシンボル(521)に従ってフェッチされたサンプルの動き補償の後で、これらのサンプルは、出力サンプル情報を生成するたように、アグリゲータ(555)によって、スケーラ／逆変換ユニット(551)の出力(ユニット551の出力は残差サンプルまたは残差信号と称され得る)に追加され得る。動き補償予測ユニット(553)が、そこから予測サンプルをフェッチする、参照ピクチャメモリ(557)内のアドレスは、例えば、X、Y成分(シフト)、および、参照ピクチャ成分(時間)を有することができる、シンボル(521)の形式で動き補償予測ユニット(553)に利用可能な、動きベクトルによって制御され得る。動き補償は、また、サブサンプルの正確な動きベクトルが使用されている場合、参照ピクチャメモリ(557)からフェッチされるサンプル値の補間を含んでよい。そして、また、動きベクトル予測メカニズム、などに関連付けされてよい。
【0046】
アグリゲータ(555)の出力サンプルは、ループフィルタユニット(556)における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、コード化ビデオシーケンス(コード化ビデオビットストリームとも称される)に含まれるパラメータによって制御され、かつ、パーサ(520)からシンボル(521)としてループフィルタユニット(556)に利用可能にされる、インループフィルタ技術を含むことができる。しかし、また、コード化ピクチャまたはコード化ビデオシーケンスの以前の部分(デコーディング順序で)のデコーディングの最中に獲得されたメタ情報に応答することができ、同様に、以前に再構成され、かつ、ループフィルタリングされたサンプル値に応答することができる、ループ内フィルタ技術を含むことができる。いくつかのタイプのループフィルタが、以下でさらに詳細に説明するように、様々な順序でループフィルタユニット556の一部として含まれてよい。
【0047】
ループフィルタユニット(556)の出力は、レンダリング装置(512)に出力され、同様に、将来のインターピクチャ予測で使用するために参照ピクチャメモリ(557)に保管され得る、サンプルストリームであり得る。
【0048】
所定のコード化ピクチャは、いったん完全に再構成されると、将来のインターピクチャ予測のための参照ピクチャとして使用され得る。例えば、現在ピクチャに対応するコード化ピクチャが完全に再構成され、そして、コード化ピクチャが参照ピクチャとして(例えば、パーサ(520)によって)識別されると、現在ピクチャバッファ(558)は、参照ピクチャメモリ(557)の一部となり得る。そして、フレッシュな（fresh）現在ピクチャバッファは、次のコード化ピクチャの再構成を開始する前に再割当てされ得る。
【0049】
ビデオデコーダ(510)は、ITU-T Rec. H.265といった、標準において採用されている事前決定されたビデオ圧縮技術に従って、デコーディングオペレーションを実行することができる。コード化ビデオシーケンスは、コード化ビデオシーケンスが、ビデオ圧縮技術または標準のシンタックス、および、ビデオ圧縮技術または標準に文書化されているプロファイルの両方に従うという意味で、使用されているビデオ圧縮技術または標準によって指定されたシンタックスに適合し得る。具体的に、プロファイルは、そのプロファイルの下での使用に利用可能な唯一のツールとして、ビデオ圧縮技術または標準において利用可能な全てのツールから、所定のツールを選択することができる。標準に準拠するために、コード化ビデオシーケンスの複雑さは、ビデオ圧縮技術または標準のレベルによって定義される範囲内にあってよい。場合によって、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート(例えば、毎秒メガサンプルで測定される)、最大参照ピクチャサイズ、などを制限する。レベルによって設定される制限値は、場合によって、仮想参照デコーダ(Hypothetical Reference Decoder、HRD)仕様、および、コード化ビデオシーケンスにおいて信号化されたHRDバッファ管理のためのメタデータを通して、さらに制限され得る。
【0050】
いくつかの例示的な実施形態において、受信器(531)は、コード化ビデオと共に追加(冗長な)データを受信することができる。追加データは、コード化ビデオシーケンスの一部として含まれ得る。追加データは、データを適切にデコーディングするため、かつ／あるいは、元のビデオデータをより正確に再構成するために、ビデオデコーダ(510)によって使用され得る。追加データは、例えば、時間的、空間的、または、信号雑音比（SNR）エンハンスメント層、冗長スライス、冗長ピクチャ、前方エラー補正コード、などの形式であり得る。
【0051】
図6は、本開示の一つの例示的な実施形態に従って、ビデオエンコーダ(603)のブロックダイアグラムを示している。ビデオエンコーダ(603)は、電子デバイス(620)内に含まれてよい。電子デバイス(620)は、さらに、送信器(640)(例えば、送信回路)を含んでよい。ビデオエンコーダ(603)が、図4の例におけるビデオエンコーダ(403)の代わりに使用され得る。
【0052】
ビデオエンコーダ(603)は、ビデオエンコーダ(603)によってコード化されるべきビデオイメージをキャプチャすることができる、ビデオソース(601)から(図6の例において電子デバイス(620)の一部ではない)、ビデオサンプルを受け取ることができる。別の例において、ビデオソース(601)は、電子デバイス(620)の一部として実装され得る。
【0053】
ビデオソース(601)は、任意の適切なビット深さ(例えば、8ビット、10ビット、12ビット、...)、任意の色空間(例えば、BT.601 YCrCb、RGB、XYZ...)、および、任意の適切なサンプリング構造(例えば、YCrCb 4:2:0、YCrCb 4:4:4)であり得る、デジタルビデオサンプルストリームの形式で、ビデオエンコーダ(603)によってコード化されるソースビデオシーケンスを提供することができる。メディア配信システムにおいて、ビデオソース(601)は、以前に準備されたビデオを保管することができるストレージ装置であり得る。ビデオ会議システムにおいて、ビデオソース(601)は、ローカルイメージセンサ情報をビデオシーケンスとしてキャプチャするカメラであってよい。ビデオデータは、順番に観察されるときに動きを伝える、複数の個々のピクチャまたはイメージとして提供されてよい。ピクチャ自体は、ピクセルの空間的アレイとして構成されてよい。ここで、各ピクセルは、使用されているサンプリング構造、色空間、などに応じて、１つ以上のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。
【0054】
いくつかの例示的な実施形態によれば、ビデオエンコーダ(603)は、ソースビデオシーケンスのピクチャを、リアルタイムで、または、アプリケーションによって要求される任意の他の時間制約の下で、コード化ビデオシーケンス(643)へとコード化および圧縮することができる。適切なコーディング速度を実現することは、コントローラ(650)の１つの機能を構成する。いくつかの実施形態において、コントローラ(650)は、以下で説明されるように、他の機能ユニットに機能的に結合されてよく、そして、制御することができる。この結合（coupling）は、単純化のために示されていない。コントローラ(650)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ（lambda）値、...)、ピクチャサイズ、ピクチャグループレ（GOP）イアウト、最大動きベクトル探索範囲、などを含むことができる。コントローラ(650)は、所定のシステム設計のために最適化された、ビデオエンコーダ(603)に関係する他の適切な機能を有するように構成することができる。
【0055】
いくつかの例示的な実施形態において、ビデオエンコーダ(603)は、コーディングループにおいて動作するように構成され得る。過剰に単純化された説明として、一つの例において、コーディングループは、ソースコーダ(630)(例えば、コード化されるべき入力ピクチャおよび参照ピクチャに基づいて、シンボルストリームといった、シンボルを生成する責任を負うもの)、および、ビデオエンコーダ(603)に埋め込まれた(ローカル)デコーダ(633)を含み得る。デコーダ(633)は、たとえ埋め込みデコーダ633がエントロピー符号化なしでソースコーダ630によってコード化ビデオストリームを処理するとしても(エントロピー符号化においてシンボルとコード化ビデオビットストリームとの間の任意の圧縮は、開示される技術的事項において考慮されるビデオ圧縮技術において可逆であり得るため)、(リモート)デコーダと同様の方法でサンプルデータを生成するためにシンボルを再構成する。再構成されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームのデコーディングは、デコーダ位置(ローカルまたはリモート)に依存しないビット正確（bit-exact）な結果をもたらすので、参照ピクチャメモリ(634)内のコンテンツも、また、ローカルエンコーダとリモートエンコーダとの間でビット正確である。別の言葉で言えば、エンコーダの予測部は、参照ピクチャサンプルとして、デコーディングの最中に予測を使用するときに、デコーダが「見る（“see”）」であろうものと全く同じサンプル値を「見る」。参照ピクチャ同期性のこの基本原理(および、例えば、チャネルエラーのせいで、同期性が維持できない場合に、結果として生じるドリフト)は、コーディング品質を改善するために使用される。
【0056】
「ローカル（“local”）」デコーダ(633)のオペレーションは、ビデオデコーダ(510)といった、「リモート（“remote”）」デコーダと同じであり得る。これは、既に図5に関連して上記で詳細に説明されている。しかしながら、また、図5も簡単に参照すると、シンボルが利用可能であり、かつ、エントロピーコーダ(645)およびパーサ(520)によるコード化ビデオシーケンスへのシンボルのエンコーディング／デコーディングが可逆であり得るので、バッファメモリ(515)を含む、ビデオデコーダ(510)のエントロピー復号部分、および、パーサ(520)は、エンコーダ内のローカルデコーダ(633)において完全には実装されなくてよい。
【0057】
この時点で行うことができる観察は、デコーダ内にだけ存在し得る解析／エントロピー復号を除く任意のデコーダ技術が、また、対応するエンコーダにおいて、実質的に同一の機能形式で、存在する必要があり得ることである。この理由のために、開示される技術的事項は、時には、エンコーダのデコーダ部分と関連する、デコーダオペレーションにフォーカスし得る。従って、エンコーダ技術の記述は、包括的に記述されたデコーダ技術の逆であるので、省略することができる。所定の領域または態様においてだけ、エンコーダのより詳細な説明が以下に提供される。
【0058】
いくつかの例示的な実装におけるオペレーションの最中に、ソースコーダ(630)は、「参照ピクチャ（“reference picture”）」として指定されたビデオシーケンスからの１つ以上の以前にコード化されたピクチャに関して入力ピクチャを予測的にコード化する、動き補償予測コーディングを実行することができる。このようにして、コーディングエンジン(632)は、入力ピクチャのピクセルブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャのピクセルブロックとの間のカラーチャネルにおける差異(または残差)をコード化する。
【0059】
ローカルビデオデコーダ(633)は、ソースコーダ(630)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコード化ビデオデータをデコーディングすることができる。コーディングエンジン(632)のオペレーションは、有利なことに、損失プロセスであり得る。コード化ビデオデータがビデオデコーダ（図６に図示なし）でデコーディングされ得る場合、再構成されたビデオシーケンスは、典型的に、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ(633)は、参照ピクチャ上でビデオデコーダによって実行され、そして、再構成された参照ピクチャを参照ピクチャキャッシュ(634)に保管させ得る、デコーディング処理を複製（replicate）する。このようにして、ビデオエンコーダ(603)は、遠端(リモート)のビデオデコーダによって獲得される、再構成された参照ピクチャとして、共通のコンテンツを有する、再構成された参照ピクチャのコピーをローカルに保管することができる。
【0060】
予測器(635)は、コーディングエンジン(632)について予測探索を実行することができる。すなわち、コード化されるべき新しいピクチャについて、予測器(635)は、参照ピクチャメモリ(634)を、サンプルデータ(参照ピクセルブロックの候補として)、または、参照ピクチャ動きベクトル、ブロック形状、等といった所定のメタデータについて検索することができ、これらは、新しいピクチャに対する適切な予測参照として役立ち得る。予測器(635)は、適切な予測参照を見出すために、サンプルブロック毎に動作し得る。場合によっては、予測器(635)により獲得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(634)に保管された複数の参照ピクチャから引き出された予測参照を有し得る。
【0061】
コントローラ(650)は、例えば、ビデオデータをエンコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ソースコーダ(630)のコーディングオペレーションを管理することができる。
【0062】
全ての前述された機能ユニットの出力は、エントロピーコーダ(645)においてエントロピー符号化を受けることができる。エントロピーコーダ(645)は、ハフマン（Huffman）コーディング、可変長コーディング、算術コーディング、などの技術に従ったシンボルの可逆圧縮によって、様々な機能ユニットによって生成されたシンボルをコード化ビデオシーケンスへと変換する。
【0063】
送信器(640)は、エントロピーコーダ(645)によって生成された際に、通信チャネル(660)を介した送信の準備のために、コード化ビデオシーケンスをバッファし得る。通信チャネルは、コード化ビデオデータを保管するストレージ装置へのハードウェア／ソフトウェアリンクであってよい。送信器(640)は、ビデオコーダ(603)からのコード化ビデオデータを、例えば、コード化音声データ及び／又は補助的なデータストリーム(ソースの図示なし)などの、送信される他のデータとマージすることができる。
【0064】
コントローラ(650)は、ビデオエンコーダ(603)のオペレーションを管理することができる。コーディングの最中に、コントローラ(650)は、各コード化ピクチャに対して、所定のコード化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、ピクチャは、しばしば、以下のピクチャタイプの１つとして割り当てられ得る。
【0065】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内のあらゆる他のピクチャを使用することなくコーディングおよびデコーディングされ得るもの、であってよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(「IDR」)ピクチャを含む、イントラピクチャの異なるタイプを許容する。当業者でれば、Iピクチャのこうした変形、および、それらそれぞれのアプリケーションおよび特徴を知っている。
【0066】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で１つの動きベクトルおよび参照インデックスを使用する、イントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るもの、であってよい。
【0067】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2個の動きベクトルおよび参照インデックスを使用する、イントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るもの、であってよい。同様に、複数の予測ピクチャは、単一ブロックの再構成のために、2個以上の参照ピクチャおよび関連するメタデータを使用することができる。
【0068】
ソースピクチャは、通常、空間的に複数のサンプルコーディングブロック(例えば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック)へと分割され、そして、ブロック毎にコード化される。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように、他の(既にコード化された)ブロックを参照して予測的にコード化され得る。例えば、Iピクチャのブロックは、非予測的にコード化されてよく、または、それらは、同じピクチャの既にコード化されたブロック(空間的予測またはイントラ予測)を参照して予測的にコード化され得る。Pピクチャのピクセルブロックは、１つの以前にコード化された参照ピクチャを参照して、空間的予測を介して、または、時間的予測を介して予測的に符号化され得る。Bピクチャのブロックは、１つまたは2つの以前にコード化参照ピクチャを参照して、予測的に、空間的予測を介して、または時間的予測を介して、コード化され得る。ソースピクチャまたは中間処理されたピクチャは、他の目的のために、他のタイプのブロックへと細分化され得る。コーディングブロックおよび他のタイプのブロックの分割は、以下でさらに詳細に説明されるように、同じ方法に従ってよく、または、従わなくてよい。
【0069】
ビデオエンコーダ(603)は、ITU-T Rec.H.265.といった、事前決定されたビデオコーディング技術または標準に従って、コーディングオペレーションを実行することができる。そのオペレーションにおいて、ビデオエンコーダ(603)は、入力ビデオシーケンスにおける時間的および空間的冗長性を利用する予測コーディングオペレーションを含む、様々な圧縮オペレーションを実行することができる。コード化ビデオデータは、このように、使用されているビデオコーディング技術または標準によって指定されたシンタックスに従うことができる。
【0070】
いくつかの例示的な実施形態において、送信器(640)は、エンコード化ビデオと共に追加データを送信し得る。ソースコーダ(630)は、コード化ビデオシーケンスの一部として、そうしたデータを含むことができる。追加データは、時間的／空間的／SNR強調層、冗長ピクチャおよびスライス、SEIメッセージ、VUIパラメータセットフラグメント、などといった他の形式の冗長データ、を含み得る。
【0071】
ビデオは、時間シーケンスにおいて複数のソースピクチャ(ビデオピクチャ)としてキャプチャされ得る。イントラピクチャ予測(しばしば、イントラピクチャ予測と略される)は、所与のピクチャにおける空間的相関を利用し、そして、インターピクチャ予測は、ピクチャ間の時間的または他の相関を利用する。例えば、現在ピクチャと称される、エンコーディング／デコーディング中の特定のピクチャは、ブロックへとパーティション分割されてよい。現在ピクチャ内のブロックは、ビデオ内で以前にコード化され、かつ、依然としてバッファされている参照ピクチャにおける参照ブロックに類似する場合、動きベクトルと称されるベクトルによってコード化され得る。動きベクトルは、参照ピクチャ内の参照ブロックを指し、そして、複数の参照ピクチャが使用されている場合には、参照ピクチャを識別する第３ディメンションを有し得る。
【0072】
いくつかの例示的な実施形態において、インターピクチャ予測のために双予測（bi-prediction）技術が使用され得る。そうした両予測技術に従って、2個の参照ピクチャが使用される。第１参照ピクチャおよび第２参照ピクチャといったものであり、両方が、デコーディング順序で(しかい、それぞれ、過去または将来において、表示順序で)ビデオ内の現在ピクチャを進める。現在ピクチャ内のブロックは、第１参照ピクチャ内の第１基準ブロックを指し示す第１動きベクトル、および、第２参照ピクチャ内の第２基準ブロックを指し示す第２動きベクトルによって、コード化され得る。ブロックは、第１基準ブロックと第２基準ブロックの組み合わせによって、同時に予測され得る。
【0073】
さらに、コーディング効率を改善するために、インターピクチャ予測においてマージモード技術が使用され得る。
【0074】
本開示のいくつかの例示的実施形態に従って、インターピクチャ予測およびイントラピクチャ予測といった、予測は、ブロックのユニットにおいて実行される。例えば、ビデオピクチャのシーケンス内のピクチャは、圧縮のためにコーディングツリーユニット（CTU）へとパーティション分割され、ピクチャにおけるCTUは、64×64ピクセル、32×32ピクセル、または16×16ピクセルといった、同じサイズを有し得る。一般的に、CTUは、3つの並列コーディングツリーブロック(CTB)を含むことができる：１個のルマCTBと2個のクロマCTB。各CTUは、１つまたは複数のコーディングユニット(CU)に再帰的に四分木分割することができる。例えば、64×64ピクセルのCTUは、64×64ピクセルの１個のCU、または32×32ピクセルの4個のCUに分割することができる。32×32ブロックの１つ以上は、さらに16×16ピクセルの4CUに分割することができる。いくつかの例示的な実施形態において、各CUは、エンコーディングの最中に分析されて、インター予測タイプまたはイントラ予測タイプといった様々な予測タイプの中でCUの予測タイプを決定することができる。CUは、時間的及び／又は空間的予測可能性に依存して、１つ以上の予測ユニット(PU)へと分割され得る。一般的に、各PUは、ルマ予測ブロック(PB)と2つのクロマPBを含む。一つの実施形態において、コーディング(エンコーディング／デコーディング)における予測オペレーションは、予測ブロックのユニットにおいて実行される。CUのPU(または異なるカラーチャネルのPB)への分割は、様々な空間的パターンで実行され得る。ルマまたはクロマPBは、例えば、8×8ピクセル、16×16ピクセル、8×16ピクセル、16×8サンプルなどといった、サンプルの値(例えば、ルマ値)のマトリクスを含んでよい。
【0075】
図7は、本開示の別の例示的実施形態に従って、ビデオエンコーダ(703)のダイアグラムを示している。ビデオエンコーダ(703)は、ビデオピクチャのシーケンスにおける現在ビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、そして、処理ブロックをコード化ビデオシーケンスの一部である、コード化ピクチャへとエンコーディングするように構成されている。例示的なビデオエンコーダ(703)は、図4の例におけるビデオエンコーダ(403)の代わりに使用することができる。
【0076】
例えば、ビデオエンコーダ(703)は、8×8サンプルの予測ブロックなど、といった処理ブロックのサンプル値のマトリクスを受信する。次いで、ビデオエンコーダ(703)は、処理ブロックが、例えば、レート歪み最適化(RDO)を使用して、イントラモード、インターモード、または双予測モードを使用して、最良にコード化されるか否かを決定する。処理ブロックがイントラモードでコード化されると決定された場合、ビデオエンコーダ703は、処理ブロックをコード化ピクチャへとエンコーディングするためにイントラ予測技術を使用してよく、そして、処理ブロックがインターモードまたは双予測モードでエンコーディングされると決定された場合、ビデオエンコーダ703は、処理ブロックをコード化ピクチャへとエンコーディングするために、それぞれ、インター予測技術または双予測技術を使用してよい。いくつかの例示的な実施形態において、マージモードは、予測器の外側のコード化動きベクトル成分の利益を伴うことなく、動きベクトルが１つ以上の動きベクトル予測器から導出される、インターピクチャ予測のサブモードとして使用されてよい。いくつかの他の例示的な実施形態において、対象ブロック（subject block）に対して適用可能な動きベクトル構成要素が存在し得る。従って、ビデオエンコーダ(703)は、処理ブロックのパーティションモードを決定するために、モード決定モジュールといった、図7に明示的に示されていない構成要素を含んでよい。
【0077】
図7の例において、ビデオエンコーダ(703)は、インターエンコーダ(730)、イントラエンコーダ(722)、残差計算器(723)、スイッチ(726)、残差エンコーダ(724)、汎用コントローラ(721)、および、図7の例の構成で示されるように一緒に結合されたエントロピーエンコーダ(725)を含んでいる。
【0078】
インターエンコーダ(730)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、ブロックを参照ピクチャ内の１つ以上の参照ブロック(例えば、表示順序で以前のピクチャおよび後のピクチャにおけるブロック)と比較し、インター予測情報(例えば、インターエンコーディング技術に従った冗長情報の記述、動きベクトル、マージモード情報)を生成し、そして、任意の適切な技術を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成されている。いくつかの例において、参照ピクチャは、図6の例示的なエンコーダ620に埋め込まれたデコーディングユニット633を使用して(以下でさらに詳細に説明するように、図7の残差デコーダ728として示される)、エンコーディングされたビデオ情報に基づいてデコーディングされる、デコーディングされた参照ピクチャである。
【0079】
イントラエンコーダ(722)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、そのブロックを同じピクチャ内で既にコード化されたブロックと比較し、かつ、変換後に量子化された係数を生成し、そして、場合によっては、イントラ予測情報(例えば、１つ以上のイントラエンコーディング技術に従ったイントラ予測方向情報)も生成するように構成されている。イントラエンコーダ(722)は、同じピクチャ内のイントラ予測情報および参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)を計算することができる。
【0080】
汎用コントローラ(721)は、一般的制御データを決定し、そして、一般的制御データに基づいてビデオエンコーダ(703)の他の構成要素を制御するように構成することができる。一つの例において、汎用コントローラ(721)は、ブロックの予測モードを決定し、そして、予測モードに基づいて、スイッチ(726)に制御信号を供給する。例えば、予測モードがイントラモードである場合、汎用コントローラ721は、スイッチ726を制御して、残差計算器723による使用のためのイントラモード結果を選択し、そして、エントロピーエンコーダ725を制御して、イントラ予測情報を選択し、かつ、ビットストリームにイントラ予測情報を含める。そして、ブロックの予測モードがインターモードである場合、汎用コントローラ721は、スイッチ726を制御して、残差計算器723による使用のためのインター予測結果を選択し、エントロピーエンコーダ725を制御して、インター予測情報を選択し、かつ、ビットストリームにインター予測情報を含める。
【0081】
残差計算器(723)は、イントラエンコーダ(722)またはインターエンコーダ(730)から選択されたブロックについて、受信されたブロックと予測結果との差異(残差データ)を計算するように構成することができる。残差エンコーダ(724)は、変換係数を生成するために、残差データをエンコーディングするように構成することができる。例えば、残差エンコーダ(724)は、残差データを空間ドメインから周波数ドメインに変換して、変換係数を生成するように構成することができる。次いで、変換係数は、量子化処理にかけられ、量子化された変換係数を獲得する。様々な例示的な実施形態において、ビデオエンコーダ(703)は、また、残差デコーダ(728)も含んでいる。残差デコーダ(728)は、逆変換を実行し、そして、デコーディングされた残差データを生成するように構成されている。デコーディングされた残差データは、イントラエンコーダ(722)およびインターエンコーダ(730)によって適切に使用することができる。例えば、インターエンコーダ(730)は、デコーディングされた残差データおよびインター予測情報に基づいてデコーディングされたブロックを生成することができ、そして、イントラエンコーダ(722)は、デコーディングされた残差データおよびイントラ予測情報に基づいてデコーディングされたブロックを生成することができる。デコーディングされたブロックは、デコーディングされたピクチャを生成するために適切に処理され、そして、デコーディングされたピクチャは、メモリ回路(図示なし)においてバッファリングされ、かつ、参照ピクチャとして使用され得る。
【0082】
エントロピーエンコーダ(725)は、エンコーディングされたブロックを含むようにビットストリームをフォーマットし、そして、エントロピー符号化を実行するように構成することができる。エントロピーエンコーダ(725)は、ビットストリーム内に様々な情報を含むように構成されている。例えば、エントロピーエンコーダ(725)は、一般的な制御データ、選択された予測情報(例えば、イントラ予測情報またはインター予測情報)、残差情報、および、ビットストリーム内の他の適切な情報を含むように構成することができる。インターモードまたは双予測モードいずれかのマージサブモードでブロックをコーディングする場合、残差情報は存在しなくてよい。
【0083】
図8は、本開示の別の実施形態に従って、例示的なビデオデコーダ(810)のダイアグラムを示している。ビデオデコーダ(810)は、コード化ビデオシーケンスの一部であるコード化ピクチャを受信し、そして、コード化ピクチャをデコーディングして、再構成されたピクチャを生成するように構成されている。一つの実施形態においては、図4の実施形態でのビデオデコーダ(410)の代わりに、ビデオデコーダ(810)が使用され得る。
【0084】
図8の例において、ビデオデコーダ(810)は、エントロピーデコーダ(871)、インターデコーダ(880)、残差デコーダ(873)、再構成モジュール(874)、および、図8の例示の構成に示されるように一緒に結合されたイントラデコーダ(872)を含んでいる。
【0085】
エントロピーデコーダ(871)は、コード化ピクチャから、そのコード化ピクチャが構成されるシンタックス要素を表す特所定のシンボルを再構成するように構成することができる。そうしたシンボルは、例えば、ブロックがコード化されるモード(例えば、イントラモード、インターモード、双予測モード、マージサブモード、または他のサブモード)、イントラデコーダ(872)またはインターデコーダ(880)によって予測のために使用される所定のサンプルまたはメタデータを識別することができる予測情報(例えば、イントラ予測情報またはインター予測情報)、例えば、量子化された変換係数の形式の残差情報、などを含むことができる。一つの例として、予測モードがインターまたは双予測モードである場合、インター予測情報がインターデコーダ(880)に提供され、そして、予測タイプがイントラ予測タイプである場合、イントラ予測情報がイントラデコーダ(872)に提供される。残差情報は、逆量子化を受けることができ、そして、残差デコーダ(873)に提供される。
【0086】
インターデコーダ(880)は、インター予測情報を受信し、そして、インター予測情報に基づいてインター予測結果を生成するように構成することができる。
【0087】
イントラデコーダ(872)は、イントラ予測情報を受信し、そして、イントラ予測情報に基づいて予測結果を生成するように構成することができる。
【0088】
残差デコーダ(873)は、逆量子化変換係数を抽出するために逆量子化を実行し、そして、脱量子化（de-quantized）変換係数を処理して、残差を周波数領域から空間領域に変換するように構成することができる。残差デコーダ(873)は、また、エントロピーデコーダ(871)によって提供され得る、所定の制御情報(量子化器パラメータ(Quantizer Parameter、QP)を含む)を利用することもできる(データ経路は、低データ量制御情報だけであり得るので、図示されてない)。
【0089】
再構成モジュール(874)は、空間領域において、残差デコーダ(873)による出力としての残差と、予測結果(場合によっては、インターまたはイントラ予測モジュールによる出力としてのもの)とを組み合わせて、再構成ビデオの一部として再構成されたピクチャの一部を形成する再構成されたブロックを形成するように構成することができる。デブロッキングオペレーション、等の他の適切なオペレーションも、また、視覚品質を改善するために実施することができることに留意されたい。
【0090】
ビデオエンコーダ(403)、(603)、および(703)、並びに、ビデオデコーダ(410)、(510)、および(810)は、任意の適切な技術を使用して実施することができることに留意すること。いくつかの例示的な実施形態において、ビデオエンコーダ(403)、(603)、および(703)、並びに、ビデオデコーダ(410)、(510)、および(810)は、１つ以上の集積回路を使用して実施することができる。別の実施形態において、ビデオエンコーダ(403)、(603)、および(603)、並びに、ビデオデコーダ(410)、(510)、および(810)は、ソフトウェア命令を実行する１つ以上のプロセッサを使用して実施することができる。
【0091】
コーディングブロックパーティション分割に向けて、および、いくつかの実施例においては、事前決定されたパターンが適用されてよい。図9に示されるように、第１事前決定レベル(例えば、64×64ブロックレベル)から開始して第２事前決定レベル(例えば、4×4レベル)までの、例示的な4方向（4-way）パーティションツリーを使用することができる。例えば、ベースブロックは、図9に示すのと同じパーティションツリーが、最低レベル(例えば、4×4レベル)まで、より低いスケールで繰り返され得るという点で、再帰パーティションに対して許容されるものとして、Rとして指定されたパーティションを有する、902、904、906、および908によって示される4つのパーティション分割オプションに従うことができる。いくつかの実装形態において、図9のパーティション分割スキームに追加の制限が適用されてよい。図9の実施においては、矩形パーティション(例えば、1:2/2:1の矩形パーティション)が許可され得るが、それらは再帰的であることが許可されず、一方で、正方形パーティションは再帰的であることが許可されている。再帰（recursion）を伴う図9に続くパーティション分割は、必要であれば、コーディングブロックの最終セットを生成する。そうしたスキームは、１つ以上のカラーチャネルに適用され得る。
【0092】
図10は、再帰的なパーティショニングがパーティション分割ツリーを形成するのを可能にする別の例の事前定義された分割パターンを示している。図10に示されるように、例示的な10個のパーティション分割構造またはパターンを事前定義され得る。ルートブロックは、事前定義されたレベル(例えば、128×128レベル、または64×64レベル)から開始し得る。図10の例示的なパーティション分割構造は、様々な2:1/1:2および4:1/1:4の矩形パーティションを含んでいる。なお、図10の第２行に示されている3個のサブパーティションを有するパーティションタイプは、「T型（“T-type”）」パーティションと称され得る。「T型」パーティション1002、1004、1006、および1008は、左T型（Left T-Type）、上T型（Top T-Type）、右T型（Right T-Type）、下T型（Bottom T-Type）と称され得る。いくつかの実装形態において、図10の矩形パーティションのいずれも、さらに細分化することは許されない。ルートノードまたはルートブロックからの分割深さを示すために、コーディングツリーの深さが、さらに定義されてよい。例えば、ルートノードまたはルートブロック、例えば、128×128ブロックについて、コーディングツリー深さ、は、0に設定されてよく、そして、ルートブロックが図10に続いてさらに分割された後で、コーディングツリー深さは、1だけ増加される。いくつかの実装においては、図10のパターンに従って、パーティション分割ツリーの次のレベルへと再帰的なパーティション分割するために、1010のオールスクェア（all-square）パーティションのみが許可されてよい。別の言葉で言えば、パターン1002、1004、1006、および1006を有する正方形パーティションに対して、再帰パーティションが許可されないことがある。再帰を伴う図10に続くパーティション分割は、必要であれば、コーディングブロックの最終セットを生成する。そうしたスキームは、１つ以上のカラーチャネルに適用され得る。
【0093】
ベースブロックを上記のパーティション分割プロシージャまたは他の手順のいずれかに従って分割またはパーティション分割した後、再度、パーティションまたはコーディングブロックの最終セットが獲得されてよい。これらのパーティションそれぞれは、様々なパーティション分割レベルの１つである。各パーティションは、コーディングブロック(CB)と称される。上記の様々な例示的なパーティション分割の実装について、結果として得られる各CBは、任意の許容されるサイズおよびパーティション分割レベルあってよい。それらは、コーディングブロックと称される。それらは、いくつかの基本的なコーディング／デコーディング決定が為され得るユニットを形成することができ、そして、コーディング／デコーディングパラメータが、コード化ビデオビットストリームにおいて最適化され、決定され、信号化され得るからである。最終的なパーティションにおける最高レベルは、コーディングブロックパーティション分割ツリーの深さを表している。コーディングブロックは、ルマコーディングブロックまたはクロマコーディングブロックであってよい。
【0094】
いくつかの他の例において、四分木構造が、ベースのルマおよびクロマブロックを再帰的にコーディングユニットへと分割するために使用されてよい。そうした分割構造は、コーディングツリーユニット(CTU)と称することができ、これは、パーティション分割をベースのCTUの様々なローカル特性に適応させるために、四分木構造を使用することにより、コーディングユニット(CU)へと分割される。そうした実装においては、サイズがピクチャ境界に適合（fit）するまで、ブロックが四分木分割を維持するように、暗黙の四分木分割がピクチャ境界で実行されてよい。用語CUは、ルマおよびクロマコーディングブロック(CB)のユニットを総称するために使用される。
【0095】
いくつかの実装において、CBはさらにパーティション分割され得る。例えば、CBは、コーディングおよびデコーディングプロセスの最中のイントラフレームまたはインターフレーム予測の目的のために、複数の予測ブロック（PB）へとさらにパーティション分割されてよい。別の言葉で言えば、CBは、異なるサブパーティションへとさらに分割され、そこで、個々の予測決定／構成が行われ得る。並行して、CBは、ビデオデータの変換または逆変換が実行されるレベルを表現する目的のために、複数の変換ブロックへとさらにパーティション分割される。PBおよびTBへのCBのパーティション分割スキームは、同じであってよく、または、そうでなくてよい。例として、各パーティション分割スキームは、例えば、ビデオデータの様々な特性に基づいて、それ自身のプロシージャを使用して実行されてよい。PBおよびTBのパーティション分割スキームは、いくつかの例示的な実装において、独立し得る。PBおよびTBのパーティション分割スキームおよび境界は、いくつかの他の例示的な実装において相関させることができる。いくつかの実装において、例えば、TBは、PBパーティション分割の後でパーティション分割されてよく、そして、特に、各PBは、コーディングブロックの次のパーティションが決定された後、１つ以上のTBへとさらに分割され得る。例えば、いくつかの実装において、PBは１個、2個、4個、または他の個数のTBへと分割され得る。
【0096】
いくつかの実装において、ベースブロックを、コーディングブロへと、そして、さらに予測ブロック及び／又は変換ブロックへとパーティション分割するために、ルマチャネルおよびクロマチャネルは、異なって処理されてよい。例えば、いくつかの実装において、コーディングブロックの予測ブロック及び／又は変換ブロックへのパーティション分割がルマチャネルについて許可されてよいが、一方、そうしたコーディングブロックの予測ブロック及び／又は変換ブロックへのパーティション分割がクロマチャネルについて許可されなくてよい。そうした実装において、ルマブロックの変換及び／又は予測は、従って、コーディングブロックレベルでのみ実行され得る。別の例において、ルマチャネルとおよびクロマチャネルの最小変換ブロックサイズは、異なってよい。例えば、ルマチャネルのコーディングブロックは、クロマチャネルよりも小さな変換ブロック及び／又は予測ブロックへとパーティション分割されることが許容され得る。さらに別の例において、コーディングブロックの変換ブロック及び／又は予測ブロックへのパーティション分割の最大深さは、ルマチャネルおよびクロマチャネルとの間で異なってよい。例えば、ルマチャネルのコーディングブロックは、クロマチャネルよりも深い変換及び／又は予測ブロックへとパーティション分割されることが許容され得る。特定の例において、ルマコーディングブロックは、最大2レベルまで下がる再帰的なパーティションによって表現され得る、複数のサイズの変換ブロックへと分割されてよく、そして、正方形といった変換ブロック形状、2:1/1:2、および4:1/1:4、そして、4×4から64×64への変換ブロックサイズが許可され得る。しかしながら、クロマブロックについては、ルマブロックに対して指定された最大の可能な変換ブロックのみが許可され得る。
【0097】
コーディングブロックをPBへとパーティション分割するためのいくつかの例示的な実装において、PBパーティション分割の深さ、形状、及び／又は、他の特性は、PBがイントラコード化であるか、または、インターコード化であるかに依存し得る。
【0098】
コーディングブロック(または予測ブロック)の変換ブロックへのパーティション分割は、これらに限定されるわけではないが、再帰的または非再帰的に、そして、コーディングブロックまたは予測ブロックの境界での変換ブロックについて追加的に考慮した、四分木分割および所定のパターン分割を含む、様々な例示的なスキームで実装され得る。一般的に、結果として生じる変換ブロックは、異なる分割レベルであってよく、同じサイズでなくてよく、そして、正方形の形状である必要がなくてよい(例えば、それらは、許容されるサイズおよびアスペクト比を有する矩形であり得る)。
【0099】
いくつかの実装において、コーディングパーティション分割ツリースキームまたは構造が使用されてよい。ルマチャネルおよびクロマチャネルのために使用されるコーディングパーティション分割ツリースキームは、同じである必要がなくてよい。別の言葉で言えば、ルマチャネルおよびクロマチャネルは、別個のコーディングツリー構造を有し得る。さらに、ルマチャネルおよびクロマチャネルが、同一または異なるコーディングパーティション分割ツリー構造を使用しているか否か、および、使用される実際のコーディングパーティション分割ツリー構造は、コード化されるスライスがP、B、またはIスライスであるか否かに依存し得る。例えば、Iスライスについて、クロマチャネルおよびルマチャネルは、別々のコーディングパーティション分割ツリー構造またはコーディングパーティション分割ツリー構造モードを有することができ、一方で、PまたはBスライスについて、ルマおよびクロマチャネルは、同じコーディングパーティション分割ツリースキームを共有し得る。別々のコーディングパーティション分割ツリー構造またはモードが適用される場合、ルマチャネルは、１つのコーディングパーティション分割ツリー構造によってCBへとパーティション分割され、そして、クロマチャネルは、別のコーディングパーティション分割ツリー構造によってクロマCBへとパーティション分割され得る。
【0100】
コーディングブロックおよび変換ブロックのパーティション分割の具体的な例示的な実装が以下で説明される。そうした例示的な実装において、ベースコーディングブロックは、上述した再帰的四分木分割を使用してコーディングブロックへと分割され得る。各レベルにおいて、特定のパーティションの更なる四分木分割を継続すべきか否かは、ローカルビデオデータ特性によって決定され得る。結果として生じるCBは、様々なサイズの、様々な四分木分割レベルであり得る。インターピクチャ(時間的)またはイントラピクチャ(空間的)予測を使用してピクチャ領域をコード化するか否かの決定は、CBレベル(または、CUレベル、全ての3色チャネルについて)で行うことができる。各CBは、PB分割タイプに従って、１個、2個、4個、または他の個数のPBへと、さらに分割され得る。１つのPBの内部では、同じ予測プロセスが適用されてよく、そして、関連情報がPBベースでデコーダに送信される。PBの分割タイプに基づいて予測プロセスを適用することによって残差ブロックを獲得した後、CBが、CBのコーディングツリーに類似した別の四分木構造に従ってTBへとパーティション分割され得る。この特定な実装において、CBまたはTBは、正方形に限定され得るが、必ずしも限定される必要はない。さらに、この特定な実装において、PBは、インター予測のために正方形または長方形の形状であってよく、そして、イントラ予測のために正方形だけであってよい。コーディングブロックは、例えば、4個の正方形のTBへと、さらに、分割され得る。各TBは、再帰的に(四分木分割を使用して)より小さなTB、残差四分木（Residual Quad-Tree、RQT)と称されるもの、へと、さらに分割され得る。
【0101】
ベースコード化ブロックをCB、および、他のPB及び／又はTBへとパーティション分割するための別の具体的な例が以下で説明される。例えば、図10に示されてものといった、複数のパーティションユニットタイプを使用するのではなく、むしろ、二値（binary）分割および三値（ternary）分割セグメンテーション構造を使用する、ネストされたマルチタイプのツリーを有する四分木を使用することができる。CB、PB、およびTBの概念の分離(すなわち、CBをPB及び／又はTBへとパーティション分割すること、および、PBをTBへとパーティション分割すること)は、最大変換長に対して大き過ぎるサイズを有するCBについて必要とされる場合を除き、放棄されることがあり、そうしたCBは、さらなる分割を必要とし得る。この例示的な部分化（portioning）スキームは、予測および変換の両方が、さらなる分割なしにCBレベルで実行され得るように、CBのパーティション分割形状に対してよりフレキシビリティをサポートするように設計され得る。そうしたコーディングツリー構造において、CBは、正方形または長方形のいずれかの形状を有し得る。具体的には、コーディングツリーブロック(CTB)は、最初に、四分木構造によって分割される。次いで、四分木リーフノードは、マルチタイプツリー構造によってさらにパーティション分割され得る。マルチタイプツリー構造の一つの例が図11に示されている。具体的には、図11の例示的なマルチタイプツリー構造は、4個の分割タイプを含んでいる。垂直二値分割(SPLIT_BT_VER)(1102)、水平二値分割(SPLIT_BT_HOR)(1104)、垂直三値分割(SPLIT_TT_VER)(1106)、水平三値分割(SPLIT_TT_HOR)(1108)と称されるものである。CBは、次いで、マルチタイプツリーのリーフに対応する。この例示的な実装においては、CBが最大変換長に対して大き過ぎなければ、このセグメンテーションは、任意のさらなるパーティション分割なしで、予測および変換処理の両方について使用される。このことは、ほとんどの場合、CB、PB、およびTBが、ネストされたマルチタイプのツリーコーディングブロック構造を持つ四分木において、同じブロックサイズを有することを意味する。例外は、サポートされる変換長の最大値がCBの色成分の幅または高さよりも小さい場合に発生する。
【0102】
１つのCTBに対するブロックパーティションのネストされたマルチタイプのツリーコーディングブロック構造を有する四分木について一つの例が図12に示されている。より詳細には、図12は、CTB1200が4個の正方形パーティション1202、1204、1206、および1208へと四分木分割されていることを示している。分割のために図11のマルチタイプツリー構造をさらに使用する決定が、四分木分割パーティションそれぞれに対して行われる。図12の例において、パーティション1204は、それ以上分割されない。パーティション1202および1208は、それぞれ、別の四分木分割を採用する。パーティション1202について、第２レベルの四分木分割された左上（top-left）、右上（top-right）、左下（bottom-left）、および右下（bottom-right）のパーティションは、それぞれ、図11の1104、非分割、および図11の1108である、第3レベルの分割を採用している。パーティション1208は、別の四分木分割を採用しており、そして、第２レベルの四分木分割の左上、右上、左下、および右下パーティションは、それぞれ、図11の1106、非分割、および図11の1104、第3のレベル分割を採用している。1208の第3レベルの左上のパーティションの2個のサブパーティションは、1104および1108に従ってさらに分割されている。パーティション1206は、2つのパーティションへの図11の1102に続く第２レベル分割パターンを採用し、図11の1108および1102に従って第3レベルにおいてさらに分割される。第4のレベル分割が、さらに、図11の1104に従って、それらのうち１つに適用される。
【0103】
上記の特定な例において、最大ルマ変換サイズは64×64であってよく、そして、サポートされる最大クロマ変換サイズは、例えば、32×32で、ルマと異なり得る。ルマコーディングブロックまたはクロマコーディングブロックの幅または高さが、最大変換幅または高さよりも大きい場合、ルマコーディングブロックまたはクロマコーディングブロックは、その方向における変換サイズの制限を満たすように、自動的に水平方向及び／又は垂直方向において分割される。
【0104】
ベースコーディングブロックを上記のCBへとパーティション分割する特定の例において、コーディングツリースキームは、ルマとクロマが別々のブロックツリー構造を有する能力をサポートすることができる。例えば、PおよびBスライスについて、１つのCTUにおけるルマCTBおよびクロマCTBは、同じコーディングツリー構造を共有することができる。例えば、Iスライスについて、ルマおよびクロマは、別個のコーディングブロックツリー構造を有し得る。個別のブロックツリーモードが適用される場合、ルマCTBは、１つのコーディングツリー構造によってルマCBへとパーティション分割され、そして、クロマCTBは、別のコーディングツリー構造によってクロマCBへとパーティション分割される。このことは、IスライスのCUが、ルマ成分のコーディングブロック、または、2個のクロマ成分のコーディングブロックで構成されている可能性があり、そして、PまたはBスライスにおけるCUは、ビデオがモノクロでなければ、常に、3個の色成分全てのコーディングブロックで構成されていることを意味する。
【0105】
コーディングブロックまたは予測ブロックを変換ブロックへと分割するための例示的な実装、および、変換ブロックのコーディング順序が、以下でさらに詳細に説明される。いくつかの例示的な実装において、変換パーティション分割は、複数形状の変換ブロック、例えば、1:1(正方形)、1:2/2:1、および1:4/4:1、をサポートすることができ、変換ブロックサイズは、例えば、4×4から64×64までの範囲である。いくつかの実装形態において、コーディングブロックが64×64以下である場合、変換ブロックパーティション分割は、ルマ成分にのみ適用可能であり、クロマブロックについて、変換ブロックサイズはコーディングブロックのサイズと同一である。そうでなければ、コーディングブロックの幅または高さが64より大きい場合には、ルマおよびクロマコーディングブロックの両方が、それぞれに、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)変換ブロックの複数個へと暗黙的に分割され得る。
【0106】
いくつかの例示的な実装において、イントラおよびインターコーディングブロックの両方について、コーディングブロックは、事前定義された数のレベル(例えば、2レベル)までのパーティション分割深さを有する複数の変換ブロックへと、さらに分割され得る。変換ブロックパーティション分割の深さおよびサイズは、関連し得る。現在深さの変換サイズ（Transform size of current depth）から次の深さの変換サイズ（Transform size of next depth）へのマッピングの一つの例が表1に示されている。
表１：変換パーティションサイズ設定
【表1】
【0107】
表1の例示的なマッピングに基づいて、1:1正方形ブロックについて、次のレベル変換分割は、4個の1:1の正方形サブ変換ブロックを生成し得る。変換パーティションは、例えば4×4で停止してよい。従って、現在深さ4×4の変換サイズは、次の深さ4×4の同じサイズに対応する。表1の例において、1:2/2:1の非正方形ブロックについて、次のレベル変換分割は、2個の1:1正方形サブ変換ブロックを生成するが、一方で、1:4/4:1の非正方形ブロックについて、次のレベル変換分割は、2個の1:2/2:1のサブ変換ブロックを生成する。
【0108】
いくつかの例示的な実装において、イントラコード化ブロックのルマ成分について、追加の制限が適用され得る。例えば、変換パーティション分割の各レベルについて、全てのサブ変換ブロックは、等しいサイズを有するように制限され得る。例えば、32×16のコーディングブロックについて、レベル1の変換分割は2個の16×16のサブ変換ブロックを作成し、レベル2の変換分割は8個の8×8のサブ変換ブロックを作成する。別の言葉で言えば、第２レベルの分割は、変換ユニットを等しいサイズに維持するために、全ての第１レベルサブブロックに適用されなければならない。表1に続くイントラコード化正方形ブロックに対する変換ブロックパーティション分割の一つの例が、矢印によって示されるコーディング順序と共に、図13に示されている。具体的に、1302は、正方形コーディングブロックを示している。表1に従った、4個の等しいサイズの変換ブロックへの第１レベルの分割は、矢印で示されたコーディング順序で1304に示されている。表1に従った、全ての第１レベルの等しいサイズのブロックの16個の等しいサイズの変換ブロックへの第２レベルの分割は、矢印で示されたコーディング順序で1306に示されている。
【0109】
いくつかの例示的な実装において、インターコード化ブロックのルマ成分について、イントラコーディングに対する上記の制限は適用されなくてよい。例えば、変換分割の第１レベルの後で、サブ変換ブロックのいずれか１つが、もう１つのレベルで独立してさらに分割されてよい。結果として生じた変換ブロックは、従って、同じサイズであっても、または、なくてもよい。コーディング順序を用いた変換ブロックへのインターコード化ブロックの例示的な分割が図14に示されている。図14の例において、インターコード化ブロック1402は、表1に従って、2つのレベルで変換ブロックへと分割される。第１レベルにおいて、インターコード化ブロックは等しいサイズの4個の変換ブロックへと分割される。次いで、4個の変換ブロックのうちの１つだけ(全てではない)が、さらに4個のサブ変換ブロックへと分割され、1404で示されるように、2つの異なるサイズを有する合計7個の変換ブロックを結果として生じる。これら7個の変換ブロックの例示的なコーディング順序が、図14の1404において矢印で示されている。
【0110】
いくつかの例示的な実装において、クロマ成分について、変換ブロックに対するいくつかの追加の制限が適用され得る。例えば、クロマ成分について、変換ブロックサイズは、コーディングブロックサイズと同じ大きさであってよいが、事前定義されたサイズ、例えば、8×8より小さくはない。
【0111】
いくつかの他の例示的な実装において、幅(W)または高さ(H)のいずれかが64より大きいコーディングブロックについて、ルマおよびクロマの両方のコーディングブロックは、それぞれに、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)変換ユニットの複数個へと暗黙的に分割され得る。
【0112】
図15は、さらに、コーディングブロックまたは予測ブロックを変換ブロックへとパーティション分割するための代替の例示的なスキームを示している。図15に示されるように、再帰的な変換パーティション分割を使用する代わりに、コーディングブロックの変換タイプに従って、パーティション分割タイプの事前定義されたセットが、コーディングブロックに適用され得る。図15に示される特定の例においては、コーディングブロックを様々な数の変換ブロックへと分割するために6個の例示的なパーティション分割タイプの１つが適用され得る。そうしたスキームは、コーディングブロックまたは予測ブロックのいずれかに適用され得る。
【0113】
より詳細には、図15のパーティション分割スキームは、図15に示されるように、任意の所与の変換タイプについて最大6個のパーティション分割タイプを提供する。このスキームにおいて、全てのコーディングブロックまたは予測ブロックは、例えば、レート歪みコストに基づいて、変換タイプが割り当てられてよい。一つの例において、コーディングブロックまたは予測ブロックに割り当てられるパーティション分割タイプは、コーディングブロックまたは予測ブロックの変換パーティション分割タイプに基づいて決定され得る。特定のパーティション分割タイプは、図15に示される4個のパーティション分割タイプによって示されるように、変換ブロック分割サイズおよびパターン(またはパーティション分割タイプ)に対応し得る。様々な変換タイプと様々なパーティション分割タイプとの間の対応関係は、事前定義され得る。一つの例示的な対応が以下に示されており、大文字のラベルは、レート歪みコストに基づいてコーディングブロックまたは予測ブロックに割り当てることができる変換タイプを示している。
【0114】
・PARTITION_NONE:ブロックサイズに等しい変換サイズを割り当てる。
【0115】
・PARTITION_SPLIT:ブロックサイズの幅の1/2、かつ、ブロックサイズの高さの1/2の変換サイズを割り当てる。
【0116】
P・ARTITION_HORZ:ブロックサイズと同じ幅、かつ、ブロックサイズの高さの1/2の変換サイズを割り当てる。
【0117】
・PARTITION_VERT:ブロックサイズの幅の1/2、かつ、ブロックサイズと同じ高さの変換サイズを割り当てる。
【0118】
・PARTITION_HORZ4:ブロックサイズと同じ幅、かつ、ブロックサイズの高さの1/4の変換サイズを割り当てる。
【0119】
・PARTITION_VERT4:ブロックサイズの幅の1/4、かつ、ブロックサイズと同じ高さの変換サイズを割り当てる。
【0120】
上記の例において、図15に示されるようなパーティション分割タイプは全て、パーティション分割された変換ブロックについて均一な変換サイズを含んでいる。これは単なる例示であって、限定ではない。いくつかの他の実装においては、ミックスされた変換ブロックサイズが、特定のパーティション分割タイプ(または、パターン)でパーティション分割された変換ブロックについて使用されてよい。
【0121】
様々な実施形態においては、セミ・デカップリングパーティション分割(semi decoupled partitioning、SDP)スキームが使用され得る。ここで、１つのスーパーブロック(super block、SB)におけるルマおよびクロマブロックは、同一または異なるブロックパーティション分割構造を有し得る。SDPスキームは、また、セミ・セパレートツリー(semi separate tree、SST)またはクロマ成分に対するフレキシブルなブロックパーティション分割とも呼ばれてよい。
【0122】
いくつかの実装において、SDPスキームは、ルマコード化ブロックのサイズ、または、ルマブロックパーティション分割ツリーの深さに依存し得る。例えば、ルマブロックのサイズ(例えば、面積について)が第１閾値(T1)より大きい場合、または、ルマブロックのコーディングツリー分割深さが第２閾値(T2)以下である場合、クロマブロックは、ルマブロックと同じコーディングツリー構造を使用し得る。
【0123】
そうでなければ、ルマブロックのサイズがT1以下である場合、または、ルマ分割深さがT2より大きい場合、対応するクロマブロックは、ルマ成分とは異なるコーディングブロックパーティション分割を有し得る。これは、クロマ成分に対するフレキシブルなブロックパーティション分割と呼ばれる。いくつかの実装において、T1は正の整数であり、例えば、これらに限定されるわけではないが、128または256である。T2は正の整数であり、例えば、限定されるわけではないが、1または2である。
【0124】
図16は、ルマ成分(1610)およびクロマ成分(1650)について異なるコーディングブロックパーティション分割構造の一つの例を示している。ここで、T2は、1に設定されている。第１レベル(レベル=1)では、ルマ成分およびクロマ成分が、同じ構造を有している。第２レベル(レベル=2)では、ルマ成分におけるいくつかのレベル1ブロックおよびクロマ成分におけるいくつかのレベル1ブロックは、同じ構造を有している。例えば、それぞれに、1611と1651、1641と168である。そして、ルマ成分におけるいくつかのレベル1ブロックおよびクロマ成分におけるいくつかのレベル1ブロックは、異なる構造を有している。例えば、それぞれに、1621と1661、1631と1671である。
【0125】
様々な実施形態においては、改善されたセミ・デカップリングパーティション分割(SDP)スキームが使用され得る。ここで、ルマ成分およびクロマ成分は、スーパーブロックのルートノードからの部分的ツリー構造を共有することができ、そして、ルマおよびクロマが分離ツリーパーティション分割を開始するときの条件は、ルマのパーティション分割情報に依存する。
【0126】
セミ・デカップリングパーティション分割の実装に関連する、いくつかの問題／問題点が存在し得る。例えば、いくつかの実施において、クロマ成分は、変換パーティション分割を可能にしなくてよく、すなわち、変換ユニットサイズは、コーディングユニットサイズと同じである。ルマ成分とクロマ成分が異なるコーディングブロックパーティション分割ツリーを使用する場合、クロマ成分は、典型的に、より大きなパーティション分割サイズが好ましくあってよく、かつ／あるいは、別々に信号化されている場合、クロマ成分について変換分割が有益であり得る。
【0127】
本開示は、ビデオコーディング及び／又はデコーディングにおける変換ブロックパーティション分割のための様々な実施形態を説明しており、上述の問題／問題点のうち少なくとも１つに対処している。
【0128】
様々な実施形態において、図17を参照すると、方法1700は、ビデオデコーディングにおいて変換ブロックパーティション分割のためのものである。方法1700は、以下のステップの一部または全部を含んでよい。ステップ1710では、命令を保管しているメモリ、および、メモリと通信するプロセッサを含むデバイスによって、ルマブロックおよびクロマブロックについてコード化ビデオビットストリームを受信し、ルマブロックはクロマブロックと共配置されている。ステップ1720では、ルマコーディングブロックパーティション分割ツリーを獲得するために、デバイスによって、ルマブロックをパーティション分割する。ステップ1730では、クロマコーディングブロックパーティション分割ツリーを獲得するために、デバイスによって、クロマブロックをパーティション分割する。ステップ1740では、複数のルマ変換ブロックを獲得するために、デバイスによって、ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割する。及び／又は、ステップ1750では、少なくとも１つの複数のクロマ変換ブロックを獲得するために、デバイスによって、クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割する。
【0129】
いくつかの実装において、デバイスは、ルマコーディングブロックおよびクロマコーディングブロックを別々にパーティション分割してよく、そして、獲得された複数のルマ変換ブロックは、獲得された少なくとも１つの複数のクロマ変換ブロックのうちいずれか１つとは異なっている。
【0130】
他の実装において、デバイスは、ルマコーディングブロックおよびクロマコーディングブロックを別々にパーティション分割してよくそして、獲得された複数のルマ変換ブロックは、獲得された少なくとも１つの複数のクロマ変換ブロックのうちの１つと同じである。
【0131】
本開示における様々な実施形態において、ブロックのサイズ(例えば、限定されるわけではないが、コーディングブロック、予測ブロック、または、変換ブロック)は、ブロックの幅または高さを参照し得る。ブロックの幅または高さは、ピクセルの単位で整数であってよい。
【0132】
本開示における様々な実施形態において、ブロックのサイズ(例えば、限定されるわけではないが、コーディングブロック、予測ブロック、または、変換ブロック)は、ブロックの面積サイズ（area size）を参照し得る。ブロックの面積サイズは、ブロックの幅にピクセルの単位でブロックの高さを乗じた整数であってよい。
【0133】
本開示におけるいくつかの様々な実施形態において、ブロック(例えば、限定されるわけではないが、コーディングブロック、予測ブロック、または、変換ブロック)のサイズは、ブロックの幅または高さの最大値、ブロックの幅または高さの最小値、または、ブロックのアスペクト比を参照し得る。ブロックのアスペクト比は、幅をブロックの高さで割ったものとして計算されてよく、または、高さをブロックの幅で割ったものとして計算されてよい。
【0134】
本開示の様々な実施形態において、スーパーブロック(SB)は、最大コーディングユニット(LCU)、例えば、128×128ブロックを参照し得る。ルマブロックは、クロマブロックと共配置されたルマブロックを参照し得る。セミ・デカップリングパーティション分割(SDP)は、また、セミ・デカップリングツリー(SDT)としても参照され得る。ブロック分割（splitting）は、また、ブロックパーティション分割（partitioning）としても参照され得る。
【0135】
ステップ1710を参照すると、デバイスは、図5における電子デバイス(530)、または、図8におけるビデオデコーダ(810)であってよい。いくつかの実装形態において、デバイスは、図6におけるエンコーダ(620)内のデコーダ(633)であってよい。他の実装において、デバイスは、図5における電子デバイス(530)の一部、図8におけるビデオデコーダ(810)の一部、または、図6におけるエンコーダ(620)内のデコーダ(633)の一部であってよい。コード化ビデオビットストリームは、図8におけるコード化ビデオシーケンス、もしくは、図6または7における中間コード化データであってよい。コード化ビデオビットストリームは、ルマブロック(例えば、図18における1810)およびクロマブロック(例えば、図18における1850)のためのものであってよく、そして、ルマブロックおよびクロマブロックは、相互に共配置されている。
【0136】
いくつかの実装においては、異なる色成分、例えば、ルマ成分およびクロマ成分、について、別々の変換ユニット分割および信号化が適用され得る。クロマ成分は、１つ以上の色成分、例えば、第１色成分(青色)および第２色成分(赤色)を含み得る。
【0137】
図18は、コーディングブロックパーティション分割が異なる場合に別個の変換ユニット分割を適用する一つの例を示している。ここで、実線はコーディングブロックパーティション分割境界を示し、そして、点線は変換ユニットパーティション分割境界を示している。ルマブロック(1810)は、レベル1における、1811、1821、1831、および1841を含む。クロマブロック(1850)には、レベル1において、1851、1861、1871、および1881を含む。図18は、コーディングブロックパーティション分割(実線)パターンが、ルマ成分とクロマ成分との間で異なっている。例えば、1811と1851、および、1821と1861、並びに、1841と1881である。一方で、変換ブロックパーティション分割(破線)は、ルマおよびクロマの両方に対して可能であるが、異なる分割パターンを有している。例えば、1821と1861である。
【0138】
ステップ1720を参照すると、デバイスは、ルマコーディングブロックパーティション分割ツリーを獲得するために、ルマブロックをパーティション分割し得る。図18を参照すると、ルマブロック(1810)は、1810において実線で示される、ルマコーディングブロックパーティション分割ツリーを獲得するためにパーティション分割されている。
【0139】
ステップ1730を参照すると、デバイスは、クロマコーディングブロックパーティション分割ツリーを獲得するために、クロマブロックをパーティション分割し得る。図18を参照すると、クロマブロック(1850)は、1850において実線で示される、クロマコーディングブロックパーティション分割ツリーを獲得するためにパーティション分割されている。
【0140】
ステップ1740を参照すると、デバイスは、複数のルマ変換ブロックを獲得するために、ルマコーディングブロックパーティション分割ツリーからルマコーディングブロックをパーティション分割し得る。1810内のいくつかのルマコーディングブロックは、1810内の破線で示されるように、複数のルマ変換ブロックへとさらにパーティション分割されている。例えば、ルマコーディングブロック(1811内の上半分)は、2個のルマ変換ブロック(1812、および1813)へとパーティション分割されている。別の例として、ルマコーディングブロック(1831)は、4個のルマ変換ブロック(1832、1833、1834、および1835)へとパーティション分割されている。
【0141】
ステップ1750を参照すると、デバイスは、少なくとも１つの複数のクロマ変換ブロックを獲得するために、クロマコーディングブロックパーティション分割ツリーからクロマコーディングブロックをパーティション分割し得る。1850内いくつかのルマコーディングブロックは、1850内の破線で示されるように、複数のルマ変換ブロックへとさらにパーティション分割されている。例えば、クロマコーディングブロック(1861内の右半分)は、2個のクロマ変換ブロック(1863および1864)にパーティション分割されている。別の例として、クロマコーディングブロック(1871)は、4個のクロマ変換ブロック(1872、1873、1874、および1875)へとパーティション分割されている。
【0142】
様々な実施形態において、ルマコーディングブロックパーティション分割ツリーは、クロマコーディングブロックパーティション分割ツリーとは異なっており、かつ／あるいは、コード化ビデオビットストリームは、ルマパラメータおよびクロマパラメータを含んでいる。ルマパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、ルマコーディングブロック及び／又は複数のルマ変換ブロックからの変換パーティション分割構造を示し得る。クロマパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、クロマコーディングブロック及び／又は複数のクロマ変換ブロックからの変換パーティション分割構造を示し得る。
【0143】
ステップ1740は、複数のルマ変換ブロックを獲得するために、ルマパラメータに従って、ルマコーディングブロックをパーティション分割することを含んでよく、かつ／あるいは、ステップ1750は、複数のクロマ変換ブロックを獲得するために、クロマパラメータに従って、クロマコーディングブロックをパーティション分割することを含み得る。
【0144】
いくつかの実装において、ルマカラーチャネルとクロマカラーチャネルが異なるコーディングブロックパーティション分割ツリーを適用する場合、クロマチャネルに対して変換ユニット分割が許容されてよく、そして、ルマチャネルと比較して、クロマチャネルについて別々に変換ユニット分割が信号化され得る。
【0145】
様々な実施形態において、ルマコーディングブロックパーティション分割ツリーは、クロマコーディングブロックパーティション分割ツリーとは異なっており、かつ／あるいは、コード化ビデオビットストリームは、ルマパラメータ、第１クロマパラメータ、および第２クロマパラメータを含む。ルマパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、ルマコーディングブロック及び／又は複数のルマ変換ブロックからの変換パーティション分割構造を示し得る。第１クロマパラメータは、クロマ成分における第１色(例えば、青)に対応しており、かつ、第２クロマパラメータは、クロマ成分における第２色(例えば赤)に対応している。第１クロマパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、クロマコーディングブロック及び／又はクロマ成分における第１色に対する複数のクロマ変換ブロックからの変換パーティション分割構造を示し得る。第２クロマパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、クロマコーディングブロック及び／又はクロマ成分における第２色に対する複数のクロマ変換ブロックからの変換パーティション分割構造を示し得る。第１色および第２色に対する変換パーティション分割構造は、異なってよい。
【0146】
ステップ1740は、複数のルマ変換ブロックを獲得するために、ルマパラメータに従って、ルマコーディングブロックをパーティション分割することを含み得る。ステップ1750は、第１複数のクロマ変換ブロックを獲得するために、第１クロマパラメータに従って、第１クロマコーディングブロックの第１構成要素をパーティション分割すること、及び／又は、第２複数のクロマ変換ブロックを獲得するために、第２クロマパラメータに従って、第２クロマコーディングブロックの第２構成要素をパーティション分割することを含み得る。クロマコーディングブロックの第１構成要素は、コーディングブロックの第１カラーチャネル(例えば、青)を参照してよく、かつ／あるいは、クロマコーディングブロックの第２構成要素は、コーディングブロックの第２カラーチャネル(例えば、赤)を参照し得る。
【0147】
いくつかの実装において、ルマカラーチャネルおよびクロマカラーチャネルが異なるコーディングブロックパーティション分割ツリーを適用する場合、クロマに対して変換ユニット分割が許容され、そして、変換ユニット分割は、クロマの異なる色成分、例えば、CbおよびCr、に対して別々に信号化され得る。
【0148】
いくつかの他の実装において、色成分が異なるコーディングブロックパーティション分割ツリーを適用する場合、各色成分に対して変換ユニット分割が許容され、そして、変換ユニット分割は、各色成分に対して別々に信号化され得る。
【0149】
様々な実施形態において、クロマコーディングブロックの変換深さは、0または1を含み、かつ／あるいは、クロマコーディングブロックは、四分木変換分割を含み、かつ／あるいは、非正方形矩形ブロックであるクロマコーディングブロックは、二値変換分割を示している。
【0150】
いくつかの実装において、異なる色成分について、異なる変換ユニットパーティション分割パターン及び／又は深さが適用されてよい。一つの例において、クロマチャネルまたは成分について、変換深さが0または1に制限され得る。別の例において、クロマチャネルまたは構成要素の場合、四分木変換分割のみが許可される。別の例において、クロマチャネルまたは成分について、非正方形矩形ブロックに対して、二値変換分割だけ許容される。別の例において、水平二値変換分割または垂直二値変換分割が適用されるか否かは、コーディングブロックのアスペクト比に依存する。コーディングブロックのアスペクト比が1より大きい場合(例えば、水平ディメンションがコーディングブロックの垂直ディメンションより長い)、垂直二値変換分割が使用されてよく、コーディングブロックのアスペクト比が1より小さい場合(例えば、水平ディメンションがコーディングブロックの垂直ディメンションより短い)、コーディングブロックに対して水平二値変換分割が使用されてよい。
【0151】
様々な実施形態において、ステップ1750は、少なくとも１つの複数のクロマ変換ブロックを獲得するために、以下の条件のうち少なくとも１つを満たしていることに応答して、クロマコーディングブロックをパーティション分割することを含み得る。クロマコーディングブロックが最小コーディングブロックサイズより大きいこと、クロマコーディングブロックが最大コーディングブロックサイズより小さいこと、クロマコーディングブロックが少なくとも１つのイントラ予測モードを使用していること、または、クロマコーディングブロックが少なくとも１つの変換タイプを使用していることである。いくつかの実施において、最小コーディングブロックサイズは、以下の4、8、16、32、または64のうち少なくとも１つを含む最小コーディング幅に対応しており、最大コーディングブロックサイズは、以下の32、64、128、または256のうち少なくとも１つを含む最大コーディング長さに対応しており、かつ／あるいは、少なくとも１つのイントラ予測モードは、少なくとも１つの指向性（directional）イントラ予測モードを含む。
【0152】
いくつかの他の実装においては、異なる色成分について、変換分割を許容する最小コーディングブロックサイズが異なってよい。一つの例において、クロマコーディングブロックがM×Nより小さい場合、変換ユニット分割は許可されない。MおよびNの値の例は、これらに限定されないが、4、8、16、32、64を含む。
【0153】
他のいくつかの実装においては、異なる色成分について、変換分割を許容する最大コーディングブロックサイズが異なってよい。
【0154】
いくつかの他の実装において、M×Nより大きいサイズを有するクロマコーディングブロックについて、変換ユニット分割は許容されなくてよい。MおよびNの値の例は、これらに限定されないが、32、64、128、256を含む。
【0155】
いくつかの他の実装においては、イントラコード化ブロックについて、ルマカラーチャネルとクロマカラーチャネルが異なるコーディングブロックパーティション分割ツリーを適用する場合、クロマカラーチャネルにおける変換ユニット分割は、所定のイントラ予測モードに対してのみ許容され得る。一つの例において、クロマカラーチャネルにおけるクロマコーディングブロック内の変換ユニット分割は、指向性イントラ予測モードに対してのみ許容され得る。
【0156】
いくつかの他の実装において、クロマ内の変換ユニット分割が許容される場合、所定の変換タイプのみが許容される。
【0157】
様々な実施形態において、コード化ビデオビットストリームは、ルマコーディングパラメータ、ルマ変換パラメータ、クロマコーディングパラメータ、およびクロマ変換パラメータを含み、かつ／あるいは、コード化ビデオビットストリームのエントロピー復号の最中に、クロマ変換パラメータは、ルマコーディングパラメータ、ルマ変換パラメータ、またはクロマコーディングパラメータのうち少なくとも１つをコンテキストとして使用する。
【0158】
ルマコーディングパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、ルマ成分のコーディングブロックパーティション分割構造を示し得る。ルマ変換パラメータは、コード化ビデオビットストリームから抽出されてよく、そして、ルマコーディングブロック及び／又は複数のルマ変換ブロックからの変換パーティション分割構造を示し得る。クロマコーディングパラメータは、コード化ビデオビットストリームから抽出されてよく、そして、クロマ成分のコーディングブロックパーティション分割構造を示し得る。クロマ変換パラメータは、コード化ビデオビットストリームから抽出されてよく、そして、クロマコーディングブロック及び／又は複数のクロマ変換ブロックからの変換パーティション分割構造を示し得る。
【0159】
いくつかの他の実装においては、クロマ変換ブロックパーティション分割パターンを信号化するために、ルマコーディングブロックパーティション分割フラグ及び／又は変換ブロック分割フラグが、クロマ変換ブロックパーティション分割フラグをエントロピー符号化するためのコンテキストとして使用され得る。
【0160】
様々な実施形態において、クロマ成分内のコード化ブロックからの変換ユニットパーティション分割が許容される場合、全てのクロマ変換ユニットのサイズは、コード化ブロックの中で同一であってよい。一つの例において、フラグは、クロマ成分(または、各クロマチャネル)の変換深さを示すために、コード化ブロックレベルにおいて信号化され得る。別の例において、コード化ブロックにおいてルマ変換ユニットの変換サイズは同一でなくてよいが、一方で、全てのクロマ変換ユニットのサイズは、コード化ブロックの中で同一である。
【0161】
本開示の実施形態は、別々に、または、任意の順序で組み合わされて、使用され得る。さらに、本方法(または実施形態)それぞれ、エンコーダ、およびデコーダは、処理回路(例えば、１つ以上のプロセッサ、または、１つ以上の集積回路)によって実装され得る。一つの例において、１つ以上のプロセッサは、非一時的コンピュータ読取り可能な媒体に保管されたプログラムを実行する。本開示における実施形態は、ルマブロックまたはクロマブロックに適用することができる。そして、クロマブロックにおいて、実施形態は、１つより多い色成分に別々に適用されてよく、または、１つより多い色成分に一緒に適用されてよい。
【0162】
上述の技術は、コンピュータ読取り可能な命令を使用してコンピュータソフトウェアとして実装され、そして、１つ以上のコンピュータ読取り可能な媒体に物理的に保管され得る。例えば、図19は、開示される技術的事項の所定の実施形態を実施するのに適したコンピュータシステム(2600)を示している。
【0163】
コンピュータソフトウェアは、任意の適切なマシンコードまたはコンピュータ言語を使用してコード化され得る。アセンブル、コンパイル、リンク、もしくは、１つ以上のコンピュータ中央処理装置（CPU）、グラフィックス処理装置(GPU),
などによって、直接的、または、インタープリタ、マイクロコード実行、などを通して実行され得る命令を含むコードを作成するための類似のメカニズムの対象となり得るものである。
などによって、直接的、または、インタープリタ、マイクロコード実行、などを通して実行され得る命令を含むコードを作成するための類似のメカニズムの対象となり得るものである。
【0164】
命令は、様々なタイプのコンピュータまたはその構成要素上で実行され得る。例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット、等を含むものである。
【0165】
コンピュータシステム(2600)のための図19に示される構成要素は、本質的に例示的なものであり、そして、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能性の範囲について、いかなる制限も示唆するように意図されたものではない。また、構成要素の構成は、コンピュータシステム(2600)の例示的な実施形態において示される構成要素の任意の１つまたは組み合わせに関して、いかなる従属性または要件も有するものとして解釈されてはならない。
【0166】
コンピュータシステム(2600)は、所定のヒューマンインターフェイス入力デバイスを含み得る。そうしたヒューマンインターフェイス入力装置は、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き、といったもの)、音声入力(声、拍手、といったもの)、視覚入力(ジェスチャ、といったもの)、嗅覚入力(図示なし)を通じて、一人以上の人間ユーザによる入力に対して応答し得る。ヒューマンインターフェイス装置は、また、オーディオ(スピーチ、音楽、環境音、といったもの)、画像(スキャンされた画像、静止画像カメラから獲得した写真画像、といったもの)、ビデオ(2次元ビデオ、立体映像を含む3次元ビデオといったもの)といった、人間による意識的入力に必ずしも直接的に関係しない所定の媒体をキャプチャするためにも使用され得る。
【0167】
入力ヒューマンインターフェイスデバイスは、キーボード(2601)、マウス(2602)、トラックパッド(2603)、タッチスクリーン(2610)、データグローブ(図示なし)、ジョイスティック(2605)、マイクロフォン(2606)、スキャナ(2607)、カメラ(2608)の１つ以上を含み得る（それぞれ１つだけが描かれている）。
【0168】
コンピュータシステム(2600)は、また、所定のヒューマンインターフェイス出力デバイスを含み得る。そうしたヒューマンインターフェイス出力装置は、例えば、触覚出力、音、光、および嗅覚／味覚を通して、一人以上の人間ユーザの感覚を刺激することができる。そうしたヒューマンインターフェイス出力装置は、触覚出力装置(例えば、タッチスクリーン(2610)、データグローブ(図示なし)、またはジョイスティック(2605)、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在する)、オーディオ出力装置(スピーカ(2609)、ヘッドフォン(図示なし)といったもの)、視覚出力装置(CRTスクリーン、LCDスクリーン、プラズマスクリーンを含むスクリーン（2610）といったものであり、それぞれがタッチスクリーン入力能力を有し又は有さず、それぞれが触覚フィードバック能力を有し又は有さない。－そのうちいくつかは、立体画法（stereographic）出力といった手段、仮想現実メガネ(図示なし)、ホログラフィックディスプレイおよびスモーク（smoke）タンク(図示なし)、およびプリンタ(図示なし)、を介して、2次元の視覚出力または3次元以上の出力を出力することができる。)を含み得る。
【0169】
コンピュータシステム(2600)は、また、人間がアクセス可能な記憶装置およびそれらの関連媒体を含むことができる。CD/DVD等の媒体(2621)を伴うCD/DVD ROM/RW(2620)を含む光媒体、サムドライブ（thumb-drive）(2622)、リムーバブルハードドライブまたはソリッドステートドライブ(2623)、テープおよびフロッピー（登録商標）ディスク(図示なし)といった従来の磁気媒体、セキュリティドングル（security dongle）(図示なし)といった特殊化されたROM/ASIC/PLDベースの装置など、といったものである。
【0170】
当業者は、また、現在開示されている技術的事項（subject matter）に関連して使用される用語「コンピュータ読取可能媒体（“computer readable media”）」は、伝送媒体、搬送波、または他の過渡信号を包含しないことも理解すべきである。
【0171】
コンピュータシステム(2600)は、また、１つ以上の通信ネットワーク(2655)へのインターフェイス(2654)も含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性、等であり得る。ネットワークの例は、イーサネットといったローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、および地上放送TVを含むTVワイドエリアまたはワイドエリアデジタルネットワーク、CANバスを含む車両および工業など、を含む。所定のネットワークは、一般的に、所定の汎用データポートまたはペリフェラルバス(2649)に接続される外部ネットワークインターフェイスアダプタ(例えば、コンピュータシステム(2600)のUSBポート、といったもの)を必要とする。他のものは、一般的に、以下で説明するように、システムバスへの取付け（attachment）によって、コンピュータシステム(2600)のコアに統合される(例えば、PCコンピュータシステムへのイーサネットインターフェイス、または、スマートフォンコンピュータシステムへのセルラーネットワークインターフェイス)。これらのネットワークのいずれかを使用して、コンピュータシステム(2600)は、他のエンティティと通信することができる。そうした通信は、単指向性、受信専用(例えば、放送テレビ)、単指向性送信専用(例えば、所定のCANバスデバイスへのCANバス)、または、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの双指向性、であり得る。所定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェイスそれぞれで使用され得る。
【0172】
前述のヒューマンインターフェイスデバイス、人がアクセス可能なストレージデバイス、およびネットワークインターフェイスは、コンピュータシステム(2600)のコア(2640)に取付けることができる。
【0173】
コア(2640)は、１つ以上の中央処理装置(CPU)(2641)、グラフィックス処理装置(GPU)(2642)、フィールドプログラマブルゲートアレイ(FPGA)(2643)の形式の特殊なプログラマブル処理装置、所定のタスクのためのハードウェアアクセラレータ(2644)、グラフィックアダプタ(2650)、などを含むことができる。これらの装置は、リードオンリーメモリ(ROM)(2645)、ランダムアクセスメモリ(2646)、内部非ユーザアクセス可能ハードドライブといった内部大容量ストレージ、SSD、等(2647)と共に、システムバス(2648)を介して接続され得る。いくつかのコンピュータシステムにおいて、システムバス(2648)は、追加のCPU、GPUなどによる拡張を可能にするために、１つ以上の物理的プラグの形式でアクセス可能である。周辺装置は、コアのシステムバス(2648)に直接的に接続されるか、または、ペリフェラルバス(2649)を介して接続され得る。一つの例において、スクリーン(2610)をグラフィックアダプタ(2650)に接続することができる。ペリフェラルバスのアーキテクチャは、PCI、USB、などを含む。
【0174】
CPU(2641)、GPU(2642)、FPGA(2643)、およびアクセラレータ(2644)は、組み合わせて、上述のコンピュータコードを構成することができる、所定の命令を実行することができる。そのコンピュータコードは、ROM(2645)またはRAM(2646)に保管することができる。移行データも、また、RAM(2646)に保管することができるが、一方で、永久データは、例えば、内部大容量ストレージ(2647)に保管することができる。１つ以上のCPU(2641)、GPU(2642)、大容量ストレージ(2647)、ROM(2645)、RAM(2646)、などと密接に関連付けることができる、キャッシュメモリの使用を通じて、メモリデバイスのいずれかへの高速ストレージおよび取出し可能にすることができる。
【0175】
コンピュータ読取可能媒体は、様々なコンピュータ実装されたオペレーションを実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計され、かつ、構築されたものであってよく、または、コンピュータソフトウェア技術の当業者に周知であり、かつ、利用可能な種類のものであってよい。
【0176】
非限定的な例として、アーキテクチャ(2600)を有するコンピュータシステム、および、特にコア(2640)は、１つ以上の有形で、コンピュータ読取可能媒体において具現化されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ、などを含む)の結果として機能性を提供することができる。そうしたコンピュータ読取可能媒体は、上述のようにユーザがアクセス可能な大容量ストレージ、並びに、コア-内部大容量ストレージ(2647)またはROM(2645)といった、非一時的な性質のコア(2640)に係る措定のストレージ、に関連する媒体であってよい。本開示の様々な実施形態を実装するソフトウェアは、そうしたデバイスに保管され、そして、コア(2640)によって実行され得る。コンピュータ読取可能媒体は、特定のニーズに従って、１つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア(2640)、および、具体的にはその中のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM(2646)に保管されたデータ構造を定義すること、および、ソフトウェアによって定義されたプロセスに従って、そうしたデータ構造を修正することを含む、ここにおいて説明された特定のプロセス、または、特定のプロセスの特定部分を実行させることができる。加えて又は代替として、コンピュータシステムは、回路(例えば、アクセラレータ(2644))内で配線され（hardwired）、または他の方法で具現化されたロジックの結果として機能性を提供することができる。これは、ここにおいて説明される特定のプロセスまたは特定のプロセスの特定部分を実行するためのソフトウェアの代わりに、またはソフトウェアと共に動作することができる。ソフトウェアへの参照は、論理を含み、そして、必要に応じて、その逆も同様である。コンピュータ読取可能媒体への参照は、実行のためのソフトウェアを保管する回路（集積回路（IC）といったもの）、実行のためのロジックを具体化する回路、または、必要に応じて、両方を含むことができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含している。
【0177】
特定の発明が例示的な実施形態を参照して説明されてきたが、この説明は限定的であることを意味するものではない。本発明の例示的な実施形態および追加の実施形態の様々な修正が、この説明から当業者にとって明らかだろう。当業者は、本発明の精神および範囲から逸脱することなく、ここにおいて示され、かつ、説明された例示的な実施形態に、これらの及び様々な他の修正が成され得ることを容易に理解するだろう。従って、添付の請求項は、そうした修正および代替の実施形態をカバーすることが期待されている。図中の所定の比率は誇張されてよく、一方、他の比率は最小化されてよい。従って、本開示および図面は、限定的ではなく例示的であるとみなされる。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【外国語明細書】