知財求人 - 知財ポータルサイト「IP Force」
特表2025-503628ビデオコーディングのためのコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）確率推定
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2025-02-04
(54)【発明の名称】ビデオコーディングのためのコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）確率推定
(51)【国際特許分類】
H04N 19/13 20140101AFI20250128BHJP
H04N 19/157 20140101ALI20250128BHJP
H04N 19/176 20140101ALI20250128BHJP
H04N 19/46 20140101ALI20250128BHJP
【ＦＩ】
H04N19/13
H04N19/157
H04N19/176
H04N19/46
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024541058
(86)(22)【出願日】2022-12-23
(85)【翻訳文提出日】2024-07-08
(86)【国際出願番号】 US2022053966
(87)【国際公開番号】W WO2023132951
(87)【国際公開日】2023-07-13
(31)【優先権主張番号】63/266,623
(32)【優先日】2022-01-10
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】18/145,399
(32)【優先日】2022-12-22
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】507364838
【氏名又は名称】クアルコム，インコーポレイテッド
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100163522
【弁理士】
【氏名又は名称】黒田 晋平
(72)【発明者】
【氏名】ジエ・ドン
(72)【発明者】
【氏名】ヴァディム・セレジン
(72)【発明者】
【氏名】マルタ・カルチェヴィチ
【テーマコード（参考）】
5C159
【Ｆターム（参考）】
5C159MA04
5C159MA05
5C159ME11
5C159RC11
5C159TA58
5C159TB08
5C159TC41
5C159TC42
5C159TD15
5C159UA02
5C159UA05
(57)【要約】
ビデオデコーダは、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信し、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定し、第１のシフト値に基づいて第１の状態変数を更新し、第２のシフト値に基づいて第２の状態変数を更新し、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定し、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号し、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する、ように構成される。
【特許請求の範囲】
【請求項1】
ビデオデータを復号する方法であって、前記方法は、コンテキストモデルに従ってビン値を受信することであって、前記コンテキストモデルが、１つ又は複数の確率状態を含み、前記ビン値が、前記ビデオデータの１つ又は複数のシンタックス要素に対応する、受信することと、
前記受信されたビン値に基づいて第１のシフト値を決定することと、
前記受信されたビン値に基づいて第２のシフト値を決定することと、
前記第１のシフト値に基づいて第１の状態変数を更新することと、
前記第２のシフト値に基づいて第２の状態変数を更新することと、
復号されるべき次のビンについて、前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの確率状態を決定することと、
前記確率状態に基づいて、前記復号されるべき次のビンをコンテキスト復号することと、
前記受信されたビン値及び前記コンテキスト復号された次のビン値に基づいて前記１つ又は複数のシンタックス要素の値を決定することと、を含む、方法。
【請求項2】
前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの前記確率状態を決定することが、前記第１の状態変数及び前記第２の状態変数の加重平均に基づいて前記確率状態を決定することを含む、請求項１に記載の方法。
【請求項3】
前記コンテキストモデルに基づいて、前記第１の状態変数及び前記第２の状態変数の前記加重平均を計算するための重みを決定すること、を更に含む、請求項２に記載の方法。
【請求項4】
前記重みが、第１の重み及び第２の重みを含み、前記第１の重みと前記第２の重みとの和が、１に等しい、請求項３に記載の方法。
【請求項5】
前記コンテキストモデルの識別子に基づいて前記重みの値を決定すること、を更に含む、請求項３に記載の方法。
【請求項6】
前記受信されたビン値に基づいて前記第１のシフト値を決定することは、前記コンテキストモデルの識別子及び受信された最後のＭ個のビン値に基づいてルックアップテーブル中のエントリを識別することであって、Ｍが、１より大きい整数値である、識別することと、
前記エントリに基づいて前記第１のシフト値を決定することと、を含む、請求項１に記載の方法。
【請求項7】
前記エントリに基づいて前記第２のシフト値を決定すること、を更に含む、請求項６に記載の方法。
【請求項8】
前記エントリが８ビット値を含み、前記８ビット値の最初の４ビットが前記第１のシフト値を識別し、前記８ビット値の最後の４ビットが前記第２のシフト値を識別する、請求項７に記載の方法。
【請求項9】
前記第１のシフト値が、前記第２のシフト値より高いレートで更新される、請求項１に記載の方法。
【請求項10】
前記受信されたビン値が、前記コンテキストモデルによって復号された最後のＭ個のビンに対応し、Ｍが、０より大きい整数値である、請求項１に記載の方法。
【請求項11】
Ｍが１に等しい、請求項１０に記載の方法。
【請求項12】
ビデオデータを復号するデバイスであって、前記デバイスが、ビデオデータを記憶するように構成されたメモリと、
回路に実装された１つ又は複数のプロセッサと、を備え、前記１つ又は複数のプロセッサは、
コンテキストモデルに従ってビン値を受信することであって、前記コンテキストモデルが、１つ又は複数の確率状態を含み、前記ビン値が、前記ビデオデータの１つ又は複数のシンタックス要素に対応する、受信することと、
前記受信されたビン値に基づいて第１のシフト値を決定することと、
前記受信されたビン値に基づいて第２のシフト値を決定することと、
前記第１のシフト値に基づいて第１の状態変数を更新することと、
前記第２のシフト値に基づいて第２の状態変数を更新することと、
復号されるべき次のビンについて、前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの確率状態を決定することと、
前記確率状態に基づいて、前記復号されるべき次のビンをコンテキスト復号することと、
前記受信されたビン値及び前記コンテキスト復号された次のビン値に基づいて前記１つ又は複数のシンタックス要素の値を決定することと、を行うように構成されている、デバイス。
【請求項13】
前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの前記確率状態を決定するために、前記１つ又は複数のプロセッサが、前記第１の状態変数及び前記第２の状態変数の加重平均に基づいて前記確率状態を決定するように更に構成されている、請求項１２に記載のデバイス。
【請求項14】
前記１つ又は複数のプロセッサが、前記コンテキストモデルに基づいて、前記第１の状態変数及び前記第２の状態変数の前記加重平均を計算するための重みを決定する、ように更に構成されている、請求項１３に記載のデバイス。
【請求項15】
前記重みが、第１の重み及び第２の重みを含み、前記第１の重みと前記第２の重みとの和が、１に等しい、請求項１４に記載のデバイス。
【請求項16】
前記１つ又は複数のプロセッサが、前記コンテキストモデルの識別子に基づいて前記重みの値を決定する、ように更に構成されている、請求項１４に記載のデバイス。
【請求項17】
前記受信されたビン値に基づいて前記第１のシフト値を決定するために、前記１つ又は複数のプロセッサは、前記コンテキストモデルの識別子及び受信された最後のＭ個のビン値に基づいてルックアップテーブル中のエントリを識別し、Ｍが、１より大きい整数値であり、
前記エントリに基づいて前記第１のシフト値を決定する、ように更に構成されている、請求項１２に記載のデバイス。
【請求項18】
前記１つ又は複数のプロセッサが、前記エントリに基づいて前記第２のシフト値を決定する、ように更に構成されている、請求項１７に記載のデバイス。
【請求項19】
前記エントリが８ビット値を含み、前記８ビット値の最初の４ビットが前記第１のシフト値を識別し、前記８ビット値の最後の４ビットが前記第２のシフト値を識別する、請求項１８に記載のデバイス。
【請求項20】
前記第１のシフト値が、前記第２のシフト値より高いレートで更新される、請求項１２に記載のデバイス。
【請求項21】
前記受信されたビン値が、前記コンテキストモデルによって復号された最後のＭ個のビンに対応し、Ｍが、０より大きい整数値である、請求項１２に記載のデバイス。
【請求項22】
Ｍが１に等しい、請求項２１に記載のデバイス。
【請求項23】
前記デバイスが符号化ビデオデータを受信するように構成された受信機を更に備えるワイヤレス通信デバイスを備える、請求項１２に記載のデバイス。
【請求項24】
前記ワイヤレス通信デバイスが電話ハンドセットを備え、前記受信機が、ワイヤレス通信規格に従って、前記符号化ビデオデータを含む信号を復調するように構成されている、請求項２３に記載のデバイス。
【請求項25】
復号されたビデオデータを表示するように構成されたディスプレイ、を更に備える、請求項１２に記載のデバイス。
【請求項26】
前記デバイスが、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、又はセットトップボックスのうちの１つ又は複数を備える、請求項１２に記載のデバイス。
【請求項27】
ビデオデータを復号する装置であって、前記装置は、コンテキストモデルに従ってビン値を受信する手段であって、前記コンテキストモデルが、１つ又は複数の確率状態を含み、前記ビン値が、前記ビデオデータの１つ又は複数のシンタックス要素に対応する、受信する手段と、
前記受信されたビン値に基づいて第１のシフト値を決定する手段と、
前記受信されたビン値に基づいて第２のシフト値を決定する手段と、
前記第１のシフト値に基づいて第１の状態変数を更新する手段と、
前記第２のシフト値に基づいて第２の状態変数を更新する手段と、
復号されるべき次のビンについて、前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの確率状態を決定する手段と、
前記確率状態に基づいて、前記復号されるべき次のビンをコンテキスト復号する手段と、
前記受信されたビン値及び前記コンテキスト復号された次のビン値に基づいて前記１つ又は複数のシンタックス要素の値を決定する手段と、を備える、装置。
【請求項28】
前記第１の状態変数及び前記第２の状態変数に基づいて前記コンテキストモデルの前記確率状態を決定することが、前記第１の状態変数及び前記第２の状態変数の加重平均に基づいて前記確率状態を決定することを含む、請求項２７に記載の装置。
【請求項29】
前記コンテキストモデルに基づいて、前記第１の状態変数及び前記第２の状態変数の前記加重平均を計算するための重みを決定する手段、を更に備える、請求項２８に記載の装置。
【請求項30】
前記重みが、第１の重み及び第２の重みを含み、前記第１の重みと前記第２の重みとの和が、１に等しい、請求項２９に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、２０２２年１月１０日に出願された米国仮特許出願第６３／２６６，６２３号及び２０２２年１２月２２日に出願された米国特許出願第１８／１４５，３９９号に対する優先権を主張する。２０２２年１２月２２日に出願された米国特許出願第１８／１４５，３９９号は、２０２２年１月１０日に出願された米国仮特許出願第６３／２６６，６２３号の利益を主張し、これらの各々の内容全体は参照により本明細書に組み込まれる。
【0002】
本開示は、ビデオ符号化及びビデオ復号に関する。
【背景技術】
【0003】
デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（personal digital assistants、ＰＤＡｓ）、ラップトップ又はデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラー又は衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスの中に組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４、Ｐａｒｔ１０、アドバンストビデオコーディング（Advanced Video Coding、ＡＶＣ）、ＩＴＵ－Ｔ Ｈ．２６５／高効率ビデオコーディング（High Efficiency Video Coding、ＨＥＶＣ）、ＩＴＵ－Ｔ Ｈ．２６６／汎用ビデオコーディング（Versatile Video Coding、ＶＶＣ）によって定義された規格、及びそのような規格の拡張、並びにＡｌｌｉａｎｃｅ ｆｏｒ Ｏｐｅｎ Ｍｅｄｉａによって開発されたＡＯＭｅｄｉａ Ｖｉｄｅｏ１（ＡＶ１）などのプロプライエタリビデオコーデック／フォーマットに記載されているビデオコーディング技法など、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、及び／又は記憶する場合がある。
【0004】
ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減又は除去するために、空間（ピクチャ内）予測及び／又は時間（ピクチャ間）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（例えば、ビデオピクチャ又はビデオピクチャの一部分）は、ビデオブロックに分割されてもよく、ビデオブロックは、コーディングツリーユニット（coding tree units、ＣＴＵｓ）、コーディングユニット（coding units、ＣＵｓ）及び／又はコーディングノードと呼ばれることもある。ピクチャのイントラコーディングされた（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコーディングされた（Ｐ又はＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測又は他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれる場合があり、参照ピクチャは参照フレームと呼ばれる場合がある。
【発明の概要】
【0005】
いくつかのシンタックス要素をコーディングするために必要とされるビットを低減するために、いくつかのシンタックス要素は、コンテキスト適応型バイナリ算術コーディング（context adaptive binary arithmetic coding、ＣＡＢＡＣ）を使用してコーディングされる場合がある。ＣＡＢＡＣは、コンテキストを使用して、次のビットがある値を有する確率を決定する。本開示では、バイナリ算術コーダの確率推定の精度を改善する技法について説明する。本技法は、ビデオエンコーダ及びビデオデコーダが、ＣＡＢＡＣに関連付けられたコンテキストモデルの確率状態を計算及び更新するために使用され得る。本開示の技法は、汎用ビデオコーディング（ＶＶＣ）において実装されるようなＣＡＢＡＣなど、線形領域中での現実の確率を確率状態が表すバイナリ演算コーダに好適であり得る。
【0006】
通常、コンテキスト状態は、２つの状態変数、すなわち低レート状態変数及び高レート状態変数の関数として選択される。低レート状態変数及び高レート状態変数は、前にコーディングされたビンの値に基づいて次のビンのために更新される。本開示の技法によれば、低レート状態変数及び高レート状態変数は、更に、最後のＭ個のビンの値の特定の組み合わせに基づいて更新され得る。既存の技法では、前のビンがある値を有していた場合、低レート状態変数及び高レート状態変数は常に同じ方法で更新されよう。
【0007】
しかしながら、本発明の技法によれば、前のビンが同じ値を有する２つのコーディングシナリオでは、コーディングされるべきビンが同じであっても、最後のＭ個のビンが異なるので、状態変数への更新が異なり得る。例えば、ビデオコーダは、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定するように構成され得る。ビデオコーダは次いで、第１のシフト値に基づいて、低レート状態変数などの第１の状態変数を更新し、第２のシフト値に基づいて、高レート状態変数などの第２の状態変数を更新することができる。本開示の技法は、ビデオコーダが、シンタックス要素がより少ないビットでシグナリングされることを可能にするより良いコンテキストを選択することを可能にでき、それによりビデオ圧縮が改善される。
【0008】
本開示の一例によれば、ビデオデータを復号する方法は、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信することと、受信されたビン値に基づいて第１のシフト値を決定することと、受信されたビン値に基づいて第２のシフト値を決定することと、第１のシフト値に基づいて第１の状態変数を更新することと、第２のシフト値に基づいて第２の状態変数を更新することと、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定することと、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号することと、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定することと、を含む。
【0009】
本開示の一例によれば、ビデオデータを復号するデバイスは、ビデオデータを記憶するように構成されたメモリと、回路に実装された１つ又は複数のプロセッサと、を含み、１つ又は複数のプロセッサは、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信し、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定し、第１のシフト値に基づいて第１の状態変数を更新し、第２のシフト値に基づいて第２の状態変数を更新し、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定し、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号し、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する、ように構成される。
【0010】
本開示の一例によれば、ビデオデータを復号する装置は、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信する手段と、受信されたビン値に基づいて第１のシフト値を決定する手段と、受信されたビン値に基づいて第２のシフト値を決定する手段と、第１のシフト値に基づいて第１の状態変数を更新する手段と、第２のシフト値に基づいて第２の状態変数を更新する手段と、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定する手段と、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号する手段と、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する手段と、を含む。
【0011】
本開示の一例によれば、コンピュータ可読記憶媒体は命令を記憶し、命令は、１つ又は複数のプロセッサによって実行されたとき、１つ又は複数のプロセッサに、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信することを行わせ、受信されたビン値に基づいて第１のシフト値を決定させ、受信されたビン値に基づいて第２のシフト値を決定させ、第１のシフト値に基づいて第１の状態変数を更新させ、第２のシフト値に基づいて第２の状態変数を更新させ、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定させ、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号させ、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定させる。
【0012】
ビデオデータを符号化するデバイスは、ビデオデータを記憶するように構成されたメモリと、回路に実装された１つ又は複数のプロセッサと、を含み、１つ又は複数のプロセッサは、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を決定し、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定し、第１のシフト値に基づいて第１の状態変数を更新し、第２のシフト値に基づいて第２の状態変数を更新し、符号化されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定し、確率状態に基づいて、符号化されるべき次のビンをコンテキスト符号化する、ように構成される。
【0013】
１つ又は複数の例の詳細が、添付の図面及び以下の説明に記載されている。他の特徴、目的、及び利点は、説明、図面、及び特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【0014】
【図1】本開示の技法を実行し得る例示的なビデオ符号化及び復号システムを示すブロック図である。
【図2】本開示の技法に従って使用され得るビンメモリの一例を示す。
【図3】本開示の技法に従って使用され得る２Ｄルックアップテーブルの一例を示す。
【図4】本開示の技法を実行し得る例示的なビデオエンコーダを示すブロック図である。
【図5】本開示の技法を実行し得る例示的なビデオデコーダを示すブロック図である。
【図6】本開示の技法による、現在ブロックを符号化する例示的なプロセスを示すフローチャートである。
【図7】本開示の技法による、現在ブロックを復号する例示的なプロセスを示すフローチャートである。
【図8A】バイナリ算術コーディングにおける範囲更新プロセスを示す概念図である。
【図8B】バイナリ算術コーディングにおける範囲更新プロセスを示す概念図である。
【図9】バイナリ算術コーディングにおける出力プロセスを示す概念図である。
【図10】ビデオエンコーダ中のコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）コーダを示すブロック図である。
【図11】ビデオデコーダ中のＣＡＢＡＣコーダを示すブロック図である。
【図12】本開示の技法による、現在ブロックを復号する例示的なプロセスを示すフローチャートである。
【発明を実施するための形態】
【0015】
ビデオコーディング（例えば、ビデオ符号化及び／又はビデオ復号）は、通常、同じピクチャの中のビデオデータのすでにコーディングされたブロック（例えば、イントラ予測）又は異なるピクチャの中のビデオデータのすでにコーディングされたブロック（例えば、インター予測）のいずれかから、ビデオデータのブロックを予測することを伴う。いくつかの事例では、ビデオエンコーダはまた、予測ブロックを元のブロックと比較することによって残差データを計算する。したがって、残差データは、予測ブロックと元のブロックとの間の差分を表す。残差データをシグナリングするために必要とされるビットの数を低減するために、ビデオエンコーダは、残差データを変換及び量子化し、変換及び量子化された残差データを符号化ビットストリーム中でシグナリングする。変換及び量子化プロセスによって達成される圧縮は不可逆であることがあり、これは、変換及び量子化プロセスが復号されたビデオデータに歪みをもたらし得ることを意味する。
【0016】
ビデオデコーダは、残差データを復号し予測ブロックに加算して、予測ブロック単独よりも元のビデオブロックと厳密に一致する再構成されたビデオブロックを生成する。残差データの変換及び量子化によってもたらされる損失により、最初の再構成されたブロックは歪み又はアーチファクトを有することがある。１つの一般のタイプのアーチファクト又は歪みは、ビデオデータをコーディングするために使用されるブロックの境界が見えるブロッキネスと呼ばれる。
【0017】
復号されたビデオの品質を更に改善するために、ビデオデコーダは、再構成されたビデオブロックに対して１つ又は複数のフィルタ処理演算を実行することができる。これらのフィルタ処理演算の例としては、デブロッキングフィルタ処理、サンプル適応オフセット（ＳＡＯ）フィルタ処理、及び適応ループフィルタ処理（ＡＬＦ）が挙げられる。これらのフィルタ処理演算のためのパラメータは、ビデオエンコーダによって決定され符号化ビデオビットストリーム中で明示的にシグナリングされ得るか、又はパラメータが符号化ビデオビットストリーム中で明示的にシグナリングされる必要なくビデオデコーダによって暗黙的に決定され得るかのいずれかである。
【0018】
いくつかのシンタックス要素をコーディングするために必要とされるビットを低減するために、いくつかのシンタックス要素は、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）を使用してコーディングされる場合がある。ＣＡＢＡＣは、コンテキストを使用して、次のビットがある値を有する確率を決定する。本開示では、バイナリ算術コーダの確率推定の精度を改善する技法について説明する。本技法は、ビデオエンコーダ及びビデオデコーダが、ＣＡＢＡＣに関連付けられたコンテキストモデルの確率状態を計算及び更新するために使用され得る。本開示の技法は、汎用ビデオコーディング（ＶＶＣ）において実装されるようなＣＡＢＡＣなど、線形領域中での現実の確率を確率状態が表すバイナリ演算コーダに好適であり得る。
【0019】
通常、コンテキスト状態は、２つの状態変数、すなわち低レート状態変数及び高レート状態変数の関数として選択される。低レート状態変数及び高レート状態変数は、前にコーディングされたビンの値に基づいて次のビンのために更新される。本開示の技法によれば、低レート状態変数及び高レート状態変数は、更に、最後のＭ個のビンの値の特定の組み合わせに基づいて更新され得る。既存の技法では、前のビンがある値を有していた場合、低レート状態変数及び高レート状態変数は常に同じ方法で更新されよう。しかしながら、本発明の技法によれば、前のビンが同じ値を有する２つのコーディングシナリオでは、コーディングされるべきビンが同じであっても、最後のＭ個のビンが異なるので、状態変数への更新が異なり得る。例えば、ビデオコーダは、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定するように構成され得る。ビデオコーダは次いで、第１のシフト値に基づいて、低レート状態変数などの第１の状態変数を更新し、第２のシフト値に基づいて、高レート状態変数などの第２の状態変数を更新することができる。本開示の技法は、ビデオコーダが、シンタックス要素がより少ないビットでシグナリングされることを可能にするより良いコンテキストを選択することを可能にでき、それによりビデオ圧縮が改善される。
【0020】
本開示で使用されるビデオコーディングという用語は、一般的に、ビデオ符号化又はビデオ復号のいずれかを指す。同様に、ビデオコーダという用語は、一般的に、ビデオエンコーダ又はビデオデコーダを指すことがある。更に、ビデオ復号に関して本開示で説明されるいくつかの技法は、ビデオ符号化に適用されることもあり、その逆も同様である。例えば、しばしば、ビデオエンコーダ及びビデオデコーダは、同じプロセス又は相反するプロセスを実行するように構成される。また、ビデオエンコーダは、通常、ビデオデータをどのように符号化すべきかを決定するプロセスの一部として、ビデオ復号（再構成とも呼ばれる）を実行する。例えば、ビデオデコーダは、ビデオエンコーダとビデオデコーダの両方がコンテキストを明示的にシグナリングする必要なしに同じコンテキストを使用することができるように、ビデオエンコーダと同じ方法でＣＡＢＡＣのコンテキストを決定するように構成され得る。
【0021】
図１は、本開示の技法を実行し得る例示的なビデオ符号化及び復号システム１００を示すブロック図である。本開示の技法は、一般に、ビデオデータをコーディング（符号化及び／又は復号）することを対象とする。一般に、ビデオデータは、ビデオを処理するための任意のデータを含む。したがって、ビデオデータは、未加工の符号化されていないビデオ、符号化されたビデオ、復号された（例えば、再構成された）ビデオ、及びシグナリングデータなどのビデオメタデータを含んでもよい。
【0022】
図１に示されるように、この例では、システム１００は、宛先デバイス１１６によって復号され表示されるべき、符号化ビデオデータを提供するソースデバイス１０２を含む。具体的には、ソースデバイス１０２は、コンピュータ可読媒体１１０を介して宛先デバイス１１６にビデオデータを提供する。ソースデバイス１０２及び宛先デバイス１１６は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、モバイルデバイス、タブレットコンピュータ、セットトップボックス、スマートフォンなどの電話ハンドセット、テレビジョン、カメラ、表示デバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイス、ブロードキャスト受信機デバイスなどを含む、広範囲にわたるデバイスのうちのいずれかを備えてもよい。場合によっては、ソースデバイス１０２及び宛先デバイス１１６は、ワイヤレス通信に対応し得るので、ワイヤレス通信デバイスと呼ばれ得る。
【0023】
図１の例では、ソースデバイス１０２は、ビデオソース１０４、メモリ１０６、ビデオエンコーダ２００、及び出力インターフェース１０８を含む。宛先デバイス１１６は、入力インターフェース１２２、ビデオデコーダ３００、メモリ１２０、及び表示デバイス１１８を含む。本開示によれば、ソースデバイス１０２のビデオエンコーダ２００及び宛先デバイス１１６のビデオデコーダ３００は、確率推定のための開示される技法を適用するように構成され得る。したがって、ソースデバイス１０２はビデオ符号化デバイスの一例を表し、一方で宛先デバイス１１６はビデオ復号デバイスの一例を表す。他の例では、ソースデバイス及び宛先デバイスは、他の構成要素又は構成を含み得る。例えば、ソースデバイス１０２は、外部カメラなどの外部ビデオソースからビデオデータを受信してもよい。同様に、宛先デバイス１１６は、一体型表示デバイスを含むのではなく、外部表示デバイスとインターフェースしてもよい。
【0024】
図１に示すようなシステム１００は一例にすぎない。一般に、いかなるデジタルビデオ符号化及び／又は復号デバイスも、確率推定の技法を実行し得る。ソースデバイス１０２及び宛先デバイス１１６は、ソースデバイス１０２が宛先デバイス１１６へ送信するためのコーディングされたビデオデータを生成するような、コーディングデバイスの例にすぎない。本開示は、データのコーディング（符号化及び／又は復号）を実行するデバイスを「コーディング」デバイスと呼ぶ。したがって、ビデオエンコーダ２００及びビデオデコーダ３００は、コーディングデバイス、具体的には、それぞれビデオエンコーダ及びビデオデコーダの例を表す。いくつかの例では、ソースデバイス１０２及び宛先デバイス１１６は、ソースデバイス１０２及び宛先デバイス１１６の各々がビデオ符号化及び復号構成要素を含むように、実質的に対称的な方式で動作し得る。したがって、システム１００は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、又はビデオ電話のために、ソースデバイス１０２と宛先デバイス１１６との間での一方向又は両方向のビデオ送信をサポートし得る。
【0025】
一般に、ビデオソース１０４は、ビデオデータのソース（すなわち、未加工の符号化されていないビデオデータ）を表し、ビデオデータの連続した一連のピクチャ（「フレーム」とも呼ばれる）をビデオエンコーダ２００に提供し、ビデオエンコーダ２００は、ピクチャのデータを符号化する。ソースデバイス１０２のビデオソース１０４は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされた未加工のビデオを含むビデオアーカイブ、及び／又はビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。更なる代替として、ビデオソース１０４は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、又はライブビデオ、アーカイブされたビデオ、及びコンピュータ生成されたビデオの組み合わせを生成し得る。各場合において、ビデオエンコーダ２００は、キャプチャされたビデオデータ、事前にキャプチャされたビデオデータ、又はコンピュータ生成されたビデオデータを符号化する。ビデオエンコーダ２００は、受信された順序（「表示順序」と呼ばれることがある）からコーディングのためのコーディング順序へと、ピクチャを並べ替え得る。ビデオエンコーダ２００は、符号化ビデオデータを含むビットストリームを生成し得る。ソースデバイス１０２は次いで、例えば宛先デバイス１１６の入力インターフェース１２２によって受信する及び／又は取り出すために、出力インターフェース１０８を介してコンピュータ可読媒体１１０へと、符号化ビデオデータを出力し得る。
【0026】
ソースデバイス１０２のメモリ１０６及び宛先デバイス１１６のメモリ１２０は、汎用メモリを表す。いくつかの例では、メモリ１０６、１２０は、未加工のビデオデータ、例えば、ビデオソース１０４からの未加工のビデオと、ビデオデコーダ３００からの未加工の復号されたビデオデータと、を記憶し得る。追加又は代替として、メモリ１０６、１２０は、例えば、ビデオエンコーダ２００及びビデオデコーダ３００によってそれぞれ実行可能なソフトウェア命令を記憶し得る。メモリ１０６及びメモリ１２０は、この例ではビデオエンコーダ２００及びビデオデコーダ３００とは別個に示されるが、ビデオエンコーダ２００及びビデオデコーダ３００はまた、機能的に類似の又は等価な目的のために内部メモリを含み得ることを理解されたい。更に、メモリ１０６、１２０は、例えば、ビデオエンコーダ２００から出力されビデオデコーダ３００へ入力される、符号化ビデオデータを記憶し得る。いくつかの例では、メモリ１０６、１２０の部分は、例えば、未加工の復号ビデオデータ及び／又は符号化ビデオデータを記憶するための、１つ又は複数のビデオバッファとして割り振られ得る。
【0027】
コンピュータ可読媒体１１０は、ソースデバイス１０２から宛先デバイス１１６に符号化ビデオデータを移すことが可能な任意のタイプの媒体又はデバイスを表し得る。一例では、コンピュータ可読媒体１１０は、ソースデバイス１０２が、例えば、無線周波数ネットワーク又はコンピュータベースのネットワークを介して、符号化ビデオデータを宛先デバイス１１６にリアルタイムで直接送信することを可能にするための通信媒体を表す。出力インターフェース１０８は、符号化ビデオデータを含む送信信号を変調してもよく、入力インターフェース１２２は、ワイヤレス通信プロトコルなどの通信規格に従って、受信された送信信号を復調してもよい。通信媒体は、無線周波数（ＲＦ）スペクトル又は１つ若しくは複数の物理伝送線路などの、任意のワイヤレス又はワイヤードの通信媒体を備えてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、又はソースデバイス１０２から宛先デバイス１１６への通信を容易にするために有用であり得る任意の他の機器を含み得る。
【0028】
いくつかの例では、ソースデバイス１０２は、出力インターフェース１０８から記憶デバイス１１２に符号化されたデータを出力し得る。同様に、宛先デバイス１１６は、入力インターフェース１２２を介して、記憶デバイス１１２からの符号化されたデータにアクセスし得る。記憶デバイス１１２は、ハードドライブ、ブルーレイディスク、ＤＶＤ、ＣＤ－ＲＯＭ、フラッシュメモリ、揮発性若しくは不揮発性メモリ、又は符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、様々な分散されたデータ記憶媒体又はローカルでアクセスされるデータ記憶媒体のうちのいずれかを含み得る。
【0029】
いくつかの例では、ソースデバイス１０２は、符号化ビデオデータを、ソースデバイス１０２によって生成された符号化ビデオデータを記憶し得るファイルサーバ１１４又は別の中間記憶デバイスに出力し得る。宛先デバイス１１６は、ストリーミング又はダウンロードを介して、ファイルサーバ１１４からの記憶されたビデオデータにアクセスし得る。
【0030】
ファイルサーバ１１４は、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１１６に送信することが可能な任意のタイプのサーバデバイスであり得る。ファイルサーバ１１４は、（例えば、ウェブサイトのための）ウェブサーバ、（ファイル転送プロトコル（File Transfer Protocol、ＦＴＰ）又は片方向伝送路上ファイル配信（File Delivery over Unidirectional Transport、ＦＬＵＴＥ）プロトコルなどの）ファイル転送プロトコルサービスを提供するように構成されたサーバ、コンテンツ配信ネットワーク（content delivery network、ＣＤＮ）デバイス、ハイパーテキスト転送プロトコル（hypertext transfer protocol、ＨＴＴＰ）サーバ、マルチメディアブロードキャストマルチキャストサービス（Multimedia Broadcast Multicast Service、ＭＢＭＳ）若しくは拡張ＭＢＭＳ（Enhanced MBMS、ｅＭＢＭＳ）サーバ、及び／又はネットワークアタッチトストレージ（network attached storage、ＮＡＳ）デバイスを表し得る。ファイルサーバ１１４は、追加又は代替として、ＨＴＴＰ経由動的適応ストリーミング（Dynamic Adaptive Streaming over HTTP、ＤＡＳＨ）、ＨＴＴＰライブストリーミング（HTTP Live Streaming、ＨＬＳ）、リアルタイムストリーミングプロトコル（Real Time Streaming Protocol、ＲＴＳＰ）、ＨＴＴＰ動的ストリーミング（HTTP Dynamic Streaming）などの１つ又は複数のＨＴＴＰストリーミングプロトコルを実装し得る。
【0031】
宛先デバイス１１６は、インターネット接続を含む任意の標準的なデータ接続を通じて、ファイルサーバ１１４からの符号化ビデオデータにアクセスし得る。これは、ワイヤレスチャネル（例えば、Ｗｉ－Ｆｉ接続）、ワイヤード接続（例えば、デジタル加入者線（digital subscriber line、ＤＳＬ）、ケーブルモデムなど）、又はファイルサーバ１１４に記憶されている符号化ビデオデータにアクセスするのに適した両方の組み合わせを含み得る。入力インターフェース１２２は、ファイルサーバ１１４からメディアデータを取り出すか若しくは受信するための上述の様々なプロトコル、又はメディアデータを取り出すための他のそのようなプロトコルのうちのいずれか１つ又は複数に従って動作するように構成され得る。
【0032】
出力インターフェース１０８及び入力インターフェース１２２は、ワイヤレス送信機／受信機、モデム、ワイヤードネットワーク構成要素（例えば、Ｅｔｈｅｒｎｅｔカード）、様々なＩＥＥＥ８０２．１１規格のいずれかに従って動作するワイヤレス通信構成要素、又は他の物理構成要素を表し得る。出力インターフェース１０８及び入力インターフェース１２２がワイヤレス構成要素を備える例では、出力インターフェース１０８及び入力インターフェース１２２は、４Ｇ、４Ｇ－ＬＴＥ（ロングタームエボリューション（Long-Term Evolution））、ＬＴＥアドバンスト、５Ｇなどのセルラー通信規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。出力インターフェース１０８がワイヤレス送信機を備えるいくつかの例では、出力インターフェース１０８及び入力インターフェース１２２は、ＩＥＥＥ８０２．１１仕様、ＩＥＥＥ８０２．１５仕様（例えば、ＺｉｇＢｅｅ（商標））、Ｂｌｕｅｔｏｏｔｈ（商標）規格などの他のワイヤレス規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。いくつかの例では、ソースデバイス１０２及び／又は宛先デバイス１１６は、それぞれのシステムオンチップ（system-on-a-chip、ＳｏＣ）デバイスを含み得る。例えば、ソースデバイス１０２は、ビデオエンコーダ２００及び／又は出力インターフェース１０８に起因する機能を実行するＳｏＣデバイスを含んでもよく、宛先デバイス１１６は、ビデオデコーダ３００及び／又は入力インターフェース１２２に起因する機能を実行するＳｏＣデバイスを含んでもよい。
【0033】
本開示の技法は、オーバージエアテレビジョンブロードキャスト、ケーブルテレビジョン送信、衛星テレビジョン送信、ＨＴＴＰ経由動的適応ストリーミング（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、又は他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用されてもよい。
【0034】
宛先デバイス１１６の入力インターフェース１２２は、コンピュータ可読媒体１１０（例えば、通信媒体、記憶デバイス１１２、ファイルサーバ１１４など）から、符号化されたビデオビットストリームを受信する。符号化されたビデオビットストリームは、ビデオブロック又は他のコードディングされたユニット（例えば、スライス、ピクチャ、ピクチャグループ、シーケンスなど）の特性及び／又は処理を記述する値を有するシンタックス要素などの、ビデオデコーダ３００によっても使用される、ビデオエンコーダ２００によって定義されるシグナリング情報を含んでもよい。表示デバイス１１８は、復号されたビデオデータの復号されたピクチャをユーザに表示する。表示デバイス１１８は、液晶ディスプレイ（liquid crystal display、ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（organic light emitting diode、ＯＬＥＤ）ディスプレイ、又は別のタイプの表示デバイスなど、様々な表示デバイスのいずれかを表し得る。
【0035】
図１には示されないが、いくつかの例では、ビデオエンコーダ２００及びビデオデコーダ３００は各々、オーディオエンコーダ及び／又はオーディオデコーダと統合されてもよく、共通のデータストリームにおいてオーディオとビデオの両方を含む多重化されたストリームを扱うために、適切なＭＵＸ－ＤＥＭＵＸユニット、又は他のハードウェア及び／若しくはソフトウェアを含んでもよい。
【0036】
ビデオエンコーダ２００及びビデオデコーダ３００は各々、１つ若しくは複数のマイクロプロセッサ、デジタル信号プロセッサ（digital signal processors、ＤＳＰｓ）、特定用途向け集積回路（application specific integrated circuits、ＡＳＩＣｓ）、フィールドプログラマブルゲートアレイ（field programmable gate arrays、ＦＰＧＡｓ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせなど、様々な好適なエンコーダ及び／又はデコーダ回路のいずれかとして実装され得る。技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、本開示の技法を実行するために１つ又は複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ２００及びビデオデコーダ３００の各々は、１つ又は複数のエンコーダ又はデコーダに含まれてもよく、それらのいずれもが、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック（CODEC））の一部として統合されてもよい。ビデオエンコーダ２００及び／又はビデオデコーダ３００を含むデバイスは、集積回路、マイクロプロセッサ、及び／又はセルラー電話などのワイヤレス通信デバイスを備えてもよい。
【0037】
ビデオエンコーダ２００及びビデオデコーダ３００は、高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれるＩＴＵ－Ｔ Ｈ．２６５などのビデオコーディング規格、又は、マルチビュー及び／若しくはスケーラブルビデオコーディング拡張などのその拡張規格に従って動作し得る。代替として、ビデオエンコーダ２００及びビデオデコーダ３００は、汎用ビデオコーディング（ＶＶＣ）とも呼ばれるＩＴＵ－Ｔ Ｈ．２６６など、他のプロプライエタリ規格又は業界規格に従って動作し得る。他の例では、ビデオエンコーダ２００及びビデオデコーダ３００は、ＡＯＭｅｄｉａ Ｖｉｄｅｏ１（ＡＶ１）、ＡＶ１の拡張、及び／又はＡＶ１の後継バージョン（例えば、ＡＶ２）など、プロプライエタリビデオコーデック／フォーマットに従って動作し得る。他の例では、ビデオエンコーダ２００及びビデオデコーダ３００は、他のプロプライエタリフォーマット又は業界規格に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格又はフォーマットにも限定されない。一般に、ビデオエンコーダ２００及びビデオデコーダ３００は、ＣＡＢＡＣプロセスの一部として確率推定を使用する任意のビデオコーディング技法とともに本開示の技法を実行するように構成され得る。
【0038】
一般に、ビデオエンコーダ２００及びビデオデコーダ３００は、ピクチャのブロックベースのコーディングを実行してもよい。「ブロック」という用語は、一般に、処理される（例えば、符号化、復号、又はそうでなければ符号化及び／又は復号プロセスにおいて使用される）べきデータを含む構造を指す。例えば、ブロックは、ルミナンス及び／又はクロミナンスデータのサンプルの２次元行列を含んでもよい。一般に、ビデオエンコーダ２００及びビデオデコーダ３００は、ＹＵＶ（例えば、Ｙ、Ｃｂ、Ｃｒ）フォーマットで表されるビデオデータをコーディングし得る。すなわち、ピクチャのサンプルに対する赤、緑、及び青（ＲＧＢ）のデータをコーディングするのではなく、ビデオエンコーダ２００及びビデオデコーダ３００は、ルミナンス成分及びクロミナンス成分をコーディングしてもよく、クロミナンス成分は、赤色と青色の両方のクロミナンス成分を含み得る。いくつかの例では、ビデオエンコーダ２００は、受信されたＲＧＢフォーマットデータを符号化する前にＹＵＶ表現に変換し、ビデオデコーダ３００は、ＹＵＶ表現をＲＧＢフォーマットに変換する。代替として、前処理ユニット及び後処理ユニット（図示せず）が、これらの変換を実行してもよい。
【0039】
本開示は、一般に、ピクチャのデータを符号化又は復号するプロセスを含むものとして、ピクチャのコーディング（例えば、符号化及び復号）に言及することがある。同様に、本開示は、ブロックのためのデータを符号化又は復号するプロセス、例えば予測及び／又は残差コーディングを含むものとして、ピクチャのブロックのコーディングに言及することがある。符号化されたビデオビットストリームは、一般に、コーディング決定（例えば、コーディングモード）及びブロックへのピクチャの分割を表すシンタックス要素のための一連の値を含む。したがって、ピクチャ又はブロックをコーディングすることへの言及は、一般に、ピクチャ又はブロックを形成するシンタックス要素のためのコーディング値として理解されるべきである。
【0040】
ＨＥＶＣは、コーディングユニット（ＣＵｓ）、予測ユニット（prediction units、ＰＵｓ）、及び変換ユニット（transform units、ＴＵｓ）を含む、様々なブロックを定義する。ＨＥＶＣによれば、（ビデオエンコーダ２００などの）ビデオコーダは、四分木構造に従ってコーディングツリーユニット（ＣＴＵ）をＣＵに分割する。すなわち、ビデオコーダは、ＣＴＵ及びＣＵを４個の等しい重複しない正方形に分割し、四分木の各ノードは、０個又は４個のいずれかの子ノードを有する。子ノードがないノードは「リーフノード」と呼ばれることがあり、そのようなリーフノードのＣＵは、１つ又は複数のＰＵ、及び／又は、１つ又は複数のＴＵを含んでもよい。ビデオコーダは、ＰＵ及びＴＵを更に分割し得る。例えば、ＨＥＶＣでは、残差四分木（residual quadtree、ＲＱＴ）はＴＵの分割を表す。ＨＥＶＣでは、ＰＵはインター予測データを表し、ＴＵは残差データを表す。イントラ予測されたＣＵは、イントラモード指示などのイントラ予測情報を含む。
【0041】
別の例として、ビデオエンコーダ２００及びビデオデコーダ３００は、ＶＶＣに従って動作するように構成され得る。ＶＶＣによれば、（ビデオエンコーダ２００などの）ビデオコーダは、ピクチャを複数のコーディングツリーユニット（ＣＴＵｓ）に分割する。ビデオエンコーダ２００は、四分木二分木（quadtree-binary tree、ＱＴＢＴ）構造又はマルチタイプツリー（Multi-Type Tree、ＭＴＴ）構造などの木構造に従って、ＣＴＵを分割し得る。ＱＴＢＴ構造は、ＨＥＶＣのＣＵ、ＰＵ、及びＴＵの間の分離などの、複数の区分タイプの概念を排除する。ＱＴＢＴ構造は、２つのレベル、すなわち、四分木分割に従って分割された第１のレベル、及び二分木分割に従って分割された第２のレベルを含む。ＱＴＢＴ構造のルートノードは、ＣＴＵに対応する。二分木のリーフノードは、コーディングユニット（ＣＵｓ）に対応する。
【0042】
ＭＴＴ分割構造では、ブロックは、四分木（quadtree、ＱＴ）分割、二分木（binary tree、ＢＴ）分割、及び１つ又は複数のタイプの三分木（triple tree、ＴＴ）（三元木（ternary tree、ＴＴ）とも呼ばれる）分割を使用して分割され得る。三分木分割又は三元木分割は、ブロックが３個のサブブロックに分けられる分割である。いくつかの例では、三分木分割又は三元木分割は、中心を通って元のブロックを分けることなく、ブロックを３個のサブブロックに分ける。ＭＴＴにおける分割タイプ（例えば、ＱＴ、ＢＴ、及びＴＴ）は、対称又は非対称であり得る。
【0043】
ＡＶ１コーデックに従って動作するとき、ビデオエンコーダ２００及びビデオデコーダ３００は、ブロック中のビデオデータをコーディングするように構成され得る。ＡＶ１では、処理され得る最大コーディングブロックは、スーパーブロックと呼ばれる。ＡＶ１では、スーパーブロックは、１２８×１２８のルーマサンプル又は６４×６４のルーマサンプルのいずれかであり得る。しかしながら、後継ビデオコーディングフォーマット（例えば、ＡＶ２）では、スーパーブロックは、異なる（例えば、より大きい）ルーマサンプルサイズによって定義され得る。いくつかの例では、スーパーブロックは、ブロック４分木のトップレベルである。ビデオエンコーダ２００は、スーパーブロックをより小さいコーディングブロックに更に分割し得る。ビデオエンコーダ２００は、正方形又は非正方形分割を使用してスーパーブロック及び他のコーディングブロックをより小さいブロックに分割し得る。非正方形ブロックは、Ｎ／２×Ｎ、Ｎ×Ｎ／２、Ｎ／４×Ｎ、及びＮ×Ｎ／４ブロックを含み得る。ビデオエンコーダ２００及びビデオデコーダ３００は、コーディングブロックの各々に対して別個の予測及び変換プロセスを実行し得る。
【0044】
ＡＶ１はまた、ビデオデータのタイルを定義する。タイルは、他のタイルとは無関係にコーディングされ得るスーパーブロックの長方形アレイである。すなわち、ビデオエンコーダ２００及びビデオデコーダ３００は、他のタイルからのビデオデータを使用せずにタイル内のコーディングブロックを、それぞれ、符号化及び復号し得る。ただし、ビデオエンコーダ２００及びビデオデコーダ３００は、タイル境界を越えてフィルタ処理を実行し得る。タイルは、サイズが均一であっても不均一であってもよい。タイルベースのコーディングは、エンコーダ及びデコーダ実装形態のために、並列処理及び／又はマルチスレッディングを可能にし得る。
【0045】
いくつかの例では、ビデオエンコーダ２００及びビデオデコーダ３００は、ルミナンス成分及びクロミナンス成分の各々を表すために単一のＱＴＢＴ構造又はＭＴＴ構造を使用してもよく、他の例では、ビデオエンコーダ２００及びビデオデコーダ３００は、ルミナンス成分のための１つのＱＴＢＴ／ＭＴＴ構造及び両方のクロミナンス成分のための別のＱＴＢＴ／ＭＴＴ構造（又はそれぞれのクロミナンス成分のための２つのＱＴＢＴ／ＭＴＴ構造）などの、２つ以上のＱＴＢＴ又はＭＴＴ構造を使用してもよい。
【0046】
ビデオエンコーダ２００及びビデオデコーダ３００は、四分木分割、ＱＴＢＴ分割、ＭＴＴ分割、スーパーブロック分割、又は他の分割構造を使用するように構成され得る。
【0047】
いくつかの例では、ＣＴＵは、ルーマサンプルのコーディングツリーブロック（ＣＴＢ）、３つのサンプルアレイを有するピクチャのクロマサンプルの２つの対応するＣＴＢ、又はモノクロームピクチャ若しくはサンプルをコーディングするために使用される３つの別個の色平面及びシンタックス構造を使用してコーディングされたピクチャのサンプルのＣＴＢを含む。ＣＴＢは、成分をＣＴＢに分けるように分割するような、何らかのＮの値に対するサンプルのＮ×Ｎのブロックであってもよい。成分は、１つのアレイ又は４：２：０、４：２：２、若しくは４：４：４カラーフォーマットでピクチャを構成する３つのアレイ（ルーマ及び２つのクロマ）のうちの１つからの単一のサンプル、あるいはアレイ又はモノクロームフォーマットでピクチャを構成するアレイの単一のサンプルである。いくつかの例では、コーディングブロックは、ＣＴＢをコーディングブロックに分けるように分割するような、いくつかのＭ及びＮの値に対するサンプルのＭ×Ｎのブロックである。
【0048】
ブロック（例えば、ＣＴＵ又はＣＵ）は、ピクチャの中で様々な方法でグループ化され得る。一例として、ブリックは、ピクチャの中の特定のタイル内のＣＴＵ行の長方形領域を指すことがある。タイルは、ピクチャの中の特定のタイル列及び特定のタイル行内のＣＴＵの長方形領域であり得る。タイル列は、ピクチャの高さに等しい高さ及び（例えば、ピクチャパラメータセットの中などの）シンタックス要素によって指定される幅を有する、ＣＴＵの長方形領域を指す。タイル行は、（例えば、ピクチャパラメータセットの中などの）シンタックス要素によって指定される高さ及びピクチャの幅に等しい幅を有する、ＣＴＵの長方形領域を指す。
【0049】
いくつかの例では、タイルは複数のブリックに分割されてもよく、ブリックの各々はタイル内の１つ又は複数のＣＴＵ行を含み得る。複数のブリックに分割されないタイルも、ブリックと呼ばれることがある。しかしながら、タイルの真のサブセットであるブリックは、タイルと呼ばれないことがある。ピクチャの中のブリックは、スライスとしても並べられ得る。スライスは、単一のネットワークアブストラクションレイヤ（network abstraction layer、ＮＡＬ）ユニットの中に独占的に含まれ得る、ピクチャの整数個のブリックであってもよい。いくつかの例では、スライスは、いくつかの完全なタイル、又は１つのタイルの完全なブリックの連続シーケンスのみ、のいずれかを含む。
【0050】
本開示は、垂直次元及び水平次元において（ＣＵ又は他のビデオブロックなどの）ブロックのサンプル次元を指すために、互換的に「Ｎ×Ｎ」及び「Ｎ掛けるＮ」、例えば、１６×１６サンプル又は１６掛ける１６サンプルを使用してもよい。一般に、１６×１６のＣＵは、垂直方向に１６個のサンプル（ｙ＝１６）及び水平方向に１６個のサンプル（ｘ＝１６）を有する。同様に、Ｎ×ＮのＣＵは、一般に、垂直方向にＮ個のサンプル及び水平方向にＮ個のサンプルを有し、Ｎは非負の整数値を表す。ＣＵの中のサンプルは、行及び列をなして並べられてもよい。その上、ＣＵは、必ずしも水平方向において垂直方向における数と同じ数のサンプルを有する必要があるとは限らない。例えば、ＣＵはＮ×Ｍのサンプルを備えてもよく、Ｍは必ずしもＮに等しいとは限らない。
【0051】
ビデオエンコーダ２００は、予測及び／又は残差情報、並びに他の情報を表すＣＵのためのビデオデータを符号化する。予測情報は、ＣＵに対する予測ブロックを形成するためにＣＵがどのように予測されることになるのかを示す。残差情報は、一般に、符号化する前のＣＵのサンプルと予測ブロックとの間のサンプルごとの差分を表す。
【0052】
ＣＵを予測するために、ビデオエンコーダ２００は、一般に、インター予測又はイントラ予測を通してＣＵに対する予測ブロックを形成してもよい。インター予測は、一般に、以前にコーディングされたピクチャのデータからＣＵを予測することを指し、イントラ予測は、一般に、同じピクチャの以前にコーディングされたデータからＣＵを予測することを指す。インター予測を実行するために、ビデオエンコーダ２００は、１つ又は複数の動きベクトルを使用して予測ブロックを生成してもよい。ビデオエンコーダ２００は、一般に、例えば、ＣＵと参照ブロックとの間の差分に関してＣＵと厳密に一致する参照ブロックを識別するために、動き探索を実行し得る。ビデオエンコーダ２００は、参照ブロックが現在のＣＵと厳密に一致するかどうかを決定するために、差分絶対値和（sum of absolute difference、ＳＡＤ）、差分二乗和（sum of squared differences、ＳＳＤ）、平均絶対差（mean absolute difference、ＭＡＤ）、平均二乗差（mean squared differences、ＭＳＤ）、又は他のそのような差分計算を使用して差分メトリックを計算し得る。いくつかの例では、ビデオエンコーダ２００は、単方向予測又は双方向予測を使用して現在のＣＵを予測し得る。
【0053】
ＶＶＣのいくつかの例はまた、インター予測モードと見なされ得るアフィン動き補償モードを提供する。アフィン動き補償モードでは、ビデオエンコーダ２００は、ズームイン若しくはズームアウト、回転、遠近移動、又は他の不規則な動きタイプなどの、非並進運動を表す２つ以上の動きベクトルを決定し得る。
【0054】
イントラ予測を実行するために、ビデオエンコーダ２００は、予測ブロックを生成するためにイントラ予測モードを選択してもよい。ＶＶＣのいくつかの例は、様々な方向モードを含む６７個のイントラ予測モード、並びに平面モード及びＤＣモードを提供する。一般に、ビデオエンコーダ２００は、現在ブロック（例えば、ＣＵのブロック）に対する隣接サンプルを記述し、そこから現在ブロックのサンプルを予測する、イントラ予測モードを選択する。ビデオエンコーダ２００がラスター走査順序（左から右、上から下）でＣＴＵ及びＣＵをコーディングすると仮定すると、そのようなサンプルは一般に、現在ブロックと同じピクチャにおいて、現在ブロックの上、上及び左、又は左にあり得る。
【0055】
ビデオエンコーダ２００は、現在ブロックに対する予測モードを表すデータを符号化する。例えば、インター予測モードの場合、ビデオエンコーダ２００は、様々な利用可能なインター予測モードのうちのどれが使用されるのか、並びに対応するモードに対する動き情報を表すデータを符号化してもよい。単方向又は双方向インター予測の場合、例えば、ビデオエンコーダ２００は、高度動きベクトル予測（advanced motion vector prediction、ＡＭＶＰ）モード又はマージモードを使用して動きベクトルを符号化してもよい。ビデオエンコーダ２００は、アフィン動き補償モードの動きベクトルを符号化するために類似のモードを使用してもよい。
【0056】
ＡＶ１は、ビデオデータのコーディングブロックを符号化及び復号するための２つの一般的な技法を含む。２つの一般的な技法は、イントラ予測（例えば、イントラフレーム予測又は空間予測）及びインター予測（例えば、インターフレーム予測又は時間予測）である。ＡＶ１のコンテキストでは、イントラ予測モードを使用してビデオデータの現在フレームのブロックを予測するとき、ビデオエンコーダ２００及びビデオデコーダ３００は、ビデオデータの他のフレームからのビデオデータを使用しない。たいていのイントラ予測モードでは、ビデオエンコーダ２００は、現在ブロック中のサンプル値と、同じフレーム中の参照サンプルから生成される予測値との間の差分に基づいて、現在フレームのブロックを符号化する。ビデオエンコーダ２００は、イントラ予測モードに基づいて参照サンプルから生成される予測値を決定する。
【0057】
ブロックのイントラ予測又はインター予測などの予測に続いて、ビデオエンコーダ２００はブロックの残差データを計算してもよい。残差ブロックなどの残差データは、ブロックと、対応する予測モードを使用して形成されたそのブロックに対する予測ブロックとの間の、サンプルごとの差分を表す。ビデオエンコーダ２００は、サンプル領域ではなく変換領域において変換データを生成するために、１つ又は複数の変換を残差ブロックに適用してもよい。例えば、ビデオエンコーダ２００は、離散コサイン変換（discrete cosine transform、ＤＣＴ）、整数変換、ウェーブレット変換、又は概念的に類似の変換を残差ビデオデータに適用してもよい。加えて、ビデオエンコーダ２００は、モード依存非分離可能二次変換（mode-dependent non-separable secondary transform、ＭＤＮＳＳＴ）、信号依存変換、カルーネンレーベ変換（Karhunen-Loeve transform、ＫＬＴ）などの二次的な変換を、最初の変換に続いて適用してもよい。ビデオエンコーダ２００は、１つ又は複数の変換の適用に続いて、変換係数を生成する。
【0058】
上述のように、変換係数を生成するための任意の変換に続いて、ビデオエンコーダ２００は、変換係数の量子化を実行してもよい。量子化は、一般に、変換係数を表すために使用されるデータの量をできる限り低減するために変換係数が量子化され、更なる圧縮を行うプロセスを指す。量子化プロセスを実行することによって、ビデオエンコーダ２００は、変換係数の一部又は全てに関連付けられたビット深度を低減し得る。例えば、ビデオエンコーダ２００は、量子化の間にｎビット値をｍビット値に切り捨ててもよく、ｎはｍより大きい。いくつかの例では、量子化を実行するために、ビデオエンコーダ２００は、量子化されるべき値のビットごとの右シフトを実行し得る。
【0059】
量子化に続いて、ビデオエンコーダ２００は、変換係数を走査してもよく、量子化された変換係数を含む２次元行列から１次元ベクトルを生成する。走査は、より高いエネルギー（したがって、より低い周波数）の変換係数をベクトルの前方に置き、より低いエネルギー（したがって、より高い周波数）の変換係数をベクトルの後方に置くように設計され得る。いくつかの例では、ビデオエンコーダ２００は、シリアル化ベクトルを生成し、次いで、ベクトルの量子化された変換係数をエントロピー符号化するために、量子化された変換係数を走査するためのあらかじめ定義された走査順序を使用し得る。他の例では、ビデオエンコーダ２００は、適応走査を実行してもよい。量子化された変換係数を走査して１次元ベクトルを形成した後、ビデオエンコーダ２００は、例えば、コンテキスト適応型バイナリ算術コーディング（context-adaptive binary arithmetic coding、ＣＡＢＡＣ）に従って、１次元ベクトルをエントロピー符号化してもよい。ビデオエンコーダ２００はまた、ビデオデータを復号する際にビデオデコーダ３００が使用する符号化ビデオデータに関連付けられたメタデータを記述するシンタックス要素に対する値をエントロピー符号化してもよい。
【0060】
ＣＡＢＡＣを実行するために、ビデオエンコーダ２００は、コンテキストモデル内のコンテキストを、送信されるべきシンボルに割り当ててもよい。コンテキストは、例えば、シンボルの隣接値が０値化されているか否かに関係し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
【0061】
ビデオエンコーダ２００は更に、ビデオデコーダ３００に対して、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、及びシーケンスベースのシンタックスデータなどのシンタックスデータを、例えば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、又は、シーケンスパラメータセット（sequence parameter set、ＳＰＳ）、ピクチャパラメータセット（picture parameter set、ＰＰＳ）、若しくはビデオパラメータセット（video parameter set、ＶＰＳ）などの他のシンタックスデータにおいて生成し得る。ビデオデコーダ３００は、そのようなシンタックスデータを同様に復号して、対応するビデオデータをどのように復号すべきかを決定してもよい。
【0062】
このようにして、ビデオエンコーダ２００は、符号化ビデオデータ、例えば、ブロック（例えば、ＣＵ）へのピクチャの分割並びにブロックに対する予測情報及び／又は残差情報を記述するシンタックス要素を含む、ビットストリームを生成し得る。最終的に、ビデオデコーダ３００は、ビットストリームを受信し、符号化ビデオデータを復号し得る。
【0063】
一般に、ビデオデコーダ３００は、ビデオエンコーダ２００によって実行されるプロセスに対する相反プロセスを実行して、ビットストリームの符号化ビデオデータを復号する。例えば、ビデオデコーダ３００は、ビデオエンコーダ２００のＣＡＢＡＣ符号化プロセスとは相反ではあるが実質的に類似の方式で、ＣＡＢＡＣを使用してビットストリームのシンタックス要素に対する値を復号してもよい。シンタックス要素は、ＣＴＵのＣＵを定義するために、ＣＴＵへのピクチャの分割、及びＱＴＢＴ構造などの対応する分割構造に従った各ＣＴＵの分割のための、分割情報を定義し得る。シンタックス要素は、ビデオデータのブロック（例えば、ＣＵ）に対する予測情報及び残差情報を更に定義し得る。
【0064】
残差情報は、例えば、量子化された変換係数によって表され得る。ビデオデコーダ３００は、ブロックの量子化された変換係数を逆量子化し逆変換して、ブロックのための残差ブロックを再生し得る。ビデオデコーダ３００は、シグナリングされた予測モード（イントラ予測又はインター予測）及び関係する予測情報（例えば、インター予測の動き情報）を使用して、ブロックに対する予測ブロックを形成する。ビデオデコーダ３００は次いで、予測ブロックと残差ブロックとを（サンプルごとに）組み合わせて、元のブロックを再生し得る。ビデオデコーダ３００は、ブロックの境界に沿った視覚アーチファクトを低減するためのデブロッキングプロセスを実行するなどの、追加の処理を実行してもよい。
【0065】
本開示は全般に、シンタックス要素などの何らかの情報を「シグナリングすること」に言及することがある。「シグナリング」という用語は、一般に、シンタックス要素に対する値、及び／又は符号化ビデオデータを復号するために使用される他のデータの通信を指すことがある。すなわち、ビデオエンコーダ２００は、ビットストリームにおいてシンタックス要素に対する値をシグナリングし得る。一般に、シグナリングは、ビットストリームにおいて値を生成することを指す。上述のように、ソースデバイス１０２は、実質的にリアルタイムで、又は非リアルタイムでビットストリームを宛先デバイス１１６に転送してもよく、これは、例えば、宛先デバイス１１６によって後で取り出すためにシンタックス要素を記憶デバイス１１２に記憶するときに起こることがある。
【0066】
ＣＡＢＡＣは、ＶＶＣにおいて実装されるように、各コンテキストモデルについて２つの確率状態を採用する。ＣＡＢＡＣビン符号化及び復号に使用される確率は、以下に示されるように、２つの確率状態の平均として計算される。
ｓｔａｔｅｉ＝（ｓｔａｔｅｉ［０］＋ｓｔａｔｅｉ［１］）＞＞Ｎ （１）
ここで、ｓｔａｔｅｉは、第ｉのコンテキストモデルの確率状態を意味する。Ｎは、ｓｔａｔｅｉの精度を制御する整数であり、平均を生成する。
ｓｔａｔｅｉ＝（ｓｔａｔｅｉ［０］＋ｓｔａｔｅｉ［１］）＞＞Ｎ （１）
ここで、ｓｔａｔｅｉは、第ｉのコンテキストモデルの確率状態を意味する。Ｎは、ｓｔａｔｅｉの精度を制御する整数であり、平均を生成する。
【0067】
ビデオエンコーダ２００及びビデオデコーダ３００は、ビンが符号化又は復号された後に、それぞれ低レート及び高レートで２つの確率状態を更新するように構成され得る。以下の例では、ｓｔａｔｅｉ［０］はより遅いレートで更新されており、ｓｔａｔｅｉ［１］はより高いレートで適応されている。すなわち、一例では、より遅いレートの状態変数に対する状態値は、より高いレートの状態変数の状態値より多くの以前のビンを考慮に入れ、したがって、典型的には、１つの追加のビンの結果としてより少なく変化する。対照的に、より高いレートの状態変数に対する状態値は、より低いレートの状態変数の状態値より少ない以前のビンを考慮に入れ、したがって、典型的には、１つの追加のビンの結果としてより多く変化する。別の例では、両方のレートは、以前のビンの同じ量に基づいて適応される。
【0068】
ビデオエンコーダ２００及びビデオデコーダ３００は、以下に示されるように確率を更新するように構成され得る。
たった今コーディングされているビンが１に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］＋（（（２１０－１）－ｓｔａｔｅｉ［０］）＞＞ｓｈｉｆｔＬｉ）（２）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］＋（（（２１４－１）－ｓｔａｔｅｉ［１］）＞＞ｓｈｉｆｔＨｉ）（３）
そうではなく、たった今コーディングされているビンが０に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］－（ｓｔａｔｅｉ［０］＞＞ｓｈｉｆｔＬｉ）（４）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］－（ｓｔａｔｅｉ［１］＞＞ｓｈｉｆｔＨｉ）（５）
ｓｈｉｆｔＬｉ及びｓｈｉｆｔＨｉは、第ｉのコンテキストモデルの適応レートを制御するために使用されることに留意されたい。ｓｈｉｆｔＨｉはｓｈｉｆｔＬｉ以上であり、これは、より速い適応を意味する。これらの２つのパラメータは、各コンテキストモデルに対してあらかじめ定義され、ＲＯＭに記憶されるべきである。
たった今コーディングされているビンが１に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］＋（（（２１０－１）－ｓｔａｔｅｉ［０］）＞＞ｓｈｉｆｔＬｉ）（２）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］＋（（（２１４－１）－ｓｔａｔｅｉ［１］）＞＞ｓｈｉｆｔＨｉ）（３）
そうではなく、たった今コーディングされているビンが０に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］－（ｓｔａｔｅｉ［０］＞＞ｓｈｉｆｔＬｉ）（４）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］－（ｓｔａｔｅｉ［１］＞＞ｓｈｉｆｔＨｉ）（５）
ｓｈｉｆｔＬｉ及びｓｈｉｆｔＨｉは、第ｉのコンテキストモデルの適応レートを制御するために使用されることに留意されたい。ｓｈｉｆｔＨｉはｓｈｉｆｔＬｉ以上であり、これは、より速い適応を意味する。これらの２つのパラメータは、各コンテキストモデルに対してあらかじめ定義され、ＲＯＭに記憶されるべきである。
【0069】
本開示の技法によれば、ビデオエンコーダ２００及びビデオデコーダ３００は、より多くの次元の柔軟性を提供することによって更新及び確率状態計算を決定するように構成され得る。開示される技法は２つの手法を含み、それらは別々に又は組み合わせて使用されてもよい。
【0070】
一例では、ビデオエンコーダ２００及びビデオデコーダ３００は、ＶＶＣの場合のように均一平均を行う代わりに、確率計算のために加重平均を決定するように構成され得る。このような技法を以下に示す。
ｓｔａｔｅｉ＝（ｗ１×ｓｔａｔｅｉ［０］＋ｗ２×ｓｔａｔｅｉ［１］）＞＞Ｎ （６）
ここで、ｗ１及びｗ２は、それぞれ２つの確率状態に割り当てられた２つの重みである。
ｓｔａｔｅｉ＝（ｗ１×ｓｔａｔｅｉ［０］＋ｗ２×ｓｔａｔｅｉ［１］）＞＞Ｎ （６）
ここで、ｗ１及びｗ２は、それぞれ２つの確率状態に割り当てられた２つの重みである。
【0071】
また、この手法のいくつかの変形があり、これらは別々に使用されてもよいし、組み合わされてもよい。一例では、（ｗ１，ｗ２）のペアは、コンテキストモデルごとにあらかじめ定義され得る。更に、（ｗ１，ｗ２）は、そのコンテキストモデルが、Ｉスライス、Ｂスライス、又はＰスライスなどの異なるタイプのスライスをコーディングする際に使用されるとき、異なってもよい。別の例では、（ｗ１，ｗ２）のペアは、最小平均二乗誤差など、ある特定の最適化基準によって、符号化又は復号プロセス中に導出されてもよい。別の例では、（ｗ１，ｗ２）のペアは正規化され、これはｗ１＋ｗ２が１．０に等しいことを意味するか、又は正規化されないがｃ０＜ｗ１＋ｗ２＜ｃ１のように制限され得る。別の例では、一般に、（ｗ１，ｗ２）のペアは、実数（浮動小数点）値によって表されるが、実際の実装形態では、スケーリングによって整数に変換される。したがって、確率計算では、正規化のために適切なシフトを使用することができる。
【0072】
本開示の他の技法によれば、ビデオエンコーダ２００及びビデオデコーダ３００は、ｓｈｉｆｔＬｉ及びｓｈｉｆｔＨｉを調整することによって、遅い適応レート及び速い適応レートをローカルアクティビティ（例えば、所与のコンテキストのための全てのビンとは対照的なビンのあるローカルシーケンス）に適応させるように構成され得る。提案される確率更新プロセスを以下に示す。
たった今コーディングされているビンが１に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］＋（（（２１０－１）－ｓｔａｔｅｉ［０］）＞＞（ｓｈｉｆｔＬｉ＋ｄｅｌｔａＬｉ））、（７）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］＋（（（２１４－１）－ｓｔａｔｅｉ［１］）＞＞（ｓｈｉｆｔＨｉ＋ｄｅｌｔａＨｉ））、（８）
そうではなく、たった今コーディングされているビンが０に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］－（ｓｔａｔｅｉ［０］＞＞（ｓｈｉｆｔＬｉ＋ｄｅｌｔａＬｉ））、（９）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］－（ｓｔａｔｅｉ［１］＞＞（ｓｈｉｆｔＨｉ＋ｄｅｌｔａＨｉ））、（１０）
たった今コーディングされているビンが１に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］＋（（（２１０－１）－ｓｔａｔｅｉ［０］）＞＞（ｓｈｉｆｔＬｉ＋ｄｅｌｔａＬｉ））、（７）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］＋（（（２１４－１）－ｓｔａｔｅｉ［１］）＞＞（ｓｈｉｆｔＨｉ＋ｄｅｌｔａＨｉ））、（８）
そうではなく、たった今コーディングされているビンが０に等しい場合、
ｓｔａｔｅｉ［０］＝ｓｔａｔｅｉ［０］－（ｓｔａｔｅｉ［０］＞＞（ｓｈｉｆｔＬｉ＋ｄｅｌｔａＬｉ））、（９）
ｓｔａｔｅｉ［１］＝ｓｔａｔｅｉ［１］－（ｓｔａｔｅｉ［１］＞＞（ｓｈｉｆｔＨｉ＋ｄｅｌｔａＨｉ））、（１０）
【0073】
式（７）～（１０）において、ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉは整数であり、－３～３、－５～５、及び－７～７などの範囲内にあり得る。ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉの値は、コンテキストモデルの先行するＭ個のビンによって決定されたローカルアクティビティに適応し得る。いくつかの実装形態では、Ｍの典型的な値は１６を超えないことがある。図２に示される例のように、コンテキストモデルが与えられると、次のビン（ビン１３０）を処理する前に、確率状態は、式（７）～（１０）による更新であり、ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉは、先行するＭビンメモリによって決定される。
【0074】
Ｍビンメモリの２Ｍ個の可能な組み合わせが存在する。例えば、Ｍが１０に等しい場合、１０２４個の異なるＭビンメモリがあり、各メモリは、次のビン１３０に対する一意の条件（又はコンテキスト）を示す。２Ｍエントリルックアップテーブルが、正しいｄｅｌｔａＬｉ及びｄｅｌｔａＨｉを検索するために各コンテキストモデルに対して開発され、したがって、バイナリ表現がＭビンメモリである整数インデックスを使用してテーブルをルックアップし、ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉを見つけることができる。
【0075】
図３は、本開示の技法に従って使用され得る２Ｄルックアップテーブル１４０の一例を示す。２Ｍエントリルックアップテーブルが各コンテキストモデルに対して開発されるので、ルックアップテーブルは最終的に２Ｄであり、コンテキストモデルＩＤ及びＭビンメモリを検索するための２つのインデックスとして有する。したがって、ビデオエンコーダ２００及びビデオデコーダ３００は、コンテキストモデルの識別子及び最後のＭ個のビンに基づいてｄｅｌｔａＬｉ及びｄｅｌｔａＨｉの値を決定するように構成され得る。図３の例では、（ｃｔｘとして示される）コンテキストモデルの識別子がｘ軸上にあり、２Ｍ個のＭビンメモリがｙ軸上に示されている。ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉの値は、図３に示されるように、バイト（８ビット）エントリ１４２にパックされ、ｄｅｌｔａＬｉ及びｄｅｌｔａＨｉはそれぞれ４ビットである。
【0076】
図４は、本開示の技法を実行し得る、例示的なビデオエンコーダ２００を示すブロック図である。図４は、説明のために提供され、本開示において広く例示されて説明される技法を限定するものと見なされるべきでない。説明の目的で、本開示は、ＶＶＣ（開発中のＩＴＵ－Ｔ Ｈ．２６６）及びＨＥＶＣ（ＩＴＵ－Ｔ Ｈ．２６５）の技法に従って、ビデオエンコーダ２００について説明する。しかしながら、本開示の技法は、他のビデオコーディング規格、並びに、ＡＶ１及びＡＶ１の後継のビデオコーディングフォーマットなどのビデオコーディングフォーマットに構成された、ビデオ符号化デバイスによって実行され得る。
【0077】
図４の例では、ビデオエンコーダ２００は、ビデオデータメモリ２３０、モード選択ユニット２０２、残差生成ユニット２０４、変換処理ユニット２０６、量子化ユニット２０８、逆量子化ユニット２１０、逆変換処理ユニット２１２、再構成ユニット２１４、フィルタユニット２１６、復号ピクチャバッファ（decoded picture buffer、ＤＰＢ）２１８、及びエントロピー符号化ユニット２２０を含む。ビデオデータメモリ２３０、モード選択ユニット２０２、残差生成ユニット２０４、変換処理ユニット２０６、量子化ユニット２０８、逆量子化ユニット２１０、逆変換処理ユニット２１２、再構成ユニット２１４、フィルタユニット２１６、ＤＰＢ２１８、及びエントロピー符号化ユニット２２０のうちのいずれか又は全てが、１つ若しくは複数のプロセッサに又は処理回路に実装され得る。例えば、ビデオエンコーダ２００のユニットは、ハードウェア回路の一部としての１つ又は複数の回路若しくは論理要素として、又はプロセッサ、ＡＳＩＣ、若しくはＦＰＧＡの一部として実装され得る。その上、ビデオエンコーダ２００は、これら及び他の機能を実行するための追加若しくは代替のプロセッサ又は処理回路を含んでもよい。
【0078】
ビデオデータメモリ２３０は、ビデオエンコーダ２００の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオエンコーダ２００は、ビデオデータメモリ２３０に記憶されたビデオデータを、例えば、ビデオソース１０４（図１）から受信し得る。ＤＰＢ２１８は、ビデオエンコーダ２００によって後続のビデオデータの予測において使用するための参照ビデオデータを記憶する、参照ピクチャメモリとして機能してもよい。ビデオデータメモリ２３０及びＤＰＢ２１８は、同期ダイナミックランダムアクセスメモリ（synchronous dynamic random access memory、ＳＤＲＡＭ）を含むＤＲＡＭ、磁気抵抗ＲＡＭ（magnetoresistive RAM、ＭＲＡＭ）、抵抗ＲＡＭ（resistive RAM、ＲＲＡＭ）、又は他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ２３０及びＤＰＢ２１８は、同じメモリデバイス又は別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ２３０は、示されるように、ビデオエンコーダ２００の他の構成要素とともにオンチップであってもよく、又はそれらの構成要素に対してオフチップであってもよい。
【0079】
本開示では、ビデオデータメモリ２３０への言及は、そのように特に記載されない限り、ビデオエンコーダ２００の内部のメモリに、又はそのように特に記載されない限り、ビデオエンコーダ２００の外部のメモリに限定されるものとして、解釈されるべきではない。むしろ、ビデオデータメモリ２３０への言及は、ビデオエンコーダ２００が符号化のために受信するビデオデータ（例えば、符号化されるべき現在ブロックに対するビデオデータ）を記憶する参照メモリとして理解されるべきである。図１のメモリ１０６はまた、ビデオエンコーダ２００の様々なユニットからの出力の一時的な記憶を提供し得る。
【0080】
図４の様々なユニットは、ビデオエンコーダ２００によって実行される動作を理解する助けとなるように示される。ユニットは、固定機能回路、プログラマブル回路、又はそれらの組み合わせとして実装され得る。固定機能回路は、特定の機能を提供する回路を指し、実行され得る動作があらかじめ設定されている。プログラマブル回路は、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能を提供する。例えば、プログラマブル回路は、ソフトウェア又はファームウェアの命令によって定義される方式でプログラマブル回路を動作させるソフトウェア又はファームウェアを実行し得る。固定機能回路は（例えば、パラメータを受信するか又はパラメータを出力する）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは一般に不変である。いくつかの例では、ユニットのうちの１つ又は複数は、異なる回路ブロック（固定機能又はプログラマブル）であってもよく、いくつかの例では、ユニットのうちの１つ又は複数は集積回路であってもよい。
【0081】
ビデオエンコーダ２００は、算術論理ユニット（arithmetic logic units、ＡＬＵｓ）、基本機能ユニット（elementary function units、ＥＦＵｓ）、デジタル回路、アナログ回路、及び／又は、プログラマブル回路から形成されるプログラマブルコアを含み得る。ビデオエンコーダ２００の動作がプログラマブル回路によって実行されるソフトウェアを使用して実行される例では、メモリ１０６（図１）が、ビデオエンコーダ２００が受信及び実行するソフトウェアの命令（例えば、オブジェクトコード）を記憶してもよく、又はビデオエンコーダ２００内の別のメモリ（図示せず）が、そのような命令を記憶してもよい。
【0082】
ビデオデータメモリ２３０は、受信されたビデオデータを記憶するように構成されている。ビデオエンコーダ２００は、ビデオデータメモリ２３０からビデオデータのピクチャを取り出し、ビデオデータを残差生成ユニット２０４及びモード選択ユニット２０２に提供してもよい。ビデオデータメモリ２３０中のビデオデータは、符号化されるべき未加工のビデオデータであってもよい。
【0083】
モード選択ユニット２０２は、動き推定ユニット２２２、動き補償ユニット２２４、及びイントラ予測ユニット２２６を含む。モード選択ユニット２０２は、他の予測モードに従ってビデオ予測を実行する追加の機能ユニットを含んでもよい。例として、モード選択ユニット２０２は、パレットユニット、（動き推定ユニット２２２及び／又は動き補償ユニット２２４の一部であり得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（linear model、ＬＭ）ユニットなどを含んでもよい。
【0084】
モード選択ユニット２０２は一般に、複数の符号化パスを協調させて、符号化パラメータの組み合わせと、そのような組み合わせに対して結果として得られるレート歪み値を試験する。符号化パラメータは、ＣＵへのＣＴＵの分割、ＣＵに対する予測モード、ＣＵの残差データに対する変換タイプ、ＣＵの残差データに対する量子化パラメータなどを含んでもよい。モード選択ユニット２０２は最終的に、他の試験された組み合わせより良いレート歪み値を有する符号化パラメータの組み合わせを選択し得る。
【0085】
ビデオエンコーダ２００は、ビデオデータメモリ２３０から取り出されたピクチャを一連のＣＴＵに分割し、１つ又は複数のＣＴＵをスライス内にカプセル化してもよい。モード選択ユニット２０２は、上述のＭＴＴ構造、ＱＴＢＴ構造、スーパーブロック構造、又は四分木構造など、木構造に従ってピクチャのＣＴＵを分割し得る。上記で説明されたように、ビデオエンコーダ２００は、木構造に従ってＣＴＵを分割することから１つ又は複数のＣＵを形成し得る。そのようなＣＵは、一般に、「ビデオブロック」又は「ブロック」と呼ばれることもある。
【0086】
一般に、モード選択ユニット２０２はまた、現在ブロック（例えば、現在のＣＵ、又はＨＥＶＣでは、ＰＵ及びＴＵの重複部分）に対する予測ブロックを生成するように、その構成要素（例えば、動き推定ユニット２２２、動き補償ユニット２２４、及びイントラ予測ユニット２２６）を制御する。現在ブロックのインター予測の場合、動き推定ユニット２２２は、１つ又は複数の参照ピクチャ（例えば、ＤＰＢ２１８内に記憶されている１つ又は複数の以前にコーディングされたピクチャ）の中の１つ又は複数の厳密に一致する参照ブロックを識別するために、動き探索を実行し得る。具体的には、動き推定ユニット２２２は、例えば、差分絶対値和（ＳＡＤ）、差分二乗和（ＳＳＤ）、平均絶対差（ＭＡＤ）、平均二乗差（ＭＳＤ）などに従って、可能性のある参照ブロックが現在ブロックとどれだけ類似しているかを表す値を計算し得る。動き推定ユニット２２２は一般に、現在ブロックと検討されている参照ブロックとの間のサンプルごとの差分を使用して、これらの計算を実行し得る。動き推定ユニット２２２は、現在ブロックと最も厳密に一致する参照ブロックを示す、これらの計算に起因する最低の値を有する参照ブロックを識別し得る。
【0087】
動き推定ユニット２２２は、現在ピクチャの中の現在ブロックの位置に対する参照ピクチャの中の参照ブロックの位置を定義する、１つ又は複数の動きベクトル（ＭＶｓ）を形成し得る。動き推定ユニット２２２は、次いで、動きベクトルを動き補償ユニット２２４に提供し得る。例えば、単方向のインター予測の場合、動き推定ユニット２２２は単一の動きベクトルを提供してもよく、一方、双方向インター予測の場合、動き推定ユニット２２２は２つの動きベクトルを提供してもよい。動き補償ユニット２２４は、次いで、動きベクトルを使用して予測ブロックを生成し得る。例えば、動き補償ユニット２２４は、動きベクトルを使用して参照ブロックのデータを取り出してもよい。別の例として、動きベクトルが小数サンプル精度を有する場合、動き補償ユニット２２４は、１つ又は複数の補間フィルタに従って、予測ブロックに対する値を補間し得る。その上、双方向インター予測の場合、動き補償ユニット２２４は、それぞれの動きベクトルによって識別される２つの参照ブロックに対するデータを取り出し、例えば、サンプルごとの平均又は加重平均を通じて、取り出されたデータを組み合わせ得る。
【0088】
動き推定ユニット２２２及び動き補償ユニット２２４は、ＡＶ１ビデオコーディングフォーマットに従って動作するとき、並進動き補償、アフィン動き補償、重複ブロック動き補償（overlapped block motion compensation、ＯＢＭＣ）、及び／又は合成インター－イントラ予測を使用して、ビデオデータのコーディングブロック（例えば、ルーマコーディングブロックとクロマコーディングブロックの両方）を符号化するように構成され得る。
【0089】
別の例として、イントラ予測又はイントラ予測コーディングの場合、イントラ予測ユニット２２６は、現在ブロックに隣接するサンプルから予測ブロックを生成し得る。例えば、方向モードの場合、イントラ予測ユニット２２６は一般に、予測ブロックを作り出すために、隣接サンプルの値を数学的に組み合わせて、現在ブロックにわたって定められた方向においてこれらの計算された値をポピュレートし得る。別の例として、ＤＣモードの場合、イントラ予測ユニット２２６は、現在ブロックに対する隣接サンプルの平均を計算し、予測ブロックの各サンプルに対するこの得られた平均を含むように予測ブロックを生成し得る。
【0090】
イントラ予測ユニット２２６は、ＡＶ１ビデオコーディングフォーマットに従って動作する場合、方向性イントラ予測、非方向性イントラ予測、再帰的フィルタイントラ予測、ルーマからクロマ（chroma-from-luma、ＣＦＬ）予測、イントラブロックコピー（intra block copy、ＩＢＣ）、及び／又はカラーパレットモードを使用して、ビデオデータのコーディングブロック（例えば、ルーマコーディングブロックとクロマコーディングブロックとの両方）を符号化するように構成され得る。モード選択ユニット２０２は、他の予測モードに従ってビデオ予測を実行する追加の機能ユニットを含んでもよい。
【0091】
モード選択ユニット２０２は、予測ブロックを残差生成ユニット２０４に提供する。残差生成ユニット２０４は、ビデオデータメモリ２３０から現在ブロックの未加工の符号化されていないバージョン、及びモード選択ユニット２０２から予測ブロックを受信する。残差生成ユニット２０４は、現在ブロックと予測ブロックとのサンプルごとの差分を計算する。得られるサンプルごとの差分は、現在ブロックに対する残差ブロックを定義する。いくつかの例では、残差生成ユニット２０４はまた、残差差分パルスコード変調（residual differential pulse code modulation、ＲＤＰＣＭ）を使用して残差ブロックを生成するために、残差ブロックの中のサンプル値の間の差分を決定し得る。いくつかの例では、残差生成ユニット２０４は、バイナリ減算を実行する１つ又は複数の減算器回路を使用して形成され得る。
【0092】
モード選択ユニット２０２がＣＵをＰＵへと分割する例では、各ＰＵは、ルーマ予測ユニット及び対応するクロマ予測ユニットに関連付けられ得る。ビデオエンコーダ２００及びビデオデコーダ３００は、様々なサイズを有するＰＵをサポートすることができる。前述のように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指すことがあり、ＰＵのサイズは、ＰＵのルーマ予測ユニットのサイズを指すことがある。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２００は、イントラ予測に対して２Ｎ×２Ｎ又はＮ×ＮのＰＵサイズ、及びインター予測に対して２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、又は類似の、対称のＰＵサイズをサポートし得る。ビデオエンコーダ２００及びビデオデコーダ３００はまた、インター予測に対して２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、及びｎＲ×２ＮのＰＵサイズのための非対称分割をサポートし得る。
【0093】
モード選択ユニット２０２がＣＵをＰＵに更に分割しない例では、各ＣＵはルーマコーディングブロック及び対応するクロマコーディングブロックに関連付けられ得る。上記のように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指すことがある。ビデオエンコーダ２００及びビデオデコーダ３００は、２Ｎ×２Ｎ、２Ｎ×Ｎ、又はＮ×２ＮのＣＵサイズをサポートしてもよい。
【0094】
いくつかの例として、イントラブロックコピーモードコーディング、アフィンモードコーディング、及び線形モデル（ＬＭ）モードコーディングなどの他のビデオコーディング技法の場合、モード選択ユニット２０２は、コーディング技法に関連付けられたそれぞれのユニットを介して、符号化されている現在ブロックに対する予測ブロックを生成する。パレットモードコーディングなどのいくつかの例では、モード選択ユニット２０２は、予測ブロックを生成しなくてもよく、代わりに、選択されたパレットに基づいてブロックを再構成する方式を示すシンタックス要素を生成してもよい。そのようなモードでは、モード選択ユニット２０２は、これらのシンタックス要素を符号化されるようにエントロピー符号化ユニット２２０に提供し得る。
【0095】
上記で説明されたように、残差生成ユニット２０４は、現在ブロック及び対応する予測ブロックに対するビデオデータを受信する。残差生成ユニット２０４は次いで、現在ブロックに対する残差ブロックを生成する。残差ブロックを生成するために、残差生成ユニット２０４は、予測ブロックと現在ブロックとの間のサンプルごとの差分を計算する。
【0096】
変換処理ユニット２０６は、変換係数のブロック（本明細書では「変換係数ブロック」と呼ばれる）を生成するために、１つ又は複数の変換を残差ブロックに適用する。変換処理ユニット２０６は、変換係数ブロックを形成するために、様々な変換を残差ブロックに適用し得る。例えば、変換処理ユニット２０６は、離散コサイン変換（ＤＣＴ）、方向変換、カルーネンレーベ変換（ＫＬＴ）、又は概念的に類似の変換を残差ブロックに適用し得る。いくつかの例では、変換処理ユニット２０６は、複数の変換、例えば、１次変換及び回転変換などの２次変換を、残差ブロックに対して実行し得る。いくつかの例では、変換処理ユニット２０６は、変換を残差ブロックに適用しない。
【0097】
変換処理ユニット２０６は、ＡＶ１に従って動作する場合、（本明細書では「変換係数ブロック」と呼ばれる）変換係数のブロックを生成するために、１つ又は複数の変換を残差ブロックに適用し得る。変換処理ユニット２０６は、変換係数ブロックを形成するために、様々な変換を残差ブロックに適用し得る。例えば、変換処理ユニット２０６は、離散コサイン変換（ＤＣＴ）と、非対称離散サイン変換（asymmetric discrete sine transform、ＡＤＳＴ）と、反転ＡＤＳＴ（例えば、逆順におけるＡＤＳＴ）と、恒等変換（identity transform、ＩＤＴＸ）とを含み得る、水平／垂直変換組み合わせを適用し得る。恒等変換を使用する場合、変換は、垂直方向又は水平方向のうちの１つにおいてスキップされる。いくつかの例では、変換処理はスキップされてもよい。
【0098】
量子化ユニット２０８は、変換係数ブロックにおける変換係数を量子化して、量子化された変換係数ブロックを生成してもよい。量子化ユニット２０８は、現在ブロックに関連付けられた量子化パラメータ（quantization parameter、ＱＰ）値に従って、変換係数ブロックの変換係数を量子化し得る。ビデオエンコーダ２００は（例えば、モード選択ユニット２０２を介して）、ＣＵに関連付けられたＱＰ値を調整することによって、現在ブロックに関連付けられた変換係数ブロックに適用される量子化の程度を調整し得る。量子化は情報の損失をもたらすことがあり、したがって、量子化された変換係数は、変換処理ユニット２０６によって生成された元の変換係数より精度が低いことがある。
【0099】
逆量子化ユニット２１０及び逆変換処理ユニット２１２は、それぞれ、逆量子化及び逆変換を量子化された変換係数ブロックに適用して、変換係数ブロックから残差ブロックを再構成し得る。再構成ユニット２１４は、モード選択ユニット２０２によって生成される再構成された残差ブロック及び予測ブロックに基づいて、（ある程度の歪みを伴う可能性があるが）現在ブロックに対応する再構成されたブロックを生成し得る。例えば、再構成ユニット２１４は、再構成されたブロックを生成するために、再構成された残差ブロックのサンプルを、モード選択ユニット２０２によって生成された予測ブロックからの対応するサンプルに加算し得る。
【0100】
フィルタユニット２１６は、再構成されたブロックに対して１つ又は複数のフィルタ動作を実行し得る。例えば、フィルタユニット２１６は、ＣＵのエッジに沿ったブロッキネスアーチファクトを低減するためにデブロッキング動作を実行し得る。フィルタユニット２１６の動作は、いくつかの例では、スキップされてもよい。
【0101】
フィルタユニット２１６は、ＡＶ１に従って動作する場合、再構成されたブロックに対して１つ又は複数のフィルタ動作を実行し得る。例えば、フィルタユニット２１６は、ＣＵのエッジに沿ったブロッキネスアーチファクトを低減するためにデブロッキング動作を実行し得る。他の例では、フィルタユニット２１６は、制約付き方向性強調フィルタ（constrained directional enhancement filter、ＣＤＥＦ）を適用してもよく、これは、デブロッキングの後に適用されてもよく、推定されたエッジ方向に基づく、分離不可能、非線形、ローパス方向性フィルタの適用を含み得る。フィルタユニット２１６はまた、ループ復元フィルタを含んでもよく、これは、ＣＤＥＦの後に適用され、分離可能対称正規化ウィーナーフィルタ又はデュアル自己誘導フィルタを含み得る。
【0102】
ビデオエンコーダ２００は、再構成されたブロックをＤＰＢ２１８に記憶する。例えば、フィルタユニット２１６の動作が実行されない例では、再構成ユニット２１４が、再構成されたブロックをＤＰＢ２１８に記憶し得る。フィルタユニット２１６の動作が実行される例では、フィルタユニット２１６が、フィルタ処理された再構成されたブロックをＤＰＢ２１８に記憶し得る。動き推定ユニット２２２及び動き補償ユニット２２４は、後で符号化されるピクチャのブロックをインター予測するために、再構成された（かつ、フィルタ処理された可能性のある）ブロックから形成された参照ピクチャをＤＰＢ２１８から取り出し得る。加えて、イントラ予測ユニット２２６は、現在ピクチャの中の他のブロックをイントラ予測するために、ＤＰＢ２１８内の、現在ピクチャの再構成されたブロックを使用し得る。
【0103】
一般に、エントロピー符号化ユニット２２０は、ビデオエンコーダ２００の他の機能構成要素から受信されたシンタックス要素をエントロピー符号化し得る。例えば、エントロピー符号化ユニット２２０は、量子化ユニット２０８からの量子化された変換係数ブロックをエントロピー符号化し得る。別の例として、エントロピー符号化ユニット２２０は、モード選択ユニット２０２からの予測シンタックス要素（例えば、インター予測のための動き情報又はイントラ予測のためのイントラモード情報）をエントロピー符号化し得る。エントロピー符号化ユニット２２０は、エントロピー符号化データを生成するために、ビデオデータの別の例であるシンタックス要素に対して１つ又は複数のエントロピー符号化動作を実行し得る。例えば、エントロピー符号化ユニット２２０は、コンテキスト適応型可変長コーディング（context-adaptive variable length coding、ＣＡＶＬＣ）動作、ＣＡＢＡＣ動作、可変長－可変長（variable-to-variable、Ｖ２Ｖ）コーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング（syntax-based context-adaptive binary arithmetic coding、ＳＢＡＣ）動作、確率間隔分割エントロピー（Probability Interval Partitioning Entropy、ＰＩＰＥ）コーディング動作、指数ゴロム符号化動作、又は別のタイプのエントロピー符号化動作を、データに対して実行し得る。いくつかの例では、エントロピー符号化ユニット２２０は、シンタックス要素がエントロピー符号化されないバイパスモードで動作し得る。
【0104】
ビデオエンコーダ２００は、スライス又はピクチャのブロックを再構成するために必要とされるエントロピー符号化シンタックス要素を含むビットストリームを出力し得る。具体的には、エントロピー符号化ユニット２２０がビットストリームを出力してもよい。
【0105】
エントロピー符号化ユニット２２０は、ＡＶ１に従って、シンボル対シンボル適応マルチシンボル算術コーダ（symbol-to-symbol adaptive multi-symbol arithmetic coder）として構成され得る。ＡＶ１におけるシンタックス要素はＮ個の要素のアルファベットを含み、コンテキスト（例えば、確率モデル）はＮ個の確率のセットを含む。エントロピー符号化ユニット２２０は、確率をｎビット（例えば、１５ビット）累積分布関数（cumulative distribution functions、ＣＤＦｓ）として記憶し得る。エントロピー符号化ユニット２２は、コンテキストを更新するために、アルファベットサイズに基づく更新ファクタを用いて、再帰的スケーリングを実行し得る。
【0106】
上記で説明された動作は、ブロックに関して説明されている。そのような説明は、ルーマコーディングブロック及び／又はクロマコーディングブロックのための動作であるものとして理解されるべきである。上記で説明されたように、いくつかの例では、ルーマコーディングブロック及びクロマコーディングブロックは、ＣＵのルーマ成分及びクロマ成分である。いくつかの例では、ルーマコーディングブロック及びクロマコーディングブロックは、ＰＵのルーマ成分及びクロマ成分である。
【0107】
いくつかの例では、ルーマコーディングブロックに関して実行される動作は、クロマコーディングブロックに対して繰り返される必要はない。一例として、ルーマコーディングブロックのための動きベクトル（ＭＶ）及び参照ピクチャを識別する動作が、クロマブロックのためのＭＶ及び参照ピクチャを識別するために繰り返される必要はない。むしろ、ルーマコーディングブロックのためのＭＶは、クロマブロックのためのＭＶを決定するためにスケーリングされてもよく、参照ピクチャは同じであってもよい。別の例として、イントラ予測プロセスは、ルーマコーディングブロック及びクロマコーディングブロックについて同じであってもよい。
【0108】
ビデオエンコーダ２００は、ビデオデータを記憶するように構成されたメモリと、回路に実装され、本開示で説明される任意の技法に従ってシンボルが特定の値を有する確率を計算し、シンボルが特定の値を有する確率に従ってシンボルをバイナリ算術コーディングするように構成された１つ又は複数の処理ユニットとを含む、ビデオデータを符号化するように構成されたデバイスの一例を表す。
【0109】
図５は、本開示の技法を実行し得る、例示的なビデオデコーダ３００を示すブロック図である。図５は、説明のために提供され、本開示において広く例示されて説明される技法を限定するものではない。説明のために、本開示は、ＶＶＣ（開発中のＩＴＵ－Ｔ Ｈ．２６６）、及びＨＥＶＣ（ＩＴＵ－Ｔ Ｈ．２６５）の技法によるビデオデコーダ３００について説明する。しかしながら、本開示の技法は、他のビデオコーディング規格へと構成されたビデオコーディングデバイスによって実行され得る。
【0110】
図５の例では、ビデオデコーダ３００は、コーディングされたピクチャバッファ（coded picture buffer、ＣＰＢ）メモリ３２０、エントロピー復号ユニット３０２、予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構成ユニット３１０、フィルタユニット３１２、及び復号ピクチャバッファ（decoded picture buffer、ＤＰＢ）３１４を含む。ＣＰＢメモリ３２０、エントロピー復号ユニット３０２、予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構成ユニット３１０、フィルタユニット３１２、及びＤＰＢ３１４のいずれか又は全てが、１つ又は複数のプロセッサに又は処理回路に実装され得る。例えば、ビデオデコーダ３００のユニットは、ハードウェア回路の一部としての１つ又は複数の回路若しくは論理要素として、又はプロセッサ、ＡＳＩＣ、若しくはＦＰＧＡの一部として実装され得る。その上、ビデオデコーダ３００は、これらの機能及び他の機能を実行する追加若しくは代替のプロセッサ又は処理回路を含んでもよい。
【0111】
予測処理ユニット３０４は、動き補償ユニット３１６及びイントラ予測ユニット３１８を含む。予測処理ユニット３０４は、他の予測モードに従って予測を実行する追加のユニットを含み得る。例として、予測処理ユニット３０４は、パレットユニット、（動き補償ユニット３１６の一部を形成し得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ）ユニットなどを含んでもよい。他の例では、ビデオデコーダ３００は、より多い、より少ない、又は異なる機能構成要素を含んでもよい。
【0112】
動き補償ユニット３１６は、ＡＶ１に従って動作するとき、上記で説明されたように、並進動き補償、アフィン動き補償、ＯＢＭＣ、及び／又は合成インター－イントラ予測を使用して、ビデオデータのコーディングブロック（例えば、ルーマコーディングブロックとクロマコーディングブロックの両方）を復号するように構成され得る。イントラ予測ユニット３１８は、上記で説明されたように、方向性イントラ予測、非方向性イントラ予測、再帰的フィルタイントラ予測、ＣＦＬ、イントラブロックコピー（ＩＢＣ）、及び／又はカラーパレットモードを使用して、ビデオデータのコーディングブロック（例えば、ルーマコーディングブロックとクロマコーディングブロックの両方）を復号するように構成され得る。
【0113】
ＣＰＢメモリ３２０は、ビデオデコーダ３００の構成要素によって復号されるべき符号化されたビデオビットストリームなどのビデオデータを記憶してもよい。ＣＰＢメモリ３２０内に記憶されたビデオデータは、例えば、コンピュータ可読媒体１１０（図１）から取得され得る。ＣＰＢメモリ３２０は、符号化されたビデオビットストリームからの符号化ビデオデータ（例えば、シンタックス要素）を記憶するＣＰＢを含み得る。また、ＣＰＢメモリ３２０は、ビデオデコーダ３００の様々なユニットからの出力を表す一時的なデータなど、コーディングされたピクチャのシンタックス要素以外のビデオデータを記憶し得る。ＤＰＢ３１４は、一般に、符号化されたビデオビットストリームの後続のデータ又はピクチャを復号するときにビデオデコーダ３００が参照ビデオデータとして出力及び／又は使用し得る復号されたピクチャを記憶する。ＣＰＢメモリ３２０及びＤＰＢ３１４は、ＳＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、又は他のタイプのメモリデバイスなどを含む、ＤＲＡＭなどの様々なメモリデバイスのいずれかによって形成され得る。ＣＰＢメモリ３２０及びＤＰＢ３１４は、同じメモリデバイス又は別個のメモリデバイスによって提供され得る。様々な例では、ＣＰＢメモリ３２０は、ビデオデコーダ３００の他の構成要素とともにオンチップであってもよく、又はそれらの構成要素に対してオフチップであってもよい。
【0114】
追加又は代替として、いくつかの例では、ビデオデコーダ３００は、メモリ１２０（図１）からのコーディングされたビデオデータを取り出し得る。すなわち、メモリ１２０は、ＣＰＢメモリ３２０について上述されたようなデータを記憶し得る。同様に、メモリ１２０は、ビデオデコーダ３００の機能の一部又は全てがビデオデコーダ３００の処理回路によって実行されるべきソフトウェアにおいて実装されるとき、ビデオデコーダ３００によって実行されるべき命令を記憶し得る。
【0115】
図５に示される様々なユニットは、ビデオデコーダ３００によって実行される動作を理解する助けとなるように示されている。ユニットは、固定機能回路、プログラマブル回路、又はそれらの組み合わせとして実装され得る。図４と同様に、固定機能回路は、特定の機能を提供する回路を指し、実行され得る動作があらかじめ設定されている。プログラマブル回路は、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能を提供する。例えば、プログラマブル回路は、ソフトウェア又はファームウェアの命令によって定義される方式でプログラマブル回路を動作させるソフトウェア又はファームウェアを実行し得る。固定機能回路は（例えば、パラメータを受信するか又はパラメータを出力する）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは一般に不変である。いくつかの例では、ユニットのうちの１つ又は複数は、異なる回路ブロック（固定機能又はプログラマブル）であってもよく、いくつかの例では、ユニットのうちの１つ又は複数は集積回路であってもよい。
【0116】
ビデオデコーダ３００は、ＡＬＵ、ＥＦＵ、デジタル回路、アナログ回路、及び／又は、プログラマブル回路から形成されるプログラマブルコアを含み得る。ビデオデコーダ３００の動作が、プログラマブル回路上で実行するソフトウェアによって実行される例では、オンチップメモリ又はオフチップメモリが、ビデオデコーダ３００が受信及び実行するソフトウェアの命令（例えば、オブジェクトコード）を記憶してもよい。
【0117】
エントロピー復号ユニット３０２は、シンタックス要素を再生するために、符号化ビデオデータをＣＰＢから受信し、ビデオデータをエントロピー復号してもよい。予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構成ユニット３１０、及びフィルタユニット３１２は、ビットストリームから抽出されたシンタックス要素に基づいて、復号されたビデオデータを生成し得る。
【0118】
一般に、ビデオデコーダ３００は、ブロックごとにピクチャを再構成する。ビデオデコーダ３００は、各ブロックに対して再構成動作を個別に実行し得る（現在再構成されているブロック、すなわち復号されているブロックは、「現在ブロック」と呼ばれることがある）。
【0119】
エントロピー復号ユニット３０２は、量子化された変換係数ブロックの量子化された変換係数、並びに量子化パラメータ（ＱＰ）及び／又は変換モード指示（単数若しくは複数）などの変換情報を定義する、シンタックス要素をエントロピー復号してもよい。逆量子化ユニット３０６は、量子化の程度、及び同様に逆量子化ユニット３０６が適用すべき逆量子化の程度を決定するために、量子化された変換係数ブロックに関連付けられたＱＰを使用してもよい。逆量子化ユニット３０６は、例えば、量子化された変換係数を逆量子化するために、ビットごとの左シフト演算を実行してもよい。それによって、逆量子化ユニット３０６は、変換係数を含む変換係数ブロックを形成し得る。
【0120】
逆量子化ユニット３０６が変換係数ブロックを形成した後、逆変換処理ユニット３０８は、現在ブロックに関連付けられた残差ブロックを生成するために、変換係数ブロックに１つ又は複数の逆変換を適用し得る。例えば、逆変換処理ユニット３０８は、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向変換、又は別の逆変換を変換係数ブロックに適用し得る。
【0121】
更に、予測処理ユニット３０４は、エントロピー復号ユニット３０２によってエントロピー復号された予測情報シンタックス要素に従って予測ブロックを生成する。例えば、現在ブロックがインター予測されることを予測情報シンタックス要素が示す場合、動き補償ユニット３１６は、予測ブロックを生成し得る。この場合、予測情報シンタックス要素は、参照ブロックをそこから取り出すべきＤＰＢ３１４内の参照ピクチャ、並びに、現在ピクチャの中の現在ブロックの位置に対する参照ピクチャの中の参照ブロックの位置を識別する動きベクトルを示し得る。動き補償ユニット３１６は、一般に、動き補償ユニット２２４（図４）に関して説明した方式と実質的に類似の方式で、インター予測プロセスを実行することができる。
【0122】
別の例として、現在ブロックがイントラ予測されることを予測情報シンタックス要素が示す場合、イントラ予測ユニット３１８は、予測情報シンタックス要素によって示されるイントラ予測モードに従って、予測ブロックを生成し得る。この場合も、イントラ予測ユニット３１８は、一般に、イントラ予測ユニット２２６（図４）に関して説明した方式と実質的に類似の方式で、イントラ予測プロセスを実行することができる。イントラ予測ユニット３１８は、現在ブロックに対する隣接サンプルのデータをＤＰＢ３１４から取り出し得る。
【0123】
再構成ユニット３１０は、予測ブロック及び残差ブロックを使用して現在ブロックを再構成し得る。例えば、再構成ユニット３１０は、現在ブロックを再構成するために、予測ブロックの対応するサンプルに残差ブロックのサンプルを加算し得る。
【0124】
フィルタユニット３１２は、再構成されたブロックに対して１つ又は複数のフィルタ動作を実行し得る。例えば、フィルタユニット３１２は、再構成されたブロックのエッジに沿ったブロッキネスアーチファクトを低減するために、デブロッキング動作を実行してもよい。フィルタユニット３１２の動作は必ずしも全ての例において実行される必要はない。
【0125】
ビデオデコーダ３００は、再構成されたブロックをＤＰＢ３１４に記憶してもよい。例えば、フィルタユニット３１２の動作が実行されない例では、再構成ユニット３１０が、再構成されたブロックをＤＰＢ３１４に記憶し得る。フィルタユニット３１２の動作が実行される例では、フィルタユニット３１２が、フィルタ処理された再構成されたブロックをＤＰＢ３１４に記憶し得る。上記で説明されたように、ＤＰＢ３１４は、イントラ予測のための現在ピクチャ及び後続の動き補償のための以前に復号されたピクチャのサンプルなどの参照情報を、予測処理ユニット３０４に提供してもよい。更に、ビデオデコーダ３００は、図１の表示デバイス１１８などの表示デバイス上に後で表示するための復号されたピクチャ（例えば、復号されたビデオ）を、ＤＰＢ３１４から出力し得る。
【0126】
このようにして、ビデオデコーダ３００は、ビデオデータを記憶するように構成されたメモリと、回路に実装され、本開示で説明される任意の技法に従ってシンボルが特定の値を有する確率を計算し、シンボルが特定の値を有する確率に従ってシンボルをバイナリ算術コーディングするように構成された１つ又は複数の処理ユニットとを含む、ビデオ復号デバイスの一例を表す。
【0127】
図６は、本開示の技法による、現在ブロックを符号化する例示的なプロセスを示すフローチャートである。現在ブロックは、現在のＣＵを含み得る。ビデオエンコーダ２００（図１及び図４）に関して説明されるが、他のデバイスが図６のプロセスと類似のプロセスを実行するように構成され得ることを理解されたい。
【0128】
この例では、ビデオエンコーダ２００は最初に、現在ブロックを予測する（３５０）。例えば、ビデオエンコーダ２００は、現在ブロックに対する予測ブロックを形成することができる。ビデオエンコーダ２００は、次いで、現在ブロックに対する残差ブロックを計算することができる（３５２）。残差ブロックを計算するために、ビデオエンコーダ２００は、元の符号化されていないブロックと現在ブロックに対する予測ブロックとの間の差分を計算することができる。ビデオエンコーダ２００は、次いで、残差ブロックを変換し、残差ブロックの変換係数を量子化することができる（３５４）。次に、ビデオエンコーダ２００は、残差ブロックの量子化された変換係数を走査することができる（３５６）。走査の間に又は走査に続いて、ビデオエンコーダ２００は、変換係数をエントロピー符号化することができる（３５８）。例えば、ビデオエンコーダ２００は、ＣＡＶＬＣ又はＣＡＢＡＣを使用して変換係数を符号化することができる。ビデオエンコーダ２００は、次いで、ブロックのエントロピー符号化されたデータを出力することができる（３６０）。
【0129】
図７は、本開示の技法による、ビデオデータの現在ブロックを復号する例示的なプロセスを示すフローチャートである。現在ブロックは、現在のＣＵを含み得る。ビデオデコーダ３００（図１及び図５）に関して説明されるが、他のデバイスが図７のプロセスと類似のプロセスを実行するように構成され得ることを理解されたい。
【0130】
ビデオデコーダ３００は、エントロピー符号化された予測情報及び現在ブロックに対応する残差ブロックの変換係数のエントロピー符号化されたデータなどの、現在ブロックに対するエントロピー符号化されたデータを受信することができる（３７０）。ビデオデコーダ３００は、現在ブロックに対する予測情報を決定し、残差ブロックの変換係数を再生するために、エントロピー符号化されたデータをエントロピー復号することができる（３７２）。ビデオデコーダ３００は、現在ブロックに対する予測ブロックを計算するために、例えば、現在ブロックに対する予測情報によって示されるイントラ予測モード又はインター予測モードを使用して、現在ブロックを予測することができる（３７４）。ビデオデコーダ３００は、次いで、量子化された変換係数のブロックを作成するために、再生された変換係数を逆走査することができる（３７６）。ビデオデコーダ３００は、次いで、残差ブロックを生成するために、変換係数を逆量子化し、変換係数に逆変換を適用することができる（３７８）。ビデオデコーダ３００は、予測ブロックと残差ブロックとを組み合わせることによって、現在ブロックを最終的に復号することができる（３８０）。
【0131】
図８Ａ及び図８Ｂは、ビンｎにおけるＣＡＢＡＣプロセスの例を示す。図８Ａの例４００では、ビンｎにおいて、ビン２における範囲は、あるコンテキスト状態（σ）が与えられると、最低確率シンボル（ＬＰＳ）（ｐσ）の確率によって与えられるＲａｎｇｅＭＰＳ及びＲａｎｇｅＬＰＳを含む。例４００は、ビンｎの値が最高確率シンボル（ＭＰＳ）に等しいときの、ビンｎ＋１における範囲の更新を示す。この例では、低は同じままあるが、ビンｎ＋１における範囲の値は、ビンｎにおいてＲａｎｇｅＭＰＳの値まで下げられる。図８Ｂの例４０２は、ビンｎの値がＭＰＳに等しくない（すなわち、ＬＰＳに等しい）とき、ビンｎ＋１における範囲の更新を示す。この例では、低は、ビンｎにおいてＲａｎｇｅＬＰＳのより低い範囲値に移される。加えて、ビンｎ＋１における範囲の値は、ビンｎにおけるＲａｎｇｅＬＰＳの値まで下げられる。
【0132】
ＨＥＶＣビデオコーディングプロセスの一例では、範囲は９ビットで表され、低は１０ビットで表される。範囲及び低の値を十分な精度で維持するための再正規化プロセスがある。再正規化は、範囲が２５６未満であるときはいつでも起こる。したがって、範囲は、再正規化の後は常に２５６以上である。範囲及び低の値に応じて、バイナリ算術コーダ（binary arithmetic coder、ＢＡＣ）は、ビットストリームに、「０」、若しくは「１」を出力し、又は今後の出力に備えるために、内部変数（ＢＯ：未解決ビットと呼ばれる）を更新する。図９は、範囲に応じたＢＡＣ出力の例を示す。例えば、範囲及び低がある閾値（例えば、５１２）を上回るとき、「１」がビットストリームに出力される。範囲及び低がある閾値（例えば、５１２）を下回るとき、「０」がビットストリームに出力される。範囲及びより低がある閾値とある閾値との間にあるとき、ビットストリームには何も出力されない。そうではなく、ＢＯ値がインクリメントされ、次のビンが符号化される。
【0133】
Ｈ．２６４／ＡＶＣのＣＡＢＡＣコンテキストモデルでは、及びＨＥＶＣのいくつかの例では、１２８個の状態がある。０～６３であり得る６４個の可能なＬＰＳ確率（状態σによって表記される）がある。各ＭＰＳは、０又は１であり得る。したがって、１２８個の状態は、６４個の状態確率×ＭＰＳの２つの可能な値（０又は１）である。したがって、状態は、７ビットでインデックス付けされ得る。
【0134】
ＬＰＳ範囲（ｒａｎｇｅＬＰＳσ）を導出する計算を減らすために、全ての事例についての結果が、近似としてあらかじめ計算され、ルックアップテーブルに記憶されてもよい。したがって、ＬＰＳ範囲は、単純なテーブルルックアップを使用することによって、いかなる乗算も用いずに取得され得る。乗算を避けることは、いくつかのデバイス又はアプリケーションにとって重要であることがあり、それは、この演算が、多くのハードウェアアーキテクチャにおいて多大な待ち時間を引き起こし得るからである。
【0135】
４列のあらかじめ計算されたＬＰＳ範囲テーブルが、乗算の代わりに使用され得る。範囲は、４つのセグメントに分割される。セグメントインデックスが、質問（範囲＞＞６）＆３によって導出され得る。実際には、セグメントインデックスは、ビットをシフトし、実際の範囲から除去することによって導出される。以下の表１は、可能な範囲と、それらの対応するインデックスとを示す。
【0136】
【表1】
【0137】
そして、ＬＰＳ範囲テーブルは、６４個のエントリ（各確率状態に対して１つ）×４（各範囲インデックスに対して１つ）を有する。各エントリは、ＲａｎｇｅＬＰＳ、すなわち、範囲とＬＰＳ確率を乗算した値である。このテーブルの一部の一例が、以下の表２に示される。表２は、確率状態９～１２を示す。ＨＥＶＣに対する１つの提案では、確率状態は０～６３にわたり得る。
【0138】
【表2】
【0139】
各セグメント（すなわち、範囲値）の中で、各確率状態σのＬＰＳ範囲があらかじめ定義される。言い換えると、確率状態σのＬＰＳ範囲は、４つの値（すなわち、各範囲インデックスに対して１つの値）へと量子化される。所与の点において使用される具体的なＬＰＳ範囲は、どのセグメントに範囲が属すかに依存する。テーブルにおいて使用される可能なＬＰＳ範囲の数は、テーブル列の数（すなわち、可能なＬＰＳ範囲値の数）とＬＰＳ範囲精度との間のトレードオフである。一般に、列が多いほど、ＬＰＳ範囲値の量子化誤差は小さくなるが、テーブルを記憶するための、より多くのメモリの必要性も増す。列が少ないと量子化誤差が増大するが、テーブルを記憶するのに必要とされるメモリも減る。
【0140】
上記で説明されたように、各ＬＰＳ確率状態は、対応する確率を有する。各状態の確率ｐは、次のように導出される。
Ｐσ＝αｐσ－１
ここで、状態σは０～６３である。定数αは、各コンテキスト状態間の確率変化の量を表す。一例では、α＝０．９４９３であり、又は、より厳密には、α＝（０．０１８７５／０．５）１／６３である。状態σ＝０における確率は、０．５（すなわち、ｐ０＝１／２）に等しい。すなわち、コンテキスト状態０において、ＬＰＳ及びＭＰＳは等しく起こり得る。各々の連続する状態における確率は、前の状態をαと乗算することによって導出される。したがって、ＬＰＳがコンテキスト状態α＝１において起こる確率は、ｐ０ ＊０．９４９３（０．５＊０．９４９３＝０．４７４６５）である。したがって、状態αのインデックスが増大すると、ＬＰＳが起こる確率が下がる。
Ｐσ＝αｐσ－１
ここで、状態σは０～６３である。定数αは、各コンテキスト状態間の確率変化の量を表す。一例では、α＝０．９４９３であり、又は、より厳密には、α＝（０．０１８７５／０．５）１／６３である。状態σ＝０における確率は、０．５（すなわち、ｐ０＝１／２）に等しい。すなわち、コンテキスト状態０において、ＬＰＳ及びＭＰＳは等しく起こり得る。各々の連続する状態における確率は、前の状態をαと乗算することによって導出される。したがって、ＬＰＳがコンテキスト状態α＝１において起こる確率は、ｐ０ ＊０．９４９３（０．５＊０．９４９３＝０．４７４６５）である。したがって、状態αのインデックスが増大すると、ＬＰＳが起こる確率が下がる。
【0141】
ＣＡＢＡＣは、確率状態が信号統計（すなわち、前にコーディングされたビンの値）に従うために更新されるので、適応的である。更新プロセスは次の通りである。所与の確率状態について、更新は、状態インデックスと、ＬＰＳ又はＭＰＳのいずれかとして識別された符号化されたシンボルの値とに依存する。更新プロセスの結果として、新しい確率状態が導出され、これは、修正された可能性のあるＬＰＳ確率推定値と、必要であれば、修正されたＭＰＳ値とからなる。
【0142】
ビン値がＭＰＳに等しい場合、所与の状態インデックスが１だけインクリメントされ得る。これは、ＭＰＳが、ＬＰＳ確率がすでにその最低値である（又は等価的に、最高のＭＰＳ確率に達している）、状態インデックス６２において起こるときを除いて、全ての状態に当てはまる。この場合、状態インデックス６２は、ＬＰＳが見つかるか、又は最後のビン値が符号化される（最後のビン値の特殊な場合に対しては、状態６３が使用される）まで、固定されたままである。ＬＰＳが起こると、状態インデックスは、以下の式に示されるように、状態インデックスをある量だけデクリメントすることによって変更される。この規則は全般に、以下を例外として、ＬＰＳの各発生に対して適用される。確率が等しい事例に対応するインデックスσ＝０の状態において、ＬＰＳが符号化されていると仮定すると、状態インデックスは固定されたままであるが、ＭＰＳ値は、ＬＰＳ及びＭＰＳの値が交換されるように切り替えられる。全ての他の事例では、どのシンボルが符号化されていても、ＭＰＳ値は変えられない。ＬＰＳ確率に対する遷移規則の導出は、所与のＬＰＳ確率ｐｏｌｄと、その更新された確率ｐｎｅｗとの間の以下の関係に基づく。
ＭＰＳが起こる場合、Ｐｎｅｗ＝ｍａｘ（αｐｏｌｄ，ｐ６２）
ＬＰＳが起こる場合、Ｐｎｅｗ＝（１－α）＋αｐｏｌｄ
ＭＰＳが起こる場合、Ｐｎｅｗ＝ｍａｘ（αｐｏｌｄ，ｐ６２）
ＬＰＳが起こる場合、Ｐｎｅｗ＝（１－α）＋αｐｏｌｄ
【0143】
ＣＡＢＡＣにおける確率推定プロセスの現実的な実装形態に関して、全ての遷移規則が、６ビットの符号なし整数値の６３個のエントリを各々有する、最大で２つのテーブルによって実現され得ることに留意することが重要である。いくつかの例では、単一のテーブルＴｒａｎｓＩｄｘＬＰＳを用いて状態遷移が決定されてもよく、このテーブルは、所与の状態インデックスσに対して、ＬＰＳが観察されている事例における新しい更新された状態インデックスＴｒａｎｓＩｄｘＬＰＳ［σ］を決定する。１という固定値による、状態インデックスの単純な（飽和した）インクリメントによって、ＭＰＳにより引き起こされる遷移を得ることができ、更新された状態インデックスｍｉｎ（σ＋１，６２）をもたらす。以下の表３は、部分的ＴｒａｎｓＩｄｘＬＰＳテーブルの一例である。
【0144】
【表3】
【0145】
前のＢＡＣ手法（例えば、Ｈ．２６４／ＡＶＣにおいて使われるＢＡＣ手法）に伴う１つの問題は、テーブルＲａｎｇｅＬＰＳ及びＴｒａｎｓＩｄｘＬＰＳが、低解像度ビデオ（すなわち、共通中間フォーマット（ＣＩＦ）及びクオーターＣＩＦ（ＱＣＩＦ）ビデオ）用に調整されることである。現在では、大量のビデオコンテンツが高精細（ＨＤ）であり、場合によっては、ＨＤより大きい。ＨＤであるか、又はＨＤ解像度より大きいビデオコンテンツは、Ｈ．２６４／ＡＶＣを開発するために使われた、１０年昔のＱＣＩＦシーケンスとは異なる統計値を有する。
【0146】
したがって、Ｈ．２６４／ＡＶＣからのテーブルＲａｎｇｅＬＰＳ及びＴｒａｎｓＩｄｘＬＰＳは、状態の間で、速すぎるような適応を引き起こす場合がある。すなわち、特にＬＰＳが起こるときの、確率状態の間の遷移は、ＨＤビデオのより滑らかな、より高解像度のコンテンツにとっては大きすぎることがある。したがって、従来技法に従って使われる確率モデルは、ＨＤ及びエクストラＨＤコンテンツにとって正確でない。加えて、ＨＤビデオコンテンツは、より大きい範囲のピクセル値を含むので、Ｈ．２６４／ＡＶＣテーブルは、ＨＤコンテンツに存在し得るより極端な値を考慮するための十分なエントリを含まない。
【0147】
したがって、ＲａｎｇｅＬＰＳ及びＴｒａｎｓＩｄｘＬＰＳテーブルは、この新しいコンテンツの特性を考慮するように修正される必要がある。これはまた、ＢＡＣが少なくとも２つの側面において異なるべきであることを含意する。１つの違いは、ＢＡＣプロセスが、より遅い適応プロセスを可能にするテーブルを使うべきであることである。別の違いは、ＢＡＣプロセスが、より極端な事例（すなわち、傾斜した確率）を考慮すべきであることである。
【0148】
現在のＲａｎｇｅＬＰＳ及びＴｒａｎｓＩｄｘＬＰＳテーブルは、単により多くの確率状態及び範囲を含めることによって、これらの目標を達成するように修正され得る。ただし、この解決策は、テーブルのサイズのかなりの増大を招く。より遅い適応は、現在使われているパラメータα（例えば、α＝０．９４９３）より１に近いパラメータαを使うことによって達成され得る。ただし、より大きい値のαを使うと、確率は、よりゆっくりと０に向かい、したがって、より多くの状態が必要とされる。加えて、より遅い適応を達成するために、最も低い可能な確率が、現在使われている最も低い確率よりはるかに低ければ有益であり得る。したがって、その非常に低い確率値に達するために、一層より多くの状態が必要とされ得る。
【0149】
上記の問題に鑑みて、本開示は、テーブルサイズ（例えば、ＲａｎｇｅＬＰＳ及びＴｒａｎｓＩｄｘＬＰＳテーブル）を現実的なレベルに保ったまま、より遅い適応及びより傾斜した確率を遂げるように、ＢＡＣを修正する技法を提案する。言い換えると、本開示は、比較的小さいサイズのテーブルを使いながら、より遅い適応及びより極端な確率（すなわち、０及び１により近い確率）を達成する技法を記載する。
【0150】
本開示に記載される技法は、より多くの確率状態、例えば、Ｈ．２６４／ＡＶＣ又はＨＥＶＣとともにＢＡＣにおいて使われるより多くの確率状態を使うことができる。この場合、ＴｒａｎｓＩｄｘＬＰＳテーブルは、より遅い適応及びより低い確率を取得し得る。一例では、本開示に記載される技法は、６４個ではなく、１２８個の確率状態を使うことができる。こうすることにより、テーブルＴｒａｎｓＩｄｘＬＰＳは、６４個のエントリだけ増大する（すなわち、６４個ではなく、１２８個のエントリ）。この増大は、より遅い適応及びより低い極小確率を可能にする。一例として、パラメータα＝０．９６８９を設定することによって、連続的確率の間の差がより小さくなる。更に、最も低い最小確率は０．００９まで下がり、これは、Ｈ．２６４／ＡＶＣ事例の約２分の１（すなわち、０．０１８７５）である。他の数の状態及びα値も可能であるが、概して、状態の数は増大されてもよく、αの値は、α＝０．９４９３のＨ．２６４／ＡＶＣ事例より１に近くなり得る。
【0151】
ＨＤ又はエクストラＨＤコーディングを改善するために修正されてもよい別のパラメータは、パラメータｐ０である。ｐ０の値は概して、ＬＰＳについての最大確率を示す。この可能性を検討する理由は、より低いｐ０を有することは、極小確率も低下することを意味するからである。ｐ０の値は、従来のＢＡＣプロセスでは０．５に設定される。本開示は、ｐ０について他の値を可能にすることを提案する。０．５より低い他の値のｐ０を有することにより、ＭＰＳ／ＬＰＳスワップが起きたとき、状態０におけるより滑らかな遷移が可能になる。一例では、ｐ０は０．４９３に等しくてもよいが、多くの他の例が使われ得る。
【0152】
通常、各確率状態は、それ自体のエントリをＲａｎｇｅＬＰＳテーブル中に有する。テーブルサイズは、
＃確率状態×＃量子化された範囲インデックス
として表すことができ、これは、ＨＥＶＣ向けのいくつかの提案では６４×４＝２５６バイトである。状態の数は、本開示の例では増大する（上の例では２倍になる）ので、ＲａｎｇｅＬＰＳテーブルサイズは１２８×４＝５１２バイトであり得る。ただし、ＲａｎｇｅＬＰＳテーブルサイズのこの増大を避けるために、本開示は、ＲａｎｇｅＬＰＳサイズをインデックス付けするために、確率状態インデックスを、より低いサイズ（すなわち、少数のインデックス）にマッピングすることを更に提案する。言い換えると、本開示は、範囲計算プロセスから状態遷移プロセスを切り離すことを提案する。これは、本例では、状態から範囲への計算のためのマップがあることを意味する。ビデオエンコーダ２００及び／又はビデオデコーダ３００は、決定された確率状態を示すインデックスを、複数のグループ化インデックスのうちの１つ（例えば、ＲａｎｇｅＬＰＳテーブル用のグループ化インデックス）にマッピングするように構成されてもよく、グループ化インデックスのうちの少なくとも１つは、複数の確率状態のうちの少なくとも２つを表す。したがって、ＲａｎｇｅＬＰＳテーブル（又は他のＢＡＣテーブル）は、確率状態が存在するより少数のインデックスを使い得る。
＃確率状態×＃量子化された範囲インデックス
として表すことができ、これは、ＨＥＶＣ向けのいくつかの提案では６４×４＝２５６バイトである。状態の数は、本開示の例では増大する（上の例では２倍になる）ので、ＲａｎｇｅＬＰＳテーブルサイズは１２８×４＝５１２バイトであり得る。ただし、ＲａｎｇｅＬＰＳテーブルサイズのこの増大を避けるために、本開示は、ＲａｎｇｅＬＰＳサイズをインデックス付けするために、確率状態インデックスを、より低いサイズ（すなわち、少数のインデックス）にマッピングすることを更に提案する。言い換えると、本開示は、範囲計算プロセスから状態遷移プロセスを切り離すことを提案する。これは、本例では、状態から範囲への計算のためのマップがあることを意味する。ビデオエンコーダ２００及び／又はビデオデコーダ３００は、決定された確率状態を示すインデックスを、複数のグループ化インデックスのうちの１つ（例えば、ＲａｎｇｅＬＰＳテーブル用のグループ化インデックス）にマッピングするように構成されてもよく、グループ化インデックスのうちの少なくとも１つは、複数の確率状態のうちの少なくとも２つを表す。したがって、ＲａｎｇｅＬＰＳテーブル（又は他のＢＡＣテーブル）は、確率状態が存在するより少数のインデックスを使い得る。
【0153】
本開示の一例では、ＲａｎｇｅＬＰＳテーブル用のエントリとして使うための新規インデックスを生成するように、確率状態数が２で除算されてもよい。この場合、１２８個の確率状態は、６４個のエントリまで低減される。したがって、ＲａｎｇｅＬＰＳテーブルは、Ｈ．２６４／ＡＶＣにおいて使われる現在のサイズを保ち得る。したがって、範囲ＬＰＳテーブル中のエントリをインデックス付けするのに確率状態σを使うのではなく、本開示に記載される技法は（σ＞＞１）を利用し、すなわち、状態σは、２で除算され、ＲａｎｇｅＬＰＳテーブル中へのグループ化インデックスとしての使用のために、より低い整数に丸められる。除算は、ＲａｎｇｅＬＰＳテーブルが所与の実装のためにより小さいことが望まれる場合、又は状態の数がより大きい（例えば、２５６個の確率状態の）場合、より大きい数によるものであってもよい。このコンテキストでは、各グループ化インデックスは２つの確率状態を表す。本開示の他の例では、グループ化インデックスは、２つ以上の確率状態を表し得る。
【0154】
最適エントロピーの観点から、除算又は右ビットシフト演算を使うことによる、ＲａｎｇｅＬＰＳテーブルのための状態のグループ化は、有益であり得るが、常に最適な技法であるとは限らない場合がある。最適なグループ化は、特に、状態の数及びパラメータαを含む、いくつかの要因に依存し得る。最も望ましい（及び、おそらく最適な）グループ化は、ビットシフト演算のような簡単な演算ではない可能性がある。概して、グループ化は、確率状態の総数から始まって、低減された数の確率状態（すなわち、グループ化状態）までのテーブルを用いて記述され得る。別の例では、本開示は、この種類のテーブルを使うことを提案する。この手法は、追加のメモリという犠牲を払って、（除算又は右シフトと比較して）性能を高めることになる。したがって、この例は、メモリと性能との間のトレードオフであり、線形マッピング例（すなわち、除算又は右シフト）よりも、より優れた性能を優先する。
【0155】
したがって、ＲａｎｇｅＬＰＳテーブル中のエントリへの、確率状態の線形マッピングが使われ得るが、非線形マッピングを提供することが望ましい場合がある。例えば、確率状態は、対数マッピングに従ってマッピングされてもよい。対数マッピングは、いくつかの例では、区分的線形マッピング技法を使用して達成され得る。概して、そのようなマッピングは、あらかじめ計算されたマッピングテーブルなどのテーブルを使用して定義され得る。
【0156】
概して、本開示に記載される技法は、いくつかの例では、ビデオデータをエントロピーコーディングするプロセス又はデバイスによって実行され得る。本プロセスは、バイナリ算術コーディングプロセスにおいて、シンボルの確率状態であって、確率状態は、複数の確率状態のうちの１つであり得る、シンボルの確率状態を決定することと、決定された確率状態を示すインデックスを、複数のグループ化インデックスのうちの１つにマッピングすることであって、グループ化インデックスのうちの少なくとも１つは、複数の確率状態のうちの少なくとも２つを表し、グループ化インデックスの各々は、テーブル中の最も低い確率シンボルの範囲をポイントする、マッピングすることとを含み得る。
【0157】
いくつかの例では、確率状態の数は６４より大きくてもよい。例えば、確率状態の数は１２８であってもよい。いくつかの例では、ＲａｎｇｅＬＰＳテーブルへの入力として使われるグループ化インデックスの数は６４である。具体的には、確率状態の数は１２８であってもよく、ＲａｎｇｅＬＰＳテーブルへの入力として使われるグループ化インデックスの数は６４であってもよい。シンボルは、グループ化インデックスに基づいて、例えば、確率状態インデックスに基づくテーブルに従って、又はインデックスに基づく数学的演算に従ってコーディングされ得る。決定された確率状態は、テーブルに従って、又は数学的演算に従って、複数のインデックスのうちの１つにマッピングする。マッピングは、線形又は非線形であってもよい。例えば、マッピングは、２で除算する演算に従って実行され得る。いくつかの例では、マッピングは対数マッピングであってもよい。いくつかの例では、区分的線形マッピングが、対数マッピングを定義するために使用されてもよい。いくつかの例では、ＬＰＳについての最大確率の値ｐ０は０．５未満であってもよい。
【0158】
本開示に記載される技法は、例えば、ビデオエンコーダ、ビデオデコーダ、又は複合ビデオエンコーダデコーダ（コーデック）内で実行され得る。具体的には、そのような技法は、ビデオエンコーダのエントロピー符号化ユニット及び／又はビデオデコーダのエントロピー復号ユニットにおいて実行され得る。本技法は、例えば、ＨＥＶＣ規格の態様によるビデオコーディングなどのビデオコーディングをサポートするように構成され得るＣＡＢＡＣプロセス内で実行され得る。エントロピー符号化及び復号ユニットは、例えば、残差ビデオデータに関連付けられた量子化された変換係数、動きベクトル情報、シンタックス要素、並びにビデオ符号化及び／又はビデオ復号プロセスにおいて有用であり得る他のタイプの情報など、様々なビデオデータのいずれかを符号化又は復号するために、相反する又は逆の様式でコーディングプロセスを適用し得る。
【0159】
図１０は、図４のエントロピー符号化ユニット２２０の例示的な実装形態のブロック図である。エントロピー符号化ユニット２２０は、本開示の技法に従ってＣＡＢＡＣを実行するように構成され得る。シンタックス要素４１８が、エントロピー符号化ユニット２２０へと入力される。シンタックス要素が、すでにバイナリ値のシンタックス要素（すなわち、０及び１の値のみを有するシンタックス要素）である場合、バイナリ化のステップはスキップされてもよい。シンタックス要素が非バイナリ値のシンタックス要素（例えば、変換係数レベルなどの、複数のビットによって表されるシンタックス要素）である場合、非バイナリ値のシンタックス要素はバイナライザ４２０によってバイナリ化される。バイナライザ４２０は、非バイナリ値のシンタックス要素の、バイナリ決定のシーケンスへのマッピングを実行する。これらのバイナリ決定はしばしば、「ビン」と呼ばれる。例えば、変換係数レベルに対して、レベルの値を連続するビンに分解することができ、各ビンは、係数レベルの絶対値が何らかの値より大きいか否かを示す。例えば、ビン０（有意性フラグと呼ばれることがある）は、変換係数レベルの絶対値が０より大きいか否かを示す。ビン１は、変換係数レベルの絶対値が１より大きいか否かを示し、以下同様である。各非バイナリ値のシンタックス要素のために、固有のマッピングが開発されてもよい。
【0160】
バイナライザ４２０によって生成された各ビンは、エントロピー符号化ユニット５６のバイナリ算術コーディング側に供給される。すなわち、非バイナリ値のシンタックス要素の所定のセットに対して、各ビンタイプ（例えば、ビン０）は、次のビンタイプ（例えば、ビン１）の前にコーディングされる。コーディングは、普通モード又はバイパスモードのいずれかで実行され得る。バイパスモードでは、バイパスコーディングエンジン４２６は、固定確率モデルを使用して、例えば、ゴロムライスコーディング又は指数ゴロムコーディングを使用して、算術コーディングを実行する。バイパスモードは一般に、より予測可能なシンタックス要素のために使用される。
【0161】
普通モードでのコーディングは、ＣＡＢＡＣを実行することを伴う。普通モードＣＡＢＡＣは、前にコーディングされたビンの値を与えられるとビンの値の確率が予測可能である場合のビン値をコーディングするためである。ビンがＬＰＳである確率は、コンテキストモデラ４２２によって決定される。コンテキストモデラ４２２は、ビン値及びコンテキストモデル（例えば、確率状態σ）を出力する。コンテキストモデルは、一連のビンのための初期コンテキストモデルであってもよく、又は、前にコーディングされたビンのコーディングされた値に基づいて決定されてもよい。上記で説明されたように、コンテキストモデラは、前にコーディングされたビンがＭＰＳであったかＬＰＳであったかに基づいて、状態を更新することができる。
【0162】
コンテキストモデル及び確率状態σがコンテキストモデラ４２２によって決定された後、普通コーディングエンジン４２４は、ビン値に対してＢＡＣを実行する。本開示の技法によれば、普通コーディングエンジン４２４は、６４個より多い確率状態σを含むＴｒａｎｓＩｄｘＬＰＳテーブル４３０を使用してＢＡＣを実行する。一例では、確率状態の数は４２８である。ＴｒａｎｓＩｄｘＬＰＳは、前のビン（ビンｎ）がＬＰＳであるとき、どの確率状態が次のビン（ビンｎ＋１）に使用されるかを決定するために使用される。普通コーディングエンジン４２４はまた、特定の確率状態σを与えられると、ＬＰＳに対する範囲値を決定するために、ＲａｎｇｅＬＰＳテーブル４２８を使用し得る。しかしながら、本開示の技法によれば、ＴｒａｎｓＩｄｘＬＰＳテーブル４３０の全ての可能な確率状態σを使用するのではなく、確率状態インデックスσは、ＲａｎｇｅＬＰＳテーブルにおける使用のためにグループ化インデックスにマッピングされる。すなわち、ＲａｎｇｅＬＰＳテーブル４２８への各インデックスは、確率状態の総数のうちの２つ以上を表し得る。確率状態インデックスσの、グループ化インデックスへのマッピングは、線形（例えば、２で除算することによる）であってもよく、又は非線形（例えば、対数関数若しくはマッピングテーブル）であってもよい。
【0163】
本開示の他の例では、連続する確率状態の間の差は、パラメータαを、０．９４９３より大きくなるように設定することによって、より小さくすることができる。一例では、α＝０．９６８９である。本開示の別の例では、ＬＰＳが起こる最も高い確率（ｐ０）は、０．５より低くなるように設定され得る。一例では、ｐ０は０．４９３に等しくなり得る。
【0164】
本開示の１つ又は複数の技法によれば、バイナリ算術コーディングプロセスにおいて確率状態を更新するのに使用される変数（例えば、ウィンドウサイズ、スケーリング因子（α）、及び確率更新速度のうちの１つ又は複数）の同じ値を使用するのとは反対に、エントロピー符号化ユニット５６は、異なるコンテキストモデル及び／又は異なるシンタックス要素に対して、変数の異なる値を使用し得る。例えば、エントロピー符号化ユニット５６は、複数のコンテキストモデルのうちの１つのコンテキストモデルについて、バイナリ算術コーディングプロセスにおいて確率状態を更新するのに使われる変数の値を決定し、決定された値に基づいて確率状態を更新することができる。
【0165】
図１１は、本開示の技法による、ＣＡＢＡＣを実行するように構成され得る例示的なエントロピー復号ユニット３０２のブロック図である。図１１のエントロピー復号ユニット３０２は、図４で説明されたエントロピー符号化ユニット２２０の方式とは逆の方式で、ＣＡＢＡＣを実行する。ビットストリーム５１８からのコーディングされたビットが、エントロピー復号ユニット３０２へと入力される。コーディングされたビットは、コーディングされたビットが、バイパスモードを使用してエントロピーコーディングされたか、又は普通モードを使用してエントロピーコーディングされたかに基づいて、コンテキストモデラ５２０又はバイパス復号エンジン５２２のいずれかに供給される。コーディングされたビットがバイパスモードでコーディングされた場合、バイパス復号エンジン５２２は、例えば、バイナリ値のシンタックス要素又は非バイナリシンタックス要素のビンを取り出すために、ゴロムライス復号又は指数ゴロム復号を使用し得る。
【0166】
コーディングされたビットが普通モードでコーディングされた場合、コンテキストモデラ５２０は、コーディングされたビットに対する確率モデルを決定してもよく、普通復号エンジン５２４は、非バイナリ値のシンタックス要素のビン（又は、バイナリ値である場合はシンタックス要素自体）を生成するように、コーディングされたビットを復号してもよい。コンテキストモデル及び確率状態σがコンテキストモデラ５２０によって決定された後、普通復号エンジン５２４は、ビン値に対してＢＡＣを実行する。本開示の技法によれば、普通復号エンジン５２４は、６４個より多い確率状態σを含むＴｒａｎｓＩｄｘＬＰＳテーブル５２８を使用してＢＡＣを実行する。一例では、確率状態の数は１２８であるが、本開示の技法と整合する他の数の確率状態が定義されてもよい。ＴｒａｎｓＩｄｘＬＰＳテーブル５２８は、前のビン（ビンｎ）がＬＰＳであるとき、どの確率状態が次のビン（ビンｎ＋１）に使用されるかを決定するために使用される。普通復号エンジン５２４はまた、特定の確率状態σを与えられると、ＬＰＳに対する範囲値を決定するために、ＲａｎｇｅＬＰＳテーブル５２６を使用し得る。しかしながら、本開示の技法によれば、ＴｒａｎｓＩｄｘＬＰＳテーブル５２８の全ての可能な確率状態σを使用するのではなく、確率状態インデックスσは、ＲａｎｇｅＬＰＳテーブル５２６における使用のためにグループ化インデックスにマッピングされる。すなわち、ＲａｎｇｅＬＰＳテーブル５２６への各インデックスは、確率状態の総数のうちの２つ以上を表し得る。確率状態インデックスσの、グループ化インデックスへのマッピングは、線形（例えば、２で除算することによる）であってもよく、又は非線形（例えば、対数関数若しくはマッピングテーブル）であってもよい。
【0167】
本開示の他の例では、連続する確率状態の間の差は、パラメータαを、０．９４９３より大きくなるように設定することによって、より小さくすることができる。一例では、α＝０．９６８９である。本開示の別の例では、ＬＰＳが起こる最も高い確率（ｐ０）は、０．５より低くなるように設定され得る。一例では、ｐ０は０．４９３に等しくなり得る。
【0168】
ビンが普通復号エンジン５２４によって復号された後、逆バイナライザ５３０が、ビンを非バイナリ値のシンタックス要素の値へ戻すように変換するために、逆方向マッピングを実行し得る。
【0169】
図１２は、ビデオデータのビットストリームを復号する例示的なプロセスを示すフローチャートである。ビデオデコーダ３００（図１及び図５）に関して説明されるが、他のデバイスが図１２のプロセスと類似のプロセスを実行するように構成され得ることを理解されたい。
【0170】
ビデオデコーダ３００は、コンテキストモデルに従ってビン値を受信するように構成され得る（６００）。コンテキストモデルは、１つ又は複数の確率状態を含み、ビン値は、ビデオデータの１つ又は複数のシンタックス要素に対応する。
【0171】
ビデオデコーダ３００は、受信されたビン値に基づいて第１のシフト値を決定する（６０２）。ビデオデコーダ３００は、受信されたビン値に基づいて第２のシフト値を決定する（６０４）。受信されたビン値に基づいて第１のシフト値を決定するために、ビデオデコーダ３００は、コンテキストモデルの識別子及び受信された最後のＭ個のビン値に基づいてルックアップテーブル中のエントリを識別するように構成されてもよく、Ｍは、１より大きい整数値であり、ビデオデコーダ３００は、エントリに基づいて第１のシフト値を決定し得る。ビデオデコーダ３００はまた、エントリに基づいて第２のシフト値を決定し得る。エントリは、例えば、８ビット値であってもよく、８ビット値の最初の４ビットは第１のシフト値を識別し、８ビット値の最後の４ビットは第２のシフト値を識別する。第１のシフト値は、第２のシフト値より高いレートで更新され得る。すなわち、第１のシフト値は、第２のシフト値より速く更新し得る。
【0172】
ビデオデコーダ３００は、第１のシフト値に基づいて第１の状態変数を更新する（６０６）。ビデオデコーダ３００は、第２のシフト値に基づいて第２の状態変数を更新する（６０８）。第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定するために、ビデオデコーダ３００は、第１の状態変数及び第２の状態変数の加重平均に基づいて確率状態を決定するように構成され得る。ビデオデコーダ３００は、コンテキストモデルに基づいて、第１の状態変数及び第２の状態変数の加重平均を計算するための重みを決定し得る。上記で説明されたように、重みは、第１の重み及び第２の重みを含むことができ、第１の重みと第２の重みとの和は、１に等しい。ビデオデコーダ３００は、コンテキストモデルの識別子に基づいて重みの値を決定するように構成され得る。
【0173】
ビデオデコーダ３００は、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定する（６１０）。ビデオデコーダ３００は、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号する（６１２）。
【0174】
ビデオデコーダ３００は、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する（６１４）。ビデオデコーダ３００は、ビデオデータのブロックを復号するためにシンタックス要素を使用してもよく、ビデオデータのブロックは、復号ピクチャの一部として出力されてもよい。本開示の技法は、いかなる特定のタイプのシンタックス要素にも限定されないが、変換係数をコーディングするために使用されるシンタックス要素など、頻繁に発生するシンタックス要素にとって特に有益であり得る。
【0175】
以下の番号付き条項は、本開示で説明されるデバイス及び技法の１つ又は複数の態様を例示する。
【0176】
条項１Ａ：データをコーディングする方法であって、本方法は、本開示で説明される任意の技法に従ってシンボルが特定の値を有する確率を計算することと、シンボルが特定の値を有する確率に従ってシンボルをバイナリ算術コーディングすることとを含む、方法。
【0177】
条項２Ａ：コーディングすることが復号することを含む、条項１Ａの方法。
【0178】
条項３Ａ：コーディングすることが符号化することを含む、条項１Ａの方法。
【0179】
条項４Ａ：ビデオデータをコーディングするデバイスであって、デバイスが、条項１Ａ～３Ａのいずれかの方法を実行する１つ又は複数の手段を備える、デバイス。
【0180】
条項５Ａ：１つ又は複数の手段が、回路に実装された１つ又は複数のプロセッサを備える、条項４Ａのデバイス。
【0181】
条項６Ａ：ビデオデータを記憶するメモリを更に備える、条項４Ａ及び５Ａのいずれかのデバイス。
【0182】
条項７Ａ：復号されたビデオデータを表示するように構成されたディスプレイを更に備える、条項４Ａ～６Ａのいずれかのデバイス。
【0183】
条項８Ａ：デバイスが、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、又はセットトップボックスのうちの１つ又は複数を備える、条項４Ａ～７Ａのいずれかのデバイス。
【0184】
条項９Ａ：デバイスがビデオデコーダを備える、条項４Ａ～８Ａのいずれかのデバイス。
【0185】
条項１０Ａ：デバイスがビデオエンコーダを備える、条項４Ａ～９Ａのいずれかのデバイス。
【0186】
条項１１Ａ：実行されたとき、条項１Ａ～３Ａのいずれかの方法を１つ又は複数のプロセッサに実行させる命令をその上に記憶した、コンピュータ可読記憶媒体。
【0187】
条項１２Ａ：ビデオデータを符号化するデバイスであって、デバイスは、本開示で説明される任意の技法に従ってシンボルが特定の値を有する確率を計算する手段と、シンボルが特定の値を有する確率に従ってシンボルをバイナリ算術コーディングする手段とを備える、デバイス。
【0188】
条項１Ｂ：ビデオデータを復号する方法であって、本方法は、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信することと、受信されたビン値に基づいて第１のシフト値を決定することと、受信されたビン値に基づいて第２のシフト値を決定することと、第１のシフト値に基づいて第１の状態変数を更新することと、第２のシフト値に基づいて第２の状態変数を更新することと、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定することと、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号することと、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定することと、を含む、方法。
【0189】
条項２Ｂ：第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定することが、第１の状態変数及び第２の状態変数の加重平均に基づいて確率状態を決定することを含む、条項１Ｂの方法。
【0190】
条項３Ｂ：コンテキストモデルに基づいて、第１の状態変数及び第２の状態変数の加重平均を計算するための重みを決定すること、を更に含む、条項２Ｂの方法。
【0191】
条項４Ｂ：重みが、第１の重み及び第２の重みを含み、第１の重みと第２の重みとの和が、１に等しい、条項３Ｂの方法。
【0192】
条項５Ｂ：コンテキストモデルの識別子に基づいて重みの値を決定すること、を更に含む、条項３Ｂ又は４Ｂの方法。
【0193】
条項６Ｂ：受信されたビン値に基づいて第１のシフト値を決定することは、コンテキストモデルの識別子及び受信された最後のＭ個のビン値に基づいてルックアップテーブル中のエントリを識別することであって、Ｍが、１より大きい整数値である、識別することと、エントリに基づいて第１のシフト値を決定することと、を含む、条項１Ｂ～５Ｂのいずれかの方法。
【0194】
条項７Ｂ：エントリに基づいて第２のシフト値を決定すること、を更に含む、条項６Ｂの方法。
【0195】
条項８Ｂ：エントリが８Ｂビット値を含み、８Ｂビット値の最初の４ビットが第１のシフト値を識別し、８Ｂビット値の最後の４ビットが第２のシフト値を識別する、条項７Ｂの方法。
【0196】
条項９Ｂ：第１のシフト値が、第２のシフト値より高いレートで更新される、条項１Ｂ～８Ｂのいずれかの方法。
【0197】
条項１０Ｂ：受信されたビン値が、コンテキストモデルによって復号された最後のＭ個のビンに対応し、Ｍが、０より大きい整数値である、条項１Ｂ～９Ｂのいずれかの方法。
【0198】
条項１１Ｂ：Ｍが１に等しい、条項１０Ｂの方法。
【0199】
条項１２Ｂ：ビデオデータを復号するデバイスであって、デバイスが、ビデオデータを記憶するように構成されたメモリと、回路に実装された１つ又は複数のプロセッサと、を備え、１つ又は複数のプロセッサは、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信し、受信されたビン値に基づいて第１のシフト値を決定し、受信されたビン値に基づいて第２のシフト値を決定し、第１のシフト値に基づいて第１の状態変数を更新し、第２のシフト値に基づいて第２の状態変数を更新し、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定し、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号し、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する、ように構成されている、デバイス。
【0200】
条項１３Ｂ：第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定するために、１つ又は複数のプロセッサが、第１の状態変数及び第２の状態変数の加重平均に基づいて確率状態を決定するように更に構成されている、条項１２Ｂのデバイス。
【0201】
条項１４Ｂ：１つ又は複数のプロセッサが、コンテキストモデルに基づいて、第１の状態変数及び第２の状態変数の加重平均を計算するための重みを決定するように更に構成されている、条項１３Ｂのデバイス。
【0202】
条項１５Ｂ：重みが、第１の重み及び第２の重みを含み、第１の重みと第２の重みとの和が、１に等しい、条項１４Ｂのデバイス。
【0203】
条項１６Ｂ：１つ又は複数のプロセッサが、コンテキストモデルの識別子に基づいて重みの値を決定するように更に構成されている、条項１４Ｂ又は１５Ｂのデバイス。
【0204】
条項１７Ｂ：受信されたビン値に基づいて第１のシフト値を決定するために、１つ又は複数のプロセッサは、コンテキストモデルの識別子及び受信された最後のＭ個のビン値に基づいてルックアップテーブル中のエントリを識別し、Ｍが、１より大きい整数値であり、エントリに基づいて第１のシフト値を決定する、ように更に構成されている、条項１２Ｂ～１６Ｂのいずれかのデバイス。
【0205】
条項１８Ｂ：１つ又は複数のプロセッサが、エントリに基づいて第２のシフト値を決定するように更に構成されている、条項１７Ｂのデバイス。
【0206】
条項１９Ｂ：エントリが８Ｂビット値を含み、８Ｂビット値の最初の４ビットが第１のシフト値を識別し、８Ｂビット値の最後の４ビットが第２のシフト値を識別する、条項１８Ｂのデバイス。
【0207】
条項２０Ｂ：第１のシフト値が、第２のシフト値より高いレートで更新される、条項１２Ｂ～１９Ｂのいずれかのデバイス。
【0208】
条項２１Ｂ：受信されたビン値が、コンテキストモデルによって復号された最後のＭ個のビンに対応し、Ｍが、０より大きい整数値である、条項１２Ｂ～２０Ｂのいずれかのデバイス。
【0209】
条項２２Ｂ：Ｍが１に等しい、条項２１Ｂのデバイス。
【0210】
条項２３Ｂ：デバイスは符号化ビデオデータを受信するように構成された受信機を更に備えるワイヤレス通信デバイスを備える、条項１２Ｂ～２２Ｂのいずれかのデバイス。
【0211】
条項２４Ｂ：ワイヤレス通信デバイスが電話ハンドセットを備え、受信機が、ワイヤレス通信規格に従って、符号化ビデオデータを含む信号を復調するように構成されている、条項２３Ｂのデバイス。
【0212】
条項２５Ｂ：復号されたビデオデータを表示するように構成されたディスプレイ、を更に備える、条項１２Ｂ～２４Ｂのいずれかのデバイス。
【0213】
条項２６Ｂ：デバイスが、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、又はセットトップボックスのうちの１つ又は複数を備える、条項１２Ｂ～２５Ｂのいずれかのデバイス。
【0214】
条項２７Ｂ：ビデオデータを復号する装置であって、装置は、コンテキストモデルであって、コンテキストモデルが、１つ又は複数の確率状態を含み、ビン値が、ビデオデータの１つ又は複数のシンタックス要素に対応する、コンテキストモデルに従ってビン値を受信する手段と、受信されたビン値に基づいて第１のシフト値を決定する手段と、受信されたビン値に基づいて第２のシフト値を決定する手段と、第１のシフト値に基づいて第１の状態変数を更新する手段と、第２のシフト値に基づいて第２の状態変数を更新する手段と、復号されるべき次のビンについて、第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定する手段と、確率状態に基づいて、復号されるべき次のビンをコンテキスト復号する手段と、受信されたビン値及びコンテキスト復号された次のビン値に基づいて１つ又は複数のシンタックス要素の値を決定する手段と、を備える、装置。
【0215】
条項２８Ｂ：第１の状態変数及び第２の状態変数に基づいてコンテキストモデルの確率状態を決定することが、第１の状態変数及び第２の状態変数の加重平均に基づいて確率状態を決定することを含む、条項２７Ｂの装置。
【0216】
条項２９Ｂ：コンテキストモデルに基づいて、第１の状態変数及び第２の状態変数の加重平均を計算するための重みを決定する手段、を更に備える、条項２８Ｂの装置。
【0217】
条項３０Ｂ：重みが、第１の重み及び第２の重みを含み、第１の重みと第２の重みとの和が、１に等しい、条項２９Ｂの装置。
【0218】
例によっては、本明細書で説明された技法のうちのいずれかのいくつかの行為又はイベントは、異なる順序で実行されることが可能であり、追加、統合、又は完全に除外されてもよい（例えば、説明された全ての行為又はイベントが技法の実践に必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為又はイベントは、連続的にではなく、例えば、マルチスレッド処理、割込み処理、又は複数のプロセッサを通じて並行して実行されてもよい。
【0219】
１つ又は複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせで実装されてもよい。ソフトウェアで実装される場合、機能は、１つ又は複数の命令又はコードとして、コンピュータ可読媒体上に記憶されてもよく、又はコンピュータ可読媒体を介して送信されてもよく、ハードウェアベースの処理ユニットによって実行されてもよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、又は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このように、コンピュータ可読媒体は一般に、（１）非一時的である有形のコンピュータ可読記憶媒体、又は（２）信号若しくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法を実装するための命令、コード、及び／又はデータ構造を取り出すために、１つ又は複数のコンピュータ又は１つ又は複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってもよい。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【0220】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ若しくは他の光ディスクストレージ、磁気ディスクストレージ、若しくは他の磁気ストレージデバイス、フラッシュメモリ、又は、命令若しくはデータ構造の形態の所望のプログラムコードを記憶するために使用でき、コンピュータによってアクセスできる任意の他の媒体を備えることができる。また、任意の接続がコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、又は他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線、及びマイクロ波などのワイヤレス技術は、媒体の定義の中に含まれる。しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時的な媒体を含まず、代わりに、非一時的な有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピーディスク（disk）及びブルーレイディスク（disc）を含み、ディスク（disk）は通常、データを磁気的に再生し、一方で、ディスク（disc）は、レーザーを用いてデータを光学的に再生する。上記の組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。
【0221】
命令は、１つ又は複数のＤＳＰ、汎用マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、又は他の等価な集積論理回路若しくはディスクリート論理回路など、１つ又は複数のプロセッサによって実行されてもよい。したがって、本明細書で使用される「プロセッサ」及び「処理回路」という用語は、上記の構造、又は本明細書で説明された技法の実装に適した任意の他の構造のうちのいずれかを指すことがある。加えて、いくつかの態様では、本明細書で説明された機能は、符号化及び復号のために構成された専用ハードウェアモジュール及び／若しくはソフトウェアモジュール内で提供されてもよく、又は複合コーデックの中に組み込まれてもよい。また、技法は、１つ又は複数の回路又は論理要素において完全に実装されてもよい。
【0222】
本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、又はＩＣのセット（例えば、チップセット）を含む、多種多様なデバイス又は装置に実装されてもよい。開示された技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、又はユニットについて本開示で説明したが、それらは必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて組み合わせられてもよく、又は好適なソフトウェア及び／若しくはファームウェアと連携して、上記で説明された１つ又は複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてもよい。
【0223】
様々な例について説明した。これら及び他の例は以下の特許請求の範囲内に入る。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【国際調査報告】