JP2020536443A - ビデオコーディングのためのアフィン予測動き情報をコーディングすること - Google Patents

Abstract

ビデオデータをコーディングするための例示的なデバイスは、ビデオデータを記憶するように構成されたメモリと、回路に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、現在のブロックの第２の動きベクトルについて、第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングすることとを行うように構成される。これにおいて、第１のＭＶＤから第２のＭＶＤを予測することは、コード化ビデオデータを含むビットストリームのビットレートを低減し、ならびに処理効率を改善し得る。【選択図】図９

Description

優先権の主張

[0001]本出願は、各々の内容全体が参照により本明細書に組み込まれる、２０１７年１０月３日に出願された米国仮出願第６２／５６７，５９８号および２０１８年１０月１日に出願された米国出願第１６／１４８，７３８号の利益を主張する。

[0002]本開示は、ビデオコーディングに関し、より詳細には、ビデオデータの動き情報をコーディングすることに関する。

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

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

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

[0006]概して、本開示はインターピクチャ予測に関係する技法について説明する。たとえば、本開示の技法は、ブロックベースのビデオコーディングにおけるアフィン動き補償のための動きベクトルコーディング（符号化および／または復号）を含む。これらの技法は、既存のおよび／または将来のビデオコーディング規格に適用され得る。

[0007]一例では、ビデオデータをコーディングする（たとえば、符号化または復号する）方法は、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングすることとを含む。

[0008]別の例では、ビデオデータをコーディングする（たとえば、符号化または復号する）ためのデバイスは、ビデオデータを記憶するように構成されたメモリと、回路に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングすることとを行うように構成される。

[0009]別の例では、コンピュータ可読記憶媒体は、実行されたとき、プロセッサに、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングすることとを行わせる命令を記憶している。

[0010]別の例では、ビデオデータをコーディングする（たとえば、符号化または復号する）ためのデバイスは、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングするための手段と、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測するための手段と、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングするための手段とを含む。

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

[0012]高効率ビデオコーディング（ＨＥＶＣ）のマージモードのための空間隣接候補の例を示す概念図。 高効率ビデオコーディング（ＨＥＶＣ）の高度動きベクトル予測（ＡＭＶＰ）モードのための空間隣接候補の例を示す概念図。 [0013]現在のブロックのための４つのアフィンパラメータをもつ例示的な２点動きベクトルアフィンを示す概念図。 [0014]現在のブロックのためのアフィンインター予測モードの一例を示す概念図。 [0015]現在のブロックのためのアフィンマージモードの一例を示す概念図。 現在のブロックのためのアフィンマージモードの一例を示す概念図。 [0016]６つのパラメータ（３つの動きベクトル）をもつ例示的なアフィンモデルを示す概念図。 [0017]アフィン予測での効率的なコーディング動き情報のための開示の技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0018]アフィン予測動き情報を符号化するための本開示の技法を実装し得るビデオエンコーダの一例を示すブロック図。 [0019]アフィン予測動き情報を復号するための本開示の技法を実装し得るビデオデコーダ３０の一例を示すブロック図。 [0020]アフィン動き情報予測のための動きベクトル差（ＭＶＤ）予測の一例を示す概念図。 [0021]３つの動きベクトルを用いるアフィン予測（６パラメータアフィン予測）でのＭＶＤ予測の一例を示す概念図。 [0022]本開示の技法による、ビデオデータの現在のブロックを符号化するための例示的な方法を示すフローチャート。 [0023]本開示の技法による、ビデオデータの現在のブロックを復号する例示的な方法を示すフローチャート。

[0024]ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む、（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４を含む。

[0025]最近では、新しいビデオコーディング規格、すなわち、ＩＴＵ−Ｔ Ｈ．２６５／高効率ビデオコーディング（ＨＥＶＣ）の設計が、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ）とのジョイントコラボレーションチームオンビデオコーディング（ＪＣＴ−ＶＣ）によって確定された。以下で「ＨＥＶＣ ＷＤ」と呼ばれる、最新のＨＥＶＣドラフト仕様が、ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１５＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｏ１００３−ｖ２．ｚｉｐから入手可能である。ＨＥＶＣに対する範囲拡張、すなわちＨＥＶＣ−Ｒｅｘｔも、ＪＣＴ−ＶＣによって開発されている。以下でＲＥｘｔ ＷＤ６と呼ばれる、範囲拡張の作業草案（ＷＤ）が、ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１６＿Ｓａｎ％２０Ｊｏｓｅ／ｗｇ１１／ＪＣＴＶＣ−Ｐ１００５−ｖ１．ｚｉｐから入手可能である。

[0026]将来のビデオコーディングのための新しいコーディングツールについての調査が進行中であり（たとえば、ＪＶＥＴ−ジョイントビデオ探査チームにおいて研究されている）、ビデオコーディングのためのコーディング効率を改善する技術が提案されている。Ｈ．２６５／ＨＥＶＣを越えた新規の専用コーディングツールを用いて４Ｋのような高解像度コンテンツのために特にビデオコンテンツの特性を活用することによってコーディング効率における有意な改善が獲得され得るという証拠がある。ビデオコーディング効率の可能なさらなる改善のための探査ステージにおいて提案を提出するように会社および団体が勧誘されている。

[0027]Ｈ．２６５／ＨＥＶＣでは、ブロックごとに、動き情報のセットが利用可能であり得る。動き情報のセットは、前方および後方の予測方向に関する動き情報を含み得る。前方予測方向および後方予測方向は、双方向予測モードの２つの予測方向であり、「前方」および「後方」という用語は、必ずしも幾何学的な意味を有するとは限らず、代わりに、これらの用語は現在ピクチャの参照ピクチャリスト０（ＲｅｆＰｉｃＬｉｓｔ０）および参照ピクチャリスト１（ＲｅｆＰｉｃＬｉｓｔ１）に対応する。ピクチャまたはスライスに関して１つの参照ピクチャリストのみが利用可能であるとき、ＲｅｆＰｉｃＬｉｓｔ０のみが利用可能であり、スライスの各ブロックの動き情報は常に前方である。

[0028]予測方向ごとに、Ｈ．２６５／ＨＥＶＣによれば、動き情報は参照インデックスと動きベクトルとを含まなければならない。場合によっては、簡単のために、動きベクトルが関連する参照インデックスを有すると仮定されるような方法では、動きベクトル自体が参照されることがある。参照インデックスは、現在の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）中の参照ピクチャを特定するために使用される。動きベクトルは水平成分と垂直成分とを有する。

[0029]ビデオコーディング規格において、ピクチャの表示順序を識別するためにピクチャ順序カウント（ＰＯＣ）が広く使用されている。１つのコード化ビデオシーケンス内の２つのピクチャが同じＰＯＣ値を有し得る場合があるが、これは、一般に、コード化ビデオシーケンス内で生じない。複数のコーディングされたビデオシーケンスがビットストリーム中に存在するとき、ＰＯＣの同じ値をもつピクチャは、復号順序に関して互いに近いことがある。ピクチャのＰＯＣ値は、一般に、参照ピクチャリスト構成と、ＨＥＶＣの場合のような参照ピクチャセットの導出と、動きベクトルスケーリングとのために使用される。

[0030]ＨＥＶＣでは、スライス中の最大コーディングユニットはコーディングツリーブロック（ＣＴＢ）と呼ばれる。ＣＴＢは４分木を含んでおり、そのノードはコーディングユニットである。（技術的に、８×８ＣＴＢサイズがサポートされ得るが）ＣＴＢのサイズは、ＨＥＶＣメインプロファイルにおいて１６×１６ピクセルから６４×６４ピクセルに及び得る。コーディングユニット（ＣＵ）は、ＣＴＢの同じサイズであり、８×８ピクセル程度に小さくなり得る。各コーディングユニットは１つのモードでコーディングされ得る。ＣＵがインターコーディングされるとき、ＣＵは、２つ以上の予測ユニット（ＰＵ）にさらに区分され得るか、または、さらなる区分が適用されないとき、１つのＰＵだけになる。１つのＣＵ中に２つのＰＵが存在するとき、それらのＰＵは、１／２サイズの長方形、あるいはＣＵの１／４または３／４サイズをもつ２つの長方形サイズであり得る。ＣＵがインターコーディングされるとき、各ＰＵについて動き情報の１つのセットが存在する。さらに、各ＰＵは、動き情報のセットを導出するために固有のインター予測モードを用いてコーディングされる。ＨＥＶＣでは、最小ＰＵサイズは８×４および４×８である。

[0031]ＨＥＶＣでは、予測ユニット（ＰＵ）のために、マージモード（スキップはマージの特殊な場合と見なされる）および高度動きベクトル予測（ＡＭＶＰ）モードと称される２つのインター予測モードがある。ＡＭＶＰモードまたはマージモードのいずれかでは、１つの動きベクトル（ＭＶ）候補リストは、複数の動きベクトル予測子について維持される。現在ＰＵの、動きベクトル、ならびにマージモードにおける参照インデックスは、ＭＶ候補リストから１つの候補を取ることによって生成される。

[0032]ＭＶ候補リストは、ＨＥＶＣごとに、マージモードのために最高５つの候補を、およびＡＭＶＰモードのために２つだけの候補を含んでいる。マージ候補は、動き情報のセット、たとえば、両方の参照ピクチャリスト（リスト０およびリスト１）に対応する動きベクトルと、参照インデックスとを含み得る。マージ候補がマージインデックスによって特定される場合、現在のブロックの予測のために参照ピクチャが使用され、ならびに関連する動きベクトルが決定される。しかしながら、リスト０またはリスト１のいずれかからの各潜在的予測方向についてのＡＭＶＰモード下で、参照インデックスは、ＡＭＶＰ候補が動きベクトルのみを含んでいるので、ＭＶ候補リストへの動きベクトル予測子（ＭＶＰ）インデックスとともに明示的にシグナリングされる必要がある。ＡＭＶＰモードでは、予測動きベクトルはさらに改良され得る。

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

[0034]図１Ａおよび図１Ｂは、ＨＥＶＣのマージおよびＡＭＶＰモードのための空間隣接候補の例を示す概念図である。特に、図１Ａに、マージモードのための空間隣接動きベクトル（ＭＶ）候補を示し、一方、図１Ｂに、ＡＭＶＰモードのための空間隣接ＭＶ候補を示す。ＨＥＶＣによれば、空間ＭＶ候補は、特定のＰＵ（ＰＵ₀）に関して図１Ａおよび図１Ｂに示す隣接ブロックから導出されるが、ブロックから候補を生成するための技法は、マージモードおよびＡＭＶＰモードに関して異なる。

[0035]ＨＥＶＣのマージモードでは、番号付きで図１Ａに示す順序で、最高４つの空間ＭＶ候補が導出され得、順序は、図１Ａに示すように、左（０）、上（１）、右上（２）、左下（３）、および左上（４）である。

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

[0037]Ｈ．２６５／ＨＥＶＣにおける動き補償は、現在のインター符号化ブロックのための予測子を生成するために使用される。クォータピクセル精度動きベクトルが使用され得、分数位置におけるピクセル値は、ルーマ成分とクロマ成分との両方の隣接整数ピクセル値を使用して補間され得る。

[0038]図２は、現在のブロックのための４つのアフィンパラメータをもつ例示的な２点動きベクトルアフィンを示す概念図である。現在の既存のビデオコーデック規格では、平行移動動きモデル（translational motion model）のみが、動き補償予測（ＭＣＰ）に適用される。しかしながら、実世界では、多くの種類の動き、たとえばズームイン／アウト、回転、遠近法の動きおよび他の不規則な動きがある。ＭＣＰのための平行移動動きモデルのみが不規則な動きをもつそのようなテストシーケンスに適用される場合、予測精度に影響を及ぼし、低いコーディング効率を生じることになる。長年の間、多くのビデオ専門家は、より高いコーディング効率のためにＭＣＰを改善するために多くのアルゴリズムを設計することを試みてきた。アフィンマージおよびアフィンインター（ＡＭＶＰ）モードは、次のような４つのパラメータをもつアフィン動きモデルに対処するために提案されている。

[0039]上記の式（１）では、（ｖｘ₀，ｖｙ₀）は、図２の現在のブロックの左上隅にある制御点動きベクトルであり、（ｖｘ₁，ｖｙ₁）は、図２の現在のブロックの右上隅にある別の制御点動きベクトルである。アフィンモデルは、以下に帰着する。

[0040]現在のＪＥＭソフトウェアでは、アフィン動き予測は、正方形ブロックにのみ適用される。自然な流れとして、アフィン動き予測は、非正方形ブロックに適用され得る。

[0041]図３は、現在のブロックのためのアフィンインター予測モードの一例を示す概念図である。現在のブロックは、現在のＣＵ、または現在のＰＵであり得る。この例では、現在のブロックは、左上隅に「Ｖ０」と標示されたブロックと右上隅に「Ｖ１」と標示されたブロックとの２つのブロックとＡ、Ｂ、Ｃ、Ｄ、およびＥと標示された隣接ブロックとを含む。特に、「Ｖ０」ブロックは、ブロックＡ、Ｂ、およびＣに隣接し、一方、「Ｖ１」ブロックは、ブロックＤおよびＥに隣接する。

[0042]サイズが１６×１６に等しいかそれよりも大きいＣＵ／ＰＵごとに、アフィンインター予測モード（ＡＦ＿ＩＮＴＥＲモード）が次のように適用され得る。現在のＣＵ／ＰＵがＡＦ＿ＩＮＴＥＲモードにある場合、ＣＵ／ＰＵレベル中のアフィンフラグがビットストリーム中でシグナリングされ得る。候補リスト｛（ｖ₀，ｖ₁）｜ｖ₀＝｛ｖ_A，ｖ_B，ｖ_c｝，ｖ₁＝｛ｖ_D，ｖ_E｝｝は、ネイバーの有効な再構成されたブロックを使用して構築される。

[0043]図３に示すように、動き情報ｖ₀は、ブロックＡ、Ｂ、および／またはＣの動きベクトルから選択される。ネイバーブロックからの動きベクトルは、参照リストと、ネイバーブロックのための参照のＰＯＣ、現在のＣＵ／ＰＵのための参照のＰＯＣ、および現在のＣＵ／ＰＵのＰＯＣの間の関係と、に従ってスケーリングされる。また、ネイバーブロックＤおよびＥからｖ₁を選択するための手法は、同様である。候補リストの数が２よりも小さい場合、ＡＭＶＰの候補は、ｖ₀およびｖ₁に割り当てられる。現在のＣＵ／ＰＵのレートひずみ最適化（ＲＤＯ）コストは、どの（ｖ₀，ｖ₁）が現在のＣＵ／ＰＵの制御点動きベクトル予測（ＣＰＭＶＰ）として選択されるのかを決定するために使用される。また、候補リスト中のＣＰＭＶＰの位置を示すインデックスが、ビットストリーム中でシグナリングされる。

[0044]現在のアフィンＣＵ／ＰＵのＣＰＭＶＰが決定された後に、アフィン動き推定が適用され、ＣＰＭＶが見つけられる。次いで、ＣＰＭＶとＣＰＭＶＰとの差がビットストリーム中にコーディングされる。前述のアフィン動き補償予測は、現在のＣＵ／ＰＵの残余を生成するために適用される。最後に、現在のＣＵ／ＰＵの残余は、従来のプロシージャに従って、変換され、量子化され、ビットストリームにコーディングされる。

[0045]図４Ａおよび図４Ｂは、現在のブロックのためのアフィンマージモードの一例を示す概念図である。現在のブロックは、現在のＣＵ、または現在のＰＵであり得る。この例では、現在のブロックは、図４Ａに示すように、Ａ、Ｂ、Ｃ、Ｄ、およびＥと標示された５つの隣接ブロックを有する。

[0046]現在のＣＵ／ＰＵは、アフィンマージモード（ＡＦ＿ＭＥＲＧＥモード）で適用されるとき、Ａ、Ｂ、Ｃ、Ｄ、およびＥの有効なネイバーの再構成されたブロックからアフィンモードを用いてコーディングされた第１のブロックを得る。候補ブロックのための選択順序は、図４Ａに示すように、左、上、右上、左下、左上の順である。たとえば、ネイバー左下ブロックＡが、図４Ｂに示すようにアフィンモードにおいてコーディングされる場合、ブロックＡを含んでいるＣＵ／ＰＵの左上隅、右上隅および左下隅の動きベクトルｖ₂、ｖ₃およびｖ₄が導出される。現在のＣＵ／ＰＵ上の左上隅の動きベクトルｖ₀は、ｖ₂、ｖ₃、およびｖ₄に従って計算される。同様に、現在のＣＵ／ＰＵの右上の動きベクトルｖ₁は、ｖ₂、ｖ₃、およびｖ₄に基づいて計算される。

[0047]現在のＣＵ／ＰＵのＣＰＭＶｖ₀およびｖ₁が計算された後に、上記の式（２）に定義されている簡略化されたアフィン動きモデルに従って、現在のＣＵ／ＰＵのＭＶＦが生成される。次いで、アフィンＭＣＰが適用される。現在のＣＵ／ＰＵがＡＦ＿ＭＥＲＧＥモードを用いてコーディングされるのかどうかを識別するために、アフィンモードにおいてコーディングされた少なくとも１つのネイバーブロックがあるとき、アフィンフラグがビットストリーム中でシグナリングされる。図４Ａに示すように、現在のブロックに隣接するアフィンブロックが存在しない場合、アフィンフラグがビットストリーム中に書かれない。

[0048]ＨＥＶＣでは、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）は、２値化された値にシンボルを変換するために使用される２値化プロセスを含む。２値化により、ビンと呼ばれるビットのシーケンスへの非バイナリシンタックス要素の一意のマッピングを介して効率的なバイナリ算術符号化が可能になる。ＪＥＭ２．０参照ソフトウェアでは、アフィンマージモードの場合、アフィンフラグのみがコーディングされ、マージインデックスは、あらかじめ定義されたチェック順序Ａ→Ｂ→Ｃ→Ｄ→Ｅで第１の利用可能な隣接アフィンモデルであると推測される。アフィンインターモードの場合、２つのＭＶＤシンタックスが予測リストごとにコーディングされ、導出されたアフィン動きベクトルと予測された動きベクトルとの間の動きベクトル差を示す。

[0049]図５は、６つのパラメータ（３つの動きベクトル）をもつ例示的なアフィンモデルを示す概念図である。Ｚｏｕらによる、２０１７年５月４日に出願された「ＡＦＦＩＮＥ ＭＯＴＩＯＮ ＰＲＥＤＩＣＴＩＯＮ ＦＯＲ ＶＩＤＥＯ ＣＯＤＩＮＧ」と題する米国出願第１５／５８７，０４４号では、切替え可能なアフィン動き予測方式について説明した。アフィン予測を用いるブロックは、４つのパラメータのアフィンモデルまたは６つのパラメータのアフィンモデルを適応的に使用することができる。６つのパラメータを用いるアフィンモデルは、次のように定義され得る。

[0050]６つのパラメータを用いるアフィンモデルは、３つの制御点を有する。言い換えれば、６つのパラメータを用いるアフィンモデルは、たとえば、図５に示すように、３つの動きベクトル（ＭＶ０、ＭＶ１、およびＭＶ２）によって決定される。図５に示すように、ＭＶ０は、現在のブロックの左上隅にある第１の制御点動きベクトルであり、ＭＶ１は、現在のブロックの右上隅にある第２の制御点動きベクトルであり、ＭＶ２は、現在のブロックの左下隅にある第３の制御点動きベクトルである。３つの動きベクトルを用いて構築されるアフィンモデルは、次のように計算される。

[0051]上の式（４）は、ｗに等しい辺を有する正方形ブロックのためのものである。ｗの幅とｈの高さとを有する非正方形ブロック（たとえば、矩形ブロック）の場合、以下のアフィンモデルが使用され得る。

[0052]左上隅、右上隅、および左下隅のためのＭＶＰを導出するために、上記の図４に関して説明した左上隅および右上隅の動きベクトルを導出するアフィンマージと同様の方法が同じく使用され得る。追加の例は、Ｃｈｅｎらによる、２０１６年１０月５日に出願された「ＭＯＴＩＯＮ ＶＥＴＯＲ ＰＲＥＤＩＣＴＩＯＮ ＦＯＲ ＡＦＦＩＮＥ ＭＯＴＩＯＮ ＭＯＤＥＬ」と題する米国仮出願第６２／４０４，７１９号に記載されている。

[0053]図６は、アフィン予測での効率的なコーディング動き情報のための開示の技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図６に示すように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォン、いわゆる「スマート」パッドなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲のデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に対応し得る。

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

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

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

[0057]図６の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、アフィン予測での効率的なコーディング動き情報のための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または配置を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部のビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。

[0058]図６の図示のシステム１０は一例にすぎない。アフィン予測での効率的なコーディング動き情報のための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスによって実行されるが、これらの技法は、通常は「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。さらに、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４への送信のためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的な様式で動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオ電話のための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートし得る。

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

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

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

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

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

[0064]概して、ＩＴＵ−Ｔ Ｈ．２６５に従って、ビデオピクチャが、ルーマサンプルとクロマサンプルの両方を含み得る、コーディングツリーユニット（ＣＴＵ）（または最大コーディングユニット（ＬＣＵ））のシーケンスに分割され得る。代替的に、ＣＴＵはモノクロームデータ（すなわち、ルーマサンプルのみ）を含み得る。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＣＴＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するＣＴＵを含む。ビデオピクチャは、１つまたは複数のスライスに区分され得る。各ＣＴＵは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはＣＴＵに対応する。ＣＵが４つのサブＣＵに分割される場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。

[0065]４分木データ構造の各ノードは、対応するＣＵにシンタックスデータを与え得る。たとえば、４分木内のノードは、そのノードに対応するＣＵがサブＣＵに分割されるか否かを示すスプリットフラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるか否かに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵはリーフＣＵとも呼ばれる。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵはリーフＣＵとも呼ばれる。

[0066]ＣＵは、ＣＵがサイズの特異性を有しないことを別にすれば、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ＣＴＵは、（サブＣＵとも呼ばれる）４つの子ノードに分割され得、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深さと呼ばれる、ＣＴＵが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームはまた、最小コーディングユニット（ＳＣＵ）を定義し得る。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、予測ユニット（ＰＵ）、または変換ユニット（ＴＵ）、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。

[0067]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、概して形状が正方形である。ＣＵのサイズは、８×８ピクセルから最大サイズ、たとえば、６４×６４以上のピクセルをもつＣＴＵのサイズに及び得る。各ＣＵは、１つまたは複数のＰＵと１つまたは複数のＴＵとを含み得る。ＣＵに関連付けられたシンタックスデータは、たとえば、１つまたは複数のＰＵへのＣＵの区分を記述し得る。区分モードは、ＣＵがスキップモード符号化もしくは直接モード符号化されるのか、イントラ予測モード符号化されるのか、またはインター予測モード符号化されるのかの間で異なり得る。ＰＵは、形状が非正方形に区分され得る。ＣＵに関連付けられたシンタックスデータはまた、たとえば、４分木に従うＣＵの１つまたは複数のＴＵへの区分を記述し得る。ＴＵは、形状が方形または非正方形（たとえば、長方形）であり得る。

[0068]ＨＥＶＣ規格は、ＣＵごとに異なり得る、ＴＵに従う変換を可能にする。ＴＵは、一般に、区分されたＣＴＵについて定義された所与のＣＵ内のＰＵ（またはＣＵの区分）のサイズに基づいてサイズ決定されるが、これは常にそうであるとは限らない。ＴＵは、一般に、ＰＵ（または、たとえば、イントラ予測の場合は、ＣＵの区分）と同じサイズであるか、またはそれよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ）として知られる４分木構造を使用して、より小さいユニットにさらに分割され得る。ＲＱＴのリーフノードは、変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連付けられたピクセル差分値は、変換係数を生成するために変換され得、変換係数は量子化され得る。

[0069]リーフＣＵは、インター予測を用いて予測されるとき、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間エリアを表し、そのＰＵの参照サンプルを取り出しおよび／または生成するためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。ＣＵがインターモード符号化されるとき、ＣＵの１つまたは複数のＰＵは、１つまたは複数の動きベクトルなどの動き情報を定義するデータを含み得るか、またはＰＵは、スキップモードコーディングされ得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０またはリスト１）を記述し得る。

[0070]リーフＣＵはまた、イントラモード予測され得る。概して、イントラ予測は、イントラモードを使用してリーフＣＵ（またはそれの区分）を予測することに関与する。ビデオコーダは、リーフＣＵ（またはそれの区分）を予測するために使用すべきリーフＣＵに隣接する以前にコーディングされたピクセルのセットを選択し得る。

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

[0072]さらに、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、そのリーフＣＵがＴＵにどのように区分されるのかを示す４分木を含み得る。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してＣＴＵ（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。概して、本開示は、別段に明記されていない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。

[0073]ビデオシーケンスは、一般に、ランダムアクセスポイント（ＲＡＰ）ピクチャで開始する、一連のビデオフレームまたはピクチャを含む。ビデオシーケンスは、シーケンスパラメータセット（ＳＰＳ）ビデオシーケンスのその特性中にシンタックスデータを含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに作用する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し、指定のコーディング規格に応じてサイズが異なり得る。

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

[0075]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法の観点からビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。一般に、１６ｘ１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここで、Ｎは非負整数値を表す。ブロック中のピクセルは行および列に配列され得る。さらに、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。

[0076]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングに続いて、ビデオエンコーダ２０は、ＣＵのＴＵについての残差データを計算し得る。ＰＵは、空間領域（ピクセル領域とも呼ばれる）において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを表す被量子化変換係数を含むようにＴＵを形成し得る。すなわち、ビデオエンコーダ２０は、（残差ブロックの形態の）残差データを計算し、変換係数のブロックを生成するために残差ブロックを変換し、次いで、被量子化変換係数を形成するために変換係数を量子化し得る。ビデオエンコーダ２０は、被量子化変換係数を含むＴＵ、ならびに他のシンタックス情報（たとえば、ＴＵのためのスプリッティング情報）を形成し得る。

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

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

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

[0080]概して、ビデオデコーダ３０は、符号化データを復号するためにビデオエンコーダ２０によって実行されるものと、逆ではあるが、実質的に同様のプロセスを実行する。たとえば、ビデオデコーダ３０は、残差ブロックを再生するために、受信されたＴＵの係数を逆量子化および逆変換する。ビデオデコーダ３０は、予測されたブロックを形成するために、シグナリングされた予測モード（イントラ予測またはインター予測）を使用する。次いで、ビデオデコーダ３０は、元のブロックを再生するために、（ピクセルごとに）予測されたブロックと残差ブロックとを組み合わせる。ブロック境界に沿って視覚的アーティファクトを低減するためにデブロッキングプロセスを実行することなど、追加の処理が実行され得る。さらに、ビデオデコーダ３０は、ビデオエンコーダ２０のＣＡＢＡＣ符号化プロセスと逆ではあるが、それと実質的に同様の様式でＣＡＢＡＣを使用してシンタックス要素を復号し得る。

[0081]概して、ビデオエンコーダ２０とビデオデコーダ３０とは、本開示の技法に従ってアフィン予測での動き情報をより効率的にコーディングする（それぞれ、符号化するまたは復号する）ように構成され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、単独でまたは任意の組合せで、後述する様々な技法のいずれかを適用するように構成され得る。

[0082]いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測を用いて予測されたブロック中の別のベクトル（ＭＶ）のＭＶＤを予測するために１つの動きベクトル（ＭＶ）の動きベクトル差（ＭＶＤ）を使用し得る。ＭＶＤは、ＭＶと動きベクトル予測（ＭＶＰ）との間の差ＭＶＤ＝ＭＶ−ＭＶＰとして定義され得る。より詳細には、動きベクトル（ＭＶ_x，ＭＶ_y）がそれの水平成分（ＭＶ_x）と垂直成分（ＭＶ_y）とによって示され、動きベクトル予測子が成分（ＭＶＰ_x，ＭＶＰ_y）を有する場合、ＭＶＤの水平（垂直）成分は、それぞれ、ＭＶとＭＶＰとの水平（垂直）成分の差として定義される。したがって、ＭＶＤは、（ＭＶＤ_x，ＭＶＤ_y）として定義され得、ここで、ＭＶＤ_x＝ＭＶ_x−ＭＶＰ_xであり、ＭＶＤ_y＝ＭＶ_y−ＭＶＰ_yである。

[0083]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測において１つまたは複数の他のＭＶのＭＶＤを予測するために第１のＭＶのＭＶＤを使用するように構成され得る。図９は、そのようなＭＶＤ予測の一例を示す概念図である。いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測（たとえば、４パラメータアフィン）において第２のＭＶのＭＶＤを予測するために第１のＭＶのＭＶＤを使用するように構成され得る。下の図９は、２つの動きベクトルを用いるアフィン予測でのＭＶＤ予測の一例を示し、ここで、ＭＶＤ１は、ＭＶＤ０によって予測される。

[0084]図１０は、３つの動きベクトルを用いるアフィン予測（６パラメータアフィン予測）でのＭＶＤ予測の一例を示す概念図である。６パラメータアフィン予測の場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、第２のＭＶのＭＶＤを予測するために第１のＭＶのＭＶＤを使用し得る。さらに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、３つの動きベクトルを用いるアフィン予測において第３のＭＶのＭＶＤを予測するために第１のＭＶのＭＶＤを使用し得る。図１０は、３つの動きベクトルを用いるアフィン予測でのＭＶＤ予測の一例を示し、ここで、ＭＶＤ１は、ＭＶＤ０によって予測され、ＭＶＤ２はまた、ＭＶＤ０によって予測される。

[0085]図６を再び参照すると、いくつかの例では、ビデオエンコーダ２０とビデオデコーダ３０とは、上記の例中の第１のＭＶが図３、図９、および図１０中の「ＭＶ０」で示される左上の制御点に関連するＭＶとして定義されるように構成し得る。代替的に、ビデオエンコーダ２０とビデオデコーダ３０とは、第１のＭＶに関連する第１の制御点を適応的に選択するように構成され得る。たとえば、第１の制御点は、ブロック形状などのコーディングされた情報に依存し得る。代替的に、ビデオエンコーダ２０とビデオデコーダ３０とは、第１のＭＶに関連する第１の制御点を暗黙的に導出し得る。

[0086]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測では任意の２つのＭＶＤ間にＭＶＤ予測を適用するように構成され得る。たとえば、ビデオエンコーダ２０とビデオデコーダ３０とは、２つの動きベクトルを用いるアフィン予測ではＭＶＤ１からＭＶＤ０を予測し得る。別の例では、ビデオエンコーダ２０とビデオデコーダ３０とは、３つの動きベクトルを用いるアフィン予測ではＭＶＤ０からＭＶＤ１を予測し、ＭＶＤ１からＭＶＤ２を予測し得る。

[0087]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＤｂからＭＶＤａを予測するように構成され得る。ビデオエンコーダ２０は、ＭＶＤａ’＝ＭＶＤａ−ＭＶＤｂを計算し、ビットストリームの一部としてＭＶＤａ’を表す情報をコーディングし得、したがって、ビデオデコーダ３０は、ＭＶＤａ’を決定するためにこの情報を復号し得る。ビデオデコーダ３０は、次いで、ＭＶＤａ＝ＭＶＤａ’＋ＭＶＤｂを計算し得る。一例では、４つのパラメータを用いるアフィン予測ではａ＝１であり、ｂ＝０である。

[0088]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＤｂからＭＶＤａを予測するように構成され得る。ビデオエンコーダ２０は、次いで、ＭＶＤａ’＝ＭＶＤａ−ｗ＊ＭＶＤｂを計算し、ビットストリームの一部としてＭＶＤａ’を表す情報をコーディングし得、したがって、ビデオデコーダ３０は、ＭＶＤａ’を決定するためにこの情報を復号し得る。ビデオデコーダ３０は、次いで、ＭＶＤａ＝ＭＶＤａ’＋ｗ＊ＭＶＤｂを計算し得る。この例では、ｗは、０．５などの重み付け値である。一例では、２つのパラメータを用いるアフィン予測ではａ＝１であり、ｂ＝０である。この例は、ｗ＝０．５であるときにＭＶＤ１’＝ＭＶＤ１−（（ＭＶＤ０＋１）＞＞１）であるか、またはｗ＝０．２５であるときにＭＶＤ１’＝ＭＶＤ１−（（ＭＶＤ０＋２）＞＞２）であるような整数形態（integer form）で実装され得る。一例では、ビデオエンコーダ２０は、たとえば、（シーケンスパラメータセット（ＳＰＳ）などの）シーケンスレベル、（ピクチャパラメータセット（ＰＰＳ）などの）ピクチャレベル、（スライスヘッダ中でなどの）スライスレベル、または（ブロックヘッダ中でなどの）ブロックレベルでビットストリームの一部としてｗを表すデータを符号化する。ビデオデコーダ３０は、対応するレベルの情報からこのシグナリングされた情報をさらに抽出し得る。

[0089]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、２つ以上の他の制御点のＭＶＤから１つの制御点のＭＶＤを予測するように構成され得る。たとえば、ビデオエンコーダ２０とビデオデコーダ３０とは、６パラメータアフィンモデルにおいてＭＶＤ０とＭＶＤ１とからＭＶＤ２を予測し得る。一例として、ビデオエンコーダ２０は、ＭＶＤ２’＝ＭＶＤ２−（（ＭＶＤ０＋ＭＶＤ１）＞＞１）を計算し、ビットストリームの一部としてＭＶＤ２’を表す情報をコーディングし得、したがって、ビデオデコーダ３０は、ＭＶＤ２’を決定するためにこの情報を復号し得る。ビデオデコーダ３０は、次いで、ＭＶＤ２＝ＭＶＤ２’＋（（ＭＶＤ０＋ＭＶＤ１）＞＞１）を計算するためにこの情報を使用し得る。

[0090]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＤ値に基づいてＭＶＤを予測すべきか否かを決定するように構成され得る。たとえば、ビデオエンコーダ２０は、｜ＭＶＤｂ^x＋ＭＶＤｂ^y｜＜Ｔである場合にＭＶＤｂからＭＶＤａを予測することを決定し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。別の例では、ビデオエンコーダ２０は、ｍａｘ（｜ＭＶＤｂ^x｜，｜ＭＶＤｂ^y｜）＜Ｔである場合にＭＶＤｂからＭＶＤａを予測することを決定し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。さらに別の例では、ビデオエンコーダ２０は、｜ＭＶＤｂ^x＋ＭＶＤｂ^y｜＞Ｔである場合にＭＶＤｂからＭＶＤａを予測し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。さらに別の例では、ビデオエンコーダ２０は、ｍｉｎ（｜ＭＶＤｂ^x｜，｜ＭＶＤｂ^y｜）＞Ｔである場合にＭＶＤｂからＭＶＤａを予測し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。上記の例では、Ｔは、固定数であるか、またはビデオエンコーダ２０によってシグナリングされ、ビデオデコーダ３０によって復号され得るしきい値を表す。ビデオエンコーダ２０は、上記の例示的な決定のいずれかに基づいてＭＶＤｂからＭＶＤａを予測すべきか否かを表すデータを符号化し得、ビデオデコーダ３０は、ＭＶＤｂからＭＶＤａを予測すべきかどうかを決定するためにこの符号化されたデータを復号し得る。

[0091]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、様々な方法でＭＶＤの水平（ｘ）および／または垂直（ｙ）成分を予測するように構成され得る。たとえば、ビデオエンコーダ２０とビデオデコーダ３０とは、ＭＶＤａのｘ成分からＭＶＤｂのｘ成分のみを予測するが、別のＭＶＤ（たとえば、ＭＶＤａ）からＭＶＤｂのｙ成分を予測しないことがある。

[0092]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰの値に基づいてＭＶＤを予測すべきかどうかについて決定するように構成され得る。たとえば、ビデオエンコーダ２０は、｜ＭＶＰａ^x−ＭＶＰｂ^x｜＋｜ＭＶＰａ^y−ＭＶＰｂ^y｜＜Ｓである場合にＭＶＤｂからＭＶＤａを予測することを決定し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。別の例では、ビデオエンコーダ２０は、ｍａｘ（｜｜ＭＶＰａ^x−ＭＶＰｂ^x｜，｜ＭＶＰａ^y−ＭＶＰｂ^y｜）＜Ｓである場合にＭＶＤｂからＭＶＤａを予測することを決定し得、そうでない場合、ビデオエンコーダ２０は、ＭＶＤｂからＭＶＤａを予測しない。上記の例では、Ｓは、固定数であるか、またはビデオエンコーダ２０によってシグナリングされ、ビデオデコーダ３０によって復号され得るしきい値を表す。ビデオエンコーダ２０は、上記の例示的な決定のいずれかに基づいてＭＶＤｂからＭＶＤａを予測すべきか否かを表すデータを符号化し得、ビデオデコーダ３０は、ＭＶＤｂからＭＶＤａを予測すべきかどうかを決定するためにこの符号化されたデータを復号し得る。

[0093]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、動き予測方法に基づいてアフィン予測を使用して予測されるブロックのためのＭＶＤを予測すべきかどうかを決定するように構成され得る。たとえば、ＭＶＰが図３に関して上記で説明したようにＪＥＭにおけるＭＶＰ導出方法から来る場合、ビデオエンコーダ２０とビデオデコーダ３０とは、ＭＶＤ予測を使用しないことを決定し得る。別の例として、ＭＶＰが米国仮出願第６２／４０４，７１９号に関して上記で説明したアフィンマージと同様のＭＶＰ導出方法から来る場合、ビデオエンコーダ２０とビデオデコーダ３０とは、ＭＶＤ予測を使用することを決定し得る。追加または代替として、ビデオエンコーダ２０とビデオデコーダ３０とは、照度補償がＭＶＰのソースブロックのために使用されるのかどうかに基づいてＭＶＤ予測を使用すべきかどうかを決定し得る。

[0094]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、現在のブロックのサイズおよび／または形状に基づいてＭＶＤを予測すべきかどうかについて決定するように構成され得る。たとえば、ビデオエンコーダ２０とビデオデコーダ３０とは、Ｗ＊Ｈ＞ＴであるときにＭＶＤ予測を使用することを決定し得、ここで、Ｗは、現在のブロックの幅を表し、Ｈは、現在のブロックの高さを表し、Ｔは、しきい値を表す。Ｔは、固定数であるか、またはビットストリーム中でビデオエンコーダ２０からビデオデコーダ３０にシグナリングされ得る。別の例では、ビデオエンコーダ２０とビデオデコーダ３０とは、Ｗ＊Ｈ＜ＴであるときにＭＶＤ予測を使用することを決定し得る。

[0095]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ビットストリーム中のＭＶＤ（またはそれの成分）を予測すべきか否かを表すデータをコーディングするように構成され得る。すなわち、ビデオエンコーダ２０は、ビットストリーム中のＭＶＤのいずれかのまたは両方の成分（水平および垂直）を予測すべきかどうかを表すデータを符号化し得、ビデオデコーダ３０は、（データを復号することによって）ビットストリームの符号化されたデータからＭＶＤのいずれかのまたは両方の成分を予測すべきかどうかを決定し得る。

[0096]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、どの（1つまたは複数の）制御点をビットストリーム中のＭＶＤ予測のための参照として使用すべきかを表すデータをコーディングするように構成され得る。すなわち、ビデオエンコーダ２０は、このデータを符号化し得、ビデオデコーダ３０は、どの（1つまたは複数の）制御点をＭＶＤ予測のための参照として使用すべきかを決定するためにこのデータを復号し得る。

[0097]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測を使用して予測されるブロック中の別のＭＶのＭＶＤからＭＶのＭＶＰを生成するように構成され得る。

[0098]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測において１つまたは複数の他のＭＶのＭＶＰを生成するために第１のＭＶのＭＶＤを使用するように構成され得る。一例では、ビデオエンコーダ２０およびビデオデコーダ３０は、アフィン予測（たとえば、４パラメータアフィン）において第２のＭＶのＭＶＰを生成するために第１のＭＶのＭＶＤを使用し得る。別の例では、６パラメータアフィン予測の場合、ビデオエンコーダ２０とビデオデコーダ３０とは、３つの動きベクトルを用いるアフィン予測において第２のＭＶのＭＶＰを生成するために第１のＭＶのＭＶＤを使用し得る。さらに、ビデオエンコーダ２０とビデオデコーダ３０とは、３つの動きベクトルを用いるアフィン予測において第３のＭＶのＭＶＰを生成するために第１のＭＶのＭＶＤを使用し得る。代替的に、ビデオエンコーダ２０とビデオデコーダ３０とは、３つの動きベクトルを用いるアフィン予測において第３のＭＶのＭＶＰを生成するために第２のＭＶのＭＶＤを使用し得る。

[0099]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、２つの動きベクトルを用いるアフィン予測ではＭＶＤ１からＭＶＰ０を生成するように構成され得る。別の例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、３つの動きベクトルを用いるアフィン予測ではＭＶＤ０からＭＶＰ１を生成し、ＭＶＤ１からＭＶＰ２を生成するように構成され得る。

[0100]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰａ＝ＭＶＰ’ａ＋ＭＶＤｂに従ってＭＶＰａを計算するように構成され得る。ＭＶＰ’ａは、アフィン予測のためのＡＭＶＰおよびマージモードについて上記で説明したようにＭＶＤｂについて考えることなしに元の（original）方法で生成されたＭＶＰを表す。一例では、４つのパラメータ（２つの動きベクトル）を用いるアフィン予測ではａ＝１であり、ｂ＝０である。

[0101]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰａ＝ＭＶＰ’ａ＋ｗ＊ＭＶＤｂに従ってＭＶＰａを計算するように構成され得、ここで、ｗは、０．５などの重み付け値である。この例では、ＭＶＰ’ａは、アフィン予測のためのＡＭＶＰおよびマージモードについて上記で説明したようにＭＶＤｂについて考えることなしに元の方法で生成されたＭＶＰである。一例では、２つのパラメータを用いるアフィン予測ではａ＝１であり、ｂ＝０である。この例は、ｗ＝０．５であるときにＭＶＰ１＝ＭＶＰ’１＋（（ＭＶＤ０＋１）＞＞１）であるか、またはｗ＝０．２５であるときにＭＶＰ１＝ＭＶＰ’１＋（（ＭＶＤ０＋２）＞＞２）であるような整数形態（integer form）で実装され得る。一例では、ビデオエンコーダ２０は、ｗを決定し、シーケンスレベル、ピクチャレベル、スライスレベル、またはブロックレベルでビットストリーム中でｗの値をシグナリングする。ビデオデコーダ３０は、相応して、適切なレベルの情報からｗの値を復号することになる。

[0102]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、複数の他の制御点の複数のＭＶＤから１つの制御点のＭＶＰを生成するように構成され得る。たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０とは、６パラメータアフィンモデルにおいてＭＶＤ０とＭＶＤ１とからＭＶＰ２を生成し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰ２＝ＭＶＰ’２＋（（ＭＶＤ０＋ＭＶＤ１）＞＞１）としてＭＶＰ２を計算し得る。

[0103]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測を使用して予測される１つのブロック中の１つまたは複数の他の制御点の（1つまたは複数の）ＭＶの（1つまたは複数の）ＭＶＰを生成するために１つの制御点のＭＶを使用するように構成され得る。一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、アフィン予測（たとえば、４パラメータアフィン）において第２のＭＶのＭＶＰを生成するために第１のＭＶを使用し得る。別の例では、６パラメータアフィン予測の場合、ビデオエンコーダ２０および／またはビデオデコーダ３０とは、３つの動きベクトルを用いるアフィン予測において第２のＭＶのＭＶＰを生成するために第１のＭＶを使用し、３つの動きベクトルを用いるアフィン予測において第３のＭＶのＭＶＰを生成するために第１のＭＶを使用し得る。代替的に、６パラメータアフィン予測の場合、エンコーダ２０および／またはビデオデコーダ３０は、３つの動きベクトルを用いるアフィン予測において第３のＭＶのＭＶＰを生成するために第２のＭＶを使用し得る。

[0104]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰａ＝（ＭＶＰ’ａ＋ＭＶｂ）＞＞１としてＭＶＰａを計算するように構成され得る。ＭＶＰ’ａは、アフィン予測のためのＡＭＶＰおよびマージを説明したセクションにおいて上記で説明したようにＭＶｂについて考えることなしに元の方法で生成されたＭＶＰである。一例では、４つのパラメータを用いるアフィン予測ではａ＝１であり、ｂ＝０である。

[0105]追加または代替として、いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＶＰａ＝ｗ１＊ＭＶＰ’ａ＋ｗ２＊ＭＶｂとしてＭＶＰａを計算するように構成され得る。この例では、ｗ１とｗ２とは、同じまたは異なる値、たとえば、ｗ１＝ｗ２＝０．５を有し得る重み付け値である。ＭＶＰ’ａは、アフィン予測のためのＡＭＶＰおよびマージモードに関する上記のセクションにおいて説明したようにＭＶｂについて考えることなしに元の方法で生成されたＭＶＰである。一例では、４つのパラメータを用いるアフィン予測ではａ＝１であり、ｂ＝０である。この例は、ｗ１＝０．７５であり、ｗ２＝０．２５であるときにＭＶＰ１＝（３＊ＭＶＰ’１＋ＭＶ０＋２）＞＞２であるような整数形態で実装され得る。一例では、ビデオエンコーダ２０は、シーケンスレベル、ピクチャレベル、スライスレベル、またはブロックレベルのいずれかでビットストリーム中でｗ１およびｗ２についてのデータを符号化する。同様に、ビデオデコーダ３０は、適切なレベルでこのデータを復号することによってｗ１とｗ２とを決定することになる。

[0106]ビデオエンコーダ２０は、さらに、ブロックベースシンタックスデータ、ピクチャベースシンタックスデータ、およびシーケンスベースシンタックスデータなど、シンタックスデータを、たとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、あるいはシーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、またはビデオパラメータセット（ＶＰＳ）など、他のシンタックスデータ中でビデオデコーダ３０に送り得る。

[0107]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、離散論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な好適なエンコーダまたはデコーダ回路のいずれかとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として組み込まれ得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。

[0108]図７は、アフィン予測動き情報を符号化するための本開示の技法を実装し得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングとインターコーディングとを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために、空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間冗長性を低減または除去するために時間的予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースコーディングモードのいずれかを指すことがある。単方向予測（Ｐモード）または双予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指すことがある。

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

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

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

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

[0113]動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別個に示されている。動き推定ユニット４２によって実施される動き推定は、ビデオブロックの動きを推定する動きベクトルを発生するプロセスである。動きベクトルは、たとえば、現在のフレーム内でコーディングされている現在のブロック（または、他のコード化ユニット）に対する、参照フレーム内の予測ブロック（または、他のコード化ユニット）に対する、現在のビデオフレーム内またはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、ピクセル差分の観点で、コーディングされるべきブロックと密に適合すると見出されたブロックであり、ピクセル差分は、絶対値差分の合計（ＳＡＤ）、二乗差分の合計（ＳＳＤ）、または他の差分の測定規準によって決定され得る。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの４分の１ピクセル位置、８分の１ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。

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

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

[0116]ビデオエンコーダ２０は、図６に関して上記で説明された本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット４４は、ＨＥＶＣに従ってＡＭＶＰまたはマージモードを使用してビデオデータのブロックについての動き情報をコーディングするように構成され得、および／または本開示の技法に従ってアフィンインターモードまたはアフィンマージモードを使用してアフィン動き情報またはビデオデータのブロックをコーディングするように構成され得る。

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

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

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

[0120]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、変換係数値を備えるビデオブロックを生成する。ウェーブレット変換、整数変換、サブバンド変換、離散サイン変換（ＤＳＴ）、または他のタイプの変換が、ＤＣＴの代わりに使用され得る。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、変換係数のブロックを生成する。変換は、残差情報をピクセル領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４へ送り得る。量子化ユニット５４は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって、変更され得る。

[0121]量子化に続いて、エントロピー符号化ユニット５６は量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型２値算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型２値算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは近隣ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングに続いて、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されるか、または後で送信するかもしくは取り出すためにアーカイブされ得る。

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

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

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

[0125]ビデオスライスが、イントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、現在のフレームまたはピクチャの以前に復号されたブロックから、シグナリングされたイントラ予測モードおよびデータに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（すなわち、ＢまたはＰ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つの内の参照ピクチャのうちの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ８２に記憶された参照ピクチャに基づくデフォルト構成技法を使用して、参照フレームリスト、リスト０およびリスト１を構成し得る。動き補償ユニット７２は、動きベクトルと他のシンタックス要素とをパースすることによって現在のビデオスライスのビデオブロックのための予測情報を決定し、この予測情報を使用して、復号されている現在のビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラ予測またはインター予測）と、インター予測スライスタイプ（たとえば、ＢスライスまたはＰスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数についての構成情報と、スライスの各インター符号化されたビデオブロックのための動きベクトルと、スライスの各インターコーディングされたビデオブロックについてのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。

[0126]ビデオデコーダ３０は、図６に関して上記で説明された本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット７２は、ＨＥＶＣに従ってＡＭＶＰまたはマージモードを使用して動きベクトル予測を実行するように構成され得、および／または本開示の技法に従ってアフィンインターモードまたはアフィンマージモードを使用してアフィン動き情報またはビデオデータのブロックを実行するように構成され得る。エントロピー復号ユニット７０は、動き情報（たとえば、アフィン動き情報）が現在のブロックについてどのようにコーディングされるかを表す１つまたは複数のシンタックス要素を復号し得る。

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

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

[0129]逆変換ユニット７８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用して、ピクセル領域において残差ブロックを生成する。

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

[0131]図１１は、本開示の技法による、ビデオデータの現在のブロックを符号化するための例示的な方法を示すフローチャートである。例および説明の目的で、図１１の方法は、図６および図７のビデオエンコーダ２０に関して説明される。ただし、他のデバイスが、この方法または同様の方法を実行するように構成され得ることを理解されたい。

[0132]最初に、図１１には示されていないが、モード選択ユニット４０は、現在のブロックを予測するために使用されるべき予測モードを決定し得る。この例では、モード選択ユニット４０は、少なくとも２つの動きベクトルを使用した予測を含むアフィン予測モードを選択すると仮定する。したがって、モード選択ユニット４０は、動き推定ユニット４２に、第１の動きベクトルと第２の動きベクトルとを決定するために動き探索を実行させる（１００）。モード選択ユニット４０は、イントラ予測、インター予測、およびアフィン予測などの様々な予測方法間のレートひずみ結果を比較し、アフィン予測が様々なテストされた予測モードのうちで最良のレートひずみ結果を生じると決定し得る。

[0133]動き推定ユニット４２が第１のおよび第２の動きベクトルを決定した後、ビデオエンコーダ２０は、第１の動きベクトルについて第１の動きベクトル予測子（ＭＶＰ）を計算し得る（１０２）。第１のＭＶＰは、隣接ブロックの動きベクトルに対応し得る。ビデオエンコーダ２０は、次いで、第１の動きベクトルと第１の動きベクトル予測子との間の差として第１の動きベクトル差（ＭＶＤ）を計算し得る（１０４）。特に、ビデオエンコーダ２０は、それぞれ、動きベクトルとＭＶＤとのｘ成分とｙ成分との両方の間の差を計算し得る。

[0134]ビデオエンコーダ２０は、次いで、第２の動きベクトルについて第２のＭＶＰを決定し得る（１０６）。ビデオエンコーダ２０は、さらに、第２の動きベクトルと第２のＭＶＤとの間の差として第２のＭＶＤを計算し得る（１０８）。

[0135]動き補償ユニット４４はまた、現在のブロックのための予測ブロックを生成するためにアフィン予測を使用して現在のブロックを予測し得る（１１０）。例として２つの動きベクトルについて説明したが、予測ブロックを生成するためにアフィン予測のために３つの動きベクトルが使用され得ることを理解されたい。同様に、ビデオエンコーダ２０は、上記で説明したように、第３の動きベクトルのための本開示の技法によれば第３のＭＶＤと第３のＭＶＰとを生成し得る。

[0136]予測ブロックを生成した後、ビデオエンコーダ２０は、現在のブロックと予測ブロックとの間のピクセルごとの差を表す残差ブロックを計算し得る（１１２）。特に、加算器５０は、現在のブロックと予測ブロックとの間のピクセルごとの差を計算し得る。ビデオエンコーダ２０は、次いで、現在のブロックを符号化するために第１のＭＶＤと、第２のＭＶＤと、残差ブロックとを符号化し得る（１１４）。すなわち、本開示の技法によれば、ビデオエンコーダ２０は、たとえば、マージモードまたはＡＭＶＰモードなどの動きベクトル予測技法を使用して第１のＭＶＤを符号化し、第１のＭＶＤから第２のＭＶＤを予測することによって第２のＭＶＤを符号化し得る。したがって、第２のＭＶＤを符号化するために、ビデオエンコーダ２０は、第１のＭＶＤと第２のＭＶＤとのｘ成分とｙ成分との間の差などの第１のＭＶＤと第２のＭＶＤとの間の差を表すデータを符号化し得る。残差ブロックを符号化するために、変換処理ユニット５２は、残差ブロックを変換し得、量子化ユニット５４は、得られた変換ブロックの変換係数を量子化し得、エントロピー符号化ユニット５６は、得られた量子化された変換係数をエントロピー符号化し得る。

[0137]このようにして、図１１の方法は、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）との間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングする（すなわち、符号化する）ことと、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングする（すなわち、符号化する）こととを含む方法の一例を表す。図１１の方法を実行することによって、第２のＭＶＤが第１のＭＶＤから予測されるので第２のＭＶＤを表すデータがより小さくなり得るので、ビデオエンコーダ２０は、前の技法を実行するときより良い帯域幅効率であるビットストリームを生成し得る。

[0138]図１２は、本開示の技法による、ビデオデータの現在のブロックを復号する例示的な方法を示すフローチャートである。図１２の方法について、例として図６および図８のビデオデコーダ３０に関して説明する。ただし、他のデバイスが、この方法または同様の方法の技法を実行するように構成され得ることを理解されたい。

[0139]ビデオデコーダ３０は、現在のブロックの第１の動きベクトル差（ＭＶＤ）、第２のＭＶＤ、および残差ブロックを復号し得る（１２０）。すなわち、本開示の技法によれば、ビデオデコーダ３０は、たとえば、マージモードまたはＡＭＶＰモードなどの動きベクトル予測技法を使用して第１のＭＶＤを復号し、第１のＭＶＤから第２のＭＶＤを予測することによって第２のＭＶＤを復号し得る。したがって、第２のＭＶＤを復号するために、ビデオデコーダ３０は、第１のＭＶＤと第２のＭＶＤとのｘ成分とｙ成分との間の差などの第１のＭＶＤと第２のＭＶＤとの間の差を表すデータを復号し得る。残差ブロックを復号するために、エントロピー復号ユニット７０は、量子化された変換係数をエントロピー復号し、逆量子化ユニット７６は、変換係数を逆量子化し、逆変換ユニット７８は、残差ブロックを再生するために変換係数を逆変換し得る。

[0140]動き補償ユニット７２は、次いで、現在のブロックの第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）を決定し（１２２）、第１のＭＶＰから第１の動きベクトルを計算し得る（１２４）。特に、動き補償ユニット７２は、第１の動きベクトルを計算するために第１のＭＶＰに第１のＭＶＤを加算し得る。動き補償ユニット７２は、同様に、現在のブロックの第２の動きベクトルのための第２のＭＶＰを決定し（１２６）、第２のＭＶＰから第２の動きベクトルを計算し得る（１２８）。特に、動き補償ユニット７２は、第２の動きベクトルを計算するために第２のＭＶＰに第２のＭＶＤを加算し得る。いくつかの例では、第３の動きベクトルが含まれ得、その場合、エントロピー復号ユニット７０は、たとえば、第３の動きベクトルのための第１のＭＶＤと第３のＭＶＤとの間の差を表すデータをエントロピー復号し得、動き補償ユニット７２は、同様の様式で第３のＭＶＤと第３のＭＶＰとから第３の動きベクトルを計算し得る。

[0141]動き補償ユニット７２は、次いで、第１のおよび第２の（および潜在的に第３の）動きベクトルを使用して、たとえば、アフィン動き予測に従って現在のブロックを予測し得る（１３０）。ビデオデコーダ３０は、次いで、たとえば、加算器８０に、ピクセルごとに残差ブロックの値に予測ブロックの値を加算させることによって現在のブロックを復号し得る（１３２）。

[0142]このようにして、図１２の方法は、アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと、第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）と、の間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングする（すなわち、復号する）ことと、現在のブロックの第２の動きベクトルについて第１のＭＶＤから第２のＭＶＤを予測することと、第１の動きベクトルと第２の動きベクトルとに従ってアフィン予測を使用して現在のブロックをコーディングする（すなわち、復号する）ことと、を含む方法の一例を表す。図１２の方法を実行することによって、第２のＭＶＤが第１のＭＶＤから予測されるので第２のＭＶＤを表すデータがより小さくなり得るので、ビデオデコーダ３０は、前の技法を実行するときより良い帯域幅効率であるビットストリームを復号し得る。

[0143]上記例に応じて、本明細書で説明された技法のいずれかのいくつかの行為またはイベントが、異なるシーケンスで実施され得、追加、マージ、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが本技法の実施のために必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実施され得る。

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

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

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

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

[0148]様々な例について説明した。これらおよび他の例は添付の特許請求の範囲内に入る。

Claims (30)

1. ビデオデータをコーディングする方法であって、
   アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと、前記第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）と、の間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、
   前記現在のブロックの第２の動きベクトルについて、前記第１のＭＶＤから第２のＭＶＤを予測することと、
   前記第１の動きベクトルと前記第２の動きベクトルとに従ってアフィン予測を使用して前記現在のブロックをコーディングすることと、
   を備える方法。
2. 前記第１のＭＶＤは、水平成分（ＭＶＤｘ１）と垂直成分（ＭＶＤｙ１）とを含み、
   前記第１のＭＶＰは、水平成分（ＭＶＰｘ１）と垂直成分（ＭＶＰｙ１）とを含み、
   前記第１の動きベクトルは、水平成分（ＭＶｘ１）と垂直成分（ＭＶｙ１）とを含み、
   ＭＶＤｘ１＝ＭＶｘ１−ＭＶＰｘ１、および、ＭＶＤｙ１＝ＭＶｙ１−ＭＶＰｙ１である、
   請求項１に記載の方法。
3. 前記現在のブロックをコーディングすることは、４つのパラメータアフィンモデル
   

   

   に従って前記現在のブロックをコーディングすることを備える、請求項１に記載の方法。
4. 前記現在のブロックの第３の動きベクトルについて、前記第１のＭＶＤまたは前記第２のＭＶＤのうちの少なくとも１つから第３のＭＶＤを予測すること、をさらに備え、
   前記現在のブロックをコーディングすることは、前記第１の動きベクトルと、前記第２の動きベクトルと、前記第３の動きベクトルとに従ってアフィン予測を使用して前記現在のブロックをコーディングすることを備える、請求項１に記載の方法。
5. 前記現在のブロックをコーディングすることは、６つのパラメータアフィンモデル
   

   

   に従って前記現在のブロックをコーディングすることを備える、請求項４に記載の方法。
6. 前記第１の動きベクトルは、前記現在のブロックの左上隅から発生し、前記第２の動きベクトルは、前記現在のブロックの右上隅から発生する、請求項１に記載の方法。
7. 前記第１の動きベクトルと前記第２の動きベクトルとのための制御点を定義するデータをコーディングすることをさらに備える、請求項１に記載の方法。
8. 前記現在のブロックの形状に基づいて前記第１の動きベクトルと前記第２の動きベクトルとのための制御点を決定することをさらに備える、請求項１に記載の方法。
9. 前記第１の動きベクトルと前記第２の動きベクトルとのための制御点を暗黙的に導出することをさらに備える、請求項１に記載の方法。
10. 前記第２のＭＶＤのためのＭＶＤ’２を表すデータをコーディングすること、をさらに備え、ＭＶＤ’２は、前記第１のＭＶＤに対する前記第２のＭＶＤの残差値を表す、請求項１に記載の方法。
11. 前記第１のＭＶＤは、ＭＶＤ１を備え、前記第２のＭＶＤは、ＭＶＤ２を備え、ｗは、重み付け値を備え、ＭＶＤ’２＝ＭＶＤ１−ｗ＊ＭＶＤ２である、請求項１０に記載の方法。
12. 前記第１のＭＶＤは、ＭＶＤ１を備え、前記第２のＭＶＤは、ＭＶＤ２を備え、０．５の重み付け値の場合、ＭＶＤ’２＝ＭＶＤ２−（（ＭＶＤ１＋１）＞＞１）である、請求項１０に記載の方法。
13. 前記第１のＭＶＤは、ＭＶＤ１を備え、前記第２のＭＶＤは、ＭＶＤ２を備え、０．２５の重み付け値の場合、ＭＶＤ’２＝ＭＶＤ２−（（ＭＶＤ１＋２）＞＞２）である、請求項１０に記載の方法。
14. 前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定すること、をさらに備え、
    前記第１のＭＶＤから前記第２のＭＶＤを予測することは、前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することに応答して、前記第１のＭＶＤから前記第２のＭＶＤを予測することを備える、請求項１に記載の方法。
15. 前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することは、前記現在のブロックの形状に基づいて、前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することを備える、請求項１４に記載の方法。
16. 前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することは、前記現在のブロックのための動き予測方法に基づいて、前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することを備える、請求項１４に記載の方法。
17. 前記第１のＭＶＤから前記第２のＭＶＤを予測すると決定することは、前記動き予測方法がアフィンマージモードであると決定することを備える、請求項１６に記載の方法。
18. 前記第２のＭＶＤは、水平成分（ＭＶＤ２^x）と垂直成分（ＭＶＤ２^y）とを含み、前記第２のＭＶＤを予測することは、ＭＶＤ２^yを予測することとは別様にＭＶＤ２^xを予測することを備える、請求項１に記載の方法。
19. 前記第１のＭＶＤまたは前記第２のＭＶＤのうちの少なくとも１つから、前記現在のブロックの第３の動きベクトルのための第３のＭＶＰを生成することをさらに備える、請求項１に記載の方法。
20. 前記第１のＭＶＤは、ＭＶＤ１を備え、前記方法は、
    前記現在のブロックの１つまたは複数の隣接ブロックの動きベクトルから、前記第２の動きベクトルのための第２の中間ＭＶＰ（ＭＶＰ’２）を決定することと、
    ＭＶＰ’２とＭＶＤ１とから、前記第２の動きベクトルのための第２のＭＶＰ（ＭＶＰ２）を生成することと、
    をさらに備える、請求項１に記載の方法。
21. 前記現在のブロックの第３の動きベクトルについて、前記第１のＭＶＤと第３のＭＶＤとから前記第２の動きベクトルのための第２のＭＶＰを生成すること、ここにおいて、前記第２のＭＶＰは、ＭＶＰ２を備え、前記第１のＭＶＤは、ＭＶＤ１を備え、前記第３のＭＶＤは、ＭＶＤ３を備える、をさらに備え、前記方法は、
    前記現在のブロックの１つまたは複数の隣接ブロックの動きベクトルから、前記第２の動きベクトルのための第２の中間ＭＶＰ（ＭＶＰ’２）を決定することをさらに備え、
    ＭＰＶ２を生成することは、ＭＶＰ２＝ＭＶＰ’２＋（（ＭＶＤ１＋ＭＶＤ３）＞＞１）としてＭＶＰ２を生成することを備える、請求項１に記載の方法。
22. 前記現在のブロックをコーディングすることは、前記現在のブロックを復号することを備え、前記現在のブロックを復号することは、
    前記第１の動きベクトルを再構成するために、前記第１のＭＶＰに前記第１のＭＶＤを加算することと、
    前記第２の動きベクトルのための第２のＭＶＰを決定することと、
    前記第１のＭＶＤからの前記予測を使用して前記第２のＭＶＤを再構成することと、
    前記第２の動きベクトルを再構成するために、前記第２のＭＶＰに前記第２のＭＶＤを加算することと、
    前記第１の動きベクトルと前記第２の動きベクトルとを使用して、前記現在のブロックのための予測ブロックを形成することと、
    前記現在のブロックのための残差ブロックを復号することと、
    前記現在のブロックを再構成するために、前記残差ブロックと前記予測ブロックとを加算することと、
    を備える、請求項１に記載の方法。
23. 前記現在のブロックをコーディングすることは、前記現在のブロックを符号化することを備え、前記現在のブロックを符号化することは、
    前記第１のＭＶＤを生成するために、前記第１の動きベクトルから前記第１のＭＶＰを減算することと、
    前記第２の動きベクトルのための第２のＭＶＰを決定することと、
    前記第２のＭＶＤを生成するために、前記第２のＭＶＰから前記第２の動きベクトルを減算することと、
    前記第１のＭＶＤを符号化することと、
    前記第１のＭＶＤから予測された前記第２のＭＶＤを表すデータを符号化することと、
    前記第１の動きベクトルと前記第２の動きベクトルとを使用して、前記現在のブロックのための予測ブロックを形成することと、
    残差ブロックを生成するために、前記現在のブロックから前記予測ブロックを減算することと、
    前記残差ブロックを符号化することと、
    を備える、請求項１に記載の方法。
24. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    回路に実装された１つまたは複数のプロセッサと、を備え、前記１つまたは複数のプロセッサは、
    アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと、前記第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）と、の間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、
    前記現在のブロックの第２の動きベクトルについて、前記第１のＭＶＤから第２のＭＶＤを予測することと、
    前記第１の動きベクトルと前記第２の動きベクトルとに従ってアフィン予測を使用して前記現在のブロックをコーディングすることと、
    を行うように構成された、デバイス。
25. 前記１つまたは複数のプロセッサは、
    前記第１の動きベクトルを再構成するために、前記第１のＭＶＰに前記第１のＭＶＤを加算することと、
    前記第２の動きベクトルのための第２のＭＶＰを決定することと、
    前記第１のＭＶＤからの前記予測を使用して前記第２のＭＶＤを再構成することと、
    前記第２の動きベクトルを再構成するために、前記第２のＭＶＰに前記第２のＭＶＤを加算することと、
    前記第１の動きベクトルと前記第２の動きベクトルとを使用して、前記現在のブロックのための予測ブロックを形成することと、
    前記現在のブロックのための残差ブロックを復号することと、
    前記現在のブロックを再構成するために、前記残差ブロックと前記予測ブロックとを加算することと、
    を行うように構成された、請求項２４に記載のデバイス。
26. 前記１つまたは複数のプロセッサは、
    前記第１のＭＶＤを生成するために、前記第１の動きベクトルから前記第１のＭＶＰを減算することと、
    前記第２の動きベクトルのための第２のＭＶＰを決定することと、
    前記第２のＭＶＤを生成するために、前記第２のＭＶＰから前記第２の動きベクトルを減算することと、
    前記第１のＭＶＤを符号化することと、
    前記第１のＭＶＤから予測された前記第２のＭＶＤを表すデータを符号化することと、
    前記第１の動きベクトルと前記第２の動きベクトルとを使用して、前記現在のブロックのための予測ブロックを形成することと、
    残差ブロックを生成するために、前記現在のブロックから前記予測ブロックを減算することと、
    前記残差ブロックを符号化することと、
    を行うように構成された、請求項２４に記載のデバイス。
27. 復号されたビデオデータを表示するように構成されたディスプレイをさらに備える、請求項２４に記載のデバイス。
28. 前記デバイスが、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、またはセットトップボックスのうちの１つまたは複数を備える、請求項２４に記載のデバイス。
29. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータをコーディングするためのデバイスのプロセッサに、
    アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと、前記第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）と、の間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングすることと、
    前記現在のブロックの第２の動きベクトルについて、前記第１のＭＶＤから第２のＭＶＤを予測することと、
    前記第１の動きベクトルと前記第２の動きベクトルとに従ってアフィン予測を使用して前記現在のブロックをコーディングすることと、
    を行わせる、コンピュータ可読記憶媒体。
30. ビデオデータをコーディングするためのデバイスであって、
    アフィン予測を使用して予測されるビデオデータの現在のブロックの第１の動きベクトルと、前記第１の動きベクトルのための第１の動きベクトル予測子（ＭＶＰ）と、の間の差を表す第１の動きベクトル差（ＭＶＤ）をコーディングするための手段と、
    前記現在のブロックの第２の動きベクトルについて、前記第１のＭＶＤから第２のＭＶＤを予測するための手段と、
    前記第１の動きベクトルと前記第２の動きベクトルとに従ってアフィン予測を使用して前記現在のブロックをコーディングするための手段と、
    を備えるデバイス。

Images