JP2019534624A - ビデオコーディングのための変換選択 - Google Patents

Abstract

ビデオコーディングのためのデバイスは、現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、特性に基づいて、現在ブロックを復号するための変換を識別することと、現在ブロックについての残差ブロックを決定するために係数を逆変換することと、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加することと、を行うように構成される。

Description

[0001] 本出願は、２０１６年１０月１日に出願された米国特許仮出願第６２／４０３，１１２号の利益を主張し、それのすべての内容は、参照によってここに組み込まれる。
［技術分野］
[0002] 本開示は、ビデオ符号化およびビデオ復号に関する。

[0003] デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、ｅ−ｂｏｏｋリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラまたは衛星無線電話、いわゆる「スマートフォン」、ビデオテレビ会議デバイス、ビデオストリーミングデバイス等を含む幅広いデバイスに組み込まれることができる。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、最近完成された高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格、およびそのような規格の拡張によって定義された規格に説明されるもののようなビデオ圧縮技法をインプリメントする。ビデオデバイスは、そのようなビデオ圧縮技法をインプリメントすることによって、より効率的にデジタルビデオ情報を送信、受信、符号化、復号および／または記憶し得る。

[0004] ビデオ圧縮技法は、ビデオシーケンスに内在する冗長性を減少させるまたは削除するために、空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を実施（perform）する。ブロックベースビデオコーディングについては、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部）は、複数のビデオブロックに区分され得、それはまた、ツリーブロック（tree block）、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードとも呼ばれ得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ内の隣接ブロックにおける参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ内の隣接ブロックにおける参照サンプルに対する空間的予測、または他の参照ピクチャ（reference picture）における参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれ得、参照ピクチャは参照フレームと呼ばれ得る。

[0005] 空間または時間的予測は、コード化されることになるブロック（block）についての予測ブロック（predictive block）をもたらす。残差データ（residual data）は、コーディングされることになる元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトル（motion vector）、およびコード化ブロックと予測ブロックとの間の差を示す残差データに従って符号化される。イントラコード化ブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換され得、残差変換係数をもたらし、それは次いで量子化され得る。量子化された変換係数は、最初は２次元アレイで配列されているが、変換係数（transform coefficients）の１次元ベクトルを生み出すために走査され得、より一層の圧縮を達成するためにエントロピーコーディングが適用され得る。

[0006] 本開示は、残差データのコーディングのための変換（transform）を決定する（determine）ことに関する技法を説明する。より具体的には、本開示は、ビデオエンコーダ（video encoder）およびビデオデコーダ（video decoder）の両方において、残差ブロック（residual block）をコード化するために使用される変換が、ほとんど明示的なシグナリングなしにシグナリングされることができるか、または一部のケースでは、全く明示的なシグナリングなしにされることができ、それにより帯域幅（bandwidth）を節約するような、ある特定の変換情報（transform information）を導出するための技法を説明する。

[0007] 一例では、ビデオデータ（video data）を復号する（decode）ための方法は、現在のピクチャ（current picture）の現在ブロック（current block）の予測ブロックの特性（characteristic）を決定することと、特性に基づいて、現在ブロックを復号するための変換（transform）を識別する（identify）ことと、現在ブロックについての残差ブロックを決定するために、変換係数を逆変換（inverse transform）することと、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加（add）することと、を含む。

[0008] 別の例では、ビデオデータを復号するためのデバイス（device）は、ビデオデータを記憶するように構成されるメモリと、ビデオデータの現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、特性に基づいて、現在ブロックを復号するための変換を識別することと、現在ブロックについての残差ブロックを決定するために、変換係数のセットを逆変換することと、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加（add）することと、を行うように構成される１つまたは複数のプロセッサ（processor）と、を含む。

[0009] 別の例では、ビデオデータを復号するための装置は、現在のピクチャの現在ブロックの予測ブロックの特性を決定するための手段と、特性に基づいて、現在ブロックを復号するための変換を識別するための手段と、現在ブロックについての残差ブロックを決定するために、変換係数を逆変換するための手段と、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加するための手段と、を含む。

[0010] 別の例では、１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサに、現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、特性に基づいて、現在ブロックを復号するための変換を識別することと、現在ブロックについての残差ブロックを決定するために、変換係数のセットを逆変換することと、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加することと、を行わせる命令（instruction）を記憶するためのコンピュータ読み取り可能な媒体（computer-readable medium）。

[0011] 本開示の１つまたは複数の態様の詳細は、添付の図面および以下の説明に記載される。本開示に説明される技法の他の特徴、目的、および利点は、説明および図面、および特許請求の範囲から明らかとなる。

[0012] 図１は、本開示で説明される技法を利用し得る例示的なビデオ符号化および復号システムを例示するブロック図である。 [0013] 図２Ａは、変換タイプ（transform type）の例を例示する表である。 図２Ｂは、変換タイプの例を例示する表である。 図２Ｃは、変換タイプの例を例示する表である。 図２Ｄは、変換タイプの例を例示する表である。 図２Ｅは、変換タイプの例を例示する表である。 [0014] 図３は、高効率ビデオコーディング（ＨＥＶＣ）における残差四分木（residual quadtree）に基づく変換スキームの例を例示する概念図である。 [0015] 図４は、ＨＥＶＣにおけるコーディンググループに基づく係数走査の例を例示する概念図である。 [0016] 図５は、二次変換の例を示す。 [0017] 図６は、ＫＬＴ処理のフローチャートの例を示す。 [0018] 図７は、ビデオデコーダ３０（またはビデオエンコーダ２０）によって実施され得るテンプレートマッチング処理（template matching process）の例を示す。 [0019] 図８は、本開示で説明される技法をインプリメントし得る例示的なビデオエンコーダを例示するブロック図である。 [0020] 図９は、本開示で説明される技法をインプリメントし得る例示的なビデオデコーダを例示するブロック図である。 [0021] 図１０は、本開示で説明される例示的なビデオ復号技法を例示するフローダイアグラムである。

詳細な説明

[0022] 本開示は、残差データのコーディングのために使用される１つまたは複数の変換（transform）を決定することに関する技法を説明する。より具体的には、本開示は、ビデオエンコーダおよびビデオデコーダの両方において、残差ブロックをコード化するために使用される変換が、ほとんど明示的なシグナリングなしにシグナリングされることができるか、または一部のケースでは、全く明示的なシグナリングなしにされることができ、それにより変換をシグナリングすることに関連するシグナリングオーバヘッド（signaling overhead）を潜在的に減少させるような、ある特定の変換情報を導出するための技法を説明する。本開示の技法は、ＨＥＶＣ（高効率ビデオコーディング）のような既存のビデオコーデックのうちのいずれかのものと併せて使用され得るか、またはＨ．２６６規格およびその拡張のような将来のビデオコーディング規格で使用するための効率的なコーディングツールであり得る。

[0023] 本開示における様々な技法は、ビデオコーダを参照して説明され得、それはビデオエンコーダまたはビデオデコーダのいずれをも示すことができる総称を意図したものである。そうでないと明示的に述べられていない限り、ビデオエンコーダまたはビデオデコーダに関して説明される技法は、ビデオエンコーダまたはビデオデコーダのうちの他方によって実施されることはできないと見なされるべきではない。例えば、多くの事例において、ビデオデコーダは、符号化されたビデオデータを復号するために、ビデオエンコーダと同じ、または時には逆の（reciprocal）コーディング技法を実施する。多くの事例において、ビデオエンコーダはまた、ビデオ復号ループ（video decoding loop）を含み、よってビデオエンコーダは、ビデオデータを符号化することの一部として、ビデオ復号を実施する。したがって、そうでないと述べられていない限り、ビデオデコーダに関して本開示で説明される技法はまた、ビデオエンコーダによっても実施され得、逆もまた同様である。

[0024] 本開示はまた、現在ブロック、現在のピクチャ等のような用語も使用し得る。本開示の文脈においては、現在（current）という用語は、例えば、前にまたは既にコード化されたブロックまたはピクチャ、あるいはまだコード化されていないブロックまたはピクチャとは対照的に、現在コード化されている（currently being coded）ブロックまたはピクチャを識別するように意図されている。

[0025] 図１は、本開示で説明される技法を利用し得る例示的なビデオ符号化および復号システム（video encoding and decoding system）１０を例示するブロック図である。図１に示されるように、システム１０は、宛先デバイス（destination device）１４によって後に復号されることとなる、符号化されたビデオデータを生成するソースデバイス（source device）１２を含む。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット（telephone handset）、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイス、または同様のものを含む多様なデバイスのうちの任意のものを備え得る。一部のケースでは、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信（wireless communication）のために装備され得る。

[0026] 宛先デバイス１４は、リンク１６を介して、復号されることとなる符号化されたビデオデータを受信し得る。リンク１６は、符号化されたビデオデータをソースデバイス１２から宛先デバイス１４に転送することができるいかなるタイプの媒体またはデバイスも備え得る。一例では、リンク１６は、ソースデバイス１２が、リアルタイムで直接的に宛先デバイス１４に符号化されたビデオデータを送信することを可能にする通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格（communication standard）に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理送信経路のようないかなるワイヤレスまたはワイヤード通信媒体も備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークのような、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を容易にするために有益であり得る任意の他の機器を含み得る。

[0027] 別の例では、符号化されたデータは、出力インタフェース２２から記憶デバイス２６へと出力され得る。同様に、符号化されたデータは、入力インタフェースによって記憶デバイス２６からアクセスされ得る。記憶デバイス２６は、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、多様な分配型の、または局所的にアクセスされるデータ記憶媒体のうちのいずれのものも含み得る。さらなる例では、記憶デバイス２６は、ソースデバイス１２によって生成される符号化されるビデオを保持し得るファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、記憶デバイス２６からの記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶する、およびその符号化されたビデオデータを宛先デバイス１４に送信することができるいかなるタイプのサーバでもあり得る。例示的なファイルサーバは、（例えば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ：network attached storage）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む任意の規格データ接続を通して、符号化されたビデオデータにアクセスし得る。これは、ワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデム等）、またはファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適したそれら両方の組合せを含み得る。記憶デバイス２６からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれら両方の組合せであり得る。

[0028] 本開示の技法は、ワイヤレスアプリケーションまたはセッティングに必ずしも限定されない。これら技法は、無線テレビブロードキャスト、ケーブルテレビ送信、衛星テレビ送信、例えばインターネットを介したストリーミングビデオ送信、データ記憶媒体上で記憶するためのデジタルビデオの符号化、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、多様なマルチメディアアプリケーションのうちの任意のものをサポートしてビデオコーディング（video coding）に適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティングおよび／またはビデオ電話のようなアプリケーションをサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

[0029] 図１の例では、ソースデバイス（source device）１２は、ビデオソース１８、ビデオエンコーダ２０、および出力インタフェース２２を含む。一部のケースでは、出力インタフェース２２は、変調器／復調器（モデム）および／または送信機を含み得る。ソースデバイス１２では、ビデオソース１８は、ビデオキャプチャデバイス、例えばビデオカメラ、前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインタフェース、および／またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステム、またはそのようなソースの組合せのようなソースを含み得る。１つの例として、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはビデオ電話を形成し得る。しかしながら、本開示で説明される技法は、一般的にはビデオコーディングに適用可能であり得、および、ワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。

[0030] キャプチャされたか、事前にキャプチャされたか、またはコンピュータによって生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオデータは、ソースデバイス１２の出力インタフェース２２を介して宛先デバイス１４に直接的に送信され得る。符号化されたビデオデータはまた（または代替的に）、復号および／または再生のための宛先デバイス１４または他のデバイスによる後のアクセスのために記憶デバイス２６上へと記憶され得る。

[0031] 宛先デバイス１４は、入力インタフェース２８、ビデオデコーダ３０、およびディスプレイデバイス３２を含む。一部のケースでは、入力インタフェース２８は、受信機（）および／またはモデムを含み得る。宛先デバイス１４の入力インタフェース２８は、リンク１６を介して符号化されたビデオデータを受信する。記憶デバイス２６上に提供された、またはリンク１６を介して通信された符号化されたビデオデータは、ビデオデータを復号する際にビデオデコーダ３０のようなビデオデコーダによって使用されるための、ビデオエンコーダ２０によって生成される多様なシンタックス要素（syntax element）を含み得る。そのようなシンタックス要素は、通信媒体上で送信される、記憶媒体上に記憶される、またはファイルサーバ上に記憶される符号化されたビデオデータと共に含まれ得る。

[0032] ディスプレイデバイス３２は、宛先デバイス１４に統合され得るか、または宛先デバイス１４の外部にあり得る。いくつかの例では、宛先デバイス１４は、統合されたディスプレイデバイスを含み得、また外部のディスプレイデバイスとインタフェースするようにも構成され得る。他の例では、宛先デバイス１４は、ディスプレイデバイスであり得る。一般に、ディスプレイデバイス３２は、復号されたビデオデータをユーザに表示し、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような多様なディスプレイデバイスのうちのいずれのものも備え得る。

[0033] ビデオエンコーダ２０およびビデオデコーダ３０は、最近完成された高効率ビデオコーディング（ＨＥＶＣ）規格のようなビデオ圧縮規格に従って動作し得る。ビデオエンコーダ２０およびビデオデコーダ３０は、ISO/IEC Motion Picture Experts Group (MPEG)およびITU-T Video Coding Experts Group (VCEG)のＪＣＴ−３Ｖ（Joint Collaboration Team on 3D Video Coding Extension Development）ならびにＪＣＴ−ＶＣ（Joint Collaboration Team on Video Coding）によって開発されたスケーラブル拡張（ＳＨＶＣ）、マルチビュー拡張（ＭＶ−ＨＥＶＣ）、または範囲拡張（range extension）のようなＨＥＶＣ拡張に従ってさらに動作し得る。

[0034] ビデオエンコーダ２０およびビデオデコーダ３０はまた、代替的にＩＳＯ／ＩＥＣ ＭＰＥＧ−４、Ｐａｒｔ１０と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格、アドバンストビデオコーディング（ＡＶＣ）、またはそのような規格の拡張、例えば、スケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）拡張のような他の専有または工業規格（proprietary or industry standards）に従って動作し得る。しかしながら、本開示の技法はいかなる特定のコーディング規格にも限定されない。 ビデオ圧縮規格の他の例は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、およびＩＳＯ／ＩＥＣ ＭＰＥＧ−４Ｖｉｓｕａｌを含む。

[0035] ＩＴＵ−Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）は、現在のＨＥＶＣ規格（それの、スクリーンコンテンツコーディングおよびハイダイナミックレンジコーディングのための近い将来の拡張および現在の拡張を含む）の圧縮能力を大幅に上回る圧縮能力を有する、将来のビデオコーディング技術の標準化についての潜在的な必要性を現在検討中である。これらのグループは、この分野のそれらの専門家によって提案された圧縮技術設計を評価するために、ＪＶＥＴ（Joint Video Exploration Team）として知られる連携した取り組みにおいて、この調査活動について協力して取り組んでいる。ＪＶＥＴは、２０１５年１０月１９〜２１日の間に最初に開かれた。参照ソフトウェアの１つのバージョン、すなわち、Joint Exploration Model 2 (JEM 2)は、https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-2.0/.からダウンロードされることができる。ＪＥＭ２のためのアルゴリズムは、J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, J. Boyce, “Algorithm description of Joint Exploration Test Model 2”, JVET-B1001, San Diego, Mar. 2016に説明されており、その説明は参照によってここに組み込まれる。参照ソフトウェアの別のバージョン、すなわち、Joint Exploration Model 3 (JEM 3)は、https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-3.0/.からダウンロードされることができる。ＪＥＭ３についてのアルゴリズムの説明はまた、ＪＶＥＴ−Ｃ１００１とも呼ばれ得、参照によってここに組み込まれる。

[0036] 本開示の技法は、説明を容易にするためにＨＥＶＣ用語を利用し得る。しかしながら、本開示の技法はＨＥＶＣに限定されると見なされるべきではなく、実際には本開示の技法は、ＨＥＶＣの後継の規格、例えばＨ．２６６およびそれの拡張においてインプリメントされ得ることが明示的に考慮されている。

[0037] 図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は各々、オーディオエンコーダおよびデコーダと統合され得、オーディオおよびビデオの両方を共通データストリームまたは別々のデータストリームにおいて符号化することに対処するために、適したＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。該当する場合、いくつかの例では、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルに準拠し得る。

[0038] ビデオエンコーダ２０およびビデオデコーダ３０は各々、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せのような多様な好適なエンコーダ回路構成またはデコーダ回路構成のうちのいずれとしてもインプリメントされ得る。これらの技法が部分的にソフトウェアにおいてインプリメントされるとき、デバイスは、ソフトウェアのための命令を、好適な、非一時的なコンピュータ読み取り可能な媒体に記憶し、本開示の技法を実施するために１つまたは複数のプロセッサを使用してハードウェアにおいてそれら命令を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのうちのいずれも、それぞれのデバイスにおいて、組み合わせられたエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として、統合され得る。

[0039] ＨＥＶＣおよび他のビデオコーディング仕様では、ビデオシーケンスは典型的に、一連のピクチャを含む。ピクチャはまた、「フレーム（frame）」とも呼ばれ得る。１つの例示的なアプローチでは、ピクチャは、Ｓ_Ｌ、Ｓ_Ｃｂ、およびＳ_Ｃｒと示される３つのサンプルアレイを含み得る。そのような例示的なアプローチでは、Ｓ_Ｌは、ルーマサンプル（luma sample）の２次元アレイ（すなわちブロック）である。Ｓ_Ｃｂは、Ｃｂクロミナンスサンプルの２次元アレイである。Ｓ_Ｃｒは、Ｃｒクロミナンスサンプルの２次元アレイである。クロミナンスサンプルはまた、ここにおいて「クロマ（chroma）」サンプルとも呼ばれ得る。他の事例では、ピクチャはモノクロであり得、ルーマサンプルのアレイのみを含み得る。

[0040] ピクチャの符号化された表現を生成するために、ビデオエンコーダ２０は、コーディングツリーユニット（ＣＴＵ：coding tree unit）のセットを生成し得る。ＣＴＵの各々は、ルーマサンプルのコーティングツリーブロック（coding tree block）、クロマサンプルの２つの対応するコーティングツリーブロック、およびそれらコーティングツリーブロックのサンプルをコード化するために使用されるシンタックス構造（syntax structure）を備え得る。モノクロピクチャまたは３つの別々の色平面を有するピクチャにおいては、ＣＴＵは、単一のコーティングツリーブロック、およびそのコーティングツリーブロックのサンプルをコード化するために使用されるシンタックス構造を備え得る。コーティングツリーブロックは、サンプルのＮｘＮブロックであり得る。ＣＴＵはまた、「ツリーブロック（tree block）」または「最大コーディングユニット（largest coding unit）」（ＬＣＵ）とも呼ばれ得る。ＨＥＶＣのＣＴＵは、Ｈ．２６４／ＡＶＣのような他の規格のマクロブロックとおおまかに類似し得る。しかしながら、ＣＴＵは必ずしも特定のサイズに限定されず、１つまたは複数のコーディングユニット（ＣＵ：coding unit）を含み得る。スライスは、ラスター走査順序で連続して並べられた整数個のＣＴＵを含み得る。

[0041] コード化されたＣＴＵを生成するために、ビデオエンコーダ２０は、コーティングツリーブロックをコーディングブロック（coding block）へと分割するために、ＣＴＵのコーティングツリーブロックに対して四分木区分（quad-tree partitioning）を再帰的に実施し得るので、よって「コーディングツリーユニット」という名が付いている。コーディングブロックは、サンプルのＮｘＮブロックであり得る。ＣＵは、ルーマサンプルアレイ、Ｃｂサンプルアレイ、およびＣｒサンプルアレイを有するピクチャの、ルーマサンプルのコーディングブロック、およびクロマサンプルの２つの対応するコーディングブロック、ならびにそれらコーディングブロックのサンプルをコード化するために使用されるシンタックス構造を備え得る。モノクロピクチャまたは３つの別々の色平面を有するピクチャでは、ＣＵは、単一のコーディングブロック、およびそのコーディングブロックのサンプルをコード化するために使用されるシンタックス構造を備え得る。

[0042] ビデオエンコーダ２０は、ＣＵのコーディングブロックを１つまたは複数の予測ブロックへと区分し得る。予測ブロックは、同じ予測が適用されるサンプルの長方形（すなわち、正方形または非正方形の）ブロックである。ＣＵの予測ユニット（ＰＵ：prediction unit）は、ルーマサンプルの予測ブロック、クロマサンプルの２つの対応する予測ブロック、およびそれら予測ブロックを予測するために使用されるシンタックス構造を備え得る。モノクロピクチャまたは３つの別々の色平面を有するピクチャでは、ＰＵは、単一の予測ブロック、およびその予測ブロックを予測するために使用されるシンタックス構造を備え得る。ビデオエンコーダ２０は、ＣＵの各ＰＵのルーマ、Ｃｂ、およびＣｒ予測ブロックについての予測的なルーマ、Ｃｂ、およびＣｒブロックを生成し得る。

[0043] ビデオエンコーダ２０は、ＰＵについての予測ブロックを生成するためにイントラ予測（intra prediction）またはインター予測（inter prediction）を使用し得る。ビデオエンコーダ２０があるＰＵの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ２０は、そのＰＵに関連するピクチャの復号されたサンプルに基づいて、ＰＵの予測ブロックを生成し得る。ビデオエンコーダ２０があるＰＵの予測ブロックを生成するためにインター予測を使用する場合、ビデオエンコーダ２０は、そのＰＵに関連するピクチャ以外の１つまたは複数のピクチャの復号されたサンプルに基づいて、そのＰＵの予測ブロックを生成し得る。

[0044] ビデオエンコーダ２０がＣＵの１つまたは複数のＰＵについての予測的なルーマ、Ｃｂ、およびＣｒブロックを生成した後、ビデオエンコーダ２０は、ＣＵについてのルーマ残差ブロックを生成し得る。ＣＵのルーマ残差ブロック中の各サンプルは、ＣＵの予測的なルーマブロックのうちの１つ中のルーマサンプルと、ＣＵの元のルーマコーディングブロック中の対応するサンプルとの間の差を示す。加えて、ビデオエンコーダ２０は、ＣＵについてのＣｂ残差ブロックを生成し得る。ＣＵのＣｂ残差ブロック中の各サンプルは、ＣＵの予測的なＣｂブロックのうちの１つ中のＣｂサンプルと、ＣＵの元のＣｂコーディングブロック中の対応するサンプルとの間の差を示し得る。ビデオエンコーダ２０はまた、ＣＵについてのＣｒ残差ブロックを生成し得る。ＣＵのＣｒ残差ブロック中の各サンプルは、ＣＵの予測的なＣｒブロックのうちの１つ中のＣｒサンプルと、ＣＵの元のＣｒコーディングブロック中の対応するサンプルとの間の差を示し得る。

[0045] さらに、ビデオエンコーダ２０は、ＣＵのルーマ、Ｃｂ、およびＣｒ残差ブロックを１つまたは複数のルーマ、Ｃｂ、およびＣｒ変換ブロック（transform block）へと分解するために四分木区分を使用し得る。変換ブロックは、同じ変換が適用されるサンプルの長方形（例えば、正方形または非正方形）のブロックである。ＣＵの変換ユニット（ＴＵ：transform unit）は、ルーマサンプルの変換ブロック、クロマサンプルの２つの対応する変換ブロック、およびそれら変換ブロックサンプルを変換するために使用されるシンタックス構造を備え得る。したがって、ＣＵの各ＴＵは、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロックに関連し得る。ＴＵに関連するルーマ変換ブロックは、ＣＵのルーマ残差ブロックのサブブロックであり得る。Ｃｂ変換ブロックは、ＣＵのＣｂ残差ブロックのサブブロックであり得る。Ｃｒ変換ブロックは、ＣＵのＣｒ残差ブロックのサブブロックであり得る。モノクロピクチャまたは３つの別々の色平面を有するピクチャでは、ＴＵは、単一の変換ブロック、およびその変換ブロックのサンプルを変換するために使用されるシンタックス構造を備え得る。

[0046] ビデオエンコーダ２０は、ＴＵのルーマ変換ブロックに対して１つまたは複数の変換を適用してそのＴＵについてのルーマ係数ブロックを生成し得る。係数ブロックは、変換係数の２次元アレイであり得る。変換係数は、スカラー量であり得る。ビデオエンコーダ２０は、ＴＵのＣｂ変換ブロックに対して１つまたは複数の変換を適用してそのＴＵについてのＣｂ係数ブロックを生成し得る。ビデオエンコーダ２０は、ＴＵのＣｒ変換ブロックに対して１つまたは複数の変換を適用してそのＴＵについてのＣｒ係数ブロックを生成し得る。

[0047] 係数ブロック（例えば、ルーマ係数ブロック、Ｃｂ係数ブロック、またはＣｒ係数ブロック）を生成した後、ビデオエンコーダ２０は、その係数ブロックを量子化し得る。量子化は一般的には、変換係数を表すために使用されるデータの量を可能な限り減少させるために変換係数が量子化される処理を指し、それはさらなる圧縮を提供する。ビデオエンコーダ２０が係数ブロックを量子化した後、ビデオエンコーダ２０は、量子化された変換係数を示すシンタックス要素をエントロピー符号化し得る。例えば、ビデオエンコーダ２０は、量子化された変換係数を示すシンタックス要素に対してコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：Context-Adaptive Binary Arithmetic Coding）を実施し得る。

[0048] ビデオエンコーダ２０は、コード化されたピクチャの表現を形成するビットのシーケンスおよび関連するデータを含むビットストリームを出力し得る。ビットストリームは、ネットワーク抽象レイヤ（ＮＡＬ：Network Abstraction Layer）ユニットのシーケンスを備え得る。ＮＡＬユニットは、ＮＡＬユニット中のデータのタイプのインジケーションと、必要に応じてエミュレーション防止ビットが組み入れられたローバイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）の形式でそのデータを含むバイトとを含む、シンタックス構造である。ＮＡＬユニットの各々は、ＮＡＬユニットヘッダを含み、ＲＢＳＰをカプセル化する。ＮＡＬユニットヘッダは、ＮＡＬユニットタイプコードを示すシンタックス要素を含み得る。ＮＡＬユニットのＮＡＬユニットヘッダによって指定されるＮＡＬユニットタイプコードは、ＮＡＬユニットのタイプを示す。ＲＢＳＰは、ＮＡＬユニット内にカプセル化された整数個のバイトを含むシンタックス構造であり得る。いくつかの事例では、ＲＢＳＰはゼロビットを含む。

[0049] 異なるタイプのＮＡＬユニットは、異なるタイプのＲＢＳＰをカプセル化し得る。例えば、第１のタイプのＮＡＬユニットは、ＰＰＳについてのＲＢＳＰをカプセル化し得、第２のタイプのＮＡＬユニットは、コード化されたスライスについてのＲＢＳＰをカプセル化し得、第３のタイプのＮＡＬユニットは、ＳＥＩメッセージについてのＲＢＳＰをカプセル化し得る、等である。（ＳＥＩメッセージおよびパラメータセットについてのＲＢＳＰとは対照的に）ビデオコーディングデータについてのＲＢＳＰをカプセル化するＮＡＬユニットは、ＶＣＬ ＮＡＬユニットと呼ばれ得る。

[0050] ビデオデコーダ３０は、ビデオエンコーダ２０によって生成されるビットストリームを受信し得る。加えて、ビデオデコーダ３０は、ビットストリームからシンタックス要素を取得するために、ビットストリームをパース（parse）し得る。ビデオデコーダ３０は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構成し得る。ビデオデータを再構成するための処理は、ビデオエンコーダ２０によって実施される処理と概して逆の関係（generally reciprocal to）であり得る。加えて、ビデオデコーダ３０は、現在ＣＵのＴＵに関連する係数ブロックを逆量子化し得る。ビデオデコーダ３０は、現在ＣＵのＴＵに関連する変換ブロックを再構成するために係数ブロックに対して逆変換を実施し得る。ビデオデコーダ３０は、現在ＣＵのＰＵについての予測ブロックのサンプルを現在ＣＵのＴＵの変換ブロックの対応するサンプルに追加することによって現在ＣＵのコーディングブロックを再構成し得る。ピクチャの各ＣＵについてのコーディングブロックを再構成することによって、ビデオデコーダ３０は、ピクチャを再構成し得る。

[0051] 以下は、離散サインおよびコサイン変換の説明である。ビデオエンコーダ２０およびビデオデコーダは、残差ビデオデータをコード化するために、変換および逆変換をそれぞれ使用し得る。変換は、入力信号の代替的な表現を導出する処理を示す。例えば、変換は、（例えば、ビデオ符号化においては）ピクセル領域から周波数領域へ、または（例えば、ビデオ復号においては）周波数領域からピクセル領域へ、値を変換する。Ｎポイントのベクトルｘ＝［ｘ_０，ｘ_１，…，ｘ_Ｎ−１］^Ｔおよび所与のベクトルのセット｛Φ_０，Φ_１，…，Φ_Ｍ−１｝を所与とすると、ｘは、Φ_０，Φ_１，…，Φ_Ｍ−１の一次結合を使用して正確に表されるまたは近似されることができ、それは、以下の様に定式化されることができ、

ここで、

は、ｘの近似値であるかまたはｘに等しい可能性があり、ベクトルｆ＝［ｆ_０，ｆ_１，ｆ_２，．．，ｆ_Ｍ−１］は、変換係数ベクトル（transform coefficient vector）と呼ばれ、｛Φ_０，Φ_１，…，Φ_Ｍ−１｝は変換基底ベクトル（transform basis vector）である。

[0052] ビデオコーディングのシナリオでは、変換係数は、大体非相関およびスパース（roughly non-correlated and sparse）である、すなわち、入力ベクトルｘのエネルギは、いくつかの変換係数に対してのみに集中（compacted）され、残りの大多数の変換係数は典型的には０に近い。例えば、ビデオエンコーダが変換ブロックを係数ブロックに変換するとき、係数ブロック中の非ゼロ係数（nonzero coefficient）値は、係数ブロックの左上角（top-left corner）においてまとめてグループ化される傾向があり、他の係数値の大多数はゼロである。係数ブロックの左上角の近くにグループ化される非ゼロ係数は低周波数成分を反映するのに対して、ゼロになる傾向がある係数ブロックの右下角（bottom-right corner）近くの係数値は、高周波数成分を反映する。

[0053] 特定の入力データを所与とすると、エネルギ集中の観点から最適な変換は、いわゆるカルーネンレーベ変換（ＫＬＴ：Karhunen-Loeve transform）であり、それは変換基底ベクトルとして入力データの共分散行列（covariance matrix）の固有ベクトル（eigen vector）を使用する。ゆえに、ＫＬＴは、実際にはデータ依存型変換であり、一般的な数学的定式化を有しない。しかしながら、ある特定の仮定の下で、例えば、入力データが一次固定マルコフ過程（a first-order stationary Markov process）を形成するとき、対応するＫＬＴは実際ユニタリ変換のシヌソイダルファミリ（sinusoidal family）のメンバであることが文献において証明されており、それはJain, A.K., A sinusoidal family of unitary transforms, IEEE Trans. on Pattern Analysis and Machine Intelligence, 1, 356, 1979に説明されている。ユニタリ変換のシヌソイダルファミリは、以下のように定式化される変換基底ベクトルを使用した変換を示し、

ここでｅは２．７１８２８におおよそ等しい自然対数の底であり、Ａ、Ｂ、およびθは一般に複素数であり、ｍの値に依存する。

[0054] （一次固定マルコフ過程についての）離散フーリエ、コサイン、サイン、およびＫＬＴを含むいくつかの周知の変換は、ユニタリ変換のこのシヌソイダルファミリのメンバである。S. A. Martucci, "Symmetric convolution and the discrete sine and cosine transforms," IEEE Trans. Sig. Processing SP-42, 1038-1051 (1994)、によれば、完全な離散コサイン変換（ＤＣＴ：discrete cosine transform）および離散サイン変換（ＤＳＴ：discrete sine transform）ファミリは、異なるタイプに基づいた合計１６個の変換を含み、それはすなわち、Ａ、Ｂ、およびθの異なる値であり、異なるタイプのＤＣＴおよびＤＳＴの完全な定義は以下に与えられる。

[0055] 入力Ｎポイントベクトルがｘ＝［ｘ_０，ｘ_１，…，ｘ_Ｎ−１］^Ｔと示され、それがマトリックスを乗算することによってｙ＝［ｙ_０，ｙ_１，…，ｙ_Ｎ−１］^Ｔと示される別のＮポイント変換係数ベクトルへと変換されると仮定すると、それの処理は、以下の変換定式化のうちの１つに従ってさらに例示されることができ、ここでｋは、両端値を含む０〜Ｎ−１にわたる：

[0056] 上記は、異なるＤＣＴおよびＤＳＴタイプの例を提供し、全体で１６種の変換タイプが存在する。変換タイプ（transform type）は、変換基底関数（transform basis function）の数学的定式化によって規定される。変換タイプと変換サイズとは混同されるべきではない。変換タイプは、基底関数を指し、それに対して変換サイズは変換のサイズを指す。例えば、４ポイントＤＳＴ−ＶＩＩおよび８ポイントＤＳＴ−ＶＩＩは、Ｎの値（例えば、４ポイントまたは８ポイント）に関わらず同じ変換タイプを有する。

[0057] 一般性を失うことなく、上記変換タイプはすべて、以下の一般化された定式化を使用して表されることができる：

ここでＴは、ＤＣＴ Ｔｙｐｅ−Ｉ〜ＤＣＴ Ｔｙｐｅ−ＶＩＩＩ、またはＤＳＴ Ｔｙｐｅ−Ｉ〜ＤＳＴ Ｔｙｐｅ−ＶＩＩＩ等の１つのある特定の変換の定義によって指定される変換マトリックス（transform matrix）であり、Ｔの行ベクトル、例えば、［Ｔ_ｉ，０，Ｔ_ｉ，１，Ｔ_ｉ，２，…，Ｔ_{ｉ，Ｎ-１}］は、ｉ番目の変換基底ベクトルである。Ｎポイント入力ベクトルに対して適用される変換は、Ｎポイント変換と呼ばれる。

[0058] 上記の変換定式化は、１−Ｄ入力データｘに対して適用されるものであるが、それは以下のようなマトリックス乗算公式において表されることができることにもまた留意されたい
ｙ＝Ｔ・ｘ
ここでＴは、変換マトリックスを示し、ｘは入力データベクトルを示し、ｙは出力変換係数ベクトルを示す。

[0059] 例えば、ビデオエンコーダは、変換係数ベクトルを生成するためにマトリックスの乗算ｙ＝Ｔ・ｘを実施し得る。ビデオデコーダは、変換係数ベクトルから変換ベクトルを生成するために逆マトリックス乗算（inverse matrix multiplication）を実施し得る。

[0060] 上で紹介されたような変換は、１−Ｄ入力データに対して適用され、変換はまた２−Ｄ入力データソースについても拡張されることができる。Ｘは入力ＭｘＮデータアレイであると仮定する。２−Ｄ入力データに対して変換を適用する典型的な方法は、分離可能なおよび分離不可能な２−Ｄ変換を含む。

[0061] 分離可能な２−Ｄ変換は、連続的にＸの水平および垂直ベクトルに対して１−Ｄ変換を適用し、以下のように定式化される：
Ｙ＝Ｃ・Ｘ・Ｒ^Ｔ
ここでＣおよびＲは所与のＭｘＭおよびＮｘＮ変換マトリックスをそれぞれ示す。

[0062] 定式化から、ＣはＸの列ベクトルに対する１−Ｄ変換に適用され、一方でＲはＸの行ベクトルに対する１−Ｄ変換に適用されることを見て取ることができる。本開示の後半では、簡潔さのために、ＣおよびＲを左（垂直）および右（水平）変換として表し、それらの両方は変換ペアを形成する。ＣがＲに等しく、直交マトリックスである場合がある。そのような場合には、分離可能な２−Ｄ変換は、１つの変換マトリックスのみによって決定される。

[0063] 分離不可能な２−Ｄ変換は、例として以下の数学的マッピングを行うことによって、Ｘの全要素を単一のベクトル、つまりＸ’へと最初に再編成した：
Ｘ′_{（ｉ・Ｎ＋ｊ）}＝Ｘ_ｉ，ｊ
[0064] 次いで１−Ｄ変換Ｔ’が以下のようにＸ’に対して適用される：
Ｙ＝Ｔ′・Ｘ
ここでＴ’は、（Ｍ＊Ｎ）ｘ（Ｍ＊Ｎ）変換マトリックスである。

[0065] ビデオコーディングでは、分離可能な２−Ｄ変換が典型的に適用される、なぜなら分離可能な２−Ｄ変換は典型的に、１−Ｄ変換に比べてより少ない演算（加算、乗算）カウントを使用するからである。以下により詳細に説明されるように、本開示は、ビデオエンコーダおよびビデオデコーダが左および右変換を決定するのに用いる例示的な技法を説明する。

[0066] 例えば、ビデオエンコーダおよびビデオデコーダは、複数の変換サブセットを決定し得、各変換サブセットは複数の候補変換を識別する。１６種の可能性のある変換（例えば、ＤＣＴ−１〜ＤＣＴ−８およびＤＳＴ−１〜ＤＳＴ−８）の例として、ビデオエンコーダおよびビデオデコーダは、３つの変換サブセットを決定し得、それら変換サブセットの各々は、１６種の変換のうちの２つ以上を含む。ビデオエンコーダおよびビデオデコーダは、３つの変換サブセットのうちの１つを選択して、その選択された変換サブセットから左変換（例えば、Ｃ）を決定し、および３つの変換サブセットのうちの１つを選択して、その選択された変換サブセットから右変換（例えば、Ｒ）を決定し得る。選択された変換サブセットは、異なるサブセットまたは同じサブセットであり得る。

[0067] 変換効率（transform efficiency）は、異なる基準によって測定されることができ、１つの伝統的な測定は、変換効率の定義であり、以下に説明されるような変換コーディング利得（transform coding gain）である：

ここでσ^２ _Ｙｎは、変換係数Ｙ（ｎ）の分散（variance）である。より多くの例がまたhttp://web.stanford.edu/class/ee398a/handouts/lectures/07-TransformCoding.pdfにおいても見つけられ得る。

[0068] 以下は、ＨＥＶＣにおいて適用される変換タイプの説明である。Ｈ．２６４／ＡＶＣのような例示的なビデオコーデックでは、４ポイントおよび８ポイント離散コサイン変換（ＤＣＴ）Ｔｙｐｅ−ＩＩの整数の近似値は、イントラおよびインター予測残差の両方に対して適用される。イントラ予測残差は、イントラ予測からの残差を指し、インター予測残差は、インター予測からの残差を指す。残差、インター予測およびイントラ予測はすべて以下に、より詳細に説明される。一般に、残差ブロックは、複数の変換ブロックへと分割される。ビデオ符号化では、変換は、係数ブロックを生成するために、変換ブロックの各々に適用される。ビデオ復号では、変換は、変換ブロックを生成するおよび残差ブロックを再構成するために、係数ブロックの各々に適用される。

[0069] 残差サンプルの様々な統計値により良く順応するために、より新しい世代のビデオコーデックでは、ＤＣＴ Ｔｙｐｅ−ＩＩ以外のより柔軟なタイプの変換が利用される。例えば、ＨＥＶＣでは、４ポイントＴｙｐｅ−ＶＩＩ離散サイン変換（ＤＳＴ）の整数の近似値が、イントラ予測残差のために利用され、それは、ＤＳＴ Ｔｙｐｅ−ＶＩＩがイントラ予測方向に沿って生成される残差ベクトルについてＤＣＴ Ｔｙｐｅ−ＩＩより効率的であること、例えば、ＤＳＴ Ｔｙｐｅ−ＶＩＩが水平イントラ予測方向によって生成される行残差ベクトルについてＤＣＴ Ｔｙｐｅ−ＩＩより効率的であること、が理論的に証明されており、かつ実験的に正当性が立証されている。例えば、J. Han、A. SaxenaおよびK. Rose、“Towards jointly optimal spatial prediction and adaptive transform in video/image coding,” IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), March 2010, pp. 726-729参照。

[0070] ＨＥＶＣでは、４ポイントＤＳＴ Ｔｙｐｅ−ＶＩＩの整数の近似値は、４ｘ４ルーマイントラ予測残差ブロックに対してのみ適用される（ルーマイントラ予測残差ブロックは、以下により詳細に説明される）。ＨＥＶＣで使用される４ポイントＤＳＴ−ＶＩＩは、図２Ａに示される。

[0071] ＨＥＶＣでは、４ｘ４ルーマイントラ予測残差ブロックでない残差ブロックについて、４ポイント、８ポイント、１６ポイント、および３２ポイントのＤＣＴ Ｔｙｐｅ−ＩＩの整数の近似値がまた適用される。図２Ｂは、４ポイントＤＣＴ−ＩＩの例を例示し、図２Ｃは、８ポイントＤＣＴ−ＩＩの例を例示し、図２Ｄは、１６ポイントＤＣＴ−ＩＩの例を例示し、および図２Ｅは、３２ポイントＤＣＴ−ＩＩの例を例示する。図２Ａ〜図２Ｅは、タイプＩＩの異なるサイズのＤＣＴの例を例示し、図２Ａ〜図２Ｅと同様に、異なるタイプのＮポイントＤＣＴおよびＤＳＴの例がある。

[0072] 上述したように、ＣＵは１つまたは複数のＴＵを含む。以下は、ＨＥＶＣにおける残差四分木に基づく変換スキームを説明する。残差ブロックの様々な特性に適応するために、残差四分木（ＲＱＴ：residual quadtree）を使用した変換コーディング構造がＨＥＶＣにおいて適用され、それはhttp://www.hhi.fraunhofer.de/fields-of-competence/image-processing/research-groups/image-video-coding/hevc-high-efficiency-video-coding/transform-coding-using-the-residual-quadtree-rqt.htmlに簡単に説明されている。

[0073] 上述したように、各ピクチャはＣＴＵへと分割され、それらは特定のタイルまたはスライスについてラスター走査順序でコード化される。ＣＴＵは、四角ブロック（square block）であり、四分木のルート（root）、すなわち、コーディングツリー（coding tree）を表す。ＣＴＵサイズは、８×８〜６４×６４のルーマサンプルにわたり得るが、典型的には６４×６４が使用される。各ＣＴＵは、コーディングユニット（ＣＵ）と呼ばれるより小さい四角ブロックにさらに分割されることができる。ＣＴＵが再帰的にＣＵへと分割された後、各ＣＵは、予測ユニット（ＰＵ）および変換ユニット（ＴＵ）へとさらに分割される。ＣＵのＴＵへの区分は、四分木アプローチに基づいて再帰的に実行されるので、よって各ＣＵの残差信号は、ツリー構造、つまり残差四分木（ＲＱＴ）によってコード化される。ＲＱＴは、ＴＵサイズに４×４から３２×３２までのルーマサンプルを許す。

[0074] 図３は、ＣＵが「ａ」〜「ｊ」の文字でラベル付けされた１０個のＴＵと対応するブロック区分を含む例を示す。ＲＱＴの各ノードは、実際、変換ユニット（ＴＵ）である。個々のＴＵは、深さ優先ツリー巡回順序（depth-first tree traversal order）で処理され、それは、アルファベット順として図３に例示されており、それは深さ優先巡回での再帰的なＺスキャンに従う（follows a recursive Z-scan）。四分木アプローチは、残差信号の様々な空間−周波数特性に対する変換の適応を可能にする。典型的には、より大きな変換ブロックサイズは、より大きな空間のサポートを有するものであり、より良い周波数分解能を提供する。しかしながら、より小さい変換ブロックサイズは、より小さい空間のサポートを有するものであり、より良い空間分解能を提供する。これら２つ、空間分解能と周波数分解能との間のトレードオフは、例えばレートひずみ最適化技法に基づいて、（例えば、ビデオエンコーダ２０による）エンコーダモード決定によって選ばれる。レートひずみ最適化技法は、コーディングビットと復元ひずみとの重み付けされた合計、すなわち、レートひずみコスト（rate-distortion cost）をコーディングモード（coding mode）（例えば、特定のＲＱＴ分割構造）ごとに計算し、最小のレートひずみコスト（least rate-distortion cost）を有するコーディングモードを最良のモードとして選択する。

[0075] ＲＱＴにおいて３つのパラメータ、つまりツリーの最大深度、最小許容変換サイズ、および最大許容変換サイズが定義される。最小および最大変換サイズは、４×４〜３２×３２サンプルにわたる範囲内で変化することができ、それは、前段落で言及したサポートされたブロック変換に対応する。ＲＱＴの最大許容深度は、ＴＵの数を制限する。ゼロに等しい最大深度は、各含まれたＴＢ（変換ブロック）が最大許容変換サイズ、例えば３２ｘ３２に到達する場合にＣＢ（コーディングブロック）がそれ以上分割されることができないことを意味する。

[0076] すべてのこれらのパラメータは、ＲＱＴ構造と相互作用し、およびＲＱＴ構造に影響を与える。ルートＣＢサイズが６４×６４であり、最大深度がゼロに等しく、最大変換サイズが３２×３２に等しい場合を検討する。このケースでは、ＣＢは少なくとも一旦区分される必要があるが、その理由はもしそうでなければそれが６４×６４のＴＢをもたらすことになり、それは許容されていないからである。ＨＥＶＣでは、より大きなサイズの変換、例えば６４ｘ６４の変換は、主として、すべてを考慮すると割に限定されたそれの利益、および比較的より小さな解像度のビデオ（relatively smaller resolution videos）についての比較的高い複雑性が理由で、採用されない。

[0077] ＲＱＴパラメータ、すなわち、最大ＲＱＴ深度、最小および最大変換サイズは、シーケンスパラメータセットレベルにおいてビットストリーム中で送信される。ＲＱＴ深度に関して、イントラおよびインターコード化されたＣＵ（すなわち、イントラ予測された符号化されたＣＵまたはインター予測された復号されたＣＵまたはイントラ予測された符号化されたＣＵまたはインター予測されたＣＵ）について、異なる値が指定されシグナリングされることができる。

[0078] 四分木変換が、イントラおよびインター残差ブロックの両方に対して適用される。典型的には、同じサイズの現在の残差四分木区分のＤＣＴ−ＩＩ変換が、残差ブロックに対して適用される。しかしながら、現在の残差四分木ブロックが４ｘ４であり、イントラ予測によって生成される場合、上記の４ｘ４ＤＳＴ−ＶＩＩ変換が適用される。

[0079] 以下は、ＨＥＶＣにおける係数コーディングを説明する。ＴＵサイズに関わらず、変換ユニットの残差は、オーバーラップ（overlap）していない係数グループ（ＣＧ：coefficient group）を用いてコード化され、各々はＴＵの４ｘ４ブロックの係数を含む。例えば、３２ｘ３２のＴＵは合計６４のＣＧを有し、１６ｘ１６のＴＵは合計１６のＣＧを有する。ＴＵ内のＣＧは、ある特定の事前に定義された走査順序に従ってコード化される。各ＣＧをコード化するとき、現在のＣＧ内の係数は、４ｘ４ブロックのためのある特定の事前に定義された走査順序に従って走査およびコード化される。図４は、４つのＣＧを含む８ｘ８のＴＵについての係数走査を例示する。

[0080] 色成分ごとに、初めに１つのフラグが、現在の変換ユニットが少なくとも１つの非ゼロ係数を有するかどうかを示すためにシグナリングされ得る。少なくとも１つの非ゼロ係数が存在する場合、変換ユニット内の係数走査順序における最後の有効係数の位置が次いで、変換ユニットの左上角に対するコーディネーション（coordination）を用いて明示的にコード化される。そのコーディネーションの垂直または水平成分は、それのプリフィックスおよびサフィックスによって表され、ここでプリフィックスはトランケーティド・ライス（ＴＲ：truncated rice）を用いて２値化され、サフィックスは、固定長を用いて２値化される。

[0081] ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘの値は、変換ブロック内の走査順序における最後の有効係数の列の位置のプリフィックスを指定する。ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘの値は、両端値を含む０〜（ｌｏｇ２ＴｒａｆｏＳｉｚｅ＜＜１）−１の範囲にあるものとする。

[0082] ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘの値は、変換ブロック内の走査順序における最後の有効係数の行の位置のプリフィックスを指定する。ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘの値は、両端値を含む０〜（ｌｏｇ２ＴｒａｆｏＳｉｚｅ＜＜１）−１の範囲にあるものとする。

[0083] ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｓｕｆｆｉｘの値は、変換ブロック内の走査順序における最後の有効係数の列の位置のサフィックスを指定する。ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｓｕｆｆｉｘの値は、両端値を含む０〜（１＜＜（（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘ＞＞１）−１））−１の範囲にあるものとする。

[0084] 変換ブロック内の走査順序における最後の有効係数の列の位置ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸは、以下の様に導出される：
−ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｓｕｆｆｉｘが存在しない場合、以下が適用される：
ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸ＝ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘ
−もしそうでなければ（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｓｕｆｆｉｘが存在すれば）以下が適用される：
ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸ＝（１＜＜（（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘ＞＞１）−１））＊（２＋（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｐｒｅｆｉｘ＆１））＋ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｘ＿ｓｕｆｆｉｘ
[0085] ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｓｕｆｆｉｘの値は、変換ブロック内の走査順序における最後の有効係数の行の位置のサフィックスを指定する。ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｓｕｆｆｉｘの値は、両端値を含む０〜（１＜＜（（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘ＞＞１）−１））−１の範囲にあるものとする。

[0086] 変換ブロック内の走査順序における最後の有効係数の行の位置ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹは、以下の様に導出される：
−ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｓｕｆｆｉｘが存在しない場合、以下が適用される：
ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹ＝ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘ

−もしそうでなければ（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｓｕｆｆｉｘが存在すれば）以下が適用される：
ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹ＝（１＜＜（（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘ＞＞１）−１））＊（２＋（ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｐｒｅｆｉｘ＆１））＋ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｙ＿ｓｕｆｆｉｘ
[0087] ｓｃａｎＩｄｘの値が２に等しいとき、座標は以下の様にスワップされる：
（ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸ，ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹ）＝Ｓｗａｐ（ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸ，ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹ）
[0088] そのようなコード化される位置と、またＣＧの係数走査順序とを用いると、１つのフラグがさらに（走査順序で）最後のＣＧ以外のＣＧについてシグナリングされ、それは、それが非ゼロ係数を含むかどうかを示す。非ゼロ係数を包含し得るそれらのＣＧについて、有効フラグ、係数の絶対値、およびサイン情報は、事前に定義された４ｘ４の係数走査順序に従って係数ごとにさらにコード化され得る。

[0089] 上述したように、本開示で説明される技法は、ビデオエンコーダ２０が変換ブロックを係数ブロックに変換するために適用する変換を決定するための方法と、ビデオデコーダ３０が係数ブロックを変換ブロックに変換するために（例えば、逆変換として）適用する変換を決定するための方法を説明する。以下は、イントラおよびインター予測残差のための複数の変換（例えば、残差ブロックがイントラ予測から生成される場合についての、および残差ブロックがインター予測から生成される場合についての異なる変換タイプ）を説明する。

[0090] 一部のケースでは、ＤＳＴ Ｔｙｐｅ−ＶＩＩは従来のＤＣＴ Ｔｙｐｅ−ＩＩに比べて効率的にイントラコーディング効率を改善することができるにも関わらず、変換効率は比較的限定されている、なぜなら、予測残差は様々な統計値を提示し、かつＤＣＴ Ｔｙｐｅ−ＩＩおよびＤＳＴ Ｔｙｐｅ−ＶＩＩの固定された使用は、すべての可能性のあるケースに効率的に適応することができないからである。いくつか技法が異なる複数のケースに適応するために提案されている。

[0091] S.-C. Lim、D.-Y. Kim、S. Jeong、J. S. Choi、H. ChoiおよびY.-L. Lee、“Rate-distortion optimized adaptive transform coding,” Opt. Eng., vol. 48, no. 8, pp. 087004-1-087004-14, Aug. 2009には、予測残余（prediction residue）についてのＤＣＴまたはＤＳＴの整数バージョンを適応的に用いる新しい変換スキームが提案され、各ブロックについて、ＤＣＴまたはＤＳＴ変換が予測残余のために使用されるかどうかがシグナリングされる。Y. YeおよびM. Karczewicz、“Improved H.264 intra coding based on bidirectional intra prediction, directional transform, and adaptive coefficient scanning,” in Proc. 15th IEEE Int. Conf. Image Process., Oct. 2008, pp. 2116-2119では、モード依存型変換（ＭＤＤＴ：mode dependent transform m）が適用されるように、ＫＬＴペアとして事前に定義された、一意の対の変換（ＣおよびＲ）に各イントラ予測モードがマッピングされることができることが提案されている。この方法で、異なるイントラ予測モードについて異なるＫＬＴ変換が使用されることができるが、しかしながら、いずれの変換が使用されることになるかは事前に定義され、イントラ予測モードに依存する。

[0092] しかしながら、X. Zhao、L. Zhang、S. W. Ma、およびW. Gao、“Video coding with rate-distortion optimized transform,” IEEE Trans. Circuits Syst. Video Technol., vol. 22, no. 1, pp. 138-151, Jan. 2012では、より多くの変換が使用されることができ、およびオフライントレーニング処理（off-line training process）から導出される事前に定義された変換候補（transform candidate）のセットからの変換に対するインデックスが明示的にシグナリングされる。ＭＤＤＴと同様に、各イントラ予測方向は、それの一意のセットの対の変換を有し得る。インデックスは、どの変換ペアがそのセットから選ばれるかを指定するためにシグナリングされる。例えば、最も小さいブロックサイズ４ｘ４について４つまでの垂直ＫＬＴ変換と４つまでの水平ＫＬＴ変換が存在し、よって１６個の組合せが選ばれ得る。より大きなブロックサイズについては、より少ない数の組合せが使用される。「Video coding with rate−distortion optimized transform」において提案された方法がイントラおよびインター予測残差の両方に適用される。インター予測残差については、１６個までの組合せのＫＬＴ変換が選ばれることができ、それらの組合せ（４ｘ４については４つ、および８ｘ８については１６個）のうちの１つに対するインデックスがブロックごとにシグナリングされる。

[0093] A. SaxenaおよびF. Fernandes、“DCT/DST-based transform coding for intra prediction in image/video coding,” IEEE Trans. Image ProcessingおよびC. Yeo、Y. H. Tan、Z. Li、およびS. Rahardja、“Mode-dependent transforms for coding directional intra prediction residuals,” IEEE Trans. Circuits Syst. Video Technol., vol. 22, no. 4, pp. 545-554, 2012では、複数の変換が使用されるが、しかしながら、（典型的には訓練（train）される必要がある）ＫＬＴ変換を使用する代わりに、ＤＣＴ（ＤＣＴ−ＩＩ）またはＤＳＴ（ＤＳＴ−ＶＩＩ）のいずれかが、（左および右変換（例えば、ＣおよびＲ）の両方が同じである状態で）変換ユニットのために使用され、どちらが使用されるかはシグナリングされるフラグによって決定される。F. Zou、O. C. Au、C. Pang、J. Dai、およびF. Lu、“Rate-Distortion Optimized Transforms Based on the Lloyd-Type Algorithm for Intra Block Coding ,” IEEE Journal of Selected Topics in Signal Processing, Volume:7 , Issue: 6, Nov. 2013では、いくつかの事前に定義されたＫＬＴ変換ペアが使用され、コーディングユニットについて変換ペアに対するインデックスが（導出される代わりに）シグナリングされて、その結果コーディングユニットの各変換ユニットは同じ対の変換を使用する。

[0094] J. An、X. Zhao、X. GuoおよびS. Lei、“Non-CE7: Boundary-Dependent Transform for Inter-Predicted Residue,” JCTVC-G281では、ＴＵのインター予測された残差について複数の変換が、ＣＵ内のそれらのロケーションに従って選ばれる。ＣおよびＲ変換の両方は、ＤＳＴ−ＶＩＩおよびフリップされたバージョンのＤＳＴ−ＶＩＩから選ばれる。ゆえに、４つまでの組合せが、ＣＵ内のＴＵについて可能性がある。しかしながら、組み合せはＰＵのロケーションによって完全に決定されるので、どの組合せが使用されているかをシグナリングする必要はない。

[0095] エンハンストマルチプル変換（ＥＭＴ：enhanced multiple transform）の態様がこれより説明されることとなる。ＪＥＭでは、ＥＭＴ（また時には適応型マルチプル変換（Adaptive Multiple Transform）、すなわち、ＡＭＴと呼ばれることもある）がインターおよびイントラコード化ブロックの両方についての残差コーディングに関して提案されている。このＥＭＴスキームの態様は、２０１６年１月２５日に出願された米国特許出願１５／００５，７３６に説明されている。ＥＭＴは、ＨＥＶＣにおける現在の変換以外のＤＣＴ／ＤＳＴファミリからの複数の選択された変換を利用する。新しく導入された変換マトリックスは、ＤＳＴ−ＶＩＩ、ＤＣＴ−ＶＩＩＩ、ＤＳＴ−ＩおよびＤＣＴ−Ｖである。以下の表は、選択されたＤＳＴ／ＤＣＴの基底関数を示す
[0096] 変換マトリックスの直交性を保つために、変換マトリックスは、ＨＥＶＣにおける変換マトリックスよりも正確に量子化される。１６ビットの範囲内に変換された係数の中間値を保つために、水平変換の後におよび垂直変換の後に、すべての係数は、現在のＨＥＶＣ変換で使用される右シフトと比較して２ビット分多く右にシフトされる。

[0097] ＡＭＴは、幅および高さの両方が６４よりも小さいかまたは６４に等しいＣＵに適用され、ＡＭＴが適用されるかどうかは、ＣＵレベルフラグによって制御される。ＣＵレベルフラグが０に等しいとき、残余を符号化するためにＣＵにおいてＤＣＴ−ＩＩが適用される。ＡＭＴが可能にされたＣＵ内のルーマコーディングブロックについては、２つの追加的なフラグが、使用されることになる水平および垂直変換を識別するためにシグナリングされる。

[0098] イントラ残余（残差）コーディング（intra residue (residual) coding）については、異なるイントラ予測モードの異なる残差統計値に起因して、モード依存型変換候補選択処理（mode-dependent transform candidate selection process）が使用される。３つの変換サブセットが表１に示されるように定義されており、変換サブセットは、表２に定められたようなイントラ予測モードに基づいて選択される。

[0099] サブセットの概念を用いると、変換サブセットは、初めに、ＣＵ−レベルＡＭＴフラグが１に等しいＣＵのイントラ予測モードを使用して表１に基づいて識別される。その後、水平および垂直変換の各々について、表２に従って、識別された変換サブセット中の２つの変換候補のうちの１つが、ラグを伴って明示的にシグナリングされたに基づいて、選択される。

[0100] インター予測残差については、しかしながら、ＤＳＴ−ＶＩＩおよびＤＣＴ−ＶＩＩＩから構成される１つの変換セットのみが、すべてのインターモードについて、および水平および垂直変換の両方について、使用される。

[0101] 分離不可能な二次変換（ＮＳＳＴ：non-separable secondary transform）の態様がこれより説明される。ＪＥＭでは、モード依存型ＮＳＳＴがフォワードコア変換と量子化との間で（エンコーダにおいて）、および量子化解除（de-quantization）と逆コア変換（inverse core transform）との間で（デコーダサイドにおいて）適用される。モード依存型ＮＳＳＴ（ＭＤＮＳＳＴ：mode dependent NSST）の態様は、両方２０１６年９月２０日に出願された米国特許出願第１５／２７０，４５５号および第１５／２７０，５０７号に説明されている。図５は、二次変換の例を示す。図５に示されるように、ＭＤＮＳＳＴは、イントラコード化ＣＵ内の変換係数の４×４のサブグループごとに独立して実施され、イントラＣＵにおいてのみ適用される。

[0102] 分離不可能な変換のアプリケーションは、例として入力を使用して以下の様に説明される。分離不可能な変換を適用するために、４ｘ４の入力ブロックＸ

は、ベクトル

：

として表される。

[0103] 分離不可能な変換は、

として計算され、ここで、

は、変換係数ベクトルを示し、Ｔは１６ｘ１６の変換マトリックスである。１６ｘ１の係数ベクトル

は、そのブロックについての走査順序を使用して４ｘ４ブロック（水平、垂直または対角）として、続いて再編成される。より小さいインデックスを有する係数は、４ｘ４の係数ブロック内により小さい走査インデックスを用いて配置され得る。

[0104] 合計１１×３（方向性モードについて）６＋１×２（非方向性モードについて）の分離不可能な変換マトリックスが存在し、ここで１１は、方向性イントラ予測モード（directional intra prediction mode）についての変換セットの数であり、各変換セットは、３つの変換マトリックスを含む。一方、非方向性モード、すなわち、平面、ＤＣおよびＬＭについては、２つの変換マトリックスを含む１つの変換セットのみが適用される。イントラ予測モードから変換セットへのマッピングは、表３に定義される。ルーマ／クロマ変換係数に適用される変換セットは、表３に従って、対応するルーマ／クロマイントラ予測モードによって指定される。

[0105] 各変換セットについて、選択された分離不可能な二次変換候補はさらに、明示的にシグナリングされたＣＵ−レベルＭＤＮＳＳＴインデックスによって指定される。インデックスは、変換係数の後にイントラＣＵごとに一度ビットストリーム内でシグナリングされ、および切り捨て単項バナライゼーション（truncated unary banalization）が使用される。平面またはＤＣモード（planar or DC mode）の場合は、切り捨て値（truncated value）は２であり、角度イントラ予測モード（angular intra prediction mode）については３である。このＭＤＮＳＳＴインデックスは、１つより多くの非ゼロ係数がＣＵ内にあるときにのみ、シグナリングされる。値がシグナリングされないとき、デフォルト値はゼロである。このシンタックス要素のゼロ値は、二次変換が現在ＣＵに対して適用されないことを示し、値１〜３は、セットからのいずれの二次変換が適用されるべきかを示す。

[0106] ＪＥＭでは、ＭＤＮＳＳＴは、変換スキップモード（transform skip mode）でコード化されたブロックには適用されない。ＭＤＮＳＳＴインデックスがＣＵについてシグナリングされ、ゼロに等しくないとき、ＭＤＮＳＳＴは、ＣＵにおいて変換スキップモードでコード化されたコンポーネントのブロックのためには使用されるべきでない。変換スキップモードにおいてコード化されたすべてのコンポーネントのブロックを有するＣＵのとき、ＭＤＮＳＳＴインデックスはＣＵについてシグナリングされない。

[0107] エンコーダサイドでは、ＣＵレベルＲＤチェックがＣＵについてのＮＳＳＴインデックスを選択するために使用される。つまり、イントラコード化されたＣＵについては、ＣＵレベルＲＤチェックは、ループインデックスとしてＮＳＳＴインデックス値を使用することによって４回ループされる。エンコーダ速度を加速させるために、ループの早期の停止が適用される。より大きな値を有するＮＳＳＴインデックスについてのＲＤチェックは、より小さい値を有するＮＳＳＴインデックスについての現在ＣＵ内に非ゼロの変換された係数が存在しないとき、スキップされる。

[0108] 信号依存型変換（ＳＤＴ：signal-dependent transform）の態様がこれより説明される。C. Lanらによる“Exploiting non-local correlation via signal-dependent transform (SDT).” IEEE Journal of Selected Topics in Signal Processing 5.7 (2011): 1298-1308に説明されているように、フレーム内におよび複数のフレームにわたって多くの同様のパッチが存在することを考慮すると、ＳＤＴはそのような相関を探索し、ＫＬＴによってコーディングパフォーマンスを向上させることができる。この訓練されたＫＬＴは、エネルギをより効率的にコンパクトにすることを意図する変換の役割を果たす。この文脈では、パッチは、ビデオデータのブロックを指す。しかしながら、パッチは、ビデオデータのＣＵ、ＰＵ、またはＴＵのようなシグナリングされた区分と必ずしも１対１の対応を有しない。パッチは、例えば、部分的にのみＣＵ、ＰＵ、またはＴＵとオーバーラップし得るか、あるいは複数のＣＵ、ＰＵ、またはＴＵのうちのいくつかまたはすべてとオーバーラップし得る。

[0109] 図６は、非ローカル相関（non-local correlation）を探索するＫＬＴのフローチャートの例を示す。図６におけるフローチャートは、この概念を説明する。Ｃによって示される現在のコーディングブロックについて、初めに、コーディングブロックの予測ブロックｐおよび再構成されたレフトアップテンプレートｔ_ｂから構成された参照パッチＲが取得される。次いで、この参照パッチは、再構成された領域にわたってＮ個の最も類似したパッチを探索するために使用される。最後に、これらのブロックおよび予測ブロックに基づいた１次元ＫＬＴが計算される。コーディングブロックは、同様の候補ブロックの集まりについてデコーダにおいて知られていない。予測ブロックおよび再構成されたテンプレートは、元のブロックを使用する代わりに同様のブロックの探索をガイドするために使用される。このツールは、様々なブロックサイズ４ｘ４、８ｘ８、１６ｘ１６および３２ｘ３２のために使用される。

[0110] カルーネンレーベ変換（ＫＬＴ）は、エネルギ集中効率から最適な変換であると考えられている。再構成された領域上を探索することによって、参照パッチと最も類似したＮ個のブロックｘ_ｉ，ｉ＝１，２，…，Ｎが取得される。ここで、ｘ_ｉ＝（ｘ_ｉ１，ｘ_ｉ２，…，ｘ_ｉＤ）^Ｔであり、およびＤは、変換ブロックサイズであるベクトル次元（vector dimension）を示す。例として、４ｘ４のコーディングブロックについてＮは１６である。それらのブロックからの予測ｐは減算され、ｕ_ｉ，ｉ＝１，２，…，Ｎとして残差ブロックを取得し、ここで

である。これらの残差ブロックは、ＫＬＴ導出についての平均ゼロのトレーニングサンプル（training sample）として使用される。これらのＮ個のトレーニングサンプルは、Ｕ＝（ｕ_１，ｕ_２，…，ｕ_Ｎ）によって表されることができ、それはＤ×Ｎマトリックスである。共分散行列Σは、
Σ＝ＵＵ^Ｔ （１）
とイニデート（inidated）されることができる。ここでこの共分散行列の次元（dimension）は、Ｄ×Ｄである。ＫＬＴの基底（base）は、すると、この共分散行列の固有ベクトルである。自然のイメージ／ビデオコンテンツについては、候補数Ｎを１００と選択することは、良好なパフォーマンスのために十分であり得る。

[0111] 固有値分解（eigenvalue decomposition）についての計算複雑性（computation complexity）は、０（Ｄ^３）である。Ｄが１６である４ｘ４ブロックについては、複雑性は０（１６^３）であり、それは許容可能である。大きいブロックについては、複雑性は非常に高い可能性がある。Ｄが１０２４である３２ｘ３２のブロックについては、時間複雑性は、例えば、４ｘ４ブロックについてのものよりも２６２１４４倍遅い可能性があり、それはコーディングフレームワークにおいて潜在的に許容できない。

[0112] この点を考慮すると、大きいブロックサイズのＫＬＴを実現可能にするために速いアルゴリズムが利用される。Σの次元（dimension）は、Ｄ×Ｄである。しかしながら、Ｕ^ＴＵは、Ｎ×Ｎとして格段により低い次元を有する。方程式を満たすΣ′＝Ｕ^ＴＵの固有ベクトルΦは、
Ｕ^ＴＵΦ＝ΦΛ （２２）
と計算され得る。
Φは、固有ベクトルマトリックス（eigenvector matrix）を示し、一方、Λは、固有値が対角要素である対角マトリックスを表す。方程式（２）の両側は、Ｕで乗算されることができ、以下が得られる：
ＵＵ^Ｔ ＵΦ＝ＵΦΛ （２３）
この方程式にブラケットを付けると以下が得られる：
（ＵＵ^Ｔ）（ＵΦ）＝（ＵΦ）Λ （２４）
[0113] ＵΦの列ベクトルは、それらの対応する固有値がマトリックスΛの対角要素であるＵＵ^Ｔの固有ベクトルである。φ＝ＵΦとする。これは、高次元共分散行列Ｕ^ＴＵの固有ベクトルが低次元共分散行列Ｕ^ＴＵから取得された固有ベクトルΦでＵを乗算することによって取得されることができることを示す。φおよびΛの次元は、両方Ｄ×Ｎである。ＵＵ^Ｔのすべての他（Ｄ−Ｎ）の固有ベクトルは、ゼロの固有ベクトルを有する。シュミット直交化は、Ｄ×Ｄの固有ベクトルマトリックスを得るためにこれらの（Ｄ−Ｎ）固有ベクトルを満たすために使用され得る。

[0114] マトリックス乗算のための複雑性を減少させるために、取得されたＮ個の固有ベクトルがＫＬＴ変換を実施するために使用されることができ、残りの（Ｄ−Ｎ）の変換係数はゼロのままにされる。これは、パフォーマンスを減弱させない可能性がある、なぜなら、第１のＮ個の投影（projections）は信号エネルギの大部分をカバーすることができ、一方で基底（base）はコーディングブロックと高度に相関しているサンプルから訓練（train）されることができるからである。

[0115] 説明されたＫＬＴは、ＪＥＭ内のコーディングブロックに対してブロックレベルにおいてインプリメントされる。イメージ／ビデオコンテンツに対する高い適応性を有するために、提案されたスキームは、４ｘ４、８ｘ８、１６ｘ１６および３２ｘ３２のコーディングブロックにおける提案されたＫＬＴをサポートする。ＪＥＭのエンコーダサイドにおいて、ＳＤＴおよびアドバンストマルチプル変換（ＡＭＴ：advanced multiple transform）のうちの最良の変換モードを決定するためにレートひずみ最適化が利用される。説明されたＫＬＴ方法は、ＪＥＭに含められるが、極端に高い複雑性に起因して、この方法は、デフォルトでは無効にされている。

[0116] 変換をシグナリングするための既存の技法には、いくつか問題が見られ得る。１つの例として、インターコード化ブロックに対して適用される上記の説明されたＡＭＴ方法、すなわち「インターＡＭＴ」について、３ビットまでのオーバヘッドがいずれの変換が実際に適用されるかを示すために、ブロックごとにシグナリングされる必要があり、それはインターコーディングにとっては非常にコストの大きな（expensive）ものである。オーバヘッドビットが変換選択について同様の効率で節約される場合、全体的なコーディングパフォーマンスは改善され得る。上で説明されたＳＤＴについての潜在的な問題の別の例としては、インプリメンテーションのために必要とされる符号器の複雑性が、同様のイメージパッチに対する大規模なデコーダ探索とＫＬＴマトリックスを導出するための大規模な計算の両方が必要であることに起因して高すぎることであり得る。同様のイメージパッチを使用したオンライン更新変換関数の概念が利用される場合であってしかしそれがより低い複雑性においてである場合、この技法は、既存のハードウェアを用いてインプリメントするためにより実用的であり得る。潜在的な問題の別の例として、現在のピクチャ中のあるイメージブロックと、現在利用されていない、時間的距離の観点から現在のピクチャに近い別のピクチャにおける別のブロックとの間に時間的な統計上の相関が存在する。この時間的な統計上の相関は、コーディング効率のさらなる改善のために変換を選択または導出するために利用され得る。本開示は、上述した様々な問題に対処し得る技法を紹介する。上で述べた問題を潜在的に解決するため、本開示は以下の技法を提案する。説明される技法のうちのいくつかはまた、イントラコード化およびインターコード化ブロックの両方に適用され得る。

[0117] 以下の技法は、独立して、または任意の組合せにおいて、ビデオエンコーダ２０およびビデオデコーダ３０によって適用され得る。ビデオエンコーダ２０およびビデオデコーダ３０は、例えば、現在のピクチャの現在ブロックの予測ブロックの特性を決定する、および特性に基づいて、現在ブロックを復号するための変換を識別するように構成され得る。以下により詳細に説明されることになるように、予測ブロックの特性は、例えば、現在ブロックの隣接している再構成されたサンプル（neighboring reconstructed samples）の値、予測ブロックにおけるエッジの存在（a presence of an edge）、予測ブロックにおける分散の量（an amount of variance）、予測ブロックにおけるエッジ方向（edge direction）、予測ブロックのコーディングモード、予測ブロックについての適応ループフィルタ分類（adaptive loop filter classification）、または予測ブロックの何らかの他のそのような特性であり得る。以下により詳細に説明されるように、ビデオエンコーダ２０およびビデオデコーダ３０は、ビデオデータの現在ブロックのための１つまたは複数の変換を決定するために、様々な方法でこれらの特性を使用することができる。

[0118] １つの例示的な技法に従って、現在ブロックと何らかの類似性を有する１つのまたはいくつかのイメージ／ビデオ（再構成されたかまたは残差のいずれかの）ブロック（パッチ）が、ビデオエンコーダ２０およびビデオデコーダ３０の両方によって探索および位置特定（locate）される。位置特定されたブロックは、事前に定義されたＫＬＴのセット、または異なるタイプのＤＣＴ／ＤＳＴ変換等の、事前に定義された変換候補のグループからの１つのまたは複数の変換候補（変換サブセット）を識別するために使用される。識別された１つの変換が、現在残差ブロックに対する変換として適用される、または複数の識別された変換のうちの１つが、現在残差ブロックに対する変換として適用される。以下により詳細に説明されるように、ビデオエンコーダ２０は、残差サンプルのブロックを変換係数へ変換するために選択された変換を使用し得る。ビデオエンコーダ２０によって適用される変換は、時にフォワード変換と呼ばれ得る。ビデオデコーダ３０は、変換係数を残差サンプルのブロックへと逆変換するために、選択された変換を使用し得る。

[0119] １つのまたはいくつかのイメージ／ビデオブロックは、現在のピクチャの復号された領域からのものであり得るか、または参照ピクチャからのものであり得る。１つのまたはいくつかのイメージ／ビデオブロックは、それらの隣接している再構成されたピクセルと現在ブロックの隣接している再構成されたピクセルとを比較（compare）すること、すなわちテンプレートマッチング処理、によって導出され得る。

[0120] 図７は、ビデオデコーダ３０（またはビデオエンコーダ２０）によって実施され得るテンプレートマッチング処理の例を示す。ビデオデコーダ３０は、現在のピクチャ１００をコーディングしており、より具体的には、現在ブロック１０２をコーディングしている。現在ブロック１０２の残差ブロックについての変換を決定するために、ビデオデコーダ３０は、現在ブロック１０２の隣接している再構成されたサンプル１０４を、ピクチャ１００における他の再構成されたサンプルと比較する。ビデオデコーダ３０は、再構成された隣接しているサンプル１０４に最も近く、または充分に近く、マッチする他の再構成されたサンプルのグループを見つける。図７の例では、再構成されたサンプル１０６は、再構成された隣接しているサンプル１０４にマッチする再構成されたサンプルである。再構成されたサンプル１０６のロケーションに基づいて、ビデオデコーダ３０は、ブロック１０８を位置特定する。以下に説明される様々な技法のうちの１つを使用して、ビデオデコーダ３０は、ブロック１０２についての変換を決定するために、ブロック１０８を使用する。図７は、再構成された隣接しているサンプル１０６およびブロック１０８を隣接している再構成されたサンプル１０４および現在ブロック１０２と同じピクチャ中にあるものとして示しているが、再構成された隣接しているサンプル１０６およびブロック１０８は、いくつかの例では、ピクチャ１００とは異なる参照ピクチャにあり得ることに留意されたい。

[0121] １つのまたはいくつかのイメージ／ビデオブロックは、現在ブロックの予測ブロック（１つまたは複数）であり得る。したがって、「同様の（similar）」ブロックを探索する代わりに、この例では、ビデオコーダは、１つのまたは複数の変換候補を識別するために、現在ブロックの予測ブロックを直接的に使用し得る。別の例では、現在ブロックの予測ブロックの予測ブロック、すなわち、現在ブロックがそこから予測されるブロックはまた、変換アイデンティフィケーションのために使用される同様のイメージ／ビデオブロックのうちの１つであり得る。識別された変換は、分離可能な変換、すなわち左（列）または右（行）変換の両方を含むものか、または分離不可能な変換（例えば、ＮＳＳＴからの変換候補）か、のいずれかであることができる。

[0122] ビデオエンコーダ２０および／またはビデオデコーダ３０は、初めに１つのまたはいくつかのイメージ／ビデオブロックに対して所与の変換サブセットからの各利用可能な変換候補を実施することによって変換を識別することができ、所与の基準の下で最良の効率を有する変換が、現在ブロックに適用されるために識別される変換であり得る。変換効率の基準は、位置特定されたイメージ／ビデオまたは残余ブロックに変換候補を適用した後の絶対値変換係数値和（ＳＡＴＣ：Sum of absolute transformed coefficients value）であることができる。より小さいＳＡＴＣは、より高い変換効率を意味する。別の例では、変換効率の基準は、上述したような、またhttp://web.stanford.edu/class/ee398a/handouts/lectures/07-TransformCoding.pdfに説明されているような変換コーディング利得であることができる。別の例では、変換効率の基準は、いくつかの選択された変換係数、例えば左上１、２ｘ２または４ｘ４の低周波数係数または係数走査順序における最初の／最後のＮ個の係数、の絶対値の合計であることができ、ここでＮは、ブロックサイズに依存し得る事前に定義された値であることができる。

[0123] ビデオエンコーダ２０および／またはビデオデコーダ３０は、所与の基準を使用して１つのまたはいくつかのイメージ／ビデオ（または残差または予測）ブロックを分析することによって変換を識別することができ、その基準に従って、１つの変換または複数の変換（変換サブセット）が識別される。一例では、基準は、１つのまたはいくつかのイメージ／ビデオ（または残差、または予測）ブロックに対して実施される分析処理に依存し得る。分析処理の例は、予測ブロックのために使用されるコーディングモード、分散の量、（例えば、Ｓｏｂｅｌ演算子（Sobel operator）を使用した）エッジ検出を含むが、それらに限定されるわけではない。分析処理の出力に従って、１つのまたは複数の変換候補（変換サブセット）が識別され、識別された１つの変換、または複数の識別された変換のうちの１つが、現在残差ブロックに対する変換として使用される。

[0124] 別の例では、基準は、１つのまたは複数の変換候補（変換サブセット）を識別するために直接的に使用されることができるいくつか利用可能な分類情報であり得る。利用可能な分類情報は、予測ブロックの位置において位置特定されたイメージ／ビデオブロックに対して適用されたＡＬＦ（適応型ループフィルタ（Adaptive Loop Filter））分類情報を含み得るが、それに限定されるわけではない。このケースでは、分類情報と変換との間の関係は、事前に定義され得る。例えば、１つの変換または変換のサブセットは、量子化されたラプラシアンアクティビティ値（Laplacian activity values）および／または方向情報（いくつかの方向に沿った勾配）に基づいて選択され得る。

[0125] 別の例では、１つの変換候補のみを識別する代わりに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、１つのまたはいくつかのイメージ／ビデオブロックを使用して変換サブセットを識別し得、識別された変換サブセットは、変換候補の事前に定義されたセット／グループからの１つより多くの変換候補を含み得る。このケースでは、インデックスは、識別された変換サブセットのうちのいずれの変換候補が現在ブロックのために実際に使用されるのかを示し、インデックスは、復号された情報を使用して、明示的にシグナリングされ得るまたは黙示的に導出され得る。

[0126] 別の例示的な技法によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、変換の事前に定義されたセット／グループからの１つのまたは複数の変換（または変換サブセット）を識別するために、現在ブロックのいくつかのコード化された情報を使用し得る。そのようなコード化された情報は、例えば、ブロックサイズ、ブロック幅および／または高さ、ブロックエリアサイズ、ブロック幅対高さの比、変換係数、動き情報、アフィン（Affine）モード情報、ＩＣ（イルミネーション補償（Illumination Compensation））モード情報等を含み得るが、それらに限定されるわけではない。

[0127] 一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、変換の事前に定義されたセット／グループからの１つのまたは複数の変換（または変換サブセット）を識別するために、シグナリングされた変換係数を使用し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、例えば、変換係数に基づいて、所与の変換サブセットから選択された変換候補のインデックスを識別することができ得る。変換インデックスは、しかしながら、明示的にシグナリングされない可能性があるが、代わりにシグナリングされた変換係数に隠され得る。一例では、選択された変換候補は、非ゼロの変換のうちのいくつかまたはすべてのパリティをチェックすることによって識別され得る。別の例では、選択された変換候補は、非ゼロ係数が、変換係数ブロックのある特定のロケーション（高周波数、低周波数）において発生するかどうかのような、変換係数の分配をチェックすることによって識別され得る。

[0128] 一例では、動き情報は、変換の事前に定義されたセット／グループからの１つのまたは複数の変換（または変換サブセット）を識別するために使用されることができる。ビデオエンコーダ２０および／またはビデオデコーダ３０は、動き情報に基づいて、変換の事前に定義されたセット／グループからの１つのまたは複数の変換（または変換サブセット）を識別することができ得る。一例では、選択された変換（１つまたは複数）は、異なる変換が異なる大きさ範囲（different magnitude ranges）に適用されるような、動きベクトル（１つまたは複数）の大きさ（magnitude）に基づいて、識別される。別の例では、選択された変換（１つまたは複数）は、単予測または双予測（uni-prediction or bi-prediction）に基づいて、識別される。別の例では、選択された変換（１つまたは複数）は、動きベクトル（１つまたは複数）によって指し示される方向（１つまたは複数）に基づいて、識別される。別の例では、選択された変換（１つまたは複数）は、動きベクトル（１つまたは複数）のタイプ（並進またはアフィン運動）に基づいて、識別される。

[0129] 別の例示的な技法によれば、ビデオデコーダ３０は、変換の事前に定義されたセット／グループからの１つのまたは複数の変換（または変換サブセット）を識別し得、次いでビデオデコーダ３０は、識別された１つのまたは複数の変換（または変換サブセット）が、実際にブロックのために使用される選択された１つのまたは複数の変換（または変換サブセット）であるかどうかを示すフラグまたはインデックスを受信し得る。フラグ／インデックスは、ビットストリームに含まれ得、フラグ／インデックスは、既にコード化された情報によって導出されたコンテキストモデル化を使用してエントロピーコード化され得る。

[0130] １つのまたは複数の変換（または変換サブセット）は、例えば、既に復号された変換係数ブロックを有する利用可能な変換候補の各々を使用して現在ブロックを再構成することによって識別され得る。各再構成されたブロックと、隣接している再構成されたブロックとの間の不連続性が測定されることができ、１つのまたは複数の変換（または変換サブセット）が、それらの再構成されたブロックと、隣接している再構成されたブロックとの間の最小限の不連続性を示す１つのまたは複数の変換を選択することによって識別され得る。

[0131] 別の例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、復号された変換係数ブロックを有する各利用可能な変換候補を使用して現在ブロックを再構成することによって１つのまたは複数の変換（または変換サブセット）を識別し得、各再構成されたブロックのトップおよび／または左境界の１つの（またはいくつかの）ラインと予測ブロックのそれらのとの間の差が計算される。１つのまたは複数の変換（または変換サブセット）は、最小限の差を示す１つのまたは複数の変換を選択することによって識別される。この技法は、イントラ予測されたブロックに適用され得るか、または、ある特定のイントラモードを使用して、例えば、方向性イントラ予測モードを用いて、ブロックに適用され得る。いくつかのインプリメンテーションでは、ライン（１つまたは複数）のトップまたは左の境界のみがイントラ予測モードの方向に基づいて使用される。

[0132] フラグ／インデックスをエントロピーコーディングするためのコンテキストモデル化は、変換係数ブロックのレベル（変換係数の大きさ）に依存し得、レベル値は、選択された変換係数からのレベル値の合計、またはすべての変換係数からのレベル値の合計、またはすべての変換係数からの二乗レベル（squared level）値の合計、１つからのものであり得る。別の例では、フラグ／インデックスをエントロピーコーディングするためのコンテキストモデル化は、変換係数ブロックの最後の位置に依存し得る。

[0133] 上で提案された技法は、ある特定の条件下で適用され得る。例えば、ある特定の技法は、ある特定の時間的なレベルについて引き起こされ得る。別の例では、ある特定の技法は、コーディングモードおよび／またはブロックサイズについて引き起こされる。

[0134] 図８は、本開示で説明される技法をインプリメントし得る例示的なビデオエンコーダ２０を例示するブロック図である。ビデオエンコーダ２０は、ビデオスライス内でビデオブロックのイントラおよびインターコーディングを実施し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオ中の空間的冗長性を減少させるまたは削除するために空間的予測に頼る。インターコーディングは、ビデオシーケンスの隣接したフレームまたはピクチャ内のビデオ中の時間的冗長性を減少させるまたは削除するために時間的予測に頼る。イントラ−モード（Ｉモード）は、いくつかの空間ベースの圧縮モードのうちの任意のものを指し得る。一方向予測（Ｐモード）または双予測（Ｂモード）のようなインターモードは、いくつかの時間ベースの圧縮モードのうちの任意のものを指し得る。

[0135] 図８の例では、ビデオエンコーダ２０は、ビデオデータメモリ３３、区分ユニット（partitioning unit）３５、予測処理ユニット（prediction processing unit）４１、加算器５０、変換処理ユニット（transform processing unit）５２、量子化ユニット（quantization unit）５４、エントロピー符号化ユニット（entropy encoding unit）５６を含む。予測処理ユニット４１は、動き推定ユニット（ＭＥＵ：motion estimation unit）４２、動き補償ユニット（ＭＣＵ：motion compensation unit）４４、およびイントラ予測ユニット４６を含む。ビデオブロック復元については、ビデオエンコーダ２０はまた、逆量子化ユニット（inverse quantization unit）５８、逆変換処理ユニット（inverse transform processing unit）６０、加算器６２、フィルタユニット６４、および復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）６６を含む。

[0136] 図８に示されるように、ビデオエンコーダ２０は、ビデオデータを受信し、受信されたビデオデータをビデオデータメモリ３３に記憶する。ビデオデータメモリ３３は、ビデオエンコーダ２０のコンポーネントによって符号化されることになるビデオデータを記憶し得る。ビデオデータメモリ３３中に記憶されたビデオデータは、例えばビデオソース１８から取得され得る。ＤＰＢ６６は、例えば、イントラまたはインターコーディングモードにおけるビデオエンコーダ２０によるビデオデータの符号化で使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ３３およびＤＰＢ６６は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスを含む動的ランダムアクセスメモリ（ＤＲＡＭ）のような多様なメモリデバイスのいずれによっても形成され得る。ビデオデータメモリ３３およびＤＰＢ６６は、同じメモリデバイスまたは別々のメモリデバイスによって提供され得る。様々な例において、ビデオデータメモリ３３は、ビデオエンコーダ２０の他のコンポーネントと共にオンチップであり得るか、またはそれらのコンポーネントに対してオフチップであり得る。

[0137] 区分ユニット３５は、ビデオデータメモリ３３からビデオデータを取り出し、ビデオデータをビデオブロックに区分する。この区分することはまた、例えば、ＣＵおよびＬＣＵの四分木構造に従って、スライス、タイル、または他のより大きなユニットへと区分すること、ならびにビデオブロック区分を含み得る。ビデオエンコーダ２０は一般に、符号化されることになるビデオスライス内のビデオブロックを符号化するコンポーネントを例示する。スライスは、複数のビデオブロックに（および場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。予測処理ユニット４１は、（コーディングレートおよびひずみのレベル等）のエラー結果に基づいて、現在ビデオブロックについて、複数のイントラコーディングモードのうちの１つまたは複数のインターコーディングモードのうちの１つのような複数の可能性のあるコーディングモードのうちの１つを選択し得る。予測処理ユニット４１は、結果的なイントラまたはインターコード化ブロックを、残差ブロックデータを生成するために加算器５０に提供し、および参照ピクチャとして使用するための符号化されたブロックを再構成するために加算器６２に提供し得る。

[0138] 予測処理ユニット４１内のイントラ予測ユニット４６は、空間圧縮を提供するためにコード化されることになる現在ブロックと同じフレームまたはスライス中の１つまたは複数の隣接しているブロックに対する現在ビデオブロックのイントラ予測コーディングを実施し得る。予測処理ユニット４１内の動き推定ユニット４２および動き補償ユニット４４は、時間的圧縮を提供するために、１つまたは複数の参照ピクチャ中の１つまたは複数の予測ブロックに対する現在ビデオブロックのインター予測コーディングを実施する。

[0139] 動き推定ユニット４２は、ビデオシーケンスについての事前決定されたパターンに従って、ビデオスライスについてのインター予測モードを決定するように構成され得る。事前決定されたパターンは、シーケンス中のビデオスライスを、ＰスライスまたはＢスライスとして指定し得る。動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別々に例示されている。動き推定ユニット４２によって実施される動き推定は、動きベクトルを生成する処理であり、それはビデオブロックについての動きを推定する。動きベクトルは、例えば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵのずれを示し得る。

[0140] 予測ブロックは、ピクセル差分の観点からコード化されることになるビデオブロックのＰＵに近くマッチすることが分かるブロックであり、それは差分絶対値和（ＳＡＤ：sum of absolute difference）、差分二乗和（ＳＳＤ：sum of square difference）、または他の差の測定基準によって決定され得る。いくつかの例では、ビデオエンコーダ２０は、ＤＰＢ６６中に記憶された参照ピクチャのサブ整数ピクセル位置についての値を計算し得る。例えば、ビデオエンコーダ２０は、参照ピクチャの４分の１ピクセル位置、８分の１ピクセル位置、または他の分数ピクセル位置の値を補間し得る。ゆえに、動き推定ユニット４２は、全ピクセル位置および分数ピクセル位置に対する動き探索を実施し、分数ピクセル精度で動きベクトルを出力し得る。

[0141] 動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによってインターコード化されたスライス中のビデオブロックのＰＵについての動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得、それらの各々は、ＤＰＢ６６中に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６および動き補償ユニット４４に送る。

[0142] 動き補償ユニット４４によって実施される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチングまたは生成することに関わり得、場合によってはサブピクセル精度に対する補間を実施する。現在ビデオブロックのＰＵについての動きベクトルを受信する際、動き補償ユニット４４は、動きベクトルポイントが指し示す予測ブロックを参照ピクチャリストのうちの１つに位置特定し得る。ビデオエンコーダ２０は、コード化されている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロックを形成し、ピクセル差分値を形成する。ピクセル差分値は、ブロックのための残差データを形成し、ルーマおよびクロマ差成分の両方を含み得る。加算器５０は、この減算演算（subtraction operation）を実施する１つまたは複数のコンポーネントを表す。動き補償ユニット４４はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０によって使用されるためのビデオスライスおよびビデオブロックに関連するシンタックス要素を生成し得る。

[0143] 予測処理ユニット４１が現在ビデオブロックについての予測ブロックを生成した後、イントラ予測またはインター予測のいずれかによって、ビデオエンコーダ２０は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、１つまたは複数のＴＵに含まれ、変換処理ユニット５２に適用され得る。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換のような変換を使用して残差ビデオデータを残差変換係数へと変換する。変換処理ユニット５２は、ピクセル領域からの残差ビデオデータを、周波数領域のような変換領域に変換し得る。

[0144] 変換処理ユニット５２は、結果として生じる変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレート（bit rate）をさらに減少させるために、変換係数を量子化する。量子化処理は、係数のうちのいくつかまたはすべてに関連するビット深度（bit depth）を減少させ得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４は次いで、量子化された変換係数を含むマトリックスの走査を実施し得る。別の例では、エントロピー符号化ユニット５６が走査を実施し得る。

[0145] 量子化に続いて、エントロピー符号化ユニット５６は、量子化された変換係数をエントロピー符号化する。例えば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context adaptive binary arithmetic coding）、シンタックスベースのコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率区間区分エントロピー（ＰＩＰＥ：probability interval partitioning entropy）コーディングまたは別のエントロピー符号化方法もしくは技法を実施し得る。エントロピー符号化ユニット５６によるエントロピー符号化に続いて、符号化されたビットストリームは、ビデオデコーダ３０に送信され、後の送信またはビデオデコーダ３０による取り出しのためにアーカイブされ得る。エントロピー符号化ユニット５６はまた、コード化されている現在のビデオスライスについての動きベクトルおよび他のシンタックス要素をエントロピー符号化し得る。

[0146] 逆量子化ユニット５８および逆変換処理ユニット６０は、参照ピクチャの参照ブロックとして後に使用するためにピクセル領域中の残差ブロックを再構成するために、逆量子化および逆変換をそれぞれ適用する。動き補償ユニット４４は、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つの予測ブロックに残差ブロックを追加することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、動き推定で使用するためのサブ整数ピクセル値（sub-integer pixel value）を計算するために再構成された残差ブロックに１つまたは複数の補間フィルタ（interpolation filter）を適用し得る。加算器６２は、再構成されたブロックを生み出すために、動き補償ユニット４４によって生み出された動き補償された予測ブロックに再構成された残差ブロックを追加する。

[0147] フィルタユニット６４は、再構成されたブロック（例えば、加算器６２の出力）をフィルタし、参照ブロックとして使用するためにＤＰＢ６６にフィルタされた再構成されたブロックを記憶する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するための参照ブロックとして動き推定ユニット４２および動き補償ユニット４４によって使用され得る。フィルタユニット６４は、例えば、デブロッキングフィルタ（deblocking filter）、適応型ループフィルタ（ＡＬＦ：adaptive loop filter）、サンプル適応型オフセット（ＳＡＯ：sample adaptive offset）フィルタ、または他のタイプのフィルタのうちの１つまたは複数を使用して再構成されたビデオブロックをフィルタする。他のループフィルタ（コーディングループ中またはコーディングループ後のいずれかの）はまた、ピクセル遷移を平滑化するまたはもしそうでなければビデオ品質を改善するために使用され得る。

[0148] 図９は、本開示で説明される技法をインプリメントし得る例示的なビデオデコーダ３０を例示するブロック図である。図９のビデオデコーダ３０は、例えば、図８のビデオエンコーダ２０に関して上述したシグナリングを受信するように構成され得る。図９の例では、ビデオデコーダ３０は、ビデオデータメモリ７８、エントロピー復号ユニット（entropy decoding unit）８０、予測処理ユニット８１、逆量子化ユニット８６、逆変換処理ユニット８８、加算器９０、フィルタユニット９２、およびＤＰＢ９４を含む。予測処理ユニット８１は、動き補償ユニット８２およびイントラ予測ユニット８４を含む。ビデオデコーダ３０は、いくつかの例では、図８からのビデオエンコーダ２０に関して説明された符号化パス（encoding pass）と、概して逆の関係の復号パス（decoding pass）を実施し得る。

[0149] 復号処理の間に、ビデオデコーダ３０は、ビデオエンコーダ２０からの符号化されたビデオスライスおよび関連したシンタックス要素のビデオブロックを表す符号化されたビデオビットストリーム（encoded video bitstream）を受信する。ビデオデコーダ３０は、受信された符号化されたビデオビットストリームをビデオデータメモリ７８に記憶する。ビデオデータメモリ７８は、ビデオデコーダ３０のコンポーネントによって復号されることとなる符号化されたビデオビットストリームのようなビデオデータを記憶し得る。ビデオデータメモリ７８中に記憶されたビデオデータは、物理データ記憶媒体にアクセスすることによって、またはカメラのようなローカルビデオソースから、または記憶デバイス２６から、リンク１６を介する等して、取得され得る。ビデオデータメモリ７８は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶するコード化されたピクチャバッファ（ＣＰＢ：coded picture buffer）を形成し得る。ＤＰＢ９４は、例えば、イントラまたはインターコーディングモードにおいて、ビデオデコーダ３０によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ７８およびＤＰＢ９４は、ＤＲＡＭ、ＳＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、または他のタイプのメモリデバイスのような多様なメモリデバイスのうちのいずれによっても形成され得る。ビデオデータメモリ７８およびＤＰＢ９４は、同じメモリデバイスまたは別々のメモリデバイスによって提供され得る。様々な例において、ビデオデータメモリ７８は、ビデオデコーダ３０の他のコンポーネントと共にオンチップであり得るか、またはそれらのコンポーネントに対してオフチップであり得る。

[0150] ビデオデコーダ３０のエントロピー復号ユニット８０は、量子化された係数、動きベクトル、および他のシンタックス要素を生成するために、ビデオデータメモリ７８中に記憶されたビデオデータをエントロピー復号する。エントロピー復号ユニット８０は、動きベクトルおよび他のシンタックス要素を予測処理ユニット８１に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルにおいてシンタックス要素を受信し得る。

[0151] ビデオスライスがイントラコード化（Ｉ）スライスとしてコード化されるとき、予測処理ユニット８１のイントラ予測ユニット８４は、現在のフレームまたはピクチャの前に復号されたブロックからのデータおよびシグナリングされたイントラ予測モードに基づいて、現在のビデオスライスのビデオブロックについての予測データを生成し得る。ビデオフレームがインターコード化されたスライス（例えば、ＢスライスまたはＰスライス）としてコード化されるとき、予測処理ユニット８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックについての予測ブロックを生み出す。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから生み出され得る。ビデオデコーダ３０は、ＤＰＢ９４中に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリストであるリスト０およびリスト１を組み立て得る。

[0152] 動き補償ユニット８２は、動きベクトルおよび他のシンタックス要素をパースすることによって現在のビデオスライスのビデオブロックについての予測情報を決定し、その予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生み出す。例えば、動き補償ユニット８２は、ビデオスライスのビデオブロックをコード化するために使用される予測モード（例えば、イントラまたはインター予測）、インター予測スライスタイプ（例えば、ＢスライスまたはＰスライス）、スライスについての参照ピクチャリストのうちの１つまたは複数についての構造（construction）情報、スライスの各インター符号化されたビデオブロックについての動きベクトル、スライスの各インターコード化されたビデオブロックについてのインター予測ステータス、および現在のビデオスライス中のビデオブロックを復号するための他の情報を決定するために、受信されたシンタックス要素のうちのいくつかを使用する。

[0153] 動き補償ユニット８２はまた、補間フィルタに基づいて、補間を実施し得る。動き補償ユニット８２は、参照ブロックのサブ整数ピクセルのための補間された値を計算するためにビデオブロックの符号化の間にビデオエンコーダ２０によって使用されるような補間フィルタを使用し得る。このケースでは、動き補償ユニット８２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用される補間フィルタを決定し、補間フィルタを使用して予測ブロックを生み出し得る。

[0154] 逆量子化ユニット８６は、ビットストリーム中で提供されかつエントロピー復号ユニット８０によって復号され量子化された変換係数を逆量子化する、すなわち、量子化解除する。逆量子化処理は、適用されるべき量子化の程度、同じく逆量子化の程度を決定するために、ビデオスライス中の各ビデオブロックについてビデオエンコーダ２０によって計算された量子化パラメータの使用を含み得る。逆変換処理ユニット８８は、ピクセル領域における残差ブロックを生み出すために、変換係数に対して、逆変換、例えば、逆ＤＣＴ、逆整数変換（inverse integer transform）、または概念的に同様の逆変換処理を適用する。

[0155] 予測処理ユニットが、例えばイントラまたはインター予測を使用して現在ビデオブロックについての予測ブロックを生成した後で、ビデオデコーダ３０は、逆変換処理ユニット８８からの残差ブロックを動き補償ユニット８２によって生成される対応する予測ブロックと合計することによって、再構成されたビデオブロックを形成する。加算器９０は、この加算演算（summation operation）を実施する１つまたは複数のコンポーネントを表す。

[0156] フィルタユニット９２は、例えば、デブロッキングフィルタ、ＡＬＦフィルタ、ＳＡＯフィルタ、または他のタイプのフィルタのうちの１つまたは複数を使用して再構成されたビデオブロックをフィルタする。他のループフィルタ（コーディングループ中またはコーディングループ後のいずれかの）はまた、ピクセル遷移を平滑化するまたはもしそうでなければビデオ品質を改善するために使用され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは次いで、ＤＰＢ９４に記憶され、それは、後続の動き補償のために使用される参照ピクチャを記憶する。ＤＰＢ９４は、図１のディスプレイデバイス３２のようなディスプレイデバイス上での後の提示のために復号されたビデオを記憶する追加的なメモリの一部であり得るか、またはそれとは別個のものであり得る。

[0157] 図１０は、本開示で説明される例示的なビデオ復号技法を例示するフローダイアグラムである。図１０の技法は具体的に、および本開示は一般に、いかなる特定のタイプのビデオデコーダにも限定されないが、図１０の例は、図１および図９のビデオデコーダ３０に関して説明されることとなる。図１０の例では、ビデオデコーダ３０は、現在のピクチャの現在ブロックの予測ブロックの特性を決定する（１２０）。ビデオデコーダ３０は、特性に基づいて、現在ブロックを復号するための変換を識別する（１２２）。

[0158] ビデオデコーダ３０は、例えば、第２のブロック（second block）を位置特定するために、現在のピクチャの現在ブロックの予測ブロックの特性をビデオデータ中の他のブロック（other blocks）の特性と比較し、第２のブロックに基づいて、現在ブロックを復号するための変換を識別し得る。第２のブロックは、例えば、参照ピクチャからのブロックまたは現在のピクチャの復号された部分（decoded portion）からのブロックであり得る。第２のブロックは、複数のＣＵと完全にオーバーラップし得るかまたは部分的にオーバーラップし得るかのいずれかである。現在のピクチャの現在ブロックの予測ブロックの特性をビデオデータ中の他のブロックの特性と比較するために、ビデオデコーダ３０は、現在ブロックの隣接している再構成されたサンプルを他のブロックの隣接している再構成されたサンプルと比較し得る。現在のピクチャの現在ブロックの予測ブロックの特性をビデオデータ中の他のブロックの特性と比較するために、ビデオデコーダ３０は、現在ブロックの予測ブロックを他のブロックの予測ブロックと比較し得る。

[0159] 他の例では、現在のピクチャの現在ブロックの予測ブロックの特性を決定するために、ビデオデコーダ３０は、予測ブロックにおけるエッジの存在を決定し得、ここにおいて、特性に基づいて、現在ブロックを復号するための変換を識別することは、エッジの存在に関連する変換を決定することを備える。現在のピクチャの現在ブロックの予測ブロックの特性を決定するために、ビデオデコーダ３０は、予測ブロックにおける分散の量を決定し得、ここにおいて、特性に基づいて、現在ブロックを復号するための変換を識別することは、分散の量に関連する変換を決定することを備える。現在のピクチャの現在ブロックの予測ブロックの特性を決定するために、予測ブロックにおけるエッジ方向を決定することを備え、特性に基づいて、現在ブロックを復号するための変換を識別するために、ビデオデコーダ３０は、エッジ方向に関連する変換を決定し得る。現在のピクチャの現在ブロックの予測ブロックの特性を決定するために、ビデオデコーダ３０は、予測ブロックのコーディングモードを決定し得、特性に基づいて、現在ブロックを復号するための変換を識別するために、ビデオデコーダ３０は、コーディングモードに関連する変換を決定し得る。現在のピクチャの現在ブロックの予測ブロックの特性を決定するために、ビデオデコーダ３０は、予測ブロックについての適応ループフィルタ分類を決定し得、特性に基づいて、現在ブロックを復号するための変換を識別するために、ビデオデコーダ３０は、適応ループフィルタ分類に関連する変換を決定し得る。

[0160] 一例では、特性に基づいて、現在ブロックを復号するための変換を識別するために、ビデオデコーダ３０は、追加的なシグナリングを受信することなく、特性に基づいて直接的に変換を識別し得る。他の例では、特性に基づいて、現在ブロックを復号するための変換を識別するために、ビデオデコーダ３０は、特性に基づいて、利用可能な変換のサブセット（a subset of available transforms）を識別し、サブセットからの変換を、現在ブロックを復号するための変換として識別するインデックス値（index value）を受信し得る。変換を識別した後に、ビデオデコーダ３０は、現在ブロックについての残差ブロックを決定するために、変換係数のセットを逆変換する（１２４）。ビデオデコーダ３０は、現在ブロックを復号するために、残差ブロックを現在ブロックの予測ブロックに追加する（１２６）。

[0161] １つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいてインプリメントされ得る。ソフトウェアにおいてインプリメントされる場合、これら機能は、１つまたは複数の命令またはコードとして、コンピュータ読み取り可能な媒体上で記憶または送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な記憶媒体を含み得、それは、データ記憶媒体のような有形の媒体、または、例えば通信プロトコルに従って１つの場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体に対応する。このように、コンピュータ読み取り可能な媒体は一般に、（１）非一時的である有形のコンピュータ読み取り可能な記憶媒体、または（２）信号（signal）または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示に説明された技法のインプリメンテーションのための命令、コードおよび／またはデータ構造をリトリーブ（retrieve）するために１つまたは複数のコンピュータまたは１つまたは複数のプロセッサによってアクセスされることができる、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ読み取り可能な媒体を含み得る。

[0162] 限定ではなく例として、そのようなコンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用されることができ、かつコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、いかなる接続も、コンピュータ読み取り可能な媒体と適切に称される。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ読み取り可能な記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに、非一時的な、有形の記憶媒体を対象とすることは、理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多目的ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙディスク（disc）を含み、ここで、ディスク（disks）は、通常磁気的にデータを再生し、一方ディスク（discs）は、レーザーを用いて光学的にデータを再生する。上記の組合せもまた、コンピュータ読み取り可能な媒体の範囲内に含まれるべきである。

[0163] 命令は、１つまたは複数のＤＳＰ、汎用マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、または他の同等の統合またはディスクリート論理回路構成のような１つまたは複数のプロセッサによって実行され得る。したがって、「プロセッサ」という用語は、ここで使用される場合、前述の構造のうちの任意のもの、またはここに説明された技法のインプリメンテーションのために適した任意の他の構造を指し得る。加えて、いくつかの態様では、ここに説明された機能性は、組み合わせられたコーデック内に組み込まれるか、または符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に提供され得る。また、これら技法は、１つまたは複数の回路または論理素子において完全にインプリメントされる可能性がある。

[0164] 本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、多種多様なデバイスまたは装置においてインプリメントされ得る。開示された技法を実施するように構成されるデバイスの機能的態様を強調するために、様々なコンポーネント、モジュール、またはユニットが、本開示において説明されているが、必ずしも、複数の異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上述したように、様々なユニットは、好適なソフトウェアおよび／またはファームウェアと併せて、上述したような１つまたは複数のプロセッサを含む相互動作可能な複数のハードウェアユニットのコレクションによって提供され得るか、コーデックハードウェアユニットにおいて組み合わせられ得る。

[0165] 様々な例が説明された。これらのおよび他の例は、以下の特許請求の範囲の適用範囲内にある。

Claims (30)

1. ビデオデータを復号するための方法であって、
   現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、
   前記特性に基づいて、前記現在ブロックを復号するための変換を識別することと、
   前記現在ブロックについての残差ブロックを決定するために、変換係数を逆変換することと、
   前記現在ブロックを復号するために、前記残差ブロックを前記現在ブロックの予測ブロックに追加することと、
   を備える、方法。
2. 第２のブロックを位置特定するために、前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の他のブロックの特性と比較することと、
   前記第２のブロックに基づいて、前記現在ブロックを復号するための前記変換を識別することと、
   をさらに備える、請求項１に記載の方法。
3. 前記第２のブロックが参照ピクチャからのブロックを備える、請求項２に記載の方法。
4. 前記第２のブロックが前記現在のピクチャの復号された部分からのブロックを備える、請求項２に記載の方法。
5. 前記第２のブロックが複数のコーディングユニットとオーバーラップする、請求項２に記載の方法。
6. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の前記他のブロックの特性と比較することが、前記現在ブロックの隣接している再構成されたサンプルを前記他のブロックの隣接している再構成されたサンプルと比較することを備える、請求項２に記載の方法。
7. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の前記他のブロックの特性と比較することが、前記現在ブロックの予測ブロックを前記他のブロックの予測ブロックと比較することを備える、請求項２に記載の方法。
8. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定することが、前記予測ブロックにおけるエッジの存在を決定することを備え、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、前記エッジの前記存在に関連する変換を決定することを備える、請求項１に記載の方法。
9. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定することが、前記予測ブロックにおける分散の量を決定することを備え、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、分散の前記量に関連する変換を決定することを備える、請求項１に記載の方法。
10. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定することが、前記予測ブロックにおけるエッジ方向を決定することを備え、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、前記エッジ方向に関連する変換を決定することを備える、請求項１に記載の方法。
11. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定することが、前記予測ブロックのコーディングモードを決定することを備え、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、前記コーディングモードに関連する変換を決定することを備える、請求項１に記載の方法。
12. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定することが、前記予測ブロックについての適応ループフィルタ分類を決定することを備え、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、前記適応ループフィルタ分類に関連する変換を決定することを備える、請求項１に記載の方法。
13. 前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別することが、
    前記特性に基づいて、利用可能な変換のサブセットを識別することと、
    インデックス値を受信することと、ここにおいて、前記インデックス値が、前記サブセットからの変換を、前記現在ブロックを復号するための前記変換として識別する、
    を備える、請求項１に記載の方法。
14. ビデオデータを復号するためのデバイスであって、
    前記ビデオデータを記憶するように構成されるメモリと、
    １つまたは複数のプロセッサと、
    を備え、
    前記１つまたは複数のプロセッサが、
    前記ビデオデータの現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、
    前記特性に基づいて、前記現在ブロックを復号するための変換を識別することと、
    前記現在ブロックについての残差ブロックを決定するために、変換係数のセットを逆変換することと、
    前記現在ブロックを復号するために、前記残差ブロックを前記現在ブロックの予測ブロックに追加することと、
    を行うように構成される、デバイス。
15. 前記１つまたは複数のプロセッサが、
    第２のブロックを位置特定するために、前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の他のブロックの特性と比較することと、
    前記第２のブロックに基づいて、前記現在ブロックを復号するための前記変換を識別することと、
    を行うようにさらに構成される、請求項１４に記載のデバイス。
16. 前記第２のブロックが参照ピクチャからのブロックを備える、請求項１５に記載のデバイス。
17. 前記第２のブロックが前記現在のピクチャの復号された部分からのブロックを備える、請求項１５に記載のデバイス。
18. 前記第２のブロックが複数のコーディングユニットとオーバーラップする、請求項１５に記載のデバイス。
19. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の前記他のブロックの特性と比較するために、前記１つまたは複数のプロセッサが、前記現在ブロックの隣接している再構成されたサンプルを前記他のブロックの隣接している再構成されたサンプルと比較するようにさらに構成される、請求項１５に記載のデバイス。
20. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を前記ビデオデータ中の前記他のブロックの特性と比較するために、前記１つまたは複数のプロセッサが、前記現在ブロックの予測ブロックを前記他のブロックの予測ブロックと比較するようにさらに構成される、請求項１５に記載のデバイス。
21. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定するために、前記１つまたは複数のプロセッサが、前記予測ブロックにおけるエッジの存在を決定するようにさらに構成され、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、前記エッジの前記存在に関連する変換を決定するようにさらに構成される、請求項１４に記載のデバイス。
22. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定するために、前記１つまたは複数のプロセッサが、前記予測ブロックにおける分散の量を決定するようにさらに構成され、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、分散の前記量に関連する変換を決定するようにさらに構成される、請求項１４に記載のデバイス。
23. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定するために、前記１つまたは複数のプロセッサが、前記予測ブロックにおけるエッジ方向を決定するようにさらに構成され、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、前記エッジ方向に関連する変換を決定するようにさらに構成される、請求項１４に記載のデバイス。
24. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定するために、前記１つまたは複数のプロセッサが、前記予測ブロックのコーディングモードを決定するようにさらに構成され、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、前記コーディングモードに関連する変換を決定するようにさらに構成される、請求項１４に記載のデバイス。
25. 前記現在のピクチャの前記現在ブロックの前記予測ブロックの前記特性を決定するために、前記１つまたは複数のプロセッサが、前記予測ブロックについての適応ループフィルタ分類を決定するようにさらに構成され、ここにおいて、前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、前記適応ループフィルタ分類に関連する変換を決定するようにさらに構成される、請求項１４に記載のデバイス。
26. 前記特性に基づいて、前記現在ブロックを復号するための前記変換を識別するために、前記１つまたは複数のプロセッサが、
    前記特性に基づいて、利用可能な変換のサブセットを識別することと、
    インデックス値を受信することと、ここにおいて、前記インデックス値が、前記サブセットからの変換を、前記現在ブロックを復号するための前記変換として識別する、
    を行うようにさらに構成される、請求項１４に記載のデバイス。
27. 前記デバイスがワイヤレス通信デバイスを備え、符号化されたビデオデータを受信するように構成される受信機をさらに備える、請求項１４に記載のデバイス。
28. 前記ワイヤレス通信デバイスが電話ハンドセットを備え、前記受信機が、ワイヤレス通信規格に従って、前記符号化されたビデオデータを備える信号を復調するように構成される、請求項２７に記載のデバイス。
29. ビデオデータを復号するための装置であって、前記装置が、
    現在のピクチャの現在ブロックの予測ブロックの特性を決定するための手段と、
    前記特性に基づいて、前記現在ブロックを復号するための変換を識別するための手段と、
    前記現在ブロックについての残差ブロックを決定するために、変換係数を逆変換するための手段と、
    前記現在ブロックを復号するために、前記残差ブロックを前記現在ブロックの予測ブロックに追加するための手段と、
    を備える、装置。
30. １つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、
    現在のピクチャの現在ブロックの予測ブロックの特性を決定することと、
    前記特性に基づいて、前記現在ブロックを復号するための変換を識別することと、
    前記現在ブロックについての残差ブロックを決定するために、変換係数のセットを逆変換することと、
    前記現在ブロックを復号するために、前記残差ブロックを前記現在ブロックの予測ブロックに追加することと、
    を行わせる命令を記憶するためのコンピュータ読み取り可能な媒体。

Images