JP6234994B2 - ビデオ・コーディングのためのウェーブフロント並列処理 - Google Patents

Description

優先権主張

本願は、２０１２年４月１１日出願の米国仮出願６１／６２２，９７４、および２０１２年４月３０日出願の米国仮出願６１／６４０，５２９の利益を主張する。これら出願のおのおのの内容全体が、本明細書において、参照によって組み込まれている。

本開示は、ビデオ・コーディングに関連する。

デジタル・ビデオ機能は、デジタル・テレビ、デジタル・ダイレクト・ブロードキャスト・システム、無線ブロードキャスト・システム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップ・コンピュータ、タブレット・コンピュータ、ｅブック・リーダ、デジタル・カメラ、デジタル記録デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・デバイス、ビデオ・ゲーム・コンソール、セルラまたは衛星ラジオ電話、いわゆる「スマート・フォン」、ビデオ・テレビ会議デバイス、ビデオ・ストリーミング・デバイス等を含む広範囲のビデオに組み込まれうる。デジタル・ビデオ・デバイスは、例えば、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、パート１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）、現在開発中の高効率ビデオ・コーディング（ＨＥＶＣ）規格、およびこれら規格の拡張版によって定義された規格において記載されているようなビデオ・コーディング技法を実施する。これら規格の拡張は、例えば、Ｈ．２６４／ＡＶＣのスケーラブル・ビデオ・コーディング（ＳＶＣ）拡張およびマルチビュー・ビデオ・コーディング（ＭＶＣ）拡張を含む。ビデオ・デバイスは、このようなビデオ・コーディング技法を実施することによって、デジタル・ビデオ情報をより効率的に送信、受信、エンコード、デコード、および／または、格納しうる。

ビデオ・コーディング技法は、ビデオ・シーケンスに固有の冗長性を低減または除去するために、空間（イントラ・ピクチャ）予測、および／または、時間（インタ・ピクチャ）予測を含む。ブロック・ベースのビデオ・コーディングのために、ビデオ・スライス（例えば、ビデオ・フレーム、またはビデオ・フレームの一部分）が、ツリーブロック、コーディング・ユニット（ＣＵ）、および／または、コーディング・ノードとも称される複数のビデオ・ブロックへ分割されうる。ピクチャのイントラ・コード（Ｉ）スライスにおけるビデオ・ブロックは、同じピクチャ内の近隣ブロックにおける基準サンプルに対する空間予測を用いてエンコードされる。ピクチャのインタ・コード（ＰまたはＢ）スライスにおけるビデオ・ブロックは、同じピクチャ内の近隣ブロックにおける基準サンプルに対する空間予測を用いるか、別の基準ピクチャにおける基準サンプルに対する時間予測を用いうる。ピクチャは、フレームと称され、基準ピクチャは、基準フレームと称されうる。

空間予測または時間予測の結果、ブロックの予測ブロックがコーディングされるようになる。残余データは、コーディングされるべきオリジナルのブロックと、予測ブロックとの間のピクセル差分を表す。インタ・コード・ブロックは、予測ブロックを形成する基準サンプルのブロックを示す動きベクトルと、コーディングされたブロックと予測ブロックとの差分を示す残余データと、にしたがってエンコードされる。イントラ・コード・ブロックは、イントラ・コーディング・モードと残余データとにしたがってエンコードされる。さらなる圧縮のため、残余データは、ピクセル領域から変換領域へ変換され、残余変換係数となる。残余変換係数は、その後、量子化されうる。最初に２次元アレイで配列された量子化された変換係数は、変換係数の一次元ベクトルを生成するためにスキャンされ、より更なる圧縮を達成するために、エントロピ・コーディングが適用されうる。

一般に、本開示は、ピクチャのウェーブフロントの並列処理のための技法を記載する。特に、ビデオ・コーダは、本開示のいくつかの技法にしたがって、おのおのが１または複数の完全なスライスを有する１または複数のウェーブフロントを有するピクチャのためのビデオ・データをコーディングするように構成されうる。別の例として、ビデオ・コーダは、本開示のいくつかの技法にしたがって、おのおのが１または複数のウェーブフロントを含む１または複数のスライスを有するピクチャのビデオ・データをコーディングするように構成されうる。いずれのケースであれ、複数のウェーブフロントにおける各ウェーブフロントは、ウェーブフロントの並列処理を可能にする十分な情報を含みうる。したがって、ウェーブフロントは、常にスライス・ヘッダで始まるか、または、スライス・ヘッダで始まらないのであれば、ウェーブフロント上のブロックの行と同じスライスに属する。

一例では、方法は、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、行の先頭以外の位置において始まることを判定することと、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定することと、このスライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングすることと、を含む。

別の例では、ビデオ・データをコーディングするデバイスは、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、行の先頭以外の位置において始まることを判定することと、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定することと、このスライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングすることと、を実行するように構成されたビデオ・コーダを含む。

別の例では、ビデオ・データをコーディングするデバイスは、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、行の先頭以外の位置において始まることを判定する手段と、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定する手段と、スライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングする手段と、を含む。

別の例では、コンピュータ読取可能な記憶媒体は、実行された場合、コンピューティング・デバイスのプログラム可能なプロセッサに対して、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、行の先頭以外の位置において始まることを判定することと、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定することと、このスライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングすることと、を実行させる命令群を格納している。

１または複数の例の詳細が、添付図面および以下の説明において述べられる。他の特徴、目的、および利点が、説明と図面から、および特許請求の範囲から明らかになるだろう。

図１は、ウェーブフロントを並列的にコーディングするための技法を利用しうるビデオ・エンコーディングおよびでコーディング・システムの例を例示するブロック図である。 図２は、ウェーブフロントを並列的にコーディングするための技法を実施しうるビデオ・エンコーダの例を例示するブロック図である。 図３は、ウェーブフロントを並列的にコーディングするための技法を実施しうるビデオ・デコーダの例を例示するブロック図である。 図４は、ウェーブフロントに分割されたピクチャの例を例示する概念図である。 図５は、ビデオ・コーダが、ウェーブフロントを並列的にコーディングするための本開示の技法を実施しうる処理の例を例示するフローチャートである。 図６は、ビデオ・コーダが、ウェーブフロントを並列的にコーディングするための本開示の技法を実施しうる処理の別の例を例示するフローチャートである。

一般に、本開示は、ピクチャのウェーブフロントを並行処理のための技法を記述する。ピクチャは、複数のウェーブフロントへ分割されうる。おのおののウェーブフロントは、ピクチャのブロックの行に対応しうる。例において、ブロックは、最大コーディング・ユニット（ＬＣＵ）とも称される、ピクチャのコーディング・ツリー・ユニット（ＣＴＵ）に相当しうる。ビデオ・エンコーダまたはビデオ・デコーダのようなビデオ・コーダは、実質的に並列的にウェーブフロントをコーディングしうる。例えば、ビデオ・コーダは、ピクチャの最初のウェーブフロントのブロックを、ピクチャの２番目のウェーブフロントのブロックと、並列的にコーディングしうる。ビデオ・コーダは、上のウェーブフロントの最初の２つのブロックのデータに基づいて、現在のウェーブフロントのコンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）を実行するための現在のウェーブフロントのコンテキストのみならず、現在のウェーブフロントの最初のブロックを含むスライスのスライス・ヘッダの１または複数の要素を初期化しうる。

ピクチャは、コーディング・ツリー・ユニット（ＣＴＵ）の複数の行に分割されうる。ＣＴＵの各行は、それぞれのウェーブフロントに対応しうる。ウェーブフロント並列処理は、ＣＴＵの複数の行を、隣接するウェーブフロントの開始間に、２つのＣＴＵ分の遅延が生じうるウェーブフロント方式で並列的に処理する機能を提供する。ビデオ・コーダは、後続するＣＴＵ行の上にあるＣＴＵ行のうちの２つのＣＴＵをコーディングした後のコンテキスト状態を用いて、後続するウェーブフロント（またはＣＴＵ行）のＣＡＢＡＣ初期化を実行しうる。言い換えれば、現在のウェーブフロントのコーディングを開始する前に、ビデオ・コーダは、現在のウェーブフロントがピクチャのＣＴＵの先頭行ではないと仮定して、現在のウェーブフロント上のウェーブフロントの少なくとも２つのブロックをコーディングしうる。さらに、ビデオ・コーダは、現在のウェーブフロント上のウェーブフロントの少なくとも２つのブロックをコーディングした後、現在のウェーブフロントのＣＡＢＡＣコンテキストを初期化しうる。

ＣＡＢＡＣ機能は、右上のＣＴＵと同期化されうる。ビデオ・コーダは、ウェーブフロントを並列的に処理しうるので、２番目のＣＴＵ行の最初をデコードするために、先頭のＣＴＵ行の終わりからの情報を必要としうる。そのような情報の例は、スライス情報、量子化パラメータ（ＱＰ）等を含みうる。例えば、新たなスライスが、先頭のＣＴＵ行（ウェーブフロント）の終了に向かって始まると、ビデオ・コーダは、直下のＣＴＵ行（ウェーブフロント）をコーディングする前に、先頭のＣＴＵ行の、ある情報を必要としうる。さらに具体的には、先頭のＣＴＵ行からの情報は、下のＣＴＵ行のデコード処理に影響を与えうる。

一般に、本開示の技法は、ウェーブフロントの最初のＣＴＵの後である位置において始まり、後続するウェーブフロントへ続くスライスによって引き起こされる潜在的な問題を緩和することに向けられる。特に、スライスが、ウェーブフロントの最初のＣＴＵに続く位置で始まり、１または複数の後続するウェーブフロントのＣＴＵを含んでいるのであれば、ビデオ・コーダは、現在のウェーブフロントをコーディングするために必要とされる情報を取得するために、現在のウェーブフロントの各スライスのそれぞれのスライス・ヘッダをコーディングする必要がありうる。そのようなシナリオでは、ビデオ・デコーダは、ビデオ・エンコーダによってエンコードされたスライス・ヘッダに基づいて、ピクチャのさまざまなウェーブフロントをデコードするために必要な情報を決定するために、ピクチャにおける各スライス・ヘッドを検査することが必要とされうる。そのような情報の例は、ウェーブフロントのエントリ・ポイント、ウェーブフロントの量子化パラメータ等を含みうる。いくつかの事例では、ビデオ・コーダは、例えば、ピクチャ内の各スライスの先頭および終了ポイントをマップすることのように、ピクチャ内の位置にしたがってスライスをマップすることが必要とされうる。一方、ビデオ・コーダは、上の行から、現在のＣＴＵの右の２つのＣＴＵ内から、現在のウェーブフロントの情報を有しているのであれば、スライス・スピルオーバによって引き起こされる遅延無しで、各ウェーブフロントをコーディングしうる。例えば、ビデオ・デコーダ、または、デコードを実行するように構成されたビデオ・エンコーダが、上の行から、現在のＣＴＵの右の２つのＣＴＵ内から、現在のウェーブフロントの情報へのアクセスを有するのであれば、ビデオ・デコーダは、スライス・スピルオーバによって引き起こされる遅延無しで各ウェーブフロントをデコードしうる。

スライス・スピルオーバによって引き起こされるコーディング遅延を緩和または阻止するために、ビデオ・コーダは、ウェーブフロント・スライス・インタラクションを制限するために、本開示の１または複数の技法を実施する。これによって、スライスは、ＣＴＵ行の先頭以外のＣＴＵ行の位置において始まる（例えば、スライスが、ＣＴＵ行の中間において始まる）と、ＣＴＵ行内（例えば、行の最後のＣＴＵにおいて、または、行の最後のＣＴＵの前のＣＴＵにおいて）で終了するようになる。反対に、ビデオ・コーダは、スライスがＣＴＵ行の先頭で始まる（例えば、行の最初のＣＴＵが、スライスの最初のＣＴＵを形成する）ことと、スライスが現在の行のすべてのＣＴＵと、１または複数の後続するＣＴＵ行の１または複数のＣＴＵとを含むことと、を判定するために本技法を実施しうる。このシナリオでは、ビデオ・コーダは、スライス・スピルオーバを許可しうる。すなわち、ビデオ・コーダは、スライスが、１または複数の後続するＣＴＵ行の１または複数のＣＴＵを含んでいると判定しうる。本開示の技法によって提供される潜在的な利点は、ビデオ・デコーダは、ピクチャをウェーブフロント並列処理順にデコードしている間に、後続するスライス・ヘッダに依存する必要がないかもしれないことである。代わりに、ビデオ・デコーダは、ウェーブフロント並列処理順にＣＴＵを処理している間に遭遇しうる各スライス・ヘッダを処理しうる。

いくつかの例では、ビデオ・コーダは、スライスが、ウェーブフロントの中間または最後（例えば、ウェーブフロントの最初のブロックに後続するブロック）において始まり、後続するウェーブフロントへの境界を横切ったことを検出しうる。この事例では、ビデオ・コーダは、スライスが始まるウェーブフロント内（例えば、最後のブロック）で終了するようにスライスを設定しうる。前述したスライス・ウェーブフロント構成を用いて、ビデオ・コーダは、ウェーブフロントがスライス・ヘッダで始まるか、あるいは、ウェーブフロントがスライス・ヘッダで始まらないのであれば、このウェーブフロントのは、すぐ上に位置しているウェーブフロントと同じスライスに属していることを保証しうる。

いくつかの例では、ビデオ・コーダは、スライスが、ウェーブフロントの先頭で始まり、後続するウェーブフロントへ続くのであれば、スライスは、ウェーブフロントの中間（または、ウェーブフロント内）で終了せねばならないことを必要とする技法を実施しうる。前述した制約と合わせて、ビデオ・コーダは、最初のスライスが終了するウェーブフロントの残りが、１または複数の完全なスライスを含んでいることを保証しうる。これら要件にしたがってスライスおよびウェーブフロントを構成することによって、ビデオ・コーダは、例えば、ウェーブフロントの最初のブロック後に始まるスライスのスピルオーバによって引き起こされる遅延を緩和することによって、イメージのウェーブフロント並列処理をより効率的に実行する技法を実施しうる。

図１は、ウェーブフロントを並列的にコーディングするための技法を利用しうるビデオ・エンコーディングおよびデコーディング・システム１０の例を例示するブロック図である。図１に図示されるように、システム１０は、宛先デバイス１４によって、後の時間においてデコードされるべきエンコードされたビデオ・データを提供するソース・デバイス１２を含む。特に、ソース・デバイス１２は、ビデオ・データを、コンピュータ読取可能な媒体１６を経由して、宛先デバイス１４へ提供する。ソース・デバイス１２および宛先デバイス１４は、デスクトップ・コンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレット・コンピュータ、セット・トップ・ボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイ・デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイス等を含む広範なデバイスのうちの何れかを備えうる。いくつかのケースでは、ソース・デバイス１２および宛先デバイス１４が無線通信のために装備されうる。

宛先デバイス１４は、デコードされるべき、エンコードされたビデオ・データを、コンピュータ読取可能な媒体１６を経由して受け取りうる。コンピュータ読取可能な媒体１６は、エンコードされたビデオ・データを、ソース・デバイス１２から宛先デバイス１４へ移動させることが可能な任意のタイプの媒体またはデバイスを備えうる。一例において、コンピュータ読取可能な媒体１６は、エンコードされたビデオ・データを、ソース・デバイス１２が、宛先デバイス１４へリアル・タイムでダイレクトに送信することを可能にする通信媒体を備えうる。エンコードされたビデオ・データは、例えば無線通信プロトコルのような通信規格にしたがって変調され、宛先デバイス１４へ送信されうる。通信媒体は、例えばラジオ周波数（ＲＦ）スペクトルまたは１または複数の物理送信ラインのような任意の無線または有線の通信媒体を備えうる。通信媒体は、例えば、ローカル・エリア・ネットワーク、広域ネットワーク、またはインターネットのようなグローバル・ネットワークのような、パケット・ベースのネットワークの一部を形成しうる。通信媒体は、ルータ、スイッチ、基地局、または、ソース・デバイス１２から宛先デバイス１４への通信を容易にするために有用でありうるその他任意の機器を含みうる。

いくつかの例において、エンコードされたデータは、出力インタフェース２２から、記憶デバイスへ出力されうる。同様に、エンコードされたデータは、入力インタフェースによって、記憶デバイスからアクセスされうる。記憶デバイスは、例えば、ハード・ドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュ・メモリ、揮発性メモリまたは不揮発性メモリ、または、エンコードされたビデオ・データを格納するのに適したその他任意のデジタル記憶媒体のような、分散的にまたはローカルにアクセスされるさまざまなデータ記憶媒体のうちの何れかを含みうる。さらなる例では、記憶デバイスは、ソース・デバイス１２によって生成された、エンコードされたビデオを格納しうるファイル・サーバまたはその他の中間記憶デバイスに相当しうる。宛先デバイス１４は、ストリーミングまたはダウンロードによって、記憶デバイスから、格納されたビデオ・データにアクセスしうる。ファイル・サーバは、エンコードされたビデオ・データを格納することと、エンコードされたビデオ・データを宛先デバイス１４へ送信することとが可能な任意のタイプのサーバでありうる。ファイル・サーバの例は、（例えば、ウェブサイト用の）ウェブ・サーバ、ＦＴＰサーバ、ネットワーク・アタッチ・ストレージ（ＮＡＳ：ｎｅｔｗｏｒｋ ａｔｔａｃｈｅｄ ｓｔｏｒａｇｅ）デバイス、またはローカル・ディスク・ドライブを含む。宛先デバイス１４は、エンコードされたビデオ・データに、インターネット接続を含む任意の標準的なデータ接続によってアクセスしうる。これは、無線チャネル（例えば、Ｗｉ−Ｆｉ接続）、有線接続（例えば、ＤＳＬ、ケーブル・モデム等）、または、ファイル・サーバに格納されたエンコードされたビデオ・データにアクセスすることに適したこれら両方の組み合わせを含みうる。記憶デバイスからの、エンコードされたビデオ・データの送信は、ストリーミング送信、ダウンロード送信、またはこれらの組み合わせを備えうる。

本開示の技法は、必ずしも無線のアプリケーションまたは設定に制限される必要はない。これら技法は、例えば、オーバ・ザ・エア・テレビジョン・ブロードキャスト、ケーブル・テレビジョン送信、衛星テレビ送信、ダイナミック・アダプティブ・ストリーミング・オーバＨＴＴＰ（ＤＡＳＨ）のようなインターネット・ストリーミング・ビデオ送信、データ記憶媒体にエンコードされるデジタル・ビデオ、データ記憶媒体に格納されたデジタル・ビデオのデコーディング、またはその他のアプリケーションのうちの何れかをサポートするビデオ・コーディングに適用されうる。いくつかの例において、システム１０は、例えばビデオ・ストリーミング、ビデオ再生、ビデオ・ブロードキャスト、および／または、ビデオ・テレフォニのようなアプリケーションをサポートする１方向または２方向のビデオ送信をサポートするように構成されうる。

図１の例では、ソース・デバイス１２は、ビデオ・ソース１８、ビデオ・エンコーダ２０、および出力インタフェース２２を含んでいる。宛先デバイス１４は、入力インタフェース２８、ビデオ・デコーダ３０、およびディスプレイ・デバイス３２を含んでいる。本開示によれば、ソース・デバイス１２のビデオ・エンコーダ２０は、ウェーブフロントを並列的にコーディングするための技法を適用するように構成されうる。別の例では、ソース・デバイスおよび宛先デバイスは、その他の構成要素または構成を含みうる。例えば、ソース・デバイス１２は、例えば外部カメラのような外部ビデオ・ソース１８からビデオ・データを受信しうる。同様に、宛先デバイス１４は、統合されたディスプレイ・デバイスを含んでいるのではなく、外部のディスプレイ・デバイスとインタフェースしうる。

図１の例示されたシステム１０は単なる一例である。ウェーブフロントを並列的にコーディングするための技法は、任意のデジタル・ビデオ・エンコーディングおよび／またはデコーディング・デバイスによって実行されうる。一般に、本開示の技法は、ビデオ・エンコーディング・デバイスによって実行されるが、これら技法は、一般に「コーデック」と称されるビデオ・エンコーダ／デコーダによっても実行されうる。さらに、本開示の技術はまた、ビデオ・プリプロセッサによっても実行されうる。ソース・デバイス１２および宛先デバイス１４は、単に、ソース・デバイス１２が、宛先デバイス１４への送信のために、コーディングされたビデオ・データを生成するこのようなコーディング・デバイスの例である。いくつかの例において、デバイス１２，１４は、デバイス１２，１４のおのおのがビデオ・エンコードおよびデコード構成要素を含むように、実質的に対称的に動作しうる。したがって、システム１０は、例えば、ビデオ・ストリーミング、ビデオ・プレイバック、ビデオ・ブロードキャスト、またはビデオ・テレフォニのために、ビデオ・デバイス１２，１４間の一方向または二方向のビデオ送信をサポートしうる。

ソース・デバイス１２のビデオ・ソース１８は、例えば、ビデオ・カメラ、以前にキャプチャされたビデオを含むビデオ・アーカイブ、および／または、ビデオ・コンテンツ・プロバイダからビデオを受け取るためのビデオ・フィード・インタフェースのようなビデオ・キャプチャ・デバイスを含みうる。さらなる代案として、ビデオ・ソース１８は、コンピュータ・グラフィック・ベースのデータを、ソース・ビデオとして、または、ライブ・ビデオと、アーカイブされたビデオと、コンピュータによって生成されたビデオとの組み合わせとして生成しうる。いくつかのケースにおいて、ビデオ・ソース１８がビデオ・カメラであれば、ソース・デバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはビデオ電話を形成しうる。しかしながら、前述したように、本開示において記載されているこれら技術は、一般に、ビデオ・コーディングに適用可能でありうる。そして、無線または有線のアプリケーションに適用されうる。各ケースでは、キャプチャされたビデオ、プリキャプチャされたビデオ、または、コンピュータによって生成されたビデオが、ビデオ・エンコーダ２０によってエンコードされうる。エンコードされたビデオ情報は、その後、出力インタフェース２２によって、コンピュータ読取可能な媒体１６に出力されうる。

コンピュータ読取可能な媒体１６は、例えば、無線ブロードキャストまたは有線ネットワーク送信のような一時的な媒体、または、例えば、ハード・ディスク、フラッシュ・ドライブ、コンパクト・ディスク、デジタル・ビデオ・ディスク、ブルーレイ・ディスク、または、その他のコンピュータ読取可能な媒体のような記憶媒体（すなわち、非一時的な記憶媒体）を含みうる。いくつかの例において、ネットワーク・サーバ（図示せず）は、エンコードされたビデオ・データを、ソース・デバイス１２から受け取り、エンコードされたビデオ・データを、例えばネットワーク送信によって、宛先デバイス１４へ提供しうる。同様に、例えばディスク・スタンピング施設のような媒体製造施設のコンピューティング・デバイスが、エンコードされたビデオ・データをソース・デバイス１２から受け取り、このエンコードされたビデオ・データを含むディスクを生成しうる。したがって、コンピュータ読取可能な媒体１６は、さまざまな例において、さまざまな形態からなる１または複数のコンピュータ読取可能な媒体を含むものと理解されうる。

宛先デバイス１４の入力インタフェース２８は、コンピュータ読取可能な媒体１６から、情報を受け取る。コンピュータ読取可能な媒体１６の情報は、ビデオ・エンコーダ２０によって定義され、ビデオ・デコーダ３０によっても使用されるシンタックス情報を含みうる。これは、例えばＧＯＰのように、ブロックおよびその他のコーディングされたユニットの特性および／または処理を記述するシンタックス要素を含む。ディスプレイ・デバイス３２は、デコードされたビデオ・データをユーザへ表示しうる。そして、例えば、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイ・デバイスのようなさまざまなディスプレイ・デバイスのうちの何かを備えうる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格のようなビデオ・コーディング規格にしたがって動作し、ＨＥＶＣテスト・モデル（ＨＭ）に準拠しうる。あるいは、ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、例えば、ＭＰＥＧ ４、パート１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）とも称されるＩＴＵ−Ｔ Ｈ．２６４規格のようなその他の独占規格または業界規格、または、これら規格の拡張版にしたがって動作しうる。しかしながら、本開示の技法は、任意の特定のコーディング規格に限定されない。ビデオ・コーディング規格のその他の例は、ＭＰＥＧ２およびＩＴＵ−Ｔ Ｈ．２６３を含んでいる。図１に図示されていないが、いくつかの態様では、ビデオ・エンコーダ２０およびビデオ・デコーダ３０はおのおの、オーディオ・エンコーダおよびデコーダと統合されうる。そして、共通のデータ・ストリームまたは個別のデータ・ストリームでオーディオとビデオとの両方のエンコードを取り扱うために、適切なＭＵＸ−ＤＥＭＵＸユニット、またはその他のハードウェアおよびソフトウェアを含みうる。適用可能であれば、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサ・プロトコル、または、例えばユーザ・データグラム・プロトコル（ＵＤＰ）のようなその他のプロトコルに準拠しうる。

ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、ジョイント・ビデオ・チーム（ＪＶＴ）として知られている集合的なパートナシップの製品として、ＩＳＯ／ＩＥＣムービング・ピクチャ・エキスパート・グループ（ＭＰＥＧ）とともにＩＴＵ−Ｔビデオ・コーディング・エキスパート・グループ（ＶＣＥＧ）によって公布された。いくつかの態様では、本開示に記載された技術は、一般に、Ｈ．２６４規格に準拠するデバイスに適用されうる。Ｈ．２６４規格は、２００５年３月付けのＩＴＵ−Ｔスタディ・グループによるＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６４，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｆｏｒ ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓに記載されている。これは、本明細書では、Ｈ．２６４規格またはＨ．２６４仕様、またはＨ．２６４／ＡＣＤ規格または仕様と称されうる。ジョイント・ビデオ・チーム（ＪＶＴ）は、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣに対する拡張に取り組み続けている。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０はおのおの、例えば１または複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディスクリート・ロジック、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせ、のようなさまざまな適切なエンコーダ回路のうちの何れかとして実現されうる。これら技法が部分的にソフトウェアで実現される場合、デバイスは、本開示の技法を実行するために、ソフトウェアのための命令群を、適切な非一時的なコンピュータ読取可能な媒体に格納し、１または複数のプロセッサを用いて、ハードウェアにおいて、これら命令群を実行しうる。ビデオ・エンコーダ２０およびビデオ・デコーダ３０のおのおのは、１または複数のエンコーダまたはデコーダに含まれうる。これらの何れかは、それぞれのデバイスにおいて、結合されたビデオ・エンコーダ／デコーダ（コーデック）の一部として統合されうる。

ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に寄与している。ＨＥＶＣ規格化の努力は、ＨＥＶＣテスト・モデル（ＨＭ）と称されるビデオ・コーディング・デバイスの発展中のモデルに基づく。ＨＭは、例えばＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣにしたがう既存のデバイスに対するビデオ・コーディング・デバイスのいくつかの追加機能であると考えられる。例えば、Ｈ．２６４が、９つのイントラ予測エンコーディング・モードを提供する一方、ＨＭは、３３ものイントラ予測エンコーディング・モードを提供しうる。

一般に、ＨＭのワーキング・モデルは、ビデオ・フレームまたはピクチャが、輝度サンプルと彩度サンプルとの両方を含むコーディング・ツリー・ユニット（ＣＴＵ）またはツリーブロックのシーケンスに分割されうると記載している。ビットストリーム内のシンタックス・データは、ピクセル数の観点から最大のコーディング・ユニットである、ＣＴＵのサイズを定義しうる。スライスは、連続した多くのツリーブロックをコーディング順に含んでいる。ビデオ・フレームまたはピクチャは、１または複数のスライスへ分割されうる。おのおののツリーブロックは、クワッドツリーにしたがってコーディング・ユニット（ＣＵ）へ分割されうる。一般に、クワッドツリー・データ構造は、ツリーブロックに対応するルート・ノードと共に、ＣＵ当たり１つのノードを含んでいる。ＣＵが４つのサブＣＵへ分割されるのであれば、ＣＵに対応するノードは、４つのリーフ・ノードを含んでいる。これらのおのおのは、サブＣＵのうちの１つに対応する。

クワッドツリー・データ構造の各ノードは、対応するＣＵのためのシンタックス・データを提供しうる。例えば、クワッドツリーにおけるノードは、分割フラグを含みうる。これは、このノードに対応するＣＵが、サブＣＵに分割されるか否かを示す。ＣＵのためのシンタックス要素は、再帰的に定義されうる。そして、ＣＵがサブＣＵに分割されるか否かに依存しうる。ＣＵは、さらに分割されないのであれば、リーフＣＵと称される。本開示では、たとえオリジナルのリーフＣＵの明示的な分割が無くても、リーフＣＵのうちの４つのサブＣＵも、リーフＣＵと称されるだろう。例えば、１６×１６サイズのＣＵがこれ以上分割されていないのであれば、１６×１６のＣＵが分割されていなくても、４つの８×８のサブＣＵもまたリーフＣＵと称されるだろう。

ＣＵは、ＣＵがサイズ区別を有していないこと以外は、Ｈ．２６４規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、４つの子ノード（サブＣＵとも称される）に分割され、各子ノードが親ノードになり、別の４つの子ノードに分割されうる。クワッドツリーのリーフ・ノードと称される最終的に分割されない子ノードは、リーフＣＵとも称されるコーディング・ノードを備える。コーディングされたビットストリームに関連付けられたシンタックス・データは、最大ＣＵデプスと称される、ツリーブロックが分割される最大回数を定義しうる。そして、コーディング・ノードの最大サイズをも定義しうる。したがって、ビットストリームはまた、最小コーディング・ユニット（ＳＣＵ）を定義しうる。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵのうちの何れか、または、その他の規格（例えば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそのサブ・ブロック）のコンテキストにおける類似のデータ構造を称するために「ブロック」という用語を用いる。

ＣＵは、コーディング・ノードと、コーディング・ノードに関連付けられた変換ユニット（ＴＵ：ｔｒａｎｓｆｏｒｍ ｕｎｉｔ）および予測ユニット（ＰＵ：ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）を含む。ＣＵのサイズは、コーディング・ノードのサイズに相当し、正方形の形状でなければならない。ＣＵのサイズは、８×８ピクセルから、最大６４×６４またはそれ以上のピクセルを有するツリーブロックのサイズに及びうる。おのおののＣＵは、１または複数のＰＵおよび１または複数のＴＵを含みうる。ＣＵに関連付けられたシンタックス・データは、例えば、ＣＵを、１または複数のＰＵへ分割することを記述しうる。モードを分割することは、ＣＵがスキップされるか、または、ダイレクト・モード・エンコードされるか、イントラ予測モード・エンコードされるか、インタ予測モード・エンコードされるかで異なりうる。ＰＵは、非正方形の形状に分割されうる。ＣＵに関連付けられたシンタックス・データはまた、例えば、クワッドツリーにしたがって、ＣＵを１または複数のＴＵへ分割することを記述しうる。ＴＵは、正方形形状または非正方形形状（例えば、長方形）でありうる。

ＨＥＶＣ規格は、ＴＵにしたがう変換を考慮している。これは異なるＣＵについて異なりうる。ＴＵは、必ずしもそうだとは限らないかもしれないが、一般に、分割されたＣＴＵのために定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ化されうる。ＴＵは、一般に、ＰＵと同じサイズであるか、ＰＵよりも小さい。いくつかの例において、ＣＵに対応する残余サンプルは、「残余クワッドツリー」（ＲＱＴ：ｒｅｓｉｄｕａｌ ｑｕａｄ ｔｒｅｅ）として知られているクワッドツリー構造を用いて、より小さなユニットに細分化されうる。ＲＱＴのリーフ・ノードは、変換ユニット（ＴＵ）と称されうる。ＴＵに関連付けられたピクセル差分値は、変換係数を生成するために変換されうる。これは、量子化されうる。

リーフＣＵは、１または複数の予測ユニット（ＰＵ）を含みうる。一般に、ＰＵは、対応するＣＵのすべてまたは一部に対応する空間エリアを表し、ＰＵのための基準サンプルを取得するためのデータを含みうる。さらに、ＰＵは、予測に関連するデータを含む。例えば、ＰＵがイントラ・モード・エンコードされた場合、ＰＵのデータは、残余クワッドツリー（ＲＱＴ）に含まれうる。これは、ＰＵに対応するＴＵのためのイントラ予測モードを記述するデータを含みうる。別の例として、ＰＵがインタ・モード・エンコードされている場合、ＰＵは、ＰＵのための１または複数の動きベクトルを定義するデータを含みうる。ＰＵの動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（例えば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが示す基準ピクチャ、および／または、動きベクトルの基準ピクチャ・リスト（例えば、リスト０、リスト１、またはリストＣ）、を記述しうる。

１または複数のＰＵを有するリーフＣＵはまた、１または複数の変換ユニット（ＴＵ）を含みうる。変換ユニットは、前述したように、（ＴＵクワッドツリー構造とも称される）ＲＱＴを用いて指定されうる。例えば、分割フラグが、リーフＣＵが４つの変換ユニットに分割されているか否かを示しうる。その後、各変換ユニットは、さらに、さらなるサブＴＵに分割されうる。ＴＵは、さらに分割されない場合、リーフＴＵと称されうる。一般に、イントラ・コーディングの場合、リーフＣＵに属するすべてのリーフＴＵは、同じイントラ予測モードを共有する。すなわち、同じイントラ予測モードは、一般に、リーフＣＵのすべてのＴＵのための予測値を計算するために適用される。イントラ・コーディングのために、ビデオ・エンコーダは、イントラ予測モードを用いて、各リーフＴＵのための残余値を、ＴＵに対応するＣＵの一部と、オリジナル・ブロックとの間の差分として計算しうる。ＴＵは、必ずしもＰＵのサイズに制限されない。したがって、ＴＵは、ＰＵより大きくも、または、小さくもなりうる。イントラ・コーディングのために、ＰＵは、同じＣＵのための対応するリーフＴＵと連結されうる。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに相当しうる。

さらに、リーフＣＵのＴＵはまた、残余クワッドツリー（ＲＱＴ）と称されるそれぞれのクワッドツリー・データ構造に関連付けられうる。すなわち、リーフＣＵは、リーフＣＵがどうやってＴＵへ分割されるのかを示すクワッドツリーを含みうる。ＴＵクワッドツリーのルート・ノードは、一般に、リーフＣＵに対応する一方、ＣＵクワッドツリーのルート・ノードは、一般に、ツリーブロック（またはＣＴＵ）に対応する。

分割されないＲＱＴのＴＵは、リーフＴＵと称される。一般に、もしも別に言及されていないのであれば、本開示は、リーフＣＵおよびリーフＴＵを称するためにＣＵおよびＴＵという用語を用いる。

ビデオ・シーケンスは一般に、一連のビデオ・フレームまたはピクチャを含む。ピクチャのグループ（ＧＯＰ：ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ）は、一般に、１または複数のビデオ・ピクチャからなる一連のビデオ・ピクチャを備える。ＧＯＰは、ＧＯＰのヘッダ、ピクチャの１または複数のヘッダ、または別の何れかに、シンタックス・データを含みうる。これは、ＧＯＰに含まれるピクチャの数を記述している。ピクチャのおのおののスライスは、それぞれのスライスのためのエンコード・モードを記述するスライス・シンタックス・データを含みうる。ビデオ・エンコーダ２０は一般に、ビデオ・データをエンコードするために、個々のビデオ・スライス内のビデオ・ブロックに対して動作する。ビデオ・ブロックは、ＣＵ内のコーディング・ノードに対応しうる。ビデオ・ブロックは、固定サイズまたは可変サイズを有しうる。そして、指定されたコーディング規格によってサイズが異なりうる。

例として、ＨＭは、さまざまなＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮであるＰＵサイズではイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎである対称なＰＵサイズではインタ予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズにおけるインタ予測のために、非対称分割をサポートする。非対称分割では、ＣＵの１つの方向が分割されないが、他の方向が２５％および７５％へ分割される。２５％分割に対応するＣＵ部分は、“Ｕｐ”、“Ｄｏｗｎ”、“Ｌｅｆｔ”、または“Ｒｉｇｈｔ”を示すインジケーションが続く“ｎ”によって示される。したがって、例えば、“２Ｎ×ｎＵ”は、トップにおいて２Ｎ×０．５Ｎ ＰＵで、ボトムにおいて２Ｎ×１．５Ｎ ＰＵを用いて水平的に分割される２Ｎ×２Ｎ ＣＵを称する。

本開示では、“Ｎ×Ｎ”および“ＮバイＮ”は、例えば１６×１６ピクセルまたは１６バイ１６ピクセルのように、垂直寸法および水平寸法に関するビデオ・ブロックのピクセル寸法を称するために交換可能に使用されうる。一般に、１６×１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）と、水平方向に１６ピクセル（ｘ＝１６）を有するだろう。同様に、Ｎ×Ｎブロックは、一般に、垂直方向におけるＮ個のピクセルと、水平方向におけるＮ個のピクセルとを有する。ここで、Ｎは、負ではない整数値を表わす。ブロックにおけるピクセルは、行と列とで構成されうる。さらに、ブロックは、必ずしも、垂直方向と同じ数のピクセルを、水平方向に有する必要はない。例えば、ブロックは、Ｎ×Ｍピクセルを備えうる。ここで、Ｍは、必ずしもＮに等しくはない。

ＣＵのＰＵを用いたイントラ予測コーディングまたはインタ予測コーディングの後、ビデオ・エンコーダ２０は、ＣＵのＴＵの残余データを計算しうる。ＰＵは、（ピクセル領域とも称される）空間領域に予測ピクセル・データ生成する方法またはモードを記述するシンタックス・データを備えうる。そして、ＴＵは、例えば、ディスクリート・コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または、残余ビデオ・データへの概念的に類似の変換、のような変換の適用後の係数を変換領域に備えうる。残余データは、エンコードされていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応しうる。ビデオ・エンコーダ２０は、ＣＵのための残余データを含むＴＵを生成し、その後、ＴＵを変換して、ＣＵのための変換係数を生成する。

変換係数を生成するいずれの変換後も、ビデオ・エンコーダ２０は、変換係数の量子化を実行しうる。量子化は一般に、変換係数が量子化され、恐らくは、さらなる圧縮によって、これら係数を表すために使用されるデータ量が低減される処理を称する。この量子化処理は、これら係数のうちのいくつかまたはすべてに関連付けられたビット・デプスを低減しうる。例えば、ｎビット値は、量子化中に、ｍビット値に丸められうる。ここで、ｎは、ｍよりも大きい。

量子化後、ビデオ・エンコーダは、変換係数をスキャンし、量子化された変換係数を含む２次元行列から１次元ベクトルを生成する。スキャンは、アレイの前面により高いエネルギ（したがって、より低い周波数）係数を配置し、アレイに背面により低いエネルギ（したがって、より高い周波数）係数を配置するように設計されうる。いくつかの例において、ビデオ・エンコーダ２０は、量子化された変換係数をスキャンするために、予め定義されたスキャン順序を利用し、エントロピ・エンコードされうるシリアル・ベクトルが生成されうる。別の例では、ビデオ・エンコーダ２０は、適応性スキャンを実行しうる。１次元ベクトルを生成するために、量子化された変換係数がスキャンされた後、ビデオ・エンコーダ２０は、例えば、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ・コーディング、（ＣＡＢＡＣ）、シンタックス・ベース・コンテキスト適応バイナリ・コーディング（ＳＢＡＣ）、確率インタバル分割エントロピ（ＰＩＰＥ）コーディング、または、その他のエントロピ・エンコード方法にしたがって、１次元ベクトルをエントロピ・エンコードしうる。ビデオ・エンコーダ２０はさらに、ビデオ・データをデコードする際にビデオ・デコーダ３０によって用いられるために、エンコードされたビデオ・データに関連付けられたシンタックス要素をエントロピ・エンコードしうる。

ＣＡＢＡＣを実行するために、ビデオ・エンコーダ２０は、コンテキスト・モデル内のコンテキストを、送信されるべきシンボルへ割り当てうる。このコンテキストは、例えば、近隣のシンボルの値が、非ゼロであるか否かに関連しうる。ＣＡＶＬＣを実行するために、ビデオ・エンコーダ２０は、送信されるべきシンボルのために、可変長コードを選択しうる。ＶＬＣにおけるコードワードは、比較的短いコードが、より確率の高いシンボルに対応する一方、よい長いコードが、より確率の低いシンボルに対応するように構築されうる。このように、ＶＬＣを用いることで、例えば、送信されるべき各シンボルのために等しい長さのコードワードを用いることに対するビット節約を達成しうる。確率決定は、シンボルに割り当てられたコンテキストに基づきうる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、ピクチャをエンコードおよびデコードするために、それぞれウェーブフロント並列処理（ＷＰＰ）を用いうる。ＷＰＰを用いてピクチャをコーディングするために、例えばビデオ・エンコーダ２０およびビデオ・デコーダ３０のようなビデオ・コーダは、ピクチャのコーディング・ツリー・ユニット（ＣＴＵ）を、複数のウェーブフロントに分割しうる。各ウェーブフロントは、ピクチャのＣＴＵの異なる行に相当しうる。ビデオ・コーダは、例えば、第１のコーダ・コアまたはスレッドを用いて、先頭のウェーブフロントのコーディングを開始しうる。ビデオ・コーダは、先頭のウェーブフロントのうちの２またはそれ以上のＣＴＵをコーディングした後、例えば、第２の並列したコーダ・コアまたはスレッドを用いて、先頭のウェーブフロントをコーディングすることと並列的に、先頭から２つ目のウェーブフロントのコーディングを開始しうる。ビデオ・コーダは、先頭から２つ目のウェーブフロントの２またはそれ以上のＣＴＵをコーディングした後、例えば、第３の並列したコーダ・コアまたはスレッドを用いて、より高次のウェーブフロントをコーディングすることと並列的に、先頭から３つ目のウェーブフロントのコーディングを開始しうる。このパターンは、ピクチャのウェーブフロントを下がって継続しうる。

本開示は、ビデオ・コーダが、例えばＷＰＰを用いて「ＣＴＵグループ」として現在コーディングしているＣＴＵのセットを参照する。したがって、ビデオ・コーダが、ピクチャをコーディングするためにＷＰＰを用いている場合、ＣＴＵグループのうちのＣＴＵのおのおのは、ピクチャの異なるウェーブフロントにありうる。そして、ＣＴＵグループのうちのＣＴＵのおのおのは、ピクチャのＣＴＵの少なくも２列、それぞれウェーブフロント上において、ＣＴＵから垂直方向にオフセットしうる。

さらに、ＷＰＰを用いてピクチャをコーディングする場合、ビデオ・コーダは、特定のＣＴＵの外部にある１または複数の空間的に近隣にあるＣＵが、特定のＣＴＵの左、左上、上、または右上にある限り、特定のＣＴＵにおける特定のＣＵにおけるイントラ予測またはインタ予測を実行するために、特定のＣＴＵの外部にある１または複数の空間的に近隣にあるＣＵに関連付けられた情報を用いうる。１または複数の空間的に近隣にあるＣＵが、特定のＣＴＵの右上にある場合、１または複数の空間的に近隣にあるＣＵは既にコーディングされていると仮定される。特定のＣＴＵが、一番上のウェーブフロント以外のウェーブフロントにおける最も左のＣＴＵであれば、ビデオ・コーダは、特定のＣＴＵのシンタックス要素をエントロピ・コーディングするためのコーディング・コンテキストを選択するために、隣接するウェーブフロント（例えば、すぐ上に位置するウェーブフロント）の第１および／または第２のＣＴＵに関連付けられた情報を用いうる。特定のＣＴＵが、ウェーブフロントにおける最も左のＣＴＵではないのであれば、ビデオ・コーダは、特定のＣＴＵのシンタックス要素をエントロピ・コーディングするためのコーディング・コンテキストを選択するために、特定のＣＴＵの左、左上、上、および／または、右上に位置している空間的に隣接しているＣＵに関連付けられた情報から選択しうる。このように、ビデオ・コーダは、すぐ上に位置するウェーブフロントのうちの２またはそれ以上のＣＴＵをエンコーディングした後、すぐ上に位置するウェーブフロントのエントロピ・コーディング状態に基づいて、ウェーブフロントのエントロピ・コーディング（例えば、ＣＡＢＡＣ）状態を初期化しうる。

さらに、ビデオ・コーダは、イメージを、スライスへ分割しうる。一般に、各スライスは、個々にエントロピ・コーディングされ、これによって、コンテキストは、新たなスライスのコーディングの先頭においてリセットされるようになる。ソース・デバイス１２のビデオ・エンコーダ２０またはポスト処理ユニット（例えば、図１に図示されないカプセル化ユニット）は、スライスを、それぞれのネットワーク・アブストラクション・レイヤ（ＮＡＬ）ユニットへカプセル化しうる。例えば、ＮＡＬユニットは、１または複数のエンコードされたスライスを表わすペイロードおよびＮＡＬヘッダを含みうる。エンコードされたスライスを互いに区別するために、ビデオ・エンコーダ２０は、スライスの開始を示すために、ＮＡＬユニット・ペイロード内にスライス・ヘッダを含めうる。さらに、ビデオ・エンコーダ２０は、エンコードされた個別のスライスの終わりを示すために、ＮＡＬユニット・ペイロード内に、１または複数のエンド・オブ・スライス・シンボルを含めうる。

ビデオ・エンコーダ２０は、与えられたイメージを、可変長のスライスへ分割しうる。言い換えれば、特定のイメージの異なるスライスが、可変数のＣＴＵを含みうるか、または、可変数のＣＴＵに対応しうる。その結果、ビデオ・エンコーダ２０は、異なる数のエンコードされたスライスを含めるために、異なるＮＡＬユニットを生成しうる。

それに相応して、ビデオ・デコーダ３０は、イメージを、スライス毎にエントロピ・デコードしうる。さらに詳しくは、ソース・デバイス２２は、宛先デバイス１４の入力インタフェース２８にＮＡＬユニットを送信するために出力インタフェース２２を用いうる。あるいは、出力インタフェース２２は、例えば磁気メモリまたはフラッシュ・メモリのようなディスクまたはコンピュータ読取可能なメモリのようなコンピュータ読取可能媒体へＮＡＬユニットを出力しうる。ビデオ・デコーダ３０は、入力インタフェース２８を介してＮＡＬユニットを受け取り、エンコードされた各スライスを、含まれたスライス分割情報（例えば、スライス・ヘッダおよび／またはエンド・オブ・スライス・シンボル）を用いて抽出しうる。次に、ビデオ・デコーダ３０は、抽出された各スライスをエントロピ・デコードし、イメージをスライス毎に再構築しうる。

ＷＰＰのコンテキストでは、いくつかの状況下では、ビデオ・コーダは、スライス境界を超えてコーディング・コンテキストを選択することができないことがありうる。例えば、特定のＣＴＵのコンテキスト情報が、特定のＣＴＵの右上に位置するＣＴＵとは異なるスライスに属するのであれば、ビデオ・コーダは、特定のＣＴＵをコーディングするために必要な情報へのアクセスを有していないことがありうる。さらに具体的には、ウェーブフロント内に位置するという観点において、特定のＣＴＵのスライス・ヘッダは、ビデオ・コーダが、特定のＣＴＵに達した場合にコーディングされないことがありうる。例えば、スライス・ヘッダは、ＣＴＵのウェーブフロントのすぐ上にあるウェーブフロントに位置しうる。また、スライス・ヘッダは、特定のＣＴＵと比較して、２よりも多いブロック、右に位置しうる。この例において、ビデオ・コーダは、空間的に近隣にあるＣＵへのアクセスを有しうる。ビデオ・コーダは、特定のＣＴＵをコーディングするためのコンテキストを、このＣＵから描画しうる。しかしながら、ビデオ・コーダは、特定のＣＴＵに対応するスライス・ヘッダを未だにコーディングしていないかもしれず、したがって、このスライス・ヘッダがコーディングされるまで、特定のＣＴＵをコーディングすることができないことがありうる。その結果、ビデオ・コーダは、特定のＣＴＵのコーディングを開始する前に、（スライス・ヘッダがコーディングされるまで）先行するウェーブフロントの追加のブロックをコーディングする必要がありうる。このシナリオでは、ビデオ・コーダは、例えば、右上に位置するＣＴＵと並列して特定のＣＴＵをコーディングすることのような、ＷＰＰの利点を利用することはできない。

ビデオ・コーダは、スライスがウェーブフロントの中間にある場合に、スライスがウェーブフロント境界を超えることを許可するのではなく、スライスが、ウェーブフロントの先頭（すなわち、最初のＣＴＵ）後の任意のポイントで始まる場合に、そのウェーブフロント内で終了するように、コーディング処理を制限するために本開示の技法を実施しうる。議論目的を容易にするのみのために、ウェーブフロントの先頭後の任意のポイントは、一般に、ウェーブフロントの「中間」として総括的に称される。すなわち、本明細書において用いられるようなウェーブフロントの「中間」は、必ずしも中間点である必要はなく、ウェーブフロントの順序的に最初のブロック以外のウェーブフロントの任意のＣＴＵ（または任意のブロック）である。そのようなスライスはまた、ウェーブフロントの「内部」で始まるとも言われうる。

例えば、ビデオ・エンコーダ２０は、スライス・ヘッダが、ウェーブフロントの中間内にあることを判定しうる。そして、このスライスは、ウェーブフロントの残りすべてのＣＴＵのみならず、すぐ下に位置するウェーブフロントの少なくとも１つのＣＴＵをも含む。これに応じて、ビデオ・エンコーダ２０は、ＣＴＵのエントロピ・エンコードを終了すると、または、ウェーブフロントの最後のＣＴＵを含めると、エンド・オブ・スライス・シンボルを挿入しうる。すなわち、ビデオ・エンコーダ２０は、スライスが始まるウェーブフロント内でスライスが終了することを保証しうる。これによって、スライスは、ウェーブフロントの順序的に最初のブロック以外のブロックで始まる場合、ウェーブフロント境界を超えないようになる。さらに、ビデオ・エンコーダ２０は、エンド・オブ・シンボルの後にスライス・ヘッダを挿入しうる。これによって、次のウェーブフロント（例えば、すぐ下に位置するウェーブフロント）が、エンコードされた新たなスライスの始まりに対応していることが示される。同様に、ビデオ・デコーダ３０は、ＷＰＰにしたがってイメージをエントロピ・デコードする場合、エンコードされたスライスが、ウェーブフロントの中間で始まることと、このスライスがまた、このスライスが始まるのと同じウェーブフロント内で終了することとを判定するために、受け取られたＮＡＬユニットのエンド・オブ・スライス・シンボルおよび／またはスライス・ヘッダを読み取りうる。いくつかの例では、ビデオ・エンコーダ２０は、２または複数のスライスが、単一のウェーブフロントの中間で始まることを判定しうる。そのような例では、ビデオ・エンコーダ２０は、このような最後のスライスが、後続するウェーブフロントにスピルオーバするか否かを判定し、このような最後のウェーブフロントに関して本明細書において記載された制約を実施しうる。

このように、スライスは、ウェーブフロントの順序的に最初のＣＴＵ以外のＣＴＵまたはその他のブロックで始まり、このウェーブフロント内で終了するという制約が課せられる。これらの制約を実施することによって、例えばビデオ・エンコーダ２０および／またはビデオ・デコーダ３０のようなビデオ・コーダは、ＷＰＰを実施する際の効率を高めうる。さらに詳しくは、ビデオ・コーダは、現在のウェーブフロントのＣＴＵをコーディングしている間に、現在のＣＴＵをコーディングするために必要でありうる以前のウェーブフロントの任意のデータへのアクセスを有することを保証するための制約を実施しうる。すなわち、現在のＣＴＵを含むスライスのスライス・ヘッダ・データは、現在のＣＴＵの１または複数のシンタックス要素をエントロピ・コーディングしている場合に利用可能となることが保証されうる。これによって、ビデオ・コーダは、シンタックス要素を正しくエントロピ・コーディングするためのコンテキストを決定できるようになりうる。

いくつかの例において、スライスは、最初のウェーブフロントの最初のＣＴＵにおいて始まり、最初のウェーブフロントのすぐ下に位置する２番目のウェーブフロントへの境界を超えることがありうる。そのような例において、スライスは、２番目のウェーブフロントの複数のＣＴＵを含みうるが、２番目のウェーブフロント内で終了しうる。言い換えれば、２番目のウェーブフロントは、別の２番目のスライスに属する追加のＣＴＵを含みうる。

この例では、ビデオ・コーダは、２番目のウェーブフロントに位置するスライスのＣＴＵをコーディングしている間、コーディング処理のために必要な最初のウェーブフロントからのすべてのデータへのアクセスを有しうる。すなわち、ビデオ・コーダは、前のウェーブフロントのコーディング中に、スライス・ヘッダ・データのコーディングをすでに完了しているだろう。したがって、ウェーブフロントの順序的に最初のＣＴＵにおいて始まるスライスは、未だに、後続するウェーブフロントへのウェーブフロント境界を超えることを許可されうる。さらに、ビデオ・コーダは、本明細書に記載された制約を用いて、２番目のスライスが、２番目のウェーブフロント内で終了しうることを保証しうる。例えば、２番目のスライスが、２番目のウェーブフロントの中間で始まり、２番目のウェーブフロントの最後のＣＴＵで終わるとビデオ・コーダが判定すると、ビデオ・コーダは、２番目のスライスのコーディングを終了することと同時に２番目のウェーブフロントのコーディングを終了しうる。その結果、３番目のウェーブフロントの開始は、定義によって、３番目のスライスの始まりと一致するだろう。さらに詳しくは、３番目のウェーブフロントのうちの最初の（最も左の）ＣＴＵが、３番目のスライスの最初のＣＴＵを表わすだろう。３番目のスライスが、４番目（またはそれ以降の）ウェーブフロントへの境界を超えると、ビデオ・コーダは、前のウェーブフロント内に位置する３番目のスライスの一部からのコーディング・クリティカル・データへの一貫したアクセスを有しうる。これによって、ＷＰＰを実行するためのビデオ・コーダの機能が向上される。このように、ビデオ・コーダは、現在のスライスをコーディングするために本開示の技法を実施しうる。これによって、ＷＰＰを実施している間、後続するスライスが、ＷＰＰにしたがって効率的にコーディングされる。

ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０のようなビデオ・コーダは、ビデオ・コーダが現在ＷＰＰを実施しているか否かに基づいてこの制約（単数または複数）をアクティブにしうる。一例として、ビデオ・デコーダ３０は、ＷＰＰがイネーブルされていることを示す、シンタックス・データのビットストリームを用いて、ＷＰＰが現在イネーブルされているか否かを判定しうる。同様に、ビデオ・エンコーダ２０は、ＷＰＰがイネーブルされているかを示すシンタックス・データをエンコードしうる。そのようなシンタックス・データは、ビデオ・パラメータ・セット（ＶＰＳ）、シーケンス・パラメータ・セット（ＳＰＳ）、ピクチャ・パラメータ・セット（ＰＰＳ）、補足的エンハンスメント情報（ＳＥＩ）メッセージ等でコーディングされうる。この例では、ＷＰＰがイネーブルされていると判定されることに応じて、ビデオ・エンコーダ２０は、エントロピ・エンコードし、ビデオ・デコーダ３０は、前述したスライス・ウェーブフロント制約を確保しながら、ＷＰＰを用いて、ピクチャをエントロピ・デコードしうる。いくつかの実施では、ビデオ・コーダは、例えば、ＷＰＰが現在ディセーブルされていると判定されることに応じて、ＷＰＰをイネーブルしうる。

ビデオ・エンコーダ２０はさらに、例えば、ブロック・ベースのシンタックス・データ、フレーム・ベースのシンタックス・データ、およびＧＯＰベースのシンタックス・データのようなシンタックス・データを、例えば、フレーム・ヘッダ、ブロック・ヘッダ、スライス・ヘッダ、またはＧＯＰヘッダで、ビデオ・デコーダ３０へ送信しうる。ＧＯＰシンタックス・データは、それぞれのＧＯＰにおけるフレームの数を記述しうる。そして、フレーム・シンタックス・データは、対応するフレームをエンコードするために使用されるエンコード／予測モードを示しうる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０はおのおの、適用可能であれば、例えば、１または複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれら任意の組み合わせのように、さまざまな適切なエンコーダまたはデコーダ回路の何れかとして実現されうる。ビデオ・エンコーダ２０およびビデオ・デコーダ３０のおのおのは、１または複数のエンコーダまたはデコーダに含まれうる。これらの何れかは、結合されたビデオ・エンコーダ／デコーダ（コーデック）の一部として統合されうる。ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／または、例えばセルラ電話のような無線通信デバイスを含みうる。

図２は、複数のウェーブフロントを並列的にコーディングするための技法を実施しうるビデオ・エンコーダ２０の例を例示するブロック図である。ビデオ・エンコーダ２０は、ビデオ・スライス内で、ビデオ・ブロックのイントラ・コーディングおよびインタ・コーディングを実行しうる。イントラ・コーディングは、所与のビデオ・フレームまたはピクチャ内のビデオにおける空間冗長を低減または除去するために、空間予測に依存する。インタ・コーディングは、ビデオ・シーケンスの隣接するフレームまたはピクチャ内のビデオにおける時間冗長を低減または除去するために、時間予測に依存する。イントラ・モード（Ｉモード）は、いくつかの空間ベースのコーディング・モードのうちの何れかを称しうる。例えば単一方向予測（Ｐモード）または双方向予測（Ｂモード）のようなインタ・モードは、いくつかの時間ベースのコーディング・モードのうちの何れかを称しうる。

図２に図示されるように、ビデオ・エンコーダ２０は、エンコードされるべきビデオ・フレーム内の現在のビデオ・ブロックを受け取る。図２の例では、ビデオ・エンコーダ２０は、モード選択ユニット４０、基準ピクチャ・メモリ６４、加算器５０、変換処理ユニット５２、量子化ユニット５４、およびエントロピ・エンコード・ユニット５６を含んでいる。一方、モード選択ユニット４０は、動き補償ユニット４４、動き推定ユニット４２、イントラ予測ユニット４６、および分割ユニット４８を含んでいる。ビデオ・ブロック再構築のために、ビデオ・エンコーダ２０はまた、逆量子化ユニット５８、逆変換ユニット６０、および加算器６２を含んでいる。再構築されたビデオからのブロッキネス・アーティファクト（blockiness artifacts）を除去するためにブロック境界をフィルタするデブロッキング・フィルタ（図２に図示せず）もまた含まれうる。所望されるのであれば、デブロッキング・フィルタは、一般には、加算器６２の出力をフィルタするであろう。デブロッキング・フィルタに加えて、（ループまたはポスト・ループにおける）追加のフィルタも使用されうる。このようなフィルタは、簡潔さのために図示されていないが、もしも所望されるのであれば、加算器５０の出力を（イン・ループ・フィルタとして）フィルタしうる。

エンコード処理中、ビデオ・エンコーダ２０は、コーディングされるべきビデオ・フレームまたはスライスを受け取る。フレームまたはスライスは、複数のビデオ・ブロックに分割されうる。動き推定ユニット４２および動き補償ユニット４４は、時間予測を与えるために、１または複数の基準フレームにおける１または複数のブロックに対して、受け取られたビデオ・ブロックのインタ予測コーディングを実行する。イントラ予測ユニット４６は、代わりに、同じフレームまたはスライスにおける１または複数の近隣ブロックに対して、受け取られたビデオ・ブロックのイントラ予測コーディングを、空間予測を提供するためにコーディングされるべきブロックとして実行しうる。ビデオ・エンコーダ２０は、例えば、ビデオ・データの各ブロックのために適切なコーディング・モードを選択するために、複数のコーディング・パスを実行しうる。

さらに、分割ユニット４８は、以前のコーディング・パスにおける以前の分割スキームの評価に基づいて、ビデオ・データのブロックを、サブ・ブロックに分割しうる。例えば、分割ユニット４８は、先ず、フレームまたはスライスを、ＣＴＵに分割し、ＣＴＵのおのおのを、レート歪み分析（例えば、レート歪み最適化）に基づいてサブＣＵに分割しうる。モード選択ユニット４０はさらに、ＣＴＵのサブＣＵへの分割を示すクワッドツリー・データ構造を生成しうる。クワッドツリーのリーフ・ノードＣＵは、１または複数のＰＵおよび１または複数のＴＵを含みうる。

モード選択ユニット４０は、例えば、誤り結果に基づいて、イントラまたはインタのコーディング・モードのうちの１つを選択しうる。そして、結果として得られたイントラ・コーディングされたブロックまたはインタ・コーディングされたブロックを加算器５０に提供し、残余ブロック・データを生成し、加算器６２に提供し、エンコードされたブロックを、基準フレームとして使用するために再構築する。モード選択ユニット４０はまた、例えば、動きベクトル、イントラ・モード・インジケータ、分割情報、およびその他のこのようなシンタックス情報を、エントロピ・コーディング・ユニット５６に提供する。

動き推定ユニット４２および動き補償ユニット４４は、高度に統合されうるが、概念の目的のために、個別に例示されている。動き推定ユニット４２によって実行される動き推定は、動きベクトルを生成する処理であり、ビデオ・ブロックの動きを推定する。例えば、動きベクトルは、現在のフレーム内でコーディングされている現在のブロック（または、その他のコーディングされたユニット）に対する、基準フレーム内の予測ブロック（または、その他のコーディングされたユニット）に対する現在のビデオ・フレームまたはピクチャ内のビデオ・ブロックのＰＵの変位を示しうる。予測ブロックは、絶対差分（ＳＡＤ）の合計、平方差分（ＳＳＤ）の合計、または、その他の別のメトリックによって決定されうるピクセル差分の観点においてコーディングされるべきブロックに緊密にマッチするものとして発見されるブロックである。いくつかの例では、ビデオ・エンコーダ２０は、基準ピクチャ・メモリ６４内に格納された基準ピクチャの整数未満のピクセル位置の値を計算しうる。例えば、ビデオ・エンコーダ２０は、基準ピクチャの、１／４ピクセル位置、１／８ピクセル位置、または、その他の分数のピクセル位置の値を補間しうる。したがって、動き推定ユニット４２は、フル・ピクセル位置および分数ピクセル位置に対する動き探索を実行し、動きベクトルを、分数ピクセル精度で出力しうる。

動き推定ユニット４２は、ＰＵの位置を、基準ピクチャの予測ブロックの位置と比較することによって、インタ・コード・スライスにおけるビデオ・ブロックのＰＵの動きベクトルを計算する。基準ピクチャは、第１の基準ピクチャ・リスト（リスト０）または第２の基準ピクチャ・リスト（リスト１）から選択されうる。これらのおのおのは、基準ピクチャ・メモリ６４に格納された１または複数の基準ピクチャを識別しうる。動き推定ユニット４２は、計算された動きベクトルを、エントロピ・エンコード・ユニット５６および動き補償ユニット４４へ送信する。

動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを含みうる。繰り返すが、動き推定ユニット４２と動き補償ユニット４４とは、いくつかの例では、機能的に統合されうる。動き補償ユニット４４は、現在のビデオ・ブロックのＰＵの動きベクトルを受け取ると、基準ピクチャ・リストのうちの１つにおいて動きベクトルが指し示す予測ブロックを位置決めしうる。加算器５０は、以下に示すように、予測ブロックのピクセル値を、コーディングされている現在のビデオ・ブロックのピクセル値から引くことによって、ピクセル差分値を生成する。一般に、動き推定ユニット４２は、輝度成分に対する動き推定を実行し、動き補償ユニット４４は、彩度成分と輝度成分との両方のために、輝度成分に基づいて計算された動きベクトルを用いる。また、モード選択ユニット４０は、ビデオ・スライスのビデオ・ブロックをデコードする際に、ビデオ・デコーダ３０によって使用されるための、ビデオ・ブロックおよびビデオ・スライスに関連付けられたシンタックス要素を生成しうる。

イントラ予測ユニット４６は、前述されたように、動き推定ユニット４２および動き補償ユニット４４によって実行されるインタ予測に対する代替として、現在のブロックをイントラ予測しうる。特に、イントラ予測ユニット４６は、現在のブロックをエンコードするために使用するための、イントラ予測モードを決定しうる。

いくつかの例では、イントラ予測ユニット４６は、例えば、個別のエンコーディング・パスの間、さまざまなイントラ予測モードを用いて現在のブロックをエンコードし、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから、使用する適切な予測モードを選択しうる。

例えば、イントラ予測ユニット４６は、テストされたさまざまなイントラ予測モードのためのレート歪み値を、レート歪み分析を用いて計算し、テストされたモードのうち最良のレート歪み特性を有するイントラ予測モードを選択しうる。レート歪み分析は、一般に、エンコードされたブロックと、エンコードされたブロックを生成するためのエンコードされる、オリジナルのエンコードされていないブロックとの間の歪み（または誤差）の量のみならず、エンコードされたブロックを生成するために使用されるビットレート（すなわち、ビット数）をも決定する。イントラ予測ユニット４６は、どのイントラ予測モードが、ブロックのために最良のレート歪み値（または、最低のコスト値）を示すのかを判定するために、エンコードされたさまざまなブロックのレートおよび歪みからの比を計算しうる。

ブロックのためのイントラ予測モードを選択した後、イントラ予測ユニット４６は、ブロックのために選択されたイントラ予測モードを示す情報を、エントロピ・エンコード・ユニット５６へ提供しうる。エントロピ・エンコード・ユニット５６は、選択されたイントラ予測モードを示す情報をエンコードしうる。ビデオ・エンコーダ２０は、送信されるビットストリームに、コンフィギュレーション・データを含めうる。このデータは、複数のイントラ予測モード・インデクス・テーブルおよび複数の修正されたイントラ予測モード・インデクス・テーブル（これらは、コードワード・マッピング・テーブルとも称される）、さまざまなブロックのエンコード・コンテキストの定義、最も確実性の高いイントラ予測モードを示すインジケーション、イントラ予測モード・インデクス・テーブル、および、コンテキストのおのおのを使用するための修正されたイントラ予測モード・インデクス・テーブルを含みうる。

ビデオ・エンコーダ２０は、コーディングされているオリジナルのビデオ・ブロックから、モード選択ユニット４０からの予測データを引くことにより、残余ビデオ・ブロックを生成する。加算器５０は、この減算演算を実行する構成要素（単数または複数）を表す。変換処理ユニット５２は、例えば離散コサイン変換（ＤＣＴ）または概念的に類似した変換のような変換を、残余ブロックに適用し、残余変換係数値を備えるビデオ・ブロックが生成される。変換処理ユニット５２は、概念的にＤＣＴに類似したその他の変換を実行しうる。ウェーブレット変換、整数変換、サブ帯域変換、またはその他のタイプの変換もまた使用されうる。何れの場合も、変換処理ユニット５２は、この変換を残余ブロックに適用し、残余変換係数のブロックが生成される。この変換は、残余情報を、ピクセル値領域から、例えば周波数領域のような変換領域に変換しうる。

変換処理ユニット５２は、結果として得られた変換係数を量子化ユニット５４へ送信しうる。量子化ユニット５４は、さらにビット・レートを低減するために、この変換係数を量子化する。この量子化処理は、これら係数のうちのいくつかまたはすべてに関連付けられたビット・デプスを低減しうる。量子化の程度は、量子化パラメータを調節することにより修正されうる。いくつかの例では、その後、量子化ユニット５４は、量子化された変換係数を含むマトリックスのスキャンを実行しうる。あるいは、エントロピ・エンコード・ユニット５６が、このスキャンを実行しうる。

量子化の後、エントロピ・エンコード・ユニット５６は、量子化された変換係数を、エントロピ・エンコードする。例えば、エントロピ・エンコード・ユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ計算コーディング（ＣＡＢＡＣ）、シンタックス・ベースのコンテキスト適応バイナリ演算コーディング（ＳＢＡＣ）、確率インタバル分割エントロピ（ＰＩＰＥ）コーディング、またはその他のエントロピ・コーディング技法を実行しうる。コンテキスト・ベースのエントロピ・エンコーディングのケースでは、コンテキストは、近隣のブロックに基づきうる。エンコードされたビットストリームは、エントロピ・エンコード・ユニット５６によるエントロピ・コーディング後、（例えばビデオ・デコーダ３０のような）別のデバイスへ送信されうるか、または、後の送信または取得のためにアーカイブされうる。

例では、エントロピ・エンコード・ユニット５６は、ウェーブフロント並列処理（ＷＰＰ）を用いて、量子化された変換係数をエントロピ・エンコードしうる。図１に関して記載されるように、ＷＰＰは、量子化された変換係数を並列的にエントロピ・エンコードすることを含みうる。例えば、エントロピ・エンコード・ユニット５６は、量子化された変換係数を、複数の行、すなわちウェーブフロントへ整えうる。一方、エントロピ・エンコード・ユニット５６は、例えば、近隣係数に関連付けられた１または複数の動きベクトルのように、モード選択ユニット４０から受け取られたシンタックス要素を用いて各係数をエンコードしうる。ＷＰＰを用いてエンコードするという観点では、エントロピ・エンコード・ユニット５６は、ウェーブフロントの先頭または終了以外の任意の位置における係数のために、エンコードされるべき係数の左、左上、上、および右上に位置する係数に関連付けられた動きベクトルを用いうる。

ＷＰＰベースのエントロピ・エンコーディングの効率を高めるために、エントロピ・エンコード・ユニット５６は、量子化された変換係数に関して、従来のスライス・ウェーブフロント・インタラクションを制限するために、本開示の技法を実施しうる。記載されているように、例えばビデオ・エンコーダ２０のようなビデオ・コーダは、イメージ、またはイメージを代表するデータを、複数のスライスに分割しうる。図２に関し、量子化された変換係数のストリームが、複数のスライスに分割されうる。一方、スライスは、エントロピ・エンコード・ユニット５６によって区別された１または複数のウェーブフロントの変動部分をカバーしうる。例えば、第１のスライスは、第１のウェーブフロントの全体と、第２のウェーブフロントの不完全な部分をカバーしうる。第２のスライスは、第１のスライスによってカバーされていない第２のウェーブフロントの残りと、第３のウェーブフロントの不完全な部分をカバーしうる。このように、ＷＰＰによって提供されるような従来のスライス・ウェーブフロント・インタラクションは、スライスの開始／終了点を、ウェーブフロントの開始／終了点に相関付けないことがありうる。

ＷＰＰにしたがうエントロピ・エンコードの効率を高めるために、エントロピ・エンコード・ユニット５６は、本開示の１または複数の技法を実施しうる。例えば、エントロピ・エンコード・ユニット５６は、量子化ユニット５４から受けとられた量子化変換係数に基づいて、ウェーブフロントの開始以外の位置におけるピクチャ内のウェーブフロント、すなわち、コーディング・ツリー・ユニット（ＣＴＵ）の行において、ビデオ・データのピクチャのスライスが始まると判定しうる。この判定に基づいて、エントロピ・エンコード・ユニット５６は、スライスがウェーブフロント内で終了すると判定し、この判定に基づいて、スライスをコーディングしうる。さらに詳しくは、エントロピ・エンコード・ユニット５６は、例えば、ウェーブフロントの最後の係数がエンコードされると、エンド・オブ・スライス・シンボルをＮＡＬユニットに挿入することによって、ウェーブフロントの最後の係数においてスライスを終了しうる。このように、エントロピ・エンコード・ユニット５６は、特定のＣＴＵをコーディングしている間、エントロピ・エンコード・ユニット５６がＷＰＰにしたがって特定のＣＴＵをコーディングするためのすべての情報へのアクセスを有することと、特定のＣＴＵのスライス・ヘッダ・データが、すでにエントロピ・エンコードされていることと、を保証しうる。

さらに、エントロピ・エンコード・ユニット５６は、次のウェーブフロントの第１の係数をエンコードする前に、ＮＡＬユニットにスライス・ヘッダを挿入しうる。この事例では、エントロピ・エンコード・ユニット５６は、次のウェーブフロントの開始が、個別のスライスの開始と一致するように、量子化された変換係数のストリームをエンコードしうる。新たなスライスが、２番目のウェーブフロント全体を含み、３番目のウェーブフロントにスピルオーバするのであれば、エントロピ・エンコード・ユニット５６は、ＷＰＰにしたがって、３番目のウェーブフロントを効率的にコーディングするために必要なデータのすべてへのアクセスを有しうる。さらに詳しくは、エントロピ・エンコード・ユニット５６は、３番目のウェーブフロントのすべてのＣＴＵのスライス・ヘッダが、３番目のウェーブフロントの何れかのＣＴＵがエントロピ・エンコードされる前にエントロピ・エンコードされていることを保証しうる。

特定の例では、エントロピ・エンコード・ユニット５６は、３番目のウェーブフロントの第２の係数をコーディングしている間、２番目および３番目のウェーブフロントのおのおのの第１の係数（すなわち、現在の係数のうちの左および左上の係数）と、２番目のウェーブフロントの第２の係数（すなわち、現在の係数のすぐ上に位置する係数）と、２番目のウェーブフロントの第３の係数（すなわち、現在の係数の右上に位置する係数）とを識別する動きベクトルに、モード選択ユニット４０によって送信されたシンタックス要素からアクセスしうる。さらに、２番目のスライス・ヘッダは、２番目のウェーブフロントの第１の係数と一致するので、第２の係数のスライス・ヘッダは、既にエントロピ・エンコードされている。このように、エントロピ・エンコード・ユニット５６は、現在のスライスをエンコードするために本開示の技法を実施し、これによって、ＷＰＰを用いたその後のスライスのエンコードがより効率的になる。

逆量子化ユニット５８および逆変換ユニット６０は、例えば、基準ブロックとして後に使用するために、逆量子化または逆変換をそれぞれ適用し、ピクセル領域内の残余ブロックを再構築しうる。動き補償ユニット４４は、残余ブロックを、基準ピクチャ・メモリ６４のフレームのうちの１つの予測ブロックへ加えることによって、基準ブロックを計算しうる。動き補償ユニット４４はまた、動き推定において使用するための整数未満のピクセル値を計算するために、１または複数の補間フィルタを、再構築された残余ブロックに適用しうる。加算器６２は、動き補償ユニット４４によって生成された動き補償予測ブロックに、再構築された残余ブロックを加え、基準ピクチャ・メモリ６４に格納するための再構築されたビデオ・ブロックが生成される。再構築されたビデオ・ブロックは、その後のビデオ・フレームにおけるブロックをインタ・コーディングするために、動き推定ユニット４２および動き補償ユニット４４によって、基準ブロックとして使用されうる。

前述したように、ビデオ・エンコーダ２０は、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、行の先頭以外の位置において始まることを判定することと、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定することと、このスライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングすることと、を実行するように構成されたビデオ・コーダの例を示す。例において、ビデオ・エンコーダ２０は、例えばデスクトップ・コンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレット・コンピュータ、セット・トップ・ボックス、いわゆる「スマート」フォンのようなテレフォン・ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイ・デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイス等のような、ビデオ・データをコーディングするためのデバイスに含まれうる。例において、ビデオ・データをコーディングするためのそのようなデバイスは、ビデオ・エンコーダ２０を含む通信デバイス、マイクロプロセッサ、および集積回路のうちの１または複数を含みうる。

図３は、ウェーブフロントを並列的にコーディングするための技法を実施しうるビデオ・デコーダ３０の例を例示するブロック図である。図３の例では、ビデオ・デコーダ３０は、エントロピ・デコード・ユニット７０、動き補償ユニット７２、イントラ予測ユニット７４、逆量子化ユニット７６、逆変換ユニット７８、基準ピクチャ・メモリ８２、および加算器８０を含んでいる。ビデオ・デコーダ３０は、いくつかの例において、ビデオ・エンコーダ２０（図２）に関して記載されたエンコード・パスに一般に逆であるデコード・パスを実行しうる。動き補償ユニット７２は、エントロピ・デコード・ユニット７０から受け取った動きベクトルに基づいて、予測データを生成しうる一方、イントラ予測ユニット７４は、エントロピ・デコード・ユニット７０から受け取ったイントラ予測モード・インジケータに基づいて、予測データを生成しうる。

デコード処理中、ビデオ・デコーダ３０は、関連付けられたシンタックス要素とエンコードされたビデオ・スライスのビデオ・ブロックを示す、エンコードされたビデオ・ビットストリームを、ビデオ・エンコーダ２０から受け取る。ビデオ・デコーダ３０のエントロピ・デコード・ユニット７０は、量子化された係数、動きベクトルまたはイントラ予測モード予測子、およびその他のシンタックス要素を生成するために、ビットストリームをエントロピ・デコードする。エントロピ・デコード・ユニット７０は、動きベクトルおよびその他のシンタックス要素を、動き補償ユニット７２へ転送する。ビデオ・デコーダ３０は、ビデオ・スライス・レベルおよび／またはビデオ・ブロック・レベルにおいて、シンタックス要素を受け取りうる。

エントロピ・デコード・ユニット７０は、ウェーブフロント並列処理（ＷＰＰ）を用いてイメージをより効率的にエントロピ・デコードするために、スライス・ウェーブフロント・インタラクションを制限するために、本開示の技法を実施しうる。例えば、エントロピ・デコード・ユニット７０は、例えば、受け取られたＮＡＬユニットにおけるスライス・ヘッダが、それぞれのウェーブフロントの最初のＣＴＵではないＣＴＵと一致していると判定することよって、スライスが、ウェーブフロントの中間において始まると判定しうる。この判定に基づいて、エントロピ・デコード・ユニット７０は、例えば、受け取られたＮＡＬユニットが、現在のウェーブフロントの最後のＣＴＵの終了においてエンド・オブ・スライス・シンボルを含んでいると判定することによって、スライスが、同じウェーブフロント内で終了すると判定しうる。

このようにしてスライス・ウェーブフロント・インタラクションを制限することによって、エントロピ・デコード・ユニット７０は、ＷＰＰを用いてイメージをより効率的にエントロピ・デコードしうる。例えば、エントロピ・デコード・ユニット７０は、特定のＣＴＵをデコードしている間、エントロピ・デコード・ユニット７０が、ＷＰＰを用いて特定のＣＴＵをデコードするために必要なすべての情報へのアクセスを有することと、エントロピ・デコード・ユニット７０が特定のＣＴＵをデコードする準備ができる時までに、特定のＣＴＵのスライス・ヘッダが、すでにエントロピ・デコードされていることと、を保証しうる。このように、エントロピ・デコード・ユニット７０は、ＷＰＰにしたがってイメージをより効率的にデコードするために、本開示の技法を実施しうる。

ビデオ・スライスが、イントラ・コード（Ｉ）スライスとしてコーディングされた場合、イントラ予測ユニット７４は、現在のフレームまたはピクチャの、以前にデコードされたブロックからの、シグナルされたイントラ予測モードおよびデータに基づいて、現在のビデオ・スライスのビデオ・ブロックの予測データを生成しうる。ビデオ・フレームが、インタ・コーディングされた（すなわち、Ｂ、Ｐ、またはＧＰＢ）スライスとしてコーディングされている場合、動き補償ユニット７２は、エントロピ・デコード・ユニット７０から受け取られた動きベクトルおよびその他のシンタックス要素に基づいて、現在のビデオ・スライスのビデオ・ブロックの予測ブロックを生成する。予測ブロックは、基準ピクチャ・リストのうちの１つ内の、基準ピクチャのうちの１つから生成されうる。ビデオ・デコーダ３０は、基準ピクチャ・メモリ８２に格納された基準ピクチャに基づいて、デフォルトの構築技法を用いて、基準フレーム・リスト、リスト０およびリスト１を構築しうる。動き補償ユニット７２は、動きベクトルおよびその他のシンタックス要素を解析することによって、現在のビデオ・スライスのビデオ・ブロックの予測情報を決定し、この予測情報を用いて、デコードされている現在のビデオ・ブロックの予測ブロックを生成する。例えば、動き補償ユニット７２は、受け取ったシンタックス要素のうちのいくつかを用いて、ビデオ・スライスのビデオ・ブロック、インタ予測スライス・タイプ（例えば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）、スライスのための基準ピクチャ・リストのうちの１または複数の構築情報、スライスの各インタ・エンコード・ビデオ・ブロックの動きベクトル、スライスの各インタ・コード・ビデオ・ブロックのインタ予測状態、および、現在のビデオ・スライスにおけるビデオ・ブロックをデコードするためのその他の情報、をコーディングするために使用される予測モード（例えば、イントラ予測またはインタ予測）を決定する。

動き補償ユニット７２はまた、補間フィルタに基づいて、補間を実行しうる。動き補償ユニット７２は、基準ブロックの整数未満ピクセルの補間値を計算するために、ビデオ・ブロックのエンコード中、ビデオ・エンコーダ２０によって使用されるような補間フィルタを使用しうる。このケースでは、動き補償ユニット７２は、受け取られたシンタックス要素から、ビデオ・エンコーダ２０によって使用される補間フィルタを決定し、この補間フィルタを用いて、予測ブロックを生成する。

逆量子化ユニット７６は、ビットストリームで提供され、エントロピ・デコード・ユニット８０によってデコードされた、量子化された変換係数を逆量子化、すなわちｄｅ ｑｕａｎｔｉｚｅする。逆量子化処理は、量子化の程度、および、適用されるべき逆量子化の程度も同様に決定するために、ビデオ・スライスにおけるおのおののビデオ・ブロックについて、ビデオ・デコーダ３０によって計算される量子化パラメータ（ＱＰＹ）を使用することを含みうる。

逆変換ユニット７８は、ピクセル領域における残余ブロックを生成するために、例えば、逆ＤＣＴ、逆整数変換、または概念的に同様な逆変換処理を変換係数に適用する。

動き補償ユニット７２が、動きベクトルおよびその他のシンタックス要素に基づいて、現在のビデオ・ブロックの予測ブロックを生成した後、ビデオ・デコーダ３０は、逆変換ユニット７８からの残余ブロックと、動き補償ユニット７２によって生成された対応する予測ブロックとを総和することによって、デコードされたビデオ・ブロックを生成する。加算器８０は、この総和演算を実行する構成要素（単数または複数）を表わす。所望されるのであれば、ブロッキネス・アーティファクトを除去するために、デブロッキング・フィルタも適用され、デコードされたブロックがフィルタされる。その他のループ・フィルタ（コーディング・ループ中の、またはコーディング・ループ後の何れか）もまた、ピクセル推移を平滑化するために、あるいは、ビデオ品質を改善するために、使用されうる。所与のフレームまたはピクチャ内の、デコードされたビデオ・ブロックは、その後、基準ピクチャ・メモリ８２に格納される。基準ピクチャ・メモリ８２は、その後の動き補償のために使用される基準ピクチャを格納する。基準ピクチャ・メモリ８２はまた、例えば、図１のディスプレイ・デバイス３２のような、ディスプレイ・デバイスにおける後の表示のために、デコードされたビデオを格納する。

このように、ビデオ・デコーダ３０は、ビデオ・データのピクチャのスライスが、ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、この行の先頭以外の位置において始まることを判定することと、この判定に基づいて、このスライスがＣＴＵの行内で終わると判定することと、このスライスがＣＴＵの行内で終わるとの判定に基づいて、このスライスをコーディングすることと、を実行するように構成されたビデオ・コーダの例を表す。例において、ビデオ・デコーダ３０は、例えばデスクトップ・コンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレット・コンピュータ、セット・トップ・ボックス、いわゆる「スマート」フォンのようなテレフォン・ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイ・デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイス等のような、ビデオ・データをコーディングするためのデバイスに含まれうる。例において、ビデオ・データをコーディングするためのそのようなデバイスは、ビデオ・デコーダ３０を含む通信デバイス、マイクロプロセッサ、および集積回路のうちの１または複数を含みうる。

図４は、ウェーブフロント１５０−１６０に分割されたピクチャ１００の例を例示する概念図である。ウェーブフロント１５０−１６０のおのおのは、多くのブロックを含んでいる。ピクチャ１００は、さらなるウェーブフロントを含み、おのおののウェーブフロントは、図示されるもの以外のさらなるブロックを含みうることが注目されるべきである。ブロックの各々は、例えばＣＴＵに対応しうる。

例えば、ビデオ・エンコーダ２０またはビデオ・デコーダ３０のようなビデオ・コーダは、ウェーブフロント１５０−１６０を並列的にコーディングするように構成されうる。ビデオ・エンコーダ２０は、上のウェーブフロントのうちの２ブロックがコーディングされた後に、ウェーブフロントのコーディングを開始しうる。図４は、この後、比較的水平な曲線矢印によって接続されている黒い点を用いてウェーブフロントがコーディングされうるブロックを例示する。例えば、ウェーブフロント１５６のブロック１３４は、ウェーブフロント１５４のブロック１２８がコーディングされた後にコーディングされうる。例として、ビデオ・コーダは、“Ｘ”を用いて印されたブロック、すなわち、ブロック１１６，１２４，１３２，および１３６のおのおのを並列的にコーディングしうる。図４の例では、破線１０２，１０４，１０６，および１０８は、解析されたブロックを表し、これらから、特定のコーディグ時間における取得のための情報が利用可能である。特定のコーディング時間は、“Ｘ”を用いて印されたブロック、すなわち、ブロック１１６，１２４，１３２，および１３６がコーディングされる時間に対応しうる。

したがって、ビデオ・コーダは、図４において実線の白矢印によって示されたブロックから、“Ｘ”を用いて印されたブロックのためのコンテキスト情報を取得しうる。図４に図示されるように、実線の白矢印が示すブロックのおのおのが、破線１０２，１０４，１０６，および１０８のうちの１つ内にある。例えば、ビデオ・コーダが、ブロック１１４から、ブロック１１６のためのコンテキスト情報を取得し、ビデオ・コーダが、ブロック１１０，１１２，１１４，および／または１２２から、ブロック１２４のためのコンテキスト情報を取得し、ビデオ・コーダが、ブロック１１８，１２０，１２２，および／または１３０から、ブロック１３２のためのコンテキスト情報を取得し、ビデオ・コーダが、ブロック１２６，１２８，１３０，および／または１３４から、ブロック１３６のためのコンテキスト情報を取得しうる。集合的に、破線１０２，１０４，１０６，および１０８は、ＣＴＵグループ、すなわち、ビデオ・コーダが、ＷＰＰにしたがって、所与の時間においてコーディングすることができるピクチャ１００のブロックの集合を含む。

本開示の技法にしたがって、ウェーブフロント１５０−１６０のおのおのは、１または複数のスライスの一部または全体を含みうる。あるいは、スライスは、例えばウェーブフロント１５０−１６０のうちの１または複数のように、１または複数のウェーブフロントの一部または全体を含みうる。例えば、１番目のスライスは、ウェーブフロント１５０および１５２のブロックを含み、２番目のスライスは、ウェーブフロント１５２，１５４および１５６のブロックを含み、３番目のスライスは、ウェーブフロント１５８および１６０のブロックを含みうる。このように、スライスが、２つのウェーブフロント間の境界を超えた場合、スライスは、２つのウェーブフロントのうちのいくつかまたはすべてのブロックを含みうる。

ビデオ・コーダが、ブロック１３２をコーディングすべきであると仮定されたい。ブロック１３２を含むウェーブフロント１５４のコンテキスト状態を初期化するために、ビデオ・コーダは、ブロック１３２を含むスライスのためのスライス・ヘッダの１または複数のパラメータを必要としうる。スライスが、ウェーブフロント１５２の中間におけるブロックで始まることと、ウェーブフロント１５２とウェーブフロント１５４との間の境界を超えることとが許されるのであれば、ビデオ・コーダは、スライス・ヘッダの情報を取得するためにスライス中の第１のブロックをコーディングするのを待たねばならないことがありうる。例えば、スライスが、ブロック１１６の下のウェーブフロント１５２におけるブロックの水平位置において始まるのであれば、このブロックは、まだ解析されていないであろうから、ビデオ・コーダは、ウェーブフロント１５４のコーディングを開始する前に、このブロックが解析されるまで待つ必要になるであろう。しかしながら、ビデオ・コーダは、スライスが、ウェーブフロントの先頭以外の位置におけるピクチャ１００のウェーブフロントで始まるのであれば、このスライスが、その特定のウェーブフロント内で終了することを定めるために、本開示の技法を実施しうる。言い換えれば、ピクチャ１００のどのウェーブフロントも、スライス・ヘッダで始まるか、または、エンド・オブ・スライス・シンボルで終了しうる（または、その両方である）。このようにスライス・ウェーブフロント・インタラクションを制限することによって、ビデオ・コーダは、ピクチャ１００の特定のブロックをコーディングしている間、ビデオ・コーダが、ＷＰＰにしたがってブロックをコーディングするために必要なすべての情報へのアクセスを有することと、ブロックに対応するスライス・ヘッダがすでにコーディングされていることと、を保証しうる。したがって、ビデオ・コーダは、ウェーブフロント並列処理（ＷＰＰ）にしたがってブロックをコーディングすることを待つ必要がある状況の発生を回避しうる。

さらに詳しくは、ビデオ・コーダは、例えばＣＡＢＡＣを用いて、ウェーブフロント並列処理（ＷＰＰ）にしたがってブロックをコーディングするために必要なすべてのデータが利用可能であることと、ブロックのスライス・ヘッダがすでにコーディングされているという点において、ブロックがコーディングされる準備ができていることと、を保証するために本技法を実施しうる。さまざまなビデオ・コーダが本技法を実施しうるが、説明の目的のために、本技法のうちの１または複数は、図２のビデオ・エンコーダ２０および図３のビデオ・デコーダおよびこれらのそれぞれの構成要素を参照して記載されている。例えば、ビデオ・デコーダ３０のエントロピ・デコード・ユニット７０は、ＷＰＰにしたがってブロックをコーディングするために必要なすべてのデータが利用可能であることと、ブロックの対応するスライス・ヘッダがすでにコーディングされていることと、を保証するために、ピクチャ１００内のスライス・ウェーブフロント・インタラクションを制限しうる。例えば、エントロピ・デコード・ユニット７０は、ピクチャ１００のスライスがウェーブフロント１５０であるが、ウェーブフロント１５０の先頭以外の位置（例えば、ブロック１１０）において始まることを判定しうる。この判定に基づいて、エントロピ・デコード・ユニット７０は、スライスがウェーブフロント１５０内で終了すると判定しうる。例えば、エントロピ・デコード・ユニット７０は、ピクチャ１００の一部を表わす、受け取られたＮＡＬユニットにおいて、ウェーブフロント１５０の最後にエンコードされたブロックの直後のエンド・オブ・スライス・シンボルを検出し、ウェーブフロント１５２の最初にエンコードされたブロックの直前のスライス・ヘッダを検出しうる。このように、ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０は、特定のブロックがコーディングされる準備ができる前に、ウェーブフロント１５２の任意の特定のブロックのスライス・ヘッダがコーディングされたことを保証しうる。

ＷＰＰにしたがってピクチャ１００をエンコードするコンテキストでは、ビデオ・エンコーダ２０のエントロピ・エンコード・ユニット５６は、ブロック１１０において始まるスライスが、ウェーブフロント１５２の１または複数のブロックをも含んでいることを検出しうる。この概念は、本明細書では、「スライス・スピルオーバ」と称される。この事例では、エントロピ・エンコード・ユニット５６は、ウェーブフロント１５０の最後のブロックを含めた後にスライスを終了し、ウェーブフロント１５２の最初のブロックを含む新たなスライスを開始しうる。記載されているように、エントロピ・エンコード・ユニット５６は、ピクチャ１００を表わす、エンコードされたデータを含むＮＡＬユニットを生成し、ウェーブフロント１５０の最後のブロックを（エンコードされたとして）表わすデータの後にエンド・オブ・スライス・シンボルを挿入しうる。同様に、エントロピ・エンコード・ユニット５６は、ウェーブフロント１５２の最初のブロックを、エンコードされたものとして表わすデータの直前のスライス・ヘッダを、同じまたは後続するＮＡＬユニット内に挿入しうる。これらの制限を実行することによって、ビデオ・エンコーダ２０は、ウェーブフロント１５０および／または１５２の所与のブロックのスライス・ヘッダが、所与のブロックがコーディングされる準備ができる前にコーディングされていることを保証しうる。このように、ビデオ・エンコーダ２０は、ＷＰＰをより効率的に利用するためにスライス・ウェーブフロント・インタラクションを制限するために、および、ＷＰＰをより効率的に利用するようにビデオ・デコーダ３０をイネーブルするために、本開示の技法を実施しうる。

このように、ビデオ・コーダは、ピクチャ１００のスライスが、行の先頭以外であるピクチャ１００のＣＴＵの行において始まることを判定しうる。この判定に基づいて、ビデオ・コーダは、ＣＴＵの行内でスライスが終了していることを判定し、スライスがＣＴＵの行内で終了しているとの判定に基づいてスライスをコーディングしうる。

前述したように、いくつかの例では、例えばビデオ・エンコーダ２０またはビデオ・デコーダ３０のようなビデオ・コーダは、ビデオ・データのスライスが、フル行を備えるコーディング・ツリー・ユニット（ＣＴＵ）の最初の行と、フル行よりも少ないＣＴＵを備えるＣＴＵの２番目の行の一部分とを含んでいる場合、このスライスが、最大のコーディング・ユニットのうちの少なくとも１つのフル行の先頭において始まるように、ビデオ・データをコーディングするように構成されうる。例えば、スライスが、ウェーブフロント１５０の先頭で始まると仮定されたい。この例において、スライスは、例えばウェーブフロント１５２のような、後続するウェーブフロントの中間（すなわち、後続するウェーブフロントの終了前）において終了しうる。

例えば、スライスがブロック１２０において終了すると仮定されたい。これは、前述した制約によって可能となるであろう。なぜなら、このスライスは、ウェーブフロント、すなわち、この例ではウェーブフロント１５０の先頭で始まるからである。したがって、後続するスライスは、ブロック１２２において開始しうる。しかしながら、このスライスは、この例において、ウェーブフロント１５２の終了時において境界を超えることを許されないであろう。したがって、スライスは、ウェーブフロント１５２の終了で終わるであろう。もちろん、この例では、スライスが、ウェーブフロント１５２とウェーブフロント１５４との間の境界を超えない限りは、ウェーブフロント１５２内に、さらなるスライスが追加されないことがありうる。

図５は、ビデオ・コーダが、ウェーブフロントを並列的にコーディングするために本開示の技法を実施しうる処理１８０の例を例示するフローチャートである。図５は、例えば、ビデオ・エンコーダ２０のようなビデオ・コーダが、本開示の１または複数の技法を用いて、例えば、ビデオ・データのフレームのようなピクチャをエンコードしうる処理１８０の例を例示する。処理１８０は、本開示の態様にしたがってさまざまなデバイスによって実行されうるが、説明の目的で、処理１８０は、本明細書では、図４のピクチャ１００においても同様に、図１−２のデバイスおよびそれらの構成要素に関して記載されている。処理１８０は、デバイスがビデオ・データのピクチャを受け取る場合に始まりうる（１８２）。一例として、ソース・デバイス１２は、１または複数の入力デバイスによってピクチャ１００を受け取りうる。

さらに、ソース・デバイス１２は、ウェーブフロント並列処理（ＷＰＰ）をイネーブルしうる（１８４）。例えば、ソース・デバイス１２は、ＷＰＰをイネーブルしうる。これは、ビデオ・エンコーダ２０に対して、ＷＰＰにしたがってピクチャ１００をエンコードさせる。例えばビデオ・エンコーダ２０のようなビデオ・コーダは、ピクチャ１００のウェーブフロントを決定しうる（１８６）。例えば、ビデオ・エンコーダ２０は、ピクチャ１００のＷＰＰベースのエンコードに関連付けられたウェーブフロント毎のブロックの数（例えば、ＣＴＵ）を判定しうる。そして、整数倍のブロック数に達すると、ウェーブフロント移行を決定しうる。

さらに、ビデオ・エンコーダ２０は、ピクチャ１００のスライス・ヘッダを判定しうる（１８８）。さらに詳しくは、ビデオ・エンコーダ２０は、スライス移行、すなわち、ピクチャ１００の新たなスライスの開始を示すために、スライス・ヘッダを使用しうる。例えば、ビデオ・エンコーダ２０は、新たなスライスの開始に対応するピクチャ１００の特定の部位にスライス・ヘッダを挿入しうる。いくつかの例において、ビデオ・エンコーダ２０は、例えば、スライスの終了を示すために、ピクチャ１００の一部にエンド・オブ・スライス・シンボルを挿入することによって、エンド・オブ・スライス・シンボルに基づいて、スライス移行を示しうる。いくつかの例において、ビデオ・エンコーダ２０は、例えば、スライスの終了を示すためにエンド・オブ・スライス・シンボルを挿入することによって、および、新たなスライスの先頭を示すためにエンド・オブ・スライス・シンボルの直後にスライス・ヘッダを挿入することによって、スライス・ヘッダの直後のエンド・オブ・スライス・シンボルのシーケンスを用いてスライス移行を示しうる。

ビデオ・コーダは、現在のスライスが、ウェーブフロントの最初のＣＴＵの後に始まるか否かを判定しうる（１９０）。例えば、ビデオ・エンコーダ２０は、ブロック１１０において、スライス・ヘッダを検出または挿入すると、ウェーブフロント１５０の最初のＣＴＵの後に（例えば、ウェーブフロントの「中間」において）現在のスライスが始まることを判定しうる。この例では、ウェーブフロントの最初のＣＴＵの後に現在のスライスが始まるとビデオ・エンコーダ２０が判定する（１９０の「Ｙｅｓ」分岐）と、ビデオ・エンコーダ２０は、現在のスライスが、現在のウェーブフロント内で終了すると判定しうる（１９２）。例えば、ビデオ・エンコーダ２０は、ウェーブフロント１５２への移行を区別する前に、生成されたＮＡＬユニット内にエンド・オブ・スライス・シンボルを配置することによって、現在のスライスが、ウェーブフロント１５０内で終了すると判定しうる。記載されたスライス移行を判定することによって、ビデオ・エンコーダ２０は、ビデオ・エンコーダ２０（および／または、ビデオ・デコーダ３０）が、ウェーブフロント１５２のブロックをコーディングするために必要なすべての情報へのアクセスを有していることと、ブロックのスライス・ヘッダがすでにコーディングされていることと、を保証しうる。

一方、現在のスライスが、ウェーブフロントの最初のＣＴＵ後に始まらない、すなわち、スライス・ヘッダが、ウェーブフロントの最初のＣＴＵと一致しない、とビデオ・コーダが判定すると（１９０の「Ｎｏ」分岐）、ビデオ・コーダは、ピクチャ１００のスライス・ヘッダを判定し続けうる（１８８）。例えば、ビデオ・エンコーダ３０は、現在のスライスが、ウェーブフロントの先頭において始まるとの判定に基づいて、後続するスライス・ヘッダ（および／または、エンド・オブ・スライス・シンボル）をエンコードしうる。このように、ビデオ・エンコーダ２０は、ビデオ・エンコーダ２０およびビデオ・デコーダ３０が、ＷＰＰにしたがって現在のＣＴＵを効率的にコーディングするために必要なデータのすべて（既にコーディングされたスライス・ヘッダを含む）に対するアクセスを有するように、スライス・ウェーブフロント・インタラクションを制限するための処理１８０を実施しうる。

図６は、ビデオ・デコーダが、本開示の１または複数の技法を用いて、例えば、ビデオ・データのフレームのようなエンコードされたピクチャをデコードする別の例の処理２００を例示するフローチャートである。処理２００は、本開示の態様にしたがうさまざまなデバイスによって実行されうるが、説明の目的のために、処理２００は、本明細書では、図４のピクチャ１００と同様、図１および図３のデバイスおよびそれらの構成要素の観点で記載される。処理２００は、ビデオ・デコーダ３０が、ビデオ・データのエンコードされたピクチャを受け取った場合に始まりうる（２０２）。一例として、宛先デバイス１４は、入力インタフェース１２８において、ピクチャ１００のエンコードされたバージョンを受け取りうる。

さらに、ビデオ・デコーダ３０は、ウェーブフロント並列処理（ＷＰＰ）をイネーブルしうる（２０４）。いくつかの例において、コンピュータ読取可能な媒体１６は、ＷＰＰがイネーブルされるべきであることを示すシグナリング・データを含みうる。逆に、別の例では、ビデオ・デコーダ３０は、コンピュータ読取可能な媒体１６に含まれるビデオ・データが、特定の規格、および／または、規格の特定のプロファイルに準拠するか否かに基づいて、ＷＰＰをイネーブルするための暗黙的なインジケーションを決定しうる。例えば、宛先デバイス１４は、ビデオ・デコーダ３０に対して、ＷＰＰにしたがってピクチャ１００の、受け取られたエンコードされたバージョンをデコードさせることができるようにＷＰＰをイネーブルしうる。さらに、ビデオ・デコーダ３０は、エンコードされたピクチャ１００の新たなウェーブフロントの開始を決定しうる（２０６）。例えば、ビデオ・デコーダ３０は、エンコードされたピクチャ１００の最初のブロック（例えば、ＣＴＵ）が、新たなウェーブフロント１５０の先頭を示していると判定しうる。さらに、ビデオ・デコーダ３０は、ピクチャ１００のＷＰＰベースのエンコーディングに関連付けられたウェーブフロント毎のＣＴＵの数を判定しうる。そして、整数倍のＣＴＵ数に達すると、新たなウェーブフロントの開始（すなわち、「ウェーブフロント移行」）を判定しうる。

ビデオ・デコーダ３０は、ピクチャ１００のエンコードされたバージョンの現在のウェーブフロント（例えば、ウェーブフロント１５０）の現在のスライスのビデオ・データをデコードしうる（２０８）。さらに詳しくは、ビデオ・デコーダ３０は、最も左のＣＴＵにおいて始まって、ＣＴＵ毎ベースでウェーブフロント１５０をデコードし、その後、右側にある次のＣＴＵをデコードするという具合である。さらに、ビデオ・デコーダ３０は、ビデオ・デコーダ３０がウェーブフロント１５０の終了（例えば、最も右のＣＴＵ）に達する前にスライス・ヘッダを検出したか否かを判定しうる（２１０）。ビデオ・デコーダ３０は、エンコードされたピクチャ１００におけるスライス・ヘッダを検出することに基づいて、エンコードされたピクチャ１００の新たなスライスの開始、すなわち、「スライス移行」を判定しうる。ビデオ・デコーダ３０が、ウェーブフロント１５０の終了前にスライス・ヘッダを検出しない（２１０の「Ｎｏ」分岐）のであれば、ビデオ・デコーダ３０は、新たなウェーブフロント１５２の開始を検出しうる（２０６）。さらに詳しくは、このシナリオでは、ビデオ・デコーダ３０は、ウェーブフロント１５２のＣＴＵと同じスライスに属するウェーブフロント１５２の最初のＣＴＵを含む、ウェーブフロント１５２の少なくとも一部分を判定しうる。

逆に、ビデオ・デコーダ３０が、ウェーブフロント１５０の終了前にスライス・ヘッダを検出する（２１０の「Ｙｅｓ」分岐）と、ビデオ・デコーダ３０は、スライス・ヘッダが、ウェーブフロント１５０の最初のＣＴＵに一致するか否かを判定しうる（２１２）。言い換えれば、ビデオ・デコーダ３０は、現在のスライスが、現在のウェーブフロント１５０と同じＣＴＵにおいて始まるか否かを判定しうる。検出されたスライス・ヘッダが、ウェーブフロント１５０の最初のＣＴＵと一致するとビデオ・デコーダ３０が判定する（２１２の「Ｙｅｓ」分岐）と、ビデオ・デコーダ３０は、ウェーブフロント１５０の現在のスライスのビデオ・データをデコードし続けうる（２０８）。

一方、検出されたスライス・ヘッダが、ウェーブフロント１５０の最初のＣＴＵと一致しないとビデオ・デコーダ３０が判定する（２１２の「Ｎｏ］分岐）と、ビデオ・デコーダ３０は、現在のスライスがウェーブフロント１５０内で終了すると判定しうる（２１４）。さらに詳しくは、ビデオ・デコーダ３０は、本開示の技法によってイネーブルされるスライス・ウェーブフロント・インタラクション制約に基づいて、現在のスライスが、ウェーブフロント１５０内（例えば、ウェーブフロント１５０の最後／最も右のＣＴＵにおいてまたはその前において）終了すると判定しうる。さらに、ビデオ・デコーダは、現在のスライスがウェーブフロント１５０内で終了するとの判定に基づいて、ウェーブフロント１５０の現在のスライスのビデオ・データをデコードし続けうる。

図６に例示された方式でスライス・ウェーブフロント・インタラクションを制限することによって、ビデオ・デコーダ３０は、例えばウェーブフロント１５２のようなウェーブフロント内に位置するスライスのＣＴＵをデコードしている間、ウェーブフロント１５２のデコード処理のために必要なすべてのデータへのウェーブフロント１５０からのアクセスを有することを保証しうる。すなわち、ビデオ・デコーダ３０は、ウェーブフロント１５０のデコード中、ウェーブフロント１５２内のスライスのスライス・ヘッダ・データを既にデコードしているか、ウェーブフロント１５２内のスライスのスライス・ヘッダが、ウェーブフロント１５２の最初において生じるであろう。したがって、ビデオ・デコーダ３０は、ＷＰＰにしたがって、必要なすべてのデコードにクリティカルなデータへのアクセスを有することに基づいて、ウェーブフロント１５２のデコードを開始しうる。

本明細書に記載された技法の何れかのいくつかの動作またはイベントは、例に依存して異なるシーケンスで実行されうるか、追加されうるか、マージされうるか、ともに除外されうる（例えば、記載されたすべての動作またはイベントが、必ずしも本技法の実施のために必要とされる訳ではない）ことが認識されるべきである。さらに、いくつかの例では、これら動作またはイベントは、個別にではなく、例えば、マルチ・スレッド処理、中断処理、または複数のプロセッサによって同時に実行されうる。

１または複数の例において、記述された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせで実現されうる。ソフトウェアで実現されるのであれば、これら機能は、コンピュータ読取可能な媒体におけるコードまたは１または複数の命令群で送信されるか格納され、ハードウェア・ベースの処理ユニットによって実行されうる。コンピュータ読取可能な媒体は、コンピュータ読取可能な記憶媒体を含みうる。これは、例えばデータ記憶媒体のような有形な媒体、または、例えば通信プロトコルにしたがって、１つの場所から別の場所へのコンピュータ・プログラムの転送を容易にする任意の媒体を含む通信媒体に相当しうる。このように、コンピュータ読取可能な媒体は、一般に、（１）非一時的である有形のコンピュータ読取可能な記憶媒体、または、（２）例えば信号または搬送波のような通信媒体に対応しうる。データ記憶媒体は、本開示において記述された技術を実施するための命令群、コード、および／または、データ構造を検索するために１または複数のコンピュータまたは１または複数のプロセッサによってアクセスされうる任意の利用可能な媒体でありうる。コンピュータ・プログラム製品は、コンピュータ読取可能な媒体を含みうる。

例として、限定することなく、このようなコンピュータ読取可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、フラッシュ・デバイス、あるいは、所望のプログラム・コード手段を命令群またはデータ構造の形式で搬送または格納するために使用され、しかも、コンピュータによってアクセスされうるその他任意の媒体を備えうる。さらに、いかなる接続も、コンピュータ読取可能な媒体として適切に称される。同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、デジタル加入者線（ＤＳＬ）、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術を使用して、ウェブサイト、サーバ、あるいはその他の遠隔ソースから命令群が送信される場合、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、ＤＳＬ、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術が、媒体の定義に含まれる。しかしながら、コンピュータ読取可能な記憶媒体およびデータ記憶媒体は、コネクション、搬送波、信号、またはその他の一時的な媒体を含まず、代わりに、非一時的な、有形の記憶媒体に向けられていることが理解されるべきである。本明細書で使用されるディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクト・ディスク（ｄｉｓｃ）（ＣＤ）、レーザ・ディスク（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、およびブルーレイ・ディスク（ｄｉｓｃ）を含む。これらｄｉｓｃは、レーザを用いてデータを光学的に再生する。それに対して、ｄｉｓｋは、通常、データを磁気的に再生する。前述した組み合わせもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。

命令群は、例えば１または複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ロジック・アレイ（ＦＰＧＡ）、またはその他等価な集積またはディスクリート論理回路のような１または複数のプロセッサによって実行されうる。したがって、本明細書で使用されているように、用語「プロセッサ」は、前述した構成、または、本明細書に記載された技術の実施のために適切なその他任意の構成のうちの何れかを称しうる。さらに、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェア・モジュール内に適用されうるか、または、結合されたコーデック内に組み込まれうる。さらに、これら技法は、１または複数の回路または論理要素で完全に実現されうる。

本開示の技術は、無線ハンドセット、集積回路（ＩＣ）、またはＩＣのセット（例えば、チップセット）を含む種々さまざまなデバイスまたは装置において実現されうる。さまざまな構成要素、モジュール、またはユニットは、本開示では、開示された技術を実行するように構成されたデバイスの機能態様を強調するように記載されているが、異なるハードウェア・ユニットによる実現を必ずしも必要とする訳ではない。むしろ、前述されたように、さまざまなユニットは、適切なソフトウェアおよび／またはハードウェアと連携する、前述されたような１または複数のプロセッサを含む共通のハードウェア・ユニットの集合によって提供されうるか、コーデック・ハードウェア・ユニットに結合されうる。

さまざまな例が記載された。これらの例およびその他の例は、以下の特許請求の範囲のスコープ内である。
以下に、出願時の特許請求の範囲に記載された発明を付記する。
［発明１］
ビデオ・データをコーディングする方法であって、
ビデオ・データのピクチャのスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、前記行の先頭以外の位置において始まることを判定することと、
前記判定に基づいて、前記スライスが前記ＣＴＵの行内で終了すると判定することと、
前記スライスが前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをコーディングすることと、
を備える方法。
［発明２］
ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了するように、前記ビデオ・データのすべてのピクチャのすべてのスライスをコーディングすること、をさらに備える発明１に記載の方法。
［発明３］
前記スライスをコーディングすることは、ウェーブフロント並列処理を用いて前記スライスをコーディングすることを備える、発明１に記載の方法。
［発明４］
前記ウェーブフロント並列処理を用いて前記スライスをコーディングすることはさらに、前記ウェーブフロント並列処理がイネーブルされていることを判定することを備える、発明３に記載の方法。
［発明５］
ウェーブフロント並列処理をイネーブルすること、をさらに備える発明３に記載の方法。
［発明６］
ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをコーディングすること、をさらに備える発明５に記載の方法。
［発明７］
前記スライスをコーディングすることは、ウェーブフロント並列処理を用いて、前記スライスを含むピクチャの少なくとも一部をコーディングすることを備える、発明３に記載の方法。
［発明８］
前記ＣＴＵの行の終わりにおいて、または、前記ＣＴＵの行の終わりの前において、前記スライスが終了していることを判定すること、をさらに備える発明１に記載の方法。
［発明９］
前記スライスをコーディングすることは、前記スライスの終わりに達する前に、前記ピクチャ内のＣＴＵの後続する行に進むことなく、ラスタ・スキャン順に前記スライスのＣＴＵをコーディングすることを備える、発明１に記載の方法。
［発明１０］
前記ＣＴＵの行は、ＣＴＵの最初の行を備え、
前記方法はさらに、前記ＣＴＵの最初の行をコーディングすることと実質的に並列的に、前記ＣＴＵの最初の行に隣接するＣＴＵの行をコーディングすることを備える、発明１に記載の方法。
［発明１１］
前記隣接するＣＴＵの行は、前記ＣＴＵの最初の行の下に位置するＣＴＵの２番目の行を備える、発明１０に記載の方法。
［発明１２］
前記隣接するＣＴＵの行は、前記ＣＴＵの最初の行の上に位置するＣＴＵの２番目の行を備える、発明１０に記載の方法。
［発明１３］
前記スライスをコーディングすることは、前記スライスが、前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをエントロピ・デコードすることを備える、発明１に記載の方法。
［発明１４］
前記スライスをコーディングすることは、前記スライスが、前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをエントロピ・エンコードすることを備える、発明１に記載の方法。
［発明１５］
ビデオ・データをコーディングするためのデバイスであって、
ビデオ・データのピクチャのスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、前記行の先頭以外の位置において始まることを判定することと、
前記判定に基づいて、前記スライスが前記ＣＴＵの行内で終了すると判定することと、
前記スライスが前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをコーディングすることと、
を実行するように構成されたビデオ・コーダ、を備えるデバイス。
［発明１６］
前記ビデオ・コーダを備える通信デバイスと、マイクロプロセッサと、集積回路とのうちの少なくとも１つを備える、発明１５に記載のデバイス。
［発明１７］
前記ビデオ・コーダはさらに、ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了するように、前記ビデオ・データのすべてのピクチャのすべてのスライスをコーディングするように構成された、発明１５に記載のデバイス。
［発明１８］
前記ビデオ・コーダは、ウェーブフロント並列処理を用いて前記スライスをコーディングするように構成された、発明１５に記載のデバイス。
［発明１９］
前記ビデオ・コーダは、少なくとも部分的に、前記ウェーブフロント並列処理が前記デバイスによってイネーブルされたと判定することによって、ウェーブフロント並列処理を用いて前記スライスをコーディングするように構成された、発明１８に記載のデバイス。
［発明２０］
前記ビデオ・コーダはさらに、前記デバイスにおいてウェーブフロント並列処理をイネーブルするように構成された、発明１８に記載のデバイス。
［発明２１］
前記ビデオ・コーダはさらに、前記ＣＴＵの行の終わりにおいて、または、前記ＣＴＵの行の終わりの前において、前記スライスが終了していることを判定するように構成された、発明１５に記載のデバイス。
［発明２２］
前記ビデオ・コーダは、少なくとも部分的に、前記スライスの終わりに達する前に、前記ピクチャ内のＣＴＵの後続する行に進むことなく、ラスタ・スキャン順に前記スライスのＣＴＵをコーディングすることによって、前記スライスをコーディングするように構成された、発明１５に記載のデバイス。
［発明２３］
前記ＣＴＵの行は、前記ＣＴＵの最初の行を備え、
前記ビデオ・コーダはさらに、前記ＣＴＵの最初の行をコーディングすることと実質的に並列的に、最初のスライスに隣接するＣＴＵの行をコーディングするように構成された、発明１５に記載のデバイス。
［発明２４］
前記隣接するＣＴＵの行は、前記ＣＴＵの最初の行の下に位置するＣＴＵの２番目の行を備える、発明２３に記載のデバイス。
［発明２５］
前記隣接するＣＴＵの行は、前記ＣＴＵの最初の行の上に位置するＣＴＵの２番目の行を備える、発明２３に記載のデバイス。
［発明２６］
前記ビデオ・コーダは、前記スライスが、前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをエントロピ・デコードするように構成されたビデオ・デコーダを備える、発明１５に記載のデバイス。
［発明２７］
前記ビデオ・コーダは、前記スライスが、前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをエントロピ・エンコードするように構成されたビデオ・エンコーダを備える、発明１５に記載のデバイス。
［発明２８］
ビデオ・データをコーディングするためのデバイスであって、
ビデオ・データのピクチャのスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、前記行の先頭以外の位置において始まることを判定する手段と、
前記判定に基づいて、前記スライスが前記ＣＴＵの行内で終了すると判定する手段と、
前記スライスが前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをコーディングする手段と、
を備えるデバイス。
［発明２９］
ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了するように、前記ビデオ・データのすべてのピクチャのすべてのスライスをコーディングする手段、をさらに備える発明２８に記載のデバイス。
［発明３０］
前記スライスをコーディングする手段は、ウェーブフロント並列処理を用いて前記スライスをコーディングする手段を備える、発明２８に記載のデバイス。
［発明３１］
前記スライスをコーディングする手段は、前記スライスの終わりに達する前に、前記ピクチャ内のＣＴＵの後続する行に進むことなく、ラスタ・スキャン順に前記スライスのＣＴＵをコーディングする手段を備える、発明２８に記載のデバイス。
［発明３２］
前記スライスは、最初のスライスを備え、
前記デバイスはさらに、前記ＣＴＵの最初の行をコーディングすることと実質的に並列的に、前記ＣＴＵの最初の行に隣接するＣＴＵの行をコーディングする手段を備える、発明２８に記載のデバイス。
［発明３３］
格納された命令群を有するコンピュータ読取可能な記憶媒体であって、
前記命令群は、実行された場合、コンピューティング・デバイスのプログラマブル・プロセッサに対して、
ビデオ・データのピクチャのスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行において、前記行の先頭以外の位置において始まることを判定することと、
前記判定に基づいて、前記スライスが前記ＣＴＵの行内で終了すると判定することと、
前記スライスが前記ＣＴＵの行内で終了するとの判定に基づいて、前記スライスをコーディングすることと
を実行させる、コンピュータ読取可能な記憶媒体。
［発明３４］
前記命令群は、実行された場合、コンピューティング・デバイスのプログラマブル・プロセッサに対して、
ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了するように、前記ビデオ・データのすべてのピクチャのすべてのスライスをコーディングすることを実行させる、発明３３に記載のコンピュータ読取可能な記憶媒体。
［発明３５］
前記命令群は、実行された場合、コンピューティング・デバイスのプログラマブル・プロセッサに対して、ウェーブフロント並列処理を用いて前記スライスをコーディングすることを実行させる、発明３３に記載のコンピュータ読取可能な記憶媒体。
［発明３６］
前記命令群は、実行された場合、コンピューティング・デバイスのプログラマブル・プロセッサに対して、少なくとも部分的に、前記スライスの終わりに達する前に、前記ピクチャ内のＣＴＵの後続する行に進むことなく、ラスタ・スキャン順に前記スライスのＣＴＵをコーディングすることによって、前記スライスをコーディングすることを実行させる、発明３３に記載のコンピュータ読取可能な記憶媒体。
［発明３７］
前記ＣＴＵの行は、前記ＣＴＵの最初の行であり、
前記命令群は、実行された場合、コンピューティング・デバイスのプログラマブル・プロセッサに対して、前記ＣＴＵの最初の行をコーディングすることと実質的に並列的に、前記ＣＴＵの最初の行に隣接するＣＴＵの行をコーディングすることを実行させる、発明３３に記載のコンピュータ読取可能な記憶媒体。

Claims (37)

1. エンコードされたビデオビットストリームのビデオ・データをデコードするための方法において、
   ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをデコードすることと、
   前記ウェーブフロント並列処理がイネーブルされていることを示す前記シンタックス・データに応答して、前記ビデオ・データのピクチャの現在のスライスのスライス・ヘッダに基づいて、前記ビデオ・データのピクチャの現在のスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行中の、前記行の先頭以外の位置において始まることを決定することと、
   前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に基づいて、前記現在のスライスが前記ＣＴＵの行内で終了することを決定することと、
   前記現在のスライスが前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスに後続するスライスのスライス・ヘッダに依存することなく、前記現在のスライスをデコードすることとを含み、
   前記行は前記ピクチャの幅に渡り、前記行の先頭は、前記ピクチャの左端に対応し、前記行の終わりは、前記ピクチャの右端に対応する方法。
2. 前記ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了する請求項１記載の方法。
3. 前記ウェーブフロント並列処理を使用して、前記現在のスライスをデコードすることをさらに含む請求項１記載の方法。
4. 前記現在のスライスをデコードすることは、ウェーブフロント並列処理を使用して、前記現在のスライスを含むピクチャの少なくとも一部をデコードすることを含む請求項３記載の方法。
5. 前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に応答して、前記ＣＴＵの行の終わりにおいて、または、前記ＣＴＵの行の終わりの前において、前記現在のスライスが終了することを決定することをさらに含む請求項１記載の方法。
6. 後続するスライスから前記現在のスライスを区別するスライス分割シンタックス要素に達する前に、前記ピクチャ中の前記ＣＴＵの後続する行を横切ることなく、ラスタ・スキャン順に前記現在のスライスの前記ＣＴＵをデコードすることをさらに含む請求項１記載の方法。
7. 前記ＣＴＵの行は、前記ＣＴＵの第１の行を備え、
   前記方法は、前記ＣＴＵの前記第１の行をコーディングすることと実質的に並列的に、前記ＣＴＵの前記第１の行に隣接する前記ＣＴＵの行をデコードすることをさらに含む請求項１記載の方法。
8. 前記ＣＴＵの隣接する行は、前記ＣＴＵの前記第１の行の下に位置する前記ＣＴＵの第２の行を備える請求項７記載の方法。
9. 前記ＣＴＵの隣接する行は、前記ＣＴＵの前記第１の行の上に位置する前記ＣＴＵの第２の行を備える請求項７記載の方法。
10. 前記エンコードされたビデオビットストリームを受け取ることをさらに含み、前記現在のスライスをデコードすることは、前記現在のスライスが前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスをエントロピ・デコードすることを含む請求項１記載の方法。
11. 前記行は、第１の行を備え、
    前記方法は、前記現在のスライスが前記ＣＴＵの前記第１の行内で終了するとの決定に基づいて、第２のスライスのスライス・ヘッダを使用して、後続するスライスに対して、１つ以上のコンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）確率を初期化することをさらに含み、
    前記後続するスライスは、前記第１の行の直下に位置する第２の行の先頭において始まる請求項１記載の方法。
12. 前記行は、第１の行を備え、
    前記方法は、
    後続するスライスが、前記第１の行の直下に位置する第２の行の先頭において始まることを決定することと、
    前記後続するスライスが、前記第２の行の先頭において始まるとの決定に基づいて、
    前記第２の行の直下に位置する第３の行のデータが、前記後続するスライスの一部分、または、前記後続するスライスの後に始まるスライスの一部分を形成するか否かを決定することと、
    前記第３の行のデータが、前記後続するスライスの一部分を形成するとの決定に基づいて、前記後続するスライスからの１つ以上のＣＡＢＡＣパラメータを使用して、前記第３の行のデータをコーディングすること、または、
    前記第３の行のデータが、前記後続するスライスの後に始まるスライスの一部分を形成するとの決定に基づいて、前記後続するスライスの後に始まるスライスのスライス・ヘッダから初期化された１つ以上のＣＡＢＡＣパラメータを使用して、前記第３の行のデータをコーディングすること、のうちの１つを実行することとをさらに含む請求項１記載の方法。
13. 前記スライス分割シンタックス要素は、
    （ｉ）前記現在のスライスの終了を示す１つ以上のエンド・オブ・スライス・シンボル、または、
    （ｉｉ）後続するスライスの始まりを示すスライス・ヘッダシンタックス要素、のうちの少なくとも１つを含む請求項６記載の方法。
14. エンコードされたビデオビットストリームのビデオ・データをデコードするデバイスにおいて、
    前記ビデオ・データの少なくとも一部分を記憶するように構成されているメモリと、
    １つ以上のプロセッサとを具備し、
    前記１つ以上のプロセッサは、
    ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをデコードするようにと、
    前記ウェーブフロント並列処理がイネーブルされていることを示す前記シンタックス・データに応答して、前記ビデオ・データのピクチャの現在のスライスのスライス・ヘッダに基づいて、前記ビデオ・データのピクチャの現在のスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行中の、前記行の先頭以外の位置において始まることを決定するようにと、
    前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に基づいて、前記現在のスライスが前記ＣＴＵの行内で終了することを決定するようにと、
    前記現在のスライスが前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスに後続するスライスのスライス・ヘッダに依存することなく、前記現在のスライスをデコードするように構成され、
    前記行は前記ピクチャの幅に渡り、前記行の先頭は、前記ピクチャの左端に対応し、前記行の終わりは、前記ピクチャの右端に対応するデバイス。
15. １つ以上の集積回路と、
    １つ以上のマイクロプロセッサと、
    １つ以上のデジタル信号プロセッサ（ＤＳＰ）と、
    １つ以上のフィールドプログラマブルゲートアレイ（ＦＧＰＡ）と、
    デスクトップコンピュータと、
    ラップトップコンピュータと、
    タブレットコンピュータと、
    電話機と、
    テレビと、
    カメラと、
    ディスプレイデバイスと、
    デジタルメディアプレーヤーと、
    ビデオゲームコンソールと、
    ビデオゲームデバイスと、
    ビデオストリーミングデバイスと、または、
    ワイヤレス通信デバイスと、
    のうちの少なくとも１つをさらに具備する請求項１４記載のデバイス。
16. 前記ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了する請求項１４記載のデバイス。
17. 前記１つ以上のプロセッサは、前記ウェーブフロント並列処理を使用して、前記現在のスライスをデコードするようにさらに構成されている請求項１４記載のデバイス。
18. 前記ウェーブフロント並列処理を使用して、前記現在のスライスをデコードするために、前記１つ以上のプロセッサは、前記ウェーブフロント並列処理が前記デバイス上でイネーブルされていることを決定するように構成されている請求項１７記載のデバイス。
19. 前記１つ以上のプロセッサは、前記デバイス上で前記ウェーブフロント並列処理をイネーブルするようにさらに構成されている請求項１７記載のデバイス。
20. 前記１つ以上のプロセッサは、前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に応答して、前記ＣＴＵの行の終わりにおいて、または、前記ＣＴＵの行の終わりの前において、前記現在のスライスが終了することを決定するようにさらに構成されている請求項１４記載のデバイス。
21. 前記１つ以上のプロセッサは、後続するスライスから前記現在のスライスを区別するスライス分割シンタックス要素に達する前に、前記ピクチャ中の前記ＣＴＵの後続する行を横切ることなく、ラスタ・スキャン順に前記現在のスライスの前記ＣＴＵをデコードするようにさらに構成されている請求項１４記載のデバイス。
22. 前記ＣＴＵの行は、前記ＣＴＵの第１の行を備え、
    前記１つ以上のプロセッサは、前記ＣＴＵの前記第１の行をデコードすることと実質的に並列的に、前記ＣＴＵの前記第１の行に隣接する前記ＣＴＵの行をデコードするようにさらに構成されている請求項１４記載のデバイス。
23. 前記ＣＴＵの隣接する行は、前記ＣＴＵの前記第１の行の下に位置する前記ＣＴＵの第２の行を備える請求項２２記載のデバイス。
24. 前記ＣＴＵの隣接する行は、前記ＣＴＵの前記第１の行の上に位置する前記ＣＴＵの第２の行を備える請求項２２記載のデバイス。
25. 前記現在のスライスをデコードするために、前記１つ以上のプロセッサは、前記現在のスライスが、前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスをエントロピ・デコードするように構成されている請求項１４記載のデバイス。
26. スライス分割シンタックス要素は、
    （ｉ）前記現在のスライスの終了を示す１つ以上のエンド・オブ・スライス・シンボル、または、
    （ｉｉ）後続するスライスの始まりを示すスライス・ヘッダシンタックス要素、のうちの少なくとも１つを含む請求項２１記載のデバイス。
27. エンコードされたビデオビットストリームのビデオ・データをデコードするデバイスにおいて、
    ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをデコードする手段と、
    前記ウェーブフロント並列処理がイネーブルされていることを示す前記シンタックス・データに応答して、前記ビデオ・データのピクチャの現在のスライスのスライス・ヘッダに基づいて、前記ビデオ・データのピクチャの現在のスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行中の、前記行の先頭以外の位置において始まることを決定する手段と、
    前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に基づいて、前記現在のスライスが前記ＣＴＵの行内で終了することを決定する手段と、
    前記現在のスライスが前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスに後続するスライスのスライス・ヘッダに依存することなく、前記現在のスライスをデコードする手段とを具備し、
    前記行は前記ピクチャの幅に渡り、前記行の先頭は、前記ピクチャの左端に対応し、前記行の終わりは、前記ピクチャの右端に対応するデバイス。
28. 前記ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了する請求項２７記載のデバイス。
29. 前記ウェーブフロント並列処理を使用して、前記現在のスライスをデコードする手段をさらに具備する請求項２７記載のデバイス。
30. 後続するスライスから前記現在のスライスを区別するスライス分割シンタックス要素に達する前に、前記ピクチャ中の前記ＣＴＵの後続する行を横切ることなく、ラスタ・スキャン順に前記現在のスライスの前記ＣＴＵをデコードする手段をさらに具備する請求項２７記載のデバイス。
31. 前記ＣＴＵの行は、前記ＣＴＵの第１の行を備え、
    前記デバイスは、前記ＣＴＵの前記第１の行をデコードすることと実質的に並列的に、前記ＣＴＵの前記第１の行に隣接する前記ＣＴＵの行をデコードする手段をさらに具備する請求項２７記載のデバイス。
32. 格納された命令群を有する非一時的コンピュータ読取可能な記憶媒体において、
    前記命令群は、実行されるとき、コンピューティング・デバイスのプログラマブル・プロセッサに、
    エンコードされたビデオビットストリームのビデオ・データを処理させ、
    ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをデコードさせ、
    前記ウェーブフロント並列処理がイネーブルされていることを示す前記シンタックス・データに応答して、前記ビデオ・データのピクチャの現在のスライスのスライス・ヘッダに基づいて、前記ビデオ・データのピクチャの現在のスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行中の、前記行の先頭以外の位置において始まることを決定させ、
    前記現在のスライスが前記行の先頭以外の位置において始まるとの決定に基づいて、前記現在のスライスが前記ＣＴＵの行内で終了することを決定させ、
    前記現在のスライスが前記ＣＴＵの行内で終了するとの決定に基づいて、前記現在のスライスに後続するスライスのスライス・ヘッダに依存することなく、前記現在のスライスをデコードさせ、
    前記行は前記ピクチャの幅に渡り、前記行の先頭は、前記ピクチャの左端に対応し、前記行の終わりは、前記ピクチャの右端に対応する非一時的コンピュータ読取可能な記憶媒体。
33. 前記ＣＴＵの対応する行の先頭以外の位置において始まるスライスのすべてが、前記ＣＴＵの対応する行内で終了する請求項３２記載の非一時的コンピュータ読取可能な記憶媒体。
34. 前記命令群は、実行されるとき、前記コンピューティング・デバイスのプログラマブル・プロセッサにさらに、前記ウェーブフロント並列処理を使用させて、前記現在のスライスをデコードさせる請求項３２記載の非一時的コンピュータ読取可能な記憶媒体。
35. 前記命令群は、実行されるとき、前記コンピューティング・デバイスのプログラマブル・プロセッサにさらに、少なくとも部分的に、後続するスライスから前記現在のスライスを区別するスライス分割シンタックス要素に達する前に、前記ピクチャ中の前記ＣＴＵの後続する行を横切ることなく、ラスタ・スキャン順に前記スライスの前記ＣＴＵをコーディングさせることによって、前記現在のスライスをデコードさせる請求項３２記載の非一時的コンピュータ読取可能な記憶媒体。
36. 前記ＣＴＵの行は、前記ＣＴＵの第１の行を備え、
    前記命令群は、実行されるとき、前記コンピューティング・デバイスのプログラマブル・プロセッサにさらに、前記ＣＴＵの前記第１の行をデコードさせることと実質的に並列的に、前記ＣＴＵの前記第１の行に隣接する前記ＣＴＵの行をデコードさせる請求項３２記載の非一時的コンピュータ読取可能な記憶媒体。
37. ビデオ・データをエンコードするための方法において、
    ウェーブフロント並列処理がイネーブルされていることに応答して、前記ビデオ・データのピクチャの現在のスライスが、前記ピクチャにおけるコーディング・ツリー・ユニット（ＣＴＵ）の行中の、前記行の先頭以外の位置において始まり、後続する行への境界を横切ることを決定することと、
    前記現在のスライスが前記行の先頭以外の位置において始まり、前記後続する行への境界を横切るとの決定に基づいて、前記現在のスライスが前記ＣＴＵの行内で終了するように設定することと、
    前記スライスが前記ＣＴＵの行内で終了するとの設定に基づいて、前記スライスをエンコードすることと、
    前記ウェーブフロント並列処理がイネーブルされていることを示すシンタックス・データをエンコードすることを含み、
    前記行は前記ピクチャの幅に渡り、前記行の先頭は、前記ピクチャの左端に対応し、前記行の終わりは、前記ピクチャの右端に対応する方法。

Images