特表 2023-546962 成分間のブロック終了フラグの符号化

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-11-08

(54)【発明の名称】成分間のブロック終了フラグの符号化

(51)【国際特許分類】

   H04N 19/13 20140101AFI20231031BHJP

   H04N 19/186 20140101ALI20231031BHJP

   H04N 19/70 20140101ALI20231031BHJP

【ＦＩ】

H04N19/13

H04N19/186

H04N19/70

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023525007

(86)(22)【出願日】2022-01-28

(85)【翻訳文提出日】2023-04-25

(86)【国際出願番号】 US2022014289

(87)【国際公開番号】W WO2023003597

(87)【国際公開日】2023-01-26

(31)【優先権主張番号】17/576,255

(32)【優先日】2022-01-14

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

(31)【優先権主張番号】63/225,273

(32)【優先日】2021-07-23

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャオ，シン

(72)【発明者】

【氏名】ペリンガーセリー，クリシュナン マドフ

(72)【発明者】

【氏名】リウ，シャン

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159MA04

5C159MA05

5C159MA21

5C159MC01

5C159MC11

5C159ME01

5C159PP04

5C159PP15

5C159PP16

5C159RC11

5C159TA59

5C159TB08

5C159UA02

5C159UA05

(57)【要約】

デコーダにおいてビデオデータを符号化/復号するための方法、装置及びコンピュータ読み取り可能記憶媒体である。当該方法は、ビデオデータからデータブロックの第1の色成分に関連する第1のブロック終了(EOB)フラグを受信するステップと、ビデオデータのデータブロックの第2の色成分に関連する第2のEOBフラグに基づいて、第1のEOBフラグをエントロピー符号化するためのコンテキストを導出するステップと、導出されたコンテキストに基づいて第1のEOBフラグのエントロピー復号を実行するステップとを含む。

【特許請求の範囲】

【請求項1】

デコーダがビデオデータを復号するための方法であって、
前記ビデオデータからデータブロックの第1の色成分に関連する第1のブロック終了(EOB)フラグを受信するステップと、
前記ビデオデータの前記データブロックの第2の色成分に関連する第2のEOBフラグに基づいて、前記第1のEOBフラグをエントロピー符号化するためのコンテキストを導出するステップと、
前記導出されたコンテキストに基づいて前記第1のEOBフラグのエントロピー復号を実行するステップと
を含む方法。

【請求項2】

前記データブロックの前記第1の色成分は、
Cb色成分、
Cr色成分、又は
ルマ色成分
のうち1つを含む、請求項１に記載の方法。

【請求項3】

前記第1の色成分はルマ色成分を含み、
前記第2の色成分はCb色成分又はCr色成分の1つを含む、請求項１又は２に記載の方法。

【請求項4】

前記第1の色成分はCb色成分又はCr色成分の1つを含み、
前記第2の色成分はルマ色成分を含む、請求項１又は２に記載の方法。

【請求項5】

前記第1の色成分はCb(又はCr)色成分を含み、
前記第2の色成分はCr(又はCb)色成分を含む、請求項１又は２に記載の方法。

【請求項6】

デコーダがビデオデータを復号するための方法であって、
前記ビデオデータからデータブロックの色成分に関連するジョイントEOBフラグを受信するステップであって、前記ジョイントEOBフラグは、前記データブロックの前記色成分のそれぞれについてのEOBフラグ値を示す、ステップと、
前記ジョイントEOBフラグに基づいて前記データブロックの前記色成分を処理するステップと
を含む方法。

【請求項7】

前記データブロックの前記色成分は、
ルマ色成分
Cb色成分、又は
Cr色成分
のうち少なくとも2つを含む、請求項６に記載の方法。

【請求項8】

前記ジョイントEOBフラグの値は、前記データブロックの前記色成分のそれぞれについてEOBフラグ値の全ての組み合わせを表す値を有する値のセットから選択される、請求項６又は７に記載の方法。

【請求項9】

前記ジョイントEOBフラグに基づいて前記データブロックの前記色成分を処理するステップは、
前記データブロックの前記色成分のそれぞれについて前記EOBフラグ値を導出するステップと、
前記データブロックの前記色成分のそれぞれについての前記EOBフラグ値に基づいて、前記データブロックの前記色成分のそれぞれを処理するステップと
を含む、請求項６乃至８のうちいずれか１項に記載の方法。

【請求項10】

前記ジョイントEOBフラグは、ルマ色成分、Cr色成分及びCb色成分について異なるEOBフラグ値の一意の組み合わせを示す8つの異なる値によって単一のシンタックスを使用して信号伝達される、請求項６乃至９のうちいずれか１項に記載の方法。

【請求項11】

前記ジョイントEOBフラグは、Cr色成分及びCb色成分について異なるEOBフラグ値の一意の組み合わせを示す4つの異なる値によって単一のシンタックスを使用して信号伝達される、請求項６乃至９のうちいずれか１項に記載の方法。

【請求項12】

デコーダがビデオデータを復号するための方法であって、
前記ビデオデータからデータブロックの2つのクロマ色成分に関連する第1のフラグを受信するステップであって、前記第1のフラグは、前記データブロックの前記2つのクロマ色成分のうち1つにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、
前記データブロックの前記2つのクロマ色成分のうち前記1つのEOBフラグ値を示す第2のフラグを受信するステップと、
前記第1のフラグ及び前記第2のフラグに基づいて、前記データブロックの前記2つのクロマ色成分のもう一方のEOBフラグ値を導出するステップと
を含む方法。

【請求項13】

デコーダがビデオデータを復号するための方法であって、
データブロックの2つのクロマ色成分と、前記2つのクロマ色成分を用いた前記データブロックのルマ色成分とに関連する第1のフラグを受信するするステップであって、前記第1のフラグは、前記データブロックの前記2つのクロマ色成分のうち1つと、前記データブロックの前記ルマ色成分とにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、
前記データブロックの前記ルマ色成分のEOBフラグ値を示す第2のフラグを受信するステップと、
前記第2のフラグに基づいて、前記データブロックの前記ルマ色成分のEOBフラグ値を導出するステップと
を含む方法。

【請求項14】

前記データブロックの前記2つのクロマ色成分のうち1つと、前記データブロックの前記ルマ色成分とにそれぞれ関連する前記EOBフラグが等しいことを前記第1のフラグが示すことに応じて、前記第2のフラグに基づいて前記データブロックの前記2つのクロマ色成分のそれぞれのEOBフラグ値を導出するステップを更に含む、請求項１３に記載の方法。

【請求項15】

前記データブロックの前記2つのクロマ色成分のうち1つと、前記データブロックの前記ルマ色成分とにそれぞれ関連する前記EOBフラグが等しくないことを前記第1のフラグが示すことに応じて、前記ビデオデータから前記データブロックの前記2つのクロマ色成分に関連する第3のフラグを受信するステップであって、前記第3のフラグは、前記データブロックの前記2つのクロマ色成分のうち1つにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップを更に含む、請求項１３に記載の方法。

【請求項16】

前記データブロックの前記2つのクロマ色成分のうち前記1つのEOBフラグ値を示す第4のフラグを受信するステップと、
前記3のフラグ及び前記4のフラグに基づいて、前記データブロックの前記2つのクロマ色成分のうちもう一方のEOBフラグ値を導出するステップと
を更に含む、請求項１５に記載の方法。

【請求項17】

請求項１乃至１６のうちいずれか１項に記載の方法を実施するように構成された回路を含むデバイス。

【請求項18】

1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに請求項１乃至１６のうちいずれか１項に記載の方法を実施させるコンピュータプログラム。

【請求項19】

エンコーダがビデオデータを符号化するための方法であって、
前記ビデオデータのデータブロックの第1の色成分に関連する第1のブロック終了(EOB)フラグを生成するステップと、
前記ビデオデータの前記データブロックの第2の色成分に関連する第2のEOBフラグに基づいて、前記第1のEOBフラグをエントロピー符号化するためのコンテキストを導出するステップと、
前記導出されたコンテキストに基づいて前記第1のEOBフラグのエントロピー復号を実行するステップと
を含む方法。

【請求項20】

エンコーダがビデオデータを符号化するための方法であって、
前記ビデオデータのデータブロックの色成分に関連するジョイントEOBフラグを生成するステップであって、前記ジョイントEOBフラグは、前記データブロックの前記色成分のそれぞれについてのEOBフラグ値を示す、ステップと、
前記ジョイントEOBフラグに基づいて前記データブロックの前記色成分を処理するステップと
を含む方法。

【請求項21】

エンコーダがビデオデータを符号化するための方法であって、
前記ビデオデータのデータブロックの2つのクロマ色成分に関連する第1のフラグを生成するステップであって、前記第1のフラグは、前記データブロックの前記2つのクロマ色成分のうち1つにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、
前記データブロックの前記2つのクロマ色成分のうち前記1つのEOBフラグ値を示す第2のフラグを生成するステップと、
前記第1のフラグ及び前記第2のフラグに基づいて、前記データブロックの前記2つのクロマ色成分のもう一方のEOBフラグ値を導出するステップと
を含む方法。

【請求項22】

エンコーダがビデオデータを符号化するための方法であって、
データブロックの2つのクロマ色成分と、前記2つのクロマ色成分を用いた前記データブロックのルマ色成分とに関連する第1のフラグを生成するするステップであって、前記第1のフラグは、前記データブロックの前記2つのクロマ色成分のうち1つと、前記データブロックの前記ルマ色成分とにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、
前記データブロックの前記ルマ色成分のEOBフラグ値を示す第2のフラグを生成するステップと、
前記第2のフラグに基づいて、前記データブロックの前記ルマ色成分のEOBフラグ値を導出するステップと
を含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

［参照による援用］
本出願は、2021年7月23日に出願された米国仮出願第63/225,273号及び2022年1月14日に出願された米国非仮出願第17/576,255号に基づくものであり、優先権の利益を主張する。双方の出願の全内容を参照により援用する。

【0002】

［技術分野］
本開示は、一般的に、一式の高度ビデオ符号化/復号技術に関し、より具体的には、成分間のブロック終了(End of Block)フラグの符号化のための設計に関する。

【背景技術】

【0003】

本明細書で提供されるこの背景説明は、本開示の文脈を概括的に提示するためのものである。本願で名前が挙がっている発明者の仕事であってその仕事がこの背景セクションに記載されている範囲におけるもの、また、他の意味で本出願の出願時に先行技術として適格でない可能性がある本記述の側面は、明示的にも暗黙的にも本開示に対する先行技術として認められない。

【0004】

ビデオ符号化及び復号は、動き補償を伴うインターピクチャ予測を使用して実行できる。非圧縮デジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば1920×1080のルミナンスサンプル及び関連するフル又はサブサンプリングされたクロミナンスサンプルの空間的寸法を有する。一連のピクチャは、固定又は可変のピクチャレート(或いはフレームレートとも呼ばれる)、例えば、毎秒60ピクチャ又は毎秒60フレームのピクチャレートを有することができる。非圧縮ビデオは、ストリーミング又はデータ処理のために特定のビットレート要件を有する。例えば、1920×1080のピクセル解像度、60フレーム/秒のフレームレート、及びピクセル当たりカラーチャネル当たり8ビットの4:2:0のクロマサブサンプリングを有するビデオは、1.5Gbit/sに近い帯域幅を必要とする。このようなビデオの1時間は、600Gバイトを超える記憶スペースを必要とする。

【0005】

ビデオ符号化及び復号の1つの目的は、圧縮による非圧縮入力ビデオ信号における冗長性の低減であり得る。圧縮は、上記の帯域幅及び／又は記憶スペースの要件を、場合によっては2桁以上も低減するのに役立つ可能性がある。可逆圧縮及び不可逆圧縮の双方、並びにそれらの組み合わせが使用できる。可逆圧縮は、復号プロセスを介して、圧縮された元の信号から元の信号の正確なコピーが再構成できる技術を示す。不可逆圧縮は、元のビデオ情報が符号化中に十分に保持されず、復号中に十分に回復できない符号化/復号プロセスを示す。不可逆圧縮を使用する場合、再構成された信号は、元の信号と同一ではないことがあるが、元の信号と再構成された信号との間の歪みは、いくつかの情報損失にもかかわらず再構成された信号を意図された用途のために有用にレンダリングするのに十分小さくなる。ビデオの場合、不可逆圧縮が多くの用途で広く使用されている。許容可能な歪みの量はアプリケーションに依存する。例えば、特定の消費者ビデオストリーミングアプリケーションのユーザは、映画又はテレビ放送アプリケーションのユーザよりも高い歪みを許容することがある。特定の符号化アルゴリズムによって達成可能な圧縮比は、様々な歪み耐性を反映するように選択又は調整でき、一般的に、より高い許容可能な歪みはより高い損失及びより高い圧縮比をもたらす符号化アルゴリズムを許容する。

【0006】

ビデオエンコーダ及びデコーダは、例えば動き補償、フーリエ変換、量子化、及びエントロピー符号化を含むいくつかの広範なカテゴリ及びステップからの技術を利用することができる。

【0007】

ビデオコーデック技術は、イントラ符号化として知られる技術を含むことができる。イントラ符号化では、サンプル値は、以前に再構成された参照ピクチャからのサンプル又は他のデータを参照することなく表現される。いくつかのビデオコーデックでは、ピクチャは空間的にサンプルのブロックに分割される。サンプルの全てのブロックがイントラモードで符号化される場合、そのピクチャはイントラピクチャと呼ばれることができる。イントラピクチャと、独立デコーダリフレッシュピクチャのようなその派生物は、デコーダ状態をリセットするために使用でき、したがって、符号化ビデオビットストリーム及びビデオセッションにおける最初のピクチャとして或いは静止画像として使用できる。次いで、イントラ予測の後のブロックのサンプルは周波数ドメインへの変換にかけることができ、そのように生成された変換係数は、エントロピー符号化の前に量子化できる。イントラ予測は、変換前ドメインにおけるサンプル値を最小化する技術を表す。場合によっては、変換後のDC値が小さく、AC係数が小さいほど、エントロピー符号化後のブロックを表すために所与の量子化ステップサイズで必要とされるビット数が少なくなる。

【0008】

例えばMPEG-2世代の符号化技術から知られているような伝統的なイントラ符号化は、イントラ予測を使用しない。しかし、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に隣接するものの符号化及び/又は復号中に取得され、イントラ符号化又は復号されているデータのブロックに復号順で先行する周囲のサンプルデータ及び/又はメタデータに基づいてブロックの符号化/復号を試みる技術を含む。このような技術は、以下では「イントラ予測」技術と呼ばれる。少なくともいくつかの場合には、イントラ予測は再構成中の現在ピクチャからの参照データのみを使用し、他の参照ピクチャからの参照データは使用しないことに注意されたい。

【0009】

様々な形式のイントラ予測が存在し得る。所与のビデオ符号化技術において、このような技術の2つ以上が利用可能である場合、使用される技術は、イントラ予測モードと呼ばれることができる。1つ以上のイントラ予測モードが特定のコーデックで提供されてもよい。特定の場合には、モードは、サブモードを有することができ、及び/又は様々なパラメータに関連付けられてもよく、ビデオのブロックのモード/サブモード情報及びイントラ符号化パラメータは、個別に符号化されることができ、或いは、併せてモードコードワードに含められることができる。所与のモード、サブモード及び/又はパラメータの組み合わせのためにどのコードワードを使用するかは、イントラ予測を通して符号化効率利得に影響を与える可能性があり、コードワードをビットストリームに変換するために使用されるエントロピー符号化技術も同様に影響を与える可能性がある。

【0010】

イントラ予測の特定のモードがH.264で導入され、H.265で洗練され、共同探査モデル(JEM, joint exploration model)、バーサタイルビデオ符号化(VVC, versatile video coding)、及びベンチマークセット(BMS, benchmark set)のようなより新しい符号化技術においてさらに洗練された。一般的にイントラ予測について、予測子ブロックは、利用可能になった隣接サンプル値を使用して形成されることができる。例えば、特定の方向及び/又はラインに沿った特定のセットの隣接サンプルの利用可能な値が予測子ブロックにコピーされてもよい。使用される方向への参照は、ビットストリームにおいて符号化されることができ、或いは、それ自身予測されてもよい。

【0011】

図１Ａを参照すると、右下に、H.265の33個の可能なイントラ予測子方向(H.265で指定されている35個のイントラモードのうち33個の角度モードに対応する)で指定されている9個の予測子方向のサブセットが描かれている。矢印が収束する点(101)は、予測されるサンプルを表す。矢印は、101において隣接サンプルがサンプルを予測するために使用されるときの方向を表す。例えば、矢印(102)は、サンプル(101)が、水平方向から45度の角度の右上の隣接サンプル(単数又は複数)から予測されることを示す。同様に、矢印(103)は、サンプル(101)が、水平方向から22.5度の角度の、サンプル(101)の左下の隣接サンプル(単数又は複数)から予測されることを示す。

【0012】

引き続き図１Ａを参照すると、左上には、4×4サンプルの正方形ブロック(104)が描かれている(太い破線で示されている)。正方形ブロック(104)は、16個のサンプルを含み、各サンプルは「S」とY次元におけるその位置(例えば、行インデックス)及びX次元におけるその位置(例えば、列インデックス)でラベル付けされている。例えば、サンプルS21は、Y次元の(上から)2番目のサンプルであり、X次元の(左から)最初のサンプルである。同様に、サンプルS44は、Y及びX次元の双方においてブロック(104)内の4番目のサンプルである。ブロックが4×4サンプルのサイズであるので、S44は右下にある。さらに、同様の番号付け方式に従う例示的な参照サンプルが示されている。参照サンプルは、Rと、ブロック(104)に対するそのY位置(例えば、行インデックス)及びX位置(列インデックス)でラベル付けされる。H.264とH.265との双方において、再構成中のブロックの近傍の隣接する予測サンプルが使用される。

【0013】

ブロック104のイントラピクチャ予測は、信号伝達(シグナリング)される予測方向に従って隣接サンプルから参照サンプル値をコピーすることによって始まってもよい。例えば、符号化ビデオビットストリームは、このブロック104について、矢印(102)の予測方向を示す信号伝達を含むと想定する。すなわち、サンプルは、水平方向から45度の角度の右上の予測サンプル(単数又は複数)から予測される。このような場合、サンプルS41、S32、S23及びS14は、同じ参照サンプルR05から予測される。次いで、サンプルS44は、参照サンプルR08から予測される。

【0014】

特定の場合には、特に方向が45度で割り切れない場合には、参照サンプルを計算するために、複数の参照サンプルの値が、例えば補間によって組み合わされることができる。

【0015】

ビデオ符号化技術の発達し続けるにつれて、可能な方向の数が増加してきた。H.264(2003年)では、例えば、9つの異なる方向が表イントラ予測に利用可能である。これは、H.265(2013年)では33に増加し、本開示の時点でのJEM/VVC/BMSは、最大で65の方向をサポートできる。最も適切なイントラ予測方向を識別するのを助けるために実験が行われ、方向についての特定のビットペナルティを受け入れつつ、これらの最も適切な方向を少数のビットで符号化するために、エントロピー符号化において特定の技術が使用されてもよい。さらに、場合によっては、方向自身が、復号された隣接ブロックのイントラ予測で使用された隣接方向から予測できる。

【0016】

図１Ｂは、時間とともに開発された様々な符号化技術において増加する予測方向の数を示すために、JEMによる65個のイントラ予測方向を描く概略図(180)を示している。

【0017】

符号化ビデオビットストリームにおける予測方向へのイントラ予測方向ビットのマッピングの方式は、ビデオ符号化技術毎に異なってもよく、例えば、予測方向のイントラ予測モードへの単純な直接的マッピングから、コードワード、最確モードに関わる複雑な適応方式、及び同様の技術まであり得る。しかし、全ての場合に、ビデオコンテンツにおいて、特定の他の方向よりも統計的に起こりにくいイントラ予測の特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるので、良好に設計されたビデオ符号化技術においては、これらのより可能性の低い方法は、より可能性の高い方向よりもより多くのビット数によって表されてもよい。

【0018】

インターピクチャ予測又はインター予測は動き補償に基づくものでもよい。動き補償では、以前に再構成されたピクチャ又はその一部(参照ピクチャ)からのサンプルデータが、動きベクトル(以下、MV)によって示される方向に空間的にシフトされた後に、新しく再構成されるピクチャ又はその一部(例えば、ブロック)の予測のために使用されてもよい。場合によっては、参照ピクチャは、現在再構成中のピクチャと同じものとすることもできる。MVは、X及びYの2次元、又は3次元を有してもよく、第3の次元は、使用される参照ピクチャの指示である(時間次元と同様である)。

【0019】

いくつかのビデオ圧縮技術では、サンプルデータの特定の領域に適用可能な現在のMVは、他のMVから、例えば、再構成中の領域に空間的に隣接し、復号順で現在のMVに先行するサンプルデータの他の領域に関連する他のMVから予測されることができる。そうすることにより、関連するMVにおける冗長性を削減することに依存することで、MVの符号化に必要とされる全体のデータ量を実質的に削減することができ、それにより圧縮効率を増加させることができる。MV予測が有効に機能できるのは、例えば、カメラから導出される入力ビデオ信号(ナチュラルビデオとして知られる)を符号化する際に、ビデオシーケンスにおいて単一のMVが適用可能である領域よりも大きい領域が同様の方向に移動し、したがって、場合によっては、隣接領域のMVから導出された同様の動きベクトルを使用して予測できるという、統計的確からしさがあるからである。その結果、所与の領域について実際のMVが、周囲のMVから予測されるMVと同様又は同一であることになる。次いで、このようなMVは、エントロピー符号化の後、隣接MVから予測されるのではなくMVを直接符号化する場合に使用されるであろうものよりも少数のビットで表現されてもよい。いくつかの場合には、MV予測は、元の信号(すなわち、サンプルストリーム)から導出された信号(すなわち、MV)の可逆圧縮の例とすることができる。他の場合には、MV予測自身が、例えば、いくつかの周囲のMVから予測子を計算する際の丸め誤差のために、不可逆であることがある。

【0020】

H.265/HEVC(ITU-T Rec. H.265、「High Efficiency Video Coding」、December 2016)には、様々なMV予測機構が記載されている。H.265が指定する多くのMV予測機構のうち、本明細書では、以後、「空間マージ(spatial merge)」と呼ばれる技術が記載される。

【0021】

具体的には図２を参照すると、現在ブロック(201)は、空間的にシフトされた同じサイズの前のブロックから予測可能であることが動き探索プロセスの間にエンコーダによって見出されたサンプルを含む。そのMVを直接符号化する代わりに、MVは、1つ以上の参照ピクチャに関連付けられたメタデータから、例えば(復号順で)最新の参照ピクチャから、A0、A1、及びB0、B1、B2(それぞれ202～206)と記される5つの周囲のサンプルのいずれかに関連付けられたMVを使用して、導出できる。H.265では、MV予測は、隣接ブロックが使用するのと同じ参照ピクチャからの予測子を使用することができる。

【発明の概要】

【0022】

本開示の側面は、ビデオ符号化及び復号のための方法及び装置を提供する。

【0023】

本開示の側面はまた、ビデオ復号及び/又は符号化のためにコンピュータによって実行されると、コンピュータにビデオ復号及び/又は符号化のための方法を実行させる命令を記憶した非一時的なコンピュータ読み取り可能媒体を提供する。

【0024】

一側面によれば、本開示の一実施形態は、デコーダにおいてビデオデータを復号するための方法を提供する。当該方法は、ビデオデータからデータブロックの第1の色成分に関連する第1のブロック終了(EOB, End of Block)フラグを受信するステップと、ビデオデータのデータブロックの第2の色成分に関連する第2のEOBフラグに基づいて、第1のEOBフラグをエントロピー符号化するためのコンテキストを導出するステップと、導出されたコンテキストに基づいて第1のEOBフラグのエントロピー復号を実行するステップとを含む。

【0025】

別の側面によれば、本開示の一実施形態は、デコーダにおいてビデオデータを復号するための方法を提供する。当該方法は、ビデオデータからデータブロックの色成分に関連するジョイントEOBフラグを受信するステップであって、ジョイントEOBフラグは、データブロックの色成分のそれぞれについてのEOBフラグ値を示す、ステップと、ジョイントEOBフラグに基づいてデータブロックの色成分を処理するステップとを含む。

【0026】

別の側面によれば、本開示の一実施形態は、デコーダにおいてビデオデータを復号するための方法を提供する。当該方法は、ビデオデータからデータブロックの2つのクロマ色成分に関連する第1のフラグを受信するステップであって、第1のフラグは、データブロックの2つのクロマ色成分のうち1つにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、データブロックの2つのクロマ色成分のうち1つのEOBフラグ値を示す第2のフラグを受信するステップと、第1のフラグ及び第2のフラグに基づいて、データブロックの2つのクロマ色成分のもう一方のEOBフラグ値を導出するステップとを含む。

【0027】

別の側面によれば、本開示の一実施形態は、デコーダにおいてビデオデータを復号するための方法を提供する。当該方法は、データブロックの2つのクロマ色成分と、2つのクロマ色成分を用いたデータブロックのルマ色成分とに関連する第1のフラグを受信するするステップであって、第1のフラグは、データブロックの2つのクロマ色成分のうち1つと、データブロックのルマ色成分とにそれぞれ関連するEOBフラグが等しいか否かを示す、ステップと、データブロックのルマ色成分のEOBフラグ値を示す第2のフラグを受信するステップと、第2のフラグに基づいて、データブロックのルマ色成分のEOBフラグ値を導出するステップとを含む。

【0028】

別の側面によれば、本開示の一実施形態は、ビデオ符号化及び/又は復号のための装置を提供する。当該装置は、命令を記憶するメモリと、メモリと通信するプロセッサとを含む。プロセッサが命令を実行すると、プロセッサは、当該装置にビデオ復号及び/又は符号化のために上記の方法を実行させるように構成される。

【0029】

更に別の側面によれば、本開示の一実施形態は、ビデオ復号及び/又は符号化のためにコンピュータによって実行されると、コンピュータにビデオ復号及び/又は符号化のために上記の方法を実行させる命令を記憶した、非一時的なコンピュータ読み取り可能媒体を提供する。

【0030】

上記及び他の側面並びにそれらの実装は、図面、詳細な説明及び特許請求の範囲においてより詳細に記載されている。

【図面の簡単な説明】

【0031】

開示された主題の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明白になるであろう。

【図1A】イントラ予測方向モードの例示的なサブセットの概略図を示す。

【図1B】例示的なイントラ予測方向の説明図を示す。

【図2】一例における動きベクトル予測のための現在ブロック及びその周囲の空間的マージ候補の概略図を示す。

【図3】例示的な実施形態による通信システムの簡略化されたブロック図の概略図を示す。

【図4】例示的な実施形態による通信システム(400)の簡略化されたブロック図の概略図を示す。

【図5】例示的な実施形態によるビデオデコーダの簡略化されたブロック図の概略図を示す。

【図6】例示的な実施形態によるビデオエンコーダの簡略化されたブロック図の概略図を示す。

【図7】例示的な実施形態によるビデオエンコーダのブロック図を示す。

【図8】例示的な実施形態によるビデオデコーダのブロック図を示す。

【図9】本開示の例示的な実施形態による符号化ブロック分割の方式を示す。

【図10】本開示の例示的な実施形態による符号化ブロック分割の別の方式を示す。

【図11】本開示の例示的な実施形態による符号化ブロック分割の別の方式を示す。

【図12】本開示の例示的な実施形態による符号化ブロック分割の別の方式を示す。

【図13】本開示の例示的な実施形態に従って符号化ブロックを複数の変換ブロックに分割するための方式と、変換ブロックの符号化順序とを示す。

【図14】本開示の例示的な実施形態に従って符号化ブロックを複数の変換ブロックに分割するための別の方式と、変換ブロックの符号化順序とを示す。

【図15】本開示の例示的な実施形態に従って符号化ブロックを複数の変換ブロックに分割するための別の方式を示す。

【図16】本開示の例示的な実施形態によるフローチャートを示す。

【図17】本開示の例示的な実施形態によるコンピュータシステムの概略図を示す。

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

【0032】

図３は、本開示の一実施形態による通信システム(300)の簡略化されたブロック図を示す。通信システム(300)は、例えばネットワーク(350)を介して互いに通信することができる複数の端末デバイスを含む。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された第1の対の端末デバイス(310)及び(320)を含む。図３の例では、第1の対の端末デバイス(310)及び(320)は、データの一方向伝送を実行してもよい。例えば、端末デバイス(310)は、ネットワーク(350)を介した他方の端末デバイス(320)への伝送のために、ビデオデータ(例えば、端末デバイス(310)によって捕捉されたビデオピクチャのストリーム)を符号化してもよい。符号化されたビデオデータは、1つ以上の符号化ビデオビットストリームの形式で伝送されることができる。端末デバイス(320)は、ネットワーク(350)から、符号化ビデオデータを受信し、符号化ビデオデータを復号してビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャを表示してもよい。一方向データ伝送は、メディアサービスアプリケーション等において実施されてもよい。

【0033】

別の例では、通信システム(300)は、例えばビデオ会議アプリケーション中に実施され得る符号化されたビデオデータの双方向伝送を実行する第2の対の端末デバイス(330)及び(340)を含む。データの双方向伝送のために、一例では、端末デバイス(330)及び(340)の各端末デバイスは、ネットワーク(350)を介した、端末デバイス(330)及び(340)のうちの他方の端末デバイスへの伝送のために、ビデオデータ(例えば、端末デバイスによって捕捉されたビデオピクチャのストリーム)を符号化してもよい。端末デバイス(330)及び(340)の各端末デバイスは、端末デバイス(330)及び(340)のうちの他方の端末デバイスによって送信された符号化されたビデオデータを受信してもよく、符号化されたビデオデータを復号して、ビデオピクチャを復元し、復元されたビデオデータに従って、アクセス可能な表示デバイスにおいてビデオピクチャを表示してもよい。

【0034】

図３の例では、端末デバイス(310)、(320)、(330)及び(340)は、サーバ、パーソナルコンピュータ及びスマートフォンとして実装されてもよいが、本開示の基礎の原理の適用可能性は、これらに限定されなくてもよい。本開示の実施形態は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、ウェアラブルコンピュータ、及び/又は専用のビデオ会議設備に実装されてもよい。ネットワーク(350)は、例えば有線(配線）及び/又は無線通信ネットワークを含む、端末デバイス(310)、(320)、(330)及び(340)の間で符号化されたビデオデータを伝達する任意の数又はタイプのネットワークを表す。通信ネットワーク(350)は、回線交換、パケット交換及び/又は別のタイプのチャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。ここでの議論の目的のために、ネットワーク(350)のアーキテクチャ及びトポロジは、以下に明示的に説明しない限り、本開示の動作には重要ではないことがある。

【0035】

図４は、開示される主題のためのアプリケーションの例として、ビデオストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示される主題は、例えば、ビデオ会議、デジタルTV放送、ゲーム、仮想現実、CD、DVD、メモリスティック等を含むデジタル媒体上の圧縮ビデオの記憶等を含む、他のビデオアプリケーションにも等しく適用可能であり得る。

【0036】

ビデオストリーミングシステムは、ビデオソース(401)、例えばデジタルカメラを含むことができ、例えば非圧縮のビデオピクチャ又は画像のストリーム(402)を生成するビデオ捕捉サブシステム(413)を含んでもよい。一例では、ビデオピクチャのストリーム(402)は、ビデオソース401のデジタルカメラによって記録されたサンプルを含む。符号化されたビデオデータ(404)(又は符号化されたビデオビットストリーム)と比較した場合の高いデータボリュームを強調するために太線として描かれているビデオピクチャのストリーム(402)は、ビデオソース(401)に結合されたビデオエンコーダ(403)を含む電子デバイス(420)によって処理されることができる。ビデオエンコーダ(403)は、以下により詳細に説明されるように、開示される主題の側面を可能にするため或いは実現するためのハードウェア、ソフトウェア、又はこれらの組み合わせを含むことができる。非圧縮のビデオピクチャのストリーム(402)と比較した場合の、より低いデータボリュームを強調するために細い線として描かれている、符号化されたビデオデータ(404)(又は符号化されたビデオビットストリーム(404))は、将来の使用のためにストリーミングサーバ(405)に記憶されることができ、或いは、ダウンストリームのビデオデバイス(図示せず)に直接記憶されることができる。図４のクライアントサブシステム(406)及び(408)のような1つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ(405)にアクセスして、符号化されたビデオデータ(404)のコピー(407)及び(409)を取り出すことができる。クライアントサブシステム(406)は、例えば電子デバイス(430)内にビデオデコーダ(410)を含むことができる。ビデオデコーダ(410)は、符号化されたビデオデータの入力コピー(407)を復号し、ディスプレイ(412)(例えば表示画面)又は他のレンダリングデバイス(図示せず)上にレンダリングできる非圧縮のビデオピクチャの出力ストリーム(411)を生成する。ビデオデコーダ410は、本開示に記載の様々な機能の一部又は全部を実行するように構成されてもよい。いくつかのストリーミングシステムでは、符号化されたビデオデータ(404)、(407)、及び(409)(例えば、ビデオビットストリーム)は、特定のビデオ符号化/圧縮標準に従って符号化されることができる。これらの標準の例は、ITU-T勧告H.265を含む。一例では、開発中のビデオ符号化標準は、非公式に多用途ビデオ符号化(VVC)として知られている。開示される主題は、VVC及び他のビデオ符号化標準の文脈で使用されてもよい。

【0037】

電子デバイス(420)及び(430)は、他の構成要素(図示せず)を含むことができることを注意しておく。例えば、電子デバイス(420)は、ビデオデコーダ(図示せず)を含むことができ、電子デバイス(430)は、ビデオエンコーダ(図示せず)も含むことができる。

【0038】

図５は、以下の本開示の任意の実施形態によるビデオデコーダ(510)のブロック図を示す。ビデオデコーダ(510)は、電子デバイス(530)に含まれることができる。電子デバイス(530)は、受信機(531)(例えば、受信回路)を含むことができる。ビデオデコーダ(510)は、図４の例におけるビデオデコーダ(310)の代わりに使用できる。

【0039】

受信機(531)は、ビデオデコーダ(510)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよい。同じ又は別の実施形態において、一度に1つの符号化ビデオシーケンスが復号されてもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスから独立である。各ビデオシーケンスは複数のビデオフレーム又は画像に関連付けられてもよい。符号化ビデオシーケンスは、チャネル(501)から受信されてもよく、該チャネルは、符号化されたビデオデータを記憶する記憶デバイス又は符号化ビデオデータを送信するストリーミングソースへのハードウェア/ソフトウェアリンクでもよい。受信機(531)は、符号化されたビデオデータを、符号化されたオーディオデータ及び/又は補助データストリームのような他のデータと一緒に受信してもよく、これらのデータは、それぞれの処理回路(図示せず)を転送されてもよい。受信機(531)は、符号化ビデオシーケンスを他のデータから分離することができる。ネットワークジッタ対策として、バッファメモリ(515)が、受信機(531)とエントロピーデコーダ/パーサ(520)(以下「パーサ」)との間に配置されてもよい。特定のアプリケーションでは、バッファメモリ(515)はビデオデコーダ(510)の一部として実装されてもよい。他のアプリケーションでは、ビデオデコーダ(510)の外部に離れて存在することができる(図示せず)。さらに他のアプリケーションでは、例えばネットワークジッタに対抗するために、ビデオデコーダ(510)の外部にバッファメモリ(図示せず)が存在してもよく、さらに、例えば再生タイミングを扱うために、ビデオデコーダ(510)の内部に別の更なるバッファメモリ(515)が存在してもよい。受信機(531)が、十分な帯域幅及び制御可能性の記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合は、バッファメモリ(515)は、必要とされなくてもよく、或いは、小さくてもよい。インターネットのようなベストエフォート型のパケットネットワークでの使用のためには、十分なサイズのバッファメモリ(515)が要求されることがあり、そのサイズは比較的大きい。このようなバッファメモリは適応サイズで実装されてもよく、少なくとも部分的に、ビデオデコーダ(510)の外部でオペレーティングシステム又は同様の要素(図示せず)において実装されてもよい。

【0040】

ビデオデコーダ(510)は、符号化ビデオシーケンスからシンボル(521)を再構成するためのパーサ(520)を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ(510)の動作を管理するために使用される情報と、潜在的には、ディスプレイ(512)(例えば表示画面)のようなレンダリングデバイスを制御するための情報とを含む。ディスプレイは、図５に示されるように、電子デバイス(530)の一体的な部分でも一体的な部分でなくてもよく、電子デバイス(530)に結合されることができる。レンダリングデバイス(単数又は複数)のための制御情報は、補足エンハンスメント情報(Supplementary Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(Video Usability Information、VUI)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(520)は、パーサ(520)によって受信された符号化ビデオシーケンスをパースする/エントロピー復号することができる。符号化ビデオシーケンスのエントロピー符号化は、ビデオ符号化技術又は標準に従うことができ、可変長符号化、ハフマン符号化、コンテキスト感受性あり又はなしの算術符号化等を含む、様々な原理に従うことができる。パーサ(520)は、符号化ビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つについてのサブグループパラメータのセットを、サブグループに対応する少なくとも1つのパラメータに基づいて、抽出することができる。サブグループは、グループオブピクチャ(Group of Pictures、GOP)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(Coding Unit、CU)、ブロック、変換ユニット(Transform Unit、TU)、予測ユニット(Prediction Unit、PU)等を含むことができる。パーサ(520)はまた、符号化ビデオシーケンスから、変換係数(例えば、フーリエ変換係数)、量子化器パラメータ値、動きベクトル等の情報を抽出することができる。

【0041】

パーサ(520)は、バッファメモリ(515)から受信されたビデオシーケンスに対してエントロピー復号/パース動作を実行し、それによりシンボル(521)を生成することができる。

【0042】

シンボル(521)の再構成は、符号化されたビデオピクチャ又はその部分のタイプ(例えば、インター及びイントラピクチャ、インター及びイントラブロック)及び他の要因に依存して、複数の異なる処理又は機能ユニットに関わることができる。関わるユニット及びどのように関わるかは、符号化ビデオシーケンスからパーサ(520)によってパースされたサブグループ制御情報によって制御されてもよい。パーサ(520)と下記の複数の処理又は機能ユニットとの間のこのようなサブグループ制御情報の流れは、簡潔のため、描かれていない。

【0043】

既に述べた機能ブロックのほかに、ビデオデコーダ(510)は、以下に説明するように、概念的に、いくつかの機能ユニットに分割できる。商業的制約の下で機能する実際的な実装では、これらの機能ユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されることができる。しかし、開示される主題の様々な機能を明確に記述する目的のために、機能ユニットへの概念的な細分が以下の開示において採用される。

【0044】

第1のユニットは、スケーラ/逆変換ユニット(551)を含んでもよい。スケーラ/逆変換ユニット(551)は、パーサ(520)から、量子化された変換係数及び制御情報をシンボル(単数又は複数)(521)として受信してもよい。制御情報は、どのタイプの逆変換を使用するか、ブロックサイズ、量子化係数/パラメータ、量子化スケーリング行列等を示す情報含む。スケーラ/逆変換ユニット(551)は、集計器(555)に入力できるサンプル値を含むブロックを出力することができる。

【0045】

場合によっては、スケーラ/逆変換(551)の出力サンプルは、イントラ符号化されたブロック、すなわち、以前に再構成されたピクチャからの予測情報を使用しないが、現在ピクチャの、以前に再構成された部分からの予測情報を使用することができるブロックに関することができる。このような予測情報は、イントラピクチャ予測ユニット(552)によって提供されることができる。場合によっては、イントラピクチャ予測ユニット(552)は、既に再構成されて現在ピクチャバッファ(558)に記憶されている周囲のブロック情報を使用して、再構成中のブロックと同じサイズ及び形状のブロックを生成してもよい。現在ピクチャバッファ(558)は、例えば、部分的に再構成された現在ピクチャ及び/又は完全に再構成された現在ピクチャをバッファリングする。集計器(555)は、実装によっては、サンプル毎に、イントラ予測ユニット(552)が生成した予測情報を、スケーラ/逆変換ユニット(551)によって提供される出力サンプル情報に加算してもよい。

【0046】

他の場合には、スケーラ/逆変換ユニット(551)の出力サンプルは、インター符号化され、潜在的には動き補償されたブロックに関することができる。このような場合、動き補償予測ユニット(553)は、インターピクチャ予測のために使用されるサンプルを取り出すために参照ピクチャメモリ(557)にアクセスすることができる。取り出されたサンプルを、ブロックに関するシンボル(521)に従って動き補償した後、これらのサンプルは、集計器(555)によってスケーラ/逆変換ユニットの出力(ユニット551の出力は、残差サンプル又は残差信号と呼ばれてもよい)に加算されて、それにより出力サンプル情報を生成することができる。動き補償ユニット(553)が予測サンプルを取り出す参照ピクチャメモリ(557)内のアドレスは、シンボル(521)の形式で動き補償ユニット(553)に利用可能な動きベクトルによって制御できる。該シンボルは、例えばX、Y成分(シフト)、及び参照ピクチャ成分(時間)を有することができる。動き補償は、サンプル以下の正確な動きベクトルが使用されるときの参照ピクチャメモリ(557)から取ってこられるサンプル値の補間を含んでもよく、動きベクトル予測機構等にも関連してもよい。

【0047】

集計器(555)の出力サンプルは、ループフィルタユニット(556)内で様々なループフィルタリング技術にかけられることができる。ビデオ圧縮技術は、ループ内フィルタ技術を含むことができる。ループ内フィルタ技術は、符号化ビデオシーケンス(符号化されたビデオビットストリームとも呼ばれる)に含まれるパラメータによって制御され、パーサ(520)からのシンボル(521)としてループフィルタユニット(556)に利用可能にされるが、符号化されたピクチャ又は符号化されたビデオシーケンスの(復号順で)前の部分の復号中に得られたメタ情報に応答するとともに、以前に再構成されループフィルタリングされたサンプル値に応答することもできる。以下に更に詳細に説明するように、いくつかのタイプのループフィルタが、様々な順序でループフィルタユニット556の一部として含まれてもよい。

【0048】

ループフィルタユニット(556)の出力はサンプルストリームであることができ、これは、レンダリングデバイス(512)に出力されることができ、また将来のインターピクチャ予測において使用するために参照ピクチャメモリ(557)に記憶されることができる。

【0049】

特定の符号化されたピクチャは、いったん完全に再構成されると、将来のインターピクチャ予測のための参照ピクチャとして使用できる。例えば、現在ピクチャに対応する符号化されたピクチャが完全に再構成され、該符号化されたピクチャが(例えば、パーサ(520)によって)参照ピクチャとして特定されると、現在ピクチャバッファ(558)は参照ピクチャメモリ(557)の一部となることができ、後続の符号化されたピクチャの再構成を開始する前に、新鮮な現在ピクチャバッファが再割り当てされることができる。

【0050】

ビデオデコーダ(510)は、ITU-T勧告H.265のような標準で採用されている所定のビデオ圧縮技術に従って復号動作を実行することができる。符号化ビデオシーケンスはビデオ圧縮技術又は標準のシンタックス及びビデオ圧縮技術又は標準において文書化されているプロファイルに従うという意味で、符号化されたビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって規定されたシンタックスに準拠することができる。具体的には、プロファイルはビデオ圧縮技術又は標準において利用可能な全てのツールから、そのプロファイルのもとでの使用のためにそれだけが利用可能なツールとして、特定のツールを選択することができる。標準に準拠するために、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内になり得る。いくつかの場合には、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート(例えば、毎秒メガサンプルの単位で測られる)、最大参照ピクチャサイズ等を制約する。レベルによって設定された限界は、場合によっては、符号化ビデオシーケンスにおいて信号伝達される、HRDバッファ管理のための仮想参照デコーダ(Hypothetical Reference Decoder、HRD)仕様及びメタデータを通じてさらに制約されることができる。

【0051】

いくつかの例示的な実施形態において、受信機(531)は、符号化されたビデオとともに追加の(冗長な)データを受信してもよい。追加データは、符号化されたビデオシーケンス(単数又は複数)の一部として含まれていてもよい。追加データは、データを適正に復号するため、及び/又は元のビデオデータをより正確に再構成するために、ビデオデコーダ(510)によって使用されてもよい。追加データは、例えば、時間的、空間的、又は信号対雑音比(SNR)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正符号等の形式になり得る。

【0052】

図６は、本開示の例示的な実施形態によるビデオエンコーダ(603)のブロック図を示している。ビデオエンコーダ(603)は、電子デバイス(620)に含まれてもよい。電子デバイス(620)は、送信機(640)(例えば、送信回路)を更に含んでもよい。ビデオエンコーダ(603)は、図４の例におけるビデオエンコーダ(403)の代わりに使用できる。

【0053】

ビデオエンコーダ(603)は、ビデオエンコーダ(603)によって符号化されるべきビデオ画像を捕捉することができるビデオソース(601)(これは図６の例では電子デバイス(620)の一部ではない)からビデオサンプルを受信することができる。別の例では、ビデオソース(601)は、電子デバイス(620)の一部として実装されてもよい。

【0054】

ビデオソース(601)は、任意の好適なビット深さ(例えば、8ビット、10ビット、12ビット、…)、任意の色空間(例えば、BT.601 YCrCB、RGB、XYZ、…)及び任意の好適なサンプリング構造(例えば、YCrCb 4:2:0、YCrCb 4:4:4)であり得るデジタルビデオサンプルストリームの形式で、ビデオエンコーダ(603)によって符号化されるべきソースビデオシーケンスを提供することができる。メディアサービスシステムにおいては、ビデオソース(601)は、事前に準備されたビデオを記憶可能な記憶デバイスでもよい。ビデオ会議システムにおいては、ビデオソース(601)は、ローカルでの画像情報をビデオシーケンスとして捕捉するカメラでもよい。ビデオデータは、シーケンスで見たときに動きを付与する複数の個々のピクチャ又は画像として提供されてもよい。ピクチャ自体は、ピクセルの空間的アレイとして編成されてもよく、各ピクセルは、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。下記の説明は、サンプルに焦点を当てる。

【0055】

いくつかの例示的な実施形態によれば、ビデオエンコーダ(603)は、ソースビデオシーケンスのピクチャを、リアルタイムで或いはアプリケーションによって要求される任意の他の時間的制約の下で、符号化及び圧縮して、符号化ビデオシーケンス(643)にすることができる。適切な符号化速度を施行することは、コントローラ(650)の1つの機能を構成する。いくつかの実施形態では、コントローラ(650)は、以下に記載されるような他の機能ユニットに機能的に結合され、該他の機能ユニットを制御してもよい。かかる結合は、簡潔のために描かれていない。コントローラ(650)によって設定されるパラメータは、レート制御に関連するパラメータ(ピクチャスキップ、量子化器、レート‐歪み最適化技術のラムダ値、…)、ピクチャサイズ、グループオブピクチャ(GOP)レイアウト、最大動きベクトル探索範囲等を含むことができる。コントローラ(650)は、特定のシステム設計のために最適化されたビデオエンコーダ(603)に関する他の好適な機能を有するように構成できる。

【0056】

いくつかの例示的な実施形態では、ビデオエンコーダ(603)は、符号化ループにおいて動作するように構成されてもよい。思い切って単純化した説明として、一例では、符号化ループは、ソース符号化器(630)(例えば、符号化されるべき入力ピクチャと参照ピクチャ(単数又は複数)に基づいてシンボルストリームのようなシンボルを生成することを受け持つ)と、ビデオエンコーダ(603)に埋め込まれた(ローカル)デコーダ(633)とを含むことができる。埋め込みデコーダ633がソースコーダ630によってエントロピーコーディングせずに符号化ビデオストリームを処理する場合であっても、デコーダ(633)は、(リモートの)デコーダも生成するであろうのと同様の仕方でサンプルデータを生成するよう前記シンボルを再構成する(開示される主題において考慮されるビデオ圧縮技術では、エントロピーコーディングにおけるシンボルと符号化ビデオビットストリームとの間のどの圧縮も無損失になり得る)。再構成されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームの復号は、デコーダ位置(ローカルかリモートか)によらずビット正確な結果をもたらすので、参照ピクチャメモリ(634)の内容もローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えると、エンコーダの予測部は、デコーダが復号中に予測を使用するときに「見る」のとまったく同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャ同期性のこの基本原理(及び、例えば、チャネルエラーのために同期性が維持できない場合の結果として生じるドリフト)は、符号化品質を改善するために使用される。

【0057】

「ローカル」デコーダ(633)の動作は、図５との関連で既に上記で詳細に述べた「リモート」デコーダ、例えばビデオデコーダ(410)の動作と同じでもよい。しかし、簡単に図５も参照すると、シンボルが利用可能であり、エントロピー符号化器(645)及びパーサ(420)による、シンボルの符号化ビデオシーケンスへの符号化/復号が可逆であり得るので、バッファメモリ(415)及びパーサ(420)を含むビデオデコーダ(410)のエントロピー復号部は、エンコーダのローカルデコーダ(633)においては完全には実装されなくてもよい。

【0058】

この時点で行なうことができる観察は、デコーダ内のみに存在し得るパース/エントロピー復号を除くどのデコーダ技術も、対応するエンコーダ内で実質的に同一の機能的形態で存在する必要があり得ることである。このため、開示される主題は時としてデコーダ動作に焦点を当てることがある。これはエンコーダの復号部分と同様である。したがって、エンコーダ技術の記述は、包括的に記述されるデコーダ技術の逆であるため、省略することができる。エンコーダの特定の領域又は側面においてのみ、より詳細な説明が以下に提供される。

【0059】

動作中、いくつかの例示的な実装では、ソース符号化器(630)は、「参照ピクチャ」として指定された、ビデオシーケンスからの1つ以上の以前に符号化されたピクチャを参照して、入力ピクチャを予測的に符号化する、動き補償された予測符号化を実行することができる。このようにして、符号化エンジン(632)は、入力ピクチャのピクセルブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャ(単数又は複数)のピクセルブロックとの間のカラーチャネルにおける差分(又は残差)を符号化する。「残差」及びその派生形の「残差の」という用語は交換可能に使用されてもよい。

【0060】

ローカルビデオデコーダ(633)は、ソース符号化器(630)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャの符号化されたビデオデータを復号することができる。符号化エンジン(632)の動作は、有利には、損失のあるプロセスであり得る。符号化されたビデオデータがビデオデコーダ(図６には示さず)で復号され得るとき、再構成されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスの複製であり得る。ローカルビデオデコーダ(633)は、ビデオデコーダによって参照ピクチャに対して実行され得る復号プロセスを複製し、再構成された参照ピクチャを参照ピクチャキャッシュ(634)に格納させることができる。このようにして、ビデオエンコーダ(603)は、遠端(リモート)のビデオデコーダによって得られるであろう再構成された参照ピクチャとしての共通の内容を(伝送エラーがなければ)有する再構成された参照ピクチャのコピーを、ローカルに記憶することができる。

【0061】

予測器(635)は、符号化エンジン(632)について予測探索を実行することができる。すなわち、符号化されるべき新しいピクチャについて、予測器(635)は、新しいピクチャのための適切な予測参照として機能し得るサンプルデータ(候補参照ピクセルブロックとして)又は特定のメタデータ、例えば参照ピクチャ動きベクトル、ブロック形状等を求めて、参照ピクチャメモリ(634)を探索することができる。予測器(635)は、適切な予測参照を見出すために、サンプルブロック/ピクセルブロック毎に(on a sample block-by-pixel block basis)動作し得る。場合によっては、予測器(635)によって得られた検索結果によって決定されるところにより、入力ピクチャは、参照ピクチャメモリ(634)に記憶された複数の参照ピクチャから引き出された予測参照を有することができる。

【0062】

コントローラ(650)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含め、ソース符号化器(630)の符号化動作を管理してもよい。

【0063】

上記の機能ユニット全ての出力は、エントロピー符号化器(645)におけるエントロピー符号化を受けることができる。エントロピー符号化器(645)は、ハフマン符号化、可変長符号化、算術符号化等といった技術に従ってシンボルを無損失圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。

【0064】

送信機(640)は、エントロピー符号化器(645)によって生成される符号化ビデオシーケンスをバッファに入れて、通信チャネル(660)を介した送信のために準備することができる。通信チャネル(660)は、符号化されたビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクであってもよい。送信機(640)は、ビデオ符号化器(630)からの符号化されたビデオデータを、送信されるべき他のデータ、例えば符号化されたオーディオデータ及び/又は補助データストリーム(ソースは図示せず)とマージすることができる。

【0065】

コントローラ(650)は、ビデオエンコーダ(603)の動作を管理してもよい。符号化の間、コントローラ(650)は、それぞれの符号化されたピクチャに、ある符号化ピクチャタイプを割り当てることができる。符号化ピクチャタイプは、それぞれのピクチャに適用され得る符号化技術に影響し得る。例えば、ピクチャはしばしば、以下のピクチャタイプのうちの1つとして割り当てられることがある。

【0066】

イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずに、符号化され、復号され得るものであり得る。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(Independent Decoder Refresh、「IDR」)ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形、並びにそれらのそれぞれの用途及び特徴を認識する。

【0067】

予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを用いるイントラ予測又はインター予測を用いて符号化及び復号され得るものであり得る。

【0068】

双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを用いるイントラ予測又はインター予測を用いて符号化及び復号され得るものであり得る。同様に、マルチ予測ピクチャは、単一のブロックの再構成のために、3つ以上の参照ピクチャ及び関連するメタデータを使用することができる。

【0069】

ソースピクチャは、通常では、空間的に複数のサンプル符号化ブロック(例えば、それぞれ4×4、8×8、4×8、又は16×16サンプルのブロック)に分割され、ブロック毎に符号化され得る。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定されるところにより、他の(既に符号化された)ブロックを参照して予測的に符号化され得る。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間的予測又はイントラ予測)。Pピクチャのピクセルブロックは、以前に符号化された1つの参照ピクチャを参照して、空間的予測を介して或いは時間的予測を介して予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つの以前に符号化された参照ピクチャを参照して、空間的予測を介して或いは時間的予測を介して予測的に符号化されてもよい。ソースピクチャ又は中間処理ピクチャは、他の目的のために他のタイプのブロックに細分されてもよい。以下に更に詳細に説明するように、符号化ブロック及び他のタイプのブロックの分割は同じ方式に従ってもよく、或いは、同じ方式に従わなくてもよい。

【0070】

ビデオエンコーダ(603)は、ITU-T勧告H.265等の所定のビデオ符号化技術又は標準に従って符号化動作を実行することができる。その動作において、ビデオエンコーダ(603)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を活用する予測符号化動作を含む、様々な圧縮動作を実行することができる。よって、符号化されたビデオデータは、使用されるビデオ符号化技術又は標準によって指定されるシンタックスに準拠し得る。

【0071】

いくつかの例示的な実施形態において、送信機(640)は、符号化されたビデオと一緒に追加データを送信してもよい。ソース符号化器(630)は、符号化ビデオシーケンスの一部としてこのようなデータを含めてもよい。追加データは、時間的/空間的/SNRエンハンスメント層、冗長ピクチャ及びスライスのような他の形式の冗長データ、SEIメッセージ、VUIパラメータセットフラグメント等を含んでいてもよい。

【0072】

ビデオは、時間的シーケンスにおいて複数のソースピクチャ(ビデオピクチャ)として捕捉されてもよい。イントラピクチャ予測(しばしば、イントラ予測と略される)は、所与のピクチャにおける空間的相関を利用し、インターピクチャ予測は、ピクチャ間の時間的又は他の相関を利用する。例えば、現在ピクチャと呼ばれる符号化/復号対象の特定のピクチャは、ブロックに分割されてもよい。現在ピクチャ内のブロックが、ビデオにおける、前に符号化され、且つ、まだバッファに入れられている参照ピクチャ内の参照ブロックに類似する場合、動きベクトルと呼ばれるベクトルによって符号化されてもよい。動きベクトルは、参照ピクチャ内の参照ブロックを指し、複数の参照ピクチャが使用される場合には、参照ピクチャを特定する第3の次元を有することができる。

【0073】

いくつかの例示的な実施形態において、インターピクチャ予測において双方向予測技術が使用できる。このような双方向予測技術によれば、いずれもビデオにおいて現在ピクチャより復号順で先行する(ただし、表示順では、それぞれ過去又は将来でもよい)第1の参照ピクチャ及び第2の参照ピクチャのような2つの参照ピクチャが使用される。現在ピクチャ内のブロックは、第1の参照ピクチャ内の第1の参照ブロックを指す第1の動きベクトルと、第2の参照ピクチャ内の第2の参照ブロックを指す第2の動きベクトルとによって符号化できる。ブロックは、第1の参照ブロックと第2の参照ブロックの組み合わせによって一緒に予測できる。

【0074】

さらに、符号化効率を改善するために、インターピクチャ予測においてマージモード技術が使用されてもよい。

【0075】

本開示のいくつかの例示的な実施形態によれば、インターピクチャ予測及びイントラピクチャ予測等の予測は、ブロックの単位で実行される。例えば、ビデオピクチャのシーケンスにおけるピクチャは、圧縮のために符号化ツリーユニット(CTU)に分割され、ピクチャにおけるそれらのCTUは、64×64ピクセル、32×32ピクセル、又は16×16ピクセル等の同じサイズを有してもよい。一般に、CTUは、1つのルマCTB及び2つのクロマCTBである3つの並列の符号化ツリーブロック(CTB)を含んでもよい。各CTUは、再帰的に、1つ以上の符号化ユニット(CU)に四分木分割されていくことができる。例えば、64×64ピクセルのCTUは、64×64ピクセルの1つのCU、又は32×32ピクセルの4つのCUに分割されることができる。1つ以上の32×32ブロックのそれぞれは、16×16ピクセルの4つのCUに更に分割されてもよい。いくつかの例示的な実施形態では、各CUは、符号化中に、インター予測タイプ又はイントラ予測タイプのような様々な予測タイプの中で、そのCUについての予測タイプを決定するために解析されてもよい。CUは時間的及び/又は空間的予測可能性に依存して、1つ以上の予測ユニット(PU)に分割されてもよい。一般に、各PUはルマ予測ブロック(PB)及び2つのクロマPBを含む。ある実施形態では、コーディング(符号化/復号)における予測動作は、予測ブロックの単位で実行される。PU(又は異なるカラーチャネルのPB)へのCUの分割は、様々な分割パターンで実行されてもよい。例えば、ルマ又はクロマPBは、8×8ピクセル、16×16ピクセル、8×16ピクセル、16×8ピクセル等のように、ピクセルについての値(例えば、ルマ値)の行列を含んでもよい。

【0076】

図７は、本開示の別の例示的な実施形態によるビデオエンコーダ(703)の図を示す。ビデオエンコーダ(703)は、ビデオピクチャのシーケンス内の現在ビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックを、符号化ビデオシーケンスの一部である符号化されたピクチャに符号化するように構成される。例示的なビデオエンコーダ(703)は、図４の例におけるビデオエンコーダ(403)の代わりに使用されてもよい。

【0077】

例えば、ビデオエンコーダ(703)は、8×8サンプル等の予測ブロックのような処理ブロックについてサンプル値の行列を受信する。次いで、ビデオエンコーダ(703)は、処理ブロックが、イントラモード、インターモード、又は双方向予測モードのどれを使用して、最もよく符号化されるかを、例えばレート‐歪み最適化(RDO)を使用して、判別する。処理ブロックがイントラモードで符号化されると決定された場合、ビデオエンコーダ(703)は、処理ブロックを符号化されたピクチャに符号化するためにイントラ予測技術を使用してもよい。処理ブロックがインターモード又は双方向予測モードで符号化されると決定された場合、ビデオエンコーダ(703)は、処理ブロックを符号化されたピクチャに符号化するために、それぞれ、インター予測技術又は双方向予測技術を使用してもよい。いくつかの例示的な実施形態では、マージモード(merge mode)は、動きベクトルが1つ以上の動きベクトル予測子から導出されるが前記予測子の外の符号化された動きベクトル成分の利益のない、インターピクチャ予測のサブモードとして使用されてもよい。いくつかの例示的な実施形態では、対象ブロックに適用可能な動きベクトル成分が存在してもよい。よって、ビデオエンコーダ(703)は、処理ブロックの予測モードを決定するためのモード決定モジュール(図示せず)のような、図７に明示的に図示しないコンポーネントを含んでもよい。

【0078】

図７の例では、ビデオエンコーダ(703)は、インターエンコーダ(730)、イントラエンコーダ(722)、残差計算器(723)、スイッチ(726)、残差エンコーダ(724)、全般コントローラ(721)、及びエントロピー符号化器(725)を、図７の例示的な配置に示されるように一緒に結合されて含む。

【0079】

インターエンコーダ(730)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、該ブロックを参照ピクチャ内の1つ以上の参照ブロック(例えば、表示順で以前のピクチャ及び後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インター符号化技術による冗長情報の記述、動きベクトル、マージモード情報)を生成し、該インター予測情報に基づいて、任意の好適な技術を使用してインター予測結果(例えば、予測されたブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、符号化されたビデオ情報に基づいて、図６の例示的なエンコーダ620に埋め込まれた復号ユニット633(以下に更に詳細に説明するように、図７の残差デコーダ728として示される)を使用して復号された、復号された参照ピクチャである。

【0080】

イントラエンコーダ(722)は、現在ブロック(例えば、処理ブロック)のサンプルを受信し、該ブロックを、同じピクチャ内で既に符号化されているブロックと比較し、変換後に量子化された係数を生成し、場合によっては、イントラ予測情報(例えば、1つ以上のイントラ符号化技術によるイントラ予測方向情報)も生成するように構成される。イントラエンコーダ(722)はまた、該イントラ予測情報及び同じピクチャ内の参照ブロックに基づいて、イントラ予測結果(例えば、予測されたブロック)を計算してもよい。

【0081】

全般コントローラ(721)は、全般制御データを決定し、全般制御データに基づいてビデオエンコーダ(703)の他のコンポーネントを制御するように構成されてもよい。一例では、全般コントローラ(721)は、ブロックの予測モードを決定し、その予測モードに基づいて制御信号をスイッチ(726)に提供する。例えば、予測モードがイントラモードである場合、全般コントローラ(721)は、残差計算器(723)による使用のためにイントラモードの結果を選択するようスイッチ(726)を制御し、イントラ予測情報を選択し、イントラ予測情報をビットストリームに含めるようエントロピーエンコーダ(725)を制御する。そのブロックの予測モードがインターモードである場合、全般コントローラ(721)は、残差計算器(723)による使用のためにインター予測の結果を選択するようスイッチ(726)を制御し、インター予測情報を選択し、インター予測情報をビットストリームに含めるようエントロピーエンコーダ(725)を制御する。

【0082】

残差計算器(723)は、受信されたブロックと、イントラエンコーダ(722)又はインターエンコーダ(730)から選択されたそのブロックの予測結果との差(残差データ)を計算するように構成されてもよい。残差エンコーダ(724)は、残差データを符号化して変換係数を生成するように構成されてもよい。例えば、残差エンコーダ(724)は、残差データを空間領域から周波数領域に変換し、変換係数を生成するように構成されてもよい。次いで、変換係数は、量子化処理にかけられ、量子化された変換係数を得る。様々な例示的な実施形態において、ビデオエンコーダ(703)は、残差デコーダ(728)をも含む。残差デコーダ(728)は、逆変換を実行して、復号された残差データを生成するように構成される。復号された残差データは、イントラエンコーダ(722)及びインターエンコーダ(730)によって好適に使用されることができる。例えば、インターエンコーダ(730)は、復号された残差データ及びインター予測情報に基づいて、復号されたブロックを生成することができ、イントラエンコーダ(722)は、復号された残差データ及びイントラ予測情報に基づいて、復号されたブロックを生成することができる。復号されたブロックは、復号されたピクチャを生成するために好適に処理され、復号されたピクチャは、メモリ回路(図示せず)内にバッファリングされ、参照ピクチャとして使用されることができる。

【0083】

エントロピーエンコーダ(725)は、符号化されたブロックを含むようにビットストリームをフォーマットし、エントロピー符号化を実行するように構成される。エントロピーエンコーダ(725)は、様々な情報をビットストリーム内に含めるように構成される。例えば、エントロピーエンコーダ(725)は、全般制御データ、選択された予測情報(例えば、イントラ予測情報又はインター予測情報)、残差情報、及び他の好適な情報をビットストリーム内に含めるように構成されてもよい。インターモード又は双方向予測モードのいずれかのマージサブモードにおいてブロックを符号化する場合は、残差情報は存在しなくてもよい。

【0084】

図８は、本開示の別の実施形態による例示的なビデオデコーダ(810)の図を示す。ビデオデコーダ(810)は、符号化されたビデオシーケンスの一部である符号化されたピクチャを受信し、符号化されたピクチャを復号して、再構成されたピクチャを生成するように構成される。一例では、ビデオデコーダ(810)は、図４の例におけるビデオデコーダ(410)の代わりに使用されてもよい。

【0085】

図８の例では、ビデオデコーダ(810)は、エントロピーデコーダ(871)、インターデコーダ(880)、残差デコーダ(873)、再構成モジュール(874)、及びイントラデコーダ(872)が図８の例示的な構成に示されるように一緒に結合されたものを含む。

【0086】

エントロピーデコーダ(871)は、符号化されたピクチャから、その符号化されたピクチャが構成されるシンタックスエレメントを表す特定のシンボルを再構成するように構成されることができる。このようなシンボルは、例えば、ブロックが符号化されるモード(例えば、イントラモード、インターモード、双方向予測モード、マージサブモード又は別のサブモード)、イントラデコーダ(872)又はインターデコーダ(880)によって予測のために使用される特定のサンプル又はメタデータを識別することができる予測情報(例えば、イントラ予測情報又はインター予測情報)、例えば量子化された変換係数の形式の残差情報等を含むことができる。一例では、予測モードがインター又は双方向予測モードである場合、インター予測情報がインターデコーダ(880)に提供される。予測タイプがイントラ予測タイプである場合には、イントラ予測情報がイントラデコーダ(872)に提供される。残差情報は、逆量子化を受けることができ、残差デコーダ(873)に提供される。

【0087】

インターデコーダ(880)は、インター予測情報を受信し、該インター予測情報に基づいてインター予測結果を生成するように構成されてもよい。

【0088】

イントラデコーダ(872)は、イントラ予測情報を受信し、該イントラ予測情報に基づいて予測結果を生成するように構成されてもよい。

【0089】

残差デコーダ(873)は、逆量子化を実行して量子化解除された変換係数を抽出し、量子化解除された変換係数を処理して、残差を周波数領域から空間領域に変換するように構成されてもよい。残差デコーダ(873)はまた、特定の制御情報(量子化器パラメータ(QP)を含む)をも利用してもよく、その情報は、エントロピーデコーダ(871)によって提供されてもよい(これは、低データボリュームの制御情報のみであるため、データ経路は描かれていない)。

【0090】

再構成モジュール(874)は、空間領域において、残差デコーダ(873)によって出力される残差と、予測結果(場合に応じてイントラ又はインター予測モジュールによって出力される)とを組み合わせて、再構成されたビデオの一部として再構成されたピクチャの一部を形成する再構成されたブロックを形成するように構成されてもよい。視覚的品質を改善するためにデブロッキング動作等の他の好適な動作も実行されてもよいことを注意しておく。

【0091】

なお、ビデオエンコーダ(403)、(603)、(703)、及びビデオデコーダ(410)、(510)、(810)は、任意の好適な技術を用いて実装できる。いくつかの例示的な実施形態では、ビデオエンコーダ(403)、(603)、(703)及びビデオデコーダ(410)、(510)、(810)は、1つ以上の集積回路を使用して実装できる。別の実施形態では、ビデオエンコーダ(403)、(603)、(703)、及びビデオデコーダ(410)、(510)、(810)は、ソフトウェア命令を実行する1つ以上のプロセッサを使用して実装できる。

【0092】

符号化ブロックパーティション(分割)に関して、いくつかの例示的な実装では、所定のパターンが適用されてもよい。図９に示すように、第1の所定のレベル(例えば、64×64ブロックレベル)から始まり第2の所定のレベル(例えば、4×4レベル)までの例示的な4通りのパーティションツリーが使用されてもよい。例えば、ベースブロックは、902、904、906及び908で示される4つのパーティションの選択肢の対象となってもよく、Rとして指定されるパーティションは、図９に示すものと同じパーティションツリーが最低レベル(例えば、4×4レベル)まで低いスケールで繰り返されてもよいという再帰的パーティションで可能になる。いくつかの実装では、図９のパーティション方式に更なる制限が適用されてもよい。図９の実装では、長方形パーティション(例えば、1:2/2:1の長方形パーティション)は許可され得るが再帰的にすることは許可されず、正方形パーティションは再帰的にすることが許可される。図９に従った再帰によるパーティションは、必要に応じて、符号化ブロックの最終セットを生成する。このような方式は、カラーチャネルの1つ以上に適用してもよい。

【0093】

図１０は、パーティションツリーを形成するために再帰的パーティションを許可する別の所定のパーティションパターンの例を示す。図１０に示すように、例えば10通りのパーティション構造又はパターンが予め定義されてもよい。ルートブロックは、所定のレベルで(例えば、128×128レベル又は64×64レベルから)開始してもよい。図１０の例示的なパーティション構造は、様々な2:1/1:2及び4:1/1:4の長方形パーティションを含む。図１０の2行目に1002、1004、1006及び1008と示されている3つのサブパーティションを有するパーティションタイプは、「Tタイプ」パーティションと呼ばれてもよい。「Tタイプ」パーティション1002、1004、1006及び1008は、左Tタイプ、上Tタイプ、右Tタイプ及び下Tタイプと呼ばれてもよい。いくつかの実装では、図１０の長方形パーティションのどれも、更に細分されることが許可されない。ルートノード又はルートブロックからの分割の深さを示すために、符号化ツリー深さが更に定義されてもよい。例えば、128×128ブロックの例では、ルートノード又はルートブロックの符号化ツリー深さは0に設定されてもよく、図１０に従ってルートブロックを更に一回分割した後に、符号化ツリー深さは1だけ増加する。いくつかの実装では、1010における全正方形パーティションのみが、図１０のパターンに従って次のレベルのパーティションツリーへの再帰的パーティショニングを許可されてもよい。言い換えると、パターン1002、1004、1006及び1006を有する正方形パーティションでは、再帰的パーティションが許可されなくてもよい。図１０に従った再帰によるパーティションは、必要に応じて、符号化ブロックの最終セットを生成する。このような方式は、カラーチャネルの1つ以上に適用してもよい。

【0094】

上記のパーティション手順又は他の手順のいずれかに従ってベースブロックを分割又はパーティションした後に、再び、最終的なセットのパーティション又は符号化ブロックが取得されてもよい。これらのパーティションのそれぞれは、様々なパーティションレベルの1つになってもよい。パーティションのそれぞれは、符号化ブロック(CB, coding block)と呼ばれてもよい。上記の様々な例示的なパーティションの実装では、結果として得られる各CBは、許容サイズ及びパーティションレベルのいずれかにすることができる。これらは、いくつかの基本的な符号化/復号決定が行われ、符号化/復号パラメータが最適化されて決定されて符号化ビデオビットストリームで信号伝達され得る単位を形成する可能性があるので、符号化ブロックと呼ばれる。最終的なパーティションにおける最上位レベルは、符号化ブロックパーティションツリーの深さを表す。符号化ブロックはルマ符号化ブロック又はクロマ符号化ブロックでもよい。

【0095】

いくつかの他の例示的な実装では、ベースのルマ及びクロマブロックを再帰的に符号化ユニットに分割するために四分木構造が使用されてもよい。このような分割構造は符号化ツリーユニット(CTU, coding tree unit)と呼ばれてもよく、CTUは、ベースCTUの様々な局所特性にパーティションを適応させるために四分木構造を使用することによって符号化ユニット(CU)に分割される。このような実装では、暗黙的な四分木分割がピクチャ境界で実行されてもよく、その結果、サイズがピクチャ境界に適合するまでブロックが四分木分割を保持するようになる。CUという用語は、ルマ及びクロマ符号化ブロック(CB, coding block)の単位を総称するために使用される。

【0096】

いくつかの実装では、CBは更にパーティションされてもよい。例えば、CBは、符号化及び復号プロセス中のイントラ又はインターフレーム予測の目的で、複数の予測ブロック(PB, prediction block)に更に分割されてもよい。言い換えると、CBは異なるサブパーティションに更に分割されてもよく、そこで個々の予測の決定/構成が行われてもよい。並行して、CBは、ビデオデータの変換又は逆変換が実行されるレベルを示す目的で、複数の変換ブロック(TB, transform block)に更にパーティションされてもよい。CBのPB及びTBへのパーティション方式は同じでもよく、或いは、同じでなくてもよい。例えば、各パーティション方式は、例えば、ビデオデータの様々な特性に基づいて、独自の手順を使用して実行されてもよい。いくつかの例示的な実装では、PB及びTBのパーティション方式は独立してもよい。いくつかの他の例示的な実装では、PB及びTBのパーティション方式及び境界は相関してもよい。いくつかの実装では、例えば、TBはPBパーティションの後にパーティションされてもよく、特に、各PBは、符号化ブロックのパーティションに続いて決定された後に、1つ以上のTBに更にパーティションされてもよい。例えば、いくつかの実装では、PBは1つ、2つ、4つ又は他の数のTBに分割されてもよい。

【0097】

いくつかの実装では、ベースブロックの符号化ブロックへのパーティションのために、また、予測ブロック及び/又は変換ブロックへのパーティションのために、ルマチャネル及びクロマチャネルは別々に扱われてもよい。例えば、いくつかの実装では、符号化ブロックの予測ブロック及び/又は変換ブロックへのパーティションはルマチャネルについて許可されてもよいが、符号化ブロックの予測ブロック及び/又は変換ブロックへのこのようなパーティションはクロマチャネルについて許可されなくてもよい。このような実装では、ルマブロックの変換及び/又は予測は、符号化ブロックレベルでのみ実行されてもよい。別の例では、ルマチャネル及びクロマチャネルの最小変換ブロックサイズは異なってもよく、例えば、ルマチャネルの符号化ブロックは、クロマチャネルよりも小さい変換ブロック及び/又は予測ブロックにパーティションされることが許可されてもよい。更に別の例では、符号化ブロックの変換ブロック及び/又は予測ブロックへのパーティションの最大深さは、ルマチャネルとクロマチャネルとの間で異なってもよく、例えば、ルマチャネルの符号化ブロックは、クロマチャネルよりも深い変換ブロック及び/又は予測ブロックにパーティションされることが許可されてもよい。具体例として、ルマ符号化ブロックは、2つのレベルまで降りる再帰的パーティションで表されることができる複数のサイズの変換ブロックにパーティションされてもよく、正方形、2:1/1:2及び4:1/1:4のような変換ブロック形状と、4×4から64×64までの変換ブロックサイズとが許可されてもよい。しかし、クロマブロックについては、ルマブロックに指定された最大の可能な変換ブロックのみが許可されてもよい。

【0098】

符号化ブロックをPBにパーティションするいくつかの例示的な実装では、PBパーティションの深さ、形状及び/又は他の特性は、PBがイントラ符号化されるかインター符号化されるかに依存してもよい。

【0099】

符号化ブロック(又は予測ブロック)の変換ブロックへのパーティションは様々な例示的な方式で実施されてもよく、四分木分割及び所定のパターンの分割、再帰的又は非再帰的、並びに、符号化ブロック又は予測ブロックの境界における変換ブロックの更なる考慮を伴うものを含むがこれに限定されない。一般的に、結果の変換ブロックは、異なる分割レベルとなってもよく、同じサイズでなくてもよく、正方形の形状である必要がなくてもよい(例えば、いくつかの許可されたサイズ及びアスペクト比を有する長方形とすることができる)。

【0100】

いくつかの実装では、符号化パーティションツリー方式又は構造が使用されてもよい。ルマチャネル及びクロマチャネルに使用される符号化パーティションツリー方式は同じである必要はなくてもよい。言い換えると、ルマチャネル及びクロマチャネルは別々の符号化ツリー構造を有してもよい。さらに、ルマチャネル及びクロマチャネルが同じ符号化パーティションツリー構造を使用するか異なる符号化パーティションツリー構造を使用するか、及び実際に使用される符号化パーティションツリー構造は、符号化されているスライスがPスライスであるかBスライスであるかIスライスであるかに依存してもよい。例えば、Iスライスについては、クロマチャネル及びルマチャネルは別々の符号化パーティションツリー構造又は符号化パーティションツリー構造モードを有してもよいが、P又はBスライスについては、ルマチャネル及びクロマチャネルは同じ符号化パーティションツリー方式を共有してもよい。別々の符号化パーティションツリー構造又はモードが適用される場合、ルマチャネルは1つの符号化パーティションツリー構造によってCBにパーティションされてもよく、クロマチャネルは別の符号化パーティションツリー構造によってクロマCBにパーティションされてもよい。

【0101】

符号化ブロック及び変換ブロックのパーティションの具体例の実装について、以下に説明する。このような例示的な実装では、上記の再帰的な四分木分割を使用して、ベース符号化ブロックが符号化ブロックに分割されてもよい。各レベルにおいて、特定のパーティションの更なる四分木分割を継続するか否かは、局所ビデオデータ特性によって決定されてもよい。結果のCBは、様々なサイズの様々な四分木分割レベルになってもよい。インターピクチャ(時間)予測を使用してピクチャ領域を符号化するかイントラピクチャ(空間)予測を使用してピクチャ領域を符号化するかの決定は、CBレベル(又は全ての3つのカラーチャネルについてCUレベル)で行われてもよい。各CBは、PB分割タイプに従って、1つ、2つ、4つ又は他の数のPBに更に分割されてもよい。1つのPBの内部では、同じ予測プロセスが適用されてもよく、関連する情報がPBベースでデコーダに送信される。PB分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後に、CBの符号化ツリーと同様の別の四分木構造に従ってCBがTBにパーティションできる。この特定の実装では、CB又はTBは正方形の形状でもよいが、それに限定される必要はない。さらに、この特定の例では、PBはインター予測については正方形又は長方形の形状でもよく、イントラ予測については正方形の形状のみでもよい。符号化ブロックは、例えば4つの正方形のTBに更に分割されてもよい。各TBは再帰的に(四分木分割を使用して)より小さいTBに更に分割されてもよく、これは残差四分木(RQT, Residual Quad-Tree)と呼ばれる。

【0102】

ベース符号化ブロックをCB及び他のPB及び/又はTBにパーティションする別の具体例について、以下に説明する。例えば、図１０に示すような複数のパーティションユニットタイプを使用するのではなく、二分割及び三分割のセグメント構造を使用したネスト型マルチタイプツリーを有する四分木が使用されてもよい。CB、PB及びTBの概念の分離(すなわち、CBのPB及び/又はTBへのパーティション、及びPBのTBへのパーティション)は、最大変換長にとって大きすぎるサイズを有するCBに必要な場合を除き、破棄されてもよく、このようなCBは更に分割する必要があってもよい。この例示的なパーティション方式は、更なるパーティションを行わずに予測及び変換の双方がCBレベルで実行できるように、CBパーティション形状についてのより大きい柔軟性をサポートするように設計されてもよい。このような符号化ツリー構造では、CBは正方形又は長方形のいずれかの形状を有してもよい。具体的には、符号化ツリーブロック(CTB, coding tree block)は最初に四分木構造によってパーティションされてもよい。次いで、四分木リーフノードはマルチタイプツリー構造によって更にパーティションされてもよい。マルチタイプツリー構造の例が図１１に示されている。具体的には、図１１の例示的なマルチタイプツリー構造は、垂直二分割(SPLIT_BT_VER)(1102)、水平二分割(SPLIT_BT_HOR)(1104)、垂直三分割(SPLIT_TT_VER)(1106)及び水平三分割(SPLIT_TT_HOR)(1108)と呼ばれる四つの分割タイプを含む。次いで、CBはマルチタイプツリーのリーフに対応する。この例示的な実装では、CBが最大変換長にとって大きすぎない限り、このセグメンテーションは、更なるパーティションを行うことなく予測及び変換処理の双方に使用される。これは、ほとんどの場合、CB、PB及びTBがネスト型マルチタイプのツリー符号化ブロック構造を有する四分木で同じブロックサイズを有することを意味する。例外は、サポートされる最大変換長がCBの色成分の幅又は高さよりも小さい場合に発生する。

【0103】

1つのCTBについてのブロックパーティションのネスト型マルチタイプツリー符号化ブロック構造を有する四分木の一例が図１２に示されている。より詳細には、図１２は、CTB1200が四つの正方形のパーティション1202、1204、1206及び1208に分割された四分木であることを示している。分割のために図１１のマルチタイプツリー構造を更に使用することに関する決定は、四分木分割パーティションのそれぞれについて行われる。図１２の例では、パーティション1204は更に分割されない。パーティション1202及び1208はそれぞれ別の四分木分割を採用する。パーティション1202については、第2レベルの四分木分割の左上、右上、左下及び右下のパーティションは、それぞれ第3レベルの四分木の分割、図１１の1104、分割なし及び図１１の1108を採用する。パーティション1208は別の四分木分割を採用し、第2レベルの四分木分割の左上、右上、左下及び右下のパーティションは、それぞれ図１１の1106の第3レベルの分割、分割なし、分割なし及び図１１の1104を採用する。1208の第3レベルの左上のパーティションのサブパーティションのうち2つは、1104及び1108に従って更に分割される。パーティション1206は、2つのパーティションへの図11の1102に従った第2レベルの分割パターンを採用し、2つのパーティションは図１１の1108及び1102に従って第3レベルで更に分割される。図１１の1104に従って、第4レベルの分割がこれらのうち1つに更に適用される。

【0104】

上記の具体例では、最大ルマ変換サイズは64×64でもよく、サポートされる最大クロマ変換サイズはルマと異なってもよく、例えば、32×32でもよい。ルマ符号化ブロック又はクロマ符号化ブロックの幅又は高さが最大変換幅又は高さよりも大きい場合、ルマ符号化ブロック又はクロマ符号化ブロックは、水平方向及び/又は垂直方向に自動的に分割され、その方向の変換サイズの制限を満たしてもよい。

【0105】

上記のベース符号化ブロックをCBにパーティションする具体例では、符号化ツリー方式はルマ及びクロマが別々のブロックツリー構造を有する機能をサポートしてもよい。例えば、Pスライス及びBスライスについて、1つのCTU内のルマCTB及びクロマCTBは同じ符号化ツリー構造を共有してもよい。例えば、Iスライスについて、ルマ及びクロマは別々の符号化ブロックツリー構造を有してもよい。別々のブロックツリーモードが適用される場合、ルマCTBは1つの符号化ツリー構造によってルマCBにパーティションされてもよく、クロマCTBは別の符号化ツリー構造によってクロマCBにパーティションされる。これは、Iスライス内のCUがルマ成分の符号化ブロック又は2つのクロマ成分の符号化ブロックで構成されてもよく、ビデオがモノクロでない限り、P又はBスライス内のCUが常に全ての3つの色成分の符号化ブロックで構成されることを意味する。

【0106】

符号化ブロック又は予測ブロックを変換ブロックにパーティションするための例示的な実装、及び変換ブロックの符号化順序について、以下に更に詳細に説明する。いくつかの例示的な実装では、変換パーティションは、例えば4×4から64×64の範囲の変換ブロックサイズによって、例えば1:1(正方形)、1:2/2:1及び1:4/4:1の複数の形状の変換ブロックをサポートしてもよい。いくつかの実装では、符号化ブロックが64×64以下である場合、変換ブロックのパーティションはルマ成分にのみ適用されてもよく、クロマブロックについては、変換ブロックサイズは符号化ブロックサイズと同じである。そうでなく、符号化ブロックの幅又は高さが64よりも大きい場合、ルマ符号化ブロック及びクロマ符号化ブロックの双方が、それぞれmin(W,64)×min(H,64)及びmin(W,32)×min(H,32)の倍数の変換ブロックに暗黙的に分割されてもよい。

【0107】

いくつかの例示的な実装では、イントラ符号ブロック及びインター符号化ブロックの双方について、符号化ブロックは、所定数のレベル(例えば、2レベル)までのパーティション深さによって複数の変換ブロックに更にパーティションされてもよい。変換ブロックのパーティション深さ及びサイズは関連してもよい。現在の深さの変換サイズから次の深さの変換サイズへの例示的なマッピングが以下の表１に示されている。

【表1】

【0108】

表１の例示的なマッピングに基づいて、1:1正方形ブロックについて、次のレベルの変換分割が4つの1:1正方形サブ変換ブロックを作成してもよい。変換パーティションは、例えば4×4で停止してもよい。したがって、現在の深さについて4×4の変換サイズは、次の深さについて4×4の同じサイズに対応する。表１の例では、1:2/2:1非正方形ブロックについて、次のレベルの変換分割が2つの1:1正方形サブ変換ブロックを作成し、1:4/4:1非正方形ブロックについて、次のレベルの変換分割が2つの1:2/2:1サブ変換ブロックを作成する。

【0109】

いくつかの例示的な実装では、イントラ符号化ブロックのルマ成分について、更なる制限が適用されてもよい。例えば、変換パーティションのレベル毎に、全てのサブ変換ブロックが同じサイズを有するように制限されてもよい。例えば、32×16符号化ブロックについて、レベル1の変換分割が2つの16×16サブ変換ブロックを作成し、レベル2の変換分割が8つの8×8サブ変換ブロックを作成する。言い換えると、変換ユニットを同じサイズに保持するために、第2レベルの分割が全ての第1レベルのサブブロックに適用されなければならない。表１に従ったイントラ符号化された正方形ブロックについての変換ブロックパーティションの例が、矢印で示す符号化順序と共に図１３に示されている。具体的には、1302は正方形の符号化ブロックを示す。表１に従った4つの等しいサイズの変換ブロックへの第1レベルの分割が、矢印で示す符号化順序と共に1304に示されている。表１に従った第1レベルの等しいサイズのブロックの全ての16個の等しいサイズの変換ブロックへの第2レベルの分割が、矢印で示す符号化順序と共に1306に示されている。

【0110】

いくつかの例示的な実装では、インター符号化ブロックのルマ成分について、上記のイントラ符号化の制限が適用されなくてもよい。例えば、第1レベルの変換分割の後に、サブ変換ブロックのいずれか1つは1つの更なるレベルで独立して更に分割されてもよい。したがって、結果の変換ブロックは同じサイズでもよく、或いは、同じサイズでなくてもよい。インター符号化ブロックをその符号化順序で変換ロックに分割する例が、図１４に示されている。図１４の例では、インター符号化ブロック1402は、表１に従って2つのレベルで変換ブロックに分割される。第1レベルでは、インター符号化ブロックは、等しいサイズの4つの変換ブロックに分割される。次いで、4つの変換ブロックのうち1つのみ(全てではない)が4つのサブ変換ブロックに更に分割され、その結果、1404で示すように、2つの異なるサイズを有する合計で7つの変換ブロックを生じる。これらの7つの変換ブロックの例示的な符号化順序が、図１４の1404において矢印で示されている。

【0111】

いくつかの例示的な実装では、クロマ成分について、変換ブロックのいくつかの更なる制限が適用されてもよい。例えば、クロマ成分について、変換ブロックサイズは符号化ブロックサイズと同じ大きさにすることができるが、所定のサイズ、例えば8×8よりも小さくすることはできない。

【0112】

いくつかの他の例示的な実装では、幅(W)又は高さ(H)のいずれかが64よりも大きい符号化ブロックについて、ルマ符号化ブロック及びクロマ符号化ブロックの双方は、それぞれmin(W,64)×min(H,64)及びmin(W,32)×min(H,32)の倍数の変換ユニットに暗黙的に分割されてもよい。

【0113】

図１５は、符号化ブロック又は予測ブロックを変換ブロックにパーティションするための別の例示的な方式を更に示す。図１５に示すように、再帰的な変換パーティションを使用する代わりに、所定のセットのパーティションタイプが符号化ブロックの変換タイプに従って符号化ブロックに適用されてもよい。図１５に示す特定の例では、符号化ブロックを様々な数の変換ブロックに分割するために、6つの例示的なパーティションタイプのうち1つが適用されてもよい。このような方式は、符号化ブロック又は予測ブロックのいずれかに適用されてもよい。

【0114】

より詳細には、図１５のパーティション方式は、図１５に示すいずれか所与の変換タイプについて最大で6つのパーティションタイプを提供する。この方式では、各符号化ブロック又は予測ブロックは、例えばレート歪みコストに基づいて変換タイプを割り当てられてもよい。一例では、符号化ブロック又は予測ブロックに割り当てられるパーティションタイプは、符号化ブロック又は予測ブロックの変換パーティションタイプに基づいて決定されてもよい。特定のパーティションタイプは、図１５に示す4つのパーティションタイプで示すように、変換ブロック分割サイズ及びパターン(又はパーティションタイプ)に対応してもよい。様々な変換タイプと様々なパーティションタイプとの間の対応関係が予め定義されてもよい。レート歪みコストに基づいて符号化ブロック又は予測ブロックに割り当てられ得る変換タイプを示す大文字ラベルとの例示的な対応関係が以下に示される。

【0115】

・PARTITION_NONE:ブロックサイズに等しい変換サイズを割り当てる。

【0116】

・PARTITION_SPLIT:ブロックサイズの幅の1/2及びブロックサイズの高さの1/2の変換サイズを割り当てる。

【0117】

・PARTITION_HORZ:ブロックサイズと同じ幅及びブロックサイズの1/2の高さの変換サイズを割り当てる。

【0118】

・PARTITION_VERT:ブロックサイズの幅の1/2及びブロックサイズと同じ高さの変換サイズを割り当てる。

【0119】

・PARTITION_HORZ4:ブロックサイズと同じ幅及びブロックサイズの1/4の高さの変換サイズを割り当てる。

【0120】

・PARTITION_VERT4:ブロックサイズの幅の1/4及びブロックサイズと同じ高さの変換サイズを割り当てる。

【0121】

上記の例では、図１５に示すパーティションタイプは全て、パーティションされた変換ブロックについて均一な変換サイズを含む。これは限定ではなく単なる例である。他のいくつかの実装では、特定のパーティションタイプ(又はパターン)においてパーティションされた変換ブロックに、混合した変換ブロックサイズが使用されてもよい。

【0122】

符号化ブロック/ユニットについての特定のタイプの信号伝達のいくつかの例示的な実装に関して、以下の表２の例示的なシンタックスに示すように、各イントラ及びインター符号化ユニットについて、あるフラグ、すなわちskip_txfmフラグが符号化ビットストリームで信号伝達されてもよく、ビットストリームからこれらのフラグを取得するためにread_skip()関数によって表されてもよい。このフラグは、現在符号化ユニットにおいて変換係数が全て0であるか否かを示してもよい。いくつかの例示的な実装では、例えばこのフラグが値1で信号伝達される場合、別の変換係数に関するシンタックス、例えばEOB(End of Block)は、符号化ユニットのどの符号化ブロックについても信号伝達される必要はなく、0の変換係数のブロックについて予め定義されて関連付けられた値又はデータ構造として導出できる。インター符号化ブロックについて、表２の例に示すように、このフラグは、様々な理由で符号化ユニットがスキップされ得ることを示すskip_modeフラグの後に信号伝達されてもよい。skip_modeがtrueである場合、符号化ユニットはスキップされるべきであり、skip_txfmフラグを信号伝達する必要はなく、skip_txfmフラグは1として推定される。そうでなく、skip_modeがfalseである場合、符号化ユニットに関する詳細情報がビットストリームに含まれ、符号化ユニットが全て0であるか否かを示すためにskip_txfmフラグが更に信号伝達される。

【表2】

【0123】

色成分のそれぞれにおける残差の変換係数の符号化及び復号(エントロピーコーディング)に関して、各変換ブロックについて、変換係数の符号化はスキップ符号の信号伝達から始まり、スキップ符号が0である場合(すなわち、変換符号化がスキップされない場合)、変換カーネルタイプ及びEOB(End-of-Block)位置が続く。次いで、そのレベル(値の範囲)に基づいて、各係数値が対応するレベルマップ及び符号にマッピングされる。

【0124】

EOB位置が符号化された後に、低レベルのマップ及び中間レベルのマップが逆方向スキャン順序で符号化されてもよく、前者は係数の大きさが低レベル内(例えば、0から2の間)にあるか否かを示し、後者は範囲が3から14の間にあるか否かを示す。次のステップは、高レベル(例えば、14)よりも大きい係数の残差値だけでなく、係数の符号も、順方向スキャン順序で、例えばExp-Golomb符号によって符号化する。

【0125】

コンテキストモデリングの使用に関して、低レベルのマップの符号化は、圧縮効率の改善のために、変換サイズ及び方向と、最大で5つの隣接係数情報とを組み込んでもよい。他方、中間レベルのマップの符号化は、隣接係数の数が2まで小さくなることを除いて、低レベルの振幅符号化と同様の手法に従ってもよい。AC係数の符号と残差レベルのExp-Golomb符号はコンテキストモデルなしで符号化されてもよく、DC係数の符号はその隣接変換ブロックのDC符号を使用して符号化されてもよい。変換ブロックが0の係数のみを有するか、少なくとも1つの0でない係数を有するかを示すEOBフラグを符号化するために、均一なコンテキストモデリングを使用する代わりに、異なる色成分に対して異なるコンテキストモデリングが選択されてもよい。例えば、ルマ色成分について7つのコンテキストが使用されてもよい。EOBフラグを符号化するためのコンテキストは、上及び左隣接ルマ変換係数レベルに依存してもよく、及び/又は現在符号化ブロックサイズ及び変換ブロックサイズが同じであるか否かに依存してもよい。別の例では、クロマ色成分について、同じ方法を使用してU及びV色成分に適用される別々のコンテキストモデリングで6つのコンテキスト(U成分について3つのコンテキスト及びV成分について3つのコンテキスト)が使用されてもよく、コンテキストモデルの導出は、変換ブロックサイズ及び/又は上及び左隣接変換係数ブロックに依存してもよい。

【0126】

いくつかの例示的な実装では、クロマ残差は一緒に符号化されてもよい。このような符号化方式は、クロマチャネルの間の何らかの統計的相関に基づいてもよい。例えば、多くの場合、Cr及びCbクロマ係数は振幅が似ている可能性があるため、例えば変換係数が信号伝達される変換ブロックレベルでは、小さい色の歪みを導入するだけで符号化効率を改善するために一緒に符号化されてもよい。ジョイントクロマ符号化モードの使用(活性化)は、例えば、変換ユニット(ルマ及びクロマの双方を含むTU)又は変換ブロックレベルのフラグtu_joint_cbcr_residual_flagによって示されてもよく、選択されたモードはクロマ符号化ブロックフラグ(CBF, Coded Bock Flag)によって暗黙的に示される。

【0127】

具体的には、TUの一方又は双方のクロマCBFが1に等しい場合、フラグtu_joint_cbcr_residual_flagが存在してもよい。ピクチャパラメータセット(PPS, Picture Parameter Set)及びスライスヘッダにおいて、通常のクロマ残差符号化モードについて信号伝達されるクロマQPオフセット値と区別するために、ジョイントクロマ残差符号化モードについてクロマ量子化パラメータ(QP, quantization parameter)オフセット値が信号伝達されてもよい。これらのクロマQPオフセット値は、ジョイントクロマ残差符号化モードを使用して符号化されたブロックのクロマQP値を導出するために使用されてもよい。対応するジョイントクロマ符号化モード(下記の表３のモード2)がTUにおいてアクティブである場合、このクロマQPオフセットは、そのTUの量子化及び復号中に、適用されるルマから導出されるクロマQPに追加されてもよい。他のモード(表３のモード1及び3)については、従来のCb又はCrブロックと同様にクロマQPが導出される。送信された変換ブロックからのクロマ残差(resCb及びresCr)の再構成プロセスが表３に示されている。このモードが活性化されると(モード2)、単一のジョイントクロマ残差ブロック(表３のresJointC[x][y])が信号伝達され、Cbの残差ブロック(resCb)及びCrの残差ブロック(resCr)が、変換ブロックレベルではなく、tu_cbf_cb、tu_cbf_cr及びCSign(例えば、スライスヘッダで指定された符号値)のような情報を考慮して導出されてもよい。いくつかの実装では、CSignはほとんどの場合に-1でもよい。

【0128】

表３はクロマ残差再構成の様々なモードを示す。値CSignは符号値(+1又は1)であり、これはスライスヘッダで指定される。resJointC[][]は送信される残差である。

【表3】

【0129】

いくつかの例示的な実装では、上記の3つのジョイントクロマ符号化モードは、イントラ符号化CUでのみサポートされてもよい。インター符号化CUでは、モード2のみがサポートされる。したがって、インター符号化CUでは、シンタックスエレメントtu_joint_cbcr_residual_flagは、双方のクロマCBFが1である場合にのみ存在してもよい。

【0130】

特に、第1の色成分の係数符号値を利用して第2の色成分の係数符号を符号化する、成分間係数符号の符号化方法が実装されてもよい。例えば、Cb変換係数の符号値は、他のCr変換係数の符号を符号化するコンテキストとして使用されてもよい。このような成分間符号化は、色成分の変換係数ペア(係数毎)に実装されてもよい。このような実装の基礎となる原理、及び以下で更に詳細に説明する他の実装は、Cr及びCb成分に限定されない。これらは、3つの色成分の任意の2つの間で適用可能である。この点で、ルマチャネルは色成分の1つと考えられる。いくつかの実装では、U色成分とV色成分との間でEOBフラグの符号化に対して強い成分間の相関関係が存在し得る。すなわち、U色成分について0でないEOBフラグが信号伝達されている場合、同一位置のV色成分のEOBフラグも0でない可能性が高く、その逆も同様である。

【0131】

本開示では、クロマ成分(例えば、Cb成分及びCr成分、又はU成分及びV成分)の間、又はルマ成分とクロマ成分との間の相関関係を利用するための様々な実施形態が開示される。相関関係は、符号化及び信号伝達効率を改善するために、エンコーダ/デコーダによって使用されてもよい。これらの実施形態は、様々なビデオ符号化技術に適用されてもよい。また、これらの実施形態は、YCbCr、RGB等のような異なるカラーフォーマットに適用してもよい。YCbCrは、様々な実施形態を説明するための例としてのみ使用される。

【0132】

以下の例示的な実装では、クロマチャネルという用語は一般的にCb及びCrの双方の色成分(又はチャネル)、又はU及びVの双方の色成分(又はチャネル)を示してもよい。ルマチャネルという用語は、ルマ成分又はY成分を含んでもよい。ルマ成分又はチャネルは、ルマ色成分又はチャネルと呼ばれてもよい。以下ではY、U及びVが3つの色成分を表すために使用される。さらに、「符号化済みブロック」及び「符号化」ブロックという用語は、符号化されるべきブロック又は既に符号化されたブロックのいずれかを意味するために交換可能に使用される。これらは、3つの色成分のいずれかのブロックでもよい。3つの対応するカラー符号化済み/符号化ブロックは、符号化済み/符号化ユニットについてのものでもよい。

【0133】

或いは、いくつかの例示的な実装では、データブロックは3つの色成分を含んでもよい。言い換えると、データブロックは3つのレイヤを含み、各レイヤが1つの色成分に対応してもよい。いくつかの実装では、データブロック内の3つの色成分が同一位置にあってもよい。

【0134】

以下の例示的な実装では、「レベル値」という用語は、変換係数値の大きさ又は振幅を示してもよい。

【0135】

一実施形態では、ある色成分のEOBフラグは、別の色成分のEOBフラグをエントロピーコーディングするためのコンテキストを導出するために使用されてもよい。これら2つの色成分は同一位置にあってもよい。この開示では、2つの色成分が同じ空間位置にある場合、これらは同一位置にある。

【0136】

上記のある色成分及び別の色成分は特定の色成分に限定されなくてもよいが、いくつかの例示的な実装では、Cb(又はCr)色成分のEOBフラグは、Cr(又はCb)色成分のEOBフラグをエントロピーコーディングするためのコンテキストを導出するために使用されてもよい。

【0137】

ある実装では、ルマ(Y)色成分のEOBフラグは、Cb(及び/又はCr)色成分のEOBフラグをエントロピーコーディングするためのコンテキストを導出するために使用されてもよい。

【0138】

ある実装では、Cb(及び/又はCr)色成分のEOBフラグは、ルマ(Y)色成分のEOBフラグをエントロピーコーディングするためのコンテキストを導出するために使用されてもよい。

【0139】

いくつかの例示的な実装では、共有EOBフラグが複数の色成分について一緒に符号化及び/又は信号伝達されてもよい。共有EOBフラグの使用は、符号化効率を改善し、信号伝達オーバーヘッドを低減し得る。

【0140】

ある実装では、一緒に符号化されたEOBの1つの共通シンタックスが符号化及び/又は信号伝達されてもよく、共通シンタックスが複数の色成分のそれぞれのEOBフラグ値を示すために使用されてもよい。

【0141】

例えば、ルマEOBフラグ及びクロマEOBフラグは、例えば8つの異なる値によって1つのシンタックス(例えば、JOINT_EOB又はEOBS)を使用して一緒に符号化されてもよく、それぞれの値は複数の(例えば、3つの)成分の異なるEOBフラグ値の一意の組み合わせを示す。一例については、以下の表４を参照する。

【表4】

【0142】

別の例では、Cb EOBフラグ及びCr EOBフラグは4つの異なる値によって1つのシンタックス(例えば、JOINT_EOB)を使用して一緒に符号化され、それぞれの値はCb及びCr色成分の異なるEOBフラグ値の一意の組み合わせを示す。表４における同じ概念が、この例にも適用されてもよい。このような方式を使用して、符号化を改善するために様々な色成分のEOBフラグの間の相関関係を利用することが可能になる。例えば、表４におけるEOB値のいくつかは、他の値よりもはるかに高い確率を有してもよく(例えば、全ての色のEOBについて同じフラグ値を表す値111及び000)、それによって3つのEOBフラグが一緒に符号化されたときに優れた符号化効率を提供する。

【0143】

一実施形態では、成分毎にEOBフラグを直接信号伝達する代わりに、マルチレベルの符号化方式が実装されてもよい。この方式では、複数のフラグが実装されてもよい。複数の色成分のEOBが同じであるか否かを示すために、第1のフラグが符号化/信号伝達されてもよく、次いで、1つ以上の色成分(全ての色成分ではない)のEOBフラグを示すために、1つ以上のフラグが符号化/信号伝達され、信号伝達されたフラグに基づいて他の残りの色成分のEOBが導出できる。この方式は、以下の例によって更に説明される。

【0144】

ある実装では、この方式はCb及びCr成分に適用される。第1のフラグ(すなわち、flag0)は、Cb及びCrのEOBフラグが等しいか否かを示すために信号伝達されてもよく、次いで、第2のフラグ(すなわち、flag1)は、Cb(又はCr)のEOBフラグの値を示すために信号伝達されてもよい。例えば、CbのEOBフラグは0又は1として符号化/信号伝達されてもよい。次いで、flag0及びflag1に基づいてCr(又はCb)のEOBフラグの値が導出されてもよい。例えば、以下の通りである。

【0145】

flag0=1であり(すなわち、Cb及びCrのEOBフラグが等しい)、flag1=1である(例えば、Cb成分のEOBフラグが1である)場合、Cr成分のEOBフラグも1である。

【0146】

flag0=0であり(すなわち、Cb及びCrのEOBフラグが等しくない)、flag1=1である(例えば、Cb成分のEOBフラグが1である)場合、Cr成分のEOBフラグは0である。

【0147】

ある実装では、当該方式はルマ成分及び2つのクロマ成分に適用される。各成分のEOBフラグを決定するための例示的なフローについて、以下に説明する。

【0148】

1.第1のフラグ(すなわち、flag0)は、ルマ及びクロマEOBフラグが等しいか否かを示すために符号化/信号伝達されてもよい。

【0149】

2.第2のフラグ(すなわち、flag1)は、ルマEOBフラグが0であるか1であるかを示すために符号化/信号伝達されてもよい。

【0150】

flag0がルマ及びクロマEOBフラグが同じ値を有することを示す値で符号化/信号伝達される場合、flag1に基づいてCb及びCr成分のEOBフラグを導出する。EOBフラグの決定プロセスはここで終了してもよい。

【0151】

flag0がルマ及びクロマEOBフラグが異なる値を有することを示す値で符号化/信号伝達される場合、Cb及びCr成分が同じEOBフラグ値を有するか否かを更に示すために、第3のフラグ(すなわち、flag2)が符号化/信号伝達されてもよい。

【0152】

第4のフラグ(すなわち、flag3)は、Cb(又はCr)EOBフラグが0であるか1であるかを示すために符号化/信号伝達されてもよい。flag2及びflag3に基づいて、Cb及びCr成分のEOB値がそれに従って導出されてもよい。

【0153】

したがって、上記の最大で4つの信号伝達されたフラグに基づいて、ルマ、Cb及びCr色成分のEOB値がそれに従って導出されてもよい。

【0154】

CBFを使用してEOBを置き換える技術において、上記の実施形態で説明したのと同じ概念が適用されてもよく、ここでは詳細に説明しない。

【0155】

図１６はビデオデータを復号するための例示的な方法1600を示す。方法1600は、ビデオデータからデータブロックの第1の色成分に関連する第1のブロック終了(EOB, End of Block)フラグを受信するステップ1610と、ビデオデータのデータブロックの第2の色成分に関連する第2のEOBフラグに基づいて、第1のEOBフラグをエントロピー符号化するためのコンテキストを導出するステップ1620と、導出されたコンテキストに基づいて第1のEOBフラグのエントロピー復号を実行するステップ1630との一部又は全部を含んでもよい。ある実装では、第1の色成分は第2の色成分と同一位置にあってもよい。

【0156】

本開示の実施形態では、いずれかのステップ及び/又は動作が、必要に応じて組み合わされてもよく或いは任意の量又は順序で配置されてもよい。2つ以上のステップ及び/又は動作は並行して実行されてもよい。

【0157】

本開示の実施形態は、個別に使用されてもよく、或いは、任意の順序で組み合わされてもよい。さらに、方法(又は実施形態)、エンコーダ及びデコーダのそれぞれは、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では、1つ以上のプロセッサは、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。本開示の実施形態は、ルマブロック又はクロマブロックに適用されてもよい。

【0158】

上述の技術は、コンピュータ読み取り可能命令を用いてコンピュータソフトウェアとして実装することができ、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されることができる。例えば、図１７は、開示された主題の特定の実施形態を実施するのに好適なコンピュータシステム(1700)を示す。

【0159】

コンピュータソフトウェアは、任意の好適な機械コード又はコンピュータ言語を用いてコーディングされることができ、アセンブリ、コンパイル、リンク、又は同様の機構の対象とされて、1つ以上のコンピュータ中央処理ユニット(CPU)、グラフィックス処理ユニット(GPU)等によって、直接的に、又はインタープリット、マイクロコード実行等を通じて実行可能な命令を含むコードを作成することができる。

【0160】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイス等を含む様々なタイプのコンピュータ又はそのコンポーネント上で実行されることができる。

【0161】

コンピュータシステム(1700)について図１７に示されるコンポーネントは、例としての性質であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関する制限を示唆することを意図したものではない。コンポーネントの構成も、コンピュータシステム(1700)の例示的実施形態において示されているコンポーネントの任意の1つ又は組み合わせに関する何らかの依存性又は要件を有するものとして解釈されるべきではない。

【0162】

コンピュータシステム(1700)は、特定のヒューマンインターフェース入力デバイスを含むことができる。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力(例えば、キーストローク、スワイプ、データグローブの動き)、音声入力(例えば、声、拍手)、視覚入力(例えば、ジェスチャー)、嗅覚入力(図示せず)を通じた一又は複数の人間ユーザによる入力に応答することができる。また、ヒューマンインターフェースデバイスは、音声(例えば、発話、音楽、周囲の音)、画像(例えば、スキャンされた画像、スチール画像カメラから得られる写真画像)、ビデオ(例えば、2次元ビデオ、立体視ビデオを含む3次元ビデオ)のような、人間による意識的入力に必ずしも直接関係しない特定のメディアを捕捉するために使用できる。

【0163】

入力ヒューマンインターフェースデバイスは、キーボード(1701)、マウス(1702)、トラックパッド(1703)、タッチスクリーン(1710)、データグローブ(図示せず)、ジョイスティック(1705)、マイクロフォン(1706)、スキャナ(1707)、カメラ(1708)の1つ以上(それぞれの一つしか図示していない)を含んでいてもよい。

【0164】

コンピュータシステム(1700)はまた、特定のヒューマンインターフェース出力デバイスを含んでいてもよい。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、及び臭い/味を通じて、一又は複数の人間ユーザの感覚を刺激するものであってもよい。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス(例えば、タッチスクリーン(1710)、データグローブ(図示せず)、又はジョイスティック(1705)による触覚フィードバック；ただし、入力デバイスのはたらきをしない触覚フィードバックデバイスもあり得る)、音声出力デバイス(例えば、スピーカー(1709)、ヘッドフォン(図示せず))、視覚出力デバイス(例えば、CRT画面、LCD画面、プラズマスクリーン、OLED画面を含む画面(1710)；それぞれはタッチスクリーン入力機能があってもなくてもよく、それぞれは触覚フィードバック機能があってもなくてもよく、そのうちのいくつかは、2次元の視覚出力又は立体視出力のような手段を通じた3次元より高い出力を出力することができる；仮想現実感眼鏡(図示せず)、ホログラフィーディスプレイ及び煙タンク(図示せず))、及びプリンタ(図示せず)を含んでいてもよい。

【0165】

コンピュータシステム(1700)はまた、人間がアクセス可能な記憶デバイス及び関連する媒体、例えば、CD/DVD又は類似の媒体(1721)とともにCD/DVD ROM/RW(1720)を含む光学式媒体、サムドライブ(1722)、取り外し可能なハードドライブ又はソリッドステートドライブ(1723)、テープ及びフロッピーディスクといったレガシー磁気媒体(図示せず)、セキュリティドングルのような特化したROM/ASIC/PLDベースのデバイス(図示せず)等を含むことができる。

【0166】

当業者はまた、現在開示されている主題に関連して使用される用語「コンピュータ読み取り可能媒体」は、伝送媒体、搬送波、又は他の一時的な信号を包含しないことを理解すべきである。

【0167】

コンピュータシステム(1700)はまた、1つ以上の通信ネットワーク(1755)へのインターフェース(1754)を含むことができる。ネットワークは、例えば、無線、有線、光学式であり得る。ネットワークは、さらに、ローカル、広域、都市圏、車載及び工業用、リアルタイム、遅延耐性等であり得る。ネットワークの例は、イーサネット〔登録商標〕、無線LAN、GSM、3G、4G、5G、LTE等を含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、地上放送テレビを含むTV有線又は無線の広域デジタルネットワーク、CAN Busを含む車載及び工業用等を含む。特定のネットワークは、普通、特定の汎用データポート又は周辺バス(1749)(例えば、コンピュータシステム(1700)のUSBポート等)に取り付けられる外部ネットワークインターフェースアダプターを必要とする。他は、普通、後述するようなシステムバスへの取り付けによって、コンピュータシステム(1700)のコアに統合される(例えば、PCコンピュータシステムへのイーサネットインターフェース又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース)。これらのネットワークのいずれかを使用して、コンピュータシステム(1700)は、他のエンティティと通信することができる。このような通信は、一方向性、受信のみ(例えば、放送テレビ)、一方向性送信専用(例えば、特定のCANbusデバイスへのCANbus)、又は、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向性であってもよい。上述のようなそれらのネットワーク及びネットワークインターフェースのそれぞれで、特定のプロトコル及びプロトコルスタックが使用できる。

【0168】

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインターフェースは、コンピュータシステム(1700)のコア(1740)に取り付けることができる。

【0169】

コア(1740)は、1つ以上の中央処理装置(CPU)(1741)、グラフィックス処理装置(GPU)(1742)、フィールドプログラマブルゲートアレイ(FPGA)(1743)の形式の特化したプログラマブル処理装置、特定のタスクのためのハードウェアアクセラレータ(1744)、グラフィックアダプター(1750)等を含むことができる。これらの装置は、読み取り専用メモリ(ROM)(1745)、ランダムアクセスメモリ(1746)、内部のユーザアクセス可能でないハードドライブ、ソリッドステートドライブ(SSD)等の内部大容量記憶デバイス(1747)とともに、システムバス(1748)を通じて接続され得る。いくつかのコンピュータシステムでは、追加のCPU、GPU等による拡張を可能にするために、システムバス(1748)は、1つ以上の物理プラグの形式でアクセス可能であってもよい。周辺デバイスは、コアのシステムバス(1748)に直接取り付けられることも、周辺バス(1749)を通じて取り付けられることもできる。一例では、グラフィックアダプター(1750)にスクリーン(1710)が接続されることができる。周辺バスのためのアーキテクチャは、PCI、USB等を含む。

【0170】

CPU(1741)、GPU(1742)、FPGA(1743)、及びアクセラレータ(1744)は、組み合わせて上述のコンピュータコードを構成することができる特定の命令を、実行することができる。そのコンピュータコードは、ROM(1745)又はRAM(1746)に記憶できる。一時的データも、RAM(1746)に記憶されることができ、一方、持続的データは、例えば、内部大容量記憶デバイス(1747)に記憶されることができる。1つ以上のCPU(1741)、GPU(1742)、大容量記憶デバイス(1747)、ROM(1745)、RAM(1746)等と密接に関連付けることができるキャッシュメモリを使用することを通じて、メモリデバイスのいずれかへの高速な記憶及び取り出しを可能にすることができる。

【0171】

コンピュータ読み取り可能媒体は、様々なコンピュータ実装された動作を実行するためのコンピュータコードをその上に有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構築されたものであってもよく、又は、コンピュータソフトウェア分野の技術を有する者に周知であり利用可能な種類のものであってもよい。

【0172】

非限定的な例として、アーキテクチャ(1700)、具体的にはコア(1740)を有するコンピュータシステムは、プロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)が1つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行することの結果として、機能性を提供することができる。このようなコンピュータ読み取り可能媒体は、上記で紹介したようなユーザアクセス可能な大容量記憶並びにコア内部の大容量記憶デバイス(1747)又はROM(1745)のような非一時的な性質のコア(1740)の特定の記憶に関連する媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶され、コア(1740)によって実行されることができる。

【0173】

本開示はいくつかの例示的な実施形態を記載しているが、変更、並べ替え及び様々な代替均等物が存在し、これらは本開示の範囲内に入る。したがって、当業者は、ここに明示的に図示又は記載されてないが、本開示の原則を具体化し、したがってその真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。

【0174】

付録A:略語
JEM: joint exploration model
VVC: versatile video coding
BMS: benchmark set
MV: Motion Vector
HEVC: High Efficiency Video Coding
SEI: Supplementary Enhancement Information
VUI: Video Usability Information
GOP: Group of Pictures
TU: Transform Unit
PU: Prediction Unit
CTU: Coding Tree Unit
CTB: Coding Tree Block
PB: Prediction Block
HRD: Hypothetical Reference Decoder
SNR: Signal Noise Ratio
CPU: Central Processing Unit
GPU: Graphics Processing Unit
CRT: Cathode Ray Tube
LCD: Liquid-Crystal Display
OLED: Organic Light-Emitting Diode
CD: Compact Disc
DVD: Digital Video Disc
ROM: Read-Only Memory
RAM: Random Access Memory
ASIC: Application-Specific Integrated Circuit
PLD: Programmable Logic Device
LAN: Local Area Network
GSM: Global System for Mobile communications
LTE: Long-Term Evolution
CANBus: Controller Area Network Bus
USB: Universal Serial Bus
PCI: Peripheral Component Interconnect
FPGA: Field Programmable Gate Area
SSD: solid-state drive
IC: Integrated Circuit
HDR: high dynamic range
SDR: standard dynamic range
JVET: Joint Video Exploration Team
MPM: most probable mode
WAIP: Wide-Angle Intra Prediction
CU: Coding Unit
PU: Prediction Unit
TU: Transform Unit
CTU: Coding Tree Unit
PDPC: Position Dependent Prediction Combination
ISP: Intra Sub-Partitions
SPS: Sequence Parameter Setting
PPS: Picture Parameter Set
APS: Adaptation Parameter Set
VPS: Video Parameter Set
DPS: Decoding Parameter Set
ALF: Adaptive Loop Filter
SAO: Sample Adaptive Offset
CC-ALF: Cross-Component Adaptive Loop Filter
CDEF: Constrained Directional Enhancement Filter
CCSO: Cross-Component Sample Offset
LSO: Local Sample Offset
LR: Loop Restoration Filter
AV1: AOMedia Video 1
AV2: AOMedia Video 2

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【国際調査報告】