JP7383038B2 - ビデオコーディングのための方法、装置及びプログラム - Google Patents

Description

参照による援用
本出願は、２０１９年８月１３日に出願された米国仮出願第６２／８８６，０５６号「ｍｐｒｏｖｅｄ ＳＰＳ Ｈｅａｄｅｒ Ｓｙｎｔａｘ ａｎｄ Ｄｅｓｃｒｉｐｔｏｒ ｆｏｒ ＣＴＵ Ｓｉｚｅ（改良されたＣＴＵサイズのためのＳＰＳヘッダ構文及び記述子）」に対する優先権の利益を主張する、２０２０年７月２８日に出願された米国特許出願第１６／９４１，１９３号「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ビデオ符号化のための方法及び装置）」に対する優先権の利益を主張する。先願の全ての開示は、完全に本願明細書に援用したものとする。

技術分野
本開示は、概して、ビデオコーディングに関連する実施形態を記載する。

本明細書で提供される背景説明は、本開示のコンテキストを全般的に提示するためのものである。現在挙げられている発明者の研究は、その研究がこの背景部分に記載されている範囲において、また、出願時に他の点では先行技術として適格でないかもしれない説明の側面において、本開示に対する先行技術として明示的にも黙示的にも認められていない。

ビデオコーディングとデコーディングは、動き補正を伴うインター画像予測（ｉｎｔｅｒ－ｐｉｃｔｕｒｅ ｐｒｅｄｉｃｔｉｏｎ）を用いて行うことができる。非圧縮ディジタルビデオは、一連の画像を含むことができ、各画像は、例えば、１９２０×１０８０の輝度サンプル及び関連する色サンプルの空間寸法を有する。一連の画像は、固定又は可変の画像レート（例えば、６０画像／秒又は６０Ｈｚ）を有することができる。非圧縮ビデオは、特定のビットレート要件を有する。例えば、サンプル当たり８ビットの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚのフレームレートでの１９２０ｘ１０８０の輝度サンプル解像度）は、１．５Ｇビット／秒に近い帯域幅を必要とする。このようなビデオの１時間は、６００Ｇバイトを超えるストレージ領域を必要とする。

ビデオコーディング及びデコーディングの１つの目的は、圧縮による入力ビデオ信号の冗長性の低減である。圧縮は、前述の帯域幅やストレージスペースの要件を、場合によっては２桁以上削減するのに役立つ。可逆圧縮と非可逆圧縮の両方、及びそれらの組み合わせを用いることができる。可逆圧縮とは、元の信号の正確なコピーを圧縮された元の信号から再構成することができる技術をいう。非可逆圧縮を使用する場合、再構成された信号は、元の信号と同一ではないかもしれないが、元の信号と再構成された信号との間の歪みは十分小さく、再構成された信号を意図された用途に役立てられる。ビデオの場合、非可逆圧縮が広く用いられている。許容される歪みの量は、用途に依存し、例えば、特定の消費者ストリーミング用途のユーザは、テレビ配信用途のユーザよりも高い歪みを容認し得る。達成可能な圧縮比は、より高い許容可能／容認可能歪みは、より高い圧縮比をもたらすことができることを反映することができる。

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

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

例えばＭＰＥＧ－２世代のコーディング技術から知られるような従来のイントラコーディングは、イントラ予測を使用しない。しかしながら、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に近接するデータのエンコード／デコード中に得られる周囲の、デコード順において先行するサンプルデータ及び／又はメタデータから、データのブロックを試行する技術を含む。このような技術は、以後「イントラ予測」技術と称される。少なくともいくつかのケースでは、イントラ予測は再構成中の現在の画像からの参照データのみを使用し、参照画像からは使用しないことに留意されたい。

さまざまな形式のイントラ予測があり得る。かかり技術のうちの１つ以上が、所与のビデオコーディング技術において用いられることができる場合、使用中の技術は、イントラ予測モードでコーディングされることができる。特定の場合には、モードは、サブモード及び／又はパラメータを有することができ、それらは、個別にコーディングされることができ、又はモードコード名（ｍｏｄｅ ｃｏｄｅｗｏｒｄ）に含まれることができる。所与のモード／サブモード／パラメータの組み合わせに用いられるコード名は、イントラ予測を通してコーディング効率ゲイン（ｃｏｄｉｎｇ ｅｆｆｉｃｉｅｎｃｙ ｇａｉｎ）に影響を与える可能性があり、同様に、コード名をビットストリームに変換するために使用されるエントロピーコーディング技術も同様に影響を与える可能性がある。

特定のイントラ予測モードがＨ．２６４で導入され、Ｈ．２６５で改良され、共同探索モデル（ＪＥＭ：ｊｏｉｎｔ ｅｘｐｌｏｒａｔｉｏｎ ｍｏｄｅｌ）、汎用ビデオコーディング（ＶＶＣ：ｖｅｒｓａｔｉｌｅ ｖｉｄｅｏ ｃｏｄｉｎｇ）、及びベンチマークセット（ＢＭＳ：ｂｅｎｃｈｍａｒｋ ｓｅｔ）等のより新しいコーディング技術でさらに改良された。予測子ブロックは、既に利用可能なサンプルに属する近接するサンプル値を使用して形成されることができる。隣接するサンプルのサンプル値は、方向にしたがって予測子ブロックにコピーされる。使用中の方向への参照は、ビットストリームでコーディングされることができ、又はそれ自体が予測されることがある。

図１Ａを参照すると、右下に示されているのは、（３５個のイントラモードの３３個の角度モードに対応する、）Ｈ．２６５の３３個の可能な予測子方向から知られる９個の予測子方向のサブセットである。矢印が集中する点（１０１）は、予測されているサンプルを表す。矢印は、サンプルが予測されている方向を示す。例えば、矢印（１０２）は、サンプル（１０１）が、１つ以上のサンプルから、水平から４５度の角度で右上に向かって予測されることを示す。同様に、矢印（１０３）は、サンプル（１０１）が、１つ以上のサンプル（１０１）から、水平方向から２２．５度の角度でサンプル（１０１）の左下へ予測されることを示す。

さらに図１Ａを参照すると、左上には、４×４サンプルの正方形ブロック（１０４）が示されている（破線の太線で示されている）。正方形ブロック（１０４）は、１６個のサンプルを含み、各サンプルは「Ｓ」でラベル付けされ、Ｙ次元におけるその位置（例えば、行インデックス）及びＸ次元におけるその位置（例えば、列インデックス）を含む。例えば、サンプルＳ２１は、Ｙ次元の（頂部から）２番目のサンプル及びＸ次元の（左側から）１番目のサンプルである。同様に、サンプルＳ４４は、ブロック（１０４）内でＹ及びＸ次元の両方において４番目のサンプルである。ブロックのサイズが４×４サンプルであるので、Ｓ４４は右下にある。さらに、同様の番号付けスキームにしたがった参照サンプルを示す。参照サンプルは、Ｒ、ブロック（１０４）に対するそのＹ位置（例えば、行インデックス）及びＸ位置（列インデックス）でラベル付けされる。Ｈ．２６４とＨ．２６５の両方で、予測サンプルは再構成中のブロックに隣接しているため、負の値を使用する必要はない。

イントラ画像予測は、信号予測方向に応じて、隣接するサンプルから参照サンプル値をコピーすることによって機能する。例えば、コーディングされたビデオビットストリームは、このブロックについて、矢印（１０２）と一致する予測方向を示す信号を含むと仮定する。すなわち、サンプルは、１つ以上の予測サンプルから右上へ、水平方向から４５度の角度で予測される。その場合、サンプルＳ４１、Ｓ３２、Ｓ２３、及びＳ１４は、同じ参照サンプルＲ０５から予測される。その後、サンプルＳ４４は、参照サンプルＲ０８から予測される。

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

ビデオコーディング技術の発達に伴って可能性のある方向の数が増加している。Ｈ．２６４（２００３年）では、９つの異なる方向を表すことができた。これは、Ｈ．２６５（２０１３年）で３３に増加し、開示時のＪＥＭ／ＶＶＣ／ＢＭＳでは、最大６５の方向性をサポートできる。最も可能性の高い方向を特定するために実験が行われており、エントロピーコーディングの特定の技術は、少数のビットにおいて、それらの可能性のある方向を表現するために用いられ、より可能性の低い方向に対する特定のペナルティを受け入れる。さらに、方向それ自体は、時々、近接する、すでにデコードされたブロックで使用される近接する方向から予測されることができる。

図１Ｂは、経時的に増加する予測方向の数を示すために、ＪＥＭによる６５のイントラ予測方向を示す概略図（１８０）を示す。

方向を表すコーディングされたビデオビットストリームにおけるイントラ予測方向ビットのマッピングは、ビデオコーディング技術からビデオコーディング技術へ異なることができ、例えば、予測方向の単純な直接マッピングから、イントラ予測モード、コード名、最も可能性の高いモードを含む複合適応方式、及び類似の技術にまで及ぶことができる。しかし、どのような場合でも、ビデオコンテンツにおいて、他の特定の方向よりも統計的に起こりにくい特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるので、良好に動作するビデオコーディング技術においては、より可能性の低い方向は、より可能性の高い方向よりもより多くのビット数によって表されるであろう。

動き補償は、非可逆圧縮技術であることができ、かつ、先行して再構成された画像又はその一部（参照画像）からのサンプルデータのブロックが、動きベクトル（以下、ＭＶとも称する。）によって示される方向に空間的にシフトされた後に、新たな再構成画像又はその一部の予測のために使用される技術に関連付けることができる。場合によっては、参照画像は現在再構成中の画像と同一であることもできる。ＭＶは、Ｘ及びＹの２次元、又は３次元を有することができ、第３次元は、使用中の参照画像の表示である（後者は、間接的に、時間次元であることができる）。

いくつかのビデオ圧縮技術では、サンプルデータの、あるエリアに適用可能なＭＶは、他のＭＶから、例えば、再構成中のエリアに空間的に隣接し、デコードの順序（ｄｅｃｏｄｉｎｇ ｏｒｄｅｒ）でそのＭＶに先行するサンプルデータの別のエリアに関連するＭＶから予測することができる。このようにして、ＭＶのコーディングに必要なデータ量を大幅に削減することができ、それによって冗長性を除去し、圧縮を増大させることができる。ＭＶ予測は効率的に作用することができ、なぜならば、例えば、（ナチュラルビデオとして既知の）カメラから導出された入力ビデオ信号をコーディングする場合、単一のＭＶが適用可能であるエリアよりも大きなエリアは、類似の方向に移動するという統計的可能性があり、したがって、場合によっては、隣接するエリアのＭＶから導出された類似の動きベクトルを用いて予測することができるからである。その結果、所与のエリアについて見出されたＭＶは、周囲のＭＶから予測されるＭＶと類似又は同一になり、それは、エントロピーコーディングの後、ＭＶを直接コーディングする場合に使用されるであろうものよりも、より少ない数のビットで表され得る。場合によっては、ＭＶ予測は、元の信号（すなわち、サンプルストリーム）から導出された信号（すなわち、ＭＶ）の可逆圧縮の例であり得る。他の場合には、ＭＶ予測それ自体は、例えば、いくつかの周囲ＭＶから予測子を計算する際の丸め誤差のために、非可逆的であり得る。

様々なＭＶ予測メカニズムがＨ．２６５／ＨＥＶＣ （ＩＴＵ－Ｔ Ｒｅｃ． Ｈ．２６５， Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ， Ｄｅｃｅｍｂｅｒ ２０１６）に、記述されている。Ｈ．２６５が提供する多くのＭＶ予測メカニズムのうち、ここでは、以後「空間マージ」と称されるテクニックについて説明する。

図２を参照すると、現在ブロック（２０１）は、空間的にシフトされた同じサイズの以前のブロックから予測可能であることが、モーションサーチプロセス中にエンコーダによって見出されたサンプルを含む。そのＭＶを直接コーディングする代わりに、１つ以上の参照画像に関連付けられたメタデータから、例えば、Ａ０、Ａ１、及びＢ０、Ｂ１、Ｂ２（それぞれ２０２から２０６）と示される５つの周囲のサンプルのいずれかに関連付けられたＭＶを使用して、（デコード順において）最新の参照画像から、ＭＶを導出することができる。Ｈ．２６５では、ＭＶ予測は、隣接ブロックが使用しているのと同じ参照画像からの予測子を使用することができる。

本開示の態様は、ビデオエンコード／デコードのための方法及び装置を提供する。いくつかの実施例では、ビデオデコードのための装置は、処理回路を含む。コード化されたビデオシーケンス内の画像のコード化された情報を受信することができる。コード化された情報は、画像に対して選択されたＣＴＵサイズを示すコーディングトリーユニット（ＣＴＵ）サイズ情報を含む。ＣＴＵサイズは短縮単項コード（ｔｒｕｎｃａｔｅｄ ｕｎａｒｙ ｃｏｄｅ）を用いてエンコードされている。処理回路は、前記短縮単項コードを用いてエンコードされたＣＴＵサイズ情報に基づいて、選択されたＣＴＵサイズを決定することができ、選択されたＣＴＵサイズに基づいて画像内のサンプルを再構成することができる。一実施形態において、前記選択されたＣＴＵサイズは、３２×３２、６４×６４又は１２８×１２８ルマサンプルである、

一実施形態において、処理回路は、短縮単項コードを用いてエンコードされたＣＴＵサイズ情報に基づいて、コード化された情報内のビットストリングからコード化された値を決定し、ビットストリング内の最大ビット数は２である。ビットストリングが０、１０及び１１である場合に、前記コード化された値はそれぞれ０，１及び２である。そして、処理回路は、コード化された値に基づいて選択されるＣＴＵサイズを決定することができる。

実施例において、処理回路は、コード化された値が０、１及び２である場合に、選択されたＣＴＵサイズが、それぞれ１２８、６４及び３２であることを決定することができる。処理回路は、選択されたＣＴＵサイズが、２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} になることを決定することができ、ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、７とコード化された値との間の差であることができる。

実施例において、処理回路は、コード化された値が０、１及び２である場合に、選択されたＣＴＵサイズが、それぞれ３２、６４及び１２８であることを決定することができる。処理回路は、選択されたＣＴＵサイズが、２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} になになることを決定することができ、ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、５とコード化された値の和であることができる。

一実施形態において、コード化された情報は、コード化されたビデオシークエンスに対するシークエンスパラメータセットヘッダである。

また、本開示の態様は、ビデオデコーディングのためにコンピュータによって実行されたときに、コンピュータにビデオコーディングのための方法を実行させる命令を格納する非一時的なンピュータ読取可能媒体記憶を提供する。

開示された主題のさらなる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになるであろう。
図１Ａは、イントラ予測モードの例示的サブセットの概略図である。 図１Ｂは、例示的なイントラ予測方向の説明図である。 図２は、一実施例における現在ブロック及びその周囲の空間マージ候補を模式的に示す図である。 図３は、一実施形態による通信システム（３００）の簡略ブロック図を模式的に示す図である。 図４は、一実施形態による通信システム（４００）の簡略ブロック図を模式的に示す図である。 図５は、一実施形態によるデコーダの簡略ブロック図を模式的に示す図である。 図６は、一実施形態によるエンコーダの簡略ブロック図を模式的に示す図である。 図７は、別の実施形態によるエンコーダのブロック図である。 図８は、別の実施形態によるデコーダのブロック図である。 図９Ａ‐９Ｂは、本開示の実施形態による、コーディングトリーユニット（ＣＴＵ）及び四分木プラス二分木（ｑｕａｄｔｒｅｅ ｐｌｕｓ ｂｉｎａｒｙ ｔｒｅｅ：ＱＴＢＴ）構造を示す図である。 図９Ａ‐９Ｂは、本開示の実施形態による、コーディングトリーユニット（ＣＴＵ）及び四分木プラス二分木（ｑｕａｄｔｒｅｅ ｐｌｕｓ ｂｉｎａｒｙ ｔｒｅｅ：ＱＴＢＴ）構造を示す図である。 図１０Ａは、本開示の一実施形態による、シーケンスパラメータ設定（ＳＰＳ）ヘッダにおける構文及び対応する記述子の例を示す図である。 図１０Ｂは、本開示の一実施形態による、符号なし整数指数ゴロムコーディングの例を示す図である。 図１１Ａは、本開示の一実施形態による、ＳＰＳヘッダ内の構文及び対応する記述子の例を示す。 図１１Ｂは、本開示の一実施形態による、２ビットを使用する固定長コーディングの一例を示す。 図１２Ａは、本開示の一実施形態による、ＳＰＳヘッダ内の構文及び対応する記述子の例を示す。 図１２Ｂは、本開示の一実施形態による、短縮単項コーディングの一例を示す。 図１３は、本開示の一実施形態によるプロセス（１３００）の概略を示すフローチャートを示す。 図１４は、一実施形態によるコンピュータシステムを模式的に示す図である。

図３は、本開示の一実施形態による通信システム（３００）の簡略化されたブロック図を示す。通信システム（３００）は、例えばネットワーク（３５０）を介して互いに通信することができる複数の端末デバイスを含む。例えば、通信システム（３００）は、ネットワーク（３５０）を介して相互接続された第１対の端末デバイス（３１０）及び（３２０）を含む。図３の例では、第１対の端末デバイス（３１０）及び（３２０）は、データの一方向送信を行う。例えば、端末デバイス（３１０）は、ビデオデータ（例えば、端末デバイス（３１０）によって捕捉されるビデオ画像のストリーム）をコーディングすることができ、ネットワーク（３５０）を介して他の端末デバイス（３２０）に伝送することができる。エンコードされた画像データは、１つ以上のコーディングされたビデオビットストリームの形態で送信されることができる。端末デバイス（３２０）は、ネットワーク（３５０）からコーディングされたビデオデータを受信し、コーディングされたビデオデータをデコードして、ビデオ画像を復元し、復元されたビデオデータにしたがってビデオ画像を表示することができる。一方向性データ伝送は、メディア提供アプリケーション等において一般的であり得る。

別の例では、通信システム（３００）は、第２対の端末デバイス（３３０）及び（３４０）を含み、例えばビデオ会議中に、発生し得るコーディングされたビデオデータの双方向伝送を行う。データの双方向伝送のために、例えば、端末デバイス（３３０）及び（３４０）の各端末デバイスは、ネットワーク（３５０）を介して端末デバイス（３３０）及び（３４０）の他方の端末デバイスに伝送するために、ビデオデータ（例えば、端末デバイスによって捕捉されるビデオ画像のストリーム）をコーディングし得る。端末デバイス（３３０）及び（３４０）の各端末デバイスは、端末デバイス（３３０）及び（３４０）の他方の端末デバイスによって送信されたコーディングされたビデオデータを受信し、コーディングされたビデオデータをデコードして、ビデオ画像を復元し、復元されたビデオデータにしたがって、アクセス可能な表示デバイスにビデオ画像を表示し得る。

図３の例では、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）は、サーバ、パーソナルコンピュータ及びスマートフォンとして示され得るが、本発明の原理はこれらに限定されない。本発明の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は専用のビデオ会議機器への適用を見出す。ネットワーク（３５０）は、例えばワイヤライン（有線）及び／又は無線通信ネットワークを含む、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）の間でコーディングされたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク（３５０）は、回線交換及び／又はパケット交換チャネル内のデータを交換することができる。代表的なネットワークには、テレコミュニケーションネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又はインターネットが含まれる。本説明の目的のためには、以下に説明しない限り、ネットワーク（２５０）のアーキテクチャ及びトポロジーは本発明の動作には重要ではない可能性がある。

図４は、開示された主題の適用例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルＴＶや、ＣＤ、ＤＶＤ、メモリースティック等を含むデジタルメディアへの圧縮ビデオの保存等を含む、他のビデオ対応アプリケーションに等しく適用することができる。

ストリーミングシステムは、例えば、非圧縮のビデオ画像（４０２）のストリームを生成するビデオソース（４０１）、例えばデジタルカメラを含むことができるキャプチャサブシステム（４１３）を含み得る。一実施形態では、ビデオ画像のストリーム（４０２）は、デジタルカメラによって撮影されるサンプルを含む。エンコードされたビデオデータ（４０４）（又はコーディングされたビデオビットストリーム）と比較した場合に、高データ量を強調するために太線として描かれたビデオ画像のストリーム（４０２）は、ビデオソース（４０１）に結合されたビデオエンコーダ（４０３）を含む電子デバイス（４２０）によって処理されることができる。ビデオエンコーダ（４０３）は、ハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができ、以下により詳細に説明されるように、開示された主題の態様を可能にし、又は実施する。エンコードされたビデオデータ（４０４）（又はエンコードされたビデオビットストリーム（４０４））は、ビデオ画像（４０２）のストリームと比較した場合に、より低いデータ量を強調するために細線として示され、将来の使用のためにストリーミングサーバ（４０５）に格納され得る。図４のクライアントサブシステム（４０６）及び（４０８）等の１つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ（４０５）にアクセスすることができ、エンコードされたビデオデータ（４０４）のコピー（４０７）及び（４０９）を読み出すことができる。クライアントサブシステム（４０６）は、例えば電子デバイス（４３０）内のビデオデコーダ（４１０）を含むことができる。ビデオデコーダ（４１０）は、エンコードされたビデオデータの入力コピー（４０７）をデコードし、ディスプレイ（４１２）（例えばディスプレイスクリーン）又は他のレンダリングデバイス（図示せず）上にレンダリングすることができるビデオ画像の出力ストリーム（４１１）を生成する。いくつかのストリーミングシステムでは、エンコードされたビデオデータ（４０４）、（４０７）及び（４０９）（例えば、ビデオビットストリーム）は、特定のビデオコーディング／圧縮標準にしたがってコーディングされることができる。これらの標準の例は、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。例えば、開発中のビデオコーディング規格は、汎用ビデオコーディング（ＶＶＣ）として非公式に知られている。開示された主題は、ＶＶＣのコンテキストで使用され得る。

電子デバイス（４２０）及び（４３０）は、他の構成要素（図示せず）を含むことができることに留意されたい。例えば、電子デバイス（４２０）は、ビデオデコーダ（図示せず）を含むことができ、電子デバイス（４３０）は、ビデオエンコーダ（図示せず）も含むことができる。

図５は、本開示の一実施例によるビデオデコーダ（５１０）のブロック図を示す。ビデオデコーダ（５１０）は、電子デバイス（５３０）に含まれることができる。電子デバイス（５３０）は、受信器（５３１）（例えば、受信回路）を含むことができる。ビデオデコーダ（５１０）は、図４の例のビデオデコーダ（４１０）の代わりに使用されることができる。

受信器（５３１）は、ビデオデコーダ（５１０）によってデコードされるべき１つ以上のコーディングされたビデオシーケンスを受信することができ、同一又は別の実施形態では、一度に１つのコーディングされたビデオシーケンスを受信することができ、その際、各コーディングされたビデオシーケンスのデコーディングは、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、チャネル（５０１）から受信することができ、このチャネルは、エンコードされたビデオデータを格納するストレージデバイスへのハードウェア／ソフトウェアリンクであり得る。受信器（５３１）は、エンコードされたビデオデータを、他のデータ、例えばコーディングされたオーディオデータ及び／又は付随的なデータストリームと共に受信することができ、これらのデータは、それぞれのエンティティ（図示せず）を使用して転送され得る。受信器（５３１）は、コーディングされたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ（５１５）が、受信器（５３１）とエントロピーデコーダ／パーサ（５２０）（以後「パーサ（５２０）」）との間に結合され得る。特定の用途では、バッファメモリ（５１５）はビデオデコーダ（５１０）の一部である。他の場合には、ビデオデコーダ（５１０）の外側にあることができる（図示せず）。さらに別の場合には、例えばネットワークジッタに対抗するために、ビデオデコーダ（５１０）の外側にバッファメモリ（図示せず）が存在することができ、さらに、例えば再生タイミング（ｐｌａｙｏｕｔ ｔｉｍｉｎｇ）を処理するために、ビデオデコーダ（５１０）の内側に別のバッファメモリ（５１５）が存在することもできる。受信器（５３１）が、十分な帯域幅及び制御可能性の記憶／転送デバイスから、又は、アイソクロナスネットワーク（ｉｓｏｓｙｎｃｈｒｏｎｏｕｓ ｎｅｔｗｏｒｋ）から、データを受信している場合、バッファメモリ（５１５）は不要であるか、又は小さくてもよい。インターネット等のベストエフォート型パケットネットワークでの使用のために、バッファメモリ（５１５）は、必要とされ、比較的大きく、有利には適応サイズであり得、ビデオデコーダ（５１０）の外側のオペレーティングシステム又は類似の要素（図示せず）に少なくとも部分的に実装され得る。

ビデオデコーダ（５１０）は、コーディングされたビデオシーケンスからシンボル（５２１）を再構成するためのパーサ（５２０）を含み得る。これらのシンボルのカテゴリは、図５に示されているように、ビデオデコーダ（５１０）の動作を管理するために使用される情報、及び、電子デバイス（５３０）の不可欠な部分ではないが、電子デバイス（５３０）に結合され得るレンダリングデバイス（５１２）（例えば、表示スクリーン）等のレンダリングデバイスを制御する潜在的な情報を含む。（複数の）レンダリングデバイスの制御情報は、付加拡張情報（ＳＥＩメッセージ）又はビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（図示せず）の形態であり得る。パーサ（５２０）は、受信されるコーディングされたビデオシーケンスをパースし／エントロピーデコードすることができる。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術又は標準に従うことができ、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わない算術コーディングなどを含む種々の原理に従うことができる。パーサ（５２０）は、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも１つに対するサブグループパラメータのセットを、コーディングされたビデオシーケンスから抽出し得る。サブグループは、画像グループ（ＧＯＰ）、画像、タイル、スライス、マクロブロック、コーディングユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）等を含み得る。パーサ（５２０）はまた、変換係数、量子化パラメータ値、動きベクトル等の情報を、コーディングされたビデオシーケンスから抽出し得る。

パーサ（５２０）は、シンボル（５２１）を生成するように、バッファメモリ（５１５）から受信したビデオシーケンスに、エントロピーデコード／パース動作を実行し得る。

シンボル（５２１）の再構成は、コーディングされたビデオ画像又はその部分のタイプ（例えば、画像間及び画像内、ブロック間及びブロック内）及び他の要因に応じて、複数の異なるユニットを含むことができる。どのユニットが、どのように含まれているかは、パーサ（５２０）によってコーディングされたビデオシーケンスからパースされたサブグループ制御情報によって制御されることができる。パーサ（５２０）と以下の複数ユニットとの間のかかるサブグループ制御情報のフローは、明確さのために図示されていない。

すでに述べた機能ブロックの他に、ビデオデコーダ（５１０）は、概念的に、以下に説明するように、いくつかの機能ユニットに分割されることができる。商業的制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されることができる。しかしながら、開示された主題を説明するの目的で、以下の機能単位に概念的に細分化することが適切である。

第１ユニットは、スケーラ／逆変換ユニット（５５１）である。スケーラ／逆変換ユニット（５５１）は、量子化された変換係数、並びに、パーサ（５２０）から（複数の）シンボル（５２１）として、使用されるべき変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報を受信する。スケーラ／逆変換ユニット（５５１）は、アグリゲータ（５５５）に入力可能なサンプル値を含むブロックを出力することができる。

いくつかの場合には、スケーラ／逆変換ユニット（４５１）の出力サンプルは、イントラコード化されたブロックに関係することができる；すなわち、先行して再構成された画像からの予測情報を使用していないが、現在画像のうち先行して再構成された部分からの予測情報を使用できるブロック。かかる予測情報は、イントラ画像予測ユニット（５５２）によって提供されることができる。場合によっては、イントラ画像予測ユニット（５５２）は、現在の画像バッファ（５５８）からフェッチされた周囲の既に再構成された情報を使用して、再構成中のブロックと同じサイズ及び形状のブロックを生成する。現在の画像バッファ（５５８）は、例えば、部分的に再構成された現在の画像及び／又は完全に再構成された現在の画像をバッファする。アグリゲータ（５５５）は、場合によっては、サンプル毎に、イントラ予測ユニット（５５２）が生成した予測情報を、スケーラ／逆変換ユニット（５５１）によって提供される出力サンプル情報に加算する。

他の場合には、スケーラ／逆変換ユニット（５５１）の出力サンプルは、インターコーディングに関係し、潜在的に動き補償ブロックに関係することができる。かかる場合、動き補償予測ユニット（５５３）は、予測に使用されるサンプルをフェッチするために参照画像メモリ（５５７）にアクセスすることができる。ブロックに関連するシンボル（５２１）にしたがって、フェッチされたサンプルを動き補償した後、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（５５５）によって、スケーラ／逆変換ユニット（５５１）の出力（この場合、残差サンプル又は残差信号と称される）に加算されることができる。動き補償予測ユニット（５５３）が予測サンプルをフェッチする参照画像メモリ（５５７）内のアドレスは、動きベクトルによって制御することができ、例えばＸ、Ｙ、及び参照画像コンポーネントを有することができるシンボル（５２１）の形態で動き補償予測ユニット（５５３）に利用可能である。動き補償はまた、サブサンプルの正確な動きベクトルが使用されている場合には、参照画像メモリ（５５７）からフェッチされるようにサンプル値を補間すること、動きベクトル予測機構、等を含むことができる。

アグリゲータ（５５５）の出力サンプルは、ループフィルタユニット（５５６）内の種々のループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタ技術（ｉｎ－ｌｏｏｐ ｆｉｌｔｅｒ ｔｅｃｈｎｏｌｏｇｉｅｓ）を含むことができ、コーディングされたビデオシーケンス（コーディングされたビデオビットストリームとも称される）に含まれるパラメータによって制御され、パーサー（５２０）からシンボル（５２１）としてループフィルタユニット（５５６）に利用可能にされるが、コーディングされた画像又はコーディングされたビデオシーケンスと（デコード順において）先行する部分のデコードの間で得られるメタ情報に応答することができると共に、先行して再構成されループフィルタリングされたサンプル値に応答することができる、インループフィルタ技術を含むことができる。

ループフィルタユニット（５５６）の出力は、レンダリングデバイス（５１２）に出力されることができ、また将来のイントラ画像予測に使用するために参照画像メモリ（５５７）に記憶されることができるサンプルストリームであることができる。

コーディングされた画像は、一旦完全に再構成されると、将来の予測のための参照画像として使用されることができる。例えば、一旦現在の画像に対応するコーディング画像が完全に再構成され、（例えば、パーサ（５２０）によって）コーディングされた画像が参照画像として識別されると、現在の画像バッファ（４５５８）は参照画像メモリ（５５７）の一部となることができ、新たな現在画像バッファは、後続のコーディング画像の再構成を開始する前に再割当てされ得る。

ビデオデコーダ(５10)は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５．等の標準の所定のビデオ圧縮技術にしたがってデコーディング動作を実行し得る。コーディングされたビデオシーケンスは、コーディングされたビデオシーケンスが、ビデオ圧縮技術若しくは標準の構文、及び、ビデオ圧縮技術若しくは標準に文書化されているプロファイルの両方に準拠するという意味で、使用されているビデオ圧縮技術又は標準によって特定された構文に適合し得る。具体的には、プロファイルは、特定のツールを、そのプロファイルの下で使用できる唯一のツールとして、ビデオ圧縮技術又は標準で使用可能なすべてのツールから選択することができる。また、コンプライアンスのために必要なことは、コーディングされたビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることであり得る。場合によっては、レベルは、最大画像サイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒メガサンプルで測定される）、最大参照画像サイズなどを制限する。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（ＨＲＤ：Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ）の仕様と、コーディングされたビデオシーケンスでシグナリングされるＨＲＤバッファ管理のメタデータによってさらに制限され得る。

一実施形態では、受信器（５３１）は、エンコードされたビデオと共に追加の（冗長な）データを受信することができる。追加データは、コーディングされた（複数の）ビデオシーケンスの部分として含まれ得る。追加のデータは、データを適切にデコードするため、及び／又は元のビデオデータをより正確に再構成するために、ビデオデコーダ（５１０）によって使用され得る。追加のデータは、例えば、時間的、空間的、又は信号雑音比（ＳＮＲ）拡張層、冗長スライス、冗長画像、前方エラー補正コードなどの形態であり得る。

図６は、本開示の一実施例によればビデオエンコーダ（６０３）のブロック図を示す。ビデオエンコーダ（６０３）は、電子デバイス（６２０）に含まれる。電子デバイス（６２０）は、送信器（６４０）（例えば送信回路）を含む。図４の例のビデオエンコーダ（４０３）の代わりに、ビデオエンコーダ（６０３）を用いることができる。

ビデオエンコーダ（６０３）は、ビデオエンコーダ（６０３）によってコーディングされる（複数の）ビデオ映像を捕捉することができるビデオソース（６０１）（図６の例では電子デバイス（６２０）の一部ではない）からビデオサンプルを受信し得る。別の例では、ビデオソース（６０１）は、電子デバイス（６２０）の一部である。

ビデオソース（６０１）は、任意の適切なビット深さ（例えば、８ビット、１０ビット、１２ビット、．．．）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、．．．）、及び任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であることができるデジタルビデオサンプルストリームの形態で、ビデオエンコーダ（６０３）によってコーディングされるべきソースビデオシーケンスを提供し得る。メディア配信システムにおいて、ビデオソース（６０１）は、予め準備されたビデオを記憶する記憶デバイスであり得る。ビデオ会議システムでは、ビデオソース（６０１）は、局所映像情報をビデオシーケンスとして捕捉するカメラであり得る。ビデオデータは、シーケンスで見たときに動きをもたらす複数の個々の画像として提供され得る。画像自体は、ピクセルの空間アレイとして組織化されることができ、各ピクセルは、使用中のサンプリング構造、色空間等に応じて、１つ以上のサンプルを含むことができる。当業者は、ピクセルとサンプルの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。

一実施形態によれば、ビデオエンコーダ（６０３）は、ソースビデオシーケンスの画像を、リアルタイムで、又はアプリケーションによって要求される任意の他の時間制約下で、コーディングされたビデオシーケンス（６４３）にコーディングし、圧縮し得る。適切なコーディングスピードを実現することは、コントローラ（６５０）の一つの機能である。いくつかの実施形態において、コントローラ（６５０）は、以下に記載されるように、他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。カップリングは、明確にするため表されない。コントローラ（６５０）によって設定されるパラメータは、レート制御関連パラメータ（画像スキップ、量子化器、レート歪み最適化技術のラムダ値、．．．）、画像サイズ、画像グループレイアウト、最大動きベクトル探索範囲等を含むことができる。コントローラ（６５０）は、特定のシステム設計のために最適化されたビデオエンコーダ（６０３）に関連する他の適切な機能を有するように構成されることができる。

いくつかの実施形態では、ビデオエンコーダ（６０３）は、コーディングループで動作するように構成される。過剰に単純化された説明として、一例において、コーディングループは、（例えば、コーディングされるべき入力画像及び参照画像に基づいて、シンボルストリーム等のシンボルを生成する責任を担う）ソースコーダ（６３０）と、ビデオエンコーダ（６０３）に埋め込まれた（ローカル）デコーダ（６３３）とを含むことができる。デコーダ（６３３）は、（シンボルとコーディングされたビデオビットストリームとの間の任意の圧縮が、開示された主題において考慮されたビデオ圧縮技術において可逆的であるように）、（リモート）デコーダも作成するのと同様の方法で、シンボルを再構成してサンプルデータを作成する。再構成されたサンプルストリーム（サンプルデータ）は、参照画像メモリ（６３４）に入力される。シンボルストリームのデコーディングは、デコーダロケーション（ローカル又はリモート）に依存しないビットイクザクトな結果（ｂｉｔ－ｅｘａｃｔ ｒｅｓｕｌｔｓ）をもたらすので、参照画像メモリ（６３４）中の内容もまた、ローカルエンコーダとリモートエンコーダとの間でビットイクザクトである。換言すれば、エンコーダの予測部分は、デコーダがデコード中に予測を使用するときに「見る」のとまったく同じサンプル値を参照画像サンプルとして「見る」。参照画像同期性のこの基本原理（及び、例えばチャンネルエラーのために、同期性が維持できない場合の結果として生じるドリフト）は、いくつかの関連技術においても同様に使用される。

「ローカル」デコーダ（５３３）の動作は、ビデオデコーダ（４１０）等の「リモート」デコーダと同じであることができ、これは、図５と関連して詳細に既に上述したとおりである。しかしながら、図５も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ（６４５）及びパーサ（５２０）によるコーディングビデオシーケンスへのシンボルのコーディング／デコーディングが可逆的であることができるので、バッファメモリ（５１５）を含むビデオデコーダ（５１０）のエントロピーデコーディング部分及びパーサ（５２０）は、ローカルデコーダ（６３３）に完全には実装されない場合がある。

この点で行うことができる観察は、デコーダ内に存在するパース／エントロピーデコードを除く任意のデコーダ技術もまた、対応するエンコーダ内に実質的に同一の機能的形態で存在する必要があることである。このために、開示された主題は、デコーダ動作に集中する。それらが包括的に記載されているデコーダ技術の逆であるにつれて、エンコーダ技術の説明は略記されることができる。特定の領域だけで、より多くの詳細説明が、必要とされて、下でなされる。

動作中に、いくつかの例において、ソースコーダ（６３０）は、「参照画像」として指定されたビデオシーケンスからの１つ以上の、先行してコーディングされた画像を参照して入力画像を予測的にコーディングする、動き補償予測コーディングを実行し得る。このようにして、コーディングエンジン（６３２）は、入力画像のピクセルブロックと、入力画像に対する（複数の）予測参照として選択され得る（複数の）参照画像のピクセルブロックとの間の差をコーディングする。

ローカルビデオデコーダ（６３３）は、ソースコーダ（６３０）によって生成されたシンボルに基づいて、参照画像として指定され得る画像のコーディングされたビデオデータをデコードし得る。コーディングエンジン（６３２）の動作は、有利には、非可逆プロセスであり得る。コーディングされたビデオデータがビデオデコーダ（図６には示されていない）でデコードされ得る場合、再構成されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスの複であり得る。ローカルビデオデコーダ（６３３）は、参照画像上でビデオデコーダによって実行され、参照画像キャッシュ（６３４）に記憶されるべき再構成された参照画像を生じさせ得るデコーディング処理を繰り返す。このようにして、ビデオエンコーダ（６０３）は、遠位端ビデオデコーダによって得られるであろう再構成された参照画像として、共通のコンテンツを有する再構成された参照画像のコピーをローカルに記憶することができる。

予測器（６３５）は、コーディングエンジン（６３２）について予測サーチを実行し得る。すなわち、コーディングされるべき新しい画像について、予測器（６３５）は、新しい画像についての適切な予測参照として役立ち得る、参照画像動きベクトル、ブロック形状等の特定のメタデータ、又は、サンプルデータ（参照ピクセルブロックの候補として）、について参照画像メモリ（６３４）を検索し得る。予測器（６３５）は、適切な予測参照を見出すために、サンプルブロック毎に動作し得る。場合によっては、予測器（６３５）によって得られた検索結果によって決定されるように、入力画像は、参照画像メモリ（６３４）に記憶された複数の参照画像から引き出された予測参照を有し得る。

コントローラ（６５０）は、例えば、ビデオデータをエンコードするために使用されるパラメータ及びサブグループパラメータの設定を含む、ソースコーダ（６３０）のコーディング動作を管理し得る。

上述した機能ユニットの全ての出力は、エントロピーコーダ（６４５）におけるエントロピーコーディングを受け得る。エントロピーコーダ（６４５）は、ハフマンコーディング、可変長コーディング、算術コーディング等の技術にしたがって、シンボルを可逆的に圧縮することによって、種々の機能ユニットによって生成されたシンボルをコーディングされたビデオシーケンスに変換する。

送信器（６４０）は、エントロピーコーダ（６４５）によって作成されたコーディングされたビデオシーケンスをバッファすることができ、エンコードされたビデオデータを格納するであろうストレージデバイスへのハードウェア／ソフトウェアアリンクであり得る通信チャネル（６６０）を経由した送信のために用意する。送信器（６４０）は、ビデオ・コーダ（６０３）からのコーディングされたビデオデータを、例えばコーディングされたオーディオデータ及び／又は補助的なデータ・ストリーム（図示せず）等の、送信されるべき他のデータとともにマージし得る。

コントローラ（６５０）は、ビデオエンコーダ（６０３）の動作を管理し得る。コーディングの間、コントローラ（６５０）は、各コーディングされた画像に、特定のコーディングされた画像タイプを割り当てることができ、これは、各画像に適用され得るコーディング技術に影響を及ぼし得る。例えば、画像は、しばしば、次の画像タイプの１つとして割り当てられる：

イントラ画像（Ｉ画像）は、予測ソースとしてシーケンス内の他の画像を使用することなく、コーディングされ、デコードされ得る。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ（「ＩＤＲ」：Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）画像を含む、異なるタイプのイントラ画像を許容する。当業者は、Ｉ画像のこれらの変形例、並びにそれらのそれぞれの用途及び特徴を認識している。

予測画像（Ｐ画像）は、各ブロックのサンプル値を予測するために、最大で１つの運動ベクトルと参照インデックスを用いるインター予測又はイントラ予測を使用して、コーディングされ、デコードされ得るものであり得る。

双方向（ｂｉ－ｄｉｒｅｃｔｉｏｎａｌｌｙ）予測画像（Ｂ画像）は、各ブロックのサンプル値を予測するために、最大で２つの動きベクトルと参照インデックスを用いるインター予測又はイントラ予測を使用して、コーディングされ、デコードされ得るものであり得る。同様に、複数の予測画像は、１つのブロックの再構成のために、２つ以上の参照画像及び関連するメタデータを使用することができる。

ソース画像は、通常、空間的に複数のサンプルブロック（例えば、４×４、８×８、４×８、又は１６×１６の各サンプルのブロック）に分割され、ブロック毎にコーディングされる。ブロックは、ブロックのそれぞれの画像に適用されるコーディング割り当てによって決定された、他の（既にコーディングされた）ブロックを参照して予測的にコーディングされ得る。例えば、Ｉ画像のブロックは、非予測的にコーディングされるか、又は、それらは、同じ画像の既にコーディングされたブロック（空間予測又はインター予測）を参照して予測的にコーディングされ得る。Ｐ画像の画素ブロックは、先行してコーディングされた一つの参照画像を参照して、空間的予測又は時間的予測を介して予測的にコーディングされ得る。Ｂ画像のブロックは、１つ又は２つの、先行してコーディングされた参照画像を参照して、空間的予測を介して、又は時間的予測を介して予測的にコーディングされ得る。

ビデオエンコーダ（６０３）は、所定のビデオコーディング技術又はＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５．等の標準にしたがってコーディング動作を実行し得る。その動作において、ビデオエンコーダ（６０３）は、入力ビデオシーケンスにおける時間的及び空間的冗長性を活用する予測コーディング動作を含む種々の圧縮動作を実行し得る。したがって、コード化されたビデオデータは、使用されているビデオコード化技術又は標準によって指定された構文に準拠し得る。

一実施形態では、送信器（６４０）は、エンコードされたビデオと共に追加データを送信し得る。ソースコーダ（６３０）は、コーディングされたビデオシーケンスの一部としてかかるデータを含めることができる。追加のデータは、時間的／空間的／ＳＮＲ強調レイヤーや、他の形式の冗長データ、例えば冗長画像及びスライス、ＳＥＩメッセージ、ＶＵＩパラメータセットフラグメント等を含み得る。

ビデオは、時間シーケンスにおいて複数のソース画像（ビデオ画像）として捕捉され得る。画像内予測（Ｉｎｔｒａ－ｐｉｃｔｕｒｅ ｐｒｅｄｉｃｔｉｏｎ）（しばしば、イントラ予測と略される）は、所与の画像における空間的相関を使用し、画像間予測又はインター予測（ｉｎｔｅｒ－ｐｉｃｔｕｒｅ ｐｒｅｄｉｃｔｉｏｎ）は、画像間の（時間的又は他の）相関を使用する。一例では、現在画像と称されるコーディング／デコーディング中の特定の画像は、ブロックに分割される。現在画像内のブロックが、ビデオ内の、先行してコーディングされ、まだバッファされている参照画像内の参照ブロックに類似する場合、現在の画像内ブロックは、動きベクトルと称されるベクトルによってコーディングされ得る。動きベクトルは、参照画像内の参照ブロックを指し、複数の参照画像が使用されている場合には、参照画像を識別する第３次元を有することができる。

いくつかの実施形態において、双方向予測技術（ｂｉ－ｐｒｅｄｉｃｔｉｏｎ ｔｅｃｈｎｉｑｕｅ）は、画像間予測において使用され得る。双方向予測技術によれば、ビデオ内の現在画像に対してデコード順では両方とも先行する（ただし、表示順では、それぞれ過去及び未来であり得る）第１参照画像及び第２参照画像等の２つの参照画像が使用される。現在画像内のブロックは、第１参照画像内の第１参照ブロックを指す第１動きベクトルと、第２参照画像内の第２参照ブロックを指す第２の動きベクトルとによってコーディングされることができる。ブロックは、第１参照ブロックと第２参照ブロックとの組み合わせによって予測されることができる。

さらに、コーディング効率を改善するために、インター画像予測にマージモード技術を使用することができる。

本開示のいくつかの実施形態によれば、インター画像予測及びイントラ画像予測等の予測は、ブロックの単位で実行される。例えば、ＨＥＶＣ標準によれば、ビデオ画像シーケンス中の画像は、圧縮のためにコーディングツリーユニット（ＣＴＵ）に仕切られ、画像中のＣＴＵは、６４×６４ピクセル、３２×３２ピクセル、又は１６×１６ピクセル等の、同じサイズを有する。一般に、ＣＴＵは、１つのルマＣＴＢ（ｏｎｅ ｌｕｍａ ＣＴＢ）と２つのクロマＣＴＢ（ｔｗｏ ｃｈｒｏｍａ ＣＴＢｓ）である３つのコーディングツリーブロック（ＣＴＢ）を含む。各ＣＴＵは、１つ又は複数のコーディング単位（ＣＵ）に再帰的に４分木分割することができる。例えば、６４×６４ピクセルのＣＴＵは、６４×６４ピクセルの１ＣＵ、３２×３２ピクセルの４ＣＵ、又は１６×１６ピクセルの１６ＣＵに分割することができる。例では、各ＣＵは、インター予測タイプ又はイントラ予測タイプ等の、ＣＵの予測タイプを決定するために分析される。ＣＵは時間的及び／又は空間的予測可能性に依存して１つ以上の予測単位（ＰＵ）に分割される。一般に、各ＰＵはルマ予測ブロック（ＰＢ）と２つのクロマＰＢを含む。一実施形態では、コーディング（エンコード／デコード）における予測動作は、予測ブロックのユニットにおいて実行される。予測ブロックの一例としてルマ予測ブロックを用いると、予測ブロックは、８×８ピクセル、１６×１６ピクセル、８×１６ピクセル、１６×８ピクセル等、ピクセルに対する値（例えば、ルマ値）の行列を含む。

図７は、本開示の別の実施形態によるビデオエンコーダ（７０３）の図を示す。ビデオエンコーダ（７０３）は、ビデオ画像シーケンス内の現在ビデオ画像内のサンプル値の処理ブロック（例えば、予測ブロック）を受信し、処理ブロックをコーディングされたビデオシーケンスの一部であるコーディングされた画像にエンコードするように構成されている。一実施形態では、ビデオエンコーダ（７０３）は、図４の例のビデオエンコーダ（４０３）の代わりに使用される。

ＨＥＶＣの例では、ビデオエンコーダ（７０３）は、８×８サンプルの予測ブロック等の処理ブロックに対するサンプル値のマトリックスを受信する。ビデオエンコーダ（７０３）は、処理ブロックが、例えばレート歪み最適化を使用して、イントラモード、インターモード、又は双方向予測モードを使用して、最良にコーディングされるかどうかを決定する。処理ブロックがイントラモードでコーディングされる場合、ビデオエンコーダ（７０３）は、処理ブロックをコーディングされた画像にエンコードするためにイントラ予測技術を使用することができ、処理ブロックがインターモード又は双方向予測モードでコーディングされる場合、ビデオエンコーダ（７０３）は、処理ブロックをコーディングされた画像にコーディングするために、それぞれ、インター予測技術又は双方向予測技術を使用し得る。特定のビデオコーディング技術では、マージモードは、予測器外部のコード化された動きベクトル成分の利益なしに、動きベクトルが１つ以上の動きベクトル予測器から導出されるインター画像予測サブモードであり得る。特定の他のビデオコーディング技術では、対象ブロックに適用可能な動きベクトル成分が存在し得る。一実施形態では、ビデオエンコーダ（７０３）は、処理ブロックのモードを決定するためのモード決定モジュール（図示せず）等の他の構成要素を含む。

図７の例では、ビデオエンコーダ（７０３）は、図７に示すように一緒に結合されたエントロピーエンコーダ（７２５）と、インターエンコーダ（７３０）と、イントラエンコーダ（７２２）と、残差計算器（７２３）と、スイッチ（７２６）と、残差エンコーダ（７２４）と、汎用コントローラ（７２１）と、を含む。

インターエンコーダ（７３０）は、現在ブロック（例えば、処理ブロック）のサンプルを受信し、ブロックを参照画像内の１つ以上の参照ブロックと比較し（例えば、先行する画像内及び後の画像内のブロック）、インター予測情報（例えば、インターエンコーディング技術による冗長情報の記述、動きベクトル、マージモード情報）を生成し、任意の適切な技術を使用して、インター予測情報に基づいてインター予測結果（例えば、予測ブロック）を計算するように構成される。若干の実施例において、基準ピクチャは、コード化されたビデオ情報に基づいて復号化される復号化基準ピクチャである。

イントラエンコーダ（７２２）は、現在ブロック（例えば、処理ブロック）のサンプルを受信し、場合によっては、ブロックを、同じ画像内で既にコーディングされたブロックと比較し、変換後に量子化された係数を生成し、場合によっては、イントラ予測情報（例えば、１つ以上のイントラコーディング技術に従ったイントラ予測方向情報）も生成するように構成されている。一例では、イントラエンコーダ（７２２）はまた、同じ画像内のイントラ予測情報及び参照ブロックに基づいて、イントラ予測結果（例えば、予測ブロック）を計算する。

汎用制御デバイス（７２１）は、汎用制御データを決定し、汎用制御データに基づいてビデオエンコーダ（７０３）の他の構成要素を制御するように構成される。一実施形態では、汎用コントローラ（７２１）は、ブロックのモードを決定し、そのモードに基づいてスイッチ（７２６）に制御信号を供給する。例えば、モードがイントラモードの場合、汎用コントローラ（７２１）は、スイッチ（７２６）を制御して、残差計算器（７２３）が使用するイントラモードの結果を選択し、エントロピーエンコーダ（７２５）を制御して、イントラ予測情報を選択し、ビットストリームにイントラ予測情報を含め、モードがインターモードの場合、汎用コントローラ（７２１）は、スイッチ（７２６）を制御して、残差計算器（７２３）が使用するインター予測結果を選択し、エントロピーエンコーダ（７２５）を制御して、インター予測情報を選択し、ビットストリームにインター予測情報を含める。

残差計算器（７２３）は、受信されたブロックと、イントラエンコーダ（７２２）又はインターエンコーダ（７３０）から選択された予測結果との差（残差データ）を計算するように構成される。残差エンコーダ（７２４）は、残差データに基づいて動作し、残差データをエンコードして変換係数を生成するように構成される。一実施例では、残差エンコーダ（７２４）は、残差データを空間ドメインから周波数ドメインにコンバートし、変換係数を生成するように構成される。それから、変換係数は量子化処理に従属して、量子化変換係数を得る。様々な実施形態では、ビデオエンコーダ（７０３）は、残差デコーダ（７２８）も含む。残差デコーダ（７２８）は、逆変換を実行し、デコードされた残差データを生成するように構成される。デコードされた残差データは、イントラエンコーダ（７２２）及びインターエンコーダ（７３０）によって適切に使用されることができる。例えば、インターエンコーダ（７３０）は、デコードされた残差データ及びインター予測情報に基づいてデコードされたブロックを生成することができ、イントラエンコーダ（７２２）は、デコードされた残差データ及びイントラ予測情報に基づいてデコードされたブロックを生成することができる。デコードされたブロックは、いくつかの実施例では、デコードされた画像を生成するために適切に処理され、デコードされた画像は、メモリ回路（図示せず）内でバッファされ、参照画像として使用され得る。

エントロピーエンコーダ（７２５）は、エンコードされたブロックを含むようにビットストリームをフォーマットするように構成されている。エントロピーエンコーダ（７２５）は、ＨＥＶＣ標準等の適切な標準にしたがった種々の情報を含むように構成される。一実施例では、エントロピーエンコーダ（７２５）は、汎用制御データ、選択された予測情報（例えば、イントラ予測情報又はインター予測情報）、残差情報、及びビットストリーム内の他の適切な情報を含むように構成される。開示された主題にしたがってインターモード又は双方向予測モードのいずれかのマージサブモードにおけるブロックをコーディングする場合、残差情報は存在しないことに留意されたい。

図８は、本開示の別の実施形態によるビデオデコーダ（８１０）の図を示す。ビデオデコーダ（８１０）は、コーディングされたビデオシーケンスの一部であるコーディングされた画像を受信し、コーディングされた画像をデコードして再構成画像を生成するように構成されている。一実施形態では、ビデオデコーダ（８１０）は、図３の実施形態のビデオデコーダ（４１０）の代わりに使用される。

図８の実施例では、ビデオデコーダ（８１０）は、図８に示すように一緒に結合されたイントラデコーダ（８７２）と、エントロピーデコーダ（８７１）と、インターデコーダ（８８０）と、残差デコーダ（８７３）と、再構成モジュール（８７４）と、及びを含む。

エントロピーデコーダ（８７１）は、コーディングされた画像から、そのコーディング画像を作成する（ｏｆ ｗｈｉｃｈ ｔｈｅ ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｉｓ ｍａｄｅ ｕｐ）構文要素を表す特定のシンボルを再構成するように構成することができる。かかるシンボルは、例えば、ブロックがコーディングされるモード（例えば、イントラモード、インターモード、双方向予測モード、マージサブモード又は別のサブモードにおけるインターモード、双方向予測モード等）、予測情報（例えば、イントラ予測情報又はインター予測情報）を含むことができ、それらは、イントラデコーダ（８２２）又はインターデコーダ（８８０）によって、それぞれ使用される特定のサンプル又はメタデータ、例えば量子化された変換係数の形態の残差情報等、を識別することができる。施例において、予測モードがインターであるか双予測されたモードであるときに、インター予測情報はインター・デコーダ（８８０）に提供される；そして、予測タイプが先行復号化タイプであるときに、先行復号化情報はイントラ・デコーダ（８７２）に提供される。残差情報は、逆量子化を受けることができ、残差デコーダ（８７３）に提供される。

インターデコーダ（８８０）は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成される。

イントラデコーダ（８７２）は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成される。

残差デコーダ（８７３）は、逆量子化変換係数（ｄｅ－ｑｕａｎｔｉｚｅｄ ｔｒａｎｓｆｏｒｍ ｃｏｅｆｆｉｃｉｅｎｔｓ）を抽出するために逆量子化を実行し、逆量子化変換係数を処理して残差を周波数領域から空間領域にコンバートするように構成される。残差デコーダ（８７３）はまた、特定の制御情報（量子化器パラメータ（ＱＰ）を含む）を必要とすることがあり、その情報は、エントロピーデコーダ（８７１）によって提供され得る（データパスは、低ボリューム制御情報のみであるため、図示されていない）。

再構成モジュール（８７４）は、空間領域において、残差デコーダ（８７３）による出力としての残差と、（場合によってはインター又はイントラ予測モジュールによる出力としての）予測結果とを組み合わせて、再構成ブロックを形成するように構成され、これは、再構成画像の一部であり得、したがって、再構成ビデオの一部であり得る。デブロッキング等の他の適切な動作を行って、視覚品質を改善することができることに留意されたい。

なお、ビデオエンコーダ（４０３）、（６０３）及び（７０３）と、ビデオデコーダ（４１０）、（５１０）、及び（８１０）とは、任意の適切な技術を用いて実現することができる。一実施形態では、ビデオエンコーダ（４０３）、（６０３）及び（７０３）と、ビデオデコーダ（４１０）、（５１０）及び（８１０）とは、１つ以上の集積回路を使用して実装され得る。別の実施形態では、ビデオエンコーダ（４０３）、（６０３）及び（６０３）と、ビデオデコーダ（４１０）、（５１０）、及び（８１０）とは、ソフトウェア命令を実行する１つ以上のプロセッサを使用して実現することができる。

ブロック分割構造（ｂｌｏｃｋ ｐａｒｔｉｔｉｏｎｉｎｇ ｓｔｒｕｃｔｕｒｅ）は、コーディングツリーと称することができる。いくつかの実施態様において、ブロック分割構造は、四分木（ＱＴ）＋二分木（ＢＴ）を使用する。例えば、ＱＴ構造を使用することにより、ＣＴＵは、様々な局所特性に適応するためにＣＵに分化する（ｓｐｌｉｔ）。インター画像（時間的）予測又はイントラ画像（空間的）予測を使用して画像領域をコード化するかどうかの決定を、ＣＵレベルで行うことができる。各ＣＵはさらに、ＰＵ分割タイプに応じて、１つ、２つ、又は４つのＰＵに分化することができる。１つのＰＵの内部では、同じ予測プロセスが適用され、関連情報がＰＵベースでデコーダに送信される。

ＰＵ分割型に基づく予測プロセスを適用して残差ブロックを得た後、ＣＵを別のＱＴ構造に従ってＴＵに分化することができる。図示のように、ＣＵ、ＰＵ、及びＴＵを含む複数のパーティションの概念が存在する。

画像境界において、いくつかの実施形態では、サイズが画像境界に適合するまで、ブロックがＱＴ分化を維持するように、黙示的四分木分化（ｉｍｐｌｉｃｉｔ ｑｕａｄｔｒｅｅ ｓｐｌｉｔ）を採用することができる。

いくつかの実施態様において、四分木＋二分木（ＱＴＢＴ）構造を使用する。ＱＴＢＴ構造体は、複数のパーティションタイプの概念（例えば、ＣＵ、ＰＵ、及びＴＵの概念）を除去し、ＣＵパーティションの形状に対してより柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは正方形又は長方形のいずれかの形状を有することができる。

図９Ａは、図９Ｂに示すＱＴＢＴ構造（９２０）を使用して分割されたＣＴＵ（９１０）を示す。ＣＴＵ（９１０）は、まずＱＴ構造によって分割される。ＱＴリーフノードは、ＢＴ構造又はＱＴ構造によってさらに分割される。ＢＴ分化には、対称水平分化と対称垂直分化の２つの分割型がある。ＢＴリーフノードは、ＣＵと称され、さらなるパーティション分割なしで予測と変換処理に使用できる。したがって、ＣＵ、ＰＵ、ＴＵは、ＱＴＢＴコーディングブロック構造内で同じブロックサイズを有する。

いくつかの実施形態では、ＣＵは、異なる色要素のコーディングブロック（ＣＢ）を含むことができる。例えば、１つのＣＵは、４：２：０のクロマフォーマットのＰおよびＢスライスの場合、１つのルマＣＢ及び２つのクロマＣＢを含む。ＣＵは、単色要素のＣＢを含むことができる。例えば、１つのＣＵは、Ｉスライスの場合１つのルマＣＢだけ又はちょうど２つのクロマＣＢだけを含む。

以下のパラメータは、いくつかの実施態様においてＱＴＢＴ分割スキームに対して定義される
－ ＣＴＵ ｓｉｚｅ：ＨＥＶＣのような四分木のルートノードサイズ
－ ＭｉｎＱＴＳｉｚｅ：最小許容ＱＴリーフノードサイズ
－ ＭａｘＢＴＳｉｚｅ：ＢＴルートノードの最大許容サイズ
－ ＭａｘＢＴＤｅｐｔｈ：最大許容ＢＴ深さ
－ ＭｉｎＢＴＳｉｚｅ：最小許容ＢＴリーフノードサイズ

ＱＴＢＴ分割構造の一例では、ＣＴＵサイズは、対応する２つの６４×６４ブロックのクロマサンプルを含む１２８×１２８ルマサンプルとして設定されます。ＭｉｎＱＴＳｉｚｅを１６×１６に設定し、ＭａｘＢＴＳｉｚｅを６４×６４に設定し、ＭｉｎＢＴＳｉｚｅ（幅と高さの両方）を４×４に設定し、ＭａｘＢＴＤｅｐｔｈを４に設定する。ＱＴ分割は、ＱＴリーフノードを生成するために最初にＣＴＵに適用される。ＱＴリーフノードのサイズは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までである。リーフＱＴノードが１２８×１２８の場合、サイズがＭａｘＢＴＳｉｚｅ（すなわち６４×６４）を超えるため、バイナリツリーによってそれ以上分割されることはない。さもなければ、リーフＱＴノードは、バイナリツリーによってさらに分割され得る。したがって、ＱＴリーフノードはバイナリツリーのルートノードでもあり、ＢＴ深さは０である。

ＢＴ深さがＭａｘＢＴＤｅｐｔｈ（すなわち４）に達した場合、それ以上の分化は考慮されない。ＢＴノードの幅がＭｉｎＢＴＳｉｚｅに等しい場合（すなわち４）、それ以上の水平分化は考慮されない。同様に、ＢＴノードの高さがＭｉｎＢＴＳｉｚｅに等しい場合、それ以上の垂直分化は考慮されない。バイナリツリーのリーフノードは、それ以上分割することなく、予測及び変換処理によってさらに処理される。一実施形態では、最大ＣＴＵサイズは、２５６×２５６ルマサンプルである。

図９Ａ及び９Ｂにおいて、実線はＱＴ分化を示し、点線はＢＴ分化を示す。バイナリツリーの各分化（すなわち、非リーフ）ノードでは、どの分割タイプ（すなわち、水平又は垂直）が使用されるかを示すために、１つのフラグに信号を送ることができる。例えば、０は水平分化を示し、１は垂直分化を示します。ＱＴ分化では、四分木分化は常にブロックを水平方向と垂直方向の両方に分化し、等しいサイズの４つのサブブロックを生成するので、分化タイプを示す必要はない。

いくつかの実施態様において、ＱＴＢＴスキームは、ルマ及びクロマが別個のＱＴＢＴ構造を有するための柔軟性をサポートする。例えば、ＰスライスとＢスライスでは、１つのＣＴＵのルマブロックとクロマブロックが同じＱＴＢＴ構造を共有している。しかし、Ｉスライスの場合、ルマＣＴＢはＱＴＢＴ構造によってＣＵに分割され、クロマブロックは別のＱＴＢＴ構造によってクロマＣＵに分割される。したがって、Ｉスライス中のＣＵは、ルマ構成要素のコーディングブロック又は２つのクロマ構成要素のコーディングブロックを含むことができ、Ｐスライス又はＢスライス中のＣＵは、３つのカラー構成要素すべてのコーディングブロックを含むことができ、又はそれらからなることができる。

いくつかの実施形態では、小さなブロックのためのインター予測は、動き補償のメモリアクセスを低減するために制限される。例えば、４×８ブロック及び８×４ブロックでは双方向予測はサポートされず、４×４ブロックではインター予測はサポートされない。ＱＴＢＴが実装されている場合のように、いくつかの例では、上記の制約を取り除くことができる。

ＣＴＵサイズは、ＣＴＵの幅（又は高さ）Ｍによって表すことができる。一実施形態では、ＣＴＵが正方形の形状を有する場合、ＣＴＵサイズはまた、ＣＴＵ内のＭｘＭルマサンプルによって表すことができる。したがって、ＣＴＵサイズは、Ｍ又はＭｘＭと称することができる。一実施形態では、同じＣＴＵサイズを使用して、ビデオシーケンス内の画像をコード化（例えば、エンコード／デコード）することができ、ＣＴＵサイズを示すコーディング情報をシーケンスパラメータ設定（ＳＰＳ）（例えば、ＳＰＳヘッダ内）でシグナリングし、ビデオシーケンス内の画像間で共有することができる。

いくつかの実施形態において、１６、３２、６４、及び１２８等の複数のＣＴＵサイズ（例えば、４つのＣＴＵサイズ）を使用することができる。したがって、４つのＣＴＵサイズは、それぞれ１６×１６、３２×３２、６４×６４、１２８×１２８ルマサンプルであることができる。変数「ＣｔｂＳｉｚｅＹ」は、４つのＣＴＵサイズ（例えば、１６、３２、６４、１２８）を表すために使用することができる。数４‐７は、４つのＣＴＵサイズ１６、３２、６４、１２８のそれぞれの基数２の対数であり、変数「ＣｔｂＬｏｇ２ＳｉｚｅＹ」で表すことができる。４つの数２、３、４、５をそれぞれ、１６（又は１６×１６ルマサンプル）、３２（又は３２×３２ルマサンプル）、６４（又は６４×６４ルマサンプル）、１２８（又は１２８×１２８ルマサンプル）のコード化に使用することができ、変数「ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２」で表すことができる。例えば、４つの数２－５（又はｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２）は、４つのＣＴＵサイズ１６、３２、６４、１２８のそれぞれの基本２対数（又はＣｔｂＬｏｇ２ＳｉｚｅＹ）と値２との間の差である。ＣＴＵサイズに対するＳＰＳヘッダ構文の例は、図１０Ａに示すように「ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２」に設定することができる。

４つの数２－５（又はｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２）は、エントロピーコーディングツール、例えば符号なし整数０次指数ゴロムコーディング（又はｕｅ（ｖ））等の指数ゴロムコーディングを使用してコード化することができる。したがって、変数ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２に対する対応する記述子は、図１０Ａにおいてはｕｅ（ｖ）である。

図１０Ｂは、本開示の一実施形態による、ｕｅ（ｖ）コーディングの例を示す。可変ビットストリング（１０１０）は、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２（コード化値又はコード番号（ｃｏｄｅＮｕｍｓ）とも呼ばれる）（１０２０）をコード化するために使用することができる。例えば、ビットストリング０１１、００１００、００１０１、及び００１１０は、それぞれ、ｃｏｄｅＮｕｍｓ２－５をコード化するために使用される。

上記の記述に基づいて、ＣＴＵサイズの意味を以下に記述することができる。ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２＋２は、各ＣＴＵのルマＣＴＢサイズを特定する（式（１））。ｌｏｇ２＿ｍｉｎ＿ｌｕｍａ＿ｂｌｏｃｋ＿ｓｉｚｅ＿ｍｉｎｕｓ２＋２は、最小ルマコーディングブロックサイズを特定する。変数ＣｔｂＬｏｇ２ＳｉｚｅＹ及びＣｔｂＳｉｚｅＹは、式（１）‐（２）を使用して導出することができる。
ＣｔｂＬｏｇ２ＳｉｚｅＹ＝ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２＋２ 式（１）
ＣｔｂＳｉｚｅＹ＝１＜＜ＣｔｂＬｏｇ２ＳｉｚｅＹ 式（２）

例えば、ビット列０１１は、図１０Ｂに示すように、ｕｅ（ｖ）符号化に基づくｃｏｄｅＮｕｍ ２を表す。したがって、変数ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２の値は２です。変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、式（１）に基づいて４であると決定される。式（２）に基づいて、変数ＣｔｂＳｉｚｅＹの値は２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定されるので、変数ＣｔｂＳｉｚｅＹの値は２ ^４ ＝１６である。従って、ＣＴＵサイズは１６又は１６×１６ルマサンプルである。上記の説明は、３２、６４、又は１２８のような種々のＣＴＵサイズを示す他のビットストリングに適用することができる。

いくつかの例では、より大きなＣＴＵサイズ（例えば、１２８）を使用する代わりに、ＣＴＵサイズ１６を使用すると、より大きなオーバーヘッドが発生する可能性がある。したがって、ＣＴＵサイズ１６を使用すると、デコーディング時間が長くなる可能性がある。例えば、１６×１６ルマのＣＴＵサイズは、８×８クロマＣＴＢサイズに相当する。一部のコーディングモジュールでは、ループフィルタが一般に入力として１６×１６ブロックを使用するので、８×８クロマＣＴＢサイズの処理は困難である。さらに、ＣＴＵサイズ１６×１６は、著しいエンコーディング損失を引き起こす可能性がある。したがってって、ＣＴＵサイズ１６は除去することができる。

いくつかの実施態様において、３２、６４及び１２８（又は３２×３２、６４×６４、１２８×１２８ルマサンプル）等の複数のＣＴＵサイズ（例えば、３つのＣＴＵサイズ）を使用する。同様に、変数「ＣｔｂＳｉｚｅＹ」は３つのＣＴＵサイズを表すのに使用できます。数５－７は、３つのＣＴＵサイズ３２、６４、１２８のそれぞれの基数２の対数であり、変数「ＣｔｂＬｏｇ２ＳｉｚｅＹ」で表すことができる。ＳＰＥヘッダ内の構文及び対応する記述は、以下のように修正することができ、図１１Ａに示す。

３つの数０‐２を用いて、３つのＣＴＵサイズをコード化することができ、例えば、それぞれ３２（又は３２×３２ルマサンプル）、６４（又は６４×６４ルマサンプル）、１２８（又は１２８×１２８ルマサンプル）であり、変数「ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５」で表すことができる。例えば、３つの数０－２（又はｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５）は、３つのＣＴＵのサイズ３２、６４、１２８のそれぞれの基数２の対数（すなわち５－７）（又はＣｔｂＬｏｇ２ＳｉｚｅＹ）と数５の差である。上述したように、ＣＴＵサイズに対するＳＰＳヘッダ構文は、図１１Ａに示すように「ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５」に設定することができる。

３つの数０－２（又はｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５）は、ｎビット（又はｕ（ｎ））を使用する符号なし整数等の固定長コーディングを有するエントロピーコーディングツールを使用して符号化することができる。一例では、２ビット（例えば、ｎ＝２）を使用することができる。したがって、対応する記述子は、図１１Ａのｕ（２）である。図１０Ａ及び１１Ａを比較すると、差分は、ラベル１１１０および１１２０によって示されている。

図１１Ｂは、本開示の一実施形態によるｕ（２）コーディングの例を示す。固定長ビット列（１１３０）は、変数ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５（コード化値又はｃｏｄｅＮｕｍｓとも称される）（１１４０）をコード化するために使用することができる。例えば、ビットストリング００、０１、及び１０は、それぞれ、ｃｏｄｅＮｕｍｓ０‐２をコード化するために使用することができる。

ＣＴＵサイズのセマンティクスは次のように記述され、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２及びｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５に関連するいくつかの差が斜体で強調されている。

ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５ ｐｌｕｓ ５は、各ＣＴＵのルマＣＴＢサイズを特定する。一実施例では、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５の値が２以下であることがビットストリーム適合の要件である。

ｌｏｇ２＿ｍｉｎ＿ｌｕｍａ＿ｃｏｄｉｎｇ＿ｂｌｏｃｋ＿ｓｉｚｅ＿ｍｉｎｕｓ２ ｐｌｕｓ ２は、最小ルマコーディングブロックサイズを特定することができる。

変数ＣｔｂＬｏｇ２ＳｉｚｅＹ及びＣｔｂＳｉｚｅＹは、式（２）ー（３）を使用して導出することができ、ここで式（３）は、式（１）と異なる。
ＣｔｂＬｏｇ２ＳｉｚｅＹ＝ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５＋５ 式（３）

例えば、ビットストリング００は、図１１Ｂに示すように、ｕ（２）コーディングに基づくｃｏｄｅＮｕｍ０を表す。したがって、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５は０であある。変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、式（３）に基づいて５であると決定される。式（２）に基づいて、変数ＣｔｂＳｉｚｅＹの値は２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定されるので、変数ＣｔｂＳｉｚｅＹの値は２ ^５ ＝３２である。したがって、ＣＴＵサイズは３２ルマサンプル又は３２×３２ルマサンプルである。上記の説明は、他のＣＴＵサイズを示す他のビットストリング（例えば、６４又は１２８）に適用することができる。

いくつかの実施形態において、３つのＣＴＵサイズを表す３つの数（例えば、ｃｏｄｅＮｕｍｓ０‐２）のみがエンコードされる。固定長コーディングｕ（２）を用いて構文ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５を記述することは、例えばエンコードされた数が０又は１の場合に、１ビットを無駄にする可能性がある。

上記のいくつかの実施形態では、数０（例えば、ｃｏｄｅＮｕｍ ０）はＣＴＵサイズ３２（又は３２×３２ルマサンプル）を表すために使用することができ、数２（例えば、ｃｏｄｅＮｕｍ ２）はＣＴＵサイズ１２８（又は１２８×１２８ルマサンプル）を表すために使用することができる。いくつかの実施例において、ＣＴＵサイズ１２８は、ビデオシーケンスにおいて最も頻繁に使用されるＣＴＵサイズであり、従って、ＣＴＵサイズ１２８を数２でエンコードすることは、コーディング効率を低下させ、コーディングの複雑さを増加させることができる。

いくつかの実施形態では、ビデオシーケンス内の画像について、画像をコーディングするために使用されるＣＴＵサイズは、ビデオシーケンスについてのコード化された情報において示され得る。ＣＴＵサイズを示す情報はＳＰＳヘッダに入れることができる。ＣＴＵサイズは、３つのＣＴＵサイズ３２、６４、及び１２８のような複数のＣＴＵサイズのうちの１つとすることができる。本開示の態様によれば、ＣＴＵサイズを示すコード化（例えば、符号化／復号）数（例えば、符号化された値又はｃｏｄｅＮｕｍｓ）を示すために、短縮単項コードを使用することができる。上述の固定長コード化と比較して（例えば、図１１Ａ‐１１Ｂを参照して）、短縮単項コードは、例えば、ビットの不必要な無駄を排除することによって、コーディング効率を改善することができる。このように、固定長コーディングｕ（２）の代わりに短縮単項コーディングを用いると、ＳＰＳヘッダのサイズが小さくなり、コーディング効率が向上する。さらに、いくつかの例では、不適合なエンコーダによって生成された不正なビットストリーム（例えば、いくつかの標準やコーダでは許されないＣＴＵサイズ１６ｘ１６を可能にする）を避けることができる。

一実施形態では、３つのＣＴＵサイズ３２、６４、及び１２８（又は３２×３２、６４×６４、１２８×１２８ルマサンプル）を使用することができる。上述のように、変数「ＣｔｂＳｉｚｅＹ」は、３つのＣＴＵサイズを表すのに使用できる。数５‐７は、３つのＣＴＵサイズ３２、６４、１２８のそれぞれの基数２の対数であり、変数「ＣｔｂＬｏｇ２ＳｉｚｅＹ」で表すことができる。ＳＰＳヘッダ内の構文及び対応する記述子は、以下のように変更することができ、図１２Ａに示される。

３つの数０‐２は、３つのＣＴＵサイズをコード化又は表現するために使用することができる。本開示の態様によれば、０は、１２８（又は１２８×１２８ルマサンプル）を表す（又はコード化する）ために使用され、１は、６４（又は６４×６４ルマサンプル）を表す（又はコード化する）ために使用され、２は、３２（又は３２×３２ルマサンプル）を表す（又はコード化する）ために使用される。したがって、３つの数は、変数「７＿マイナス＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ」によって表される。例えば、３つの数０－２（又は７＿マイナス＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ）は、３つのＣＴＵサイズ１２８、６４、及び３２ のそれぞれについて、７と、基数２の対数７、６、及び５（又はＣｔｂＬｏｇ２ＳｉｚｅＹ）との間の差分である。上述したように、ＣＴＵサイズに対するＳＰＳヘッダ構文は、図１２Ａに示すように「７＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ」に設定することができる。

３つの数０－２（又はｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ）は、図１２Ａにおいて記述子ｔｕ（ｖ）によって示されるように、短縮単項コーディング（又はｔｕ（ｖ））を使用してコード化することができる。一実施形態では、短縮単項コーディングは単項符号化であり、コード化されるべき数が最大値ｃＭａｘより小さい場合に、「１」の後に「０」が続くビンストリング（又はビットストリング）を生成する。コード化されるべき数が最大値ｃＭａｘに等しい場合、最後の０は切り捨てられる。実施形態において、ｃＭａｘの最大値は、３つの数０‐２（又は７＿マイナス＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ）をコーディングする場合、２である。図１２Ｂは、本開示の一実施形態による、短縮単項コーディングの一例を示す。可変長ビットストリング（１２３０）は、変数ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ（コード化値又はｃｏｄｅＮｕｍｓ （１２４０）とも称される）をコード化するために使用される。ビットストリング０は、ｃｏｄｅＮｕｍ ０をコード化するために使用することができる。ビットストリング１０は、ｃｏｄｅＮｕｍ １をコード化するために使用することができる。ビットストリング１１は、ｃｏｄｅＮｕｍ ２をコード化するために使用することができる。図１１Ａ及び１２Ａを比較すると、差は、ラベル（１２１０）及び（１２２０）によって示される。図１０Ａ及び１２Ａを比較すると、差は、ラベル（１２１０）及び（１２２０）によって示される。

概して、３つの数０－２（又はｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ）は、可変長符号化（例えば、短縮単項コーディング、指数ゴロムコーディング）、固定長コーディング（例えば、ｕ（ｎ）））、又は数０がＣＴＵサイズ１２８を表すような、任意の適切なコーディング方法を使用してコード化することができる。コード番号はＣＴＵサイズの使用頻度に基づいて割り当てることができる。例えば、１２８のＣＴＵサイズは、最小又はより小さいコード番号に割り当てることができる。

図１２Ａ－１２Ｂで上述したように、変数「ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ」を使用してＣＴＵサイズを記述することができ、ＣＴＵサイズ１２８はコード化された値又はｃｏｄｅＮｕｍ ０でコード化することができる。さらに、１ビットを有するビット列０を用いて、ｃｏｄｅＮｕｍ ０をコード化することができる。種々の実施例において、ＣＴＵサイズ１２８が他のＣＴＵサイズ（例えば、３２及び６４）よりも頻繁に使用される場合、ＣＴＵサイズ１２８を１ビットでコーディングすることにより、コーディング効率を改善することができる。例えば、ビットストリング００１１０は、ＣＴＵサイズ１２８が５ビットを有することを示すために使用することができ（図１０Ｂ）、又はビットストリング１０は、ＣＴＵサイズ１２８が２ビットを有することを示すために使用することができる（図１１Ｂ）。

ＣＴＵサイズのセマンティクス は次のように記述され、ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅと（複数の）他の変数（ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５ ａｎｄ ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ２）の間の差異は斜体で強調されている。

ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅは、各ＣＴＵのルマＣＴＢサイズを特定する。一実施例では、ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅの値が２以下であることがビットストリーム適合の要件である。

ｌｏｇ２＿ｍｉｎ＿ｌｕｍａ＿ｃｏｄｉｎｇ＿ｂｌｏｃｋ＿ｓｉｚｅ＿ｍｉｎｕｓ２ ｐｌｕｓ ２は、最小ルマコーディングブロックサイズを特定できる。

変数ＣｔｂＬｏｇ２ＳｉｚｅＹ及びＣｔｂＳｉｚｅＹは、式（２）及び（４）を使用して導出することができる。

ＣｔｂＬｏｇ２ＳｉｚｅＹ＝７－ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ 式（４）

図１２Ｂを参照すると、例えば、ビットストリング０は、最大値ｃＭａｘ２を有するｔｕ（ｖ）コーディングに基づくｃｏｄｅＮｕｍ ０を表すために使用され得る。したがって、変数ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅの値は０になります。変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、式（４）に基づいて７であると決定される。式（２）に基づいて、変数ＣｔｂＳｉｚｅＹの値は２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定されるので、変数ＣｔｂＳｉｚｅＹの値は２ ^７ ＝１２８である。したがって、ＣＴＵサイズは１２８又は１２８×１２８ルマのサンプルである。上記の説明は、他のＣＴＵサイズを示す他のビットストリング（例えば、３２又は６４）に適用することができる。

本開示の態様によれば、コード化されたビデオシーケンス内の画像のコード化された情報をデコーダによって受信することができる。コード化された情報は、例えばエンコーダによって画像をエンコードするために選択又は使用されるＣＴＵサイズを示すことができる。選択されたＣＴＵサイズは、３つのＣＴＵサイズ３２、６４、及び１２８等の複数のＣＴＵサイズのうちの１つとすることができる。コード化情報は、選択されたＣＴＵサイズを得るために、短縮単項コーディングを用いてエンコード／デコードされ得る。一実施例において、コーディング情報は、ＣＴＵサイズをコーディングするために使用されるコーディングツール（例えば、短縮単項コーディング）を示すことができる。他の例では、コーディングツールは、予め決定されているか、予めシグナリングされている。

一実施形態では、コード化された情報は、図１２Ａ－１２Ｂを参照して上述したように、ＳＰＳヘッダ（例えば、ＳＰＳヘッダの構文及び記述子）内にある。コード化情報は、ビットストリング（例えば、図１２Ｂのビットストリング１０）を含んでもよい。一例では、コード化値／ｃｏｄｅＮｕｍ（例えば、ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ）は、短縮単項符号化を使用してビット列から決定され得、符号化値は、図１２Ｂに示される数１である。一実施例では、短縮単項コーディングで使用されるｃＭａｘの最大値は２である。さらに、選択されたＣＴＵサイズ（例えば、６４）は、構文及び関連するセマンティクス（例えば、式（４）及び式（２））に基づいてコード化された値（例えば、数１）から決定され得る。例えば、変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、式（４）を用いて、７とコード化された値との間の差分であると決定され、したがって、変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅが０のとき、７である。その後、式（２）を用いて変数ＣｔｂＳｉｚｅＹの値が２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定され、したがって、変数ＣｔｂＳｉｚｅＹの値は、ＣｔｂＬｏｇ２ＳｉｚｅＹが７の場合、２ ^７ ＝１２８である。

図１２Ａ－１２Ｂを参照して上述したように、最も頻繁に使用されるＣＴＵサイズをより少ないビット数でコーディングすることにより、コーディング効率を改善できる。いくつかの実施例において、最も頻繁に使用されるＣＴＵサイズは１２８であり、従って、ＣＴＵサイズ１２８は、１ビット（例えば、図１２Ｂに示されるようなビットストリング「０」）で符号化され得る。

いくつかの実施形態において、３２、６４、及び１２８等の複数のＣＴＵサイズ（例えば、３つのＣＴＵサイズ）は、例えば、式（２）及び（３）を使用して、変数ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５を使用して表すことができ、図１２Ｂに示すように、最大値ｃＭａｘが２である短縮単項コーディングｔｕ（ｖ）を用いて符号化される。一実施形態では、ＣＴＵサイズ１２８は、コード化された値（又はｃｏｄｅＮｕｍ）２によってエンコードされ、従って、ビットストリング１１は、数２及びＣＴＵサイズ１２８をエンコードするために使用される。一実施形態では、ＣＴＵサイズ６４は、符号化された値（又はｃｏｄｅＮｕｍ）１で符号化され、従って、ビット列１０は、番号１及びＣＴＵサイズ６４を符号化するために使用される。一実施形態では、ＣＴＵサイズ３２は、符号化された値（又はｃｏｄｅＮｕｍ）０で符号化され、したがって、ビット列０は、数０及びＣＴＵサイズ３２を符号化するために使用される。したがって、符号化値（又はｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５）は、最大値ｃＭａｘが２の切り捨てられた単項符号化を使用してビット列から決定することができる。さらに、選択されたＣＴＵサイズは、構文及び関連するセマンティクス（例えば、式（３）及び式（２））に基づいて符号化された値から決定され得る。例えば、変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値は、５及び式（３）を使用してコード化された値の和であると決定され得る。その後、式（２）を用いて、変数ＣｔｂＳｉｚｅＹの値を２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} とすることができる。

図１３は、本開示の一実施形態によるプロセス（１３００）の概略を示すフローチャートを示す。プロセス（１３００）は、コード化されたビデオシーケンス内の画像に使用されるＣＴＵサイズを決定するために使用され得る。様々な実施形態では、プロセス（１３００）は、端末装置（３１０）、（３２０）、（３３０）及び（３４０）の処理回路、ビデオエンコーダ（４０３）の機能を実行する処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、ビデオデコーダ（５１０）の機能を実行する処理回路、ビデオエンコーダ（６０３）の機能を実行する処理回路などの処理回路によって実行される。いくつかの実施形態では、プロセス（１３００）は、ソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路は、プロセス（１３００）を実行する。プロセスは（Ｓ１３０１）から始まり、（Ｓ１３１０）に進む。

（Ｓ１３１０）において、コード化ビデオシーケンス内の画像のコード化情報を、例えば、デコーダによって受信することができる。コード化された情報は、例えば、画像をエンコードするためにエンコーダによって選択される、ＣＴＵサイズを示すＣＴＵサイズ情報を含むことができる。選択されたＣＴＵサイズは、３２×３２、６４×６４、及び１２８×１２８ルマサンプルの３つのＣＴＵサイズ等の、複数のＣＴＵサイズのうちの１つであってもよい。複数のＣＴＵサイズは、任意の適切な数のＣＴＵサイズを含むことができ、任意の（複数の）適切なＣＴＵサイズを含むことができる。ＣＴＵサイズ情報は、短縮単項コード又は他のコーディング体系を用いて符号化することができる。

一実施例では、コード化された情報は、選択されたＣＴＵサイズをコード化するために使用されるコーディングツールを示す。例えば、コーディング情報は、コーディングツール（例えば、ｔｕ（ｖ）、ｕ（２）、又はｕｅ（ｖ））を示すＳＰＳヘッダ内にある。いくつかの例では、構文はＳＰＳヘッダに含まれ、したがって対応するセマンティクスを示す。

（Ｓ１３２０）において、選択されたＣＴＵサイズは、ＣＴＵサイズ情報に基づくコーディングツール（例えば、切り詰められた単項コード化）を用いて決定され得る。例えば、図１２Ａ－１２Ｂを参照して上述したように、コード化された情報は、短縮単項デコーディングを使用してデコードされる。一実施形態では、ＣＴＵサイズ情報はビットストリングを含む。コード化値（例えば、ｃｏｄｅＮｕｍ）は、短縮単項デコーディングを使用して、ビットストリングから決定することができる。例えば、ビットストリングがそれぞれ０、１０、及び１１であり、短縮単項コーディングで使用される最大値Ｃｍａｘが２である場合、コード化値は０、１、及び２であると決定され得る。さらに、選択されたＣＴＵサイズは、例えば、コード化情報に示される構文（又は対応する意味）を使用して、コード化値に基づいて決定され得る。

一実施例では、構文は、コード化された値が変数ｓｅｖｅｎ＿ｍｉｎｕｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅを参照することを示し、したがって、式（２）及び（４）は、ＣＴＵサイズを取得するのに使用することができる。したがって、コード化された値が０の場合、選択されたＣＴＵサイズは１２８である。コード化された値が１の場合、選択されたＣＴＵサイズは６４である。コード化された値が２の場合、選択されたＣＴＵサイズは３２である。さらに、選択されたＣＴＵサイズは、変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値が、７とコード化値との間の差である場合、２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定することができる。

一実施例では、構文は、コード化された値が変数ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５の値を参照していることを示し、したがって、式（２）及び（３）は、選択したＣＴＵサイズを取得するために使用されることができる。したがって、コード化された値が２の場合、選択されたＣＴＵサイズは１２８である。コード化された値が１の場合、選択されたＣＴＵサイズは６４である。コード化された値が０の場合、選択されたＣＴＵサイズは３２である。さらに、選択されたＣＴＵサイズは、変数ＣｔｂＬｏｇ２ＳｉｚｅＹの値がコード化された値と５の和である場合、２ ^{ＣｔｂＬｏｇ２ＳｉｚｅＹ} であると決定することができる。

（Ｓ１３３０）では、選択したＣＴＵサイズに基づいて画像のサンプルを再構成できる。例えば、画像の１つを、選択したＣＴＵサイズのＣＴＵに分割することができる。ＣＴＵの各々は、複数のＣＵにさらに分割することができ、ＣＵ内のサンプルを再構成するためにインター予測及び／又はイントラ予測を使用することができる。その後、プロセス（１３００）は（Ｓ１３９９）に進み、終了する。

上記の技術は、コンピュータ可読命令を用いたコンピュータソフトウェアとして行うことができて、物理的に一つ以上のコンピュータ可読媒体に格納されることができる。例えば、図１４は、開示された主題の特定の実施例を実施するのに適しているコンピュータシステム（１４００）を示す。

コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、又は類似のメカニズムの対象となり得る任意の適切な機械コード若しくはコンピュータ言語を使用してコーディングされることができ、直接実行されることができるか、又は、１つ以上のコンピュータ中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）等による、実施、マイクロコード実行等を介して実行されることができる命令を含むコードを作成する。

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

コンピュータ・システム（１４００）のための図１８に示されるコンポーネントは、例示的な性質のものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能性に関する制限を示唆することを意図するものではない。また、コンポーネントの構成は、コンピュータシステム（１４００）の例示的な実施形態に示されるコンポーネントのいずれか１つ又は組み合わせに関連する依存性又は要件を有すると解釈されるべきではない

コンピュータシステム（１４００）は、特定のヒューマンインタフェース入力デバイスを含み得る。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スイッピング、データグローブの動き）、音声入力（例えば、音声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を介して、一人又は複数の人間ユーザによる入力に応答し得る。また、ヒューマンインタフェースデバイスは、オーディオ（例えば、音声、音楽、周囲の音声）、画像（例えば、走査画像、静止画像カメラから得られる写真画像）、ビデオ（例えば、２次元ビデオ、立体画像を含む３次元ビデオ）等の、人間による意識的入力に必ずしも直接関係しない特定の媒体を捕捉するために用いられ得る。

入力ヒューマンインタフェースデバイスには、次のものが１つ以上含まれ得る（それぞれ１つのみ表されている）：キーボード（１４０１）、マウス（１４０２）、トラックパッド（１４０３）、タッチスクリーン（１４１０）、データグローブ（図示せず）、ジョイスティック（１４０５）、マイクロホン（１４０６）、スキャナ（１４０７）、カメラ（１４０８）。

コンピュータシステム（１４００）はまた、特定のヒューマンインタフェース出力デバイスを含み得る。かかるヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光、及び嗅覚／味覚を通して、１人又は複数の人間ユーザの感覚を刺激し得る。かかるヒューマンインタフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（１４１０）、データグローブ（図示せず）、又はジョイスティック（１４０５）による触覚フィードバック）、入力デバイスとして働かない触覚フィードバックデバイスであることもでき）と、オーディオ出力デバイス（例えば、スピーカー（１４０９）、ヘッドフォン（図示せず））と、視覚出力デバイス（例えば、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン（１４１０）であり、各々が触覚フィードバック能力を有するか又は有さず、各々が触覚フィードバック能力を有するか又は有さず、そのうちのいくつかは、仮想現実眼鏡（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）等の立体出力のような手段を介して２次元視出力又は３次元以上の出力を可能にし得るもの）と、プリンタ（図示せず）と、を含み得る。

コンピュータシステム（１４００）はまた、人間がアクセス可能な記憶デバイスと、それらのアクセス可能な媒体とを含むことができ、媒体は、例えば、ＣＤ／ＤＶＤ等の媒体（１４２１）によるＣＤ／ＤＶＤ ＲＯＭ／ＲＷを含む光学媒体ドライブ（１４２０）、ＵＳＢメモリ（１４２２）、着脱可能ヘッドドライブ又はソリッドステートドライブ（１４２３）、テープ、フロッピーディスク（図示せず）等の従来の磁気媒体、セキュリティドングル等の特殊化されたＲＯＭ／ＡＳＩＣ／ＰＬＤベースデバイス等である。

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

コンピュータシステム（１４００）はまた、１つ以上の通信ネットワークへのインタフェースを含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、広域、大都市、車両及び工業、リアルタイム、遅延耐性等であり得る。ネットワークの例としては、イーサネット、無線ＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ等を含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上放送ＴＶ、ＣＡＮＢｕｓを含む産業用及び車両用を含む。特定のネットワークは、特定の汎用データポート又はペリフェラルバス（１７４９）（たとえば、コンピュータシステムのＵＳＢポート（１７００））に接続された外部ネットワークインターフェイスアダプタを必要とする；他には、一般に、以下に説明するようにシステムバス（たとえば、ＰＣコンピュータシステムへのイーサネットインターフェイス又はスマートフォンコンピュータシステムへのセルラーネットワークインタフェース）に接続することによってコンピュータシステム（１７００）のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム（１４００）は、他のエンティティと通信することができる。かかる通信は、単指向性通信、受信のみ（例えば、放送テレビ）通信、単指向性送信専用（例えば、特定のＣＡＮバスデバイスへのＣＡＮバス）通信、又は、例えばローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの、双方向通信であることができる。特定のプロトコル及びプロトコルスタックは、上述のように、それらのネットワーク及びネットワークインタフェースの各々で使用されることができる。

前述のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインタフェースは、コンピュータシステム（１４００）のコア（１４４０）に接続されることができる。。

コア（１４４０）は、１つ以上の中央処理デバイス（ＣＰＵ）（１４４１）、グラフィックス処理デバイス（ＧＰＵ）（１４４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）（１４４３）の形態の特殊なプログラマブル処理デバイス、特定のタスクのためのハードウェアアクセラレータ（１４４４）等を含むことができる。これらのデバイスは、読出し専用メモリ（ＲＯＭ）（１４４５）、ランダムアクセスメモリ（１４４６）、内部大容量記憶デバイス、例えば内部非ユーザアクセス可能ハードドライブ、ＳＳＤ等（１４４７）と共に、システムバス（１４４８）を介して接続され得る。いくつかのコンピュータシステムでは、システムバス（１４４８）は、追加のＣＰＵ、ＧＰＵ等による拡張を可能にするために、１つ又は複数の物理プラグの形態でアクセス可能である。周辺デバイスは、コアのシステムバス（１４４８）に直接接続するか、又は周辺バス（１４４９）を介して接続することができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢ等を含む。

ＣＰＵ（１４４１）、ＧＰＵ（１４４２）、ＦＰＧＡ（１４４３）、及びアクセラレータ（１４４４）は、組み合わされて、上述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ（１４４５）又はＲＡＭ（１４４６）に格納されることができる。移行データは、ＲＡＭ（１４４６）に格納されることもできるが、永久データは例えば内部大容量記憶デバイス（１４４７）に格納されことができる。１つ以上のＣＰＵ（１４４１）、ＧＰＵ（１４４２）、大容量記憶デバイス（１４４７）、ＲＯＭ（１４４５）、ＲＡＭ（１４４６）等と密接に関連付けることができるキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索を可能にすることができる。

コンピュータ可読媒体は、各種のコンピュータ実施動作（ｃｏｍｐｕｔｅｒ－ｉｍｐｌｅｍｅｎｔｅｄ ｏｐｅｒａｔｉｏｎｓ）を実行するためにその上のコンピュータコードを有することができる。メディアおよびコンピュータコードは特別に設計されたそれらであることができて、本開示のために作成されることができる、または、それらはよく公知で、コンピュータソフトウェア技術の技術を有するそれらが利用できる種類でありえる。

一例として、限定するものではなく、アーキテクチャ（１４００）、具体的にはコア（１４４０）を有するコンピュータシステムは、１つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ等を含む）の結果として機能性を提供することができる。かかるコンピュータ可読媒体は、コア－内部大容量記憶デバイス（１４４７）又はＲＯＭ（１４４５）等の一時的でない性質のコア（１４４０）の特定の記憶デバイスと同様に、上述のようにユーザがアクセス可能な大容量記憶デバイスに関連する媒体であってもよい。本開示の様々な実施形態を実装するソフトウェアは、かかるデバイスに記憶され、コア（１４４０）によって実行され得る。コンピュータ読取可能媒体は、特定のニーズに応じて、１つ以上のメモリデバイス又はチップを含むことができる。ソフトウェアは、コア（１４４０）及びその中の具体的にプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ等を含む）に、ＲＡＭ（１４４６）に記憶されたデータ構造を定義し、ソフトウェアによって定義されたプロセスにしたがって、かかるデータ構造を変更することを含む、本明細書に記載された特定のプロセス又は特定の部分を実行させることができる。付加的に又は代替的に、コンピュータシステムは、回路（例えば、アクセラレータ（１４４４））内に配線された、又は他の方法で具現化されたロジックの結果として、機能性を提供することができ、これは、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、又はソフトウェアと共に動作することができる。ソフトウェアへの言及は、論理を含み、また、必要に応じて、その逆も可能である。コンピュータ読取り可能媒体への参照は、実行のためのソフトウェアを記憶する（集積回路（ＩＣ）等の）回路、実行のためのロジックを具体化する回路、又は適切な場合にはその両方を含むことができる。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

付録Ａ：
頭文字
ＪＥＭ：ジョイント探索モデル
ＶＶＣ：広用途ビデオコーディング
ＢＭＳ：ベンチマークセット
ＭＶ：動きベクトル
ＨＥＶＣ：高効率ビデオコーディング
ＭＰＭ：最も可能性のあるモード
ＷＡＩＰ：ワイドアングルイントラ予測
ＳＥＩ：付加強化情報
ＶＵＩ：ビデオユーザビリティ情報
ＧＯＰ：画像グループ
ＴＵ：変換ユニット
ＰＵ：予測ユニット
ＣＴＵ：コーディングトリーユニット
ＣＴＢ：コーディングトリーブロック
ＰＢ：予測ブロック
ＨＲＤ：仮想参照デコーダ
ＳＤＲ：標準ダイナミクスクレンジ
ＳＮＲ：信号雑音比
ＣＰＵ：中央処理装置
ＧＰＵ：グラフィックスプロセッシングユニット
ＣＲＴ：陰極線管
ＬＣＤ：液晶ディスプレイ
ＯＬＥＤ：有機発光ダイオード
ＣＤ：コンパクト・ディスク
ＤＶＤ：デジタルビデオディスク
ＲＯＭ：リードオンリーメモリ
ＲＡＭ：ランダムアクセスメモリ
ＡＳＩＣ：特定用途向け集積回路
ＰＬＤ：プログラマブルロジックデバイス
ＬＡＮ：ローカルエリアネットワーク
ＧＳＭ：グローバスシステムフォーモバイルコミュニケーション
ＬＴＥ：ロングタームエヴォリューション
ＣＡＮバス：コントローラエリアネットワークバス
ＵＳＢ：ユニバーサルシリアル・バス
ＰＣＩ：ペリフェラルコンポーネントインターコネクト
ＦＰＧＡ：フィールドプログラマブルゲートエリア
ＳＳＤ：ソリッドステートドライブ
ＩＣ：集積回路
ＣＵ：コーディングユニット
ＰＤＰＣ：位置依存予測組合せ
ＩＳＰ：イントラサブ予測
ＳＰＳ：シークエンスパラメータセッティング

本開示はいくつかの例示的な実施形態を説明しているが、本発明の範囲内に入る、変更、置換、及び様々な均等物が存在する。
したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本発明の原理を実施し、したがってその概念及び範囲内にある多数のシステム及び方法を創造することができることが理解されよう。

Claims (5)

1. デコーダが実行するビデオをデコードするための方法であって、
   コード化されたビデオシーケンス内の画像のコード化された情報を受信するステップであって、前記コード化された情報は、前記画像に対して選択されたＣＴＵサイズを示すコーディングトリーユニットサイズ情報（ＣＴＵサイズ情報）を含み、ステップと、
   前記ＣＴＵサイズ情報に対応する少なくとも１ビットに基づいて、前記選択されたＣＴＵサイズを決定するステップと、
   前記選択されたＣＴＵサイズに基づいて前記画像内のサンプルを再構成するステップと、
   を含み、
   前記選択されたＣＴＵサイズは、第１値である、前記ＣＴＵサイズ情報に対応する少なくとも１ビットの第１ビットに基づいて、３つのＣＴＵサイズのうちの第１ＣＴＵサイズとして決定され、
   前記選択されたＣＴＵサイズは、第２値である前記第１ビット及び前記ＣＴＵサイズ情報に対応する少なくとも１ビットの第２ビットに基づいて、３つのＣＴＵサイズのうちの第２ＣＴＵサイズ及び第３ＣＴＵサイズのうちの１つとして決定され、
   前記少なくとも１ビットは、前記第２値である前記第１ビットに基づいて前記第２ビットを含み、
   前記選択されたＣＴＵサイズを決定するステップは、
   短縮単項コードを用いてエンコードされた前記ＣＴＵサイズ情報に基づいて、前記コード化された情報内の前記少なくとも１ビットからコード化された値を決定するステップであって、前記少なくとも１ビット内の最大ビット数は２であり、前記少なくとも１ビットが０である場合に、前記コード化された値は０であり、前記少なくとも１ビットが１０である場合に、前記コード化された値は１であり、前記少なくとも１ビットが１１である場合に、前記コード化された値は２である、ステップ、
   を含み、
   前記選択されたＣＴＵサイズを決定するステップは、
   前記コード化された値が０、１及び２である場合に、前記選択されたＣＴＵサイズが、それぞれ１２８、６４及び３２であることを決定するステップを含み、
   前記選択されたＣＴＵサイズが、それぞれ１２８、６４及び３２であることを決定するステップは、
   前記ＣＴＵサイズ情報に対応する前記コード化された値に基づいて、前記コード化された値と所定の定数値との差に等しい変数値を決定するステップであって、前記所定の定数値は奇素数である、ステップと、
   前記選択されたＣＴＵサイズが、２^{ＣｔｂＬｏｇ２ＳｉｚｅＹ}になることを決定するステップであって、前記変数値はＣｔｂＬｏｇ２ＳｉｚｅＹの値である、ステップを含む、
   方法。
2. デコーダが実行するビデオをデコードするための方法であって、
   コード化されたビデオシーケンス内の画像のコード化された情報を受信するステップであって、前記コード化された情報は、前記画像に対して選択されたＣＴＵサイズを示すコーディングトリーユニットサイズ情報（ＣＴＵサイズ情報）を含み、ステップと、
   前記ＣＴＵサイズ情報に対応する少なくとも１ビットに基づいて、前記選択されたＣＴＵサイズを決定するステップと、
   前記選択されたＣＴＵサイズに基づいて前記画像内のサンプルを再構成するステップと、
   を含み、
   前記選択されたＣＴＵサイズは、第１値である、前記ＣＴＵサイズ情報に対応する少なくとも１ビットの第１ビットに基づいて、３つのＣＴＵサイズのうちの第１ＣＴＵサイズとして決定され、
   前記選択されたＣＴＵサイズは、第２値である前記第１ビット及び前記ＣＴＵサイズ情報に対応する少なくとも１ビットの第２ビットに基づいて、３つのＣＴＵサイズのうちの第２ＣＴＵサイズ及び第３ＣＴＵサイズのうちの１つとして決定され、
   前記少なくとも１ビットは、前記第２値である前記第１ビットに基づいて前記第２ビットを含み、
   前記選択されたＣＴＵサイズを決定するステップは、
   短縮単項コードを用いてエンコードされた前記ＣＴＵサイズ情報に基づいて、前記コード化された情報内の前記少なくとも１ビットからコード化された値を決定するステップであって、前記少なくとも１ビット内の最大ビット数は２であり、前記少なくとも１ビットが０である場合に、前記コード化された値は０であり、前記少なくとも１ビットが１０である場合に、前記コード化された値は１であり、前記少なくとも１ビットが１１である場合に、前記コード化された値は２である、ステップ、
   を含み、
   前記選択されたＣＴＵサイズを決定するステップは、
   前記ＣＴＵサイズ情報に対応する前記コード化された値に基づいて、変数値が（７－前記コード化された値）になることを決定するステップと、
   前記選択されたＣＴＵサイズが、２^{ＣｔｂＬｏｇ２ＳｉｚｅＹ}になることを決定するステップであって、前記変数値がＣｔｂＬｏｇ２ＳｉｚｅＹの値である、ステップを含む、
   方法。
3. 前記コード化された情報は、前記コード化されたビデオシークエンスに対するシークエンスパラメータセットヘッダである、
   請求項１又は２記載の方法。
4. ビデオを処理するための装置であって、
   処理回路を備え、前記処理回路は、
   請求項１乃至３いずれか１項記載の方法を実行する、ように構成されている、
   装置。
5. 少なくとも１つのプロセッサによって実行可能なプログラムであって、前記プログラムは、
   前記プロセッサに請求項１乃至３いずれか１項記載の方法を実行させるように構成されている、プログラム。