【文献】
Cheung Auyeung, et.al.,"Context reduction of the last transform position in JCTVC-D262 for CE11.1",[online],Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11,2011年 3月18日,Document: JCTVC-E344(version 4),[平成27年7月2日検索],インターネット,URL,http://phenix.it-sudparis.eu/jct/doc_end_user/documents/5_Geneva/wg11/JCTVC-E344-v4.zip
【文献】
Sole, J., et.al.,"Parallel Context Processing for the significance map in high coding efficiency",[online],Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11,2011年 1月21日,Document: JCTVC-D262(version 2),[平成27年7月2日検索],インターネット,URL,http://phenix.it-sudparis.eu/jct/doc_end_user/documents/4_Daegu/wg11/JCTVC-D262-v2.zip
【文献】
Seregin, V.,et.al.,"Binarisation modification for last position coding",[online],Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11,2011年 7月16日,Document: JCTVC-F375(version 3),[平成27年7月2日検索],インターネット,URL,http://phenix.it-sudparis.eu/jct/doc_end_user/documents/6_Torino/wg11/JCTVC-F375-v3.zip
【文献】
大久保榮監修,「インプレス標準教科書シリーズ 改訂三版H.264/AVC教科書」,日本,株式会社インプレスR&D,2009年 1月 1日,第1版,第148〜162頁,ISBN:978-4-8443-2664-9
【文献】
亀山渉(外1名)監修,「インプレス標準教科書シリーズ IPTV時代のデジタル放送教科書」,日本,株式会社インプレスR&D,2010年 4月 1日,初版,第155〜161頁,ISBN:978-4-8443-2853-7
(58)【調査した分野】(Int.Cl.,DB名)
前記コンテキストが、16×16の変換ブロックの最後のバイナリインデックス、及び32×32の変換ブロックの最後のバイナリインデックスに割り当てられる、請求項1に記載の方法。
【発明を実施するための形態】
【0017】
概して、本開示はビデオデータをコード化するための技法を記載する。詳細には、本開示はビデオ符号化プロセス及び/又はビデオ復号プロセス内で変換係数をコード化するための技法を記載する。ブロックベースのビデオコード化では、変換係数のブロックは2次元(2D)アレイに配置することができる。変換係数の2次元(2D)アレイを順序付き変換係数の1次元(1D)アレイ、即ちベクトルに再配置するために、走査プロセスを実行することができる。走査順序に基づく変換係数のブロック内の最後有意係数(即ち、非ゼロ係数)の位置を示すために、1つ又は複数のシンタックス要素を使用することができる。最後有意係数の位置は、変換係数の符号化を最適化するためにビデオエンコーダによって使用することができる。同様に、ビデオデコーダは、最後有意係数の位置を使用して変換係数の復号を最適化することができる。即ち、最後有意係数の位置を示す1つ又は複数のシンタックス要素を効率的にコード化することが望ましい。
【0018】
本開示は、最後有意係数の位置を示す1つ又は複数のシンタックス要素をコード化するための技法を記載する。幾つかの例では、最後有意係数の位置を示すシンタックス要素の全部又は一部は、以下の技法のうちのいずれか1つによりエントロピーコード化することができる:コンテキスト適応型可変長コード化(CAVLC)、コンテキスト適応型バイナリ算術コード化(CABAC)、確率間隔区分エントロピーコード化(PIPE)など。「ビン」又は「ビンインデックス」と呼ばれる場合もあるバイナリインデックスとコンテキスト割当てとを利用するエントロピーコード化技法では、異なる変換ブロック(TU)サイズ及び/又は異なる色成分について、共通のコンテキスト割当てを利用することができる。このようにして、コンテキストの総数を削減することができる。コンテキストの総数を削減することによって、記憶される必要があるコンテキストがより少なくなるので、ビデオエンコーダ及び/又はビデオデコーダは、最後有意係数の位置を示すシンタックス要素をより効率的にコード化することができる。
【0019】
図1は、本開示の例により、変換係数をコード化するための技法を利用するように構成され得る、例示的なビデオ符号化及び復号システム10を示すブロック図である。
図1に示されたように、システム10は、通信チャネル16を介して宛先機器14に符号化されたビデオを送信する発信源機器12を含む。符号化されたビデオデータはまた、記憶媒体34又はファイルサーバ36に記憶される場合があり、必要に応じて宛先機器14によってアクセスされる場合がある。記憶媒体又はファイルサーバに記憶されたとき、ビデオエンコーダ20は、コード化ビデオデータを記憶媒体に記憶するための、ネットワークインターフェース、コンパクトディスク(CD)、ブルーレイ(登録商標)又はデジタルビデオディスク(DVD)のバーナ若しくはスタンピングファシリティ機器、又は他の機器などの別の機器にコード化ビデオデータを供給することができる。同様に、ネットワークインターフェース、CD又はDVDのリーダなどのビデオデコーダ30とは別個の機器は、記憶媒体からコード化ビデオデータを取り出し、取り出されたデータをビデオデコーダ30に供給することができる。
【0020】
発信源機器12及び宛先機器14は、デスクトップコンピュータ、ノートブック(即ち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、所謂スマートフォンなどの電話ハンドセット、テレビジョン、カメラ、表示装置、デジタルメディアプレーヤ、ビデオゲームコンソールなどを含む、多種多様な機器のうちのいずれかを備えることができる。多くの場合、そのような機器はワイヤレス通信用に装備することができる。従って、通信チャネル16は、符号化されたビデオデータの送信に適したワイヤレスチャネル、有線チャネル、又はワイヤレスチャネルと有線チャネルの組合せを備えることができる。同様に、ファイルサーバ36は、インターネット接続を含む任意の標準データ接続を介して宛先機器14によってアクセスすることができる。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適したワイヤレスチャネル(例えば、Wi−Fi(登録商標)接続)、有線接続(例えば、DSL、ケーブルモデムなど)、又は両方の組合せを含む場合がある。
【0021】
本開示の例による、変換係数をコード化するための技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、例えばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、又は他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコード化に適用することができる。幾つかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、及び/又はビデオテレフォニなどの適用例をサポートするために、一方向又は双方向のビデオ送信をサポートするように構成することができる。
【0022】
図1の例では、発信源機器12は、ビデオ発信源18と、ビデオエンコーダ20と、変調器/復調器22と、送信機24とを含む。発信源機器12では、ビデオ発信源18は、ビデオカメラなどの撮像装置、以前に撮影されたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、及び/又は発信源ビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどの発信源、又はそのような発信源の組合せを含むことができる。一例として、ビデオ発信源18がビデオカメラである場合、発信源機器12及び宛先機器14は、所謂カメラ付き電話又はビデオ電話を形成する場合がある。しかしながら、本開示に記載された技法は、一般のビデオコード化に適用可能であり得るし、ワイヤレス及び/又は有線の適用例、又は符号化されたビデオデータがローカルディスクに記憶される適用例に適用することができる。
【0023】
撮影されたビデオ、以前に撮影されたビデオ、又はコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化することができる。符号化されたビデオ情報は、ワイヤレス通信プロトコルなどの通信規格に従ってモデム22によって変調される場合があり、送信機24を介して宛先機器14に送信される場合がある。モデム22は、信号変調用に設計された様々なミキサ、フィルタ、増幅器又は他の構成要素を含むことができる。送信機24は、増幅器、フィルタ、及び1つ以上のアンテナを含む、データを送信するために設計された回路を含むことができる。
【0024】
ビデオエンコーダ20によって符号化された、撮影されたビデオ、以前に撮影されたビデオ、又はコンピュータ生成ビデオはまた、後で消費するために記憶媒体34又はファイルサーバ36に記憶される場合がある。記憶媒体34には、ブルーレイディスク、DVD、CD−ROM、フラッシュメモリ、又は符号化ビデオを記憶するための他の適切なデジタル記憶媒体が含まれ得る。記憶媒体34に記憶された符号化ビデオは、次いで、復号及び再生のために宛先機器14によってアクセスされる場合がある。
【0025】
ファイルサーバ36は、符号化されたビデオを記憶すること、及び符号化されたビデオを宛先機器14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバには、(例えば、ウェブサイト用の)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)機器、ローカルディスクドライブ、又は符号化されたビデオデータを記憶すること、及び符号化されたビデオデータを宛先機器に送信することが可能な他のタイプの機器が含まれる。ファイルサーバ36からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、又は両方の組合せであり得る。ファイルサーバ36は、インターネット接続を含む任意の標準データ接続を介して、宛先機器14によってアクセスされる場合がある。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適したワイヤレスチャネル(例えば、Wi−Fi接続)、有線接続(例えば、DSL、ケーブルモデム、イーサネット(登録商標)、USBなど)、又は両方の組合せを含む場合がある。
【0026】
図1の例では、宛先機器14は、受信機26と、モデム28と、ビデオデコーダ30と、表示装置32とを含む。宛先機器14の受信機26は、チャネル16を介して情報を受信し、モデム28はその情報を復調して、ビデオデコーダ30用の復調されたビットストリームを生成する。チャネル16を介して通信される情報は、ビデオデータを復号する際にビデオデコーダ30が使用する、ビデオエンコーダ20によって生成された様々なシンタックス情報を含む場合がある。そのようなシンタックスはまた、記憶媒体34又はファイルサーバ36に記憶された符号化ビデオデータとともに含まれる場合がある。ビデオエンコーダ20及びビデオデコーダ30の各々は、ビデオデータを符号化又は復号することが可能である、それぞれのエンコーダ−デコーダ(コーデック)の一部を形成する場合がある。
【0027】
表示装置32は、宛先機器14と一体化されるか、又はその外部にあり得る。幾つかの例では、宛先機器14は、一体型表示装置を含む場合があり、外部表示装置とインターフェースするように構成される場合もある。他の例では、宛先機器14は表示装置であり得る。概して、表示装置32は、復号されたビデオデータをユーザに対して表示し、液晶表示器(LCD)、プラズマ表示器、有機発光ダイオード(OLED)表示器、又は別のタイプの表示装置などの様々な表示装置のいずれかを備えることができる。
【0028】
図1の例では、通信チャネル16は、無線周波数(RF)スペクトル又は1つ以上の物理伝送線路などの任意のワイヤレスもしくは有線の通信媒体、又はワイヤレス媒体と有線媒体の任意の組合せを備えることができる。通信チャネル16は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネットなどのグローバルネットワークなどのパケットベースネットワークの一部を形成することができる。通信チャネル16は、概して、有線媒体又はワイヤレス媒体の任意の適切な組合せを含む、ビデオデータを発信源機器12から宛先機器14に送信するのに適した任意の通信媒体、又は様々な通信媒体の集合を表す。通信チャネル16には、発信源機器12から宛先機器14への通信を容易にするのに有用であり得るルータ、スイッチ、基地局、又は任意の他の機器が含まれ得る。
【0029】
ビデオエンコーダ20及びビデオデコーダ30は、ITU−Tビデオコード化専門家グループ(VCEG)のビデオコード化共同研究部会(JCT−VC)によって現在開発中の高効率ビデオコード化(HEVC)規格及びISO/IEC動画専門家グループ(MPEG)などのビデオ圧縮規格に従って動作することができ、HEVCテストモデル(HM)に準拠することができる。ビデオエンコーダ20及びビデオデコーダ30は、「HEVCワーキングドラフト5」又は「WD5」と呼ばれるHEVC規格の最近のドラフトに従って動作することができ、同ドラフトは、文書JCTVC−G1103、Brossら、「WD5:高効率ビデオコード化(HEVC)ワーキングドラフト5」、ITU−T SG16 WP3とISO/IEC JTC1/SC29/WG11のビデオコード化共同研究部会(JCT−VC)、第7回会合:ジュネーブ、スイス、2012年11月に記載されている。更に、HEVCの別の最近のワーキングドラフト、ワーキングドラフト7は、文書HCTVC−I1003、Brossら、「高効率ビデオコード化(HEVC)テキスト仕様ドラフト7」、ITU−T SG16WP3とISO/IEC JTC1/SC29/WG11のビデオコード化共同研究部会(JCT−VC)、第9回会合:ジュネーブ、スイス、2012年4月27日〜2012年5月7日に記載されている。代替として、ビデオエンコーダ20及びビデオデコーダ30は、代替的にMPEG−4、Part10、高度ビデオコード化(AVC)と呼ばれるITU−T H.264規格などの他のプロプライエタリ規格又は業界規格、若しくはそのような規格の拡張に従って動作することができる。しかしながら、本開示の技法は、いかなる特定のコード化規格にも限定されない。他の例にはMPEG−2及びITU−T H.263が含まれる。
【0030】
図1には示されていないが、幾つかの態様では、ビデオエンコーダ20及びビデオデコーダ30は、各々オーディオエンコーダ及びオーディオデコーダと一体化される場合があり、共通のデータストリーム又は個別のデータストリーム内のオーディオとビデオの両方の符号化を処理するのに適したMUX−DEMUXユニット、又は他のハードウェア及びソフトウェアを含む場合がある。適用可能な場合、幾つかの例では、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、又はユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
【0031】
ビデオエンコーダ20及びビデオデコーダ30は各々、1つ以上のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組合せなどの様々な適切なエンコーダ回路のうちのいずれかとして実装することができる。本技法が部分的にソフトウェアに実装されるとき、機器は、適切な非一時的コンピュータ可読媒体にソフトウェア用の命令を記憶し、1つ又は複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行することができる。ビデオエンコーダ20及びビデオデコーダ30の各々は、1つ又は複数のエンコーダ又はデコーダに含まれる場合があり、そのいずれも、それぞれの機器において複合エンコーダ/デコーダ(コーデック)の一部として統合される場合がある。
【0032】
ビデオエンコーダ20は、ビデオ符号化プロセス内で変換係数をコード化するための、本開示の技法のうちのいずれか又は全てを実施することができる。同様に、ビデオデコーダ30は、ビデオコード化プロセス内で変換係数をコード化するための、これらの技法のいずれか又は全てを実施することができる。本開示に記載されたビデオコーダは、ビデオエンコーダ又はビデオデコーダを指す場合がある。同様に、ビデオコード化ユニットは、ビデオエンコーダ又はビデオデコーダを指す場合がある。同様に、ビデオコード化はビデオ符号化又はビデオ復号を指す場合がある。
【0033】
図1のビデオエンコーダ20及びビデオデコーダ30は、ビデオブロック内の最後有意係数の位置を示すバイナリストリングを取得することと、ビデオブロックのサイズに基づいてバイナリストリングのバイナリインデックス用のコンテキストを決定することと、コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に決定されたコンテキストに基づいて、コンテキスト適応型バイナリ算術コード化(CABAC)を使用してバイナリストリングを符号化することとを行うように構成されたビデオコーダの例を表す。
【0034】
現在開発中のHEVC規格に従うビデオコード化の場合、ビデオフレームをコード化単位に区分することができる。コード化単位(CU)は、一般に、様々なコード化ツールがビデオ圧縮用に適用される基本単位として働く画像領域を指す。CUは、通常、Yと表記されるルミナンス成分と、U及びVと表記される2つのクロマ成分とを有する。ビデオサンプリングフォーマットに応じて、U成分とV成分のサイズは、サンプル数に換算して、Y成分のサイズと等しい場合があるか、又は異なる場合もある。CUは、通常、正方形であり、例えば、ITU−T H.264などの他のビデオコード化規格の下での所謂マクロブロックと同様であると考えることができる。本出願では、例示のために、開発中のHEVC規格の現在提案されている態様の幾つかに従うコード化が記載される。しかしながら、本開示に記載される技法は、H.264又は他の規格に従って定義されるビデオコード化プロセス、若しくは他の標準もしくはプロプライエタリのビデオコード化プロセスなどの他のビデオコード化プロセスに有用であり得る。HEVCの規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコード化機器のモデルに基づく。HMは、例えば、ITU−T H.264/AVCによる機器に勝るビデオコード化機器の幾つかの能力を仮定する。例えば、H.264は9つのイントラ予測符号化モードを提供するが、HMは34個ものイントラ予測符号化モードを提供する。
【0035】
ビデオシーケンスは、通常、一連のビデオフレーム又はピクチャを含む。ピクチャグループ(GOP)は、一般に、ビデオピクチャのうちの一連の1つ又は複数を備える。GOPは、GOP内に含まれるピクチャの数を記述するシンタックスデータを、GOPのヘッダ内、ピクチャのうちの1つ以上のヘッダ内、又は他の場所に含む場合がある。ピクチャの各スライスは、それぞれのスライス用の符号化モードを記述するスライスシンタックスデータを含む場合がある。ビデオエンコーダ20は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコード化ノードに対応する1つ又は複数のTU又はPUを含む場合がある。ビデオブロックは、サイズを固定することも変更することもでき、指定されたコード化規格に応じてサイズが異なる場合がある。
【0036】
HMによれば、CUは、1つもしくは複数の予測単位(PU)及び/又は1つ以上の変換単位(TU)を含むことができる。ビットストリーム内のシンタックスデータは、画素数に換算して最大のCUである最大コード化単位(LCU)を定義することができる。概して、CUは、CUがサイズの差異を有していないことを除いて、H.264のマクロブロックと同様の目的を有する。従って、CUはサブCUに分割することができる。概して、本開示におけるCUへの言及は、ピクチャの最大コード化単位又はLCUのサブCUを指す場合がある。LCUはサブCUに分割され得るし、各サブCUは更にサブCUに分割され得る。ビットストリームのシンタックスデータは、CU深度と呼ばれる、LCUが分割され得る最大数を定義することができる。それに応じて、ビットストリームは最小コード化単位(SCU)も定義することができる。本開示ではまた、CU、PU、又はTUのいずれかを指すために「ブロック」又は「部分」という用語も使用する。概して、「部分」は、ビデオフレームの任意のサブセットを指す場合がある。
【0037】
LCUは4分木データ構造に関連付けることができる。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードはLCUに対応する。CUが4つのサブCUに分割される場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。4分木データ構造の各ノードは、対応するCUにシンタックスデータを提供することができる。例えば、4分木のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含むことができる。CUのシンタックス要素は、再帰的に定義され得るし、CUがサブCUに分割されるかどうかに依存する場合がある。CUがこれ以上分割されない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的分割が存在しなくても、リーフCUの4つのサブCUはリーフCUとも呼ばれる。例えば、16×16サイズのCUがこれ以上分割されない場合、この16×16CUがまったく分割されなくても、4つの8×8サブCUもリーフCUと呼ばれる。
【0038】
その上、リーフCUのTUもそれぞれの4分木データ構造に関連付けることができる。即ち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含むことができる。本開示では、LCUがどのように区分されるかを示す4分木をCU4分木と呼び、リーフCUがどのようにTUに区分されるかを示す4分木をTU4分木と呼ぶ。TU4分木のルートノードは概してリーフCUに対応し、CU4分木のルートノードは概してLCUに対応する。分割されないTU4分木のTUはリーフTUと呼ばれる。
【0039】
リーフCUは、1つ又は複数の予測単位(PU)を含むことができる。概して、PUは、対応するCUの全部又は一部を表し、そのPU用の参照サンプルを取り出すためのデータを含むことができる。例えば、PUがインターモード符号化されるとき、PUは、PU用の動きベクトルを定義するデータを含むことができる。動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(例えば、1/4画素精度もしくは1/8画素精度)、動きベクトルが指す参照フレーム、及び/又は動きベクトル用の参照リスト(例えば、リスト0又はリスト1)を記述することができる。PUを定義するリーフCU用のデータはまた、例えば、CUを1つ又は複数のPUに区分することを記述することができる。区分モードは、CUがコード化されていないか、イントラ予測モード符号化されるか、又はインター予測モード符号化されるかに応じて異なる場合がある。イントラコード化の場合、PUは、以下に記載されるリーフ変換単位と同じように扱うことができる。
【0040】
一例として、HMは、様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2N又はN×NのPUサイズでのイントラ予測をサポートし、2N×2N、2N×N、N×2N、又はN×Nの対称的なPUサイズでのインター予測をサポートする。HMはまた、2N×nU、2N×nD、nL×2N、及びnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、又は「Right」という表示によって示される。従って、例えば、「2N×nU」は、上部の2N×0.5NのPUと下部の2N×1.5NのPUとで水平方向に区分された2N×2NのCUを指す。
【0041】
本開示では、「N×N(NxN)」及び「N×N(N by N)」は、垂直寸法及び水平寸法に関するビデオブロックの画素寸法、例えば、16×16(16x16)画素又は16×16(16 by 16)画素を指すために互換的に使用される場合がある。一般に、16×16ブロックは、垂直方向に16画素を有し(y=16)、水平方向に16画素を有する(x=16)。同様に、N×Nブロックは、一般に、垂直方向にN画素を有し、水平方向にN画素を有し、ここでNは非負整数値を表す。ブロック内の画素は行と列で構成することができる。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数の画素を有する必要があるとは限らない。例えば、ブロックはN×M画素を備える場合があり、ここでMは必ずしもNに等しいとは限らない。
【0042】
ブロック(例えば、ビデオデータの予測単位)をコード化するために、ブロックの予測子が最初に導出される。予測ブロックとも呼ばれる予測子は、イントラ(I)予測(即ち、空間的予測)又はインター(P又はB)予測(即ち時間的予測)のいずれかを介して導出することができる。従って、幾つかの予測単位は、同じフレーム(又はスライス)の中の隣接参照ブロック内の参照サンプルに対する空間的予測を使用してイントラコード化(I)され得るし、他の予測単位は、以前にコード化された他のフレーム(又はスライス)の中の参照サンプルのブロックに対して単方向にインターコード化(P)されるか、又は双方向にインターコード化(B)され得る。各場合において、参照サンプルは、コード化されるべきブロック用の予測ブロックを形成するために使用することができる。
【0043】
予測ブロックの識別時に、元のビデオデータブロックとその予測ブロックとの間の差分が決定される。この差分は予測残差データと呼ばれる場合があり、コード化されるべきブロック内の画素値と、コード化ブロックを表すように選択された予測ブロック内の画素値との間の画素差分を示す。より良好な圧縮を実現するために、予測残差データは、例えば、離散コサイン変換(DCT)、整数変換、カルーネン−レーベ(K−L)変換、又は別の変換を使用して変換することができる。
【0044】
TUなどの変換ブロック内の残差データは、空間的画素領域に存在する画素差分値の2次元(2D)アレイに配置される場合がある。変換は、周波数領域などの変換領域内で残差画素値を変換係数の2次元アレイに変換する。さらなる圧縮のために、変換係数は、エントロピーコード化より前に量子化することができる。次いで、エントロピーコーダは、CAVLC、CABAC、PIPEなどのエントロピーコード化を、量子化された変換係数に適用する。
【0045】
量子化された変換係数のブロックをエントロピーコード化するために、ブロック内の量子化された変換係数の2次元(2D)アレイが、特定の走査順序に従って変換係数の順序付き1次元(1D)アレイ、即ちベクトルに再配置されるように、通常、走査プロセスが実行される。次いで、変換係数のベクトルにエントロピーコード化が適用される。変換単位内の量子化された変換係数の走査は、エントロピーコーダ用の変換係数の2Dアレイをシリアル化する。有意性マップは、有意(即ち、非0)係数の位置を示すために生成することができる。走査は、有意(即ち、非0)係数のレベルを走査するために、及び/又は有意係数の符号をコード化するために適用することができる。
【0046】
HEVCでは、有意変換係数の位置情報(例えば、有意性マップ)は、走査順序内の最後の非ゼロ係数の位置を示すために、TUについて最初にコード化される。有意性マップ及びレベル情報(係数の絶対値と符号)は、逆方向走査順序で係数ごとにコード化される。
【0047】
変換係数を生成する任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行することができる。量子化は、一般に、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部又は全部に関連するビット深度を低減することができる。例えば、nビット値は量子化を通じてmビット値に切り捨てることができ、ここでnはmよりも大きい。幾つかの例では、ビデオエンコーダ20は、予め定義された走査順序を利用して、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化された変換係数を走査することができる。他の例では、ビデオエンコーダ20は適応型走査を実行することができる。
【0048】
図2A〜
図2Dは、幾つかの異なる例示的な走査順序を示す。他の定義された走査順序、又は適応型(変化する)走査順序が使用される場合もある。
図2Aはジグザグ走査順序を示し、
図2Bは水平走査順序を示し、
図2Cは垂直走査順序を示し、
図2Dは対角走査順序を示す。これらの走査順序の組合せも定義し使用することができる。幾つかの例では、本開示の技法は、特に、ビデオコード化プロセス内の所謂有意性マップのコード化を通じて適用可能であり得る。
【0049】
最後有意係数(即ち、非ゼロ係数)の位置を示すために、1つ又は複数のシンタックス要素が定義される場合があり、これは係数のブロックに関連する走査順序に依存する場合がある。例えば、1つのシンタックス要素は係数値のブロック内の最後有意係数の列の位置を定義する場合があり、別のシンタックス要素は係数値のブロック内の最後有意係数の行の位置を定義する場合がある。
【0050】
図3は、係数値のブロックに対する有意性マップの一例を示す。有意性マップが右側に示され、その中で、1ビットのフラグが有意即ち非ゼロである、左側のビデオブロック内の係数を識別する。一例では、(例えば、有意性マップによって定義された)有意係数のセット及び走査順序が与えられると、最後有意係数の位置を定義することができる。新興のHEVC規格では、変換係数はチャンクにグループ化することができる。チャンクはTU全体を備えることができるか、又は場合によっては、TUはより小さいチャンクに細分することができる。有意性マップ及びレベル情報(絶対値と符号)は、チャンク内の係数ごとにコード化される。一例では、チャンクは、4×4のTU及び8×8のTUについての逆方向走査順序(例えば、対角、水平又は垂直)で16個の連続する係数からなる。16×16のTU及び32×32のTUの場合、4×4のサブブロック内の係数はチャンクとして扱われる。チャンク内の係数レベル情報を表すために、シンタックス要素がコード化され通知される。一例では、全てのシンボルが逆方向走査順序で符号化される。本開示の技法は、係数のブロックの最後有意係数の位置を定義するために使用されるシンタックス要素のコード化を改善することができる。
【0051】
一例として、本開示の技法は、係数のブロック(例えば、TU又はTUのチャンク)の最後有意係数の位置をコード化するために使用することができる。次いで、最後有意係数の位置をコード化した後、変換係数に関連付けられたレベル及び符号の情報をコード化することができる。レベル及び符号の情報のコード化は、(例えば、TU又はTUのチャンクについての)逆方向走査順序で以下のシンボルをコード化することによって、5段階手法に従って処理することができる。
【0052】
significant_coeff_flag(略称sigMapFlag):このフラグは、チャンク内の各係数の有意性を示すことができる。1以上の値を有する係数は有意であると考えることができる。
【0053】
coeff_abs_level_greater1_flag(略称gr1Flag):このフラグは、非ゼロ係数(即ち、sigMapFlagが1である係数)について、係数の絶対値が1よりも大きいかどうかを示すことができる。
【0054】
coeff_abs_level_greater2_flag(略称gr2Flag):このフラグは、1よりも大きい絶対値を有する係数(即ち、gr1Flagが1である係数)について、係数の絶対値が2よりも大きいかどうかを示すことができる。
【0055】
coeff_sign_flag(略称signFlag):このフラグは、非ゼロ係数についての符号情報を示すことができる。例えば、このフラグについてのゼロは正符号を示し、1は負符号を示す。
【0056】
coeff_abs_level_remain(略称levelRem):このシンタックス要素は、変換係数レベルの残っている絶対値を示すことができる。このシンタックス要素の場合、xよりも大きい大きさを有する各係数について、係数の絶対値−xを(abs(level)−x)とコード化することができる。xの値は、gr1Flag及びgr2Flagの存在に依存する。gr2Flagがコード化された場合、levelRemの値は(abs(level)−2)と計算することができる。gr2Flagがコード化されなかったが、gr1Flagがコード化された場合、levelRemの値は(abs(level)−1)と計算することができる。
【0057】
このようにして、TU又はTUの一部分(例えば、チャンク)用の変換係数をコード化することができる。いずれの場合も、係数のブロックの最後有意係数の位置を定義するために使用されるシンタックス要素のコード化に関係する本開示の技法は、変換係数のレベル及び符号の情報を最終的にコード化するための他のタイプの技法とともに、使用することもできる。有意性、レベル及び符号の情報をコード化するための5段階手法は、本開示に記載されたように、ブロックの最後有意係数の位置のコード化に続いて使用できる1つの例示的な技法にすぎない。
【0058】
量子化変換係数を走査して1次元ベクトルを形成した後、ビデオエンコーダ20は、変換係数の1次元ベクトルをエントロピー符号化することができる。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化することができる。エントロピー符号化は、以下の技法の1つに従って実行することができる:CAVLC、CABAC、シンタックスベースコンテキスト適応型バイナリ算術コード化(SBAC)、PIPEコード化又は別のエントロピー符号化方法。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボル用の可変長コードを選択することができる。可変長コード化(VLC)におけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成することができる。このようにして、VLCを使用すると、例えば、送信されるべきシンボルごとに等長コードワードを使用するよりも、ビット節約を実現することができる。
【0059】
本開示のエントロピーコード化技法は、特にCABACに適用可能であると記載されるが、この技法はCAVLC、SBAC、PIPE、又は他の技法にも適用可能であり得る。PIPEは算術コード化の原理と同様の原理を使用することに留意されたい。
【0060】
概して、CABACを使用してデータシンボルをコード化することは、以下のステップのうちの1つ又は複数を伴う場合がある。
【0061】
(1)2値化:コード化されるべきシンボルが非2進値化された場合、そのシンボルは、バイナリシーケンス、即ち、所謂「ビンストリング」にマッピングされる。ビンストリング内の各バイナリインデックス(即ち、「ビン」)は、「0」又は「1」の値を有することができる。
【0062】
(2)コンテキスト割当て:通常モードでは、各ビンはコンテキストに割り当てられる。ビンはまた、コンテキストが割り当てられないバイパスモードに従ってコード化することができる。コンテキストは確率モデルであり、しばしば「コンテキストモデル」と呼ばれる。本明細書で使用するコンテキストという用語は、確率モデル又は確率値を指す場合がある。コンテキストは、ビンの値の確率が所与のビンについてどのように計算されるかを決定する。コンテキストは、以前に符号化されたシンボル又はビン番号の値などの情報に基づいて、ビンの値の確率を関連付けることができる。更に、コンテキストは、より高いレベル(例えば、スライス)のパラメータに基づいて、ビンに割り当てることができる。
【0063】
(3)ビン符号化:ビンは算術エンコーダを用いて符号化される。ビンを符号化するために、算術エンコーダは、入力として、ビンの値の確率、即ち、ビンの値が「0」に等しい確率、及び/又はビンの値が「1」に等しい確率を必要とする。(推定)確率は、「コンテキスト状態」と呼ばれる整数値により、コンテキスト内で表現することができる。
【0064】
(4)状態更新:選択されたコンテキストについての確率(状態)は、ビンの実際にコード化された値に基づいて更新することができる(例えば、ビン値が「1」であった場合、「1」であるビンの確率が増加され得る)。確率の更新は、コンテキストに関連する変換規則に従って左右される場合がある。
【0065】
以下は、ビデオエンコーダ20によって実行され得る最後有意係数のシンタックス要素の例示的な2値化技法である。最後有意係数シンタックス要素は、2次元ブロック内の最後有意係数の行の位置と列の位置(即ち、x座標とy座標)を含むことができる。8×8ブロックの場合、列又は行の内部の係数の最後の位置、即ち、0、1、...、7についての8個の異なる確率が存在する。8個の異なるビンは、これらの8個の行の位置又は列の位置を表すために使用される。例えば、ビン0=1は、行0又は列0にある係数が最後有意係数であることを示すことができる。この例では、ビン0=0である場合、位置0にある係数は最後の係数ではない。1に等しい別のビンは、最後有意係数の位置を示すことができる。例えば、ビン1=1は、位置1が最後有意係数であることを示すことができる。別の例として、ビンX=1は、位置Xが最後有意係数であることを示すことができる。上述されたように、各ビンは、2つの異なる方法:(1)コンテキストを用いたビンの符号化、及び(2)(コンテキストがない)バイパスモードを使用するビンの符号化によって符号化することができる。
【0066】
表1は、幾つかのビンがコンテキストを用いて符号化され、他のビンがバイパスモードを使用して符号化される、最後有意係数の位置の例示的な2値化を示す。表1の例は、32×32のTUについての最後有意係数の例示的な2値化を提供する。表1の第2列は、2log
2(T)−1の最大切捨て単項プレフィックス長によって定義された、サイズTのTU内の最後有意係数の位置の考えられる値に対応する切捨て単項プレフィックス値を提供する。表1の第3列は、各切捨て単項プレフィックスに対応する固定長サフィックスを提供する。簡略にするために、表1は1又は0のいずれかのビット値を示すX値を含む。X値は、固定長コードに従って切捨て単項プレフィックスを共有する各値を一意にマッピングすることに留意されたい。表1の最後の位置成分の大きさは、x座標の値及び/又はy座標の値に対応することができる。4×4、8×8、及び16×16のTUについての最後有意係数の2値化は、表1に関して記載された32×32のTUの2値化と同様の方式で定義することができる。
【表1】
【0067】
上述されたように、CABACを使用してデータシンボルをコード化することは、コンテキスト割当てを伴う場合もある。一例では、コンテキストのモデル化は、ビンストリングの切捨て単項ストリング部分の算術符号化に使用される場合があるが、コンテキストのモデル化は、ビンストリングの固定バイナリストリングの算術符号化に使用されない(即ち、固定バイナリストリングはバイパスされる)。切捨て単項ストリングがコンテキストのモデル化を使用して符号化される場合、コンテキストはバイナリストリングのビンインデックスの各々に割り当てることができる。
【0068】
コンテキストがバイナリストリングの各ビンインデックスに割り当てることができる幾つかの方法が存在する。最後有意係数の位置を表すビンストリング用のコンテキスト割当ての数は、ビンインデックスの数又は考えられるTUサイズ及び色成分についての切捨て単項ストリングの長さに等しい場合がある。例えば、ルーマ成分の考えられるサイズが4×4、8×8、16×16、及び32×32である場合、ビンが1つもバイパスされないとき、1次元用のコンテキスト割当ての数は、60(即ち、4+8+16+32)に等しくなることができる。同様に、考えられるサイズが4×4、8×8、及び16×16である各クロマ成分の場合、ビンが1つもバイパスされないとき、コンテキスト割当ての数は、28(即ち、4+8+16)に等しくなることができる。従って、最後有意係数の位置がx座標とy座標の両方を使用して指定されるとき、コンテキスト割当ての最大数は、次元ごとに116(即ち、60+28+28)に等しくなることができる。下記の例示的なコンテキスト割当ては、幾つかのビンが表1に関して記載された2値化方式に従ってバイパスされると考える。しかしながら、本明細書に記載されたコンテキスト割当て技法は、幾つかの2値化方式に適用可能であり得ることに留意されたい。更に、幾つかのビンがバイパスされることが考えられるときでも、コンテキストが最後有意係数の位置を表すビンストリングのビンに割り当てることができる多数の方法がまだ存在する。
【0069】
場合によっては、必要なコンテキスト割当ての数に対してコンテキスの総数を削減することが望ましい場合がある。このようにして、エンコーダ又はデコーダは同数のコンテキストを記憶し維持する必要はない可能性がある。しかしながら、コンテキストの数が削減されるとき、例えば、コンテキストが異なる確率を有する2つのビンに共有される場合、予測確度も低減される可能性がある。更に、特定のコンテキストがより頻繁に更新される場合があり、このことはビンの値の推定確率に影響を及ぼす可能性がある。即ち、割り当てられたコンテキストを使用してビンをコード化することは、コンテキストを更新することを伴う場合がある。従って、コンテキストに割り当てられた後続のビンは、更新されたコンテキストを使用してコード化することができる。更に、幾つかの例では、スライス内のビンの値が後続のスライス内のビンのコード化に影響を及ぼすことができないが、それらのビンが同じコンテキストに割り当てられるように、コンテキストモデルはスライスレベルで初期化できることに留意されたい。本開示は、推定確率についての確度を維持しながらコンテキストの数を削減できるように、コンテキスト割当てを最適化するための技法を記載する。一例では、本明細書に記載されたコンテキスト割当て技法は、個々のビンインデックスが同じコンテキストに割り当てられる技法を含む。
【0070】
下記の表2〜表13は、TU内の最後有意係数の位置を表すビンストリングのビンインデックス用のコンテキスト割当てを示す。表2〜表13の幾つかのビン(例えば、8×8ブロックのビン5〜7)には、コンテキストが割り当てられないことに留意されたい。これは、上述されたように、これらのビンがバイパスモードを使用してコード化されるからである。表2〜表13の値がコンテキストのインデックスを表すことにも留意されたい。表2〜表13では、異なるビンが同じコンテキストインデックス値を有するとき、それらは同じコンテキストを共有する。コンテキストインデックスの実際のコンテキストへのマッピングは、ビデオコード化規格に従って定義することができる。表2〜表13は、コンテキストが通常どのようにビンに割り当てられ得るかを示す。
【0071】
表2は、上記の表1に関して提供された例示的な2値化用の様々なTUサイズのビンごとに可能なコンテキストのインデックス付けを示す。表2の例では、隣接するビンは同じコンテキストを共有することを許可される。例えば、8×8のTUのビン2とビン3は同じコンテキストを共有する。
【表2】
【0072】
表3〜表6は、各々以下の規則に従うコンテキスト割当てのさらなる例を示す。
【0073】
1. 最初のK個のビンはコンテキストを共有しない、但しK>1。KはTUサイズごとに異なる可能性がある。
【0074】
2. 1つのコンテキストは連続するビンに割り当てることだけできる。例えば、ビン3〜ビン5はコンテキスト5を使用する可能性がある。しかしながら、コンテキスト5を使用するビン3及びビン5、ならびにコンテキスト6を使用するビン4は許可されない。
【0075】
3. 様々なTUサイズの最後のN個のビン、N>=0、は同じコンテキストを共有することができる。
【0076】
4. 同じコンテキストを共有するビンの数は、TUサイズとともに増加する。
【0077】
上記の規則1〜4は、表1に提供された2値化に特に有用であり得る。しかしながら、規則1〜4は、他の2値化方式に等しく有用であり得るし、実際のコンテキスト割当ては、実装された2値化方式に従って調整することができる。
【表3】
【表4】
【表5】
【表6】
【0078】
記の表7〜表8は、様々なブロックサイズからの最後のビンが同じコンテキストを共有する例示的なコンテキスト割当てを提供し、これはコンテキストの数を更に最適化することができる。一例では、2つ以上のブロックサイズの最後のビンの間でどのようにコンテキストが共有されるかを決定するために、直接マッピングを使用することができる。例えば、それぞれサイズMとサイズNを有するブロックAとブロックBの場合、ブロックAのn番目のビンのコンテキストは、ブロックサイズBのn番目のビンと同じコンテキストを使用することができる。
【表7】
【0079】
表8は、幾つかのブロックサイズからの最後の位置のビンが、お互いにコンテキストを共有する別の例を示す。この場合、サイズ8×8と16×16のTUが同じコンテキストを共有する。
【表8】
【0080】
別の例では、様々なブロックサイズからの最後の位置のビンについてのコンテキストのマッピングは、関数f(.)を使用して導出することができる。例えば、ブロックサイズA内のn番目のビンは、ブロックサイズB内のm番目のビンと同じコンテキストを共有することができ、ここでmはnの関数である(m=f(n))。例えば、関数は線形、即ち、m=n*a+bであり得るし、但しaとbは線形関数のパラメータである。表9は、a=1、b=1、A=8×8のTU、及びB=16×16のTUである例を示す。
【表9】
【0081】
上記の式を幾つかのケースに適用するとき、整数演算に起因して丸めが必要とされる場合があることに留意されたい。例えば、7*0.5=3である。
【0082】
以下の例によれば、8×8ブロックサイズ内の位置nから4×4ブロック内の位置mへのマッピングは、以下の式を用いて計算することができる。
【数1】
【0083】
16×16ブロック内の位置nから4×4ブロック内の位置mへのマッピングは、以下の式を用いて計算することができる。
【数2】
【0084】
上述されたように、式(1)及び式(2)は、異なるサイズのブロック間のマッピングを実施するために使用され得る2つの例にすぎない。式(1)及び式(2)は、マッピング関数と呼ばれる場合がある。式(1)及び式(2)の中の「>>」は、HEVCなどのビデオコード化規格に従って定義されたシフト演算を表すことができることに留意されたい。更に、同じマッピング又は異なるマッピングを実現するために、他の式を使用することができる。
【0085】
表10は、式(1)及び式(2)に従う4×4、8×8、及び16×16のTUについての最後有意係数用の例示的なコンテキスト割当てを提供する。
【表10】
【0086】
表11は、異なるコンテキストインデックスの値(即ち、0〜2の代わりに15〜17)が使用される場合の、表10のコンテキスト割当ての例を提供する。上述されたように、表3〜表12のコンテキストインデックスの値は、バイナリインデックスに割り当てられる実際のコンテキストを限定するものではない。
【表11】
【0087】
表11のコンテキストのマッピングは、以下のマッピング関数と同等であることに留意されたい。
【数3】
【0088】
但し、ctx_indexはコンテキストのインデックスである。
【0089】
n=ビンインデックス
k = log2TrafoDimension-2
log2TrafoDimension =x寸法における最後の位置のlog2(幅)
log2TrafoDimension =y寸法における最後の位置のlog2(高さ)
場合によっては、(1)〜(3)に定義された関数は、メモリに記憶され、コンテキスト割当てを参照するために利用され得る一連のテーブルを構築するために、コード化機器によって使用される場合がある。場合によっては、表は、本明細書に記載された式と規則とに基づいて予め決定され、ビデオエンコーダ20とビデオデコーダ30の両方に記憶される場合がある。
【0090】
更に、幾つかの例では、上記に定義された関数(1)〜(3)は、特定のビンにコンテキストを割り当てるために選択的に適用することができる。このようにして、様々なビンは異なる規則に基づいてコンテキストに割り当てられる場合がある。一例では、上述された関数などの関数は、閾値Th1よりも小さく、及び/又は閾値Th2よりも大きいビンインデックス(即ち、nの値)のみに適用することができる。表12は、上述されたマッピング技法がビンインデックスの値に基づいて選択的に適用される場合、即ち、n>Th2=2の例を示す。
【表12】
【0091】
別の例では、ビンインデックスに技法を適用するための閾値は、様々なブロックサイズ、様々なフレームタイプ、様々な色成分(Y、U、V)、及び/又は他の側面の情報で異なる可能性がある。この閾値は、ビデオコード化規格に従って予め定義することができるか、又は高レベルシンタックスを使用して通知することができる。例えば、閾値は、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、適応パラメータセット(APS)、及び/又はスライスヘッダの中で通知することができる。
【0092】
別の例では、マッピング関数は、様々なブロックサイズ、様々なフレームタイプ、様々な色成分(Y、U、及びV)、及び/又は他の側面の情報で異なる可能性がある。マッピング関数は、ビデオコード化規格に従って予め定義することができるか、又は高レベルシンタックスを使用して通知することができる。例えば、マッピング関数は、SPS、PPS、APS、及び/又はスライスヘッダの中で通知することができる。
【0093】
別の例では、上述された直接マッピング技法及び関数マッピング技法は、色成分、フレームタイプ、量子化パラメータ(QP)及び/又は他の側面の情報に基づいて、適応的に適用することができる。例えば、直接マッピング技法又は関数マッピング技法は、クロマ成分のみに適用される場合がある。この適応性についての規則は、予め定義することができるか、又は高レベルシンタックスを使用して通知することができる。例えば、適応性についての規則は、SPS、PPS、APS、及び/又はスライスヘッダの中で通知することができる。
【0094】
別の例では、クロマ成分用の最後の位置のビンとルーマ成分用の最後の位置のビンは、同じコンテキストを共有することができる。これは、任意のブロックサイズ、例えば、4×4、8×8、16×16、及び32×32に適用することができる。表13は、4×4のTU用のルーマ成分の最後の位置のビンとクロマ成分の最後の位置のビンにコンテキストが共有される場合の例を示す。
【表13】
【0095】
図4は、本開示に記載されるように変換係数をコード化するための技法を使用できるビデオエンコーダ20の例を示すブロック図である。例えば、ビデオエンコーダ20は、ビデオブロック内の最後有意係数の位置を示すバイナリストリングを取得することと、ビデオブロックのサイズに基づいてバイナリストリングのバイナリインデックス用のコンテキストを決定することと、コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に決定されたコンテキストに基づいて、CABACを使用してバイナリストリングを符号化することとを行うように構成されたビデオエンコーダの例を表す。ビデオエンコーダ20は、例示のためにHEVCコード化のコンテキストで記載されるが、変換係数の走査を必要とする場合がある他のコード化規格又はコード化方法に関して本開示を限定するものではない。ビデオエンコーダ20は、ビデオフレーム内のCUのイントラコード化とインターコード化とを実行することができる。イントラコード化は、所与のビデオフレーム内のビデオデータの空間的冗長性を低減又は除去するために空間的予測に依拠する。インターコード化は、ビデオシーケンスの現在のフレームと以前にコード化されたフレームとの間の時間的冗長性を低減又は除去するために時間的予測に依拠する。イントラモード(Iモード)は、幾つかの空間ベースのビデオ圧縮モードのいずれかを指す場合がある。単方向予測(Pモード)又は双方向予測(Bモード)などのインターモードは、幾つかの時間ベースのビデオ圧縮モードのいずれかを指す場合がある。
【0096】
図4に示されたように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。
図4の例では、ビデオエンコーダ20は、モード選択モジュール40と、動き推定モジュール42と、動き補償モジュール44と、イントラ予測モジュール46と、参照フレームバッファ64と、加算器50と、変換モジュール52と、量子化モジュール54と、エントロピー符号化モジュール56とを含む。
図4に示された変換モジュール52は、残差データのブロックに実際の変換又は変換の組合せを適用するモジュールであり、CUの変換単位(TU)と呼ばれる場合もある変換係数のブロックと混同されるべきでない。ビデオブロック復元のために、ビデオエンコーダ20はまた、逆量子化モジュール58と、逆変換モジュール60と、加算器62とを含む。ブロック境界をフィルタ処理して、復元されたビデオからブロック歪み(blockiness artifacts)を除去するデブロッキングフィルタ(
図4に図示せず)が含まれる場合もある。所望される場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタ処理することになる。
【0097】
符号化プロセス中に、ビデオエンコーダ20は、符号化されるべきビデオのフレーム又はスライスを受信する。フレーム又はスライスは、複数のビデオブロック、例えば、最大コード化単位(LCU)に分割することができる。動き推定モジュール42及び動き補償モジュール44は、時間圧縮を行うために、1つ又は複数の参照フレームの中の1つ又は複数のブロックに対して、受信されたビデオブロックのインター予測コード化を実行する。イントラ予測モジュール46は、空間圧縮を行うために、コード化されるべきブロックと同じフレーム又はスライスの中の1つ又は複数の隣接ブロックに対して、受信されたビデオブロックのイントラ予測コード化を実行することができる。
【0098】
モード選択モジュール40は、例えば、モードごとの誤差(即ち、歪み)結果に基づいて、コード化モードのうちの1つ、イントラ又はインターを選択することができ、得られたイントラ又はインター予測ブロック(例えば、予測単位(PU))を加算器50に供給して残差ブロックデータを生成し、加算器62に供給して参照フレーム内で使用する符号化ブロックを復元する。加算器62は、以下でより詳細に記載されるように、予測ブロックを、そのブロックについての逆変換モジュール60からの逆量子化され逆変換されたデータと合成して、符号化ブロックを復元する。幾つかのビデオフレームはIフレームとして指定することができ、Iフレーム内の全てのブロックはイントラ予測モードで符号化される。場合によっては、例えば、動き推定モジュール42によって実行された動き探索によって得られたブロックの予測が不十分であったとき、イントラ予測モジュール46は、Pフレーム又はBフレームの中のブロックのイントラ予測符号化を実行することができる。
【0099】
動き推定モジュール42及び動き補償モジュール44は、高度に統合される場合があるが、概念的な目的のために別々に示される。動き推定(又は動き探索)は、ビデオブロックについて動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、参照フレームの参照サンプルに対する、現在フレーム内の予測単位の変位を示すことができる。動き推定モジュール42は、予測単位を参照フレームバッファ64に記憶された参照フレームの参照サンプルと比較することによって、インターコード化フレームの予測単位用の動きベクトルを計算する。参照サンプルは、絶対差分和(SAD)、2乗差分和(SSD)、又は他の差分メトリックによって決定され得る画素差分に関して、コード化されているPUを含むCUの部分にぴったり一致することがわかるブロックであり得る。参照サンプルは、参照フレーム又は参照スライス内のどこにでも発生する可能性があり、必ずしも、参照フレーム又はスライスのブロック(例えば、コード化単位)境界で発生するとは限らない。幾つかの例では、参照サンプルは分数画素位置で発生する場合がある。
【0100】
動き推定モジュール42は、計算された動きベクトルをエントロピー符号化モジュール56と動き補償モジュール44とに送る。動きベクトルによって識別される参照フレームの部分は、参照サンプルと呼ばれる場合がある。動き補償モジュール44は、例えば、PU用の動きベクトルによって識別された参照サンプルを取り出すことによって、現在CUの予測単位についての予測値を計算することができる。
【0101】
イントラ予測モジュール46は、動き推定モジュール42及び動き補償モジュール44によって実行されるインター予測の代替として、受信ブロックをイントラ予測する場合がある。イントラ予測モジュール46は、隣接する、以前にコード化されたブロック、例えば、ブロックについての左から右へ、上から下への符号化順序を仮定すると、現在ブロックの上、右上、左上、又は左のブロックに対して、受信ブロックを予測することができる。イントラ予測モジュール46は多種多様なイントラ予測モードで構成することができる。例えば、イントラ予測モジュール46は、符号化されているCUのサイズに基づいて、一定数の方向性予測モード、例えば、34個の方向性予測モードで構成することができる。
【0102】
イントラ予測モジュール46は、例えば、様々なイントラ予測モードの誤差値を計算し、最も低い誤差値を生じるモードを選択することによって、イントラ予測モードを選択することができる。方向性予測モードは、空間的に隣接する画素の値を合成し、その合成された値をPU内の1つ又は複数の画素位置に適用するための機能を含むことができる。PU内の全ての画素位置についての値が計算されると、イントラ予測モジュール46は、PUと符号化されるべき受信ブロックとの間の画素差分に基づいて、予測モードについての誤差値を計算することができる。イントラ予測モジュール46は、許容できる誤差値を生じるイントラ予測モードが発見されるまで、イントラ予測モードをテストし続けることができる。次いで、イントラ予測モジュール46は、PUを加算器50に送ることができる。
【0103】
ビデオエンコーダ20は、コード化されている元のビデオブロックから、動き補償モジュール44又はイントラ予測モジュール46によって計算された予測データを減算することによって、残差ブロックを形成する。加算器50は、この減算演算を実行する1つ又は複数の構成要素を表す。残差ブロックは、画素差分値の2次元行列に対応することができ、残差ブロック内の値の数は、残差ブロックに対応するPU内の画素の数と同じである。残差ブロック内の値は、PUの中と、コード化されるべき元のブロックの中とで、同じ場所に位置する画素の値の差分、即ち誤差に対応することができる。差分は、コード化されるブロックのタイプに応じて、クロマ差分又はルーマ差分であり得る。
【0104】
変換モジュール52は、残差ブロックから1つ又は複数の変換単位(TU)を形成することができる。変換モジュール52は、複数の変換の中から1つの変換を選択する。変換は、ブロックサイズ、コード化モードなどの1つ又は複数のコード化特性に基づいて選択することができる。次いで、変換モジュール52は、選択された変換をTUに適用して、変換係数の2次元アレイを備えるビデオブロックを生成する。
【0105】
変換モジュール52は、得られた変換係数を量子化モジュール54に送ることができる。次いで、量子化モジュール54は変換係数を量子化することができる。次いで、エントロピー符号化モジュール56は、走査モードに従って、行列内の量子化された変換係数の走査を実行することができる。本開示は、エントロピー符号化モジュール56が走査を実行するものとして記載する。しかしながら、他の例では、量子化モジュール54などの他の処理モジュールが走査を実行できることを理解されたい。
【0106】
逆量子化モジュール58及び逆変換モジュール60は、それぞれ逆量子化及び逆変換を適用して、例えば参照ブロックとして後で使用するために、画素領域において残差ブロックを復元する。動き補償モジュール44は、残差ブロックを参照フレームバッファ64のフレームのうちの1つの予測ブロックに加算することによって、参照ブロックを計算することができる。参照フレームバッファ64は時々復号ピクチャバッファ(DPB)と呼ばれる。動き補償モジュール44はまた、復元された残差ブロックに1つ又は複数の補間フィルタを適用して、動き推定において使用するサブ整数画素値を計算することができる。加算器62は、復元された残差ブロックを、動き補償モジュール44によって生成された動き補償予測ブロックに加算して、参照フレームバッファ64に記憶するための復元されたビデオブロックを生成する。復元されたビデオブロックは、後続のビデオフレーム内のブロックをインターコード化するために、動き推定モジュール42及び動き補償モジュール44によって参照ブロックとして使用することができる。
【0107】
変換係数が1次元アレイに走査されると、エントロピー符号化モジュール56は、CAVLC、CABAC、SBAC、PIPE、又は別のエントロピーコード化方法などのエントロピーコード化を係数に適用することができる。場合によっては、エントロピー符号化モジュール56は、エントロピーコード化に加えて、他のコード化機能を実行するように構成される場合がある。例えば、エントロピー符号化モジュール56は、CU及びPU用のコード化ブロックパターン(CBP)の値を決定するように構成される場合がある。また、場合によっては、エントロピー符号化モジュール56は、係数のランレングスコード化を実行することができる。エントロピー符号化モジュール56によるエントロピーコード化に続いて、得られた符号化ビデオは、ビデオデコーダ30などの別の機器に送信されるか、又は後で送信するか若しくは取り出すためにアーカイブされる場合がある。
【0108】
本開示の技法によれば、エントロピー符号化モジュール56は、例えば、表2〜表13に関して上述されたコンテキスト割当て、又は以下の任意の組合せに基づいて、シンタックス要素を符号化するために使用されるコンテキストを選択することができる:イントラ予測モード用のイントラ予測方向、シンタックス要素に対応する係数の走査位置、ブロックタイプ、変換タイプ、及び/又は他のビデオシーケンス特性。
【0109】
一例では、エントロピー符号化モジュール56は、表1に関して上述された、HEVCに採用された2値化技法を使用して、最後有意係数の位置を符号化することができる。他の例では、エントロピー符号化モジュール56は、他の2値化技法を使用して、最後有意係数の位置を符号化することができる。一例では、最後有意係数の位置用のコードワードは、その後に固定長コードサフィックスが続く切捨て単項コードプレフィックスを含む場合がある。一例では、最後の位置の各大きさは、最後の位置がTUサイズマイナス1に等しいときを除き、全ての考えられるTUサイズに同じ2値化を使用することができる。この例外は切捨て単項コード化の特性に起因する。一例では、方形変換係数内の最後有意係数の位置は、x座標の値とy座標の値とを指定することによって指定される場合がある。別の例では、変換係数ブロックは1×Nベクトルの形態であり得るし、ベクトル内の最後有意係数の位置は単一の位置値によって指定される場合がある。
【0110】
図5は、本開示に記載された技法を実施できる例示的なエントロピー符号化モジュール56を示すブロック図である。一例では、
図5に示されたエントロピー符号化モジュール56は、CABACエンコーダであり得る。例示的なエントロピー符号化モジュール56は、2値化モジュール502と、算術符号化モジュール510とを含む場合があり、算術符号化モジュール510は、バイパス符号化エンジン504と、正規符号化エンジン508と、コンテキストモデル化モジュール506とを含む。エントロピー符号化モジュール56は、変換ブロック係数内の最後有意変換係数の位置を表す1つ又は複数のシンタックス要素などのシンタックス要素を受信し、そのシンタックス要素をビットストリームに符号化する。シンタックス要素は、変換係数ブロック内の最後有意係数の位置のx座標を指定するシンタックス要素と、変換係数ブロック内の最後有意係数の位置のy座標を指定するシンタックス要素とを含む場合がある。
【0111】
2値化モジュール502は、シンタックス要素を受信し、ビンストリング(即ち、バイナリストリング)を生成する。一例では、2値化モジュール502は、変換係数のブロック内の有意係数の最後の位置を表すシンタックス要素を受信し、表1に関して上述された例に従ってビンストリングを生成する。算術符号化モジュール510は、2値化モジュール502からビンストリングを受信し、そのビンストリングに対して算術符号化を実行する。
図5に示されたように、算術符号化モジュール510は、バイパス経路又は正規コード化経路からビン値を受信することができる。上述されたCABACプロセスに従って、算術符号化モジュール510がバイパス経路からビン値を受信する場合、バイパス符号化エンジン504は、ビン値に割り当てられたコンテキストを利用せずに、ビン値に対して算術符号化を実行することができる。一例では、バイパス符号化エンジン504は、ビンの考えられる値について等しい確率を仮定することができる。
【0112】
算術符号化モジュール510が正規経路を介してビン値を受信する場合、コンテキストモデル化モジュール506はコンテキスト変数(例えば、コンテキスト状態)を提供することができ、その結果、正規符号化エンジン508は、コンテキストモデル化モジュール506によって提供されたコンテキスト割当てに基づいて、算術符号化を実行することができる。一例では、算術符号化モジュール510は、コンテキスト割当てを使用してビットストリングのプレフィックス部分を符号化することができ、コンテキスト割当てを使用せずにビットストリングのサフィックス部分を符号化することができる。コンテキスト割当ては、表2〜表13に関して上述された例に従って定義することができる。コンテキストモデルはメモリに記憶することができる。コンテキストモデル化モジュール506は、一連のインデックス付きデーブルを含み、及び/又はマッピング関数を利用してコンテキストと特定のビン用のコンテキスト変数とを決定することができる。ビン値を符号化した後、正規符号化エンジン508は、実際のビン値に基づいてコンテキストを更新し、符号化されたビン値をビットストリームの一部として出力することができる。このようにして、エントロピー符号化モジュールは、本明細書に記載されたコンテキスト割当て技法に基づいて、1つ又は複数のシンタックス要素を符号化するように構成される。
【0113】
図6は、本開示の技法により、最後有意係数の位置を示すバイナリストリング値用のコンテキストを決定するための例示的な方法を示すフローチャートである。
図6に記載された方法は、本明細書に記載された例示的なビデオエンコーダ又はエントロピーエンコーダのいずれかによって実行することができる。ステップ602で、ビデオブロック内の最後有意変換係数の位置を示すバイナリストリングが取得される。バイナリストリングは、表1に関して記載された2値化方式に従って定義することができる。ステップ604で、バイナリストリングのビン値についてコンテキストが決定される。コンテキストは、本明細書に記載された技法に基づいて、ビンに割り当てることができる。コンテキストは、参照テーブルにアクセスするか、又はマッピング関数を実行するビデオエンコーダ又はエントロピーエンコーダによって決定することができる。コンテキストは、特定のビン用の特定のコンテキスト変数を導出するために使用することができる。コンテキスト変数は、64個の考えられる確率(状態)のうちの1つと最も可能性がある状態(例えば、「1」又は「0」)とを示す7ビットのバイナリ値であり得る。上述されたように、場合によっては、ビンは、上述のマッピング関数と表2〜表13とに従って、コンテキストを共有することができる。ステップ606で、CABACなどの、コンテキスト変数を利用する算術符号化プロセスを使用して、ビン値が符号化される。ビンがコンテキストを共有するとき、1つのビンの値は、コンテキスト適応型符号化技法に従って後続のビンを符号化するために使用される、コンテキスト変数の値に影響を及ぼす場合があることに留意されたい。例えば、特定のビンが「1」である場合、後続のビンは、増加された1である確率に基づいて符号化される場合がある。このようにして、バイナリストリングをエントロピー符号化することは、コンテキストモデルのコンテキスト状態を更新することを含む場合がある。更に、幾つかの例では、スライス内のビンの値が後続のスライス内のビンの符号化に影響を及ぼすことができないように、コンテキストモデルはスライスレベルで初期化できることに留意されたい。
【0114】
図7は、本開示に記載されるように、変換係数をコード化するための技法を使用できるビデオデコーダ30の例を示すブロック図である。例えば、ビデオデコーダ30は、ビデオブロック内の最後有意係数の位置を示す、CABACを使用して符号化された符号化バイナリストリングを取得することと、ビデオブロックのサイズに基づいて符号化バイナリストリングのバイナリインデックス用のコンテキストを決定することと、コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に決定されたコンテキストに基づいて、CABACを使用して符号化バイナリストリングを復号することとを行うように構成されたビデオデコーダの例を表す。
【0115】
図7の例では、ビデオデコーダ30は、エントロピー復号モジュール70と、動き補償モジュール72と、イントラ予測モジュール74と、逆量子化モジュール76と、逆変換モジュール78と、参照フレームバッファ82と、加算器80とを含む。幾つかの例では、ビデオデコーダ30は、ビデオエンコーダ20に関して記載された符号化パスとは全体的に逆の復号パスを実行することができる。
【0116】
エントロピー復号モジュール70は、変換係数の1次元アレイを取り出すために、符号化ビットストリームに対してエントロピー復号プロセスを実行する。使用されるエントロピー復号プロセスは、ビデオエンコーダ20によって使用されたエントロピーコード化(例えば、CABAC、CAVLCなど)に依存する。エンコーダによって使用されたエントロピーコード化プロセスは、符号化ビットストリーム内で通知され得るか、又は予め決められたプロセスであり得る。
【0117】
幾つかの例では、エントロピー復号モジュール70(又は逆量子化モジュール76)は、ビデオエンコーダ20のエントロピー符号化モジュール56(又は量子化モジュール54)によって使用された走査モードをミラーリングする走査を使用して、受信された値を走査することができる。係数の走査は逆量子化モジュール76において実行され得るが、走査は、例示のために、エントロピー復号モジュール70によって実行されるものとして記載される。加えて、説明しやすいように別個の機能モジュールとして示されているが、ビデオデコーダ30のエントロピー復号モジュール70、逆量子化モジュール76、及び他のモジュールの構造及び機能は、互いに高度に統合される場合がある。
【0118】
逆量子化モジュール76は、ビットストリーム内で供給され、エントロピー復号モジュール70によって復号された、量子化変換係数を逆量子化(inverse quantize)、即ち、逆量子化(de-quantize)する。逆量子化プロセスは、例えば、HEVC用に提案されたプロセス、又はH.264復号規格によって定義されたプロセスと同様の、従来のプロセスを含むことができる。逆量子化プロセスは、CUが量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオエンコーダ20によって計算された量子化パラメータQPの使用を含むことができる。逆量子化モジュール76は、係数が1次元アレイから2次元アレイに変換される前、又は変換された後に変換係数を逆量子化することができる。
【0119】
逆変換モジュール78は、逆量子化された変換係数に逆変換を適用する。幾つかの例では、逆変換モジュール78は、ビデオエンコーダ20からの通知に基づいて、又はブロックサイズ、コード化モードなどの1つ又は複数のコード化特性から変換を推論することによって、逆変換を決定することができる。幾つかの例では、逆変換モジュール78は、現在ブロックを含むLCU用の4分木のルートノードで通知された変換に基づいて、現在ブロックに適用すべき変換を決定することができる。代替として、変換は、LCU4分木内のリーフノードCU用のTU4分木のルートで通知することができる。幾つかの例では、逆変換モジュール78は、逆変換モジュール78が復号されている現在ブロックの変換係数に2つ以上の逆変換を適用する、カスケード逆変換を適用することができる。
【0120】
イントラ予測モジュール74は、通知されたイントラ予測モードと、現在フレームの以前に復号されたブロックからのデータとに基づいて、現在フレームの現在ブロックについての予測データを生成することができる。動き補償モジュール72は、符号化ビットストリームから、動きベクトルと、動き予測方向と、参照インデックスとを取り出すことができる。参照予測方向は、インター予測モードが単方向である(例えば、Pフレーム)か、双方向である(Bフレーム)かを示す。参照インデックスは、候補動きベクトルがどの参照フレームに基づくかを示す。取り出された動き予測方向と、参照フレームインデックスと、動きベクトルとに基づいて、動き補償モジュール72は現在部分用の動き補償ブロックを生成する。これらの動き補償ブロックは、基本的に、残差データを生成するために使用される予測ブロックを再現する。
【0121】
動き補償モジュール72は、動き補償ブロックを生成し、場合によっては、補間フィルタに基づいて補間を実行することができる。サブ画素精度を有する動き推定に使用されるべき補間フィルタ用の識別子は、シンタックス要素内に含まれる場合がある。動き補償モジュール72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数画素用の補間値を計算することができる。動き補償モジュール72は、受信されたシンタックス情報に従って、ビデオエンコーダ20によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成することができる。
【0122】
加えて、動き補償モジュール72及びイントラ予測モジュール74は、HEVCの例では、(例えば、4分木によって提供される)シンタックス情報の一部を使用して、符号化ビデオシーケンスのフレームを符号化するために使用されたLCUのサイズを決定することができる。動き補償モジュール72及びイントラ予測モジュール74はまた、シンタックス情報を使用して、符号化ビデオシーケンスのフレームの各CUがどのように分割されるか(かつ、同様に、サブCUがどのように分割されるか)を記述する分割情報を決定することができる。シンタックス情報はまた、各分割がどのように符号化されるかを示すモード(例えば、イントラ予測又はインター予測、及びイントラ予測の場合はイントラ予測符号化モード)と、各インター符号化PUについての1つ又は複数の参照フレーム(及び/又はそれらの参照フレーム用の識別子を含んでいる参照リスト)と、符号化ビデオシーケンスを復号するための他の情報とを含むことができる。
【0123】
加算器80は、残差ブロックを、動き補償モジュール72又はイントラ予測モジュール74によって生成された対応する予測ブロックと合成して、復号ブロックを形成する。必要な場合、ブロック歪みを除去するために、デブロッキングフィルタを適用して、復号ブロックをフィルタ処理することもできる。次いで、復号ビデオブロックは、参照フレームバッファ82に記憶され、参照フレームバッファ82は、その後の動き補償用の参照ブロックを提供し、また、(
図1の表示装置32などの)表示装置上の提示用の復号ビデオを生成する。参照フレームバッファ82はDPBと呼ばれる場合もある。
【0124】
図8は、本開示に記載された技法を実施できる例示的なエントロピー復号モジュール70を示すブロック図である。エントロピー復号モジュール70は、エントロピー符号化ビットストリームを受信し、そのビットストリームからのシンタックス要素を復号する。一例では、シンタックス要素は、変換ブロック係数内の最後有意変換係数の位置を表すことができる。シンタックス要素は、変換係数ブロック内の最後有意係数の位置のx座標を指定するシンタックス要素と、変換係数ブロック内の最後有意係数の位置のy座標を指定するシンタックス要素とを含む場合がある。一例では、
図8に示されたエントロピー復号モジュール70は、CABACデコーダであり得る。
図8の例示的なエントロピー復号モジュール70は、算術復号モジュール702を含み、算術復号モジュール702は、バイパス復号エンジン704と正規復号エンジン706とを含む場合がある。例示的なエントロピー復号モジュール70はまた、コンテキストモデル化ユニット708と、逆2値化モジュール710とを含む。例示的なエントロピー復号モジュール70は、
図5に関して記載された例示的なエントロピー符号化モジュール56の逆の機能を実行することができる。このようにして、エントロピー復号モジュール70は、本明細書に記載されたコンテキスト割当て技法に基づいて、エントロピー復号を実行することができる。
【0125】
算術復号モジュール702は符号化ビットストリームを受信する。
図8に示されたように、算術復号モジュール702は、バイパス経路又は正規コード化経路からの符号化されたビン値を処理することができる。符号化されたビン値がバイパス経路に従って処理されるべきか、又は正規経路に従って処理されるべきかの指示は、より高いレベルのシンタックスを有するビットストリーム内で通知することができる。上述されたCABACプロセスに従って、算術復号モジュール702がバイパス経路からビン値を受信する場合、バイパス復号エンジン704は、ビン値に割り当てられたコンテキストを利用せずに、ビン値に対して算術復号を実行することができる。一例では、バイパス復号エンジン704は、ビンの考えられる値について等しい確率を仮定することができる。
【0126】
算術復号モジュール702が正規経路を介してビン値を受信する場合、コンテキストモデル化モジュール708はコンテキスト変数を提供することができ、その結果、正規復号エンジン706は、コンテキストモデル化モジュール708によって提供されたコンテキスト割当てに基づいて、算術復号を実行することができる。コンテキスト割当ては、表2〜表13に関して上述された例に従って定義することができる。コンテキストモデルはメモリに記憶することができる。コンテキストモデル化モジュール708は、一連のインデックス付きデーブルを含み、及び/又はマッピング関数を利用して、符号化ビットストリームのコンテキストとコンテキスト変数部分とを決定することができる。ビン値を復号した後、正規復号エンジン706は、復号されたビン値に基づいてコンテキストを更新することができる。更に、逆2値化モジュール710は、ビン値に対して逆2値化を実行し、ビン照合関数を使用してビン値が有効かどうかを決定することができる。逆2値化モジュール710はまた、照合決定に基づいてコンテキストモデル化モジュールを更新することができる。従って、逆2値化モジュール710は、コンテキスト適応型復号技法に従ってシンタックス要素を出力する。このようにして、エントロピー復号モジュール70は、本明細書に記載されたコンテキスト割当て技法に基づいて、1つ又は複数のシンタックス要素を復号するように構成される。
【0127】
図9は、本開示の技法により、バイナリストリングからの変換係数内の最後有意係数の位置を示す値を決定するための例示的な方法を示すフローチャートである。
図9に記載された方法は、本明細書に記載された例示的なビデオデコーダ又はエントロピー復号ユニットのいずれかによって実行することができる。ステップ902で、符号化ビットストリームが取得される。符号化ビットストリームは、メモリから、又は伝送を介して取り出すことができる。符号化ビットストリームは、CABAC符号化プロセス又は別のエントロピーコード化プロセスに従って符号化することができる。ステップ904で、符号化バイナリストリングの部分についてコンテキストが決定される。コンテキストは、本明細書に記載された技法に基づいて、符号化されたビンに割り当てることができる。コンテキストは、参照テーブルにアクセスするか、又はマッピング関数を実行する、ビデオデコーダ又はエントロピーデコーダによって決定することができる。コンテキストは、符号化ビットストリーム内に提供されたより高いレベルのシンタックスに基づいて決定することができる。コンテキストは、特定の符号化されたビン用の特定のコンテキスト変数を導出するために使用することができる。上述されたように、コンテキスト変数は、64個の考えられる確率(状態)のうちの1つと最も可能性がある状態(例えば、「1」又は「0」)とを示す7ビットのバイナリ値であり得るし、場合によっては、ビンは、コンテキストを共有することができる。ステップ906で、CABACなどの、コンテキスト変数を利用する算術復号プロセスを使用して、バイナリストリングが復号される。バイナリストリングはビンごとのベースで復号することができ、コンテキストモデルは各ビンを復号した後更新される。復号ビットストリームは、符号化ビデオデータに関連する変換係数を復号するために更に使用されるシンタックス要素を含む場合がある。このようにして、上述された技法を利用する特定のビンへのコンテキストの割当ては、符号化ビデオデータの効率的な復号を提供することができる。
【0128】
1つ又は複数の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せに実装することができる。ソフトウェアに実装される場合、機能は、1つ又は複数の命令又はコードとして、コンピュータ可読媒体上に記憶されるか、又はコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行することができる。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、データ記憶媒体又は通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含むことができる。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、又は(2)信号若しくは搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示に記載された技法を実施するための命令、コード及び/又はデータ構造を取り出すために、1つ以上のコンピュータ又は1つ以上のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含むことができる。
【0129】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROM又は他の光ディスク記憶装置、磁気ディスク記憶装置若しくは他の磁気記憶装置、フラッシュメモリ、又は命令若しくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るし、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、又は他のリモート発信源から送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、又は赤外線、無線、及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)及びディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)及びブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【0130】
命令は、1つ又は複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、又は他の等価な集積回路若しくはディスクリート論理回路などの、1つ又は複数のプロセッサによって実行され得る。従って、本明細書で使用する「プロセッサ」という用語は、前述の構造、又は本明細書に記載された技法の実装に適した他の構造のいずれかを指す場合がある。加えて、幾つかの態様では、本明細書に記載された機能は、符号化及び復号のために構成された専用のハードウェア及び/又はソフトウェアのモジュール内に提供されるか、又は複合コーデックに組み込まれ得る。また、本技法は、1つ又は複数の回路又は論理要素に完全に実装することができる。
【0131】
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、又はICのセット(例えば、チップセット)を含む、多種多様な機器又は装置に実装され得る。開示された技法を実行するように構成された機器の機能的態様を強調するために、様々な構成要素、モジュール、又はユニットが本開示に記載されたが、それらの構成要素、モジュール、又はユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上述されたように、様々なユニットが、適切なソフトウェア及び/又はファームウェアとともに、上述された1つ又は複数のプロセッサを含めて、コーデックハードウェアユニットに組み合わせられるか、又は相互動作ハードウェアユニットの集合によって提供され得る。
【0132】
様々な例が記載された。これら及び他の例は、以下の特許請求の範囲内に入る。
以下に本件出願当初の特許請求の範囲に記載された発明を付記する。
[1] ビデオブロック用の変換係数を符号化する方法であって、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示すバイナリストリングを取得することと、ビデオブロックのサイズに基づいて前記バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストが少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々が異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して前記バイナリストリングを符号化することとを備える、方法。
[2] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストが前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数4】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[1]に記載の方法。
[3] 前記コンテキストが、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[1]に記載の方法。
[4] 第2のコンテキストが、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[3]に記載の方法。
[5] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記バイナリストリングを符号化することが、前記バイナリストリングの値に基づいて前記コンテキストを更新することを含み、第2のビデオブロック内の最後有意係数の位置を示す第2のバイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2のバイナリストリングを符号化することと
を更に備え、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[1]に記載の方法。
[6] 変換係数を復号する方法であって、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示す符号化バイナリストリングを取得することと、前記符号化バイナリストリングはコンテキスト適応型バイナリ算術コード化(CABAC)を使用して符号化される、ビデオブロックのサイズに基づいて前記符号化バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することとを備える、方法。
[7] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストが前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数5】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[6]に記載の方法。
[8] 前記コンテキストが、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[6]に記載の方法。
[9] 第2のコンテキストが、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[8]に記載の方法。
[10] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することは、前記符号化バイナリストリングの値に基づいて前記コンテキストを更新することを含み、第2のビデオブロック内の最後有意係数の位置を示す第2の符号化バイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2の符号化バイナリストリングを復号することとを更に備え、前記ビデオブロックと前記第2のビデオブロックは異なるサイズである、[6]に記載の方法。
[11] ビデオブロック用の変換係数を符号化するように構成された装置であって、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示すバイナリストリングを取得するための手段と、ビデオブロックのサイズに基づいて前記バイナリストリングのバイナリインデックス用のコンテキストを決定するための手段と、前記コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して前記バイナリストリングを符号化するための手段とを備える、装置。
[12] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストは前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数6】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[11]に記載の装置。
[13] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記バイナリストリングを符号化することは、前記バイナリストリングの値に基づいて前記コンテキストを更新することを含み、第2のビデオブロック内の最後有意係数の位置を示す第2のバイナリストリングを取得するための手段と、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2のバイナリストリングをエントロピーコード化するための手段とを更に備え、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[11]に記載の装置。
[14] ビデオブロック用の変換係数を復号するように構成された装置であって、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示す、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して符号化された符号化バイナリストリングを取得するための手段と、ビデオブロックのサイズに基づいて前記符号化バイナリストリングのバイナリインデックス用のコンテキストを決定するための手段と、前記コンテキストが少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々が異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号するための手段とを備える、装置。
[15] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストが前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数7】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[14]に記載の装置。
[16] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することは、前記符号化バイナリストリングの値に基づいて前記コンテキストを更新することを含み、第2のビデオブロック内の最後有意係数の位置を示す第2の符号化バイナリストリングを取得するための手段と、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2の符号化バイナリストリングを復号するための手段とを備え、前記ビデオブロックと前記第2のビデオブロックとは異なるサイズである、[14]に記載の装置。
[17] ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示すバイナリストリングを取得することと、ビデオブロックのサイズに基づいて前記バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストが少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して前記バイナリストリングを符号化することとを行うように構成されたビデオエンコーダを備える、装置。
[18] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストは前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数8】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[17]に記載の装置。
[19] 前記コンテキストは、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[17]に記載の装置。
[20] 第2のコンテキストは、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[19]に記載の装置。
[21] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記バイナリストリングを符号化することは、前記バイナリストリングの値に基づいて前記コンテキストを更新することを含み、前記ビデオエンコーダが、第2のビデオブロック内の最後有意係数の位置を示す第2のバイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2のバイナリストリングを符号化することとを行うように更に構成され、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[17]に記載の装置。
[22] ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示す、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して符号化された符号化バイナリストリングを取得することと、ビデオブロックのサイズに基づいて前記符号化バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することとを行うように構成されたビデオデコーダを備える、装置。
[23] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストは前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数9】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[22]に記載の装置。
[24] 前記コンテキストが、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[22]に記載の装置。
[25] 第2のコンテキストが、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[24]に記載の装置。
[26] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化されたバイナリストリングを復号することが、前記符号化されたバイナリストリングの値に基づいて前記コンテキストを更新することを含み、前記ビデオデコーダが、第2のビデオブロック内の最後有意係数の位置を示す第2の符号化バイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2の符号化バイナリストリングを復号することとを行うように更に構成され、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[22]に記載の装置。
[27] 実行されると、ビデオ符号化装置の1つ以上のプロセッサに、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示すバイナリストリングを取得することと、ビデオブロックのサイズに基づいて前記バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、コンテキスト適応型バイナリ算術コード化(CABAC)を使用して前記バイナリストリングを符号化することとを行わせる命令を記憶する、非一時的コンピュータ可読記憶媒体。
[28] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストは前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数10】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[27]に記載の非一時的コンピュータ可読記憶媒体。
[29] 前記コンテキストが、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[27]に記載の非一時的コンピュータ可読記憶媒体。
[30] 第2のコンテキストは、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[29]に記載の非一時的コンピュータ可読記憶媒体。
[31] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記バイナリストリングを符号化することは、前記バイナリストリングの値に基づいて前記コンテキストを更新することを含み、前記命令が、実行されると、ビデオ符号化装置の1つ以上のプロセッサに、第2のビデオブロック内の最後有意係数の位置を示す第2のバイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2のバイナリストリングを符号化することとを更に行わせ、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[27]に記載の非一時的コンピュータ可読記憶媒体。
[32] 実行されると、ビデオ復号装置の1つ以上のプロセッサに、ビデオブロックに関連付けられた変換係数のブロック内の最後有意係数の位置を示す符号化された符号化バイナリストリングを取得することと、前記符号化された符号化バイナリストリングはコンテキスト適応型バイナリ算術コード化(CABAC)を使用して符号化される、ビデオブロックのサイズに基づいて前記符号化バイナリストリングのバイナリインデックス用のコンテキストを決定することと、前記コンテキストは少なくとも2つのバイナリインデックスに割り当てられ、前記少なくとも2つのバイナリインデックスの各々は異なるビデオブロックのサイズに関連付けられる、少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することとを行わせる命令を記憶する、非一時的コンピュータ可読記憶媒体。
[33] 下記関数によって定義されたコンテキストインデックス(ctx_index)に従って、前記コンテキストは前記少なくとも2つのバイナリインデックスの各々に割り当てられ、
【数11】
nが前記バイナリインデックスであり、Tが前記ビデオブロックの寸法である、[32]に記載の非一時的コンピュータ可読記憶媒体。
[34] 前記コンテキストが、16×16のビデオブロックの最後のバイナリインデックス、及び32×32のビデオブロックの最後のバイナリインデックスに割り当てられる、[32]に記載の非一時的コンピュータ可読記憶媒体。
[35] 第2のコンテキストが、前記16×16のビデオブロックの隣接するバイナリインデックスに割り当てられる、[34]に記載の非一時的コンピュータ可読記憶媒体。
[36] 少なくとも部分的に前記決定されたコンテキストに基づいて、CABACを使用して前記符号化バイナリストリングを復号することは、前記符号化バイナリストリングの値に基づいて前記コンテキストを更新することを含み、前記命令が、実行されると、ビデオ復号装置の1つ以上のプロセッサに、第2のビデオブロック内の最後有意係数の位置を示す第2の符号化バイナリストリングを取得することと、少なくとも部分的に前記更新されたコンテキストに基づいて、CABACを使用して前記第2の符号化バイナリストリングを復号することとを行わせ、前記ビデオブロックと前記第2のビデオブロックが異なるサイズである、[32]に記載の非一時的コンピュータ可読記憶媒体。