JP6378433B2 - イントラｂｃとインター予測の統合のためのａｍｖｐおよびマージ候補リスト導出 - Google Patents

Description

本出願は、2014年10月14日に出願された米国仮出願第62/063,857号、2014年10月17日に出願された米国仮出願第62/065,384号、2014年10月18日に出願された米国仮出願第62/065,643号、2015年1月29日に出願された米国仮出願第62/109,323号、および2015年1月30日に出願された米国仮出願第62/110,261号の利益を主張するものであり、それらの各々の内容全体が参照により本明細書に組み込まれる。

本開示はビデオコーディングに関し、より詳細には、他のビデオブロックに基づくビデオブロックの予測に関する。

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲のデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4、Part 10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、現在開発中の高効率ビデオコーディング(HEVC:High Efficiency Video Coding)規格、およびそのような規格の拡張によって定義された規格に記載されるものなどのビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および/または記憶し得る。

ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間(ピクチャ内)予測および/または時間(ピクチャ間)予測を実行する。ブロックベースのビデオコーディングのために、ビデオスライス(すなわち、ビデオフレーム、またはビデオフレームの一部)は、ビデオブロックに区分されてもよく、ビデオブロックはまた、ツリーブロック、コーディングユニット(CU:coding unit)、および/またはコーディングノードと呼ばれることがある。ピクチャのイントラコーディングされた(I)スライスの中のビデオブロックは、同じピクチャにおける隣接ブロックの中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコーディングされた(PまたはB)スライスの中のビデオブロックは、同じピクチャにおける隣接ブロックの中の参照サンプルに対する空間予測、または他の参照ピクチャの中の参照サンプルに対する時間予測を使用し得る。ピクチャは、フレームと呼ばれることがあり、参照ピクチャは、参照フレームと呼ばれることがある。

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

米国仮出願第62/000,437号

Brossら、「Editors' proposed corrections to HEVC version 1」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第13回会合、仁川、韓国、2013年4月 B. Liら、「Non-SCCE1: Unification of intra BC and inter modes」、ITU-T SG 16 WP 3およびISO/IEC JTC1/SC 29/WG 11のビデオコーディング共同研究部会(JCT-VC)、第18回会合、札幌、日本、2014年6月30日〜7月9日(JCTVC-R0100)

一般に、本開示では、ビデオコーディングにおける動きベクトルおよびブロックベクトル予測のための技法について説明する。本開示の技法は、ビデオデータの別のフレーム内の予測ブロックに対してコーディングされたビデオデータのブロックに対して、およびビデオデータの同じフレーム内の予測ブロックに対してコーディングされたビデオデータのブロック(たとえば、イントラブロックコピーモードに従ってコーディングされたブロック)に対して使用されてよい。

一例では、本開示は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信するステップであって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、受信するステップと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを復号するステップとを含むビデオデータを復号する方法を説明し、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

別の例では、本開示は、ビデオデータを復号するように構成された装置を説明し、装置はビデオデータを記憶するように構成されたメモリとビデオデコーダとを備え、ビデオデコーダは、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信することであって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、受信することと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを復号することとを行うように構成され、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

別の例では、本開示は、ビデオデータを符号化する方法を説明し、方法は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを符号化するステップであって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、符号化するステップと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを符号化するステップとを含み、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

別の例では、本開示は、ビデオデータを復号するように構成された装置を説明し、装置は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信するための手段であって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、受信するための手段と、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを復号するための手段とを含み、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

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

本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図である。 本開示に記載の技法を実装してもよい例示的なビデオエンコーダを示すブロック図である。 本開示に記載の技法を実装してもよい例示的なビデオデコーダを示すブロック図である。 マージモードおよびAMVPモードに対する空間隣接動きベクトル候補の例を示す図である。 イントラブロックコピー(IBC)モードの概念図である。 本開示の技法による例示的なビデオ符号化方法を示すフローチャートである。 本開示の技法による例示的なビデオ復号方法を示すフローチャートである。

最近開発された高効率ビデオコーディング(HEVC)規格を含む様々なビデオコーディング規格は、ビデオブロックに対する予測コーディングモードを含み、予測コーディングモードでは、現在コーディングされているブロックが、ビデオデータのすでにコーディングされたブロックに基づいて予測される。イントラ予測モードでは、現在のブロックは、現在のブロックと同じピクチャ内の、1つまたは複数の前にコーディングされた隣接ブロックに基づいて予測される一方で、インター予測モードでは、現在のブロックは、異なるピクチャ内のすでにコーディングされたブロックに基づいて予測される。インター予測モードでは、予測ブロックとして使用するために前にコーディングされたフレームのブロックを決定するプロセスは、動き推定と呼ばれることがある。動き推定は一般にビデオエンコーダによって実行され、予測ブロックを識別しておよび取り出すプロセスは、動き補償と呼ばれることがあり、動き補償はビデオエンコーダとビデオデコーダの両方によって実行される。前にコーディングされたフレーム内の予測ブロックは、動きベクトルによって識別され得る。動きベクトルは、今コーディングされたブロック内の点(たとえば、現在のブロックの左上の隅)に対する予測ブロックの位置を示し得る。

一般に、ビデオエンコーダは、複数のコーディングシナリオを使用してビデオデータをコーディングすること、および望ましいレート・歪みのトレードオフを作成するコーディングシナリオを識別することによって、ビデオデータのシーケンスをコーディングする方法を決定する。特定のビデオブロックに対するイントラ予測コーディングシナリオを試験するとき、ビデオエンコーダは、一般に、ピクセルの隣接行(たとえば、コーディングされているブロックの真上のピクセルの行)を試験し、ピクセルの隣接列(たとえば、コーディングされているブロックのすぐ左のピクセルの列)を試験する。対照的に、インター予測シナリオを試験するとき、ビデオエンコーダは、一般に、はるかに大きい探索エリア内で候補予測ブロックを識別し、探索エリアは、ビデオデータの前にコーディングされたフレーム内の任意の位置におけるビデオブロックに対応する。

テキスト、シンボルまたは繰返しパターンを含むビデオ画像など、いくつかのタイプのビデオ画像に対して、コーディング利得が、イントラ動き補償(IMC)モードを使用することによってイントラ予測およびインター予測に対して達成され得る。IMCモードは、イントラブロックコピー(IBC)モードと呼ばれることもある。本開示では、IMCモードおよびIBCモードという用語は置き換え可能である。IBCモードでは、ビデオエンコーダは、イントラ予測モードにおけるように、コーディングされているブロックと同じフレームまたはピクチャ内の予測ブロックを探索するが、ビデオエンコーダは、隣接する行および列だけではなく、より幅広い探索エリアを探索する。より幅広い探索エリアは、ビデオデータの現在のブロックをコーディングする前にコーディングされたフレームの任意のエリアを含んでよい。

IBCモードでは、ビデオエンコーダは、予測されているブロックと同じフレームまたはピクチャ内の予測ブロックを識別するために、動きベクトルまたはブロックベクトルとも呼ばれることもあるオフセットベクトルを決定してよい。ブロックベクトルは、たとえば、x成分およびy成分を含み、x成分は、予測されているビデオブロックと予測ブロックとの間の水平変位を識別し、y成分は、予測されているビデオブロックと予測ブロックとの間の垂直変位を識別する。ビデオエンコーダは、決定されたブロックベクトルを符号化ビットストリーム内で通知し、それによってビデオデコーダは、符号化ビットストリームを復号するときに、ビデオエンコーダによって選択された予測ブロックを識別し得る。一般に、IMCおよび/またはIBCのコーディングモードは任意のコーディングモードであり、ビデオデータのブロックは、ビデオデータの現在のブロックと同じフレームからのビデオの予測ブロックから予測され、ビデオデータの予測ブロックは、オフセットベクトル(たとえば、ブロックベクトルまたは動きベクトル)によって識別される。

本開示は、IBCモードとインター予測モードとを効率的に統合するための技法を導入する。提案される技法は、限定はしないが、動きベクトル/ブロックベクトル候補リスト導出を含む、動きベクトル/ブロックベクトル予測技法を主に対象とする。本開示の技法は、場合によっては高ビット深度(たとえば、8ビット以上)および4:4:4、4:2:2、4:2:0、4:0:0などの異なるクロマサンプリングフォーマットのサポートを含む、スクリーンコンテンツコーディングを利用するビデオコーディング技法を含む、インター予測モードおよびIBCモードを使用し得る任意のビデオコーディング技法とともに使用するために適用可能であり得る。

図1は、本開示の技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用する「ビデオコーダ」という用語は、総称的に、ビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、総称的に、ビデオ符号化またはビデオ復号のいずれかを指す場合がある。ビデオコーディングシステム10のビデオエンコーダ20およびビデオデコーダ30は、本開示で説明する様々な例による動きベクトルおよびブロックベクトル予測のための技法を実行するように構成され得るデバイスの例を表す。

図1に示すように、ビデオコーディングシステム10は、ソースデバイス12および宛先デバイス14を含む。ソースデバイス12は、符号化ビデオデータを生成する。したがって、ソースデバイス12は、ビデオ符号化デバイスまたはビデオ符号化装置と呼ばれることがある。宛先デバイス14は、ソースデバイス12によって生成された符号化ビデオデータを復号し得る。したがって、宛先デバイス14は、ビデオ復号デバイスまたはビデオ復号装置と呼ばれることがある。ソースデバイス12および宛先デバイス14は、ビデオコーディングデバイスまたはビデオコーディング装置の例であり得る。ソースデバイス12、宛先デバイス14、またはその両方の様々な実装形態は、1つまたは複数のプロセッサと、1つまたは複数のプロセッサに結合されたメモリとを含み得る。メモリは、本明細書で説明するように、限定はしないが、RAM、ROM、EEPROM、フラッシュメモリ、または所望のプログラムコードを命令またはデータ構造の形で記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を含み得る。

ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、モバイルコンピューティングデバイス、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、車載コンピュータなどを含む、広範囲のデバイスを備え得る。

宛先デバイス14は、符号化ビデオデータをソースデバイス12からリンク16を介して受信し得る。リンク16は、符号化ビデオデータをソースデバイス12から宛先デバイス14に移動させることが可能な1つまたは複数の媒体またはデバイスを備え得る。一例では、リンク16は、ソースデバイス12がリアルタイムで符号化ビデオデータを宛先デバイス14に直接送信することを可能にする、1つまたは複数の通信媒体を備え得る。この例では、ソースデバイス12は、ワイヤレス通信プロトコルなどの通信規格に従って符号化ビデオデータを変調し得、変調されたビデオデータを宛先デバイス14に送信し得る。1つまたは
複数の通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、ワイヤレスおよび/またはワイヤードの通信媒体を含み得る。1つまたは複数の通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはグローバルネットワーク(たとえば、インターネット)などの、パケットベースのネットワークの一部を形成し得る。1つまたは複数の通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にする他の機器を含み得る。

別の例では、符号化されたデータは、出力インターフェース22から記憶デバイス17に出力されてもよい。同様に、符号化されたデータは、入力インターフェース28によって記憶デバイス17からアクセスされてもよい。ストレージデバイス17は、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または、符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの、様々な分散されたまたは局所的にアクセスされるデータ記憶媒体のうちのいずれかを含んでもよい。

さらなる例では、ストレージデバイス17は、ソースデバイス12によって生成された符号化ビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応してもよい。宛先デバイス14は、ストリーミングまたはダウンロードを介してストレージデバイス17から記憶されたビデオデータにアクセスしてもよい。ファイルサーバは、符号化ビデオデータを記憶し、宛先デバイス14にその符号化ビデオデータを送信することが可能な任意のタイプのサーバであってもよい。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS:network attached storage)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準的なデータ接続を介して符号化ビデオデータにアクセスしてもよい。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含んでもよい。ストレージデバイス17からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであってもよい。

ビデオコーディングにおける動きベクトルおよびブロックベクトル予測のための本開示の技法は、ワイヤレスの用途またはセッティングに限定されない。技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえば、インターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのビデオデータの符号化、データ記憶媒体に記憶されたビデオデータの復号、または他の用途などの様々なマルチメディア用途をサポートするビデオコーディングに適用され得る。いくつかの例では、ビデオコーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオ放送、および/またはビデオテレフォニーなどの用途をサポートするために、片方向または双方向のビデオ送信をサポートするように構成され得る。

図1に示すビデオコーディングシステム10は一例にすぎず、本開示の技法は、符号化デバイスと復号デバイスとの間に必ずしもデータ通信を含まないビデオコーディングのセッティング(たとえば、ビデオ符号化またはビデオ復号)に適用され得る。他の例では、データは、ローカルメモリから、ネットワークを介してストリーミングされて、または類似のやり方で取り出される。ビデオ符号化デバイスがデータを符号化するとともにメモリに記憶してよく、かつ/またはビデオ復号デバイスがメモリからデータを取り出すとともに復号してもよい。多くの例では、互いに通信しないが、単にデータを符号化するとともにメモリに記憶し、かつ/またはメモリからデータを取り出すとともに復号するデバイスによって、符号化および復号が実行される。

図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。いくつかの例では、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ビデオソース18は、ビデオキャプチャデバイス、たとえば、ビデオカメラ、前にキャプチャされたビデオデータを含むビデオアーカイブ、ビデオデータをビデオコンテンツプロバイダから受信するためのビデオフィードインターフェース、および/もしくはビデオデータを生成するためのコンピュータグラフィックスシステム、またはビデオデータのそのようなソースの組合せを含み得る。

ビデオエンコーダ20は、ビデオソース18からのビデオデータを符号化し得る。いくつかの例では、ソースデバイス12は、符号化ビデオデータを宛先デバイス14に出力インターフェース22を介して直接送信する。他の例では、復号および/または再生のために宛先デバイス14によって後でアクセスできるように、符号化ビデオデータはまた、記憶デバイス17に記憶され得る。

図1の例では、宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。いくつかの例では、入力インターフェース28は、受信機および/またはモデムを含む。入力インターフェース28は、リンク16を介して、および/または記憶デバイス17から、符号化ビデオデータを受信し得る。ディスプレイデバイス32は、宛先デバイス14と一体化されてよく、または宛先デバイス14の外部にあってもよい。概して、ディスプレイデバイス32は復号ビデオデータを表示する。ディスプレイデバイス32は、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの様々なディスプレイデバイスを備え得る。

図1には示していないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、各々、オーディオエンコーダおよびデコーダと一体化されてもよく、共通データストリームまたは別々のデータストリームにおけるオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニットまたは他のハードウェアおよびソフトウェアを含んでもよい。適用可能な場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。

ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ハードウェア、またはそれらの任意の組合せなどの、様々な適当な回路のいずれかとして実装され得る。技法が部分的にソフトウェアで実装される場合、本開示の技法を実行するために、デバイスは、ソフトウェアのための命令を適切な非一時的コンピュータ可読記憶媒体に記憶し得、1つまたは複数のプロセッサを使用するハードウェアにおいて命令を実行し得る。前述のもののいずれか(ハードウェア、ソフトウェア、ハードウェアとソフトウェアの組合せなどを含む)は、1つまたは複数のプロセッサであると見なされてよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、それらのいずれかが、組み合わされたエンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中で一体化されてよい。

本開示は、概して、ある種の情報をビデオデコーダ30などの別のデバイスへ「シグナリングする」または「送信する」ビデオエンコーダ20に言及することがある。「シグナリングすること」または「送信すること」という用語は、概して、シンタックス要素、および/または圧縮ビデオデータを復号するために使用される他のデータの通信を指すことがある。そのような通信は、リアルタイムで、またはほぼリアルタイムで発生し得る。代替的に、そのような通信は、符号化の時点において符号化ビットストリームの中のシンタックス要素をコンピュータ可読記憶媒体に記憶し、次いで、シンタックス要素が、この媒体に記憶された後の任意の時点において復号デバイスによって取り出され得るときに発生し得るような、時間の範囲にわたって発生することもある。

ビデオエンコーダ20およびビデオデコーダ30は、高効率ビデオコーディング(HEVC)などのビデオ圧縮規格に従って動作してもよく、HEVC試験モデル(HM)に準拠してもよい。「HEVCワーキングドラフト10」または「HEVC WD10」と呼ばれるHEVC規格のワーキングドラフトは、Brossら、「Editors' proposed corrections to HEVC version 1」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第13回会合、仁川、韓国、2013年4月において記載されている。本開示で説明する技法はまた、現在開発中であるHEVC規格の拡張に従って動作し得る。代替または追加として、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、アドバンストビデオコーディング(AVC)と呼ばれるITU-T H.264規格、またはそのような規格の拡張など、他の独自規格または工業規格に従って動作してもよい。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例は、そのスケーラブルビデオコーディング(SVC)拡張およびマルチビュービデオコーディング(MVC)拡張を含む、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 VisualおよびITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)を含む。

一例では、ビデオデコーダ30は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信することであって、ビデオデータの第1のブロックはビデオデータの第2のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックは動きベクトルによって識別される、受信することと、ビデオデータの第1のフレーム内のビデオデータの第2のブロックを受信することであって、ビデオデータの第2のブロックはビデオデータの第1のフレーム内の第2の予測ブロックに対して符号化され、第2の予測ブロックはブロックベクトルによって識別される、受信することと、動きベクトル予測プロセスおよび動きベクトル候補リストを使用して動きベクトルを復号することと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるのと同じ動きベクトル候補リストを使用してブロックベクトルを復号することとを行うように構成されてよい。

別の例では、ビデオエンコーダ20は、ビデオデータの第2のフレーム内の第1の予測ブロックに対してビデオデータの第1のフレーム内のビデオデータの第1のブロックを符号化することであって、第1の予測ブロックは動きベクトルによって識別される、符号化することと、ビデオデータの第1のフレーム内の第2の予測ブロックに対してビデオデータの第1のフレーム内のビデオデータの第2のブロックを符号化することであって、第2の予測ブロックはブロックベクトルによって識別される、符号化することと、動きベクトル予測プロセスおよび動きベクトル候補リストを使用して動きベクトルを符号化することと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるのと同じ動きベクトル候補リストを使用してブロックベクトルを符号化することとを行うように構成されてよい。

最近、新しいビデオコーディング規格、すなわち高効率ビデオコーディング(HEVC)の設計は、ITU-Tビデオコーディング専門家グループ(VCEG)およびISO/IEC動画専門家グループ(MPEG)のビデオコーディング共同研究部会(JCT-VC)によって確定された。以下でHEVC WDと呼ばれるHEVCドラフト仕様の一バージョンは、http://phenix.int-evry.fr/jct/doc_end_user/documents/15_Geneva/wg11/JCTVC-O1003-v2.zipから入手可能である。HEVCに対する範囲拡張、すなわちHEVC-RExtが、同じく、JCT-VCによって開発中である。以下RExt WD7と呼ばれる、範囲拡張の最近のワーキングドラフト(WD)が、http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q1005-v4.zipから入手可能である。

JCTVC-Q1003において説明されるHEVC仕様テキストは、しばしば、HEVCバージョン1と呼ばれる。範囲拡張仕様は、HEVCのバージョン2となる。しかしながら、大体において、提案される技法、たとえば動きベクトル予測に関する限り、HEVCバージョン1と範囲拡張仕様とは、技術的に同様である。したがって、本開示がHEVCバージョン1に基づく技法に言及するときはいつでも、同じ技法が範囲拡張仕様にも適用されてよく、本技法が任意のHEVCバージョン1のモジュールの再使用に言及するときはいつでも、本開示はまた、(たとえば、同じサブクローズを有する)HEVC範囲拡張モジュールの再使用に言及する。

最近、動きを伴うテキストおよびグラフィックスなどのスクリーンコンテンツ材料に対する新しいコーディングツールの調査が要求され、スクリーンコンテンツに対するコーディング効率を改善する技術が提案されている。コーディング効率における著しい改善が、新奇な専用コーディングツールを用いるスクリーンコンテンツの特性を利用することによって得ることができるという証拠があるので、スクリーンコンテンツコーディング(SCC)のための特定のツールを含む高効率ビデオコーディング(HEVC)規格のさらなる拡張をできる限り発展させる目標に対する提案募集(CfP)が発行されている。この募集に応答して提案を提出するように、会社および機構が請願されている。このCfPの使用事例および要件が、MPEG文書N14174に記載されている。第17回JCT-VC会合中に、SCC試験モデル(SCM)が確立される。SCCの最新のワーキングドラフト(WD)は、http://phenix.int-evry.fr/jct/doc_end_user/documents/18_Sapporo/wg11/JCTVC-R1005-v3.zipから利用可能である。

JCT-VCはHEVC規格を開発した。HEVCの規格化の取組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。HMは、たとえば、ITU-T H.264/AVCによる既存のデバイスと比較して、ビデオコーディングデバイスのいくつかの追加の能力を想定する。たとえば、H.264は、9個のイントラ予測符号化モードを提供する一方で、HMは、33個ものイントラ予測符号化モードを提供し得る。

一般に、HMの作業中のモデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット(LCU)に分割されてもよいことを記載している。ツリーブロックは、H.264規格のマクロブロックと同様の目的を有する。スライスは、コーディング順にいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分されてもよい。各ツリーブロックは、4分木に従ってコーディングユニット(CU)に***されてもよい。たとえば、ツリーブロックは、4分木のルートノードとして、4つの子ノードに***されてもよく、各子ノードは、次に、親ノードになり、別の4つの子ノードに***されてもよい。最後の、***されていない子ノードは、4分木のリーフノードとして、コーディングノード、すなわちコーディングされたビデオブロックを備える。コーディングされたビットストリームに関連付けられたシンタックスデータは、ツリーブロックが***されてもよい最大回数を定義してもよく、また、コーディングノードの最小サイズを定義してもよい。

CUは、HEVCにおける基本コーディングユニットとして定義される。HEVCでは、フレームは、最初に、CTU(コーディングツリーユニット)と呼ばれるいくつかの正方形ユニットに分割される。CTUサイズは2N×2Nであるとする。各CTUは4つのN×N CUに分割することができ、各CUは4つの(N/2)×(N/2)ユニットにさらに分割することができる。ブロック分割は、分割が所定の最大分割レベルまたは可能な最小CUサイズに到達するまで、同じ方法で継続することができる。CTUのサイズ、CTUをCUにさらに分割するレベル、およびCUの最小サイズは、符号化構成の中で定義され、ビデオデコーダ30に送信されることになるか、またはビデオエンコーダ20とビデオデコーダ30の両方に知られてよい。

CUは、コーディングノードと、コーディングノードに関連付けられた予測ユニット(PU)および変換ユニット(TU)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。CUのサイズは、8×8ピクセルから、最大64×64ピクセルまたはそれ以上のツリーブロックのサイズまでの範囲であってもよい。各CUは、1つまたは複数のPUと1つまたは複数のTUとを含んでもよい。CUに関連付けられたシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述してもよい。区分モードは、CUがスキップもしくは直接モードで符号化されているのか、イントラ予測モード符号化されているのか、またはインター予測モードで符号化されているのかの間で異なってもよい。PUは、形状が非正方形であるように区分されてもよい。CUに関連付けられたシンタックスデータはまた、たとえば、4分木に従った1つまたは複数のTUへのCUの区分を記述してもよい。TUは、形状において正方形または非正方形であることができる。

HEVC規格は、TUに従う変換を可能にし、それは、異なるCUのために異なってもよい。TUは、典型的には、区分されたLCUのために定義された所与のCU内のPUのサイズに基づいてサイズが決められるが、これは、必ずしもそうでないことがある。TUは通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用して、より小さいユニットに細分されてもよい。RQTのリーフノードは、変換ユニット(TU)と呼ばれることがある。TUに関連付けられたピクセル差分値は、量子化されてもよい変換係数を生成するために変換されてもよい。

一般に、PUは、予測プロセスに関連するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUは、PUのイントラ予測モードを記述するデータを含み得る。別の例として、PUがインターモード符号化されるとき、PUは、PUの動きベクトルを定義するデータを含み得る。PUのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、4分の1ピクセル精度もしくは8分の1ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルのための参照ピクチャリスト(たとえば、リスト0、リスト1、もしくはリストC)を記述してもよい。

一般に、TUは、変換および量子化プロセスのために使用される。1つまたは複数のPUを有する所与のCUはまた、1つまたは複数の変換ユニット(TU)を含んでもよい。予測に続いて、ビデオエンコーダ20は、PUに対応する残差値を計算してもよい。残差値は、ピクセル差分値を備え、ピクセル差分値は、エントロピーコーディングのためのシリアライズ化された変換係数を生成するために、変換係数に変換され、量子化され、TUを使用して走査されてもよい。本開示は、典型的には、CUのコーディングノードを指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合には、本開示はまた、コーディングノードとPUおよびTUとを含むツリーブロック、すなわち、LCUまたはCUを指すために「ビデオブロック」という用語を使用することがある。

ビデオシーケンスは、典型的には、一連のビデオフレームまたはピクチャを含む。ピクチャグループ(GOP)は一般に、一連の1つまたは複数のビデオピクチャを備える。GOPは、GOPに含まれるピクチャの数を記述する構文データを、GOPのヘッダ、ピクチャのうちの1つまたは複数のヘッダ、または他の場所に含んでもよい。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライス構文データを含んでもよい。ビデオエンコーダ20は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロック上で動作する。ビデオブロックは、CU内のコーディングノードに対応する場合がある。ビデオブロックは固定サイズまたは可変サイズを有してもよく、指定されたコーディング規格に従ってサイズが異なってもよい。

一例として、HMは、様々なPUサイズにおける予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズにおけるイントラ予測と、2N×2N、2N×N、N×2N、またはN×Nの対称PUサイズにおけるインター予測とをサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズにおけるインター予測のための非対称区分をサポートする。非対称区分では、CUの一方の方向は、区分されず、他方の方向は、25%および75%に区分される。25%区分に対応するCUの部分は、「上」、「下」、「左」、または「右」の指示が続く「n」によって示される。したがって、たとえば、「2N×nU」は、上に2N×0.5NのPUおよび下に2N×1.5NのPUで水平に区分された2N×2NのCUを指す。

本開示では、「NxN」および「N掛けるN」は、垂直方向および水平方向のサイズに関するビデオブロックのピクセルのサイズ、たとえば、16×16ピクセル、または16掛ける16ピクセルを指すために、交換可能に使用されてもよい。一般に、16×16ブロックは、垂直方向に16ピクセル(y=16)と水平方向に16ピクセル(x=16)とを有することになる。同様に、N×Nブロックは、一般に、垂直方向にNピクセルと水平方向にNピクセルとを有し、ここでNは、負ではない整数値を表す。ブロック内のピクセルは、行および列に配置されてもよい。さらに、ブロックは、必ずしも水平方向で垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックは、N×Mピクセルを備えてもよく、ここでMは、Nと必ずしも等しくない。

したがって、HEVCによれば、CUは、1つもしくは複数の予測ユニット(PU)、および/または、1つもしくは複数の変換ユニット(TU)を含み得る。本開示はまた、CU、PU、またはTUのいずれかを指すために「ブロック」、「区分」または「部分」という用語を使用する。概して、「部分」は、ビデオフレームの任意のサブセットを指すことがある。さらに、本開示は、典型的には、CUのコーディングノードを指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合には、本開示はまた、ツリーブロック、すなわち、LCU、またはコーディングノードとPUとTUとを含むCUを指すために、「ビデオブロック」という用語を使用し得る。したがって、ビデオブロックは、CU内のコーディングノードに対応してよく、ビデオブロックは、固定サイズまたは可変サイズを有してよく、指定されたコーディング規格に従ってサイズが異なってもよい。

クロマフォーマットとも呼ばれることがあるビデオサンプリングフォーマットは、CU内に含まれるルーマサンプルの数に対する、CU内に含まれるクロマサンプルの数を定義してよい。クロマ成分に対するビデオサンプリングフォーマットに応じて、U成分およびV成分の、サンプル数に関するサイズは、Y成分のサイズと同じサイズであってよく、または異なるサイズであってもよい。HEVC規格では、構文要素chroma_format_idcの値は、ルーマ成分に対する、クロマ成分の異なるサンプリングフォーマットを示すために定義される。HEVCでは、chroma_format_idc構文要素は、シーケンスパラメータセット(SPS)の中で通知される。Table 1(表1)は、chroma_format_idcの値と、関連するクロマフォーマットの値との間の関係を示す。

Table 1(表1)では、変数SubWidthCおよびSubHeightCは、ルーマ成分に対するサンプル数と各クロマ成分に対するサンプル数との間の水平および垂直のサンプリングレート比を示すために使用され得る。Table 1(表1)で説明するクロマフォーマットでは、2つのクロマ成分は、同じサンプリングレートを有する。したがって、4:2:0サンプリングでは、2つのクロマアレイの各々は、ルーマアレイの半分の高さと半分の幅とを有する一方で、4:2:2サンプリングでは、2つのクロマアレイの各々は、ルーマアレイと同じ高さとルーマアレイの半分の幅とを有する。4:4:4サンプリングでは、2つのクロマアレイの各々は、ルーマアレイと同じ高さと幅とを有してよく、またはいくつかの例では、3色の平面は、すべて、モノクロームサンプルされたピクチャとして別々に処理されてよい。

Table 1(表1)の例では、4:2:0フォーマットに対して、ルーマ成分のサンプリングレートは、水平と垂直の両方向に対してクロマ成分のサンプリングレートの2倍である。その結果、4:2:0フォーマットに従ってフォーマットされたコーディングユニットに対して、ルーマ成分に対するサンプルのアレイの幅および高さは、クロマ成分に対するサンプルの各アレイの幅および高さの2倍である。同様に、4:2:2フォーマットに従ってフォーマットされたコーディングユニットに対して、ルーマ成分に対するサンプルのアレイの幅は、各クロマ成分に対するサンプルのアレイの幅の2倍であるが、ルーマ成分に対するサンプルのアレイの高さは、各クロマ成分に対するサンプルのアレイの高さに等しい。4:4:4フォーマットに従ってフォーマットされたコーディングユニットに対して、ルーマ成分に対するサンプルのアレイは、各クロマ成分に対するサンプルのアレイと同じ幅および高さを有する。

YUV色空間に加えて、ビデオデータは、RGB色空間に従って定義され得ることに留意されたい。このようにして、本明細書で説明するクロマフォーマットは、YUVまたはRGBの色空間のいずれかに適用されてよい。RGBクロマフォーマットは、一般に、赤サンプルの数、緑サンプルの数および青サンプルの数が等しいようにサンプリングされる。したがって、本明細書で使用する「4:4:4クロマフォーマット」という用語は、YUV色空間またはRGB色空間のいずれかを指すことがあり、サンプルの数は、すべての色成分に対して等しい。

CUのPUを使用するイントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ20は、CUのTUのための残差データを計算してもよい。PUは、空間領域(ピクセル領域とも呼ばれる)におけるピクセルデータを備えてもよく、TUは、残差ビデオデータへの変換、たとえば、離散コサイン変換(DCT:discrete cosine transform)、整数変換、ウェーブレット変換、または概念的に同様の変換に続いて、変換領域における係数を備えてもよい。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差に対応してもよい。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、CUのための変換係数を生成するためにTUを変換してもよい。

変換係数を生成するための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行してもよい。量子化は、一般に、係数を表すために使用されるデータの量をできる限り低減するために変換係数が量子化され、さらなる圧縮が行われるプロセスを指す。量子化プロセスは、係数の一部またはすべてに関連するビット深度を低減してもよい。たとえば、nビット値は、量子化の間にmビット値に切り捨てられてもよく、ここでnは、mよりも大きい。

いくつかの例では、ビデオエンコーダ20は、エントロピー符号化されることが可能なシリアル化ベクトルを生成するために、量子化された変換係数を走査するために事前定義された走査順を利用してもよい。他の例では、ビデオエンコーダ20は、適応走査を実行してもよい。量子化された変換係数を走査して1次元ベクトルを形成した後、ビデオエンコーダ20は、たとえば、コンテキスト適応型バイナリ算術コーディング(CABAC)または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化してもよい。ビデオエンコーダ20はまた、ビデオデータを復号する上でビデオデコーダ30によって使用するための符号化されたビデオデータに関連付けられた構文要素をエントロピー符号化してもよい。

CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルにコンテキストモデル内のコンテキストを割り当ててもよい。コンテキストは、たとえば、シンボルの隣接値が非ゼロであるかどうかに関連してもよい。

図2は、本開示で説明する技術を実施してもよい例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は、ビデオを後処理エンティティ27に出力するように構成されてよい。後処理エンティティ27は、メディアアウェアネットワーク要素(MANE)、またはビデオエンコーダ20からの符号化されたビデオデータを処理してよいスプライシング/エディティングデバイスなど、ビデオエンティティの一例を表すように意図されている。いくつかの例では、後処理エンティティ27は、ネットワークエンティティの一例であってよい。いくつかのビデオ符号化システムでは、後処理エンティティ27およびビデオエンコーダ20は、別々のデバイスの部分であってよいが、他の例では、後処理エンティティ27に関して説明される機能は、ビデオエンコーダ20を備える同じデバイスによって実行されてもよい。いくつかの例では、後処理エンティティ27は、図1の記憶デバイス17の一例である。

ビデオエンコーダ20は、本開示の技法による、ビデオスライス内のビデオブロックのイントラコーディング、インターコーディング、およびIBCコーディングを実行してもよい。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間的冗長性を低減または除去するために時間的予測に依存する。イントラモード(Iモード)は、いくつかの空間ベースの圧縮モードのうちのいずれかを指してもよい。片方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのうちのいずれかを指してもよい。以下でより詳細に説明するように、IBCコーディングモードは、ビデオデータのフレームから空間冗長性を除去し得るが、従来のイントラモードとは違って、IBCコーディングコードは、現在コーディングされているブロックと同じフレーム内のより大きい探索エリア内で予測ブロックの位置を特定して、イントラ予測コーディングモードに依存するのではなく、ブロックベクトルを有する予測ブロックを参照するために使用されてよい。

図2の例では、ビデオエンコーダ20は、ビデオデータメモリ33と、区分ユニット35と、予測処理ユニット41と、フィルタユニット63と、復号ピクチャバッファ(DPB)64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。予測処理ユニット41は、動き推定ユニット42と、動き補償ユニット44と、イントラ予測処理ユニット46とを含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換処理ユニット60と、加算器62とを含む。フィルタユニット63は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなど、1つまたは複数のループフィルタを表すことを意図している。フィルタユニット63は、ループフィルタであるように図2に示されているが、他の構成では、フィルタユニット63は、ポストループフィルタとして実装されてもよい。

ビデオデータメモリ33は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶してもよい。ビデオデータメモリ33内に記憶されるビデオデータは、たとえば、ビデオソース18から取得されてもよい。DPB64は、たとえば、イントラコーディングモード、インターコーディングモードまたはIBCコーディングモードにおいて、ビデオエンコーダ20によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであってもよい。ビデオデータメモリ33およびDPB64は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ33およびDPB64は、同じメモリデバイスまたは別個のメモリデバイスによって備えられてよい。様々な例では、ビデオデータメモリ33は、ビデオエンコーダ20の他の構成要素とともにオンチップであってもよく、または、これらの構成要素に対してオフチップであってもよい。

図2に示すように、ビデオエンコーダ20はビデオデータを受信し、ビデオデータをビデオデータメモリ33内に記憶する。区分ユニット35は、データをビデオブロックに区分する。この区分はまた、スライス、タイル、または他のより大きいユニットへの区分、ならびに、たとえば、LCUおよびCUの4分木構造によるビデオブロック区分を含んでもよい。ビデオエンコーダ20は、全体的に、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに(および、あるいは、タイルと呼ばれるビデオブロックのセットに)分割されてもよい。予測処理ユニット41は、エラー結果(たとえば、コーディングレートおよび歪のレベル)に基づいて、現在のビデオブロックのための、複数のイントラコーディングモードのうちの1つ、複数のインターコーディングモードのうちの1つ、または複数のIBCコーディングモードのうちの1つなど、複数の可能なコーディングモードのうちの1つを選択してもよい。予測処理ユニット41は、残差ブロックデータを生成するために加算器50に、および、参照ピクチャとして使用するための符号化ブロックを再構成するために加算器62に、得られたイントラコーディングされたブロック、インターコーディングされたブロック、またはIBCコーディングされたブロックを提供してもよい。

予測処理ユニット41内のイントラ予測処理ユニット46は、空間的圧縮を提供するために、コーディングされるべき現在のブロックと同じフレームまたはスライス内の1つまたは複数の隣接ブロックに対する現在のビデオブロックのイントラ予測コーディングを実行してもよい。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44は、時間的圧縮を提供するために、1つまたは複数の参照ピクチャ内の1つまたは複数の予測ブロックに対する現在のビデオブロックのインター予測コーディングを実行してよい。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44はまた、空間的圧縮を提供するために、同じピクチャ内の1つまたは複数の予測ブロックに対する現在のビデオブロックのIBCコーディングを実行してよい。

この点について、IBC予測コーディングおよびインター予測コーディングは、統合されているものと見なしてよい。すなわち、インター予測コーディングとIBCコーディングの両方は、別の、前にコーディングされたブロックから現在のブロックを予測する。前にコーディングされたブロックの位置は、動きベクトルまたはブロックベクトルによって識別され得る。概して、動きベクトルは、(たとえば、インター予測における)現在コーディングされているブロックのフレームとは異なるフレーム内の、前にコーディングされたブロックを識別するために使用されてよい。ブロックベクトルは、(たとえば、IBCモードにおける)現在コーディングされているブロックのフレームと同じフレーム内の、前にコーディングされたブロックを識別するために使用されてよい。ブロックベクトルはフレーム内の特定の物体の動きとは無関係であるにも関わらず、ブロックベクトルは、動きベクトルとも呼ばれることがあることを理解されたい。

動き推定ユニット42および動き補償ユニット44を使用してIBCを実行するために、現在のフレーム(たとえば、現在コーディングされているブロックのフレーム)の参照フレームインデックスが、参照ピクチャリストに追加されてよい。このようにして、動き推定ユニット42は、現在コーディングされているブロックと同じフレームだけではなく、現在コーディングされているブロックと異なるフレーム内の予測ブロックを探索することができる。予測ブロックが現在コーディングされているブロックと同じ参照フレームインデックスを有する場合、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCモードを使用して現在のブロックをコーディングしたものと見なされてよい。このようにして、ビデオエンコーダ20は、IBCモードを示す別個の構文要素を通知する必要はなく、IBCモードは、予測ブロックの参照フレームインデックスから推測され得る。

動き推定ユニット42は、ビデオシーケンスのための所定のパターンに従ってビデオスライスのためのインター予測モードまたはIBCモードを決定するように構成されてもよい。所定のパターンは、PスライスまたはBスライスとしてシーケンス内のビデオスライスを指定してもよい。動き推定ユニット42および動き補償ユニット44は、高度に統合されてもよいが、概念的な目的のために別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックに関する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示してもよい。IBCコーディングの場合、IBC内のブロックベクトルと呼ばれることがある動きベクトルは、現在のビデオフレーム内の予測ブロックに対して現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示すことができる。

予測ブロックは、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定されてもよいピクセル差分の観点で、コーディングされるべきビデオブロックのPUと密接に整合することが見出されたブロックである。いくつかの例では、ビデオエンコーダ20は、復号済みピクチャバッファ64内に記憶された参照ピクチャのサブ整数ピクセル位置に関する値を計算してもよい。たとえば、ビデオエンコーダ20は、参照ピクチャの4分の1ピクセル位置の値、8分の1ピクセル位置の値、または他の分数ピクセル位置の値を補間してもよい。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力してもよい。

動き推定ユニット42は、参照ピクチャの予測ブロックの位置とPUの位置とを比較することによって、インターコーディングされたスライス内のビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、その各々が復号済みピクチャバッファ64内に記憶された1つまたは複数の参照ピクチャを識別する、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されてもよい。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44に送信する。

本開示のいくつかの技法によれば、IBCモードを使用してビデオブロックをコーディングするとき、動き推定ユニット42は、ビデオブロックのルーマ成分に対する動きベクトルまたはブロックベクトルを決定し、ルーマ成分に対するブロックベクトルに基づいてビデオブロックのクロマ成分に対するブロックベクトルを決定することができる。別の例では、IBCモードを使用してビデオブロックをコーディングするとき、動き推定ユニット42は、ビデオブロックのクロマ成分に対する動きベクトルまたはブロックベクトルを決定し、クロマ成分に対するブロックベクトルに基づいてビデオブロックのルーマ成分に対するオフセットベクトルを決定することができる。したがって、ビデオエンコーダ20は、1つだけのブロックベクトルをビットストリーム内で通知し、そのブロックベクトルから、ビデオブロックのクロマ成分とルーマ成分の両方に対するブロックベクトルが決定され得る。

動き補償ユニット44によって実行される動き補償は、あるいはサブピクセル精度で補間を行う動き推定によって決定された動きベクトル/ブロックベクトルに基づいて、予測ブロックを取得または生成することを伴ってもよい。補間フィルタ処理が、知られているピクセルサンプルから追加のピクセルサンプルを生成することができ、このようにして潜在的に、ビデオブロックをコーディングするために使用され得る候補予測ブロックの数が増加する。現在のビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つにおいて動きベクトルが指す予測ブロックの位置を特定してもよい。IBCコーディングの場合、ブロックベクトルは、コーディングされているピクチャを指すことができる。上記のように、現在のピクチャはまた、参照ピクチャリスト内に含まれてよい。ビデオエンコーダ20は、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。ピクセル差分値は、ブロックのための残差データを形成し、輝度差成分と彩度差成分の両方を含んでもよい。加算器50は、この減算演算を実行する1つまたは複数の成分を表す。動き補償ユニット44はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用するための、ビデオブロックおよびビデオスライスに関連付けられた構文要素を生成してもよい。

いくつかの例では、予測処理ユニット41は、動きベクトル予測および/またはブロックベクトル予測を実行してもよい。すなわち、ビデオデータのブロックを符号化するために使用される動きベクトルおよび/またはブロックベクトルの全体を通知するのではなく、動きベクトルおよび/またはブロックベクトルは、隣接ブロックの動きベクトルおよび/またはブロックベクトルに対して予測されてよい。以下でより詳細に説明するように、本開示は、インター予測モードとIBCコーディングモードの両方に対して動きベクトル予測およびブロックベクトル予測のための技法を説明する。

イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測およびIBCの代替として、現在のブロック上でイントラ予測を実行してもよい。具体的には、イントラ予測処理ユニット46は、現在のブロックを符号化するために使用するイントラ予測モードを決定してもよい。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在のブロックを符号化してよく、イントラ予測処理ユニット46は、試験されたモードから、使用するための適切なイントラ予測モードを選択することができる。たとえば、イントラ予測処理ユニット46は、様々な試験されたイントラ予測モードに対してレート歪み分析を使用してレート歪み値を計算し、試験されたモードの中から最良のレート歪み特性を有するイントラ予測モードを選択してもよい。レート歪み分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化される、符号化されていない元のブロックとの間の歪み(すなわち、エラー)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット46は、どのイントラ予測モードがブロックのための最良のレート歪み値を示すのかを決定するために、様々な符号化ブロックに関する歪みおよびレートから比を計算してもよい。

いずれの場合でも、ブロックのためのイントラ予測処理モードを選択した後、イントラ予測ユニット46は、エントロピー符号化ユニット56にブロックのための選択されたイントラ予測モードを示す情報を提供してもよい。エントロピー符号化ユニット56は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化してもよい。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)を含んでもよい、送信されたビットストリーム構成データ内に、コンテキストの各々のために使用する、様々なブロックのための符号化コンテキストの定義と、最もあり得るイントラ予測モードの指示と、イントラ予測モードインデックステーブルと、変更されたイントラ予測モードインデックステーブルとを含んでもよい。

予測処理ユニット41が、インター予測、イントラ予測、またはIBCのいずれかによって現在のビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ20は、現在のビデオブロックから予測ブロックを減算することによって、残差ビデオブロックを形成する。残差ブロック内の残差ビデオデータは、1つまたは複数のTU内に含まれ、変換処理ユニット52に適用されてもよい。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット52は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換してもよい。

変換処理ユニット52は、結果として生じた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行してもよい。

量子化に続いて、エントロピー符号化ユニット56は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット56は、コンテキスト適応可変長コーディング(CAVLC)、コンテキスト適応2値算術コーディング(CABAC)、構文ベースコンテキスト適応2値算術コーディング(SBAC)、確率インターバル区分エントロピー(PIPE)コーディング、または別のエントロピー符号化方法もしくは技術を実行してもよい。エントロピー符号化ユニット56によるエントロピー符号化に続いて、符号化ビットストリームは、ビデオデコーダ30に送信されてもよく、または、ビデオデコーダ30による後の送信または検索のためにアーカイブされてもよい。エントロピー符号化ユニット56は、コーディングされている現在のビデオスライスに関する動きベクトルおよび他の構文要素を符号化してもよい。

逆量子化ユニット58および逆変換処理ユニット60は、参照ピクチャの参照ブロックとして後に使用するためのピクセル領域における残差ブロックを再構成するために、それぞれ、逆量子化および逆変換を適用する。動き補償ユニット44は、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算してもよい。動き補償ユニット44はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構成された残差ブロックに1つまたは複数の補間フィルタを適用してもよい。補間フィルタ処理が、知られているピクセルサンプルから追加のピクセルサンプルを生成することがあり、このようにして潜在的に、ビデオブロックをコーディングするために使用され得る候補予測ブロックの数が増加する。加算器62は、動き補償ユニット44によって生成された動き補償された予測ブロックに、再構成された残差ブロックを加算して、復号されたピクチャバッファ64に記憶するための参照ブロックを生成する。参照ブロックは、後続のビデオフレームまたはピクチャ内のブロックをインター予測するために、参照ブロックとして動き推定ユニット42および動き補償ユニット44によって使用されてもよい。

図3は、本開示に記載の技法を実装してもよい例示的なビデオデコーダ30を示すブロック図である。図3の例では、ビデオデコーダ30は、ビデオデータメモリ78と、エントロピー復号ユニット80と、予測処理ユニット81と、逆量子化ユニット86と、逆変換処理ユニット88と、加算器90と、フィルタユニット91と、復号ピクチャバッファ92とを含む。予測処理ユニット81は、動き補償ユニット82と、イントラ予測処理ユニット84とを含む。ビデオデコーダ30は、いくつかの例では、図2からのビデオエンコーダ20に関連して説明した符号化パスと全体的に相互的な復号パスを実行してもよい。

復号プロセスの間、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックおよび関連する構文要素を表すビデオデータ、たとえば符号化されたビデオビットストリームを受信する。ビデオデコーダ30は、ネットワークエンティティ29からビデオデータを受信し、そのビデオデータをビデオデータメモリ78に記憶することができる。ビデオデータメモリ78は、ビデオデコーダ30の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶してもよい。ビデオデータメモリ78内に記憶されたビデオデータは、たとえば記憶デバイス17から、たとえばカメラなどのローカルビデオソースから、ビデオデータのワイヤードもしくはワイヤレスネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって取得されてもよい。ビデオデータメモリ78は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコーディングされたピクチャバッファ(CPB)を形成してもよい。したがって、図3に別個に示しているけれども、ビデオデータメモリ78およびDPB92は、同じメモリデバイスまたは別個のメモリデバイスによって備えられてよい。ビデオデータメモリ78およびDPB92は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。様々な例では、ビデオデータメモリ78は、ビデオデコーダ30の他の構成要素とともにオンチップであってもよく、または、これらの構成要素に対してオフチップであってもよい。

たとえば、ネットワークエンティティ29は、上記で説明した技法のうちの1つまたは複数を実装するように構成されたサーバ、MANE、ビデオエディタ/スライサ、または他のそのようなデバイスであってよい。ネットワークエンティティ29は、ビデオエンコーダ20のようなビデオエンコーダを含んでもよく、含まなくてもよい。本開示で説明する技法のうちのいくつかは、ネットワークエンティティ29が符号化ビデオビットストリームをビデオデコーダ30に送信する前に、ネットワークエンティティ29によって実装されてもよい。いくつかのビデオ復号システムでは、ネットワークエンティティ29およびビデオデコーダ30は、別々のデバイスの部分であってよいが、他の例では、ネットワークエンティティ29に関して説明される機能は、ビデオデコーダ30を備える同じデバイスによって実行されてもよい。いくつかの場合には、ネットワークエンティティ29は、図1の記憶デバイス17の一例であってよい。

ビデオデコーダ30のエントロピー復号ユニット80は、量子化係数と、動きベクトルと、他の構文要素とを生成するためにビットストリームを復号する。エントロピー復号ユニット80は、予測処理ユニット81に動きベクトルと他の構文要素とを転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいて構文要素を受信してもよい。

ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされたとき、予測処理ユニット81のイントラ予測処理ユニット84は、通知されたイントラ予測モードと、現在のフレームまたはピクチャの以前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成してもよい。ビデオフレームがインターコーディングされた(すなわち、BまたはP)スライスとしてコーディングされたとき、またはブロックがIBCコーディングされたとき、予測処理ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信した動きベクトルと他の構文要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。インター予測に対して、予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、DPB92内に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、リスト0およびリスト1を構成してもよい。IBCコーディングに対して、予測ブロックは、予測されているブロックと同じピクチャから生成されてよい。現在のピクチャに対する参照フレームインデックスは、参照フレームリスト0およびリスト1のうちの一方または両方に含まれてよい。いくつかの例では、ビデオデコーダ30は、IBCモードが特定のブロックをコーディングするために使用されたことを示す特定の構文要素を通知するのではなく、現在のピクチャを指す参照フレームインデックスからIBCモードを推測するように構成されてよい(たとえば、現在のブロックに対する予測ブロックは、現在のブロックと同じピクチャからのものである)。

動き補償ユニット82は、動きベクトルと他の構文要素とを構文解析することによって、現在のビデオスライスのビデオブロックのための予測情報を決定し、復号されている現在のビデオブロックのための予測ブロックを生成するために予測情報を使用する。たとえば、動き補償ユニット82は、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラ予測またはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスのための参照ピクチャリストのうちの1つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコーディングされたビデオブロックのためのインター予測状態と、現在のビデオスライス内のビデオブロックを復号するための他の情報とを決定するために、受信した構文要素の一部を使用する。

動き補償ユニット82はまた、補間フィルタに基づいて補間を実行してもよい。動き補償ユニット82は、参照ブロックのサブ整数ピクセルに関する補間値を計算するために、ビデオブロックの符号化の間にビデオエンコーダ20によって使用されるように補間フィルタを使用してもよい。この場合には、動き補償ユニット82は、受信した構文要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するために補間フィルタを使用してもよい。

いくつかの例では、予測処理ユニット81は、動きベクトル予測および/またはブロックベクトル予測を実行してもよい。すなわち、ビデオデータのブロックを符号化するために使用される動きベクトルおよび/またはブロックベクトルの全体を受信するのではなく、動きベクトルおよび/またはブロックベクトルは、隣接ブロックの動きベクトルおよび/またはブロックベクトルに対して予測されてよい。以下でより詳細に説明するように、本開示は、インター予測とIBCコーディングモードの両方に対して動きベクトル予測およびブロックベクトル予測のための技法を説明する。

本開示のいくつかの技法によれば、IBCモードを使用してビデオブロックをコーディングするとき、動き補償ユニット82は、ビデオブロックのルーマ成分に対する動きベクトルまたはブロックベクトルを決定し、ルーマ成分に対する動きベクトルに基づいてビデオブロックのクロマ成分に対する動きベクトルを決定することができる。別の例では、IBCモードを使用してビデオブロックをコーディングするとき、動き補償ユニット82は、ビデオブロックのクロマ成分に対する動きベクトルまたはブロックベクトルを決定し、クロマ成分に対する動きベクトルに基づいてビデオブロックのルーマ成分に対する動きベクトルを決定することができる。したがって、ビデオデコーダ30は、1つだけのブロックベクトルをビットストリーム内で受信し、そのブロックベクトルから、ビデオブロックのクロマ成分とルーマ成分の両方に対するオフセットベクトルが決定され得る。

IBCモードを使用してビデオブロックを復号するとき、動き補償ユニット82は、たとえば、ルーマ成分に対する、IBCモードに対するブロックオフセットベクトルと呼ばれる動きベクトルを修正して、クロマ成分に対するブロックベクトルを決定することができる。動き補償ユニット82は、たとえば、ビデオブロックに対するサンプリングフォーマットに基づいて、およびブロックベクトルが指すサブピクセル位置の正確さに基づいて、ルーマブロックのブロックベクトルのx成分とy成分の一方または両方を修正することができる。たとえば、ビデオブロックが4:2:2サンプリングフォーマットを使用してコーディングされる場合、動き補償ユニット82は、ルーマオフセットベクトルのy成分を修正せず、x成分だけを修正して、クロマ成分に対するオフセットベクトルを決定することができる。

別の例では、ビデオブロックが4:2:0サンプリングフォーマットを使用してコーディングされる場合、動き補償ユニット82は、ルーマブロックベクトルのx成分とy成分のいずれかまたは両方を修正して、クロマ成分に対するブロックベクトルを決定することができる。動き補償ユニット82は、クロマ予測ブロックの位置を特定するために使用されるとき、ルーマブロックベクトルが(たとえば、現在のブロックを含む現在のピクチャのクロマサンプル内のサブピクセル位置において)クロマサンプルがない位置を指す場合、ルーマブロックベクトルだけを修正してもよい。ルーマブロックベクトルが、クロマ予測ブロックの位置を特定するために使用されるとき、クロマサンプルが存在する位置を指す場合、動き補償ユニット82は、ルーマブロックベクトルを修正しない。

動き補償ユニット82は、ルーマブロックベクトルを修正して、修正されたブロックベクトルとも呼ばれる、修正された動きベクトルを生成することができる。動き補償ユニット82は、クロマ予測ブロックの位置を特定するために使用されるとき、クロマブロックのために使用される、修正されたブロックベクトルが、より低い解像度のサブピクセル位置を指すか、または整数ピクセル位置を指すように、サブピクセル位置を指すルーマブロックベクトルを修正してよい。一例として、1/8ピクセル位置を指すルーマオフセットベクトルが1/4ピクセル位置を指すように修正されてよく、1/4ピクセル位置を指すルーマブロックベクトルが1/2ピクセル位置を指すように修正されてよく、以下同様である。他の例では、動き補償ユニット82は、修正されたブロックベクトルがクロマ参照ブロックの位置を特定するために整数ピクセル位置を常に指すように、ルーマブロックベクトルを修正してもよい。より低い解像度のサブピクセル位置かまたは整数ピクセル位置を指すようにルーマブロックベクトルを修正することによって、何らかの補間フィルタ処理の必要性を除去すること、および/または任意の必要な補間フィルタ処理の複雑さを低減することが可能になる。

逆量子化ユニット86は、ビットストリーム内で提供され、エントロピー復号ユニット80によって復号された量子化変換係数を逆量子化する(inverse quantize)、すなわち逆量子化する(de-quantize)。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライス内の各ビデオブロックのための、ビデオエンコーダ20によって計算された量子化パラメータの使用を含んでもよい。逆変換処理ユニット88は、ピクセル領域における残差ブロックを生成するために、変換係数に逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを適用する。

動き補償ユニット82が、動きベクトルと他の構文要素とに基づいて現在のビデオブロックのための予測ブロックを生成した後、ビデオデコーダ30は、逆変換処理ユニット88からの残差ブロックを、動き補償ユニット82によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器90は、この加算演算を実行する1つまたは複数の成分を表す。必要に応じて、(コーディングループ内またはコーディングループ後のいずれかの)ループフィルタもまた、ピクセル遷移を平滑化するため、またはさもなければビデオ品質を改善するために使用されてよい。フィルタユニット91は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなど、1つまたは複数のループフィルタを表すことを意図している。フィルタユニット91は、ループフィルタであるように図3に示されているが、他の構成では、フィルタユニット91は、ポストループフィルタとして実装されてもよい。次いで、所与のフレームまたはピクチャ中の復号されたビデオブロックが、後続の動き補償のために使用される参照ピクチャを記憶する復号済みピクチャバッファ92内に記憶される。復号されたピクチャバッファ92は、図1の表示デバイス32などの表示デバイス上で後で表示するために復号されたビデオを同様に記憶するメモリの一部であってよく、またはそのようなメモリから分離されてもよい。

以下のセクションは、動きベクトル予測およびブロックベクトル予測に対する本開示の技法に関連するビデオコーディングの追加の特徴を論じる。

インター予測を用いてコーディングされた各ブロックに対して、動き情報のセットが利用可能であり得る。動き情報のセットは、前向きおよび後向き予測方向に対する動き情報を含む。ここで、前向きおよび後向き予測方向は、双方向性予測モードの2つの予測方向であり、「前向き」および「後向き」という用語は、必ずしも幾何学的な意味を有するとは限らない。そうではなく、「前向き」および「後向き」という用語は、現在のピクチャの参照ピクチャリスト0(RefPicList0)および参照ピクチャリスト1(RefPicList1)に対応する。1つだけの参照ピクチャリストが1つのピクチャまたはスライスに対して利用可能であるとき、RefPicList0だけが利用可能であり、スライスの各ブロックの動き情報は、常に前向きである。

各予測方向に対して、動き情報は、参照インデックスおよび動きベクトルを含んでよい。いくつかの場合には、簡単のために、動きベクトルが関連する参照インデックスを有することが仮定される方法で、動きベクトル自体が参照されてよい。参照インデックスは、現在の参照ピクチャリスト(RefPicList0またはRefPicList1)内の参照ピクチャを識別するために使用される。動きベクトルは、水平および垂直の成分を有してよい。

ピクチャ順序カウント(POC)は、ピクチャの表示順序を識別するためにビデオコーディング規格において広く使用されている。1つのコーディングされたビデオシーケンス内の2つのピクチャが同じPOC値を有することがある場合があるが、それは、一般に、コーディングされたビデオシーケンス内で発生しない。複数のコーディングされたビデオシーケンスが1つのビットストリーム内に存在するとき、同じ値のPOCを有するピクチャは、復号順序に関して互いに接近している。

ピクチャのPOC値は、一般に、参照ピクチャリスト構築、HEVC内にあるような参照ピクチャセットの導出、および動きベクトルスケーリングのために使用される。

HEVCでは、スライスの中の最大のコーディングユニットは、コーディングツリーブロック(CTB)と呼ばれる。CTBは、そのノードがコーディングユニットである4分木を含む。CTBのサイズは、HEVCメインプロファイルにおいて16×16〜64×64の範囲とすることができる(ただし、技術的には8×8CTBサイズをサポートすることができる)。CUは、CTBと同じサイズであってもよいが、8×8程度の小さいサイズであってもよい。各CUは、1つのモードでコーディングされる。CUは、インターコーディングされるときに、2つの予測ユニット(PU:prediction unit)にさらに区分されてもよく、またはさらなる区分が適用されないときに単一のPUになってもよい。1つのCUの中に2つのPUが存在するとき、PUは、CUの半分のサイズの長方形であってもよく、あるいはCUの1/4または3/4のサイズを有する2つの長方形であってよい。

CUがインターコーディングされるとき、動き情報の1セットが各PUに対して存在する。加えて、各PUは、動き情報のセットを導出するために一意のインター予測モードでコーディングされる。HEVCでは、最小のPUサイズは、8×4および4×8である。

いくつかの例では、エンコーダは、元の動きベクトルを直接通知するのではなく、各区分に対する、すなわち各PUに対する動きベクトルを予測してよい。この動きベクトル予測を実行することにおいて、ビデオエンコーダ20は、現在の部分と同じフレーム内の空間的隣接ブロックから決定された候補動きベクトルのセット、または参照フレーム内にコロケートされたブロックから決定された候補動きベクトルを決定してよい。ビデオエンコーダ20は、動きベクトル予測を実行してよく、必要な場合、シグナリングにおけるビットレートを低減するために、元の動きベクトルを通知するのではなく、ビデオデコーダ30が動きベクトルを予測することを可能にする構文要素を通知してもよい。空間的隣接ブロックからの候補動きベクトルは、空間的動きベクトル予測子(MVP)候補と呼ばれることがある一方で、別の参照フレーム内のコロケートされたブロックからの候補動きベクトルは、時間的MVP候補と呼ばれることがある。

HEVC規格では、予測ユニット(PU)に対して、それぞれ、マージモード(スキップはマージの特別な場合であると見なされる)および高度動きベクトル予測(AMVP)モードと名付けられた、2つのインター予測モードがある。概して、これらのモードは、動きベクトル予測モードと呼ばれることがある。

マージモードでは、ビデオエンコーダ20は、予測構文のビットストリームシグナリングを介してビデオデコーダ30に、フレームの現在のブロックに対して選択された候補動きベクトルから、動きベクトルと、(所与の参照ピクチャリスト内で動きベクトルが指す参照フレームを識別する)参照ピクチャインデックスと、(参照ピクチャリスト(List 0またはList 1)を識別する、すなわち参照フレームが時間的に現在のフレームに先行するかまたは後続するかに関して識別する)動き予測方向とをコピーするように指示する。これは、選択された候補動きベクトル(たとえば、特定の空間的MVP候補または時間的MVP候補)を識別する候補動きベクトルリストへのインデックスをビットストリーム内で通知することによって達成される。したがって、マージモードに対して、予測構文は、モード(この場合は「マージ」モード)と、選択された候補動きベクトルを識別するインデックスとを識別するフラグを含んでよい。いくつかの例では、候補動きベクトルは、現在のブロックに関する原因部分(causal portion)内にあることになる。すなわち、候補動きベクトルは、ビデオデコーダ30によってすでに復号されていることになる。このように、ビデオデコーダ30はすでに、原因部分に対する動きベクトル、参照インデックス、および動き予測方向を受信および/または決定している。このように、ビデオデコーダ30は、メモリから原因部分に関連する動きベクトル、参照インデックス、および動き予測方向を簡単に取り出して、これらの値を現在の部分に対する動き情報としてコピーすることができる。マージモードでブロックを再構成するために、ビデオデコーダ30は、現在の部分に対して導出された動き情報を使用して予測ブロックを取得し、残差データを予測ブロックに加えて、コーディングされたブロックを再構成する。

AMVPでは、ビデオエンコーダ20は、ビットストリームシグナリングを介してビデオデコーダ30に、単に、候補の部分から動きベクトルをコピーし、コピーされたベクトルを現在の部分の動きベクトルに対する予測子として使用して、動きベクトル差分(MVD)を通知するように指示する。現在の部分の動きベクトルに関連する参照フレームおよび予測方向が、別々に通知される。MVDは、現在のブロックに対する現在の動きベクトルと候補ブロックから導出された動きベクトル予測子との間の差分である。この場合、ビデオエンコーダ20は、動き推定を使用して、コーディングされるべきブロックに対する実際の動きベクトルを決定し、次いで、実際の動きベクトルと動きベクトル予測子との間の差分をMVD値として決定する。このようにして、ビデオデコーダ30は、マージモードにおけるように候補動きベクトルの正確なコピーを現在の動きベクトルとして使用するのではなく、動き推定から決定された現在の動きベクトルに「近い」値であり得る候補動きベクトルを使用し、MVDを加算して現在の動きベクトルを復元することができる。ブロックをAMVPモードで再構成するために、ビデオデコーダ30は、対応する残差データを加算してコーディングされたブロックを再構成する。

ほとんどの状況において、MVDは、現在の動きベクトル全体より少ないビットを、通知するために必要とする。このように、AMVPは、全動きベクトルを送信することをしのぐコーディング効率を維持しながら、現在の動きベクトルをより正確に通知することを可能にする。対照的に、マージモードは、MVDの仕様を斟酌せず、したがって、マージモードは、向上したシグナリング効率(すなわち、より少ないビット)のために、動きベクトルシグナリングの正確さを犠牲にする。AMVPに対する予測構文には、モードに対するフラグ(この場合はAMVPフラグ)、候補部分に対するインデックス、現在の動きベクトルと候補部分からの予測動きベクトルとの間のMVD、参照インデックス、および動き予測方向が含まれることがある。

AMVPモードまたはマージモードのいずれでも、動きベクトル(MV)候補リストが、複数の動きベクトル予測子のために維持される。現在のPUの、動きベクトルならびにマージモードにおける参照インデックスは、MV候補リストから1つの候補を決定することによって生成される。

一例では、MV候補リストは、マージモードに対して5つまでの候補を含んでよく、AMVPモードに対して2つだけの候補を含んでよい。両モードに対するMVP候補は、同じ空間的および時間的隣接ブロックから同様に導出される。一例では、空間的MV候補は、特定のPU(PU0)に対して図4に示す隣接ブロックから導出され得るが、ブロックから候補を生成する方法は、マージモードとAMVPモードとで異なる。すなわち、動きベクトル予測モードの各々は候補ブロックの同じセットを使用してよいが、使用されるMVP候補の最終リストを決定するために、異なるMVP候補リスト導出技法を使用してよい。

マージモードに対する一例では、5つの空間的MV候補の位置が、図4に示されている。各候補位置に対して、利用可能性が、順序{a1、b1、b0、a0、b2}に従って検査される。いくつかの例では、特定の候補に対する動き情報は、特定の候補ブロックが、そのブロックに関連付けられた動き情報を持たない(たとえば、候補ブロックはイントラ予測を使用してコーディングされた)場合、利用不可能であると見なされることがある。他の例では、候補ブロックは、それらが現在コーディングされているブロックと同じCU内にある場合、利用不可能であると見なされることがある。

図4に示すように、AMVPモードに対する一例では、隣接ブロックは2つのグループ、すなわちブロックa0およびa1からなる左のグループと、ブロックb0、b1およびb2からなる上のグループとに分割される。左のグループに対して、利用可能性が、順序{a0、a1}に従って検査される。上のグループに対して、利用可能性が、順序{b0、b1、b2}に従って検査される。各グループに関して、シグナリングされた参照インデックスによって示される参照ピクチャと同じ参照ピクチャを参照する隣接ブロック内の潜在的候補は、グループの最終候補を形成するために選択されるための最高の優先度を有する。すべての隣接ブロックが、同じ参照ピクチャを指す動きベクトルを含まないことが可能である。そのために、そのような候補を見出すことができない場合、第1の利用可能な候補が、最終候補を形成するようにスケーリングされることになり、したがって時間的距離の差が補償され得る。

マージモードの一例では、空間的候補を検証した後、2種類の冗長性が除去され得る。現在のPUに対する候補位置が同じCU内の第1のPUを指す場合、同じマージが、予測区分に分離することなくCUによって達成され得るので、その位置は除外される。さらに、候補がまったく同じ動き情報を有する冗長なエントリもまた除外されてよい。

空間的隣接候補が検査された後、時間的候補が検証される(たとえば、時間的候補が利用可能な動き情報に対して検査される)。時間的候補に対して、参照ピクチャのコロケートされたPUのすぐ外側にある右下の位置が、それが利用可能である場合に使用される。さもなければ、中央の位置が、代わりに使用される。コロケートされたPUを選択する方法は、前の規格の方法と同様であるが、HEVCは、どの参照ピクチャリストがコロケートされた参照ピクチャのために使用されるかを指定するためのインデックスを送信することによって、より大きい柔軟性を可能にする。

時間的候補の使用に関する1つの問題は、参照ピクチャの動き情報を記憶するためのメモリの量である。この問題は、より小さいPB構造が参照ピクチャ内の対応する位置において使用されるときでさえ、時間的動き候補を記憶するための粒度を、わずか16×16ルーマグリッド(luma grid)の解像度に制限することによって対処される。加えて、ピクチャパラメータセット(PPS)フラグは、エンコーダが、エラーを起こしやすい送信を伴う応用例に対して有用である時間的候補の使用を無効にすることを許容する。

いくつかの例では、マージ候補Cの最大数が、スライスヘッダ内で指定される。発見された(時間的候補を含む)マージ候補の数がCより大きい場合、最初のC-1個の空間的候補および時間的候補だけが保持される。さもなければ、識別されたマージ候補の数がCより小さい場合、その数がCに等しくなるまで、追加の候補が生成されてよい。これは、コーディングされたデータを構文解析する能力が、マージ候補の利用可能性に依存しないので、構文解析を簡単にし、構文解析をよりロバストにする。追加のMVP候補は、必要な場合、「デフォルト」MVP候補または「代用の」MVP候補と呼ばれることがある。

Bスライスに対して、追加のマージ候補が、参照ピクチャリスト0およびリスト1に対する既定の順序に従って2つの既存の候補を選択することによって生成される。たとえば、最初に生成された候補は、リスト0に対する第1のマージ候補と、リスト1に対する第2のマージ候補とを使用する。HEVCは、すでに構成されているマージ候補リスト内で以下の順序の2個の、合計12個の所定のペアを、(0, 1)、(1, 0)、(0, 2)、(2, 0)、(1, 2)、(2, 1)、(0, 3)、(3, 0)、(1, 3)、(3, 1)、(2, 3)および(3, 2)として指定する。それらの中で、5個までの候補が、冗長なエントリを取り除いた後で含まれ得る。

マージ候補の数が依然としてC未満であるとき、デフォルト動きベクトルおよび対応する参照インデックスを含むデフォルトマージ候補が代わりに使用され、ゼロから参照ピクチャ数マイナス1までの参照インデックスに関連付けられたゼロ動きベクトルが、マージ候補リスト内の残りのエントリを埋めるために使用される。

AMVPモードの一例では、HEVCは、より少ない数の候補が、動きベクトル予測プロセスの場合に使用されることを可能にする。なぜならば、ビデオエンコーダ20は、コーディングされた差分を送信して、動きベクトルを変えることができるからである。さらに、ビデオエンコーダ20は、ビデオエンコーダ20の中で最も計算コストが高い演算のうちの1つである動き推定を実行し、複雑さは、少ない数の候補を許容することによって低減される。

隣接するPUの参照インデックスが現在のPUの参照インデックスに等しくないとき、動きベクトルのスケーリングされたバージョンが使用されてよい。隣接する動きベクトルは、現在のピクチャと、隣接するPUおよび現在のPUそれぞれの参照インデックスによって示される参照ピクチャとの間の時間的距離に従ってスケーリングされる。

いくつかの例では、2つの空間的候補が同じ動きベクトル成分を有するとき、1つの冗長な空間的候補が除外されてよい(たとえば、MVP候補リストに加えられない)。一例では、動きベクトル予測子の数が2に等しくなく、時間的MV予測の使用が明示的に無効にされているとき、時間的MV予測候補が含められる。これは、2つの空間的候補が利用可能であるとき、時間的候補はまったく使用されないことを意味する。

最後に、この例ではゼロ動きベクトル(すなわち、ゼロの値を有する動きベクトル)であるデフォルト動きベクトルは、動きベクトル予測候補の数が2に等しくなるまで繰り返し含められ、そのことが、動きベクトル予測子の数が2であることを保証する。したがって、どの動きベクトル予測がAMVPモードの場合に使用されるかを識別するために、コーディングされたフラグだけが必要である。

動きベクトルは、それがクロマ動き補償に対して使用される前に、現在のPU/CUのルーマ成分に対して導出される。動きベクトルは、クロマサンプリングフォーマットに基づいてスケーリングされてよい。

HEVCでは、LCU(または「CTB」)が、並行した動き推定領域(MER)に分割されてよく、現在のPUと異なるMERに属するそれらの隣接するPUだけが、マージ/スキップMVPリスト構築プロセス内に含められることを可能にする。MERのサイズは、構文要素log2_parallel_merge_level_minus2を有するPPS内で通知される。

MERサイズがN×Nより大きく、2N×2Nが最小CUサイズであるとき、MERは、空間的隣接ブロックが現在のPUと同じMER内にある場合、空間的隣接ブロックは利用不可能であるものと見なされるという効果を生じる。

IBCコーディングモードは、HEVCに対するいくつかのバージョンのSCC内に含まれている。IBCコーディング技法を示す概念図が、図5におけるように示されており、現在のブロック(CU/PU)102は、現在のピクチャ/スライスのすでに復号された予測ブロック104から予測される。この例では、予測信号(たとえば、現在のブロック102と予測ブロック104との間の予測残差)は再構成されるが、ループ内フィルタ処理なしに、デブロッキングおよびサンプル適応オフセット(SAO)を含む。

ビデオエンコーダ20およびビデオデコーダ30は、図5に示すようにIBCモードを使用してビデオデータのブロックを符号化および復号するように構成されてよい。リモートデスクトップ、リモートゲーミング、ワイヤレスディスプレイ、自動インフォテインメント、クラウドコンピューティングなど、多くの適用例が、人々の日常生活における常套手段になりつつあり、そのようなコンテンツをコーディングするときのコーディング効率が、IBCモードの使用によって改善され得る。図1のシステム10は、これらの適用例のいずれかを実行するように構成されたデバイスを表すことができる。これらの用途でのビデオコンテンツは、しばしば、自然なコンテンツ、テキスト、人工グラフィックスなどの組合せである。ビデオフレームのテキストおよび人工グラフィックス領域では、繰り返されるパターン(文字、アイコン、シンボルなど)がしばしば存在する。上記で紹介したように、IBCは、この種類の冗長性を除去し、イントラフレームコーディング効率を潜在的に改善することを可能にする専用の技法である。IBCを使用するコーディングユニット(CU)に対して図5に示すように、予測信号は、現在のブロック102と同じフレーム内ですでに再構成された探索領域108から取得される。最終的に、現在のブロック102から変位された予測ブロック104の位置を示すブロックベクトル106は、予測残差とともに符号化される。ブロックベクトル106は、水平成分112および垂直成分110を含んでよいことに留意されたい。

図5は、本開示による、たとえば本開示の技法に従うIBCモードによる、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測に対するモードに従って、現在のピクチャ103内のビデオデータの現在のブロック102を予測するための例示的な技法を示す。図5は、現在のピクチャ103内のビデオデータの予測ブロック104を示す。ビデオコーダ、たとえば、ビデオエンコーダ20および/またはビデオデコーダ30は、予測ビデオブロック104を使用して、本開示の技法に従うIBCによって現在のビデオブロック102を予測してもよい。

ビデオエンコーダ20は、ビデオデータの以前に再構成されたブロックのセットから現在のビデオブロック102を予測するための予測ビデオブロック104を選択する。ビデオエンコーダ20は、符号化されたビデオビットストリームにも含まれるビデオデータを逆量子化し逆変換し、得られた残差ブロックを、ビデオデータの再構成されたブロックを予測するのに使用される予測ブロックと加算することによってビデオデータのブロックを再構成する。図5の例では、ピクチャ103内の探索領域108は、「対象領域」または「ラスタ領域」と呼ばれることもあり、以前に再構成されたビデオブロックのセットを含む。ビデオエンコーダ20は、以下でより詳細に説明するように、ピクチャ103内の探索領域108を多様な方法で定義してよい。ビデオエンコーダ20は、探索領域108内の様々なビデオブロックに基づいて現在のブロック102を予測しコーディングする相対的な効率および精度の分析に基づいて探索領域108内のビデオブロックの中から現在のブロック102を予測するために予測ブロック104を選択してもよい。

探索領域108は、現在のブロック102と同じピクチャ103からのすでにコーディングされたブロックを含む。たとえば、フレームがラスタ走査順序(すなわち、左から右および上から下)でコーディングされていると仮定すると、図5に示すように、フレームのすでにコーディングされたブロックは、現在のブロック102の左および上にあるブロックに対応する。いくつかの例では、探索領域108は、フレーム内のすでにコーディングされたブロックのすべてを含んでよいが、他の例では、探索領域は、すでにコーディングされたブロックのすべてより少ないブロックを含んでよい。

ビデオエンコーダ20は、現在のブロック102に対する予測ブロック104の位置または変位を表すブロックベクトル106を決定する。ブロックベクトル106は、現在のビデオブロック102に対する予測ブロック104の水平変位および垂直変位をそれぞれ表す水平変位成分112および垂直変位成分110を含む。一例では、図5のブロックベクトルは、現在のブロック102の左上のピクセルと予測ブロック104の左上のピクセルとの間の差分を識別する。したがって、符号化されたビデオビットストリーム内のブロックベクトルを通知することによって、ビデオデコーダ30は、現在のブロック102がIBCモードでコーディングされるとき、現在のブロック102に対する予測ブロック104を識別することができる。ビデオエンコーダ20は、符号化されたビデオビットストリーム内の、ブロックベクトル106を特定または定義する、たとえば水平変位成分112および垂直変位成分110を定義する、1つまたは複数の構文要素を含んでもよい。ビデオデコーダ30は、ブロックベクトル106を決定するために1つまたは複数の構文要素を復号し、決定されたベクトルを使用して現在のビデオブロック102に対する予測ブロック104を識別してもよい。以下でより詳細に説明するように、本開示の例では、ビデオエンコーダ20およびビデオデコーダ30は、IBCモードに対するブロックベクトルを予測するために(たとえば、現在のブロックと同じフレーム内でビデオデータの別のブロックから予測されたビデオデータの現在のブロックに対するブロックベクトルを予測するために)、インター予測に対する動きベクトルをコーディングするために使用される技法のような動きベクトル予測技法を使用してもよい。

いくつかの例では、ブロックベクトル106の解像度は整数ピクセルであり得る、たとえば整数ピクセルの解像度を有するように制約され得る。そのような例では、水平変位成分112および垂直変位成分110の解像度は、整数ピクセルの解像度であることになる。そのような例では、ビデオエンコーダ20およびビデオデコーダ30は、現在のビデオブロック102に対する予測子を決定するために予測ビデオブロック104のピクセル値を補完する必要はない。

他の例では、水平変位成分112および垂直変位成分110の一方または両方の解像度は、サブピクセルの解像度であり得る。たとえば、成分112および110のうちの一方は整数ピクセルの解像度を有してよく、他方はサブピクセルの解像度を有してよい。いくつかの例では、水平変位成分112と垂直変位成分110の両方の解像度は、サブピクセルであり得るが、水平変位成分112および垂直変位成分110は、異なる解像度を有することがある。

いくつかの例では、ビデオコーダ、たとえばビデオエンコーダ20および/またはビデオデコーダ30は、水平変位成分112および垂直変位成分110の解像度を、特定のレベル、たとえばブロックレベル、スライスレベル、またはピクチャレベルの適合に基づいて適合させる。たとえば、ビデオエンコーダ20は、水平変位成分112および垂直変位成分110の解像度が整数ピクセルの解像度であるかまたは整数ピクセルの解像度でないかを示すスライスレベルにおけるフラグを、たとえばスライスヘッダ内で通知してよい。水平変位成分112および垂直変位成分110の解像度が整数ピクセルの解像度でないことをフラグが示す場合、ビデオデコーダ30は、解像度がサブピクセルの解像度であるものと推測してよい。いくつかの例では、必ずしもフラグであるとは限らない1つまたは複数の構文要素が、水平変位成分112および/または垂直変位成分110の総体的または個別的解像度を示すために、ビデオデータの各スライスまたは他のユニットに対して送信されてよい。

さらに他の例では、フラグまたは構文要素の代わりに、ビデオエンコーダ20は、解像度コンテキスト情報からの水平変位成分112および/または垂直変位成分110の解像度に基づいて設定してよく、ビデオデコーダ30は、解像度コンテキスト情報からの水平変位成分112および/または垂直変位成分110の解像度を推測してよい。解像度コンテキスト情報は、例として、現在のビデオブロック102を含むピクチャまたはピクチャのシーケンスに対する色空間(たとえば、YUV、RGBなど)、特定の色フォーマット(たとえば、4:4:4、4:2:2、4:2:0など)、フレームサイズ、フレームレート、または量子化パラメータ(QP)を含んでよい。少なくともいくつかの例では、ビデオコーダは、前にコーディングされたフレームまたはピクチャに関する情報に基づいて、水平変位成分112および/または垂直変位成分110の解像度を決定してよい。このようにして、水平変位成分112の解像度および垂直変位成分110に対する解像度はあらかじめ定義され、通知されるか、他のサイド情報(たとえば、解像度コンテキスト情報)から推測されるか、またはすでにコーディングされたフレームに基づくことがある。

現在のブロック102は、CUであってよく、またはCUのPUであってもよい。いくつかの例では、ビデオコーダ、たとえばビデオエンコーダ20および/またはビデオデコーダ30は、IBCに従って予測されたCUをいくつかのPUに分割してもよい。そのような例では、ビデオコーダは、CUのPUの各々についてそれぞれの(たとえば、異なる)2次元ベクトル106を決定してもよい。たとえば、ビデオコーダは、2N×2N CUを2つの2N×N PUまたは2つのN×2N PUまたは4つのN×N PUに分割してもよい。他の例として、ビデオコーダは、2N×2N CUを((N/2)×N+(3N/2)×N) PU、または((3N/2)×N+(N/2)×N) PU、または(N×(N/2)+N×(3N/2)) PU、または(N×(3N/2)+N×(N/2)) PU、または4つの(N/2)×2N PU、または4つの2N×(N/2) PUに分割してもよい。いくつかの例では、ビデオコーダは、2N×2N PUを使用して2N×2N CUを予測してもよい。

現在のブロック102は、ルーマビデオブロック(たとえば、ルーマ成分)と、ルーマビデオブロックに対応するクロマビデオブロック(たとえば、クロマ成分)とを含んでよい。いくつかの例では、ビデオエンコーダ20は、ルーマビデオブロックに対するブロックベクトル106を定義する1つまたは複数の構文要素だけを、符号化されたビデオビットストリームに符号化することがある。そのような例では、ビデオデコーダ30は、ルーマブロックに対して通知された2次元ベクトルに基づいて、ルーマブロックに対応する1つまたは複数のクロマブロックの各々に対するブロックベクトル106を導出してよい。本開示で説明する技法では、1つまたは複数のクロマブロックに対する2次元ベクトルの導出において、ビデオデコーダ30は、ルーマブロックに対する2次元ベクトルがクロマサンプル内のサブピクセル位置を指す場合、ルーマブロックに対する2次元ベクトルを修正してもよい。

色フォーマット、たとえば色サンプリングフォーマットまたはクロマサンプリングフォーマットに応じて、ビデオコーダは、ルーマビデオブロックに対して、対応するクロマビデオブロックをダウンサンプリングしてよい。色フォーマット4:4:4はダウンサンプリングを含まず、クロマブロックがルーマブロックと同じ数のサンプルを、水平および垂直の方向に含むことを意味する。色フォーマット4:2:2は水平方向にダウンサンプリングされ、ルーマブロックに対して、クロマブロック内で水平方向に半数のサンプルが存在することを意味する。色フォーマット4:2:0は水平および垂直の方向にダウンサンプリングされ、ルーマブロックに対して、クロマブロック内で水平および垂直の方向に半数のサンプルが存在することを意味する。

ビデオエンコーダ20および/またはビデオデコーダ30が、対応するルーマブロックに対するブロックベクトル106に基づいてクロマビデオブロックに対するブロックベクトル106を決定する例では、ビデオエンコーダ20および/またはビデオデコーダ30は、ルーマベクトルを修正してもよい。たとえば、ルーマブロックベクトル106が整数解像度を有し、水平変位成分112および/または垂直変位成分110が奇数の数のピクセルであり、色フォーマットが4:2:2または4:2:0である場合、変換されたルーマベクトルは、対応するクロマブロック内の整数ピクセル位置を指さない。そのような例では、ビデオエンコーダ20および/またはビデオデコーダ30は、ルーマベクトルを、対応するクロマブロックを予測するためのクロマベクトルとして使用するためにスケーリングしてよい。

次に、ブロック補償について説明する。IBCを用いてコーディングされたルーマ成分またはクロマ成分に対して、ビデオエンコーダ20および/またはビデオデコーダ30は、整数ブロック補償を使用してブロック補償を実行し、したがって、補間は必要とされない。この例では、ブロックベクトル106は、整数レベルにおいて予測され、通知される。

SCCに対するいくつかの提案において、ブロックベクトル106は、その全体を通知されるのではなく、ブロックベクトル予測子から予測される。一例では、ブロックベクトル予測子は、各CTBの最初に(-w, 0)に設定され、ここでwは、CU(たとえば、現在のブロック102)の幅である。そのようなブロックベクトル予測子は、それがIBCモードを用いてコーディングされる場合、更新されて、最新のコーディングされたCU/PUのうちの1つになる。

CU/PUがイントラBCを用いてコーディングされない場合、ブロックベクトル予測子は変更されないままである。ブロックベクトル予測の後、ブロックベクトルの差分が、上記で説明したHEVC内のMV差分(MVD)コーディング方法を使用して符号化される。

次に、IBCブロックサイズについて説明する。いくつかの例では、IBCは、CUレベルとPUレベルの両方において有効にされる。PUレベルのIBCコーディングに対して、2N×NおよびN×2NのPU区分が、すべてのCUサイズに対してサポートされる。加えて、CUが最少CUであるとき、N×NのPU区分がサポートされる。

上記で説明したように、本開示の例では、インター予測モードとIBCモードとが統合される。すなわち、ビデオエンコーダ20の動き推定ユニット42と動き補償ユニット44の両方が、インター予測モードとIBCモードの両方でビデオブロックを符号化するように構成されてよい。一例では、そのような統合は、動き推定ユニット42および動き補償ユニット44によって使用される参照ピクチャリストの中に現在フレームの参照フレームインデックスを含めることによって達成されてよい。同様に、ビデオデコーダ30の動き補償ユニット82はまた、動き補償ユニット82によって使用される参照ピクチャリストの中に現在フレームの参照フレームインデックスを含めることによって、インター予測モードとIBCモードの両方でビデオブロックを復号するように構成されてよい。2014年5月19日に出願された同時係属の米国仮出願第62/000,437号は、インター予測モードおよびIBCモードの統合のためのいくつかの技法について詳述している。

B. Liら、「Non-SCCE1: Unification of intra BC and inter modes」、ITU-T SG 16 WP 3およびISO/IEC JTC1/SC 29/WG 11のビデオコーディング共同研究部会(JCT-VC)、第18回会合、札幌、日本、2014年6月30日〜7月9日(JCTVC-R0100)において、イントラBCおよびインターの統合が提案された。上記で説明したように、現在のピクチャが、参照リストに追加される。現在のピクチャは、現在のピクチャを復号する前は長期参照ピクチャとしてマークされ、現在のピクチャを復号した後は短期参照ピクチャとしてマークされてよい。IBCモードが有効にされると、Pスライスの構文解析プロセスおよび復号プロセスが、Iスライス(たとえば、IBCコーディングされたブロックを含むスライス)に対して続けられる。

インター予測とIBCモードの統合に対して、通知された予測モードは同じであり得る(たとえば、両者がMODE_INTERを使用する)が、ビデオデコーダ30は、現在のブロックに関連付けられた参照インデックスによって識別された参照ピクチャが現在のピクチャである(たとえば、参照ピクチャインデックスによって識別された参照ピクチャが現在のピクチャと同じPOC値を有する)かどうかを検査することによって、IBCモードを使用してコーディングされたブロックと、従来のインター予測されたブロックとを区別することが可能であり得る。参照ピクチャおよび現在のピクチャが同じピクチャである場合、ビデオデコーダ30は、ブロックがIBCモードを使用してコーディングされたものと決定してよい。さもなければ、ブロックは、従来のインター予測された(たとえば、現在のブロックに対して別のピクチャ内のブロックから予測された)ブロックである。

インター予測モードとIBCモードの統合のための上記の技法はピクセル予測技法に対処するが、既存のIBC技法は、動きベクトルおよびブロックベクトルの予測に関していくつかの欠点を有することがある。本開示は、インター予測モードでコーディングされたブロックおよびIBCモードでコーディングされたブロックをコーディングするための、動きベクトル予測およびブロックベクトル予測のための技法を説明する。

本開示の一例では、IBCモードおよびインター予測モードのためのピクセル予測技法が上記で説明したように統合されると、ビデオエンコーダ20およびビデオデコーダ30は、IBCコーディングされたブロックに対するブロックベクトル予測の実行に対するものと同じ動きベクトル予測候補をインター予測されたブロックのために使用するようにさらに構成されてよい。すなわち、上記で概説したブロックベクトル予測技法を使用するのではなく、ビデオエンコーダ20およびビデオデコーダ30は、図4に示す候補ブロックを使用してインターマージおよびインターAMVP技法を使用するように構成されてよい。たとえば、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCモードを使用してコーディングされたブロックに対するブロックベクトルを予測するためにインターマージプロセスを使用してよい。

本開示の一例では、MVP候補リスト導出のためのルールを含む、インター予測されたブロックに対するマージプロセスおよびAMVPプロセスの全体が、IBCコーディングされたブロックに対して同様に利用される。他の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、(たとえば、ブロックベクトルを予測するために)IBCコーディングされたブロックに対する動きベクトル予測のマージモードおよびAMVPモードに対して同じ候補リストを使用してよいが、MVP候補リスト導出に対するルールは、いくつかの差を有することがある。

一例として、ブロックがIBCモードを使用してコーディングされる(たとえば、参照ピクチャインデックスによって識別される)場合、ビデオエンコーダ20および/またはビデオデコーダ30は、4×4より大きいサイズを有するすべてのIBCブロックに対してインター予測マージ技法を使用するように構成されてよい。4×4またはそれ以下のサイズを有するIBCブロックに対して、ビデオエンコーダ20および/またはビデオデコーダ30は、そのようなIBCブロックに対してマージ動きベクトル予測プロセスを無効にするように構成される。

本開示の別の例では、マージまたはAMVPでの使用に利用可能であると見なされるMVP候補は、現在コーディングされているブロックがインター予測モードまたはIBCモードを使用して符号化されたかどうかに応じて変更されてよい。本開示の一例では、図4に示す候補など、すべての可能なMVP候補は、それらの候補がIBCコーディングされたブロックであるか、またはインター予測コーディングされたブロックであるかにかかわらず、MVP候補リストに追加される。たとえば、IBCブロックに対するMVP候補は、インター予測されたブロックとIBCコーディングされたブロックの両方を含んでよい。同様に、インター予測されたブロックに対するMVP候補は、インター予測されたブロックとIBCコーディングされたブロックの両方を含んでよい。そのような技法は、ビデオエンコーダ20および/またはビデオデコーダ30が、マージモードおよび/またはAMVPモードに対する候補リスト導出プロセスの間の追加の条件検査を回避することを可能にすることがある。

本開示の別の例では、MVP候補リストに追加され得る候補ブロックのタイプは、何らかの方式で制限されることがある。たとえば、インター予測を使用してコーディングされたブロックに対して、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCコーディングされたブロックからのMVP候補リストに、X個までのMVP候補だけを追加するように構成されてよい。IBCコーディングされたブロックのブロックベクトルは、インター予測されたブロックに対する動きベクトルと同じフォーマットであってよいが、動きベクトルおよびブロックベクトルによって伝達された情報の性質は異なる。動きベクトルは、ビデオフレーム内の物体の、一フレームから別のフレームへの移動を示す一方で、ブロックベクトルは、単に、同じブロック内で現在のブロックと同様の情報を有する別のフレームを示す。インター予測されたブロックに対してMVP候補リスト内にあまりに多くのIBCコーディングされたブロックを含むことによって、動きベクトルを予測するときのビットレート効率が低下することがある。

このように、ビデオエンコーダ20および/またはビデオデコーダ30は、インター予測されたブロックに対するMVP候補リスト内に含まれ得るIBCコーディングされたブロックの数を制限するように構成されてよい。いくつかの例では、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCブロックからのすべてのMVP候補を利用不可能としてマークするように構成されてよい。利用不可能なMVP候補は、上記で説明したように、または以下で説明する本開示の技法に従って、デフォルト候補で置き換えられてよい。

同様に、本開示の別の例では、IBCモードを使用してコーディングされたブロックに対して、ビデオエンコーダ20および/またはビデオデコーダ30は、インター予測コーディングされたブロックからのMVP候補リストに、X個までのMVP候補だけを追加するように構成されてよい。いくつかの例では、ビデオエンコーダ20および/またはビデオデコーダ30は、インター予測されたブロックからのすべてのMVP候補を利用不可能としてマークするように構成されてよい。利用不可能なMVP候補は、上記で説明したように、または以下で説明する本開示の技法に従って、デフォルト候補で置き換えられてよい。

本開示の他の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、(たとえば、図4に示すような)同じマージ候補を使用して、マージ候補リストを導出してもよい。しかしながら、MVP候補リストに追加されるデフォルトのまたは追加のマージ候補は、インター予測ブロックおよびIBCコーディングされたブロックに対して異なることがある。HEVC v1におけるAMVPおよびマージモードに対する前の提案では、AMVPモードに対して2個の予測子候補と、マージモードに対して最小数(たとえば、5個)のMVP候補とが存在することを確実にするために、(ゼロ動きベクトルである)デフォルト動きベクトルがMVP候補リストに追加される。しかしながら、ゼロ動きベクトルは、IBCコーディングされたブロックに対して有効ではない。これは、IBCコーディングされたブロックは、同じピクチャ内の別のブロックに対してコーディングされるからである。したがって、ゼロ動きベクトルは、現在コーディングされているブロックを指すことになる。ブロックは、それ自体から予測されることはない。したがって、本開示の技法によれば、ビデオエンコーダ20および/またはビデオデコーダ30は、AMVPモードおよびマージモードに対するIBCコーディングされたブロックに対して有効である他のデフォルト動きベクトルを決定するように構成されてよい。

ビデオエンコーダ20および/またはビデオデコーダ30が、ブロックがIBCモードを使用してコーディングされたものと決定すると、AMVPおよびMVPの候補リスト構築のための技法は、動きベクトルをより効率的にコーディングするように、本開示において提案される。より具体的には、以下の例示的な技法が提案される。例示的な技法の各々は、他の技法のうちの1つまたは複数と別々に、または一緒に適用されてよい。

本開示の一例では、IBCコーディングされたブロックに対するデフォルト動きベクトル候補に対してゼロの候補を使用する代わりに、ビデオエンコーダ20および/またはビデオデコーダ30は、有効なIBC候補だけを含み、たとえばゼロ動きベクトルを含まないデフォルト候補の所定のリストからIBCコーディングされたブロックに対するデフォルト動きベクトル候補を選択するように構成されてよい。

別の例では、IBCコーディングされたブロックに対するデフォルト候補のセットは、(-2w, 0)、(2w, 0)、(-w, 0)、(w, 0)、(0, 0)、(0, -h)、(0, -2h)、(0, h)、(0, 2h)、(-8, 0)、(0, 8)、(-w, -h)、(-2w, -h)、(-w, -2h)、(-2w, -2h)のうちの1つまたは複数を含んでよく、ここでwおよびhは、現在のCU、PUまたはCTBの幅および高さである。他の例では、上記の所定のセットは、ゼロ動きベクトル(0, 0)を含まない。いくつかの例では、これらの所定のデフォルト動きベクトルの値は、整数ピクセル精度に対応することがあり、ビデオエンコーダ20および/またはビデオデコーダ30は、動きベクトルに対して使用される精度に応じてビデオエンコーダ20および/またはビデオデコーダ30によって所定の動きベクトルの値を上または下にスケーリングすることがある。たとえば、ビデオエンコーダ20およびビデオデコーダ30が動きベクトルを1/4ピクセル精度でコーディングするように構成される場合、ビデオエンコーダ20および/またはビデオデコーダ30は、使用前に、所定のセット内の動きベクトル(-2w, 0)を(-8w, 0)にスケーリングするように構成されてよい。

本開示の別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、動きベクトルの所定のセットをデフォルト動きベクトルとして使用するように構成されてよく、動きベクトルの所定のセットは、現在コーディングされているブロックと同じCTBの動きベクトルを、復号順序で(たとえば、最新にコーディングされたブロックを)含む。一例では、動きベクトルの所定のセットに追加された、前に復号された動きベクトルは、IBCコーディングされたブロックからのそれらの動きベクトルだけを含んでよい。別の例では、動きベクトルの所定のセットに追加された、前に復号された動きベクトルは、従来のインターコーディングされたブロックからのそれらの動きベクトルだけを含んでよい。別の例では、動きベクトルの所定のセットに追加された、前に復号された動きベクトルは、IBCコーディングされたブロックと従来のインターコーディングされたブロックの両方からの動きベクトルを含んでよい。

本開示の別の例では、IBCが有効にされるとき、利用不可能なMVP候補に対するデフォルト動きベクトル選択を除いて、ビデオエンコーダ20および/またはビデオデコーダ30は、HEVC v1におけるものと同じAMVP動きベクトル予測プロセスを、IBCコーディングされたブロックとインター予測されたブロックの両方に適用するように構成されてよい。一例では、ビデオエンコーダ20および/またはビデオデコーダ30は、デフォルト動きベクトルIBCおよびインターコーディングされたブロックとしてゼロ動きベクトルを使用しないように構成されてよい。代わりに、ビデオエンコーダ20および/またはビデオデコーダ30は、上記で定義されたデフォルト動きベクトルなど、デフォルト動きベクトルの所定のセットからのデフォルト動きベクトルを決定するように構成されてよい。別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、ゼロ動きベクトルを含まないデフォルト動きベクトルの所定のセットからデフォルト動きベクトルを決定するように構成されてよい。

本開示の別の例では、IBCが有効にされるとき、利用不可能なMVP候補に対するデフォルト動きベクトル選択を除いて、ビデオエンコーダ20および/またはビデオデコーダ30は、HEVC v1におけるものと同じマージ動きベクトル予測プロセスを、IBCコーディングされたブロックとインター予測されたブロックの両方に適用するように構成されてよい。一例では、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCコーディングされたブロックおよびインター予測コーディングされたブロックに対して同じマージ候補リストを使用するように構成されてよい。マージに対する候補リスト構築に対して、IBCコーディングされたブロックおよびインター予測コーディングされたブロックに対して使用されるデフォルト動きベクトルは、HEVC v1におけるようなゼロ動きベクトルではなく、上記で説明したように所定のセットから選択されてよい。このようにしてデフォルト動きベクトルを選択するとき、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCコーディングされたブロックに対する現在フレームの参照インデックスを使用するように構成されてよい。

別の例では、IBCコーディングされたブロックおよびインター予測コーディングされたブロックは、同じマージ候補リストを共有する。デフォルトマージ候補に対して、参照インデックス生成プロセスは、HEVC v1におけるプロセスと同じである。しかしながら、参照インデックスによってインデックス付けられる参照ピクチャが現在のピクチャであるとき、対応するデフォルト動きベクトルはゼロ動きベクトルではなく、ビデオエンコーダ20および/またはビデオデコーダ30は、上記で説明した所定のセットからデフォルト動きベクトルを決定するように構成されてよい。

上記で説明した技法のいずれかが、特定の参照リスト、たとえば参照リスト0だけ、参照リスト1だけ、または参照リスト0と参照リスト1の両方に対して使用されてよい。同じく、上記で説明した技法の使用は、現在のピクチャが参照ピクチャリストに追加されるかどうかに依存することがある。すなわち、IBCコーディングされたブロックに対してゼロ動きベクトルを使用しないための上記の技法は、IBCコーディングを可能にする参照ピクチャリスト(たとえば、現在のピクチャを含む参照ピクチャリスト)に限定されてよい。

本開示の他の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、上記のデフォルト候補以外のIBCマージ候補を決定するように構成されてよい。以下の技法は、IBCマージ候補の動きベクトルがマージプロセス内で現在のブロックに対して使用されるときに、全参照ブロックが利用可能でない(たとえば、参照ブロックが再構成されない、参照ブロックがパディングされない、参照ブロックが異なるスライス/タイル内にある、など)場合に適用されてよい。一例では、IBCマージ候補は、マージ候補リストに追加されないことになる。

別の例では、IBCマージ候補は候補リストに追加されるが、IBCマージ候補がマージプロセス内で使用される前に、ビデオエンコーダ20および/またはビデオデコーダ30は、以下の方法のうちの1つにおいてIBCマージ候補を変更するように構成されてよい。一例では、ビデオエンコーダ20および/またはビデオデコーダ30は、上記で説明したように、対応する動きベクトルを所定のセット内の動きベクトルで置き換えるように構成されてよい。たとえば、ルーマ位置(CUx, CUy)が現在のピクチャの左上のルーマサンプルに対して現在のルーマコーディングブロックの左上のサンプルを指定するものとすると、(PUx, PUy)は現在のピクチャの左上のルーマサンプルに対して現在のルーマ予測ブロックの左上のサンプルを指定し、(MVx, MVy)は変更されるべき1つのIBCマージ候補に対して対応する動きベクトルを指定し、(PUw, PUh)は現在のCUの幅および高さを指定する。PUx+MVx+PUw>CUxならば、MVyは、min(MVy, CUy-PUy-PUh)に変更される。

別の例では、ルーマ位置(CUx CUy)が現在のピクチャの左上のルーマサンプルに対して現在のルーマコーディングブロックの左上のサンプルを指定するものとすると、(PUx, PUy)は現在のピクチャの左上のルーマサンプルに対して現在のルーマ予測ブロックの左上のサンプルを指定し、(MVx, MVy)は変更されるべき1つのIBCマージ候補に対して対応する動きベクトルを指定し、(PUw, PUh)は現在のCUの幅および高さを指定する。PUy+MVy+PUh>CUyならば、MVxは、min(MVx, CUx-PUx-PUw)に変更される。

本開示の別の例では、時間的MVP(TMVP)が使用されるとき、コロケートされたMVが、IBCコーディングされたブロックとインター予測コーディングされたブロックの両方に対して、AMVPモードおよびマージモードに対する候補リストの構築に使用されてよい。しかしながら、HEVCマージモードに伴って、現在のピクチャが長期参照ピクチャとしてマークされているとき、およびコロケートされたブロックがIBCブロックであるとき、問題が発生することがある。たとえば、参照リスト内の第1の参照ピクチャ(たとえば、参照インデックスが0に等しい)が長期ピクチャでないに場合、コロケートされたIBCブロックに関連付けられたMVは、マージモードに対する候補リストに追加されないことになる。本開示の例によれば、以下の技法が、候補リスト構築に利用されてよい。

一例では、IBCモードとTMVPの両方が有効にされるとき、マージプロセスに対して、コロケートされたブロックがIBCブロックである場合、ビデオエンコーダ20および/またはビデオデコーダ30は、各参照ピクチャリスト内の第1の参照ピクチャが長期参照ピクチャであるかまたは短期参照ピクチャであるかを検査することなく、コロケートされたIBCブロックを利用可能であるものと見なしてよい。ビデオエンコーダ20および/またはビデオデコーダ30は、コロケートされたIBCブロックに関連付けられたMVを候補リストに追加するように構成されてよい。ビデオエンコーダ20および/またはビデオデコーダ30は、HEVCにおけるコロケートされたブロックの導出技法と同じ方法でコロケートされたブロックを導出するように構成されてよい。すなわち、最初に右下のブロックを検査し、利用可能でない場合、次いで中央のブロックを検査する。

別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、右下のブロックと中央のブロックの両方がIBCブロックである限り、各リスト内の第1の参照ピクチャが長期参照ピクチャであるかまたは短期参照ピクチャであるかを検査することなく、右下のブロックと中央のブロックの両MV(たとえば、ブロックベクトル)を候補リストに追加するように構成されてよい。このようにして、MV(たとえば、ブロックベクトル)をマージ候補リストに追加することによって、現在のブロックに対して対応する参照インデックスは、現在のピクチャに対応する参照インデックスとなるように設定される。

別の例では、IBCモードとTMVPの両方が有効にされるとき、AMVPプロセスに対して、コロケートされたブロックがIBCブロックである場合、ビデオエンコーダ20および/またはビデオデコーダ30は、現在のブロックの参照ピクチャが長期参照ピクチャであるかまたは短期参照ピクチャであるかを検査することなく、コロケートされたIBCブロックを利用可能であるものと見なしてよい。ビデオエンコーダ20および/またはビデオデコーダ30は、コロケートされたIBCブロックに関連付けられたMVを候補リストに追加するように構成されてよい。ビデオエンコーダ20および/またはビデオデコーダ30は、HEVCにおけるコロケートされたブロック導出技法と同じ方法でコロケートされたブロックを導出するように構成されてよい。すなわち、最初に右下のブロックを検査し、利用可能でない場合、次いで中央のブロックを検査する。

別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、右下のブロックと中央のブロックの両方がIBCブロックである限り、各リスト内の第1の参照ピクチャが長期参照ピクチャであるかまたは短期参照ピクチャであるかを検査することなく、右下のブロックと中央のブロックの両MV(たとえば、ブロックベクトル)を候補リストに追加するように構成されてよい。

上記の例では、現在のMV(たとえば、ブロックベクトル)をIBCブロックとして取り扱うとき、特定のMV(たとえば、ブロックベクトル)が現在のブロックに対して有効でない場合、MV(たとえば、ブロックベクトル)は、候補リストに追加されない可能性がある。

図6は、本開示の技法による例示的なビデオ符号化方法を示すフローチャートである。図6の技法は、動き補償ユニット44および動き推定ユニット42を含む、ビデオエンコーダ20の1つまたは複数の構造によって実施され得る。以下で説明する例の各々は、一緒に実行されてよく、または別々に実行されてもよいことを理解されたい。

図6に示すように、本開示の一例では、ビデオエンコーダ20は、ビデオデータの第2のフレーム内の第1の予測ブロックに対して、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを符号化するように構成されてよい(600)。第1の予測ブロックは、動きベクトルによって識別されてよい。ビデオエンコーダ20は、ビデオデータの第1のフレーム内の第2の予測ブロックに対して、ビデオデータの第1のフレーム内のビデオデータの第2のブロックを符号化するようにさらに構成されてよい(602)。第2の予測ブロックは、ブロックベクトルによって識別されてよい。ビデオエンコーダ20は、動きベクトル予測プロセスおよび動きベクトル候補リストを使用して動きベクトルを符号化すること(604)と、動きベクトル予測プロセス、および動きベクトルを符号化するために使用されたものと同じ動きベクトル候補リストを使用してブロックベクトルを符号化すること(606)とを行うようにさらに構成されてよい。

本開示の技法はまた、インター予測されたブロックが、IBCコーディングされたブロックを含む同じフレーム内で符号化されない状況において使用されてよいことを理解されたい。たとえば、ビデオエンコーダ20は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを符号化することであって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、符号化することと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを符号化することとを行うように構成されてよく、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

本開示の一例では、動きベクトル予測プロセスは、マージモードおよび高度動きベクトル予測(AMVP)モードのうちの1つである。本開示の別の例では、ビデオデータの第2のブロックは、4×4であるかまたはそれより小さい。

本開示の別の例では、ブロックベクトルを符号化するために、ビデオエンコーダ20は、動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

本開示の別の例では、ビデオエンコーダ20は、それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定し、デフォルト動きベクトルを動きベクトル候補リストに追加するようにさらに構成されてよい。本開示の別の例では、ビデオエンコーダ20は、デフォルト動きベクトルの所定のセットからデフォルト動きベクトルを決定するようにさらに構成されてよく、所定のセットはゼロベクトル(0, 0)を含まない。

本開示の別の例では、動きベクトルを符号化するために、ビデオエンコーダ20は、動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

本開示の別の例では、ブロックベクトルを符号化するために、ビデオエンコーダ20は、動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。本開示の別の例では、ブロックベクトルを符号化するために、ビデオエンコーダ20は、動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

図7は、本開示の技法による例示的なビデオ復号方法を示すフローチャートである。図7の技法は、動き補償ユニット82を含む、ビデオデコーダ30の1つまたは複数の構造によって実施されてよい。以下で説明する例の各々は、一緒に実行されてよく、または別々に実行されてもよいことを理解されたい。

図7に示すように、本開示の一例では、ビデオデコーダ30は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信するように構成されてよく、ビデオデータの第1のブロックは、ビデオデータの第2のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックは動きベクトルによって識別される(700)。ビデオデコーダ30は、ビデオデータの第1のフレーム内のビデオデータの第2のブロックを受信するようにさらに構成されてよく、ビデオデータの第2のブロックは、ビデオデータの第1のフレーム内の第2の予測ブロックに対して符号化され、第2の予測ブロックはブロックベクトルによって識別される(702)。ビデオデコーダ30は、動きベクトル予測プロセスおよび動きベクトル候補リストを使用して動きベクトルを復号すること(704)と、動きベクトル予測プロセス、および動きベクトルを復号するために使用されたものと同じ動きベクトル候補リストを使用してブロックベクトルを復号すること(706)とを行うようにさらに構成されてよい。ビデオデコーダ30は、第1の予測ブロックおよび動きベクトルを使用してビデオデータの第1のブロックを復号することと、第2の予測ブロックおよびオフセットベクトルを使用してビデオデータの第2のブロックを復号することとを行うようにさらに構成されてよい。

本開示の技法はまた、インター予測されたブロックが、IBCコーディングされたブロックを含む同じフレーム内で受信されない状況において使用されてよいことを理解されたい。たとえば、ビデオデコーダ30は、ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信することであって、ビデオデータの第1のブロックはビデオデータの第1のフレーム内の第1の予測ブロックに対して符号化され、第1の予測ブロックはブロックベクトルによって識別される、受信することと、動きベクトル予測プロセスおよび動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストを使用してブロックベクトルを復号することとを行うように構成されてよく、動きベクトルは、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される。

本開示の一例では、動きベクトル予測プロセスは、マージモードおよび高度動きベクトル予測(AMVP)モードのうちの1つである。本開示の別の例では、ビデオデータの第2のブロックは、4×4であるかまたはそれより小さい。

本開示の別の例では、ブロックベクトルを復号するために、ビデオデコーダ30は、動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

本開示の別の例では、ビデオデコーダ30は、それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定し、デフォルト動きベクトルを動きベクトル候補リストに追加するようにさらに構成されてよい。本開示の別の例では、ビデオデコーダ30は、デフォルト動きベクトルの所定のセットからデフォルト動きベクトルを決定するようにさらに構成されてよく、所定のセットはゼロベクトル(0, 0)を含まない。

本開示の別の例では、動きベクトルを復号するために、ビデオデコーダ30は、動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

本開示の別の例では、ブロックベクトルを復号するために、ビデオデコーダ30は、動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。本開示の別の例では、ブロックベクトルを復号するために、ビデオデコーダ30は、動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成されてよい。

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

限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標)ディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せは、コンピュータ可読媒体の範囲内に同じく含まれるものとする。

命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは離散論理回路のような、1つまたは複数のプロセッサによって実行されてもよい。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明される技法の実装に適した任意の他の構造のいずれかを指す場合がある。さらに、いくつかの態様では、本明細書で述べられた機能は、専用のハードウェア内で、かつ/または符号化および復号を行うように構成された、もしくは組み合わされたコーデックに組み込まれたソフトウェアモジュール内で提供することができる。さらに本技法は、1つまたは複数の回路または論理要素において完全に実施することもできる。

本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装されてもよい。本開示では、開示する技法を実施するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが述べられているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。そうではなくて、上記で述べたように、様々なユニットは、コーデックハードウェアユニットにおいて組み合わせることができる、または適切なソフトウェアおよび/またはファームウェアと併せて、上記で述べたように1つまたは複数のプロセッサを含む、相互運用するハードウェアユニットの集合体により提供することができる。

様々な例を説明してきた。これらおよび他の例は以下の特許請求の範囲内に入る。

10 ビデオコーディングシステム
12 ソースデバイス
14 宛先デバイス
16 リンク
17 記憶デバイス
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
27 後処理エンティティ
28 入力インターフェース
29 ネットワークエンティティ
30 ビデオデコーダ
32 表示デバイス
33 ビデオデータメモリ
35 区分ユニット
41 予測処理ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測処理ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピー符号化ユニット
58 逆量子化ユニット
60 逆変換処理ユニット
62 加算器
63 フィルタユニット
64 復号ピクチャバッファ(DPB)
78 ビデオデータメモリ
80 エントロピー復号ユニット
81 予測処理ユニット
82 動き補償ユニット
84 イントラ予測処理ユニット
86 逆量子化ユニット
88 逆変換処理ユニット
90 加算器
91 フィルタユニット
92 復号ピクチャバッファ(DPB)
102 現在のブロック(CU/PU)
103 現在のピクチャ
104 予測ブロック
106 ブロックベクトル
108 探索領域
110 垂直成分、垂直変位成分
112 水平成分、水平変位成分

Claims (30)

1. ビデオデータを復号する方法であって、
   ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信するステップであって、ビデオデータの前記第1のブロックが、ビデオデータの前記第1のフレーム内の第1の予測ブロックに対して符号化され、前記第1の予測ブロックが、ブロックベクトルによって識別される、受信するステップと、
   動きベクトル予測プロセスと、動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストとを使用して前記ブロックベクトルを復号するステップとを含み、前記動きベクトルが、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される、方法。
2. 前記動きベクトル予測プロセスが、マージモードおよび高度動きベクトル予測(AMVP)モードのうちの1つである、請求項1に記載の方法。
3. ビデオデータの前記第2のブロックを受信するステップと、
   前記動きベクトル予測プロセスと、前記動きベクトル候補リストとを使用して前記動きベクトルを復号するステップとをさらに含む、請求項1に記載の方法。
4. 前記第1の予測ブロックおよび前記ブロックベクトルを使用してビデオデータの前記第1のブロックを復号するステップと、
   前記フレーム間予測ブロックおよび前記動きベクトルを使用してビデオデータの前記第2のブロックを復号するステップとをさらに含む、請求項3に記載の方法。
5. 前記動きベクトルを復号するステップが、
   前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項3に記載の方法。
6. 前記ブロックベクトルを復号するステップが、
   前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項1に記載の方法。
7. それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定するステップと、
   デフォルト動きベクトルを前記動きベクトル候補リストに追加するステップとをさらに含む、請求項6に記載の方法。
8. デフォルト動きベクトルの所定のセットから前記デフォルト動きベクトルを決定するステップをさらに含み、前記所定のセットがゼロベクトル(0, 0)を含まない、請求項7に記載の方法。
9. 前記ブロックベクトルを復号するステップが、
   前記動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項1に記載の方法。
10. ビデオデータを復号するように構成された装置であって、前記装置が、
    ビデオデータを記憶するように構成されたメモリと、
    ビデオデコーダとを備え、前記ビデオデコーダが、
    ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信することであって、ビデオデータの前記第1のブロックが、ビデオデータの前記第1のフレーム内の第1の予測ブロックに対して符号化され、前記第1の予測ブロックが、ブロックベクトルによって識別される、受信することと、
    動きベクトル予測プロセスと、動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストとを使用して前記ブロックベクトルを復号することとを行うように構成され、前記動きベクトルが、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される、装置。
11. 前記ビデオデコーダが、
    ビデオデータの前記第2のブロックを受信することと、
    前記動きベクトル予測プロセスと、前記動きベクトル候補リストとを使用して前記動きベクトルを復号することとを行うようにさらに構成される、請求項10に記載の装置。
12. 前記ビデオデコーダが、
    前記第1の予測ブロックおよび前記ブロックベクトルを使用してビデオデータの前記第1のブロックを復号することと、
    前記フレーム間予測ブロックおよび前記動きベクトルを使用してビデオデータの前記第2のブロックを復号することとを行うようにさらに構成される、請求項11に記載の装置。
13. 前記動きベクトルをさらに復号するために、前記ビデオデコーダが、
    前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成される、請求項11に記載の装置。
14. 前記ブロックベクトルを復号するために、前記ビデオデコーダが、
    前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成される、請求項10に記載の装置。
15. 前記ビデオデコーダが、
    それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定することと、
    デフォルト動きベクトルを前記動きベクトル候補リストに追加することとを行うようにさらに構成される、請求項14に記載の装置。
16. 前記ビデオデコーダが、
    デフォルト動きベクトルの所定のセットから前記デフォルト動きベクトルを決定するようにさらに構成され、前記所定のセットがゼロベクトル(0, 0)を含まない、請求項15に記載の装置。
17. 前記ブロックベクトルを復号するために、前記ビデオデコーダが、
    前記動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するようにさらに構成される、請求項10に記載の装置。
18. 前記ビデオデコーダと通信している表示デバイスをさらに備え、前記ビデオデコーダが前記ビデオデータを復号するようにさらに構成され、前記表示デバイスが前記復号されたビデオデータを表示するように構成される、請求項10に記載の装置。
19. ビデオデータを符号化する方法であって、
    ビデオデータの第1のフレーム内のビデオデータの第1のブロックを符号化するステップであって、ビデオデータの前記第1のブロックが、ビデオデータの前記第1のフレーム内の第1の予測ブロックに対して符号化され、前記第1の予測ブロックが、ブロックベクトルによって識別される、符号化するステップと、
    動きベクトル予測プロセスと、動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストとを使用して前記ブロックベクトルを符号化するステップとを含み、前記動きベクトルが、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される、方法。
20. ビデオデータの前記第2のブロックを符号化するステップと、
    前記動きベクトル予測プロセスと、前記動きベクトル候補リストとを使用して前記動きベクトルを符号化するステップとをさらに含む、請求項19に記載の方法。
21. 前記第1の予測ブロックおよび前記ブロックベクトルを使用してビデオデータの前記第1のブロックを符号化するステップと、
    前記フレーム間予測ブロックおよび前記動きベクトルを使用してビデオデータの前記第2のブロックを符号化するステップとをさらに含む、請求項20に記載の方法。
22. 前記動きベクトルを符号化するステップが、
    前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項20に記載の方法。
23. 前記ブロックベクトルを符号化するステップが、
    前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項19に記載の方法。
24. それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定するステップと、
    デフォルト動きベクトルを前記動きベクトル候補リストに追加するステップとをさらに含む、請求項23に記載の方法。
25. デフォルト動きベクトルの所定のセットから前記デフォルト動きベクトルを決定するステップをさらに含み、前記所定のセットがゼロベクトル(0, 0)を含まない、請求項24に記載の方法。
26. 前記ブロックベクトルを符号化するステップが、
    前記動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するステップをさらに含む、請求項19に記載の方法。
27. ビデオデータを復号するように構成された装置であって、前記装置が、
    ビデオデータの第1のフレーム内のビデオデータの第1のブロックを受信するための手段であって、ビデオデータの前記第1のブロックが、ビデオデータの前記第1のフレーム内の第1の予測ブロックに対して符号化され、前記第1の予測ブロックが、ブロックベクトルによって識別される、受信するための手段と、
    動きベクトル予測プロセスと、動きベクトルを復号するために使用されるものと同じ動きベクトル候補リストとを使用して前記ブロックベクトルを復号するための手段とを含み、前記動きベクトルが、インターコーディングを使用してコーディングされたビデオデータの第2のブロックに対するフレーム間予測ブロックを識別するために使用される、装置。
28. 前記ブロックベクトルを復号するための前記手段が、
    前記動きベクトル候補リスト内の1つまたは複数の隣接ブロックからの候補ブロックベクトルおよび候補動きベクトルのうちの少なくとも1つを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するための手段をさらに含む、請求項27に記載の装置。
29. それぞれの候補ブロックベクトルまたはそれぞれの候補動きベクトルが利用不可能であるものと決定するための手段と、
    デフォルト動きベクトルを前記動きベクトル候補リストに追加するための手段と、
    デフォルト動きベクトルの所定のセットから前記デフォルト動きベクトルを決定するための手段とをさらに含み、前記所定のセットがゼロベクトル(0, 0)を含まない、請求項28に記載の装置。
30. 前記ブロックベクトルを復号するための前記手段が、
    前記動きベクトル候補リスト内の隣接ブロックからの候補ブロックベクトルだけを、前記動きベクトル予測プロセスに対する動きベクトル予測子候補リストに追加するための手段をさらに含む、請求項27に記載の装置。

Images