JP2014523710A - ビデオ・コーディングにおける直交形状変換をスキャンするためのデバイスおよび方法 - Google Patents

Abstract

波面スキャンを直交変換ブロックに適用可能にするデバイスおよび方法が、本明細書に記載される。このようなデバイスおよび方法は、変換係数の並行処理を可能にすることによって、エントロピー・コーディングの効率を高めることができる。一部の実施形態では、複数のピクチャを有するデジタル・ビデオ・シーケンスをコーディングするための方法が、複数のピクチャの少なくとも１つをブロックに分割する工程と、該ブロックの少なくとも１つに対し直交変換を実行して、１つまたは複数の変換係数を生成する工程と、１つまたは複数の変換係数に量子化を実行する工程と、１つまたは複数の変換係数を１度に１つ、コーディングスキャン順序に沿ってエンコードして、圧縮ビットストリームを生成する工程とを含む。コーディングスキャン順序は、順方向波面スキャン順序または逆方向波面スキャン順序を含むことができ、量子化により量子化変換係数を生成することができる。

Description

本開示は、一般にビデオ・コーディングの分野に関し、より詳細には、エントロピー・コーディングにおいて直交形状変換をスキャンするためのシステム、デバイス、および方法に関する。

デジタル・ビデオ機能を、デジタル・テレビ、デジタル直接放送システム、無線放送システム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップ・コンピュータ、タブレット・コンピュータ、電子書籍端末、デジタル・カメラ、デジタル記録デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・デバイス、ビデオ・ゲーム・コンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ会議デバイス、ビデオ・ストリーミング・デバイス等を含む広範囲のデバイスに組み込むことができる。デジタル・ビデオ・デバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−ＴＨ．２６３、ＩＴＵ−ＴＨ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、現在開発中のＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、およびこのような規格の拡張規格により定義された規格に記載された技術等のビデオ圧縮技術を実施する。ビデオ・デバイスは、このようなビデオ圧縮技術を実施することによって、より効率的にデジタル・ビデオ情報を送信、受信、エンコード（符号化）、デコード（復号化）、および／または記憶することができる。

ビデオ圧縮技術は、空間（たとえば、イントラピクチャ）予測および／または時間（たとえば、インターピクチャ）予測を実行して、ビデオ・シーケンスに固有の冗長性を減少させ、または除去する。ブロックベースのビデオ・コーディングについて、ビデオ・スライス（たとえば、ビデオ・フレームまたはビデオ・フレームの一部）をビデオ・ブロックに区画することができ、このビデオ・ブロックを、木ブロック、コーディング・ユニット（ＣＵ）、および／またはコーディングノードと呼ぶこともできる。ピクチャのイントラコーディング（Ｉ）スライスのビデオ・ブロックは、同一ピクチャにおける隣接ブロック内の基準サンプルに対する空間予測を使用してエンコードされ得る。ピクチャのインターコーディング（ＰまたはＢ）スライスにおけるビデオ・ブロックは、同一ピクチャにおける隣接ブロックの基準サンプルに対する空間予測、または他の基準ピクチャの基準サンプルに対する時間予測を使用することができる。ピクチャをフレームと呼ぶこともでき、基準ピクチャを基準フレームと呼ぶこともできる。

空間または時間予測は、コーディングするブロックに対する予測ブロックを生じさせることができる。残差データは、コーディングするオリジナル・ブロックと予測ブロックとの画素差を表すことができる。インターコーディングブロックを、予測ブロックを形成する基準サンプルのブロックを指す動きベクトルと、コーディングブロックと予測ブロックとの差を示す残差データとによってエンコードすることができる。イントラコーディングブロックを、イントラコーディングモードおよび残差データによってエンコードすることができる。さらなる圧縮について、残差データを画素領域から変換領域に変換して、残差変換係数を生じさせることができ、次いで残差変換係数を量子化することができる。変換係数の１次元ベクトルを生じさせるために、最初に２次元配列に配置された量子化変換係数をスキャンすることができ、エントロピー・コーディングを適用してさらなる圧縮を達成することができる。

本開示は、エントロピー・コーディングのための効率を提供する新しいデバイスおよび方法を検討する。

したがって、本明細書では、波面スキャンを直交変換ブロックに適用可能にするデバイスおよび方法が提供される。このようなデバイスおよび方法は、変換係数の並行処理を可能にすることによって、エントロピー・コーディングの効率を高めることができる。

一部の実施形態では、複数のピクチャを有するデジタル・ビデオ・シーケンスをコーディングするための方法が、複数のピクチャの少なくとも１つをブロックに分割する工程と、該ブロックの少なくとも１つに対し直交変換を実行して、１つまたは複数の変換係数を生成する工程と、１つまたは複数の変換係数に量子化を実行する工程と、１つまたは複数の変換係数を１度に１つ、コーディングスキャン順序に沿ってエンコードして、圧縮ビットストリームを生成する工程とを含む。コーディングスキャン順序は、順方向波面スキャン順序または逆方向波面スキャン順序を含むことができ、量子化により量子化変換係数を生成することができる。

一部の実施形態では、複数のピクチャを有するデジタル・ビデオ・シーケンスをコーディングするための装置が、複数のピクチャの少なくとも１つをブロックに分割し、ブロックの少なくとも１つに対し直交変換を実行して、１つまたは複数の変換係数を生成し、１つまたは複数の変換係数に量子化を実行し、１つまたは複数の変換係数を１度に１つ、コーディングスキャン順序に沿ってエンコードして、圧縮ビットストリームを生成するように構成されたビデオ・コーダを備える。コーディングスキャン順序は、順方向波面スキャン順序または逆方向波面スキャン順序を含むことができ、量子化により量子化変換係数を生成することができる。

他の実施形態では、圧縮ビットストリームを処理するための方法が、圧縮ビットストリームを受信する工程と、圧縮ビットストリームを処理して、直交変換の１つまたは複数の変換係数を生成する工程とを含む。１つまたは複数の変換係数を、１度に１つ、直交変換のコーディングスキャン順序に沿って生成することができ、コーディングスキャン順序は、順方向波面スキャン順序または逆方向波面スキャン順序を含むことができる。

さらに他の実施形態では、圧縮ビットストリームを処理するための装置が、圧縮ビットストリームを受信し、圧縮ビットストリームを処理して、直交変換の１つまたは複数の変換係数を生成するように構成されたビデオ・デコーダを備える。１つまたは複数の変換係数を、１度に１つ、直交変換のコーディングスキャン順序に沿って生成することができ、コーディングスキャン順序は、順方向波面スキャン順序または逆方向波面スキャン順序を含むことができる。

構造および作用に関する本開示の詳細は、添付図面を検討することにより部分的に理解することができる。図中、同一の参照符号は同一の部品を示す。図面は必ずしも一定の縮尺ではなく、本発明の原理を示す部分を強調する。

画像の空間および時間サンプリングを示すブロック図。 １実施形態による、ビデオ・データの直交ブロックのスキャニングを効率的に実行するための技術を実施可能な、ビデオエンコードおよびデコードシステムの例を示すブロック図。 １実施形態による、ピクチャがブロック（ＬＣＵ）に分割される一例を示す図。 １実施形態による、ＣＵに分割されたＬＣＵの一例を示す図。 １実施形態による、図４のＬＣＵ区画の４分木表示の図。 １実施形態による、ＣＵごとのＰＵへの考えられる４つの区画を示す図。 １実施形態による、ＣＵ区画および関連する一組のＴＵの例を示す図。 １実施形態による、図７の例におけるＣＵ内のＴＵの４分木表示を示す図。 ビデオ・データおよび対応する有意係数位置情報および最後の有意係数位置情報のブロックの例を示す概念図。 ビデオ・データおよび対応する有意係数位置情報および最後の有意係数位置情報のブロックの例を示す概念図。 ビデオ・データおよび対応する有意係数位置情報および最後の有意係数位置情報のブロックの例を示す概念図。 ジグザグ・スキャニング順序を使用してスキャンされたビデオ・データのブロックの例を示す概念図。 ジグザグ・スキャニング順序を使用してスキャンされたビデオ・データのブロックのさらなる例を示す概念図。 方形波面スキャンの例を示す図。 １実施形態による波面スキャン方向の例を示す図。 １実施形態による波面スキャン方向の例を示す図。 １実施形態による波面スキャン方向の例を示す図。 １実施形態による波面スキャン方向の例を示す図。 １実施形態による、全順方向直交形状波面スキャン（左下から右上へ４５°）の一例を示す図。 １実施形態による、全逆方向直交形状波面スキャン（左下から右上へ４５°）の一例を示す図。 １実施形態による、全順方向直交形状波面スキャン（右上から左下へ−１３５°）の一例を示す図。 １実施形態による、全逆方向直交形状波面スキャン（右上から左下へ−１３５°）の一例を示す図。 １実施形態による、最後の非ゼロ量子化変換係数までの部分順方向直交形状波面スキャン（左下から右上へ４５°）の一例を示す図。 １実施形態による、最後の非ゼロ量子化変換係数から始まる部分逆方向直交形状波面スキャン（左下から右上へ４５°）の一例を示す図。 １実施形態による、最後の非ゼロ量子化変換係数までの部分順方向直交形状波面スキャン（右上から左下へ−１３５°）の一例を示す図。 １実施形態による、最後の非ゼロ量子化変換係数から始まる部分逆方向直交形状波面スキャン（右上から左下へ−１３５°）の一例を示す図。 １実施形態による、ビデオ・データの直交ブロックのスキャニングを効率的に実行するための技術を実施可能なビデオ・エンコーダの例を示すブロック図。 １実施形態による、ビデオ・データの直交ブロックのエンコードスキャン情報を効率的にデコードするための技術を実施可能なビデオ・デコーダの例を示すブロック図。

本開示の技術は、一部の例において、ＣＡＢＡＣ（ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｅｎｔｒｏｐｙ ｃｏｄｉｎｇ）、ＰＩＰＥ（ｐｒｏｂａｂｉｌｉｔｙ ｉｎｔｅｒｖａｌ ｐａｒｔｉｔｉｏｎｉｎｇ ｅｎｔｒｏｐｙ ｃｏｄｉｎｇ）、または別の状況適応エントロピー・コーディング方法を含む任意の状況適応エントロピー・コーディング方法と共に使用することができる。本開示においては、例示の目的でＣＡＢＡＣについて説明するが、本開示に広く記載された技術に関する限定はない。また、一般に、たとえば、ビデオ・データに加えて、他のタイプのデータのコーディングに本技術を適用することができる。

本開示において、「コーディング」という用語は、エンコーダで行われるエンコードまたはデコーダで行われるデコードを指す。同様に、コーダという用語は、エンコーダ、デコーダ、または複合エンコーダ／デコーダ（コーデック）を指す。コーダ、エンコーダ、デコーダおよびコーデックという用語はすべて、本開示に一致するビデオ・データのコーディング（エンコードおよび／またはデコード）のために設計された特定の機械を指す。

本説明を、一部の用語およびデジタル画像圧縮の分野で公知の技術の非常に簡潔な概要から始める。この概要は、公知の技術を詳細に教示することを意図したものではない。当業者は、テキストや関連する規格にさらなる詳細を見つける方法を知っている。

実際の視覚シーンは、時間的に変化する３次元空間にレイアウトされた複数のオブジェクトからなる。色、テクスチャ、照度、位置等のオブジェクト特性は、連続して変化する。デジタル・ビデオは、実際のシーンの空間および時間サンプル表示である。デジタル・ビデオは、周期的な時間間隔で、シーンの２次元映像をセンサにキャプチャすることによって得られる。空間サンプリングは、センサ出力に重畳されるサンプリング・グリッドと一致する点を取ることによって行われる。画素（ピクセル）またはサンプルと呼ばれる各点が、輝度および色を記述する色空間領域からの１組の値によって、対応するセンサ位置の特徴を表す。所与の時間指数における画素２次元配列が、フレームと呼ばれる。図１は、視覚シーンの空間時間サンプリングを示す。

ビデオエンコードシステムは、ビデオ・データの冗長性を除去することにより、たとえば、再現忠実度に悪影響を与えることなく破棄可能なそれらの要素を除去することにより、圧縮を達成する。ビデオ信号が時間および空間で行われるため、大半のビデオエンコードシステムは、これらの信号に存在する時間および空間冗長性を利用する。典型的には、連続するフレーム間に高い時間相関がある。これは、互いに近くにある画素についての空間領域にも当てはまる。したがって、これらの空間時間相関を慎重に利用することにより、高い圧縮ゲインが達成される。

図２は、本開示の技術に一致した、ビデオ・データの直交ブロックの波面スキャニングを効率的に実行するための技術を実施可能な、ビデオエンコードおよびデコードシステム１０の例を示すブロック図である。図２に示すように、システム１０は、エンコードビデオを宛先デバイス１４に通信チャネル１６を介して送信するソース・デバイス１２を備える。ソース・デバイス１２および宛先デバイス１４は、広範囲のデバイスのいずれかを含むことができる。場合によっては、ソース・デバイス１２および宛先デバイス１４は、無線ハンドセット、いわゆるセルラーもしくは衛星無線電話、またはビデオ情報を通信チャネル１６（この場合は無線）によって通信可能な任意の無線デバイス等の、無線通信デバイスを含むことができる。

本開示の技術は、必ずしも無線の適用または設定に限定されないことを理解されたい。これらの技術は、一般に、無線テレビ放送、ケーブル・テレビ放送、衛星テレビ放送、ストリーミング・インターネット・ビデオ放送、記憶媒体上にエンコードされ、もしくは記憶媒体から読み出されデコードされたエンコードデジタル・ビデオを含む、エンコードまたはデコードが実行される任意の状況、または他の状況に適用可能である。したがって、通信チャネル１６は必要なく、本開示の技術は、エンコードが適用される設定またはデコードが適用される設定に、エンコードデバイスおよびデコードデバイス間のデータ通信なしで、適用可能である。

図２の例では、ソース・デバイス１２が、ビデオ・ソース１８、ビデオ・エンコーダ２０、変調器／復調器（モデム）２２、および送信器２４を備える。宛先デバイス１４は、受信器２６、モデム２８、ビデオ・デコーダ３０、および表示デバイス３２を備える。本開示によれば、ソース・デバイス１２のビデオ・エンコーダ２０および／または宛先デバイス１４のビデオ・デコーダ３０を、ビデオ・データの直交ブロックの波面スキャニングを実行するための技術を適用するように構成することができる。他の例では、ソース・デバイスおよび宛先デバイスが、他の部品および配置を含むことができる。たとえば、ソース・デバイス１２は、外部カメラ等の外部ビデオ・ソース１８からビデオ・データを受信することができる。同様に、宛先デバイス１４は、一体型表示デバイスを備えるのではなく、外部表示デバイスと接続することができる。

図２の図示したシステム１０は、一例にすぎない。ビデオ・データの直交ブロックの波面スキャニングを効率的に実行するための技術を、任意のデジタル・ビデオエンコードおよび／またはデコードデバイスによって実行することができる。一般に、本開示の技術はビデオエンコードデバイスにより実行されるが、典型的には「コーデック（ＣＯＤＥＣ）」と呼ばれるビデオ・エンコーダ／デコーダにより、技術を実行することもできる。さらに、本開示の技術を、ビデオ・プリプロセッサによって実行してもよい。ソース・デバイス１２および宛先デバイス１４は、ソース・デバイス１２が宛先デバイス１４へ送信するためのコーディングビデオ・データを生成する、このようなコーディングデバイスの例にすぎない。一部の例では、デバイス１２、１４は、デバイス１２、１４のそれぞれがビデオエンコードおよびデコード部品を備えるように、ほぼ対称に動作することができる。これにより、システム１０は、たとえば、ビデオ・ストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のための、ビデオ・デバイス１２、１４間の一方向または双方向ビデオ放送を支持することができる。

ソース・デバイス１２のビデオ・ソース１８は、ビデオ・カメラ、先にキャプチャされたビデオを含むビデオ・アーカイブ、および／またはビデオ・コンテンツ・プロバイダからのビデオ・フィード等のビデオ・キャプチャ・デバイスを備えることができる。さらなる代替例として、ビデオ・ソース１８は、コンピュータ・グラフィック・ベースのデータを、ソース・ビデオとして、またはライブ・ビデオ、アーカイブ・ビデオ、およびコンピュータ生成ビデオの組合せとして生成することができる。場合によっては、ビデオ・ソース１８がビデオ・カメラであれば、ソース・デバイス１２および宛先デバイス１４がいわゆるカメラ電話またはビデオ電話を形成することができる。しかしながら、前述したように、本開示に記載された技術は、一般にビデオ・コーディングに適用可能とすることができ、無線および／または有線用途に適用することができる。それぞれの場合に、キャプチャされ、プリキャプチャされ、またはコンピュータ生成されたビデオを、ビデオ・エンコーダ２０によりエンコードすることができる。次いで、エンコードビデオ情報を通信規格に従ってモデム２２により変調し、送信器２４を介して宛先デバイス１４に送信することができる。モデム２２は、様々なミキサ、フィルタ、増幅器、またはその他の信号変調用に設計された部品を備えることができる。送信器２４は、増幅器、フィルタ、および１つまたは複数のアンテナを含む、データ送信用に設計された回路を備えることができる。

宛先デバイス１４の受信器２６、たとえば、デコーダは、チャネル１６により情報を受信し、モデム２８は情報を復調する。再び、前述したビデオエンコード方法は、本明細書に記載された技術の１つまたは複数を実施して、ビデオ・データの直交ブロックの波面スキャニングを効率的に実行することができる。チャネル１６により通信される情報は、ビデオ・エンコーダ２０により定義されるシンタックス情報を含むことができ、このシンタックス情報は、ビデオ・デコーダ３０によっても使用され、ビデオ・データのブロック（たとえば、マクロブロックもしくはエンコードユニット）の特徴および／または処理を記述するシンタックス要素、たとえば、ブロックのスキャニング順序情報、およびその他の情報を含む。表示デバイス３２は、デコードビデオ・データをユーザに表示し、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプの表示デバイス等の種々の表示デバイスのいずれかを含むことができる。

図２の例では、通信チャネル１６が、無線周波数（ＲＦ）スペクトラム、または１つまたは複数の物理伝送ライン、または無線および有線媒体の組合せ等の任意の無線または有線通信媒体を備えることができる。通信チャネル１６は、ローカル・エリア・ネットワーク、広域ネットワーク、またはインターネット等のグローバル・ネットワーク等のパケットベース・ネットワークの一部を形成することができる。通信チャネル１６は、一般に、有線または無線媒体の任意の適切な組合せを含む、ソース・デバイス１２から宛先デバイス１４へビデオ・データを送信するための任意の適切な通信媒体、または異なる通信媒体の集合体を表す。通信チャネル１６は、ルータ、スイッチ、ベース・ステーション、またはソース・デバイス１２から宛先デバイス１４への通信を促進させるのに有用であり得るその他の機器を備えることができる。他の例では、エンコードデバイスまたはデコードデバイスが、このようなデバイス間の通信なしで、本開示の技術を実施することができる。たとえば、エンコードデバイスは、本開示の技術に一致する、エンコードビットストリームをエンコードし、記憶することができる。あるいは、デコードデバイスは、エンコードビットストリームを受信し、または読み出し、本開示の技術に一致するビットストリームをデコードすることができる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、ＩＴＵ−ＴＨ．２６４規格あるいはＭＰＥＧ−４、Ｐａｒｔ １０、ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）とも呼ばれるビデオ圧縮規格によって動作することができる。しかしながら、本開示の技術は、いかなる特定のコーディング規格にも限定されない。他の例は、ＭＰＥＧ−２、ＩＴＵ−ＴＨ．２６３、および現在開発中のＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｅｉｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）を含む。一般に、本開示の技術はＨＥＶＣに関して説明されるが、これらの技術を他のビデオ・コーディング規格と共に使用してもよいことを理解されたい。図２には示されていないが、一部の態様では、ビデオ・エンコーダ２０およびビデオ・デコーダ３０が、それぞれオーディオ・エンコーダおよびデコーダと一体化されていてもよく、共通のデータ・ストリームまたは別のデータ・ストリームにおいて音声と映像の両方のエンコードを処理するための適切なＭＵＸ−ＤＥＭＵＸユニットまたは他のハードウェアおよびソフトウェアを備えていてもよい。適用可能であれば、ＭＵＸ−ＤＥＭＵＸユニットが、ＩＴＵＨ．２２３マルチプレクサ・プロトコル、またはユーザ・データグラム・プロトコル（ＵＤＰ）等の他のプロトコルに適合することができる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、それぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せ等の種々の適切なエンコーダおよびデコーダ回路のいずれかとして実施することができる。ビデオ・エンコーダ２０およびビデオ・デコーダ３０のそれぞれが、１つまたは複数のエンコーダまたはデコーダに含まれていてもよく、これらのいずれかが、それぞれのカメラ、コンピュータ、モバイル・デバイス、加入者デバイス、放送デバイス、セットトップ・ボックス、サーバ等に、複合エンコーダ／デコーダ（コーデック）の一部として組み込まれていてもよい。

ビデオ・シーケンスは、典型的には、一連のビデオ・フレームを含む。ピクチャ（ＧＯＰ）のグループは、一般に、一連の１つまたは複数のビデオ・フレームを含む。ＧＯＰは、ＧＯＰのヘッダ、ＧＯＰの１つまたは複数のフレームのヘッダ、または他の場所に、ＧＯＰに含まれる多数のフレームを記述するシンタックス・データを含むことができる。各フレームは、それぞれのフレームについてのエンコードモードを記述するフレーム・シンタックス・データを含むことができる。ビデオ・エンコーダ、たとえば、ビデオ・エンコーダ２０は、典型的には、ビデオ・データをエンコードするために、個々のビデオ・フレーム内のビデオ・ブロックで動作する。ＩＴＵ−ＴＨ．２６４規格によれば、ビデオ・ブロックが、マクロブロックまたはマクロブロックの区画に対応することができる。他の規格、たとえば、以下でさらに詳細に説明するＨＥＶＣによれば、図３に示すように、ビデオ・ブロックは、コーディング・ユニット（たとえば、最大コーディング・ユニット（ＬＣＵ））、またはコーディング・ユニットの区画に対応することができる。ビデオ・ブロックは、一定の、または異なるサイズを有することができ、かつ特定のコーディング規格に従ってサイズが異なっていてもよく、たとえば、（ＬＣＵサイズに応じて）ＨＥＶＣについて１２８×１２８画素または６４×６４画素または３２×３２画素または１６×１６画素とすることができる。各ビデオ・フレームは、複数のスライス、たとえば、ビデオ・フレームの部分を含むことができる。各スライスは、複数のビデオ・ブロックを含むことができ、これらのビデオ・ブロックは区画に配置され、サブブロックとも呼ばれ得る。

特定のコーディング規格に応じて、ビデオ・ブロックを、１６×１６、８×８、４×４、２×２等の種々の「Ｎ×Ｎ」サブブロック・サイズに区画することができる。処理の規則性のためにサブブロッキングを使用することができる。本開示では、「Ｎ×Ｎ」および「Ｎ掛けるＮ」を同義で使用して、ブロックの画素寸法を垂直寸法および水平寸法に関して、たとえば、１６×１６画素または１６掛ける１６画素のように示すことができる。一般に、１６×１６ブロックは、垂直方向に１６画素（ｙ＝１６）および水平方向に１６画素（ｘ＝１６）を有する。同様に、Ｎ×Ｎブロックは、一般に垂直方向にＮ画素および水平方向にＮ画素を有し、Ｎは非負の整数値を示す。ブロック内の画素を行と列に配置することができる。さらに、ブロックは、必ずしも垂直方向と同一数の画素を水平方向に有する必要はない。たとえば、ブロックは、Ｎ×Ｍ画素を含むことができ、Ｍは必ずしもＮに等しくない。一例として、ＩＴＵ−ＴＨ．２６４規格では、１６掛ける１６画素のサイズのブロックをマクロブロックと呼ぶことができ、１６掛ける１６画素よりも小さいブロックを１６掛ける１６マクロブロックの区画と呼ぶことができる。ＨＥＶＣ等の他の規格では、より一般的には、ブロックを、サイズに対して、たとえば、それぞれが一定のサイズではなく異なるサイズを有するコーディング・ユニットおよびその区画として定義することができる。

ビデオ・ブロックは、たとえば、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換等の変換を、所与のビデオ・ブロックについての残差データに適用するのに続いて、画素領域の画素データのブロック、または変換領域の変換係数のブロックを含むことができ、残差データが、ブロックについてのビデオ・データとブロックについて生成された予測データとの画素差を表す。場合によっては、ビデオ・ブロックが、変換領域の量子化変換係数のブロックを含むことができ、所与のビデオ・ブロックについての残差データへの変換の適用に続いて、これにより生じる変換係数も量子化される。

量子化により、信号が取ることのできる値の範囲が減少するため、信号をより少ないビットで表すことができる。一部の実施形態では、外部境界条件を使用して、修正された１つまたは複数の変換係数を生成する。たとえば、変換係数が非ゼロ値であるか、ちょうどゼロであるかを判定する際に、より低い範囲または値を使用することができる。ビデオエンコードにおいて、量子化は損失を導入する工程であるため、ビットレートと再構成品質とのバランスを確立することができる。

ブロック区画は、ブロックベースのビデオ・コーディング技術において重要な目的を果たす。ビデオ・データをコーディングするためにより小さいブロックを使用すると、高い詳細度を有するビデオ・フレームの位置についてのデータをより良好に予測することができ、したがって、結果として生じる、残差データとして表されるエラー（たとえば、ソース・ビデオ・データからの予測データの偏差）を減少させることができる。一般に、予測は、種々の寸法のサンプル・ブロック間の相関をモデリングすることにより、ビデオ・シーケンスの空間または時間冗長性を利用して、実信号と予測信号とのわずかな差のみをエンコードする必要があるようにする。現在のブロックについての予測が、すでにエンコードされたサンプルから生成される。しかしながら、このような技術は、残差データを減少させる可能性はあるが、より小さいブロックがビデオ・フレームに対してどのように区画されるかを示すさらなるシンタックス情報を必要とし、コーディングビデオ・ビットレートを増加させ得る。したがって、一部の技術では、ブロック区画が、残差データの望ましい減少と、結果として生じる、さらなるシンタックス情報によるコーディングビデオ・データのビットレートの増加とのバランスに依存し得る。

一般に、ブロックおよびその種々の区画（たとえば、サブブロック）は、ビデオ・ブロックと考えられる。加えて、スライスは、複数のビデオ・ブロック（たとえば、マクロブロックまたはエンコードユニット）、および／またはサブブロック（マクロブロックまたはサブエンコードユニット）と考えられる。各スライスは、ビデオ・フレームの、独立して復号可能なユニットであってもよい。あるいは、フレーム自体が復号可能ユニットであってもよく、またはフレームの他の部分を復号可能ユニットとして定義してもよい。さらに、シーケンスとも呼ばれるＧＯＰを復号可能ユニットとして定義してもよい。

前述したように、現在ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）と呼ばれる新しいビデオ・コーディング規格の策定が、現在進行中である。新たなＨＥＶＣ規格をＨ．２６５と呼ぶこともできる。規格化の試みは、ＨＥＶＣ試験モデル（ＨＭ）と呼ばれるビデオ・コーディングデバイスのモデルに基づく。ＨＭは、たとえば、ＩＴＵ−ＴＨ．２６４／ＡＶＣによるデバイスを超えるビデオ・コーディングデバイスの複数の機能を推定している。たとえば、Ｈ．２６４は９個のイントラ予測エンコードモードを提供するが、ＨＭは、たとえば、ブロックのサイズがイントラ予測コーディングされることに基づいて、３５個ものイントラ予測エンコードモードを提供する。

一般に、イントラ予測エンコードにおいて、フレームの隣接ブロック間に、高レベルの空間相関が存在する。結果として、ブロックを、隣接するエンコードされ再構成されたブロックから予測することができ、イントラ予測を生じさせる。一部の実施形態では、現在のブロックの上および左に位置する先にエンコードされたサンプルの加重平均により、予測を形成することができる。エンコーダは、オリジナルと予測との差を最小限にするモードを選択することができ、この選択を制御データで伝える。

ＨＭは、コーディング・ユニット（ＣＵ）としてのビデオ・データのブロックを指す。ＣＵは、種々のコーディングツールが圧縮のために適用される基本単位として機能する画像領域を指すことができる。Ｈ．２６４では、ＣＵはマクロブロックとも呼ばれる。ビットストリーム内のシンタックス・データが、画素数に関して最大ＣＵである最大コーディング・ユニット（ＬＣＵ）を定義することができる。一般に、ＣＵは、ＣＵにサイズの区別がないことを除いて、Ｈ．２６４のマクロブロックと同様の目的を有する。したがって、図４に示すように、ＣＵを区画し、サブＣＵに「分割」することができる。

ＬＣＵがどのように区画されるかを示す図５に示されるように、ＬＣＵを４分木データ構造に関連させることができる。すなわち、ノードがさらにサブノードに分割される場合、４分木の各ノードにビット「１」が割り当てられ、そうでない場合にはビット「０」が割り当てられる。たとえば、図４のＬＣＵ区画を、図５に示す４分木で表すことができる。バイナリ・データ１０１００の４分木表示をコーディングして、オーバヘッドとして送信することができる。

一般に、４分木データ構造は、ＬＣＵのＣＵごとに１つのノードを含み、ここでは根ノードがＬＣＵに対応し、他のノードがＬＣＵのサブＣＵに対応する。所与のＣＵが４つのサブＣＵに分割された場合、分割ＣＵに対応する４分木のノードは、それぞれサブＣＵの１つに対応する４つの子ノードを含む。４分木データ構造の各ノードが、対応するＣＵのためのシンタックス情報を提供することができる。たとえば、４分木のノードは、ノードに対応するＣＵが４つのサブＣＵに分割されるか否かを示す、ＣＵの分割フラグを有することができる。所与のＣＵについてのシンタックス情報は、再帰的に定義され得、ＣＵがサブＣＵに分割されるか否かに依存し得る。

分割されないＣＵ（たとえば、所与の４分木の終端または「葉」ノードに対応するＣＵ）は、１つまたは複数の予測ユニット（ＰＵ）を含むことができる。一般に、ＰＵは、対応するＣＵの全部または一部を表し、ＣＵの予測を実行する目的でＰＵの基準サンプルを読み出すためのデータを含む。たとえば、ＣＵがイントラモードエンコードされているときには、ＰＵが、ＰＵのイントラ予測モードを記述するデータを含むことができる。別の例として、ＣＵがインターモードエンコードされているときには、ＰＵが、ＰＵの動きベクトルを定義するデータを含むことができる。動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４画素精度または１／８画素精度）、動きベクトルが指す基準フレーム、および／または動きベクトルの基準リスト（たとえば、リスト０またはリスト１）を記述することができる。ＣＵの１つまたは複数のＰＵを定義するＣＵのデータは、たとえば、ＣＵの１つまたは複数のＰＵへの区画を記述することもできる。区画モードは、ＣＵが、コーディングされていないか、イントラ予測モードエンコードされているか、インター予測モードエンコードされているかによって異なっていてもよい。ＣＵごとの４つの考えられる区画を示す例が、図６に示される。

現在のＨＥＶＣ規格では、ＰＵごとに、水平、垂直、４５度斜め、１３５度斜め、ＤＣ等を含む３５個の空間予測方向またはモードがある。一般に、シンタックスを使用してＰＵごとの空間予測を示す。

一般に、インター予測エンコードでは、ビデオ・シーケンスはフレーム間の高い時間相関を有し、現在のフレームのブロックを、基準フレームとして知られる先のフレームの領域によって正確に記述することができる。インター予測は、先にエンコードされ再構成された基準フレームを使用して、ブロックベースの動き推定および補償技術を使用した予測を展開させる。

また、１つまたは複数のＰＵを有するＣＵは、図７に示すように、１つまたは複数の変換ユニット（ＴＵ）を含むこともできる。前述したように、１つまたは複数のＰＵを使用するＣＵの予測に続いて、ビデオ・エンコーダは、１つまたは複数のＰＵに対応するＣＵの各部分について１つまたは複数の残差ブロックを算出することができる。残差ブロックは、ＣＵについてのビデオ・データと１つまたは複数のＰＵについての予測データとの画素差を表すことができる。１組の残差値を変換、スキャン、および量子化して、１組の量子化変換係数を定義することができる。図８に示すように、ＴＵは、ＣＵを参照して前述した４分木データ構造とほぼ同様の変換係数についての区画情報を示す区画データ構造を定義することができる。

他のビデオ・コーディング規格と同様に、ＨＥＶＣは、残差データにブロック変換を適用して、ブロック内の画素の相関を失わせ、ブロック・エネルギーを下位変換係数に圧縮する。しかしながら、単一の４×４または８×８変換をマクロブロックに適用する規格とは異なり、ＨＥＶＣは、異なるサイズの１組のブロック変換を単一のＣＵに適用することができる。ＣＵに適用される１組のブロック変換は、その関連ＴＵによって表される。したがって、ＴＵは必ずしもＰＵのサイズに限定されず、たとえば、ＴＵは同一のＣＵについて対応するＰＵよりも大きいか、または小さくてもよいことを理解されたい。一部の例では、ＴＵの最大サイズが、対応するＣＵのサイズに対応していてもよい。一般に、ＴＵは、何のブロック変換をＣＵ区画に適用すべきであるかを示し、ここでは各ブロック変換の範囲が各ＴＵの位置およびサイズによって定義される。特定のＣＵに関連するＴＵの構成が、種々の基準に基づいて異なっていてもよい。

一例では、ＣＵに対応する残差サンプルを、「残差４分木」（ＲＱＴ）として知られる４分木構造を使用して、より小さいユニットに細分化することができる。図８に示すように、ＲＱＴ表示１１０００をコーディングして、オーバヘッドとして送信することができる。この場合、ＲＱＴの葉ノードをＴＵと呼ぶことができ、このＴＵについて、対応する残差サンプルを変換し量子化することができる。

予測データおよび残差データを生成するためのイントラ予測またはインター予測エンコード、および変換係数を生成するための任意の変換（Ｈ．２６４／ＡＶＣで使用される４×４もしくは８×８整数変換、または離散コサイン変換（ＤＣＴ）等）に続いて、変換係数の量子化を実行することができる。一般に、量子化は、たとえば、高精度変換係数を考えられる値の有限数に変換することにより、変換係数を量子化して、係数を表すために使用されるデータの量を場合によって減少させる方法を指す。量子化方法は、係数の一部または全部に関連するビット深さを減少させることができる。たとえば、量子化中に、ｎビット値を切り捨てによってｍビット値に丸めることができ、ここでｎはｍよりも大きい。理解されるように、量子化は損失の多い操作であり、量子化による損失は、一般に、回復することができない。

量子化に続いて、量子化データ（たとえば、量子化変換係数）のエントロピー・コーディングを実行することができる。エントロピー・コーディングは、ビデオ・データの直交ブロックのスキャニングを効率的に実行することに関して本開示の技術に適合することができ、かつＣＡＶＬＣ（ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｃｏｄｉｎｇ）、ＣＡＢＡＣ、ＰＩＰＥ、もしくは別のエントロピー・コーディング方法等の他のエントロピー・コーディング技術を使用することもできる。たとえば、量子化変換係数の大きさおよび対応する記号（たとえば、「＋１」または「−１」）で表される係数値を、エントロピー・コーディング技術を使用してエンコードすることができる。

前述した予測、変換、および量子化を、特定のコーディング規格に応じて、ビデオ・データの任意のブロック、たとえば、ＣＵのＰＵおよび／もしくはＴＵ、またはマクロブロックに対して実行することができることに注目されたい。したがって、ビデオ・データの直交ブロックのスキャニングを効率的に実行することに関する本開示の技術を、ビデオ・データの任意の直交ブロック、たとえば、マクロブロックまたはＣＵのＴＵを含む量子化変換係数の任意の直交ブロックに適用することができる。さらに、ビデオ・データのブロック（たとえば、マクロブロック、またはＣＵのＴＵ）は、対応するビデオ・データの輝度成分（Ｙ）、第１のクロミナンス成分（Ｕ）、および第２のクロミナンス成分（Ｖ）のそれぞれを含むことができる。このようにして、本開示の技術を、ビデオ・データの所与の直交ブロックのＹ、Ｕ、およびＶ成分のそれぞれについて実行することができる。

前述したようにビデオ・データのブロックをエンコードするために、所与のブロック内の有意係数の位置に関する情報を生成し、エンコードすることもできる。続いて、前述したように、有意係数の値をエンコードすることができる。Ｈ．２６４／ＡＶＣおよび新たなＨＥＶＣ規格では、状況適応エントロピー・コーディング方法、たとえばＣＡＢＡＣ方法を使用するときに、ビデオ・データのブロック内の有意係数の位置を、有意係数の値をエンコードする前にエンコードすることができる。ブロック内のすべての有意係数の位置をエンコードする方法は、有意性マップ（ＳＭ）エンコードと呼ぶこともできる。以下でより詳細に説明する図９Ａ〜９Ｃは、量子化変換係数および対応するＳＭデータのの４×４ブロックの例を示す概念図である。量子化変換係数および対応するＳＭデータの４×４ブロックは、本開示の技術として、単に例の目的で示されたものであり、一般に、ビデオ・データの直交ブロックのスキャニングを効率的に実行することに関することを理解されたい。

典型的なＳＭエンコード手順は、以下のように説明することができる。ビデオ・データの所与のブロックについて、ブロック内に少なくとも１つ有意係数がある場合にのみ、ＳＭをエンコードすることができる。ビデオ・データの所与のブロック内の有意係数の存在を、ビデオ・データの画素領域に関連する１組のブロック（輝度およびクロミナンス・ブロック）についてコーディングされたバイナリ値である、コーディングブロック・パターンで（たとえば、シンタックス要素「ｃｏｄｅｄ＿ｂｌｏｃｋ＿ｐａｔｔｅｒｎ」またはＣＢＰを使用して）示すことができる。ＣＢＰの各ビットはコーディングブロック・フラグ（たとえば、シンタックス要素「ｃｏｄｅｄ＿ｂｌｏｃｋ＿ｆｌａｇ」に対応する）と呼ばれ、対応するブロック内に少なくとも１つの有意係数があるか否かを示すために使用される。言い換えると、コーディングブロック・フラグは、変換係数の単一のブロック内に有意係数があるか否かを示す１ビット・シンボルであり、ＣＢＰは、１組の関連するビデオ・データ・ブロックのための１組のコーディングブロック・フラグである。

コーディングブロック・フラグが、対応するブロック内に有意係数がないことを示す（たとえば、フラグが「０」である）場合、ブロックについてさらなる情報をエンコードすることができない。しかしながら、コーディングブロック・フラグが、対応するブロック内に少なくとも１つの有意係数が存在することを示す（たとえば、フラグが「１」である）場合、ブロックに関連する係数スキャニング順序をたどることにより、ＳＭをブロックについてエンコードすることができる。一部の実施形態では、有意係数は非ゼロの量子化変換係数を含むことができる。スキャン順序は、ブロック内の各係数の有意性がＳＭエンコードの一部としてエンコードされる順序を定義することができる。一部の実施形態では、有意係数が非ゼロの量子化変換係数を含むことができる。言い換えると、スキャニングは、係数の２次元ブロックを１次元表示に直列化して、係数の有意性を判定することができる。

異なるスキャニング順序、たとえばジグザグが、従来使用されている。以下でより詳細に説明する図１０は、ビデオ・データの８×８ブロックに対して従来使用されている種々のスキャニング順序の一部の例を示す。ビデオ・データの８×８ブロックは、本開示の技術として、単に例の目的で示されたものであり、一般に、ビデオ・データの直交ブロックのスキャニングを効率的に実行することに関することを理解されたい。

少なくとも１つの有意係数が所与のブロック内に存在することを示すコーディングブロック・フラグ、およびブロックについてのスキャニング順序を与えられると、ブロックについてのＳＭを以下のようにエンコードすることができる。量子化変換係数の２次元ブロックを、スキャニング順序を使用して、最初に１次元配列にマッピングすることができる。配列内の各係数について、スキャニング順序に従って、１ビット有意係数フラグ（たとえば、シンタックス要素「ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｆｌａｇ」に対応する）をエンコードすることができる。すなわち、配列内の各位置にバイナリ値が割り当てられ、バイナリ値は、対応する係数が有意である場合に「１」に設定され、対応する係数が非有意である（たとえばゼロである）場合に「０」に設定され得る。

所与の有意係数フラグが、対応する係数が有意であることを示す「１」である場合、さらなる１ビットの最後の有意係数フラグ（たとえば、シンタックス要素「ｌａｓｔ＿ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｆｌａｇ」に対応する）をエンコードすることもでき、対応する係数が、配列内（たとえば、スキャニング順序が与えられたブロック内）の最後の有意係数であるか否かを示すことができる。すなわち、対応する係数が配列内の最後の有意係数である場合には、各最後の有意係数フラグを「１」に、そうでない場合には「０」に設定することができる。このようにして最後の配列位置に到達し、ＳＭエンコード方法が、「１」である最後の有意係数フラグによって終わらない場合には、配列の最後の係数（および、これによりスキャン順序が与えられたブロック）を有意であると推測することができ、最後の有意係数フラグを最後の配列位置についてエンコードすることができない。

図９Ｂ、９Ｃは、図９Ａに示すブロックについてのＳＭデータに対応する、１組の有意係数フラグおよび最後の有意係数フラグそれぞれの例を、配列形式ではなくマップで示した概念図である。前述したように、他の例では、有意係数フラグおよび最後の有意係数フラグを、異なる値に設定することができる（たとえば、有意係数フラグを、対応する係数が有意である場合には「０」に、非有意である場合には「１」に設定することができ、最後の有意係数フラグを、対応する係数が最後の有意係数である場合には「０」に、最後の有意係数でない場合には「１」に設定することができる）ことに注目されたい。

前述したように、ＳＭがエンコードされた後、ブロック内の各有意係数の値（たとえば、シンタックス要素「ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｍｉｎｕｓ１」および「ｃｏｅｆｆ＿ｓｉｇｎ＿ｆｌａｇ」のそれぞれにより示される各有意係数の大きさおよび記号）をエンコードすることもできる。

図９Ａ〜９Ｃは、ビデオ・データのブロックおよび対応する有意係数位置情報および最後の有意係数位置情報のブロックの例を示す概念図である。
図９Ａに示すように、ビデオ・データのブロック、たとえば、マクロブロック、またはＣＵのＴＵは、量子化変換係数を含むことができる。たとえば、図９Ａに示すように、ブロック４００は、前述した予測、変換、および量子化技術を使用して生成した量子化変換係数を含むことができる。本例について、ブロック４００が２Ｎ×２Ｎのサイズを有し、Ｎが２であると仮定する。したがって、ブロック４００は４×４のサイズを有し、図９Ａに示すように１６個の量子化変換係数を含む。以下でより詳細に説明する図１０に示すように、ブロック４００に関連するスキャニング順序がジグザグ・スキャニング順序であるとさらに仮定する。本例では、ジグザグ・スキャニング順序によるブロック４００内の最後の有意係数が、ブロック４００内の位置４０６にある、「１」である量子化変換係数である。

図９Ｂは、有意係数フラグ・データ、たとえば、前述したマップまたはブロック形式で表される有意係数フラグの例を示す。図９Ｂの例では、ブロック４０２が、図９Ａに示すブロック４００に対応することができる。言い換えると、ブロック４０２の有意係数フラグは、ブロック４００の量子化変換係数に対応することができる。図９Ｂに示すように、「１」であるブロック４０２の有意係数フラグは、ブロック４００の有意係数に対応する。同様に、「０」であるブロック４０２の有意係数フラグは、ブロック４００のゼロまたは非有意係数に対応する。本例では、ジグザグ・スキャニング順序によるブロック４００内の最後の有意係数に対応するブロック４０２の有意係数フラグが、ブロック４０２内の位置４０８に位置する、「１」である有意係数フラグである。

図９Ｃは、最後の有意係数フラグ・データ、たとえば、前述したマップまたはブロック形式で表される最後の有意係数フラグの例を示す。図９Ｃの例では、ブロック４０４が、図９Ａおよび図９Ｂに示すブロック４００およびブロック４０２にそれぞれ対応することができる。言い換えると、ブロック４０４の最後の有意係数フラグが、ブロック４００の量子化変換係数、およびブロック４０２の有意係数フラグに対応することができる。図９Ｃに示すように、ジグザグ・スキャニング順序によれば、ブロック４０４内の位置４１０に位置する、「１」であるブロック４０４の最後の有意係数フラグは、「１」であるブロック４００の最後の有意係数およびブロック４０２の有意係数フラグの最後の１つに対応する。いずれの場合にも、ブロック４０２の有意係数フラグおよびブロック４０４の最後の有意係数フラグを、まとめてブロック４００についてのＳＭデータと呼ぶことができる。

前述したように、図９Ｂに示すブロック４０２に表されるように、ブロックに関連するスキャニング順序を使用して、ブロックについての有意係数フラグを、２次元ブロック表示から１次元配列に直列化することにより、ビデオ・データのブロックについての有意係数位置情報を示すことができる。図９Ａ、９Ｂに示すブロック４００〜４０２の例では、再びジグザグ・スキャニング順序を想定し、ブロック４０２の有意係数フラグ１次元配列に直列化することにより、ブロック４００についての有意係数位置情報を示すことができる。すなわち、ブロック４００の有意係数位置情報を、ジグザグ・スキャニング順序により、ブロック４０２の有意係数フラグのシーケンスを生成することによって示すことができる。

本例では、生成したシーケンスが、ジグザグ・スキャニング順序によるブロック４０２の最初の６個の有意係数フラグを表す値「１１１１１１」に対応することができる。ジグザグ・スキャニング順序の最初のブロック位置（たとえば、ＤＣ位置または最上部左端角）から始まり、ジグザグ・スキャニング順序によるブロック４００の最後の有意係数に対応するブロック位置（たとえば、「１」であるブロック４０４の最後の有意係数フラグに対応する）で終わる、ブロック４００内のブロック位置の範囲に対応する有意係数フラグを、生成したシーケンスが含むことができることに注目されたい。

前述したように、図９Ｃに示すブロック４０４に表されるように、ブロックに関連するスキャニング順序を使用して、ブロックについての最後の有意係数フラグを、２次元ブロック表示から１次元配列に直列化することにより、ブロックについての最後の有意係数位置情報を示すことができる。図９Ａ〜９Ｃに示すブロック４００〜４０４の例では、再びジグザグ・スキャニング順序を想定し、ブロック４０４の最後の有意係数フラグを１次元配列に直列化することによって、ブロック４００についての最後の有意係数位置情報を示すことができる。すなわち、ジグザグ・スキャニング順序により、ブロック４０４の最後の有意係数フラグのシーケンスを生成することによって、ブロック４００についての最後の有意係数位置情報を示すことができる。本例では、生成したシーケンスが、ジグザグ・スキャニング順序によるブロック４０４の最初の６個の最後の有意係数フラグを表す値「０００００１」に対応することができる。

図１０は、従来のジグザグ・スキャニング順序を使用してスキャンされたビデオ・データのブロックの例を示す概念図である。図１０に示すように、ビデオ・データの８×８ブロック、たとえば、マクロブロック、またはＣＵのＴＵが、円で示される対応するブロック位置内の６４個の量子化変換係数を含むことができる。たとえば、ブロック５００が、前述した予測、変換、および量子化技術を使用して生成した６４個の量子化変換係数を含むことができ、再び、ここでは各対応するブロック位置が円で示される。本例について、ブロック５００が２Ｎ×２Ｎサイズを有し、Ｎが４であると仮定する。したがって、ブロック５００は、８×８のサイズを有する。

図１０に示すように、ブロック５００に関連するスキャニング順序は、従来のジグザグ・スキャニング順序である。ジグザグ・スキャニング順序は、図１０に矢印で示すように、ブロック５００の量子化変換係数を斜めにスキャンする。

図１１は、ジグザグ・スキャニング順序を使用してスキャンされたビデオ・データのブロックのさらなる例を示す概念図である。図１１に示すように、ブロック６００が、矢印で示すように、かつ図１０を参照して前述したように、ジグザグ・スキャニング順序により０〜１５に順序付けされた１６個のブロック位置を含むことができる。１６個のブロック位置のそれぞれが、図９Ａを参照して前述したように、量子化変換係数を含むことができる。図１１に示すように、ジグザグ・スキャニング順序によるブロック６００内の第１および第２の位置は、位置「０」および「１」に対応し、それぞれ共通位置６０６および共通位置６０８と呼ぶことができる。一部の例では、共通位置６０６、６０８の１つまたは複数が、別のスキャニング順序によるビデオ・データの別のブロック内の第１および第２のブロック位置に一致することができる。

図１０および１１で前述し図示したように、ビデオ・データのブロックは、ジグザグ・パターンを使用してスキャンされ、これにより各ブロック位置が斜めにスキャンされ、次いで、対角線の端部に到達すると、スキャンが方向を変え、第２の対角線の端部に到達するまで続けられる。第２の対角線の端部に到達したときに、スキャンは再び方向を変える等する。このジグザグ・スキャンはビデオ・データの各ブロックをキャプチャするが、各ブロックが前のブロックのスキャンが終わるのを待たなければならないため、完全スキャンはいくぶん遅くなる。たとえば、ブロック６１２は、ブロック６１０がスキャンされるのを待たなければならず、ブロック６１０はブロック６０８がスキャンされるのを待たなければならず、ブロック６０８はブロック６０６がスキャンされるのを待たなければならない。結果として、ブロック６００内のすべてのブロックをスキャンする時間は、少なくとも個々のブロック６０６、６０８、６１０等をスキャンするのにかかる時間の合計となる。したがって、後に続く各ブロックについては前のブロックへの依存性がある。その結果、ジグザグ・スキャンを使用する、データの並行処理または並行データ収集は不可能である。

図１２に示すように、方形波面スキャンまたは固定斜めスキャンがＨＥＶＣに導入されている。本願明細書に援用する、ヴィ ズィー（Ｖ．Ｓｚｅ）およびエム ブダガヴィ（Ｍ．Ｂｕｄａｇａｖｉ）、「ＣＥ１１：Ｐａｒａｌｌｅｌｉｚａｔｉｏｎ ｏｆ ＨＨＩ＿ＴＲＡＮＳＦＯＲＭ＿ＣＯＤＩＮＧ（Ｆｉｘｅｄ Ｄｉａｇｏｎａｌ Ｓｃａｎ ｆｒｏｍ Ｃ２２７）」、ＪＣＴＶＣ−Ｆ１２９、Ｊｕｌｙ ２０１１を参照されたい。従来のジグザグ・スキャンを使用するのではなく、たとえば、ＣＡＢＡＣを使用するときに、すべてのスキャン・ラインが同一の斜めスキャン方向を有する。このスキャンの利点は、先にデコードされたデータ・ブロックまたはビンへの依存性がなくなることである。これまで、図１２に示すように、波面スキャンは方形ブロックのみに限定されている。

前述したように、ＨＥＶＣの利点の１つは、ビデオ・ブロックが、コーディング・ユニット、たとえば、ＬＣＵ、またはコーディング・ユニットの区画に対応することができ、サイズによって限定されないことである。これが望ましいのは、図１に示すように、フレームがしばしば直交形状であるか、または垂直方向にＮ画素、水平方向にＭ画素あり、ＮおよびＭが等しくない非負の整数値を有するＮ×Ｍを特徴とするからである。たとえば、さらに図１を参照すると、Ｎは８であり、Ｍは１２である。

一般に、フレームが直交であると、その区画またはサブブロックも直交になる可能性がある。ＨＥＶＣでは直交ＰＵを使用することができ、これは、一般に、直交ＰＵが直交オブジェクトについてより良好な予測を有するためである。同様に、直交変換を直交または方形予測残差のより良好な圧縮のために使用することができる。したがって、並行データ収集を使用可能な直交サブブロックについての効果的なスキャニング・パターンが望ましい。

さらに、ＨＥＶＣのより高いコーディング効率を達成するために、直交変換が最近提案されている。このより高いコーディング効率のための１つの考えられる説明は、直交変換が残差コーディングのより多くの選択肢を与えることができることである。たとえば、エンコーダが、所与のまたは所定の基準に従って、方形変換を使用すべきか、直交変換を使用すべきかを適応的に選択して、より高い圧縮効率を達成可能にすることができる。たとえば、本願明細書に援用する、ワイ ユエン（Ｙ．Ｙｕａｎ）、エックス ジュヨン（Ｘ．Ｚｈｅｎｇ）、エックス プオン（Ｘ．Ｐｅｎｇ）、ジェイ シュイ（Ｊ．Ｘｕ）、エル リウ（Ｌ．Ｌｉｕ）、ワイ ワーン（Ｙ．Ｗａｎｇ）、エックス ツァオ（Ｘ．Ｃａｏ）、シー ライ（Ｃ．Ｌａｉ）、ジェイ ジュヨン（Ｊ．Ｚｈｅｎｇ）、ワイ ホーァ（Ｙ．Ｈｅ）、およびエイチ ユイ（Ｈ．Ｙｕ）、「ＣＥ２：Ｎｏｎ−Ｓｑｕａｒｅ Ｑｕａｄｔｒｅｅ Ｔｒａｎｓｆｏｒｍｆｏｒ ｓｙｍｍｅｔｒｉｃ ｍｏｔｉｏｎ ｐａｒｔｉｔｉｏｎｓ」、ＪＣＴＶＣ−Ｆ４１０、Ｊｕｌｙ ２０１１、ワイ ユエン（Ｙ．Ｙｕａｎ）、エックス ジュヨン（Ｘ．Ｚｈｅｎｇ）、エックス プオン（Ｘ．Ｐｅｎｇ）、ジェイ シュイ（Ｊ．Ｘｕ）、ワイ ケー キム（Ｉ．−Ｋ Ｋｉｍ）、エル リウ（Ｌ．Ｌｉｕ）、ワイ ワーン（Ｙ．Ｗａｎｇ）、エックス ツァオ（Ｘ．Ｃａｏ）、シー ライ（Ｃ．Ｌａｉ）、ジェイ ジュヨン（Ｊ．Ｚｈｅｎｇ）、ワイ ホーァ（Ｙ．Ｈｅ）、およびエイチ ユイ（Ｈ．Ｙｕ）、「ＣＥ２：Ｎｏｎ−Ｓｑｕａｒｅ Ｑｕａｄｔｒｅｅ Ｔｒａｎｓｆｏｒｍ ｆｏｒ ｓｙｍｍｅｔｒｉｃ ａｎｄ ａｓｙｍｍｅｔｒｉｃ ｍｏｔｉｏｎ ｐａｒｔｉｔｉｏｎｓ」、ＪＣＴＶＣ−Ｆ４１２、Ｊｕｌｙ ２０１１、ならびにエル グオ（Ｌ．Ｇｕｏ）、ジェイ ソール（Ｊ．Ｓｏｌｅ）、アール ジョシ（Ｒ．Ｊｏｓｈｉ）、ピー チェン（Ｐ．Ｃｈｅｎ）、エックス ワーン（Ｘ．Ｗａｎｇ）、およびエム カルツェウィッツ（Ｍ．Ｋａｒｃｚｅｗｉｃｚ）、「Ｎｏｎ−Ｓｑｕａｒｅ Ｔｒａｎｓｆｏｒｍ ｆｏｒ ２ＮｘＮ ａｎｄ Ｎｘ２Ｎ Ｍｏｔｉｏｎ Ｐａｒｔｉｔｉｏｎｓ」、ＪＣＴＶＣ−Ｆ５６３、Ｊｕｌｙ ２０１１を参照されたい。

結果として、すべてのスキャン・ラインが同一のスキャン方向である直交変換のための波面スキャンを使用することが提案される。波面スキャンのスキャン方向は、任意の角度θとすることができる。図１３Ａ〜１３Ｄは、θが０°、４５°、−９０°および−１３５°の場合の直交ブロックまたはサブブロックの効果的なスキャニングを可能にする、このような例のスキャン・パターンを示す。

直交形状波面スキャンの４つの特定の変化は以下のように示される。図１４は、各スキャン・ライン上の量子化変換係数が左下から右上へ処理される、４５°のスキャン方向の全順方向直交形状波面スキャンの例を示す。図１５は、各スキャン・ライン上の量子化変換係数が左下から右上へ処理される、４５°のスキャン方向の全逆方向直交形状波面スキャン・パターンの例を示す。図１６は、各スキャン・ライン上の量子化変換係数が右上から左下へ処理される、−１３５°のスキャン方向の全順方向直交形状波面スキャンの例を示す。図１７は、各スキャン・ライン上の量子化変換係数が右上から左下へ処理される、−１３５°のスキャン方向の全逆方向直交形状波面スキャンの例を示す。

図１４〜１７を検討すると、各スキャン・ラインが比較的独立し、たとえば、前のスキャン・ラインからの依存性が小さいことが明らかであろう。比較的小さいものであり得るが、いくらかの遅れがあることを理解されたい。このような遅れは、各ライン間の依存性が小さいことによるものであり得るが、しかしながら、遅れは、他のスキャン、たとえばジグザグと比べると小さいものであり得る。結果として、各ラインをほぼ同時にスキャンすることができ、このことは、データ・ブロック・データを処理するのに必要な全時間が、単一のスキャン・ラインを、たとえば、いくらかの遅れを伴ってスキャンするのにかかる時間の長さの関数であり得ることを意味する。しかしながら、第１のスキャン・ラインのスキャン開始後に第２のスキャン・ラインのスキャンを開始して、第２のラインのブロックにすぐ隣接または近接するブロックが、第１のスキャン・ラインですでにスキャンされているようにすることが望ましくあり得るため、制限があり得る。たとえば、順方向スキャン、たとえば、波面またはジグザグについては、すぐ右の位置の状況モデリングのために使用可能であるため、左隣を最初にデコードすることが望ましくあり得る。同様に、逆方向スキャンについては、すぐ右の位置の状況モデリングのために使用可能であるため、右隣を最初にデコードすることが望ましくあり得る。複数のラインをほぼ同時に、たとえばいくらか並行してスキャンすることにより、エントロピーエンコードにおいてより高い読み取り速度を達成することができることを理解されたい。加えて、少なくとも一部には、スキャンされたデータの並行処理によって、計算複雑性効率を高めることができる。

一般に、ＴＵ内の高周波変換係数は、ＤＣまたは低周波変換係数よりも小さいエネルギーを有する。一般に、たとえば、変換係数についての高周波および低周波数は、相対概念である。高周波数は、より急速に変化する周波数成分を意味し、低周波数は、よりゆっくりと変化する周波数成分を意味する。すなわち、変換（たとえばＤＣＴ）後のビデオ圧縮において、ＤＣは左上位置（０、０位置）の成分である。低周波数は左上角の成分であり、高周波数は右下角の成分である。

別の方法で説明すると、離散信号処理（ＤＳＰ）において、空間領域のＮ×Ｍサンプルのブロックが、しばしば変換領域のＮ×Ｍ係数のブロックに変換される。各変換係数は、ブロックについてのある周波数でのエネルギーを表す。自然ビデオ・ピクチャのブロックは、しばしば、低周波数のエネルギーをより多く、高周波数のエネルギーをより少なく有する。このため、自然ビデオ・ピクチャのブロックについて、大きい低周波係数および小さい高周波係数がしばしば見られる。

したがって、詳細に前述したように、量子化後に多くの高周波係数が０になる。十分に設計されたエントロピー・コードは、しばしば、この量子化変換係数の特徴を利用する。一部の実施形態では、最後の非ゼロの量子化変換係数が、順方向スキャンの意味で特定されると想定することができる。これは、図９の説明で前述した有意係数フラグを使用して達成することができる。

順方向スキャンを使用する場合、最後の非ゼロの量子化係数が生成されると、スキャン・パスに沿ったさらなるコーディングは必要なくなる。一方、逆方向または後方向スキャンを使用する場合、コーディングが最後の非ゼロの係数から始まり得る。特定の（順方向または後方向）スキャンについて最後の非ゼロの係数の位置情報を、異なる方法を使用してコーディングすることができる。たとえば、ｌａｓｔ＿ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｆｌａｔ等のフラグを使用して、非ゼロの係数が最後か否かを示すことができる。あるいは、本願明細書に援用する、ジェイ ソール（Ｊ．Ｓｏｌｅ）、アール ジョシ（Ｒ．Ｊｏｓｈｉ）、エム カルツェウィッツ（Ｍ．Ｋａｒｃｚｅｗｉｃｚ）、「ＣＥ１１：Ｐａｒａｌｌｅｌ Ｃｏｎｔｅｘｔ Ｐｒｏｃｅｓｓｉｎｇ ｆｏｒ ｔｈｅ ｓｉｇｎｉｆｉｃａｎｃｅ ｍａｐ ｉｎ ｈｉｇｈ ｃｏｄｉｎｇ ｅｆｆｉｃｉｅｎｃｙ」、ＪＣＴＶＣ−Ｅ３３８、Ｍａｒｃｈ ２０１１に記載されているように、最後の非ゼロの係数の座標、ｌａｓｔ＿ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｘおよびｌａｓｔ＿ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆ＿ｙをコーディングすることができる。

最後の非ゼロの量子化変換係数で終わる、または始まる直交形状波面スキャンの４つの特定の変化は、以下のように表される。図１８は、各スキャン・ライン上の量子化変換係数が左下から右上へ処理される、４５°のスキャン方向の部分順方向直交形状波面スキャンの例を示す。本例では、方法は、最後の非ゼロの量子化変換係数で停止する。図１９は、各スキャン・ライン上の量子化変換係数が左下から右上へ処理される、４５°のスキャン方向の部分逆方向直交形状波面スキャン・パターンの例を示す。本例では、方法が最後の非ゼロの量子化変換係数から始まる。図２０は、各スキャン・ライン上の量子化変換係数が右上から左下へ処理される、−１３５°のスキャン方向の部分順方向直交形状波面スキャンの例を示す。本例では、方法が、最後の非ゼロの量子化変換係数で停止する。図２１は、各スキャン・ライン上の量子化変換係数が右上から左下へ処理される、−１３５°のスキャン方向の部分逆方向直交形状波面スキャンの例を示す。本例では、方法が、最後の非ゼロの量子化変換係数から始まる。

図１４〜１７および１８〜２１の比較により、主な差は、図１８〜２１が最後の非ゼロの量子化変換係数までスキャンするのみであるか、または最後の非ゼロの量子化変換係数でスキャニングを開始するかであることが明らかになる。結果として、図１８〜２１は、一般に、スキャンしコーディングする係数がより少なく、図１４〜１７にわたって高い効率（たとえば、ビット保存）を提供することを理解されたい。

異なるサイズの直交ブロックにおけるスキャン指数と係数の座標とのマッピングを示すテーブル１〜１２が、以下に示される。他の例では、ブロックが、テーブル１〜１２に挙げたブロックのサイズよりも小さいかまたは大きいサイズを有することができ、より多いまたは少ない量子化変換係数および対応するブロック位置を有することができる。このような例では、ブロックに関連するスキャニング順序が、図１４〜１７および１８〜２１の直交ブロックの例に示すものとほぼ同様の方法で、ブロックの量子化変換係数をスキャンすることができ、たとえば、ブロックを、前述したスキャニング順序のいずれかに従ってスキャンすることができる。

全８×２波面スキャン・パターンの例

全２×８波面スキャン・パターンの例

全８×４波面スキャン・パターンの例

全４×８波面スキャン・パターンの例

全１６×４波面スキャン・パターンの例

全４×１６波面スキャン・パターンの例

全１６×８波面スキャン・パターンの例

全８×１６波面スキャン・パターンの例

全３２×８波面スキャン・パターンの例

全８×３２波面スキャン・パターンの例

全３２×１６波面スキャン・パターンの例

全１６×３２波面スキャン・パターンの例

このようにして、本開示の技術により、ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０は、他の方法を使用するときよりも効率的に、直交ブロックの波面スキャンを実行することができるようになる。このようにして、本開示の技術を使用したとき、並行処理機能に対応するかなりの時間節約があり得る。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、それぞれ、可能な場合には、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、離散論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組合せ等の種々の適切なエンコーダまたはデコーダ回路のいずれかとして実施され得る。ビデオ・エンコーダ２０およびビデオ・デコーダ３０のそれぞれは、複合ビデオ・エンコーダ／デコーダ（コーデック）の一部として組み込み可能な１つまたは複数のエンコーダまたはデコーダに含まれてもよい。ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０を備えた装置は、集積回路、マイクロプロセッサ、および／または携帯電話等の無線通信デバイスを含むことができる。

図２２は、本開示の技術に一致する、ビデオ・データの直交ブロックのスキャニングを効率的に実行するための技術を実施可能なビデオ・エンコーダ２０の例を示すブロック図である。ビデオ・エンコーダ２０は、マクロブロック、ＣＵ、および区画またはそのサブ区画を含む、ビデオ・フレーム内のブロックのイントラおよびインターコーディングを実行することができる。イントラコーディングは空間予測に依拠して、所与のビデオ・フレーム内のビデオの空間冗長性を低減させ、または除去する。インターコーディングは時間予測に依拠して、ビデオ・シーケンスの隣接するフレーム内のビデオの時間冗長性を低減させ、または除去する。イントラモード（Ｉモード）は、複数の空間ベース圧縮モード、および１方向予測（Ｐモード）または双方向予測（Ｂモード）等のインターモードのいずれかを指すことができ、複数の時間ベース圧縮モードを指すことができる。

図２２に示すように、ビデオ・エンコーダ２０は、エンコードするビデオ・フレーム内のビデオ・データの現在のブロックを受信する。図２２の例では、ビデオ・エンコーダ２０が、動き補償ユニット４４、動き推定ユニット４２、メモリ６４、アナログ加算器５０、変換モジュール５２、量子化ユニット５４、およびエントロピーエンコードユニット５６を備える。ビデオ・ブロック再構成のために、ビデオ・エンコーダ２０は、逆量子化ユニット５８、逆変換モジュール６０、およびアナログ加算器６２をさらに備える。ブロック解除フィルタまたは適応ループ・フィルタ（図２２には示されていない）を備えて、たとえば、ブロック境界を平滑化し、入力ピクチャと出力ピクチャとのコーディング歪みを最小限にするために、ブロック境界をフィルタリングして、再構成されたビデオからブロック性アーチファクトを除去することもできる。希望に応じて、ブロック解除フィルタは、典型的には、アナログ加算器６２の出力をフィルタリングする。

エンコード方法中に、ビデオ・エンコーダ２０が、コーディングするビデオ・フレームまたはスライスを受信する。フレームまたはスライスを複数のビデオ・ブロックに分割することができる。動き推定ユニット４２および動き補償ユニット４４は、１つまたは複数の基準フレームの１つまたは複数のブロックに対して所与の受信ビデオ・ブロックのインター予測コーディングを実行して、時間圧縮を施すことができる。イントラ予測モジュール４６は、コーディングするブロックと同一のフレームまたはスライスの１つまたは複数の隣接ブロックに対して所与の受信ビデオ・ブロックのイントラ予測コーディングを実行して、空間圧縮を施すことができる。

モード選択ユニット４０は、コーディングの結果（たとえば、結果として生じるコーディング速度および歪みのレベル）に基づき、かつコーディングされている所与の受信ブロックを含むフレームまたはスライスのフレームまたはスライス・タイプに基づき、コーディングモード、たとえば、１つのモードまたは複数のイントラもしくはインターコーディングモードの１つを選択することができ、結果として生じるイントラまたはインターコーディングブロックを、アナログ加算器５０に供給して残差ブロック・データを生成し、アナログ加算器６２に供給して、基準フレームまたは基準スライスで使用するエンコードブロックを再構成することができる。一般に、イントラ予測は、隣接する、先にコーディングされたブロックに対して現在のブロックを予測することを含み、インター予測は、現在のブロックを時間予測する動き推定および動き補償を含む。一部の実施形態では、再構成されたピクチャが基準ピクチャである場合、これらのピクチャが、さらなる時間予測のために基準バッファ（図示せず）またはメモリ６４に記憶される。

動き推定ユニット４２および動き補償ユニット４４は、ビデオ・エンコーダ２０のインター予測要素を表す。動き推定ユニット４２および動き補償ユニット４４は、高度に一体化されていてもよいが、概念的な目的で別個に図示されている。動き推定は、ビデオ・ブロックの動きを推定する、動きベクトルを生成する方法である。動きベクトルは、たとえば、現在のフレーム（または他のコーディング・ユニット）内でコーディングされている現在のブロックに対する、予測基準フレーム（または他のコーディング・ユニット）内の予測ブロックの変位を示すことができる。予測ブロックは、絶対差の和（ＳＡＤ）、平方差の和（ＳＳＤ）、または他の差の測定基準によって判定され得る画素差に関して、コーディングするブロックに厳密に一致すると認められるブロックである。動きベクトルは、ブロックの区画の変位を示すこともできる。動き補償は、動き推定によって判定される動きベクトルに基づいて、予測ブロックをフェッチし、または生成することを含み得る。再び、動き推定ユニット４２および動き補償ユニット４４は、一部の例では、機能的に一体化されていてもよい。

動き推定ユニット４２は、ビデオ・ブロックをメモリ６４内の基準フレームのビデオ・ブロックと比較することによって、インターコーディングフレームのビデオ・ブロックについて動きベクトルを算出することができる。動き補償ユニット４４は、基準フレーム、たとえば、Ｉフレーム、Ｂフレーム、またはＰフレームのサブ整数画素を、この比較の目的で内挿することもできる。

動き推定ユニット４２は、メモリ６４からの１つまたは複数の基準フレームのブロックを、現在のフレーム、たとえば、ＰフレームまたはＢフレームのエンコードするブロックと比較することができる。一部の実施形態では、ＰおよびＢフレームを、基準ピクチャまたはフレームとして使用可能な一般的なＢピクチャに統合することができる。メモリ６４内の基準フレームがサブ整数画素の値を有するとき、動き推定ユニット４２によって算出された動きベクトルは、基準フレームのサブ整数画素位置を指すことができる。動き推定ユニット４２および／または動き補償ユニット４４は、サブ整数画素位置の値がメモリ６４に記憶されていない場合に、メモリ６４に記憶された基準フレームのサブ整数画素位置の値を算出するように構成され得る。動き推定ユニット４２は、算出された動きベクトルをエントロピーエンコードユニット５６および動き補償ユニット４４に送信することができる。動きベクトルにより特定された基準フレーム・ブロックを、インター予測ブロック、またはより一般的には、予測ブロックと呼ぶことができる。動き補償ユニット４４は、予測ブロックに基づいて予測データを算出することができる。

イントラ予測モジュール４６は、前述したような動き推定ユニット４２および動き補償ユニット４４により実行されるインター予測の代わりとして、現在のブロックをイントラ予測することができる。特に、イントラ予測モジュール４６は、現在のブロックをエンコードするために使用するイントラ予測モードを判定することができる。一部の例では、イントラ予測モジュール４６は、たとえば、別個のエンコードパス中に、種々のイントラ予測モードを使用して現在のブロックをエンコードすることができ、イントラ予測モジュール４６（または、一部の例ではモード選択ユニット４０）は、使用する適切なイントラ予測モードを試験済みモードから選択することができる。たとえば、イントラ予測モジュール４６は、種々の試験済みイントラ予測モードについての速度−歪み分析を使用して速度−歪み値を算出し、試験済みモードの中から最良の速度−歪み特徴を有するイントラ予測モードを選択する。速度−歪み分析は、一般に、エンコードブロックと、エンコードされてエンコードブロックを生成する、オリジナルのエンコードされていないブロックとの歪み（またはエラー）の量、ならびにエンコードブロックを生成するために使用されるビットレート（すなわちビット数）を判定する。イントラ予測モジュール４６は、種々のエンコードブロックについての歪みおよび速度から割合を算出して、どのイントラ予測モードが、ブロックについての最良の速度−歪み値を呈するかを判定することができる。

たとえば、イントラ予測またはインター予測を使用して現在のブロックを予測した後、ビデオ・エンコーダ２０は、動き補償ユニット４４またはイントラ予測モジュール４６により算出された予測データを、コーディングされているオリジナルのビデオ・ブロックから減算することにより、残差ビデオ・ブロックを形成することができる。アナログ加算器５０は、この減算動作を実行可能な１つまたは複数の部品を表す。変換モジュール５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換等の変換を残差ブロックに適用して、残差変換係数値を含むビデオ・ブロックを生成することができる。変換モジュール５２は、ＤＣＴと概念的に同様のＨ．２６４規格により定義された変換等の他の変換を実行することができる。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換を使用することもできる。いずれの場合にも、変換モジュール５２は、残差ブロックに変換を適用して、残差変換係数のブロックを生成することができる。変換は、残差情報を画素領域から、周波数領域等の変換領域へ変換する。量子化ユニット５４は、残差変換係数を量子化して、ビットレートをさらに低下させる。量子化方法は、係数の一部または全部に関連するビット深さを減少させることができる。量子化パラメータを調節することにより、量子化の度合いを修正することができる。

量子化に続いて、エントロピーエンコードユニット５６は、量子化変換係数をエントロピーエンコードすることができ、これはＣＡＶＬＣ、ＣＡＢＡＣ、ＰＩＰＥ、または別のエントロピー・コーディング技術を含み得る。エントロピーエンコードユニット５６によるエントロピー・コーディングに続いて、エンコードビデオを別のデバイスに送信することができ、または後で送信または読み出しを行うためにアーカイブすることができる。

場合によっては、ビデオ・エンコーダ２０のエントロピーエンコードユニット５６または別のユニットを、前述したエントロピー・コーディング量子化変換係数に加えて、他のコーディング機能を実行するように構成することができる。たとえば、エントロピーエンコードユニット５６は、ブロックについての（たとえば、マクロブロック、ＣＵ、もしくはＬＣＵ）ヘッダ情報、またはブロックを含むビデオ・フレームを、エンコードビデオ・ビットストリームで送信するための適切なシンタックス要素によって構成することができる。この開示は、他の方法を使用するときよりも効率的に直交ブロック情報のスキャニングを実行可能な技術を説明する。

たとえば、ビデオ・エンコーダ２０のエントロピーエンコードユニット５６を、ビデオ・データのあるブロック（たとえば、１つまたは複数のマクロブロック、またはＣＵのＴＵ）をエンコードするように構成することができる。本開示の技術によれば、一例として、エントロピーエンコードユニット５６を、特定のスキャン・タイプおよび特定の状況モデル選択方式を使用して、現在のＴＵのための有意性マップをエンコードするように構成することができる。エントロピーエンコードについてのさらなる詳細が、本願明細書に援用する、２０１２年７月１６日提出の米国特許出願第１３／５５０，４９３号、「ＣＯＮＴＥＸＴ ＭＯＤＥＬＩＮＧ ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＴＲＡＮＳＦＯＲＭ ＣＯＥＦＦＩＣＩＥＮＴ ＬＥＶＥＬ ＣＯＤＩＮＧ」からわかる。

逆量子化ユニット５８および逆変換モジュール６０は、それぞれ逆量子化および逆変換を適用して、たとえば、基準ブロックとして後で使用するために、画素領域の残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックをメモリ６４のフレームの１つの予測ブロックに加算することにより、基準ブロックを算出することができる。また、動き補償ユニット４４は、１つまたは複数の内挿フィルタを再構成された残差ブロックに適用して、動き推定で使用するためのサブ整数画素値を算出することができる。アナログ加算器６２は、再構成された残差ブロックを、動き補償ユニット４４により生成された動き補償予測ブロックに加算して、メモリ６４に記憶させるための、再構成されたビデオ・ブロックを生成する。再構成されたビデオ・ブロックを、動き推定ユニット４２および動き補償ユニット４４により、次のビデオ・フレームのブロックをインターコーディングするための基準ブロックとして使用することができる。

図２３は、本開示の技術に一致する、ビデオ・データの直交ブロックについてのエンコードスキャニング情報を効率的にデコードするための技術を実施可能なビデオ・デコーダ３０の例を示すブロック図である。図２３の例では、ビデオ・デコーダ３０が、エントロピーデコードユニット７０、動き補償ユニット７２、イントラ予測モジュール７４、逆量子化ユニット７６、逆変換モジュール７８、メモリ８２、およびアナログ加算器８０を備える。ビデオ・デコーダ３０は、一部の例では、ビデオ・エンコーダ２０（図２２）に関して説明したエンコードパスと一般に逆であるデコードパスを実行することができる。動き補償ユニット７２は、エントロピーデコードユニット７０から受信した動きベクトルに基づいて予測データを生成することができる。

たとえば、ビデオ・デコーダ３０を、エンコードビデオ・データ（たとえば、１つまたは複数のマクロブロック、またはＣＵのＴＵ）をビデオ・エンコーダ２０から受信するように構成することができる。エントロピーデコードユニット７０を、特定のスキャン・タイプおよび特定の状況モデル選択方式を使用して、現在のＴＵについての有意性マップをデコードするように構成することができる。エントロピーデコードについてのさらなる詳細が、本願明細書に援用する、２０１２年７月１６日提出の米国特許出願第１３／５５０，４９３号、「ＣＯＮＴＥＸＴ ＭＯＤＥＬＩＮＧ ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＴＲＡＮＳＦＯＲＭ ＣＯＥＦＦＩＣＩＥＮＴ ＬＥＶＥＬ ＣＯＤＩＮＧ」からわかる。

このようにして、本開示の技術により、エントロピーデコードユニット７０は、他の方法を使用するときよりも効率的に、直交ブロックについてのスキャニング情報をデコードすることができる。このようにして、本開示の技術を使用したとき、並行処理機能に対応するかなりの時間節約があり得る。

動き補償ユニット７２は、ビットストリームで受信された動きベクトルを使用して、メモリ８２内の基準フレームの予測ブロックを特定することができる。イントラ予測モジュール７４は、ビットストリームで受信されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成する。

イントラ予測モジュール７４は、エンコードブロックについてのイントラ予測モードの表示を使用して、たとえば、隣接する、先にデコードされたブロックの画素を用いてエンコードブロックをイントラ予測することができる。ブロックがインター予測モードエンコードされる例については、エンコードブロックについての動き補償予測データを読み出すために、動き補償ユニット７２が動きベクトルを定義する情報を受信する。いずれの場合にも、動き補償ユニット７２またはイントラ予測モジュール７４が、予測ブロックを定義する情報をアナログ加算器８０に提供することができる。

逆量子化ユニット７６は、ビットストリームに設けられ、エントロピーデコードユニット７０によりデコードされた量子化ブロック係数を逆量子化、たとえば、非量子化する。逆量子化方法は、たとえば、Ｈ．２６４デコード規格により定義され、ＨＥＶＣ試験モデルにより実行される従来の方法を含むことができる。逆量子化方法は、各ブロックについてのビデオ・エンコーダ２０により算出された量子化パラメータＱＰｙの使用を含んで、量子化の程度、および同様に、適用可能な逆量子化の程度を判定することができる。

逆変換モジュール７８は、画素領域に残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換方法を変換係数に適用する。動き補償ユニット７２は、内挿フィルタに基づく内挿を場合によって実行する動き補償ブロックを生成する。サブ画素精度による動き推定に使用する内挿フィルタの識別子が、シンタックス要素に含まれていてもよい。動き補償ユニット７２は、ビデオ・ブロックのエンコード中にビデオ・エンコーダ２０により使用される内挿フィルタを使用して、基準ブロックのサブ整数画素の内挿値を算出することができる。動き補償ユニット７２は、受信したシンタックス情報によって、ビデオ・エンコーダ２０により使用される内挿フィルタを判定し、内挿フィルタを使用して予測ブロックを生成することができる。

動き補償ユニット７２は、エンコードビデオ・シーケンスの１つまたは複数のフレームをエンコードするために使用されるブロックのサイズを判定するための、エンコードブロックについてのシンタックス情報、エンコードビデオ・シーケンスのフレームまたはスライスの各ブロックがどのように区画されるかを説明する区画情報、各区画がどのようにエンコードされるかを示すモード、各インターエンコードブロックまたは区画についての１つまたは複数の基準フレーム（および基準フレーム・リスト）、およびエンコードビデオ・シーケンスをデコードするための他の情報の一部を使用する。また、イントラ予測モジュール７４は、エンコードブロックについてのシンタックス情報を使用して、たとえば、前述したように、隣接する、先にデコードされたブロックの画素を用いて、エンコードブロックをイントラ予測する。

アナログ加算器８０は、残差ブロックを、動き補償ユニット７２またはイントラ予測モジュール７４により生成した対応する予測ブロックと合計して、デコードブロックを形成する。望ましい場合には、ブロック性アーチファクトを除去するために、ブロック解除フィルタを適用してデコードブロックをフィルタリングしてもよい。次いで、デコードビデオ・ブロックはメモリ８２に記憶され、次の動き補償のための基準ブロックを提供し、また、表示デバイス（図２２の表示デバイス３２等）へ表示するためのデコードビデオを生成する。

開示された実施形態の前記説明は、当業者が本発明を製造または使用することを可能にするために提示されたものである。これらの実施形態に対する種々の変更が当業者には容易に明らかであり、本発明の精神または範囲から逸脱することなく、本明細書に記載された一般的原理を他の実施形態に適用することができる。したがって、本明細書に提示された説明および図面は、本発明の例示的な実施形態を示し、したがって、本発明により広く考慮される主題を代表するものであることを理解されたい。さらに、本発明の範囲は他の実施形態を完全に包含し、したがって、本発明の範囲は、添付の特許請求の範囲以外の何物によっても限定されないことをさらに理解されたい。

Claims (20)

1. 複数のピクチャを有するデジタル・ビデオ・シーケンスをコーディングするための方法であって、
   （ａ）該複数のピクチャの少なくとも１つをブロックに分割する工程と、
   （ｂ）該ブロックの少なくとも１つに対し直交変換を実行して、１つまたは複数の変換係数を生成する工程と、
   （ｃ）該１つまたは複数の変換係数に量子化を実行する工程と、
   （ｄ）該１つまたは複数の変換係数を１度に１つ、コーディングスキャン順序に沿ってエンコードして、圧縮ビットストリームを生成する工程とを備え、
   該コーディングスキャン順序が、順方向波面スキャン順序または逆方向波面スキャン順序を含み、
   該量子化により量子化変換係数を生成する方法。
2. 工程（ａ）の前記ブロックをより小さいサブブロックに分割する工程をさらに備える、請求項１に記載の方法。
3. 前記順方向波面スキャン順序が、第１の非ゼロの変換係数またはＤＣ係数においてスキャニングを開始するように構成される、請求項１に記載の方法。
4. 前記逆方向波面スキャン順序が、最後の非ゼロの変換係数においてスキャニングを開始するように構成される、請求項１に記載の方法。
5. 前記直交変換が、１２８×１２８画素よりも小さいブロックに適用される、請求項１に記載の方法。
6. 前記１つまたは複数の変換係数が、変換係数の複数のラインがあるように１つの変換ブロックにより表され、
   前記方法は、変換係数の少なくとも２つのラインを並行してエンコードする工程をさらに備える、請求項１に記載の方法。
7. 前記エンコードする工程が、単一の方向に実行される、請求項６に記載の方法。
8. プロセッサと、該プロセッサに連結されたメモリとを有するコンピュータで実施され、工程（ａ）〜（ｄ）の少なくとも一部が該プロセッサを使用して実行される、請求項１に記載の方法。
9. 複数のピクチャを有するデジタル・ビデオ・シーケンスをコーディングするための装置であって、
   該複数のピクチャの少なくとも１つをブロックに分割し、
   該ブロックの少なくとも１つに対し直交変換を実行して、１つまたは複数の変換係数を生成し、
   該１つまたは複数の変換係数に量子化を実行し、
   該１つまたは複数の変換係数を１度に１つ、コーディングスキャン順序に沿ってエンコードして、圧縮ビットストリームを生成するように構成されたビデオ・コーダを備え、
   該コーディングスキャン順序が、順方向波面スキャン順序または逆方向波面スキャン順序を含み、
   該量子化により量子化変換係数を生成する装置。
10. 集積回路、
    マイクロプロセッサ、および
    前記ビデオ・コーダを備えた無線通信デバイスの少なくとも１つを備える、請求項９に記載の装置。
11. 前記１つまたは複数の変換係数が、変換係数の複数のラインがあるように１つの変換ブロックにより表され、
    前記装置は、変換係数の少なくとも２つのラインを同時にエンコードするために並行して動作するように構成された複数のマイクロプロセッサをさらに備える、請求項９に記載の装置。
12. 前記順方向波面スキャン順序が、第１の非ゼロの変換係数またはＤＣ係数でスキャニングを開始するように構成される、請求項９に記載の装置。
13. 前記逆方向波面スキャン順序が、最後の非ゼロの変換係数でスキャニングを開始するように構成される、請求項９に記載の装置。
14. 圧縮ビットストリームを処理するための方法であって、
    （ａ）該圧縮ビットストリームを受信する工程と、
    （ｂ）該圧縮ビットストリームを処理して、直交変換の１つまたは複数の変換係数を生成する工程とを備え、
    該１つまたは複数の変換係数を、１度に１つ、該直交変換のコーディングスキャン順序に沿って生成し、
    該コーディングスキャン順序が、順方向波面スキャン順序または逆方向波面スキャン順序を含む方法。
15. （ｃ）該１つまたは複数の変換係数に量子化を実行する工程をさらに備える、請求項１４に記載の方法。
16. （ｄ）該１つまたは複数の変換係数で逆直交変換を実行する工程をさらに備える、請求項１４に記載の方法。
17. 圧縮ビットストリームを処理するための装置であって、
    該圧縮ビットストリームを受信し、
    該圧縮ビットストリームを処理して、直交変換の１つまたは複数の変換係数を生成するように構成されたビデオ・デコーダを備え、
    該１つまたは複数の変換係数を、１度に１つ、該直交変換のコーディングスキャン順序に沿って生成し、
    該コーディングスキャン順序が、順方向波面スキャン順序または逆方向波面スキャン順序を含む装置。
18. 集積回路、
    マイクロプロセッサ、および
    前記ビデオ・デコーダを備えた無線通信デバイスの少なくとも１つからなる、請求項１７に記載の装置。
19. 前記順方向波面スキャン順序が、第１の非ゼロの変換係数またはＤＣ係数においてスキャニングを開始するように構成される、請求項１７に記載の装置。
20. 前記逆方向波面スキャン順序が、最後の非ゼロの変換係数においてスキャニングを開始するように構成される、請求項１７に記載の装置。