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

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

Info

Publication number
JP7446297B2
JP7446297B2 JP2021527074A JP2021527074A JP7446297B2 JP 7446297 B2 JP7446297 B2 JP 7446297B2 JP 2021527074 A JP2021527074 A JP 2021527074A JP 2021527074 A JP2021527074 A JP 2021527074A JP 7446297 B2 JP7446297 B2 JP 7446297B2
Authority
JP
Japan
Prior art keywords
block
dmvr
motion vector
samples
video
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.)
Active
Application number
JP2021527074A
Other languages
English (en)
Other versions
JP2022507683A (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

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • H04N19/521Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/563Motion estimation with padding, i.e. with filling of non-object values in an arbitrarily shaped picture block or region for estimation purposes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/117Filters, e.g. for pre-processing or post-processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/12Selection 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/122Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/136Incoming video signal characteristics or properties
    • H04N19/137Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/176Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/523Motion estimation or motion compensation with sub-pixel accuracy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/573Motion compensation with multiple frame prediction using two or more reference frames in a given prediction direction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/577Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/80Details 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)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

優先権の主張
[0001]本出願は、2019年11月26日に出願された米国出願第16/695,907号、および2018年11月27日に出願された米国仮出願第62/771,960号の利益を主張し、その内容全体が参照により本明細書に組み込まれる。
[0002]本開示は、ビデオ符号化とビデオ復号とを含む、ビデオコーディングに関する。
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタルレコーディングデバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲーム機、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、幅広いデバイスの中に組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4、パート10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、高効率ビデオコーディング(HEVC:High Efficiency Video Coding)規格、ITU-T H.265/高効率ビデオコーディング(HEVC)によって規定される規格、およびそのような規格の拡張において記載されるものなどの、ビデオコーディング技法を実施する。ビデオデバイスは、そのようなビデオコーディング技法を実施することによって、より効率的にデジタルビデオ情報を送信、受信、符号化、復号、および/または記憶し得る。
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間(イントラピクチャ)予測および/または時間(インターピクチャ)予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス(たとえば、ビデオピクチャまたはビデオピクチャの一部分)は、コーディングツリーユニット(CTU:coding tree unit)、コーディングユニット(CU:coding unit)、および/またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコード化(I)スライスの中のビデオブロックは、同じピクチャの中の隣接ブロックの中の参照サンプルを基準にした空間予測を使用して符号化される。ピクチャのインターコード化(PまたはB)スライスの中のビデオブロックは、同じピクチャの中の隣接ブロックの中の参照サンプルを基準にした空間予測、または他の参照ピクチャの中の参照サンプルを基準にした時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
[0005]概して、本開示は、デコーダ側動きベクトル改良(DMVR:decoder-side motion vector refinement)を改善するための技法を説明する。それは、HEVC(高効率ビデオコーディング:High Efficiency Video Coding)もしくはVVC(多用途ビデオコーディング:Versatile Video Coding)などの既存のビデオコーデックのうちのいずれかに適用されてよく、またはいかなる将来のビデオコーディング規格においても効率的なコーディングツールであり得る。たとえば、ビデオエンコーダおよびビデオデコーダなどのビデオコーディングデバイスは、DMVRをその上で実行すべきブロックサイズにおける制約を伴って構成されることがある。詳細には、ブロックが、8ピクセルよりも小さい幅もしくは高さ、または8×8ピクセルに等しいサイズを有する場合、DMVRは回避されてよい。そうでない場合、少なくとも8×NまたはN×8というサイズを有するブロックに対して(ただし、Nは8よりも大きい整数である)、DMVRは実行され得る。
[0006]一例では、ビデオデータをコーディングする方法は、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を含む。
[0007]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された1つまたは複数のプロセッサとを含み、1つまたは複数のプロセッサは、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を行うように構成される。
[0008]別の例では、コンピュータ可読記憶媒体は命令を記憶し、該命令は、実行されたとき、プロセッサに、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を行わせる。
[0009]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定するための手段と、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定するための手段と、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングするための手段と、を含む。
[0010]1つまたは複数の例の詳細が、添付図面および以下の説明において記載される。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかとなろう。
[0011]動きベクトル予測のための空間的な隣接候補を示す概念図。 動きベクトル予測のための空間的な隣接候補を示す概念図。 [0012]時間的な動きベクトル予測を示す概念図。 時間的な動きベクトル予測を示す概念図。 [0013]マージ動きベクトル改良を表す概念図。 マージ動きベクトル改良を表す概念図。 [0014]オフセットマージ候補の例を示す概念図。 [0015]双方向テンプレートマッチングの一例を示す概念図。 双方向テンプレートマッチングの一例を示す概念図。 [0016]デコーダ側動きベクトル導出(DMVD:decoder-side motion vector derivation)のためのステージの例示的なパイプラインを示す概念図。 [0017]双方向オプティカルフロー(BIO:bi-directional optical flow)のための例示的なオプティカルフロー軌跡を示す概念図。 [0018]8×4ブロックに対するBIOの間の勾配計算の一例を示す概念図。 [0019]本開示の技法を実行し得る例示的なビデオ符号化および復号システムを示すブロック図。 [0020]改良された動きベクトルを使用してBIOを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図。 改良された動きベクトルを使用してBIOを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図。 [0021]コーディングツリーユニット(CTU)を横断する仮想パイプラインデータユニット(VPDU:virtual pipeline data unit)の例示的な処理順序を示す概念図。 [0022]水平補間に対して水平パディングしか使用されない技法を示す概念図。 [0023]例示的な4分木2分木(QTBT:quadtree binary tree)構造と、対応するコーディングツリーユニット(CTU)とを示す概念図。 例示的な4分木2分木(QTBT)構造と、対応するコーディングツリーユニット(CTU)とを示す概念図。 [0024]本開示の技法を実行し得る例示的なビデオエンコーダを示すブロック図。 [0025]本開示の技法を実行し得る例示的なビデオデコーダを示すブロック図。 [0026]本開示の技法による、現在ブロックを符号化する例示的な方法を示すフローチャート。 [0027]本開示の技法による、現在ブロックを復号する例示的な方法を示すフローチャート。 [0028]本開示の技法による、ビデオデータのブロックをコーディングする方法の一例を示すフローチャート。
[0029]ビデオコーディング規格は、そのスケーラブルビデオコーディング(SVC:Scalable Video Coding)とマルチビュービデオコーディング(MVC:Multi-view Video Coding)拡張とを含む、ITU-T H.261、ISO/IEC MPEG-1ビジュアルと、ITU-T H.262またはISO/IEC MPEG-2ビジュアルと、ITU-T H.263、ISO/IEC MPEG-4ビジュアルと、ITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)と、を含む。
[0030]加えて、その範囲拡張と、マルチビュー拡張(MV-HEVC)と、スケーラブル拡張(SHVC)とを含む、高効率ビデオコーディング(HEVC)またはITU-T H.265が、ビデオコーディング共同研究部会(JCT-VC)ならびにITU-Tビデオコーディングエキスパートグループ(VCEG:Video Coding Experts Group)とISO/IECモーションピクチャエキスパートグループ(MPEG:Motion Picture Experts Group)との3Dビデオコーディング拡張開発共同研究部会(JCT-3V)によって開発されている。以下でHEVC WDと呼ばれるHEVCドラフト仕様は、phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zipから入手可能である。
[0031]ITU-T VCEG(Q6/16)およびISO/IEC MPEG(JTC1/SC29/WG11)は、(スクリーンコンテンツコーディングおよび高ダイナミックレンジコーディングのためのその現在の拡張と短期での拡張とを含む)現在のHEVC規格の圧縮能力を著しく上回る圧縮能力を有する将来のビデオコーディング技術の標準化に対する潜在的なニーズを現在研究している。そのグループは、このエリアにおけるそれらの専門家によって提案された圧縮技術設計を評価するために、共同ビデオ探求部会(JVET:Joint Video Exploration Team)と呼ばれる共同探求作業においてこの探求活動に関して協働している。JVETは、最初に2015年10月19日~21日の間に開かれた。あるバージョンの参照ソフトウェア、すなわち、共同探求モデル7(JEM7:Joint Exploration Model 7)は、jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-7.0/からダウンロードされ得る。JEM7のアルゴリズム説明は、phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3286から入手可能である。
[0032]HEVCでは、スライスの中の最大のコーディングユニットは、コーディングツリーブロック(CTB:coding tree block)またはコーディングツリーユニット(CTU)と呼ばれる。CTBは、そのノードがコーディングユニットである4分木を含む。CTBのサイズは、HEVCメインプロファイルにおいて16×16から64×64までにわたることができる(ただし、技術的に8×8のCTBサイズがサポートされ得る)。コーディングユニット(CU)は、8×8くらいまで小さい同じサイズのCTBであり得る。各コーディングユニットは、1つのモード、すなわち、インターモードまたはイントラモードを用いてコーディングされる。CUは、インターコーディングされるとき、2つもしくは4つの予測ユニット(PU:prediction unit)にさらに区分されてよく、またはさらなる区分が適用されないとき、たった1つのPUになってもよい。1つのCUの中に2つのPUが存在するとき、それらは半分のサイズの長方形、またはCUの1/4もしくは3/4のサイズを有する2つの長方形サイズであり得る。CUがインターコーディングされるとき、各PUは、固有のインター予測モードとともに導出される、動き情報の1つのセットを有する。
[0033]HEVC規格では、予測ユニット(PU)に対して、それぞれ、マージモード(スキップはマージの特別な事例と見なされる)および高度動きベクトル予測(AMVP:advanced motion vector prediction)モードと称する、2つのインター予測モードがある。AMVPモードまたはマージモードのいずれかにおいて、複数の動きベクトル予測子に対して動きベクトル(MV:motion vector)候補リストが保持される。現在PUの、(1つまたは複数の)動きベクトル、ならびにマージモードにおける参照インデックスは、MV候補リストから1つの候補を取ることによって生成される。MV候補リストは、マージモード用の5つまでの候補と、AMVPモード用の2つのみの候補とを含む。マージ候補は、動き情報のセット、たとえば、両方の参照ピクチャリスト(リスト0およびリスト1)に対応する動きベクトルと、参照インデックスとを含み得る。マージインデックスによってマージ候補が識別される場合、現在ブロックの予測のために使用される参照ピクチャならびに関連する動きベクトルが決定される。一方、AMVPモードの下では、リスト0またはリスト1のいずれかからの各可能な予測方向について、AMVP候補が1つの動きベクトルしか含まないので、MV候補リストへのMV予測子(MVP:MV predictor)インデックスと一緒に、参照インデックスが明示的にシグナリングされる必要がある。AMVPモードでは、予測される動きベクトルがさらに改良され得る。両方のモードのための候補は、同じ空間的および時間的な隣接ブロックから同様に導出される。
[0034]図1Aおよび図1Bは、動きベクトル予測のための空間的な隣接候補を示す概念図である。詳細には、図1Aは、マージモードのための空間的な隣接候補の例を示し、図1Bは、高度動きベクトル予測(AMVP)モードのための空間的な隣接候補の例を示す。特定のPU(PU0)に対して、図1Aおよび図1Bに示す隣接ブロックから空間的なMV候補が導出されるが、ブロックから候補を生成するための方法は、マージモードおよびAMVPモードに対して異なる。HEVCのマージモードでは、4つまでの空間的なMV候補が、図1Aに番号で示される順序で導出され得、その順序は、以下の通り、すなわち、左(0,A1)、上(1,B1)、右上(2,B0)、左下(3,A0)、および左上(4,B2)である。
[0035]AVMPモードでは、隣接ブロックは、図1Bに示すように、2つのグループ、すなわち、ブロック0と1とを含む左グループ、およびブロック2と3と4とを含む上グループに分割される。各グループについて、シグナリングされる参照インデックスによって示されるのと同じ参照ピクチャを参照する、隣接ブロックの中の可能な候補が、グループの最終候補を形成するために選ばれるべき最高の優先度を有する。すべての隣接ブロックが、同じ参照ピクチャを指し示す動きベクトルを含むとは限らない可能性がある。したがって、そのような候補が見つけられ得ない場合、最初の利用可能な候補は最終候補を形成するようにスケーリングされ、したがって、時間距離差分が補償され得る。
[0036]図2Aおよび図2Bは、時間的な動きベクトル予測を示す概念図である。詳細には、図2Aは、時間動きベクトル予測(TMVP:temporal motion vector prediction)候補を示し、図2Bは、動きベクトルスケーリングを示す。TMVP候補は、イネーブルにされ利用可能な場合、HEVCにおける空間的な動きベクトル候補の後にMV候補リストの中へ追加され得る。TMVP候補に対する動きベクトル導出のプロセスは、マージモードとAMVPモードの両方に対して同じである。ただし、マージモードにおけるTMVP候補に対するターゲット参照インデックスは、HEVCごとに常に0に設定される。
[0037]TMVP候補導出のための主要なブロックロケーションは、空間的な隣接候補を生成するために使用される上および左のブロックへのバイアスを補償するために、ブロック「T」として図2Aに示すような、コロケートPUの外部の右下のブロックである。しかしながら、そのブロックが現在CTB行の外部に位置するか、または動き情報が利用可能でない場合、ブロックはPUの中心ブロックで置換されてよい。
[0038]TMVP候補に対する動きベクトルは、スライスレベルにおいて示される、コロケートピクチャのコロケートPUから導出され得る。コロケートPUに対する動きベクトルは、コロケートMVと呼ばれる。AVCにおける時間ダイレクトモードと同様に、TMVP候補動きベクトルを導出するために、コロケートMVは、図2Bに示すように、時間距離差分を補償するためにスケーリングされる必要があり得る。
[0039]図3Aおよび図3Bは、マージ動きベクトル改良を表す概念図である。JVET-L0054では、シグナリングされる動きベクトル差分に基づいてマージ候補の動きベクトルを改良するために、マージ動きベクトル改良(MMVR、最終動きベクトル表現、UMVEとも呼ばれる)が提示される。MMVRは、開始ポイントと、動きの大きさと、動き方向とを含む、簡略化されたシグナリングを用いて、代替の動きベクトル表現を提供する。マージ動きは、未改良のマージ動きベクトルによって指し示されるロケーションを中心とする十字形パターン上の、図3Bにおける図示のオフセットのうちの1つを使用して改良され得る。加えて、リストL0の中の参照ピクチャを指し示すMVオフセット(すなわち、改良されたMV-元のMV)は、リストL1の中の参照ピクチャにスケーリングされる。
[0040]図4は、オフセットマージ候補の例を示す概念図である。JVET-L0176では、新たな拡張されたMVオフセット候補が、マージ候補リストの第1の候補に基づいて構成される。新たな拡張されたMVオフセット候補は、第1の候補の現在MVへのMVオフセットしか有さず、他の予測情報は第1の候補と同じである。新たに追加される候補は、時間的な候補の後にマージ候補リストへ押し込まれる。サポートされる動きベクトルオフセットが図4に示され、オフセット(0または±1,0または±1)を伴う水平および垂直の影付き点と、オフセット(0または±2,0または±2)を伴う対角の影付き点とを含む。
[0041]過去における参照ピクチャからの1つのMV(すなわち、MV0)および未来の事例における参照ピクチャからの別のMV(すなわち、MV1)を用いた双予測の場合、ビデオコーダは、選択されたMVオフセットを第1の候補MV0に加え、逆のMVオフセットを第1の候補MV1に加え得る。他の双予測事例では、ビデオコーダは、同じMVオフセットを、それぞれ、第1の候補MV0およびMV1に加え得る。
[0042]履歴ベース動きベクトル予測(HMVP:history-based motion vector prediction)(JVET-K0104において記載される)とは、各ブロックが、すぐ隣り合う因果的隣接動きフィールドの中のMVに加えて、過去から復号されたMVのリストから、そのMV予測子を見つけることを可能にする、履歴ベースの方法である。符号化/復号プロセスの間、複数のHMVP候補を有するテーブルが保持される。新たなスライスに遭遇すると、テーブルは空にされる。インターコード化ブロックがあるときはいつでも、関連する動き情報は、新たなHMVP候補として先入れ先出し(FIFO)方式でテーブルに挿入される。次いで、制約付きFIFO規則が適用され得る。テーブルにHMVPを挿入するとき、テーブルの中に同一のHMVPがあるかどうかを見つけるために、最初に冗長性チェックが適用される。見つかった場合、その特定のHMVPがテーブルから除去され、以後のすべてのHMVP候補は移動される。
[0043]HMVP候補は、マージ候補リスト構成プロセスにおいて使用され得る。テーブルの中の最後のエントリから最初のエントリまでのすべてのHMVP候補が、TMVP候補の後に挿入される。HMVP候補に対してプルーニングが適用される。利用可能なマージ候補の総数が、シグナリングされた最大許容マージ候補に到達すると、マージ候補リスト構成プロセスは終了する。
[0044]同様に、HMVP候補は、AMVP候補リスト構成プロセスにおいても使用され得る。テーブルの中の最後のK個のHMVP候補の動きベクトルは、TMVP候補の後に挿入される。AMVPターゲット参照ピクチャと同じ参照ピクチャを有するHMVP候補だけが、AMVP候補リストを構成するために使用される。HMVP候補に対してプルーニングが適用される。
[0045]マージモードおよび/またはAMVPモードの間、動きベクトルスケーリングが実行され得る。動きベクトルの値がプレゼンテーション時間におけるピクチャの距離に比例することが想定される。動きベクトルは、2つのピクチャ、すなわち、参照ピクチャと、動きベクトルを含むピクチャ(すなわち、含有(containing)ピクチャ)とを関連付ける。ある動きベクトルが、他の動きベクトルを予測するために利用されるとき、含有ピクチャと参照ピクチャとの距離は、ピクチャ順序カウント(POC:Picture Order Count)値に基づいて計算される。
[0046]予測されるべき動きベクトルにとって、その関連する含有ピクチャおよび参照ピクチャは異なってよい。したがって、(POCに基づく)新たな距離が計算され得る。そして、動きベクトルは、これらの2つのPOC距離に基づいてスケーリングされ得る。空間的な隣接候補にとって、2つの動きベクトルに対する含有ピクチャは同じであるが、参照ピクチャは異なる。HEVCでは、空間的および時間的な隣接候補に対してTMVPとAMVPの両方に動きベクトルスケーリングが適用される。
[0047]マージモードおよび/またはAMVPモードの間、擬似(artificial)動きベクトル候補生成も実行され得る。動きベクトル候補リストが完全でない場合、擬似動きベクトル候補が生成され得、リストが所定の個数の候補を有するまでリストの末尾に挿入され得る。
[0048]HEVCのマージモードでは、2つのタイプの擬似MV候補、すなわち、Bスライスのみに対して導出される組合せ候補と、第1のタイプが十分な擬似候補を提供しない場合、AMVPのみに対して使用されるゼロ候補がある。すでに候補リストの中にあり必要な動き情報を有する候補の各ペアについて、双方向組合せ動きベクトル候補が、リスト0の中のピクチャを参照する第1の候補の動きベクトルと、リスト1の中のピクチャを参照する第2の候補の動きベクトルとの組合せによって導出される。
[0049]候補挿入のためのプルーニングプロセスは、HEVCのマージモードおよび/またはAMVPモードの間に実行され得る。異なるブロックからの候補がたまたま同じである場合があり、そのことはマージ/AMVP候補リストの効率を下げることがある。プルーニングプロセスは、この問題を解決するために適用され得る。このプロセスは、同一の候補を挿入することをある程度まで回避するために、現在の候補リストの中で、ある候補を他の候補に対して比較する。計算量を低減するために、可能な各候補をすべての他の既存の候補と比較するのではなく、限られた数のプルーニングプロセスしか適用されない。
[0050]図5Aおよび図5Bは、双方向テンプレートマッチングの一例を示す概念図である。双方向マッチングは、テンプレートベースの改良プロセスを回避し得る、DMVR技法の変形形態である。この技法は、初期双予測MV(たとえば、図5Aおよび図5Bの中のv0およびv1)によって指し示される単予測参照ブロック(I0(x+v0)およびI1(x+v1)、ならびに現在ブロック内のピクセルの座標としてのxとして示す)の間で双方向マッチングコストを直接算出する。初期双予測MVの周囲の事前定義された探索範囲内での双方向マッチングに基づいて、局所的な探索が実行される。詳細には、初期MVが、最初の探索反復においてv0 (0)およびv1 (0)、いくつかのMVペア(たとえば、v0 (0)+Δおよびv1 (0)-Δ、ただし、Δ∈(0,0),(-1,1),(0,1),(1,1),(1,0),(1,-1),(0,-1),(-1,-1),(-1,0)など}である)と仮定すると、最小の双方向マッチングコストをもたらすことができる最適なΔ*を見つけ出す。この案では、コスト関数は、I0(x+v0 (0)+Δ)とI1(x+v1 (0)-Δ)との間のひずみ+動きコストとして定義される。ひずみ関数は、絶対差分和(SAD:sum of absolute difference)または平均除去SAD(MRSAD:Mean Removed SAD)のいずれかであり得る。
[0051]最適なΔ*が見つけられた後、反復プロセスは、Δ*を使用することによって初期MV(v0 (0)およびv1 (0))を更新する。詳細には、我々は、v0 (1)=v0 (0)+Δ*と、v1 (1)=v1 (0)-Δ*)とを有する。次いで、上の説明におけるすべての上付き文字を1だけ進めた後、Δ*が(0,0)に等しいことが到達されるまで、同じ反復プロセスが繰り返す。出力MVペア(v0 (n)およびv1 (n)として示し、n≧1である)が、次いで、サブペル精度で再び改良され得る。得られるMVペアは、次いで、マージブロックの元のMV(v0 (0)およびv1 (0))を置き換えるために使われる。最後に、改良されたMV(たとえば、図5Bの中のv0’およびv1’)に基づいて動き補償が実行される。
[0052]JVET-K0041では、可能な分数ペルMVごとに予測誤差曲面(prediction error surface)を形成するために、2次パラメトリック関数が使用される。基本的に、それは推定量としての予測誤差の値を補間する補間関数である。整数探索からの厳密な予測誤差値に基づいて、2次パラメトリック関数のパラメータが導出され、したがって、この誤差探索における最良の動きサンプリングロケーションが見つけられ得る。次いで、実際にサブペル動きベクトル推定を実行する代わりに、元の(original)MVがこの厳密な動きサンプリングロケーションに調整される。このパラメトリック関数は、誤差曲面を形成しこの面上で最小コスト値を有する最良の位置を見つけるための参照として5つの点からコスト値を取る。5つの点は十字形を形成し、隣り合う2つの各点の間のギャップは2ピクセルであり、ここで、中心/左/右/上/下の点は、(0,0)/(-1,0)/(1,0)/(0,-1)/(0,1)に合わせられる。
[0053]いくつかの例では、このパラメトリック誤差曲面関数は、2D放物線誤差曲面方程式、すなわち、
であり、ここで、(Δx,Δy)は最小コストを有する位置に相当し、Cは最小コスト値に相当する。
[0054]5つの方程式を5つの未知数で解くことによって、(Δx,Δy)は、
のように算出され得、ここで、αは(Δx,Δy)をいくつかのサブペル精度で表すために導入された整数スケーリング係数、たとえば、1/16の精度に対して16、および1/4の精度に対して4である。
[0055]動きオーバーヘッドを低減する際にDMVDは効率的であるが、(DMVRなどの)既存のDMVD設計は、空間的な隣接CUのコーディングの間の相互依存性に起因する復号レイテンシ問題に遭遇することがある。CUのMVが、DMVRを使用することによってコーディングされたその空間的なネイバーから予測される場合、その復号プロセスは、隣接CUの改良されたMVが利用可能になるまで待たなければならない。新たなコーディング規格、すなわち、多用途ビデオコーディングの開発において、いくつかのデコーダ側MV導出(DMVD)手法のための低レイテンシ設計を達成するための、本開示のいくつかの技法がある。
[0056]本開示の技法は、DMVRおよびDMVDの性能を改善するために使用され得る。たとえば、DMVRが適用されるブロックに、サイズ制約が課されることがある。詳細には、DMVRは、8×8ピクセルよりも大きいサイズを有するブロックに制約されることがある。すなわち、ブロックの1つの寸法(ブロックの幅または高さ)が8ピクセルに等しい場合、ブロックに対してDMVRを実行するために、直交する寸法は8ピクセルよりも大きくなるべきである。このようにしてDMVRを制約することによって、ブロックコーディングプロセスは、ひずみに悪影響を及ぼすことなく改善され得る。
[0057]図6は、デコーダ側動きベクトル導出(DMVD)のためのステージの例示的なパイプラインを示す概念図である。DMVDを使用してコーディングされるブロックに対して、復号プロセスは、3つのステップ、すなわち、(1)初期動きフィールドの再構成、および参照ブロックをプリフェッチすること、(2)最終MVを得るための、ブロック動きに対する改良プロセス、ならびに(3)最終MVを用いた動き補償、で解実行され得る。
[0058]ステップ2における改良プロセスの後、最終MVがピクチャ動きフィールドに書き戻され、そのため、空間的なMV予測、時間的なMV予測、および境界強度計算に関して、改良されたMVが使用され得る。図6は、デコーダ側MV改良(DMVR)などのDMVD方法のためのパイプラインステージのいくつかの実装形態を示す。図6において、3つの主要モジュールが、DMVD方法のための3つの復号ステップを表す。
[0059]第1に、CUprevは、現在のCU(CUcur)の前の、以前にコーディングされたCUである。CUcurのオリジナルの(元の)MVを再構成するとき、MV予測子が、たまたまDMVDコード化ブロックであるCUprevからである場合、この予測子は、CUcurにとって利用不可能としてマークされる。したがって、CUcurの初期MVの再構成は、もはやCUprevの改良されたMVに依存せず、MV改良とMV予測との間の相互依存性は、ある程度まで除去される。
[0060]改良されたMVを使用するのではなく、いくつかの例では、各DMVR CUのオリジナルのMVが、空間的なMV予測子を導出するために使用され得る。時間的なMV予測の場合、コロケートピクチャが完全に再構成されているので、改良されたMVは復号レイテンシ問題を伴わずに使用され得る。したがって、空間的な隣接CUの間のコーディング依存性がもはや存在しないので、DMVRの復号レイテンシ問題は完全に解決され得る。しかしながら、コーディングパフォーマンスの減退が予想され得る。
[0061]いくつかの例では、現在ブロックと一緒にこれらの隣接ブロックがすべて同じCTU行の中に落ちる場合、空間的なMV予測を実行するために、直接隣接するブロックからの参照として、未改良のMVが使用され得る。(いくつかの他の技法が、そのような隣接ブロックからのMV予測子に、利用不可能としてマークする場合があることに留意されたい)。反対に、それらの関連するブロックが、すぐ上のCTUおよび左上のCTUに位置する隣接する因果的CTU内に落ちるときのみ、改良されたMVは、空間的なMV予測に対して利用可能であり得る。したがって、いくつかの例は、CTU行の内側で、MV改良と空間的なMV予測との間の相互依存性を壊す。
[0062]図7は、双方向オプティカルフロー(BIO)のための例示的なオプティカルフロー軌跡を示す概念図である。BIOとは、双予測の事例においてブロック単位の動き補償の上部で実行される、ピクセル単位の動き改良である。BIOがブロックの内側の細かい動きを補償するので、BIOをイネーブルにすることは、動き補償に対するブロックサイズを大きくするという結果になり得る。サンプルレベル動き改良は、サンプルごとに細かい動きベクトルを与える明示方程式があるので、網羅的な探索またはシグナリングを必要としない。
[0063]補償ブロック動きの後の参照k(k=0,1)からのルミナンス値をI(k)とすると、∂I(k)/∂x、∂I(k)/∂yは、それぞれ、I(k)勾配の水平成分および垂直成分である。オプティカルフローが有効であると想定すると、動きベクトルフィールド(vx,vy)は、式
によって与えられる。
[0064]オプティカルフロー方程式を各サンプルの動き軌跡に対するエルミート補間と組み合わせると、関数値I(k)と導関数∂I(k)/∂x、∂I(k)/∂yの両方に整合する、3次の一意多項式が最後に得られる。t=0におけるこの多項式の値は、BIO予測、すなわち、
である。
[0065]ここで、τ0およびτ1は、図7に示すように参照フレームまでの距離を示す。距離τ0およびτ1は、Ref0およびRef1に対するPOCに基づいて計算され、すなわち、τ0=POC(現在)-POC(Ref0)、τ1=POC(Ref1)-POC(現在)である。両方の予測が同じ時間方向から(両方が過去から、または両方が未来から)来る場合、符号は異なり、τ0・τ1<0である。この場合、予測が同じ時間モーメントから来るのではなく(τ0≠τ1)、参照される両方の領域が非0の動きを有し(MVx0、MVy0、MVx1、MVy1≠0)、ブロック動きベクトルが時間距離に比例する(MVx0/MVx1=MVy0/MVy1=-τ0/τ1)場合のみ、BIOが適用される。
[0066]点AおよびBの値の間の差分Δ(図7の中の動き軌跡と参照フレーム平面との交差)を最小化することによって、動きベクトルフィールド(vx,vy)が決定される。例示的なモデルは、Δに対する局所的なテイラー展開の最初の線形項しか使用しない。
[0067](1)におけるすべての値は、ここまで省略されたサンプルロケーション(i’,j’)に依存する。局所的な周囲状況の中で動きが一致することを想定すると、我々は、現在予測される点(i,j)と中心とする(2M+1)×(2M+1)の正方形ウィンドウΩの内側でΔを最小化する。
[0068]この最適化問題に対して、我々は、最初に垂直方向で、次いで水平方向で、最小化を行う、簡略化された解決策を使用する。そのことは、
という結果になり、ここで、
である。
[0069]0または極めて小さい値による除算を回避するために、正則化パラメータrおよびmが式(2)、式(3)の中に導入される。
[0070]ここで、dは入力ビデオの内部ビット深度である。
[0071]場合によっては、BIOのMV統治は、雑音または不規則な動きに起因して信頼できないことがある。したがって、BIOでは、MV統治の大きさは、いくつかのしきい値thBIOにクリップされる。しきい値は、現在ピクチャのすべての参照ピクチャが、すべて1つの方向からであるかどうかに基づいて決定される。現在ピクチャの現在ピクチャのすべての参照ピクチャが1つの方向からである場合、しきい値の値は12×214-dに設定され、そうでない場合、12×213-dに設定される。
[0072]BIOに対する勾配は、HEVC動き補償プロセスと一致する演算を使用して動き補償補間と同時に計算される(2D分離可能FIR)。この2D分離可能FIRのための入力は、動き補償プロセス用と同じ参照フレームサンプル、およびブロック動きベクトルの分数部分による分数位置(fracX,fracY)である。水平勾配∂I/∂x信号の場合、最初に、デスケーリングシフトd-8を有する(with)分数位置fracYに対応するBIOfilterSを使用して垂直に補間され、次いで、勾配フィルタBIOfilterGが、18-dだけのデスケーリングシフトを有する分数位置fracXに対応する水平方向において適用される。垂直勾配∂I/∂yの場合、最初に、勾配フィルタが、デスケーリングシフトd-8を有する分数位置fracYに対応するBIOfilterGを使用して垂直に適用され、次いで、信号変位が、18-dだけのデスケーリングシフトを有する分数位置fracXに対応する水平方向においてBIOfilterSを使用して実行される。勾配計算のための補間フィルタBIOfilterGおよび信号変位BIOfilterFの長さは、妥当な計算量を維持するためにもっと短い(6タップ)。
[0073]図8は、8×4ブロックに対するBIOの間の勾配計算の一例を示す概念図である。8×4ブロックに対して、式(4)に示すように、各ピクセルについてvxとvyとを解くことが、各ピクセルを中心としたウィンドウΩ内のピクセルの動き補償された予測子、水平勾配値および垂直勾配値を必要とするので、ビデオコーダは、動き補償された予測子をフェッチし得、ブロック内のすべてのピクセルの水平勾配および垂直勾配、ならびにピクセルの外側の2つのラインを計算し得る。そしてJEMでは、このウィンドウのサイズは5×5に設定される。したがって、ビデオコーダは、動き補償された予測子をフェッチし、ピクセルの外側の2つのラインに対する勾配を計算する必要がある。JEMでは、2つの予測が異なる参照ピクチャからであるとき、BIOはすべての双方向予測ブロックに適用される。CUに対してLICがイネーブルにされているとき、BIOはディセーブルにされる。
[0074]一般化双予測(GBi:generalized bi-prediction)がJVET-C0047において提案された。JVET-K0248は、GBiに対する利得計算量トレードオフを改善しBMS2.1の中に採択された。BMS2.1 GBiは、双予測モードにおけるL0およびL1からの予測子に不均等な重みを適用する。インター予測モードでは、均等な重みペア(1/2,1/2)を含む複数の重みペアが、レートひずみ最適化(RDO:rate-distortion optimization)に基づいて評価され、選択された重みペアのGBiインデックスが、デコーダにシグナリングされる。マージモードでは、GBiインデックスは隣接CUから継承される。BMS2.1 GBiにおいて、双予測モードでの予測子生成が以下に示される。
ここで、PGBiはGBiの最終予測子である。w0およびw1は選択されたGBi重みペアであり、それぞれ、リスト0(L0)およびリスト1(L1)の予測子に適用される。RoundingOffsetGBiおよびshiftNumGBiは、GBiにおける最終予測子を正規化するために使用される。サポートされるw1重みセットは、{-1/4,3/8,1/2,5/8,5/4}であり、5つの重みは1つの均等な重みペアおよび4つの不均等な重みペアに対応する。混合利得、すなわち、w1とw0との合計は、1.0に固定される。したがって、対応するw0重みセットは、{5/4,5/8,1/2,3/8,-1/4}である。重みペア選択はCUレベルである。
[0075]非低遅延ピクチャの場合、重みセットサイズは5つから3つに低減され、ここで、w1重みセットは{3/8,1/2,5/8}であり、w0重みセットは{5/8,1/2,3/8}である。非低遅延ピクチャに対する重みセットサイズ低減は、BMS2.1 GBi、およびこの案におけるすべてのGBiテストに適用される。
[0076]本開示は、DMVD関連の方法(PMMVD、双方向テンプレートマッチング、デコーダ側MV改良など)が、著しいコーディング性能改善をもたらすことを認識する。これらの既存の技術のうちのいくつかは、デコーダ側MV導出プロセスと空間的なMV予測との間で、相互依存性問題(復号レイテンシ問題とも呼ばれる)を部分的または完全に(コーディング効率を代償として)さらに解決している。また、DMVRが、BIO、履歴ベースマージ候補、およびアフィンマージ候補に関与するとき、多くの適用シナリオにおいても同じ復号レイテンシ問題が起こる。しかしながら、1)改良されたMVが、どのように使用され得るのか、および2)改良されたMVが、アクセス不可能なときにどのように置き換えられ得るのかに関して、いくつかの使用事例が指定されるべきである。その上、GBi、重み付き双予測、MMVR、マージオフセット拡張、およびDMVRパディングプロセスの現在の設計は、DMVRの大部分にメモリバッファサイズと計算量とを低減させるように改善され得る。本開示の技法は、これらおよび他の問題に対処し得、それによって、ビデオコーディング(符号化および/または復号)の技術分野を改善し、ビデオエンコーダおよびビデオデコーダなどの、ビデオコーディングを実行するデバイスも改善する。
[0077]図9は、本開示の技法を実行し得る例示的なビデオ符号化および復号システム100を示すブロック図である。本開示の技法は、一般に、ビデオデータをコーディング(符号化および/または復号)することを対象とする。一般に、ビデオデータは、ビデオを処理するための任意のデータを含む。したがって、ビデオデータは、未加工のコーディングされていないビデオと、符号化されたビデオと、復号された(たとえば、再構成された)ビデオと、シグナリングデータなどのビデオメタデータとを含んでよい。
[0078]図9に示すように、システム100は、この例では、宛先デバイス116によって復号および表示されるべき符号化ビデオデータを提供するソースデバイス102を含む。詳細には、ソースデバイス102は、コンピュータ可読媒体110を介してビデオデータを宛先デバイス116に提供する。ソースデバイス102および宛先デバイス116は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、スマートフォンなどの電話ハンドセット、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、幅広いデバイスのうちのいずれかを備えてよい。場合によっては、ソースデバイス102および宛先デバイス116は、ワイヤレス通信のために装備されてよく、したがって、ワイヤレス通信デバイスと呼ばれることがある。
[0079]図9の例では、ソースデバイス102は、ビデオソース104と、メモリ106と、ビデオエンコーダ200と、出力インターフェース108とを含む。宛先デバイス116は、入力インターフェース122と、ビデオデコーダ300と、メモリ120と、ディスプレイデバイス118とを含む。本開示によれば、ソースデバイス102のビデオエンコーダ200および宛先デバイス116のビデオデコーダ300は、DMVRを改善するための技法を適用するように構成され得る。したがって、ソースデバイス102は、ビデオ符号化デバイスの一例を表し、宛先デバイス116は、ビデオ復号デバイスの一例を表す。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含んでよい。たとえば、ソースデバイス102は、外部カメラなどの外部ビデオソースからビデオデータを受信してよい。同様に、宛先デバイス116は、統合されたディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースしてよい。
[0080]図9に示すようなシステム100は一例にすぎない。一般に、いかなるデジタルビデオ符号化および/または復号デバイスも、DMVRを改善するための技法を実行し得る。ソースデバイス102および宛先デバイス116は、ソースデバイス102が宛先デバイス116への送信のためにコード化ビデオデータを生成する、そのようなコーディングデバイスの例にすぎない。本開示は、データのコーディング(符号化および/または復号)を実行するデバイスとして「コーディング」デバイスに言及する。したがって、ビデオエンコーダ200およびビデオデコーダ300は、コーディングデバイス、詳細には、それぞれ、ビデオエンコーダおよびビデオデコーダの例を表す。いくつかの例では、ソースデバイス102および宛先デバイス116は、ソースデバイス102および宛先デバイス116の各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、システム100は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオ電話のために、ソースデバイス102と宛先デバイス116との間で1方向または2方向のビデオ送信をサポートし得る。
[0081]概して、ビデオソース104は、ビデオデータ(すなわち、未加工のコーディングされていないビデオデータ)のソースを表し、ビデオデータの連続した一連のピクチャ(「フレーム」とも呼ばれる)をビデオエンコーダ200に提供し、ビデオエンコーダ200はピクチャに対するデータを符号化する。ソースデバイス102のビデオソース104は、以前にキャプチャされた未加工のビデオを含むビデオカメラ、ビデオアーカイブなどのビデオキャプチャデバイス、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含んでよい。さらなる代替として、ビデオソース104は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。各場合において、ビデオエンコーダ200は、キャプチャされた、事前キャプチャされた、またはコンピュータ生成されたビデオデータを符号化する。ビデオエンコーダ200は、受信された順序(時々、「表示順序」と呼ばれる)からコーディング用のコーディング順序に、ピクチャを再配置し得る。ビデオエンコーダ200は、符号化ビデオデータを含むビットストリームを生成し得る。ソースデバイス102は、次いで、たとえば、宛先デバイス116の入力インターフェース122による、受信および/または取出しのために、出力インターフェース108を介してコンピュータ可読媒体110上に符号化ビデオデータを出力し得る。
[0082]ソースデバイス102のメモリ106および宛先デバイス116のメモリ120は、汎用メモリを表す。いくつかの例では、メモリ106、120は、未加工のビデオデータ、たとえば、ビデオソース104からの未加工ビデオと、ビデオデコーダ300からの未加工の復号されたビデオデータとを記憶し得る。追加または代替として、メモリ106、120は、たとえば、それぞれ、ビデオエンコーダ200およびビデオデコーダ300によって実行可能な、ソフトウェア命令を記憶し得る。メモリ106、120は、この例ではビデオエンコーダ200およびビデオデコーダ300から別個に示されるが、ビデオエンコーダ200およびビデオデコーダ300がまた、機能的に類似のまたは均等な目的のための内部メモリを含んでよいことを理解されたい。さらに、メモリ106、120は、符号化ビデオデータ、たとえば、ビデオエンコーダ200からの出力と、ビデオデコーダ300への入力とを記憶し得る。いくつかの例では、メモリ106、120の部分は、たとえば、未加工の復号ビデオデータおよび/または符号化ビデオデータを記憶するための、1つまたは複数のビデオバッファとして割り振られてよい。
[0083]コンピュータ可読媒体110は、ソースデバイス102から宛先デバイス116に符号化ビデオデータをトランスポートすることが可能な任意のタイプの媒体またはデバイスを表してよい。一例では、コンピュータ可読媒体110は、ソースデバイス102が、たとえば、無線周波数ネットワークまたはコンピュータベースネットワークを介して、符号化ビデオデータをリアルタイムで直接宛先デバイス116へ送信することを可能にするための、通信媒体を表す。出力インターフェース108は、符号化ビデオデータを含む送信信号を変調してよく、入力インターフェース122は、受信された送信信号をワイヤレス通信プロトコルなどの通信規格に従って復調してよい。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を備えてよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス102から宛先デバイス116への通信を容易にするために有用であり得る任意の他の機器を含んでよい。
[0084]いくつかの例では、ソースデバイス102は、出力インターフェース108から記憶デバイス112に符号化データを出力し得る。同様に、宛先デバイス116は、入力インターフェース122を介して記憶デバイス112からの符号化データにアクセスし得る。記憶デバイス112は、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含んでよい。
[0085]いくつかの例では、ソースデバイス102は、ソースデバイス102によって生成された符号化ビデオを記憶し得る、ファイルサーバ114または別の中間記憶デバイスに、符号化ビデオデータを出力し得る。宛先デバイス116は、ストリーミングまたはダウンロードを介してファイルサーバ114からの記憶されたビデオデータにアクセスし得る。ファイルサーバ114は、符号化ビデオデータを記憶することおよびその符号化ビデオデータを宛先デバイス116へ送信することが可能な、任意のタイプのサーバデバイスであってよい。ファイルサーバ114は、(たとえば、ウェブサイト用の)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、コンテンツ配信ネットワークデバイス、またはネットワーク接続ストレージ(NAS)デバイスを表してよい。宛先デバイス116は、インターネット接続を含む任意の標準データ接続を通じて、ファイルサーバ114からの符号化ビデオデータにアクセスし得る。これは、ワイヤレスチャネル(たとえば、Wi-Fi(登録商標)接続)、有線接続(たとえば、デジタル加入者回線(DSL)、ケーブルモデムなど)、またはファイルサーバ114上に記憶された符号化ビデオデータにアクセスするのに適したその両方の組合せを含んでよい。ファイルサーバ114および入力インターフェース122は、ストリーミング伝送プロトコル、ダウンロード伝送プロトコル、またはそれらの組合せに従って動作するように構成され得る。
[0086]出力インターフェース108および入力インターフェース122は、ワイヤレス送信機/受信機、モデム、有線ネットワーキング構成要素(たとえば、Ethernet(登録商標)カード)、様々なIEEE802.11規格のうちのいずれかに従って動作するワイヤレス通信構成要素、または他の物理構成要素を表してよい。出力インターフェース108および入力インターフェース122がワイヤレス構成要素を備える例では、出力インターフェース108および入力インターフェース122は、4G、4G-LTE(登録商標)(ロングタームエボリューション)、LTEアドバンスト、5Gなどのセルラー通信規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。出力インターフェース108がワイヤレス送信機を備えるいくつかの例では、出力インターフェース108および入力インターフェース122は、IEEE802.11仕様、IEEE802.15仕様(たとえば、ZigBee(登録商標))、Bluetooth(登録商標)規格などの他のワイヤレス規格に従って、符号化ビデオデータなどのデータを転送するように構成され得る。いくつかの例では、ソースデバイス102および/または宛先デバイス116は、それぞれのシステムオンチップ(SoC)デバイスを含んでよい。たとえば、ソースデバイス102は、ビデオエンコーダ200および/または出力インターフェース108のものとされる機能性を実行するためのSoCデバイスを含んでよく、宛先デバイス116は、ビデオデコーダ300および/または入力インターフェース122のものとされる機能性を実行するためのSoCデバイスを含んでよい。
[0087]本開示の技法は、オーバージエアテレビ放送、ケーブルテレビ送信、衛星テレビ送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア適用例のうちのいずれかのサポートにおけるビデオコーディングに適用され得る。
[0088]宛先デバイス116の入力インターフェース122は、コンピュータ可読媒体110(たとえば、通信媒体、記憶デバイス112、ファイルサーバ114など)から符号化ビデオビットストリームを受信する。符号化ビデオビットストリームは、ビデオブロックまたは他のコード化ユニット(たとえば、スライス、ピクチャ、ピクチャのグループ、シーケンスなど)の特性および/または処理を記述する値を有するシンタックス要素などの、ビデオデコーダ300によっても使用される、ビデオエンコーダ200によって規定されるシグナリング情報を含んでよい。ディスプレイデバイス118は、復号ビデオデータの復号ピクチャをユーザに表示する。ディスプレイデバイス118は、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのうちのいずれかを表してよい。
[0089]図9に示さないが、いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は各々、オーディオエンコーダおよび/またはオーディオデコーダと統合されてよく、共通のデータストリームの中にオーディオとビデオの両方を含む多重化ストリームを処理するために、適切なMUX-DEMUXユニットまたは他のハードウェアおよび/もしくはソフトウェアを含んでよい。適用可能な場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0090]ビデオエンコーダ200およびビデオデコーダ300は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な好適なエンコーダおよび/またはデコーダ回路構成のうちのいずれかとして実装され得る。技法が部分的にソフトウェアで実装されるとき、デバイスは、本開示の技法を実行するために、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体の中に記憶してよく、1つまたは複数のプロセッサを使用してハードウェアで命令を実行してよい。ビデオエンコーダ200およびビデオデコーダ300の各々は、1つまたは複数のエンコーダまたはデコーダの中に含まれてよく、それらのうちのいずれも、それぞれのデバイスの中で、組み合わせられたエンコーダ/デコーダ(コーデック)の一部として統合されてよい。ビデオエンコーダ200および/またはビデオデコーダ300を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを備えてよい。
[0091]ビデオエンコーダ200およびビデオデコーダ300は、高効率ビデオコーディング(HEVC)とも呼ばれるITU-T H.265、またはマルチビューおよび/もしくはスケーラブルビデオコーディング拡張などのそれらの拡張などの、ビデオコーディング規格に従って動作し得る。代替として、ビデオエンコーダ200およびビデオデコーダ300は、共同探求テストモデル(JEM)または多用途ビデオコーディング(VVC:Versatile Video Coding)とも呼ばれるITU-T H.266などの、他のプロプライエタリ規格または業界規格に従って動作し得る。VVC規格の最近のドラフトは、Brossら、「Versatile Video Coding (Draft6)」、ITU-T SG16 WP3とISO/IEC JTC1/SC29/WG11との共同ビデオエキスパート部会(JVET)、第15回会合、イェーテボリ、スウェーデン、2019年7月3日~12日、JVET-O2001-vE(以下では「VVCドラフト6」)の中に記載されている。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。
[0092]概して、ビデオエンコーダ200およびビデオデコーダ300は、ピクチャのブロックベースコーディングを実行し得る。「ブロック」という用語は、概して、処理される(たとえば、符号化される、復号される、または符号化および/もしくは復号プロセスにおいて別のやり方で使用される)べきデータを含む構造を指す。たとえば、ブロックは、ルミナンスおよび/またはクロミナンスデータのサンプルの2次元行列を含んでよい。概して、ビデオエンコーダ200およびビデオデコーダ300は、YUV(たとえば、Y、Cb、Cr)フォーマットで表されるビデオデータをコーディングし得る。すなわち、ピクチャのサンプルに対して赤色、緑色、および青色(RGB)のデータをコーディングするのではなく、ビデオエンコーダ200およびビデオデコーダ300は、ルミナンス成分とクロミナンス成分とをコーディングし得、ここで、クロミナンス成分は、赤色色相および青色色相の両方のクロミナンス成分を含んでよい。いくつかの例では、ビデオエンコーダ200は、符号化の前に、受信されたRGBフォーマット式データをYUV表現に変換し、ビデオデコーダ300は、YUV表現をRGBフォーマットに変換する。代替として、前処理ユニットおよび後処理ユニット(図示せず)がこれらの変換を実行してよい。
[0093]本開示は、概して、ピクチャのデータを符号化または復号するプロセスを含めるように、ピクチャのコーディング(たとえば、符号化および復号)に言及することがある。同様に、本開示は、ブロックに対するデータを符号化または復号する、たとえば、予測および/または残差コーディングのプロセスを含めるように、ピクチャのブロックのコーディングに言及することがある。符号化ビデオビットストリームは、概して、コーディング決定(たとえば、コーディングモード)およびブロックへのピクチャの区分を表す、シンタックス要素に対する一連の値を含む。したがって、ピクチャまたはブロックをコーディングすることへの言及は、概して、ピクチャまたはブロックを形成するシンタックス要素に対する値をコーディングすることとして理解されるべきである。
[0094]HEVCは、コーディングユニット(CU)と、予測ユニット(PU)と、変換ユニット(TU:transform unit)とを含む、様々なブロックを規定する。HEVCによれば、(ビデオエンコーダ200などの)ビデオコーダは、4分木構造に従ってコーディングツリーユニット(CTU)をCUに区分する。すなわち、ビデオコーダは、CTUとCUとをオーバーラップしない4つの均等な正方形に区分し、4分木の各ノードは、0個または4個の子ノードのいずれかを有する。子ノードを有しないノードは、「リーフノード」と呼ばれることがあり、そのようなリーフノードのCUは、1つもしくは複数のPUおよび/または1つもしくは複数のTUを含んでよい。ビデオコーダは、PUとTUとをさらに区分し得る。たとえば、HEVCでは、残差4分木(RQT:residual quadtree)はTUの区分を表す。HEVCでは、PUはインター予測データを表し、TUは残差データを表す。イントラ予測されるCUは、イントラモード表示などのイントラ予測情報を含む。
[0095]別の例として、ビデオエンコーダ200およびビデオデコーダ300は、JEMまたはVVCに従って動作するように構成され得る。JEMまたはVVCによれば、(ビデオエンコーダ200などの)ビデオコーダは、ピクチャを複数のコーディングツリーユニット(CTU)に区分する。ビデオエンコーダ200は、4分木2分木(QTBT)構造またはマルチタイプツリー(MTT:Multi-Type Tree)構造などの木構造に従ってCTUを区分し得る。QTBT構造は、HEVCのCU、PU、およびTUの間の分離などの、複数の区分タイプという概念を除去する。QTBT構造は、2つのレベル、すなわち、4分木区分に従って区分される第1のレベルと、2分木区分に従って区分される第2のレベルとを含む。QTBT構造のルートノードは、CTUに対応する。2分木のリーフノードは、コーディングユニット(CU)に対応する。
[0096]MTT区分構造では、ブロックは、4分木(QT:quadtree)区分と、2分木(BT:binary tree)区分と、1つまたは複数のタイプの3分木(TT:triple tree)(3元木(TT:ternary tree)とも呼ばれる)区分とを使用して、区分され得る。3分木区分または3元木区分は、ブロックが3つのサブブロックに分割される区分である。いくつかの例では、3分木区分または3元木区分は、中心を通って元のブロックを分割することなく、ブロックを3つのサブブロックに分割する。MTTにおける区分タイプ(たとえば、QT、BT、およびTT)は、対称または非対称であってよい。
[0097]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、ルミナンス成分およびクロミナンス成分の各々を表すために単一のQTBTまたはMTT構造を使用し得るが、他の例では、ビデオエンコーダ200およびビデオデコーダ300は、ルミナンス成分用の1つのQTBT/MTT構造および両方のクロミナンス成分用の別のQTBT/MTT構造(すなわち、それぞれのクロミナンス成分用の2つのQTBT/MTT構造)などの、2つ以上のQTBTまたはMTT構造を使用し得る。
[0098]ビデオエンコーダ200およびビデオデコーダ300は、HEVCによる4分木区分、QTBT区分、MTT区分、または他の区分構造を使用するように構成され得る。説明のために、本開示の技法の説明はQTBT区分に関して提示される。ただし、本開示の技法が、4分木区分、または同様に他のタイプの区分を使用するように構成されたビデオコーダにも適用され得ることを理解されたい。
[0099]ブロック(たとえば、CTUまたはCU)は、ピクチャの中に様々な方法でグループ化されてよい。一例として、ブリック(brick)とは、ピクチャの中の特定のタイル内のCTU行の長方形領域を指し得る。タイルとは、ピクチャの中の特定のタイル列内および特定のタイル行内のCTUの長方形領域であり得る。タイル列とは、ピクチャの高さに等しい高さと、(たとえば、ピクチャパラメータセットの中などで)シンタックス要素によって指定される幅とを有する、CTUの長方形領域を指す。タイル行とは、(たとえば、ピクチャパラメータセットの中などで)シンタックス要素によって指定される高さと、ピクチャの幅に等しい幅とを有する、CTUの長方形領域を指す。
[0100]いくつかの例では、タイルは複数のブリックに区分され得、その各々はタイル内の1つまたは複数のCTU行を含み得る。複数のブリックに区分されないタイルも、ブリックと呼ばれ得る。ただし、タイルの真のサブセットであるブリックは、タイルと呼ばれないことがある。
[0101]ピクチャの中のブリックはまた、スライスの中に配置され得る。スライスは、単一のネットワーク抽象レイヤ(NAL)ユニットの中に排他的に含まれ得る1つのピクチャの整数個のブリックであり得る。いくつかの例では、スライスは、いくつかの完全なタイル、または1つのタイルの完全なブリックの連続したシーケンスのみ、のいずれかを含む。
[0102]本開示は、垂直寸法および水平寸法、たとえば、16×16サンプルまたは16バイ16(16 by 16)サンプルの観点から、(CUまたは他のビデオブロックなどの)ブロックのサンプル寸法を指すために、「N×N」と「NバイN」とを互換的に使用し得る。概して、16×16のCUは、垂直方向において16サンプル(y=16)と、水平方向において16サンプル(x=16)とを有する。同様に、N×NのCUは、概して、垂直方向においてNサンプルと、水平方向においてNサンプルとを有し、ただし、Nは非負の整数値を表す。CUの中のサンプルは、行および列をなして配置され得る。その上、CUは、必ずしも水平方向において垂直方向と同じ個数のサンプルを有することを必要としない。たとえば、CUはN×M個のサンプルを備えてよく、ただし、Mは必ずしもNに等しいとは限らない。
[0103]ビデオエンコーダ200は、予測情報および/または残差情報ならびに他の情報を表す、CUに対するビデオデータを符号化する。予測情報は、CUに対する予測ブロックを形成するために、CUがどのように予測されることになるのかを示す。残差情報は、概して、符号化の前のCUのサンプルと予測ブロックとの間のサンプルごとの差分を表す。
[0104]CUを予測するために、ビデオエンコーダ200は、概して、インター予測またはイントラ予測を通じてCUに対する予測ブロックを形成し得る。インター予測は、一般に、以前にコーディングされたピクチャのデータからCUを予測することを指すが、イントラ予測は、一般に、同じピクチャの、以前にコーディングされたデータからCUを予測することを指す。インター予測を実行するために、ビデオエンコーダ200は、1つまたは複数の動きベクトルを使用して予測ブロックを生成し得る。ビデオエンコーダ200は、概して、たとえば、CUと参照ブロックとの間の差分の観点から、CUに密に整合する参照ブロックを識別するために、動き探索を実行し得る。ビデオエンコーダ200は、参照ブロックが現在CUに密に整合するかどうかを決定するために、絶対差分和(SAD)、2乗差分和(SSD:sum of squared differences)、平均絶対差分(MAD:mean absolute difference)、平均2乗差分(MSD:mean squared differences)、または他のそのような差分計算を使用して、差分メトリックを計算し得る。いくつかの例では、ビデオエンコーダ200は、単方向予測または双方向予測を使用して現在CUを予測し得る。
[0105]JEMおよびVVCのいくつかの例はまた、インター予測モードと見なされ得るアフィン動き補償モードを提供する。アフィン動き補償モードでは、ビデオエンコーダ200は、ズームインもしくはズームアウト、回転、遠近の動き(perspective motion)、または他の不規則な動きタイプなどの、並進でない動き(non-translational motion)を表す2つ以上の動きベクトルを決定し得る。
[0106]イントラ予測を実行するために、ビデオエンコーダ200は、予測ブロックを生成するためのイントラ予測モードを選択し得る。JEMおよびVVCのいくつかの例は、様々な方向性モードならびに平面モードおよびDCモードを含む、67個のイントラ予測モードを提供する。概して、ビデオエンコーダ200は、現在ブロックのサンプルをそこから予測するための、現在ブロック(たとえば、CUのブロック)への隣接サンプルを記述する、イントラ予測モードを選択する。ビデオエンコーダ200がラスタ走査順序(左から右、上から下)でCTUとCUとをコーディングすることを想定すると、そのようなサンプルは、概して、現在ブロックと同じピクチャの中の現在ブロックの上、現在ブロックの上およびその左、または現在ブロックの左にあってよい。
[0107]ビデオエンコーダ200は、現在ブロック用の予測モードを表すデータを符号化する。たとえば、インター予測モードの場合、ビデオエンコーダ200は、様々な利用可能なインター予測モードのうちのどれが使用されるのか、ならびに対応するモードに対する動き情報を表す、データを符号化し得る。単方向または双方向インター予測の場合、たとえば、ビデオエンコーダ200は、高度動きベクトル予測(AMVP)モードまたはマージモードを使用して動きベクトルを符号化し得る。ビデオエンコーダ200は、アフィン動き補償モード用の動きベクトルを符号化するために、類似のモードを使用し得る。
[0108]ブロックのイントラ予測またはインター予測などの予測に続いて、ビデオエンコーダ200は、ブロックに対する残差データを計算し得る。残差ブロックなどの残差データは、ブロックと、対応する予測モードを使用して形成された、ブロックに対する予測ブロックとの間の差分を、サンプルごとに表す。ビデオエンコーダ200は、サンプルドメインではなく変換ドメインにおける変換されたデータを作り出すために、1つまたは複数の変換を残差ブロックに適用し得る。たとえば、ビデオエンコーダ200は、離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に類似の変換を、残差ビデオデータに適用し得る。追加として、ビデオエンコーダ200は、第1の変換に続いて、モード依存非分離可能2次変換(MDNSST:mode-dependent non-separable secondary transform)、信号依存変換(signal dependent transform)、カルーネンレーベ変換(KLT:Karhunen-Loeve transform)などの2次変換を適用し得る。ビデオエンコーダ200は、1つまたは複数の変換の適用に続いて変換係数を作り出す。
[0109]上述のように、変換係数を作り出すための任意の変換に続いて、ビデオエンコーダ200は変換係数の量子化を実行し得る。量子化とは、概して、係数を表すために使用されるデータの量をできる限り低減してさらなる圧縮をもたらすように、変換係数が量子化されるプロセスを指す。量子化プロセスを実行することによって、ビデオエンコーダ200は、係数の一部または全部に関連するビット深度を低減し得る。たとえば、ビデオエンコーダ200は、量子化の間にnビット値をmビット値まで小さく丸めてよく、ただし、nはmよりも大きい。いくつかの例では、量子化を実行するために、ビデオエンコーダ200は、量子化されるべき値のビット単位での右シフトを実行し得る。
[0110]量子化に続いて、ビデオエンコーダ200は変換係数を走査してよく、量子化変換係数を含む2次元行列から1次元ベクトルを作り出す。走査は、より高いエネルギー(したがって、より低い周波数)係数をベクトルの前方に配置し、より低いエネルギー(したがって、より高い周波数)変換係数をベクトルの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ200は、量子化変換係数を走査してシリアル化されたベクトルを作り出すために、既定の走査順序を利用してよく、次いで、ベクトルの量子化変換係数をエントロピー符号化してよい。他の例では、ビデオエンコーダ200は適応走査を実行し得る。1次元ベクトルを形成するために量子化変換係数を走査した後、ビデオエンコーダ200は、たとえば、コンテキスト適応型バイナリ算術コーディング(CABAC)に従って、1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ200はまた、ビデオデータを復号する際のビデオデコーダ300による使用のために、符号化ビデオデータに関連するメタデータを記述するシンタックス要素に対する値をエントロピー符号化し得る。
[0111]CABACを実行するために、ビデオエンコーダ200は、コンテキストモデル内のコンテキストを、送信されるべきシンボルに割り当ててよい。コンテキストは、たとえば、シンボルの隣接する値が0値であるか否かに関係し得る。確率決定は、シンボルに割り当てられたコンテキストに基づいてよい。
[0112]ビデオエンコーダ200は、たとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはシーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、もしくはビデオパラメータセット(VPS)などの他のシンタックスデータの中で、ビデオデコーダ300への、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、およびシーケンスベースのシンタックスデータなどの、シンタックスデータをさらに生成し得る。ビデオデコーダ300は、対応するビデオデータをどのように復号すべきかを決定するために、そのようなシンタックスデータを同様に復号し得る。
[0113]このようにして、ビデオエンコーダ200は、符号化ビデオデータ、たとえば、ブロック(たとえば、CU)へのピクチャの区分ならびにブロックに対する予測情報および/または残差情報を記述するシンタックス要素を含む、ビットストリームを生成し得る。最終的に、ビデオデコーダ300は、ビットストリームを受信し得、符号化ビデオデータを復号し得る。
[0114]概して、ビデオデコーダ300は、ビットストリームの符号化ビデオデータを復号するために、ビデオエンコーダ200によって実行されるプロセスとは相反のプロセスを実行する。たとえば、ビデオデコーダ300は、ビデオエンコーダ200のCABAC符号化プロセスとは相反としても、それと実質的に類似の方法で、CABACを使用してビットストリームのシンタックス要素に対する値を復号し得る。シンタックス要素は、CTUのCUを規定するために、QTBT構造などの対応する区分構造に従って、CTUへのピクチャの区分情報と、各CTUの区分とを規定し得る。シンタックス要素は、ビデオデータのブロック(たとえば、CU)に対する予測情報と残差情報とをさらに規定し得る。
[0115]残差情報は、たとえば、量子化変換係数によって表されてよい。ビデオデコーダ300は、ブロックに対する残差ブロックを再生するために、ブロックの量子化変換係数を逆量子化および逆変換し得る。ビデオデコーダ300は、ブロックに対する予測ブロックを形成するために、シグナリングされた予測モード(イントラ予測またはインター予測)と、関連する予測情報(たとえば、インター予測用の動き情報)とを使用する。ビデオデコーダ300は、次いで、元のブロックを再生するために予測ブロックと残差ブロックとを(サンプルごとに)組み合わせ得る。ビデオデコーダ300は、ブロックの境界に沿った視覚的アーティファクトを低減するためにデブロッキングプロセスを実行することなどの、追加の処理を実行し得る。
[0116]ビデオエンコーダ200およびビデオデコーダ300は、デコーダ側動きベクトル改良(DMVR)を向上させるために、本開示の技法を実行し得る。「デコーダ側」と呼ばれるが、ビデオエンコーダ200とビデオデコーダ300の両方によって生成される、対応する予測ブロックが一致することを確実にするために、これらの技法をビデオエンコーダ200も実行し得ることを理解されたい。ビデオエンコーダ200およびビデオデコーダ300は、単独で、または任意の組合せで、以下で説明する技法のうちのいずれかまたはすべてを実行し得る。
[0117]図10Aおよび図10Bは、改良された動きベクトルを使用してBIOを実行することに関連するメモリ帯域幅を低減するための例示的な技法を示す概念図である。ビデオエンコーダ200およびビデオデコーダ300は、BIOが、勾配値を算出するためのソースとして、パディングされたフィルタ入力サンプル(すなわち、参照ピクチャからフェッチされるとともに動き補償のために使用されるサンプル)を取り、最終の動き補償を実行することを可能にするために、この技法を使用するように構成され得る。
[0118]メモリ帯域幅に対する制約に起因して、参照ピクチャからフェッチされ得るピクセルの最大数は(w+7)*(h+7)であり、ただし、wおよびhは、CUの幅と高さとを示す。デコーダ側動きベクトル改良(DMVR)および/またはテンプレートマッチング予測(TMP:template matching prediction)から導出され得る、事前定義された最大変位ベクトルdを用いると、フェッチされるサンプルエリアは、(w+7+2d)*(h+7+2d)と同程度に大きさとなるべきであり、ここで、(w+7)*(h+7)のエリアの外側の追加のサンプルは、近くのサンプルからパディングされ、d≧0である。
[0119]図10Bは、(w+7)*(h+7)のエリアとパディングされるサンプルとの間の幾何学的関係を示す。改良されたMV(たとえば、図10Aおよび図10Bの中のΔMV)を用いてBIOが適用されるとき、勾配値を算出するために、パディングされるエリアの外側の余分なピクセルがやはり必要である。したがって、ビデオエンコーダ200およびビデオデコーダ300は、パディングされるサイズをdピクセルからd+sピクセルに大きくし得、ここで、sは勾配フィルタの長さの半分である(たとえば、3,5,7,...タップ勾配フィルタに対して、それぞれ、s=1,2,3,...である)。(w+7+2d)*(h+7+2d)を形成するために使用された同じパディング方法が適用される。元のフィルタ入力サンプル+パディングされるエリアの、得られるサイズは、(w+7+2d+2s)*(h+7+2d+2s)になる。
[0120]図11は、コーディングツリーユニット(CTU)を横断する仮想パイプラインデータユニット(VPDU:virtual pipeline data unit)の例示的な処理順序を示す概念図である。ビデオエンコーダ200およびビデオデコーダ300は、マージモードおよび/またはAMVPモードに対して動きベクトル予測のための参照が取られ得る場所を制約することがある。(上記で説明したような)プリフェッチング問題に起因して、後続のブロックが空間的な動き予測を実行するために、現在のフレームの中の復号されたCUからの、改良されたすべてのMVが利用可能であるとは限らない。基本的に、改良された動きベクトルが左上のCTUまたは上のCTUのいずれかの中のブロックからである場合のみ、空間的な因果的近傍の中にある改良されたMVが使用され得る。以下の2つの技法のうちの一方または両方が、単独で、もしくは互いに組み合わせて、および/または本明細書で説明する他の技法とともに、使用され得る。
[0121]一例では、右上のCTUからの改良されたMVも、空間的な動き予測のための参照として取られ得る。別の例では、少なくともN個のVPDU(64×64というサイズを有する仮想パイプラインデータユニット、N>1)だけ前方で生成される、改良されたMVは、空間的な動き予測のための参照として取られ得る。図11に示すように、CTUサイズが128×128であるとき、パイプラインデータユニットは、下にあるCU区分が何であろうと最大サイズの変換ユニット用に合わせるために、CTUをサイズが等しくオーバーラップしない4個の正方形ブロックに小さく分割する。したがって、空間的に直接隣接するVPDUの中の改良されたMVのうちのいくつかは、利用可能になり得る。たとえば、N=2であることが与えられると、D0/A1/D1は、A0/B0/A1から改良されたMVを取ることができ、C1は、B0およびD0から参照を取ることができる。
[0122]いくつかの例では、次のように、HMVPリストの更新プロセスに対して追加の制約があり得る。アフィンフラグがオフ(すなわち、並進動きモデル)であるとき、現在フレームの中の復号されるCUの改良されたMVは、HMVPリストへ入れることはできない。代わりに、HMVPリストを更新するために2つの代替形態が使用され得る。いくつかの例では、復号されるCUの元の(オリジナルの)MVは、HMVPリストへ入れられる。他の例では、HMVPリストを更新するために何も入れられない。
[0123]いくつかの例では、アフィンフラグがオン(すなわち、アフィン動きモデル)であるとき、現在フレームの中の復号されるCUの改良されたCPMV(制御点動きベクトル)は、アフィンHMVPリストへ入れることができない。代わりに、ビデオエンコーダ200およびビデオデコーダ300は、この復号されるCUの元のCPMVをアフィンHMVPリストへ入れることによって、アフィンHMVPリストを更新し得る。代替として、いくつかの例では、アフィンHMVPリストを更新するために何も入れられない。
[0124]別の例示的な技法は、アフィンマージ候補を形成するために、改良されたMVをCPMVとして因果的隣接サブブロックから条件付きで取ることを回避するために、構成型アフィンマージ候補(構成型モードとも呼ばれる)に対する制約を含む。この例示的な技法では、現在CUの空間的な因果的近傍の中でサンプリングされる各サブブロックMVは、構成型モードに対してその元のサブブロックMVが使用され得るのか、それともその改良された代替物が使用され得るのかを決定するために、以下の規則を適用する。(MVが、ここでは、並進動き、アフィンCPMV、およびアフィン導出サブブロックMVのものであり得ることに留意されたい。)いくつかの例では、サンプリングされるサブブロックが上のCTU行に位置する場合、それらの改良されたMV(それらが存在する場合)が、構成型モードのために使用され得る。追加または代替として、サンプリングされるサブブロックが、現在CTU中、または現在CTUの左の他のCTU中に位置する場合、それらの元のMV(それらが存在する場合)だけが、構成型モードのために使用され得る。
[0125]加えて、低計算量コード設計のために、現在CTU行の中の改良された情報を有するサブブロックは、構成型モードのプロセスにおいて常に利用不可能としてマークされ、現在CTU行のすぐ上のCTU行に置かれているサブブロックは、利用可能としてマークされる。その上、ビデオエンコーダ200およびビデオデコーダ300は、構成型モードのプロセスにおいて、右上のCTUからの改良されたMVが利用可能としてマークされるべきか否かを決定する(たとえば、シーケンスレベルにおいて事前定義または構成される)ための追加のフレキシビリティを保持し得る。
[0126]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、一般化双予測(GBi)と重み付き双予測(WP:weighted bi-prediction)とを使用する双予測に適用される重み値を正規化してよい。重み値の大きさに従って、各予測サンプルは、双予測の最終の予測信号への不均等な寄与を有することがある。しかしながら、DMVRは常に、L0予測信号およびL1予測信号が最終の双予測信号に均等に寄与することを想定し、そのため、目的関数は、L0予測ブロックとL1予測ブロックとの間の差分を最小化すべきデルタMVを見つけるものとして定義される。不均等な重み値が双予測に対して使用されるとき、この想定が当てはまらないことがあるので、この例示的な技法は、GBiおよびWPによって使用される重み値を正規化することを含む。w0およびw1が、それぞれ、L0予測ブロックおよびL1予測ブロック(すなわち、それぞれ、p0およびp1として示される)に適用される重み値であると考えると、提案される正規化されたコスト関数は次のように定義される。
または
ただし、nは、予測ブロックの中のピクセルの局所的なピクセル座標である。
[0127]これらの式を非整数演算から防止するために、w0およびw1に正の整数スカラー(sとして示す)が適用されてよい。
または
[0128]sの値は、1、2、4、8、および2のべき乗の他の整数であり得る。たとえば、sの示唆される構成は、GBiに対してs=8、ルーマWPに対してs=2luma_log2_weight_denom+Max(2,14-LumaBitDepth)、またはクロマWPに対してs=2luma_log2_weight_denom+delta_chroma_log2_weight_denom+Max(2,14-ChromaBitDepth)であり得る。
[0129]様々な例では、MMVRまたはマージオフセット拡張のいずれかのシンタックスがビットストリームの中に存在するとき、その使用を限定するために、DMVRに対して制約が課されることがある。例示的な独立した5つの制約が以下に示される。
・DMVRは、それがMMVRによって生成されるのか、マージオフセット拡張によって生成されるのか、それとも通常のマージモードによって生成されるのかにかかわらず、双予測動きを有するブロックに常に適用される。
・DMVRは、1)通常のマージモード、および2)元の動きが指し示した位置を中心とする[±d,±d]エリア(ただし、d≧0)の外側を指し示す変位ベクトルを用いる、そのMMVRまたはマージオフセット拡張、から導出された、双予測動きに適用される。
・DMVRは、1)通常のマージモード、および2)元の動きが指し示した位置を中心とする[±d,±d]エリア(ただし、d≧0)の内側を指し示す変位ベクトルを用いる、そのMMVRまたはマージオフセット拡張、から導出された、双予測動きに適用される。
・DMVRは、それがMMVRおよびマージオフセット拡張によって生成されないとき、双予測動きを改良するためだけに適用される。
・DMVRは、MMVRおよびマージオフセット拡張のシンタックスを有するマージ候補には適用されない。たとえば、ビデオ規格が、マージリストの中のいくつかの動き候補にMMVRシンタックスを適用し得る。本開示では、DMVRはそれらに適用されない。
[0130]図12は、水平補間に対して水平パディングしか使用されない技法を示す概念図である。いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、DMVRにおける(上で前述の)パディングプロセスの計算量と記憶空間とを低減するために、指定された順序付きプロセスを実行し得る。上記の例では、2つの余分なピクセルが、(w+7)*(h+7)のピクセルの各側部にパディングされる。結果は、(w+11)*(h+11)のピクセルを含むメモリブロックの中にバッファリングされる。次いで、DMVRは、探索エリアサンプルを形成するために動き補償の実行を必要とする。基本的に、最初に水平補間が適用され、補間結果をバッファリングするためにサイズ(w+11-t)*(w+11)の中間バッファが必要とされ、ただし、tは補間フィルタタップの数-1である。たとえば、補間フィルタが8タップであるとき、t=7である。
[0131]いくつかの例では、パディングプロセスは2ステップのプロセスになる。最初に、(w+7)*(h+7)のピクセルの各側部へのパディングを実行するのではなく、ビデオエンコーダ200およびビデオデコーダ300は、パディングプロセスを水平にのみ実行し得る。したがって、水平補間を実行する前に(w+11)*(h+7)のピクセルだけがバッファリングされる必要がある。次いで、ビデオエンコーダ200およびビデオデコーダ300は、水平補間を実行し得、得られたピクセルを、サイズ(w+11-t)*(h+7)のメモリブロックにぴったり合うようにバッファリングし得る。このことに続いて、ビデオエンコーダ200およびビデオデコーダ300は、元のパディングプロセスを通じて生成される前述の(w+11-t)*(w+11)のピクセルと同じピクセルを形成するために、メモリブロックの上および下への垂直パディングを実行し得る。
[0132]2ステップのパディングプロセスを用いると、水平補間入力を保つためのバッファサイズが(w+11)*(h+11)から(w+11)*(h+7)に事実上低減される。したがって、水平補間から持ち込まれる計算量が低減され得る。
[0133]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、パラメトリックサブペルMV導出の概念を、丸めオフセットおよび代替のサンプリングロケーションを有する、より正確なMV表現に拡張するために、下の3つの例示的な技法のうちの1つまたは複数を実行し得る。
[0134]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、丸めオフセットを実行し得る。すなわち、ビデオエンコーダ200およびビデオデコーダ300は、次のように、パラメトリック誤差曲面関数の解に丸めオフセットを追加してよい。
ここで、βは、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで決定され得る、丸めオフセットである。βの値は、0、±e、±2e、±3e、4e-1、または-4e+1であり得、ただし、e=E-1,0+E1,0-2E0,0である。
[0135]加えて、いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300はまた、丸めオフセットが、シグナリングを伴わない定数値、たとえば、β=2(E-1,0+E1,0-2E0,0)として直接設定される、簡略化された設計を使用してよい。
[0136]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、スパースサンプリング表現を実行し得る。1ペル区間を有する十字形の終点からコスト値をサンプリングするのではなく、ビデオエンコーダ200およびビデオデコーダ300は、パラメトリックサブペルMV導出の概念をNペル区間に拡張する技法を適用し得る。
ここで、Nは、1、2、3、4、...、8であり得、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで示される。
[0137]加えて、本開示はまた、定数値、すなわち、N=2を伴う、簡略化された設計を提案する。
[0138]これらの技法も、上述のように丸めオフセットを扱う。丸めオフセットが存在するとき、(Δx,Δy)は以下のように表され得る。
ここで、βは、シーケンスレベル、ピクチャレベル、タイルレベル、またはスライスレベルで決定され得る、丸めオフセットである。βの値は、0、±e、±2e、±3e、4e-1、または-4e+1であり得、ただし、e=E-N,0+EN,0-2E0,0である。加えて、ビデオエンコーダ200およびビデオデコーダ300は、丸めオフセットが、シグナリングを伴わない定数値、たとえば、β=2(E-N,0+EN,0-2E0,0)として直接設定され得る、簡略化された設計を使用してよい。
[0139]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、代替のサンプリングパターンを実行し得る。いくつかの例では、パラメトリックサブペルMV導出のために使用されるサンプリングロケーションは、x軸およびy軸に沿った十字形パターンの終点からである必要がない。そのような例では、ビデオエンコーダ200およびビデオデコーダ300は、配位系を反時計回りに45度だけ回転させ得、次のように、パラメトリック解の新たな閉形式解(Δx,Δy)が得られる。
および
[0140]さらに、これらの技法も、上記で説明した丸めオフセット、および/または上記で説明したスパースサンプリングを扱うことができる。
・丸めオフセット(Rounding offset):
・スパースサンプリング(Sparse sampling):
・組合せ(Combination):
[0141]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、DMVRがインター予測の最悪状況のメモリ帯域幅を過大に増大させることを防止するために、DMVRの最小ブロックサイズに対する制約を採用し得る。そのような例では、予測ブロックが以下の条件のうちのいずれかを満たすとき、ビデオエンコーダ200およびビデオデコーダ300はDMVRを実行しない。
・ブロックサイズがN×4または4×Nであり、ここで、Nは、正の整数(たとえば、4、8、16、32、64、128、256、...)である。
・ブロックサイズが8×8と同じである。
[0142]いくつかの例では、ビデオエンコーダ200およびビデオデコーダ300は、以下のサイズのブロックに対してDMVRを実行することを回避してよい。
・N<64(たとえば、4、8、16、32)であって、ブロックサイズがN×4または4×Nである。
・DMVRの探索点が完全に[-1,1]×[-1,1]の範囲内にカバーされるとは限らないとき、N≧64(たとえば、64、128)であって、ブロックサイズがN×4または4×Nである。
・ブロックサイズが8×8と同じである。
[0143]このようにして、ビデオエンコーダ200およびビデオデコーダ300は、8ピクセルよりも小さい幅もしくは高さのうちの少なくとも1つ、または8×8ピクセルに等しいサイズを有するブロックに対して、DMVRを実行することを回避してよい。ビデオエンコーダ200およびビデオデコーダ300は、8×8よりも大きいサイズ、すなわち、少なくとも8×NまたはN×8を有するブロックに対して、DMVRを実行し得、ここで、Nは、8よりも大きい整数値である。そのようなブロックに対してデフォルトでDMVRがイネーブルにさ得、またはビデオエンコーダ200およびビデオデコーダ300は、そのようなブロックに対してDMVRを実行すべきかどうかを決定するために評価されるべき追加の基準とともに構成され得る。
[0144]本開示は、概して、シンタックス要素などのいくつかの情報を「シグナリングすること」に言及することがある。「シグナリング」という用語は、概して、シンタックス要素の値および/または符号化ビデオデータを復号するために使用される他のデータの通信を指してよい。すなわち、ビデオエンコーダ200は、シンタックス要素に対する値をビットストリームの中でシグナリングしてよい。概して、シグナリングとは、ビットストリームの中の値を生成することを指す。上述のように、ソースデバイス102は、実質的にリアルタイムで、または宛先デバイス116によって後で取り出せるようにシンタックス要素を記憶デバイス112に記憶するときに起こり得るようにリアルタイムでなく、ビットストリームを宛先デバイス116にトランスポートし得る。
[0145]図13Aおよび図13Bは、例示的な4分木2分木(QTBT)構造130と、対応するコーディングツリーユニット(CTU)132とを示す概念図である。実線は4分木分割を表し、点線は2分木分割を示す。2分木の分割された各(すなわち、非リーフ)ノードにおいて、どの分割タイプ(すなわち、水平または垂直)が使用されるのかを示すために1つのフラグがシグナリングされ、ここで、この例では、0は水平分割を示し、1は垂直分割を示す。4分木分割の場合、4分木ノードは、サイズが等しい4つのサブブロックに、水平および垂直にブロックを分割するので、分割タイプを示す必要がない。したがって、QTBT構造130の領域ツリーレベルに対する(分割情報などの)シンタックス要素(すなわち、実線)と、QTBT構造130の予測ツリーレベルに対する(分割情報などの)シンタックス要素(すなわち、破線)とを、ビデオエンコーダ200が符号化し得、ビデオデコーダ300が復号し得る。QTBT構造130の端末リーフノードによって表されるCUに対して、予測データおよび変換データなどのビデオデータを、ビデオエンコーダ200が符号化し得、ビデオデコーダ300が復号し得る。
[0146]概して、図13BのCTU132は、第1および第2のレベルにおけるQTBT構造130のノードに対応するブロックのサイズを規定するパラメータに関連し得る。これらのパラメータは、(サンプル単位でCTU132のサイズを表す)CTUサイズと、最小4分木サイズ(最小許容4分木リーフノードサイズを表す、MinQTSize)と、最大2分木サイズ(最大許容2分木ルートノードサイズを表す、MaxBTSize)と、最大2分木深度(最大許容2分木深度を表す、MaxBTDepth)と、最小2分木サイズ(最小許容2分木リーフノードサイズを表す、MinBTSize)とを含み得る。
[0147]CTUに対応するQTBT構造のルートノードは、QTBT構造の第1のレベルにおいて4つの子ノードを有してよく、その各々は、4分木区分に従って区分され得る。すなわち、第1のレベルのノードは、(子ノードを有しない)いずれかのリーフノードであるか、または4つの子ノードを有する。QTBT構造130の例は、分岐に対して実線を有する親ノードと子ノードとを含むものとして、そのようなノードを表す。第1のレベルのノードが最大許容2分木ルートノードサイズ(MaxBTSize)よりも大きくない場合、ノードはそれぞれの2分木によってさらに区分され得る。1つのノードの2分木分割は、分割から得られるノードが最小許容2分木リーフノードサイズ(MinBTSize)または最大許容2分木深度(MaxBTDepth)に到達するまで反復され得る。QTBT構造130の例は、分岐に対して破線を有するものとしてそのようなノードを表す。2分木リーフノードは、コーディングユニット(CU)と呼ばれ、コーディングユニット(CU)は、それ以上区分することなく、予測(たとえば、イントラピクチャ予測またはインターピクチャ予測)および変換のために使用される。上記で説明したように、CUは、「ビデオブロック」または「ブロック」と呼ばれることもある。
[0148]QTBT区分構造の一例では、CTUサイズは128×128(ルーマサンプルおよび2つの対応する64×64クロマサンプル)として設定され、MinQTSizeは16×16として設定され、MaxBTSizeは64×64として設定され、MinBTSizeは(幅と高さの両方に対して)4として設定され、MaxBTDepthは4として設定される。4分木リーフノードを生成するために、最初に4分木区分がCTUに適用される。4分木リーフノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを有してよい。リーフ4分木ノードが128×128である場合、リーフ4分木ノードは、サイズがMaxBTSize(すなわち、この例では64×64)を上回るので、2分木によってそれ以上分割されない。そうでない場合、リーフ4分木ノードは、2分木によってさらに区分される。したがって、4分木リーフノードはまた、2分木に対してルートノードであり、0としての2分木深度を有する。2分木深度がMaxBTDepth(この例では4)に到達すると、それ以上の分割は許されない。2分木ノードがMinBTSize(この例では4)に等しい幅を有するとき、そのことはそれ以上の水平分割が許されないことを暗示する。同様に、MinBTSizeに等しい高さを有する2分木ノードは、その2分木ノードに対してそれ以上の垂直分割が許されないことを暗示する。上述のように、2分木のリーフノードはCUと呼ばれ、それ以上区分することなく予測および変換に従ってさらに処理される。
[0149]図14は、本開示の技法を実行し得る例示的なビデオエンコーダ200を示すブロック図である。図14は説明のために提供され、本開示において広く例示および説明されるような技法の限定と見なされるべきでない。説明のために、本開示は、開発中のHEVCビデオコーディング規格およびH.266ビデオコーディング規格などの、ビデオコーディング規格のコンテキストでビデオエンコーダ200を説明する。しかしながら、本開示の技法はこれらのビデオコーディング規格に限定されず、一般にビデオ符号化およびビデオ復号に適用可能である。
[0150]図14の例では、ビデオエンコーダ200は、ビデオデータメモリ230と、モード選択ユニット202と、残差生成ユニット204と、変換処理ユニット206と、量子化ユニット208と、逆量子化ユニット210と、逆変換処理ユニット212と、再構成ユニット214と、フィルタユニット216と、復号ピクチャバッファ(DPB:decoded picture buffer)218と、エントロピー符号化ユニット220とを含む。ビデオデータメモリ230、モード選択ユニット202、残差生成ユニット204、変換処理ユニット206、量子化ユニット208、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、フィルタユニット216、DPB218、およびエントロピー符号化ユニット220のうちのいずれかまたはすべては、1つまたは複数のプロセッサまたは処理回路構成で実装され得る。たとえば、ビデオエンコーダ200のユニットは、1つまたは複数の回路または論理要素として、ハードウェア回路構成の一部として、またはプロセッサ、ASIC、もしくはFPGAの一部として、実装され得る。その上、ビデオエンコーダ200は、これらおよび他の機能を実行するために、追加または代替のプロセッサまたは処理回路構成を含んでよい。
[0151]ビデオデータメモリ230は、ビデオエンコーダ200の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオエンコーダ200は、たとえば、ビデオソース104(図9)から、ビデオデータメモリ230の中に記憶されるビデオデータを受信し得る。DPB218は、ビデオエンコーダ200による後続のビデオデータの予測における使用のための参照ビデオデータを記憶する参照ピクチャメモリとして働いてよい。ビデオデータメモリ230およびDPB218は、同期DRAM(SDRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM(登録商標))、または他のタイプのメモリデバイスを含むダイナミックランダムアクセスメモリ(DRAM)などの、様々なメモリデバイスのうちのいずれかによって形成され得る。ビデオデータメモリ230およびDPB218は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、ビデオデータメモリ230は、図示したようにビデオエンコーダ200の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってよい。
[0152]本開示では、ビデオデータメモリ230への言及は、そのように特に説明されない限りビデオエンコーダ200の内部のメモリに限定されるものとして解釈されるべきでなく、またはそのように特に説明されない限りビデオエンコーダ200の外部のメモリに限定されるものとして解釈されるべきでない。むしろ、ビデオデータメモリ230への言及は、符号化するためにビデオエンコーダ200が受信するビデオデータ(たとえば、符号化されることになる現在ブロックに対するビデオデータ)を記憶する参照メモリとして理解されるべきである。図9のメモリ106も、ビデオエンコーダ200の様々なユニットからの出力の一時的な記憶を提供し得る。
[0153]図14の様々なユニットは、ビデオエンコーダ200によって実行される動作を理解するのを支援するために図示される。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。固定機能回路とは、特定の機能性を提供する回路を指し、実行され得る動作において事前設定される。プログラマブル回路とは、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能性を提供する。たとえば、プログラマブル回路は、プログラマブル回路に、ソフトウェアまたはファームウェアの命令によって規定される方式で動作させる、ソフトウェアまたはファームウェアを実行し得る。固定機能回路は、(たとえば、パラメータを受信しパラメータを出力するための)ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは、一般に不変である。いくつかの例では、ユニットのうちの1つまたは複数は異なる回路ブロック(固定機能またはプログラマブル)であってよく、いくつかの例では、1つまたは複数のユニットは集積回路であってよい。
[0154]ビデオエンコーダ200は、算術論理ユニット(ALU)、初等関数ユニット(EFU)、デジタル回路、アナログ回路、および/またはプログラマブル回路から形成されたプログラマブルコアを含んでよい。ビデオエンコーダ200の動作が、プログラマブル回路によって実行されるソフトウェアを使用して実行される例では、メモリ106(図9)は、ビデオエンコーダ200が受信および実行するソフトウェアのオブジェクトコードを記憶してよく、またはビデオエンコーダ200内の別のメモリ(図示せず)が、そのような命令を記憶してもよい。
[0155]ビデオデータメモリ230は、受信されたビデオデータを記憶するように構成される。ビデオエンコーダ200は、ビデオデータメモリ230からビデオデータのピクチャを取り出してよく、残差生成ユニット204およびモード選択ユニット202にビデオデータを提供してよい。ビデオデータメモリ230の中のビデオデータは、符号化されることになる未加工のビデオデータであってよい。
[0156]モード選択ユニット202は、動き推定ユニット222と、動き補償ユニット224と、イントラ予測ユニット226とを含む。モード選択ユニット202は、他の予測モードに従ってビデオ予測を実行するために、追加の機能ユニットを含んでよい。例として、モード選択ユニット202は、パレットユニット、(動き推定ユニット222および/または動き補償ユニット224の一部であり得る)イントラブロックコピーユニット、アフィンユニット、線形モデル(LM:linear model)ユニットなどを含んでよい。
[0157]モード選択ユニット202は、概して、符号化パラメータの組合せと、そのような組合せに対して得られたレートひずみ値とをテストするために、複数の符号化パスを協調させる。符号化パラメータは、CUへのCTUの区分、CUのための予測モード、CUの残差データ用の変換タイプ、CUの残差データのための量子化パラメータなどを含んでよい。モード選択ユニット202は、テストされた他の組合せよりも良好なレートひずみ値を有する符号化パラメータの組合せを、最終的に選択してよい。
[0158]ビデオエンコーダ200は、ビデオデータメモリ230から取り出されたピクチャを一連のCTUに区分してよく、スライス内の1つまたは複数のCTUをカプセル化してよい。モード選択ユニット202は、上記で説明した、HEVCのQTBT構造または4分木構造などの木構造に従って、ピクチャのCTUを区分してよい。上記で説明したように、ビデオエンコーダ200は、木構造に従ってCTUを区分することから1つまたは複数のCUを形成し得る。そのようなCUは、一般に、「ビデオブロック」または「ブロック」と呼ばれることもある。
[0159]概して、モード選択ユニット202はまた、現在ブロック(たとえば、現在CU、またはHEVCでは、PUおよびTUのオーバーラップする部分)に対する予測ブロックを生成するために、その構成要素(たとえば、動き推定ユニット222、動き補償ユニット224、およびイントラ予測ユニット226)を制御する。現在ブロックのインター予測に対して、動き推定ユニット222は、1つまたは複数の参照ピクチャ(たとえば、DPB218の中に記憶された、以前にコーディングされた1つまたは複数のピクチャ)の中の、密に整合する1つまたは複数の参照ブロックを識別するために、動き探索を実行し得る。詳細には、動き推定ユニット222は、たとえば、絶対差分和(SAD)、2乗差分和(SSD)、平均絶対差分(MAD)、平均2乗差分(MSD)などに従って、可能な参照ブロックが現在ブロックにどのくらい類似しているのかを表す値を計算し得る。動き推定ユニット222は、概して、現在ブロックと検討中の参照ブロックとの間のサンプルごとの差分を使用して、これらの計算を実行し得る。動き推定ユニット222は、現在ブロックに最も密に整合する参照ブロックを示す、これらの計算から得られる最小値を有する参照ブロックを識別し得る。
[0160]動き推定ユニット222は、現在ピクチャの中の現在ブロックの位置に対して、参照ピクチャの中の参照ブロックの位置を規定する、1つまたは複数の動きベクトル(MV)を形成し得る。動き推定ユニット222は、次いで、動き補償ユニット224に動きベクトルを提供し得る。たとえば、単方向インター予測の場合、動き推定ユニット222は単一の動きベクトルを提供し得るが、双方向インター予測の場合、動き推定ユニット222は2つの動きベクトルを提供し得る。動き補償ユニット224は、次いで、動きベクトルを使用して予測ブロックを生成し得る。たとえば、動き補償ユニット224は、動きベクトルを使用して参照ブロックのデータを取り出し得る。別の例として、動きベクトルが分数サンプル精度を有する場合、動き補償ユニット224は、予測ブロックに対する値を1つまたは複数の補間フィルタに従って補間し得る。さらに、双方向インター予測の場合、動き補償ユニット224は、それぞれの動きベクトルによって識別される2つの参照ブロックに対するデータを取り出し得、たとえば、サンプルごとの平均化または重み付き平均化を通じて、取り出されたデータを組み合わせ得る。
[0161]本開示の技法によれば、動き補償ユニット224は、ビデオデータの現在ブロックに対してDMVRがイネーブルにされているとき、動きベクトルを改良するためにDMVRを実行し得る。たとえば、現在ブロックが8×8以下のサイズ、すなわち、8ピクセルよりも小さい幅もしくは高さ、または8×8ピクセルに厳密に等しいサイズを有する場合、動き補償ユニット224は、動きベクトルに対してDMVRを実行するのを回避してよく、予測ブロックを生成するために動きベクトルを使用してよい。そうではなく、ブロックが8×8よりも大きいサイズ(たとえば、少なくとも8×NまたはN×8というサイズ、ここで、Nは8よりも大きい整数である)を有する場合、動き補償ユニット224は、他の基準を使用して、動きベクトルに対してDMVRを実行すべきかどうかを決定し得る。DMVRがイネーブルにされているとき、動き補償ユニット224は、上記で説明したようにDMVRを実行し得、次いで、改良された動きベクトルを使用して予測ブロックを生成し得る。
[0162]別の例として、イントラ予測またはイントラ予測コーディングに対して、イントラ予測ユニット226は、現在ブロックに隣接するサンプルから予測ブロックを生成し得る。たとえば、方向性モードの場合、イントラ予測ユニット226は、概して、隣接するサンプルの値を数学的に組み合わせてよく、予測ブロックを作り出すために、計算されたこれらの値を現在ブロックにわたる規定された方向で埋めてよい。別の例として、DCモードの場合、イントラ予測ユニット226は、現在ブロックへの隣接するサンプルの平均を計算してよく、予測ブロックのサンプルごとにこの得られた平均を含むように、予測ブロックを生成してよい。
[0163]モード選択ユニット202は、残差生成ユニット204に予測ブロックを提供する。残差生成ユニット204は、現在ブロックの未加工のコーディングされていないバージョンをビデオデータメモリ230から、および予測ブロックをモード選択ユニット202から受信する。残差生成ユニット204は、現在ブロックと予測ブロックとの間のサンプルごとの差分を計算する。得られたサンプルごとの差分は、現在ブロックに対する残差ブロックを規定する。いくつかの例では、残差生成ユニット204はまた、残差差分パルスコード変調(RDPCM:residual differential pulse code modulation)を使用して残差ブロックを生成するために、残差ブロックの中のサンプル値の間の差分を決定し得る。いくつかの例では、残差生成ユニット204は、2進減算を実行する1つまたは複数の減算器回路を使用して形成され得る。
[0164]モード選択ユニット202がCUをPUに区分する例では、各PUは、ルーマ予測ユニットおよび対応するクロマ予測ユニットに関連し得る。ビデオエンコーダ200およびビデオデコーダ300は、様々なサイズを有するPUをサポートし得る。上記で示されるように、CUのサイズとは、CUのルーマコーディングブロックのサイズを指してよく、PUのサイズとは、PUのルーマ予測ユニットのサイズを指してよい。特定のCUのサイズが2N×2Nであると想定すると、ビデオエンコーダ200は、イントラ予測に対して2N×2NまたはN×NというPUサイズと、インター予測に対して2N×2N、2N×N、N×2N、N×N、または類似の対称的なPUサイズとを、サポートし得る。ビデオエンコーダ200およびビデオデコーダ300はまた、インター予測の場合、2N×nU、2N×nD、nL×2N、およびnR×2NというPUサイズに対して非対称の区分をサポートし得る。
[0165]モード選択ユニット202がそれ以上CUをPUに区分しない例では、各CUは、ルーマコーディングブロックおよび対応するクロマコーディングブロックに関連し得る。上記のように、CUのサイズとは、CUのルーマコーディングブロックのサイズを指してよい。ビデオエンコーダ200およびビデオデコーダ300は、2N×2N、2N×N、またはN×2NというCUサイズをサポートし得る。
[0166]いくつかの例として、イントラブロックコピーモードコーディング、アフィンモードコーディング、および線形モデル(LM)モードコーディングなどの、他のビデオコーディング技法の場合、モード選択ユニット202は、コーディング技法に関連するそれぞれのユニットを介して、符号化中の現在ブロックに対する予測ブロックを生成する。パレットモードコーディングなどのいくつかの例では、モード選択ユニット202は、予測ブロックを生成しなくてよく、代わりに、選択されたパレットに基づいてブロックを再構成するための方式を示すシンタックス要素を生成し得る。そのようなモードでは、モード選択ユニット202は、符号化されるべきこれらのシンタックス要素をエントロピー符号化ユニット220に提供し得る。
[0167]上記で説明したように、残差生成ユニット204は、現在ブロックに対するビデオデータと、対応する予測ブロックとを受信する。残差生成ユニット204は、次いで、現在ブロックに対する残差ブロックを生成する。残差ブロックを生成するために、残差生成ユニット204は、予測ブロックと現在ブロックとの間のサンプルごとの差分を計算する。
[0168]変換処理ユニット206は、変換係数のブロック(本明細書で「変換係数ブロック」と呼ぶ)を生成するために、残差ブロックに1つまたは複数の変換を適用する。変換処理ユニット206は、変換係数ブロックを形成するために、残差ブロックに様々な変換を適用し得る。たとえば、変換処理ユニット206は、離散コサイン変換(DCT)、方向性変換、カルーネンレーベ変換(KLT)、または概念的に類似の変換を、残差ブロックに適用してよい。いくつかの例では、変換処理ユニット206は、複数の変換、たとえば、1次変換および回転変換などの2次変換を、残差ブロックに実行し得る。いくつかの例では、変換処理ユニット206は、残差ブロックに変換を適用しない。
[0169]量子化ユニット208は、量子化変換係数ブロックを作り出すために、変換係数ブロックの中の変換係数を量子化し得る。量子化ユニット208は、現在ブロックに関連する量子化パラメータ(QP:quantization parameter)値に従って変換係数ブロックの変換係数を量子化し得る。ビデオエンコーダ200は(たとえば、モード選択ユニット202を介して)、CUに関連するQP値を調整することによって、現在ブロックに関連する係数ブロックに適用される量子化の程度を調整し得る。量子化は情報の損失を持ち込むことがあり、したがって、量子化変換係数は、変換処理ユニット206によって作り出される元の変換係数よりも精度が低いことがある。
[0170]逆量子化ユニット210および逆変換処理ユニット212は、変換係数ブロックから残差ブロックを再構成するために、それぞれ、逆量子化と逆変換とを量子化変換係数ブロックに適用し得る。再構成ユニット214は、再構成された残差ブロック、およびモード選択ユニット202によって生成された予測ブロックに基づいて、(潜在的にいくらかの程度のひずみを有するとしても)現在ブロックに対応する再構成されたブロックを作り出し得る。たとえば、再構成ユニット214は、再構成されたブロックを作り出すために、モード選択ユニット202によって生成された予測ブロックからの対応するサンプルに、再構成された残差ブロックのサンプルを加算してよい。
[0171]フィルタユニット216は、再構成されたブロックに対して1つまたは複数のフィルタ動作を実行し得る。たとえば、フィルタユニット216は、CUのエッジに沿ったブロッキネスアーティファクトを低減するために、デブロッキング動作を実行してよい。いくつかの例では、フィルタユニット216の動作はスキップされてよい。
[0172]ビデオエンコーダ200は、再構成されたブロックをDPB218の中に記憶する。たとえば、フィルタユニット216の動作が必要とされない例では、再構成ユニット214は、再構成されたブロックをDPB218に記憶し得る。フィルタユニット216の動作が必要とされる例では、フィルタユニット216は、フィルタ処理済みの再構成されたブロックをDPB218に記憶し得る。動き推定ユニット222および動き補償ユニット224は、その後に符号化されるピクチャのブロックをインター予測するために、再構成された(また潜在的にフィルタ処理された)ブロックから形成された参照ピクチャをDPB218から取り出し得る。加えて、イントラ予測ユニット226は、現在ピクチャの中の他のブロックをイントラ予測するために、現在ピクチャの、DPB218の中の再構成されたブロックを使用し得る。
[0173]概して、エントロピー符号化ユニット220は、ビデオエンコーダ200の他の機能構成要素から受信されたシンタックス要素をエントロピー符号化し得る。たとえば、エントロピー符号化ユニット220は、量子化ユニット208からの量子化変換係数ブロックをエントロピー符号化し得る。別の例として、エントロピー符号化ユニット220は、モード選択ユニット202からの予測シンタックス要素(たとえば、インター予測のための動き情報、またはイントラ予測のためのイントラモード情報)をエントロピー符号化し得る。エントロピー符号化ユニット220は、エントロピー符号化データを生成するために、ビデオデータの別の例であるシンタックス要素に対して、1つまたは複数のエントロピー符号化動作を実行し得る。たとえば、エントロピー符号化ユニット220は、コンテキスト適応型可変長コーディング(CAVLC)動作、CABAC動作、可変対可変(V2V)長コーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)動作、確率区間区分エントロピー(PIPE)コーディング動作、指数ゴロム符号化動作、または別のタイプのエントロピー符号化動作を、データに対して実行してよい。いくつかの例では、エントロピー符号化ユニット220は、シンタックス要素がエントロピー符号化されないバイパスモードで動作し得る。
[0174]ビデオエンコーダ200は、スライスまたはピクチャのブロックを再構成するために必要とされるエントロピー符号化されたシンタックス要素を含むビットストリームを出力し得る。詳細には、エントロピー符号化ユニット220がビットストリームを出力してよい。
[0175]上記で説明した動作は、ブロックに関して説明される。そのような説明は、ルーマコーディングブロックおよび/またはクロマコーディングブロックのための動作であるものとして理解されるべきである。上記で説明したように、いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、CUのルーマ成分およびクロマ成分である。いくつかの例では、ルーマコーディングブロックおよびクロマコーディングブロックは、PUのルーマ成分およびクロマ成分である。
[0176]いくつかの例では、ルーマコーディングブロックに関して実行される動作は、クロマコーディングブロックに対して繰り返される必要がない。一例として、ルーマコーディングブロックに対する動きベクトル(MV)と参照ピクチャとを識別するための動作は、クロマブロックに対するMVと参照ピクチャとを識別するために繰り返される必要がない。むしろ、クロマブロックに対するMVを決定するために、ルーマコーディングブロックに対するMVがスケーリングされ得、参照ピクチャが同じであってよい。別の例として、イントラ予測プロセスは、ルーマコーディングブロックおよびクロマコーディングブロックにとって同じであってよい。
[0177]このようにして、ビデオエンコーダ200は、ビデオデータをコーディング(この例では、符号化および復号)するためのデバイスの一例を表し、デバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された1つまたは複数のプロセッサとを含み、1つまたは複数のプロセッサは、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を行うように構成される。
[0178]図15は、本開示の技法を実行し得る例示的なビデオデコーダ300を示すブロック図である。図15は説明のために提供され、本開示において広く例示および説明されるような技法における限定ではない。説明のために、本開示は、JEMおよびHEVCの技法によるビデオデコーダ300を説明する。しかしながら、本開示の技法は、他のビデオコーディング規格に構成されるビデオコーディングデバイスによって実行され得る。
[0179]図15の例では、ビデオデコーダ300は、コード化ピクチャバッファ(CPB:coded picture buffer)メモリ320と、エントロピー復号ユニット302と、予測処理ユニット304と、逆量子化ユニット306と、逆変換処理ユニット308と、再構成ユニット310と、フィルタユニット312と、復号ピクチャバッファ(DPB)314とを含む。CPBメモリ320、エントロピー復号ユニット302、予測処理ユニット304、逆量子化ユニット306、逆変換処理ユニット308、再構成ユニット310、フィルタユニット312、およびDPB314のうちのいずれかまたはすべては、1つまたは複数のプロセッサまたは処理回路構成で実装され得る。その上、ビデオデコーダ300は、これらおよび他の機能を実行するために、追加または代替のプロセッサまたは処理回路構成を含んでよい。
[0180]予測処理ユニット304は、動き補償ユニット316とイントラ予測ユニット318とを含む。予測処理ユニット304は、他の予測モードに従って予測を実行するために、追加のユニットを含んでよい。例として、予測処理ユニット304は、パレットユニット、(動き補償ユニット316の一部を形成し得る)イントラブロックコピーユニット、アフィンユニット、線形モデル(LM)ユニットなどを含んでよい。他の例では、ビデオデコーダ300は、より多数の、より少数の、または異なる機能の、構成要素を含んでよい。
[0181]CPBメモリ320は、ビデオデコーダ300の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。CPBメモリ320の中に記憶されるビデオデータは、たとえば、コンピュータ可読媒体110(図9)から取得され得る。CPBメモリ320は、符号化ビデオビットストリームからの符号化ビデオデータ(たとえば、シンタックス要素)を記憶するCPBを含んでよい。また、CPBメモリ320は、ビデオデコーダ300の様々なユニットからの出力を表す一時的なデータなどの、コード化ピクチャのシンタックス要素以外のビデオデータを記憶し得る。DPB314は、概して、符号化ビデオビットストリームの後続のデータもしくはピクチャを復号するときに、ビデオデコーダ300が参照ビデオデータとして出力および/または使用することがある、復号ピクチャを記憶する。CPBメモリ320およびDPB314は、同期DRAM(SDRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM)、または他のタイプのメモリデバイスを含むダイナミックランダムアクセスメモリ(DRAM)などの、様々なメモリデバイスのうちのいずれかによって形成され得る。CPBメモリ320およびDPB314は、同じメモリデバイスまたは別個のメモリデバイスによって設けられてよい。様々な例では、CPBメモリ320は、ビデオデコーダ300の他の構成要素とともにオンチップであってよく、またはそれらの構成要素に対してオフチップであってよい。
[0182]追加または代替として、いくつかの例では、ビデオデコーダ300は、メモリ120(図9)からコード化ビデオデータを取り出してよい。すなわち、メモリ120は、CPBメモリ320とともに、上記で説明したようにデータを記憶し得る。同様に、メモリ120は、ビデオデコーダ300の機能性の一部または全部が、ビデオデコーダ300の処理回路構成によって実行されるべきソフトウェアで実装されるとき、ビデオデコーダ300によって実行されるべき命令を記憶し得る。
[0183]図15に示す様々なユニットは、ビデオデコーダ300によって実行される動作を理解するのを支援するために図示される。ユニットは、固定機能回路、プログラマブル回路、またはそれらの組合せとして実装され得る。図14と同様に、固定機能回路とは、特定の機能性を提供する回路を指し、実行され得る動作において事前設定される。プログラマブル回路とは、様々なタスクを実行するようにプログラムされ得る回路を指し、実行され得る動作においてフレキシブルな機能性を提供する。たとえば、プログラマブル回路は、プログラマブル回路に、ソフトウェアまたはファームウェアの命令によって規定される方式で動作させる、ソフトウェアまたはファームウェアを実行し得る。固定機能回路は、(たとえば、パラメータを受信しパラメータを出力するための)ソフトウェア命令を実行し得るが、固定機能回路が実行する動作のタイプは、一般に不変である。いくつかの例では、ユニットのうちの1つまたは複数は異なる回路ブロック(固定機能またはプログラマブル)であってよく、いくつかの例では、1つまたは複数のユニットは集積回路であってよい。
[0184]ビデオデコーダ300は、ALU、EFU、デジタル回路、アナログ回路、および/またはプログラマブル回路から形成されたプログラマブルコアを含んでよい。ビデオデコーダ300の動作が、プログラマブル回路上で実行するソフトウェアによって実行される例では、ビデオデコーダ300が受信および実行するソフトウェアの命令(たとえば、オブジェクトコード)を、オンチップメモリまたはオフチップメモリが記憶し得る。
[0185]エントロピー復号ユニット302は、CPBから符号化ビデオデータを受信し得、シンタックス要素を再生するためにビデオデータをエントロピー復号し得る。予測処理ユニット304、逆量子化ユニット306、逆変換処理ユニット308、再構成ユニット310、およびフィルタユニット312は、ビットストリームから抽出されるシンタックス要素に基づいて復号ビデオデータを生成し得る。
[0186]概して、ビデオデコーダ300は、ピクチャをブロックごとに再構成する。ビデオデコーダ300は、各ブロックに対して再構成動作を個別に実行し得る(ここで、現在再構成中の、すなわち、復号中のブロックは、「現在ブロック」と呼ばれることがある)。
[0187]エントロピー復号ユニット302は、量子化変換係数ブロックの量子化変換係数ならびに量子化パラメータ(QP)および/または変換モード表示などの変換情報を規定する、シンタックス要素をエントロピー復号し得る。逆量子化ユニット306は、量子化の程度、および同様に、逆量子化ユニット306が適用すべき逆量子化の程度を決定するために、量子化変換係数ブロックに関連するQPを使用し得る。逆量子化ユニット306は、たとえば、量子化変換係数を逆量子化するために、ビット単位での左シフト演算を実行し得る。逆量子化ユニット306は、それによって、変換係数を含む変換係数ブロックを形成し得る。
[0188]逆量子化ユニット306が変換係数ブロックを形成した後、逆変換処理ユニット308は、現在ブロックに関連する残差ブロックを生成するために、変換係数ブロックに1つまたは複数の逆変換を適用し得る。たとえば、逆変換処理ユニット308は、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT)、逆回転変換、逆方向性変換、または別の逆変換を、係数ブロックに適用してよい。
[0189]さらに、予測処理ユニット304は、エントロピー復号ユニット302によってエントロピー復号された予測情報シンタックス要素に従って、予測ブロックを生成する。たとえば、現在ブロックがインター予測されていることを予測情報シンタックス要素が示す場合、動き補償ユニット316は、予測ブロックを生成し得る。この場合、予測情報シンタックス要素は、参照ブロックをそこから取り出すためのDPB314の中の参照ピクチャ、ならびに現在ピクチャの中の現在ブロックのロケーションに対して、参照ピクチャの中の参照ブロックのロケーションを識別する、動きベクトルを示してよい。動き補償ユニット316は、概して、動き補償ユニット224(図14)に関して説明したのと実質的に類似の方法で、インター予測プロセスを実行し得る。
[0190]本開示の技法によれば、動き補償ユニット316は、ビデオデータの現在ブロックに対してDMVRがイネーブルにされているとき、動きベクトルを改良するためにDMVRを実行し得る。たとえば、現在ブロックが8×8以下のサイズ、すなわち、8ピクセルよりも小さい幅もしくは高さ、または8×8ピクセルに厳密に等しいサイズを有する場合、動き補償ユニット316は、動きベクトルに対してDMVRを実行するのを回避し得、予測ブロックを生成するために動きベクトルを使用し得る。そうではなく、ブロックが8×8よりも大きいサイズ(たとえば、少なくとも8×NまたはN×8というサイズ、ただし、Nは8よりも大きい整数である)を有する場合、動き補償ユニット316は、他の基準を使用して、動きベクトルに対してDMVRを実行すべきかどうかを決定し得る。DMVRがイネーブルにされているとき、動き補償ユニット316は、上記で説明したようにDMVRを実行し得、次いで、改良された動きベクトルを使用して予測ブロックを生成し得る。
[0191]別の例として、現在ブロックがイントラ予測されていることを予測情報シンタックス要素が示す場合、イントラ予測ユニット318は、予測情報シンタックス要素によって示されるイントラ予測モードに従って予測ブロックを生成し得る。再び、イントラ予測ユニット318は、概して、イントラ予測ユニット226(図14)に関して説明したのと実質的に類似の方法で、イントラ予測プロセスを実行し得る。イントラ予測ユニット318は、現在ブロックへの隣接するサンプルのデータを、DPB314から取り出し得る。
[0192]再構成ユニット310は、予測ブロックと残差ブロックとを使用して、現在ブロックを再構成し得る。たとえば、再構成ユニット310は、現在ブロックを再構成するために、残差ブロックのサンプルを予測ブロックの対応するサンプルに加算し得る。
[0193]フィルタユニット312は、再構成されたブロックに対して1つまたは複数のフィルタ動作を実行し得る。たとえば、フィルタユニット312は、再構成されたブロックのエッジに沿ったブロッキネスアーティファクトを低減するために、デブロッキング動作を実行してよい。フィルタユニット312の動作は、必ずしもすべての例において実行されるとは限らない。
[0194]ビデオデコーダ300は、再構成されたブロックをDPB314の中に記憶し得る。たとえば、フィルタユニット312の動作が実行されない例では、再構成ユニット310は、再構成されたブロックをDPB314に記憶し得る。フィルタユニット312の動作が実行される例では、フィルタユニット312は、フィルタ処理済みの再構成されたブロックをDPB314に記憶し得る。上記で説明したように、DPB314は、イントラ予測のための現在ピクチャのサンプル、および後続の動き補償のための以前に復号されたピクチャなどの、参照情報を、予測処理ユニット304に提供し得る。その上、ビデオデコーダ300は、図1のディスプレイデバイス118などのディスプレイデバイス上での後続の提示のために、DPBから復号ピクチャを出力し得る。
[0195]このようにして、ビデオデコーダ300は、ビデオデータをコーディング(この例では、復号)するためのデバイスの一例を表し、デバイスは、ビデオデータを記憶するように構成されたメモリと、回路構成の中に実装された1つまたは複数のプロセッサとを含み、1つまたは複数のプロセッサは、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有することを決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を行うように構成される。
[0196]図16は、本開示の技法による、現在ブロックを符号化する例示的な方法を示すフローチャートである。現在ブロックは、現在CUを備え得る。ビデオエンコーダ200(図9および図14)に関して説明されるが、他のデバイスが図16の方法と類似の方法を実行するように構成され得ることを理解されたい。
[0197]この例では、ビデオエンコーダ200は、最初に現在ブロックを予測する(350)。たとえば、ビデオエンコーダ200は、現在ブロックに対する予測ブロックを形成し得る。ビデオエンコーダ200は、予測ブロックを形成するとき、本開示のDMVRに関係する技法のうちのいずれかまたはすべてを実行し得る。いくつかの例では、ビデオエンコーダ200は、上記で説明したように、デコーダ側動きベクトル改良(DMVR)を使用して、動き探索から決定された動きベクトルを改良し得る。詳細には、本開示の技法によれば、ビデオエンコーダ200は、現在ブロックのサイズに少なくとも部分的に基づいて、DMVRを実行すべきかどうかを決定し得る。現在ブロックが、8ピクセルよりも小さい幅もしくは高さのうちの少なくとも1つを有するか、または8ピクセルに等しい幅と高さの両方(すなわち、8×8ピクセルというサイズ)を有する場合、ビデオエンコーダ200は、現在ブロックに対してDMVRを実行すべきでないと決定し得る。そうではなく、現在ブロックが少なくとも8×NまたはN×8というサイズを有する場合(ここにおいて、Nは8よりも大きい整数値である)、ビデオエンコーダ200は、DMVRを実行すべきと決定し得、または追加の基準に基づいて、現在ブロックに対してDMVRを実行すべきかどうかを決定し得る。ビデオエンコーダ200は、次いで、予測ブロックを形成するために、DMVRを使用して潜在的に改良される、動きベクトルを使用し得る。
[0198]ビデオエンコーダ200は、次いで、現在ブロックに対する残差ブロックを計算し得る(352)。残差ブロックを計算するために、ビデオエンコーダ200は、コーディングされていない元のブロックと現在ブロックに対する予測ブロックとの間の差分を計算し得る。ビデオエンコーダ200は、次いで、残差ブロックの係数を変換および量子化し得る(354)。次に、ビデオエンコーダ200は、残差ブロックの量子化変換係数を走査し得る(356)。走査の間、または走査に続いて、ビデオエンコーダ200は、係数をエントロピー符号化し得る(358)。たとえば、ビデオエンコーダ200は、CAVLCまたはCABACを使用して係数を符号化し得る。ビデオエンコーダ200は、次いで、ブロックの係数に対するエントロピーコード化データを出力し得る(360)。
[0199]このようにして、図16は、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディングする(すなわち、符号化する)方法の一例を表す。
[0200]図17は、本開示の技法による、現在ブロックを復号する例示的な方法を示すフローチャートである。現在ブロックは、現在CUを備え得る。ビデオデコーダ300(図9および図15)に関して説明されるが、他のデバイスが図17の方法と類似の方法を実行するように構成され得ることを理解されたい。
[0201]ビデオデコーダ300は、エントロピーコード化予測情報、および現在ブロックに対応する残差ブロックの係数に対するエントロピーコード化データなどの、現在ブロックに対するエントロピーコード化データを受信し得る(370)。ビデオデコーダ300は、現在ブロックに対する予測情報を決定し残差ブロックの係数を再生するために、エントロピーコード化データをエントロピー復号し得る(372)。ビデオデコーダ300は、現在ブロックに対する予測ブロックを計算するために、たとえば、現在ブロックに対する予測情報によって示されるようなインター予測モードを使用して、現在ブロックを予測し得る(374)。
[0202]ビデオデコーダ300は、予測ブロックを形成するとき、本開示のDMVRに関係する技法のうちのいずれかまたはすべてを実行し得る。いくつかの例では、ビデオデコーダ300は、上記で説明したように、デコーダ側動きベクトル改良(DMVR)を使用して、決定された復号動きベクトルを改良し得る。詳細には、本開示の技法によれば、ビデオデコーダ300は、現在ブロックのサイズに少なくとも部分的に基づいて、DMVRを実行すべきかどうかを決定し得る。現在ブロックが、8ピクセルよりも小さい幅もしくは高さのうちの少なくとも1つを有するか、または8ピクセルに等しい幅と高さの両方(すなわち、8×8ピクセルというサイズ)を有する場合、ビデオデコーダ300は、現在ブロックに対してDMVRを実行すべきでないと決定し得る。そうではなく、現在ブロックが、少なくとも8×NまたはN×8というサイズを有する場合(ここにおいて、Nは8よりも大きい整数値である)、ビデオデコーダ300は、DMVRを実行すべきと決定し得る、または追加の基準に基づいて、現在ブロックに対してDMVRを実行すべきかどうかを決定し得る。ビデオデコーダ300は、次いで、予測ブロックを形成するために、DMVRを使用して潜在的に改良される、動きベクトルを使用し得る。
[0203]ビデオデコーダ300は、次いで、量子化変換係数のブロックを作成するために、再生された係数を逆走査し得る(376)。ビデオデコーダ300は、次いで、残差ブロックを作り出すために、係数を逆量子化および逆変換し得る(378)。ビデオデコーダ300は、予測ブロックと残差ブロックとを組み合わせることによって、最終的に現在ブロックを復号し得る(380)。
[0204]このようにして、図17は、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディングする(すなわち、復号する)方法の一例を表す。
[0205]図18は、本開示の技法による、ビデオデータのブロックをコーディングする方法の一例を示すフローチャートである。図18の方法は、ビデオエンコーダ200またはビデオデコーダ300などの、ビデオコーディングデバイスによって実行され得る。例として、図18の方法はビデオデコーダ300に関して説明されるが、ビデオエンコーダ200などの他のビデオコーディングデバイスが、この方法または類似の方法を実行し得る。
[0206]最初に、ビデオデコーダ300は、ブロックのサイズを決定する(400)。たとえば、ビデオデコーダ300は、木構造の中の分割を決定するために、コーディングツリーユニット(CTU)に関連する木構造を復号し得、最終的に木構造のリーフノードを識別する。分割の数、ツリータイプ、および分割のタイプを使用して、ビデオデコーダ300は、ブロックのサイズ、たとえば、ピクセルの単位でのブロックの幅と高さとを決定し得る。ビデオエンコーダ200によって実行されるとき、ビデオエンコーダ200は、最良のパフォーマンスのレートひずみ値をもたらすCTUの区分を決定するために、様々な異なるブロックサイズとCTUの区分パターンとをテストすることによってブロックのサイズを決定し得る。
[0207]ビデオデコーダ300は、次いで、ブロックの幅が8ピクセルよりも小さいか、ブロックの高さが8ピクセルよりも小さいか、それともブロックのサイズが8×8に等しいかのいずれかを決定し得る(482)。これらのうちのいずれかが真である場合(402の「YES」分岐)、ビデオデコーダ300は、ブロックがDMVRを使用してコーディングされないと決定し得る(404)。したがって、ビデオデコーダ300は、たとえば、ブロックを復号することによって、ブロックに対する動きベクトルを決定することに進み得(406)、次いで、動きベクトルを使用してブロックに対する予測ブロックを生成してよい(408)。
[0208]一方、ブロックが、幅または高さのうちの少なくとも1つが8ピクセルよりも大きくて少なくとも8×8というサイズ(すなわち、少なくとも8×NまたはN×8というサイズ、ただし、Nは8よりも大きい整数である)を有する場合(402の「NO」分岐)、ビデオデコーダ300は、たとえば、サイズの決定に基づいて、および/または追加の基準を使用して、ブロックに対してDMVRを実行すべきと決定し得る(410)。いくつかの例では、他の基準は、DMVRが実行されないことになることを示し得る。ビデオデコーダ300は、ブロックに対する動きベクトルを決定し得(412)、DMVRがイネーブルにされることを他の基準が示す場合、動きベクトルに対してDMVRを実行し得(414)、(潜在的に改良された)動きベクトルを使用して予測ブロックを生成し得る(416)。
[0209]いずれの場合も(すなわち、ステップ408または416のいずれかに続いて)、ビデオデコーダ300は、次いで、予測ブロックを使用してブロックをコーディング(すなわち、この例では復号)し得る(418)。
[0210]このようにして、図18は、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することと、ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい幅および高さのうちの、少なくとも1つを有すると決定することに応答して、ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、ブロックがDMVRを使用してコーディングされないと決定することに応答して、ブロックに対してDMVRを実行することなくブロックをコーディングすることと、を含む、ビデオデータのブロックをコーディング(符号化または復号)する方法の一例を表す。
[0211]例に応じて、本明細書で説明した技法のいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る(たとえば、説明したすべての行為またはイベントが本技法の実践のために必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して並行して実行され得る。
[0212]1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶またはコンピュータ可読媒体を介して送信されてよく、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に相当するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含んでよい。このようにして、コンピュータ可読媒体は、概して、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に相当し得る。データ記憶媒体は、本開示で説明した技法の実施のための命令、コード、および/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含んでよい。
[0213]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的な有形の記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびBlu-rayディスク(disc)を含み、ここで、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
[0214]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の均等な集積論理回路構成もしくは個別論理回路構成などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」および「処理回路構成」という用語は、上記の構造または本明細書で説明した技法の実装にとって好適な任意の他の構造のうちのいずれかを指してよい。加えて、いくつかの態様では、本明細書で説明する機能性は、符号化および復号のために構成された専用ハードウェアおよび/もしくはソフトウェアモジュール内で提供されてよく、または組み合わせられたコーデックの中に組み込まれてよい。また、本技法は、1つまたは複数の回路または論理要素で十分に実装され得る。
[0215]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置で実装され得る。開示する技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが本開示で説明されるが、異なるハードウェアユニットによる実現を必ずしも必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明したような1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットの中で組み合わせられてよく、または相互動作可能なハードウェアユニットの集合によって提供されてよい。
[0216]様々な例が説明されている。これらおよび他の例は、以下の特許請求の範囲内に入る。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビデオデータをコーディングする方法であって、
ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有すると決定することと、
ビデオデータの前記ブロックが、8ピクセルよりも小さい前記幅、8ピクセルよりも小さい前記高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも1つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
を備える方法。
[C2]
前記ブロックは、第1のブロックを備え、前記方法は、
ビデオデータの第2のブロックが少なくとも8×NまたはN×8というサイズを有すると決定することと、ここにおいて、Nは8よりも大きい整数値であり、
ビデオデータの前記第2のブロックが少なくとも8×NまたはN×8という前記サイズを有すると決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすべきかどうかを決定することと、
DMVRを使用して前記第2のブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすることと、をさらに備える、
C1に記載の方法。
[C3]
前記第2のブロックをコーディングすることは、
前記第2のブロックが双方向オプティカルフロー(BIO)を使用して予測されることになるとき、前記第2のブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
前記パディングされたフィルタ入力サンプルを使用して、前記第2のブロックの1つまたは複数のサンプルに対する1つまたは複数の勾配値を計算することと、
前記勾配値を使用して、前記第2のブロックの前記1つまたは複数のサンプルに対する1つまたは複数の改良された動きベクトルを計算することと、
前記1つまたは複数の改良された動きベクトルを使用して、前記第2のブロックに対する予測ブロックを生成することと、を備える、
C2に記載の方法。
[C4]
前記第2のブロックは、wサンプルの幅とhサンプルの高さとを備え、
前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、前記取り出されたサンプルを(w+7+2d)*(h+7+2d)というサイズにパディングすることと、を備え、ここにおいて、dは、予め定義された最大変位ベクトルを表す、C3に記載の方法。
[C5]
前記1つまたは複数の勾配値を計算することは、Lという長さを有する勾配フィルタを使用して前記1つまたは複数の勾配値を計算することを備え、
前記第2のブロックは、wサンプルの幅とhサンプルの高さとを備え、
前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、前記取り出されたサンプルを(w+7+2d+2s)*(h+7+2d+2s)というサイズにパディングすることと、を備え、ここにおいて、dは、予め定義された最大変位ベクトルを表し、sは、Lの半分を表す、C3に記載の方法。
[C6]
前記第2のブロックは、wサンプルの幅とhサンプルの高さとを備え、
前記パディングされたフィルタ入力サンプルを取り出すことは、
前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、
前記取り出されたサンプルを(w+11)*(h+7)というサイズに水平にパディングすることと、
前記パディングされたサンプルを(w+11-t)*(h+7)というサイズに水平に補間することと、
前記水平に補間されパディングされたサンプルを(w+11-t)*(h+11)というサイズに垂直にパディングすることと、を備える、
C3に記載の方法。
[C7]
前記第2のブロックに対する初期動きベクトルを復号することをさらに備え、
前記1つまたは複数の改良された動きベクトルを計算することは、前記初期動きベクトルを使用して、前記1つまたは複数の改良された動きベクトルを計算することを備える、C3に記載の方法。
[C8]
前記ブロックをコーディングすることは、
前記ブロックに対する動きベクトルを復号することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックに対する残差ブロックを復号することと、
前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を備える、
C1に記載の方法。
[C9]
前記ブロックをコーディングすることは、
前記ブロックに対する動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を備える、
C1に記載の方法。
[C10]
前記ブロックをコーディングすることは、
前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックの右上の隣接ブロックの改良された動きベクトルを取り出すことと、
前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
C1に記載の方法。
[C11]
前記ブロックをコーディングすることは、
前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックに隣接する仮想パイプラインデータユニット(VPDU)の改良された動きベクトルを取り出すことと、ここにおいて、前記VPDUは、コーディングツリーユニット(CTU)の4つのVPDUのうちの1つを備え、前記4つのVPDUは、前記CTUの均等に分割された4分の1のブロックであり、
前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
C1に記載の方法。
[C12]
前記ブロックをコーディングすることは、
前記ブロックの動きベクトルに対する1つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測(HMVP)リストを生成することと、
改良された動きベクトルを使用して以前のブロックを復号することに応答して、前記HMVPリストの中への前記改良された動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがディセーブルにされることを示し、
前記HMVPリストの前記動きベクトル予測子候補のうちの1つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
C1に記載の方法。
[C13]
前記ブロックをコーディングすることは、
前記ブロックの動きベクトルに対する1つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測(HMVP)リストを生成することと、
改良された制御点動きベクトルを使用して以前のブロックを復号することに応答して、前記HMVPリストの中への前記改良された制御点動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがイネーブルにされることを示し、
前記HMVPリストの前記動きベクトル予測子候補のうちの1つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
C1に記載の方法。
[C14]
前記ブロックをコーディングすることは、
前記ブロックの因果的隣接サブブロックから、前記ブロックの動きベクトルに対するアフィンマージ候補を決定することを備え、ここにおいて、前記アフィンマージ候補を決定することは、
前記因果的隣接サブブロックが、前記ブロックを含むコーディングツリーユニット(CTU)行の上の隣接CTU行の中にあるとき、前記アフィンマージ候補として、前記因果的隣接サブブロックの改良された動きベクトルを選択すること、または
前記因果的隣接サブブロックが、前記ブロックを含む前記CTU行の中にあるとき、前記アフィンマージ候補として、前記改良された動きベクトルを生成するために使用される未改良の動きベクトルを選択することと、
前記アフィンマージ候補を使用して、前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
C1に記載の方法。
[C15]
前記ブロックをコーディングすることは、
コスト関数を使用してコスト値を計算するために使用される重み値に適用されるべき正の整数スカラー(s)値を決定することと、
前記コスト関数、および前記s値を使用して、前記ブロックの予測ブロックのサンプルに対する前記コスト値を計算することと、
一般化双予測(GBi)または重み付き双予測(WP)のうちの少なくとも1つに従って、前記コスト値を使用して前記予測ブロックを生成することと、を備える、
C1に記載の方法。
[C16]
前記s値を決定することは、
GBiに対して、s=8を決定すること、
ルーマWPに対して、s=2 luma_log2_weight_denom+Max(2,14-LumaBitDepth) を決定すること、または
クロマWPに対して、s=2 luma_log2_weight_denom+delta_chroma_log2_weight_denom+Max(2,14-ChromaBitDepth) を決定すること、を備える、
C15に記載の方法。
[C17]
ビデオデータをコーディングするためのデバイスであって、
ビデオデータを記憶するように構成されたメモリと、
回路の中に実装された1つまたは複数のプロセッサと、
を備え、前記1つまたは複数のプロセッサは、
ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有すると決定することと、
ビデオデータの前記ブロックが、8ピクセルよりも小さい前記幅、8ピクセルよりも小さい前記高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも1つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
を行うように構成される、
デバイス。
[C18]
前記ブロックは、第1のブロックを備え、
前記1つまたは複数のプロセッサは、
ビデオデータの第2のブロックが少なくとも8×NまたはN×8というサイズを有すると決定することと、ここにおいて、Nが8よりも大きい整数値であり、
ビデオデータの前記第2のブロックが少なくとも8×NまたはN×8という前記サイズを有すると決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすべきかどうかを決定することと、
DMVRを使用して前記第2のブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすることと、
を行うようにさらに構成される、
C17に記載のデバイス。
[C19]
前記第2のブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記第2のブロックが双方向オプティカルフロー(BIO)を使用して予測されることになるとき、前記第2のブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
前記パディングされたフィルタ入力サンプルを使用して、前記第2のブロックの1つまたは複数のサンプルに対する1つまたは複数の勾配値を計算することと、
前記勾配値を使用して、前記第2のブロックの前記1つまたは複数のサンプルに対する1つまたは複数の改良された動きベクトルを計算することと、
前記1つまたは複数の改良された動きベクトルを使用して、前記第2のブロックに対する予測ブロックを生成することと、を行うように構成される、
C18に記載のデバイス。
[C20]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックに対する動きベクトルを復号することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックに対する残差ブロックを復号することと、
前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を行うように構成される、
C17に記載のデバイス。
[C21]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックに対する動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を行うように構成される、
C17に記載のデバイス。
[C22]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックの右上の隣接ブロックの改良された動きベクトルを取り出すことと、
前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C23]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックの動きベクトルに対する動きベクトル予測子として、前記ブロックに隣接する仮想パイプラインデータユニット(VPDU)の改良された動きベクトルを取り出すことと、ここにおいて、前記VPDUは、コーディングツリーユニット(CTU)の4つのVPDUのうちの1つを備え、前記4つのVPDUは、前記CTUの均等に分割された4分の1のブロックであり、
前記動きベクトル予測子を使用して、前記現在ブロックに対する前記動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C24]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックの動きベクトルに対する1つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測(HMVP)リストを生成することと、
改良された動きベクトルを使用して以前のブロックを復号することに応答して、前記HMVPリストの中への前記改良された動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがディセーブルにされることを示し、
前記HMVPリストの前記動きベクトル予測子候補のうちの1つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C25]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックの動きベクトルに対する1つまたは複数の動きベクトル予測子候補を含む履歴ベース動きベクトル予測(HMVP)リストを生成することと、
改良された制御点動きベクトルを使用して以前のブロックを復号することに応答して、前記HMVPリストの中への前記改良された制御点動きベクトルの挿入を止めることと、ここにおいて、前記以前のブロックに対するアフィンフラグは、前記以前のブロックに対してアフィン動きがイネーブルにされることを示し、
前記HMVPリストの前記動きベクトル予測子候補のうちの1つを使用して、前記ブロックに対する前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C26]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
前記ブロックの因果的隣接サブブロックから、前記ブロックの動きベクトルに対するアフィンマージ候補を決定するように構成され、ここにおいて、前記アフィンマージ候補を決定するために、前記1つまたは複数のプロセッサは、
前記因果的隣接サブブロックが、前記ブロックを含むコーディングツリーユニット(CTU)行の上の隣接CTU行の中にあるとき、前記アフィンマージ候補として、前記因果的隣接サブブロックの改良された動きベクトルを選択すること、または
前記因果的隣接サブブロックが、前記ブロックを含む前記CTU行の中にあるとき、前記アフィンマージ候補として、前記改良された動きベクトルを生成するために使用される未改良の動きベクトルを選択することと、
前記アフィンマージ候補を使用して、前記動きベクトルをコーディングすることと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C27]
前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
コスト関数を使用してコスト値を計算するために使用される重み値に適用されるべき正の整数スカラー(s)値を決定することと、
前記コスト関数、および前記s値を使用して、前記ブロックの予測ブロックのサンプルに対する前記コスト値を計算することと、
一般化双予測(GBi)または重み付き双予測(WP)のうちの少なくとも1つに従って、前記コスト値を使用して前記予測ブロックを生成することと、を行うように構成される、
C17に記載のデバイス。
[C28]
前記ビデオデータを表示するように構成されたディスプレイをさらに備える、C17に記載のデバイス。
[C29]
カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、またはセットトップボックスのうちの1つまたは複数を備える、C17に記載のデバイス。
[C30]
命令が記憶されたコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有すると決定することと、
ビデオデータの前記ブロックが、8ピクセルよりも小さい前記幅、8ピクセルよりも小さい前記高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも1つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
を行わせる、
コンピュータ可読記憶媒体。
[C31]
前記ブロックは、第1のブロックを備え、
前記コンピュータ可読記憶媒体は、さらに、前記プロセッサに、
ビデオデータの第2のブロックが少なくとも8×NまたはN×8というサイズを有すると決定することと、ここにおいて、Nは8よりも大きい整数値であり、
ビデオデータの前記第2のブロックが少なくとも8×NまたはN×8という前記サイズを有することを決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすべきかどうかを決定することと、
DMVRを使用して前記第2のブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすることと、
を行わせる命令を備える、
C30に記載のコンピュータ可読記憶媒体。
[C32]
前記プロセッサに前記ブロックをコーディングさせる前記命令は、前記プロセッサに、
前記ブロックに対する動きベクトルを復号することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックに対する残差ブロックを復号することと、
前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を行わせる命令を備える、
C30に記載のコンピュータ可読記憶媒体。
[C33]
前記プロセッサに前記ブロックをコーディングさせる前記命令は、前記プロセッサに、
前記ブロックに対する動きベクトルを生成することと、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を行わせる命令を備える、
C30に記載のコンピュータ可読記憶媒体。
[C34]
ビデオデータをコーディングするためのデバイスであって、
ビデオデータのブロックが、8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有すると決定するための手段と、
ビデオデータの前記ブロックが、8ピクセルよりも小さい前記幅、8ピクセルよりも小さい前記高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの前記少なくとも1つを有すると決定することに応答して、前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定するための手段と、
前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングするための手段と、
を備えるデバイス。
[C35]
前記ブロックは、第1のブロックを備え、前記デバイスは、
ビデオデータの第2のブロックが少なくとも8×NまたはN×8というサイズを有すると決定するための手段と、ここにおいて、Nは8よりも大きい整数値であり、
ビデオデータの前記第2のブロックが少なくとも8×NまたはN×8という前記サイズを有すると決定することに応答して、DMVRを使用して前記第2のブロックをコーディングすべきかどうかを決定するための手段と、
DMVRを使用して前記第2のブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記第2のブロックをコーディングするための手段と、をさらに備える、
C34に記載のデバイス。
[C36]
前記ブロックをコーディングするための前記手段は、
前記ブロックに対する動きベクトルを復号するための手段と、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算するための手段と、
前記ブロックに対する残差ブロックを復号するための手段と、
前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせるための手段と、を備える、
C34に記載のデバイス。
[C37]
前記ブロックをコーディングするための前記手段は、
前記ブロックに対する動きベクトルを生成するための手段と、
前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算するための手段と、
前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成するための手段と、
前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化するための手段と、を備える、
C34に記載のデバイス。

Claims (13)

  1. ビデオデータをコーディングする方法であって、
    ビデオデータのブロックのサイズを決定することと、
    8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有する各ブロックについて、
    前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
    前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
    少なくとも8×NまたはN×8というサイズを有する各ブロックについて、ここにおいて、Nは8よりも大きい整数値であり、
    DMVRを使用して前記ブロックをコーディングすべきと決定することと、
    DMVRを使用して前記ブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記ブロックをコーディングすることと、
    を備え、
    DMVRを使用して前記ブロックをコーディングすることは、
    前記ブロックに対する参照ピクチャから取り出されたサンプルを垂直にパディングすることなく、水平にパディングすることと、
    前記水平にパディングされたサンプルを水平補間した後に、水平補間結果を垂直にパディングすることと、
    を備える、方法。
  2. DMVRを使用して前記ブロックをコーディングすることは、
    前記ブロックが双方向オプティカルフロー(BIO)を使用して予測されることになるとき、前記ブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
    前記パディングされたフィルタ入力サンプルを使用して、前記ブロックの1つまたは複数のサンプルに対する1つまたは複数の勾配値を計算することと、
    前記勾配値を使用して、前記ブロックの前記1つまたは複数のサンプルに対する1つまたは複数の改良された動きベクトルを計算することと、
    前記1つまたは複数の改良された動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を備える、
    請求項に記載の方法。
  3. 前記ブロックは、wサンプルの幅とhサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、前記取り出されたサンプルを(w+7+2d)*(h+7+2d)というサイズにパディングすることと、を備え、ここにおいて、dは、予め定義された最大変位ベクトルを表す、請求項に記載の方法。
  4. 前記1つまたは複数の勾配値を計算することは、Lという長さを有する勾配フィルタを使用して前記1つまたは複数の勾配値を計算することを備え、
    前記ブロックは、wサンプルの幅とhサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、前記取り出されたサンプルを(w+7+2d+2s)*(h+7+2d+2s)というサイズにパディングすることと、を備え、ここにおいて、dは、予め定義された最大変位ベクトルを表し、sは、Lの半分を表す、請求項に記載の方法。
  5. 前記ブロックは、wサンプルの幅とhサンプルの高さとを備え、
    前記パディングされたフィルタ入力サンプルを取り出すことは、
    前記参照ピクチャから(w+7)*(h+7)サンプルを取り出すことと、
    前記取り出されたサンプルを(w+11)*(h+7)というサイズに水平にパディングすることと、
    前記パディングされたサンプルを(w+11-t)*(h+7)というサイズに水平に補間することと、
    前記水平に補間されパディングされたサンプルを(w+11-t)*(h+11)というサイズに垂直にパディングすることと、を備え、ここにおいて、tは、補間フィルタタップの数-1である、
    請求項に記載の方法。
  6. 前記ブロックに対する初期動きベクトルを復号することをさらに備え、
    前記1つまたは複数の改良された動きベクトルを計算することは、前記初期動きベクトルを使用して、前記1つまたは複数の改良された動きベクトルを計算することを備える、請求項に記載の方法。
  7. 前記ブロックをコーディングすることは、
    前記ブロックに対する動きベクトルを復号することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックに対する残差ブロックを復号することと、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を備える、または、
    前記ブロックをコーディングすることは、
    前記ブロックに対する動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、を備える、
    請求項1に記載の方法。
  8. ビデオデータをコーディングするためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    回路の中に実装された1つまたは複数のプロセッサと、
    を備え、前記1つまたは複数のプロセッサは、
    ビデオデータのブロックのサイズを決定することと、
    8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有する各ブロックについて、
    前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
    前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
    少なくとも8×NまたはN×8というサイズを有する各ブロックについて、ここにおいて、Nは8よりも大きい整数値であり、
    DMVRを使用して前記ブロックをコーディングすべきと決定することと、
    DMVRを使用して前記ブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記ブロックをコーディングすることと、
    を行うように構成され、
    DMVRを使用して前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
    前記ブロックに対する参照ピクチャから取り出されたサンプルを垂直にパディングすることなく、水平にパディングすることと、
    前記水平にパディングされたサンプルを水平補間した後に、水平補間結果を垂直にパディングすることと、
    を行うように構成される、
    デバイス。
  9. 前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
    前記ブロックが双方向オプティカルフロー(BIO)を使用して予測されることになるとき、前記ブロックに対する参照ピクチャのパディングされたフィルタ入力サンプルを取り出すことと、
    前記パディングされたフィルタ入力サンプルを使用して、前記ブロックの1つまたは複数のサンプルに対する1つまたは複数の勾配値を計算することと、
    前記勾配値を使用して、前記ブロックの前記1つまたは複数のサンプルに対する1つまたは複数の改良された動きベクトルを計算することと、
    前記1つまたは複数の改良された動きベクトルを使用して、前記ブロックに対する予測ブロックを生成することと、を行うように構成される、
    請求項に記載のデバイス。
  10. 前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
    前記ブロックに対する動きベクトルを復号することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックに対する残差ブロックを復号することと、
    前記ブロックを復号するために、前記予測ブロックを前記残差ブロックと組み合わせることと、を行うように構成される、または、
    前記ブロックをコーディングするために、前記1つまたは複数のプロセッサは、
    前記ブロックに対する動きベクトルを生成することと、
    前記動きベクトルを使用して、前記ブロックに対する予測ブロックを計算することと、
    前記ブロックと前記予測ブロックとの間の差分を表す、前記ブロックに対する残差ブロックを生成することと、
    前記ブロックを符号化するために、前記残差ブロックと前記動きベクトルとを符号化することと、
    を行うように構成される、
    請求項に記載のデバイス。
  11. 前記ビデオデータを表示するように構成されたディスプレイをさらに備える、または、前記デバイスは、カメラ、コンピュータ、モバイルデバイス、ブロードキャスト受信機デバイス、またはセットトップボックスのうちの1つまたは複数を備える、請求項に記載のデバイス。
  12. 命令が記憶されたコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
    ビデオデータのブロックのサイズを決定することと、
    8ピクセルよりも小さい幅、8ピクセルよりも小さい高さ、または8ピクセルに等しい前記幅および前記高さ、のうちの少なくとも1つを有する各ブロックについて、
    前記ブロックがデコーダ側動きベクトル改良(DMVR)を使用してコーディングされないと決定することと、
    前記ブロックがDMVRを使用してコーディングされないと決定することに応答して、前記ブロックに対してDMVRを実行することなく前記ブロックをコーディングすることと、
    少なくとも8×NまたはN×8というサイズを有する各ブロックについて、ここにおいて、Nは8よりも大きい整数値であり、
    DMVRを使用して前記ブロックをコーディングすべきと決定することと、
    DMVRを使用して前記ブロックをコーディングすべきと決定することに応答して、DMVRを使用して前記ブロックをコーディングすることと、
    を行わせ、
    DMVRを使用して前記ブロックをコーディングすることは、
    前記ブロックに対する参照ピクチャから取り出されたサンプルを垂直にパディングすることなく、水平にパディングすることと、
    前記水平にパディングされたサンプルを水平補間した後に、水平補間結果を垂直にパディングすることと、
    を備える、コンピュータ可読記憶媒体。
  13. 前記コンピュータ可読記憶媒体は、さらに、前記プロセッサに、請求項2乃至のうちのいずれか一項に記載の方法を実行させる命令を備える、
    請求項12に記載のコンピュータ可読記憶媒体。
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 2019-11-26
US16/695,907 US11146810B2 (en) 2018-11-27 2019-11-26 Decoder-side motion vector refinement
PCT/US2019/063673 WO2020113051A2 (en) 2018-11-27 2019-11-27 Decoder-side motion vector refinement

Publications (3)

Publication Number Publication Date
JP2022507683A JP2022507683A (ja) 2022-01-18
JPWO2020113051A5 JPWO2020113051A5 (ja) 2022-11-08
JP7446297B2 true 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 (1) CN113039787A (ja)
BR (1) BR112021009606A2 (ja)
CL (1) CL2021001335A1 (ja)
SG (1) SG11202104085RA (ja)
WO (1) WO2020113051A2 (ja)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110662057B (zh) 2018-06-29 2022-06-21 北京字节跳动网络技术有限公司 视频处理方法、装置、设备以及存储比特流的方法
CN115134599A (zh) 2018-06-29 2022-09-30 抖音视界有限公司 更新查找表(lut)的条件
TWI723444B (zh) 2018-06-29 2021-04-01 大陸商北京字節跳動網絡技術有限公司 使用一個或多個查找表來按順序存儲先前編碼的運動信息並使用它們來編碼後面的塊的概念
BR112020024202A2 (pt) 2018-06-29 2021-02-17 Beijing Bytedance Network Technology Co., Ltd. método de processamento de dados de vídeo, aparelho de processamento de vídeo e meios de armazenamento e gravação legíveis por computador não transitório
MX2020013828A (es) 2018-06-29 2021-03-25 Beijing Bytedance Network Tech Co Ltd Interaccion entre lut y amvp.
TWI752331B (zh) 2018-06-29 2022-01-11 大陸商北京字節跳動網絡技術有限公司 當向Merge/AMVP添加HMVP候選時的部分/完全修剪
EP3791589A1 (en) 2018-06-29 2021-03-17 Beijing Bytedance Network Technology Co. Ltd. Which lut to be updated or no updating
JP7181395B2 (ja) 2018-07-02 2022-11-30 北京字節跳動網絡技術有限公司 イントラ予測モードを有するルックアップテーブルおよび非隣接ブロックからのイントラモード予測
TWI820211B (zh) 2018-09-12 2023-11-01 大陸商北京字節跳動網絡技術有限公司 取決於總數減去k的開始檢查hmvp候選的條件
JP7005480B2 (ja) * 2018-12-27 2022-01-21 Kddi株式会社 画像復号装置、画像符号化装置、プログラム及び画像処理システム
US11102476B2 (en) * 2018-12-28 2021-08-24 Qualcomm Incorporated Subblock based affine motion model
CN113475078A (zh) * 2019-01-08 2021-10-01 腾讯美国有限责任公司 用于小帧间块的存储器带宽减小的方法和装置
KR20240010576A (ko) * 2019-01-10 2024-01-23 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 Lut 업데이트의 호출
CN113383554B (zh) 2019-01-13 2022-12-16 北京字节跳动网络技术有限公司 LUT和共享Merge列表之间的交互
WO2020147772A1 (en) 2019-01-16 2020-07-23 Beijing Bytedance Network Technology Co., Ltd. Motion candidates derivation
JP7232345B2 (ja) * 2019-02-08 2023-03-02 ベイジン・ダジア・インターネット・インフォメーション・テクノロジー・カンパニー,リミテッド ビデオ符号化のための双方向オプティカルフローおよびデコーダ側動きベクトル補正を選択的に適用する方法およびデバイス
WO2020164577A1 (en) * 2019-02-14 2020-08-20 Beijing Bytedance Network Technology Co., Ltd. Selective application of decoder side refining tools
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
CN113545041A (zh) * 2019-03-07 2021-10-22 数字洞察力有限公司 图像编码/解码方法和设备
CN113615193A (zh) 2019-03-22 2021-11-05 北京字节跳动网络技术有限公司 Merge列表构建和其他工具之间的交互
US20200402546A1 (en) * 2019-06-24 2020-12-24 Seagate Technology Llc Reducing base deck porosity
US20220264146A1 (en) * 2019-07-01 2022-08-18 Interdigital Vc Holdings France, Sas Bi-prediction refinement in affine with optical flow
BR112022005408A2 (pt) * 2019-09-30 2022-11-29 Huawei Tech Co Ltd Restrições de modelo de movimento afim que reduzem número de linhas de referência buscadas durante processamento de uma linha de bloco com filtro de interpolação aprimorado
JP7482220B2 (ja) 2019-10-18 2024-05-13 北京字節跳動網絡技術有限公司 サブピクチャのパラメータセットシグナリングにおける構文制約
US11399188B2 (en) * 2020-01-01 2022-07-26 Tencent America LLC Method for mixed NAL unit type support in a coded picture
CN115398892A (zh) * 2020-03-23 2022-11-25 抖音视界有限公司 仿射merge和仿射运动矢量预测模式的预测细化
EP4222962A4 (en) * 2020-10-15 2024-03-20 Beijing Dajia Internet Information Tech Co Ltd IMPROVED MOTION ESTIMATION FOR INTERCODING
KR20240050408A (ko) * 2021-08-27 2024-04-18 주식회사 윌러스표준기술연구소 움직임 정보를 보정하는 방법 및 이를 위한 장치
WO2023088472A1 (en) * 2021-11-22 2023-05-25 Beijing Bytedance Network Technology Co., Ltd. Method, apparatus, and medium for video processing
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 (17)

* 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
CN110115032B (zh) * 2016-12-22 2021-07-20 联发科技股份有限公司 用于视频编解码的运动细化的方法以及装置
US20180192071A1 (en) * 2017-01-05 2018-07-05 Mediatek 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
WO2019089933A1 (en) 2017-11-01 2019-05-09 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
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,JVET-K0119,11th Meeting: Ljubljana, Slovenia,2018年07月,pp.1-3
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,JVET-L0267-v1,12th Meeting: Macao, CN,2018年09月,pp.1-4
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,JVET-L0163,12th Meeting: Macao, CN,2018年10月,pp.1-7
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,JVET-J0020-v1,10th Meeting: San Diego, US,2018年04月,pp.10-11,49-51

Also Published As

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

Similar Documents

Publication Publication Date Title
JP7446297B2 (ja) デコーダ側動きベクトル改良
JP7367018B2 (ja) 履歴ベースの動きベクトル予測の簡略化
JP7278333B2 (ja) 復号器側動きベクトル導出によって導出された動きベクトル情報を制約すること
TWI736872B (zh) 基於解碼器側運動向量推導之運動向量預測推導之限制
CN110771164B (zh) 视频译码中的帧间预测与帧内预测的组合
TWI717586B (zh) 於視訊解碼器中導出運動向量資訊
US11190797B2 (en) Constraints on decoder-side motion vector refinement based on weights for bi-predicted prediction
CN113196749B (zh) 用于译码视频数据的方法和设备
TW202025752A (zh) 用於仿射模式之以歷史為基礎之運動向量預測
CN112806012A (zh) 用于帧间预测译码的基于历史的运动向量预测
TW201924345A (zh) 寫碼用於視頻寫碼之仿射預測移動資訊
TW201711463A (zh) 判定用於視訊寫碼之照明補償狀態之系統及方法
TW201703531A (zh) 判定用於視訊寫碼之照明補償狀態之系統及方法
JP7474774B2 (ja) ビデオコーディングにおけるイントラブロックコピーモードのための動きベクトル予測子リスト生成
US11122288B2 (en) Spatio-temporal motion vector prediction patterns for video coding
JP7379391B2 (ja) シグナリングサブ予測ユニット動きベクトル予測子
US20230007238A1 (en) Using unrefined motion vectors for performing decoder-side motion vector derivation
US11528504B2 (en) Motion vector prediction with motion information collecting buffer
TWI704799B (zh) 取決於形狀的插值順序
JP2024508216A (ja) ビデオコーディングのためのモデルベースの動きベクトル差分導出およびテンプレート照合予測

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