JP2019526988A

JP2019526988A - 候補リストの構築のためのジオメトリベースの優先度

Info

Publication number: JP2019526988A
Application number: JP2019512667A
Authority: JP
Inventors: チェン、イ−ウェン; チェン、ウェイ−ジュン; ジャン、リ; ジャン、カイ; カルチェビチ、マルタ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2016-09-06
Filing date: 2017-09-06
Publication date: 2019-09-19
Also published as: BR112019003836A2; CN109644272A; US10721489B2; WO2018048904A1; CN109644272B; KR20190041480A; US20180070100A1; EP3510774A1

Abstract

一例では、デバイスは、ビデオデータを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、該１つまたは複数のプロセッサは、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに隣接するブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接するブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングすることと、を行うように構成される。候補リストは、たとえば、マージリスト、ＡＭＶＰリスト、またはＭＰＭリストであり得る。代わりとして、候補リストは、ＣＡＢＡＣ（context adaptive binary arithmetic coding）についてのコンテキスト情報を決定するための候補のリストであり得る。【選択図】図１８

Description

優先権の主張

本出願は、２０１６年９月６日付で出願された米国仮出願第６２／３８４，０８９号の利益を主張し、その内容全体が参照により本明細書に組み込まれる。

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

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

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

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

[0006] 一般に、本開示は、候補リストの構築に関する技法を説明する。候補リストは、イントラ予測モードのシグナリング、（たとえば、マージモードまたはＡＭＶＰ（advanced motion vector prediction）モードでの）動き情報コーディング、または他のそのようなビデオコーディング技法といった様々なビデオコーディング技法のために構築され得る。本開示は、候補リストの構築のためのジオメトリベースの優先度について説明する。いくつかの態様では、ジオメトリ情報、たとえば現在ブロックと隣接ブロックとの間の距離が、候補リストの構築のための候補の優先度または挿入順序を決定するために使用され得る。

[0007] 一例では、ビデオデータをコーディングする方法は、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに隣接する隣接ブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングすることと、を含む。

[0008] 別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、該１つまたは複数のプロセッサは、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに隣接する隣接ブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つ又は複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングすることと、を行うように構成される。

[0009] 別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに隣接する隣接ブロックの複数の第２の代表点との間の複数の距離を決定するための手段と、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えるための手段と、候補リストを使用して現在ブロックをコーディングするための手段と、を含む。

[0010] 別の例では、実行されたときに、プロセッサに、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに隣接する隣接ブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングすることと、を行わせる命令を記憶したコンピュータ可読記憶媒体。

[0011] １つまたは複数の例の詳細が、添付の図面および以下の説明において述べられる。他の特徴、目的、および利点は、説明および図面から、ならびに請求項から明らかになるだろう。

高効率ビデオコーディング（ＨＥＶＣ）における空間的隣接候補を例示する概念図である。ＨＥＶＣにおける時間動きベクトル予測（ＴＭＶＰ）を例示する概念図である。３Ｄ−ＨＥＶＣについての例となる予測構造を例示する概念図である。３Ｄ−ＨＥＶＣにおけるサブＰＵベースのビュー間動き予測を例示する概念図である。参照ピクチャからのサブＰＵ動き予測を例示する概念図である。（ＴＭＶＰに類似する）ＡＴＭＶＰにおける関連するピクチャを例示する概念図である。本開示の技法にしたがった例となる方法を示すフローチャートである。ＰＵおよび隣接ブロックの一例を示す概念図である。ＰＵおよび隣接ブロックの別の例を示す概念図である。ＰＵおよび隣接ブロックの別の例を示す概念図である。ＰＵおよび隣接ブロックの別の例を示す概念図である。本開示の技法にしたがった空間的マージ候補のジオメトリ情報の例を例示する概念図である。本開示の技法にしたがった空間的マージ候補のジオメトリ情報の例を例示する概念図である。本開示の技法を実行するように構成され得る例となるビデオ符号化および復号システムを例示するブロック図である。本開示の技法を実行するように構成され得るビデオエンコーダの例を例示するブロック図である。本開示の技法を実行するように構成され得るビデオデコーダの例を例示するブロック図である。本開示の技法にしたがった、ビデオデータを符号化する例となる方法を例示するフローチャートである。本開示の技法したがった、ビデオデータを復号する例となる方法を例示するフローチャートである。

[0030] 本開示は、マージ候補リスト、ＡＭＶＰリスト、およびイントラＭＰＭリストといった候補リストの構築のための優先度または挿入順序を決定するために、現在ブロックと隣接ブロックとの間のジオメトリ情報に基づいて優先度を導入することによって、ビデオコーデックにおける候補リストの構築およびコンテキストモデル化を改善するように使用され得る技法を説明する。さらに、このジオメトリ情報は、ＣＡＢＡＣコーディングのためのコンテキストの決定に使用され得る。複数の候補（たとえば、マージ候補、最も可能性のある（most probable）イントラモード候補）の順序は、ジオメトリ優先度によって適応する形で（adaptively）決定され得る。それは、ＨＥＶＣの拡張版またはビデオコーディング規格の次世代版といったアドバンスドビデオコーデックのコンテキストで使用され得る。

[0031] ビデオコーディング規格は、ＩＴＵ−ＴＨ．２６１、ＩＳＯ／ＩＥＣＭＰＥＧ−１ビジュアル、ＩＴＵ−ＴＨ．２６２またはＩＳＯ／ＩＥＣＭＰＥＧ−２ビジュアル、ＩＴＵ−ＴＨ．２６３、ＩＳＯ／ＩＥＣＭＰＥＧ−４ビジュアル、およびＩＴＵ−ＴＨ．２６４（ＩＳＯ／ＩＥＣＭＰＥＧ−４ＡＶＣとしても知られている）を含み、そのＳＶＣ（Scalable Video Coding）およびＭＶＣ（MultiView Video Coding）拡張版も含む。ＭＶＣの最新の共同ドラフトは、２０１０年３月付のＩＴＵ−Ｔ勧告Ｈ．２６４「Advanced video coding for generic audiovisual services」で説明されている。

[0032] 加えて、新たに開発されたビデオコーディング規格、即ち、ＩＴＵ−ＴのＪＣＴ−ＶＣ（Joint Collaboration Team on Video Coding）、ＶＣＥＧ（Video Coding Experts Group）、およびＩＳＯ／ＩＥＣＭＰＥＧ（Motion Picture Experts Group）によって開発された高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）が存在する。最新のＨＥＶＣドラフト仕様は、以下ではＨＥＶＣＷＤと称されており、phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1から入手可能である。ＨＥＶＣ規格は、IEEE Transactions on Circuits and Systems for Video Technology（ＩＥＥＥ）２２巻１２号のG.J.Sullivan、J.-R.Ohm、W.-J.Han、T.Wiegand（２０１２年１２月付）による「Overview of the High Efficiency Video Coding (HEVC) Standard」（ＰＤＦ）で完結されている（has been finalized）。

[0033] ＩＴＵ−ＴＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）は、現在のＨＥＶＣ規格（スクリーンコンテンツコーディングおよび高ダイナミックレンジコーディングについてのその現在の拡張版および近い未来の拡張版を含む）の圧縮能力を著しく上回る圧縮能力をもつ将来的なビデオコーディング技術の標準化を求める潜在的なニーズを今研究している。該団体は、この領域のエキスパートによって提案された圧縮技術設計を評価するために、ＪＶＥＴ（Joint Video Exploration Team）として知られている共同の試みでこの調査活動に関して協力し合っている。ＪＶＥＴが最初に集ったのは２０１５年１０月１９日〜２１日の間である。そして、参照ソフトウェアの最新バージョン、即ちＪＥＭ３（Joint Exploration Model 3）は、jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16. 6-JEM-3.0/からダウンロードされ得るだろう。ＪＥＭ３についてのアルゴリズムの説明は、ＪＶＥＴ−Ｃ１００１のJ.Chen,E.Alshina,G.J.Sullivan,J.-R.Ohm,J.Boyce（サンディエゴ、２０１６年３月）による「Algorithm description of Joint Exploration Test Model 3」で説明されている。

[0034] 各ブロックについて、１セットの動き情報が利用可能であり得る。１セットの動き情報は、前方予測方向および後方予測方向についての動き情報を保有する。ここで、前方予測方向および後方予測方向は、現在のピクチャまたはスライスの参照ピクチャリスト０（RefPicList0）および参照ピクチャリスト１（RefPicList1）に対応する２つの予測方向である。「前方」および「後方」という用語は、必ずしもジオメトリな意味を有するわけではない。代わりに、どの参照ピクチャリストに動きベクトルが基づくかを区別するために、それらは使用される。前方予測は、参照リスト０に基づいて形成された予測を意味し、それに対して後方予測は、参照リスト１に基づいて形成された予測を意味する。参照リスト０と参照リスト１との両方が所与のブロックについて予測を形成するために使用されるケースでは、それは双方向予測と呼ばれる。

[0035] 所与のピクチャまたはスライスについて、１つの参照ピクチャリストのみが使用される場合、ピクチャまたはスライス内部の全てのブロックが前方予測される。所与のピクチャまたはスライスについて両方の参照ピクチャリストが使用される場合、ピクチャまたはスライス内部のブロックは前方予測され得るか、または後方予測され得るか、または双方向予測され得る。

[0036] 各予測方向について、動き情報は、参照インデックスおよび動きベクトルを保有する。参照インデックスは、対応する参照ピクチャリスト（たとえば、RefPicList０またはRefPicList1）中の参照ピクチャを識別するために使用される。動きベクトルは水平成分と垂直成分との両方を有し、その各々が水平方向および垂直方向それぞれに沿ったオフセット値を示す。いくつかの説明では、簡潔さのために、「動きベクトル」という言葉が、動きベクトルとそれに関連する参照インデックスとの両方を示すために、動き情報と交換可能に使用され得る。

[0037] ピクチャ順序カウント（ＰＯＣ：picture order count）が、ピクチャの表示順序を識別するためにビデオコーディング規格で広く使用されている。１つのコーディングされたビデオシーケンス内の２つのピクチャが同じＰＯＣ値を有し得るケースが存在するけれども、それは通常、１つのコーディングビデオシーケンス内では起こらない。複数のコーディングされたビデオシーケンスが１つのビットストリームに存在するとき、ＰＯＣの同じ値をもつピクチャは、復号順序の観点から互いにより近くにあり得る。

[0038] ピクチャのＰＯＣ値は通常、参照ピクチャリスト構築、ＨＥＶＣにあるような参照ピクチャセットの導出、および動きベクトルスケーリングに使用される。

[0039] IEEE Transactions on Circuits and Systems for Video Technology１３巻７号のWiegand,Thomas、Sullivan,Gary J、Bjontegaard,Gisle、Luthra,Ajay（２００３年７月付）による「Overview of the H.264/AVC Video Coding Standard」（ＰＤＦ）のＨ．２６４／ＡＶＣ（アドバンスドビデオコーディング）では、各インターマクロブロックは、４つの異なる方法に分割され得る：
・１つの１６ｘ１６ＭＢ区分
・２つの１６ｘ８ＭＢ区分
・２つの８ｘ１６ＭＢ区分
・４つの８ｘ８ＭＢ区分
[0040] １つのＭＢ中の異なるＭＢ区分が、方向（RefPicList0またはRefPicList1）毎に異なる参照インデックス値を有し得る。１つのＭＢが４つの８ｘ８ＭＢ区分に分割されないとき、それは各方向においてＭＢ区分毎に１つの動きベクトルのみを有する。１つのＭＢが４つの８ｘ８ＭＢ区分に分割されるとき、各８ｘ８ＭＢ区分はサブブロックにさらに分割され得、該サブブロックの各々が各方向に異なる動きベクトルを有し得る。８ｘ８ＭＢ区分からサブブロックを得るためには４つの異なる方法が存在する：
・１つの８ｘ８サブブロック
・２つの８ｘ４サブブロック
・２つの４ｘ８サブブロック
・４つの４ｘ４サブブロック
[0041] 各サブブロックは、各方向に異なる動きベクトルを有し得る。したがって、動きベクトルは、サブブロックと等しいかまたはより高いレベルに存在する。

[0042] ＡＶＣでは、時間ダイレクトモードが、ＢスライスにおけるスキップまたはダイレクトモードのためにＭＢレベルまたはＭＢ区分レベルのどちらかにおいてイネーブルにされ得る。各ＭＢ区分について、現在ブロックのRefPicList1[0]中の現在のＭＢ区分とコロケートされたブロックの動きベクトルが、動きベクトルを導出するために使用される。コロケートされたブロックにおける各動きベクトルは、ＰＯＣの距離に基づいてスケーリングされる。

[0043] ＡＶＣでは、空間ダイレクトモードもまた、空間的隣接から動き情報を予測するために使用され得る。

[0044] ＨＥＶＣでは、スライス中の最大符号化ユニットは、符号化ツリーブロック（ＣＴＢ）または符号化ツリーユニット（ＣＴＵ）と呼ばれる。ＣＴＢは四分木を保有し、そのノードは符号化ユニット（ＣＵ）である。

[0045] ＣＴＢのサイズは、（厳密には、８ｘ８ＣＴＢサイズはサポートされ得るが）ＨＥＶＣメインプロファイルでは１６ｘ１６〜６４ｘ６４の範囲に及び得る。符号化ユニット（ＣＵ）は、ＣＴＢの同じサイズであり得るが、８ｘ８程に小さくあり得るだろう。各符号化ユニットは１つのモードを用いてコーディングされる。ＣＵがインターコーディングされるとき、それは２つまたは４つの予測ユニット（ＰＵ）にさらに分割され得るか、またはさらなる分割が適用されないときはたった１つのＰＵになり得る。１つのＣＵに２つのＰＵが存在するとき、それらは、ハーフサイズの矩形であり得るか、またはＣＵの１／４サイズまたは３／４サイズの２つの矩形サイズであり得る。

[0046] ＣＵがインターコーディングされるとき、１セットの動き情報が各ＰＵに存在する。加えて、各ＰＵは、該１セットの動き情報を導出するために、一意のインター予測モードを用いてコーディングされる。

[0047] ＨＥＶＣ規格では、１つの予測ユニット（ＰＵ）に対してそれぞれ、マージモード（スキップはマージの特別なケースと見なされる）および高度動きベクトル予測（ＡＭＶＰ）モードと名付けられた、２つのインター予測モードが存在する。

[0048] ＡＭＶＰモードまたはマージモードのどちらでも、動きベクトル（ＭＶ）候補リストが、複数の動きベクトル予測子のために維持される。現在のＰＵの（１つまたは複数の）動きベクトル、およびマージモードでの参照インデックスが、ＭＶ候補リストから１つの候補を取ることによって生成される。

[0049] ＭＶ候補リストは、マージモードについては最大５つの候補を、およびＡＭＶＰモードについては２つの候補のみを保有する。マージ候補は、動き情報のセット、たとえば両方の参照ピクチャリスト（リスト０およびリスト１）に対応する動きベクトル、ならびに参照インデックスを保有し得る。マージ候補がマージインデックスによって識別される場合、参照ピクチャが現在ブロックの予測に使用され、同様に、関連する動きベクトルが決定される。しかしながら、リスト０またはリスト１のどちらかからの各潜在的な予測方向についてのＡＭＶＰモード下では、ＡＭＶＰ候補が１つの動きベクトルのみを保有するので、ＭＶ候補リストへの１つのＭＶＰインデックスと共に、１つの参照インデックスが明示的にシグナリングされる必要がある。ＡＭＶＰモードでは、予測された動きベクトルが、さらに補正され得る。

[0050] 上記から分かるように、マージ候補が動き情報の完全なセットに対応するのに対し、ＡＭＶＰ候補は、特定の予測方向についてのたった１つの動きベクトルおよび１つの参照インデックスを保有する。つまり一般に、動き情報は、動きベクトル予測子、参照ピクチャリスト、参照ピクチャリスト中へのインデックス、およびＡＭＶＰのケースでは動きベクトル予測子に適用されるべき差分を含む。ＨＥＶＣにしたがうと、マージモードでは、動きベクトル、参照ピクチャリスト、およびインデックスが選択された候補から引き継がれるのに対し、ＡＭＶＰでは、動きベクトル予測子が選択された候補の動きベクトルに対応し、参照ピクチャリスト、インデックス、および動きベクトル差分値がシグナリングされる。

[0051] 両方のモードについての候補が、同じ空間的および時間的隣接ブロックから同様に導出される。

[0052] 図１は、ＨＥＶＣにおける空間的隣接候補を例示する概念図である。空間ＭＶ候補は、特定のＰＵ（ＰＵ₀）について、図１で示されている隣接ブロックから導出されるが、ブロックから候補を生成する方法は、マージモードとＡＭＶＰモードとでは異なる。

[0053] マージモードでは、最大４つの空間ＭＶ候補が、番号付きで図１（ａ）に示されている順序で導出され得、順序は、図１（ａ）で示されているように、以下：左（０、Ａ１）、上（１、Ｂ１）、右上（２、Ｂ０）、左下（３、Ａ０）、および左上（４、Ｂ２）である。

[0054] マージモードでは、最大４つの空間ＭＶ候補が、番号付きで図１（ａ）で示されている順序で導出され得、順序は、図１（ａ）で示されているように、以下：左（０、Ａ１）、上（１、Ｂ１）、右上（２、Ｂ０）、左下（３、Ａ０）、および左上（４、Ｂ２）である。つまり図４（ａ）では、ブロック１００は、ＰＵ０１０４ＡおよびＰＵ１１０４Ｂを含む。ビデオコーダ（たとえば、ビデオエンコーダまたはビデオデコーダ）が、マージモードを使用してＰＵ０１０４Ａについての動き情報をコーディング（符号化または復号）することになるとき、ビデオコーダは、空間的隣接ブロック１０８Ａ、１０８Ｂ、１０８Ｃ、１０８Ｄ、および１０８Ｅからの動き情報を、その順序で候補リストに加える。ブロック１０８Ａ、１０８Ｂ、１０８Ｃ、１０８Ｄ、および１０８Ｅはまた、ＨＥＶＣにおけるように、ブロックＡ１、Ｂ１、Ｂ０、Ａ０、およびＢ２ともそれぞれ称され得る。

[0055] ＡＶＭＰモードでは、隣接ブロックは、図１（ｂ）に示されているように、２つのグループ：ブロック０および１を含む左グループ、ならびにブロック２、３、および４を含む上グループに分割される。これらのブロックは、図１（ｂ）において、ブロック１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ、および１１０Ｅとそれぞれラベル付けされる。特に図１（ｂ）では、ブロック１０２は、ＰＵ０１０６ＡおよびＰＵ１１０６Ｂを含み、ブロック１１０Ａ、１１０Ｂ、１１０Ｃ、１１０Ｄ、および１１０Ｅは、ＰＵ０１０６Ａに対する空間的隣接を表す。各グループについて、シグナリングされた参照インデックスによって示されたものと同じ参照ピクチャを指す隣接ブロックにおける潜在的な候補が、グループの最終的な候補を形成するために選ばれるための最高の優先度を有する。全ての隣接ブロックが同じ参照ピクチャを指す動きベクトルを保有しないこともあり得る。したがって、そのような候補が発見できない場合、最初に利用可能な候補が最終的な候補を形成するためにスケーリングされることになり、したがって、時間的な距離差分が補償され得る。

[0056] 図２は、ＨＥＶＣにおける時間動きベクトル予測を例示する概念図である。特に図２（ａ）は、ＰＵ０１２２ＡおよびＰＵ１１２２Ｂを含む例となるＣＵ１２０を例示している。ＰＵ０１２２Ａは、ＰＵ１２２Ａについての中央ブロック１２６およびＰＵ０１２２Ａに対する右下ブロック１２４を含む。図２（ａ）はまた、外部ブロック１２８を示し、それについての動き情報が、以下で説明されるように、ＰＵ０１２２Ａの動き情報から予測され得る。図２（ｂ）は、現在ブロック１３８を含む現在のピクチャ１３０を例示しており、現在ブロック１３８についての動き情報が予測されることになる。特に図２（ｂ）は、現在のピクチャ１３０に対するコロケートされたピクチャ１３４（現在ブロック１３８に対するコロケートされたブロック１４０を含む）、現在の参照ピクチャ１３２、およびコロケートされた参照ピクチャ１３６を例示している。コロケートされたブロック１４０は、動きベクトル１４４を使用して予測され、該動きベクトル１４４は、ブロック１３８の動き情報についての時間動きベクトル予測子（ＴＭＶＰ）１４２として使用される。

[0057] ＴＭＶＰが有効にされ、ＴＭＶＰ候補が利用可能である場合、ビデオコーダは、任意の空間動きベクトル候補の後に、ＴＭＶＰ候補（たとえば、ＴＭＶＰ候補１４２）をＭＶ候補リスト中に加え得る。ＴＭＶＰ候補についての動きベクトル導出のプロセスは、マージモードとＡＭＶＰモードとの両方について同じである。しかしながら、マージモードにおけるＴＭＶＰ候補についてのターゲット参照インデックスは、ＨＥＶＣにしたがうと、０に設定される。

[0058] ＴＭＶＰ候補導出のためのプライマリブロック位置は、空間的隣接候補を生成するために使用される上ブロックおよび左ブロックに対するバイアスを補償するために、図２（ａ）でＰＵ０１２２Ａに対するブロック１２４として示されているようなコロケートされたＰＵ外部の右下ブロックである。しかしながら、ブロック１２４が現在のＣＴＢの行の外部に位置するか、または動き情報がブロック１２４について利用可能でない場合、該ブロックは、図２（ａ）で示されているようなＰＵの中央ブロック１２６と置き換えられる。

[0059] ＴＭＶＰ候補１４２についての動きベクトルは、スライスレベル情報で示されるような、コロケートされたピクチャ１３４のコロケートされたブロック１４０から導出される。コロケートされたＰＵについての動きベクトルは、コロケートされたＭＶと呼ばれる。

[0060] ＡＶＣにおける時間ダイレクトモードと同様に、ＴＭＶＰ候補の動きベクトルは動きベクトルスケーリングされやすく、動きベクトルスケーリングは、現在のピクチャ１３０と現在の参照ピクチャ１３２との間、およびコロケートされたピクチャ１３４と、コロケートされた参照ピクチャ１３６との間のピクチャ順序カウント（ＰＯＣ）距離の差分および／または時間距離距離（temporal distance distances）を補償するために実行される。つまり動きベクトル１４４は、これらのＰＯＣ／時間距離差分に基づいて、ＴＭＶＰ候補１４２を作り出すためにスケーリングされ得る。

[0061] マージモードおよびＡＭＶＰモードのいくつかの態様は、以下の通り、言及するに値する。

[0062] 動きベクトルスケーリング：動きベクトルの値が、提示時間（presentation time）におけるピクチャの距離に比例することが前提とされる。動きベクトルが２つのピクチャ、即ち参照ピクチャおよび動きベクトルを保有するピクチャ（即ち保有ピクチャ（the containing picture））を関連付ける。動きベクトルが他の動きベクトルを予測するために利用されるとき、保有ピクチャと参照ピクチャとの距離が、ピクチャ順序カウント（ＰＯＣ）値に基づいて計算される。

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

[0064] 疑似（artificial）動きベクトル候補生成：動きベクトル候補リストが完成していない場合、リストが全ての候補を有するまで、疑似動きベクトル候補が生成され、リストの末尾に挿入される。

[0065] マージモードでは、２つのタイプの疑似ＭＶ候補：Ｂスライスのためだけに導出された結合候補（combined candidate）と、１つ目のタイプが十分な疑似候補を提供しない場合にＡＭＶＰにのみ使用されるゼロ候補とが存在する。

[0066] 候補リスト中に既に存在し、必要な動き情報を有する候補の各ペアでは、双方向結合動きベクトル候補が、リスト０中の１つのピクチャを指す第１の候補の動きベクトルと、リスト１中の１つのピクチャを指す第２の候補の動きベクトルとの結合によって導出される。

[0067] 候補挿入のためのプルーニング（pruning）プロセス：異なるブロックからの候補が偶然同じであり得、このことは、マージ／ＡＭＶＰ候補リストの効率を下げる。プルーニングプロセスが、この問題を解決するために適用される。それは、ある特定の範囲で同一の候補を挿入するのを避けるために、現在の候補リスト中で１つの候補を他の候補に対して比較する。複雑性を低減するために、各潜在的な候補を全ての他の既存の候補と比較するのではなく、限られた数のプルーニングプロセスのみが適用される。

[0068] 図３は、３Ｄ−ＨＥＶＣについての例となる予測構造を例示する。３Ｄ−ＨＥＶＣは、ＪＣＴ−３Ｖによって開発中のＨＥＶＣの３Ｄビデオ拡張である。３Ｄ−ＨＥＶＣは、ＪＣＴ−３ＶのGerhard Tech、Krzysztof Wegner、Ying Chen、Sehoon Yea（２０１５年２月１８日付）による「3D-HEVC Draft Text 7」で説明されている。本開示の技法に関連するある特定の技法が、以下の図３および図４に関係して説明される。

[0069] 図３は、３つのビューのケースについてのマルチビュー予測構造を示す。Ｖ３はベースビューを表し、非ベースビュー（Ｖ１またはＶ５）中のピクチャは、同じ時間インスタンスの依存（ベース）ビュー中のピクチャから予測され得る。

[0070] （再構築されたサンプルからの）ビュー間サンプル予測がＭＶ−ＨＥＶＣにおいてサポートされ、その典型的な予測構造が図３で示されていることは言及に値する。

[0071] ＭＶ−ＨＥＶＣと３Ｄ−ＨＥＶＣとの両方が、ベース（テクスチャ）ビューがＨＥＶＣ（バージョン１）デコーダによって復号可能である点で、ＨＥＶＣと互換性がある。

[0072] ＭＶ−ＨＥＶＣでは、非ベースビュー中の現在のピクチャは、同じビュー中のピクチャと、同じ時間インスタンスの参照ビュー中のピクチャとの両方によって、これらのピクチャの全てを該ピクチャの参照ピクチャリストに入れることで予測され得る。したがって、現在のピクチャの参照ピクチャリストは、時間参照ピクチャ（temporal reference picture）とビュー間参照ピクチャ（inter-virw reference picture）との両方を保有する。

[0073] 時間参照ピクチャに対応する参照インデックスに関連付けられた動きベクトルは、時間動きベクトル（temporal motion vector）として表される。

[0074] ビュー間参照ピクチャに対応する参照インデックスに関連付けられた動きベクトルは、視差動きベクトルとして表される。

[0075] ３Ｄ−ＨＥＶＣは、ＭＶ−ＨＥＶＣにおける全ての特徴をサポートする。したがって、上で言及されたようなビュー間サンプル予測がイネーブルにされる。

[0076] 加えて、より高度なテキスチャオンリコーディングツールおよび深度関連／依存コーディングツールがサポートされる。

[0077] テキスチャオンリコーディングツールはしばしば、同じオブジェクトに属し得る（ビュー間で）対応するブロックの識別を必要とする。したがって、視差ベクトル導出は、３Ｄ−ＨＥＶＣにおけるベース技術である。

[0078] （再構築されたサンプルからの）ビュー間サンプル予測はＭＶ−ＨＥＶＣにおいてサポートされ、その典型的な予測構造は図５で示される。

[0079] 図４は、３Ｄ−ＨＥＶＣにおけるサブＰＵベースのビュー間動き予測を例示する概念図である。図４は、現在のビュー（Ｖ１）の現在のピクチャ１６０および参照ビュー（Ｖ０）でのコロケートされたピクチャ１６２を示す。現在のピクチャ１６０は、４つのサブＰｕｓ１６６Ａ〜１６６Ｄ（サブＰＵ１６６）を含む現在のＰＵ１６４を含む。それぞれの視差ベクトル１７４Ａ〜１７４Ｄ（視差ベクトル１７４）は、コロケートされたピクチャ１６２中のサブＰＵ１６６に対応するサブＰＵ１６８Ａ〜１６８Ｄを識別する。３Ｄ−ＨＥＶＣにおける、ビュー間マージ候補、即ち参照ビュー中の参照ブロックから導出された候補についてのサブＰＵレベルのビュー間動き予測方法。

[0080] そのようなモードがイネーブルにされたとき、現在のＰＵ１６４は、参照ビューでの参照エリア（現在のＰＵと同じサイズが視差ベクトルによって識別される）に対応し得、該参照エリアは、通常ＰＵについての１セットの動き情報を生成するのに必要とされるよりも豊富な動き情報を有し得る。したがって、図４で示されるように、サブＰＵレベルのビュー間動き予測（ＳＰＩＶＭＰ）方法が使用され得る。

[0081] このモードはまた、特別なマージ候補としてもシグナリングされ得る。サブＰＵの各々が、完全な動き情報のセットを保有する。したがって、ＰＵは、動き情報の複数のセットを保有し得る。

[0082] 同様に、３Ｄ−ＨＥＶＣの深度コーディングにおいて、テクスチャビューから導出された動きパラメータ継承（ＭＰＩ：Motion Parameter Inheritance）候補もまた、サブＰＵレベルのビュー間動き予測と同様の形で拡張され得ることが設計される。

[0083] たとえば、現在の深度ＰＵが、複数のＰＵを保有するコロケートされた領域を有する場合、該現在の深度ＰＵはサブＰＵに分割され得、その各々は、動き情報の異なるセットを有し得る。

[0084] この方法は、サブＰＵＭＰＩと呼ばれる。

[0085] 例となる２ＤビデオコーディングのためのサブＰＵに関連する技法が、米国出願第１４／４９７，１２８号で説明されており、その全体が、本明細書に参照により組み込まれている。米国出願第１４／４９７，１２８号では、サブＰＵベースの高度ＴＭＶＰ（ＡＴＭＶＰ）設計が提案されている。

[0086] 単層コーディングでは、２段階の高度時間動きベクトル予測子設計が提案される。第１段階は、参照ピクチャにおける現在の予測ユニット（ＰＵ）の対応するブロックを識別するベクトルを導出するために利用され、第２段階は、該対応するブロックから動き情報の複数のセットを抽出し、それらをＰＵのサブＰＵに割り当てることとする。したがってＰＵの各サブＰＵは、別個に動き補償される。ＡＴＭＶＰのコンセプトは以下の通りに要約される：（１）第１段階におけるベクトルは、現在のＰＵの空間的および時間的隣接ブロックから導出され得る。（２）このプロセスは、全ての他のマージ候補のうちから１つのマージ候補をアクティブにするときに達成され得る。

[0087] 単層コーディングおよびサブＰＵ時間動きベクトル予測に適用可能、ＰＵまたはＣＵは、予測子に加えて（on top of）伝達されるべき動きリファインメント（refinement）データを有し得る。

[0088] 米国出願第１４／４９７，１２８号のいくつかの設計態様が以下の通りにハイライトされる：
１．ベクトル導出の第１段階はまた、０ベクトルのみによって簡略化され得る。

２．ベクトル導出の第１段階は、動きベクトルとそれに関連するピクチャとを合わせて識別することを含み得る。関連するピクチャを選択し、動きベクトルを第１段階のベクトルであるとさらに決める様々な方法が提案されている。

３．上記プロセス中の動き情報が利用可能でない場合、「第１段階のベクトル」は代用（substitution）に使用される。

４．時間的隣接から識別される動きベクトルは、ＴＭＶＰにおける動きベクトルスケーリングと同様の形で、現在のサブＰＵに使用されるようにスケーリングされなければならない。しかしながら、そのような動きベクトルがどの参照ピクチャにスケーリングされ得るかは、以下の方法のうちの１つで設計され得る：
ａ．ピクチャは、現在のピクチャの固定の参照インデックスによって識別される。

ｂ．ピクチャは、現在のピクチャの参照ピクチャリストにおいても利用可能である場合、対応する時間的隣接の参照ピクチャであると識別される。

ｃ．ピクチャは、第１段階で、動きベクトルが獲得されるところから（from where the motion vectors are grabbed from）識別される、コロケートされたピクチャであると設定される。

[0089] 米国出願第１４／４９７，１２８号におけるいくつかの設計課題に対処するために、以下の技法が米国出願第１５／００５，５６４号において提案されており、その内容全体が、本明細書に参照により組み込まれている：
１．たとえばマージ候補リストとして挿入される場合、ＡＴＭＶＰ候補の位置は、
ａ．空間候補およびＴＭＶＰ候補が、ある特定の順序でマージ候補リストに挿入されることを前提とする。ＡＴＭＶＰ候補は、それらの候補の任意の相対的に固定の位置に挿入され得る。

ｉ．一代替例では、たとえば、ＡＴＭＶＰ候補は、マージ候補リスト中に、最初の２つの空間候補、たとえばＡ１およびＢ１の後に、挿入され得る。

ｉｉ．一代替例では、たとえば、最初の３つの空間候補、たとえばＡ１およびＢ１およびＢ０の後に、ＡＴＭＶＰ候補が挿入され得る。

ｉｉｉ．一代替例では、たとえば、最初の４つの候補、たとえばＡ１、Ｂ１、Ｂ０、およびＡ０の後に、ＡＴＭＶＰ候補が挿入され得る。

ｉｖ．一代替例では、たとえば、ＴＭＶＰ候補の直前に、ＡＴＭＶＰ候補が挿入され得る。

ｖ．一代替例では、たとえば、ＴＭＶＰ候補の直後に、ＡＴＭＶＰ候補が挿入され得る。

ｂ．代わりとして、候補リスト中のＡＴＭＶＰ候補の位置が、ビットストリームにおいてシグナリングされ得る。ＴＭＶＰ候補を含む他の候補の位置も、加えてシグナリングされ得る。

２.ＡＴＭＶＰ候補の利用可能性検査が、たった１セットの動き情報にアクセスすることによって適用できる。そのようなセットの情報が利用可能でない、たとえば１つのブロックがイントラコーディングされるとき、全ＡＴＭＶＰ候補が利用可能でないと見なされる。そのケースでは、ＡＴＭＶＰはマージリスト中に挿入されない。

ａ．中央位置または中央サブＰＵが、ＡＴＭＶＰ候補の利用可能性を純粋に検査するために使用される。中央サブＰＵが使用されるとき、該中央サブＰＵは中央の位置をカバーするものになるように選択される（たとえば、ＰＵの左上のサンプルに対して相対的な座標（Ｗ／２，Ｈ／２）をもつ中央３位置、ここにおいて、ＷｘＨはＰＵのサイズである）。そのような位置または中央サブＰＵは、動きソースピクチャ中の対応するブロックを識別するために時間ベクトルと共に使用され得る。対応するブロックの中央位置をカバーするブロックからの動き情報のセットが識別される。

３．サブＰＵからＡＴＭＶＰコーディングされたＰＵについての代表的な動き情報のセット。

ａ．ＡＴＭＶＰ候補を形成するために、代表的な動き情報のセットが最初に形成される。

ｂ．そのような代表的な動き情報のセットは、固定の位置または固定のサブＰＵから導出され得る。それは、箇条書き２．で説明されたようなＡＴＭＶＰ候補の利用可能性を決定するために使用された動き情報のセットのものと同じ方法で選ばれ得る。

ｃ．サブＰＵがそれ自体の動き情報のセットを識別して、それが利用可能でないとき、それは代表的な動き情報のセットに等しくなるように設定される。

ｄ．代表的な動き情報のセットがサブＰＵのものになるように設定される場合、最悪ケースのシナリオでは、現在のＣＴＵまたはスライスについてさらなる動き記憶がデコーダ側で必要とされない。

ｅ．復号プロセスが１セットの動き情報によってＰＵ全体が表されることを必要とするとき、全てのシナリオにおいて、そのような代表的な動き情報のセットは使用され、プルーニングを含め、該プロセスが結合双予測マージ候補を生成するために使用される。

４．ＡＴＭＶＰ候補はＴＭＶＰ候補を用いてプルーニングされ、ＴＭＶＰとＡＴＭＶＰとの間の相互作用が考慮され得る：詳細な技法が以下に挙げられる。

ａ．サブＰＵベースの候補、たとえばＡＴＭＶＰ候補、の通常の候補を用いたプルーニングが、そのようなサブＰＵベースの候補についての（箇条書き３．にあるような）代表的な動き情報のセットを使用することによって行われ得る。そのような動き情報のセットが通常のマージ候補と同じである場合、２つの候補は同じと見なされる。

ｂ．代わりとして、加えて、ＡＴＭＶＰが複数のサブＰｕｓについての複数の異なるセットの動き情報を保有するかどうかを決定するために、検査が行われる；もし２つの異なるセットが識別された場合、サブＰＵベースの候補はプルーニングに使用されず、これは即ち、任意の他の候補に対しても異なると見なされる。そうでない場合、それはプルーニングに使用され得る（たとえば、プルーニングプロセス中にプルーニングされ得る）。

ｃ．代わりとして、加えて、ＡＴＭＶＰ候補は、Ａ１およびＢ１で表されている位置にある空間候補、たとえば左および上の候補のみ、を用いてプルーニングされ得る。

ｄ．代わりとして、ＡＴＭＶＰ候補またはＴＭＶＰ候補のどちらかである、１つの候補のみが時間参照から形成される。ＡＴＭＶＰが利用可能であるとき、候補はＡＴＭＶＰであり、そうでなければ候補はＴＭＶＰである。そのような候補は、ＴＭＶＰの位置と同様の位置でマージ候補リスト中に挿入される。このケースでは、最大数の候補が変化されないまま維持され得る。

ｉ．代わりとして、ＴＭＶＰは、ＡＴＭＶＰが利用可能でないときでさえ、常にディセーブルにされている。

ｉｉ．代わりとして、ＴＭＶＰは、ＡＴＭＶＰが利用可能でないときにのみ使用される。

ｅ．代わりとして、ＡＴＭＶＰが利用可能であり、かつＴＭＶＰが利用可能でないとき、１つのサブＰＵの１セットの動き情報がＴＭＶＰ候補として使用される。このケースではさらに、ＡＴＭＶＰとＴＭＶＰとの間のプルーニングプロセスは適用されない。

ｆ．代わりとして、または加えて、ＡＴＭＶＰに使用される時間ベクトルはまた、ＴＭＶＰにも使用され得、よって、ＨＥＶＣにおける現在のＴＭＶＰに使用されるような右下位置または中央３位置が使用される必要がない。

ｉ．代わりとして、時間ベクトルによって識別される位置と、右下および中央３位置とは合わせて、利用可能なＴＭＶＰ候補を提供すると見なされる。

５．ＡＴＭＶＰ候補がより正確で効率的になる可能性をより高くする（give higher chances）ために、ＡＴＭＶＰのための複数の利用可能性検査がサポートされる。（たとえば、図９で示されるような）第１の時間ベクトルによって識別されるような動きソースピクチャからの現在のＡＴＭＶＰ候補が利用可能でないとき、他のピクチャが動きソースピクチャと見なされ得る。別のピクチャが考慮されるとき、それは、異なる第２の時間ベクトルに関連付けられ得るか、または利用可能でないＡＴＭＶＰ候補を指す第１の時間ベクトルからスケーリングされた第２の時間ベクトルに単に関連付けられ得る。

ａ．第２の時間ベクトルは、第２の動きソースピクチャ中のＡＴＭＶＰ候補を識別し得、同じ利用可能性検査が適用され得る。第２の動きソースピクチャから導出されるようなＡＴＭＶＰ候補が利用可能である場合、ＡＴＭＶＰ候補は導出され、他のピクチャは検査される必要がない。そうでない場合、動きソースピクチャとしての他のピクチャが検査される必要がある。

ｂ．検査されるピクチャは、所与の順序をもつ現在のピクチャの参照ピクチャリスト中のピクチャであり得る。各リストについて、ピクチャは、参照インデックスの昇順で検査される。リストＸが最初に検査され、（１−Ｘである）リストＹ中のピクチャが後に続く。

ｉ．リストＸが、ＴＭＶＰに使用されるコロケートされたピクチャを保有するリストになるように、リストＸは選ばれる。

ｉｉ．代わりとして、Ｘは、単に１または０に設定される。

ｃ．検査されるピクチャは、所与の順序をもつ空間的隣接の動きベクトルによって識別されるピクチャである。

６．現在のＡＴＭＶＰが適用されるＰＵの区分は、２Ｎｘ２Ｎ、ＮｘＮ、２ＮｘＮ、Ｎｘ２Ｎ、または２ＮｘＮ／２のような非対称の動き区分（ＡＭＰ）の区分であり得る。

ａ．代わりとして、加えて、他の区分サイズが許容され得る場合、ＡＴＭＶＰもサポートされ得、そのようなサイズは、たとえば６４ｘ８を含み得る。

ｂ．代わりとして、モードは、ある特定の区分、たとえば２Ｎｘ２Ｎにのみ適用され得る。

７．ＡＴＭＶＰ候補は、異なるタイプのマージ候補としてマークされる。

８．隣接からベクトル（第１段階にあるような時間ベクトル）を識別するとき、複数の隣接位置、たとえばマージ候補リスト構築で使用されるものが順番に検査され得る。隣接の各々について、参照ピクチャリスト０（リスト０）または参照ピクチャリスト１（リスト１）に対応する動きベクトルが順番に検査され得る。２つの動きベクトルが利用可能であるとき、リストＸ中の動きベクトルが最初に検査され、その後にリストＹ（ここで、Ｙは１−Ｘに等しい）が続き得、その結果、リストＸがＴＭＶＰに使用されるコロケートされたピクチャを保有するリストになる。ＡＴＭＶＰでは、時間ベクトルがサブＰＵの任意の中央位置のシフトとして加えられるように使用され、ここにおいて、時間ベクトルの成分は、整数にシフトされる必要があり得る。そのようなシフトされた中央位置は、たとえば現在の中央位置をカバーする４ｘ４のサイズをもつ、動きベクトルが割り振られ得る最小ユニットを識別するために使用される。

ａ．代わりとして、リスト０に対応する動きベクトルが、リスト１に対応するものの前に検査され得る。

ｂ．代わりとして、リスト１に対応する動きベクトルが、リスト０に対応するものの前に検査され得る。

ｃ．代わりとして、全ての空間的隣接中のリストＸに対応する全ての動きベクトルが順番に検査され、その後にリストＹ（ここで、Ｙは１−Ｘに等しい）に対応する動きベクトルが続く。ここで、リスト「Ｘ」は、コロケートされたピクチャが属するところを示すリストであり得るか、または単に０または１に設定されるだけであり得る。

ｄ．空間的隣接の順序は、ＨＥＶＣマージモードで使用されるものと同じであり得る。

９．第１段階で、参照ピクチャを識別する情報を含まない時間ベクトルを識別するとき、図９で示されているような動きソースピクチャは単に、固定のピクチャ、たとえばＴＭＶＰに使用されるコロケートされたピクチャに設定され得る。

ａ．そのようなケースでは、ベクトルは、そのような固定のピクチャを指す動きベクトルからのみ識別され得る。

ｂ．そのようなケースでは、ベクトルは、任意のピクチャを指す動きベクトルからのみ識別されるが、固定のピクチャに向かってさらにスケーリングされ得る。

１０．ベクトルを識別する第１段階が、参照ピクチャ、即ち図９で示されているような動きソースピクチャを識別することを含む（consist）とき、以下の追加の検査のうちの１つまたは複数が、候補の動きベクトルについて適用され得る。

ａ．動きベクトルがイントラコーディングされるピクチャまたはスライスに関連付けられる場合、そのような動きベクトルは利用可能でないと見なされ、ベクトルに変換されるようには使用されることができない。

ｂ．動きベクトルが、関連付けられるピクチャにおいて、（たとえば、動きベクトルを現在の中央座標に加えることによって）イントラブロックを識別する場合、そのような動きベクトルは、利用可能でないと見なされ、ベクトルに変換されるように使用されることができない。

１１．第１段階がベクトルを識別するとき、ベクトルの成分は、（現在のＰＵの半分の幅、現在のＰＵの半分の高さ）に設定され得、結果、それが動きソースピクチャ中の右下ピクセル位置を識別するようにする。ここで、（ｘ，ｙ）は、１つの動きベクトルの水平および垂直成分を示す。

ａ．代わりとして、ベクトルの成分は、（ｓｕｍ（現在のＰＵの半分の幅，Ｍ），ｓｕｍ（現在のＰＵの半分の高さ，Ｎ））に設定され得、ここで、関数ｓｕｍ（ａ，ｂ）は、ａとｂの合計を返す。一例では、動き情報が４ｘ４ユニットで記憶されるとき、ＭおよびＮは両方とも、２に等しくなるように設定される。別の例では、動き情報が８ｘ８ユニットで記憶されるとき、ＭおよびＮは両方とも、４に等しくなるように設定される。

１２．ＡＴＭＶＰが適用されるときのサブブロック／サブＰＵサイズは、パラメータセット、たとえばピクチャパラメータセットのシーケンスパラメータセットに、おいてシグナリングされる。サイズは、少なくともＰＵサイズからＣＴＵサイズに及ぶ。サイズはまた、予め定義されるか、またはシグナリングされ得る。サイズは、たとえば４ｘ４程の小ささであり得る。代わりとして、サブブロック／サブＰＵサイズは、ＰＵまたはＣＵのサイズに基づいて導出され得る。たとえば、サブブロック／サブＰＵは、最大値（４ｘ４，（ＣＵの幅）＞＞Ｍ）に等しく設定され得る。Ｍの値は、予め定義され得るか、ビットストリームにおいてシグナリングされ得る。

１３．マージ候補の最大数は、ＡＴＭＶＰが新たなマージ候補として見なされ得るという事実に起因して１だけ増加し得る。たとえば、プルーニング後にマージ候補リストに最大５つの候補を入れるＨＥＶＣと比較すると、マージ候補の最大数は、６まで増加し得る。

ａ．代わりとして、従来のＴＭＶＰ候補を用いたプルーニングまたは従来のＴＭＶＰ候補との統合が、マージ候補の最大数が変化されないまま維持され得るように、ＡＴＭＶＰについて実行され得る。

ｂ．代わりとして、ＡＴＭＶＰが利用可能であると識別されるとき、１つの空間的隣接候補が、マージ候補リストから排除され、たとえば、フェッチ順序で最後の空間的隣接候補が排除される。

１４．複数の空間的隣接動きベクトルが時間ベクトルを導出するために考慮されるとき、現在のＰＵの隣接動きベクトルと、ある動きベクトルに等しく設定されている特定の時間ベクトルによって識別された隣接動きベクトルとに基づいて、動きベクトルの類似度が計算され得る。最高の動きの類似度に導くものが、最終的な時間ベクトルとして選ばれ得る。

ａ．一代替例では、隣接位置Ｎからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロック（現在のＰＵと同じサイズ）を識別し、ここにおいて、その隣接位置Ｎは、１セットの動き情報を保有する。この１セットの動きベクトルは、現在ブロックの隣接位置Ｎにあるような１セットの動き情報と比較される。

ｂ．別の代替例では、隣接位置Ｎからの各動きベクトルについて、それは動きソースピクチャ中のブロックを識別し、ここにおいて、その隣接位置は、動き情報の複数のセットを保有する。これらの動きベクトルの複数のセットは、同じ関連する(the same relative)位置にある現在のＰＵの隣接位置からの動き情報の複数のセットと比較される。動き情報の類似度が計算される。たとえば、現在のＰＵは、Ａ１、Ｂ１、Ａ０、およびＢ０からの以下の動き情報のセット、ＭＩ_A1、ＭＩ_B1、ＭＩ_A0、およびＭＩ_B0と表される、を有する。時間ベクトルＴＶでは、それは、動きソースピクチャ中のＰＵに対応するブロックを識別する。そのようなブロックは、同じ関連する（the same relative）Ａ１、Ｂ１、Ａ０、およびＢ０の位置からの動き情報を有し、ＴＭＩ_A1、ＴＭＩ_B1、ＴＭＩ_A0、およびＴＭ_IB０と表される。ＴＶによって決定されるような動きの類似度は、MS_tv=Σ_{N∈{A1,B1,A0,B0}}MVSim(MI_N,TMI_N)として計算され、ここにおいて、ＭＶＳｉｍは、２セットの動き情報間の類似度を定義する。

ｃ．上記ケースの両方において、動きの類似度ＭＶＳｉｍが使用され得、ここにおいて、２つの入力パラメータは２つの動き情報であり、その各々が、最大２つの動きベクトルおよび２つの参照インデックスを保有する。リストＸ中の動きベクトルの各ペアは、実際、異なるピクチャの異なるリストＸ中の参照ピクチャ、現在のピクチャ、および動きソースピクチャに関連付けられているので。２つの動きベクトルＭＶＸ_NおよびＴＭＶＸ_Nの各々（ここで、Ｘは０または１に等しい）について、動きベクトル差分ＭＶＤＸ_Nが、MVX_N-TMVX_Nとして計算され得る。その後、差分ＭＶＳｉｍＸが、たとえばabs(MVDX_N[0])+abs(MVDX_N[1])、または(MVDX_N[0]*MVDX_N[0]+MVDX_N[1]*MVDX_N[1])として計算される。両方の動き情報のセットが利用可能な動きベクトルを保有する場合、ＭＶＳｉｍは、MVSim0+MVSim1に等しく設定される。

ｉ．動き差分の統一的計算を有するために、動きベクトルの両方が、同じ固定のピクチャ、たとえば現在のピクチャのリストＸの第１の参照ピクチャRefPicListX[0]であり得るピクチャ、に向かってスケーリングされる必要がある。

ｉｉ．第１のセットからのリストＸ中の動きベクトルの利用可能性と、第２のセットからのリストＸ中の動きベクトルの利用可能性とが異なる、即ち、１つの参照インデックスが−１であるのに対してもう一方がそうでない場合、そのような２セットの動き情報は方向Ｘで類似しないと見なされる。２セットが両方のセットにおいて類似しない場合、最終的なＭＶＳｉｍ関数は大きい値Ｔを返し得、Ｔは、たとえば無限と見なされ得る。

ｉｉｉ．代わりとして、ペアの動き情報のセットについて、一方がリストＸ（Ｘは０または１に等しい）から予測されるがリストＹ（Ｙは１−Ｘに等しい）からは予測されず、他方が同じステータスを有する場合、１と２との間の重み（たとえば、ＭＶＳｉｍがＭＶＳｉｍＸ＊１．５に等しい）が使用され得る。１セットがリストＸからのみ予測され、もう一方がリストＹからのみ予測されるとき、ＭＶＳｉｍは、大きい値Ｔに設定される。

ｉｖ．代わりとして、動き情報の任意のセットについて、１つの動きベクトルが利用可能である限り、両方の動きベクトルが作り出されることになる。（リストＸに対応する）１つの動きベクトルのみが利用可能であるケースでは、それは、もう一方のリストＹに対応する動きベクトルを形成するようにスケーリングされる。

ｄ．代わりとして、現在のＰＵの隣接ピクセルと、動きベクトルによって識別されたブロック（現在のＰＵと同じサイズ）の隣接ピクセルとの間の差分に基づいて、動きベクトルが測定され得る。最小の差分を導く動きベクトルが、最終的な時間ベクトルとして選ばれ得る。

１５．現在ブロックの時間ベクトルを導出するとき、ＡＴＭＶＰを用いてコーディングされる隣接ブロックからの時間ベクトルおよび／または動きベクトルは、他の隣接ブロックからの動きベクトルよりも高い優先度を有し得る。

ａ．一例では、隣接ブロックの時間ベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときにのみ、通常の時間ベクトルがさらに検査される。このケースでは、ＡＴＭＶＰコーディングされたブロックについての時間ベクトルが記憶される必要がある。

ｂ．別の例では、ＡＴＭＶＰコーディングされた隣接ブロックからの動きベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときにのみ、通常の時間ベクトルがさらに検査される。

ｃ．別の例では、ＡＴＭＶＰコーディングされた隣接ブロックからの動きベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条書き１５ａ．にあるものと同様に継続する。

ｄ．別の例では、隣接ブロックからの時間ベクトルが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条書き１５ｂ．にあるものと同様に継続する。

ｅ．別の例では、ＡＴＭＶＰコーディングされた隣接ブロックの時間ベクトルおよび動きベクトルが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルおよび動きベクトルが存在しないときにのみ、通常の動きベクトルがさらに検査される。

１６．複数の空間的隣接動きベクトルが時間ベクトルを導出するために考慮されるとき、動きベクトルが、ピクセルドメインから計算される歪みを最小化するように選ばれ得、たとえば、テンプレートマッチングが時間ベクトルを導出するために使用され得、最小のマッチングコストに導くものが最終的な時間ベクトルとして選択される。

１７．動きベクトルが、何れのリストＸについても、対応するブロックで利用可能である（動きベクトルをＭＶＸと表す）ときに、ＡＴＭＶＰ候補の現在のサブＰＵについて、該動きベクトルが（ＭＶＸをスケーリングすることによって）リストＸについて利用可能であると見なされる形で、（動きソースピクチャ中の）対応するブロックからの動き情報のセットの導出がなされる。動きベクトルが何れのリストＸについても、対応するブロックで利用可能でない場合、動きベクトルは、リストＸについて利用可能でないと見なされる。

ａ．代わりとして、対応するブロックにおける動きベクトルが、リストＸについては利用可能でないが、リスト１−Ｘ（Ｙで１−Ｘを表し、動きベクトルをＭＶＹと表す）については利用可能であるとき、動きベクトルは依然として、（リストＸ中のターゲット参照ピクチャに対してＭＶＹをスケーリングすることによって）リストＸについて利用可能であると見なされる。

ｂ．代わりとして、または加えて、リストＸおよびリストＹ（１−Ｘに等しい）についての対応するブロックにおける両方の動きベクトルが利用可能であるとき、リストＸおよびリストＹからの動きベクトルは、直接スケーリングする必要はなく（are not necessary used to directly scale）、スケーリングすることによって現在のサブＰＵの２つの動きベクトルを生成する。

ｉ．一例では、ＡＴＭＶＰ候補を作る（formulating）とき、ＴＭＶＰで行われるような低遅延検査が各サブＰＵに適用される。現在のスライスの全ての参照ピクチャリスト中の全てのピクチャ（ｒｅｆＰｉｃによって表されている）について、ｒｅｆＰｉｃのピクチャ順序カウント（ＰＯＣ）値は、現在のスライスのＰＯＣよりも小さい場合、現在のスライスは低遅延モードで考慮される。この低遅延モードでは、リストＸおよびリストＹからの動きベクトルは、リストＸおよびリストＹそれぞれについて現在のサブＰＵの動きベクトルを生成するようにスケーリングされる。低遅延モードにないとき、ＭＶＸまたはＭＶＹから１つの動きベクトルＭＶＺのみが選ばれ、現在のサブＰＵについての２つの動きベクトルを生成するためにスケーリングされる。ＴＭＶＰと同様に、Ｚがcollocated_from_l0_flagに等しく設定されるケースにおいて、それは、ＴＭＶＰにあるようなコロケートされたピクチャが現在ピクチャのリストＸにあるのか、またはリストＹにあるかに依存することを意味する。代わりとして、Ｚは以下の通りに設定される。動きソースピクチャがリストＸから識別される場合、ＺはＸに設定される。代わりとして、加えて、動きソースピクチャが両方の参照ピクチャリストに属し、RefPicList0[idx0]は、最初にリスト０に存在する動きソースピクチャであり、RefPicList(1)[idx1]は、最初にリスト１に存在する動きソースピクチャであるとき、Ｚは、ｉｄｘ０がｉｄｘ１以下である場合には０に設定され、そうでなければ１に設定される。

１８．動きソースピクチャはシグナリングされ得、たとえば、ビデオエンコーダ２０によって生成され、コーディングされたビットストリームにおいてシグナリングされ得る。詳細には、動きソースピクチャがリスト０からのものか、リスト１からのものかを示すフラグが、Ｂスライスのためにシグナリングされる。代わりとして、加えて、現在のピクチャのリスト０またはリスト１への参照インデックスが、動きソースピクチャを識別するためにシグナリングされ得る。

[0090] 時間ベクトルを識別するとき、ベクトルは、それが、関連する動きソースピクチャ中のイントラコーディングされたブロックを指す場合、利用可能でないと見なされる（従って他のベクトルが考慮され得る）。

[0091] 図５は、参照ピクチャからのサブＰＵ動き予測を例示する概念図である。この例では、現在のピクチャ１８０は、現在のＰＵ１８４（たとえばＰＵ）を含む。この例では、動きベクトル１９２は、ＰＵ１８４に対する参照ピクチャ１８２のＰＵ１８６を識別する。ＰＵ１８６は、サブＰＵ１８８Ａ〜１８８Ｄに分割され、その各々がそれぞれの動きベクトル１９０Ａ〜１９０Ｄを有する。したがって、現在のＰＵ１８４は、実際には別個のサブＰＵに分割されないが、この例では、現在のＰＵ１８４は、サブＰＵ１８８Ａ〜１８８Ｄからの動き情報を使用して予測され得る。特に、ビデオコーダは、現在のＰＵ１８４のサブＰＵをそれぞれの動きベクトル１９０Ａ〜１９０Ｄを使用して、コーディングし得る。しかしながら、ビデオコーダは、現在のＰＵ１８４がサブＰＵに分けられることを示すシンタックス要素をコーディングする必要はない。このように、現在のＰＵ１８４は事実上、現在のＰＵ１８４を複数のサブＰＵに分けるために使用されるシンタックス要素のシグナリングオーバーヘッドなしで、それぞれのサブＰＵ１８８Ａ〜１８８Ｄから受け継がれる複数の動きベクトル１９０Ａ〜１９０Ｄを使用して予測され得る。

[0092] 図６は、（ＴＭＶＰに類似する）ＡＴＭＶＰにおける関連するピクチャを例示する概念図である。特に、図９は、現在のピクチャ２０４、動きソースピクチャ２０６、および参照ピクチャ２００、２０２を例示する。より具体的には、現在のピクチャ２０４は現在ブロック２０８を含む。時間動きベクトル２１２は、現在ブロック２０８に対する動きソースピクチャ２０６の対応するブロック２１０を識別する。対応するブロック２１０が今度は、参照ピクチャ２０２を指し、現在ブロック２０８の少なくとも一部分、たとえば現在ブロック２０８のサブＰＵについての高度時間動きベクトル予測子（advanced temporal motion vector predictor）としての役割をする動きベクトル２１４を含む。つまり動きベクトル２１４は、現在ブロック２０８についての候補の動きベクトル予測子として加えられ得る。選択された場合、現在ブロック２０８の少なくとも一部分は、対応する動きベクトル、すなわち参照ピクチャ２００を指す動きベクトル２１６を使用して予測され得る。

[0093] ＨＥＶＣのためのサブＰＵ関連技法はまた、米国出願第６２／１７４，３９３号および第６２／２９５，３２９号でも説明されており、その両方の内容全体が、本明細書に参照により組み込まれている。時空間動きベクトル予測子（spatial-temporal motion vector predictor）導出についての例となる技法を示すフローチャートが、以下の図７において示される。

[0094] サブＰＵ動き予測を使用するパフォーマンスを高めるために、隣接サブＰＵの時空間動き情報（ＡＴＭＶＰ＿ＥＸＴ）が、米国出願第６２／１７４，３９３号および第６２／２９５，３２９号で説明されているように利用される。この例では、サブＰＵ毎の動きベクトルが、３次元ドメインにおける隣接ブロックの情報から導出される。それは、隣接ブロックが、現在のピクチャ中の空間的隣接であるか、または前にコーディングされたピクチャ中の時間的隣接であり得ることを意味する。図７は、時空間動きベクトル予測子（ＳＴＭＶＰ）導出プロセスのフローチャートを示す。以下で説明されることに加えて、ＡＴＭＶＰについて上で説明された方法（たとえば、箇条書き１、２、３、４、６、７、１２、１３）がＳＴＭＶＰに直接拡張され得る。

[0095] 図７の方法は、（以下でより詳細に説明されるように）ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得る。一般性のために（for generality）、図７の方法は、「ビデオコーダ」によって実行されるものとして説明されるが、この場合も同様に、「ビデオコーダ」は、ビデオエンコーダ２０またはビデオデコーダ３０のどちらかに対応し得る。

[0096] 最初に、ビデオコーダは、ＰＵの現在のサブＰＵについての空間的または時間的隣接ブロックから利用可能な動きフィールドを取得する（２３０）。ビデオコーダはその後、取得された隣接動きフィールドから動き情報を導出する（２３２）。ビデオコーダはその後、ＰＵの全てのサブＰＵについての動き情報が導出されたかどうかを決定する（２３４）。導出されていない（not）場合（２３４の「ＮＯ」の分岐）、ビデオコーダは、残りのサブＰＵについての動き情報を導出する（２３０）。一方で、全てのサブＰＵについての動作情報が導出された場合（２３４の「ＹＥＳ」の分岐）、ビデオコーダは、たとえば上で説明されたように、時空間サブＰＵ動き予測子の利用可能性を決定する（２３６）。時空間サブＰＵ動き予測子が利用可能である場合、ビデオコーダは、マージリスト中に時空間サブＰＵ動き予測子を挿入する（２３８）。

[0097] 図７の方法では示されていないけれども、ビデオコーダはその後、マージ候補リストを使用して、ＰＵ（たとえば、ＰＵのサブＰＵの各々）をコーディングし得る。たとえば、ビデオエンコーダ２０によって実行されるとき、ビデオエンコーダ２０は、予測子としてサブＰＵを使用して、ＰＵについての（たとえば、サブＰＵ毎の）（１つまたは複数の）残差ブロックを計算し、該（１つまたは複数の）残差ブロックを変換および量子化し、結果として得た量子化された変換係数をエントロピー符号化し得る。ビデオデコーダ３０も同様に、受信されたデータをエントロピー復号して、量子化された変換係数を再生成し、これらの係数を逆量子化および逆変換して（１つまたは複数の）残差ブロックを再生成し、その後、該（１つまたは複数の）残差ブロックを対応するサブＰＵと結合して（combine）、当該ＰＵに対応するブロックを復号し得る。

[0098] 以下の説明では、「ブロック」という用語は、たとえば、インターまたはイントラ予測、イントラ予測モード、動き情報等の予測関連情報の記憶のためのブロックユニットを参照するために使用される。そのような予測情報は、将来的なブロックをコーディングするため、たとえば将来的なブロックについて予測モード情報を予測するために記憶され、使用され得る。ＡＶＣおよびＨＥＶＣでは、そのようなブロックのサイズは４ｘ４である。以下の説明では、「ＰＵ」はインターコーディングされるブロックユニットを示すために使用され、サブＰＵは隣接ブロックから動き情報を導出するユニットを示すために使用される。

[0099] 以下の技法の何れの組合せも適用され得る。

[0100] 図８は、例となる現在の予測ユニット（ＰＵ）２５０および隣接サブＰＵ２５２Ａ〜２５２Ｉを例示する概念図である。現在ブロック２５０は、サブＰＵ２５４Ａ〜２５４Ｐを含む。ＰＵが複数のサブＰＵを含むとき、サブＰＵの各々のサイズは通常、その隣接ブロックサイズ以上である。図８の例では、サブＰＵ２５２Ａ〜２５２Ｉは、現在のＰＵ２５０の外側にある隣接ブロックを表し、サブＰＵ２５４Ａ〜２５４Ｐは、現在のＰＵ２５０中のサブＰＵを表す。この例では、サブＰＵ２５４Ａ〜２５４Ｐと隣接サブＰＵ２５２Ａ〜２５２Ｉとのサイズは同じである。たとえば、サイズは４ｘ４に等しくなり得る。

[0101] 一方、図９は、隣接ブロック２６４Ａ〜２６４Ｉよりも大きいサブＰＵ２６２Ａ〜２６２Ｄを含む別の例となる現在のＰＵ２６０を例示する概念図である。他の例では、サブＰＵは、矩形(rectangles)または三角形のような非正方形（non-square shapes）を有し得る。

[0102] いくつかの例では、サブＰＵのサイズは、サブＰＵに分割されたブロックを含むスライスのスライスヘッダにおいてシグナリングされ得る。

[0103] 代わりとして、ＡＴＭＰＶに関連する上記説明の箇条書き１２．におけるプロセスが拡張され得る。図８におけるケースを考慮すると、ラスタ走査順序（２５４Ａ、２５４Ｂ、２５４Ｃ、２５４Ｄ、２５４Ｅなど）が、サブＰＵ２５４Ａ〜２５４Ｐに対して、以下の説明におけるそれらの動き予測導出のために適用されることを前提とする。しかしながら、他の走査順序も適用され得、本開示の技法がラスタ走査順序のみに限定されないことに留意されたい。

[0104] ここで、隣接ブロックは、２つの異なるタイプ：空間的および時間的、に分類され得る。空間的隣接ブロックは、図８の空間的隣接サブＰＵ２５２Ａ〜２５２Ｉのような、現在のピクチャまたはスライス中にある、現在のサブＰＵに隣接する、既にコーディングされたブロックまたは既に走査されたサブＰＵである。時間的隣接ブロック（図８では図示せず）は、前にコーディングされたピクチャ中にある、現在のサブＰＵのコロケートされたブロックに隣接するブロックである。一例では、現在のＰＵに関連付けられた全ての参照ピクチャが、時間的隣接ブロックを取得するために使用される。別の例では、参照ピクチャのサブセットがＳＴＭＶＰ導出に使用され、たとえば、各参照ピクチャリストの最初のエントリのみが使用される。

[0105] この定義にしたがうと、サブＰＵ２５４Ａについて、全ての隣接ブロック２５２Ａ〜２５２Ｐおよび前にコーディングされたピクチャ中のそれらのコロケートされたブロックが、利用可能と扱われる空間的および時間的隣接ブロックである。ラスタ走査順序にしたがうと、ブロック２５４Ｂ〜２５４Ｐは空間的に利用可能でない。しかしながら、全てのサブＰＵ（２５４Ａ〜２５４Ｐ）は、それらの動き情報が前にコーディングされたピクチャ中のそれらのコロケートされたブロックにおいて発見され得るので、サブＰＵ（Ａ）についての時間的に利用可能な隣接ブロックである。サブＰＵ２５４Ｇを別の例として挙げると、それの利用可能な空間的隣接ブロックは、２５２Ａ〜２５２Ｉからのもの、そしてまた２５４Ａ〜２５４Ｆからのものを含む。いくつかの例では、ある特定の制限が空間的隣接ブロックに適用され得、たとえば、空間的隣接ブロック（即ち、サブＰＵ２５２Ａ〜２５２Ｉ）は、「利用可能」と見なされるためには、現在ブロック２５０と同じＬＣＵ／スライス／タイルに存在するように制限され得る。

[0106] 全ての利用可能な隣接ブロックのサブセットが、各サブＰＵのための動き情報または動きフィールドを導出するために選択され得る。各ＰＵの導出に使用されるサブセットは予め定義され得、代わりとして、それは、スライスヘッダ／ＰＰＳ／ＳＰＳにおいて高レベルシンタックスとしてシグナリングされ得る。コーディングパフォーマンスを最適化するために、サブセットは各サブＰＵについて異なり得る。実際、簡潔さのために、サブセットについてのロケーションの固定パターンが好ましい。たとえば、各サブＰＵは、そのすぐ上の空間的隣接、そのすぐ左の空間的隣接、およびそのすぐ右下の時間的隣接、をサブセットとして使用し得る。図８で示されているように、サブＰＵ２５４Ｊを考慮するとき、上ブロック（サブＰＵ２５４Ｆ）および左ブロック（サブＰＵ２５４Ｉ）が空間的に利用可能な隣接ブロックであり、右下ブロック（サブＰＵ２５４Ｏ）が時間的に利用可能な隣接ブロックである。そのようなサブセットを用いて、現在のＰＵ２５０中のサブＰＵ２５４Ａ〜２５４Ｐは、処理依存に起因して、シーケンシャルに、処理され得る。

[0107] 現在のＰＵ２５０中のサブＰＵ２５４Ａ〜２５４Ｐの各々の並列処理を可能にするために、隣接サブＰＵ２５２Ａ〜２５２Ｉの異なるサブセットが定義および使用され得る。一例では、サブセットは、現在のＰＵ２５０に属さない空間的隣接ブロック、たとえば隣接サブＰＵ２５２Ａ〜２５２Ｉのみを保有する。このケースでは、並列処理が可能だろう。別の例では、サブＰＵ２５４Ａ〜２５４Ｐの所与の１つについて、その空間的隣接ブロックが現在のＰＵ２５０内にある場合、その空間的隣接ブロックのコロケートされたブロックがサブセットに置かれ、現在のサブＰＵの動き情報を導出するために使用され得る。たとえば、サブＰＵ２５４Ｊを考慮するとき、上ブロック（サブＰＵ２５４Ｆ）と左ブロック（サブＰＵ２５４Ｉ）と右下ブロック（サブＰＵ２５４Ｏ）との時間的にコロケートされたブロックが、サブＰＵ（サブＰＵ２５４Ｊ）の動きを導出するためにサブセットとして選択される。このケースでは、サブＰＵ２５４Ｊのためのサブセットは、３つの時間的隣接ブロックを保有する。別の例では、部分的な並列処理がイネーブルにされ得、ここにおいて、１つのＰＵがいくつかの領域に分けられ、（いくつかのサブＰＵをカバーする）各領域が別個に処理され得るだろう。

[0108] 時折、隣接ブロックがイントラコーディングされ、より良好な動き予測およびコーディング効率のために、それらのブロックについての置き換え動き情報（replacement motion information）を決定する規則を有することが望ましくあり得る。たとえば、サブＰＵ２５４Ａを考慮すると、サブＰＵ２５２Ｂ、２５２Ｃ、および２５２Ｆがイントラコーディングされ、サブＰＵ２５２Ａ、２５２Ｄ、２５２Ｅ、２５２Ｇ、２５２Ｈ、および２５２Ｉがインターコーディングされるケースが存在するかもしれない。

[0109] 空間的隣接では、予め定義された順序が、イントラコーディングされたブロックの動き情報に、最初に発見されたインターコーディングされたブロックの動き情報を投入するために使用され得る。たとえば、上の隣接の探索順序は、真上の隣接から始まり右方向に右端（rightmost）の隣接まで向かうように設定され、これはサブＰＵ２５２Ｂ、２５２Ｃ、２５２Ｄ、および２５２Ｅの順序を意味する。左の隣接の探索順序は、すぐ左の隣接から始まり下方向に最下部（bottommost）の隣接まで向かうように設定され、これはサブＰＵ２５２Ｆ、２５２Ｇ、２５２Ｈ、および２５２Ｉの順序を意味する。インターコーディングされたブロックが探索プロセスを通じて発見されない場合、上または左の空間的隣接が利用可能でないと見なされる。

[0110] 時間的隣接では、ＴＭＶＰ導出で指定されているものと同じ規則が使用され得る。しかしながら、他の規則、たとえば、動き方向、時間距離（異なる参照ピクチャにおける探索）、および空間的ロケーション等に基づく規則も使用され得ることに留意されたい。

[0111] 各隣接ブロックについて、全ての隣接ブロックの動きベクトルを各リスト中の同じ参照ピクチャにマッピングするために、動きベクトルスケーリングが各参照ピクチャリストに基づいてその動きベクトルに適用される。ステップは２つある：第１に、スケーリングに使用されるべきソース動きベクトルを決定する。第２に、ソース動きベクトルが投影されるターゲット参照ピクチャを決定する。第１のステップでは、いくつかの方法が使用され得る。

（ａ）各参照リストについて、動きベクトルスケーリングが、別の参照リストにおける動きベクトルから独立している；所与のブロックの動き情報について、参照リストに動きベクトルがない（たとえば、双予測モードではなく単一予測モード）場合、どの動きベクトルスケーリングも、そのリストについては実行されない。

（ｂ）動きベクトルスケーリングが、別の参照リストにおける動きベクトルから独立していない；所与のブロックの動き情報について、参照リストにおいてどの動きベクトルも利用不可能でない場合、それは、別の参照リストにおけるものからスケーリングされ得る。

（ｃ）両方の動きベクトルが、（上で言及されたＴＭＶＰにあるような）１つの予め定義された参照リストからスケーリングされる。

[0112] 一例として、方法（ａ）は空間的隣接ブロックの動きベクトルをスケーリングするために使用され、方法（ｃ）は時間的隣接ブロックの動きベクトルをスケーリングするために使用される。

[0113] 第２のステップに関しては、ターゲット参照ピクチャは、利用可能な空間的隣接ブロックの動き情報（たとえば、参照ピクチャ）に基づくある特定の規則にしたがって選択され得る。そのような規則の一例は、多数決原理、即ちブロックの大多数によって共有される参照ピクチャを選択することである。このケースでは、エンコーダからデコーダへの、ターゲット参照ピクチャについて必要なシグナリングが存在せず、これは、デコーダ側でも同じ規則を使用して、同じ情報が推論され得るからである。代わりとして、そのような参照ピクチャはまた、明示的にスライスヘッダにおいて指定され得るか、または何らかの他の方法でデコーダにシグナリングされ得る。ターゲット参照ピクチャは、各参照リストの第１の参照ピクチャ（refidx=0）として決定される。

[0114] 前章で例示されたように隣接ブロックから動き情報を検索した後、および（必要であれば）動きスケーリングプロセスの後、現在のサブＰＵの動き情報が導出される。１つの所与のサブＰＵについての動き情報をもつＮ個の利用可能な隣接ブロックが存在することを前提とする。最初に、予測方向（InterDir）が決定されなければならない。最もシンプルな方法は以下の通りである：
ａ．InterDirが０として初期化され、その後、Ｎ個の利用可能な隣接ブロックの動き情報をループする(loop through)。

ｂ．リスト０に少なくとも１つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR 1)である。

ｃ．リスト１に少なくとも１つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR 2)である。
ここで、「bitwiseOR」は、ビット単位の論理和演算（bitwise OR operation）を表す。InterDirの値は以下の通りに定義される：０（インター予測なし）、１（リスト０に基づくインター予測）、２（リスト１に基づくインター予測）、および３（リスト０とリスト１との両方に基づくインター予測）。

[0115] 代わりとして、上で説明された動きベクトルスケーリングのためのターゲット参照ピクチャに関する決定と同様に、多数決原理が、全ての利用可能な隣接ブロックの動き情報に基づいて、所与のサブＰＵについてのInterDirの値を決定するために使用され得る。

[0116] InterDirが決定された後、動きベクトルが導出され得る。導出されたInterDirに基づく各参照リストについて、上で説明されたように、ターゲット参照ピクチャに対する動きベクトルスケーリングを通じて利用可能なＭ（Ｍ＜＝Ｎ）個の動きベクトルが存在し得る。参照リストについての動きベクトルは、以下の通りに導出され得る：

ここで、ｗ_iおよびｗ_jは、水平および垂直動き成分それぞれについての重み係数（weighting factors）であり、Ｏ_iおよびＯ_jは、重み係数に依存するオフセット値である。

[0117] 重み係数は、様々な係数に基づいて決定され得る。一例では、同じ規則が１つのＰＵ内の全てのサブＰＵに適用され得る。規則は以下の通りに定義され得る。

[0118] たとえば、重み係数は、現在のサブＰＵと対応する隣接ブロックとのロケーション距離に基づいて決定され得る。

[0119] 別の例では、重み係数はまた、ターゲット参照ピクチャと、スケーリング前の対応する隣接ブロックの動きベクトルに関連付けられた参照ピクチャとの間のＰＯＣ距離に基づいても決定され得る。

[0120] また別の例では、重み係数は、動きベクトルの差分または一貫性に基づいて決定され得る。

[0121] 簡略さのために、全ての重み係数が、１に設定されることもあり得る。

[0122] 代わりとして、異なる規則が１つのＰＵ内のサブＰＵに適用され得る。たとえば、上記規則が適用され得、それに加えて、第１の行／第１のカラムに位置するサブＰＵについて、時間的隣接ブロックから導出された動きベクトルについての重み係数が０に設定され、残りのブロックについては、空間的隣接ブロックから導出された動きベクトルについての重み係数が０に設定される。

[0123] 実際、上記数式は、そのまま実施され（implemented）得るか、または簡単な実施のために簡略化され得ることに留意されたい。たとえば、除算または浮動小数点演算を避けるために、固定小数点演算が、上記数式を近似するために使用され得る。一例は、３による除算を避けるために、代わりに、除算演算を乗算およびビットシフトで置き換えるために、４３／１２８で乗算することを選び得る。それらの実施（implementation）のバリエーションが、本開示の技法と同じ趣旨の下でカバーされると見なされるべきである。

[0124] 代わりとして、メジアンフィルター（median filter）のような非線形演算もまた、動きベクトルを導出するために適用され得る。

[0125] いくつかの例では、各サブＰＵの動きベクトル予測子が利用可能であるときでさえ、ＳＴＭＶＰモードがリセットされ、１つのＰＵについて利用可能でなくなり得る。

[0126] たとえば、一度各サブＰＵの動きベクトル予測子が所与のＰＵについて導出されると、ＳＴＭＶＰモードが該所与のＰＵについて利用可能にされるべきであるかどうかを決定するために、いくつかの利用可能性検査が実行される。そのような演算は、ＳＴＭＶＰモードが所与のＰＵについて最終的に選ばれる可能性が非常に低いケースを排除するために使用される。ＳＴＭＶＰモードが利用可能でないとき、モードシグナリングはＳＴＭＶＰを含まない。ＳＴＭＶＰをマージリストに挿入することによってＳＴＭＶＰモードが実装されるケースでは、ＳＴＭＶＰモードが利用可能でないと決定されるとき、マージリストは、このＳＴＭＶＰ候補を含まない。結果として、シグナリングオーバーヘッドは低減され得る。

[0127] Ｍ個のサブＰＵに分割される１つのＰＵを検討する。一例では、Ｍ個のサブＰＵのうちのＮ１（Ｎ１＜＝Ｍ）個のサブＰＵが同じ動きベクトル予測子（即ち、同じ動きベクトルおよび同じ参照ピクチャインデックス）を有する場合、Ｎ１がしきい値よりも小さいか、または該予測子が、マージリスト中の（より小さいマージインデックスをもつ）他の動きベクトル予測子とは異なるときにのみ、ＳＴＭＶＰは利用可能にされる。別の例では、ＳＴＭＶＰモード下のＮ２（Ｎ２＜＝Ｍ）個のサブＰＵが、ＡＴＭＶＰ下の対応するサブＰＵと同じ動きベクトル予測子を共有する場合、Ｎ２が別のしきい値よりも小さいときにのみ、ＳＴＭＶＰは利用にされる。

[0128] 本開示の一例では、Ｎ１についてのしきい値とＮ２についてのしきい値との両方とも、Ｍに等しく設定される。

[0129] いくつかの例では、ＳＴＭＶＰが利用可能である場合、それはマージリストに挿入される。上記箇条書き１．におけるプロセスが拡張され得、ＳＴＭＶＰがＡＴＭＶＰの前またはＡＴＭＶＰの後のどちらかで挿入され得る。一例では、ＳＴＭＶＰは、ＡＴＭＶＰの直後に、マージリストに挿入される。

[0130] シンタックス要素が、ＣＡＢＡＣ（context adaptive binary arithmetic coding）でコーディングされるとき、コンテキストモデルが、条件付き確率を表すために適用される。ＨＥＶＣでは、ＣＡＢＡＣコーダは、異なるシンタックス要素について異なるコンテキストモデルを決定する。ＣＡＢＡＣコーダは、いくつかの例では、復号された隣接ブロックのビン数または情報のようなコーディングコンテキストに基づいて、シンタックス要素のために、いくつかの候補のコンテキストモデルから１つのコンテキストモデルを選び得る。たとえば、skip_flag_C[0]、skip_flag_C[1]、およびskip_flag_C[2]という名称の３つの候補のコンテキストモデルが、１つのＣＵがスキップモードでコーディングされるか否かを示すシンタックス要素cu_skip_flagをコーディングするために使用され得る。
[0131] ３つの候補から適切なコンテキストを選ぶために、ＣＡＢＡＣコーダがコンテキストインデックスｘを以下の通りに計算し得る：
x=(cu_skip_flag[xNbL][yNbL] && availableL)+(cu_skip_flag[xNbA][yNbA] &&
availableA)
ここにおいて、ルーマロケーション（ｘ０，ｙ０）は、現在のピクチャの左上のサンプルに対する現在のルーマブロックの左上のルーマサンプルを指定し、ロケーション（ｘＮｂＬ，ｙＮｂＬ）は、（ｘ０-１，ｙ０）に等しく設定され、変数availableLは、現在ブロックのすぐ左に位置するブロック、即ち図１０におけるブロックＬの利用可能性を指定し、ロケーション（ｘＮｂＡ，ｙＮｂＡ）は、（ｘ０，ｙ０-１）に等しく設定され、変数availableAは、現在ブロックの真上に位置するコーディングブロック、即ち図１０におけるブロックＡの利用可能性を指定し、cu_skip_flag[xNbL][yNbL］およびcu_skip_flag[xNbA][yNbA]は、図１０における左ブロックＬおよび上ブロックＡのcu_skip_flagをそれぞれ表す。cu_skip_flagのコンテキスト情報を導出するために使用される隣接ブロックが図１０で例示される。

[0132] 上で説明されたように、多くの優先度ベースの候補リストが存在する。各候補は、予め定義された優先度にしたがって候補リストに挿入される。たとえば、ＨＥＶＣでは、マージ候補リスト、ＡＭＶＰ候補リスト、イントラＭＰＭ（most probable mode）リストが、予め定義された順序に基づいて（または予め定義された優先度にしたがって）候補を挿入することによって構築される。図１１で示されるように、マージ候補リストは、予め定義された順序（Ａ１→Ｂ１→Ｂ０→Ａ０→Ｂ２）で空間的マージ候補を挿入することによって構築される。そのような固定の順序は、局所的な特性をキャプチャできないことがある。選択される可能性がより高い候補を他の候補よりも前に置くことによってフレキシブルな順序が適用され得る場合、より高いコーディングパフォーマンスが期待され得る。

[0133] 本開示の技法では、マージ候補リスト、ＡＭＶＰリスト、およびイントラＭＰＭリストのような候補リストの構築のための優先度または挿入順序を決定するために、現在ブロックと隣接ブロックとの間でジオメトリ情報が使用され得る。さらに、このジオメトリ情報は、ＣＡＢＡＣコーディングのためのコンテキストの決定にも使用され得る。

[0134] 以下の箇条書きにされた方法が個別に適用され得る。代わりとして、それらの任意の組合せも適用され得る。

[0135] （１）一例では、現在ブロックの代表点と、候補が属する隣接ブロックの代表点との間の距離が、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。ここで使用される「ブロック」（たとえば、図１２におけるブロック０〜ブロック４および現在ブロック）という用語は、コーディングユニット／ブロック、予測ユニット／ブロック、サブＰＵ、変換ユニット／ブロック、または任意の他のコーディング構造でもあり得る。さらに、ユニットブロックは、動き情報（動きベクトル、参照ピクチャインデックス、インター予測方向等）、イントラ予測モード、変換情報等といったコーディング情報を記憶するための基本ユニットである。たとえば、このユニットブロックのサイズは４ｘ４であり得る。図１２で示されているように、候補Ａ０、Ａ１、Ｂ０、Ｂ１、およびＢ２が、隣接ブロックのブロック０、ブロック１、ブロック２、ブロック３、およびブロック４によってそれぞれカバーされているユニットブロックから導出される。

ａ．一例では、候補の代表点と現在の代表点との間の距離がより短いと、より高い優先度を有し、またはその逆も同様である。

ｂ．一例では、該距離は、ＬＮノルム距離であり得る（Ｎは、１、２、または任意の他の正の整数であり得る）。

[0136] （２）項目１では、現在ブロックの代表点は、現在ブロック内の任意の点でもあり得る。一例では、図１２で示されているように、現在ブロックの代表点は、現在ブロックの中央点である。図１２は、空間的マージ候補のジオメトリ情報の例である。

[0137] （３）項目１では、隣接ブロックの代表点は、隣接ブロック内の任意の点でもあり得る。一例では、図１２で示されているように、隣接ブロックの代表点は、隣接ブロックの中央点である。

[0138] （４）代わりとして、図１３で示されているように、隣接ブロックの代表点は、隣接ブロックによってカバーされたサブＰＵの中央点である。たとえば、隣接ブロックが、ＦＲＵＣ、Ａｆｆｉｎｅ、ＡＴＭＶＰといったサブＰＵモードとしてコーディングされる場合、そのサブＰＵの中央点は、そのブロックについての代表点として使用される。図１３は、空間的マージ候補のジオメトリ情報の例を例示する。図１３で示されているように、ブロック１がサブＰＵモードとしてコーディングされるため、候補Ａ１が属するサブＰＵの代表点が、ジオメトリ優先度を導出するために使用される。

[0139] （５）加えて、または代わりとして、代表点は、ＭＶ、参照ピクチャ情報、イントラモード、変換係数、残差情報等といったコーディング情報にしたがって適応的に決定される隣接ブロックまたは現在ブロック内の任意の点でもあり得る。

ａ．一例では、イントラモード候補リストを構築するために、中央点が、ブロック内の左上点で置き換えられ得る。

[0140] （６）上で言及された方法は、個々に、または他の優先度の任意の組合せで、候補リストを構築するための優先度を決定するために適用され得る。

ａ．一例では、２つ以上の候補が同じジオメトリ優先度（たとえば、代表点間で同じ距離）を有するとき、予め定義された優先度が、それらを区別するために使用され得る。たとえば、挿入順序（Ａ１→Ｂ１→Ｂ０→Ａ０→Ｂ２）が使用され得る。

ｂ．代わりとして、他の優先度は、インター予測方向（たとえば、Ｌ０、Ｌ１、または双方向）、ＭＶ、イントラ予測モード、参照ピクチャのＰＯＣ等といったコーディング情報であり得る。

[0141] （７）上で言及された方法は、ある特定のブロックに適用され得る。

ａ．一例では、上記方法は、異なる幅および高さのブロックに適用される。

ｂ．代わりとして、上記方法は、幅と高さの比がＫよりも大きい、または１／Ｋよりも小さいブロックに適用され、ここにおいて、Ｋは、正の整数値であり、１よりも大きい。

ｃ．代わりとして、上記方法は、ある特定のサイズのブロックに適用される。

[0142] （８）上で言及された方法は、候補のうちのいくつかに部分的に適用され得る。

ａ．一例では、ジオメトリ情報は、空間的マージ／イントラモード候補、即ち空間的隣接ブロックから導出された候補、の順序を決定するためにのみ使用される。

ｂ．一例では、ジオメトリ情報は、ペアにされた候補（Ａ１，Ｂ１）の順序を決定するためにのみ使用される。

ｂ．一例では、ジオメトリ情報は、ペアにされた候補（Ａ０，Ｂ０）の順序を決定するためにのみ使用される。

[0143] （９）ジオメトリベースの優先度を使用すべきかどうかは、ビットストリーム中でシグナリングされ得る。

ａ．一例では、コーディングユニット／予測ユニット／変換ユニットについて、ジオメトリベースの優先度が使用されるべきか、または予め定義された優先度リストが使用されるべきか、を示すために、フラグがシグナリングされ得る。

[0144] （１０）マージ候補リストの順序が、ジオメトリベースの優先度にしたがって修正されるとき、再順序づけ後の最初の候補が、ＡＴＭＶＰおよび／またはＳＴＭＶＰプロセスについての第１段階において使用される。

ａ．代わりとして、予め定義された順序から導出された最初の候補が、ＡＴＭＶＰおよび／またはＳＴＭＶＰプロセスについての第１段階において使用される。

[0145] （１１）ジオメトリ情報は、隣接ブロックからの情報が利用されるときに、ＣＡＢＡＣコーディングのためのコンテキストの決定のために使用され得る。

ａ．一例では、（図１０で示されているＬのような）左ブロック、および（図１０で示されているＡのような）上ブロックに加えて、図１１で示されているようなＡ０、Ａ１、Ｂ０、Ｂ１、およびＢ２（図１０におけるＡと同じ）といったより多くの隣接ブロックが、現在ブロックのcu_skip_flagのコンテキストを導出するために使用される。

ｂ．複数の隣接ブロック（Ｍで総数を示す）が、コンテキストモデル化のために利用されるとき、ジオメトリ優先度に基づく最初のＮ個のブロックからの情報のみが考慮される。ここで、ＮはＭよりも小さい。一例では、Ｎは２に設定され、Ｍは５に設定される。

ｃ．代わりとして、さらに、限定されないが、cu_transquant_bypass_flag、cu_skip_flag、cbf、pred_mode_flag、rqt_root_cbf、merge_idx、merge_flag、cbf_luma、cbf_cb、cbf_crを含む他のシンタックス要素のコンテキストモデル化（context modeling）もまた、上記方法を使用し得る。

ｄ．一例では、上記方法は、ある特定のブロックに適用され得、たとえば、ブロックの幅および高さが異なるか、あるいは幅と高さの比がしきい値よりも大きいか、またはある特定のサイズのブロックに適用される。

ｅ．一例では、ＣＡＢＡＣコンテキストは、関連する重み係数によってスケーリングされた隣接ブロックのコーディング情報によって決定される。関連する重み係数は、ジオメトリ情報を用いて導出される。たとえば、スキップフラグをコーディングするためのコンテキストを選択するとき、ｘは、以下の数式によって導出され得る。

x=WL*(cu_skip_flag[xNbL][yNbL]&&availableL)+WA(cu_skip_flag[xNbA][yNbA]&&availableA)
ＷＬおよびＷＡは、それぞれ、左および上の隣接ブロックについての関連する重み係数である。ＷＬおよびＷＡは、それらのジオメトリ情報にしたがって導出され得る。一例では、隣接ブロックと現在ブロックとの代表点間の距離が、予め定義されたしきい値よりも大きいとき、関連する重み係数は、値Ｍに設定され、そうでなければ（該距離が予め定義されたしきい値以下であるとき）、関連する重み係数は、値Ｎに設定される。

ｆ．項目１１．ｅにおいて、隣接ブロックは、ＨＥＶＣで使用される左および上ブロックに限定されない。隣接ブロックは、前にコーディングされたブロックのうちの任意の１つであり得る。

ｇ．項目１１．ｅにおいて、より多くの値が、より多くのしきい値を導入することによって、重み係数について割り当てられ得る。

[0146] （１２）別の例では、隣接ブロックのジオメトリ情報は、マージ候補リスト、ＡＭＶＰリスト、およびイントラＭＰＭリストのような候補リストの構築のための優先度または挿入順序を決定するために使用され得る。さらに、このジオメトリ情報は、ＣＡＢＡＣコーディングのためのコンテキストの決定に使用され得る。

[0147] （１３）一例では、候補が属する隣接ブロックのエリアが、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。ここで使用されている「ブロック」という用語は、コーディングユニット／ブロック、予測ユニット／ブロック、サブＰＵ、変換ユニット／ブロック、または任意の他のコーディング構造でもあり得る。より小さいエリアをもつブロックは、より高い優先度を持ち、逆もまた同様である。

[0148] （１４）エリアベースのジオメトリ情報は、項目６〜１１で説明されたような上述の方法と同じように適用され得る。

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

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

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

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

[0153] 図１４の例では、ソースデバイス１２は、ビデオソース１８、ビデオエンコーダ２０、および出力インターフェース２２を含む。宛先デバイス１４は、入力インターフェース２８、ビデオデコーダ３０、およびディスプレイデバイス３２を含む。本開示にしたがうと、ソースデバイス１２のビデオエンコーダ２０および宛先デバイス１４のビデオデコーダ３０は、動きベクトル予測のための本開示の候補リスト構築技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは配置を含み得る。たとえば、ソースデバイス１２は、外部のカメラのような外部のビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、統合されたディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェース接続し得る。

[0154] 図１４の例示されているシステム１０は一例に過ぎない。動きベクトル予測のための本開示の技法は、何れのデジタルビデオ符号化および／または復号デバイスによっても実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスによって実行されるけれども、本技法は、通常「ＣＯＤＥＣ」と称されるビデオエンコーダ／デコーダによっても実行され得る。さらに本開示の技法はまた、ビデオプレプロセッサによっても実行され得る。ソースデバイス１２および宛先デバイス１４は単に、ソースデバイス１２が宛先デバイス１４への送信のためのコーディングされたビデオデータを生成するようなコーディングデバイスの例に過ぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化および復号コンポーネントを含むような実質的に対称的な形で動作し得る。したがってシステム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス１２とビデオデバイス１４との間の一方向または二方向ビデオ送信をサポートし得る。

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

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

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

[0158] ビデオエンコーダ２０およびビデオデコーダ３０は、高効率ビデオコーディング（ＨＥＶＣ）規格、ＨＥＶＣ規格の拡張版、またはＩＴＵ−ＴＨ．２６６のような後続する規格のような、ビデオコーディング規格にしたがって動作し得る。代わりとして、ビデオエンコーダ２０およびビデオデコーダ３０は、ＭＰＥＧ―４、Ｐａｒｔ１０、アドバンスドビデオコーディング（ＡＶＣ）、またはそのような規格の拡張版と代わりに称される、ＩＴＵ−ＴＨ．２６４規格のような他の専有または工業規格にしたがって動作し得る。しかしながら本開示の技法は、何れの特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、ＭＰＥＧ−２およびＩＴＵ−ＴＨ．２６３を含む。図１４には示されていないけれども、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は各々、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリームにおけるオーディオとビデオとの両方の符号化を扱うのに適切なＭＵＸ−ＤＥＭＵＸユニットまたは他のハードウェアおよびソフトウェアを含み得る。適用可能である場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵＨ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルに準拠し得る。

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

[0160] ビデオコーディング規格は、ＩＴＵ−ＴＨ．２６１、ＩＳＯ／ＩＥＣＭＰＥＧ−１ビジュアル、ＩＴＵ−ＴＨ．２６２またはＩＳＯ／ＩＥＣＭＰＥＧ−２ビジュアル、ＩＴＵ−ＴＨ．２６３、ＩＳＯ／ＩＥＣＭＰＥＧ−４ビジュアル、および（ＩＳＯ／ＩＥＣＭＰＥＧ−４ＡＶＣとしても知られている）ＩＴＵ−ＴＨ．２６４を含み、そのＳＶＣ（Scalable Video Coding）およびＭＶＣ（MultiView Video Coding）拡張版も含む。ＭＶＣの１つの共同ドラフトは、２０１０年３月付のＩＴＵ−Ｔ勧告Ｈ．２６４「Advanced video coding for generic audiovisual services」で説明されている。

[0161] 加えて、新たに開発されたビデオコーディング規格、即ちＩＴＵ−Ｔビデオコーディング専門家グループ（ＶＣＥＧ）およびＩＳＯ／ＩＥＣ動画専門家グループ（ＭＰＥＧ）のビデオコーディングに関する共同チーム（ＪＣＴ−ＶＣ）よって開発された高効率ビデオコーディング（ＨＥＶＣ）が存在する。ＨＥＶＣの最新のドラフトは、phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zipから利用可能である。ＨＥＶＣ規格はまた、勧告ＩＴＵ−ＴＨ．２６５および国際規格ＩＳＯ／ＩＥＣ２３００８−２においても共同で提示されており、この両方が「High efficiency video coding」と題し、またこの両方が、２０１４年１０月付で公表されている。

[0162] ＪＣＴ−ＶＣは、ＨＥＶＣ規格を開発した。ＨＥＶＣ標準化の試みは、ＨＥＶＣテストモデル（ＨＭ）と称されるビデオコーディングデバイスの発展型モデルに基づく。ＨＭは、たとえば、ＩＴＵ−ＴＨ．２６４／ＡＶＣにしたがった既存のデバイスと比較して、ビデオコーディングデバイスのいくつかの追加の能力を想定する。たとえば、Ｈ．２６４が９個のイントラ予測符号化モードを提供するのに対し、ＨＥＶＣＨＭは、３３個程に多くのイントラ予測符号化モードを提供し得る。

[0163] 一般に、ＨＭの作業モデル（working model）は、ビデオフレームまたはピクチャがルーマサンプルとクロマサンプルとの両方を含む、ツリーブロックのシーケンス、または、最大符号化ユニット（ＬＣＵ）に分割され得ることを記述する。ビットストリーム内のシンタックスデータは、ピクセル数の観点で最大の符号化ユニットであるＬＣＵのサイズを定義し得る。スライスは、いくつかの連続するツリーブロックをコーディング順序で含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに分割され得る。各ツリーブロックは四分木にしたがってコーディングユニット（ＣＵ）に分けられ得る。一般に、四分木データ構造は、ＣＵ毎の１つのノードを含み、ツリーブロックに対応する１つのルートノードをもつ。ＣＵが４つのサブＣＵに分けられる場合、ＣＵに対応するノードは４つのリーフノードを含み、その各々がサブＣＵのうちの１つに対応する。

[0164] 四分木データ構造の各ノードは、対応するＣＵにシンタックスデータを提供し得る。たとえば、四分木におけるノードは、ノードに対応するＣＵがサブＣＵに分けられるかどうかを示す、分割フラグ（split flag）を含み得る。ＣＵについてのシンタックス要素は再帰的に定義され得、ＣＵが複数のサブＣＵに分けられるかどうかに依存し得る。ＣＵがこれ以上分けられない場合、それはリーフＣＵと称される。本開示では、リーフＣＵの４つのサブＣＵもまた、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵと称されることになる。たとえば、１６ｘ１６のサイズのＣＵがこれ以上分けられない場合、４つの８ｘ８のサブＣＵもまた、１６ｘ１６のＣＵが全く分けられなかったといえども、リーフＣＵと称されることになる。

[0165] ＣＵは、ＣＵがサイズの区別（a size distinction）を有さない点を除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは４つの子ノード（サブＣＵとも称される）に分けられ得、各子ノードは、今度は親ノードになり、別の４つの子ノードに分けられ得る。四分木のリーフノードと称される最後の分割されない子ノードは、リーフＣＵとも称されるコーディングノードを備える。コーディングされたビットストリームに関連付けられたシンタックスデータは、最大ＣＵ深度と称される、ツリーブロックが分けられ得る最大回数を定義し得、またコーディングノードの最小サイズも定義し得る。したがって、ビットストリームはまた、最小コーディングユニット（ＳＣＵ）も定義し得る。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵの何れも指すように、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるそのマクロブロックおよびサブブロック）を指すように、「ブロック」という用語を使用する。

[0166] ＣＵは、コーディングノード、ならびに該コーディングノードに関連付けられた予測ユニット（ＰＵ）および変換ユニット（ＴＵ）を含む。ＣＵのサイズはコーディングノードのサイズに対応し、形状が正方形（square）でなければならない。ＣＵのサイズは、８ｘ８ピクセルから、最大６４ｘ６４ピクセルまたはそれより大きいツリーブロックのサイズまでの範囲に及び得る。各ＣＵは、１つまたは複数のＰＵ、および１つまたは複数のＴＵを保有し得る。ＣＵに関連付けられたシンタックスデータは、たとえば、ＣＵの１つまたは複数のＰＵへの分割を記述し得る。分割モードは、ＣＵが、スキップまたはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、インター予測モード符号化されるかで異なり得る。ＰＵは、形状が非正方形（non-square）になるように分割され得る。ＣＵに関連付けられたシンタックスデータはまた、たとえば、四分木にしたがったＣＵの１つまたは複数のＴＵへの分割を記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、長方形（rectangular））であり得る。

[0167] ＨＥＶＣ規格は、異なるＣＵでは異なり得る、ＴＵにしたがった変換を許容する。ＴＵは通常、分割されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ化されるが、常にこれが起こり得るわけではない。ＴＵは通常、ＰＵと同じサイズであるかそれより小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差四分木」（ＲＱＴ：residual quad tree）として知られる四分木構造を使用してより小さいユニットにさらに分割され（subdivided）得る。ＲＱＴのリーフノードは、変換ユニット（ＴＵ）と称され得る。ＴＵに関連付けられたピクセル差分値は、変換係数を作り出すために変換され得、変換係数は量子化され得る。

[0168] リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。一般に、ＰＵは、対応するＣＵの全てまたは一部分に対応する空間エリアを表し、該ＰＵについての参照サンプルを検索するためのデータを含み得る。さらにＰＵは、予測に関連するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵについてのデータは残差四分木（ＲＱＴ）に含まれ得、それは、ＰＵに対応するＴＵのためのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵについての１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵについての動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度（たとえば、４分の１ピクセル精度または８分の１ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルについての参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）を記述し得る。

[0169] 現在ブロックと隣接ブロックとの間のジオメトリ情報は、動きベクトルについての参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）の構築のための優先度または挿入順序を決定し得る。ジオメトリ情報は、現在ブロックの代表点（たとえば中央点）と、候補が属する隣接ブロックの代表点との間の距離を含み得る。その代表点と現在ブロックの代表点との間でより短い距離をもつ隣接ブロックに対し、より高い優先度が示され得る。代表点は、ブロック内の何れの点（たとえば中央点）でもあり得る。

[0170] １つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）も含み得る。変換ユニットは、上で説明されたように、ＲＱＴ（ＴＵ四分木構造とも称される）を使用して指定され得る。たとえば、分割フラグ（split flag）は、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。その後、各変換ユニットが、さらなるサブＴＵにさらに分けられ得る。ＴＵがこれ以上分けられないとき、それはリーフＴＵと称され得る。一般に、イントラコーディングでは、１つのリーフＣＵに属する全てのリーフＴＵが、同じイントラ予測モードを共有する。つまり一般に、１つのリーフＣＵの全てのＴＵについて予測される値を計算するために同じイントラ予測モードが適用される。イントラコーディングでは、ビデオエンコーダは、各リーフＴＵについての残差値を、イントラ予測モードを使用して、ＴＵに対応するＣＵの一部分と元のブロックとの間の差分として、計算し得る。１つのＴＵは、１つのＰＵのサイズに限定される必要はない。したがって、ＴＵは、ＰＵより大きいことも小さいこともある。イントラコーディングでは、ＰＵは、同じＣＵについての対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。

[0171] さらに、リーフＣＵのＴＵはまた、残差四分木（ＲＱＴ）と称される、それぞれの四分木データ構造とも関連付けられ得る。つまりリーフＣＵは、リーフＣＵがどのようにＴＵに分割されるかを示す四分木を含み得る。ＴＵ四分木のルートノードは一般に、リーフＣＵに対応するのに対し、ＣＵ四分木のルートノードは一般に、ツリーブロック（またはＬＣＵ）に対応する。分けられないＲＱＴのＴＵは、リーフＴＵと称される。一般に、本開示は、そうではないと注釈されない限り、リーフＣＵおよびリーフＴＵそれぞれを指すためにＣＵおよびＴＵという用語を使用する。

[0172] ビデオシーケンスは通常、一連のビデオフレームまたはピクチャを含む。ピクチャのグループ（ＧＯＰ：group of picture）は一般に、一連の１つまたは複数のビデオピクチャを備える。ＧＯＰは、ＧＯＰのヘッダ、1つまたは複数のピクチャのヘッダ、またはその他の場所に、当該ＧＯＰに含まれるいくつかのピクチャ（a number of pictures）を記述するシンタックスデータを含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対してオペレートする。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定か、または変動するサイズを有し得、指定されたコーディング規格にしたがってサイズが異なり得る。

[0173] 例として、ＨＭは、様々なＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎｘ２Ｎであることを前提とすると、ＨＭは、２Ｎｘ２ＮまたはＮｘＮのＰＵサイズにおけるイントラ予測、および２Ｎｘ２Ｎ、２ＮｘＮ、Ｎｘ２Ｎ、またはＮｘＮの対称ＰＵサイズにおけるインター予測をサポートする。ＨＭはまた、２ＮｘｎＵ、２ＮｘｎＤ、ｎＬｘ２Ｎ、およびｎＲｘ２ＮのＰＵサイズにおけるインター予測のための非対称分割をサポートする。非対称分割では、ＣＵの一方向は分割されないが、他の方向は２５％および７５％に分割される。２５％区分に対応するＣＵの一部分は、「ｎ」と、その後に続く「Ｕｐ（上）」、「Ｄｏｗｎ（下）」、「Ｌｅｆｔ（左）」、または「Ｒｉｇｈｔ（右）」のインジケーションとによって示される。したがって、たとえば、「２ＮｘｎＵ」は、上に２Ｎｘ０．５ＮのＰＵと、下に２Ｎｘ１．５ＮのＰＵとに、水平に分割される２Ｎｘ２ＮのＣＵを指す。

[0174] 一般に、イントラ予測は、ブロックを、（同じピクチャ内の）当該ブロックに対して隣接する前にコーディングされたピクセルを使用して、予測することを伴う。水平、垂直、および様々な対角モードといった様々なイントラ予測モード、ならびにＤＣおよび平面（planar）モードが使用され得る。さらに、ある特定のモードが、隣接ブロックをイントラ予測するために使用されるイントラ予測モードに基づいて、「最も可能性のある（most probable）」と見なされ得る。本開示の技法にしたがうと、ビデオエンコーダ２０およびビデオデコーダ３０は、現在ブロックに対する隣接ブロックを候補として含むＭＰＭ（most probable mode）リストを、上で説明されたように、たとえば現在ブロックおよび隣接ブロックについてのジオメトリ情報にしたがってＭＰＭリスト内の候補が順序付けされる形で構築し得る。

[0175] 本開示では、「ＮｘＮ」および「Ｎ×Ｎ（N by N）」は、垂直次元および水平次元の観点からビデオブロックのピクセル次元、たとえば、１６ｘ１６ピクセルまたは１６×１６（16 by 16）ピクセルを指すように、交換可能に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）、および水平方向に１６ピクセル（ｘ＝１６）を有することになる。同様に、ＮｘＮブロックは一般に、垂直方向にＮピクセル、および水平方向にＮピクセルを有し、ここで、Ｎは負でない整数の値を表す。ブロックにおけるピクセルは、行と列に配置され得る。さらに、ブロックは、垂直方向と同じ数のピクセルを水平方向に必ずしも有する必要はない。たとえば、ブロックは、Ｎ×Ｍピクセルを備え得るが、Ｍは必ずしもＮと等しいわけではない。

[0176] ＣＵのＰＵを使用するイントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ２０は、ＣＵのＴＵについての残差データを計算し得る。ＰＵは、空間ドメイン（ピクセルドメインとも称される）において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え、ＴＵは、変換、たとえば離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または残差ビデオデータに対する概念的に類似する変換の適用にしたがう変換ドメインにおける係数を備え得る。残差データは、ＰＵに対応する予測値と符号化されていないピクチャのピクセルとの間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵについての残差データを含むＴＵを形成し、その後、ＣＵについての変換係数を作り出すためにＴＵを変換し得る。

[0177] 変換係数を作り出すための任意の変換に続いて、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量を出来る限り減少させるために、変換係数が量子化されるプロセスを指し、さらなる圧縮を提供する。量子化プロセスは、係数のいくつかまたは全てに関連付けられたビット深度を低減し得る。たとえば、ｎビット値は量子化中にｍビット値に丸められ得、ここにおいて、ｎはｍよりも大きい。

[0178] 量子化にしたがうと、ビデオエンコーダは変換係数を走査して、量子化された変換係数を含む２次元行列から１次元ベクトルを作り出し得る。走査は、より高いエネルギー（ひいては、より低い周波数）係数をアレイの前方に置き、より低いエネルギー（ひいては、より高い周波数）係数をアレイの後方に置くように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化されることができる直列にされたベクトルを生成するために、量子化された変換係数を走査するのに予め定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は、適応走査を実行し得る。１次元ベクトルを形成するために量子化された変換係数を走査した後に、ビデオエンコーダ２０は、たとえばＣＡＶＬＣ（context adaptive variable length coding）、ＣＡＢＡＣ（context adaptive binary arithmetic coding）、ＳＢＡＣ（syntax-based context-adaptive binary arithmetic coding）、ＰＩＰＥ（Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法にしたがって、当該１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０によって使用される、符号化されたビデオデータに関連付けられたシンタックス要素をエントロピー符号化し得る。

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

[0180] 図１５は、ジオメトリベースの優先度リストについての本開示の技法を実行するように構成され得るビデオエンコーダ２０の例を例示するブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または取り除くための空間予測に依存する。インターコーディングは、ビデオシーケンスの隣り合ったフレームまたはピクチャ内のビデオの時間的冗長性を低減または取り除くための時間予測に依存する。イントラ（Ｉ）モードは、いくつかの空間ベースのコーディングモードのうちの何れも指し得る。単一方向予測（Ｐモード）または双予測（Ｂモード）のようなインターモードは、いくつかの時間ベースのコーディングモードの何れも指し得る。

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

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

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

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

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

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

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

[0188] さらに、エントロピー符号化ユニット５６、または動き補償ユニット４４は、たとえばマージモードまたはＡＭＶＰモードを使用して動きベクトル予測を実行するとき、本開示の技法を適用し得る。特に、現在ブロックについての動きベクトルを予測するために使用される候補リスト（たとえば、マージ候補リストまたはＡＭＶＰ候補リスト）を構築するとき、エントロピー符号化ユニット５６または動き補償ユニット４４は、候補についての優先度値にしたがって候補リスト内に候補を配置し得、ここで、本開示で説明されているように、優先度値は、候補についてのジオメトリ情報を表し得る。ジオメトリ情報は、たとえば、現在ブロックと、該現在ブロックに対する隣接ブロック（空間的および／または時間的隣接ブロックを含み得る）との代表点間の距離であり得る。上で説明されたように、代表点は、ブロックの中央点、ブロックの左上点、または同様のものであり得る。エントロピー符号化ユニット５６または動き補償ユニット４４は、優先度値を計算するとき、本開示の様々な技法のうちの任意のものを、単独または任意の組合せで、使用し得る。

[0189] ビデオエンコーダ２０は、図１４に関係して上で説明され、および以下でより詳細に説明されることになるような、本開示の様々な技法の何れも実行するように構成され得る。たとえば、動き補償ユニット４４は、本開示の技法にしたがって、ＡＭＶＰまたはマージモードを使用して、ビデオデータのブロックについての動き情報をコーディングするように構成され得る。加えて、または代わりとして、イントラ予測ユニット４６は、本開示の技法にしたがってイントラ予測モードをコーディングするように構成され得る。加えて、または代わりとして、エントロピー符号化ユニット５６は、本開示の技法を使用してＣＡＢＡＣコーディングのためのコンテキスト情報を決定するように構成され得る。

[0190] たとえば、動き補償ユニット４４がマージモードを実行することを選ぶとすると、動き補償ユニット４４は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット４４は、特定の、予め定められた順序に基づいて、候補リストに候補を加え得る。動き補償ユニット４４はまた、上で説明されたように、追加の候補を加え、候補リストのプルーニングを実行し、候補リストに優先順位をつける。最終的には、モード選択ユニット４０が、候補のうちのどれが現在ブロックの動き情報を符号化するために使用されるべきかを決定し、選択された候補を表すマージインデックスを符号化し得る。

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

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

[0193] ブロックのためのイントラ予測モードを選択した後で、イントラ予測ユニット４６は、該ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット５６に提供し得る。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。上で説明されたように、イントラ予測ユニット４６および／またはエントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化するために本開示の技法を使用し得る。特に、エントロピー符号化ユニット５６は、ジオメトリ情報、たとえばブロックと隣接ブロックとの代表点間の距離に基づいて、該ブロックに対する隣接ブロックから１つまたは複数の最も可能性のあるモード（most probable mode）を決定し得る。エントロピー符号化ユニット５６はさらに、ブロックをイントラ予測するために使用されるイントラ予測モードが最も可能性のあるモード（most probable mode）のうちの１つであるか、または異なるモードであるかを示すデータをさらにエントロピー符号化し得、もし異なるモードの場合、最も可能性のあるモード（most probable mode）を除いてイントラ予測モードのリスト中へインデックスをエントロピー符号化し得る。

[0194] ビデオエンコーダ２０は、複数のイントラ予測モードインデックス表および（コードワードマッピング表とも称される）複数の修正されたイントラ予測モードインデックス表を含み得る送信されるビットストリーム構成データ中に、様々なブロックについての符号化コンテキストの定義、および該コンテキストの各々について使用すべき最も可能性のあるイントラ予測モードと、イントラ予測モードインデックス表と、修正されたイントラ予測モードインデックス表との指示を含め得る。

[0195] ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数のコンポーネントを表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念上同様の変換のような変換を、残差ブロックに適用し、残差変換係数値を備えるビデオブロックを作り出す。変換処理ユニット５２は、ＤＣＴと概念上同様である他の変換も実行し得る。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換もまた使用され得る。

[0196] 何れのケースでも、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを作り出す。変換は、残差情報を、ピクセル値ドメインから周波数ドメインのような変換ドメインへ転換する（convert）し得る。変換処理ユニット５２は、結果として得た変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数のいくつかまたは全てに関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４はその後、量子化された変換係数を含む行列の走査を実行し得る。代わりとして、エントロピー符号化ユニット５６が走査を実行し得る。

[0197] 量子化に続いて、エントロピー符号化ユニット５６は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、ＣＡＶＬＣ（context adaptive variable length coding）、ＣＡＢＡＣ（context adaptive binary arithmetic coding）、ＳＢＡＣ（syntax-based context-adaptive binary arithmetic coding）、ＰＩＰＥ（probability interval partitioning entropy）コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストベースのエントロピーコーディングのケースでは、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス（たとえばビデオデコーダ３０）に送信され得るか、または後の送信または検索のためにアーカイブされ得る。

[0198] エントロピー符号化ユニット５６は、ＣＡＢＡＣコーディングのためのコンテキスト情報の決定に使用され得るジオメトリ情報を使用し得る。たとえば、ブロックのシンタックス要素についての値をＣＡＢＡＣコーディングするとき、エントロピー符号化ユニット５６は、当該ブロックに対し、ジオメトリ情報、たとえば、該ブロックと隣接ブロックとの代表点間の距離、に基づいて、コンテキスト情報を形成するために使用される情報が検索される１つまたは複数の隣接ブロックを決定し得る。いくつかの例では、エントロピー符号化ユニット５６は、上で説明されたように、ジオメトリ情報にしたがって、２つ以上の隣接ブロックからのデータの寄与に重み付けし得る。

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

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

[0201] 復号プロセス中、ビデオデコーダ３０は、ビデオエンコーダ２０からの符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化されたビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化された係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するために、ビットストリームをエントロピー復号する。いくつかの例では、エントロピー復号ユニット７０は、シンタックス要素の値をエントロピー復号するためのコンテキスト情報を決定するために、本開示の技法を使用し得る。たとえば、エントロピー復号ユニット７０は、現在ブロックについてのシンタックス要素の値をＣＡＢＡＣ復号するために使用されるべきコンテキスト情報を決定するために、ジオメトリ情報（たとえば、現在ブロックの代表点と隣接ブロックの代表点との間の距離）を使用して、１つまたは複数の隣接ブロック（および、いくつかの例では重み）を決定し得る。エントロピー復号ユニット７０は、動き補償ユニット７２に、動きベクトルおよび他のシンタックス要素を転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

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

[0203] 動き補償ユニット７２は、たとえばマージモードまたはＡＭＶＰモードを使用して動きベクトルを復号するときに、マージ候補リストまたはＡＭＶＰ候補リストといった候補リストの構築のための優先度または挿入順序を決定するために現在ブロックと隣接ブロックとの間のジオメトリ情報を使用して、候補リストを形成し得る。加えて、または代わりとして、イントラ予測ユニット７４は、最も可能性のあるモード（most probable mode）についての優先度または挿入順序を決定するために現在ブロックと隣接ブロックとの間のジオメトリ情報を使用して、イントラ予測のための１つまたは複数の最も可能性のあるモード（most probable mode）（ここで、最も可能性のあるモード（most probable mode）は１つの候補リストに対応する）を決定し得る。一例では、現在ブロックの代表点と隣接ブロックの代表点との間の距離が、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。一例では、その候補の代表点と現在の代表点との間の距離が短いほど、より優先度は高くなり、またはその逆も同様である。別の例では、該距離は、ＬＮノルム距離であり得る（Ｎは、１、２、または何れの他の正の整数でもあり得る）。

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

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

[0206] ビデオデコーダ３０は、図１４に関係して上で説明され、および以下でより詳細に説明されることになるような本開示の様々な技法の何れも実行するように構成され得る。たとえば、動き補償ユニット７２は、本開示の技法にしたがって、ＡＭＶＰまたはマージモードを使用して動きベクトル予測を実行すると決定するように構成され得る。エントロピー復号ユニット７０は、どのように動き情報が現在ブロックについてコーディングされるかを表す１つまたは複数のシンタックス要素を復号し得る。

[0207] マージモードが実行されるとシンタックス要素が示すことを前提とすると、動き補償ユニット７２は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット７２は、特定の予め定められた順序に基づいて、候補を候補リストに加え得る。動き補償ユニット７２はまた、上で説明されたように、追加の候補を加え、候補リストのプルーニングを実行し得る。最終的には、動き補償ユニット７２は、候補のうちのどれが現在ブロックについての動き情報をコーディングするために使用されるかを示すマージインデックスを復号し得る。

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

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

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

[0211] 図１７は、本開示の技法にしたがった、ビデオデータを符号化する例となる方法を例示するフローチャートである。例および説明の目的で、図１７の方法は、図１５のビデオエンコーダ２０によって実行されるものとして説明される。しかしながら、他のデバイスも、この方法または類似の方法を実行するように構成され得ることは理解されるべきである。

[0212] 最初に、ビデオエンコーダ２０は、符号化されるべき現在ブロックを受信する（３００）。モード選択ユニット４０はその後、現在ブロックを予測するために使用されるべき予測モードを決定する（３０２）。たとえば、モード選択ユニット４０は最初に、イントラ予測モードを使用すべきか、またはインター予測モードを使用すべきかを決定し得る。モード選択ユニット４０がイントラ予測を使用すると決定した場合、モード選択ユニット４０は、様々なイントラ予測モード（たとえば、方向性（directional）モード、ＤＣモード、平面モード、または同様のもの）のうちの、現在ブロックを予測するために使用されるべき１つをさらに決定し得る。モード選択ユニット４０がインター予測モードを使用すると決定した場合、動き推定ユニット４２は、現在ブロックの１つまたは複数の予測ユニット（ＰＵ）についての動きベクトルを決定するために動き探索を実行し得る。

[0213] 何れのケースでも、ビデオエンコーダ２０は、予測モードを使用して現在ブロックを予測し得る（３０４）。たとえば、インター予測モードでは、動き補償ユニット４４が、現在ブロックについての予測されたブロックを計算するために、動き推定ユニット４２によって決定された動きベクトルを使用し得る。別の例として、イントラ予測モードでは、イントラ予測ユニット４６が、決定されたイントラ予測モードにしたがって、現在ブロックに対する隣接ピクセルの値を使用して、予測されたブロックを生成し得る。

[0214] ビデオエンコーダ２０はその後、現在ブロックの代表点と、空間的および／または時間的隣接ブロックのような隣接ブロックの代表点との間の距離を決定し得る（３０６）。代表点は、たとえば、ブロックの中央点（たとえば図１２および図１３で示されている）、またはブロックの左上点のような他の代表点に対応し得る。隣接ブロックは、上で説明されたように、符号化ユニット、ＰＵ、またはサブＰＵに対応し得る。

[0215] ビデオエンコーダ２０はその後、決定された距離にしたがって、１つまたは複数の隣接ブロックからのデータを候補リストに加える（３０８）。たとえば、イントラ予測では、ビデオエンコーダ２０は、隣接ブロックからの１つまたは複数の最も可能性のあるイントラ予測モード（たとえば、最も短い距離を有する隣接ブロックを予測するために使用されるイントラ予測モード）のリストを決定し得、ここで、これらのブロックは、候補リストに含まれる候補と称され得る。別の例として、インター予測では、ビデオエンコーダ２０は、動きベクトルを符号化するためのマージモードまたはＡＭＶＰモードの候補リストを形成し得る。

[0216] 何れのケースでも、エントロピー符号化ユニット５６は、候補リストを使用して予測情報を符号化し得る（３１０）。たとえば、イントラ予測では、エントロピー符号化ユニット５６は、現在ブロックを予測するために、最も可能性のあるモード（most probable mode）が使用されるかどうか、および最も可能性のあるモード（most probable mode）のうちのどれが使用されるかを表すシンタックス要素を符号化し得る。最も可能性のあるモード（most probable mode）のうちのどれも、現在ブロックを予測するためには使用されない場合、エントロピー符号化ユニット５６はさらに、残りのセットのイントラ予測モードのうちののどれが、現在ブロックを予測するために使用されるかを表す情報を符号化し得る。別の例として、インター予測では、エントロピー符号化ユニット５６は、マージモードまたはＡＭＶＰモードにしたがって、動き情報を符号化し得る。たとえば、マージモードでは、エントロピー符号化ユニット５６は、候補リスト中へのインデックスをエントロピー符号化し得る。別の例として、ＡＭＶＰモードでは、エントロピー符号化ユニット５６は、候補リスト中へのインデックス、動きベクトル差分情報、参照ピクチャリスト識別子、および参照ピクチャリスト中へのインデックスをエントロピー符号化し得る。

[0217] ビデオエンコーダ２０はまた、現在ブロックについての残差ブロックを計算し得る（３１２）。つまり上で説明されたように、加算器５０が、残差ブロックを計算するために、予測されたブロックと元の現在ブロックとの間のピクセル毎の（pixel-by-pixel）差分を計算し得る。変換処理ユニット５２がその後、該残差ブロックのピクセル差分を、変換係数を作り出すためにピクセルドメイン（または空間ドメイン）から周波数ドメインに変換し得、量子化ユニット５４がその後、該変換係数を量子化し、それにより残差ブロックを変換および量子化し得る（３１４）。エントロピー符号化ユニット５６がその後、該量子化された変換係数をエントロピー符号化し得る（３１６）。

[0218] 図１７の例では示されていないけれども、ステップ３０６〜３１０のものと同様のステップを含む方法が、加えて、または代わりとして、ビデオデータの現在ブロックの１つまたは複数のシンタックス要素についての値をエントロピー符号化するためにエントロピー符号化ユニット５６によって使用され得る。そのようなシンタックス要素は、たとえば、コーディングユニットトランスクアント（coding unit transquant）バイパスフラグ、コーディングユニットスキップフラグ、コーディングブロック（coded block）フラグ、予測モードフラグ、残差四分木変換ルートコーディングブロック（residual quadtree transform root coded block）フラグ、マージインデックス、マージフラグ、ルミナンスブロックについてのコーディングブロック（coded block）フラグ、またはクロミナンスブロックについてのコーディングブロック（coded block）フラグのうちの何れかまたは全てを含み得る。一般にそのような方法は、ＣＡＢＡＣコーディングのためのコンテキスト情報を決定する目的で、隣接ブロックまでの距離を決定することを含み得る。エントロピー符号化ユニット５６は、最も確率が高いシンボルまたは最も確率の低いシンボルに等しい値を有する２値化された値のビットの確率を表すコンテキストモデルを初期化および／または更新するために、コンテキスト情報を使用し得る。
[0219] このように図１７の方法は、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに対する複数の隣接ブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングする（特にこの例では、符号化する）ことと、を含むビデオデータをコーディングする方法の例を表す。

[0220] 図１８は、本開示の技法したがった、ビデオデータを復号する例となる方法を例示するフローチャートである。例および説明の目的で、図１８の方法は、図１６のビデオデコーダ３０によって実行されるものとして説明される。しかしながら、他のデバイスも、この方法または類似の方法を実行するように構成され得ることは理解されるべきである。

[0221] 最初に、この例では、ビデオデコーダ３０は、復号されるべき現在ブロックを受信する（３３０）。現在ブロックは、たとえば、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ）、ＰＵに対応するＣＵの一部分、サブＰＵの集合、または同様のものであり得る。本開示の技法にしたがうと、ビデオデコーダ３０は、ジオメトリ情報、即ち、現在ブロックの代表点と、現在ブロックに対する隣接ブロックの代表点との間の距離、を決定する（３３２）。代表点は、たとえば、ブロックの中央、ブロックの左上の角（corner）、または同様のものであり得る。隣接ブロックは、いくつかの例では、ＰＵまたはサブＰＵであり得る。さらに、隣接ブロックは、空間的および／または時間的隣接であり得る。

[0222] ビデオデコーダ３０はその後、決定された距離にしたがって、隣接ブロックからのデータを候補リストに加える（３３４）。距離は一般に、候補リスト中のデータの順序付けのための優先度を表し得、ここで、より短い距離は一般に、より高い優先度を表し得る。上で説明されたように、候補リストは、現在ブロックがインター予測される場合は、動きベクトルのマージモードまたはＡＭＶＰモード復号の候補リストであり得、または、現在ブロックがイントラ予測される場合は、１つまたは複数の最も可能性のあるモード（most probable mode）のリストであり得る。ビデオデコーダ３０はまた、予測モード、たとえばインター予測またはイントラ予測のどちらかを決定し（３３８）、該予測モードにしたがい、予測リストを使用してブロックを予測する（３４０）。特に、予測モードがイントラ予測である場合、イントラ予測ユニット７４は、最も可能性のあるモード（most probable mode）のうちの１つが使用されることをデータが示すかどうかに基づいて、ブロックを予測するために使用されるべき実際のイントラモードを決定し、そうでない場合、実際の予測モードの識別子を決定する。一方で、予測モードがインター予測である場合、動き補償ユニット７２は、マージモードまたはＡＭＶＰモードにしたがって、現在ブロックについての動きベクトルを復号し、参照ピクチャメモリ８２からの動きベクトルによって識別されるデータを検索することによって、動きベクトルを使用して予測されたブロックを生成し得る。

[0223] 加えて、エントロピー復号ユニット７０は、現在ブロックの量子化された変換係数をエントロピー復号する（３４２）。逆量子化ユニット７６が、現在ブロックについての量子化された変換係数を逆量子化し、逆変換ユニット７８が、変換係数に逆変換を適用し、それにより、量子化された変換係数を逆量子化および逆変換し（３４４）、残差ブロックを作り出す。加算器８０がその後、現在ブロックを復号するために、ピクセル毎のベースで予測されたブロックの値を残差ブロックの値に加える（３４６）。

[0224] この場合もやはり、いくつかの例では、様々なシンタックス要素の値のエントロピー復号を実行するとき、ビデオデコーダ３０が図１８のステップ３３２〜３３６と同様のステップを含む方法を適用し得ることは理解されるべきである。そのようなシンタックス要素は、たとえば、コーディングユニットトランスクアント（transquant）バイパスフラグ、コーディングユニットスキップフラグ、コーディングブロックフラグ、予測モードフラグ、残差四分木変換ルートコーディングブロックフラグ、マージインデックス、マージフラグ、ルミナンスブロックについてのコーディングブロックフラグ、またはクロミナンスブロックについてのコーディングブロックフラグのうちの何れかまたは全てを含み得る。一般にそのような方法は、ＣＡＢＡＣコーディングのためのコンテキスト情報を決定する目的で、隣接ブロックまでの距離を決定することを含み得る。エントロピー復号ユニット７０は、最も確率が高いシンボルまたは最も確率の低いシンボルに等しい値を有する２値化された値のビットの確率を表すコンテキストモデルを初期化および／または更新するために、コンテキスト情報を使用し得る。

[0225] このように図１８の方法は、ビデオデータの現在ブロックの第１の代表点と、現在ブロックに対する複数の隣接ブロックの複数の第２の代表点との間の複数の距離を決定することと、第１の代表点と第２の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングする（特にこの例では、復号する）ことと、を含むビデオデータをコーディングする方法の例を表す。

[0226] 例に応じて、本明細書で説明されている技法のうちの何れの特定の動作またはイベントも、異なるシーケンスで実行されるか、加えられ得るか、マージされ得るか、または完全に除外され得る（たとえば、全ての説明されている動作またはイベントが技法の実施のために必要であるわけではない）ことは認識されるものとする。さらに、ある特定の例では、動作またはイベントは、たとえば、マルチスレッド処理、割り込み処理、または複数のプロセッサを通じて、シーケンシャルにではなく同時に実行され得る。

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

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

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

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

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

Claims

ビデオデータをコーディングする方法であって、
ビデオデータの現在ブロックの第１の代表点と、前記現在ブロックに隣接するブロックの複数の第２の代表点との間の複数の距離を決定することと、
前記第１の代表点と前記第２の代表点との間の前記距離にしたがった順序で、１つまたは複数の前記隣接するブロックを候補として前記現在ブロックの候補リストに加えることと、
前記候補リストを使用して前記現在ブロックをコーディングすることと、
備える方法。
前記候補リストは、マージ候補リスト、高度動きベクトル予測（ＡＭＶＰ）候補リスト、またはイントラＭＰＭ（most probable mode）リストのうちの１つを備える、請求項１に記載の方法。
前記候補リストは前記マージ候補リストを備え、前記現在ブロックをコーディングすることは、前記マージ候補リストの候補を使用して、マージモードにしたがって、前記現在ブロックについての動き情報をコーディングすることを備える、請求項２に記載の方法。
前記候補リストは前記ＡＭＶＰ候補リストを備え、前記現在ブロックをコーディングすることは、前記ＡＭＶＰ候補リストの候補を使用して、ＡＭＶＰモードにしたがって、前記現在ブロックについての動き情報をコーディングすることを備える、請求項２に記載の方法。
前記候補リストは前記イントラＭＰＭリストを備え、前記現在ブロックをコーディングすることは、前記イントラＭＰＭリストを使用して前記現在ブロックをイントラ予測するために使用されるイントラ予測モードのインジケーションをコーディングすることと、前記イントラ予測モードを使用して、前記現在ブロックをイントラ予測することと、を備える、請求項２に記載の方法。
前記隣接するブロックのうちの少なくとも１つはサブ予測ユニット（サブＰＵ）を備え、前記サブＰＵに関連付けられる前記複数の第２の代表点のうちの１つは、前記サブＰＵの中央点を備える、請求項１に記載の方法。
前記現在ブロックの前記第１の代表点は、前記現在ブロックの中央点を備え、前記隣接するブロックの前記第２の代表点は、前記隣接するブロックのそれぞれの中央点を備える、請求項１に記載の方法。
前記現在ブロックの前記第１の代表点は、前記現在ブロックの左上点を備え、前記隣接するブロックの前記第２の代表点は、前記隣接するブロックのそれぞれの左上点を備える、請求項１に記載の方法。
前記隣接するブロックは、前記現在ブロックに空間的に隣接するブロック、または前記現在ブロックに時間的に隣接するブロックのうちの１つまたは複数を備える、請求項１に記載の方法。
前記候補リストは、前記現在ブロックのシンタックス要素についての値のＣＡＢＡＣ（context adaptive binary arithmetic coding）のためのコンテキスト情報を決定するための候補のリストを備え、前記現在ブロックをコーディングすることは、前記候補のリストから決定される前記コンテキスト情報を使用して、前記現在ブロックの前記シンタックス要素についての前記値をＣＡＢＡＣコーディングすることを備える、請求項１に記載の方法。
前記シンタックス要素は、コーディングユニットトランスクワント（transquant）バイパスフラグ、コーディングユニットスキップフラグ、コード化ブロックフラグ、予測モードフラグ、残差四分木変換ルートコード化ブロックフラグ、マージインデックス、マージフラグ、ルミナンスブロックについてのコード化ブロックフラグ、またはクロミナンスブロックについてのコード化ブロックフラグのうちの１つを備える、請求項１０に記載の方法。
前記第１の代表点と前記第２の代表点との間の前記距離にしたがって、前記隣接するブロックからの値の寄与に重み付けすることを備える、前記コンテキスト情報を決定することをさらに備える、請求項１０に記載の方法。
コーディングすることは、前記候補リストを使用して前記現在ブロックを符号化することを備える、請求項１に記載の方法。
コーディングすることは、前記候補リストを使用して前記現在ブロックを復号することを備える、請求項１に記載の方法。
ビデオデータをコーディングするためのデバイスであって、
前記ビデオデータを記憶するように構成されたメモリと、
回路中に実装された１つまたは複数のプロセッサと、を備え、前記１つまたは複数のプロセッサは、
ビデオデータの現在ブロックの第１の代表点と、前記現在ブロックに隣接するブロックの複数の第２の代表点との間の複数の距離を決定することと、
前記第１の代表点と前記第２の代表点との間の前記距離にしたがった順序で、1つまたは複数の前記隣接するブロックを候補として前記現在ブロックの候補リストに加えることと、
前記候補リストを使用して前記現在ブロックをコーディングすることと、
を行うように構成されるデバイス。
前記候補リストは、マージ候補リスト、高度動きベクトル予測（ＡＭＶＰ）候補リスト、またはイントラＭＰＭ（most probable mode）リストのうちの１つを備える、請求項１５に記載のデバイス。
前記隣接するブロックのうちの少なくとも１つはサブ予測ユニット（サブＰＵ）を備え、前記サブＰＵに関連付けられる前記複数の第２の代表点のうちの１つは、前記サブＰＵの中央点を備える、請求項１５に記載のデバイス。
前記現在ブロックの前記第１の代表点は、前記現在ブロックの中央点を備え、前記隣接するブロックの前記第２の代表点は、前記隣接するブロックのそれぞれの中央点を備える、請求項１５に記載のデバイス。
前記候補リストは、前記現在ブロックのシンタックス要素についての値のＣＡＢＡＣ（context adaptive binary arithmetic coding）のためのコンテキスト情報を決定するための候補のリストを備え、前記１つまたは複数のプロセッサは、前記候補のリストから決定される前記コンテキスト情報を使用して、前記現在ブロックの前記シンタックス要素についての前記値をＣＡＢＡＣコーディングするように構成される、請求項１５に記載のデバイス。
前記デバイスは、前記現在ブロックを符号化するように構成されたビデオエンコーダ、または前記現在ブロックを復号するように構成されたビデオデコーダのうちの１つを備える、請求項１５に記載のデバイス。
ビデオデータをコーディングするためのデバイスであって、
ビデオデータの現在ブロックの第１の代表点と、前記現在ブロックに隣接するブロックの複数の第２の代表点との間の複数の距離を決定するための手段と、
前記第１の代表点と前記第２の代表点との間の前記距離にしたがった順序で、1つまたは複数の前記隣接するブロックを候補として前記現在ブロックの候補リストに加えるための手段と、
前記候補リストを使用して前記現在ブロックをコーディングするための手段と、
備えるデバイス。
前記候補リストは、マージ候補リスト、高度動きベクトル予測（ＡＭＶＰ）候補リスト、またはイントラＭＰＭ（most probable mode）リストのうちの１つを備える、請求項２１に記載のデバイス。
前記隣接するブロックのうちの少なくとも１つはサブ予測ユニット（サブＰＵ）を備え、前記サブＰＵに関連付けられる前記複数の第２の代表点のうちの１つは、前記サブＰＵの中央点を備える、請求項２１に記載のデバイス。
前記現在ブロックの前記第１の代表点は、前記現在ブロックの中央点を備え、前記隣接するブロックの前記第２の代表点は、前記隣接するブロックのそれぞれの中央点を備える、請求項２１に記載のデバイス。
前記候補リストは、前記現在ブロックのシンタックス要素についての値のＣＡＢＡＣ（context adaptive binary arithmetic coding）のためのコンテキスト情報を決定するための候補のリストを備え、前記現在ブロックをコーディングするための前記手段は、前記候補のリストから決定される前記コンテキスト情報を使用して、前記現在ブロックの前記シンタックス要素についての前記値をＣＡＢＡＣコーディングするための手段を備える、請求項２１に記載のデバイス。
実行されると、プロセッサに、
ビデオデータの現在ブロックの第１の代表点と、前記現在ブロックに隣接するブロックの複数の第２の代表点との間の複数の距離を決定することと、
前記第１の代表点と前記第２の代表点との間の前記距離にしたがった順序で、1つまたは複数の前記隣接するブロックを候補として前記現在ブロックの候補リストに加えることと、
前記候補リストを使用して前記現在ブロックをコーディングすることと、
を行わせる命令を記憶したコンピュータ可読記憶媒体。
前記候補リストは、マージ候補リスト、高度動きベクトル予測（ＡＭＶＰ）候補リスト、またはイントラＭＰＭ（most probable mode）リストのうちの１つを備える、請求項２６に記載のコンピュータ可読記憶媒体。
前記隣接するブロックのうちの少なくとも１つはサブ予測ユニット（サブＰＵ）を備え、前記サブＰＵに関連付けられる前記複数の第２の代表点のうちの１つは、前記サブＰＵの中央点を備える、請求項２６に記載のコンピュータ可読記憶媒体。
前記現在ブロックの前記第１の代表点は、前記現在ブロックの中央点を備え、前記隣接するブロックの前記第２の代表点は、前記隣接するブロックのそれぞれの中央点を備える、請求項２６に記載のコンピュータ可読記憶媒体。
前記候補リストは、前記現在ブロックのシンタックス要素についての値のＣＡＢＡＣ（context adaptive binary arithmetic coding）のためのコンテキスト情報を決定するための候補のリストを備え、前記プロセッサに前記現在ブロックをコーディングさせる前記命令は、前記プロセッサに、前記候補のリストから決定される前記コンテキスト情報を使用して、前記現在ブロックの前記シンタックス要素についての前記値をＣＡＢＡＣコーディングさせる命令を備える、請求項２６に記載のコンピュータ可読記憶媒体。