JP2015516768A - 変換係数コーディング - Google Patents

Abstract

ブロックの変換係数のための走査順序を判断するための技法について説明される。本技法は、判断された走査順序に基づいて変換係数のための有意性シンタックス要素を符号化または復号するためのコンテキストを判断し得る。ビデオエンコーダは有意性シンタックス要素を符号化し得、ビデオデコーダは、判断されたコンテキストに基づいて有意性シンタックス要素を復号し得る。

Description

関連出願
[0001] 本出願は、その各々の内容全体が参照により本明細書に組み込まれる、２０１２年４月１６日に出願された米国仮出願第６１／６２５，０３９号、および２０１２年７月２日に出願された米国仮出願第６１／６６７，３８２号の利益を主張する。

[0002] 本開示は、ビデオコーディングに関し、より詳細には、ビデオコーディングにおいて使用される、変換係数（transform coefficient）に関連するシンタックス要素をコーディングするための技法に関する。

[0003] デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ビデオコーディング規格に従って定義されるビデオ圧縮技法を実装する。デジタルビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６３と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌと、それのスケーラブルビデオコーディング（ＳＶＣ：Scalable Video Coding）およびマルチビュービデオコーディング（ＭＶＣ：Multiview Video Coding）拡張を含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４とを含む。さらに、高効率ビデオコーディング（ＨＥＶＣ：High-Efficiency Video Coding）は、ＩＴＵ−Ｔビデオコーディングエキスパーツグループ（ＶＣＥＧ： Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパーツグループ（ＭＰＥＧ）とのビデオコーディング共同研究部会（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding：Motion Picture Experts Group）によって開発されているビデオコーディング規格である。

[0004] ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を実行する。ブロックベースのビデオコーディングでは、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部）はビデオブロックに区分され得、これらのビデオブロックは、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることがある。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック内の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

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

[0006] 概して、本開示は、ブロックの変換係数に関連するシンタックス要素（たとえば、有意性フラグ（significance flag））を表すデータを符号化および復号するための技法について説明する。いくつかの技法では、ビデオエンコーダおよびビデオデコーダがそれぞれ、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context adaptive binary arithmetic coding）のために使用されるべきコンテキストを判断する。より詳細に説明するように、ビデオエンコーダおよびビデオデコーダは、ブロックのための走査順序（scan order）を判断し、走査順序に基づいてコンテキストを判断する。いくつかの例では、ビデオデコーダは、２つ以上の走査順序について同じであるコンテキストを判断し、他の走査順序について異なるコンテキストを判断する。同様に、これらの例では、ビデオエンコーダは、２つ以上の走査順序について同じであるコンテキストを判断し、他の走査順序について異なるコンテキストを判断する。

[0007] 一例では、本開示は、ビデオデータを復号するための方法について説明する。コード化ビットストリームから、ブロックの変換係数の有意性フラグを受信することと、ブロックの変換係数のための走査順序を判断することと、判断された走査順序に基づいてブロックの変換係数の有意性フラグのためのコンテキストを判断することと、少なくとも判断されたコンテキストに基づいて変換係数の有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）復号することとを備える方法。

[0008] 別の例では、本開示は、ビデオデータを符号化するための方法について説明する。ブロックの変換係数のための走査順序を判断することと、判断された走査順序に基づいてブロックの変換係数の有意性フラグのためのコンテキストを判断することと、少なくとも判断されたコンテキストに基づいて変換係数の有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）符号化することと、コード化ビットストリーム中で符号化された有意性フラグをシグナリングすることとを備える方法。

[0009] 別の例では、本開示は、ビデオデータをコーディングするための装置について説明する。その装置は、ブロックの変換係数のための走査順序を判断することと、判断された走査順序に基づいてブロックの変換係数の有意性フラグのためのコンテキストを判断することと、少なくとも判断されたコンテキストに基づいて変換係数の有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）コーディングすることとを行うように構成されたビデオコーダを備える。

[0010] 別の例では、本開示は、ビデオデータをコーディングするための装置について説明する。その装置は、ブロックの変換係数のための走査順序を判断するための手段と、判断された走査順序に基づいてブロックの変換係数の有意性フラグのためのコンテキストを判断するための手段と、少なくとも判断されたコンテキストに基づいて変換係数の有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）するための手段とを備える。

[0011] 別の例では、本開示は、コンピュータ可読記憶媒体について説明する。実行されたとき、ビデオデータをコーディングするための装置の１つまたは複数のプロセッサに、ブロックの変換係数のための走査順序を判断することと、判断された走査順序に基づいてブロックの変換係数の有意性フラグのためのコンテキストを判断することと、少なくとも判断されたコンテキストに基づいて変換係数の有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）コーディングすることとを行わせるその上に記憶された命令を有するコンピュータ可読記憶媒体。

[0012] １つまたは複数の例の詳細を添付の図面および以下の説明に記載する。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。

[0013] 変換係数を含むブロックの走査順序の例を示す概念図。 変換係数を含むブロックの走査順序の例を示す概念図。 変換係数を含むブロックの走査順序の例を示す概念図。 [0014] 有意性シンタックス要素（significance syntax element）への変換係数のマッピングを示す概念図。 [0015] 本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0016] 本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図。 [0017] 本開示による、シンタックス要素をエントロピー符号化するための技法を実装し得るエントロピーエンコーダの一例を示すブロック図。 [0018] 本開示による、ビデオデータを符号化するための例示的なプロセスを示すフローチャート。 [0019] 本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図。 [0020] 本開示による、シンタックス要素を復号するための技法を実装し得るエントロピーデコーダの一例を示すブロック図。 [0021] 本開示による、ビデオデータを復号する例示的なプロセスを示すフローチャート。 [0022] 走査順序に応じて最後有意係数（last significant coefficient）の位置を示す概念図。 [0023] 元の水平走査の代わりに対角走査の使用を示す概念図。 [0024] 公称水平走査のためのコンテキスト近傍（context neighborhood）を示す概念図。

[0025] ビデオエンコーダは、ブロックのための変換係数を判断し、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）を使用して、変換係数の値を示すシンタックス要素を符号化し、ビットストリーム中で符号化されたシンタックス要素をシグナリングする。ビデオデコーダは、変換係数の値を示す符号化シンタックス要素を含むビットストリームを受信し、ブロックのための変換係数を判断するためにシンタックス要素をＣＡＢＡＣ復号する。

[0026] ビデオエンコーダおよびビデオデコーダは、それぞれ、ＣＡＢＡＣ符号化およびＣＡＢＡＣ復号を実行するために、どのコンテキストが使用されるべきかを判断する。本開示で説明する技法では、ビデオエンコーダおよびビデオデコーダは、変換係数のブロックの走査順序に基づいてＣＡＢＡＣ符号化またはＣＡＢＡＣ復号を実行するためにどのコンテキストを使用すべきかを判断し得る。いくつかの例では、ビデオエンコーダおよびビデオデコーダは、ブロックのサイズと、ブロック内の変換係数の位置と、走査順序とに基づいて、ＣＡＢＡＣ符号化またはＣＡＢＡＣ復号を実行するためにどのコンテキストを使用すべきかを判断し得る。

[0027] いくつかの例では、ビデオエンコーダおよびビデオデコーダは走査順序によって異なるコンテキスト（すなわち、水平走査のためのコンテキストの第１のセットと、垂直走査のためのコンテキストの第２のセットと、対角走査のためのコンテキストの第３のセットと）を利用し得る。別の例として、変換係数のブロックが垂直方向または水平方向に走査される場合、ビデオエンコーダおよびビデオデコーダは、これらの走査順序の両方について（たとえば、変換係数の特定の位置について）同じコンテキストを利用し得る。

[0028] ＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のためにどのコンテキストを使用すべきかを判断することによって、本開示で説明する技法は、他の技法と比較して、より良いビデオ圧縮を達成するように変換係数の大きさの統計的挙動を活用し得る。たとえば、ビデオエンコーダおよびビデオデコーダが、走査順序にかかわらず、変換係数の位置に基づいて、ＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のためにどのコンテキストを使用すべきかを判断することは可能であり得る。しかしながら、走査順序は変換係数の順序付けに影響を及ぼし得る。

[0029] たとえば、変換係数のブロックは、１次元（１Ｄ）ベクトルを構成するためにビデオエンコーダが走査する係数の２次元（２Ｄ）ブロックであり得、ビデオエンコーダは、１Ｄベクトル中に変換係数の値を（ＣＡＢＡＣを使用して）エントロピー符号化する。ビデオエンコーダが１Ｄベクトル中に変換係数の値（たとえば、大きさ）を配置する順序は走査順序によって決まる。ビデオエンコーダが対角走査のために変換係数の大きさを配置する順序は、ビデオエンコーダが垂直走査のために変換係数の大きさを配置する順序とは異なり得る。

[0030] 言い換えれば、変換係数の大きさの位置は走査順序によって異なり得る。変換係数の大きさの位置はコーディング効率に影響を及ぼし得る。たとえば、ブロック中の最後有意係数のロケーションは走査順序によって異なり得る。この場合、最後有意係数の大きさは走査順序によって異なり得る。

[0031] したがって、走査順序にかかわらず変換係数の位置に基づいてコンテキストを判断するこれらの他の技法は、特定の位置における変換係数についての有意性統計（significance statistics）が走査順序に応じて変動し得る可能性を適切に考慮することができない。本開示で説明する技法では、ビデオエンコーダおよびビデオデコーダは、ブロックのための走査順序を判断し、判断された走査順序に基づいて（また、いくつかの例では、変換係数の位置、および場合によってはブロックのサイズに基づいて）コンテキストを判断し得る。このようにして、ビデオエンコーダおよびビデオデコーダは、走査順序に依拠せず、どのコンテキストを使用すべきかを判断するための位置のみに依拠する技法と比較して、どのコンテキストを使用すべきかを判断するための有意性統計をより良く考慮し得る。

[0032] ビデオコーディングのいくつかの例では、ビデオエンコーダおよびビデオデコーダは、ブロックの変換係数を符号化または復号するために５つのコーディングパス、すなわち、（１）有意性パス、（２）１よりも大きいパス、（３）２よりも大きいパス、（４）サインパス、および（５）係数レベル残存パス（coefficient level remaining pass）を使用し得る。ただし、本開示の技法は、必ずしも５つのパスシナリオに限定されるとは限らない。概して、有意性コーディング（significance coding）は、ブロック内の係数のいずれかが１以上の絶対値を有するかどうかを示すために、シンタックス要素（syntax element）を生成することを指す。すなわち、１以上の絶対値をもつ係数は「有意である（significant）」と見なされる。他のコーディングパスについて、以下でより詳細に説明する。

[0033] 有意性パス中に、ビデオエンコーダは、変換係数が有意であるかどうかを示すシンタックス要素を判断する。本明細書では、変換係数が有意であるかどうかを示すシンタックス要素を有意性シンタックス要素（significance syntax element）と呼ぶ。有意性シンタックス要素の一例は有意性フラグであり、有意性フラグについての０の値は、係数が有意でない（すなわち、変換係数の値は０である）ことを示し、有意性フラグについての１の値は、係数が有意である（すなわち、変換係数の値は非０である）ことを示す。

[0034] 有意性パスを実行するために、ビデオエンコーダは、（最後有意位置の位置があらかじめ決定されており、デコーダにシグナリングされた場合）ブロックまたはブロックの一部の変換係数を走査し、各変換係数についての有意性シンタックス要素を判断する。水平走査、垂直走査、および対角走査など、走査順序の様々な例がある。ビデオエンコーダは、有意性シンタックス要素をＣＡＢＡＣ符号化し、コード化ビットストリーム中で符号化有意性シンタックス要素をシグナリングする。いくつかの例では、ジグザグ走査、適応または部分的適応走査など、他のタイプの走査も使用され得る。

[0035] シンタックス要素にＣＡＢＡＣコーディングを適用するために、「ビン（bin）」と呼ばれる一連の１つまたは複数のビットを形成するために、シンタックス要素に２値化が適用され得る。さらに、コーディングコンテキストはシンタックス要素のビンに関連し得る。コーディングコンテキストは、特定の値を有するビンをコーディングする確率を識別し得る。たとえば、コーディングコンテキストは、（この事例では、「最も有望なシンボル」の一例を表す）０の値のビンをコーディングする０．７の確率と、１の値のビンをコーディングする０．３の確率とを示し得る。コーディングコンテキストを識別した後に、ビンは、コンテキストに基づいて算術的にコーディングされ得る。場合によっては、特定のシンタックス要素またはそれのビンに関連するコンテキストは、他のシンタックス要素またはコーディングパラメータに依存し得る。

[0036] 本開示で説明する技法では、ビデオエンコーダは、走査順序に基づいてＣＡＢＡＣ符号化のためにどのコンテキストを使用すべきかを判断し得る。ビデオエンコーダは、走査順序タイプごとにコンテキストの１つのセットを使用し得る。たとえば、ブロックが４×４ブロックである場合、１６個の係数がある。この例では、ビデオエンコーダは、各走査について１６個のコンテキストを利用し、合計４８個のコンテキスト（すなわち、合計４８個のコンテキストの場合、水平走査のための１６個のコンテキストと、垂直走査のための１６個のコンテキストと、対角走査のための１６個のコンテキストと）を生じ得る。同様のことは、８×８ブロックについて成り立つが、合計１９２個のコンテキスト（すなわち、合計１９２個のコンテキストの場合、水平走査のための６４個のコンテキストと、垂直走査のための６４個のコンテキストと、対角走査のための６４個のコンテキストと）をもつことになる。しかしながら、４８個または１９２個のコンテキストの例は、単に例示のために与えられる。各ブロックのためのコンテキストの数はブロックサイズの関数であることが可能であり得る。

[0037] ビデオデコーダは、（たとえば、直接、またはコード化ビットストリームを記憶する記憶媒体を介してビデオエンコーダから）コード化ビットストリームを受信し、変換係数の値を判断するために、ビデオエンコーダの関数として逆関数を実行する。たとえば、ビデオデコーダは、受信ビットストリーム中の有意性シンタックス要素に基づいてどの変換係数が有意であるかを判断するために有意性パスを実装する。

[0038] 本開示で説明する技法では、ビデオデコーダは、ブロックの変換係数の走査順序（たとえば、変換係数が走査された走査順序）を判断し得る。ビデオデコーダは、走査順序に基づいて有意性シンタックス要素をＣＡＢＡＣ復号するためにどのコンテキストを使用すべきか（たとえば、４×４ブロックの場合に４８個のコンテキストのうちの１６個、または８×８ブロックの場合に１９２個のコンテキストのうちの６４個）を判断し得る。このようにして、ビデオデコーダは、ＣＡＢＡＣ復号のために、ビデオエンコーダがＣＡＢＡＣ符号化のために選択したコンテキストと同じコンテキストを選択し得る。ビデオデコーダは、判断されたコンテキストに基づいて有意性シンタックス要素をＣＡＢＡＣ復号する。

[0039] 上記の例では、ビデオエンコーダおよびビデオデコーダは、走査順序に基づいてコンテキストを判断し、コンテキストは、走査順序によって異なり、４×４ブロックの場合に合計４８個のコンテキストを生じ、８×８ブロックの場合に１９２個のコンテキストを生じた。しかしながら、本開示で説明する技法は、この点について限定されない。代替的に、いくつかの例では、ビデオエンコーダおよびビデオデコーダが使用するコンテキストは、走査順序タイプに応じてコンテキスト共有を可能にする複数の（すなわち、２つ以上の）走査順序について同じコンテキストであり得る。

[0040] 一例として、ビデオエンコーダおよびビデオデコーダは、走査順序が水平走査である場合または走査順序が垂直走査である場合に同じであるコンテキストを判断し得る。言い換えれば、走査順序が水平走査である場合、または、走査順序がブロック内の変換係数の特定の位置について垂直走査である場合、コンテキストは同じである。ビデオエンコーダとビデオデコーダは、対角走査のために異なるコンテキストを利用し得る。この例では、水平走査と垂直走査とのためのコンテキストが同じであり、対角走査のための異なるコンテキストがあるので、４×４ブロックの場合のコンテキストの数は、４８個のコンテキストから３２個のコンテキストまで減少し、８×８ブロックの場合、１９２個のコンテキストから１２８個まで減少する。

[0041] 別の例として、ビデオエンコーダとビデオデコーダがすべての走査順序タイプについて同じコンテキストを使用することは可能であり、それにより、コンテキストを４×４ブロックの場合に１６個まで低減し、８×８ブロックの場合に６４個まで低減し得る。しかしながら、すべての走査順序タイプについて同じコンテキストを使用することは、ブロックサイズによって決まり得る。たとえば、いくつかのブロックサイズの場合、すべての走査順序について同じコンテキストを使用することが可能であり得、いくつかの他のブロックサイズの場合、コンテキストは走査順序によって異なり得るか、または走査順序の２つ以上がコンテキストを共有し得る。

[0042] たとえば、８×８ブロックの場合、水平および垂直走査のためのコンテキストは（たとえば、特定の位置について）同じであり、対角走査については異なり得る。４×４、１６×１６、および３２×３２ブロックの場合、コンテキストは走査順序によって異なり得る。その上、位置に依拠したいくつかの他の技法では、２Ｄブロックのためのコンテキストと１Ｄブロックのためのコンテキストとは異なり得る。本開示で説明する技法では、コンテキストがすべての走査順序について共有されるとき、２Ｄブロックのためのコンテキストまたは１Ｄブロックのためのコンテキストは同じであり得る。

[0043] いくつかの例では、コンテキストを判断するために走査順序を利用することに加えて、ビデオエンコーダおよびビデオデコーダはブロックのサイズを考慮し得る。たとえば、上記の例では、ブロックのサイズは、すべての走査順序がコンテキストを共有するかどうかを示していた。いくつかの例では、ビデオエンコーダおよびビデオデコーダは、ブロックのサイズと走査順序とに基づいてどのコンテキストを使用すべきかを判断し得る。これらの例では、本開示で説明する技法は、コンテキスト共有を可能にし得る。たとえば、第１のサイズをもつブロックの場合、ビデオエンコーダおよびビデオデコーダは、第１のサイズのブロックが水平方向に走査される場合または第１のサイズのブロックが垂直方向に走査される場合に同じであるコンテキストを判断し得る。第２のサイズをもつブロックの場合、ビデオエンコーダおよびビデオデコーダは、第２のサイズのブロックが水平方向に走査される場合または第２のサイズのブロックが垂直方向に走査される場合に同じであるコンテキストを判断し得る。

[0044] これらの技法には他の変形形態があり得る。たとえば、いくつかのサイズ決定されたブロック（たとえば、１６×１６または３２×３２）の場合、ビデオエンコーダおよびビデオデコーダは、すべての走査順序についてＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のために使用されるコンテキストの第１のセットを判断する。いくつかのサイズ決定されたブロック（たとえば、８×８）の場合、ビデオエンコーダおよびビデオデコーダは、対角走査のためのＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のために使用されるコンテキストの第２のセットを判断し、水平走査と垂直走査の両方のためのＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のために使用されるコンテキストの第３のセットを判断する。いくつかのサイズ決定されたブロック（たとえば、４×４）の場合、ビデオエンコーダおよびビデオデコーダは、対角走査と水平走査と垂直走査とのためのＣＡＢＡＣ符号化またはＣＡＢＡＣ復号のために使用されるコンテキストの第４のセットを判断する。

[0045] 場合によっては、走査順序に基づいてコンテキストを判断する例は、イントラコーディングモードを対象とし得る。たとえば、変換係数はイントラコーディングの結果であり得、本開示で説明する技法は、そのような変換係数に適用可能であり得る。しかしながら、本開示で説明する技法は、そのように限定されず、インターコーディングまたはイントラコーディングに対して適用可能であり得る。

[0046] 図１Ａ〜図１Ｃは、変換係数を含むブロックの走査順序の例を示す概念図である。変換係数を含むブロックは変換ブロック（ＴＢ：transform block）と呼ばれることがある。変換ブロックは変換ユニットのブロックであり得る。たとえば、変換ユニットは、３つの変換ブロックと対応するシンタックス要素とを含む。変換ユニットは、８×８、１６×１６、または３２×３２サイズのルーマサンプル（luma sample）の変換ブロック、あるいは４×４サイズのルーマサンプルの４つの変換ブロック、ピクチャ３サンプルアレイのクロマサンプル（chroma sample）の２つの対応する変換ブロック、あるいは８×８、１６×１６、または３２×３２サイズのルーマサンプルの変換ブロック、あるいは４×４サイズのルーマサンプルの４つの変換ブロック、あるいはモノクロームピクチャまたは変換ブロックサンプルを変換するために使用される個別のカラープレーンおよびシンタックス構造を使用してコーディングされたピクチャであり得る。

[0047] 図１Ａに、変換係数１２Ａ〜１２Ｐ（「変換係数１２」と総称される）を含む４×４ブロック１０（たとえば、ＴＢ１０）の水平走査を示す。たとえば、水平走査は、変換係数１２Ｐから開始し、変換係数１２Ａにおいて終了し、変換係数を介して水平方向に進む。

[0048] 図１Ｂに、変換係数１６Ａ〜１６Ｐ（「変換係数１６」と総称される）を含む４×４ブロック１４（たとえば、ＴＢ１４）の垂直走査を示す。たとえば、垂直走査は、変換係数１６Ｐから開始し、変換係数１６Ａにおいて終了し、変換係数を介して垂直方向に進む。

[0049] 図１Ｃに、変換係数２０Ａ〜２０Ｐ（「変換係数２０」と総称される）を含む４×４ブロック１８（たとえば、ＴＢ１８）の対角走査を示す。たとえば、対角走査は、変換係数２０Ｐから開始し、変換係数２０Ａにおいて終了し、変換係数を介して対角方向に進む。

[0050] 図１Ａ〜図１Ｃは、最後の変換係数から開始し、最初の変換係数上で終了することを示しているが、本開示の技法はそのように限定されないことを理解されたい。いくつかの例では、ビデオエンコーダは、ブロック中の最後有意係数（last significant coefficient）（たとえば、０でない値をもつ最後の変換係数）のロケーションを判断し得る。ビデオエンコーダは、最後有意係数から開始し、最初の変換係数上で終了する走査を行い得る。ビデオエンコーダは、コード化ビットストリーム中で最後有意係数のロケーション（すなわち、最後有意係数のｘ座標およびｙ座標）をシグナリングし得、ビデオデコーダは、コード化ビットストリームから最後有意係数のロケーションを受信し得る。このようにして、ビデオデコーダは、変換係数のための後続のシンタックス要素（たとえば、有意性シンタックス要素）が、最後有意係数から開始し最初の変換係数上で終了する変換係数のためのものであることを判断し得る。

[0051] 図１Ａ〜図１Ｃは４×４ブロックとして示されているが、本開示で説明する技法はそのように限定されず、本技法は他のサイズ決定されたブロックに拡張され得る。その上、場合によっては、４×４ブロック１０、１４、および１８のうちの１つまたは複数は、より大きいブロックのサブブロックであり得る。たとえば、８×８ブロックは４つの４×４サブブロックに分割され得、１６×１６は１６個の４×４サブブロックに分割され得、以下同様であり、４×４ブロック１０、１４、および１８のうちの１つまたは複数は、８×８ブロックまたは１６×１６ブロックのサブブロックであり得る。サブブロック水平および垂直走査の例は、その各々が参照により本明細書に組み込まれる、（１）Rosewarne,C. Maeda,M. “Non-CE11: Harmonisation of 8x8 TU residual scan” JCT-VC Contribution JCTVC-H0145 （２）Yu,Y., Panusopone,K.Lou,J. Wang,L. “Adaptive Scan for Large Blocks for HEVC” JCT-VC Contribution JCTVC-F569 および（３）２０１２年７月１７日に出願された米国特許出願第１３／５５１，４５８号に記載されている。

[0052] 変換係数１２、１６、および２０は、予測されているブロックと別のブロックとの間の変換された残差値を表す。ビデオエンコーダは、変換係数１２、１６、および２０の値が０であるのか非０であるのかを示す有意性シンタックス要素を生成し、有意性シンタックス要素を符号化し、コード化ビットストリーム中で符号化有意性シンタックス要素をシグナリングする。ビデオデコーダは、コード化ビットストリームを受信し、変換係数１２、１６、および２０を判断するプロセスの一部として有意性シンタックス要素を復号する。

[0053] 符号化および復号の場合、ビデオエンコーダおよびビデオデコーダは、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）符号化および復号のために使用されるべきコンテキストを判断する。本開示で説明する技法では、変換係数１２、１６、および２０のための有意性シンタックス要素のためのコンテキストを判断するために、ビデオエンコーダおよびビデオデコーダは走査順序を考慮する。

[0054] たとえば、ビデオエンコーダおよびビデオデコーダは、走査順序が水平走査であると判断した場合、ビデオエンコーダおよびビデオデコーダは、ＴＵ１０の１６個の変換係数１２のためのコンテキストの第１のセットを判断し得る。ビデオエンコーダおよびビデオデコーダは、垂直走査中の走査順序を判断した場合、ビデオエンコーダおよびビデオデコーダは、ＴＵ１４の１６個の変換係数１６のためのコンテキストの第２のセットを判断し得る。ビデオエンコーダおよびビデオデコーダは、走査順序が対角走査であると判断した場合、ビデオエンコーダおよびビデオデコーダは、ＴＵ１８の１６個の変換係数２０のためのコンテキストの第３のセットを判断し得る。

[0055] この例では、コンテキスト共有がないことを仮定して、４×４ブロック１０、１４、および１８のための合計４８個のコンテキスト（すなわち、３つの走査順序の各々について１６個のコンテキスト）がある。ブロック１０、１４、および１８が８×８サイズのブロックであった場合、コンテキスト共有がないことを仮定して、合計１９２個のコンテキストの場合、そこで、３つの８×８サイズのブロックの各々のための６４個のコンテキスト（すなわち、３つの走査順序の各々について６４個のコンテキスト）がそうする。

[0056] より詳細に説明するように、いくつかの例では、２つ以上の走査順序がコンテキストを共有することが可能であり得る。たとえば、コンテキストの第１のセットとコンテキストの第２のセットとコンテキストの第３のセットとのうちの２つまたはそれ以上がコンテキストの同じセットであり得る。たとえば、水平走査のためのコンテキストの第１のセットは垂直走査のためのコンテキストの第２のセットと同じであり得る。場合によっては、第１、第２、および第３のコンテキストは、コンテキストの同じセットであり得る。

[0057] 上記の例では、ビデオエンコーダおよびビデオデコーダは、走査順序に基づいて、コンテキストの第１、第２、および第３のセットから、ＣＡＢＡＣ符号化および復号のために使用すべきコンテキストを判断する。いくつかの例では、ビデオエンコーダおよびビデオデコーダは、走査順序とブロックのサイズとに基づいてＣＡＢＡＣ符号化および復号のためのどのコンテキストを使用すべきかを判断する。

[0058] たとえば、ブロックが８×８である場合、ビデオエンコーダおよびビデオデコーダは、走査順序に基づいてコンテキストの第４、第５、および第６のセットからコンテキスト（各走査順序について１つ）を判断する。ブロックが１６×１６である場合、ビデオエンコーダおよびビデオデコーダは、走査順序に基づいてコンテキストの第７、第８、および第９のセットからコンテキスト（各走査順序について１つ）を判断し、以下同様である。上記と同様に、いくつかの例では、異なるサイズのブロックのためのコンテキスト共有があり得る。

[0059] 上記の例示的な技法の変形態があり得る。たとえば、ある場合には、特定のサイズのブロック（たとえば、４×４）の場合、ビデオエンコーダおよびビデオデコーダは、すべての走査順序について同じであるコンテキストを判断するが、８×８サイズのブロックの場合、ビデオエンコーダおよびビデオは、（たとえば、特定の位置における変換係数のための）水平走査と垂直走査とについて同じであるコンテキストを判断し、対角走査について異なるコンテキストを判断する。別の例として、より大きいサイズのブロック（たとえば、１６×１６および３２×３２）の場合、ビデオエンコーダおよびビデオデコーダは、すべての走査順序について、および両方のサイズについて同じであるコンテキストを判断し得る。いくつかの例では、１６×１６および３２×３２ブロックの場合、水平および垂直走査は適用されないことがある。他のそのような置換および組合せが可能であり、本開示によって企図される。

[0060] 走査順序に基づいてＣＡＢＡＣ符号化および復号のためにどのコンテキストを使用すべきかを判断することは、変換係数の大きさをより良く考慮し得る。たとえば、走査順序は変換係数の構成を定義する。一例として、第１の変換係数（ＤＣ係数と呼ばれる）の大きさは概して最も高い。第２の変換係数の大きさは（平均して、必ずしもそうではないが）次に高く、以下同様である。しかしながら、第２の変換係数のロケーションは走査順序に基づく。たとえば、図１Ａでは、第２の変換係数は、第１の変換係数のすぐ右（すなわち、変換係数１２Ａのすぐ右）の変換係数である。しかしながら、図１Ｂおよび図１Ｃでは、第２の変換係数は、第１の変換係数のすぐ下（すなわち、図１Ｂでは変換係数１６Ａのすぐ下、および図１Ｃでは変換係数２０Ａのすぐ下）の変換係数である。

[0061] このようにして、特定の走査位置における変換係数についての有意性統計は、走査順序に応じて変動し得る。たとえば、図１Ａでは、水平走査の場合、第１の行中の最後変換係数は、図１Ｂの垂直走査または図１Ｃの対角走査における同じ変換係数と比較して（平均して）はるかに高い大きさを有し得る。

[0062] 走査順序に基づいてどのコンテキストを使用すべきかを判断することによって、ビデオエンコーダおよびビデオデコーダは、走査順序を考慮しない他の技法と比較して、より良くＣＡＢＡＣ符号化またはＣＡＢＡＣ復号するように構成され得る。たとえば、４×４および８×８ブロックのための有意性シンタックス要素（たとえば、有意性フラグ）の符号化および復号は、位置ベースであることが可能であり得る。たとえば、４×４ブロック中の各位置のための別個のコンテキストと、８×８ブロックの各２×２サブブロックのための別個のコンテキストとがある。

[0063] しかしながら、この場合、コンテキストは、実際の走査順序にかかわらず、変換係数のロケーションに基づく（すなわち、４×４および８×８ブロックのための位置ベースのコンテキストは、様々な走査を区別しない）。たとえば、ブロック中の（ｉ，ｊ）に位置する変換係数のためのコンテキストは、水平、垂直、および対角走査について同じである。上記で説明したように、走査順序は変換係数についての有意性統計値に影響を及ぼし得、本開示で説明する技法は、有意性統計値を考慮するために走査順序に基づいてコンテキストを判断し得る。

[0064] 上記で説明したように、いくつかの例では、ビデオエンコーダおよびビデオデコーダは、２つ以上の走査順序について同じであるコンテキストを判断し得る。ビデオエンコーダおよびビデオデコーダは、変換係数の特定のロケーションのための２つ以上の走査順序について同じであるコンテキストを判断し得る様々な方法があり得る。一例として、水平および垂直走査順序は、水平走査と垂直走査のブロックの転置との間でコンテキストを共有することによって、特定のブロックサイズのためのコンテキストを共有する。たとえば、ビデオエンコーダおよびビデオデコーダは、特定のブロックサイズのための水平走査のための変換係数（ｉ，ｊ）と垂直走査のための変換係数（ｊ，ｉ）とについて同じコンテキストを判断し得る。

[0065] この事例は、特定の位置における変換係数が、異なる走査順序についてコンテキストを共有する一例である。たとえば、水平走査のための位置（ｉ，ｊ）における変換係数のためのコンテキストと、垂直走査のための位置（ｊ，ｉ）における変換係数のためのコンテキストとは同じコンテキストであり得る。いくつかの例では、コンテキストの共有は、変換係数の８×８サイズのブロックのために適用可能であり得る。また、いくつかの例では、走査順序が水平でもなく垂直でもない（たとえば、対角である）場合、位置（ｉ，ｊ）および／または（ｊ，ｉ）のためのコンテキストは、水平および垂直走査のための共有コンテキストのためのものとは異なり得る。

[0066] しかしながら、本開示で説明する技法は、そのように限定されず、特定のブロックサイズの場合の水平走査のための変換係数（ｉ，ｊ）のためのコンテキストと垂直走査のための変換係数（ｊ，ｉ）のためのコンテキストとが同じである例に限定されるものと見なされるべきでない。以下は、特定の位置における変換係数のためのコンテキストが異なる走査順序について共有される別の例示的な方法である。

[0067] たとえば、水平走査のためのブロックの第４の（最後の）行のためのコンテキストは、垂直走査のためのブロックの第４の（最後の）列のためのコンテキストとして同じであり得、水平走査のためのブロックの第３の行のためのコンテキストは、垂直走査のためのブロックの第３の列のためのコンテキストと同じであり得、水平走査のためのブロックの第２の行のためのコンテキストは、垂直走査のためのブロックの第２の列のためのコンテキストと同じであり得、水平走査のためのブロックの第１の行のためのコンテキストは、垂直走査のためのブロックの第１の列のためのコンテキストと同じであり得る。同様のことが８×８ブロックに適用され得る。ビデオエンコーダおよびビデオデコーダが、走査順序のうちの２つ以上について同じであるコンテキストを判断するための他の例示的な方法があり得る。

[0068] いくつかの例では、コンテキストは、異なるブロックサイズ間で共有される（たとえば、４×４ブロックと８×８ブロックとの間で共有される）ことが可能であり得る。一例として、４×４ブロック中の変換係数（１，１）のためのコンテキストと、８×８ブロック中の変換係数（２，２）、（２，３）、（３，２）および（３，３）のためのコンテキストとは同じであり得、いくつかの例では、特定の走査順序について同じであり得る。

[0069] 図２は、有意性シンタックス要素への変換係数のマッピングを示す概念図である。たとえば、図２の左側は変換係数値を示し、図２の右側は、対応する有意性シンタックス要素を示す。非０である値をもつすべての変換係数について、値１をもつ対応する有意性シンタックス要素（たとえば、有意性フラグ）がある。０である値をもつすべての変換係数について、値０をもつ対応する有意性シンタックス要素（たとえば、有意性フラグ）がある。本開示において説明する例では、ビデオエンコーダおよびビデオデコーダは、走査順序に基づいて、また、いくつかの例では、変換係数の位置とブロックのサイズとに基づいてコンテキストを判断することによって、図２に示す例示的な有意性シンタックス要素をＣＡＢＡＣ符号化およびＣＡＢＡＣ復号するように構成される。

[0070] 図３は、本開示で説明する技法を利用してコンテキストを割り当てるように構成され得る例示的なビデオ符号化および復号システム２２を示すブロック図である。図３に示すように、システム２２は、宛先デバイス２６によって後で復号されるべき符号化ビデオデータを生成するソースデバイス２４を含む。ソースデバイス２４および宛先デバイス２６は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス２４および宛先デバイス２６はワイヤレス通信に対応し得る。

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

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

[0073] 本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエア（over-the-air）テレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム２２は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

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

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

[0076] 宛先デバイス２６は、入力インターフェース４０と、ビデオデコーダ４２と、ディスプレイデバイス４４とを含む。場合によっては、入力インターフェース４０は受信機および／またはモデムを含み得る。宛先デバイス２６の入力インターフェース４０は、リンク２８を介して符号化ビデオデータを受信する。リンク２８を介して通信され、またはストレージデバイス３８上に与えられた符号化ビデオデータは、ビデオデータを復号する際に、ビデオデコーダ４２など、ビデオデコーダが使用するためのビデオエンコーダ３２によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体上に記憶されるか、またはファイルサーバ上に記憶される符号化ビデオデータとともに含まれ得る。

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

[0078] ビデオエンコーダ３２およびビデオデコーダ４２は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、ビデオ圧縮規格、またはそのような規格の拡張に従って動作し得る。代替的に、ビデオエンコーダ３２およびビデオデコーダ４２は、高効率ビデオコーディング（ＨＥＶＣ）規格などの他のプロプライエタリ（proprietary）または業界規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ：HEVC Test Model）に準拠し得る。ただし、本開示の技法は、特定のコーディング規格に限定されない。ビデオ圧縮規格の他の例としてはＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。

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

[0080] ビデオエンコーダ３２およびビデオデコーダ４２はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適なコンピュータ可読記憶媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ３２およびビデオデコーダ４２の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合され得る。たとえば、ビデオデコーダ４２を含むデバイスは、ビデオデコーダ４２を含むマイクロプロセッサ、集積回路（ＩＣ）、またはワイヤレス通信デバイスであり得る。

[0081] ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９個のイントラ予測符号化モードを与えるが、ＨＭは３５個ものイントラ予測符号化モードを与え得る。

[0082] 概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding unit）に分割され得ることを記述する。ツリーブロックは、Ｈ．２６４規格のマクロブロックと同様の目的を有する。スライスは、コーディング順序でいくつかの連続するツリーブロック（treeblock）を含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木（quadtree）に従ってコーディングユニット（ＣＵ：coding unit）に分割され得る。たとえば、４分木のルートノードとしてのツリーブロックは、４つの子ノードに分割され得、各子ノードは、次に、親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノード（leaf node）としての、最終的な、分割されていない子ノードは、コーディングノード、すなわち、コード化ビデオブロックを備える。コード化ビットストリームに関連するシンタックスデータは、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズをも定義し得る。

[0083] ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ：prediction unit）および変換ユニット（ＴＵ：transform unit）とを含む。上記で説明したように、変換ユニットは１つまたは複数の変換ブロックを含み、本開示で説明する技法は、走査順序に基づいて、いくつかの例では、走査順序と変換ブロックのサイズとに基づいて変換ブロックの変換係数のための有意性シンタックス要素（significance syntax element）のためのコンテキストを判断することに関する。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルを有するツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。

[0084] ＴＵは、形状が正方形または非正方形であり得る。この場合も、ＴＵは、１つまたは複数の変換ブロック（ＴＢ：transform block）（たとえば、ルーマサンプルのための１つのＴＢ、第１のクロマサンプルのための１つのＴＢ、および第２のクロマサンプルのための１つのＴＢ）を含む。この意味で、ＴＵは、これらのＴＢを含むものとして概念的に考慮され得、これらのＴＢは、形状が正方形または非正方形であり得る。たとえば、本開示では、ＴＵという用語は、一般的にＴＢを指すために使用され、本開示で説明する例示的な技法について、ＴＢに関して説明する。

[0085] ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従う変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用してより小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、変換されて変換係数が生成され得、その変換係数は量子化され得る。

[0086] 概して、ＰＵは、予測プロセスに関係するデータを含む。たとえば、ＰＵがイントラモード符号化（イントラ予測符号化（intra-prediction encoded））されるとき、ＰＵは、ＰＵのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化（インター予測符号化（inter-prediction encoded））されるとき、ＰＵは、ＰＵの動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０（Ｌ０）もしくはリスト１（Ｌ１））を記述し得る。

[0087] 概して、ＴＵは、変換プロセスと量子化プロセスとのために使用される。１つまたは複数のＰＵを有する所与のＣＵは、１つまたは複数の変換ユニット（ＴＵ）も含み得る。ＴＵは１つまたは複数の変換ブロック（ＴＢ）を含む。図１Ａ〜図１Ｃのブロック１０、１４、および１８は、それぞれＴＢの例である。予測の後に、ビデオエンコーダ３２は、ＰＵに対応する残差値を計算し得る。残差値は、エントロピーコーディングのためのシリアル化変換係数（serialized transform coefficient）を生成するために、ＴＢを使用して変換係数に変換され、量子化され、走査され得るピクセル差分値を備える。本開示では、一般に、ＣＵのコーディングノードを指すために「ビデオブロック（video block）」という用語を使用する。いくつかの特定の場合において、本開示では、コーディングノードとＰＵとを含む、ツリーブロック、すなわち、ＬＣＵまたはＣＵを指す「ビデオブロック」という用語も使用し得る。「ビデオブロック」という用語はまた、ＴＵの変換ブロックを指すことがある。

[0088] たとえば、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格に従うビデオコーディングでは、ビデオピクチャがコーディングユニット（ＣＵ）と予測ユニット（ＰＵ）と変換ユニット（ＴＵ）とに区分され得る。ＣＵは、概して、ビデオ圧縮のために様々なコーディングツールが適用される基本ユニットとして働く画像領域を指す。ＣＵは、一般に正方形の形状を有し、たとえば、ＩＴＵ−Ｔ Ｈ．２６４などの他のビデオコーディング規格の下でのいわゆる「マクロブロック（macroblock）」と同様であると見なされ得る。

[0089] より良いコーディング効率を達成するために、ＣＵは、それが含んでいるビデオデータに応じて可変サイズを有し得る。すなわち、ＣＵは、より小さいブロックまたはサブＣＵに区分または「分割（split）」され得、その各々はＣＵと呼ばれることもある。さらに、サブＣＵに分割されない各ＣＵは、それぞれ、ＣＵの予測および変換のために１つまたは複数のＰＵとＴＵとにさらに区分され得る。

[0090] ＰＵは、Ｈ．２６４などの他のビデオコーディング規格の下でのいわゆるブロックのパーティションと同様であると見なされ得る。ＰＵは、「残差（residual）」係数を生成するためにブロックについての予測が実行されるベースである。ＣＵの残差係数は、ＣＵのビデオデータと、ＣＵの１つまたは複数のＰＵを使用して判断されたＣＵについての予測データとの間の差を表す。詳細には、１つまたは複数のＰＵは、ＣＵが予測のためにどのように区分されるかを指定し、ＣＵの各パーティション内に含まれているビデオデータを予測するためにどの予測モードが使用されるかを指定する。

[0091] ＣＵの１つまたは複数のＴＵは、ＣＵのための残差変換係数のブロックを生成するために、ブロックにどの変換が適用されるかに基づいて、ＣＵの残差係数のブロックのパーティションを指定する。１つまたは複数のＴＵはまた、適用される変換のタイプに関連し得る。変換は、残差係数をピクセルまたは空間領域から周波数領域などの変換領域に変換する。さらに、１つまたは複数のＴＵは、量子化残差変換係数のブロックを生成するために残差変換係数の得られたブロックにどの量子化が適用されるかに基づいてパラメータを指定し得る。残差変換係数は、場合によっては、係数を表すために使用されるデータの量を低減するために量子化され得る。

[0092] ＣＵは、概して、Ｙとして示される１つのルミナンス成分と、ＵおよびＶとして示される２つのクロミナンス成分とを含む。言い換えれば、サブＣＵにさらに分割されない所与のＣＵは、Ｙ成分とＵ成分とＶ成分とを含み得、その各々は、前に説明したように、ＣＵの予測および変換のために１つまたは複数のＰＵとＴＵとにさらに区分され得る。たとえば、ビデオサンプリングフォーマットに応じて、サンプルの数で表されるＵ成分およびＶ成分のサイズは、Ｙ成分のサイズと同じであるかまたはそれとは異なり得る。したがって、予測、変換、および量子化に関して上記で説明した技法は、所与のＣＵのＹ成分とＵ成分とＶ成分との各々について実行され得る。

[0093] ＣＵを符号化するために、ＣＵの１つまたは複数のＰＵに基づいて、ＣＵのための１つまたは複数の予測子（predictor）が最初に導出される。予測子は、ＣＵについての予測データを含んでいる参照ブロックであり、前に説明したように、ＣＵのための対応するＰＵに基づいて導出される。たとえば、ＰＵは、それについて予測データが判断されるべきＣＵのパーティションと、予測データを判断するために使用される予測モードとを示す。予測子は、イントラ（Ｉ）予測（すなわち、空間的予測）モードまたはインター（ＰまたはＢ）予測（すなわち、時間的予測）モードのいずれかを通して導出され得る。したがって、いくつかのＣＵは、同じフレーム中の隣接参照ブロック（neighboring reference block）またはＣＵに対する空間的予測を使用してイントラコーディング（Ｉ）され得るが、他のＣＵは、他のフレーム中の参照ブロックまたはＣＵに対してインターコーディング（ＰまたはＢ）され得る。

[0094] ＣＵの１つまたは複数のＰＵに基づいて１つまたは複数の予測子を識別するときに、１つまたは複数のＰＵに対応するＣＵの元のビデオデータと１つまたは複数の予測子中に含まれているＣＵについての予測データとの間の差が計算される。予測残差（prediction residual）とも呼ばれるこの差は、残差係数を備え、前に説明したように、１つまたは複数のＰＵと１つまたは複数の予測子とによって指定されたＣＵの部分間のピクセル差分を指す。残差係数は、概して、１つまたは複数のＰＵｏＣＵに対応する２次元（２Ｄ）アレイで構成される。

[0095] さらなる圧縮を達成するために、予測残差は、概して、たとえば、離散コサイン変換（ＤＣＴ：discrete cosine transform）、整数変換、カルーネン・レーベ（Karhunen-Loeve）（Ｋ−Ｌ）変換、または別の変換を使用して変換され得る。変換は、同じく前に説明したように、空間領域中の予測残差、すなわち、残差係数を変換領域、たとえば、周波数領域中の残差変換係数に変換する。いくつかの場合では、変換はスキップされ、すなわち、変換は予測残差に適用されない。変換をスキップされた係数も変換係数として参照される。（変換スキップ係数を含む）変換係数はまた、概してＣＵの１つまたは複数のＴＵに対応する２Ｄアレイで構成される。さらなる圧縮のため、残差変換係数は、同じく前に説明したように、場合によっては、係数を表すために使用されるデータの量を低減するために量子化され得る。

[0096] またさらなる圧縮を達成するために、エントロピーコーダは、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：Context Adaptive Variable Length Coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、確率間隔区分エントロピーコーディング（ＰＩＰＥ：Probability Interval Partitioning Entropy Coding）、または別のエントロピーコーディング方法を使用して、得られた残差変換係数を後で符号化する。エントロピーコーディングは、他のＣＵと比較して、係数によって表される、ＣＵのビデオデータに固有の統計的冗長を低減または削除することによって、このさらなる圧縮を達成し得る。

[0097] ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ：group of pictures）は、概して、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ３２は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ（たとえば、変換係数の変換ブロック）内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に応じてサイズが異なり得る。

[0098] 一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ ＰＵと下部の２Ｎ×１．５Ｎ ＰＵとで水平方向に区分された２Ｎ×２Ｎ ＣＵを指す。

[0099] 本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ掛けるＮ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６掛ける１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ただし、Ｎは非負整数値を表す。ブロック中のピクセルは行と列とに構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ただし、Ｍは必ずしもＮに等しいとは限らない。

[0100] ＣＵのＰＵを使用したイントラ予測符号化またはインター予測符号化の後、ビデオエンコーダ３２は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域においてピクセルデータを備え得、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、スキップ変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ３２は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。

[0101] 変換係数を生成するための任意の変換の後に、ビデオエンコーダ３２は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度（bit depth）を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、ただし、ｎはｍよりも大きい。

[0102] いくつかの例では、ビデオエンコーダ３２は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序（たとえば、水平、垂直、または対角）を利用し得る。いくつかの例では、ビデオエンコーダ３２は適応走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ３２は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ３２はまた、ビデオデータを復号する際にビデオデコーダ４２が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化することができる。

[0103] ＣＡＢＡＣを実行するために、ビデオエンコーダ３２は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ３２は、送信されるべきシンボルのための可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率判断は、シンボルに割り当てられたコンテキストに基づき得る。

[0104] ビデオデコーダ４２は、ビデオエンコーダ３２によって実装される符号化技法の逆数を実装するように構成され得る。たとえば、符号化された有意性シンタックス要素の場合、ビデオデコーダ４２は、判断された走査順序に基づいてどのコンテキストを使用すべきかを判断することによって有意性シンタックス要素を復号し得る。

[0105] たとえば、ビデオエンコーダ３２は、変換係数の値を示すシンタックス要素をシグナリングする。ビデオエンコーダ３２は、一例として、５つのパス中でこれらのシンタックス要素を生成し、５つのパスを使用することは、あらゆる例において必要であるとは限らない。ビデオエンコーダ３２は、最後有意係数のロケーションを判断し、最後有意係数から第１のパスを開始する。第１のパスの後に、ビデオエンコーダ３２は、前のパスから残っているそれらの変換係数上にのみ残りの４つのパスを実装し得る。第１のパスでは、ビデオエンコーダ３２は、図１Ａ〜図１Ｃに示された走査順序のうちの１つを使用して変換係数を走査し、変換係数についての値が０であるのか非０であるのか（すなわち、有意でないのか有意であるのか）を示す、各変換係数についての有意性シンタックス要素を判断する。

[0106] １よりも大きいパスと呼ばれる第２のパスでは、ビデオエンコーダ３２は、有意係数の絶対値が１よりも大きいかどうかを示すためのシンタックス要素を生成する。同様にして、２よりも大きいパスと呼ばれる第３のパスでは、ビデオエンコーダ３２は、１よりも大きい係数の絶対値が２よりも大きいかどうかを示すためのシンタックス要素を生成する。

[0107] サインパスと呼ばれる第４のパスでは、ビデオエンコーダ３２は、有意係数についての符号情報を示すためのシンタックス要素を生成する。係数レベル残存パスと呼ばれる第５のパスでは、ビデオエンコーダ３２は、変換係数レベルの残りの絶対値（たとえば、余り値（remainder value））を示すシンタックス要素を生成する。余り値は、係数（coefficient）マイナス３の絶対値としてコーディングされ得る。５つのパス手法（five pass approach）は、変換係数をコーディングするために使用され得る１つの例示的な技法にすぎず、本明細書で説明する技法は、他の技法に等しく適用可能であり得ることに留意されたい。

[0108] 本開示で説明する技法では、ビデオエンコーダ３２は、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）を使用して有意性シンタックス要素を符号化する。本開示で説明する技法によれば、ビデオエンコーダ３２は、ブロックの変換係数のための走査順序を判断し、判断された走査順序に基づいてブロックの変換係数の有意性シンタックス要素のためのコンテキストを判断し得る。ビデオエンコーダ３２は、判断されたコンテキストに基づいて有意性シンタックス要素をＣＡＢＡＣ符号化し、コード化ビットストリーム中で符号化された有意性シンタックス要素をシグナリングし得る。

[0109] ビデオデコーダ４２は、同様の機能を実行するように構成され得る。たとえば、ビデオデコーダ４２は、コード化ビットストリームから、ブロックの変換係数の有意性シンタックス要素を受信する。ビデオデコーダ４２は、ブロックの変換係数のための走査順序（たとえば、ビデオエンコーダ３２が変換係数を走査した順序）を判断し得る。ビデオデコーダ４２は、次いで、変換係数ベースの少なくとも１つの判断されたコンテキストの有意性シンタックス要素をＣＡＢＡＣ復号し得る。

[0110] いくつかの例では、ビデオエンコーダ３２およびビデオデコーダ４２はそれぞれ、判断された走査順序が水平走査である場合および判断された走査順序が垂直走査である場合に同じであるコンテキストを判断し、判断された走査順序が対角走査である場合、水平走査および垂直走査のためのコンテキストとは異なるコンテキストを判断する。概して、ビデオエンコーダ３２およびビデオデコーダ４２はそれぞれ、走査順序が第１の走査順序である場合に有意性シンタックス要素のためのコンテキストの第１のセットを判断し、走査順序が第２の走査順序である場合に有意性シンタックス要素のためのコンテキストの第２のセットを判断し得る。コンテキストの第１のセットとコンテキストの第２のセットとは、場合によっては同じであり得る（たとえば、第１の走査順序は水平走査であり、第２の走査順序は垂直走査であり、またはその逆も同様である）。コンテキストの第１のセットとコンテキストの第２のセットとは、場合によっては異なり得る（たとえば、第１の走査順序は水平走査または垂直走査のいずれかであり、第２の走査順序は水平走査でもなく垂直走査でもない）。

[0111] いくつかの例では、ビデオエンコーダ３２およびビデオデコーダ４２はまた、ブロックのサイズを判断する。これらの例のいくつかでは、ビデオエンコーダ３２およびビデオデコーダ４２は、判断された走査順序に基づいて、およびブロックの判断されたサイズに基づいて有意性シンタックス要素のためのコンテキストを判断する。たとえば、コンテキストを判断するために、ビデオエンコーダ３２およびビデオデコーダ４２は、ブロックのサイズに基づいて、すべての走査順序について同じである変換係数の有意性シンタックス要素のためのそのコンテキストを判断し得る。言い換えれば、いくつかのサイズ決定されたブロックの場合、ビデオエンコーダ３２およびビデオデコーダ４２は、すべての走査順序について同じであるコンテキストを判断し得る。

[0112] いくつかの例では、本開示で説明する技法は、（１）Rosewarne, C. Maeda, M. “Non-CE11: Harmonisation of 8x8 TU residual scan” JCT-VC Contribution JCTVC-H0145 （２）Ｙu, Y. Panusopone, K. Lou, J., Wang, L. “Adaptive Scan for Large Blocks for HEVC” JCT-VC Contribution JCTVC-F569、および（３）２０１２年７月１７日に出願された米国特許出願第１３／５５１，４５８号に記載されているものなど、サブブロックの水平および垂直走査の概念に基づき得る。たとえば、本開示で説明する技法は、有意性シンタックス要素のコーディングの改善と、異なる走査順序およびブロック（たとえばＴＵ）サイズにわたる調和（harmonization）とを提供する。

[0113] たとえば、上記で説明したように、４×４ブロックは、より大きいブロックのサブブロックであり得る。本開示で説明する技法では、比較的大きいサイズのブロック（たとえば、１６×１６または３２×３２）は４×４サブブロックに分割され得、ビデオエンコーダ３２およびビデオデコーダ４２は、走査順序に基づいて４×４サブブロックのためのコンテキストを判断するように構成され得る。いくつかの例では、そのような技法は、８×８サイズのブロックに拡張可能であり、ならびにすべての走査順序のために拡張可能であり得る（すなわち、８×８ブロックの４×４サブブロックは、水平方向に、垂直方向に、または対角線方向に走査され得る）。そのような技法はまた、異なる走査順序間のコンテキスト共有を可能にし得る。

[0114] いくつかの例では、ビデオエンコーダ３２およびビデオデコーダ４２は、走査順序が対角走査である場合、すべてのブロックサイズについて同じであるコンテキストを判断する（すなわち、コンテキストは、対角走査を使用するときにＴＵのすべてについて共有される）。この例では、ビデオエンコーダ３２およびビデオデコーダ４２は、水平および垂直走査について同じであるコンテキストの別のセットを判断し得、それにより、走査順序に応じてコンテキスト共有を可能にする。

[0115] いくつかの例では、コンテキストの３つのセット、すなわち、比較的大きいブロックのためのセット、８×８ブロックまたは４×４ブロックの対角走査のためのセット、および８×８ブロックまたは４×４ブロックの水平走査と垂直走査の両方のためのセットがあり得、８×８ブロックのためのコンテキストと４×４ブロックのためのコンテキストとは異なる。サイズと走査順序との他の組合せおよび置換が可能であり得、ビデオエンコーダ３２およびビデオデコーダ４２は、サイズと走査順序とのこれらの様々な組合せおよび順列について同じであるコンテキストを判断するように構成され得る。

[0116] 図４は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ３２を示すブロック図である。図４の例では、ビデオエンコーダ３２は、モード選択ユニット４６と、予測処理ユニット４８と、参照ピクチャメモリ７０と、加算器５６と、変換処理ユニット５８と、量子化処理ユニット６０と、エントロピー符号化ユニット６２とを含む。予測処理ユニット４８は、動き推定ユニット５０と、動き補償ユニット５２と、イントラ予測ユニット５４とを含む。ビデオブロック再構成のために、ビデオエンコーダ３２はまた、逆量子化処理ユニット６４と、逆変換処理ユニット６６と、加算器６８とを含む。再構成されたビデオからブロッキネスアーティファクト（blockiness artifact）を除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ（deblocking filter）（図４に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６８の出力をフィルタ処理することになる。追加のループフィルタ（ループ内またはループ後）もデブロッキングフィルタに加えて使用され得る。予測処理ユニット４８および変換処理ユニット５８は、上記で説明したＰＵおよびＴＵと混同されるべきでないことに留意されたい。

[0117] 図４に示すように、ビデオエンコーダ３２はビデオデータを受信し、モード選択ユニット４６はデータをビデオブロックに区分する。この区分は、たとえば、ＬＣＵおよびＣＵの４分木構造に応じて、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分をも含み得る。ビデオエンコーダ３２は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに（および、場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。予測処理ユニット４８は、誤差結果（たとえば、コーディングレートおよびひずみレベル）に基づいて現在ビデオブロックについて、複数のイントラコーディングモードのうちの１つまたは複数のインターコーディングモードのうちの１つなど、複数の可能なコーディングモードのうちの１つを選択し得る。予測処理ユニット４８は、得られたイントラコード化ブロックまたはインターコード化ブロックを、残差ブロックデータを生成するために加算器５６に与え、参照ピクチャとして使用するための符号化ブロックを再構成するために加算器６８に与え得る。

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

[0119] 動き推定ユニット５０は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを判断するように構成され得る。所定のパターンは、シーケンス中のビデオスライスをＰスライスまたはＢスライスに指定し得る。動き推定ユニット５０と動き補償ユニット５２とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット５０によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。

[0120] 予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるべきビデオブロックのＰＵにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ３２は、参照ピクチャメモリ７０に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ３２は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット５０は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。

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

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

[0123] イントラ予測ユニット５４は、上記で説明したように、動き推定ユニット５０と動き補償ユニット５２とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット５４は、現在ブロックを符号化するために使用すべきイントラ予測モードを判断し得る。いくつかの例では、イントラ予測ユニット５４は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット５４（または、いくつかの例では、モード選択ユニット４６）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。たとえば、イントラ予測ユニット５４は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（bit rate）（すなわち、ビット数）を判断する。イントラ予測ユニット５４は、どのイントラ予測モードがブロックについて最良のレートひずみ値（rate-distortion value）を呈するかを判断するために、様々な符号化ブロックのひずみおよびレートから比を計算し得る。

[0124] いずれの場合も、ブロックのイントラ予測モードを選択した後に、イントラ予測ユニット５４は、ブロックについての選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット６２に提供し得る。エントロピー符号化ユニット６２は、本明細書で説明するエントロピー技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。

[0125] 予測処理ユニット４８が、インター予測またはイントラ予測のいずれかを介して、現在ビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ３２は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロックにおける残差ビデオデータは、１つまたは複数のＴＢに含まれ得、変換処理ユニット５８に適用され得る。変換処理ユニット５８は、変換、たとえば離散コサイン変換（ＤＣＴ）または概念的に類似の変換を使用して、残差ビデオデータを残差変換係数に変換し得る。変換処理ユニット５８は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。場合によっては、変換処理ユニット５８は、ＴＢ中の残差データに２次元（２Ｄ）変換を（水平方向と垂直方向の両方で）適用し得る。いくつかの例では、変換処理ユニット５８は、代わりに、ＴＢの各々中の残差データに、水平１Ｄ変換、垂直１Ｄ変換を適用するか、または変換を適用しないことがある。

[0126] 変換処理ユニット５８は、得られた変換係数を量子化処理ユニット６０に送り得る。量子化処理ユニット６０は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化処理ユニット６０は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット６２が走査を実行し得る。

[0127] 上記で説明したように、変換ブロックに対して実行される走査は変換ブロックのサイズに基づき得る。量子化処理ユニット６０および／またはエントロピー符号化ユニット６２は、図１Ａ〜図１Ｃに関して上記で説明したサブブロック走査の任意の組合せを使用して８×８、１６×１６、および３２×３２変換ブロックを走査し得る。１つの走査よりも多くの走査が変換ブロックのために利用可能であるとき、エントロピー符号化ユニット６２は、変換ブロックに対応する予測ユニットに関連する予測モードなど、変換ブロックに関連するコーディングパラメータに基づいて走査順序を判断し得る。エントロピー符号化ユニット６２に関するさらなる詳細について、図５に関して以下で説明する。

[0128] 逆量子化処理ユニット６４および逆変換処理ユニット６６は、それぞれ逆量子化および逆変換を適用して、参照ピクチャの参照ブロックとして後で使用するために、ピクセル領域において残差ブロックを再構成する。動き補償ユニット５２は、残差ブロックを参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット５２はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６８は、再構成された残差ブロックを動き補償ユニット５２によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ７０に記憶するための参照ブロックを生成する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット５０および動き補償ユニット５２によって参照ブロックとして使用され得る。

[0129] 量子化の後に、エントロピー符号化ユニット６２は量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット６２は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピー符号化方法または技法を実行し得る。エントロピー符号化ユニット６２によるエントロピー符号化の後に、符号化ビットストリームは、ビデオデコーダ４２に送信されるか、あるいはビデオデコーダ４２が後で送信するかまたは取り出すためにアーカイブされ得る。エントロピー符号化ユニット６２はまた、コーディングされている現在ビデオスライスのための動きベクトルと他のシンタックス要素とをエントロピー符号化し得る。エントロピー符号化ユニット６２は、ＣＡＢＡＣを使用して上記で説明した変換係数のための有意性シンタックス要素および他のシンタックス要素など、シンタックス要素をエントロピー符号化し得る。

[0130] いくつかの例では、エントロピー符号化ユニット６２は、判断された走査順序に基づいてコンテキストを判断する、本開示で説明する技法を実装するように構成され得る。いくつかの例では、ビデオエンコーダ３２内の１つまたは複数のユニットとともに、エントロピー符号化ユニット６２は、本開示で説明する技法を実装するように構成され得る。いくつかの例では、ビデオエンコーダ３２のプロセッサまたは処理ユニット（図示せず）は、本開示で説明する技法を実装するように構成され得る。

[0131] 図５は、本開示で説明する技法を実装し得る例示的なエントロピー符号化ユニット６２を示すブロック図である。図５に示すエントロピー符号化ユニット６２は、ＣＡＢＡＣエンコーダであり得る。例示的なエントロピー符号化ユニット６２は、２値化ユニット７２と、バイパス符号化エンジン７４および正規符号化エンジン７８を含む算術符号化ユニット８０と、コンテキストモデリングユニット７６とを含み得る。

[0132] エントロピー符号化ユニット６２は、ＨＥＶＣにおいてｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆｉｃｉｅｎｔ＿ｆｌａｇと呼ばれる有意性シンタックス要素、ＨＥＶＣにおいてｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇと呼ばれる１よりも大きいフラグ、ＨＥＶＣにおいてｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇと呼ばれる２よりも大きいフラグ、ＨＥＶＣにおいてｃｏｅｆｆ＿ｓｉｇｎ＿ｆｌａｇと呼ばれるサインフラグ、およびｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｒｅｍａｉｎと呼ばれるレベルシンタックス要素など、１つまたは複数のシンタックス要素を受信し得る。２値化ユニット７２は、シンタックス要素を受信し、ビンストリング（すなわち、バイナリストリング）を生成する。２値化ユニット７２は、たとえば、ビンストリングを生成するために以下の技法、すなわち、固定長コーディング（fixed length coding）と、単項コーディング（unary coding）と、短縮単項コーディング（truncated unary coding）と、短縮ライスコーディング（truncated Rice coding）と、ゴロムコーディング（Golomb coding）と、指数ゴロムコーディング（exponential Golomb coding）と、ゴロムライスコーディング（Golomb-Rice coding）とのいずれか１つまたは組合せを使用し得る。さらに、場合によっては、２値化ユニット７２は、バイナリストリングとしてシンタックス要素を受信し、単にビン値をパススルーし得る。一例では、２値化ユニット７２は、有意性シンタックス要素を受信し、ビンストリングを生成する。

[0133] 算術符号化ユニット８０は、２値化ユニット７２からビンストリングを受信し、ビンストリングに対して算術符号化を実行するように構成される。図５に示すように、算術符号化ユニット８０は、バイパス経路または正規コーディング経路からビン値を受信し得る。バイパス経路に続くビン値は、バイパスコーディングされたものとして識別されたビン値であり得、正規符号化経路に続くビン値は、ＣＡＢＡＣコーディングされたものとして識別され得る。上記で説明したＣＡＢＡＣプロセスに従って、算術符号化ユニット８０がバイパス経路からビン値を受信した場合、バイパス符号化エンジン７４は、ビン値に割り当てられた適応コンテキストを利用することなしに、ビン値に対して算術符号化を実行し得る。一例では、バイパス符号化エンジン７４は、ビンの考えられる値について等しい確率を仮定し得る。

[0134] 算術符号化ユニット８０が正規経路を介してビン値を受信した場合、コンテキストモデリングユニット７６は、正規符号化エンジン７８が、コンテキストモデリングユニット７６によって与えられたコンテキスト割当てに基づいて算術符号化を実行し得るように、コンテキスト変数（たとえば、コンテキスト状態）を与え得る。コンテキスト割当ては、ＨＥＶＣ規格など、ビデオコーディング規格に従って定義され得る。さらに、一例では、コンテキストモデリングユニット７６および／またはエントロピー符号化ユニット６２は、本明細書で説明する技法に基づいて有意性シンタックス要素のビンのためのコンテキストを判断するように構成され得る。本技法は、ＨＥＶＣまたは別のビデオコーディング規格に組み込まれ得る。コンテキストモデルはメモリに記憶され得る。コンテキストモデリングユニット７６は、一連のインデックス付きテーブルを含み、および／または特定のビンのためのコンテキストおよびコンテキスト変数を判断するためにマッピング関数を利用し得る。ビン値を符号化した後に、正規符号化エンジン７８は、実際のビン値に基づいてコンテキストを更新し得る。

[0135] 図６は、本開示による、ビデオデータを符号化するための例示的なプロセスを示すフローチャートである。図６のプロセスについて、概してビデオエンコーダ３２によって実行されるものとして以下で説明するが、プロセスは、ビデオエンコーダ３２、エントロピー符号化ユニット６２、および／またはコンテキストモデリングユニット７６の任意の組合せによって実行され得る。

[0136] 図示のように、ビデオエンコーダ３２は、ブロックの変換係数のための走査順序を判断する（８２）。ビデオエンコーダ３２は、走査順序に基づいて変換係数のためのコンテキストを判断する（８４）。いくつかの例では、ビデオエンコーダ３２は、判断された走査順序と、ブロックをもつ変換係数の位置と、ブロックのサイズとに基づいてコンテキストを判断する。たとえば、特定のブロックサイズ（たとえば、変換係数の８×８ブロック）および特定の位置（たとえば、変換係数位置）の場合、ビデオエンコーダ３２は、走査順序が水平走査または垂直走査のいずれかである場合に同じコンテキストを判断し、水平走査でなく垂直走査でない中の走査順序の場合に異なるコンテキストを判断し得る。

[0137] ビデオエンコーダ３２は、判断されたコンテキストに基づいて変換係数のための有意性シンタックス要素（たとえば、有意性フラグ）をＣＡＢＡＣ符号化する（８６）。ビデオエンコーダ３２は、符号化された有意性シンタックス要素（たとえば、有意性フラグ）をシグナリングする（８８）。

[0138] 図７は、本開示で説明する技法を実装し得る例示的なビデオデコーダ４２を示すブロック図である。図７の例では、ビデオデコーダ４２は、エントロピー復号ユニット９０と、予測処理ユニット９２と、逆量子化処理ユニット９８と、逆変換処理ユニット１００と、加算器１０２と、参照ピクチャメモリ１０４とを含む。予測処理ユニット９２は、動き補償ユニット９４と、イントラ予測ユニット９６とを含む。ビデオデコーダ４２は、いくつかの例では、図４のビデオエンコーダ３２に関して説明した符号化パスとは概して逆の復号パスを実行し得る。

[0139] 復号プロセス中に、ビデオデコーダ４２は、ビデオエンコーダ３２から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ４２のエントロピー復号ユニット９０は、量子化係数、動きベクトル、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット９０は、予測処理ユニット９２に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ４２は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

[0140] いくつかの例では、エントロピー復号ユニット９０は、判断された走査順序に基づいてコンテキストを判断する、本開示で説明する技法を実装するように構成され得る。いくつかの例では、エントロピー復号ユニット９０は、ビデオデコーダ４２内の１つまたは複数のユニットとともに、本開示で説明する技法を実装するように構成され得る。いくつかの例では、ビデオデコーダ４２のプロセッサまたは処理ユニット（図示せず）は、本開示で説明する技法を実装するように構成され得る。

[0141] 図８は、本開示で説明する技法を実装し得る例示的なエントロピー復号ユニット９０を示すブロック図である。エントロピー復号ユニット９０は、エントロピー符号化ビットストリームを受信し、ビットストリームからシンタックス要素を復号する。シンタックス要素は、ｓｉｇｎｉｆｉｃａｎｔ＿ｃｏｅｆｆｉｃｉｅｎｔ＿ｆｌａｇ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｒｅｍａｉｎ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇ、およびｃｏｅｆｆ＿ｓｉｇｎ＿ｆｌａｇなどのシンタックス要素、ブロックの変換係数のための上記で説明したシンタックス要素を含み得る。図８の例示的なエントロピー復号ユニット９０は算術復号ユニット１０６を含み、算術復号ユニット１０６はバイパス復号エンジン１０８と正規復号エンジン１１０とを含み得る。例示的なエントロピー復号ユニット９０はまた、コンテキストモデリングユニット１１２と逆２値化ユニット１１４とを含む。例示的なエントロピー復号ユニット９０は、図５に関して説明した例示的なエントロピー符号化ユニット６２の逆の機能を実行し得る。このようにして、エントロピー復号ユニット９０は、本開示で説明する技法に基づいてエントロピー復号を実行し得る。

[0142] 算術復号ユニット１０６は符号化ビットストリームを受信する。図８に示すように、算術復号ユニット１０６は、バイパス経路または正規コーディング経路に従って、符号化されたビン値を処理し得る。符号化されたビン値がバイパス経路に従って処理されるべきか、または正規パスに従って処理されるべきかという指示は、より高いレベルシンタックスとともにビットストリーム中でシグナリングされ得る。上記で説明したＣＡＢＡＣプロセスに従って、算術復号ユニット１０６がバイパス経路からビン値を受信した場合、バイパス復号エンジン１０８は、ビン値に割り当てられたコンテキストを利用することなしにビン値に対して算術符号化を実行し得る。一例では、バイパス復号エンジン１０８は、ビンの考えられる値について等しい確率を仮定し得る。

[0143] 算術復号ユニット１０６が、正規経路を介してビン値を受信した場合、コンテキストモデリングユニット１１２によって与えられるコンテキスト割当て（context assignment）に基づいて、正規復号エンジン１１０が算術符号化を実行し得るように、コンテキストモデリングユニット１１２はコンテキスト変数（context variable）を与え得る。コンテキスト割当ては、ＨＥＶＣなどのビデオコーディング規格に従って定義され得る。コンテキストモデルはメモリに記憶され得る。コンテキストモデリングユニット１１２は、一連のインデックス付きテーブルを含み、および／または符号化ビットストリームのコンテキストおよびコンテキスト変数部分を判断するためにマッピング関数を利用し得る。さらに、一例では、コンテキストモデリングユニット１１２および／またはエントロピー復号ユニット９０は、本明細書で説明する技法に基づいて有意性シンタックス要素のビンにコンテキストを割り当てるように構成され得る。ビン値を復号した後、正規復号エンジン１１０は、復号されたビン値に基づいてコンテキストを更新し得る。さらに、逆２値化ユニット１１４は、ビン値に対して逆２値化を実行し、ビン値が有効であるかどうかを判断するためにビン照合関数を使用し得る。逆２値化ユニット１１４はまた、照合判断に基づいてコンテキストモデリングユニットを更新し得る。したがって、逆２値化ユニット１１４は、コンテキスト適応型復号技法に従ってシンタックス要素を出力する。

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

[0145] 動き補償ユニット９４は、動きベクトルと他のシンタックス要素とを解析（parsing）することによって現在ビデオスライスのビデオブロックのための予測情報を判断し、その予測情報を使用して、復号されている現在ビデオブロックの予測ブロックを生成する。たとえば、動き補償ユニット９４は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、ＢスライスまたはＰスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを判断するために、受信されたシンタックス要素のいくつかを使用する。

[0146] 動き補償ユニット９４はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット９４は、ビデオブロックの符号化中にビデオエンコーダ３２によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット９４は、受信されたシンタックス要素からビデオエンコーダ３２によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。

[0147] 逆量子化処理ユニット９８は、ビットストリーム中で与えられ、エントロピー復号ユニット９０によって復号された、量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を判断し、同様に、適用されるべき逆量子化の程度を判断するための、ビデオスライス中の各ビデオブロックについてビデオエンコーダ３２によって計算される量子化パラメータの使用を含み得る。逆変換ユニット１００は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。

[0148] 場合によっては、逆変換処理ユニット１００は、係数に２次元（２Ｄ）変換を（水平方向と垂直方向の両方で）適用し得る。いくつかの例では、逆変換処理ユニット８８は、代わりに、ＴＵの各々中の残差データに、水平１Ｄ逆変換、垂直１Ｄ逆変換を適用するか、または変換を適用しないことがある。ビデオエンコーダ３２において残差データに適用される変換のタイプは、適切なタイプの逆変換を変換係数に適用するために、ビデオデコーダ４２にシグナリングされ得る。

[0149] 動き補償ユニット９４が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ４２は、逆変換処理ユニット１００からの残差ブロックを動き補償ユニット９４によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器１０２は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ１０４に記憶される。参照ピクチャメモリ１０４はまた、図３のディスプレイデバイス４４などのディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。

[0150] 図９は、本開示による、ビデオデータを復号するための例示的なプロセスを示すフローチャートである。図９のプロセスについて、概してビデオデコーダ４２によって実行されるものとして以下で説明するが、プロセスは、ビデオデコーダ４２、エントロピー復号ユニット９０、および／またはコンテキストモデリングユニット１１２の任意の組合せによって実行され得る。

[0151] 図９に示すように、ビデオデコーダ４２は、コード化ビットストリームから、ブロックの変換係数のための有意性シンタックス要素（たとえば、有意性フラグ（significance flag））を受信する（１１６）。ビデオデコーダ４２は変換係数のための走査順序を判断する（１１８）。ビデオデコーダ４２は、判断された走査順序に基づいて変換係数のためのコンテキストを判断する（１２０）。いくつかの例では、ビデオデコーダ４２はまた、ブロックサイズを判断し、判断された走査順序とブロックサイズとに基づいてコンテキストを判断する。いくつかの例では、ビデオデコーダ４２は、判断された走査順序と、ブロックをもつ変換係数の位置と、ブロックのサイズとに基づいてコンテキストを判断する。たとえば、特定のブロックサイズ（たとえば、変換係数の８×８ブロック）および特定の位置（たとえば、変換係数位置）の場合、ビデオデコーダ４２は、走査順序が水平走査または垂直走査のいずれかである場合に同じコンテキストを判断し、走査順序が水平走査でなく垂直走査でない場合に異なるコンテキストを判断し得る。ビデオデコーダ４２は、判断されたコンテキストに基づいて有意性シンタックス要素（たとえば、有意性フラグ）をＣＡＢＡＣ復号する（１２２）。

[0152] 図６のフローチャートで説明したビデオエンコーダ３２と、図９のフローチャートで説明したビデオデコーダ４２とは、本開示で説明する様々な他の例示的な技法を実装するように構成され得る。たとえば、コンテキストを判断するために、ビデオエンコーダ３２およびビデオデコーダ４２は、判断された走査順序が水平走査である場合および判断された走査順序が垂直走査である場合に同じであるコンテキストを判断し、判断された走査順序が水平走査でなく垂直走査でない（たとえば、対角走査である）場合、判断された走査順序が水平走査である場合および判断された走査順序が垂直走査である場合のコンテキストとは異なるコンテキストを判断するように構成され得る。

[0153] いくつかの例では、コンテキストを判断するために、ビデオエンコーダ３２およびビデオデコーダ４２は、走査順序が第１の走査順序である場合に有意性シンタックス要素のためのコンテキストの第１のセットを判断し、走査順序が第２の走査順序である場合に有意性シンタックス要素のためのコンテキストの第２のセットを判断するように構成され得る。いくつかのこれらの例では、コンテキストの第１のセットは、第１の走査順序が水平走査であり、第２の走査順序が垂直走査である場合、コンテキストの第２のセットと同じである。これらの例のいくつかでは、コンテキストの第１のセットは、第１の走査順序が水平走査または垂直走査のうちの１つであり、第２の走査順序が水平走査でなく垂直走査でない場合、コンテキストの第２のセットとは異なる。

[0154] いくつかの例では、ビデオエンコーダ３２およびビデオデコーダ４２はブロックのサイズを判断し得る。これらの例のいくつかでは、ビデオエンコーダ３２およびビデオデコーダ４２は、走査順序とブロックの判断されたサイズとに基づいてコンテキストを判断し得る。一例として、ビデオエンコーダ３２およびビデオデコーダ４２は、ブロックの判断されたサイズに基づいて、すべての走査順序について同じである変換係数の有意性シンタックス要素のためのコンテキストを判断し得る（すなわち、いくつかのブロックサイズについて、コンテキストは、すべての走査順序について同じである）。

[0155] たとえば、ビデオエンコーダ３２およびビデオデコーダ４２は、ブロックのサイズが第１のサイズであるのか第２のサイズであるのかを判断し得る。第１のサイズの一例は４×４ブロックであり、第２のサイズの一例は８×８ブロックである。ブロックのサイズが第１のサイズ（たとえば、４×４ブロック）である場合、ビデオエンコーダ３２およびビデオデコーダ４２は、すべての走査順序について同じであるコンテキスト（たとえば、４×４ブロックの場合、対角、水平、および垂直走査について同じであるコンテキスト）を判断し得る。ブロックのサイズが第２のサイズ（たとえば、８×８ブロック）である場合、ビデオエンコーダ３２およびビデオデコーダ４２は、少なくとも２つの異なる走査順序について異なるコンテキストを判断し得る（たとえば、８×８ブロックの対角走査のためのコンテキストは、８×８ブロックの水平または垂直走査のためのコンテキストとは異なるが、８×８ブロックの水平走査のためのコンテキストと垂直走査のためのコンテキストとは同じであり得る）。

[0156] 以下に、一例として、イントラコーディングから生じる変換係数など、変換係数がコーディングされる方法を改善するための様々な追加の技法について説明する。しかしながら、本技法は、インターコーディングの場合など、他の例にも適用可能であり得る。以下の技法は、個々に、または本開示で説明する他の技法のいずれかとともに使用され得る。その上、上記で説明した技法は、以下の技法のいずれかとともに使用され得るか、または以下の技法のいずれかとは別々に実装され得る。

[0157] いくつかの例では、ビデオエンコーダ３２およびビデオデコーダ４２は、最後有意係数（last significant coefficient）のロケーションを判断するために１つの走査順序を利用し得る。ビデオエンコーダ３２およびビデオデコーダ４２は、変換係数のための近傍コンテキストを判断するために異なる走査順序を利用し得る。ビデオエンコーダ３２およびビデオデコーダ４２は、次いで、判断された近傍コンテキストに基づいて、有意性フラグと、レベル情報と、符号情報とをコーディングし得る。たとえば、ビデオエンコーダ３２およびビデオデコーダ４２は、最後有意変換係数を識別するために（ノミナル走査（nominal scan）と呼ばれる）水平または垂直走査を利用し、次いで、近傍コンテキストを判断するために４×４ブロックまたは４×４サブブロック（８×８ブロックの場合）に対して対角走査を利用し得る。

[0158] いくつかの例では、１６×１６および３２×３２ブロックの場合、処理されている現在係数の（変換領域中の）近傍は、係数のための有意性フラグをコーディングするために使用されるコンテキストの導出のために使用される。同様に、ＪＣＴＶＣ−Ｈ０２２８では、近傍は、すべてのブロックサイズのための有意性ならびにレベル情報をコーディングするために使用される。４×４および８×８ブロックのための近傍ベースのコンテキストを使用することは、ＨＥＶＣのコーディング効率を改善し得る。ただし、いくつかの他の技法による有意性マップのための既存の有意性近傍が、水平または垂直走査とともに使用された場合、コンテキストを並列に導出する能力は影響を受け得る。したがって、いくつかの例では、いくつかの他の技法による有意性コーディングのために使用される近傍とともに水平および垂直走査のいくつかの態様を使用する方式について説明する。

[0159] これは、以下のように達成される。いくつかの例では、最初に、走査順序中の最後有意係数の位置は、ビットストリーム中でコーディングされる。この後に、逆方向走査順序中で１６個の係数のサブセット（４×４サブブロックベースの対角走査の場合４×４サブブロック）のための有意性マップが続き、レベル情報および符号のためのコーディングパスが続く。最後有意係数の位置は、使用される特定の走査に直接依存することに留意されたい。この例を図１０に示す。

[0160] 図１０は、走査順序に応じて最後有意係数の位置を示す概念図である。図１０にブロック１２４を示す。黒丸で示されるピクセルは有意である。水平走査の場合、最後有意位置の位置は、（行，列）フォーマットで（１，２）（変換係数１２８）である。４×４サブブロックベースの対角走査（右上）の場合、最後有意位置の位置は（０，３）（変換係数１２６）である。

[0161] この例では、水平または垂直走査の場合、最後有意係数位置は依然として、ノミナル走査に基づいて判断され、コーディングされる。ただし、その場合、有意性、レベルおよび符号情報をコーディングするために、ブロックは、右下係数で開始し、ＤＣ係数に逆方向に進む４×４サブブロックベースの対角走査を使用して走査される。特定の係数が有意でないことが、最後有意係数の位置から導出され得る場合、その係数のための有意性、レベルまたは符号情報はコーディングされない。

[0162] 水平走査の場合のこの手法の例を図１１に示す。図１１は、元の水平走査の代わりに対角走査の使用を示す概念図である。図１１にブロック１３０を示す。黒く塗りつぶされた係数は有意である。最後有意位置の位置は、水平走査を仮定すると、（１，１）（変換係数１３２）である。１よりも大きい行インデックスをもつすべての係数は、有意でないと推論され得る。同様に、行インデックス１と、１よりも大きい列インデックスとをもつすべての係数は、有意でないと推論され得る。同様に、係数（１，１）は有意であると推論され得る。それのレベルおよび符号情報は推論されないことがある。有意性、レベルおよび符号情報のコーディングのために、逆方向４×４サブブロックベースの対角走査が使用される。右下係数で開始して、有意性フラグは符号化される。推論され得る有意性フラグは明示的にコーディングされない。有意性フラグのコーディングのために、近傍ベースのコンテキストが使用される。近傍は、１６×１６および３２×３２ブロックのために使用されるものと同じであり得るか、または異なる近傍が使用され得る。上記と同様に、近傍ベースのコンテキストの別個のセットが、異なる走査（水平、垂直、および４×４サブブロック）のために使用され得ることに留意されたい。また、コンテキストは異なるブロックサイズ間で共有され得る。

[0163] 別の例では、ノミナル走査を仮定して最後有意位置の位置がコーディングされた後、ＪＣＴＶＣ−Ｈ０２２８の技法など、様々な技法のいずれかが、４×４および８×８ブロックのための有意性、レベルおよび符号情報をコーディングするために使用され得る。有意性、レベルおよび符号情報のコーディングのために、４×４サブブロックベースの対角走査が使用され得る。

[0164] 本方法は、水平、垂直、および４×４サブブロックベースの対角走査に限定されないことに留意されたい。基本原理は、ノミナル走査を仮定して最後有意係数位置を送り、次いで、近傍ベースのコンテキストを使用する別の走査を使用して有意性（および場合によってはレベルおよび符号）情報をコーディングすることである。同様に、４×４および８×８ブロックの場合の技法について説明したが、本技法は、水平および／または垂直走査が使用され得る任意のブロックサイズに拡張され得る。

[0165] 一例では、変換ブロック中のそれの位置に基づいて各変換係数について別個のコンテキストを利用するのではなく、ビデオコーダ（たとえば、ビデオエンコーダ３２またはビデオデコーダ４２）は、変換係数の行インデックスまたは列インデックスに基づいて変換係数をコーディングするためにどのコンテキストを使用すべきかを判断し得る。たとえば、水平走査の場合、同じ行中のすべての変換係数は同じコンテキストを共有し得、ビデオコーダは、異なる行中の変換係数について異なるコンテキストを利用し得る。垂直走査の場合、同じ列中のすべての変換係数は同じコンテキストを共有し得、ビデオコーダは、異なる列中の変換係数について異なるコンテキストを利用し得る。

[0166] いくつかの他の技法は、１６×１６およびより高いブロックサイズのための有意性マップのコーディングのための係数位置に基づいて複数のコンテキストセットを使用し得る。同様に、ＪＣＴＶＣ−Ｈ０２２８（およびまたＨＭ５．０）は、コンテキストセットを判断するために行および列インデックスの和を使用する。ＪＣＴＶＣ−Ｈ０２２８の場合、これは水平および垂直走査のためにも行われる。

[0167] 本開示のいくつかの例示的な技法では、水平走査の場合の特定の係数のための有意性またはレベルをコーディングするために使用されるコンテキストセットは、係数の行インデックスのみに依存し得る。同様に、垂直走査の場合、係数のための有意性またはレベルをコーディングするコンテキストセットは、係数の列インデックスのみに依存し得る。

[0168] 本開示のいくつかの例示的な技法では、コンテキストセットは、走査における係数の絶対インデックスのみに依存し得る。異なる走査は、コンテキストセットを導出するために異なる機能を使用し得る。

[0169] さらに、上記で説明したように、水平、垂直および４×４サブブロックベース対角走査は別個のコンテキストセットを使用し得るか、または水平および垂直走査はコンテキストセットを共有し得る。いくつかの例では、コンテキストセットだけでなくコンテキスト自体も、走査順序中の係数の絶対インデックスのみに依存する。

[0170] いくつかの例では、ビデオコーダ（たとえば、ビデオエンコーダ３２またはビデオデコーダ４２）は、ただ１つのタイプの走査（たとえば、対角走査）を実装するように構成され得る。しかしながら、ビデオコーダが評価する隣接領域は、ノミナル走査に基づき得る。ノミナル走査は、ビデオコーダが他の走査を実行することが可能であった場合にビデオコーダが実行したであろう走査である。たとえば、ビデオエンコーダ３２は、水平走査が使用されるべきであることをシグナリングし得る。しかしながら、ビデオデコーダ４２は、代わりに対角走査を実装し得るが、ビデオコーダが評価する隣接領域は、水平走査が使用されるべきであるというシグナリングに基づき得る。同様のことは、垂直走査のために適用されることになる。

[0171] いくつかの例では、ノミナル走査が水平走査である場合、ビデオコーダは、現在使用されている領域に対して水平方向に評価される隣接領域を伸ばし得る。同じことは、ノミナル走査が垂直走査であるときに適用されるであろう、しかし、垂直方向においてである。隣接領域を伸ばすことは、領域を変化させることと呼ばれることがある。たとえば、ノミナル走査が水平である場合、コーディングされている現在変換係数が位置するところから２行下にある変換係数を評価することではなく、ビデオコーダは、現在変換係数が位置するところから３列離れた変換係数を評価し得る。同様のことは、ノミナル走査が垂直走査であるとき、適用されることになるが、変換係数は、現在の変換係数（たとえば、コーディングされている変換係数）が位置するところから３行離れて位置することになる。

[0172] 図１２は、公称水平走査のためのコンテキスト近傍を示す概念図である。図１２に、４×４サブブロック１３６Ａ〜１３６Ｄを含む８×８ブロック１３４を示す。いくつかの他の技法におけるコンテキスト近傍と比較して、２行下の係数は、同じ行中にあるが３列離れた係数（Ｘ₄）によって置き換えられた。同様に、ノミナル走査が垂直である場合、垂直方向に伸ばされるコンテキスト近傍が使用され得る。

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

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

[0175] 命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明した技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。

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

[0177] 様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内である。

[0177] 様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ ビデオデータを復号するための方法であって、前記方法は、
コード化ビットストリームから、ブロックの変換係数の有意性フラグを受信することと、
前記ブロックの前記変換係数のための走査順序を判断することと、
前記判断された走査順序に基づいて前記ブロックの前記変換係数の前記有意性フラグのためのコンテキストを判断することと、
少なくとも前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）復号することとを備える、方法。
［Ｃ２］ 前記コンテキストを判断することが、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断することを備える、Ｃ１に記載の方法。
［Ｃ３］ 前記コンテキストを判断することは、
前記判断された走査順序が水平走査である場合および前記判断された走査順序が垂直走査である場合に同じである前記コンテキストを判断することと、
前記判断された走査順序が前記水平走査でなく前記垂直走査でない場合、前記判断された走査順序が前記水平走査である場合および前記判断された走査順序が前記垂直走査である場合の前記コンテキストとは異なる前記コンテキストを判断することと
を備える、Ｃ１に記載の方法。
［Ｃ４］ 前記判断された走査順序に基づいて前記ブロックの前記変換係数の前記有意性フラグのためのコンテキストを判断することは、前記走査順序が水平走査順序または垂直走査順序である場合の同じコンテキストを判断することを備える、Ｃ１に記載の方法。
［Ｃ５］ 前記コンテキストを判断することは、
前記走査順序が第１の走査順序である場合、前記有意性フラグのためのコンテキストの第１のセットを判断することと、
前記走査順序が第２の走査順序である場合、前記有意性フラグのためのコンテキストの第２のセットを判断することと
を備える、Ｃ１に記載の方法。
［Ｃ６］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査であり、前記第２の走査順序が垂直走査である場合、コンテキストの前記第２のセットと同じである、Ｃ５に記載の方法。
［Ｃ７］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査または垂直走査のうちの１つであり、前記第２の走査順序が前記水平走査でなく前記垂直走査でない場合、コンテキストの前記第２のセットとは異なる、Ｃ５に記載の方法。
［Ｃ８］ 前記コンテキストを判断することは、前記判断された走査順序に基づいて、および前記ブロックのサイズに基づいて、前記ブロックの前記変換係数の前記有意性フラグのための前記コンテキストを判断することを備える、Ｃ１に記載の方法。
［Ｃ９］ 前記ブロックのサイズが第１のサイズであるのか第２のサイズであるのかを判断すること
をさらに備え、
ここで、前記ブロックの前記サイズが前記第１のサイズである場合、前記コンテキストを判断することが、すべての走査順序について同じである前記コンテキストを判断することを備え、
ここで、前記ブロックの前記サイズが前記第２のサイズである場合、前記コンテキストを判断することが、少なくとも２つの異なる走査順序について異なる前記コンテキストを判断することを備える、Ｃ１に記載の方法。
［Ｃ１０］ 前記ブロックが変換係数の８×８ブロックを備える、Ｃ１に記載の方法。
［Ｃ１１］ ビデオデータを符号化するための方法であって、前記方法は、
ブロックの変換係数のための走査順序を判断することと、
前記判断された走査順序に基づいて前記ブロックの前記変換係数の有意性フラグのためのコンテキストを判断することと、
少なくとも前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）符号化することと、
コード化ビットストリーム中で前記符号化された有意性フラグをシグナリングすることと
を備える、方法。
［Ｃ１２］ 前記コンテキストを判断することが、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断することを備える、Ｃ１１に記載の方法。
［Ｃ１３］ 前記コンテキストを判断することは、
前記判断された走査順序が水平走査である場合および前記判断された走査順序が垂直走査である場合に同じである前記コンテキストを判断することと、
前記判断された走査順序が前記水平走査でなく前記垂直走査でない場合、前記判断された走査順序が前記水平走査である場合および前記判断された走査順序が前記垂直走査である場合の前記コンテキストとは異なる前記コンテキストを判断することと
を備える、Ｃ１１に記載の方法。
［Ｃ１４］ 前記判断された走査順序に基づいて前記ブロックの前記変換係数の前記有意性フラグのためのコンテキストを判断することは、前記走査順序が水平走査順序または垂直走査順序である場合の同じコンテキストを判断することを備える、Ｃ１１に記載の方法。
［Ｃ１５］ 前記コンテキストを判断することは、
前記走査順序が第１の走査順序である場合、前記有意性フラグのためのコンテキストの第１のセットを判断することと、
前記走査順序が第２の走査順序である場合、前記有意性フラグのためのコンテキストの第２のセットを判断することと
を備える、Ｃ１１に記載の方法。
［Ｃ１６］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査であり、前記第２の走査順序が垂直走査である場合、コンテキストの前記第２のセットと同じである、Ｃ１５に記載の方法。
［Ｃ１７］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査または垂直走査のうちの１つであり、前記第２の走査順序が前記水平走査でなく前記垂直走査でない場合、コンテキストの前記第２のセットとは異なる、Ｃ１５に記載の方法。
［Ｃ１８］ 前記コンテキストを判断することは、前記判断された走査順序に基づいて、および前記ブロックのサイズに基づいて、前記ブロックの前記変換係数の前記有意性フラグのための前記コンテキストを判断することを備える、Ｃ１１に記載の方法。
［Ｃ１９］ 前記ブロックが変換係数の８×８ブロックを備える、Ｃ１１に記載の方法。
［Ｃ２０］ ビデオデータをコーディングするための装置であって、前記装置が、
ブロックの変換係数のための走査順序を判断することと、
前記判断された走査順序に基づいて前記ブロックの前記変換係数の有意性フラグのためのコンテキストを判断することと、
少なくとも前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）コーディングすることとを行うように構成されたビデオコーダを備える、装置。
［Ｃ２１］ 前記ビデオコーダがビデオデコーダを備え、ここで、前記ビデオデコーダが、
コード化ビットストリームから、前記ブロックの前記変換係数の前記有意性フラグを受信することと、
前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをＣＡＢＡＣ復号することと
を行うように構成された、Ｃ２０に記載の装置。
［Ｃ２２］ 前記ビデオコーダがビデオエンコーダを備え、ここで、前記ビデオエンコーダが、
前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをＣＡＢＡＣ符号化することと、
コード化ビットストリーム中で、前記変換係数の前記有意性フラグをシグナリングすることと
を行うように構成された、Ｃ２０に記載の装置。
［Ｃ２３］ 前記コンテキストを判断するために、前記ビデオコーダが、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断するように構成された、Ｃ２０に記載の装置。
［Ｃ２４］ 前記コンテキストを判断するために、前記ビデオコーダは、
前記判断された走査順序が水平走査である場合および前記判断された走査順序が垂直走査である場合に同じである前記コンテキストを判断することと、
前記判断された走査順序が前記水平走査でなく前記垂直走査でない場合、前記判断された走査順序が前記水平走査である場合および前記判断された走査順序が前記垂直走査である場合の前記コンテキストとは異なる前記コンテキストを判断することと
を行うように構成された、Ｃ２０に記載の装置。
［Ｃ２５］ 前記判断された走査順序に基づいて前記ブロックの前記変換係数の前記有意性フラグのためのコンテキストを判断するために、前記ビデオコーダは、前記走査順序が水平走査順序または垂直走査順序である場合の同じコンテキストを判断するように構成された、Ｃ２０に記載の装置。
［Ｃ２６］ 前記コンテキストを判断するために、前記ビデオコーダは、
前記走査順序が第１の走査順序である場合、前記有意性フラグのためのコンテキストの第１のセットを判断することと、
前記走査順序が第２の走査順序である場合、前記有意性フラグのためのコンテキストの第２のセットを判断することと
を行うように構成された、Ｃ２０に記載の装置。
［Ｃ２７］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査であり、前記第２の走査順序が垂直走査である場合、コンテキストの前記第２のセットと同じである、Ｃ２６に記載の装置。
［Ｃ２８］ コンテキストの前記第１のセットは、前記第１の走査順序が水平走査または垂直走査のうちの１つであり、前記第２の走査順序が前記水平走査でなく前記垂直走査でない場合、コンテキストの前記第２のセットとは異なる、Ｃ２６に記載の装置。
［Ｃ２９］ 前記コンテキストを判断するために、前記ビデオコーダが、前記判断された走査順序に基づいて、および前記ブロックのサイズに基づいて、前記ブロックの前記変換係数の前記有意性フラグのための前記コンテキストを判断するように構成された、Ｃ２０に記載の装置。
［Ｃ３０］ 前記ビデオコーダは、
前記ブロックのサイズが第１のサイズであるのか第２のサイズであるのかを判断するように構成され、
ここで、前記ブロックの前記サイズが前記第１のサイズである場合、前記ビデオコーダが、すべての走査順序について同じである前記コンテキストを判断するように構成され、
ここで、前記ブロックの前記サイズが前記第２のサイズである場合、前記ビデオコーダが、少なくとも２つの異なる走査順序について異なる前記コンテキストを判断するように構成された、Ｃ２０に記載の装置。
［Ｃ３１］ 前記ブロックが変換係数の８×８ブロックを備える、Ｃ２０に記載の装置。
［Ｃ３２］ 前記装置が、
マイクロプロセッサと、
集積回路（ＩＣ）と、
前記ビデオコーダを含むワイヤレス通信デバイスと
のうちの１つを備える、Ｃ２０に記載の装置。
［Ｃ３３］ ビデオデータをコーディングするための装置であって、前記装置が、
ブロックの変換係数のための走査順序を判断するための手段と、
前記判断された走査順序に基づいて前記ブロックの前記変換係数の有意性フラグのためのコンテキストを判断するための手段と、
少なくとも前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）するための手段とを備える、装置。
［Ｃ３４］ 前記コンテキストを判断するための前記手段が、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断するための手段を備える、Ｃ３３に記載の装置。
［Ｃ３５］ 実行されたとき、ビデオデータをコーディングするための装置の１つまたは複数のプロセッサに、
ブロックの変換係数のための走査順序を判断することと、
前記判断された走査順序に基づいて前記ブロックの前記変換係数の有意性フラグのためのコンテキストを判断することと、
少なくとも前記判断されたコンテキストに基づいて前記変換係数の前記有意性フラグをコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）コーディングすることとを行わせる、その上に記憶された命令を有するコンピュータ可読記憶媒体。
［Ｃ３６］ 前記１つまたは複数のプロセッサに前記コンテキストを判断させる前記命令が、前記１つまたは複数のプロセッサに、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断させる命令を備える、Ｃ３５に記載のコンピュータ可読記憶媒体。

Claims (36)

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. 前記１つまたは複数のプロセッサに前記コンテキストを判断させる前記命令が、前記１つまたは複数のプロセッサに、前記ブロックのサイズと、前記ブロック内の前記変換係数の位置と、前記走査順序とに基づいて前記コンテキストを判断させる命令を備える、請求項３５に記載のコンピュータ可読記憶媒体。

Images