特許 5964448 コンテキスト適応型バイナリ算術コード化のためのコンテキスト削減

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5964448

(24)【登録日】2016年7月8日

(45)【発行日】2016年8月3日

(54)【発明の名称】コンテキスト適応型バイナリ算術コード化のためのコンテキスト削減

(51)【国際特許分類】

   H04N 19/13 20140101AFI20160721BHJP

   H04N 19/186 20140101ALI20160721BHJP

   H04N 19/60 20140101ALI20160721BHJP

   H04N 19/70 20140101ALI20160721BHJP

   H04N 19/91 20140101ALI20160721BHJP

   H04N 19/96 20140101ALI20160721BHJP

【ＦＩ】

   H04N19/13

   H04N19/186

   H04N19/60

   H04N19/70

   H04N19/91

   H04N19/96

【請求項の数】11

【全頁数】47

(21)【出願番号】特願2014-541071(P2014-541071)

(86)(22)【出願日】2012年10月5日

(65)【公表番号】特表2015-502076(P2015-502076A)

(43)【公表日】2015年1月19日

(86)【国際出願番号】US2012059100

(87)【国際公開番号】WO2013070355

(87)【国際公開日】20130516

【審査請求日】2014年7月24日

(31)【優先権主張番号】61/557,325

(32)【優先日】2011年11月8日

(33)【優先権主張国】US

(31)【優先権主張番号】61/561,911

(32)【優先日】2011年11月20日

(33)【優先権主張国】US

(31)【優先権主張番号】13/645,330

(32)【優先日】2012年10月4日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(72)【発明者】

【氏名】チェン、ウェイ―ジュン

(72)【発明者】

【氏名】ソル・ロジャルス、ジョエル

(72)【発明者】

【氏名】カークゼウィックズ、マルタ

【審査官】 久保 光宏

(56)【参考文献】

【文献】 Vivienne Sze，"BoG report on context reduction for CABAC"，[online]，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11，２０１１年 ７月２１日，Document: JCTVC-F746（version 4），[平成28年5月19日検索], インターネット，ＵＲＬ，http://phenix.it-sudparis.eu/jct/doc_end_user/documents/6_Torino/wg11/JCTVC-F746-v4.zip

【文献】 Wei-Jung Chien, et.al.，"Memory and Parsing Friendly CABAC Context"，[online]，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11，２０１１年 ７月２０日，Document: JCTVC-F606（version 3），[平成28年5月19日検索], インターネット，ＵＲＬ，http://phenix.it-sudparis.eu/jct/doc_end_user/documents/6_Torino/wg11/JCTVC-F606-v3.zip

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ１９／００−１９／９８，

ＣＳＤＢ（日本国特許庁），

ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）

(57)【特許請求の範囲】

【請求項1】

ビデオコーダがビデオデータを符号化する方法であって、
符号化されるべきビデオデータの１つのブロックに関連する変換単位の変換深度に基づいて２つ以上のコンテキストから１つのコンテキストを選択することと、前記変換深度が、変換コード化のために、ブロックへのコード化単位の現在細分レベルを指定する、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）及び選択された前記コンテキストを使用してビデオデータの前記ブロックのためのＣｂクロマコード化ブロックフラグを符号化することと、前記Ｃｂクロマコード化ブロックフラグを符号化することが、前記２つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグを符号化することと、前記Ｃｒクロマコード化ブロックフラグを符号化することが、前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、
を備えることを特徴とする、方法。

【請求項2】

ビデオデコーダがビデオデータを復号する方法であって、
復号されるべきビデオデータの１つのブロックに関連する変換単位の変換深度に基づいて２つ以上のコンテキストから１つのコンテキストを選択することと、前記変換深度が、変換コード化のために、ブロックへのコード化単位の現在細分レベルを指定する、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）及び選択された前記コンテキストを使用してビデオデータの前記ブロックのためのＣｂクロマコード化ブロックフラグを復号することと、前記Ｃｂクロマコード化ブロックフラグを復号することが、前記２つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグを復号することと、前記Ｃｒクロマコード化ブロックフラグを復号することが、前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、
を備えることを特徴とする、方法。

【請求項3】

前記コンテキストセットが５つのコンテキストを含むことを特徴とする、請求項１又は２に記載の方法。

【請求項4】

符号化ビデオビットストリーム中の符号化された前記Ｃｂクロマコード化ブロックフラグを信号伝達することと、
前記符号化ビデオビットストリーム中の符号化された前記Ｃｒクロマコード化ブロックフラグを信号伝達することと
を備えることを特徴とする、請求項１に記載の方法。

【請求項5】

符号化ビデオビットストリーム中の符号化された前記Ｃｂクロマコード化ブロックフラグを受信することと、
前記符号化ビデオビットストリーム中の符号化された前記Ｃｒクロマコード化ブロックフラグを受信することと
を備えることを特徴とする、請求項２に記載の方法。

【請求項6】

ビデオデータを符号化するように構成された装置であって、
符号化されるべきビデオデータの１つのブロックに関連する変換単位の変換深度に基づいて２つ以上のコンテキストから１つのコンテキストを選択するための手段と、前記変換深度が、変換コード化のために、ブロックへのコード化単位の現在細分レベルを指定する、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）及び選択された前記コンテキストを使用してビデオデータの前記ブロックのためのＣｂクロマコード化ブロックフラグを符号化するための手段と、前記Ｃｂクロマコード化ブロックフラグを符号化することが、前記２つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグを符号化するための手段と、前記Ｃｒクロマコード化ブロックフラグを符号化することが、前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、
を備えることを特徴とする、装置。

【請求項7】

ビデオデータを復号するように構成された装置であって、
復号されるべきビデオデータの１つのブロックに関連する変換単位の変換深度に基づいて２つ以上のコンテキストから１つのコンテキストを選択するための手段と、前記変換深度が、変換コード化のために、ブロックへのコード化単位の現在細分レベルを指定する、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）及び選択された前記コンテキストを使用してビデオデータの前記ブロックのためのＣｂクロマコード化ブロックフラグを復号するための手段と、前記Ｃｂクロマコード化ブロックフラグを復号することが、前記２つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグを復号するための手段と、前記Ｃｒクロマコード化ブロックフラグを復号することが、前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、
を備えることを特徴とする、装置。

【請求項8】

前記コンテキストセットが５つのコンテキストを含むという点で特徴付けられる、請求項６又は７に記載の装置。

【請求項9】

符号化ビデオビットストリーム中の符号化された前記Ｃｂクロマコード化ブロックフラグを信号伝達するための手段と、
前記符号化ビデオビットストリーム中の符号化された前記Ｃｒクロマコード化ブロックフラグを信号伝達するための手段と
を備えることを特徴とする、請求項６に記載の装置。

【請求項10】

符号化ビデオビットストリーム中の符号化された前記Ｃｂクロマコード化ブロックフラグを受信するための手段と、
前記符号化ビデオビットストリーム中の符号化された前記Ｃｒクロマコード化ブロックフラグを受信するための手段と
を備えることを特徴とする、請求項７に記載の装置。

【請求項11】

命令を記憶することによって特徴付けられるコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータを符号化又は復号するように構成された１つ以上のプロセッサに、請求項１乃至５のいずれか１項の方法を実行することを行わせる、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、どちらもそれぞれの全体が参照により本明細書に組み込まれる、２０１１年１１月８日に出願された米国仮出願第６１／５５７，３２５号、及び２０１１年１１月２０日に出願された米国仮出願第６１／５６１，９１１号の利益を主張する。

【0002】

本開示は、ビデオコード化に関し、より詳細には、ビデオコード化において使用されるコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ：context adaptive binary arithmetic coding）に関する。

【背景技術】

【0003】

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップ又はデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録機器、デジタルメディアプレーヤ、ビデオゲーム機器、ビデオゲームコンソール、セルラー又は衛星無線電話、所謂「スマートフォン」、ビデオ遠隔会議機器、ビデオストリーミング機器などを含む、広範囲にわたる機器に組み込まれ得る。デジタルビデオ機器は、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、現在開発中の高効率ビデオコード化（ＨＥＶＣ：High Efficiency Video Coding）規格によって定義された規格、及びそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。ビデオ機器は、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、及び／又は記憶し得る。

【0004】

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

【0005】

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

【発明の概要】

【0006】

概して、本開示では、ビデオコード化プロセスにおけるコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）のための技法について説明する。より詳細には、本開示は、非限定的な例として、ｐｒｅｄ＿ｔｙｐｅ、ｍｅｒｇｅ＿ｉｄｘ、ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇ、ｒｅｆ＿ｉｄｘ＿ｌｘ、ｃｂｆ＿ｃｂ、ｃｂｆ＿ｃｒ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、及びｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇを含む、１つ又は複数のシンタックス要素のために使用されるＣＡＢＡＣコンテキストの数の削減を提案する。その修正により、無視できるコード化効率の変化とともに、最高５６個のコンテキストを削減し得る。シンタックス要素のための提案するコンテキスト削減は、単独で、又は任意の組合せで使用され得る。

【0007】

本開示の一例では、ビデオを符号化する方法は、Ｐスライス中のビデオデータのブロックのための第１の予測タイプを決定することと、第１の予測タイプをＰスライス予測タイプシンタックス要素として表すことと、Ｂスライス中のビデオデータのブロックのための第２の予測タイプを決定することと、第２の予測タイプをＢスライス予測タイプシンタックス要素として表すことと、Ｐスライス予測タイプシンタックス要素のためのＰスライス２値化を決定することと、Ｂスライス予測タイプシンタックス要素のためのＢスライス２値化を決定することと、Ｐスライス予測タイプシンタックス要素とＢスライス予測タイプシンタックス要素とが同じ２値化論理を使用して決定される、Ｐスライス予測タイプシンタックス要素の２値化とＢスライス予測タイプシンタックス要素の２値化とに基づいてビデオデータを符号化することとを含み得る。

【0008】

本開示の別の例では、ビデオを復号する方法は、Ｐスライス中のビデオデータのブロックのための２値化マッピングを使用して、２値化されたＰスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、Ｂスライス中のビデオデータのブロックのための同じ２値化マッピングを使用して、２値化されたＢスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、マッピングされた予測タイプに基づいてビデオデータを復号することとを含み得る。

【0009】

本開示の別の例では、ビデオデータを符号化する方法は、ビデオデータのブロックのための予測モードのための区分タイプを決定することと、単一のコンテキストとともにＣＡＢＡＣを使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分タイプビンを符号化することでと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでＣＡＢＡＣを使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分サイズビンを符号化することとを備える。

【0010】

本開示の別の例では、ビデオデータを復号する方法は、ＣＡＢＡＣを使用してコード化されたビデオデータのブロックのための予測タイプシンタックス要素を受信することと、予測タイプシンタックス要素が、区分タイプを表す区分タイプビンと、区分サイズを表す区分サイズビンとを含む、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化を使用して、予測タイプシンタックス要素の区分タイプビンを復号することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでＣＡＢＡＣを使用して、予測タイプシンタックス要素の区分サイズビンを復号することと、を備える。

【0011】

本開示の別の例では、ビデオデータをコード化する方法は、ＣＡＢＡＣを使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、Ｃｂクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部として１つ又は複数のコンテキストを含むコンテキストセットを使用することを備える、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することと、Ｃｒクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部としてＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、を備える。

【0012】

本開示ではまた、上記の技法について、本技法を実行するように構成された装置に関して、ならびに、実行されたとき、１つ又は複数のプロセッサに本技法を実行させる命令を記憶するコンピュータ可読記憶媒体に関して説明する。

【0013】

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

【図面の簡単な説明】

【0014】

【図1】本開示で説明する技法を利用し得る例示的なビデオ符号化及び復号システムを示すブロック図。

【図2】本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図。

【図3】本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図。

【図4】方形区分タイプと非方形区分タイプの両方を示す概念図。

【図5】非対称区分タイプを示す概念図。

【図6】本開示の例示的なビデオ符号化方法を示すフローチャート。

【図7】本開示の例示的なビデオ復号方法を示すフローチャート。

【図8】本開示の例示的なビデオ符号化方法を示すフローチャート。

【図9】本開示の例示的なビデオ復号方法を示すフローチャート。

【図10】本開示の例示的なビデオコード化方法を示すフローチャート。

【発明を実施するための形態】

【0015】

本開示では、ビデオデータなどのデータをコード化するための技法について説明する。特に、本開示では、コンテキスト適応型エントロピーコード化プロセスを使用したビデオデータの効率的なコード化を促進し得る技法について説明する。より詳細には、本開示は、ｐｒｅｄ＿ｔｙｐｅ、ｍｅｒｇｅ＿ｉｄｘ、ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇ、ｒｅｆ＿ｉｄｘ＿ｌｘ、ｃｂｆ＿ｃｂ、ｃｂｆ＿ｃｒ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、及びｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇなど、シンタックス要素をコード化するために使用されるＣＡＢＡＣコンテキストの数の削減を提案する。その修正により、無視できるコード化効率の変化とともに、最高５６個のコンテキストを削減する。本開示では、説明のためにビデオコード化について説明する。但し、本開示で説明する技法は、他のタイプのデータをコード化することにも適用可能であり得る。

【0016】

図１は、本開示の例による、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）のための技法を利用するように構成され得る例示的なビデオ符号化及び復号システム１０を示すブロック図である。図１に示すように、システム１０は、通信チャネル１６を介して符号化ビデオを宛先機器１４に送信する発信源機器１２を含む。符号化ビデオデータはまた、記憶媒体３４又はファイルサーバ３６に記憶され得、必要に応じて宛先機器１４によってアクセスされ得る。記憶媒体又はファイルサーバに記憶されたとき、ビデオエンコーダ２０は、コード化ビデオデータを記憶媒体に記憶するための、ネットワークインターフェース、コンパクトディスク（ＣＤ）、Ｂｌｕ−ｒａｙ（登録商標）又はデジタルビデオディスク（ＤＶＤ）バーナー又はスタンピングファシリティ機器、若しくは他の機器など、別の機器にコード化ビデオデータを与え得る。同様に、ネットワークインターフェース、ＣＤ又はＤＶＤリーダーなど、ビデオデコーダ３０とは別個の機器が、記憶媒体からコード化ビデオデータを取り出し、取り出されたデータをビデオデコーダ３０に与え得る。

【0017】

発信源機器１２及び宛先機器１４は、デスクトップコンピュータ、ノートブック（即ち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、所謂スマートフォンなどの電話ハンドセット、テレビジョン、カメラ、表示装置、デジタルメディアプレーヤ、ビデオゲームコンソールなどを含む、多種多様な機器のいずれかを備え得る。多くの場合、そのような機器はワイヤレス通信が可能であり得る。従って、通信チャネル１６は、符号化ビデオデータの送信に好適なワイヤレスチャネル、ワイヤードチャネル、又はワイヤレスチャネルとワイヤードチャネルとの組合せを備え得る。同様に、ファイルサーバ３６は、インターネット接続を含む任意の標準データ接続を介して宛先機器１４によってアクセスされ得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデムなど）、又は両方の組合せを含み得る。

【0018】

本開示の例による、ＣＡＢＡＣのための技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、例えばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、又は他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコード化に適用され得る。幾つかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、及び／又はビデオテレフォニーなどの適用例をサポートするために、一方向又は双方向のビデオ送信をサポートするように構成され得る。

【0019】

図１の例では、発信源機器１２は、ビデオ発信源１８と、ビデオエンコーダ２０と、変調器／復調器２２と、送信機２４とを含む。発信源機器１２において、ビデオ発信源１８は、ビデオカメラなどの撮像装置、以前に撮影されたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、及び／又は発信源ビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどの発信源、若しくはそのような発信源の組合せを含み得る。一例として、ビデオ発信源１８がビデオカメラである場合、発信源機器１２及び宛先機器１４は、所謂カメラフォン又はビデオフォンを形成し得る。但し、本開示で説明する技法は、概してビデオコード化に適用可能であり得、ワイヤレス及び／又はワイヤード適用例、あるいは符号化ビデオデータがローカルディスクに記憶された適用例に適用され得る。

【0020】

撮影されたビデオ、以前に撮影されたビデオ、又はコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、ワイヤレス通信プロトコルなどの通信規格に従ってモデム２２によって変調され、送信機２４を介して宛先機器１４に送信され得る。モデム２２は、信号変調のために設計された様々なミキサ、フィルタ、増幅器又は他の構成要素を含み得る。送信機２４は、増幅器、フィルタ、及び１つ又は複数のアンテナを含む、データを送信するために設計された回路を含み得る。

【0021】

ビデオエンコーダ２０によって符号化された、撮影されたビデオ、以前に撮影されたビデオ、又はコンピュータ生成されたビデオはまた、後で消費するために記憶媒体３４又はファイルサーバ３６に記憶され得る。記憶媒体３４は、Ｂｌｕ−ｒａｙディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、又は符号化ビデオを記憶するための任意の他の好適なデジタル記憶媒体を含み得る。記憶媒体３４に記憶された符号化ビデオは、次いで、復号及び再生のために宛先機器１４によってアクセスされ得る。図１には示されていないが、幾つかの例では、記憶媒体３４及び／又はファイルサーバ３６は送信機２４の出力を記憶し得る。

【0022】

ファイルサーバ３６は、符号化ビデオを記憶すること、及びその符号化ビデオを宛先機器１４に送信することが可能な、任意のタイプのサーバであり得る。例示的なファイルサーバは、（例えば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）機器、ローカルディスクドライブ、又は、符号化されたビデオデータを記憶すること、及び符号化されたビデオデータを宛先機器に送信することが可能な任意の他のタイプの機器を含む。ファイルサーバ３６からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、又はその両方の組合せであり得る。ファイルサーバ３６は、インターネット接続を含む任意の標準的なデータ接続を通じて宛先機器１４によってアクセスされ得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適である、ワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデム、イーサネット（登録商標）、ＵＳＢなど）、又は両方の組合せを含み得る。

【0023】

宛先機器１４は、図１の例では、受信機２６と、モデム２８と、ビデオデコーダ３０と、表示装置３２とを含む。宛先機器１４の受信機２６は、チャネル１６を介して情報を受信し、モデム２８はその情報を復調して、ビデオデコーダ３０のために復調されたビットストリームを生成する。チャネル１６を介して通信される情報は、ビデオデータを復号する際にビデオデコーダ３０が使用する、ビデオエンコーダ２０によって生成された様々なシンタックス情報を含み得る。そのようなシンタックスはまた、記憶媒体３４又はファイルサーバ３６に記憶された符号化ビデオデータとともに含まれ得る。ビデオエンコーダ２０及びビデオデコーダ３０の各々は、ビデオデータを符号化又は復号することが可能であるそれぞれのエンコーダデコーダ（コーデック）の一部を形成し得る。

【0024】

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

【0025】

図１の例では、通信チャネル１６は、無線周波数（ＲＦ）スペクトルあるいは１つ又は複数の物理伝送線路など、任意のワイヤレス又はワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。通信チャネル１６は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信チャネル１６は、概して、ワイヤード媒体又はワイヤレス媒体の任意の好適な組合せを含む、ビデオデータを発信源機器１２から宛先機器１４に送信するのに好適な任意の通信媒体、又は様々な通信媒体の集合体を表す。通信チャネル１６は、発信源機器１２から宛先機器１４への通信を可能にするのに有用であり得るルータ、スイッチ、基地局、又は任意の他の機器を含み得る。

【0026】

ビデオエンコーダ２０及びビデオデコーダ３０は、ＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）のＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって現在開発中の高効率ビデオコード化（ＨＥＶＣ）規格及びＩＳＯ／ＩＥＣ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）などのビデオ圧縮規格に従って動作し得る。「ＨＥＶＣ Ｗｏｒｋｉｎｇ Ｄｒａｆｔ６」又は「ＷＤ６」と呼ばれる、ＨＥＶＣ規格の最近のドラフトは、２０１２年６月１日現在、http://phenix.int-evry.fr/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-H1003-v22.zipからダウンロード可能である、ドキュメントＪＣＴＶＣ−Ｈ１００３、Ｂｒｏｓｓら、「High efficiency video coding (HEVC) text specification draft 6」、Ｊｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ （ＪＣＴ−ＶＣ） ｏｆ ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３ ａｎｄ ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１、８ｔｈ Ｍｅｅｔｉｎｇ： Ｓａｎ Ｊｏｓｅ、Ｃａｌｉｆｏｒｎｉａ、ＵＳＡ、Ｆｅｂｒｕａｒｙ、２０１２に記載されている。

【0027】

代替的に、ビデオエンコーダ２０及びビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、他のプロプライエタリ規格又は業界規格、あるいはそのような規格の拡張に従って動作し得る。但し、本開示の技法は、いかなる特定のコード化規格にも限定されない。他の例としては、ＭＰＥＧ−２及びＩＴＵ−Ｔ Ｈ．２６３がある。

【0028】

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

【0029】

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

【0030】

ビデオエンコーダ２０は、ビデオコード化プロセスにおけるＣＡＢＡＣのための本開示の技法のいずれか又はすべてを実装し得る。同様に、ビデオデコーダ３０は、ビデオコード化プロセスにおけるＣＡＢＡＣのためのこれらの技法のいずれか又はすべてを実装し得る。本開示で説明するビデオコーダは、ビデオエンコーダ又はビデオデコーダを指し得る。同様に、ビデオコード化ユニットは、ビデオエンコーダ又はビデオデコーダを指し得る。同様に、ビデオコード化はビデオ符号化又はビデオ復号を指し得る。

【0031】

本開示の一例では、ビデオエンコーダ２０は、Ｐスライス中のビデオデータのブロックのための第１の予測タイプを決定することと、第１の予測タイプをＰスライス予測タイプシンタックス要素として表すことと、Ｂスライス中のビデオデータのブロックのための第２の予測タイプを決定することと、第２の予測タイプをＢスライス予測タイプシンタックス要素として表すことと、Ｐスライス予測タイプシンタックス要素のためのＰスライス２値化を決定することと、Ｂスライス予測タイプシンタックス要素のためのＢスライス２値化を決定することと、Ｐスライス予測タイプシンタックス要素とＢスライス予測タイプシンタックス要素とが同じ２値化論理を使用して決定される、Ｐスライス予測タイプシンタックス要素の２値化とＢスライス予測シンタックス要素の２値化とに基づいてビデオデータを符号化することとを行うように構成され得る。

【0032】

本開示の別の例では、ビデオデコーダ３０は、Ｐスライス中のビデオデータのブロックのための２値化マッピングを使用して、２値化されたＰスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、Ｂスライス中のビデオデータのブロックのための同じ２値化マッピングを使用して、２値化されたＢスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、マッピングされた予測タイプに基づいてビデオデータを復号することとを行うように構成され得る。

【0033】

本開示の別の例では、ビデオエンコーダ２０は、ビデオデータのブロックのための予測モードのための区分タイプを決定することと、単一のコンテキストとともにＣＡＢＡＣを使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分タイプビンを符号化することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでＣＡＢＡＣを使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分サイズビンを符号化することとを行うように構成され得る。

【0034】

本開示の別の例では、ビデオデコーダ３０は、ＣＡＢＡＣを使用してコード化されたビデオデータのブロックのための予測タイプシンタックス要素を受信することと、予測タイプシンタックス要素が、区分タイプを表す区分タイプビンと、区分サイズを表す区分サイズビンとを含む、単一のコンテキストとともにＣＡＢＡＣを使用して、予測タイプシンタックス要素の区分タイプビンを復号することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでＣＡＢＡＣを使用して、予測タイプシンタックス要素の区分サイズビンを復号することとを行うように構成され得る。

【0035】

本開示の別の例では、ビデオエンコーダ２０とビデオデコーダ３０の両方は、ＣＡＢＡＣを使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、Ｃｂクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部として１つ又は複数のコンテキストを含むコンテキストセットを使用することを備える、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することと、コード化することとを行うように構成され得、Ｃｒクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部としてＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える。

【0036】

ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコード化機器の発展的モデルに基づく。ＨＭは、例えば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣに従う既存の機器に対してビデオコード化機器の幾つかの追加の能力を仮定する。例えば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。以下のセクションでは、ＨＭの幾つかの態様についてより詳細に説明する。

【0037】

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

【0038】

ＣＵは、コード化ノードと、コード化ノードに関連する予測単位（ＰＵ：prediction unit）及び変換単位（ＴＵ：transform unit）とを含む。ＣＵのサイズは、概して、コード化ノードのサイズに対応し、一般に、形状が方形でなければならない。ＣＵのサイズは、８×８画素から最大６４×６４以上の画素をもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つ又は複数のＰＵと、１つ又は複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、例えば、ＣＵを１つ又は複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化又はダイレクトモード符号化されるか、イントラ予測モード符号化されるか、又はインター予測モード符号化されるかの間で異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、例えば、４分木に従って、ＣＵを１つ又は複数のＴＵに区分することも記述し得る。ＴＵは、形状が方形又は非方形であり得る。

【0039】

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

【0040】

概して、ＰＵは、予測プロセスに関係するデータを指す。例えば、ＰＵがイントラモード符号化されるとき、ＰＵは、ＰＵのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（例えば、１／４画素精度又は１／８画素精度）、動きベクトルが指す参照ピクチャ、及び／又は動きベクトルの参照ピクチャリスト（例えば、リスト０、リスト１、又はリストＣ）を記述し得る。

【0041】

概して、ＴＵは、変換プロセスと量子化プロセスとのために使用される。１つ又は複数のＰＵを有する所与のＣＵは、１つ又は複数の変換単位（ＴＵ）をも含み得る。予測に続いて、ビデオエンコーダ２０は、ＰＵに従ってコード化ノードによって識別されたビデオブロックから残差値を計算し得る。コード化ノードは、次いで、元のビデオブロックではなく、残差値を参照するように更新される。残差値は画素差分値を備え、画素差分値は、エントロピーコード化のためのシリアル化変換係数（serialized transform coefficient）を生成するためにＴＵ中で指定された変換及び他の変換情報を使用して変換係数に変換され、量子化され、走査され得る。コード化ノードは、これらのシリアル化変換係数を参照するように、もう一度更新され得る。本開示では、一般に、ＣＵのコード化ノードを指すために「ビデオブロック」という用語を使用する。幾つかの特定の場合において、本開示では、コード化ノードならびにＰＵ及びＴＵを含む、ツリーブロック、即ち、ＬＣＵ又はＣＵを指す「ビデオブロック」という用語も使用し得る。

【0042】

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

【0043】

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

【0044】

図４は、イントラ予測及びインター予測のための方形区分タイプと非方形区分タイプの両方を示す概念図である。区分１０２は、２Ｎ×２Ｎ区分であり、イントラ予測とインター予測の両方のために使用され得る。区分１０４は、Ｎ×Ｎ区分であり、イントラ予測とインター予測の両方のために使用され得る。区分１０６は、２Ｎ×Ｎ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。区分１０８は、Ｎ×２Ｎ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。

【0045】

図５は、非対称区分タイプを示す概念図である。区分１１０は、２Ｎ×ｎＵ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。区分１１２は、２Ｎ×ｎＤ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。区分１１４は、ｎＬ×２Ｎ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。区分１１６は、ｎＲ×２Ｎ区分であり、インター予測のためのＨＥＶＣにおいて現在使用されている。

【0046】

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

【0047】

ＣＵのＰＵを使用したイントラ予測コード化又はインター予測コード化の後、ビデオエンコーダ２０は、ＣＵのＴＵによって指定された変換が適用される残差データを計算し得る。残差データは、符号化されていないピクチャの画素と、ＣＵに対応する予測値との間の画素差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを形成し、次いで、残差データを変換して、変換係数を生成し得る。

【0048】

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

【0049】

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

【0050】

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

【0051】

本開示は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）エントロピーコーダ、又は確率間隔区分エントロピーコード化（ＰＩＰＥ）若しくは関係するコーダなど、他のエントロピーコーダのための関係する技法である。算術コード化は、シンボルを非整数長さコードワードにマッピングすることが可能であるので、高いコード化効率を有する多くの圧縮アルゴリズムにおいて使用されるエントロピーコード化の形態である。算術コード化アルゴリズムの一例は、Ｈ．２６４／ＡＶＣにおいて使用されるコンテキストベースバイナリ算術コード化（ＣＡＢＡＣ）である。

【0052】

概して、ＣＡＢＡＣを使用してデータシンボルをコード化することは、以下のステップのうちの１つ又は複数を伴う。

【0053】

（１）２値化。コード化されるべきシンボルが非２進値化された場合、そのシンボルは、所謂「ビン」のシーケンスにマッピングされる。各ビンは「０」又は「１」の値を有することができる。

【0054】

（２）コンテキスト割当て。（標準モードにおける）各ビンはコンテキストに割り当てられる。コンテキストモデルは、前に符号化されたシンボルの値又はビン数など、ビンについて利用可能な情報に基づいて所与のビンのコンテキストがどのように計算されるかを決定する。

【0055】

（３）ビン符号化。ビンは算術エンコーダを用いて符号化される。ビンを符号化するために、算術エンコーダは、入力として、ビンの値の確率、即ち、ビンの値が「０」に等しい確率と、ビンの値が「１」に等しい確率とを必要とする。各コンテキストの（推定された）確率は、「コンテキスト状態」と呼ばれる整数値によって表される。各コンテキストはある状態を有し、従って、その状態（即ち、推定された確率）は、１つのコンテキストに割り当てられたビンに対して同じであり、コンテキスト間で異なる。

【0056】

（４）状態更新。選択されたコンテキストの確率（状態）は、ビンの実際のコード化値に基づいて更新される（例えば、ビン値が「１」であった場合、「１」の確率が増加される）。

【0057】

確率間隔区分エントロピーコード化（ＰＩＰＥ）は、算術コード化の原理と同様の原理を使用し、従って、本開示の技法をも利用することができることに留意されたい。

【0058】

Ｈ．２６４／ＡＶＣ及びＨＥＶＣにおけるＣＡＢＡＣは状態を使用し、各状態は暗黙的に確率に関係する。シンボル（「０」又は「１」）の確率が直接使用される、即ち、確率（又はそれの整数バージョン）が状態である、ＣＡＢＡＣの変形態が存在する。例えば、ＣＡＢＡＣのそのような変形態は、以下において「ＪＣＴＶＣ−Ａ１１４」と呼ぶ、「Description of video coding technology proposal by France Telecom, NTT, NTT DOCOMO, Panasonic and Technicolor」、ＪＣＴＶＣ−Ａ１１４、１^st ＪＣＴ−ＶＣ Ｍｅｅｔｉｎｇ、Ｄｒｅｓｄｅｎ、ＤＥ、Ａｐｒｉｌ ２０１０、及び、以下において「ＪＣＴＶＣ−Ｆ２５４」と呼ぶ、Ａ． Ａｌｓｈｉｎ及びＥ． Ａｌｓｈｉｎａ、「Multi-parameter probability update for CABAC」、ＪＣＴＶＣ−Ｆ２５４、６^th ＪＣＴ−ＶＣ Ｍｅｅｔｉｎｇ、Ｔｏｒｉｎｏ、ＩＴ、Ｊｕｌｙ ２０１１に記載されている。

【0059】

本開示では、ＣＡＢＡＣにおいて使用される２値化及び／又はコンテキストの数の削減が提案される。特に、本開示は、ＣＡＢＡＣにおいて使用されるコンテキストの数を最高５６個だけ減じ得る技法を提案する。５６個少ないコンテキストの場合、実験結果は、それぞれ、高効率イントラ限定条件、ランダムアクセス条件及び低遅延テスト条件で、０．００％、０．０１％及び−０．１３％のビット歪み（ＢＤ：bit-distortion）レート変化を示す。従って、必要とされるコンテキストの数の削減により、コード化効率に実質的に影響を及ぼすことなしに、エンコーダとデコーダの両方における記憶部のニーズが低減する。

【0060】

本開示では、シンタックス要素、即ち、ｐｒｅｄ＿ｔｙｐｅ、ｍｅｒｇｅ＿ｉｄｘ、ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇ、ｒｅｆ＿ｉｄｘ＿ｌｘ、ｃｂｆ＿ｃｂ、ｃｂｆ＿ｃｒ、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、及びｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇのために使用されるＣＡＢＡＣコンテキストの数の削減が提案される。その修正により、無視できるコード化効率の変化とともに、最高５６個のコンテキストを削減する。上記のシンタックス要素のための提案するコンテキスト削減は、単独で、又は任意の組合せで使用され得る。

【0061】

シンタックス要素ｐｒｅｄ＿ｔｙｐｅは、各コード化単位のための予測モード（ｐｒｅｄ＿ｍｏｄｅ＿ｆｌａｇ）と区分タイプ（ｐａｒｔ＿ｍｏｄｅ）とを含む。０に等しいシンタックス要素ｐｒｅｄ＿ｍｏｄｅ＿ｆｌａｇは、現在コード化単位がインター予測モードでコード化されることを指定する。１に等しいシンタックス要素ｐｒｅｄ＿ｍｏｄｅ＿ｆｌａｇは、現在コード化ユニットがイントラ予測モードでコード化されることを指定する。シンタックス要素ｐａｒｔ＿ｍｏｄｅは、現在コード化単位の区分モードを指定する。

【0062】

シンタックス要素ｍｅｒｇｅ＿ｉｄｘ［ｘ０］［ｙ０］は、マージ候補リストのマージ候補インデックスを指定し、ｘ０、ｙ０は、ピクチャの左上ルーマサンプルに対する当該の予測ブロックの左上ルーマサンプルの位置（ｘ０，ｙ０）を指定する。ｍｅｒｇｅ＿ｉｄｘ［ｘ０］［ｙ０］が存在しないとき、０に等しいことが推論される。マージ候補リストは、動き情報がそこからコピーされ得る現在単位に隣接するコード化単位のリストである。

【0063】

シンタックス要素ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇ［ｘ０］［ｙ０］は、現在予測単位に単予測が使用されるのか、双予測が使用されるのかを指定する。アレイインデックスｘ０、ｙ０は、ピクチャの左上ルーマサンプルに対する当該予測ブロックの左上ルーマサンプルの位置（ｘ０，ｙ０）を指定する。

【0064】

シンタックス要素ｒｅｆ＿ｉｄｘ＿ｌｘは、参照ピクチャリスト内の特定の参照ピクチャを指す。

【0065】

シンタックス要素ｃｂｆ＿ｃｂ、ｃｂｆ＿ｃｒは、クロマ（それぞれ、Ｃｂ及びＣｒ）変換ブロックが非０変換係数を含んでいるか否かを示す。１に等しいシンタックス要素ｃｂｆ＿ｃｂ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］は、Ｃｂ変換ブロックが０に等しくない１つ又は複数の変換係数レベルを含んでいることを指定する。アレイインデックスｘ０、ｙ０は、ピクチャの左上ルーマサンプルに対する当該変換ブロックの左上ルーマサンプルの位置（ｘ０，ｙ０）を指定する。アレイインデックスｔｒａｆｏＤｅｐｔｈは、変換コード化のために、ブロックへのコード化ユニットの現在細分レベルを指定する。アレイインデックスｔｒａｆｏＤｅｐｔｈは、コード化ユニットに対応するブロックについて０に等しい。ｃｂｆ＿ｃｂ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］が存在せず、予測モードがイントラ予測でないとき、ｃｂｆ＿ｃｂ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］の値は０に等しいことが推論される。

【0066】

１に等しいシンタックス要素ｃｂｆ＿ｃｒ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］は、Ｃｒ変換ブロックが０に等しくない１つ又は複数の変換係数レベルを含んでいることを指定する。アレイインデックスｘ０、ｙ０は、ピクチャの左上ルーマサンプルに対する当該変換ブロックの左上ルーマサンプルの位置（ｘ０，ｙ０）を指定する。アレイインデックスｔｒａｆｏＤｅｐｔｈは、変換コード化のために、ブロックへのコード化単位の現在細分レベルを指定する。アレイインデックスｔｒａｆｏＤｅｐｔｈは、コード化単位に対応するブロックについて０に等しい。ｃｂｆ＿ｃｒ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］が存在せず、予測モードがイントラ予測でないとき、ｃｂｆ＿ｃｒ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］の値は０に等しいことが推論される。

【0067】

シンタックス要素ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ［ｎ］は、走査位置ｎについて、１よりも大きい変換係数レベルがあるかどうかを指定する。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ［ｎ］が存在しないとき、０に等しいことが推論される。

【0068】

シンタックス要素ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇ［ｎ］は、走査位置ｎについて、２よりも大きい変換係数レベルがあるかどうかを指定する。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇ［ｎ］が存在しないとき、０に等しいことが推論される。

【0069】

ＨＥＶＣについての１つの提案では、表１に示すように、ＰスライスとＢスライスとにおいて、シンタックス要素ｐｒｅｄ＿ｔｙｐｅに対する異なる２値化が使用される。本開示は、ＰスライスとＢスライスとについて同じ２値化を使用することを提案する。例を表２〜表４に示す。表５に、共通テスト条件（例えば、Ｆ．Ｂｏｓｓｅｎ、「Common test conditions and software reference configurations」、ＪＣＴＶＣ―Ｆ９００参照）の下での、Ｐスライスへのコード化性能の影響を示す。

【表1】

【0070】

表１でわかるように、Ｉスライス（例えば、イントラ予測されたブロックのみを含むスライス）は、２つの異なる予測タイプ（ｐｒｅｄ＿ｔｙｐｅ）を含む。１つのビンストリング（２値化）は、２Ｎ×２Ｎ区分タイプをもつイントラ予測されたブロックのために使用され、別のビンストリングは、Ｎ×Ｎ区分タイプをもつイントラ予測されたブロックのために使用される。表１に示すように、Ｉスライスのために使用されるビンストリングは、ＣＵサイズに依存しない。

【0071】

Ｐスライス及びＢスライスの場合、表１では、ｐｒｅｄ＿ｔｙｐｅの各値について異なるビンストリングが使用される。この場合も、ｐｒｅｄ＿ｔｙｐｅの値は、予測モード（インター予測又はイントラ予測）と、使用される区分タイプの両方に依存する。Ｐスライス及びＢスライスの場合、使用される実際のビンストリングは更に、コード化されているＣＵのサイズと、インター予測が４×４ブロックサイズについて使用可能であるか否かとに依存する。

【0072】

コード化されているＣＵのＣＵサイズの対数関数が最小許容ＣＵサイズの対数関数よりも大きい状況では、ビンストリングの下の１列目が適用される。ＨＥＶＣにおける一例によれば、ｃＬｏｇ２ＣＵＳｉｚｅ＞Ｌｏｇ２ＭｉｎＣＵｓｉｚｅの場合、ビンストリングの１列目が使用される。対数関数は、より小さい連続するインデックスが使用され得るように、より小さい数を作成するために使用される。

【0073】

コード化されているＣＵのＣＵサイズの対数関数が、最小許容ＣＵサイズの対数関数に等しい場合（即ち、ｃＬｏｇ２ＣＵＳｉｚｅ＝＝Ｌｏｇ２ＭｉｎＣＵＳｉｚｅ）、２値化を選択するために、表１のビンストリングの下の列２及び列３のうちの１つが使用される。コード化されているＣＵのＣＵサイズの対数関数が３に等しく、４×４ＣＵについてインター予測が使用可能でないとき（即ち、ｃＬｏｇ２ＣＵＳｉｚｅ＝＝３＆＆！ｉｎｔｅｒ＿４ｘ４＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、列２が使用される。コード化されているＣＵのＣＵサイズの対数関数が３よりも大きいとき、又は４×４ＣＵについてインター予測が使用可能であるとき（即ち、ｃＬｏｇ２ＣＵＳｉｚｅ＞３｜｜ｉｎｔｅｒ＿４ｘ４＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、列３が使用される。

【0074】

以下の表２は、本開示で説明する１つ又は複数の例による、ＰスライスとＢスライスとが同じビンストリングを使用する例示的な２値化を示す。表２に示すように、Ｐスライスは、表１中のＢスライスのために使用されるものと同じ２値化を使用する。このようにして、ＰスライスとＢスライスの両方についてコンテキストの別のセットを記憶し、使用する必要がない。従って、ｐｒｅｄ＿ｔｙｐｅシンタックス要素をコード化するために必要なコンテキストの総数が削減される。更に、ビンストリング論理（列（１）〜（３）に示す）と実際のビンストリングとの間の（２つではなく）１つのマッピングのみが記憶される必要がある。

【表2】

【0075】

以下の表３は、ｐｒｅｄ＿ｔｙｐｅについての２値化の別の例を示す。この例では、Ｂスライスは、表１によるＰスライスと同じ２値化を使用する。以下の表４は、ＰスライスとＢスライスとが同じ２値化を使用する追加の例を示す。表２〜表４は、ＰスライスとＢスライスとの間の共有２値化の例を示すことのみを意図している。ＰスライスとＢスライスの両方についてのｐｒｅｄ＿ｔｙｐｅシンタックス要素が同じ２値化を共有するように、任意の２値化又は２値化ルールが使用され得る。

【0076】

ビデオエンコーダ２０及びビデオデコーダ３０は、ＰスライスとＢスライスの両方で使用する同じマッピングルール及びマッピングテーブル（例えば、表２〜表４に示す）を記憶し得る。ＣＡＢＡＣ符号化及び復号は、これらのマッピングを使用するｐｒｅｄ＿ｔｙｐｅシンタックス要素に適用され得る。

【0077】

このようにして、ビデオエンコーダ２０は、Ｐスライス中のビデオデータのブロックのための第１の予測タイプを決定することと、第１の予測タイプをＰスライス予測タイプシンタックス要素として表すことと、Ｂスライス中のビデオデータのブロックのための第２の予測タイプを決定することと、第２の予測タイプをＢスライス予測タイプシンタックス要素として表すことと、Ｐスライス予測タイプシンタックス要素のためのＰスライス２値化を決定することと、Ｂスライス予測タイプシンタックス要素のためのＢスライス２値化を決定することと、Ｐスライス予測タイプシンタックス要素とＢスライス予測タイプシンタックス要素とが同じ２値化論理を使用して決定される、Ｐスライス予測タイプシンタックス要素の２値化とＢスライス予測シンタックス要素の２値化とに基づいてビデオデータを符号化することとを行うように構成され得る。

【0078】

ビデオエンコーダ２０は、決定されたＰスライス２値化を用いてＰスライス予測タイプシンタックス要素を２値化することと、決定されたＢスライス２値化を用いてＢスライス予測タイプシンタックス要素を２値化することと、２値化されたＰスライス予測タイプシンタックス要素にコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を適用することと、２値化されたＢスライス予測タイプシンタックス要素にコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を適用することとを行うように更に構成され得る。

【0079】

同様に、ビデオデコーダ３０は、Ｐスライス中のビデオデータのブロックのための２値化マッピングを使用して、２値化されたＰスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、Ｂスライス中のビデオデータのブロックのための同じ２値化マッピングを使用して、２値化されたＢスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、マッピングされた予測タイプに基づいてビデオデータを復号することとを行うように構成され得る。

【0080】

ビデオデコーダ３０は、Ｐスライス中のビデオデータのブロックのための予測タイプを示すコンテキスト適応型バイナリ算術コード化Ｐスライス予測タイプシンタックス要素を受信することと、Ｂスライス中のビデオデータのブロックのための予測タイプを示すコンテキスト適応型バイナリ算術コード化Ｂスライス予測タイプシンタックス要素を受信することと、２値化されたＰスライス予測タイプシンタックス要素を生成するためにＰスライス予測タイプシンタックス要素を復号することと、２値化されたＢスライス予測タイプシンタックス要素を生成するためにＢスライス予測タイプシンタックス要素を復号することとを行うように更に構成され得る。

【表3】

【表4】

【0081】

以下の表５は、表２に示すＰスライスとＢスライスとについて共有２値化を使用するコード化性能を示す。表５でわかるように、共有２値化を使用してもコード化効率は殆んど失われない。低遅延Ｐ ＨＥ（高効率）が、単方向予測された（Ｐ）スライス２値化についての共通テスト条件である。クラスＡ〜Ｅは、異なるフレーム解像度を表す。クラスＡは２ｋ×４ｋ解像度である。クラスＢは１９２０×１０８０解像度である。クラスＣはＷＶＧＡ解像度である。クラスＤはＷＱＶＧＡ解像度である。クラスＥは７２０Ｐ解像度である。低遅延Ｐ ＨＥテスト条件における０．１〜０．２パーセントの変化は、概して、有意でないと見なされる。

【表5】

【0082】

場合によっては、予測タイプ（予測サイズ及び／又は予測モードを含む）のための同じ２値化（表２〜表４に限定されない）が、２つ以上の異なるタイプのインター予測スライスにおいて共有され得る。インター予測スライスは、限定はしないが、以下を含み得る。

【0083】

ａ．Ｐスライス：スライスは単方向動き予測のみをサポートする
ｂ．Ｂスライス：スライスは単方向動き予測と双方向動き予測とをサポートする
ｃ．スケーラブルビデオコード化の場合：エンハンスメントレイヤがベースレイヤと同じ２値化を共有することができる。

【0084】

ｄ．マルチビューコード化の場合：異なるビューが同じ２値化を共有し得る。

【0085】

非対称区分が使用可能であるとき、非対称区分（即ち、ＰＡＲＴ＿２ＮｘｎＵ、ＰＡＲＴ＿２ＮｘｎＤ、ＰＡＲＴ＿ｎＬｘ２Ｎ、ＰＡＲＴ＿ｎＲｘ２Ｎ）のためのｐｒｅｄ＿ｔｙｐｅシンタックス要素を信号伝達するための最後の２つのビンに対するＣＡＢＡＣのために、２つのコンテキストセットに等しく分割された４つのコンテキストが使用される。区分が水平方向に沿って分割されるのか、垂直方向に沿って分割されるのかに応じて、１つのコンテキストセットが適用される。最後から２つ目のビン（即ち、区分タイプビン、ｐａｒｔ＿ｍｏｄｅ）は、現在ＣＵが対称区分を有するのか、非対称区分を有するのかを指定する。最後のビン（即ち、区分サイズビン、ｐａｒｔ＿ｍｏｄｅ）は、第１の区分のサイズがＣＵサイズの１／４であるのか、３／４であるのかを指定する。表６に、ｐｒｅｄ＿ｔｙｐｅシンタックス要素の最後から２つ目（区分タイプ）及び最後（区分サイズ）のためのコンテキストの一例を示す。

【表6】

【0086】

本開示は、最後から２つ目のビン（即ち、区分タイプビン）について１つのコンテキストを使用し、最後のビン（即ち、区分サイズビン）に対してバイパスモードを使用することを提案する。その結果、コンテキストの数は４から１に削減される。図７に、本開示の本例に従って使用されるコンテキストの一例を示す。表８に、提案する変更に関連するコード化性能を示す。ランダムアクセス高効率（ＨＥ）は、ランダムアクセスフレームの場合のテスト条件である。低遅延Ｂ ＨＥは、双方向予測を可能にするテスト条件である。

【表7】

【表8】

【0087】

このようにして、本例によれば、ビデオエンコーダ２０は、ビデオデータのブロックのための予測モードのための区分タイプを決定することと、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分タイプビンを符号化することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックスの区分サイズビンを符号化することとを行うように構成され得る。

【0088】

同様に、本例によれば、ビデオデコーダ３０は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してコード化されたビデオデータのブロックのための予測タイプシンタックス要素を受信することと、予測タイプシンタックス要素が、区分タイプを表す区分タイプビンと、区分サイズを表す区分サイズビンとを含む、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化を使用して、予測タイプシンタックス要素の区分タイプビンを復号することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックスの区分サイズビンを復号することとを行うように構成され得る。

【0089】

別の例では、矩形区分タイプをコード化するときに、バイパスモード又は単一のコンテキストは、区分モードがＰＡＲＴ＿ｎＬｘ２ＮｏｒＰＡＲＴ＿ｎＲｘ２Ｎであるかどうか、又は、モードがＰＡＲＴ＿２ＮｘｎＵ，ＰＡＲＴ＿２ＮｘｎＤであるかどうかを示すビンのために使用され得る。いずれかの区分モードが使用される見込みが５０％に近いので、バイパスモード又は単一のコンテキストを使用することは適用可能である。また場合によっては、バイパスモード又は単一のコンテキストは、モードが対称区分であるのか、非対称区分であるのかを示すビンのために使用され得る。

【0090】

本開示の次の例は、インター予測の「マージ」モードにおける信号伝達に関係する。マージモードでは、エンコーダは、コード化されるべきピクチャの現在部分のための選択された候補動きベクトルから、動きベクトルと、（所与の参照ピクチャリストにおいて動きベクトルがポイントする参照フレームを識別する）参照インデックスと、（即ち、参照フレームが時間的に現在フレームに先行するか又は後続するかに関して、参照ピクチャリスト（リスト０又はリスト１）を識別する）動き予測方向とをコピーするように、予測シンタックスのビットストリーム信号伝達を通してデコーダに命令する。これは、選択された候補動きベクトル（即ち、特定の空間動きベクトル予測子（ＭＶＰ：motion vector predictor）候補又は時間ＭＶＰ候補）を識別する候補動きベクトルリストへのインデックスをビットストリーム中で信号伝達(signaling)することによって達成される。

【0091】

従って、マージモードでは、予測シンタックスは、モード（この場合は「マージ」モード）を識別するフラグと、選択された候補動きベクトルを識別するインデックス（ｍｅｒｇｅ＿ｉｄｘ）とを含み得る。幾つかの事例では、候補動きベクトルは、現在部分に関する因果的部分中にあることになる。即ち、候補動きベクトルは、デコーダによってすでに復号されていることになる。従って、デコーダは、因果的部分のための動きベクトルと参照インデックスと動き予測方向とをすでに受信及び／又は決定している。従って、デコーダは、単に、メモリから、因果的部分に関連する動きベクトルと参照インデックスと動き予測方向とを取り出し、これらの値を現在部分についての動き情報としてコピーし得る。マージモードでブロックを再構成するために、デコーダは、現在部分についての導出された動き情報を使用して予測ブロックを取得し、予測ブロックに残差データを加算してコード化ブロックを再構成する。

【0092】

ＨＭ４．０では、現在ＰＵがマージモードにあるとき、５つのマージ候補のうちの１つが信号伝達される。シンタックス要素ｍｅｒｇｅ＿ｉｄｘを表すために、短縮単項コード（truncated unary code）が利用される。ＨＥＶＣのための１つの提案では、ＣＡＢＡＣの場合、各ビンは１つコンテキストを使用する。表９に示すように、本開示は、すべての４つのビンにおいて１つのコンテキストを繰り返し使用することを提案する。

【表9】

【0093】

表１０に、本例に関連するコード化性能を示す。

【表10】

【0094】

場合によっては、マージインデックスコード化では、２つ以上のコンテキストが使用され得、幾つかのビンが同じコンテキストを共有し、幾つかのビンが他のコンテキストを使用する。一例として、連続するビンのみが同じコンテキストを共有する。例えば、ビン２とビン３とが１つのコンテキストを共有することができ、ビン２とビン４とは、ビン３もコンテキストを共有していない限り、同じコンテキストを共有することができない。

【0095】

別の例として、マージインデックスのビンの総数がＮ個であると仮定する（第１のビンはビン０であり、最後のビンはビンＮ−１である）。Ｙ個のしきい値ｔｈｒｅｓ_i、ｉ＝１，．．．，ｙは、マージインデックスコード化におけるコンテキスト共有を決定するために使用される。この例では、以下のルールは、コンテキストがどのようにビン間で共有されるかを示す。

【数1】

【0096】

これらのルールに基づいて、すべての４つのビンにおいて１つのコンテキストが繰り返し使用される前の方法が、Ｎ＝４、Ｙ＝１、ｔｈｒｅｓ₁＝４である１つの事例として考えられ得る。従って、ビン０〜ビン３は同じコンテキストを共有している。

【0097】

別の例は、設定Ｎ＝４、Ｙ＝２、ｔｈｒｅｓ₁＝２、ｔｈｒｅｓ₂＝４を含む。この例では、ビン０とビン１とは同じコンテキストを共有し、ビン２とビン３とは同じコンテキストを共有する。

【0098】

インター予測フラグ（ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇ）は、現在ＰＵのために単予測が使用されるのか、双予測が使用されるのかを指定する。幾つかの例では、インター予測フラグのためのコンテキストインデックスは現在ＣＵ深度に等しい。４つの可能なＣＵ深度（０〜３）があるので、ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇをコード化するための４つの可能なコンテキストがある。

【0099】

本開示は、ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇをコード化するためのコンテキストを選択するために使用されるコンテキストインデックスは、現在ＣＵ深度（例えば、ＣＵのためのレベル４分木分解）に等しいが、選定されたしきい値でキャッピングされる（即ち、現在ＣＵ深度又はしきい値のより小さい方である）ことを提案する。しきい値は、一例では、２であると選定され得る。代替として、コンテキストインデックスは、最大ＣＵ深度から現在ＣＵ深度を引いたものに等しく、選定されたしきい値でキャッピングされ得る。代替として、予め定義されたマッピングテーブルが、所与のＣＵ深度によってコンテキストインデックスを選択するように設計され得る。マッピングテーブルは論理のセットとして実装され得る。その結果、シンタックス要素ｉｎｔｅｒ＿ｐｒｅｄ＿ｆｌａｇをコード化するために、３つのコンテキストが使用される。

【0100】

表１１に、初期化テーブルは変更されたがコンテキストの数は変更されないときのコード化性能を示す。表１２に、コンテキストの数を４から３に削減する提案する技法のコード化性能を示す。

【表11】

【表12】

【0101】

参照フレームインデックス（ｒｅｆ＿ｉｄｘ＿ｌｘ）は、関連するリスト（例えば、リスト０又はリスト１）中のアクティブ参照フレームに関して短縮単項コードを使用することによって信号伝達される。参照フレームインデックスをコード化するために、３つのコンテキストが使用される。１つのコンテキストがビン０のために、１つコンテキストがビン１のために、及び１つコンテキストが、残りのビンに対して使用される。表１３に、ｒｅｆ＿ｉｄｘ＿ｌｘのための単項コードのビンのためのコンテキスト割当ての一例を示す。

【表13】

【0102】

本開示は、ｒｅｆ＿ｉｄｘ＿ｌｘのための単項コードをコード化するために２つのコンテキスト、即ち、１つのコンテキストをビン０に対して、もう１つのコンテキストを残りのビンに対して使用することを提案する。表１４に、本開示の本例によるｒｅｆ＿ｉｄｘ＿ｌｘのための単項コードのビンのためのコンテキスト割当ての一例を示す。表１５に、提案する変更に関連するコード化性能を示す。

【表14】

【表15】

【0103】

クロマコード化ブロックフラグシンタックス要素（ｃｂｆ＿ｃｂ及びｃｂｆ＿ｃｒ）の場合、ＣＡＢＡＣのために、２つの異なるコンテキストセット（各コンテキストセット中に５つのコンテキスト）が使用される。各セットにおいて使用される実際のコンテキストのインデックスは、コード化されているクロマコード化ブロックフラグに関連する現在変換深度に等しい。表１６に、ｃｂｆ＿ｃｂ及びｃｂｆ＿ｃｒクロマコード化ブロックフラグのためのコンテキストセットを示す。

【表16】

【0104】

本開示は、ｃｂｆ＿ｃｂ及びｃｂｆ＿ｃｒが１つのコンテキストセットを共有することを提案する。各セットにおいて使用される実際のコンテキストのインデックスは、依然として、コード化されているクロマコード化ブロックフラグに関連する現在変換深度に等しくなり得る。表１７に、本開示の例によるｃｂｆ＿ｃｂ及びｃｂｆ＿ｃｒクロマコード化ブロックフラグのためのコンテキストセットを示す。表１８に、提案する変更に関連するコード化性能を示す。

【表17】

【表18】

【0105】

このようにして、本例によれば、ビデオエンコーダ２０とビデオデコーダ３０の両方は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、ＣＡＢＡＣが１つ又は複数のコンテキストを含むコンテキストセットを使用する、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することとを行うように構成され得、ＣＡＢＡＣがＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用する。ビデオエンコーダ２０及びビデオデコーダ３０は、ビデオデータのブロックに関連する変換ユニットの変換深度に基づいて１つ又は複数のコンテキストからコンテキストを選択するように更に構成され得る。

【0106】

ＨＥＶＣのための１つの提案では、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇとｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇの両方のための１２個のコンテキストセットがある。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇは、変換係数が１よりも大きい絶対値を有するかどうかを示す。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇは、変換係数が２よりも大きい絶対値を有するかどうかを示す。コンテキストセットは、ルーマ成分とクロマ成分とに対して等しく割り当てられ、即ち、ルーマのために６つのコンテキストセット及びクロマのために６つのコンテキストセットが割り当てられる。各コンテキストセットは５つのコンテキストからなる。コンテキストセットのインデックスｃｔｘＳｅｔは、前のｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇに基づいて選択される。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇの場合、コンテキストセット内のコンテキストのインデックスｇｒｅａｔｅｒ１Ｃｔｘは、最大４までのトレーリング１（trailing ones）に基づいて決定される。コンテキストインデックスは次のように表され得る。

【数2】

【0107】

ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇの場合、コンテキストセット内のコンテキストのインデックスｇｒｅａｔｅｒ２Ｃｔｘは、１から最大４までのｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇの数に基づく。コンテキストインデックスは次のように表され得る。

【数3】

【0108】

ｇｒｅａｔｅｒ１Ｃｔｘは、有意係数の数と１よりも大きい係数の数に基づく。一方、ｇｒｅａｔｅｒ２Ｃｔｘは、１よりも大きい係数の数に基づく。

【0109】

幾つかの例では、異なる数のコンテキストが、例えば、以下を含む異なるコンテキストセット中で使用され得る。

【0110】

１．１よりも大きいレベル又は２よりも大きいレベルのためのコンテキストセットは、異なる数のコンテキストを有することができる。例えば、コンテキストセット０及び３は５つのコンテキストを有することができ、残りのコンテキストセットは２つのコンテキストを有することができる。

【0111】

２．ルーマ係数のためのコンテキストセットは、クロマ成分のためのコンテキストセットと比較して異なる数のコンテキストを有することができる。例えば、ルーマのためのコンテキストセット０は５つのコンテキストを有することができ、クロマのためのコンテキストセット０は４つのコンテキストを有することができる。

【0112】

３．１よりも大きいレベルのためのコンテキストセットは、２よりも大きいレベルのためのコンテキストセットとは異なるコンテキスト数を有することができる。例えば、１よりも大きいレベルのためのコンテキストセット０は、５つのコンテキストを有することができ、２よりも大きいレベルのためのコンテキストセット０は、３つのコンテキストのみを有することができる。

【0113】

他の例では、例えば、以下を含む、１よりも大きい又は２よりも大きいコード化のために、コンテキストセットについて異なる数が使用され得る。

【0114】

１．ルーマ係数のためのコンテキストセットは、クロマ成分のために使用されるコンテキストセットと異なる数のコンテキストを有することができる。例えば、ルーマは６つのコンテキストを使用することができ、クロマは４つのコンテキストを使用することができる。

【0115】

２．１よりも大きいコンテキストセットは、２よりも大きい使用されるコンテキストセットと異なる数のコンテキストセットを有することができる。例えば、１よりも大きいコンテキストセットは、６つのコンテキストを使用することができ、２よりも大きいコンテキストセットは、４つのコンテキストを使用することができる。

【0116】

場合によっては、コンテキストセット中のどのコンテキストが使用されているのかを決定するためにメトリックが使用され、メトリックの値の範囲はコンテキストセット中のコンテキストについての数よりも大きい。１つのそのような態様では、１つのコンテキストは、メトリックの１つ又は複数の値に関連することができる。コンテキスト共有は、好ましくは連続値に限定される。例えば、メトリックの値をｙであるとする。ｙ＝２はコンテキスト３に関連し、ｙ＝１及びｙ＝４もコンテキスト３に関連することができる。但し、ｙ＝３がコンテキスト４に関連する場合、ｙ＝４はコンテキスト３に関連することができない。

【0117】

例えば、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇの場合、コンテキストセット０及び３は５つのコンテキストを有し、コンテキストセット１、２、４及び５は２つのコンテキストを有する。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇの場合、コンテキストセット０、１、及び２は５つのコンテキストを有し、コンテキストセット３、４、及び５は２つのコンテキストを有する。以下のように表すことができる。

【数4】

【0118】

Ｔｈｒｅｓ＿ｇｒｅａｔｅｒ１とＴｈｒｅｓ＿ｇｒｅａｔｅｒ２とは、以下の状況に基づいて別様に選定され得る。

【0119】

１．ルーマ成分又はクロマ成分
２．コンテキストセット
別の例として、ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇの場合、コンテキストセット０及び３は５つのコンテキストを有し、コンテキストセット１、２、４及び５は３つのコンテキストを有する。ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇの場合、コンテキストセット０、１、及び２は５つのコンテキストを有し、コンテキストセット３、４、及び５は２つのコンテキストを有する。以下のように表すことができる。

【数5】

【0120】

そのような例では、マッピングは、表１９及び表２０に示す通りであり得る。

【表19】

【表20】

【0121】

ｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ及びｃｏｅｆｆ＿ａｂｓ＿ｌｅｖｅｌ＿ｇｒｅａｔｅｒ２＿ｆｌａｇのＣＡＢＡＣ初期化テーブルはまた、１に等しいＴｈｒｅｓ＿ｇｒｅａｔｅｒ１又はＴｈｒｅｓ＿ｇｒｅａｔｅｒ２のためのコンテキストセットについて変更される。変更では、第２のコンテキストの初期化の前に第５のコンテキストの初期化を異動する。この提案する方法は、コンテキストの数を１２０から７８に削減する。

【表21】

【0122】

表２１は、前のセクションにおいて述べたすべてのシンタックス要素のためのコンテキストの数を記載する。コンテキストの総削減数は５６個である。

【表22】

【0123】

図２は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ２０を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコード化及びインターコード化を実行し得る。イントラコード化は、所与のビデオフレーム又はピクチャ内のビデオの空間的冗長性を低減又は除去するために空間的予測に依拠する。インターコード化は、ビデオシーケンスの隣接フレーム又はピクチャ内のビデオの時間的冗長性を低減又は除去するために時間的予測に依拠する。イントラモード（Ｉモード）は、幾つかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測（Ｐモード）又は双方向予測（Ｂモード）などのインターモードは、幾つかの時間ベースの圧縮モードのいずれかを指し得る。

【0124】

図２の例では、ビデオエンコーダ２０は、区分化ユニット３５と、予測ユニット４１と、参照ピクチャメモリ６４と、加算器５０と、変換ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。予測ユニット４１は、動き推定ユニット４２と、動き補償ユニット４４と、イントラ予測ユニット４６とを含む。ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ（図２に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタ処理することになる。追加のループフィルタ（ループ内又はループ後）もデブロッキングフィルタに加えて使用され得る。

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

いずれの場合も、ブロックのイントラ予測モードを選択した後に、イントラ予測ユニット４６は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピーコード化ユニット５６に提供し得る。エントロピーコード化ユニット５６は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブル及び複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、及び変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを含み得る。

【0133】

予測ユニット４１が、インター予測又はイントラ予測のいずれかを介して、現在ビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ２０は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロックにおける残差ビデオデータは、１つ又は複数のＴＵに含まれ得、変換ユニット５２に適用され得る。変換ユニット５２は、変換、例えば離散コサイン変換（ＤＣＴ）又は概念的に類似の変換を使用して、残差ビデオデータを残差変換係数に変換する。変換ユニット５２は、画素領域からの残差ビデオデータを周波数領域などの変換領域に変換し得る。

【0134】

変換ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートを更に低減するために変換係数を量子化する。量子化プロセスは、係数の一部又は全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。幾つかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。一例として、本開示で説明するコード化技法は、エントロピー符号化ユニット５６によって十分に又は部分的に実行され得る。但し、本開示の態様はそのように限定されない。例えば、本開示で説明するコード化技法は、プロセッサ又は任意の他の構成要素など、図２に示されていないビデオエンコーダ２０の構成要素によって実行され得る。幾つかの例では、本開示のコード化技法は、図２に示す他のユニット又はモジュールのうちの１つによって実行され得る。更に幾つかの他の例では、本開示のコード化技法は、ビデオエンコーダ２０のユニット及びモジュールの組合せによって実行され得る。このようにして、ビデオエンコーダ２０は、本開示で説明する例示的な技法を実行するように構成され得る。

【0135】

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

【0136】

本開示の一例では、エントロピー符号化ユニット５６は、Ｐスライス中のビデオデータのブロックのための第１の予測タイプを決定することと、第１の予測タイプをＰスライス予測タイプシンタックス要素として表すことと、Ｂスライス中のビデオデータのブロックのための第２の予測タイプを決定することと、第２の予測タイプをＢスライス予測タイプシンタックス要素として表すことと、Ｐスライス予測タイプシンタックス要素のためのＰスライス２値化を決定することと、Ｂスライス予測タイプシンタックス要素のためのＢスライス２値化を決定することと、Ｐスライス予測タイプシンタックス要素とＢスライス予測タイプシンタックス要素とが同じ２値化論理を使用して決定される、Ｐスライス予測タイプシンタックス要素の２値化とＢスライス予測シンタックス要素の２値化とに基づいてビデオデータを符号化することとを行うように構成され得る。

【0137】

本開示の別の例では、エントロピー符号化ユニット５６は、ビデオデータのブロックのための予測モードのための区分タイプを決定することと、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分タイプビンを符号化することと、単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックスの区分サイズビンを符号化することとを行うように構成され得る。

【0138】

本開示の別の例では、エントロピー符号化ユニット５６は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、ＣＡＢＡＣが１つ又は複数のコンテキストを含むコンテキストセットを使用する、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することとを行うように構成され得、ＣＡＢＡＣがＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用する。ビデオエンコーダ２０及びビデオデコーダ３０は、ビデオデータのブロックに関連する変換単位の変換深度に基づいて１つ又は複数のコンテキストからコンテキストを選択するように更に構成され得る。

【0139】

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

【0140】

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

【0141】

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

【0142】

一例として、本開示で説明するコード化技法は、エントロピー復号ユニット８０によって十分に又は部分的に実行され得る。但し、本開示の態様はそのように限定されない。例えば、本開示で説明するコード化技法は、プロセッサ又は任意の他の構成要素など、図３に示されていないビデオデコーダ３０の構成要素によって実行され得る。幾つかの例では、本開示のコード化技法は、図３に示す他のユニット又はモジュールのうちの１つによって実行され得る。更に幾つかの他の例では、本開示のコード化技法は、ビデオデコーダ３０のユニット及びモジュールの組合せによって実行され得る。このようにして、ビデオデコーダ３０は、本開示で説明する例示的な技法を実行するように構成され得る。

【0143】

本開示の一例では、エントロピー復号ユニット８０は、Ｐスライス中のビデオデータのブロックのための２値化マッピングを使用して、２値化されたＰスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、Ｂスライス中のビデオデータのブロックのための同じ２値化マッピングを使用して、２値化されたＢスライス予測タイプシンタックス要素を予測タイプにマッピングすることと、マッピングされた予測タイプに基づいてビデオデータを復号することとを行うように構成され得る。

【0144】

本開示の一例では、エントロピー復号ユニット８０は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してコード化されたビデオデータのブロックのための予測タイプシンタックス要素を受信することと、予測タイプシンタックス要素が、区分タイプを表す区分タイプビンと、ここで区分サイズを表す区分サイズビンとを含む、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化を使用して、予測タイプシンタックス要素の区分タイプビンを復号することと、ここで単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでコンテキスト適応型バイナリ算術コード化を使用して、ビデオデータのブロックのための予測タイプシンタックスの区分サイズビンを復号することとを行うように構成され得る。

【0145】

本開示の別の例では、エントロピー復号ユニット８０は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、ここでＣＡＢＡＣが１つ又は複数のコンテキストを含むコンテキストセットを使用する、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することとを行うように構成され得、ＣＡＢＡＣがＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用する。ビデオエンコーダ２０及びビデオデコーダ３０は、ビデオデータのブロックに関連する変換ユニットの変換深度に基づいて１つ又は複数のコンテキストからコンテキストを選択するように更に構成され得る。

【0146】

ビデオスライスがイントラコード化（Ｉ）スライスとしてコード化されたとき、予測ユニット８１のイントラ予測ユニット８４は、信号伝達されたイントラ予測モードと、現在フレーム又はピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（即ちＢ、Ｐ、又はＧＰＢ）スライスとしてコード化されたとき、予測ユニット８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトル及び他のシンタックス要素に基づいて現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、即ち、リスト０及びリスト１を構成し得る。

【0147】

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

【0148】

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

【0149】

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

【0150】

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

【0151】

図６は、本開示の例示的なビデオ符号化方法を示すフローチャートである。図６の方法は、ビデオエンコーダ２０によって実装され得る。ビデオエンコーダ２０は、Ｐスライス中のビデオデータのブロックのための第１の予測タイプを決定すること（６０２）と、第１の予測タイプをＰスライス予測タイプシンタックス要素として表すこと（６０４）とを行うように構成され得る。ビデオエンコーダ２０は、Ｂスライス中のビデオデータのブロックのための第２の予測タイプを決定すること（６０６）と、第２の予測タイプをＢスライス予測タイプシンタックス要素として表すこと（６０８）とを行うように更に構成され得る。Ｐスライス予測タイプシンタックス要素及びＢスライス予測タイプシンタックス要素は、予測モードと区分タイプとを指定する。予測モードは、インター予測及びイントラ予測のうちの１つを含み得る。区分タイプは、対称区分及び非対称区分のうちの１つを含み得る。

【0152】

ビデオエンコーダ２０は、Ｐスライス予測タイプシンタックス要素のためのＰスライス２値化を決定すること（６１０）と、Ｂスライス予測タイプシンタックス要素のためのＢスライス２値化を決定することと（６１２）を行うように更に構成され得、Ｐスライス予測タイプシンタックス要素とＢスライス予測タイプシンタックス要素とが同じ２値化論理を使用して決定される。ビデオエンコーダ２０は、次いで、Ｐスライス予測タイプシンタックス要素の２値化とＢスライス予測タイプシンタックス要素の２値化とに基づいてビデオデータを符号化する（６１４）。

【0153】

ビデオデータを符号化することは、決定されたＰスライス２値化を用いてＰスライス予測タイプシンタックス要素を２値化することと、決定されたＢスライス２値化を用いてＢスライス予測タイプシンタックス要素を２値化することと、２値化されたＰスライス予測タイプシンタックス要素にコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を適用することと、２値化されたＢスライス予測タイプシンタックス要素にコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を適用することとを備え得る。

【0154】

図７は、本開示の例示的なビデオ復号方法を示すフローチャートである。図７の方法は、ビデオデコーダ３０によって実装され得る。ビデオデコーダ３０は、Ｐスライス中のビデオデータのブロックのための予測タイプを示すコンテキスト適応型バイナリ算術コード化Ｐスライス予測タイプシンタックス要素を受信すること（７０２）と、Ｂスライス中のビデオデータのブロックのための予測タイプを示すコンテキスト適応型バイナリ算術コード化Ｂスライス予測タイプシンタックス要素を受信すること（７０４）とを行うように構成され得る。Ｐスライス予測タイプシンタックス要素及びＢスライス予測タイプシンタックス要素は、予測モードと区分タイプとを指定する。予測モードは、インター予測及びイントラ予測のうちの１つを含み得る。区分タイプは、対称区分及び非対称区分のうちの１つを含み得る。

【0155】

ビデオデコーダ３０は、２値化されたＰスライス予測タイプシンタックス要素を生成するためにＰスライス予測タイプシンタックス要素を復号すること（７０６）と、２値化されたＢスライス予測タイプシンタックス要素を生成するためにＢスライス予測タイプシタックス要素を復号すること（７０８）とを行うように更に構成され得る。ビデオデコーダ３０は、Ｐスライス中のビデオデータのブロックのための２値化マッピングを使用して、２値化されたＰスライス予測タイプシンタックス要素を予測タイプにマッピングすること（７１０）と、Ｂスライス中のビデオデータのブロックのための同じ２値化マッピングを使用して、２値化されたＢスライス予測タイプシンタックス要素を予測タイプにマッピングすること（７１２）とを行うように更に構成され得る。ビデオデコーダ３０は、次いで、マッピングされた予測タイプに基づいてビデオデータを復号する（７１４）。

【0156】

図８は、本開示の例示的なビデオ符号化方法を示すフローチャートである。図８の方法は、ビデオエンコーダ２０によって実装され得る。ビデオエンコーダ２０は、ビデオデータのブロックのための予測モードのための区分タイプを決定すること（８０２）と、単一のコンテキストとともにコンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分タイプビンを符号化すること（８０４）とを行うように構成され得る。単一のコンテキストはいずれの区分タイプについても同じである。一例では、区分タイプは非対称区分であり、区分タイプビンは、非対称区分が垂直方向に区分されるのか、水平方向に区分されるのかを示す。例えば、区分サイズビンは、第１の区分がビデオデータのブロックのサイズの１／４であるのか、又は第１の区分がビデオデータのブロックのサイズの３／４であるのかを示す。

【0157】

ビデオエンコーダ２０は、バイパスモードでＣＡＢＡＣを使用して、ビデオデータのブロックのための予測タイプシンタックス要素の区分サイズビンを符号化する（８０６）ように更に構成され得る。

【0158】

図９は、本開示の例示的なビデオ復号方法を示すフローチャートである。図９の方法は、ビデオデコーダ３０によって実装され得る。ビデオデコーダ３０は、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してコード化されたビデオデータのブロックのための予測タイプシンタックス要素を受信すること（９０２）を行うように構成され得、予測タイプシンタックス要素が、区分タイプを表す区分タイプビンと、区分サイズを表す区分サイズビンとを含む。一例では、区分タイプは非対称区分であり、区分タイプビンは、非対称区分が垂直方向に区分されるのか、水平方向に区分されるのかを示す。例えば、区分サイズビンは、第１の区分がビデオデータのブロックのサイズの１／４であるのか、又は第１の区分がビデオデータのブロックのサイズの３／４であるのかを示す。

【0159】

ビデオデコーダ３０は、単一のコンテキストとともにＣＡＢＡＣを使用して、予測タイプシンタックス要素の区分タイプビンを復号すること（９０４）と、ここで単一のコンテキストがいずれの区分タイプについても同じである、バイパスモードでＣＡＢＡＣを使用して、予測タイプシンタックス要素の区分サイズビンを復号すること（９０６）とを行うように更に構成され得る。

【0160】

図１０は、本開示の例示的なビデオコード化方法を示すフローチャートである。図１０の方法は、ビデオエンコーダ２０又はビデオデコーダのいずれかによって実装され得る。図１０では、ビデオエンコーダ２０とビデオデコーダ３０とを集合的にビデオコーダと呼ぶ。図１０の技法によれば、ビデオコーダは、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化すること（１００２）と、ここでＣｂクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部として１つ又は複数のコンテキストを含むコンテキストセットを使用することを備える、ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化すること（１００４）とを行うように構成され得、Ｃｒクロマコード化ブロックフラグをコード化することが、ＣＡＢＡＣの一部としてＣｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える。一例では、コンテキストセットは５つのコンテキストを含む。

【0161】

本開示の随意の一例では、ビデオコーダは、ビデオデータのブロックに関連する変換単位の変換深度に基づいて１つ又は複数のコンテキストからコンテキストを選択する（１００６）ように更に構成され得る。

【0162】

ビデオエンコーダとして動作するときに、ビデオコーダは、符号化ビデオビットストリーム中のコード化Ｃｂクロマコード化ブロックフラグを信号伝達することと、符号化ビデオビットストリーム中のコード化Ｃｒクロマコード化ブロックフラグを信号伝達することとを行うように更に構成され得る。ビデオデコーダとして動作するときに、ビデオコーダは、符号化ビデオビットストリーム中のコード化Ｃｂクロマコード化ブロックフラグを受信することと、符号化ビデオビットストリーム中のコード化Ｃｒクロマコード化ブロックフラグを受信することとを行うように更に構成され得る。

【0163】

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

【0164】

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

【0165】

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

【0166】

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

【0167】

様々な例について説明した。これら及び他の例は以下の特許請求の範囲内に入る。
以下に本件出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ ビデオデータをコード化する方法であって、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、前記Ｃｂクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として１つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することと、前記Ｃｒクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、を備える、方法。
［Ｃ２］ 前記コンテキストセットが５つのコンテキストを含む、Ｃ１に記載の方法。
［Ｃ３］ ビデオデータの前記ブロックに関連する変換単位の変換深度に基づいて前記１つ以上のコンテキストからコンテキストを選択することを更に備える、Ｃ１に記載の方法。
［Ｃ４］ コード化する前記方法が符号化する方法であり、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを信号伝達することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを信号伝達することとを更に備える、Ｃ１に記載の方法。
［Ｃ５］ コード化する前記方法が復号する方法であり、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを受信することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを受信することとを更に備える、Ｃ１に記載の方法。
［Ｃ６］ ビデオデータをコード化するように構成された装置であって、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、前記Ｃｂクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として１つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することと、前記Ｃｒクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、
を行うように構成されたビデオコーダを備える、装置。
［Ｃ７］ 前記コンテキストセットが５つのコンテキストを含む、Ｃ６に記載の装置。
［Ｃ８］ 前記ビデオコーダが、
ビデオデータの前記ブロックに関連する変換単位の変換深度に基づいて前記１つ以上のコンテキストからコンテキストを選択することを行うように更に構成された、Ｃ６に記載の装置。
［Ｃ９］ 前記ビデオコーダがビデオエンコーダであり、前記ビデオエンコーダが、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを信号伝達することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを信号伝達することとを行うように更に構成された、Ｃ６に記載の装置。
［Ｃ１０］ 前記ビデオコーダがビデオデコーダであり、前記ビデオデコーダは、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを受信することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを受信することとを行うように更に構成された、Ｃ６に記載の装置。
［Ｃ１１］ ビデオデータをコード化するように構成された装置であって、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化するための手段と、前記Ｃｂクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として１つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化するための手段と、前記Ｃｒクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、を備える、装置。
［Ｃ１２］ 前記コンテキストセットが５つのコンテキストを含む、Ｃ１１に記載の装置。
［Ｃ１３］ ビデオデータの前記ブロックに関連する変換単位の変換深度に基づいて前記１つ以上のコンテキストからコンテキストを選択するための手段を更に備える、Ｃ１１に記載の装置。
［Ｃ１４］ 前記装置が、ビデオデータを符号化するように構成され、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを信号伝達するための手段と、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを信号伝達するための手段とを更に備える、Ｃ１１に記載の装置。
［Ｃ１５］ 前記装置が、ビデオデータを復号するように構成され、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを受信するための手段と、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを受信するための手段とを更に備える、Ｃ１１に記載の装置。
［Ｃ１６］ 実行されたとき、ビデオデータをコード化するように構成された１つ以上のプロセッサに、
コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）を使用してビデオデータのブロックのためのＣｂクロマコード化ブロックフラグをコード化することと、前記Ｃｂクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として１つ以上のコンテキストを含むコンテキストセットを使用することを備える、
ＣＡＢＡＣを使用してＣｒクロマコード化ブロックフラグをコード化することと、前記Ｃｒクロマコード化ブロックフラグをコード化することが、前記ＣＡＢＡＣの一部として前記Ｃｂクロマコード化ブロックフラグと同じコンテキストセットを使用することを備える、を行わせる命令を記憶する、コンピュータ可読記憶媒体。
［Ｃ１７］ 前記コンテキストセットが５つのコンテキストを含む、Ｃ１６に記載のコンピュータ可読記憶媒体。
［Ｃ１８］ 前記命令が、前記１つ以上のプロセッサに、
ビデオデータの前記ブロックに関連する変換ユニットの変換深度に基づいて前記１つ以上のコンテキストからコンテキストを選択することを更に行わせる、Ｃ１６に記載のコンピュータ可読記憶媒体。
［Ｃ１９］ 前記１つ以上のプロセッサが、ビデオデータを符号化するように構成され、前記命令が、前記１つ以上のプロセッサに、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを信号伝達することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを信号伝達することとを更に行わせる、Ｃ１６に記載のコンピュータ可読記憶媒体。
［Ｃ２０］ 前記１つ以上のプロセッサが、ビデオデータを復号するように構成され、前記命令が、前記１つ以上のプロセッサに、
符号化ビデオビットストリーム中の前記コード化Ｃｂクロマコード化ブロックフラグを受信することと、
前記符号化ビデオビットストリーム中の前記コード化Ｃｒクロマコード化ブロックフラグを受信することとを更に行わせる、Ｃ１６に記載のコンピュータ可読記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】