Interpretation method and apparatus therefor

Abstract

To provide a method and apparatus for video coding capable of decreasing the complexity and improving the encoding / decoding efficiency.SOLUTION: An inter prediction method according to the present invention comprises the steps of: generating a merge candidate list for a block to be predicted corresponding to a current prediction unit; deriving, on the basis of one of a plurality of merge candidates constituting the merge candidate list, motion information on the block to be predicted; and performing, on the basis of the derived motion information, a prediction on the block to be predicted, so as to generate a prediction block corresponding to the current prediction unit.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present invention relates to video processing, and more particularly to an inter prediction method and apparatus.

Background Art

[0002] In recent years, the demand for high-resolution, high-quality video such as high-definition (HD) video and ultra-high-definition (UHD) video has been increasing in various fields. As the video data becomes higher in resolution and quality, the amount of information or bits to be transmitted relatively increases compared to existing video data. Therefore, when transmitting video data using a medium such as an existing wired or wireless broadband network, or when storing video data using an existing storage medium, the transmission cost and storage cost increase. To solve such problems, high-efficiency video compression technology is used.

[0003] As video compression technologies, there are various technologies such as an inter prediction technology that predicts pixel values included in a current picture from pictures before and / or after the current picture, an intra prediction technology that predicts pixel values included in the current picture using pixel information within the current picture, and an entropy coding technology that assigns short codewords to values with high occurrence frequencies and long codewords to values with low occurrence frequencies. Video data can be effectively compressed, transmitted, or stored using such video compression technologies.

Summary of the Invention

Problems to be Solved by the Invention

[0004] A technical problem of the present invention is to provide a video encoding method and apparatus that can reduce complexity and improve encoding / decoding efficiency.

[0005] Another technical problem of the present invention is to provide a video decoding method and apparatus that can reduce complexity and improve encoding / decoding efficiency.

[0006] Another technical problem of the present invention is to provide an interface prediction method and apparatus that can reduce complexity and improve coding / decoding efficiency.

[0007] Another technical problem of the present invention is to provide a merge candidate list generation method and apparatus that can reduce complexity and improve coding / decoding efficiency. [Means for solving the problem]

[0008] One embodiment of the present invention is an inter prediction method. This method includes the steps of: generating a merge candidate list of blocks to be predicted corresponding to the current prediction unit (current Prediction Unit, current PU); deriving motion information of a block to be predicted based on one of a plurality of merge candidates constituting the merge candidate list; and generating a prediction block corresponding to the current prediction unit by performing a prediction on the block to be predicted based on the derived motion information. The current prediction unit is a prediction unit belonging to a merge candidate sharing unit. In the merge candidate list generation step, one of a first merge candidate list composed of a plurality of first merge candidates and a second merge candidate list composed of a plurality of second merge candidates is selectively generated. The plurality of first merge candidates are motion information of a plurality of first blocks determined based on the position and size of the block to be predicted, and the plurality of second merge candidates are motion information of a plurality of second blocks determined based on the position and size of the block corresponding to the merge candidate sharing unit.

[0009] In the merge candidate list generation step, whether a first merge candidate list or a second merge candidate list is generated is determined by the merge candidate sharing unit. If it is determined that a second merge candidate list is generated, all prediction units within the merge candidate sharing unit share the second merge candidate list.

[0010] The merge candidate shared unit is the current coding unit (current CU) to which the current prediction unit belongs, and the multiple second merge candidates are movement information of multiple second blocks determined based on the position and size of the decoded block corresponding to the current coding unit.

[0011] Multiple first blocks include the block closest to the lower left corner outside the prediction target block, the lowest block among the blocks adjacent to the left of the prediction target block, the block closest to the upper left corner outside the prediction target block, the rightmost block among the blocks adjacent to the top edge of the prediction target block, and the block closest to the upper right corner of the prediction target block. Multiple second blocks include the block closest to the lower left corner outside the decryption target block, the lowest block among the blocks adjacent to the left of the decryption target block, the block closest to the upper left corner outside the decryption target block, the rightmost block among the blocks adjacent to the top edge of the decryption target block, and the block closest to the upper right corner of the decryption target block.

[0012] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, the movement information of blocks located within the decryption target block among multiple first blocks is not used as the first merge candidate.

[0013] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, and the current prediction unit's split mode is 2N×N, 2N×nU, or 2N×nD, and the current prediction unit is located at the lower end of the current coding unit, then the motion information of the rightmost block among the blocks adjacent to the upper end of the block to be predicted is not used as the first merge candidate.

[0014] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, and the current prediction unit's partition mode is N×2N, nL×2N, or nR×2N, and the current prediction unit is located on the right side within the current coding unit, then the movement information of the lowest-positioned block among the blocks adjacent to the left of the block to be predicted is not used as the first merge candidate.

[0015] The merge candidate list generation step and the motion information derivation step are performed in parallel for all prediction units within the parallel processing unit to which the current prediction unit belongs. The parallel processing unit is determined based on the parallel processing level, which indicates the size of the parallel processing unit. Information regarding the parallel processing level is included in the Picture Parameter Set (PPS) and transmitted from the encoder to the decoder.

[0016] In the merge candidate list generation step, whether a first merge candidate list or a second merge candidate list is generated is determined based on the size of the block to be decrypted and the parallel processing level.

[0017] In the merge candidate list generation step, a second merge candidate list is generated if the size of the block to be decrypted is 8x8 and the size of the parallel processing unit is greater than 4x4.

[0018] Another embodiment of the present invention is a video decoding method. This method includes the steps of: generating a merge candidate list of prediction target blocks corresponding to the current prediction unit; deriving motion information of prediction target blocks based on one of a plurality of merge candidates constituting the merge candidate list; generating a prediction block corresponding to the current prediction unit by performing a prediction on the prediction target block based on the derived motion information; and generating a restored block based on the generated prediction block. The current prediction unit is a prediction unit belonging to a merge candidate sharing unit. In the merge candidate list generation step, one of a first merge candidate list consisting of a plurality of first merge candidates and a second merge candidate list consisting of a plurality of second merge candidates is selectively generated. The plurality of first merge candidates are motion information of a plurality of first blocks determined based on the position and size of the prediction target block, and the plurality of second merge candidates are motion information of a plurality of second blocks determined based on the position and size of the block corresponding to the merge candidate sharing unit.

[0019] In the merge candidate list generation step, whether a first merge candidate list or a second merge candidate list is generated is determined by the merge candidate sharing unit. If it is determined that a second merge candidate list is generated, all prediction units within the merge candidate sharing unit share the second merge candidate list.

[0020] The merge candidate shared unit is the current coded unit to which the current prediction unit belongs, and the multiple second merge candidates are movement information of multiple second blocks determined based on the position and size of the decoded block corresponding to the current coded unit.

[0021] Multiple first blocks include the block closest to the lower left corner outside the block to be predicted, the lowest block among the blocks adjacent to the left of the block to be predicted, the block closest to the upper left corner outside the block to be predicted, the rightmost block among the blocks adjacent to the top edge of the block to be predicted, and the block closest to the upper right corner of the block to be predicted. Multiple second blocks include the block closest to the lower left corner outside the block to be decoded, the lowest block among the blocks adjacent to the left of the block to be decoded, the block closest to the upper left corner outside the block to be decoded, the rightmost block among the blocks adjacent to the top edge of the block to be decoded, and the block closest to the upper right corner of the block to be decoded.

[0022] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, the movement information of blocks located within the decryption target block among multiple first blocks is not used as the first merge candidate.

[0023] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, and the current prediction unit's split mode is 2N×N, 2N×nU, or 2N×nD, and the current prediction unit is located at the lower end of the current coding unit, then the motion information of the rightmost block among the blocks adjacent to the upper end of the block to be predicted is not used as the first merge candidate.

[0024] In the merge candidate list generation step, if it is determined that a first merge candidate list is generated, and the current prediction unit's partition mode is N×2N, nL×2N, or nR×2N, and the current prediction unit is located on the right side within the current coding unit, then the movement information of the lowest-positioned block among the blocks adjacent to the left of the block to be predicted is not used as the first merge candidate.

[0025] The merge candidate list generation step and the motion information derivation step are performed in parallel for all prediction units within the parallel processing unit to which the current prediction unit belongs. The parallel processing unit is determined based on the parallel processing level indicating the size of the parallel processing unit, and the information regarding the parallel processing level is included in the PPS and transmitted from the encoder to the decoder.

[0026] In the merge candidate list generation step, whether the first merge candidate list is generated or the second merge candidate list is generated is determined based on the size of the decoding target block and the parallel processing level.

[0027] In the merge candidate list generation step, when the size of the decoding target block is 8×8 and the size of the parallel processing unit is larger than 4×4, the second merge candidate list is generated.

Advantages of the Invention

[0028] According to the video encoding method of the present invention, the complexity is reduced, and the encoding / decoding efficiency can be improved.

[0029] According to the video decoding method of the present invention, the complexity is reduced, and the encoding / decoding efficiency can be improved.

[0030] According to the inter prediction method of the present invention, the complexity is reduced, and the encoding / decoding efficiency can be improved.

[0031] According to the merge candidate list generation method of the present invention, the complexity is reduced, and the encoding / decoding efficiency can be improved.

Brief Description of the Drawings

[0032] [Figure 1] It is a block diagram schematically showing a video encoding apparatus according to an embodiment of the present invention. [Figure 2] It is a conceptual diagram schematically showing a prediction unit according to an embodiment of the present invention. [Figure 3]This is a schematic block diagram showing an image decoding device according to one embodiment of the present invention. [Figure 4] This is a conceptual diagram illustrating the prediction unit of an image decoding device according to one embodiment of the present invention. [Figure 5] This is a conceptual diagram illustrating an example of a quadtree structure for a processing unit in a system to which the present invention is applied. [Figure 6] This flowchart outlines one example of an interface prediction method in merge mode. [Figure 7] This diagram schematically illustrates an example of a merge candidate used to generate a merge candidate list. [Figure 8] This diagram schematically illustrates one embodiment of a parallel processing unit in merge mode and skip mode. [Figure 9] This diagram outlines the problems that occur when performing parallel motion prediction in merge mode. [Figure 10] This figure schematically illustrates one embodiment of a merge candidate derivation method for enabling parallel motion prediction. [Figure 11] This figure schematically illustrates another embodiment of a merge candidate derivation method for enabling parallel motion prediction. [Figure 12] This figure schematically illustrates yet another embodiment of a merge candidate derivation method for enabling parallel motion prediction. [Figure 13] This figure schematically illustrates one embodiment of a method for deriving common merge candidates for prediction units within a merge candidate sharing unit. [Figure 14] This figure schematically illustrates another embodiment of a method for deriving common merge candidates for prediction units within a merge candidate sharing unit. [Figure 15] This figure schematically illustrates an example of a method for deriving MER merge candidates. [Figure 16] This figure schematically illustrates another embodiment of the MER merge candidate derivation method. [Figure 17] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 18] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 19] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 20] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 21] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 22] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 23] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Figure 24] This figure schematically illustrates yet another embodiment of the MER merge candidate derivation method. [Modes for carrying out the invention]

[0033] The present invention can be modified in various ways and may have many embodiments, but specific embodiments will be illustrated and described in detail in the drawings. However, this is not intended to limit the present invention to any particular embodiment. The terms used herein are used solely to describe specific embodiments and are not intended to limit the technical idea of ​​the present invention. Singular expressions include plural expressions unless they are clearly different in context. In this specification, terms such as "includes" or "has" are intended to specify the existence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preemptively exclude the possibility of the existence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0034] On the other hand, each configuration shown in the drawings described in this invention is shown independently for the convenience of describing a distinct characteristic function in the video encoding / decoding device, and does not mean that each configuration is implemented in separate hardware or separate software. For example, two or more of the configurations may be combined to form a single configuration, and a single configuration may be divided into multiple configurations. Embodiments in which each configuration is integrated and / or separated are also included within the scope of the invention as long as they do not deviate from the essence of the invention.

[0035] Furthermore, some components may not be essential components that perform an essential function in the present invention, but may be optional components that are merely for performance improvement. The present invention can be realized by including only the components that are essential to realizing the essence of the present invention, excluding components that are used merely for performance improvement, and a structure including only the essential components, excluding optional components that are used merely for performance improvement, is also included within the scope of the rights of the present invention.

[0036] Preferred embodiments of the present invention will be described in more detail below with reference to the attached drawings. Hereafter, the same reference numerals will be used for identical components in the drawings, and redundant descriptions of identical components will be omitted.

[0037] Figure 1 is a schematic block diagram showing a video encoding device according to one embodiment of the present invention.

[0038] Referring to Figure 1, the video encoding device 100 includes a picture division unit 105, a prediction unit 110, a conversion unit 115, a quantization unit 120, a realignment unit 125, an entropy encoding unit 130, an inverse quantization unit 135, an inverse conversion unit 140, a filter unit 145, and a memory 150.

[0039] The picture splitting unit 105 can split the input picture into at least one processing unit, in which case the processing unit may be a prediction unit (PU), a conversion unit (TU), or an encoding unit (CU).

[0040] As described later, the prediction unit 110 may include an inter-prediction unit that performs inter-prediction and an intra-prediction unit that performs intra-prediction. The prediction unit 110 can perform predictions on the picture processing units in the picture division unit 105 and generate prediction blocks. The picture processing units in the prediction unit 110 may be coding units, conversion units, or prediction units. Furthermore, it can determine whether the prediction performed on the processing unit is an inter-prediction or an intra-prediction, and determine the specific details of each prediction method (e.g., prediction mode). In this case, the processing unit on which the prediction is performed and the processing unit on which the prediction method and specific details are determined may be different. For example, the prediction method and prediction mode may be determined at the prediction unit level, and the prediction may be executed at the conversion unit level. The residual value (residual block) between the generated prediction block and the original block can be input to the conversion unit 115. In addition, the prediction mode information, motion vector information, etc. used for prediction can be encoded together with the residual value in the entropy coding unit 130 and transmitted to the decoder.

[0041] The transformation unit 115 performs transformations on the residual block in transformation units to generate transformation coefficients. The transformation unit in the transformation unit 115 is a transformation unit and can have a quad tree structure. In this case, the size of the transformation unit can be determined within a predetermined range of maximum and minimum sizes. The transformation unit 115 can transform the residual block using discrete cosine transform (DCT) and / or discrete sine transform (DST).

[0042] The quantization unit 120 can generate quantization coefficients by quantizing the residual values ​​converted by the conversion unit 115. The values ​​calculated by the quantization unit 120 are provided to the inverse quantization unit 135 and the realignment unit 125.

[0043] The re-arrangement unit 125 can re-arrange the quantization coefficients provided by the quantization unit 120. By re-arranging the quantization coefficients, the efficiency of coding in the entropy coding unit 130 can be increased. The re-arrangement unit 125 can re-arrange the 2D block form of quantization coefficients into a 1D vector form through a coefficient scanning method. The re-arrangement unit 125 can also increase the efficiency of entropy coding in the entropy coding unit 130 by changing the order of coefficient scanning based on the probabilistic statistics of the coefficients transmitted to the quantization unit.

[0044] The entropy coding unit 130 can perform entropy coding on the quantization coefficients realigned by the realignment unit 125. The entropy coding unit 130 can encode various types of information transmitted from the realignment unit 125 and the prediction unit 110, including quantization coefficient information and block type information of the coding unit, prediction mode information, division unit information, prediction unit information and transmission unit information, motion vector information, reference picture information, block interpolation information, and filter information.

[0045] Entropy coding can utilize coding methods such as exponential golomb, context-adaptive variable-length coding (CAVLC), and / or context-adaptive binary arithmetic coding (CABAC). For example, the entropy coding unit 130 can store a table for performing entropy coding, such as a variable-length coding (VLC) table, and the entropy coding unit 130 can perform entropy coding using the stored VLC table. As another example, in the CABAC entropy coding method, the entropy coding unit 130 can also generate a bitstream by binary-coding symbols into bins, and then performing arithmetic coding on the bins according to the probability of bin occurrence.

[0046] When entropy coding is applied, symbols with a high probability of occurrence are assigned low index values ​​and corresponding short codewords, while symbols with a low probability of occurrence are assigned high index values ​​and corresponding long codewords. Therefore, the amount of bits used for coding can be reduced, and entropy coding can improve video compression performance.

[0047] The inverse quantization unit 135 can inversely quantize the values ​​quantized by the quantization unit 120, and the inverse transformation unit 140 can inversely transform the values ​​inversely quantized by the inverse quantization unit 135. The residual values ​​generated by the inverse quantization unit 135 and the inverse transformation unit 140 can be combined with the predicted block predicted by the prediction unit 110 to generate a reconstructed block.

[0048] The filter unit 145 can apply an in-loop filter to the restored blocks and / or pictures. The in-loop filter may include a deblocking filter, a sample adaptive offset (SAO), and / or an adaptive loop filter (ALF).

[0049] The block removal filter can remove block distortion that occurs at the boundaries between blocks in the restored picture. SAO can add an appropriate offset value to the pixel value to compensate for encoding errors. ALF can perform filtering operations based on a comparison of the restored image with the original image after blocks have been removed through the block removal filter.

[0050] On the other hand, the filter unit 145 does not need to apply a filter operation to the restoration block used for intra prediction.

[0051] Memory 150 can store the restored blocks or pictures calculated through the filter unit 145. The restored blocks or pictures stored in memory 150 can be provided to the prediction unit 110, which performs interface prediction.

[0052] Figure 2 is a conceptual diagram illustrating a prediction unit according to one embodiment of the present invention.

[0053] Referring to Figure 2, the prediction unit 200 can include an intermediate prediction unit 210 and an intra-prediction unit 220.

[0054] The interface prediction unit 210 can make predictions and generate prediction blocks based on information from at least one picture, either a previous picture or a subsequent picture of the current picture. The intra prediction unit 220 can also make predictions and generate prediction blocks based on pixel information within the current picture.

[0055] The interface prediction unit 210 can select a reference picture for the prediction unit and select a reference block of the same size as the prediction unit in integer pixel sample units. Next, the interface prediction unit 210 can generate a prediction block that is most similar to the current prediction unit, minimizes the residual signal, and minimizes the magnitude of the encoded motion vector, in integer sample units such as 1 / 2 pixel sample units and 1 / 4 pixel sample units. At this time, the motion vector can be represented in units of integer pixels or less.

[0056] The index and motion vector information of the reference picture selected by the interface prediction unit 210 can be encoded and transmitted to the decoder.

[0057] Figure 3 is a schematic block diagram showing an image decoding device according to one embodiment of the present invention.

[0058] Referring to Figure 3, the video decoder 300 may include an entropy decoding unit 310, a realignment unit 315, an inverse quantization unit 320, an inverse transformation unit 325, a prediction unit 330, a filter unit 335, and a memory 340.

[0059] When a video bitstream is input to a video decoder, the input bitstream can be decoded according to the procedure by which the video information was processed by the video encoder.

[0060] The entropy decoding unit 310 can perform entropy decoding on the input bitstream, and the entropy decoding method is similar to the entropy encoding method described above. When entropy decoding is applied, symbols with a high probability of occurrence are assigned a low index value and a corresponding short codeword, and symbols with a low probability of occurrence are assigned a high index value and a corresponding long codeword. Therefore, the amount of bits for the symbols to be encoded is reduced, and video compression performance can be improved by entropy encoding.

[0061] The information decoded by the entropy decoding unit 310 for generating prediction blocks is provided to the prediction unit 330, and the residual values ​​after entropy decoding by the entropy decoding unit are input to the re-sorting unit 315.

[0062] The re-arrangement unit 315 can re-arrange the bitstream that has been entropically decoded by the entropy decoding unit 310 based on the method re-arranged by the video encoder. The re-arrangement unit 315 can re-arrange the coefficients expressed in one-dimensional vector form by further restoring them to two-dimensional block form coefficients. The re-arrangement unit 315 can re-arrange the information related to the coefficient scan performed by the encoder by scanning it in reverse based on the scan order performed by the encoding unit.

[0063] The inverse quantization unit 320 can perform inverse quantization based on the quantization parameters supplied from the encoder and the coefficient values ​​of the rearranged blocks.

[0064] The inverse transform unit 325 can perform inverse DCT and / or inverse DST on the DCT and DST performed by the transform unit of the encoder with respect to the quantization result performed by the video encoder. The inverse transform can be performed based on the transmission unit or video division unit determined by the encoder. The DCT and / or DST in the transform unit of the encoder can be performed selectively based on multiple pieces of information such as the prediction method, the size of the current block and / or the prediction direction, and the inverse transform unit 325 of the decoder can perform the inverse transform based on the transformation information performed by the transform unit of the encoder.

[0065] The prediction unit 330 can generate predicted blocks based on prediction block generation-related information provided by the entropy decoding unit 310 and previously decoded block and / or picture information provided by the memory 340. The restored blocks can be generated using the predicted blocks generated by the prediction unit 330 and the residual blocks provided by the inverse transform unit 325.

[0066] The restored blocks and / or pictures can be provided to the filter unit 335. The filter unit 335 can apply an in-loop filter to the restored blocks and / or pictures. The in-loop filter may include a block removal filter, SAO and / or ALF, etc.

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

[0068] Figure 4 is a conceptual diagram illustrating the prediction unit of an image decoding device according to one embodiment of the present invention.

[0069] Referring to Figure 4, the prediction unit 400 can include an intra-prediction unit 420 and an inter-prediction unit 410.

[0070] The intra-prediction unit 420 can generate prediction blocks based on pixel information within the current picture when the prediction mode for the prediction unit in question is intra-prediction mode (in-screen prediction mode).

[0071] When the prediction mode for the prediction unit in question is the inter-prediction mode (inter-screen prediction mode), the inter-prediction unit 410 can use information necessary for inter-prediction of the current prediction unit provided by the video encoder, such as motion vectors and reference picture indexes, to perform inter-prediction for the current prediction unit based on information contained in at least one picture that precedes or follows the current picture containing the current prediction unit.

[0072] At this time, when the skip flag, merge flag, etc. of the encoding unit received from the encoder are confirmed, motion information can be derived from these.

[0073] Hereinafter, in accordance with the structure or expression of the invention, when "image" or "screen" has the same meaning as "picture," "picture" may be referred to as "image" or "screen." Furthermore, inter-prediction and inter-screen prediction have the same meaning, and intra-prediction and in-screen prediction have the same meaning.

[0074] Figure 5 is a conceptual diagram illustrating an example of a quadtree structure of a processing unit in a system to which the present invention is applied.

[0075] A coding unit (CU) is the unit in which a picture is coded / decoded. A single coding block within a picture to be coded has a depth based on a quadtree structure and can be repeatedly divided. When this happens, coding blocks that cannot be further divided correspond to coding units, and the encoder can perform coding operations on these coding units. Coding units can have multiple sizes, such as 64x64, 32x32, 16x16, and 8x8.

[0076] Here, coding blocks that are repeatedly divided based on a quadtree structure can be called coding tree blocks (CTBs). A coding tree block may not be further divided, in which case the coding tree block itself corresponds to a coding unit. Therefore, a coding tree block may correspond to the largest coding unit, the Largest Coding Unit (LCU). On the other hand, the smallest coding unit within a coding tree block is sometimes called the Smallest Coding Unit (SCU).

[0077] Referring to Figure 5, the coding tree block 500 can have a hierarchical structure consisting of even smaller coding units 510 through partitioning, and the hierarchical structure of the coding tree block 500 can be identified based on size information, depth information, partitioning flag information, etc. Information related to the size of the coding tree block, partitioning depth information, partitioning flag information, etc., can be included in the sequence parameter set (SPS) on the bitstream and transmitted from the encoder to the decoder.

[0078] On the other hand, whether to perform interpretation or intrapretation can be determined at the coding unit level. When interpretation is performed, the interpretation mode and motion information can be determined at the prediction unit level, and when intrapretation is performed, the intrapretation mode can be determined at the prediction unit level. In this case, as described above, the processing unit in which prediction is performed and the processing unit in which the prediction method and specific content are determined may be the same or they may be different. For example, the prediction method and prediction mode can be determined at the prediction unit level, and the prediction can be executed at the transformation unit level.

[0079] Referring to Figure 5, one coding unit 510 may be used as one prediction unit, or it may be divided into multiple prediction units. In the case of intra-prediction 520, the partitioning mode of the coding unit (and / or prediction unit) is 2N×2N or N×N (where N is an integer). Here, in the 2N×2N mode, the prediction unit can have a size of 2N×2N, and in the N×N mode, the prediction unit can have a size of N×N. In the case of inter-prediction 530, the partitioning mode of the coding unit (and / or prediction unit) is 2N×2N, 2N×N, N×2N, N×N, 2N×nU, 2N×nD, nL×2N, or nR×2N (where N is an integer). Here, in the 2N×N mode, the prediction unit can have a size of 2N×N, and in the N×2N mode, the prediction unit can have a size of N×2N. Furthermore, in 2N×nU mode, one coding unit can be divided into a prediction unit of size 2N×(1 / 2)N and a prediction unit of size 2N×(3 / 2)N, in which case the 2N×(1 / 2)N prediction unit can be located at the upper end of the 2N×(3 / 2)N prediction unit. In 2N×nD mode, one coding unit can be divided into a prediction unit of size 2N×(3 / 2)N and a prediction unit of size 2N×(1 / 2)N, in which case the 2N×(1 / 2)N prediction unit can be located at the lower end of the 2N×(3 / 2)N prediction unit. Furthermore, in nL×2N mode, one coding unit can be divided into a prediction unit of size (1 / 2)N×2N and a prediction unit of size (3 / 2)N×2N, in which case the (1 / 2)N×2N prediction unit can be located to the left of the (3 / 2)N×2N prediction unit. In nR×2N mode, one coding unit can be divided into a prediction unit of size (3 / 2)N×2N and a prediction unit of size (1 / 2)N×2N, in which case the prediction unit of size (1 / 2)N×2N can be located to the right of the prediction unit of size (3 / 2)N×2N.

[0080] The above-described division modes represent only one embodiment, and the method by which the coding unit is divided into prediction units is not limited to this embodiment. For example, in the case of interpretation 530, only four division modes of the coding unit (and / or prediction unit) may be used: 2N×2N, 2N×N, N×2N, and N×N. In addition, other division modes other than the eight division modes described above may also be used.

[0081] The partitioning mode applied to the current coding unit (and / or prediction unit) can be determined by the encoder. Information regarding the partitioning mode determined by the encoder can be encoded and transmitted to the decoder, which can then determine the partitioning mode of the current coding unit (and / or prediction unit) based on the transmitted partitioning mode information. For example, partitioning mode information can be transmitted to the decoder via the part_mode syntax.

[0082] On the other hand, the numbers assigned to each prediction unit shown in Figure 5, 520 and 530, indicate the division index of the prediction unit. Here, the division index refers to an index that indicates which of the prediction units belonging to the current coding unit the current prediction unit corresponds to. The division index is represented by partIdx as an example.

[0083] Referring to Figure 5, as an example, in the 520 N×N partitioning mode in Figure 5, the partitioning index of the prediction unit located in the upper right of the coding unit corresponds to 1. Therefore, when 1 is assigned to the partitioning index of the current prediction unit, the value of the partitioning index indicates that the current prediction unit is located in the upper right of the current coding unit. As another example, in the 530 2N×nU partitioning mode in Figure 5, the partitioning index of the prediction unit located on the left side of the coding unit corresponds to 0. Therefore, when 0 is assigned to the partitioning index of the current prediction unit, the value of the partitioning index indicates that the current prediction unit is located on the left side of the current coding unit.

[0084] The division index assignment method in each division mode shown in Figure 5 is merely one embodiment, and the presence or absence of division index assignment and the assignment method may differ from the embodiments described above. For example, in the 2N × nU division mode of 530 in Figure 5, the division index of the prediction unit located on the left side of the coding unit may correspond to 1. As another example, in the 2N × 2N division mode, the coding unit is not divided into multiple prediction units, so a division index may not be assigned to the prediction unit. In the embodiments described later in this specification, for the sake of explanation, it will be assumed that the division modes and division indices shown in Figure 5 are applied during coding and decoding.

[0085] In this specification, "current block" refers to the block currently being coded, coded, and / or predicted, and which corresponds to the processing unit at the time the coding, coding, and / or prediction is performed. For example, when prediction is performed on the current block, the current block corresponds to the predicted block corresponding to the current prediction unit. In this specification, the block generated by the prediction is called the predicted block.

[0086] The term "unit" refers to a processing unit used in encoding and decoding, and is sometimes distinguished from a "block," which represents a combination of pixels and / or samples. However, for the sake of clarity, in this specification, "unit" may sometimes refer to the "block" that corresponds to a "unit." For example, in this specification, a prediction target block corresponding to a single prediction unit may be called a prediction unit, and a coding / decoding target block corresponding to a single coding unit may be called a coding unit. Such distinctions should be clearly understood by anyone with ordinary knowledge in the relevant art.

[0087] On the other hand, when inter-prediction is performed on the current block, prediction modes such as Advanced Motion Vector Prediction (AMVP), merge mode, and / or skip mode are used to reduce the amount of information transmitted due to the prediction.

[0088] In merge mode, the current block can be merged with other blocks in the current picture and / or reference picture (for example, surrounding blocks, where surrounding blocks include blocks adjacent to the current block and / or blocks located closest to the outer corners of the current block). In this case, merging means that in the inter-prediction of the current block, motion information is obtained from the motion information of other blocks in the current picture and / or reference picture.

[0089] The merge-related information for the current block includes information indicating whether the prediction mode for the current block is merge mode, and information indicating which of the merge candidates included in the merge candidate list the current block will be merged into. Hereafter, the information indicating whether the prediction mode for the current block is merge mode will be called the merge flag, and the information indicating which of the merge candidates included in the merge candidate list the current block will be merged into will be called the merge index. For example, the merge flag is represented by merge_flag, and the merge index is represented by merge_idx. In this case, the merge index can be configured to be retrieved only when the merge flag indicates that the prediction mode for the current block is merge mode (for example, merge_flag=1).

[0090] Skip mode is a prediction mode in which the transmission of the residual signal, which is the difference between the predicted block and the current block, is omitted. In skip mode, the value of the residual signal between the predicted block and the current block is 0. Therefore, in skip mode, the encoder does not transmit the residual signal to the decoder, and the decoder can generate the predicted block using only the motion information from the residual signal and motion information. In skip mode, the encoder can transmit motion information to the decoder. At this time, the motion information can also be transmitted by specifying one of the surrounding blocks of the current block and using the motion information of that block for the current block.

[0091] In the skip mode described above, the same method used in the merge mode can be used to obtain the motion information of the current block. In this case, the same surrounding blocks can be used as candidate blocks for deriving motion information in both the skip mode and the merge mode. For example, even in the skip mode, the motion information of the merge candidate block indicated by the merge index from among the merge candidate lists can be used directly as the motion information of the current block. Such a skip mode is also called a merge skip mode. Hereafter in this specification, the skip mode refers to the merge skip mode described above. A specific example of the interface prediction method in the merge mode will be described later in relation to Figure 6.

[0092] Figure 6 is a flowchart illustrating one embodiment of an interface prediction method in merge mode.

[0093] The embodiment shown in Figure 6 can be applied to both an encoder and a decoder, and for convenience, the embodiment shown in Figure 6 will be described below primarily in terms of the decoder.

[0094] Referring to Figure 6, the decoder can generate a merge candidate list consisting of multiple merge candidates (S610). The decoder can derive multiple merge candidates through a predetermined process and generate a merge candidate list based on the derived merge candidates. At this time, motion information contained in blocks within the current picture and / or in identically positioned blocks (col blocks) in reference pictures that are not the current picture can be used as merge candidates and / or used for deriving merge candidates. Hereinafter, for the sake of explanation, blocks containing motion information used as merge candidates will be referred to as "merge candidate blocks". Examples of merge candidates used for generating the merge candidate list will be described later.

[0095] Furthermore, referring to Figure 6, the decoder can derive motion information for the current block based on the generated merge candidate list (S620).

[0096] Specifically, the decoder can select a merge candidate from the merge candidate list to be used to derive the motion information of the current block. In one embodiment, the decoder can select a merge candidate indicated by the merge index transmitted from the encoder as the merge candidate to be used to derive the motion information of the current block. In this case, the decoder can derive the motion information of the current block based on the selected merge candidate. For example, the decoder can use the motion information of the selected merge candidate directly as the motion information of the current block.

[0097] Once the motion information of the current block is derived, the encoder can generate a predicted block for the current block based on the derived motion information (S630).

[0098] Figure 7 is a schematic diagram illustrating an example of merge candidates used to generate a merge candidate list.

[0099] As described above, when merge mode is applied, the motion information of the current block can be derived based on the motion information of one of the merge candidates included in the merge candidate list. For example, the motion information of one of the merge candidates included in the merge candidate list can be used as the motion information of the current block. In this case, the residual signal may be transmitted along with the motion information, or the residual signal may not be transmitted if the pixel values ​​of the predicted block are used directly as the pixel values ​​of the current block.

[0100] Figure 7, block 710 shows an example of a merge candidate used to generate a merge candidate list. Referring to Figure 7, block 710 shows that block A, which surrounds the left side of the current block, and / or block B, which surrounds the top edge of the current block, are used as merge candidate blocks. In this case, as shown in the figure, the block surrounding the left side of the current block may be the block located at the top edge of the blocks adjacent to the left side of the current block, and the block surrounding the top edge of the current block may be the block located at the leftmost position of the blocks adjacent to the top edge of the current block. Then, block C, which is in the lower left corner, and / or block D, which is in the upper right corner, are used as merge candidate blocks. The aforementioned left-side surround block A, upper-edge surround block B, lower-left corner block C, and upper-right corner block D are the surrounding blocks of the current block located within the current picture. Therefore, the merge candidates derived from the merge candidate blocks can be called spatial merge candidates. From another perspective, spatial merge candidates can be used to predict the motion vector of the current block, and are therefore sometimes called Spatial Motion Vector Predictors (SMVP).

[0101] Furthermore, in Figure 7, at 710, a co-located block (col) is used as a merge candidate block. A co-located block corresponds to a block in a reference picture that is not the current picture. Specifically, the encoder and decoder can select a block at a predetermined location in the reference picture and / or a location determined by a predetermined process as a co-located block. Here, the location of the co-located block can be derived based on the current block and / or a block in the reference picture that is co-located with the current block (hereinafter referred to as a "co-located block" for convenience of explanation). The co-located block described above is a block derived from the reference picture. Therefore, merge candidates derived from co-located blocks are sometimes called temporal merge candidates. Also, from another perspective, since temporal merge candidates can be used to predict the motion vector of the current block, they are sometimes called Temporal Motion Vector Predictors (TMVP).

[0102] Figure 7, 720 shows another example of merge candidates used to generate the merge candidate list. Referring to Figure 7, 720, the merge candidate list includes motion information for the lower left corner block A0, the upper right corner block B0, and / or the upper left corner block B2 as merge candidates. The merge candidate list also includes motion information for the left peripheral block A1 and / or the top peripheral block B1 of the current block as merge candidates. In this case, the left peripheral block A1 is the lowest-positioned block among the blocks adjacent to the left of the current block, and the top peripheral block B1 is the rightmost-positioned block among the blocks adjacent to the top of the current block. The aforementioned lower left corner block A0, left peripheral block A1, upper right corner block B0, top peripheral block B1, and upper left corner block B2 correspond to the peripheral blocks of the current block located within the current picture. Therefore, the merge candidates derived from the merge candidate blocks are sometimes called spatial merge candidates. From another perspective, spatial merge candidates can be used to predict the motion vector of the current block, and are therefore sometimes called spatial motion vector predictors (SMVPs).

[0103] Furthermore, in Figure 7, 720, similar to Figure 7, 710, the motion information of the same-location block is included in the merge candidate list and used as a merge candidate. As mentioned above, the same-location block corresponds to a block in a reference picture that is not the current picture. Here, the position of the same-location block can be derived based on the current block and / or the same-location block. The same-location block mentioned above is a block derived from the reference picture. Therefore, merge candidates derived from the same-location block are sometimes called temporal merge candidates. Also, from another perspective, since temporal merge candidates can be used to predict the motion vector of the current block, they are sometimes called temporal motion vector predictors (TMVPs).

[0104] In this specification, the merge candidates used to generate the merge candidate list are not limited to the embodiments described above, and merge candidates may be derived in a different manner than those described above, if necessary. However, unless otherwise specified, this specification assumes that merge candidates at the positions shown in Figure 7, 720, relative to the block to be predicted (and / or the current block), are used for predicting the merge mode. Furthermore, when this specification describes merge candidates for prediction units that are subject to merging / skipping, the block closest to the lower left corner outside the prediction unit is denoted as A0, the block at the bottom of the blocks adjacent to the left side of the prediction unit is denoted as A1, the block closest to the upper right corner outside the prediction unit is denoted as B0, the block at the rightmost of the blocks adjacent to the top edge of the prediction unit is denoted as B1, and the block closest to the upper left corner outside the prediction unit is denoted as B2.

[0105] Referring to the embodiment in Figure 7, the method for selecting merge candidates to constitute the merge candidate list can be extended in various ways. The encoder and decoder can select merge candidates and constitute the merge candidate list according to the embodiment in Figure 7 described above. In this case, when merge candidates are selected, the encoder and decoder can also constitute the merge candidate list by eliminating duplicate candidates to reduce redundancy.

[0106] Furthermore, in the embodiment shown in Figure 7 described above, the number of merge candidates constituting the merge candidate list can be limited to a predetermined fixed number. For example, suppose in the embodiment of 720 in Figure 7, the number of merge candidates is limited to 5, and merge candidates are added and / or inserted into the merge candidate list in the order {A1, B1, B0, A0, B2, col}. In this case, when blocks A1, B1, B0, A0, B2, and col are all available, only the movement information of blocks A1, B1, B0, A0, and col can be determined as merge candidates to be included in the merge candidate list. As another example, the number of available blocks among A1, B1, B0, A0, B2, and col may be less than 5. In this case, the encoder and decoder can derive new merge candidates through a predetermined process based on the available merge candidates so that the final number of derived merge candidates is 5.

[0107] On the other hand, as an example, when performing inter prediction in merge mode and / or skip mode, the encoder and decoder can perform motion prediction (ME) sequentially for each prediction unit. However, as another example, in order to improve coding / decoding performance, the encoder and decoder can also perform motion prediction for multiple prediction units simultaneously. That is, motion prediction in merge mode and / or skip mode can be performed in parallel for multiple prediction units, and motion prediction in such cases can be called parallel motion prediction. Hereinafter, in this specification, merge modes to which parallel motion prediction is applied will be referred to as parallel merge mode and / or parallel merge and pre-prediction, and skip modes to which parallel motion prediction is applied will be referred to as parallel skip mode and / or parallel skip.

[0108] For the sake of explanation, the embodiments described below will focus primarily on the parallel merge mode. However, the embodiments described below are not limited to the parallel merge mode and can be applied to the parallel skip mode in the same or similar manner.

[0109] Figure 8 is a schematic diagram illustrating one embodiment of a parallel processing unit in merge mode and skip mode.

[0110] The overall block shown in Figure 8 represents a single coding tree block (CTB), and a coding tree block can correspond to a maximum coding unit (LCU). As described above, a coding tree block can have a hierarchical structure consisting of even smaller coding units through partitioning, and each coding unit can be used as a single prediction unit or partitioned into multiple prediction units. Therefore, the square block and rectangular block that make up the coding tree block in Figure 8 each correspond to a single prediction unit.

[0111] On the other hand, the square blocks 810, 820, 830, and 840 shown in Figure 8 each represent parallel processing units in which parallel motion prediction is performed. That is, the Largest Code Unit (LCU) can be divided into multiple parallel processing units that do not overlap with each other. Here, as an example, multiple parallel processing units can have the same size. In this case, the encoder and decoder can perform motion prediction simultaneously for all prediction units within a single parallel processing unit. For example, motion prediction can be performed in parallel for prediction units A and B contained in parallel processing unit 810. Since a parallel processing unit corresponds to the region to which parallel motion prediction is applied, it is sometimes called a Motion Estimation Region (MER). Hereafter, for the sake of explanation, in this specification, a parallel processing unit in which parallel motion prediction is performed will be referred to as a MER.

[0112] When parallel motion prediction is applied in merge mode and / or skip mode, the encoder needs to transmit information related to the parallel motion prediction to the decoder. As mentioned above, since parallel motion prediction may be applied to all prediction units within the MER, the information transmitted from the encoder to the decoder corresponds to the parallel processing level in merge mode and / or skip mode. Here, the parallel processing level corresponds to the size of the parallel processing unit in which parallel motion prediction is performed, and therefore also corresponds to the size of the MER. For example, if parallel motion prediction is performed in blocks of size 32x32, i.e., if the size of the MER is 32x32, then it can be said that parallel motion prediction is performed at a 32x32 parallel processing level. The parallel processing level indicates the parallel processing level in merge mode and / or merge-skip mode, and is therefore sometimes called the parallel-merge level.

[0113] Here, the level of parallel processing may be limited to a certain range. For example, the level of parallel processing may be limited to 4x4 or a size less than or equal to the size of the LCU. In this case, the MER may be smaller than or equal to the size of the LCU and / or the CTB.

[0114] The information regarding the parallel processing level described above can be transmitted from the encoder to the decoder in a sequence parameter set (SPS) or picture parameter set (PPS) on the bitstream. As one embodiment, the parallel processing level-related information included in the PPS can be defined by syntactic elements as shown in Table 1 below.

[0115] [Table 1]

[0116] Here, log2_parallel_merge_level_minus2 indicates the parallel processing level in merge mode and / or skip mode. More precisely, the value assigned to log2_parallel_merge_level_minus2 corresponds to the logarithm of the actual parallel processing level, i.e., the logarithm of the actual MER size minus 2. When the minimum size of the prediction unit is 4x4, the minimum logarithm of the parallel processing level corresponds to 2. Therefore, to reduce the amount of transmitted information, log2_parallel_merge_level_minus2 is assigned the value of the actual parallel processing level minus 2.

[0117] The parallel processing level information defined in PPS is not limited to the embodiments described above. In the embodiments of Table 1, the syntax for other information besides the parallel processing level information may be applied differently as needed.

[0118] On the other hand, log2_parallel_merge_level_minus2 in Table 1 can have meanings like those in the example shown in Table 2, depending on the value assigned to it.

[0119] [Table 2]

[0120] Referring to Table 2, if log2_parallel_merge_level_minus2 is assigned a value of 0, the size of the MER corresponds to 4x4. In this case, since the size of the minimum prediction unit is 4x4, the encoder and decoder can sequentially predict motion for all prediction units within the LCU. As another example, if log2_parallel_merge_level_minus2 is assigned a value of 2, the size of the MER corresponds to 16x16. In this case, the encoder and decoder can perform parallel motion prediction at a 16x16 parallel processing level. That is, the encoder and decoder can perform motion prediction in parallel for all prediction units within the 16x16 block. Similarly, if other values ​​are assigned to log2_parallel_merge_level_minus2, the encoder and decoder can perform parallel motion prediction in a similar manner depending on the assigned value.

[0121] On the other hand, a single coding tree block can contain multiple coding units (CUs). In this case, a single parallel processing unit, i.e., a single MER, can contain one prediction unit (PU) and have the same size as a single coding unit. Furthermore, a single MER can contain multiple coding units.

[0122] For example, referring to Figure 8, MER810 has the same size as a single coding unit composed of prediction unit A and prediction unit B. Also, MER830 and MER840 have the same size as coding unit G and coding unit H, respectively. In this way, when a single coding unit has the same size as a MER, parallel motion prediction for that coding unit can be considered to be performed on a coding unit basis. On the other hand, MER820 can include coding unit C (coding unit C corresponds to prediction unit C), coding unit D (coding unit D includes prediction units D1 and D2), coding unit E (coding unit E corresponds to prediction unit E), and coding unit F (coding unit F includes prediction units F1 and F2). In this case, motion prediction in merge mode and / or skip mode can be performed in parallel for all of the prediction units C, D1, D2, E, F1, and F2 within MER820.

[0123] On the other hand, as shown in the embodiment of Figure 8 above, in order for parallel motion prediction to be performed in merge mode and / or skip mode, inter-prediction and / or motion prediction must be able to be performed independently for each prediction unit within the parallel processing unit, i.e., within the MER. However, problems related to parallel motion prediction may arise in the merge mode and / or skip mode described above.

[0124] Figure 9 is a diagram illustrating the problems that occur during parallel execution in merge mode. Numbers 910, 920, 930, and 940 in Figure 9 each represent a single encoding unit.

[0125] As explained in Figure 8, the parallel processing unit, i.e., the MER, may or may not be the same size as the current coding unit. In the embodiment shown in Figure 9, we assume that the size of the MER is the same as the current coding unit. In this case, each coding unit shown in Figure 9 corresponds to a parallel processing unit, and in this case, parallel motion prediction may be performed at the coding unit level. However, the problems described later in Figure 9 may occur in the same or similar way even when the size of the MER is larger than the current coding unit.

[0126] In Figure 9, at 910, the partitioning mode of the coding unit (and / or prediction unit) is 2N × 2N. Therefore, one coding unit can be used as prediction unit A without being partitioned, thus avoiding the problems associated with parallel motion prediction.

[0127] In Figure 9, at 920, the division mode of the coding unit (and / or prediction unit) is 2N × N. In this case, motion prediction must be performed simultaneously for the upper prediction unit B1 and the lower prediction unit B2 in order to perform parallel motion prediction. However, among the merge candidates for the lower prediction unit B2, the motion information of block 925, which is adjacent to the upper end of the lower prediction unit B2 and is located on the far right, can only be used as a merge candidate for the lower prediction unit B2 when the coding / decoding of the upper prediction unit B1 is complete. Thus, since the lower prediction unit B2 uses motion information belonging to the upper prediction unit B1, motion prediction cannot be performed simultaneously for the prediction units belonging to the coding unit 920 in Figure 9.

[0128] In Figure 9, at 930, the division mode of the coding unit (and / or prediction unit) is N×2N. In this case, motion prediction must be performed simultaneously for the left prediction unit C1 and the right prediction unit C2 in order to perform parallel motion prediction. However, among the merge candidates for the right prediction unit C2, the motion information of block 935, which is adjacent to the left side of the right prediction unit C2 and is located at the bottom edge, can only be used as a merge candidate for the right prediction unit C2 when the coding / decoding of the left prediction unit C1 is complete. Thus, since the right prediction unit C2 uses motion information belonging to the left prediction unit C1, motion prediction cannot be performed simultaneously for the prediction units belonging to the coding unit 930 in Figure 9.

[0129] In Figure 9, at 940, the division mode of the coding unit (and / or prediction unit) is N×N. In this case, motion prediction must be performed simultaneously for the upper-left prediction unit D1, upper-right prediction unit D2, lower-left prediction unit D3, and lower-right prediction unit D4 in order to perform parallel motion prediction. However, as an example, among the merge candidates for the lower-right prediction unit D4, the motion information of block 941 located in the upper-left corner of the lower-right prediction unit D4, block 943 located furthest to the right adjacent to the top edge of the lower-right prediction unit D4, and block 945 located at the bottom edge adjacent to the left side of the lower-right prediction unit D4 can only be used as a merge candidate for the lower-right prediction unit D4 when the coding / decoding of the upper-left prediction unit D1, upper-right prediction unit D2, and lower-left prediction unit D3 are completed, respectively. Furthermore, in Figure 9, at 940, similar problems to those described above may occur with the upper-right prediction unit D2 and lower-left prediction unit D3. Thus, since prediction units other than the upper left prediction unit D1 use motion information belonging to other prediction units, it is not possible to perform motion prediction simultaneously for prediction units belonging to the 940 coding unit in Figure 9.

[0130] In the embodiments described above, only the problems when the partitioning modes of the coding unit (and / or prediction unit) are 2N×2N, 2N×N, N×2N, and N×N are mentioned. However, similar problems may occur in other partitioning modes (e.g., 2N×nU, 2N×nD, nL×2N, or nR×2N). Below, embodiments of a merge candidate derivation method and a merge candidate list construction method for solving the problems described in Figure 9 will be explained.

[0131] Figure 10 is a schematic diagram illustrating one embodiment of a merge candidate derivation method for enabling parallel motion prediction.

[0132] In Figure 10, numbers 1010 through 1060 each represent a single coding unit, and the numbers displayed for each prediction unit belonging to each coding unit indicate the division index.

[0133] In the embodiment shown in Figure 10, for the sake of explanation, we assume that the size of the MER is the same as that of the current coding unit. In this case, each coding unit shown in Figure 10 corresponds to a parallel processing unit, and in this case, parallel motion prediction may be performed on a coding unit basis. However, the embodiment shown in Figure 10, which will be described later, may also be applied identically to each coding unit belonging to a parallel processing level even when the size of the MER, i.e., the parallel processing level, is larger than that of the coding unit.

[0134] On the other hand, as explained in Figure 9, within a MER where parallel motion prediction is performed, there may be prediction units that use motion information from other blocks (and / or prediction units) that have not yet been encoded / decoded. In such cases, motion prediction cannot be performed simultaneously for prediction units belonging to the MER. Therefore, to solve this problem, the encoder and decoder do not use blocks for which motion information is not available as merge candidate blocks. That is, the encoder and decoder treat blocks as unavailable during the merge candidate derivation process and do not add the block's motion information to the merge candidate list.

[0135] In Figure 10, at point 1010, the partitioning mode of the coding unit (and / or prediction unit) is 2N × N, and the merge candidates for the lower end prediction unit with a partitioning index of 1 are shown. In this case, of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block B1 belongs to another prediction unit within the same coding unit. Therefore, since block B1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the lower end prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0136] Furthermore, when predicting the motion of a lower-end prediction unit with a division index of 1, the motion information of blocks A0 and B0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of blocks may not be completed. In this case, since blocks A0 and B0 are blocks that cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-end prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0137] As shown in the 1010 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a lower end prediction unit with a partition index of 1 is 2. In this case, if 1 is added to the number of spatial merge candidates to consider temporal merge candidates, the maximum number of available merge candidates derived for a lower end prediction unit is 3.

[0138] In Figure 10, at point 1020, the partitioning mode of the coding unit (and / or prediction unit) is 2N × nU, and the merge candidates for the lower end prediction unit with a partitioning index of 1 are shown. In this case, of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block B1 belongs to another prediction unit within the same coding unit. Therefore, since block B1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the lower end prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0139] Furthermore, when predicting the motion of a lower-end prediction unit with a division index of 1, the motion information of blocks A0 and B0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of blocks may not be completed. In this case, since blocks A0 and B0 are blocks that cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-end prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0140] As shown in the 1020 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a lower end prediction unit with a partition index of 1 is 2. In this case, when 1 is added to the number of spatial merge candidates to consider temporal merge candidates, the maximum number of available merge candidates derived for a lower end prediction unit is 3.

[0141] In Figure 10, at point 1030, the partitioning mode of the coding unit (and / or prediction unit) is 2N × nD, and the merge candidates for the lower end prediction unit with a partitioning index of 1 are shown. In this case, among blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block B1 belongs to another prediction unit within the same coding unit. Therefore, since block B1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the lower end prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0142] Furthermore, when predicting the motion of a lower-end prediction unit with a division index of 1, the motion information of blocks A0 and B0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of blocks may not be completed. In this case, since blocks A0 and B0 are blocks that cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-end prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0143] As shown in the 1030 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a lower end prediction unit with a partition index of 1 is 2. In this case, when 1 is added to the number of spatial merge candidates to consider temporal merge candidates, the maximum number of available merge candidates derived for a lower end prediction unit is 3.

[0144] In Figure 10, at point 1040, the partitioning mode of the coding unit (and / or prediction unit) is N×2N, and the merge candidates for the right-hand prediction unit with a partitioning index of 1 are shown. Of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block A1 belongs to another prediction unit within the same coding unit. Therefore, since block A1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-hand prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0145] Furthermore, when predicting the motion of a right-side prediction unit with a split index of 1, the motion information for block A0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of the block may not be completed. In this case, since block A0 is a block that cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-side prediction unit. In this case, the block's motion information is not added to the merge candidate list.

[0146] As shown in the 1040 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a right-side prediction unit with a partition index of 1 is 3. In this case, when 1 is added to the number of spatial merge candidates to account for temporal merge candidates, the maximum number of available merge candidates derived for a right-side prediction unit is 4.

[0147] In Figure 10, at point 1050, the partitioning mode of the coding unit (and / or prediction unit) is nL × 2N, and the merge candidates for the right-hand prediction unit with a partitioning index of 1 are shown. Of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block A1 belongs to another prediction unit within the same coding unit. Therefore, since block A1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-hand prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0148] Furthermore, when predicting the motion of a right-side prediction unit with a split index of 1, the motion information for block A0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of the block may not be completed. In this case, since block A0 is a block that cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-side prediction unit. In this case, the block's motion information is not added to the merge candidate list.

[0149] As shown in the 1050 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a right-side prediction unit with a partition index of 1 is 3. In this case, when 1 is added to the number of spatial merge candidates to account for temporal merge candidates, the maximum number of available merge candidates derived for a right-side prediction unit is 4.

[0150] In Figure 10, at point 1060, the partitioning mode of the coding unit (and / or prediction unit) is nR × 2N, and the merge candidates for the right-hand prediction unit with a partitioning index of 1 are shown. Of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, block A1 belongs to another prediction unit within the same coding unit. Therefore, since block A1 cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-hand prediction unit. In this case, the motion information of the block is not added to the merge candidate list.

[0151] Furthermore, when predicting the motion of a right-side prediction unit with a split index of 1, the motion information for block A0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of the block may not be completed. In this case, since block A0 is a block that cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the right-side prediction unit. In this case, the block's motion information is not added to the merge candidate list.

[0152] As shown in the 1060 embodiment of Figure 10, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a right-side prediction unit with a partition index of 1 is 3. In this case, when 1 is added to the number of spatial merge candidates to account for temporal merge candidates, the maximum number of available merge candidates derived for a right-side prediction unit is 4.

[0153] In the embodiments described above, during the process of deriving spatial merge candidates, the encoder and decoder can treat the surrounding blocks of the prediction unit as unavailable according to predetermined conditions. This can be expressed as follows:

[0154]

number

[0155] Here, availableFlagN is a flag indicating whether block N (where N is one of A0, A1, B0, B1, and B2) is an available block that can be used as a merge candidate block. Also, mvLXN indicates the motion vector of block N, and refIdxLXN indicates the reference picture index of block N, where X can have a value of 0 or 1. And predFlagLXN is a flag indicating whether or not an LX prediction is performed for block N.

[0156] There are various conditions for treating surrounding blocks of a prediction unit as unavailable. For example, if block N is block B2, and blocks A0, A1, B0, and B1 are all available, block B2 is treated as unavailable in order to maintain a number of five merge candidates, including the block at the same location. Also, if the prediction mode of a surrounding block is intra-mode, that block is treated as unavailable. This can be expressed as follows:

[0157]

number

[0158] Furthermore, as in the embodiment described above, if the partitioning mode of the current coding unit (and / or prediction unit) is 2N×N, 2N×nU, or 2N×nD, and the partitioning index of the current prediction unit is 1, block B1 is treated as unavailable. And if the partitioning mode of the current coding unit (and / or prediction unit) is N×2N, nL×2N, or nR×2N, and the partitioning index of the current prediction unit is 1, block A1 is treated as unavailable. This can be expressed as follows:

[0159]

number

[0160] The last two conditions described above enable parallel motion prediction for all prediction units belonging to the same coding unit by ensuring that prediction units belonging to the same coding unit are not subordinate to each other. Furthermore, if one prediction unit uses motion information belonging to another prediction unit within the same coding unit, then the rectangular prediction units within the same coding unit will have the same motion information, resulting in having the same motion information as the 2N×2N division mode. In this case, the last two conditions described above can prevent the rectangular prediction units within the same coding unit from having the same motion information as the 2N×2N division mode.

[0161] Figure 11 schematically illustrates another embodiment of a merge candidate derivation method for enabling parallel motion prediction. Numbers 1110 through 1130 in Figure 11 each represent a single coding unit, and the numbers displayed for each prediction unit belonging to each coding unit represent the partition index.

[0162] In the embodiment shown in Figure 11, for the sake of explanation, we assume that the size of the MER is the same as that of the current coding unit. In this case, each coding unit shown in Figure 11 corresponds to a parallel processing unit, and in this case, parallel motion prediction can be performed on a coding unit basis. However, the embodiment shown in Figure 11, which will be described later, can also be applied identically to each coding unit belonging to a parallel processing level even when the size of the MER, i.e., the parallel processing level, is larger than that of the coding unit.

[0163] On the other hand, the embodiment shown in Figure 10 describes the cases where the partitioning modes of the coding unit (and / or prediction unit) are 2N×N, 2N×nU, 2N×nD, N×2N, nL×2N, and nR×2N. However, even when the partitioning mode of the coding unit (and / or prediction unit) is N×N, within the MER where parallel motion prediction is performed, there may be prediction units that use motion information from other blocks (and / or prediction units) that have not yet been coded / decoded. In such cases, motion prediction cannot be performed simultaneously for prediction units belonging to the MER. Therefore, to solve this problem, the encoder and decoder do not use the motion information of blocks for which motion information is unavailable as merge candidates. That is, the encoder and decoder treat blocks as unavailable during the merge candidate derivation process and do not add the block's motion information to the merge candidate list.

[0164] In Figure 11, at 1110, the partitioning mode of the coding unit (and / or prediction unit) is N×N, and the merge candidates for the upper right prediction unit with a partitioning index of 1 are shown. In this case, of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, blocks A0 and A1 belong to other prediction units within the same coding unit. In this case, the upper right prediction unit is dependent on other prediction units within the same coding unit. Therefore, since blocks A0 and A1 cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the upper right prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0165] As shown in the 1110 embodiment in Figure 11, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for the upper right prediction unit with a partition index of 1 is 3. In this case, when 1 is added to the number of spatial merge candidates to consider temporal merge candidates, the maximum number of available merge candidates derived for the upper right prediction unit is 4.

[0166] In Figure 11, at point 1120, the partitioning mode of the coding unit (and / or prediction unit) is N×N, and the merge candidates for the lower-left prediction unit with a partitioning index of 2 are shown. In this case, of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, blocks B0 and B1 belong to other prediction units within the same coding unit. In this case, the lower-left prediction unit is dependent on other prediction units within the same coding unit. Therefore, since blocks B0 and B1 cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-left prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0167] Furthermore, when predicting the motion of the lower-left prediction unit, where the division index is 2, the motion information for block A0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of the block may not be completed. In this case, since block A0 is a block that cannot be used during parallel motion prediction, it is treated as unavailable and is not used as a merge candidate block for the lower-left prediction unit. In this case, the block's motion information is not added to the merge candidate list.

[0168] As shown in the 1120 embodiment in Figure 11, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for the lower-left prediction unit with a partition index of 2 is 2. In this case, if 1 is added to the number of spatial merge candidates to consider temporal merge candidates, the maximum number of available merge candidates derived for the lower-left prediction unit is 3.

[0169] In Figure 11, at point 1130, the partitioning mode of the coding unit (and / or prediction unit) is N×N, and the merge candidates for the lower-right prediction unit with a partitioning index of 3 are shown. In this case, of the blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, blocks A1, B1, and B2 belong to other prediction units within the same coding unit. In this case, the lower-right prediction unit is dependent on other prediction units within the same coding unit. Therefore, since blocks A1, B1, and B2 cannot be used during parallel motion prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-right prediction unit. In this case, the motion information of the blocks is not added to the merge candidate list.

[0170] Furthermore, when predicting the movement of a lower-right prediction unit with a division index of 3, the movement information of blocks A0 and B0 may not be available. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of blocks may not be completed. In this case, since blocks A0 and B0 are blocks that cannot be used during parallel movement prediction, they are treated as unavailable and are not used as merge candidate blocks for the lower-right prediction unit. In this case, the movement information of the blocks is not added to the merge candidate list.

[0171] As shown in the 1130 embodiment in Figure 11, when blocks that cannot be used during parallel motion prediction are treated as unavailable, the number of spatial merge candidates derived for a lower-right prediction unit with a partition index of 3 is 0. In this case, when 1 is added to the number of spatial merge candidates to account for temporal merge candidates, the maximum number of available merge candidates derived for a lower-right prediction unit is 1.

[0172] In the embodiments described above, during the process of deriving spatial merge candidates, the encoder and decoder can process the surrounding blocks of the prediction unit as unavailable according to predetermined conditions. As illustrated in Figure 10, there can be various conditions for processing the surrounding blocks of the prediction unit as unavailable.

[0173] According to the embodiment in Figure 11, if the partitioning mode of the current coding unit (and / or prediction unit) is N×N and the partitioning index of the current prediction unit is 1, blocks A0 and A1 are treated as unavailable. If the partitioning mode of the current coding unit (and / or prediction unit) is N×N and the partitioning index of the current prediction unit is 2, blocks B0 and B1 are treated as unavailable. Furthermore, if the partitioning mode of the current coding unit (and / or prediction unit) is N×N and the partitioning index of the current prediction unit is 3, blocks A1, B1, and B2 are treated as unavailable. The three conditions can be added to the embodiment described in Figure 10 as follows.

[0174]

number

[0175] The three additional conditions in the above-described embodiment prevent one prediction unit belonging to an encoding unit from referencing motion information of other prediction units belonging to the same encoding unit. Therefore, according to the above-described embodiment, parallel derivation of spatial merge candidates becomes possible for all prediction units belonging to the same encoding unit.

[0176] On the other hand, in parallel merge mode and / or parallel skip mode, when the embodiments of Figures 10 and 11 described above are applied, the maximum number of available merge candidates that can be derived for each prediction unit by the split mode and split index can be estimated. The maximum number of available merge candidates for each prediction unit is estimated by adding the number of temporal merge candidates (e.g., 1) to the number of available spatial merge candidates that can be used for parallel motion prediction. For example, in each split mode shown in Figures 10 and 11, a maximum of 5 available merge candidates can be derived for a prediction unit with a split index value of 0. As another example, in a 2N×N split mode as shown in 1010 of Figure 10, a maximum of 3 available merge candidates can be derived for a prediction unit with a split index of 1. The maximum number of available merge candidates derived for each prediction unit by the split mode and split index is shown in Table 3 below as one embodiment.

[0177] [Table 3]

[0178] Here, PartMode indicates the partition mode of the coding unit (and / or prediction unit), partIdx indicates the partition index of the prediction unit, and maxNumMergeCand indicates the maximum number of available merge candidates derived for the prediction unit.

[0179] On the other hand, as explained in Figure 7, if the number of merge candidates is limited to five, the merge index will indicate one of the five merge candidates. In this case, the amount of bits corresponding to the five merge candidates can be used for transmitting the merge index. However, as mentioned above, the maximum number of available merge candidates derived for the prediction unit may be less than five, in which case the amount of bits required for transmitting the merge index is less than the amount of bits corresponding to the five merge candidates. In other words, the more blocks that are treated as unavailable, the less bit is actually required to transmit the merge index. At this time, bits used in excess of the actual amount of bits required to transmit the merge index can be considered wasted bits for the merge index.

[0180] To address the aforementioned problems, the encoder and decoder can reduce or save the amount of bits used to transmit the merge index by encoding / decoding the merge index by applying the number of merge candidates optimized by the division mode and division index.

[0181] As one embodiment, the encoder and decoder can store the same table as shown in Table 3. In this case, the encoder can determine the maximum number of available merge candidates that can be derived for any prediction unit based on the division mode and division index, based on the table. The encoder can then encode the merge index for the prediction unit based on the maximum number and transmit it to the decoder. In this case, since only the amount of bits corresponding to the maximum number is used for transmitting the merge index, the amount of bits used for transmitting the merge index can be reduced. Since the decoder stores the same table, it can determine the maximum number of available merge candidates that can be derived for any prediction unit in the same way as the encoder. In this case, the decoder can decode the merge index transmitted from the encoder based on the maximum number.

[0182] On the other hand, referring to 1130 in Figure 11 and Table 3, if the partitioning mode of the coding unit (and / or prediction unit) is N×N and the partitioning index value of the prediction unit belonging to the coding unit is 3, then only one temporal merge candidate corresponds to the available merge candidate for the prediction unit. In this case, the maximum number of available merge candidates that can be derived for the prediction unit is 1. When the maximum number of available merge candidates is 1, the decoder can determine which merge candidate will be used to derive the motion information of the prediction unit even without a merge index. Therefore, if the partitioning mode of the coding unit (and / or prediction unit) is N×N and the partitioning index value of the prediction unit belonging to the coding unit is 3, the encoder does not transmit a merge index for the prediction unit to the decoder.

[0183] Figure 12 schematically illustrates yet another embodiment of a merge candidate derivation method for enabling parallel motion prediction. In Figure 12, 1210 represents a single coding unit, and the numbers displayed for each prediction unit belonging to the coding unit represent the division index.

[0184] In the embodiment shown in Figure 12, for the sake of explanation, we assume that the size of the MER is the same as that of the current coding unit. In this case, the coding unit shown in Figure 12 corresponds to a parallel processing unit, and in this case, parallel motion prediction can be performed on a coding unit basis. However, the embodiment shown in Figure 12, which will be described later, can also be applied to each coding unit belonging to a parallel processing level even when the size of the MER, i.e., the parallel processing level, is larger than that of the coding unit.

[0185] In the embodiments shown in Figures 10 and 11 above, merge candidates corresponding to blocks for which motion information is unavailable during parallel motion prediction are treated as unavailable and are not added to the merge candidate list. In this case, merge candidates treated as unavailable can be replaced with merge candidates used when the partitioning mode of the current coding unit (and / or prediction unit) is 2N × 2N.

[0186] In Figure 12, at 1210, the current coding unit (and / or prediction unit) has a partitioning mode of 2N × N, and the prediction unit currently being targeted for motion prediction is the lower-end prediction unit with a partitioning index of 1. In this case, as explained in Figure 10, among blocks A0, A1, B0, B1, and B2 used as merge candidate blocks, blocks A0, B0, and B1 cannot be used during parallel motion prediction and are therefore treated as unavailable.

[0187] However, when the division mode of the current coding unit (and / or prediction unit) is 2N × 2N, blocks B0' (the block closest to the upper right corner outside the current coding unit) and B1' (the rightmost block among the blocks adjacent to the top edge of the current coding unit), which are used as merge candidate blocks, may also contain motion information that can be used when performing parallel motion prediction. Therefore, the encoder and decoder can use block B0' instead of block B0 as the merge candidate block for the lower edge prediction unit, and block B1' instead of block B1 as the merge candidate block for the lower edge prediction unit.

[0188] Although the above-described embodiment is limited to the case where the partitioning mode of the current coding unit (and / or prediction unit) is 2N×N, the present invention is not limited thereto. That is, the merge candidate derivation method described above can be applied in a similar manner to cases where the partitioning mode of the current coding unit is N×2N, N×N, 2N×nU, 2N×nD, nL×2N, or nR×2N.

[0189] On the other hand, the encoder and decoder can also enable parallel motion prediction by deriving and using a common merge candidate and / or a common merge candidate list for multiple prediction units in which parallel motion prediction is performed. The parallel motion prediction scheme based on the common merge candidate and / or common merge candidate list can be applied separately and independently from the embodiments in Figures 10 and / or 11 described above, but it can also be applied together with the encoder / decoder in combination with the embodiments in Figures 10 and / or 11. Hereinafter, a merge candidate used in common for multiple prediction units will be referred to as a "common merge candidate," and a merge candidate list used in common for multiple prediction units will be referred to as a "single merge candidate list."

[0190] In this case, the unit from which the common merge candidate and / or single merge candidate list is derived may be a predetermined unit. Here, the predetermined unit may be defined by a number, or it may be a CU, MER, and / or LCU unit. Alternatively, the unit from which the common merge candidate and / or single merge candidate list is derived may be determined by an encoder. In this case, the encoder can encode information about the unit and transmit it to the decoder. In this case, the decoder can determine the unit from which the common merge candidate and / or single merge candidate list is derived based on the transmitted information. Hereinafter, in this specification, the unit from which the common merge candidate and / or single merge candidate list is derived as described above will be referred to as the "merging candidate shared unit".

[0191] For example, if the merge candidate sharing unit is a CU, all prediction units within a single CU (prediction units with merge mode and / or skip mode) can share a common merge candidate list for the CU and / or a single merge candidate list for the CU. In this case, the single merge candidate list may be identical to the merge candidate list held by prediction units belonging to a CU when the division mode of the CU (and / or PUs belonging to the CU) is 2N × 2N. As another example, if the merge candidate sharing unit is an LCU, all prediction units within a single LCU (prediction units with merge mode and / or skip mode) can share a common merge candidate list for the LCU and / or a single merge candidate list for the LCU. As yet another example, if the merge candidate sharing unit is a MER, all prediction units within a single MER (prediction units with merge mode and / or skip mode) can share a common merge candidate list for the MER and / or a single merge candidate list for the MER.

[0192] If all prediction units within a single merge candidate sharing unit share a common merge candidate and / or a single merge candidate list, some coding loss may occur. Therefore, the encoder and decoder may selectively determine the merge candidate derivation scheme and / or merge candidate list derivation scheme based on the merge candidate sharing flag. Here, the merge candidate sharing flag corresponds to a flag that indicates whether a single merge candidate list is derived and used for all prediction units within the merge candidate sharing unit, or whether a separate merge candidate list is derived and used for each prediction unit. The merge candidate sharing flag can be represented, for example, by parallel_merge_cand_flag, parallel_merge_derivation_flag, or singleMCLFlag.

[0193] For example, if the merge candidate sharing flag is valued at 1, the flag indicates that all prediction units within the merge candidate sharing unit share a common merge candidate and / or a single merge candidate list. In other words, in this case, the flag indicates that the positions of the merge candidates (spatial merge candidates and / or temporal merge candidates) are the same for all prediction units within the merge candidate sharing unit. If the merge candidate sharing flag is valued at 0, the flag indicates that a separate merge candidate list is derived and used for each prediction unit.

[0194] The merge candidate shared flag described above is, in one embodiment, a flag encoded by the encoder and transmitted to the decoder. In this case, the merge candidate shared flag can be defined in the SPS, PPS, adaptation parameter set (APS), or slice header. That is, the merge candidate shared flag can be included in the SPS, PPS, APS, or slice header on the bitstream and transmitted from the encoder to the decoder. In this case, the decoder can determine the merge candidate derivation scheme and / or merge candidate list derivation scheme based on the transmitted flag.

[0195] In another embodiment, the value assigned to the merge candidate shared flag can be derived in the same manner in both the encoder and the decoder. In this case, the encoder does not transmit information about the merge candidate shared flag to the decoder.

[0196] As an example, let's assume the merge candidate sharing unit is a CU. In this case, the value assigned to the merge candidate sharing flag can be determined based on the size of the MER and / or the size of the current CU. For example, the encoder and decoder can assign a value of 1 to the merge candidate sharing flag only if the size of the MER, i.e., the parallel processing level, is greater than 4x4 and the size of the current coding unit is 8x8. Here, when the value of the merge candidate sharing flag is 1, the flag indicates that all prediction units within the merge candidate sharing unit share a common merge candidate and / or a single merge candidate list. That is, the encoder and decoder allow all prediction units within the current coding unit to share a common merge candidate and / or a single merge candidate list only if the parallel processing level is greater than 4x4 and the size of the current coding unit is 8x8. In this case, if the parallel processing level is 4x4 or the size of the current coding unit is not 8x8, the value of 0 is assigned to the merge candidate sharing flag. Here, when the value of the merge candidate sharing flag is 0, the flag indicates that a separate merge candidate list is derived and used for each prediction unit.

[0197] The following describes an example of a method for deriving common merge candidates for prediction units within a merge candidate sharing unit.

[0198] Figure 13 schematically illustrates one embodiment of a method for deriving common merge candidates for prediction units within a merge candidate sharing unit.

[0199] In Figure 13, numbers 1310 to 1330 represent a single identical coding unit, and the partitioning mode of the coding unit (and / or prediction unit) corresponds to N × 2N. PartIdx represents the partitioning index, PU0 represents a prediction unit with a partitioning index value of 0, and PU1 represents a prediction unit with a partitioning index value of 1.

[0200] On the other hand, in the embodiment shown in Figure 13, for the sake of explanation, we assume that the merge candidate shared unit is CU. In this case, each coding unit shown in Figure 13 corresponds to a merge candidate shared unit. The size of the merge candidate shared unit may be the same as or different from the size of the MER, i.e., the parallel processing unit.

[0201] Figure 13, 1310 shows the merge candidate for the left prediction unit with a partition index of 0. Figure 13, 1320 shows the merge candidate for the right prediction unit with a partition index of 1. Referring to Figures 1310 and 1320, each prediction unit within a coding unit (a shared merge candidate unit) can have its own independent list of merge candidates.

[0202] In this case, block A1 of 1320 in Figure 13 belongs to the right-side prediction unit. Therefore, since the right-side prediction unit uses motion information belonging to the left-side prediction unit, motion prediction cannot be performed simultaneously for both the left-side and right-side prediction units. At this time, the encoder and decoder can either process block A1 as unavailable to enable parallel motion prediction, or they can enable parallel motion prediction by using the motion information of blocks with available motion information as a common merge candidate.

[0203] Referring to 1330 in Figure 13, prediction units within a coding unit (a unit that shares merge candidates) have a common merge candidate (and / or a common list of merge candidates). That is, in 1330 in Figure 13, all prediction units within a coding unit can share a common merge candidate (and / or a single list of merge candidates).

[0204] Here, as an example, the common merge candidate may be the same as the merge candidate derived when the division mode of the current coding unit 1330 is 2N × 2N. Specifically, the encoder and decoder can use the movement information of block A0 located closest to the lower left corner outside the coding unit 1330, block A1 located at the bottom of the blocks adjacent to the left side of the coding unit 1330, block B0 located closest to the upper right corner outside the coding unit 1330, block B1 located at the rightmost of the blocks adjacent to the top edge of the coding unit 1330, and block B2 located closest to the upper left corner outside the coding unit 1330 as a common merge candidate for the left prediction unit PU0 and the right prediction unit PU1.

[0205] In the embodiment 1330 described above, all prediction units within a single coding unit (merging candidate sharing unit) can share a common merge candidate (a merge candidate derived when the division mode of the current coding unit 1330 is 2N × 2N) and / or a single merge candidate list. That is, all prediction units within a coding unit (merging candidate sharing unit) can use the same merge candidate at the same location. Therefore, the common merge candidate derivation method described above can reduce the complexity of coding and facilitate parallel motion prediction.

[0206] The common merge candidate derivation method described above is merely one example, and the partitioning mode to which the common merge candidate derivation method is applied is not limited to N×2N. The common merge candidate derivation method described above can be applied in the same or similar manner when the partitioning mode of the current coding unit (and / or prediction unit) is 2N×2N mode, 2N×N mode, N×N mode, 2N×nU mode, 2N×nD mode, nL×2N mode, or nR×2N mode. That is, all prediction units within a single coding unit can share a common merge candidate and / or single merge candidate list regardless of the partitioning mode of the coding unit (and / or prediction unit). In this case, the encoder and decoder can use blocks at the same positions as the merge candidates used when the partitioning mode of the coding unit (and / or prediction unit) is 2N×2N as common merge candidates.

[0207] For example, even when the partitioning mode of the current coding unit (and / or prediction unit) is N×N mode, all prediction units within the current coding unit (prediction unit with partitioning index 0, prediction unit with partitioning index 1, prediction unit with partitioning index 2, and prediction unit with partitioning index 3) can share a common merge candidate and / or single merge candidate list. In this case, the movement information of a block located at the same position as a merge candidate block used when the partitioning mode of the current coding unit (and / or prediction unit) is 2N×2N can be derived as a common merge candidate.

[0208] In general, merge candidate blocks and / or merge candidates for prediction units can be identified by their relative position to the prediction unit. Therefore, a merge candidate for a single prediction unit can be determined based on the coordinates of the top-leftmost pixel within the prediction unit (e.g., (xP, yP)), the width of the prediction unit (e.g., nPbW), and the height of the prediction unit (e.g., nPbH).

[0209] However, when a common merge candidate and / or single merge candidate list is used, the common merge candidate is identical to the merge candidate derived when the partition mode of the coding unit (and / or prediction unit) is 2N × 2N, and can therefore be identified by its relative position to the coding unit. Thus, when a common merge candidate and / or single merge candidate list is used, the encoder and decoder can reset the coordinates of the top-leftmost pixel in the prediction unit to the coordinates of the top-leftmost pixel in the coding unit to which the prediction unit belongs (e.g., (xC, yC)). The encoder and decoder can also reset the width and height of the prediction unit to the width (e.g., nCS) and height (e.g., nCS) of the coding unit. In this case, the encoder and decoder determine the merge candidate of the prediction unit based on the reset values, thereby enabling the prediction unit to use the common merge candidate when predicting parallel motion.

[0210] On the other hand, as mentioned above, if all prediction units within a single merge candidate sharing unit share a common merge candidate and / or a single merge candidate list, a small coding loss may occur. Therefore, the encoder and decoder can selectively determine the merge candidate derivation scheme and / or merge candidate list derivation scheme based on the merge candidate sharing flag.

[0211] For example, if the merge candidate sharing flag is valued at 1, the flag indicates that all prediction units within the merge candidate sharing unit share a common merge candidate and / or a single merge candidate list. This corresponds to the common merge candidate derivation method shown at 1330 in Figure 13. If the merge candidate sharing flag is valued at 0, the flag indicates that a separate merge candidate list is derived and used for each prediction unit. This corresponds to the merge candidate derivation methods shown at 1310 and 1320 in Figure 13.

[0212] The specifics regarding the merge candidate sharing flag have been explained above, so they will be omitted here.

[0213] Figure 14 schematically illustrates another embodiment of the method for deriving common merge candidates for prediction units within a merge candidate shared unit.

[0214] Figures 1410 and 1430 in Figure 14 each represent a single LCU (and / or coded tree block). Since Figure 1430 in Figure 14 further represents the same LCU as Figure 1410 in Figure 14, identical components in Figures 1410 and 1430 are referred to by the same reference code.

[0215] On the other hand, in the embodiment shown in Figure 14, for the sake of explanation, we assume that one LCU is composed of four square MERs of the same size, and that the merge candidate shared unit for a prediction unit within the LCU is the same as the MER unit. In this case, the MER may have the same size as the coding unit, or it may have a different size, depending on the size of each coding unit that constitutes the coding tree block. In the embodiment shown in Figure 14, since the MER corresponds to the merge candidate shared unit, if the coding unit has the same size as the MER, the coding unit can also correspond to the merge candidate shared unit. For example, if the size of the MER is 8x8, and the size of the current coding unit is 8x8, then the current coding unit can also correspond to the merge candidate shared unit. The embodiment shown in Figure 14 is explained based on the case where the merge candidate shared unit is the MER unit, but the same or a similar method can be applied when the merge candidate shared unit is the coding unit.

[0216] Referring to 1410 in Figure 14, the current prediction unit 1415, which is subject to motion prediction, is included in one MER 1413. Hereafter, in the embodiment of Figure 14, the MER to which the current prediction unit 1415 belongs will be referred to as the current MER 1413. In 1410 of Figure 14, merge candidates 1421, 1423, 1425, 1427, and 1429 of the current prediction unit 1415 are shown.

[0217] Of the blocks 1421, 1423, 1425, 1427, and 1429 used as merge candidate blocks, blocks 1423, 1425, and 1427 belong to the current MER 1413 and are blocks belonging to the same MER as the current prediction unit 1415. Therefore, blocks 1423, 1425, and 1427 are blocks that have not been encoded / decoded during parallel motion prediction and are therefore not used for the parallel motion prediction of the current prediction unit 1415. In addition, motion information for blocks 1421 and 1429 may not be available during motion prediction of the current prediction unit 1415. This is because, due to the encoding / decoding procedure, the encoding and / or decoding of the blocks may not be completed. Therefore, when merge mode (and / or skip mode) motion prediction is performed for the current prediction unit, the merge candidate blocks mentioned above (blocks belonging to the same MER as the current prediction unit 1415 and / or blocks that have not been encoded / decoded during parallel motion prediction) are treated as unavailable.

[0218] Furthermore, as described above, the encoder and decoder enable parallel motion prediction by deriving and using a common merge candidate and / or single merge candidate list for multiple prediction units within a merge candidate shared unit.

[0219] Referring to 1430 in Figure 14, prediction units within a Merger Candidate Sharing Unit (MER) have a common merge candidate (and / or a single merge candidate list). That is, in 1430 in Figure 14, all prediction units within the MER can share a common merge candidate (e.g., blocks 1441, 1443, 1445, 1447, and 1449). In this case, the current prediction unit 1415 can use the common merge candidate instead of the merge candidates 1421, 1423, 1425, 1427, and 1429 shown in 1410 in Figure 14.

[0220] Here, as an example, the common merge candidate may be the same as the merge candidate derived when a coding unit (and / or prediction unit belonging to a coding unit) of the same size as the current MER1413 has a 2N × 2N partitioning mode. That is, the encoder and decoder can use a block located outside the current MER1413 as the common merge candidate, and the common merge candidate can be identified by its relative position to the current MER1413.

[0221] As one embodiment, the encoder and decoder can use the motion information of block 1441, which is located closest to the lower left corner outside the current MER 1413, block 1443, which is located at the bottom of the blocks adjacent to the left side of the current MER 1413, block 1449, which is located closest to the upper right corner outside the current MER 1413, block 1447, which is located on the rightmost of the blocks adjacent to the top edge of the current MER 1413, and block 1445, which is located closest to the upper left corner outside the current MER 1413, as merge candidates (common merge candidates) for the current prediction unit 1415. In this case, if there is a block that does not have usable motion information (for example, block 1449, which is located closest to the upper right corner outside the current MER 1413), the encoder and decoder will either treat that block as unavailable or not use it as a merge candidate block for the current prediction unit 1415. In another embodiment, the encoder and decoder may use block 1444, adjacent to the left of the current MER 1413, as a merge candidate block for the current prediction unit 1415, instead of block 1445, which is closest to the upper left corner outside the current MER 1413. In this case, block 1444 may be an intermediate block among the blocks adjacent to the left of the current MER 1413, and if there are two intermediate blocks, it may be the uppermost of the two blocks.

[0222] As shown in the 1430 embodiment in Figure 14, when a common merge candidate (and / or single merge candidate list) is used for all prediction units within a single merge candidate shared unit, blocks containing available motion information can be used as merge candidate blocks instead of blocks that would otherwise be treated as unavailable. Therefore, in such cases, encoding / decoding performance can be improved compared to when a common merge candidate (and / or single merge candidate list) is not used.

[0223] As described above, the encoder and decoder can use blocks located outside the MER to which the prediction unit belongs as merge candidate blocks for the prediction unit, instead of blocks located around the prediction unit (for example, the block closest to the lower left corner outside the prediction unit, the block at the bottom of the blocks adjacent to the left side of the prediction unit, the block closest to the upper right corner outside the prediction unit, the block at the right of the blocks adjacent to the top edge of the prediction unit, and the block closest to the upper left corner outside the prediction unit). Hereinafter, in this specification, merge candidates derived from blocks located outside the MER to which the prediction unit belongs will be referred to as MER merge candidates in order to replace merge candidates derived from blocks located around the prediction unit.

[0224] The embodiment in Figure 14 can also be considered an embodiment of the MER merge candidate derivation method. In the embodiment in Figure 14, all prediction units within a single merge candidate sharing unit can share a common merge candidate (and / or a single merge candidate list). Therefore, in Figure 14, all prediction units within a single MER (merger candidate sharing unit) can have the same MER merge candidate. The MER merge candidate can be derived as a common merge candidate for all prediction units within a single MER, as in the embodiment in Figure 14, or it can be derived separately for each prediction unit contained within a single MER. In this regard, embodiments of the MER merge candidate derivation method will be further described below.

[0225] Figure 15 is a schematic diagram illustrating an example of the MER merge candidate derivation method. Figures 1510 and 1520 in Figure 15 each represent a single MER.

[0226] Referring to 1510 in Figure 15, the current prediction unit 1515 included in the current MER 1510 can have five spatial merge candidates A0, A1, B0, B1, and B2. However, as explained in Figure 14, blocks corresponding to spatial merge candidates may not contain motion information available during parallel motion prediction, and are therefore treated as unavailable. In this case, spatial merge candidates A0, A1, B0, B1, and B2 can be replaced by MER merge candidates A0', A1', B0', B1', and B2' shown in 1510 of Figure 15, respectively. That is, the encoder and decoder can use MER merge candidates A0', A1', B0', B1', and B2' as merge candidates for the current prediction unit 1515. The positions of the MER merge candidates shown in 1510 of Figure 15 are substantially the same as in the embodiment in Figure 14, so a detailed explanation is omitted.

[0227] Referring to 1520 in Figure 15, the current prediction unit 1525 included in the current MER 1520 has five spatial merge candidates A0, A1, B0, B1, and B2, as shown in 1510 in Figure 15. In this case, the positions of merge candidates A0, A1, B0, and B1 are identified, i.e., represented by the following coordinates.

[0228] A0:(x-1,y+nPSH-1) A1: (x-1, y+nPSH) B0:(x+nPSW-1,y-1) B1:(x+nPSW,y-1) Here, (x,y) represents the coordinates of the top-leftmost pixel within the current prediction unit 1525, and these coordinates are determined relative to the top-leftmost position of the picture to which the current prediction unit 1525 belongs. nPSH represents the height of the current prediction unit 1525, and nPSW represents the width of the current prediction unit 1525.

[0229] On the other hand, as shown in Figure 15, block corresponding to a spatial merge candidate may not contain motion information available during parallel motion prediction, and is therefore treated as unavailable. In this case, spatial merge candidates A0, A1, B0, B1, and B2 can be replaced by MER merge candidates A0', A1', B0', B1', and B2' shown in Figure 15, respectively. That is, the encoder and decoder can use MER merge candidates A0', A1', B0', B1', and B2' as merge candidates for the current prediction unit 1515.

[0230] Here, MER merge candidate A0' is derived based on block A0' which is adjacent to the left of the current MER1520 and has the same horizontal position as block A0, and MER merge candidate A1' is derived based on block A1' which is adjacent to the left of the current MER1520 and has the same horizontal position as block A1. Similarly, MER merge candidate B1' is derived based on block B1' which is adjacent to the top of the current MER1520 and has the same vertical position as block B0, and MER merge candidate B0' is derived based on block B0' which is adjacent to the right of block B1'. At this time, the positions of MER merge candidates A0', A1', B0' and B1' are specified, i.e., represented by the following coordinates.

[0231] A0':(((x>>nMER)< <nMER)-1, y+nPSH-1) A1': (((x>>nMER)< <nMER)-1, y+nPSH) B0': (x+nPSW-1, ((y>>nMER)< <nMER)-1) B1': (x+nPSW, ((y>>nMER)< <nMER)-1) Here, nMER represents the logarithm of the MER size (width / height).

[0232] Furthermore, in 1520 of Figure 15, the encoder and decoder may treat merge candidate B2 as unavailable and not use it, or they may substitute it with MER merge candidate B2'. When MER merge candidate B2' is used as a merge candidate for the current prediction unit 1525, MER merge candidate B2' can be derived based on the left block 1531, which is adjacent to the left side of the current MER 1520 and has the same horizontal position as block B2, or the upper block 1533, which is adjacent to the upper end of the current MER 1520 and has the same vertical position as block B2. As an example, the encoder and decoder can check whether the left block 1531 is available or not. In this case, if the left block 1531 is available, the encoder and decoder can derive MER merge candidate B2' based on the left block 1531, and if the left block 1531 is unavailable, they can derive MER merge candidate B2' based on the upper block 1533.

[0233] In the embodiment of 1520 in Figure 15, compared to the embodiment of 1510 in Figure 15, blocks located closer to the current prediction unit 1520 can be used as merge candidate blocks, thereby improving coding efficiency.

[0234] On the other hand, once a MER merge candidate for the current prediction unit 1525 is derived, the encoder and decoder can generate a merge candidate list based on the derived MER merge candidate. At this time, multiple MER merge candidates can be added to and / or inserted into the merge candidate list in a predetermined order. Since MER merge candidates added to the merge candidate list earlier are assigned a smaller merge index, the amount of information transmitted from the encoder to the decoder can be reduced by preferentially adding MER merge candidates that are more likely to be used to derive the movement of the current prediction unit to the merge candidate list. For this reason, the encoder and decoder preferentially add MER merge candidates corresponding to blocks located closer to the current prediction unit 1520 to the merge candidate list.

[0235] The horizontal distance from the current prediction unit 1520 to the MER is represented by the distance from the top-leftmost pixel within the current prediction unit 1520 to the left boundary of the MER. Similarly, the vertical distance from the current prediction unit 1520 to the MER is represented by the distance from the top-leftmost pixel within the current prediction unit 1520 to the top boundary of the MER. Therefore, the horizontal and vertical distances from the current prediction unit 1520 to the MER can be expressed, for example, by the following equation 1.

[0236] (Formula 1) distX=x% nMER distY=y%nMER Here, distX represents the horizontal distance from the current prediction unit 1520 to the MER, and distY represents the horizontal distance from the current prediction unit 1520 to the MER. (x,y) represents the coordinates of the top-leftmost pixel within the current prediction unit 1520, and nMER represents the size of the MER.

[0237] For example, if the value of distX is less than the value of distY, the encoder and decoder add MER merge candidates A1' and A0' to the merge candidate list before B1' and B0', respectively, because the block adjacent to the left of the MER is closer to the current prediction unit 1520 than the block adjacent to the top of the MER. In one embodiment, when the value of distX is less than the value of distY, the MER merge candidates are added to the merge candidate list in the order A1', A0', B1', B0'. Otherwise (when the value of distX is greater than or equal to the value of distY), the MER merge candidates are added to the merge candidate list in the order B1', B0', A1', A0'. In another embodiment, when the value of distX is less than the value of distY, the MER merge candidates are added to the merge candidate list in the order A1', B1', A0', B0'. Otherwise (when the value of distX is greater than or equal to the value of distY), the MER merge candidates are added to the merge candidate list in the order of B1', A1', B0', A0'.

[0238] Figure 16 schematically illustrates another embodiment of the MER merge candidate derivation method. 1610 in Figure 16 represents one MER.

[0239] Referring to Figure 16, a single MER1610 can contain multiple prediction units. Hereinafter, in the case of the embodiment shown in Figure 16, the pixel located in the upper left corner of a prediction unit will be referred to as the upper left pixel, the pixel located in the upper right corner of a prediction unit will be referred to as the upper right pixel, and the pixel located in the lower left corner of a prediction unit will be referred to as the lower left pixel. In the embodiment shown in Figure 16, four MER merge candidates can be derived for each of the multiple prediction units belonging to MER1610.

[0240] In Figure 16, the motion information of two blocks adjacent to the top edge of the MER and the motion information of two blocks adjacent to the left side of the MER can be used as MER merge candidates for a single prediction unit. Here, the two blocks adjacent to the top edge of the MER are the block containing a pixel located on the same vertical line as the top-left pixel of the prediction unit and the block containing a pixel located on the same vertical line as the top-right pixel of the prediction unit, respectively. Also, the two blocks adjacent to the left side of the MER are the block containing a pixel located on the same horizontal line as the top-left pixel of the prediction unit and the block containing a pixel located on the same horizontal line as the bottom-left pixel of the prediction unit, respectively.

[0241] Referring to Figure 16, the prediction unit PU0 can use the motion information of two blocks T0 and T1 adjacent to the upper end of the MER, and the motion information of two blocks L0 and L1 adjacent to the left side of the MER, as MER merge candidates. Here, block T0 is a block containing a pixel located on the same vertical line as the top-left pixel of the prediction unit PU0, and block T1 is a block containing a pixel located on the same vertical line as the top-right pixel of the prediction unit PU0. Also, block L0 is a block containing a pixel located on the same horizontal line as the top-left pixel of the prediction unit PU0, and block L1 is a block containing a pixel located on the same horizontal line as the bottom-left pixel of the prediction unit PU0.

[0242] Furthermore, referring to Figure 16, the prediction unit PU1 can use the motion information of two blocks T2 and T3 adjacent to the upper end of the MER, and the motion information of two blocks L2 and L3 adjacent to the left side of the MER, as MER merge candidates. Here, block T2 is a block containing a pixel located on the same vertical line as the upper-left pixel of the prediction unit PU1, and block T3 is a block containing a pixel located on the same vertical line as the upper-right pixel of the prediction unit PU1. Also, block L2 is a block containing a pixel located on the same horizontal line as the upper-left pixel of the prediction unit PU1, and block L3 is a block containing a pixel located on the same horizontal line as the lower-left pixel of the prediction unit PU1.

[0243] Figure 17 schematically illustrates yet another embodiment of the MER merge candidate derivation method. 1710 in Figure 17 represents one MER.

[0244] Referring to Figure 17, a single MER1710 can contain multiple prediction units. Hereinafter, in the example shown in Figure 17, the pixel located in the upper left corner of a prediction unit will be referred to as the upper left pixel, the pixel located in the upper right corner of a prediction unit will be referred to as the upper right pixel, and the pixel located in the lower left corner of a prediction unit will be referred to as the lower left pixel. In the example shown in Figure 17, as in the example shown in Figure 16, four MER merge candidates can be derived for each of the multiple prediction units belonging to MER1710.

[0245] In Figure 17, the motion information of two blocks adjacent to the top edge of the MER (where each block is the block closest to the top-left corner outside the MER or the block closest to the top-right corner outside the MER; the same applies hereafter) and the motion information of two blocks adjacent to the left side of the MER (where each block is the block closest to the top-left corner outside the MER or the block closest to the bottom-left corner outside the MER; the same applies hereafter) can be used as MER merge candidates for a single prediction unit. Here, the two blocks adjacent to the top edge of the MER are, respectively, a block containing a pixel located on the same vertical line as the pixel adjacent to the left of the top-left pixel (a pixel in the prediction unit), and a block containing a pixel located on the same vertical line as the pixel adjacent to the right of the top-right pixel (a pixel in the prediction unit). Also, the two blocks adjacent to the left side of the MER are, respectively, a block containing a pixel located on the same horizontal line as the pixel adjacent to the top edge of the top-left pixel (a pixel in the prediction unit), and a block containing a pixel located on the same horizontal line as the pixel adjacent to the bottom edge of the bottom-left pixel (a pixel in the prediction unit).

[0246] Referring to Figure 17, the prediction unit PU0 can use the motion information of two blocks T0 and T1 adjacent to the top edge of the MER, and the motion information of two blocks L0 and L1 adjacent to the left side of the MER, as MER merge candidates. Here, block T0 is a block containing a pixel located on the same vertical line as the pixel adjacent to the left of the top-left pixel (a pixel in the prediction unit PU0). Block T1 is a block containing a pixel located on the same vertical line as the pixel adjacent to the right of the top-right pixel (a pixel in the prediction unit PU0). Block L0 is a block containing a pixel located on the same horizontal line as the pixel adjacent to the top edge of the top-left pixel (a pixel in the prediction unit PU0). And block L1 is a block containing a pixel located on the same horizontal line as the pixel adjacent to the bottom edge of the bottom-left pixel (a pixel in the prediction unit PU0).

[0247] Figure 18 schematically illustrates another example of the MER merge candidate derivation method. 1810 in Figure 18 represents one MER.

[0248] Referring to Figure 18, a single MER1810 can contain multiple prediction units. Hereafter, in the example shown in Figure 18 only, the pixel located in the upper left corner of a prediction unit will be referred to as the upper left pixel. In the example shown in Figure 18, two MER merge candidates can be derived for each of the multiple prediction units belonging to MER1810.

[0249] In the embodiment shown in Figure 18, motion information from one block adjacent to the top edge of the MER and motion information from one block adjacent to the left side of the MER can be used as MER merge candidates for a single prediction unit. Here, the block adjacent to the top edge of the MER is a block containing a pixel located on the same vertical line as the top-left pixel of the prediction unit. The block adjacent to the left side of the MER is a block containing a pixel located on the same horizontal line as the top-left pixel of the prediction unit.

[0250] Referring to Figure 18, the prediction unit PU0 can use the motion information of one block T adjacent to the upper end of the MER and the motion information of one block L adjacent to the left side of the MER as MER merge candidates. Here, block T is a block containing a pixel located on the same vertical line as the top-left pixel of the prediction unit PU0. Block L is a block containing a pixel located on the same horizontal line as the top-left pixel of the prediction unit PU0.

[0251] Figure 19 schematically illustrates yet another embodiment of the MER merge candidate derivation method. 1910 in Figure 19 shows one MER.

[0252] Referring to Figure 19, a single MER1910 can contain multiple prediction units. Hereinafter, in the example shown in Figure 19, the pixel located in the upper right corner of a prediction unit will be referred to as the upper right pixel, and the pixel located in the lower left corner of a prediction unit will be referred to as the lower left pixel. In the example shown in Figure 19, as in the example shown in Figure 18, two MER merge candidates can be derived for each of the multiple prediction units belonging to MER1910.

[0253] In the embodiment shown in Figure 19, motion information from one block adjacent to the top edge of the MER and motion information from one block adjacent to the left side of the MER can be used as MER merge candidates for a single prediction unit. Here, the block adjacent to the top edge of the MER is a block containing a pixel located on the same vertical line as the upper right pixel of the prediction unit. The block adjacent to the left side of the MER is a block containing a pixel located on the same horizontal line as the lower left pixel of the prediction unit.

[0254] Referring to Figure 19, the prediction unit PU0 can use the motion information of one block T adjacent to the upper end of the MER and the motion information of one block L adjacent to the left side of the MER as MER merge candidates. Here, block T is a block containing a pixel located on the same vertical line as the upper right pixel of the prediction unit PU0. Block L is a block containing a pixel located on the same horizontal line as the lower left pixel of the prediction unit PU0.

[0255] Figure 20 schematically illustrates yet another example of the MER merge candidate derivation method. In Figure 20, 2010 represents one MER.

[0256] Referring to Figure 20, a single MER2010 can contain multiple prediction units. Hereinafter, in the example shown in Figure 20, the pixel located in the upper left corner of a prediction unit will be referred to as the upper left pixel, the pixel located in the upper right corner of a prediction unit will be referred to as the upper right pixel, and the pixel located in the lower left corner of a prediction unit will be referred to as the lower left pixel. In the example shown in Figure 20, four MER merge candidates can be derived for each of the multiple prediction units belonging to MER2010.

[0257] In Figure 20, candidate MER merges for prediction units can be derived based on the position of the prediction unit within the MER. Specifically, candidate MER merges for prediction units can be derived based on the horizontal and vertical distances from the prediction unit to the MER. Here, the horizontal distance from the prediction unit to the MER refers to the distance from the top-left pixel of the prediction unit to the left boundary of the MER. The vertical distance from the prediction unit to the MER refers to the distance from the top-left pixel of the prediction unit to the top boundary of the MER.

[0258] For example, if the horizontal distance from the prediction unit to the MER is shorter than the vertical distance, the motion information of the four blocks adjacent to the left of the MER (where two of the four blocks are the block closest to the upper left corner outside the MER or the block closest to the lower left corner outside the MER; the same applies hereafter) can be used as candidates for MER merging for the prediction unit. The four blocks adjacent to the left of the MER are, respectively, a block containing a pixel located on the same horizontal line as the pixel adjacent to the top edge of the top-left pixel (a pixel in the prediction unit), a block containing a pixel located on the same horizontal line as the top-left pixel (a pixel in the prediction unit), a block containing a pixel located on the same horizontal line as the bottom-left pixel (a pixel in the prediction unit), and a block containing a pixel located on the same horizontal line as the pixel adjacent to the bottom edge of the bottom-left pixel (a pixel in the prediction unit).

[0259] Alternatively, the motion information of four blocks adjacent to the top edge of the MER (where two of the four blocks are the block closest to the top-left corner outside the MER or the block closest to the top-right corner outside the MER; the same applies hereafter) can be used as MER merge candidates for the prediction unit. Here, the four blocks adjacent to the top edge of the MER are, respectively, a block containing a pixel located on the same vertical line as the pixel adjacent to the left of the top-left pixel (a pixel in the prediction unit), a block containing a pixel located on the same vertical line as the top-left pixel (a pixel in the prediction unit), a block located on the same vertical line as the top-right pixel (a pixel in the prediction unit), and a block containing a pixel located on the same vertical line as the pixel adjacent to the right of the top-right pixel (a pixel in the prediction unit).

[0260] Referring to Figure 20, the vertical distance to the MER is much shorter for the prediction unit PU0 than the horizontal distance. Therefore, the prediction unit PU0 can use the motion information of the four blocks T0, T1, T2, and T3 adjacent to the top edge of the MER as MER merge candidates. Here, block T0 is a block containing a pixel located on the same vertical line as the pixel adjacent to the left of the top-left pixel (a pixel in the prediction unit PU0). Block T1 is a block containing a pixel located on the same vertical line as the top-left pixel (a pixel in the prediction unit PU0). Block T2 is a block containing a pixel located on the same vertical line as the top-right pixel (a pixel in the prediction unit PU0). And block T3 is a block containing a pixel located on the same vertical line as the pixel adjacent to the right of the top-right pixel (a pixel in the prediction unit PU0).

[0261] Furthermore, referring to Figure 20, the horizontal distance to the MER is much shorter for the prediction unit PU1 than the vertical distance. Therefore, the prediction unit PU1 can use the movement information of the four blocks L0, L1, L2, and L3 adjacent to the left of the MER as MER merge candidates. Here, block L0 is a block containing a pixel located on the same horizontal line as the pixel adjacent to the top edge of the top-left pixel (a pixel in the prediction unit PU1). Block L1 is a block containing a pixel located on the same horizontal line as the top-left pixel (a pixel in the prediction unit PU1). Block L2 is a block containing a pixel located on the same horizontal line as the bottom-left pixel (a pixel in the prediction unit PU1). And block L3 is a block containing a pixel located on the same vertical line as the pixel adjacent to the bottom edge of the bottom-left pixel (a pixel in the prediction unit PU1).

[0262] Figure 21 schematically illustrates yet another embodiment of the MER merge candidate derivation method. 2110 in Figure 21 represents one MER.

[0263] Referring to Figure 21, a single MER2110 can contain multiple prediction units. Hereinafter, in the case of the embodiment shown in Figure 21, the pixel located in the upper left corner of a prediction unit will be referred to as the upper left pixel, the pixel located in the upper right corner of a prediction unit will be referred to as the upper right pixel, and the pixel located in the lower left corner of a prediction unit will be referred to as the lower left pixel. In the embodiment shown in Figure 21, two MER merge candidates can be derived for each of the multiple prediction units belonging to the MER2110.

[0264] In FIG. 21, based on the position of the prediction unit in the MER, the MER merge candidates of the prediction unit can be derived. That is, the MER merge candidates of the prediction unit can be derived based on the horizontal distance and the vertical distance from the prediction unit to the MER. Here, the horizontal distance from the prediction unit to the MER means the distance from the upper left pixel of the prediction unit to the left boundary of the MER. Also, the vertical distance from the prediction unit to the MER means the distance from the upper left pixel of the prediction unit to the upper boundary of the MER.

[0265] As an example, when the horizontal distance from the prediction unit to the MER is closer than the vertical distance, the motion information of two blocks adjacent to the left side of the MER (here, the two blocks are respectively the block closest to the upper left corner outside the MER or the block closest to the lower left corner outside the MER. The same applies hereinafter.) can be used as the MER merge candidates of the prediction unit. The two blocks adjacent to the left side of the MER are respectively the block including pixels located on the same horizontal line as the upper left pixel of the prediction unit, and the block including pixels located on the same horizontal line as the lower left pixel of the prediction unit.

[0266] Alternatively, the motion information of two blocks adjacent to the upper end of the MER (here, the two blocks are respectively the block closest to the upper left corner outside the MER or the block closest to the upper right corner outside the MER. The same applies hereinafter.) can be used as the MER merge candidates of the prediction unit. Here, the two blocks adjacent to the upper end of the MER are respectively the block including pixels located on the same vertical line as the upper left pixel of the prediction unit, and the block including pixels located on the same vertical line as the upper right pixel of the prediction unit.

[0267] Referring to FIG. 21, for prediction unit PU0, the vertical distance to MER may be closer than the horizontal distance. Therefore, prediction unit PU0 can use the motion information of two blocks T0 and T1 adjacent to the upper end of MER as MER merge candidates. Here, block T0 is a block including pixels located on the same vertical line as the upper left pixel of prediction unit PU0. Also, block T1 is a block including pixels located on the same vertical line as the upper right pixel of prediction unit PU0.

[0268] Referring further to FIG. 21, for prediction unit PU1, the horizontal distance to MER may be closer than the vertical distance. Therefore, prediction unit PU1 can use the motion information of two blocks L0 and L1 adjacent to the left side of MER as MER merge candidates. Here, block L0 is a block including pixels located on the same horizontal line as the upper left pixel of prediction unit PU1. Also, block L1 is a block including pixels located on the same horizontal line as the lower left pixel of prediction unit PU1.

[0269] FIG. 22 is a diagram schematically showing another embodiment of the MER merge candidate derivation method. 2210 in FIG. 22 shows one MER.

[0270] Referring to FIG. 22, one MER 2210 can include a plurality of prediction units. Hereinafter, limited to the embodiment of FIG. 22, the pixel located at the uppermost right in the prediction unit is referred to as the upper right pixel, and the pixel located at the lowermost left in the prediction unit is referred to as the lower left pixel.

[0271] Furthermore, referring to Figure 22, the prediction unit PU0 can have five spatial merge candidates A0, A1, B0, B1, and B2. However, as mentioned above, spatial merge candidates may not be available during parallel motion prediction in merge mode and / or skip mode. For example, if a block used as a merge candidate is included in the same MER as the prediction unit PU0, the block will be one of the blocks that has not been coded / decoded during motion prediction and therefore cannot be used for parallel motion prediction of the prediction unit PU0. Also, due to the coding / decoding procedure, blocks used as merge candidates may not have been coded and / or decoded during parallel motion prediction of the prediction unit PU0.

[0272] On the other hand, in the embodiment shown in Figure 22, up to four MER merge candidates can be derived for the prediction unit PU0 belonging to MER2210. The four MER merge candidates are the motion information of two blocks T0 and T1 adjacent to the top edge of the MER (where one of the two blocks is the block closest to the upper right corner outside the MER; the same applies hereafter), and the motion information of two blocks L0 and L1 adjacent to the left side of the MER (where one of the two blocks is the block closest to the lower left corner outside the MER; the same applies hereafter). Here, the two blocks adjacent to the top edge of the MER are block T0, which is located on the same vertical line as the upper right pixel (a pixel in the prediction unit PU0), and block T1, which includes a pixel located on the same vertical line as the pixel adjacent to the right of the upper right pixel (a pixel in the prediction unit PU0). Furthermore, the two blocks adjacent to the left of MER are block L0, which is located on the same horizontal line as the bottom-left pixel (a pixel within prediction unit PU0), and block L1, which contains a pixel located on the same horizontal line as the pixel adjacent to the bottom edge of the bottom-left pixel (a pixel within prediction unit PU0).

[0273] In this case, the encoder and decoder derive corresponding MER merge candidates only for merge candidates A0, A1, B0, and B1 that are unavailable among the merge candidates possessed by prediction unit PU0. Since whether or not each spatial merge candidate possessed by a prediction unit within the MER is unavailable during parallel motion prediction is determined by the position of the prediction unit, it can also be considered that in this case, the MER merge candidate derived for prediction unit PU0 is determined based on the position of the prediction unit.

[0274] Referring to Figure 22, if merge candidate A1 of prediction unit PU0 is unavailable during parallel merge mode / parallel skip mode motion prediction, the motion information of block L0 can be used as a MER merge candidate for prediction unit PU0. Similarly, if merge candidate A0 of prediction unit PU0 is unavailable during parallel merge mode / parallel skip mode motion prediction, the motion information of block L1 can be used as a MER merge candidate for prediction unit PU0. Furthermore, if merge candidate B1 of prediction unit PU0 is unavailable during parallel merge mode / parallel skip mode motion prediction, the motion information of block T0 can be used as a MER merge candidate for prediction unit PU0, and if merge candidate B0 of prediction unit PU0 is unavailable during parallel merge mode / parallel skip mode motion prediction, the motion information of block T1 can be used as a MER merge candidate for prediction unit PU0.

[0275] Figure 23 schematically illustrates another example of the MER merge candidate derivation method. 2310 in Figure 23 represents one MER.

[0276] Referring to Figure 23, the prediction unit PU02320 included in MER2310 can have five spatial merge candidates A0, A1, B0, B1, and B2. Although not shown in Figure 23, as explained in Figure 7, the prediction unit PU02320 can also have temporal merge candidates.

[0277] As illustrated in Figure 22, spatial merge candidates for any prediction unit within a MER may not be available during parallel motion prediction in merge mode and / or skip mode. In the embodiment shown in Figure 23, since all the blocks used to derive the spatial merge candidate for prediction unit PU02320 are contained within the same MER as prediction unit PU02320, the spatial merge candidate for prediction unit PU02320 is treated as unavailable and is not included in the merge candidate list.

[0278] On the other hand, as mentioned above, the number of merge candidates that make up the merge candidate list can be limited to a predetermined fixed number. In the embodiment shown in Figure 23, for the sake of explanation, we assume that the number of merge candidates that make up the merge candidate list is limited to 5. In this case, the number of available merge candidates (spatial merge candidates and temporal merge candidates) derived for the prediction unit may be less than 5 for the reasons mentioned above, and the merge candidate list may not be completely filled even if both the available spatial merge candidates and temporal merge candidates are added to the merge candidate list. In this case, after the temporal merge candidate is added to the merge candidate list last, the encoder and decoder can derive a MER merge candidate and insert it into the merge candidate list in a predetermined procedure so that the number of merge candidates that make up the merge candidate list becomes 5. That is, the encoder and decoder can add or insert MER merge candidates into the merge candidate list until the number of merge candidates that make up the merge candidate list becomes 5.

[0279] Referring to Figure 23, the motion information of blocks L0, L1, T0, and T1 can be used as MER merge candidates to be added to the merge candidate list of the prediction unit PU02320. Here, block L0 is the uppermost block among the blocks adjacent to the left side of the MER, and block L1 is the lowermost block among the blocks adjacent to the left side of the MER. Also, block T0 is the leftmost block among the blocks adjacent to the top edge of the MER, and block T1 is the rightmost block among the blocks adjacent to the top edge of the MER.

[0280] The number of MER merge candidates added to the merge candidate list to ensure that the number of merge candidates constituting the merge candidate list is five may be changed depending on the position of the prediction unit, etc. Therefore, the order in which the above-mentioned MER merge candidates are added to the merge candidate list may be predetermined. In one embodiment, the encoder and decoder can add MER merge candidates to the merge candidate list in the order of MER merge candidate corresponding to block L1, MER merge candidate corresponding to block T1, MER merge candidate corresponding to block L0, and MER merge candidate corresponding to block T0.

[0281] Figure 24 schematically illustrates yet another example of the MER merge candidate derivation method. 2410 in Figure 24 represents one MER.

[0282] Referring to Figure 24, the prediction unit PU02420 included in MER2410 can have five spatial merge candidates A0, A1, B0, B1, and B2. Although not shown in Figure 24, as explained in Figure 7, the prediction unit PU02420 can also have temporal merge candidates. However, as explained in Figure 23, spatial merge candidates for any prediction unit within the MER are treated as unavailable during parallel motion prediction in merge mode and / or skip mode and are not included in the merge candidate list.

[0283] In this case, the encoder and decoder can derive MER merge candidates in the same manner as in the embodiment of Figure 23 and add them to the merge candidate list in a predetermined order. For example, if the number of merge candidates constituting the merge candidate list is limited to 5, the encoder and decoder can add or insert MER merge candidates to the merge candidate list until the number of merge candidates constituting the merge candidate list reaches 5.

[0284] Referring to Figure 24, the motion information of blocks L1 and T1 can be used as MER merge candidates to be added to the merge candidate list of the prediction unit PU02420. Here, block L1 is the lowest block among the blocks adjacent to the left side of the MER, and block T1 is the rightmost block among the blocks adjacent to the top end of the MER.

[0285] Furthermore, as explained in Figure 23, the number of MER merge candidates added to the merge candidate list may vary depending on the position of the prediction unit, etc. Therefore, in the embodiment shown in Figure 24, the order in which MER merge candidates are added to the merge candidate list may be predetermined. In one embodiment, the encoder and decoder can add MER merge candidates to the merge candidate list in the order of MER merge candidates corresponding to block L1, then MER merge candidates corresponding to block T1.

[0286] On the other hand, as in the embodiments shown in Figures 13 to 24 above, if common merge candidates and / or MER merge candidates are derived for a single prediction unit, the derived common merge candidates and / or MER merge candidates can be added to or inserted into the merge candidate list of the prediction unit. In the embodiments described below, for the sake of explanation, common merge candidates and MER merge candidates will be collectively referred to as parallel merge candidates.

[0287] When parallel merge candidates are not applied, the spatial merge candidates of the prediction unit can be derived from the blocks adjacent to the prediction unit and the blocks located closest to the outer corners of the current block, as described in FIG. 7. Also, the temporal merge candidates of the prediction unit can be derived from the blocks at the same position included in the reference picture. Hereinafter, when parallel merge candidates are not applied as in the embodiment of FIG. 7, the merge candidates used for the prediction unit are called PU merge candidates.

[0288] As described above, among the spatial candidates corresponding to the PU merge candidates of one prediction unit, there may be merge candidates included in the same MER as the prediction unit. At this time, the merge candidates included in the same MER as the prediction unit may not include motion information available during parallel motion prediction. Therefore, the number of available PU merge candidates derived for the prediction unit may be less than the number of merge candidates required to construct the merge candidate list. Here, the number of merge candidates required to construct the merge candidate list may be a predetermined value. For example, the number of merge candidates constituting the merge candidate list may be 5.

[0289] In this case, the encoder and decoder can additionally insert the parallel merge candidates into the merge candidate list in a predetermined order. At this time, the parallel merge candidates additionally inserted into the merge candidate list are located after the available PU merge candidates in the merge candidate list. That is, the merge candidates can be inserted into the merge candidate list in the order of PU merge candidates, parallel merge candidates.

[0290] For example, suppose a PU merge candidate like 720 in Figure 7 is applied to the current prediction unit. In this case, the encoder and decoder can use the following as PU merge candidates for the current prediction unit: block A0, which is located closest to the lower left corner outside the current prediction unit; block A1, which is located at the bottom of the blocks adjacent to the left side of the current prediction unit; block B0, which is located closest to the upper right corner outside the current prediction unit; block B1, which is located at the rightmost of the blocks adjacent to the top edge of the current prediction unit; block B2, which is located closest to the upper left corner outside the current prediction unit; and the movement information of block COL, which is located at the same position. In this case, as an example, PU merge candidates can be added to and / or inserted into the merge candidate list in the order of A1, B1, B0, A0, B2, COL.

[0291] However, if the current prediction unit is located inside the MER, spatial merge candidates A1, B1, B0, A0, B2 that correspond to PU merge candidates may not be available when performing parallel motion prediction in merge mode and / or skip mode. In this case, only the temporal merge candidate COL that corresponds to the PU merge candidate is added to the merge candidate list.

[0292] In this case, the encoder and decoder can insert parallel merge candidates after the PU merge candidates added to the merge candidate list. For example, let the parallel merge candidates derived for the current prediction unit be A1', B1', B0', A0', and B2', respectively. In this case, the temporal merge candidates and parallel merge candidates corresponding to the PU merge candidates can be added to and / or inserted into the merge candidate list in the order COL, A1', B1', B0', A0', and B2'. In this case, the encoder and decoder can add parallel merge candidates until the number of merge candidates constituting the merge candidate list reaches the maximum number (e.g., 5).

[0293] On the other hand, even if all available PU merge candidates and available parallel merge candidates are added to the merge candidate list, the merge candidate list may not be completely filled. In such cases, the encoder and decoder can derive new merge candidates based on the merge candidates already added to the merge candidate list and add them to the list. In this case, the encoder can use not only PU merge candidates but also parallel merge candidates to derive new merge candidates.

[0294] New merge candidates derived based on merge candidates already added to the merge candidate list include combined bi-predictive candidates (CB), non-scaled bi-predictive candidates (NB), and / or zero motion candidates (Zero). Here, CB can be derived based on two merge candidates already added to the merge candidate list. For example, the L0 motion information of CB can be derived based on one of the two merge candidates, and the L1 motion information of CB can be derived based on the other of the two merge candidates. In other words, CB can be derived by combining the motion information of the two merge candidates. The L0 and L1 motion information of NB can be derived through predetermined conditions and operations based on one of the merge candidates already added to the merge candidate list. Zero refers to motion information that includes the zero vector (0,0).

[0295] Newly derived merge candidates CB, NB, and Zero, which are added to the merge candidate list, can be positioned after the available PU merge candidates and available parallel merge candidates within the merge candidate list. That is, merge candidates can be inserted into the merge candidate list in the order of PU merge candidates, parallel merge candidates, and CB, NB, and Zero derived based on the PU and parallel merge candidates. For example, assuming that three CBs (CB0, CB1, CB2), one NB (NB0), and one Zero are derived for one prediction unit, the merge candidate list can be added to and / or inserted in the order of COL, A1', B1', B0', A0', B2', CB0, CB1, CB2, NB0, and Zero. In this case, the encoder and decoder can add parallel merge candidates until the number of merge candidates constituting the merge candidate list reaches the maximum number (e.g., 5).

[0296] In the embodiments described above, the method is explained based on a flowchart as a series of steps or blocks, but the present invention is not limited to the order of the steps, and any step may occur in a different order or simultaneously with other steps than those described above. Furthermore, those skilled in the art will understand that the steps shown in the flowchart are not exclusive, and other steps may be included, or one or more steps in the flowchart may be removed without affecting the scope of the present invention.

[0297] The embodiments described above include examples of various modes. It is not possible to describe all possible combinations to demonstrate these various modes, but a person with ordinary skill in the art will recognize that other combinations are possible. Therefore, the present invention includes all other substitutions, modifications, and changes that fall within the scope of the following claims.

Claims

1. A video decoding method performed by a decoding device, The steps include receiving information about the parallel merge level, which indicates the size of the parallel merge unit region, and merge index information, A step to obtain merge flag information indicating whether the merge mode is applied to the current block, The steps include: deriving a spatial merge candidate for the current block based on the merge flag information indicating that the merge mode is applied to the current block; The steps include: constructing a merge candidate list that includes the spatial merge candidate for the current block; The steps include: deriving the movement information of the current block based on one of the spatial merge candidates indicated by the merge index information within the merge candidate list; The step of deriving a predicted sample of the current block based on the derived motion information is included, The size of the parallel merge unit region is derived based on the information relating to the parallel merge level, The aforementioned current block belongs to the aforementioned parallel merge unit region, The aforementioned block relates to a PU (prediction unit), and the PU is one of the PUs separated from a CU (coding unit). The PU has a size smaller than the size of the parallel merge unit region and is located within the parallel merge unit region. The aforementioned spatial merge candidate is identical to the 2N × 2N PU spatial merge candidate having the same size as the parallel merge unit region. The spatial merge candidates for the 2N × 2N PU having the same size as the parallel merge unit region are derived from the lower left corner surrounding block, the left side surrounding block, the upper right corner surrounding block, the upper side surrounding block, and the upper left corner surrounding block of the parallel merge unit region. The information relating to the parallel merge level is received through a picture parameter set, in a manner.

2. A video encoding method performed by an encoding device, The steps include: deriving a spatial merge candidate for the current block based on the merge flag information indicating that the merge mode is applied to the current block; The steps include: configuring a merge candidate that includes the spatial merge candidate for the current block; The steps include selecting a candidate from the merge candidate list, The steps include generating merge index information that indicates the selected merge candidate from the merge candidate list, The steps include: deriving the parallel merge level, which indicates the size of the parallel merge unit region; The steps include generating information regarding the parallel merge level, The steps include encoding video information including the merge flag information, the merge index information, and the information relating to the parallel merge level, The aforementioned current block belongs to the aforementioned parallel merge unit region, The aforementioned block relates to a PU (prediction unit), and the PU is one of the PUs separated from a CU (coding unit). The PU has a size smaller than the size of the parallel merge unit region and is located within the parallel merge unit region. The aforementioned spatial merge candidate is identical to the 2N × 2N PU spatial merge candidate having the same size as the parallel merge unit region. The spatial merge candidates for the 2N × 2N PU having the same size as the parallel merge unit region are derived from the lower left corner surrounding block, the left side surrounding block, the upper right corner surrounding block, the upper side surrounding block, and the upper left corner surrounding block of the parallel merge unit region. The information relating to the parallel merge level is signaled through a picture parameter set, in a manner.

3. A method for transmitting video data, A step of generating a bitstream relating to the video, wherein the bitstream is: The steps include: deriving a spatial merge candidate for the current block based on the merge flag information indicating that the merge mode is applied to the current block; The steps include: configuring a merge candidate that includes the spatial merge candidate for the current block; The steps include selecting a candidate from the merge candidate list, The steps include generating merge index information that indicates the selected merge candidate from the merge candidate list, The steps include: deriving the parallel merge level, which indicates the size of the parallel merge unit region; The steps include generating information regarding the parallel merge level, A step of encoding video information including the merge flag information, the merge index information, and the information relating to the parallel merge level, which is generated based on the step of The step of transmitting the data, which includes the bitstream, The aforementioned current block belongs to the aforementioned parallel merge unit region, The aforementioned block relates to a PU (prediction unit), and the PU is one of the PUs separated from a CU (coding unit). The PU has a size smaller than the size of the parallel merge unit region and is located within the parallel merge unit region. The aforementioned spatial merge candidate is identical to the 2N × 2N PU spatial merge candidate having the same size as the parallel merge unit region. The spatial merge candidates for the 2N × 2N PU having the same size as the parallel merge unit region are derived from the lower left corner surrounding block, the left side surrounding block, the upper right corner surrounding block, the upper side surrounding block, and the upper left corner surrounding block of the parallel merge unit region. The information relating to the parallel merge level is signaled through a picture parameter set, in a manner.

Images