(57)【特許請求の範囲】
【請求項１】
ビデオデータを復号する方法であって、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形形状の変換ブロックに対応し、前記変換が、ＮｘＮ変換、ｈＮｘ２Ｎ変換、および２ＮｘｈＮ変換からなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表し、前記最も可能性の高い変換が、前記ｈＮｘ２Ｎ変換または前記２ＮｘｈＮ変換のうちの１つに対応する、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示を復号することであって、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示を復号することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示す１つのフラグを受信することを備える、復号することと、
前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記１つのフラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換以外の変換であることに応答して、前記ビデオデータのブロックを符号化するために使用される前記変換を識別する指示を復号することと
を備え、前記方法はさらに、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
を備える方法。
【請求項２】
イントラ予測モードに対する最も可能性の高い変換のマッピングを維持すること
をさらに備える、請求項１に記載の方法。
【請求項３】
前記マッピングが固定である、請求項２に記載の方法。
【請求項４】
前記マッピングがコード化ビットストリームの一部としてシグナリングされる、請求項２に記載の方法。
【請求項５】
前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、請求項２に記載の方法。
【請求項６】
前記マッピングが適応可能である、請求項２に記載の方法。
【請求項７】
前記マッピングがブロックサイズに基づいて適応可能である、請求項６に記載の方法。
【請求項８】
ビデオデータのブロックのためのイントラ予測モードを決定することと、前記決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形形状の変換ブロックに対応し、前記変換が、ＮｘＮ変換、ｈＮｘ２Ｎ変換、および２ＮｘｈＮ変換からなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表し、前記最も可能性の高い変換が、前記ｈＮｘ２Ｎ変換または前記２ＮｘｈＮ変換のうちの１つに対応する、識別することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示を復号することであって、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示を復号することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示す１つのフラグを受信することを備える、復号することと、前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記１つのフラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換以外の変換であることに応答して、前記最も可能性の高い変換以外の変換の指示を復号することであって、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、復号することとを行うように構成されたビデオデコーダ
を備え、前記ビデオデコーダが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することとを行うように構成される、ビデオコーディングデバイス。
【請求項９】
前記ビデオデコーダが、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するようにさらに構成される、請求項８に記載のビデオコーディングデバイス。
【請求項１０】
前記マッピングが固定である、請求項９に記載のビデオコーディングデバイス。
【請求項１１】
前記マッピングがコード化ビットストリームの一部としてシグナリングされる、請求項９に記載のビデオコーディングデバイス。
【請求項１２】
前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、請求項９に記載のビデオコーディングデバイス。
【請求項１３】
前記マッピングが適応可能である、請求項９に記載のビデオコーディングデバイス。
【請求項１４】
前記マッピングがブロックサイズに基づいて適応可能である、請求項１３に記載のビデオコーディングデバイス。
【請求項１５】
前記ビデオコーディングデバイスが、
集積回路と、
マイクロプロセッサと、
前記ビデオデコーダを含むワイヤレス通信デバイスと
のうちの少なくとも１つを備える、請求項８に記載のビデオコーディングデバイス。
【請求項１６】
ビデオコーディングのためのデバイスであって、
ビデオデータのブロックのためのイントラ予測モードを決定するための手段と、
前記決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別するための手段であって、前記最も可能性の高い変換が非正方形形状の変換ブロックに対応し、前記変換が、ＮｘＮ変換、ｈＮｘ２Ｎ変換、および２ＮｘｈＮ変換からなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表し、前記最も可能性の高い変換が、前記ｈＮｘ２Ｎ変換または前記２ＮｘｈＮ変換のうちの１つに対応する、手段と、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示を復号するための手段であって、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示を復号するための前記手段が、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示す１つのフラグを受信するための手段を備える、復号するための手段と、
前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記１つのフラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成するための手段と、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換以外の変換であることに応答して、前記ビデオデータのブロックを符号化するために使用される前記変換を識別する指示を復号するための手段と
を備え、前記デバイスはさらに、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信するための手段と、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成するための手段と
を備えるデバイス。
【請求項１７】
イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するための手段
をさらに備える、請求項１６に記載のデバイス。
【請求項１８】
前記マッピングが適応可能である、請求項１７に記載のデバイス。
【請求項１９】
コンピュータ可読記憶媒体であって、１つまたは複数のプロセッサに、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形形状の変換ブロックに対応し、前記変換が、ＮｘＮ変換、ｈＮｘ２Ｎ変換、および２ＮｘｈＮ変換からなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表し、前記最も可能性の高い変換が、前記ｈＮｘ２Ｎ変換または前記２ＮｘｈＮ変換のうちの１つに対応する、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示を復号することとであって、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示を復号することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示す１つのフラグを受信することを備える、復号することと、
前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記１つのフラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換以外の変換であることに応答して、前記最も可能性の高い変換以外の変換の指示を復号することであって、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、復号することと
を行わせるように動作可能な命令を記憶し、前記コンピュータ可読記憶媒体はさらに、１つまたは複数のプロセッサに、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
を行わせるように動作可能な命令を記憶するコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、その内容全体が参照により本明細書に組み込まれる、２０１１年１０月１１日に出願された米国仮出願第６１／５４５，９０１号の優先権を主張する。
【０００２】
本開示は、ビデオコーディングに関し、より詳細には、コード化されたビデオデータについてのコード化特性のシグナリングに関する。
【背景技術】
【０００３】
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３またはＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ  １０、Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。
【０００４】
ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間的予測および／または時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスはビデオブロックに区分され得る。各ビデオブロックはさらに区分され得る。イントラコード化（Ｉ）フレームまたはスライス中のビデオブロックは、隣接ビデオブロックに対する空間的予測を使用して符号化される。インターコード化（ＰまたはＢ）フレームまたはスライス中のビデオブロックは、同じフレームまたはスライス中の隣接マクロブロックまたはコーディングユニットに関する空間的予測、あるいは他の参照フレームに関する時間的予測を使用し得る。
【発明の概要】
【０００５】
本開示は、符号化されたビデオビットストリームにおけるビデオデータのブロックのための選択された変換サイズをシグナリングするための技法を記述する。本開示の技法によれば、最も可能性の高い変換は、ブロックのためのイントラ予測モードに基づいて決定され得る。最も可能性の高い変換は、正方形の変換または非正方形の変換のいずれかであり得る。第１のシンタックス要素は、決定された最も可能性の高い変換が変換ブロックをコード化するために使用される実際の変換サイズであるかどうかをシグナリングすることができる。実際の変換が最も可能性の高い変換である場合、他のシンタックス要素が符号化されたビットストリームでシグナリングされる必要はない。実際の変換が最も可能性の高い変換でない場合、追加のシンタックス要素は、（最も可能性の高い変換以外の）どの変換がブロックをコード化するために使用される実際の変換であるかをシグナリングすることができる。
【０００６】
一例では、ビデオデータをコード化する方法は、ビデオデータのブロックのためのイントラ予測モードを決定することと、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別することであって、最も可能性の高い変換が非正方形の変換である、識別することと、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することとを含む。
【０００７】
別の例では、ビデオコーディングデバイスは、ビデオデータのブロックのためのイントラ予測モードを決定することと、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別することであって、最も可能性の高い変換が非正方形の変換である、識別することと、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することとを行うように構成されたビデオコーダを含む。
【０００８】
別の例では、ビデオコーディングのためのデバイスは、ビデオデータのブロックのためのイントラ予測モードを決定するための手段と、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別するための手段であって、最も可能性の高い変換が非正方形の変換である、手段と、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するための手段とを含む。
【０００９】
別の例では、コンピュータ可読記憶媒体は、１つまたは複数のプロセッサに、ビデオデータのブロックのためのイントラ予測モードを決定することと、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて最も可能性の高い変換を識別することであって、最も可能性の高い変換が非正方形の変換である、識別することと、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することとを行わせるように動作可能な命令を記憶する。
【００１０】
１つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１１】
【図１】本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２Ａ】最大コーディングユニット（ＬＣＵ：largest coding unit）に適用される４分木区分の一例を示す概念図。
【図２Ｂ】最大コーディングユニット（ＬＣＵ）に適用される４分木区分の一例を示す概念図。
【図３】４分木区分の一例を示す概念図。
【図４Ａ】正方形の変換ユニット区分の概念図。
【図４Ｂ】正方形の変換ユニット区分の概念図。
【図５Ａ】非正方形の変換ユニット区分の概念図。
【図５Ｂ】非正方形の変換ユニット区分の概念図。
【図６】本開示で説明する技法を実装し得るビデオエンコーダの一例を示すブロック図。
【図７】イントラ予測モードおよび方向の一例を示す図。
【図８】符号化ビデオシーケンスを復号するビデオデコーダの一例を示すブロック図。
【図９】本開示の技法による変換をシグナリングするための例示的な方法を示すフローチャート。
【発明を実施するための形態】
【００１２】
ビデオコーダは、空間的および時間的冗長性を利用することによってビデオデータを圧縮する。たとえば、ビデオコーダは、同じピクチャの前にコード化された隣接するブロックに対して現在のブロックを予測することによって空間的冗長性を利用し得る。同じピクチャの前にコード化された隣接するブロックに対して現在のブロックを予測することは、イントラ予測またはイントラモードと呼ばれることがある。同様に、ビデオコーダは、前にコード化されたピクチャのデータに対して現在のブロックを予測することによって時間的冗長性を利用し得る。前にコード化されたフレームのブロックに対して現在のブロックを予測することは、インター予測またはインターモードと呼ばれることがある。イントラ予測とインター予測の両方で、ビデオコーダは、すでにコード化されたブロックから現在のブロックを予測し、次いで、ブロックの実効値とブロックの予測値との間の差として、ブロックの残差データを計算する。
【００１３】
以下でより詳細に説明するように、１組の残差値は、変換され、走査され、量子化されて、１組の変換係数が定義され得る。変換係数を含むデータ構造は、一般に変換ユニット（ＴＵ）と呼ばれる。符号化されたビデオデータを送信し、再構成するために、様々な形状およびサイズのＴＵが使用され得る。本開示は、ビデオデータの特定のブロックのために使用されるＴＵのサイズを、符号化されたビットストリームでシグナリングするための技法を記述する。より詳細には、本開示は、変換サイズをシグナリングすることに関連付けられたビットのオーバーヘッドを低減することができる、イントラ予測モードと変換サイズとの間の相関を利用するための技法を記述する。
【００１４】
以下でより詳細に説明するように、新興のＨＥＶＣ規格は、ビデオブロックのための４分木スタイルのＴＵパーティション構造を可能にする。４分木分解を使用すると、大きい正方形のブロックが４つの小さい正方形のブロックに分割され得る。４つの小さい正方形のブロックの各々は、さらに小さい４つのブロックに各々分割され得るなど、最も小さいブロックサイズに達するまで、分割され得る。レベル１の分解では、変換ブロック全体が、４分の１サイズの４つのブロックに分割される。レベル２で、４分の１サイズの４つの変換ブロックのうちの１つまたは複数は、１／１６サイズの４つの変換ブロックにさらに分割される。レベル３で、１／１６サイズの変換ブロックのうちの１つまたは複数は、４つのさらに小さい変換ブロックにさらに分割される。変換ブロックがさらに分割されることを必要とするかどうかは、たとえば、ビデオデータの符号化の一部として決定されるレートひずみ最適化計算に基づいて決定され得る。レベル０のＴＵは、コーディングユニット全体がさらなる分割なしで一緒に変換されることを意味する。そのような場合、ＴＵは、コーディングユニットと同じサイズを有する。
【００１５】
イントラ予測されたブロックのために非正方形の変換を使用することが提案されている。そのような場合、ＴＵは、矩形形状を有することができる。２Ｎｘ２Ｎが正方形の変換を示すと仮定する。したがって、非正方形の変換は、ｈＮｘ２Ｎおよび２ＮｘｈＮと表され得、そこで、ｈＮは、Ｎの値の半分を表し、２Ｎは、Ｎの値の２倍を表す。したがって、２Ｎｘ２ＮのＴＵは、４つの垂直変換（すなわち４つのｈＮｘ２Ｎ変換）または４つの水平変換（すなわち４つの２ＮｘｈＮ変換）に分割され得る。現在の技法の一例では、ビデオエンコーダは、まず、正方形の変換（すなわちＮｘＮ）が使用されるかどうかをビデオデコーダにシグナリングするためのフラグ（ＮＳ＿Ｆｌａｇ）を、符号化されたビットストリームでシグナリングすることができ、たとえば、０に設定されたＮＳ＿Ｆｌａｇは、変換ＮｘＮが選択されることをシグナリングし、１に設定されたＮＳ＿Ｆｌａｇは、２つの非正方形の変換（ｈＮｘ２Ｎおよび２ＮｘｈＮ）のうちの１つが選択されることをシグナリングする。２つの非正方形の変換のうちの１つが選択される（すなわちＮＳ＿Ｆｌａｇ＝１）場合、追加のフラグ（ＮＳ＿Ｄｉｒ）が送信されることを必要する場合があり、たとえば、０に設定されたＮＳ＿Ｄｉｒは、変換サイズｈＮｘ２Ｎが選択されることを示し、１に設定されたＮＳ＿Ｄｉｒは、変換サイズ２ＮｘｈＮが選択されることを示す。
【００１６】
上記で説明したシグナリング方法によれば、ＮｘＮ変換が選択されるとき、１つのフラグが使用され、非正方形の変換ｈＮｘ２Ｎまたは２ＮｘｈＮが選択されるとき、２つのフラグが使用される。ＮｘＮ変換のために最少のシグナリングビット（この例では１つのフラグ）が使用されるので、ＮｘＮが最も可能性の高い変換であるとき、このシグナリング技法は、ビットの節約をもたらし得る。しかしながら、いくつかの例では、可能性が最も高い変換は、ＮｘＮ変換とは対照的に、非正方形の変換であり得る。たとえば、ビデオデータの特定のブロックについての可能性が最も高い変換が正方形の変換であるか非正方形の変換であるかは、ブロックをコード化するために使用されるイントラ予測モードに依存し得る。本開示の技法によれば、あるブロックの最も可能性の高い変換サイズが非正方形の変換であるとき、ビデオエンコーダは、最も可能性の高い変換がブロックをコード化するために使用される実際の変換であるかどうかを示すフラグを、符号化されたビットストリームでシグナリングすることができる。したがって、非正方形の変換が最も可能性の高い変換であるとき、上記で説明した２つのフラグと対照的に、非正方形の変換をシグナリングするために１つのフラグを使用することによって、ビットの節約が達成され得る。したがって、本開示の技法は、いくつかの例では、最も可能性の高い変換のために最少のシグナリングビットを使用することによって、変換シグナリング方法を向上させる。
【００１７】
一例では、ビデオエンコーダは、上記で説明したように、まず、コーディングユニットのためにイントラ予測モードを選択し、次いで、変換を選択することができる。各イントラ予測モードｋは、関連する最も可能性の高い変換（ＭＰＴ）を有することができ、これは、たとえば、ＮｘＮ、ｈＮｘ２Ｎ、または２ＮｘｈＮのうちの１つであり得る。ビデオエンコーダは、現在のイントラ予測モードｋについて、選択された変換がＭＰＴ（ｋ）であるかどうかをシグナリングするために、符号化されたビットストリームに含めるためのフラグ（ＭＰＴ＿Ｆｌａｇ）を生成することができる。たとえば、１に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）であることを意味し、一方、０に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）ではないことを意味することができる。ＭＰＴ＿Ｆｌａｇが０に設定される例では、余分のフラグ（ＭＰＴ＿ＲｅｓＭｏｄｅ）は、他の２つの変換のうちのどちらが選択されるかをシグナリングするために送信され得る。
【００１８】
一例として、現在の予測ブロックのためのイントラ予測モードがモード１であり、ｈＮｘ２Ｎがこのイントラ予測モードに関連付けられたＭＰＴである、すなわちｈＮｘ２Ｎ＝ＭＰＴ（１）と仮定する。選択されたイントラ予測モードがｈＮｘ２Ｎである場合、１に設定されたＭＰＴ＿Ｆｌａｇは、変換をシグナリングするために必要な任意の他の追加のビットなしに、符号化されたビットストリームでシグナリングされ得る。選択されたイントラ予測モードがＮｘＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇがシグナリングされ得、０に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。選択されたイントラ予測モードが２ＮｘｈＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇがシグナリングされ得、１に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。
【００１９】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、あらかじめ定義され、ビデオエンコーダとビデオデコーダの両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、ビデオエンコーダによって決定され、たとえばシーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、適応パラメータセット（ＡＰＳ）など、高レベルのシンタックスを使用して、符号化されたビットストリームでシグナリングされ得る。さらに他の例では、ＭＰＴとイントラ予測モードｋとの間のマッピング、ＭＰＴ（ｋ）は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、ＭＰＴ（ｋ）は異なり得る。同様に、ＭＰＴ（ｋ）は、たとえばＱＰ、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【００２０】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードｋのすべてのブロックについて、変換ＮｘＮが最も頻繁に行われる変換である場合、ＭＰＴ（ｋ）は、現在のブロックの符号化のために、ＮｘＮ変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダとビデオデコーダの両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、符号化されたビットストリームにおいてマッピングが明示的にシグナリングされることなく、ビデオエンコーダとビデオデコーダとの両方で動的に調整され得る。
【００２１】
図１は、本開示で説明する変換サイズをシグナリングするための技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示すように、システム１０は、通信チャネル１６を介して符号化ビデオを宛先デバイス１４に送信するソースデバイス１２を含む。ソースデバイス１２および宛先デバイス１４は、広範囲のデバイスのいずれかを備えることができる。場合によっては、ソースデバイス１２および宛先デバイス１４は、いわゆるセルラー電話または衛星無線電話のワイヤレスハンドセットなどのワイヤレス通信デバイス、または通信チャネル１６を介してビデオ情報を通信することができ、その場合、通信チャネル１６がワイヤレスである任意のワイヤレスデバイスを備え得る。
【００２２】
ただし、ビデオデータのブロックについての変換サイズを表すシンタックスデータのコード化に関係する本開示の技法は、必ずしもワイヤレスアプリケーションまたは設定に限定されるとは限らない。たとえば、これらの技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、インターネットビデオ送信、記憶媒体上に符号化される符号化デジタルビデオ、または他のシナリオに適用し得る。したがって、通信チャネル１６は、符号化ビデオデータの送信に好適なワイヤレスまたはワイヤード媒体の任意の組合せを備え得る。その上、通信チャネル１６は、ビデオ符号化デバイスがビデオ復号デバイスにデータを送信し得る多くの方法のうちのただ１つを表すためのものである。たとえば、システム１０の他の構成では、ソースデバイス１２は、宛先デバイス１４による復号のために符号化ビデオを生成し、必要に応じて、符号化ビデオが宛先デバイス１４によってアクセスできるように、記憶媒体またはファイルサーバ上に符号化ビデオを記憶し得る。
【００２３】
図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、変調器／復調器（モデム）２２と、送信機２４とを含む。宛先デバイス１４は、受信機２６と、モデム２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、ビデオデータのブロックについてのイントラ予測モードを表すシンタックスデータをコード化するための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【００２４】
図１の図示のシステム１０は一例にすぎない。ビデオデータのブロックについての選択された変換を表すシンタックスデータのコード化のための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。概して、本開示の技法はビデオコード化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコード化されたビデオデータを発生するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４の各々がビデオ符号化構成要素および復号構成要素を含むので、デバイス１２、１４は、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話通信のためのビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートすることができる。
【００２５】
ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからのビデオフィードを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き携帯電話またはビデオ電話を形成することができる。ただし、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能であり、ワイヤレスおよび／またはワイヤードアプリケーションに適用可能であり得る。各場合において、キャプチャされたビデオ、以前にキャプチャされたビデオまたはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。次いで、符号化ビデオ情報は、通信規格に従ってモデム２２によって変調され、送信機２４を介して宛先デバイス１４に送信され得る。モデム２２は、信号変調のために設計された様々なミキサ、フィルタ、増幅器または他の構成要素を含むことができる。送信機２４は、増幅器、フィルタ、および１つまたは複数のアンテナを含む、データを送信するために設計された回路を含むことができる。
【００２６】
宛先デバイス１４の受信機２６はチャネル１６を介して情報を受信し、モデム２８は情報を復調する。この場合も、ビデオ符号化プロセスは、ビデオデータのブロックについてのイントラ予測モードを表すシンタックスデータをコード化するために、本明細書で説明する技法のうちの１つまたは複数を実施することができる。チャネル１６を介して通信される情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、マクロブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００２７】
図１の例では、通信チャネル１６は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。通信チャネル１６は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信チャネル１６は、概して、ワイヤード媒体またはワイヤレス媒体の任意の好適な組合せを含む、ビデオデータをソースデバイス１２から宛先デバイス１４に送信するのに好適な任意の通信媒体、または様々な通信媒体の集合体を表す。通信チャネル１６は、ソースデバイス１２から宛先デバイス１４への通信を可能にするのに有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【００２８】
ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ  １０、Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格など、ビデオ圧縮規格に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびデコーダと統合され得、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットはＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。
【００２９】
ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｔｅａｍ（ＪＶＴ）として知られる共同パートナーシップの成果として、ＩＳＯ／ＩＥＣ  Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）とともにＩＴＵ−Ｔ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＶＣＥＧ）によって策定された。いくつかの態様では、本開示で説明する技法は、一般にＨ．２６４規格に準拠するデバイスに適用することができる。Ｈ．２６４規格は、ＩＴＵ−Ｔ研究グループによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４「Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ」に記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ぶ。Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｔｅａｍ（ＪＶＴ）はＨ．２６４／ＭＰＥＧ−４  ＡＶＣへの拡張に取り組み続けている。
【００３０】
ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合エンコーダ／デコーダ（コーデック）の一部としてそれぞれのカメラ、コンピュータ、モバイルデバイス、加入者デバイス、ブロードキャストデバイス、セットトップボックス、サーバなどに統合され得る。
【００３１】
ビデオシーケンスは、一般に一連のビデオフレームを含む。ピクチャのグループ（ＧＯＰ）は、概して、一連の１つまたは複数のビデオフレームを備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのフレームを記述するシンタックスデータを、ＧＯＰのヘッダ中、ＧＯＰの１つまたは複数のフレームのヘッダ中、または他の場所に含み得る。各フレームは、それぞれのフレームのための符号化モードを記述するフレームシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために、個々のビデオフレーム内のビデオブロックに対して動作する。ビデオブロックは、マクロブロックまたはマクロブロックのパーティションに対応し得る。ビデオブロックは、サイズを固定することも変更することもでき、指定のコーディング規格に応じてサイズが異なることがある。各ビデオフレームは複数のスライスを含み得る。各スライスは複数のマクロブロックを含み得、それらはサブブロックとも呼ばれるパーティションに配置され得る。
【００３２】
一例として、ＩＴＵ−Ｔ  Ｈ．２６４規格は、ルーマ成分については１６×１６、８×８、または４×４、およびクロマ成分については８×８など、様々なブロックサイズのイントラ予測をサポートし、ならびにルーマ成分については１６×１６、１６×８、８×１６、８×８、８×４、４×８および４×４、ならびにクロマ成分については対応するスケーリングされたサイズなど、様々なブロックサイズのインター予測をサポートする。本開示では、「Ｎ×（x）Ｎ」と「Ｎ×（by）Ｎ」は、垂直寸法および水平寸法に関するブロックのピクセル寸法、たとえば、１６×（x）１６ピクセルまたは１６×（by）１６ピクセルを指すために互換的に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、Ｎは、非負整数値を表す。ブロック中のピクセルは行と列に構成され得る。さらに、ブロックは、必ずしも、水平方向に垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックは、Ｎ×Ｍピクセルを備え得、Ｍは必ずしもＮに等しいとは限らない。１６×１６未満のブロックサイズは、ＩＴＵ−Ｔ  Ｈ．２６４では１６×１６のマクロブロックのパーティションと呼ばれ得る。
【００３３】
ビデオブロックは、ピクセル領域中のピクセルデータのブロックを備え得、あるいは、たとえば、コード化ビデオブロックと予測ビデオブロックとのピクセル差分を表す残差ビデオブロックデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換などの変換の適用後の、変換領域中の変換係数のブロックを備え得る。場合によっては、ビデオブロックは、変換領域中の量子化変換係数のブロックを備え得る。
【００３４】
小さいビデオブロックほど、より良い解像度が得られ、高い詳細レベルを含むビデオフレームのロケーションのために使用され得る。一般に、マクロブロック、およびサブブロックと呼ばれることがある様々なパーティションは、ビデオブロックと見なされ得る。さらに、スライスは、マクロブロックおよび／またはサブブロックなど、複数のビデオブロックであると見なされ得る。各スライスはビデオフレームの単独で復号可能なユニットであり得る。代替的に、フレーム自体が復号可能なユニットであり得るか、またはフレームの他の部分が復号可能なユニットとして定義され得る。
【００３５】
たとえば高効率ビデオコーディング（ＨＥＶＣ）規格など、新しいビデオコーディング規格が開発されている。新興のＨＥＶＣ規格はＨ．２６５と呼ばれることもあり得る。この規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ：HEVC Test Model）と呼ばれるビデオコーディングデバイスのモデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣによるデバイスに勝るビデオコーディングデバイスのいくつかの能力を仮定する。たとえば、Ｈ．２６４が９つのイントラ予測モードを提供するのに対して、ＨＭは、たとえば、イントラ予測コード化されるブロックのサイズに基づいて、３３ものイントラ予測モードを提供する。「ＨＥＶＣ  Ｗｏｒｋｉｎｇ  Ｄｒａｆｔ  ８」または「ＷＤ８」と呼ばれるＨＥＶＣ規格の最近のドラフトは、２０１２年１０月３日現在、http://phenix.int-evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J1003-v8.zipからダウンロード可能である、ドキュメントＪＣＴＶＣ−Ｊ１００３、Ｂｒｏｓｓら、「High efficiency video coding (HEVC) text specification draft 8」、Ｊｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  （ＪＣＴ−ＶＣ）  ｏｆ  ＩＴＵ−Ｔ  ＳＧ１６  ＷＰ３  ａｎｄ  ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１，  １０ｔｈ  Ｍｅｅｔｉｎｇ：  Ｓｔｏｃｋｈｏｌｍ，  ＳＥ  １１−２０  Ｊｕｌｙ  ２０１２に記載されている。
【００３６】
ＨＭは、ビデオデータのブロックをコーディングユニット（ＣＵ）と称する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大のコーディングユニットである最大コーディングユニット（ＬＣＵ：largest coding unit）を定義し得る。概して、ＣＵは、ＣＵがサイズの差異を有しないことを除いて、Ｈ．２６４のマクロブロックと同様の目的を有する。したがって、ＣＵは、サブＣＵに分割され得る。概して、本開示におけるＣＵへの言及は、ピクチャの最大コーディングユニットまたはＬＣＵのサブＣＵを指すことがある。ＬＣＵはサブＣＵに分割され得、各サブＣＵはサブＣＵに分割され得る。ビットストリームのシンタックスデータは、ＣＵ深さと呼ばれる、ＬＣＵが分割され得る最大回数を定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ：smallest coding unit）をも定義し得る。本開示ではまた、ＣＵ、予測ユニット（ＰＵ：prediction unit）、またはＴＵのいずれかを指すために「ブロック」という用語を使用する。
【００３７】
ＬＣＵは４分木データ構造に関連付けられ得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはＬＣＵに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。
【００３８】
分割されないＣＵは、１つまたは複数の予測ユニット（ＰＵ：prediction unit）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分を表し、そのＰＵの参照サンプルを取り出すためのデータを含む。たとえば、ＰＵがイントラ予測モード符号化されるとき、ＰＵは、そのＰＵのためのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵの動きベクトルを定義するデータを含み得る。動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照フレーム、および／または動きベクトルの参照リスト（たとえば、リスト０もしくはリスト１）を記述し得る。また、（１つまたは複数の）ＰＵを定義するＣＵについてのデータは、たとえば、１つまたは複数のＰＵへのＣＵの区分について記述し得る。区分モードは、ＣＵがコーディングされないか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかとの間で異なり得る。
【００３９】
１つまたは複数のＰＵを有するＣＵは、１つまたは複数のＴＵをも含み得る。ＰＵを使用した予測の後に、ビデオエンコーダは、ＰＵに対応するＣＵの部分の残差値を計算し得る。１組の残差値は、変換され、走査され、量子化されて、１組の変換係数が定義され得る。ＴＵは、変換係数を含むデータ構造を定義する。ＴＵは、必ずしもＰＵのサイズまたは形状に制限されるとは限らない。したがって、ＴＵは、同じＣＵについての対応するＰＵよりも大きくてもよく、またはより小さくてもよく、ＴＵは、正方形または非正方形のいずれかであり得る。いくつかの例では、ＴＵの最大サイズは、対応するＣＵのサイズに対応し得る。
【００４０】
図２Ａおよび図２Ｂは、例示的な４分木２５０と、対応するＬＣＵ２７２とを示す概念図である。図２Ａは、階層式に構成されたノードを含む、例示的な４分木２５０を示している。４分木２５０など、４分木中の各ノードは、子をもたないリーフノードであるか、または４つの子ノードを有し得る。図２Ａの例では、４分木２５０はルートノード２５２を含む。ルートノード２５２は、リーフノード２５６Ａ〜２５６Ｃ（リーフノード２５６）とノード２５４とを含む、４つの子ノードを有する。ノード２５４はリーフノードでないので、ノード２５４は、この例ではリーフノード２５８Ａ〜２５８Ｄ（リーフノード２５８）である、４つの子ノードを含む。
【００４１】
４分木２５０は、この例ではＬＣＵ２７２など、対応するＬＣＵの特性を記述するデータを含み得る。たとえば、４分木２５０は、それの構造により、サブＣＵへのＬＣＵの分割を記述し得る。ＬＣＵ２７２が２Ｎ×２Ｎのサイズを有すると仮定する。ＬＣＵ２７２は、この例では、４つのサブＣＵ２７６Ａ〜２７６Ｃ（サブＣＵ２７６）および２７４を有し、各々はＮ×Ｎサイズである。サブＣＵ２７４はさらに４つのサブＣＵ２７８Ａ〜２７８Ｄ（サブＣＵ２７８）に分割され、各々はサイズＮ／２×Ｎ／２である。この例では、４分木２５０の構造はＬＣＵ２７２の分割に対応する。すなわち、ルートノード２５２はＬＣＵ２７２に対応し、リーフノード２５６はサブＣＵ２７６に対応し、ノード２５４はサブＣＵ２７４に対応し、リーフノード２５８はサブＣＵ２７８に対応する。
【００４２】
４分木２５０のノードのデータは、ノードに対応するＣＵが分割されるかどうかを記述し得る。ＣＵが分割される場合、４分木２５０中に４つの追加のノードが存在し得る。いくつかの例では、４分木のノードは以下の擬似コードと同様に実装され得る。
【数１】
0005996661.tif 000002
【００４３】
ｓｐｌｉｔ＿ｆｌａｇ値は、現在のノードに対応するＣＵが分割されるかどうかを表す１ビット値であり得る。ＣＵが分割されない場合、ｓｐｌｉｔ＿ｆｌａｇ値は「０」であり得るが、ＣＵが分割される場合、ｓｐｌｉｔ＿ｆｌａｇ値は「１」であり得る。４分木２５０の例に関して、分割フラグ値のアレイは１０１００００００であり得る。
【００４４】
いくつかの例では、サブＣＵ２７６およびサブＣＵ２７８の各々は、同じイントラ予測モードを使用してイントラ予測符号化され得る。したがって、ビデオエンコーダ１２２は、ルートノード２５２においてイントラ予測モードの指示を与え得る。その上、サブＣＵのいくつかのサイズは、特定のイントラ予測モードのために複数の可能な変換を有し得る。ビデオエンコーダ１２２は、ルートノード２５２においてそのようなサブＣＵのために使用すべき変換の指示を与え得る。たとえば、サイズＮ／２×Ｎ／２のサブＣＵでは複数の可能な変換が利用可能であり得る。ビデオエンコーダ１２２は、ルートノード２５２において使用すべき変換をシグナリングし得る。したがって、ビデオデコーダ１２８は、ルートノード２５２においてシグナリングされたイントラ予測モードと、ルートノード２５２においてシグナリングされた変換とに基づいてサブＣＵ２７８に適用すべき変換を判断し得る。
【００４５】
したがって、ビデオエンコーダ１２２は、本開示の技法によれば、リーフノード２５６およびリーフノード２５８においてサブＣＵ２７６およびサブＣＵ２７８に適用すべき変換をシグナリングする必要はないが、代わりに、単に、ルートノード２５２において、イントラ予測モードと、いくつかの例では、いくつかのサイズのサブＣＵに適用すべき変換とをシグナリングし得る。このようにして、これらの技法は、ＬＣＵ２７２など、ＬＣＵのサブＣＵごとに変換機能をシグナリングするオーバーヘッドコストを低減し得る。
【００４６】
いくつかの例では、サブＣＵ２７６および／またはサブＣＵ２７８のイントラ予測モードは、ＬＣＵ２７２のイントラ予測モードとは異なり得る。ビデオエンコーダ１２２およびビデオデコーダ１３０は、ルートノード２５２においてシグナリングされるイントラ予測モードを、サブＣＵ２７６および／またはサブＣＵ２７８のために利用可能なイントラ予測モードにマッピングする機能を用いて構成され得る。この機能は、ＬＣＵ２７２のために利用可能なイントラ予測モードとサブＣＵ２７６および／またはサブＣＵ２７８のイントラ予測モードとの多対１のマッピングを与え得る。
【００４７】
上記で紹介されたように、図３は、４分木スタイルのＴＵパーティション構造の一例を示す。新興のＨＥＶＣ規格は、４分木スタイルのＴＵパーティション構造を可能にする。図３に示すように、たとえば、実線によるブロック３００全体は、元のコーディングユニットを表す。点線は、４分木構造による変換ブロック分解の１つの例示的な結果を示す。当然、そのような結果は、多くの考えられる分解の中のうちのただ１つである。図３の例では、３つのレベルの変換分解がある。レベル１の分解では、変換ブロック全体が、４分の１サイズの４つのブロック（図３のブロック３２２、３２４、３２６、および３２８）に分割される。レベル２で、第２の４分の１サイズの変換ブロックは、１／１６サイズの４つの変換ブロック（図３のブロック３３２、３３４、３３６、および３３８）にさらに分割される。レベル３で、１／１６サイズの４つの変換ブロック（ブロック３３６）は、さらに小さい４つの変換ブロック（ブロック３４２、３４４、３４６、および３４８）にさらに分割される。変換ブロックがさらに分割されることを必要とするかどうかは、たとえば、レートひずみ最適化に基づいて決定され得る。図３に示される例は、４分木分解構造と呼ばれており、その場合、１つのブロックは分割されない、または４分の１サイズの４つのブロックに分割される。レベル０のＴＵは、コーディングユニット全体がさらなる分割なしで一緒に変換されることを意味する。そのような場合、ＴＵは、コーディングユニットと同じサイズを有する。
【００４８】
イントラ予測されたブロックでは、いくつかのコーディング方法によれば、正方形のＴＵ（たとえば図３に示されるＴＵなど）のみが許容される。さらに、いくつかのコーディング方法によれば、ＴＵは、イントラ予測されたブロックについての予測ユニットと常に整合される。例が図４Ａおよび図４Ｂに示される。図４Ａの例では、１つのブロックが４分の１のサイズの４つのブロックに区分される。図４Ｂの例では、第２の４分の１のサイズのブロックが、１／１６の元のブロックサイズのサイズを有するより小さい４つのブロックにさらに区分される。ＨＥＶＣの現在の実装に基づいて、図６Ａおよび図６Ｂに示される各ブロックは、予測され、変換され、別々に再構成され得る。変換ブロック（またはＴＵ）サイズは、予測ブロック（または予測ユニット）サイズと同じでもよい。
【００４９】
図５Ａおよび図５Ｂは、イントラ予測されたブロックに使用され得る非正方形の変換の例を示す。そのような場合、ＴＵは、矩形形状を有することができる。図５Ａおよび図５Ｂの例は、上記で説明した正方形の変換に加えて、可能であり得る。言い換えれば、所与のブロックについて、図４Ａおよび図４Ｂと、図５Ａおよび図５Ｂの両方に示される例が使用され得る。たとえば、分解レベル１で、１つのブロックは、図４Ａに示される変換区分を選択することができる。ブロックは、図５Ａおよび図５Ｂに示される変換区分を選択することもできる。ビデオエンコーダ２０で、これらの３つの異なる予測およびＴＵ区分のすべてがテストされ得、選択されたパーティションユニットおよびＴＵは、ビデオデコーダ３０にシグナリングされる。
【００５０】
ＮｘＮは、図４Ａに示される変換を示し、ｈＮｘ２Ｎは、図５Ａに示される変換を示し、２ＮｘｈＮは、図５Ｂに示される変換を示すと仮定する。一例では、ビデオエンコーダ２０は、まず、正方形の変換、ＮｘＮが使用されるかどうかをビデオデコーダ３０にシグナリングするためにフラグ（ＮＳ＿Ｆｌａｇ）をシグナリングすることができ、０に設定されたＮＳ＿Ｆｌａｇは、変換ＮｘＮが選択されることをシグナリングし、１に設定されたＮＳ＿Ｆｌａｇは、２つの非正方形の変換（ｈＮｘ２Ｎおよび２ＮｘｈＮ）のうちの１つが選択されることをシグナリングする。２つの非正方形の変換のうちの１つが選択される（すなわちＮＳ＿Ｆｌａｇ＝１）場合、追加のフラグ（ＮＳ＿Ｄｉｒ）がシグナリングされることを必要する場合があり、０に設定されたＮＳ＿Ｄｉｒは、変換ｈＮｘ２Ｎが選択されることを示し、１に設定されたＮＳ＿Ｄｉｒは、２ＮｘｈＮが選択されることを示す。このようにして、正方形の変換に加えて、非正方形の変換を可能にすることは、コーディング効率を向上させることができる。
【００５１】
上記で説明したシグナリング方法によれば、ＮｘＮ変換が選択されるとき、１つのフラグが使用され、非正方形の変換ｈＮｘ２Ｎまたは２ＮｘｈＮが選択されるとき、２つのフラグが使用される。最も頻繁に行われる変換モードのために最少のシグナリングビット（この例では１つのフラグ）が使用されるので、イントラ予測コーディングにおいてＮｘＮが最も可能性の高い変換であるとき、このシグナリング技法は、ビットの節約をもたらし得る。しかしながら、いくつかの例では、異なるイントラ予測方向（たとえば図４に示される３５個のイントラ予測方向モード）についての最も可能性の高い変換は、異なり得る。本開示の技法によれば、非正方形の変換が最も可能性の高い変換であるとき、上記で説明した２つのフラグと対照的に、非正方形の変換をシグナリングするために１つのフラグを使用することによって、ビットの節約が達成され得る。したがって、本開示の技法は、いくつかの例では、最も可能性の高い変換のために最少のシグナリングビットを使用することによって、変換シグナリング方法を向上させる。
【００５２】
本開示の技法によれば、ビデオエンコーダ２０は、イントラ予測モード符号化を使用して、ビデオデータのいくつかのブロックを符号化することができ、ブロックを符号化するために使用される選択されたイントラ予測モードを示す情報を提供することができる。ビデオエンコーダ２０は、ＰフレームまたはＰスライス、およびＢフレームまたはＢスライスに加えて、たとえば、ＩフレームまたはＩスライスなど、イントラ予測モードを使用して、任意のタイプのフレームまたはスライスのブロックをイントラ予測符号化することができる。あるブロックがイントラ予測モード符号化されるべきであることをビデオエンコーダ２０が決定したとき、ビデオエンコーダ２０は、最も適切なイントラ予測モードを選択するためにレートひずみ分析を実行することができる。たとえば、ビデオエンコーダ２０は、１つまたは複数のイントラ予測モードについてのレートひずみ値を計算し、受容できるレートひずみ特性を有するモードのうちの１つを選択することができる。
【００５３】
ビデオエンコーダ２０は、ブロックの符号化コンテキストを決定するように構成することもできる。コンテキストは、たとえば、ピクセル寸法で決定され得るブロックのサイズ、たとえばＨＥＶＣの例における２Ｎ×２Ｎ、Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×Ｎなどの予測ユニット（ＰＵ）タイプ、２Ｎ×Ｎ／２、Ｎ／２×２Ｎ、２Ｎ×１、１×２Ｎなどの短距離イントラ予測（ＳＤＩＰ）タイプ、Ｈ．２６４の例におけるマクロブロックタイプ、ブロックについてのコーディングユニット（ＣＵ）深さ、またはビデオデータのブロックについてのサイズの他の測定値など、ブロックの様々な特性を含むことができる。いくつかの例では、コンテキストは、上に隣接するブロック、左に隣接するブロック、左上に隣接するブロック、右上に隣接するブロック、または他の隣接するブロックについてのイントラ予測モードの方法のいずれかまたはすべてに対応することができる。いくつかの例では、コンテキストは、１つまたは複数のブロックについてのイントラ予測モードと、符号化されている現在のブロックのサイズ情報の両方を含むことができる。ブロックについてのコンテキスト情報を提供することができる隣接ブロックまたは他のデータからのデータに基づいて、他のコンテキストがあるブロックのために定義される、または使用され得る。
【００５４】
いずれの場合にも、ビデオエンコーダ２０は、ブロックのコンテキストを現在のブロックについての様々なコーディング特性にマッピングする構成データを含み得る。たとえば、ブロックのコンテキストに基づいて、構成データは、１つまたは複数の最も可能性の高いイントラ予測モードを示し得る。ビデオエンコーダ２０は、いくつかの例では、コンテキストに基づいて、最も可能性の高いモードでイントラ予測モードの選択のための分析を開始するように構成され得る。最も可能性の高いモードが適切なレートひずみ特性を達成するとき、いくつかの例では、ビデオエンコーダ２０は、最も可能性の高いモードを選択することができる。他の例では、ビデオエンコーダ２０は、最も可能性の高いモードで選択プロセスを開始する必要はない。
【００５５】
予測データと残差データとを生成するためのイントラ予測コーディングまたはインター予測コーディングの後、および変換係数を生成するための（Ｈ．２６４／ＡＶＣで使用される４×４または８×８整数変換、あるいは離散コサイン変換ＤＣＴなどの）任意の変換の後、変換係数の量子化が実行され得る。量子化は、概して、係数を表すために使用されるデータ量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減することができる。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、ｎはｍよりも大きい。
【００５６】
量子化の後に、たとえば、コンテンツ適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、または別のエントロピーコーディング方法に従って、量子化データのエントロピーコーディングが実行され得る。エントロピーコーディング用に構成された処理ユニットまたは別の処理ユニットは、量子化係数のゼロランレングスコーディング、および／またはコード化ブロックパターン（ＣＢＰ）値、マクロブロックタイプ、コーディングモード、（フレーム、スライス、マクロブロック、またはシーケンスなどの）コード化ユニットの最大マクロブロックサイズなどのシンタックス情報の生成など、他の処理機能を実行し得る。
【００５７】
ビデオデコーダ３０は、最終的に、たとえば、モデム２８および受信機２６から符号化ビデオデータを受信することができる。本開示の技法によれば、ビデオデコーダ３０は、ビデオデータのブロックを符号化するために使用されるイントラ予測モードを表す符号化データを受信することができる。ビデオデコーダ３０は、ビデオエンコーダ２０と実質的に同様の方法でブロックについてのコーディングコンテキストを決定するように構成することができる。その上、ビデオデコーダ３０は、たとえば、最も可能性の高いモードの指示、イントラ予測モードインデックステーブル、およびコーディングコンテキストごとのＶＬＣテーブルなど、ビデオエンコーダ２０と同様の構成データを含み得る。
【００５８】
ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
【００５９】
図６は、特定のＣＵの変換を示す情報をコード化するための技法を実装し得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、マクロブロックあるいはマクロブロックのパーティションまたはサブパーティションを含むビデオフレーム内のブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレーム内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは時間的予測を利用して、ビデオシーケンスの隣接フレーム内のビデオの時間的冗長性を低減または除去する。イントラ予測モード（Ｉモード）は、いくつかの空間ベースの圧縮モードのいずれかを指し、単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指し得る。
【００６０】
図６に示されるように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図６の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測処理ユニット４６と、メモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピーコーディングユニット５６とを含む。ビデオブロックの再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換処理ユニット６０と、加算器６２とを含む。再構成されたビデオブロックをフィルタ処理するために、たとえばデブロッキングフィルタ、サンプル適応オフセットフィルタ、および／または適応ループフィルタなど、様々なループフィルタ（図６には図示せず）が含まれることもある。所望される場合、ループフィルタは、一般に、加算器６２の出力をフィルタ処理するであろう。
【００６１】
符号化プロセス中に、ビデオエンコーダ２０はコーディングされるビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間圧縮を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対する受信したビデオブロックのインター予測コーディングを実行する。イントラ予測処理ユニット４６は、空間圧縮を行うために、コーディングされるブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対する受信したビデオブロックのイントラ予測コーディングを実行し得る。
【００６２】
モード選択ユニット４０は、誤差結果に基づいて、およびコード化されている現在のブロックを含むフレームまたはスライスのフレームまたはスライスタイプに基づいて、コーディングモード、（たとえば、イントラまたはインター）のうちの１つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器５０に供給し、参照フレームまたは参照スライス中で使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器６２に供給し得る。一般に、イントラ予測は、隣接する、前にコード化されたブロックに対して現在のブロックを予測することを伴い、一方、インター予測は、現在のブロックを時間的に予測するために、動き推定および動き補償を伴う。
【００６３】
動き推定ユニット４２および動き補償ユニット４４は、ビデオエンコーダ２０のインター予測要素を表す。動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または、他のコード化ユニット）内のコーディングされている現在のブロックに対する予測参照フレーム（または、他のコード化ユニット）内の予測ブロックの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるブロックにぴったり一致することがわかるブロックである。動きベクトルはまた、マクロブロックのパーティションの変位を示し得る。動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。
【００６４】
動き推定ユニット４２は、ビデオブロックを参照フレームストア６４中の参照フレームのビデオブロックと比較することによってインターコード化フレームのビデオブロックの動きベクトルを計算する。動き補償ユニット４４はまた、参照フレーム、たとえば、ＩフレームまたはＰフレームのサブ整数ピクセルを補間し得る。ＩＴＵ  Ｈ．２６４規格は、一例として、符号化されている現在のフレームよりも前の表示順序を有する参照フレームを含むリスト０、および符号化されている現在のフレームよりも後の表示順序を有する参照フレームを含むリスト１の２つのリストを記述する。したがって、参照フレームストア６４に記憶されたデータは、これらのリストに従って編成され得る。
【００６５】
動き推定ユニット４２は、参照フレームストア６４からの１つまたは複数の参照フレームのブロックを現在のフレーム、たとえば、ＰフレームまたはＢフレームの符号化すべきブロックと比較する。参照フレームストア６４中の参照フレームがサブ整数ピクセルの値を含むとき、動き推定ユニット４２によって計算される動きベクトルは参照フレームのサブ整数ピクセルロケーションを参照し得る。動き推定ユニット４２および／または動き補償ユニット４４はまた、サブ整数ピクセル位置の値が参照フレームストア６４に記憶されていない場合、参照フレームストア６４に記憶された参照フレームのサブ整数ピクセル位置の値を計算するように構成され得る。動き推定ユニット４２は、計算された動きベクトルをエントロピーコード化ユニット５６と動き補償ユニット４４とに送る。動きベクトルによって識別される参照フレームブロックは予測ブロックと呼ばれることがある。動き補償ユニット４４は、インター予測ブロックに基づいて予測データを計算し得る。
【００６６】
イントラ予測処理ユニット４６は、上記で説明したように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測処理ユニット４６は、現在のブロックの符号化に使用するためのイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット４６は、たとえば、別々の符号化パスの間など、様々なイントラ予測モードを使用して、現在のブロックを符号化することができ、イントラ予測処理ユニット４６（または、いくつかの例において、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。たとえば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中の最良のレートひずみ特性を有するイントラ予測モードを選択することができる。レートひずみ分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（またはエラー）の量、ならびに、符号化されたブロックを生成するために使用されたビットレート（すなわち、ビット数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックについての最良のレートひずみ値を呈するかを決定するために、様々な符号化されたブロックについてのひずみおよびレートから比率を計算することができる。
【００６７】
図７は、ＨＥＶＣで使用することができるイントラ予測モードおよび対応するモードインデックスの一例を示す。図７の矢印は、予測方向を表し、数字は、モードインデックスを表す。以下の表１は、ＣＵのサイズと、ＨＥＶＣ仕様の１つの中間バージョンにおけるそのサイズのＣＵの符号化のために利用可能なイントラ予測モードの数との間の対応を示す。表１によってわかるように、８×８、１６×１６、および３２×３２のＣＵは、図４に示される３５のイントラ予測モードを使用することができ、一方、４×４および６４×６４のＣＵはより少ない組のイントラ予測モードを使用する。
【表１】
0005996661.tif 000003
【００６８】
ＨＥＶＣは、現在、３５個の異なるイントラ予測モードを許容する。これらのモードは、１つのＤＣモードと、１つの平面モードと、３３個の異なる方向性予測モードとを含む。方向性予測モードを用いて、そのモードによって示されるある方向に沿った隣接ブロックの再構成されたピクセルに基づいて予測が実行される。異なる予測モードに関連する方向を図７に示す。
【００６９】
いずれの場合も、ブロックのイントラ予測モードを選択した後に、イントラ予測処理ユニット４６は、ブロックについての選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット５６に提供し得る。エントロピーコーディングユニット５６は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。
【００７０】
たとえば、イントラ予測またはインター予測を使用して、現在のブロックを予測した後、ビデオエンコーダ２０は、コード化されている元のビデオブロックから、動き補償ユニット４４またはイントラ予測処理ユニット４６によって計算された予測データを減算することによって残差ビデオブロックを形成し得る。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、概念的にＤＣＴと同様である、Ｈ．２６４規格によって定義される変換などの他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換をも使用することができる。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。量子化ユニット５４は、ビットレートをさらに低減するために残差変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減することができる。量子化の程度は、量子化パラメータを調整することによって変更され得る。
【００７１】
一例では、予測ユニットごとに１つのイントラ予測モード（たとえば図６に示される３５個のうちの１つ）を選択した後、次いで、ビデオエンコーダ２０は、上記で説明したように、変換を選択することができる。各イントラ予測モードｋは、関連する最も可能性の高い変換ＭＰＴ（ｋ）を有することができ、それは、たとえば、ＮｘＮ、ｈＮｘ２Ｎ、または２ＮｘｈＮのうちの１つである。ビデオエンコーダ２０は、現在のイントラ予測モードｋについて、選択された変換がＭＰＴ（ｋ）であるかどうかをシグナリングするために、符号化されたビットストリームに含めるためのフラグ（ＭＰＴ＿Ｆｌａｇ）を生成することができる。たとえば、１に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）であることを示し、一方、０に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）ではないことを示すことができる。ＭＰＴ＿Ｆｌａｇが０に設定される例では、余分のフラグ（ＭＰＴ＿ＲｅｓＭｏｄｅ）は、他の２つの変換のうちのどちらが選択されるかをシグナリングするために生成され得る。
【００７２】
一例として、現在のＰＵについてのイントラ予測モードがモード１であり、ｈＮｘ２Ｎがこのイントラ予測モードに関連付けられたＭＰＴである、すなわちｈＮｘ２Ｎ＝ＭＰＴ（１）と仮定する。選択されたイントラ予測モードがｈＮｘ２Ｎである場合、１に設定されたＭＰＴ＿Ｆｌａｇは、変換をシグナリングするために必要な任意の他のビットなしに、ビデオエンコーダ２０からビデオエンコーダ３０に、符号化されたビットストリームでシグナリングされ得る。選択されたイントラ予測モードがＮｘＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇがシグナリングされ得、０に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。選択されたイントラ予測モードが２ＮｘｈＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇがシグナリングされ得、１に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。
【００７３】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、あらかじめ定義され、ビデオエンコーダ２０とビデオデコーダ３０の両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、ビデオエンコーダ２０によって決定され、たとえば（シーケンスパラメータセット）、ＰＰＳ（ピクチャパラメータセット）、ＡＰＳ（適応パラメータセット）など、高レベルのシンタックスを使用して、ビデオデコーダ３０にシグナリングされ得る。さらに他の例では、ＭＰＴとイントラ予測モードｋとの間のマッピング、ＭＰＴ（ｋ）は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、ＭＰＴ（ｋ）は異なり得る。同様に、ＭＰＴ（ｋ）は、たとえばＱＰ、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【００７４】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードｋのすべてのブロックについて、変換ＮｘＮが最も頻繁に行われる変換である場合、ＭＰＴ（ｋ）は、現在のブロックの符号化のために、ＮｘＮ変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダ２０とビデオデコーダ３０の両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、ビデオエンコーダ２０とビデオデコーダ３０との間でマッピングが明示的にシグナリングされることなく、ビデオエンコーダ２０とビデオデコーダ３０との両方で動的に調整され得る。
【００７５】
量子化の後、エントロピーコード化ユニット５６は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコード化ユニット５６は、コンテンツ適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、または別のエントロピーコーディング技法を実行し得る。エントロピーコード化ユニット５６によるエントロピーコーディングの後に、符号化されたビデオは、別のデバイスに送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。コンテキスト適応型バイナリ算術コーディングの場合、コンテキストは隣接ブロックおよび／またはブロックサイズに基づき得る。
【００７６】
場合によっては、エントロピーコード化ユニット５６またはビデオエンコーダ２０の別のユニットは、上記で説明したように、エントロピーコーディングおよびイントラ予測モードのコーディングに加えて他のコーディング機能を実行するように構成され得る。たとえば、エントロピーコード化ユニット５６はブロックのコード化ブロックパターン（ＣＢＰ：coded block pattern）値およびパーティションを判断するように構成され得る。また、場合によっては、エントロピーコード化ユニット５６は、マクロブロックまたはそれのパーティション中の係数のランレングスコーディングを実行し得る。特に、エントロピーコード化ユニット５６は、マクロブロックまたはパーティション中の変換係数をスキャンするためにジグザグスキャンまたは他のスキャンパターンを適用し、さらなる圧縮のためにゼロのランを符号化し得る。エントロピーコード化ユニット５６はまた、符号化ビデオビットストリーム中での送信のために適切なシンタックス要素を用いてヘッダ情報を構成し得る。
【００７７】
逆量子化ユニット５８および逆変換処理ユニット６０は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックを参照フレームストア６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６２は、再構成された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照フレームストア６４に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。
【００７８】
このようにして、ビデオエンコーダ２０は、ビデオデータの１つのブロックのためのイントラ予測モードを決定し、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別し、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するように構成され得るビデオエンコーダの一例を表す。最も可能性の高い変換は、非正方形の変換とすることができる。ビデオエンコーダ２０は、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを生成することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオエンコーダ２０は、最も可能性の高い変換以外の変換の指示を生成することができ、ただし、最も可能性の高い変換以外の変換は、ビデオデータのブロックを符号化するために使用される変換である。変換は、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群の変換から選択され得、ただし、Ｎは、変換の寸法のサイズを表し、ｈＮは、Ｎの値の半分を表し、２ＮはＮの値の２倍を表す。
【００７９】
ビデオエンコーダ３０は、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することもできる。マッピングは、固定される、ビデオエンコーダ２０からビデオデコーダにシグナリングされる、または、適応可能とすることができる。マッピングが適応可能である場合、マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングは、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【００８０】
図８は、符号化されたビデオシーケンスを復号するビデオデコーダ３０の一例を示すブロック図である。図５の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測処理ユニット７４と、逆量子化ユニット７６と、逆変換処理ユニット７８と、メモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図６）に関して説明した符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信した動きベクトルに基づいて予測データを生成し得る。
【００８１】
動き補償ユニット７２は、ビットストリーム中で受信した動きベクトルを使用して、参照フレームストア８２中の参照フレーム中の予測ブロックを識別し得る。イントラ予測処理ユニット７４は、ビットストリーム中で受信されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成し得る。特に、ビデオデコーダ３０は、図５の例では、構成データ８４を含む。構成データ８４が、イントラ予測されたブロックのコンテキストを記述する情報と、コンテキストごとの最も可能性の高いイントラ予測モードなどを含むという点で、構成データ８４は、図６の構成データ６６と実質的に同様である。
【００８２】
エントロピー復号ユニット７０は、ビデオデータの符号化されたブロックの復号に使用するためのイントラ予測モードを表すデータを受信することができる。エントロピー復号ユニット７０は、たとえば、符号化されたブロックの左に隣接するブロックおよび上に隣接するブロックについてのイントラ予測モード、ならびに／または符号化されたブロックについてのサイズに基づいて、符号化されたブロックのコンテキストを決定することができる。コンテキストに基づいて、エントロピー復号ユニット７０は、ブロックの復号に使用するための１つまたは複数の最も可能性の高いイントラ予測モードを決定することができる。
【００８３】
イントラ予測処理ユニット７４は、たとえば、隣接する、以前復号されたブロックのピクセルを使用して、符号化されたブロックをイントラ予測するためにイントラ予測モードの指示を使用することができる。ブロックがインター予測モード符号化される例では、動き補償ユニット７２は、符号化されたブロックについての動き補償予測データを取り出すために、動きベクトルを定義する情報を受信することができる。いずれの場合も、動き補償ユニット７２またはイントラ予測処理ユニット７４は、加算器８０に予測ブロックを定義する情報を提供することができる。
【００８４】
逆量子化ユニット７６は、ビットストリーム中で供給され、エントロピー復号ユニット７０によって復号された量子化ブロック係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、たとえば、Ｈ．２６４復号規格によって定義される、またはＨＥＶＣテストモデルによって実行されるなど、従来のプロセスを含み得る。逆量子化プロセスはまた、量子化の程度を判断し、同様に、適用する逆量子化の程度を判断するための、各マクロブロックについてエンコーダ２０によって計算される量子化パラメータＱＰYの使用を含み得る。
【００８５】
逆変換ユニット５８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用して、ピクセル領域において残差ブロックを生成する。動き補償ユニット７２は動き補償ブロックを生成し、場合によっては、補間フィルタに基づいて補間を実行する。サブピクセル精度をもつ動き推定に使用されるべき補間フィルタの識別子は、シンタックス要素中に含まれ得る。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。動き補償ユニット７２は、受信されたシンタックス情報に従って、ビデオエンコーダ２０によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。
【００８６】
動き補償ユニット７２は、シンタックス情報のいくつかを使用して、符号化ビデオシーケンスの（１つまたは複数の）フレームを符号化するために使用されるブロックのサイズと、符号化ビデオシーケンスのフレームまたはスライスの各ブロックがどのように区分されるかを記述するパーティション情報と、各パーティションがどのように符号化されるかを示すモードと、各インター符号化ブロックまたはパーティションのための１つまたは複数の参照フレーム（および参照フレームリスト）と、符号化ビデオシーケンスを復号するための他の情報とを判断する。
【００８７】
一例では、予測ユニットごとに１つのイントラ予測モード（たとえば図６に示される３５個のうちの１つ）を決定した後、次いで、ビデオデコーダ３０は、ＰＵに関連付けられたＴＵのために使用される変換サイズを決定することができる。各イントラ予測モードｋは、関連する最も可能性の高い変換ＭＰＴ（ｋ）を有することができ、それは、たとえば、ＮｘＮ、ｈＮｘ２Ｎ、または２ＮｘｈＮのうちの１つである。ビデオデコーダ３０は、現在のイントラ予測モードｋについて、選択された変換がＭＰＴ（ｋ）であるかどうかをシグナリングするために、符号化されたビットストリームでフラグ（ＭＰＴ＿Ｆｌａｇ）を受信することができる。たとえば、１に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）であることを示し、一方、０に設定されたＭＰＴ＿Ｆｌａｇは、選択された変換がＭＰＴ（ｋ）ではないことを示すことができる。ＭＰＴ＿Ｆｌａｇが０に設定される例では、余分のフラグ（ＭＰＴ＿ＲｅｓＭｏｄｅ）は、他の２つの変換のうちのどちらが選択されるかをシグナリングするために受信され得る。
【００８８】
一例として、現在のＰＵについてのイントラ予測モードがモード１であり、ｈＮｘ２Ｎがこのイントラ予測モードに関連付けられたＭＰＴである、すなわちｈＮｘ２Ｎ＝ＭＰＴ（１）と仮定する。選択されたイントラ予測モードがｈＮｘ２Ｎである場合、１に設定されたＭＰＴ＿Ｆｌａｇが符号化されたビットストリームでビデオデコーダ３０によって受信され得る。選択されたイントラ予測モードがＮｘＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇが符号化されたビットストリームでビデオデコーダ３０によって受信され得、０に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。選択されたイントラ予測モードが２ＮｘｈＮである場合、０に設定されたＭＰＴ＿Ｆｌａｇが受信され得、１に設定されたＭＰＴ＿ＲｅｓＭｏｄｅが続く。
【００８９】
いくつかの場合、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、あらかじめ定義され、ビデオエンコーダ２０とビデオデコーダ３０の両方にとって既知であり得る。他の例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、ビデオエンコーダ２０によって決定され、ＳＰＳ（シーケンスパラメータセット）、ＰＰＳ（ピクチャパラメータセット）、ＡＰＳ（適応パラメータセット）、スライスヘッダ、ブロックヘッダ、または別のタイプのシンタックスなどの中の１要素など、高レベルのシンタックスを使用して、ビデオデコーダ３０にシグナリングされ得る。さらに他の例では、ＭＰＴとイントラ予測モードｋとの間のマッピング、ＭＰＴ（ｋ）は、ブロックサイズ適応型とすることができ、異なるブロックサイズでは、イントラ予測モードが同じことであるときでさえ、ＭＰＴ（ｋ）は異なり得る。同様に、ＭＰＴ（ｋ）は、たとえばＱＰ、インター予測方向、ブロックタイプなど、他の情報に基づいて適応可能とすることもできる。
【００９０】
いくつかの例では、イントラ予測モードについての最も可能性の高い変換、ＭＰＴ（ｋ）は、いくつかのすでに符号化されたブロックの選択された変換に基づき得る。たとえば、現在のフレームにおけるすでに符号化された同じイントラ予測モードｋのすべてのブロックについて、変換ＮｘＮが最も頻繁に行われる変換である場合、ＭＰＴ（ｋ）は、現在のブロックの符号化のために、ＮｘＮ変換に設定され得る。そのような例では、そのような変換が行われる頻度は、ビデオエンコーダ２０とビデオデコーダ３０の両方によって追跡され得、したがって、イントラ予測モードに対する最も可能性の高い変換のマッピングが、ビデオエンコーダ２０とビデオデコーダ３０との間でマッピングが明示的にシグナリングされることなく、ビデオエンコーダ２０とビデオデコーダ３０との両方で動的に調整され得る。
【００９１】
加算器８０は、残差ブロックを、動き補償ユニット７２またはイントラ予測処理ユニット７４によって生成される対応する予測ブロックと合計して、復号ブロックを形成する。必要に応じて、ブロッキネスアーティファクトを除去するために、デブロッキングフィルタを適用して、復号ブロックをフィルタ処理することもできる。復号されたビデオブロックは、次いで、参照フレームストア８２に記憶され、参照フレームストア８２は、参照ブロックをその後の動き補償に供給し、また、ディスプレイデバイス（図１のディスプレイデバイス３２など）上での提示のために復号されたビデオを生成する。
【００９２】
このようにして、ビデオデコーダ３０は、ビデオデータの１つのブロックのためのイントラ予測モードを決定し、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別し、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するように構成され得るビデオデコーダの一例を表す。最も可能性の高い変換は、非正方形の変換とすることができる。ビデオデコーダ３０は、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができ、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを受信することを備える。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であることを示すフラグに応答して、ビデオデコーダ３０は、最も可能性の高い変換に基づいてビデオデータのブロックを再構成することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオデコーダ３０は、最も可能性の高い変換以外の変換の指示を受信し、最も可能性の高い変換以外の変換に基づいて、ビデオデータのブロックを再構成することができる。変換は、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群の変換から選択され得、ただし、Ｎは、変換の寸法のサイズを表し、ｈＮは、Ｎの値の半分を表し、２ＮはＮの値の２倍を表す。
【００９３】
ビデオデコーダ３０は、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することもできる。マッピングは、固定される、ビデオエンコーダからビデオデコーダ３０にシグナリングされる、または、適応可能とすることができる。マッピングが適応可能である場合、マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングは、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【００９４】
図９は、本開示の技法による変換サイズをシグナリングするための例示的な方法を示すフローチャートである。図９の技法について、一般的なビデオコーダを参照しながら説明する。一般的なビデオコーダは、たとえば、ビデオエンコーダ２０などのビデオエンコーダ、またはビデオデコーダ３０などのビデオデコーダでもよい。
【００９５】
ビデオコーダは、ビデオデータのブロックのためのイントラ予測モードを決定する（９１０）。ビデオコーダは、ビデオデータのブロックのために決定されたイントラ予測モードに基づいて、最も可能性の高い変換を識別する（９２０）。最も可能性の高い変換は、正方形の変換または非正方形の変換のいずれかとすることができる。ビデオコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化する（９３０）。変換は、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群の変換から選択され得、ただし、Ｎは、変換の寸法のサイズを表し、ｈＮは、Ｎの値の半分を表し、２ＮはＮの値の２倍を表す。
【００９６】
ビデオコーダは、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持することができる。マッピングは、固定される、またはビデオエンコーダからビデオデコーダにシグナリングされ得る。マッピングは、適応可能とすることもできる。マッピングは、たとえば、ブロックサイズに基づいて適応可能でもよい。マッピングはまた、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づき得る。
【００９７】
ビデオコーダがビデオエンコーダであるとき、ビデオコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを生成することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオコーダは、ビデオデータのブロックを符号化するために使用される変換である最も可能性の高い変換以外の変換の指示を生成することができる。
【００９８】
ビデオコーダがビデデコーダであるとき、ビデオデコーダは、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかを示すフラグを受信することによって、最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換であることを示すフラグに応答して、ビデオコーダは、最も可能性の高い変換に基づいてビデオデータのブロックを再構成することができる。最も可能性の高い変換がビデオデータのブロックを符号化するために使用される変換ではないことに応答して、ビデオコーダは、最も可能性の高い変換以外の変換の指示を受信し、最も可能性の高い変換以外の変換に基づいて、ビデオデータのブロックを再構成することができる。
【００９９】
１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【０１００】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）、およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１０１】
命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つもしくは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
【０１０２】
本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実施され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
【０１０３】
様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
なお、以下に、出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ビデオデータをコード化する方法であって、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することと
を備える方法。
［Ｃ２］ビデオデータを符号化する方法を備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成することを備える、Ｃ１に記載の方法。
［Ｃ３］前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成することをさらに備え、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、Ｃ２に記載の方法。
［Ｃ４］ビデオデータを復号する方法を備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信することを備える、Ｃ１に記載の方法。
［Ｃ５］前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成すること
をさらに備える、Ｃ４に記載の方法。
［Ｃ６］前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
をさらに備える、Ｃ４に記載の方法。
［Ｃ７］イントラ予測モードに対する最も可能性の高い変換のマッピングを維持すること
をさらに備える、Ｃ１に記載の方法。
［Ｃ８］前記マッピングが固定である、Ｃ７に記載の方法。
［Ｃ９］前記マッピングがコード化ビットストリームの一部としてシグナリングされる、Ｃ７に記載の方法。
［Ｃ１０］前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、Ｃ７に記載の方法。
［Ｃ１１］前記マッピングが適応可能である、Ｃ７に記載の方法。
［Ｃ１２］前記マッピングがブロックサイズに基づいて適応可能である、Ｃ１１に記載の方法。
［Ｃ１３］前記変換が、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表す、Ｃ１に記載の方法。
［Ｃ１４］ビデオコーダが、ビデオデータのブロックのためのイントラ予測モードを決定することと、前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて、最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することとを行うように構成されたビデオコーダ
を備えるビデオコーディングデバイス。
［Ｃ１５］前記ビデオコーダがビデオエンコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成することを備える、Ｃ１４に記載のビデオコーディングデバイス。
［Ｃ１６］前記ビデオコーダが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成するようにさらに構成され、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である、Ｃ１５に記載のビデオコーディングデバイス。
［Ｃ１７］前記ビデオコーダがビデオデコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化することが、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信することを備える、Ｃ１４に記載のビデオコーディングデバイス。
［Ｃ１８］前記ビデオコーダが、
前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成する
ように構成される、Ｃ１７に記載のビデオコーディングデバイス。
［Ｃ１９］前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信することと、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成することと
をさらに備える、Ｃ１７に記載のビデオコーディングデバイス。
［Ｃ２０］前記ビデオコーダが、イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するようにさらに構成される、Ｃ１４に記載のビデオコーディングデバイス。
［Ｃ２１］前記マッピングが固定である、Ｃ２０に記載のビデオコーディングデバイス。
［Ｃ２２］前記マッピングがコード化ビットストリームの一部としてシグナリングされる、Ｃ２０に記載のビデオコーディングデバイス。
［Ｃ２３］前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、Ｃ２０に記載のビデオコーディングデバイス。
［Ｃ２４］前記マッピングが適応可能である、Ｃ２０に記載のビデオコーディングデバイス。
［Ｃ２５］前記マッピングがブロックサイズに基づいて適応可能である、Ｃ２４に記載のビデオコーディングデバイス。
［Ｃ２６］前記変換が、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表す、Ｃ１４に記載のビデオコーディングデバイス。
［Ｃ２７］前記ビデオコーディングデバイスが、
集積回路と、
マイクロプロセッサと、
前記ビデオコーダを含むワイヤレス通信デバイスと
のうちの少なくとも１つを備える、Ｃ１４に記載のビデオコーディングデバイス。
［Ｃ２８］ビデオコーディングのためのデバイスであって、
ビデオデータのブロックのためのイントラ予測モードを決定するための手段と、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別するための手段であって、前記最も可能性の高い変換が非正方形の変換である、手段と、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化するための手段と
を備えるデバイス。
［Ｃ２９］前記デバイスがビデオエンコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化するための前記手段が、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを生成するための手段を備える、Ｃ２８に記載のデバイス。
［Ｃ３０］前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を生成するための手段をさらに備え、前記最も可能性の高い変換以外の前記変換が、前記ビデオデータのブロックを符号化するために使用される前記変換である
Ｃ２９に記載のデバイス。
［Ｃ３１］前記デバイスがビデオデコーダを備え、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかの前記指示をコード化するための前記手段が、前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換であるかどうかを示すフラグを受信するための手段を備える、Ｃ２８に記載のデバイス。
［Ｃ３２］前記最も可能性の高い変換が前記ビデオデータの前記ブロックを符号化するために使用される前記変換であることを示す前記フラグに応答して、前記最も可能性の高い変換に基づいて前記ビデオデータのブロックを再構成するための手段
をさらに備える、Ｃ３１に記載のデバイス。
［Ｃ３３］前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される前記変換ではないことに応答して、前記最も可能性の高い変換以外の変換の指示を受信するための手段と、
前記最も可能性の高い変換以外の前記変換に基づいて前記ビデオデータのブロックを再構成するための手段と
をさらに備える、Ｃ３２に記載のデバイス。
［Ｃ３４］イントラ予測モードに対する最も可能性の高い変換のマッピングを維持するための手段
をさらに備える、Ｃ２８に記載のデバイス。
［Ｃ３５］前記マッピングが固定である、Ｃ３４に記載のデバイス。
［Ｃ３６］前記マッピングがコード化ビットストリームの一部としてシグナリングされる、Ｃ３４に記載のデバイス。
［Ｃ３７］前記マッピングが、特定のイントラ予測モードを有する以前符号化されたビデオブロックのために、変換がどのくらいの頻度で選択されたかの頻度に基づく、Ｃ３４に記載のデバイス。
［Ｃ３８］前記マッピングが適応可能である、Ｃ３４に記載のデバイス。
［Ｃ３９］前記マッピングがブロックサイズに基づいて適応可能である、Ｃ３８に記載のデバイス。
［Ｃ４０］前記変換が、ＮｘＮ、ｈＮｘ２Ｎ、および２ＮｘｈＮからなる一群から選択され、Ｎが変換の寸法のサイズを表し、ｈＮがＮの値の半分を表し、２ＮがＮの前記値の２倍を表す、Ｃ２８に記載のデバイス。
［Ｃ４１］１つまたは複数のプロセッサに、
ビデオデータのブロックのためのイントラ予測モードを決定することと、
前記ビデオデータのブロックのために決定された前記イントラ予測モードに基づいて最も可能性の高い変換を識別することであって、前記最も可能性の高い変換が非正方形の変換である、識別することと、
前記最も可能性の高い変換が前記ビデオデータのブロックを符号化するために使用される変換であるかどうかの指示をコード化することと
を行わせるように動作可能な命令を記憶するコンピュータ可読記憶媒体。
【図１】
0005996661.tif 000004
【図２Ａ】
0005996661.tif 000005
【図２Ｂ】
0005996661.tif 000006
【図３】
0005996661.tif 000007
【図４Ａ】
0005996661.tif 000008
【図４Ｂ】
0005996661.tif 000009
【図５Ａ】
0005996661.tif 000010
【図５Ｂ】
0005996661.tif 000011
【図６】
0005996661.tif 000012
【図７】
0005996661.tif 000013
【図８】
0005996661.tif 000014
【図９】
0005996661.tif 000015