(57)【要約】  ビデオデータを復号する方法が、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することを含み、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数は現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数は５よりも大きい。いくつかの例では、本方法は、隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、導出されたヒストグラムに基づいて、動きベクトル候補リストを構築することとを含む。
2019515587.tif 000002
【特許請求の範囲】
【請求項１】
ビデオデータを復号する方法であって、前記方法は、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が５よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を備える、方法。
【請求項２】
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
をさらに備える、請求項１に記載の方法。
【請求項３】
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けること
をさらに備える、請求項２に記載の方法。
【請求項４】
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定すること
をさらに備える、請求項２に記載の方法。
【請求項５】
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
をさらに備える、請求項２に記載の方法。
【請求項６】
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
をさらに備える、請求項２に記載の方法。
【請求項７】
１つまたは複数の高度時間動きベクトル予測（ＡＴＭＶＰ）候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにＡＴＭＶＰ候補を追加すること
をさらに備える、請求項２に記載の方法。
【請求項８】
１つまたは複数のＡＴＭＶＰ候補のための動きベクトルの前記関数に基づいて、前記ＡＴＭＶＰ候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、請求項７に記載の方法。
【請求項９】
２つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
をさらに備える、請求項２に記載の方法。
【請求項１０】
１つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、請求項９に記載の方法。
【請求項１１】
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングすること
をさらに備える、請求項２に記載の方法。
【請求項１２】
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付けること
をさらに備える、請求項２に記載の方法。
【請求項１３】
ビデオデータを復号するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
１つまたは複数のプロセッサと
を備え、前記１つまたは複数のプロセッサは、
マージモードで符号化されたビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が５よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行うように構成された、装置。
【請求項１４】
前記１つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、請求項１３に記載の装置。
【請求項１５】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、請求項１４に記載の装置。
【請求項１６】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、請求項１４に記載の装置。
【請求項１７】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、請求項１４に記載の装置。
【請求項１８】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
を行うようにさらに構成された、請求項１４に記載の装置。
【請求項１９】
前記１つまたは複数のプロセッサが、
１つまたは複数の高度時間動きベクトル予測（ＡＴＭＶＰ）候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにＡＴＭＶＰ候補を追加する
ようにさらに構成された、請求項１４に記載の装置。
【請求項２０】
前記１つまたは複数のプロセッサが、
１つまたは複数のＡＴＭＶＰ候補のための動きベクトルの前記関数に基づいて、前記ＡＴＭＶＰ候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、請求項１９に記載の装置。
【請求項２１】
前記１つまたは複数のプロセッサが、
２つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
を行うようにさらに構成された、請求項１４に記載の装置。
【請求項２２】
前記１つまたは複数のプロセッサが、
１つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、請求項１４に記載の装置。
【請求項２３】
前記１つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングする
ようにさらに構成された、請求項１４に記載の装置。
【請求項２４】
前記１つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付ける
ようにさらに構成された、請求項１４に記載の装置。
【請求項２５】
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータを復号するように構成された１つまたは複数のプロセッサに、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が５よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行わせる、コンピュータ可読記憶媒体。
【請求項２６】
ビデオデータを符号化するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
１つまたは複数のプロセッサと
を備え、前記１つまたは複数のプロセッサは、
ビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が５よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを符号化することと
を行うように構成された、装置。
【請求項２７】
前記１つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、請求項２６に記載の装置。
【請求項２８】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、請求項２７に記載の装置。
【請求項２９】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、請求項２７に記載の装置。
【請求項３０】
前記１つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、請求項２７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、２０１６年５月１３日に出願された米国仮出願第６２／３３６，４４９号の利益を主張する。
【０００２】
[0002]本開示は、ビデオコーディングに関する。
【背景技術】
【０００３】
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）とも呼ばれるＩＴＵ−Ｔ  Ｈ．２６５によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法など、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００４】
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を含む。ブロックベースビデオコーディングでは、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、いくつかの技法ではツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００５】
[0005]空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルに従って符号化され、残差データは、コード化ブロックと予測ブロックとの間の差分を示す。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換され、残差変換係数が生じ得、その残差変換係数は、次いで量子化され得る。最初に２次元アレイで構成される量子化変換係数は、変換係数の１次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するために、エントロピーコーディングが適用され得る。
【発明の概要】
【０００６】
[0006]概して、本開示は、ビデオデータのブロックのための動き情報のコーディング（たとえば、符号化または復号）に関係する技法について説明する。本開示の様々な例では、（マージ候補リストまたは単に候補リストとも呼ばれる）動きベクトル候補リストが、複数の隣接ブロックからの動き情報を使用して構築され得る。動き情報のヒストグラムが導出され、次いで、動きベクトル候補リストのための空間マージ候補の順序および／またはロケーションを決定するために使用され得る。
【０００７】
[0007]一例では、本開示は、ビデオデータを復号する方法について説明し、本方法は、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が５よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを備える。
【０００８】
[0008]別の例では、本開示は、ビデオデータを復号するように構成された装置について説明し、本装置は、ビデオデータの現在ブロックを記憶するように構成されたメモリと、１つまたは複数のプロセッサとを備え、１つまたは複数のプロセッサは、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が５よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを行うように構成される。
【０００９】
[0009]別の例では、本開示は、命令を記憶するコンピュータ可読記憶媒体であって、命令が、実行されたとき、ビデオデータを復号するように構成された１つまたは複数のプロセッサに、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が５よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを行わせる、コンピュータ可読記憶媒体について説明する。
【００１０】
[0010]一例では、本開示は、ビデオデータを符号化するように構成された装置について説明し、本装置は、ビデオデータの現在ブロックを記憶するように構成されたメモリと、１つまたは複数のプロセッサとを備え、１つまたは複数のプロセッサは、ビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が５よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを符号化することとを行うように構成される。
【００１１】
[0011]１つまたは複数の例の詳細が、添付の図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１２】
【図１】[0012]本開示の技法を実行するように構成され得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２】[0013]本開示の技法を実行するように構成され得るビデオエンコーダの一例を示すブロック図。
【図３】[0014]本開示の技法を実行するように構成され得るビデオデコーダの一例を示すブロック図。
【図４】[0015]高効率ビデオコーディング（ＨＥＶＣ）におけるコーディングユニット（ＣＵ）構造を示す概念図。
【図５】[0016]インター予測モードのための例示的な区分タイプを示す概念図。
【図６Ａ】[0017]４分木２分木（ＱＴＢＴ：quad-tree-binary-tree）構造を使用するブロック区分の一例を示す概念図。
【図６Ｂ】[0018]図６ＡのＱＴＢＴ構造を使用するブロック区分に対応する例示的なツリー構造を示す概念図。
【図７】[0019]ＨＥＶＣにおける空間隣接候補を示す概念図。
【図８】[0020]ＨＥＶＣにおける時間動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）を示す概念図。
【図９】[0021]３Ｄ−ＨＥＶＣのための例示的な予測構造を示す概念図。
【図１０】[0022]３Ｄ−ＨＥＶＣにおけるサブＰＵベースインタービュー動き予測を示す概念図。
【図１１】[0023]参照ピクチャからのサブＰＵ動き予測を示す概念図。
【図１２】[0024]ＡＴＭＶＰにおける関連するピクチャを示す概念図。
【図１３】[0025]本開示の技法による、例示的な方法を示すフローチャート。
【図１４】[0026]ＰＵおよび隣接ブロックの一例を示す概念図。
【図１５】[0027]ＰＵおよび隣接ブロックの別の例を示す概念図。
【図１６】[0028]ＰＵおよび隣接ブロックの別の例を示す概念図。
【図１７】[0029]ＰＵおよび隣接ブロックの別の例を示す概念図。
【図１８】[0030]本開示の例示的な符号化方法を示すフローチャート。
【図１９】[0031]本開示の例示的な復号方法を示すフローチャート。
【発明を実施するための形態】
【００１３】
[0032]本開示は、マージベース動きベクトル予測の効率を改善するための技法について説明する。本開示は、動きベクトル予測のために使用すべきマージ候補を決定するための技法について説明する。本開示の例示的な技法は、マージ候補の適応順序付けおよびプルーニング（adaptive ordering and pruning）を含み得る。本開示の例示的な適応順序付け技法は、空間、サブ予測ユニット（ＰＵ）、および組合せ動きベクトル（ｃｏｍｂｉ−ｍｖ：combined motion vector）候補の適応順序付けを含み得る。いくつかの例では、本開示の提案される適応プルーニング技法は、時間動きベクトル予測（ＴＭＶＰ）候補、０動きベクトル（０ｍｖ）候補、ならびに上述の候補を含む、すべてのマージ候補に適用され得る。
【００１４】
[0033]本開示の技法は、以下の利益、すなわち、（１）より高い効率、（２）単純さ（たとえば、より低いデコーダ実装複雑さ）、および（３）フレキシビリティのうちの１つまたは複数を与え得る。本明細書で説明される技法は、実際の動きベクトルに値がより近い（または値がより近くなる可能性がある）マージ候補により高い優先度を割り当てることによって、より高いビット節約（bit-savings）を与え得る。さらに、ビデオエンコーダおよびビデオデコーダ複雑さ、ならびにメモリ要件は、比較的小さい。最後に、提案される技法は、Ｈ．２６６および４分木プラス２分木（ＱＴＢＴ：quad-tree plus binary tree ）ベースビデオコーデックなど、様々なコーデックに適用され得る。さらに、提案される技法は、本明細書で説明される技法が、独立してまたは一緒に使用され得るように、技法が任意の様式で組み合わせられ得るようなフレキシビリティを与える。
【００１５】
[0034]図１は、動きベクトル予測のための本開示の技法を実行するように構成され得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示されているように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介してビデオデータを宛先デバイス１４に与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４はワイヤレス通信のために装備され得る。
【００１６】
[0035]宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体１６は、ソースデバイス１２から宛先デバイス１４に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、符号化ビデオデータを宛先デバイス１４にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【００１７】
[0036]いくつかの例では、符号化データは、出力インターフェース２２からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介してストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することと、その符号化ビデオデータを宛先デバイス１４に送信することとが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブがある。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、またはその両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【００１８】
[0037]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【００１９】
[0038]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、動きベクトル予測のための本開示の技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなど、外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【００２０】
[0039]図１の図示されたシステム１０は一例にすぎない。動きベクトル予測のための本開示の技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオテレフォニーのための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートし得る。
【００２１】
[0040]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明される技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
【００２２】
[0041]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Ｂｌｕ−ｒａｙディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、ソースデバイス１２から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス１４に与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
【００２３】
[0042]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号ビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００２４】
[0043]ビデオエンコーダ２０およびビデオデコーダ３０は、高効率ビデオコーディング（ＨＥＶＣ）規格、ＨＥＶＣ規格に対する拡張、またはＩＴＵ−Ｔ  Ｈ．２６６などの後続の規格など、ビデオコーディング規格に従って動作し得る。代替または追加として、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例としては、ＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。
【００２５】
[0044]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路またはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、本開示の技法を実行するために１つまたは複数のプロセッサを使用してその命令をハードウェアで実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。
【００２６】
[0045]以下でより詳細に説明されるように、ビデオエンコーダ２０およびビデオデコーダ３０は、ビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の（a number of）隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が５よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックをコーディングする（たとえば、符号化または復号する）こととを行うように構成され得る。
【００２７】
[0046]ビデオコーディング規格は、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ：Scalable Video Coding）拡張とマルチビュービデオコーディング（ＭＶＣ：Multiview Video Coding）拡張とを含む、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４を含む。ＭＶＣの１つのジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１０年３月に記載されている。
【００２８】
[0047]さらに、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）とのジョイントコラボレーションチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）によって開発された、新たに開発されたビデオコーディング規格、すなわち、ＨＥＶＣがある。ＨＥＶＣの最近のドラフトは、http://phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zipから入手可能である。ＨＥＶＣ規格はまた、両方が「High efficiency video coding」と題する、両方が２０１４年１０月に発行された、勧告ＩＴＵ−Ｔ  Ｈ．２６５および国際規格ＩＳＯ／ＩＥＣ２３００８−２において一緒に提示される。
【００２９】
[0048]ＪＣＴ−ＶＣはＨＥＶＣ規格を開発した。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づいていた。ＨＭは、たとえば、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定した。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを与えるが、ＨＥＶＣ  ＨＭは３３個ものイントラ予測符号化モードを与え得る。本開示は、説明の目的で何らかの（some）ＨＥＶＣ用語を使用し得るが、本開示の技法はＨＥＶＣに限定されず、実際は、本開示の技法が、ＨＥＶＣの後継規格において実装され得ることが明示的に企図される。
【００３０】
[0049]概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding unit）に分割され得ることを記載した。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）にスプリットされ得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵにスプリットされた場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
【００３１】
[0050]４分木データ構造の各ノードは、対応するＣＵのためのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵにスプリットされるかどうかを示すスプリットフラグを含み得る。ＣＵのためのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵにスプリットされるかどうかに依存し得る。ＣＵがさらにスプリットされない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的スプリッティングが存在しない場合でも、リーフＣＵの４つのサブＣＵはリーフＣＵとも呼ばれる。たとえば、１６×１６サイズのＣＵがさらにスプリットされない場合、その１６×１６ＣＵが決してスプリットされなくても、４つの８×８サブＣＵはリーフＣＵとも呼ばれる。
【００３２】
[0051]ＣＵは、ＣＵがサイズ差異を有しないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、（サブＣＵとも呼ばれる）４つの子ノードにスプリットされ得、各子ノードは、今度は親ノードとなり、別の４つの子ノードにスプリットされ得る。４分木のリーフノードと呼ばれる、最後のスプリットされていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックがスプリットされ得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ：smallest coding unit）をも定義し得る。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵ、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。
【００３３】
[0052]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４ピクセル以上をもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含んでいることがある。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モード（partitioning mode）は、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。ＰＵは、形状が非正方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従ってＣＵを１つまたは複数のＴＵに区分することをも記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。
【００３４】
[0053]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従う変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、これは常にそうであるとは限らない。ＴＵは、一般に、ＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用してより小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、変換係数を生成するために変換され得、その変換係数は量子化され得る。
【００３５】
[0054]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間エリアを表し、そのＰＵのための参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのデータは、ＰＵに対応するＴＵについてのイントラ予測モードを記述するデータを含み得る残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）を記述し得る。
【００３６】
[0055]１つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上記で説明されたように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、スプリットフラグは、リーフＣＵが４つの変換ユニットにスプリットされるかどうかを示し得る。次いで、各変換ユニットは、さらなるサブＴＵにさらにスプリットされ得る。ＴＵがさらにスプリットされないとき、そのＴＵはリーフＴＵと呼ばれることがある。概して、イントラコーディングでは、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、概して、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングでは、ビデオエンコーダは、イントラ予測モードを使用して各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵは、ＰＵよりも大きいことも小さいこともある。イントラコーディングでは、ＰＵは、同じＣＵのための対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。
【００３７】
[0056]その上、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連し得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してツリーブロック（またはＬＣＵ）に対応する。スプリットされないＲＱＴのＴＵはリーフＴＵと呼ばれる。概して、本開示は、特に明記しない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
【００３８】
[0057]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ：group of pictures）は、概して、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックはＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定されたコーディング規格に応じてサイズが異なり得る。
【００３９】
[0058]一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測と、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称ＰＵサイズでのインター予測とをサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ  ＰＵと下部の２Ｎ×１．５Ｎ  ＰＵとで水平方向に区分された２Ｎ×２Ｎ  ＣＵを指す。
【００４０】
[0059]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここで、Ｎは非負整数値を表す。ブロック中のピクセルは行および列に配列され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。
【００４１】
[0060]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後に、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＣＵのための変換係数を生成するためにＴＵを変換し得る。
【００４２】
[0061]変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、ここで、ｎはｍよりも大きい。
【００４３】
[0062]量子化の後に、ビデオエンコーダは、変換係数を走査し、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、アレイの前部により高いエネルギー（したがって、より低い周波数）係数を配置し、アレイの後部により低いエネルギー（したがって、より高い周波数）係数を配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応型走査を実行し得る。１次元ベクトルを形成するために量子化変換係数を走査した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【００４４】
[0063]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、コンテキストモデル内のコンテキストを、送信されるべきシンボルに割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルのための可変長コードを選択し得る。ＶＬＣ中のコードワードは、比較的より短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのための等長コードワードを使用することに勝るビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
【００４５】
[0064]図２は、以下でより詳細に説明されるように、動きベクトル予測のための本開示の技法を実行するように構成され得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオの時間冗長性を低減または除去するために時間予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースコーディングモードのいずれかを指すことがある。単方向予測（Ｐモード）または双予測（Ｂモード）などのインターモードは、いくつかの時間ベースコーディングモードのいずれかを指すことがある。
【００４６】
[0065]図２に示されているように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、ビデオデータメモリ４１と、モード選択ユニット４０と、参照ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、今度は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、区分ユニット４８とを含む。ビデオブロック再構築のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。再構築されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するための（図２に示されていない）デブロッキングフィルタも含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタ処理することになる。（ループ中またはループ後の）追加のフィルタもデブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、（ループ内フィルタとして）加算器５０の出力をフィルタ処理し得る。
【００４７】
[0066]ビデオデータメモリ４１は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶するように構成され得る。ビデオデータメモリ４１に記憶されたビデオデータは、たとえば、ビデオソース１８から取得され得る。（復号ピクチャバッファと呼ばれることがある）参照ピクチャメモリ６４は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ４１および参照ピクチャメモリ６４は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ４１および参照ピクチャメモリ６４は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ４１は、ビデオエンコーダ２０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
【００４８】
[0067]符号化プロセス中に、ビデオエンコーダ２０は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は、代替的に、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
【００４９】
[0068]その上、区分ユニット４８は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、さらに、サブＣＵへのＬＣＵの区分を示す４分木データ構造を生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと１つまたは複数のＴＵとを含み得る。
【００５０】
[0069]モード選択ユニット４０は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの１つを選択し得、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器５０に与え、参照フレームとして使用するための符号化ブロックを再構築するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器６２に与える。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報など、シンタックス要素をエントロピー符号化ユニット５６に与える。
【００５１】
[0070]動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別個に示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを発生するプロセスである。動きベクトルは、たとえば、現在フレーム（または他のコード化ユニット）内でコーディングされている現在ブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
【００５２】
[0071]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵのための動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得、それらの各々が、参照ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。
【００５３】
[0072]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴い得る。この場合も、動き推定ユニット４２および動き補償ユニット４４は、いくつかの例では、機能的に統合され得る。現在ビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいてそれを指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明されるように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
【００５４】
[0073]動き推定ユニット４２と動き補償ユニット４４とを含むビデオエンコーダ２０は、図１に関して上記で説明された、および以下でより詳細に説明される本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット４４は、本開示の技法に従ってＡＭＶＰモードまたはマージモードを使用してビデオデータのブロックのための動き情報をコーディングするように構成され得る。さらに、動き推定ユニット４２と動き補償ユニット４４とを含むビデオエンコーダ２０は、以下でより詳細に説明される、本開示の動きベクトル候補リスト構築技法の任意の組合せを実行するように構成され得る。本開示のコンテキストでは、動きベクトル候補リスト、マージ候補リスト、および候補リストという用語は、互換的に使用され得る。
【００５５】
[0074]動き補償ユニット４４がマージモードを実行することを選ぶと仮定すると、動き補償ユニット４４は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット４４は、特定の、所定の順序に基づいて候補リストに候補を追加し得る。本開示の他の例では、動き補償ユニット４４は、隣接ブロックからの動きベクトルのヒストグラム情報に基づいて、動的に異なる順序で候補リストに候補を追加するように構成され得る。動き補償ユニット４４はまた、以下でより詳細に説明されるように、追加の候補を追加し、候補リストのプルーニングを実行し得る。最終的に、モード選択ユニット４０は、現在ブロックの動き情報を符号化し、選択された候補を表すマージインデックスを符号化するために、それらの候補のうちのどれが使用されるべきかを決定し得る。
【００５６】
[0075]イントラ予測ユニット４６は、上記で説明されたように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
【００５７】
[0076]たとえば、イントラ予測ユニット４６は、様々なテストされるイントラ予測モードのためにレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのためのひずみおよびレートから比を計算し得る。
【００５８】
[0077]ブロックのためのイントラ予測モードを選択した後に、イントラ予測ユニット４６は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット５６に与え得る。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを送信ビットストリーム中に含め得る。
【００５９】
[0078]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。
【００６０】
[0079]いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。
【００６１】
[0080]量子化の後に、エントロピー符号化ユニット５６は量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングの後に、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。
【００６２】
[0081]逆量子化ユニット５８および逆変換ユニット６０は、たとえば、参照ブロックとして後で使用するために、ピクセル領域において残差ブロックを再構築するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット４４は、残差ブロックを参照ピクチャメモリ６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、動き推定において使用するサブ整数ピクセル値を計算するために、再構築された残差ブロックに１つまたは複数の補間フィルタを適用し得る。加算器６２は、参照ピクチャメモリ６４に記憶するための再構築されたビデオブロックを生成するために、動き補償ユニット４４によって生成された動き補償予測ブロックに再構築された残差ブロックを加算する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。
【００６３】
[0082]このようにして、図２のビデオエンコーダ２０は、現在ブロックに対する（relative to）隣接ブロックから動きベクトル情報のヒストグラムを導出し、導出されたヒストグラムに基づいて、現在ブロックのための動きベクトル予測のための動きベクトル候補リストのためのマージ候補を決定し、導出されたヒストグラムに基づいて、動きベクトル候補リストを順序付け（order）、動きベクトル候補リストを使用してマージベクトル予測を実行するように構成されたビデオコーダの一例を表す。
【００６４】
[0083]図３は、本開示の動きベクトル予測技法を実行するように構成され得るビデオデコーダ３０の一例を示すブロック図である。図３の例では、ビデオデコーダ３０は、ビデオデータメモリ７１と、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照ピクチャメモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明された符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
【００６５】
[0084]ビデオデータメモリ７１は、ビデオデコーダ３０の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ７１に記憶されるビデオデータは、たとえば、コンピュータ可読媒体１６から、たとえば、カメラなどのローカルビデオソースから、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介して、あるいは物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ７１は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ（ＣＰＢ）を形成し得る。（復号ピクチャバッファ（ＤＰＢ）とも呼ばれる）参照ピクチャメモリ８２は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオデコーダ３０によってビデオデータを復号する際に使用するための、または出力のための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ７１および参照ピクチャメモリ８２は、ＤＲＡＭ、ＳＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ７１および参照ピクチャメモリ８２は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ７１は、ビデオデコーダ３０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
【００６６】
[0085]復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他のシンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。
【００６７】
[0086]ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（たとえば、ＢＢまたはＰ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ８２に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照フレームリスト、すなわち、リスト０とリスト１とを構築し得る。
【００６８】
[0087]動き補償ユニット７２は、動きベクトルと他のシンタックス要素とをパースすることによって現在ビデオスライスのビデオブロックのための予測情報を決定し、復号されている現在ビデオブロックのための予測ブロックを生成するために、その予測情報を使用する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、ＢスライスまたはＰスライス）と、スライスのための参照ピクチャリストのうちの１つまたは複数のための構築情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつかを使用する。
【００６９】
[0088]動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、参照ブロックのサブ整数ピクセルの補間値を計算するために、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット７２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、予測ブロックを生成するためにその補間フィルタを使用し得る。
【００７０】
[0089]動き補償ユニット７２を含むビデオデコーダ３０は、図１に関して上記で説明された、および以下でより詳細に説明される本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット７２は、本開示の技法に従ってＡＭＶＰモードまたはマージモードを使用して動きベクトル予測を実行するように構成され得る。さらに、動き補償ユニット７２を含むビデオデコーダ３０は、以下でより詳細に説明される、本開示の動きベクトル候補リスト構築技法の任意の組合せを実行するように構成され得る。エントロピー復号ユニット７０は、動き情報が現在ブロックについてどのようにコーディングされるかを表す１つまたは複数のシンタックス要素を復号し得る。
【００７１】
[0090]マージモードが実行されることをシンタックス要素が示すと仮定すると、動き補償ユニット７２は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット７２は、特定の、所定の順序に基づいて候補リストに候補を追加し得る。本開示の他の例では、動き補償ユニット７２は、隣接ブロックからの動きベクトルのヒストグラム情報に基づいて、動的に異なる順序で候補リストに候補を追加するように構成され得る。動き補償ユニット７２はまた、以下でより詳細に説明されるように、追加の候補を追加し、候補リストのプルーニングを実行し得る。最終的に、動き補償ユニット７２は、現在ブロックのための動き情報をコーディングするために、それらの候補のうちのどれが使用されるかを表すマージインデックスを復号し得る。
【００７２】
[0091]逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット７０によってエントロピー復号された量子化変換係数を逆量子化、すなわち、量子化解除する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ３０によって計算される量子化パラメータＱＰYの使用を含み得る。
【００７３】
[0092]逆変換ユニット７８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
【００７４】
[0093]動き補償ユニット７２が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器８０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、他のループフィルタも（コーディングループ中またはコーディングループ後のいずれかで）使用され得る。所与のフレームまたはピクチャの復号ビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ８２に記憶される。参照ピクチャメモリ８２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上での後の提示のために、復号ビデオを記憶する。
【００７５】
[0094]このようにして、ビデオデコーダ３０は、現在ブロックに対する隣接ブロックから動きベクトル情報のヒストグラムを導出し、導出されたヒストグラムに基づいて、現在ブロックのための動きベクトル予測のための動きベクトル候補リストのためのマージ候補を決定し、導出されたヒストグラムに基づいて、動きベクトル候補リストを順序付け、動きベクトル候補リストを使用してマージベクトル予測を実行するように構成されたビデオコーダの一例を表す。
【００７６】
[0095]以下のセクションは、ビデオコーディング技法および規格のいくつかの態様について、特に、動きベクトル予測および関係する技法を考慮して説明する。最初に、動き情報が説明される。インター予測モードを使用してコーディングされるビデオデータの各ブロックについて、動き情報のセットが利用可能であり得る。動き情報のセットは、前方予測方向および後方予測方向のための動き情報を含んでいる。ここで、前方予測方向および後方予測方向は、現在ピクチャまたはスライスの参照ピクチャリスト０（ＲｅｆＰｉｃＬｉｓｔ０）と参照ピクチャリスト１（ＲｅｆＰｉｃＬｉｓｔ１）とに対応する２つの予測方向である。「前方」および「後方」という用語は、必ずしも幾何学的な意味を有するとは限らない。代わりに、それらは、動きベクトルがどの参照ピクチャリストに基づくかを区別するために使用される。前方予測は、参照リスト０に基づいて形成された予測を意味し、後方予測は、参照リスト１に基づいて形成された予測を意味する。参照リスト０と参照リスト１の両方が、所与のブロックのための予測を形成するために使用される場合、それは双方向予測と呼ばれる。
【００７７】
[0096]所与のピクチャまたはスライスについて、ただ１つの参照ピクチャリストが使用される場合、ピクチャまたはスライス内のあらゆるブロックが前方予測される。両方の参照ピクチャリストが所与のピクチャまたはスライスのために使用される場合、ピクチャまたはスライス内のブロックは、前方予測されるか、後方予測されるか、または双方向予測され得る。
【００７８】
[0097]各予測方向について、動き情報はまた、参照インデックスと動きベクトルとを含む。参照インデックスは、対応する参照ピクチャリスト（たとえばＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）中の参照ピクチャを識別するために使用される。動きベクトルは、水平成分と垂直成分の両方を有し、各成分が、それぞれ、水平方向および垂直方向に沿ったオフセット値を示す。動きベクトルは、コーディングされている現在ブロックの位置に対する予測子ブロックの位置を示す。参照インデックスは、予測子ブロック（predictor block）を含んでいるピクチャを示す。いくつかの説明では、簡単のために、「動きベクトル」という用語は、動きベクトルとそれの関連する参照インデックスの両方を示すために、動き情報と互換的に使用され得る。
【００７９】
[0098]ビデオコーディング規格において、ピクチャの表示順序を識別するためにピクチャ順序カウント（ＰＯＣ：picture order count）が広く使用されている。１つのコード化ビデオシーケンス内の２つのピクチャが同じＰＯＣ値を有し得る場合があるが、一般に、それはコード化ビデオシーケンス内で起こらない。複数のコード化ビデオシーケンスがビットストリーム中に存在するとき、ＰＯＣの同じ値をもつピクチャは、復号順序に関して互いに近いことがある。ピクチャのＰＯＣ値は、一般に、参照ピクチャリスト構築と、ＨＥＶＣの場合のような参照ピクチャセットの導出と、動きベクトルスケーリングとのために使用される。
【００８０】
[0099]次のセクションは、アドバンストビデオコーディング（ＡＶＣ）（Ｈ．２６４）におけるマクロブロック（ＭＢ）構造について説明する。Ｈ．２６４／ＡＶＣでは、各インターマクロブロック（ＭＢ）（たとえば、インター予測を使用してコーディングされるＭＢ）は、４つの異なる方法で区分され得る。
・１つの１６×１６ＭＢ区分
・２つの１６×８ＭＢ区分
・２つの８×１６ＭＢ区分
・４つの８×８ＭＢ区分
[0100]１つのＭＢ中の異なるＭＢ区分は、各予測方向について異なる参照インデックス値（ＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１）を有し得る。ＭＢが４つの８×８ＭＢ区分に区分されないとき、ＭＢは、各ＭＢ区分について各予測方向に１つの動きベクトルのみを有する。
【００８１】
[0101]ＭＢが４つの８×８ＭＢ区分に区分されるとき、各８×８ＭＢ区分は、その各々が各予測方向に異なる動きベクトルを有することができるサブブロックにさらに区分され得る。８×８ＭＢ区分をサブブロックに分割するための４つの異なる方法がある。
・１つの８×８サブブロック
・２つの８×４サブブロック
・２つの４×８サブブロック
・４つの４×４サブブロック
[0102]各サブブロックは、各予測方向に異なる動きベクトルを有し得る。したがって、動きベクトルは、サブブロックに等しいかまたはそれよりも高いレベルにおいて存在する。
【００８２】
[0103]ＡＶＣにおける時間直接モード（Temporal direct mode）は説明されない。ＡＶＣでは、時間直接モードは、Ｂスライス中のスキップまたは直接モードについてＭＢレベルまたはＭＢ区分レベルのいずれかにおいて有効にされ得る。各ＭＢ区分について、動きベクトルを導出するために、現在ブロックのＲｅｆＰｉｃＬｉｓｔ１［０］中の現在ＭＢ区分とコロケートされたブロックの動きベクトルが使用される。コロケートされたブロック中の各動きベクトルは、ＰＯＣ距離に基づいてスケーリングされる。ＡＶＣでは、直接モードはまた、空間ネイバーから動き情報を予測することができる。
【００８３】
[0104]次に、ＨＥＶＣにおけるコーディングユニット（ＣＵ）構造が説明される。ＨＥＶＣでは、スライス中の最大コーディングユニットは、コーディングツリーブロック（ＣＴＢ）またはコーディングツリーユニット（ＣＴＵ）と呼ばれる。ＣＴＢは、それのノードがコーディングユニットである４分木を含んでいる。ＣＴＢは、Ｗ．Ｊ．Ｈａｎら、「Improved Video Compression Efficiency Through Flexible Unit Representation and Corresponding Extension of Coding Tools」、ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎ  ｏｎ  Ｃｉｒｃｕｉｔｓ  ａｎｄ  Ｓｙｓｔｅｍｓ  ｆｏｒ  Ｖｉｄｅｏ  Ｔｅｃｈｎｏｌｏｇｙ、ｖｏｌ．２０、ｎｏ．１２、１７０９〜１７２０ページ、２０１０年１２月に記載され、図４に示されているように、４分木様式でＣＵに再帰的にスプリットされ得る。図４に示されているように、区分の各レベルは、４つのサブブロックにスプリットされた４分木である。黒いブロックは、リーフノード（すなわち、さらにスプリットされないブロック）の一例である。
【００８４】
[0105]（技術的に、８×８ＣＴＢサイズがサポートされ得るが）ＣＴＢのサイズは、ＨＥＶＣメインプロファイルにおいて１６×１６から６４×６４に及び得る。ＣＵは、ＣＴＢの同じサイズであり得るが、８×８程度に小さくなり得る。各ＣＵは１つのモード（たとえば、イントラ予測モードまたはインター予測モード）を用いてコーディングされる。ＣＵがインターコーディングされるとき、ＣＵは、２つまたは４つの予測ユニット（ＰＵ）にさらに区分され得るか、あるいは、さらなる区分が適用されないとき、ただ１つのＰＵになり得る。１つのＣＵ中に２つのＰＵが存在するとき、それらのＰＵは、１／２サイズの長方形、あるいはＣＵの１／４または３／４サイズである２つの長方形であり得る。
【００８５】
[0106]ＣＵがインターコーディングされるとき、各ＰＵについて動き情報の１つのセット（たとえば、動きベクトル、予測方向、および参照ピクチャ）が存在する。さらに、各ＰＵは、動き情報のセットを導出するために固有のインター予測モードを用いてコーディングされる。しかしながら、２つのＰＵが固有に（uniquely）コーディングされるさえ（even）、それらは、依然として（still）、いくつかの状況において同じ動き情報を有し得ることを理解されたい。
【００８６】
[0107]ＨＥＶＣでは、図５に示されているように、インター予測モードを用いてコーディングされるＣＵのための８つの区分モード（partition mode）、すなわち、ＰＡＲＴ＿２Ｎ×２Ｎ、ＰＡＲＴ＿２Ｎ×Ｎ、ＰＡＲＴ＿Ｎ×２Ｎ、ＰＡＲＴ＿Ｎ×Ｎ、ＰＡＲＴ＿２Ｎ×ｎＵ、ＰＡＲＴ＿２Ｎ×ｎＤ、ＰＡＲＴ＿ｎＬ×２Ｎ、およびＰＡＲＴ＿ｎＲ×２Ｎがある。区分モードＰＡＲＴ＿２Ｎ×２Ｎを用いてコーディングされるＣＵは、さらにスプリットされない。すなわち、ＣＵ全体が単一のＰＵ（ＰＵ０）として扱われる。区分モードＰＡＲＴ＿２Ｎ×Ｎを用いてコーディングされるＣＵは、対称的に水平方向に（horizontally）２つのＰＵ（ＰＵ０およびＰＵ１）にスプリットされる。区分モードＰＡＲＴ＿Ｎ×２Ｎを用いてコーディングされるＣＵは、対称的に垂直方向に２つのＰＵにスプリットされる。区分モードＰＡＲＴ＿Ｎ×Ｎを用いてコーディングされるＣＵは、対称的に４つの等しいサイズのＰＵ（ＰＵ０、ＰＵ１、ＰＵ２、ＰＵ３）にスプリットされる。
【００８７】
[0108]区分モードＰＡＲＴ＿２Ｎ×ｎＵを用いてコーディングされるＣＵは、非対称的に水平方向に、ＣＵの１／４のサイズを有する１つのＰＵ０（上側ＰＵ）と、ＣＵの３／４のサイズを有する１つのＰＵ１（下側ＰＵ）とにスプリットされる。区分モードＰＡＲＴ＿２Ｎ×ｎＤを用いてコーディングされるＣＵは、非対称的に水平方向に、ＣＵの３／４のサイズを有する１つのＰＵ０（上側ＰＵ）と、ＣＵの１／４のサイズを有する１つのＰＵ１（下側ＰＵ）とにスプリットされる。区分モードＰＡＲＴ＿ｎＬ×２Ｎを用いてコーディングされるＣＵは、非対称的に垂直方向に、ＣＵの１／４のサイズを有する１つのＰＵ０（左ＰＵ）と、ＣＵの３／４のサイズを有する１つのＰＵ１（右ＰＵ）とにスプリットされる。区分モードＰＡＲＴ＿ｎＲ×２Ｎを用いてコーディングされるＣＵは、非対称的に垂直方向に、ＣＵの３／４のサイズを有する１つのＰＵ０（左ＰＵ）と、ＣＵの１／４のサイズを有する１つのＰＵ１（右ＰＵ）とにスプリットされる。
【００８８】
[0109]ＨＥＶＣは４分木区分構造を使用するが、将来のビデオコーディング規格のために他の区分構造が研究されている。たとえば、Ｊ．Ａｎら、「Block partitioning structure for next generation video coding」、国際電気通信連合、ＣＯＭ１６−Ｃ９６６、２０１５年９月（以下、「ＶＣＥＧ提案ＣＯＭ１６−Ｃ９６６」）では、４分木２分木（ＱＴＢＴ）区分技法が、ＨＥＶＣ以外の（beyond）将来のビデオコーディング規格（たとえば、Ｈ．２６６）のために提案された。シミュレーションは、提案されたＱＴＢＴ構造が、いくつかのビデオシーケンスについて、使用されるＨＥＶＣにおける４分木構造よりも効率的であることを示した。
【００８９】
[0110]ＶＣＥＧ提案ＣＯＭ１６−Ｃ９６６の提案されたＱＴＢＴ構造では、４分木分割技法を使用してＣＴＢが最初に区分され、ここで、１つのノードの４分木スプリッティングは、ノードが最小許容４分木リーフノードサイズに達するまで反復され得る。最小許容４分木リーフノードサイズは、シンタックス要素ＭｉｎＱＴＳｉｚｅの値によってビデオデコーダに示され得る。４分木リーフノードサイズが（たとえば、シンタックス要素ＭａｘＢＴＳｉｚｅによって示される）最大許容２分木ルートノードサイズよりも大きくない場合、４分木リーフノードは、２分木区分を使用してさらに区分され得る。１つのノードの２分木区分は、ノードが、（たとえば、シンタックス要素ＭｉｎＢＴＳｉｚｅによって示されるように）最小許容２分木リーフノードサイズ、または（たとえば、シンタックス要素ＭａｘＢＴＤｅｐｔｈによって示されるように）最大許容２分木深度に達するまで、反復され得る。ＶＣＥＧ提案ＣＯＭ１６−Ｃ９６６は、２分木リーフノードを指すために「ＣＵ」という用語を使用する。ＶＣＥＧ提案ＣＯＭ１６−Ｃ９６６では、ＣＵは、任意のさらなる区分なしに予測（たとえば、イントラ予測、インター予測など）および変換のために使用される。概して、ＱＴＢＴ技法によれば、２分木スプリッティングのための２つのスプリットタイプ、すなわち、対称水平スプリッティングおよび対称垂直スプリッティングがある。各場合において、ブロックは、ブロックを水平方向または垂直方向のいずれかに半分に（down the middle）分割することによってスプリットされる。
【００９０】
[0111]ＱＴＢＴ区分構造の一例では、ＣＴＵサイズは１２８×１２８（たとえば、１２８×１２８ルーマブロックおよび２つの対応する６４×６４クロマブロック）として設定され、ＭｉｎＱＴＳｉｚｅは１６×１６として設定され、ＭａｘＢＴＳｉｚｅは６４×６４として設定され、（幅と高さの両方のための）ＭｉｎＢＴＳｉｚｅは４として設定され、ＭａｘＢＴＤｅｐｔｈは４として設定される。４分木区分は、４分木リーフノードを生成するために最初にＣＴＵに適用される。４分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅが１６×１６である）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを有し得る。ＱＴＢＴ区分の一例によれば、リーフ４分木ノードが１２８×１２８である場合、リーフ４分木ノードのサイズがＭａｘＢＴＳｉｚｅ（すなわち、６４×６４）を超えるので、リーフ４分木ノードは２分木によってさらにスプリットされ得ない。他の場合（Otherwise）、リーフ４分木ノードは、２分木によってさらに区分される。したがって、４分木リーフノードはまた、２分木のためのルートノードであり、０としての２分木深度を有する。２分木深度がＭａｘＢＴＤｅｐｔｈ（たとえば、４）に達することは、さらなるスプリッティングがないことを暗示する。２分木ノードが、ＭｉｎＢＴＳｉｚｅ（たとえば、４）に等しい幅を有することは、さらなる水平スプリッティングがないことを暗示する。同様に、２分木ノードが、ＭｉｎＢＴＳｉｚｅに等しい高さを有することは、さらなる垂直スプリッティングがないことを暗示する。２分木のリーフノード（ＣＵ）は、任意の（any）さらなる区分なしに（たとえば、予測プロセスおよび変換プロセスを実行することによって）さらに処理される。
【００９１】
[0112]図６Ａは、ＱＴＢＴ区分技法を使用して区分されるブロック１５０（たとえば、ＣＴＢ）の一例を示す。図６Ａに示されているように、ＱＴＢＴ区分技法を使用して、得られた（resultant）ブロックの各々が、各ブロックの中心を通って対称的にスプリットされる。図６Ｂは、図６Ａのブロック区分に対応するツリー構造を示す。図６Ｂ中の実線は４分木スプリッティングを示し、点線は２分木スプリッティングを示す。一例では、２分木の各スプリッティング（すなわち、非リーフ）ノードでは、実行されるスプリッティングのタイプ（たとえば、水平または垂直）を示すために、シンタックス要素（たとえば、フラグ）がシグナリングされ、ここで、０は水平スプリッティングを示し、１は垂直スプリッティングを示す。４分木スプリッティングの場合、４分木スプリッティングが、常に、ブロックを、等しいサイズをもつ４つのサブブロックに水平および垂直にスプリットするので（as）、スプリッティングタイプを示す必要がない。
【００９２】
[0113]図６Ｂに示されているように、ノード１７０において、ブロック１５０は、ＱＴ区分を使用して、図６Ａに示されている４つのブロック１５１、１５２、１５３、および１５４にスプリットされる。ブロック１５４はさらにスプリットされず、したがってリーフノードである。ノード１７２において、ブロック１５１は、ＢＴ区分を使用して２つのブロックにさらにスプリットされる。図６Ｂに示されているように、ノード１７２は、垂直スプリッティングを示す１でマークされる。したがって、ノード１７２におけるスプリッティングは、ブロック１５７、およびブロック１５５とブロック１５６の両方を含むブロックを生じる（results in）。ブロック１５５および１５６は、ノード１７４において、さらなる垂直スプリッティングによって作成される。ノード１７６において、ブロック１５２は、ＢＴ区分を使用して２つのブロック１５８および１５９にさらにスプリットされる。図６Ｂに示されているように、ノード１７６は、水平スプリッティングを示す１でマークされる。
【００９３】
[0114]ノード１７８において、ブロック１５３は、ＱＴ区分を使用して４つの等しいサイズのブロックにスプリットされる。ブロック１６３および１６６は、このＱＴ区分から作成され、さらにスプリットされない。ノード１８０において、左上ブロックは、垂直２分木スプリッティングを使用して最初にスプリットされ、ブロック１６０および右垂直ブロックを生じる。右垂直ブロックは、次いで、水平２分木スプリッティングを使用して、ブロック１６１とブロック１６２とにスプリットされる。ノード１７８において４分木スプリッティングから作成される右下ブロックは、ノード１８４において、水平２分木スプリッティングを使用してブロック１６４とブロック１６５とにスプリットされる。
【００９４】
[0115]以下でより詳細に説明される動きベクトル候補リスト構築技法は、Ｈ．２６４／ＡＶＣのＭＢ区分構造、ＨＥＶＣの４分木区分構造、またはＨ．２６６のために提案されるＱＴＢＴ構造などのＱＴＢＴ区分構造を含む、任意のビデオブロック区分技法とともに（in conjunction with）使用され得る。
【００９５】
[0116]次に、ＨＥＶＣにおける動き予測が説明される。ＨＥＶＣ規格では、それぞれ、マージモード（スキップはマージの特殊な場合と見なされる）および高度動きベクトル予測（ＡＭＶＰ）モードと称される、ＰＵのための２つのインター予測モードがある。ＡＭＶＰモードまたはマージモードのいずれかでは、ビデオエンコーダ２０およびビデオデコーダ３０は、複数の動きベクトル予測子のための動きベクトル（ＭＶ）候補リストを構築するように構成される。動きベクトル予測子は、隣接ブロックからの動きベクトルであるか、または人工的に生成された動きベクトルであり得、それらは、ビデオデータの現在コーディングされているブロックのための動きベクトルを予測するために使用され得る。マージモードの場合、現在ブロック自体の動きベクトルを符号化するのではなく、ビデオエンコーダ２０は、動きベクトル候補リストからの１つの動きベクトル、ならびにその候補に関連する参照インデックスを選択し、インター予測のためにその候補動きベクトルを使用する。ビデオエンコーダ２０は、選択された動きベクトル候補のインデックス（たとえば、マージインデックス）をビデオデコーダ３０にシグナリングし得る。ビデオデコーダ３０は、ビデオエンコーダ２０と同じ様式でマージモードのための動きベクトル候補リストを構築し得る。ビデオデコーダ３０は、選択された候補を識別するために、動きベクトル候補リスト中へのシグナリングされたインデックスを使用し、次いで、現在ブロックのための動きベクトルとして使用するために動きベクトルとその候補に関連する参照インデックスとを取り出し得る。
【００９６】
[0117]ＭＶ候補リストは、マージモードのための最高５つの候補とＡＭＶＰモードのための２つの候補とを含んでいる。マージ候補は、動き情報のセット、たとえば、参照ピクチャリスト（リスト０およびリスト１）と参照インデックスの両方に対応する動きベクトルを含んでいることがある。マージ候補がマージインデックスによって識別された場合、参照ピクチャは現在ブロックの予測のために使用され、ならびに、関連する動きベクトルが決定される。しかしながら、リスト０またはリスト１のいずれかからの各潜在的予測方向についてのＡＭＶＰモード下で、参照インデックスは、ＡＭＶＰ候補が動きベクトルのみを含んでいるので、ＭＶ候補リストへの動きベクトル予測子（ＭＶＰ）インデックスとともに明示的にシグナリングされる。ＡＭＶＰモードでは、予測される動きベクトルはさらに改良され得る。ＡＭＶＰのいくつかの例では、ビデオエンコーダ２０はまた、動きベクトル差分（ＭＶＤ：motion vector difference）をシグナリングし得る。ＭＶＤは、現在ブロックのための選択されたＭＶＰと実際の決定された動きベクトルとの間の差分である。上記でわかるように、マージ候補は動き情報のフルセットに対応し、ＡＭＶＰ候補は、特定の予測方向および参照インデックスのためのただ１つの動きベクトルを含んでいる。
【００９７】
[0118]図７は、ＨＥＶＣにおける空間隣接候補を示す概念図である。空間ＭＶ候補は、特定のＰＵ（ＰＵ０）について、図７上に示されている隣接ブロックから導出されるが、ブロックから候補を生成する方法は、マージモードおよびＡＭＶＰモードについて異なる。
【００９８】
[0119]マージモードでは、図７（ａ）に示されている順序で、最高４つの空間ＭＶ候補が導出され得る。順序は、図７（ａ）に示されているように、左（０，Ａ１）、上（１，Ｂ１）、右上（２，Ｂ０）、左下（３，Ａ０）、および左上（４，Ｂ２）である。すなわち、図７（ａ）では、ブロック２００はＰＵ０  ２０４ＡとＰＵ１  ２０４Ｂとを含む。ビデオコーダ（たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０）が、マージモードを使用してＰＵ０  ２０４Ａのための動き情報をコーディングすべきであるとき、ビデオコーダは、空間隣接ブロック２０８Ａ、２０８Ｂ、２０８Ｃ、２０８Ｄ、および２０８Ｅからの動き情報を、その順序で候補リストに追加する。ブロック２０８Ａ、２０８Ｂ、２０８Ｃ、２０８Ｄ、および２０８Ｅは、ＨＥＶＣにおいて、それぞれ、ブロックＡ１、Ｂ１、Ｂ０、Ａ０、およびＢ２と呼ばれることもある。
【００９９】
[0120]ＡＶＭＰモードでは、隣接ブロックは、２つのグループ、すなわち、図７（ｂ）上に示されているように、ブロック０および１を含む左グループと、ブロック２、３、および４を含む上グループとに分割される。これらのブロックは、それぞれ、図７（ｂ）中でブロック２１０Ａ、２１０Ｂ、２１０Ｃ、２１０Ｄ、および２１０Ｅと標示される。ブロック２０２は、ＰＵ０  ２０６ＡとＰＵ１  ２０６Ｂとを含み、ブロック２１０Ａ、２１０Ｂ、２１０Ｃ、２１０Ｄ、および２１０Ｅは、ＰＵ０  ２０６Ａに対する空間ネイバーを表す。各グループについて、シグナリングされた参照インデックスによって示された参照ピクチャと同じ参照ピクチャを参照する隣接ブロック中の潜在的候補は、グループの最終候補を形成するために選定されるべき最高優先度を有する。すべての隣接ブロックが、同じ参照ピクチャを指す動きベクトルを含んでいるとは限らない可能性がある。したがって、そのような候補が見つけられ得ない場合、第１の利用可能な候補は、最終候補を形成するためにスケーリングされることになり、したがって、時間距離差分が補償され得る。
【０１００】
[0121]図８は、ＨＥＶＣにおける時間動きベクトル予測（ＴＭＶＰ）を示す概念図である。特に、図８（ａ）は、ＰＵ０  ２２２ＡとＰＵ１  ２２２Ｂとを含む例示的なＣＵ２２０を示す。ＰＵ０  ２２２Ａは、ＰＵ２２２Ａのための中心ブロック２２６とＰＵ０  １２２Ａに対する右下ブロック２２４とを含む。図８（ａ）はまた、以下で説明されるように、動き情報がＰＵ０  ２２２Ａの動き情報からそれについて予測され得る外部ブロック２２８を示す。図８（ｂ）は、動き情報がそれについて予測されるべきである現在ブロック２３８を含む現在ピクチャ２３０を示す。特に、図８（ｂ）は、（現在ブロック２３８に対するコロケートされたブロック２４０を含む）現在ピクチャ２３０に対するコロケートされたピクチャ２３４と、現在参照ピクチャ２３２と、コロケートされた参照ピクチャ２３６とを示す。コロケートされたブロック２４０は、ブロック２３８の動き情報のための時間動きベクトル予測子（ＴＭＶＰ：temporal motion vector predictor）２４２として使用される、動きベクトル２４４を使用して予測される。
【０１０１】
[0122]ビデオコーダ（たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０）は、ＴＭＶＰが有効にされ、ＴＭＶＰ候補が利用可能である場合、ＴＭＶＰ候補（たとえば、ＴＭＶＰ候補２４２）を、任意の空間動きベクトル候補の後にＭＶ候補リストに追加し得る。ＴＭＶＰ候補のための動きベクトル導出のプロセスは、マージモードとＡＭＶＰモードの両方について同じである。しかしながら、マージモードでのＴＭＶＰ候補のためのターゲット参照インデックスは、ＨＥＶＣに従って、０に設定される。
【０１０２】
[0123]ＴＭＶＰ候補導出のための１次ブロックロケーションは、空間隣接候補を生成するために使用される上および左ブロックへのバイアスを補償するための、ＰＵ０  ２２２Ａに対するブロック２２４として図８（ａ）に示されているような、コロケートされたＰＵの外側の右下ブロックである。しかしながら、ブロック２２４が現在ＣＴＢ行の外側に位置するか、または、動き情報がブロック２２４のために利用可能でない場合、ブロックは、図８（ａ）に示されているようにＰＵの中心ブロック２２６と置換される。ＴＭＶＰ候補２４２のための動きベクトルは、スライスレベル情報に示されているように、コロケートされたピクチャ２３４のコロケートされたブロック２４０から導出される。
【０１０３】
[0124]ＡＶＣにおける時間直接モードと同様に、ＴＭＶＰ候補の動きベクトルは、動きベクトルスケーリングを受けることがあり、動きベクトルスケーリングは、現在ピクチャ２３０と現在参照ピクチャ２３２との間の、およびコロケートされたピクチャ２３４とコロケートされた参照ピクチャ２３６との間のＰＯＣ距離差分を補償するために実行される。すなわち、動きベクトル２４４は、これらのＰＯＣ差分に基づいて、ＴＭＶＰ候補２４２を生成するためにスケーリングされ得る。ＨＥＶＣにおける動き予測の他の態様が以下で説明される。
【０１０４】
[0125]動きベクトルスケーリングがＨＥＶＣにおいて実行され得る。動きベクトルの値はプレゼンテーション時間におけるピクチャの距離に比例すると仮定される。動きベクトルは、２つのピクチャ、すなわち、参照ピクチャと、動きベクトルを含んでいるピクチャ（すなわち、含有ピクチャ（containing picture））とを関連付ける。他の動きベクトルを予測するために動きベクトルが利用されるとき、含有ピクチャと参照ピクチャとの距離は、ピクチャ順序カウント（ＰＯＣ）値に基づいて計算される。
【０１０５】
[0126]予測されるべき動きベクトルについて、それの関連する含有ピクチャと参照ピクチャの両方は異なり得る。したがって、（ＰＯＣに基づく）新しい距離が計算される。また、動きベクトルは、これらの２つのＰＯＣ距離に基づいてスケーリングされる。空間隣接候補では、２つの動きベクトルのための含有ピクチャは同じであるが、参照ピクチャは異なる。ＨＥＶＣでは、動きベクトルスケーリングは、空間および時間隣接候補のためにＴＭＶＰとＡＭＶＰの両方に適用される。
【０１０６】
[0127]また、擬似動きベクトル候補生成が、ＨＥＶＣにおいて実行され得る。動きベクトル候補リストが完全でない（たとえば、候補の規定された（prescribed）数よりも少ない候補を含む）場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は擬似動きベクトル候補を生成し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、動きベクトル候補リストが規定された数の候補を有するまで、擬似（artificial）動きベクトル候補を生成し、動きベクトル候補リストの最後に挿入する。
【０１０７】
[0128]マージモードでは、２つのタイプの擬似ＭＶ候補、すなわち、Ｂスライスのために導出される双方向組合せ擬似動きベクトル候補と、第１のタイプ（すなわち、組合せ擬似動きベクトル候補）が候補リストを満たすのに十分な擬似候補を与えない場合にＡＭＶＰのみ使用される０動きベクトル候補とがあり得る。
【０１０８】
[0129]すでに候補リスト中にあり、必要な動き情報を有する候補の各ペアについて、双方向組合せ動きベクトル候補が、リスト０中のピクチャを参照する第１の候補の動きベクトルとリスト１中のピクチャを参照する第２の候補の動きベクトルとの組合せによって導出される。０動きベクトル候補は、単に、別のピクチャ中のコロケートされたブロックを指す（たとえば、０動きベクトル候補は（０，０）である）。
【０１０９】
[0130]また、ＨＥＶＣに従って構成されたビデオコーダは、候補挿入のためのプルーニングプロセスを実行し得る。異なるブロックからの動きベクトル候補は偶然同じであり得、これはマージ／ＡＭＶＰ候補リストの効率を減少させる。すなわち、同じ値をもつ複数の（multiple）動きベクトル候補を有することは、テストおよび選択すべき動きベクトルの実際の数を減少させる。この問題を解決するために、プルーニングプロセスが適用され得る。プルーニングプロセスは、いくつかの状況において同等の候補を挿入することを回避するために、現在候補リスト中のある動きベクトル候補を他の動きベクトル候補と比較する。複雑さを低減するために、各潜在的な動きベクトル候補（one）をすべての他の既存の動きベクトル候補（one）と比較する代わりに、限られた数のプルーニングプロセスのみが適用される。
【０１１０】
[0131]図９は、３Ｄ−ＨＥＶＣのための例示的な予測構造を示す。３Ｄ−ＨＥＶＣは、ＪＣＴ−３Ｖによって開発中のＨＥＶＣの３Ｄビデオ拡張である。本開示の技法に関係するいくつかの技法が、以下の図９および図１０に関して説明される。図９は、３つのビューの場合のマルチビュー予測構造を示す。Ｖ３はベースビューを示し、非ベースビュー（Ｖ１またはＶ５）中のピクチャは、同じ時間インスタンスの従属（ベース）ビュー中のピクチャから予測され得る。（再構築されたサンプルからの）インタービューサンプル予測がマルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）においてサポートされ、それの一般的な予測構造が図１０に示される。
【０１１１】
[0132]ＭＶ−ＨＥＶＣと３Ｄ−ＨＥＶＣの両方は、ベース（テクスチャ）ビューがＨＥＶＣ（バージョン１）デコーダによって復号可能であるようにＨＥＶＣに適合する。ＭＶ−ＨＥＶＣおよび３Ｄ−ＨＥＶＣのためのテストモデルは、２０１５年１月２６日現在、ウェブサイトmpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding/test-model-6-3d-hevc-and-mv-hevcにおいて入手可能な、Ｚｈａｎｇら、「Test Model 6 of 3D-HEVC and MV-HEVC」、ＪＣＴ−３ＶドキュメントＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１  Ｎ１３９４０に記載されている。
【０１１２】
[0133]ＭＶ−ＨＥＶＣでは、非ベースビュー中の現在ピクチャは、同じビュー中のピクチャと同じ時間インスタンスの参照ビュー中のピクチャの両方のすべてをそのピクチャの参照ピクチャリスト中に入れることによって、これらのピクチャによって予測され得る。したがって、現在ピクチャの参照ピクチャリストは、時間参照ピクチャとインタービュー参照ピクチャの両方を含んでいる。時間参照ピクチャに対応する参照インデックスに関連する動きベクトルは、時間動きベクトルと示される。インタービュー参照ピクチャに対応する参照インデックスに関連する動きベクトルは、ディスパリティ動きベクトルと示される。３Ｄ−ＨＥＶＣはＭＶ−ＨＥＶＣにおけるすべての特徴をサポートする。したがって、上述のようなインタービューサンプル予測が有効にされる。
【０１１３】
[0134]追加として、３Ｄ−ＨＥＶＣでは、より高度のテクスチャオンリーコーディングツール（texture only coding tool）および深度関係／依存コーディングツール（depth related/dependent coding tool）がサポートされる。テクスチャオンリーコーディングツールは、しばしば、同じオブジェクトに属し得る（ビュー間の）対応するブロックの識別を使用する。したがって、ディスパリティベクトル導出は、３Ｄ−ＨＥＶＣにおいて使用される１つの技法である。
【０１１４】
[0135]図１０は、３Ｄ−ＨＥＶＣにおけるサブＰＵベースインタービュー動き予測を示す概念図である。図１０は、現在ビュー（Ｖ１）の現在ピクチャ３６０と参照ビュー（Ｖ０）中のコロケートされたピクチャ３６２とを示す。現在ピクチャ３６０は、４つのサブＰｕ３６６Ａ〜３６６Ｄ（サブＰＵ３６６）を含む現在ＰＵ３６４を含む。それぞれのディスパリティベクトル３７４Ａ〜３７４Ｄ（ディスパリティベクトル３７４）は、コロケートされたピクチャ３６２中の、サブＰＵ３６６への対応するサブＰＵ３６８Ａ〜３６８Ｄを識別する。３Ｄ−ＨＥＶＣでは、サブＰＵレベルインタービュー動き予測方法は、インタービューマージ候補、すなわち、参照ビュー中の参照ブロックから導出された候補のために使用される。
【０１１５】
[0136]そのようなモードが有効にされるとき、現在ＰＵ３６４は、参照ビュー中の（ディスパリティベクトルによって識別される現在ＰＵと同じサイズをもつ）参照エリアに対応し得、参照エリアは、ＰＵのための動き情報の１つのセット生成のために必要とされるよりも豊富な動き情報（たとえば、多くの異なる関連する動きベクトル）を有し得る。したがって、図１０に示されているように、サブＰＵレベルインタービュー動き予測（ＳＰＩＶＭＰ：sub-PU level inter-view motion prediction）方法が使用され得る。このモードはまた、特殊マージ候補としてシグナリングされ得る。サブＰＵの各々は、動き情報のフルセットを含んでいる。したがって、ＰＵは、動き情報の複数のセットを含んでいることがある。
【０１１６】
[0137]また、３Ｄ−ＨＥＶＣにおいて、サブＰＵベース動きパラメータ継承（ＭＰＩ：Motion Parameter Inheritance）が使用され得る。３Ｄ−ＨＥＶＣの深度コーディングでは、テクスチャビューから導出されたＭＰＩ候補も、サブＰＵレベルインタービュー動き予測と同様の方法で拡張され得る。たとえば、現在深度ＰＵが、複数のＰＵを含んでいるコロケートされた領域を有する場合、現在深度ＰＵはサブＰＵに分離され得、各サブＰＵが動き情報の異なるセットを有し得る。この方法は、サブＰＵ  ＭＰＩと呼ばれる。
【０１１７】
[0138]２Ｄビデオコーディングのための例示的なサブＰＵ関係技法は、その全体が参照により本明細書に組み込まれる、２０１４年９月２５日に出願された米国出願第１４／４９７，１２８号に記載されている。米国出願第１４／４９７，１２８号では、サブＰＵベース高度ＴＭＶＰ（ＡＴＭＶＰ）設計が提案された。
【０１１８】
[0139]シングルレイヤコーディングでは、２段高度時間動きベクトル予測（advanced temporal motion vector prediction）設計が使用され得る。第１の段は、参照ピクチャ中の現在予測ユニット（ＰＵ）の対応するブロックを識別するベクトルを導出するために利用され、第２の段は、対応するブロックから複数のセット動き情報を抽出し、それらをＰＵのサブＰＵに割り当てることである。ＰＵの各サブＰＵは、したがって、別々に動き補償される。ＡＴＭＶＰの概念は以下のように要約される。（１）第１の段におけるベクトルは、現在ＰＵの空間および時間隣接ブロックから導出され得る。（２）このプロセスは、すべての他のマージ候補のうちのマージ候補をアクティブにすることとして達成され得る。シングルレイヤコーディングおよびサブＰＵ時間動きベクトル予測に適用可能であるが、ＰＵまたはＣＵは、予測子の上で伝達されるべき動き改良データを有し得る。
【０１１９】
[0140]米国出願第１４／４９７，１２８号のいくつかの態様は、以下のようにハイライトされる。
１．ベクトル導出の第１の段はまた、ただ０ベクトルによって簡略化され得る。
２．ベクトル導出の第１の段は、動きベクトルとそれの関連するピクチャとを一緒に識別することを含み得る。関連するピクチャを選択し、さらに、動きベクトルが第１段ベクトルであると決める、様々な方法が提案されている。
３．上記のプロセス中の動き情報が利用不可能である場合、「第１段ベクトル」は、置換のために使用される。
４．時間ネイバーから識別された動きベクトルは、ＴＭＶＰにおける動きベクトルスケーリングと同様の方法で、現在サブＰＵのために使用されるようにスケーリングされ得る。しかしながら、そのような動きベクトルがどの参照ピクチャにスケーリングされ得るかは、以下の方法のうちの１つを用いて設計され得る。
【０１２０】
ａ．そのピクチャは、現在ピクチャの固定参照インデックスによって識別される。
【０１２１】
ｂ．そのピクチャは、現在ピクチャの参照ピクチャリスト中でも利用可能である場合、対応する時間ネイバーの参照ピクチャであると識別される。
【０１２２】
ｃ．そのピクチャは、第１の段において、および動きベクトルがそこから捕捉された場所から識別された、コロケートされたピクチャであるように設定される。
【０１２３】
[0141]米国出願第１４／４９７，１２８号におけるいくつかの設計問題に対処するために、内容全体が参照により本明細書に組み込まれる、２０１６年１月２５日に出願された米国出願第１５／００５，５６４号において以下の技法が提案された。
【０１２４】
１．たとえば、マージ候補リストとして、挿入される場合の、ＡＴＭＶＰ候補の位置
ａ．空間候補およびＴＭＶＰ候補が、ある順序でマージ候補リストに挿入されると仮定する。ＡＴＭＶＰ候補は、それらの候補の任意の比較的固定された位置中に挿入され得る。
【０１２５】
ｉ．一代替では、たとえば、ＡＴＭＶＰ候補は、第１の２つの空間候補、たとえば、Ａ１およびＢ１の後にマージ候補リストに挿入され得る。
【０１２６】
ｉｉ．一代替では、たとえば、ＡＴＭＶＰ候補は、第１の３つの空間候補、たとえば、Ａ１およびＢ１およびＢ０の後に挿入され得る。
【０１２７】
ｉｉｉ．一代替では、たとえば、ＡＴＭＶＰ候補は、第１の４つの候補、たとえば、Ａ１、Ｂ１、Ｂ０、およびＡ０の後に挿入され得る。
【０１２８】
ｉｖ．一代替では、たとえば、ＡＴＭＶＰ候補は、ＴＭＶＰ候補の直前に挿入され得る。
【０１２９】
ｖ．一代替的にでは、たとえば、ＡＴＭＶＰ候補は、ＴＭＶＰ候補の直後に挿入され得る。
【０１３０】
ｂ．代替的に、候補リスト中のＡＴＭＶＰ候補の位置は、ビットストリーム中でシグナリングされ得る。さらに、ＴＭＶＰ候補を含む他の候補の位置がシグナリングされ得る。
【０１３１】
２．動き情報のただ１つのセットにアクセスすることによって、ＡＴＭＶＰ候補の利用可能性検査が適用され得る。情報のそのようなセットが利用不可能であり、たとえば、１つのブロックがイントラコーディングされるとき、全ＡＴＭＶＰ候補が利用不可能であると見なされる。その場合、ＡＴＭＶＰはマージリストに挿入されない。
【０１３２】
ａ．純粋に、ＡＴＭＶＰ候補の利用可能性を検査するために、中心位置、または中心サブＰＵが使用される。中心サブＰＵが使用されるとき、中心サブＰＵは、中心位置（たとえば、ＰＵの左上サンプルに対する（Ｗ／２，Ｈ／２）の相対座標をもつ、中心３位置、ここにおいて、Ｗ×ＨはＰＵのサイズである）をカバーするものであるように選定される。そのような位置または中心サブＰＵは、動きソースピクチャ中の対応するブロックを識別するために、時間ベクトルとともに使用され得る。対応するブロックの中心位置をカバーするブロックからの動き情報のセットが識別される。
【０１３３】
３．サブＰＵからのＡＴＭＶＰコード化ＰＵのための動き情報の代表的セット。
【０１３４】
ａ．ＡＴＭＶＰ候補を形成するために、動き情報の代表的セットは、最初に形成される。
【０１３５】
ｂ．動き情報のそのような代表的セットは、固定位置または固定サブＰＵから導出され得る。それは、箇条２に記載されているように、ＡＴＭＶＰ候補の利用可能性を決定するために使用される動き情報のセットのそれと同様の方法で選定され得る。
【０１３６】
ｃ．サブＰＵが動き情報のそれ自体のセットを識別しており、利用不可能であるとき、それは、動き情報の代表的セットに等しくなるように設定される。
【０１３７】
ｄ．動き情報の代表的セットがサブＰＵのそれであるように設定される場合、追加の動き記憶は、ワーストケースシナリオにおいて現在ＣＴＵまたはスライスのためにデコーダ側において必要とされない。
【０１３８】
ｅ．動き情報のそのような代表的セットは、プルーニングを含めて、動き情報の１つのセットによって全ＰＵが表されることを復号プロセスが要求するとき、そのプロセスが、組合せ双予測マージング候補を生成するために使用されるように、すべてのシナリオにおいて使用される。
【０１３９】
４．ＡＴＭＶＰ候補がＴＭＶＰ候補を用いてプルーニングされ、ＴＭＶＰとＡＴＭＶＰとの間の相互作用が考慮され得、詳細な技法が以下に記載される。
【０１４０】
ａ．通常候補を用いた、サブＰＵベース候補、たとえば、ＡＴＭＶＰ候補のプルーニングは、そのようなサブＰＵベース候補について（箇条３の場合のように）動き情報の代表的セットを使用することによって行われ得る。動き情報のそのようなセットが通常マージ候補と同じである場合、２つの候補は同じであると見なされる。
【０１４１】
ｂ．代替的に、追加として、ＡＴＭＶＰが複数のサブＰｕのための動き情報の複数の異なるセットを含んでいるかどうかを決定するために、検査が実行され、少なくとも２つの異なるセットが識別された場合、サブＰＵベース候補は、プルーニングのために使用されず、すなわち、他の候補とは異なると見なされる。他の場合、それは、プルーニングのために使用され得る（たとえば、プルーニングプロセス中にプルーニングされ得る）。
【０１４２】
ｃ．代替的に、追加として、ＡＴＭＶＰ候補は、Ａ１およびＢ１として示された位置をもつ、空間候補、たとえば、左および上の空間候補のみを用いてプルーニングされ得る。
【０１４３】
ｄ．代替的に、ＡＴＭＶＰ候補またはＴＭＶＰ候補のいずれかである、１つの候補のみが、時間参照から形成される。ＡＴＭＶＰが利用可能であるとき、候補はＡＴＭＶＰであり、他の場合、候補はＴＭＶＰである。そのような候補は、ＴＭＶＰの位置と同様の位置においてマージ候補リストに挿入される。この場合、候補の最大数は、不変であるように保たれ得る。
【０１４４】
ｉ．代替的に、ＴＭＶＰは、ＡＴＭＶＰが利用不可能であるときでも常に無効にされる。
【０１４５】
ｉｉ．代替的に、ＴＭＶＰは、ＡＴＭＶＰが利用不可能であるときのみ使用される。
【０１４６】
ｅ．代替的に、ＡＴＭＶＰが利用可能であり、ＴＭＶＰが利用不可能であるとき、１つのサブＰＵの動き情報の１つのセットがＴＭＶＰ候補として使用される。この場合、さらに、ＡＴＭＶＰとＴＭＶＰとの間のプルーニングプロセスは適用されない。
【０１４７】
ｆ．また、代替または追加として、ＡＴＭＶＰのために使用される時間ベクトルは、ＨＥＶＣにおいて現在ＴＭＶＰのために使用されるような右下位置または中心３位置が使用される必要がないように、ＴＭＶＰのために使用され得る。
【０１４８】
ｉ．代替的に、時間ベクトルによって識別された位置ならびに右下および中心３位置は、一緒に、利用可能なＴＭＶＰ候補を与えると見なされる。
【０１４９】
５．ＡＴＭＶＰに対する複数の利用可能性検査は、ＡＴＭＶＰ候補がより正確で効率的となる、より高い可能性を与えるためにサポートされる。（たとえば、図９に示されているように）第１の時間ベクトルによって識別されるような動きソースピクチャからの現在ＡＴＭＶＰ候補が利用不可能であるとき、他のピクチャは動きソースピクチャと見なされ得る。別のピクチャが考慮されるとき、それは、異なる第２の時間ベクトルに関連し得るか、または、単に、利用不可能なＡＴＭＶＰ候補を指す第１の時間ベクトルからスケーリングされる第２の時間ベクトルに関連し得る。
【０１５０】
ａ．第２の時間ベクトルは、第２の動きソースピクチャ中のＡＴＭＶＰ候補を識別することができ、同じ利用可能性検査が適用され得る。第２の動きソースピクチャから導出されるようなＡＴＭＶＰ候補が利用可能である場合、ＡＴＭＶＰ候補が導出され、他のいかなるピクチャも検査される必要がなく、他の場合、動きソースピクチャとしての他のピクチャが検査される必要がある。
【０１５１】
ｂ．検査されるべきピクチャは、所与の順序をもつ、現在ピクチャの参照ピクチャリスト中のピクチャであり得る。各リストについて、ピクチャは、参照インデックスの昇順で検査される。リストＸが最初に検査され、リスト（１−Ｘである）Ｙ中のピクチャが続く。
【０１５２】
ｉ．リストＸは、リストＸが、ＴＭＶＰのために使用されるコロケートされたピクチャを含んでいるリストであるように選定される。
【０１５３】
ｉｉ．代替的に、Ｘは、単に、１または０であるように設定される。
【０１５４】
ｃ．検査されるべきピクチャは、所与の順序をもつ、空間ネイバーの動きベクトルによって識別されるピクチャである。
【０１５５】
６．現在ＡＴＭＶＰが適用されるＰＵの区分は、２Ｎ×２Ｎ、Ｎ×Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、または、２Ｎ×Ｎ／２などの非対称動き区分（ＡＭＰ：asymmetric motion partition）区分であり得る。
【０１５６】
ａ．代替的に、追加として、他の区分サイズが可能にされ得る場合、ＡＴＭＶＰもサポートされ得、そのようなサイズは、たとえば、６４×８を含み得る。
【０１５７】
ｂ．代替的に、モードは、いくつかの区分、たとえば、２Ｎ×２Ｎに適用されるにすぎないことがある。
【０１５８】
７．ＡＴＭＶＰ候補は、マージ候補の異なるタイプとしてマークされる。
【０１５９】
８．ネイバーからベクトル（第１の段の場合のような時間ベクトル）を識別するとき、複数の隣接位置、たとえば、マージ候補リスト構築において使用される隣接位置が順番に検査され得る。ネイバーの各々について、参照ピクチャリスト０（リスト０）または参照ピクチャリスト１（リスト１）に対応する動きベクトルが順番に検査され得る。２つの動きベクトルが利用可能であるとき、リストＸ中の動きベクトルが最初に検査され、その後に（Ｙが１−Ｘに等しい）リストＹが続き得、その結果、リストＸは、ＴＭＶＰのために使用されるコロケートされたピクチャを含んでいるリストとなる。ＡＴＭＶＰでは、サブＰＵの中心位置のシフトとして時間ベクトルが追加され使用され、ここにおいて、時間ベクトルの成分は、整数にシフトされる必要があり得る。そのようなシフトされる中心位置は、たとえば、現在中心位置をカバーする４×４のサイズをもつ、動きベクトルが割り振られ得る最も小さいユニットを識別するために使用される。
【０１６０】
ａ．代替的に、リスト０に対応する動きベクトルが、リスト１に対応する動きベクトルの前に検査され得る。
【０１６１】
ｂ．代替的に、リスト１に対応する動きベクトルが、リスト０に対応する動きベクトルの前に検査され得る。
【０１６２】
ｃ．代替的に、すべての空間ネイバー中のリストＸに対応するすべての動きベクトルが順番に検査され、その後に（Ｙが１−Ｘに等しい）リストＹに対応する動きベクトルが続く。ここで、リスト「Ｘ」は、コロケートされたピクチャがどこに属するかを示すリストであるか、あるいは、ただ単に、０または１であるように設定され得る。
【０１６３】
ｄ．空間ネイバーの順序は、ＨＥＶＣマージモードで使用される順序と同じであり得る。
【０１６４】
９．識別する第１の段において、時間ベクトルが参照ピクチャを識別する情報を含まないとき、図９に示されているような動きソースピクチャは、単に、固定ピクチャ、たとえば、ＴＭＶＰのために使用されるコロケートされたピクチャであるように設定され得る。
【０１６５】
ａ．そのような場合、ベクトルは、そのような固定ピクチャを指す動きベクトルのみから識別され得る。
【０１６６】
ｂ．そのような場合、ベクトルは、任意のピクチャを指す動きベクトルからのみ識別されるが、さらに、固定ピクチャのほうへスケーリングされ得る。
【０１６７】
１０．参照ピクチャを識別することなる、ベクトルを識別する第１の段にあるとき、図９に示されているような動きソースピクチャ、以下の追加の検査のうちの１つまたは複数が、候補動きベクトルに対して適用され得る。
【０１６８】
ａ．動きベクトルが、イントラコーディングされるピクチャまたはスライスに関連する場合、そのような動きベクトルは、利用不可能であると見なされ、そのベクトルに変換されるために使用されないことがある。
【０１６９】
ｂ．動きベクトルが、関連するピクチャ中で（たとえば、動きベクトルをもつ現在中心座標を追加することによって）イントラブロックを識別する場合、そのような動きベクトルは、利用不可能であると見なされ、そのベクトルに変換されるために使用されないことがある。
【０１７０】
１１．ベクトルを識別する第１の段にあるとき、ベクトルの成分は、それが動きソースピクチャ中の右下ピクセル位置を識別するように、（現在ＰＵの１／２の幅，現在ＰＵの１／２の高さ）であるように設定され得る。ここで、（ｘ，ｙ）は、１つの動きベクトルの水平成分と垂直成分とを示す。
【０１７１】
ａ．代替的に、ベクトルの成分は、（ｓｕｍ（現在ＰＵの１／２の幅、Ｍ），ｓｕｍ（現在ＰＵの１／２の高さ、Ｎ））であるように設定され得、ここで、関数ｓｕｍ（ａ，ｂ）はａとｂの和を返す。一例では、動き情報が４×４ユニットにおいて記憶されるとき、ＭとＮは両方とも２に等しくなるように設定される。別の例では、動き情報が８×８ユニットにおいて記憶されるとき、ＭとＮは両方とも４に等しくなるように設定される。
【０１７２】
１２．ＡＴＭＶＰが適用されるときのサブブロック／サブＰＵサイズは、パラメータセット、たとえば、ピクチャパラメータセットのシーケンスパラメータセット中でシグナリングされる。サイズは、最小ＰＵサイズからＣＴＵサイズに及ぶ。サイズはまた、あらかじめ定義されるか、またはシグナリングされ得る。サイズは、たとえば、４×４程度に小さくなり得る。代替的に、サブブロック／サブＰＵサイズは、ＰＵまたはＣＵのサイズに基づいて導出され得る。たとえば、サブブロック／サブＰＵは、ｍａｘ（４×４，（ＣＵの幅）＞＞Ｍ）に等しく設定され得る。Ｍの値は、あらかじめ定義されるか、またはビットストリーム中でシグナリングされ得る。
【０１７３】
１３．マージ候補の最大数は、ＡＴＭＶＰが新しいマージ候補と見なされ得ることにより、１だけ増加され得る。たとえば、プルーニングの後にマージ候補リスト中の最高５つの候補を要するＨＥＶＣと比較して、マージ候補の最大数は６に増加され得る。
【０１７４】
ａ．代替的に、従来のＴＭＶＰ候補を用いたプルーニングまたは従来のＴＭＶＰ候補との統一は、マージ候補の最大数が、不変であるように保たれ得るように、ＡＴＭＶＰに対して実行され得る。
【０１７５】
ｂ．代替的に、ＡＴＭＶＰが利用可能であると識別されたとき、空間隣接候補がマージ候補リストから除外され、たとえば、フェッチング順序での最後の空間隣接候補が除外される。
【０１７６】
１４．複数の空間隣接動きベクトルが時間ベクトルを導出すると見なされるとき、動きベクトルの類似度が、現在ＰＵの隣接動きベクトル、ならびに、動きベクトルに等しく設定されている特定の時間ベクトルによって識別された隣接動きベクトルに基づいて計算され得る。最も高い動き類似度をもたらすものが、最終時間ベクトルとして選定され得る。
【０１７７】
ａ．一代替では、隣接位置Ｎからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロック（現在ＰＵと同じサイズ）を識別し、ここにおいて、それの隣接位置Ｎは動き情報のセットを含んでいる。動きベクトルのこのセットは、現在ブロックの隣接位置Ｎの場合のように動き情報のセットと比較される。
【０１７８】
ｂ．別の代替では、隣接位置Ｎからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロックを識別し、ここにおいて、それの隣接位置は動き情報の複数のセットを含んでいる。動きベクトルのこれらの複数のセットは、同じ相対位置において現在ＰＵの隣接位置からの動き情報の複数のセットと比較される。動き情報の類似度が計算される。たとえば、現在ＰＵは、ＭＩＡ１、ＭＩＢ１、ＭＩＡ０およびＭＩＢ０として示される、Ａ１、Ｂ１、Ａ０およびＢ０からの動き情報の以下のセットを有する。時間ベクトルＴＶについて、それは、動きソースピクチャ中のＰＵに対応するブロックを識別する。そのようなブロックは、同じ相対Ａ１、Ｂ１、Ａ０およびＢ０位置からの動き情報を有し、ＴＭＩＡ１、ＴＭＩＢ１、ＴＭＩＡ０およびＴＭＩＢ０として示した。ＴＶによって決定された動き類似度は、
【０１７９】
【数１】
2019515587.tif 000003
【０１８０】
として計算され、ここにおいて、ＭＶＳｉｍは動き情報の２つのセット間の類似度を定義する。
【０１８１】
ｃ．上記の場合の両方では、動き類似度ＭＶＳｉｍが使用され得、ここにおいて、２つの入力パラメータは、各々が最高２つの動きベクトルと２つの参照インデックスとを含んでいる、動き情報の２つのセットである。リストＸ中の動きベクトルの各ペアは、実際は、異なるピクチャ、すなわち、現在ピクチャおよび動きソースピクチャの異なるリストＸ中の参照ピクチャに関連する。（Ｘが０または１に等しい）２つの動きベクトルＭＶＸＮおよびＴＭＶＸＮの各々について、動きベクトル差分ＭＶＤＸＮがＭＶＸＮ−ＴＭＶＸＮとして計算され得る。その後、差分ＭＶＳｉｍＸが、たとえば、
【０１８２】
【数２】
2019515587.tif 000004
【０１８３】
または
【０１８４】
【数３】
2019515587.tif 000005
【０１８５】
ｉ．動き差分の統一された計算を有するために、動きベクトルの両方は、たとえば、現在ピクチャのリストＸの第１の参照ピクチャＲｅｆＰｉｃＬｉｓｔＸ［０］であり得る、同じ固定ピクチャのほうへスケーリングされる必要がある。
【０１８６】
ｉｉ．第１のセットからのリストＸ中の動きベクトルの利用可能性と第２のセットからのリストＸ中の動きベクトルの利用可能性とが異なる、すなわち、一方の参照インデックスが−１であり、他方の参照インデックスが−１でない場合、動き情報のそのような２つのセットは、方向Ｘにおいて類似していないと見なされる。２つのセットが両方のセットにおいて類似していない場合、最終ＭＶＳｉｍ関数は大きい値Ｔを返し得、それは、たとえば、無限と見なされ得る。
【０１８７】
ｉｉｉ．代替的に、動き情報のセットのペアについて、一方が、（Ｙが１−Ｘに等しい）リストＹではなく（Ｘが０または１に等しい）リストＸから予測され、他方が同じステータスを有する場合、１から２の間の重み付け（たとえば、ＭＶＳｉｍはＭＶＳｉｍＸ＊１．５に等しい）が使用され得る。一方のセットがリストＸのみから予測され、他方のセットがリストＹのみから予測されるとき、ＭＶＳｉｍは、大きい値Ｔに設定される。
【０１８８】
ｉｖ．代替的に、動き情報の任意のセットについて、１つの動きベクトルが利用可能である限り、両方の動きベクトルが生成される。１つの動きベクトルのみが利用可能である（リストＸに対応している）場合、それは、他のリストＹに対応する動きベクトルを形成するためにスケーリングされる。
【０１８９】
ｄ．代替的に、動きベクトルは、現在ＰＵの隣接ピクセルと、動きベクトルによって識別されたブロック（現在ＰＵと同じサイズ）の隣接ピクセルとの間の差分に基づいて測定され得る。最も小さい差分をもたらす動きベクトルが、最終時間ベクトルとして選定され得る。
【０１９０】
１５．現在ブロックの時間ベクトルを導出するとき、ＡＴＭＶＰを用いてコーディングされる隣接ブロックからの動きベクトルおよび／または時間ベクトルは、他の隣接ブロックからの動きベクトルよりも高い優先度を有し得る。
【０１９１】
ａ．一例では、隣接ブロックの時間ベクトルのみが最初に検査され、第１の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。この場合、ＡＴＭＶＰコード化ブロックのための時間ベクトルが記憶される必要がある。
【０１９２】
ｂ．別の例では、ＡＴＭＶＰコード化隣接ブロックからの動きベクトルのみが最初に検査され、第１の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。
【０１９３】
ｃ．別の例では、ＡＴＭＶＰコード化隣接ブロックからの動きベクトルのみが最初に検査され、第１の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条１５ａの場合と同様に続く。
【０１９４】
ｄ．別の例では、隣接ブロックからの時間ベクトルが最初に検査され、第１の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条１５ｂの場合と同様に続く。
【０１９５】
ｅ．別の例では、ＡＴＭＶＰコード化隣接ブロックの時間ベクトルと動きベクトルとが最初に検査され、第１の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルおよび動きベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。
【０１９６】
１６．複数の空間隣接動きベクトルが時間ベクトルを導出すると見なされるとき、動きベクトルは、それが、ピクセル領域から計算されるひずみを最小限に抑えるように選定され得、たとえば、最小マッチングコストをもたらすものが最終時間ベクトルとして選択されるように時間ベクトルを導出するために、テンプレートマッチングが使用され得る。
【０１９７】
１７．（動きソースピクチャ中の）対応するブロックからの動き情報のセットの導出は、動きベクトルが、任意のリストＸのために、対応するブロック中で利用可能であるとき（動きベクトルをＭＶＸであると示す）、ＡＴＭＶＰ候補の現在サブＰＵについて、動きベクトルが（ＭＶＸをスケーリングすることによって）リストＸのために利用可能であると見なされるように、行われる。動きベクトルが、任意のリストＸのために、対応するブロック中で利用不可能である場合、動きベクトルはリストＸのために利用不可能であると見なされる。
【０１９８】
ａ．代替的に、対応するブロック中の動きベクトルがリストＸのために利用不可能であるが、リスト１−Ｘのために利用可能であるとき（１−ＸがＹで示され、動きベクトルをＭＶＹであるとして示す）、動きベクトルは、依然として、（リストＸ中のターゲット参照ピクチャのほうへＭＶＹをスケーリングすることによって）リストＸのために利用可能であると見なされる。
【０１９９】
ｂ．代替的に、または追加として、リストＸおよびリスト（１−Ｘに等しい）Ｙのための対応するブロック中の両方の動きベクトルが利用可能であるとき、リストＸおよびリストＹからの動きベクトルが、スケーリングによって現在サブＰＵの２つの動きベクトルを直接スケーリングし、生成するために必要な使用されない。
【０２００】
ｉ．一例では、ＡＴＭＶＰ候補を構築するとき、ＴＭＶＰにおいて行われるような低遅延検査が各サブＰＵに適用される。現在スライスのあらゆる参照ピクチャリスト中の（ｒｅｆＰｉｃによって示される）あらゆるピクチャについて、ｒｅｆＰｉｃのピクチャ順序カウント（ＰＯＣ）値が現在スライスのＰＯＣよりも小さい場合、現在スライスは低遅延モードで考慮される。この低遅延モードでは、リストＸおよびリストＹからの動きベクトルは、それぞれ、リストＸおよびリストＹのための現在サブＰＵの動きベクトルを生成するためにスケーリングされる。低遅延モードにないとき、ＭＶＸまたはＭＶＹからの１つの動きベクトルＭＶＺのみが選定され、現在サブＰＵのための２つの動きベクトルを生成するためにスケーリングされる。ＴＭＶＰと同様に、そのような場合、Ｚは、ｃｏｌｌｏｃａｔｅｄ＿ｆｒｏｍ＿ｌ０＿ｆｌａｇに等しく設定され、これは、それが、ＴＭＶＰの場合のようなコロケートされたピクチャが現在ピクチャのリストＸまたはリストＹ中にあるかどうかに依存することを意味する。代替的に、Ｚは、以下のように設定され、すなわち、動きソースピクチャがリストＸから識別される場合、ＺがＸに設定される。代替的に、追加として、動きソースピクチャが両方の参照ピクチャリストに属し、ＲｅｆＰｉｃＬｉｓｔ０［ｉｄｘ０］が、リスト０中に最初に存在する動きソースピクチャであり、ＲｅｆＰｉｃＬｉｓｔ（１）［ｉｄｘ１］が、リスト１中に最初に存在する動きソースピクチャであるとき、Ｚは、ｉｄｘ０がｉｄｘ１よりも小さいかそれに等しい場合、０であるように設定され、他の場合、１であるように設定される。
【０２０１】
１８．動きソースピクチャは、コード化ビットストリーム中でビデオエンコーダ２０によってシグナリングされ、たとえば、生成され得る。詳細に、動きソースピクチャがリスト０からであるのかリスト１からであるのかを示すフラグが、Ｂスライスのためにシグナリングされる。代替的に、追加として、現在ピクチャのリスト０またはリスト１への参照インデックスが、動きソースピクチャを識別するためにシグナリングされ得る。
【０２０２】
[0142]時間ベクトルを識別するとき、それが、関連する動きソースピクチャ中のイントラコード化ブロックを指す場合、ベクトルは利用不可能であると見なされる（したがって他のベクトルが考慮され得る）。
【０２０３】
[0143]図１１は、参照ピクチャからのサブＰＵ動き予測を示す概念図である。この例では、現在ピクチャ３８０は、現在ＰＵ３８４（たとえば、ＰＵ）を含む。この例では、動きベクトル３９２は、ＰＵ３８４に対する参照ピクチャ３８２のＰＵ３８６を識別する。ＰＵ３８６は、各々がそれぞれの動きベクトル３９０Ａ〜３９０Ｄを有する、サブＰＵ３８８Ａ〜３８８Ｄに区分される。したがって、現在ＰＵ３８４は、実際は別個のサブＰＵに区分されないが、この例では、現在ＰＵ３８４は、サブＰＵ３８８Ａ〜３８８Ｄからの動き情報を使用して予測され得る。特に、ビデオコーダは、それぞれの動きベクトル３９０Ａ〜３９０Ｄを使用して現在ＰＵ３８４のサブＰＵをコーディングし得る。しかしながら、ビデオコーダは、現在ＰＵ３８４がサブＰＵにスプリットされることを示すシンタックス要素をコーディングする必要がない。このようにして、現在ＰＵ３８４は、現在ＰＵ３８４を複数のサブＰＵにスプリットするために使用されるシンタックス要素のシグナリングオーバーヘッドなしに、それぞれのサブＰＵ３８８Ａ〜３８８Ｄから継承される、複数の動きベクトル３９０Ａ〜３９０Ｄを使用して効果的に予測され得る。
【０２０４】
[0144]図１２は、（ＴＭＶＰと同様の）ＡＴＭＶＰにおける関連するピクチャを示す概念図である。特に、図１２は、現在ピクチャ４０４と、動きソースピクチャ４０６と、参照ピクチャ４００および４０２とを示す。より詳細には、現在ピクチャ４０４は現在ブロック４０８を含む。時間動きベクトル４１２は、現在ブロック４０８に対する動きソースピクチャ４０６の対応するブロック４１０を識別する。対応するブロック４１０は、今度は、動きベクトル４１４を含み、これは、参照ピクチャ４０２を参照し、現在ブロック４０８の少なくとも一部分、たとえば、現在ブロック４０８のサブＰＵのための高度時間動きベクトル予測子として働く。すなわち、動きベクトル４１４は、現在ブロック４０８のための候補動きベクトル予測子として追加され得る。選択された場合、現在ブロック４０８の少なくとも一部分は、参照ピクチャ４００を参照する、対応する動きベクトル、すなわち、動きベクトル４１６を使用して予測され得る。
【０２０５】
[0145]また、ＨＥＶＣのためのサブＰＵ関係技法は、その両方の内容全体が参照により本明細書に組み込まれる、２０１６年７月９日に出願された米国出願第１５／１７６，７９０号に記載されている。サブＰＵ動き予測を使用して性能を向上させるために、隣接サブＰＵの空間時間動き情報（ＡＴＭＶＰ＿ＥＸＴ）が活用される（exploited）。この例では、各サブＰＵのための動きベクトルは、３次元領域における隣接ブロックの情報から導出される。これは、隣接ブロックが、現在ピクチャ中の空間ネイバーまたは前のコード化ピクチャ中の時間ネイバーであり得ることを意味する。図１３は、空間時間動きベクトル予測子（ＳＴＭＶＰ：spatial-temporal motion vector predictor）導出プロセスのフローチャートを示す。以下で説明されることのほかに、ＡＴＭＶＰについて上記で説明された方法（たとえば、箇条１、２、３、４、６、７、１２、１３）は、ＳＴＭＶＰに直接拡張され得る。
【０２０６】
[0146]図１３に示されているように、ビデオエンコーダ２０および／またはビデオデコーダ３０は、現在サブＰＵのための空間または時間隣接ブロックから利用可能な動きフィールドを取得するように構成され得る（４３０）。このコンテキストでは、動きフィールドは、空間的に／時間的に隣接するブロックのための最良として選択された動きベクトルの集合（collection）である。たとえば、現在ブロックの左または上に位置するブロックは、すでにコーディングされており、最良の動きベクトルは、現在サブＰＵをコーディングする前に利用可能である。隣接ブロックからの利用可能な動き情報は、ビデオエンコーダ２０とビデオデコーダ３０の両方において同等である。動き情報は、１つまたは２つの３次元ベクトル（ＭＶｘ、Ｍｖｙ、時間的方向）、すなわち、単予測のための１つのベクトルおよび双予測のための２つのベクトルのを含む。ビデオエンコーダ２０および／またはビデオデコーダ３０は、次いで、取得された隣接動きフィールドから動き情報を導出する（４３２）。ビデオエンコーダ２０および／またはビデオデコーダ３０は、次いで、サブＰＵのすべてが処理されたかどうかを決定する（４３４）。いいえの場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は次のサブＰＵに移動する。はいの場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、空間時間サブＰＵ動き予測子の利用可能性を決定し得る（４３６）。利用可能な場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は空間時間サブＰＵ動き予測子をマージリストに挿入する。
【０２０７】
[0147]以下の説明では、「ブロック」という用語は、予測関係情報、たとえば、インターまたはイントラ予測、イントラ予測モード、動き情報などの記憶のためのブロックユニットを指すために使用される。そのような予測情報は、保存され、将来のブロックをコーディングするために、たとえば、将来のブロックのための予測モード情報を予測するために使用され得る。ＡＶＣおよびＨＥＶＣでは、そのようなブロックのサイズは４×４である。以下の説明では、隣接ブロックから動き情報を導出するユニットを示すためのインターコード化ブロックユニットおよびサブＰＵを示すために「ＰＵ」を使用することに留意されたい。以下の技法の任意の組合せが適用され得る。
【０２０８】
[0148]一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、隣接ブロックから動き情報を取得するように構成され得る。サブＰＵおよび隣接ブロックは、異なるサイズを有し得る。複数のサブＰＵをもつＰＵについて考える。サブＰＵのサイズは、通常、その隣接ブロックサイズに等しいかまたはそれよりも大きい。一例では、図１４に示されているように、ハッシングされた（hashed）正方形は、現在ＰＵの外部にある隣接ブロック（ａ、ｂ、．．．ｉ）を表し、残りのハッシングされていない正方形（Ａ、Ｂ、．．．Ｐ）は、現在ＰＵ中のサブＰＵを表す。図１４に示されているように、サブＰＵのサイズと、それの隣接ブロックのサイズとは同じである。一例では、サブＰＵのサイズは４×４に等しいが、異なるサイズのサブＰＵが使用され得る。図１５は、サブＰＵが隣接ブロックよりも大きい別の例を示す。他の例では、サブＰＵは、長方形または三角形などの非正方形形状をとり得る。ある例では、サブＰＵのサイズは、スライスヘッダ中でシグナリングされ得る。
【０２０９】
[0149]他の例では、ＡＴＭＰＶに関係する上記の説明の箇条１２におけるプロセスは、ＳＴＭＶＰに拡張され得る。たとえば、ＳＴＭＶＰが適用されるときのサブブロック／サブＰＵサイズは、パラメータセット、たとえば、ピクチャパラメータセットのシーケンスパラメータセット中でシグナリングされる。サイズは、最小ＰＵサイズからＣＴＵサイズに及ぶ。サイズはまた、あらかじめ定義されるか、またはシグナリングされ得る。サイズは、たとえば、４×４程度に小さくなり得る。代替的に、サブブロック／サブＰＵサイズは、ＰＵまたはＣＵのサイズに基づいて導出され得る。たとえば、サブブロック／サブＰＵは、ｍａｘ（４×４，（ＣＵの幅）＞＞Ｍ）に等しく設定され得る。Ｍの値は、あらかじめ定義されるか、またはビットストリーム中でシグナリングされ得る。
【０２１０】
[0150]ＳＴＭＶＰでは、サブＰＵの異なる検査順序が使用され得る。図１４の例では、以下の説明において、ラスタ走査順序（Ａ、Ｂ、Ｃ、Ｄ、Ｅ．．．）が、サブＰＵに、それらの動き予測導出のために、適用されると仮定する。しかしながら、他の走査順序も適用され得、本開示の技法はラスタ走査順序のみに限定されるものでないことに留意されたい。
【０２１１】
[0151]ＳＴＭＶＰでは、隣接ブロックは、２つの異なるタイプ、すなわち、空間および時間に分類され得る。空間隣接ブロックは、現在ピクチャまたはスライス中にあり、現在サブＰＵに隣接している、すでにコード化されたブロックまたはすでに走査されたサブＰＵである。時間隣接ブロックは、前のコード化ピクチャ中のブロックであり、現在サブＰＵのコロケートされたブロックに隣接している。一例では、時間隣接ブロックを取得するために、現在ＰＵに関連するすべての参照ピクチャが使用される。別の例では、参照ピクチャのサブセットが、ＳＴＭＶＰ導出のために使用される。たとえば、各参照ピクチャリストの第１のエントリのみが使用される。
【０２１２】
[0152]この定義に続いて、図１４を参照すると、サブＰＵ（Ａ）の場合、前のコード化ピクチャ中のすべての隣接ブロック（ａ、ｂ、．．．ｉ）およびそれらのコロケートされたブロックは、利用可能として扱われる空間および時間隣接ブロックである。ラスタ走査順序によれば、ブロックＢ、Ｃ、Ｄ、Ｅ．．．Ｐは空間的に利用可能でない。とはいえ、（ＡからＰまでの）すべてのサブＰＵは、それらの動き情報が前のコード化ピクチャ中のそれらのコロケートされたブロック中で見つけられ得るので、サブＰＵ（Ａ）のための時間的に利用可能な隣接ブロックである。別の例としてサブＰＵ（Ｇ）を挙げると、利用可能であるそれの空間隣接ブロックは、ａ、ｂ．．．からｉまでのものを含み、また、ＡからＦまでのものを含む。いくつかの例では、空間隣接ブロック（すなわち、ａ、ｂ．．．からｉまで）が同じＬＣＵ／スライス／タイル中にあるものとするなど、いくつかの制限が空間隣接ブロックに適用され得る。
【０２１３】
[0153]ビデオエンコーダ２０および／またはビデオデコーダ３０は、各サブＰＵのための動き情報または動きフィールドを導出するために、すべての利用可能な隣接ブロックのサブセットを選択する。各ＰＵの導出のために使用されるサブセットは、あらかじめ定義され得る。他の例では、導出のために使用されるサブセットは、スライスヘッダ、ピクチャパラメータセット（ＰＰＳ）、および／またはシーケンスパラメータセット（ＳＰＳ）中で高レベルシンタックスとしてシグナリングされ得る。コーディング性能を最適化するために、サブセットは各サブＰＵについて異なり得る。実際には、サブセットのためのロケーションの固定パターンが、簡単のために選好される。たとえば、各サブＰＵは、サブセットとして、それのすぐ上の空間ネイバーと、それのすぐ左の空間ネイバーと、それのすぐ右下の時間ネイバーとを使用し得る。図１４に示されているように、サブＰＵ（Ｊ）について考えるとき、上ブロック（Ｆ）および左ブロック（Ｉ）は、空間的に利用可能な隣接ブロックであり、右下ブロック（Ｏ）は、時間的に利用可能な隣接ブロックである。そのようなサブセットの場合、現在ＰＵ中のサブＰＵは、処理依存性（processing dependency）により、連続的に処理される。
【０２１４】
[0154]現在ＰＵ中の各サブＰＵの並列処理を可能にするために、隣接ブロックの異なるサブセットが定義および使用され得る。一例では、サブセットは、現在ＰＵに属さない空間ネイバーブロック、たとえば、ブロックａ、ｂ、．．．ｉのみを含んでいる。この場合、並列処理が可能であろう。別の例では、所与のサブＰＵについて、それの空間隣接ブロックが現在ＰＵ内にある場合、その空間隣接ブロックのコロケートされたブロックは、サブセット中に入れられ、現在サブＰＵの動き情報を導出するために使用され得る。たとえば、サブＰＵ（Ｊ）について考えるとき、上ブロック（Ｆ）および左ブロック（Ｉ）および右下ブロック（Ｏ）の時間的なコロケートされたブロックは、サブＰＵ（Ｊ）の動きを導出するためのサブセットとして選択される。この場合、サブＰＵ（Ｊ）のためのサブセットは３つの時間隣接ブロックを含んでいる。別の例では、部分並列プロセスが有効にされ得、ここにおいて、１つのＰＵはいくつかの領域にスプリットされ、（いくつかのサブＰＵをカバーする）各領域は独立して処理され得る。
【０２１５】
[0155]時々、隣接ブロックはイントラコーディングされ、ここにおいて、より良い動き予測およびコーディング効率のために、それらのブロックのための代替動き情報を決定するためのルールを有することが望ましい。たとえば、サブＰＵ（Ａ）について考えると、ブロックｂ、ｃ、ｆがイントラコーディングされ、ブロックａ、ｄ、ｅ、ｇ、ｈ、ｉがインターコーディングされる場合があり得る。
【０２１６】
[0156]空間ネイバーについて、イントラコード化ブロックの動き情報を、最初に見つけられたインターコード化ブロックの動き情報でポピュレートするために、あらかじめ定義された順序が使用され得る。たとえば、上ネイバーの探索順序は、最右ネイバーまで右向にすぐ上のネイバーから開始するように設定され得、これは、ｂ、ｃ、ｄ、およびｅの順序を意味する。左ネイバーの探索順序は、最下ネイバーまで下方へすぐ左のネイバーから開始するように設定され得る。この例では、順序は、ｆ、ｇ、ｈ、次いでｉである。インターコード化ブロックが探索プロセスを通して見つけられなかった場合、上または左空間ネイバーは利用不可能であると見なされる。
【０２１７】
[0157]時間ネイバーについて、ＴＭＶＰ導出において指定されるものと同じルールが使用され得る。しかしながら、他のルール、たとえば、動き方向、時間距離（異なる参照ピクチャ中での探索）および空間ロケーションなどに基づくルールも使用され得ることに留意されたい。
【０２１８】
[0158]ビデオエンコーダ２０および／またはビデオデコーダ３０は、次いで、所与のサブＰＵのための動き情報を導出し得る。このプロセスの一部として、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ターゲット参照ピクチャ決定および動きベクトルスケーリングを実行し得る。隣接ブロックについて、動きベクトルスケーリングが、すべての隣接ブロックの動きベクトルを各リスト中の同じ参照ピクチャにマッピングするために、各参照ピクチャリストに基づいて、隣接ブロックに関連する動きベクトルに適用され得る。本例では、２つのステップがあり得、第１に、スケーリングのために使用するソース動きベクトルを決定し、第２に、ソース動きベクトルが投影されるターゲット参照ピクチャを決定する。
【０２１９】
[0159]第１のステップでは、いくつかの方法が使用され得る。
【０２２０】
（ａ）各参照リストについて、動きベクトルスケーリングは、別の参照リスト中の動きベクトルとは無関係である。所与のブロックの動き情報について、参照リスト中の動きベクトルがない場合（たとえば、双予測モードではなく（instead of）単予測モード）、動きベクトルスケーリングはそのリストのために実行されない。
【０２２１】
（ｂ）動きベクトルスケーリングは、別の参照リスト中の動きベクトルとは無関係でない。所与のブロックの動き情報について、動きベクトルが参照リスト中で利用不可能でない場合、動きベクトルは、別の参照リスト中の動きベクトルからスケーリングされ得る。
【０２２２】
（ｃ）両方の動きベクトルは、（上述のＴＭＶＰの場合のように）１つのあらかじめ定義された参照リストからスケーリングされる。
【０２２３】
[0160]一例として、方法（ａ）は、空間隣接ブロックの動きベクトルをスケーリングするために使用され、方法（ｃ）は、時間隣接ブロックの動きベクトルをスケーリングするために使用される。
【０２２４】
[0161]第２のステップに関しては、ビデオエンコーダ２０および／またはビデオデコーダ３０は、利用可能な空間隣接ブロックの動き情報（たとえば参照ピクチャ）に基づく、あるルールに従って、ターゲット参照ピクチャを選択し得る。そのようなルールの一例は、多数決ルール、すなわち、ブロックの大部分によって共有される参照ピクチャを選択することである。この場合、同じ情報が同じルールを使用してデコーダ側においても推論され得るので、エンコーダからデコーダへの、ターゲット参照ピクチャのために必要とされるシグナリングがない。代替的に、そのような参照ピクチャはまた、スライスヘッダ中で明示的に指定されるか、またはいくつかの他の方法でデコーダにシグナリングされ得る。ターゲット参照ピクチャは、各参照リストの第１の参照ピクチャ（ｒｅｆｉｄｘ＝０）として決定される。
【０２２５】
[0162]ビデオエンコーダ２０および／またはビデオデコーダ３０は、所与のサブＰＵのための動き情報を導出するように構成され得る。前のセクションに示されているように、隣接ブロックから動き情報を取り出し、（必要な場合）動きスケーリングプロセスを実行した後に、現在サブＰＵの動き情報は導出される。１つの所与のサブＰＵのための動き情報をもつＮ個の利用可能な隣接ブロックがあると仮定する。第１に、予測指示（ＩｎｔｅｒＤｉｒ）が決定される。例示的な方法は、以下のとおりである。
【０２２６】
ａ．ＩｎｔｅｒＤｉｒは０として初期化され、次いで、Ｎ個の利用可能な隣接ブロックの動き情報を通してループする、
ｂ．リスト０中に少なくとも１つの動きベクトルがある場合、ＩｎｔｅｒＤｉｒ＝（ＩｎｔｅｒＤｉｒ  ｂｉｔｗｉｓｅＯＲ１）である、
ｃ．リスト１中に少なくとも１つの動きベクトルがある場合、ＩｎｔｅｒＤｉｒ＝（ＩｎｔｅｒＤｉｒ  ｂｉｔｗｉｓｅＯＲ２）である。
【０２２７】
ここで、「ｂｉｔｗｉｓｅＯＲ」はビット単位ＯＲ演算を表す。ＩｎｔｅｒＤｉｒの値は、０（インター予測なし）、１（リスト０に基づくインター予測）、２（リスト１に基づくインター予測）、および３（リスト０とリスト１の両方に基づくインター予測）と定義される。
【０２２８】
[0163]別の例では、上記で説明された動きベクトルスケーリングのためのターゲット参照ピクチャに関する決定と同様に、多数決ルールは、すべての利用可能な隣接ブロックの動き情報に基づいて、所与のサブＰＵのためのＩｎｔｅｒＤｉｒの値を決定するために使用され得る。
【０２２９】
[0164]ＩｎｔｅｒＤｉｒが決定された後、動きベクトルは導出され得る。導出されたＩｎｔｅｒＤｉｒに基づく各参照リストについて、上記で説明されたように、ターゲット参照ピクチャに対する動きベクトルスケーリングを通して利用可能なＭ個の動きベクトル（Ｍ≦Ｎ）があり得る。参照リストのための動きベクトルは次のように導出され得る。
【０２３０】
【数４】
2019515587.tif 000006
【０２３１】
ここで、ｗiおよびｗjは、それぞれ、水平動き成分および垂直動き成分のための重み付けファクタであり、ＯiおよびＯjは、重み付けファクタに依存するオフセット値である。
【０２３２】
[0165]重み付けファクタは、様々なファクタに基づいて決定され得る。一例では、同じルールが１つのＰＵ内のすべてのサブＰＵに適用され得る。ルールは以下のように定義され得る。たとえば、重み付けファクタは、現在サブＰＵと、対応する隣接ブロックとのロケーション距離に基づいて決定され得る。別の例では、重み付けファクタはまた、ターゲット参照ピクチャと、スケーリングの前の対応する隣接ブロックの動きベクトルに関連する参照ピクチャとの間のＰＯＣ距離に基づいて決定され得る。また別の例では、重み付けファクタは、動きベクトル差分または一貫性に基づいて決定され得る。また、簡単のために、すべての重み付けファクタは１に設定され得る。
【０２３３】
[0166]別の例では、異なるルールが１つのＰＵ内のサブＰＵに適用され得る。たとえば、上記のルールが適用され得、さらに、第１の行／第１の列に位置するサブＰＵについて、時間隣接ブロックから導出された動きベクトルのための重み付けファクタが０に設定され、残りのブロックについて、空間隣接ブロックから導出された動きベクトルのための重み付けファクタが０に設定される。
【０２３４】
[0167]実際には、上記の式は、そのままで実装されるか、または容易な実装のために簡略化され得ることに留意されたい。たとえば、除算または浮動小数点演算を回避するために、固定小数点演算が、上記の式を近似するために使用され得る。一事例は、３で除算する、を回避するために、除算演算を乗算およびビットシフトと置き換えるために、４３／１２８を乗算することを代わりに選択し得ることである。実装におけるそれらの変形形態は、本開示の技法の同じ趣旨の下でカバーされると見なされるべきである。代替的に、メジアンフィルタなど、非線形演算も、動きベクトルを導出するために適用され得る。
【０２３５】
[0168]ビデオエンコーダ２０および／またはビデオデコーダ３０はまた、ＳＴＭＶＰのための候補リスト構築プロセス中に利用可能性検査を実行するように構成され得る。各サブＰＵの動きベクトル予測子が利用可能である場合でも、ＳＴＭＶＰモードは、１つのＰＵのために利用不可能であるようにリセットされ得ることが提案される。たとえば、各サブＰＵの動きベクトル予測子が所与のＰＵについて導出されると、いくつかの利用可能性検査が、ＳＴＭＶＰモードが所与のＰＵのために利用可能にされるべきであるかどうかを決定するために実行される。そのような演算は、ＳＴＭＶＰモードが所与のＰＵについて最終的に選定される可能性が極めて低い場合をなくすために使用される。ＳＴＭＶＰモードが利用可能でないとき、モードシグナリングはＳＴＭＶＰを含まない。ＳＴＭＶＰモードが、マージリスト中にＳＭＴＶＰを挿入することによって実装される場合、マージリストは、ＳＴＭＶＰモードが利用可能でないと決定されたとき、このＳＴＭＶＰ候補を含まない。その結果、シグナリングオーバーヘッドが低減され得る。
【０２３６】
[0169]１つのＰＵがＭ個のサブＰＵに区分されることについて考える。一例では、Ｍ個のサブＰＵのうちのＮ１（Ｎ１≦Ｍ）個のサブＰＵが同じ動きベクトル予測子（すなわち、同じ動きベクトルおよび同じ参照ピクチャインデックス）を有する場合、ＳＴＭＶＰは、Ｎ１がしきい値よりも小さいか、または予測子がマージリスト中の（より小さいマージインデックスをもつ）他の動きベクトル予測子とは異なるときのみに利用可能にされる。別の例では、ＳＴＭＶＰモード下でのＮ２（Ｎ２≦Ｍ）個のサブＰＵが、ＡＴＭＶＰ下での対応するサブＰＵと同じ動きベクトル予測子を共有する場合、ＳＴＭＶＰは、Ｎ２が別のしきい値よりも小さいときのみに利用可能にされる。本開示の一例では、Ｎ１のためのしきい値とＮ２のためのしきい値の両方がＭに等しく設定される。
【０２３７】
[0170]ＳＴＭＶＰが利用可能である場合、ビデオエンコーダ２０および／またはビデオデコーダ３０はＳＴＭＰＶ候補をマージリスト中にに中に挿入する。上記のＡＴＭＶＰについての箇条１におけるプロセスは拡張され得、ＳＴＭＶＰ候補は、ＡＴＭＶＰ候補の前または後のいずれかに挿入され得る。一例では、ＳＴＭＶＰ候補は、マージリスト中のＡＴＭＶＰ候補のちょうど後に（right after）挿入される。
【０２３８】
[0171]ＰＯＣベースＭＶプルーニング技法は、その内容全体が参照により本明細書に組み込まれる、２０１７年２月１３日に出願された米国出願第１５／４３１，３２１号に記載されている。ＭＶ予測の効率を最大にする（maximize）ために、利用可能なＭＶの一意性が調べられ得る。他の場合、冗長ＭＶは、ターゲットデバイスのビットバジェットまたはリソースを浪費することなど、非効率的なリソース利用につながることになる。したがって、ＭＶ候補の冗長性をなくすこと、いわゆるプルーニングは、ＭＶ予測においてより有意味な（meaningful）ＭＶ候補を与えるために、ＭＶをできるだけ一意および多様に保つために重要なステップであり得る。
【０２３９】
[0172]本開示は、３つの主要な強み、すなわち、（１）より高い精度、（２）単純さ、および（３）普遍性を有するＰＯＣベースプルーニングについて説明する。提案される技法は、それが既存のプルーニング方法によってキャプチャされなかった冗長ＭＶを検出することができるので、より高いプルーニング精度を有する。さらに、それは、さらなる複雑さが必要とされないので、単純である。最後に、ＰＯＣベースプルーニングは、それが、汎用性のある（versatile）状況、たとえば、ＡＴＭＶＰ／マージ候補のための空間ＭＶ、サブＰＵ（ＡＴＭＶＰおよびＳＴＭＶＰ）ＭＶ、ＴＭＶＰ、組合せＭＶ、さらには０ＭＶに適用され得るという点で普遍である。
【０２４０】
【表１】
2019515587.tif 000007
【０２４１】
[0173]表１は、ＰＯＣベースの方法を使用してどんな種類のＭＶペアがプルーニングされ得るかを要約している。カテゴリーＣ１では、（サブＰＵでない）通常ＰＵからのＭＶが比較される。比較は、２つの単ＭＶ（たとえば、単予測のための動きベクトル）または２つの双ＭＶ（たとえば、双予測のための動きベクトル）のいずれかの間であり得る。Ｃ２からＣ４まで、（１つまたは複数の）サブＰＵ  ＭＶは比較に含まれる。Ｃ２では、ＰＯＣベースプルーニングは、ＰＵ内のサブＰＵ  ＭＶがすべて同等であるかどうかを決定するために使用される。これは、Ｃ１における同じ技法をサブＰＵからのＭＶに適用することによって扱われ得る。すべてのサブＰＵ  ＭＶが等しい状況はＣ３に分類され（falls into）、ここで、ＭＶはサブＰＵからのすべてのＭＶを表し、したがって、Ｃ１の場合と同じ比較が適用される。しかし、候補のすべてのサブＰＵ  ＭＶが等しくなく、サブＰＵ  ＭＶを有する別の候補、すなわち、Ｃ４が存在する場合、ＰＯＣベースプルーニングは、ＰＵ内の同じ位置に位置するサブＰＵからのＭＶの各ペアに適用される。Ｃ５とＣ６の両方は、２つの単ＭＶ、すなわち、Ｌ０からの単ＭＶと、Ｌ１からの別の単ＭＶを組み合わせることによって、双ＭＶ構築に関係する。２つの単ＭＶが同等（たとえば、同じ参照ピクチャからの同じＭＶ）である場合、得られた双ＭＶが単ＭＶと同じになるので、双ＭＶ構築は必要とされない。したがって、ＰＯＣベースプルーニングは、特にＬ０とＬ１とが同じ参照ピクチャを有するとき、同等のＭＶをより正確に検出することによってリソースを節約するのを助けることができる。
【０２４２】
[0174]候補の所与のリストの場合、マージ候補リストの効率を決定し得る２つのファクタは、（１）候補リストの順序付け（たとえば、リスト中の候補の順序をどのように割り当てるべきか）、および（２）プルーニング（たとえば、それらの候補の間の冗長性を除去すること）である。概して、第１の候補へのインデックスがより少数でシグナリングされ得るので、候補リスト中の順序で第１になるために最も可能性がある選定された候補を有することが選好される。また、リスト中により様々な候補を有すること（たとえば、より少ない冗長性）は、より正確な動きベクトルがリスト中の候補の間に存在する機会を増加させる。
【０２４３】
[0175]本開示の技法は、可能な候補のより大きいグループからマージ候補のセットを決定するための技法を含む。さらに、本開示は、動きベクトル候補リストのより高い効率を達成するための、マージ候補の適応選択、順序付けおよびプルーニングのための技法について説明する。適応順序付けの場合、提案される技法は、（たとえば、リスト中のより小さいインデックスを生じる）より高い優先度を、より正確な動き情報を有するより高い可能性をもつ候補に割り当てるために、さらなるＭＶ情報を活用する。適応プルーニングの場合、動きベクトル差分（ＭＶＤ）を適応しきい値と比較することによって２つのＭＶが同等である（または極めて近い）かどうかを決定するために、ＭＶＤが使用され得る。
【０２４４】
[0176]提案される技法のフレキシビリティにより、本開示の技法は、Ｈ．２６４、ＨＥＶＣ、またはＨ．２６６など、既存の最先端のコーデックの大部分に適用され得、上記で説明されたＱＴＢＴ構造など、異なる区分フレームワークに容易に拡張され得る。さらに、提案される技法の異なる組合せは、特定の適用例のための所望のソリューションに組み合わせられ得る。すなわち、以下の技法は、独立して、または任意の相互排他的でない組合せで適用され得る。
【０２４５】
[0177]さらに、以下の提案される技法は、ＨＥＶＣまたはＨ．２６６参照ソフトウェアの場合のようなマージインデックス以外の追加のシグナリングなしに実行され得る。すなわち、いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０は、所定のルールのセットに基づいて、および明示的シグナリングを使用せずに以下の技法を実行するように構成され得る。ビデオエンコーダ２０は、現在ブロックのためのマージインデックスをシグナリングするように構成され得、ビデオデコーダ３０は、マージ候補を導出するために、ビデオエンコーダ２０が実行するのと同じプロシージャを実行するように構成され得る。したがって、受信されたマージインデックスを用いて、ビデオデコーダ３０は、不整合なしに（without any mismatch）同等のＭＶ情報を決定するように構成され得る。
【０２４６】
[0178]図１６は、現在ブロック４５０のための隣接ブロックの例示的なセットを示す。図１６に示されているように、陰影を付けられた隣接ブロックａ、ｅ、ｆ、ｊ、およびｋは、ＨＥＶＣにおいて空間マージ候補として使用されるものと同じである。本開示は、現在ブロック４５０の前にコーディングされる追加の隣接ブロックからの動き情報を使用することを提案する。そのような追加の隣接ブロックは隣接ブロックｂ、ｃ、ｄ、ｇ、ｈ、およびｉを含み得る。より多くの隣接ブロックから最終動きベクトル候補リストを導出することによって、より正確な動きベクトルが動きベクトル候補リストの中に（among）あるという可能性が増加される。
【０２４７】
[0179]図１６の例では、現在ブロック４５０は１６×１６であり、隣接ブロックの各々は４×４ブロックである。しかしながら、隣接ブロックが、現在ブロックのサイズに基づく異なるサイズのものであり得ることに留意されたい。概して、ビデオエンコーダ２０およびビデオデコーダ３０は、現在ブロック４５０のための候補の動きベクトル候補リストを構築するように構成され得、ここで、動きベクトル候補リストは、現在ブロックに対するある数の（a number of）隣接ブロックからの動きベクトル情報を含んでおり、ここにおいて、隣接ブロックの数は５よりも大きい。
【０２４８】
[0180]本開示の別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、隣接ブロックからの動き情報の動きベクトルヒストグラムベース順序付けを使用して動きベクトル候補リストを構築するように構成され得る。動きが空間的に均質である（たとえば、ピクチャ中の所与の空間ロケーションにおいて同じ、または同じに近い可能性がある）という仮定に基づいて、隣接ブロックの優勢（dominant）動き情報は、現在ブロックのために選択された動き情報である可能性が高い。したがって、ビデオエンコーダ２０およびビデオデコーダ３０は、隣接ブロックの動きベクトル分布から動きベクトルヒストグラムを導出するように構成され得る。上記で説明されたように、動きベクトル情報は３次元ベクトル（ＭＶｘ，ＭＶｙ，方向）を含み、ここで、ＭＶｘは動きベクトルの水平成分であり、ＭＶｙは動きベクトルの垂直成分であり、ここで、方向は、過去（参照リストＬ０）予測方向または将来（参照リストＬ１）予測方向のいずれかを指す。図１３を参照すると、ビデオエンコーダ２０およびビデオデコーダ３０は、特定の動きベクトルがどのくらいの頻度で（how often）隣接ブロックａ〜ｋの各々について同じであるかを決定し得る。
【０２４９】
[0181]ビデオエンコーダ２０およびビデオデコーダ３０は、複数の異なる方法でヒストグラム情報を使用し得る。一例では、ビデオエンコーダ２０およびビデオデコーダ３０は、どの動きベクトルが、したがって、どの隣接ブロックが候補リスト中の空間マージ候補として使用され得るかを決定するために、ヒストグラム情報を使用し得る。別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、どの順序でリストにいくつかの（certain）空間マージ候補を追加すべきかを決定するために、ヒストグラムを使用し得る。
【０２５０】
[0182]概して、ビデオエンコーダ２０およびビデオデコーダ３０は、隣接ピクセルまたはブロックから動きベクトルヒストグラムを導出するように構成され得る。上記で説明されたように、図１６は、１６×１６現在ブロック４５０の動きベクトルヒストグラムのために使用されるべき４×４隣接ブロック（ａ〜ｋ）の一例を示す。ハイライトされたブロック（ａ、ｅ、ｆ、ｊ、およびｋ）は、ＨＥＶＣにおける空間マージ候補のロケーションである。
【０２５１】
[0183]いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０は、あるサイズをもつ隣接ブロックの動きベクトル分布から動きベクトルヒストグラムを導出する。図１６は、ＭＶヒストグラムを構築するためにどんな隣接ブロック（ａ〜ｋ）が使用されるかを示す。隣接ブロックのユニットサイズは、特定のサイズ、たとえば、４×４、または動き補償のための何らかのあらかじめ定義された最小サイズであり得る。ブロックが、関連する動き情報（たとえば、イントラ予測されたブロック）を有しない場合、それらは、無視されるか、または他の隣接ブロックからの動き情報で満たされ得る。たとえば、隣接ブロックｈがイントラ予測されたブロックである場合、ビデオエンコーダ２０およびビデオデコーダ３０は、その隣接ブロックを単に使用しないことがある。他の例では、隣接ブロックｈがイントラ予測されたブロックである場合、ビデオエンコーダ２０およびビデオデコーダ３０は、隣接ブロックｈの左のブロックからの動き情報を使用し得る。
【０２５２】
[0184]図１６中の一例に示されているように、１６×１６現在ブロックのＭＶヒストグラムを構築するために、ビデオエンコーダ２０およびビデオデコーダ３０は、４×４のサイズをもつ（ブロックａからブロックｋまでの）１１個の隣接ブロックを調べ得る。隣接ブロックは、（最上行／左列を含む）図１６の場合のようにあらかじめ定義されるか、あるいは現在ブロックのサイズおよび／または形状に依存し得ることに留意されたい。
【０２５３】
[0185]別の例では、ヒストグラムは、隣接ブロックのサイズに比例するある重みを用いて構築され得る。たとえば、隣接ブロックに属するピクセルの数（またはユニットブロック、すなわち４×４ブロック）は、ヒストグラムのための重みとして使用され得る。すなわち、より大きいブロック（詳細には、より多くのピクセルを含んでいるブロック）からの動きベクトルは、それらのブロック内のピクセルの数に比例するより高い重みを有する。別の例では、ヒストグラムのための重みは、上述の２つのファクタ、すなわち、隣接ブロック内のピクセル（またはユニットブロック）の数と、現在ブロックに隣接するピクセル（またはユニットブロック）の数との組合せによって決定され得る。
【０２５４】
[0186]ビデオエンコーダ２０とビデオデコーダ３０の両方が、不整合を回避するためにヒストグラムを構築するために同等のルールに従うべきであることに留意されたい。ビデオエンコーダ２０およびビデオデコーダ３０の両方において同等のヒストグラムを仮定すれば、マージ候補のためのすべての以下の適応方式が、等価マージリストにつながることになる。
【０２５５】
[0187]動きベクトルヒストグラムを決定した後に、ビデオエンコーダ２０およびビデオデコーダ３０は、次いで、動きベクトル候補リスト中の空間マージ候補の順序を決定するためにヒストグラムを使用し得る。いくつかの例では、構築されたヒストグラムは、所与の（固定の）Ｎf個の空間マージ候補の順序を決定するために使用され得、ここで、Ｎfは固定空間候補の数である。一例として、固定のＮf個の空間候補は、ＨＥＶＣにおいて使用されるように、隣接ブロックａ、ｅ、ｆ、ｊ、およびｋであり得る。しかしながら、候補の総数の任意のサブセットが使用され得る。たとえば、図１６を参照すると、隣接ブロックａ〜ｋの任意の固定サブセットが空間マージ候補として使用され得る。
【０２５６】
[0188]利用可能な隣接ブロックの各動きベクトルの頻度に応じて、ヒストグラムからの最も頻度が高い動きベクトルが、最初にマージリストに挿入され、ヒストグラムからの最も頻度が低い動きベクトルが、リストに挿入されるべき空間マージ候補の中の最後の１つである。たとえば、図１６は、ＨＥＶＣにおいて使用される５つの空間マージ候補（ａ、ｅ、ｆ、ｊ、ｋ）を示す。それらの候補の固定順序（ＨＥＶＣにおけるｊ−ｅ−ｆ−ｋ−ａの順序）に従う代わりに、ビデオエンコーダ２０とビデオデコーダ３０の両方は、ＭＶヒストグラムから順序を適応的に決定する構成され得る。別の例では、各隣接ブロック（たとえば、４×４空間マージ候補）を検査する代わりに、空間マージング候補の並べ替えは、空間マージング候補を導出するために使用されるブロックを含んでいる予測ブロック（たとえば、ＨＥＶＣにおけるＰＵ）のサイズに基づく。
【０２５７】
[0189]図１７の例について考える。図１７に示されているように、３つの隣接ブロック（ｅ、ｇ、およびｈ）は動きベクトル０（ＭＶ０）を有し、４つの異なる隣接ブロック（ａ、ｂ、ｃ、およびｄ）は動きベクトル１（ＭＶ１）を有し、１つの隣接ブロック（ｆ）は動きベクトル２（ＭＶ２）を有し、２つの異なる隣接ブロック（ｉおよびｊ）は動きベクトル３（ＭＶ３）を有し、１つの隣接ブロック（ｋ）は動きベクトル４（ＭＶ４）を有する。したがって、ビデオエンコーダ２０およびビデオデコーダ３０は、固定候補ａ、ｅ、ｆ、ｊ、およびｋを使用して、動きベクトル候補リストを、ＭＶ１−候補ａ（インデックス０）、ＭＶ０−候補ｅ（インデックス０）、ＭＶ３候補ｊ（インデックス０）、ＭＶ２候補ｆ（インデックス０）、ＭＶ４−候補ｋ（インデックス０）のように順序付けるように構成されることになる。図１７の例は、すべての隣接ブロックが同じ重みを有すると仮定する。いくつかの例では、固定候補のうちの２つまたはそれ以上（two or more）がヒストグラム（たとえば、図１７中のＭＶ２およびＭＶ４）中で同じ発生回数を有する同じ関連する動きベクトルを有する場合、候補を検査するもののために所定の順序が使用され得る。図１７の例では、候補ｆは、候補ｋの前にリスト中に配置される。しかしながら、任意の所定の順序が使用され得る。
【０２５８】
[0190]本開示の別の例では、動きベクトルヒストグラムを決定した後に、ビデオエンコーダ２０およびビデオデコーダ３０は、次いで、順序にかかわらず、動きベクトル候補リスト中の空間マージ候補として隣接ブロックのうちのどれを使用すべきかを決定するためにヒストグラムを使用し得る。すなわち、固定Ｎf数の空間マージング候補を使用したではなく、ビデオエンコーダ２０およびビデオデコーダ３０は、リスト中の空間マージ候補としてすべての可能な隣接ブロックのうちのどれを使用すべきかを決定し得る。この例では、図１６に関して、すべての隣接ブロックａ〜ｋは、動きベクトル候補リスト中の空間マージ候補として含めるために考慮され得る。
【０２５９】
[0191]ビデオエンコーダ２０およびビデオデコーダ３０は、利用可能な隣接ブロックの総数のうちのどの隣接ブロックが、動きベクトル候補リスト中で所定の数（Ｎh）の候補を作成する（make up）ことになるかを決定するために、動きベクトルヒストグラムを使用し得る。上記で説明されたように、候補の所与のリストの順序のみを変更する代わりに、決定された空間マージ候補のロケーション（たとえば、どの実際の隣接ブロック）と順序の両方は、決定されたヒストグラム中の隣接動きベクトル分布から適応的に導出され得る。たとえば、Ｎh＝２である場合、隣接ブロックからの２つの最も頻度が高い動きベクトルが、マージリストにおいて頻度の順序で配置される。２つ以上の（more than one）隣接ブロックが、ヒストグラム中で最も頻度が高い動きベクトルに関連する場合、ビデオエンコーダ２０およびビデオデコーダ３０は、隣接ブロックのうちのどれを候補リスト中に配置すべきかを決定するために所定のルールを使用し得る。しかしながら、いかなるルールが使用されても、ヒストグラム中で最も高い頻度で出現する動きベクトルに関連する隣接ブロックが、動きベクトル候補リストに追加されることになることに留意されたい。この例によれば、図１７を参照すると、ＭＶ０に関連する隣接ブロックと、ＭＶ１に関連する隣接ブロックとが、動きベクトル候補リストに追加されることになる。
【０２６０】
[0192]いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０は、決定されたヒストグラムを使用するマージリスト構築のための上記の技法の両方を使用するように構成され得る。すなわち、ビデオエンコーダ２０およびビデオデコーダ３０は両方とも、ヒストグラムを使用して候補の固定セットを順序付け得、ならびにヒストグラムに基づいてある数（Ｎh）の非固定候補を追加すること得る。上述のように、Ｎf個の空間マージ候補のロケーションは、すべてのブロック、たとえば、図１６中のブロックａ、ｅ、ｆ、ｊ、およびｋ全体にわたって固定される。さらに、隣接ブロックからのＮhの最も高い頻度で出現する動き情報は、空間マージ候補としてリストに追加され、次いで、（Ｎf＋Ｎh）個の候補の順序は、決定されたヒストグラム中の関連する動きベクトルの発生頻度に基づいて決定される。
【０２６１】
[0193]別の例では、Ｎf個の空間マージ候補のロケーションは、すべてのブロック、たとえば、図１６中のブロックａ、ｅ、ｆ、ｊ、およびｋのすべてにわたって固定され、ビデオエンコーダ２０およびビデオデコーダ３０は、決定されたヒストグラムを使用して固定候補の順序を決定する。さらに、隣接ブロックからのＮhの最も高い頻度で出現する動き情報がリストに追加されるが、さらなる（additional）Ｎh個の候補は、ある所定の位置に（たとえば、図１６中のブロックｅからの動きベクトルの前または後に）挿入される。
【０２６２】
[0194]別の例では、本開示は、サブＰＵマージ候補、たとえば、上記で説明されたＡＴＭＶＰおよびＡＴＭＶＰ＿ＥＸＴ候補の適応順序付けについて説明する。ＪＥＭ２．０ソフトウェアの一例では、ＡＴＭＶＰおよびＡＴＭＶＰ＿ＥＸＴは、（たとえば、図１６に示されているように）常に候補ｋと候補ａとの間に配置される。マージリスト中の固定ロケーションにおいてＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴを配置する代わりに、ビデオエンコーダ２０およびビデオデコーダ３０は、他の利用可能なマージ候補、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ、またはそれらの組合せに関する（relate to）状態に応じて、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補を適応的に配置するように構成され得る。
【０２６３】
[0195]いくつかの例では、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補のロケーションを決定するために、２つの空間マージ候補間の動きベクトル差分（ＭＶＤ）が活用され得る。ビデオエンコーダ２０およびビデオデコーダ３０は、動きベクトルの関数としてＭＶＤを計算するように構成され得る。一例では、２つのＭＶ間の絶対差分和は、ＭＶＤ＝ａｂｓ（ＭＶx［１］−ＭＶx［０］）＋ａｂｓ（ＭＶy［１］−ＭＶy［０］）である。別の例では、関数は、ＭＶＤ＝（ＭＶx［１］−ＭＶx［０］）＊（ＭＶx［１］−ＭＶx［０］）＋（ＭＶy［１］−ＭＶy［０］）＊（ＭＶy［１］−ＭＶy［０］）として定義される。ＭＶＤを計算するための関数が、整数、１／２、１／４、１／８、または１／１６ピクセル精度などの動きベクトル精度に基づいて異なり得ることに留意されたい。
【０２６４】
[0196]たとえば、常に、図１６中の候補ｋと候補ａとの間にＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴを配置する最新のＪＥＭソフトウェアとは異なり、ビデオエンコーダ２０およびビデオデコーダ３０は、候補ｊと候補ｋとの間のＭＶＤ（ＭＶＤjk）に応じて、候補ｋの前にＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補を位置させるように構成され得る。ＭＶＤjkがしきい値ＴＨ１よりも小さいか、または別のしきい値ＴＨ２よりも大きい場合、すなわち、ＭＶＤjk＜ＴＨ１またはＭＶＤjk＞ＴＨ２である場合、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴは、候補ｋの前に位置する。たとえば、適応しきい値は、すべてのまたは（いくつかの）空間的に隣接する動きベクトルの間の最小ＭＶＤをとることによってＴＨ１を算出することと、最大ＭＶＤをとることによってＴＨ２を算出することとによって使用され得、ここで、算出は、同等のＭＶペアならびに（ＭＶｊおよびＭＶｋ）のペアを除外する。ビデオエンコーダ２０とビデオデコーダ３０の両方は、同等の隣接動きベクトルアクセスを有する（have access identical neighboring motion vectors）ので、算出は、同じＴＨ１およびＴＨ２をもたらすことになる。代替的に、ＴＨ１とＴＨ２の両方は実験的に決定され得、たとえば、１／１６ピクセルＭＶ精度でＴＨ１＝２およびＴＨ２＝８である。他の場合、候補ｋは、リスト中でＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴの前にある。同様に、ビデオエンコーダ２０およびビデオデコーダ３０は、候補ｅと候補ｆとの間のＭＶＤ（ＭＶＤef）を調べることによって、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補と候補ｆとの順序を決定するように構成され得る。ＭＶＤ算出のために使用される候補、すなわち、上記の例における候補ｋまたは候補ａのうちの１つがマージリスト中で利用可能であるか、またはそれらのいずれも利用可能でない場合（If one or neither of the candidates used for MVD computation, candidate k or candidate a in above example, is not available in the merge list）、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補は、デフォルト順序で動きベクトル候補リスト中に配置され得る。
【０２６５】
[0197]別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、それらの候補が動きベクトル候補リスト中でどこに位置することになるかを決定するために、ＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補の特性、たとえば、サブブロックＭＶの分散またはサブブロックＭＶの空間分布を分析するように構成され得る。分散が範囲［ＴＨ1，ＴＨ2］内にある場合、より高い優先度、すなわち、リスト中のより小さいインデックスが割り当てられる。範囲［ＴＨ1，ＴＨ2］は、最良のマージ候補としてＡＴＭＶＰまたはＡＴＭＶＰ＿ＥＸＴを選定した、前にコーディングされたブロックのサブブロックＭＶの平均分散によって、ＴＨ1＝Ｃ1＊Ｖａｒ1およびＴＨ2＝Ｃ2＊Ｖａｒ2のように決定され得、ここで、Ｖａｒ１およびＶａｒ２は、前にコーディングされたブロックから算出され、記憶される。係数Ｃ1およびＣ2は定数として固定であるか、あるいは現在ブロックのサイズおよび／または形状に依存し得る。範囲は現在ブロックのサイズおよび／または形状に依存し得る。より大きいブロックの場合、ＴＨ1とＴＨ2の両方は増加し、範囲はより広くなる。範囲は動きベクトル精度に依存し得る。
【０２６６】
[0198]別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、それらの候補の間の順序を決定するために、空間マージ候補とＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補の両方のステータスを分析するように構成され得る。たとえば、ＡＴＭＶＰまたはＡＴＭＶＰ＿ＥＸＴ候補からの最も頻度が高いサブブロック動きベクトル、または平均動きベクトルは、サブブロックの代表（delegate）ＭＶと見なされ得る。代表的動きベクトルは、空間候補、たとえば、図１６中のブロックｆに対するＭＶＤを算出するために使用され得る。ＭＶＤがＴＨ1よりも大きいが、ＴＨ2よりも小さい場合、ビデオエンコーダ２０およびビデオデコーダ３０は、空間候補の前にＡＴＭＶＰ／ＡＴＭＶＰ＿ＥＸＴ候補を配置するように構成され得る。
【０２６７】
[0199]ＨＥＶＣでは、組合せ動きベクトル（ｃｏｍｂｉ−ｍｖ：combination motion vector）候補は、両方の予測方向、すなわち、参照リストＬ０および参照リストＬ１のための２つの動きベクトルを含む、２つの利用可能な双方向マージ候補、すなわち、Ｃ１およびＣ２を使用して導出される。Ｃ１とＣ２の両方が双方向ＭＶを有する、すなわち、候補Ｃ１のためのＭＶL0C1およびＭＶL1C1、ならびに候補Ｃ２のためのＭＶL0C2およびＭＶL1C2と仮定する。ビデオエンコーダ２０およびビデオデコーダ３０は、Ｃ１からＬ０  ＭＶをとり、Ｃ２からＬ１  ＭＶをとることによって、新しいｃｏｍｂｉ−ｍｖ、すなわち（ＭＶ０，ＭＶ１）を導出するように構成され得、（ＭＶ０，ＭＶ１）＝（ＭＶL0C1，ＭＶL1C2）である。同様に、ビデオエンコーダ２０およびビデオデコーダ３０は、残りのＭＶをとることによって別のｃｏｍｂｉ−ｍｖを導出するように構成され得、（ＭＶ０’，ＭＶ１’）＝（ＭＶL0C2，ＭＶL1C1）であり得る。
【０２６８】
[0200]いくつかの例では、ｃｏｍｂｉ−ｍｖ候補の最大数は固定である。ＨＥＶＣでは、利用可能なマージ候補の数が、マージ候補の最大数、たとえば、ＨＥＶＣでは５よりも少なく、２つ以上の双方向マージ候補がリスト中で利用可能である場合、多くとも（at most）１２個のｃｏｍｂｉ−ｍｖ候補がマージ候補と見なされ得る。ＨＥＶＣの拡張では、ＡＴＭＶＰおよびＡＴＭＶＰ＿ＥＸＴ候補などのより多くのマージ候補が追加され、したがって、ｃｏｍｂｉ−ｍｖ候補の最大数を、１２からある大きい数（certain large number）、たとえば３０まで増加させることは、可能な拡張（possible extension）である。
【０２６９】
[0201]本開示の別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、必要な場合（たとえば、マージ候補の最大数にまだ達しない場合）より多くのｃｏｍｂｉ−ｍｖを考慮するように構成され得る。たとえば、利用可能なマージ候補間の類似度が、あるしきい値よりも高い場合、ｃｏｍｂｉ−ｍｖ候補はまた、既存の候補に類似することになり、したがって、ｃｏｍｂｉ−ｍｖの最大数は抑制される。類似度は、絶対差分和（ＳＡＤ：sum of absolute differences）、ＳＡＴＤ、平均ルミナンスまたはクロミナンス値、ピクセルの分散、および／またはＭＶ軌道によって測定され得る。
【０２７０】
[0202]より多くのｃｏｍｂｉ−ｍｖが考慮される場合、適応順序付けが、予備（spare）ｃｏｍｂｉ−ｍｖ候補からの利益を最大にすると見なされ得る。ｃｏｍｂｉ−ｍｖ候補の順序を仮定すれば、以下の技法は、ある基準に関して候補を並べ替える。その基準に入らない候補は、デフォルト順序に従う。
【０２７１】
[0203]いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０は、導出されたｃｏｍｂｉ−ｍｖと利用可能な候補からの既存のｍｖとの間の類似度に関して、ｃｏｍｂｉ−ｍｖ候補を並べ替える（reorder）ように構成され得る。Ｃ１とＣ２の両方が、双方向ＭＶ、すなわち、ＭＶC1＝（ＭＶL0C1，ＭＶL1C1）とＭＶC2＝（ＭＶL0C2，ＭＶL1C2）とを有し、２つのｃｏｍｂｉ−ｍｖがＭＶcombi-1＝（ＭＶL0C1，ＭＶL1C2）およびＭＶcombi-2＝（ＭＶL0C2，ＭＶL1C1）のように導出され得ると仮定する。ＭＶL0C1およびＭＶL0C2（ならびに／またはＭＶL1C2およびＭＶL1C1）が同じピクチャを指す場合、ＭＶL0C1とＭＶL0C2と（および／またはＭＶL1C2とＭＶL1C1と）の間のＭＶＤが算出される。次いで、ビデオエンコーダ２０およびビデオデコーダ３０は、以下の条件のうちの１つが満たされた場合、すなわち、（１）ＭＶＤが２つのしきい値間にある、すなわち、ＴＨ1＜ＭＶＤ＜ＴＨ2である場合、または（２）ＭＶL0C1とＭＶL0C2とが、異なるピクチャを指す場合、プルーニングの後に、動きベクトル候補リストに導出されたｃｏｍｂｉ−ｍｖを追加するように構成され得る。他の場合、ｃｏｍｂｉ−ｍｖは後に（behind）残される。１／１６ピクセル動きベクトル精度の場合の一例では、現在ブロックの幅と高さの両方が８よりも小さいとき、ＴＨ１＝２およびＴＨ２＝８である。現在ブロックの幅および高さが８よりも大きく、３２よりも小さい場合、ＴＨ１＝８およびＴＨ２＝３２である。幅および高さが３２よりも大きい場合、ＴＨ１＝１６およびＴＨ２＝６４である。それらの条件を満たすすべてのｃｏｍｂｉ−ｍｖ候補が最初にマージリストに追加されると、ビデオエンコーダ２０およびビデオデコーダ３０は、プルーニングの後にリストに残りのｃｏｍｂｉ−ｍｖを追加するように構成され得る。しきい値、ＴＨ1およびＴＨ2は、現在ブロックのサイズまたは形状、たとえば、ｍａｘ（幅，高さ）によって適応的に選定され得る。
【０２７２】
[0204]また別の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、上述のＭＶＤに関してｃｏｍｂｉ−ｍｖ候補をソートするように構成され得る。簡単のために、異なるピクチャを指すＭＶL0C1およびＭＶL0C2（またはＭＶL1C1およびＭＶL1C2）をもつ（whose）ｃｏｍｂｉ−ｍｖ候補のＭＶＤは、０として設定される。ｃｏｍｂｉ−ｍｖ候補が等しいＭＶＤ値を有する（have equal MVD values）場合、それらはデフォルト順序に従う。ソートされると、ビデオエンコーダ２０およびビデオデコーダ３０は、プルーニングの後に動きベクトル候補リストに候補を追加するように構成され得る。
【０２７３】
[0205]ＰＯＣベースプルーニングに加えて、上記で説明されたように、ビデオエンコーダ２０およびビデオデコーダ３０は、動きベクトル自体以外の追加情報（たとえば、現在ブロックのサイズおよび／または形状、ターゲットマージ候補のタイプ、ならびに／あるいは空間の場合（if spatial）マージ候補のロケーション）によって決定されるべき適応基準を使用してマージ候補をさらにプルーニングするように構成され得る。
【０２７４】
[0206]いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０は、適応しきい値よりも小さいＭＶＤをもつＭＶのペアを同等と見なし、したがって、動きベクトル候補リストをさらに多様化させるためにプルーニングされると見なす（consider a pair of MVs with smaller MVD than an adaptive threshold as identical, and thus pruned to diversify the motion vector candidate list further）ように構成され得る。しきい値は、現在ブロックのサイズおよび／または形状によって適応的に選定され得る。
【０２７５】
[0207]いくつかの例では、上記の適応しきい値を用いた（with）ＭＶＤベースプルーニングなどのプルーニング方法が、すべてのタイプのマージ候補、すなわち、空間候補、時間候補、サブブロック候補、またはｃｏｍｂｉ−ｍｖ候補に適用され得る。また別の例では、異なるタイプの候補について、異なる基準が考慮され得る。空間候補の一例として、それらの候補が導出されるロケーション間の距離が、適応しきい値を決定するためのメトリックとして使用され得る。たとえば、２つの動きベクトルが、隣接するブロック、たとえば、図１６中のブロックｅおよびｆから導出された場合、動きベクトルは、動きベクトルが遠い（distant）ブロック、たとえば、図１６中のブロックｆおよびｋから導出されたしきい値よりも小さいしきい値によってプルーニングされる。
【０２７６】
[0208]いくつかの例では、双方向マージ候補の場合、２つの単予測ブロック（uni-predicted blocks）（Ｌ０からの単予測ブロック、およびＬ１方向からの別の単予測ブロック）の類似度は、マージ候補がどのくらい信頼できるかを示すことができる（could）。この観測に基づいて、ビデオエンコーダ２０およびビデオデコーダ３０は、２つの単予測ブロックの類似度を使用することによって双方向マージ候補を区別する（differentiate）ために測定値を使用し、それに応じて、双方向マージ候補を並べ替えるように構成され得る。たとえば、ビデオエンコーダ２０およびビデオデコーダ３０は、類似度を決定するために、絶対差分和（ＳＡＤ）、ＳＳＥ、ＳＡＴＤ、平均ルミナンスまたはクロミナンス値、ピクセルの分散、および／あるいはＭＶ軌道を使用するように構成され得る。より複雑なメトリックが、予測性能を測定するためにより高い精度を与えることができる。メトリックの決定は、ターゲット適用例の要件に依存し得る。
【０２７７】
[0209]ＳＡＤが使用される場合、所与の２つの双方向マージ候補、Ｃ１およびＣ２のために、各双方向候補についてＬ０方向とＬ１方向との間で２つのＳＡＤ、すなわち、ＳＡＤC1およびＳＡＤC2が算出される。ビデオエンコーダ２０およびビデオデコーダ３０は、マージリスト中で、より小さい最終ＳＡＤ、すなわち、ＳＡＤＣ１またはＳＡＤＣ２をもつ候補を、他方の前方に（ahead of the other）配置するように構成され得る。
【０２７８】
[0210]いくつかの例では、上記で説明されたすべての提案される技法は、動きベクトル候補リストを構築するために組み合わせられ得る。また別の例では、提案される技法のあるセットまたはサブセットが組み込まれ得る。
【０２７９】
[0211]図１８は、本開示の例示的な符号化方法を示すフローチャートである。図１８の技法は、動き推定ユニット４２と動き補償ユニット４４とを含む、ビデオエンコーダ２０の１つまたは複数のハードウェアユニットによって実行され得る。
【０２８０】
[0212]本開示の一例では、ビデオエンコーダ２０は、ビデオデータの現在ブロックを受信するように構成され得る（５００）。ビデオエンコーダ２０は、現在ブロックに対する隣接ブロックのための動きベクトル情報のヒストグラムを導出し得る（５０２）。本開示の一例では、動きベクトル候補リストのために考慮される隣接ブロックの数は、現在ブロックのサイズに基づき、隣接ブロックの数は５よりも大きい。このコンテキストでは、「考慮される（considered）」という用語は、ビデオエンコーダ２０が、隣接ブロックを分析することと、隣接ブロックが関連する動き情報を有するかどうかを決定することと、隣接ブロックが関連する動き情報を有する場合、動きベクトル候補リストを構築するために動き情報を使用することとを含み得る。上記で説明されたように、動き情報は、動きベクトル候補リストに直接追加され得るか、または動きベクトル候補リスト中で空間マージ候補として使用すべき隣接ブロックの順序および／またはロケーションを決定するために使用され得るヒストグラムを構築するために使用され得る。ビデオエンコーダ２０は、ビデオデータの現在ブロックに対する（relative to）上記数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築するようにさらに構成され得る。いくつかの例では、考慮される動き情報は、導出されたヒストグラムである（５０４）。ビデオエンコーダ２０は、次いで、動きベクトル候補リストから現在動きベクトルを決定し（５０６）、現在動きベクトルを使用してビデオデータの現在ブロックを符号化する（５０８）。
【０２８１】
[0213]本開示の別の例では、ビデオエンコーダ２０は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける（order a predetermined fixed subset of spatial merge candidates in the motion vector candidate list based on the derived histogram）ように構成され得る。
【０２８２】
[0214]本開示の別の例では、ビデオエンコーダ２０は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の（a fixed number of）空間マージ候補を決定するように構成され得る。
【０２８３】
[0215]本開示の別の例では、ビデオエンコーダ２０は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、決定された固定数の空間マージ候補とを順序付けることとを行うように構成され得る。
【０２８４】
[0216]本開示の別の例では、ビデオエンコーダ２０は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、動きベクトル候補リスト中の所定のロケーションにおいて、決定された固定数の空間マージ候補を挿入することとを行うように構成され得る。
【０２８５】
[0217]本開示の別の例では、ビデオエンコーダ２０は、１つまたは複数の高度時間動きベクトル予測（ＡＴＭＶＰ）候補のための動きベクトルの関数に基づいて、動きベクトル候補リストにＡＴＭＶＰ候補を追加するように構成され得る。本開示の別の例では、ビデオエンコーダ２０は、１つまたは複数のＡＴＭＶＰ候補のための動きベクトルの関数に基づいて、ＡＴＭＶＰ候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【０２８６】
[0218]本開示の別の例では、ビデオエンコーダ２０は、２つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、動きベクトル候補リストに組合せ動きベクトル候補を追加することとを行うように構成され得る。
【０２８７】
[0219]本開示の別の例では、ビデオエンコーダ２０は、１つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、組合せ動きベクトル候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【０２８８】
[0220]本開示の別の例では、ビデオエンコーダ２０は、動きベクトル候補リスト中の動きベクトル候補の動きベクトル差分情報に基づいて、動きベクトル候補リストをプルーニングするように構成され得る。
【０２８９】
[0221]本開示の別の例では、ビデオエンコーダ２０は、動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、双方向候補を順序付けるように構成され得る。
【０２９０】
[0222]図１９は、本開示の例示的な復号方法を示すフローチャートである。図１９の技法は、動き補償ユニット７２を含む、ビデオデコーダ３０の１つまたは複数のハードウェアユニットによって実行され得る。
【０２９１】
[0223]本開示の一例では、ビデオデコーダ３０は、マージモードを使用して符号化されたビデオデータの現在ブロックを受信するように構成され得る（５５０）。ビデオデコーダ３０は、現在ブロックに対する隣接ブロックのための動きベクトル情報のヒストグラムを導出する（５５２）。本開示の一例では、動きベクトル候補リストのために考慮される隣接ブロックの数は、現在ブロックのサイズに基づき、隣接ブロックの数は５よりも大きい。このコンテキストでは、「考慮される」という用語は、ビデオデコーダ３０が、隣接ブロックを分析することと、隣接ブロックが関連する動き情報を有するかどうかを決定することと、隣接ブロックが関連する動き情報を有する場合、動きベクトル候補リストを構築するために動き情報を使用することとを含み得る。上記で説明されたように、動き情報は、動きベクトル候補リストに直接追加され得るか、または動きベクトル候補リスト中で空間マージ候補として使用すべき隣接ブロックの順序および／またはロケーションを決定するために使用され得るヒストグラムを構築するために使用され得る。ビデオデコーダ３０は、ビデオデータの現在ブロックに対する上記数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築するようにさらに構成され得る。いくつかの例では、考慮される動き情報は、導出されたヒストグラムである（５５４）。ビデオデコーダ３０は、次いで、動きベクトル候補リストから現在動きベクトルを決定し（５５６）、現在動きベクトルを使用してビデオデータの現在ブロックを復号する（５５８）。
【０２９２】
[0224]本開示の別の例では、ビデオデコーダ３０は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で所定の固定サブセットの空間マージ候補を順序付けるように構成され得る。
【０２９３】
[0225]本開示の別の例では、ビデオデコーダ３０は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定するように構成され得る。
【０２９４】
[0226]本開示の別の例では、ビデオデコーダ３０は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、決定された固定数の空間マージ候補とを順序付けることとを行うように構成され得る。
【０２９５】
[0227]本開示の別の例では、ビデオデコーダ３０は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、動きベクトル候補リスト中の所定のロケーションにおいて、決定された固定数の空間マージ候補を挿入することとを行うように構成され得る。
【０２９６】
[0228]本開示の別の例では、ビデオデコーダ３０は、１つまたは複数の高度時間動きベクトル予測（ＡＴＭＶＰ）候補のための動きベクトルの関数に基づいて、動きベクトル候補リストにＡＴＭＶＰ候補を追加するように構成され得る。本開示の別の例では、ビデオエンコーダ２０は、１つまたは複数のＡＴＭＶＰ候補のための動きベクトルの関数に基づいて、ＡＴＭＶＰ候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【０２９７】
[0229]本開示の別の例では、ビデオデコーダ３０は、２つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、動きベクトル候補リストに組合せ動きベクトル候補を追加することとを行うように構成され得る。
【０２９８】
[0230]本開示の別の例では、ビデオデコーダ３０は、１つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、組合せ動きベクトル候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【０２９９】
[0231]本開示の別の例では、ビデオデコーダ３０は、動きベクトル候補リスト中の動きベクトル候補の動きベクトル差分情報に基づいて、動きベクトル候補リストをプルーニングするように構成され得る。
【０３００】
[0232]本開示の別の例では、ビデオデコーダ３０は、動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、双方向候補を順序付けるように構成され得る。
【０３０１】
[0233]一例として、提案される技法の組合せは、以下の表の場合のように、ＪＥＭ２．０ソフトウェア上のランダムアクセス構成において０．４％のＢＤレート改善を示す。以下の例における利得は、（１）ヒストグラムベース空間マージ候補順序付け、（２）ＭＶＤベース組合せマージ候補順序付けおよびプルーニング、（３）ＡＴＭＶＰ、組合せ、０ｍｖ候補に対する（on）プルーニング、ならびに（４）増加された数のマージ候補およびｃｏｍｂｉマージ候補のツールの組合せから来る（comes）。
【０３０２】
【表２】
2019515587.tif 000008
【０３０３】
[0234]上記例に応じて、本明細書で説明された技法のうちのいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが本技法の実施のために必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実行され得る。
【０３０４】
[0235]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明される技法の実装のための命令、コードおよび／またはデータ構造を取り出すために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【０３０５】
[0236]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【０３０６】
[0237]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路など、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、上記の構造、または本明細書で説明された技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素で十分に実装され得る。
【０３０７】
[0238]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明された１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって与えられ得る。
【０３０８】
[0239]様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
【図１】
2019515587.tif 000009
【図２】
2019515587.tif 000010
【図３】
2019515587.tif 000011
【図４】
2019515587.tif 000012
【図５】
2019515587.tif 000013
【図６Ａ】
2019515587.tif 000014
【図６Ｂ】
2019515587.tif 000015
【図７（ａ）】
2019515587.tif 000016
【図７（ｂ）】
2019515587.tif 000017
【図８】
2019515587.tif 000018
【図９】
2019515587.tif 000019
【図１０】
2019515587.tif 000020
【図１１】
2019515587.tif 000021
【図１２】
2019515587.tif 000022
【図１３】
2019515587.tif 000023
【図１４】
2019515587.tif 000024
【図１５】
2019515587.tif 000025
【図１６】
2019515587.tif 000026
【図１７】
2019515587.tif 000027
【図１８】
2019515587.tif 000028
【図１９】
2019515587.tif 000029
【国際調査報告】
2019515587.tif 000030
2019515587.tif 000031
2019515587.tif 000032
2019515587.tif 000033