JP2021530904A - ビデオコーディングの波面処理のための複数履歴ベース非隣接ｍｖｐ - Google Patents

Abstract

ビデオデータをコーディングするための例となるデバイスは、ビデオデータを記憶するように構成されたメモリと、回路で実施され、ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、メモリの第２の履歴ＭＶＰバッファをリセットすることと、第２の履歴ＭＶＰバッファをリセットした後に、ピクチャの第２のＣＴＵラインの動き情報を第２の履歴ＭＶＰバッファに記憶することと、ここで、前記第２のＣＴＵラインは、前記第１のＣＴＵラインとは異なる、を行うように構成された１つまたは複数の処理ユニットとを含む。いくつかの例では、１つまたは複数のプロセッサによって実行されるビデオコーディングプロセスの別個のスレッドがそれぞれのＣＴＵラインを処理し得る。【選択図】 図１８

Description

関連出願

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

[0002] 本開示は、ビデオ符号化およびビデオ復号を含むビデオコーディングに関する。

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

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

[0005] 概して、本開示は、ビデオデータのブロックの動き情報をコーディングするための技法を説明する。これらの技法は、波面並列処理中に使用され得る。動き情報は、履歴動きベクトル予測子（ＨＭＶＰ：history motion vector predictors）から予測される動きベクトルを含み得る。ＨＭＶＰ候補は、前にコーディングされたブロックの動き情報を指し得る。ビデオコーダ（エンコーダまたはデコーダ）は、コーディング（符号化または復号）プロセス中、複数のＨＭＶＰ候補を有するテーブルを維持し得る。ビデオコーダは、新しいスライスが発生すると、テーブルを空にし得る。インターコーディングされたブロックが存在するとき、ビデオコーダは、インターコーディングされたブロックに関連する動き情報をテーブルに付加し得る。

[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] コンピュータ読取可能な媒体１１０は、符号化ビデオデータをソースデバイス１０２から宛先デバイス１１６に伝送する能力がある任意のタイプの媒体またはデバイスを表し得る。一例において、コンピュータ読取可能な媒体１１０は、ソースデバイス１０２が、例えば、無線周波数ネットワークまたはコンピュータベースネットワークを介して、リアルタイムで符号化ビデオデータを宛先デバイス１１６に直接送信することを可能にする通信媒体を表す。出力インターフェース１０８は、符号化ビデオデータを含む送信信号を変調し得、入力インターフェース１２２は、ワイヤレス通信プトロコルのような通信規格に従って、受信した送信信号を復調し得る。通信媒体は、無線周波数（ＲＦ：radio frequency）スペクトルまたは１もしくは複数の物理伝送線のような任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットのようなグローバルネットワークといった、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１０２から宛先デバイス１１６への通信を容易にするのに有用であり得る任意の他の機器を含み得る。

[0036] いくつかの例において、ソースデバイス１０２は、出力インターフェース１０８から記憶デバイス１１２に符号化データを出力し得る。同様に、宛先デバイス１１６は、入力インターフェース１２２を介して記憶デバイス１１２からの符号化データにアクセスし得る。記憶デバイス１１２は、ハードドライブ、ブルーレイディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性もしくは非揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、様々な分配型の、または局所的にアクセスされるデータ記憶媒体のうちの任意のものを含み得る。

[0037] いくつかの例において、ソースデバイス１０２は、符号化ビデオデータを、ファイルサーバ１１４に、またはソースデバイス１０２によって生成された符号化ビデオを記憶し得る別の中間記憶デバイスに出力し得る。宛先デバイス１１６は、ストリーミングまたはダウンロードを介してファイルサーバ１１４からの記憶されたビデオデータにアクセスし得る。ファイルサーバ１１４は、符号化ビデオデータを記憶するおよび符号化ビデオデータを宛先デバイス１１６に送信する能力がある任意のタイプのサーバデバイスであり得る。ファイルサーバ１１４は、（例えば、ウェブサイトの）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ：File Transfer Protocol）サーバ、コンテンツ配信ネットワークデバイス、またはネットワーク接続ストレージ（ＮＡＳ）デバイスを表し得る。宛先デバイス１１６は、インターネット接続を含む任意の標準的なデータ接続を通してファイルサーバ１１４からの符号化ビデオデータにアクセスし得る。これは、ファイルサーバ１１４に記憶されている符号化ビデオデータにアクセスするのに好適なワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（例えば、デジタル加入者回線（ＤＳＬ：digital subscriber line）、ケーブルモデム、等）、または両方の組合せを含み得る。ファイルサーバ１１４および入力インターフェース１２２は、ストリーミング送信プロトコル、ダウンロード送信プロトコル、またはそれらの組合せに従って動作するように構成され得る。

[0038] 出力インターフェース１０８および入力インターフェース１２２は、ワイヤレス送信機／受信機、モデム、ワイヤードネットワーキング構成要素（例えば、イーサネット（登録商標）カード）、様々なＩＥＥＥ８０２．１１規格のうちの任意のものに従って動作するワイヤレス通信構成要素、または他の物理的構成要素を表し得る。出力インターフェース１０８および入力インターフェース１２２がワイヤレス構成要素を備える例にでは、出力インターフェース１０８および入力インターフェース１２２が、４Ｇ、４Ｇ−ＬＴＥ（登録商標）（ロングタームエボリューション）、ＬＴＥアドバンスド、５Ｇ、または同様のもののようなセルラ通信規格に従って、符号化ビデオデータのようなデータを転送するように構成され得る。出力インターフェース１０８がワイヤレス送信機を備えるいくつかの例において、出力インターフェース１０８および入力インターフェース１２２は、ＩＥＥＥ８０２．１１仕様、ＩＥＥＥ８０２．１５仕様（例えば、ＺｉｇＢｅｅ（登録商標））、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格、または同様のもののような他のワイヤレス規格に従って、符号化ビデオデータのようなデータを転送するように構成され得る。いくつかの例において、ソースデバイス１０２および／または宛先デバイス１１６は、それぞれのシステムオンチップ（ＳｏＣ：system-on-a-chip）デバイスを含み得る。例えば、ソースデバイス１０２は、ビデオエンコーダ２００および／または出力インターフェース１０８に起因する機能性を実行するためのＳｏＣデバイスを含み得、宛先デバイス１１６は、ビデオデコーダ３００および／または入力インターフェース１２２に起因する機能性を実行するためのＳｏＣデバイスを含み得る。

[0039] 本開示の技法は、無線テレビ放送、ケーブルテレビ放送、衛星テレビ放送、動的適応型ストリーミングオーバＨＴＴＰ（ＤＡＳＨ：dynamic adaptive streaming over HTTP）のようなインターネットストリーミングビデオ送信、データ記憶媒体上で符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、様々なマルチメディアアプリケーションのうちの任意のものをサポートして、ビデオコーディングに適用され得る。

[0040] 宛先デバイス１１６の入力インターフェース１２２は、コンピュータ読取可能な媒体１１０（例えば、記憶デバイス１１２、ファイルサーバ１１４、または同様のもの）から符号化ビデオビットストリームを受信する。符号化ビデオビットストリームは、ビデオブロックまたは他のコーディングされる単位（例えば、スライス、ピクチャ、ピクチャのグループ、シーケンス、または同様のもの）の特性および／または処理を説明する値を有するシンタックス要素のような、ビデオエンコーダ２００によって定義され、ビデオデコーダ３００によっても使用されるシグナリング情報を含み得る。ディスプレイデバイス１１８は、復号ビデオデータの復号ピクチャをユーザに表示する。ディスプレイデバイス１１８は、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような様々なディスプレイデバイスのうちの任意のものを表し得る。

[0041] 図１には示されていないが、いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は各々、オーディオエンコーダおよび／またはオーディオデコーダと一体化され得、共通データストリーム中のオーディオとビデオの両方を含む多重化ストリームを処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよび／またはソフトウェアを含み得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ：user datagram protocol）のような他のプロトコルに準拠し得る。

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

[0043] ビデオエンコーダ２００およびビデオデコーダ３００は、高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれるＩＴＵ−Ｔ Ｈ．２６５のようなビデオコーディング規格またはそれに対する拡張、例えば、マルチビューおよび／またはスケーラブルビデオコーディング拡張に従って動作し得る。代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、ＪＥＭ（Joint Exploration Test Model）またはＶＶＣ（Versatile Video Coding）とも呼ばれるＩＴＵ−Ｔ Ｈ．２６６のような他のプロプライエタリ規格または業界規格に従って動作し得る。ＶＶＣ規格の最近のドラフトは、Ｂｒｏｓｓ等による「Versatile Video Coding （Draft 5)」，ＩＴＵ−Ｔ ＳＧ １６ ＷＰ ３およびＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ ２９／ＷＧ １１からなるＪＶＥＴ（Joint Video Experts Team），第１４回会合：ジュネーブ、スイス、２０１９年３月１９−２７日、ＪＶＥＴ−Ｎ１００１−ｖ３（以下、「ＶＶＣドラフト５」）、に記載されている。しかしながら、本開示の技法は、どの特定のコーディング規格にも限定されるものではない。

[0044] 概して、ビデオエンコーダ２００およびビデオデコーダ３００は、ピクチャのブロックベースコーディングを実行し得る。「ブロック」という用語は、一般に、処理される（例えば、符号化されるか、復号されるか、それ以外の場合には符号化および／または復号プロセスにおいて使用される）べきデータを含む構造を指す。例えば、ブロックは、ルミナンスおよび／またはクロミナンスデータのサンプルの二次元マトリックスを含み得る。概して、ビデオエンコーダ２００およびビデオデコーダ３００は、ＹＵＶ（例えば、Ｙ、Ｃｂ、Ｃｒ）フォーマットで表されるビデオデータをコーディングし得る。すなわち、ピクチャのサンプルの赤、緑、および青（ＲＧＢ）データをコーディングするのではなく、ビデオエンコーダ２００およびビデオデコーダ３００は、輝度成分とクロミナンス成分とをコーディングし得、ここで、クロミナンス成分は、赤の色相と青の色相の両方のクロミナンス成分を含み得る。いくつかの例において、ビデオエンコーダ２００は、符号化の前に、受信したＲＧＢフォーマットのデータをＹＵＶ表現に変換し、ビデオデコーダ３００は、ＹＵＶ表現をＲＧＢフォーマットに変換する。代替的に、前処理ユニットおよび後処理ユニット（図示せず）がこれらの変換を実行し得る。

[0045] 本開示は、一般に、ピクチャのデータを符号化または復号するプロセスを含むために、ピクチャのコーディング（例えば、符号化および復号）に言及し得る。同様に、本開示は、ブロックのためのデータを符号化または復号するプロセス、例えば、予測および／または残差コーディングを含むために、ピクチャのブロックのコーディングに言及し得る。符号化ビデオビットストリームは、一般に、コーディング決定（例えば、コーディングモード）とブロックへのピクチャの区分とを表すシンタックス要素のための一連の値を含む。ゆえに、ピクチャまたはブロックをコーディングすることへの言及は、一般に、ピクチャまたはブロックを形成するシンタックス要素のための値をコーディングすることと理解されるべきである。

[0046] ＨＥＶＣは、コーディング単位（ＣＵ）、予測単位（ＰＵ：prediction units）、および変換単位（ＴＵ：transform units）を含む様々なブロックを定義する。ＨＥＶＣによれば、ビデオコーダ（例えばビデオエンコーダ２００）は、四分木構造に従ってコーディングツリー単位（ＣＴＵ）をＣＵに区分する。すなわち、ビデオコーダは、ＣＴＵおよびＣＵを４つの等しい重複しない正方形に区分し、四分木の各ノードは、子ノードを有さないかまたは４つの子ノードを有するかのいずれかである。子ノードのないノードは、「リーフノード」と呼ばれ得、そのようなリーフノードのＣＵは、１つまたは複数のＰＵおよび／または１つまたは複数のＴＵを含み得る。ビデオコーダは、ＰＵおよびＴＵをさらに区分し得る。例えば、ＨＥＶＣでは、残差四分木（ＲＱＴ：residual quadtree）が、ＴＵの区分を表す。ＨＥＶＣでは、ＰＵがインター予測データを表し、ＴＵが残差データを表す。イントラ予測されるＣＵは、イントラモードインジケーションのようなイントラ予測情報を含む。

[0047] 別の例として、ビデオエンコーダ２００およびビデオデコーダ３００は、ＪＥＭまたはＶＶＣに従って動作するように構成され得る。ＪＥＭまたはＶＶＣによれば、ビデオコーダ（例えばビデオエンコーダ２００）は、ピクチャを複数のコーディングツリー単位（ＣＴＵ）に区分する。ビデオエンコーダ２００は、四分木−二分木（ＱＴＢＴ：quadtree-binary tree）構造またはマルチタイプツリー（ＭＴＴ：Multi-Type Tree）構造のようなツリー構造に従ってＣＴＵを区分し得る。ＱＴＢＴ構造は、ＨＥＶＣのＣＵ、ＰＵ、およびＴＵ間の区別のような複数の区分タイプという概念を除去する。ＱＴＢＴ構造は、四分木区分に従って区分される第１のレベルと、二分木区分に従って区分される第２のレベルという２つのレベルを含み得る。ＱＴＢＴ構造のルートノードは、ＣＴＵに対応する。二分木のリーフノードは、コーディング単位（ＣＵ）に対応する。

[0048] ＭＴＴ区分構造では、ブロックが、四分木（ＱＴ）区分、二分木（ＢＴ：binary tree）区分、および１つまたは複数のタイプの三分木（ＴＴ：triple tree）区分を使用して区分され得る。三分木区分は、ブロックが３つのサブブロックに分割される区分である。いくつかの例では、三分木区分が、中心を通って元のブロックを分割することなく、ブロックを３つのサブブロックに分割する。ＭＴＴにおける区分タイプ（例えば、ＱＴ、ＢＴ、およびＴＴ）は、対称または非対称であり得る。

[0049] いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は、輝度成分およびクロミナンス成分の各々を表すために単一のＱＴＢＴまたはＭＴＴ構造を使用し得るが、他の例において、ビデオエンコーダ２００およびビデオデコーダ３００は、輝度成分に対して１つのＱＴＢＴまたはＭＴＴ構造および両方のクロミナンス成分に対して別のＱＴＢＴまたはＭＴＴ構造（または、それぞれのクロミナンス成分に対して２つのＱＴＢＴまたはＭＴＴ構造）など、２つ以上のＱＴＢＴまたはＭＴＴ構造を使用し得る。

[0050] ビデオエンコーダ２００およびビデオデコーダ３００は、ＨＥＶＣによる四分木区分、ＪＥＭによるＱＴＢＴ区分、または他の区分構造を使用するように構成され得る。説明のために、本開示の技法の説明は、ＱＴＢＴ区分に関して提示される。しかしながら、本開示の技法は、四分木区分、または他のタイプの区分を使用するように構成されたビデオコーダにも適用され得ることは理解されるべきである。

[0051] 本開示は、垂直次元および水平次元の観点からブロック（例えばＣＵまたは他のビデオブロック）のサンプル次元を指すために、例えば、１６×１６（16x16）のサンプルまたは１６×１６（16 by 16）のサンプルのように、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」を同義で使用し得る。概して、１６×１６のＣＵは、垂直方向に１６個のサンプルを有し（ｙ＝１６）、水平方向に１６個のサンプルを有する（ｘ＝１６）であろう。同様に、Ｎ×ＮのＣＵは、一般に、垂直方向にＮ個のサンプルを有し、水平方向にＮ個のサンプルを有し、ここで、Ｎは、非負の整数値を表す。ＣＵ中のサンプルは、行および列に配置され得る。さらに、ＣＵは、水平方向において、必ずしも、垂直方向と同じ数のサンプルを有する必要はない。例えば、ＣＵは、Ｎ×Ｍのサンプルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。

[0052] ビデオエンコーダ２００は、予測情報および／または残差情報並びに他の情報を表すＣＵのためのビデオデータを符号化する。予測情報は、ＣＵのための予測ブロックを形成するためにＣＵがどのように予測されるべきかを示す。残差情報は、一般に、符号化の前のＣＵのサンプルと予測ブロックとの間のサンプルごとの差分を表す。

[0053] ＣＵを予測するために、ビデオエンコーダ２００は、一般に、インター予測またはイントラ予測を通してＣＵのための予測ブロックを形成し得る。インター予測は、一般に、前にコーディングされたピクチャのデータからＣＵを予測することを指し、イントラ予測は、一般に、同じピクチャの、前にコーディングされたデータからＣＵを予測することを指す。インター予測を実行するために、ビデオエンコーダ２００は、１つまたは複数の動きベクトルを使用して予測ブロックを生成し得る。ビデオエンコーダ２００は、一般に、例えば、ＣＵと参照ブロックとの間の差分の観点から、ＣＵに厳密に一致する参照ブロックを識別するために動き探索を実行し得る。ビデオエンコーダ２００は、参照ブロックが現在ＣＵに厳密に一致するかどうかを決定するために、差分絶対値和（ＳＡＤ：sum of absolute difference）、差分二乗和（ＳＳＤ：sum of squared differences）、平均絶対値差分（ＭＡＤ：mean absolute difference）、平均二乗差分（ＭＳＤ：mean squared differences）、または他のそのような差分算出を使用して差分メトリックを算出し得る。いくつかの例において、ビデオエンコーダ２００は、単方向予測または双方向予測を使用して現在ＣＵを予測し得る。

[0054] ＪＥＭはまた、インター予測モードとみなされ得るアフィン動き補償モードを提供する。アフィン動き補償モードにおいて、ビデオエンコーダ２００は、ズームインまたはズームアウト、回転、射影運動、または他の不規則な動作タイプのような非並進運動を表す２つ以上の動きベクトルを決定し得る。

[0055] イントラ予測を実行するために、ビデオエンコーダ２００は、予測ブロックを生成するためのイントラ予測モードを選択し得る。ＪＥＭは、平面モードおよびＤＣモード並びに様々な方向性モードを含む６７個のイントラ予測モードを提供する。概して、ビデオエンコーダ２００は、現在ブロックのサンプルが予測される、現在ブロック（例えば、ＣＵのブロック）に隣接するサンプルを説明するイントラ予測モードを選択する。ビデオエンコーダ２００がラスタ走査順序で（左から右、上から下に）ＣＴＵおよびＣＵをコーディングすると仮定すると、そのようなサンプルは、一般に、現在ブロックと同じピクチャ中で現在ブロックの上、左上、または左にあり得る。

[0056] ビデオエンコーダ２００は、現在ブロックのための予測モードを表すデータを符号化する。例えば、インター予測モードの場合、ビデオエンコーダ２００は、様々な利用可能なインター予測モードのうちのどれが使用されるかを表すデータ、並びに対応するモードの動き情報を符号化し得る。単方向または双方向インター予測の場合、例えば、ビデオエンコーダ２００は、高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）またはマージモードを使用して動きベクトルを符号化し得る。ビデオエンコーダ２００は、同様のモードを使用して、アフィン動き補償モードのための動きベクトルを符号化し得る。

[0057] ブロックのイントラ予測またはインター予測のような予測に続いて、ビデオエンコーダ２００は、ブロックのための残差データを算出し得る。残差ブロックのような残差データは、ブロックと、対応する予測モードを使用して形成された、そのブロックの予測ブロックとの間のサンプルごとの差分を表す。ビデオエンコーダ２００は、サンプル領域ではなく変換領域において変換データを作り出すために、残差ブロックに１つまたは複数の変換を適用し得る。例えば、ビデオエンコーダ２００は、離散コサイン変換（ＤＣＴ：discrete cosine transform）、整数変換、ウェーブレット変換、または概念的に同様の変換を残差ビデオデータに適用し得る。追加的に、ビデオエンコーダ２００は、第１の変換に続いて、モード依存分離不可能二次変換（ＭＤＮＳＳＴ：mode-dependent non-separable secondary transform）、信号依存変換、カルーネンレーベ変換（ＫＬＴ：Karhunen-Loeve transform）、または同様のもののような二次変換を適用し得る。ビデオエンコーダ２００は、１つまたは複数の変換の適用に続いて変換係数を作り出す。

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

[0059] 量子化に続いて、ビデオエンコーダ２００は、変換係数を走査し、量子化された変換係数を含む二次元マトリックスから一次元ベクトルを作り出し得る。走査は、より高いエネルギー（そのため、より低い周波数）の係数をベクトルの前方に置き、より低いエネルギー（そのため、より高い周波数）の変換係数をベクトルの後方に置くように設計され得る。いくつかの例において、ビデオエンコーダ２００は、直列化されたベクトルを作り出すために、あらかじめ定義された走査順序を利用して、量子化された変換係数を走査し、次いで、このベクトルの量子化された変換係数をエントロピー符号化し得る。他の例において、ビデオエンコーダ２００は、適応走査を実行し得る。一次元ベクトルを形成するために、量子化された変換係数を走査した後、ビデオエンコーダ２００は、例えば、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）にしたがって、一次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２００はまた、ビデオデータを復号する際にビデオデコーダ３００が使用するために、符号化ビデオデータに関連するメタデータを説明するシンタックス要素の値をエントロピー符号化し得る。

[0060] ＣＡＢＡＣを実行するために、ビデオエンコーダ２００は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、例えば、シンボルの隣接する値がゼロ値であるか否かに関係し得る。確率の決定は、シンボルに割り当てられたコンテキストに基づき得る。

[0061] ビデオエンコーダ２００はさらに、例えば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはシーケンスパラメータセット（ＳＰＳ：sequence parameter set）、ピクチャパラメータセット（ＰＰＳ：picture parameter set）、もしくはビデオパラメータセット（ＶＰＳ：video parameter set）のような他のシンタックスデータ中で、ビデオデコーダ３００への、ブロックベースシンタックスデータ、ピクチャベースシンタックスデータ、およびシーケンスベースシンタックスデータのようなシンタックスデータを生成し得る。ビデオデコーダ３００は、対応するビデオデータを復号する方法を決定するために、そのようなシンタックスデータを同様に復号し得る。

[0062] このように、ビデオエンコーダ２００は、符号化ビデオデータ、例えば、ブロック（例えば、ＣＵ）へのピクチャの区分と、ブロックの予測情報および／または残差情報とを説明するシンタックス要素を含むビットストリームを生成し得る。最終的に、ビデオデコーダ３００は、ビットストリームを受信し、符号化ビデオデータを復号し得る。

[0063] 概して、ビデオデコーダ３００は、ビットストリームの符号化ビデオデータを復号するために、ビデオエンコーダ２００によって実行されるものと逆のプロセスを実行する。例えば、ビデオデコーダ３００は、ビデオエンコーダ２００のＣＡＢＡＣ符号化プロセスと逆ではあるが実質的に同じである方法で、ＣＡＢＡＣを使用してビットストリームのシンタックス要素の値を復号し得る。シンタックス要素は、ピクチャの情報をＣＴＵに区分することと、ＣＴＵのＣＵを定義するために、ＱＴＢＴ構造のような対応する区分構造に従って各ＣＴＵを区分することとを定義し得る。シンタックス要素は、ビデオデータのブロック（例えば、ＣＵ）の予測情報および残差情報をさらに定義し得る。

[0064] 残差情報は、例えば、量子化された変換係数によって表され得る。ビデオデコーダ３００は、ブロックのための残差ブロックを再生するために、ブロックの量子化された変換係数を逆量子化および逆変換し得る。ビデオデコーダ３００は、ブロックのための予測ブロックを形成するために、シグナリングされた予測モード（イントラ予測またはインター予測）および関連する予測情報（例えば、インター予測の動き情報）を使用する。ビデオデコーダ３００は、次いで、元のブロックを再生するために、（サンプル単位で）予測ブロックと残差ブロックとを組み合わせ得る。ビデオデコーダ３００は、ブロックの境界に沿った視覚的アーティファクトを低減するためのデブロッキングプロセスの実行のような追加の処理を実行し得る。

[0065] 本開示は、一般に、シンタックス要素のような特定の情報を「シグナリング」することを指し得る。「シグナリング」という用語は、一般に、符号化ビデオデータを復号するために使用されるシンタックス要素および／または他のデータのための値の通信を指し得る。すなわち、ビデオエンコーダ２００は、ビットストリーム中のシンタックス要素の値をシグナリングし得る。概して、シグナリングは、ビットストリームにおいて値を生成することを指す。上述のように、ソースデバイス１０２は、ビットストリームを宛先デバイス１１６に略リアルタイムで伝送し得るか、または宛先デバイス１１６による後の取り出しのためにシンタックス要素を記憶デバイス１１２に記憶するときに行われるように、リアルタイムでなくてもよい。

[0066] 本開示の技法によれば、ビデオエンコーダ２００およびビデオデコーダ３００は、ビデオデータのピクチャをコーディングするときに波面並列処理を実行するように構成され得る。概して、波面並列処理は、別個の処理スレッドを使用してコーディングツリー単位（ＣＴＵ）の個々のラインをコーディングすることを伴い得る。例えば、ビデオエンコーダ２００またはビデオデコーダ３００によって実行される第１のスレッドがＣＴＵの第１のラインを処理し得、第２のスレッドがＣＴＵの第２のラインを処理し得、以下同様である。ＣＴＵをコーディングすることは、とりわけ、同じＣＴＵまたは前にコーディングされたＣＴＵ（例えば、左の隣接ＣＴＵおよび／または上の隣接ＣＴＵ）内の動き情報を指し得る、ＣＴＵの動き予測されたコーディング単位（ＣＵ）の動き情報をコーディングすることを含む。そのような動き情報は、動きベクトル予測子（ＭＶＰ）バッファに記憶され得る。本開示の技法によれば、ビデオエンコーダ２００およびビデオデコーダ３００は、現在ＣＴＵラインのビデオデータをコーディングする前に、現在ＣＴＵラインのためのＭＶＰバッファをリセットするように構成され得る。ＭＶＰバッファは、現在ＣＴＵラインのための個別のＭＶＰバッファであり得るか、または共通のＭＶＰバッファがＣＴＵの複数のラインに使用され得る。

[0067] いくつかの例において、動き情報をＭＶＰバッファに記憶するとき、ビデオエンコーダ２００およびビデオデコーダ３００は、ＭＶＰバッファ内の一意の動き情報だけを記憶し得る。例えば、ビデオエンコーダ２００およびビデオデコーダ３００は、現在の動きベクトルを使用して現在ＣＵをコーディングし、動きベクトルが現在ＣＵについてＭＶＰバッファに現在記憶されているかどうかを決定し、記憶されている場合には、動きベクトルをＭＶＰバッファに記憶するのを防ぎ、記憶されていない場合には、動きベクトルをＭＶＰバッファに記憶し得る。

[0068] いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は、ＭＶＰバッファが満杯になったときにＭＶＰバッファから動きベクトルを除去するために先入れ先出し（ＦＩＦＯ：first-in-first-out）規則を使用し得る。すなわち、新しい動きベクトルをＭＶＰバッファに追加するために、ビデオエンコーダ２００およびビデオデコーダ３００は、最も早く挿入された動きベクトルをＭＶＰバッファから除去し、新しい動きベクトルをＭＶＰバッファに挿入し得る。このように、ＭＶＰバッファは、キューのような挙動を有し得る。

[0069] いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は、様々なタイプの異なる動きモデルの各々のための別個のＭＶＰバッファを維持し得る。例えば、ビデオエンコーダ２００およびビデオデコーダ３００は、アフィン動きモデルのためのアフィンＭＶＰバッファ、イントラブロックコピーモードの動き情報のためのイントラブロックコピーＭＶＰバッファ、局所照明補償の動き情報のための照明補償ＭＶＰバッファ、サブブロックＭＶＰのためのサブブロックＭＶＰバッファ、および／または時間的動き予測のための時間ＭＶＰバッファを維持し得る。

[0070] いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は、１つまたは複数のＭＶＰバッファ内の２つ以上のＭＶＰから合成ＭＶＰを生成し、合成ＭＶＰをＭＶＰバッファのうちの１つに挿入し得る。２つ以上のＭＶＰは、同じ動きモデルに準拠するかまたは異なる動きモデルに準拠し得る（すなわち、異なる動き情報タイプを有する）。

[0071] 図２Ａおよび図２Ｂは、例となる四分木二分木（ＱＴＢＴ）構造１３０と、対応するコーディングツリー単位（ＣＴＵ）１３２とを例示する概念図である。実線は四分木分割を表し、破線は二分木分割を示す。二分木の各分割（すなわち、非リーフ）ノードでは、どの分割タイプ（すなわち、水平または垂直）が使用されるかを示すために１つのフラグがシグナリングされ、ここで、０は水平分割を示し、１は垂直分割を示す。四分木分割の場合、四分木ノードがブロックを同じサイズの４つのサブブロックへと水平および垂直に分割するため、分割タイプを示す必要はない。従って、ＱＴＢＴ構造１３０の領域ツリーレベル（すなわち、実線）のためのシンタックス要素（例えば分割情報）と、ＱＴＢＴ構造１３０の予測ツリーレベル（すなわち、破線）のためのシンタックス要素（例えば分割情報）とを、ビデオエンコーダ２００は符号化し得、ビデオデコーダ３００は復号し得る。ＱＴＢＴ構造１３０の終端リーフノードによって表されるＣＵのための、予測および変換データのようなビデオデータを、ビデオエンコーダ２００は符号化し得、ビデオデコーダ３００は復号し得る。

[0072] 概して、図２ＢのＣＴＵ１３２は、第１および第２のレベル（例えば、領域ツリーレベルおよび予測ツリーレベル）におけるＱＴＢＴ構造１３０のノードに対応するブロックのサイズを定義するパラメータに関連付けられ得る。これらのパラメータは、ＣＴＵサイズ（サンプル中のＣＴＵ１３２のサイズを表す）、最小四分木サイズ（ＭｉｎＱＴＳｉｚｅ、最小許容四分木リーフノードサイズを表す）、最大二分木サイズ（ＭａｘＢＴＳｉｚｅ、最大許容二分木ルートノードサイズを表す）、最大二分木深度（ＭａｘＢＴＤｅｐｔｈ、最大許容二分木深度を表す）、および最小二分木サイズ（ＭｉｎＢＴＳｉｚｅ、最小許容二分木リーフノードサイズを表す）を含み得る。

[0073] ＣＴＵに対応するＱＴＢＴ構造のルートノードは、ＱＴＢＴ構造の第１のレベルにおいて４つの子ノードを有し得、その各々が四分木区分に従って区分され得る。すなわち、第１のレベルのノードは、（子ノードを有さない）リーフノードであるか、または４つの子ノードを有するかのいずれかである。ＱＴＢＴ構造１３０の例は、そのようなノードを、親ノードと、分岐のための実線を有する子ノードとを含むものとして表す。第１のレベルのノードが最大許容二分木ルートノードサイズ（ＭａｘＢＴＳｉｚｅ）より大きくない場合、ノードは、それぞれの二分木によってさらに区分され得る。１つのノードの二分木分割は、分割の結果生じるこのノードが最小許容二分木リーフノードサイズ（ＭｉｎＢＴＳｉｚｅ）または最大許容二分木深度（ＭａｘＢＴＤｅｐｔｈ）に達するまで反復され得る。ＱＴＢＴ構造１３０の例は、そのようなノードを、分岐のための破線を有するものとして表す。二分木リーフノードは、コーディング単位（ＣＵ）と呼ばれ、これは、これ以上の区分なしに、予測（例えば、イントラピクチャ予測またはインターピクチャ予測）および変換に使用される。上述したように、ＣＵは「ビデオブロック」または「ブロック」とも呼ばれ得る。

[0074] ＱＴＢＴ区分構造の一例において、ＣＴＵサイズは１２８×１２８（ルーマサンプルと２つの対応する６４×６４のクロマサンプル）と設定され、ＭｉｎＱＴＳｉｚｅは、１６×１６と設定され、ＭａｘＢＴＳｉｚｅは、６４×６４と設定され、（幅と高さの両方についての）ＭｉｎＢＴＳｉｚｅは、４と設定され、ＭａｘＢＴＤｅｐｔｈは、４と設定される。四分木リーフノードを生成するために、最初に四分木区分がＣＴＵに適用される。四分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを有し得る。リーフ四分木ノードが１２８×１２８である場合、サイズがＭａｘＢＴＳｉｚｅ（すなわち、この例において６４×６４）を超えるので、それは、二分木によってこれ以上分割されない。そうでない場合、リーフ四分木ノードは、二分木によってさらに区分される。従って、四分木リーフノードは、二分木のためのルートノードでもあり、０の二分木深度を有する。二分木深度がＭａｘＢＴＤｅｐｔｈ（この例において４）に達すると、これ以上の分割は許可されない。二分木ノードがＭｉｎＢＴＳｉｚｅ（この例において４）に等しい幅を有するとき、それはこれ以上の垂直分割が許可されないことを意味する。同様に、ＭｉｎＢＴＳｉｚｅに等しい高さを有する二分木ノードは、その二分木ノードについてこれ以上の水平分割が許可されないことを意味する。上述のように、二分木のリーフノードはＣＵと呼ばれ、これ以上の区分なく予測および変換に従ってさらに処理される。

[0075] 図３は、履歴動きベクトル予測子（ＨＭＶＰ）を使用して動き情報をコーディングするための例となるプロセスを例示するフロー図である。最初に、ビデオエンコーダ２００またはビデオデコーダ３００のようなビデオコーダは、ＨＭＶＰ候補を有するテーブルをロードする（１４０）。次いで、ビデオコーダは、ＨＭＶＰ候補を使用してビデオデータのブロックをコーディングする（１４２）。次いで、ビデオコーダは、コーディングされたブロックの動き情報でテーブルを更新する（１４４）。

[0076] 図４は、ＨＭＶＰテーブルを更新する例を例示する概念図である。ＪＶＥＴ−Ｋ０１０４では、テーブルサイズが１６に設定され、先入れ先出し（ＦＩＦＯ）規則が適用される。図４は、ＨＭＶＰ候補を除去し、本開示の技法の例において使用されるテーブルに新しいものを追加するためにＦＩＦＯ規則が適用される例を描写する。

[0077] ビデオエンコーダ２００またはビデオデコーダ３００のようなビデオコーダは、候補リスト内の時間動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）候補の後に、テーブル内の最後のエントリから最初のエントリまでのＨＭＶＰ候補を挿入し得る。ビデオコーダは、ＨＭＶＰ候補にプルーニングを適用し得る。ビデオコーダは、利用可能なマージ候補の総数がマージ候補のシグナリングされた最大許容数に達したとき、プルーニングプロセスを終了し得る。

[0078] 図４の例において、更新前のテーブルは、履歴ＭＶＰ_０−（ＨＭＶＰ_０）〜履歴ＭＶＰ_Ｌ−１（ＨＭＶＰ_Ｌ−１）を含み、ここで、下付きの数字０〜Ｌ−１は、履歴ＭＶＰが追加された順序を表す。Ｃ_Ｌ−１は、テーブルに追加される新しい履歴ＭＶＰを表す。ゆえに、この例では、ＦＩＦＯ規則に従って、Ｃ_Ｌ−１を追加する前にＨＭＶＰ_０がテーブルから除去される。

[0079] 図５は、動き情報コーディングのための非隣接ブロックの例となる選択を例示する概念図である。図５の例では、「Ｃｕｒｒ」とラベル付けされている現在ブロックが、Ａ_ｉ、Ｂ_ｊ、およびＮＡ_ｋとラベル付けされている隣接ブロックおよび／または非隣接の隣接ブロックを使用して動き情報がコーディングされ得る現在コーディング単位（ＣＵ）を表す。非隣接動きベクトル予測は、例えば、２０１８年６月８日に出願された米国出願第１６／００３，２６９号に記載されている。ビデオコーダは、ＦＩＦＯ規則と、非隣接ブロックのための動き候補のバッファの最大サイズとを適用し得る。

[0080] 図６は、親ブロックに基づく非隣接ブロックの例となる選択を例示する概念図である。すなわち、親ブロックは、現在ブロックを含むサブブロックに分割されたブロックである。例えば、親ブロックは、ＣＴＵであるか、またはＣＴＵが区分されたサブブロックであり得る。図５と同様に、図６では、現在ＣＵは、「Ｃｕｒｒ」とラベル付けされており、動き情報が取り出され、現在ＣＵの動き情報を予測するために使用され得る非隣接ブロックは、「ＮＡ_ｉ，ｊ」とラベル付けされている。

[0081] コロケートされたブロックの隣接空間ブロックの動きベクトルは、動きベクトルＨおよびＣ（すなわち、コロケートされたブロックの中心および右下にある動きベクトル）に加えて、マージモードのための動きベクトル予測（ＭＶＰ）候補として使用され得る。

[0082] 本開示の技法は、例えば、ＡＭＶＰおよび／またはマージコーディングモードに使用される候補を追加することによって、動きベクトル予測を改善するために使用され得、ここで、追加される候補は、非隣接ブロックから取得され得る。例えば、追加される候補は、図６のＮＡ_１，１〜ＮＡ_１，９のうちのいずれかに対応し得る。

[0083] 図７は、コーディングツリー単位（ＣＴＵ）の所望の波面処理の例を例示する概念図である。図７に示されるように、様々なスレッドが、ＣＴＵの異なるラインを処理するために割り当てられ得る。すなわち、ビデオエンコーダ２００またはビデオデコーダ３００のようなビデオコーダは、例えば、異なるＣＴＵラインをコーディングするときの波面並列処理（ＷＰＰ：wavefront parallel processing）のために、複数の異なるスレッドを実行し得る。いくつかの例では、インター予測されたブロックの動き情報をコンテキストベースコーディング（例えば、ＣＡＢＡＣコーディング）するために使用される特定の確率が、例えば、最後のブロックがまだコーディングされていなかったと仮定して、その確率が前のＣＴＵラインの最後のブロックから決定されるべきものであった場合、決定されないであろう。ゆえに、本開示の技法によれば、ビデオエンコーダ２００およびビデオデコーダ３００は、ＣＴＵラインが正しく処理され得ることを確実にするために、ＣＴＵラインをコーディングする前に、ＣＴＵラインのためのＣＴＵバッファをリセットし得る。

[0084] 図８は、ＨＭＶＰに使用される動き情報の例を例示する概念図である。図８は、さらなるブロックの動きベクトルを考慮しつつ、ＦＩＦＯの使用により、現在ブロックにより近いブロックの動きベクトルがどのように候補リストから除去され得るかを例示する。特に、図８では、Ｘが、現在コーディングされている動き情報を表し、影付きブロックのＭＶが、履歴バッファ内にある。本開示は、図８に示されるように、従来のＨＭＶＰ技法が、ＦＩＦＯ規則の使用に少なくとも部分的に起因して、非隣接ブロックの動きベクトルを十分には活用しないことを認識する。

[0085] 特に、ブロックＸがコーディングされるとき、左上ＣＴＵ、上ＣＴＵ、および右上ＣＴＵの非隣接ブロック（ＴＬ０，Ｔ０，Ｔ１，ＴＲ０，ＴＲ１，ＴＲ２，ＴＲ３）の動き情報は、履歴バッファから除去されている。従って、これらのブロックの動き情報は、動きベクトルが履歴バッファ内にある、例えば、ＣＴＵのＬＬ０、ＣＴＵのＬＬ１、およびＣＴＵのＦ０〜Ｆ３より非隣接ブロックがＸに近い場合でも、候補リストへの追加について考慮されない。

[0086] 本開示はまた、ＨＶＭＰのための単一のバッファが波面並列処理に適用可能でないことを認識する。単一のバッファだけが使用される場合、バッファのサイズは、全てのスレッド（例えば、ＣＴＵライン）において処理されているブロックのための潜在的な空間候補を含むために非常に大きくなるであろう。例えば、４つのスレッドが並列に実行されるように設定されている場合、バッファのサイズは６４に達し得る。結果として、ビデオデコーダ３００にＭＶＰのインデックスをシグナリングするためにより多くのビットが必要とされる。同様に、冗長なエントリが発生し得る。すなわち、履歴バッファ内のエントリは、このライン中のブロックに対して潜在的に有用であり得るが、他のライン（例えば、図８中のＸおよびＦ）中のブロックに対しては有用でない可能性がある。その結果、ブロックの最適な候補を見つけることは困難であり得る。

[0087] 図９は、コーディングツリー単位（ＣＴＵ）の複数のラインに区分されたピクチャの例を例示する概念図である。特に、図９の例において、ピクチャ１５０は、ＣＴＵライン１５２Ａ〜１５２Ｅ（ＣＴＵライン１５２）を含む。ＣＴＵライン１５２の各々は、ＣＴＵのそれぞれのセットを含む：ＣＴＵライン１５２Ａは、ＣＴＵ１５４Ａ〜１５４Ｊを含み、ＣＴＵライン１５２Ｂは、ＣＴＵ１５６Ａ〜１５６Ｊを含み、ＣＴＵライン１５２Ｃは、ＣＴＵ１５８Ａ〜１５８Ｊを含み、ＣＴＵライン１５２Ｄは、ＣＴＵ１６０Ａ〜１６０Ｊを含み、ＣＴＵライン１５２Ｅは、ＣＴＵ１６２Ａ〜１６２Ｊを含む。

[0088] ビデオエンコーダ２００およびビデオデコーダ３００は、履歴ベースＭＶＰのために複数のバッファを使用するように、本開示の技法に従って構成され得る。いくつかの例において、ビデオエンコーダ２００およびビデオデコーダ３００は、（各々が別個のそれぞれの処理スレッドによって処理され得る）ＣＴＵライン１５２の各々について別個の履歴ＭＶＰバッファを維持し得るか、または波面並列処理が適用されるときに各ＣＴＵラインの開始時にリセットされる単一のバッファが存在し得る。

[0089] 一例において、ＣＴＵ１５８Ｃは、現在ＣＴＵを表し得る。ＣＴＵ１５４Ａ〜１５４Ｆ、１５６Ａ〜１５６Ｄ、１５８Ａ、および１５８Ｂ（図９中でグレーの陰影を使用して示される）の動き情報が、ＣＴＵ１５８Ｃの動き情報をコーディングするときに使用するために１つまたは複数のそれぞれの履歴ＭＶＰバッファで利用可能であり得る。

[0090] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、以下の技法のうちのいずれかまたは全てを単独でまたは組み合わせて使用して、履歴ＭＶＰバッファの初期化を実行し得る。ビデオエンコーダ２００およびビデオデコーダ３００は、各ＣＴＵラインの履歴ＭＶＰバッファをリセットして空にし得る。ビデオエンコーダ２００およびビデオデコーダ３００は、各ＣＴＵラインの履歴ＭＶＰバッファを、異なる参照フレームインデックスおよび／もしくはインター予測方向を有するゼロ動きベクトル、または他の事前定義されたもしくは導出された動き情報で事前に満たすことができる。ビデオエンコーダ２００およびビデオデコーダ３００は、各ＣＴＵラインの履歴ＭＶＰバッファを、同じ時間レイヤまたは下位時間レイヤ（現在フレーム／ピクチャに利用可能な参照ピクチャ）中のコーディングされたフレーム（ピクチャ）からの動き情報で事前に満たすことができる。

[0091] ビデオエンコーダ２００およびビデオデコーダ３００は、例えば、時間的距離に基づいて動き情報をスケーリングするか、または動き情報を処理／修正する、例えば、この動き情報を別のＭＶと組み合わせることができる。概して、ビデオエンコーダ２００およびビデオデコーダ３００は、この動き情報を、コーディングされたフレーム／ピクチャ中の前の履歴ＭＶＰバッファからの動き情報、またはコーディングされたフレーム／ピクチャ中のコロケートされた領域（ＣＴＵであるか、または特定のブロックサイズ、例えば４×４ブロックより大きい可能性がある）の動き情報と組み合わせ得る。ビデオエンコーダ２００およびビデオデコーダ３００は、現在ＣＴＵの右上ＣＴＵがコーディングされるとき、上ＣＴＵラインの履歴ＭＶＰバッファを事前に満たし得る。ビデオエンコーダ２００およびビデオデコーダ３００は、異なる参照フレームインデックスおよび／またはインター予測方向を有するゼロ動きベクトル、または他の事前定義されたもしくは導出された動き情報を使用し得る。

[0092] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、ＣＴＵラインのＣＴＵがコーディング（符号化または復号）されるときはいつでも、現在ＣＴＵラインの下のＣＴＵラインの履歴バッファを初期化または修正するために、関連する履歴ＭＶＰバッファを使用し得る。

[0093] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、関連する履歴ＭＶＰバッファからエントリを除去するためにＦＩＦＯ規則を適用し得る。

[0094] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、関連するＣＴＵラインが完全に符号化／復号されたとき、履歴ＭＶＰバッファをクリアし得る。

[0095] ビデオエンコーダ２００およびビデオデコーダ３００は、ＡＭＶＰ／マージまたは他のモードの候補リストより大きいＭＶＰバッファサイズを維持し得る。バッファからの任意の１つまたは複数のＭＶは、特定のモード、例えば、ＡＭＰＶ、マージモード、アフィン、または任意の他のインターモードで使用される候補リストのための（１つまたは複数の）ＭＶ候補として選択され得る。バッファからＭＶをどのように選択するのか、例えば、Ｎ個の最後にバッファに追加されたＭＶを選ぶのか、バッファの先頭から数個、および／またはバッファの中間から数個、および／またはバッファの末尾から数個を選ぶのか、についての規則が定義され得る。代替的に、どのＭＶが選択されるかを示すために、シグナリングが適用され得る（例えば、ビデオエンコーダ２００は、シグナリングされたデータを符号化し得、ビデオデコーダ３００は、シグナリングされたデータを復号し得る）。ＭＶＰバッファサイズは、任意のパラメータセット（例えば、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、または同様のもの）、スライスヘッダ、またはその他においてシグナリングされ得る。ＭＶＰバッファは、スライス、ピクチャ、および／またはビデオシーケンスに関連付けられ得る。

[0096] ビデオエンコーダ２００およびビデオデコーダ３００がインターコーディングされたブロックを処理するとき、ブロック中で使用されるＭＶはＭＶＰバッファに追加され得、一意のＭＶだけがバッファ内に保持され得る。バッファが満杯である場合、新しいＭＶが追加されるときに古いＭＶがバッファから除去され得る。ＭＶがバッファに追加され得る規則が存在し得、例えば、ＡＭＶＰモードでは、シグナリングされたＭＶだけが追加され得、ブロックがマージモードでコーディングされる場合には、ブロックのＭＶはバッファに追加されない。

[0097] ビデオエンコーダ２００およびビデオデコーダ３００は、バッファ内の既存の１つまたは複数のＭＶにＭＶを付加し得る。例えば、バッファ内の既存のＭＶが単方向である場合、新しいＭＶを追加するとき、それらの既存のＭＶは、新しいＭＶを付加することによって双方向になるように修正され得る。

[0098] 新しいＭＶを追加しつつ、いくつかのＭＶ処理が適用され得る。例えば、新しいＭＶがバッファ内の既存のＭＶに近い場合、それらの近いＭＶが除去され得る。近いとは、ＭＶ成分値（例えば、ｘ成分およびｙ成分）を比較することによって近いことを意味し得る。いくつかの例では、バッファ内の既存のＭＶとしきい値だけ異なるＭＶだけがバッファに追加され得る。同じしきい値が、異なるバッファに対して構成され得る。

[0099] バッファ内の動きベクトルは、単方向（Ｌ０またはＬ１）、双方向、または任意の他の動きモデルＭＶであり得る。

[0100] モード情報は、バッファ内のＭＶに関連付けられ得、バッファ内のＭＶのインデックスがブロック中でシグナリングされるか、またはバッファからＭＶを取得することに関して他の規則が適用される場合、モード情報は、そのＭＶ情報に関連するデータから導出され得る。例えば、その情報がマージモードである場合、ブロックは、示されたＭＶを用いてマージモードでコーディングされる。

[0101] 本開示はさらに、従来の履歴ベースＭＶＰが、通常の動き予測子だけを保持し、動き情報を修正することなく通常の動き予測のためだけに使用されることを認識する。本開示の技法によれば、ビデオエンコーダ２００およびビデオデコーダ３００は、コーディングされた動き情報だけでなく、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ、または時間的動き予測子のような、他のタイプの動き予測子も保持する少なくとも１つの履歴ＭＶＰバッファを使用し得る。

[0102] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ、または時間的動き予測子のような、異なる動きモデルのために複数の履歴ＭＶＰバッファを使用し得る。

[0103] 追加的にまたは代替的に、現在ＭＶＰと、他の空間ＭＶＰまたは時間ＭＶＰのような他の動き予測子とに基づく合成動きベクトルも候補リストに追加され得る。

[0104] 追加的にまたは代替的に、ビデオエンコーダ２００およびビデオデコーダ３００は、履歴ＭＶＰバッファ内の２つ以上のＭＶＰ、または空間ＭＶＰもしくは時間ＭＶＰのような他のタイプのＭＶＰを有する履歴ＭＶＰバッファ内の１つまたは複数のＭＶＰから合成ＭＶＰを生成し得る。

[0105] ビデオエンコーダ２００およびビデオデコーダ３００は、ブロック区分方式を実施し得る。ＨＥＶＣでは、ピクチャが、コーディングツリー単位（ＣＴＵ）のシーケンスに分割される。３つのサンプルアレイを有するピクチャの場合、ＣＴＵは、クロマサンプルの２つの対応するブロックとともにルーマサンプルのＮ×Ｎブロックを含む。ＣＴＵは、ツリー構造を使用することによってコーディング単位（ＣＵ）に分割される。各リーフＣＵは、ＰＵ分割タイプに従って、１つ、２つ、または４つの予測単位（ＰＵ）にさらに分割され得る。ＰＵ分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後、リーフＣＵは、変換単位（ＴＵ）に区分され得る。

[0106] ＶＶＣでは、二分割および三分割セグメンテーション構造を使用するネストされたマルチタイプツリーを有する四分木が、複数の区分単位タイプの概念に取って代わり、すなわち、ネストされたマルチタイプツリー区分は、最大変換長に対して大きすぎるサイズを有するＣＵを必要に応じて除いて、ＣＵ、ＰＵ、およびＴＵ概念の区別を除去し、ＣＵ区分形状に対してさらなる柔軟性をサポートする。コーディングツリー構造では、ＣＵが、正方形または長方形のいずれかの形状を有し得る。

[0107] ビデオエンコーダ２００およびビデオデコーダ３００は、ビデオデータのブロックを予測するために動き情報を利用し得る。各ブロックについて、動き情報のセットが利用可能であり得る。動き情報のセットは、前方予測方向および後方予測方向の動き情報を含む。ここで、前方予測方向および後方予測方向は、現在ピクチャまたはスライスの参照ピクチャリスト０（ＲｅｆＰｉｃＬｉｓｔ０）および参照ピクチャリスト１（ＲｅｆＰｉｃＬｉｓｔ１）に対応する２つの予測方向である。「前方」および「後方」という用語は、必ずしも幾何学的意味を有するとは限らない。むしろ、それらは、動きベクトルがどの参照ピクチャリストに基づくかを区別するために使用される。前方予測は、参照リスト０に基づいて形成された予測を意味し、後方予測は、参照リスト１に基づいて形成された予測を意味する。参照リスト０および参照リスト１の両方が所与のブロックのための予測を形成するために使用される場合、それは双方向予測と呼ばれる。

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

[0109] 各予測方向について、動き情報は、参照インデックスおよび動きベクトルを含む。参照インデックスは、対応する参照ピクチャリスト（例えば、ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）内の参照ピクチャを識別するために使用される。動きベクトルは、各々がそれぞれ水平方向および垂直方向に沿ったオフセット値を示す水平成分および垂直成分の両方を有する。いくつかの説明では、簡単さのために、「動きベクトル」という単語が、動きベクトルとその関連する参照インデックスの両方を示すために、動き情報と同義で使用され得る。

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

[0111] ＨＥＶＣでは、それぞれＰＵについて、マージモード（スキップはマージモードの特例とみなされる）と高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）モードという名前の２つのインター予測モードが存在する。

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

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

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

[0115] 図１０Ａおよび１０Ｂは、マージモードおよび高度動きベクトル予測（ＡＭＶＰ）モードのための例となる空間隣接動きベクトル候補を例示するブロック図である。図１０Ａは、マージモードのための空間隣接ＭＶ候補の例を示し、図１０Ｂは、ＡＭＶＰモードのための空間隣接ＭＶ候補の例を示す。空間ＭＶ候補は、図１０Ａおよび図１０Ｂに示されるように、隣接ブロックから導出される。特定のＰＵ（ＰＵ０）について、ブロックから候補を生成するための方法は、マージモードとＡＭＶＰモードとで異なる。

[0116] マージモードでは、最大４つのＭＶ候補が、図１０Ａに示される順序で導出され得る。具体的には、この順序は、図１０Ａに示されるように以下の通りである：左（０）、上（１）、右上（２）、左下（３）、および左上（４）。

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

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

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

[0120] ＴＭＶＰ候補のための動きベクトルは、スライスレベルにおいて示される、コロケートされたピクチャのコロケートされたＰＵから導出される。コロケートされたＰＵのための動きベクトルは、コロケートされたＭＶと呼ばれる。

[0121] 図１１Ｂは、ＭＶスケーリングの例を示す。ＴＭＶＰ候補動きベクトルを導出するためには、図１１Ｂに示されるように、コロケートされたＭＶが、時間的距離差を補償するようにスケーリングされる必要があり得る。

[0122] マージモードおよびＡＭＶＰモードのいくつかの他の態様は、以下の通り、特筆するに値する。例えば、ビデオエンコーダ２００およびビデオデコーダ３００は、動きベクトルスケーリングを実行し得る。動きベクトルの値が、プレゼンテーション時間におけるピクチャの距離に比例すると仮定する。動きベクトルは、２つのピクチャ、参照ピクチャ、および動きベクトルを含むピクチャ（すなわち、包含ピクチャ）を関連付ける。ある動きベクトルがその他の動きベクトルを予測するために利用されるとき、包含ピクチャと参照ピクチャとの距離が、ピクチャ順序カウント（ＰＯＣ）値に基づいて算出される。

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

[0124] 別の例として、ビデオエンコーダ２００およびビデオデコーダ３００は、人工的動きベクトル候補の生成を実行し得る。動きベクトル候補リストが完全でない場合、人工的動きベクトル候補が生成され、リストが全ての候補を有することとなるまでリストの最後に挿入される。

[0125] マージモードでは、２つのタイプの人工的ＭＶ候補、すなわち、Ｂスライスだけのために導出された組み合わされた候補と、第１のタイプが十分な人工的候補を提供しない場合にＡＭＶＰだけに使用されるゼロ個の候補とが存在する。すでに候補リスト内にあり、必要な動き情報を有する候補の各対について、双方向の組み合わされた動きベクトル候補が、リスト０内のピクチャを指す第１の候補の動きベクトルと、リスト１内のピクチャを指す第２の候補の動きベクトルとの組合せによって導出される。

[0126] 別の例として、ビデオエンコーダ２００およびビデオデコーダ３００は、候補挿入のためにプルーニングプロセスを実行し得る。異なるブロックからの候補が偶然同じになることがあり得、これはマージ／ＡＭＶＰ候補リストの効率を低下させる。この問題を解決するためにプルーニングプロセスが適用される。それは、ある程度同一の候補を挿入することを回避するために、現在の候補リストにおいて１つの候補をその他の候補と比較する。複雑さを低減するために、各潜在的なものを他の全ての既存のものと比較する代わりに、限られた数のプルーニングプロセスだけが適用される。適用可能な場合、以下の比較だけが適用される：上のマージ候補が左のマージ候補と比較され、右上のマージ候補が上のマージ候補と比較され、左下のマージ候補が左のマージ候補と比較され、左上のマージ候補が左のマージ候補および上のマージ候補と比較される。

[0127] ビデオエンコーダ２００およびビデオデコーダ３００はまた、他の動き予測方法を使用し得る。ＶＶＣ（Versatile Video Coding）の開発において、履歴ベース動きベクトル予測子（ＨＭＶＰ）方法が、Ｌ．Ｚｈａｎｇ等による、「CE4-related: History-based Motion Vector Prediction」、Joint Video Experts Team文書：ＪＶＥＴ−Ｋ０１０４（以下「Ｋ０１０４」）で提案されている。ＨＭＶＰ方法は、各ブロックが、直接隣接する因果的な隣接動きフィールドに加えて、過去から復号されたＭＶのリストからそのＭＶ予測子を見つけることを可能にする。符号化／復号プロセス中、複数のＨＭＶＰ候補を有するテーブルが維持される。新しいスライスに遭遇すると、テーブルは空にされる。インターコーディングされたブロックがあるときはいつでも、関連する動き情報が、ＨＭＶＰ候補として先入れ先出し（ＦＩＦＯ）方式でテーブルに挿入される。次いで、制約であるＦＩＦＯ規則が適用され得る。ＨＭＶＰをテーブルに挿入するとき、テーブル内に同一のＨＭＶＰがあるかどうかを見つけるために、冗長検査が最初に適用され得る。見つかった場合、その特定のＨＭＶＰがテーブルから除去され得、その後、全てのＨＭＶＰ候補が移動される。

[0128] ＨＭＶＰ候補は、マージ候補リスト構築プロセスにおいて使用され得る。例えば、テーブル内の最後のエントリから最初のエントリまでの全てのＨＭＶＰ候補が、ＴＭＶＰ候補の後に挿入され得る。プルーニングがＨＭＶＰ候補に適用され得る。利用可能なマージ候補の総数が、シグナリングされた最大許容マージ候補に達すると、マージ候補リスト構築プロセスは終了する。

[0129] 同様に、ＨＭＶＰ候補はまた、ＡＭＶＰ候補リスト構築プロセスにおいて使用され得る。テーブル内の最後のＫ個のＨＭＶＰ候補の動きベクトルは、ＴＭＶＰ候補の後に挿入され得る。いくつかの例では、ＡＭＶＰターゲット参照ピクチャと同じ参照ピクチャをもつＨＭＶＰ候補だけが、ＡＭＶＰ候補リストを構築するために使用される。プルーニングは、ＨＭＶＰ候補に適用され得る。

[0130] ＨＥＶＣにおいて、現在ＣＴＵのコーディングは、左、左上、上、および右上のＣＴＵだけに依存し得る。ゆえに、波面並列処理（ＷＰＰ）は、ＨＥＶＣにおいてサポートされ得る。しかしながら、Ｋ０１０４におけるＨＭＶＰ方法は、現在ブロックとスライス内の全ての前にコーディングされたＣＴＵとの間の依存状態をもたらし得る。従って、ＨＭＶＰ方法が使用される場合、ＷＰＰは適用されないであろう。本開示は、ＣＴＵ初期化付きのＨＭＶＰを使用するための技法を説明し、ここでは、依存状態がＨＥＶＣの場合と同じ状態のままである。本開示はまた、ＣＴＵ行初期化（リセット）付きのＨＭＶＰのための技法を説明する。

[0131] 本開示の技法に従って、ビデオエンコーダ２００およびビデオデコーダ３００は、ＣＴＵ初期化付きのＨＭＶＰを実行し得る。ＨＭＶＰテーブルは、各ＣＴＵの開始時に初期化される。初期化は、現在ＣＴＵの直接隣接するコーディングされたブロックからのＭＶをＨＭＶＰテーブルに追加し得る。直接隣接するコーディングされたブロックは、ＨＥＶＣにあるように、現在ＣＴＵの左、上、左上、または右上にあり得る。時間動きベクトル予測が可能な場合、直接隣接するコーディングされたブロックはまた、参照ピクチャ中のコロケートされたブロックであり得る。

[0132] 図１２は、コーディングツリー単位（ＣＴＵ）および隣接ブロックの例を例示するブロック図である。一例では、現在ＣＴＵブロックのための空間および時間マージ候補だけが、ＨＭＶＰテーブルを初期化するために使用される。ＨＥＶＣの空間および時間マージ候補を使用する例を図１２に示す。挿入順序は以下の通りである：左（０）、上（１）、右上（２）、および左上（４）。時間マージ候補のロケーションは、「Ｔ」によって示される。右下の時間マージ候補および左下（３）の候補は、それらのロケーションが現在ＣＴＵラインより下であるため、利用不可能であることに留意されたい。

[0133] 別の例において、現在ＣＴＵブロックのためのマージ候補導出プロセスは、ＨＭＶＰテーブルを初期化するために使用される。空間および時間マージ候補に加えて、他のマージ候補（例えば、人工的動きベクトル候補）も初期化に使用され得る。

[0134] 図１３は、現在ＣＴＵ内の現在ＣＵを例示するブロック図である。いくつかの例において、ＨＭＶＰテーブルは、現在ＣＴＵのコーディングの開始時に空として初期化される。しかしながら、図１３に示されているように、第１のＣＵがコーディングされた後、第１のＣＵの空間および時間マージ候補がＨＭＶＰテーブルに追加される。次いで、ＣＵがインター予測コーディングされる場合、第１のＣＵのＭＶも追加される。第１のＣＵが現在ＣＴＵに等しくない場合、順に２つの時間マージ候補「Ｔ０」および「Ｔ１」が追加され得ることに留意されたい。図１３は、ＣＴＵ内の第１のＣＵのマージ候補の例を示す。

[0135] 別の例において、ＨＭＶＰテーブルは、現在ＣＴＵのコーディングの開始時に空として初期化される。しかしながら、第１のＣＵがコーディングされた後、第１のＣＵの全てのマージ候補がＨＭＶＰテーブルに追加される。そして、第１のＣＵのＭＶも、それがインター予測コーディングされる場合、追加される。

[0136] ビデオエンコーダ２００およびビデオデコーダ３００はまた、ＣＴＵ行初期化付きのＨＭＶＰを実行し得る。別の例において、上で説明したＨＭＶＰのためのＣＴＵ初期化は、ＣＴＵ行中の第１のＣＴＵにおいてのみ適用される。Ｋ０１０４におけるＨＭＶＰと同様に、プルーニングプロセスが、いくつかまたは全ての重複を除去するために、初期化されたテーブルに適用され得る。プルーニングプロセスはまた、複雑さを低減するために初期化されたテーブルに適用されないであろう。

[0137] 図１４は、本開示の技法を実行し得る例となるビデオエンコーダ２００を例示するブロック図である。図１４は、説明のために提供されており、本開示で広範に実証および説明される技法を限定するものとみなされるべきではない。説明のために、本開示は、開発中のＨ．２６６ビデオコーディング規格およびＨＥＶＣビデオコーディング規格のようなビデオコーディング規格のコンテキストにおいて、ビデオエンコーダ２００を説明する。しかしながら、本開示の技法は、これらのビデオコーディング規格に限定されるものではなく、一般に、ビデオ符号化および復号に適用可能である。

[0138] 図１４の例において、ビデオエンコーダ２００は、ビデオデータメモリ２３０と、モード選択ユニット２０２と、残差生成ユニット２０４と、変換処理ユニット２０６と、量子化ユニット２０８と、逆量子化ユニット２１０と、逆変換処理ユニット２１２と、再構築ユニット２１４と、フィルタユニット２１６と、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）２１８と、エントロピー符号化ユニット２２０とを含む。ビデオデータメモリ２３０、モード選択ユニット２０２、残差生成ユニット２０４、変換処理ユニット２０６、量子化ユニット２０８、逆量子化ユニット２１０、逆変換処理ユニット２１２、再構築ユニット２１４、フィルタユニット２１６、ＤＰＢ２１８、およびエントロピー符号化ユニット２２０のうちのいずれかまたは全ては、１つまたは複数のプロセッサにおいてまたは処理回路において実施され得る。さらに、ビデオエンコーダ２００は、これらおよび他の機能を実行するための追加または代替のプロセッサまたは処理回路を含み得る。

[0139] ビデオデータメモリ２３０は、ビデオエンコーダ２００の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオエンコーダ２００は、例えば、ビデオソース１０４（図１）から、ビデオデータメモリ２３０に記憶されたビデオデータを受信し得る。ＤＰＢ２１８は、ビデオエンコーダ２００による後続のビデオデータの予測において使用するための参照ビデオデータを記憶する参照ピクチャメモリとして機能し得る。ビデオデータメモリ２３０およびＤＰＢ２１８は、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）を含むＤＲＡＭ、磁気ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ（登録商標））のような様々なメモリデバイスまたは他のタイプのメモリデバイスのうちの任意のものによって形成され得る。ビデオデータメモリ２３０およびＤＰＢ２１８は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例において、ビデオデータメモリ２３０は、例示されるように、ビデオエンコーダ２００の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。

[0140] 本開示において、ビデオデータメモリ２３０への参照は、そうであることが具体的に説明されない限り、ビデオエンコーダ２００の内部のメモリに限定されると解釈されるべきでも、そうであることが具体的に説明されない限り、ビデオエンコーダ２００の外部のメモリに限定されると解釈されるべきででもない。むしろ、ビデオデータメモリ２３０への参照は、ビデオエンコーダ２００が符号化のために受信するビデオデータ（例えば、符号化されるべきである現在ブロックのためのビデオデータ）を記憶する参照メモリとして理解されるべきである。図１のメモリ１０６はまた、ビデオエンコーダ２００の様々なユニットからの出力の一時的な記憶を提供し得る。

[0141] 図１４の様々なユニットは、ビデオエンコーダ２００によって実行される動作の理解を助けるために例示されている。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実施され得る。固定機能回路は、特定の機能性を提供する回路を指し、実行され得る動作にプリセットされている。プログラマブル回路は、様々なタスクを実行し、実行され得る動作において柔軟な機能性を提供するようにプログラムされ得る回路を指す。例えば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって定義された方法でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行し得る。固定機能回路は、（例えば、パラメータを受信するためまたはパラメータを出力するために）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは一般に不変である。いくつかの例において、ユニットのうちの１つまたは複数は、別個の回路ブロック（固定機能またはプログラマブル）であり得、いくつかの例において、１つまたは複数のユニットは、集積回路であり得る。

[0142] ビデオエンコーダ２００は、算術論理ユニット（ＡＬＵ）、基本機能ユニット（ＥＦＵ）、デジタル回路、アナログ回路、および／またはプログラマブル回路から形成されたプログラマブルコアを含み得る。ビデオエンコーダ２００の動作がプログラマブル回路によって実行されるソフトウェアを使用して実行される例では、メモリ１０６（図１）が、ビデオエンコーダ２００が受信して実行するソフトウェアのオブジェクトコードを記憶し得るか、またはビデオエンコーダ２００内の別のメモリ（図示せず）がそのような命令を記憶し得る。

[0143] ビデオデータメモリ２３０は、受信されたビデオデータを記憶するように構成される。ビデオエンコーダ２００は、ビデオデータメモリ２３０からビデオデータのピクチャを取り出し、ビデオデータを残差生成ユニット２０４およびモード選択ユニット２０２に提供し得る。ビデオデータメモリ２３０中のビデオデータは、符号化されるべき生のビデオデータであり得る。

[0144] モード選択ユニット２０２は、動き推定ユニット２２２と、動き補償ユニット２２４と、イントラ予測ユニット２２６とを含む。モード選択ユニット２０２は、他の予測モードに従ってビデオ予測を実行するための追加の機能ユニットを含み得る。例として、モード選択ユニット２０２は、パレットユニット、（動き推定ユニット２２２および／または動き補償ユニット２２４の一部であり得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ：linear model）ユニット、または同様のものを含み得る。

[0145] モード選択ユニット２０２は、一般に、符号化パラメータの組合せと、そのような組合せのための結果として生じるレート歪み値をテストするために複数の符号化パスを調整する。符号化パラメータは、ＣＴＵのＣＵへの区分、ＣＵのための予測モード、ＣＵの残差データのための変換タイプ、ＣＵの残差データのための量子化パラメータ、等を含み得る。モード選択ユニット２０２は、最終的に、テストされた他のどの組合せより良好なレート歪み値を有する符号化パラメータの組合せを選択し得る。

[0146] ビデオエンコーダ２００は、ビデオデータメモリ２３０から取り出されたピクチャを一連のＣＴＵに区分し、スライス内に１つまたは複数のＣＴＵをカプセル化し得る。モード選択ユニット２０２は、上で説明したＨＥＶＣのＱＴＢＴ構造または四分木構造のようなツリー構造に従ってピクチャのＣＴＵを区分し得る。上で説明したように、ビデオエンコーダ２００は、ツリー構造に従ってＣＴＵの区分から１つまたは複数のＣＵを形成し得る。そのようなＣＵは、一般に、「ビデオブロック」または「ブロック」とも呼ばれ得る。

[0147] 概して、モード選択ユニット２０２はまた、現在ブロック（例えば、現在ＣＵ、またはＨＥＶＣにおいて、ＰＵとＴＵとの重複部分）のための予測ブロックを生成するために、その構成要素（例えば、動き推定ユニット２２２、動き補償ユニット２２４、およびイントラ予測ユニット２２６）を制御する。現在ブロックのインター予測のために、動き推定ユニット２２２は、１つまたは複数の参照ピクチャ（例えば、ＤＰＢ２１８に記憶された１つまたは複数の前にコーディングされたピクチャ）中の１つまたは複数の厳密に一致する参照ブロックを識別するために動き探索を実行し得る。特に、動き推定ユニット２２２は、例えば、差分絶対値和（ＳＡＤ）、差分二乗和（ＳＳＤ）、平均絶対値差分（ＭＡＤ）、平均二乗差分（ＭＳＤ）、または同様のものに従って、潜在的な参照ブロックが現在ブロックにどれだけ類似しているかを表す値を算出し得る。動き推定ユニット２２２は、一般に、現在ブロックと考慮されている参照ブロックとの間のサンプルごとの差分を使用してこれらの算出を実行し得る。動き推定ユニット２２２は、現在ブロックに最も厳密に一致する参照ブロックを示す、これらの算出から生じる最低値を有する参照ブロックを識別し得る。

[0148] 動き推定ユニット２２２は、現在ピクチャ中の現在ブロックの位置に対する参照ピクチャ中の参照ブロックの位置を定義する１つまたは複数の動きベクトル（ＭＶ）を形成し得る。次いで、動き推定ユニット２２２は、動きベクトルを動き補償ユニット２２４に提供し得る。例えば、単方向インター予測の場合、動き推定ユニット２２２は、単一の動きベクトルを提供し得るが、双方向インター予測の場合、動き推定ユニット２２２は、２つの動きベクトルを提供し得る。次いで、動き補償ユニット２２４は、動きベクトルを使用して予測ブロックを生成し得る。例えば、動き補償ユニット２２４は、動きベクトルを使用して参照ブロックのデータを取り出し得る。別の例として、動きベクトルが分数サンプル精度を有する場合、動き補償ユニット２２４は、１つまたは複数の補間フィルタに従って予測ブロックの値を補間し得る。さらに、双方向インター予測の場合、動き補償ユニット２２４は、それぞれの動きベクトルによって識別された２つの参照ブロックのためのデータを取り出し、例えば、サンプルごとの平均化または重み付け平均化を通して、取り出されたデータを組み合わせることができる。

[0149] 本開示の技法によれば、復号ピクチャバッファ２１８は、ＣＴＵのラインのための１つまたは複数の履歴ＭＶＰバッファを含み得る。すなわち、各ＣＴＵラインがそれ自体のＭＶＰバッファを割り振られ得るか、または単一のＭＶＰバッファが複数のＣＴＵラインに使用され得る。いずれの場合も、ビデオエンコーダ２００は、ＣＴＵラインのビデオデータの復号開始時に、ＣＴＵラインのためのＭＶＰバッファをリセットし得る。動き補償ユニット２２４またはビデオエンコーダ２００の別のユニットは、一意の動きベクトルだけをＭＶＰバッファに記憶するように構成され得る。上述したように、動き補償ユニット２２４またはビデオエンコーダ２００の別のユニットは、ＭＶＰバッファに記憶された動き情報を管理するためにＦＩＦＯ規則を使用するように構成され得、その結果、動きベクトルをＭＶＰバッファに追加するとき、ＭＶＰバッファが満杯である場合、動き補償ユニット２２４は、最も早く追加された動きベクトルをＭＶＰバッファから除去し得る。いくつかの例において、ビデオエンコーダ２００は、例えば、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ、および時間的動き予測のような、様々な動きモデルの各々について異なるそれぞれのＭＶＰバッファを維持し得る。

[0150] 別の例として、イントラ予測、またはイントラ予測コーディングの場合、イントラ予測ユニット２２６は、現在ブロックに隣接するサンプルから予測ブロックを生成し得る。例えば、方向性モードの場合、イントラ予測ユニット２２６は、一般に、隣接するサンプルの値を数学的に組み合わせ、予測ブロックを作り出すために、現在ブロックにわたって定義された方向にこれらの算出された値をポピュレートさせ得る。別の例として、ＤＣモードの場合、イントラ予測ユニット２２６は、現在ブロックに隣接するサンプルの平均を算出し、予測ブロックの各サンプルについての結果として生じる平均を含むように予測ブロックを生成し得る。

[0151] モード選択ユニット２０２は、予測ブロックを残差生成ユニット２０４に提供する。残差生成ユニット２０４は、ビデオデータメモリ２３０から現在ブロックの生のコーディングされていないバージョンを受信し、モード選択ユニット２０２から予測ブロックを受信する。残差生成ユニット２０４は、現在ブロックと予測ブロックとの間のサンプルごとの差分を算出する。結果として生じるサンプルごとの差分は、現在ブロックについての残差ブロックを定義する。いくつかの例において、残差生成ユニット２０４はまた、残差差分パルスコード変調（ＲＤＰＣＭ：residual differential pulse code modulation）を使用して残差ブロックを生成するために、残差ブロック中のサンプル値間の差分を決定し得る。いくつかの例において、残差生成ユニット２０４は、バイナリ減算を実行する１つまたは複数の減算器回路を使用して形成され得る。

[0152] モード選択ユニット２０２がＣＵをＰＵに区分する例では、各ＰＵが、ルーマ予測単位および対応するクロマ予測単位に関連付けられ得る。ビデオエンコーダ２００およびビデオデコーダ３００は、様々なサイズを有するＰＵをサポートし得る。上で示したように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指し得、ＰＵのサイズは、ＰＵのルーマ予測単位のサイズを指し得る。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２００は、イントラ予測の場合には、２Ｎ×２ＮまたはＮ×ＮというＰＵサイズを、インター予測の場合には、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、等という対称ＰＵサイズをサポートし得る。ビデオエンコーダ２００およびビデオデコーダ３００はまた、インター予測の場合に、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮというＰＵサイズについての非対称区分をサポートし得る。

[0153] モード選択ユニットがこれ以上ＣＵをＰＵに区分しない例において、各ＣＵは、ルーマコーディングブロックおよび対応するクロマコーディングブロックに関連付けられ得る。以上のように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指し得る。ビデオエンコーダ２００およびビデオデコーダ１２０は、２Ｎ×２Ｎ、２Ｎ×Ｎ、またはＮ×２ＮのＣＵサイズをサポートし得る。

[0154] いくつかの例として、イントラブロックコピーモードコーディング、アフィンモードコーディング、および線形モデル（ＬＭ）モードコーディングのような他のビデオコーディング技法の場合、モード選択ユニット２０２は、コーディング技法に関連するそれぞれのユニットを介して、符号化されている現在ブロックのための予測ブロックを生成する。パレットモードコーディングのようないくつかの例において、モード選択ユニット２０２は、予測ブロックを生成せず、代わりに、選択されたパレットに基づいてブロックを再構築する方法を示すシンタックス要素を生成し得る。そのようなモードにおいて、モード選択ユニット２０２は、符号化されるために、これらのシンタックス要素をエントロピー符号化ユニット２２０に提供し得る。

[0155] 上で説明したように、残差生成ユニット２０４は、現在ブロックおよび対応する予測ブロックのためのビデオデータを受信する。次いで、残差生成ユニット２０４は、現在ブロックのための残差ブロックを生成する。残差ブロックを生成するために、残差生成ユニット２０４は、予測ブロックと現在ブロックとの間のサンプルごとの差分を算出する。

[0156] 変換処理ユニット２０６は、変換係数のブロック（本明細書において「変換係数ブロック」と呼ばれる）を生成するために、残差ブロックに１つまたは複数の変換を適用する。変換処理ユニット２０６は、変換係数ブロックを形成するために、残差ブロックに様々な変換を適用し得る。例えば、変換処理ユニット２０６は、離散コサイン変換（ＤＣＴ）、方向性変換、カルーネンレーベ変換（ＫＬＴ）、または概念的に類似した変換を残差ブロックに適用し得る。いくつかの例において、変換処理ユニット２０６は、残差ブロックへの複数の変換、例えば、一次変換と、回転変換のような二次変換とを実行し得る。いくつかの例において、変換処理ユニット２０６は、残差ブロックに変換を適用しない。

[0157] 量子化ユニット２０８は、量子化された変換係数ブロックを作り出すために、変換係数ブロック中の変換係数を量子化し得る。量子化ユニット２０８は、現在ブロックに関連する量子化パラメータ（ＱＰ：quantization parameter）値に従って変換係数ブロックの変換係数を量子化し得る。ビデオエンコーダ２００は（例えば、モード選択ユニット２０２を介して）、ＣＵに関連するＱＰ値を調整することによって、現在ブロックに関連する変換係数ブロックに適用される量子化の度合いを調整し得る。量子化は、情報の損失をもたらし得るため、量子化された変換係数は、変換処理ユニット２０６によって作り出された元の変換係数より低い精度を有し得る。

[0158] 逆量子化ユニット２１０および逆変換処理ユニット２１２は、変換係数ブロックから残差ブロックを再構築するために、それぞれ量子化された変換係数ブロックに逆量子化および逆変換を適用し得る。再構築ユニット２１４は、再構築された残差ブロックと、モード選択ユニット２０２によって生成された予測ブロックとに基づいて、（ある程度の歪みを伴う可能性があるが）現在ブロックに対応する再構築されたブロックを作り出し得る。例えば、再構築ユニット２１４は、再構築されたブロックを作り出すために、再構築された残差ブロックのサンプルを、モード選択ユニット２０２によって生成された予測ブロックからの対応するサンプルに加算し得る。

[0159] フィルタユニット２１６は、再構築されたブロックに対して１つまたは複数のフィルタ動作を実行し得る。例えば、フィルタユニット２１６は、ＣＵのエッジに沿ったブロッキネスアーティファクトを低減するためにデブロッキング動作を実行し得る。いくつかの例では、フィルタユニット２１６の動作がスキップされ得る。

[0160] ビデオエンコーダ２００は、再構築されたブロックをＤＰＢ２１８に記憶する。例えば、フィルタユニット２１６の動作が必要とされない例では、再構築ユニット２１４が、再構築されたブロックをＤＰＢ２１８に記憶し得る。フィルタユニット２１６の動作が必要とされる例では、フィルタユニット２１６が、フィルタ処理された再構築されたブロックをＤＰＢ２１８に記憶し得る。動き推定ユニット２２２および動き補償ユニット２２４は、後に符号化されるピクチャのブロックをインター予測するために、再構築された（および潜在的にフィルタ処理された）ブロックから形成された参照ピクチャをＤＰＢ２１８から取り出し得る。加えて、イントラ予測ユニット２２６は、現在ピクチャ中の他のブロックをイントラ予測するために、現在ピクチャのＤＰＢ２１８中の再構築されたブロックを使用し得る。

[0161] 概して、エントロピー符号化ユニット２２０は、ビデオエンコーダ２００の他の機能構成要素から受信されたシンタックス要素をエントロピー符号化し得る。例えば、エントロピー符号化ユニット２２０は、量子化ユニット２０８からの量子化された変換係数ブロックをエントロピー符号化し得る。別の例として、エントロピー符号化ユニット２２０は、モード選択ユニット２０２からの予測シンタックス要素（例えば、インター予測の動き情報またはイントラ予測のためのイントラモード情報）をエントロピー符号化し得る。エントロピー符号化ユニット２２０は、エントロピー符号化されたデータを生成するために、ビデオデータの別の例であるシンタックス要素に対して、１つまたは複数のエントロピー符号化動作を実行し得る。例えば、エントロピー符号化ユニット２２０は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）動作、ＣＡＢＡＣ動作、Ｖ２Ｖ（variable-to-variable）長コーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）動作、確率区間区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作をデータに対して実行し得る。いくつかの例において、エントロピー符号化ユニット２２０は、シンタックス要素がエントロピー符号化されないバイパスモードで動作し得る。

[0162] ビデオエンコーダ２００は、スライスまたはピクチャのブロックを再構築するために必要とされるエントロピー符号化されたシンタックス要素を含むビットストリームを出力し得る。特に、エントロピー符号化ユニット２２０は、ビットストリームを出力し得る。

[0163] 上で説明した動作は、ブロックに関して説明される。そのような説明は、ルーマコーディングブロックおよび／またはクロマコーディングブロックのための動作であると理解されるべきである。上で説明したように、いくつかの例において、ルーマコーディングブロックおよびクロマコーディングブロックは、ＣＵのルーマ成分およびクロマ成分である。いくつかの例において、ルーマコーディングブロックおよびクロマコーディングブロックは、ＰＵのルーマ成分およびクロマ成分である。

[0164] いくつかの例では、ルーマコーディングブロックに関して実行された動作が、クロマコーディングブロックについて繰り返される必要はない。一例として、ルーマコーディングブロックの動きベクトル（ＭＶ）および参照ピクチャを識別するための動作が、クロマブロックのＭＶおよび参照ピクチャを識別するために繰り返される必要はない。むしろ、ルーマコーディングブロックのＭＶは、クロマブロックのＭＶを決定するためにスケーリングされ得、参照ピクチャは同じであり得る。別の例として、イントラ予測プロセスは、ルーマコーディングブロックおよびクロマコーディングブロックについて同じであり得る。

[0165] ビデオエンコーダ２００は、ビデオデータを記憶するように構成されたメモリと、回路で実施され、第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、第２のＣＴＵラインの動き情報をメモリの第２の履歴ＭＶＰバッファに記憶することと、ここで、第２のＣＴＵラインは、第１のＣＴＵラインとは異なる、を行うように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを符号化するように構成されたデバイスの例を表す。

[0166] ビデオエンコーダ２００はまた、ビデオデータを記憶するように構成されたメモリと、回路で実施され、コーディングされた動き情報を履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、異なるタイプの動き情報を履歴ＭＶＰバッファに記憶することと、履歴ＭＶＰバッファの動き情報を使用してビデオデータのブロックの動き情報をコーディングすることとを行うように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを符号化するように構成されたデバイスの例を表す。

[0167] ビデオエンコーダ２００はまた、ビデオデータを記憶するように構成されたメモリと、回路で実施され、複数の異なるタイプの動き情報をそれぞれの異なる履歴動きベクトル予測子（ＭＶＰ）バッファに記憶するように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを符号化するように構成されたデバイスの例を表す。

[0168] 図１５は、本開示の技法を実行し得る例となるビデオデコーダ３００を例示するブロック図である。図１５は、説明のために提供されており、本開示で広範に実証および説明される技法を限定するものではない。説明のために、本開示は、ＪＥＭおよびＨＥＶＣの技法によるビデオデコーダ３００を記載する。しかしながら、本開示の技法は、他のビデオコーディング規格に従って構成されたビデオコーディングデバイスによって実行され得る。

[0169] 図１５の例において、ビデオデコーダ３００は、符号化ピクチャバッファ（ＣＰＢ：coded picture buffer）メモリ３２０と、エントロピー復号ユニット３０２と、予測処理ユニット３０４と、逆量子化ユニット３０６と、逆変換処理ユニット３０８と、再構築ユニット３１０と、フィルタユニット３１２と、復号ピクチャバッファ（ＤＰＢ）３１４とを含む。ＣＰＢメモリ３２０、エントロピー復号ユニット３０２、予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構築ユニット３１０、フィルタユニット３１２、およびＤＰＢ３１４のうちのいずれかまたは全ては、１つまたは複数のプロセッサにおいてまたは処理回路において実施され得る。さらに、ビデオデコーダ３００は、これらおよび他の機能を実行するための追加または代替のプロセッサまたは処理回路を含み得る。

[0170] 予測処理ユニット３０４は、動き補償ユニット３１６と、イントラ予測ユニット３１８とを含む。予測処理ユニット３０４は、他の予測モードに従って予測を実行するための加算ユニットを含み得る。例として、予測処理ユニット３０４は、パレットユニット、（動き補償ユニット３１６の一部を形成し得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ）ユニット、または同様のものを含み得る。他の例において、ビデオデコーダ３００は、より多くの、より少ない、または異なる機能構成要素を含み得る。

[0171] ＣＰＢメモリ３２０は、ビデオデコーダ３００の構成要素によって復号されることとなる符号化ビデオビットストリームのようなビデオデータを記憶し得る。ＣＰＢメモリ３２０に記憶されるビデオデータは、例えば、コンピュータ読取可能な媒体１１０（図１）から取得され得る。ＣＰＢメモリ３２０は、符号化ビデオビットストリームからの符号化ビデオデータ（例えば、シンタックス要素）を記憶するＣＰＢを含み得る。また、ＣＰＢメモリ３２０は、ビデオデコーダ３００の様々なユニットからの出力を表す一時データのような、コーディングされたピクチャのシンタックス要素以外のビデオデータを記憶し得る。ＤＰＢ３１４は、一般に、ビデオデコーダ３００が符号化ビデオビットストリームの後続のデータまたはピクチャを復号するときに参照ビデオデータとして出力および／または使用し得る復号ピクチャを記憶する。ＣＰＢメモリ３２０およびＤＰＢ３１４は、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）を含むＤＲＡＭ、磁気ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ）のような様々なメモリデバイスまたは他のタイプのメモリデバイスのうちの任意のものによって形成され得る。ＣＰＢメモリ３２０およびＤＰＢ３１４は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例において、ＣＰＢメモリ３２０は、ビデオデコーダ３００の他の構成要素とともにオンチップであり得るか、これらの構成要素に対してオフチップであり得る。

[0172] 追加的にまたは代替的に、いくつかの例において、ビデオデコーダ３００は、コード化されたビデオデータをメモリ１２０（図１）から取り出し得る。すなわち、メモリ１２０は、ＣＰＢメモリ３２０を用いて上述したようにデータを記憶し得る。同様に、メモリ１２０は、ビデオデコーダ３００の機能性のうちの一部または全部が、ビデオデコーダ３００の処理回路によって実行されるソフトウェアで実施されるとき、ビデオデコーダ３００によって実行されるべき命令を記憶し得る。

[0173] 図１５に示される様々なユニットは、ビデオデコーダ３００によって実行される動作の理解を助けるために例示される。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実施され得る。図１４と同様に、固定機能回路は、特定の機能性を提供する回路を指し、実行され得る動作にプリセットされている。プログラマブル回路は、様々なタスクを実行し、実行され得る動作において柔軟な機能性を提供するようにプログラムされ得る回路を指す。例えば、プログラマブル回路は、ソフトウェアまたはファームウェアの命令によって定義された方法でプログラマブル回路を動作させるソフトウェアまたはファームウェアを実行し得る。固定機能回路は、（例えば、パラメータを受信するためまたはパラメータを出力するために）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは一般に不変である。いくつかの例において、ユニットのうちの１つまたは複数は、別個の回路ブロック（固定機能またはプログラマブル）であり得、いくつかの例において、１つまたは複数のユニットは、集積回路であり得る。

[0174] ビデオデコーダ３００は、ＡＬＵ、ＥＦＵ、デジタル回路、アナログ回路、および／またはプログラマブル回路から形成されたプログラマブルコアを含み得る。ビデオデコーダ３００の動作がプログラマブル回路上で実行するソフトウェアによって実行される例では、オンチップまたはオフチップメモリが、ビデオデコーダ３００が受信して実行するソフトウェアの命令（例えば、オブジェクトコード）を記憶し得る。

[0175] エントロピー復号ユニット３０２は、ＣＰＢから符号化ビデオデータを受信し、シンタックス要素を再生するためにビデオデータをエントロピー復号し得る。予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構築ユニット３１０、およびフィルタユニット３１２は、ビットストリームから抽出されたシンタックス要素に基づいて、復号ビデオデータを生成し得る。

[0176] 概して、ビデオデコーダ３００は、ブロック単位でピクチャを再構築する。ビデオデコーダ３００は、各ブロックに対して個別に再構築動作を実行し得る（ここで、現在再構築されている、すなわち復号されているブロックは、「現在ブロック」と呼ばれ得る）。

[0177] エントロピー復号ユニット３０２は、量子化された変換係数ブロックの量子化された変換係数を定義するシンタックス要素、並びに量子化パラメータ（ＱＰ）および／または（１つまたは複数の）変換モードインジケーションのような変換情報をエントロピー復号し得る。逆量子化ユニット３０６は、量子化された変換係数ブロックに関連するＱＰを使用して、量子化の程度を決定し、同様に、逆量子化ユニット３０６が適用すべき逆量子化の程度を決定し得る。例えば、逆量子化ユニット３０６は、量子化された変換係数を逆量子化するためにビット単位の左シフト演算を実行し得る。それによって、逆量子化ユニット３０６は、変換係数を含む変換係数ブロックを形成し得る。

[0178] 逆量子化ユニット３０６が変換係数ブロックを形成した後、逆変換処理ユニット３０８は、現在ブロックに関連する残差ブロックを生成するために、この変換係数ブロックに１つまたは複数の逆変換を適用し得る。例えば、逆変換処理ユニット３０８は、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向性変換、または別の逆変換を係数ブロックに適用し得る。

[0179] さらに、予測処理ユニット３０４は、エントロピー復号ユニット３０２によってエントロピー復号された予測情報シンタックス要素に従って予測ブロックを生成する。例えば、現在ブロックがインター予測されることを予測情報シンタックス要素が示す場合、動き補償ユニット３１６は、予測ブロックを生成し得る。この場合、予測情報シンタックス要素は、参照ブロックを取り出すべきＤＰＢ３１４中の参照ピクチャと、現在ピクチャ中の現在ブロックのロケーションに対する参照ピクチャ中の参照ブロックのロケーションを識別する動きベクトルとを示し得る。動き補償ユニット３１６は、一般に、動き補償ユニット２２４（図１４）に関して説明した方法と実質的に同様の方法でインター予測プロセスを実行し得る。

[0180] 本開示の技法によれば、復号ピクチャバッファ３１４は、ＣＴＵのラインのための１つまたは複数の履歴ＭＶＰバッファを含み得る。すなわち、各ＣＴＵラインがそれ自体のＭＶＰバッファを割り振られ得るか、または単一のＭＶＰバッファが複数のＣＴＵラインに使用され得る。いずれの場合も、ビデオデコーダ３００は、ＣＴＵラインのビデオデータの符号化開始時に、ＣＴＵラインのためのＭＶＰバッファをリセットし得る。動き補償ユニット３１６またはビデオデコーダ３００の別のユニットは、一意の動きベクトルだけをＭＶＰバッファに記憶するように構成され得る。上述したように、動き補償ユニット３１６またはビデオデコーダ３００の別のユニットは、ＭＶＰバッファに記憶された動き情報を管理するためにＦＩＦＯ規則を使用するように構成され得、その結果、動きベクトルをＭＶＰバッファに追加するとき、ＭＶＰバッファが満杯である場合、動き補償ユニット３１６は、最も早く追加された動きベクトルをＭＶＰバッファから除去し得る。いくつかの例において、ビデオデコーダ３００は、例えば、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ、および時間的動き予測のような、様々な動きモデルの各々について異なるそれぞれのＭＶＰバッファを維持し得る。

[0181] 別の例として、現在ブロックがイントラ予測されることを予測情報シンタックス要素が示す場合、イントラ予測ユニット３１８は、予測情報シンタックス要素によって示されるイントラ予測モードに従って予測ブロックを生成し得る。この場合も、イントラ予測ユニット３１８は、一般に、イントラ予測ユニット２２６（図１４）に関して説明した方法と実質的に同様の方法でイントラ予測プロセスを実行し得る。イントラ予測ユニット３１８は、ＤＰＢ３１４から現在ブロックに隣接するサンプルのデータを取り出し得る。

[0182] 再構築ユニット３１０は、予測ブロックと残差ブロックとを使用して現在ブロックを再構築し得る。例えば、再構築ユニット３１０は、現在ブロックを再構築するために、残差ブロックのサンプルを予測ブロックの対応するサンプルに加算し得る。

[0183] フィルタユニット３１２は、再構築されたブロックに対して１つまたは複数のフィルタ動作を実行し得る。例えば、フィルタユニット３１２は、再構築されたブロックのエッジに沿ってブロッキネスアーティファクトを低減させるためにデブロッキング動作を実行し得る。フィルタユニット３１２の動作は、必ずしも全ての例において実行されるとは限らない。

[0184] ビデオデコーダ３００は、再構築されたブロックをＤＰＢ３１４に記憶し得る。例えば、フィルタユニット３１２の動作が必要とされない例では、再構築ユニット３１０が、再構築されたブロックをＤＰＢ３１４に記憶し得る。フィルタユニット３１２の動作が必要とされる例では、フィルタユニット３１２が、フィルタ処理された再構築されたブロックをＤＰＢ３１４に記憶し得る。上述したように、ＤＰＢ３１４は、イントラ予測のためには現在ピクチャのおよび後続の動き補償のためには前に復号されたピクチャとのサンプル、といった参照情報を予測処理ユニット３０４に提供し得る。さらに、ビデオデコーダ３００は、図１のディスプレイデバイス１１８のようなディスプレイデバイス上での後続の提示のために、ＤＰＢ３１４から復号ピクチャを出力し得る。

[0185] ビデオデコーダ３００は、ビデオデータを記憶するように構成されたメモリと、回路で実施され、（ビデオコーディングプロセスの第１のスレッドによって処理され得る）第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、（ビデオコーディングプロセスの第２のスレッドによって処理され得る）第２のＣＴＵラインの動き情報をメモリの第２の履歴ＭＶＰバッファに記憶することと、ここで、第２のＣＴＵラインは、第１のＣＴＵラインとは異なる、を行うように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを復号するように構成されたデバイスの例を表す。第２のスレッドは、第１のスレッドと異なり得る。

[0186] ビデオデコーダ３００はまた、ビデオデータを記憶するように構成されたメモリと、回路で実施され、コーディングされた動き情報を履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、異なるタイプの動き情報を履歴ＭＶＰバッファに記憶することと、履歴ＭＶＰバッファの動き情報を使用してビデオデータのブロックの動き情報をコーディングすることとを行うように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを復号するように構成されたデバイスの例を表す。

[0187] ビデオデコーダ３００はまた、ビデオデータを記憶するように構成されたメモリと、回路で実施され、複数の異なるタイプの動き情報をそれぞれの異なる履歴動きベクトル予測子（ＭＶＰ）バッファに記憶するように構成された１つまたは複数の処理ユニットとを含む、ビデオデータを復号するように構成されたデバイスの例を表す。

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

[0189] この例において、ビデオエンコーダ２００は、動き情報を使用して現在ブロックを最初に予測する（３５０）。例えば、ビデオエンコーダ２００は、動き情報を使用して現在ブロックのための予測ブロックを形成し得る。次いで、ビデオエンコーダ２００は、現在ブロックのための残差ブロックを算出し得る（３５２）。残差ブロックを算出するために、ビデオエンコーダ２００は、元の符号化されていないブロックと現在ブロックのための予測ブロックとの間の差分を算出し得る。次いで、ビデオエンコーダ２００は、残差ブロックの係数を変換および量子化し得る（３５４）。次に、ビデオエンコーダ２００は、残差ブロックの量子化された変換係数を走査し得る（３５６）。走査中、または走査に続いて、ビデオエンコーダ２００は、本開示の技法を使用して係数と動き情報とをエントロピー符号化し得る（３５８）。ビデオエンコーダ２００は、ＣＡＶＬＣまたはＣＡＢＡＣを使用して係数を符号化し得る。

[0190] ビデオエンコーダ２００は、本開示の技法のうちのいずれかまたは全てに従って、例えば、ＨＭＶＰ候補を含む動き情報候補リストを構築し、ブロックの動き情報のための予測子を表す候補インデックスを選択し、候補インデックスをエントロピー符号化し得る。本開示の技法によれば、ビデオエンコーダ２００は、対応するＣＴＵラインの動き情報を記憶するためにＭＶＰバッファを使用する前に、ＭＶＰバッファをリセットし得る。いくつかの例では、各ＣＴＵラインがそれ自体のＭＶＰバッファを有し得るか、または１つのＭＶＰバッファが複数のＣＴＵラインに使用され得る。さらに、ビデオエンコーダ２００は、複数のタイプの動き情報をＭＶＰバッファ、例えば、同じバッファまたは異なるそれぞれの動きモデルバッファに記憶し得る。ビデオエンコーダ２００は、ＭＶＰバッファのデータから選択された動きベクトル予測子を使用して現在ブロックの動き情報を符号化し得る。次いで、ビデオエンコーダ２００は、例えば、候補インデックスのような、動き情報および係数のためのデータを含む、ブロックのエントロピーコーディングされたデータを出力し得る（３６０）。

[0191] このように、図１６の方法は、ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、メモリの第２の履歴ＭＶＰバッファをリセットすることと、第２の履歴ＭＶＰバッファをリセットした後に、ピクチャの第２のＣＴＵラインの動き情報を第２の履歴ＭＶＰバッファに記憶することと、ここで、第２のＣＴＵラインは、第１のＣＴＵラインとは異なる、を含む方法の例を表す。

[0192] 図１６の方法はまた、動き情報を履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、異なるタイプの動き情報を履歴ＭＶＰバッファに記憶することと、履歴ＭＶＰバッファの動き情報を使用してビデオデータのブロックの動き情報をコーディングすることとを含む方法の例を表す。

[0193] 図１６の方法はまた、複数の異なるタイプの動き情報をそれぞれの異なる履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することを含む方法の例を表す。

[0194] 図１７は、本開示の技法による、ビデオデータの現在ブロックを復号するための例となる方法を例示するフローチャートである。現在ブロックは、現在ＣＵを備え得る。ビデオデコーダ３００（図１および１５）に関して説明したが、他のデバイスが図１７の方法と同様の方法を実行するように構成され得ることは理解されるべきである。

[0195] ビデオデコーダ３００は、現在ブロックに対応する残差ブロックの係数のためのエントロピーコーディングされた予測情報およびエントロピーコーディングされたデータのような、現在ブロックのためのエントロピーコーディングされたデータを受信し得る（３７０）。上述したように、エントロピーコーディングされた予測情報は、例えば、本開示の技法に従って、ＨＭＶＰ候補を含み得る候補リストに候補インデックスを含め得る。ビデオデコーダ３００は、現在ブロックのための予測情報を決定するため、および、残差ブロックの係数を再生するために、エントロピーコーディングされたデータをエントロピー復号し得る（３７２）。ビデオデコーダ３００は、現在ブロックの予測ブロックを算出するために、例えば、現在ブロックのための予測情報によって示された予測モードを使用して、現在ブロックを予測し得る（３７４）。

[0196] 特に、ビデオデコーダ３００は、上述したように、ＨＭＶＰ候補を含む候補リストを構築し、次いで、復号された候補インデックスを使用して、現在ブロックのための動きベクトル予測子として使用すべき候補を候補リストから決定し得る。本開示の技法によれば、ビデオデコーダ３００は、対応するＣＴＵラインの動き情報を記憶するためにＭＶＰバッファを使用する前に、ＭＶＰバッファをリセットし得る。いくつかの例では、各ＣＴＵラインがそれ自体のＭＶＰバッファを有し得るか、または１つのＭＶＰバッファが複数のＣＴＵラインに使用され得る。さらに、ビデオデコーダ３００は、複数のタイプの動き情報をＭＶＰバッファ、例えば、同じバッファまたは異なるそれぞれの動きモデルバッファに記憶し得る。ビデオデコーダ３００は、ＭＶＰバッファのデータから動きベクトル予測子を使用して選択し得る。

[0197] 次いで、ビデオデコーダ３００は、動きベクトル予測子を使用して現在ブロックのための動きベクトルを再構築し、次いで、予測ブロックを生成するために動きベクトルを使用して現在ブロックを予測し得る。次いで、ビデオデコーダ３００は、量子化された変換係数のブロックを作成するために、再生された係数を逆走査し得る（３７６）。次いで、ビデオデコーダ３００は、残差ブロックを作り出すために、係数を逆量子化および逆変換し得る（３７８）。ビデオデコーダ３００は、最終的に、予測ブロックと残差ブロックとを組み合わせることによって現在ブロックを復号し得る（３８０）。

[0198] このように、図１７の方法は、ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、メモリの第２の履歴ＭＶＰバッファをリセットすることと、第２の履歴ＭＶＰバッファをリセットした後に、ピクチャの第２のＣＴＵラインの動き情報を第２の履歴ＭＶＰバッファに記憶することと、ここで、第２のＣＴＵラインは、第１のＣＴＵラインとは異なる、を含む方法の例を表す。

[0199] 図１７の方法はまた、動き情報を履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、異なるタイプの動き情報を履歴ＭＶＰバッファに記憶することと、履歴ＭＶＰバッファの動き情報を使用してビデオデータのブロックの動き情報をコーディングすることとを含む方法の例を表す。

[0200] 図１７の方法はまた、複数の異なるタイプの動き情報をそれぞれの異なる履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することを含む方法の例を表す。

[0201] 図１８は、本開示の技法による、ビデオデータをコーディング（符号化または復号）する例となる方法を例示するフローチャートである。例えば、図１８の方法は、図１６のステップ３５０または図１７のステップ３７４の間に実行され得る。例示および説明のために、図１８の方法は、ビデオデコーダ３００に関して説明されるが、ビデオエンコーダ２００もまた、この方法または同様の方法を実行し得る。

[0202] ビデオデコーダ３００は、例えば、イントラ予測またはインター予測を使用して、ピクチャの第１のＣＴＵラインのブロックをコーディングし得る（３９０）。ビデオデコーダ３００は、ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報を、例えばＤＰＢ３１４の第１のバッファに記憶する（３９２）。ビデオデコーダ３００は、インター予測コーディング中に使用される動き情報をコーディングするために、第１のバッファの動き情報を使用し得る。いくつかの例では、ビデオデコーダ３００によって実行されるビデオコーディングプロセスの第１のスレッドが、第１のＣＴＵラインをコーディングし得る。

[0203] ビデオデコーダ３００はまた、例えば、ＤＰＢ３１４の第２のバッファをリセットし得る（３９４）。第２のバッファは、第１のバッファと同じであり得るか、または異なるバッファであり得る。ビデオデコーダ３００はまた、第２のＣＴＵラインのブロックをコーディングし得る（３９６）。ビデオデコーダ３００は、第２のＣＴＵラインの動き情報を第２のバッファに記憶し得る（３９８）。いくつかの例では、ビデオデコーダ３００によって実行されるビデオコーディングプロセスの第２のスレッドが、第２のＣＴＵラインをコーディングし得、ここで、第２のスレッドは、第１のスレッドとは異なる。

[0204] このように、図１８の方法は、ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、メモリの第２の履歴ＭＶＰバッファをリセットすることと、第２の履歴ＭＶＰバッファをリセットした後に、ピクチャの第２のＣＴＵラインの動き情報を第２の履歴ＭＶＰバッファに記憶することと、ここで、第２のＣＴＵラインは、第１のＣＴＵラインとは異なる、を含む方法の例を表す。

[0205] 例によっては、本明細書で説明した技法のうちの任意のものの特定の動作（ａｃｔ）またはイベントが、異なる順序で実行され得、追加、混合、または完全に省略され得る（例えば、説明した全ての動作またはイベントが本技法の実践に必要なわけではない）ことは認識されるべきである。さらに、特定の例では、動作またはイベントが、連続してではなく、例えば、マルチスレッド処理、割込み処理、または複数のプロセッサによって同時に実行され得る。

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

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

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

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

[0210] 様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。

Claims (50)

1. ビデオデータをコーディングする方法であって、
   ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、
   前記メモリの第２の履歴ＭＶＰバッファをリセットすることと、
   前記第２の履歴ＭＶＰバッファをリセットした後に、前記ピクチャの第２のＣＴＵラインの動き情報を前記第２の履歴ＭＶＰバッファに記憶することと、ここで、前記第２のＣＴＵラインは、前記第１のＣＴＵラインとは異なる、
   を備える方法。
2. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファとは異なり、前記第１のＣＴＵラインの前記動き情報を記憶することは、ビデオコーディングプロセスの第１のスレッドによって、前記第１のＣＴＵラインの前記動き情報を記憶することを備え、前記第２のＣＴＵラインの前記動き情報を記憶することは、前記ビデオコーディングプロセスの第２のスレッドによって、前記第２のＣＴＵラインの前記動き情報を記憶することを備え、ここで、前記第１のスレッドは、前記第２のスレッドとは異なる、請求項１に記載の方法。
3. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファと同じであり、前記第２の履歴ＭＶＰバッファをリセットすることは、波面並列処理中に前記第２のＣＴＵラインの開始を処理することに応答して前記第２の履歴ＭＶＰバッファをリセットすることを備える、請求項１に記載の方法。
4. 前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第１の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第１の履歴ＭＶＰバッファに記憶することを備え、
   前記第２のＣＴＵラインの前記動き情報を記憶することは、前記第２の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第２の履歴ＭＶＰバッファに記憶することを備える、
   請求項１に記載の方法。
5. 前記第１の履歴ＭＶＰバッファが満杯になると、先入れ先出し（ＦＩＦＯ）規則に従って前記第１の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと、
   前記第２の履歴ＭＶＰバッファが満杯になると、前記ＦＩＦＯ規則に従って前記第２の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと
   をさらに備える、請求項１に記載の方法。
6. 前記第１のＣＴＵラインの前記動き情報を記憶することは、複数の異なるタイプの動きモデルの各々の動き情報を、前記第１の履歴ＭＶＰバッファを含む第１の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶することを備え、
   前記第２のＣＴＵラインの前記動き情報を記憶することは、前記複数の異なるタイプの動きモデルの各々の動き情報を、前記第２の履歴ＭＶＰバッファを含む第２の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶することを備える、
   請求項１に記載の方法。
7. 前記複数の異なるタイプの動きモデルは、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロック動きベクトル予測（ＭＶＰ）、または時間的動き予測のうちの１つまたは複数を備える、請求項６に記載の方法。
8. １つまたは複数の履歴ＭＶＰバッファ内の２つ以上のＭＶＰから合成ＭＶＰを生成することをさらに備える、請求項１に記載の方法。
9. 前記２つ以上のＭＶＰは、コーディングされた動き情報、アフィン動きモデル動き情報、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ動き情報、時間的動き予測子動き情報、ＭＶＰ動き情報に基づく合成動きベクトル情報、空間ＭＶＰ動き情報、または時間ＭＶＰ動き情報のうちの２つ以上を備える異なる動き情報タイプを有する、請求項８に記載の方法。
10. 前記第１のＣＴＵラインの前記動き情報を記憶することは、第１の事前定義された動き情報で前記第１の履歴ＭＶＰバッファを事前に満たすことをさらに備え、ここにおいて、前記第１の事前定義された動き情報は、第１の参照フレームインデックスと第１のインター予測方向とを有する第１のゼロ動きベクトルを備える、
    前記第２のＣＴＵラインの前記動き情報を記憶することは、第２の事前定義された動き情報で前記第２の履歴ＭＶＰバッファを事前に満たすことをさらに備え、ここにおいて、前記第２の事前定義された動き情報は、第２の参照フレームインデックスと第２のインター予測方向とを有する第２のゼロ動きベクトルを備える、
    請求項１に記載の方法。
11. 前記第１のＣＴＵラインと前記第２のＣＴＵラインとを含むピクチャは、第１の時間レイヤ内にあり、
    前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第１の時間レイヤまたは前記第１の時間レイヤより低い１つまたは複数の時間レイヤ内の第１の１つまたは複数のコーディングされたピクチャからの第１の動き情報で前記第１の履歴ＭＶＰバッファを事前に満たすことをさらに備え、
    前記第２のＣＴＵラインの前記動き情報を記憶することは、前記第１の時間レイヤまたは前記第１の時間レイヤより低い１つまたは複数の時間レイヤ内の第２の１つまたは複数のコーディングされたピクチャからの第２の動き情報で前記第２の履歴ＭＶＰバッファを事前に満たすことをさらに備え、
    前記方法は、時間差に従って前記第１の動き情報または前記第２の動き情報のうちの少なくとも１つをスケーリングすることをさらに備える、
    請求項１に記載の方法。
12. 第１の参照フレームインデックスと第１のインター予測方向とを有する第１のゼロ動きベクトルで前記第１の履歴ＭＶＰバッファを初期化することと、
    第２の参照フレームインデックスと第２のインター予測方向とを有する第２のゼロ動きベクトルで前記第２の履歴ＭＶＰバッファを初期化することと
    をさらに備える、請求項１に記載の方法。
13. 前記第２のＣＴＵラインは、前記第１のＣＴＵラインの真下にあり、前記方法は、前記第１の履歴ＭＶＰバッファを使用して前記第２の履歴ＭＶＰバッファを初期化または変更することをさらに備える、請求項１に記載の方法。
14. 前記第１の履歴ＭＶＰバッファを使用して前記第１のＣＴＵラインのＣＴＵのコーディング単位（ＣＵ）を復号することと、
    前記第２の履歴ＭＶＰバッファを使用して前記第２のＣＴＵラインのＣＴＵのＣＵを復号することと
    をさらに備える、請求項１に記載の方法。
15. 前記第１の履歴ＭＶＰバッファを使用して前記第１のＣＴＵラインのＣＴＵのコーディング単位（ＣＵ）を符号化することと、
    前記第２の履歴ＭＶＰバッファを使用して前記第２のＣＴＵラインのＣＴＵのＣＵを符号化することと
    をさらに備える、請求項１に記載の方法。
16. 前記第１の履歴ＭＶＰバッファを使用して前記第１のＣＴＵラインのＣＴＵのコーディング単位（ＣＵ）の第１の動き情報をコーディングすることと、ここにおいて、前記第１の動き情報をコーディングすることは、ＡＭＶＰ、マージ、またはアフィンモードを使用して前記第１の動き情報をコーディングすることを備える、
    前記第２の履歴ＭＶＰバッファを使用して前記第２のＣＴＵラインのＣＴＵのＣＵの第２の動き情報をコーディングすることと、ここにおいて、前記第２の動き情報をコーディングすることは、ＡＭＶＰ、マージ、またはアフィンモードを使用して前記第２の動き情報をコーディングすることを備える、
    をさらに備える、請求項１に記載の方法。
17. 前記第１の履歴ＭＶＰバッファ内の第１の単方向動き情報を第１の双方向動き情報に変換するために、前記第１の単方向動き情報の第１の１つまたは複数の動きベクトルに１つまたは複数の動きベクトルを追加することと、
    前記第２の履歴ＭＶＰバッファ内の第２の単方向動き情報を第２の双方向動き情報に変換するために、前記第２の単方向動き情報の第２の１つまたは複数の動きベクトルに１つまたは複数の動きベクトルを追加することと
    をさらに備える、請求項１に記載の方法。
18. 前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第１の履歴ＭＶＰバッファ内の他の動きベクトルとしきい値だけ異なる動きベクトルだけを前記第１の履歴ＭＶＰバッファに記憶することを備え、
    前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第２の履歴ＭＶＰバッファ内の他の動きベクトルと前記しきい値だけ異なる動きベクトルだけを前記第２の履歴ＭＶＰバッファに記憶することを備える、
    請求項１に記載の方法。
19. 前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第１のＣＴＵラインの前記動き情報の動きベクトルがマージモードコーディングされたコーディング単位（ＣＵ）に関連付けられているかＡＭＶＰコーディングされたＣＵに関連付けられているかを示すデータを記憶することを備え、
    前記第１のＣＴＵラインの前記動き情報を記憶することは、前記第２のＣＴＵラインの前記動き情報の動きベクトルがマージモードコーディングされたＣＵに関連付けられているかＡＭＶＰコーディングされたＣＵに関連付けられているかを示すデータを記憶することを備える、
    請求項１に記載の方法。
20. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    回路で実施され、
    ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報を前記メモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、
    前記メモリの第２の履歴ＭＶＰバッファをリセットすることと、
    前記第２の履歴ＭＶＰバッファをリセットした後に、前記ピクチャの第２のＣＴＵラインの動き情報を前記第２の履歴ＭＶＰバッファに記憶することと、ここで、前記第２のＣＴＵラインは、前記第１のＣＴＵラインとは異なる、
    を行うように構成された１つまたは複数の処理ユニットと
    を備えるデバイス。
21. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファとは異なり、前記１つまたは複数のプロセッサは、前記第１のＣＴＵラインの前記動き情報を記憶するためにビデオコーディングプロセスの第１のスレッドを実行し、前記１つまたは複数のプロセッサは、前記第２のＣＴＵラインの前記動き情報を記憶するために前記ビデオコーディングプロセスの第２のスレッドを実行し、ここで、前記第１のスレッドは、前記第２のスレッドとは異なる、請求項２０に記載のデバイス。
22. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファと同じであり、前記第２の履歴ＭＶＰバッファをリセットするために、前記１つまたは複数の処理ユニットは、波面並列処理中に前記第２のＣＴＵラインの開始を処理することに応答して前記第２の履歴ＭＶＰバッファをリセットするように構成される、請求項２０に記載のデバイス。
23. 前記１つまたは複数の処理ユニットは、前記第１の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第１の履歴ＭＶＰバッファに記憶するように構成され、
    前記１つまたは複数の処理ユニットは、前記第２の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第２の履歴ＭＶＰバッファに記憶するように構成される、
    請求項２０に記載のデバイス。
24. 前記１つまたは複数の処理ユニットは、
    前記第１の履歴ＭＶＰバッファが満杯になると、先入れ先出し（ＦＩＦＯ）規則に従って前記第１の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと、
    前記第２の履歴ＭＶＰバッファが満杯になると、前記ＦＩＦＯ規則に従って前記第２の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと
    を行うようにさらに構成される、請求項２０に記載のデバイス。
25. 前記１つまたは複数の処理ユニットは、複数の異なるタイプの動きモデルの各々の動き情報を、前記第１の履歴ＭＶＰバッファを含む第１の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶するように構成され、
    前記１つまたは複数の処理ユニットは、前記複数の異なるタイプの動きモデルの各々の動き情報を、前記第２の履歴ＭＶＰバッファを含む第２の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶するように構成される、
    請求項２０に記載のデバイス。
26. 前記複数の異なるタイプの動きモデルは、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロック動きベクトル予測（ＭＶＰ）、または時間的動き予測のうちの１つまたは複数を備える、請求項２５に記載のデバイス。
27. 前記１つまたは複数の処理ユニットは、１つまたは複数の履歴ＭＶＰバッファ内の２つ以上のＭＶＰから合成ＭＶＰを生成するようにさらに構成される、請求項２０に記載のデバイス。
28. 前記２つ以上のＭＶＰは、コーディングされた動き情報、アフィン動きモデル動き情報、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ動き情報、時間的動き予測子動き情報、ＭＶＰ動き情報に基づく合成動きベクトル情報、空間ＭＶＰ動き情報、または時間ＭＶＰ動き情報のうちの２つ以上を備える異なる動き情報タイプを有する、請求項２７に記載のデバイス。
29. 前記ビデオデータを表示するように構成されたディスプレイをさらに備える、請求項２０に記載のデバイス。
30. 前記ビデオデータをキャプチャするように構成されたカメラをさらに備える、請求項２０に記載のデバイス。
31. 前記デバイスは、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、またはセットトップボックスのうちの１つまたは複数を備える、請求項２０に記載のデバイス。
32. 前記デバイスは、
    集積回路、
    マイクロプロセッサ、または
    ワイヤレス通信デバイス
    のうちの少なくとも１つを備える、請求項２０に記載のデバイス。
33. コンピュータ読取可能な記憶媒体であって、実行されると、プロセッサに、
    ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報をメモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶することと、
    前記メモリの第２の履歴ＭＶＰバッファをリセットすることと、
    前記第２の履歴ＭＶＰバッファをリセットした後に、前記ピクチャの第２のＣＴＵラインの動き情報を前記第２の履歴ＭＶＰバッファに記憶することと、ここで、前記第２のＣＴＵラインは、前記第１のＣＴＵラインとは異なる、
    を行わせる命令が記憶されている、コンピュータ読取可能な記憶媒体。
34. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファとは異なり、前記プロセッサに、前記第１のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、前記第１のＣＴＵラインの前記動き情報を記憶するためにビデオコーディングプロセスの第１のスレッドを実行させる命令を備え、前記プロセッサに、前記第２のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、前記第２のＣＴＵラインの前記動き情報を記憶するために前記ビデオコーディングプロセスの第２のスレッドを実行させる命令を備え、ここで、前記第１のスレッドは、前記第２のスレッドとは異なる、請求項３３に記載のコンピュータ読取可能な記憶媒体。
35. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファと同じであり、前記プロセッサに、前記第２の履歴ＭＶＰバッファをリセットさせる前記命令は、前記プロセッサに、波面並列処理中に前記第２のＣＴＵラインの開始を処理することに応答して前記第２の履歴ＭＶＰバッファをリセットさせる命令を備える、請求項３３に記載のコンピュータ読取可能な記憶媒体。
36. 前記プロセッサに、前記第１のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、前記第１の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第１の履歴ＭＶＰバッファに記憶させる命令を備え、
    前記プロセッサに、前記第２のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、前記第２の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第２の履歴ＭＶＰバッファに記憶させる命令を備える、
    請求項３３に記載のコンピュータ読取可能な記憶媒体。
37. 前記プロセッサに、
    前記第１の履歴ＭＶＰバッファが満杯になると、先入れ先出し（ＦＩＦＯ）規則に従って前記第１の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと、
    前記第２の履歴ＭＶＰバッファが満杯になると、前記ＦＩＦＯ規則に従って前記第２の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去することと
    を行わせる命令をさらに備える、請求項３３に記載のコンピュータ読取可能な記憶媒体。
38. 前記プロセッサに、前記第１のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、複数の異なるタイプの動きモデルの各々の動き情報を、前記第１の履歴ＭＶＰバッファを含む第１の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶させる命令を備え、
    前記プロセッサに、前記第２のＣＴＵラインの前記動き情報を記憶させる前記命令は、前記プロセッサに、前記複数の異なるタイプの動きモデルの各々の動き情報を、前記第２の履歴ＭＶＰバッファを含む第２の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶させる命令を備える、
    請求項３３に記載のコンピュータ読取可能な記憶媒体。
39. 前記複数の異なるタイプの動きモデルは、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロック動きベクトル予測（ＭＶＰ）、または時間的動き予測のうちの１つまたは複数を備える、請求項３８に記載のコンピュータ読取可能な記憶媒体。
40. 前記プロセッサに、１つまたは複数の履歴ＭＶＰバッファ内の２つ以上のＭＶＰから合成ＭＶＰを生成させる命令をさらに備える、請求項３３に記載のコンピュータ読取可能な記憶媒体。
41. 前記２つ以上のＭＶＰは、コーディングされた動き情報、アフィン動きモデル動き情報、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ動き情報、時間的動き予測子動き情報、ＭＶＰ動き情報に基づく合成動きベクトル情報、空間ＭＶＰ動き情報、または時間ＭＶＰ動き情報のうちの２つ以上を備える異なる動き情報タイプを有する、請求項４０に記載のコンピュータ読取可能な記憶媒体。
42. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    ピクチャの第１のコーディングツリー単位（ＣＴＵ）ラインの動き情報を前記メモリの第１の履歴動きベクトル予測子（ＭＶＰ）バッファに記憶するための手段と、
    前記メモリの第２の履歴ＭＶＰバッファをリセットするための手段と、
    前記第２の履歴ＭＶＰバッファをリセットした後に、前記ピクチャの第２のＣＴＵラインの動き情報を前記第２の履歴ＭＶＰバッファに記憶するための手段と、ここで、前記第２のＣＴＵラインは、前記第１のＣＴＵラインとは異なる、
    を備えるデバイス。
43. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファとは異なり、前記第１のＣＴＵラインの前記動き情報を記憶するための前記手段は、ビデオコーディングプロセスの第１のスレッドを備え、前記第２のＣＴＵラインの前記動き情報を記憶するための前記手段は、前記ビデオコーディングプロセスの第２のスレッドを備える、請求項４２に記載のデバイス。
44. 前記第２の履歴ＭＶＰバッファは、前記第１の履歴ＭＶＰバッファと同じであり、前記第２の履歴ＭＶＰバッファをリセットするための前記手段は、波面並列処理中に前記第２のＣＴＵラインの開始を処理することに応答して前記第２の履歴ＭＶＰバッファをリセットするための手段を備える、請求項４２に記載のデバイス。
45. 前記第１のＣＴＵラインの前記動き情報を記憶するための前記手段は、前記第１の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第１の履歴ＭＶＰバッファに記憶するための手段を備え、
    前記第２のＣＴＵラインの前記動き情報を記憶するための前記手段は、前記第２の履歴ＭＶＰバッファ内で一意の動きベクトルだけを前記第２の履歴ＭＶＰバッファに記憶するための手段を備える、
    請求項４２に記載のデバイス。
46. 前記第１の履歴ＭＶＰバッファが満杯になると、先入れ先出し（ＦＩＦＯ）規則に従って前記第１の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去するための手段と、
    前記第２の履歴ＭＶＰバッファが満杯になると、前記ＦＩＦＯ規則に従って前記第２の履歴ＭＶＰバッファから１つまたは複数の最も古い挿入された動きベクトルを除去するための手段と
    をさらに備える、請求項４２に記載のデバイス。
47. 前記第１のＣＴＵラインの前記動き情報を記憶するための前記手段は、複数の異なるタイプの動きモデルの各々の動き情報を、前記第１の履歴ＭＶＰバッファを含む第１の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶するための手段を備え、
    前記第２のＣＴＵラインの前記動き情報を記憶するための前記手段は、前記複数の異なるタイプの動きモデルの各々の動き情報を、前記第２の履歴ＭＶＰバッファを含む第２の複数の履歴ＭＶＰバッファのそれぞれの異なる履歴ＭＶＰバッファに記憶するための手段を備える、
    請求項４２に記載のデバイス。
48. 前記複数の異なるタイプの動きモデルは、アフィン動きモデル、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロック動きベクトル予測（ＭＶＰ）、または時間的動き予測のうちの１つまたは複数を備える、請求項４７に記載のデバイス。
49. １つまたは複数の履歴ＭＶＰバッファ内の２つ以上のＭＶＰから合成ＭＶＰを生成するための手段をさらに備える、請求項４２に記載のデバイス。
50. 前記２つ以上のＭＶＰは、コーディングされた動き情報、アフィン動きモデル動き情報、イントラブロックコピーモードの動き情報、局所照明補償の動き情報、サブブロックＭＶＰ動き情報、時間的動き予測子動き情報、ＭＶＰ動き情報に基づく合成動きベクトル情報、空間ＭＶＰ動き情報、または時間ＭＶＰ動き情報のうちの２つ以上を備える異なる動き情報タイプを有する、請求項４９に記載のデバイス。
    

Images