Video encoding / decoding method, video encoder, video decoder, video encoding device, video decoding device, and computer-readable storage medium

Abstract

The present invention provides a video encoding / decoding method, video encoder, video decoder, video encoding device, video decoding device, and computer-readable storage medium that improve the efficiency of motion vector coding. [Solution] The video decoding method includes the steps of determining whether a merge offset vector encoding method is applied to the current block, generating a list of merge candidates for the current block, identifying a merge candidate for the current block based on the list of merge candidates, and inducing a motion vector for the current block based on the merge candidate.

Description

Technical Field

[0001] The present invention relates to a video encoding / decoding method, a video encoder, a video decoder, a video encoding device, a video decoding device, and a computer-readable storage medium.

Background Art

[0002] As display panels are becoming larger and larger, higher-quality video services are increasingly demanded. The biggest problem with high-definition video services is that the amount of data increases significantly. To solve such problems, research on improving the video compression ratio has been actively conducted. As a typical example, in 2009, MPEG (Motion Picture Experts Group) and VCEG (Video Coding Experts Group) under the umbrella of ITU-T (International Telecommunication Union-Telecommunication) formed JCT-VC (Joint Collaborative Team on Video Coding). Compared with H.264 / AVC, JCT-VC proposed HEVC (High Efficiency Video Coding), a video compression standard with a compression performance approximately twice that of H.264 / AVC, and the standard was approved on January 25, 2013. With the rapid development of high-definition video services, the performance of HEVC is also showing its limitations more and more.

Summary of the Invention

[0003] The present invention is defined by the independent claims. Further embodiments are defined by the dependent claims.

[0004] A video decoding method according to the present invention includes the steps of: determining whether a merge offset vector encoding method is applied to the current block; generating a list of merge candidates for the current block; identifying a merge candidate for the current block based on the list of merge candidates; and inducing a motion vector for the current block based on the merge candidate. In this case, if the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate; if the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating any one of the merge candidates; if the maximum number is one, the merge candidate can be determined without decoding the index information.

[0005] A video encoding method according to the present invention includes the steps of: determining whether a merge offset vector encoding method is applied to the current block; generating a list of merge candidates for the current block; identifying a merge candidate for the current block based on the list of merge candidates; and inducing a motion vector for the current block based on the merge candidate, wherein if the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate; if the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded; if the maximum number is one, encoding of the index information is omitted.

[0006] The video coder according to the present invention includes a processor and memory, the memory being used to store a computer program, the processor executing the computer program stored in the memory to determine whether the merge offset vector encoding method is applicable to the current block, generating a list of merge candidates for the current block, identifying a merge candidate for the current block based on the list of merge candidates, and deriving a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applicable to the current block, the motion vector for the current block is derived by adding an offset vector to the motion vector of the merge candidate, if the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating any one of the merge candidates, if the maximum number is one, the merge candidate is determined without decoding the index information.

[0007] The video encoder according to the present invention includes a processor and memory, the memory being used to store a computer program, the processor executing the computer program stored in the memory to determine whether a merge offset vector encoding method is applied to the current block, generating a list of merge candidates for the current block, identifying a merge candidate for the current block based on the list of merge candidates, and deriving a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applied to the current block, the motion vector of the current block is derived by adding an offset vector to the motion vector of the merge candidate, if the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded, if the maximum number is one, encoding of the index information is omitted.

[0008] The video decoding apparatus according to the present invention includes an inter-prediction unit that determines whether a merge offset vector encoding method is applied to the current block, generates a list of merge candidates for the current block, identifies a merge candidate for the current block based on the list of merge candidates, and induces a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applied to the current block, the motion vector for the current block is induced by adding an offset vector to the motion vector of the merge candidate. If the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating one of the merge candidates. If the maximum number is one, the merge candidate is determined without decoding the index information.

[0009] The video encoding apparatus according to the present invention includes an interpretation unit that determines whether a merge offset vector encoding method is applied to the current block, generates a list of merge candidates for the current block, identifies a merge candidate for the current block based on the list of merge candidates, and induces a motion vector for the current block based on the merge candidate. When the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate. If the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded. If the maximum number is one, encoding of the index information is omitted.

[0010] The computer-readable storage medium according to the present invention is used to store a computer program, and when the computer program is executed by a processor, a video decoding method or a video encoding method is executed. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a block diagram showing a video encoder (encoder) according to one embodiment of the present invention. [Figure 2] Figure 2 is a block diagram showing a video decoder (decoder) according to one embodiment of the present invention. [Figure 3] Figure 3 shows a basic coding tree unit according to one embodiment of the present invention. [Figure 4] Figure 4 shows various ways of dividing a coding block. [Figure 5] Figure 5 shows the division patterns of the coding tree units. [Figure 6] Figure 6 shows the configuration of the basic data unit. [Figure 7]Figure 7 shows an example where a coding block is divided into multiple subblocks. [Figure 8] Figure 8 shows an example where a coding block is divided into multiple subblocks. [Figure 9] Figure 9 is a flowchart of an interpretation prediction method according to one embodiment of the present invention. [Figure 10] Figure 10 shows the nonlinear motion of an object. [Figure 11] Figure 11 is a flowchart of an inter-prediction method based on affine motion according to one embodiment of the present invention. [Figure 12] Figure 12 illustrates the affine seed vectors for each affine motion model. [Figure 13] Figure 13 illustrates the affine vectors of subblocks in a four-parameter motion model. [Figure 14] Figure 14 is a flowchart showing the process of deriving the movement information of the current block in merge mode. [Figure 15] Figure 15 illustrates candidate blocks used to guide merge candidates. [Figure 16] Figure 16 shows the position of the reference sample. [Figure 17] Figure 17 illustrates candidate blocks used to guide merge candidates. [Figure 18] Figure 18 shows an example where the position of the reference sample is changed. [Figure 19] Figure 19 shows an example where the position of the reference sample is changed. [Figure 20] Figure 20 shows the process of updating the inter-domain motion information table. [Figure 21] Figure 21 shows the process of updating the inter-region merge candidate table. [Figure 22] Figure 22 shows an example where the index of already stored inter-area merge candidates is updated. [Figure 23] FIG. 23 is a diagram showing the positions of representative sub-blocks. [Figure 24] FIG. 24 is a diagram showing an example in which an inter-region motion information table is generated for each inter-prediction mode. [Figure 25] FIG. 25 is a diagram showing an example in which inter-region merge candidates included in a long-term motion information table are added to a merge candidate list. [Figure 26] FIG. 26 is a diagram showing an example in which redundancy checking is performed only on some of the merge candidates. [Figure 27] FIG. 27 is a diagram showing an example in which redundancy checking with a specific merge candidate is omitted. [Figure 28] FIG. 28 is a diagram showing an offset vector based on values of distance_idx indicating the magnitude of the offset vector and direction_idx indicating the direction of the offset vector. [Figure 29] FIG. 29 is a diagram showing an offset vector based on values of distance_idx indicating the magnitude of the offset vector and direction_idx indicating the direction of the offset vector. [Figure 30] FIG. 30 is a diagram showing the division state of a coding block when the triangular division technique is applied. [Figure 31] FIG. 31 is a diagram showing an example in which offset vectors of each sub-unit are set to be different. [Figure 32] FIG. 32 is a diagram showing motion vector candidates that a refine merge candidate can take. [Figure 33] FIG. 33 is a diagram showing the configuration of a merge refinement offset list. [Figure 34] FIG. 34 is a diagram showing an offset vector specified by a merge offset candidate. [Figure 35] FIG. 35 is a diagram showing an offset vector specified by a merge offset candidate. [Figure 36]Figure 36 shows a candidate block used to guide motion vector prediction candidates. [Figure 37] Figure 37 shows motion vector candidates that can be set as refined motion vector prediction candidates. [Figure 38] Figure 38 shows the structure of the prediction vector refinement offset list. [Modes for carrying out the invention]

[0012] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0013] A video decoding method according to the present invention includes the steps of: determining whether a merge offset vector encoding method is applied to the current block; generating a list of merge candidates for the current block; identifying a merge candidate for the current block based on the list of merge candidates; and inducing a motion vector for the current block based on the merge candidate. In this case, if the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate; if the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating any one of the merge candidates; if the maximum number is one, the merge candidate can be determined without decoding the index information.

[0014] In one embodiment, the magnitude of the offset vector is determined based on first index information that identifies one of the candidate vector magnitudes.

[0015] In one embodiment, at least one of the maximum or minimum values ​​of the vector magnitude candidate is set to be different based on the value of a flag indicating the numerical value of the vector magnitude candidate.

[0016] In one embodiment, the flag is signaled at the picture level.

[0017] In one embodiment, at least one of the maximum or minimum values ​​of the vector magnitude candidate is set to differ depending on the accuracy of the motion vector relative to the current block.

[0018] In one embodiment, the magnitude of the offset vector is obtained by applying a bit shift operation to the value indicated by the vector magnitude candidate identified by the first index information.

[0019] In one embodiment, the direction of the offset vector is determined based on second index information that identifies one of the candidate vector directions.

[0020] A video encoding method according to the present invention includes the steps of: determining whether a merge offset vector encoding method is applied to the current block; generating a list of merge candidates for the current block; identifying a merge candidate for the current block based on the list of merge candidates; and inducing a motion vector for the current block based on the merge candidate, wherein if the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate; if the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded; if the maximum number is one, encoding of the index information is omitted.

[0021] In one embodiment, the video encoding method further includes the step of encoding first index information for identifying a vector size candidate that indicates the magnitude of the offset vector from among a plurality of vector size candidates.

[0022] In one embodiment, the video encoding method further includes the step of encoding a flag indicating a numerical value of the vector magnitude candidate, wherein at least one of the maximum or minimum values ​​of the vector magnitude candidate is different depending on the value of the flag.

[0023] In one embodiment, the flag is encoded at the picture level.

[0024] In one embodiment, at least one of the maximum or minimum values ​​of the vector magnitude candidate is set to differ depending on the accuracy of the motion vector relative to the current block.

[0025] In one embodiment, the candidate vector magnitude has a value derived by applying a bit shift operation to the magnitude of the offset vector.

[0026] In one embodiment, the video encoding method further includes the step of encoding second index information for identifying a vector direction candidate indicating the direction of the offset vector from among a number of vector direction candidates.

[0027] The video decoder according to the present invention includes a processor and memory, the memory being used to store a computer program, the processor executing the computer program stored in the memory to determine whether a merge offset vector encoding method is applied to the current block, generating a list of merge candidates for the current block, identifying a merge candidate for the current block based on the list of merge candidates, and deriving a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applied to the current block, the motion vector for the current block is derived by adding an offset vector to the motion vector of the merge candidate, if the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating any one of the merge candidates, if the maximum number is one, the merge candidate is determined without decoding the index information.

[0028] The video encoder according to the present invention includes a processor and memory, the memory being used to store a computer program, the processor executing the computer program stored in the memory to determine whether a merge offset vector encoding method is applied to the current block, generating a list of merge candidates for the current block, identifying a merge candidate for the current block based on the list of merge candidates, and deriving a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applied to the current block, the motion vector of the current block is derived by adding an offset vector to the motion vector of the merge candidate, if the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded, if the maximum number is one, encoding of the index information is omitted.

[0029] The video decoding apparatus according to the present invention includes an inter-prediction unit that determines whether a merge offset vector encoding method is applied to the current block, generates a list of merge candidates for the current block, identifies a merge candidate for the current block based on the list of merge candidates, and induces a motion vector for the current block based on the merge candidate. If the merge offset vector encoding method is applied to the current block, the motion vector for the current block is induced by adding an offset vector to the motion vector of the merge candidate. If the maximum number of merge candidates that the list of merge candidates can contain is multiple, the merge candidate for the current block is selected based on index information decoded from a bitstream indicating one of the merge candidates. If the maximum number is one, the merge candidate is determined without decoding the index information.

[0030] The video encoding apparatus according to the present invention includes an interpretation unit that determines whether a merge offset vector encoding method is applied to the current block, generates a list of merge candidates for the current block, identifies a merge candidate for the current block based on the list of merge candidates, and induces a motion vector for the current block based on the merge candidate. When the merge offset vector encoding method is applied to the current block, the motion vector of the current block is induced by adding an offset vector to the motion vector of the merge candidate. If the maximum number of merge candidates that the list of merge candidates can contain is multiple, index information indicating the merge candidate for the current block among the merge candidates is encoded. If the maximum number is one, encoding of the index information is omitted.

[0031] The computer-readable storage medium according to the present invention is used to store a computer program, and when the computer program is executed by a processor, a video decoding method or a video encoding method is executed.

[0032] The present invention can further provide a method for refining motion vectors derived from merge candidates based on an offset vector when encoding / decoding a video signal, and an apparatus for performing this method.

[0033] The present invention can further provide a method for signaling an offset vector when encoding / decoding a video signal, and an apparatus for performing this method.

[0034] According to the present invention, interpretation efficiency can be improved by refining the motion vectors of merge candidates based on the offset vector.

[0035] According to the present invention, the interpretation efficiency can be improved by adaptively determining the magnitude and direction of the offset vector.

[0036] Video encoding and decoding are performed in block units. For example, encoding / decoding processes such as transformation, quantization, prediction, in-loop filtering, or reconstruction can be performed on coding blocks, transformation blocks, or prediction blocks.

[0037] Hereafter, the block being encoded / decoded will be referred to as the "current block." For example, based on the current encoding / decoding process step, the current block may be a coding block, a transformation block, or a prediction block.

[0038] Furthermore, as used herein, the term "unit" may be understood to refer to a basic unit for performing a particular encoding / decoding process, and the term "block" may be understood to refer to a sample array of a given size. Unless otherwise stated, "block" and "unit" may be used interchangeably. For example, in the embodiments described later, coding block and coding unit may be understood to have the same meaning.

[0039] Figure 1 is a block diagram showing a video encoder (encoder) according to one embodiment of the present invention.

[0040] Referring to Figure 1, the video encoding device 100 may include a picture splitting unit 110, prediction units 120, 125, a conversion unit 130, a quantization unit 135, a realignment unit 160, an entropy coding unit 165, an inverse quantization unit 140, an inverse conversion unit 145, a filter unit 150, and a memory 155.

[0041] In the video encoding device, each component shown in Figure 1 is illustrated independently to illustrate its different characteristic functions; however, this does not mean that each component consists of separate hardware or a single software component unit. In other words, for the convenience of explanation, each component is listed, and at least two of these components can be combined to form a single component, or a single component can be divided into multiple components to perform functions. Both integrated and separated embodiments of these components are included within the scope of the present invention, as long as they do not deviate from the essence of the invention.

[0042] Furthermore, some components may not be essential for performing the essential functions of the present invention, but may be optional components used solely to improve performance. The present invention may include only the components essential for realizing the essence of the invention, excluding components used solely to improve performance, and a structure including only the necessary components, excluding optional components used solely to improve performance, is also within the scope of the rights of the present invention.

[0043] The picture splitting unit 110 can split an input picture into at least one processing unit. In this case, the processing unit can be a prediction unit (PU), a transform unit (TU), or a coding unit (CU). The picture splitting unit 110 can split a single picture into a combination of multiple coding units, prediction units, and transform units, and then, based on a predetermined criterion (e.g., a cost function), select one combination of coding units, prediction units, and transform units to encode the picture.

[0044] For example, a single picture can be divided into multiple coding units. To divide a picture into coding units, a recursive tree structure such as a Quad Tree Structure can be used, with one video or the largest coding unit as the root, and each coding unit that is divided into other coding units can have as many child nodes as there are coding units it is divided into. Coding units that cannot be divided further, according to certain limits, become leaf nodes. In other words, assuming that only square division is possible for a single coding unit, one coding unit can be divided into up to four other coding units.

[0045] In the embodiments of the present invention described below, the term "coding unit" can be used to mean a unit that performs encoding, or it can be used to mean a unit that performs decoding.

[0046] A prediction unit may be divided within a coding unit so that at least one of the prediction units has the same shape, such as a square or rectangle, and may also be divided such that one of the prediction units within a coding unit has a different shape and / or size from the other prediction units.

[0047] When generating prediction units that perform intra-prediction based on coding units, if there is no minimum coding unit, intra-prediction can be performed without dividing into multiple prediction units N×N.

[0048] The prediction units 120 and 125 may include an inter-prediction unit 120 that performs inter-prediction and an intra-prediction unit 125 that performs intra-prediction. The prediction unit can decide whether to perform inter-prediction or intra-prediction, and specific information (e.g., intra-prediction mode, motion vector, reference picture, etc.) can be determined for each prediction method. In this case, the processing unit where the prediction is performed and the processing unit where the prediction method and specific content are determined can be different. For example, the prediction method and prediction mode may be determined in the prediction unit, while the prediction is performed in the conversion unit. The residual values ​​(residual blocks) between the generated prediction blocks and the original blocks can be input to the conversion unit 130. Furthermore, prediction mode information, motion vector information, etc., used for prediction can be encoded together with the residual values ​​in the entropy coding unit 165 and transferred to the decoder. When using a specific encoding mode, the prediction units 120 and 125 can also encode the original blocks directly and transmit them to the decoder without generating prediction blocks.

[0049] The interpretation unit 120 can predict prediction units based on information from at least one picture that is either a picture before or after the current picture, and may also predict prediction units based on information from an encoded sub-region within the current picture. The interpretation unit 120 may include a reference picture interpolation unit, a motion prediction unit, and a motion compensation unit.

[0050] The reference picture interpolation unit receives reference picture information from memory 155 and can generate pixel information for integer pixels or smaller in the reference picture. For luminance pixels, a DCT-based 8-tab interpolation filter with changing filter coefficients can be used to generate pixel information for integer pixels or smaller in 1 / 4 pixel units. For color difference signals, a DCT-based 4-tab interpolation filter with changing filter coefficients can be used to generate pixel information for integer pixels or smaller in 1 / 8 pixel units.

[0051] The motion prediction unit can perform motion prediction based on the reference picture interpolated by the reference picture interpolation unit. Various methods can be used to calculate the motion vector, such as FBMA (Full search-based Block Matching Algorithm), TSS (Three Step Search), and NTS (New Three-Step Search Algorithm). The motion vector may have motion vector values ​​in units of 1 / 2 or 1 / 4 pixels based on the interpolated pixels. The motion prediction unit can predict the current prediction unit by changing the motion prediction method. Various methods can be used as motion prediction methods, such as the Skip method, Merge method, AMVP (Advanced Motion Vector Prediction) method, and Intra Block Copy method.

[0052] The intra-prediction unit 125 can generate prediction units based on reference pixel information around the current block, which is the pixel information of the current picture. If the surrounding blocks of the current prediction unit are blocks that have undergone inter-prediction, and the reference pixels are pixels that have undergone inter-prediction, the reference pixels included in the inter-predicted block can be replaced with the reference pixel information of the surrounding intra-predicted blocks. In other words, if a reference pixel is unavailable, the unavailable reference pixel information can be replaced with at least one of the available reference pixels.

[0053] In intra-prediction, the prediction modes include a directional prediction mode that uses reference pixel information according to the prediction direction, and a non-directional mode that does not use directional information when making predictions. The modes for predicting luminance information and the modes for predicting chrominance information may be different, and the intra-prediction mode information or predicted luminance signal information used for predicting luminance information may be utilized to predict chrominance information.

[0054] When performing intraprediction, if the size of the prediction unit and the size of the transformation unit are the same, intraprediction can be performed on the prediction unit based on the pixels to the left of the prediction unit, the pixels in the upper left corner, and the pixels at the top edge of the prediction unit. However, when performing intraprediction, if the size of the prediction unit and the size of the transformation unit are different, intraprediction can be performed using reference pixels based on the transformation unit. In addition, intraprediction using N×N partitioning can be used only for the smallest coding unit.

[0055] The intra-prediction method can generate a prediction block after applying an AIS (Adaptive Intra Smoothing) filter to a reference pixel based on the prediction mode. The type of AIS filter applied to the reference pixel can vary. To execute the intra-prediction method, the intra-prediction mode of the current prediction unit can be predicted from the intra-prediction modes of prediction units surrounding the current prediction unit. When predicting the prediction mode of the current prediction unit using mode information predicted from surrounding prediction units, if the intra-prediction modes of the current prediction unit and the surrounding prediction units are the same, information indicating that the prediction modes of the current prediction unit and the surrounding prediction units are the same can be transmitted using predetermined flag information. If the prediction modes of the current prediction unit and the surrounding prediction units are different, entropy coding can be performed to encode the prediction mode information of the current block.

[0056] Furthermore, residual blocks can be generated that include residual value information, which is the difference between the prediction unit that performed the prediction based on the prediction units generated by the prediction units 120 and 125 and the original block of the prediction unit. The generated residual blocks can be input to the conversion unit 130.

[0057] The transformation unit 130 can transform residual blocks containing residual value information between the original block and the prediction units generated by the prediction units 120,125, using a transformation method such as DCT (Discrete Cosine Transform) or DST (Discrete Sine Transform). Here, the DCT transformation core includes at least one of DCT2 or DCT8, and the DST transformation core includes DST7. Whether to apply DCT or DST to transform the residual block can be determined based on the intra-prediction mode information of the prediction unit used to generate the residual block. The transformation of the residual block can also be skipped. A flag indicating whether or not to skip the transformation of the residual block can be encoded. Transformation skipping may be permitted for residual blocks, lumens, or chroma components under the 4:4:4 format whose size is below a threshold.

[0058] The quantization unit 135 can quantize the values ​​converted to the frequency domain by the conversion unit 130. The quantization coefficients can be changed according to the importance of the blocks or video. The values ​​calculated by the quantization unit 135 can be provided to the inverse quantization unit 140 and the realignment unit 160.

[0059] The realignment unit 160 can realign coefficient values ​​with respect to the quantized residual values.

[0060] The realignment unit 160 can convert two-dimensional block shape coefficients into one-dimensional vector shapes using a coefficient scanning method. For example, the realignment unit 160 can use a zig-zag scan method to scan from DC coefficients to high-frequency coefficients and convert them into one-dimensional vector shapes. Depending on the size of the conversion unit and the intra-prediction mode, a vertical scan that scans the two-dimensional block shape coefficients in the column direction or a horizontal scan that scans the two-dimensional block shape coefficients in the row direction may also be used instead of a zig-zag scan. In other words, the scanning method to use from zig-zag scan, vertical scan, and horizontal scan can be determined based on the size of the conversion unit and the intra-prediction mode.

[0061] The entropy coding unit 165 can perform entropy coding based on the values ​​calculated by the re-alignment unit 160. Entropy coding can use various encoding methods, such as Exponential Golomb, CAVLC (Context-Adaptive Variable Length Coding), and CABAC (Context-Adaptive Binary Arithmetic Coding).

[0062] The entropy coding unit 165 can encode various information from the realignment unit 160 and prediction units 120, 125, such as residual coefficient information of the coding unit, block type information, prediction mode information, divided unit information, prediction unit information, transmission unit information, motion vector information, reference frame information, block interpolation information, and filtering information.

[0063] The entropy coding unit 165 can entropi-encode the coefficient values ​​of the coding units input from the realignment unit 160.

[0064] The inverse quantization unit 140 inversely quantizes the value quantized by the quantization unit 135, and the inverse transformation unit 145 inversely transforms the value transformed by the transformation unit 130. The residual values ​​generated from the inverse quantization unit 140 and the inverse transformation unit 145 can be combined with the prediction units predicted by the motion estimation unit, motion compensation unit, and intra-prediction unit included in the prediction units 120 and 125 to generate a reconstructed block.

[0065] The filter section 150 may include at least one of the following: a deblocking filter, an offset correction section, and an ALF (Adaptive Loop Filter).

[0066] A deblocking filter can remove block distortion caused by the boundaries between blocks in the restored picture. To determine whether to deblock, the number of pixels in a given column or row within the block can be used to decide whether to apply the deblocking filter to the current block. When applying a deblocking filter to a block, a strong filter or a weak filter can be applied depending on the required deblocking filtering strength. Additionally, when applying a deblocking filter, if vertical filtering and horizontal filtering are performed, the horizontal and vertical filtering can be processed in parallel.

[0067] The offset correction unit can correct the offset between the deblocked video and the original video at the pixel unit level. To perform offset correction on a specific picture, one can divide the pixels contained in the video into a certain number of regions, determine the region to which the offset should be applied, and then apply the offset to the corresponding region, or apply the offset while considering the edge information of each pixel.

[0068] Adaptive Loop Filtering (ALF) can be performed based on a comparison of the filtered restored video with the original video. The pixels in the video are divided into predetermined groups, and then a single filter is determined to be applied to each corresponding group, allowing for differential filtering of each group. A luminance signal, which is information related to whether or not ALF should be applied, can be transmitted for each coding unit (CU), and the shape and filter coefficients of the ALF filter applied can differ depending on the block. Alternatively, the same (fixed) form of ALF filter can be applied regardless of the characteristics of the block being processed.

[0069] Memory 155 can store the restored blocks or pictures calculated via the filter unit 150, and the stored restored blocks or pictures can be provided to the prediction units 120 and 125 when performing interpretation.

[0070] Figure 2 is a block diagram showing a video decoder (decoder) according to one embodiment of the present invention.

[0071] Referring to Figure 2, the video decoder 200 may include an entropy decoding unit 210, a realignment unit 215, an inverse quantization unit 220, an inverse transform unit 225, prediction units 230, 235, a filter unit 240, and a memory 245.

[0072] When a video bitstream is input from a video decoder, the input bitstream can be decoded in the reverse order of the video encoder's procedure.

[0073] The entropy decoding unit 210 can perform entropy decoding in the reverse order of the procedure performed by the entropy coding unit of the video encoder. For example, various methods such as Exponential Golomb, CAVLC (Context-Adaptive Variable Length Coding), and CABAC (Context-Adaptive Binary Arithmetic Coding) can be applied, corresponding to the method performed by the video encoder.

[0074] The entropy decoding unit 210 can decode information regarding intra-prediction and inter-prediction performed by the encoder.

[0075] The re-arrangement unit 215 can perform re-arrangement on the bitstream entropy-decoded from the entropy-decodement unit 210 based on the re-arrangement method performed in the encoding unit. It can re-arrange coefficients expressed in the form of one-dimensional vectors by restoring them to the form of two-dimensional blocks. The re-arrangement unit 215 receives information related to the coefficient scan performed in the encoding unit and can re-arrange using a reverse scan method based on the scan order performed in the corresponding encoding unit.

[0076] The inverse quantization unit 220 can perform inverse quantization based on the quantization parameters provided by the encoder and the coefficient values ​​of the realigned blocks.

[0077] The inverse transformer 225 can perform an inverse transform on the quantization result performed by the video encoder, with respect to the transform performed by the transformer, i.e., DCT or DST, i.e., it can perform an inverse DCT or inverse DST. Here, the DCT transformer core may include at least one of DCT2 or DCT8, and the DST transformer core may include DST7. Alternatively, if the transform is skipped by the video encoder, the inverse transformer 225 may also not perform an inverse transform. The inverse transformer can be performed based on the transmission unit determined by the video encoder. The inverse transformer 225 of the video decoder can selectively perform a transform technique (e.g., DCT or DST) based on multiple pieces of information such as the prediction method, the current block size, and the prediction direction.

[0078] The prediction units 230 and 235 can generate prediction blocks based on information related to the generation of prediction blocks provided by the entropy decoding unit 210 and previously decoded block or picture information provided by the memory 245.

[0079] As described above, similar to the operation of a video encoder, when performing intra-prediction, if the size of the prediction unit and the size of the transformation unit are the same, intra-prediction can be performed on the prediction unit based on the pixels to the left of the prediction unit, the pixels in the upper left, and the pixels at the top edge of the prediction unit. However, when performing intra-prediction, if the size of the prediction unit and the size of the transformation unit are different, intra-prediction can be performed using reference pixels based on the transformation unit. In addition, intra-prediction using N×N partitioning can be used only for the smallest coding unit.

[0080] The prediction units 230 and 235 may include a prediction unit discrimination unit, an inter-prediction unit, and an intra-prediction unit. The prediction unit discrimination unit receives various information such as prediction unit information input from the entropy decoding unit 210, prediction mode information of the intra-prediction method, and motion prediction information of the inter-prediction method, and can classify prediction units in the current coding unit and determine whether the prediction unit performs inter-prediction or intra-prediction. The inter-prediction unit 230 can use the information necessary for inter-prediction of the current prediction unit provided by the video encoder to perform inter-prediction for the current prediction unit based on information contained in at least one picture that is either a picture before or after the current picture containing the current prediction unit. Alternatively, it can perform inter-prediction based on information from several regions previously restored within the current picture containing the current prediction unit.

[0081] To perform inter-prediction, based on the coding unit, it is possible to determine whether the motion prediction method of the prediction unit included in the corresponding coding unit is Skip Mode, Merge Mode, Motion Vector Prediction Mode (AMVP Mode), or Intrablock Copy Mode.

[0082] The intra-prediction unit 235 can generate prediction blocks based on the pixel information in the current picture. If the prediction unit is the same prediction unit that performed intra-prediction, it can perform intra-prediction based on the intra-prediction mode information of the prediction unit provided by the video encoder. The intra-prediction unit 235 may include an AIS (Adaptive Intra Smoothing) filter, a reference pixel interpolation unit, and a DC filter. The AIS filter is the part that performs filtering on the reference pixels of the current block, and it can decide whether or not to apply the filter based on the prediction mode of the current prediction unit and then apply the AIS filter. Using the prediction mode of the prediction unit and the AIS filter information provided by the video encoder, AIS filtering can be performed on the reference pixels of the current block. If the prediction mode of the current block is a mode that does not perform AIS filtering, the AIS filter may not be applied.

[0083] If the prediction mode of the prediction unit is one that performs intraprediction based on pixel values ​​interpolated from reference pixels, the reference pixel interpolation unit can interpolate the reference pixels to generate reference pixels for pixel units less than or equal to integer values. If the prediction mode of the current prediction unit is one that generates prediction blocks without interpolating reference pixels, the reference pixels may not be interpolated. If the prediction mode of the current block is DC mode, the DC filter can generate prediction blocks by filtering.

[0084] The restored block or picture can be provided to the filter unit 240. The filter unit 240 may include a deblocking filter, an offset correction unit, and an ALF.

[0085] The video decoder can receive information from the video encoder regarding whether a deblocking filter has been applied to the corresponding block or picture, and, if so, whether a strong or weak filter was applied. The video decoder's deblocking filter receives the information related to the deblocking filter provided by the video encoder, and the video encoder can then perform the deblocking filter process on the corresponding block.

[0086] The offset correction unit can perform offset correction on the restored video based on the type of offset correction applied to the video and offset value information during encoding.

[0087] The ALF can be applied to the coding unit based on information provided by the encoder regarding whether or not to apply the ALF, ALF coefficient information, etc. Such ALF information can be provided in a specific set of parameters.

[0088] Memory 245 can store the restored picture or block and make it available for use as a reference picture or reference block, and can also provide the restored picture to the output unit.

[0089] Figure 3 shows a basic coding tree unit according to one embodiment of the present invention.

[0090] The largest coding block can be defined as a coding tree block. A single picture is divided into multiple coding tree units (CTUs). A coding tree unit is the largest coding unit and can also be called an LCU (Largest Coding Unit). Figure 3 shows an example where a single picture is divided into multiple coding tree units.

[0091] The size of a coding tree unit can be defined at the picture level or the sequence level. For this purpose, information indicating the size of a coding tree unit can be signaled by a picture parameter set or a sequence parameter set.

[0092] For example, the size of the coding tree unit for all pictures in a sequence can be set to 128x128. Alternatively, the size of the coding tree unit can be determined at the picture level to be either 128x128 or 256x256. For example, the coding tree unit size can be set to 128x128 for the first picture and 256x256 for the second picture.

[0093] Coding tree units can be divided to generate coding blocks. A coding block represents a basic unit for performing encoding / decoding. For example, prediction or transformation may be performed for each coding block, or a predictive encoding mode may be determined for each coding block. Here, the predictive encoding mode indicates how to generate the predicted video. For example, a predictive encoding mode may include intra-prediction, inter-prediction, current picture referencing (CPR), or intra-block copy (IBC), or combined prediction. For a coding block, a predictive block of the coding block can be generated using at least one predictive encoding mode from intra-prediction, inter-prediction, current picture referencing, or combined prediction.

[0094] Information indicating the current block's predictive encoding mode can be signaled via a bitstream. For example, this information may be a one-bit flag indicating whether the predictive encoding mode is intra-mode or inter-mode. The current picture reference or composite prediction can only be used if the current block's predictive encoding mode is determined to be inter-mode.

[0095] The current picture reference sets the current picture as the reference picture and obtains the predicted block for the current block from the already encoded / decoded region within the current picture. Here, the current picture means the picture containing the current block. Information indicating whether the current picture reference applies to the current block may be signaled via a bitstream. For example, this information may be a 1-bit flag. If the flag is true, the predicted encoding for the current block is determined to be the current picture reference; if the flag is false, the prediction mode for the current block may be determined to be interprediction.

[0096] Alternatively, the predicted encoding mode for the current block can be determined based on the reference picture index. For example, if the reference picture index points to the current picture, the predicted encoding mode for the current block can be determined as current picture reference. If the reference picture index points to a picture other than the current picture, the predicted encoding mode for the current block can be determined as inter-prediction. In other words, current picture reference is a prediction method that uses information from the region within the current picture that has been encoded / decoded, while inter-prediction is a prediction method that uses information from other pictures that have been encoded / decoded.

[0097] A composite prediction represents an encoding mode that combines one or more of the following: intra prediction, inter prediction, and current picture reference. For example, when composite prediction is applied, a first prediction block can be generated based on one of the intra prediction, inter prediction, or current picture reference, and a second prediction block can be generated based on the other one. Once the first and second prediction blocks are generated, a final prediction block can be generated through averaging or weighted summing of the first and second prediction blocks. Information indicating whether composite prediction is applied can be signaled via a bitstream. This information may be a 1-bit flag.

[0098] Figure 4 shows various ways of dividing a coding block.

[0099] A coding block can be divided into multiple coding blocks based on quad-tree, binary-tree, or triple-tree partitioning. These divided coding blocks can also be further divided into multiple coding blocks based on quad-tree, binary-tree, or triple-tree partitioning.

[0100] Quad tree partitioning is a partitioning technique that divides the current block into four blocks. As a result of quad tree partitioning, the current block can be divided into four square partitions (see Figure 4(a) "SPLIT_QT").

[0101] Binary tree partitioning is a partitioning technique that divides the current block into two blocks. Dividing the current block into two blocks along the vertical direction (i.e., using vertical lines that cross the current block) can be called vertical binary tree partitioning, and dividing the current block into two blocks along the horizontal direction (i.e., using horizontal lines that cross the current block) can be called horizontal binary tree partitioning. As a result of binary tree partitioning, the current block can be divided into two non-square partitions. Figure 4(b) "SPLIT_BT_VER" shows the result of vertical binary tree partitioning, and Figure 4(c) "SPLIT_BT_HOR" shows the result of horizontal binary tree partitioning.

[0102] Triple tree partitioning is a partitioning method that divides the current block into three blocks. Dividing the current block into three blocks along the vertical direction (i.e., using two vertical lines that cross the current block) can be called vertical triple tree partitioning, and dividing the current block into three blocks along the horizontal direction (i.e., using two horizontal lines that cross the current block) can be called horizontal triple tree partitioning. As a result of triple tree partitioning, the current block can be divided into three non-square partitions. In this case, the width / height of the partition located in the center of the current block can be twice the width / height of the other partitions. Figure 4(d) "SPLIT_TT_VER" shows the result of vertical triple tree partitioning, and Figure 4(e) "SPLIT_TT_HOR" shows the result of horizontal triple tree partitioning.

[0103] The number of divisions in a coding tree unit can be defined as the partitioning depth. The maximum partitioning depth of a coding tree unit can be determined at the sequence or picture level. As a result, the maximum partitioning depth of a coding tree unit may differ from sequence to sequence or picture to picture.

[0104] Alternatively, the maximum partitioning depth for each partitioning method can be determined individually. For example, the maximum partitioning depth allowed for a quad-tree partition may differ from the maximum partitioning depth allowed for a binary-tree partition and / or a triple-tree partition.

[0105] The encoder can signal via the bitstream information indicating at least one of the division type or division depth of the current block. The decoder can determine the division type and division depth of the coding tree unit based on the information analyzed from the bitstream.

[0106] Figure 5 shows the division patterns of the coding tree units.

[0107] The process of dividing a coding block using partitioning techniques such as quad-tree partitioning, binary-tree partitioning, and / or triple-tree partitioning can be called multi-tree partitioning.

[0108] A coding block generated by applying a multi-tree partition to a coding block can be called a sub-coding block. If the partitioning depth of the coding block is k, the partitioning depth of the sub-coding block is set to k+1.

[0109] Conversely, a coding block with a division depth of k can be referred to as a higher-level coding block compared to a coding block with a division depth of k+1.

[0110] The partition type of the current coding block can be determined based on at least one of the partition types of the parent coding block or the partition types of the adjacent coding blocks. Here, adjacent coding blocks are adjacent to the current coding block and can include at least one of the top adjacent block, left adjacent block, or adjacent block adjacent to the top left corner of the current coding block. Here, the partition type can include at least one of whether or not to perform a quad tree partition, whether or not to perform a binary tree partition, the direction of the binary tree partition, whether or not to perform a triple tree partition, or the direction of the triple tree partition.

[0111] To determine the splitting method of a coding block, information indicating whether or not the coding block will be split can be signaled via a bitstream. This information is a 1-bit flag "split_cu_flag", and if this flag is true, it indicates that the coding block will be split by a multi-tree splitting technique.

[0112] If split_cu_flag is true, information indicating whether or not the coding block can be split into a quad tree can be signaled via a bitstream. This information is a 1-bit flag split_qt_flag, and if this flag is true, the coding block can be split into four blocks.

[0113] As an example, Figure 5 shows that when a coding tree unit is quad-tree partitioned, four coding blocks with a partition depth of 1 are generated. Furthermore, it is shown that the first and fourth coding blocks of the four coding blocks generated as a result of the quad-tree partitioning are then subjected to quad-tree partitioning again. As a result, four coding blocks with a partition depth of 2 can be generated.

[0114] Furthermore, by applying a quad tree partitioning again to a coding block with a partitioning depth of 2, it is possible to generate a coding block with a partitioning depth of 3.

[0115] If a quad-tree split is not applied to a coding block, it is possible to determine whether to perform a binary tree split or a triple-tree split on the coding block by considering at least one of the following: the size of the coding block, whether the coding block is located on a picture boundary, the maximum split depth, or the split configuration of adjacent blocks. If it is determined that a binary tree split or a triple-tree split is to be performed on the coding block, information indicating the split direction may be signaled via a bitstream. This information may be a 1-bit flag mtt_split_cu_vertical_flag. Based on this flag, it is possible to determine whether the split direction is vertical or horizontal. In addition, information indicating whether a binary tree split or a triple-tree split is applied to the coding block may be signaled via a bitstream. This information may be a 1-bit flag mtt_split_cu_binary_flag. Based on this flag, it is possible to determine whether a binary tree split or a triple-tree split is applied to the coding block.

[0116] As an example, in the example shown in Figure 5, a vertical binary tree partitioning is applied to a coding block with a partitioning depth of 1. In the coding block generated by the partitioning result, a vertical triple tree partitioning is applied to the left coding block, and a vertical binary tree partitioning is applied to the right coding block.

[0117] In devices that encode or decode video, problems arise in processing areas that exceed the hardware performance threshold. For example, if the hardware can process a maximum of 4096 samples simultaneously, then in areas with more than 4096 samples, problems may arise where processing requires duplicate access to 64x64 data units, and where simultaneous data processing becomes impossible. Thus, the basic unit of data processing can be defined as a pipeline-based data unit (Virtual Processing Data Unit, VPDU, hereinafter referred to as the data unit).

[0118] Data base units can be classified into square, non-square, or rectangular types.

[0119] Figure 6 shows the basic structure of the data unit.

[0120] A data base unit can contain a number of samples equal to or less than the maximum number of samples that can be processed simultaneously. For example, a 64x64 square block can be configured in the data base unit, as shown in Figure 6(a). Alternatively, a non-square block can be configured in the data base unit. For example, a 32x128 block or a 64x32 block can be configured in the data base unit, as shown in Figure 6(b) or Figure 6(c).

[0121] Although not shown in the illustration, triangular, L-shaped, or polygonal data base units can also be defined.

[0122] Information for determining the data base unit can be signaled via a bitstream. This information may be for determining at least one of the size or shape of the data base unit. Based on this information, it can be determined whether or not to allow non-square data base units or non-rectangular data base units.

[0123] Alternatively, the encoder and decoder may predefine at least one of the size or shape of the data base unit.

[0124] Whether or not to allow a coding block partitioning configuration can be determined by considering the size of the data base unit. For example, if the resulting coding block is larger than the data base unit, the partitioning may not be allowed. Alternatively, if the resulting non-square coding block is larger than the data base unit, the partitioning may not be allowed. For example, if the width or height of a coding block is greater than a threshold, or if the number of samples contained in a coding block is greater than a threshold, binary tree partitioning or triple tree partitioning may not be allowed. This allows for the omission of encoding information regarding binary tree partitioning or triple tree partitioning.

[0125] Alternatively, you can configure the system to always split coding blocks larger than the data base unit. Or, you can configure the system to always perform binary tree splitting or triple tree splitting on coding blocks larger than the data base unit. This allows the split_flag flag, which indicates whether or not to split a coding block, to be automatically set to 1 even if it is not encoded for coding blocks larger than the data base unit.

[0126] As another example, a coding block larger than a data base unit can be divided into multiple subblocks. Here, the subblocks can be configured as prediction units, which are base units for prediction, or transformation units, which are base units for transformation and / or quantization. In this case, dividing a coding block into multiple prediction units can be defined as VPDU prediction unit partitioning, and dividing a coding block into multiple transformation units can be defined as VPDU transformation unit partitioning.

[0127] A coding block can be partitioned using either VPDU prediction unit partitioning or VPDU conversion unit partitioning. The type of coding block partitioning achieved by applying VPDU prediction unit partitioning can be set to be the same as the type of coding block partitioning achieved by applying VPDU conversion unit partitioning.

[0128] When only VPDU prediction unit partitioning is applied to a coding block, predictions are made for each subblock, but transformations and / or quantization can be performed on the coding block. In this case, the prediction mode, such as the prediction encoding mode, intra-prediction mode, or inter-prediction mode, can be determined on the coding block.

[0129] If only VPDU transformation unit partitioning is applied to a coding block, predictions are made for the subblocks, but transformations and / or quantization can be performed for each subblock.

[0130] Figures 7 and 8 illustrate examples where a coding block is divided into multiple subblocks.

[0131] Figure 7 shows the partitioning pattern when only square data base units are allowed, and Figure 8 shows the partitioning pattern when both square data base units and non-square data base units are allowed.

[0132] Assuming only square data base units are allowed, in Figures 7(a) and (b), CU0 and CU3 are defined by two different VPDUs, and CU1 is defined by four different VPDUs. This allows CU0 and CU3 to be divided into two subblocks, and CU1 to be divided into four subblocks.

[0133] Assuming that both square and non-square data base units are permitted, in Figures 8(a) and (b), CU0 and CU3 can be defined with a single VPDU, while CU1 can be defined using two different VPDUs. As a result, CU0 and CU3 are not divided into subblocks, but CU1 can be divided into two subblocks.

[0134] In this case, CU1 can be divided into square subblocks or non-square subblocks. For example, CU1 can be divided into two square subblocks based on a horizontal line dividing it vertically. Alternatively, CU1 can be divided into two non-square subblocks based on a vertical line dividing it horizontally.

[0135] If there are multiple possible partitioning types that can be applied to a coding block, information indicating one of the multiple partitioning type candidates can be signaled via the bitstream. For example, this information may indicate whether the coding block is divided into square subblocks or whether it is divided into non-square subblocks.

[0136] Alternatively, it's possible to set a higher priority for dividing a coding block into square subblocks than for dividing it into non-square subblocks. For example, dividing a coding block into non-square subblocks might be allowed only when it's not possible to divide it into square subblocks.

[0137] Alternatively, the partitioning configuration of a coding block can be determined based on the partitioning configuration of its parent node. For example, if the parent node is partitioned based on a triple tree, the coding block can be configured to be partitioned into square subblocks. On the other hand, if the parent node is partitioned based on a binary tree or a triple tree, the coding block can be configured to be partitioned into non-square subblocks.

[0138] Interpretation is a predictive encoding mode that uses information from the previous picture to predict the current block. For example, the block at the same position as the current block in the previous picture (hereinafter referred to as a collocated block) can be set as the predicted block for the current block. Hereafter, the predicted block generated based on the block at the same position as the current block will be called a collocated prediction block.

[0139] On the other hand, if an object in the previous picture moves to a different position in the current picture, the object's movement can be used to effectively predict the current block. For example, by comparing the previous picture with the current picture, if the direction and size of the object's movement can be determined, a predicted block (or predicted video) of the current block can be generated, taking the object's movement information into account. Hereafter, a predicted block generated using motion information can be referred to as a motion-predicted block.

[0140] A residual block can be generated by subtracting the predicted block from the current block. If object motion exists, using a motion prediction block instead of a collated prediction block reduces the energy of the residual block and thus improves its compression performance.

[0141] As mentioned above, generating prediction blocks using motion information can be called motion-compensated prediction. In most interpretation systems, prediction blocks can be generated based on motion-compensated prediction.

[0142] Motion information can include at least one of the following: motion vector, reference picture index, prediction direction, or bidirectional weight index. The motion vector indicates the direction and size of movement of an object. The reference picture index identifies the reference picture of the current block from among the reference pictures included in the reference picture list. The prediction direction refers to one of the following: unidirectional L0 prediction, unidirectional L1 prediction, or bidirectional prediction (L0 prediction and L1 prediction). Depending on the prediction direction of the current block, at least one of the motion information in the L0 direction or the motion information in the L1 direction can be used. The bidirectional weight index identifies the weights applied to the L0 prediction block and the weights applied to the L1 prediction block.

[0143] Figure 9 is a flowchart of an interpretation prediction method according to one embodiment of the present invention.

[0144] Referring to Figure 9, the inter-prediction method includes the steps of determining the inter-prediction mode of the current block (S901), acquiring motion information of the current block according to the determined inter-prediction mode (S902), and performing motion compensation prediction of the current block based on the acquired motion information (S903).

[0145] Here, the interpretation mode refers to various methods for determining the motion information of the current block and may include an interpretation mode that utilizes translational motion information and an interpretation mode that utilizes affine motion information. For example, the interpretation mode that utilizes translational motion information may include a merge mode and a motion vector prediction mode, while the interpretation mode that utilizes affine motion information may include an affine merge mode and an affine motion vector prediction mode. The motion information of the current block can be determined, depending on the interpretation mode, based on information analyzed from adjacent blocks or bitstreams adjacent to the current block.

[0146] The following provides a detailed explanation of an inter-prediction method that utilizes affine motion information.

[0147] Figure 10 shows the nonlinear motion of an object.

[0148] Nonlinear motion of objects can occur in video. For example, as shown in Figure 10, nonlinear motion of objects can occur through camera zoom-in, zoom-out, rotation, or affine transformation. When nonlinear motion of an object occurs, the motion of the object cannot be effectively represented by translational motion vectors. Therefore, in parts where nonlinear motion of an object occurs, affine motion can be used instead of translational motion to improve encoding efficiency.

[0149] Figure 11 is a flowchart of an inter-prediction method based on affine motion according to one embodiment of the present invention.

[0150] Whether or not an affine motion-based inter-prediction method is applied to the current block can be determined based on information analyzed from the bitstream. Specifically, the decision on whether or not an affine motion-based inter-prediction method is applied to the current block can be made based on at least one of the following flags: a flag indicating whether or not the affine merge mode is applied to the current block, or a flag indicating whether or not the affine motion vector prediction mode is applied to the current block.

[0151] When an interpretation method based on affine motion is applied to the current block, the affine motion model of the current block can be determined (S1101). The affine motion model can be determined as at least one of a 6-parameter affine motion model or a 4-parameter affine motion model. A 6-parameter affine motion model represents affine motion using six parameters, and a 4-parameter affine motion model represents affine motion using four parameters.

[0152] Equation (1) represents affine motion using six parameters. Affine motion represents translational motion within a predetermined region determined by the affine seed vector.

[0153] [Formula 1]

[0154]

number

[0155] While using six parameters to represent affine motion allows for the depiction of complex movements, the increased number of bits required for encoding each parameter can reduce encoding efficiency. Therefore, it is also possible to represent affine motion using only four parameters. Mathematical equation 2 represents affine motion using four parameters.

[0156] [Formula 2]

[0157]

number

[0158] Information for determining the affine motion model of the current block can be encoded and signaled via a bitstream. For example, this information may be a 1-bit flag "affine_type_flag". A value of 0 for the flag indicates that a 4-parameter affine motion model is applied, and a value of 1 indicates that a 6-parameter affine motion model is applied. The flag can be encoded at the slice, tile, or block level (e.g., coding block or coding tree unit). If the flag is signaled at the slice level, the affine motion model determined at the slice level can be applied to all blocks belonging to that slice.

[0159] Alternatively, the affine motion model of the current block can be determined based on the affine interpretation mode of the current block. For example, if the affine merge mode is applied, the affine motion model of the current block can be determined as a 4-parameter motion model. On the other hand, if the affine motion vector prediction mode is applied, the information for determining the affine motion model of the current block can be encoded and signaled via a bitstream. For example, if the affine motion vector prediction mode is applied to the current block, the affine motion model of the current block can be determined based on a 1-bit flag "affine_type_flag".

[0160] Next, the affine seed vector of the current block can be derived (S1102). If a 4-parameter affine motion model is selected, motion vectors can be derived at two control points of the current block. On the other hand, if a 6-parameter affine motion model is selected, motion vectors can be derived at three control points of the current block. The motion vectors at the control points can be called affine seed vectors. The control points can include at least one of the top-left corner, top-right corner, or bottom-left corner of the current block.

[0161] Figure 12 illustrates the affine seed vectors for each affine motion model.

[0162] In a parameterized affine motion model, two affine seed vectors can be derived from the upper left corner, the upper right corner, or the lower left corner. For example, as shown in Figure 12(a), if a four-parameter affine motion model is selected, the affine vectors can be derived using the affine seed vector sv0 of the upper left corner of the current block (e.g., the upper left sample (x1, y1)) and the affine seed vector sv1 of the upper right corner of the current block (e.g., the upper right sample (x1, y1)). The affine seed vector can also be used instead of the upper left corner affine seed vector, or the affine seed vector can be used instead of the upper right corner affine seed vector.

[0163] In a parameterized affine motion model, affine seed vectors for the upper left, upper right, and lower left corners can be derived. For example, as shown in Figure 12(b), if a 6-parameter affine motion model is selected, affine vectors can be derived using the affine seed vector sv0 for the upper left corner of the current block (e.g., the upper left sample (x1, y1)), the affine seed vector sv1 for the upper right corner of the current block (e.g., the upper right sample (x1, y1)), and the affine seed vector sv2 for the upper left corner of the current block (e.g., the upper left sample (x2, y2)).

[0164] In the embodiments described later, in the 4-parameter affine motion model, the affine seed vectors of the upper left control point and the upper right control point are referred to as the first affine seed vector and the second affine seed vector, respectively. In embodiments using the first and second affine seed vectors described later, at least one of the first and second affine seed vectors can be replaced with the affine seed vector of the lower left control point (third affine seed vector) or the affine seed vector of the lower right control point (fourth affine seed vector).

[0165] Furthermore, in the 6-parameter affine motion model, the affine seed vectors of the upper left control point, the upper right control point, and the lower left control point will be referred to as the first affine seed vector, the second affine seed vector, and the third affine seed vector, respectively. In embodiments that utilize the first, second, and third affine seed vectors as described later, at least one of the first, second, and third affine seed vectors can be replaced with the affine seed vector of the lower right control point (the fourth affine seed vector).

[0166] The affine vector of each subblock can be induced using the affine seed vector (S1103). Here, the affine vector represents the translational motion vector induced based on the affine seed vector. The affine vector of a subblock can be called the affine subblock motion vector or subblock motion vector.

[0167] Figure 13 illustrates the affine vectors of subblocks in a four-parameter motion model.

[0168] The affine vector of a subblock can be derived based on the position of the control point, the position of the subblock, and the affine seed vector. As an example, Equation 3 shows an example of deriving an affine subblock vector.

[0169] [Formula 3]

[0170]

number

[0171] In equation 3 above, (x, y) indicates the position of the subblock. Here, the position of the subblock indicates the position of the reference sample contained within the subblock. The reference sample can be the sample located in the upper left corner of the subblock, or the sample whose x-axis coordinate or y-axis coordinate is at the center. (x0, y0) indicates the position of the first control point, and (sv0x, sv0y) indicates the first affine seed vector. (x1, y1) indicates the position of the second control point, and (sv1x, sv1y) indicates the second affine seed vector.

[0172] If the first and second control points correspond to the top-left and top-right corners of the current block, respectively, then x1-x0 can be set to the same value as the width of the current block.

[0173] Subsequently, motion compensation prediction for each subblock can be performed using the affine vector of each subblock (S1104). As a result of the motion compensation prediction, prediction blocks for each subblock can be generated. The prediction blocks of the subblocks can be set as the prediction blocks of the current block.

[0174] Next, we will explain in detail the interpretation method that utilizes translational motion information.

[0175] The motion information of the current block can be derived from the motion information of other blocks. Here, the other blocks can be blocks that were encoded / decoded by interpretation before the current block. Setting the motion information of the current block to be the same as the motion information of other blocks can be defined as merge mode. Alternatively, setting the motion vector of other blocks to the predicted value of the motion vector of the current block can be defined as motion vector prediction mode.

[0176] Figure 14 is a flowchart showing the process of deriving the movement information of the current block in merge mode.

[0177] Candidates for merging the current block can be derived (S1401). Candidates for merging the current block can be derived from blocks encoded / decoded by interpretation prior to the current block.

[0178] Figure 15 illustrates candidate blocks used to guide merge candidates.

[0179] A candidate block may include at least one adjacent block containing samples adjacent to the current block, or a non-adjacent block containing samples not adjacent to the current block. Hereinafter, the sample used to determine a candidate block will be defined as the reference sample. A reference sample adjacent to the current block will be referred to as the adjacent reference sample, and a reference sample not adjacent to the current block will be referred to as the non-adjacent reference sample.

[0180] An adjacent reference sample can be located in the adjacent column to the leftmost column of the current block or in the adjacent row to the topmost row of the current block. For example, if the coordinates of the top-left sample of the current block are (0, 0), then at least one of the following blocks can be used as a candidate block: the block containing the reference sample at position (-1, H-1), the block containing the reference sample at position (W-1, -1), the block containing the reference sample at position (W, -1), the block containing the reference sample at position (-1, H), or the block containing the reference sample at position (-1, -1). Referring to the diagram, adjacent blocks with indices 0 to 4 can be used as candidate blocks.

[0181] A non-adjacent reference sample is a sample whose x-axis distance or y-axis distance from an adjacent reference sample to the current block is a predefined value. For example, at least one of the following can be used as a candidate block: a block containing a reference sample whose x-axis distance from the left reference sample is a predefined value; a block containing a non-adjacent sample whose y-axis distance from the top reference sample is a predefined value; or a block containing a non-adjacent sample whose x-axis and y-axis distances from the top-left reference sample are predefined values. The predefined value can be a natural number such as 4, 8, 12, or 16. Referring to the diagram, at least one of the blocks with indices 5 through 26 can be used as a candidate block.

[0182] Samples that are not located on the same vertical, horizontal, or diagonal line as adjacent reference samples can also be designated as non-adjacent reference samples.

[0183] Figure 16 shows the position of the reference sample.

[0184] As shown in the example in Figure 16, the x-coordinate of the upper end non-adjacent reference sample can be set to be different from the x-coordinate of the upper end adjacent reference sample. For example, if the position of the upper end adjacent reference sample is (W-1, -1), the position of the upper end non-adjacent reference sample located N away from the upper end adjacent reference sample in the y-axis direction can be set to ((W / 2)-1, -1-N), and the position of the upper end non-adjacent reference sample located 2N away from the upper end adjacent reference sample in the y-axis direction can be set to (0, -1-2N). In other words, the position of the non-adjacent reference sample can be determined based on the position of the adjacent reference sample and the distance to the adjacent reference sample.

[0185] Hereafter, candidate blocks that contain adjacent criterion samples will be referred to as adjacent blocks, and blocks that contain non-adjacent criterion samples will be referred to as non-adjacent blocks.

[0186] If the distance between the current block and a candidate block exceeds a threshold, the candidate block can be set to be unavailable as a merge candidate. The threshold can be determined based on the size of the coding tree unit. For example, the threshold can be set to the height of the coding tree unit (ctu_height) or a value obtained by adding or subtracting an offset from the height of the coding tree unit (e.g., ctu_height±N). The offset N is a value already defined in the encoder and decoder and can be set to 4, 8, 16, 32, or ctu_height.

[0187] If the difference between the y-axis coordinate of the current block and the y-axis coordinate of the sample included in the candidate block is greater than a threshold, the candidate block can be determined to be unavailable as a merge candidate.

[0188] Alternatively, candidate blocks that do not belong to the same coding tree unit as the current block can be configured to be unavailable as merge candidates. For example, if a reference sample exceeds the upper boundary of the coding tree unit to which the current block belongs, candidate blocks containing the reference sample can be configured to be unavailable as merge candidates.

[0189] If the top boundary of the current block is adjacent to the top boundary of a coding tree unit, many candidate blocks may be deemed unavailable as merge candidates, potentially reducing the encoding / decoding efficiency of the current block. To address this issue, candidate blocks can be configured such that the number of candidate blocks located to the left of the current block is greater than the number of candidate blocks located at the top of the current block.

[0190] Figure 17 illustrates candidate blocks used to guide merge candidates.

[0191] As shown in the example in Figure 17, the top-end blocks belonging to the top N block rows of the current block and the left-side blocks belonging to the left M block rows of the current block can be set as candidate blocks. In this case, M can be set to be larger than N, so that the number of left-side candidate blocks is larger than the number of top-end candidate blocks.

[0192] For example, the difference between the y-axis coordinate of the reference sample within the current block and the y-axis coordinate of the uppermost block that can be used as a candidate block can be set so as not to exceed N times the height of the current block. Similarly, the difference between the x-axis coordinate of the reference sample within the current block and the x-axis coordinate of the leftmost block that can be used as a candidate block can be set so as not to exceed M times the width of the current block.

[0193] As an example, in the example shown in Figure 17, the blocks belonging to the top two block columns of the current block and the blocks belonging to the five block columns to the left of the current block are shown as candidate blocks.

[0194] As another example, if the candidate block and the current block do not belong to the same coding tree unit, a merge candidate can be guided by using a block that belongs to the same coding tree unit as the current block or a block containing a reference sample adjacent to the boundary of the coding tree unit, instead of the candidate block.

[0195] Figure 18 shows an example where the position of the reference sample is changed.

[0196] If a reference sample is located in a different coding tree unit than the current block, and the reference sample is not adjacent to the boundary of the coding tree unit, a candidate block can be determined by using a reference sample adjacent to the boundary of the coding tree unit instead of the reference sample.

[0197] For example, in the examples shown in Figure 18(a) and (b), if the upper boundary of the current block touches the upper boundary of the coding tree unit, the reference sample at the top of the current block will belong to a different coding tree unit than the current block. In a reference sample belonging to a different coding tree unit than the current block, a reference sample that is not adjacent to the upper boundary of the coding tree unit can be replaced with a sample that is adjacent to the upper boundary of the coding tree unit.

[0198] For example, as shown in Figure 18(a), the reference sample at position 6 can be replaced with the sample at position 6' located at the upper boundary of the coding tree unit, and as shown in Figure 18(b), the reference sample at position 15 can be replaced with the sample at position 15' located at the upper boundary of the coding tree unit. In this case, the y-coordinate of the alternative sample is changed to an adjacent position in the coding tree unit, and the x-coordinate of the alternative sample can be set to be the same as that of the reference sample. For example, the sample at position 6' can have the same x-coordinate as the sample at position 6, and the sample at position 15' can have the same x-coordinate as the sample at position 15.

[0199] Alternatively, the x-coordinate of the alternative sample can be set by adding or subtracting an offset from the x-coordinate of the reference sample. For example, if the x-coordinates of an adjacent reference sample and a non-adjacent reference sample located at the top edge of the block are the same, the x-coordinate of the alternative sample can be set by adding or subtracting an offset from the x-coordinate of the reference sample. This is to prevent the alternative sample that replaces a non-adjacent reference sample from being in the same position as another non-adjacent reference sample or an adjacent standard sample.

[0200] Figure 19 shows an example where the position of the reference sample is changed.

[0201] When replacing a reference sample located in a different coding tree unit than the current block and not adjacent to the coding tree unit boundary with a sample located at the coding tree unit boundary, the x-coordinate of the replacement sample can be set to a value obtained by adding or subtracting an offset from the x-coordinate of the reference sample.

[0202] As an example, in the example shown in Figure 19, the reference sample at position 6 and the reference sample at position 15 can be replaced with the sample at position 6' and the sample at position 15', respectively, whose y-coordinates are the same as the row adjacent to the upper boundary of the coding tree unit. In this case, the x-coordinate of the sample at position 6' can be set to a value obtained by subtracting W / 2 from the x-coordinate of the reference sample at position 6, and the x-coordinate of the sample at position 15' can be set to a value obtained by subtracting W-1 from the x-coordinate of the reference sample at position 15.

[0203] Unlike the examples shown in Figures 18 and 19, the y-coordinate of the row located at the top edge of the topmost row of the current block, or the y-coordinate of the top boundary of the coding tree unit, can also be set as the y-coordinate of the alternative sample.

[0204] Although not shown in the diagram, the sample to replace the reference sample can also be determined based on the left boundary of the coding tree unit. For example, if the reference sample is not included in the same coding tree unit as the current block and is not adjacent to the left boundary of the coding tree unit, the reference sample can be replaced with a sample adjacent to the left boundary of the coding tree unit. In this case, the replacement sample can have the same y-coordinate as the reference sample, or a y-coordinate obtained by adding or subtracting an offset from the y-coordinate of the reference sample.

[0205] Subsequently, blocks containing alternative samples can be set as candidate blocks, and merge candidates for the current block can be guided based on these candidate blocks.

[0206] It is also possible to derive merge candidates from temporally adjacent blocks contained in a different picture from the current block. For example, merge candidates can be derived from collated blocks contained in a collated picture.

[0207] The motion information for merge candidates can be set in the same way as the motion information for candidate blocks. For example, at least one of the candidate block's motion vector, reference picture index, or predicted direction or bidirectional weight index can be set as the motion information for merge candidates.

[0208] A list of merge candidates, including merge candidates, can be generated (S1402). The merge candidates can be divided into adjacent merge candidates derived from adjacent blocks adjacent to the current block and non-adjacent merge candidates derived from non-adjacent blocks.

[0209] The indices of merge candidates in the merge candidate list can be assigned in a predetermined order. For example, the index assigned to an adjacent merge candidate may be smaller than the index assigned to a non-adjacent merge candidate. Alternatively, an index can be assigned to each merge candidate based on the index of each block illustrated in Figure 15 or Figure 17.

[0210] If a merge candidate includes multiple merge candidates, at least one of the multiple merge candidates can be selected (S1403). In this case, information indicating whether the current block's motion information is derived from an adjacent merge candidate can be signaled via the bitstream. This information can be a 1-bit flag. For example, a syntax element, isAdjancentMergeFlag, which indicates whether the current block's motion information is derived from an adjacent merge candidate, can be signaled via the bitstream. If the value of the syntax element isAdjancentMergeFlag is 1, the current block's motion information can be derived based on an adjacent merge candidate. On the other hand, if the value of the syntax element isAdjancentMergeFlag is 0, the current block's motion information can be derived based on a non-adjacent merge candidate.

[0211] Table 1 shows the syntax table including the syntactic element isAdjancentMergeFlag.

[0212] [Table 1]

[0213] Information to identify one of several merge candidates can be signaled via a bitstream. For example, information indicating the index of one of the merge candidates included in the merge candidate list can be signaled via a bitstream.

[0214] If isAdjacentMergeflag is 1, the syntax element merge_idx, which identifies one of the adjacent merge candidates, can be signaled. The maximum value of the syntax element merge_idx can be set to the number of adjacent merge candidates minus 1.

[0215] If isAdjacentMergeflag is 0, the syntax element NA_merge_idx may be signaled, which identifies one of the non-adjacent merge candidates. The syntax element NA_merge_idx represents the difference between the index of the non-adjacent merge candidate and the number of adjacent merge candidates. The decoder can select a non-adjacent merge candidate by adding the number of adjacent merge candidates to the index identified by NA_merge_idx.

[0216] If the number of merge candidates in the merge candidate list is less than a threshold, merge candidates included in the inter-region motion information table can be added to the merge candidate list. Here, the threshold can be the maximum number of merge candidates that the merge candidate list can contain, or the maximum number of merge candidates minus an offset. The offset can be a natural number such as 1 or 2. The inter-region motion information table may include merge candidates derived based on blocks encoded / decoded before the current block.

[0217] The inter-region motion information table contains merge candidates derived from blocks encoded / decoded based on inter-predictions within the current picture. For example, the motion information of merge candidates included in the inter-region motion information table can be set in the same way as the motion information of blocks encoded / decoded based on inter-predictions. Here, the motion information can include at least one of the following: a motion vector, a reference picture index, or a prediction direction or bidirectional weight index.

[0218] For convenience, merge candidates included in the inter-domain motion information table will be referred to as inter-domain merge candidates.

[0219] The maximum number of merge candidates included in the inter-domain motion information table can be predefined in the encoder and decoder. For example, the maximum number of merge candidates included in the inter-domain motion information table can be 1, 2, 3, 4, 5, 6, 7, 8 or more (e.g., 16).

[0220] Alternatively, information indicating the maximum number of merge candidates in the inter-region motion information table can be signaled via a bitstream. This information can be signaled at the sequence, picture, or slice level.

[0221] Alternatively, the maximum number of merge candidates for the inter-region motion information table can be determined based on the picture size, slice size, or coding tree unit size.

[0222] The inter-region motion information table can be initialized at the picture, slice, tile, brick, coding tree unit, or coding tree unit line (row or column) level. For example, when a slice is initialized, the inter-region motion information table is also initialized, and the inter-region motion information table may not contain any merge candidates.

[0223] Alternatively, information indicating whether or not to initialize the inter-region motion information table may be signaled via a bitstream. This information may be signaled at the slice, tile, brick, or block level. An already configured inter-region motion information table may be used before the information instructs the initialization of the inter-region motion information table.

[0224] Alternatively, information regarding initial inter-region merge candidates can be signaled via the picture parameter set or slice header. Even after the slice has been initialized, the inter-region motion information table can still contain initial inter-region merge candidates. Therefore, inter-region merge candidates can be used for the first block to be encoded / decoded within the slice.

[0225] Blocks can be encoded / decoded in the encoding / decoding order, and based on inter-region prediction, the encoded / decoded blocks can be sequentially set as inter-region merge candidates in the encoding / decoding order.

[0226] Figure 20 shows the process of updating the inter-domain motion information table.

[0227] If an inter-region merge prediction is performed on the current block (S2001), inter-region merge candidates can be guided based on the current block (S2002). The movement information of the inter-region merge candidates can be set in the same way as the movement information of the current block.

[0228] If the inter-region motion information table is empty (S2003), inter-region merge candidates induced based on the current block can be added to the inter-region motion information table (S2004).

[0229] If the inter-domain motion information table already contains inter-domain merge candidates (S2003), a redundancy check can be performed on the motion information of the current block (or the inter-domain merge candidates derived based on this) (S2005). The redundancy check is to determine whether the motion information of the inter-domain merge candidates already stored in the inter-domain motion information table is the same as the motion information of the current block. The redundancy check can be performed on all inter-domain merge candidates already stored in the inter-domain motion information table. Alternatively, the redundancy check can be performed on inter-domain merge candidates whose index in the inter-domain merge candidates already stored in the inter-domain motion information table is above or below a threshold.

[0230] If no interpredictive merge candidates with the same motion information as the current block are included, interregional merge candidates derived based on the current block can be added to the interregional motion information table (S2008). Whether or not interpredictive merge candidates are the same can be determined based on whether or not their motion information (e.g., motion vectors and / or reference picture indices) is the same.

[0231] At this time, if the inter-region motion information table already contains the maximum number of inter-region merge candidates (S2006), the oldest inter-region merge candidate can be deleted (S2007), and an inter-region merge candidate derived based on the current block can be added to the inter-region motion information table (S2008).

[0232] Each inter-region merge candidate can be identified by an index. When an inter-region merge candidate derived from the current block is added to the inter-region motion information table, the lowest index (e.g., 0) can be assigned to the inter-region merge candidate, and the indices of already stored inter-region merge candidates can be incremented by 1. At this time, if the inter-region motion information table has already stored the maximum number of inter-predicted merge candidates, the inter-region merge candidate with the highest index is removed.

[0233] Alternatively, if an inter-region merge candidate derived from the current block is added to the inter-region motion information table, the largest possible index can be assigned to the inter-region merge candidate. For example, if the number of inter-predictive merge candidates already stored in the inter-region motion information table is less than the maximum value, the inter-region merge candidate can be assigned an index equal to the number of inter-predictive merge candidates already stored. Alternatively, if the number of inter-predictive merge candidates already stored in the inter-region motion information table is equal to the maximum value, the inter-region merge candidate can be assigned an index equal to the maximum value minus 1. The inter-region merge candidate with the smallest index is removed, and the indices of the remaining already stored inter-region merge candidates are decreased by 1 each.

[0234] Figure 21 shows the process of updating the inter-region merge candidate table.

[0235] Assume that inter-region merge candidates derived from the current block are added to the inter-region merge candidate table, and that the largest possible index is assigned to each inter-region merge candidate. Also, assume that the inter-region merge candidate table already contains the maximum number of inter-region merge candidates.

[0236] When adding the inter-region merge candidate HmvpCand[n + 1] derived from the current block to the inter-region merge candidate table HmvpCandList, the inter-region merge candidate HmvpCand[0], which has the smallest index among the already stored inter-region merge candidates, can be deleted, and the indices of the remaining inter-region merge candidates can be decreased by 1 each time. Furthermore, the index of the inter-region merge candidate HmvpCand[n + 1] derived from the current block can be set to its maximum value (n in the example shown in Figure 21).

[0237] If the same inter-region merge candidate derived based on the current block is already stored (S2005), it is not necessary to add the inter-region merge candidate derived based on the current block to the inter-region motion information table (S2009).

[0238] Alternatively, it is possible to add inter-region merge candidates derived based on the current block to the inter-region motion information table while deleting already stored inter-region merge candidates that are the same as the aforementioned inter-region merge candidates. In this case, the same effect is achieved as updating the index of the already stored inter-region merge candidates.

[0239] Figure 22 shows an example where the index of already stored inter-area merge candidates is updated.

[0240] If there is an already stored inter-region merge candidate whose index hIdx is the same as the inter-region merge candidate mvCand derived based on the current block, the already stored inter-region merge candidate can be deleted, and the index of any inter-region merge candidates whose index is greater than hIdx can be decreased by 1. As an example, in the example shown in Figure 22, HmvpCand[2], which is the same as mvCand, is deleted from the inter-region motion information table HvmpCandList, and the indices from HmvpCand[3] to HmvpCand[n] are decreased by 1 each.

[0241] Then, the inter-region merge candidate mvCand, induced based on the current block, can be added to the end of the inter-region motion information table.

[0242] Alternatively, you can update the index assigned to an already stored inter-region merge candidate that is the same as the inter-region merge candidate induced based on the current block. For example, you can change the index of an already stored inter-region merge candidate to its minimum or maximum value.

[0243] Motion information for blocks included in a predetermined area can be configured not to be added to the inter-area motion information table. For example, inter-area merge candidates derived based on the motion information of blocks included in the merge processing area can not be added to the inter-area motion information table. If the encoding / decoding order is not defined for the blocks included in the merge processing area, and it is inappropriate to use the motion information of any one of these blocks when predicting inter-area movement for other blocks, then inter-area merge candidates derived based on the blocks included in the merge processing area can not be added to the inter-area motion information table.

[0244] When motion compensation prediction is performed in a subblock unit, inter-region merge candidates can be guided based on the motion information of a representative subblock among the multiple subblocks included in the current block. For example, when a subblock merge candidate is used for the current block, inter-region merge candidates can be guided based on the motion information of a representative subblock among the subblocks.

[0245] The motion vectors of subblocks can be derived in the following order: First, one of the merge candidates included in the current block's merge candidate list can be selected, and an initial shift vector (shVector) can be derived based on the motion vector of the selected merge candidate. Then, by adding the initial shift vector to the position (xSb, ySb) of the reference sample (e.g., the top-left sample or the sample in the middle) of each subblock in the coding block, a shift subblock with the reference sample position (xColSb, yColSb) can be derived. Equation 4 below shows the formula for deriving the shift subblock.

[0246] [Formula 4]

[0247]

number

[0248] Then, the motion vector of the collated block corresponding to the center position of the subblock containing (xColSb, yColSb) can be set as the motion vector of the subblock containing (xSb, ySb).

[0249] A representative subblock can refer to a subblock containing the top-left or center sample of the current block.

[0250] Figure 23 shows the location of the representative subblock.

[0251] Figure 23(a) shows an example where a subblock located in the upper left of the current block is set as the representative subblock, and Figure 23(b) shows an example where a subblock located in the center of the current block is set as the representative subblock. When motion compensation prediction is performed in the subblock unit, inter-region merge candidates for the current block can be derived based on the motion vector of the subblock containing the sample in the upper left of the current block or the subblock containing the sample in the center of the current block.

[0252] Based on the current block's inter-prediction mode, it is also possible to determine whether or not to use the current block as an inter-region merge candidate. For example, blocks encoded / decoded based on an affine motion model can be configured not to be used as inter-region merge candidates. Therefore, even if the current block is encoded / decoded by inter-prediction, if the current block's inter-prediction mode is affine prediction mode, the inter-prediction motion information table may not be updated based on the current block.

[0253] Alternatively, inter-region merge candidates can be derived based on at least one subblock vector from among the subblocks contained within a block encoded / decoded based on an affine motion model. For example, inter-region merge candidates can be derived using a subblock located in the upper left, center, or upper right of the current block. Alternatively, the average value of the subblock vectors of multiple subblocks can be set as the motion vector for the inter-region merge candidate.

[0254] Alternatively, inter-region merge candidates can be derived based on the average value of the affine seed vectors of the blocks encoded / decoded based on the affine motion model. For example, the average of at least one of the first, second, or third affine seed vectors of the current block can be set as the motion vector for the inter-region merge candidate.

[0255] Alternatively, an inter-domain motion information table can be configured for each inter-prediction mode. For example, at least one of the following can be defined: an inter-domain motion information table for blocks encoded / decoded by intra-block copying, an inter-domain motion information table for blocks encoded / decoded based on a translational motion model, or an inter-domain motion information table for blocks encoded / decoded based on an affine motion model. Depending on the inter-prediction mode of the current block, one of several inter-domain motion information tables can be selected.

[0256] Figure 24 shows an example in which an inter-domain motion information table is generated for each inter-prediction mode.

[0257] If a block is encoded / decoded based on a non-fine motion model, the inter-region merge candidate mvCand derived from the block can be added to the inter-region non-fine motion information table HmvpCandList. On the other hand, if a block is encoded / decoded based on an affine motion model, the inter-region merge candidate mvAfCand derived from the block can be added to the inter-region affine motion information table HmvpAfCandList.

[0258] Inter-region merge candidates derived from blocks encoded / decoded based on an affine motion model can store the affine seed vector of the said block. Therefore, these inter-region merge candidates can be used as merge candidates to derive the affine seed vector of the current block.

[0259] In addition to the inter-domain motion information table described above, an additional inter-domain motion information table can also be defined. In addition to the inter-domain motion information table described above (hereinafter referred to as the first inter-domain motion information table), a long-term motion information table (hereinafter referred to as the second inter-domain motion information table) can be defined. Here, the long-term motion information table includes long-term merge candidates.

[0260] If both the first and second inter-domain motion information tables are empty, inter-domain merge candidates can first be added to the second inter-domain motion information table. Only after the number of available inter-domain merge candidates in the second inter-domain motion information table reaches the maximum number can inter-domain merge candidates be added to the first inter-domain motion information table.

[0261] Alternatively, a single inter-prediction merge candidate can be added to both the second inter-domain motion information table and the first inter-domain motion information table.

[0262] At this point, the second inter-region motion information table, once configured, may not be updated further. Alternatively, the second inter-region motion information table may be updated if the decoded region exceeds a predetermined ratio of the slice. Alternatively, the second inter-region motion information table may be updated for every N coding tree unit lines.

[0263] On the one hand, the first inter-region motion information table can be updated every time a block encoded / decoded by inter-prediction occurs. However, the inter-region merge candidates added to the second inter-region motion information table can also be set so as not to be used for updating the first inter-region motion information table.

[0264] Information for selecting either one of the first inter-region motion information table or the second inter-region motion information table can be signaled via a bitstream. When the number of merge candidates included in the merge candidate list is smaller than a threshold value, the merge candidates included in the inter-region motion information table indicated by the information can be added to the merge candidate list.

[0265] Alternatively, the inter-region motion information table can also be selected based on the size, shape, inter-prediction mode, whether to perform bidirectional prediction, whether to refine the motion vector, or whether to perform triangular partitioning of the current block.

[0266] Alternatively, even if the inter-region merge candidates included in the first inter-region motion information table are added, when the number of merge candidates included in the merge candidate list is smaller than the maximum merge number, the inter-region merge candidates included in the second inter-region motion information table can be added to the merge candidate list.

[0267] FIG. 25 is a diagram showing an example in which the inter-region merge candidates included in the long-term motion information table are added to the merge candidate list.

[0268] If the number of merge candidates in the merge candidate list is less than the maximum number, the inter-region merge candidates contained in the first inter-region motion information table HmvpCandList can be added to the merge candidate list. If, even after adding the inter-region merge candidates contained in the first inter-region motion information table to the merge candidate list, the number of merge candidates in the merge candidate list is still less than the maximum number, the inter-region merge candidates contained in the long-term motion information table HmvpLTCandList can be added to the merge candidate list.

[0269] Table 2 shows the process of adding inter-region merge candidates included in the long-term motion information table to the merge candidate list.

[0270] [Table 2]

[0271] Inter-region merge candidates can be configured to include additional information in addition to movement information. For example, inter-region merge candidates can store additional information such as block size, shape, or block partition information. When configuring the current block's merge candidate list, only inter-predictive merge candidates with the same or similar size, shape, or partition information as the current block can be used, or inter-predictive merge candidates with the same or similar size, shape, or partition information as the current block can be added to the merge candidate list first.

[0272] Alternatively, an inter-region motion information table can be generated for each block size, shape, or partition information. A list of merge candidates for the current block can be generated using the inter-region motion information table that matches the current block's shape, size, or partition information from among multiple inter-region motion information tables.

[0273] If the number of merge candidates in the current block's merge candidate list is less than a threshold, inter-region merge candidates included in the inter-region motion information table can be added to the merge candidate list. This addition process is performed in ascending or descending order based on index. As an example, the inter-region merge candidate with the highest index can be added to the merge candidate list first.

[0274] When attempting to add an inter-region merge candidate included in the inter-region motion information table to the merge candidate list, a redundancy check can be performed between the inter-region merge candidate and any merge candidates already stored in the merge candidate list.

[0275] As an example, Table 3 shows the process by which inter-region merge candidates are added to the merge candidate list.

[0276] [Table 3]

[0277] Redundancy checks can be performed only on a subset of inter-region merge candidates included in the inter-region motion information table. For example, redundancy checks can be performed only on inter-region merge candidates whose index is above or below a threshold. Alternatively, redundancy checks can be performed only on the N merge candidates with the largest index or the N merge candidates with the smallest index.

[0278] Alternatively, redundancy checks can be performed on only a subset of the merge candidates already stored in the merge candidate list. For example, redundancy checks can be performed only on merge candidates whose index is above or below a threshold, or on merge candidates derived from a block at a specific location. Here, the specific location may include at least one of the left-side adjacent block, top-side adjacent block, top-right adjacent block, or bottom-left adjacent block of the current block.

[0279] Figure 26 shows an example where redundancy checks are performed on only a portion of the merge candidates.

[0280] When attempting to add the inter-region merge candidate HmvpCand[j] to the merge candidate list, a redundancy check can be performed on the inter-region merge candidate against the two merge candidates with the highest indices, mergeCandList[NumMerge-2] and mergeCandList[NumMerge-1], where NumMerge can indicate the number of available spatial and temporal merge candidates.

[0281] Unlike the illustrated example, when attempting to add the inter-region merge candidate HmvpCand[j] to the merge candidate list, a redundancy check can also be performed on the inter-region merge candidate against up to two merge candidates with the smallest index. For example, it can be checked whether mergeCandList[0] and mergeCandList[1] are the same as HmvpCand[j]. Alternatively, a redundancy check can be performed only on merge candidates induced from a specific location. For example, a redundancy check can be performed on at least one of the merge candidates induced from a peripheral block located to the left of the current block or from a peripheral block located at the top edge of the current block. If no merge candidates induced from a specific location exist in the merge candidate list, the inter-region merge candidate can be added to the merge candidate list without a redundancy check.

[0282] If the same merge candidate as the first inter-area merge candidate is found, when performing a redundancy check on the second inter-area merge candidate, the redundancy check with the same merge candidate as the first inter-area merge candidate can be omitted.

[0283] Figure 27 shows an example where redundancy checks with a specific merge candidate were omitted.

[0284] When attempting to add an inter-region merge candidate HmvpCand[i] with index i to the merge candidate list, a redundancy check is performed between the inter-region merge candidate and the merge candidates already stored in the merge candidate list. At this time, if the same merge candidate mergeCandList[j] as the inter-region merge candidate HmvpCand[i] is found, instead of adding the inter-region merge candidate HmvpCand[i] to the merge candidate list, a redundancy check can be performed between the inter-region merge candidate HmvpCand[i - 1] with index i - 1 and the merge candidate. At this time, the redundancy check between the inter-region merge candidate HmvpCand[i - 1] and the merge candidate mergeCandList[j] can be omitted.

[0285] As an example, in the example shown in FIG. 27, it is determined that HmvpCand[i] and mergeCandList[2] are the same. Therefore, HmvpCand[i] is not added to the merge candidate list, and a redundancy check of HmvpCand[i - 1] can be performed. At this time, the redundancy check between HvmpCand[i - 1] and mergeCandList[2] can be omitted.

[0286] When the number of merge candidates included in the merge candidate list of the current block is smaller than the threshold, in addition to the inter-region merge candidates, it may further include at least one of the pairwise merge candidates or zero merge candidates. The pairwise merge candidate means a merge candidate having a motion vector that is an average value of the motion vectors of two or more merge candidates, and the zero merge candidate means a merge candidate having a motion vector of 0.

[0287] The merge candidate list of the current block can have merge candidates added in the following procedure.

[0288] Spatial merge candidate - Temporal merge candidate - Inter-region merge candidate - (Inter-region affine merge candidate) - Pairwise merge candidate - Zero merge candidate

[0289] Spatial merge candidates refer to merge candidates derived from at least one adjacent or non-adjacent block, while temporal merge candidates refer to merge candidates derived from the previous reference picture. Inter-region affine merge candidates indicate inter-region merge candidates derived from blocks encoded / decoded in the affine motion model.

[0290] The inter-domain motion information table can also be used in motion vector prediction mode. For example, if the number of motion vector prediction candidates currently included in the block's motion vector prediction candidate list is less than a threshold, the inter-domain merge candidates included in the inter-domain motion information table can be set as the motion vector prediction candidates for the current block. Specifically, the motion vectors of the inter-domain merge candidates can be set as motion vector prediction candidates.

[0291] When one of the motion vector prediction candidates included in the current block's motion vector prediction candidate list is selected, the selected candidate can be set as the motion vector predictor for the current block. Subsequently, after decoding the motion vector residual value of the current block, the motion vector of the current block can be obtained by adding the motion vector predictor and the motion vector residual value.

[0292] The current block's motion vector prediction candidate list can be structured in the following order.

[0293] Spatial motion vector prediction candidate - Temporal motion vector prediction candidate - Inter-domain merge candidate - (Inter-domain affine merge candidate) - Zero motion vector prediction candidate

[0294] Spatial motion vector prediction candidates refer to motion vector prediction candidates derived from at least one of adjacent or non-adjacent blocks, while temporal motion vector prediction candidates refer to motion vector prediction candidates derived from the previous reference picture. Inter-region affine merge candidates indicate inter-region motion vector prediction candidates derived from blocks encoded / decoded in the affine motion model. Zero motion vector prediction candidates indicate candidates whose motion vector value is 0.

[0295] When a merge candidate for the current block is selected, the motion vector of the selected merge candidate is set as the initial motion vector, and motion compensation prediction for the current block can be performed using the motion vector induced by adding or subtracting an offset vector to the initial motion vector. Inducing a new motion vector by adding or subtracting an offset vector to the motion vector of the merge candidate can be defined as a merge offset vector encoding method.

[0296] Information indicating whether or not to use the merge offset encoding method can be signaled via a bitstream. This information can be a 1-bit flag, merge_offset_vector_flag. For example, a value of merge_offset_vector_flag of 1 indicates that the merge offset vector encoding method is applied to the current block. If the merge offset vector encoding method is applied to the current block, the motion vector of the current block can be derived by adding or subtracting the offset vector to the motion vector of the merge candidate. A value of merge_offset_vector_flag of 0 indicates that the merge offset vector encoding method is not applied to the current block. If the merge offset vector encoding method is not applied, the motion vector of the merge candidate can be set as the motion vector of the current block.

[0297] The flag can only be signaled if the value of the skip flag, which indicates whether skip mode is applied, is true, or if the value of the merge flag, which indicates whether merge mode is applied, is true. For example, if the value of skip_flag, which indicates that skip mode is applied to the current block, is 1, or if the value of merge_flag, which indicates that merge mode is applied to the current block, is 1, then merge_offset_vector_flag can be encoded and signaled.

[0298] If it is determined that the merge offset encoding method should be applied to the current block, at least one of the following may be added as a signal ring: information identifying one of the merge candidates included in the merge candidate list, information indicating the magnitude of the offset vector, or information indicating the direction of the offset vector.

[0299] Information to determine the maximum number of merge candidates that a merge candidate list can contain can be signaled via a bitstream. For example, the maximum number of merge candidates that a merge candidate list can contain can be set to a natural number less than or equal to 6.

[0300] If it is determined that the merge offset encoding method is applied to the current block, only the maximum number of merge candidates already set can be set as the initial motion vector for the current block. In other words, the number of merge candidates available to the current block can be adaptively determined depending on whether or not the merge offset encoding method is applied. For example, if the value of merge_offset_vector_flag is set to 0, the maximum number of merge candidates available to the current block is set to M, but if the value of merge_offset_vector_flag is set to 1, the maximum number of merge candidates available to the current block can be set to N. Here, M represents the maximum number of merge candidates that the merge candidate list can contain, and N represents a natural number that is the same as or less than M.

[0301] For example, if M is 6 and N is 2, the two merge candidates with the smallest indices from the merge candidate list can be set as available for the current block. Therefore, the motion vector of the merge candidate with an index value of 0 or the motion vector of the merge candidate with an index value of 1 can be set as the initial motion vector of the current block. If M and N are the same (for example, if M and N are both 2), all merge candidates included in the merge candidate list can be set as available for the current block.

[0302] Alternatively, whether adjacent blocks are available as merge candidates can be determined based on whether the merge offset vector encoding method is applied to the current block. For example, if the value of merge_offset_vector_flag is 1, at least one of the adjacent blocks adjacent to the upper right corner or the lower left corner of the current block can be set to be unavailable as a merge candidate. Therefore, if the merge offset vector encoding method is applied to the current block, at least one of the adjacent blocks adjacent to the upper right corner or the lower left corner of the current block cannot be set as the initial motion vector. Alternatively, if the value of merge_offset_vector_flag is 1, the temporally adjacent blocks of the current block can be set to be unavailable as merge candidates.

[0303] When the merge offset vector encoding method is applied to the current block, it can be configured not to utilize at least one of the pairwise merge candidates or zero merge candidates. Therefore, if the value of merge_offset_vector_flag is 1, at least one of the pairwise merge candidates or zero merge candidates may not be added to the merge candidate list, even if the number of merge candidates included in the merge candidate list is less than the maximum number.

[0304] The motion vector of a merge candidate can be set as the initial motion vector of the current block. If the current block has multiple available merge candidates, information identifying one of these candidates can be signaled via the bitstream. For example, if the maximum number of merge candidates that the merge candidate list can contain is greater than 1, information `merge_idx` pointing to one of the multiple merge candidates can be signaled via the bitstream. That is, the merge candidate can be identified via `merge_idx`, which identifies one of the multiple merge candidates, depending on the merge offset encoding method. The initial motion vector of the current block can be set as the motion vector of the merge candidate pointed to by `merge_idx`.

[0305] On the other hand, if the current block has only one available merge candidate, the signal ring for identifying the merge candidate can be omitted. For example, if the maximum number of merge candidates that the merge candidate list can contain is not greater than one, the signal ring for the merge_idx information used to identify the merge candidate can be omitted. That is, under the merge offset encoding method, if the merge candidate list contains one merge candidate, the encoding of the merge_idx information used to identify the merge candidate can be omitted, and the initial motion vector can be determined based on the merge candidate contained in the merge candidate list. The motion vector of the merge candidate can then be set as the initial motion vector of the current block.

[0306] As another example, one can determine the merge candidates for the current block and then decide whether or not to apply the merge offset vector encoding method to the current block. For example, if the maximum number of merge candidates that a merge candidate can contain is greater than 1, information called merge_idx can be signaled to identify one of the merge candidates. After selecting a merge candidate based on merge_idx, a merge_offset_vector_flag can be decoded to indicate whether or not the merge offset vector encoding method is applied to the current block. Table 4 is a diagram showing the syntax table according to the embodiment described above.

[0307] [Table 4]

[0308] As another example, one could determine the merge candidates for the current block and then decide whether or not to apply the merge offset vector encoding method to the current block only if the index of the determined merge candidate is smaller than the maximum number of merge candidates available when applying the merge offset vector encoding method. For example, a merge_offset_vector_flag indicating whether or not to apply the merge offset vector encoding method to the current block can be encoded and signaled only if the value of the index information merge_idx is less than N. If the value of the index information merge_idx is equal to or greater than N, the encoding of merge_offset_vector_flag can be omitted. If the encoding of merge_offset_vector_flag is omitted, it can be determined that the merge offset vector encoding method will not be applied to the current block.

[0309] Alternatively, after determining the merge candidates for the current block, it is possible to decide whether or not to apply the merge offset vector encoding method to the current block by considering whether or not the determined merge candidates have bidirectional motion information or unidirectional motion information. For example, if the value of the index information merge_idx is less than N and the merge candidate selected by the index information has bidirectional motion information, a merge_offset_vector_flag indicating whether or not to apply the merge offset vector encoding method to the current block can be encoded and signaled. Alternatively, if the value of the index information merge_idx is less than N and the merge candidate selected by the index information has unidirectional motion information, a merge_offset_vector_flag indicating whether or not to apply the merge offset vector encoding method to the current block can be encoded and signaled.

[0310] Alternatively, the decision to apply the merge offset vector encoding method can be made based on at least one of the following: the size, shape, or whether the current block touches the boundary of a coding tree unit. If at least one of the following conditions—the size, shape, or whether the current block touches the boundary of a coding tree unit—has already been set and is not met, the encoding of the merge_offset_vector_flag, which indicates whether the merge offset vector encoding method should be applied to the current block, can be omitted.

[0311] When a merge candidate is selected, its motion vector can be set as the initial motion vector for the current block. Then, the offset vector can be determined by decoding information indicating the magnitude and direction of the offset vector. The offset vector can have either a horizontal or vertical component.

[0312] Information indicating the magnitude of an offset vector can be index information that indicates one of the candidate vector magnitudes. For example, index information distance_idx, which indicates one of the candidate vector magnitudes, can be signaled via a bitstream. Table 5 shows the binarization of the index information distance_idx and the value of the variable DistFromMergeMV for determining the magnitude of the offset vector using distance_idx.

[0313] [Table 5]

[0314] The magnitude of the offset vector can be derived by dividing the variable DistFromMergeMV by an already set value. Equation 5 shows an example of determining the magnitude of the offset vector.

[0315] [Formula 5]

[0316]

number

[0317] According to equation 5 above, the magnitude of the offset vector can be set to the value obtained by dividing the variable DistFromMegeMV by 4 or the value obtained by shifting the variable DistFromMergeMV 2 bits to the left.

[0318] You can use more or fewer vector size candidates than those shown in Table 5, or set the range of motion vector offset size candidates to be different from those shown in Table 5. For example, you can set the magnitude of the horizontal or vertical component of the offset vector to not be greater than the distance of two samples. Table 6 shows the binarization of the index information distance_idx and the value of the variable DistFromMergeMV for determining the magnitude of the offset vector using distance_idx.

[0319] [Table 6]

[0320] Alternatively, the range of motion vector offset size candidates can be set differently based on the motion vector precision. For example, if the precision of the motion vector of the current block is fractional-pel, the value of the variable DistFromMergeMV corresponding to the value of the index information distance_idx can be set to 1, 2, 4, 8, 16, etc. Here, fractional-pel includes at least one of 1 / 16-pel (pel), octo-pel, quarter-pel, or half-pel. On the other hand, if the precision of the motion vector of the current block is integer-pel, the value of the variable DistFromMergeMV corresponding to the value of the index information distance_idx can be set to 4, 8, 16, 32, 64, etc. In other words, the table referenced to determine the variable DistFromMergeMV can be set differently depending on the precision of the motion vector of the current block.

[0321] For example, if the precision of the motion vector of the current block or merge candidate is in the quarter Pel, the variable DistFromMergeMV pointed to by distance_idx can be derived using Table 5. On the other hand, if the precision of the motion vector of the current block or merge candidate is in the integer Pel, the value of the variable DistFromMergeMV pointed to by distance_idx in Table 5 can be derived by taking N times (for example, 4 times) the value of the variable DistFromMergeMV.

[0322] Information for determining the precision of a motion vector can be signaled via a bitstream. For example, this information can be signaled at the sequence, picture, slice, or block level. Thus, the range of candidate vector sizes can be set to vary depending on the information regarding the precision of the motion vector signaled via the bitstream. Alternatively, the precision of a motion vector can be determined based on the merge candidate of the current block. For example, the precision of the motion vector of the current block can be set to be the same as the precision of the motion vector of the merge candidate.

[0323] Alternatively, information for determining the search range of the offset vector can be signaled via a bitstream. Based on the search range, at least one of the following can be determined: the number of vector size candidates, or the minimum or maximum value among the vector size candidates. As an example, a flag for determining the search range of the offset vector, merge_offset_vector_flag, can be signaled via a bitstream. This information can be signaled via a sequence header, picture header, or slice header.

[0324] For example, if the value of merge_offset_extend_range_flag is 0, the offset vector can be set so that its magnitude does not exceed 2. Therefore, the maximum value of DistFromMergeMV can be set to 8. On the other hand, if the value of merge_offset_extend_range_flag is 1, the offset vector can be set so that its magnitude does not exceed a distance of 32 samples. Therefore, the maximum value of DistFromMergeMV can be set to 128.

[0325] The magnitude of an offset vector can be determined using a flag that indicates whether the magnitude of the offset vector is greater than a threshold. For example, a flag called distance_flag, which indicates whether the magnitude of the offset vector is greater than a threshold, can be signaled via a bitstream. The threshold can be 1, 2, 4, 8, or 16. For example, distance_flag being 1 indicates that the magnitude of the offset vector is greater than 4. On the other hand, distance_flag being 0 indicates that the magnitude of the offset vector is 4 or less.

[0326] If the magnitude of the offset vector is greater than the threshold, the difference between the magnitude of the offset vector and the threshold can be derived using the index information distance_idx. Alternatively, if the magnitude of the offset vector is less than or equal to the threshold, the magnitude of the offset vector can be determined using the index information distance_idx. Table 7 is a syntax table showing the encoding aspects of distance_flag and distance_idx.

[0327] [Table 7]

[0328] Equation 6 shows an example of using distance_flag and distance_idx to derive the variable DistFromMergeMV for determining the magnitude of the offset vector.

[0329] [Formula 6]

[0330]

number

[0331] In Equation 6, the value of distance_flag can be set to 1 or 0. The value of distance_idx can be set to 1, 2, 4, 8, 16, 32, 64, 128, etc. N represents a coefficient determined by the threshold. For example, if the threshold is 4, N can be set to 16.

[0332] Information indicating the direction of the offset vector can be index information indicating one of the candidate vector directions. For example, index information direction_idx indicating one of the candidate vector directions can be signaled via a bitstream. Table 8 shows the binarization of the index information direction_idx and the direction of the offset vector according to direction_idx.

[0333] [Table 8]

[0334] In Table 8, sign[0] indicates the horizontal direction, and sign[1] indicates the vertical direction. +1 indicates that the x or y component of the offset vector is positive, and -1 indicates that the x or y component of the offset vector is negative. Equation 7 shows an example of determining the offset vector based on its magnitude and direction.

[0335] [Formula 7]

[0336]

number

[0337] In Equation 7, offsetMV[0] represents the vertical component of the offset vector, and offsetMV[1] represents the horizontal component of the offset vector.

[0338] Figure 28 shows an offset vector based on the values ​​of distance_idx, which indicates the magnitude of the offset vector, and direction_idx, which indicates the direction of the offset vector.

[0339] As shown in the example in Figure 28, the magnitude and direction of the offset vector can be determined based on the values ​​of distance_idx and direction_idx. The maximum magnitude of the offset vector can be set so as not to exceed a threshold, where the threshold can be a value already defined in the encoder and decoder. For example, the threshold can be a distance of 32 samples. Alternatively, the threshold can be determined according to the magnitude of the initial motion vector. For example, the horizontal threshold can be set based on the magnitude of the horizontal component of the initial motion vector, and the vertical threshold can be set based on the magnitude of the vertical component of the initial motion vector.

[0340] If a merge candidate has bidirectional motion information, the L0 motion vector of the merge candidate can be set as the initial L0 motion vector of the current block, and the L1 motion vector of the merge candidate can be set as the initial L1 motion vector of the current block. At this time, the L0 offset vector and the L1 offset vector can be determined by considering the output order difference value between the L0 reference picture of the merge candidate and the current picture (hereinafter referred to as the L0 difference value) and the output order difference value between the L1 reference picture of the merge candidate and the current picture (hereinafter referred to as the L1 difference value).

[0341] First, if the signs of the L0 difference value and the L1 difference value are the same, the L0 offset vector and the L1 offset vector can be set in the same way. On the other hand, if the signs of the L0 difference value and the L1 difference value are different, the L1 offset vector can be set in the opposite direction to the L0 offset vector.

[0342] The magnitudes of the L0 offset vector and the L1 offset vector can be set to be the same. Alternatively, the magnitude of the L1 offset vector can be determined by scaling the L0 offset vector based on the L0 difference value and the L1 difference value.

[0343] As an example, Equation 8 shows the L0 offset vector and the L1 offset vector when the signs of the L0 difference value and the L1 difference value are the same.

[0344] [Formula 8]

[0345]

number

[0346] In Equation 8, offsetMVL0[0] represents the horizontal component of the L0 offset vector, and offsetMVL0[1] represents the vertical component of the L0 offset vector. offsetMVL1[0] represents the horizontal component of the L1 offset vector, and offsetMVL1[1] represents the vertical component of the L1 offset vector.

[0347] Equation 9 shows the L0 offset vector and the L1 offset vector when the signs of the L0 difference value and the L1 difference value are different.

[0348] [Formula 9]

[0349]

number

[0350] It is also possible to define more than four vector direction candidates. Tables 9 and 10 show an example where eight vector direction candidates are defined.

[0351] [Table 9]

[0352] [Table 10]

[0353] In Tables 9 and 10, if the absolute values ​​of sign[0] and sign[1] are greater than 0, it indicates that the offset vector is diagonal. When Table 8 is used, the magnitudes of the x and y components of the diagonal offset vector are set to abs(offsetMV), but when Table 9 is used, the magnitudes of the x and y components of the diagonal offset vector can be set to abs(offsetMV / 2).

[0354] Figure 29 shows an offset vector based on the values ​​of distance_idx, which indicates the magnitude of the offset vector, and direction_idx, which indicates the direction of the offset vector.

[0355] Figure 29(a) shows an example of when Table 8 applies, and Figure 29(b) shows an example of when Table 9 applies.

[0356] Information for determining at least one of the number or magnitude of vector direction candidates can be signaled via a bitstream. For example, the merge_offset_direction_range_flag flag for determining vector direction candidates can be signaled via a bitstream. This flag can be signaled at the sequence, picture, or slice level. For example, if the value of the flag is 0, the four vector direction candidates exemplified in Table 8 can be used. On the other hand, if the value of the flag is 1, the eight vector direction candidates exemplified in Table 9 or Table 10 can be used.

[0357] Alternatively, based on the magnitude of the offset vector, at least one of the number or magnitude of vector direction candidates can be determined. For example, if the value of the variable DistFromMergeMV, which determines the magnitude of the offset vector, is equal to or less than the threshold, the eight vector direction candidates exemplified in Table 9 or Table 10 can be used. On the other hand, if the value of the variable DistFromMergeMV is greater than the threshold, the four vector direction candidates exemplified in Table 8 can be used.

[0358] Alternatively, at least one of the number or magnitude of vector direction candidates can be determined based on the x-component value MVx and the y-component value MVy of the initial motion vector. For example, if the difference between MVx and MVy, or the absolute value of the difference, is less than or equal to a threshold, the eight vector direction candidates exemplified in Table 9 or Table 10 can be used. On the other hand, if the difference between MVx and MVy, or the absolute value of the difference, is greater than the threshold, the four vector direction candidates exemplified in Table 8 can be used.

[0359] The current motion vector of a block can be derived by adding an offset vector to the initial motion vector. Equation 10 shows an example of determining the current motion vector of a block.

[0360] [Formula 10]

[0361]

number

[0362] In Equation 10, mvL0 represents the L0 motion vector of the current block, and mvL1 represents the L1 motion vector of the current block. mergeMVL0 represents the initial L0 motion vector of the current block (i.e., the L0 motion vector of the merge candidate), and mergeMVL1 represents the initial L1 motion vector of the current block. [0] represents the horizontal component of the motion vector, and [1] represents the vertical component of the motion vector.

[0363] The merge offset vector encoding method can also be applied when a coding block is divided into multiple subunits and interpretation is performed for each subunit. Here, performing interpretation on a subunit basis can include at least one of ATMVP (Advanced Temporal Motion Vector Prediction), STMVP (Spatial Temporal Motion Vector Prediction), or triangulation techniques.

[0364] As an example, in the ATMVP method, the initial motion vector can be derived as follows.

[0365] First, an initial shift vector can be derived using the motion vectors of merge candidates derived from adjacent blocks adjacent to the coding block. Then, the shift blocks of subblocks contained within the coding block can be derived using the initial shift vector. Equation 11 is a diagram showing the positions of the shift blocks.

[0366] [Formula 11]

[0367]

number

[0368] In Equation 11, (xColSb, yColSb) represents the position of the sample at the top-left corner of the shift block, and (xSb, ySb) represents the position of the sample at the top-left corner of the subblock. shVector represents the shift vector.

[0369] Once a shift block is determined, the motion vector of a collated block that is at the same position as the shift block in the collated picture can be set as the motion vector of a subblock. That is, the motion vector of a collated block containing a sample at position (xColSb, yColSb) can be set as the motion vector of a subblock containing a sample at position (xSb, ySb).

[0370] When the triangular partitioning technique is applied, a coding block can be divided into triangular subunits. For example, a coding block can be divided into two subunits by a diagonal line connecting the top-left and bottom-right edges of the coding block, or by a diagonal line connecting the top-right and bottom-left edges of the coding block.

[0371] Figure 30 shows the division patterns of a coding block when the triangulation technique is applied.

[0372] The movement information of each subunit of a triangle can be identified by its merge candidate. For each subunit, an index information indicating one of the merge candidates can be signaled. For example, the index information merge_1st_idx for the first subunit identifies the merge candidate for the first subunit, and the index information merge_2nd_idx for the second subunit identifies the merge candidate for the second subunit.

[0373] The initial motion vectors of each subunit can be determined individually. For example, if an affine motion model is applied to a coding block, the affine vector of a subblock derived from the coding block's affine seed vector can be set as the subblock's initial motion vector. The motion vector of each subblock can be derived by adding or subtracting an offset vector from the initial motion vector.

[0374] When the merge offset vector encoding method is applied to a coding block divided into multiple subunits, the multiple subunits can be configured to use the same offset vector. That is, the initial motion vectors of each of the multiple subunits can be modified using the same offset vector.

[0375] Alternatively, a coding block can be divided into multiple subunits, and the offset vector for each subunit can be determined individually. Thus, at least one offset vector within a subunit can be set to be different from the offset vectors of the other subunits.

[0376] Figure 31 shows an example where the offset vectors of each subunit are set to be different.

[0377] As shown in the example in Figure 31, signal rings can be created by encoding information indicating the magnitude of the offset vector (distance_idx) and information indicating the direction of the offset vector (direction_idx) for each subunit.

[0378] Alternatively, the magnitude of the offset vectors for all subunits can be set to be the same, but the direction of the offset vectors for each subunit can be set individually. For example, subunits can be configured to share the value of distance_idx, which is signaled at the coding level, and direction_idx can be encoded and signaled for each subunit.

[0379] Alternatively, the direction of the offset vectors for all subunits can be set to be the same, but the magnitude of the offset vectors for each subunit can be set individually. For example, subunits can be configured to share the same direction_idx value, which is signaled at the coding level, and distance_idx can be encoded and signaled for each subunit.

[0380] It is also possible to apply the merge offset vector encoding method to only some of the subunits generated by splitting a coding block. For example, if the current block is split into a first subunit and a second subunit, the motion vector of the first subunit can be set to be the same as the motion vector of the merge candidate, and the motion vector of the second subunit can be derived by adding an offset vector to the motion vector of the merge candidate.

[0381] Instead of signaling information to determine the offset vector, the decoder can also induce the offset vector. Specifically, the offset vector can be induced using the average horizontal gradient and the average vertical gradient of the prediction samples contained in the subblock.

[0382] Here, the gradient can be derived based on the difference between the reconstructed sample corresponding to the predicted sample in the reference picture and adjacent samples adjacent to the reconstructed sample. For example, a horizontal gradient may show the difference between the reconstructed sample and adjacent reconstructed samples to the left and / or right, and a vertical gradient may show the difference between the reconstructed sample and adjacent reconstructed samples to the top and / or bottom.

[0383] Among the merge candidates included in the merge candidate list, merge candidates having motion vectors derived by adding or subtracting an offset vector to the motion vector of a reference merge candidate can be added to the merge candidate list. A merge candidate having a motion vector derived by adding or subtracting an offset vector to the motion vector of a reference merge candidate may be called a refined merge candidate.

[0384] The remaining motion information, excluding the motion vector of the refine merge candidate, can be set to be the same as that of the base merge candidate.

[0385] Figure 32 shows the motion vector candidates that the refine merge candidate can take.

[0386] If the motion vector of the reference merge candidate is (MvLX[0], MvLX[1]), the motion vector of the refine merge candidate can be derived by adding or subtracting an offset to at least one of the x or y components of the motion vector of the reference merge candidate. For example, the motion vector of the refine merge candidate can be set to (MvLX[0] + M, MvLX[1]), (MvLX[0] - M, MvLX[1]), (MvLX[0], MvLX[1] + M), or (MvLX[0], MvLX[1] - M), where M is the magnitude of the offset vector.

[0387] A reference merge candidate can be a merge candidate with an already defined index value within the merge candidate list. For example, among the merge candidates included in the merge candidate list, the merge candidate with the smallest index value (i.e., the merge candidate with an index value of 0) or the merge candidate with the largest index value can be set as the reference merge candidate. Alternatively, the inter-area merge candidate with the smallest index value or the inter-area merge candidate with the largest index value within the inter-area motion information table can be set as the reference merge candidate.

[0388] Alternatively, among merge candidates with bidirectional motion information, the merge candidate with the smallest index value can be set as the reference merge candidate. That is, when the candidate blocks are searched sequentially, the first bidirectional merge candidate found can be set as the reference merge candidate.

[0389] You can also select a base merge candidate based on the size, shape, or whether the current block touches the boundary of a coding tree unit. For example, if the current block is square, or if the current block is a non-square with height greater than width, you can set the merge candidate with index 0 or a merge candidate derived from an adjacent block located at the top edge of the current block as the base merge candidate. If the current block is a non-square with width greater than height, you can set the merge candidate with index 1 or a merge candidate derived from an adjacent block located to the left of the current block as the base merge candidate.

[0390] Alternatively, information identifying a criterion merge candidate can be signaled via a bitstream. This information may be index information that identifies any one of the merge candidates included in the merge candidate list.

[0391] Information indicating whether or not to use a refined merge candidate can be signaled via a bitstream. This information may be a 1-bit flag. If the value of the flag is 1, a refined merge candidate generated based on a reference merge candidate can be added to the merge candidate list. On the other hand, if the value of the flag is 0, the merge candidate list does not include any refined merge candidates.

[0392] Alternatively, if the number of merge candidates already added to the merge candidate list is less than the maximum number of merge candidates the merge candidate list can contain, a refined merge candidate can be added to the merge candidate list. Here, the already added merge candidates may include at least one of the following: spatial merge candidates, temporal merge candidates, inter-domain merge candidates, or pairwise merge candidates. For example, if the number of at least one of the spatial merge candidates, temporal merge candidates, or inter-domain merge candidates included in the merge candidate list is below a threshold, a refined merge candidate can be added to the merge candidate list.

[0393] Alternatively, if the number of merge candidates already added to the merge candidate list exceeds a certain threshold, you can use refined merge candidates.

[0394] The maximum number of merge candidates that can be included in the merge candidate list can be set differently depending on whether or not refined merge candidates are used. For example, if refined merge candidates are not used, the maximum number of merge candidates that can be included in the merge candidate list is set to N, but if refined merge candidates are used, the maximum number of merge candidates that can be included in the merge candidate list can be set to N+n.

[0395] A refined merge candidate can have a higher index than a merge candidate already added to the merge candidate list. As an example, Table 11 shows a possible structure of the merge candidate list.

[0396] [Table 11]

[0397] In Table 11, mergeCand[X] represents the merge candidate with index X. mvLx[0] represents the x-component motion vector of the reference merge candidate, and mvLx[1] represents the y-component motion vector of the reference merge candidate. For example, if the reference merge candidate is mergeCand[0], then mvLx[0] and mvLx[1] can represent the motion vector of mergeCand[0].

[0398] The magnitude M of the offset vector can be defined in the encoder and decoder. For example, the magnitude M of the offset vector can be set to an integer less than or equal to 4, such as 1 or 4.

[0399] Alternatively, information for determining the offset vector can be signaled via a bitstream. This information can be signaled at the sequence, picture, slice, or block level. For example, the offset vector can be determined using at least one of the information for determining the magnitude of the offset vector, distance_idx, or the information for determining the direction of the offset vector, direction_idx.

[0400] As shown in the example in Table 11, at least one refined merge candidate derived from a base merge candidate can be added to the merge candidate list. If there is a merge candidate already added whose motion information is the same as the refined merge candidate, the refined merge candidate may not be added to the merge candidate list. For example, if the refined merge candidate derived from the base merge candidate mergeCand[0] is the same as any one of mergeCand[1] to mergeCand[5], the refined merge candidate may not be added to the merge candidate list.

[0401] Alternatively, if there is a merge candidate whose motion information is the same as that of the refine merge candidate, the offset vector can be changed, or the merge candidate whose motion information is the same as that of the refine merge candidate can be reset to the refine merge candidate to re-induce the refine merge candidate. For example, if the motion information of the refine merge candidate mergeCand[6], which was induced based on the base merge candidate mergeCand[0], is the same as that of the merge candidate mergeCand[2], the motion vector of the refine merge candidate mergeCand[6] can be changed to a value obtained by adding or subtracting the offset vector from the motion vector of the merge candidate mergeCand[2]. For example, the motion vector of mergeCand[6] can be changed from (mergeCand[0]_mxLx[0]+M, mergeCand[0]_mvLx[1]) to (mergeCand[2]_mxLx[0]+ M, mergeCand[2]_mvLx[1]). Here, mergeCand[X]_mvLx represents the motion vector of the merge candidate with index X.

[0402] As another example, the offset vector can be determined using a merge refinement offset list that includes at least one merge offset candidate. If the merge candidate identified by the current block's index information is the reference merge candidate, the offset vector can be determined using the merge refinement offset list. The motion vector of the current block can then be derived by adding or subtracting the offset vector from the motion vector of the merge candidate. The reference merge candidate can be a merge candidate with an already defined index value in the merge candidate list. For example, the merge candidate with the smallest index value (i.e., the merge candidate with an index value of 0) or the merge candidate with the largest index value among the merge candidates included in the merge candidate list can be set as the reference merge candidate. Alternatively, the inter-region merge candidate with the smallest index value or the inter-region merge candidate with the largest index value in the inter-region motion information table can be set as the reference merge candidate.

[0403] Figure 33 shows the structure of the merge refinement offset list.

[0404] In Figure 33, we assume that the criterion merge candidate is the merge candidate with an index of 6.

[0405] If the index of a merge candidate identified by the index information merge_idx, which indicates one of the merge candidates, is not 6, the motion vector of the merge candidate can be set as the motion vector of the current block.

[0406] On the other hand, if the index of the merge candidate identified by the index information merge_idx is 6, the offset vector can be derived using the merge refinement offset list. The index information MrgOffset_idx, which identifies one of the merge offset candidates included in the merge refinement offset list, can be signaled via the bitstream.

[0407] Once the offset vector is identified, the motion vector of the current block can be derived by adding or subtracting the offset vector from the motion vector of the reference merge candidate.

[0408] A merge refinement offset list can contain at least one merge offset candidate. For example, a merge refinement offset list can contain 4, 8, or 16 merge offset candidates.

[0409] Figures 34 and 35 show the offset vectors identified by the merge offset candidates.

[0410] Figure 34 shows an example where there are 8 merge offset candidates, and Figure 35 shows an example where there are 16 merge offset candidates.

[0411] As shown in the example in Figure 34(a), the offset vector indicated by a merge offset candidate can be set so that the absolute values ​​of the horizontal motion vector and / or the vertical motion vector have fixed values. Alternatively, as shown in the example in Figure 35, among the merge offset candidates, the offset vector indicated by a merge offset candidate whose index is smaller than a threshold can be set so that the absolute values ​​of the horizontal motion vector and / or the vertical motion vector have a first value, while the offset vectors indicated by other merge offset candidates can be set so that the absolute values ​​of the horizontal motion vector and / or the vertical motion vector have a second value.

[0412] Alternatively, as shown in the example in Figure 34(b), the offset vector indicated by the merge offset candidate can be set such that the sum of the absolute values ​​of the horizontal motion vector and the absolute values ​​of the vertical motion vector has a fixed value.

[0413] It is also possible to set multiple criterion merge candidates. For example, the two merge candidates with the smallest indices among those included in the merge candidate list can be set as criterion merge candidates. Therefore, if the index of the merge candidate identified by the index information merge_idx is 0 or 1, the offset vector can be derived using the merge refinement offset list. Alternatively, the merge candidate with the smallest index among those included in the merge candidate list and the merge candidate with the largest index among those included in the inter-region merge candidate list can be set as criterion merge candidates.

[0414] In motion vector prediction mode, the motion vector of the current block can be derived by adding a motion difference vector to the motion prediction vector. The motion prediction vector of the current block can be determined based on a motion vector prediction candidate list that includes at least one motion prediction vector candidate. For example, one of the motion prediction vector candidates can be set as the motion prediction vector of the current block.

[0415] Motion vector prediction candidates can be derived based on at least one of the spatially adjacent blocks or the temporally adjacent blocks of the current block.

[0416] Figure 36 shows a candidate block used to guide motion vector prediction candidates.

[0417] A spatially adjacent block may include an upper adjacent block located at the top of the current block and a left adjacent block located to the left of the current block. An upper adjacent block may include at least one of the following: block B0 containing a sample at position (xCb + CbW, yCb-1), block B1 containing a sample at position (xCb + CbW-1, yCb-1), block B2 containing a sample at position (xCb-1, yCb-1), or block B3 containing a sample at position (xCb, yCb-1). Here, (xCb, yCb) indicates the position of the upper left sample of the current block, and CbW indicates the width of the current block. A left adjacent block may include at least one of the following: block A0 containing a sample at position (xCb-1, yCb + CbH), block A1 containing a sample at position (xCb-1, yCb + CbH-1), or block A2 containing a sample at position (xCb-1, yCb). Here, CbH indicates the current block height.

[0418] A temporally adjacent block may include at least one of the following: block C0, which contains a sample in the center of a block having the same position and size as the current block within the collated block; or block C1, which contains a sample adjacent to the upper right corner of the block.

[0419] The motion vector prediction candidate list can contain a maximum of two motion vector prediction candidates. The induction order of motion vector prediction candidates is as follows:

[0420] 1. If at least one of the left adjacent blocks A0 or A1 is available, the motion vector of the available block is set as the motion vector prediction candidate.

[0421] 2. If at least one of the upper adjacent block B0, upper adjacent block B1, or upper adjacent block B2 is available, the motion vector of the available block is set as a motion vector prediction candidate.

[0422] 3. If temporally adjacent blocks are available, set the temporal motion vector as the motion vector prediction candidate.

[0423] 4. Set the zero motion vector as a candidate for motion vector prediction.

[0424] Alternatively, if the number of motion vector prediction candidates derived according to the order of 1-3 is less than two, motion vectors included in the inter-domain motion information table can also be set as motion vector prediction candidates. If the inter-domain motion information table is available, motion vector prediction candidates can be derived according to the following order.

[0425] 1. If at least one of the left adjacent blocks A0 or A1 is available, the motion vector of the available block is set as the motion vector prediction candidate.

[0426] 2. If at least one of the upper adjacent block B0, upper adjacent block B1, or upper adjacent block B2 is available, the motion vector of the available block is set as a motion vector prediction candidate.

[0427] 3. If temporally adjacent blocks are available, set the temporal motion vector as the motion vector prediction candidate.

[0428] 4. Set the motion vectors included in the inter-domain motion information table as motion vector prediction candidates.

[0429] 5. Set the zero motion vector as a candidate for motion vector prediction.

[0430] It is also possible to add motion vector prediction candidates to the motion vector prediction candidate list if they have motion vectors derived by adding or subtracting an offset vector to the motion vector of a reference motion vector prediction candidate. Motion vector prediction candidates that have motion vectors derived by adding or subtracting an offset vector to the motion vector of a reference motion vector prediction candidate can be called refined motion vector prediction candidates.

[0431] Figure 37 shows motion vector candidates that can be set as refined motion vector prediction candidates.

[0432] If the motion vector of the reference motion vector prediction candidate is (MvpLX[0], MvpLX[1]), the motion vector of the refined motion vector prediction candidate can be derived by adding or subtracting an offset to at least one of the x or y components of the motion vector of the reference motion vector prediction candidate. For example, the motion vector of the refined motion vector prediction candidate can be set to (MvpLX[0] + M, MvpLX[1]), (MvpLX[0] - M, MvpLX[1]), (MvpLX[0], MvpLX[1] + M), or (MvpLX[0], MvpLX[1] - M), where M represents the magnitude of the offset vector.

[0433] The magnitude M of the offset vector can be defined in the encoder and decoder. For example, the magnitude M of the offset vector can be set to an integer less than or equal to 4, such as 1 or 4.

[0434] Alternatively, information for determining the offset vector can be signaled via a bitstream. This information can be signaled at the sequence, picture, slice, or block level. For example, the offset vector can be determined using at least one of the information for determining the magnitude of the offset vector, distance_idx, or the information for determining the direction of the offset vector, direction_idx.

[0435] A reference motion vector prediction candidate can be a motion vector prediction candidate with an already defined index value within the motion vector prediction candidate list. For example, among the motion vector prediction candidates included in the motion vector prediction candidate list, a motion vector prediction candidate with an index value of 0 or a motion vector prediction candidate with an index value of 1 can be set as the reference motion vector prediction candidate.

[0436] As another example, the offset vector can be determined using a merge refinement offset list that includes at least one predicted vector offset candidate. If the motion vector prediction candidate identified by the current block's index information is the reference motion vector prediction candidate, the offset vector can be determined using the predicted vector refinement offset list. Then, the motion vector of the current block can be derived by adding or subtracting the offset vector from the motion vector of the motion vector prediction candidate. The reference motion vector prediction candidate can be a motion vector prediction candidate with an already defined index value in the motion vector prediction candidate list. As an example, among the motion vector prediction candidates included in the motion vector prediction candidate list, the motion vector prediction candidate with the smallest index value or the motion vector prediction candidate with the largest index value can be set as the reference motion vector prediction candidate.

[0437] When calculating the offset vector using a prediction vector offset refinement list, you can also set the maximum number of prediction vector candidates that the prediction vector candidate list can contain to a value greater than 2.

[0438] Figure 38 shows the structure of the prediction vector refinement offset list.

[0439] In Figure 38, we assume that the reference prediction vector candidate is the prediction vector candidate with index 2.

[0440] If the index of the predicted vector candidate identified by the index information AMVPcand_idx, which indicates one of the predicted vector candidates, is not 2, then the motion vector of the predicted vector candidate can be set as the motion predicted vector for the current block.

[0441] On the other hand, if the index of the prediction vector candidate identified by the index information AMVPcand_idx is 2, the offset vector can be derived using the prediction vector refinement offset list. The index information AMVPOffset_idx, which identifies one of the prediction vector offset candidates included in the prediction vector refinement offset list, can be signaled via the bitstream.

[0442] Once the offset vector is identified, the motion vector of the current block can be derived by adding or subtracting the offset vector from the motion vector of the reference prediction vector candidate.

[0443] Even when coding blocks are encoded based on an affine motion model, motion vector refinement techniques can be used. For example, when an affine motion vector prediction mode is applied, the affine seed vector of a coding block can be derived by adding an affine seed difference vector to the affine seed prediction vector. Here, the affine seed prediction vector can be derived based on the affine seed vectors of the spatially or temporally adjacent blocks of the coding block. The affine seed difference vector can be determined based on information signaled from the bitstream. In this case, the same affine seed difference vector can be applied to all control points. Alternatively, information for determining the affine seed vector can be signaled to each control point.

[0444] When the affine vectors of subblocks are induced based on the affine seed vector of a coding block, the affine vectors can be set as the initial motion vectors, and then the offset vectors can be induced. The motion vectors of each subblock can be induced by adding or subtracting the offset vector from the initial motion vector.

[0445] Instead of signaling information to determine the offset vector, decoding can also induce the offset vector. Specifically, the offset vector can be induced using the mean values ​​of the horizontal and vertical gradients of the predicted samples contained in the subblock.

[0446] Intra-prediction predicts the current block using reconstructed samples encoded / decoded around the current block. In this case, reconstructed samples before the application of the in-loop filter can be used for the intra-prediction of the current block.

[0447] Intra-prediction techniques include matrix-based intra-prediction and general intra-prediction that considers orientation with respect to surrounding recovered samples. Information indicating the intra-prediction technique for the current block can be signaled via a bitstream. This information may be a 1-bit flag. Alternatively, the intra-prediction technique for the current block can be determined based on the current block's position, size, shape, or at least one of the intra-prediction techniques of adjacent blocks. For example, if the current block extends beyond the picture boundary, matrix-based intra-prediction may be set not to apply to the current block.

[0448] Matrix-based intra-prediction is a method of obtaining a predicted block for the current block based on the matrix product of a matrix already stored in the encoder / decoder and a reconstructed sample around the current block. Information to identify one of several already stored matrices can be signaled via a bitstream. The decoder can determine the matrix for the intra-prediction of the current block based on this information and the size of the current block.

[0449] A typical intra-prediction method is a way to obtain the predicted block for the current block based on either a non-directional intra-prediction mode or a directional intra-prediction mode.

[0450] The induced residual video can be derived by subtracting the predicted video from the original video. When the residual video is converted to the frequency domain, the subjective image quality of the video does not deteriorate significantly even if the high-frequency components are removed. Therefore, reducing the value of the high-frequency components or setting the value of the high-frequency components to 0 has the effect of improving compression efficiency without causing significant visual distortion. Reflecting the above characteristics, the current block can be transformed to decompose the residual video into two-dimensional frequency components. This transformation can be performed using transformation techniques such as DCT (Discrete Cosine Transform) or DST (Discrete Sine Transform).

[0451] It is possible to transform the current block using DCT or DST, and then transform the transformed current block again. In this case, the transformation based on DCT or DST can be defined as the first transformation, and the transformation of the block to which the first transformation has been applied can be defined as the second transformation.

[0452] The first transformation can be performed using one of several candidate transformation cores. For example, the first transformation can be performed using one of DCT2, DCT8, or DCT7.

[0453] Different conversion cores may be used for the horizontal and vertical directions. Information indicating the combination of horizontal and vertical conversion cores may also be signaled via a bitstream.

[0454] The execution units for the first and second transformations can be different. For example, an 8x8 block can undergo the first transformation, and then a 4x4 subblock within the transformed 8x8 block can undergo the second transformation. In this case, the transformation coefficient for the remaining area where the second transformation has not been performed can also be set to 0.

[0455] Alternatively, a 4x4 block could undergo the first transformation, and the 8x8 area containing the transformed 4x4 block could undergo the second transformation.

[0456] Information indicating whether or not to perform the second transformation can be signaled via the bitstream.

[0457] The decoder can perform the inverse of the second transformation (second inverse transformation) and then perform the inverse of the first transformation (first inverse transformation) on the result of that transformation. As a result of performing the second and first inverse transformations, the residual signal of the current block can be obtained.

[0458] Quantization is used to reduce the energy of a block, and the quantization process involves dividing a transformation coefficient by a specific constant value. This constant value can be derived by a quantization parameter, which can be defined as a value between 1 and 63.

[0459] When the encoder performs the transformation and quantization, the decoder can obtain the residual block through inverse quantization and inverse transformation. The decoder can then add the predicted block and the residual block to obtain the restored block of the current block.

[0460] Once the restored block of the current block is obtained, the loss of information that occurs during the quantization and encoding process can be reduced via in-loop filtering. The in-loop filter may include at least one of the following: a deblocking filter, a sample adaptive offset filter (SAO), or an adaptive loop filter (ALF).

[0461] Applying embodiments described focusing on a decoding process or an encoding process to an encoding process or a decoding process is within the scope of the present invention. Modifying embodiments described in a predetermined order to a different order is also within the scope of the present invention.

[0462] The embodiments described above are explained based on a series of steps or flowcharts, but this does not limit the chronological order of the present invention, and the steps may be performed simultaneously or in other orders as needed. In addition, in the embodiments described above, each of the components constituting the block diagram (e.g., units, modules, etc.) can be embodied in a hardware device or software, and multiple components may be combined to be embodied in a single hardware device or software. The embodiments described above can be embodied in the form of program commands executed through various computer components and recorded on a computer-readable recording medium. A computer-readable recording medium may include program commands, data files, data structures, etc., individually or in combination. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floppy disks; and hardware devices specifically configured to store and execute program commands, such as ROM, RAM, and flash memory. The hardware device may be configured to operate using one or more software modules to perform the processing according to the present invention, and vice versa.

[0463] This invention can be applied to electronic devices that encode / decode video.

Claims

1. A bitstream reception method, This includes receiving a bitstream, performing the following video decoding operations to decode the bitstream, and generating a video or picture: The aforementioned video decoding operation is A step of determining whether the merge offset vector encoding method is applied to the current block, The steps include generating a list of merge candidates for the current block, A step of identifying a merge candidate for the current block based on the merge candidate list, A step of inducing a motion vector for the current block based on the merge candidate, Includes, When the merge offset vector encoding method is applied to the current block, the motion vector of the current block is derived by adding an offset vector to the motion vector of the merge candidate, and if the maximum number of merge candidates that the merge candidate list can contain is greater than one, the merge candidate of the current block is selected based on index information decoded from a bitstream indicating one of the merge candidates, and if the maximum number is one, the merge candidate is determined without decoding the index information. At least one of the maximum or minimum values ​​of the vector magnitude candidates is set to differ depending on the accuracy of the motion vector relative to the current block. A bitstream reception method characterized by the following:

2. The magnitude of the offset vector is determined based on first index information that identifies one of the candidate vector magnitudes. The bitstream reception method according to feature 1.

3. At least one of the maximum or minimum values ​​of the vector magnitude candidate is set to be different based on the value of a flag indicating the numerical value of the vector magnitude candidate, and the flag is signaled at the picture level. The bitstream reception method according to feature 2.

4. The direction of the offset vector is determined based on second index information that identifies one of the candidate vector directions. The bitstream receiving method according to any one of claims 2 to 3.

5. A bitstream transmission method, This includes performing the following video encoding operations to generate a bitstream and transmitting the bitstream: The aforementioned video encoding operation is A step of determining whether the merge offset vector encoding method is applied to the current block, The steps include generating a list of merge candidates for the current block, A step of identifying a merge candidate for the current block based on the merge candidate list, A step of inducing a motion vector for the current block based on the merge candidate, Includes, When the merge offset vector encoding method is applied to the current block, the motion vector of the current block is derived by adding an offset vector to the motion vector of the merge candidate, and if the maximum number of merge candidates that the merge candidate list can contain is greater than one, the index information indicating the merge candidate of the current block among the merge candidates is encoded, and if the maximum number is one, the encoding of the index information is omitted. At least one of the maximum or minimum values ​​of the vector magnitude candidates is set to differ depending on the accuracy of the motion vector relative to the current block. A bitstream transmission method characterized by the following:

6. The aforementioned video encoding operation is The further step includes encoding first index information for identifying a vector size candidate that indicates the magnitude of the offset vector among a plurality of vector size candidates. The bitstream transmission method according to claim 5.

7. The aforementioned video encoding operation is The process further includes encoding a flag indicating a numerical value of the vector size candidate, wherein at least one of the maximum or minimum values ​​of the vector size candidate differs depending on the value of the flag, and the flag is encoded at the picture level. The bitstream transmission method according to feature 6.

8. The aforementioned video encoding operation is The further step includes encoding a second index information for identifying a vector direction candidate that indicates the direction of the offset vector from among a plurality of vector direction candidates. The bitstream transmission method according to any one of claims 6 to 7.

9. A computer-readable storage medium in which computer programs and bitstreams are stored, When the computer program is executed by the processor, the following steps of the video encoding method are performed to generate the bitstream: The aforementioned video encoding method is A step of determining whether the merge offset vector encoding method is applied to the current block, The steps include generating a list of merge candidates for the current block, A step of identifying a merge candidate for the current block based on the merge candidate list, A step of inducing a motion vector for the current block based on the merge candidate, Includes, When the merge offset vector encoding method is applied to the current block, the motion vector of the current block is derived by adding an offset vector to the motion vector of the merge candidate, and if the maximum number of merge candidates that the merge candidate list can contain is greater than one, the index information indicating the merge candidate of the current block among the merge candidates is encoded, and if the maximum number is one, the encoding of the index information is omitted. At least one of the maximum or minimum values ​​of the vector magnitude candidates is set to differ depending on the accuracy of the motion vector relative to the current block. A computer-readable storage medium characterized by the following features.

Images