Video signal encoding / decoding method and apparatus thereof

The method addresses the data volume challenge in high-definition video services by optimizing merge candidates and redundancy detection in video encoding/decoding, improving efficiency and performance.

JP7871442B2Active Publication Date: 2026-06-08GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP LTD

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP LTD
Filing Date
2025-02-07
Publication Date
2026-06-08

AI Technical Summary

Technical Problem

The increasing demand for high-definition video services has led to a significant increase in data volume, and existing video compression standards like HEVC are facing performance limitations.

Method used

A method for deriving merge candidates using a prediction region motion information list during video signal encoding/decoding, including redundancy detection and motion compensation based on a comparison of motion information in merge candidate lists.

Benefits of technology

Improves encoding/decoding efficiency by simplifying redundancy detection and deriving optimal merge candidates, enhancing the interpretation efficiency of video signals.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007871442000009
    Figure 0007871442000009
  • Figure 0007871442000010
    Figure 0007871442000010
  • Figure 0007871442000011
    Figure 0007871442000011
Patent Text Reader

Abstract

To provide a video decoding method for improving merging candidate derivation using a prediction region motion information list.SOLUTION: A video decoding method includes the steps of: deriving merge candidates for a current block from neighboring blocks of the current block; adding the derived merge candidates to a merge candidate list; adding at least one prediction region merge candidate included in a prediction region motion information list to the merge candidate list when the number of merge candidates added to the merge candidate list is less than a threshold; deriving motion information of the current block based on the merge candidate list; and performing motion compensation on the current block based on the derived motion information.SELECTED DRAWING: Figure 17
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a video signal encoding / decoding method and an apparatus therefor.

Background Art

[0002] As display panels are getting larger, there is a need for higher-quality video services. The biggest problem with high-definition video services is the significant increase in data volume. To solve such problems, active research has been conducted on improving video compression ratios. As a typical example, in 2009, the Motion Picture Experts Group (MPEG) and the Video Coding Experts Group (VCEG) under the umbrella of the International Telecommunication Union - Telecommunication (ITU-T) established the Joint Collaborative Team on Video Coding (JCT-VC). JCT-VC submitted the video compression standard High Efficiency Video Coding (HEVC), and the standard was approved on January 25, 2013. Its compression performance is approximately twice that of H.264 / AVC. With the rapid growth of high-definition video services, the performance limitations of HEVC are gradually emerging.

Summary of the Invention

Problems to be Solved by the Invention

[0003] An object of the present invention is to provide a method for deriving merge candidates using a prediction region motion information list when encoding / decoding a video signal, and an apparatus for executing the method.

[0004] The object of the present invention is to provide a redundancy detection method for detecting the degree of redundancy between a predicted region merge candidate included in a predicted region motion information list and a merge candidate included in a merge candidate list when encoding / decoding a video signal.

[0005] The object of the present invention is to provide a method for deriving merge candidates for blocks included in a merge processing area when encoding / decoding a video signal, and an apparatus for performing the said method.

[0006] The technical problems that this invention aims to solve are not limited to those mentioned above, and a person with ordinary skill in the art to which this invention belongs will clearly understand other technical problems not mentioned in the following description. [Means for solving the problem]

[0007] The video signal decoding / encoding method according to the present invention includes the steps of: deriving merge candidates for the current block from adjacent blocks of the current block; adding the derived merge candidates to a merge candidate list; if the number of merge candidates added to the merge candidate list is less than a threshold, adding at least one predicted region merge candidate included in a predicted region motion information list to the merge candidate list; deriving motion information for the current block based on the merge candidate list; and performing motion compensation for the current block based on the derived motion information. In this case, whether or not to add the predicted region merge candidate to the merge candidate list can be determined based on a comparison result between the motion information of the predicted region merge candidate and the motion information of the merge candidates included in the merge candidate list.

[0008] In the video signal decoding / encoding method of the present invention, the comparison can be performed on at least one merge candidate whose index in the merge candidate list is less than or equal to a threshold.

[0009] In the video signal decoding / encoding method according to the present invention, the comparison can be performed on at least one of the merge candidates derived from the left adjacent block located to the left of the current block, or from the upper adjacent block located above the current block.

[0010] In the video signal decoding / encoding method according to the present invention, if it is determined that there is a merge candidate in the merge candidate list that has motion information that is the same as the motion information of the first predicted region merge candidate, the first predicted region merge candidate may not be added to the merge candidate list. Furthermore, based on the result of comparing the motion information of the second predicted region merge candidate included in the predicted region motion information list with the motion information of the merge candidate included in the merge candidate list, it may be determined whether or not to add the second predicted region merge candidate to the merge candidate list.

[0011] In the video signal decoding / encoding method according to the present invention, the determination of whether the motion information of the second predicted region merge candidate is the same as the motion information of a merge candidate having motion information that is the same as the motion information of the first predicted region merge candidate can be omitted.

[0012] In the video signal decoding / encoding method according to the present invention, the difference between the number of predicted region merge candidates included in the predicted region merge candidates and the index of the predicted region merge candidates is less than or equal to a threshold.

[0013] The video signal decoding / encoding method according to the present invention further includes the step of adding a current predicted region merge candidate derived from the motion information of the current block to the predicted region motion information list. In this case, if there is a predicted region merge candidate that is the same as the current predicted region merge candidate, the predicted region merge candidate that is the same as the current predicted region merge candidate can be deleted and the maximum index can be assigned to the current predicted region merge candidate.

[0014] The above brief summary of the present invention is limited to the exemplary embodiments described in the detailed description of the present invention below, and does not limit the scope of the invention. [Effects of the Invention]

[0015] According to the present invention, the interpretation efficiency can be improved by providing a method for deriving merge candidates using a list of predicted region motion information.

[0016] According to the present invention, interpretation efficiency can be improved by simplifying the redundancy detection between prediction region merge candidates and merge candidates.

[0017] According to the present invention, the interpretation efficiency can be improved by providing a method for deriving merge candidates for blocks included in the merge processing area.

[0018] The effects that can be obtained with this invention are not limited to those described above, and a person with ordinary skill in the art to which this invention belongs will clearly understand other effects not mentioned below from the following description. [Brief explanation of the drawing]

[0019] [Figure 1] This is a block diagram showing a video encoder according to an embodiment of the present invention. [Figure 2] This is a block diagram showing a video decoder according to an embodiment of the present invention. [Figure 3] This figure shows a basic coding tree unit according to an embodiment of the present invention. [Figure 4] This diagram shows multiple types of coding block partitioning. [Figure 5] This diagram shows the partitioning modes of the coding tree unit. [Figure 6] The flowchart shows an inter prediction method according to an embodiment of the present invention. [Figure 7] This figure shows the nonlinear motion of the object. [Figure 8]It is a flowchart showing an inter-prediction method based on affine motion according to an embodiment of the present invention. [Figure 9] It is a diagram showing an example of an affine seed vector of each affine motion model. [Figure 10] It is a diagram showing an example of an affine vector of a sub-block in a 4-parameter motion model. [Figure 11] It is a flowchart showing a process of deriving motion information of a current block in merge mode. [Figure 12] It is a diagram showing an example of a candidate block for deriving a merge candidate. [Figure 13] It is a diagram showing the position of a reference sample. [Figure 14] It is a diagram showing an example of a candidate block for deriving a merge candidate. [Figure 15a] It is a diagram showing an example of variation in the position of a reference sample. [Figure 15b] It is a diagram showing an example of variation in the position of a reference sample. [Figure 16] It is a diagram showing an example of variation in the position of a reference sample. [Figure 17] It is a flowchart showing a process for updating a prediction region motion information list. [Figure 18] It is a diagram showing an example of implementation of updating a prediction region merge candidate list. [Figure 19] It is a diagram showing an example of updating an index of a stored prediction region merge candidate. [Figure 20] It is a diagram showing the position of a representative sub-block. [Figure 21] It is a diagram showing an example of generating a prediction region motion information list for each inter-prediction mode. [Figure 22] It is a diagram showing an example of adding a prediction region merge candidate included in a long-term motion information list to a merge candidate list. [Figure 23] It is a diagram showing an example of performing redundancy detection for only some merge candidates. [Figure 24] It is a diagram showing an example of omitting redundancy detection for a specific merge candidate. [Figure 25] This diagram shows an example of setting candidate blocks that are currently located in the same merge processing area as the block as unavailable as merge candidates. [Figure 26] This is a diagram showing a list of temporary movement information. [Figure 27] This figure shows an example of merging a predicted area motion information list and a temporary motion information list. [Figure 28] This figure shows an example of address information for blocks included in a candidate for encoding region merge. [Figure 29] This figure shows an example of address information for blocks included in a candidate for encoding region merge. [Figure 30] This figure shows an example where a candidate for a coded region merge that has the same address information as the current block's address information is set as unavailable as a candidate for a merge in the current block. [Figure 31] This figure shows an example where a candidate for a coded region merge that has the same address information as the current block's address information is set as unavailable as a candidate for a merge in the current block. [Modes for carrying out the invention]

[0020] The embodiments of the present invention will be described in detail below with reference to the drawings.

[0021] Video encoding and decoding are performed in blocks. For example, encoding / decoding operations such as transformation, quantization, prediction, loop filtering, or reconstruction can be performed on an encoding block, a transform block, or a prediction block.

[0022] Hereafter, the block to be encoded / decoded will be referred to as the "current block." For example, according to the current encoding / decoding process step, the current block can represent an encoded block, a transformed block, or a predicted block.

[0023] In this specification, the term "unit" may be understood to refer to a basic unit for performing a particular encoding / decoding process, and "block" may be understood to refer to a sample array of a predetermined size. Unless otherwise specified, "block" and "unit" are used interchangeably. For example, in the embodiments described later, encoding blocks and encoding units may be understood to have the same meaning.

[0024] Figure 1 is a block diagram showing a video encoder according to an embodiment of the present invention.

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

[0026] Each component shown in Figure 1 is shown individually and represents a distinct characteristic function in a video encoding device, but this does not mean that each component consists of separate hardware or a single software assembly. That is, for the sake of clarity, each component is arranged such that at least two of the components are combined to form one component, or one component is divided into multiple components, thereby performing its function. Embodiments in which such components are harmonized and embodiments in which components are separated are also within the scope of the present invention, without departing from the essence of the present invention.

[0027] Furthermore, some components are not essential for performing the essential functions of the present invention, but are merely optional components for improving performance. The present invention may also be implemented by including only components necessary for realizing the essence of the invention, other than components used solely for improving performance, and a structure including only essential components other than optional components used solely for improving performance also falls within the scope of the rights of the present invention.

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

[0029] For example, a single image can be divided into multiple coding units. To divide an image 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 the coding unit can be divided into other coding units. The other coding units may have the same number of child nodes as the number of coding units that have been divided. Coding units that are not divided due to certain restrictions become leaf nodes. In other words, assuming that one coding unit can only achieve square partitioning, one coding unit can be divided into up to four other coding units.

[0030] In the embodiments of the present invention described below, the encoding unit may refer to a unit that performs encoding, or it may refer to a unit that performs decoding.

[0031] A prediction unit in one coding unit can be divided into shapes such as at least one of the same size squares or rectangles, or a prediction unit in one coding unit can be divided into shapes and / or sizes different from another prediction unit.

[0032] If the prediction unit that performs intraprediction based on the coding unit is not the minimum coding unit, it is not necessary to divide it into multiple prediction units N×N, and intraprediction can be performed.

[0033] 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 use inter-prediction or intra-prediction, and can also determine specific information (e.g., intra-prediction mode, motion vector, reference image, etc.) based on each prediction method. In this case, the processing unit that performs the prediction may be different from the processing unit that determines the prediction method and specific content. For example, the prediction unit can determine the prediction method and prediction mode, and the conversion unit can perform the prediction. The residual value (residual block) between the generated prediction block and the original block can be input to the conversion unit 130. Prediction mode information, motion vector information, etc. for prediction can be encoded together with the residual value in the entropy encoding unit 165 and transmitted to the decoder. When using a specific encoding mode, the original block can be directly encoded and transmitted to the decoder without generating prediction blocks by the prediction units 120 and 125.

[0034] The interpretation unit 120 can predict prediction units based on information from at least one image, either the image immediately preceding or immediately following the current image. In some cases, it can also predict prediction units based on information from a specific encoded region of the current image. The interpretation unit 120 may include a reference image interpolation unit, a motion prediction unit, and a motion compensation unit.

[0035] The reference image interpolation unit receives reference image information from memory 155 and can generate integer pixel or smaller pixel information from the reference image. Regarding luminance pixels, an 8-tap interpolation filter based on a DCT with different filter coefficients can be used to generate integer pixel or smaller pixel information in units of 1 / 4 pixels. Regarding chromaticity signals, a 4-tap interpolation filter based on a DCT with different filter coefficients can be used to generate integer pixel or smaller pixel information in units of 1 / 8 pixels.

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

[0037] The intra-prediction unit 125 can generate prediction units based on reference pixel information surrounding the current block, which is pixel information in the current image. If the adjacent block of the current prediction unit is a block where inter-prediction has been performed, and the reference pixel is a pixel where inter-prediction has been performed, the reference pixel included in the block where inter-prediction has been performed can be used as the reference pixel information of the surrounding blocks where intra-prediction has been performed. In other words, if a reference pixel is unavailable, at least one of the available reference pixels can be used instead of the unavailable reference pixel information.

[0038] In intra-prediction, the prediction mode may include an angle prediction mode that uses reference pixel information based on the prediction direction and a non-angle mode that does not use direction information when performing prediction. The mode for predicting luminance information may be different from the mode for predicting chromaticity information. To predict chromaticity information, intra-prediction mode information for predicting luminance information or predicted luminance signal information can be used.

[0039] When performing intraprediction, if the size of the prediction unit is the same as the size of the transformation unit, intraprediction can be performed on the prediction unit based on the pixels located to the left, the upper left, and the pixels located above the prediction unit. However, when performing intraprediction, if the size of the prediction unit is different from the size of the transformation unit, intraprediction can be performed based on the reference pixels of the transformation unit. Furthermore, intraprediction using N×N partitioning can be applied only to the minimum coding unit.

[0040] After applying an Adaptive Intra Smoothing (AIS) filter to a reference pixel based on the prediction mode, a prediction block can be generated using an intra-prediction method. The type of Adaptive Intra Smoothing filter applied to the reference pixel may vary. To perform the intra-prediction method, the intra-prediction mode of the current prediction unit can be predicted based on the intra-prediction modes of prediction units located around 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 mode of the current prediction unit is the same as that of the surrounding prediction units, information indicating that the prediction mode of the current prediction unit is the same as that of the surrounding prediction units can be transmitted using predetermined flag information. If the prediction mode of the current prediction unit is different from that of the surrounding prediction units, the prediction mode information of the current block can be encoded by performing entropy coding.

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

[0042] The transformation unit 130 can perform transformations on the original block and the residual block containing residual value information between prediction units generated by the prediction units 120 and 125, using transformation methods such as the Discrete Cosine Transform (DCT) and the Discrete Sine Transform (DST). Here, the DCT transformation kernel includes at least one of DCT2 or DCT8, and DSTc 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 for generating the residual block. It is also possible to skip the transformation of the residual block. A flag indicating whether to skip the transformation of the residual block can be encoded. It is permissible to skip the transformation for residual blocks, luminance components, or chromaticity components (4:4:4 format or less) whose magnitude is below a threshold.

[0043] The quantization unit 135 can quantize the values ​​converted to the frequency domain by the conversion unit 130. The quantization coefficients may vary depending on the importance of the blocks or images. The values ​​calculated by the quantization unit 135 may be provided to the inverse quantization unit 140 and the rearrangement unit 160.

[0044] The rearrangement unit 160 can perform a rearrangement of coefficient values ​​for the quantized residual values.

[0045] The rearrangement unit 160 can convert two-dimensional block shape coefficients into one-dimensional vector form using a coefficient scanning method. For example, the rearrangement unit 160 can scan DC coefficients or coefficients in the high-frequency region using a zig-zag scan method and convert them into one-dimensional vector form. Depending on the size of the conversion unit and the intra-prediction mode, vertical scanning, which scans the two-dimensional block shape coefficients along the column direction, and horizontal scanning, which scans the two-dimensional block shape coefficients along the row direction, can also be used instead of zigzag scanning. In other words, it is possible to decide which of zigzag scanning, vertical scanning, and horizontal scanning to use based on the size of the conversion unit and the intra-prediction mode.

[0046] The entropy coding unit 165 can perform entropy coding based on the value calculated by the rearrangement unit 160. For example, entropy coding can use multiple coding methods such as Exponential Golomb coding, Context-Adaptive Variable Length Coding (CAVLC), and Context-Adaptive Binary Arithmetic Coding (CABAC).

[0047] The entropy coding unit 165 can encode multiple pieces of information from the rearrangement unit 160 and the prediction units 120 and 125, including residual coefficient information and block type information of the coding units, prediction mode information, divided unit information, prediction unit information and transmission unit information, motion vector information, reference frame information, block interpolation information, and filtering information.

[0048] The entropy coding unit 165 can perform entropy coding on the coefficient values ​​of the coding units input from the rearrangement unit 160.

[0049] The inverse quantization unit 140 and the inverse transformation unit 145 perform inverse quantization on multiple values ​​quantized by the quantization unit 135, and perform inverse transformation on the values ​​transformed by the transformation unit 130. By merging the residual values ​​generated by the inverse quantization unit 140 and the inverse transformation unit 145 with the prediction units predicted by the motion prediction unit, motion compensation unit, and intra prediction unit included in the prediction units 120 and 125, a reconstructed block can be generated.

[0050] The filter unit 150 may include at least one of the following: a deblocking filter, an offset correction unit, or an adaptive loop filter (ALF).

[0051] A deblocking filter can remove block distortion generated in the reconstructed image due to the boundaries between blocks. To determine whether to perform deblocking, it is possible to determine whether to apply a deblocking filter to the current block based on the pixels contained in several columns or rows within the block. When applying a deblocking filter to a block, a strong filter or a weak filter can be applied based on the required deblocking filtering strength. Furthermore, when performing vertical or horizontal filtering during the process of using a deblocking filter, horizontal and vertical filtering can be performed synchronously.

[0052] The offset correction unit can correct the offset between the deblocked video and the original video on a pixel-by-pixel basis. Offset correction can be performed on a specified image using the following method: the pixels contained in the video are divided into a predetermined number of regions, the regions requiring offset correction are determined, and the offset is applied to the corresponding regions, or the offset is applied considering the edge information of each pixel.

[0053] Adaptive Loop Filtering (ALF) can be performed based on a comparison between the filtered reconstructed image and the original video. By dividing the pixels in the video into predetermined groups and then determining a single filter to be used for each group, filtering can be performed differentially for each group. Information regarding whether or not to apply adaptive loop filtering, as well as luminance information, can be transmitted according to the coding unit (CU). The shape and filter coefficients of the applied adaptive loop filter differ for each block. However, it is also possible to apply the same type (a fixed type) of adaptive loop filter regardless of the characteristics of the block to which it is applied.

[0054] The memory 155 can store the reconstructed blocks or images calculated by the filter unit 150, and when interpretation is performed, the stored reconstructed blocks or images can be provided to the prediction units 120 and 125.

[0055] Figure 2 is a block diagram showing a video decoder according to an embodiment of the present invention.

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

[0057] When a video bitstream is input from a video encoder, the input bitstream can be decoded in steps that are the reverse of the steps taken by the video encoder.

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

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

[0060] The rearrangement unit 215 can perform rearrangement by rearranging the bitstream that has been entropically decoded by the entropy decoding unit 210 in the encoding unit. Rearrangement can be performed by reconstructing multiple coefficients represented in one-dimensional vector form into two-dimensional block-shaped coefficients. The rearrangement unit 215 can also perform rearrangement by receiving information related to the coefficient scan performed by the encoding unit and performing a reverse scan according to the scan order performed by the corresponding encoding unit.

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

[0062] The inverse transform unit 225 can perform an inverse discrete cosine transform and an inverse discrete sine transform on the quantization result performed by the video encoder. The inverse discrete cosine transform and the inverse discrete sine transform are the inverse transforms of the transform performed by the transform unit, that is, the inverse transforms of the discrete cosine transform and the discrete sine transform. Here, the DCT transform kernel may include at least one of DCT2 or DCT8, and the DST transform kernel may include DST7. Alternatively, if the video encoder skips the transform, the inverse transform unit 225 does not have to perform the inverse transform. The inverse transform may be performed by a transmission unit determined by the video encoder. The inverse transform unit 225 of the video decoder can selectively perform a transform method (e.g., DCT or DST) based on multiple pieces of information such as the prediction method, the size of the current block, and the prediction direction.

[0063] 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 blocks or image information provided by the memory 245.

[0064] As described above, when performing intraprediction using the same method as in a video encoder, if the size of the prediction unit is the same as the size of the conversion unit, intraprediction is performed on the prediction unit based on the pixels located to the left, the pixels located to the upper left, and the pixels located above the prediction unit. When performing intraprediction, if the size of the prediction unit is different from the size of the conversion unit, intraprediction can be performed based on the reference pixels of the conversion unit. Furthermore, intraprediction using N×N partitioning can be applied only to the minimum coding unit.

[0065] The prediction units 230 and 235 may include a prediction unit determination unit, an inter-prediction unit, and an intra-prediction unit. The prediction unit determination unit receives multiple pieces of information input from the entropy decoding unit 210, such as prediction unit information, prediction mode information of the intra-prediction method, and motion prediction-related information of the inter-prediction method, classifies the prediction units based on the currently encoded unit, and determines whether the prediction unit is performing inter-prediction or intra-prediction. The inter-prediction unit 230 can perform inter-prediction on the current prediction unit based on information contained in at least one image, either the image immediately preceding or following the current image to which the current prediction unit belongs, using the information provided by the video encoder that is necessary for performing inter-prediction on the current prediction unit. Alternatively, inter-prediction can also be performed based on information from a reconstructed portion of the current image to which the current prediction unit belongs.

[0066] To perform interpretation, based on the encoded unit, it is possible to determine whether the motion prediction method of the prediction unit contained within the corresponding encoded unit is Skip Mode, Merge Mode, Advanced Motion Vector Prediction Mode (AMVP Mode), or Intrablock Duplication Mode.

[0067] The intra-prediction unit 235 can generate prediction blocks based on pixel information in the current image. 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 adaptive intra-smoothing (AIS) filter, a reference pixel interpolation unit, and a DC filter. The adaptive intra-smoothing filter is the part that performs filtering on the reference pixels of the current block, and can also determine whether to apply the filter based on the prediction mode of the current prediction unit. Adaptive intra-smoothing filtering can be performed on the reference pixels of the current block using the prediction mode of the prediction unit and the adaptive intra-smoothing filter information provided by the video encoder. If the prediction mode of the current block is a mode that does not perform adaptive intra-smoothing filtering, the adaptive intra-smoothing filter does not need to be applied.

[0068] Regarding the reference pixel interpolation unit, if the prediction mode of the prediction unit is a prediction unit that performs intra-prediction based on the pixel values ​​to be interpolated for the reference pixels, then interpolation can be performed on the reference pixels to generate reference pixels in units of integer values ​​or smaller. If the prediction mode of the current prediction unit is a prediction mode that generates prediction blocks in a way that does not interpolate for the reference pixels, then interpolation for the reference pixels is not required. If the prediction mode of the current block is DC mode, the DC filter can generate prediction blocks by filtering.

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

[0070] The video encoder can receive information regarding whether to apply a deblocking filter to the relevant block or image, and if so, whether to use a strong or weak filter. The video decoder's deblocking filter can receive the information regarding the deblocking filter provided by the video encoder, and the video decoder can perform deblocking filtering on the relevant block.

[0071] The offset correction unit can perform offset correction on the reconstructed image based on the type of offset correction applied to the video during encoding and the offset information.

[0072] Based on information provided by the encoder regarding whether or not to apply ALF, ALF coefficient information, etc., ALF can be applied to the encoding unit. Such ALF information may be provided by being included in a specific set of parameters.

[0073] Memory 245 stores the reconstructed image or block, making the image or block available as a reference image or reference block, and can also provide the reconstructed image to the output unit.

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

[0075] The largest coding block can be defined as a coding tree block. A single image may be divided into multiple coding tree units (each coding tree unit having a size of Coding Tree Unit: CTU). The largest coding unit is the Largest Coding Unit (LCU). Figure 3 shows an example of dividing a single image into multiple coding tree units.

[0076] The size of a coded tree unit may be defined at the image level or the sequence level. Therefore, information indicating the size of a coded tree unit can be transmitted using a signal based on an image parameter set or a sequence parameter set.

[0077] For example, the size of the encoding tree unit for the entire sequence of images can be set to 128×128. Alternatively, the size of the encoding tree unit can be determined to be either 128×128 or 256×256 at the image level. For example, the size of the encoding tree unit for the first image can be set to 128×128, and the size of the encoding tree unit for the second image can be set to 256×256.

[0078] Encoded blocks can be generated by dividing the encoding tree units. Encoded blocks represent basic units for encoding / decoding processing. For example, prediction or transformation can be performed depending on different encoding blocks, or a predictive encoding mode can be determined depending on different encoding blocks. Here, the predictive encoding mode represents a method for generating a predicted image. For example, predictive encoding modes may include intra-prediction, inter-prediction, current picture referencing (CPR), intra-block copy (IBC), or combined prediction. For each encoding block, a predictive block related to the encoding block can be generated using at least one predictive encoding mode from intra-prediction, inter-prediction, current picture referencing, or combined prediction.

[0079] Information representing the predictive coding mode of the current block can be transmitted via a bitstream signal. For example, this information may be a 1-bit flag indicating whether the predictive coding mode is intra-mode or inter-mode. Only when it is determined that the predictive coding mode of the current block is inter-mode can current image referencing or combined prediction be used.

[0080] The current image reference is used to obtain the predicted block of the current block from the encoded / decoded region of the current image, using the current image as the reference image. Here, the current image means the image containing the current block. Information indicating whether to apply the current image reference to the current block can be transmitted via a bitstream signal. For example, the information may be a 1-bit flag. If the flag is true, the predicted encoding mode of the current block can be determined to be current image reference. If the flag is false, the prediction mode of the current block can be determined to be interprediction.

[0081] Alternatively, the predictive coding mode of the current block can be determined based on a reference image index. For example, if the reference image index points to the current image, the predictive coding mode of the current block can be determined as current image reference. If the reference image index points to an image other than the current image, the predictive coding mode of the current block can be determined as inter-prediction. In other words, current image reference is a prediction method that uses information from the encoded / decoded region in the current image, while inter-prediction is a prediction method that uses information from other encoded / decoded images.

[0082] Combinatorial prediction is an encoding mode formed by combining two or more of the following: intra-prediction, inter-prediction, and current image reference. For example, when applying combinational prediction, a first prediction block can be generated based on one of the intra-prediction, inter-prediction, or current image reference, and a second prediction block can be generated based on another. When generating the first and second prediction blocks, a final prediction block can be generated by averaging and weighting the first and second prediction blocks. Information indicating whether or not to apply combinational prediction can be transmitted via a bitstream in a signal. This information may be a 1-bit flag.

[0083] Figure 4 shows multiple partitioning types for encoded blocks.

[0084] Based on quadtree, binary, or ternary tree partitioning, an encoded block can be divided into multiple encoded blocks. Furthermore, based on quadtree, binary, or ternary tree partitioning, the divided encoded block can be further divided into multiple encoded blocks.

[0085] Quadrarrow partitioning is a partitioning technique that divides the current block into four blocks. As a result of quadrarrow partitioning, the current block can be divided into four square partitions (see "SPLIT_QT" in Figure 4(a)).

[0086] Binary tree partitioning is a partitioning technique that divides the current block into two blocks. The process of dividing the current block into two blocks along the vertical direction (i.e., using a vertical line that crosses the current block) is called vertical binary tree partitioning, and the process of dividing the current block into two blocks along the horizontal direction (i.e., using a horizontal line that crosses the current block) is called horizontal binary tree partitioning. After binary tree partitioning, the current block can be divided into two non-square partitions. In Figure 4(b), "SPLIT_BT_VER" represents the result of vertical binary tree partitioning, and in Figure 4(c), "SPLIT_BT_HOR" represents the result of horizontal binary tree partitioning.

[0087] Ternary tree partitioning is a partitioning technique that divides the current block into three blocks. The process of dividing the current block into three blocks along the vertical direction (i.e., using two vertical lines that cross the current block) is called vertical ternary tree partitioning, and the process of 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 ternary tree partitioning. After ternary 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 may be twice the width / height of the other partitions. In Figure 4(d), "SPLIT_TT_VER" represents the result of vertical ternary tree partitioning, and in Figure 4(e), "SPLIT_TT_HOR" represents the result of horizontal ternary tree partitioning.

[0088] The number of divisions in an encoded tree unit can be defined as the partitioning depth. The maximum partitioning depth of an encoded tree unit can be determined at the sequence or image level. Therefore, the maximum partitioning depth of an encoded tree unit may vary depending on the sequence or image.

[0089] Alternatively, the maximum partitioning depth can be determined independently for each of the multiple partitioning techniques. For example, the maximum partitioning depth that allows quadtree partitioning may be different from the maximum partitioning depth that allows binary tree partitioning and / or ternary tree partitioning.

[0090] The encoder can transmit information via the bitstream as a signal representing at least one of the division shape or division depth of the current block. The decoder can determine the division shape and division depth of the coded tree unit based on the information analyzed from the bitstream.

[0091] Figure 5 shows an example of a coding tree unit partitioning.

[0092] The process of dividing an encoded block using partitioning techniques such as quadtree partitioning, binary tree partitioning, and / or ternary tree partitioning can be called multi-tree partitioning.

[0093] The coded blocks generated by applying multi-tree partitioning to a coded block can be called multiple downstream coded blocks. If the partitioning depth of a coded block is k, the partitioning depth of the multiple downstream coded blocks is k+1.

[0094] On the other hand, for multiple coding blocks with a division depth of k+1, the coding block with a division depth of k can be called the upstream coding block.

[0095] The partition type of the current coded block can be determined based on at least one of the partition shape of the upstream coded block or the partition type of the adjacent coded block. Here, adjacent coded blocks are adjacent to the current coded block and may include at least one of the above adjacent block, left adjacent block, or adjacent block adjacent to the upper left corner of the current coded block. Here, the partition type may include at least one of whether to perform a quadtree partition, whether to perform a binary tree partition, the direction of the binary tree partition, whether to perform a ternary tree partition, or the direction of the ternary tree partition.

[0096] To determine the partition shape of the encoded block, information indicating whether the encoded block has been partitioned can be transmitted via a bitstream signal. This information is a 1-bit flag "split_cu_flag", and if the flag is true, it indicates that the encoded block will be partitioned using multi-tree partitioning technique.

[0097] If "split_cu_flag" is true, a signal can be transmitted via the bitstream indicating whether the encoded block has been quadtree-split. This information is a 1-bit flag "split_qt_flag", and if this flag is true, the encoded block may be split into four blocks.

[0098] For example, in the example shown in Figure 5, the coding tree unit is divided into four coding blocks with a division depth of 1. The figure then illustrates applying the quadtree division again to the first and fourth coding blocks among the four coding blocks generated as a result of the quadtree division. Ultimately, four coding blocks with a division depth of 2 can be generated.

[0099] Furthermore, by applying quadtree partitioning again to an encoded block with a partitioning depth of 2, it is possible to generate an encoded block with a partitioning depth of 3.

[0100] If a quadtree split is not applied to an encoded block, it is possible to determine whether to perform a binary tree split or a ternary tree split on the encoded block by considering at least one of the following: the size of the encoded block, whether the encoded block is located at the boundary of the image, the maximum splitting depth, or the splitting shape of adjacent blocks. If it is determined that a binary tree split or a ternary tree split should be performed on the encoded block, information representing the splitting direction can be transmitted via a bitstream as a signal. This information may be a 1-bit flag "mtt_split_cu_vertical_flag". Based on this flag, it is possible to determine whether the splitting direction is vertical or horizontal. Furthermore, it is possible to transmit information via a bitstream as a signal indicating whether to apply a binary tree split or a ternary tree split to the encoded block. This information may be a 1-bit flag "mtt_split_cu_binary_flag". Based on this flag, it is possible to determine whether to apply a binary tree split or a ternary tree split to the encoded block.

[0101] For example, in the example shown in Figure 5, a vertical binary tree partition is applied to an encoded block with a partitioning depth of 1. A vertical ternary tree partition is applied to the left encoded block of the encoded block generated as a result of the partitioning, and a vertical binary tree partition is applied to the right encoded block.

[0102] Interpretation is a predictive coding mode that predicts the current block using information from the previous image. For example, a block in the previous image at the same position as the current block (hereinafter referred to as a collocated block) can be used as the predicted block for the current block. Hereafter, a predicted block generated based on a block at the same position as the current block will be called a collocated prediction block.

[0103] On the other hand, if an object present in the previous image moves to a different position in the current image, the current block can be effectively predicted based on the object's movement. For example, by comparing the previous image with the current image, the direction and size of the object's movement can be determined, allowing for the generation of a predicted block (or predicted image) of the current block, 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.

[0104] A residual block can be generated by subtracting a predicted block from the current block. In this case, if the target motion exists, using a motion prediction block instead of a collated prediction block can reduce the energy of the residual block and improve its compression performance.

[0105] As mentioned above, the process of generating prediction blocks using motion information can be called motion-compensated prediction. In most interpretations, prediction blocks can be generated based on motion-compensated prediction.

[0106] Motion information may include at least one of the following: motion vector, reference image index, prediction direction, or bidirectional weighted index. The motion vector represents the direction and magnitude of the object's movement. The reference image index specifies the reference image of the current block from among multiple reference images included in the reference image list. The prediction direction refers to one of the following: unidirectional L0 prediction, unidirectional L1 prediction, or bidirectional prediction (L0 prediction and L1 prediction). Based 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 weighted index specifies the weights applied to the L0 prediction block and the weights applied to the L1 prediction block.

[0107] Figure 6 is a flowchart showing an inter-prediction method according to an embodiment of the present invention.

[0108] Referring to Figure 6, the inter-prediction method includes the steps of determining the inter-prediction mode of the current block (S601), obtaining motion information of the current block based on the determined inter-prediction mode (S602), and performing motion compensation prediction for the current block based on the obtained motion information (S603).

[0109] Here, the interpretation mode represents multiple techniques for determining the motion information of the current block, and may include interpretation modes using translational motion information and interpretation modes using affine motion information. For example, the interpretation mode using translational motion information may include merge mode and advanced motion vector prediction mode. The interpretation mode using affine motion information may include affine merge mode and affine motion vector prediction mode. According to the interpretation mode, the motion information of the current block can be determined based on information analyzed from adjacent blocks or bitstreams adjacent to the current block.

[0110] The following explains in detail the inter-prediction method using affine motion information.

[0111] Figure 7 shows the nonlinear motion of the object.

[0112] The movement of an object in a video may be nonlinear. For example, as shown in Figure 7, nonlinear motion of the object can occur due to camera zoom-in, zoom-out, rotation, or affine transformation. When nonlinear motion occurs in an object, the movement cannot be effectively represented by a translational motion vector. Therefore, encoding efficiency can be improved by using affine motion instead of translational motion in parts where nonlinear motion occurs in the object.

[0113] Figure 8 is a flowchart showing an inter-prediction method based on affine motion according to an embodiment of the present invention.

[0114] Based on the information analyzed from the bitstream, it is possible to determine whether to apply affine motion-based interpretation techniques to the current block. Specifically, it is possible to determine whether to apply affine motion-based interpretation techniques to the current block based on at least one of the following flags: a flag indicating whether to apply affine merge mode to the current block, or a flag indicating whether to apply affine motion vector prediction mode to the current block.

[0115] When applying interpretation techniques based on affine motion to a current block, the affine motion model of the current block can be determined (S801). The affine motion model can be determined by at least one of a 6-parameter affine motion model or a 4-parameter affine motion model. The 6-parameter affine motion model represents affine motion with six parameters, and the 4-parameter affine motion model represents affine motion with four parameters.

[0116] Equation 1 represents the case where affine motion is expressed using six parameters. Affine motion represents translational motion within a predetermined region determined by the affine seed vector.

number

[0117] While representing affine motion with six parameters allows for the representation of complex motion, it increases the number of bits required for encoding each parameter, thus reducing encoding efficiency. Therefore, affine motion can also be represented with four parameters. Equation 2 shows the case where affine motion is represented with four parameters.

number

[0118] Information for determining the affine motion model of a block can be encoded and transmitted as a signal via a bitstream. For example, the 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. A value of 1 for the flag indicates that a 6-parameter affine motion model is applied. The flag can be encoded on a slice, image block, or block (e.g., encoded block or encoded tree unit) basis. When the flag is transmitted as a signal at the slice level, the affine motion model determined at the slice level can be applied to all blocks belonging to the slice.

[0119] Alternatively, the affine motion model of the current block can be determined based on the affine interpretation mode of the current block. For example, when applying the affine merge mode, the affine motion model of the current block can be determined to be a four-parameter motion model. On the other hand, when applying the affine motion vector prediction mode, the information for determining the affine motion model of the current block can be encoded and transmitted as a signal via a bitstream. For example, when applying the affine motion vector prediction mode to the current block, the affine motion model of the current block can be determined based on a 1-bit flag "affine_type_flag".

[0120] Next, the affine seed vector of the current block can be derived (S802). If a 4-parameter affine motion model is selected, the motion vectors of the two control points of the current block can be derived. If a 6-parameter affine motion model is selected, the motion vectors of the three control points of the current block can be derived. The motion vectors at the control points can be called affine seed vectors. The control points may include at least one of the upper left corner, upper right corner, or lower left corner of the current block.

[0121] Figure 9 shows examples of affine seed vectors for each affine motion model.

[0122] In a four-parameter affine motion model, it is possible to derive affine seed vectors related to two of the following corners: the upper left corner, the upper right corner, or the lower left corner. For example, as shown in Figure 9(a), if a four-parameter affine motion model is selected, the affine vector can be derived using the affine seed vector sv0 related to the upper left corner of the current block (e.g., the upper left sample (x0, y0)) and the affine seed vector sv1 related to the upper right corner of the current block (e.g., the upper right sample (x1, y1)). Alternatively, the affine seed vector related to the lower left corner can be used instead of the affine seed vector related to the upper left corner. Or, the affine seed vector related to the lower left corner can be used instead of the affine seed vector related to the upper right corner.

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

[0124] 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 the 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).

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

[0126] Using an affine seed vector, affine vectors can be derived according to different subblocks (S803). Here, the affine vector represents the translational motion vector derived based on the affine seed vector. The affine vector of a subblock can be called the affine subblock motion vector or subblock motion vector.

[0127] Figure 10 shows an example of an affine vector for a subblock in a four-parameter motion model.

[0128] 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. For example, Equation 3 shows an example of deriving the affine subblock vector.

number

[0129] In equation 3 above, (x,y) represents the position of the subblock. Here, the position of the subblock represents the position of the reference sample contained in the subblock. The reference sample may be a sample located in the upper left corner of the subblock, or it may be at least one sample located at the center in the x-axis or y-axis coordinate system. (x0,y0) represents the position of the first control point, and (sv 0x sv 0y ) represents the first affine seed vector. Note that (x1, y1) represents the position of the second control point, and (sv 1x sv 1y ) represents the second affine seed vector.

[0130] 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 a value equal to the width of the current block.

[0131] Next, motion compensation prediction can be performed for each subblock using the affine vector of each subblock (S804). After performing motion compensation prediction, prediction blocks related to each subblock can be generated. The prediction block of a subblock can be set as the prediction block of the current block.

[0132] Next, we will explain in detail the interpretation prediction method using translational motion information.

[0133] The motion information of the current block can be derived from the motion information of other blocks. Here, the other blocks may be blocks that are coded / decoded by interpretation with higher priority than the current block. When the motion information of the current block is the same as the motion information of other blocks, it can be defined as merge mode. Also, when the motion vectors of other blocks are set as the predicted values ​​of the motion vectors of the current block, it can be defined as motion vector prediction mode.

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

[0135] Candidates for merging the current block can be derived (S1101). Candidates for merging the current block are derived from the block preceding the current block, which was encoded / decoded by interpretation.

[0136] Figure 12 shows an example of a candidate block for deriving merge candidates.

[0137] A candidate block may contain at least one of the following: an adjacent block containing samples adjacent to the current block, or a non-adjacent block containing samples not adjacent to the current block. Below, the samples used to determine a candidate block are designated as reference samples. Reference samples adjacent to the current block are called adjacent reference samples, and reference samples not adjacent to the current block are called non-adjacent reference samples.

[0138] Adjacent reference samples may be located in the column adjacent to the leftmost column of the current block, or in the row adjacent to the top row of the current block. For example, if the coordinates of the top-left sample of the current block are (0,0), then one of the following blocks may 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). As shown in the drawing, adjacent blocks with indices from 0 to 4 can be used as candidate blocks.

[0139] A non-adjacent reference sample represents a sample whose x-axis distance or y-axis distance from a reference sample adjacent to the current block is a predefined value. For example, 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 upper reference sample is a predefined value; or a block containing a non-adjacent sample whose x-axis and y-axis distances from the upper-left reference sample are predefined values. The predefined value may be an integer such as 4, 8, 12, or 16. As shown in the drawing, at least one of the blocks with an index from 5 to 26 can be used as a candidate block.

[0140] A sample that is not located on the same vertical, horizontal, or diagonal line as an adjacent reference sample can be designated as a non-adjacent reference sample.

[0141] Figure 13 shows the location of the reference sample.

[0142] As shown in the example in Figure 13, the x-coordinate of the upper non-adjacent reference sample can be set to be different from the x-coordinate of the upper adjacent reference sample. For example, if the position of the upper adjacent reference sample is (W-1, -1), the position of the upper non-adjacent reference sample that is N away from the upper adjacent reference sample along the y-axis can be set to ((W / 2)-1, -1-N), and the position of the upper non-adjacent reference sample that is 2N away from the upper adjacent reference sample along the y-axis 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.

[0143] Hereafter, among the candidate blocks, those containing adjacent reference samples will be referred to as adjacent blocks, and those containing non-adjacent reference samples will be referred to as non-adjacent blocks.

[0144] If the distance between the current block and a candidate block is greater than or equal to a threshold, the candidate block can be set as unavailable as a merge candidate. The threshold may be determined by 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 to a value obtained by adding or subtracting an offset value to the height of the coding tree unit (e.g., ctu_height ± N). The offset value N is a value predefined in the encoder and decoder and can be set to 4, 8, 16, 32, or ctu_height.

[0145] 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.

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

[0147] If the upper boundary of a current block is adjacent to the upper boundary of a coding tree unit, setting multiple candidate blocks as unavailable as merge candidates will reduce the coding / decoding efficiency of the current block. To solve this problem, the number of candidate blocks located above the current block can be set to be greater than the number of candidate blocks located to the left of the current block.

[0148] Figure 14 shows an example of a candidate block for deriving merge candidates.

[0149] As shown in the example in Figure 14, the upper blocks belonging to the N block rows above the current block and the left blocks belonging to the M block rows to the left of the current block can be considered candidate blocks. In this case, by making M greater than N, the number of left candidate blocks can be greater than the number of upper candidate blocks.

[0150] For example, the difference between the y-axis coordinate of the reference sample within the current block and the y-axis coordinate of the upper block available as a candidate block can be set to be less than or equal to N times the height of the current block. Furthermore, the difference between the x-axis coordinate of the reference sample within the current block and the x-axis coordinate of the left block available as a candidate block can be set to be less than or equal to M times the width of the current block.

[0151] For example, in the example shown in Figure 14, the blocks belonging to the two block columns above the current block and the blocks belonging to the five block columns to the left of the current block are illustrated as candidate blocks.

[0152] As another example, if a candidate block does not belong to the same coding tree unit as the current block, a merge candidate can be derived using, instead of the candidate block, a block belonging 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.

[0153] Figure 15 (also referred to as Figure 15, which includes both Figure 15a and Figure 15b; Figure 15a is also called Figure 15(a); and Figure 15b is also called Figure 15(b)) shows an example of variation in the position of a reference sample.

[0154] If a reference sample is contained 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 reference sample can be determined using a reference sample adjacent to the boundary of the coding tree unit instead of the reference sample.

[0155] For example, in the examples shown in Figures 15(a) and 15(b), when the upper boundary of the current block and the upper boundary of the coding tree unit are in contact with each other, the reference samples above the current block belong to a different coding tree unit than the current block. A sample adjacent to the upper boundary of the coding tree unit can replace a reference sample belonging to a different coding tree unit than the current block that is not adjacent to the upper boundary of the coding tree unit.

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

[0157] Alternatively, the x-coordinate of the replacement sample can be obtained by adding or subtracting an offset value 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 above the current block are the same, the x-coordinate of the replacement sample can be obtained by adding or subtracting an offset value from the x-coordinate of the reference sample. The purpose of this is to prevent the replacement sample used to replace a non-adjacent reference sample from being in the same position as another non-adjacent or adjacent reference sample.

[0158] Figure 16 shows an example of variation in the position of the reference sample.

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

[0160] For example, in the example shown in Figure 16, the reference sample at position 6 and the reference sample at position 15 may be replaced with the sample at position 6' and the sample at position 15', respectively, which have the same y-coordinate 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' may be set to be W / 2, which is the difference between it and the x-coordinate of the reference sample at position 6, and the x-coordinate of the sample at position 15' may be set to be W-1, which is the difference between it and the x-coordinate of the reference sample at position 15.

[0161] Unlike the examples shown in Figures 15 and 16, the y-coordinate of the row currently located above the top row of the block, or the y-coordinate of the upper boundary of the coding tree unit, may also be set to the y-coordinate of the replacement sample.

[0162] Although not shown in the diagram, a sample to replace a reference sample can be determined based on the left boundary of the coding tree unit. For example, if a 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 may have the same y-coordinate as the reference sample, or it may have a y-coordinate obtained by adding or subtracting an offset value from the y-coordinate of the reference sample.

[0163] Next, a block containing the replacement sample is designated as a candidate block, and based on this candidate block, a merge candidate for the current block can be derived.

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

[0165] The motion information of a merge candidate can be set to be the same as the motion information of a candidate block. For example, at least one of the following can be used as the motion information of a merge candidate: the motion vector of the candidate block, the reference image index, the predicted direction, or the bidirectional weighted index.

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

[0167] Multiple merge candidates in the merge candidate list can be assigned indices according to a predetermined order. For example, the index assigned to an adjacent merge candidate may have a smaller value 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 shown in Figure 12 or Figure 14.

[0168] If the merge candidate list contains multiple merge candidates, at least one of the multiple merge candidates can be selected (S1103). In this case, information can be transmitted via the bitstream as a signal indicating whether the motion information of the current block was derived from an adjacent merge candidate. This information may be a 1-bit flag. For example, a syntax element isAdjancentMergeFlag can be transmitted via the bitstream as a signal indicating whether the motion information of the current block was derived from an adjacent merge candidate. If the value of the syntax element isAdjancentMergeFlag is 1, the motion information of the current block may be derived based on an adjacent merge candidate. On the other hand, if the value of the syntax element isAdjancentMergeFlag is 0, the motion information of the current block may be derived based on a non-adjacent merge candidate.

[0169] Table 1 shows the syntax table including the syntax element isAdjancentMergeFlag. [Table 1(1)] [Table 1(2)]

[0170] Information can be transmitted via a bitstream or signal to specify one of several merge candidates. For example, information can be transmitted via a bitstream or signal indicating the index of one of the merge candidates included in a list of merge candidates.

[0171] If isAdjacentMergeflag is 1, a signal can be used to send the syntax element merge_idx to determine one of the adjacent merge candidates. The maximum value of the syntax element merge_idx can be a value where the difference between the number of adjacent merge candidates and the current value is 1.

[0172] If isAdjacentMergeflag is 0, the signal can be used to send the syntax element NA_merge_idx to determine one of the non-adjacent merge candidates. The syntax element NA_merge_idx represents the value obtained by calculating 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 based on NA_merge_idx.

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

[0174] The predicted region motion information list contains merge candidates derived from blocks encoded / decoded based on interpretation in the current image. For example, the motion information of the merge candidates included in the predicted region motion information list can be set to be equal to the motion information of the blocks encoded / decoded based on interpretation. Here, the motion information may include at least one of the following: motion vector, reference image index, prediction direction, or bidirectional weighted index.

[0175] For ease of interpretation, merge candidates included in the predicted region movement information list are referred to as predicted region merge candidates.

[0176] The encoder and decoder can predefine the maximum number of merge candidates that can be included in the predicted region motion information list. For example, the maximum number of merge candidates that can be included in the predicted region motion information list may be 1, 2, 3, 4, 5, 6, 7, 8 or more (e.g., 16).

[0177] Alternatively, information indicating the maximum number of merge candidates that can be included in the predicted region motion information list can be transmitted via a bitstream signal. This information is transmitted at the sequence level, image level, or slice level. The information may indicate the maximum number of merge candidates that can be included in the predicted region motion information list. Alternatively, the information may indicate the difference between the maximum number of merge candidates that can be included in the predicted region motion information list and the maximum number of merge candidates that can be included in the merge candidate list.

[0178] Alternatively, the maximum number of merge candidates to be included in the predicted region motion information list can be determined by the image size, slice size, or coding tree unit size.

[0179] The predicted region motion information list can be initialized using an image, slice, tile, brick, coded tree unit, or coded tree unit line (row or column) as the unit. For example, when a slice is initialized, the predicted region motion information list is also initialized, and it is possible that the predicted region motion information list does not contain any merge candidates.

[0180] Alternatively, information indicating whether to initialize the predicted region motion information list can be transmitted via a bitstream as a signal. This information may be transmitted at the slice level, tile level, brick level, or block level. The deployed predicted region motion information list can be used before the information indicates the initialization of the predicted region motion information list.

[0181] Alternatively, information related to initial predicted region merge candidates can be transmitted in the signal via an image parameter set or slice header. Even after the slice has been initialized, the initial predicted region merge candidates may be included in the predicted region motion information list. Therefore, the predicted region merge candidates are used for the block that is the first target to be encoded / decoded in the slice.

[0182] Alternatively, the initial prediction region merge candidates can be those included in the prediction region movement information list of the immediately preceding coding tree unit. For example, among the prediction region merge candidates included in the prediction region movement information list of the immediately preceding coding tree unit, the prediction region merge candidate with the smallest index or the prediction region merge candidate with the largest index can be used as the initial prediction region merge candidate.

[0183] Blocks are encoded / decoded according to the encoding / decoding order. Blocks encoded / decoded based on interpretation may also be set as candidates for prediction region merge, according to the encoding / decoding order.

[0184] Figure 17 is a flowchart showing the process for updating the predicted area motion information list.

[0185] When performing interpretation on the current block (S1701), a candidate for prediction region merge can be derived based on the current block (S1702). The movement information of the candidate for prediction region merge can be set to be equal to the movement information of the current block.

[0186] If the predicted region movement information list is empty (S1703), a predicted region merge candidate derived based on the current block can be added to the predicted region movement information list (S1704).

[0187] If the predicted region merge candidate is included in the predicted region movement information list (S1703), redundancy detection can be performed on the movement information of the current block (or the predicted region merge candidate derived based on the current block) (S1705). Redundancy detection is used to determine whether the movement information of the predicted region merge candidate stored in the predicted region movement information list is the same as the movement information of the current block. Redundancy detection can be performed on all predicted region merge candidates stored in the predicted region movement information list. Alternatively, redundancy detection can be performed on predicted region merge candidates stored in the predicted region movement information list whose index is greater than or less than a threshold.

[0188] If the current block does not contain any inter-prediction merge candidates that have motion information identical to that of the current block, the predicted region merge candidates derived based on the current block can be added to the predicted region motion information list (S1708). Whether the inter-merge candidates are the same can be determined based on whether their motion information (e.g., motion vectors and / or reference image indices) is the same.

[0189] In this case, if the maximum number of predicted region merge candidates are stored in the predicted region movement information list (S1706), the oldest predicted region merge candidate can be deleted (S1707), and a predicted region merge candidate derived based on the current block can be added to the predicted region movement information list (S1708). Here, the oldest predicted region merge candidate may be the predicted region merge candidate with the largest index or the predicted region merge candidate with the smallest index.

[0190] Each predicted region merge candidate may be labeled with an index. When adding a predicted region merge candidate derived from the current block to the predicted region movement information list, the smallest index (e.g., 0) is assigned to the predicted region merge candidate, and the index of the stored predicted region merge candidates can be incremented by 1. In this case, if the maximum number of interpredictive merge candidates is stored in the predicted region movement information list, the predicted region merge candidate with the largest index is removed.

[0191] Alternatively, when adding a predicted region merge candidate derived from the current block to the predicted region movement information list, the largest index can be assigned to the predicted region merge candidate. For example, if the number of inter-predictive merge candidates stored in the predicted region movement information list is less than the maximum value, an index equal to the number of inter-predictive merge candidates stored can be assigned to the predicted region merge candidate. Alternatively, if the number of inter-predictive merge candidates stored in the predicted region movement information list is equal to the maximum value, an index obtained by subtracting 1 from the maximum value can be assigned to the predicted region merge candidate. The predicted region merge candidate with the smallest index is then deleted. The index of the remaining stored predicted region merge candidates can also be decreased by 1.

[0192] Figure 18 shows an example of updating the list of candidate regions for merge.

[0193] When adding a predicted region merge candidate derived from the current block to the predicted region merge candidate list, we assume that the largest index is assigned to the predicted region merge candidate. We also assume that the predicted region merge candidate list contains the maximum number of predicted region merge candidates.

[0194] When adding the predicted region merge candidate HmvpCand[n+1] derived from the current block to the predicted region merge candidate list HmvpCandList, the predicted region merge candidate HmvpCand[0], which has the smallest index among the stored predicted region merge candidates, is deleted. Additionally, the indices of the remaining predicted region merge candidates can be decreased by 1. Furthermore, the index of the predicted 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 18).

[0195] If a predicted region merge candidate that is the same as the predicted region merge candidate derived based on the current block is stored (S1705), it is not necessary to add the predicted region merge candidate derived based on the current block to the predicted region movement information list (S1709).

[0196] Alternatively, when adding predicted region merge candidates derived based on the current block to the predicted region movement information list, it is possible to delete a stored predicted region merge candidate that is the same as the current one. In this case, the same effect as updating the index of stored predicted region merge candidates is achieved.

[0197] Figure 19 shows an example of updating the index of stored prediction region merge candidates.

[0198] If the index of an interpredictive merge candidate that is the same as the stored predictive region merge candidate mvCand derived based on the current block is hIdx, the index of the stored interpredictive merge candidate is deleted. In addition, the index of any interpredictive merge candidate whose index is greater than hIdx can be decreased by 1. For example, in the example shown in Figure 19, HmvpCand[2], which is the same as mvCand, is deleted from the predictive region motion information list HvmpCand list, and the indices of HmvpCand[3] through HmvpCand[n] are each decreased by 1.

[0199] Furthermore, the predicted region merge candidate mvCand derived from the current block can be added to the end of the predicted region movement information list.

[0200] Alternatively, you can update the index assigned to a predicted region merge candidate that is the same as the one stored and derived based on the current block. For example, you can change the index of a stored predicted region merge candidate to its minimum or maximum value.

[0201] The system may be configured not to add motion information of blocks included in a given region to the predicted region motion information list. For example, it is not necessary to add predicted region merge candidates derived based on the motion information of blocks included in the merge processing region to the predicted region motion information list. Since the encoding / decoding order of blocks included in the merge processing region is not defined, it is inappropriate to use the motion information of any one of these blocks for interpretation of other blocks. Therefore, it is not necessary to add predicted region merge candidates derived based on blocks included in the merge processing region to the predicted region motion information list.

[0202] Alternatively, motion information for blocks smaller than a predetermined size may be configured not to be added to the predicted region motion information list. For example, predicted region merge candidates derived based on motion information for coded blocks with a width or height of less than 4 or 8, or motion information for coded blocks with a size of 4x4, may not be added to the predicted region motion information list.

[0203] When performing motion compensation prediction on a subblock basis, a candidate for prediction region merge can be derived based on the motion information of a representative subblock among the multiple subblocks contained in the current block. For example, when using a candidate subblock merge for the current block, a candidate for prediction region merge can be derived based on the motion information of a representative subblock among the subblocks.

[0204] The motion vector of a subblock may 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. Furthermore, by adding the initial shift vector to the position (xSb, ySb) of the reference sample (e.g., top-left sample or middle-position sample) of each subblock in the encoded block, a shift subblock with the reference sample position (xColSb, yColSb) can be derived. Equation 4 below shows the formula for deriving a shift subblock.

number

[0205] Next, the motion vector of the collated block corresponding to the center position of the subblock containing (xColSb, yColSb) is set to the motion vector of the subblock containing (xSb, ySb).

[0206] A typical subblock may refer to a subblock containing the top-left or center sample of the current block.

[0207] Figure 20 shows the location of typical subblocks.

[0208] Figure 20(a) shows an example where a subblock located in the upper left of the current block is used as a representative subblock. Figure 20(b) shows an example where a subblock located in the center of the current block is used as a representative subblock. When motion compensation prediction is performed on a subblock basis, a candidate for the predicted region merge of the current block can be derived based on the motion vector of a subblock containing the upper left sample of the current block or a subblock containing the center sample of the current block.

[0209] Based on the interpretation mode of the current block, it is possible to determine whether to use the current block as a candidate for prediction region merging. For example, a block encoded / decoded based on an affine motion model can be set as unavailable as a candidate for prediction region merging. This ensures that even if the current block is encoded / decoded by interpretation, if the interpretation mode of the current block is affine prediction mode, the interpretation motion information list will not be updated based on the current block.

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

[0211] Alternatively, the predicted region merge candidate can be derived from the average 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, and third affine seed vectors of the current block can be set as the motion vector of the predicted region merge candidate.

[0212] Alternatively, a predicted region motion information list can be assigned to each inter-prediction mode. For example, at least one of the following can be defined: a predicted region motion information list for blocks encoded / decoded by intra-block replication, a predicted region motion information list for blocks encoded / decoded based on a translational motion model, and a predicted region motion information list for blocks encoded / decoded based on an affine motion model. Based on the inter-prediction mode of the current block, one of several predicted region motion information lists can be selected.

[0213] Figure 21 shows an example of generating a prediction region motion information list for each interpretation mode.

[0214] When encoding / decoding a block based on a non-affine motion model, the predicted region merge candidate mvCand derived based on the block can be added to the predicted region non-affine motion information list HmvpCandList. On the other hand, when encoding / decoding a block based on an affine motion model, the predicted region merge candidate mvAfCand derived based on the block can be added to the predicted region affine motion information list HmvpAfCandList.

[0215] The affine seed vector of a block, encoded / decoded based on an affine motion model, can be stored in a predicted region merge candidate derived from the block. Therefore, the predicted region merge candidate can be used as a merge candidate for deriving the affine seed vector of the current block.

[0216] In addition to the above predicted region movement information list, another predicted region movement information list can also be defined. In addition to the above predicted region movement information list (hereinafter referred to as the first predicted region movement information list), a long-term movement information list (hereinafter referred to as the second predicted region movement information list) can also be defined. Here, the long-term movement information list includes long-term merge candidates.

[0217] If both the first and second prediction region movement information lists are empty, a candidate for prediction region merge can first be added to the second prediction region movement information list. Only after the number of available prediction region merge candidates in the second prediction region movement information list reaches the maximum number can a candidate for prediction region merge be added to the first prediction region movement information list.

[0218] Alternatively, one interprediction merge candidate can be added to both the second prediction region motion information list and the first prediction region motion information list.

[0219] In this case, it is not necessary to update the second prediction region motion information list once the placement is complete. Alternatively, the second prediction region motion information list can be updated if the decoded region is greater than or equal to a predetermined ratio of the slice. Alternatively, the second prediction region motion information list can be updated every N coded tree unit lines.

[0220] On the other hand, the first predicted region motion information list can be updated each time a block is generated that has been encoded / decoded by interpretation. However, it is also possible to configure the system so that predicted region merge candidates added to the second predicted region motion information list are not used to update the first predicted region motion information list.

[0221] Information for selecting either a first predicted region motion information list or a second predicted region motion information list can be transmitted via a bitstream signal. If the number of merge candidates in the merge candidate list is less than a threshold, the merge candidates in the predicted region motion information list indicated by the information can be added to the merge candidate list.

[0222] Alternatively, a list of predicted region motion information can be selected based on the current block size and shape, interpretation mode, whether bidirectional prediction is enabled, whether motion vector improvement is enabled, or whether triangulation is enabled.

[0223] Alternatively, if a merge candidate for a predicted region is added to the first predicted region movement information list, and the number of merge candidates in the merge candidate list is less than the maximum number of merge candidates, then a merge candidate for a predicted region included in the second predicted region movement information list can be added to the merge candidate list.

[0224] Figure 22 shows an example of adding a candidate for merged forecast regions included in the long-term movement information list to the merge candidate list.

[0225] If the number of merge candidates in the merge candidate list is less than the maximum number, the predicted region merge candidates included in the first predicted region movement information list HmvpCandList can be added to the merge candidate list. If, even after adding the predicted region merge candidates included in the first predicted region movement information list to the merge candidate list, the number of merge candidates included in the merge candidate list is still less than the maximum number, then the predicted region merge candidates included in the long-term movement information list HmvpLTCandList can be added to the merge candidate list.

[0226] Table 2 shows the process of adding potential merge candidates for predicted regions included in the long-term movement information list to the merge candidate list. [Table 2]

[0227] Predicted region merge candidates may be configured to include additional information in addition to motion information. For example, block size, shape, or partition information can be stored separately for predicted region merge candidates. When building a list of merge candidates for the current block, only inter-merge candidates whose size, shape, or partition information is the same as or similar to the current block are used. Alternatively, inter-merge candidates whose size, shape, or partition information is the same as or similar to the current block can be preferentially added to the merge candidate list.

[0228] Alternatively, a list of predicted region motion information can be generated for each of the block's size, shape, or division information. By using the list of predicted region motion information that corresponds to the current block's shape, size, or division information from among multiple predicted region motion information lists, a list of merge candidates for the current block can be generated.

[0229] If the number of merge candidates currently included in the block merge candidate list is below a threshold, the predicted region merge candidates included in the predicted region movement information list can be added to the merge candidate list. This addition process is performed in ascending or descending order of index. For example, the predicted region merge candidate with the highest index can be added to the merge candidate list first.

[0230] When it is desired to add a predicted region merge candidate included in the predicted region movement information list to the merge candidate list, redundancy detection can be performed between the predicted region merge candidate and the merge candidate stored in the merge candidate list.

[0231] For example, Table 3 shows the process of adding a predicted region merge candidate to the merge candidate list. [Table 3]

[0232] Redundancy detection can be performed on only a subset of predicted region merge candidates included in the predicted region movement information list. For example, redundancy detection can be performed only on predicted region merge candidates whose index is above a threshold. Alternatively, redundancy detection can be performed only on the N merge candidates with the largest index or the N merge candidates with the smallest index.

[0233] Alternatively, redundancy detection can be performed on only a subset of the merge candidates stored in the merge candidate list. For example, redundancy detection 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, above-side adjacent block, right-upper adjacent block, or left-down adjacent block of the current block.

[0234] Figure 23 shows an example of performing redundancy detection on only some of the merge candidates.

[0235] When it is desired to add the predicted region merge candidate HmvpCand[j] to the merge candidate list, redundancy detection can be performed on the two merge candidates mergeMandCandList[NumMerge-2] and mergeCandList[NumMerge-1] that have the maximum index of the predicted region merge candidate. Here, NumMerge can represent the number of available spatial and temporal merge candidates.

[0236] When the situation differs from the illustrated example and it is desired to add the predicted region merge candidate HmvpCand[j] to the merge candidate list, redundancy detection can be performed on at most two merge candidates that have the same minimum index as the predicted region merge candidate. For example, it can be checked whether mergeCandList[0] and mergeCandList[1] are the same as HmvpCand[j].

[0237] Alternatively, redundancy detection can be performed only on merge candidates derived from a specific location. For example, redundancy detection can be performed on at least one of the following: a merge candidate derived from an adjacent block located to the left of the current block, or a merge candidate derived from an adjacent block located above the current block. If no merge candidates derived from a specific location exist in the merge candidate list, the predicted region merge candidate can be added to the merge candidate list without performing redundancy detection.

[0238] When it is desired to add the predicted region merge candidate HmvpCand[j] to the merge candidate list, redundancy detection can be performed on the two merge candidates mergeMandCandList[NumMerge-2] and mergeCandList[NumMerge-1] that have the maximum index of the predicted region merge candidate. Here, NumMerge can represent the number of available spatial and temporal merge candidates.

[0239] Redundancy detection can be performed on only some of the predicted area merge candidates. For example, redundancy detection can be performed on only the N predicted area merge candidates with the largest index or the N predicted area merge candidates with the smallest index among the predicted area merge candidates included in the predicted area movement information list. For example, redundancy detection can be performed only on predicted area merge candidates whose number and index difference is less than or equal to a threshold. If the threshold is 2, redundancy detection can be performed on only the three predicted area merge candidates with the largest index among the predicted area merge candidates included in the predicted area movement information list. Redundancy detection can be omitted for predicted area merge candidates other than these three. When redundancy detection is omitted, the predicted area merge candidates can be added to the merge candidate list regardless of whether they have movement information similar to that of the merge candidates.

[0240] On the other hand, redundancy detection may be configured to be performed only on predicted region merge candidates for which the difference between the number of predicted region merge candidates included in the predicted region movement information list and the index is greater than or equal to a threshold.

[0241] In encoders and decoders, the number of predicted region merge candidates for which redundancy detection is performed can be predefined. For example, the threshold may be an integer such as 0, 1, or 2.

[0242] Alternatively, the threshold can be determined based on at least one of the following: the number of merge candidates included in the merge candidate list and the number of predicted region merge candidates included in the predicted region movement information list.

[0243] When a merge candidate identical to the first predicted region merge candidate is found, and redundancy detection is performed on the second predicted region merge candidate, redundancy detection for the merge candidate identical to the first predicted region merge candidate can be omitted.

[0244] Figure 24 shows an example of omitting redundancy detection for a specific merge candidate.

[0245] When it is desired to add the predicted region merge candidate HmvpCand[i] with index i to the merge candidate list, redundancy detection is performed between the predicted region merge candidate and the merge candidates stored in the merge candidate list. In this case, if a merge candidate mergeCandList[j] that is the same as the predicted region merge candidate HmvpCand[i] is found, redundancy detection can be performed between the predicted region merge candidate HmvpCand[i-1] with index i-1 and the merge candidate without adding the predicted region merge candidate HmvpCand[i] to the merge candidate list. In this case, redundancy detection between the predicted region merge candidate HmvpCand[i-1] and the merge candidate mergeCandList[j] can be omitted.

[0246] For example, in the example shown in Figure 24, it is determined that HmvpCand[i] and mergeCandList[2] are the same. This allows redundancy detection to be performed on HmvpCand[i-1] without adding HmvpCand[i] to the merge candidate list. In this case, redundancy detection between HmvpCand[i-1] and mergeCandList[2] can be omitted.

[0247] If the number of merge candidates currently included in the block merge candidate list is below a threshold, the list may further include at least one of the following, in addition to the predicted region merge candidates: paired merge candidates and zero merge candidates. Paired merge candidates are merge candidates whose motion vector is the average of the motion vectors of two or more merge candidates, and zero merge candidates are merge candidates whose motion vector is 0.

[0248] Currently, merge candidates can be added to the list of block merge candidates in the following order.

[0249] Spatial merge candidates - Temporal merge candidates - Prediction region merge candidates - (Prediction region affine merge candidates) - Paired merge candidates - Zero merge candidates Spatial merge candidates are merge candidates derived from at least one adjacent or non-adjacent block, while temporal merge candidates are merge candidates derived from the immediately preceding reference image. Predicted region affine merge candidates represent predicted region merge candidates derived from blocks encoded / decoded by the affine motion model.

[0250] The prediction region motion information list may also be used in motion vector prediction mode. For example, if the number of motion vector prediction candidates included in the motion vector prediction candidate list for the current block is less than a threshold, the prediction region merge candidate included in the prediction region motion information list can be set as the motion vector prediction candidate for the current block. Specifically, the motion vector of the prediction region merge candidate can be set as the motion vector prediction candidate.

[0251] If you select one of the motion vector prediction candidates included in the current block's motion vector prediction candidate list, the selected candidate will be set as the current block's motion vector prediction value. Subsequently, after decoding the current block's motion vector residual value, the current block's motion vector can be obtained by adding the motion vector prediction value and the motion vector residual value.

[0252] Currently, a list of candidate block motion vector predictions can be constructed in the following order.

[0253] Spatial motion vector prediction candidate - Temporal motion vector prediction candidate - Interpretation region merge candidate - (Interpretation region affine merge candidate) - Zero motion vector prediction candidate Spatial motion vector prediction candidates are motion vector prediction candidates derived from at least one adjacent or non-adjacent block, while temporal motion vector prediction candidates are motion vector prediction candidates derived from the immediately preceding reference image. Prediction region affine merge candidates represent prediction region motion vector prediction candidates derived from blocks encoded / decoded by the affine motion model. Zero motion vector prediction candidates represent candidates whose motion vector value is 0.

[0254] A merge processing area larger than the encoded block can be specified. Encoded blocks contained within the merge processing area may not be encoded / decoded sequentially, but may be processed in parallel. Here, not performing encoding / decoding sequentially means that the order of encoding / decoding is not specified. This allows the encoding / decoding processes of the blocks contained within the merge processing area to be executed independently. Alternatively, blocks contained within the merge processing area may share merge candidates, which may be derived based on the merge processing area.

[0255] According to the above characteristics, the merge processing area can also be called a parallel processing area, a shared merge region (SMR), or a merge estimation region (MER).

[0256] The merge candidate of the current block may be derived based on the coded block. However, when the current block is included in a merge processing area whose size is larger than the size of the current block, candidate blocks included in the same merge processing area as the current block can be set as not available for use as merge candidates.

[0257] FIG. 25 is a diagram showing an example of setting candidate blocks included in the same merge processing area as the current block as not available for use as merge candidates.

[0258] In the example shown in FIG. 25(a), when encoding / decoding is performed on CU5, blocks including reference samples adjacent to CU5 can be set as candidate blocks. In this case, candidate blocks X3 and X4 included in the same merge processing area as CU5 can be set as not available for use as merge candidates for CU5. On the other hand, candidate blocks X0, X1, and X2 not included in the same merge processing area as CU5 can be set as available for use as merge candidates.

[0259] In the example shown in FIG. 25(b), when encoding / decoding is performed on CU8, blocks including reference samples adjacent to CU8 can be set as candidate blocks. In this case, candidate blocks X6, X7, and X8 included in the same merge processing area as CU8 can be set as not available for use as merge candidates. On the other hand, candidate blocks X5 and X9 not included in the same parallel merge area as CU8 can be set as available for use as merge candidates.

[0260] The merge processing area may be square or non-square. Information for determining the merge processing area can be transmitted as a signal via a bitstream. The information may include at least one of information indicating the shape of the merge processing area and information indicating the size of the merge processing area. When the merge processing area is non-square, at least one of information indicating the size of the merge processing area, information indicating the width and / or height of the merge processing area, and information indicating the ratio of the width to the height of the merge processing area can be transmitted as a signal via a bitstream.

[0261] The size of the merge processing area may be determined by at least one of the information transmitted as a signal via a bitstream, the image resolution, the size of a slice, or the size of a tile.

[0262] When performing motion compensation prediction on the blocks included in the merge processing area, a prediction area merge candidate derived based on the motion information of the blocks on which the motion compensation prediction has been performed can be added to the prediction area motion information list.

[0263] However, when adding a prediction area merge candidate derived from a block included in the merge processing area to the prediction area motion information list, when encoding / decoding is performed on another block in the merge processing area (which is actually encoded / decoded after the block has been encoded / decoded), the prediction area merge candidate derived from the block may be used. That is, when encoding / decoding is performed on the blocks included in the merge processing area, the dependency between blocks should be eliminated, but motion prediction compensation may be performed using the motion information of another block included in the merge processing area. To solve the above problem, even if the encoding / decoding for the blocks included in the merge processing area has been completed, the motion information of the encoded / decoded blocks may not be added to the prediction area motion information list.

[0264] Alternatively, when performing motion compensation prediction on blocks included in a merge processing area, the predicted area merge candidates derived from the blocks can be added to the predicted area motion information list according to a predefined order. Here, the predefined order may be determined by the scanning order of the encoded blocks in the merge processing area or the encoded tree unit. The scanning order may be at least one of raster scanning, horizontal scanning, vertical scanning, or zigzag scanning. Alternatively, the predefined order may be determined by the motion information of each block or the number of blocks having the same motion information.

[0265] Alternatively, a prediction region merge candidate containing unidirectional motion information can be added to the prediction region merge list before a prediction region merge candidate containing bidirectional motion information.

[0266] Alternatively, predicted region merge candidates can be added to the predicted region movement information list according to their frequency of use in the merge processing region or coding tree unit.

[0267] If the current block is included in the merge processing area, and the number of merge candidates in the current block's merge candidate list is less than the maximum number, the predicted area merge candidates included in the predicted area movement information list can be added to the merge candidate list. In this case, it may be configured not to add the predicted area merge candidates derived from blocks included in the same merge processing area as the current block to the current block's merge candidate list.

[0268] Alternatively, if the current block is included in the merge processing area, the system may be configured not to use the predicted area merge candidates included in the predicted area movement information list. In other words, even if the number of merge candidates included in the current block's merge candidate list is less than the maximum number, the predicted area merge candidates included in the predicted area movement information list do not need to be added to the merge candidate list.

[0269] A predicted area motion information list for a merge processing area or coding tree unit can be placed within the merge processing area. This predicted area motion information list serves to temporarily store motion information for blocks included in the merge processing area. To distinguish it from a general predicted area motion information list, the predicted area motion information list for a merge processing area or coding tree unit is called a temporary motion information list. Furthermore, the predicted area merge candidates stored in the temporary motion information list are called temporary merge candidates.

[0270] Figure 26 shows a list of temporary movement information.

[0271] A temporary motion information list for the coding tree unit or merge processing area can be placed. If motion compensation prediction has already been performed on the current block included in the coding tree unit or merge processing area, the motion information of the said block does not need to be added to the inter-prediction motion information list HmvpCandList. Conversely, temporary merge candidates derived from the said block can be added to the temporary motion information list HmvpMERCandList. In other words, temporary merge candidates added to the temporary motion information list do not need to be added to the prediction area motion information list. As a result, the prediction area motion information list may not include prediction area merge candidates derived based on the motion information of the blocks included in the coding tree unit or merge processing area.

[0272] The maximum number of merge candidates that can be included in the temporary motion information list can be set to the same number as the maximum number of merge candidates that can be included in the predicted region motion information list. Alternatively, the maximum number of merge candidates that can be included in the temporary motion information list may be determined by the size of the coding tree unit or the merge processing area.

[0273] The current block included in a coding tree unit or merge processing area can be configured not to use the temporary motion information list of the corresponding coding tree unit or merge processing area. In other words, if the number of merge candidates included in the merge candidate list of the current block is less than a threshold, the predicted area merge candidates included in the predicted area motion information list may be added to the merge candidate list, and the temporary merge candidates included in the temporary motion information list may not be added to the merge candidate list. Therefore, motion information of other blocks included in the same coding tree unit or merge processing area as the current block may not be used for motion compensation prediction for the current block.

[0274] Once encoding / decoding of all blocks contained within the coding tree unit or merge processing area is complete, the predicted area motion information list and the temporary motion information list can be merged.

[0275] Figure 27 shows an example of merging the predicted region motion information list and the temporary motion information list.

[0276] Once encoding / decoding of all blocks contained in the encoding tree unit or merge processing area is complete, the predicted area motion information list can be updated using the temporary merge candidates contained in the temporary motion information list, as shown in the example in Figure 27.

[0277] In this case, depending on the order in which they are inserted into the temporary movement information list (i.e., in ascending or descending order of index values), temporary merge candidates included in the temporary movement information list can be added to the predicted region movement information list.

[0278] As another example, temporary merge candidates included in the temporary motion information list can be added to the predicted region motion information list according to a predefined order.

[0279] Here, the predefined order may be determined by the scanning order of the coding blocks in the merge processing area or the coding tree unit. The scanning order may be at least one of raster scanning, horizontal scanning, vertical scanning, or zigzag scanning. Alternatively, the predefined order may be determined by the motion information of each block or the number of blocks having the same motion information.

[0280] Alternatively, before the temporary merge candidate including bidirectional motion information, the temporary merge candidate including unidirectional motion information can be added to the prediction area merge list. On the other hand, before the temporary merge candidate including unidirectional motion information, the temporary merge candidate including bidirectional motion information can be added to the prediction area merge candidate list.

[0281] Alternatively, according to the order of high usage frequency or low usage frequency in the merge processing area or the coding tree unit, the temporary merge candidate can be added to the prediction area motion information list.

[0282] When adding the temporary merge candidate included in the temporary motion information list to the prediction area motion information list, redundant detection for the temporary merge candidate can be performed. For example, if a prediction area merge candidate that is the same as the temporary merge candidate included in the temporary motion information list is stored in the prediction area motion information list, it may not be necessary to add the temporary merge candidate to the prediction area motion information list. In this case, redundant detection can be performed for some of the prediction area merge candidates included in the prediction area motion information list. For example, redundant detection can be performed for the inter-prediction merge candidates whose index is greater than or equal to the threshold value. For example, if the temporary merge candidate is the same as the prediction area merge candidate whose index is greater than or equal to the predefined value, it may not be necessary to add the temporary merge candidate to the prediction area motion information list.

[0283] The use of predicted region merge candidates derived from blocks included in the same coding tree unit or merge processing area as the current block's coding tree unit or merge processing area may be restricted to being used as merge candidates for the current block. For this purpose, block address information can be stored separately for predicted region merge candidates. The block address information includes at least one of the following: block location, block address, block index, location of the merge processing area containing the block, address of the merge processing area containing the block, index of the merge processing area containing the block, location of the coding tree area containing the block, address of the coding tree area containing the block, and index of the coding tree area containing the block.

[0284] Figures 28 and 29 show examples of address information for blocks included in a candidate for coding region merge.

[0285] The motion information of a block encoded by interpretation may be stored as motion information of a candidate for encoded region merge. For example, the block motion vector mv may be stored as the motion vector mvCand of the candidate for encoded region merge, and the block's reference image index RefIdx may be stored as the reference image index RefIdxCand of the candidate for encoded region merge.

[0286] Furthermore, block address information can be stored for the coding region merge candidates. For example, the block address BLK_ADR, the address of the merge processing region containing the block MER_ADDR, or the address of the coding tree unit containing the block CTU_ADDR can be stored separately.

[0287] In the example shown in Figure 28, the motion vector mvCand, the reference image index RefIdxCand, and the address MER_ADDR of the merge processing area are stored for the coding region merge candidate.

[0288] Multiple address pieces of information can be stored for the aforementioned coding region merge candidate. In the example shown in Figure 29, the motion vector mvCand, the reference image index RefIdxCand, the merge processing region address MER_ADDR, and the coding tree unit address CTU_ADDR are stored for the coding region merge candidate.

[0289] By comparing the address of the current block with the address of the coding region merge candidate, it is possible to determine whether the coding region merge candidate can be used as a merge candidate for the current block. For example, if the index of the merge processing region containing the current block is the same as the index of the merge processing region indicated by the coding region merge candidate, the coding region merge candidate can be set as unavailable as a merge candidate for the current block. Alternatively, if the index of the coding tree region containing the current block is the same as the index of the coding tree region indicated by the coding region merge candidate, the coding region merge candidate can be set as unavailable as a merge candidate for the current block. In other words, coding region merge candidates derived from blocks contained in the same merge processing region or coding tree unit as the current block, or coding region merge candidates derived from blocks adjacent to the current block, do not need to be added to the current block's merge candidate list.

[0290] Figures 30 and 31 illustrate an example in which a candidate for a coded region merge that has the same address information as the current block's address information is set as unavailable as a candidate for a merge of the current block.

[0291] If the index of the merge processing area to which the current block belongs is 2, the coding area merge candidate derived from the block belonging to the merge processing area with index 2 can be set as unavailable as a merge candidate for the current block. In the example shown in Figure 30, the address information of the coding area merge candidate HvmpCand[5] with index 5 points to index 2, so the coding area merge candidate can be set as unavailable as a merge candidate for the current block.

[0292] If the index of the coding tree unit to which the current block belongs is 2, and the index of the merge processing area to which the current block belongs is 1, then coding area merge candidates derived from blocks included in the same coding tree unit and merge processing area as the current block can be set as unavailable as merge candidates for the current block. In the example shown in Figure 31, if the coding area merge candidate HvmpCand[5] has an index of 5, then if the index of the coding tree unit is 2 and the index of the merge processing area is 1, then the coding area merge candidate can be set as unavailable as a merge candidate for the current block.

[0293] As another example, if the difference between the address information indicated by the coding region merge candidate and the address information of the current block exceeds a threshold, the coding region merge candidate can be set to be unavailable. For example, if the difference between the address or index of the coding tree unit indicated by the coding region merge candidate and the address or index of the coding tree unit to which the current block belongs exceeds a threshold, the coding region merge candidate can be set to be unavailable.

[0294] Alternatively, as another example, if the difference between the address information indicated by the coding region merge candidate and the address information of the current block is less than or equal to a threshold, the coding region merge candidate can be set as unavailable. For example, if the difference between the address information or index indicated by the coding region merge candidate and the address or index of the current block is less than or equal to a threshold, the coding region merge candidate can be set as unavailable. In other words, a coding region merge candidate derived from a block adjacent to the current block can be set as unavailable as a merge candidate for the current block.

[0295] When attempting to add a coding region merge candidate derived from the current block to the coding region motion information list, redundancy detection can be performed. In this case, redundancy detection may determine whether the motion information and address information of the coding region merge candidate derived from the current block are the same as the motion information and address information of the coding region merge candidate stored in the coding region motion information list. In this case, if a coding region merge candidate with the same motion vector, reference image index, and address information as the coding region merge candidate derived from the current block is stored, the coding region merge candidate derived from the current block does not need to be added to the coding region motion information list. Alternatively, if a coding region merge candidate with the same motion vector, reference image index, and address information as the coding region merge candidate derived from the current block is stored, the stored coding region merge candidate can be deleted, and the coding region merge candidate derived from the current block can be added to the coding region motion information list. In this case, the maximum or minimum index can be assigned to the coding region merge candidate derived from the current block.

[0296] Alternatively, when performing redundancy detection, the system may be configured not to consider whether the address information is the same. For example, even if the address information of a coding region merge candidate derived from the current block differs from the address information of a coding region merge candidate stored in the coding region movement information list, if the movement information of the two coding region merge candidates is the same, the coding region merge candidate derived from the current block does not need to be added to the coding region movement information list. Alternatively, if the address information of a coding region merge candidate derived from the current block is the same as the movement information (address information) of a coding region merge candidate stored in the coding region movement information list, but the address information (movement information) is different, the stored coding region merge candidate can be deleted, and the coding region merge candidate derived from the current block can be added to the coding region movement information list. In this case, the maximum or minimum index can be assigned to the coding region merge candidate derived from the current block.

[0297] Intra-prediction is the process of predicting the current block using encoded / decoded reconstructed samples from the surrounding area. In this case, the intra-prediction of the current block can use the reconstructed samples before applying the in-loop filter.

[0298] Intra-prediction techniques include matrix-based intra-prediction and general intra-prediction that considers orientation with surrounding reconstructed samples. Information indicating the intra-prediction technique of the current block can be transmitted via a bitstream signal. This information may be a 1-bit flag. Alternatively, the intra-prediction technique of the current block can be determined based on at least one of the current block's location, size, shape, or the intra-prediction techniques of adjacent blocks. For example, if the current block straddles an image boundary, the current block may be set not to have matrix-based intra-prediction applied.

[0299] Matrix-based intra-prediction is a method for obtaining a predicted block of the current block based on matrix multiplication of a matrix stored in an encoder and decoder with a reconstructed sample surrounding the current block. Information indicating one of several stored matrices can be transmitted via a bitstream signal. The decoder can determine the matrix to be used for the intra-prediction of the current block based on this information and the size of the current block.

[0300] A typical intra-prediction method is a way to obtain predicted blocks related to the current block based on either a non-angle intra-prediction mode or an angle intra-prediction mode.

[0301] The residual image can be derived by subtracting the original image from the predicted image. In this case, when the residual image is converted to the frequency domain, removing the high-frequency components does not significantly degrade the subjective image quality of the video. 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 obvious visual distortion. To reflect the above characteristics, the residual image can be decomposed into two-dimensional frequency components by transforming the current block. This transformation can be performed using transformation techniques such as the Discrete Cosine Transform (DCT) or the Discrete Sine Transform (DST).

[0302] After transforming the current block using DCT or DST, it is possible to perform another transformation on the transformed current block. In this case, the transformation based on DCT or DST is defined as the first transformation, and the process of performing another transformation on the block to which the first transformation was applied is called the second transformation.

[0303] The first transformation can be performed using any one of several transformation kernel candidates. For example, the first transformation can be performed using any one of DCT2, DCT8, or DCT7.

[0304] Different conversion kernels can be used for the horizontal and vertical directions. Information representing the combination of the horizontal and vertical conversion kernels can also be transmitted via a bitstream signal.

[0305] The execution units for the first and second transformations are different. For example, the first transformation can be performed on an 8x8 block, and the second transformation can be performed on a subblock of the transformed 8x8 block that is 4x4 in size. In this case, the transformation coefficient for the remaining area where the second transformation is not performed can also be set to 0.

[0306] Alternatively, the first transformation can be performed on a 4x4 block, and then the second transformation can be performed on an 8x8 region containing the transformed 4x4 block.

[0307] The bitstream can transmit information via a signal indicating whether or not to perform a second transformation.

[0308] In the decoder, the inverse of the second transformation (second inverse transformation) can be performed, and the inverse of the first transformation (first inverse transformation) can be performed on the result. As a result of performing the second and first inverse transformations, the residual signal of the current block can be obtained.

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

[0310] When the encoder performs the transformation and quantization, the decoder can obtain the residual block by inverse quantization and inverse transformation. In the decoder, the current block can be reconstructed by adding the predicted block and the residual block.

[0311] Once a reconstructed block is obtained, in-loop filtering can be used to reduce the loss of information that occurred during the quantization and encoding processes. 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).

[0312] The invention also includes the use of embodiments described with an emphasis on the decoding or encoding process in the encoding or decoding process. Furthermore, the invention also includes modifications of the embodiments described in a predetermined order, but in a different order than that described.

[0313] Although embodiments have been described based on a series of steps or flowcharts, this does not limit the chronological order of the invention. Furthermore, they may be executed simultaneously or in other orders as needed. In the above embodiments, the components constituting the block diagram (e.g., units, modules, etc.) may each be implemented as hardware devices or software. Multiple components may also be combined and executed as a single hardware device or software. The embodiments may be executed in the form of program instructions. These program instructions may be executed by various computer components and recorded on a computer-readable storage medium. The computer-readable storage medium may include program instructions, data files, data structures, etc., individually or in combination thereof. Examples of computer-readable storage media include magnetic media such as hard disks, flexible disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices such as ROMs, RAMs, and flash memory that are specifically configured to store and execute program instructions. The hardware devices may be configured to operate as one or more software modules and perform the processing according to the present invention, and vice versa. [Industrial applicability]

[0314] This invention is applicable to electronic devices that perform encoding / decoding of video.

Claims

1. A video decoding method, The current step is to derive a list of candidates for merging blocks, If the number of merge candidates included in the merge candidate list is less than a first threshold, the step is to determine, based on a condition, whether or not to add the predicted region merge candidates included in the predicted region motion information list to the merge candidate list, wherein the condition is: (a) Whether the difference between the number of predicted region merge candidates included in the predicted region movement information list and the index of the predicted region merge candidates is less than or equal to a second threshold; (b) Whether the predicted region merge candidate has the same motion information as at least one of the merge candidates included in the merge candidate list; The steps are as follows: In response to the decision to add the predicted region merge candidate to the merge candidate list, the steps include adding the predicted region merge candidate to the merge candidate list, The steps include: deriving the movement information of the current block based on the merge candidate list; A video decoding method comprising the step of performing motion compensation on the current block based on the derived motion information.

2. At least one merge candidate included in the merge candidate list includes a merge candidate derived from an adjacent block located to the left of the current block and a merge candidate derived from an adjacent block located above the current block. The video decoding method according to claim 1.

3. The step of determining whether or not to add the predicted region merge candidate included in the predicted region movement information list to the merge candidate list based on conditions is: If both conditions (a) and (b) are met, the step of deciding not to add the predicted region merge candidate to the merge candidate list, The process includes the step of deciding to add the predicted region merge candidate to the merge candidate list if at least one of conditions (a) and (b) is not met, The video decoding method according to claim 2.

4. If at least one of the above conditions (a) and (b) is not met, the step of deciding to add the predicted region merge candidate to the merge candidate list is: If condition (a) is not met, the step of deciding to add the predicted region merge candidate to the merge candidate list, regardless of whether condition (b) is met. The video decoding method according to claim 3.

5. The video decoding method further includes, when the coordinates of the top-left sample of the current block are (0,0), at least one merge candidate included in the merge candidate list includes a merge candidate derived from an adjacent block containing a reference sample at position (-1, H-1) and a merge candidate derived from an adjacent block containing a reference sample at position (W-1, -1), where H is the height of the current block and W is the width of the current block. The video decoding method according to any one of claims 2 to 4.

6. The aforementioned video decoding method further, The steps include determining the list of merge candidates based on at least one of the predicted region merge candidates, pairwise merge candidates, and zero merge candidates, in addition to the predicted region merge candidates, The step of deriving current block movement information based on the merge candidate list includes, The video decoding method according to any one of claims 1 to 5.

7. A video encoding method, The current step is to derive a list of candidates for merging blocks, If the number of merge candidates included in the merge candidate list is less than a first threshold, the step is to determine, based on a condition, whether or not to add the predicted region merge candidates included in the predicted region motion information list to the merge candidate list, wherein the condition is: (a) Whether the difference between the number of predicted region merge candidates included in the predicted region movement information list and the index of the predicted region merge candidates is less than or equal to a second threshold; (b) Whether the predicted region merge candidate has the same motion information as at least one of the merge candidates included in the merge candidate list; The steps are as follows: In response to the decision to add the predicted region merge candidate to the merge candidate list, the steps include adding the predicted region merge candidate to the merge candidate list, The steps include: deriving the movement information of the current block based on the merge candidate list; A video encoding method comprising the step of performing motion compensation on the current block based on the derived motion information.

8. At least one merge candidate included in the merge candidate list includes a merge candidate derived from an adjacent block located to the left of the current block and a merge candidate derived from an adjacent block located above the current block. The video encoding method according to claim 7.

9. The step of determining whether or not to add the predicted region merge candidate included in the predicted region movement information list to the merge candidate list based on conditions is: If both conditions (a) and (b) are met, the step of deciding not to add the predicted region merge candidate to the merge candidate list, The process includes the step of deciding to add the predicted region merge candidate to the merge candidate list if at least one of conditions (a) and (b) is not met, The video encoding method according to claim 8.

10. If at least one of the above conditions (a) and (b) is not met, the step of deciding to add the predicted region merge candidate to the merge candidate list is: If condition (a) is not met, the step of deciding to add the predicted region merge candidate to the merge candidate list, regardless of whether condition (b) is met. The video encoding method according to claim 9.

11. The video encoding method further includes, when the coordinates of the top-left sample of the current block are (0,0), at least one merge candidate included in the merge candidate list includes a merge candidate derived from an adjacent block containing a reference sample at position (-1, H-1) and a merge candidate derived from an adjacent block containing a reference sample at position (W-1, -1), where H is the height of the current block and W is the width of the current block. The video encoding method according to any one of claims 8 to 10.

12. The aforementioned video encoding method further, The steps include determining the list of merge candidates based on at least one of the predicted region merge candidates, pairwise merge candidates, and zero merge candidates, in addition to the predicted region merge candidates, The step of deriving current block movement information based on the merge candidate list includes, The video encoding method according to any one of claims 7 to 11.

13. A video decoding device comprising an interpretation unit for performing the video decoding method according to any one of claims 1 to 6.

14. A video encoding device comprising an interpretation unit for performing the video encoding method described in any one of claims 7 to 12.

15. A non-temporary computer-readable storage medium comprising a computer program and a bitstream, wherein the computer program causes a computer to perform the video encoding method according to any one of claims 7 to 12 in order to generate the bitstream.