Video signal processing method and apparatus using subblock-based motion compensation
Sub-block-based motion compensation in video signal processing improves coding efficiency by refining motion vector determination and prediction, addressing inefficiencies in existing methods.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2026-01-14
- Publication Date
- 2026-04-10
AI Technical Summary
Existing video signal processing methods lack efficiency in coding, particularly in the application of motion compensation, which affects the compression and transmission of video data.
The method employs sub-block-based motion compensation using syntax elements to determine the application of merge modes with motion vector differences, allowing for more precise motion vector calculation and prediction block generation.
This approach enhances coding efficiency by reducing signaling overhead and increasing compression efficiency through optimized syntax parsing.
Smart Images

Figure 2026063141000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a method and apparatus for processing video signals, and more particularly, to a method and apparatus for encoding or decoding video signals using sub-block-based motion compensation.
Background Art
[0002] Compression encoding means a series of signal processing techniques for transmitting digitized information via a communication line or storing it in a form suitable for a storage medium. The targets of compression encoding include audio, video, characters, etc., and in particular, the technology for performing compression encoding on video is called video compression. Compression encoding of video signals is performed by removing redundant information in consideration of spatial correlation, temporal correlation, probabilistic correlation, etc. However, due to the recent development of various media and data transmission media, more efficient video signal processing methods and apparatuses are required.
Summary of the Invention
Problems to be Solved by the Invention
[0003] An object of the present invention is to increase the coding efficiency of video signals. An object of the present invention is to provide a method for efficiently performing sub-block-based motion compensation. Also, an object is to provide a motion compensation method based on a merge mode with motion vector difference (merge mode with MVD).
Means for Solving the Problems
[0004] In order to solve the above problems, the present invention provides a video signal processing apparatus and a video signal processing method as follows.
[0005] According to one embodiment of the present invention, a video signal processing method is provided, comprising the steps of: obtaining a first syntax element indicating whether or not a subblock-based merge mode is applied to the current block; if the first syntax element indicates that a subblock-based merge mode is not applied to the current block, obtaining a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block; if the second syntax element indicates that a merge mode using motion vector differences is applied to the current block, obtaining a third syntax element indicating a candidate among the candidates included in the merge candidate list for the current block to be used for interpretation of the current block; obtaining information related to the motion vector difference; inducing the motion vector of the current block by adding the motion vector difference to the motion vector of the candidate indicated by the third syntax element; and generating a predicted block for the current block using the motion vector of the current block.
[0006] As an example, the third syntax element may indicate the candidate used for interpretation of the current block from among the first and second candidates in the current block merge candidate list.
[0007] As an example, the third syntax element may be parsed from the bitstream if the maximum number of merge candidates is greater than 1, and inferred to be 0 if the maximum number of merge candidates is not greater than 1.
[0008] As an example, the step of acquiring information related to the motion vector difference may involve acquiring a fourth syntax element indicating the distance of the motion vector difference, and acquiring a fifth syntax element indicating the direction of the motion vector difference.
[0009] As an embodiment, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the step further includes obtaining a sixth syntax element indicating a candidate used for interpretation of the current block from among the candidates included in the subblock merge candidate list of the current block, and if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the motion vector of the current block can be guided in units of at least one subblock included in the current block based on the motion vector of the candidate indicated by the sixth syntax element.
[0010] As an example, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the second syntax element may be inferred to be 0.
[0011] As an example, the sixth syntax element may be parsed from the bitstream if the maximum number of subblock merge candidates is greater than 1, and may be inferred to be 0 if the maximum number of subblock merge candidates is not greater than 1.
[0012] According to one embodiment of the present invention, a video signal processing device is provided, which includes a processor, the processor acquires a first syntax element indicating whether or not a subblock-based merge mode is applied to the current block; if the first syntax element indicates that a subblock-based merge mode is not applied to the current block, the processor acquires a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block; if the second syntax element indicates that a merge mode using motion vector differences is applied to the current block, the processor acquires a third syntax element indicating a candidate among the candidates included in the merge candidate list for the current block to be used for interpretation of the current block; the processor acquires information related to the motion vector differences; the processor induces the motion vector of the current block by adding the motion vector differences to the motion vector of the candidate indicated by the third syntax element; and generates a predicted block of the current block using the motion vector of the current block.
[0013] As an example, the third syntax element may indicate the candidate used for interpretation of the current block from among the first and second candidates in the current block merge candidate list.
[0014] As an example, the third syntax element may be parsed from the bitstream if the maximum number of merge candidates is greater than 1, and inferred to be 0 if the maximum number of merge candidates is not greater than 1.
[0015] As an example, the processor can obtain a fourth syntax element indicating the distance of the motion vector difference and a fifth syntax element indicating the direction of the motion vector difference.
[0016] As an embodiment, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the processor may obtain a sixth syntax element indicating a candidate to be used for inter prediction of the current block from among the candidates included in the subblock merge candidate list of the current block, and if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the motion vector of the current block may be guided in units of at least one subblock included in the current block based on the motion vector of the candidate indicated by the sixth syntax element.
[0017] As an example, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the second syntax element may be inferred to be 0.
[0018] As an example, the sixth syntax element may be parsed from the bitstream if the maximum number of subblock merge candidates is greater than 1, and may be inferred to be 0 if the maximum number of subblock merge candidates is not greater than 1.
[0019] According to one embodiment of the present invention, a video signal processing method is provided, comprising the steps of: encoding a first syntax element indicating whether or not a subblock-based merge mode is applied to the current block; if a subblock-based merge mode is not applied to the current block, encoding a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block; if a merge mode using motion vector differences is applied to the current block, encoding a third syntax element indicating a candidate among the candidates included in the merge candidate list of the current block to be used for interpretation of the current block; encoding information related to the motion vector difference; inducing the motion vector of the current block by adding the motion vector difference to the motion vector of the candidate indicated by the third syntax element; and generating a predicted block of the current block using the motion vector of the current block. [Effects of the Invention]
[0020] According to embodiments of the present invention, the coding efficiency of video signals can be increased. In particular, according to one embodiment of the present invention, signaling overhead can be reduced and compression efficiency increased by adjusting the syntax parsing order. [Brief explanation of the drawing]
[0021] [Figure 1] This is a schematic block diagram of a video signal encoding device according to one embodiment of the present invention. [Figure 2] This is a schematic block diagram of a video signal decoding device according to one embodiment of the present invention. [Figure 3] This figure shows an example in which a coding tree unit is divided into coding units within a picture. [Figure 4] This figure shows one embodiment of a method for signaling the division of quad trees and multi-type trees. [Figure 5] FIG. showing inter prediction according to an embodiment of the present invention. [Figure 6] FIG. illustrating a motion vector signaling method according to an embodiment of the present invention. [Figure 7] FIG. illustrating a signaling method for adaptive motion vector resolution information according to an embodiment of the present invention. [Figure 8] FIG. showing affine motion compensation according to an embodiment of the present invention. [Figure 9] FIG. showing an embodiment of a 4-parameter affine motion compensation method. [Figure 10] FIG. for explaining an affine motion prediction method according to an embodiment of the present invention. [Figure 11] FIG. showing an embodiment of a sub-block based affine motion compensation method. [Figure 12] FIG. showing an embodiment of the present invention for obtaining a control point motion vector set for prediction of a current block. [Figure 13] FIG. showing an embodiment of the present invention for obtaining a control point motion vector set for prediction of a current block. [Figure 14] FIG. for explaining an affine motion compensation method according to an embodiment of the present invention. [Figure 15] FIG. for explaining an affine motion compensation method according to an embodiment of the present invention. [Figure 16] FIG. showing subblock-based temporal MVP (SbTMVP) according to an embodiment of the present invention. [Figure 17] FIG. illustrating planar MVP according to an embodiment of the present invention. [Figure 18] FIG. showing a method for determining a temporary motion vector according to an embodiment of the present invention. [Figure 19]This figure illustrates the presence or absence of SbTMVP in one embodiment of the present invention. [Figure 20] This figure illustrates an example of an SbTMVP induction method according to one embodiment of the present invention. [Figure 21] This figure illustrates an MMVD application method according to one embodiment of the present invention. [Figure 22] This figure illustrates an MMVD-related syntax structure according to one embodiment of the present invention. [Figure 23] This figure illustrates an MMVD-related syntax structure according to one embodiment of the present invention. [Figure 24] This figure illustrates an MMVD-related syntax structure according to one embodiment of the present invention. [Figure 25] This figure illustrates an MMVD syntax according to one embodiment of the present invention. [Figure 26] This figure illustrates an MMVD syntax according to one embodiment of the present invention. [Figure 27] This figure illustrates an MMVD syntax according to one embodiment of the present invention. [Figure 28] This figure illustrates an MMVD syntax according to one embodiment of the present invention. [Figure 29] This figure illustrates a coding unit syntax structure according to one embodiment of the present invention. [Figure 30] This figure illustrates a merged data syntax structure according to one embodiment of the present invention. [Figure 31] This figure illustrates a merged data syntax structure according to one embodiment of the present invention. [Figure 32] This figure illustrates a merged data syntax structure according to one embodiment of the present invention. [Figure 33] This figure illustrates a video signal processing method according to one embodiment to which the present invention is applied. [Modes for carrying out the invention]
[0022] The terminology used herein has been selected as widely used and general terms as possible, taking into account the function of the present invention; however, this may vary depending on the intent of the articulators, conventions, or the emergence of new technologies. In addition, in certain cases, the applicant has arbitrarily selected some terms, in which case their meaning will be described in the section describing the mode of implementation of the invention. Therefore, it is important to clarify that the terminology used herein is not merely a set of names, but should be interpreted based on the substantive meaning of the term and the overall content of this specification.
[0023] In this specification, some terms are interpreted as follows: Coding is sometimes interpreted as encoding or coding. In this specification, a device that encodes a video signal to generate a video signal bitstream is referred to as an encoding device or encoder, and a device that decodes a video signal bitstream to restore a video signal is referred to as a decoding device or decoder. In this specification, the term video signal processing device is used as a conceptual term that includes both encoders and decoders. Information is a term that includes values, parameters, coefficients, elements, etc., and may be interpreted differently in some cases, so the present invention is not limited thereto. "Unit" is used to mean a basic unit of image processing or a specific location in a picture, and refers to an image region that includes both luma and chroma components. "Block" refers to an image region that includes a specific component among the luma and chroma components (i.e., Cb and Cr). However, in some embodiments, terms such as "unit," "block," "partition," and "region" may be used interchangeably. Furthermore, in this specification, the term "unit" is used as a concept that includes coding units, prediction units, and transformation units. "Picture" refers to a field or frame, and in some embodiments, these terms are used interchangeably.
[0024] Figure 1 is a schematic block diagram of a video signal encoding device according to one embodiment of the present invention. Referring to Figure 1, the encoding device 100 of this specification includes a conversion unit 110, a quantization unit 115, an inverse quantization unit 120, an inverse conversion unit 125, a filtering unit 130, a prediction unit 150, and an entropy coding unit 160.
[0025] The conversion unit 110 converts the residual signal, which is the difference between the input video signal and the predicted signal generated by the prediction unit 150, to obtain conversion coefficient values. For example, discrete cosine transform (DCT), discrete sine transform (DST), or wavelet transform may be used. Discrete cosine transform and discrete sine transform divide the input picture signal into block form and perform the transformation. In the transformation, the coding efficiency may differ depending on the distribution and characteristics within the transformation domain. The quantization unit 115 quantizes the values of the conversion coefficients output by the conversion unit 110.
[0026] To improve coding efficiency, instead of directly coding the picture signal, a method is used in which the picture is predicted using a pre-coded region via the prediction unit 150, and the restored picture is obtained by adding the residual value between the original picture and the predicted picture to the predicted picture. To prevent mismatches between the encoder and decoder, the encoder should use information that is also available to the decoder when performing predictions. For this purpose, the encoder performs a further process of restoring the currently encoded block. The inverse quantization unit 120 inversely quantizes the conversion coefficient values, and the inverse transformation unit 125 restores the residual value using the inversely quantized conversion coefficient values. Meanwhile, the filtering unit 130 performs filtering operations to improve the quality of the restored picture and enhance coding efficiency. Examples include deblocking filters, sample adaptive offsets (SAO), and adaptive loop filters. The filtered picture is stored in a decoded picture buffer (DPB) 156 for output or use as a reference picture.
[0027] To improve coding efficiency, instead of directly coding the picture signal, a method is used in which the picture is predicted using an already coded region in the prediction unit 150, and the restored picture is obtained by adding the residual value between the original picture and the predicted picture to the predicted picture. The intra-prediction unit 152 performs in-screen prediction within the current picture, and the inter-prediction unit 154 predicts the current picture using a reference picture stored in the decoded picture buffer 156. The intra-prediction unit 152 performs in-screen prediction from the restored region within the current picture and transmits the in-screen coding information to the entropy coding unit 160. The inter-prediction unit 154 may further include a motion estimation unit 154a and a motion compensation unit 154b. The motion estimation unit 154a obtains the motion vector value of the current region by referring to a specific restored region. The motion estimation unit 154a transmits position information of the reference region (reference frame, motion vector, etc.) to the entropy coding unit 160 so that it can be included in the bitstream. The motion compensation unit 154b performs inter-screen motion compensation using the motion vector values transmitted from the motion estimation unit 154a.
[0028] The prediction unit 150 includes an intra-prediction unit 152 and an inter-prediction unit 154. The intra-prediction unit 152 performs intra-prediction within the current picture, and the inter-prediction unit 154 performs inter-prediction, predicting the current picture using a reference buffer stored in the decoded picture buffer 156. The intra-prediction unit 152 performs intra-prediction from the restored samples in the current picture and transmits intra-coded information to the entropy coding unit 160. The intra-coded information includes at least one of the following: intra-prediction mode, MPM (Most Probable Mode) flag, and MPM index. The intra-coded information may include information about the reference sample. The inter-prediction unit 154 includes a motion estimation unit 154a and a motion compensation unit 154b. The motion estimation unit 154a obtains motion vector values for the current region by referring to a specific region of the restored reference signal picture. The motion estimation unit 154a transmits a set of motion information (reference picture index, motion vector information) for the reference region to the entropy coding unit 160. The motion compensation unit 154b performs motion compensation using the motion vector values transmitted from the motion compensation unit 154a. The inter-prediction unit 154 transmits inter-coded information, including motion information for the reference region, to the entropy coding unit 160.
[0029] In a further embodiment, the prediction unit 150 includes an intrablock copy (BC) prediction unit (not shown). The intraBC prediction unit performs intraBC prediction from the restored samples in the current picture and transmits the intraBC encoded information to the entropy coding unit 160. The intraBC prediction unit obtains a block vector value indicating a reference region used for prediction of the current region by referring to a specific region in the current picture. The intraBC prediction unit performs intraBC prediction using the obtained block vector value. The intraBC prediction unit transmits the intraBC encoded information to the entropy coding unit 160. The intraBC prediction unit includes block vector information.
[0030] Once the picture prediction described above is performed, the conversion unit 110 converts the residual values between the original picture and the predicted picture to obtain conversion coefficient values. In this case, the conversion is performed in units of specific blocks within the picture, but the size of the specific block is variable within a preset range. The quantization unit 115 quantizes the values of the conversion coefficients generated by the conversion unit 110 and transmits them to the entropy coding unit 160.
[0031] The entropy coding unit 160 generates a video signal bitstream by entropy coding information indicating quantized conversion coefficients, intra-coded information, and inter-coded information. The entropy coding unit 160 uses methods such as variable length coding (VLC) and arithmetic coding. Variable length coding (VLC) converts input symbols into a sequence of codewords, but the length of the codewords is variable. For example, frequently occurring symbols are represented by short codewords, and less frequently occurring symbols are represented by long codewords. Context-based Adaptive Variable Length Coding (CAVLC) is used as the variable length coding method. Arithmetic coding converts a sequence of data symbols into a single prime number, but arithmetic coding obtains the optimal number of prime bits necessary to represent each symbol. Context-based Adaptive Binary Arithmetic Coding (CABAC) is used as the arithmetic coding method. For example, the entropy coding unit 160 can binary-code information indicating quantized transformation coefficients. Furthermore, the entropy coding unit 160 can arithmetically code the binary-coded information to generate a bitstream.
[0032] The generated bitstream is encapsulated in Network Abstraction Layer (NAL) units as its basic units. Each NAL unit contains an encoded integer number of coding tree units. To decode the bitstream with a video decoder, the bitstream must first be separated into NAL units, and then each separated NAL unit must be decoded. Meanwhile, the information necessary for decoding the video signal bitstream is transmitted via Raw Byte Sequence Payloads (RBSPs) of higher-level sets such as Picture Parameter Set (PPS), Sequence Parameter Set (SPS), and Video Parameter Set (VPS).
[0033] On the other hand, the block diagram in Figure 1 shows an encoding device 100 according to one embodiment of the present invention, and the separated blocks show the elements of the encoding device 100 in a logically distinguishable manner. Therefore, the elements of the encoding device 100 described above are mounted on one chip or multiple chips depending on the device design. According to one embodiment, the operation of each element of the encoding device 100 described above is performed by a processor (not shown).
[0034] Figure 2 is a schematic block diagram of a video signal decoding apparatus 200 according to an embodiment of the present invention. Referring to Figure 2, the decoding apparatus 200 according to this specification includes an entropy decoding unit 210, an inverse quantization unit 220, an inverse transformation unit 225, a filtering unit 230, and a prediction unit 250.
[0035] The entropy decoding unit 210 entropy decodes the video signal bitstream and extracts conversion coefficient information, intra-encoded information, inter-encoded information, etc., for each region. For example, the entropy decoding unit 210 can obtain binary-coded conversion coefficient information for a specific region from the video signal bitstream. The entropy decoding unit 210 also performs inverse binary-coded conversion of the binary-coded conversion coefficient to obtain quantized conversion coefficients. The inverse quantization unit 220 inverse quantizes the quantized conversion coefficients, and the inverse conversion unit 225 restores the residual value using the inverse quantized conversion coefficient. The video signal processing device 200 adds the residual value obtained from the inverse conversion unit 225 with the predicted value obtained from the prediction unit 250 to restore the original pixel value.
[0036] Meanwhile, the filtering unit 230 improves image quality by filtering the picture. This includes a deblocking filter to reduce block distortion and / or an adaptive loop filter to remove distortion from the entire picture. The filtered picture is either output or stored in the decoded picture buffer (DPB) 256 to be used as a reference picture for the next picture.
[0037] The prediction unit 250 includes an intra-prediction unit 252 and an inter-prediction unit 254. The prediction unit 250 generates a prediction picture by utilizing the encoding type decoded through the aforementioned entropy decoding unit 210, the conversion coefficients for each region, intra / inter-encoded information, etc. To restore the current block from which decoding is performed, the current picture containing the current block or the decoded region of another picture can be used. A picture (or tile / slice) that uses only the current picture for restoration, i.e., performs intra-prediction or intra-BC prediction, is called an intra-picture or I-picture (or tile / slice), and a picture (or tile / slice) that can perform intra-prediction, inter-prediction, and intra-BC prediction is called an inter-picture (or tile / slice). Among interpictures (or tiles / slice), a picture (or tile / slice) that uses up to one motion vector and a reference picture index to predict the sample value of each block is called a predictive picture or P-picture (or tile / slice), and a picture (or tile / slice) that uses up to two motion vectors and a reference picture index is called a bi-predictive picture or B-picture (or tile / slice). In other words, a P-picture (or tile / slice) uses up to one motion information set to predict each block, and a B-picture (or tile / slice) uses up to two motion information sets to predict each block. Here, a motion information set includes one or more motion vectors and one reference picture index.
[0038] The intra-prediction unit 252 generates a prediction block using intra-encoded information and the recovered sample in the current picture. As described above, the intra-encoded information includes at least one of the intra-prediction mode, the MPM (MOST Probable Mode) flag, and the MPM index. The intra-prediction unit 252 predicts the sample value of the current block using the recovered sample located to the left and / or above the current block as a reference sample. In this disclosure, the recovered sample, the reference sample, and the sample of the current block represent pixels. The sample value also represents the pixel value.
[0039] In one embodiment, the reference sample is a sample included in the surrounding blocks of the current block. For example, the reference sample is a sample adjacent to the left boundary and / or the upper boundary of the current block. Alternatively, the reference sample is a sample located in the surrounding blocks of the current block that lies on a line within a predetermined distance from the left boundary and / or on a line within a predetermined distance from the upper boundary of the current block. In this case, the surrounding blocks of the current block include at least one of the following blocks adjacent to the current block: the left (L) block, the upper (A) block, the lower left (BL) block, the upper right (AR) block, or the upper left (AL) block.
[0040] The interprediction unit 254 generates a prediction block using the reference picture and intercoded information stored in the decoded picture buffer 256. The intercoded information includes a set of motion information for the current block relative to the reference block (reference picture index, motion vector, etc.). Interpretation includes L0 prediction, L1 prediction, and bi-prediction. L0 prediction is a prediction that uses one reference picture included in the L0 picture list, and L1 prediction means a prediction that uses one reference picture included in the L1 picture list. For this, one set of motion information (e.g., motion vector and reference picture index) is required. In the bi-prediction method, up to two reference regions are used, but these two reference regions may reside in the same reference picture or in different pictures. In other words, in the bi-prediction method, up to two sets of motion information (e.g., motion vector and reference picture index) are used, but the two motion vectors may correspond to the same reference picture index or to different reference picture indices. In this case, the reference picture is displayed (or output) either before or after the current picture in terms of time. In one embodiment, the two reference regions used in the dual prediction method may be regions selected from the L0 picture list and the L1 picture list, respectively.
[0041] The interpretation unit 254 obtains the current reference block using the motion vector and the reference picture index. The reference block resides within the reference picture corresponding to the reference picture index. The sample value of the block identified by the motion vector, or an interpolated value thereof, is used as the predictor for the current block. For motion prediction with sub-pel pixel accuracy, for example, an 8-tab interpolation filter is used for the luminance signal and a 4-tab interpolation filter is used for the chrominance signal. However, the interpolation filter for sub-pel motion prediction is not limited to these. In this way, the interpretation unit 254 performs motion compensation, predicting the texture of the current unit from the previously restored picture. In this process, the interpretation unit utilizes a motion information set.
[0042] In a further embodiment, the prediction unit 250 may include an intra-BC prediction unit (not shown). The intra-BC prediction unit can reconstruct the current region by referring to a specific region containing the reconstructed sample in the current picture. The intra-BC prediction unit obtains intra-BC encoded information for the current region from the entropy decoding unit 210. The intra-BC prediction unit obtains a block vector value of the current region that points to a specific region in the current picture. The intra-BC prediction unit can perform intra-BC prediction using the obtained block vector value. The intra-BC encoded information may include block vector information.
[0043] In a further embodiment, the prediction unit 250 may include an intra-BC prediction unit (not shown). The intra-BC prediction unit can reconstruct the current region by referring to a specific region containing the reconstructed sample in the current picture. The intra-BC prediction unit obtains intra-BC encoded information for the current region from the entropy decoding unit 210. The intra-BC prediction unit obtains a block vector value of the current region that points to a specific region in the current picture. The intra-BC prediction unit can perform intra-BC prediction using the obtained block vector value. The intra-BC encoded information may include block vector information.
[0044] On the other hand, the block diagram in Figure 2 shows a decoding device 200 according to one embodiment of the present invention, and the separated blocks show the elements of the decoding device 200 in a logically distinguishable manner. Thus, the elements of the decoding device 200 described above are mounted on one chip or multiple chips depending on the device design. According to one embodiment, the operation of each element of the decoding device 200 described above is performed by a processor (not shown).
[0045] Figure 3 shows an example in which a Coding Tree Unit (CTU) is divided into Coding Units (CUs) within a picture. In the coding process of a video signal, the picture is divided into a sequence of Coding Tree Units (CTUs). A Coding Tree Unit consists of two blocks: an NXN block of luminance samples and its corresponding chrominance samples. A Coding Tree Unit is divided into multiple Coding Units. A Coding Tree Unit may also become a leaf node without being divided. In this case, the Coding Tree Unit itself can become a Coding Unit. A Coding Unit refers to a basic unit for processing a picture in the video signal processing processes described above, i.e., intra / inter prediction, transformation, quantization, and / or entropy coding. Within a single picture, the size and pattern of the Coding Units are not constant. Coding Units have a square or rectangular pattern. A rectangular Coding Unit (or rectangular block) includes vertical Coding Units (or vertical blocks) and horizontal Coding Units (or horizontal blocks). In this specification, a vertical block is a block whose height is greater than its width, and a horizontal block is a block whose width is greater than its height. Furthermore, in this specification, a non-square block refers to a rectangular block, but the present invention is not limited to this.
[0046] Referring to Figure 3, the coding tree unit is first divided into a quad tree (QT) structure. That is, in the quad tree structure, one node with a size of 2N × 2N is divided into four nodes with a size of N × N. In this specification, the quad tree is also referred to as a quaternary tree. The quad tree division is performed recursively, and it is not necessary for all nodes to be divided to the same depth.
[0047] On the other hand, the leaf nodes of the quad tree described above are further divided into a multi-type tree (MTT) structure. According to embodiments of the present invention, in a multi-type tree structure, one node is divided into a binary or ternary tree structure with horizontal or vertical division. In other words, there are four division structures in a multi-type tree structure: vertical binary division, horizontal binary division, vertical ternary division, and horizontal ternary division. According to embodiments of the present invention, in each of the tree structures, the width and height of the node are both powers of 2. For example, in a binary tree (BT) structure, a node of size 2N×2N is divided into two N×2N nodes by vertical binary division and into two 2N×N nodes by horizontal binary division. Furthermore, in a Ternary Tree (TT) structure, a node of size 2N×2N is divided into (N / 2)×2N, N×2N, and (N / 2)×2N nodes by vertical ternary decomposition, and into 2N×(N / 2), 2N×N, and 2N×(N / 2) nodes by horizontal ternary decomposition. Such multi-type tree decomposition is performed recursively.
[0048] Leaf nodes in a multi-type tree can be coding units. If no splitting is instructed for a coding unit, or if the coding unit is not larger than the maximum transformation length, the coding unit is used as the unit for prediction and transformation without further splitting. On the other hand, in the quad tree and multi-type tree described above, at least one of the following parameters is predefined or transmitted via RBSP of a higher-level set such as PPS, SPS, VPS, etc.: 1) CTU size: the size of the root node of the quad tree, 2) MinQtSize: the minimum allowed QT leaf node size, 3) MaxBtSize: the maximum allowed BT root node size, 4) MaxTtSize: the maximum allowed TT root node size, 5) MaxMttDepth: the maximum allowed depth of MTT splitting from the leaf nodes of the QT, 6) MinBtSize: the minimum allowed BT leaf node size, 7) MinTT size: the minimum allowed TT leaf node size.
[0049] Figure 4 illustrates one embodiment of a method for signaling the splitting of quad trees and multi-type trees. The flags previously set to signal the splitting of quad trees and multi-type trees can be used. Referring to Figure 4, at least one of the following can be used: 'qt_split_flag' which indicates whether or not to split a quad tree node, 'mtt_split_flag' which indicates whether or not to split a multi-type tree node, 'mtt_split_vertical_flag' which indicates the splitting direction of a multi-type tree node, or 'mtt_split_binary_flag' which indicates the splitting form of a multi-type tree node.
[0050] According to an embodiment of the present invention, the coding tree unit is the root node of a quad tree and can be divided into a quad tree structure beforehand. In the quad tree structure, each node 'QT_node' is signaled with 'qt_split_flag'. If the value of 'qt_split_flag' is 1, the node is divided into four square nodes, and if the value of 'qt_split_flag' is 0, the node becomes a leaf node 'QT_leaf_node' of the quad tree.
[0051] Each quadtree leaf node 'QT_leaf_node' can be further divided into a multi-type tree structure. In the multi-type tree structure, each node 'MTT_node' is signaled with 'mtt_split_flag'. If the value of 'mtt_split_flag' is 1, the node is divided into multiple rectangular nodes, and if the value of 'mtt_split_flag' is 0, the node becomes a leaf node 'MTT_leaf_node' in the multi-type tree. When a multi-type tree node 'MTT_node' is divided into multiple rectangular nodes (i.e., when the value of 'mtt_split_flag' is 1), additional 'mtt_split_vertical_flag' and 'mtt_split_binary_flag' can be signaled for the node 'MTT_node'. If the value of 'mtt_split_vertical_flag' is 1, the node 'MTT_node' is instructed to be split vertically. If the value of 'mtt_split_vertical_flag' is 0, the node 'MTT_node' is instructed to be split horizontally. Also, if the value of 'mtt_split_binary_flag' is 1, the node 'MTT_node' is split into two rectangular nodes. If the value of 'mtt_split_binary_flag' is 0, the node 'MTT_node' is split into three rectangular nodes.
[0052] Picture prediction (motion compensation) for coding is performed on coding units that cannot be further divided (i.e., leaf nodes in the coding unit tree). The basic unit for performing such predictions is referred to below as a prediction unit or prediction block.
[0053] Hereinafter, the term "unit" as used herein is used as a substitute for the prediction unit, which is the basic unit for making predictions. However, the present invention is not limited thereto and is understood in a broader sense as a concept that includes the coding unit.
[0054] Figure 5 illustrates an interpretation according to an embodiment of the present invention. As described above, the decoder predicts the current block by referring to a restored sample of another decoded picture. Referring to Figure 5, the decoder obtains the reference block 42 in the reference picture based on the motion information of the current block 32. At this time, the motion information may include the reference picture index and the motion vector 50. The reference picture index indicates the reference picture of the current block in the reference picture list. The motion vector 50 represents the offset between the coordinate values of the current block 32 in the current picture and the coordinate values of the reference block 42 in the reference picture. The decoder obtains a predictor of the current block 32 based on the sample values of the reference block 42 and uses the predictor to restore the current block 32.
[0055] On the other hand, according to an embodiment of the present invention, subblock-based motion compensation may be used. That is, the current block 32 may be divided into a plurality of subblocks, and an independent motion vector may be used for each subblock. Therefore, each subblock within the current block 32 may be predicted using a different reference block. According to one embodiment, the subblocks may have a pre-set size such as 4x4 or 8x8. The decoder obtains predictors for each subblock of the current block 32 using the motion vectors of each subblock. By combining the predictors of each subblock, a predictor for the current block 32 can be obtained, and the decoder can reconstruct the current block 32 using the predictor for the current block 32 thus obtained.
[0056] According to embodiments of the present invention, various methods of subblock-based motion compensation may be performed. Subblock-based motion compensation can include affine model-based motion compensation (hereinafter referred to as affine motion compensation or affine motion prediction) and subblock-based temporal motion vector prediction (SbTMVP). Various embodiments of affine motion compensation and SbTMVP will be described below with reference to the figures.
[0057] Figure 6 illustrates a motion vector signaling method according to one embodiment of the present invention. According to one embodiment of the present invention, the motion vector (MV) may be generated based on a motion vector prediction (or predictor) (MVP). For example, the MV may be determined to be the same as the MVP as shown in the following mathematical formula 1. In other words, the MV may be determined (or set, guided) to the same value as the MVP.
[0058]
number
[0059] As another example, MV may be determined based on MVP and motion vector difference (MVD), as shown in the following mathematical equation 2. The encoder can signal MVD information to the decoder to represent a more accurate MV, and the decoder can induce MV by adding the acquired MVD to MVP.
[0060]
number
[0061] According to one embodiment of the present invention, the encoder transmits determined motion information to the decoder, and the decoder can generate (or induce) a motion vector (MV) from the received motion information and generate a prediction block based on it. For example, the motion information may include MVP information and MVD information. In this case, the components of the motion information may differ depending on the inter-prediction mode. For example, in merge mode, the motion information may include MVP information but not MVD information. As another example, in AMVP (advanced motion vector prediction) mode, the motion information may include both MVP information and MVD information.
[0062] To determine, transmit, and receive information about the MVP, the encoder and decoder can generate MVP candidates (or a list of MVP candidates) in the same manner. For example, the encoder and decoder can generate the same MVP candidates in the same order. The encoder then transmits an index to the decoder indicating the determined (or selected) MVP from the generated MVP candidates, and the decoder can derive the determined MVP and / or MV based on the received index.
[0063] According to one embodiment of the present invention, MVP candidates may include spatial candidates, temporal candidates, and the like. When merge mode is applied, the MVP candidate may be called a merge candidate, and when AMVP mode is applied, it may be called an AMVP candidate. A spatial candidate may be the MV (or motion information) for a block at a specific position relative to the current block. For example, the spatial candidate may be the MV of a block at a position adjacent to or not adjacent to the current block. A temporal candidate may be the MV corresponding to a block in a picture different from the current picture. Furthermore, for example, MVP candidates may include affine MV, ATMVP, STMVP, a combination of the aforementioned MVs (or candidates), the average MV of the aforementioned MVs (or candidates), zero MV, and the like.
[0064] In one embodiment, the encoder can signal information indicating a reference picture to the decoder. In one embodiment, if the reference picture of the MVP candidate is different from the reference picture of the current block (or the current processing block), the encoder / decoder can perform motion vector scaling (MV scaling) of the MVP candidate. In this case, MV scaling may be performed based on the picture order count (POC) of the current picture, the POC of the reference picture of the current block, and the POC of the reference picture of the MVP candidate.
[0065] The following describes a specific example of an MVD signaling method. Table 1 below illustrates a syntax structure for MVD signaling.
[0066] [Table 1]
[0067] Referring to Table 1, according to one embodiment of the present invention, the MVD may be coded with its sign and absolute value separately. That is, the sign and absolute value of the MVD may each be represented by different syntax (or syntax elements). The absolute value of the MVD may be coded directly, or it may be coded stepwise based on a flag indicating whether the absolute value is greater than N, as shown in Table 1. If the absolute value is greater than N, the value of (absolute value - N) may be signaled together. Specifically, in the example in Table 1, an abs_mvd_greater0_flag indicating whether the absolute value is greater than 0 may be transmitted. If abs_mvd_greater0_flag indicates (or suggests) that the absolute value is not greater than 0, the absolute value of the MVD may be determined to be 0. If abs_mvd_greater0_flag indicates that the absolute value is greater than 0, additional syntax (or syntax elements) may be present.
[0068] For example, an abs_mvd_greater1_flag indicating whether the absolute value is greater than 1 may be transmitted. If abs_mvd_greater1_flag indicates (or suggests) that the absolute value is not greater than 1, then the absolute value of the MVD may be determined to be 1. If abs_mvd_greater1_flag indicates that the absolute value is greater than 1, then additional syntax may exist. For example, abs_mvd_minus2 may exist. abs_mvd_minus2 may be the value of (absolute value - 2). Since the absolute value has been determined to be greater than 1 (i.e., 2 or greater) by the values of abs_mvd_greater0_flag and abs_mvd_greater1_flag, the value of (absolute value - 2) may be signaled. In this way, by hierarchically syntactically signaling information about the absolute value, fewer bits are used compared to signaling by directly binary-coding the absolute value.
[0069] In one embodiment, the syntax related to absolute values described above may be coded by applying binary evolution methods with variable lengths such as Exponential-Golomb, truncated unary, or truncated Rice. Furthermore, a flag indicating the sign of the MVD may be signaled by mvd_sign_flag.
[0070] In the above-described embodiment, a coding method for MVD was explained, but information other than MVD can also be signaled by separating the sign and absolute value. The absolute value may be coded as a flag indicating whether the absolute value is greater than a predetermined specific value, and as the value obtained by subtracting the specific value from the absolute value. In Table 1, [0] and [1] can represent component indices. For example, they can represent x-components (i.e., horizontal components) and y-components (i.e., vertical components).
[0071] Figure 7 illustrates a signaling method for adaptive motion vector resolution information according to one embodiment of the present invention. According to one embodiment of the present invention, the resolution for indicating MV or MVD can be diverse. For example, the resolution may be expressed based on pixels (or pel). For example, MV or MVD may be signaled in units such as 1 / 4 (quarter), 1 / 2 (half), 1 (integer), 2, 4 pixels, etc. The encoder can then signal the MV or MVD resolution information to the decoder. Also, for example, 16 may be coded as 64 when it is in 1 / 4 units (1 / 4 * 64 = 16), as 16 when it is in 1 unit (1 * 16 = 16), and as 4 when it is in 4 units (4 * 0.4 = 16). That is, the MV or MVD value may be determined by the following mathematical formula 3.
[0072]
number
[0073] In mathematical formula 3, valueDetermined represents the MV or MVD value. ValuePerResolution represents the value signaled based on the determined resolution. If the value signaled by MV or MVD is not divisible by the determined resolution, a rounding process or the like may be applied. Using a higher resolution may improve accuracy, but may use more bits because the encoded value is larger. Using a lower resolution may lower accuracy, but may require fewer bits because the encoded value is smaller. As one example, the resolution described above may be set individually in units such as sequence, picture, slice, coding tree unit (CTU), and coding unit (CU). That is, the encoder / decoder can adaptively determine / apply the resolution according to a predefined unit from among the above units.
[0074] According to one embodiment of this specification, the resolution information described above may be signaled from the encoder to the decoder. In this case, the resolution information may be signaled in binary based on the variable length described above. In such a case, signaling overhead can be reduced if the signaling is based on the index corresponding to the smallest value (i.e., the earliest value). In one embodiment, the signaling index may be mapped in order from high resolution to low resolution.
[0075] In one embodiment of this specification, Figure 7 illustrates a signaling method assuming that three resolutions are used from among several various resolutions. In this case, the three signaling bits may be 0, 10, and 11, and the three signaling indices can represent the first resolution, second resolution, and third resolution, respectively. Since one bit is required to signal the first resolution and two bits are required to signal the remaining resolutions, the signaling overhead can be relatively reduced when signaling the first resolution. In the example of Figure 7, the first resolution, second resolution, and third resolution may be defined as 1 / 4, 1, and 4 pixel resolutions, respectively. In the following embodiments, MV resolution can mean the resolution of MVD.
[0076] Figure 8 shows an affine motion compensation according to one embodiment of the present invention. According to existing interpretation methods, interpretation is performed using a single motion vector for each L0 and L1 prediction for the current block, and is therefore optimized for translation motion prediction. However, in order to efficiently perform motion compensation for zoom in / out, rotation, and other irregular motions, it is necessary to use reference blocks 44 of various shapes and sizes.
[0077] Referring to Figure 8, in affine motion compensation, the current block 34 may be predicted using a reference block 44 having a different size, shape, and / or orientation from the current block 34. That is, the reference block 44 can have a non-rectangular shape and may be larger or smaller in size than the current block 34. The reference block 44 can be obtained by performing an affine transformation on the current block 34. The affine transformation can include a 6-parameter affine transformation using three control point motion vectors (CPMVs) and a 4-parameter affine transformation using two control point motion vectors. Specific examples of this will be described later.
[0078] Figure 9 shows an embodiment of a 4-parameter affine motion compensation method. To reduce the computational complexity and signaling overhead of the affine transformation, affine motion prediction can be performed using a pre-defined number of control point motion vectors (CPMVs). A control point motion vector (CPMV) is a motion vector corresponding to a specific control point (or sample position) of the current block. A specific control point can include at least one vertex of the current block. In this embodiment of the present invention, the CPMV corresponding to the upper left vertex of the current block is called v0 (or the first CPMV), the CPMV corresponding to the upper right vertex of the current block is called v1 (or the second CPMV), and the CPMV corresponding to the lower left vertex of the current block is called v2 (or the third CPMV). A set of CPMVs containing at least two CPMVs can be used for affine motion prediction.
[0079] According to the embodiment in Figure 9, 4-parameter affine motion prediction can be performed using v0 and v1. The current block 36, shown by the solid line, can be predicted using the reference block 46 at the position shown by the dotted line. Each sample of the current block 36 may be mapped to a different reference sample by an affine transformation. More specifically, the motion vector (vx, vy) at the sample position (x, y) of the current block 36 may be derived by the following mathematical formula 4.
[0080]
number
[0081] Here, (v0x, v0y) is the first CPMV corresponding to the top-left vertex of block 36, and (v1x, v1y) is the second CPMV corresponding to the top-right vertex of block 36. Also, w is the width of block 36.
[0082] Figure 10 is a diagram illustrating an affine motion prediction method according to one embodiment of the present invention. According to one embodiment of the present invention, affine motion can be represented using a number of CPMVs or a number of parameters.
[0083] Referring to Figure 10, the encoder / decoder can perform affine motion prediction using the CPMVs v0, v1, and v2. When six parameters are used, three control point motion vectors (CPMVs) v0, v1, and v2 may be used for affine motion prediction. Based on the three vectors v0, v1, and v2 or the six parameters, it is possible to indicate what shape of reference block the current block 36 is predicted from. Referring to Figure 10, the current block 36, represented by a solid line, may be predicted from the reference block 46, represented by a dotted line in Figure 10 of the reference picture. That is, each control point (or pixel at that position) of the current block 36 may be mapped to other points (or pixels) by an affine transformation. The following mathematical formula 5 is an expression representing a motion vector field according to one embodiment of the present invention.
[0084]
number
[0085] In mathematical formula 5, the CPMV v0 representing the motion vector of the top-left corner control point in Figure 10 may be expressed as (mv_0^x, mv_0^y). The CPMV v1 representing the motion vector of the top-right corner control point may be expressed as (mv_1^x, mv_1^y). The CPMV v2 representing the motion vector of the bottom-left corner control point may be expressed as (mv_2^x, mv_2^y). In this case, the motion vector (mv^x, mv^y) at the (x,y) position can be derived (or calculated) using mathematical formula 5. Therefore, the motion vector for each pixel position or specific position may be derived by mathematical formula 5 based on the control point motion vectors v0, v1, and v2.
[0086] Furthermore, in mathematical formula 5, (x,y) may be relative coordinates within the block. For example, if the upper left corner of the block is at (0,0), then (x,y) may be a position relative to the upper left corner. Therefore, assuming that the position of v0 is (x0,y0), the position of v1 is (x1,y1), and the position of v2 is (x2,y2), and using the same coordinates for (x,y) as for the positions of v0, v1, and v2, then in mathematical formula 5, x and y can be expressed as (x-x0) and (y-y0), respectively. In this case, w, which represents the width of the block, may be (x1-x0), and h, which represents the height of the block, may be (y2-y0).
[0087] FIG. 11 shows an example of a sub-block-based affine motion compensation method. As described above, when using an affine motion transformation, a motion vector (i.e., a motion vector field) at each sample position of the current block can be derived. However, according to an embodiment of the present invention, in order to reduce the amount of calculation, sub-block-based affine motion compensation can be performed. As shown in FIG. 8, the current block can include a plurality of sub-blocks, and a representative motion vector for each sub-block is obtained based on the CPMV set. According to one embodiment, the representative motion vector for each sub-block may be a motion vector corresponding to the sample position at the center of the sub-block. According to an additional embodiment, a motion vector with higher accuracy than a general motion vector may be used as the motion vector of the sub-block. For this purpose, a motion compensation interpolation filter may be applied.
[0088] The size of the sub-block for which affine motion compensation is performed may be set in various ways. According to one embodiment of the present invention, the sub-block can have a size that has already been set, such as 4X4 or 8X8. According to another embodiment of the present invention, the size MXN of the sub-block may be determined by the following mathematical formula 6.
[0089]
Equation
[0090] Here, w is the width of the current block, and MvPre is the fractional unit accuracy of the motion vector. (v2x, v2y) is the third CPMV corresponding to the lower left vertex of the current block, and according to one embodiment, it may be calculated by mathematical formula 5. max(a, b) is a function that returns the relatively larger value between a and b, and abs(x) is a function that returns the absolute value of x. Also, clip3(x, y, z) is a function that returns x when z < x, returns y when z > y, and returns z in other cases.
[0091] The decoder uses the CPMV set to obtain the motion vectors of each subblock in the current block. The decoder then uses the motion vectors of each subblock to obtain the predictors for each subblock, and combines these predictors to obtain the predictor for the current block. The decoder can then use the predictors obtained in this way to reconstruct the current block.
[0092] Figures 12 and 13 illustrate an embodiment of the present invention for obtaining a control point motion vector set for predicting the current block. According to an embodiment of the present invention, the CPMV set for predicting the current block may be obtained in various ways. More specifically, the CPMV set for predicting the current block may be obtained by referring to motion vector information sets of one or more surrounding blocks. In an embodiment of the present invention, the motion vector information may represent the motion vector of the block in question or the CPMV of the block in question. The motion vector information set represents a collection of motion vector information of one or more blocks. A surrounding block may represent a block that includes a previously set surrounding position of the current block. In this case, the surrounding block may be a coding unit that includes a previously set surrounding position, or a previously set area (e.g., 4x4, 8x8) that includes the said surrounding position.
[0093] There may be multiple candidates that can be referenced to guide the CPMV of the current block. Therefore, information about the surrounding blocks referenced to guide the CPMV of the current block may be signaled separately. According to one embodiment of the present invention, an indicator may be signaled that indicates a set of motion vector information to be referenced to guide the motion vectors of each subblock in the current block. The indicator can indicate a set of motion vector information of a surrounding block referenced to guide the motion vectors of each subblock in the current block. The decoder can obtain the indicator and obtain each CPMV of the CPMV set for the current block by referencing the set of motion vector information of the surrounding block indicated by the indicator. According to a more specific embodiment, the decoder can generate a candidate list consisting of one or more candidate motion vector information sets. Each candidate motion vector information set constituting the candidate list is a set of motion vectors of a surrounding block that can be used to guide the motion vector information of the current block. In this case, the indicator may be an index that points to any one of the motion vector information sets in the candidate list. The CPMV of the current block can be obtained by referencing the set of motion vector information selected from the candidate list based on the indicator (i.e., the index). The following describes various examples of motion vector information set candidates that may be included in the candidate list for guiding the motion vector information (or CPMV set) of a block.
[0094] Figure 12 shows one embodiment of obtaining the CPMV set of the current block. In the embodiment of Figure 12, it is assumed that the CPMV set of the current block contains two CPMVs, namely v0 and v1. According to one embodiment of the present invention, the CPMV of the current block may be derived from the motion vectors of the surrounding blocks adjacent to the point in question. Referring to Figure 12, v0 may be derived from the motion vector of any one of the surrounding blocks A, B, and C adjacent to the point in question, and v1 may be derived from the motion vector of any one of the surrounding blocks D and E adjacent to the point in question. When the motion vectors of surrounding blocks A, B, C, D, and E are vA, vB, vC, vD, and vE, respectively, the set of motion vector information that may be included in the candidate list may be derived as shown in the following mathematical formula 7.
[0095]
number
[0096] That is, a (v0,v1) pair may be obtained, consisting of v0 selected from vA, vB, and vC, and v1 selected from vD and vE. In this case, v0 is derived from the motion vector of the block adjacent to the upper left vertex of the current block, and v1 is derived from the motion vector of the block adjacent to the upper right vertex of the current block. In an additional embodiment, motion vector scaling may be performed based on the Picture Order Count (POC) of the current block, the POC of the reference pictures of the surrounding blocks, and the POC of the reference picture of the current block.
[0097] A candidate list containing the motion vector information set candidates obtained in this manner may be generated, and an indicator indicating any one of the motion vector information sets in the candidate list may be signaled. According to an additional embodiment of the present invention, the candidate list may include motion vector information set candidates for other types of interpretation. For example, the candidate list may include motion vector information set candidates for subblock-based temporal motion vector prediction (SbTMVP).
[0098] The decoder can derive the CPMV of the current block based on a set of motion vector information obtained from a candidate list. In one embodiment, the decoder can perform affine merge prediction by using the motion vectors from the set of motion vector information obtained from the candidate list as the CPMV of the current block without separate motion vector difference values. In another embodiment, the decoder can obtain separate motion vector difference values for the CPMV of the current block. The decoder can obtain the CPMV of the current block by summing the motion vectors from the set of motion vector information obtained from the candidate list with the motion vector difference values. A separate flag or index may be signaled to indicate whether the decoder uses separate motion vector difference values for affine motion compensation of the current block.
[0099] Figure 13 shows another embodiment of obtaining the CPMV set of the current block. According to another embodiment of the present invention, the CPMV of the current block may be derived from the motion vector information of the surrounding block that has undergone affine motion compensation, i.e., from the CPMV or motion vector of the surrounding block. In this case, the surrounding block may include the left surrounding block and the upper surrounding block of the current block. Referring to Figure 13(a), the left surrounding block includes the block adjacent to the lower left vertex of the current block, i.e., left block A and lower left block D. The upper surrounding block includes the block adjacent to the upper left vertex of the current block, i.e., upper left block E, and the block adjacent to the upper right vertex of the current block, i.e., upper block B and upper right block C. The decoder checks whether the surrounding blocks have undergone affine motion compensation in the order that has already been set. If a surrounding block that has undergone affine motion compensation is found, the decoder uses the CPMV set (or motion vector) of that surrounding block to obtain the CPMV set of the current block. Referring to the embodiment in Figure 13(b), the CPMV set of left block A may be used to derive the CPMV set of the current block. In other words, the CPMV set (v0,v1) of the current block may be obtained based on the CPMV set (v2,v3,v4) of the left block A.
[0100] According to an embodiment of the present invention, information about surrounding blocks referenced to guide the CPMV of the current block may be signaled separately. In this case, the CPMV sets of the surrounding blocks of the current block may become motion vector information set candidates that constitute the aforementioned candidate list in an already set order. More specifically, the motion vector information set candidates may include a first candidate derived from the CPMV (or motion vector) of the left surrounding block of the current block, and a second candidate derived from the CPMV (or motion vector) of the upper surrounding block of the current block. In this case, the left surrounding block is the block adjacent to the lower left vertex of the current block, and the upper surrounding block is the block adjacent to the upper left vertex of the current block or the block adjacent to the upper right vertex of the current block. A candidate list containing the motion vector information set candidates thus obtained may be generated, and an indicator indicating any one of the motion vector information sets in the candidate list may be signaled. According to one embodiment, the indicator can indicate the position information of the surrounding blocks referenced to guide the motion vector of each subblock in the current block. The decoder can obtain the CPMV set of the current block by referring to the CPMV set (or motion vector) of the surrounding block indicated by the indicator.
[0101] According to an additional embodiment of the present invention, the current block's CPMV may be derived based on the CPMV of a nearby surrounding block from the point in question. For example, v0 may be obtained by referring to the CPMV of the left surrounding block, and v1 may be obtained by referring to the CPMV of the upper surrounding block. Alternatively, v0 may be obtained by referring to the CPMV of surrounding blocks A, D, or E, and v1 may be obtained by referring to the CPMV of surrounding block B or C.
[0102] Figure 14 is a diagram illustrating an affine motion compensation method according to one embodiment of the present invention. According to one embodiment of the present invention, a CPMV may be required for affine motion prediction, and a motion vector field, i.e., a motion vector for a subblock or a certain position (or pixel), may be calculated based on the CPMV. In this specification, the CPMV may be referred to as a seed vector. In this case, the CPMV may be derived based on a predictor. For example, the predictor may be determined to be the CPMV. As another example, the CPMV may be calculated based on the predictor and the difference. Specifically, the CPMV can be calculated by adding or subtracting the difference to the predictor.
[0103] According to one embodiment of the present invention, the CPMV predictor may be derived from the CPMV or MV of a surrounding affine motion compensation (MC) block (i.e., a surrounding block encoded with affine mode). For example, if a block at a previously set position is predicted to have affine motion, the encoder / decoder can derive a predictor for affine motion compensation of the current block from the CPMV or MV of that block. In one embodiment, the previously set positions may be positions A0, A1, B0, B1, and B2 shown in Figure 14. Alternatively, the previously set positions may include positions adjacent to and / or not adjacent to the current block. The encoder / decoder may also refer to the CPMV or MV of a spatially adjacent previously set position, or to a temporally adjacent previously set position. In this specification, the candidates based on the affine MC blocks described above may be called inherited candidates. Alternatively, the candidates based on the affine MC blocks described above may be called merged candidates. Furthermore, in one embodiment, when the encoder / decoder refers to a previously set position, it can refer to it in a previously set order.
[0104] Figure 15 is a diagram illustrating an affine motion compensation method according to one embodiment of the present invention. A CPMV may be required for affine motion prediction, and a motion vector field, i.e., a motion vector for a subblock or a certain position, may be calculated based on the CPMV. In this specification, the CPMV may be referred to as a seed vector. In this case, the CPMV may be derived based on a predictor. For example, the predictor may be determined to be the CPMV. In yet another example, the CPMV may be calculated based on the predictor and the difference. Specifically, the CPMV can be calculated by adding or subtracting the difference to the predictor.
[0105] According to one embodiment of the present invention, an encoder / decoder can induce a predictor for a CPMV using the MV of a surrounding block. In this case, the MV of the surrounding block may include MVs that are not affine MC blocks. For example, when the encoder / decoder induces each CPMV of the current block, it can use the MV at a previously set position for each CPMV as a predictor for the CPMV. For example, the previously set position may be a portion included in a block adjacent to that portion.
[0106] Referring to Figure 15, the encoder / decoder can determine CPMV mv0, mv1, and mv2. Here, mv0 represents the upper left CPMV, mv1 represents the upper right CPMV, and mv2 represents the lower left CPMV. According to one embodiment of the present invention, the encoder / decoder can use the MVs corresponding to already set positions A, B, and C as predictors for mv0. The encoder / decoder can also use the MVs corresponding to already set positions D and E as predictors for mv1. The encoder / decoder can also use the MVs corresponding to already set positions F and G as predictors for mv2.
[0107] When determining the CPMV mv0, mv1, and mv2 predictors according to one embodiment of Figure 15, the order in which pre-configured positions are referenced for each control point location may be predefined. For example, there may be many pre-configured positions referenced as CPMV predictors for each control point location, and possible combinations of pre-configured positions may be predefined. Candidates (or predictors) for affine MC can be derived by a method such as the embodiment of Figure 15, and such candidates may be called constructed candidates. Alternatively, such candidates may be called inter-candidates or virtual candidates. Furthermore, in the method of Figure 15, when the encoder / decoder references pre-configured positions, it may reference them according to a pre-configured order.
[0108] According to one embodiment of the present invention, the encoder / decoder can generate a candidate list of affine MCs or a candidate list of CPMVs for affine MCs in the embodiments described in Figures 12 to 15 or in combination thereof. The following mathematical formula 8 illustrates the affine motion predictor guidance method according to one embodiment of the present invention.
[0109]
number
[0110] As mentioned above, the CPMV for predicting the affine motion of the current block can be derived from the surrounding blocks whose affine motion has been predicted. In this case, mathematical formula 8 may be used. In mathematical formula 8, the MVs of the control points at the top-left, top-right, and bottom-left edges of the surrounding blocks whose affine motion has been predicted may be expressed as (v_E0x,v_E0y), (v_E1x,v_E1y), and (v_E2x,v_E2y), respectively. Also, the coordinates of the top-left, top-right, and bottom-left edges of the surrounding blocks whose affine motion has been predicted may be expressed as (x_E0,y_E0), (x_E1,y_E1), and (x_E2,y_E2), respectively. At this time, the encoder / decoder can calculate the predictor or CPMV of the current block, (v_0x,v_0y) and (v_1x,v_1y), using mathematical formula 8. Mathematical formulas 9 and 10 below illustrate an affine motion predictor induction method according to one embodiment of the present invention.
[0111]
number
[0112]
number
[0113] As mentioned above, multiple CPMVs or multiple CPMV predictors may be used for affine motion compensation. In this case, the encoder / decoder can derive other CPMVs or CPMV predictors from one CPMV or CPMV predictor. For example, the encoder / decoder can derive (or generate) two CPMVs or two CPMV predictors in the manner described above, and then derive other CPMVs or other CPMV predictors based on these.
[0114] According to one embodiment of the present invention, an encoder / decoder can induce (or generate) mv0, mv1, and mv2, which are CPMV predictors or CPMVs, at the top left, top right, and bottom left ends using mathematical formulas 9 and 10. In mathematical formulas 9 and 10, x and y represent the x-component and y-component, respectively, and the size of the current block may be w*h. The encoder / decoder can create predictors for the CPMV to perform affine MC on the current block and determine the CPMV by adding the difference to these predictors. According to one embodiment, CPMV predictors can be generated by the method described in Figures 14 and 15, and the difference of the CPMV may be signaled from the encoder to the decoder.
[0115] Furthermore, in one embodiment, there may be differences for each CPMV. Also, each difference for each CPMV may be signaled. In a 4-parameter model, two CPMVs may be used, and the MV of each CPMV may be induced by adding mvd0 and mvd1, respectively, to the predictor of each CMPV. In the case of a 6-parameter model, three CPMVs may be used, and the MV of each CPMV may be induced by adding mvd0, mvd1, and mvd2, respectively, to the predictor of each CMPV.
[0116] According to one embodiment of the present invention, the encoder / decoder can determine the motion vector difference based on the following mathematical formula 11.
[0117]
number
[0118] In mathematical formula 11, if the reference list is 0, then MvdL0[x0][y0][compIdx] may be set to lMvd[compIdx]. In this case, compIdx represents the component index and can have values of 0 or 1. If the reference list is 1, then MvdL1[x0][y0][compIdx] may be set to lMvd[compIdx].
[0119] In one embodiment, the motion vector difference may be signaled by the method described in Table 1 above, and the motion vector difference may be lMvd in mathematical formula 11. As described above, the encoder / decoder can determine the signaled mvd as the difference with respect to the predictor of CPMV, and the determined difference may be MvdL0 and MvdL1 in mathematical formula 11. In mathematical formula 11, L0 represents reference list 0 and L1 represents reference list 1.
[0120] Furthermore, according to one embodiment of the present invention, the encoder / decoder can determine the CPMV by inducing a predictor for the CPMV and adding the difference to it in order to perform affine MC on the current block. In one embodiment, the encoder / decoder can generate a predictor for the CPMV by the method described in Figures 14 and 15. The difference of the CPMV may be signaled from the encoder to the decoder. In one embodiment, the encoder / decoder can induce the CPMV based on the following mathematical formulas 12 and 13.
[0121]
number
[0122]
number
[0123] Referring to mathematical equations 12 and 13, there may be predictors for the difference for each CPMV. In one embodiment, the differences of other CPMVs may be determined based on the difference of one CPMV. This may be based on the similarity between the differences for CPMVs. That is, since the differences for CPMVs are similar to each other, if a predictor for one CPMV is determined, predictors for CPMVs can be determined using relatively less information. As an example, a difference predictor for a CPMV may be signaled, and the difference between this difference predictor and the CPMV may be signaled from the encoder to the decoder. Mathematical equation 12 assumes the use of a 4-parameter model, and mathematical equation 13 assumes the use of a 6-parameter model.
[0124] Referring to mathematical formulas 12 and 13, the encoder / decoder can determine the difference and CPMV for each CPMV based on the difference (mvd0) of mv0, which is CPMV 0. mvd0, mvd1, and mvd2 in mathematical formulas 12 and 13 may be signaled from the encoder to the decoder. Compared to the method described in Figure 15 above, the methods of mathematical formulas 12 and 13 may have different signaled values for mvd1 and mvd2, even though they use the same predictors as the method described in Figure 15 above. If the differences with the predictors for CPMV mv0, mv1, and mv2 are similar, the absolute values of mvd1 and mvd2 may be smaller when using the methods of mathematical formulas 12 and 13 compared to when using the method described in Figure 15 above, thereby effectively reducing the signaling overhead of mvd1 and mvd2. The encoder / decoder can determine the difference between the predictor of mv1 as (mvd1+mvd0) and the difference between the predictor of mv2 as (mvd2+mvd0). In mathematical formulas 12 and 13, the characters shown above with a bar represent the predictors of CPMV.
[0125] According to one embodiment of the present invention, the encoder / decoder can determine the motion vector difference based on the following mathematical formula 14. In this case, the mathematical formulas 12 and 13 described above may be applied.
[0126]
number
[0127] In one embodiment, the motion vector difference may be signaled according to Table 1 described above or Table 2 described later. The signaled motion vector difference may be lMvd in mathematical formula 14. Also, the mvd signaled in mathematical formulas 12 and 13, i.e., mvd0, mvd1, and mvd2, may be lMvd in mathematical formula 14. In mathematical formula 14, MvdLX may represent the difference between each CPMV and its predictor, i.e., (mv-mvp). In this case, as explained in mathematical formulas 12 and 13, for CPMV 0, the signaled motion vector difference can be used directly as the difference for the CPMV (MvdLX), and for other CPMVs, it can be used as the difference for the CPMV, MvdLX, based on the signaled motion vector difference (mvd1 and mvd2 in mathematical formulas 12 and 13) and the motion vector difference signaled for CPMV 0 (mvd0 in mathematical formulas 12 and 13).
[0128] In mathematical formula 14, LX can represent reference list X. compIdx represents a component index and can indicate x and y components. cpIdx can represent a control point index. cpIdx can mean 0, 1 or 0, 1, 2 as represented in mathematical formulas 12 and 13. In one embodiment, in Table 1, mathematical formula 14, and Table 2 described above, the encoder / decoder can take into account the resolution of the motion vector difference. For example, when the resolution is R, the value of lMvd*R may be used as lMvd in mathematical formula 14. Table 2 illustrates a motion vector difference syntax structure according to one embodiment of the present invention.
[0129] [Table 2]
[0130] Referring to Table 2, the motion vector difference may be coded in essentially the same way as described in Table 1 above. In this case, coding for the motion vector difference may be performed individually using cpIdx and / or the control point index.
[0131] Figure 16 shows a subblock-based temporal MVP (SbTMVP) according to one embodiment of the present invention. According to one embodiment of the present invention, an encoder / decoder can take in (or induce) motion vectors of temporally adjacent blocks on a subblock basis. For example, an encoder / decoder can take in motion vectors corresponding to the subblock of the current block from another picture. Here, the block may be a CU, and the subblock may be a sub-CU. The other picture may be a collocated picture. In the present invention, the SbTMVP may also be called a subblock-based temporal merge candidate, or ATMVP (alternative temporal motion vector prediction).
[0132] According to one embodiment of the present invention, when SbTMVP mode is applied, the encoder / decoder can search for a block corresponding to the current block (which may be called a corresponding block or reference block) from another picture. In this case, the corresponding block may be called a collocated block. In one embodiment, the collocated block may be determined to be a block in another picture that corresponds to a pre-defined position, such as the lower right corner or the center of the current block. In SbTMVP, the collocated block may be a motion-compensated block. For example, the encoder / decoder can search for the collocated block by referencing motion vectors around the current block.
[0133] Referring to Figure 16, a collated block may be determined (or guided) to be a block located in another picture that is moved from the current block's position by the amount of the motion vector at position A1 among the surrounding blocks of the current block. In one embodiment, the motion vector that points to (or directs to) the collated block may be guided based on the motion vectors of candidates searched by scanning the already set positions around the current block in a set order. In yet another embodiment, the motion vector that points to the collated block may be determined based on a part of a merge candidate list. For example, an encoder / decoder can determine the collated block using the first merge candidate in the merge candidate list.
[0134] Furthermore, according to one embodiment of the present invention, the encoder / decoder can determine (or induce) the motion information of the current block's subblock from the motion information of the subblock of the collated block. In this specification, the motion vector can mean motion information including the motion vector, reference index, and whether or not a reference list is used, regardless of its representation. Also, the collated block's subblocks that form the basis of the current block's subblock's motion information may have the same relative position within the block (CU). That is, both subblocks can have the same relative position within the block.
[0135] Furthermore, according to one embodiment of the present invention, when SbTMVP is used, the subblock size may be fixed to a predetermined size. For example, it may be fixed to an 8x8 size. In another embodiment, the subblock size may be variable. In this case, sequence, picture, slice, CTU, or CU unit signaling may exist to determine the variable subblock size. For example, the subblock size may be variably determined to be a 4x4 or 8x8 size.
[0136] Figure 17 illustrates a planar MVP according to one embodiment of the present invention. According to one embodiment of the present invention, an encoder / decoder can generate a motion vector field for each subblock of the current block using the planar MVP method. The encoder / decoder can also refer to surrounding motion vectors using the planar MVP method. Furthermore, in the planar MVP method, the encoder / decoder can determine the subblock motion vector based on a linear weighted summation using one or more surrounding motion vectors. In this case, the surrounding motion vectors may include motion information extrapolated from the motion vectors of adjacent blocks. For example, the encoder / decoder can perform the extrapolation process for the motion vector at a position below or to the right of the current block using the motion vectors of adjacent blocks.
[0137] Referring to Figure 17, the motion vector P(x,y) corresponding to the subblock of the current block may be determined based on P_h(x,y) or P_v(x,y). In Figure 17, W and H represent the width and height of the current block, respectively. In this case, P_h(x,y) may be determined based on L(-1,y) or R(W,y). L(-1,y) may be the motion vector corresponding to the subblock adjacent to the current block on the left side of the current subblock. Also, R(W,y) may be a value based on the motion vector corresponding to the upper right position of the current block and the time motion vector corresponding to the lower right position of the current block. P_v(x,y) may be determined based on A(x,-1) or B(x,H). A(x,-1) may be the motion vector corresponding to the subblock adjacent to the current block on the upper side of the current subblock. Furthermore, B(x,H) may be a weighted sum based on the motion vector corresponding to the current lower-left corner of the block and the upper-right motion vector corresponding to the current lower-right corner of the block.
[0138] Table 3 illustrates an interprediction-related syntax structure according to one embodiment of the present invention.
[0139] [Table 3A]
[0140] [Table 3B]
[0141] According to one embodiment of the present invention, the inter-prediction method may include skip mode, merge mode, inter-mode, etc. In one embodiment, the residual signal does not need to be transmitted in skip mode. Also, the same MV determination method as in merge mode may be applied in skip mode. As an example, whether or not to use skip mode may be determined by a skip flag (or syntax element). Referring to Table 3, whether or not to use skip mode may be determined by the cu_skip_flag value. The cu_skip_flag indicates whether or not skip mode is currently applied to the CU.
[0142] In one embodiment, when merge mode is applied, motion vector differences do not need to be used. In this case, the encoder / decoder can determine the motion vector based on the motion candidate index. For example, whether or not to use merge mode may be determined by a merge flag (or syntax element). Referring to Table 3, whether or not to apply merge mode may be determined by the merge flag (i.e., merge_flag) value. Also, merge mode may be used when skip mode is not used.
[0143] According to one embodiment of the present invention, the encoder / decoder can selectively use one or more candidate list sets in skip mode or merge mode. For example, the candidate list set may include a candidate list using merge candidates and / or a candidate list using subblock-based merge candidates. The merge candidates may include spatial neighboring candidates, temporal neighboring candidates, etc. The merge candidates may also include candidates that use motion vectors for the entire current block (CU). That is, they may include candidates in which the motion vectors of each subblock belonging to the current block are the same. The subblock merge candidates may include subblock-based temporal motion vectors (subblock-based MV), affine merge candidates, etc. In one embodiment, the subblock merge candidates may include candidates that use different motion vectors for each subblock of the current block (CU). In one embodiment, the affine merge candidate may represent a merge candidate that determines the CPMV of affine motion prediction without motion vector differences. The subblock merge candidate may also include a method for determining motion vectors on a subblock basis in the current block. For example, subblock merge candidates can include not only the subblock-based time-based MV and affine merge candidates mentioned earlier, but also planar MV, regression-based MV, STMVP, and others.
[0144] According to one embodiment of the present invention, in intermode, the encoder / decoder can use motion vector difference. A motion vector predictor can be determined based on a motion candidate index, and a motion vector can be determined based on the motion vector predictor and the motion vector difference. Whether or not to use intermode may be determined by whether or not other modes are used. In yet another embodiment, whether or not to use intermode may be determined by a flag (or syntax element). Table 3 assumes an example in which intermode is used when other modes, such as skip mode and merge mode, are not used. In one embodiment, intermode can include AMVP mode, affine intermode, etc. Intermode may be a mode in which the motion vector is determined based on a motion vector predictor and the motion vector difference. In affine intermode, the encoder / decoder can use motion vector difference when determining the CPMV of the affine motion prediction.
[0145] Referring to Table 3, after determining skip mode or merge mode, the encoder / decoder can decide whether to use subblock merge candidates or merge candidates. For example, the decoder can parse a merge_subblock_flag indicating whether to use subblock merge candidates if certain conditions are met. In this case, the certain conditions may be related to block size. For example, they may be conditions related to width, height, area, etc., or they may be a combination of these conditions.
[0146] Referring to Table 3, for example, the specific condition may be whether the width and height of the current block (CU) are greater than or equal to a specific value. If merge_subblock_flag is not parsed, the encoder / decoder can infer its value to be 0. If merge_subblock_flag is 1, the encoder / decoder can use a subblock merge candidate, and if it is 0, it can use a merge candidate. If a subblock merge candidate is used, the encoder / decoder can parse merge_subblock_idx, which represents the index (or syntax element) indicating a specific candidate in the candidate list (subblock merge candidate list), and if a merge candidate is used, the encoder / decoder can parse the merge index, which represents the index indicating a specific candidate in the candidate list (merge candidate list). In this case, the encoder / decoder does not need to parse if the maximum number of items in the candidate list is 1. That is, the encoder / decoder can parse the index if the maximum number of items in the candidate list is greater than 1. If merge_subblock_idx or the merge index is not parsed, the encoder / decoder can infer its value to be 0.
[0147] Table 3 above illustrates coding unit functions, and intra-prediction-related content may be omitted. Table 3 may also be an example of a case where it is determined that intra-prediction is applied.
[0148] The following describes a method for constructing a subblock merge candidate list according to one embodiment of the present invention. Subblock merge candidates are described in Table 3 above, and the method for constructing the subblock merge candidate list is described below. According to one embodiment of the present invention, the encoder / decoder can decide whether or not to add a candidate to the candidate list, taking into account the size of the current block or subblock. The above-mentioned size may be defined based on the width, height, or area of the block or subblock, etc.
[0149] In one embodiment, if there are numerous candidates that could belong to the subblock merge candidates, and the subblock sizes of these numerous candidates differ, it is possible to determine whether or not to add them to the candidate list by considering the size of the current block. Furthermore, the condition for considering the size of the current block for a given candidate can be based on the subblock size of that candidate. Here, a candidate (before being added to the candidate list) can represent any MVP method, mode, etc., and can include either an MVP or a method for creating an MV, while a candidate added to the candidate list can represent a candidate, MVP method, mode, etc. that is available for the current block.
[0150] According to one embodiment of the present invention, an encoder / decoder can decide whether or not to add a candidate to a candidate list based on the block size condition of the current block. For example, the encoder / decoder can decide whether or not to add a candidate to the candidate list based on whether or not the size of the current block is greater than or equal to a certain block size threshold. The block size condition or threshold may be determined by the subblock size of the candidate. This is because the subblock-based prediction method can improve compression efficiency by using subblock-based prediction for blocks that are larger than the subblock size or sufficiently larger than the subblock size. For example, in the case of blocks that are the same size as or smaller than the subblock size, even if subblock-based prediction is applied, motion information at the subblock level cannot be obtained, and as a result, it may not contribute to compression efficiency.
[0151] In one embodiment, when the current block size is either already set or less than the already set size, the encoder / decoder can configure a first candidate list, and when the current block is greater than or equal to the already set size, it can configure a second candidate list. Furthermore, the candidate types belonging to candidate list 2 may include the candidate types belonging to candidate list 1. For example, if the subblock size for the first mode is set to the first subblock size and the subblock size for the second mode is set to the second subblock size, the encoder / decoder can add only the second mode to the candidate list when the current block is already set to the size, and can add both the first and second modes to the candidate list when the current block is larger than the already set size. For example, the first subblock size may be 8x8 and the second subblock size may be 4x4. Also, the already set size may be 8x8. Or, the already set size may have a width (or height) of 8. As another example, the first mode may be SbTMVP and the second mode may be affine merge mode.
[0152] In one embodiment, the subblock-based merge candidate list may be constructed (or generated) in the following manner. In the following, i may first be set to 0.
[0153] - If the value (availableFlagSbCol && blockSizeCondition) is true, then subblockMergeCandList[i++] is set to SbCol. That is, SbCol may be added to the candidate list. Here, subblockMergeCandList[i++] represents the i++th subblock merge candidate in the subblock merge candidate list, and SbCol represents the subblock-based time merge candidate (or SbTMVP).
[0154] - If the value of (availableFlagA && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to A. That is, the A candidate (or the candidate at the A position) may be added as the next candidate.
[0155] - If the value of (availableFlagB && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to B. That is, the B candidate may be added as the next candidate.
[0156] - If the value of (availableFlagConst1 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const1. That is, the Const1 candidate may be added as the next candidate. Const1 represents the first candidate among the configured candidates described above.
[0157] - If the value of (availableFlagConst2 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const2. That is, the Const2 candidate may be added as the next candidate. Const2 represents the second candidate among the configured candidates described above.
[0158] - If the value of (availableFlagConst3 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const3. That is, the Const3 candidate may be added as the next candidate. Const3 represents the third candidate among the configured candidates described above.
[0159] - If the value of (availableFlagConst4 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const4. That is, the Const4 candidate may be added as the next candidate. Const4 represents the fourth candidate among the configured candidates described above.
[0160] - If the value of (availableFlagConst5 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const5. That is, the Const5 candidate may be added as the next candidate. Const5 represents the fifth candidate among the configured candidates described above.
[0161] - If the value of (availableFlagConst6 && i < MaxNumSubblockMergeCand) is true, then subblockMergeCandList[i++] is set to Const6. That is, the Const6 candidate may be added as the next candidate. Const6 represents the sixth candidate among the configured candidates described above.
[0162] According to one embodiment of the present invention, the encoder / decoder adds an SbCol candidate to a candidate list called subblockMergeCandList only if it satisfies a predefined block size condition. In one embodiment, the block size condition for determining whether or not to add an SbTMVP to the candidate list may be determined by the subblock size of the SbTMVP. For example, the block size condition may be (cbWidth>=16 && cbHeight>=16), where cbWidth represents the width of the current coding block and cbHeight represents the height of the current coding block. Also, A, B, Const1, Const2, Const3, Const4, Const5, and Const6 may be affine merge candidates. A and B are affine inheritance candidates, and ConstX (where X is one of 1 to 6) may be an affine constructed candidate.
[0163] In other embodiments, the encoder / decoder can determine whether or not to parse the candidate index based on the block size condition of the current block. For example, if there are many candidates, and all but one of the candidates are not added to the candidate list due to the block size condition and other conditions, the encoder / decoder does not need to parse the candidate index. For example, if there are two candidates that can be added to the candidate list, the encoder / decoder can determine whether or not to parse the candidate index based on the block size condition. For example, if one of the two candidates that can be added to the candidate list does not satisfy the block size condition, the encoder / decoder does not need to parse the candidate index.
[0164] Table 4 illustrates an interpretation-related syntax according to one embodiment of the present invention.
[0165] [Table 4A]
[0166] [Table 4B]
[0167] According to one embodiment of the present invention, the subblock mode can be used when the current block size is larger than the subblock size. For example, if there are many candidates that can be added to the subblock merge candidate list, and the subblock sizes of these candidates are equal, the subblock merge mode can be used when the current block size is larger than the subblock size. As a specific example, if the subblock size is 8x8 and the current block size is 16x16 or larger (or if the width or height is 16 or larger), the subblock mode can be used. Using the subblock mode can indicate whether or not flag parsing is performed to show whether or not a mode corresponding to the subblock mode is being used. The flag indicating whether or not a mode corresponding to the subblock mode is being used may be merge_subblock_flag, inter_affine_flag, etc. Explanations that overlap with those in Table 3 above are omitted in Table 4.
[0168] According to one embodiment of the present invention, referring to Table 4, the decoder can parse merge_subblock_flag and inter_affine_flag only if cbWidth>=16 and cbHeight>=16. In another embodiment, the encoder / decoder can use the subblock mode not only when the current block size is larger than the subblock size, but also when it is equal to the subblock size. This is because the motion compensation method in subblock mode may differ from that of non-subblock modes. In this specification, a subblock-based merge mode may be referred to as a subblock mode.
[0169] Table 5 illustrates an interpretation-related syntax according to one embodiment of the present invention.
[0170] [Table 5A]
[0171] [Table 5B]
[0172] According to one embodiment of the present invention, the subblock mode can be used when the width of the current block satisfies a specific condition or when the height of the current block satisfies a specific condition. For example, even if the width or height of the current block is equal to the size of one side of the subblock, if the unequal width or height is larger than the size of one side (or the size of the other side) of the subblock, a large number of subblocks may exist within the current block. Therefore, the subblock mode can be used when the width of the current block is greater than the width of the subblock, or when the height of the current block is greater than the height of the subblock. Alternatively, the subblock mode can be used when the width of the current block is greater than or equal to the width of the subblock, or when the height of the current block is greater than or equal to the height of the subblock. In Table 5, explanations that overlap with Tables 3 and 4 above are omitted. Referring to Table 5, the encoder / decoder can use the subblock merge mode when the width of the current block is 8 or more, or when the height of the current block is 8 or more. Also, when the width of the current block is 16 or more, or when the height of the current block is 16 or more, the decoder can use the affine inter mode.
[0173] Tables 6 and 7 below illustrate the subblock merge-related syntax according to one embodiment of the present invention.
[0174] [Table 6]
[0175] [Table 7]
[0176] According to one embodiment of the present invention, a signal may be given in the first unit indicating whether or not a particular mode is used. If the signaling indicates that a mode is used, the encoder can signal to the decoder which mode to actually use in the second unit belonging to the first unit. In this case, the signaling value in the first unit may determine whether or not parsing is performed on syntax elements in the second unit. For example, the first unit may be a sequence, picture, slice, tile, etc., and the second unit may be a CTU, CU, etc. In one embodiment, the particular mode may be a subblock mode. The first unit may also be called a higher-level unit, and the second unit may be called a lower-level unit.
[0177] Table 6 shows the signaling parsing process for the use of a subblock mode, assuming that the subblock sizes of the modes belonging to the subblock mode are all the same or that differences in subblock sizes are not considered. According to one embodiment of the present invention, if there are many modes belonging to a subblock mode, and there are also many usability signaling signals for the higher-level units of the modes corresponding to the subblock mode, then if at least one of the usability signaling signals for the higher-level units indicates that it is usable, then the subblock mode can be used in the lower-level unit. Furthermore, the usability signaling signals for the higher-level units may correspond to many modes. For example, when there are different modes depending on the position of the adjacent block being referenced, the usability of the higher-level units for many of these modes may be signaled. In this case, it may also be applied in combination with conditions such as block size conditions. In this specification, the usability of a subblock mode means parsing the signaling indicating whether or not the subblock mode is being used, and for this, refer to the embodiment above.
[0178] Referring to Table 6, the decoder can parse merge_subblock_flag only if at least one of sps_affine_enabled_flag and sps_sbtmvp_enabled_flag, which indicate whether affine merge mode and SbTMVP belonging to subblock merge mode are enabled, is 1.
[0179] Referring to Table 7, if the subblock sizes of the modes belonging to a subblock mode may differ, the decoder can take this into consideration and parse the syntax element indicating whether or not the subblock mode is used. According to one embodiment of the present invention, the encoder / decoder can use the subblock mode if all the usability signaling of the higher-level unit of a mode belonging to a subblock mode and the block size conditions of the mode are met. For example, if there are a first mode and a second mode belonging to a subblock mode, and a first signaling indicating whether or not the higher-level unit corresponding to the first mode is usable and a second signaling indicating whether or not the higher-level unit corresponding to the second mode is usable are used, and there is a first block size condition for the first mode and a second block size condition for the second mode, the encoder / decoder can use the subblock mode if the first signaling indicating whether or not the higher-level unit is usable and the first block size condition is met. Furthermore, if the second signaling indicating whether or not the higher-level unit is usable and the second block size condition is met, the encoder / decoder can use the subblock mode.
[0180] As an example, referring to Table 7, the syntax elements sps_affine_enabled_flag and sps_sbtmvp_enabled_flag, which indicate whether the affine merge mode and SbTMVP included in the subblock merge mode are available, respectively, may be signaled from the encoder to the decoder. In this case, the decoder parses merge_subblock_flag if the following mathematical formula 15 is satisfied. Similarly, the encoder can syntax signal merge_subblock_flag if the following mathematical formula 15 is satisfied.
[0181]
number
[0182] Table 7 also illustrates the case where the block size condition for affine merge mode is (cbWidth>=8 && cbHeight>=8) and the block size condition for SbTMVP is (cbWidth>=16 && cbHeight>=16).
[0183] Table 8 below shows syntax for other examples where the conditions in Table 7 are used.
[0184] [Table 8]
[0185] There are two sub-block modes, a first mode and a second mode, with a first signaling indicating whether a higher-level unit corresponding to the first mode is usable and a second signaling indicating whether a higher-level unit corresponding to the second mode is usable. Given that there is a first block size condition 1 for the first mode and a block size condition 2 for the second mode, if the first block size condition is included in the second block size condition (i.e., satisfying the first block size condition satisfies the second block size condition), then the encoder / decoder can use the sub-block mode as shown in the following mathematical formula 16.
[0186]
number
[0187] In other embodiments, there may be higher-level unit availability signalings that apply to all subblock modes, or higher-level unit availability signalings that apply to all subblock merge modes. In this case, the decoder can parse the lower-level unit signaling only if the higher-level unit availability signaling indicates that it is available. According to one embodiment of the present invention, the encoder / decoder can set block size conditions for using subblock modes based on the subblock size. In this case, if the subblock size is variable, the encoder / decoder can set block size conditions based on the largest of the possible subblock sizes.
[0188] Tables 9 and 10 below show the subblock merge-related syntax according to one embodiment of the present invention.
[0189] [Table 9]
[0190] [Table 10]
[0191] According to one embodiment of the present invention, a signal may be given in the first unit indicating whether a particular mode is available or not. If the signaling indicates that a mode is available, the encoder can signal to the decoder which mode to actually use in the second unit belonging to the first unit. In this case, the signaling value in the first unit may determine whether parsing is performed on syntax elements in the second unit. For example, the first unit may be a sequence, picture, slice, tile, etc., and the second unit may be a CTU, CU, etc. In one embodiment, the particular mode may be a subblock mode. The first unit may be called a higher-level unit, and the second unit may be called a lower-level unit. The higher-level unit availability signaling may correspond to multiple modes. For example, if different modes exist depending on the adjacent block position being referenced, there may be higher-level unit availability signaling for multiple of these modes.
[0192] According to one embodiment of the present invention, the presence or absence of candidate index parsing can be determined by referring to a higher-level unit availability signaling. For example, if one or more of the numerous higher-level unit availability signalings indicate that it is available, the candidate index can be parsed. In one embodiment, there may be multiple higher-level unit availability signalings corresponding to multiple modes (in which case, the mode may represent a unit included as a candidate in the candidate list). In this specification, the multiple higher-level unit availability signalings corresponding to these modes can be indicated by a first flag, a second flag, a third flag, etc. There may also be a higher-level unit availability signaling corresponding to a single mode (a candidate; a unit that can occupy one position in the candidate list). In this specification, the higher-level unit availability signaling corresponding to a single mode can be referred to as the A flag, the B flag, and the C flag.
[0193] According to one embodiment of the present invention, if at least one of the higher-level unit availability signalings corresponding to a number of modes indicates that it is available, the encoder / decoder can parse the candidate index. That is, when (first flag || second flag || third flag, ...) (i.e., flag value 1 indicates that it is available), the encoder / decoder can parse the candidate index.
[0194] Furthermore, if there are zero or one higher-level unit availability signalings corresponding to a single mode, or if there are zero or one mode without any higher-level unit availability signalings, and at least one of the higher-level unit availability signalings corresponding to multiple modes indicates that it is available, then the encoder / decoder can parse the candidate index. That is, when (first flag || second flag || third flag, ...) (when flag value 1 indicates availability), the encoder / decoder can parse the candidate index.
[0195] If there is one higher-level unit availability signaling corresponding to one mode, and one mode that does not have a higher-level unit availability signaling, then if the higher-level unit availability signaling corresponding to the one mode indicates that it is available, the encoder / decoder can parse the candidate index. In this case, it is not necessary to consider the values of the higher-level unit availability signaling corresponding to multiple modes. Therefore, in such a case, if at least one of the higher-level unit availability signalings corresponding to multiple modes and the higher-level unit availability signaling corresponding to one mode indicates that it is available, the encoder / decoder can parse the candidate index. That is, when (1st flag || 2nd flag || 3rd flag, ... || A flag) (when flag value 1 indicates it is available), the encoder / decoder can parse the candidate index.
[0196] If the candidate index is not parsed, the encoder / decoder can use the only candidate in the candidate list. Alternatively, if the candidate index is not parsed, the encoder / decoder can infer that the candidate index is 0.
[0197] Referring to Table 9, the affine merge mode and SbTMVP may correspond to the subblock merge mode, and the affine merge mode may be constructed from numerous candidates in this manner. Furthermore, whether or not a higher-level unit corresponding to the affine merge mode is available may be signaled by the sps_affine_enabled_flag syntax element. In such a case, if sps_affine_enabled_flag indicates that it is available, the encoder / decoder can parse the candidate index merge_subblock_idx.
[0198] According to one embodiment of the present invention, if there are two or more higher-level unit availability signalings corresponding to a single mode, the encoder / decoder can parse candidate indices if at least two of the multiple higher-level unit availability signalings corresponding to a single mode indicate that it is available. That is, when (A flag + B flag + C flag + ... >= 2) (when flag value 1 indicates availability), the encoder / decoder can parse candidate indices. In this case, there may be no modes that do not have a higher-level unit availability signaling.
[0199] If there are two or more higher-level unit availability signalings corresponding to one mode, and there are higher-level unit availability signalings corresponding to multiple modes, then the encoder / decoder can parse a candidate index if at least two of the multiple higher-level unit availability signalings corresponding to one mode indicate that it is available, or if at least one of the multiple higher-level unit availability signalings corresponding to multiple modes indicates that it is available. That is, when ((1st flag||2nd flag||3rd flag…)||(A flag + B flag + C flag +…>=2)) (when flag value 1 indicates that it is available), the encoder / decoder can parse a candidate index. In this case, it is not necessary for there to be any modes that do not have a higher-level unit availability signaling.
[0200] If there is one mode without a higher-level unit availability signaling, the candidate index can be parsed when at least one of the many higher-level unit availability signalings corresponding to that mode indicates that it is available, rather than when at least two of them indicate that it is available. That is, the encoder / decoder can parse the candidate index when it is (A flag||B flag||C flag+…) rather than (A flag+B flag+C flag+…>=2).
[0201] Referring to Table 10, the subblock merge mode can include the affine merge mode, SbTMVP, and planar MVP. The affine merge mode may consist of multiple candidates. SbTMVP may consist of one candidate. Planar MVP may consist of one candidate. In addition, the availability of the higher-level units corresponding to the affine merge mode, SbTMVP, and planar MVP may be signaled using the sps_affine_enabled_flag, sps_sbtmvp_enabled_flag, and sps_planar_enabled_flag syntax elements, respectively. In this case, if sps_affine_enabled_flag is indicated as available, or if both sps_sbtmvp_enabled_flag and sps_planar_enabled_flag are available (or if two or more of sps_sbtmvp_enabled_flag and sps_planar_enabled_flag are available), the encoder / decoder can parse the candidate index merge_subblock_idx. In this invention, indicating that both sps_sbtmvp_enabled_flag and sps_planar_enabled_flag are available may be expressed as (sps_sbtmvp_enabled_flag + sps_planar_enabled_flag >= 2).
[0202] The conditions for using SbTMVP according to one embodiment of the present invention may be derived by the following method. Hereinafter, availableFlagSbCol represents a parameter (or flag) indicating whether SbTMVP is available or not.
[0203] - If one or more of the following conditions are true, availableFlagSbCol may be set to 0.
[0204] 1) When tile_group_temporal_mvp_enable_flag is 0.
[0205] 2) When sps_sbtmvp_flag is 0.
[0206] 3) When cbWidth is less than 8.
[0207] 4) When cbHeight is less than 8.
[0208] According to one embodiment of the present invention, whether or not SbTMVP is available may be expressed by an availability flag. The availability flag indicating whether or not SbTMVP is available may be availableFlagSbCol. SbTMVP can also be called SbCol. Furthermore, if the availability flag is 1, it indicates that it is available, and if the availability flag is 0, it indicates that it is not available.
[0209] According to one embodiment of the present invention, there may be conditions under which SbTMVP cannot be used. In one embodiment, SbTMVP may be unusable based on the higher-level unit signaling described above. Currently, the higher-level unit for a block or CU or PU may be a slice, tile, tile group, sequence, picture, CTU, etc. The higher-level unit signaling may include tile_group_temporal_mvp_enable_flag. For example, tile_group_temporal_mvp_enable_flag represents a flag indicating whether or not time motion vectors (or time motion vector prediction) are enabled. Since SbTMVP may be a technique that uses time motion vectors, SbTMVP may be unusable if the use of time MV is not set to enabled. The higher-level unit signaling may also include sps_sbtmvp_flag. For example, sps_sbtmvp_flag may be a flag indicating whether or not SbTMVP can be used.
[0210] In other embodiments, SbTMVP may be unavailable based on the block size. The block size may include the width of the block, the height of the block, or a value based on the width or height of the block. The value based on the width or height of the block may include the area of the block. SbTMVP may be unavailable if the width or height of the block is smaller than a critical value. In one embodiment, the critical value may be the width or height of a subblock. For example, the critical value may be set to 8.
[0211] If the conditions for not being able to use SbTMVP as described above are met, the encoder / decoder can set the availability flag corresponding to SbTMVP to 0. Otherwise, it can perform additional actions to determine the availability flag.
[0212] Figure 18 shows a method for determining a temporary motion vector according to one embodiment of the present invention. In this specification, the motion vector representing the aforementioned collated block is referred to as a temporary motion vector. The temporary motion vector is not limited to its name and may be called an initial motion vector, a time motion vector, a subblock-based temporal merging base motion vector (subblock-based temporal merging base MV), or a base motion vector. That is, the encoder / decoder can determine a motion vector that identifies the aforementioned collated block based on the initial motion vector, time motion vector, subblock-based temporal merging base motion vector, or base motion vector.
[0213] According to one embodiment of the present invention, an encoder / decoder can determine a temporary motion vector based on motion information of the current block's position. The current block's position may be a previously set position. The current block's position may also include spatial candidate positions of merge candidates. Alternatively, the current block's position may include spatial candidate positions of AMVP candidates.
[0214] Referring to Figure 18, the positions corresponding to A0, A1, B0, B1, and B2 may already be set. Also, these positions can represent brightness positions. If the current top-left corner position of a block is (xCb, yCb), then A0, A1, B0, B1, and B2 may be (xCb-1, yCb+cbHeight), (xCb-1, yCb+cbHeight-1), (xCb+cbWidth, yCb-1), (xCb+cbWidth-1, yCb-1), and (xCb-1, yCb-1), respectively. In this case, cbWidth and cbHeight may be the width and height of the current block, respectively. Also, (xCb, yCb) may be the top-left corner position of the shared merge list area. When many blocks use the same merge candidate list, the areas of those many blocks may be the shared merge list area. Furthermore, there may already be a set reference sequence corresponding to an already set position. Table 11 below provides examples of such already set reference sequences.
[0215] [Table 11]
[0216] Referring to Table 11, the already set positions may be predefinedPosition1, predefinedPosition2, ..., predefinedPositionN, etc. Also, the reference order may already be set in the order predefinedPosition1, predefinedPosition2, ..., predefinedPositionN. The said reference order may be in the forward or reverse direction of the reference order of the merge candidate list construction. Or, the said reference order may be in the forward or reverse direction of the reference order of the AMVP candidate list construction. For example, the reference positions and reference order may be A1, B1, B0, A0. Or, predefinedPosition1, predefinedPosition2, ..., predefinedPositionN may represent motion information corresponding to the already set positions.
[0217] In Table 11, the temporary motion vector may be set to the zero motion vector. Also, if motion information for an already set position is unavailable, the encoder / decoder can set the temporary motion vector to the zero motion vector. Also, if motion information for an already set position is available, the motion information for that already set position can be set to the temporary motion vector. Furthermore, "available" can include cases where the position in question is not intra-predicted. Or, "available" can include cases where the position in question is inter-predicted. Or, "available" can include cases where the reference picture of the motion information for the position in question is the same as the collated picture corresponding to the current block. Or, "available" can include cases where the reference picture of the motion information for the position in question is the same as the reference picture corresponding to the current block.
[0218] Table 11 checks whether the second usable condition is met for the motion information of the first position among the already set positions that satisfies the first usable condition 1. If the second usable condition is met, the encoder / decoder can set the motion information of that position as a temporary motion vector. Otherwise, the encoder / decoder can set the temporary motion vector as a zero motion vector. This can be represented in pseudocode as shown in Table 12.
[0219] [Table 12]
[0220] In the above embodiment, in order to make only the first of the already set positions that satisfy the first usable condition available for use as a temporary motion vector, the else if statement in Table 12 above may be used. Also, the first and second usable conditions may mean the above-mentioned usability. For example, the first usable condition may mean that the position in question used interpretation. The second usable condition may mean that the reference picture of the motion information of the position in question is the same as the collated picture corresponding to the current block. In the above embodiment, if a certain position satisfies the first usable condition but does not satisfy the second usable condition, it is not necessary to check the positions referenced after that position.
[0221] In other embodiments, the encoder / decoder can set the motion information of the first applicable position among the already set positions that satisfies both the first and second usable conditions as a temporary motion vector. Otherwise, the encoder / decoder can set the temporary motion vector as a zero motion vector. This can be represented in pseudocode as shown in Table 13 below.
[0222] [Table 13]
[0223] In Table 13, if a certain position satisfies the first usable condition but does not satisfy the second usable condition, the encoder / decoder can also check positions that are referenced after the aforementioned position.
[0224] Furthermore, according to one embodiment of the present invention, there may be only one already set position. Such a case can be represented by pseudocode as shown in Table 14 below.
[0225] [Table 14]
[0226] In other words, the encoder / decoder can set a temporary motion vector to the motion information if motion information corresponding to one of the already set positions is available, and if not, it can set the temporary motion vector to a zero motion vector. In one embodiment, the one already set position may be the left position of the current block. That is, the x-coordinate of the one already set position may be smaller than the left coordinate inside the current block. For example, the one already set position may be position A1.
[0227] In the embodiments described above, an example was shown in which two types of usability conditions, a first usability condition and a second usability condition, are used. However, the present invention is not limited thereto and can include cases where more usability conditions exist. Furthermore, motion information can include motion vectors (mvLX), reference indexes (refIdxLX), prediction utilization flags (predFlagLX), and the like.
[0228] Furthermore, in one embodiment, the process of confirming the second usability condition and setting the temporary motion vector may be carried out as follows. That is, if availableFlagN is true, the following process may be applied.
[0229] A. If all of the following conditions are true, the temporary motion vector may be set to mvL1N.
[0230] a. When predFlagL1N is 1
[0231] b. When DiffPicOrderCnt(ColPic,RefPicList1[refIdxL1N]) is 0
[0232] c. When DiffPicOrderCnt(aPic,currPic) is less than or equal to 0, aPic represents all pictures in the entire reference picture list of the slice (or, tile group)
[0233] d. When tile_group_type is equal to B
[0234] e. When collocated_from_l0_flag is equal to 0
[0235] B. Otherwise, if all of the following conditions are true, the temporary motion vector may be set to mvL0N.
[0236] a. When predFlagL0N is 1
[0237] b. When DiffPicOrderCnt(ColPic,RefPicList0[refIdxL0N]) is 0
[0238] Here, availableFlagN being true can indicate that the first available condition is met. In an example that uses only one of the previously described set positions, the parameter that can become availableFlagN may be the availableFlag corresponding to the previously set position. For example, when using only position A1, availableFlagN may be availableFlagA1, which may be a value indicating whether the motion information at position A1 can be used.
[0239] Figure 19 illustrates the presence or absence of SbTMVP use according to one embodiment of the present invention. According to one embodiment of the present invention, the encoder / decoder can determine whether or not to use a particular mode based on the current position of block 1901. According to yet another embodiment of the present invention, the encoder / decoder can determine whether or not to use a particular mode based on the current position of the merge list shared region to which block 1901 belongs.
[0240] According to one embodiment of the present invention, an encoder / decoder can determine whether or not to use SbTMVP based on the current position of block 1901. According to yet another embodiment of the present invention, it is possible to determine whether or not to use SbTMVP based on the position of the merge list shared area to which the current block 1901 belongs. In one embodiment, the position of the current block 1901 or the position of the merge list shared area to which the current block belongs may be expressed as top-left coordinates or relative to top-left coordinates. Alternatively, the position of the current block 1901 or the position of the merge list shared area to which the current block 1901 belongs may be a relative position within a higher group. The higher group may include pictures, tiles, tile groups, CTUs, slices, etc. Alternatively, the higher group may be the group to which the current block belongs. That is, for example, an encoder / decoder can determine whether or not to use SbTMVP based on the position of the current block 1901 within picture 1902. In this specification, the current block or the merge list shared area of the current block may be referred to as the current area.
[0241] According to one embodiment of the present invention, the encoder / decoder can decide whether or not to use SbTMVP based on whether or not the current region is touching the boundary of a higher group. For example, if the current region is touching the boundary of a higher group, it can be determined that SbTMVP should not be used. Alternatively, it can be determined whether or not to use SbTMVP based on whether the already set positions referenced to determine the temporary motion vector corresponding to the current region, as explained in Figure 19, are outside the higher group. For example, if all the already set positions referenced to determine the temporary motion vector corresponding to the current region are outside the higher group, the encoder / decoder can be determined that SbTMVP should not be used. Furthermore, whether or not all the already set positions referenced to determine the temporary motion vector corresponding to the current region are outside the higher group may be determined based on the coordinates of the current region. This is because, according to the embodiment described above, if all the already set positions referenced to determine the temporary motion vector corresponding to the current region are outside the higher group, a zero motion vector is used as the temporary motion vector, which can reduce the prediction performance of SbTMVP. Furthermore, in one embodiment, by deciding that SbTMVP cannot be used in this case, other modes that signal with the same syntax elements as SbTMVP can be signaled using fewer bits. For example, as mentioned above, SbTMVP and affine merge mode may be included in subblock merge mode, and if it is decided that SbTMVP cannot be used, affine merge mode can be signaled using fewer indices. Therefore, in such a case, index 0 can always indicate affine merge mode.
[0242] Referring to Figure 19, as mentioned above, only position A1 1903 can be referenced to determine the temporary motion vector of the current region. If the motion information of position A1 1903 is unavailable, the zero motion vector can be used as the temporary motion vector. If the current region touches the left boundary of picture 1902, the temporary motion vector can always be the zero motion vector. Therefore, if the current region touches the left boundary of picture 1902, SbTMVP can be deemed not to be used. In addition to the left boundary of picture 1902, if the region touches the left boundary of a parallelizable unit, SbTMVP can also be deemed not to be used. Parallelizable units can include tiles, tile groups, slices, etc. Therefore, if the top-left coordinate of the current region is (xCb, yCb), and xCb is 0, the encoder / decoder can be the one touching the left boundary of picture 1902, and in this case, it can be determined not to use SbTMVP. Alternatively, if (xCb - (left-hand coordinate of the parallelizable unit)) is 0, SbTMVP may be not used.
[0243] Furthermore, in one embodiment, if only the upper edge of the current region is referenced to determine the temporary motion vector of the current region, the encoder / decoder can be set not to use SbTMVP when the current region touches the upper boundary of picture 1902 or a parallelizable unit.
[0244] In other additional embodiments, the conditions under which it is decided not to use SbTMVP have been described. However, in addition to these conditions, SbTMVP may also be not used only if the conditions related to block size are met. That is, for example, SbTMVP may be not used if the coordinates of the current region meet the already set conditions and the conditions related to block size are met. In one embodiment, the condition related to block size may be that the block size of the current block is less than or equal to the subblock size. This is because when the current block size is less than or equal to the subblock size, the current block has only one subblock, and in this case, the advantages and performance of SbTMVP may be reduced. For example, the subblock size may be 8x8. Therefore, in the embodiments described, the following embodiments may be derived. If the current region is adjacent to the left boundary of the picture and the current block is 8x8 or less, the encoder / decoder can decide not to use SbTMVP. However, there may be embodiments in which the subblock merge mode can only be used with blocks of 8x8 or larger. In this case, if the current area is adjacent to the left boundary of picture 1902 and block 1901 is currently 8x8, it can be determined that SbTMVP should not be used.
[0245] Furthermore, in other embodiments of the present invention, the availability flag indicating the conditions for SbTMVP use may include, in addition to the conditions described above, whether xCb is 0 and the current block width and height are 8. That is, if xCb is 0 and the current block width and height are 8, the availability flag may be set to 0. If all of the above conditions and the conditions described above are met, or if one or more of them are met, the encoder / decoder can set the availability flag to 0. As described above, whether SbTMVP is usable or not may be indicated by the availability flag. Also, when certain conditions are met, it can be indicated that SbTMVP is unavailable. That is, when certain conditions are met, the encoder / decoder can set availableFlagSbCol to 0. Therefore, according to the embodiment described in Figure 19, the encoder / decoder can set availableFlagSbCol based on the position of the current region. That is, the encoder / decoder can set availableFlagSbCol based on the coordinates (xCb, yCb) representing the current region. For example, (xCb, yCb) may be the coordinates of the top-left corner of the current region.
[0246] As explained in Figure 19, SbTMVP may be unavailable if the current region or current block is adjacent to the left boundary of the picture. Therefore, if xCb is 0, the encoder / decoder can set avilableFlagSbCol to 0. For example, if the current region or current block is adjacent to the left boundary of the picture and the current block is 8x8, SbTMVP may be unavailable. Therefore, if xCb is 0 and the width and height of the current block are both 8, the encoder / decoder can set avilableFlagSbCol to 0.
[0247] Table 15 illustrates a subblock merge mode syntax structure according to one embodiment of the present invention.
[0248] [Table 15]
[0249] As described above, the sub-block merge mode (or sub-block-based merge mode) can include SbTMVP and / or the affine merge mode. Also, a syntax element (or flag) sps_affine_enabled_flag indicating whether the affine mode can be used may be signaled from the encoder to the decoder using the upper-level syntax. As an example, the upper level may be at least one of the sequence, picture, slice, or CTU level. Also, in one embodiment, as described in FIG. 19 above, conditions where SbTMVP cannot be used (or applied) may be predefined.
[0250] According to one embodiment of the present invention, when the condition where SbTMVP cannot be used is satisfied and the affine mode is not available, the encoder / decoder may not need to parse the merge_subblock_flag. For example, the merge_subblock_flag may be signaling indicating the use of the sub-block merge mode. If the merge_subblock_flag does not exist, the encoder / decoder can infer its value as 0. When the affine mode is not available, the sps_affine_enabled_flag may be 0. Therefore, the merge_subblock_flag can be parsed when SbTMVP can be used or when the affine mode is available. Also, the condition for parsing the merge_subblock_flag can include additional conditions in addition to the conditions described above. For example, referring to Table 15, conditions related to MaxNumSubblockMergeCand indicating the maximum number of sub-block merge candidates and conditions related to the block size may both be considered to determine the parsing of the merge_subblock_flag.
[0251] Referring to Table 15, if x0, which is the x-value of the top-left coordinate of the current block, is 0, and sps_affine_enabled_flag, which indicates whether affine mode is available, is 0, then it is not necessary to parse merge_subblock_flag. On the other hand, if x0 is not 0, or sps_affine_enabled_flag is 1, then merge_subblock_flag can be parsed.
[0252] Furthermore, although the above-described embodiment assumed that the subblock merge mode includes SbTMVP and affine merge mode, the present invention is not limited thereto, and the subblock merge mode may include other modes. For example, the subblock merge mode may include a first mode and a second mode in addition to SbTMVP. Also, syntax elements sps_mode1_enabled_flag and sps_mode2_enabled_flag, which indicate whether the first mode and the second mode are available or not, may be signaled. In this case, if the condition for disabling SbTMVP is met, and neither the first mode nor the second mode is available, the encoder / decoder does not need to parse merge_subblock_flag. In this case, the encoder / decoder can infer merge_subblock_flag to be 0. As one embodiment, if the condition for disabling SbTMVP is not met, or if the first mode is available, or if the second mode is available, the encoder / decoder can parse merge_subblock_flag. Furthermore, the conditions for parsing merge_subblock_flag may include other conditions in addition to those mentioned above. Referring to Table 15, conditions related to MaxNumSubblockMergeCand, which indicates the maximum number of subblock merge candidates, and conditions related to the block size may both be considered in determining the parsing of merge_subblock_flag.
[0253] Furthermore, according to one embodiment of the present invention, if affine mode is not enabled, the encoder / decoder can set MaxNumSubblockMergeCand to 1. Alternatively, if affine mode is not enabled and SbTMVP is enabled, the encoder / decoder can set MaxNumSubblockMergeCand to 1. Also, if affine mode is not enabled and SbTMVP is not enabled, the encoder / decoder can set MaxNumSubblockMergeCand to 0.
[0254] Figure 20 illustrates an SbTMVP induction method according to one embodiment of the present invention. According to one embodiment of the present invention, the already set position referenced to determine the temporary motion vector may be variable. Alternatively, the already set position referenced to determine the temporary motion vector for a particular block may be set to one position, and that position may be variable.
[0255] In one embodiment, the reference position for determining the temporary motion vector based on the current block 2001 or the current region may be determined variably. The current region represents the region described in Figure 19 above. For example, if the current region is adjacent to the boundary of picture 2002 or the boundary of a parallelizable unit, motion information at a particular position may always be unavailable. Therefore, the encoder / decoder can set a position other than the always unavailable position as a pre-set position to reference for determining the temporary motion vector. That is, the pre-set position to reference for determining the temporary motion vector may be set to a position that is not always unavailable, based on the current region's position. The always unavailable position may be a position outside of picture 2002 or the parallelizable range.
[0256] According to the embodiment described in Figure 18 above, the already set position referenced to determine the temporary motion vector may be defined as the left-side position of the current block 2001 or the current region. In this case, as described in Figure 19 above, if the current block 2001 or the current region is in a specific position, the motion information of the already set position is unavailable, so such an already set position can be set (or determined) to a position other than the left-side position. For example, the already set position may be set to the upper position 2003 of the current block 2001 or the current region. For example, the already set position may be position B1 in Figure 18(a).
[0257] Furthermore, in one embodiment, referring to Figure 20, if the current block 2001 or current region is touching the left boundary of picture 2002 or the left boundary of a parallelizable unit, the already set position referenced to determine the temporary motion vector may be determined to be the upper position of the current block 2001 or current region. The upper position of the current region can mean a position whose y-coordinate is relatively smaller than the y-coordinate (i.e., vertical coordinate) of the current region. For example, if the current block 2001 or current region is touching the left boundary of picture 2002 or the left boundary of a parallelizable unit, the already set position referenced to determine the temporary motion vector may be position B1 in Figure 18(a).
[0258] Alternatively, in one embodiment, if the current block 2001 or current region is touching the upper boundary of picture 2002 or the upper boundary of a parallelizable unit, the already set position referenced to determine the temporary motion vector may be determined to be the left position of the current block 2001 or current region. The left position of the current region can mean a position whose x-coordinate is relatively smaller than the x-coordinate (i.e., horizontal coordinate) of the current region. For example, if the current block 2001 or current region is touching the upper boundary of picture 2002 or the upper boundary of a parallelizable unit, the already set position referenced to determine the temporary motion vector may be position A1 in Figure 18(a).
[0259] The above describes a subblock-based motion compensation method. Below, we will describe a motion compensation method based on a merge mode (MVD, MMVD) (or merge MVD) using motion vector differences, and how to apply it in combination with the above-described embodiment of subblock-based motion compensation.
[0260] Figure 21 illustrates an MMVD application method according to one embodiment of the present invention. According to one embodiment of the present invention, an encoder / decoder can determine a motion vector (MV) based on a motion vector predictor (MVP) and a motion vector difference (MVD). In this specification, the MVP may be called the base motion vector (baseMV). That is, the encoder / decoder can derive a motion vector (i.e., the final motion vector) by adding the motion vector difference to the base motion vector. However, the present invention is not limited to such names, and the MVP may also be called the base motion vector, temporary motion vector, initial motion vector, MMVD candidate motion vector, etc. The MVD can be expressed as a value that refines the MVP, and may be called the refined motion vector (refineMV) or merged motion vector difference.
[0261] According to one embodiment of the present invention, when MMVD is applied, i.e., in MMVD mode, the MV may be determined based on the base motion vector, a (distance) parameter (or variable), and a direction parameter (or variable). Also according to one embodiment of the present invention, the base motion vector may be determined from a candidate list. For example, the base motion vector may be determined from a merge candidate list. The encoder / decoder may also determine the base motion vector from a portion of another candidate list. The portion of the candidate list may be the first portion (the one with the smaller index) of the candidate list. For example, the encoder / decoder may determine the base motion vector using the first and second candidates from the merge candidate list. To this end, a candidate index indicating a specific candidate from the two candidates may be signaled from the encoder to the decoder. Referring to Figure 21, a base candidate index, which is an index that signals the base motion vector, may be defined. The encoder / decoder can use the base candidate index to determine which candidate from the candidate list is applied to the current block, and determine the motion vector of the determined candidate as the base motion vector. In the present invention, the base candidate index is not limited to its name, and can be called a base candidate flag, candidate index, candidate flag, MMVD index, MMVD candidate index, MMVD candidate flag, etc.
[0262] Furthermore, according to one embodiment of the present invention, there may be MVDs different from the MVDs described in Figures 6 and 7. For example, the MVD in MMVD may be defined differently from the MVDs described in Figures 6 and 7. In this specification, MMVD may represent a merge mode (i.e., a motion compensation mode or method) using motion vector differences, or it may represent the motion vector difference when MMVD is applied. For example, an encoder / decoder can decide whether or not to apply (or use) MMVD. If MMVD is applied, the encoder / decoder can determine the motion vector of the current block by deriving a merge candidate from the merge candidate list to be used for interpretation of the current block, and by deriving an MMVD and applying (or adding) it to the motion vector of the merge candidate.
[0263] In one embodiment, the other MVDs can refer to simplified MVDs, MVDs with other (or lower) resolutions, MVDs with a limited number of available options, MVDs with different signaling methods, etc. For example, the MVDs used in existing AMVP and affine intermodes described in Figures 6 and 7 can represent all areas in the x and y axes (i.e., horizontal and vertical directions) with respect to a specific signaling unit (e.g., x-pel), such as picture-based areas (e.g., picture areas or areas including the picture and surrounding areas), at equal intervals, whereas the units used to represent a specific signaling unit in an MMVD may be relatively limited. Furthermore, the areas (or units) that signal the MMVD do not need to be at equal intervals. Also, an MMVD can indicate only a specific direction with respect to a specific signaling unit.
[0264] Furthermore, according to one embodiment of the present invention, the MMVD may be determined based on distance and direction. Referring to Figure 21, the distance and direction of the MMVD may already be set by a distance index indicating the distance of the MMVD and a direction index indicating the direction of the MMVD. In one embodiment, the distance may indicate the MMVD size (e.g., absolute value) in specific pixel units, and the direction may indicate the direction of the MMVD. Also, the encoder / decoder can signal relatively small distances with relatively small indices. That is, in the case of signaling that does not use fixed-length binary, the encoder / decoder can signal relatively small distances with relatively few bits.
[0265] Furthermore, according to one embodiment of the present invention, the MVD can use a signaled MV or an MV based on a signaled MV. For example, the MV based on a signaled MV may be the same as the signaled MV with the sign reversed. For example, if the MVD signaling is based on a value corresponding to a certain reference list, the value corresponding to a reference list different from the one in question can be the same as the value corresponding to the one in question (i.e., the signaled MVD) or can be used with a different sign. Whether to use it as is or with a different sign may be determined by the picture order count (POC) relationship between the current picture and the reference picture in the reference list, and the POC relationship between the current picture and the reference picture in the reference list different from the one in question. More specifically, even when both reference lists L0 and L1 are used, only one MVD may be signaled. For example, the MVD corresponding to L0 may be signaled. The MVD corresponding to L1 may then be determined based on the MVD corresponding to L0.
[0266] For example, the MVD corresponding to L1 may remain the same as the MVD corresponding to L0, or it may be a value with the sign of the MVD corresponding to L0 changed. This may be determined by the POC relationship between the current picture and the L0 reference picture, and between the current picture and the L1 reference picture. For example, whether the value of DiffPicOrderCnt(RefPicList0[refIdxLN0],currPic)*DiffPicOrderCnt(currPic,RefPicList1[refIdxLN1]) is greater than or less than 0 can be used to determine whether the MVD corresponding to L0 is used as is or modified for L1. Furthermore, if DiffPicOrderCnt(RefPicList0[refIdxLN0],currPic)*DiffPicOrderCnt(currPic,RefPicList1[refIdxLN1]) is greater than 0, it means that both the L0 referenced picture and the L1 referenced picture are either temporally earlier than the current picture or temporally later than the current picture.
[0267] Therefore, in this case, the signs of L0MVD and L1MVD may be the same. Also, if DiffPicOrderCnt(RefPicList0[refIdxLN0],currPic)*DiffPicOrderCnt(currPic,RefPicList1[refIdxLN1]) is less than 0, it may mean that one of the L0 reference picture and L1 reference picture is temporally earlier than the current picture, and the other is temporally later than the current picture. Therefore, in this case, the signs of L0MVD and L1MVD may be different. Also, being temporally earlier may mean a smaller POC, and being temporally later may mean a larger POC. Furthermore, in the embodiment described above, an MV scaling process may be added. That is, a process of MV scaling of the signaled MV or a modified signaled MV (for example, an MV with the sign reversed) may be added.
[0268] Table 16 illustrates an MMVD syntax structure according to one embodiment of the present invention.
[0269] [Table 16]
[0270] According to one embodiment of the present invention, there may be a signaling to indicate whether or not MMVD is used (or applied) as described in Figure 21 above. Referring to Table 16, the MMVD flag (i.e., mmvd_flag) represents a syntax element indicating whether or not MMVD is used. For example, MMVD may be applied to skip mode or merge mode. In one embodiment, when MMVD is used, the decoder can parse MMVD-related syntax. When MMVD is used, MMVD-related information may be further parsed from the MMVD index coding (i.e., mmvd_idx_coding) syntax.
[0271] In one embodiment, if MMVD is not used, the decoder can parse the merge index. Referring to Table 16, the merge index (i.e., merge_idx) represents a syntax element that indicates a specific merge candidate in the merge candidate list. Also, in the case of a merge mode other than skip mode, after parsing the merge flag (i.e., merge flag), if the merge flag is 1, the MMVD flag can be parsed. The merge flag can indicate whether or not a merge mode or subblock merge mode is used (or whether or not it is applied). The merge flag can also indicate that AMVP, intermode, affine intermode, etc., are not to be used. In this embodiment, the merge index may be a different index from the base candidate index described in Figure 21 above.
[0272] Furthermore, according to one embodiment of the present invention, there may be a signaling indicating the maximum number of merge candidates. The signaling indicating the maximum number of merge candidates may be performed in units larger than CU (prediction unit). For example, the signaling indicating the maximum number of merge candidates may be performed in slice or tile units. Also, if the conditions based on the signaling indicating the maximum number of merge candidates are met, the decoder can parse the merge index. In one embodiment, if the value of the syntax element indicating the maximum number of merge candidates indicates that the maximum number of merge candidates is 1, the encoder / decoder can infer a merge index of 0. That is, if the signaling indicating the maximum number of merge candidates indicates that the maximum number of merge candidates is 1, the candidates may be determined without parsing the merge index.
[0273] Furthermore, referring to Table 16, a value (variable, parameter) called MaxNumMergeCand may be defined, which is a signaling-based value (variable) representing the maximum number of merge candidates. MaxNumMergeCand can represent the maximum number of merge candidates. MaxNumMergeCand can have a value of 1 or more. In addition, the maximum number of merge candidates can be determined for a signaling unit that indicates the maximum number of merge candidates, based on the maximum number of facilitable merge candidates and the signaling that indicates the maximum number of merge candidates. For example, by subtracting the signaling value that indicates the maximum number of merge candidates from the maximum number of facilitable merge candidates, the encoder / decoder can determine the maximum number of merge candidates for a signaling unit that indicates the maximum number of merge candidates. Furthermore, although the maximum number of merge candidates has been described, the maximum number of subblock merge candidates and the maximum number signaling may exist substantially identically.
[0274] Furthermore, in one embodiment, the merge index may be parsed when using skip mode or merge mode. The decoder can parse the merge index if the conditions for using skip mode or merge mode are met. For example, if subblock merge mode is not used, the encoder / decoder can use skip mode or merge mode. In Table 16 above, the merge index may be parsed after MMVD flag parsing. This may be to give MMVD priority over existing skip mode or merge mode. Also, a subblock merge flag (i.e., subblock_merge_flag) (or merge subblock flag (i.e., merge_subblock_flag) syntax element indicating whether or not to use subblock merge mode may be signaled.
[0275] Figure 22 illustrates an MMVD-related syntax structure according to one embodiment of the present invention. The embodiments described in Table 16 above may be applied identically to Figure 22, and related and redundant explanations will be omitted. The syntax shown in Figure 22 further includes processes related to subblock merging in addition to those in Table 16. In Figure 22 and the drawings described below (i.e., Figures 23 to 31), parts relating to the intra-prediction process and inter-prediction, such as intermode, AMVP mode, and affine intermode, may be omitted. For the sake of explanation, Figure 22 will focus on the decoder, but the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0276] According to one embodiment of the present invention, the decoder can parse the subblock merge flag before the MMVD flag and / or merge index. This is for the purpose of prioritizing the subblock merge mode over at least one of the skip mode, merge mode, and / or MMVD. The decoder can parse the MMVD flag and / or merge index, etc., when the subblock merge mode is not used. For example, the decoder can parse the subblock merge flag before the MMVD flag, and if the subblock merge mode is not applied, it can parse the MMVD flag. Because the subblock merge mode performs motion compensation in relatively small subblock units, the accuracy of motion prediction can be increased, and due to the characteristics of subblock-based motion compensation, improving MV using a single MVD may not be effective. Therefore, according to an embodiment of the present invention, compression efficiency can be increased by checking whether MMVD is applied only when the subblock merge mode is not applied, and this objective can be achieved by setting the parsing order of syntax (or syntax elements) (i.e., by parse the subblock merge flag before the MMVD flag).
[0277] Figure 23 illustrates an MMVD-related syntax structure according to one embodiment of the present invention. The syntax (or function) shown in Figure 23 can represent the syntax for parsing MMVD information as shown in Table 16, Figure 22, and the MMVD-related syntax described below. As explained in Figure 21 above, the MMVD may be determined based on the base motion vector, distance, and direction. An index (or syntax element) for signaling such information may be defined. Referring to Figure 23, the syntax elements for signaling the base motion vector, distance, and direction may be defined as base_mv_idx, distance_idx, and direction_idx. As explained in Table 16 and Figure 22, if it is decided to use MMVD, the syntax elements in Figure 23 that indicate specific MMVD values may be signaled from the encoder to the decoder. Although Figure 23 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0278] Figure 24 illustrates an MMVD-related syntax structure according to one embodiment of the present invention. The syntax (or function) shown in Figure 24 can represent the syntax for parsing MMVD information as shown in Table 16, Figure 22, and the MMVD-related syntax described below. According to one embodiment of the present invention, some of the MMVD-related syntax can be parsed if certain predefined conditions are met. For example, after it has been decided to use MMVD, if the aforementioned predefined conditions are met, the decoder can parse some of the MMVD-related syntax. In one embodiment, some of the MMVD-related syntax may be base motion vector-related signaling. The decision to use MMVD may be based on the MMVD flag value. It may be decided to use MMVD if the MMVD flag is parsed or if the MMVD flag is inferred to show a specific value (e.g., 1). Although Figure 24 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0279] Furthermore, according to one embodiment of the present invention, the aforementioned specific condition may relate to the maximum number of possible base motion vector candidates. For example, the decoder may parse the base motion vector-related syntax if the maximum number of possible base motion vector candidates is 2 or more, but may not parse the base motion vector-related syntax if the maximum number of possible base motion vector candidates is 1. When no base motion vector-related syntax exists, the decoder can infer its value. In this case, the base motion vector-related syntax may be inferred to be 0. If a base motion vector candidate is a merge candidate, the decoder can decide whether or not to parse the base motion vector-related syntax based on a condition derived from the maximum number of possible merge candidates.
[0280] As mentioned above, the maximum number of possible base motion vector candidates is the value indicated by the signaling that shows the maximum number of merge candidates as described in Table 16, and this value may be expressed as MaxNumMergeCand.
[0281] Referring to Figure 24, the decoder can parse the base motion vector index only if MaxNumMergeCand, which represents the maximum number of merge candidates, is greater than 1. If the base motion vector index does not exist, for example, because it has not been parsed, the decoder can infer its value to be 0. If the maximum number of possible candidates is 1, the index can be determined without signaling it.
[0282] Figure 25 illustrates an MMVD syntax according to one embodiment of the present invention. In the syntax structure described in Figure 22, the MMVD flag is always parsed even when skip mode or merge mode is used instead of MMVD. Also, the base motion vector index or merge index is parsed in both cases, whether MMVD is used or not. On the other hand, in the embodiment of Figure 25, the MMVD flag may not be parsed even when skip mode or merge mode is used instead of MMVD. For the sake of explanation, Figure 25 focuses on the decoder, but the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0283] According to one embodiment of the present invention, the base motion vector-related syntax and the merge index may be defined as having the same value. For example, the base motion vector index and the merge index may be the same. That is, signaling to indicate the corresponding candidate may be performed with a single syntax element. Furthermore, according to one embodiment of the present invention, the decoder can parse the base motion vector-related syntax and parse the MMVD flag depending on the conditions. When the MMVD flag indicates the use of MMVD, the decoder can parse MMVD-related syntax other than the base motion vector-related syntax.
[0284] For example, after parsing the merge index, it is possible to distinguish whether the corresponding candidate is available for use in MMVD. If it is available for use in MMVD, the MMVD flag is parsed; if it is not available for use in MMVD, the MMVD flag does not need to be parsed. Also, if the MMVD flag does not exist, it can be inferred that MMVD will not be used. For example, if the base motion vectors of the MMVD can match up to num_mmvd_baseCand at the beginning (smaller index) of the merge candidate list, the MMVD flag is parsed if the parsed index is smaller than num_mmvd_baseCand; otherwise, the MMVD flag is not parsed, and it can be decided that MMVD will not be used. In this case, if candidate indices greater than or equal to num_mmvd_baseCand are used, there is the advantage of saving bits for the MMVD flag.
[0285] Referring to Figure 25, after parsing the merge index, if the merge index is smaller than num_mmvd_baseCand, the MMVD flag is parsed. num_mmvd_baseCand may be the number of possible candidates for the MMVD base motion vector. Furthermore, the MMVD base motion vector index may be determined based on the merge index.
[0286] Figure 26 illustrates an MMVD syntax according to one embodiment of the present invention. Referring to Figure 26, the MMVD flag may be higher in the syntax structure than the merge flag. For example, the decoder can decide whether or not to parse the merge flag based on the MMVD flag. This can be applied, for example, when not in skip mode. Although Figure 26 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0287] According to one embodiment of the present invention, if the MMVD flag indicates the use of MMVD, the merge flag does not need to be parsed. For example, if the base motion vector candidate for MMVD is determined from the merge candidates, and the MMVD flag indicates the use of MMVD, the decoder does not need to parse the merge flag. When using MMVD (when the MMVD flag is 1), the merge flag can be inferred to mean that merge mode is being used. Referring to Figure 26, when skip mode is being used, i.e., when cu_skip_flag is 1, the decoder can infer the merge flag to be 1 regardless of whether MMVD is being used or not. Also, if the merge flag does not exist and skip mode is not being used, the decoder can infer the merge flag to be 1 when using MMVD, and to be 0 when not using MMVD. Alternatively, in one embodiment, if the merge flag does not exist and skip mode is not being used, the decoder can infer the merge flag to be 1. Also, referring to Figure 26, when not in skip mode, the decoder parses MMVD-related syntax if the MMVD flag is 1, and parses the merge flag if the MMVD flag is not 0.
[0288] According to one embodiment of the present invention, if the subblock merge flag is higher than the merge flag, and the subblock merge flag is 1, the merge flag does not need to be parsed and can be inferred to be 1. Also, if the subblock merge flag is higher than the MMVD flag, and the subblock merge flag is 1, the MMVD flag does not need to be parsed and can be inferred to be 0. Furthermore, in this specification, a modeX_flag of 1 means that modeX is used, and a modeX_flag of 0 means that modeX is not used.
[0289] Figure 27 illustrates an MMVD syntax according to one embodiment of the present invention. According to one embodiment of the present invention, in a candidate list used as a base motion vector candidate for MMVD, MMVD can always be used for some of the candidates. For example, when the base motion vector candidate for MMVD is determined from a merge candidate list, MMVD can always be used for some of the merge candidate list. For example, MMVD can always be used for a defined candidate index. For example, MMVD can always be used when the candidate index is smaller than an already set value. In this case, it is possible to determine whether or not to use MMVD from the candidate index. Furthermore, MMVD flag parsing may not be required.
[0290] For example, after parsing the merge index, if the merge index falls within a value that specifies the use of MMVD, it can be determined that MMVD should be used. In such cases, MMVD-related syntax (e.g., distance, direction signaling, etc.) can also be parsed. Although Figure 27 focuses on the decoder for illustrative purposes, the coding process in this embodiment can be applied to the encoder in substantially the same way. Referring to Figure 27, MMVD can always be used up to num_mmvd_baseCand items in the front of the merge candidate list. In such cases, if the candidate index is smaller than num_mmvd_baseCand, it can be determined that MMVD should be used, and MMVD-related syntax can be parsed.
[0291] Figure 28 illustrates an MMVD syntax according to one embodiment of the present invention. According to one embodiment of the present invention, the decoder can always use MMVD for some of the candidates in the candidate list used as the base motion vector candidate for MMVD. For example, when the base motion vector candidate for MMVD is determined from a merge candidate list, the decoder can always use MMVD for some of the merge candidate list. For example, the decoder can always use MMVD for a given candidate index. For example, MMVD can always be used when the candidate index is smaller than an already set value. Although Figure 27 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same way.
[0292] According to one embodiment of the present invention, the MMVD flag may be higher in rank than the merge flag in terms of syntax structure (or syntax parsing order). In this case, the decoder can parse MMVD-related syntax if the MMVD flag is 1. Also, if the MMVD flag is 1, the decoder can infer that the merge flag is 1. Also, if the MMVD flag is 0, the decoder can parse the merge flag. The decoder can parse the merge index if the merge flag is 1. In this case, there may be additional conditions for parsing the merge index. In this embodiment, the decoder can determine the merge index to be actually used by transforming it based on the parsed merge index. For example, the merge index to be actually used can be determined by adding the number of candidates that are smaller than the parsed merge index and are designated to always use MMVD to the parsed merge index. For example, if it is specified that MMVD should always be used for the first num_mmvd_baseCand items in the candidate list, the merge index can be the parsed merge index plus num_mmvd_baseCand. If the MMVD flag is before the merge flag, and the MMVD flag is 0, then candidates that use MMVD can be excluded from the candidate list.
[0293] Referring to Figure 27, the MMVD flag is present before the merge flag. Also, if the MMVD flag is 1, the decoder can parse MMVD-related syntax. If the MMVD flag is 0, the decoder can parse the merge flag. Furthermore, if the MMVD flag is 0 and the merge flag is 1, the decoder can parse the merge index. In this case, there may be additional conditions for parsing the merge index. Additionally, the number of candidate base motion vectors available for MMVD, num_mmvd_baseCand, can be added to the parsed merge index to determine the merge index to actually use.
[0294] FIG. 28 is a diagram illustrating the MMVD syntax according to an embodiment of the present invention. According to an embodiment of the present invention, a candidate index may exist before a flag indicating the presence or absence of mode use. For example, the candidate index may exist before the MMVD flag or the merge flag. In such a case, after parsing the candidate index, it is possible to determine whether to parse the MMVD flag depending on whether the parsed index is a candidate for using MMVD. For example, if the parsed candidate index is a candidate for using MMVD, the MMVD flag is parsed, and if it is a candidate for not using MMVD, the MMVD flag is not parsed and can be inferred as 0. Also, when the MMVD flag is 0, the merge flag can be parsed. The merge flag can determine whether the merge mode or the sub-block merge mode is used, or whether the inter mode or the AMVP mode or the affine inter mode is used. In FIG. 28, the decoder is mainly described for convenience of explanation, but the coding process according to this embodiment may be applied to the encoder in substantially the same manner.
[0295] For example, if the number of candidates possible as the first mode is num1, the number of candidates possible as the second mode is num2, and num1 < num2, when parsing the candidate index, if the parsed index is num1 or more, it is not necessary to parse the syntax for determining from the first mode and the second mode (for example, the syntax indicating whether to use the first mode), and it can be inferred that the first mode is not used. And when the parsed index is smaller than num1, the syntax for determining from the first mode and the second mode can be parsed.
[0296] Referring to Figure 28, after parsing the merge index, if the merge index is less than num_mmvd_baseCand, which is the number of available MMVD candidates, the MMVD flag can be parsed. If the merge index is greater than or equal to num_mmvd_baseCand, the MMVD flag does not need to be parsed, and in this case, the MMVD flag can be inferred to be 0. If the MMVD flag is 1, the distance index (distance_idx) and direction index (direction_idx) representing the MMVD-related syntax elements can be parsed. If the MMVD flag is 0, the merge flag is parsed, which allows us to distinguish between merge mode, subblock merge mode, intermode, AMVP mode, and affine mode.
[0297] Figure 29 illustrates a coding unit syntax structure according to one embodiment of the present invention. As shown in Figure 29, when the merge flag is 1, the merge data (i.e., merge_data) parsing process can be performed. Although Figure 29 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same way. In one embodiment, the merge data may include a part of the merge-related syntax. The merge data may also be called the merge data syntax. For example, the merge data may include the syntax parsing process performed when the merge flag is 1 in Figures 21 to 28 described above. Furthermore, a merge flag of 1 can mean that the merge mode is used. Furthermore, a merge flag of 1 can mean that inter prediction without using mvd_coding, as shown in Figure 6 and Table 1 above, is used.
[0298] Figure 30 illustrates a merge data syntax structure according to one embodiment of the present invention. As explained in Figure 29, when the merge flag is 1, the decoder can parse (or call) the merge data syntax. Although Figure 30 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same manner. Also, as mentioned above, when using merge mode or skip mode, the merge flag may be set to 1.
[0299] Referring to Figure 30, in the merge data syntax, the MMVD flag may be parsed first among the syntax elements. The MMVD flag may be the first syntax element to be parsed after confirming that the merge flag is 1. The MMVD flag may also be parsed before any signaling indicating the use of other prediction modes that set the merge flag to 1. The MMVD flag may also be a signaling indicating whether or not MMVD is used. The same methods as those described in Table 16 and Figures 22 to 29 may also be applied. As shown in Figure 30, the merge data syntax may include decoding processes for subblock merge modes, multi-hypothesis prediction (or intra and inter combined prediction), triangle prediction, etc.
[0300] According to one embodiment of the present invention, multiple assumption prediction may be a method of generating and combining two or more prediction blocks when generating a prediction block. Alternatively, multiple assumption prediction may be a method of using both interpretation and intrapretation when generating a prediction block. Furthermore, interpretation and intrapretation may be methods of using the same picture as the picture containing the current block and a different picture, respectively, when performing prediction. Referring to Figure 30, the multiple assumption prediction flag represents a syntax element indicating whether or not to use multiple assumption prediction.
[0301] Furthermore, according to one embodiment of the present invention, the subblock merge mode may be a method in which motion compensation is performed on a subblock basis (i.e., a motion vector is determined on a subblock basis) when predicting the current block (e.g., a coding unit or a prediction unit). In one embodiment, the subblock merge mode may include methods such as subblock-based time MVP and affine motion prediction. Referring to Figure 30, the merge subblock flag represents a syntax element indicating whether or not to use the subblock merge mode.
[0302] Furthermore, according to one embodiment of the present invention, triangle prediction represents a method of motion compensation for areas other than quadrilaterals within the current block. That is, in triangle prediction, the unit for which the motion vectors are the same within the current block does not have to be a quadrilateral. Referring to Figure 30, the triangle prediction flag (i.e., merge_triangle_flag) represents a syntax element that indicates whether or not to use triangle prediction.
[0303] Furthermore, according to one embodiment of the present invention, the MMVD flag may be parsed before any signaling (or syntax element) indicating the use of a merge mode other than MMVD. The signaling indicating the use of a merge mode other than MMVD may include a multiple assumption prediction flag, a merge subblock flag, a merge triangle flag, and the like.
[0304] Referring to Figure 30, the MMVD merge index (i.e., mmvd_merge_idx) (or MMVD index) represents a syntax element that indicates which MMVD base motion vector to use. If MMVD is used, the merge index can be inferred to be the MMVD merge flag (i.e., mmvd_merge_flag) (or MMVD flag).
[0305] Figure 31 illustrates a merge data syntax structure according to one embodiment of the present invention. The embodiment in Figure 31 may be a part of the merge data syntax performed when the merge flag is 1 in Figure 29. Although Figure 31 focuses on the decoder for ease of explanation, the coding process according to this embodiment may be applied to the encoder in substantially the same manner. According to one embodiment of the present invention, the MMVD flag may be parsed after the merge index. For example, the MMVD flag may be parsed immediately after the merge index. For example, the MMVD flag does not have to be parsed at any position other than the very beginning in the merge data syntax. That is, after confirming that the merge flag is 1, the MMVD flag can be parsed after other syntax has been parsed instead of the MMVD flag.
[0306] Furthermore, according to one embodiment of the present invention, as explained in Figure 21, the base motion vector of the MMVD may be determined from another candidate list, and in one embodiment, the base motion vector may be determined from a part of the other candidate list. Therefore, as explained in Figure 25, according to this embodiment, it is possible to decide whether or not to parse the MMVD flag based on an index associated with another candidate list that can be used as the base motion vector of the MMVD. For example, the index associated with another candidate list that can be used as the base motion vector of the MMVD can be parsed before the MMVD flag. Then, if the index associated with the other candidate list indicates that it can be used as the base motion vector of the MMVD, the MMVD flag can be parsed, and if not, the MMVD flag can not be parsed.
[0307] Referring to Figure 31, the base motion vector of the MMVD may be determined from the merge candidates. Therefore, in one embodiment, the MMVD flag may be parsed if the merge index indicates that it can be used as the base motion vector of the MMVD, and not otherwise. Alternatively, if the base motion vector of the MMVD may be selected from the first n of the merge candidate list, the MMVD flag may be parsed if the merge index is less than n (the merge index may start from 0), and not otherwise. More specifically, the base motion vector of the MMVD can be the first or second candidate in the merge candidate list, and referring to Figure 31, the MMVD flag can be parsed if the merge index is less than 2, i.e., 0 or 1. The merge index can represent the merge candidate index. This means that if it is a merge mode but the merge index indicates that the MMVD cannot be used, the MMVD flag does not need to be parsed, thereby improving coding efficiency.
[0308] Furthermore, the base motion vector of the MMVD may be determined from a list of candidate modes. Therefore, according to one embodiment of the present invention, when there are many signalings indicating whether or not various modes are used, the MMVD flag can be parsed after it is determined that a certain mode is to be used. For example, assuming that there are a first mode, a second mode, and a third mode, and the MMVD is determined based on the third mode, or the base motion vector of the MMVD is determined from candidates for the third mode, the MMVD flag can be parsed after it is determined that the third mode is to be used. For example, it may be determined that the third mode is to be used by a signaling that indicates whether or not the third mode is to be used. Or, for example, if it is determined that modes other than the third mode, such as the first and second modes, are not to be used, it may be determined that the third mode is to be used. For example, when there are subblock merge modes, multiple assumption predictions, triangle predictions, conventional merge modes, etc., and the MMVD can be applied to the conventional merge mode, the MMVD flag can be parsed after it is determined that the conventional merge mode or the MMVD is to be used from among the enumerated modes. The conventional merge mode described above is a mode that performs interpretation using motion information of surrounding intracoded blocks, and can be said to be the merge mode of conventional video compression technology (e.g., HEVC (high efficiency video coing)).
[0309] Furthermore, when parsing the MMVD flag based on an index associated with another candidate list usable as the MMVD base motion vector, there is no need for a separate signaling indicating the MMVD base motion vector. For example, in Figure 23 or Figure 24, a signaling such as the base motion vector index exists separately from the merge index. Also, referring to Figure 30, the MMVD merge flag may be a signaling indicating the MMVD base motion vector. According to one embodiment of the present invention, as shown in Figure 31, the MMVD merge flag may not exist. For example, the MMVD-related syntax may only include the MMVD flag, a signaling indicating the MMVD distance (mmvd_distance_idx in Figures 30 and 31), and a signaling indicating the MMVD direction (mmvd_direction_idx in Figures 30 and 31). Also, the MMVD base motion vector may be determined by the merge index. As a result, the signaling and context model showing the base motion vector of the MMVD in Figure 30 may not be present in the embodiment shown in Figure 31.
[0310] Furthermore, according to one embodiment of the present invention, the MMVD flag may be parsed after signaling indicating the use of a merge mode other than MMVD as described above. Referring to Figure 31, the MMVD flag may be parsed after the merge subblock flag, the multiple assumption prediction flag (i.e., mh_intra_flag), and the merge triangle flag (i.e., merge_triangle_flag). Also, a particular merge mode does not have to be used with MMVD. In that case, if the flag indicating whether or not to use the aforementioned merge mode indicates that it will not be used, the MMVD flag can be parsed. Referring to Figure 31, MMVD may not be usable with triangle prediction, and the MMVD flag may be parsed when the merge triangle flag is 0. Alternatively, MMVD may not be usable with MH intra, and the MMVD flag may be parsed when mh_intra_flag is 0. Alternatively, MMVD may not be usable with subblock merge modes, and the MMVD flag may be parsed when the merge subblock flag is 0.
[0311] Figure 32 illustrates a merge data syntax structure according to one embodiment of the present invention. The embodiment in Figure 32 may be a part of the merge data syntax performed when the merge flag is 1 in Figure 29. For the sake of explanation, Figure 32 focuses on the decoder, but the coding process according to this embodiment may be applied to the encoder in substantially the same manner.
[0312] According to one embodiment of the present invention, the MMVD flag may be parsed after signaling indicating whether or not to use other modes. Alternatively, the MMVD flag may be parsed after signaling indicating whether or not to use other modes other than MMVD, in which the merge flag is set to 1. For example, the MMVD flag may be parsed after the merge subblock flag, the multiple assumption prediction flag (i.e., mh_intra_flag), and the merge triangle flag (i.e., merge_triangle_flag).
[0313] Furthermore, in one embodiment, the MMVD flag may be parsed if no other mode other than MMVD is used. For example, if the merge subblock flag is 0, the MMVD flag may be parsed. Also, if the multiple assumption prediction flag is 0, the MMVD flag may be parsed. Also, if the merge triangle flag is 0, the MMVD flag may be parsed. A flag indicating whether or not to use a certain mode being 0 can indicate that the aforementioned mode will not be used. Furthermore, if MMVD can be applied to the conventional merge mode, the MMVD flag may be parsed after it has been determined that the conventional merge mode or MMVD will be used.
[0314] Furthermore, in one embodiment, if MMVD is used, the MMVD-related syntax can be parsed, and if MMVD is not used, the merge index can be parsed. Alternatively, if MMVD is used, the decoder can parse the MMVD merge flag (i.e., mmvd_merge_flag), MMVD distance index (mmvd_distance_idx), and MMVD direction index (mmvd_direction_idx), and if MMVD is not used, the merge index can be parsed. Also, as shown in Figure 32, if the MMVD flag is parsed after a flag indicating whether or not to use another mode, the signaling indicating the MMVD base motion vector may exist as a syntax element separate from the merge index. Referring to Figure 32, the signaling indicating the MMVD base motion vector may be the MMVD merge flag. For example, the MMVD flag can be parsed after it has been decided to use the conventional merge mode or MMVD.
[0315] According to one embodiment of the present invention, the base motion vector of an MMVD is determined from a list of candidates, and the maximum number of candidates in the list of candidates may be variable. For example, the maximum number of candidates may be determined from a higher-level syntax. The higher-level syntax may be a syntax higher level than the current coding unit. For example, the higher-level syntax may be a sequence, picture, slice, or tile level syntax. According to one embodiment, in such a case, the maximum number of candidates for the MMVD base motion vector may follow the maximum number of candidates in the list of candidates that can become the MMVD base motion vector. Therefore, if the maximum number of candidates in the list of candidates that can become the MMVD base motion vector decreases, the maximum number of candidates that can become the MMVD base motion vector may also decrease.
[0316] In one embodiment, the base motion vector of the MMVD is determined from a list of merge candidates, and the maximum number of merge candidates may be MaxNumMergeCand. Furthermore, MaxNumMergeCand may be determined from the higher-level syntax. In such a case, the maximum number of merge candidates that can become the base motion vector of the MMVD may be less than or equal to MaxNumMergeCand. Therefore, as shown in Figure 32, MaxNumMergeCand may determine whether or not to parse the signaling indicating the base motion vector of the MMVD. For example, if MaxNumMergeCand is 1, it is not necessary to parse the signaling indicating the base motion vector of the MMVD, and if there is no signaling indicating the base motion vector of the MMVD, it can be inferred to be 0.
[0317] In other embodiments, if MaxNumMergeCand is 1, MMVD may not be used. This may be to reduce the signaling overhead for MMVD-related syntax. Therefore, if MaxNumMergeCand is 1, the MMVD flag does not need to be parsed. Also, if the MMVD flag is not present, it can be inferred as 0. Furthermore, referring to Figure 32, the merge triangle flag can only be parsed if multiple assumption intra prediction is not used. If the merge triangle flag is not present, it can be inferred as 0.
[0318] According to one embodiment of the present invention, there may be many modes that cannot be used together. For example, the subblock merge mode, triangle prediction, multiple assumption intra prediction, and MMVD may not be usable together. Furthermore, the signaling indicating whether or not to use each of the many modes that cannot be used together may be parsed in an already set order. In such a case, the signaling indicating whether or not to use a particular mode among the many modes can only be parsed if all of the signaling indicating whether or not to use other modes among the many modes that have been parsed earlier indicate that they will not be used.
[0319] Figure 33 illustrates a video signal processing method according to one embodiment to which the present invention is applied. Referring to Figure 33, the explanation will focus on the decoder for convenience, but the present invention is not limited thereto, and the multiplexed-prediction-based video signal processing method according to this embodiment may be applied to an encoder in substantially the same manner.
[0320] The decoder obtains a first syntax element indicating whether a subblock-based merge mode is applied to the current block (S3301). As described above, in one embodiment, the first syntax element may be a subblock merge flag (or merge subblock flag).
[0321] If the first syntax element indicates that a subblock-based merge mode is not applied to the current block, the decoder obtains a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block (S3302). As described above, in one embodiment, the second syntax element may be an MMVD flag (or an MMVD merge flag).
[0322] If the second syntax element indicates that the merge mode using the motion vector difference is applied to the current block, the decoder obtains a third syntax element indicating a candidate from the merge candidate list of the current block to be used for interpretation of the current block (S3303). As described above, in one embodiment, the third syntax element may be an MMVD index (or an MMVD candidate index, MMVD candidate flag).
[0323] The decoder acquires information related to the motion vector difference (S3304). As described above, in one embodiment, the step of acquiring information related to the motion vector difference can be the step of acquiring a fourth syntax element indicating the distance of the motion vector difference; and a fifth syntax element indicating the direction of the motion vector difference. As described above, in one embodiment, the fourth syntax element may be a distance index (or MMVD distance index), and the fifth syntax element may be a direction index (or MMVD direction index).
[0324] The decoder derives the motion vector of the current block by adding the motion vector difference to the candidate motion vector indicated by the third syntax element (S3305).
[0325] The decoder generates a predicted block for the current block using the motion vector of the current block (S3306).
[0326] As described above, as an example, the third syntax element may indicate the candidate used for interpretation of the current block among the first and second candidates in the current block merge candidate list.
[0327] As described above, in one example, the third syntax element may be parsed from the bitstream if the maximum number of merge candidates is greater than 1, and inferred to be 0 if the maximum number of merge candidates is not greater than 1.
[0328] As described above, in one embodiment, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the step further includes obtaining a sixth syntax element indicating a candidate used for interpretation of the current block from among the candidates included in the subblock merge candidate list of the current block, and if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the motion vector of the current block may be guided in units of at least one subblock included in the current block based on the motion vector of the candidate indicated by the sixth syntax element. As described above, in one embodiment, the sixth syntax element may be a subblock merge index (or merge subblock index).
[0329] As described above, in an example, if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the second syntax element may be inferred to be 0.
[0330] As described above, in an example, the sixth syntax element may be parsed from the bitstream if the maximum number of subblock merge candidates is greater than 1, and may be inferred to be 0 if the maximum number of subblock merge candidates is not greater than 1.
[0331] The embodiments of the present invention described above may be embodied by various means. For example, embodiments of the present invention may be embodied by hardware, firmware, software, or a combination thereof.
[0332] In the case of hardware implementation, the method according to the embodiment of the present invention may be implemented by one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), processors, controllers, microcontrollers, microprocessors, etc.
[0333] In the case of implementation by firmware or software, the methods according to the embodiments of the present invention may be implemented in the form of modules, procedures, or functions that perform the functions or operations described above. The software code may be stored in memory and driven by a processor. The memory may be located inside or outside the processor and can exchange data with the processor by various already known means.
[0334] Some embodiments may be embodied in the form of a recording medium containing computer-executable instructions, such as program modules executed by a computer. Computer-readable media may be any available medium accessible by a computer, including volatile and non-volatile media, and separable and non-separable media. Computer-readable media may also include any computer storage media and communication media. Computer storage media include any volatile and non-volatile, separable and non-separable media embodied in any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Communication media typically include any information transmission medium, including computer-readable instructions, data structures, or other data such as modulated data signals, or other transmission mechanisms.
[0335] The above description of the present invention is illustrative, and a person with ordinary skill in the art to which the present invention pertains will understand that it can be easily modified into other specific forms without altering the technical idea or essential features of the present invention. Accordingly, the embodiments described above should be interpreted as illustrative and not limiting in any respect. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.
[0336] The scope of the present invention is defined by the claims described below rather than by the detailed description above, and any modified or altered forms derived from the meaning and scope of the claims and the concept of equivalents thereof should be interpreted as being included within the scope of the present invention. [Explanation of symbols]
[0337] 100 Encoding device 110 Conversion Unit 115 Quantization section 120 Inverse quantization section 125 Inverse Transform Section 130 Filtering section 150 Prediction Section 160 Entropy coding section
Claims
1. A video signal processing method, The current step is to obtain a first syntax element indicating whether or not a subblock-based merge mode is applied to the block; If the first syntax element indicates that a subblock-based merge mode is not applied to the current block, the step is to obtain a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block; If the second syntax element indicates that the merge mode using the motion vector difference is applied to the current block, the step is to obtain a third syntax element indicating a candidate among the candidates included in the merge candidate list of the current block to be used for interpretation of the current block; A step of acquiring information related to the aforementioned motion vector difference; The step of inducing the motion vector of the current block by adding the motion vector difference to the candidate motion vector indicated by the third syntax element; and A video signal processing method comprising the step of generating a predicted block for the current block using the motion vector of the current block.
2. The video signal processing method according to claim 1, characterized in that the third syntax element indicates a candidate used for interpretation of the current block from among the first and second candidates in the merge candidate list of the current block.
3. The video signal processing method according to claim 2, characterized in that the third syntax element is parsed from the bitstream if the maximum number of merge candidates is greater than 1, and is inferred to be 0 if the maximum number of merge candidates is not greater than 1.
4. The step of acquiring information related to the aforementioned motion vector difference is: The step of obtaining a fourth syntax element indicating the distance of the motion vector difference; and The video signal processing method according to claim 1, further comprising the step of obtaining a fifth syntax element indicating the direction of the motion vector difference.
5. If the first syntax element indicates that a subblock-based merge mode is applied to the current block, the process further includes obtaining a sixth syntax element indicating a candidate among the candidates included in the subblock merge candidate list of the current block to be used for interpretation of the current block, The video signal processing method according to claim 1, wherein if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the motion vector of the current block is induced in units of at least one subblock contained in the current block based on the candidate motion vector indicated by the sixth syntax element.
6. The video signal processing method according to claim 5, characterized in that if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the second syntax element is inferred to be 0.
7. The video signal processing method according to claim 5, characterized in that the sixth syntax element is parsed from the bitstream if the maximum number of subblock merge candidates is greater than 1, and is inferred to be 0 if the maximum number of subblock merge candidates is not greater than 1.
8. A video signal processing device, Including the processor, The aforementioned processor, Get the first syntax element that indicates whether a subblock-based merge mode is currently applied to the block. If the first syntax element indicates that a subblock-based merge mode is not applied to the current block, then obtain a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block. If the second syntax element indicates that the merge mode using the motion vector difference is applied to the current block, then a third syntax element is obtained that indicates a candidate from the merge candidate list of the current block to be used for inter prediction of the current block, Information related to the aforementioned motion vector difference is obtained, The motion vector of the current block is derived by adding the motion vector difference to the candidate motion vector indicated by the third syntax element. A video signal processing device that generates a predicted block for the current block using the motion vector of the current block.
9. The video signal processing apparatus according to claim 8, characterized in that the third syntax element indicates a candidate used for interpretation of the current block among the first and second candidates in the merge candidate list of the current block.
10. The video signal processing device according to claim 9, characterized in that the third syntax element is parsed from the bitstream if the maximum number of merge candidates is greater than 1, and is inferred to be 0 if the maximum number of merge candidates is not greater than 1.
11. The aforementioned processor, A fourth syntax element indicating the distance of the motion vector difference is obtained, The video signal processing apparatus according to claim 8, which acquires a fifth syntax element indicating the direction of the motion vector difference.
12. The aforementioned processor, If the first syntax element indicates that a subblock-based merge mode is applied to the current block, a sixth syntax element is obtained that indicates a candidate from the list of subblock merge candidates for the current block to be used for inter prediction of the current block. The video signal processing apparatus according to claim 8, wherein if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the motion vector of the current block is induced in units of at least one subblock contained in the current block based on the candidate motion vector indicated by the sixth syntax element.
13. The video signal processing apparatus according to claim 12, characterized in that if the first syntax element indicates that a subblock-based merge mode is applied to the current block, the second syntax element is inferred to be 0.
14. The video signal processing apparatus according to claim 12, characterized in that the sixth syntax element is parsed from the bitstream if the maximum number of subblock merge candidates is greater than 1, and is inferred to be 0 if the maximum number of subblock merge candidates is not greater than 1.
15. A video signal processing method, The current stage involves encoding a first syntax element that indicates whether or not a subblock-based merge mode is applied to the current block; If a subblock-based merge mode is not applied to the current block, the next step is to encode a second syntax element indicating whether or not a merge mode using motion vector differences is applied to the current block; When the merge mode using the motion vector difference is applied to the current block, the step is to encode a third syntax element that indicates a candidate among the candidates included in the merge candidate list of the current block to be used for interpretation of the current block; A step of encoding information related to the motion vector difference; The step of inducing the motion vector of the current block by adding the motion vector difference to the candidate motion vector indicated by the third syntax element; and A video signal processing method comprising the step of generating a predicted block for the current block using the motion vector of the current block.