IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ クゥアルコム・インコーポレイテッドの特許一覧

特開2022-58517ビデオコーディングのための動きベクトル予測のためのマージ候補
<>
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図1
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図2
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図3
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図4
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図5
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図6A
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図6B
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図7
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図8
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図9
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図10
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図11
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図12
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図13
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図14
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図15
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図16
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図17
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図18
  • 特開-ビデオコーディングのための動きベクトル予測のためのマージ候補 図19
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022058517
(43)【公開日】2022-04-12
(54)【発明の名称】ビデオコーディングのための動きベクトル予測のためのマージ候補
(51)【国際特許分類】
   H04N 19/52 20140101AFI20220405BHJP
   H04N 19/105 20140101ALI20220405BHJP
   H04N 19/134 20140101ALI20220405BHJP
   H04N 19/139 20140101ALI20220405BHJP
   H04N 19/176 20140101ALI20220405BHJP
【FI】
H04N19/52
H04N19/105
H04N19/134
H04N19/139
H04N19/176
【審査請求】有
【請求項の数】22
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022000966
(22)【出願日】2022-01-06
(62)【分割の表示】P 2018559216の分割
【原出願日】2017-05-11
(31)【優先権主張番号】62/336,449
(32)【優先日】2016-05-13
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/591,813
(32)【優先日】2017-05-10
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】595020643
【氏名又は名称】クゥアルコム・インコーポレイテッド
【氏名又は名称原語表記】QUALCOMM INCORPORATED
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100158805
【弁理士】
【氏名又は名称】井関 守三
(74)【代理人】
【識別番号】100112807
【弁理士】
【氏名又は名称】岡田 貴志
(72)【発明者】
【氏名】ソンウォン・リ
(72)【発明者】
【氏名】ウェイ-ジュン・チェン
(72)【発明者】
【氏名】リ・ジャン
(72)【発明者】
【氏名】マルタ・カルチェビチ
(57)【要約】      (修正有)
【課題】マージベース動きベクトル予測の効率を改善するビデオデータの符号化方法及び復号方法を提供する。
【解決手段】ビデオデータの復号方法は、ビデオデータの現在ブロックに対する複数の隣接ブロックのうちの任意の隣接ブロックが動き情報を含むかどうかを決定するために、現在ブロックに対する複数の隣接ブロックを分析することと、複数の隣接ブロックのうちの隣接ブロックのセット内に含まれた動き情報にそれぞれ対応する複数の重みを決定することと、現在ブロックに対する隣接ブロックのセットからの動き情報に基づいて、現在ブロックのための動きベクトル候補リストを構築することと、複数の重みに基づいて、現在ブロックのための構築された動きベクトル候補リスト内の動きベクトル候補を適応的に順序付けることと、動きベクトル候補リスト内の動きベクトル候補から現在動きベクトルを決定することと、を含む。
【選択図】図19
【特許請求の範囲】
【請求項1】
ビデオデータを復号する方法であって、前記方法は、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を備える、方法。
【請求項2】
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
をさらに備える、請求項1に記載の方法。
【請求項3】
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けること
をさらに備える、請求項2に記載の方法。
【請求項4】
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定すること
をさらに備える、請求項2に記載の方法。
【請求項5】
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
をさらに備える、請求項2に記載の方法。
【請求項6】
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
をさらに備える、請求項2に記載の方法。
【請求項7】
1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにATMVP候補を追加すること
をさらに備える、請求項2に記載の方法。
【請求項8】
1つまたは複数のATMVP候補のための動きベクトルの前記関数に基づいて、前記ATMVP候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、請求項7に記載の方法。
【請求項9】
2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
をさらに備える、請求項2に記載の方法。
【請求項10】
1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、請求項9に記載の方法。
【請求項11】
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングすること
をさらに備える、請求項2に記載の方法。
【請求項12】
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付けること
をさらに備える、請求項2に記載の方法。
【請求項13】
ビデオデータを復号するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
マージモードで符号化されたビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行うように構成された、装置。
【請求項14】
前記1つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、請求項13に記載の装置。
【請求項15】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、請求項14に記載の装置。
【請求項16】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、請求項14に記載の装置。
【請求項17】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、請求項14に記載の装置。
【請求項18】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
を行うようにさらに構成された、請求項14に記載の装置。
【請求項19】
前記1つまたは複数のプロセッサが、
1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにATMVP候補を追加する
ようにさらに構成された、請求項14に記載の装置。
【請求項20】
前記1つまたは複数のプロセッサが、
1つまたは複数のATMVP候補のための動きベクトルの前記関数に基づいて、前記ATMVP候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、請求項19に記載の装置。
【請求項21】
前記1つまたは複数のプロセッサが、
2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
を行うようにさらに構成された、請求項14に記載の装置。
【請求項22】
前記1つまたは複数のプロセッサが、
1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、請求項14に記載の装置。
【請求項23】
前記1つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングする
ようにさらに構成された、請求項14に記載の装置。
【請求項24】
前記1つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付ける
ようにさらに構成された、請求項14に記載の装置。
【請求項25】
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータを復号するように構成された1つまたは複数のプロセッサに、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行わせる、コンピュータ可読記憶媒体。
【請求項26】
ビデオデータを符号化するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
ビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを符号化することと
を行うように構成された、装置。
【請求項27】
前記1つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、請求項26に記載の装置。
【請求項28】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、請求項27に記載の装置。
【請求項29】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、請求項27に記載の装置。
【請求項30】
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、請求項27に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、2016年5月13日に出願された米国仮出願第62/336,449号の利益を主張する。
【0002】
[0002]本開示は、ビデオコーディングに関する。
【背景技術】
【0003】
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4,Part10,アドバンストビデオコーディング(AVC:Advanced Video Coding)、高効率ビデオコーディング(HEVC:High Efficiency Video Coding)とも呼ばれるITU-T H.265によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法など、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および/または記憶し得る。
【0004】
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間(イントラピクチャ)予測および/または時間(インターピクチャ)予測を含む。ブロックベースビデオコーディングでは、ビデオスライス(たとえば、ビデオフレームまたはビデオフレームの一部分)が、いくつかの技法ではツリーブロック、コーディングユニット(CU)および/またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコード化(I)スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコード化(PまたはB)スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【0005】
[0005]空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルに従って符号化され、残差データは、コード化ブロックと予測ブロックとの間の差分を示す。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換され、残差変換係数が生じ得、その残差変換係数は、次いで量子化され得る。最初に2次元アレイで構成される量子化変換係数は、変換係数の1次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するために、エントロピーコーディングが適用され得る。
【発明の概要】
【0006】
[0006]概して、本開示は、ビデオデータのブロックのための動き情報のコーディング(たとえば、符号化または復号)に関係する技法について説明する。本開示の様々な例では、(マージ候補リストまたは単に候補リストとも呼ばれる)動きベクトル候補リストが、複数の隣接ブロックからの動き情報を使用して構築され得る。動き情報のヒストグラムが導出され、次いで、動きベクトル候補リストのための空間マージ候補の順序および/またはロケーションを決定するために使用され得る。
【0007】
[0007]一例では、本開示は、ビデオデータを復号する方法について説明し、本方法は、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が5よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを備える。
【0008】
[0008]別の例では、本開示は、ビデオデータを復号するように構成された装置について説明し、本装置は、ビデオデータの現在ブロックを記憶するように構成されたメモリと、1つまたは複数のプロセッサとを備え、1つまたは複数のプロセッサは、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が5よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを行うように構成される。
【0009】
[0009]別の例では、本開示は、命令を記憶するコンピュータ可読記憶媒体であって、命令が、実行されたとき、ビデオデータを復号するように構成された1つまたは複数のプロセッサに、マージモードで符号化されたビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が5よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを復号することとを行わせる、コンピュータ可読記憶媒体について説明する。
【0010】
[0010]一例では、本開示は、ビデオデータを符号化するように構成された装置について説明し、本装置は、ビデオデータの現在ブロックを記憶するように構成されたメモリと、1つまたは複数のプロセッサとを備え、1つまたは複数のプロセッサは、ビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が5よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックを符号化することとを行うように構成される。
【0011】
[0011]1つまたは複数の例の詳細が、添付の図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【0012】
図1】[0012]本開示の技法を実行するように構成され得る例示的なビデオ符号化および復号システムを示すブロック図。
図2】[0013]本開示の技法を実行するように構成され得るビデオエンコーダの一例を示すブロック図。
図3】[0014]本開示の技法を実行するように構成され得るビデオデコーダの一例を示すブロック図。
図4】[0015]高効率ビデオコーディング(HEVC)におけるコーディングユニット(CU)構造を示す概念図。
図5】[0016]インター予測モードのための例示的な区分タイプを示す概念図。
図6A】[0017]4分木2分木(QTBT:quad-tree-binary-tree)構造を使用するブロック区分の一例を示す概念図。
図6B】[0018]図6AのQTBT構造を使用するブロック区分に対応する例示的なツリー構造を示す概念図。
図7】[0019]HEVCにおける空間隣接候補を示す概念図。
図8】[0020]HEVCにおける時間動きベクトル予測(TMVP:temporal motion vector prediction)を示す概念図。
図9】[0021]3D-HEVCのための例示的な予測構造を示す概念図。
図10】[0022]3D-HEVCにおけるサブPUベースインタービュー動き予測を示す概念図。
図11】[0023]参照ピクチャからのサブPU動き予測を示す概念図。
図12】[0024]ATMVPにおける関連するピクチャを示す概念図。
図13】[0025]本開示の技法による、例示的な方法を示すフローチャート。
図14】[0026]PUおよび隣接ブロックの一例を示す概念図。
図15】[0027]PUおよび隣接ブロックの別の例を示す概念図。
図16】[0028]PUおよび隣接ブロックの別の例を示す概念図。
図17】[0029]PUおよび隣接ブロックの別の例を示す概念図。
図18】[0030]本開示の例示的な符号化方法を示すフローチャート。
図19】[0031]本開示の例示的な復号方法を示すフローチャート。
【発明を実施するための形態】
【0013】
[0032]本開示は、マージベース動きベクトル予測の効率を改善するための技法について説明する。本開示は、動きベクトル予測のために使用すべきマージ候補を決定するための技法について説明する。本開示の例示的な技法は、マージ候補の適応順序付けおよびプルーニング(adaptive ordering and pruning)を含み得る。本開示の例示的な適応順序付け技法は、空間、サブ予測ユニット(PU)、および組合せ動きベクトル(combi-mv:combined motion vector)候補の適応順序付けを含み得る。いくつかの例では、本開示の提案される適応プルーニング技法は、時間動きベクトル予測(TMVP)候補、0動きベクトル(0mv)候補、ならびに上述の候補を含む、すべてのマージ候補に適用され得る。
【0014】
[0033]本開示の技法は、以下の利益、すなわち、(1)より高い効率、(2)単純さ(たとえば、より低いデコーダ実装複雑さ)、および(3)フレキシビリティのうちの1つまたは複数を与え得る。本明細書で説明される技法は、実際の動きベクトルに値がより近い(または値がより近くなる可能性がある)マージ候補により高い優先度を割り当てることによって、より高いビット節約(bit-savings)を与え得る。さらに、ビデオエンコーダおよびビデオデコーダ複雑さ、ならびにメモリ要件は、比較的小さい。最後に、提案される技法は、H.266および4分木プラス2分木(QTBT:quad-tree plus binary tree )ベースビデオコーデックなど、様々なコーデックに適用され得る。さらに、提案される技法は、本明細書で説明される技法が、独立してまたは一緒に使用され得るように、技法が任意の様式で組み合わせられ得るようなフレキシビリティを与える。
【0015】
[0034]図1は、動きベクトル予測のための本開示の技法を実行するように構成され得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示されているように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを与えるソースデバイス12を含む。特に、ソースデバイス12は、コンピュータ可読媒体16を介してビデオデータを宛先デバイス14に与える。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14はワイヤレス通信のために装備され得る。
【0016】
[0035]宛先デバイス14は、コンピュータ可読媒体16を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が、符号化ビデオデータを宛先デバイス14にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【0017】
[0036]いくつかの例では、符号化データは、出力インターフェース22からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス12によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介してストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することと、その符号化ビデオデータを宛先デバイス14に送信することとが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブがある。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi-Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、またはその両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【0018】
[0037]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【0019】
[0038]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、動きベクトル予測のための本開示の技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなど、外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【0020】
[0039]図1の図示されたシステム10は一例にすぎない。動きベクトル予測のための本開示の技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオテレフォニーのための、ビデオデバイス12とビデオデバイス14との間の一方向または双方向のビデオ送信をサポートし得る。
【0021】
[0040]ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明される技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16上に出力され得る。
【0022】
[0041]コンピュータ可読媒体16は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-rayディスク、または他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)は、ソースデバイス12から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス14に与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体16は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
【0023】
[0042]宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、ブロックおよび他のコード化ユニット、たとえば、GOPの特性および/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、復号ビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【0024】
[0043]ビデオエンコーダ20およびビデオデコーダ30は、高効率ビデオコーディング(HEVC)規格、HEVC規格に対する拡張、またはITU-T H.266などの後続の規格など、ビデオコーディング規格に従って動作し得る。代替または追加として、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4,Part10,アドバンストビデオコーディング(AVC)と呼ばれるITU-T H.264規格など、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例としては、MPEG-2およびITU-T H.263がある。図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
【0025】
[0044]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路またはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してその命令をハードウェアで実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合され得る。
【0026】
[0045]以下でより詳細に説明されるように、ビデオエンコーダ20およびビデオデコーダ30は、ビデオデータの現在ブロックを受信することと、ビデオデータの現在ブロックに対するある数の(a number of)隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、動きベクトル候補リストのために考慮される隣接ブロックの数が現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの数が5よりも大きい、動きベクトル候補リストから現在動きベクトルを決定することと、現在動きベクトルを使用してビデオデータの現在ブロックをコーディングする(たとえば、符号化または復号する)こととを行うように構成され得る。
【0027】
[0046]ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびそれのスケーラブルビデオコーディング(SVC:Scalable Video Coding)拡張とマルチビュービデオコーディング(MVC:Multiview Video Coding)拡張とを含む、(ISO/IEC MPEG-4 AVCとしても知られる)ITU-T H.264を含む。MVCの1つのジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ITU-T勧告H.264、2010年3月に記載されている。
【0028】
[0047]さらに、ITU-Tビデオコーディングエキスパートグループ(VCEG:Video Coding Experts Group)とISO/IECモーションピクチャエキスパートグループ(MPEG:Motion Picture Experts Group)とのジョイントコラボレーションチームオンビデオコーディング(JCT-VC:Joint Collaboration Team on Video Coding)によって開発された、新たに開発されたビデオコーディング規格、すなわち、HEVCがある。HEVCの最近のドラフトは、http://phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zipから入手可能である。HEVC規格はまた、両方が「High efficiency video coding」と題する、両方が2014年10月に発行された、勧告ITU-T H.265および国際規格ISO/IEC23008-2において一緒に提示される。
【0029】
[0048]JCT-VCはHEVC規格を開発した。HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づいていた。HMは、たとえば、ITU-T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定した。たとえば、H.264は9つのイントラ予測符号化モードを与えるが、HEVC HMは33個ものイントラ予測符号化モードを与え得る。本開示は、説明の目的で何らかの(some)HEVC用語を使用し得るが、本開示の技法はHEVCに限定されず、実際は、本開示の技法が、HEVCの後継規格において実装され得ることが明示的に企図される。
【0030】
[0049]概して、HMの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット(LCU:largest coding unit)に分割され得ることを記載した。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるLCUのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木に従ってコーディングユニット(CU)にスプリットされ得る。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUにスプリットされた場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
【0031】
[0050]4分木データ構造の各ノードは、対応するCUのためのシンタックスデータを与え得る。たとえば、4分木のノードは、そのノードに対応するCUがサブCUにスプリットされるかどうかを示すスプリットフラグを含み得る。CUのためのシンタックス要素は、再帰的に定義され得、CUがサブCUにスプリットされるかどうかに依存し得る。CUがさらにスプリットされない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的スプリッティングが存在しない場合でも、リーフCUの4つのサブCUはリーフCUとも呼ばれる。たとえば、16×16サイズのCUがさらにスプリットされない場合、その16×16CUが決してスプリットされなくても、4つの8×8サブCUはリーフCUとも呼ばれる。
【0032】
[0051]CUは、CUがサイズ差異を有しないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、(サブCUとも呼ばれる)4つの子ノードにスプリットされ得、各子ノードは、今度は親ノードとなり、別の4つの子ノードにスプリットされ得る。4分木のリーフノードと呼ばれる、最後のスプリットされていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大CU深度と呼ばれる、ツリーブロックがスプリットされ得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット(SCU:smallest coding unit)をも定義し得る。本開示は、HEVCのコンテキストにおけるCU、PU、またはTU、あるいは他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれのサブブロック)のいずれかを指すために「ブロック」という用語を使用する。
【0033】
[0052]CUは、コーディングノードと、コーディングノードに関連する予測ユニット(PU)および変換ユニット(TU)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。CUのサイズは、8×8ピクセルから最大64×64ピクセル以上をもつツリーブロックのサイズまでに及び得る。各CUは、1つまたは複数のPUと、1つまたは複数のTUとを含んでいることがある。CUに関連するシンタックスデータは、たとえば、CUを1つまたは複数のPUに区分することを記述し得る。区分モード(partitioning mode)は、CUが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。PUは、形状が非正方形になるように区分され得る。CUに関連するシンタックスデータは、たとえば、4分木に従ってCUを1つまたは複数のTUに区分することをも記述し得る。TUは、形状が正方形または非正方形(たとえば、矩形)であり得る。
【0034】
[0053]HEVC規格は、CUごとに異なり得るTUに従う変換を可能にする。TUは、一般に、区分されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ決定されるが、これは常にそうであるとは限らない。TUは、一般に、PUと同じサイズであるかまたはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用してより小さいユニットに再分割され得る。RQTのリーフノードは変換ユニット(TU)と呼ばれることがある。TUに関連するピクセル差分値は、変換係数を生成するために変換され得、その変換係数は量子化され得る。
【0035】
[0054]リーフCUは、1つまたは複数の予測ユニット(PU)を含み得る。概して、PUは、対応するCUの全部または一部分に対応する空間エリアを表し、そのPUのための参照サンプルを取り出すためのデータを含み得る。その上、PUは、予測に関係するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUのデータは、PUに対応するTUについてのイントラ予測モードを記述するデータを含み得る残差4分木(RQT)中に含まれ得る。別の例として、PUがインターモード符号化されるとき、PUは、PUのための1つまたは複数の動きベクトルを定義するデータを含み得る。PUのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度(たとえば、1/4ピクセル精度または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルの参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)を記述し得る。
【0036】
[0055]1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換ユニット(TU)を含み得る。変換ユニットは、上記で説明されたように、(TU4分木構造とも呼ばれる)RQTを使用して指定され得る。たとえば、スプリットフラグは、リーフCUが4つの変換ユニットにスプリットされるかどうかを示し得る。次いで、各変換ユニットは、さらなるサブTUにさらにスプリットされ得る。TUがさらにスプリットされないとき、そのTUはリーフTUと呼ばれることがある。概して、イントラコーディングでは、リーフCUに属するすべてのリーフTUは同じイントラ予測モードを共有する。すなわち、概して、リーフCUのすべてのTUの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングでは、ビデオエンコーダは、イントラ予測モードを使用して各リーフTUの残差値を、TUに対応するCUの一部と元のブロックとの間の差分として計算し得る。TUは、必ずしもPUのサイズに制限されるとは限らない。したがって、TUは、PUよりも大きいことも小さいこともある。イントラコーディングでは、PUは、同じCUのための対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
【0037】
[0056]その上、リーフCUのTUはまた、残差4分木(RQT)と呼ばれる、それぞれの4分木データ構造に関連し得る。すなわち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含み得る。TU4分木のルートノードは概してリーフCUに対応し、CU4分木のルートノードは概してツリーブロック(またはLCU)に対応する。スプリットされないRQTのTUはリーフTUと呼ばれる。概して、本開示は、特に明記しない限り、リーフCUおよびリーフTUに言及するためにそれぞれCUおよびTUという用語を使用する。
【0038】
[0057]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ(GOP:group of pictures)は、概して、ビデオピクチャのうちの一連の1つまたは複数を備える。GOPは、GOP中に含まれるいくつかのピクチャを記述するシンタックスデータを、GOPのヘッダ中、ピクチャのうちの1つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックはCU内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定されたコーディング規格に応じてサイズが異なり得る。
【0039】
[0058]一例として、HMは、様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズでのイントラ予測と、2N×2N、2N×N、N×2N、またはN×Nの対称PUサイズでのインター予測とをサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、または「Right」という表示によって示される。したがって、たとえば、「2N×nU」は、上部の2N×0.5N PUと下部の2N×1.5N PUとで水平方向に区分された2N×2N CUを指す。
【0040】
[0059]本開示では、「N×N(NxN)」および「N×N(N by N)」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、16×16(16x16)ピクセルまたは16×16(16 by 16)ピクセルを指すために互換的に使用され得る。概して、16×16ブロックは、垂直方向に16ピクセルを有し(y=16)、水平方向に16ピクセルを有する(x=16)。同様に、N×Nブロックは、概して、垂直方向にNピクセルを有し、水平方向にNピクセルを有し、ここで、Nは非負整数値を表す。ブロック中のピクセルは行および列に配列され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはN×Mピクセルを備え得、ここで、Mは必ずしもNに等しいとは限らない。
【0041】
[0060]CUのPUを使用したイントラ予測コーディングまたはインター予測コーディングの後に、ビデオエンコーダ20は、CUのTUのための残差データを計算し得る。PUは、(ピクセル領域とも呼ばれる)空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、TUは、変換、たとえば、残差ビデオデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、CUのための変換係数を生成するためにTUを変換し得る。
【0042】
[0061]変換係数を生成するための任意の変換の後に、ビデオエンコーダ20は変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にnビット値がmビット値に切り捨てられ得、ここで、nはmよりも大きい。
【0043】
[0062]量子化の後に、ビデオエンコーダは、変換係数を走査し、量子化変換係数を含む2次元行列から1次元ベクトルを生成し得る。走査は、アレイの前部により高いエネルギー(したがって、より低い周波数)係数を配置し、アレイの後部により低いエネルギー(したがって、より高い周波数)係数を配置するように設計され得る。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は適応型走査を実行し得る。1次元ベクトルを形成するために量子化変換係数を走査した後に、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC:context-adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context-adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【0044】
[0063]CABACを実行するために、ビデオエンコーダ20は、コンテキストモデル内のコンテキストを、送信されるべきシンボルに割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非0であるか否かに関係し得る。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボルのための可変長コードを選択し得る。VLC中のコードワードは、比較的より短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、VLCの使用は、たとえば、送信されるべき各シンボルのための等長コードワードを使用することに勝るビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
【0045】
[0064]図2は、以下でより詳細に説明されるように、動きベクトル予測のための本開示の技法を実行するように構成され得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオの時間冗長性を低減または除去するために時間予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースコーディングモードのいずれかを指すことがある。単方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースコーディングモードのいずれかを指すことがある。
【0046】
[0065]図2に示されているように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、ビデオデータメモリ41と、モード選択ユニット40と、参照ピクチャメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。モード選択ユニット40は、今度は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、区分ユニット48とを含む。ビデオブロック再構築のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。再構築されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するための(図2に示されていない)デブロッキングフィルタも含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器62の出力をフィルタ処理することになる。(ループ中またはループ後の)追加のフィルタもデブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理し得る。
【0047】
[0066]ビデオデータメモリ41は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶するように構成され得る。ビデオデータメモリ41に記憶されたビデオデータは、たとえば、ビデオソース18から取得され得る。(復号ピクチャバッファと呼ばれることがある)参照ピクチャメモリ64は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ20によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ41および参照ピクチャメモリ64は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗性RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ41および参照ピクチャメモリ64は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ41は、ビデオエンコーダ20の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
【0048】
[0067]符号化プロセス中に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間予測を行うために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は、代替的に、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
【0049】
[0068]その上、区分ユニット48は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット48は、初めにフレームまたはスライスをLCUに区分し、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブCUに区分し得る。モード選択ユニット40は、さらに、サブCUへのLCUの区分を示す4分木データ構造を生成し得る。4分木のリーフノードCUは、1つまたは複数のPUと1つまたは複数のTUとを含み得る。
【0050】
[0069]モード選択ユニット40は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの1つを選択し得、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器50に与え、参照フレームとして使用するための符号化ブロックを再構築するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器62に与える。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報など、シンタックス要素をエントロピー符号化ユニット56に与える。
【0051】
[0070]動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別個に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを発生するプロセスである。動きベクトルは、たとえば、現在フレーム(または他のコード化ユニット)内でコーディングされている現在ブロックに対する参照フレーム(または他のコード化ユニット)内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。予測ブロックは、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置と分数ピクセル位置とに対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
【0052】
[0071]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの各々が、参照ピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56と動き補償ユニット44とに送る。
【0053】
[0072]動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴い得る。この場合も、動き推定ユニット42および動き補償ユニット44は、いくつかの例では、機能的に統合され得る。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、動きベクトルが参照ピクチャリストのうちの1つにおいてそれを指す予測ブロックの位置を特定し得る。加算器50は、以下で説明されるように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット42はルーマ成分に対して動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
【0054】
[0073]動き推定ユニット42と動き補償ユニット44とを含むビデオエンコーダ20は、図1に関して上記で説明された、および以下でより詳細に説明される本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット44は、本開示の技法に従ってAMVPモードまたはマージモードを使用してビデオデータのブロックのための動き情報をコーディングするように構成され得る。さらに、動き推定ユニット42と動き補償ユニット44とを含むビデオエンコーダ20は、以下でより詳細に説明される、本開示の動きベクトル候補リスト構築技法の任意の組合せを実行するように構成され得る。本開示のコンテキストでは、動きベクトル候補リスト、マージ候補リスト、および候補リストという用語は、互換的に使用され得る。
【0055】
[0074]動き補償ユニット44がマージモードを実行することを選ぶと仮定すると、動き補償ユニット44は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット44は、特定の、所定の順序に基づいて候補リストに候補を追加し得る。本開示の他の例では、動き補償ユニット44は、隣接ブロックからの動きベクトルのヒストグラム情報に基づいて、動的に異なる順序で候補リストに候補を追加するように構成され得る。動き補償ユニット44はまた、以下でより詳細に説明されるように、追加の候補を追加し、候補リストのプルーニングを実行し得る。最終的に、モード選択ユニット40は、現在ブロックの動き情報を符号化し、選択された候補を表すマージインデックスを符号化するために、それらの候補のうちのどれが使用されるべきかを決定し得る。
【0056】
[0075]イントラ予測ユニット46は、上記で説明されたように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
【0057】
[0076]たとえば、イントラ予測ユニット46は、様々なテストされるイントラ予測モードのためにレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測ユニット46は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのためのひずみおよびレートから比を計算し得る。
【0058】
[0077]ブロックのためのイントラ予測モードを選択した後に、イントラ予測ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に与え得る。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを送信ビットストリーム中に含め得る。
【0059】
[0078]ビデオエンコーダ20は、コーディングされている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。
【0060】
[0079]いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
【0061】
[0080]量子化の後に、エントロピー符号化ユニット56は量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングの後に、符号化ビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。
【0062】
[0081]逆量子化ユニット58および逆変換ユニット60は、たとえば、参照ブロックとして後で使用するために、ピクセル領域において残差ブロックを再構築するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するサブ整数ピクセル値を計算するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用し得る。加算器62は、参照ピクチャメモリ64に記憶するための再構築されたビデオブロックを生成するために、動き補償ユニット44によって生成された動き補償予測ブロックに再構築された残差ブロックを加算する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
【0063】
[0082]このようにして、図2のビデオエンコーダ20は、現在ブロックに対する(relative to)隣接ブロックから動きベクトル情報のヒストグラムを導出し、導出されたヒストグラムに基づいて、現在ブロックのための動きベクトル予測のための動きベクトル候補リストのためのマージ候補を決定し、導出されたヒストグラムに基づいて、動きベクトル候補リストを順序付け(order)、動きベクトル候補リストを使用してマージベクトル予測を実行するように構成されたビデオコーダの一例を表す。
【0064】
[0083]図3は、本開示の動きベクトル予測技法を実行するように構成され得るビデオデコーダ30の一例を示すブロック図である。図3の例では、ビデオデコーダ30は、ビデオデータメモリ71と、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明された符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
【0065】
[0084]ビデオデータメモリ71は、ビデオデコーダ30の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ71に記憶されるビデオデータは、たとえば、コンピュータ可読媒体16から、たとえば、カメラなどのローカルビデオソースから、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介して、あるいは物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ71は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ(CPB)を形成し得る。(復号ピクチャバッファ(DPB)とも呼ばれる)参照ピクチャメモリ82は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオデコーダ30によってビデオデータを復号する際に使用するための、または出力のための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ71および参照ピクチャメモリ82は、DRAM、SDRAM、MRAM、RRAM、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ71および参照ピクチャメモリ82は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ71は、ビデオデコーダ30の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
【0066】
[0085]復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、量子化係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット70は、動きベクトルと他のシンタックス要素とを動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
【0067】
[0086]ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化(たとえば、BBまたはP)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照フレームリスト、すなわち、リスト0とリスト1とを構築し得る。
【0068】
[0087]動き補償ユニット72は、動きベクトルと他のシンタックス要素とをパースすることによって現在ビデオスライスのビデオブロックのための予測情報を決定し、復号されている現在ビデオブロックのための予測ブロックを生成するために、その予測情報を使用する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、BスライスまたはPスライス)と、スライスのための参照ピクチャリストのうちの1つまたは複数のための構築情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつかを使用する。
【0069】
[0088]動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、参照ブロックのサブ整数ピクセルの補間値を計算するために、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するためにその補間フィルタを使用し得る。
【0070】
[0089]動き補償ユニット72を含むビデオデコーダ30は、図1に関して上記で説明された、および以下でより詳細に説明される本開示の様々な技法のいずれかを実行するように構成され得る。たとえば、動き補償ユニット72は、本開示の技法に従ってAMVPモードまたはマージモードを使用して動きベクトル予測を実行するように構成され得る。さらに、動き補償ユニット72を含むビデオデコーダ30は、以下でより詳細に説明される、本開示の動きベクトル候補リスト構築技法の任意の組合せを実行するように構成され得る。エントロピー復号ユニット70は、動き情報が現在ブロックについてどのようにコーディングされるかを表す1つまたは複数のシンタックス要素を復号し得る。
【0071】
[0090]マージモードが実行されることをシンタックス要素が示すと仮定すると、動き補償ユニット72は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット72は、特定の、所定の順序に基づいて候補リストに候補を追加し得る。本開示の他の例では、動き補償ユニット72は、隣接ブロックからの動きベクトルのヒストグラム情報に基づいて、動的に異なる順序で候補リストに候補を追加するように構成され得る。動き補償ユニット72はまた、以下でより詳細に説明されるように、追加の候補を追加し、候補リストのプルーニングを実行し得る。最終的に、動き補償ユニット72は、現在ブロックのための動き情報をコーディングするために、それらの候補のうちのどれが使用されるかを表すマージインデックスを復号し得る。
【0072】
[0091]逆量子化ユニット76は、ビットストリーム中で与えられ、エントロピー復号ユニット70によってエントロピー復号された量子化変換係数を逆量子化、すなわち、量子化解除する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ30によって計算される量子化パラメータQPYの使用を含み得る。
【0073】
[0092]逆変換ユニット78は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
【0074】
[0093]動き補償ユニット72が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、他のループフィルタも(コーディングループ中またはコーディングループ後のいずれかで)使用され得る。所与のフレームまたはピクチャの復号ビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ82に記憶される。参照ピクチャメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上での後の提示のために、復号ビデオを記憶する。
【0075】
[0094]このようにして、ビデオデコーダ30は、現在ブロックに対する隣接ブロックから動きベクトル情報のヒストグラムを導出し、導出されたヒストグラムに基づいて、現在ブロックのための動きベクトル予測のための動きベクトル候補リストのためのマージ候補を決定し、導出されたヒストグラムに基づいて、動きベクトル候補リストを順序付け、動きベクトル候補リストを使用してマージベクトル予測を実行するように構成されたビデオコーダの一例を表す。
【0076】
[0095]以下のセクションは、ビデオコーディング技法および規格のいくつかの態様について、特に、動きベクトル予測および関係する技法を考慮して説明する。最初に、動き情報が説明される。インター予測モードを使用してコーディングされるビデオデータの各ブロックについて、動き情報のセットが利用可能であり得る。動き情報のセットは、前方予測方向および後方予測方向のための動き情報を含んでいる。ここで、前方予測方向および後方予測方向は、現在ピクチャまたはスライスの参照ピクチャリスト0(RefPicList0)と参照ピクチャリスト1(RefPicList1)とに対応する2つの予測方向である。「前方」および「後方」という用語は、必ずしも幾何学的な意味を有するとは限らない。代わりに、それらは、動きベクトルがどの参照ピクチャリストに基づくかを区別するために使用される。前方予測は、参照リスト0に基づいて形成された予測を意味し、後方予測は、参照リスト1に基づいて形成された予測を意味する。参照リスト0と参照リスト1の両方が、所与のブロックのための予測を形成するために使用される場合、それは双方向予測と呼ばれる。
【0077】
[0096]所与のピクチャまたはスライスについて、ただ1つの参照ピクチャリストが使用される場合、ピクチャまたはスライス内のあらゆるブロックが前方予測される。両方の参照ピクチャリストが所与のピクチャまたはスライスのために使用される場合、ピクチャまたはスライス内のブロックは、前方予測されるか、後方予測されるか、または双方向予測され得る。
【0078】
[0097]各予測方向について、動き情報はまた、参照インデックスと動きベクトルとを含む。参照インデックスは、対応する参照ピクチャリスト(たとえばRefPicList0またはRefPicList1)中の参照ピクチャを識別するために使用される。動きベクトルは、水平成分と垂直成分の両方を有し、各成分が、それぞれ、水平方向および垂直方向に沿ったオフセット値を示す。動きベクトルは、コーディングされている現在ブロックの位置に対する予測子ブロックの位置を示す。参照インデックスは、予測子ブロック(predictor block)を含んでいるピクチャを示す。いくつかの説明では、簡単のために、「動きベクトル」という用語は、動きベクトルとそれの関連する参照インデックスの両方を示すために、動き情報と互換的に使用され得る。
【0079】
[0098]ビデオコーディング規格において、ピクチャの表示順序を識別するためにピクチャ順序カウント(POC:picture order count)が広く使用されている。1つのコード化ビデオシーケンス内の2つのピクチャが同じPOC値を有し得る場合があるが、一般に、それはコード化ビデオシーケンス内で起こらない。複数のコード化ビデオシーケンスがビットストリーム中に存在するとき、POCの同じ値をもつピクチャは、復号順序に関して互いに近いことがある。ピクチャのPOC値は、一般に、参照ピクチャリスト構築と、HEVCの場合のような参照ピクチャセットの導出と、動きベクトルスケーリングとのために使用される。
【0080】
[0099]次のセクションは、アドバンストビデオコーディング(AVC)(H.264)におけるマクロブロック(MB)構造について説明する。H.264/AVCでは、各インターマクロブロック(MB)(たとえば、インター予測を使用してコーディングされるMB)は、4つの異なる方法で区分され得る。
・1つの16×16MB区分
・2つの16×8MB区分
・2つの8×16MB区分
・4つの8×8MB区分
[0100]1つのMB中の異なるMB区分は、各予測方向について異なる参照インデックス値(RefPicList0またはRefPicList1)を有し得る。MBが4つの8×8MB区分に区分されないとき、MBは、各MB区分について各予測方向に1つの動きベクトルのみを有する。
【0081】
[0101]MBが4つの8×8MB区分に区分されるとき、各8×8MB区分は、その各々が各予測方向に異なる動きベクトルを有することができるサブブロックにさらに区分され得る。8×8MB区分をサブブロックに分割するための4つの異なる方法がある。
・1つの8×8サブブロック
・2つの8×4サブブロック
・2つの4×8サブブロック
・4つの4×4サブブロック
[0102]各サブブロックは、各予測方向に異なる動きベクトルを有し得る。したがって、動きベクトルは、サブブロックに等しいかまたはそれよりも高いレベルにおいて存在する。
【0082】
[0103]AVCにおける時間直接モード(Temporal direct mode)は説明されない。AVCでは、時間直接モードは、Bスライス中のスキップまたは直接モードについてMBレベルまたはMB区分レベルのいずれかにおいて有効にされ得る。各MB区分について、動きベクトルを導出するために、現在ブロックのRefPicList1[0]中の現在MB区分とコロケートされたブロックの動きベクトルが使用される。コロケートされたブロック中の各動きベクトルは、POC距離に基づいてスケーリングされる。AVCでは、直接モードはまた、空間ネイバーから動き情報を予測することができる。
【0083】
[0104]次に、HEVCにおけるコーディングユニット(CU)構造が説明される。HEVCでは、スライス中の最大コーディングユニットは、コーディングツリーブロック(CTB)またはコーディングツリーユニット(CTU)と呼ばれる。CTBは、それのノードがコーディングユニットである4分木を含んでいる。CTBは、W.J.Hanら、「Improved Video Compression Efficiency Through Flexible Unit Representation and Corresponding Extension of Coding Tools」、IEEE Transaction on Circuits and Systems for Video Technology、vol.20、no.12、1709~1720ページ、2010年12月に記載され、図4に示されているように、4分木様式でCUに再帰的にスプリットされ得る。図4に示されているように、区分の各レベルは、4つのサブブロックにスプリットされた4分木である。黒いブロックは、リーフノード(すなわち、さらにスプリットされないブロック)の一例である。
【0084】
[0105](技術的に、8×8CTBサイズがサポートされ得るが)CTBのサイズは、HEVCメインプロファイルにおいて16×16から64×64に及び得る。CUは、CTBの同じサイズであり得るが、8×8程度に小さくなり得る。各CUは1つのモード(たとえば、イントラ予測モードまたはインター予測モード)を用いてコーディングされる。CUがインターコーディングされるとき、CUは、2つまたは4つの予測ユニット(PU)にさらに区分され得るか、あるいは、さらなる区分が適用されないとき、ただ1つのPUになり得る。1つのCU中に2つのPUが存在するとき、それらのPUは、1/2サイズの長方形、あるいはCUの1/4または3/4サイズである2つの長方形であり得る。
【0085】
[0106]CUがインターコーディングされるとき、各PUについて動き情報の1つのセット(たとえば、動きベクトル、予測方向、および参照ピクチャ)が存在する。さらに、各PUは、動き情報のセットを導出するために固有のインター予測モードを用いてコーディングされる。しかしながら、2つのPUが固有に(uniquely)コーディングされるさえ(even)、それらは、依然として(still)、いくつかの状況において同じ動き情報を有し得ることを理解されたい。
【0086】
[0107]HEVCでは、図5に示されているように、インター予測モードを用いてコーディングされるCUのための8つの区分モード(partition mode)、すなわち、PART_2N×2N、PART_2N×N、PART_N×2N、PART_N×N、PART_2N×nU、PART_2N×nD、PART_nL×2N、およびPART_nR×2Nがある。区分モードPART_2N×2Nを用いてコーディングされるCUは、さらにスプリットされない。すなわち、CU全体が単一のPU(PU0)として扱われる。区分モードPART_2N×Nを用いてコーディングされるCUは、対称的に水平方向に(horizontally)2つのPU(PU0およびPU1)にスプリットされる。区分モードPART_N×2Nを用いてコーディングされるCUは、対称的に垂直方向に2つのPUにスプリットされる。区分モードPART_N×Nを用いてコーディングされるCUは、対称的に4つの等しいサイズのPU(PU0、PU1、PU2、PU3)にスプリットされる。
【0087】
[0108]区分モードPART_2N×nUを用いてコーディングされるCUは、非対称的に水平方向に、CUの1/4のサイズを有する1つのPU0(上側PU)と、CUの3/4のサイズを有する1つのPU1(下側PU)とにスプリットされる。区分モードPART_2N×nDを用いてコーディングされるCUは、非対称的に水平方向に、CUの3/4のサイズを有する1つのPU0(上側PU)と、CUの1/4のサイズを有する1つのPU1(下側PU)とにスプリットされる。区分モードPART_nL×2Nを用いてコーディングされるCUは、非対称的に垂直方向に、CUの1/4のサイズを有する1つのPU0(左PU)と、CUの3/4のサイズを有する1つのPU1(右PU)とにスプリットされる。区分モードPART_nR×2Nを用いてコーディングされるCUは、非対称的に垂直方向に、CUの3/4のサイズを有する1つのPU0(左PU)と、CUの1/4のサイズを有する1つのPU1(右PU)とにスプリットされる。
【0088】
[0109]HEVCは4分木区分構造を使用するが、将来のビデオコーディング規格のために他の区分構造が研究されている。たとえば、J.Anら、「Block partitioning structure for next generation video coding」、国際電気通信連合、COM16-C966、2015年9月(以下、「VCEG提案COM16-C966」)では、4分木2分木(QTBT)区分技法が、HEVC以外の(beyond)将来のビデオコーディング規格(たとえば、H.266)のために提案された。シミュレーションは、提案されたQTBT構造が、いくつかのビデオシーケンスについて、使用されるHEVCにおける4分木構造よりも効率的であることを示した。
【0089】
[0110]VCEG提案COM16-C966の提案されたQTBT構造では、4分木分割技法を使用してCTBが最初に区分され、ここで、1つのノードの4分木スプリッティングは、ノードが最小許容4分木リーフノードサイズに達するまで反復され得る。最小許容4分木リーフノードサイズは、シンタックス要素MinQTSizeの値によってビデオデコーダに示され得る。4分木リーフノードサイズが(たとえば、シンタックス要素MaxBTSizeによって示される)最大許容2分木ルートノードサイズよりも大きくない場合、4分木リーフノードは、2分木区分を使用してさらに区分され得る。1つのノードの2分木区分は、ノードが、(たとえば、シンタックス要素MinBTSizeによって示されるように)最小許容2分木リーフノードサイズ、または(たとえば、シンタックス要素MaxBTDepthによって示されるように)最大許容2分木深度に達するまで、反復され得る。VCEG提案COM16-C966は、2分木リーフノードを指すために「CU」という用語を使用する。VCEG提案COM16-C966では、CUは、任意のさらなる区分なしに予測(たとえば、イントラ予測、インター予測など)および変換のために使用される。概して、QTBT技法によれば、2分木スプリッティングのための2つのスプリットタイプ、すなわち、対称水平スプリッティングおよび対称垂直スプリッティングがある。各場合において、ブロックは、ブロックを水平方向または垂直方向のいずれかに半分に(down the middle)分割することによってスプリットされる。
【0090】
[0111]QTBT区分構造の一例では、CTUサイズは128×128(たとえば、128×128ルーマブロックおよび2つの対応する64×64クロマブロック)として設定され、MinQTSizeは16×16として設定され、MaxBTSizeは64×64として設定され、(幅と高さの両方のための)MinBTSizeは4として設定され、MaxBTDepthは4として設定される。4分木区分は、4分木リーフノードを生成するために最初にCTUに適用される。4分木リーフノードは、16×16(すなわち、MinQTSizeが16×16である)から128×128(すなわち、CTUサイズ)までのサイズを有し得る。QTBT区分の一例によれば、リーフ4分木ノードが128×128である場合、リーフ4分木ノードのサイズがMaxBTSize(すなわち、64×64)を超えるので、リーフ4分木ノードは2分木によってさらにスプリットされ得ない。他の場合(Otherwise)、リーフ4分木ノードは、2分木によってさらに区分される。したがって、4分木リーフノードはまた、2分木のためのルートノードであり、0としての2分木深度を有する。2分木深度がMaxBTDepth(たとえば、4)に達することは、さらなるスプリッティングがないことを暗示する。2分木ノードが、MinBTSize(たとえば、4)に等しい幅を有することは、さらなる水平スプリッティングがないことを暗示する。同様に、2分木ノードが、MinBTSizeに等しい高さを有することは、さらなる垂直スプリッティングがないことを暗示する。2分木のリーフノード(CU)は、任意の(any)さらなる区分なしに(たとえば、予測プロセスおよび変換プロセスを実行することによって)さらに処理される。
【0091】
[0112]図6Aは、QTBT区分技法を使用して区分されるブロック150(たとえば、CTB)の一例を示す。図6Aに示されているように、QTBT区分技法を使用して、得られた(resultant)ブロックの各々が、各ブロックの中心を通って対称的にスプリットされる。図6Bは、図6Aのブロック区分に対応するツリー構造を示す。図6B中の実線は4分木スプリッティングを示し、点線は2分木スプリッティングを示す。一例では、2分木の各スプリッティング(すなわち、非リーフ)ノードでは、実行されるスプリッティングのタイプ(たとえば、水平または垂直)を示すために、シンタックス要素(たとえば、フラグ)がシグナリングされ、ここで、0は水平スプリッティングを示し、1は垂直スプリッティングを示す。4分木スプリッティングの場合、4分木スプリッティングが、常に、ブロックを、等しいサイズをもつ4つのサブブロックに水平および垂直にスプリットするので(as)、スプリッティングタイプを示す必要がない。
【0092】
[0113]図6Bに示されているように、ノード170において、ブロック150は、QT区分を使用して、図6Aに示されている4つのブロック151、152、153、および154にスプリットされる。ブロック154はさらにスプリットされず、したがってリーフノードである。ノード172において、ブロック151は、BT区分を使用して2つのブロックにさらにスプリットされる。図6Bに示されているように、ノード172は、垂直スプリッティングを示す1でマークされる。したがって、ノード172におけるスプリッティングは、ブロック157、およびブロック155とブロック156の両方を含むブロックを生じる(results in)。ブロック155および156は、ノード174において、さらなる垂直スプリッティングによって作成される。ノード176において、ブロック152は、BT区分を使用して2つのブロック158および159にさらにスプリットされる。図6Bに示されているように、ノード176は、水平スプリッティングを示す1でマークされる。
【0093】
[0114]ノード178において、ブロック153は、QT区分を使用して4つの等しいサイズのブロックにスプリットされる。ブロック163および166は、このQT区分から作成され、さらにスプリットされない。ノード180において、左上ブロックは、垂直2分木スプリッティングを使用して最初にスプリットされ、ブロック160および右垂直ブロックを生じる。右垂直ブロックは、次いで、水平2分木スプリッティングを使用して、ブロック161とブロック162とにスプリットされる。ノード178において4分木スプリッティングから作成される右下ブロックは、ノード184において、水平2分木スプリッティングを使用してブロック164とブロック165とにスプリットされる。
【0094】
[0115]以下でより詳細に説明される動きベクトル候補リスト構築技法は、H.264/AVCのMB区分構造、HEVCの4分木区分構造、またはH.266のために提案されるQTBT構造などのQTBT区分構造を含む、任意のビデオブロック区分技法とともに(in conjunction with)使用され得る。
【0095】
[0116]次に、HEVCにおける動き予測が説明される。HEVC規格では、それぞれ、マージモード(スキップはマージの特殊な場合と見なされる)および高度動きベクトル予測(AMVP)モードと称される、PUのための2つのインター予測モードがある。AMVPモードまたはマージモードのいずれかでは、ビデオエンコーダ20およびビデオデコーダ30は、複数の動きベクトル予測子のための動きベクトル(MV)候補リストを構築するように構成される。動きベクトル予測子は、隣接ブロックからの動きベクトルであるか、または人工的に生成された動きベクトルであり得、それらは、ビデオデータの現在コーディングされているブロックのための動きベクトルを予測するために使用され得る。マージモードの場合、現在ブロック自体の動きベクトルを符号化するのではなく、ビデオエンコーダ20は、動きベクトル候補リストからの1つの動きベクトル、ならびにその候補に関連する参照インデックスを選択し、インター予測のためにその候補動きベクトルを使用する。ビデオエンコーダ20は、選択された動きベクトル候補のインデックス(たとえば、マージインデックス)をビデオデコーダ30にシグナリングし得る。ビデオデコーダ30は、ビデオエンコーダ20と同じ様式でマージモードのための動きベクトル候補リストを構築し得る。ビデオデコーダ30は、選択された候補を識別するために、動きベクトル候補リスト中へのシグナリングされたインデックスを使用し、次いで、現在ブロックのための動きベクトルとして使用するために動きベクトルとその候補に関連する参照インデックスとを取り出し得る。
【0096】
[0117]MV候補リストは、マージモードのための最高5つの候補とAMVPモードのための2つの候補とを含んでいる。マージ候補は、動き情報のセット、たとえば、参照ピクチャリスト(リスト0およびリスト1)と参照インデックスの両方に対応する動きベクトルを含んでいることがある。マージ候補がマージインデックスによって識別された場合、参照ピクチャは現在ブロックの予測のために使用され、ならびに、関連する動きベクトルが決定される。しかしながら、リスト0またはリスト1のいずれかからの各潜在的予測方向についてのAMVPモード下で、参照インデックスは、AMVP候補が動きベクトルのみを含んでいるので、MV候補リストへの動きベクトル予測子(MVP)インデックスとともに明示的にシグナリングされる。AMVPモードでは、予測される動きベクトルはさらに改良され得る。AMVPのいくつかの例では、ビデオエンコーダ20はまた、動きベクトル差分(MVD:motion vector difference)をシグナリングし得る。MVDは、現在ブロックのための選択されたMVPと実際の決定された動きベクトルとの間の差分である。上記でわかるように、マージ候補は動き情報のフルセットに対応し、AMVP候補は、特定の予測方向および参照インデックスのためのただ1つの動きベクトルを含んでいる。
【0097】
[0118]図7は、HEVCにおける空間隣接候補を示す概念図である。空間MV候補は、特定のPU(PU0)について、図7上に示されている隣接ブロックから導出されるが、ブロックから候補を生成する方法は、マージモードおよびAMVPモードについて異なる。
【0098】
[0119]マージモードでは、図7(a)に示されている順序で、最高4つの空間MV候補が導出され得る。順序は、図7(a)に示されているように、左(0,A1)、上(1,B1)、右上(2,B0)、左下(3,A0)、および左上(4,B2)である。すなわち、図7(a)では、ブロック200はPU0 204AとPU1 204Bとを含む。ビデオコーダ(たとえば、ビデオエンコーダ20および/またはビデオデコーダ30)が、マージモードを使用してPU0 204Aのための動き情報をコーディングすべきであるとき、ビデオコーダは、空間隣接ブロック208A、208B、208C、208D、および208Eからの動き情報を、その順序で候補リストに追加する。ブロック208A、208B、208C、208D、および208Eは、HEVCにおいて、それぞれ、ブロックA1、B1、B0、A0、およびB2と呼ばれることもある。
【0099】
[0120]AVMPモードでは、隣接ブロックは、2つのグループ、すなわち、図7(b)上に示されているように、ブロック0および1を含む左グループと、ブロック2、3、および4を含む上グループとに分割される。これらのブロックは、それぞれ、図7(b)中でブロック210A、210B、210C、210D、および210Eと標示される。ブロック202は、PU0 206AとPU1 206Bとを含み、ブロック210A、210B、210C、210D、および210Eは、PU0 206Aに対する空間ネイバーを表す。各グループについて、シグナリングされた参照インデックスによって示された参照ピクチャと同じ参照ピクチャを参照する隣接ブロック中の潜在的候補は、グループの最終候補を形成するために選定されるべき最高優先度を有する。すべての隣接ブロックが、同じ参照ピクチャを指す動きベクトルを含んでいるとは限らない可能性がある。したがって、そのような候補が見つけられ得ない場合、第1の利用可能な候補は、最終候補を形成するためにスケーリングされることになり、したがって、時間距離差分が補償され得る。
【0100】
[0121]図8は、HEVCにおける時間動きベクトル予測(TMVP)を示す概念図である。特に、図8(a)は、PU0 222AとPU1 222Bとを含む例示的なCU220を示す。PU0 222Aは、PU222Aのための中心ブロック226とPU0 122Aに対する右下ブロック224とを含む。図8(a)はまた、以下で説明されるように、動き情報がPU0 222Aの動き情報からそれについて予測され得る外部ブロック228を示す。図8(b)は、動き情報がそれについて予測されるべきである現在ブロック238を含む現在ピクチャ230を示す。特に、図8(b)は、(現在ブロック238に対するコロケートされたブロック240を含む)現在ピクチャ230に対するコロケートされたピクチャ234と、現在参照ピクチャ232と、コロケートされた参照ピクチャ236とを示す。コロケートされたブロック240は、ブロック238の動き情報のための時間動きベクトル予測子(TMVP:temporal motion vector predictor)242として使用される、動きベクトル244を使用して予測される。
【0101】
[0122]ビデオコーダ(たとえば、ビデオエンコーダ20および/またはビデオデコーダ30)は、TMVPが有効にされ、TMVP候補が利用可能である場合、TMVP候補(たとえば、TMVP候補242)を、任意の空間動きベクトル候補の後にMV候補リストに追加し得る。TMVP候補のための動きベクトル導出のプロセスは、マージモードとAMVPモードの両方について同じである。しかしながら、マージモードでのTMVP候補のためのターゲット参照インデックスは、HEVCに従って、0に設定される。
【0102】
[0123]TMVP候補導出のための1次ブロックロケーションは、空間隣接候補を生成するために使用される上および左ブロックへのバイアスを補償するための、PU0 222Aに対するブロック224として図8(a)に示されているような、コロケートされたPUの外側の右下ブロックである。しかしながら、ブロック224が現在CTB行の外側に位置するか、または、動き情報がブロック224のために利用可能でない場合、ブロックは、図8(a)に示されているようにPUの中心ブロック226と置換される。TMVP候補242のための動きベクトルは、スライスレベル情報に示されているように、コロケートされたピクチャ234のコロケートされたブロック240から導出される。
【0103】
[0124]AVCにおける時間直接モードと同様に、TMVP候補の動きベクトルは、動きベクトルスケーリングを受けることがあり、動きベクトルスケーリングは、現在ピクチャ230と現在参照ピクチャ232との間の、およびコロケートされたピクチャ234とコロケートされた参照ピクチャ236との間のPOC距離差分を補償するために実行される。すなわち、動きベクトル244は、これらのPOC差分に基づいて、TMVP候補242を生成するためにスケーリングされ得る。HEVCにおける動き予測の他の態様が以下で説明される。
【0104】
[0125]動きベクトルスケーリングがHEVCにおいて実行され得る。動きベクトルの値はプレゼンテーション時間におけるピクチャの距離に比例すると仮定される。動きベクトルは、2つのピクチャ、すなわち、参照ピクチャと、動きベクトルを含んでいるピクチャ(すなわち、含有ピクチャ(containing picture))とを関連付ける。他の動きベクトルを予測するために動きベクトルが利用されるとき、含有ピクチャと参照ピクチャとの距離は、ピクチャ順序カウント(POC)値に基づいて計算される。
【0105】
[0126]予測されるべき動きベクトルについて、それの関連する含有ピクチャと参照ピクチャの両方は異なり得る。したがって、(POCに基づく)新しい距離が計算される。また、動きベクトルは、これらの2つのPOC距離に基づいてスケーリングされる。空間隣接候補では、2つの動きベクトルのための含有ピクチャは同じであるが、参照ピクチャは異なる。HEVCでは、動きベクトルスケーリングは、空間および時間隣接候補のためにTMVPとAMVPの両方に適用される。
【0106】
[0127]また、擬似動きベクトル候補生成が、HEVCにおいて実行され得る。動きベクトル候補リストが完全でない(たとえば、候補の規定された(prescribed)数よりも少ない候補を含む)場合、ビデオエンコーダ20および/またはビデオデコーダ30は擬似動きベクトル候補を生成し得る。ビデオエンコーダ20および/またはビデオデコーダ30は、動きベクトル候補リストが規定された数の候補を有するまで、擬似(artificial)動きベクトル候補を生成し、動きベクトル候補リストの最後に挿入する。
【0107】
[0128]マージモードでは、2つのタイプの擬似MV候補、すなわち、Bスライスのために導出される双方向組合せ擬似動きベクトル候補と、第1のタイプ(すなわち、組合せ擬似動きベクトル候補)が候補リストを満たすのに十分な擬似候補を与えない場合にAMVPのみ使用される0動きベクトル候補とがあり得る。
【0108】
[0129]すでに候補リスト中にあり、必要な動き情報を有する候補の各ペアについて、双方向組合せ動きベクトル候補が、リスト0中のピクチャを参照する第1の候補の動きベクトルとリスト1中のピクチャを参照する第2の候補の動きベクトルとの組合せによって導出される。0動きベクトル候補は、単に、別のピクチャ中のコロケートされたブロックを指す(たとえば、0動きベクトル候補は(0,0)である)。
【0109】
[0130]また、HEVCに従って構成されたビデオコーダは、候補挿入のためのプルーニングプロセスを実行し得る。異なるブロックからの動きベクトル候補は偶然同じであり得、これはマージ/AMVP候補リストの効率を減少させる。すなわち、同じ値をもつ複数の(multiple)動きベクトル候補を有することは、テストおよび選択すべき動きベクトルの実際の数を減少させる。この問題を解決するために、プルーニングプロセスが適用され得る。プルーニングプロセスは、いくつかの状況において同等の候補を挿入することを回避するために、現在候補リスト中のある動きベクトル候補を他の動きベクトル候補と比較する。複雑さを低減するために、各潜在的な動きベクトル候補(one)をすべての他の既存の動きベクトル候補(one)と比較する代わりに、限られた数のプルーニングプロセスのみが適用される。
【0110】
[0131]図9は、3D-HEVCのための例示的な予測構造を示す。3D-HEVCは、JCT-3Vによって開発中のHEVCの3Dビデオ拡張である。本開示の技法に関係するいくつかの技法が、以下の図9および図10に関して説明される。図9は、3つのビューの場合のマルチビュー予測構造を示す。V3はベースビューを示し、非ベースビュー(V1またはV5)中のピクチャは、同じ時間インスタンスの従属(ベース)ビュー中のピクチャから予測され得る。(再構築されたサンプルからの)インタービューサンプル予測がマルチビューHEVC(MV-HEVC)においてサポートされ、それの一般的な予測構造が図10に示される。
【0111】
[0132]MV-HEVCと3D-HEVCの両方は、ベース(テクスチャ)ビューがHEVC(バージョン1)デコーダによって復号可能であるようにHEVCに適合する。MV-HEVCおよび3D-HEVCのためのテストモデルは、2015年1月26日現在、ウェブサイトmpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding/test-model-6-3d-hevc-and-mv-hevcにおいて入手可能な、Zhangら、「Test Model 6 of 3D-HEVC and MV-HEVC」、JCT-3VドキュメントISO/IEC JTC1/SC29/WG11 N13940に記載されている。
【0112】
[0133]MV-HEVCでは、非ベースビュー中の現在ピクチャは、同じビュー中のピクチャと同じ時間インスタンスの参照ビュー中のピクチャの両方のすべてをそのピクチャの参照ピクチャリスト中に入れることによって、これらのピクチャによって予測され得る。したがって、現在ピクチャの参照ピクチャリストは、時間参照ピクチャとインタービュー参照ピクチャの両方を含んでいる。時間参照ピクチャに対応する参照インデックスに関連する動きベクトルは、時間動きベクトルと示される。インタービュー参照ピクチャに対応する参照インデックスに関連する動きベクトルは、ディスパリティ動きベクトルと示される。3D-HEVCはMV-HEVCにおけるすべての特徴をサポートする。したがって、上述のようなインタービューサンプル予測が有効にされる。
【0113】
[0134]追加として、3D-HEVCでは、より高度のテクスチャオンリーコーディングツール(texture only coding tool)および深度関係/依存コーディングツール(depth related/dependent coding tool)がサポートされる。テクスチャオンリーコーディングツールは、しばしば、同じオブジェクトに属し得る(ビュー間の)対応するブロックの識別を使用する。したがって、ディスパリティベクトル導出は、3D-HEVCにおいて使用される1つの技法である。
【0114】
[0135]図10は、3D-HEVCにおけるサブPUベースインタービュー動き予測を示す概念図である。図10は、現在ビュー(V1)の現在ピクチャ360と参照ビュー(V0)中のコロケートされたピクチャ362とを示す。現在ピクチャ360は、4つのサブPu366A~366D(サブPU366)を含む現在PU364を含む。それぞれのディスパリティベクトル374A~374D(ディスパリティベクトル374)は、コロケートされたピクチャ362中の、サブPU366への対応するサブPU368A~368Dを識別する。3D-HEVCでは、サブPUレベルインタービュー動き予測方法は、インタービューマージ候補、すなわち、参照ビュー中の参照ブロックから導出された候補のために使用される。
【0115】
[0136]そのようなモードが有効にされるとき、現在PU364は、参照ビュー中の(ディスパリティベクトルによって識別される現在PUと同じサイズをもつ)参照エリアに対応し得、参照エリアは、PUのための動き情報の1つのセット生成のために必要とされるよりも豊富な動き情報(たとえば、多くの異なる関連する動きベクトル)を有し得る。したがって、図10に示されているように、サブPUレベルインタービュー動き予測(SPIVMP:sub-PU level inter-view motion prediction)方法が使用され得る。このモードはまた、特殊マージ候補としてシグナリングされ得る。サブPUの各々は、動き情報のフルセットを含んでいる。したがって、PUは、動き情報の複数のセットを含んでいることがある。
【0116】
[0137]また、3D-HEVCにおいて、サブPUベース動きパラメータ継承(MPI:Motion Parameter Inheritance)が使用され得る。3D-HEVCの深度コーディングでは、テクスチャビューから導出されたMPI候補も、サブPUレベルインタービュー動き予測と同様の方法で拡張され得る。たとえば、現在深度PUが、複数のPUを含んでいるコロケートされた領域を有する場合、現在深度PUはサブPUに分離され得、各サブPUが動き情報の異なるセットを有し得る。この方法は、サブPU MPIと呼ばれる。
【0117】
[0138]2Dビデオコーディングのための例示的なサブPU関係技法は、その全体が参照により本明細書に組み込まれる、2014年9月25日に出願された米国出願第14/497,128号に記載されている。米国出願第14/497,128号では、サブPUベース高度TMVP(ATMVP)設計が提案された。
【0118】
[0139]シングルレイヤコーディングでは、2段高度時間動きベクトル予測(advanced temporal motion vector prediction)設計が使用され得る。第1の段は、参照ピクチャ中の現在予測ユニット(PU)の対応するブロックを識別するベクトルを導出するために利用され、第2の段は、対応するブロックから複数のセット動き情報を抽出し、それらをPUのサブPUに割り当てることである。PUの各サブPUは、したがって、別々に動き補償される。ATMVPの概念は以下のように要約される。(1)第1の段におけるベクトルは、現在PUの空間および時間隣接ブロックから導出され得る。(2)このプロセスは、すべての他のマージ候補のうちのマージ候補をアクティブにすることとして達成され得る。シングルレイヤコーディングおよびサブPU時間動きベクトル予測に適用可能であるが、PUまたはCUは、予測子の上で伝達されるべき動き改良データを有し得る。
【0119】
[0140]米国出願第14/497,128号のいくつかの態様は、以下のようにハイライトされる。
1.ベクトル導出の第1の段はまた、ただ0ベクトルによって簡略化され得る。
2.ベクトル導出の第1の段は、動きベクトルとそれの関連するピクチャとを一緒に識別することを含み得る。関連するピクチャを選択し、さらに、動きベクトルが第1段ベクトルであると決める、様々な方法が提案されている。
3.上記のプロセス中の動き情報が利用不可能である場合、「第1段ベクトル」は、置換のために使用される。
4.時間ネイバーから識別された動きベクトルは、TMVPにおける動きベクトルスケーリングと同様の方法で、現在サブPUのために使用されるようにスケーリングされ得る。しかしながら、そのような動きベクトルがどの参照ピクチャにスケーリングされ得るかは、以下の方法のうちの1つを用いて設計され得る。
【0120】
a.そのピクチャは、現在ピクチャの固定参照インデックスによって識別される。
【0121】
b.そのピクチャは、現在ピクチャの参照ピクチャリスト中でも利用可能である場合、対応する時間ネイバーの参照ピクチャであると識別される。
【0122】
c.そのピクチャは、第1の段において、および動きベクトルがそこから捕捉された場所から識別された、コロケートされたピクチャであるように設定される。
【0123】
[0141]米国出願第14/497,128号におけるいくつかの設計問題に対処するために、内容全体が参照により本明細書に組み込まれる、2016年1月25日に出願された米国出願第15/005,564号において以下の技法が提案された。
【0124】
1.たとえば、マージ候補リストとして、挿入される場合の、ATMVP候補の位置 a.空間候補およびTMVP候補が、ある順序でマージ候補リストに挿入されると仮定する。ATMVP候補は、それらの候補の任意の比較的固定された位置中に挿入され得る。
【0125】
i.一代替では、たとえば、ATMVP候補は、第1の2つの空間候補、たとえば、A1およびB1の後にマージ候補リストに挿入され得る。
【0126】
ii.一代替では、たとえば、ATMVP候補は、第1の3つの空間候補、たとえば、A1およびB1およびB0の後に挿入され得る。
【0127】
iii.一代替では、たとえば、ATMVP候補は、第1の4つの候補、たとえば、A1、B1、B0、およびA0の後に挿入され得る。
【0128】
iv.一代替では、たとえば、ATMVP候補は、TMVP候補の直前に挿入され得る。
【0129】
v.一代替的にでは、たとえば、ATMVP候補は、TMVP候補の直後に挿入され得る。
【0130】
b.代替的に、候補リスト中のATMVP候補の位置は、ビットストリーム中でシグナリングされ得る。さらに、TMVP候補を含む他の候補の位置がシグナリングされ得る。
【0131】
2.動き情報のただ1つのセットにアクセスすることによって、ATMVP候補の利用可能性検査が適用され得る。情報のそのようなセットが利用不可能であり、たとえば、1つのブロックがイントラコーディングされるとき、全ATMVP候補が利用不可能であると見なされる。その場合、ATMVPはマージリストに挿入されない。
【0132】
a.純粋に、ATMVP候補の利用可能性を検査するために、中心位置、または中心サブPUが使用される。中心サブPUが使用されるとき、中心サブPUは、中心位置(たとえば、PUの左上サンプルに対する(W/2,H/2)の相対座標をもつ、中心3位置、ここにおいて、W×HはPUのサイズである)をカバーするものであるように選定される。そのような位置または中心サブPUは、動きソースピクチャ中の対応するブロックを識別するために、時間ベクトルとともに使用され得る。対応するブロックの中心位置をカバーするブロックからの動き情報のセットが識別される。
【0133】
3.サブPUからのATMVPコード化PUのための動き情報の代表的セット。
【0134】
a.ATMVP候補を形成するために、動き情報の代表的セットは、最初に形成される。
【0135】
b.動き情報のそのような代表的セットは、固定位置または固定サブPUから導出され得る。それは、箇条2に記載されているように、ATMVP候補の利用可能性を決定するために使用される動き情報のセットのそれと同様の方法で選定され得る。
【0136】
c.サブPUが動き情報のそれ自体のセットを識別しており、利用不可能であるとき、それは、動き情報の代表的セットに等しくなるように設定される。
【0137】
d.動き情報の代表的セットがサブPUのそれであるように設定される場合、追加の動き記憶は、ワーストケースシナリオにおいて現在CTUまたはスライスのためにデコーダ側において必要とされない。
【0138】
e.動き情報のそのような代表的セットは、プルーニングを含めて、動き情報の1つのセットによって全PUが表されることを復号プロセスが要求するとき、そのプロセスが、組合せ双予測マージング候補を生成するために使用されるように、すべてのシナリオにおいて使用される。
【0139】
4.ATMVP候補がTMVP候補を用いてプルーニングされ、TMVPとATMVPとの間の相互作用が考慮され得、詳細な技法が以下に記載される。
【0140】
a.通常候補を用いた、サブPUベース候補、たとえば、ATMVP候補のプルーニングは、そのようなサブPUベース候補について(箇条3の場合のように)動き情報の代表的セットを使用することによって行われ得る。動き情報のそのようなセットが通常マージ候補と同じである場合、2つの候補は同じであると見なされる。
【0141】
b.代替的に、追加として、ATMVPが複数のサブPuのための動き情報の複数の異なるセットを含んでいるかどうかを決定するために、検査が実行され、少なくとも2つの異なるセットが識別された場合、サブPUベース候補は、プルーニングのために使用されず、すなわち、他の候補とは異なると見なされる。他の場合、それは、プルーニングのために使用され得る(たとえば、プルーニングプロセス中にプルーニングされ得る)。
【0142】
c.代替的に、追加として、ATMVP候補は、A1およびB1として示された位置をもつ、空間候補、たとえば、左および上の空間候補のみを用いてプルーニングされ得る。
【0143】
d.代替的に、ATMVP候補またはTMVP候補のいずれかである、1つの候補のみが、時間参照から形成される。ATMVPが利用可能であるとき、候補はATMVPであり、他の場合、候補はTMVPである。そのような候補は、TMVPの位置と同様の位置においてマージ候補リストに挿入される。この場合、候補の最大数は、不変であるように保たれ得る。
【0144】
i.代替的に、TMVPは、ATMVPが利用不可能であるときでも常に無効にされる。
【0145】
ii.代替的に、TMVPは、ATMVPが利用不可能であるときのみ使用される。
【0146】
e.代替的に、ATMVPが利用可能であり、TMVPが利用不可能であるとき、1つのサブPUの動き情報の1つのセットがTMVP候補として使用される。この場合、さらに、ATMVPとTMVPとの間のプルーニングプロセスは適用されない。
【0147】
f.また、代替または追加として、ATMVPのために使用される時間ベクトルは、HEVCにおいて現在TMVPのために使用されるような右下位置または中心3位置が使用される必要がないように、TMVPのために使用され得る。
【0148】
i.代替的に、時間ベクトルによって識別された位置ならびに右下および中心3位置は、一緒に、利用可能なTMVP候補を与えると見なされる。
【0149】
5.ATMVPに対する複数の利用可能性検査は、ATMVP候補がより正確で効率的となる、より高い可能性を与えるためにサポートされる。(たとえば、図9に示されているように)第1の時間ベクトルによって識別されるような動きソースピクチャからの現在ATMVP候補が利用不可能であるとき、他のピクチャは動きソースピクチャと見なされ得る。別のピクチャが考慮されるとき、それは、異なる第2の時間ベクトルに関連し得るか、または、単に、利用不可能なATMVP候補を指す第1の時間ベクトルからスケーリングされる第2の時間ベクトルに関連し得る。
【0150】
a.第2の時間ベクトルは、第2の動きソースピクチャ中のATMVP候補を識別することができ、同じ利用可能性検査が適用され得る。第2の動きソースピクチャから導出されるようなATMVP候補が利用可能である場合、ATMVP候補が導出され、他のいかなるピクチャも検査される必要がなく、他の場合、動きソースピクチャとしての他のピクチャが検査される必要がある。
【0151】
b.検査されるべきピクチャは、所与の順序をもつ、現在ピクチャの参照ピクチャリスト中のピクチャであり得る。各リストについて、ピクチャは、参照インデックスの昇順で検査される。リストXが最初に検査され、リスト(1-Xである)Y中のピクチャが続く。
【0152】
i.リストXは、リストXが、TMVPのために使用されるコロケートされたピクチャを含んでいるリストであるように選定される。
【0153】
ii.代替的に、Xは、単に、1または0であるように設定される。
【0154】
c.検査されるべきピクチャは、所与の順序をもつ、空間ネイバーの動きベクトルによって識別されるピクチャである。
【0155】
6.現在ATMVPが適用されるPUの区分は、2N×2N、N×N、2N×N、N×2N、または、2N×N/2などの非対称動き区分(AMP:asymmetric motion partition)区分であり得る。
【0156】
a.代替的に、追加として、他の区分サイズが可能にされ得る場合、ATMVPもサポートされ得、そのようなサイズは、たとえば、64×8を含み得る。
【0157】
b.代替的に、モードは、いくつかの区分、たとえば、2N×2Nに適用されるにすぎないことがある。
【0158】
7.ATMVP候補は、マージ候補の異なるタイプとしてマークされる。
【0159】
8.ネイバーからベクトル(第1の段の場合のような時間ベクトル)を識別するとき、複数の隣接位置、たとえば、マージ候補リスト構築において使用される隣接位置が順番に検査され得る。ネイバーの各々について、参照ピクチャリスト0(リスト0)または参照ピクチャリスト1(リスト1)に対応する動きベクトルが順番に検査され得る。2つの動きベクトルが利用可能であるとき、リストX中の動きベクトルが最初に検査され、その後に(Yが1-Xに等しい)リストYが続き得、その結果、リストXは、TMVPのために使用されるコロケートされたピクチャを含んでいるリストとなる。ATMVPでは、サブPUの中心位置のシフトとして時間ベクトルが追加され使用され、ここにおいて、時間ベクトルの成分は、整数にシフトされる必要があり得る。そのようなシフトされる中心位置は、たとえば、現在中心位置をカバーする4×4のサイズをもつ、動きベクトルが割り振られ得る最も小さいユニットを識別するために使用される。
【0160】
a.代替的に、リスト0に対応する動きベクトルが、リスト1に対応する動きベクトルの前に検査され得る。
【0161】
b.代替的に、リスト1に対応する動きベクトルが、リスト0に対応する動きベクトルの前に検査され得る。
【0162】
c.代替的に、すべての空間ネイバー中のリストXに対応するすべての動きベクトルが順番に検査され、その後に(Yが1-Xに等しい)リストYに対応する動きベクトルが続く。ここで、リスト「X」は、コロケートされたピクチャがどこに属するかを示すリストであるか、あるいは、ただ単に、0または1であるように設定され得る。
【0163】
d.空間ネイバーの順序は、HEVCマージモードで使用される順序と同じであり得る。
【0164】
9.識別する第1の段において、時間ベクトルが参照ピクチャを識別する情報を含まないとき、図9に示されているような動きソースピクチャは、単に、固定ピクチャ、たとえば、TMVPのために使用されるコロケートされたピクチャであるように設定され得る。
【0165】
a.そのような場合、ベクトルは、そのような固定ピクチャを指す動きベクトルのみから識別され得る。
【0166】
b.そのような場合、ベクトルは、任意のピクチャを指す動きベクトルからのみ識別されるが、さらに、固定ピクチャのほうへスケーリングされ得る。
【0167】
10.参照ピクチャを識別することなる、ベクトルを識別する第1の段にあるとき、図9に示されているような動きソースピクチャ、以下の追加の検査のうちの1つまたは複数が、候補動きベクトルに対して適用され得る。
【0168】
a.動きベクトルが、イントラコーディングされるピクチャまたはスライスに関連する場合、そのような動きベクトルは、利用不可能であると見なされ、そのベクトルに変換されるために使用されないことがある。
【0169】
b.動きベクトルが、関連するピクチャ中で(たとえば、動きベクトルをもつ現在中心座標を追加することによって)イントラブロックを識別する場合、そのような動きベクトルは、利用不可能であると見なされ、そのベクトルに変換されるために使用されないことがある。
【0170】
11.ベクトルを識別する第1の段にあるとき、ベクトルの成分は、それが動きソースピクチャ中の右下ピクセル位置を識別するように、(現在PUの1/2の幅,現在PUの1/2の高さ)であるように設定され得る。ここで、(x,y)は、1つの動きベクトルの水平成分と垂直成分とを示す。
【0171】
a.代替的に、ベクトルの成分は、(sum(現在PUの1/2の幅、M),sum(現在PUの1/2の高さ、N))であるように設定され得、ここで、関数sum(a,b)はaとbの和を返す。一例では、動き情報が4×4ユニットにおいて記憶されるとき、MとNは両方とも2に等しくなるように設定される。別の例では、動き情報が8×8ユニットにおいて記憶されるとき、MとNは両方とも4に等しくなるように設定される。
【0172】
12.ATMVPが適用されるときのサブブロック/サブPUサイズは、パラメータセット、たとえば、ピクチャパラメータセットのシーケンスパラメータセット中でシグナリングされる。サイズは、最小PUサイズからCTUサイズに及ぶ。サイズはまた、あらかじめ定義されるか、またはシグナリングされ得る。サイズは、たとえば、4×4程度に小さくなり得る。代替的に、サブブロック/サブPUサイズは、PUまたはCUのサイズに基づいて導出され得る。たとえば、サブブロック/サブPUは、max(4×4,(CUの幅)>>M)に等しく設定され得る。Mの値は、あらかじめ定義されるか、またはビットストリーム中でシグナリングされ得る。
【0173】
13.マージ候補の最大数は、ATMVPが新しいマージ候補と見なされ得ることにより、1だけ増加され得る。たとえば、プルーニングの後にマージ候補リスト中の最高5つの候補を要するHEVCと比較して、マージ候補の最大数は6に増加され得る。
【0174】
a.代替的に、従来のTMVP候補を用いたプルーニングまたは従来のTMVP候補との統一は、マージ候補の最大数が、不変であるように保たれ得るように、ATMVPに対して実行され得る。
【0175】
b.代替的に、ATMVPが利用可能であると識別されたとき、空間隣接候補がマージ候補リストから除外され、たとえば、フェッチング順序での最後の空間隣接候補が除外される。
【0176】
14.複数の空間隣接動きベクトルが時間ベクトルを導出すると見なされるとき、動きベクトルの類似度が、現在PUの隣接動きベクトル、ならびに、動きベクトルに等しく設定されている特定の時間ベクトルによって識別された隣接動きベクトルに基づいて計算され得る。最も高い動き類似度をもたらすものが、最終時間ベクトルとして選定され得る。
【0177】
a.一代替では、隣接位置Nからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロック(現在PUと同じサイズ)を識別し、ここにおいて、それの隣接位置Nは動き情報のセットを含んでいる。動きベクトルのこのセットは、現在ブロックの隣接位置Nの場合のように動き情報のセットと比較される。
【0178】
b.別の代替では、隣接位置Nからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロックを識別し、ここにおいて、それの隣接位置は動き情報の複数のセットを含んでいる。動きベクトルのこれらの複数のセットは、同じ相対位置において現在PUの隣接位置からの動き情報の複数のセットと比較される。動き情報の類似度が計算される。たとえば、現在PUは、MIA1、MIB1、MIA0およびMIB0として示される、A1、B1、A0およびB0からの動き情報の以下のセットを有する。時間ベクトルTVについて、それは、動きソースピクチャ中のPUに対応するブロックを識別する。そのようなブロックは、同じ相対A1、B1、A0およびB0位置からの動き情報を有し、TMIA1、TMIB1、TMIA0およびTMIB0として示した。TVによって決定された動き類似度は、
【0179】
【数1】
【0180】
として計算され、ここにおいて、MVSimは動き情報の2つのセット間の類似度を定義する。
【0181】
c.上記の場合の両方では、動き類似度MVSimが使用され得、ここにおいて、2つの入力パラメータは、各々が最高2つの動きベクトルと2つの参照インデックスとを含んでいる、動き情報の2つのセットである。リストX中の動きベクトルの各ペアは、実際は、異なるピクチャ、すなわち、現在ピクチャおよび動きソースピクチャの異なるリストX中の参照ピクチャに関連する。(Xが0または1に等しい)2つの動きベクトルMVXNおよびTMVXNの各々について、動きベクトル差分MVDXNがMVXN-TMVXNとして計算され得る。その後、差分MVSimXが、たとえば、
【0182】
【数2】
【0183】
または
【0184】
【数3】
【0185】
i.動き差分の統一された計算を有するために、動きベクトルの両方は、たとえば、現在ピクチャのリストXの第1の参照ピクチャRefPicListX[0]であり得る、同じ固定ピクチャのほうへスケーリングされる必要がある。
【0186】
ii.第1のセットからのリストX中の動きベクトルの利用可能性と第2のセットからのリストX中の動きベクトルの利用可能性とが異なる、すなわち、一方の参照インデックスが-1であり、他方の参照インデックスが-1でない場合、動き情報のそのような2つのセットは、方向Xにおいて類似していないと見なされる。2つのセットが両方のセットにおいて類似していない場合、最終MVSim関数は大きい値Tを返し得、それは、たとえば、無限と見なされ得る。
【0187】
iii.代替的に、動き情報のセットのペアについて、一方が、(Yが1-Xに等しい)リストYではなく(Xが0または1に等しい)リストXから予測され、他方が同じステータスを有する場合、1から2の間の重み付け(たとえば、MVSimはMVSimX*1.5に等しい)が使用され得る。一方のセットがリストXのみから予測され、他方のセットがリストYのみから予測されるとき、MVSimは、大きい値Tに設定される。
【0188】
iv.代替的に、動き情報の任意のセットについて、1つの動きベクトルが利用可能である限り、両方の動きベクトルが生成される。1つの動きベクトルのみが利用可能である(リストXに対応している)場合、それは、他のリストYに対応する動きベクトルを形成するためにスケーリングされる。
【0189】
d.代替的に、動きベクトルは、現在PUの隣接ピクセルと、動きベクトルによって識別されたブロック(現在PUと同じサイズ)の隣接ピクセルとの間の差分に基づいて測定され得る。最も小さい差分をもたらす動きベクトルが、最終時間ベクトルとして選定され得る。
【0190】
15.現在ブロックの時間ベクトルを導出するとき、ATMVPを用いてコーディングされる隣接ブロックからの動きベクトルおよび/または時間ベクトルは、他の隣接ブロックからの動きベクトルよりも高い優先度を有し得る。
【0191】
a.一例では、隣接ブロックの時間ベクトルのみが最初に検査され、第1の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。この場合、ATMVPコード化ブロックのための時間ベクトルが記憶される必要がある。
【0192】
b.別の例では、ATMVPコード化隣接ブロックからの動きベクトルのみが最初に検査され、第1の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。
【0193】
c.別の例では、ATMVPコード化隣接ブロックからの動きベクトルのみが最初に検査され、第1の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条15aの場合と同様に続く。
【0194】
d.別の例では、隣接ブロックからの時間ベクトルが最初に検査され、第1の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条15bの場合と同様に続く。
【0195】
e.別の例では、ATMVPコード化隣接ブロックの時間ベクトルと動きベクトルとが最初に検査され、第1の利用可能なものが現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルおよび動きベクトルが存在しないときのみ、さらに、通常動きベクトルが検査される。
【0196】
16.複数の空間隣接動きベクトルが時間ベクトルを導出すると見なされるとき、動きベクトルは、それが、ピクセル領域から計算されるひずみを最小限に抑えるように選定され得、たとえば、最小マッチングコストをもたらすものが最終時間ベクトルとして選択されるように時間ベクトルを導出するために、テンプレートマッチングが使用され得る。
【0197】
17.(動きソースピクチャ中の)対応するブロックからの動き情報のセットの導出は、動きベクトルが、任意のリストXのために、対応するブロック中で利用可能であるとき(動きベクトルをMVXであると示す)、ATMVP候補の現在サブPUについて、動きベクトルが(MVXをスケーリングすることによって)リストXのために利用可能であると見なされるように、行われる。動きベクトルが、任意のリストXのために、対応するブロック中で利用不可能である場合、動きベクトルはリストXのために利用不可能であると見なされる。
【0198】
a.代替的に、対応するブロック中の動きベクトルがリストXのために利用不可能であるが、リスト1-Xのために利用可能であるとき(1-XがYで示され、動きベクトルをMVYであるとして示す)、動きベクトルは、依然として、(リストX中のターゲット参照ピクチャのほうへMVYをスケーリングすることによって)リストXのために利用可能であると見なされる。
【0199】
b.代替的に、または追加として、リストXおよびリスト(1-Xに等しい)Yのための対応するブロック中の両方の動きベクトルが利用可能であるとき、リストXおよびリストYからの動きベクトルが、スケーリングによって現在サブPUの2つの動きベクトルを直接スケーリングし、生成するために必要な使用されない。
【0200】
i.一例では、ATMVP候補を構築するとき、TMVPにおいて行われるような低遅延検査が各サブPUに適用される。現在スライスのあらゆる参照ピクチャリスト中の(refPicによって示される)あらゆるピクチャについて、refPicのピクチャ順序カウント(POC)値が現在スライスのPOCよりも小さい場合、現在スライスは低遅延モードで考慮される。この低遅延モードでは、リストXおよびリストYからの動きベクトルは、それぞれ、リストXおよびリストYのための現在サブPUの動きベクトルを生成するためにスケーリングされる。低遅延モードにないとき、MVXまたはMVYからの1つの動きベクトルMVZのみが選定され、現在サブPUのための2つの動きベクトルを生成するためにスケーリングされる。TMVPと同様に、そのような場合、Zは、collocated_from_l0_flagに等しく設定され、これは、それが、TMVPの場合のようなコロケートされたピクチャが現在ピクチャのリストXまたはリストY中にあるかどうかに依存することを意味する。代替的に、Zは、以下のように設定され、すなわち、動きソースピクチャがリストXから識別される場合、ZがXに設定される。代替的に、追加として、動きソースピクチャが両方の参照ピクチャリストに属し、RefPicList0[idx0]が、リスト0中に最初に存在する動きソースピクチャであり、RefPicList(1)[idx1]が、リスト1中に最初に存在する動きソースピクチャであるとき、Zは、idx0がidx1よりも小さいかそれに等しい場合、0であるように設定され、他の場合、1であるように設定される。
【0201】
18.動きソースピクチャは、コード化ビットストリーム中でビデオエンコーダ20によってシグナリングされ、たとえば、生成され得る。詳細に、動きソースピクチャがリスト0からであるのかリスト1からであるのかを示すフラグが、Bスライスのためにシグナリングされる。代替的に、追加として、現在ピクチャのリスト0またはリスト1への参照インデックスが、動きソースピクチャを識別するためにシグナリングされ得る。
【0202】
[0142]時間ベクトルを識別するとき、それが、関連する動きソースピクチャ中のイントラコード化ブロックを指す場合、ベクトルは利用不可能であると見なされる(したがって他のベクトルが考慮され得る)。
【0203】
[0143]図11は、参照ピクチャからのサブPU動き予測を示す概念図である。この例では、現在ピクチャ380は、現在PU384(たとえば、PU)を含む。この例では、動きベクトル392は、PU384に対する参照ピクチャ382のPU386を識別する。PU386は、各々がそれぞれの動きベクトル390A~390Dを有する、サブPU388A~388Dに区分される。したがって、現在PU384は、実際は別個のサブPUに区分されないが、この例では、現在PU384は、サブPU388A~388Dからの動き情報を使用して予測され得る。特に、ビデオコーダは、それぞれの動きベクトル390A~390Dを使用して現在PU384のサブPUをコーディングし得る。しかしながら、ビデオコーダは、現在PU384がサブPUにスプリットされることを示すシンタックス要素をコーディングする必要がない。このようにして、現在PU384は、現在PU384を複数のサブPUにスプリットするために使用されるシンタックス要素のシグナリングオーバーヘッドなしに、それぞれのサブPU388A~388Dから継承される、複数の動きベクトル390A~390Dを使用して効果的に予測され得る。
【0204】
[0144]図12は、(TMVPと同様の)ATMVPにおける関連するピクチャを示す概念図である。特に、図12は、現在ピクチャ404と、動きソースピクチャ406と、参照ピクチャ400および402とを示す。より詳細には、現在ピクチャ404は現在ブロック408を含む。時間動きベクトル412は、現在ブロック408に対する動きソースピクチャ406の対応するブロック410を識別する。対応するブロック410は、今度は、動きベクトル414を含み、これは、参照ピクチャ402を参照し、現在ブロック408の少なくとも一部分、たとえば、現在ブロック408のサブPUのための高度時間動きベクトル予測子として働く。すなわち、動きベクトル414は、現在ブロック408のための候補動きベクトル予測子として追加され得る。選択された場合、現在ブロック408の少なくとも一部分は、参照ピクチャ400を参照する、対応する動きベクトル、すなわち、動きベクトル416を使用して予測され得る。
【0205】
[0145]また、HEVCのためのサブPU関係技法は、その両方の内容全体が参照により本明細書に組み込まれる、2016年7月9日に出願された米国出願第15/176,790号に記載されている。サブPU動き予測を使用して性能を向上させるために、隣接サブPUの空間時間動き情報(ATMVP_EXT)が活用される(exploited)。この例では、各サブPUのための動きベクトルは、3次元領域における隣接ブロックの情報から導出される。これは、隣接ブロックが、現在ピクチャ中の空間ネイバーまたは前のコード化ピクチャ中の時間ネイバーであり得ることを意味する。図13は、空間時間動きベクトル予測子(STMVP:spatial-temporal motion vector predictor)導出プロセスのフローチャートを示す。以下で説明されることのほかに、ATMVPについて上記で説明された方法(たとえば、箇条1、2、3、4、6、7、12、13)は、STMVPに直接拡張され得る。
【0206】
[0146]図13に示されているように、ビデオエンコーダ20および/またはビデオデコーダ30は、現在サブPUのための空間または時間隣接ブロックから利用可能な動きフィールドを取得するように構成され得る(430)。このコンテキストでは、動きフィールドは、空間的に/時間的に隣接するブロックのための最良として選択された動きベクトルの集合(collection)である。たとえば、現在ブロックの左または上に位置するブロックは、すでにコーディングされており、最良の動きベクトルは、現在サブPUをコーディングする前に利用可能である。隣接ブロックからの利用可能な動き情報は、ビデオエンコーダ20とビデオデコーダ30の両方において同等である。動き情報は、1つまたは2つの3次元ベクトル(MVx、Mvy、時間的方向)、すなわち、単予測のための1つのベクトルおよび双予測のための2つのベクトルのを含む。ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、取得された隣接動きフィールドから動き情報を導出する(432)。ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、サブPUのすべてが処理されたかどうかを決定する(434)。いいえの場合、ビデオエンコーダ20および/またはビデオデコーダ30は次のサブPUに移動する。はいの場合、ビデオエンコーダ20および/またはビデオデコーダ30は、空間時間サブPU動き予測子の利用可能性を決定し得る(436)。利用可能な場合、ビデオエンコーダ20および/またはビデオデコーダ30は空間時間サブPU動き予測子をマージリストに挿入する。
【0207】
[0147]以下の説明では、「ブロック」という用語は、予測関係情報、たとえば、インターまたはイントラ予測、イントラ予測モード、動き情報などの記憶のためのブロックユニットを指すために使用される。そのような予測情報は、保存され、将来のブロックをコーディングするために、たとえば、将来のブロックのための予測モード情報を予測するために使用され得る。AVCおよびHEVCでは、そのようなブロックのサイズは4×4である。以下の説明では、隣接ブロックから動き情報を導出するユニットを示すためのインターコード化ブロックユニットおよびサブPUを示すために「PU」を使用することに留意されたい。以下の技法の任意の組合せが適用され得る。
【0208】
[0148]一例では、ビデオエンコーダ20および/またはビデオデコーダ30は、隣接ブロックから動き情報を取得するように構成され得る。サブPUおよび隣接ブロックは、異なるサイズを有し得る。複数のサブPUをもつPUについて考える。サブPUのサイズは、通常、その隣接ブロックサイズに等しいかまたはそれよりも大きい。一例では、図14に示されているように、ハッシングされた(hashed)正方形は、現在PUの外部にある隣接ブロック(a、b、...i)を表し、残りのハッシングされていない正方形(A、B、...P)は、現在PU中のサブPUを表す。図14に示されているように、サブPUのサイズと、それの隣接ブロックのサイズとは同じである。一例では、サブPUのサイズは4×4に等しいが、異なるサイズのサブPUが使用され得る。図15は、サブPUが隣接ブロックよりも大きい別の例を示す。他の例では、サブPUは、長方形または三角形などの非正方形形状をとり得る。ある例では、サブPUのサイズは、スライスヘッダ中でシグナリングされ得る。
【0209】
[0149]他の例では、ATMPVに関係する上記の説明の箇条12におけるプロセスは、STMVPに拡張され得る。たとえば、STMVPが適用されるときのサブブロック/サブPUサイズは、パラメータセット、たとえば、ピクチャパラメータセットのシーケンスパラメータセット中でシグナリングされる。サイズは、最小PUサイズからCTUサイズに及ぶ。サイズはまた、あらかじめ定義されるか、またはシグナリングされ得る。サイズは、たとえば、4×4程度に小さくなり得る。代替的に、サブブロック/サブPUサイズは、PUまたはCUのサイズに基づいて導出され得る。たとえば、サブブロック/サブPUは、max(4×4,(CUの幅)>>M)に等しく設定され得る。Mの値は、あらかじめ定義されるか、またはビットストリーム中でシグナリングされ得る。
【0210】
[0150]STMVPでは、サブPUの異なる検査順序が使用され得る。図14の例では、以下の説明において、ラスタ走査順序(A、B、C、D、E...)が、サブPUに、それらの動き予測導出のために、適用されると仮定する。しかしながら、他の走査順序も適用され得、本開示の技法はラスタ走査順序のみに限定されるものでないことに留意されたい。
【0211】
[0151]STMVPでは、隣接ブロックは、2つの異なるタイプ、すなわち、空間および時間に分類され得る。空間隣接ブロックは、現在ピクチャまたはスライス中にあり、現在サブPUに隣接している、すでにコード化されたブロックまたはすでに走査されたサブPUである。時間隣接ブロックは、前のコード化ピクチャ中のブロックであり、現在サブPUのコロケートされたブロックに隣接している。一例では、時間隣接ブロックを取得するために、現在PUに関連するすべての参照ピクチャが使用される。別の例では、参照ピクチャのサブセットが、STMVP導出のために使用される。たとえば、各参照ピクチャリストの第1のエントリのみが使用される。
【0212】
[0152]この定義に続いて、図14を参照すると、サブPU(A)の場合、前のコード化ピクチャ中のすべての隣接ブロック(a、b、...i)およびそれらのコロケートされたブロックは、利用可能として扱われる空間および時間隣接ブロックである。ラスタ走査順序によれば、ブロックB、C、D、E...Pは空間的に利用可能でない。とはいえ、(AからPまでの)すべてのサブPUは、それらの動き情報が前のコード化ピクチャ中のそれらのコロケートされたブロック中で見つけられ得るので、サブPU(A)のための時間的に利用可能な隣接ブロックである。別の例としてサブPU(G)を挙げると、利用可能であるそれの空間隣接ブロックは、a、b...からiまでのものを含み、また、AからFまでのものを含む。いくつかの例では、空間隣接ブロック(すなわち、a、b...からiまで)が同じLCU/スライス/タイル中にあるものとするなど、いくつかの制限が空間隣接ブロックに適用され得る。
【0213】
[0153]ビデオエンコーダ20および/またはビデオデコーダ30は、各サブPUのための動き情報または動きフィールドを導出するために、すべての利用可能な隣接ブロックのサブセットを選択する。各PUの導出のために使用されるサブセットは、あらかじめ定義され得る。他の例では、導出のために使用されるサブセットは、スライスヘッダ、ピクチャパラメータセット(PPS)、および/またはシーケンスパラメータセット(SPS)中で高レベルシンタックスとしてシグナリングされ得る。コーディング性能を最適化するために、サブセットは各サブPUについて異なり得る。実際には、サブセットのためのロケーションの固定パターンが、簡単のために選好される。たとえば、各サブPUは、サブセットとして、それのすぐ上の空間ネイバーと、それのすぐ左の空間ネイバーと、それのすぐ右下の時間ネイバーとを使用し得る。図14に示されているように、サブPU(J)について考えるとき、上ブロック(F)および左ブロック(I)は、空間的に利用可能な隣接ブロックであり、右下ブロック(O)は、時間的に利用可能な隣接ブロックである。そのようなサブセットの場合、現在PU中のサブPUは、処理依存性(processing dependency)により、連続的に処理される。
【0214】
[0154]現在PU中の各サブPUの並列処理を可能にするために、隣接ブロックの異なるサブセットが定義および使用され得る。一例では、サブセットは、現在PUに属さない空間ネイバーブロック、たとえば、ブロックa、b、...iのみを含んでいる。この場合、並列処理が可能であろう。別の例では、所与のサブPUについて、それの空間隣接ブロックが現在PU内にある場合、その空間隣接ブロックのコロケートされたブロックは、サブセット中に入れられ、現在サブPUの動き情報を導出するために使用され得る。たとえば、サブPU(J)について考えるとき、上ブロック(F)および左ブロック(I)および右下ブロック(O)の時間的なコロケートされたブロックは、サブPU(J)の動きを導出するためのサブセットとして選択される。この場合、サブPU(J)のためのサブセットは3つの時間隣接ブロックを含んでいる。別の例では、部分並列プロセスが有効にされ得、ここにおいて、1つのPUはいくつかの領域にスプリットされ、(いくつかのサブPUをカバーする)各領域は独立して処理され得る。
【0215】
[0155]時々、隣接ブロックはイントラコーディングされ、ここにおいて、より良い動き予測およびコーディング効率のために、それらのブロックのための代替動き情報を決定するためのルールを有することが望ましい。たとえば、サブPU(A)について考えると、ブロックb、c、fがイントラコーディングされ、ブロックa、d、e、g、h、iがインターコーディングされる場合があり得る。
【0216】
[0156]空間ネイバーについて、イントラコード化ブロックの動き情報を、最初に見つけられたインターコード化ブロックの動き情報でポピュレートするために、あらかじめ定義された順序が使用され得る。たとえば、上ネイバーの探索順序は、最右ネイバーまで右向にすぐ上のネイバーから開始するように設定され得、これは、b、c、d、およびeの順序を意味する。左ネイバーの探索順序は、最下ネイバーまで下方へすぐ左のネイバーから開始するように設定され得る。この例では、順序は、f、g、h、次いでiである。インターコード化ブロックが探索プロセスを通して見つけられなかった場合、上または左空間ネイバーは利用不可能であると見なされる。
【0217】
[0157]時間ネイバーについて、TMVP導出において指定されるものと同じルールが使用され得る。しかしながら、他のルール、たとえば、動き方向、時間距離(異なる参照ピクチャ中での探索)および空間ロケーションなどに基づくルールも使用され得ることに留意されたい。
【0218】
[0158]ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、所与のサブPUのための動き情報を導出し得る。このプロセスの一部として、ビデオエンコーダ20および/またはビデオデコーダ30は、ターゲット参照ピクチャ決定および動きベクトルスケーリングを実行し得る。隣接ブロックについて、動きベクトルスケーリングが、すべての隣接ブロックの動きベクトルを各リスト中の同じ参照ピクチャにマッピングするために、各参照ピクチャリストに基づいて、隣接ブロックに関連する動きベクトルに適用され得る。本例では、2つのステップがあり得、第1に、スケーリングのために使用するソース動きベクトルを決定し、第2に、ソース動きベクトルが投影されるターゲット参照ピクチャを決定する。
【0219】
[0159]第1のステップでは、いくつかの方法が使用され得る。
【0220】
(a)各参照リストについて、動きベクトルスケーリングは、別の参照リスト中の動きベクトルとは無関係である。所与のブロックの動き情報について、参照リスト中の動きベクトルがない場合(たとえば、双予測モードではなく(instead of)単予測モード)、動きベクトルスケーリングはそのリストのために実行されない。
【0221】
(b)動きベクトルスケーリングは、別の参照リスト中の動きベクトルとは無関係でない。所与のブロックの動き情報について、動きベクトルが参照リスト中で利用不可能でない場合、動きベクトルは、別の参照リスト中の動きベクトルからスケーリングされ得る。
【0222】
(c)両方の動きベクトルは、(上述のTMVPの場合のように)1つのあらかじめ定義された参照リストからスケーリングされる。
【0223】
[0160]一例として、方法(a)は、空間隣接ブロックの動きベクトルをスケーリングするために使用され、方法(c)は、時間隣接ブロックの動きベクトルをスケーリングするために使用される。
【0224】
[0161]第2のステップに関しては、ビデオエンコーダ20および/またはビデオデコーダ30は、利用可能な空間隣接ブロックの動き情報(たとえば参照ピクチャ)に基づく、あるルールに従って、ターゲット参照ピクチャを選択し得る。そのようなルールの一例は、多数決ルール、すなわち、ブロックの大部分によって共有される参照ピクチャを選択することである。この場合、同じ情報が同じルールを使用してデコーダ側においても推論され得るので、エンコーダからデコーダへの、ターゲット参照ピクチャのために必要とされるシグナリングがない。代替的に、そのような参照ピクチャはまた、スライスヘッダ中で明示的に指定されるか、またはいくつかの他の方法でデコーダにシグナリングされ得る。ターゲット参照ピクチャは、各参照リストの第1の参照ピクチャ(refidx=0)として決定される。
【0225】
[0162]ビデオエンコーダ20および/またはビデオデコーダ30は、所与のサブPUのための動き情報を導出するように構成され得る。前のセクションに示されているように、隣接ブロックから動き情報を取り出し、(必要な場合)動きスケーリングプロセスを実行した後に、現在サブPUの動き情報は導出される。1つの所与のサブPUのための動き情報をもつN個の利用可能な隣接ブロックがあると仮定する。第1に、予測指示(InterDir)が決定される。例示的な方法は、以下のとおりである。
【0226】
a.InterDirは0として初期化され、次いで、N個の利用可能な隣接ブロックの動き情報を通してループする、
b.リスト0中に少なくとも1つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR1)である、
c.リスト1中に少なくとも1つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR2)である。
【0227】
ここで、「bitwiseOR」はビット単位OR演算を表す。InterDirの値は、0(インター予測なし)、1(リスト0に基づくインター予測)、2(リスト1に基づくインター予測)、および3(リスト0とリスト1の両方に基づくインター予測)と定義される。
【0228】
[0163]別の例では、上記で説明された動きベクトルスケーリングのためのターゲット参照ピクチャに関する決定と同様に、多数決ルールは、すべての利用可能な隣接ブロックの動き情報に基づいて、所与のサブPUのためのInterDirの値を決定するために使用され得る。
【0229】
[0164]InterDirが決定された後、動きベクトルは導出され得る。導出されたInterDirに基づく各参照リストについて、上記で説明されたように、ターゲット参照ピクチャに対する動きベクトルスケーリングを通して利用可能なM個の動きベクトル(M≦N)があり得る。参照リストのための動きベクトルは次のように導出され得る。
【0230】
【数4】
【0231】
ここで、wiおよびwjは、それぞれ、水平動き成分および垂直動き成分のための重み付けファクタであり、OiおよびOjは、重み付けファクタに依存するオフセット値である。
【0232】
[0165]重み付けファクタは、様々なファクタに基づいて決定され得る。一例では、同じルールが1つのPU内のすべてのサブPUに適用され得る。ルールは以下のように定義され得る。たとえば、重み付けファクタは、現在サブPUと、対応する隣接ブロックとのロケーション距離に基づいて決定され得る。別の例では、重み付けファクタはまた、ターゲット参照ピクチャと、スケーリングの前の対応する隣接ブロックの動きベクトルに関連する参照ピクチャとの間のPOC距離に基づいて決定され得る。また別の例では、重み付けファクタは、動きベクトル差分または一貫性に基づいて決定され得る。また、簡単のために、すべての重み付けファクタは1に設定され得る。
【0233】
[0166]別の例では、異なるルールが1つのPU内のサブPUに適用され得る。たとえば、上記のルールが適用され得、さらに、第1の行/第1の列に位置するサブPUについて、時間隣接ブロックから導出された動きベクトルのための重み付けファクタが0に設定され、残りのブロックについて、空間隣接ブロックから導出された動きベクトルのための重み付けファクタが0に設定される。
【0234】
[0167]実際には、上記の式は、そのままで実装されるか、または容易な実装のために簡略化され得ることに留意されたい。たとえば、除算または浮動小数点演算を回避するために、固定小数点演算が、上記の式を近似するために使用され得る。一事例は、3で除算する、を回避するために、除算演算を乗算およびビットシフトと置き換えるために、43/128を乗算することを代わりに選択し得ることである。実装におけるそれらの変形形態は、本開示の技法の同じ趣旨の下でカバーされると見なされるべきである。代替的に、メジアンフィルタなど、非線形演算も、動きベクトルを導出するために適用され得る。
【0235】
[0168]ビデオエンコーダ20および/またはビデオデコーダ30はまた、STMVPのための候補リスト構築プロセス中に利用可能性検査を実行するように構成され得る。各サブPUの動きベクトル予測子が利用可能である場合でも、STMVPモードは、1つのPUのために利用不可能であるようにリセットされ得ることが提案される。たとえば、各サブPUの動きベクトル予測子が所与のPUについて導出されると、いくつかの利用可能性検査が、STMVPモードが所与のPUのために利用可能にされるべきであるかどうかを決定するために実行される。そのような演算は、STMVPモードが所与のPUについて最終的に選定される可能性が極めて低い場合をなくすために使用される。STMVPモードが利用可能でないとき、モードシグナリングはSTMVPを含まない。STMVPモードが、マージリスト中にSMTVPを挿入することによって実装される場合、マージリストは、STMVPモードが利用可能でないと決定されたとき、このSTMVP候補を含まない。その結果、シグナリングオーバーヘッドが低減され得る。
【0236】
[0169]1つのPUがM個のサブPUに区分されることについて考える。一例では、M個のサブPUのうちのN1(N1≦M)個のサブPUが同じ動きベクトル予測子(すなわち、同じ動きベクトルおよび同じ参照ピクチャインデックス)を有する場合、STMVPは、N1がしきい値よりも小さいか、または予測子がマージリスト中の(より小さいマージインデックスをもつ)他の動きベクトル予測子とは異なるときのみに利用可能にされる。別の例では、STMVPモード下でのN2(N2≦M)個のサブPUが、ATMVP下での対応するサブPUと同じ動きベクトル予測子を共有する場合、STMVPは、N2が別のしきい値よりも小さいときのみに利用可能にされる。本開示の一例では、N1のためのしきい値とN2のためのしきい値の両方がMに等しく設定される。
【0237】
[0170]STMVPが利用可能である場合、ビデオエンコーダ20および/またはビデオデコーダ30はSTMPV候補をマージリスト中にに中に挿入する。上記のATMVPについての箇条1におけるプロセスは拡張され得、STMVP候補は、ATMVP候補の前または後のいずれかに挿入され得る。一例では、STMVP候補は、マージリスト中のATMVP候補のちょうど後に(right after)挿入される。
【0238】
[0171]POCベースMVプルーニング技法は、その内容全体が参照により本明細書に組み込まれる、2017年2月13日に出願された米国出願第15/431,321号に記載されている。MV予測の効率を最大にする(maximize)ために、利用可能なMVの一意性が調べられ得る。他の場合、冗長MVは、ターゲットデバイスのビットバジェットまたはリソースを浪費することなど、非効率的なリソース利用につながることになる。したがって、MV候補の冗長性をなくすこと、いわゆるプルーニングは、MV予測においてより有意味な(meaningful)MV候補を与えるために、MVをできるだけ一意および多様に保つために重要なステップであり得る。
【0239】
[0172]本開示は、3つの主要な強み、すなわち、(1)より高い精度、(2)単純さ、および(3)普遍性を有するPOCベースプルーニングについて説明する。提案される技法は、それが既存のプルーニング方法によってキャプチャされなかった冗長MVを検出することができるので、より高いプルーニング精度を有する。さらに、それは、さらなる複雑さが必要とされないので、単純である。最後に、POCベースプルーニングは、それが、汎用性のある(versatile)状況、たとえば、ATMVP/マージ候補のための空間MV、サブPU(ATMVPおよびSTMVP)MV、TMVP、組合せMV、さらには0MVに適用され得るという点で普遍である。
【0240】
【表1】
【0241】
[0173]表1は、POCベースの方法を使用してどんな種類のMVペアがプルーニングされ得るかを要約している。カテゴリーC1では、(サブPUでない)通常PUからのMVが比較される。比較は、2つの単MV(たとえば、単予測のための動きベクトル)または2つの双MV(たとえば、双予測のための動きベクトル)のいずれかの間であり得る。C2からC4まで、(1つまたは複数の)サブPU MVは比較に含まれる。C2では、POCベースプルーニングは、PU内のサブPU MVがすべて同等であるかどうかを決定するために使用される。これは、C1における同じ技法をサブPUからのMVに適用することによって扱われ得る。すべてのサブPU MVが等しい状況はC3に分類され(falls into)、ここで、MVはサブPUからのすべてのMVを表し、したがって、C1の場合と同じ比較が適用される。しかし、候補のすべてのサブPU MVが等しくなく、サブPU MVを有する別の候補、すなわち、C4が存在する場合、POCベースプルーニングは、PU内の同じ位置に位置するサブPUからのMVの各ペアに適用される。C5とC6の両方は、2つの単MV、すなわち、L0からの単MVと、L1からの別の単MVを組み合わせることによって、双MV構築に関係する。2つの単MVが同等(たとえば、同じ参照ピクチャからの同じMV)である場合、得られた双MVが単MVと同じになるので、双MV構築は必要とされない。したがって、POCベースプルーニングは、特にL0とL1とが同じ参照ピクチャを有するとき、同等のMVをより正確に検出することによってリソースを節約するのを助けることができる。
【0242】
[0174]候補の所与のリストの場合、マージ候補リストの効率を決定し得る2つのファクタは、(1)候補リストの順序付け(たとえば、リスト中の候補の順序をどのように割り当てるべきか)、および(2)プルーニング(たとえば、それらの候補の間の冗長性を除去すること)である。概して、第1の候補へのインデックスがより少数でシグナリングされ得るので、候補リスト中の順序で第1になるために最も可能性がある選定された候補を有することが選好される。また、リスト中により様々な候補を有すること(たとえば、より少ない冗長性)は、より正確な動きベクトルがリスト中の候補の間に存在する機会を増加させる。
【0243】
[0175]本開示の技法は、可能な候補のより大きいグループからマージ候補のセットを決定するための技法を含む。さらに、本開示は、動きベクトル候補リストのより高い効率を達成するための、マージ候補の適応選択、順序付けおよびプルーニングのための技法について説明する。適応順序付けの場合、提案される技法は、(たとえば、リスト中のより小さいインデックスを生じる)より高い優先度を、より正確な動き情報を有するより高い可能性をもつ候補に割り当てるために、さらなるMV情報を活用する。適応プルーニングの場合、動きベクトル差分(MVD)を適応しきい値と比較することによって2つのMVが同等である(または極めて近い)かどうかを決定するために、MVDが使用され得る。
【0244】
[0176]提案される技法のフレキシビリティにより、本開示の技法は、H.264、HEVC、またはH.266など、既存の最先端のコーデックの大部分に適用され得、上記で説明されたQTBT構造など、異なる区分フレームワークに容易に拡張され得る。さらに、提案される技法の異なる組合せは、特定の適用例のための所望のソリューションに組み合わせられ得る。すなわち、以下の技法は、独立して、または任意の相互排他的でない組合せで適用され得る。
【0245】
[0177]さらに、以下の提案される技法は、HEVCまたはH.266参照ソフトウェアの場合のようなマージインデックス以外の追加のシグナリングなしに実行され得る。すなわち、いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、所定のルールのセットに基づいて、および明示的シグナリングを使用せずに以下の技法を実行するように構成され得る。ビデオエンコーダ20は、現在ブロックのためのマージインデックスをシグナリングするように構成され得、ビデオデコーダ30は、マージ候補を導出するために、ビデオエンコーダ20が実行するのと同じプロシージャを実行するように構成され得る。したがって、受信されたマージインデックスを用いて、ビデオデコーダ30は、不整合なしに(without any mismatch)同等のMV情報を決定するように構成され得る。
【0246】
[0178]図16は、現在ブロック450のための隣接ブロックの例示的なセットを示す。図16に示されているように、陰影を付けられた隣接ブロックa、e、f、j、およびkは、HEVCにおいて空間マージ候補として使用されるものと同じである。本開示は、現在ブロック450の前にコーディングされる追加の隣接ブロックからの動き情報を使用することを提案する。そのような追加の隣接ブロックは隣接ブロックb、c、d、g、h、およびiを含み得る。より多くの隣接ブロックから最終動きベクトル候補リストを導出することによって、より正確な動きベクトルが動きベクトル候補リストの中に(among)あるという可能性が増加される。
【0247】
[0179]図16の例では、現在ブロック450は16×16であり、隣接ブロックの各々は4×4ブロックである。しかしながら、隣接ブロックが、現在ブロックのサイズに基づく異なるサイズのものであり得ることに留意されたい。概して、ビデオエンコーダ20およびビデオデコーダ30は、現在ブロック450のための候補の動きベクトル候補リストを構築するように構成され得、ここで、動きベクトル候補リストは、現在ブロックに対するある数の(a number of)隣接ブロックからの動きベクトル情報を含んでおり、ここにおいて、隣接ブロックの数は5よりも大きい。
【0248】
[0180]本開示の別の例では、ビデオエンコーダ20およびビデオデコーダ30は、隣接ブロックからの動き情報の動きベクトルヒストグラムベース順序付けを使用して動きベクトル候補リストを構築するように構成され得る。動きが空間的に均質である(たとえば、ピクチャ中の所与の空間ロケーションにおいて同じ、または同じに近い可能性がある)という仮定に基づいて、隣接ブロックの優勢(dominant)動き情報は、現在ブロックのために選択された動き情報である可能性が高い。したがって、ビデオエンコーダ20およびビデオデコーダ30は、隣接ブロックの動きベクトル分布から動きベクトルヒストグラムを導出するように構成され得る。上記で説明されたように、動きベクトル情報は3次元ベクトル(MVx,MVy,方向)を含み、ここで、MVxは動きベクトルの水平成分であり、MVyは動きベクトルの垂直成分であり、ここで、方向は、過去(参照リストL0)予測方向または将来(参照リストL1)予測方向のいずれかを指す。図13を参照すると、ビデオエンコーダ20およびビデオデコーダ30は、特定の動きベクトルがどのくらいの頻度で(how often)隣接ブロックa~kの各々について同じであるかを決定し得る。
【0249】
[0181]ビデオエンコーダ20およびビデオデコーダ30は、複数の異なる方法でヒストグラム情報を使用し得る。一例では、ビデオエンコーダ20およびビデオデコーダ30は、どの動きベクトルが、したがって、どの隣接ブロックが候補リスト中の空間マージ候補として使用され得るかを決定するために、ヒストグラム情報を使用し得る。別の例では、ビデオエンコーダ20およびビデオデコーダ30は、どの順序でリストにいくつかの(certain)空間マージ候補を追加すべきかを決定するために、ヒストグラムを使用し得る。
【0250】
[0182]概して、ビデオエンコーダ20およびビデオデコーダ30は、隣接ピクセルまたはブロックから動きベクトルヒストグラムを導出するように構成され得る。上記で説明されたように、図16は、16×16現在ブロック450の動きベクトルヒストグラムのために使用されるべき4×4隣接ブロック(a~k)の一例を示す。ハイライトされたブロック(a、e、f、j、およびk)は、HEVCにおける空間マージ候補のロケーションである。
【0251】
[0183]いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、あるサイズをもつ隣接ブロックの動きベクトル分布から動きベクトルヒストグラムを導出する。図16は、MVヒストグラムを構築するためにどんな隣接ブロック(a~k)が使用されるかを示す。隣接ブロックのユニットサイズは、特定のサイズ、たとえば、4×4、または動き補償のための何らかのあらかじめ定義された最小サイズであり得る。ブロックが、関連する動き情報(たとえば、イントラ予測されたブロック)を有しない場合、それらは、無視されるか、または他の隣接ブロックからの動き情報で満たされ得る。たとえば、隣接ブロックhがイントラ予測されたブロックである場合、ビデオエンコーダ20およびビデオデコーダ30は、その隣接ブロックを単に使用しないことがある。他の例では、隣接ブロックhがイントラ予測されたブロックである場合、ビデオエンコーダ20およびビデオデコーダ30は、隣接ブロックhの左のブロックからの動き情報を使用し得る。
【0252】
[0184]図16中の一例に示されているように、16×16現在ブロックのMVヒストグラムを構築するために、ビデオエンコーダ20およびビデオデコーダ30は、4×4のサイズをもつ(ブロックaからブロックkまでの)11個の隣接ブロックを調べ得る。隣接ブロックは、(最上行/左列を含む)図16の場合のようにあらかじめ定義されるか、あるいは現在ブロックのサイズおよび/または形状に依存し得ることに留意されたい。
【0253】
[0185]別の例では、ヒストグラムは、隣接ブロックのサイズに比例するある重みを用いて構築され得る。たとえば、隣接ブロックに属するピクセルの数(またはユニットブロック、すなわち4×4ブロック)は、ヒストグラムのための重みとして使用され得る。すなわち、より大きいブロック(詳細には、より多くのピクセルを含んでいるブロック)からの動きベクトルは、それらのブロック内のピクセルの数に比例するより高い重みを有する。別の例では、ヒストグラムのための重みは、上述の2つのファクタ、すなわち、隣接ブロック内のピクセル(またはユニットブロック)の数と、現在ブロックに隣接するピクセル(またはユニットブロック)の数との組合せによって決定され得る。
【0254】
[0186]ビデオエンコーダ20とビデオデコーダ30の両方が、不整合を回避するためにヒストグラムを構築するために同等のルールに従うべきであることに留意されたい。ビデオエンコーダ20およびビデオデコーダ30の両方において同等のヒストグラムを仮定すれば、マージ候補のためのすべての以下の適応方式が、等価マージリストにつながることになる。
【0255】
[0187]動きベクトルヒストグラムを決定した後に、ビデオエンコーダ20およびビデオデコーダ30は、次いで、動きベクトル候補リスト中の空間マージ候補の順序を決定するためにヒストグラムを使用し得る。いくつかの例では、構築されたヒストグラムは、所与の(固定の)Nf個の空間マージ候補の順序を決定するために使用され得、ここで、Nfは固定空間候補の数である。一例として、固定のNf個の空間候補は、HEVCにおいて使用されるように、隣接ブロックa、e、f、j、およびkであり得る。しかしながら、候補の総数の任意のサブセットが使用され得る。たとえば、図16を参照すると、隣接ブロックa~kの任意の固定サブセットが空間マージ候補として使用され得る。
【0256】
[0188]利用可能な隣接ブロックの各動きベクトルの頻度に応じて、ヒストグラムからの最も頻度が高い動きベクトルが、最初にマージリストに挿入され、ヒストグラムからの最も頻度が低い動きベクトルが、リストに挿入されるべき空間マージ候補の中の最後の1つである。たとえば、図16は、HEVCにおいて使用される5つの空間マージ候補(a、e、f、j、k)を示す。それらの候補の固定順序(HEVCにおけるj-e-f-k-aの順序)に従う代わりに、ビデオエンコーダ20とビデオデコーダ30の両方は、MVヒストグラムから順序を適応的に決定する構成され得る。別の例では、各隣接ブロック(たとえば、4×4空間マージ候補)を検査する代わりに、空間マージング候補の並べ替えは、空間マージング候補を導出するために使用されるブロックを含んでいる予測ブロック(たとえば、HEVCにおけるPU)のサイズに基づく。
【0257】
[0189]図17の例について考える。図17に示されているように、3つの隣接ブロック(e、g、およびh)は動きベクトル0(MV0)を有し、4つの異なる隣接ブロック(a、b、c、およびd)は動きベクトル1(MV1)を有し、1つの隣接ブロック(f)は動きベクトル2(MV2)を有し、2つの異なる隣接ブロック(iおよびj)は動きベクトル3(MV3)を有し、1つの隣接ブロック(k)は動きベクトル4(MV4)を有する。したがって、ビデオエンコーダ20およびビデオデコーダ30は、固定候補a、e、f、j、およびkを使用して、動きベクトル候補リストを、MV1-候補a(インデックス0)、MV0-候補e(インデックス0)、MV3候補j(インデックス0)、MV2候補f(インデックス0)、MV4-候補k(インデックス0)のように順序付けるように構成されることになる。図17の例は、すべての隣接ブロックが同じ重みを有すると仮定する。いくつかの例では、固定候補のうちの2つまたはそれ以上(two or more)がヒストグラム(たとえば、図17中のMV2およびMV4)中で同じ発生回数を有する同じ関連する動きベクトルを有する場合、候補を検査するもののために所定の順序が使用され得る。図17の例では、候補fは、候補kの前にリスト中に配置される。しかしながら、任意の所定の順序が使用され得る。
【0258】
[0190]本開示の別の例では、動きベクトルヒストグラムを決定した後に、ビデオエンコーダ20およびビデオデコーダ30は、次いで、順序にかかわらず、動きベクトル候補リスト中の空間マージ候補として隣接ブロックのうちのどれを使用すべきかを決定するためにヒストグラムを使用し得る。すなわち、固定Nf数の空間マージング候補を使用したではなく、ビデオエンコーダ20およびビデオデコーダ30は、リスト中の空間マージ候補としてすべての可能な隣接ブロックのうちのどれを使用すべきかを決定し得る。この例では、図16に関して、すべての隣接ブロックa~kは、動きベクトル候補リスト中の空間マージ候補として含めるために考慮され得る。
【0259】
[0191]ビデオエンコーダ20およびビデオデコーダ30は、利用可能な隣接ブロックの総数のうちのどの隣接ブロックが、動きベクトル候補リスト中で所定の数(Nh)の候補を作成する(make up)ことになるかを決定するために、動きベクトルヒストグラムを使用し得る。上記で説明されたように、候補の所与のリストの順序のみを変更する代わりに、決定された空間マージ候補のロケーション(たとえば、どの実際の隣接ブロック)と順序の両方は、決定されたヒストグラム中の隣接動きベクトル分布から適応的に導出され得る。たとえば、Nh=2である場合、隣接ブロックからの2つの最も頻度が高い動きベクトルが、マージリストにおいて頻度の順序で配置される。2つ以上の(more than one)隣接ブロックが、ヒストグラム中で最も頻度が高い動きベクトルに関連する場合、ビデオエンコーダ20およびビデオデコーダ30は、隣接ブロックのうちのどれを候補リスト中に配置すべきかを決定するために所定のルールを使用し得る。しかしながら、いかなるルールが使用されても、ヒストグラム中で最も高い頻度で出現する動きベクトルに関連する隣接ブロックが、動きベクトル候補リストに追加されることになることに留意されたい。この例によれば、図17を参照すると、MV0に関連する隣接ブロックと、MV1に関連する隣接ブロックとが、動きベクトル候補リストに追加されることになる。
【0260】
[0192]いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、決定されたヒストグラムを使用するマージリスト構築のための上記の技法の両方を使用するように構成され得る。すなわち、ビデオエンコーダ20およびビデオデコーダ30は両方とも、ヒストグラムを使用して候補の固定セットを順序付け得、ならびにヒストグラムに基づいてある数(Nh)の非固定候補を追加すること得る。上述のように、Nf個の空間マージ候補のロケーションは、すべてのブロック、たとえば、図16中のブロックa、e、f、j、およびk全体にわたって固定される。さらに、隣接ブロックからのNhの最も高い頻度で出現する動き情報は、空間マージ候補としてリストに追加され、次いで、(Nf+Nh)個の候補の順序は、決定されたヒストグラム中の関連する動きベクトルの発生頻度に基づいて決定される。
【0261】
[0193]別の例では、Nf個の空間マージ候補のロケーションは、すべてのブロック、たとえば、図16中のブロックa、e、f、j、およびkのすべてにわたって固定され、ビデオエンコーダ20およびビデオデコーダ30は、決定されたヒストグラムを使用して固定候補の順序を決定する。さらに、隣接ブロックからのNhの最も高い頻度で出現する動き情報がリストに追加されるが、さらなる(additional)Nh個の候補は、ある所定の位置に(たとえば、図16中のブロックeからの動きベクトルの前または後に)挿入される。
【0262】
[0194]別の例では、本開示は、サブPUマージ候補、たとえば、上記で説明されたATMVPおよびATMVP_EXT候補の適応順序付けについて説明する。JEM2.0ソフトウェアの一例では、ATMVPおよびATMVP_EXTは、(たとえば、図16に示されているように)常に候補kと候補aとの間に配置される。マージリスト中の固定ロケーションにおいてATMVP/ATMVP_EXTを配置する代わりに、ビデオエンコーダ20およびビデオデコーダ30は、他の利用可能なマージ候補、ATMVP/ATMVP_EXT、またはそれらの組合せに関する(relate to)状態に応じて、ATMVP/ATMVP_EXT候補を適応的に配置するように構成され得る。
【0263】
[0195]いくつかの例では、ATMVP/ATMVP_EXT候補のロケーションを決定するために、2つの空間マージ候補間の動きベクトル差分(MVD)が活用され得る。ビデオエンコーダ20およびビデオデコーダ30は、動きベクトルの関数としてMVDを計算するように構成され得る。一例では、2つのMV間の絶対差分和は、MVD=abs(MVx[1]-MVx[0])+abs(MVy[1]-MVy[0])である。別の例では、関数は、MVD=(MVx[1]-MVx[0])*(MVx[1]-MVx[0])+(MVy[1]-MVy[0])*(MVy[1]-MVy[0])として定義される。MVDを計算するための関数が、整数、1/2、1/4、1/8、または1/16ピクセル精度などの動きベクトル精度に基づいて異なり得ることに留意されたい。
【0264】
[0196]たとえば、常に、図16中の候補kと候補aとの間にATMVP/ATMVP_EXTを配置する最新のJEMソフトウェアとは異なり、ビデオエンコーダ20およびビデオデコーダ30は、候補jと候補kとの間のMVD(MVDjk)に応じて、候補kの前にATMVP/ATMVP_EXT候補を位置させるように構成され得る。MVDjkがしきい値TH1よりも小さいか、または別のしきい値TH2よりも大きい場合、すなわち、MVDjk<TH1またはMVDjk>TH2である場合、ATMVP/ATMVP_EXTは、候補kの前に位置する。たとえば、適応しきい値は、すべてのまたは(いくつかの)空間的に隣接する動きベクトルの間の最小MVDをとることによってTH1を算出することと、最大MVDをとることによってTH2を算出することとによって使用され得、ここで、算出は、同等のMVペアならびに(MVjおよびMVk)のペアを除外する。ビデオエンコーダ20とビデオデコーダ30の両方は、同等の隣接動きベクトルアクセスを有する(have access identical neighboring motion vectors)ので、算出は、同じTH1およびTH2をもたらすことになる。代替的に、TH1とTH2の両方は実験的に決定され得、たとえば、1/16ピクセルMV精度でTH1=2およびTH2=8である。他の場合、候補kは、リスト中でATMVP/ATMVP_EXTの前にある。同様に、ビデオエンコーダ20およびビデオデコーダ30は、候補eと候補fとの間のMVD(MVDef)を調べることによって、ATMVP/ATMVP_EXT候補と候補fとの順序を決定するように構成され得る。MVD算出のために使用される候補、すなわち、上記の例における候補kまたは候補aのうちの1つがマージリスト中で利用可能であるか、またはそれらのいずれも利用可能でない場合(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)、ATMVP/ATMVP_EXT候補は、デフォルト順序で動きベクトル候補リスト中に配置され得る。
【0265】
[0197]別の例では、ビデオエンコーダ20およびビデオデコーダ30は、それらの候補が動きベクトル候補リスト中でどこに位置することになるかを決定するために、ATMVP/ATMVP_EXT候補の特性、たとえば、サブブロックMVの分散またはサブブロックMVの空間分布を分析するように構成され得る。分散が範囲[TH1,TH2]内にある場合、より高い優先度、すなわち、リスト中のより小さいインデックスが割り当てられる。範囲[TH1,TH2]は、最良のマージ候補としてATMVPまたはATMVP_EXTを選定した、前にコーディングされたブロックのサブブロックMVの平均分散によって、TH1=C1*Var1およびTH2=C2*Var2のように決定され得、ここで、Var1およびVar2は、前にコーディングされたブロックから算出され、記憶される。係数C1およびC2は定数として固定であるか、あるいは現在ブロックのサイズおよび/または形状に依存し得る。範囲は現在ブロックのサイズおよび/または形状に依存し得る。より大きいブロックの場合、TH1とTH2の両方は増加し、範囲はより広くなる。範囲は動きベクトル精度に依存し得る。
【0266】
[0198]別の例では、ビデオエンコーダ20およびビデオデコーダ30は、それらの候補の間の順序を決定するために、空間マージ候補とATMVP/ATMVP_EXT候補の両方のステータスを分析するように構成され得る。たとえば、ATMVPまたはATMVP_EXT候補からの最も頻度が高いサブブロック動きベクトル、または平均動きベクトルは、サブブロックの代表(delegate)MVと見なされ得る。代表的動きベクトルは、空間候補、たとえば、図16中のブロックfに対するMVDを算出するために使用され得る。MVDがTH1よりも大きいが、TH2よりも小さい場合、ビデオエンコーダ20およびビデオデコーダ30は、空間候補の前にATMVP/ATMVP_EXT候補を配置するように構成され得る。
【0267】
[0199]HEVCでは、組合せ動きベクトル(combi-mv:combination motion vector)候補は、両方の予測方向、すなわち、参照リストL0および参照リストL1のための2つの動きベクトルを含む、2つの利用可能な双方向マージ候補、すなわち、C1およびC2を使用して導出される。C1とC2の両方が双方向MVを有する、すなわち、候補C1のためのMVL0C1およびMVL1C1、ならびに候補C2のためのMVL0C2およびMVL1C2と仮定する。ビデオエンコーダ20およびビデオデコーダ30は、C1からL0 MVをとり、C2からL1 MVをとることによって、新しいcombi-mv、すなわち(MV0,MV1)を導出するように構成され得、(MV0,MV1)=(MVL0C1,MVL1C2)である。同様に、ビデオエンコーダ20およびビデオデコーダ30は、残りのMVをとることによって別のcombi-mvを導出するように構成され得、(MV0’,MV1’)=(MVL0C2,MVL1C1)であり得る。
【0268】
[0200]いくつかの例では、combi-mv候補の最大数は固定である。HEVCでは、利用可能なマージ候補の数が、マージ候補の最大数、たとえば、HEVCでは5よりも少なく、2つ以上の双方向マージ候補がリスト中で利用可能である場合、多くとも(at most)12個のcombi-mv候補がマージ候補と見なされ得る。HEVCの拡張では、ATMVPおよびATMVP_EXT候補などのより多くのマージ候補が追加され、したがって、combi-mv候補の最大数を、12からある大きい数(certain large number)、たとえば30まで増加させることは、可能な拡張(possible extension)である。
【0269】
[0201]本開示の別の例では、ビデオエンコーダ20およびビデオデコーダ30は、必要な場合(たとえば、マージ候補の最大数にまだ達しない場合)より多くのcombi-mvを考慮するように構成され得る。たとえば、利用可能なマージ候補間の類似度が、あるしきい値よりも高い場合、combi-mv候補はまた、既存の候補に類似することになり、したがって、combi-mvの最大数は抑制される。類似度は、絶対差分和(SAD:sum of absolute differences)、SATD、平均ルミナンスまたはクロミナンス値、ピクセルの分散、および/またはMV軌道によって測定され得る。
【0270】
[0202]より多くのcombi-mvが考慮される場合、適応順序付けが、予備(spare)combi-mv候補からの利益を最大にすると見なされ得る。combi-mv候補の順序を仮定すれば、以下の技法は、ある基準に関して候補を並べ替える。その基準に入らない候補は、デフォルト順序に従う。
【0271】
[0203]いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、導出されたcombi-mvと利用可能な候補からの既存のmvとの間の類似度に関して、combi-mv候補を並べ替える(reorder)ように構成され得る。C1とC2の両方が、双方向MV、すなわち、MVC1=(MVL0C1,MVL1C1)とMVC2=(MVL0C2,MVL1C2)とを有し、2つのcombi-mvがMVcombi-1=(MVL0C1,MVL1C2)およびMVcombi-2=(MVL0C2,MVL1C1)のように導出され得ると仮定する。MVL0C1およびMVL0C2(ならびに/またはMVL1C2およびMVL1C1)が同じピクチャを指す場合、MVL0C1とMVL0C2と(および/またはMVL1C2とMVL1C1と)の間のMVDが算出される。次いで、ビデオエンコーダ20およびビデオデコーダ30は、以下の条件のうちの1つが満たされた場合、すなわち、(1)MVDが2つのしきい値間にある、すなわち、TH1<MVD<TH2である場合、または(2)MVL0C1とMVL0C2とが、異なるピクチャを指す場合、プルーニングの後に、動きベクトル候補リストに導出されたcombi-mvを追加するように構成され得る。他の場合、combi-mvは後に(behind)残される。1/16ピクセル動きベクトル精度の場合の一例では、現在ブロックの幅と高さの両方が8よりも小さいとき、TH1=2およびTH2=8である。現在ブロックの幅および高さが8よりも大きく、32よりも小さい場合、TH1=8およびTH2=32である。幅および高さが32よりも大きい場合、TH1=16およびTH2=64である。それらの条件を満たすすべてのcombi-mv候補が最初にマージリストに追加されると、ビデオエンコーダ20およびビデオデコーダ30は、プルーニングの後にリストに残りのcombi-mvを追加するように構成され得る。しきい値、TH1およびTH2は、現在ブロックのサイズまたは形状、たとえば、max(幅,高さ)によって適応的に選定され得る。
【0272】
[0204]また別の例では、ビデオエンコーダ20およびビデオデコーダ30は、上述のMVDに関してcombi-mv候補をソートするように構成され得る。簡単のために、異なるピクチャを指すMVL0C1およびMVL0C2(またはMVL1C1およびMVL1C2)をもつ(whose)combi-mv候補のMVDは、0として設定される。combi-mv候補が等しいMVD値を有する(have equal MVD values)場合、それらはデフォルト順序に従う。ソートされると、ビデオエンコーダ20およびビデオデコーダ30は、プルーニングの後に動きベクトル候補リストに候補を追加するように構成され得る。
【0273】
[0205]POCベースプルーニングに加えて、上記で説明されたように、ビデオエンコーダ20およびビデオデコーダ30は、動きベクトル自体以外の追加情報(たとえば、現在ブロックのサイズおよび/または形状、ターゲットマージ候補のタイプ、ならびに/あるいは空間の場合(if spatial)マージ候補のロケーション)によって決定されるべき適応基準を使用してマージ候補をさらにプルーニングするように構成され得る。
【0274】
[0206]いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、適応しきい値よりも小さいMVDをもつMVのペアを同等と見なし、したがって、動きベクトル候補リストをさらに多様化させるためにプルーニングされると見なす(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)ように構成され得る。しきい値は、現在ブロックのサイズおよび/または形状によって適応的に選定され得る。
【0275】
[0207]いくつかの例では、上記の適応しきい値を用いた(with)MVDベースプルーニングなどのプルーニング方法が、すべてのタイプのマージ候補、すなわち、空間候補、時間候補、サブブロック候補、またはcombi-mv候補に適用され得る。また別の例では、異なるタイプの候補について、異なる基準が考慮され得る。空間候補の一例として、それらの候補が導出されるロケーション間の距離が、適応しきい値を決定するためのメトリックとして使用され得る。たとえば、2つの動きベクトルが、隣接するブロック、たとえば、図16中のブロックeおよびfから導出された場合、動きベクトルは、動きベクトルが遠い(distant)ブロック、たとえば、図16中のブロックfおよびkから導出されたしきい値よりも小さいしきい値によってプルーニングされる。
【0276】
[0208]いくつかの例では、双方向マージ候補の場合、2つの単予測ブロック(uni-predicted blocks)(L0からの単予測ブロック、およびL1方向からの別の単予測ブロック)の類似度は、マージ候補がどのくらい信頼できるかを示すことができる(could)。この観測に基づいて、ビデオエンコーダ20およびビデオデコーダ30は、2つの単予測ブロックの類似度を使用することによって双方向マージ候補を区別する(differentiate)ために測定値を使用し、それに応じて、双方向マージ候補を並べ替えるように構成され得る。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、類似度を決定するために、絶対差分和(SAD)、SSE、SATD、平均ルミナンスまたはクロミナンス値、ピクセルの分散、および/あるいはMV軌道を使用するように構成され得る。より複雑なメトリックが、予測性能を測定するためにより高い精度を与えることができる。メトリックの決定は、ターゲット適用例の要件に依存し得る。
【0277】
[0209]SADが使用される場合、所与の2つの双方向マージ候補、C1およびC2のために、各双方向候補についてL0方向とL1方向との間で2つのSAD、すなわち、SADC1およびSADC2が算出される。ビデオエンコーダ20およびビデオデコーダ30は、マージリスト中で、より小さい最終SAD、すなわち、SADC1またはSADC2をもつ候補を、他方の前方に(ahead of the other)配置するように構成され得る。
【0278】
[0210]いくつかの例では、上記で説明されたすべての提案される技法は、動きベクトル候補リストを構築するために組み合わせられ得る。また別の例では、提案される技法のあるセットまたはサブセットが組み込まれ得る。
【0279】
[0211]図18は、本開示の例示的な符号化方法を示すフローチャートである。図18の技法は、動き推定ユニット42と動き補償ユニット44とを含む、ビデオエンコーダ20の1つまたは複数のハードウェアユニットによって実行され得る。
【0280】
[0212]本開示の一例では、ビデオエンコーダ20は、ビデオデータの現在ブロックを受信するように構成され得る(500)。ビデオエンコーダ20は、現在ブロックに対する隣接ブロックのための動きベクトル情報のヒストグラムを導出し得る(502)。本開示の一例では、動きベクトル候補リストのために考慮される隣接ブロックの数は、現在ブロックのサイズに基づき、隣接ブロックの数は5よりも大きい。このコンテキストでは、「考慮される(considered)」という用語は、ビデオエンコーダ20が、隣接ブロックを分析することと、隣接ブロックが関連する動き情報を有するかどうかを決定することと、隣接ブロックが関連する動き情報を有する場合、動きベクトル候補リストを構築するために動き情報を使用することとを含み得る。上記で説明されたように、動き情報は、動きベクトル候補リストに直接追加され得るか、または動きベクトル候補リスト中で空間マージ候補として使用すべき隣接ブロックの順序および/またはロケーションを決定するために使用され得るヒストグラムを構築するために使用され得る。ビデオエンコーダ20は、ビデオデータの現在ブロックに対する(relative to)上記数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築するようにさらに構成され得る。いくつかの例では、考慮される動き情報は、導出されたヒストグラムである(504)。ビデオエンコーダ20は、次いで、動きベクトル候補リストから現在動きベクトルを決定し(506)、現在動きベクトルを使用してビデオデータの現在ブロックを符号化する(508)。
【0281】
[0213]本開示の別の例では、ビデオエンコーダ20は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける(order a predetermined fixed subset of spatial merge candidates in the motion vector candidate list based on the derived histogram)ように構成され得る。
【0282】
[0214]本開示の別の例では、ビデオエンコーダ20は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の(a fixed number of)空間マージ候補を決定するように構成され得る。
【0283】
[0215]本開示の別の例では、ビデオエンコーダ20は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、決定された固定数の空間マージ候補とを順序付けることとを行うように構成され得る。
【0284】
[0216]本開示の別の例では、ビデオエンコーダ20は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、動きベクトル候補リスト中の所定のロケーションにおいて、決定された固定数の空間マージ候補を挿入することとを行うように構成され得る。
【0285】
[0217]本開示の別の例では、ビデオエンコーダ20は、1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、動きベクトル候補リストにATMVP候補を追加するように構成され得る。本開示の別の例では、ビデオエンコーダ20は、1つまたは複数のATMVP候補のための動きベクトルの関数に基づいて、ATMVP候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【0286】
[0218]本開示の別の例では、ビデオエンコーダ20は、2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、動きベクトル候補リストに組合せ動きベクトル候補を追加することとを行うように構成され得る。
【0287】
[0219]本開示の別の例では、ビデオエンコーダ20は、1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、組合せ動きベクトル候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【0288】
[0220]本開示の別の例では、ビデオエンコーダ20は、動きベクトル候補リスト中の動きベクトル候補の動きベクトル差分情報に基づいて、動きベクトル候補リストをプルーニングするように構成され得る。
【0289】
[0221]本開示の別の例では、ビデオエンコーダ20は、動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、双方向候補を順序付けるように構成され得る。
【0290】
[0222]図19は、本開示の例示的な復号方法を示すフローチャートである。図19の技法は、動き補償ユニット72を含む、ビデオデコーダ30の1つまたは複数のハードウェアユニットによって実行され得る。
【0291】
[0223]本開示の一例では、ビデオデコーダ30は、マージモードを使用して符号化されたビデオデータの現在ブロックを受信するように構成され得る(550)。ビデオデコーダ30は、現在ブロックに対する隣接ブロックのための動きベクトル情報のヒストグラムを導出する(552)。本開示の一例では、動きベクトル候補リストのために考慮される隣接ブロックの数は、現在ブロックのサイズに基づき、隣接ブロックの数は5よりも大きい。このコンテキストでは、「考慮される」という用語は、ビデオデコーダ30が、隣接ブロックを分析することと、隣接ブロックが関連する動き情報を有するかどうかを決定することと、隣接ブロックが関連する動き情報を有する場合、動きベクトル候補リストを構築するために動き情報を使用することとを含み得る。上記で説明されたように、動き情報は、動きベクトル候補リストに直接追加され得るか、または動きベクトル候補リスト中で空間マージ候補として使用すべき隣接ブロックの順序および/またはロケーションを決定するために使用され得るヒストグラムを構築するために使用され得る。ビデオデコーダ30は、ビデオデータの現在ブロックに対する上記数の隣接ブロックからの動き情報に基づいて、現在ブロックのためのマージ候補の動きベクトル候補リストを構築するようにさらに構成され得る。いくつかの例では、考慮される動き情報は、導出されたヒストグラムである(554)。ビデオデコーダ30は、次いで、動きベクトル候補リストから現在動きベクトルを決定し(556)、現在動きベクトルを使用してビデオデータの現在ブロックを復号する(558)。
【0292】
[0224]本開示の別の例では、ビデオデコーダ30は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で所定の固定サブセットの空間マージ候補を順序付けるように構成され得る。
【0293】
[0225]本開示の別の例では、ビデオデコーダ30は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定するように構成され得る。
【0294】
[0226]本開示の別の例では、ビデオデコーダ30は、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、決定された固定数の空間マージ候補とを順序付けることとを行うように構成され得る。
【0295】
[0227]本開示の別の例では、ビデオデコーダ30は、導出されたヒストグラムに基づいて、動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、導出されたヒストグラムに基づいて、隣接ブロックの総数から、動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、動きベクトル候補リスト中の所定のロケーションにおいて、決定された固定数の空間マージ候補を挿入することとを行うように構成され得る。
【0296】
[0228]本開示の別の例では、ビデオデコーダ30は、1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、動きベクトル候補リストにATMVP候補を追加するように構成され得る。本開示の別の例では、ビデオエンコーダ20は、1つまたは複数のATMVP候補のための動きベクトルの関数に基づいて、ATMVP候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【0297】
[0229]本開示の別の例では、ビデオデコーダ30は、2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、動きベクトル候補リストに組合せ動きベクトル候補を追加することとを行うように構成され得る。
【0298】
[0230]本開示の別の例では、ビデオデコーダ30は、1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、組合せ動きベクトル候補を追加するための、動きベクトル候補リスト中のロケーションを決定するように構成され得る。
【0299】
[0231]本開示の別の例では、ビデオデコーダ30は、動きベクトル候補リスト中の動きベクトル候補の動きベクトル差分情報に基づいて、動きベクトル候補リストをプルーニングするように構成され得る。
【0300】
[0232]本開示の別の例では、ビデオデコーダ30は、動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、双方向候補を順序付けるように構成され得る。
【0301】
[0233]一例として、提案される技法の組合せは、以下の表の場合のように、JEM2.0ソフトウェア上のランダムアクセス構成において0.4%のBDレート改善を示す。以下の例における利得は、(1)ヒストグラムベース空間マージ候補順序付け、(2)MVDベース組合せマージ候補順序付けおよびプルーニング、(3)ATMVP、組合せ、0mv候補に対する(on)プルーニング、ならびに(4)増加された数のマージ候補およびcombiマージ候補のツールの組合せから来る(comes)。
【0302】
【表2】
【0303】
[0234]上記例に応じて、本明細書で説明された技法のうちのいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る(たとえば、すべての説明された行為またはイベントが本技法の実施のために必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実行され得る。
【0304】
[0235]1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明される技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【0305】
[0236]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlu-rayディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【0306】
[0237]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、あるいは他の等価な集積回路またはディスクリート論理回路など、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、上記の構造、または本明細書で説明された技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用ハードウェアおよび/またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素で十分に実装され得る。
【0307】
[0238]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明された1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって与えられ得る。
【0308】
[0239]様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
図1
図2
図3
図4
図5
図6A
図6B
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
【手続補正書】
【提出日】2022-01-24
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオデータを復号する方法であって、前記方法は、
インター予測モードで符号化されたビデオデータの現在ブロックを受信することと、
複数の隣接ブロックのうちの任意の隣接ブロックが動き情報を含むかどうかを決定するために、前記現在ブロックに対する前記複数の隣接ブロックを分析することと、ここにおいて、前記複数の隣接ブロックのうちで分析される前記隣接ブロックの数は、5よりも大きい、
複数の重みを決定することと、ここにおいて、前記複数の重みのうちの各重みは、動き情報を含む、前記複数の隣接ブロックのうちの隣接ブロックのセット内に含まれた動き情報にそれぞれ対応する、
ビデオデータの前記現在ブロックに対する前記隣接ブロックのセットからの前記動き情報に基づいて、前記現在ブロックのための動きベクトル候補リストを構築することと、
前記複数の重みに基づいて、ビデオデータの前記現在ブロックのための前記構築された動きベクトル候補リスト内の動きベクトル候補を適応的に順序付けることと、
前記動きベクトル候補リスト内の前記動きベクトル候補から現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を備える、方法。
【請求項2】
前記複数の重みを決定することは、前記対応する動き情報を含む前記隣接ブロックに属するピクセルの数に基づいて、前記複数の重みのうちの少なくとも1つの重みを決定することを備える、請求項1に記載の方法。
【請求項3】
前記複数の重みのうちの少なくとも1つの重みは、前記対応する動き情報を含む前記隣接ブロックのサイズに比例する、請求項1に記載の方法。
【請求項4】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補を適応的に順序付けることは、
前記複数の重みのうちの少なくとも1つの重みを更新することと、
前記複数の重みのうちの前記更新された少なくとも1つの重みに基づいて、前記構築された動きベクトル候補リスト内の前記動きベクトル候補の順序をソートすることと
を備える、請求項1に記載の方法。
【請求項5】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補の前記順序をソートすることは、重みのより高い値に対応する第1の動き情報を前記構築された動きベクトル候補リスト中の重みのより低い値に対応する第2の動き情報の前に配置することを備える、請求項4に記載の方法。
【請求項6】
前記複数の重みを決定することは、前記現在ブロックに隣接するピクセルの数に基づいて、前記複数の重みの各々を決定することを備える、請求項1に記載の方法。
【請求項7】
前記インター予測モードは、マージモードに対応する、請求項1に記載の方法。
【請求項8】
ビデオデータを復号するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
インター予測モードで符号化されたビデオデータの現在ブロックを受信することと、
複数の隣接ブロックのうちの任意の隣接ブロックが動き情報を含むかどうかを決定するために、前記現在ブロックに対する前記複数の隣接ブロックを分析することと、ここにおいて、前記複数の隣接ブロックのうちで分析される前記隣接ブロックの数は、5よりも大きい、
複数の重みを決定することと、ここにおいて、前記複数の重みのうちの各重みは、動き情報を含む、前記複数の隣接ブロックのうちの隣接ブロックのセット内に含まれた動き情報にそれぞれ対応する、
ビデオデータの前記現在ブロックに対する前記隣接ブロックのセットからの前記動き情報に基づいて、前記現在ブロックのための動きベクトル候補リストを構築することと、
前記複数の重みに基づいて、ビデオデータの前記現在ブロックのための前記構築された動きベクトル候補リスト内の動きベクトル候補を適応的に順序付けることと、
前記動きベクトル候補リスト内の前記動きベクトル候補から現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行うように構成された、装置。
【請求項9】
前記1つまたは複数のプロセッサは、前記対応する動き情報を含む前記隣接ブロックに属するピクセルの数に基づいて、前記複数の重みのうちの少なくとも1つの重みを決定する
ようにさらに構成される、請求項8に記載の装置。
【請求項10】
前記複数の重みのうちの少なくとも1つの重みは、前記対応する動き情報を含む前記隣接ブロックのサイズに比例する、請求項8に記載の装置。
【請求項11】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補を適応的に順序付けるために、前記1つまたは複数のプロセッサは、
前記複数の重みのうちの少なくとも1つの重みを更新することと、
前記複数の重みのうちの前記更新された少なくとも1つの重みに基づいて、前記構築された動きベクトル候補リスト内の前記動きベクトル候補の順序をソートすることと
を行うようにさらに構成される、請求項8に記載の装置。
【請求項12】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補の前記順序をソートするために、前記1つまたは複数のプロセッサは、重みのより高い値に対応する第1の動き情報を前記構築された動きベクトル候補リスト中の重みのより低い値に対応する第2の動き情報の前に配置する
ようにさらに構成される、請求項11に記載の装置。
【請求項13】
前記1つまたは複数のプロセッサは、前記現在ブロックに隣接するピクセルの数に基づいて、前記複数の重みの各々を決定する
ようにさらに構成される、請求項8に記載の装置。
【請求項14】
前記インター予測モードは、マージモードに対応する、請求項8に記載の装置。
【請求項15】
ビデオデータを符号化するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
インター予測モードで符号化されたビデオデータの現在ブロックを受信することと、
複数の隣接ブロックのうちの任意の隣接ブロックが動き情報を含むかどうかを決定するために、前記現在ブロックに対する前記複数の隣接ブロックを分析することと、ここにおいて、前記複数の隣接ブロックのうちで分析される前記隣接ブロックの数は、5よりも大きい、
複数の重みを決定することと、ここにおいて、前記複数の重みのうちの各重みは、動き情報を含む、前記複数の隣接ブロックのうちの隣接ブロックのセット内に含まれた動き情報にそれぞれ対応する、
ビデオデータの前記現在ブロックに対する前記隣接ブロックのセットからの前記動き情報に基づいて、前記現在ブロックのための動きベクトル候補リストを構築することと
前記複数の重みに基づいて、ビデオデータの前記現在ブロックのための前記構築された動きベクトル候補リスト内の動きベクトル候補を適応的に順序付けることと、
前記動きベクトル候補リスト内の前記動きベクトル候補から現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを符号化することと
を行うように構成された、装置。
【請求項16】
前記1つまたは複数のプロセッサは、前記対応する動き情報を含む前記隣接ブロックに属するピクセルの数に基づいて、前記複数の重みのうちの少なくとも1つの重みを決定する
ようにさらに構成される、請求項15に記載の装置。
【請求項17】
前記複数の重みのうちの少なくとも1つの重みは、前記対応する動き情報を含む前記隣接ブロックのサイズに比例する、請求項15に記載の装置。
【請求項18】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補を適応的に順序付けるために、前記1つまたは複数のプロセッサは、
前記複数の重みのうちの少なくとも1つの重みを更新することと、
前記複数の重みのうちの前記更新された少なくとも1つの重みに基づいて、前記構築された動きベクトル候補リスト内の前記動きベクトル候補の順序をソートすることと
を行うようにさらに構成される、請求項15に記載の装置。
【請求項19】
前記構築された動きベクトル候補リスト内の前記動きベクトル候補の前記順序をソートするために、前記1つまたは複数のプロセッサは、重みのより高い値に対応する第1の動き情報を前記構築された動きベクトル候補リスト中の重みのより低い値に対応する第2の動き情報の前に配置する
ようにさらに構成される、請求項18に記載の装置。
【請求項20】
前記1つまたは複数のプロセッサは、前記現在ブロックに隣接するピクセルの数に基づいて、前記複数の重みの各々を決定するようにさらに構成される、請求項15に記載の装置。
【請求項21】
前記インター予測モードは、マージモードに対応する、請求項15に記載の装置。
【請求項22】
命令を記憶する非一時的コンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータを復号するように構成された1つまたは複数のプロセッサに、
インター予測モードで符号化されたビデオデータの現在ブロックを受信することと、
複数の隣接ブロックのうちの任意の隣接ブロックが動き情報を含むかどうかを決定するために、前記現在ブロックに対する前記複数の隣接ブロックを分析することと、ここにおいて、前記複数の隣接ブロックのうちで分析される前記隣接ブロックの数は、5よりも大きい、
複数の重みを決定することと、ここにおいて、前記複数の重みのうちの各重みは、動き情報を含む、前記複数の隣接ブロックのうちの隣接ブロックのセット内に含まれた動き情報にそれぞれ対応する、
ビデオデータの前記現在ブロックに対する前記隣接ブロックのセットからの前記動き情報に基づいて、前記現在ブロックのための動きベクトル候補リストを構築することと、
前記複数の重みに基づいて、ビデオデータの前記現在ブロックのための前記構築された動きベクトル候補リスト内の動きベクトル候補を適応的に順序付けることと、
前記動きベクトル候補リスト内の前記動きベクトル候補から現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行わせる、非一時的コンピュータ可読記憶媒体。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0308
【補正方法】変更
【補正の内容】
【0308】
[0239]様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビデオデータを復号する方法であって、前記方法は、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を備える、方法。
[C2]
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
をさらに備える、C1に記載の方法。
[C3]
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けること
をさらに備える、C2に記載の方法。
[C4]
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定すること
をさらに備える、C2に記載の方法。
[C5]
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
をさらに備える、C2に記載の方法。
[C6]
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
をさらに備える、C2に記載の方法。
[C7]
1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにATMVP候補を追加すること
をさらに備える、C2に記載の方法。
[C8]
1つまたは複数のATMVP候補のための動きベクトルの前記関数に基づいて、前記ATMVP候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、C7に記載の方法。
[C9]
2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
をさらに備える、C2に記載の方法。
[C10]
1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定すること
をさらに備える、C9に記載の方法。
[C11]
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングすること
をさらに備える、C2に記載の方法。
[C12]
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付けること
をさらに備える、C2に記載の方法。
[C13]
ビデオデータを復号するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
マージモードで符号化されたビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行うように構成された、装置。
[C14]
前記1つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、C13に記載の装置。
[C15]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、C14に記載の装置。
[C16]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、C14に記載の装置。
[C17]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、C14に記載の装置。
[C18]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付けることと、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記動きベクトル候補リスト中の所定のロケーションにおいて、前記決定された固定数の空間マージ候補を挿入することと
を行うようにさらに構成された、C14に記載の装置。
[C19]
前記1つまたは複数のプロセッサが、
1つまたは複数の高度時間動きベクトル予測(ATMVP)候補のための動きベクトルの関数に基づいて、前記動きベクトル候補リストにATMVP候補を追加する
ようにさらに構成された、C14に記載の装置。
[C20]
前記1つまたは複数のプロセッサが、
1つまたは複数のATMVP候補のための動きベクトルの前記関数に基づいて、前記ATMVP候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、C19に記載の装置。
[C21]
前記1つまたは複数のプロセッサが、
2つの双方向動きベクトル候補からの動きベクトル情報を組み合わせることによって、組合せ動きベクトル候補を決定することと、
前記動きベクトル候補リストに前記組合せ動きベクトル候補を追加することと
を行うようにさらに構成された、C14に記載の装置。
[C22]
前記1つまたは複数のプロセッサが、
1つまたは複数の組合せ動きベクトル候補のための動きベクトルの関数に基づいて、前記組合せ動きベクトル候補を追加するための、前記動きベクトル候補リスト中のロケーションを決定する
ようにさらに構成された、C14に記載の装置。
[C23]
前記1つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の前記動きベクトル候補の動きベクトル差分情報に基づいて、前記動きベクトル候補リストをプルーニングする
ようにさらに構成された、C14に記載の装置。
[C24]
前記1つまたは複数のプロセッサが、
前記動きベクトル候補リスト中の双方向候補の動きベクトル差分情報に基づいて、前記双方向候補を順序付ける
ようにさらに構成された、C14に記載の装置。
[C25]
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、ビデオデータを復号するように構成された1つまたは複数のプロセッサに、
マージモードで符号化されたビデオデータの現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを復号することと
を行わせる、コンピュータ可読記憶媒体。
[C26]
ビデオデータを符号化するように構成された装置であって、前記装置が、
ビデオデータの現在ブロックを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
ビデオデータの前記現在ブロックを受信することと、
ビデオデータの前記現在ブロックに対するある数の隣接ブロックからの動き情報に基づいて、前記現在ブロックのためのマージ候補の動きベクトル候補リストを構築することと、ここにおいて、前記動きベクトル候補リストのために考慮される隣接ブロックの前記数が前記現在ブロックのサイズに基づき、ここにおいて、隣接ブロックの前記数が5よりも大きい、
前記動きベクトル候補リストから現在動きベクトルを決定することと、
前記現在動きベクトルを使用してビデオデータの前記現在ブロックを符号化することと
を行うように構成された、装置。
[C27]
前記1つまたは複数のプロセッサが、
前記隣接ブロックのための動きベクトル情報のヒストグラムを導出することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リストを構築することと
を行うようにさらに構成された、C26に記載の装置。
[C28]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補を順序付ける
ようにさらに構成された、C27に記載の装置。
[C29]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定する
ようにさらに構成された、C27に記載の装置。
[C30]
前記1つまたは複数のプロセッサが、
前記導出されたヒストグラムに基づいて、隣接ブロックの総数から、前記動きベクトル候補リストに追加すべき固定数の空間マージ候補を決定することと、
前記導出されたヒストグラムに基づいて、前記動きベクトル候補リスト中で、所定の固定サブセットの空間マージ候補と、前記決定された固定数の空間マージ候補とを順序付けることと
を行うようにさらに構成された、C27に記載の装置。
【外国語明細書】