Nothing Special   »   [go: up one dir, main page]

JP2022507683A - デコーダ側動きベクトル改良 - Google Patents

デコーダ側動きベクトル改良 Download PDF

Info

Publication number
JP2022507683A
JP2022507683A JP2021527074A JP2021527074A JP2022507683A JP 2022507683 A JP2022507683 A JP 2022507683A JP 2021527074 A JP2021527074 A JP 2021527074A JP 2021527074 A JP2021527074 A JP 2021527074A JP 2022507683 A JP2022507683 A JP 2022507683A
Authority
JP
Japan
Prior art keywords
block
motion vector
coding
dmvr
pixels
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021527074A
Other languages
English (en)
Other versions
JP7446297B2 (ja
JPWO2020113051A5 (ja
Inventor
チェン、チュン－チ
チェン、ウェイ－ジュン
フン、チャオ－ション
カルチェビチ、マルタ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2022507683A publication Critical patent/JP2022507683A/ja
Publication of JPWO2020113051A5 publication Critical patent/JPWO2020113051A5/ja
Application granted granted Critical
Publication of JP7446297B2 publication Critical patent/JP7446297B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/521—Processing of motion vectors for estimating the reliability of the determined motion vectors or motion vector field, e.g. for smoothing the motion vector field or for correcting motion vectors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/117—Filters, e.g. for pre-processing or post-processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H04N19/122—Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/127—Prioritisation of hardware or computational resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/523—Motion estimation or motion compensation with sub-pixel accuracy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/563—Motion estimation with padding, i.e. with filling of non-object values in an arbitrarily shaped picture block or region for estimation purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/573—Motion compensation with multiple frame prediction using two or more reference frames in a given prediction direction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/577—Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Discrete Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

ビデオエンコーダまたはビデオデコーダなどのビデオコーディングデバイスは、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さ、のうちの少なくとも１つを有すると決定し得、それに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定し得、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングし得る。ビデオコーディングデバイスは、ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定し得（ここにおいて、Ｎは８よりも大きい整数値である）、ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定することに応答して、次いで、ＤＭＶＲを使用して第２のブロックをコーディングすべきかどうかを決定し得る。【選択図】図１８

Description

優先権の主張
[0001]本出願は、２０１９年１１月２６日に出願された米国出願第１６／６９５，９０７号、および２０１８年１１月２７日に出願された米国仮出願第６２／７７１，９６０号の利益を主張し、その内容全体が参照により本明細書に組み込まれる。
[0002]本開示は、ビデオ符号化とビデオ復号とを含む、ビデオコーディングに関する。
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタルレコーディングデバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲーム機、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、幅広いデバイスの中に組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４、パート１０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格、ＩＴＵ－Ｔ Ｈ．２６５／高効率ビデオコーディング（ＨＥＶＣ）によって規定される規格、およびそのような規格の拡張において記載されるものなどの、ビデオコーディング技法を実施する。ビデオデバイスは、そのようなビデオコーディング技法を実施することによって、より効率的にデジタルビデオ情報を送信、受信、符号化、復号、および／または記憶し得る。
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオピクチャまたはビデオピクチャの一部分）は、コーディングツリーユニット（ＣＴＵ：coding tree unit）、コーディングユニット（ＣＵ：coding unit）、および／またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライスの中のビデオブロックは、同じピクチャの中の隣接ブロックの中の参照サンプルを基準にした空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライスの中のビデオブロックは、同じピクチャの中の隣接ブロックの中の参照サンプルを基準にした空間予測、または他の参照ピクチャの中の参照サンプルを基準にした時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
[0005]概して、本開示は、デコーダ側動きベクトル改良（ＤＭＶＲ：decoder-side motion vector refinement）を改善するための技法を説明する。それは、ＨＥＶＣ（高効率ビデオコーディング：High Efficiency Video Coding）もしくはＶＶＣ（多用途ビデオコーディング：Versatile Video Coding）などの既存のビデオコーデックのうちのいずれかに適用されてよく、またはいかなる将来のビデオコーディング規格においても効率的なコーディングツールであり得る。たとえば、ビデオエンコーダおよびビデオデコーダなどのビデオコーディングデバイスは、ＤＭＶＲをその上で実行すべきブロックサイズにおける制約を伴って構成されることがある。詳細には、ブロックが、８ピクセルよりも小さい幅もしくは高さ、または８×８ピクセルに等しいサイズを有する場合、ＤＭＶＲは回避されてよい。そうでない場合、少なくとも８×ＮまたはＮ×８というサイズを有するブロックに対して（ただし、Ｎは８よりも大きい整数である）、ＤＭＶＲは実行され得る。
[0006]一例では、ビデオデータをコーディングする方法は、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を含む。
[0007]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を行うように構成される。
[0008]別の例では、コンピュータ可読記憶媒体は命令を記憶し、該命令は、実行されたとき、プロセッサに、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を行わせる。
[0009]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定するための手段と、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定するための手段と、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングするための手段と、を含む。
[0010]１つまたは複数の例の詳細が、添付図面および以下の説明において記載される。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかとなろう。
[0011]動きベクトル予測のための空間的な隣接候補を示す概念図。 動きベクトル予測のための空間的な隣接候補を示す概念図。 [0012]時間的な動きベクトル予測を示す概念図。 時間的な動きベクトル予測を示す概念図。 [0013]マージ動きベクトル改良を表す概念図。 マージ動きベクトル改良を表す概念図。 [0014]オフセットマージ候補の例を示す概念図。 [0015]双方向テンプレートマッチングの一例を示す概念図。 双方向テンプレートマッチングの一例を示す概念図。 [0016]デコーダ側動きベクトル導出（ＤＭＶＤ：decoder-side motion vector derivation）のためのステージの例示的なパイプラインを示す概念図。 [0017]双方向オプティカルフロー（ＢＩＯ：bi-directional optical flow）のための例示的なオプティカルフロー軌跡を示す概念図。 [0018]８×４ブロックに対するＢＩＯの間の勾配計算の一例を示す概念図。 [0019]本開示の技法を実行し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0020]改良された動きベクトルを使用してＢＩＯを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図。 改良された動きベクトルを使用してＢＩＯを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図。 [0021]コーディングツリーユニット（ＣＴＵ）を横断する仮想パイプラインデータユニット（ＶＰＤＵ：virtual pipeline data unit）の例示的な処理順序を示す概念図。 [0022]水平補間に対して水平パディングしか使用されない技法を示す概念図。 [0023]例示的な４分木２分木（ＱＴＢＴ：quadtree binary tree）構造と、対応するコーディングツリーユニット（ＣＴＵ）とを示す概念図。 例示的な４分木２分木（ＱＴＢＴ）構造と、対応するコーディングツリーユニット（ＣＴＵ）とを示す概念図。 [0024]本開示の技法を実行し得る例示的なビデオエンコーダを示すブロック図。 [0025]本開示の技法を実行し得る例示的なビデオデコーダを示すブロック図。 [0026]本開示の技法による、現在ブロックを符号化する例示的な方法を示すフローチャート。 [0027]本開示の技法による、現在ブロックを復号する例示的な方法を示すフローチャート。 [0028]本開示の技法による、ビデオデータのブロックをコーディングする方法の一例を示すフローチャート。
[0029]ビデオコーディング規格は、そのスケーラブルビデオコーディング（ＳＶＣ：Scalable Video Coding）とマルチビュービデオコーディング（ＭＶＣ：Multi-view Video Coding）拡張とを含む、ＩＴＵ－Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ－１ビジュアルと、ＩＴＵ－Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ－２ビジュアルと、ＩＴＵ－Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ビジュアルと、ＩＴＵ－Ｔ Ｈ．２６４（ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ ＡＶＣとも呼ばれる）と、を含む。
[0030]加えて、その範囲拡張と、マルチビュー拡張（ＭＶ－ＨＥＶＣ）と、スケーラブル拡張（ＳＨＶＣ）とを含む、高効率ビデオコーディング（ＨＥＶＣ）またはＩＴＵ－Ｔ Ｈ．２６５が、ビデオコーディング共同研究部会（ＪＣＴ－ＶＣ）ならびにＩＴＵ－Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）との３Ｄビデオコーディング拡張開発共同研究部会（ＪＣＴ－３Ｖ）によって開発されている。以下でＨＥＶＣ ＷＤと呼ばれるＨＥＶＣドラフト仕様は、ｐｈｅｎｉｘ．ｉｎｔ－ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ－Ｎ１００３－ｖ１．ｚｉｐから入手可能である。
[0031]ＩＴＵ－Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）は、（スクリーンコンテンツコーディングおよび高ダイナミックレンジコーディングのためのその現在の拡張と短期での拡張とを含む）現在のＨＥＶＣ規格の圧縮能力を著しく上回る圧縮能力を有する将来のビデオコーディング技術の標準化に対する潜在的なニーズを現在研究している。そのグループは、このエリアにおけるそれらの専門家によって提案された圧縮技術設計を評価するために、共同ビデオ探求部会（ＪＶＥＴ：Joint Video Exploration Team）と呼ばれる共同探求作業においてこの探求活動に関して協働している。ＪＶＥＴは、最初に２０１５年１０月１９日～２１日の間に開かれた。あるバージョンの参照ソフトウェア、すなわち、共同探求モデル７（ＪＥＭ７：Joint Exploration Model 7）は、ｊｖｅｔ．ｈｈｉ．ｆｒａｕｎｈｏｆｅｒ．ｄｅ／ｓｖｎ／ｓｖｎ＿ＨＭＪＥＭＳｏｆｔｗａｒｅ／ｔａｇｓ／ＨＭ－１６．６－ＪＥＭ－７．０／からダウンロードされ得る。ＪＥＭ７のアルゴリズム説明は、ｐｈｅｎｉｘ．ｉｔ－ｓｕｄｐａｒｉｓ．ｅｕ／ｊｖｅｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝３２８６から入手可能である。
[0032]ＨＥＶＣでは、スライスの中の最大のコーディングユニットは、コーディングツリーブロック（ＣＴＢ：coding tree block）またはコーディングツリーユニット（ＣＴＵ）と呼ばれる。ＣＴＢは、そのノードがコーディングユニットである４分木を含む。ＣＴＢのサイズは、ＨＥＶＣメインプロファイルにおいて１６×１６から６４×６４までにわたることができる（ただし、技術的に８×８のＣＴＢサイズがサポートされ得る）。コーディングユニット（ＣＵ）は、８×８くらいまで小さい同じサイズのＣＴＢであり得る。各コーディングユニットは、１つのモード、すなわち、インターモードまたはイントラモードを用いてコーディングされる。ＣＵは、インターコーディングされるとき、２つもしくは４つの予測ユニット（ＰＵ：prediction unit）にさらに区分されてよく、またはさらなる区分が適用されないとき、たった１つのＰＵになってもよい。１つのＣＵの中に２つのＰＵが存在するとき、それらは半分のサイズの長方形、またはＣＵの１／４もしくは３／４のサイズを有する２つの長方形サイズであり得る。ＣＵがインターコーディングされるとき、各ＰＵは、固有のインター予測モードとともに導出される、動き情報の１つのセットを有する。
[0033]ＨＥＶＣ規格では、予測ユニット（ＰＵ）に対して、それぞれ、マージモード（スキップはマージの特別な事例と見なされる）および高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）モードと称する、２つのインター予測モードがある。ＡＭＶＰモードまたはマージモードのいずれかにおいて、複数の動きベクトル予測子に対して動きベクトル（ＭＶ：motion vector）候補リストが保持される。現在ＰＵの、（１つまたは複数の）動きベクトル、ならびにマージモードにおける参照インデックスは、ＭＶ候補リストから１つの候補を取ることによって生成される。ＭＶ候補リストは、マージモード用の５つまでの候補と、ＡＭＶＰモード用の２つのみの候補とを含む。マージ候補は、動き情報のセット、たとえば、両方の参照ピクチャリスト（リスト０およびリスト１）に対応する動きベクトルと、参照インデックスとを含み得る。マージインデックスによってマージ候補が識別される場合、現在ブロックの予測のために使用される参照ピクチャならびに関連する動きベクトルが決定される。一方、ＡＭＶＰモードの下では、リスト０またはリスト１のいずれかからの各可能な予測方向について、ＡＭＶＰ候補が１つの動きベクトルしか含まないので、ＭＶ候補リストへのＭＶ予測子（ＭＶＰ：MV predictor）インデックスと一緒に、参照インデックスが明示的にシグナリングされる必要がある。ＡＭＶＰモードでは、予測される動きベクトルがさらに改良され得る。両方のモードのための候補は、同じ空間的および時間的な隣接ブロックから同様に導出される。
[0034]図１Ａおよび図１Ｂは、動きベクトル予測のための空間的な隣接候補を示す概念図である。詳細には、図１Ａは、マージモードのための空間的な隣接候補の例を示し、図１Ｂは、高度動きベクトル予測（ＡＭＶＰ）モードのための空間的な隣接候補の例を示す。特定のＰＵ（ＰＵ０）に対して、図１Ａおよび図１Ｂに示す隣接ブロックから空間的なＭＶ候補が導出されるが、ブロックから候補を生成するための方法は、マージモードおよびＡＭＶＰモードに対して異なる。ＨＥＶＣのマージモードでは、４つまでの空間的なＭＶ候補が、図１Ａに番号で示される順序で導出され得、その順序は、以下の通り、すなわち、左（０，Ａ１）、上（１，Ｂ１）、右上（２，Ｂ０）、左下（３，Ａ０）、および左上（４，Ｂ２）である。
[0035]ＡＶＭＰモードでは、隣接ブロックは、図１Ｂに示すように、２つのグループ、すなわち、ブロック０と１とを含む左グループ、およびブロック２と３と４とを含む上グループに分割される。各グループについて、シグナリングされる参照インデックスによって示されるのと同じ参照ピクチャを参照する、隣接ブロックの中の可能な候補が、グループの最終候補を形成するために選ばれるべき最高の優先度を有する。すべての隣接ブロックが、同じ参照ピクチャを指し示す動きベクトルを含むとは限らない可能性がある。したがって、そのような候補が見つけられ得ない場合、最初の利用可能な候補は最終候補を形成するようにスケーリングされ、したがって、時間距離差分が補償され得る。
[0036]図２Ａおよび図２Ｂは、時間的な動きベクトル予測を示す概念図である。詳細には、図２Ａは、時間動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）候補を示し、図２Ｂは、動きベクトルスケーリングを示す。ＴＭＶＰ候補は、イネーブルにされ利用可能な場合、ＨＥＶＣにおける空間的な動きベクトル候補の後にＭＶ候補リストの中へ追加され得る。ＴＭＶＰ候補に対する動きベクトル導出のプロセスは、マージモードとＡＭＶＰモードの両方に対して同じである。ただし、マージモードにおけるＴＭＶＰ候補に対するターゲット参照インデックスは、ＨＥＶＣごとに常に０に設定される。
[0037]ＴＭＶＰ候補導出のための主要なブロックロケーションは、空間的な隣接候補を生成するために使用される上および左のブロックへのバイアスを補償するために、ブロック「Ｔ」として図２Ａに示すような、コロケートＰＵの外部の右下のブロックである。しかしながら、そのブロックが現在ＣＴＢ行の外部に位置するか、または動き情報が利用可能でない場合、ブロックはＰＵの中心ブロックで置換されてよい。
[0038]ＴＭＶＰ候補に対する動きベクトルは、スライスレベルにおいて示される、コロケートピクチャのコロケートＰＵから導出され得る。コロケートＰＵに対する動きベクトルは、コロケートＭＶと呼ばれる。ＡＶＣにおける時間ダイレクトモードと同様に、ＴＭＶＰ候補動きベクトルを導出するために、コロケートＭＶは、図２Ｂに示すように、時間距離差分を補償するためにスケーリングされる必要があり得る。
[0039]図３Ａおよび図３Ｂは、マージ動きベクトル改良を表す概念図である。ＪＶＥＴ－Ｌ００５４では、シグナリングされる動きベクトル差分に基づいてマージ候補の動きベクトルを改良するために、マージ動きベクトル改良（ＭＭＶＲ、最終動きベクトル表現、ＵＭＶＥとも呼ばれる）が提示される。ＭＭＶＲは、開始ポイントと、動きの大きさと、動き方向とを含む、簡略化されたシグナリングを用いて、代替の動きベクトル表現を提供する。マージ動きは、未改良のマージ動きベクトルによって指し示されるロケーションを中心とする十字形パターン上の、図３Ｂにおける図示のオフセットのうちの１つを使用して改良され得る。加えて、リストＬ０の中の参照ピクチャを指し示すＭＶオフセット（すなわち、改良されたＭＶ－元のＭＶ）は、リストＬ１の中の参照ピクチャにスケーリングされる。
[0040]図４は、オフセットマージ候補の例を示す概念図である。ＪＶＥＴ－Ｌ０１７６では、新たな拡張されたＭＶオフセット候補が、マージ候補リストの第１の候補に基づいて構成される。新たな拡張されたＭＶオフセット候補は、第１の候補の現在ＭＶへのＭＶオフセットしか有さず、他の予測情報は第１の候補と同じである。新たに追加される候補は、時間的な候補の後にマージ候補リストへ押し込まれる。サポートされる動きベクトルオフセットが図４に示され、オフセット（０または±１，０または±１）を伴う水平および垂直の影付き点と、オフセット（０または±２，０または±２）を伴う対角の影付き点とを含む。
[0041]過去における参照ピクチャからの１つのＭＶ（すなわち、ＭＶ０）および未来の事例における参照ピクチャからの別のＭＶ（すなわち、ＭＶ１）を用いた双予測の場合、ビデオコーダは、選択されたＭＶオフセットを第１の候補ＭＶ０に加え、逆のＭＶオフセットを第１の候補ＭＶ１に加え得る。他の双予測事例では、ビデオコーダは、同じＭＶオフセットを、それぞれ、第１の候補ＭＶ０およびＭＶ１に加え得る。
[0042]履歴ベース動きベクトル予測（ＨＭＶＰ：history-based motion vector prediction）（ＪＶＥＴ－Ｋ０１０４において記載される）とは、各ブロックが、すぐ隣り合う因果的隣接動きフィールドの中のＭＶに加えて、過去から復号されたＭＶのリストから、そのＭＶ予測子を見つけることを可能にする、履歴ベースの方法である。符号化／復号プロセスの間、複数のＨＭＶＰ候補を有するテーブルが保持される。新たなスライスに遭遇すると、テーブルは空にされる。インターコード化ブロックがあるときはいつでも、関連する動き情報は、新たなＨＭＶＰ候補として先入れ先出し（ＦＩＦＯ）方式でテーブルに挿入される。次いで、制約付きＦＩＦＯ規則が適用され得る。テーブルにＨＭＶＰを挿入するとき、テーブルの中に同一のＨＭＶＰがあるかどうかを見つけるために、最初に冗長性チェックが適用される。見つかった場合、その特定のＨＭＶＰがテーブルから除去され、以後のすべてのＨＭＶＰ候補は移動される。
[0043]ＨＭＶＰ候補は、マージ候補リスト構成プロセスにおいて使用され得る。テーブルの中の最後のエントリから最初のエントリまでのすべてのＨＭＶＰ候補が、ＴＭＶＰ候補の後に挿入される。ＨＭＶＰ候補に対してプルーニングが適用される。利用可能なマージ候補の総数が、シグナリングされた最大許容マージ候補に到達すると、マージ候補リスト構成プロセスは終了する。
[0044]同様に、ＨＭＶＰ候補は、ＡＭＶＰ候補リスト構成プロセスにおいても使用され得る。テーブルの中の最後のＫ個のＨＭＶＰ候補の動きベクトルは、ＴＭＶＰ候補の後に挿入される。ＡＭＶＰターゲット参照ピクチャと同じ参照ピクチャを有するＨＭＶＰ候補だけが、ＡＭＶＰ候補リストを構成するために使用される。ＨＭＶＰ候補に対してプルーニングが適用される。
[0045]マージモードおよび／またはＡＭＶＰモードの間、動きベクトルスケーリングが実行され得る。動きベクトルの値がプレゼンテーション時間におけるピクチャの距離に比例することが想定される。動きベクトルは、２つのピクチャ、すなわち、参照ピクチャと、動きベクトルを含むピクチャ（すなわち、含有（containing）ピクチャ）とを関連付ける。ある動きベクトルが、他の動きベクトルを予測するために利用されるとき、含有ピクチャと参照ピクチャとの距離は、ピクチャ順序カウント（ＰＯＣ：Picture Order Count）値に基づいて計算される。
[0046]予測されるべき動きベクトルにとって、その関連する含有ピクチャおよび参照ピクチャは異なってよい。したがって、（ＰＯＣに基づく）新たな距離が計算され得る。そして、動きベクトルは、これらの２つのＰＯＣ距離に基づいてスケーリングされ得る。空間的な隣接候補にとって、２つの動きベクトルに対する含有ピクチャは同じであるが、参照ピクチャは異なる。ＨＥＶＣでは、空間的および時間的な隣接候補に対してＴＭＶＰとＡＭＶＰの両方に動きベクトルスケーリングが適用される。
[0047]マージモードおよび／またはＡＭＶＰモードの間、擬似（artificial）動きベクトル候補生成も実行され得る。動きベクトル候補リストが完全でない場合、擬似動きベクトル候補が生成され得、リストが所定の個数の候補を有するまでリストの末尾に挿入され得る。
[0048]ＨＥＶＣのマージモードでは、２つのタイプの擬似ＭＶ候補、すなわち、Ｂスライスのみに対して導出される組合せ候補と、第１のタイプが十分な擬似候補を提供しない場合、ＡＭＶＰのみに対して使用されるゼロ候補がある。すでに候補リストの中にあり必要な動き情報を有する候補の各ペアについて、双方向組合せ動きベクトル候補が、リスト０の中のピクチャを参照する第１の候補の動きベクトルと、リスト１の中のピクチャを参照する第２の候補の動きベクトルとの組合せによって導出される。
[0049]候補挿入のためのプルーニングプロセスは、ＨＥＶＣのマージモードおよび／またはＡＭＶＰモードの間に実行され得る。異なるブロックからの候補がたまたま同じである場合があり、そのことはマージ／ＡＭＶＰ候補リストの効率を下げることがある。プルーニングプロセスは、この問題を解決するために適用され得る。このプロセスは、同一の候補を挿入することをある程度まで回避するために、現在の候補リストの中で、ある候補を他の候補に対して比較する。計算量を低減するために、可能な各候補をすべての他の既存の候補と比較するのではなく、限られた数のプルーニングプロセスしか適用されない。
[0050]図５Ａおよび図５Ｂは、双方向テンプレートマッチングの一例を示す概念図である。双方向マッチングは、テンプレートベースの改良プロセスを回避し得る、ＤＭＶＲ技法の変形形態である。この技法は、初期双予測ＭＶ（たとえば、図５Ａおよび図５Ｂの中のｖ0およびｖ1）によって指し示される単予測参照ブロック（Ｉ0（ｘ＋ｖ0）およびＩ1（ｘ＋ｖ1）、ならびに現在ブロック内のピクセルの座標としてのｘとして示す）の間で双方向マッチングコストを直接算出する。初期双予測ＭＶの周囲の事前定義された探索範囲内での双方向マッチングに基づいて、局所的な探索が実行される。詳細には、初期ＭＶが、最初の探索反復においてｖ0 (0)およびｖ1 (0)、いくつかのＭＶペア（たとえば、ｖ0 (0)＋Δおよびｖ1 (0)－Δ、ただし、Δ∈（０，０），（－１，１），（０，１），（１，１），（１，０），（１，－１），（０，－１），（－１，－１），（－１，０）など｝である）と仮定すると、最小の双方向マッチングコストをもたらすことができる最適なΔ＊を見つけ出す。この案では、コスト関数は、Ｉ0（ｘ＋ｖ0 (0)＋Δ）とＩ1（ｘ＋ｖ1 (0)－Δ）との間のひずみ＋動きコストとして定義される。ひずみ関数は、絶対差分和（ＳＡＤ：sum of absolute difference）または平均除去ＳＡＤ（ＭＲＳＡＤ：Mean Removed SAD）のいずれかであり得る。
[0051]最適なΔ＊が見つけられた後、反復プロセスは、Δ＊を使用することによって初期ＭＶ（ｖ0 (0)およびｖ1 (0)）を更新する。詳細には、我々は、ｖ0 (1)＝ｖ0 (0)＋Δ＊と、ｖ1 (1)＝ｖ1 (0)－Δ＊）とを有する。次いで、上の説明におけるすべての上付き文字を１だけ進めた後、Δ＊が（０，０）に等しいことが到達されるまで、同じ反復プロセスが繰り返す。出力ＭＶペア（ｖ0 (n)およびｖ1 (n)として示し、ｎ≧１である）が、次いで、サブペル精度で再び改良され得る。得られるＭＶペアは、次いで、マージブロックの元のＭＶ（ｖ0 (0)およびｖ1 (0)）を置き換えるために使われる。最後に、改良されたＭＶ（たとえば、図５Ｂの中のｖ0’およびｖ1’）に基づいて動き補償が実行される。
[0052]ＪＶＥＴ－Ｋ００４１では、可能な分数ペルＭＶごとに予測誤差曲面（prediction error surface）を形成するために、２次パラメトリック関数が使用される。基本的に、それは推定量としての予測誤差の値を補間する補間関数である。整数探索からの厳密な予測誤差値に基づいて、２次パラメトリック関数のパラメータが導出され、したがって、この誤差探索における最良の動きサンプリングロケーションが見つけられ得る。次いで、実際にサブペル動きベクトル推定を実行する代わりに、元の（original）ＭＶがこの厳密な動きサンプリングロケーションに調整される。このパラメトリック関数は、誤差曲面を形成しこの面上で最小コスト値を有する最良の位置を見つけるための参照として５つの点からコスト値を取る。５つの点は十字形を形成し、隣り合う２つの各点の間のギャップは２ピクセルであり、ここで、中心／左／右／上／下の点は、（０，０）／（－１，０）／（１，０）／（０，－１）／（０，１）に合わせられる。
[0053]いくつかの例では、このパラメトリック誤差曲面関数は、２Ｄ放物線誤差曲面方程式、すなわち、
Figure 2022507683000002
であり、ここで、（Δｘ，Δｙ）は最小コストを有する位置に相当し、Ｃは最小コスト値に相当する。
[0054]５つの方程式を５つの未知数で解くことによって、（Δｘ，Δｙ）は、
Figure 2022507683000003
のように算出され得、ここで、αは（Δｘ，Δｙ）をいくつかのサブペル精度で表すために導入された整数スケーリング係数、たとえば、１／１６の精度に対して１６、および１／４の精度に対して４である。
[0055]動きオーバーヘッドを低減する際にＤＭＶＤは効率的であるが、（ＤＭＶＲなどの）既存のＤＭＶＤ設計は、空間的な隣接ＣＵのコーディングの間の相互依存性に起因する復号レイテンシ問題に遭遇することがある。ＣＵのＭＶが、ＤＭＶＲを使用することによってコーディングされたその空間的なネイバーから予測される場合、その復号プロセスは、隣接ＣＵの改良されたＭＶが利用可能になるまで待たなければならない。新たなコーディング規格、すなわち、多用途ビデオコーディングの開発において、いくつかのデコーダ側ＭＶ導出（ＤＭＶＤ）手法のための低レイテンシ設計を達成するための、本開示のいくつかの技法がある。
[0056]本開示の技法は、ＤＭＶＲおよびＤＭＶＤの性能を改善するために使用され得る。たとえば、ＤＭＶＲが適用されるブロックに、サイズ制約が課されることがある。詳細には、ＤＭＶＲは、８×８ピクセルよりも大きいサイズを有するブロックに制約されることがある。すなわち、ブロックの１つの寸法（ブロックの幅または高さ）が８ピクセルに等しい場合、ブロックに対してＤＭＶＲを実行するために、直交する寸法は８ピクセルよりも大きくなるべきである。このようにしてＤＭＶＲを制約することによって、ブロックコーディングプロセスは、ひずみに悪影響を及ぼすことなく改善され得る。
[0057]図６は、デコーダ側動きベクトル導出（ＤＭＶＤ）のためのステージの例示的なパイプラインを示す概念図である。ＤＭＶＤを使用してコーディングされるブロックに対して、復号プロセスは、３つのステップ、すなわち、（１）初期動きフィールドの再構成、および参照ブロックをプリフェッチすること、（２）最終ＭＶを得るための、ブロック動きに対する改良プロセス、ならびに（３）最終ＭＶを用いた動き補償、で解実行され得る。
[0058]ステップ２における改良プロセスの後、最終ＭＶがピクチャ動きフィールドに書き戻され、そのため、空間的なＭＶ予測、時間的なＭＶ予測、および境界強度計算に関して、改良されたＭＶが使用され得る。図６は、デコーダ側ＭＶ改良（ＤＭＶＲ）などのＤＭＶＤ方法のためのパイプラインステージのいくつかの実装形態を示す。図６において、３つの主要モジュールが、ＤＭＶＤ方法のための３つの復号ステップを表す。
[0059]第１に、ＣＵprevは、現在のＣＵ（ＣＵcur）の前の、以前にコーディングされたＣＵである。ＣＵcurのオリジナルの（元の）ＭＶを再構成するとき、ＭＶ予測子が、たまたまＤＭＶＤコード化ブロックであるＣＵprevからである場合、この予測子は、ＣＵcurにとって利用不可能としてマークされる。したがって、ＣＵcurの初期ＭＶの再構成は、もはやＣＵprevの改良されたＭＶに依存せず、ＭＶ改良とＭＶ予測との間の相互依存性は、ある程度まで除去される。
[0060]改良されたＭＶを使用するのではなく、いくつかの例では、各ＤＭＶＲ ＣＵのオリジナルのＭＶが、空間的なＭＶ予測子を導出するために使用され得る。時間的なＭＶ予測の場合、コロケートピクチャが完全に再構成されているので、改良されたＭＶは復号レイテンシ問題を伴わずに使用され得る。したがって、空間的な隣接ＣＵの間のコーディング依存性がもはや存在しないので、ＤＭＶＲの復号レイテンシ問題は完全に解決され得る。しかしながら、コーディングパフォーマンスの減退が予想され得る。
[0061]いくつかの例では、現在ブロックと一緒にこれらの隣接ブロックがすべて同じＣＴＵ行の中に落ちる場合、空間的なＭＶ予測を実行するために、直接隣接するブロックからの参照として、未改良のＭＶが使用され得る。（いくつかの他の技法が、そのような隣接ブロックからのＭＶ予測子に、利用不可能としてマークする場合があることに留意されたい）。反対に、それらの関連するブロックが、すぐ上のＣＴＵおよび左上のＣＴＵに位置する隣接する因果的ＣＴＵ内に落ちるときのみ、改良されたＭＶは、空間的なＭＶ予測に対して利用可能であり得る。したがって、いくつかの例は、ＣＴＵ行の内側で、ＭＶ改良と空間的なＭＶ予測との間の相互依存性を壊す。
[0062]図７は、双方向オプティカルフロー（ＢＩＯ）のための例示的なオプティカルフロー軌跡を示す概念図である。ＢＩＯとは、双予測の事例においてブロック単位の動き補償の上部で実行される、ピクセル単位の動き改良である。ＢＩＯがブロックの内側の細かい動きを補償するので、ＢＩＯをイネーブルにすることは、動き補償に対するブロックサイズを大きくするという結果になり得る。サンプルレベル動き改良は、サンプルごとに細かい動きベクトルを与える明示方程式があるので、網羅的な探索またはシグナリングを必要としない。
[0063]補償ブロック動きの後の参照ｋ（ｋ＝０，１）からのルミナンス値をＩ(k)とすると、∂Ｉ(k)／∂ｘ、∂Ｉ(k)／∂ｙは、それぞれ、Ｉ(k)勾配の水平成分および垂直成分である。オプティカルフローが有効であると想定すると、動きベクトルフィールド（ｖx，ｖy）は、式
Figure 2022507683000004
によって与えられる。
[0064]オプティカルフロー方程式を各サンプルの動き軌跡に対するエルミート補間と組み合わせると、関数値Ｉ(k)と導関数∂Ｉ(k)／∂ｘ、∂Ｉ(k)／∂ｙの両方に整合する、３次の一意多項式が最後に得られる。ｔ＝０におけるこの多項式の値は、ＢＩＯ予測、すなわち、
Figure 2022507683000005
である。
[0065]ここで、τ0およびτ1は、図７に示すように参照フレームまでの距離を示す。距離τ0およびτ1は、Ｒｅｆ０およびＲｅｆ１に対するＰＯＣに基づいて計算され、すなわち、τ0＝ＰＯＣ（現在）－ＰＯＣ（Ｒｅｆ０）、τ1＝ＰＯＣ（Ｒｅｆ１）－ＰＯＣ（現在）である。両方の予測が同じ時間方向から（両方が過去から、または両方が未来から）来る場合、符号は異なり、τ0・τ1＜０である。この場合、予測が同じ時間モーメントから来るのではなく（τ０≠τ１）、参照される両方の領域が非０の動きを有し（ＭＶｘ0、ＭＶｙ0、ＭＶｘ1、ＭＶｙ1≠０）、ブロック動きベクトルが時間距離に比例する（ＭＶｘ0／ＭＶｘ1＝ＭＶｙ0／ＭＶｙ1＝－τ0／τ1）場合のみ、ＢＩＯが適用される。
[0066]点ＡおよびＢの値の間の差分Δ（図７の中の動き軌跡と参照フレーム平面との交差）を最小化することによって、動きベクトルフィールド（ｖx，ｖy）が決定される。例示的なモデルは、Δに対する局所的なテイラー展開の最初の線形項しか使用しない。
Figure 2022507683000006
[0067]（１）におけるすべての値は、ここまで省略されたサンプルロケーション（ｉ’，ｊ’）に依存する。局所的な周囲状況の中で動きが一致することを想定すると、我々は、現在予測される点（ｉ，ｊ）と中心とする（２Ｍ＋１）×（２Ｍ＋１）の正方形ウィンドウΩの内側でΔを最小化する。
Figure 2022507683000007
[0068]この最適化問題に対して、我々は、最初に垂直方向で、次いで水平方向で、最小化を行う、簡略化された解決策を使用する。そのことは、
Figure 2022507683000008
という結果になり、ここで、
Figure 2022507683000009
である。
[0069]０または極めて小さい値による除算を回避するために、正則化パラメータｒおよびｍが式（２）、式（３）の中に導入される。
Figure 2022507683000010
[0070]ここで、ｄは入力ビデオの内部ビット深度である。
[0071]場合によっては、ＢＩＯのＭＶ統治は、雑音または不規則な動きに起因して信頼できないことがある。したがって、ＢＩＯでは、ＭＶ統治の大きさは、いくつかのしきい値ｔｈＢＩＯにクリップされる。しきい値は、現在ピクチャのすべての参照ピクチャが、すべて１つの方向からであるかどうかに基づいて決定される。現在ピクチャの現在ピクチャのすべての参照ピクチャが１つの方向からである場合、しきい値の値は１２×２14-dに設定され、そうでない場合、１２×２13-dに設定される。
[0072]ＢＩＯに対する勾配は、ＨＥＶＣ動き補償プロセスと一致する演算を使用して動き補償補間と同時に計算される（２Ｄ分離可能ＦＩＲ）。この２Ｄ分離可能ＦＩＲのための入力は、動き補償プロセス用と同じ参照フレームサンプル、およびブロック動きベクトルの分数部分による分数位置（ｆｒａｃＸ，ｆｒａｃＹ）である。水平勾配∂Ｉ／∂ｘ信号の場合、最初に、デスケーリングシフトｄ－８を有する（with）分数位置ｆｒａｃＹに対応するＢＩＯｆｉｌｔｅｒＳを使用して垂直に補間され、次いで、勾配フィルタＢＩＯｆｉｌｔｅｒＧが、１８－ｄだけのデスケーリングシフトを有する分数位置ｆｒａｃＸに対応する水平方向において適用される。垂直勾配∂Ｉ／∂ｙの場合、最初に、勾配フィルタが、デスケーリングシフトｄ－８を有する分数位置ｆｒａｃＹに対応するＢＩＯｆｉｌｔｅｒＧを使用して垂直に適用され、次いで、信号変位が、１８－ｄだけのデスケーリングシフトを有する分数位置ｆｒａｃＸに対応する水平方向においてＢＩＯｆｉｌｔｅｒＳを使用して実行される。勾配計算のための補間フィルタＢＩＯｆｉｌｔｅｒＧおよび信号変位ＢＩＯｆｉｌｔｅｒＦの長さは、妥当な計算量を維持するためにもっと短い（６タップ）。
[0073]図８は、８×４ブロックに対するＢＩＯの間の勾配計算の一例を示す概念図である。８×４ブロックに対して、式（４）に示すように、各ピクセルについてｖｘとｖｙとを解くことが、各ピクセルを中心としたウィンドウΩ内のピクセルの動き補償された予測子、水平勾配値および垂直勾配値を必要とするので、ビデオコーダは、動き補償された予測子をフェッチし得、ブロック内のすべてのピクセルの水平勾配および垂直勾配、ならびにピクセルの外側の２つのラインを計算し得る。そしてＪＥＭでは、このウィンドウのサイズは５×５に設定される。したがって、ビデオコーダは、動き補償された予測子をフェッチし、ピクセルの外側の２つのラインに対する勾配を計算する必要がある。ＪＥＭでは、２つの予測が異なる参照ピクチャからであるとき、ＢＩＯはすべての双方向予測ブロックに適用される。ＣＵに対してＬＩＣがイネーブルにされているとき、ＢＩＯはディセーブルにされる。
[0074]一般化双予測（ＧＢｉ：generalized bi-prediction）がＪＶＥＴ－Ｃ００４７において提案された。ＪＶＥＴ－Ｋ０２４８は、ＧＢｉに対する利得計算量トレードオフを改善しＢＭＳ２．１の中に採択された。ＢＭＳ２．１ ＧＢｉは、双予測モードにおけるＬ０およびＬ１からの予測子に不均等な重みを適用する。インター予測モードでは、均等な重みペア（１／２，１／２）を含む複数の重みペアが、レートひずみ最適化（ＲＤＯ：rate-distortion optimization）に基づいて評価され、選択された重みペアのＧＢｉインデックスが、デコーダにシグナリングされる。マージモードでは、ＧＢｉインデックスは隣接ＣＵから継承される。ＢＭＳ２．１ ＧＢｉにおいて、双予測モードでの予測子生成が以下に示される。
Figure 2022507683000011
ここで、ＰGBiはＧＢｉの最終予測子である。ｗ0およびｗ1は選択されたＧＢｉ重みペアであり、それぞれ、リスト０（Ｌ０）およびリスト１（Ｌ１）の予測子に適用される。ＲｏｕｎｄｉｎｇＯｆｆｓｅｔGBiおよびｓｈｉｆｔＮｕｍGBiは、ＧＢｉにおける最終予測子を正規化するために使用される。サポートされるｗ１重みセットは、｛－１／４，３／８，１／２，５／８，５／４｝であり、５つの重みは１つの均等な重みペアおよび４つの不均等な重みペアに対応する。混合利得、すなわち、ｗ1とｗ0との合計は、１．０に固定される。したがって、対応するｗ０重みセットは、｛５／４，５／８，１／２，３／８，－１／４｝である。重みペア選択はＣＵレベルである。
[0075]非低遅延ピクチャの場合、重みセットサイズは５つから３つに低減され、ここで、ｗ1重みセットは｛３／８，１／２，５／８｝であり、ｗ0重みセットは｛５／８，１／２，３／８｝である。非低遅延ピクチャに対する重みセットサイズ低減は、ＢＭＳ２．１ ＧＢｉ、およびこの案におけるすべてのＧＢｉテストに適用される。
[0076]本開示は、ＤＭＶＤ関連の方法（ＰＭＭＶＤ、双方向テンプレートマッチング、デコーダ側ＭＶ改良など）が、著しいコーディング性能改善をもたらすことを認識する。これらの既存の技術のうちのいくつかは、デコーダ側ＭＶ導出プロセスと空間的なＭＶ予測との間で、相互依存性問題（復号レイテンシ問題とも呼ばれる）を部分的または完全に（コーディング効率を代償として）さらに解決している。また、ＤＭＶＲが、ＢＩＯ、履歴ベースマージ候補、およびアフィンマージ候補に関与するとき、多くの適用シナリオにおいても同じ復号レイテンシ問題が起こる。しかしながら、１）改良されたＭＶが、どのように使用され得るのか、および２）改良されたＭＶが、アクセス不可能なときにどのように置き換えられ得るのかに関して、いくつかの使用事例が指定されるべきである。その上、ＧＢｉ、重み付き双予測、ＭＭＶＲ、マージオフセット拡張、およびＤＭＶＲパディングプロセスの現在の設計は、ＤＭＶＲの大部分にメモリバッファサイズと計算量とを低減させるように改善され得る。本開示の技法は、これらおよび他の問題に対処し得、それによって、ビデオコーディング（符号化および／または復号）の技術分野を改善し、ビデオエンコーダおよびビデオデコーダなどの、ビデオコーディングを実行するデバイスも改善する。
[0077]図９は、本開示の技法を実行し得る例示的なビデオ符号化および復号システム１００を示すブロック図である。本開示の技法は、一般に、ビデオデータをコーディング（符号化および／または復号）することを対象とする。一般に、ビデオデータは、ビデオを処理するための任意のデータを含む。したがって、ビデオデータは、未加工のコーディングされていないビデオと、符号化されたビデオと、復号された（たとえば、再構成された）ビデオと、シグナリングデータなどのビデオメタデータとを含んでよい。
[0078]図９に示すように、システム１００は、この例では、宛先デバイス１１６によって復号および表示されるべき符号化ビデオデータを提供するソースデバイス１０２を含む。詳細には、ソースデバイス１０２は、コンピュータ可読媒体１１０を介してビデオデータを宛先デバイス１１６に提供する。ソースデバイス１０２および宛先デバイス１１６は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、スマートフォンなどの電話ハンドセット、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、幅広いデバイスのうちのいずれかを備えてよい。場合によっては、ソースデバイス１０２および宛先デバイス１１６は、ワイヤレス通信のために装備されてよく、したがって、ワイヤレス通信デバイスと呼ばれることがある。
[0079]図９の例では、ソースデバイス１０２は、ビデオソース１０４と、メモリ１０６と、ビデオエンコーダ２００と、出力インターフェース１０８とを含む。宛先デバイス１１６は、入力インターフェース１２２と、ビデオデコーダ３００と、メモリ１２０と、ディスプレイデバイス１１８とを含む。本開示によれば、ソースデバイス１０２のビデオエンコーダ２００および宛先デバイス１１６のビデオデコーダ３００は、ＤＭＶＲを改善するための技法を適用するように構成され得る。したがって、ソースデバイス１０２は、ビデオ符号化デバイスの一例を表し、宛先デバイス１１６は、ビデオ復号デバイスの一例を表す。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含んでよい。たとえば、ソースデバイス１０２は、外部カメラなどの外部ビデオソースからビデオデータを受信してよい。同様に、宛先デバイス１１６は、統合されたディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースしてよい。
[0080]図９に示すようなシステム１００は一例にすぎない。一般に、いかなるデジタルビデオ符号化および／または復号デバイスも、ＤＭＶＲを改善するための技法を実行し得る。ソースデバイス１０２および宛先デバイス１１６は、ソースデバイス１０２が宛先デバイス１１６への送信のためにコード化ビデオデータを生成する、そのようなコーディングデバイスの例にすぎない。本開示は、データのコーディング（符号化および／または復号）を実行するデバイスとして「コーディング」デバイスに言及する。したがって、ビデオエンコーダ２００およびビデオデコーダ３００は、コーディングデバイス、詳細には、それぞれ、ビデオエンコーダおよびビデオデコーダの例を表す。いくつかの例では、ソースデバイス１０２および宛先デバイス１１６は、ソースデバイス１０２および宛先デバイス１１６の各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、システム１００は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオ電話のために、ソースデバイス１０２と宛先デバイス１１６との間で１方向または２方向のビデオ送信をサポートし得る。
[0081]概して、ビデオソース１０４は、ビデオデータ（すなわち、未加工のコーディングされていないビデオデータ）のソースを表し、ビデオデータの連続した一連のピクチャ（「フレーム」とも呼ばれる）をビデオエンコーダ２００に提供し、ビデオエンコーダ２００はピクチャに対するデータを符号化する。ソースデバイス１０２のビデオソース１０４は、以前にキャプチャされた未加工のビデオを含むビデオカメラ、ビデオアーカイブなどのビデオキャプチャデバイス、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含んでよい。さらなる代替として、ビデオソース１０４は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。各場合において、ビデオエンコーダ２００は、キャプチャされた、事前キャプチャされた、またはコンピュータ生成されたビデオデータを符号化する。ビデオエンコーダ２００は、受信された順序（時々、「表示順序」と呼ばれる）からコーディング用のコーディング順序に、ピクチャを再配置し得る。ビデオエンコーダ２００は、符号化ビデオデータを含むビットストリームを生成し得る。ソースデバイス１０２は、次いで、たとえば、宛先デバイス１１６の入力インターフェース１２２による、受信および／または取出しのために、出力インターフェース１０８を介してコンピュータ可読媒体１１０上に符号化ビデオデータを出力し得る。
[0082]ソースデバイス１０２のメモリ１０６および宛先デバイス１１６のメモリ１２０は、汎用メモリを表す。いくつかの例では、メモリ１０６、１２０は、未加工のビデオデータ、たとえば、ビデオソース１０４からの未加工ビデオと、ビデオデコーダ３００からの未加工の復号されたビデオデータとを記憶し得る。追加または代替として、メモリ１０６、１２０は、たとえば、それぞれ、ビデオエンコーダ２００およびビデオデコーダ３００によって実行可能な、ソフトウェア命令を記憶し得る。メモリ１０６、１２０は、この例ではビデオエンコーダ２００およびビデオデコーダ３００から別個に示されるが、ビデオエンコーダ２００およびビデオデコーダ３００がまた、機能的に類似のまたは均等な目的のための内部メモリを含んでよいことを理解されたい。さらに、メモリ１０６、１２０は、符号化ビデオデータ、たとえば、ビデオエンコーダ２００からの出力と、ビデオデコーダ３００への入力とを記憶し得る。いくつかの例では、メモリ１０６、１２０の部分は、たとえば、未加工の復号ビデオデータおよび／または符号化ビデオデータを記憶するための、１つまたは複数のビデオバッファとして割り振られてよい。
[0083]コンピュータ可読媒体１１０は、ソースデバイス１０２から宛先デバイス１１６に符号化ビデオデータをトランスポートすることが可能な任意のタイプの媒体またはデバイスを表してよい。一例では、コンピュータ可読媒体１１０は、ソースデバイス１０２が、たとえば、無線周波数ネットワークまたはコンピュータベースネットワークを介して、符号化ビデオデータをリアルタイムで直接宛先デバイス１１６へ送信することを可能にするための、通信媒体を表す。出力インターフェース１０８は、符号化ビデオデータを含む送信信号を変調してよく、入力インターフェース１２２は、受信された送信信号をワイヤレス通信プロトコルなどの通信規格に従って復調してよい。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を備えてよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１０２から宛先デバイス１１６への通信を容易にするために有用であり得る任意の他の機器を含んでよい。
[0084]いくつかの例では、ソースデバイス１０２は、出力インターフェース１０８から記憶デバイス１１２に符号化データを出力し得る。同様に、宛先デバイス１１６は、入力インターフェース１２２を介して記憶デバイス１１２からの符号化データにアクセスし得る。記憶デバイス１１２は、ハードドライブ、Ｂｌｕ－ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含んでよい。
[0085]いくつかの例では、ソースデバイス１０２は、ソースデバイス１０２によって生成された符号化ビデオを記憶し得る、ファイルサーバ１１４または別の中間記憶デバイスに、符号化ビデオデータを出力し得る。宛先デバイス１１６は、ストリーミングまたはダウンロードを介してファイルサーバ１１４からの記憶されたビデオデータにアクセスし得る。ファイルサーバ１１４は、符号化ビデオデータを記憶することおよびその符号化ビデオデータを宛先デバイス１１６へ送信することが可能な、任意のタイプのサーバデバイスであってよい。ファイルサーバ１１４は、（たとえば、ウェブサイト用の）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、コンテンツ配信ネットワークデバイス、またはネットワーク接続ストレージ（ＮＡＳ）デバイスを表してよい。宛先デバイス１１６は、インターネット接続を含む任意の標準データ接続を通じて、ファイルサーバ１１４からの符号化ビデオデータにアクセスし得る。これは、ワイヤレスチャネル（たとえば、Ｗｉ－Ｆｉ（登録商標）接続）、有線接続（たとえば、デジタル加入者回線（ＤＳＬ）、ケーブルモデムなど）、またはファイルサーバ１１４上に記憶された符号化ビデオデータにアクセスするのに適したその両方の組合せを含んでよい。ファイルサーバ１１４および入力インターフェース１２２は、ストリーミング伝送プロトコル、ダウンロード伝送プロトコル、またはそれらの組合せに従って動作するように構成され得る。
[0086]出力インターフェース１０８および入力インターフェース１２２は、ワイヤレス送信機／受信機、モデム、有線ネットワーキング構成要素（たとえば、Ｅｔｈｅｒｎｅｔ（登録商標）カード）、様々なＩＥＥＥ８０２．１１規格のうちのいずれかに従って動作するワイヤレス通信構成要素、または他の物理構成要素を表してよい。出力インターフェース１０８および入力インターフェース１２２がワイヤレス構成要素を備える例では、出力インターフェース１０８および入力インターフェース１２２は、４Ｇ、４Ｇ－ＬＴＥ（登録商標）（ロングタームエボリューション）、ＬＴＥアドバンスト、５Ｇなどのセルラー通信規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。出力インターフェース１０８がワイヤレス送信機を備えるいくつかの例では、出力インターフェース１０８および入力インターフェース１２２は、ＩＥＥＥ８０２．１１仕様、ＩＥＥＥ８０２．１５仕様（たとえば、ＺｉｇＢｅｅ（登録商標））、Ｂｌｕｅｔｏｏｔｈ（登録商標）規格などの他のワイヤレス規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。いくつかの例では、ソースデバイス１０２および／または宛先デバイス１１６は、それぞれのシステムオンチップ（ＳｏＣ）デバイスを含んでよい。たとえば、ソースデバイス１０２は、ビデオエンコーダ２００および／または出力インターフェース１０８のものとされる機能性を実行するためのＳｏＣデバイスを含んでよく、宛先デバイス１１６は、ビデオデコーダ３００および／または入力インターフェース１２２のものとされる機能性を実行するためのＳｏＣデバイスを含んでよい。
[0087]本開示の技法は、オーバージエアテレビ放送、ケーブルテレビ送信、衛星テレビ送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア適用例のうちのいずれかのサポートにおけるビデオコーディングに適用され得る。
[0088]宛先デバイス１１６の入力インターフェース１２２は、コンピュータ可読媒体１１０（たとえば、通信媒体、記憶デバイス１１２、ファイルサーバ１１４など）から符号化ビデオビットストリームを受信する。符号化ビデオビットストリームは、ビデオブロックまたは他のコード化ユニット（たとえば、スライス、ピクチャ、ピクチャのグループ、シーケンスなど）の特性および／または処理を記述する値を有するシンタックス要素などの、ビデオデコーダ３００によっても使用される、ビデオエンコーダ２００によって規定されるシグナリング情報を含んでよい。ディスプレイデバイス１１８は、復号ビデオデータの復号ピクチャをユーザに表示する。ディスプレイデバイス１１８は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのうちのいずれかを表してよい。
[0089]図９に示さないが、いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は各々、オーディオエンコーダおよび／またはオーディオデコーダと統合されてよく、共通のデータストリームの中にオーディオとビデオの両方を含む多重化ストリームを処理するために、適切なＭＵＸ－ＤＥＭＵＸユニットまたは他のハードウェアおよび／もしくはソフトウェアを含んでよい。適用可能な場合、ＭＵＸ－ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。
[0090]ビデオエンコーダ２００およびビデオデコーダ３００は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な好適なエンコーダおよび／またはデコーダ回路構成のうちのいずれかとして実装され得る。技法が部分的にソフトウェアで実装されるとき、デバイスは、本開示の技法を実行するために、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体の中に記憶してよく、１つまたは複数のプロセッサを使用してハードウェアで命令を実行してよい。ビデオエンコーダ２００およびビデオデコーダ３００の各々は、１つまたは複数のエンコーダまたはデコーダの中に含まれてよく、それらのうちのいずれも、それぞれのデバイスの中で、組み合わせられたエンコーダ／デコーダ（コーデック）の一部として統合されてよい。ビデオエンコーダ２００および／またはビデオデコーダ３００を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備えてよい。
[0091]ビデオエンコーダ２００およびビデオデコーダ３００は、高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれるＩＴＵ－Ｔ Ｈ．２６５、またはマルチビューおよび／もしくはスケーラブルビデオコーディング拡張などのそれらの拡張などの、ビデオコーディング規格に従って動作し得る。代替として、ビデオエンコーダ２００およびビデオデコーダ３００は、共同探求テストモデル（ＪＥＭ）または多用途ビデオコーディング（ＶＶＣ：Versatile Video Coding）とも呼ばれるＩＴＵ－Ｔ Ｈ．２６６などの、他のプロプライエタリ規格または業界規格に従って動作し得る。ＶＶＣ規格の最近のドラフトは、Ｂｒｏｓｓら、「Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ （Ｄｒａｆｔ６）」、ＩＴＵ－Ｔ ＳＧ１６ ＷＰ３とＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１との共同ビデオエキスパート部会（ＪＶＥＴ）、第１５回会合、イェーテボリ、スウェーデン、２０１９年７月３日～１２日、ＪＶＥＴ－Ｏ２００１－ｖＥ（以下では「ＶＶＣドラフト６」）の中に記載されている。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。
[0092]概して、ビデオエンコーダ２００およびビデオデコーダ３００は、ピクチャのブロックベースコーディングを実行し得る。「ブロック」という用語は、概して、処理される（たとえば、符号化される、復号される、または符号化および／もしくは復号プロセスにおいて別のやり方で使用される）べきデータを含む構造を指す。たとえば、ブロックは、ルミナンスおよび／またはクロミナンスデータのサンプルの２次元行列を含んでよい。概して、ビデオエンコーダ２００およびビデオデコーダ３００は、ＹＵＶ（たとえば、Ｙ、Ｃｂ、Ｃｒ）フォーマットで表されるビデオデータをコーディングし得る。すなわち、ピクチャのサンプルに対して赤色、緑色、および青色（ＲＧＢ）のデータをコーディングするのではなく、ビデオエンコーダ２００およびビデオデコーダ３００は、ルミナンス成分とクロミナンス成分とをコーディングし得、ここで、クロミナンス成分は、赤色色相および青色色相の両方のクロミナンス成分を含んでよい。いくつかの例では、ビデオエンコーダ２００は、符号化の前に、受信されたＲＧＢフォーマット式データをＹＵＶ表現に変換し、ビデオデコーダ３００は、ＹＵＶ表現をＲＧＢフォーマットに変換する。代替として、前処理ユニットおよび後処理ユニット（図示せず）がこれらの変換を実行してよい。
[0093]本開示は、概して、ピクチャのデータを符号化または復号するプロセスを含めるように、ピクチャのコーディング（たとえば、符号化および復号）に言及することがある。同様に、本開示は、ブロックに対するデータを符号化または復号する、たとえば、予測および／または残差コーディングのプロセスを含めるように、ピクチャのブロックのコーディングに言及することがある。符号化ビデオビットストリームは、概して、コーディング決定（たとえば、コーディングモード）およびブロックへのピクチャの区分を表す、シンタックス要素に対する一連の値を含む。したがって、ピクチャまたはブロックをコーディングすることへの言及は、概して、ピクチャまたはブロックを形成するシンタックス要素に対する値をコーディングすることとして理解されるべきである。
[0094]ＨＥＶＣは、コーディングユニット（ＣＵ）と、予測ユニット（ＰＵ）と、変換ユニット（ＴＵ：transform unit）とを含む、様々なブロックを規定する。ＨＥＶＣによれば、（ビデオエンコーダ２００などの）ビデオコーダは、４分木構造に従ってコーディングツリーユニット（ＣＴＵ）をＣＵに区分する。すなわち、ビデオコーダは、ＣＴＵとＣＵとをオーバーラップしない４つの均等な正方形に区分し、４分木の各ノードは、０個または４個の子ノードのいずれかを有する。子ノードを有しないノードは、「リーフノード」と呼ばれることがあり、そのようなリーフノードのＣＵは、１つもしくは複数のＰＵおよび／または１つもしくは複数のＴＵを含んでよい。ビデオコーダは、ＰＵとＴＵとをさらに区分し得る。たとえば、ＨＥＶＣでは、残差４分木（ＲＱＴ：residual quadtree）はＴＵの区分を表す。ＨＥＶＣでは、ＰＵはインター予測データを表し、ＴＵは残差データを表す。イントラ予測されるＣＵは、イントラモード表示などのイントラ予測情報を含む。
[0095]別の例として、ビデオエンコーダ２００およびビデオデコーダ３００は、ＪＥＭまたはＶＶＣに従って動作するように構成され得る。ＪＥＭまたはＶＶＣによれば、（ビデオエンコーダ２００などの）ビデオコーダは、ピクチャを複数のコーディングツリーユニット（ＣＴＵ）に区分する。ビデオエンコーダ２００は、４分木２分木（ＱＴＢＴ）構造またはマルチタイプツリー（ＭＴＴ：Multi-Type Tree）構造などの木構造に従ってＣＴＵを区分し得る。ＱＴＢＴ構造は、ＨＥＶＣのＣＵ、ＰＵ、およびＴＵの間の分離などの、複数の区分タイプという概念を除去する。ＱＴＢＴ構造は、２つのレベル、すなわち、４分木区分に従って区分される第１のレベルと、２分木区分に従って区分される第２のレベルとを含む。ＱＴＢＴ構造のルートノードは、ＣＴＵに対応する。２分木のリーフノードは、コーディングユニット（ＣＵ）に対応する。
[0096]ＭＴＴ区分構造では、ブロックは、４分木（ＱＴ：quadtree）区分と、２分木（ＢＴ：binary tree）区分と、１つまたは複数のタイプの３分木（ＴＴ：triple tree）（３元木（ＴＴ：ternary tree）とも呼ばれる）区分とを使用して、区分され得る。３分木区分または３元木区分は、ブロックが３つのサブブロックに分割される区分である。いくつかの例では、３分木区分または３元木区分は、中心を通って元のブロックを分割することなく、ブロックを３つのサブブロックに分割する。ＭＴＴにおける区分タイプ（たとえば、ＱＴ、ＢＴ、およびＴＴ）は、対称または非対称であってよい。
[0097]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、ルミナンス成分およびクロミナンス成分の各々を表すために単一のＱＴＢＴまたはＭＴＴ構造を使用し得るが、他の例では、ビデオエンコーダ２００およびビデオデコーダ３００は、ルミナンス成分用の１つのＱＴＢＴ／ＭＴＴ構造および両方のクロミナンス成分用の別のＱＴＢＴ／ＭＴＴ構造（すなわち、それぞれのクロミナンス成分用の２つのＱＴＢＴ／ＭＴＴ構造）などの、２つ以上のＱＴＢＴまたはＭＴＴ構造を使用し得る。
[0098]ビデオエンコーダ２００およびビデオデコーダ３００は、ＨＥＶＣによる４分木区分、ＱＴＢＴ区分、ＭＴＴ区分、または他の区分構造を使用するように構成され得る。説明のために、本開示の技法の説明はＱＴＢＴ区分に関して提示される。ただし、本開示の技法が、４分木区分、または同様に他のタイプの区分を使用するように構成されたビデオコーダにも適用され得ることを理解されたい。
[0099]ブロック（たとえば、ＣＴＵまたはＣＵ）は、ピクチャの中に様々な方法でグループ化されてよい。一例として、ブリック（brick）とは、ピクチャの中の特定のタイル内のＣＴＵ行の長方形領域を指し得る。タイルとは、ピクチャの中の特定のタイル列内および特定のタイル行内のＣＴＵの長方形領域であり得る。タイル列とは、ピクチャの高さに等しい高さと、（たとえば、ピクチャパラメータセットの中などで）シンタックス要素によって指定される幅とを有する、ＣＴＵの長方形領域を指す。タイル行とは、（たとえば、ピクチャパラメータセットの中などで）シンタックス要素によって指定される高さと、ピクチャの幅に等しい幅とを有する、ＣＴＵの長方形領域を指す。
[0100]いくつかの例では、タイルは複数のブリックに区分され得、その各々はタイル内の１つまたは複数のＣＴＵ行を含み得る。複数のブリックに区分されないタイルも、ブリックと呼ばれ得る。ただし、タイルの真のサブセットであるブリックは、タイルと呼ばれないことがある。
[0101]ピクチャの中のブリックはまた、スライスの中に配置され得る。スライスは、単一のネットワーク抽象レイヤ（ＮＡＬ）ユニットの中に排他的に含まれ得る１つのピクチャの整数個のブリックであり得る。いくつかの例では、スライスは、いくつかの完全なタイル、または１つのタイルの完全なブリックの連続したシーケンスのみ、のいずれかを含む。
[0102]本開示は、垂直寸法および水平寸法、たとえば、１６×１６サンプルまたは１６バイ１６（16 by 16）サンプルの観点から、（ＣＵまたは他のビデオブロックなどの）ブロックのサンプル寸法を指すために、「Ｎ×Ｎ」と「ＮバイＮ」とを互換的に使用し得る。概して、１６×１６のＣＵは、垂直方向において１６サンプル（ｙ＝１６）と、水平方向において１６サンプル（ｘ＝１６）とを有する。同様に、Ｎ×ＮのＣＵは、概して、垂直方向においてＮサンプルと、水平方向においてＮサンプルとを有し、ただし、Ｎは非負の整数値を表す。ＣＵの中のサンプルは、行および列をなして配置され得る。その上、ＣＵは、必ずしも水平方向において垂直方向と同じ個数のサンプルを有することを必要としない。たとえば、ＣＵはＮ×Ｍ個のサンプルを備えてよく、ただし、Ｍは必ずしもＮに等しいとは限らない。
[0103]ビデオエンコーダ２００は、予測情報および／または残差情報ならびに他の情報を表す、ＣＵに対するビデオデータを符号化する。予測情報は、ＣＵに対する予測ブロックを形成するために、ＣＵがどのように予測されることになるのかを示す。残差情報は、概して、符号化の前のＣＵのサンプルと予測ブロックとの間のサンプルごとの差分を表す。
[0104]ＣＵを予測するために、ビデオエンコーダ２００は、概して、インター予測またはイントラ予測を通じてＣＵに対する予測ブロックを形成し得る。インター予測は、一般に、以前にコーディングされたピクチャのデータからＣＵを予測することを指すが、イントラ予測は、一般に、同じピクチャの、以前にコーディングされたデータからＣＵを予測することを指す。インター予測を実行するために、ビデオエンコーダ２００は、１つまたは複数の動きベクトルを使用して予測ブロックを生成し得る。ビデオエンコーダ２００は、概して、たとえば、ＣＵと参照ブロックとの間の差分の観点から、ＣＵに密に整合する参照ブロックを識別するために、動き探索を実行し得る。ビデオエンコーダ２００は、参照ブロックが現在ＣＵに密に整合するかどうかを決定するために、絶対差分和（ＳＡＤ）、２乗差分和（ＳＳＤ：sum of squared differences）、平均絶対差分（ＭＡＤ：mean absolute difference）、平均２乗差分（ＭＳＤ：mean squared differences）、または他のそのような差分計算を使用して、差分メトリックを計算し得る。いくつかの例では、ビデオエンコーダ２００は、単方向予測または双方向予測を使用して現在ＣＵを予測し得る。
[0105]ＪＥＭおよびＶＶＣのいくつかの例はまた、インター予測モードと見なされ得るアフィン動き補償モードを提供する。アフィン動き補償モードでは、ビデオエンコーダ２００は、ズームインもしくはズームアウト、回転、遠近の動き（perspective motion）、または他の不規則な動きタイプなどの、並進でない動き（non-translational motion）を表す２つ以上の動きベクトルを決定し得る。
[0106]イントラ予測を実行するために、ビデオエンコーダ２００は、予測ブロックを生成するためのイントラ予測モードを選択し得る。ＪＥＭおよびＶＶＣのいくつかの例は、様々な方向性モードならびに平面モードおよびＤＣモードを含む、６７個のイントラ予測モードを提供する。概して、ビデオエンコーダ２００は、現在ブロックのサンプルをそこから予測するための、現在ブロック（たとえば、ＣＵのブロック）への隣接サンプルを記述する、イントラ予測モードを選択する。ビデオエンコーダ２００がラスタ走査順序（左から右、上から下）でＣＴＵとＣＵとをコーディングすることを想定すると、そのようなサンプルは、概して、現在ブロックと同じピクチャの中の現在ブロックの上、現在ブロックの上およびその左、または現在ブロックの左にあってよい。
[0107]ビデオエンコーダ２００は、現在ブロック用の予測モードを表すデータを符号化する。たとえば、インター予測モードの場合、ビデオエンコーダ２００は、様々な利用可能なインター予測モードのうちのどれが使用されるのか、ならびに対応するモードに対する動き情報を表す、データを符号化し得る。単方向または双方向インター予測の場合、たとえば、ビデオエンコーダ２００は、高度動きベクトル予測（ＡＭＶＰ）モードまたはマージモードを使用して動きベクトルを符号化し得る。ビデオエンコーダ２００は、アフィン動き補償モード用の動きベクトルを符号化するために、類似のモードを使用し得る。
[0108]ブロックのイントラ予測またはインター予測などの予測に続いて、ビデオエンコーダ２００は、ブロックに対する残差データを計算し得る。残差ブロックなどの残差データは、ブロックと、対応する予測モードを使用して形成された、ブロックに対する予測ブロックとの間の差分を、サンプルごとに表す。ビデオエンコーダ２００は、サンプルドメインではなく変換ドメインにおける変換されたデータを作り出すために、１つまたは複数の変換を残差ブロックに適用し得る。たとえば、ビデオエンコーダ２００は、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に類似の変換を、残差ビデオデータに適用し得る。追加として、ビデオエンコーダ２００は、第１の変換に続いて、モード依存非分離可能２次変換（ＭＤＮＳＳＴ：mode-dependent non-separable secondary transform）、信号依存変換（signal dependent transform）、カルーネンレーベ変換（ＫＬＴ：Karhunen-Loeve transform）などの２次変換を適用し得る。ビデオエンコーダ２００は、１つまたは複数の変換の適用に続いて変換係数を作り出す。
[0109]上述のように、変換係数を作り出すための任意の変換に続いて、ビデオエンコーダ２００は変換係数の量子化を実行し得る。量子化とは、概して、係数を表すために使用されるデータの量をできる限り低減してさらなる圧縮をもたらすように、変換係数が量子化されるプロセスを指す。量子化プロセスを実行することによって、ビデオエンコーダ２００は、係数の一部または全部に関連するビット深度を低減し得る。たとえば、ビデオエンコーダ２００は、量子化の間にｎビット値をｍビット値まで小さく丸めてよく、ただし、ｎはｍよりも大きい。いくつかの例では、量子化を実行するために、ビデオエンコーダ２００は、量子化されるべき値のビット単位での右シフトを実行し得る。
[0110]量子化に続いて、ビデオエンコーダ２００は変換係数を走査してよく、量子化変換係数を含む２次元行列から１次元ベクトルを作り出す。走査は、より高いエネルギー（したがって、より低い周波数）係数をベクトルの前方に配置し、より低いエネルギー（したがって、より高い周波数）変換係数をベクトルの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２００は、量子化変換係数を走査してシリアル化されたベクトルを作り出すために、既定の走査順序を利用してよく、次いで、ベクトルの量子化変換係数をエントロピー符号化してよい。他の例では、ビデオエンコーダ２００は適応走査を実行し得る。１次元ベクトルを形成するために量子化変換係数を走査した後、ビデオエンコーダ２００は、たとえば、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）に従って、１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２００はまた、ビデオデータを復号する際のビデオデコーダ３００による使用のために、符号化ビデオデータに関連するメタデータを記述するシンタックス要素に対する値をエントロピー符号化し得る。
[0111]ＣＡＢＡＣを実行するために、ビデオエンコーダ２００は、コンテキストモデル内のコンテキストを、送信されるべきシンボルに割り当ててよい。コンテキストは、たとえば、シンボルの隣接する値が０値であるか否かに関係し得る。確率決定は、シンボルに割り当てられたコンテキストに基づいてよい。
[0112]ビデオエンコーダ２００は、たとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはシーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、もしくはビデオパラメータセット（ＶＰＳ）などの他のシンタックスデータの中で、ビデオデコーダ３００への、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、およびシーケンスベースのシンタックスデータなどの、シンタックスデータをさらに生成し得る。ビデオデコーダ３００は、対応するビデオデータをどのように復号すべきかを決定するために、そのようなシンタックスデータを同様に復号し得る。
[0113]このようにして、ビデオエンコーダ２００は、符号化ビデオデータ、たとえば、ブロック（たとえば、ＣＵ）へのピクチャの区分ならびにブロックに対する予測情報および／または残差情報を記述するシンタックス要素を含む、ビットストリームを生成し得る。最終的に、ビデオデコーダ３００は、ビットストリームを受信し得、符号化ビデオデータを復号し得る。
[0114]概して、ビデオデコーダ３００は、ビットストリームの符号化ビデオデータを復号するために、ビデオエンコーダ２００によって実行されるプロセスとは相反のプロセスを実行する。たとえば、ビデオデコーダ３００は、ビデオエンコーダ２００のＣＡＢＡＣ符号化プロセスとは相反としても、それと実質的に類似の方法で、ＣＡＢＡＣを使用してビットストリームのシンタックス要素に対する値を復号し得る。シンタックス要素は、ＣＴＵのＣＵを規定するために、ＱＴＢＴ構造などの対応する区分構造に従って、ＣＴＵへのピクチャの区分情報と、各ＣＴＵの区分とを規定し得る。シンタックス要素は、ビデオデータのブロック（たとえば、ＣＵ）に対する予測情報と残差情報とをさらに規定し得る。
[0115]残差情報は、たとえば、量子化変換係数によって表されてよい。ビデオデコーダ３００は、ブロックに対する残差ブロックを再生するために、ブロックの量子化変換係数を逆量子化および逆変換し得る。ビデオデコーダ３００は、ブロックに対する予測ブロックを形成するために、シグナリングされた予測モード（イントラ予測またはインター予測）と、関連する予測情報（たとえば、インター予測用の動き情報）とを使用する。ビデオデコーダ３００は、次いで、元のブロックを再生するために予測ブロックと残差ブロックとを（サンプルごとに）組み合わせ得る。ビデオデコーダ３００は、ブロックの境界に沿った視覚的アーティファクトを低減するためにデブロッキングプロセスを実行することなどの、追加の処理を実行し得る。
[0116]ビデオエンコーダ２００およびビデオデコーダ３００は、デコーダ側動きベクトル改良（ＤＭＶＲ）を向上させるために、本開示の技法を実行し得る。「デコーダ側」と呼ばれるが、ビデオエンコーダ２００とビデオデコーダ３００の両方によって生成される、対応する予測ブロックが一致することを確実にするために、これらの技法をビデオエンコーダ２００も実行し得ることを理解されたい。ビデオエンコーダ２００およびビデオデコーダ３００は、単独で、または任意の組合せで、以下で説明する技法のうちのいずれかまたはすべてを実行し得る。
[0117]図１０Ａおよび図１０Ｂは、改良された動きベクトルを使用してＢＩＯを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図である。ビデオエンコーダ２００およびビデオデコーダ３００は、ＢＩＯが、勾配値を算出するためのソースとして、パディングされたフィルタ入力サンプル（すなわち、参照ピクチャからフェッチされるとともに動き補償のために使用されるサンプル）を取り、最終の動き補償を実行することを可能にするために、この技法を使用するように構成され得る。
[0118]メモリ帯域幅に対する制約に起因して、参照ピクチャからフェッチされ得るピクセルの最大数は（ｗ＋７）＊（ｈ＋７）であり、ただし、ｗおよびｈは、ＣＵの幅と高さとを示す。デコーダ側動きベクトル改良（ＤＭＶＲ）および／またはテンプレートマッチング予測（ＴＭＰ：template matching prediction）から導出され得る、事前定義された最大変位ベクトルｄを用いると、フェッチされるサンプルエリアは、（ｗ＋７＋２ｄ）＊（ｈ＋７＋２ｄ）と同程度に大きさとなるべきであり、ここで、（ｗ＋７）＊（ｈ＋７）のエリアの外側の追加のサンプルは、近くのサンプルからパディングされ、ｄ≧０である。
[0119]図１０Ｂは、（ｗ＋７）＊（ｈ＋７）のエリアとパディングされるサンプルとの間の幾何学的関係を示す。改良されたＭＶ（たとえば、図１０Ａおよび図１０Ｂの中のΔＭＶ）を用いてＢＩＯが適用されるとき、勾配値を算出するために、パディングされるエリアの外側の余分なピクセルがやはり必要である。したがって、ビデオエンコーダ２００およびビデオデコーダ３００は、パディングされるサイズをｄピクセルからｄ＋ｓピクセルに大きくし得、ここで、ｓは勾配フィルタの長さの半分である（たとえば、３，５，７，．．．タップ勾配フィルタに対して、それぞれ、ｓ＝１，２，３，．．．である）。（ｗ＋７＋２ｄ）＊（ｈ＋７＋２ｄ）を形成するために使用された同じパディング方法が適用される。元のフィルタ入力サンプル＋パディングされるエリアの、得られるサイズは、（ｗ＋７＋２ｄ＋２ｓ）＊（ｈ＋７＋２ｄ＋２ｓ）になる。
[0120]図１１は、コーディングツリーユニット（ＣＴＵ）を横断する仮想パイプラインデータユニット（ＶＰＤＵ：virtual pipeline data unit）の例示的な処理順序を示す概念図である。ビデオエンコーダ２００およびビデオデコーダ３００は、マージモードおよび／またはＡＭＶＰモードに対して動きベクトル予測のための参照が取られ得る場所を制約することがある。（上記で説明したような）プリフェッチング問題に起因して、後続のブロックが空間的な動き予測を実行するために、現在のフレームの中の復号されたＣＵからの、改良されたすべてのＭＶが利用可能であるとは限らない。基本的に、改良された動きベクトルが左上のＣＴＵまたは上のＣＴＵのいずれかの中のブロックからである場合のみ、空間的な因果的近傍の中にある改良されたＭＶが使用され得る。以下の２つの技法のうちの一方または両方が、単独で、もしくは互いに組み合わせて、および／または本明細書で説明する他の技法とともに、使用され得る。
[0121]一例では、右上のＣＴＵからの改良されたＭＶも、空間的な動き予測のための参照として取られ得る。別の例では、少なくともＮ個のＶＰＤＵ（６４×６４というサイズを有する仮想パイプラインデータユニット、Ｎ＞１）だけ前方で生成される、改良されたＭＶは、空間的な動き予測のための参照として取られ得る。図１１に示すように、ＣＴＵサイズが１２８×１２８であるとき、パイプラインデータユニットは、下にあるＣＵ区分が何であろうと最大サイズの変換ユニット用に合わせるために、ＣＴＵをサイズが等しくオーバーラップしない４個の正方形ブロックに小さく分割する。したがって、空間的に直接隣接するＶＰＤＵの中の改良されたＭＶのうちのいくつかは、利用可能になり得る。たとえば、Ｎ＝２であることが与えられると、Ｄ０／Ａ１／Ｄ１は、Ａ０／Ｂ０／Ａ１から改良されたＭＶを取ることができ、Ｃ１は、Ｂ０およびＤ０から参照を取ることができる。
[0122]いくつかの例では、次のように、ＨＭＶＰリストの更新プロセスに対して追加の制約があり得る。アフィンフラグがオフ（すなわち、並進動きモデル）であるとき、現在フレームの中の復号されるＣＵの改良されたＭＶは、ＨＭＶＰリストへ入れることはできない。代わりに、ＨＭＶＰリストを更新するために２つの代替形態が使用され得る。いくつかの例では、復号されるＣＵの元の（オリジナルの）ＭＶは、ＨＭＶＰリストへ入れられる。他の例では、ＨＭＶＰリストを更新するために何も入れられない。
[0123]いくつかの例では、アフィンフラグがオン（すなわち、アフィン動きモデル）であるとき、現在フレームの中の復号されるＣＵの改良されたＣＰＭＶ（制御点動きベクトル）は、アフィンＨＭＶＰリストへ入れることができない。代わりに、ビデオエンコーダ２００およびビデオデコーダ３００は、この復号されるＣＵの元のＣＰＭＶをアフィンＨＭＶＰリストへ入れることによって、アフィンＨＭＶＰリストを更新し得る。代替として、いくつかの例では、アフィンＨＭＶＰリストを更新するために何も入れられない。
[0124]別の例示的な技法は、アフィンマージ候補を形成するために、改良されたＭＶをＣＰＭＶとして因果的隣接サブブロックから条件付きで取ることを回避するために、構成型アフィンマージ候補（構成型モードとも呼ばれる）に対する制約を含む。この例示的な技法では、現在ＣＵの空間的な因果的近傍の中でサンプリングされる各サブブロックＭＶは、構成型モードに対してその元のサブブロックＭＶが使用され得るのか、それともその改良された代替物が使用され得るのかを決定するために、以下の規則を適用する。（ＭＶが、ここでは、並進動き、アフィンＣＰＭＶ、およびアフィン導出サブブロックＭＶのものであり得ることに留意されたい。）いくつかの例では、サンプリングされるサブブロックが上のＣＴＵ行に位置する場合、それらの改良されたＭＶ（それらが存在する場合）が、構成型モードのために使用され得る。追加または代替として、サンプリングされるサブブロックが、現在ＣＴＵ中、または現在ＣＴＵの左の他のＣＴＵ中に位置する場合、それらの元のＭＶ（それらが存在する場合）だけが、構成型モードのために使用され得る。
[0125]加えて、低計算量コード設計のために、現在ＣＴＵ行の中の改良された情報を有するサブブロックは、構成型モードのプロセスにおいて常に利用不可能としてマークされ、現在ＣＴＵ行のすぐ上のＣＴＵ行に置かれているサブブロックは、利用可能としてマークされる。その上、ビデオエンコーダ２００およびビデオデコーダ３００は、構成型モードのプロセスにおいて、右上のＣＴＵからの改良されたＭＶが利用可能としてマークされるべきか否かを決定する（たとえば、シーケンスレベルにおいて事前定義または構成される）ための追加のフレキシビリティを保持し得る。
[0126]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、一般化双予測（ＧＢｉ）と重み付き双予測（ＷＰ：weighted bi-prediction）とを使用する双予測に適用される重み値を正規化してよい。重み値の大きさに従って、各予測サンプルは、双予測の最終の予測信号への不均等な寄与を有することがある。しかしながら、ＤＭＶＲは常に、Ｌ０予測信号およびＬ１予測信号が最終の双予測信号に均等に寄与することを想定し、そのため、目的関数は、Ｌ０予測ブロックとＬ１予測ブロックとの間の差分を最小化すべきデルタＭＶを見つけるものとして定義される。不均等な重み値が双予測に対して使用されるとき、この想定が当てはまらないことがあるので、この例示的な技法は、ＧＢｉおよびＷＰによって使用される重み値を正規化することを含む。ｗ0およびｗ1が、それぞれ、Ｌ０予測ブロックおよびＬ１予測ブロック（すなわち、それぞれ、ｐ0およびｐ1として示される）に適用される重み値であると考えると、提案される正規化されたコスト関数は次のように定義される。
Figure 2022507683000012
または
Figure 2022507683000013
ただし、ｎは、予測ブロックの中のピクセルの局所的なピクセル座標である。
[0127]これらの式を非整数演算から防止するために、ｗ0およびｗ1に正の整数スカラー（ｓとして示す）が適用されてよい。
Figure 2022507683000014
または
Figure 2022507683000015
[0128]ｓの値は、１、２、４、８、および２のべき乗の他の整数であり得る。たとえば、ｓの示唆される構成は、ＧＢｉに対してｓ＝８、ルーマＷＰに対してｓ＝２luma_log2_weight_denom+Max(2,14-LumaBitDepth)、またはクロマＷＰに対してｓ＝２luma_log2_weight_denom+delta_chroma_log2_weight_denom+Max(2,14-ChromaBitDepth)であり得る。
[0129]様々な例では、ＭＭＶＲまたはマージオフセット拡張のいずれかのシンタックスがビットストリームの中に存在するとき、その使用を限定するために、ＤＭＶＲに対して制約が課されることがある。例示的な独立した５つの制約が以下に示される。
・ＤＭＶＲは、それがＭＭＶＲによって生成されるのか、マージオフセット拡張によって生成されるのか、それとも通常のマージモードによって生成されるのかにかかわらず、双予測動きを有するブロックに常に適用される。
・ＤＭＶＲは、１）通常のマージモード、および２）元の動きが指し示した位置を中心とする［±ｄ，±ｄ］エリア（ただし、ｄ≧０）の外側を指し示す変位ベクトルを用いる、そのＭＭＶＲまたはマージオフセット拡張、から導出された、双予測動きに適用される。
・ＤＭＶＲは、１）通常のマージモード、および２）元の動きが指し示した位置を中心とする［±ｄ，±ｄ］エリア（ただし、ｄ≧０）の内側を指し示す変位ベクトルを用いる、そのＭＭＶＲまたはマージオフセット拡張、から導出された、双予測動きに適用される。
・ＤＭＶＲは、それがＭＭＶＲおよびマージオフセット拡張によって生成されないとき、双予測動きを改良するためだけに適用される。
・ＤＭＶＲは、ＭＭＶＲおよびマージオフセット拡張のシンタックスを有するマージ候補には適用されない。たとえば、ビデオ規格が、マージリストの中のいくつかの動き候補にＭＭＶＲシンタックスを適用し得る。本開示では、ＤＭＶＲはそれらに適用されない。
[0130]図１２は、水平補間に対して水平パディングしか使用されない技法を示す概念図である。いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、ＤＭＶＲにおける（上で前述の）パディングプロセスの計算量と記憶空間とを低減するために、指定された順序付きプロセスを実行し得る。上記の例では、２つの余分なピクセルが、（ｗ＋７）＊（ｈ＋７）のピクセルの各側部にパディングされる。結果は、（ｗ＋１１）＊（ｈ＋１１）のピクセルを含むメモリブロックの中にバッファリングされる。次いで、ＤＭＶＲは、探索エリアサンプルを形成するために動き補償の実行を必要とする。基本的に、最初に水平補間が適用され、補間結果をバッファリングするためにサイズ（ｗ＋１１－ｔ）＊（ｗ＋１１）の中間バッファが必要とされ、ただし、ｔは補間フィルタタップの数－１である。たとえば、補間フィルタが８タップであるとき、ｔ＝７である。
[0131]いくつかの例では、パディングプロセスは２ステップのプロセスになる。最初に、（ｗ＋７）＊（ｈ＋７）のピクセルの各側部へのパディングを実行するのではなく、ビデオエンコーダ２００およびビデオデコーダ３００は、パディングプロセスを水平にのみ実行し得る。したがって、水平補間を実行する前に（ｗ＋１１）＊（ｈ＋７）のピクセルだけがバッファリングされる必要がある。次いで、ビデオエンコーダ２００およびビデオデコーダ３００は、水平補間を実行し得、得られたピクセルを、サイズ（ｗ＋１１－ｔ）＊（ｈ＋７）のメモリブロックにぴったり合うようにバッファリングし得る。このことに続いて、ビデオエンコーダ２００およびビデオデコーダ３００は、元のパディングプロセスを通じて生成される前述の（ｗ＋１１－ｔ）＊（ｗ＋１１）のピクセルと同じピクセルを形成するために、メモリブロックの上および下への垂直パディングを実行し得る。
[0132]２ステップのパディングプロセスを用いると、水平補間入力を保つためのバッファサイズが（ｗ＋１１）＊（ｈ＋１１）から（ｗ＋１１）＊（ｈ＋７）に事実上低減される。したがって、水平補間から持ち込まれる計算量が低減され得る。
[0133]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、パラメトリックサブペルＭＶ導出の概念を、丸めオフセットおよび代替のサンプリングロケーションを有する、より正確なＭＶ表現に拡張するために、下の３つの例示的な技法のうちの１つまたは複数を実行し得る。
[0134]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、丸めオフセットを実行し得る。すなわち、ビデオエンコーダ２００およびビデオデコーダ３００は、次のように、パラメトリック誤差曲面関数の解に丸めオフセットを追加してよい。
Figure 2022507683000016
ここで、βは、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで決定され得る、丸めオフセットである。βの値は、０、±ｅ、±２ｅ、±３ｅ、４ｅ－１、または－４ｅ＋１であり得、ただし、ｅ＝Ｅ-1,0＋Ｅ1,0－２Ｅ0,0である。
[0135]加えて、いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００はまた、丸めオフセットが、シグナリングを伴わない定数値、たとえば、β＝２（Ｅ-1,0＋Ｅ1,0－２Ｅ0,0）として直接設定される、簡略化された設計を使用してよい。
[0136]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、スパースサンプリング表現を実行し得る。１ペル区間を有する十字形の終点からコスト値をサンプリングするのではなく、ビデオエンコーダ２００およびビデオデコーダ３００は、パラメトリックサブペルＭＶ導出の概念をＮペル区間に拡張する技法を適用し得る。
Figure 2022507683000017
ここで、Ｎは、１、２、３、４、．．．、８であり得、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで示される。
[0137]加えて、本開示はまた、定数値、すなわち、Ｎ＝２を伴う、簡略化された設計を提案する。
[0138]これらの技法も、上述のように丸めオフセットを扱う。丸めオフセットが存在するとき、（Δｘ，Δｙ）は以下のように表され得る。
Figure 2022507683000018
ここで、βは、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで決定され得る、丸めオフセットである。βの値は、０、±ｅ、±２ｅ、±３ｅ、４ｅ－１、または－４ｅ＋１であり得、ただし、ｅ＝Ｅ-N,0＋ＥN,0－２Ｅ0,0である。加えて、ビデオエンコーダ２００およびビデオデコーダ３００は、丸めオフセットが、シグナリングを伴わない定数値、たとえば、β＝２（Ｅ-N,0＋ＥN,0－２Ｅ0,0）として直接設定され得る、簡略化された設計を使用してよい。
[0139]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、代替のサンプリングパターンを実行し得る。いくつかの例では、パラメトリックサブペルＭＶ導出のために使用されるサンプリングロケーションは、ｘ軸およびｙ軸に沿った十字形パターンの終点からである必要がない。そのような例では、ビデオエンコーダ２００およびビデオデコーダ３００は、配位系を反時計回りに４５度だけ回転させ得、次のように、パラメトリック解の新たな閉形式解（Δｘ，Δｙ）が得られる。
Figure 2022507683000019
および
Figure 2022507683000020
[0140]さらに、これらの技法も、上記で説明した丸めオフセット、および／または上記で説明したスパースサンプリングを扱うことができる。
・丸めオフセット（Rounding offset）：
Figure 2022507683000021
・スパースサンプリング（Sparse sampling）：
Figure 2022507683000022
・組合せ（Combination）：
Figure 2022507683000023
[0141]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、ＤＭＶＲがインター予測の最悪状況のメモリ帯域幅を過大に増大させることを防止するために、ＤＭＶＲの最小ブロックサイズに対する制約を採用し得る。そのような例では、予測ブロックが以下の条件のうちのいずれかを満たすとき、ビデオエンコーダ２００およびビデオデコーダ３００はＤＭＶＲを実行しない。
・ブロックサイズがＮ×４または４×Ｎであり、ここで、Ｎは、正の整数（たとえば、４、８、１６、３２、６４、１２８、２５６、．．．）である。
・ブロックサイズが８×８と同じである。
[0142]いくつかの例では、ビデオエンコーダ２００およびビデオデコーダ３００は、以下のサイズのブロックに対してＤＭＶＲを実行することを回避してよい。
・Ｎ＜６４（たとえば、４、８、１６、３２）であって、ブロックサイズがＮ×４または４×Ｎである。
・ＤＭＶＲの探索点が完全に［－１，１］×［－１，１］の範囲内にカバーされるとは限らないとき、Ｎ≧６４（たとえば、６４、１２８）であって、ブロックサイズがＮ×４または４×Ｎである。
・ブロックサイズが８×８と同じである。
[0143]このようにして、ビデオエンコーダ２００およびビデオデコーダ３００は、８ピクセルよりも小さい幅もしくは高さのうちの少なくとも１つ、または８×８ピクセルに等しいサイズを有するブロックに対して、ＤＭＶＲを実行することを回避してよい。ビデオエンコーダ２００およびビデオデコーダ３００は、８×８よりも大きいサイズ、すなわち、少なくとも８×ＮまたはＮ×８を有するブロックに対して、ＤＭＶＲを実行し得、ここで、Ｎは、８よりも大きい整数値である。そのようなブロックに対してデフォルトでＤＭＶＲがイネーブルにさ得、またはビデオエンコーダ２００およびビデオデコーダ３００は、そのようなブロックに対してＤＭＶＲを実行すべきかどうかを決定するために評価されるべき追加の基準とともに構成され得る。
[0144]本開示は、概して、シンタックス要素などのいくつかの情報を「シグナリングすること」に言及することがある。「シグナリング」という用語は、概して、シンタックス要素の値および／または符号化ビデオデータを復号するために使用される他のデータの通信を指してよい。すなわち、ビデオエンコーダ２００は、シンタックス要素に対する値をビットストリームの中でシグナリングしてよい。概して、シグナリングとは、ビットストリームの中の値を生成することを指す。上述のように、ソースデバイス１０２は、実質的にリアルタイムで、または宛先デバイス１１６によって後で取り出せるようにシンタックス要素を記憶デバイス１１２に記憶するときに起こり得るようにリアルタイムでなく、ビットストリームを宛先デバイス１１６にトランスポートし得る。
[0145]図１３Ａおよび図１３Ｂは、例示的な４分木２分木（ＱＴＢＴ）構造１３０と、対応するコーディングツリーユニット（ＣＴＵ）１３２とを示す概念図である。実線は４分木分割を表し、点線は２分木分割を示す。２分木の分割された各（すなわち、非リーフ）ノードにおいて、どの分割タイプ（すなわち、水平または垂直）が使用されるのかを示すために１つのフラグがシグナリングされ、ここで、この例では、０は水平分割を示し、１は垂直分割を示す。４分木分割の場合、４分木ノードは、サイズが等しい４つのサブブロックに、水平および垂直にブロックを分割するので、分割タイプを示す必要がない。したがって、ＱＴＢＴ構造１３０の領域ツリーレベルに対する（分割情報などの）シンタックス要素（すなわち、実線）と、ＱＴＢＴ構造１３０の予測ツリーレベルに対する（分割情報などの）シンタックス要素（すなわち、破線）とを、ビデオエンコーダ２００が符号化し得、ビデオデコーダ３００が復号し得る。ＱＴＢＴ構造１３０の端末リーフノードによって表されるＣＵに対して、予測データおよび変換データなどのビデオデータを、ビデオエンコーダ２００が符号化し得、ビデオデコーダ３００が復号し得る。
[0146]概して、図１３ＢのＣＴＵ１３２は、第１および第２のレベルにおけるＱＴＢＴ構造１３０のノードに対応するブロックのサイズを規定するパラメータに関連し得る。これらのパラメータは、（サンプル単位でＣＴＵ１３２のサイズを表す）ＣＴＵサイズと、最小４分木サイズ（最小許容４分木リーフノードサイズを表す、ＭｉｎＱＴＳｉｚｅ）と、最大２分木サイズ（最大許容２分木ルートノードサイズを表す、ＭａｘＢＴＳｉｚｅ）と、最大２分木深度（最大許容２分木深度を表す、ＭａｘＢＴＤｅｐｔｈ）と、最小２分木サイズ（最小許容２分木リーフノードサイズを表す、ＭｉｎＢＴＳｉｚｅ）とを含み得る。
[0147]ＣＴＵに対応するＱＴＢＴ構造のルートノードは、ＱＴＢＴ構造の第１のレベルにおいて４つの子ノードを有してよく、その各々は、４分木区分に従って区分され得る。すなわち、第１のレベルのノードは、（子ノードを有しない）いずれかのリーフノードであるか、または４つの子ノードを有する。ＱＴＢＴ構造１３０の例は、分岐に対して実線を有する親ノードと子ノードとを含むものとして、そのようなノードを表す。第１のレベルのノードが最大許容２分木ルートノードサイズ（ＭａｘＢＴＳｉｚｅ）よりも大きくない場合、ノードはそれぞれの２分木によってさらに区分され得る。１つのノードの２分木分割は、分割から得られるノードが最小許容２分木リーフノードサイズ（ＭｉｎＢＴＳｉｚｅ）または最大許容２分木深度（ＭａｘＢＴＤｅｐｔｈ）に到達するまで反復され得る。ＱＴＢＴ構造１３０の例は、分岐に対して破線を有するものとしてそのようなノードを表す。２分木リーフノードは、コーディングユニット（ＣＵ）と呼ばれ、コーディングユニット（ＣＵ）は、それ以上区分することなく、予測（たとえば、イントラピクチャ予測またはインターピクチャ予測）および変換のために使用される。上記で説明したように、ＣＵは、「ビデオブロック」または「ブロック」と呼ばれることもある。
[0148]ＱＴＢＴ区分構造の一例では、ＣＴＵサイズは１２８×１２８（ルーマサンプルおよび２つの対応する６４×６４クロマサンプル）として設定され、ＭｉｎＱＴＳｉｚｅは１６×１６として設定され、ＭａｘＢＴＳｉｚｅは６４×６４として設定され、ＭｉｎＢＴＳｉｚｅは（幅と高さの両方に対して）４として設定され、ＭａｘＢＴＤｅｐｔｈは４として設定される。４分木リーフノードを生成するために、最初に４分木区分がＣＴＵに適用される。４分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを有してよい。リーフ４分木ノードが１２８×１２８である場合、リーフ４分木ノードは、サイズがＭａｘＢＴＳｉｚｅ（すなわち、この例では６４×６４）を上回るので、２分木によってそれ以上分割されない。そうでない場合、リーフ４分木ノードは、２分木によってさらに区分される。したがって、４分木リーフノードはまた、２分木に対してルートノードであり、０としての２分木深度を有する。２分木深度がＭａｘＢＴＤｅｐｔｈ（この例では４）に到達すると、それ以上の分割は許されない。２分木ノードがＭｉｎＢＴＳｉｚｅ（この例では４）に等しい幅を有するとき、そのことはそれ以上の水平分割が許されないことを暗示する。同様に、ＭｉｎＢＴＳｉｚｅに等しい高さを有する２分木ノードは、その２分木ノードに対してそれ以上の垂直分割が許されないことを暗示する。上述のように、２分木のリーフノードはＣＵと呼ばれ、それ以上区分することなく予測および変換に従ってさらに処理される。
[0149]図１４は、本開示の技法を実行し得る例示的なビデオエンコーダ２００を示すブロック図である。図１４は説明のために提供され、本開示において広く例示および説明されるような技法の限定と見なされるべきでない。説明のために、本開示は、開発中のＨＥＶＣビデオコーディング規格およびＨ．２６６ビデオコーディング規格などの、ビデオコーディング規格のコンテキストでビデオエンコーダ２００を説明する。しかしながら、本開示の技法はこれらのビデオコーディング規格に限定されず、一般にビデオ符号化およびビデオ復号に適用可能である。
[0150]図１４の例では、ビデオエンコーダ２００は、ビデオデータメモリ２３０と、モード選択ユニット２０２と、残差生成ユニット２０４と、変換処理ユニット２０６と、量子化ユニット２０８と、逆量子化ユニット２１０と、逆変換処理ユニット２１２と、再構成ユニット２１４と、フィルタユニット２１６と、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）２１８と、エントロピー符号化ユニット２２０とを含む。ビデオデータメモリ２３０、モード選択ユニット２０２、残差生成ユニット２０４、変換処理ユニット２０６、量子化ユニット２０８、逆量子化ユニット２１０、逆変換処理ユニット２１２、再構成ユニット２１４、フィルタユニット２１６、ＤＰＢ２１８、およびエントロピー符号化ユニット２２０のうちのいずれかまたはすべては、１つまたは複数のプロセッサまたは処理回路構成で実装され得る。たとえば、ビデオエンコーダ２００のユニットは、１つまたは複数の回路または論理要素として、ハードウェア回路構成の一部として、またはプロセッサ、ＡＳＩＣ、もしくはＦＰＧＡの一部として、実装され得る。その上、ビデオエンコーダ２００は、これらおよび他の機能を実行するために、追加または代替のプロセッサまたは処理回路構成を含んでよい。
[0151]ビデオデータメモリ２３０は、ビデオエンコーダ２００の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオエンコーダ２００は、たとえば、ビデオソース１０４（図９）から、ビデオデータメモリ２３０の中に記憶されるビデオデータを受信し得る。ＤＰＢ２１８は、ビデオエンコーダ２００による後続のビデオデータの予測における使用のための参照ビデオデータを記憶する参照ピクチャメモリとして働いてよい。ビデオデータメモリ２３０およびＤＰＢ２１８は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスを含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの、様々なメモリデバイスのうちのいずれかによって形成され得る。ビデオデータメモリ２３０およびＤＰＢ２１８は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、ビデオデータメモリ２３０は、図示したようにビデオエンコーダ２００の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってよい。
[0152]本開示では、ビデオデータメモリ２３０への言及は、そのように特に説明されない限りビデオエンコーダ２００の内部のメモリに限定されるものとして解釈されるべきでなく、またはそのように特に説明されない限りビデオエンコーダ２００の外部のメモリに限定されるものとして解釈されるべきでない。むしろ、ビデオデータメモリ２３０への言及は、符号化するためにビデオエンコーダ２００が受信するビデオデータ（たとえば、符号化されることになる現在ブロックに対するビデオデータ）を記憶する参照メモリとして理解されるべきである。図９のメモリ１０６も、ビデオエンコーダ２００の様々なユニットからの出力の一時的な記憶を提供し得る。
[0153]図１４の様々なユニットは、ビデオエンコーダ２００によって実行される動作を理解するのを支援するために図示される。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。固定機能回路とは、特定の機能性を提供する回路を指し、実行され得る動作において事前設定される。プログラマブル回路とは、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能性を提供する。たとえば、プログラマブル回路は、プログラマブル回路に、ソフトウェアまたはファームウェアの命令によって規定される方式で動作させる、ソフトウェアまたはファームウェアを実行し得る。固定機能回路は、（たとえば、パラメータを受信しパラメータを出力するための）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは、一般に不変である。いくつかの例では、ユニットのうちの１つまたは複数は異なる回路ブロック（固定機能またはプログラマブル）であってよく、いくつかの例では、１つまたは複数のユニットは集積回路であってよい。
[0154]ビデオエンコーダ２００は、算術論理ユニット（ＡＬＵ）、初等関数ユニット（ＥＦＵ）、デジタル回路、アナログ回路、および／またはプログラマブル回路から形成されたプログラマブルコアを含んでよい。ビデオエンコーダ２００の動作が、プログラマブル回路によって実行されるソフトウェアを使用して実行される例では、メモリ１０６（図９）は、ビデオエンコーダ２００が受信および実行するソフトウェアのオブジェクトコードを記憶してよく、またはビデオエンコーダ２００内の別のメモリ（図示せず）が、そのような命令を記憶してもよい。
[0155]ビデオデータメモリ２３０は、受信されたビデオデータを記憶するように構成される。ビデオエンコーダ２００は、ビデオデータメモリ２３０からビデオデータのピクチャを取り出してよく、残差生成ユニット２０４およびモード選択ユニット２０２にビデオデータを提供してよい。ビデオデータメモリ２３０の中のビデオデータは、符号化されることになる未加工のビデオデータであってよい。
[0156]モード選択ユニット２０２は、動き推定ユニット２２２と、動き補償ユニット２２４と、イントラ予測ユニット２２６とを含む。モード選択ユニット２０２は、他の予測モードに従ってビデオ予測を実行するために、追加の機能ユニットを含んでよい。例として、モード選択ユニット２０２は、パレットユニット、（動き推定ユニット２２２および／または動き補償ユニット２２４の一部であり得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ：linear model）ユニットなどを含んでよい。
[0157]モード選択ユニット２０２は、概して、符号化パラメータの組合せと、そのような組合せに対して得られたレートひずみ値とをテストするために、複数の符号化パスを協調させる。符号化パラメータは、ＣＵへのＣＴＵの区分、ＣＵのための予測モード、ＣＵの残差データ用の変換タイプ、ＣＵの残差データのための量子化パラメータなどを含んでよい。モード選択ユニット２０２は、テストされた他の組合せよりも良好なレートひずみ値を有する符号化パラメータの組合せを、最終的に選択してよい。
[0158]ビデオエンコーダ２００は、ビデオデータメモリ２３０から取り出されたピクチャを一連のＣＴＵに区分してよく、スライス内の１つまたは複数のＣＴＵをカプセル化してよい。モード選択ユニット２０２は、上記で説明した、ＨＥＶＣのＱＴＢＴ構造または４分木構造などの木構造に従って、ピクチャのＣＴＵを区分してよい。上記で説明したように、ビデオエンコーダ２００は、木構造に従ってＣＴＵを区分することから１つまたは複数のＣＵを形成し得る。そのようなＣＵは、一般に、「ビデオブロック」または「ブロック」と呼ばれることもある。
[0159]概して、モード選択ユニット２０２はまた、現在ブロック（たとえば、現在ＣＵ、またはＨＥＶＣでは、ＰＵおよびＴＵのオーバーラップする部分）に対する予測ブロックを生成するために、その構成要素（たとえば、動き推定ユニット２２２、動き補償ユニット２２４、およびイントラ予測ユニット２２６）を制御する。現在ブロックのインター予測に対して、動き推定ユニット２２２は、１つまたは複数の参照ピクチャ（たとえば、ＤＰＢ２１８の中に記憶された、以前にコーディングされた１つまたは複数のピクチャ）の中の、密に整合する１つまたは複数の参照ブロックを識別するために、動き探索を実行し得る。詳細には、動き推定ユニット２２２は、たとえば、絶対差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、平均絶対差分（ＭＡＤ）、平均２乗差分（ＭＳＤ）などに従って、可能な参照ブロックが現在ブロックにどのくらい類似しているのかを表す値を計算し得る。動き推定ユニット２２２は、概して、現在ブロックと検討中の参照ブロックとの間のサンプルごとの差分を使用して、これらの計算を実行し得る。動き推定ユニット２２２は、現在ブロックに最も密に整合する参照ブロックを示す、これらの計算から得られる最小値を有する参照ブロックを識別し得る。
[0160]動き推定ユニット２２２は、現在ピクチャの中の現在ブロックの位置に対して、参照ピクチャの中の参照ブロックの位置を規定する、１つまたは複数の動きベクトル（ＭＶ）を形成し得る。動き推定ユニット２２２は、次いで、動き補償ユニット２２４に動きベクトルを提供し得る。たとえば、単方向インター予測の場合、動き推定ユニット２２２は単一の動きベクトルを提供し得るが、双方向インター予測の場合、動き推定ユニット２２２は２つの動きベクトルを提供し得る。動き補償ユニット２２４は、次いで、動きベクトルを使用して予測ブロックを生成し得る。たとえば、動き補償ユニット２２４は、動きベクトルを使用して参照ブロックのデータを取り出し得る。別の例として、動きベクトルが分数サンプル精度を有する場合、動き補償ユニット２２４は、予測ブロックに対する値を１つまたは複数の補間フィルタに従って補間し得る。さらに、双方向インター予測の場合、動き補償ユニット２２４は、それぞれの動きベクトルによって識別される２つの参照ブロックに対するデータを取り出し得、たとえば、サンプルごとの平均化または重み付き平均化を通じて、取り出されたデータを組み合わせ得る。
[0161]本開示の技法によれば、動き補償ユニット２２４は、ビデオデータの現在ブロックに対してＤＭＶＲがイネーブルにされているとき、動きベクトルを改良するためにＤＭＶＲを実行し得る。たとえば、現在ブロックが８×８以下のサイズ、すなわち、８ピクセルよりも小さい幅もしくは高さ、または８×８ピクセルに厳密に等しいサイズを有する場合、動き補償ユニット２２４は、動きベクトルに対してＤＭＶＲを実行するのを回避してよく、予測ブロックを生成するために動きベクトルを使用してよい。そうではなく、ブロックが８×８よりも大きいサイズ（たとえば、少なくとも８×ＮまたはＮ×８というサイズ、ここで、Ｎは８よりも大きい整数である）を有する場合、動き補償ユニット２２４は、他の基準を使用して、動きベクトルに対してＤＭＶＲを実行すべきかどうかを決定し得る。ＤＭＶＲがイネーブルにされているとき、動き補償ユニット２２４は、上記で説明したようにＤＭＶＲを実行し得、次いで、改良された動きベクトルを使用して予測ブロックを生成し得る。
[0162]別の例として、イントラ予測またはイントラ予測コーディングに対して、イントラ予測ユニット２２６は、現在ブロックに隣接するサンプルから予測ブロックを生成し得る。たとえば、方向性モードの場合、イントラ予測ユニット２２６は、概して、隣接するサンプルの値を数学的に組み合わせてよく、予測ブロックを作り出すために、計算されたこれらの値を現在ブロックにわたる規定された方向で埋めてよい。別の例として、ＤＣモードの場合、イントラ予測ユニット２２６は、現在ブロックへの隣接するサンプルの平均を計算してよく、予測ブロックのサンプルごとにこの得られた平均を含むように、予測ブロックを生成してよい。
[0163]モード選択ユニット２０２は、残差生成ユニット２０４に予測ブロックを提供する。残差生成ユニット２０４は、現在ブロックの未加工のコーディングされていないバージョンをビデオデータメモリ２３０から、および予測ブロックをモード選択ユニット２０２から受信する。残差生成ユニット２０４は、現在ブロックと予測ブロックとの間のサンプルごとの差分を計算する。得られたサンプルごとの差分は、現在ブロックに対する残差ブロックを規定する。いくつかの例では、残差生成ユニット２０４はまた、残差差分パルスコード変調（ＲＤＰＣＭ：residual differential pulse code modulation）を使用して残差ブロックを生成するために、残差ブロックの中のサンプル値の間の差分を決定し得る。いくつかの例では、残差生成ユニット２０４は、２進減算を実行する１つまたは複数の減算器回路を使用して形成され得る。
[0164]モード選択ユニット２０２がＣＵをＰＵに区分する例では、各ＰＵは、ルーマ予測ユニットおよび対応するクロマ予測ユニットに関連し得る。ビデオエンコーダ２００およびビデオデコーダ３００は、様々なサイズを有するＰＵをサポートし得る。上記で示されるように、ＣＵのサイズとは、ＣＵのルーマコーディングブロックのサイズを指してよく、ＰＵのサイズとは、ＰＵのルーマ予測ユニットのサイズを指してよい。特定のＣＵのサイズが２Ｎ×２Ｎであると想定すると、ビデオエンコーダ２００は、イントラ予測に対して２Ｎ×２ＮまたはＮ×ＮというＰＵサイズと、インター予測に対して２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、または類似の対称的なＰＵサイズとを、サポートし得る。ビデオエンコーダ２００およびビデオデコーダ３００はまた、インター予測の場合、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮというＰＵサイズに対して非対称の区分をサポートし得る。
[0165]モード選択ユニット２０２がそれ以上ＣＵをＰＵに区分しない例では、各ＣＵは、ルーマコーディングブロックおよび対応するクロマコーディングブロックに関連し得る。上記のように、ＣＵのサイズとは、ＣＵのルーマコーディングブロックのサイズを指してよい。ビデオエンコーダ２００およびビデオデコーダ３００は、２Ｎ×２Ｎ、２Ｎ×Ｎ、またはＮ×２ＮというＣＵサイズをサポートし得る。
[0166]いくつかの例として、イントラブロックコピーモードコーディング、アフィンモードコーディング、および線形モデル（ＬＭ）モードコーディングなどの、他のビデオコーディング技法の場合、モード選択ユニット２０２は、コーディング技法に関連するそれぞれのユニットを介して、符号化中の現在ブロックに対する予測ブロックを生成する。パレットモードコーディングなどのいくつかの例では、モード選択ユニット２０２は、予測ブロックを生成しなくてよく、代わりに、選択されたパレットに基づいてブロックを再構成するための方式を示すシンタックス要素を生成し得る。そのようなモードでは、モード選択ユニット２０２は、符号化されるべきこれらのシンタックス要素をエントロピー符号化ユニット２２０に提供し得る。
[0167]上記で説明したように、残差生成ユニット２０４は、現在ブロックに対するビデオデータと、対応する予測ブロックとを受信する。残差生成ユニット２０４は、次いで、現在ブロックに対する残差ブロックを生成する。残差ブロックを生成するために、残差生成ユニット２０４は、予測ブロックと現在ブロックとの間のサンプルごとの差分を計算する。
[0168]変換処理ユニット２０６は、変換係数のブロック（本明細書で「変換係数ブロック」と呼ぶ）を生成するために、残差ブロックに１つまたは複数の変換を適用する。変換処理ユニット２０６は、変換係数ブロックを形成するために、残差ブロックに様々な変換を適用し得る。たとえば、変換処理ユニット２０６は、離散コサイン変換（ＤＣＴ）、方向性変換、カルーネンレーベ変換（ＫＬＴ）、または概念的に類似の変換を、残差ブロックに適用してよい。いくつかの例では、変換処理ユニット２０６は、複数の変換、たとえば、１次変換および回転変換などの２次変換を、残差ブロックに実行し得る。いくつかの例では、変換処理ユニット２０６は、残差ブロックに変換を適用しない。
[0169]量子化ユニット２０８は、量子化変換係数ブロックを作り出すために、変換係数ブロックの中の変換係数を量子化し得る。量子化ユニット２０８は、現在ブロックに関連する量子化パラメータ（ＱＰ：quantization parameter）値に従って変換係数ブロックの変換係数を量子化し得る。ビデオエンコーダ２００は（たとえば、モード選択ユニット２０２を介して）、ＣＵに関連するＱＰ値を調整することによって、現在ブロックに関連する係数ブロックに適用される量子化の程度を調整し得る。量子化は情報の損失を持ち込むことがあり、したがって、量子化変換係数は、変換処理ユニット２０６によって作り出される元の変換係数よりも精度が低いことがある。
[0170]逆量子化ユニット２１０および逆変換処理ユニット２１２は、変換係数ブロックから残差ブロックを再構成するために、それぞれ、逆量子化と逆変換とを量子化変換係数ブロックに適用し得る。再構成ユニット２１４は、再構成された残差ブロック、およびモード選択ユニット２０２によって生成された予測ブロックに基づいて、（潜在的にいくらかの程度のひずみを有するとしても）現在ブロックに対応する再構成されたブロックを作り出し得る。たとえば、再構成ユニット２１４は、再構成されたブロックを作り出すために、モード選択ユニット２０２によって生成された予測ブロックからの対応するサンプルに、再構成された残差ブロックのサンプルを加算してよい。
[0171]フィルタユニット２１６は、再構成されたブロックに対して１つまたは複数のフィルタ動作を実行し得る。たとえば、フィルタユニット２１６は、ＣＵのエッジに沿ったブロッキネスアーティファクトを低減するために、デブロッキング動作を実行してよい。いくつかの例では、フィルタユニット２１６の動作はスキップされてよい。
[0172]ビデオエンコーダ２００は、再構成されたブロックをＤＰＢ２１８の中に記憶する。たとえば、フィルタユニット２１６の動作が必要とされない例では、再構成ユニット２１４は、再構成されたブロックをＤＰＢ２１８に記憶し得る。フィルタユニット２１６の動作が必要とされる例では、フィルタユニット２１６は、フィルタ処理済みの再構成されたブロックをＤＰＢ２１８に記憶し得る。動き推定ユニット２２２および動き補償ユニット２２４は、その後に符号化されるピクチャのブロックをインター予測するために、再構成された（また潜在的にフィルタ処理された）ブロックから形成された参照ピクチャをＤＰＢ２１８から取り出し得る。加えて、イントラ予測ユニット２２６は、現在ピクチャの中の他のブロックをイントラ予測するために、現在ピクチャの、ＤＰＢ２１８の中の再構成されたブロックを使用し得る。
[0173]概して、エントロピー符号化ユニット２２０は、ビデオエンコーダ２００の他の機能構成要素から受信されたシンタックス要素をエントロピー符号化し得る。たとえば、エントロピー符号化ユニット２２０は、量子化ユニット２０８からの量子化変換係数ブロックをエントロピー符号化し得る。別の例として、エントロピー符号化ユニット２２０は、モード選択ユニット２０２からの予測シンタックス要素（たとえば、インター予測のための動き情報、またはイントラ予測のためのイントラモード情報）をエントロピー符号化し得る。エントロピー符号化ユニット２２０は、エントロピー符号化データを生成するために、ビデオデータの別の例であるシンタックス要素に対して、１つまたは複数のエントロピー符号化動作を実行し得る。たとえば、エントロピー符号化ユニット２２０は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）動作、ＣＡＢＡＣ動作、可変対可変（Ｖ２Ｖ）長コーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）動作、確率区間区分エントロピー（ＰＩＰＥ）コーディング動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作を、データに対して実行してよい。いくつかの例では、エントロピー符号化ユニット２２０は、シンタックス要素がエントロピー符号化されないバイパスモードで動作し得る。
[0174]ビデオエンコーダ２００は、スライスまたはピクチャのブロックを再構成するために必要とされるエントロピー符号化されたシンタックス要素を含むビットストリームを出力し得る。詳細には、エントロピー符号化ユニット２２０がビットストリームを出力してよい。
[0175]上記で説明した動作は、ブロックに関して説明される。そのような説明は、ルーマコーディングブロックおよび／またはクロマコーディングブロックのための動作であるものとして理解されるべきである。上記で説明したように、いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、ＣＵのルーマ成分およびクロマ成分である。いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、ＰＵのルーマ成分およびクロマ成分である。
[0176]いくつかの例では、ルーマコーディングブロックに関して実行される動作は、クロマコーディングブロックに対して繰り返される必要がない。一例として、ルーマコーディングブロックに対する動きベクトル（ＭＶ）と参照ピクチャとを識別するための動作は、クロマブロックに対するＭＶと参照ピクチャとを識別するために繰り返される必要がない。むしろ、クロマブロックに対するＭＶを決定するために、ルーマコーディングブロックに対するＭＶがスケーリングされ得、参照ピクチャが同じであってよい。別の例として、イントラ予測プロセスは、ルーマコーディングブロックおよびクロマコーディングブロックにとって同じであってよい。
[0177]このようにして、ビデオエンコーダ２００は、ビデオデータをコーディング（この例では、符号化および復号）するためのデバイスの一例を表し、デバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を行うように構成される。
[0178]図１５は、本開示の技法を実行し得る例示的なビデオデコーダ３００を示すブロック図である。図１５は説明のために提供され、本開示において広く例示および説明されるような技法における限定ではない。説明のために、本開示は、ＪＥＭおよびＨＥＶＣの技法によるビデオデコーダ３００を説明する。しかしながら、本開示の技法は、他のビデオコーディング規格に構成されるビデオコーディングデバイスによって実行され得る。
[0179]図１５の例では、ビデオデコーダ３００は、コード化ピクチャバッファ（ＣＰＢ：coded picture buffer）メモリ３２０と、エントロピー復号ユニット３０２と、予測処理ユニット３０４と、逆量子化ユニット３０６と、逆変換処理ユニット３０８と、再構成ユニット３１０と、フィルタユニット３１２と、復号ピクチャバッファ（ＤＰＢ）３１４とを含む。ＣＰＢメモリ３２０、エントロピー復号ユニット３０２、予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構成ユニット３１０、フィルタユニット３１２、およびＤＰＢ３１４のうちのいずれかまたはすべては、１つまたは複数のプロセッサまたは処理回路構成で実装され得る。その上、ビデオデコーダ３００は、これらおよび他の機能を実行するために、追加または代替のプロセッサまたは処理回路構成を含んでよい。
[0180]予測処理ユニット３０４は、動き補償ユニット３１６とイントラ予測ユニット３１８とを含む。予測処理ユニット３０４は、他の予測モードに従って予測を実行するために、追加のユニットを含んでよい。例として、予測処理ユニット３０４は、パレットユニット、（動き補償ユニット３１６の一部を形成し得る）イントラブロックコピーユニット、アフィンユニット、線形モデル（ＬＭ）ユニットなどを含んでよい。他の例では、ビデオデコーダ３００は、より多数の、より少数の、または異なる機能の、構成要素を含んでよい。
[0181]ＣＰＢメモリ３２０は、ビデオデコーダ３００の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。ＣＰＢメモリ３２０の中に記憶されるビデオデータは、たとえば、コンピュータ可読媒体１１０（図９）から取得され得る。ＣＰＢメモリ３２０は、符号化ビデオビットストリームからの符号化ビデオデータ（たとえば、シンタックス要素）を記憶するＣＰＢを含んでよい。また、ＣＰＢメモリ３２０は、ビデオデコーダ３００の様々なユニットからの出力を表す一時的なデータなどの、コード化ピクチャのシンタックス要素以外のビデオデータを記憶し得る。ＤＰＢ３１４は、概して、符号化ビデオビットストリームの後続のデータもしくはピクチャを復号するときに、ビデオデコーダ３００が参照ビデオデータとして出力および／または使用することがある、復号ピクチャを記憶する。ＣＰＢメモリ３２０およびＤＰＢ３１４は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスを含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの、様々なメモリデバイスのうちのいずれかによって形成され得る。ＣＰＢメモリ３２０およびＤＰＢ３１４は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、ＣＰＢメモリ３２０は、ビデオデコーダ３００の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってよい。
[0182]追加または代替として、いくつかの例では、ビデオデコーダ３００は、メモリ１２０（図９）からコード化ビデオデータを取り出してよい。すなわち、メモリ１２０は、ＣＰＢメモリ３２０とともに、上記で説明したようにデータを記憶し得る。同様に、メモリ１２０は、ビデオデコーダ３００の機能性の一部または全部が、ビデオデコーダ３００の処理回路構成によって実行されるべきソフトウェアで実装されるとき、ビデオデコーダ３００によって実行されるべき命令を記憶し得る。
[0183]図１５に示す様々なユニットは、ビデオデコーダ３００によって実行される動作を理解するのを支援するために図示される。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。図１４と同様に、固定機能回路とは、特定の機能性を提供する回路を指し、実行され得る動作において事前設定される。プログラマブル回路とは、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能性を提供する。たとえば、プログラマブル回路は、プログラマブル回路に、ソフトウェアまたはファームウェアの命令によって規定される方式で動作させる、ソフトウェアまたはファームウェアを実行し得る。固定機能回路は、（たとえば、パラメータを受信しパラメータを出力するための）ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは、一般に不変である。いくつかの例では、ユニットのうちの１つまたは複数は異なる回路ブロック（固定機能またはプログラマブル）であってよく、いくつかの例では、１つまたは複数のユニットは集積回路であってよい。
[0184]ビデオデコーダ３００は、ＡＬＵ、ＥＦＵ、デジタル回路、アナログ回路、および／またはプログラマブル回路から形成されたプログラマブルコアを含んでよい。ビデオデコーダ３００の動作が、プログラマブル回路上で実行するソフトウェアによって実行される例では、ビデオデコーダ３００が受信および実行するソフトウェアの命令（たとえば、オブジェクトコード）を、オンチップメモリまたはオフチップメモリが記憶し得る。
[0185]エントロピー復号ユニット３０２は、ＣＰＢから符号化ビデオデータを受信し得、シンタックス要素を再生するためにビデオデータをエントロピー復号し得る。予測処理ユニット３０４、逆量子化ユニット３０６、逆変換処理ユニット３０８、再構成ユニット３１０、およびフィルタユニット３１２は、ビットストリームから抽出されるシンタックス要素に基づいて復号ビデオデータを生成し得る。
[0186]概して、ビデオデコーダ３００は、ピクチャをブロックごとに再構成する。ビデオデコーダ３００は、各ブロックに対して再構成動作を個別に実行し得る（ここで、現在再構成中の、すなわち、復号中のブロックは、「現在ブロック」と呼ばれることがある）。
[0187]エントロピー復号ユニット３０２は、量子化変換係数ブロックの量子化変換係数ならびに量子化パラメータ（ＱＰ）および／または変換モード表示などの変換情報を規定する、シンタックス要素をエントロピー復号し得る。逆量子化ユニット３０６は、量子化の程度、および同様に、逆量子化ユニット３０６が適用すべき逆量子化の程度を決定するために、量子化変換係数ブロックに関連するＱＰを使用し得る。逆量子化ユニット３０６は、たとえば、量子化変換係数を逆量子化するために、ビット単位での左シフト演算を実行し得る。逆量子化ユニット３０６は、それによって、変換係数を含む変換係数ブロックを形成し得る。
[0188]逆量子化ユニット３０６が変換係数ブロックを形成した後、逆変換処理ユニット３０８は、現在ブロックに関連する残差ブロックを生成するために、変換係数ブロックに１つまたは複数の逆変換を適用し得る。たとえば、逆変換処理ユニット３０８は、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向性変換、または別の逆変換を、係数ブロックに適用してよい。
[0189]さらに、予測処理ユニット３０４は、エントロピー復号ユニット３０２によってエントロピー復号された予測情報シンタックス要素に従って、予測ブロックを生成する。たとえば、現在ブロックがインター予測されていることを予測情報シンタックス要素が示す場合、動き補償ユニット３１６は、予測ブロックを生成し得る。この場合、予測情報シンタックス要素は、参照ブロックをそこから取り出すためのＤＰＢ３１４の中の参照ピクチャ、ならびに現在ピクチャの中の現在ブロックのロケーションに対して、参照ピクチャの中の参照ブロックのロケーションを識別する、動きベクトルを示してよい。動き補償ユニット３１６は、概して、動き補償ユニット２２４（図１４）に関して説明したのと実質的に類似の方法で、インター予測プロセスを実行し得る。
[0190]本開示の技法によれば、動き補償ユニット３１６は、ビデオデータの現在ブロックに対してＤＭＶＲがイネーブルにされているとき、動きベクトルを改良するためにＤＭＶＲを実行し得る。たとえば、現在ブロックが８×８以下のサイズ、すなわち、８ピクセルよりも小さい幅もしくは高さ、または８×８ピクセルに厳密に等しいサイズを有する場合、動き補償ユニット３１６は、動きベクトルに対してＤＭＶＲを実行するのを回避し得、予測ブロックを生成するために動きベクトルを使用し得る。そうではなく、ブロックが８×８よりも大きいサイズ（たとえば、少なくとも８×ＮまたはＮ×８というサイズ、ただし、Ｎは８よりも大きい整数である）を有する場合、動き補償ユニット３１６は、他の基準を使用して、動きベクトルに対してＤＭＶＲを実行すべきかどうかを決定し得る。ＤＭＶＲがイネーブルにされているとき、動き補償ユニット３１６は、上記で説明したようにＤＭＶＲを実行し得、次いで、改良された動きベクトルを使用して予測ブロックを生成し得る。
[0191]別の例として、現在ブロックがイントラ予測されていることを予測情報シンタックス要素が示す場合、イントラ予測ユニット３１８は、予測情報シンタックス要素によって示されるイントラ予測モードに従って予測ブロックを生成し得る。再び、イントラ予測ユニット３１８は、概して、イントラ予測ユニット２２６（図１４）に関して説明したのと実質的に類似の方法で、イントラ予測プロセスを実行し得る。イントラ予測ユニット３１８は、現在ブロックへの隣接するサンプルのデータを、ＤＰＢ３１４から取り出し得る。
[0192]再構成ユニット３１０は、予測ブロックと残差ブロックとを使用して、現在ブロックを再構成し得る。たとえば、再構成ユニット３１０は、現在ブロックを再構成するために、残差ブロックのサンプルを予測ブロックの対応するサンプルに加算し得る。
[0193]フィルタユニット３１２は、再構成されたブロックに対して１つまたは複数のフィルタ動作を実行し得る。たとえば、フィルタユニット３１２は、再構成されたブロックのエッジに沿ったブロッキネスアーティファクトを低減するために、デブロッキング動作を実行してよい。フィルタユニット３１２の動作は、必ずしもすべての例において実行されるとは限らない。
[0194]ビデオデコーダ３００は、再構成されたブロックをＤＰＢ３１４の中に記憶し得る。たとえば、フィルタユニット３１２の動作が実行されない例では、再構成ユニット３１０は、再構成されたブロックをＤＰＢ３１４に記憶し得る。フィルタユニット３１２の動作が実行される例では、フィルタユニット３１２は、フィルタ処理済みの再構成されたブロックをＤＰＢ３１４に記憶し得る。上記で説明したように、ＤＰＢ３１４は、イントラ予測のための現在ピクチャのサンプル、および後続の動き補償のための以前に復号されたピクチャなどの、参照情報を、予測処理ユニット３０４に提供し得る。その上、ビデオデコーダ３００は、図１のディスプレイデバイス１１８などのディスプレイデバイス上での後続の提示のために、ＤＰＢから復号ピクチャを出力し得る。
[0195]このようにして、ビデオデコーダ３００は、ビデオデータをコーディング（この例では、復号）するためのデバイスの一例を表し、デバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有することを決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を行うように構成される。
[0196]図１６は、本開示の技法による、現在ブロックを符号化する例示的な方法を示すフローチャートである。現在ブロックは、現在ＣＵを備え得る。ビデオエンコーダ２００（図９および図１４）に関して説明されるが、他のデバイスが図１６の方法と類似の方法を実行するように構成され得ることを理解されたい。
[0197]この例では、ビデオエンコーダ２００は、最初に現在ブロックを予測する（３５０）。たとえば、ビデオエンコーダ２００は、現在ブロックに対する予測ブロックを形成し得る。ビデオエンコーダ２００は、予測ブロックを形成するとき、本開示のＤＭＶＲに関係する技法のうちのいずれかまたはすべてを実行し得る。いくつかの例では、ビデオエンコーダ２００は、上記で説明したように、デコーダ側動きベクトル改良（ＤＭＶＲ）を使用して、動き探索から決定された動きベクトルを改良し得る。詳細には、本開示の技法によれば、ビデオエンコーダ２００は、現在ブロックのサイズに少なくとも部分的に基づいて、ＤＭＶＲを実行すべきかどうかを決定し得る。現在ブロックが、８ピクセルよりも小さい幅もしくは高さのうちの少なくとも１つを有するか、または８ピクセルに等しい幅と高さの両方（すなわち、８×８ピクセルというサイズ）を有する場合、ビデオエンコーダ２００は、現在ブロックに対してＤＭＶＲを実行すべきでないと決定し得る。そうではなく、現在ブロックが少なくとも８×ＮまたはＮ×８というサイズを有する場合（ここにおいて、Ｎは８よりも大きい整数値である）、ビデオエンコーダ２００は、ＤＭＶＲを実行すべきと決定し得、または追加の基準に基づいて、現在ブロックに対してＤＭＶＲを実行すべきかどうかを決定し得る。ビデオエンコーダ２００は、次いで、予測ブロックを形成するために、ＤＭＶＲを使用して潜在的に改良される、動きベクトルを使用し得る。
[0198]ビデオエンコーダ２００は、次いで、現在ブロックに対する残差ブロックを計算し得る（３５２）。残差ブロックを計算するために、ビデオエンコーダ２００は、コーディングされていない元のブロックと現在ブロックに対する予測ブロックとの間の差分を計算し得る。ビデオエンコーダ２００は、次いで、残差ブロックの係数を変換および量子化し得る（３５４）。次に、ビデオエンコーダ２００は、残差ブロックの量子化変換係数を走査し得る（３５６）。走査の間、または走査に続いて、ビデオエンコーダ２００は、係数をエントロピー符号化し得る（３５８）。たとえば、ビデオエンコーダ２００は、ＣＡＶＬＣまたはＣＡＢＡＣを使用して係数を符号化し得る。ビデオエンコーダ２００は、次いで、ブロックの係数に対するエントロピーコード化データを出力し得る（３６０）。
[0199]このようにして、図１６は、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディングする（すなわち、符号化する）方法の一例を表す。
[0200]図１７は、本開示の技法による、現在ブロックを復号する例示的な方法を示すフローチャートである。現在ブロックは、現在ＣＵを備え得る。ビデオデコーダ３００（図９および図１５）に関して説明されるが、他のデバイスが図１７の方法と類似の方法を実行するように構成され得ることを理解されたい。
[0201]ビデオデコーダ３００は、エントロピーコード化予測情報、および現在ブロックに対応する残差ブロックの係数に対するエントロピーコード化データなどの、現在ブロックに対するエントロピーコード化データを受信し得る（３７０）。ビデオデコーダ３００は、現在ブロックに対する予測情報を決定し残差ブロックの係数を再生するために、エントロピーコード化データをエントロピー復号し得る（３７２）。ビデオデコーダ３００は、現在ブロックに対する予測ブロックを計算するために、たとえば、現在ブロックに対する予測情報によって示されるようなインター予測モードを使用して、現在ブロックを予測し得る（３７４）。
[0202]ビデオデコーダ３００は、予測ブロックを形成するとき、本開示のＤＭＶＲに関係する技法のうちのいずれかまたはすべてを実行し得る。いくつかの例では、ビデオデコーダ３００は、上記で説明したように、デコーダ側動きベクトル改良（ＤＭＶＲ）を使用して、決定された復号動きベクトルを改良し得る。詳細には、本開示の技法によれば、ビデオデコーダ３００は、現在ブロックのサイズに少なくとも部分的に基づいて、ＤＭＶＲを実行すべきかどうかを決定し得る。現在ブロックが、８ピクセルよりも小さい幅もしくは高さのうちの少なくとも１つを有するか、または８ピクセルに等しい幅と高さの両方（すなわち、８×８ピクセルというサイズ）を有する場合、ビデオデコーダ３００は、現在ブロックに対してＤＭＶＲを実行すべきでないと決定し得る。そうではなく、現在ブロックが、少なくとも８×ＮまたはＮ×８というサイズを有する場合（ここにおいて、Ｎは８よりも大きい整数値である）、ビデオデコーダ３００は、ＤＭＶＲを実行すべきと決定し得る、または追加の基準に基づいて、現在ブロックに対してＤＭＶＲを実行すべきかどうかを決定し得る。ビデオデコーダ３００は、次いで、予測ブロックを形成するために、ＤＭＶＲを使用して潜在的に改良される、動きベクトルを使用し得る。
[0203]ビデオデコーダ３００は、次いで、量子化変換係数のブロックを作成するために、再生された係数を逆走査し得る（３７６）。ビデオデコーダ３００は、次いで、残差ブロックを作り出すために、係数を逆量子化および逆変換し得る（３７８）。ビデオデコーダ３００は、予測ブロックと残差ブロックとを組み合わせることによって、最終的に現在ブロックを復号し得る（３８０）。
[0204]このようにして、図１７は、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディングする（すなわち、復号する）方法の一例を表す。
[0205]図１８は、本開示の技法による、ビデオデータのブロックをコーディングする方法の一例を示すフローチャートである。図１８の方法は、ビデオエンコーダ２００またはビデオデコーダ３００などの、ビデオコーディングデバイスによって実行され得る。例として、図１８の方法はビデオデコーダ３００に関して説明されるが、ビデオエンコーダ２００などの他のビデオコーディングデバイスが、この方法または類似の方法を実行し得る。
[0206]最初に、ビデオデコーダ３００は、ブロックのサイズを決定する（４００）。たとえば、ビデオデコーダ３００は、木構造の中の分割を決定するために、コーディングツリーユニット（ＣＴＵ）に関連する木構造を復号し得、最終的に木構造のリーフノードを識別する。分割の数、ツリータイプ、および分割のタイプを使用して、ビデオデコーダ３００は、ブロックのサイズ、たとえば、ピクセルの単位でのブロックの幅と高さとを決定し得る。ビデオエンコーダ２００によって実行されるとき、ビデオエンコーダ２００は、最良のパフォーマンスのレートひずみ値をもたらすＣＴＵの区分を決定するために、様々な異なるブロックサイズとＣＴＵの区分パターンとをテストすることによってブロックのサイズを決定し得る。
[0207]ビデオデコーダ３００は、次いで、ブロックの幅が８ピクセルよりも小さいか、ブロックの高さが８ピクセルよりも小さいか、それともブロックのサイズが８×８に等しいかのいずれかを決定し得る（４８２）。これらのうちのいずれかが真である場合（４０２の「ＹＥＳ」分岐）、ビデオデコーダ３００は、ブロックがＤＭＶＲを使用してコーディングされないと決定し得る（４０４）。したがって、ビデオデコーダ３００は、たとえば、ブロックを復号することによって、ブロックに対する動きベクトルを決定することに進み得（４０６）、次いで、動きベクトルを使用してブロックに対する予測ブロックを生成してよい（４０８）。
[0208]一方、ブロックが、幅または高さのうちの少なくとも１つが８ピクセルよりも大きくて少なくとも８×８というサイズ（すなわち、少なくとも８×ＮまたはＮ×８というサイズ、ただし、Ｎは８よりも大きい整数である）を有する場合（４０２の「ＮＯ」分岐）、ビデオデコーダ３００は、たとえば、サイズの決定に基づいて、および／または追加の基準を使用して、ブロックに対してＤＭＶＲを実行すべきと決定し得る（４１０）。いくつかの例では、他の基準は、ＤＭＶＲが実行されないことになることを示し得る。ビデオデコーダ３００は、ブロックに対する動きベクトルを決定し得（４１２）、ＤＭＶＲがイネーブルにされることを他の基準が示す場合、動きベクトルに対してＤＭＶＲを実行し得（４１４）、（潜在的に改良された）動きベクトルを使用して予測ブロックを生成し得る（４１６）。
[0209]いずれの場合も（すなわち、ステップ４０８または４１６のいずれかに続いて）、ビデオデコーダ３００は、次いで、予測ブロックを使用してブロックをコーディング（すなわち、この例では復号）し得る（４１８）。
[0210]このようにして、図１８は、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することと、ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい幅および高さのうちの、少なくとも１つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、ブロックに対してＤＭＶＲを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディング（符号化または復号）する方法の一例を表す。
[0211]例に応じて、本明細書で説明した技法のいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る（たとえば、説明したすべての行為またはイベントが本技法の実践のために必要であるとは限らない）ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して並行して実行され得る。
[0212]１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶またはコンピュータ可読媒体を介して送信されてよく、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に相当するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含んでよい。このようにして、コンピュータ可読媒体は、概して、（１）非一時的な有形コンピュータ可読記憶媒体、または（２）信号もしくは搬送波などの通信媒体に相当し得る。データ記憶媒体は、本開示で説明した技法の実施のための命令、コード、および／またはデータ構造を取り出すために、１つもしくは複数のコンピュータまたは１つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含んでよい。
[0213]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ－ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的な有形の記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）、およびＢｌｕ－ｒａｙディスク（disc）を含み、ここで、ディスク（disk）は通常、データを磁気的に再生し、ディスク（disc）は、レーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
[0214]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他の均等な集積論理回路構成もしくは個別論理回路構成などの、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」および「処理回路構成」という用語は、上記の構造または本明細書で説明した技法の実装にとって好適な任意の他の構造のうちのいずれかを指してよい。加えて、いくつかの態様では、本明細書で説明する機能性は、符号化および復号のために構成された専用ハードウェアおよび／もしくはソフトウェアモジュール内で提供されてよく、または組み合わせられたコーデックの中に組み込まれてよい。また、本技法は、１つまたは複数の回路または論理要素で十分に実装され得る。
[0215]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置で実装され得る。開示する技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが本開示で説明されるが、異なるハードウェアユニットによる実現を必ずしも必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明したような１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットの中で組み合わせられてよく、または相互動作可能なハードウェアユニットの集合によって提供されてよい。
[0216]様々な例が説明されている。これらおよび他の例は、以下の特許請求の範囲内に入る。

Claims (37)

  1. ビデオデータをコーディングする方法であって、
    ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの少なくとも１つを有すると決定することと、
    ビデオデータの前記ブロックが、８ピクセルよりも小さい前記幅、８ピクセルよりも小さい前記高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも１つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、
    前記ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、前記ブロックに対してＤＭＶＲを実行することなく前記ブロックをコーディングすることと、
    を備える方法。
  2. 前記ブロックは、第１のブロックを備え、前記方法は、
    ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定することと、ここにおいて、Ｎは８よりも大きい整数値であり、
    ビデオデータの前記第２のブロックが少なくとも８×ＮまたはＮ×８という前記サイズを有すると決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすべきかどうかを決定することと、
    ＤＭＶＲを使用して前記第２のブロックをコーディングすべきと決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすることと、をさらに備える、
    請求項１に記載の方法。
  3. 前記第２のブロックをコーディングすることは、
    前記第２のブロックが双方向オプティカルフロー（ＢＩＯ）を使用して予測されることになるとき、前記第２のブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
    前記パディングされたフィルタ入力サンプルを使用して、前記第２のブロックの１つまたは複数のサンプルに対する１つまたは複数の勾配値を計算することと、
    前記勾配値を使用して、前記第２のブロックの前記１つまたは複数のサンプルに対する１つまたは複数の改良された動きベクトルを計算することと、
    前記１つまたは複数の改良された動きベクトルを使用して、前記第２のブロックに対する予測ブロックを生成することと、を備える、
    請求項２に記載の方法。
  4. 前記第２のブロックは、ｗサンプルの幅とｈサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから（ｗ＋７）＊（ｈ＋７）サンプルを取り出すことと、前記取り出されたサンプルを（ｗ＋７＋２ｄ）＊（ｈ＋７＋２ｄ）というサイズにパディングすることと、を備え、ここにおいて、ｄは、予め定義された最大変位ベクトルを表す、請求項３に記載の方法。
  5. 前記１つまたは複数の勾配値を計算することは、Ｌという長さを有する勾配フィルタを使用して前記１つまたは複数の勾配値を計算することを備え、
    前記第２のブロックは、ｗサンプルの幅とｈサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから（ｗ＋７）＊（ｈ＋７）サンプルを取り出すことと、前記取り出されたサンプルを（ｗ＋７＋２ｄ＋２ｓ）＊（ｈ＋７＋２ｄ＋２ｓ）というサイズにパディングすることと、を備え、ここにおいて、ｄは、予め定義された最大変位ベクトルを表し、ｓは、Ｌの半分を表す、請求項３に記載の方法。
  6. 前記第２のブロックは、ｗサンプルの幅とｈサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、
    前記参照ピクチャから（ｗ＋７）＊（ｈ＋７）サンプルを取り出すことと、
    前記取り出されたサンプルを（ｗ＋１１）＊（ｈ＋７）というサイズに水平にパディングすることと、
    前記パディングされたサンプルを（ｗ＋１１－ｔ）＊（ｈ＋７）というサイズに水平に補間することと、
    前記水平に補間されパディングされたサンプルを（ｗ＋１１－ｔ）＊（ｈ＋１１）というサイズに垂直にパディングすることと、を備える、
    請求項３に記載の方法。
  7. 前記第２のブロックに対する初期動きベクトルを復号することをさらに備え、
    前記１つまたは複数の改良された動きベクトルを計算することは、前記初期動きベクトルを使用して、前記１つまたは複数の改良された動きベクトルを計算することを備える、請求項３に記載の方法。
  8. 前記ブロックをコーディングすることは、
    前記ブロックに対する動きベクトルを復号することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックに対する残差ブロックを復号することと、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を備える、
    請求項１に記載の方法。
  9. 前記ブロックをコーディングすることは、
    前記ブロックに対する動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を備える、
    請求項１に記載の方法。
  10. 前記ブロックをコーディングすることは、
    前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックの右上の隣接ブロックの改良された動きベクトルを取り出すことと、
    前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  11. 前記ブロックをコーディングすることは、
    前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックに隣接する仮想パイプラインデータユニット（ＶＰＤＵ）の改良された動きベクトルを取り出すことと、ここにおいて、前記ＶＰＤＵは、コーディングツリーユニット（ＣＴＵ）の４つのＶＰＤＵのうちの１つを備え、前記４つのＶＰＤＵは、前記ＣＴＵの均等に分割された４分の１のブロックであり、
    前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  12. 前記ブロックをコーディングすることは、
    前記ブロックの動きベクトルに対する１つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測（ＨＭＶＰ）リストを生成することと、
    改良された動きベクトルを使用して以前のブロックを復号することに応答して、前記ＨＭＶＰリストの中への前記改良された動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがディセーブルにされることを示し、
    前記ＨＭＶＰリストの前記動きベクトル予測子候補のうちの１つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  13. 前記ブロックをコーディングすることは、
    前記ブロックの動きベクトルに対する１つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測（ＨＭＶＰ）リストを生成することと、
    改良された制御点動きベクトルを使用して以前のブロックを復号することに応答して、前記ＨＭＶＰリストの中への前記改良された制御点動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがイネーブルにされることを示し、
    前記ＨＭＶＰリストの前記動きベクトル予測子候補のうちの１つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  14. 前記ブロックをコーディングすることは、
    前記ブロックの因果的隣接サブブロックから、前記ブロックの動きベクトルに対するアフィンマージ候補を決定することを備え、ここにおいて、前記アフィンマージ候補を決定することは、
    前記因果的隣接サブブロックが、前記ブロックを含むコーディングツリーユニット（ＣＴＵ）行の上の隣接ＣＴＵ行の中にあるとき、前記アフィンマージ候補として、前記因果的隣接サブブロックの改良された動きベクトルを選択すること、または
    前記因果的隣接サブブロックが、前記ブロックを含む前記ＣＴＵ行の中にあるとき、前記アフィンマージ候補として、前記改良された動きベクトルを生成するために使用される未改良の動きベクトルを選択することと、
    前記アフィンマージ候補を使用して、前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  15. 前記ブロックをコーディングすることは、
    コスト関数を使用してコスト値を計算するために使用される重み値に適用されるべき正の整数スカラー（ｓ）値を決定することと、
    前記コスト関数、および前記ｓ値を使用して、前記ブロックの予測ブロックのサンプルに対する前記コスト値を計算することと、
    一般化双予測（ＧＢｉ）または重み付き双予測（ＷＰ）のうちの少なくとも１つに従って、前記コスト値を使用して前記予測ブロックを生成することと、を備える、
    請求項１に記載の方法。
  16. 前記ｓ値を決定することは、
    ＧＢｉに対して、ｓ＝８を決定すること、
    ルーマＷＰに対して、ｓ＝２luma_log2_weight_denom+Max(2,14-LumaBitDepth)を決定すること、または
    クロマＷＰに対して、ｓ＝
    ２luma_log2_weight_denom+delta_chroma_log2_weight_denom+Max(2,14-ChromaBitDepth)
    を決定すること、を備える、
    請求項１５に記載の方法。
  17. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    回路の中に実装された１つまたは複数のプロセッサと、
    を備え、前記１つまたは複数のプロセッサは、
    ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの少なくとも１つを有すると決定することと、
    ビデオデータの前記ブロックが、８ピクセルよりも小さい前記幅、８ピクセルよりも小さい前記高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも１つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、
    前記ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、前記ブロックに対してＤＭＶＲを実行することなく前記ブロックをコーディングすることと、
    を行うように構成される、
    デバイス。
  18. 前記ブロックは、第１のブロックを備え、
    前記１つまたは複数のプロセッサは、
    ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定することと、ここにおいて、Ｎが８よりも大きい整数値であり、
    ビデオデータの前記第２のブロックが少なくとも８×ＮまたはＮ×８という前記サイズを有すると決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすべきかどうかを決定することと、
    ＤＭＶＲを使用して前記第２のブロックをコーディングすべきと決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすることと、
    を行うようにさらに構成される、
    請求項１７に記載のデバイス。
  19. 前記第２のブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記第２のブロックが双方向オプティカルフロー（ＢＩＯ）を使用して予測されることになるとき、前記第２のブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
    前記パディングされたフィルタ入力サンプルを使用して、前記第２のブロックの１つまたは複数のサンプルに対する１つまたは複数の勾配値を計算することと、
    前記勾配値を使用して、前記第２のブロックの前記１つまたは複数のサンプルに対する１つまたは複数の改良された動きベクトルを計算することと、
    前記１つまたは複数の改良された動きベクトルを使用して、前記第２のブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１８に記載のデバイス。
  20. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックに対する動きベクトルを復号することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックに対する残差ブロックを復号することと、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を行うように構成される、
    請求項１７に記載のデバイス。
  21. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックに対する動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を行うように構成される、
    請求項１７に記載のデバイス。
  22. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックの右上の隣接ブロックの改良された動きベクトルを取り出すことと、
    前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  23. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックに隣接する仮想パイプラインデータユニット（ＶＰＤＵ）の改良された動きベクトルを取り出すことと、ここにおいて、前記ＶＰＤＵは、コーディングツリーユニット（ＣＴＵ）の４つのＶＰＤＵのうちの１つを備え、前記４つのＶＰＤＵは、前記ＣＴＵの均等に分割された４分の１のブロックであり、
    前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  24. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックの動きベクトルに対する１つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測（ＨＭＶＰ）リストを生成することと、
    改良された動きベクトルを使用して以前のブロックを復号することに応答して、前記ＨＭＶＰリストの中への前記改良された動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがディセーブルにされることを示し、
    前記ＨＭＶＰリストの前記動きベクトル予測子候補のうちの１つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  25. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックの動きベクトルに対する１つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測（ＨＭＶＰ）リストを生成することと、
    改良された制御点動きベクトルを使用して以前のブロックを復号することに応答して、前記ＨＭＶＰリストの中への前記改良された制御点動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがイネーブルにされることを示し、
    前記ＨＭＶＰリストの前記動きベクトル予測子候補のうちの１つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  26. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    前記ブロックの因果的隣接サブブロックから、前記ブロックの動きベクトルに対するアフィンマージ候補を決定するように構成され、ここにおいて、前記アフィンマージ候補を決定するために、前記１つまたは複数のプロセッサは、
    前記因果的隣接サブブロックが、前記ブロックを含むコーディングツリーユニット（ＣＴＵ）行の上の隣接ＣＴＵ行の中にあるとき、前記アフィンマージ候補として、前記因果的隣接サブブロックの改良された動きベクトルを選択すること、または
    前記因果的隣接サブブロックが、前記ブロックを含む前記ＣＴＵ行の中にあるとき、前記アフィンマージ候補として、前記改良された動きベクトルを生成するために使用される未改良の動きベクトルを選択することと、
    前記アフィンマージ候補を使用して、前記動きベクトルをコーディングすることと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  27. 前記ブロックをコーディングするために、前記１つまたは複数のプロセッサは、
    コスト関数を使用してコスト値を計算するために使用される重み値に適用されるべき正の整数スカラー（ｓ）値を決定することと、
    前記コスト関数、および前記ｓ値を使用して、前記ブロックの予測ブロックのサンプルに対する前記コスト値を計算することと、
    一般化双予測（ＧＢｉ）または重み付き双予測（ＷＰ）のうちの少なくとも１つに従って、前記コスト値を使用して前記予測ブロックを生成することと、を行うように構成される、
    請求項１７に記載のデバイス。
  28. 前記ビデオデータを表示するように構成されたディスプレイをさらに備える、請求項１７に記載のデバイス。
  29. カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、またはセットトップボックスのうちの１つまたは複数を備える、請求項１７に記載のデバイス。
  30. 命令が記憶されたコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
    ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの少なくとも１つを有すると決定することと、
    ビデオデータの前記ブロックが、８ピクセルよりも小さい前記幅、８ピクセルよりも小さい前記高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも１つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定することと、
    前記ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、前記ブロックに対してＤＭＶＲを実行することなく前記ブロックをコーディングすることと、
    を行わせる、
    コンピュータ可読記憶媒体。
  31. 前記ブロックは、第１のブロックを備え、
    前記コンピュータ可読記憶媒体は、さらに、前記プロセッサに、
    ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定することと、ここにおいて、Ｎは８よりも大きい整数値であり、
    ビデオデータの前記第２のブロックが少なくとも８×ＮまたはＮ×８という前記サイズを有することを決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすべきかどうかを決定することと、
    ＤＭＶＲを使用して前記第２のブロックをコーディングすべきと決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすることと、
    を行わせる命令を備える、
    請求項３０に記載のコンピュータ可読記憶媒体。
  32. 前記プロセッサに前記ブロックをコーディングさせる前記命令は、前記プロセッサに、
    前記ブロックに対する動きベクトルを復号することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックに対する残差ブロックを復号することと、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を行わせる命令を備える、
    請求項３０に記載のコンピュータ可読記憶媒体。
  33. 前記プロセッサに前記ブロックをコーディングさせる前記命令は、前記プロセッサに、
    前記ブロックに対する動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を行わせる命令を備える、
    請求項３０に記載のコンピュータ可読記憶媒体。
  34. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータのブロックが、８ピクセルよりも小さい幅、８ピクセルよりも小さい高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの少なくとも１つを有すると決定するための手段と、
    ビデオデータの前記ブロックが、８ピクセルよりも小さい前記幅、８ピクセルよりも小さい前記高さ、または８ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも１つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良（ＤＭＶＲ）を使用してコーディングされないと決定するための手段と、
    前記ブロックがＤＭＶＲを使用してコーディングされないと決定することに応答して、前記ブロックに対してＤＭＶＲを実行することなく前記ブロックをコーディングするための手段と、
    を備えるデバイス。
  35. 前記ブロックは、第１のブロックを備え、前記デバイスは、
    ビデオデータの第２のブロックが少なくとも８×ＮまたはＮ×８というサイズを有すると決定するための手段と、ここにおいて、Ｎは８よりも大きい整数値であり、
    ビデオデータの前記第２のブロックが少なくとも８×ＮまたはＮ×８という前記サイズを有すると決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングすべきかどうかを決定するための手段と、
    ＤＭＶＲを使用して前記第２のブロックをコーディングすべきと決定することに応答して、ＤＭＶＲを使用して前記第２のブロックをコーディングするための手段と、をさらに備える、
    請求項３４に記載のデバイス。
  36. 前記ブロックをコーディングするための前記手段は、
    前記ブロックに対する動きベクトルを復号するための手段と、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算するための手段と、
    前記ブロックに対する残差ブロックを復号するための手段と、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせるための手段と、を備える、
    請求項３４に記載のデバイス。
  37. 前記ブロックをコーディングするための前記手段は、
    前記ブロックに対する動きベクトルを生成するための手段と、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算するための手段と、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成するための手段と、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化するための手段と、を備える、
    請求項３４に記載のデバイス。
JP2021527074A 2018-11-27 2019-11-27 デコーダ側動きベクトル改良 Active JP7446297B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862771960P 2018-11-27 2018-11-27
US62/771,960 2018-11-27
US16/695,907 US11146810B2 (en) 2018-11-27 2019-11-26 Decoder-side motion vector refinement
US16/695,907 2019-11-26
PCT/US2019/063673 WO2020113051A2 (en) 2018-11-27 2019-11-27 Decoder-side motion vector refinement

Publications (3)

Publication Number Publication Date
JP2022507683A true JP2022507683A (ja) 2022-01-18
JPWO2020113051A5 JPWO2020113051A5 (ja) 2022-11-08
JP7446297B2 JP7446297B2 (ja) 2024-03-08

Family

ID=68966058

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021527074A Active JP7446297B2 (ja) 2018-11-27 2019-11-27 デコーダ側動きベクトル改良

Country Status (9)

Country Link
US (1) US11146810B2 (ja)
EP (1) EP3888358A2 (ja)
JP (1) JP7446297B2 (ja)
KR (1) KR20210093259A (ja)
CN (2) CN113039787B (ja)
BR (1) BR112021009606A2 (ja)
CL (1) CL2021001335A1 (ja)
SG (1) SG11202104085RA (ja)
WO (1) WO2020113051A2 (ja)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210297659A1 (en) 2018-09-12 2021-09-23 Beijing Bytedance Network Technology Co., Ltd. Conditions for starting checking hmvp candidates depend on total number minus k
JP2022516191A (ja) * 2019-01-10 2022-02-24 北京字節跳動網絡技術有限公司 Ｌｕｔ更新の起動
US11528501B2 (en) 2018-06-29 2022-12-13 Beijing Bytedance Network Technology Co., Ltd. Interaction between LUT and AMVP
US11528500B2 (en) 2018-06-29 2022-12-13 Beijing Bytedance Network Technology Co., Ltd. Partial/full pruning when adding a HMVP candidate to merge/AMVP
US11641483B2 (en) 2019-03-22 2023-05-02 Beijing Bytedance Network Technology Co., Ltd. Interaction between merge list construction and other tools
US11695921B2 (en) 2018-06-29 2023-07-04 Beijing Bytedance Network Technology Co., Ltd Selection of coded motion information for LUT updating
US11877002B2 (en) 2018-06-29 2024-01-16 Beijing Bytedance Network Technology Co., Ltd Update of look up table: FIFO, constrained FIFO
US11895318B2 (en) 2018-06-29 2024-02-06 Beijing Bytedance Network Technology Co., Ltd Concept of using one or multiple look up tables to store motion information of previously coded in order and use them to code following blocks
US11909951B2 (en) 2019-01-13 2024-02-20 Beijing Bytedance Network Technology Co., Ltd Interaction between lut and shared merge list
US11909989B2 (en) 2018-06-29 2024-02-20 Beijing Bytedance Network Technology Co., Ltd Number of motion candidates in a look up table to be checked according to mode
US11956464B2 (en) 2019-01-16 2024-04-09 Beijing Bytedance Network Technology Co., Ltd Inserting order of motion candidates in LUT
US11973971B2 (en) 2018-06-29 2024-04-30 Beijing Bytedance Network Technology Co., Ltd Conditions for updating LUTs
US12034914B2 (en) 2018-06-29 2024-07-09 Beijing Bytedance Network Technology Co., Ltd Checking order of motion candidates in lut

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110677667B (zh) 2018-07-02 2022-06-07 北京字节跳动网络技术有限公司 查找表的使用
JP7005480B2 (ja) * 2018-12-27 2022-01-21 Kddi株式会社 画像復号装置、画像符号化装置、プログラム及び画像処理システム
US11102476B2 (en) * 2018-12-28 2021-08-24 Qualcomm Incorporated Subblock based affine motion model
US11431987B2 (en) * 2019-01-08 2022-08-30 Tencent America LLC Method and apparatus for memory bandwidth reduction for small inter blocks
WO2020156538A1 (en) 2019-02-03 2020-08-06 Beijing Bytedance Network Technology Co., Ltd. Interaction between mv precisions and mv difference coding
DK3909247T3 (da) * 2019-02-08 2024-04-15 Beijing Dajia Internet Information Tech Co Ltd Fremgangsmåde og indretning til selektiv anvendlse af decodersidig bevægelsesvektorforfining til videokodning
CN117336505A (zh) * 2019-02-14 2024-01-02 北京字节跳动网络技术有限公司 解码器侧细化工具的尺寸选择性应用
KR102597617B1 (ko) * 2019-02-26 2023-11-03 애플 인크. 영상 신호 부호화/복호화 방법 및 이를 위한 장치
US11166015B2 (en) * 2019-03-06 2021-11-02 Tencent America LLC Method and apparatus for video coding
CA3132582A1 (en) * 2019-03-07 2020-09-10 Digitalinsights Inc. Image encoding/decoding method and apparatus
MX2021010770A (es) 2019-03-08 2021-09-28 Sharp Kk Aparato de decodificacion de video.
US20200402546A1 (en) * 2019-06-24 2020-12-24 Seagate Technology Llc Reducing base deck porosity
WO2021001220A1 (en) * 2019-07-01 2021-01-07 Interdigital Vc Holdings France, Sas Bi-directional optical flow refinement of affine motion compensation
BR112022002493A2 (pt) 2019-08-10 2022-04-26 Beijing Bytedance Network Tech Co Ltd Método e aparelho para processamento de vídeo, e, mídia legível por computador com código armazenado na mesma
KR20220059549A (ko) * 2019-09-30 2022-05-10 후아웨이 테크놀러지 컴퍼니 리미티드 향상된 보간 필터로써 하나의 블록 행의 처리 동안 페치되는 참조 라인의 수를 감소시키는 아핀 모션 모델 제약
CN114631321B (zh) 2019-10-18 2024-04-12 北京字节跳动网络技术有限公司 子图片与环路滤波之间的相互影响
US11399188B2 (en) * 2020-01-01 2022-07-26 Tencent America LLC Method for mixed NAL unit type support in a coded picture
EP4107941A4 (en) * 2020-03-23 2023-04-19 Beijing Bytedance Network Technology Co., Ltd. PREDICTION REFINEMENT FOR AFFINE MERGE AND AFFINER MOTION VECTOR PREDICTION MODE
CN116158078A (zh) * 2020-08-07 2023-05-23 交互数字Vc控股法国有限公司 将abt与基于vvc子块的编码工具组合
CN116368799A (zh) * 2020-10-15 2023-06-30 北京达佳互联信息技术有限公司 用于帧间编解码的增强型运动估计
US12212736B2 (en) * 2021-06-30 2025-01-28 Qualcomm Incorporated Using unrefined motion vectors for performing decoder-side motion vector derivation
WO2023027564A1 (ko) * 2021-08-27 2023-03-02 주식회사 윌러스표준기술연구소 움직임 정보를 보정하는 방법 및 이를 위한 장치
CN118592027A (zh) * 2021-11-22 2024-09-03 抖音视界有限公司 用于视频处理的方法、装置和介质
US11616970B1 (en) * 2022-01-25 2023-03-28 Mediatek Inc. Motion vector refinement apparatus having motion vector predictor derivation circuit that is allowed to start new task without waiting for motion vector difference computation and associated motion vector refinement method
US20240040141A1 (en) * 2022-07-18 2024-02-01 Tencent America LLC Method for affine motion refinement
CN117579833B (zh) * 2024-01-12 2024-04-05 合肥六角形半导体有限公司 一种视频压缩电路及芯片

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190132606A1 (en) * 2017-11-02 2019-05-02 Mediatek Inc. Method and apparatus for video coding

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BRPI0818444A2 (pt) * 2007-10-12 2016-10-11 Qualcomm Inc codificação adaptativa de informação de cabeçalho de bloco de vídeo
US8208563B2 (en) * 2008-04-23 2012-06-26 Qualcomm Incorporated Boundary artifact correction within video units
US9503720B2 (en) * 2012-03-16 2016-11-22 Qualcomm Incorporated Motion vector coding and bi-prediction in HEVC and its extensions
WO2017197146A1 (en) * 2016-05-13 2017-11-16 Vid Scale, Inc. Systems and methods for generalized multi-hypothesis prediction for video coding
US20170339405A1 (en) * 2016-05-20 2017-11-23 Arris Enterprises Llc System and method for intra coding
US11638027B2 (en) * 2016-08-08 2023-04-25 Hfi Innovation, Inc. Pattern-based motion vector derivation for video coding
US10750203B2 (en) * 2016-12-22 2020-08-18 Mediatek Inc. Method and apparatus of adaptive bi-prediction for video coding
WO2018113658A1 (en) * 2016-12-22 2018-06-28 Mediatek Inc. Method and apparatus of motion refinement for video coding
US10911761B2 (en) * 2016-12-27 2021-02-02 Mediatek Inc. Method and apparatus of bilateral template MV refinement for video coding
US12063387B2 (en) * 2017-01-05 2024-08-13 Hfi Innovation Inc. Decoder-side motion vector restoration for video coding
US20180199057A1 (en) * 2017-01-12 2018-07-12 Mediatek Inc. Method and Apparatus of Candidate Skipping for Predictor Refinement in Video Coding
US20180332298A1 (en) * 2017-05-10 2018-11-15 Futurewei Technologies, Inc. Bidirectional Prediction In Video Compression
US10602180B2 (en) 2017-06-13 2020-03-24 Qualcomm Incorporated Motion vector prediction
US10477237B2 (en) * 2017-06-28 2019-11-12 Futurewei Technologies, Inc. Decoder side motion vector refinement in video coding
WO2019072373A1 (en) 2017-10-09 2019-04-18 Huawei Technologies Co., Ltd. UPDATING MODELS FOR REFINING MOTION VECTORS
US11558633B2 (en) 2017-11-01 2023-01-17 Vid Scale, Inc. Sub-block motion derivation and decoder-side motion vector refinement for merge mode
US11310526B2 (en) 2018-01-26 2022-04-19 Mediatek Inc. Hardware friendly constrained motion vector refinement
TWI719519B (zh) * 2018-07-02 2021-02-21 大陸商北京字節跳動網絡技術有限公司 對於dmvr的塊尺寸限制
US10958934B2 (en) * 2018-07-27 2021-03-23 Tencent America LLC History-based affine merge and motion vector prediction

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190132606A1 (en) * 2017-11-02 2019-05-02 Mediatek Inc. Method and apparatus for video coding

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHAO-HSIUNG HUNG, WEI-JUNG CHIEN, AND MARTA KARCZEWICZ: "CE9: BIO gradient calculation improvement (Test 9.5.4)", JOINT VIDEO EXPLORATION TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-K0119, JPN6023037744, July 2018 (2018-07-01), pages 1 - 3, ISSN: 0005150181 *
HONGBIN LIU, ET AL.: "CE9: Simplification of Decoder Side Motion Vector Derivation (Test 9.2.9)", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-L0267-v1, JPN6023037747, September 2018 (2018-09-01), pages 1 - 4, ISSN: 0005150178 *
SEMIH ESENLIK, ET AL.: "CE9: Report on the results of tests CE9.2.15 and CE9.2.16", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-L0163, JPN6023037745, October 2018 (2018-10-01), pages 1 - 7, ISSN: 0005150180 *
TADAMASA TOMA, ET AL.: "Description of SDR video coding technology proposal by Panasonic", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-J0020-v1, JPN6023037746, April 2018 (2018-04-01), pages 10 - 11, ISSN: 0005150179 *

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11973971B2 (en) 2018-06-29 2024-04-30 Beijing Bytedance Network Technology Co., Ltd Conditions for updating LUTs
US11895318B2 (en) 2018-06-29 2024-02-06 Beijing Bytedance Network Technology Co., Ltd Concept of using one or multiple look up tables to store motion information of previously coded in order and use them to code following blocks
US11909989B2 (en) 2018-06-29 2024-02-20 Beijing Bytedance Network Technology Co., Ltd Number of motion candidates in a look up table to be checked according to mode
US12167018B2 (en) 2018-06-29 2024-12-10 Beijing Bytedance Network Technology Co., Ltd. Interaction between LUT and AMVP
US12058364B2 (en) 2018-06-29 2024-08-06 Beijing Bytedance Network Technology Co., Ltd. Concept of using one or multiple look up tables to store motion information of previously coded in order and use them to code following blocks
US12034914B2 (en) 2018-06-29 2024-07-09 Beijing Bytedance Network Technology Co., Ltd Checking order of motion candidates in lut
US11695921B2 (en) 2018-06-29 2023-07-04 Beijing Bytedance Network Technology Co., Ltd Selection of coded motion information for LUT updating
US11706406B2 (en) 2018-06-29 2023-07-18 Beijing Bytedance Network Technology Co., Ltd Selection of coded motion information for LUT updating
US11877002B2 (en) 2018-06-29 2024-01-16 Beijing Bytedance Network Technology Co., Ltd Update of look up table: FIFO, constrained FIFO
US11528501B2 (en) 2018-06-29 2022-12-13 Beijing Bytedance Network Technology Co., Ltd. Interaction between LUT and AMVP
US11528500B2 (en) 2018-06-29 2022-12-13 Beijing Bytedance Network Technology Co., Ltd. Partial/full pruning when adding a HMVP candidate to merge/AMVP
US20210297659A1 (en) 2018-09-12 2021-09-23 Beijing Bytedance Network Technology Co., Ltd. Conditions for starting checking hmvp candidates depend on total number minus k
US11997253B2 (en) 2018-09-12 2024-05-28 Beijing Bytedance Network Technology Co., Ltd Conditions for starting checking HMVP candidates depend on total number minus K
JP7275286B2 (ja) 2019-01-10 2023-05-17 北京字節跳動網絡技術有限公司 Ｌｕｔ更新の起動
US11589071B2 (en) 2019-01-10 2023-02-21 Beijing Bytedance Network Technology Co., Ltd. Invoke of LUT updating
JP2022516191A (ja) * 2019-01-10 2022-02-24 北京字節跳動網絡技術有限公司 Ｌｕｔ更新の起動
JP7572499B2 (ja) 2019-01-10 2024-10-23 北京字節跳動網絡技術有限公司 Ｌｕｔ更新の起動
US11909951B2 (en) 2019-01-13 2024-02-20 Beijing Bytedance Network Technology Co., Ltd Interaction between lut and shared merge list
US11962799B2 (en) 2019-01-16 2024-04-16 Beijing Bytedance Network Technology Co., Ltd Motion candidates derivation
US11956464B2 (en) 2019-01-16 2024-04-09 Beijing Bytedance Network Technology Co., Ltd Inserting order of motion candidates in LUT
US11641483B2 (en) 2019-03-22 2023-05-02 Beijing Bytedance Network Technology Co., Ltd. Interaction between merge list construction and other tools

Also Published As

Publication number Publication date
CN113039787A (zh) 2021-06-25
JP7446297B2 (ja) 2024-03-08
WO2020113051A2 (en) 2020-06-04
KR20210093259A (ko) 2021-07-27
SG11202104085RA (en) 2021-06-29
CN113039787B (zh) 2024-06-21
US20200169748A1 (en) 2020-05-28
US11146810B2 (en) 2021-10-12
EP3888358A2 (en) 2021-10-06
CL2021001335A1 (es) 2021-12-03
WO2020113051A3 (en) 2020-07-23
CN118741148A (zh) 2024-10-01
BR112021009606A2 (pt) 2021-08-10

Similar Documents

Publication Publication Date Title
CN113039787B (zh) 解码器侧运动矢量细化
TWI846765B (zh) 以歷史為基礎之運動向量預測之簡化
CN113678452B (zh) 对解码器侧运动矢量细化的约束
CN112703740B (zh) 用于仿射模式的基于历史的运动矢量预测
CN110771164B (zh) 视频译码中的帧间预测与帧内预测的组合
CN112840646B (zh) 仿射运动预测
CN113196749B (zh) 用于译码视频数据的方法和设备
CN113383552B (zh) 用于视频译码中的帧内块复制模式的运动向量预测值列表生成
JP7504925B2 (ja) ビデオコーディングのための組み合わされたインターおよびイントラ予測モード
TWI843809B (zh) 用於視訊寫碼中具有運動向量差之合併模式之信令傳輸
CN112806012A (zh) 用于帧间预测译码的基于历史的运动向量预测
CN113748679A (zh) 用于视频编解码的帧内块复制合并数据语法
CN113170185B (zh) 用于视频译码的空间-时间运动向量预测模式
CN112534820A (zh) 信令通知子预测单元运动矢量预测器
CN112640451A (zh) 矢量预测器列表生成
CN114402608A (zh) 视频编解码中bdof和dmvr的协调早期终止
JP2024508216A (ja) ビデオコーディングのためのモデルベースの動きベクトル差分導出およびテンプレート照合予測
CN114073079A (zh) 带有运动信息采集缓冲器的运动矢量预测
CN114009039B (zh) 视频译码中的时间运动矢量预测候选的推导
CN114009039A (zh) 视频译码中的时间运动矢量预测候选的推导

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221028

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221028

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20230104

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230912

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231211

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240130

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240227

R150 Certificate of patent or registration of utility model

Ref document number: 7446297

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150