JP2020503799A - 双方向オプティカルフロー（ｂｉｏ）についての動きベクトル再構築 - Google Patents

Abstract

双方向インター予測されたブロックに対して、ビデオ復号器は、第１のＭＶを使用して、第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、第２のＭＶを使用して、第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、第１のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第１の最終予測サブブロックを決定することと、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、第２のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第２の最終予測サブブロックを決定することと、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータのブロックについての最終予測サブブロックを決定することとを行うように構成される。【選択図】図１６

Description

優先権の主張

本願は、２０１７年１月４日に出願された米国仮特許出願第６２／４４２，３５７号と、２０１７年１月１１日に出願された米国仮特許出願第６２／４４５，１５２号の利益を主張し、それらの両方の内容全体は、参照によってここに組み込まれる。

この開示は、ビデオコーディングに関する。

[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラ式または衛星無線電話、いわゆる「スマートフォン」、ビデオテレビ会議デバイス、ビデオストリーミングデバイス、および同様のものを含む、幅広い範囲のデバイスへと組み込まれることができる。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、アドバンスドビデオコーディング（ＡＶＣ）、ＩＴＵ−Ｔ Ｈ．２６５／高効率ビデオコーディング（ＨＥＶＣ）、およびそのような規格の拡張によって定義された規格に説明されているもののような、ビデオコーディング技法をインプリメントする。ビデオデバイスは、そのようなビデオコーディング技法をインプリメントすることによって、より効率的にデジタルビデオ情報を送信、受信、符号化、復号、および／または記憶し得る。

[0004]ビデオコーディング技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（例えば、ビデオフレームまたはビデオフレームの一部分）は、ビデオブロックへと区分され得、それはまた、ツリーブロック、コーディングユニット（ＣＵ）、および／またはコーディングノードと呼ばれ得る。ピクチャのイントラコーディングされた（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化され得る。ピクチャのインターコーディングされた（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャは、フレームと呼ばれ得、および参照ピクチャは、参照フレームと呼ばれ得る。

[0005]空間的または時間的予測は、コーディングされることになるブロックについての予測ブロックをもたらす。残差データは、コーディングされることになる元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコーディングされたブロックと予測ブロックとの間の差分を示す残差データにしたがって符号化される。イントラコーディングされるブロックは、イントラコーディングモードおよび残差データにしたがって符号化される。さらなる圧縮のために、残差データは、ピクセルドメインから変換ドメインに変換され得、残差変換係数をもたらし、それはその後、量子化され得る。最初に２次元アレイ中に配置された、量子化された変換係数は、変換係数の１次元ベクトルを作り出すために走査され得、およびエントロピーコーディングが、さらにいっそうの圧縮を達成するために適用され得る。

[0006]一般に、この開示は、ビデオコーディングにおける双方向オプティカルフロー（ＢＩＯ：bi-directional optical flow）に関する技法を説明する。この開示の技法は、高効率ビデオコーディング（ＨＥＶＣ）のような既存のビデオコーデックと併せて使用され得、または、将来のビデオコーディング規格のための効率的なコーディングツールであり得る。

[0007]この開示の一例によると、ビデオデータを復号する方法は、ビデオデータのブロックが双方向インター予測モードを使用して符号化されると決定することと、該ブロックについての第１の動きベクトル（ＭＶ）を決定すること、ここにおいて、第１のＭＶは、第１の参照ピクチャを指し示し、と、該ブロックについての第２のＭＶを決定すること、ここにおいて、第２のＭＶは、第２の参照ピクチャを指し示し、第１の参照ピクチャは、第２の参照ピクチャとは異なり、と、第１のＭＶを使用して、第１の参照ピクチャ中に第１の予測ブロックを定める（ロケートするlocating）ことと、第２のＭＶを使用して、第２の参照ピクチャ中に第２の予測ブロックを定める（ロケートする）ことと、第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第１の最終予測サブブロックを決定することと、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第２の最終予測サブブロックを決定することと、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータの該ブロックについての最終予測ブロックを決定することと、ビデオデータの該ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、を含む。

[0008]この開示の別の例によると、ビデオデータを復号するためのデバイスは、ビデオデータを記憶するように構成されたメモリと、ビデオデータのブロックが双方向インター予測モードを使用して符号化されると決定することと、該ブロックについての第１の動きベクトル（ＭＶ）を決定すること、ここにおいて、第１のＭＶは、第１の参照ピクチャを指し示し、と、該ブロックについての第２のＭＶを決定すること、ここにおいて、第２のＭＶは、第２の参照ピクチャを指し示し、第１の参照ピクチャは、第２の参照ピクチャとは異なり、と、第１のＭＶを使用して、第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、第２のＭＶを使用して、第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第１の最終予測サブブロックを決定することと、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第２の最終予測サブブロックを決定することと、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータの該ブロックについての最終予測ブロックを決定することと、ビデオデータの該ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、を行うように構成された１つまたは複数のプロセッサと、を含む。

[0009]この開示の別の例によると、コンピュータ可読記憶媒体は、１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサに、ビデオデータのブロックが双方向インター予測モードを使用して符号化されると決定することと、該ブロックについての第１の動きベクトル（ＭＶ）を決定すること、ここにおいて、第１のＭＶは、第１の参照ピクチャを指し示し、と、該ブロックについての第２のＭＶを決定すること、ここにおいて、第２のＭＶは、第２の参照ピクチャを指し示し、第１の参照ピクチャは、第２の参照ピクチャとは異なり、と、第１のＭＶを使用して、第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、第２のＭＶを使用して、第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第１の最終予測サブブロックを決定することと、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、
第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第２の最終予測サブブロックを決定することと、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータの該ブロックについての最終予測ブロックを決定することと、ビデオデータの該ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、を行わせる命令を記憶する。

[0010]この開示の別の例によると、ビデオデータを復号するための装置は、ビデオデータのブロックが双方向インター予測モードを使用して符号化されると決定するための手段と、該ブロックについての第１の動きベクトル（ＭＶ）を決定するための手段、ここにおいて、第１のＭＶは、第１の参照ピクチャを指し示し、と、該ブロックについての第２のＭＶを決定するための手段、ここにおいて、第２のＭＶは、第２の参照ピクチャを指し示し、第１の参照ピクチャは、第２の参照ピクチャとは異なり、と、第１のＭＶを使用して、第１の参照ピクチャ中に第１の予測ブロックをロケートするための手段と、第２のＭＶを使用して、第２の参照ピクチャ中に第２の予測ブロックをロケートするための手段と、第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定するための手段と、第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第１の最終予測サブブロックを決定するための手段と、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定するための手段と、第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータの該ブロックについての第２の最終予測サブブロックを決定するための手段と、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータの該ブロックについての最終予測ブロックを決定するための手段と、ビデオデータの該ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力するための手段と、を含む。

[0011]本開示の１つまたは複数の態様の詳細は、添付の図面および以下の説明中に記載される。この開示中に説明される技法の他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。

双方向オプティカルフローについての技法を利用し得る実例的なビデオ符号化および復号システムを例示するブロック図である。 動き補償フレームレートアップコンバージョン（ＭＣ−ＦＲＵＣ：motion compensated frame-rate up-conversion）のために実行されるブロックマッチングアルゴリズム（ＢＭＡ）としてユニラテラル（unilateral）動き推定（ＭＥ）の例を例示する概念図である。 ＭＣ−ＦＲＵＣのために遂行されるＢＭＡとしてバイラテラルＭＥの例を例示する概念図である。 マージモードの場合の空間的隣接ＭＶ候補を示す。 ＡＭＶＰモードの場合の空間的隣接ＭＶ候補を示す。 ＴＭＶＰ候補の例を示す。 ＭＶスケーリングの例を示す。 オプティカルフロー軌道（trajectory）の例を示す。 ８×４ブロックについてのＢＩＯの例を示す。 ８×４ブロックについての修正されたＢＩＯの例を示す。 ＯＢＭＣが適用されるサブブロックの実例的な例示を示す。 ＯＢＭＣが適用されるサブブロックの実例的な例示を示す。 ＯＢＭＣ重み付けの例を示す。 ＯＢＭＣ重み付けの例を示す。 ＯＢＭＣ重み付けの例を示す。 ＯＢＭＣ重み付けの例を示す。 ８×４ブロックについての提案されたＢＩＯについての例を示す。 ＯＢＭＣに関する（on）提案された簡略化されたＢＩＯの例を示す。 ＯＢＭＣに関する提案された簡略化されたＢＩＯの例を示す。 ＯＢＭＣに関する提案された簡略化されたＢＩＯの例を示す。 ＯＢＭＣに関する提案された簡略化されたＢＩＯの例を示す。 ５×５ウィンドウを有する４×４サブブロックについての実例的な重み付け関数を示す。 ビデオ符号化器の例を例示するブロック図である。 双方向オプティカルフローについての技法をインプリメントし得るビデオ復号器の例を例示するブロック図である。 この開示の技法にしたがって、ビデオ復号器の実例的な動作を例示するフローチャートである。

詳細な説明

[0030]一般に、この開示の技法は、双方向オプティカルフロー（ＢＩＯ）ビデオコーディング技法の改善に関する。ＢＩＯは、動き補償中に適用され得る。元来提案されたように、ＢＩＯは、より良い予測ブロック、例えば、ビデオデータの元のブロックとより密接にマッチする予測ブロック、を決定するために、オプティカルフロー軌道trajectory）に基づいて双予測（bi-predicted）インターコーディングされたブロックについての予測サンプル値を修正するために使用される。この開示の様々な技法は、ビデオデータのブロックを予測するときに、例えば、動き補償中に、いつＢＩＯを実行するか、およびＢＩＯを実行すべきかどうかを決定するために、単独または任意の組み合わせで、適用され得る。

[0031]この開示中に使用される場合、ビデオコーディングという用語は包括的に、ビデオ符号化またはビデオ復号のいずれかを指す。同様に、ビデオコーダという用語は包括的に、ビデオ符号化器またはビデオ復号器を指し得る。その上、ビデオ復号に関してこの開示中に説明されるある特定の技法はまた、ビデオ符号化に適用され得、および逆もまた然りである。例えば、ビデオ符号化器およびビデオ復号器は、同じプロセス、または相反するプロセスを実行するように構成されることが多い。また、ビデオ符号化器は典型的に、ビデオデータをどのように符号化するかを決定するプロセスの一部としてビデオ復号を実行する。したがって、その反対であると明示的に記載されない限り、ビデオ復号に関して説明される技法はまたビデオ符号化器によって実行されることはできない、またはその逆も然りである、と想定されるべきではない。

[0032]この開示はまた、現在のレイヤ、現在のブロック、現在のピクチャ、現在のスライス、等のような用語を使用し得る。この開示のコンテキストでは、現在の（current）という用語は、例えば、以前にまたは既にコーディングされたブロック、ピクチャ、およびスライス、あるいは未だにコーディングされていないブロック、ピクチャ、およびスライスとは対照的に、現在コーディングされているブロック、ピクチャ、スライス、等を識別することを意図される。

[0033]一般に、ピクチャは、ブロックへと分割され、それらの各々は、予測的にコーディングされ得る。ビデオコーダは、（現在のブロックを含むピクチャからのデータを使用する）イントラ予測技法、（現在のブロックを含むピクチャに対する以前にコーディングされたピクチャからのデータを使用する）インター予測技法、またはイントラブロックコピー、パレットモード、辞書モード、等のような他の技法を使用して現在のブロックを予測し得る。インター予測は、単方向（uni-directional）予測および双方向予測の両方を含む。

[0034]各インター予測されるブロックについて、ビデオコーダは、動き情報のセットを決定し得る。動き情報のセットは、前方（forward）および後方（backward）予測方向についての動き情報を包含し得る。ここで、前方および後方予測方向は、双方向予測モードの２つの予測方向である。「前方」および「後方」という用語は、必ずしもジオメトリー意味（geometry meaning）を有するわけではない。代わりに、それら用語は概して、参照ピクチャが現在のピクチャの前（「後方」）または後（「前方」）に表示されることになるかどうかに対応する。いくつかの例では、「前方」および「後方」予測方向は、現在ピクチャの参照ピクチャリスト０（ＲｅｆＰｉｃＬｉｓｔ０）と参照ピクチャリスト１（ＲｅｆＰｉｃＬｉｓｔ１）とに対応し得る。１つの参照ピクチャリストしかピクチャまたはスライスに対して利用可能でないとき、ＲｅｆＰｉｃＬｉｓｔ０のみが利用可能であり、およびスライスの各ブロックの動き情報は常に、ＲｅｆＰｉｃＬｉｓｔ０のピクチャを参照する（例えば、前方である）。

[0035]いくつかのケースでは、対応する参照インデックスとともに動きベクトルは、復号プロセスにおいて使用され得る。参照インデックスに関連するそのような動きベクトルは、動き情報の単予測（uni-predictive）セットとして表される。

[0036]各予測方向について、動き情報は、参照インデックスおよび動きベクトルを包含する。いくつかのケースでは、簡潔さのために、動きベクトル自体が、動きベクトルが関連する参照インデックスを有すると想定される方法で参照され得る。参照インデックスは、現在の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）中の参照ピクチャを識別するために使用され得る。動きベクトルは、水平（ｘ）および垂直（ｙ）成分を有する。一般に、水平成分は、参照ブロックのｘ座標をロケートする（定めるlocate）ために必要とされる、現在のピクチャ中の現在のブロックの位置に対する、参照ピクチャ内での水平変位を示し、一方、垂直成分は、参照ブロックのｙ座標をロケートするために必要とされる、現在のブロックの位置に対する、参照ピクチャ内での垂直変位を示す。

[0037]ピクチャ順序カウント（ＰＯＣ：Picture order count）値は、ピクチャの表示順序を識別するためにビデオコーディング規格において広く使用されている。１つのコーディングされたビデオシーケンス内の２つのピクチャが同じＰＯＣ値を有し得るケースが存在するが、これは典型的に、１つのコーディングされたビデオシーケンス内では起こらない。このことから、ピクチャのＰＯＣ値は、概して一意であり、およびこのことから、対応するピクチャを一意的に識別することができる。複数のコーディングされたビデオシーケンスがビットストリーム中に存在するとき、同じＰＯＣ値を有するピクチャは、復号順序の観点から互いにより近いことがあり得る。ピクチャのＰＯＣ値は典型的に、参照ピクチャリスト構築、ＨＥＶＣにあるような参照ピクチャセットの導出、および動きベクトルスケーリングのために使用される。

[0038]E. Alshina, A. Alshina, J.-H. Min, K. Choi, A. Saxena, M. Budagavi, “Known tools performance investigation for next generation video coding,” ITU - Telecommunications Standardization Sector, STUDY GROUP 16 Question 6, Video Coding Experts Group (VCEG), VCEG-AZ05, June. 2015, Warsaw, Poland（以下において「Ａｌｓｈｉｎａ１」と記載される）、およびA. Alshina, E. Alshina, T. Lee, “Bi-directional optical flow for improving motion compensation,” Picture Coding Symposium (PCS), Nagoya, Japan, 2010（以下において「Ａｌｓｈｉｎａ２」と記載される）は、双方向オプティカルフロー（ＢＩＯ）と呼ばれる方法を説明している。ＢＩＯは、ピクセルレベルのオプティカルフローに基づく。Ａｌｓｈｉｎａ１およびＡｌｓｈｉｎａ２によると、ＢＩＯは、前方（forward）予測および後方（backward）予測の両方を有するブロックにのみ適用される。Ａｌｓｈｉｎａ１およびＡｌｓｈｉｎａ２中に説明されているようなＢＩＯは、以下に要約される：

[0039]時間ｔにおけるピクセル値Ｉ_tが与えられると、ピクセル値の１次テイラー展開は、

である。

[0040]Ｉ_t0は、Ｉ_tの動き軌道（trajectory）上にある。すなわち、Ｉ_t0からＩ_tまでの動きは、公式において考慮される。

[0041]オプティカルフローの想定の下では：

であり、

とすると、式（Ａ）は、

になる。

[0042]

を移動速度と見なすと、Ｖ_x0およびＶ_y0が、それらを表すために使用され得る。

[0043]よって、式（Ｂ）は、

になる。

[0044]ｔ₀における前方参照およびｔ₁における後方参照を仮定し、そして
ｔ₀−ｔ＝ｔ−ｔ₁＝Δｔ＝１であると仮定する。

[0045]すると：

になる。

[0046]動きが軌道に沿っていることから、Ｖ_x0＝Ｖ_x1＝Ｖ_xおよびＶ_y0＝Ｖ_y1＝Ｖ_yであるとさらに想定される。よって、式（Ｄ）は、

になり、ここで、ΔＧ_x＝Ｇ_x0−Ｇ_x1、ΔＧ_y＝Ｇ_y0−Ｇ_y1は、再構築された参照に基づいて算出されることができる。

が通常の双予測であることから、

は、便宜上、これ以降ではＢＩＯオフセットと呼ばれる。

[0047]Ｖ_xおよびＶ_yは、次の歪みを最小化することによって符号化器および復号器の両方において導出される：

[0048]導出されるＶ_xおよびＶ_yを用いて、ブロックの最終予測が式（Ｅ）で算出される。Ｖ_xおよびＶ_yは、便宜上、「ＢＩＯ動き」と呼ばれる。

[0049]一般に、ビデオコーダは、動き補償中にＢＩＯを実行する。すなわち、ビデオコーダが現在のブロックについての動きベクトルを決定した後に、ビデオコーダは、動きベクトルに対する動き補償を使用して、現在のブロックについての予測されたブロックを作り出す。一般に、動きベクトルは、参照ピクチャ中の現在のブロックに対する参照ブロックのロケーションを識別する。ＢＩＯを実行するとき、ビデオコーダは、現在のブロックについての動きベクトルをピクセルごとに修正する。すなわち、ブロックユニットとして参照ブロックの各ピクセルを取り出すというよりはむしろ、ＢＩＯにしたがって、ビデオコーダは、現在のブロックについての動きベクトルに対するピクセルごとの修正を決定し、および参照ブロックが、動きベクトルによって識別される参照ピクセル、および現在のブロックの対応するピクセルについてのピクセルごとの修正を含むように、参照ブロックを構築する。このことから、ＢＩＯは、現在のブロックについてのより正確な参照ブロックを作り出すために使用され得る。

[0050]図１は、双方向オプティカルフローについての技法を利用し得る実例的なビデオ符号化および復号システム１０を例示するブロック図である。図１に示されているように、システム１０は、宛先デバイス１４によって後の時間に復号されることになる符号化されるビデオデータを提供するソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを提供する。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイス、または同様のものを含む、幅広い範囲のデバイスのうちの任意のものを備え得る。いくつかのケースでは、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。

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

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

[0053]この開示の技法は、ワイヤレスアプリケーションまたは設定に必ずしも限定されるわけではない。本技法は、無線テレビブロードキャスト、ケーブルテレビ送信、衛星テレビ送信、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）のようなインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、多様なマルチメディアアプリケーションのうちの任意のものをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティングおよび／またはビデオ電話通信のようなアプリケーションをサポートするための１方向（one-way）または２方向（two-way）ビデオ送信をサポートするように構成され得る。

[0054]図１の例では、ソースデバイス１２は、ビデオソース１８、ビデオ符号化器２０、および出力インターフェース２２を含む。宛先デバイス１４は、入力インターフェース２８、ビデオ復号器３０、およびディスプレイデバイス３２を含む。この開示にしたがって、ソースデバイス１２のビデオ符号化器２０は、双方向オプティカルフローのための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは配列を含み得る。例えば、ソースデバイス１２は、外部カメラのような外部ビデオソース１８からビデオデータを受信し得る。同じように、宛先デバイス１４は、統合されたディスプレイデバイスを含むというよりはむしろ、外部ディスプレイデバイスとインターフェースし得る。

[0055]図１の例示されているシステム１０は単に、一例に過ぎない。双方向オプティカルフローのための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって遂行され得る。概して、この開示の技法は、ビデオ符号化デバイスによって遂行されるが、本技法はまた、典型的に「ＣＯＤＥＣ」と呼ばれるビデオ符号化器／復号器によって遂行され得る。その上、この開示の技法はまた、ビデオプリプロセッサによって遂行され得る。ソースデバイス１２および宛先デバイス１４は単に、ソースデバイス１２が宛先デバイス１４への送信のためのコーディングされたビデオデータを生成するそのようなコーディングデバイスの例に過ぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化および復号コンポーネントを含むような実質的に対称的な方法で動作し得る。故に、システム１０は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス１２とビデオデバイス１４との間の１方向または２方向ビデオ送信をサポートし得る。

[0056]ソースデバイス１２のビデオソース１８は、ビデオカメラのようなビデオキャプチャデバイス、以前にキャプチャされたビデオを包含するビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてコンピュータグラフィックスベースのデータを、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組み合わせを生成し得る。いくつかのケースでは、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはビデオ電話を形成し得る。上述されたように、しかしながら、この開示中に説明される技法は、一般にビデオコーディングに適用可能であり得、およびワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。各ケースでは、キャプチャされた、事前にキャプチャされた、またはコンピュータ生成されたビデオは、ビデオ符号化器２０によって符号化され得る。符号化されたビデオ情報はその後、コンピュータ可読媒体１６上に出力インターフェース２２によって出力され得る。

[0057]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信のような一過性媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Ｂｌｕ-ｒａｙディスク、または他のコンピュータ可読媒体のような記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、ソースデバイス１２から符号化されたビデオデータを受信し、および例えば、ネットワーク送信を介して、宛先デバイス１４に符号化されたビデオデータを提供し得る。同様に、ディスクスタンピング設備のような媒体製造設備（medium production facility）のコンピューティングデバイスは、ソースデバイス１２から符号化されたビデオデータを受信し、および符号化されたビデオデータを包含するディスクを製造し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解され得る。

[0058]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオデータの特性および／または処理を記述するシンタックス要素を含む、ビデオ符号化器２０によって定義されたシンタックス情報を含み得、それはまた、ビデオ復号器３０によって使用される。ディスプレイデバイス３２は、ユーザに復号されたビデオデータを表示し、およびブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような多様なディスプレイデバイスのうちの任意のものを備え得る。

[0059]ビデオ符号化器２０およびビデオ復号器３０は、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣ（アドバンスドビデオコーディング）、またはＩＴＵ−Ｔ Ｈ．２６５とも呼ばれる高効率ビデオコーディング（ＨＥＶＣ）のような１つまたは複数のビデオコーディング規格にしたがって動作し得る。Ｈ．２６４は、International Telecommunication Union, “Advanced video coding for generic audiovisual services,” SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Infrastructure of audiovisual services - Coding of moving video, H.264, June 2011、中に説明されている。Ｈ．２６５は、International Telecommunication Union, “High efficiency video coding,” SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Infrastructure of audiovisual services - Coding of moving video, April 2015、中に説明されている。この開示の技法はまた、効率的なコーディングツールとして任意の他の以前のまたは将来のビデオコーディング規格に適用され得る。

[0060]他のビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびＨ．２６４のスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）拡張、ならびに範囲拡張、マルチビュー拡張（ＭＶ−ＨＥＶＣ）およびスケーラブル拡張（ＳＨＶＣ）のようなＨＥＶＣの拡張を含む。２０１５年４月に、ビデオコーディング専門家グループ（ＶＣＥＧ：the Video Coding Experts Group）は、次世代のビデオコーディング規格を対象にした新しい研究プロジェクトに着手した。参照ソフトウェアは、ＨＭ−ＫＴＡと呼ばれる。

[0061]ＩＴＵ−Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は現在、（ＨＥＶＣの現在の拡張およびスクリーンコンテンツコーディングおよびハイダイナミックレンジコーディングについての近々の拡張を含む）現在のＨＥＶＣ規格のそれを有意に上回る圧縮能力を有する将来のビデオコーディング技術の標準化の潜在的な必要性を研究している。グループは、このエリアにおけるそれらの専門家によって提案された圧縮技術設計を評価するために、共同ビデオ調査チーム（ＪＶＥＴ：the Joint Video Exploration Team）として知られている共同コラボレーションの取り組みにおいて、この調査活動で協働している。ＪＶＥＴは、２０１５年１０月１９日〜２１日中に最初の会合を行った。参照ソフトウェアの最新バージョン、すなわち、共同調査モデル３（ＪＥＭ３：Joint Exploration Model 3）は、https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-4.0/からダウンロードされることができる。共同調査テストモデル３（ＪＥＭ３）のアルゴリズム記述は、ＪＶＥＴ−Ｄ１００１と呼ばれることができる。

[0062]この開示の技法に関連するＨ．２６４およびＨＥＶＣのもののような、ある特定のビデオコーディング技法が、この開示中に説明される。この開示のある特定の技法は、理解を助けるためにＨ．２６４および／またはＨＥＶＣを参照して説明され得るが、説明される技法は、必ずしもＨ．２６４またはＨＥＶＣに限定されるわけではなく、他のコーディング規格および他のコーディングツールと併せて使用されることができる。

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

[0064]ＨＥＶＣおよび他のビデオコーディング仕様では、ビデオシーケンスは典型的に、一連のピクチャを含む。ピクチャはまた、「フレーム」と呼ばれ得る。ピクチャは、Ｓ_L、Ｓ_Cb、およびＳ_Crと表される３つのサンプルアレイを含み得る。Ｓ_Lは、ルーマサンプルの２次元アレイ（すなわち、ブロック）である。Ｓ_Cbは、Ｃｂクロミナンスサンプルの２次元アレイである。Ｓ_Crは、Ｃｒクロミナンスサンプルの２次元アレイである。クロミナンスサンプルはまた、ここでは「クロマ」サンプルと呼ばれ得る。他の事例では、ピクチャは、モノクロームであり得、およびルーマサンプルのアレイのみを含み得る。

[0065]ピクチャの符号化された表現を生成するために、ビデオ符号化器２０は、コーディングツリーユニット（ＣＴＵ）のセットを生成し得る。ＣＴＵの各々は、ルーマサンプルのコーディングツリーブロックと、クロマサンプルの２つの対応するコーディングツリーブロックと、それらコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは３つの別個の色平面を有するピクチャでは、ＣＴＵは、単一のコーディングツリーブロックと、そのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。コーディングツリーブロックは、サンプルのＮ×Ｎブロックであり得る。ＣＴＵはまた、「ツリーブロック」または「最大コーディングユニット」（ＬＣＵ）と呼ばれ得る。ＨＥＶＣのＣＴＵは、Ｈ．２６４／ＡＶＣのような他の規格のマクロブロックに大まかに類似し得る。しかしながら、ＣＴＵは、必ずしも特定のサイズに限定されるわけではなく、１つまたは複数のコーディングユニット（ＣＵ）を含み得る。スライスは、ラスター走査順序で連続して順序付けられた整数の数のＣＴＵを含み得る。

[0066]ＣＴＢは、四分木を包含し、それのノードは、コーディングユニットである。ＣＴＢのサイズは、（技術的には、８×８のＣＴＢサイズがサポートされることができるが）ＨＥＶＣメインプロファイルでは１６×１６〜６４×６４までの範囲であることができる。コーディングユニット（ＣＵ）は、ＣＴＢと同じサイズであることができるが、且つ８×８と同じくらい小さくあることできる。各コーディングユニットは、１つのモードでコーディングされる。ＣＵがインターコーディングされるとき、ＣＵは、２つまたは４つの予測ユニット（ＰＵ）へとさらに区分化され得るか、またはさらなる区分化が適用されないときには単に１つのＰＵになり得る。１つのＣＵ中に２つのＰＵが存在するとき、２つのＰＵは、半分のサイズの矩形、またはＣＵの１／４または３／４サイズを有する２つの矩形サイズであることができる。

[0067]コーディングされたＣＴＵを生成するために、ビデオ符号化器２０は、コーディングツリーブロックをコーディングブロックへと分割するために、ＣＴＵのコーディングツリーブロックに対して四分木区分化を再帰的に遂行し得、故に名称が「コーディングツリーユニット」である。コーディングブロックは、サンプルのＮ×Ｎブロックであり得る。ＣＵは、ルーマサンプルアレイ、Ｃｂサンプルアレイ、およびＣｒサンプルアレイを有するピクチャの、ルーマサンプルのコーディングブロックおよびクロマサンプルの２つの対応するコーディングブロックと、それらコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは３つの別個の色平面を有するピクチャでは、ＣＵは、単一のコーディングブロックと、そのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。

[0068]ビデオ符号化器２０は、ＣＵのコーディングブロックを、１つまたは複数の予測ブロックへと区分化し得る。予測ブロックは、同じ予測が適用されるサンプルの矩形（すなわち、正方形または非正方形）ブロックである。ＣＵの予測ユニット（ＰＵ）は、ルーマサンプルの予測ブロックと、クロマサンプルの２つの対応する予測ブロックと、それら予測ブロックを予測するために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは３つの別個の色平面を有するピクチャでは、ＰＵは、単一の予測ブロックと、その予測ブロックを予測するために使用されるシンタックス構造とを備え得る。ビデオ符号化器２０は、ＣＵの各ＰＵのルーマ、Ｃｂ、およびＣｒ予測ブロックについて、予測ルーマ、Ｃｂ、およびＣｒブロックを生成し得る。

[0069]ビデオ符号化器２０は、ＰＵについて、予測ブロックを生成するためにイントラ予測またはインター予測を使用し得る。ビデオ符号化器２０がＰＵの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオ符号化器２０は、ＰＵに関連付けられたピクチャの復号されたサンプルに基づいて、ＰＵの予測ブロックを生成し得る。ビデオ符号化器２０がＰＵの予測ブロックを生成するためにインター予測を使用する場合、ビデオ符号化器２０は、ＰＵに関連付けられたピクチャ以外の１つまたは複数のピクチャの復号されたサンプルに基づいて、ＰＵの予測ブロックを生成し得る。ＣＵがインターコーディングされるとき、動き情報の１つのセットが、各ＰＵに対して存在し得る。加えて、各ＰＵは、動き情報のセットを導出するために、一意のインター予測モードでコーディングされ得る。

[0070]ビデオ符号化器２０がＣＵの１つまたは複数のＰＵについて、予測ルーマ、Ｃｂ、およびＣｒブロックを生成した後に、ビデオ符号化器２０は、そのＣＵについてのルーマ残差ブロックを生成し得る。ＣＵのルーマ残差ブロック中の各サンプルは、ＣＵの予測ルーマブロックのうちの１つ中のルーマサンプルと、ＣＵの元のルーマコーディングブロック中の対応するサンプルとの間の差分を示す。加えて、ビデオ符号化器２０は、ＣＵについてのＣｂ残差ブロックを生成し得る。ＣＵのＣｂ残差ブロック中の各サンプルは、ＣＵの予測Ｃｂブロックのうちの１つ中のＣｂサンプルと、ＣＵの元のＣｂコーディングブロック中の対応するサンプルとの間の差分を示し得る。ビデオ符号化器２０はまた、ＣＵについてのＣｒ残差ブロックを生成し得る。ＣＵのＣｒ残差ブロック中の各サンプルは、ＣＵの予測Ｃｒブロックのうちの１つ中のＣｒサンプルと、ＣＵの元のＣｒコーディングブロック中の対応するサンプルとの間の差分を示し得る。

[0071]さらに、ビデオ符号化器２０は、ＣＵのルーマ、Ｃｂ、およびＣｒ残差ブロックを、１つまたは複数のルーマ、Ｃｂ、およびＣｒ変換ブロックへと分解するために、四分木区分化を使用し得る。変換ブロックは、同じ変換が適用されるサンプルの矩形（例えば、正方形または非正方形）ブロックである。ＣＵの変換ユニット（ＴＵ）は、ルーマサンプルの変換ブロックと、クロマサンプルの２つの対応する変換ブロックと、それら変換ブロックサンプルを変換するために使用されるシンタックス構造とを備え得る。このことから、ＣＵの各ＴＵは、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロックに関連付けられ得る。ＴＵに関連付けられたルーマ変換ブロックは、ＣＵのルーマ残差ブロックのサブブロックであり得る。Ｃｂ変換ブロックは、ＣＵのＣｂ残差ブロックのサブブロックであり得る。Ｃｒ変換ブロックは、ＣＵのＣｒ残差ブロックのサブブロックであり得る。モノクロームピクチャまたは３つの別個の色平面を有するピクチャでは、ＴＵは、単一の変換ブロックと、その変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。

[0072]ビデオ符号化器２０は、ＴＵについてのルーマ係数ブロックを生成するために、ＴＵのルーマ変換ブロックに１つまたは複数の変換を適用し得る。係数ブロックは、変換係数の２次元アレイであり得る。変換係数は、スカラー量であり得る。ビデオ符号化器２０は、ＴＵについてのＣｂ係数ブロックを生成するために、ＴＵのＣｂ変換ブロックに１つまたは複数の変換を適用し得る。ビデオ符号化器２０は、ＴＵについてのＣｒ係数ブロックを生成するために、ＴＵのＣｒ変換ブロックに１つまたは複数の変換を適用し得る。

[0073]係数ブロック（例えば、ルーマ係数ブロック、Ｃｂ係数ブロックまたはＣｒ係数ブロック）を生成した後に、ビデオ符号化器２０は、係数ブロックを量子化し得る。量子化は概して、変換係数を表すために使用されるデータの量をことによると低減するために変換係数が量子化されるプロセスを指し、さらなる圧縮を提供する。ビデオ符号化器２０が係数ブロックを量子化した後に、ビデオ符号化器２０は、量子化された変換係数を示すシンタックス要素をエントロピー符号化し得る。例えば、ビデオ符号化器２０は、量子化された変換係数を示すシンタックス要素に対してコンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ：Context-Adaptive Binary Arithmetic Coding）を遂行し得る。

[0074]ビデオ符号化器２０は、コーディングされたピクチャの表現と関連するデータとを形成するビットのシーケンスを含むビットストリームを出力し得る。ビットストリームは、ＮＡＬユニットのシーケンスを備え得る。ＮＡＬユニットは、ＮＡＬユニット中のデータのタイプのインジケーションと、エミュレーション防止ビットが必要に応じて組み入れられている（interspersed as necessary with）ＲＢＳＰのフォームのデータを包含するバイトと、を包含するシンタックス構造である。ＮＡＬユニットの各々は、ＮＡＬユニットヘッダを含み、およびＲＢＳＰをカプセル化する。ＮＡＬユニットヘッダは、ＮＡＬユニットタイプコードを示すシンタックス要素を含み得る。ＮＡＬユニットのＮＡＬユニットヘッダによって指定されるＮＡＬユニットタイプコードは、ＮＡＬユニットのタイプを示す。ＲＢＳＰは、ＮＡＬユニット内にカプセル化された整数の数のバイトを包含するシンタックス構造であり得る。いくつかの事例では、ＲＢＳＰは、０ビットを含む。

[0075]異なるタイプのＮＡＬユニットは、異なるタイプのＲＢＳＰをカプセル化し得る。例えば、第１のタイプのＮＡＬユニットは、ＰＰＳについてのＲＢＳＰをカプセル化し得、第２のタイプのＮＡＬユニットは、コーディングされたスライスについてのＲＢＳＰをカプセル化し得、第３のタイプのＮＡＬユニットは、ＳＥＩメッセージについてのＲＢＳＰをカプセル化し得、といった具合であり得る。（パラメータセットおよびＳＥＩメッセージについてのＲＢＳＰとは対照的に）ビデオコーディングデータについてのＲＢＳＰをカプセル化するＮＡＬユニットは、ＶＣＬ ＮＡＬユニットと呼ばれ得る。

[0076]ビデオ復号器３０は、ビデオ符号化器２０によって生成されたビットストリームを受信し得る。加えて、ビデオ復号器３０は、ビットストリームからシンタックス要素を取得するために、ビットストリームを構文解析し得る。ビデオ復号器３０は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築し得る。ビデオデータを再構築するためのプロセスは概して、ビデオ符号化器２０によって実行されるプロセスとは相補的であり得る。加えて、ビデオ復号器３０は、現在のＣＵのＴＵに関連付けられた係数ブロックを逆量子化し得る。ビデオ復号器３０は、現在のＣＵのＴＵに関連付けられた変換ブロックを再構築するために、係数ブロックに対して逆変換を実行し得る。ビデオ復号器３０は、現在のＣＵのＰＵについての予測ブロックのサンプルを、現在のＣＵのＴＵの変換ブロックの対応するサンプルに追加することによって、現在のＣＵのコーディングブロックを再構築し得る。ピクチャの各ＣＵについてのコーディングブロックを再構築することによって、ビデオ復号器３０は、ピクチャを再構築し得る。

[0077]この開示の技法にしたがって、ビデオ符号化器２０および／またはビデオ復号器３０はさらに、以下により詳細に論述されるように、動き補償中にＢＩＯ技法を実行し得る。

[0078]ビデオ符号化器２０およびビデオ復号器３０は各々、適宜、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック回路、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組み合わせのような、多様な適した符号化器または復号器回路のうちの任意のものとしてインプリメントされ得る。ビデオ符号化器２０およびビデオ復号器３０の各々は、１つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたビデオ符号化器／復号器（ＣＯＤＥＣ）の一部として統合され得る。ビデオ符号化器２０および／またはビデオ復号器３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラ電話のようなワイヤレス通信デバイスを備え得る。

[0079]図２は、動き補償フレームレートアップコンバージョン（ＭＣ−ＦＲＵＣ）のために実行されるブロックマッチングアルゴリズム（ＢＭＡ）としてユニラテラル（unilateral）動き推定（ＭＥ）の例を例示する概念図である。一般に、（ビデオ符号化器２０またはビデオ復号器３０のような）ビデオコーダは、現在のフレーム１００の現在のブロック１０６について、参照フレーム１０２からベストマッチングブロック（例えば、参照ブロック１０８）を探索することによって動きベクトル（ＭＶ）１１２のようなＭＶを取得するために、ユニラテラルＭＥを実行する。その後、ビデオコーダは、補間されたフレーム１０４中で動きベクトル１１２の動き軌道に沿って補間されたブロック１１０を補間する。すなわち、図２の例では、動きベクトル１１２は、現在のブロック１０６、参照ブロック１０８、および補間されたブロック１１０の中点を通過する。

[0080]図２に示されているように、動き軌道をたどる３つのフレーム中の３つのブロックが関わっている（involved）。現在のフレーム１００中の現在のブロック１０６は、コーディングされたブロックに属するが、参照フレーム１０２中のベストマッチングブロック（すなわち、参照ブロック１０８）は、コーディングされたブロックに完全には属する必要はない（すなわち、ベストマッチングブロックは、コーディングされたブロック境界上に収まらない（not fall on）ことがあり得るが、代わりに、そのような境界とオーバーラップし得る）。同じように、補間されたフレーム１０４中の補間されたブロック１１０は、コーディングされたブロックに完全には属する必要はない。その結果として、ブロックのオーバーラップされた領域と、満たされていない（穴）領域とが、補間されたフレーム１０４中に生じ得る。

[0081]オーバーラップに対処するために、単純なＦＲＵＣアルゴリズムは、オーバーラップされたピクセルを平均化および上書きすることを伴い得る。その上、穴は、参照または現在のフレームからのピクセル値によってカバーされ得る。しかしながら、これらのアルゴリズムは、ブロッキングアーティファクト（blocking artifacts）およびぼやけ（blurring）をもたらし得る。故に、動きフィールドセグメント化（motion field segmentation）、離散ハートレー変換を使用する連続補外（successive extrapolation）、および画像インペインティング（image inpainting）が、ブロッキングアーティファクトおよびぼやけを増大させることなしに、穴およびオーバーラップに対処するために使用され得る。

[0082]図３は、ＭＣ−ＦＲＵＣのために実行されるＢＭＡとしてバイラテラルＭＥの例を例示する概念図である。バイラテラルＭＥは、オーバーラップおよび穴によって引き起こされる問題を避けるために使用されることができる（ＭＣ−ＦＲＵＣにおける）別のソリューションである。バイラテラルＭＥを実行する（ビデオ符号化器２０および／またはビデオ復号器３０のような）ビデオコーダは、現在のフレーム１２０の現在のブロック１２６と参照フレーム１２２の参照ブロック１２８との間の時間的対称性を使用して、（現在のフレーム１２０と参照フレーム１２２との中間にある）補間されたフレーム１２４の補間されたブロック１３０を通るＭＶ１３２、１３４を取得する。結果として、ビデオコーダは、補間されたフレーム１２４中でオーバーラップおよび穴を生成しない。例えば、ビデオコーディングのケースにおいてあるように、現在のブロック１２６はビデオコーダがある特定の順序で処理するブロックであると想定すると、そのようなブロックのシーケンスは、オーバーラップなしに中間ピクチャ全体をカバーするであろう。例えば、ビデオコーディングのケースでは、ブロックは、復号順序で処理されることができる。したがって、そのような方法は、ＦＲＵＣのアイディアがビデオコーディングフレームワークにおいて考慮されることができる場合により適し得る。

[0083]S.-F. Tu, O. C. Au, Y. Wu, E. Luo and C.-H. Yeun, “A Novel Framework for Frame Rate Up Conversion by Predictive Variable Block-Size Motion Estimated Optical Flow,” International Congress on Image Signal Processing (CISP), 2009は、フレームレートアップコンバージョンのためのハイブリッドブロックレベル動き推定およびピクセルレベルオプティカルフロー方法を説明した。Ｔｕは、ハイブリッドシーンはどちらの個々の方法よりも優れていたと述べた。

[0084]ＨＥＶＣ規格では、マージモード（スキップモードはマージの特殊なケースと見なされる）および高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）モードと名付けられた、２つのインター予測モードが存在する。ＡＭＶＰモードまたはマージモードのいずれでも、ビデオコーダは、複数の動きベクトル予測子についてＭＶ候補リストを維持する。ビデオコーダは、特定のＰＵについての（１つ以上の）動きベクトル、ならびにマージモードにおける参照インデックスが、ＭＶ候補リストから１つの候補を選択すると決定する。

[0085]ＨＥＶＣでは、ＭＶ候補リストは、マージモードの場合は最大で５つまでの候補を、およびＡＭＶＰモードの場合は２つの候補のみを包含する。他のコーディング規格は、より多くのまたはより少ない候補を含み得る。マージ候補は、動き情報のセット、例えば、両方の参照ピクチャリスト（リスト０およびリスト１）に対応する動きベクトルと参照インデックスとを包含し得る。ビデオ復号器は、マージインデックスによって識別されるマージ候補を受信し、およびビデオ復号器は、識別された（１つ以上）参照ピクチャおよび（１つ以上）動きベクトルを使用して現在のＰＵを予測する。しかしながら、ＡＭＶＰモードの場合、リスト０またはリスト１のいずれかからの各潜在的な予測方向について、ＡＭＶＰ候補が１つの動きベクトルのみを包含することから、ＭＶ候補リストに対するＭＶＰ予測子（ＭＶＰ）インデックスとともに、参照インデックスが明示的にシグナリングされる必要がある。ＡＭＶＰモードでは、予測された動きベクトルは、さらに精緻化される（refined）ことができる。

[0086]マージ候補は、動き情報のフルセットに対応するが、その一方でＡＭＶＰ候補は、特定の予測方向についての単に１つの動きベクトルおよび参照インデックスを包含する。両方のモードについての候補は、同じ空間的および時間的隣接ブロックから同様に導出される。

[0087]図４Ａは、マージモードの場合の空間的隣接ＭＶ候補を示しており、および図４Ｂは、ＡＭＶＰモードの場合の空間的隣接ＭＶ候補を示している。ブロックから候補を生成する方法は、マージモードとＡＭＶＰモードとの場合で異なるが、空間的ＭＶ候補は、特定のＰＵ（ＰＵ₀）について、図４Ａおよび４Ｂに示されている隣接ブロックから導出される。

[0088]マージモードでは、最大で４つまでの空間的ＭＶ候補が、図４Ａに示されている順序で導出されることができる。順序は、次の通りである：図４Ａに示されているように、左（０）、上（１）、右上（２）、左下（３）、および左上（４）。空間的ＭＶ候補０〜３の全てが利用可能且つ一意である場合、ビデオコーダは、候補リスト中に左上ブロックについての動き情報を含めないことがあり得る。しかしながら、空間的ＭＶ候補０〜３のうちの１つまたは複数が利用可能でないか、または一意でない場合、ビデオコーダは、候補リスト中に左上ブロックについての動き情報を含め得る。

[0089]ＡＶＭＰモードでは、隣接ブロックは、２つのグループへと分割される：図４Ｂに示されているように、ブロック０および１から成る左グループ、およびブロック２、３、および４から成る上グループ。各グループについて、シグナリングされた参照インデックスによって示されたものと同じ参照ピクチャを参照する隣接ブロック中の潜在的な候補は、グループの最終候補を形成するために選ばれるための最高の優先度を有する。全ての隣接ブロックが同じ参照ピクチャを指し示す動きベクトルを包含するわけではない可能性がある。したがって、そのような候補が見出されることができない場合、第１の利用可能な候補が、最終候補を形成するためにスケーリングされることになり、このことから、時間的距離差分が補償されることができる。

[0090]図５Ａは、ＴＭＶＰ候補の例を示しており、および図５Ｂは、ＭＶスケーリングの例を示している。時間的動きベクトル予測子（ＴＭＶＰ）候補は、有効且つ利用可能である場合、ＭＶ候補リストへと、空間的動きベクトル候補の後に追加される。ＴＭＶＰ候補についての動きベクトル導出のプロセスは、マージモードとＡＭＶＰモードとの両方の場合で同じであるが、しかしながら、マージモードにおけるＴＭＶＰ候補についてのターゲット参照インデックスは、常に０に設定される。

[0091]ＴＭＶＰ候補導出のためのプライマリブロックロケーションは、ブロック「Ｔ」として図５Ａに示されているような、コロケートされたＰＵの外部の右下ブロックであり、空間的隣接候補を生成するために使用される上ブロックおよび左ブロックに対するバイアスを補償する。しかしながら、そのブロックが現在のＣＴＢ行の外部にロケートされるか、または動き情報が利用可能でない場合、そのブロックは、ＰＵの中心ブロックで代用される（substituted with）。

[0092]ＴＭＶＰ候補についての動きベクトルは、スライスレベルで示される、コロケートされたピクチャのコロケートされたＰＵから導出される。コロケートされたＰＵについての動きベクトルは、コロケートされたＭＶと呼ばれる。ＡＶＣにおける時間的直接モードと同様に、ＴＭＶＰ候補動きベクトルを導出するために、コロケートされたＭＶは、図５Ｂに示されているように、時間的距離差分を補償するためにスケーリングされる必要がある。

[0093]ＨＥＶＣはまた、動きベクトルスケーリングを利用する。動きベクトルの値は、提示時間におけるピクチャの距離に比例すると想定される。動きベクトルは、２つのピクチャ、参照ピクチャと、動きベクトルを包含するピクチャ（すなわち包含ピクチャ（the containing picture））とを関連付ける。動きベクトルが他の動きベクトルを予測するために利用されるとき、包含ピクチャと参照ピクチャとの距離は、ＰＯＣ値に基づいて算出される。

[0094]動きベクトルが予測されるために、動きベクトルの関連する包含ピクチャと参照ピクチャとの両方は、異なり得る。したがって、（ＰＯＣに基づく）新しい距離が算出され、および動きベクトルは、これらの２つのＰＯＣ距離に基づいてスケーリングされる。空間的隣接候補の場合、２つの動きベクトルについての包含ピクチャは同じであるが、参照ピクチャは異なる。ＨＥＶＣでは、動きベクトルスケーリングは、空間的および時間的隣接候補についてのＴＭＶＰとＡＭＶＰとの両方に適用される。

[0095]ＨＥＶＣはまた、疑似（artificial）動きベクトル候補生成を利用する。動きベクトル候補リストが完全でない場合、動きベクトル候補リスト中の全ての利用可能なエントリが候補を有するまで、疑似動きベクトル候補が生成され、且つリストの末尾に挿入される。マージモードでは、２つのタイプの疑似ＭＶ候補が存在する：Ｂスライスのためにのみ導出される合成（combined）候補、および第１のタイプが十分な疑似候補を提供しない場合にＡＭＶＰのためにのみ使用されるゼロ候補。候補リスト中に既に存在し、且つ必要な動き情報を有する候補の各ペアの場合、双方向合成動きベクトル候補は、リスト０中の１つのピクチャを参照する第１の候補の動きベクトルと、リスト１中の１つのピクチャを参照する第２の候補の動きベクトルとの組み合わせによって導出される。

[0096]ＨＥＶＣはまた、候補挿入のためのプルーニングプロセスを利用する。異なるブロックからの候補は、偶然同じであり得、それは、マージ／ＡＭＶＰ候補リストの効率を低下させる。プルーニングプロセスは、この問題を解決するために適用され得る。プルーニングプロセスは、同一の候補を挿入するのを避けるために、ある１つの候補を現在の候補リスト中の他の複数の候補に対して比較する。複雑性を低減するために、各潜在的な候補を全ての他の既存の候補と比較する代わりに、限定された数のプルーニングプロセスのみが適用され得る。一例として、ビデオコーダは、空間的および時間的隣接候補にプルーニングプロセスを適用し得るが、疑似的に（artificially）生成された候補には適用し得ない。

[0097]ここで、ＪＥＭにおける双方向オプティカルフローの態様が説明されることになる。図６は、オプティカルフロー軌道の例を示している。ＢＩＯは、双予測のケースでは、ブロックワイズ動き補償に加えて（on top of）実行されるピクセルワイズ動き精緻化（refinement）を利用する。ＢＩＯがブロック内部の微細な動きを補償することから、ＢＩＯをイネーブルにすることは事実上、動き補償のためにブロックサイズを拡大することをもたらし得る。サンプルレベル動き精微化は、網羅的な探索またはシグナリングを必要としないが、代わりに、各サンプルについての微細な動きベクトルを与える明確な式（an explicit equation）を利用する。

[0098]Ｉ^(k)を、補償ブロック動き（compensation block motion）の後の基準（reference）ｋ（ｋ＝０，１）からのルミナンス値とすると、∂Ｉ^(k)／∂ｘ、∂Ｉ^(k)／∂ｙは、それぞれ、Ｉ^(k)勾配（グラディエント）の水平および垂直成分である。オプティカルフローが有効であると想定すると、動きベクトルフィールド（ｖ_x，ｖ_y）が、式

によって与えられる。

[0099]各サンプルの動き軌道についてオプティカルフロー式をエルミート補間と組み合わせると、両端部において（at the ends）関数値Ｉ^(k)と導関数（derivatives）∂Ｉ^(k)／∂ｘ、∂Ｉ^(k)／∂ｙとの両方とマッチする３次の一意の多項式を得られる。ｔ＝０におけるこの多項式の値は、ＢＩＯ予測である：

[0100]ここで、τ₀およびτ₁は、図６に示されているような参照フレームまでの距離を表す。距離τ₀およびτ₁は、Ｒｅｆ０およびＲｅｆ１についてのＰＯＣに基づいて算出される：τ₀＝ＰＯＣ（ｃｕｒｒｅｎｔ）−ＰＯＣ（Ｒｅｆ０），τ₁＝ＰＯＣ（Ｒｅｆ１）−ＰＯＣ（ｃｕｒｒｅｎｔ）。両方の予測が同じ時間方向から来る場合（両方とも過去から、または両方とも将来から）、符号（signs）は、異なるτ₀・τ₁＜０。このケースでは、ＢＩＯは、予測が同じ時間モーメント（time moment）から来ない場合にのみ適用され（τ₀≠τ₁）、両方の参照される領域は、非ゼロ動きを有し（ＭＶｘ₀，ＭＶｙ₀，ＭＶｘ₁，ＭＶｙ₁≠０）、およびブロック動きベクトルは、時間距離に比例する（ＭＶｘ₀／ＭＶｘ₁＝ＭＶｙ₀／ＭＶｙ₁＝−τ₀／τ₁）。

[0101]ＢＩＯ動き量とも呼ばれる動きベクトルフィールド（ｖ_x，ｖ_y）は、点Ａ中の値と点Ｂ中の値との間の差分Δ（図６における動き軌道と参照フレーム面との交点（intersection））を最小化することによって決定される。モデルは、Δについて局所的テイラー展開の第１の線形項（first linear term of local Taylor expansion）のみを使用する：

[0102]（１）中の全ての値は、サンプルロケーション（ｉ’，ｊ’）に依存し、それは、これまで省略されていた。動きが局所的周辺（local surrounding）中で一貫していると想定すると、現在予測されている点（ｉ，ｊ）を中心とした（２Ｍ＋１）×（２Ｍ＋１）正方形ウィンドウΩ内部のΔは、次の通りに最小化され得る：

[0103]この最適化の問題について、まず最小化を垂直方向に、そして次に水平方向に行う簡略化されたソリューションが使用され得、それは：

をもたらし、ここで、

[0104]０または非常に小さい値による除算を避けるために、正則化パラメータｒおよびｍが、式（２）、（３）中に導入される。

ここで、ｄは、入力ビデオの内部ビット深度である。

[0105]いくつかのケースでは、ＢＩＯのＭＶ精緻化は、雑音または不規則な動きに起因して信頼性が低いことがあり得る。したがって、ＢＩＯでは、ＭＶ精緻化の大きさ（the magnitude）は、ある特定のしきい値ｔｈＢＩＯにクリップされる。しきい値は、現在のピクチャの全ての参照ピクチャが全て１つの方向からのものであるかどうかに基づいて決定される。現在のピクチャの現在のピクチャの全ての参照ピクチャが１つの方向からのものである場合、しきい値は、１２×２^14-dに設定され得、そうでない場合は、しきい値は、１２×２^13-dに設定され得る。

[0106]ＢＩＯについての勾配（gradients）は、ＨＥＶＣ動き補償プロセスと一致する動作（２Ｄ分離型ＦＩＲ（2D separable FIR））を使用して、動き補償補間と同じ時間に算出される。この２Ｄ分離型ＦＩＲのための入力は、ブロック動きベクトルの分数部分（the fractional part）にしたがった分数位置（fractional position）（ｆｒａｃＸ，ｆｒａｃＹ）および動き補償プロセスのためのと同じ参照フレームサンプルである。水平勾配∂Ｉ／∂ｘのケースでは、信号がまず、デスケーリングシフト（de-scaling shift）ｄ−８を伴う（with）分数位置ｆｒａｃＹに対応するＢＩＯｆｉｌｔｅｒＳを使用して垂直に補間され、次に１８−ｄだけデスケーリングシフトを伴う（with）分数位置ｆｒａｃＸに対応する勾配フィルタＢＩＯｆｉｌｔｅｒＧが、水平方向に適用される。垂直勾配∂Ｉ／∂ｙのケースでは、まず勾配フィルタが、デスケーリングシフトｄ−８を伴う（with）分数位置ｆｒａｃＹに対応するＢＩＯｆｉｌｔｅｒＧを使用して垂直に適用され、次に信号変位（signal displacement）が、１８−ｄだけデスケーリングシフトを伴う（with）分数位置ｆｒａｃＸに対応するＢＩＯｆｉｌｔｅｒＳを使用して水平方向に実行される。勾配算出のための補間フィルタＢＩＯｆｉｌｔｅｒＧおよび信号変位のための補間フィルタＢＩＯｆｉｌｔｅｒＦの長さは、合理的な複雑性を維持するためにより短い（６タップ）。表１は、ＢＩＯにおけるブロック動きベクトルの異なる分数位置についての勾配算出のために使用されるフィルタを示している。表２は、ＢＩＯにおける予測信号生成のために使用される補間フィルタを示している。

[0107]図７は、８×４ブロックについての勾配（gradient）算出の例を示している。８×４ブロックについて、ビデオコーダは、動き補償予測子をフェッチし、現在のブロック内の全てのピクセルのＨＯＲ／ＶＥＲ勾配と、ピクセルの外側の２つの線（outer two lines）とを計算するが、これは、各ピクセルについてのｖｘおよびｖｙを解くことが、式（４）中に示されているように、各ピクセルを中心としたウィンドウΩ内のピクセルの動き補償予測子およびＨＯＲ／ＶＥＲ勾配値を必要とするからである。ＪＥＭでは、このウィンドウのサイズは、５×５に設定される。したがって、ビデオコーダは、動き補償予測子をフェッチし、およびピクセルの外側の２つの線（outer two lines）についての勾配を算出する必要がある。

[0108]ＪＥＭでは、ＢＩＯは、２つの予測が異なる参照ピクチャからのものであるとき、全ての双方向予測されたブロックに適用される。ＬＩＣがＣＵについてイネーブルにされると、ＢＩＯは、ディセーブルにされる。

[0109]図８は、ＪＶＥＴ−Ｄ００４２中に提案された８×４ブロックについての修正されたＢＩＯの例を示している。第４回のＪＶＥＴの会合において、ＢＩＯ動作を修正し、およびメモリアクセス帯域幅を低減するための提案書ＪＶＥＴ−Ｄ００４２（A. Alshina, E. Alshina, “AHG6: On BIO memory bandwidth”, JVET-D0042, October 2016）が提出された。この提案書では、いかなる動き補償予測も勾配値も、現在のブロックの外部のピクセルに必要とされない。その上、各ピクセルについてのｖｘおよびｖｙを解くことは、図８中に示されているような、現在のブロック内の全てのピクセルの勾配値および動き補償予測子を使用して修正される。言い換えれば、式（４）中の正方形ウィンドウΩは、現在のブロックに等しいウィンドウに修正される。この上、重み付け係数ｗ（ｉ’，ｊ’）が、ｖｘおよびｖｙを導出するために考慮される。ｗ（ｉ’，ｊ’）は、中心ピクセル（ｉ，ｊ）の位置およびウィンドウ内のピクセル（Ｉ’，ｊ’）の位置の関数である。

[0110]ここで、ＪＥＭにおけるオーバーラップブロック動き補償（ＯＢＭＣ：Overlapped Block Motion Compensation）の態様が説明されることになる。ＯＢＭＣは、例えば、Ｈ．２６３においてあるように、初期世代のビデオ規格に対して使用されてきた。ＪＥＭでは、ＯＢＭＣは、ＣＵの右および下の境界を除き、全ての動き補償（ＭＣ）ブロック境界について実行される。その上、ＯＢＭＣは、ルーマ成分とクロマ成分との両方に適用され得る。ＪＥＭでは、ＭＣブロックは、コーディングブロックに対応している。ＣＵが（J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, J. Boyce, “Algorithm Description of Joint Exploration Test Model 4,” JVET-D1001, October 2016、中に説明されているようなサブＣＵマージ、アフィンおよびＦＲＵＣモードを含む）サブＣＵモードでコーディングされるとき、ＣＵの各サブブロックは、ＭＣブロックである。均一の様式でＣＵ境界を処理するために、ＯＢＭＣは、全てのＭＣブロック境界についてサブブロックレベルで実行され、ここで、サブブロックサイズは、図９Ａおよび９Ｂに例示されているように、４×４に等しく設定される。

[0111]ＯＢＭＣが現在のサブブロックに適用されるとき、現在の動きベクトルの他に、４つの接続された隣接サブブロックの動きベクトルもまた、利用可能であり且つ現在の動きベクトルと同一でない場合には、現在のサブブロックについての予測ブロックを導出するために使用される。複数の動きベクトルに基づくこれらの複数の予測ブロックは、現在のサブブロックの最終予測信号を生成するために組み合わされる。

[0112]図１０に示されているように、隣接サブブロックの動きベクトルに基づく予測ブロックは、Ｐ_Nとして表され、ここで、Ｎは、隣接する上、下、左および右サブブロックについてのインデックスを示し、および現在のサブブロックの動きベクトルに基づく予測ブロックは、Ｐ_Cとして表される。Ｐ_Nが現在のサブブロックに対して同じ動き情報を包含する隣接サブブロックの動き情報に基づくとき、ＯＢＭＣは、Ｐ_Nから実行されない。そうでないとき、Ｐ_Nのそれぞれのピクセルは、Ｐ_C中の同じピクセルに追加される、すなわち、Ｐ_Nの４つの行／列が、Ｐ_Cに追加される。重み付け係数｛１／４，１／８，１／１６，１／３２｝は、Ｐ_Nに対して使用され、および重み付け係数｛３／４，７／８，１５／１６，３１／３２｝は、Ｐ_Cに対して使用される。例外は、小さいＭＣブロックであり、（すなわち、コーディングブロックの高さまたは幅が４に等しいか、またはＣＵがサブＣＵモードでコーディングされるとき）、それについては、Ｐ_Nの２つの行／列のみが、Ｐ_Cに追加される。このケースは、重み付け係数｛１／４，１／８｝は、Ｐ_Nに対して使用され、および重み付け係数｛３／４，７／８｝は、Ｐ_Cに対して使用される。垂直に（水平に）隣接するサブブロックの動きベクトルに基づいて生成されるＰ_Nの場合、Ｐ_Nの同じ行（列）中のピクセルが、同じ重み付け係数を有するＰ_Cに追加される。ＢＩＯはまた、予測ブロックＰ_Nの導出のために適用され得る。

[0113]ＪＥＭでは、２５６個のルーマサンプル以下のサイズを有するＣＵの場合、ＣＵレベルフラグが、ＯＢＭＣが現在のＣＵについて適用されるか否かを示すためにシグナリングされる。２５６個のルーマサンプルより大きいサイズを有するか、またはＡＭＶＰモードでコーディングされないＣＵの場合、ＯＢＭＣは、デフォルトで適用される。符号化器において、ＯＢＭＣがＣＵに適用されるとき、その影響は、動き推定ステージ中に考慮に入れられる。上部隣接ブロックおよび左隣接ブロックの動き情報を使用することによる予測信号は、現在のＣＵの元の信号の上部および左境界を補償するために使用され、およびその後、通常の動き推定プロセスが適用される。

[0114]ＢＩＯは、ＪＥＭ４．０における１％より多くのＢｊｏｎｔｅｇａａｒｄ−Ｄｅｌｔａビットレート（ＢＤレート）低減を潜在的に提供するが、ＢＩＯはまた潜在的に、有意な計算の複雑性をもたらし、および符号化器と復号器との両方についてメモリ帯域幅の増大を必要とし得る。この開示は、ＢＩＯに関連付けられた必要とされるメモリ帯域幅および計算の複雑性を潜在的に低減し得る技法を説明している。一例では、この開示の技法にしたがって、ビデオコーダは、サブブロックレベルでＢＩＯ動き量、例えば、上述されたｖｘおよびｖｙ値、を決定し、およびサンプルごとに予測ブロックのサンプル値を修正するために、その決定されたＢＩＯ動き量を使用し得る。それ故に、この開示の技法は、ビデオ符号化器およびビデオ復号器を、それらが、ＢＩＯの既存のインプリメンテーションのために必要とされる実質的な処理およびメモリ負担を招くことなしに、ＢＩＯのコーディング利得を達成することを可能にすることによって、改善し得る。

[0115]式（４）に基づいて、この開示は、ウィンドウΩを再定義することによってＢＩＯの複雑性を低減するための技法を紹介する。そのような技法は、例えば、ビデオ符号化器２０（例えば、動き推定ユニット４２および／または動き補償ユニット４４）によって、またはビデオ復号器３０（例えば、動き補償ユニット７２）によって遂行され得る。ウィンドウΩは、Ｍ×Ｎのサイズを有する、現在のピクセルをカバーする現在のブロック内の任意のブロックとして定義され、ここで、ＭおよびＮは、任意の正の整数である。一例では、現在のブロックは、オーバーラップされていないサブブロックへと分割され、およびウィンドウΩは、現在のピクセルをカバーするサブブロックとして定義される。図１１に示されているような別の例では、サブブロックは、現在のピクセルをカバーする、動きベクトル記憶のための最小ブロックとして定義される。ＨＥＶＣおよびＪＥＭでは、最小ブロックサイズは、４×４である。別の例では、ウィンドウΩのサイズは、現在のブロックのサイズ、コーディングモードのようなコーディング情報にしたがって適応的である。現在のブロックサイズがより大きいとき、より大きいウィンドウΩが使用されることができる。現在のブロックがサブＣＵマージ、アフィンおよびＦＲＵＣモードのようなサブブロックモードとしてコーディングされるとき、ウィンドウΩは、サブブロックとして設定される。

[0116]図１１は、ピクセルＡ、ＢおよびＣについてのウィンドウΩを伴う、この開示の技法にしたがって、８×４ブロックについての提案されたＢＩＯの例を示している。この開示の技法によると、均等な重み付けが、式（７）中に示されているように、ｖｘおよびｖｙを解くために使用され得る。別の例では、不均等な重み付けが、式（１０）中に示されているように、ｖｘおよびｖｙを解くために使用されることができる。不均等な重み付けは、中心ピクセルと関連するピクセルとの間の距離の関数であることができる。さらに別の例では、重み付けは、例えば、https://en.wikipedia.org/wiki/Bilateral_filterにおいて説明されている、バイラテラルアプローチを使用して算出されることができる。その上、ルックアップテーブルが、式（７）中のウィンドウΩについての各ピクセルについての全ての重み付け係数を記憶するために使用されることができる。

[0117]別の例では、ＯＢＭＣのためにＰ_Nを導出するとき、ＢＩＯは、隣接動きを使用して予測子を導出するときにのみ部分的ピクセルについて遂行される。一例では、ＢＩＯは、Ｐ_Nを導出する際に全てのピクセルについて完全にディセーブルにされる。さらなる別の例では、ＢＩＯは、図１２Ａ〜１２Ｄに示されているように、外側の２つの線（outer two lines）中のピクセルに対してのみ適用される。

[0118]その上、各ブロックについて、いくつの線をＢＩＯは適用されるかは、ＳＰＳ／ＰＰＳのスライスレベル中で明示的にシグナリングされることができる。ＢＩＯがディセーブルにされるか、または部分的にディセーブルにされるかもまた、ＳＰＳ／ＰＰＳのスライスレベルで明示的にシグナリングされることができる。

[0119]その一方では、いくつの線をＢＩＯは適用されるかは、ＣＵモード（サブブロックモードまたは非サブブロックモード）またはブロックサイズまたはシグナリングされる照明補償（ＩＣ）フラグのような他のツールの組み合わせのような、ある特定のコーディング条件に暗示的に基づくことができる。ＢＩＯがディセーブルにされるか、または部分的にディセーブルにされるかもまた、ＣＵモード（サブブロックモードまたは非サブブロックモード）またはブロックサイズまたはシグナリングされるＩＣフラグのような他のツールの組み合わせのような、ある特定の条件に基づいて暗示的に導出されることができる。

[0120]図１２Ａ〜１２Ｄは、この開示の技法にしたがって、ＯＢＭＣに関する提案された簡略化されたＢＩＯの例を示しており、ここで、ｘは、ＢＩＯなしで導出される予測子を表し、およびｏは、ＢＩＯを伴って導出される予測子を表す。ＢＩＯからの動きベクトル精緻化は、ブロックベースであることができる。ブロックサイズをＭ×Ｎとすると、重み付け関数は、式（７）中の項の算出中に異なるロケーションのピクセルに異なるスケール係数を提供するために使用されることができる。式（５）および（６）を解くとき、ブロック全体から収集された補間されたピクセルおよびそれらの勾配値（gradient values）は、各ピクセル位置について個々にｖｘおよびｖｙを解く代わりに、一緒にｖｘおよびｖｙを解くために使用されることができる。

[0121]一例では、ウィンドウサイズオメガは、各ピクセルロケーションを中心とした実行ウィンドウとして定義されることができ、および全てのロケーションからの値を合計することによる平均値が使用される。具体的には、

であり、ここで、Ｎは、各サブブロック中のピクセルの数であり、およびΩ_kは、各ピクセルについて定義されるウィンドウである。一例では、Ω_kは、各ピクセルについての現在のＢＩＯ設計中に定義される５×５ウィンドウであることができ、および故に、重み付け関数は、前もって決定されることができる。５×５ウィンドウを有する４×４サブブロックに対して使用される重み付け関数の例が、図１３に示されている。図１３は、５×５ウィンドウを有する４×４サブブロックについての重み付け関数の例を示している。

[0122]別の例では、重み付け関数は、ＳＰＳ、ＰＰＳ、またはスライスヘッダ中で送られることができる。シグナリングコストを低減するために、予め定義された重み付け関数のセットが、記憶されることができ、および重み付け関数のインデックスのみが、シグナリングされる必要がある。

[0123]別の例では、精緻化された（refined）動きベクトルは、サブブロックの中心部分にあるピクセルを使用して見出されることができる。式（７）中の変数ｓ１〜ｓ６を算出するために、中心ピクセルの勾配（gradient）値が、補間フィルタを使用して算出され、サイズＭ×Ｎのウィンドウが、補間されたピクセルに適用されることができ、中心ピクセルへの異なる重みを提供する。一例では、中心点の勾配値が、算出されることができ、中心点の平均値が、使用されることができる（等しい重みのウィンドウ）。別の例では、式（７）中の変数ｓ１〜ｓ６を算出するために、中央値フィルタ（median filter）が、代表的なピクセルを選択するために使用されることができる。

[0124]ＪＶＥＴ−Ｄ００４２では、（１つまたは複数の）ＢＩＯオフセットについて解くとき、各ピクセルについてのウィンドウサイズは、現在ブロック全体になるように修正され得、それは、現在ブロックが８×４以上であるときに、現在の設計に計算の複雑性を潜在的に追加する。修正の最悪のケースは、１２８×１２８ウィンドウが１２８×１２８ブロック内の各ピクセルについての勾配および予測子の蓄積（accumulation）のために使用されることである。

[0125]その上、１つのＣＵ内のサブブロックが同じＭＶを共有するか、または１つのインターコーディングされたＣＵが動き補償（ＭＣ）のためにより小さいサブブロックへと分割されるとき、ＪＥＭ−４．０は、平行して各サブブロックについてＭＣおよびＢＩＯを遂行するか、または一度の取り組みで（in one-time effort）同じＭＶを有するサブブロックのアグリゲートされたより大きいブロックについてＭＣおよびＢＩＯを遂行するかのいずれかのために、柔軟性を提供する。いずれの方法でも、ＪＥＭ−４．０は、同一のコーディング結果を提供する。しかしながら、ＪＶＥＴ−Ｄ００４２中の修正されたＢＩＯは、一緒にまたは別個に２つの隣接する同じ動きブロックについてＭＣおよびＢＩＯを遂行することが異なる結果をもたらし得るような、ブロックサイズ依存勾配算出および重み付け係数を利用する。異なる結果を避けるために、復号器はブロックレベルまたはある特定のサブブロックレベルのいずれかでＭＣおよびＢＩＯを遂行すべきであることが指定されなければならない。そのような制約は、厳し過ぎ得、および実際的なコーデックインプリメンテーションには望ましくないことがあり得る

[0126]式（４）に基づいて、ＢＩＯの複雑性は、ウィンドウΩを再定義することによってさらに低減され得る。ウィンドウΩの２つのタイプが定義される；１つは、オーバーラップしていないウィンドウであり、および他の１つは、スライディングウィンドウである。オーバーラップしていないウィンドウのタイプの場合、現在のブロックは、オーバーラップしていないサブブロックへと分割され、およびウィンドウΩは、図１１に示されているような、現在のピクセルをカバーするサブブロックとして定義される。スライディングウィンドウのタイプの場合、ウィンドウΩは、図７に示されているような、現在のピクセルを中心としたブロックとして定義される。

[0127]ウィンドウΩの両方のタイプについて、ウィンドウΩのサイズは、以下に例示されているような異なる方法を使用して決定されることができる。これ以降、ウィンドウΩはサイズＭ×Ｎを有する矩形ブロックであると想定され得、ここで、ＭおよびＮは、（４×４、８×８、１６×１６、８×４、等）のような任意の非負の整数であることができる。ウィンドウΩは、矩形形状に限定されず、および菱形（diamond）形状のような任意の他の形状であることができる。説明される技法はまた、適用可能である場合、矩形形状以外の形状に適用されることができる。

[0128]ウィンドウのサイズは、固定または可変であり得、および予め定められているか、またはビットストリーム中でシグナリングされるかのいずれかであり得る。サイズがシグナリングされるとき、サイズは、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、スライスヘッダ中で、またはＣＴＵレベルでシグナリングされ得る。ウィンドウサイズは、以下の式による動き補償（ＭＣ）ブロックのサイズによって一緒に決定されることができる。
水平ウィンドウサイズＭ＝ｍｉｎ（Ｍ，ＭＣ＿Ｓｉｚｅ）；
垂直ウィンドウサイズＭ＝ｍｉｎ（Ｎ，ＭＣ＿Ｓｉｚｅ）。

[0129]一例では、動き補償（ＭＣ）ブロックは、現在のブロックのサイズおよびコーディングモードのようなコーディング情報に純粋に依存している。例えば、動き補償（ＭＣ）ブロックは、現在のＣＵがサブＣＵマージ、アフィンおよびＦＲＵＣモードのような非サブブロックモードでコーディングされるときに、ＣＵ全体として設定される。動き補償（ＭＣ）ブロックは、サブブロックが同じ動き情報を有するかどうかにかかわらず、サブＣＵマージ、アフィンおよびＦＲＵＣモードのようなサブブロックモードが使用されるときに、サブブロックとして設定される。

[0130]別の例では、動き補償（ＭＣ）ブロックは、同じＭＶを有するＣＵ内のサンプルのブロックとして定義される。このケースでは、動き補償（ＭＣ）ブロックは、現在のＣＵがサブＣＵマージ、アフィンおよびＦＲＵＣモードのような非サブブロックモードでコーディングされるときに、ＣＵ全体として設定される。ＣＵがサブＣＵマージ、アフィンおよびＦＲＵＣモードのようなサブブロックモードでコーディングされるとき、同じ動き情報を有するサブブロックは、サブブロックのある特定の走査順序で動き補償（ＭＣ）ブロックとしてマージされる。

[0131]適応的サイズ：ウィンドウΩのサイズは、現在のブロックのサイズ、コーディングモードのようなコーディング情報にしたがって適応的である。一例では、ウィンドウΩは、現在のブロックがサブＣＵマージ、アフィンおよびＦＲＵＣモードのような非サブブロックモードとしてコーディングされるときに、現在のブロック全体または現在のブロックの４分の１として設定される；およびウィンドウΩは、現在のブロックがサブブロックモードでコーディングされるときに、サブブロックとして設定される。適応的ウィンドウサイズは、以下の式による動き補償（ＭＣ）ブロックのサイズによって一緒に決定されることができる。
水平ウィンドウサイズＭ＝ｍｉｎ（Ｍ，ＭＣ＿Ｓｉｚｅ）；
垂直ウィンドウサイズＭ＝ｍｉｎ（Ｎ，ＭＣ＿Ｓｉｚｅ）。

[0132]ウィンドウΩのサイズを決定するための様々な技法について、サイズの高レベル限定が、フレンドリーなハードウェアまたはソフトウェアインプリメンテーションのために含まれることができる。例えば、ウィンドウサイズは、ビデオコーデックシステム中で許容される最大変形ユニット（ＴＵ）サイズ以下であるべきである。別の例では、ウィンドウサイズは、４×４のような最小ＭＣブロック以上であるべきである。

[0133]ＢＩＯ関連動作をさらに簡略化するために、この開示は、全ての動き補償予測が終了した後の後処理としてＢＩＯを実行するための技法を紹介する。具体的に言えば、従来のＭＣが終わった後に、ＯＢＭＣがその後、現在のブロックについてのより良い予測子を生成するために適用されることができる。最終予測子に基づいて、ＢＩＯがその後、予測子をさらに精微化するために、現在のブロックの動き情報を使用して適用される。例えば、ＢＩＯにおける勾配算出のために、ブロック全体の動きが使用され得る。別の例では、各サブブロックについて、ＯＢＭＣからの平均動きベクトルが使用されることができる。別の例では、各サブブロックについて、（個々に各次元についての）中央値動きベクトルが使用されることができる。

[0134]重み付け関数は、ＢＩＯの動きベクトル精緻化のブロックベースの導出を考慮すると、異なって設計されることができる。等しい重みは、上述された方法のうちのいずれに対しても使用されることができる。代替として、より多くの重みが、ウィンドウの中心部分に向かって配置されることができる。一例では、重みは、ウィンドウの中心からピクセルまでの間の（Ｌ１−ｎｏｒｍまたはＬ２−ｎｏｒｍを含むが、それらに限定されない）逆距離によって算出されることができる。

[0135]図１４は、双方向オプティカルフローについての技法をインプリメントし得るビデオ符号化器２０の例を例示するブロック図である。ビデオ符号化器２０は、ビデオスライス内のビデオブロックのイントラおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間的冗長性を低減または取り除くために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間的冗長性を低減または取り除くために時間的予測に依拠する。イントラ（I）モードは、いくつかの空間ベースのコーディングモードのうちの任意のものを指し得る。単方向予測（Ｐモード）または双予測（Ｂモード）のようなインターモードは、いくつかの時間ベースのコーディングモードのうちの任意のものを指し得る。

[0136]図１４に示されているように、ビデオ符号化器２０は、ビデオデータを受信し、およびビデオデータメモリ３８中に受信されたビデオデータを記憶する。ビデオデータメモリ３８は、ビデオ符号化器２０のコンポーネントによって符号化されることになるビデオデータを記憶し得る。ビデオデータメモリ３８中に記憶されるビデオデータは、例えば、ビデオソース１８から取得され得る。参照ピクチャメモリ６４は、例えば、イントラまたはインターコーディングモードで、ビデオ符号化器２０によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ３８および参照ピクチャメモリ６４は、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスを含むＤＲＡＭのような、多様なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ３８および参照ピクチャメモリ６４は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ３８は、ビデオ符号化器２０の他のコンポーネントとともにオンチップであり得るか、またはそれらのコンポーネントに対してオフチップであり得る。

[0137]ビデオ符号化器２０は、符号化されることになるビデオフレーム内の現在のビデオブロックを受信する。図１４の例では、ビデオ符号化器２０は、モード選択ユニット４０、（復号ピクチャバッファ（ＤＰＢ）とも呼ばれ得る）参照ピクチャメモリ６４、加算器５０、変換処理ユニット５２、量子化ユニット５４、およびエントロピー符号化ユニット５６を含む。モード選択ユニット４０は次に、動き補償ユニット４４、動き推定ユニット４２、イントラ予測処理ユニット４６、および区分化ユニット４８を含む。ビデオブロック再構築のために、ビデオ符号化器２０はまた、逆量子化ユニット５８、逆変換処理ユニット６０、および加算器６２を含む。デブロッキングフィルタ（deblocking filter）（図１４には図示せず）もまた、再構築されたビデオからブロッキネスアーティファクト（blockiness artifact）を取り除くようにブロック境界をフィルタリングするために含まれ得る。所望される場合、デブロッキングフィルタは典型的に、加算器６２の出力をフィルタリングするであろう。追加のフィルタ（インループまたはポストループ）もまた、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは簡潔さのために示されていないが、所望される場合、（インループフィルタとして）加算器５０の出力をフィルタリングし得る。

[0138]符号化プロセス中に、ビデオ符号化器２０は、コーディングされることになるビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックへと分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的予測を提供するために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対して、受信されたビデオブロックのインター予測符号化を実行する。イントラ予測処理ユニット４６は代替として、空間的予測を提供するために、コーディングされることになるブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックのピクセルを使用して、受信されたビデオブロックをイントラ予測し得る。ビデオ符号化器２０は、例えば、ビデオデータの各ブロックについて適切なコーディングモードを選択するために、複数のコーディングパスを遂行し得る。

[0139]その上、区分化ユニット４８は、以前のコーディングパスにおける以前の区分化スキームの評価に基づいて、ビデオデータのブロックをサブブロックへと区分化し得る。例えば、区分化ユニット４８は、レート−歪み分析（例えば、レート−歪み最適化）に基づいて、最初にフレームまたはスライスをＬＣＵへと区分化し、およびＬＣＵの各々をサブＣＵへと区分化し得る。モード選択ユニット４０はさらに、ＬＣＵのサブＣＵへの区分化を示す四分木データ構造を作り出し得る。四分木のリーフノードＣＵは、１つまたは複数のＰＵおよび１つまたは複数のＴＵを含み得る。

[0140]モード選択ユニット４０は、例えば、誤差結果に基づいて、予測モードのうちの１つ、イントラまたはインターを選択し得、および残差データを生成するための加算器５０に、および参照フレームとして使用するための符号化されたブロックを再構築するための加算器６２に、結果として生じる予測されたブロックを提供する。モード選択ユニット４０はまた、エントロピー符号化ユニット５６に、動きベクトル、イントラモードインジケータ、区分化情報、および他のそのようなシンタックス情報のようなシンタックス要素を提供する。

[0141]動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別個に例示されている。動き推定ユニット４２によって実行される動き推定は、動きベクトルを生成するプロセスであり、それは、ビデオブロックについての動きを推定する。動きベクトルは、例えば、現在のフレーム（または他のコーディングされたユニット）内でコーディングされている現在ブロックに対する参照フレーム（または他のコーディングされたユニット）内の予測ブロックに対する、現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、ピクセル差分の観点から、コーディングされることになるブロックに密接にマッチすることを見出されるブロックであり、それは、絶対差分の和（ＳＡＤ：sum of absolute difference）、２乗差分の和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得る。いくつかの例では、ビデオ符号化器２０は、参照ピクチャメモリ６４中に記憶された参照ピクチャのサブ整数ピクセル位置についての値を算出し得る。例えば、ビデオ符号化器２０は、参照ピクチャの４分の１ピクセル位置、８分の１ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、全ピクセル位置および分数ピクセル位置に対して動き探索を遂行し、および分数ピクセル精度で動きベクトルを出力し得る。

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

[0143]動き補償ユニット４４によって遂行される動き補償は、動き推定ユニット４２によって決定される動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴い得る。繰り返すが、いくつかの例では、動き推定ユニット４２および動き補償ユニット４４は機能的に統合され得る。現在のビデオブロックのＰＵについての動きベクトルを受信すると、動き補償ユニット４４は、参照ピクチャリストのうちの１つ中に、動きベクトルが指し示す予測ブロックをロケートし得る。加算器５０は、以下に論述されるように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット４２は、ルーマ成分に対して動き推定を実行し、および動き補償ユニット４４は、クロマ成分とルーマ成分との両方について、ルーマ成分に基づいて算出された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際に、ビデオ復号器３０によって使用するための、ビデオブロックおよびビデオスライスに関連付けられたシンタックス要素を生成し得る。

[0144]さらに、動き補償ユニット４４は、この開示の技法のうちの任意のものまたは全てを（単独または任意の組み合わせで）実行するように構成され得る。動き補償ユニット４４に関して論述されたが、モード選択ユニット４０、動き推定ユニット４２、区分化ユニット４８、および／またはエントロピー符号化ユニット５６もまた、単独または動き補償ユニット４４との組み合わせで、この開示のある特定の技法を遂行するように構成され得ることが理解されるべきである。一例では、動き補償ユニット４４は、ここに論述されたＢＩＯ技法を実行するように構成され得る。

[0145]イントラ予測処理ユニット４６は、上述されたように、動き推定ユニット４２および動き補償ユニット４４によって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測処理ユニット４６は、現在のブロックを符号化するために使用するためのイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット４６は、例えば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在のブロックを符号化し得、およびイントラ予測処理ユニット４６（または、いくつかの例ではモード選択ユニット４０）は、テストされたモードから使用するための適切なイントラ予測モードを選択し得る。

[0146]例えば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードについてのレート−歪み分析を使用してレート−歪み値を算出し、およびテストされたモードの中で最良のレート−歪み特性を有するイントラ予測モードを選択し得る。レート−歪み分析は概して、符号化されたブロックと、符号化されたブロックを作り出すために符号化された元の符号化されていないブロックとの間の歪み（または誤差）の量、ならびに符号化されたブロックを作り出すために使用されたビットレート（すなわち、ビットの数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックについての最良のレート−歪み値を示すかを決定するために、様々な符号化されたブロックについての歪みおよびレートからの比を算出し得る。

[0147]ブロックについてイントラ予測モードを選択した後に、イントラ予測処理ユニット４６は、エントロピー符号化ユニット５６にブロックについて選択されたイントラ予測モードを示す情報を提供し得る。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオ符号化器２０は、様々なブロックについての符号化コンテキストの定義、およびそれらコンテキストの各々に対して使用するための最確（most probable）イントラ予測モード、イントラ予測モードインデックス表、および修正されたイントラ予測モードインデックス表のインジケーションを、送信されるビットストリーム構成データ中に含め得、それは、複数のイントラ予測モードインデックス表および複数の修正されたイントラ予測モードインデックス表（コードワードマッピング表とも呼ばれる）を含み得る。

[0148]ビデオ符号化器２０は、コード化されている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数のコンポーネントを表す。変換処理ユニット５２は、残差ブロックに離散コサイン変換（ＤＣＴ）または概念的に同様の変換のような変換を適用し、変換係数値を備えるビデオブロックを作り出す。ウェーブレット変換、整数変換、サブバンド変換、離散サイン変換（ＤＳＴ）、または他のタイプの変換が、ＤＣＴの代わりに使用されることができる。いずれのケースでも、変換処理ユニット５２は、残差ブロックに変換を適用し、変換係数のブロックを作り出す。変換は、ピクセルドメインから周波数ドメインのような変換ドメインに残差情報をコンバートし得る。変換処理ユニット５２は、量子化ユニット５４に結果として生じる変換係数を送り得る。量子化ユニット５４は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数のうちのいくつかまたは全てに関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調節することによって修正され得る。

[0149]量子化に続いて、エントロピー符号化ユニット５６は、量子化された変換係数をエントロピーコーディングする。例えば、エントロピー符号化ユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ：context adaptive variable length coding）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ：context adaptive binary arithmetic coding）、シンタックスベースのコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分化エントロピー（ＰＩＰＥ：probability interval partitioning entropy）コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストベースのエントロピーコーディングのケースでは、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス（例えば、ビデオ復号器３０）に送信され得るか、または後の送信または取り出しのためにアーカイブされ得る。

[0150]逆量子化ユニット５８および逆変換処理ユニット６０は、ピクセルドメイン中の残差ブロックを再構築するために、それぞれ逆量子化および逆変換を適用する。特に、加算器６２は、参照ピクチャメモリ６４中での記憶のための再構築されたビデオブロックを作り出すために、動き補償ユニット４４またはイントラ予測処理ユニット４６によって先に作り出された動き補償予測ブロックに再構築された残差ブロックを追加する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために、参照ブロックとして動き推定ユニット４２および動き補償ユニット４４によって使用され得る。

[0151]図１５は、双方向オプティカルフローについての技法をインプリメントし得るビデオ復号器３０の例を例示するブロック図である。図１５の例では、ビデオ復号器３０は、エントロピー復号ユニット７０、動き補償ユニット７２、イントラ予測処理ユニット７４、逆量子化ユニット７６、逆変換処理ユニット７８、参照ピクチャメモリ８２および加算器８０を含む。ビデオ復号器３０は、いくつかの例では、ビデオ符号化器２０（図１４）に関して説明された符号化パスと概して相反する復号パスを遂行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成し得、その一方で、イントラ予測処理ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。

[0152]復号プロセス中に、ビデオ復号器３０は、ビデオ符号化器２０から符号化されたビデオスライスのビデオブロックと関連するシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオ復号器３０は、ビデオデータメモリ６８中に、受信された符号化されたビデオビットストリームを記憶する。ビデオデータメモリ６８は、ビデオ復号器３０のコンポーネントによって復号されることになる、符号化されたビデオビットストリームのようなビデオデータを記憶し得る。ビデオデータメモリ６８中に記憶されるビデオデータは、例えば、コンピュータ可読媒体１６を介して、記憶媒体から、またはカメラのようなローカルビデオソースから、あるいは物理的データ記憶媒体にアクセスすることによって、取得され得る。ビデオデータメモリ８５は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶するコーディングピクチャバッファ（ＣＰＢ：a coded picture buffer）を形成し得る。参照ピクチャメモリ８２は、例えば、イントラまたはインターコーディングモードで、ビデオ復号器３０によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ６８および参照ピクチャメモリ８２は、ＤＲＡＭ、ＳＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、または他のタイプのメモリデバイスのような多様なメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ６８および参照ピクチャメモリ８２は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ６８は、ビデオ復号器３０の他のコンポーネントとともにオンチップであり得るか、またはそれらのコンポーネントに対してオフチップであり得る。

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

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

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

[0156]動き補償ユニット７２はまた、サブピクセル精度のために補間フィルタに基づいて補間を遂行し得る。動き補償ユニット７２は、参照ブロックのサブ整数ピクセルについての補間された値を算出するために、ビデオブロックの符号化中にビデオ符号化器２０によって使用されるような補間フィルタを使用し得る。このケースでは、動き補償ユニット７２は、受信されたシンタックス要素からビデオ符号化器２０によって使用される補間フィルタを決定し、および予測ブロックを作り出すために補間フィルタを使用し得る。

[0157]さらに、動き補償ユニット７２は、（単独または任意の組み合わせで）この開示の技法のうちの任意のものまたは全てを実行するように構成され得る。例えば、動き補償ユニット７２は、ここに論述されたＢＩＯ技法を実行するように構成され得る。

[0158]逆量子化ユニット７６は、ビットストリーム中で提供され、且つエントロピー復号ユニット７０によって復号された量子化された変換係数を逆量子化（inverse quantizes）、すなわち、逆量子化（dequantizes）する。逆量子化プロセスは、量子化の程度、および同じように、適用されるべき逆量子化の程度を決定するために、ビデオスライス中の各ビデオブロックについてビデオ復号器３０によって算出される量子化パラメータＱＰ_Yの使用を含み得る。

[0159]逆変換処理ユニット７８は、ピクセルドメイン中に残差ブロックを作り出すために、変換係数に逆変換、例えば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを適用する。

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

[0161]図１６は、この開示の技法にしたがって、ビデオデータを復号するためのビデオ復号器の実例的な動作を例示するフローチャートである。図１６に関して説明されるビデオ復号器は、例えば、表示可能な復号されたビデオを出力するための、ビデオ復号器３０のようなビデオ復号器であり得るか、またはビデオ符号化器２０の復号ループのような、ビデオ符号化器にインプリメントされたビデオ復号器であり得、それは、逆量子化ユニット５８、逆変換処理ユニット６０、加算器６２、および参照ピクチャメモリ６４、ならびにモード選択ユニット４０の一部分を含む。

[0162]図１６の技法にしたがって、ビデオ復号器は、ビデオデータのブロックが双方向インター予測モードを使用して符号化されていると決定する（２００）。ビデオ復号器は、第１の参照ピクチャを指し示すブロックについての第１の動きベクトルを決定する（２０２）。ビデオ復号器は、第２の参照ピクチャを指し示すブロックについての第２のＭＶを決定し、ここで、第１の参照ピクチャは、第２の参照ピクチャとは異なる（２０４）。ビデオ復号器は、第１の参照ピクチャ中に第１の予測ブロックをロケートするために第１のＭＶを使用する（２０６）。ビデオ復号器は、第２の参照ピクチャ中に第２の予測ブロックをロケートするために第２のＭＶを使用する（２０８）。

[0163]ビデオ復号器は、第１の予測ブロックの第１のサブブロックについて、第１のＢＩＯ動き量を決定する（２１０）。第１のサブブロックは、ブロックについてのコーディングユニット、予測ユニット、および変換ユニットとは異なり得る。第１のＢＩＯ動き量を決定するために、ビデオ復号器は、いくつかの例では、第１のサブブロック中のサンプルおよび第１のサブブロック外のサンプルに基づいて第１のＢＩＯ動き量を決定し、および他の例では、第１のサブブロック中のサンプルのみに基づいて第１のＢＩＯ動き量を決定し得る。第１のＢＩＯ動き量は、例えば、水平成分および垂直成分を含む動きベクトルフィールドを含み得る。

[0164]ビデオ復号器は、第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第１の最終予測サブブロックを決定する（２１２）。第１の予測ブロックの第１のサブブロック、第２の予測ブロックの第１のサブブロック、および第１のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第１の最終予測サブブロックを決定するために、ビデオ復号器は、例えば、上記の式（２）を使用して第１の最終予測サブブロックを決定し得る。

[0165]ビデオ復号器は、第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定する（２１４）。第２のサブブロックは、ブロックについてのコーディングユニット、予測ユニット、および変換ユニットとは異なり得る。第２のＢＩＯ動き量を決定するために、ビデオ復号器は、いくつかの例では、第２のサブブロック中のサンプルおよび第２のサブブロック外のサンプルに基づいて第２のＢＩＯ動き量を決定し、および他の例では、第２のサブブロック中のサンプルのみに基づいて第２のＢＩＯ動き量を決定し得る。第２のＢＩＯ動き量は、例えば、水平成分および垂直成分を含む動きベクトルフィールドを含み得る。

[0166]ビデオ復号器は、第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第２の最終予測サブブロックを決定する（２１６）。第１の予測ブロックの第２のサブブロック、第２の予測ブロックの第２のサブブロック、および第２のＢＩＯ動き量に基づいて、ビデオデータのブロックについての第２の最終予測サブブロックを決定するために、ビデオ復号器は、例えば、式（２）を使用して、例えば、第２の最終予測サブブロックを決定し得る。

[0167]ビデオ復号器は、第１の最終予測サブブロックおよび第２の最終予測サブブロックに基づいて、ビデオデータのブロックについての最終予測ブロックを決定する（２１８）。ビデオ復号器は、例えば、ビデオデータのブロックについての再構築されたブロックを決定するために、最終予測ブロックに残差データを追加し得る。ビデオ復号器はまた、ビデオデータの再構築されたブロックに対して１つまたは複数のフィルタリングプロセスを実行し得る。

[0168]ビデオ復号器は、ビデオデータのブロックの復号されたバージョンを備えるビデオデータのピクチャを出力する（２２０）。復号がビデオ符号化プロセスの復号ループの一部として実行されると、ビデオ復号器は、例えば、参照ピクチャメモリ中にピクチャを記憶することによってピクチャを出力し得、およびビデオ復号器は、ビデオデータの別のピクチャを符号化する際に参照ピクチャとしてピクチャを使用し得る。ビデオ復号器が表示可能な復号されたビデオを出力するように構成されたビデオ復号器であるとき、そのビデオ復号器は、例えば、ディスプレイデバイスにビデオデータのピクチャを出力し得る。

[0169]例に依存して、ここに説明されたあらゆる技法のある特定の動作（acts）またはイベントは、異なるシーケンスで遂行されることができ、追加、統合、または完全に省略され得る（例えば、全ての説明された動作またはイベントが、それら技法の実施のために必要なわけではない）ことが認識されるべきである。その上、ある特定の例では、動作またはイベントは、順次にというよりはむしろ、例えば、マルチスレッド処理、割り込み処理、または複数のプロセッサを通じて、同時に遂行され得る。

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

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

[0172]命令は、１つまたは複数のＤＳＰ、汎用マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、あるいは他の同等な集積またはディスクリートロジック回路のような１つまたは複数のプロセッサによって実行され得る。それ故に、「プロセッサ」という用語は、ここに使用される場合、前述の構造またはここに説明された技法のインプリメンテーションに適したあらゆる他の構造のうちの任意のものを指し得る。加えて、いくつかの態様では、ここに説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内で提供され得るか、あるいは組み合わされたコーデック中に組み込まれ得る。また、それら技法は、１つまたは複数の回路またはロジック要素において十分にインプリメントされることができる。

[0173]この開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い多様なデバイスまたは装置においてインプリメントされ得る。様々なコンポーネント、モジュール、またはユニットは、開示された技法を遂行するように構成されたデバイスの機能的な態様を強調するためにこの開示中に説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上述されたように、様々なユニットは、コーデックハードウェアユニット中で組み合わされ得るか、あるいは、適したソフトウェアおよび／またはファームウェアと併せて、上述されたような１つまたは複数のプロセッサを含む、相互運用ハードウェアユニットの集合によって提供され得る。

[0174]様々な例が説明されてきた。これらおよび他の例は、次の特許請求の範囲内にある。

Claims (30)

1. ビデオデータを復号する方法であって、前記方法は、
   ビデオデータのブロックが双方向インター予測モードを使用して符号化されていると決定することと、
   前記ブロックについての第１の動きベクトル（ＭＶ）を決定することと、ここにおいて、前記第１のＭＶは、第１の参照ピクチャを指し示す、
   前記ブロックについての第２のＭＶを決定することと、ここにおいて、前記第２のＭＶは、第２の参照ピクチャを指し示し、前記第１の参照ピクチャは、前記第２の参照ピクチャとは異なる、
   前記第１のＭＶを使用して、前記第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、
   前記第２のＭＶを使用して、前記第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、
   前記第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、
   前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第１の最終予測サブブロックを決定することと、
   前記第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、
   前記第１の予測ブロックの前記第２のサブブロック、前記第２の予測ブロックの第２のサブブロック、および前記第２のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第２の最終予測サブブロックを決定することと、
   前記第１の最終予測サブブロックおよび前記第２の最終予測サブブロックに基づいて、ビデオデータの前記ブロックについての最終予測ブロックを決定することと、
   ビデオデータの前記ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、
   を備える、方法。
2. 前記第１のＢＩＯ動き量を決定することは、前記第１のサブブロック中のサンプルおよび前記第１のサブブロック外のサンプルに基づいて前記第１のＢＩＯ動き量を決定することを備える、請求項１に記載の方法。
3. 前記第１のＢＩＯ動き量を決定することは、前記第１のサブブロック中のサンプルのみに基づいて前記第１のＢＩＯ動き量を決定することを備える、請求項１に記載の方法。
4. 前記第２のＢＩＯ動き量を決定することは、前記第２のサブブロック中のサンプルおよび前記第２のサブブロック外のサンプルに基づいて前記第２のＢＩＯ動き量を決定することを備える、請求項１に記載の方法。
5. 前記第２のＢＩＯ動き量を決定することは、前記第２のサブブロック中のサンプルのみに基づいて前記第２のＢＩＯ動き量を決定することを備える、請求項１に記載の方法。
6. 前記第１のＢＩＯ動き量は、水平成分および垂直成分を備える動きベクトルフィールドを備える、請求項１に記載の方法。
7. 前記第１のサブブロックは、前記ブロックについてのコーディングユニット、予測ユニット、および変換ユニットとは異なる、請求項１に記載の方法。
8. ビデオデータの前記ブロックについての再構築されたブロックを決定するために、前記最終予測ブロックに残差データを追加すること、
   をさらに備える、請求項１に記載の方法。
9. 前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの前記第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての前記第１の最終予測サブブロックを決定することは、以下の式にしたがって前記第１の最終予測サブブロックを決定することを備え、
   ｐｒｅｄ_BIO＝１／２・（Ｉ⁽⁰⁾＋Ｉ⁽¹⁾＋ｖ_x・（τ₁∂Ｉ⁽¹⁾／∂ｘ−τ₀∂Ｉ⁽⁰⁾／∂ｘ）＋ｖ_y・（τ₁∂Ｉ⁽¹⁾／∂ｙ−τ₀∂Ｉ⁽⁰⁾／∂ｙ））
   ここにおいて、
   ｐｒｅｄ_BIOは、前記第１の最終予測サブブロックのサンプル値を備え、
   Ｉ⁽⁰⁾は、前記第１の予測ブロックの前記第１のサブブロックのサンプル値を備え、
   Ｉ⁽¹⁾は、前記第２の予測ブロックの前記第１のサブブロックのサンプル値を備え、
   ｖ_xは、前記第１のＢＩＯ動き量の水平成分を備え、
   ｖ_yは、前記第１のＢＩＯ動き量の垂直成分を備え、
   τ₀は、前記第１の参照ピクチャまでの距離を備え、
   τ₁は、前記第２の参照ピクチャまでの距離を備える、請求項１に記載の方法。
10. 前記復号の方法は、ビデオ符号化プロセスの復号ループの一部として実行され、およびビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力することは、参照ピクチャメモリ中にビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを記憶することを備え、前記方法は、
    前記ビデオデータの別のピクチャを符号化する際に参照ピクチャとしてビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを使用すること、
    をさらに備える、請求項１に記載の方法。
11. ビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力することは、ディスプレイデバイスにビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力することを備える、請求項１に記載の方法。
12. ビデオデータを復号するためのデバイスであって、前記デバイスは、
    ビデオデータを記憶するように構成されたメモリと、
    １つまたは複数のプロセッサと、を備え、前記１つまたは複数のプロセッサは、
    ビデオデータのブロックが双方向インター予測モードを使用して符号化されていると決定することと、
    前記ブロックについての第１の動きベクトル（ＭＶ）を決定することと、ここにおいて、前記第１のＭＶは、第１の参照ピクチャを指し示す、
    前記ブロックについての第２のＭＶを決定することと、ここにおいて、前記第２のＭＶは、第２の参照ピクチャを指し示し、前記第１の参照ピクチャは、前記第２の参照ピクチャとは異なる、
    前記第１のＭＶを使用して、前記第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、
    前記第２のＭＶを使用して、前記第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、
    前記第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、
    前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第１の最終予測サブブロックを決定することと、
    前記第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、
    前記第１の予測ブロックの前記第２のサブブロック、前記第２の予測ブロックの第２のサブブロック、および前記第２のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第２の最終予測サブブロックを決定することと、
    前記第１の最終予測サブブロックおよび前記第２の最終予測サブブロックに基づいて、ビデオデータの前記ブロックについての最終予測ブロックを決定することと、
    ビデオデータの前記ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、
    を行うように構成された、デバイス。
13. 前記第１のＢＩＯ動き量を決定するために、前記１つまたは複数のプロセッサは、前記第１のサブブロック中のサンプルおよび前記第１のサブブロック外のサンプルに基づいて前記第１のＢＩＯ動き量を決定するように構成される、請求項１２に記載のデバイス。
14. 前記第１のＢＩＯ動き量を決定するために、前記１つまたは複数のプロセッサは、前記第１のサブブロック中のサンプルのみに基づいて前記第１のＢＩＯ動き量を決定するように構成される、請求項１２に記載のデバイス。
15. 前記第２のＢＩＯ動き量を決定するために、前記１つまたは複数のプロセッサは、前記第２のサブブロック中のサンプルおよび前記第２のサブブロック外のサンプルに基づいて前記第２のＢＩＯ動き量を決定するように構成される、請求項１２に記載のデバイス。
16. 前記第２のＢＩＯ動き量を決定するために、前記１つまたは複数のプロセッサは、前記第２のサブブロック中のサンプルのみに基づいて前記第２のＢＩＯ動き量を決定するように構成される、請求項１２に記載のデバイス。
17. 前記第１のＢＩＯ動き量は、水平成分および垂直成分を備える動きベクトルフィールドを備える、請求項１２に記載のデバイス。
18. 前記第１のサブブロックは、前記ブロックについてのコーディングユニット、予測ユニット、および変換ユニットとは異なる、請求項１２に記載のデバイス。
19. 前記１つまたは複数のプロセッサは、
    ビデオデータの前記ブロックについての再構築されたブロックを決定するために、前記最終予測ブロックに残差データを追加すること、
    を行うように構成される、請求項１２に記載のデバイス。
20. 前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの前記第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての前記第１の最終予測サブブロックを決定するために、前記１つまたは複数のプロセッサは、以下の式にしたがって前記第１の最終予測サブブロックを決定するように構成され、
    ｐｒｅｄ_BIO＝１／２・（Ｉ⁽⁰⁾＋Ｉ⁽¹⁾＋ｖ_x・（τ₁∂Ｉ⁽¹⁾／∂ｘ−τ₀∂Ｉ⁽⁰⁾／∂ｘ）＋ｖ_y・（τ₁∂Ｉ⁽¹⁾／∂ｙ−τ₀∂Ｉ⁽⁰⁾／∂ｙ））
    ここにおいて、
    ｐｒｅｄ_BIOは、前記第１の最終予測サブブロックのサンプル値を備え、
    Ｉ⁽⁰⁾は、前記第１の予測ブロックの前記第１のサブブロックのサンプル値を備え、
    Ｉ⁽¹⁾は、前記第２の予測ブロックの前記第１のサブブロックのサンプル値を備え、
    ｖ_xは、前記第１のＢＩＯ動き量の水平成分を備え、
    ｖ_yは、前記第１のＢＩＯ動き量の垂直成分を備え、
    τ₀は、前記第１の参照ピクチャまでの距離を備え、
    τ₁は、前記第２の参照ピクチャまでの距離を備える、請求項１２に記載のデバイス。
21. 前記１つまたは複数のプロセッサは、ビデオ符号化プロセスの復号ループの一部として前記ビデオデータを復号し、およびビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力するために、前記１つまたは複数のプロセッサは、参照ピクチャメモリ中にビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを記憶するように構成され、前記１つまたは複数のプロセッサは、
    前記ビデオデータの別のピクチャを符号化する際に参照ピクチャとしてビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを使用すること、
    を行うようにさらに構成される、請求項１２に記載のデバイス。
22. ビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力するために、前記１つまたは複数のプロセッサは、ディスプレイデバイスにビデオデータの前記ブロックの前記復号されたバージョンを備えるビデオデータの前記ピクチャを出力するように構成される、請求項１２に記載のデバイス。
23. 前記デバイスは、ワイヤレス通信デバイスを備え、符号化されたビデオデータを受信するように構成された受信機をさらに備える、請求項１２に記載のデバイス。
24. 前記ワイヤレス通信デバイスは、電話ハンドセットを備え、
    前記受信機は、前記符号化されたビデオデータを備える信号を、ワイヤレス通信規格にしたがって復調するように構成される、請求項２３に記載のデバイス。
25. 前記デバイスは、ワイヤレス通信デバイスを備え、符号化されたビデオデータを送信するように構成された送信機をさらに備える、請求項１２に記載のデバイス。
26. 前記ワイヤレス通信デバイスは、電話ハンドセットを備え、
    前記送信機は、前記符号化されたビデオデータを備える信号を、ワイヤレス通信規格にしたがって変調するように構成される、請求項２５に記載のデバイス。
27. １つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、
    ビデオデータのブロックが双方向インター予測モードを使用して符号化されていると決定することと、
    前記ブロックについての第１の動きベクトル（ＭＶ）を決定することと、ここにおいて、前記第１のＭＶは、第１の参照ピクチャを指し示す、
    前記ブロックについての第２のＭＶを決定することと、ここにおいて、前記第２のＭＶは、第２の参照ピクチャを指し示し、前記第１の参照ピクチャは、前記第２の参照ピクチャとは異なる、
    前記第１のＭＶを使用して、前記第１の参照ピクチャ中に第１の予測ブロックをロケートすることと、
    前記第２のＭＶを使用して、前記第２の参照ピクチャ中に第２の予測ブロックをロケートすることと、
    前記第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定することと、
    前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第１の最終予測サブブロックを決定することと、
    前記第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定することと、
    前記第１の予測ブロックの前記第２のサブブロック、前記第２の予測ブロックの第２のサブブロック、および前記第２のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第２の最終予測サブブロックを決定することと、
    前記第１の最終予測サブブロックおよび前記第２の最終予測サブブロックに基づいて、ビデオデータの前記ブロックについての最終予測ブロックを決定することと、
    ビデオデータの前記ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力することと、
    を行わせる命令を記憶する、コンピュータ可読記憶媒体。
28. 前記第１のＢＩＯ動き量は、水平成分および垂直成分を備える動きベクトルフィールドを備える、請求項２７に記載のコンピュータ可読記憶媒体。
29. 前記第１のサブブロックは、前記ブロックについてのコーディングユニット、予測ユニット、および変換ユニットとは異なる、請求項２７に記載のコンピュータ可読記憶媒体。
30. ビデオデータを復号するための装置であって、前記装置は、
    ビデオデータのブロックが双方向インター予測モードを使用して符号化されていると決定するための手段と、
    前記ブロックについての第１の動きベクトル（ＭＶ）を決定するための手段と、ここにおいて、前記第１のＭＶは、第１の参照ピクチャを指し示す、
    前記ブロックについての第２のＭＶを決定するための手段と、ここにおいて、前記第２のＭＶは、第２の参照ピクチャを指し示し、前記第１の参照ピクチャは、前記第２の参照ピクチャとは異なる、
    前記第１のＭＶを使用して、前記第１の参照ピクチャ中の第１の予測ブロックをロケートするための手段と、
    前記第２のＭＶを使用して、前記第２の参照ピクチャ中の第２の予測ブロックをロケートするための手段と、
    前記第１の予測ブロックの第１のサブブロックについて、第１の双方向オプティカルフロー（ＢＩＯ）動き量を決定するための手段と、
    前記第１の予測ブロックの前記第１のサブブロック、前記第２の予測ブロックの第１のサブブロック、および前記第１のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第１の最終予測サブブロックを決定するための手段と、
    前記第１の予測ブロックの第２のサブブロックについて、第２のＢＩＯ動き量を決定するための手段と、
    前記第１の予測ブロックの前記第２のサブブロック、前記第２の予測ブロックの第２のサブブロック、および前記第２のＢＩＯ動き量に基づいて、ビデオデータの前記ブロックについての第２の最終予測サブブロックを決定するための手段と、
    前記第１の最終予測サブブロックおよび前記第２の最終予測サブブロックに基づいて、ビデオデータの前記ブロックについての最終予測ブロックを決定するための手段と、
    ビデオデータの前記ブロックの復号されたバージョンを備えるビデオデータのピクチャを出力するための手段と、
    を備える、装置。

Images