JP7335358B2 - 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置 - Google Patents

適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置 Download PDF

Info

Publication number
JP7335358B2
JP7335358B2 JP2021564599A JP2021564599A JP7335358B2 JP 7335358 B2 JP7335358 B2 JP 7335358B2 JP 2021564599 A JP2021564599 A JP 2021564599A JP 2021564599 A JP2021564599 A JP 2021564599A JP 7335358 B2 JP7335358 B2 JP 7335358B2
Authority
JP
Japan
Prior art keywords
motion vector
syntax element
flag
affine
enabled
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
JP2021564599A
Other languages
English (en)
Other versions
JP2022531264A (ja
Inventor
ゴンジュン・コ
ドンチョル・キム
ジュヒョン・ソン
ジェホン・ジュン
ジンサム・カク
Original Assignee
ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド
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 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド filed Critical ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド
Publication of JP2022531264A publication Critical patent/JP2022531264A/ja
Priority to JP2023133080A priority Critical patent/JP2023164843A/ja
Application granted granted Critical
Publication of JP7335358B2 publication Critical patent/JP7335358B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • H04N19/52—Processing of motion vectors by encoding by predictive encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/117—Filters, e.g. for pre-processing or post-processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/537—Motion estimation other than block-based
    • H04N19/54—Motion estimation other than block-based using feature points or meshes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本発明は、ビデオ信号の処理方法及び装置に関し、より詳細には、イントラ予測に基づいてビデオ信号をエンコード又はデコードするビデオ信号処理方法及び装置に関する。
圧縮符号化とは、デジタル化した情報を通信回線を介して伝送するか、貯蔵媒体に適合した形態に貯蔵するための一連の信号処理技術を意味する。圧縮符号化の対象としては音声、映像、文字などの対象が存在するが、特に映像を対象とする圧縮符号化を行う技術をビデオ映像圧縮と称する。ビデオ信号に対する圧縮符号化は、空間的な相関関係、時間的な相関関係、確率的な相関関係などを考慮して剰余情報を除去することで行われる。しかし、最近の多様なメディア及びデータ伝送媒体の発展によって、より高効率のビデオ信号処理方法及び装置が求められている。
本開示の目的は、ビデオ信号のコーディング効率を上げることにある。
本開示の一実施例によるビデオ信号を処理する方法は、ビットストリームから適応的な動きベクトル差分解像度が使用されるのか否かを示すＡＭＶＲ（Ａｄａｐｔｉｖｅ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｒｅｓｏｌｕｔｉｏｎ）可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングするステップと、ビットストリームからアフィン動き補償が使用可能であるのか否かを示すアフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングするステップと、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいてアフィン動き補償が使用可能であるのか否かを決定するステップと、アフィン動き補償が使用可能であれば、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいて適応的な動きベクトル差分解像度が使用されるのか否かを決定するステップと、適応的な動きベクトル差分解像度が使用されれば、ビットストリームからアフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であるのか否かを示すアフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングするステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法において、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、またはアフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）のうち一つは、Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ、スライス（ｓｌｉｃｅ）、タイル（ｔｉｌｅ）、タイルグループ（ｔｉｌｅ ｇｒｏｕｐ）、映像（ｐｉｃｔｕｒｅ）、またはシーケンス（ｓｅｑｕｅｎｃｅ）単位のうち一つでシグナリングされることを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法において、アフィン動き補償が使用可能で、適応的な動きベクトル差分解像度が使用されていない場合、アフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）はアフィン動き補償に対して適応的な動きベクトル差分解像度が使用不可能であることを暗示することを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法において、アフィン動き補償が使用不可能な場合、アフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）はアフィン動き補償に対して適応的な動きベクトル差分解像度が使用不可能であることを暗示（ｉｎｆｅｒｅｄ）することを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）が適応的な動きベクトル差分解像度の使用を示し、ビットストリームから獲得されたインターアフィンフラッグ（ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ）が現在ブロックに対してアフィン動き補償が使用されていないことを示し、現在ブロックに対する複数の動きベクトル差分のうち少なくとも一つが０でなければ、ビットストリームから動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）に関する情報をパージングするステップと、動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する複数の動きベクトル差分を修正するステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、アフィンＡＭＶＲ可能フラッグがアフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であることを示し、ビットストリームから獲得されたインターアフィンフラッグ（ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ）が現在ブロックに対してアフィン動き補償の使用を示し、現在ブロックに対する複数のコントロールポイント動きベクトル差分のうち少なくとも一つが０でなければ、ビットストリームから動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）に関する情報をパージングするステップと、動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する複数のコントロールポイント動きベクトル差分を修正するステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、現在ブロックに対して参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）を獲得するステップと、参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が第０参照ピクチャリスト（ｌｉｓｔ ０）のみを使用するものではないことを示す場合、ビットストリームから第１参照ピクチャリスト（ｌｉｓｔ １）の動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）をパージングするステップと、動きベクトル予測子の候補子を生成するステップと、動きベクトル予測子インデックスに基づいて動きベクトル予測子の候補子から動きベクトル予測子を獲得するステップと、動きベクトル予測子に基づいて現在ブロックを予測するステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、ビットストリームから、第１参照ピクチャリストに対して動きベクトル差分及び複数のコントロールポイント動きベクトル差分が０に設定されるのか否かを示す動きベクトル差分ゼロフラッグ（ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ）を獲得するステップを更に含み、動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）をパージングするステップは、動きベクトル差分ゼロフラッグ（ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ）が１で、参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が第０参照ピクチャリスト及び第１参照ピクチャリストをいずれも使用することを示すのか否かに関わらずに動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）をパージングするステップを含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、マージ動きベクトル予測に対する候補の最大個数に関する第１情報（ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ）をビットストリームからシーケンス単位でパージングするステップと、第１情報に基づいてマージ候補の最大個数を獲得するステップと、インター予測のためにブロックをパーティショニング可能であるのか否かを示す第２情報をビットストリームからパージングするステップと、第２情報が１を示し、マージ候補の最大個数が２より大きければ、パーティショニングされたブロックのためのマージモード候補の最大個数に関する第３情報をビットストリームからパージングするステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、第２情報が１を示し、マージ候補の最大個数が３より大きいか同じであれば、マージ候補の最大個数から第３情報を差し引いてパーティショニングされたブロックのためのマージモード候補の最大個数を獲得するステップと、第２情報が１を示し、マージ候補の最大個数が２であれば、パーティショニングされたブロックのためのマージモード候補の最大個数を２に設定するステップと、第２情報が０であるか、マージ候補の最大個数が１であれば、パーティショニングされたブロックのためのマージモード候補の最大個数を０に設定するステップと、を更に含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置は、プロセッサ及びメモリを含み、プロセッサはメモリに保存されている命令語に基づいて、ビットストリームから適応的な動きベクトル差分解像度が使用されるのか否かを示すＡＭＶＲ（Ａｄａｐｔｉｖｅ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｒｅｓｏｌｕｔｉｏｎ）可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングし、ビットストリームからアフィン動き補償が使用可能であるのか否かを示すアフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングし、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいてアフィン動き補償が使用可能であるのか否かを決定し、アフィン動き補償が使用可能であれば、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいて適応的な動きベクトル差分解像度が使用されるのか否かを決定し、適応的な動きベクトル差分解像度が使用されれば、ビットストリームからアフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であるのか否かを示すアフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパージングすることを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、またはアフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）のうち一つは、Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ、スライス（ｓｌｉｃｅ）、タイル（ｔｉｌｅ）、タイルグループ（ｔｉｌｅ ｇｒｏｕｐ）、映像（ｐｉｃｔｕｒｅ）、またはシーケンス（ｓｅｑｕｅｎｃｅ）単位のうち一つでシグナリングされることを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、アフィン動き補償が使用可能で、適応的な動きベクトル差分解像度が使用されていない場合、アフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）はアフィン動き補償に対して適応的な動きベクトル差分解像度が使用不可能であることを暗示することを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、アフィン動き補償が使用不可能な場合、アフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）はアフィン動き補償に対して適応的な動きベクトル差分解像度が使用不可能であることを暗示（ｉｎｆｅｒｅｄ）することを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、プロセッサはメモリに保存されている命令語に基づいて、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）が適応的な動きベクトル差分解像度の使用を示し、ビットストリームから獲得されたインターアフィンフラッグ（ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ）が現在ブロックに対してアフィン動き補償が使用されていないことを示し、現在ブロックに対する複数の動きベクトル差分のうち少なくとも一つが０でなければ、ビットストリームから動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）に関する情報をパージングし、動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する複数の動きベクトル差分を修正することを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、プロセッサはメモリに保存されている命令語に基づいて、アフィンＡＭＶＲ可能フラッグがアフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であることを示し、ビットストリームから獲得されたインターアフィンフラッグ（ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ）が現在ブロックに対してアフィン動き補償の使用を示し、現在ブロックに対する複数のコントロールポイント動きベクトル差分のうち少なくとも一つが０でなければ、ビットストリームから動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）に関する情報をパージングし、動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する複数のコントロールポイント動きベクトル差分を修正することを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、プロセッサはメモリに保存されている命令語に基づいて、現在ブロックに対して参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）を獲得し、参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が第０参照ピクチャリスト（ｌｉｓｔ ０）のみを使用するものではないことを示す場合、ビットストリームから第１参照ピクチャリスト（ｌｉｓｔ １）の動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）をパージングし、動きベクトル予測子の候補子を生成し、動きベクトル予測子インデックスに基づいて動きベクトル予測子の候補子から動きベクトル予測子を獲得し、動きベクトル予測子に基づいて現在ブロックを予測することを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、プロセッサはメモリに保存されている命令語に基づいて、ビットストリームから、第１参照ピクチャリストに対して動きベクトル差分及び複数のコントロールポイント動きベクトル差分が０に設定されるのか否かを示す動きベクトル差分ゼロフラッグ（ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ）を獲得し、動きベクトル差分ゼロフラッグ（ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ）が１で、参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が第０参照ピクチャリスト及び第１参照ピクチャリストをいずれも使用することを示すのか否かに関わらずに動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）をパージングすることを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置は、プロセッサ及びメモリを含み、プロセッサはメモリに保存されている命令語に基づいて、マージ動きベクトル予測に対する候補の最大個数に関する第１情報（ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ）をビットストリームからシーケンス単位でパージングし、第１情報に基づいてマージ候補の最大個数を獲得し、インター予測のためにブロックをパーティショニング可能であるのか否かを示す第２情報をビットストリームからパージングし、第２情報が１を示し、マージ候補の最大個数が２より大きければ、パーティショニングされたブロックのためのマージモード候補の最大個数に関する第３情報をビットストリームからパージングすることを特徴とする。
本開示の一実施例によるビデオ信号を処理する装置において、プロセッサはメモリに保存されている命令語に基づいて、第２情報が１を示し、マージ候補の最大個数が３より大きいか同じであれば、マージ候補の最大個数から第３情報を差し引いてパーティショニングされたブロックのためのマージモード候補の最大個数を獲得し、第２情報が１を示し、マージ候補の最大個数が２であれば、パーティショニングされたブロックのためのマージモード候補の最大個数を２に設定し、第２情報が０であるか、マージ候補の最大個数が１であれば、パーティショニングされたブロックのためのマージモード候補の最大個数を０に設定することを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、適応的な動きベクトル差分解像度が使用されるのか否かを示すＡＭＶＲ（Ａｄａｐｔｉｖｅ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｒｅｓｏｌｕｔｉｏｎ）可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）を生成するステップと、アフィン動き補償が使用可能であるのか否かを示すアフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）を生成するステップと、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいてアフィン動き補償が使用可能であるのか否かを決定するステップと、アフィン動き補償が使用可能であれば、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）に基づいて適応的な動きベクトル差分解像度が使用されるのか否かを決定するステップと、適応的な動きベクトル差分解像度が使用されれば、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であるのか否かを示すアフィンＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）を生成するステップと、ＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、アフィン可能フラッグ（ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）、及びＡＭＶＲ可能フラッグ（ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をエントロピーコーディングしてビットストリームを生成するステップと、を含むことを特徴とする。
本開示の一実施例によるビデオ信号を処理する方法は、マージ候補の最大個数に基づいてマージ動きベクトル予測に対する候補の最大個数に関する第１情報（ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ）を生成するステップと、インター予測のためにブロックをパーティショニング可能であるのか否かを示す第２情報を生成するステップと、第２情報が１を示し、マージ候補の最大個数が２より大きければ、パーティショニングされたブロックのためのマージモード候補の最大個数に関する第３情報を生成するステップと、第１情報（ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ）、第２情報、及び第３情報をエントロピーコーディングしてシーケンス単位でビットストリームに生成するステップと、を含むことを特徴とする。
本開示の実施例によると、ビデオ信号のコーディング効率が上がる。
本開示の実施例によるビデオ信号エンコーダ装置の概略的なブロック図である。 本開示の実施例によるビデオ信号デコーダ装置の概略的なブロック図である。 コーディングユニットを分割する本開示の一実施例を示す図である。 図３の分割構造を階層的に示す方法の一実施例を示す図である。 コーディングユニットを分割する本開示の更なる実施例を示す図である。 画面内予測のための参照ピクセルを獲得する方法を示す図である。 画面ない予測に使用される予測モードの一実施例を示す図である。 本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎを示す図である。 本開示の一実施例による動きベクトルシグナリング方法を示す図である。 本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ ｓｙｎｔａｘを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。 本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄを示す式である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。 本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄを示す式である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのあるモードを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのあるモードを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。 本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。 本開示の一実施例によるｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒの生成方法を示す図である。 図２９で説明した方法によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅの決定方法を示す図である。 本開示の一実施例によるｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒの生成方法を示す図である。 図３１で説明した方法によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅの決定方法を示す図である。 本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ ｓｙｎｔａｘを示す図である。 本開示の一実施例による上位レベルシグナリングの構造を示す図である。 本開示の一実施例によるｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘの構造を示す図である。 本開示の一実施例による上位レベルシグナリングの構造を示す図である。 本開示の一実施例による上位レベルシグナリングの構造を示す図である。 本開示の一実施例によるｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘの構造を示す図である。 本開示の一実施例によるＭＶＤ基本値の設定を示す図である。 本開示の一実施例によるＭＶＤ基本値の設定を示す図である。 本開示の一実施例によるＡＭＶＲに関連するｓｙｎｔａｘの構造を示す図である。 本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。 本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。 本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。 本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘを示す図である。 本開示の一実施例によるｔｒｉａｎｇｌｅ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅを示す図である。 本開示の一実施例によるｍｅｒｇｅ ｄａｔａ ｓｙｎｔａｘを示す図である。 本開示の一実施例による上位レベルシグナリングを示す図である。 本開示の一実施例によるＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示す図である。 本開示の一実施例によるＴＰＭに関する上位レベルシグナリングを示す図である。 本開示の一実施例によるＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示す図である。 本開示の一実施例によるＴＰＭに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔを示す図である。 本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。 本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。 本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。
本明細書で使用される用語は本発明における機能を考慮しながらできるだけ現在広く使用されている一般的な用語を選択したが、これは当分野に携わる技術者の意図、慣例または新たな技術の出現などによって異なり得る。また、特定の場合は出願人が任意に選定した用語もあるが、この場合、該当の発明を実施する形態の部分においてその意味を記載する。よって、本明細書で使用される用語は、単なる用語の名称ではなく、その用語の有する実質的な意味と本明細書全般にわたる内容に基づいて解釈すべきであることを明らかにする。
本開示において、以下の用語は以下のような基準で解釈されるが、記載されていない用語であっても下記趣旨によって解釈される。コーディングは場合によってはエンコーディングまたはデコーディングと解釈され、情報（ｉｎｆｏｒｍａｔｉｏｎ）は値（ｖａｌｕｅｓ）、パラメータ（ｐａｒａｍｅｔｅｒ）、係数（ｃｏｅｆｆｉｃｉｅｎｔｓ）、成分（ｅｌｅｍｅｎｔｓ）などをいずれも含む用語であって、場合によっては意味が異なるように解釈されることがあるため、本開示はこれに限らない。「ユニット」は映像（ピクチャ）処理の基本単位またはピクチャの特定位置を指す意味で使用されており、場合によっては「ブロック」、「パーティション」、または「領域」などの用語と互いに混用して使用されている。また、本明細書において、ユニットはコーディングユニット、予測ユニット、変換ユニットをいずれも含む概念として使用される。
図１は、本開示の一実施例によるビデオ信号エンコーディング装置の概略的なブロック図である。図１を参照すると、本開示のエンコーディング装置１００は、大きく変換部１１０、量子化部１１５、逆量子化部１２０、逆変換部１２５、フィルタリング部１３０、予測部１５０、及びエントロピーコーディング部１６０を含む。
変換部１１０は、入力されたビデオ信号に対する画素値を変換して変換係数値を獲得する。例えば、離散コサイン変換（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ、ＤＣＴ）、またはウェーブレット変換（Ｗａｖｅｌｅｔ Ｔｒａｎｓｆｏｒｍ）などが使用される。特に、離散コサイン変換は入力されたピクチャ信号を一定サイズのブロックの形態に分けて変換を行う。変換において、変換領域内の値の分布と特性によってコーディング効率が異なり得る。
量子化部１１５は、変換部１１０内で出力された変換係数値を量子化する。逆量子化部１２０では変換係数値を逆量子化し、逆変換部１２５では逆量子化された変換係数値を利用して元の画素値を復元する。
フィルタリング部１３０は、復元されがピクチャの品質を改善するための演算を行う。例えば、デブロッキングフィルタ及び適応的ループフィルタなどが含まれる。フィルタリングを経たピクチャは、出力されるか参照ピクチャとして利用するために復号ピクチャバッファ（Ｄｅｃｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ）１５６に保存される。
コーディング効率を上げるために、ピクチャ信号をそのままコードせず、予測部１５０で既にコードされた領域を用いてピクチャを予測し、予測されたピクチャに原ピクチャと予測ピクチャ間のレジデュアル値を足して復元ピクチャを取得する方法が用いられる。イントラ予測部１５２では、現在ピクチャ内で画面内予測を行い、インター予測部１５４では、復号ピクチャバッファ１５６に保存された参照ピクチャを用いて現在ピクチャを予測する。イントラ予測部１５２は、現在ピクチャ内の復元された領域から画面内予測を行い、画面内符号化情報をエントロピーコーディング部１６０に伝達する。インター予測部１５４はさらに、モーション推定部１５４ａ及びモーション補償部１５４ｂを含んで構成されてよい。モーション推定部１５４ａでは、復元された特定領域を参照して現在領域のモーションベクトル値を取得する。モーション推定部１５４ａでは、参照領域の位置情報（参照フレーム、モーションベクトルなど）などをエントロピーコーディング部１６０に伝達してビットストリームに含まれ得るようにする。モーション推定部１５４ａから伝達されたモーションベクトル値を用いて、モーション補償部１５４ｂでは画面間モーション補償を行う。
エントロピーコーディング部１６０は、量子化された変換係数、画面間符号化情報、画面内符号化情報、及びインター予測部１５４から入力された参照領域情報などをエントロピーコーディングしてビデオ信号ビットストリームを生成する。ここで、エントロピーコーディング部１６０では、可変長コーディング（Ｖａｒｉａｂｌｅ Ｌｅｎｇｔｈ Ｃｏｄｉｎｇ、ＶＬＣ）方式と算術コーディング（ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ）などが使用される。可変長コーディング（ＶＬＣ）方式は入力されるシンボルを連続したコードワードに変換するが、コードワードの長さは可変的である。例えば、よく発生するシンボルは短いコードワードで、よく発生しないシンボルは長いコードワードで表現する。可変長コーディング方式として、コンテキスト基盤の適応型可変長コーディング（Ｃｏｎｔｅｘｔ－ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｖａｒｉａｂｌｅ Ｌｅｎｇｔｈ Ｃｏｄｉｎｇ、ＣＡＶＬＣ）方式が使用される。算術コーディングは連続したデータシンボルを一つの素数に変換するが、算術コーディングは各シンボルを表現するために必要な最適の素数ビットを得る。算術コーディングとして、コンテキスト基盤の適応型算術符号化（Ｃｏｎｔｅｘｔ－ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｂｉｎａｒｙ Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ、ＣＡＢＡＣ）方式が使用される。
前記生成されたビットストリームは、ＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニットを基本単位にカプセル化されている。ＮＡＬユニットは符号化されたスライスセグメントを含むが、前記スライスセグメントは整数個のコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ）からなる。ビデオデコーダでビットストリームをデコーディングするためには、まずビットストリームをＮＡＬユニット単位に分離した後、分離されたそれぞれのＮＡＬユニットをデコーディングすべきである。
図２は、本開示の実施例によるビデオ信号デコーディング装置２００の概略的なブロック図である。図２を参照すると、本開示のデコーディング装置２００は、大きくエントロピーデコーディング部２１０、逆量子化部２２０、逆変換部２２５、フィルタリング部２３０、及び予測部２５０を含む。
エントロピーデコーディング部２１０は、ビデオ信号ビットストリームをエントロピーデコーディングし、各領域に対する変換係数、動き情報などを抽出する。逆量子化部２２０はエントロピーデコーディングされた変換係数を逆量子化し、逆変換部２２５は逆量子化された変換係数を利用して元の画素値を復元する。
一方、フィルタリング部２３０は、ピクチャに対するフィルタリングを行って画質を向上させる。ここには、ブロック歪曲現象を減少させるためのデブロッキングフィルタ及び／またはピクチャ全体の歪曲を除去するための適応的ループフィルタなどが含まれる。フィルタリングを経たピクチャは出力されるか、次のフレームに対する参照ピクチャとして利用するために復号ピクチャバッファ（Ｄｅｃｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ）２５６に保存される。
また、本開示の予測部２５０はイントラ予測部２５２とインター予測部２５４を含み、上述したエントロピーデコーディング部２１０を介してデコーディングされた符号化タイプ、各領域に対する変換係数、動き情報などを活用して予測ピクチャを復元する。
それに関連して、前記イントラ予測部２５２では現在ピクチャ内のデコーディングされたサンプルから画面内予測を行う。インター予測部２５４は、複合ピクチャバッファ２５６に保存されている参照ピクチャ及び動き情報を利用して予測ピクチャを生成する。インター予測部２５４は、更に動き推定部２５４ａ及び動き補償部２５４ｂを含んで構成される。動き推定部２５４ａでは、現在ブロックとコーディングに使用する参照ピクチャの参照ブロック間の位置関係を示す動きベクトルを獲得して動き補償部２５４ｂに伝達する。
前記イントラ―予測部２５２またはインター予測部２５４から出力された予測値、及び逆変換部２２５から出力された画素値が足されて復元されたビデオフレームが生成される。
以下では、前記エンコーディング装置１００とデコーディング装置２００の動作において、図３乃至図５を参照してコーディングユニット及び予測ユニットなどを分割する方法について説明する。
コーディングユニットとは、上述したビデオ信号の処理過程において、例えば、画面内（ｉｎｔｒａ）／画面間（ｉｎｔｅｒ）予測、変換（ｔｒａｎｓｆｏｒｍ）、量子化（ｑｕａｎｔｉｚａｔｉｏｎ）、及び／またはエントロピーコーディング（ｅｎｔｒｏｐｙ ｃｏｄｉｎｇ）などの過程でピクチャを処理するための基本単位を意味する。一つのピクチャをコーディングするのに使用されるコーディングユニットのサイズは一定ではない。コーディングユニットは四角形を有し、一つのコーディングユニットは更にいくつかのコーディングユニットに分割される。
図３は、コーディングユニットを分割する本開示の一実施例を示す図である。例えば、２Ｎ×２Ｎのサイズを有する一つのコーディングユニットは、更にＮ×Ｎのサイズを有する４つのコーディングユニットに分割される。このようなコーディングユニットの分割は再帰的に行われるが、全てのコーディングユニットが同じ形態に分割される必要はない。但し、コーディング及び処理過程における便宜上、最大コーディングユニットのサイズ及び／または最小コーディングユニットのサイズの対する制限があり得る。
一つのコーディングユニットに対して、該当コーディングユニットが分割されるのか否かを示す情報を保存する。図４は、図３に示すコーディングユニットの分割構造をブラッグ値を利用して階層的に示す方法に関する一実施例を示す図である。コーディングユニットの分割可否を示す情報は、該当ユニットが分割されていたら「１」、分割されていなければ「０」の値に割り当てる。図４に示したように、分割可否を示すフラッグの値が１であれば該当ノードに対応するコーディングユニットは更に４つのコーディングユニットに分けられ、０であればそれ以上分けられずに該当コーディングユニットに対する処理プロセスが行われる。
上述したコーディングユニットの構造は再帰的なツリー構造を利用して示される。つまり、一つのピクチャまたは最大サイズのコーディングユニットをルート（ｒｏｏｔ）にして、他のコーディングユニットに分割されるコーディングユニットは分割されたコーディングユニットの個数だけ子（ｃｈｉｌｄ）ノードを有するようになる。よって、それ以上分割されないコーディングユニットがリーフ（ｌｅａｆ）ノードになる。一つのコーディングユニットに対して正方形の分割のみ可能であるか仮定すれば、一つのコーディングユニットは最大４つの他のコーディングユニットに分割されるため、コーディングユニットを示すツリーはクアッドツリー（Ｑｕａｄ ｔｒｅｅ）状になる。
エンコーダではビデオピクチャの特性（例えば、解像度）によって、またはコーディングの効率を考慮して最適のコーディングユニットのサイズが選択され、それに関する情報またはそれを誘導する情報がビットストリームに含まれる。例えば、最大コーディングユニットのサイズ及びツリーの最大深さが定義される。正方形分割を行う際、コーディングユニットの高さ及び幅は親ノードのコーディングユニットの高さ及び幅の半分になるため、前記のような情報を利用すれば最小コーディングユニットのサイズが求められる。または逆に、最小コーディングユニットのサイズ及びツリーの最大深さを予め定義して利用し、それを利用して最大コーディングユニットのサイズを誘導して利用することもできる。正方形分割において、ユニットのサイズは２の倍数の形態に変化するため、実際のコーディングユニットのサイズは２を底にする対数値で示して伝送効率を上げることができる。
デコーダでは、現在コーディングユニットが分割されているのか否かを示す情報を獲得する。このような情報は特定条件の下でのみ獲得（伝送）されるようにすると効率を上げることができる。例えば、現在コーディングユニットが分割可能な条件は現在位置で現在コーディングユニットのサイズを足したものがピクチャのサイズより小さく、現在ユニットのサイズが予め設定された最小コーディングユニットのサイズより大きい場合であるため、このような場合にのみ現在コーディングユニットが分割されているのかを示す情報を獲得することができる。
もし前記情報がコーディングユニットが分割されていることを示せば、分割されるコーディングユニットのサイズは現在コーディングユニットの半分になり、現在処理位置を基準にして４つの正方形コーディングユニットに分割される。各運渇されたコーディングユニットに対して前記のような処理を繰り返す。
図５は、コーディングユニットを分割する本開示の更なる実施例を示す図である。本開示の更なる実施例によると、上述したクアッドツリー状のコーディングユニットは、水平分割または垂直分割のバイナリーツリー（ｂｉｎａｒｙ ｔｒｅｅ）構造に更に分割される。つまり、ルートコーディングユニットに対して正方形のクアッドツリー分割が先に適用され、クアッドツリーのリーフノードで矩形のバイナリーツリー分割が更に適用される。一実施例によると、バイナリーツリー分割は対称的な水平分割または対称的な垂直分割であるが、本開示はこれに限らない。
バイナリーツリー各分割ノードにおいて、分割形態（つまり、水平分割または垂直分割）を指示するフラッグが更にシグナリングされる。一実施例によると、前記フラッグ値が「０」であれば水平分割が指示され、前記フラッグ値が「１」であれば垂直分割が指示される。
但し、本開示の実施例において、コーディングユニットの分割方法は上述した方法に限らず、非対称的な水平／垂直分割、３つの矩形コーディングユニットに分割されるトリプルツリー（ｔｒｉｐｌｅ ｔｒｅｅ）などが適用されてもよい。
コーディングのためのピクチャ予測（動き補償）はそれ以上分けられないコーディングユニット（つまり、コーディングユニットツリーのリーフノード）を対象に行われる。このような予測を行う基本単位を、以下では予測ユニット（ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）または予測ブロック（ｐｒｅｄｉｃｔｉｏｎ ｂｌｏｃｋ）という。
以下、本明細書で使用されるユニットという用語は、予測を行う基本単位である前記予測ユニットを代替する用語として使用される。但し、本開示はこれに限らず、より広い意味では、前記コーディングユニットを含む概念として理解される。
デコーディングが行われる現在ユニットを復元するために、現在ユニットが含まれている現在ピクチャまたは他のピクチャがデコーディングされた部分がが利用される。復元に現在ピクチャのみを利用する、つまり、画面内予測のみを行うピクチャ（スライス）をイントラピクチャまたはＩピクチャ（スライス）、画面内予測と画面間予測をいずれも行うことができるピクチャ（スライス）をインターピクチャ（スライス）という。インターピクチャ（スライス）のうち各ユニットを予測するために最大一つの動きベクトル及び参照インデックス（ｒｅｆｅｒｅｎｃｅ ｉｎｄｅｘ）を利用するピクチャ（スライス）を予測ピクチャ（ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ）またはＰピクチャ（スライス）といい、最大２つのモーションベクトル及び参照インデックスを利用するピクチャ（スライス）を双予測ピクチャ（Ｂｉ－ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ）またはＢピクチャ（スライス）という。
イントラ予測部では、現在ピクチャ内の復元された領域から対象ユニットのピクセル値を予測する画面内予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）を行う。例えば、現在ユニットを中心に、左側及び／または上端に位置するユニットの復元されたピクセルから現在ユニットピクセル値を予測する。この際、現在ユニットの左側に位置するユニットは現在ユニットに隣接した左側ユニット、左側上端ユニット、及び左側下端ユニットを含む。また、現在ユニットの上端に位置するユニットは現在ユニットに隣接した上端ユニット、左側上端ユニット、及び右側上端ユニットを含む。
一方、インター予測部では、現在ピクチャではない復元された他のピクチャの情報を利用して対象ユニットのピクセル値を予測する画面間予測（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ）を行う。この際、予測に利用されるピクチャを参照ピクチャ（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）という。画面間予測過程において、現在ユニットを予測するのにどの参照領域を利用するのかは、該当参照領域が含まれている参照ピクチャを示すインデックス及び動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）情報などを利用して示す。
画面間予測には、Ｌ０予測、Ｌ１予測、及び双予測（Ｂｉ－ｐｒｅｄｉｃｔｉｏｎ）がある。Ｌ０予測は、Ｌ０（第０参照ピクチャリスト）に含まれている一つの参照ピクチャを利用した予測であり、Ｌ１予測はＬ１（第１参照ピクチャリスト）に含まれている一つの参照ピクチャを利用した予測を意味する。そのためには、１セットの動き情報（例えば、動きベクトル及び参照ピクチャインデックス）が必要である。双予測方式では最大２つの参照領域を利用するが、この２つの参照領域は同じ参照ピクチャに存在してもよく、互いに異なるピクチャにそれぞれ存在してもよい。つまり、双予測方式では最大２セットの動き情報（例えば、動きベクトル及び参照ピクチャインデックス）が利用されるが、２つの動きベクトルが同じ参照ピクチャインデックスに対応してもよく、互いに異なる参照ピクチャインデックスに対応してもよい。この際、参照ピクチャは時間的に現在ピクチャの以前や以降両方に表示（または出力）される。
動きベクトル及び参照ピクチャインデックスを利用して現在ユニットの参照ユニットを獲得する。前記参照ユニットは、参照ピクチャインデックスを有する参照ピクチャ内に存在する。また、前記動きベクトルによって特定されたユニットのピクセル値または補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）された値が現在ユニットの予測値（ｐｒｅｄｉｃｔｏｒ）として利用される。サブペル（ｓｕｂ－ｐｅｌ）単位のピクセル正確度を有する動き予測のために、例えば、輝度信号に対して８－タブ補間フィルタが、色差信号に対して４－タブ補間フィルタが使用される。但し、サブペル単位の動き予測のための補間フィルタはこれに限らない。このように、動き情報を利用して、以前デコーディングされたピクチャから現在ユニットのテクスチャを予測する動き補償（ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ）が行われる。
以下、図６及び図７を参照して、本開示の実施例による画面内予測方法をより詳しく説明する。上述したように、イントラ予測部は、現在ユニットの左側及び／または上端に位置する隣接ピクセルを参照ピクセルとして利用して、現在ユニットのピクセル値を予測する。
図６に示したように、現在ユニットのサイズがＮ×Ｎであれば、現在ユニットの左側及び／または上端に位置する最大４Ｎ＋１子の隣接ピクセルを使用して参照ピクセルが設定される。参照ピクセルとして使用される少なくとも一部の隣接ピクセルがまだ復元されていなければ、イントラ予測部は予め設定された規則による参照サンプルのパッディング過程を行って参照ピクセルを獲得する。また、イントラ予測部は、画面内予測の誤差を減らすために参照サンプルフィルタリング過程を行う。つまり、隣接ピクセル及び／または参照サンプルパッディング過程によって獲得されたピクセルにフィルタリングを行って参照ピクセルを獲得する。イントラ予測部は、このように獲得された参照ピクセルを利用して現在ユニットのピクセルを予測する。
図７は、画面内予測に使用される予測モードの一実施例を示す図である。画面内予測のために、画面内予測方向を指示する画面内予測モード情報がシグナリングされる。現在ユニットが画面内予測ユニットであれば、ビデオ信号デコーディング装置はビットストリームから現在ユニットの画面内予測モード情報を抽出する。ビデオ信号デコーディング装置のイントラ予測部は、抽出された画面内予測モード情報に基づいて現在ユニットに対する画面内予測を行う。
本開示の一実施例によると、画面内予測モードは計６７個のモードを含む。それぞれの画面内予測モードは、予め設定されたインデックス（つまり、イントラモードインデックス）によって指示される。例えば、図７に示したようにイントラモードインデックス０は平面（ｐｌａｎａｒ）モードを指示し、イントラモードインデックス１はＤＣモードを指示し、イントラモードインデックス２～６６は互いに異なる方向モード（つまり、角度モード）をそれぞれ指示する。画面内予測部は現在ユニットの画面内予測モード情報に基づいて、現在ユニットの画面内予測に使用される参照ピクセル及び／または補間された参照ピクセルを決定する。イントラモードインデックスが特定方向モードを指示すれば、現在ユニットの現在ピクセルから前記特定方向に対応する参照ピクセルまたは補間された参照ピクセルが現在ピクセルの予測に使用される。よって、画面内予測モードに応じて互いに異なるセットの参照ピクセル及び／または補完された参照ピクセルが画面内予測に使用される。
参照ピクセル及び画面内予測モード情報を利用して現在ブロックの画面内予測が行われた後、ビデオ信号デコーディング装置は逆変換部から獲得された現在ユニットの残差信号を現在ユニットの画面内予測値に足して、現在ユニットのピクセル値を復元する。
図８は、本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎを示す図である。
上述したように、現在ピクチャまたはブロックをエンコーディング、デコーディングする際に他のピクチャまたはブロックから予測する。つまり、他のピクチャまたはブロックとの類似性をに基づいてエンコーディング、デコーディングすることができる。他のピクチャまたはブロックと類似した部分を現在ピクチャまたはブロックでは省略したシグナリングでエンコーディング、デコーディングできるが、それについては以下で更に説明する。ブロック単位の予測をすることができる。
図８を参照すると、左側にＲｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）があり、右側にＣｕｒｒｅｎｔ ｐｉｃｔｕｒｅ（現在ピクチャ）があるが、ｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅまたはｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅの一部を参照ピクチャ（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）またはｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅの一部との類似性を利用して予測する。図８のｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅの中に実線で示した四角形が現在エンコーディング、デコーディングするブロックとすると、ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅの点線で示した四角形から現在ブロックを予測する。この際、現在ブロックが参照すべきブロック（参照ブロック）を指示する情報が存在するが、これは直接シグナリングされてもよく、シグナリングオーバーヘッドを減らすためにある約束によって作り出すこともできる。前記現在ブロックが参照すべきブロックを指示する情報は動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を含む。これは現在ブロックと参照ブロックとの間のピクチャ内における相対的な位置を示すベクトルである。図８を参照すると、ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅの点線で示した部分が存在するが、現在ブロックがどのように移動すればｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅの参照すべきブロックに移動できるのかを示すベクトルが動きベクトルである。つまり、現在ブロックを動きベクトルに応じて動かしたら出るブロックは図８のｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅに点線で示した部分であるが、この点線で示した部分はｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅ内での位置がｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅの参照ブロックの位置と同じである。
また、前記現在ブロックが参照すべきブロックを指示する情報は参照ピクチャ（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）を示す情報を含む。参照ピクチャを示す情報を参照ピクチャリスト（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ ｌｉｓｔ）と参照ピクチャインデックス（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ ｉｎｄｅｘ）を含む。参照ピクチャリストは参照ピクチャら（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅｓ）を含むリストであり、参照ピクチャリストに含まれている参照ピクチャから参照ブロックを使用することができる。つまり、参照ピクチャリストに含まれている参照ピクチャから現在ブロックを予測することができる。また、参照ピクチャインデックス（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ ｉｎｄｅｘ）は使用する参照ピクチャ（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）を指示するためのインデックスである。
図９は、本開示の一実施例による動きベクトルシグナリング方法を示す図である。
本開示の一実施例によると、動きベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ；ＭＶ）はｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（ＭＶＰ；動きベクトル予測子）に基づいて生成する。例えば、以下のようにｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒがｍｏｔｉｏｎ ｖｅｃｔｏｒとなる。
ＭＶ＝ＭＶＰ、他の例を挙げると、例えば、以下のようにｍｏｔｉｏｎ ｖｅｃｔｏｒはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（ＭＶＤ）に基づく。ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒに正確なｍｏｔｉｏｎ ｖｅｃｔｏｒを示すために、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（ＭＶＤ；動きベクトル差分）を足す。
ＭＶ＝ＭＶＰ＋ＭＶＤ、また、ビデオコーディングにおいて、エンコーダで決定したｍｏｔｉｏｎ ｖｅｃｔｏｒ情報をデコーダに伝送し、デコーダは受信したｍｏｔｉｏｎ ｖｅｃｔｏｒ情報からｍｏｔｉｏｎ ｖｅｃｔｏｒを生成して予測ブロックを決定する。例えば、前記ｍｏｔｉｏｎ ｖｅｃｔｏｒ情報はｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に関する情報、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を含む。この際、モードによって前記ｍｏｔｉｏｎ ｖｅｃｔｏｒ情報の構成要素が異なり得る。例えば、ｍｅｒｇｅ ｍｏｄｅでは前記ｍｏｔｉｏｎ ｖｅｃｔｏｒ情報はｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に関する情報を含み、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）は含まない。他の例として、ＡＭＶＰ（ａｄｖａｎｃｅｄ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｎ）ｍｏｄｅでは前記ｍｏｔｉｏｎ ｖｅｃｔｏｒ情報はｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に関する情報を含み、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を含む。
Ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に関する情報を決定、送信、受信するために、エンコーダとデコーダは同じ方法でＭＶＰ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補子）を生成する。例えば、エンコーダとデコーダは同じ順に同じＭＶＰ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補子）を生成する。そして、エンコーダは生成したＭＶＰ ｃａｎｄｉｄａｔｅｓ（動きベクトル予測子候補子ら）のうちから決定したＭＶＰ（動きベクトル予測子）を示すインデックス（ｍｖｐ＿ｌｘ＿ｆｌａｇ）をデコーダに伝送し、デコーダはこのインデックス（ｍｖｐ＿ｌｘ＿ｆｌａｇ）に基づいて決定されたＭＶＰ（動きベクトル予測子）及びＭＶを割り出す。インデックス（ｍｖｐ＿ｌｘ＿ｆｌａｇ）は、第０参照ピクチャリスト（ｌｉｓｔ ０）の動きベクトル予測子インデックス（ｍｖｐ＿ｌ０＿ｆｌａｇ）及び第１参照ピクチャリスト（ｌｉｓｔ １）の動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）を含む。インデックス（ｍｖｐ＿ｌｘ＿ｆｌａｇ）を受信する方法については図５６乃至図５９で説明する。
ＭＶＰ ｃａｎｄｉｄａｔｅ及びＭＶＰ ｃａｎｄｉｄａｔｅの生成方法は、ｓｐａｔｉａｌ ｃａｎｄｉｄａｔｅ、ｔｅｍｐｏｒａｌ ｃａｎｄｉｄａｔｅなどを含む。Ｓｐａｔｉａｌ ｃａｎｄｉｄａｔｅは、現在ブロックから一定位置にあるブロックに対するｍｏｔｉｏｎ ｖｅｃｔｏｒである。例えば、現在ブロックと隣接するか隣接しないブロックや位置に当たるｍｏｔｉｏｎ ｖｅｃｔｏｒである。Ｔｅｍｐｏｒａｌ ｃａｎｄｉｄａｔｅは、現在ブロックとは異なるピクチャ内のブロックに当たるｍｏｔｉｏｎ ｖｅｃｔｏｒである。または、ＭＶＰ ｃａｎｄｉｄａｔｅはａｆｆｉｎｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ、ＡＴＭＶＰ、ＳＴＭＶＰ、上述したｍｏｔｉｏｎ ｖｅｃｔｏｒらのｃｏｍｂｉｎａｔｉｏｎ、上述したｍｏｔｉｏｎ ｖｅｃｔｏｒらの平均ｖｅｃｔｏｒ、ｚｅｒｏ ｍｏｔｉｏｎ ｖｅｃｔｏｒなどを含む。
また、上述した参照ピクチャ（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）を示す情報もエンコーダからデコーダに伝送される。また、ＭＶＰ ｃａｎｄｉｄａｔｅに当たる参照ピクチャが参照ピクチャを示す情報に当たらなければｍｏｔｉｏｎ ｖｅｃｔｏｒ ｓｃａｌｉｎｇを行う。Ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｓｃａｌｉｎｇは、現在ピクチャのＰＯＣ（ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ）、現在ブロックの参照ピクチャのＰＯＣ、ＭＶＰ ｃａｎｄｉｄａｔｅの参照ピクチャのＰＯＣ、ＭＶＰ ｃａｎｄｉｄａｔｅに基づく計算である。
図１０は、本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ ｓｙｎｔａｘを示す図である。
Ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）は、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのｓｉｇｎとａｂｓｏｌｕｔｅ ｖａｌｕｅが分けられてコーディングされる。つまり、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのｓｉｇｎとａｂｓｏｌｕｔｅ ｖａｌｕｅは異なるｓｙｎｔａｘである。また、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのａｂｓｏｌｕｔｅ ｖａｌｕｅは値が直接コーディングされてもよいが、図１０のようにａｂｓｏｌｕｔｅ ｖａｌｕｅがＮより大きいのか否かを示すｆｌａｇを含んでコーディングされてもよい。もしａｂｓｏｌｕｔｅ ｖａｌｕｅがＮより大きければ、（ａｂｓｏｌｕｔｅ－Ｎ）の値が共にシグナリングされる。図１０の例ではａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇが伝送されるが、このｆｌａｇはａｂｓｏｌｕｔｅ ｖａｌｕｅが０より大きいのかを示すｆｌａｇである。もしａｂｓｏｌｕｔｅ ｖａｌｕｅが０より大きくないとａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇが示されれば、ａｂｓｏｌｕｔｅ ｖａｌｕｅが０であると決定する。また、もしａｂｓｏｌｕｔｅ ｖａｌｕｅが０より大きいとａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇが示されれば、追加のｓｙｎｔａｘが存在する可能性がある。例えば、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇが存在するが、このｆｌａｇはａｂｓｏｌｕｔｅ ｖａｌｕｅが１より大きいのかを示すｆｌａｇである。もしａｂｓｏｌｕｔｅ ｖａｌｕｅが１より大きくないとａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇが示されれば、ａｂｓｏｌｕｔｅ ｖａｌｕｅが１であると決定する。もしａｂｓｏｌｕｔｅ ｖａｌｕｅが1より大きいとａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇが示されれば、追加のｓｙｎｔａｘが存在する可能性がある。例えば、ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２が存在するが、これは（ａｂｓｏｌｕｔｅ ｖａｌｕｅ－２）の値である。上述したａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇを介してａｂｓｏｌｕｔｅ ｖａｌｕｅが１より大きいと（２以上であると）決定されたため、（ａｂｓｏｌｕｔｅ ｖａｌｕｅ－２）を示すのである。ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２がｖｒｉａｂｌｅ ｌｅｎｇｔｈにｂｉｎａｒｉｚａｔｉｏｎされる場合、より少ないビットでシグナリングするためである。例えば、Ｅｘｐ－Ｇｏｌｏｍｂ、ｔｒｕｎｃａｔｅｄ ｕｎａｒｙ、ｔｒｕｎｃａｔｅｄ Ｒｉｃｅなどのｖｒｉａｂｌｅ ｌｅｎｇｔｈであるｂｉｎａｒｉｚａｔｉｏｎ方法が存在する。また、ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのｓｉｇｎを示すｆｌａｇである。
この実施例において、コーディング方法をｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを介して説明したが、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ以外の情報もｓｉｇｎとａｂｓｏｌｕｔｅ ｖａｌｕｅに関して分けて、ａｂｓｏｌｕｔｅ ｖａｌｕｅはａｂｓｏｌｕｔｅ ｖａｌｕｅがある値より大きいのか否かを示すｆｌａｇと、ａｂｓｏｌｕｔｅ ｖａｌｕｅから前記ある値を引いた値にコーディングすることができる。また、図１０において、［０］と［１］はｃｏｍｐｏｎｅｎｔ ｉｎｄｅｘを示す。例えば、ｘ－ｃｏｍｐｏｎｅｎｔ、ｙ－ｃｏｍｐｏｎｅｎｔを示す。
図１１は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（適応的な動きベクトル解像度）のシグナリングを示す図である。
本開示の一実施例によると、ｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を示すｒｅｓｏｌｕｔｉｏｎ（解像度）は多様である。言い換えれば、ｍｏｔｉｏｎ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅがコーディングされるｒｅｓｏｌｕｔｉｏｎは多様である。例えば、ｒｅｓｏｌｕｔｉｏｎはｐｉｘｅｌ（ｐｅｌ）に基づいて示される。例えば、１／４（ｑｕａｒｔｅｒ）、１／２（ｈａｌｆ）、１（ｉｎｔｅｇｅｒ）、２、４ｐｉｘｅｌなどの単位でｍｏｔｉｏｎ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅをシグナリングする。例えば、１６を示したい場合、１／４単位にすると６４にコーディングされ（１／４＊６４＝１６）、１単位にすると１６にコーディングされ（１＊１６＝１６）、４単位にすると４にコーディングされる（４＊４＝１６）。つまり、以下のように値を定義する。
ｖａｌｕｅＤｅｔｅｒｍｉｎｅｄ＝ｒｅｓｏｌｕｔｉｏｎ＊ｖａｌｕｅPｅｒＲｅｓｏｌｕｔｉｏｎ
ここで、ｖａｌｕｅＤｅｔｅｒｍｉｎｅｄは伝達する値であって、本実施例ではｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）である。また、ｖａｌｕｅPｅｒＲｅｓｏｌｕｔｉｏｎはｖａｌｕｅＤｅｔｅｒｍｉｎｅｄを［／ｒｅｓｏｌｕｔｉｏｎ］単位で示す値である。
この際、ｍｏｔｉｏｎ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅでシグナリングする値がｒｅｓｏｌｕｔｉｏｎで割り切れない場合、ｒｏｕｎｄｉｎｇなどでｐｒｅｄｉｃｔｉｏｎ性能が最もよいｍｏｔｉｏｎ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅではない不正確な値を送る。Ｈｉｇｈ ｒｅｅｏｌｕｔｉｏｎを使用すれば不正確度が下がるが、コーディングされる値が大きいため多くのビットを使用するようになり、ｌｏｗ ｒｅｅｏｌｕｔｉｏｎを使用すれば不正確度が上がるが、コーディングされる値が小さいため少ないビットを使用するようになる。
また、前記ｒｅｓｏｌｕｔｉｏｎをブロック、ＣＵ、ｓｌｉｃｅなどの単位で異なるように設定することができる。よって、単位に合わせてａｄａｐｔｉｖｅにｒｅｓｏｌｕｔｉｏｎを適用することができる。
前記ｒｅｓｏｌｕｔｉｏｎはエンコーダからデコーダにシグナリングされる。この際、ｒｅｓｏｌｕｔｉｏｎに対するシグナリングは上述したｖａｒｉａｂｌｅ ｌｅｎｇｔｈにｂｉｎａｒｉｚａｔｉｏｎしたシグナリングである。このような場合、最も小さい値（最も前にある値）に当たるインデックスでシグナリングすれば、シグナリングオーバーヘッドが少なくなる。
一実施例として、ｈｉｇｈ ｒｅｅｏｌｕｔｉｏｎ（詳しくシグナリング）からｌｏｗ ｒｅｓｏｌｕｔｉｏｎの順にシグナリングインデックスにマッチングさせる。
図１１は、３つのｒｅｓｏｌｕｔｉｏｎに対するシグナリングを示している。このような場合、３つのシグナリングは０、１０、１１であり、３つのシグナリングそれぞれがｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ ３に当たる。ｒｅｓｏｌｕｔｉｏｎ １をシグナリングするには１ビットが必要であり、残りのｒｅｓｏｌｕｔｉｏｎをシグナリングするのに２ビットが必要であるため、ｒｅｓｏｌｕｔｉｏｎ １をシグナリングする際にシグナリングオーバーヘッド少ない。図１１の例ではｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ２、ｒｅｓｏｌｕｔｉｏｎ ３がそれぞれ１／４、１、４ｐｅｌである。
以下の開示において、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのｒｅｓｏｌｕｔｉｏｎを意味する。
図１２は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。
図１１で説明したように、ｒｅｓｏｌｕｔｉｏｎ（解像度）をシグナリングするのに必要なビット数がｒｅｓｏｌｕｔｉｏｎ（解像度）によって異なり得るため、状況に合わせてシグナリング方法を変更する。例えば、あるｒｅｓｏｌｕｔｉｏｎをシグナリングするシグナリング値が状況によって異なり得る。例えば、シグナリングインデックスとｒｅｓｏｌｕｔｉｏｎを状況によって異なる順にマッチングさせる。例えば、シグナリング０、１０、１１０、…に当たるｒｅｓｏｌｕｔｉｏｎがある状況ではそれぞれｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ２、ｒｅｓｏｌｕｔｉｏｎ ３、…であり、他の状況ではそれぞれｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ２、ｒｅｓｏｌｕｔｉｏｎ ３、…ではなく他の順である。また、２つ以上の状況を定義することができる。
図１２を参照すると、０、１０、１１に当たるｒｅｓｏｌｕｔｉｏｎがＣａｓｅ １ではそれぞれｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ３であり、Ｃａｓｅ ２ではそれぞれｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ３である。この際、Ｃａｓｅは２つ以上である。
図１３は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。
図１２で説明したように、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎを状況によって異なるようにシグナリングする。例えば、１／４、１、４ｐｅｌのｒｅｓｏｌｕｔｉｏｎが存在するとしたら、ある状況では図１１で説明したようなシグナリングを使用し、ある状況では図１３（ａ）または図１３（ｂ）のようなシグナリングを使用する。図１１、図１３（ａ）、図１３（ｂ）の２つの場合のみ存在するか、３つがいずれも存在してもよい。よって、ある状況では最も高いｒｅｓｏｌｕｔｉｏｎではないｒｅｓｏｌｕｔｉｏｎを少ないビットでシグナリングすることができる。
図１４は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。
本開示の一実施例によると、図１１で説明したａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（適応的な動きベクトル解像度）において、状況によって可能なｒｅｓｏｌｕｔｉｏｎが変わり得る。例えば、ｒｅｓｏｌｕｔｉｏｎ値が状況によって変わり得る。一実施例として、ある状況ではｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ ３、ｒｅｓｏｌｕｔｉｏｎ ４、…のうちから使用し、ある状況ではｒｅｓｏｌｕｔｉｏｎ Ａ、ｒｅｓｏｌｕｔｉｏｎ Ｂ、ｒｅｓｏｌｕｔｉｏｎ Ｃ、ｒｅｓｏｌｕｔｉｏｎ Ｄ、…のうちから使用する。また、｛ｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ ３、ｒｅｓｏｌｕｔｉｏｎ ４、…｝と｛ｒｅｓｏｌｕｔｉｏｎ Ａ、ｒｅｓｏｌｕｔｉｏｎ Ｂ、ｒｅｓｏｌｕｔｉｏｎ Ｃ、ｒｅｓｏｌｕｔｉｏｎ Ｄ、…｝には空集合ではなく積集合がある可能性がある。つまり、あるｒｅｓｏｌｕｔｉｏｎ値は２つ以上の状況で使用するが、前記２つ以上の状況は使用可能なｒｅｓｏｌｕｔｉｏｎ値のｓｅｔが異なり得る。また、状況別に使用可能なｒｅｓｏｌｕｔｉｏｎ値の個数が異なり得る。
図１４を参照すると、Ｃａｓｅ １ではｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ ３を使用し、Ｃａｓｅ ２ではｒｅｓｏｌｕｔｉｏｎ Ａ、ｒｅｓｏｌｕｔｉｏｎ Ｂ、ｒｅｓｏｌｕｔｉｏｎ Ｃを使用する。例えば、ｒｅｓｏｌｕｔｉｏｎ １、ｒｅｓｏｌｕｔｉｏｎ ２、ｒｅｓｏｌｕｔｉｏｎ ３は１／４、１、４ｐｅｌである。また、例えば、ｒｅｓｏｌｕｔｉｏｎ Ａ、ｒｅｓｏｌｕｔｉｏｎ Ｂ、ｒｅｓｏｌｕｔｉｏｎ Ｃは１／４、１／２、１ｐｅｌである。
図１５は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。
図１５を参照すると、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃａｎｄｉｄａｔｅ（動きベクトル候補）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補）によってｒｅｓｏｌｕｔｉｏｎ（解像度）シグナリングを異ならせる。例えば、図１２乃至図１４で説明した状況（ｃａｓｅ）が選択されるか、シグナリングされたｍｏｔｉｏｎ ｖｅｃｔｏｒやｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒがどのｃａｎｄｉｄａｔｅであるのかに関する。シグナリングを異ならせる方法は、図１２乃至図１４の方法による。
例えば、ｃａｎｄｉｄａｔｅ（候補）のうちどの位置にあるのかによって状況を異ならせて定義する。または、ｃａｎｄｉｄａｔｅ（候補）がどのように作られたのかによって状況を異ならせて定義する。
エンコーダまたはデコーダは、少なくとも一つのＭＶ ｃａｎｄｉｄａｔｅ（動きベクトル候補）または少なくとも一つのＭＶＰ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補）を含むｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）を生成する。ＭＶ ｃａｎｄｉｄａｔｅ（動きベクトル候補）またはＭＶＰ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補）に対するｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）で前にあるＭＶＰ（動きベクトル予測子）は正確度が高く、ｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）で後ろにあるＭＶＰ（動きベクトル予測子）は正確度が低い傾向がある。これは、ｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）の前にあるものはより少ないビットでシグナリングして、ｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）の前にあるＭＶＰ（動きベクトル予測子）がより正確度が高いように設計した可能性もある。本開示の一実施例において、ＭＶＰ（動きベクトル予測子）の正確度が高ければ予測性能のよいｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を示すためのＭＶＤ（動きベクトル差分）値が小さく、ＭＶＰ（動きベクトル予測子）の正確度が低ければ予測性能のよいｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を示すためのＭＶＤ（動きベクトル差分）値が大きい。よって、ＭＶＰ（動きベクトル予測子）の正確度が低ければ、ｌｏｗ ｒｅｓｏｌｕｔｉｏｎ（低い解像度）でシグナリングしてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）値を示すのに必要なビット（例えば、ｄｉｆｆｅｒｅｎｃｅ値をｒｅｓｏｌｕｔｉｏｎに基づいて示す値）を減らすことができる。
このような原理でＭＶＰ（動きベクトル予測子）の正確度が低い際にｌｏｗ ｒｅｓｏｌｕｔｉｏｎ（低い解像度）を使用することができるため、本開示の一実施例によると、ＭＶＰ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補）によって最もｈｉｇｈ ｒｅｅｏｌｕｔｉｏｎ（高い解像度）ではなく、ｒｅｓｏｌｕｔｉｏｎが最も少ないビットでシグナリングすることを約束することができる。例えば、１／４、１、４ｐｅｌが可能なｒｅｓｏｌｕｔｉｏｎであれば、１または４を最も少ないビット（１－ｂｉｔ）にシグナリングする。図１５を参照すると、Ｃａｎｄｉｄａｔｅ １、Ｃａｎｄｉｄａｔｅ ２に対してはｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎである１／４ｐｅｌを最も少ないビットでシグナリングし、Ｃａｎｄｉｄａｔｅ １、Ｃａｎｄｉｄａｔｅ ２より後ろにあるＣａｎｄｉｄａｔｅ Ｎに対しては１／４ｐｅｌではないｒｅｓｏｌｕｔｉｏｎを最も少ないビットでシグナリングしている。
図１６は、本開示の一実施例によるａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎのシグナリングを示す図である。
図１５で説明したように、決定されたｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）がどのｃａｎｄｉｄａｔｅ（候補）であるのかによって、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（動きベクトル解像度）を異ならせる。シグナリングを異ならせる方法は、図１２乃至図１４の方法による。
図１６を参照すると、あるｃａｎｄｉｄａｔｅ（候補）に対してはｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）を最も少ないビットでシグナリングし、あるｃａｎｄｉｄａｔｅ（候補）に対してはｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）ではないｒｅｓｏｌｕｔｉｏｎ（解像度）を最も少ないビットでシグナリングしている。例えば、ｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）ではないｒｅｓｏｌｕｔｉｏｎ（解像度）を最も少ないビットでシグナリングするｃａｎｄｉｄａｔｅ（候補）は不正確なｃａｎｄｉｄａｔｅ（候補）である。例えば、ｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）ではいｒｅｓｏｌｕｔｉｏｎ（解像度）を最も少ないビットでシグナリングするｃａｎｄｉｄａｔｅ（候補）は、ｔｅｍｐｏｒａｌ ｃａｎｄｉｄａｔｅ、ｚｅｒｏ ｍｏｔｉｏｎ ｖｅｃｔｏｒ、ｎｏｎ－ａｄｊａｃｅｎｔ ｓｐａｔｉａｌ ｃａｎｄｉｄａｔｅ、ｒｅｆｉｎｅｍｅｎｔ過程あるのか否かによるｃａｎｄｉｄａｔｅなどである。
Ｔｅｍｐｏｒａｌ Ｃａｎｄｉｄａｔｅは他のピクチャからのｍｏｔｉｏｎ ｖｅｃｔｏｒである。Ｚｅｒｏ ｍｏｔｉｏｎ ｖｅｃｔｏｒはｖｅｃｔｏｒ成分がいずれも０であるｍｏｔｉｏｎ ｖｅｃｔｏｒである。Ｎｏｎ－ａｄｊａｃｅｎｔ ｓｐａｔｉａｌ ｃａｎｄｉｄａｔｅは現在ブロックと隣接しない位置から参照したｍｏｔｉｏｎ ｖｅｃｔｏｒである。Ｒｅｆｉｎｅｍｅｎｔ（改善）過程はｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）をｒｅｆｉｎｅする過程であり、例えば、ｔｅｍｐｌａｔｅ ｍａｔｃｈｉｎｇ、ｂｉｌａｔｅｒａｌ ｍａｔｃｈｉｎｇなどを介してｒｅｆｉｎｅする。
本開示の一実施例によるとｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）をｒｅｆｉｎｅした後、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を足す。これはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）を正確にしてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）値を減らすためである。このような場合、ｒｅｆｉｎｅｍｅｎｔ（改善）過程がないｃａｎｄｉｄａｔｅ（候補）に対してｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（動きベクトル解像度）シグナリングを異ならせる。例えば、最もｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）ではないｒｅｓｏｌｕｔｉｏｎ（解像度）を最も少ないビットでシグナリングする。
他の実施例によると、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）にｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を足した後、ｒｅｆｉｎｅｍｅｎｔ（改善）過程を行う。この際、ｒｅｆｉｎｅｍｅｎｔ（改善）過程があるｃａｎｄｉｄａｔｅに対してｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（動きベクトル解像度）シグナリングを異ならせる。例えば、最もｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎ（高い解像度）ではないｒｅｓｏｌｕｔｉｏｎ（解像度）を最も少ないビットでシグナリングする。これはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を足した後でｒｅｆｉｎｅｍｅｎｔ（改善）過程が行われるため、ＭＶ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）を最大限正確に（予測誤差が少ないように）シグナリングしなくても、ｒｅｆｉｎｅｍｅｎｔ（改善）過程を介して誤差を減らすことができるためである。
また他の例として、選択されたｃａｎｄｉｄａｔｅ（候補）が他のｃａｎｄｉｄａｔｅ（候補）と一定以上値が異なれば、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（動きベクトル解像度）シグナリングをを変更する。
更に他の例として、決定されたｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）がどのｃａｎｄｉｄａｔｅ（候補）であるのかによって、行われるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｆｉｎｅｍｅｎｔ（動きベクトル改善）過程を異ならせる。Ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｆｉｎｅｍｅｎｔ（動きベクトル改善）過程は、より正確なｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を見つけるための過程である。例えば、基準点から決められた約束によって現在ブロックとｍａｔｃｈｉｎｇ（マッチング）するブロックを見つける過程である（例えば、ｔｅｍｐｌａｔｅ ｍａｔｃｈｉｎｇまたはｂｉｌａｔｅｒａｌ ｍａｔｃｈｉｎｇ）。基準点は決定されたｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に当たる位置である。この際、決められた約束によって基準点から動く程度が異なり得るが、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｆｉｎｅｍｅｎｔ（動きベクトル改善）過程を異ならせるということは、基準点から動く程度を異ならせるということである。例えば、正確なｃａｎｄｉｄａｔｅ（候補）に対しては詳しいｒｅｆｉｎｅｍｅｎｔ（改善）過程から始まり、不正確なｃａｎｄｉｄａｔｅ（候補）に対してはそれより詳しくないｒｅｆｉｎｅｍｅｎｔ（改善）過程から始まる。正確で、不正確なｃａｎｄｉｄａｔｅ（候補）はｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）における位置、またはどの方式でｃａｎｄｉｄａｔｅ（候補）が生成されたのかなどによって決定される。どのような方式でｃａｎｄｉｄａｔｅ（候補）が生成されたのかは、ｓｐａｔｉａｌ ｃａｎｄｉｄａｔｅをどの位置から持ってきたのかである。また、それについては図１６の説明を参照する。また、詳細で、それより詳細ではないｒｅｆｉｎｅｍｅｎｔ（改善）はｍａｔｃｈｉｎｇ（マッチング）するブロックを基準点から少しずつ動かしながら見つけるのか、多く動かしながら見つけるのかである。また、大きく動かしながら見つける場合、多く動かしながら見つけた最もｍａｔｃｈｉｎｇ（マッチング）するブロックから更に少しずつ動かしながら見つける過程を追加する。
更に他の実施例として、現在ピクチャのＰＯＣ及びｍｏｔｉｏｎ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ ｃａｎｄｉｄａｔｅのｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅのＰＯＣに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎシグナリングを変更する。シグナリングを異ならせる方法は、図１２乃至図１４の方法による。
例えば、現在ピクチャのＰＯＣ（ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ）とｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ ｃａｎｄｉｄａｔｅ（動きベクトル予測子候補）のｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）のＰＯＣの差が大きければ、ｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）が不正確な可能性があり、ｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎではないｒｅｓｏｌｕｔｉｏｎを最も少ないビットでシグナリングする。
更に他の例として、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｓｃａｌｉｎｇ（動きベクトルスケーリング）をすべきであるのかに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（動きベクトル解像度）シグナリングを変更する。例えば、選択したｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）がｍｏｔｉｏｎ ｖｅｃｔｏｒ ｓｃａｌｉｎｇ（動きベクトルスケーリング）を行うｃａｎｄｉｄａｔｅであれば、ｈｉｇｈ ｒｅｓｏｌｕｔｉｏｎではないｒｅｓｏｌｕｔｉｏｎを最も少ないビットでシグナリングする。Ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｓｃａｌｉｎｇ（動きベクトルスケーリング）を行う場合は、現在ブロックに対するｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）と参照したｃａｎｄｉｄａｔｅ（候補）のｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）が異なる場合である。
図１７は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。
図８で説明したような従来の予測方法では、現在ブロックが回転やスケーリングなしに単に移動した位置からのブロックから予測する。現在ブロックと同じサイズや形状、角度の参照ブロックから予測する。図８は、単にｔｒａｎｓｌａｔｉｏｎ ｍｏｔｉｏｎ ｍｏｄｅｌなのである。しかし、実際の映像に含まれているコンテンツはより複雑な動きを有し、多様な模様から予測すれば予測性能が更に向上される。
図１７を参照すると、ｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅ（現在ピクチャ）に現在予測するブロックを実線で示している。現在予測するブロックとは異なる形状、サイズ、角度のブロックを参照して現在ブロックを予測し、参照ブロックをｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）に点線で示している。参照ブロックのピクチャ内における位置と同じ位置をｃｕｒｒｅｎｔ ｐｉｃｔｕｒｅに点線で示している。この際、参照ブロックは現在ブロックにａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎで示されるブロックである。それによってｓｔｒｅｔｃｈｉｎｇ（ｓｃａｌｉｎｇ）、ｒｏｔａｔｉｏｎ、ｓｈｅａｒｉｎｇ、ｒｅｆｌｅｃｔｉｏｎ、ｏｒｔｈｏｇｏｎａｌ ｐｒｏｊｅｃｔｉｏｎなどを示すことができる。
Ａｆｆｉｎｅ ｍｏｔｉｏｎ（アフィン動き）、ａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎ（アフィン変換）を示すｐａｒａｍｅｔｅｒの個数は多様であり、より多くのｐａｒａｍｅｔｅｒを使用したらより少ないｐａｒａｍｅｔｅｒを使用する際より更に多様なｍｏｔｉｏｎを示すことができるが、ｓｉｇｎａｌｉｎｇや計算などでオーバーヘッドが発生する可能性がある。
例えば、６つのｐａｒａｍｅｔｅｒによってａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎが示される。または、３つのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓによってａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎが示される。
図１８は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。
図１７のように、ａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎ（アフィン変換）を利用して複雑な動きを表現することができるが、そのためのシグナリングオーバーヘッド及び演算を減らすためにより簡単なａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）またはａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎ（アフィン変換）を使用する。動いを制限することでより簡単なａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）をすることができる。動きを制限したら、現在ブロックが参照ブロックに変形される形状が制限される。
図１８を参照すると、ｖ０、ｖ１のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓ（コントロールポイント動きベクトルら）を利用してａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を行う。ｖ０、ｖ１の２つのｖｅｃｔｏｒｓを使用することは、４つのｐａｒａｍｅｔｅｒｓを使用することと同じである。前記ｖ０、ｖ１の２つのｖｅｃｔｏｒｓまたは４つのｐａｒａｍｅｔｅｒｓで現在ブロックがどの形状の参照ブロックから予測するのかを示す。このような簡単なａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎを使用することで、ブロックのｒｏｔａｔｉｏｎ、ｓｃａｌｉｎｇ（ｚｏｏｍ ｉｎ／ｏｕｔ）の動きを示すことができる。図１８を参照すると、実線で示した現在ブロックはｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ（参照ピクチャ）において図１８の点線で示した位置から予測する。Ａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎを介して現在ブロックの各ｐｏｉｎｔ（ｐｉｘｅｌ）が他のｐｏｉｎｔにマッピングされる。
図１９は、本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄ（動きベクトルフィールド）を示す式である。図１８のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）ｖ０は、（ｖ＿０ｘ，ｖ＿０ｙ）であり、ｔｏｐ－ｌｅｆｔ ｃｏｒｎｅｒ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒである。また、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｖ１は、（ｖ＿１ｘ，ｖ＿１ｙ）であり、ｔｏｐ－ｒｉｇｈｔ ｃｏｒｎｅｒ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒである。この際、（ｘ，ｙ）位置のｍｏｔｉｏｎ ｖｅｃｔｏｒ（ｖ＿ｘ，ｖ＿ｙ）は図１９のようである。よって、各ｐｉｘｅｌの位置またはある位置に対するｍｏｔｉｏｎ ｖｅｃｔｏｒを図１９の式によって推定し、これはｖ０、ｖ１に基づいている。
また、図１９の数式において、（ｘ，ｙ）はｂｌｏｃｋ（ブロック）内での相対的な座標である。例えば、（ｘ，ｙ）はｂｌｏｃｋ（ブロック）のｌｅｆｔ ｔｏｐ位置を（０，０）とした際の位置である。
もしｖ０がピクチャ上で位置（ｘ０，ｙ０）に対するｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）で、ｖ１がピクチャ上で位置（ｘ１，ｙ１）に対するｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）であれば、ｂｌｏｃｋ（ブロック）内での位置（ｘ，ｙ）をｖ０、ｖ１の位置と同じ座標を使用して示すには、図１９の数式でｘとｙをそれぞれ（ｘ－ｘ０，ｙ－ｙ０）に変更して示す。また、ｗ（ｂｌｏｃｋのｗｉｄｔｈ）は（ｘ１－ｘ０）である。
図２０は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。
本開示の一実施例によると、多数のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）または多数のｐａｒａｍｅｔｅｒを使用してａｆｆｉｎｅ ｍｏｔｉｏｎ（アフィン動き）を示す。
図２０を参照すると、ｖ０、ｖ１、ｖ２のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）を利用してａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を行う。ｖ０、ｖ１、ｖ２の３つのｖｅｃｔｏｒｓを使用することは、６つのｐａｒａｍｅｔｅｒｓを使用することと同じである。前記ｖ０、ｖ１、ｖ２の３つのｖｅｃｔｏｒｓまたは６つのｐａｒａｍｅｔｅｒｓで現在ブロックがどの形状の参照ブロックから予測するのかを示す。図２０を参照すると、実線で示した現在ブロックはｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅにおいて図２０の点線で示した位置から予測する。ａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎを介して現在ブロックの各ｐｏｉｎｔ（ｐｉｘｅｌ）が他のｐｏｉｎｔにマッピングされる。
図２１は、本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄを示す式である。図２０において、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）ｖ０が（ｍｖ＿０＾ｘ，ｍｖ＿０＾ｙ）でｔｏｐ－ｌｅｆｔ ｃｏｒｎｅｒ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒであり、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）ｖ１が（ｍｖ＿１＾ｘ，ｍｖ＿１＾ｙ）でｔｏｐ－ｒｉｇｈｔ ｃｏｒｎｅｒ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒであり、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）ｖ２が（ｍｖ＿２＾ｘ，ｍｖ＿２＾ｙ）でｂｏｔｔｏｍ－ｌｅｆｔ ｃｏｒｎｅｒ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒである。この際、（ｘ，ｙ）位置のｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）（ｍｖ＾ｘ，ｍｖ＾ｙ）は図２１のようである。よって、各ｐｉｘｅｌの位置またはある位置に対するｍｏｔｉｏｎ ｖｅｃｔｏｒを図２１の式によって推定し、これはｖ０、ｖ１、ｖ２に基づいている。
また、図２１の数式において、（ｘ，ｙ）はｂｌｏｃｋ（ブロック）内での相対的な座標である。例えば、（ｘ，ｙ）はｂｌｏｃｋ（ブロック）のｌｅｆｔ ｔｏｐ位置を（０，０）とした際の位置である。よって、もしｖ０が位置（ｘ０，ｙ０）に対するｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）で、ｖ１が位置（ｘ１，ｙ１）に対するｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）で、ｖ２が位置（x２，y２）に対するｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）であるとし、（ｘ，ｙ）をｖ０、ｖ１、ｖ２の位置と同じ座標を使用して示すには、図２１の数式でｘとｙをそれぞれ（ｘ－ｘ０，ｙ－ｙ０）に変更して示す。また、ｗ（ｂｌｏｃｋのｗｉｄｔｈ）は（ｘ１－ｘ０）で、ｈ（ｂｌｏｃｋのｈｅｉｇｈｔ）は（ｙ２－ｙ０）である。
図２２は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎを示す図である。
上述したように、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄ（動きベクトルフィールド）が存在し、各ｐｉｘｅｌに対してｍｏｔｉｏｎ ｖｅｃｔｏｒを計算するが、より簡単にするために、図２２のようにｓｕｂｂｌｏｃｋ ｂａｓｅｄ（サブブロック基盤）でａｆｆｉｎｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎを行う。例えば、図２２（ａ）の小さい四角形がｓｕｂｂｌｏｃｋ（サブブロック）であるが、ｓｕｂｂｌｏｃｋの代表ｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を作り、そのｓｕｂｂｌｏｃｋのｐｉｘｅｌに対して前記代表ｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を利用する。また、図１７、図１８、図２０などで複雑な動きを表現したように、ｓｕｂｂｌｏｃｋがそのような動きを表現して参照ブロックと対応するか、またはｓｕｂｂｌｏｃｋにｔｒａｎｓｌａｔｉｏｎ ｍｏｔｉｏｎのみを適用してより簡単にすることもできる。図２２（ａ）において、ｖ０、ｖ１、ｖ２はｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）である。
この際、ｓｕｂｂｌｏｃｋ（サブブロック）のサイズはＭ＊Ｎであり、ＭとＮは図２２（ｂ）に示したようである。そして、ＭｖＰｒｅはｍｏｔｉｏｎ ｆｒａｃｔｉｏｎ ａｃｃｕｒａｃｙ（動きベクトルフラクション正確度）である。また、（ｖ＿０ｘ，ｖ＿０ｙ）と（ｖ＿１ｘ，ｖ＿１ｙ）、（ｖ＿２ｘ，ｖ＿２ｙ）はそれぞれｔｏｐ－ｌｅｆｔ、ｔｏｐ－ｒｉｇｈｔ、ｂｏｔｔｏｍ－ｌｅｆｔ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）である。（ｖ＿２ｘ，ｖ＿２ｙ）は現在ブロックのｂｏｔｔｏｍ－ｌｅｆｔ ｃｏｎｔｒｏｌ ｐｏｉｎｔのｍｏｔｉｏｎ ｖｅｃｔｏｒであるが、例えば、４－ｐａｒａｍｅｔｅｒの場合、図１９の式によって計算したｂｏｔｔｏｍ－ｌｅｆｔに対するＭＶ（動きベクトル）である。
また、ｓｕｂｂｌｏｃｋの代表ｍｏｔｉｏｎ ｖｅｃｔｏｒを作る際、ｓｕｂｂｌｏｃｋの中央のサンプル位置を利用して代表ｍｏｔｉｏｎ ｖｅｃｔｏｒを計算する。また、ｓｕｂｂｌｏｃｋのｍｏｔｉｏｎ ｖｅｃｔｏｒを作る際、ｎｏｒｍａｌ ｍｏｔｉｏｎ ｖｅｃｔｏｒより正確度が高いｍｏｔｉｏｎ ｖｅｃｔｏｒを使用するが、そのためにｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ ｉｎｔｅｒｐｏｌａｔｉｏｎ ｆｉｌｔｅｒｓ（動き補償補間フィルタ）が適用される。
他の実施例として、ｓｕｂｂｌｏｃｋのサイズが可変的ではなく、特定サイズに固定されていてもよい。例えば、４＊４サイズにｓｕｂｂｌｏｃｋのサイズが固定されていてもよい。
図２３は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのあるモードを示す図である。
本開示の一実施例によると、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）の一例として、ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ（アフィンインターモード）がある。Ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ（アフィンインターモード）であることを指示するｆｌａｇ（フラッグ）がある。図２３を参照すると、ｖ０、ｖ１近くのＡ、Ｂ、Ｃ、Ｄ、Ｅ位置のブロックがあり、各ブロックに当たるｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）をｖＡ、ｖＢ、ｖＣ、ｖＤ、ｖＥとする。それを利用して以下のようにｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）またはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ（動きベクトル予測子）に対するｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）を作る。
｛（ｖ０，ｖ１）｜ｖ０＝｛ｖＡ，ｖＢ，ｖＣ｝、ｖ１＝｛ｖＤ，ｖＥ｝｝
つまり、ｖＡ、ｖＢ、ｖＣのうちから選んだｖ０と、ｖＤ、ｖＥのうちから選んだｖ１で（ｖ０，ｖ１）ｐａｉｒを作る。この際、ｎｅｉｇｈｂｏｒ ｂｌｏｃｋ（隣ブロック）のｒｅｆｅｒｅｎｃｅのＰＯＣ（ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ）とｃｕｒｒｅｎｔ ＣＵ（現在コーディングユニット；現在ブロック）に対するｒｅｆｅｒｅｎｃｅ（参照）のＰＯＣ、ｃｕｒｒｅｎｔ ＣＵ（現在コーディングユニット；現在ブロック）のＰＯＣによってｍｏｔｉｏｎ ｖｅｃｔｏｒをｓｃａｌｉｎｇ（スケーリング）する。上述したようなｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐａｉｒでｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）が作られたら、ｃａｎｄｉｄａｔｅ ｌｉｓｔのうちどれを選択したのか、選択されたのかをシグナリングすることができる。また、ｃａｎｄｉｄａｔｅ ｌｉｓｔが十分に埋められていなければ、他のｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ（インター予測）のｃａｎｄｉｄａｔｅ（候補）で埋めることができる。例えば、ＡＭＶＰ（Ａｄｖａｎｃｅｄ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ） ｃａｎｄｉｄａｔｅｓを活用して埋めてもよい。また、ｃａｎｄｉｄａｔｅ ｌｉｓｔから選んだｖ０、ｖ１をａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）としてすぐ使用せずに補正するｄｉｆｆｅｒｅｎｃｅ（差分）をシグナリングすることができるが、それによってよりよいｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）を作ることができる。つまり、デコーダではｃａｎｄｉｄａｔｅ ｌｉｓｔ（候補リスト）から選んだｖ０、ｖ１にｄｉｆｆｅｒｅｎｃｅ（差分）を足して作ったｖ０’、ｖ１’をａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒとして使用する。
一実施例として、特定サイズ以上のＣＵ（コーディングユニット）に対してａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ（アフィンインターモード）を使用してもよい。
図２４は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのあるモードを示す図である。
本開示の一実施例によると、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）の一例として、ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅ（アフィンマージモード）がある。Ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅ（アフィンマージモード）であることを指示するｆｌａｇ（フラッグ）がある。Ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅ（アフィンマージモード）では、現在ブロックの周辺でａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を使用した場合、その周辺ブロックのｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）から現在ブロックのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）を計算する。例えば、周辺ブロックがａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を使用したのかを確認する際、ｃａｎｄｉｄａｔｅ（候補）になる周辺ブロックは図２４（ａ）のようである。また、Ａ、Ｂ、Ｃ、Ｄ、Ｅの順にａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を使用したのかを確認し、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を使用したブロックを見つけたら、そのブロックまたはそのブロック周辺のｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）を使用して現在ブロックのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）を計算する。Ａ、Ｂ、Ｃ、Ｄ、Ｅは図２４（ａ）に示したように、それぞれｌｅｆｔ、ａｂｏｖｅ、ａｂｏｖｅ ｒｉｇｈｔ、ｌｅｆｔ ｂｏｔｔｏｍ、ａｂｏｖｅ ｌｅｆｔである。
一実施例として、図２４（ｂ）のようにＡ位置のブロックがａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）を使用した場合、そのブロックまたはそのブロック周辺のｍｏｔｉｏｎ ｖｅｃｔｏｒを利用してｖ０、ｖ１を計算する。前記そのブロックまたはそのブロック周辺のｍｏｔｉｏｎ ｖｅｃｔｏｒはｖ２、ｖ３、ｖ４である。
一実施例では参照する周辺ブロックの順番が決められている。しかし、特定位置からｄｅｒｉｖｅ（導出）したｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）が常に性能がよりよいことはない。よって、他の実施例として、ある位置のｂｌｏｃｋを参照してｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）をｄｅｒｉｖｅするのかをシグナリングする。例えば、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｅｒｉｖａｔｉｏｎのｃａｎｄｉｄａｔｅ位置が図２４（ａ）のＡ、Ｂ、Ｃ、Ｄ、Ｅの順に決められており、そのうちからどれを参照するのかをシグナリングする。
また他の実施例として、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）をｄｅｒｉｖｅする際、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒに対して近いｂｌｏｃｋから持ってきて正確度を上げることができる。例えば、図２４を参照すると、ｖ０をｄｅｒｉｖａｔｉｏｎする際にはｌｅｆｔ ｂｌｏｃｋを参照し、ｖ１をｄｅｒｉｖａｔｉｏｎする際にはａｂｏｖｅ ｂｌｏｃｋを参照する。または、ｖ０をｄｅｒｉｖａｔｉｏｎする際にＡ、Ｄ、またはＥを参照し、ｖ１をｄｅｒｉｖａｔｉｏｎする際にＢまたはＣを参照してもよい。
図２５は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。
Ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き予測）のためにｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓ（コントロールポイント動きベクトルら）が必要であるが、前記ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓ（コントロールポイント動きベクトルら）に基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄ（動きベクトルフィールド）、つまり、ｓｕｂｂｌｏｃｋ（サブブロック）やある位置に対するｍｏｔｉｏｎ ｖｅｃｔｏｒ（動きベクトル）が計算される。Ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）はｓｅｅｄ ｖｅｃｔｏｒ（シードベクトル）とも称される。
この際、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）はｐｒｅｄｉｃｔｏｒ（予測子）に基づく。例えば、ｐｒｅｄｉｃｔｏｒ（予測子）がｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）になり得る。他の例として、ｐｒｅｄｉｃｔｏｒ（予測子）とｄｉｆｆｅｒｅｎｃｅ（差分）に基づいてｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）が計算されてもよい。詳しくは、ｐｒｅｄｉｃｔｏｒ（予測子）にｄｉｆｆｅｒｅｎｃｅ（差分）を足すか引くことでｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）を計算する。
この際、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｐｒｅｄｉｃｔｏｒを作る過程において、周辺のａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（ＭＣ））したｂｌｏｃｋのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶｓ（コントロールポイント動きベクトルら）またはＭＶｓ（動きベクトルら）からｄｅｒｉｖｅする。例えば、予め設定された位置に当たるｂｌｏｃｋがａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎされたら、そのｂｌｏｃｋのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶｓはＭＶｓから現在ブロックのａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎのためのｐｒｅｄｉｃｔｏｒをｄｅｒｉｖａｔｉｏｎする。図２５を参照すると、予め設定された位置はＡ０、Ａ１、Ｂ０、Ｂ１、Ｂ２である。または、予め設定された位置は現在ｂｌｏｃｋと隣接した位置と隣接しない位置を含む。また、予め設定された位置のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶｓ（コントロールポイント動きベクトルら）またはＭＶｓ（動きベクトルら）を参照し（ｓｐａｔｉａｌ）、予め設定された位置のｔｅｍｐｏｒａｌ ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶｓまたはＭＶｓを参照する。
図２５の実施例のような方法でａｆｆｉｎｅ ＭＣ（アフィン動き補償）のｃａｎｄｉｄａｔｅを作ることができるが、このようなｃａｎｄｉｄａｔｅをｉｎｈｅｒｉｔｅｄ ｃａｎｄｉｄａｔｅと称してもよい。または、このようなｃａｎｄｉｄａｔｅをｍｅｒｇｅ ｃａｎｄｉｄａｔｅ（マージ候補）と称してもよい。また、図２５の方法において、予め設定された位置を参照する際に予め設定された順によって参照する。
図２６は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。
Ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎ（アフィン動き補償）のためにｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓ（コントロールポイント動きベクトルら）が必要であるが、前記ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒｓ（コントロールポイント動きベクトルら）に基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｆｉｅｌｄ（動きベクトルフィールド）、つまり、ｓｕｂｂｌｏｃｋ（サブブロック）やある位置に対するｍｏｔｉｏｎ ｖｅｃｔｏｒが計算される。Ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）はｓｅｅｄ ｖｅｃｔｏｒ（シードベクトル）とも称される。
この際、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）はｐｒｅｄｉｃｔｏｒ（予測子）に基づく。例えば、ｐｒｅｄｉｃｔｏｒがｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）になり得る。他の例として、ｐｒｅｄｉｃｔｏｒとｄｉｆｆｅｒｅｎｃｅ（差分）に基づいてｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）が計算されてもよい。詳しくは、ｐｒｅｄｉｃｔｏｒ（予測子）にｄｉｆｆｅｒｅｎｃｅ（差分）を足すか引くことでｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）を計算する。
この際、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶを作る過程において、周辺のＭＶｓからｄｅｒｉｖｅする。この際、周辺のＭＶｓはａｆｆｉｎｅ ＭＣ（アフィン動き補償）されたＭＶｓ（動きベクトルら）ではない場合のＭＶｓ（動きベクトルら）も含む。例えば、現在ｂｌｏｃｋの各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）をｄｅｒｉｖａｔｉｏｎする際、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶに対して予め設定された位置のＭＶをｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｐｒｅｄｉｃｔｏｒとして使用する。例えば、予め設定された位置はその部分と隣接したｂｌｏｃｋに含まれている部分である。
図２６を参照すると、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル） ｍｖ０、ｍｖ１、ｍｖ２を決定する。この際、本開示の一実施例によると、予め設定された位置Ａ、Ｂ、Ｃに当たるＭＶ（動きベクトル）をｍｖ０に対するｐｒｅｄｉｃｔｏｒとして使用する。また、予め設定された位置Ｄ、Ｅに当たるＭＶ（動きベクトル）をｍｖ１に対するｐｒｅｄｉｃｔｏｒとして使用する。予め設定された位置Ｆ、Ｇに当たるＭＶ（動きベクトル）をｍｖ２に対するｐｒｅｄｉｃｔｏｒとして使用する。
また、図２６の実施例によってｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル） ｍｖ０、ｍｖ１、ｍｖ２の各ｐｒｅｄｉｃｔｏｒ（予測子）を決定する際、各ｃｏｎｔｒｏｌ ｐｏｉｎｔの位置に対する予め設定された位置を参照する順番が決められている。また、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｐｒｅｄｉｃｔｏｒとして参照する予め設定された位置が各ｃｏｎｔｒｏｌ ｐｏｉｎｔに対して多数あり得るが、可能な予め設定された位置の組み合わせが決められている可能性がある。
図２６の実施例のような方法でａｆｆｉｎｅ ＭＣ（アフィン動き補償）のｃａｎｄｉｄａｔｅを作ることができるが、このようなｃａｎｄｉｄａｔｅをｃｏｎｓｔｒｕｃｔｅｄ ｃａｎｄｉｄａｔｅと称してもよい。または、このようなｃａｎｄｉｄａｔｅをｉｎｔｅｒ ｃａｎｄｉｄａｔｅまたはｖｅｒｔｕａｌ ｃａｎｄｉｄａｔｅと称してもよい。また、図４１の方法において、予め設定された位置を参照する際に予め設定された順によって参照する。
本開示の一実施例によると、図２３乃至図２６で説明した実施例またはそれらの組み合わせでａｆｆｉｎｅ ＭＣ（アフィン動き補償）のｃａｎｄｉｄａｔｅ ｌｉｓｔまたはａｆｆｉｎｅ ＭＣ（アフィン動き補償）のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｃａｎｄｉｄａｔｅ ｌｉｓｔ（コントロールポイント動き補償候補リスト）を生成することができる。
図２７は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。
図２４乃至図２５で説明したように、周辺のａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎされたｂｌｏｃｋから現在ｂｌｏｃｋのａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのためのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）をｄｅｒｉｖａｔｉｏｎする。この際、図２７と同じ方法を使用する。図２７の式において、周辺のａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎされたｂｌｏｃｋのｔｏｐ－ｌｅｆｔ、ｔｏｐ－ｒｉｇｈｔ、ｂｏｔｔｏｍ－ｌｅｆｔのＭＶ（動きベクトル）またはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）をそれぞれ（ｖ＿Ｅ０ｘ，ｖ＿Ｅ０ｙ）、（ｖ＿Ｅ１ｘ，ｖ＿Ｅ１ｙ）、（ｖ＿Ｅ２ｘ，ｖ＿Ｅ２ｙ）である。また、周辺のａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎされたｂｌｏｃｋのｔｏｐ－ｌｅｆｔ、ｔｏｐ－ｒｉｇｈｔ、ｂｏｔｔｏｍ－ｌｅｆｔの座標をそれぞれ（ｘ＿Ｅ０，ｙ＿Ｅ０）、（ｘ＿Ｅ１，ｙ＿Ｅ１）、（ｘ＿Ｅ２，ｙ＿Ｅ２）とする。この際、図２７によって現在ｂｌｏｃｋのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｐｒｅｄｉｃｔｏｒまたはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）である（ｖ＿０ｘ，ｖ＿０ｙ）、（ｖ＿１ｘ，ｖ＿１ｙ）を計算する。
図２８は、本開示の一実施例によるａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｏｒ ｄｅｒｉｖａｔｉｏｎを示す図である。
上述したように、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィン動き補償）のために多数のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）または多数のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）が必要である。この際、あるｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）またはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）から他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）またはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）を誘導する。
例えば、前記図面で説明した方法で２つのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）または２つのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）を作り出した際、それに基づいて他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）または他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）を生成する。
図２８を参照すると、ｔｏｐ－ｌｅｆｔ、ｔｏｐ－ｒｉｇｈｔ、ｂｏｔｔｏｍ－ｌｅｆｔのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｐｒｅｄｉｃｔｏｒ（コントロールポイント動きベクトル予測子）またはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）であるｍｖ０、ｍｖ１、ｍｖ２を生成する方法を示している。図面のｘ、ｙはそれぞれｘ－ｃｏｍｐｏｎｅｎｔ、ｙ－ｃｏｍｐｏｎｅｎｔを示しており、現在ｂｌｏｃｋ ｓｉｚｅがｗ＊ｈである。
図２９は、本開示の一実施例によるｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒの生成方法を示す図である。
本開示の一実施例によると、現在ｂｌｏｃｋをａｆｆｉｎｅ ＭＣ（アフィン動き補償）するためにｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｐｒｅｄｉｃｔｏｒを作り、それにｄｉｆｆｅｒｅｎｃｅを足してｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）を決定する。一実施例によると、図２３乃至図２６で説明した方法でｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｐｒｅｄｉｃｔｏｒを作ることができる。Ｄｉｆｆｅｒｅｎｃｅはエンコーダからデコーダにシグナリングされる。
図２９を参照すると、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅが存在する。また、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅがそれぞれシグナリングされる。図２９（ａ）は、４－ｐａｒａｍｅｔｅｒ ｍｏｄｅｌのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶであるｍｖ０、ｍｖ１を決定する方法を示し、図２９（ｂ）は、６－ｐａｒａｍｅｔｅｒ ｍｏｄｅｌのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）であるｍｖ０、ｍｖ１、ｍｖ２を決定する方法を示す。各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅであるｍｖｄ０、ｍｖｄ１、ｍｖｄ２をｐｒｅｄｉｃｔｏｒに足すことでｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）を決定している。
図２９において、上端バー（ｂａｒ）で示したものはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｐｒｅｄｉｃｔｏｒである。
図３０は、図２９で説明した方法によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅの決定方法を示す図である。
一実施例として、図１０で説明した方法でｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）がシグナリングされる。そして、シグナリングされた方法で決定したｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）が図３０のｌＭｖｄである。また、図２９で示したシグナリングされるｍｖｄ（動きベクトル差分）、つまり、ｍｖｄ０、ｍｖｄ１、ｍｖｄ２と同じ値が図３０のｌＭｖｄである。図２９で説明したように、シグナリングされたｍｖｄ（動きベクトル差分）をｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｐｒｅｄｉｃｔｏｒ（予測子）とのｄｉｆｆｅｒｅｎｃｅ（差分）として決定し、その決定したｄｉｆｆｅｒｅｎｃｅ（差分）が図３０のＭｖｄＬ０とＭｖｄＬ１である。Ｌ０はｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ０（第０参照ピクチャリスト）を、Ｌ１はｒｅｆｅｒｅｎｃｅ ｌｉｓｔ １（第１参照ピクチャリスト）を示す。ｃｏｍｐＩｄｘはｃｏｍｐｏｎｅｎｔ ｉｎｄｅｘであって、ｘ、ｙ ｃｏｍｐｏｎｅｎｔなどを示す。
図３１は、本開示の一実施例によるｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒの生成方法を示す図である。
本開示の一実施例によると、現在ｂｌｏｃｋをａｆｆｉｎｅ ＭＣ（アフィン動き補償）するためにｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｐｒｅｄｉｃｔｏｒを作り、それにｄｉｆｆｅｒｅｎｃｅを足してｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）を決定する。一実施例によると、図２３乃至図２６で説明した方法でｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｐｒｅｄｉｃｔｏｒを作ることができる。Ｄｉｆｆｅｒｅｎｃｅ（差分）はエンコーダからデコーダにシグナリングされる。
図３１を参照すると、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅ（差分）に対するｐｒｅｄｉｃｔｏｒ（予測子）が存在する。例えば、あるｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｄｉｆｆｅｒｅｎｃｅ（差分）に基づいて他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）のｄｉｆｆｅｒｅｎｃｅ（差分）を決定する。これはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅ（差分）間の類似性に基づく。類似しているため、ｐｒｅｄｉｃｔｏｒを決定したらｐｒｅｄｉｃｔｏｒとの差を少なくすることができるのである。この際、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅ ｐｒｅｄｉｃｔｏｒ（差分予測子）がシグナリングされ、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）に対するｄｉｆｆｅｒｅｎｃｅ ｐｒｅｄｉｃｔｏｒ（差分予測子）とのｄｉｆｆｅｒｅｎｃｅ（差分）がシグナリングされる。
図３１（ａ）は、４－ｐａｒａｍｅｔｅｒ ｍｏｄｅｌのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）であるｍｖ０、ｍｖ１を決定する方法を示し、図３１（ｂ）は、６－ｐａｒａｍｅｔｅｒ ｍｏｄｅｌのｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）であるｍｖ０、ｍｖ１、ｍｖ２を決定する方法を示す。
図３１を参照すると、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶに対するｄｉｆｆｅｒｅｎｃｅをｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ０であるｍｖ０のｄｉｆｆｅｒｅｎｃｅ（ｍｖｄ０）に基づいてｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶに対するｄｉｆｆｅｒｅｎｃｅ及びｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶを決定している。図３１に示したｍｖｄ０、ｍｖｄ１、ｍｖｄ２をエンコーダからデコーダにシグナリングする。図２９で説明した方法に比べ、図３１の方法は図２９と同じｍｖ０、ｍｖ１、ｍｖ２であって同じｐｒｅｄｉｃｔｏｒを使用してもシグナリングするｍｖｄ１とｍｖｄ２の値が異なり得る。Ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ｍｖ０、ｍｖ１、ｍｖ２のｐｒｅｄｉｃｔｏｒとのｄｉｆｆｅｒｅｎｃｅが類似していれば、図３１の方法を使用したら図２９の方法を使用する際よりｍｖｄ１とｍｖｄ２の絶対値が少ない可能性があり、それによってｍｖｄ１とｍｖｄ２のシグナリングオーバーヘッドを減らすことができる。図３１を参照すると、ｍｖ１のｐｒｅｄｉｃｔｏｒとのｄｉｆｆｅｒｅｎｃｅを（ｍｖｄ１＋ｍｖｄ０）、ｍｖ２のｐｒｅｄｉｃｔｏｒとのｄｉｆｆｅｒｅｎｃｅを（ｍｖｄ２＋ｍｖｄ０）に決定する。
図３１において、上端バー（ｂａｒ）で示したものはｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｐｒｅｄｉｃｔｏｒである。
図３２は、図３１で説明した方法によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅの決定方法を示す図である。
一実施例として、図１０または図３３で説明した方法でｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）がシグナリングされる。そして、シグナリングされたパラメータに基づいて決定されたｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）が図３２のｌＭｖｄである。また、図３１で示したシグナリングされるｍｖｄ、つまり、ｍｖｄ０、ｍｖｄ１、ｍｖｄ２と同じ値が図３２のｌＭｖｄである。
図３２のＭｖｄＬＸは、各ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（コントロールポイント動きベクトル）とｐｒｅｄｉｃｔｏｒ（予測子）との差である。つまり、（ｍｖ－ｍｖｐ）である。この際、図３１で説明したように、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ０（ｍｖ＿０）に対してはシグナリングされたｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅをすぐにｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶに対するｄｉｆｆｅｒｅｎｃｅ（ＭｖｄＬＸ）を使用し、他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ（ｍｖ＿１，ｍｖ＿２）に対してはシグナリングされたｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（図３１ではｍｖｄ１、ｍｖｄ２）及びｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶ ０（ｍｖ＿０）に対してはシグナリングされたｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（図３１ではｍｖｄ０）に基づいてｃｏｎｔｒｏｌ ｐｏｉｎｔ ＭＶのｄｉｆｆｅｒｅｎｃｅであるＭｖｄＬＸを決定して使用する。
図３２において、ＬＸはｒｅｆｅｒｅｎｃｅ ｌｉｓｔ（参照ピクチャリストＸ）を示す。ｃｏｍｐＩｄｘはｃｏｍｐｏｎｅｎｔ ｉｎｄｅｘであって、ｘ、ｙ ｃｏｍｐｏｎｅｎｔなどを示す。ｃｐＩｄｘはｃｏｎｔｒｏｌ ｐｏｉｎｔ ｉｎｄｅｘを示す。ｃｐＩｄｘは図３１で示す０、１、または０、１、２を意味する。
図１０、１２、１３などで示す値にｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅのｒｅｓｏｌｕｔｉｏｎを考慮する。例えば、ｒｅｓｏｌｕｔｉｏｎがＲであれば、図面のｌＭｖｄにｌＭｖｄ＊Ｒの値を使用する。
図３３は、本開示の一実施例によるｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ ｓｙｎｔａｘを示す図である。
図３３を参照すると、図１０の説明と類似した方法でｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅをコーディングする。この際、コーディングはｃｐＩｄｘ、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｉｎｄｅｘによって別に行われる。
図３４は、本開示の一実施例による上位レベルシグナリングの構造を示す図である。本開示の一実施例によると、一つ以上の上位レベルシグナリングが存在する。上位レベルシグナリングは上位レベルにおけるシグナリングを意味する。上位レベルはある単位を含む単位である。例えば、現在ｂｌｏｃｋ（ブロック）また現在ｃｏｄｉｎｇ ｕｎｉｔ（コーディングユニット）の上位レベルはＣＴＵ、ｓｌｉｃｅ、ｔｉｌｅ、ｔｉｌｅ ｇｒｏｕｐ、ｐｉｃｔｕｒｅ、ｓｅｑｕｅｎｃｅなどを含む。上位レベルシグナリングは該当上位レベルの下位レベルに対して影響を及ぼす。例えば、上位レベルがｓｅｑｕｅｎｃｅであれば、ｓｅｑｕｅｎｃｅの下位であるＣＴＵ、ｓｌｉｃｅ、ｔｉｌｅ、ｔｉｌｅ ｇｒｏｕｐ、ｐｉｃｔｕｒｅ単位に影響及ぼす。ここで影響を及ぼすとは、上位レベルシグナリングが下位レベルに対するエンコーディングまたはデコーディングに影響を及ぼすということである。
または、上位レベルシグナリングはあるｍｏｄｅを使用可能であるのか否かを示すシグナリングを含む。図３４を参照すると、上位レベルシグナリングはｓｐｓ＿ｍｏｄｅＸ＿ｅｎａｂｌｅｄ＿ｆｌａｇを含む。一実施例によると、ｓｐｓ＿ｍｏｄｅＸ＿ｅｎａｂｌｅｄ＿ｆｌａｇに基づいてｍｏｄｅ ｍｏｄｅＸを使用可能であるのか否かを判断する。例えば、ｓｐｓ＿ｍｏｄｅＸ＿ｅｎａｂｌｅｄ＿ｆｌａｇがある値である際にはｍｏｄｅ ｍｏｄｅＸを使用することができない。また、ｓｐｓ＿ｍｏｄｅＸ＿ｅｎａｂｌｅｄ＿ｆｌａｇが他のある値である際にはｍｏｄｅ ｍｏｄｅＸを使用することができる。また、ｓｐｓ＿ｍｏｄｅＸ＿ｅｎａｂｌｅｄ＿ｆｌａｇが他のある値である際には、更なるシグナリングに基づいてｍｏｄｅ ｍｏｄｅＸを使用するのか否かを判断する。例えば、前記ある値は０であってもよく、前記他のある値は１であってもよい。しかし、これに限らず、前記ある値は１であってもよく、前記他のある値は０であってもよい。
本開示の一実施例によると、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィン動き補償）が使用可能であるのかを示すシグナリングが存在する。例えば、このシグナリングは上位レベルシグナリングである。図３４を参照すると、このシグナリングはｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）である。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからアフィン可能フラッグをパージングする。
例えば、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が０であれば、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィン動き補償）が使用されないようにｓｙｎｔａｘが制限される。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が０であれば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）、ｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇ（コーディングユニットアフィンタイプフラッグ）が存在しない。
例えば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）はｂｌｏｃｋでａｆｆｉｎｅ ＭＣ（アフィン動き補償）が使用されるのか否かを示すシグナリングである。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）をパージングする。
また、ｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇ（コーディングユニットアフィンタイプフラッグ）はｂｌｏｃｋ（ブロック）からどのｔｙｐｅのａｆｆｉｎｅ ＭＣ（アフィン動き補償）が使用されるのかを示すシグナリングである。また、ここでｔｙｐｅは４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌであるのか、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌであるのかを示す。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が１であれば、ａｆｆｉｎｅ ｍｏｄｅｌ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィン動き補償）が使用可能である。
Aｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィン動き補償）は、ａｆｆｉｎｅ ｍｏｄｅｌ ｂａｓｅｄ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ（アフィンモデル基盤の動き補償）またはａｆｆｉｎｅ ｍｏｄｅｌ ｂａｓｅｄ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ ｆｏｒ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ（インター予測に対するアフィンモデル基盤の動き補償）を意味する。
また、本開示の一実施例によると、どのｍｏｄｅの特定ｔｙｐｅを使用可能であるのかを示すシグナリングが存在する。例えば、特定ｔｙｐｅのａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用可能であるのかを示すシグナリングが存在する。例えば、このシグナリングは上位レベルシグナリングである。図３４を参照すると、このシグナリングはｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇである。また、前記特定ｔｙｐｅは６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを意味する。例えば、ｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが０であれば、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌが使用されないようにｓｙｎｔａｘが制限される。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが０であれば、ｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが存在しない。また、もしｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが１であれば、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌが使用される。もしｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
また、本開示の一実施例によると、どのｍｏｄｅの特定ｔｙｐｅを使用可能であるのかを示すシグナリングは、前記あるｍｏｄｅを使用可能であるのかを示すシグナリングが存在する場合に存在する。例えば、前記どのｍｏｄｅを使用可能であるのかを示すシグナリングが１であれば、前記どのｍｏｄｅの特定ｔｙｐｅを使用可能であるのかを示すシグナリングをｐａｒｓｉｎｇする。また、前記どのｍｏｄｅを使用可能であるのかを示すシグナリングが０であれば、前記どのｍｏｄｅの特定ｔｙｐｅを使用可能であるのかを示すシグナリングをｐａｒｓｉｎｇしない。例えば、どのｍｏｄｅを使用可能であるのかを示すシグナリングはｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）を含む。また、どのｍｏｄｅの特定ｔｙｐｅを使用可能であるのかを示すシグナリングはｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇ（アフィン可能フラッグ）を含む。図３４を参照すると、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が１であればｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇをｐａｒｓｉｎｇする。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が０であればｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇをｐａｒｓｉｎｇせず、その値を０にｉｎｆｅｒ（暗示）する。
また、上述したように、ａｄａｐｔｉｖｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｓｏｌｕｔｉｏｎ（ＡＭＶＲ；適応的な動きベクトル解像度）を使用する。ＡＭＶＲのｒｅｓｏｌｕｔｉｏｎ ｓｅｔを状況いよって異なるように使用する。例えば、ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅによってＡＭＶＲのｒｅｓｏｌｕｔｉｏｎ ｓｅｔを異ならせて使用する。例えば、ＡＭＶＰのようなｒｅｇｕｌａｒ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎを使用する際と、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）を使用する際のＡＭＶＲ ｒｅｓｏｌｕｔｉｏｎ ｓｅｔが異なり得る。また、ＡＭＶＲのようなｒｅｇｕｌａｒ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに適用されるＡＭＶＲは、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（動きベクトル差分）に適用される。または、ＡＭＶＰ（Ａｄｖａｎｃｅｄ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）のようなｒｅｇｕｌａｒ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに適用されるＡＭＶＲは、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒに適用される。また、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）に適用されるＡＭＶＲは、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ（コントロールポイント動きベクトル）またはｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ（コントロールポイント動きベクトル差分）に適用される。
また、本開示の一実施例によると、ＡＭＶＲを使用可能であるのかを示すシグナリングが存在する。このシグナリングは上位レベルシグナリングである。図３４を参照すると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が存在する。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからＡＭＶＲ可能フラッグをパージングする。
本開示の一実施例によるｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）は、適応的な動きベクトル差分解像度が使用されるのか否かを示す。また、本開示の一実施例によるｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）は、適応的な動きベクトル差分解像度が使用可能であるのか否かを示す。例えば、本開示の一実施例によると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば、ＡＭＶＲがｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用可能である。また、本開示の一実施例によると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば、ＡＭＶＲがｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用される。また、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば、どのｒｅｓｏｌｕｔｉｏｎが使用されるのかを指すための更なるシグナリングが存在する。また、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であれば、ＡＭＶＲがｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用されない。また、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であれば、ＡＭＶＲがｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用不可能である。本開示の一実施例によると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）に当たるＡＭＶＲは、ｒｅｇｕｌａｒ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに使用されることを意味する。例えば、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）に当たるＡＭＶＲは、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）に使用されることを意味しない。また、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）の使用可否は、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）によって示される。つまり、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）に当たるＡＭＶＲは、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０である場合に使用されることを意味するか、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１である場合に使用されることを意味しない。
本開示の一実施例によると、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）にＡＭＶＲが使用可能であるのかを示すシグナリングが存在する。このシグナリングは上位レベルシグナリングである。図３４を参照すると、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）にＡＭＶＲが使用可能であるのかを示すシグナリングであるｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が存在する。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからアフィンＡＭＶＲ可能フラッグをパージングする。
ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）は、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用されるのか否かを示す。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）は、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用可能であるのか否かを示す。一実施例によると、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が１であれば、ＡＭＶＲがａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用可能である。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が1であれば、ＡＭＶＲがａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇに使用される。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が０であれば、ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇにＡＭＶＲが使用不可能である。ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が０であれば、ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｄｉｎｇにＡＭＶＲが使用されない。
例えば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が１であれば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１である場合に当たるＡＭＶＲが使用される。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が１であれば、どのｒｅｓｏｌｕｔｉｏｎが使用されるのかを指示するための更なるシグナリングが存在する。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が０であれば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１である場合に当たるＡＭＶＲが使用不可能である。
図３５は、本開示の一実施例によるｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘの構造を示す図である。
図３４で説明したように、ＡＭＶＲを使用する上位レベルシグナリングに基づいてｒｅｓｏｌｕｔｉｏｎを指示するための更なるシグナリングが存在する。図３４を参照すると、ｒｅｓｏｌｕｔｉｏｎを指示するための更なるシグナリングは、ａｍｖｒ＿ｆｌａｇまたはａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇを含む。ａｍｖｒ＿ｆｌａｇまたはａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇは動きベクトル差分の解像度に関する情報である。
一実施例によると、ａｍｖｒ＿ｆｌａｇが０である場合が示すシグナリングが存在する。また、ａｍｖｒ＿ｆｌａｇが１であればａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが存在する。また、ａｍｖｒ＿ｆｌａｇが１であればａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇにも基づいてｒｅｓｏｌｕｔｉｏｎが決定される。例えば、ａｍｖｒ＿ｆｌａｇが０であれば１／４ ｒｅｓｏｌｕｔｉｏｎである。また、もしａｍｖｒ＿ｆｌａｇが存在しなければ、ＣｕＰｒｅｄＭｏｄｅに基づいてａｍｖｒ＿ｆｌａｇ値をｉｎｆｅｒする。例えば、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであればａｍｖｒ＿ｆｌａｇの値を１にｉｎｆｅｒし、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではないか、ＣｕＰｒｅｄＭｏｄｅ（ｃｏｄｉｎｇ ｕｎｉｔ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）がＭＯＤＥ＿ＩＮＴＥＲであればａｍｖｒ＿ｆｌａｇの値を０にｉｎｆｅｒする。
また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０でａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが０であれば、１－ｐｅｌ ｒｅｓｏｌｕｔｉｏｎを使用する。また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１でａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが０であれば、1/１６－ｐｅｌ ｒｅｓｏｌｕｔｉｏｎを使用する。また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０でａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが１であれば、４－ｐｅｌ ｒｅｓｏｌｕｔｉｏｎを使用する。また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１でａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが１であれば、１－ｐｅｌ ｒｅｓｏｌｕｔｉｏｎを使用する。
もしａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが０であれば、その値を０にｉｎｆｅｒする。
一実施例によると、ｒｅｓｏｌｕｔｉｏｎはＭｖＳｈｉｆｔ値によって適用される。また、ＭｖＳｈｉｆｔは動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｆｌａｇ及びａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇによって決定される。例えば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇが０であればＭｖＳｈｉｆｔ値は以下のように決定される。
ＭｖＳｈｉｆｔ＝（ａｍｖｒ＿ｆｌａｇ＋ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇ）＜＜１
また、ＭｖＳｈｉｆｔ値に基づいてＭｖｄ（ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ；動きベクトル差分）値がｓｈｉｆｔされる。例えば、Ｍｖｄ（動きベクトル差分）は以下のようにｓｈｉｆｔされ、それによってＡＭＶＲのｒｅｓｏｌｕｔｉｏｎが適用される。
ＭｖｄＬＸ＝ＭｖｄＬＸ＜＜（ＭｖＳｈｉｆｔ＋２）
他の例として、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１であればＭｖＳｈｉｆｔ値は以下のように決定される。
ＭｖＳｈｉｆｔ＝ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇ？（ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇ＜＜１）：（－（ａｍｖｒ＿ｆｌａｇ＜＜１））
また、ＭｖＳｈｉｆｔ値に基づいてＭｖｄＣｐ（コントロールポイント動きベクトル差分）値がｓｈｉｆｔされる。ＭｖｄＣｐは、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅまたはｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒである。例えば、ＭｖｄＣｐ（コントロールポイント動きベクトル差分）は以下のようにｓｈｉｆｔされ、それによってＡＭＶＲのｒｅｓｏｌｕｔｉｏｎが適用される。
ＭｖｄＣｐＬＸ＝ＭｖｄＣｐＬＸ＜＜（ＭｖＳｈｉｆｔ＋２）
また、ＭｖｄまたはＭｖｄＣｐはｍｖｄ＿ｃｏｄｉｎｇによってシグナリングされる値である。
図３５を参照すると、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであれば、動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｆｌａｇが存在しない。また、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲであれば、動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｆｌａｇが存在するが、この際、ある条件を満足したらａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇすることができる。
本開示の一実施例によると、ＡＭＶＲが使用されるのかを示す上位レベルシグナリング値に基づいてＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓをｐａｒｓｉｎｇするのかを決定する。例えば、ＡＭＶＲが使用されるのかを示す上位レベルシグナリング値が１であれば、ＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓをｐａｒｓｉｎｇする。また、ＡＭＶＲが使用されるのかを示す上位レベルシグナリング値が０であれば、ＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓをｐａｒｓｉｎｇしない。図３５を参照すると、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣである場合、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であれば、動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇをｐａｒｓｉｎｇしない。また、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣである場合、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば、動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇをｐａｒｓｉｎｇする。この際、ｐａｒｓｉｎｇするための更なる条件が考慮される。
例えば、ＭｖｄＬＸ（複数の動きベクトル差分）のうち０ではないものが少なくとも一つ存在すれば、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇをｐａｒｓｉｎｇする。ＭｖｄＬＸはｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ＬＸに対するＭｖｄ値である。また、Ｍｖｄ（動きベクトル差分）はｍｖｄ＿ｃｏｄｉｎｇを介してシグナリングされる。ＬＸはＬ０（第０参照ピクチャリスト）、Ｌ１（第１参照ピクチャリスト）を含む。また、ＭｖｄＬＸはｘ軸、ｙ軸それぞれに当たる成分が存在する。例えば、ｘ軸はｐｉｃｔｕｒｅの横軸に当たり、ｙ軸はｐｉｃｔｕｒｅの縦軸に当たる。図３５を参照すると、ＭｖｄＬＸ［ｘ０］［ｙ０］［０］、ＭｖｄＬＸ［ｘ０］［ｙ０］［１］において、［０］、［１］がそれぞれｘ軸、ｙ軸の成分に対するものであることを指示する。また、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであればＬ０のみ使用する。図３５を参照すると、１）ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１で、２）ＭｖｄＬ０［ｘ０］［ｙ０］［０］またはＭｖｄＬ０［ｘ０］［ｙ０］［１］が０でなければ、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇをｐａｒｓｉｎｇする。また、１）ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であるか、２）ＭｖｄＬ０［ｘ０］［ｙ０］［０］とＭｖｄＬ０［ｘ０］［ｙ０］［１］がいずれも０であれば、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇをｐａｒｓｉｎｇしない。
また、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではない場合があり得る。この際、図３５を参照すると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１で、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０で、ＭｖｄＬＸ（複数の動きベクトル差分）値のうち０ではないものが少なくとも一つ存在すれば、ａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇする。ここで、ａｍｖｒ＿ｆｌａｇは動きベクトル差分の解像度に関する情報である。また、上述したように、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であるということは、適応的な動きベクトル差分解像度の使用を示す。また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０であるということは、現在ブロックに対してアフィン動き補償を使用しないことを示す。また、図３４で説明したように、ａｍｖｒ＿ｆｌａｇのような動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する前記複数の動きベクトル差分が修正される。この条件をｃｏｎｄｉｔｉｏｎ Ａと称する。
また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が１で、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１で、ＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）値のうち０ではないものが少なくとも一つ存在すれば、ａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇする。ここで、ａｍｖｒ＿ｆｌａｇは動きベクトル差分の解像度に関する情報である。また、上述したように、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が１であるということは、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用されることを示す。また、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１であるということは、現在ブロックに対してアフィン動き補償を使用することを示す。また、図３４で説明したように、ａｍｖｒ＿ｆｌａｇのような動きベクトル差分の解像度に関する情報に基づいて現在ブロックに対する前記複数のコントロールポイント動きベクトル差分が修正される。この条件をｃｏｎｄｉｔｉｏｎ Ｂと称する。
また、ｃｏｎｄｉｔｉｏｎ Ａまたはｃｏｎｄｉｔｉｏｎ Ｂを満足したらａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇする。また、ｃｏｎｄｉｔｉｏｎ Ａとｃｏｎｄｉｔｉｏｎ Ｂをいずれも満足しなければ、動きベクトル差分の解像度に関する情報であるａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇしない。つまり、１）ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であるか、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１であるか、ＭｖｄＬＸ（複数の動きベクトル差分）がいずれも０で、２）ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０であるか、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が０であるか、ＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）値がいずれも０であれば、ａｍｖｒ＿ｆｌａｇをｐａｒｓｉｎｇしない。
また、ａｍｖｒ＿ｆｌａｇ値に基づいてａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇのｐａｒｓｉｎｇ可否を決定する。例えば、ａｍｖｒ＿ｆｌａｇ値が１であれば、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇのｐａｒｓｉｎｇする。また、ａｍｖｒ＿ｆｌａｇ値が０であれば、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇのｐａｒｓｉｎｇしない。
また、ＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）はｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒに対するｄｉｆｆｅｒｅｎｃｅを意味する。また、ＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）はｍｖｄ＿ｃｏｄｉｎｇを介してシグナリングされる。ＬＸはＬ０（第０参照ピクチャリスト）、Ｌ１（第１参照ピクチャリスト）を含む。また、ＭｖｄＣｐＬＸはｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ０、１、２などに当たる成分が存在する。例えば、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ０、１、２などは現在ｂｌｏｃｋを基準にする予め設定された位置に当たるｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒである。
図３５を参照すると、ＭｖｄＣｐＬＸ［ｘ０］［ｙ０］［０］［］、ＭｖｄＣｐＬＸ［ｘ０］［ｙ０］［１］［］、ＭｖｄＣｐＬＸ［ｘ０］［ｙ０］［２］［］において、［０］、［１］、［２］がそれぞれｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ０、１、２に当たることを指示する。また、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ０に当たるＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）値は他のｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒにも使用される。例えば、図４７で使用されたように、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ０を使用してもよい。また、ＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）はｘ軸、ｙ軸それぞれに当たる成分が存在する。例えば、ｘ軸はｐｉｃｔｕｒｅの横軸に当たり、ｙ軸はｐｉｃｔｕｒｅの縦軸に当たる。図３５を参照すると、ＭｖｄＣｐＬＸ［ｘ０］［ｙ０］［］［０］、ＭｖｄＣｐＬＸ［ｘ０］［ｙ０］［］［１］において、［０］、［１］がそれぞれｘ軸、ｙ軸の成分に対することを指示する。
図３６は、本開示の一実施例による上位レベルシグナリングの構造を示す図である。
図３４乃至図３５で説明したような上位レベルシグナリングが存在する。例えば、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）、ｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇなどが存在する。
本開示の一実施例によると、前記上位レベルシグナリングはｐａｒｓｉｎｇ ｄｅｐｅｎｄｅｎｃｙを有する。例えば、どの上位レベルシグナリング値に基づいて他の上位レベルシグナリングをｐａｒｓｉｎｇするのか否かを決定する。
本開示の一実施例によると、ａｆｆｉｎｅ ＭＣ（アフィン動き補償）を使用可能であるのかに基づいてａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを決定する。例えば、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングに基づいてａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを決定する。より詳しくは、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングに基づいて、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングのｐａｒｓｉｎｇ可否を決定する。
一実施例として、ａｆｆｉｎｅ ＭＣを使用可能な場合、ａｆｆｉｎｅ ＡＭＶＲを使用可能な可能性がある。また、ａｆｆｉｎｅ ＭＣを使用不可能な場合はａｆｆｉｎｅ ＡＭＶＲを使用不可能な可能性がある。
より詳しくは、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが１であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能である。この際、更なるシグナリングされるが存在する。また、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが０であれば、ａｆｆｉｎｅ ＡＭＶＲを使用不可能である。例えば、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが１であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇする。また、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが０であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇしない。また、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングが存在しなければ、その値をｉｎｆｅｒｓする。例えば、０にｉｎｆｅｒする。他の例として、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングに基づいてｉｎｆｅｒする。また他の例として、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングに基づいてｉｎｆｅｒする。
一実施例によると、ａｆｆｉｎｅ ＡＭＶＲは図３４乃至図３５で説明したａｆｆｉｎｅ ＭＣに使用するＡＭＶＲである。例えば、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングは、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）である。また、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングはｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇである。
図３６を参照すると、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が１であればｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇをｐａｒｓｉｎｇする。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が０であれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇをｐａｒｓｉｎｇしない。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
本開示の実施例は、ａｆｆｉｎｅ ＡＭＶＲはａｆｆｉｎｅ ＭＣを使用する場合に意味があるためである。
図３７は、本開示の一実施例による上位レベルシグナリングの構造を示す図である。
図３４乃至図３５で説明したような上位レベルシグナリングが存在する。例えば、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）、ｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇなどが存在する。
本開示の一実施例によると、前記上位レベルシグナリングはｐａｒｓｉｎｇ ｄｅｐｅｎｄｅｎｃｙ（パージング依存性）を有する。例えば、どの上位レベルシグナリング値に基づいて他の上位レベルシグナリングをｐａｒｓｉｎｇするのか否かを決定する。
本開示の一実施例によると、ＡＭＶＲを使用可能であるのかに基づいてａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを決定する。例えば、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングに基づいてａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを決定する。より詳しくは、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングに基づいて、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングのｐａｒｓｉｎｇ可否を決定する。
一実施例として、ＡＭＶＲを使用可能な場合、ａｆｆｉｎｅ ＡＭＶＲを使用可能な可能性がある。また、ＡＭＶＲを使用不可能な場合はａｆｆｉｎｅ ＡＭＶＲを使用不可能な可能性がある。
より詳しくは、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングが１であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能である。この際、追加のシグナリングが存在する可能性がある。また、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングが０であれば、ａｆｆｉｎｅ ＡＭＶＲを使用不可能である。例えば、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングが１であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇする。また、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングが０であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇしない。また、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが存在しなければ、その値をｉｎｆｅｒｓする。例えば、０にｉｎｆｅｒする。他の例として、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングに基づいてｉｎｆｅｒする。また他の例として、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングに基づいてｉｎｆｅｒする。
一実施例によると、ａｆｆｉｎｅ ＡＭＶＲは図３４乃至図３５で説明したａｆｆｉｎｅ ＭＣ（アフィン動き補償）に使用するＡＭＶＲである。例えば、ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングは、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）である。また、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングは、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）である。
図３７（ａ）を参照すると、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）をｐａｒｓｉｎｇする。また、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）をｐａｒｓｉｎｇしない。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が存在しなければ、その値を０にｉｎｆｅｒする。
本開示の一実施例は、ｓｅｑｕｅｎｃｅによってａｄａｐｔｉｖｅ ｒｅｓｏｌｕｔｉｏｎ（適応的な解像度）が効率的であるのかが異なり得るためである。
また、ａｆｆｉｎｅ ＡＭＶＲの使用可否が、ａｆｆｉｎｅ ＭＣの使用可否及びＡＭＶＲの使用可否をいずれも考慮して決定される。例えば、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングとＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングに基づいて、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングのｐａｒｓｉｎｇ可否を決定する。一実施例によると、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングとＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングがいずれも１であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇする。また、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングまたはＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングがいずれも０であれば、ａｆｆｉｎｅ ＡＭＶＲを使用可能であるのかを示す上位レベルシグナリングをｐａｒｓｉｎｇしない。また、ａｆｆｉｎｅ ＭＣを使用可能であるのかを示す上位レベルシグナリングが存在しなければ、その値をｉｎｆｅｒｓする。
図３７（ｂ）を参照すると、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）とｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）がいずれも１であれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）をｐａｒｓｉｎｇする。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）とｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）のうち少なくとも一つが０であれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）をｐａｒｓｉｎｇしない。また、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が存在しなければ、その値を０にｉｎｆｅｒする。
より詳しく図３７（ｂ）を説明すると、ライン３７０１において、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）に基づいてアフィン動き補償の使用可否が決定される。図３４乃至図３５で既に説明したように、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が１であればアフィン動き補償が使用可能であることを意味する。また、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が０であれば、アフィン動き補償が使用不可能であることを意味する。
図３７（ｂ）のライン３７０１において、アフィン動き補償が使用されると決定されれば、ライン３７０２において、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）に基づいて適応的な動きベクトル差分解像度の使用可否が決定される。図３４乃至図３５で既に説明したように、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が１であれば適応的な動きベクトル差分解像度が使用されることを意味する。ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が０であれば、適応的な動きベクトル差分解像度が使用されないことを意味する。
ライン３７０１において、アフィン動き補償が使用されないと決定されれば、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）に基づいて適応的な動きベクトル差分解像度の使用可否が決定されない。つまり、図３７（ｂ）のライン３７０２が行われない。詳しくは、アフィン動き補償が使用されなければ、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）はエンコーダからデコーダに伝送されない。つまり、デコーダはｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）を受信せず、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）がでからパージングされない。この際、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）は存在しないため０と暗示（ｉｎｆｅｒ）される。上述したように、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が０であれば、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用できないことを示す。
図３７（ｂ）のライン３０７２において、適応的な動きベクトル差分解像度が使用されると決定されれば、ライン３７０３において、ビットストリームからアフィン動き補償に対する適応的な動きベクトル差分解像度の使用可否を示すｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）がパージングされる。
ライン３０７２において、適応的な動きベクトル差分解像度使用されないと決定されれば、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）はビットストリームからパージングされない。つまり、図３７（ｂ）のライン３７０３が行われない。より詳しくは、アフィン動き補償を使用し、適応的な動きベクトル差分解像度をしない場合、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）はエンコーダからデコーダに伝送されない。つまり、デコーダはｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）を受信しない。デコーダはｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）をビットストリームからパージングしない。この際、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）は存在しないため０と暗示（ｉｎｆｅｒ）される。上述したように、ｓｐｓ＿ａｆｆｉｎｅ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィンＡＭＶＲ可能フラッグ）が０であれば、アフィン動き補償に対して適応的な動きベクトル差分解像度が使用できないことを示す。
図３７（ｂ）のように、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）を先に確認し、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）を次に確認することで、不必要な処理過程を減らすことができるため効率性を上げることができる。例えば、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）が先に確認され、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が次に確認されれば、７番目の行からｓｐｓ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇを導出するためにｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）を再度確認しなければならない。しかし、ｓｐｓ＿ａｆｆｉｎｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（アフィン可能フラッグ）が先に確認され、ｓｐｓ＿ａｍｖｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（ＡＭＶＲ可能フラッグ）を次に確認することで、このような不必要な過程を減らすことができる。
図３８は、本開示の一実施例によるｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘの構造を示す図である。
図３５で説明したように、ＭｖｄＬＸまたはＭｖｄＣｐＬＸのうち０ではない値が少なくとも一つ存在するのか否かで、ＡＭＶＲに関連するｓｙｎｔａｘｗｐａｒｓｉｎｇするのか否かを決定する。しかし、どのｒｅｆｅｒｅｎｃｅ ｌｉｓｔ（参照ピクチャリスト）を使用するのか、ａｆｆｉｎｅ ｍｏｄｅｌがいくつのｐａｒａｍｅｔｅｒを使用するのかなどによって、使用するＭｖｄＬＸ（動きベクトル差分）またはＭｖｄＣｐＬX（コントロールポイント動きベクトル差分）が異なり得る。もし、ＭｖｄＬＸまたはＭｖｄＣｐＬＸの初期値が０でなければ、現在ｂｌｏｃｋで称しないＭｖｄＬＸまたはＭｖｄＣｐＬＸが０ではないため、不必要なＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔをシグナリングするようになり、ｅｎｃｏｄｅｒとｄｅｃｏｄｅｒ間のｍｉｓｓｍａｔｃｈを起こす恐れがある。図３８乃至図３９は、ｅｎｃｏｄｅｒとｄｅｃｏｄｅｒ間のｍｉｓｓｍａｔｃｈを起こさない方法を説明する。
一実施例によると、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）は、どの参照リスト（ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ）を使用するのか、またはｐｒｅｄｉｃｔｉｏｎの方向がどのようであるのかを示す。例えば、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）はＰＲＥＤ＿Ｌ０またはＰＲＥＤ＿Ｌ１またはＰＲＥＤ＿ＢＩの値である。もし、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ０であれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ０（第０参照ピクチャリスト）のみを使用する。また、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ１であれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ １（第１参照ピクチャリスト）のみを使用する。また、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿ＢＩであれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ０（第０参照ピクチャリスト）とｒｅｆｅｒｅｎｃｅ ｌｉｓｔ １（第１参照ピクチャリスト）をいずれも使用する。ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ０またはＰＲＥＤ＿Ｌ１であれば、ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎである。また、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿ＢＩであれば、ｂｉ－ｐｒｅｄｉｃｔｉｏｎである。
また、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃ値に基づいてどのａｆｆｉｎｅ ｍｏｄｅｌを使用するのかを決定する。また、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃ値に基づいてどのａｆｆｉｎｅ ＭＣを使用するのかを決定する。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃがｔｒａｎｓｌａｔｉｏｎ ｍｏｔｉｏｎまたは４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｔｉｏｎまたは６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｔｉｏｎを示す。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃがｔｒａｎｓｌａｔｉｏｎ ｍｏｔｉｏｎ値が０、１、２であれば、それぞれｔｒａｎｓｌａｔｉｏｎ ｍｏｔｉｏｎ、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｔｉｏｎ、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｔｉｏｎを指示する。また、一実施例によると、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃはｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）とｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇに基づいて決定される。例えば、ｍｅｒｇｅ＿ｆｌａｇが０であれば（ｍｅｒｇｅ ｍｏｄｅでなければ）、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃがｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）とｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇに基づいて決定される。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃは（ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ＋ｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇ）である。他の実施例によると、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃはｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇによって決定される。例えば、ｍｅｒｇｅ＿ｆｌａｇが１であれば（ｍｅｒｇｅ ｍｏｄｅであれば）、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃはｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇによって決定される。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃ値はｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ値に設定される。
例えば、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ０であるかＰＲＥＤ＿ＢＩであれば、ＭｖｄＬＸ（動きベクトル差分）またはＭｖｄＣｐＬX（コントロールポイント動きベクトル差分）においてＬ０に当たる値を使用する。よって、ＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする際、ＭｖｄＬ０またはＭｖｄＣｐＬ０はｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ０であるかＰＲＥＤ＿ＢＩである場合にのみ考慮する。つまり、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ１であれば、ＭｖｄＬ０（第０参照ピクチャリストに対する動きベクトル差分）またはＭｖｄＣｐＬ０（第０参照ピクチャリストに対するコントロールポイント動きベクトル差分）を考慮しなくてもよい。
また、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ１であるかＰＲＥＤ＿ＢＩであれば、ＭｖｄＬＸまたはＭｖｄＣＰＬＸにおいてＬ１に当たる値を使用する。よって、ＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする際、ＭｖｄＬ１（第１参照ピクチャリストに対する動きベクトル差分）またはＭｖｄＣｐＬ１（第１参照ピクチャリストに対するコントロールポイント動きベクトル差分）は、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ１であるかＰＲＥＤ＿ＢＩである場合のみ考慮する。つまり、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿Ｌ０であれば、ＭｖｄＬ１またはＭｖｄＣｐＬ１を考慮しなくてもよい。
図３８を参照すると、ＭｖｄＬ０とＭｖｄＣｐＬ０は、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ１ではない場合にのみその値が０ではないのかによってＡＭＶＲに関連するｓｙｎｔａｘのｐａｒｓｉｎｇ可否を決定する。つまり、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ１であれば、ＭｖｄＬ０のうちに０ではない値があるか、ＭｖｄＣｐＬ０のうちに０ではない値がある場合もＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇしない。
また、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが１であれば、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［０］［］、ＭｖｄＣｐＬXｘ０］［ｙ０］［１］［］、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］のうちＭｖｄＣｐＬX［ｘ０］［ｙ０］［０］［］、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［１］［］のみを考慮する。つまり、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが１であれば、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］を考慮しない。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが１であれば、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］のうちに０ではない値があるのか否かは、ＡＭＶＲに関連するｓｙｎｔａｘのｐａｒｓｉｎｇ可否に影響を及ぼさない。
また、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが２であれば、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［０］［］、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［１］［］、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］をいずれも考慮する。つまり、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが２であれば、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］を考慮する。
また、前記実施例において、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃを１、２で示したものは、ｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇが０、１であると表現することもできるこれは、ａｆｆｉｎｅ ＭＣの使用可否を破断することができるためである。例えば、ａｆｆｉｎｅ ＭＣの使用可否をｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）によって判断する。
図３８を参照すると、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］のうちに０ではないものがあるのかをＭｏｔｉｏｎＭｏｄｅｌＩｄｃが２である場合にのみ考慮する。もし、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［０］［］、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［１］［］がいずれも０で、ＭｖｄＣｐＬX［ｘ０］［ｙ０］［２］［］のうちに０ではないものが少なくとも一つあれば（上述した実施例によって、ここでＬ０、Ｌ１を分けてＬ０、Ｌ１のうち一つに当たるもののみを考慮してもよい。）、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが２でなければ、ＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇしない。
図３９は、本開示の一実施例によるＭＶＤ基本値の設定を示す図である。
上述したように、ＭｖｄＬX（動きベクトル差分）またはＭｖｄＣｐＬX（コントロールポイント動きベクトル差分はｍｖｄ＿ｃｏｄｉｎｇによってシグナリングされる。また、ｍｖｄ＿ｃｏｄｉｎｇによってＩＭｖｄ値がシグナリングされて、ＭｖｄＬXまたはＭｖｄＣｐＬXをＩＭｖｄ値に設定する。図３９を参照すると、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが０であれば、ＩＭｖｄ値によってＭｖｄＬXを設定する。また、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが０でなければ、ＩＭｖｄ値によってＭｖｄＣｐＬXを設定する。また、ｒｅｆＬｉｓｔ値によってＬＸのうちいずれかに当たる動作をするのかを決定する。
また、図１０または図２３、図３４、図３５などで説明したように、ｍｖｄ＿ｃｏｄｉｎｇが存在する。また、ｍｖｄ＿ｃｏｄｉｎｇは、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２、ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇなどをｐａｒｓｉｎｇするステップ、または決定するステップを含む。また、ＩＭｖｄは、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ、ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２、ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇなどによって決定される。
図３９を参照すると、ＩＭｖｄは以下のように設定される。
ＩＭｖｄ＝ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ＊（ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２＋２）＊（１－２＊ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇ）
ＭｖｄＬX（動きベクトル差分）またはＭｖｄＣｐＬX（コントロールポイント動きベクトル差分）の基本値を予め設定された値に設定する。本開示の一実施例によると、ＭｖｄＬXまたはＭｖｄＣｐＬXの基本値を０に設定する。または、ＩＭｖｄの基本値を予め設定された値に設定する。または、ＩＭｖｄまたはＭｖｄＬXまたはＭｖｄＣｐＬXの値が予め設定された値になるように関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔの基本値を設定する。Ｓｙｎｔａｘ ｅｌｅｍｅｎｔのきほんはｓｙｎｔａｘ ｅｌｅｍｅｎｔが存在しなければｉｎｆｅｒする値を意味する。前記予め設定された値は０である。
本開示の一実施例によると、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇはＭＶＤのａｂｓｏｌｕｔｅ ｖａｌｕｅが０より大きいのか否かを指示する。また、本開示の一実施例によると、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。このような場合、ＩＭｖｄ値が０に設定される。また、このような場合、ＭｖｄＬXまたはＭｖｄＣｐＬX値が０に設定される。
または、本開示の一実施例によると、ＩＭｖｄまたはＭｖｄＬXまたはＭｖｄＣｐＬX値が設定されていなければ、その値を予め設定された値に設定する。例えば、０に設定する。
また、本開示の一実施例によると、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇが存在しなければ、該当するＩＭｖｄまたはＭｖｄＬXまたはＭｖｄＣｐＬX値を０に設定する。
本開示の一実施例によると、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇはＭＶＤのａｂｓｏｌｕｔｅ ｖａｌｕｅが１より大きいのか否かを指示する。また、ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
また、ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２＋２はＭＶＤのａｂｓｏｌｕｔｅ ｖａｌｕｅ値を指示する。また、ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２値が存在しなければ、その値を－１にｉｎｆｅｒする。
また、ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇはＭＶＤのｓｉｇｎを指示する。ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇが０、１であれば、該当ＭＶＤがそれぞれｐｏｓｉｔｉｖｅ、ｎｅｇａｔｉｖｅ ｖａｌｕｅであることを示す。もしｍｖｄ＿ｓｉｇｎ＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
図４０は、本開示の一実施例によるＭＶＤ基本値の設定を示す図である。ＭｖｄＬXまたはＭｖｄＣｐＬXの初期値を０にして、ｅｎｃｏｄｅｒとｄｅｃｏｄｅｒ間のｍｉｓｓｍａｔｃｈを起こさないように図３９で説明したように、ＭｖｄＬX（複数の動きベクトル差分）またはＭｖｄＣｐＬX（複数のコントロールポイント動きベクトル差分）値は初期化される。また、この際、初期化する値は０である。図４０の実施例はそれについてより詳しく説明する。
本開示の一実施例によると、ＭｖｄＬX（複数の動きベクトル差分）またはＭｖｄＣｐＬX（複数のコントロールポイント動きベクトル差分）値は予め設定された値に初期化される。また、初期化する位置はＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓをｐａｒｓｉｎｇする位置より先である。前記ＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓは、図４０のａｍｖｒ＿ｆｌａｇ、ａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇなどを含む。ａｍｖｒ＿ｆｌａｇまたはａｍｖｒ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇは動きベクトル差分の解像度に関する情報である。
前記ＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓによってＭＶＤ（動きベクトル差分）またはＭＶ（動きベクトル）のｒｅｓｏｌｕｔｉｏｎ、またはＭＶＤまたはＭＶのシグナリングされるｒｅｓｏｌｕｔｉｏｎが決定される。また、本開示の実施例において、初期化する予め設定された値に０である。
書庫異化することでＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓをｐａｒｓｉｎｇする際、ｅｎｃｏｄｅｒ、ｄｅｃｏｄｅｒ間のＭｖｄＬX、ＭｖｄＣｐＬX値が同じくなるため、ｅｎｃｏｄｅｒとｄｅｃｏｄｅｒ間のｍｉｓｓｍａｔｃｈが起こらない。また、初期かを０の値にすることで、不必要にＡＭＶＲに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔｓがビットストリームに含まれない。
本開示の一実施例によると、ＭｖｄＬXはｒｅｆｅｒｅｎｃｅ Ｌｉｓｔ（Ｌ０、Ｌ１など）、ｘ－ ｏｒ ｙ－ｃｏｍｐｏｎｅｎｔなどに対して定義される。また、ＭｖｄＣｐＬXはｒｅｆｅｒｅｎｃｅ Ｌｉｓｔ（Ｌ０、Ｌ１など）、ｘ－ ｏｒ ｙ－ｃｏｍｐｏｎｅｎｔ、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ０、１、２などに対して定義される。
本開示の一実施例によると、ＭｖｄＬXまたはＭｖｄＣｐＬXの値をいずれも初期化する。また、初期化する位置は、該当ＭｖｄＬXまたはＭｖｄＣｐＬXに対するｍｖｄ＿ｃｏｄｉｎｇを行う前である。例えば、Ｌ０のみを使用するｐｒｅｃｉｓｉｏｎ ｂｌｏｃｋにおいてもＬ０に当たるＭｖｄＬX、ＭｖｄＣｐＬXを初期化することができる。初期化が必須的に必要なもののみを初期化するためには条件の確認が必要であるが、このように区分せずに初期化することで、条件の確認に負担を減らすことができる。
本開示の他の実施例によると、ＭｖｄＬXまたはＭｖｄＣｐＬX値のうち使用しないものに当たる値を初期化する。ここで、使用しないとは現在ｂｌｏｃｋで使用しないことを意味する。例えば、ＭｖｄＬXまたはＭｖｄＣｐＬXのうち現在使用しないｒｅｆｅｒｅｎｃｅ ｌｉｓｔに当たる値を初期化する。例えば、Ｌ０を使用しなければ、ＭｖｄＬ０、ＭｖｄＣｐＬ０に当たる値を初期化する。Ｌ０を使用しないのは、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ１の場合である。また、Ｌ１を使用しなければ、ＭｖｄＬ１、ＭｖｄＣｐＬ１に当たる値を初期化する。Ｌ１を使用しないのは、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ０の場合である。Ｌ０を使用するのはｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ０であるかＰＲＥＤ＿ＢＩの場合である。また、Ｌ１を使用するのはｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ１であるかＰＲＥＤ＿ＢＩの場合である。図４０を参照すると、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ１であれば、ＭｖｄＬ０［ｘ０］［ｙ０］［０］、ＭｖｄＬ０［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［２］［１］を初期化する。また、初期化する値は０である。また、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿Ｌ０あれば、ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］を初期化する。また、初期化する値は０である。
ＭｖｄＬX［ｘ］［ｙ］［ｃｏｍｐＩｄｘ］は、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ＬＸに対する（ｘ，ｙ）位置、ｃｏｍｐｏｎｅｎｔ ｉｎｄｅｘ ｃｏｍｐＩｄｘに対するｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅである。ＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］は、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ ＬＸに対するｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅである。また、ＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］は、位置（ｘ，ｙ）、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｐＩｄｘ、及びｃｏｍｐｏｎｅｎｔ ｉｎｄｅｘ ｃｏｍｐＩｄｘに対するｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅである。ここで、ｃｏｍｐｏｎｅｎｔはｘまたはｙ成分を示す。
また、本開示の一実施例によると、ＭｖｄＬX（動きベクトル差分）またはＭｖｄＣｐＬX（コントロールポイント動きベクトル差分）のうち使用しないものはａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎの使用可否による。例えば、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎが使用されれば、ＭｖｄＬXを初期化する。また、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎが使用されなければ、ＭｖｄＣｐＬXを初期化する。例えば、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用するのかを示すシグナリングが存在する。図４０を参照すると、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）はａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用するのかを示すシグナリングである。例えば、ｉｎｔｅｒ＿ａｆｆｉｎｅ＿ｆｌａｇ（インターアフィンフラッグ）が１であればａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用する。または、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃはａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用するのかを示すシグナリングである。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが０でなければａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用する。
また、本開示の一実施例によると、ＭｖｄＬXまたはＭｖｄＣｐＬXのうち使用しないものはどのａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用するのかに関する。例えば、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのか、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのかによって使用しないＭｖｄＬXまたはＭｖｄＣｐＬXが異なり得る。例えば、どのａｆｆｉｎｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎを使用するのかによってＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］のｃｐＩｄｘに対して使用しないものが異なり得る。例えば、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用する場合、ＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］のうち一部のみを使用する。または、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用しない場合、ＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］のうち一部のみを使用する。よって、使用しないＭｖｄＣｐＬXを予め設定された値に初期化する。この際、使用しないＭｖｄＣｐＬＸは６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌでは使用し、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌでは使用しないｃｐＩｄｘに当たる。例えば、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用すれば、ＭｖｄＣｐＬX［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］のｃｐＩｄｘが２の値を使用せず、それを予め設定された値に初期化する。また、上述したように、４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのか、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのかを示すシグナリングまたはｐａｒａｍｅｔｅｒが存在する。例えば、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃまたはｃｕ＿ａｆｆｉｎｅ＿ｔｙｐｅ＿ｆｌａｇによって４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのか６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用するのかが分かる。ＭｏｔｉｏｎＭｏｄｅｌＩｄｃ値が１、２であることは、それぞれ４－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌ、６－ｐａｒａｍｅｔｅｒ ａｆｆｉｎｅ ｍｏｄｅｌを使用することを示す。図４０を参照すると、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが１であれば、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ０［ｘ０］［ｙ０］［２］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］を予め設定された値に初期化する。また、この際、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃが１である場合の代わりにＭｏｔｉｏｎＭｏｄｅｌＩｄｃが２ではない場合の条件を使用することもできる。前記予め設定された値は０である。
また、本開示の一実施例によると、ＭｖｄＬＸまたはＭｖｄＣｐＬＸのうち使用しないものは、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）に基づく。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１であれば、ＭｖｄＬ１、ＭｖｄＣｐＬ１を予め設定された値に初期化する。また、この際、更なる条件を考慮する。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇとｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）に基づいて、ＭｖｄＬＸまたはＭｖｄＣｐＬＸのうち使用しないものが決定される。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１、ＭｖｄＣｐＬ１を予め設定された値に初期化する。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）はｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭＶＤ値（例えば、ＭｖｄＬＸまたはＭｖｄＣｐＬＸ）が０であることを示す上位レベルシグナリングである。シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダは、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）をビットストリームからパージングする。
本開示の他の実施例によると、あるｂｌｏｃｋに対してｍｖｄ＿ｃｏｄｉｎｇを行う前に全てのＭｖｄ、ＭｖｄＣｐを予め設定された値に初期化する。この際、ｍｖｄ＿ｃｏｄｉｎｇはあるＣＵに対する全てのｍｖｄ＿ｃｏｄｉｎｇを意味する。よって、ｍｖｄ＿ｃｏｄｉｎｇ ｓｙｎｔａｘをｐａｒｓｉｎｇし、決定したＭｖｄまたはＭｖｄＣｐ値を初期化することが発生しないようにし、全てのＭｖｄ、ＭｖｄＣＰ値を初期化することで説明した問題を解決する。
図４１は、本開示の一実施例によるＡＭＶＲに関連するｓｙｎｔａｘの構造を示す図である。図４１の実施例は、図３８の実施例に基づく。
図３８で説明したように、ＭｖｄＬＸ（動きベクトル差分）またはＭｖｄＣｐＬＸ（コントロールポイント動きベクトル差分）のうち０ではない値が少なくとも一つ存在するのか否かを確認する。この際、確認するＭｖｄＬＸまたはＭｖｄＣｐＬＸはｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）に基づいて決定される。よって、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＡＭＶＲに関連するｓｙｎｔａｘのｐａｒｓｉｎｇ可否が決定される。上述したように、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１であればｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭＶＤ（動きベクトル差分）が０であることを示すため、この場合はＭｖｄＬ１（第１参照ピクチャリストに対する動きベクトル差分）またはＭｖｄＣｐＬ１（第１参照ピクチャリストに対するコントロールポイント動きベクトル差分）を考慮しない。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１であればＭｖｄＬ１またはＭｖｄＣｐＬ１が０なのか否かに関わらずＭｖｄＬ０（第０参照ピクチャリストに対する動きベクトル差分）またはＭｖｄＣｐＬ０（第０参照ピクチャリストに対するコントロールポイント動きベクトル差分）のうちから０である値が少なくとも一つ存在するのか否かに基づいてＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする。更なる実施例によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇがｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭＶＤが０であることを示すのはｂｉ－ｐｒｅｄｉｃｔｉｏｎのｂｌｏｃｋに対してのみである。よって、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ及びｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）に基づいてＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ及びｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）に基づいて０ではない値が少なくとも一つ存在するのか否かを判断するＭｖｄＬＸまたはＭｖｄＣｐＬＸが決定される。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ及びｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃに基づいてＭｖｄＬ１またはＭｖｄＣｐＬ１を考慮しなくてもよい。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１またはＭｖｄＣｐＬ１を考慮しない。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１またはＭｖｄＣｐＬ１が０なのか否かに関わらず、ＭｖｄＬ０またはＭｖｄＣｐＬ０のうちから０である値が少なくとも一つ存在するのか否かに基づいてＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする。
図４１を参照すると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ［ｘ０］［ｙ０］＝＝ＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］のうち０ではない値が存在するのか否かに関わらない動作を行う。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ［ｘ０］［ｙ０］＝＝ＰＲＥＤ＿ＢＩの場合、ＭｖｄＬ０またはＭｖｄＣｐＬ０のうち０ではない値が存在しなければ、４１ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］のうち０ではない値が存在してもＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇしない。
また、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが０であるか、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ［ｘ０］［ｙ０］！＝ＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］のうち０ではない値が存在するのかを考慮する。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが０であるか、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ［ｘ０］［ｙ０］！＝ＰＲＥＤ＿ＢＩであれば、ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］のうち０ではない値が存在すれば、ＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが０であるか、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ［ｘ０］［ｙ０］！＝ＰＲＥＤ＿ＢＩの場合、ＭｖｄＬ１［ｘ０］［ｙ０］［０］、ＭｖｄＬ１［ｘ０］［ｙ０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［０］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［１］［１］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［０］、ＭｖｄＣｐＬ１［ｘ０］［ｙ０］［２］［１］のうち０ではない値が存在すれば、もしＭｖｄＬ０またはＭｖｄＣｐＬ０がいずれも０であってもＡＭＶＲに関連するｓｙｎｔａｘをｐａｒｓｉｎｇする。
図４２は、本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。
本開示の一実施例によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）はｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１（第１参照ピクチャリスト）に対するＭｖｄ（動きベクトル差分）値が０であることを示すシグナリングである。また、このシグナリングは現在ｂｌｏｃｋより上位レベルでシグナリングされる。よって、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値に基づいて多数のｂｌｏｃｋでｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ値が０になり得る。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が１であれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ値が０である。または、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ及びｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）に基づいてｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ値が０である。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ値が０である。この際、Ｍｖｄ値はＭｖｄＬ１［ｘ］［ｙ］［ｃｏｍｐＩｄｘ］である。また、この際、Ｍｖｄ値はｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを意味しない。つまり、この際、Ｍｖｄ値はＭｖｄＣｐ値を意味しない。
本開示の他の実施例によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇはｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０であることを示すシグナリングである。また、このシグナリングは現在ｂｌｏｃｋより上位レベルでシグナリングされる。よって、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値に基づいて多数のｂｌｏｃｋでｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０になり得る。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が１であれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０である。または、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ及ぼいｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃに基づいてｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０になる。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０である。この際、Ｍｖｄ値はＭｖｄＬ１［ｘ］［ｙ］［ｃｏｍｐＩｄｘ］である。また、ＭｖｄＣｐ値は、ＭｖｄＣｐＬ１［ｘ］［ｙ］［ｃｐＩｄｘ］［ｃｏｍｐＩｄｘ］である。
また、Ｍｖｄまたは、ＭｖｄＣｐ値が０であることは、該当するｍｖｄ＿ｃｏｄｉｎｇ ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅをｐａｒｓｉｎｇしないことを意味する。つまり、例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が１であれば、ＭｖｄＬ１またはＭｖｄＣｐＬ１に当たるｍｖｄ＿ｃｏｄｉｎｇ ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅをｐａｒｓｉｎｇしない。また、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ値が０であれば、ＭｖｄＬ１またはＭｖｄＣｐＬ１に当たるｍｖｄ＿ｃｏｄｉｎｇ ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅをｐａｒｓｉｎｇする。
本開示の一実施例によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭｖｄＣｐ値が０であれば、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇしない。ＭＶＰを示すシグナリングはｍｖｐ＿ｌ１＿ｆｌａｇを含む。また、上述したｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇの説明によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇシグナリングはＭｖｄとＭｖｄＣｐ両方に対して０であることを示すことを意味する。例えば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄまたはＭｖｄＣｐ値が０であることを示す条件を満足したら、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇしない。このような場合、ＭＶＰを示すシグナリングを予め設定された値にｉｎｆｅｒする。例えば、ＭＶＰを示すシグナリングが存在しなければ、その値を０にｉｎｆｅｒする。また、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭｖｄまたはＭｖｄＣｐ値が０であることを示す条件を満足しなかったら、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇする。しかし、このような実施例において、ＭｖｄまたはＭｖｄＣｐ値が０であればＭＶＰを選択する自由度がなくなる可能性があり、それによってコーディングの効率が下がる恐れがある。
より詳しくは、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄとＭｖｄＣｐ値が０であることを示す条件を満足し、ａｆｆｉｎｅ ＭＣを使用したら、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇしない。このような場合、ＭＶＰを示すシグナリングを予め設定された値にｉｎｆｅｒする。
図４２を参照すると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ値がＰＲＥＤ＿ＢＩであれば、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇしない。また、このような場合、ｍｖｐ＿ｌ１＿ｆｌａｇ値を０にｉｎｆｅｒする。または、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが０で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ値がＰＲＥＤ＿ＢＩでなければ、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇする。
本実施例において、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭＶＰを示すシグナリングのｐａｒｓｉｎｇ可否を決定することは、特定条件を満足する際に起こる。例えば、特定条件はｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０である条件を含む。例えば、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇは上述したｍｅｒｇｅ＿ｆｌａｇと同じ意味である。また、特定条件はＣｕＰｅｒｄＭｏｄｅに基づく条件を含む。より詳しくは、特定条件はＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではない条件を含む。また、特定条件はＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲである条件を含む。ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであれば、現在ｐｉｃｔｕｒｅをｒｅｆｅｒｅｎｃｅとする予測を使用する。また、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであれば、そのｂｌｏｃｋに当たるｂｌｏｃｋ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒが存在する。もしＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲであれば、現在ｐｉｃｔｕｒｅではないｐｉｃｔｕｒｅをｒｅｆｅｒｅｎｃｅとする予測を使用する。ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲであれば、そのｂｌｏｃｋに当たるｍｏｔｉｏｎ ｖｅｃｔｏｒが存在する。
よって、本開示の一実施例によると、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０で、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではなく、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇしない。また、ｍｖｐ＿ｌ１＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
より詳しくは、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０で、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではなく、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩで、ａｆｆｉｎｅ ＭＣを使用すれば、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇしない。また、ｍｖｐ＿ｌ１＿ｆｌａｇが存在しなければ、その値を０にｉｎｆｅｒする。
図４２を参照すると、ｓｙｍ＿ｍｖｄ＿ｆｌａｇをｓｙｍｍｅｔｒｉｃ ＭＶＤを示すシグナリングである。Ｓｙｍｍｅｔｒｉｃ ＭＶＤの場合、あるＭＶＤに基づいて他のＭＶＤを決定する。Ｓｙｍｍｅｔｒｉｃ ＭＶＤの場合、ｅｘｐｌｉｃｉｔ ｓｉｇｎａｌｉｎｇされたＭＶＤに基づいて他のＭＶＤを決定する。例えば、ｓｙｍｍｅｔｒｉｃ ＭＶＤの場合、一つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔに対するＭＶＤに基づいて他のｒｅｆｅｒｅｎｃｅ ｌｉｓｔに対するＭＶＤを決定する。例えば、ｓｙｍｍｅｔｒｉｃ ＭＶＤの場合、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ０に対するＭＶＤに基づいて他のｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭＶＤを決定する。あるＭＶＤに基づいて他のＭＶＤを決定する際、前記あるＭＶＤの符号を逆にした値を他のＭＶＤとして決定する。
図４３は、本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。
図４３の実施例は、図４２で説明した問題を解決するための実施例である。本開示の一実施例によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）に基づいてＭｖｄ（動きベクトル差分）またはＭｖｄＣｐ（コントロールポイント動きベクトル差分）値が０であれば、ＭＶＰ（動きベクトル予測子）を示すシグナリングをｐａｒｓｉｎｇする。ＭＶＰを示すシグナリングはｍｖｐ＿ｌ１＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル予測子インデックス）を含む。また、上述したｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇの説明によると、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇシグナリングはＭｖｄとＭｖｄＣｐ両方に対して０であることを示すことを意味する。例えば、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１（第１参照ピクチャリスト）に対するＭｖｄまたはＭｖｄＣｐ値が０であることを示す条件を満足したら、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇする。よって、ＭＶＰを示すシグナリングをｉｎｆｅｒしない。それによって、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭｖｄまたはＭｖｄＣｐ値が０であってもＭＶＰを選択する自由度を有する。それによってコーディングの効率が向上される。また、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭｖｄまたはＭｖｄＣｐ値が０であることを示す条件を満足しない場合も、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇする。
より詳しくは、ｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄまたはＭｖｄＣｐ値が０であることを示す条件を満足し、ａｆｆｉｎｅ ＭＣを使用したら、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇする。
図４３のライン４３０１を参照すると、現在ブロックに対して参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が獲得される。ライン４３０２を参照すると、参照ピクチャリストに関する情報（ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ）が第０参照ピクチャリスト（ｌｉｓｔ ０）のみを使用しないものではないことを示す場合、ライン４３０３において、ビットストリームから第１参照ピクチャリスト（ｌｉｓｔ １）の動きベクトル予測子インデックス（ｍｖｐ＿ｌ１＿ｆｌａｇ）がパージングされる。
ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）がビットストリームから獲得される。ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）は第１参照ピクチャリストに対してＭｖｄＬＸ（動きベクトル差分）及びＭｖｄＣｐＬＸ（複数のコントロールポイント動きベクトル差分）が０に設定されるのか否かを示す。シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）をビットストリームからパージングする。
ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）が１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）値がＰＲＥＤ＿ＢＩであれば、ｍｖｐ＿ｌ１＿ｆｌａｇ（動きベクトル予測子インデックス）をｐａｒｓｉｎｇする。ここで、ＰＲＥＤ＿ＢＩはＬｉｓｔ ０（第０参照ピクチャリスト）及びＬｉｓｔ １（第１参照ピクチャリスト）両方を使用することを示す。または、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）が０で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）値がＰＲＥＤ＿ＢＩでなければ、ｍｖｐ＿ｌ１＿ｆｌａｇ（動きベクトル予測子インデックス）をｐａｒｓｉｎｇする。つまり、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（動きベクトル差分ゼロフラッグ）が１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）が第０参照ピクチャリスト及び第１参照ピクチャリスト両方を使用することを示すのかに関わらず、ｍｖｐ＿ｌ１＿ｆｌａｇ（動きベクトル予測子インデックス）がｐａｒｓｉｎｇされる。
本実施例において、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストの動きベクトル差分ゼロフラッグ）に基づいてＭｖｄ、ＭｖｄＣｐを決定し、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇすることは、特定条件を満足した際に可能である。例えば、特定条件はｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０である条件を含む。例えば、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇは上述したｍｅｒｇｅ＿ｆｌａｇと同じ意味である。また、特定条件はＣｕＰｅｒｄＭｏｄｅに基づく条件を含む。より詳しくは、特定条件はＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではない条件を含む。また、特定条件はＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲである条件を含む。ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであれば、現在ｐｉｃｔｕｒｅをｒｅｆｅｒｅｎｃｅとする予測を使用する。また、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣであれば、そのｂｌｏｃｋに当たるｂｌｏｃｋ ｖｅｃｔｏｒまたはｍｏｔｉｏｎ ｖｅｃｔｏｒが存在する。もしＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲであれば、現在ｐｉｃｔｕｒｅではないｐｉｃｔｕｒｅをｒｅｆｅｒｅｎｃｅとする予測を使用する。ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲであれば、そのｂｌｏｃｋに当たるｍｏｔｉｏｎ ｖｅｃｔｏｒが存在する。
よって、本開示の一実施例によると、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０で、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではなく、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇが１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃがＰＲＥＤ＿ＢＩであれば、ｍｖｐ＿ｌ１＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル予測子インデックス）をｐａｒｓｉｎｇする。よって、ｍｖｐ＿ｌ１＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル予測子インデックス）が存在し、その値をｉｎｆｅｒしない。
また、より詳しくは、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが０で、ＣｕＰｅｒｄＭｏｄｅがＭＯＤＥ＿ＩＢＣではなく、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル差分ゼロフラッグ）が１で、ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃ（参照ピクチャリストに関する情報）がＰＲＥＤ＿ＢＩで、ａｆｆｉｎｅ ＭＣを使用したら、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇする。また、ｍｖｐ＿ｌ１＿ｆｌａｇ（第１参照ピクチャリストに対する動きベクトル予測子インデックス）が存在し、その値をｉｎｆｅｒしない。
図４３と図４０の実施例を共に実施してもよい。例えば、ＭｖｄまたはＭｖｄＣｐを初期化した後、ｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇする。この際、ＭｖｄまたはＭｖｄＣｐの初期かは、図４０で説明した初期化である。また、ｍｖｐ＿ｌ１＿ｆｌａｇのｐａｒｓｉｎｇは図４３の説明に従う。例えば、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてｒｅｆｅｒｅｎｃｅ ｌｉｓｔ Ｌ１に対するＭｖｄ、ＭｖｄＣｐ値が０ではない場合、ＭｏｔｉｏｎＭｏｄｅｌＩｄｃ値が１であれば、ｃｏｎｔｒｏｌ ｐｏｉｎｔ ｉｎｄｅｘ ２のＭｖｄＣｐＬ１値を初期化してｍｖｐ＿ｌ１＿ｆｌａｇをｐａｒｓｉｎｇする。
図４４は、本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘの構造を示す図である。
図４４の実施例は、ＭＶＰを選択する自由度をなくすためコーディングの効率を上げるための実施例である。また、図４４の実施例は、図４３で説明した実施例を他の方式で表現するものである。よって、図４３の実施例と重複する説明は省略する。
図４４の実施例において、ｍｖｄ＿ｌ１＿ｚｅｒｏ＿ｆｌａｇに基づいてＭｖｄまたはＭｖｄＣｐ値が０であることを示す場合、ＭＶＰを示すシグナリングをｐａｒｓｉｎｇする。ＭＶＰを示すシグナリングはｍｖｐ＿ｌ１＿ｆｌａｇを含む。
図４５は、本開示の一実施例によるｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに関連するｓｙｎｔａｘを示す図である。
本開示の一実施例によると、ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ方法はｓｋｉｐ ｍｐｄｅ、ｍｅｒｇｅ ｍｏｄｅ、ｉｎｔｅｒ ｍｏｄｅなどを含む。一実施例によると、ｓｋｉｐ ｍｏｄｅではｒｅｓｉｄｕａｌ ｓｉｇｎａｌが伝送されない。また、ｓｋｉｐ ｍｏｄｅではｍｅｒｇｅ ｍｏｄｅのようなＭＶの決定方法を使用してもよい。Ｓｋｉｐ ｍｏｄｅの使用可否はｓｋｉｐ ｆｌａｇによって決定される。図３３を参照すると、ｃｕ＿ｓｋｉｐ＿ｆｌａｇ値によってｓｋｉｐ ｍｏｄｅの使用可否が決定される。
一実施例によると、ｍｅｒｇｅ ｍｏｄｅではｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを使用しない。Ｍｏｔｉｏｎ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒを決定する。Ｍｅｒｇｅ ｍｏｄｅの使用可否はｍｅｒｇｅ ｆｌａｇによって決定される。図３３を参照すると、ｍｅｒｇｅ＿ｆｌａｇ値によってｍｅｒｇｅ ｍｏｄｅの使用可否が決定される。また、ｓｋｉｐ ｍｏｄｅを使用しなければ、ｍｅｒｇｅ ｍｏｄｅを使用することができる。
Ｓｋｉｐ ｍｏｄｅまたはｍｅｒｇｅ ｍｏｄｅにおいて、一つ以上のｃａｎｄｉｄａｔｅ ｌｉｓｔの種類のうちから選択的に使用する。例えば、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅまたはｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用する。または、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅはｓｉｇｎａｌ ｎｅｉｇｈｂｏｒｉｎｇ から選択、ｔｅｍｐｏｒａｌ ｃａｎｄｉｄａｔｅなどを含む。また、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅは現在ｂｌｏｃｋ（ＣＵ：ｃｏｄｉｎｇ ｕｎｉｔ）全体に対するｍｏｔｉｏｎ ｖｅｃｔｏｒを使用するｃａｎｄｉｄａｔｅを含む。つまり、現在ｂｌｏｃｋに属する各ｓｕｂｂｌｏｃｋのｍｏｔｉｏｎ ｖｅｃｔｏｒが同じｃａｎｄｉｄａｔｅを含む。また、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅはｓｕｂｂｌｏｃｋ－ｂａｓｅｄ ｔｅｍｐｏｒａｌ ＭＶ、ａｆｆｉｎｅ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅなどを含む。また、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅは現在ｂｌｏｃｋ（ＣＵ）のｓｕｂｂｌｏｃｋ別に異なるｍｏｔｉｏｎ ｖｅｃｔｏｒを使用可能なｃａｎｄｉｄａｔｅを含む。Ａｆｆｉｎｅ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅは、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒを決定する際にｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを使用せずに決定する方法で作った方法である。また、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅは現在ｂｌｏｃｋでｓｕｂｂｌｏｃｋ単位にｍｏｔｉｏｎ ｖｅｃｔｏｒを決定する方法を含む。例えば、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅは上述したｓｕｂｂｌｏｃｋ－ｂａｓｅｄ ｔｅｍｐｏｒａｌ ＭＶとａｆｆｉｎｅ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅ以外にもｐｌａｎａｒ ＭＶ、ｒｅｇｒｅｓｓｉｏｎ ｂａｓｅｄ ＭＶ、ＳＴＭＶＰなどを含む。
一実施例によると、ｉｎｔｅｒ ｍｏｄｅではｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを使用する。Ｍｏｔｉｏｎ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｒを決定し、ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒとｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒを決定する。Ｉｎｔｅｒ ｍｏｄｅの使用可否は他のｍｏｄｅの使用可否によって決定される。他の実施例として、ｉｎｔｅｒ ｍｏｄｅの使用可否はｆｌａｇによって決定される。図４５では他のｍｏｄｅであるｓｋｉｐ ｍｏｄｅとｍｅｒｇｅ ｍｏｄｅを使用しない場合、ｉｎｔｅｒ ｍｏｄｅを使用する例を示している。
Ｉｎｔｅｒ ｍｏｄｅはＡＭＶＰｍｏｄｅ、ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅなどを含む。Ｉｎｔｅｒ ｍｏｄｅはｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒとｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅに基づいてｍｏｔｉｏｎ ｖｅｃｔｏｒを決定するモードである。Ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅは、ａｆｆｉｎｅ ｍｏｔｉｏｎ ｐｒｅｄｉｃｔｉｏｎのｃｏｎｔｒｏｌ ｐｏｉｎｔ ｍｏｔｉｏｎ ｖｅｃｔｏｒを決定する際にｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅを使用する方法である。
図４５を参照すると、ｓｋｉｐ ｍｏｄｅまたはｍｅｒｇｅ ｍｏｄｅに決定された後、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用するのか、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用するのかを決定する。例えば、特定条件を満足したら、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅの使用可否を示すｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇをｐａｒｓｉｎｇする。前記特定条件はｂｌｏｃｋ ｓｉｚｅに関する条件である。例えば、ｗｉｄｔｈ、ｈｅｉｇｈｔ、ａｒｅａなどに関する条件であってもよく、これらを組み合わせて使用してもよい。図４５を参照すると、例えば、現在ｂｌｏｃｋ（ＣＵ）のｗｉｄｔｈ及びｈｅｉｇｈｔが特定値以上である際の条件である。ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇをｐａｒｓｉｎｇする場合、その値を０にｉｎｆｅｒする。もしｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇが１であればｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用し、０であればｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用する。Ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用すればｃａｎｄｉｄａｔｅ ｉｎｄｅｘであるｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿Ｉｄｘをｐａｒｓｉｎｇし、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅを使用すればｃａｎｄｉｄａｔｅ ｉｎｄｅｘであるｍｅｒｇｅ＿Ｉｄｘをｐａｒｓｉｎｇする。この際、ｃａｎｄｉｄａｔｅ ｌｉｓｔのｍａｘｉｍｕｍ個数が１であればｐａｒｓｉｎｇしない。ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿Ｉｄｘまたはｍｅｒｇｅ＿Ｉｄｘをｐａｒｓｉｎｇしなければ０にｉｎｆｅｒする。
図４５はｃｏｄｉｎｇ＿ｕｎｉｔ関数を示すが、ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎに関する内容な省略しており、図４５はｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎに決定された場合を示す。
図４６は、本開示の一実施例によるｔｒｉａｎｇｌｅ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅを示す図である。
本開示で言及するｔｒｉａｎｇｌｅ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅ（ＴＰＭ）は、ｔｒｉａｎｇｌｅ ｐａｒｔｉｔｉｏｎ ｍｏｄｅ、ｔｒｉａｎｇｌｅ ｐｒｅｄｉｃｔｉｏｎ、ｔｒｉａｎｇｌｅ ｂａｓｅｄ ｐｒｅｄｉｃｔｉｏｎ、ｔｒｉａｎｇｌｅ ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ、ｔｒｉａｎｇｌｕａｒ ｐｒｅｄｉｃｔｉｏｎ、ｔｒｉａｎｇｌｅ ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ、ｔｒｉａｎｇｌｕａｒ ｍｅｒｇｅ ｍｏｄｅ、ｔｒｉａｎｇｌｅ ｍｅｒｇｅ ｍｏｄｅなど多様な名称で称される。また、ＴＰＭはｇｅｏｍｅｔｒｉｃ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅ（ＧＰＭ）に含まれる。
図４６に示したように、ＴＰＭは矩形のブロックを２つの三角形に分ける方式である。しかし、ＧＰＭはブロックを多様な方式で２つのブロックに分割する。例えば、ＧＰＭは一つの矩形ブロックを図４６のように２つの三角形ブロックに分割する。また、ＧＰＭは一つの矩形ブロックを一つの五角形ブロックと一つの三角形ブロックに分割する。また、ＧＰＭは一つの矩形ブロックを２つの四角形ブロックに分割する。ここで、矩形は正方形を含む。以下では、説明の便宜上、ＧＰＭの簡単なバージョンであるＴＰＭを基準に説明するが、ＧＰＭを含むと解釈すべきである。
本開示の一実施例によると、予測する方法としてｕｎｉ－ｐｒｅｄｉｃｔｉｏｎが存在する。Ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎは一つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する予測方法である。前記ｒｅｆｅｒｅｎｃｅ ｌｉｓｔは多数存在するが、一実施例によると、Ｌ０、Ｌ１の２つが存在する。Ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎを使用する場合、一つのｂｌｏｃｋで一つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。また、ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎを使用する場合、一つのｐｉｘｅｌを予測するのに一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎを使用する。本開示において、ｂｌｏｃｋはＣＵ（ｃｏｄｉｎｇ ｕｎｉｔ）、ＰＵ（ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）を意味する。また、本開示において、ｂｌｏｃｋはＴＵ（ｔｒａｎｓｆｏｒｍ ｕｎｉｔ）を意味する。
本開示の他の実施例によると、予測する方法としてｂｉ－ｐｒｅｄｉｃｔｉｏｎが存在する。Ｂｉ－ｐｒｅｄｉｃｔｉｏｎは多数のｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する予測方法である。Ｂｉ－ｐｒｅｄｉｃｔｉｏｎは２つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する予測方法である。例えば、ｂｉ－ｐｒｅｄｉｃｔｉｏｎはＬ０とＬ１のｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。Ｂｉ－ｐｒｅｄｉｃｔｉｏｎを使用する場合、一つのｂｌｏｃｋで多数のｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。例えば、ｂｉ－ｐｒｅｄｉｃｔｉｏｎを使用する場合、一つのｂｌｏｃｋで２つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。また、ｂｉ－ｐｒｅｄｉｃｔｉｏｎを使用する場合、一つのｐｉｘｅｌを予測するのに多数のｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎを使用する。
前記ｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎは、ｍｏｔｉｏｎ ｖｅｃｔｏｒ、ｒｅｆｅｒｅｎｃｅ ｉｎｄｅｘ、ｐｒｅｄｉｃｔｉｏｎ ｌｉｓｔ ｕｔｉｌｉｚａｔｉｏｎ ｆｌａｇを含む。
前記ｒｅｆｅｒｅｎｃｅ ｌｉｓｔはｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ ｌｉｓｔである。
本開示において、ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎまたはｂｉ－ｐｒｅｄｉｃｔｉｏｎに当たるｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎを一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔと定義する。
本開示の一実施例によると、ＴＰＭを使用する場合、多数のｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを使用する。例えば、ＴＰＭを使用する場合、２つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを使用する。例えば、ＴＰＭを使用する場合、多くても２つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを使用する。また、ＴＰＭを使用するｂｌｏｃｋ内で２つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔが適用される方法は位置に基づく。例えば、ＴＰＭを使用するｂｌｏｃｋ内で予め設定された位置に対しては一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを使用し、他の予め設定された位置に対しては他の一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを使用する。更に、他の予め設定された位置に対しては、２つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔを共に使用する。例えば、他の予め設定された位置に対しては、一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔに基づく予測１と他の一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｓｅｔに基づく予測２に基づいて予測３を予測に使用する。例えば、予測３は予測１と予測２のｗｅｉｇｈｔｅｄ ｓｕｍである。
図４６を参照すると、Ｐａｒｔｉｔｉｏｎ １とＰａｒｔｉｔｉｏｎ ２は前記予め設定された位置と前記他の予め設定された位置を概略的に示す。ＴＰＭを使用する場合、図４６に示したように２つのｓｐｌｉｔ方法のうち一つを使用する。２つのｓｐｌｉｔ方法はｄｉａｇｏｎａｌ ｓｐｌｉｔ、ａｎｔｉ－ｄｉａｇｏｎａｌ ｓｐｌｉｔを含む。また、ｓｐｌｉｔによって２つのｔｒｉａｎｇｌｅ－ｓｈａｐｅｄ ｐａｒｔｉｔｉｏｎｓに分けられる。上述したように、ＴＰＭはＧＰＭに含まれる。ＧＰＭについては上述したため、重複する説明は省略する。
本開示の一実施例によると、ＴＰＭを使用する場合、各Ｐａｒｔｉｔｉｏｎに対してｕｎｉ－ｐｒｅｄｉｃｔｉｏｎのみを使用する。つまり、各Ｐａｒｔｉｔｉｏｎに対して一つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎを使用する。これはｍｅｍｏｒｙ ａｃｃｅｓｓ、ｃｏｍｐｕｔａｔｉｏｎａｌ ｃｏｍｐｌｅｘｉｔｙなどの複雑度を下げるためである。よって、ＣＵに対して２つおｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎのみを使用する。
また、各ｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎをｃａｎｄｉｄａｔｅ ｌｉｓｔから決定する。一実施例によると、ＴＰＭで使用するｃａｎｄｉｄａｔｅ ｌｉｓｔはｍｅｒｇｅ ｃａｎｄｉｄａｔｅ ｌｉｓｔに基づく。他の実施例として、ＴＰＭで使用するｃａｎｄｉｄａｔｅ ｌｉｓｔはＡＭＶＰ ｃａｎｄｉｄａｔｅ ｌｉｓｔに基づく。よって、ＴＰＭを使用するためにｃａｎｄｉｄａｔｅ ｉｎｄｅｘをシグナリングする。また、ＴＰＭを使用するｂｌｏｃｋに対してＴＰＭでＰａｒｔｉｔｉｏｎの個数だけ、または多くてもＰａｒｔｉｔｉｏｎの個数だけのｃａｎｄｉｄａｔｅ ｉｎｄｅｘをｅｎｃｏｄｉｎｇ、ｄｅｃｏｄｉｎｇ、ｐａｒｓｉｎｇする。
また、あるｂｌｏｃｋがＴＰＭによって多数のｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎに基づいてｐｒｅｄｉｃｔｉｏｎされても、ｔｒａｎｓｆｏｒｍ及びｑｕａｎｔｉｚａｔｉｏｎは前記あるｂｌｏｃｋ全体に対して行われる。
図４７は、本開示の一実施例によるｍｅｒｇｅ ｄａｔａ ｓｙｎｔａｘを示す図である。本開示の一実施例によると、ｍｅｒｇｅ ｄａｔａ ｓｙｎｔａｘを多様なｍｏｄｅに関するシグナリングを含む。前記多様なｍｏｄｅは、ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ、ＭＭＶＤ（ｍｅｒｇｅ ｗｉｔｈ ＭＶＤ）、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ、ＣＩＩＰ（ｃｏｍｂｉｎｅｄ ｉｎｔｒａ－ａｎｄ ｉｎｔｅｒ－ｐｒｅｄｉｃｔｉｏｎ）、ＴＰＭなどを含む。Ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅはＨＥＶにおいてｍｅｒｇｅ ｍｏｄｅと同じｍｏｄｅである。また、前記多様なｍｏｄｅをｂｌｏｃｋで使用するのかを示すシグナリングが存在する。また、このシグナリングはｓｙｎｔａｘ ｅｌｅｍｅｎｔとしてｐａｒｓｉｎｇされるか、ｉｍｐｌｉｃｉｔｌｙ ｓｉｇｎａｌｉｎｇされる。図４７を参照すると、ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ、ＭＭＶＤ、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ、ＣＩＩＰ、ＴＰＭを使用するのかを示すシグナリングは、それぞれｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇ、ｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇ（またはｍｍｖｄ＿ｆｌａｇ）、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ、ｃｉｉｐ＿ｆｌａｇ（またはｍｈ＿ｉｎｔｒａ＿ｆｌａｇ）、ＭｅｒｇｅＴｒｉａｎｇｌｅＦｌａｇ（またはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｆｌａｇ）である。
本開示の一実施例によると、ｍｅｒｇｅ ｍｏｄｅを使用する場合、前記多様なｍｏｄｅのうちからあるｍｏｄｅを除いた全てのｍｏｄｅを使用しないとシグナリングすれば、前記あるｍｏｄｅを使用すると決定する。また、ｍｅｒｇｅ ｍｏｄｅを使用する場合、前記多様なｍｏｄｅのうちからあるｍｏｄｅを除いた全てのｍｏｄｅのうち少なくとも一つは使用するとシグナリングすれば、前記あるｍｏｄｅを使用しないと決定する。また、ｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングが存在する。上位レベルはあるｂｌｏｃｋを含む単位である。上位レベルはｓｅｑｕｅｎｃｅ、ｐｉｃｔｕｒｅ、ｓｌｉｃｅ、ｔｉｌｅ ｇｒｏｕｐ、ｔｉｌｅ、ＣＴＵなどである。もしｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングが使用可能であることを示せば、そのｍｏｄｅを使用するのかを示す追加のシグナリングが存在し、そのｍｏｄｅを使用するか使用しない。もしｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングが使用不可能であることを示せば、そのｍｏｄｅを使用しない。例えば、ｍｅｒｇｅ ｍｏｄｅを使用する場合、ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ、ＭＭＶＤ、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ、ＣＩＩＰをいずれも使用しないとシグナリングすれば、ＴＰＭを使用すると決定する。また、ｍｅｒｇｅ ｍｏｄｅを使用する場合、ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ、ＭＭＶＤ、ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ、ＣＩＩＰのうち少なくとも一つを使用するとシグナリングすれば、ＴＰＭを使用しないと決定する。また、ｍｅｒｇｅ ｍｏｄｅを使用するのかを示すシグナリングが存在する。例えば、ｍｅｒｇｅ ｍｏｄｅを使用するの価を示すシグナリングはｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇまたはｍｅｒｇｅ＿ｆｌａｇである。もしｍｅｒｇｅ ｍｏｄｅを使用すれば、図４７のようなｍｅｒｇｅ ｄａｔａ ｓｙｎｔａｘをｐａｒｓｉｎｇする。
また、ＴＰＭを使用可能なｂｌｏｃｋ ｓｉｚｅが制限的である。例えば、ｗｉｄｔｈ、ｈｅｉｇｈｔがいずれも８以上であればＴＰＭを使用する。
もしＴＰＭを使用すれば、ＴＰＭに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔがｐａｒｓｉｎｇされる。ＴＰＭに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔはｓｐｌｉｔ方法を示すシグナリング、ｃａｎｄｉｄａｔｅ ｉｎｄｅｘを示すシグナリングを含む。Ｓｐｌｉｔ方法はｓｐｌｉｔ方向を意味する。Ｃａｎｄｉｄａｔｅ ｉｎｄｅｘを示すシグナリングはＴＰＭを使用するｂｌｏｃｋに対して多数（例えば、２つ）存在する。図４７を参照すると、ｓｐｌｉｔ方法を示すシグナリングはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｓｐｌｉｔ＿ｄｉｒである。また、ｃａｎｄｉｄａｔｅ ｉｎｄｅｘを示すシグナリングはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１である。
本開示において、ＴＰＭに対するｃａｎｄｉｄａｔｅ ｉｎｄｅｘをｍ、ｎとする。例えば、図４６のＰａｒｔｉｔｉｏｎ １とＰａｒｔｉｔｉｏｎ ２に対するｃａｎｄｉｄａｔｅ ｉｎｄｅｘがそれぞれｍ、ｎである。一実施例によると、ｍ、ｎは図４７で説明したｃａｎｄｉｄａｔｅ ｉｎｄｅｘを示すシグナリングに基づいて決定される。本開示の一実施例によると、ｍ、ｎのうち一つはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１のうち一つに基づいて決定され、ｍ、ｎのうち残りの一つはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１両方に基づいて決定される。
または、ｍ、ｎのうち一つはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１のうち一つに基づいて決定され、ｍ、ｎのうち残りの一つはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１のうち残りの一つに基づいて決定される。
より詳しくは、ｍはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０に基づいて決定され、ｎはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０（またはｍ）とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１に基づいて決定される。例えば、以下のようにｍ、ｎが決定される。
ｍ＝ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ０
ｎ＝ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１＋（ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿Ｉｄｘ１＞＝ｍ）？１：０
本開示の一実施例によると、ｍとｎは同じくではない。これはＴＰＭにおいて、２つのｃａｎｄｉｄａｔｅ ｉｎｄｅｘが同じであれば、つまり、２つのｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎが同じであればｐａｒｔｉｔｉｏｎｉｎｇの効果が得られないためである。よって、このようなシグナリング方法はｎをシグナリングする際、ｎ＞ｍであればシグナリングビット数を減らすためである。全体のｃａｎｄｉｄａｔｅのうち、ｍはｎではないため、シグナリングから除外することができる。
ＴＰＭで使用するｃａｎｄｉｄａｔｅ ｌｉｓｔをｍｅｒｇｅＣａｎＬｉｓｔとすると、ＴＰＭにおいて、ｍｅｒｇｅＣａｎＬｉｓｔ［ｍ］とｍｅｒｇｅＣａｎＬｉｓｔ［ｎ］をｍｏｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎとして使用する。
図４８は、本開示の一実施例による上位レベルシグナリングを示す図である。
本開示の一実施例によると、多数の上位レベルシグナリングが存在する。上位レベルシグナリングは上位レベル単位で伝送されるシグナリングである。上位レベル単位は一つ以上の下位レベル単位を含む。上位レベルシグナリングは一つ以上の下位レベル単位に適用されるシグナリングである。例えば、ｓｌｉｃｅまたはｓｅｑｕｅｎｃｅはＣＵ、ＰＵ、ＴＵなどに対して上位レベル単位である。逆に、ＣＵ、ＰＵ、またはＴＵはｓｌｉｃｅまたはｓｅｑｕｅｎｃｅに対して下位レベル単位である。
本開示の一実施例によると、上位レベルシグナリングはｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングを含む。例えば、上位レベルシグナリングはｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングを含む。例えば、上位レベルシグナリングはＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングを含む。前記ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングまたはＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングは、ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎが許容されればシグナリング、ｐａｒｓｉｎｇされる。Ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎが強要されるのかはｓｌｉｃｅ ｔｙｐｅによって決定される。Ｓｌｉｃｅ ｔｙｐｅはＩ、Ｐ、Ｂなどが存在する。例えば、ｓｌｉｃｅ ｔｙｐｅがＩであればｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎが許容されない。例えば、ｓｌｉｃｅ ｔｙｐｅがＩであればｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎまたはｉｎｔｒａ ｂｌｏｃｋ ｃｏｐｙ（ＩＢＣ）のみ使用する。また、ｓｌｉｃｅ ｔｙｐｅがＰまたはＢであればｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎが許容される。また、ｓｌｉｃｅ ｔｙｐｅがＰまたはＢであればｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ、ＩＢＣなどが許容される。また、ｓｌｉｃｅ ｔｙｐｅがＰであれなｐｉｘｅｌを予測するのに多くても一つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。また、ｓｌｉｃｅ ｔｙｐｅがＢであれなｐｉｘｅｌを予測するのに多数つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。例えば、ｓｌｉｃｅ ｔｙｐｅがＢであれなｐｉｘｅｌを予測するのに多ければ２つのｒｅｆｅｒｅｎｃｅ ｌｉｓｔを使用する。
本開示の一実施例によると、ｍａｘｉｍｕｍ ｎｕｍｂｅｒをシグナリングする際、基準値に基づいてシグナリングする。例えば、（基準値－ｍａｘｉｍｕｍ ｎｕｍｂｅｒ）をシグナリングする。よって、ｄｅｃｏｄｅｒでｐａｒｓｉｎｇした値と基準値に基づいてｍａｘｉｍｕｍ ｎｕｍｂｅｒをｄｅｒｉｖｅする。例えば、（基本値－ｐａｒｓｉｎｇした値）をｍａｘｉｍｕｍ ｎｕｍｂｅｒとして決定する。
一実施例によると、前記ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値は６である。
一実施例によると、前記ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値は、前記ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒである。
図４８を参照すると、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングはｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄである。ここで、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅはマージモードベクトル予測に対する候補を意味する。以下、説明の便宜上、ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄを第１情報と称する。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。ｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ（第１情報）はシーケンス単位でシグナリングされる。デコーダはビットストリームからｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ（第１情報）をパージングする。
また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングは、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄである。図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）をパージングする。ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）はパーティショニングされたブロックのためのマージモード候補の最大個数に関する情報である。
また、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒはＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）であり、この値はｓｉｘ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ（第１情報）に基づく。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒはＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄであり、この値はｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄに基づく。ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）はマージモード使用されるが、ブロックが動き補償のためにパーティショニングされるか、またはパーティショニングされない場合に使用される。以上ではＴＰＭを基準に説明したが、ＧＰＭについても同じ方式で説明される。
本開示の一実施例によると、ＴＰＭ ｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングが存在する。図４８を参照すると、ＴＰＭ ｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングは、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（だ２情報）である。ＴＰＭ ｍｏｄｅを使用可能であるのかを示す情報は、インター予測のために図４６のようにブロックのパーティショニン可否を示す情報と同じである。ＧＰＭはＴＰＭを含むため、ブロックのパーティショニング可否を示す情報はＧＰＭモードの使用可否を示す情報と同じである。インター予測のためということは、動き補償のためということを示す。つまり、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）はインター予測のためのブロックのパーティショニング可否を示す情報である。ブロックのパーティショニング可否を示す第情報が１であれば、ＴＰＭまたはＧＰＭを使用可能であることを示す。また、第２情報が０であれば、ＴＰＭまたはＧＰＭが使用不可能であることを示す。しかし、これに限らず、第２情報が０であれば、ＴＰＭまたはＧＰＭを使用可能であることを示す。また、第２情報が１であれば、ＴＰＭまたはＧＰＭが使用不可能であることを示す。
図２及び図７を参照すると、シグナリングはビットストリームを介してエンコーダからデコーダに伝送される信号を意味する。デコーダはビットストリームからｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）をパージングする。
本開示の一実施例によると、ＴＰＭのｐａｒｔｉｔｉｏｎｉｎｇ個数以上のＴＰＭで使用されるｃａｎｄｉｄａｔｅが存在する場合にのみＴＰＭを使用する。例えば、ＴＰＭが２つにｐａｒｔｉｔｉｏｎｉｎｇされる際、ＴＰＭで使用されるｃａｎｄｉｄａｔｅが２つ以上存在する場合にのみＴＰＭを使用する。一実施例によると、ＴＰＭで使用するｃａｎｄｉｄａｔｅはｍｅｒｇｅ ｃａｎｄｉｄａｔｅに基づく。よって、本開示の一実施例によると、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが２以上であればＴＰＭを使用する。よって、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが２以上であればＴＰＭに関するシグナリングをｐａｒｓｉｎｇする。ＴＰＭに関するシグナリングは、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングである。
図４８を参照すると、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２以上であれば、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄをｐａｒｓｉｎｇする。また、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０であるか、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２より小さければ、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄをｐａｒｓｉｎｇしない。
図４９は、本開示の一実施例によるＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示す図である。
図４９を参照すると、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒはＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄである。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングは、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄである。また、図４８で説明した内容は省略する。
本開示の一実施例によると、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒは「ＴＰＭのｐａｒｔｉｔｉｏｎ個数」から「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」の範囲（ｉｎｃｕｌｓｉｖｅ）に存在する。よって、ＴＰＭのｐａｒｔｉｔｉｏｎ個数が２で、基準値がｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒであれば、図４９に示したように、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄは２からＭａｘＮｕｍＭｅｒｇｅＣａｎｄの範囲（ｉｎｃｕｌｓｉｖｅ）に存在する。
本開示の一実施例によると、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在しなければ、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｉｎｆｅｒするか、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すｉｎｆｅｒする。例えば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在しなければ、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを０にｉｎｆｅｒする。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在しなければ、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングを基準値にｉｎｆｅｒする。
また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在しなければ、ＴＰＭを使用しない。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒがＴＰＭのｐａｒｔｉｔｉｏｎ個数より小さければ、ＴＰＭを使用しない。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが０であれば、ＴＰＭを使用しない。
しかし、図４８乃至図４９の実施例によると、ＴＰＭのｐａｒｔｉｔｉｏｎ個数と「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」が同じであれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒとして可能な値は１つのみである。しかし、図４８乃至図４９の実施例によると、そのような場合でもＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングがｐａｒｓｉｎｇされるが、これは不必要である。もしＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２であれば、図４９を参照すると、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄとして可能な値は２のみである。しかし、図４８を参照すると、そのような場合でもｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄをｐａｒｓｉｎｇする。
図４９を参照すると、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄは（ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ）に決定される。
図５０は、本開示の一実施例によるＴＰＭに関する上位レベルシグナリングを示す図である。本開示の一実施例によると、ＴＰＭのｐａｒｔｉｔｉｏｎ個数と「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」が同じであれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｐａｒｓｉｎｇしない。また、上述した一実施例によると、ＴＰＭのｐａｒｔｉｔｉｏｎ個数は２である。また、「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」は、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒである。よって、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが２であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｐａｒｓｉｎｇしない。
または、「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」がＴＰＭのｐａｒｔｉｔｉｏｎ個数以下であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｐａｒｓｉｎｇしない。よって、ｍｅｒｇｅ ｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが２以下であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｐａｒｓｉｎｇしない。
図５０のライン５００１を参照すると、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２であるか、またはＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２以下であれば、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）をｐａｒｓｉｎｇしない。また、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２より大きければ、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）をｐａｒｓｉｎｇする。また、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が０であれば、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）をｐａｒｓｉｎｇしない。よって、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が０であるか、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２以下であれば、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）をｐａｒｓｉｎｇしない。
図５１は、本開示の一実施例によるＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示す図である。図５１の実施例は、図５０の実施例の場合に共に実施されてもよい。また、上述したものは本図面において説明を省略している可能性がある。
本開示の一実施例によると、「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」がＴＰＭのｐａｒｔｉｔｉｏｎ個数であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒをＴＰＭのｐａｒｔｉｔｉｏｎ個数にｉｎｆｅｒ、設定する。また、ｉｎｆｅｒ、設定することは、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在しない場合である。図５０の実施例によると、「ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングにおける基準値」がＴＰＭのｐａｒｔｉｔｉｏｎ個数であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｐａｒｓｉｎｇせず、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在すれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒの値を個数にｉｎｆｅｒする。まあ、更なる条件を満足した場合にこれを行う。更なる条件は、ＴＰＭ ｍｏｄｅを使用可能であるのかを示す上位レベルシグナリングが１である条件である。
また、本実施例において、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒをｉｎｆｅｒ、設定することを説明したが、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒをｉｎｆｅｒ、設定する代わりに説明したＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒ値が導出されるように、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングをｉｎｆｅｒ、設定することもできる。
図５０を参照すると、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１を示し、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２より大きければ、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）が受信される。この際、図５１のライン５１０１を参照すると、明確にシグナリングされたｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）を利用してＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）が獲得される。要するに、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１を示し、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が３より大きいか同じであれば、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）から第３情報（ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ）を差し引いて、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）が獲得される。
図５１のライン５１０２を参照すると、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２であれば、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）を２に設定する。より詳しくは、上述したように、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２より大きければｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）が受信されるため、ライン５１０２のように、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２であれば、ｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）が受信されない。この際、 ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ （パーティショニングされたブロックのためのマージモード候補の最大個数）はｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）なしに決定される。
また、図５１のライン５１０３を参照すると、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が０であるか、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２でなければ、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）を０にｉｎｆｅｒ、設定する。この際、ライン５１０１において、上述したように、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１を示し、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が３より大きいか同じであればｍａｘ＿ｎｕｍ＿ｍｅｒｇｅ＿ｃａｎｄ＿ｍｉｎｕｓ＿ｍａｘ＿ｎｕｍ＿ｔｒｉａｎｇｌｅ＿ｃａｎｄ（第３情報）がシグナリングされるため、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを０にｉｎｆｅｒ、設定する場合は、前記第２情報が０であるか、前記マージ候補の最大個数が１である場合である。要するに、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が０であるか、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が１であれば、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）は０に設定される。
ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）とＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）は互いに異なる用途に使用される。例えば、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）はブロックが動き補償のためにパーティショニングされるかパーティショニングされない場合に使用される。しかし、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）はブロックがパーティショニングされている場合にのみ使用される情報である。マージモードであるパーティショニングされたブロックに対する候補の個数は、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ（パーティショニングされたブロックのためのマージモード候補の最大個数）を超えない。
また、他の実施例を使用することもできる。図５１の実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２でなければ２より大きい場合も含むが、その場合、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを０にｉｎｆｅｒ、設定するということの意味が不明になる恐れがあるが、そのような場合はＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在してｉｎｆｅｒしないようになるため、動作に異常がない。しかし、この実施れでは意味を活かしてｉｎｆｅｒする。
もしｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（第２情報）が１で、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ（マージ候補の最大個数）が２以上であれば、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを２（またはＭａｘＮｕｍＭｅｒｇｅＣａｎｄが）にｉｎｆｅｒ、設定する。そうでない場合（つまり、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０であるかＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２より小さい場合）、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを０にｉｎｆｅｒ、設定する。
もしｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１でＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２であれば、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを２にｉｎｆｅｒ、設定する。そうではなく、もし（ｏｔｈｅｒｗｉｓｅ ｉｆ）ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１０であれば、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄを０にｉｎｆｅｒ、設定する。
よって、前記実施例において、図５０の実施れによると、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが０ ｏｒ １ ｏｒ ２であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを示すシグナリングが存在せず、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが０ ｏｒ １であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを０にｉｎｆｅｒ、設定する。ＭａｘＮｕｍＭｅｒｇｅＣａｎｄが２であれば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒを２にｉｎｆｅｒ、設定する。
図５２は、本開示の一実施例によるＴＰＭに関連するｓｙｎｔａｘ ｅｌｅｍｅｎｔを示す図である。
上述したように、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが存在し、ＴＰＭのｐａｒｔｉｔｉｏｎ個数が予め設定されている。また、ＴＰＭで使用するｃａｎｄｉｄａｔｅ ｉｎｄｅｘは互いに異なり得る。
本開示の一実施例によると、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒがＴＰＭのｐａｒｔｉｔｉｏｎ個数と同じであれば、そうではない場合とは異なるシグナリングを行う。例えば、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒがＴＰＭのｐａｒｔｉｔｉｏｎ個数と同じであれば、そうではない場合とは異なるｃａｎｄｉｄａｔｅ ｉｎｄｅｘシグナリングを行う。それによってより少ないビットでシグナリングすることができる。また、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒがＴＰＭのｐａｒｔｉｔｉｏｎ個数以下であれば、そうではない場合とは異なるシグナリングを行う（このうちＴＰＭのｐａｒｔｉｔｉｏｎ個数より小さい場合は、ＴＰＭを使用できない場合である）。
ＴＰＭのｐａｒｔｉｔｉｏｎが２であれば、２つのｃａｎｄｉｄａｔｅ ｉｎｄｅｘをシグナリングする。もしＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒが２であれば、ｃａｎｄｉｄａｔｅ ｉｎｄｅｘの組み合わせは２つのみである。２つの組み合わせはｍ、ｎがそれぞれ０、１であるものと１、０であるものである。よって、１－ｂｉｔのシグナリングのみで２つのｃａｎｄｉｄａｔｅ ｉｎｄｅｘをシグナリングする。
図５２を参照すると、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２であれば、そうではない場合（そうではなくＴＰＭを使用する場合はＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２より大きい場合）とは異なるｃａｎｄｉｄａｔｅ ｉｎｄｅｘシグナリングを行う。また、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２以下であれば、そうではない場合（そうではなくＴＰＭを使用する場合はＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２より大きい場合）とは異なるｃａｎｄｉｄａｔｅ ｉｎｄｅｘシグナリングを行う。他のｃａｎｄｉｄａｔｅ ｉｎｄｅｘシグナリングは、図５２を参照すると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒ ｐａｒｓｉｎｇである。他のｃａｎｄｉｄａｔｅ ｉｎｄｅｘシグナリングは、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０またはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をｐａｒｓｉｎｇしないシグナリング方法である。それについては図５３で更に説明する。
図５３は、本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。
本開示の一実施例によると、図５２で説明した他のｉｎｄｅｘシグナリングを使用すれば、ｃａｎｄｉｄａｔｅ ｉｎｄｅｘをｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒに基づいて決定する。また、他のｉｎｄｅｘシグナリングを使用すれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０またはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１が存在しない可能性がる。
本開示の一実施例によると、ＴＰＭで使用されるｃａｎｄｉｄａｔｅのｍａｘｉｍｕｍ ｎｕｍｂｅｒがＴＰＭのｐａｒｔｉｔｉｏｎ個数と同じであれば、ＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘをｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒに基づいて決定する。また、これはＴＰＭを使用するｂｌｏｃｋの場合である。
より詳しくは、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２であれば（または、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２で、ＭｅｒｇｅＴｒｉａｎｇｌｅＦｌａｇが１であれば）、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒに基づいてＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘを決定する。この場合、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒが０であれば、ＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓであるｍ、ｎをそれぞれ０、１に設定し、もしｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒが１であれば、ＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓであるｍ、ｎをそれぞれ１、０に設定する。または、ｍ、ｎが説明したようにｐａｒｓｉｎｇされる値（ｓｙｎｔａｘ ｅｌｅｍｅｎｔ）であるｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０またはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をｉｎｆｅｒ、設定する。
図４７で説明したｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１に基づいてｍ、ｎを設定する方法を参照し、図５３を参照すると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が存在しなければ、もしＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２であれば（または、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２で、ＭｅｒｇｅＴｒｉａｎｇｌｅＦｌａｇが１であれば）、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒが１であればｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０値を１にｉｎｆｅｒする。また、そうでない場合、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０値を０にｉｎｆｅｒする。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１が存在しなければ、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１を０にｉｎｆｅｒする。よって、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒが０である際、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１がそれぞれ０、０で、それによってｍ、ｎはそれぞれ０、１になる。また、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄが２であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ＿ｉｎｄｉｃａｔｏｒが１である際、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１がそれぞれ１、０で、それによってｍ、ｎはそれぞれ１、０になる。
図５４は、本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。
図４７ではＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓを決定する方法を説明したが、図５４における実施例では他の決定方法、シグナリング方法を説明する。上述したものと重複する説明は省略する。また、ｍ、ｎは図４７で説明したようにｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓを示す。
本開示の一実施例によると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のうち、予め設定されたｓｙｎｔａｘ ｅｌｅｍｅｎｔにｍ、ｎのうち小さい値をシグナリングする。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のうち残りの一つにはｍとｎの差に基づく値をシグナリングする。また、ｍとｎの大小関係を示す値をシグナリングする。
例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０はｍ、ｎのうち小さい値である。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１は｜ｍ、ｎ｜に基づく値であるｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１は（｜ｍ、ｎ｜－１）である。これは、ｍとｎが同じではないためである。また、ｍとｎの大小関係を示す値が図５４のｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒである。
この関係を利用して、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒに基づいてｍ、ｎを決定する。図５４を参照すると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒ値に基づいて他の動作を行う。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒが０であれば、ｎがｍより大きい。この場合、ｍはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０である。また、ｎは（ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１＋ｍ＋１）である。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒが１であれば、ｍがｎより大きい。この場合、ｎはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０である。また、ｍは（ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１＋ｎ＋１）である。
図５４の方法は、図４７の方法に比べｍ、ｎのうち小さい値が０ではない場合（または大きい場合）にシグナリングオーバーヘッドを減らすという長所がある。例えば、ｍ、ｎがそれぞれ３、４であれば、図４７の方法ではｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ３、３にシグナリングすべきである。しかし、図５４の方法ではｍ、ｎがそれぞれ３、４であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ３、０にシグナリングすべきである（これに加えて大小関係を示すシグナリングが必要である）。よって、ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｓｉｇｎａｌｉｎｇを使う際、ｅｎｃｏｄｉｎｇ、ｄｅｃｏｄｉｎｇする値のサイズが減るため、小さいビットを使用することができる。
図５５は、本開示の一実施例によるＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｅｘのシグナリングを示す図である。
図４７ではＴＰＭ ｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓを決定する方法を説明したが、図55における実施例では他の決定方法、シグナリング方法を説明する。上述したものと重複する説明は省略する。また、ｍ、ｎは図４７で説明したようにｃａｎｄｉｄａｔｅ ｉｎｄｉｃｅｓを示す。
本開示の一実施例によると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のうち、予め設定されたｓｙｎｔａｘ ｅｌｅｍｅｎｔにｍ、ｎのうち大きい値をシグナリングする。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のうち残りの一つにはｍとｎのうち小さい値に基づく値をシグナリングする。また、ｍとｎの大小関係を示す値をシグナリングする。
例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０はｍ、ｎのうち大きい値に基づく。一実施例によると、ｍ、ｎが同じではないため、ｍ、ｎのうち大きい値は１以上である。よって、ｍ、ｎのうち大きい値が除外されることを考慮して、より小さいビットでシグナリングする。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０は（（ｍ、ｎのうち大きい値）－１）である。この際、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０のｍａｘｉｍｕｍ値は（ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ－１－１）である（０から始まる値であるため－１、大きい値が０であるものを除外できるため－１）。Ｍａｘｉｍｕｍ値はｂｉｎａｒｉｚａｔｉｏｎで使用され、ｍａｘｉｍｕｍ値が減るとより小さいビットを使用する場合があり得る。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１はｍ、ｎのうち小さい値である。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のｍａｘｉｍｕｍ値はｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０である。よって、ｍａｘｉｍｕｍ値をＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄに設定するより更に小さいビットを使用する場合があり得る。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が０であれば、つまり、ｍ、ｎのうち大きい値が１であれば、ｍ、ｎのうち小さい値が０であるため、追加のシグナリングが存在しない。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が０であれば、つまり、ｍ、ｎのうち大きい値が１であれば、ｍ、ｎのうち小さい値を０に決定する。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が０であれば、つまり、ｍ、ｎのうち大きい値が１であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１を０にｉｎｆｅｒ、決定する。図２２を参照すると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０に基づいてｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のｐａｒｓｉｎｇ可否を決定する。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が０より大きければｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をｐａｒｓｉｎｇし、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０が０であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をｐａｒｓｉｎｇしない。
また、ｍとｎの大小関係を示す値が図５５のｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒである。
この関係を利用して、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０とｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒに基づいてｍ、ｎを決定する。図５５を参照すると、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒ値に基づいて他の動作を行う。例えば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒが０であれば、ｍがｎより大きい。この場合、ｍは（ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０＋１）である。また、ｎはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１である。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒが１であれば、ｎがｍより大きい。この場合、ｎは（ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０＋１）である。また、ｍはｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１である。また、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１が存在しなければ、その値を０にｉｎｆｅｒする。
図５５の方法は、図４７の方法に比べｍ、ｎ値によってシグナリングオーバーヘッドを減らすという長所がある。例えば、ｍ、ｎがそれぞれ１、０であれば、図４７の方法ではｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ１、０にシグナリングすべきである。しかし、図５５の方法ではｍ、ｎがそれぞれ１、０であれば、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ０、０にシグナリングすべきであるが、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１はｅｎｃｏｄｉｎｇ、ｐａｒｓｉｎｇせずにｉｎｆｅｒする（これに加えて大小関係を示すシグナリングが必要である）。よって、ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｓｉｇｎａｌｉｎｇを使う際、ｅｎｃｏｄｉｎｇ、ｄｅｃｏｄｉｎｇする値のサイズが減るため、小さいビットを使用することができる。または、ｍ、ｎがそれぞれ２、１であれば、図４７の方法ではｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ２、１に、図５５の方法ではｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１をそれぞれ１、１にシグナリングすべきである。しかし、この際、図５５の方法では、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のｍａｘｉｍｕｍ値が（３－１－１）＝１であるため、ｍａｘｉｍｕｍ値が大きい際より１小さいビットでシグナリングされる。例えば、図５５の方法はｍ、ｎ間の差が小さい際、例えば、差が１である際に長所を有する方法である。
また、図５５のｓｙｎｔａｘ構造において、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のｐａｒｓｉｎｇ可否を決定するためにｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ０を参照すると説明したが、ｍ、ｎのうち大きい値に基づいて決定してもよい。つまり、ｍ、ｎのうち大きい値が１以上の場合とそうでない場合に区分する。但し、この場合、ｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｂｉｇｇｅｒのｐａｒｓｉｎｇがｍｅｒｇｅ＿ｔｒｉａｎｇｌｅ＿ｉｄｘ１のｐａｒｓｉｎｇ可否を決定するより先に起こるべきである。
これまで構成を具体的な実施例を介して説明したが、当業者であれば本開示の趣旨及び範囲を逸脱せずに修正、変更し得るはずである。よって、本開示の詳細な説明及び実施例から本開示の属する技術分野に属する人が容易に類推し得るものは、本開示の権利範囲に属すると解釈される。
１００ エンコーディング装置
１１０ 交換部
１２０ 逆量子化部
１５０ 予測部
２００ デコーディング装置
２１０ エントロピーデコーディング部
２３０ フィルタリング部

Claims (20)

  1. ビデオ信号を処理する方法であって、
    ビットストリームから、適応的な動きベクトル差分解像度が使用可能であるか否かを示す第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記ビットストリームから、アフィン動き補償が使用可能であるか否かを示す第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であること示す場合、前記ビットストリームから、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であるか否かを示す第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    を含むことを特徴とするビデオ信号を処理する方法。
  2. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、及び前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔのうち少なくとも一つは、シーケンス（ｓｅｑｕｅｎｃｅ）単位でシグナリングされることを特徴とする請求項１に記載のビデオ信号を処理する方法。
  3. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能でないことを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であることを示す場合、前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔの値は、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能でないことを示す値であると推定（ｉｎｆｅｒ）されることを特徴とする請求項１に記載のビデオ信号を処理する方法。
  4. 前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能でないことを示す場合、前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔの値は、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能でないことを示す値であると推定（ｉｎｆｅｒｅ）されることを特徴とする請求項１に記載のビデオ信号を処理する方法。
  5. 前記ビットストリームから、前記アフィン動き補償が現在ブロックに対して使用されているか否かを示す第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、前記第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記現在ブロックに対して前記アフィン動き補償が使用されていないことを示し、前記現在ブロックに対する複数の動きベクトル差分のうち少なくとも一つが０でなければ、前記ビットストリームから、動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）を示す第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔに基づいて前記現在ブロックに対する前記複数の動きベクトル差分を修正するステップと、を更に含むことを特徴とする請求項１に記載のビデオ信号を処理する方法。
  6. 前記ビットストリームから、前記アフィン動き補償が現在ブロックに対して使用されているか否かを示す第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であることを示し、前記第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が前記現在ブロックに対して使用されていることを示し、前記現在ブロックに対する複数のコントロールポイント動きベクトル差分のうち少なくとも一つが０でなければ、前記ビットストリームから、動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）を示す第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔに基づいて前記現在ブロックに対する前記複数のコントロールポイント動きベクトル差分を修正するステップと、を更に含むことを特徴とする請求項１に記載のビデオ信号を処理する方法。
  7. 前記ビットストリームから、現在ブロックに対する参照ピクチャリストに関する第６のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第６のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、第０参照ピクチャリスト以外の参照ピクチャリストが利用可能であることを示す場合、前記ビットストリームから、第１参照ピクチャリストの動きベクトル予測子インデックスを示す第７のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、を更に含むことを特徴とする請求項１に記載のビデオ信号を処理する方法。
  8. 前記ビットストリームから、前記第１参照ピクチャリストに対して動きベクトル差分及び複数のコントロールポイント動きベクトル差分が０に設定されるのか否かを示す第８のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップを更に含み、
    前記第７のｓｙｎｔａｘ ｅｌｅｍｅｎｔは、前記第８のｓｙｎｔａｘ ｅｌｅｍｅｎｔに関わらずにパージングされることを特徴とする請求項７に記載のビデオ信号を処理する方法。
  9. ビデオ信号を処理するデコーディング装置であって、プロセッサ及びメモリを含み、
    前記プロセッサが、
    ビットストリームから、適応的な動きベクトル差分解像度が使用可能であるか否かを示す第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記ビットストリームから、アフィン動き補償が使用可能であるか否かを示す第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であることを示す場合、前記ビットストリームから、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であるか否かを示す第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするように構成されることを特徴とするビデオ信号を処理するデコーディング装置。
  10. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、および前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔのうち少なくとも一つは、シーケンス（ｓｅｑｕｅｎｃｅ）単位でシグナリングされることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  11. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能でないことを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であることを示す場合、前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔの値は、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能でないことを示す値であると推定（ｉｎｆｅｒ）されることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  12. 前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能でないことを示す場合、前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔの値は、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能でないことを示す値であると推定（ｉｎｆｅｒ）されることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  13. 前記プロセッサは前記メモリに保存されている命令語に基づいて、
    前記ビットストリームから、前記アフィン動き補償が現在ブロックに対して使用されているか否かを示す第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、前記第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記現在ブロックに対して前記アフィン動き補償が使用されていないことを示し、前記現在ブロックに対する複数の動きベクトル差分のうち少なくとも一つが０でなければ、前記ビットストリームから、動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）を示す第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔに基づいて前記現在ブロックに対する前記複数の動きベクトル差分を修正するように構成されることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  14. 前記プロセッサが、
    前記ビットストリームから、前記アフィン動き補償が現在ブロックに対して使用されているか否かを示す第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であることを示し、前記第４のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記現在ブロックに対して前記アフィン動き補償が使用されることを示し、前記現在ブロックに対する複数のコントロールポイント動きベクトル差分のうち少なくとも一つが０でなければ、前記ビットストリームから、動きベクトル差分の解像度（ｒｅｓｏｌｕｔｉｏｎ）を示す第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第５のｓｙｎｔａｘ ｅｌｅｍｅｎｔに基づいて前記現在ブロックに対する前記複数のコントロールポイント動きベクトル差分を修正するように構成されることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  15. 前記プロセッサが、
    前記ビットストリームから、現在ブロックに対する参照ピクチャリストに関する第６のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第６のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、第０参照ピクチャリスト以外の参照ピクチャリストが利用可能であることを示す場合、前記ビットストリームから、第１参照ピクチャリストの動きベクトル予測子インデックスを示す第７のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするように構成されることを特徴とする請求項９に記載のビデオ信号を処理するデコーディング装置。
  16. 前記プロセッサが、
    前記ビットストリームから、前記第１参照ピクチャリストに対して動きベクトル差分及び複数のコントロールポイント動きベクトル差分が０に設定されるのか否かを示す第８のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングし、
    前記第７のｓｙｎｔａｘ ｅｌｅｍｅｎｔは、前記第８のｓｙｎｔａｘ ｅｌｅｍｅｎｔに関わらずにパージングされるように構成されることを特徴とする請求項１５に記載のビデオ信号を処理するデコーディング装置。
  17. ビデオ信号を処理するためのエンコーディング装置であって、プロセッサを含み、
    前記プロセッサが、
    デコーディング方法を使用するデコーダによってデコーディングされるビットストリームを獲得し、
    前記デコーディング方法が、
    前記ビットストリームから、適応的な動きベクトル差分解像度が使用可能であるか否かを示す第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記ビットストリームから、アフィン動き補償が使用可能であるか否かを示す第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であること示す場合、前記ビットストリームから、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であるか否かを示す第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔをパージングするステップと、
    を含むことを特徴とするビデオ信号を処理するエンコーディング装置。
  18. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、及び前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔのうち一つは、シーケンス（ｓｅｑｕｅｎｃｅ）単位でシグナリングされることを特徴とする請求項１７に記載のビデオ信号を処理するエンコーディング装置。
  19. 前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能でないことを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であることを示す場合、前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔの値は、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能でないことを示す値であると推定（ｉｎｆｅｒ）されることを特徴とする請求項１７に記載のビデオ信号を処理するエンコーディング装置。
  20. ビットストリームを生成する方法であって、
    適応的な動きベクトル差分解像度が使用可能であるか否かを示す第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔを生成するステップと、
    アフィン動き補償が使用可能であるか否かを示す第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔを生成するステップと、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記適応的な動きベクトル差分解像度が使用可能であることを示し、かつ前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔが、前記アフィン動き補償が使用可能であること示す場合、前記アフィン動き補償に対して前記適応的な動きベクトル差分解像度が使用可能であるか否かを示す第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔを生成するステップと、
    前記第１のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、前記第２のｓｙｎｔａｘ ｅｌｅｍｅｎｔ、及び前記第３のｓｙｎｔａｘ ｅｌｅｍｅｎｔを含むビットストリームを生成するステップと、
    を含むことを特徴とするビットストリームを生成する方法。
JP2021564599A 2019-04-30 2020-05-04 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置 Active JP7335358B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023133080A JP2023164843A (ja) 2019-04-30 2023-08-17 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
KR20190050960 2019-04-30
KR10-2019-0050960 2019-04-30
KR20190057185 2019-05-15
KR10-2019-0057185 2019-05-15
KR10-2019-0057650 2019-05-17
KR20190057650 2019-05-17
PCT/KR2020/005830 WO2020222588A1 (ko) 2019-04-30 2020-05-04 적응적 모션 벡터 해상도를 이용한 비디오 신호 처리 방법 및 장치

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023133080A Division JP2023164843A (ja) 2019-04-30 2023-08-17 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置

Publications (2)

Publication Number Publication Date
JP2022531264A JP2022531264A (ja) 2022-07-06
JP7335358B2 true JP7335358B2 (ja) 2023-08-29

Family

ID=73028924

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021564599A Active JP7335358B2 (ja) 2019-04-30 2020-05-04 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置
JP2023133080A Pending JP2023164843A (ja) 2019-04-30 2023-08-17 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023133080A Pending JP2023164843A (ja) 2019-04-30 2023-08-17 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置

Country Status (5)

Country Link
EP (1) EP3965420A4 (ja)
JP (2) JP7335358B2 (ja)
KR (1) KR20210149759A (ja)
CN (1) CN113906750A (ja)
WO (1) WO2020222588A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3954119A4 (en) * 2019-05-21 2022-06-22 Beijing Bytedance Network Technology Co., Ltd. SYNTAX SIGNALING IN A SUBBLOCK MERGE MODE
WO2021027774A1 (en) 2019-08-10 2021-02-18 Beijing Bytedance Network Technology Co., Ltd. Subpicture dependent signaling in video bitstreams
US11218718B2 (en) * 2019-08-26 2022-01-04 Tencent America LLC Adaptive motion vector resolution signaling
CN114631317B (zh) 2019-10-18 2024-03-15 北京字节跳动网络技术有限公司 子图片的参数集信令中的语法约束
US20230134017A1 (en) * 2021-11-01 2023-05-04 Tencent America LLC Template-matching based adaptive motion vector resolution (amvr) for bi-prediction and an affine mode
WO2023132692A1 (ko) * 2022-01-09 2023-07-13 엘지전자 주식회사 영상 인코딩/디코딩 방법 및 장치, 그리고 비트스트림을 저장한 기록 매체
WO2023220970A1 (zh) * 2022-05-18 2023-11-23 Oppo广东移动通信有限公司 视频编码方法、装置、设备、***、及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113612994B (zh) * 2016-03-15 2023-10-27 寰发股份有限公司 具有仿射运动补偿的视频编解码的方法
WO2018049594A1 (en) * 2016-09-14 2018-03-22 Mediatek Inc. Methods of encoder decision for quad-tree plus binary tree structure
US10602180B2 (en) * 2017-06-13 2020-03-24 Qualcomm Incorporated Motion vector prediction
BR112020005097A2 (pt) * 2017-09-28 2020-09-15 Samsung Electronics Co., Ltd. método de decodificação de vídeo, aparelho de decodificação de vídeo, método de codificação de vídeo, e aparelho de codificação de vídeo
CN115152228A (zh) * 2019-12-30 2022-10-04 交互数字Vc控股法国公司 合并模式、自适应运动向量精度和变换跳过语法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BROSS, Benjamin et al.，Versatile Video Coding (Draft 5)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 14th Meeting: Geneva, CH, 19-27 Mar. 2019, [JVET-N1001-v1]，JVET-N1001 (version 1)，ITU-T，2019年04月09日，＜URL:http://jvet-experts.org/jvet/doc_end_user/documents/14_Geneva/wg11/JVET-N1001-v1.zip＞: JVET-N1001-v1.docx: pp.31-33,49-52
NASER, Karam et al.，Non-CE: Clean-up of High-Level Syntax Related to AMVR，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 17th Meeting: Brussels, BE, 7-17 January 2020, [JVET-Q0444-r1]，JVET-Q0444 (version 3)，ITU-T，2020年01月09日，＜URL:https://jvet-experts.org/doc_end_user/documents/17_Brussels/wg11/JVET-Q0444-v3.zip＞: JVET-Q0444-r2.docx: pp.1-4

Also Published As

Publication number Publication date
JP2022531264A (ja) 2022-07-06
CN113906750A (zh) 2022-01-07
KR20210149759A (ko) 2021-12-09
WO2020222588A1 (ko) 2020-11-05
EP3965420A4 (en) 2022-07-06
EP3965420A1 (en) 2022-03-09
JP2023164843A (ja) 2023-11-14

Similar Documents

Publication Publication Date Title
JP7335358B2 (ja) 適応的動きベクトル解像度を利用したビデオ信号処理方法及び装置
CN113424525B (zh) 解码器侧细化工具的尺寸选择性应用
KR102572286B1 (ko) 영상 코딩 시스템에서 영상 디코딩 방법 및 장치
US11166040B2 (en) Video signal processing method and apparatus using adaptive motion vector resolution
EP3429205B1 (en) Method and apparatus for processing a video signal
US11849106B2 (en) Video signal processing method and device using motion compensation
KR102490375B1 (ko) 움직임 벡터 리스트 설정 방법 및 이러한 방법을 사용하는 장치
KR101782929B1 (ko) 비디오 신호의 처리 방법 및 장치
US20220053206A1 (en) Video signal processing method and apparatus using adaptive motion vector resolution
CN116866570A (zh) 用于处理视频信号的方法和装置
KR102550530B1 (ko) 서브블록 기반의 모션 보상을 이용한 비디오 신호 처리 방법 및 장치
KR102617235B1 (ko) 인터 예측 모드 기반 영상 처리 방법 및 이를 위한 장치
US20190356922A1 (en) Inter-prediction method and apparatus in image coding system
US20220070457A1 (en) Video encoding/decoding method and apparatus
EP4383703A1 (en) Video signal processing method and device using current picture reference
KR20200095982A (ko) 모션 벡터 차이를 사용하는 머지를 기반으로 한 모션 예측을 이용한 비디오 신호 처리 방법 및 장치
WO2012157826A1 (ko) 후보 예측 모드 리스트에서 유사 범위 벡터 제거 방법 및 이러한 방법을 사용하는 장치
KR20240026180A (ko) 인트라 예측을 이용한 비디오 신호 처리 방법 및 이를 위한 장치
KR20200137326A (ko) 현재 픽쳐 참조를 이용한 비디오 신호 처리 방법 및 장치

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211029

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211029

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20220721

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230404

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: 20230718

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230817

R150 Certificate of patent or registration of utility model

Ref document number: 7335358

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150