【文献】
ROBERT A COHEN, et al.,DIRECTION-ADAPTIVE TRANSFORMS FOR CODING PREDICTION RESIDUALS,INTERNATIONAL CONFERENCE ON IMAGE PROCESSING,米国,2010年 9月26日,pp.185-188
(58)【調査した分野】(Int.Cl.,DB名)
前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、請求項2に記載の方法。
ビデオデータのブロックのためのイントラ予測モードを決定することと、前記決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形形状の変換ブロックに対応し、前記変換が、NxN変換、hNx2N変換、および2NxhN変換からなる一群から選択され、Nが変換の寸法のサイズを表し、hNがNの値の半分を表し、2NがNの前記値の2倍を表し、前記最も可能性の高い変換が、前記hNx2N変換または前記2NxhN変換のうちの1つに対応する、識別することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示を復号することであって、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示を復号することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示す1つのフラグを受信することを備える、復号することと、前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記1つのフラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換以外の変換であることに応答して、前記最も可能性の高い変換以外の変換の指示を復号することであって、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、復号することとを行うように構成されたビデオデコーダ
を備え、前記ビデオデコーダが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することとを行うように構成される、ビデオコーディングデバイス。
【発明を実施するための形態】
【0012】
ビデオコーダは、空間的および時間的冗長性を利用することによってビデオデータを圧縮する。たとえば、ビデオコーダは、同じピクチャの前にコード化された隣接するブロックに対して現在のブロックを予測することによって空間的冗長性を利用し得る。同じピクチャの前にコード化された隣接するブロックに対して現在のブロックを予測することは、イントラ予測またはイントラモードと呼ばれることがある。同様に、ビデオコーダは、前にコード化されたピクチャのデータに対して現在のブロックを予測することによって時間的冗長性を利用し得る。前にコード化されたフレームのブロックに対して現在のブロックを予測することは、インター予測またはインターモードと呼ばれることがある。イントラ予測とインター予測の両方で、ビデオコーダは、すでにコード化されたブロックから現在のブロックを予測し、次いで、ブロックの実効値とブロックの予測値との間の差として、ブロックの残差データを計算する。
【0013】
以下でより詳細に説明するように、1組の残差値は、変換され、走査され、量子化されて、1組の変換係数が定義され得る。変換係数を含むデータ構造は、一般に変換ユニット(TU)と呼ばれる。符号化されたビデオデータを送信し、再構成するために、様々な形状およびサイズのTUが使用され得る。本開示は、ビデオデータの特定のブロックのために使用されるTUのサイズを、符号化されたビットストリームでシグナリングするための技法を記述する。より詳細には、本開示は、変換サイズをシグナリングすることに関連付けられたビットのオーバーヘッドを低減することができる、イントラ予測モードと変換サイズとの間の相関を利用するための技法を記述する。
【0014】
以下でより詳細に説明するように、新興のHEVC規格は、ビデオブロックのための4分木スタイルのTUパーティション構造を可能にする。4分木分解を使用すると、大きい正方形のブロックが4つの小さい正方形のブロックに分割され得る。4つの小さい正方形のブロックの各々は、さらに小さい4つのブロックに各々分割され得るなど、最も小さいブロックサイズに達するまで、分割され得る。レベル1の分解では、変換ブロック全体が、4分の1サイズの4つのブロックに分割される。レベル2で、4分の1サイズの4つの変換ブロックのうちの1つまたは複数は、1/16サイズの4つの変換ブロックにさらに分割される。レベル3で、1/16サイズの変換ブロックのうちの1つまたは複数は、4つのさらに小さい変換ブロックにさらに分割される。変換ブロックがさらに分割されることを必要とするかどうかは、たとえば、ビデオデータの符号化の一部として決定されるレートひずみ最適化計算に基づいて決定され得る。レベル0のTUは、コーディングユニット全体がさらなる分割なしで一緒に変換されることを意味する。そのような場合、TUは、コーディングユニットと同じサイズを有する。
【0015】
イントラ予測されたブロックのために非正方形の変換を使用することが提案されている。そのような場合、TUは、矩形形状を有することができる。2Nx2Nが正方形の変換を示すと仮定する。したがって、非正方形の変換は、hNx2Nおよび2NxhNと表され得、そこで、hNは、Nの値の半分を表し、2Nは、Nの値の2倍を表す。したがって、2Nx2NのTUは、4つの垂直変換(すなわち4つのhNx2N変換)または4つの水平変換(すなわち4つの2NxhN変換)に分割され得る。現在の技法の一例では、ビデオエンコーダは、まず、正方形の変換(すなわちNxN)が使用されるかどうかをビデオデコーダにシグナリングするためのフラグ(NS_Flag)を、符号化されたビットストリームでシグナリングすることができ、たとえば、0に設定されたNS_Flagは、変換NxNが選択されることをシグナリングし、1に設定されたNS_Flagは、2つの非正方形の変換(hNx2Nおよび2NxhN)のうちの1つが選択されることをシグナリングする。2つの非正方形の変換のうちの1つが選択される(すなわちNS_Flag=1)場合、追加のフラグ(NS_Dir)が送信されることを必要する場合があり、たとえば、0に設定されたNS_Dirは、変換サイズhNx2Nが選択されることを示し、1に設定されたNS_Dirは、変換サイズ2NxhNが選択されることを示す。
【0016】
上記で説明したシグナリング方法によれば、NxN変換が選択されるとき、1つのフラグが使用され、非正方形の変換hNx2Nまたは2NxhNが選択されるとき、2つのフラグが使用される。NxN変換のために最少のシグナリングビット(この例では1つのフラグ)が使用されるので、NxNが最も可能性の高い変換であるとき、このシグナリング技法は、ビットの節約をもたらし得る。しかしながら、いくつかの例では、可能性が最も高い変換は、NxN変換とは対照的に、非正方形の変換であり得る。たとえば、ビデオデータの特定のブロックについての可能性が最も高い変換が正方形の変換であるか非正方形の変換であるかは、ブロックをコード化するために使用されるイントラ予測モードに依存し得る。本開示の技法によれば、あるブロックの最も可能性の高い変換サイズが非正方形の変換であるとき、ビデオエンコーダは、最も可能性の高い変換がブロックをコード化するために使用される実際の変換であるかどうかを示すフラグを、符号化されたビットストリームでシグナリングすることができる。したがって、非正方形の変換が最も可能性の高い変換であるとき、上記で説明した2つのフラグと対照的に、非正方形の変換をシグナリングするために1つのフラグを使用することによって、ビットの節約が達成され得る。したがって、本開示の技法は、いくつかの例では、最も可能性の高い変換のために最少のシグナリングビットを使用することによって、変換シグナリング方法を向上させる。
【0017】
一例では、ビデオエンコーダは、上記で説明したように、まず、コーディングユニットのためにイントラ予測モードを選択し、次いで、変換を選択することができる。各イントラ予測モードkは、関連する最も可能性の高い変換(MPT)を有することができ、これは、たとえば、NxN、hNx2N、または2NxhNのうちの1つであり得る。ビデオエンコーダは、現在のイントラ予測モードkについて、選択された変換がMPT(k)であるかどうかをシグナリングするために、符号化されたビットストリームに含めるためのフラグ(MPT_Flag)を生成することができる。たとえば、1に設定されたMPT_Flagは、選択された変換がMPT(k)であることを意味し、一方、0に設定されたMPT_Flagは、選択された変換がMPT(k)ではないことを意味することができる。MPT_Flagが0に設定される例では、余分のフラグ(MPT_ResMode)は、他の2つの変換のうちのどちらが選択されるかをシグナリングするために送信され得る。
【0018】
一例として、現在の予測ブロックのためのイントラ予測モードがモード1であり、hNx2Nがこのイントラ予測モードに関連付けられたMPTである、すなわちhNx2N=MPT(1)と仮定する。選択されたイントラ予測モードがhNx2Nである場合、1に設定されたMPT_Flagは、変換をシグナリングするために必要な任意の他の追加のビットなしに、符号化されたビットストリームでシグナリングされ得る。選択されたイントラ予測モードがNxNである場合、0に設定されたMPT_Flagがシグナリングされ得、0に設定されたMPT_ResModeが続く。選択されたイントラ予測モードが2NxhNである場合、0に設定されたMPT_Flagがシグナリングされ得、1に設定されたMPT_ResModeが続く。
【0019】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、あらかじめ定義され、ビデオエンコーダとビデオデコーダの両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、ビデオエンコーダによって決定され、たとえばシーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、適応パラメータセット(APS)など、高レベルのシンタックスを使用して、符号化されたビットストリームでシグナリングされ得る。さらに他の例では、MPTとイントラ予測モードkとの間のマッピング、MPT(k)は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、MPT(k)は異なり得る。同様に、MPT(k)は、たとえばQP、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【0020】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードkのすべてのブロックについて、変換NxNが最も頻繁に行われる変換である場合、MPT(k)は、現在のブロックの符号化のために、NxN変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダとビデオデコーダの両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、符号化されたビットストリームにおいてマッピングが明示的にシグナリングされることなく、ビデオエンコーダとビデオデコーダとの両方で動的に調整され得る。
【0021】
図1は、本開示で説明する変換サイズをシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。
図1に示すように、システム10は、通信チャネル16を介して符号化ビデオを宛先デバイス14に送信するソースデバイス12を含む。ソースデバイス12および宛先デバイス14は、広範囲のデバイスのいずれかを備えることができる。場合によっては、ソースデバイス12および宛先デバイス14は、いわゆるセルラー電話または衛星無線電話のワイヤレスハンドセットなどのワイヤレス通信デバイス、または通信チャネル16を介してビデオ情報を通信することができ、その場合、通信チャネル16がワイヤレスである任意のワイヤレスデバイスを備え得る。
【0022】
ただし、ビデオデータのブロックについての変換サイズを表すシンタックスデータのコード化に関係する本開示の技法は、必ずしもワイヤレスアプリケーションまたは設定に限定されるとは限らない。たとえば、これらの技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、インターネットビデオ送信、記憶媒体上に符号化される符号化デジタルビデオ、または他のシナリオに適用し得る。したがって、通信チャネル16は、符号化ビデオデータの送信に好適なワイヤレスまたはワイヤード媒体の任意の組合せを備え得る。その上、通信チャネル16は、ビデオ符号化デバイスがビデオ復号デバイスにデータを送信し得る多くの方法のうちのただ1つを表すためのものである。たとえば、システム10の他の構成では、ソースデバイス12は、宛先デバイス14による復号のために符号化ビデオを生成し、必要に応じて、符号化ビデオが宛先デバイス14によってアクセスできるように、記憶媒体またはファイルサーバ上に符号化ビデオを記憶し得る。
【0023】
図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、変調器/復調器(モデム)22と、送信機24とを含む。宛先デバイス14は、受信機26と、モデム28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、ビデオデータのブロックについてのイントラ予測モードを表すシンタックスデータをコード化するための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【0024】
図1の図示のシステム10は一例にすぎない。ビデオデータのブロックについての選択された変換を表すシンタックスデータのコード化のための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオコード化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14に送信するためのコード化されたビデオデータを発生するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14の各々がビデオ符号化構成要素および復号構成要素を含むので、デバイス12、14は、実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話通信のためのビデオデバイス12とビデオデバイス14との間の一方向または双方向のビデオ送信をサポートすることができる。
【0025】
ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および/またはビデオコンテンツプロバイダからのビデオフィードを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラ付き携帯電話またはビデオ電話を形成することができる。ただし、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能であり、ワイヤレスおよび/またはワイヤードアプリケーションに適用可能であり得る。各場合において、キャプチャされたビデオ、以前にキャプチャされたビデオまたはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。次いで、符号化ビデオ情報は、通信規格に従ってモデム22によって変調され、送信機24を介して宛先デバイス14に送信され得る。モデム22は、信号変調のために設計された様々なミキサ、フィルタ、増幅器または他の構成要素を含むことができる。送信機24は、増幅器、フィルタ、および1つまたは複数のアンテナを含む、データを送信するために設計された回路を含むことができる。
【0026】
宛先デバイス14の受信機26はチャネル16を介して情報を受信し、モデム28は情報を復調する。この場合も、ビデオ符号化プロセスは、ビデオデータのブロックについてのイントラ予測モードを表すシンタックスデータをコード化するために、本明細書で説明する技法のうちの1つまたは複数を実施することができる。チャネル16を介して通信される情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、マクロブロックおよび他のコード化ユニット、たとえば、GOPの特性および/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【0027】
図1の例では、通信チャネル16は、無線周波数(RF)スペクトルあるいは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。通信チャネル16は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信チャネル16は、概して、ワイヤード媒体またはワイヤレス媒体の任意の好適な組合せを含む、ビデオデータをソースデバイス12から宛先デバイス14に送信するのに好適な任意の通信媒体、または様々な通信媒体の集合体を表す。通信チャネル16は、ソースデバイス12から宛先デバイス14への通信を可能にするのに有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【0028】
ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG−4、Part 10、Advanced Video Coding(AVC)と呼ばれるITU−T H.264規格など、ビデオ圧縮規格に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。他の例には、MPEG−2およびITU−T H.263がある。
図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびデコーダと統合され得、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、MUX−DEMUXユニットはITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
【0029】
ITU−T H.264/MPEG−4(AVC)規格は、Joint Video Team(JVT)として知られる共同パートナーシップの成果として、ISO/IEC Moving Picture Experts Group(MPEG)とともにITU−T Video Coding Experts Group(VCEG)によって策定された。いくつかの態様では、本開示で説明する技法は、一般にH.264規格に準拠するデバイスに適用することができる。H.264規格は、ITU−T研究グループによる2005年3月付けのITU−T勧告H.264「Advanced Video Coding for generic audiovisual services」に記載されており、本明細書ではH.264規格またはH.264仕様、あるいはH.264/AVC規格または仕様と呼ぶ。Joint Video Team(JVT)はH.264/MPEG−4 AVCへの拡張に取り組み続けている。
【0030】
ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合エンコーダ/デコーダ(コーデック)の一部としてそれぞれのカメラ、コンピュータ、モバイルデバイス、加入者デバイス、ブロードキャストデバイス、セットトップボックス、サーバなどに統合され得る。
【0031】
ビデオシーケンスは、一般に一連のビデオフレームを含む。ピクチャのグループ(GOP)は、概して、一連の1つまたは複数のビデオフレームを備える。GOPは、GOP中に含まれるいくつかのフレームを記述するシンタックスデータを、GOPのヘッダ中、GOPの1つまたは複数のフレームのヘッダ中、または他の場所に含み得る。各フレームは、それぞれのフレームのための符号化モードを記述するフレームシンタックスデータを含み得る。ビデオエンコーダ20は、一般に、ビデオデータを符号化するために、個々のビデオフレーム内のビデオブロックに対して動作する。ビデオブロックは、マクロブロックまたはマクロブロックのパーティションに対応し得る。ビデオブロックは、サイズを固定することも変更することもでき、指定のコーディング規格に応じてサイズが異なることがある。各ビデオフレームは複数のスライスを含み得る。各スライスは複数のマクロブロックを含み得、それらはサブブロックとも呼ばれるパーティションに配置され得る。
【0032】
一例として、ITU−T H.264規格は、ルーマ成分については16×16、8×8、または4×4、およびクロマ成分については8×8など、様々なブロックサイズのイントラ予測をサポートし、ならびにルーマ成分については16×16、16×8、8×16、8×8、8×4、4×8および4×4、ならびにクロマ成分については対応するスケーリングされたサイズなど、様々なブロックサイズのインター予測をサポートする。本開示では、「N×(x)N」と「N×(by)N」は、垂直寸法および水平寸法に関するブロックのピクセル寸法、たとえば、16×(x)16ピクセルまたは16×(by)16ピクセルを指すために互換的に使用され得る。一般に、16×16ブロックは、垂直方向に16ピクセルを有し(y=16)、水平方向に16ピクセルを有する(x=16)。同様に、N×Nブロックは、一般に、垂直方向にNピクセルを有し、水平方向にNピクセルを有し、Nは、非負整数値を表す。ブロック中のピクセルは行と列に構成され得る。さらに、ブロックは、必ずしも、水平方向に垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックは、N×Mピクセルを備え得、Mは必ずしもNに等しいとは限らない。16×16未満のブロックサイズは、ITU−T H.264では16×16のマクロブロックのパーティションと呼ばれ得る。
【0033】
ビデオブロックは、ピクセル領域中のピクセルデータのブロックを備え得、あるいは、たとえば、コード化ビデオブロックと予測ビデオブロックとのピクセル差分を表す残差ビデオブロックデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換などの変換の適用後の、変換領域中の変換係数のブロックを備え得る。場合によっては、ビデオブロックは、変換領域中の量子化変換係数のブロックを備え得る。
【0034】
小さいビデオブロックほど、より良い解像度が得られ、高い詳細レベルを含むビデオフレームのロケーションのために使用され得る。一般に、マクロブロック、およびサブブロックと呼ばれることがある様々なパーティションは、ビデオブロックと見なされ得る。さらに、スライスは、マクロブロックおよび/またはサブブロックなど、複数のビデオブロックであると見なされ得る。各スライスはビデオフレームの単独で復号可能なユニットであり得る。代替的に、フレーム自体が復号可能なユニットであり得るか、またはフレームの他の部分が復号可能なユニットとして定義され得る。
【0035】
たとえば高効率ビデオコーディング(HEVC)規格など、新しいビデオコーディング規格が開発されている。新興のHEVC規格はH.265と呼ばれることもあり得る。この規格化の取り組みは、HEVCテストモデル(HM:HEVC Test Model)と呼ばれるビデオコーディングデバイスのモデルに基づく。HMは、たとえば、ITU−T H.264/AVCによるデバイスに勝るビデオコーディングデバイスのいくつかの能力を仮定する。たとえば、H.264が9つのイントラ予測モードを提供するのに対して、HMは、たとえば、イントラ予測コード化されるブロックのサイズに基づいて、33ものイントラ予測モードを提供する。「HEVC Working Draft 8」または「WD8」と呼ばれるHEVC規格の最近のドラフトは、2012年10月3日現在、http://phenix.int-evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J1003-v8.zipからダウンロード可能である、ドキュメントJCTVC−J1003、Brossら、「High efficiency video coding (HEVC) text specification draft 8」、Joint Collaborative Team on Video Coding (JCT−VC) of ITU−T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 10th Meeting: Stockholm, SE 11−20 July 2012に記載されている。
【0036】
HMは、ビデオデータのブロックをコーディングユニット(CU)と称する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大のコーディングユニットである最大コーディングユニット(LCU:largest coding unit)を定義し得る。概して、CUは、CUがサイズの差異を有しないことを除いて、H.264のマクロブロックと同様の目的を有する。したがって、CUは、サブCUに分割され得る。概して、本開示におけるCUへの言及は、ピクチャの最大コーディングユニットまたはLCUのサブCUを指すことがある。LCUはサブCUに分割され得、各サブCUはサブCUに分割され得る。ビットストリームのシンタックスデータは、CU深さと呼ばれる、LCUが分割され得る最大回数を定義し得る。それに応じて、ビットストリームは最小コーディングユニット(SCU:smallest coding unit)をも定義し得る。本開示ではまた、CU、予測ユニット(PU:prediction unit)、またはTUのいずれかを指すために「ブロック」という用語を使用する。
【0037】
LCUは4分木データ構造に関連付けられ得る。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードはLCUに対応する。CUが4つのサブCUに分割された場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。4分木データ構造の各ノードは、対応するCUのシンタックスデータを与え得る。たとえば、4分木のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含み得る。CUのシンタックス要素は、再帰的に定義され得、CUがサブCUに分割されるかどうかに依存し得る。
【0038】
分割されないCUは、1つまたは複数の予測ユニット(PU:prediction unit)を含み得る。概して、PUは、対応するCUの全部または一部分を表し、そのPUの参照サンプルを取り出すためのデータを含む。たとえば、PUがイントラ予測モード符号化されるとき、PUは、そのPUのためのイントラ予測モードを記述するデータを含み得る。別の例として、PUがインターモード符号化されるとき、PUは、PUの動きベクトルを定義するデータを含み得る。動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度もしくは1/8ピクセル精度)、動きベクトルが指す参照フレーム、および/または動きベクトルの参照リスト(たとえば、リスト0もしくはリスト1)を記述し得る。また、(1つまたは複数の)PUを定義するCUについてのデータは、たとえば、1つまたは複数のPUへのCUの区分について記述し得る。区分モードは、CUがコーディングされないか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかとの間で異なり得る。
【0039】
1つまたは複数のPUを有するCUは、1つまたは複数のTUをも含み得る。PUを使用した予測の後に、ビデオエンコーダは、PUに対応するCUの部分の残差値を計算し得る。1組の残差値は、変換され、走査され、量子化されて、1組の変換係数が定義され得る。TUは、変換係数を含むデータ構造を定義する。TUは、必ずしもPUのサイズまたは形状に制限されるとは限らない。したがって、TUは、同じCUについての対応するPUよりも大きくてもよく、またはより小さくてもよく、TUは、正方形または非正方形のいずれかであり得る。いくつかの例では、TUの最大サイズは、対応するCUのサイズに対応し得る。
【0040】
図2Aおよび
図2Bは、例示的な4分木250と、対応するLCU272とを示す概念図である。
図2Aは、階層式に構成されたノードを含む、例示的な4分木250を示している。4分木250など、4分木中の各ノードは、子をもたないリーフノードであるか、または4つの子ノードを有し得る。
図2Aの例では、4分木250はルートノード252を含む。ルートノード252は、リーフノード256A〜256C(リーフノード256)とノード254とを含む、4つの子ノードを有する。ノード254はリーフノードでないので、ノード254は、この例ではリーフノード258A〜258D(リーフノード258)である、4つの子ノードを含む。
【0041】
4分木250は、この例ではLCU272など、対応するLCUの特性を記述するデータを含み得る。たとえば、4分木250は、それの構造により、サブCUへのLCUの分割を記述し得る。LCU272が2N×2Nのサイズを有すると仮定する。LCU272は、この例では、4つのサブCU276A〜276C(サブCU276)および274を有し、各々はN×Nサイズである。サブCU274はさらに4つのサブCU278A〜278D(サブCU278)に分割され、各々はサイズN/2×N/2である。この例では、4分木250の構造はLCU272の分割に対応する。すなわち、ルートノード252はLCU272に対応し、リーフノード256はサブCU276に対応し、ノード254はサブCU274に対応し、リーフノード258はサブCU278に対応する。
【0042】
4分木250のノードのデータは、ノードに対応するCUが分割されるかどうかを記述し得る。CUが分割される場合、4分木250中に4つの追加のノードが存在し得る。いくつかの例では、4分木のノードは以下の擬似コードと同様に実装され得る。
【数1】
【0043】
split_flag値は、現在のノードに対応するCUが分割されるかどうかを表す1ビット値であり得る。CUが分割されない場合、split_flag値は「0」であり得るが、CUが分割される場合、split_flag値は「1」であり得る。4分木250の例に関して、分割フラグ値のアレイは101000000であり得る。
【0044】
いくつかの例では、サブCU276およびサブCU278の各々は、同じイントラ予測モードを使用してイントラ予測符号化され得る。したがって、ビデオエンコーダ122は、ルートノード252においてイントラ予測モードの指示を与え得る。その上、サブCUのいくつかのサイズは、特定のイントラ予測モードのために複数の可能な変換を有し得る。ビデオエンコーダ122は、ルートノード252においてそのようなサブCUのために使用すべき変換の指示を与え得る。たとえば、サイズN/2×N/2のサブCUでは複数の可能な変換が利用可能であり得る。ビデオエンコーダ122は、ルートノード252において使用すべき変換をシグナリングし得る。したがって、ビデオデコーダ128は、ルートノード252においてシグナリングされたイントラ予測モードと、ルートノード252においてシグナリングされた変換とに基づいてサブCU278に適用すべき変換を判断し得る。
【0045】
したがって、ビデオエンコーダ122は、本開示の技法によれば、リーフノード256およびリーフノード258においてサブCU276およびサブCU278に適用すべき変換をシグナリングする必要はないが、代わりに、単に、ルートノード252において、イントラ予測モードと、いくつかの例では、いくつかのサイズのサブCUに適用すべき変換とをシグナリングし得る。このようにして、これらの技法は、LCU272など、LCUのサブCUごとに変換機能をシグナリングするオーバーヘッドコストを低減し得る。
【0046】
いくつかの例では、サブCU276および/またはサブCU278のイントラ予測モードは、LCU272のイントラ予測モードとは異なり得る。ビデオエンコーダ122およびビデオデコーダ130は、ルートノード252においてシグナリングされるイントラ予測モードを、サブCU276および/またはサブCU278のために利用可能なイントラ予測モードにマッピングする機能を用いて構成され得る。この機能は、LCU272のために利用可能なイントラ予測モードとサブCU276および/またはサブCU278のイントラ予測モードとの多対1のマッピングを与え得る。
【0047】
上記で紹介されたように、
図3は、4分木スタイルのTUパーティション構造の一例を示す。新興のHEVC規格は、4分木スタイルのTUパーティション構造を可能にする。
図3に示すように、たとえば、実線によるブロック300全体は、元のコーディングユニットを表す。点線は、4分木構造による変換ブロック分解の1つの例示的な結果を示す。当然、そのような結果は、多くの考えられる分解の中のうちのただ1つである。
図3の例では、3つのレベルの変換分解がある。レベル1の分解では、変換ブロック全体が、4分の1サイズの4つのブロック(
図3のブロック322、324、326、および328)に分割される。レベル2で、第2の4分の1サイズの変換ブロックは、1/16サイズの4つの変換ブロック(
図3のブロック332、334、336、および338)にさらに分割される。レベル3で、1/16サイズの4つの変換ブロック(ブロック336)は、さらに小さい4つの変換ブロック(ブロック342、344、346、および348)にさらに分割される。変換ブロックがさらに分割されることを必要とするかどうかは、たとえば、レートひずみ最適化に基づいて決定され得る。
図3に示される例は、4分木分解構造と呼ばれており、その場合、1つのブロックは分割されない、または4分の1サイズの4つのブロックに分割される。レベル0のTUは、コーディングユニット全体がさらなる分割なしで一緒に変換されることを意味する。そのような場合、TUは、コーディングユニットと同じサイズを有する。
【0048】
イントラ予測されたブロックでは、いくつかのコーディング方法によれば、正方形のTU(たとえば
図3に示されるTUなど)のみが許容される。さらに、いくつかのコーディング方法によれば、TUは、イントラ予測されたブロックについての予測ユニットと常に整合される。例が
図4Aおよび
図4Bに示される。
図4Aの例では、1つのブロックが4分の1のサイズの4つのブロックに区分される。
図4Bの例では、第2の4分の1のサイズのブロックが、1/16の元のブロックサイズのサイズを有するより小さい4つのブロックにさらに区分される。HEVCの現在の実装に基づいて、
図6Aおよび
図6Bに示される各ブロックは、予測され、変換され、別々に再構成され得る。変換ブロック(またはTU)サイズは、予測ブロック(または予測ユニット)サイズと同じでもよい。
【0049】
図5Aおよび
図5Bは、イントラ予測されたブロックに使用され得る非正方形の変換の例を示す。そのような場合、TUは、矩形形状を有することができる。
図5Aおよび
図5Bの例は、上記で説明した正方形の変換に加えて、可能であり得る。言い換えれば、所与のブロックについて、
図4Aおよび
図4Bと、
図5Aおよび
図5Bの両方に示される例が使用され得る。たとえば、分解レベル1で、1つのブロックは、
図4Aに示される変換区分を選択することができる。ブロックは、
図5Aおよび
図5Bに示される変換区分を選択することもできる。ビデオエンコーダ20で、これらの3つの異なる予測およびTU区分のすべてがテストされ得、選択されたパーティションユニットおよびTUは、ビデオデコーダ30にシグナリングされる。
【0050】
NxNは、
図4Aに示される変換を示し、hNx2Nは、
図5Aに示される変換を示し、2NxhNは、
図5Bに示される変換を示すと仮定する。一例では、ビデオエンコーダ20は、まず、正方形の変換、NxNが使用されるかどうかをビデオデコーダ30にシグナリングするためにフラグ(NS_Flag)をシグナリングすることができ、0に設定されたNS_Flagは、変換NxNが選択されることをシグナリングし、1に設定されたNS_Flagは、2つの非正方形の変換(hNx2Nおよび2NxhN)のうちの1つが選択されることをシグナリングする。2つの非正方形の変換のうちの1つが選択される(すなわちNS_Flag=1)場合、追加のフラグ(NS_Dir)がシグナリングされることを必要する場合があり、0に設定されたNS_Dirは、変換hNx2Nが選択されることを示し、1に設定されたNS_Dirは、2NxhNが選択されることを示す。このようにして、正方形の変換に加えて、非正方形の変換を可能にすることは、コーディング効率を向上させることができる。
【0051】
上記で説明したシグナリング方法によれば、NxN変換が選択されるとき、1つのフラグが使用され、非正方形の変換hNx2Nまたは2NxhNが選択されるとき、2つのフラグが使用される。最も頻繁に行われる変換モードのために最少のシグナリングビット(この例では1つのフラグ)が使用されるので、イントラ予測コーディングにおいてNxNが最も可能性の高い変換であるとき、このシグナリング技法は、ビットの節約をもたらし得る。しかしながら、いくつかの例では、異なるイントラ予測方向(たとえば
図4に示される35個のイントラ予測方向モード)についての最も可能性の高い変換は、異なり得る。本開示の技法によれば、非正方形の変換が最も可能性の高い変換であるとき、上記で説明した2つのフラグと対照的に、非正方形の変換をシグナリングするために1つのフラグを使用することによって、ビットの節約が達成され得る。したがって、本開示の技法は、いくつかの例では、最も可能性の高い変換のために最少のシグナリングビットを使用することによって、変換シグナリング方法を向上させる。
【0052】
本開示の技法によれば、ビデオエンコーダ20は、イントラ予測モード符号化を使用して、ビデオデータのいくつかのブロックを符号化することができ、ブロックを符号化するために使用される選択されたイントラ予測モードを示す情報を提供することができる。ビデオエンコーダ20は、PフレームまたはPスライス、およびBフレームまたはBスライスに加えて、たとえば、IフレームまたはIスライスなど、イントラ予測モードを使用して、任意のタイプのフレームまたはスライスのブロックをイントラ予測符号化することができる。あるブロックがイントラ予測モード符号化されるべきであることをビデオエンコーダ20が決定したとき、ビデオエンコーダ20は、最も適切なイントラ予測モードを選択するためにレートひずみ分析を実行することができる。たとえば、ビデオエンコーダ20は、1つまたは複数のイントラ予測モードについてのレートひずみ値を計算し、受容できるレートひずみ特性を有するモードのうちの1つを選択することができる。
【0053】
ビデオエンコーダ20は、ブロックの符号化コンテキストを決定するように構成することもできる。コンテキストは、たとえば、ピクセル寸法で決定され得るブロックのサイズ、たとえばHEVCの例における2N×2N、N×2N、2N×N、N×Nなどの予測ユニット(PU)タイプ、2N×N/2、N/2×2N、2N×1、1×2Nなどの短距離イントラ予測(SDIP)タイプ、H.264の例におけるマクロブロックタイプ、ブロックについてのコーディングユニット(CU)深さ、またはビデオデータのブロックについてのサイズの他の測定値など、ブロックの様々な特性を含むことができる。いくつかの例では、コンテキストは、上に隣接するブロック、左に隣接するブロック、左上に隣接するブロック、右上に隣接するブロック、または他の隣接するブロックについてのイントラ予測モードの方法のいずれかまたはすべてに対応することができる。いくつかの例では、コンテキストは、1つまたは複数のブロックについてのイントラ予測モードと、符号化されている現在のブロックのサイズ情報の両方を含むことができる。ブロックについてのコンテキスト情報を提供することができる隣接ブロックまたは他のデータからのデータに基づいて、他のコンテキストがあるブロックのために定義される、または使用され得る。
【0054】
いずれの場合にも、ビデオエンコーダ20は、ブロックのコンテキストを現在のブロックについての様々なコーディング特性にマッピングする構成データを含み得る。たとえば、ブロックのコンテキストに基づいて、構成データは、1つまたは複数の最も可能性の高いイントラ予測モードを示し得る。ビデオエンコーダ20は、いくつかの例では、コンテキストに基づいて、最も可能性の高いモードでイントラ予測モードの選択のための分析を開始するように構成され得る。最も可能性の高いモードが適切なレートひずみ特性を達成するとき、いくつかの例では、ビデオエンコーダ20は、最も可能性の高いモードを選択することができる。他の例では、ビデオエンコーダ20は、最も可能性の高いモードで選択プロセスを開始する必要はない。
【0055】
予測データと残差データとを生成するためのイントラ予測コーディングまたはインター予測コーディングの後、および変換係数を生成するための(H.264/AVCで使用される4×4または8×8整数変換、あるいは離散コサイン変換DCTなどの)任意の変換の後、変換係数の量子化が実行され得る。量子化は、概して、係数を表すために使用されるデータ量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減することができる。たとえば、量子化中にnビット値がmビット値に切り捨てられ得、nはmよりも大きい。
【0056】
量子化の後に、たとえば、コンテンツ適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、または別のエントロピーコーディング方法に従って、量子化データのエントロピーコーディングが実行され得る。エントロピーコーディング用に構成された処理ユニットまたは別の処理ユニットは、量子化係数のゼロランレングスコーディング、および/またはコード化ブロックパターン(CBP)値、マクロブロックタイプ、コーディングモード、(フレーム、スライス、マクロブロック、またはシーケンスなどの)コード化ユニットの最大マクロブロックサイズなどのシンタックス情報の生成など、他の処理機能を実行し得る。
【0057】
ビデオデコーダ30は、最終的に、たとえば、モデム28および受信機26から符号化ビデオデータを受信することができる。本開示の技法によれば、ビデオデコーダ30は、ビデオデータのブロックを符号化するために使用されるイントラ予測モードを表す符号化データを受信することができる。ビデオデコーダ30は、ビデオエンコーダ20と実質的に同様の方法でブロックについてのコーディングコンテキストを決定するように構成することができる。その上、ビデオデコーダ30は、たとえば、最も可能性の高いモードの指示、イントラ予測モードインデックステーブル、およびコーディングコンテキストごとのVLCテーブルなど、ビデオエンコーダ20と同様の構成データを含み得る。
【0058】
ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、適用可能なとき、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。ビデオエンコーダ20および/またはビデオデコーダ30を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを備え得る。
【0059】
図6は、特定のCUの変換を示す情報をコード化するための技法を実装し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、マクロブロックあるいはマクロブロックのパーティションまたはサブパーティションを含むビデオフレーム内のブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレーム内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは時間的予測を利用して、ビデオシーケンスの隣接フレーム内のビデオの時間的冗長性を低減または除去する。イントラ予測モード(Iモード)は、いくつかの空間ベースの圧縮モードのいずれかを指し、単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。
【0060】
図6に示されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。
図6の例では、ビデオエンコーダ20は、モード選択ユニット40と、動き補償ユニット44と、動き推定ユニット42と、イントラ予測処理ユニット46と、メモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピーコーディングユニット56とを含む。ビデオブロックの再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換処理ユニット60と、加算器62とを含む。再構成されたビデオブロックをフィルタ処理するために、たとえばデブロッキングフィルタ、サンプル適応オフセットフィルタ、および/または適応ループフィルタなど、様々なループフィルタ(
図6には図示せず)が含まれることもある。所望される場合、ループフィルタは、一般に、加算器62の出力をフィルタ処理するであろう。
【0061】
符号化プロセス中に、ビデオエンコーダ20はコーディングされるビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間圧縮を行うために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対する受信したビデオブロックのインター予測コーディングを実行する。イントラ予測処理ユニット46は、空間圧縮を行うために、コーディングされるブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する受信したビデオブロックのイントラ予測コーディングを実行し得る。
【0062】
モード選択ユニット40は、誤差結果に基づいて、およびコード化されている現在のブロックを含むフレームまたはスライスのフレームまたはスライスタイプに基づいて、コーディングモード、(たとえば、イントラまたはインター)のうちの1つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器50に供給し、参照フレームまたは参照スライス中で使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器62に供給し得る。一般に、イントラ予測は、隣接する、前にコード化されたブロックに対して現在のブロックを予測することを伴い、一方、インター予測は、現在のブロックを時間的に予測するために、動き推定および動き補償を伴う。
【0063】
動き推定ユニット42および動き補償ユニット44は、ビデオエンコーダ20のインター予測要素を表す。動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(または、他のコード化ユニット)内のコーディングされている現在のブロックに対する予測参照フレーム(または、他のコード化ユニット)内の予測ブロックの変位を示し得る。予測ブロックは、絶対値差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるブロックにぴったり一致することがわかるブロックである。動きベクトルはまた、マクロブロックのパーティションの変位を示し得る。動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット42と動き補償ユニット44とは機能的に統合され得る。
【0064】
動き推定ユニット42は、ビデオブロックを参照フレームストア64中の参照フレームのビデオブロックと比較することによってインターコード化フレームのビデオブロックの動きベクトルを計算する。動き補償ユニット44はまた、参照フレーム、たとえば、IフレームまたはPフレームのサブ整数ピクセルを補間し得る。ITU H.264規格は、一例として、符号化されている現在のフレームよりも前の表示順序を有する参照フレームを含むリスト0、および符号化されている現在のフレームよりも後の表示順序を有する参照フレームを含むリスト1の2つのリストを記述する。したがって、参照フレームストア64に記憶されたデータは、これらのリストに従って編成され得る。
【0065】
動き推定ユニット42は、参照フレームストア64からの1つまたは複数の参照フレームのブロックを現在のフレーム、たとえば、PフレームまたはBフレームの符号化すべきブロックと比較する。参照フレームストア64中の参照フレームがサブ整数ピクセルの値を含むとき、動き推定ユニット42によって計算される動きベクトルは参照フレームのサブ整数ピクセルロケーションを参照し得る。動き推定ユニット42および/または動き補償ユニット44はまた、サブ整数ピクセル位置の値が参照フレームストア64に記憶されていない場合、参照フレームストア64に記憶された参照フレームのサブ整数ピクセル位置の値を計算するように構成され得る。動き推定ユニット42は、計算された動きベクトルをエントロピーコード化ユニット56と動き補償ユニット44とに送る。動きベクトルによって識別される参照フレームブロックは予測ブロックと呼ばれることがある。動き補償ユニット44は、インター予測ブロックに基づいて予測データを計算し得る。
【0066】
イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測処理ユニット46は、現在のブロックの符号化に使用するためのイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別々の符号化パスの間など、様々なイントラ予測モードを使用して、現在のブロックを符号化することができ、イントラ予測処理ユニット46(または、いくつかの例において、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。たとえば、イントラ予測処理ユニット46は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中の最良のレートひずみ特性を有するイントラ予測モードを選択することができる。レートひずみ分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(またはエラー)の量、ならびに、符号化されたブロックを生成するために使用されたビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット46は、どのイントラ予測モードがブロックについての最良のレートひずみ値を呈するかを決定するために、様々な符号化されたブロックについてのひずみおよびレートから比率を計算することができる。
【0067】
図7は、HEVCで使用することができるイントラ予測モードおよび対応するモードインデックスの一例を示す。
図7の矢印は、予測方向を表し、数字は、モードインデックスを表す。以下の表1は、CUのサイズと、HEVC仕様の1つの中間バージョンにおけるそのサイズのCUの符号化のために利用可能なイントラ予測モードの数との間の対応を示す。表1によってわかるように、8×8、16×16、および32×32のCUは、
図4に示される35のイントラ予測モードを使用することができ、一方、4×4および64×64のCUはより少ない組のイントラ予測モードを使用する。
【表1】
【0068】
HEVCは、現在、35個の異なるイントラ予測モードを許容する。これらのモードは、1つのDCモードと、1つの平面モードと、33個の異なる方向性予測モードとを含む。方向性予測モードを用いて、そのモードによって示されるある方向に沿った隣接ブロックの再構成されたピクセルに基づいて予測が実行される。異なる予測モードに関連する方向を
図7に示す。
【0069】
いずれの場合も、ブロックのイントラ予測モードを選択した後に、イントラ予測処理ユニット46は、ブロックについての選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供し得る。エントロピーコーディングユニット56は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。
【0070】
たとえば、イントラ予測またはインター予測を使用して、現在のブロックを予測した後、ビデオエンコーダ20は、コード化されている元のビデオブロックから、動き補償ユニット44またはイントラ予測処理ユニット46によって計算された予測データを減算することによって残差ビデオブロックを形成し得る。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、概念的にDCTと同様である、H.264規格によって定義される変換などの他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換をも使用することができる。いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。量子化ユニット54は、ビットレートをさらに低減するために残差変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減することができる。量子化の程度は、量子化パラメータを調整することによって変更され得る。
【0071】
一例では、予測ユニットごとに1つのイントラ予測モード(たとえば
図6に示される35個のうちの1つ)を選択した後、次いで、ビデオエンコーダ20は、上記で説明したように、変換を選択することができる。各イントラ予測モードkは、関連する最も可能性の高い変換MPT(k)を有することができ、それは、たとえば、NxN、hNx2N、または2NxhNのうちの1つである。ビデオエンコーダ20は、現在のイントラ予測モードkについて、選択された変換がMPT(k)であるかどうかをシグナリングするために、符号化されたビットストリームに含めるためのフラグ(MPT_Flag)を生成することができる。たとえば、1に設定されたMPT_Flagは、選択された変換がMPT(k)であることを示し、一方、0に設定されたMPT_Flagは、選択された変換がMPT(k)ではないことを示すことができる。MPT_Flagが0に設定される例では、余分のフラグ(MPT_ResMode)は、他の2つの変換のうちのどちらが選択されるかをシグナリングするために生成され得る。
【0072】
一例として、現在のPUについてのイントラ予測モードがモード1であり、hNx2Nがこのイントラ予測モードに関連付けられたMPTである、すなわちhNx2N=MPT(1)と仮定する。選択されたイントラ予測モードがhNx2Nである場合、1に設定されたMPT_Flagは、変換をシグナリングするために必要な任意の他のビットなしに、ビデオエンコーダ20からビデオエンコーダ30に、符号化されたビットストリームでシグナリングされ得る。選択されたイントラ予測モードがNxNである場合、0に設定されたMPT_Flagがシグナリングされ得、0に設定されたMPT_ResModeが続く。選択されたイントラ予測モードが2NxhNである場合、0に設定されたMPT_Flagがシグナリングされ得、1に設定されたMPT_ResModeが続く。
【0073】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、あらかじめ定義され、ビデオエンコーダ20とビデオデコーダ30の両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、ビデオエンコーダ20によって決定され、たとえば(シーケンスパラメータセット)、PPS(ピクチャパラメータセット)、APS(適応パラメータセット)など、高レベルのシンタックスを使用して、ビデオデコーダ30にシグナリングされ得る。さらに他の例では、MPTとイントラ予測モードkとの間のマッピング、MPT(k)は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、MPT(k)は異なり得る。同様に、MPT(k)は、たとえばQP、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【0074】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードkのすべてのブロックについて、変換NxNが最も頻繁に行われる変換である場合、MPT(k)は、現在のブロックの符号化のために、NxN変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダ20とビデオデコーダ30の両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、ビデオエンコーダ20とビデオデコーダ30との間でマッピングが明示的にシグナリングされることなく、ビデオエンコーダ20とビデオデコーダ30との両方で動的に調整され得る。
【0075】
量子化の後、エントロピーコード化ユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコード化ユニット56は、コンテンツ適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、または別のエントロピーコーディング技法を実行し得る。エントロピーコード化ユニット56によるエントロピーコーディングの後に、符号化されたビデオは、別のデバイスに送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。コンテキスト適応型バイナリ算術コーディングの場合、コンテキストは隣接ブロックおよび/またはブロックサイズに基づき得る。
【0076】
場合によっては、エントロピーコード化ユニット56またはビデオエンコーダ20の別のユニットは、上記で説明したように、エントロピーコーディングおよびイントラ予測モードのコーディングに加えて他のコーディング機能を実行するように構成され得る。たとえば、エントロピーコード化ユニット56はブロックのコード化ブロックパターン(CBP:coded block pattern)値およびパーティションを判断するように構成され得る。また、場合によっては、エントロピーコード化ユニット56は、マクロブロックまたはそれのパーティション中の係数のランレングスコーディングを実行し得る。特に、エントロピーコード化ユニット56は、マクロブロックまたはパーティション中の変換係数をスキャンするためにジグザグスキャンまたは他のスキャンパターンを適用し、さらなる圧縮のためにゼロのランを符号化し得る。エントロピーコード化ユニット56はまた、符号化ビデオビットストリーム中での送信のために適切なシンタックス要素を用いてヘッダ情報を構成し得る。
【0077】
逆量子化ユニット58および逆変換処理ユニット60は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット44は、残差ブロックを参照フレームストア64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算して、参照フレームストア64に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
【0078】
このようにして、ビデオエンコーダ20は、ビデオデータの1つのブロックのためのイントラ予測モードを決定し、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別し、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するように構成され得るビデオエンコーダの一例を表す。最も可能性の高い変換は、非正方形の変換とすることができる。ビデオエンコーダ20は、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを生成することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオエンコーダ20は、最も可能性の高い変換以外の変換の指示を生成することができ、ただし、最も可能性の高い変換以外の変換は、ビデオデータのブロックを符号化するために使用される変換である。変換は、NxN、hNx2N、および2NxhNからなる一群の変換から選択され得、ただし、Nは、変換の寸法のサイズを表し、hNは、Nの値の半分を表し、2NはNの値の2倍を表す。
【0079】
ビデオエンコーダ30は、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することもできる。マッピングは、固定される、ビデオエンコーダ20からビデオデコーダにシグナリングされる、または、適応可能とすることができる。マッピングが適応可能である場合、マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングは、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【0080】
図8は、符号化されたビデオシーケンスを復号するビデオデコーダ30の一例を示すブロック図である。
図5の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測処理ユニット74と、逆量子化ユニット76と、逆変換処理ユニット78と、メモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(
図6)に関して説明した符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信した動きベクトルに基づいて予測データを生成し得る。
【0081】
動き補償ユニット72は、ビットストリーム中で受信した動きベクトルを使用して、参照フレームストア82中の参照フレーム中の予測ブロックを識別し得る。イントラ予測処理ユニット74は、ビットストリーム中で受信されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成し得る。特に、ビデオデコーダ30は、
図5の例では、構成データ84を含む。構成データ84が、イントラ予測されたブロックのコンテキストを記述する情報と、コンテキストごとの最も可能性の高いイントラ予測モードなどを含むという点で、構成データ84は、
図6の構成データ66と実質的に同様である。
【0082】
エントロピー復号ユニット70は、ビデオデータの符号化されたブロックの復号に使用するためのイントラ予測モードを表すデータを受信することができる。エントロピー復号ユニット70は、たとえば、符号化されたブロックの左に隣接するブロックおよび上に隣接するブロックについてのイントラ予測モード、ならびに/または符号化されたブロックについてのサイズに基づいて、符号化されたブロックのコンテキストを決定することができる。コンテキストに基づいて、エントロピー復号ユニット70は、ブロックの復号に使用するための1つまたは複数の最も可能性の高いイントラ予測モードを決定することができる。
【0083】
イントラ予測処理ユニット74は、たとえば、隣接する、以前復号されたブロックのピクセルを使用して、符号化されたブロックをイントラ予測するためにイントラ予測モードの指示を使用することができる。ブロックがインター予測モード符号化される例では、動き補償ユニット72は、符号化されたブロックについての動き補償予測データを取り出すために、動きベクトルを定義する情報を受信することができる。いずれの場合も、動き補償ユニット72またはイントラ予測処理ユニット74は、加算器80に予測ブロックを定義する情報を提供することができる。
【0084】
逆量子化ユニット76は、ビットストリーム中で供給され、エントロピー復号ユニット70によって復号された量子化ブロック係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、たとえば、H.264復号規格によって定義される、またはHEVCテストモデルによって実行されるなど、従来のプロセスを含み得る。逆量子化プロセスはまた、量子化の程度を判断し、同様に、適用する逆量子化の程度を判断するための、各マクロブロックについてエンコーダ20によって計算される量子化パラメータQP
Yの使用を含み得る。
【0085】
逆変換ユニット58は、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用して、ピクセル領域において残差ブロックを生成する。動き補償ユニット72は動き補償ブロックを生成し、場合によっては、補間フィルタに基づいて補間を実行する。サブピクセル精度をもつ動き推定に使用されるべき補間フィルタの識別子は、シンタックス要素中に含まれ得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。動き補償ユニット72は、受信されたシンタックス情報に従って、ビデオエンコーダ20によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。
【0086】
動き補償ユニット72は、シンタックス情報のいくつかを使用して、符号化ビデオシーケンスの(1つまたは複数の)フレームを符号化するために使用されるブロックのサイズと、符号化ビデオシーケンスのフレームまたはスライスの各ブロックがどのように区分されるかを記述するパーティション情報と、各パーティションがどのように符号化されるかを示すモードと、各インター符号化ブロックまたはパーティションのための1つまたは複数の参照フレーム(および参照フレームリスト)と、符号化ビデオシーケンスを復号するための他の情報とを判断する。
【0087】
一例では、予測ユニットごとに1つのイントラ予測モード(たとえば
図6に示される35個のうちの1つ)を決定した後、次いで、ビデオデコーダ30は、PUに関連付けられたTUのために使用される変換サイズを決定することができる。各イントラ予測モードkは、関連する最も可能性の高い変換MPT(k)を有することができ、それは、たとえば、NxN、hNx2N、または2NxhNのうちの1つである。ビデオデコーダ30は、現在のイントラ予測モードkについて、選択された変換がMPT(k)であるかどうかをシグナリングするために、符号化されたビットストリームでフラグ(MPT_Flag)を受信することができる。たとえば、1に設定されたMPT_Flagは、選択された変換がMPT(k)であることを示し、一方、0に設定されたMPT_Flagは、選択された変換がMPT(k)ではないことを示すことができる。MPT_Flagが0に設定される例では、余分のフラグ(MPT_ResMode)は、他の2つの変換のうちのどちらが選択されるかをシグナリングするために受信され得る。
【0088】
一例として、現在のPUについてのイントラ予測モードがモード1であり、hNx2Nがこのイントラ予測モードに関連付けられたMPTである、すなわちhNx2N=MPT(1)と仮定する。選択されたイントラ予測モードがhNx2Nである場合、1に設定されたMPT_Flagが符号化されたビットストリームでビデオデコーダ30によって受信され得る。選択されたイントラ予測モードがNxNである場合、0に設定されたMPT_Flagが符号化されたビットストリームでビデオデコーダ30によって受信され得、0に設定されたMPT_ResModeが続く。選択されたイントラ予測モードが2NxhNである場合、0に設定されたMPT_Flagが受信され得、1に設定されたMPT_ResModeが続く。
【0089】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、あらかじめ定義され、ビデオエンコーダ20とビデオデコーダ30の両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、ビデオエンコーダ20によって決定され、SPS(シーケンスパラメータセット)、PPS(ピクチャパラメータセット)、APS(適応パラメータセット)、スライスヘッダ、ブロックヘッダ、または別のタイプのシンタックスなどの中の1要素など、高レベルのシンタックスを使用して、ビデオデコーダ30にシグナリングされ得る。さらに他の例では、MPTとイントラ予測モードkとの間のマッピング、MPT(k)は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、MPT(k)は異なり得る。同様に、MPT(k)は、たとえばQP、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【0090】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、MPT(k)は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードkのすべてのブロックについて、変換NxNが最も頻繁に行われる変換である場合、MPT(k)は、現在のブロックの符号化のために、NxN変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダ20とビデオデコーダ30の両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、ビデオエンコーダ20とビデオデコーダ30との間でマッピングが明示的にシグナリングされることなく、ビデオエンコーダ20とビデオデコーダ30との両方で動的に調整され得る。
【0091】
加算器80は、残差ブロックを、動き補償ユニット72またはイントラ予測処理ユニット74によって生成される対応する予測ブロックと合計して、復号ブロックを形成する。必要に応じて、ブロッキネスアーティファクトを除去するために、デブロッキングフィルタを適用して、復号ブロックをフィルタ処理することもできる。復号されたビデオブロックは、次いで、参照フレームストア82に記憶され、参照フレームストア82は、参照ブロックをその後の動き補償に供給し、また、ディスプレイデバイス(
図1のディスプレイデバイス32など)上での提示のために復号されたビデオを生成する。
【0092】
このようにして、ビデオデコーダ30は、ビデオデータの1つのブロックのためのイントラ予測モードを決定し、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別し、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するように構成され得るビデオデコーダの一例を表す。最も可能性の高い変換は、非正方形の変換とすることができる。ビデオデコーダ30は、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができ、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを受信することを備える。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であることを示すフラグに応答して、ビデオデコーダ30は、最も可能性の高い変換に基づいてビデオデータのブロックを再構成することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオデコーダ30は、最も可能性の高い変換以外の変換の指示を受信し、最も可能性の高い変換以外の変換に基づいて、ビデオデータのブロックを再構成することができる。変換は、NxN、hNx2N、および2NxhNからなる一群の変換から選択され得、ただし、Nは、変換の寸法のサイズを表し、hNは、Nの値の半分を表し、2NはNの値の2倍を表す。
【0093】
ビデオデコーダ30は、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することもできる。マッピングは、固定される、ビデオエンコーダからビデオデコーダ30にシグナリングされる、または、適応可能とすることができる。マッピングが適応可能である場合、マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングは、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【0094】
図9は、本開示の技法による変換サイズをシグナリングするための例示的な方法を示すフローチャートである。
図9の技法について、一般的なビデオコーダを参照しながら説明する。一般的なビデオコーダは、たとえば、ビデオエンコーダ20などのビデオエンコーダ、またはビデオデコーダ30などのビデオデコーダでもよい。
【0095】
ビデオコーダは、ビデオデータのブロックのためのイントラ予測モードを決定する(910)。ビデオコーダは、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別する(920)。最も可能性の高い変換は、正方形の変換または非正方形の変換のいずれかとすることができる。ビデオコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化する(930)。変換は、NxN、hNx2N、および2NxhNからなる一群の変換から選択され得、ただし、Nは、変換の寸法のサイズを表し、hNは、Nの値の半分を表し、2NはNの値の2倍を表す。
【0096】
ビデオコーダは、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することができる。マッピングは、固定される、またはビデオエンコーダからビデオデコーダにシグナリングされ得る。マッピングは、適応可能とすることもできる。マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングはまた、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【0097】
ビデオコーダがビデオエンコーダであるとき、ビデオコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを生成することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオコーダは、ビデオデータのブロックを符号化するために使用される変換である最も可能性の高い変換以外の変換の指示を生成することができる。
【0098】
ビデオコーダがビデデコーダであるとき、ビデオデコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを受信することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であることを示すフラグに応答して、ビデオコーダは、最も可能性の高い変換に基づいてビデオデータのブロックを再構成することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオコーダは、最も可能性の高い変換以外の変換の指示を受信し、最も可能性の高い変換以外の変換に基づいて、ビデオデータのブロックを再構成することができる。
【0099】
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【0100】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【0101】
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)などの1つもしくは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積回路もしくはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素中に十分に実装され得る。
【0102】
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実施され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明した1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
【0103】
様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
なお、以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]ビデオデータをコード化する方法であって、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することと
を備える方法。
[C2]ビデオデータを符号化する方法を備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成することを備える、C1に記載の方法。
[C3]前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成することをさらに備え、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、C2に記載の方法。
[C4]ビデオデータを復号する方法を備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信することを備える、C1に記載の方法。
[C5]前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成すること
をさらに備える、C4に記載の方法。
[C6]前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
をさらに備える、C4に記載の方法。
[C7]イントラ予測モードに対する最も可能性の高い変換のマッピングを維持すること
をさらに備える、C1に記載の方法。
[C8]前記マッピングが固定である、C7に記載の方法。
[C9]前記マッピングがコード化ビットストリームの一部としてシグナリングされる、C7に記載の方法。
[C10]前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、C7に記載の方法。
[C11]前記マッピングが適応可能である、C7に記載の方法。
[C12]前記マッピングがブロックサイズに基づいて適応可能である、C11に記載の方法。
[C13]前記変換が、NxN、hNx2N、および2NxhNからなる一群から選択され、Nが変換の寸法のサイズを表し、hNがNの値の半分を表し、2NがNの前記値の2倍を表す、C1に記載の方法。
[C14]ビデオコーダが、ビデオデータのブロックのためのイントラ予測モードを決定することと、前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて、最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することとを行うように構成されたビデオコーダ
を備えるビデオコーディングデバイス。
[C15]前記ビデオコーダがビデオエンコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成することを備える、C14に記載のビデオコーディングデバイス。
[C16]前記ビデオコーダが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成するようにさらに構成され、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、C15に記載のビデオコーディングデバイス。
[C17]前記ビデオコーダがビデオデコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信することを備える、C14に記載のビデオコーディングデバイス。
[C18]前記ビデオコーダが、
前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成する
ように構成される、C17に記載のビデオコーディングデバイス。
[C19]前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
をさらに備える、C17に記載のビデオコーディングデバイス。
[C20]前記ビデオコーダが、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するようにさらに構成される、C14に記載のビデオコーディングデバイス。
[C21]前記マッピングが固定である、C20に記載のビデオコーディングデバイス。
[C22]前記マッピングがコード化ビットストリームの一部としてシグナリングされる、C20に記載のビデオコーディングデバイス。
[C23]前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、C20に記載のビデオコーディングデバイス。
[C24]前記マッピングが適応可能である、C20に記載のビデオコーディングデバイス。
[C25]前記マッピングがブロックサイズに基づいて適応可能である、C24に記載のビデオコーディングデバイス。
[C26]前記変換が、NxN、hNx2N、および2NxhNからなる一群から選択され、Nが変換の寸法のサイズを表し、hNがNの値の半分を表し、2NがNの前記値の2倍を表す、C14に記載のビデオコーディングデバイス。
[C27]前記ビデオコーディングデバイスが、
集積回路と、
マイクロプロセッサと、
前記ビデオコーダを含むワイヤレス通信デバイスと
のうちの少なくとも1つを備える、C14に記載のビデオコーディングデバイス。
[C28]ビデオコーディングのためのデバイスであって、
ビデオデータのブロックのためのイントラ予測モードを決定するための手段と、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別するための手段であって、前記最も可能性の高い変換が非正方形の変換である、手段と、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するための手段と
を備えるデバイス。
[C29]前記デバイスがビデオエンコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化するための前記手段が、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成するための手段を備える、C28に記載のデバイス。
[C30]前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成するための手段をさらに備え、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である
C29に記載のデバイス。
[C31]前記デバイスがビデオデコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化するための前記手段が、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信するための手段を備える、C28に記載のデバイス。
[C32]前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成するための手段
をさらに備える、C31に記載のデバイス。
[C33]前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信するための手段と、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成するための手段と
をさらに備える、C32に記載のデバイス。
[C34]イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するための手段
をさらに備える、C28に記載のデバイス。
[C35]前記マッピングが固定である、C34に記載のデバイス。
[C36]前記マッピングがコード化ビットストリームの一部としてシグナリングされる、C34に記載のデバイス。
[C37]前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、C34に記載のデバイス。
[C38]前記マッピングが適応可能である、C34に記載のデバイス。
[C39]前記マッピングがブロックサイズに基づいて適応可能である、C38に記載のデバイス。
[C40]前記変換が、NxN、hNx2N、および2NxhNからなる一群から選択され、Nが変換の寸法のサイズを表し、hNがNの値の半分を表し、2NがNの前記値の2倍を表す、C28に記載のデバイス。
[C41]1つまたは複数のプロセッサに、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することと
を行わせるように動作可能な命令を記憶するコンピュータ可読記憶媒体。