Merge candidate derivation device, video decoding device, and video encoding device

Abstract

To solve a problem in which, in merge prediction, merge candidates are derived from motion vectors of spatially non-adjacent blocks of a target block and temporally adjacent blocks (colocated blocks), when there are two or more merge candidates with the same motion information, pruning is common, but extensive pruning reduces coding efficiency and increases processing and memory bandwidth.SOLUTION: When a NASMVP merging candidate for a target block is derived, pruning to check whether motion vectors are close is restricted in non-adjacent blocks composed of multiple groups.SELECTED DRAWING: Figure 17

Description

Technical Field

[0001] Embodiments of the present invention relate to an image decoding apparatus and an image encoding apparatus.

Background Art

[0002] In order to efficiently transmit or record an image, an image encoding apparatus that generates encoded data by encoding an image, and an image decoding apparatus that generates a decoded image by decoding the encoded data are used.

[0003] Specific image encoding methods include, for example, H.264 / AVC and HEVC (High-Efficiency Video Coding) methods and the like.

[0004] In such an image encoding method, an image (picture) constituting an image is managed by a hierarchical structure composed of a slice obtained by dividing the image, a coding tree unit (CTU: Coding Tree Unit) obtained by dividing the slice, a coding unit (sometimes called a Coding Unit: CU) obtained by dividing the coding tree unit, and a transform unit (TU: Transform Unit) obtained by dividing the coding unit, and is encoded / decoded for each CU.

[0005] Also, in such an image encoding method, usually, a prediction image is generated based on a local decoded image obtained by encoding / decoding an input image, and a prediction error (sometimes called a "difference image" or "residual image") obtained by subtracting the prediction image from the input image (original image) is encoded. Examples of the method for generating the prediction image include inter-picture prediction (inter prediction) and intra-picture prediction (intra prediction).

[0006] In addition, Non-Patent Document 1 can be cited as a technology for recent video encoding and decoding. Non-Patent Document 2 discloses a technique (Non-adjacent spatial candidate Motion Vector Prediction) for deriving motion vector candidates using motion information of non-adjacent blocks of a target block. is disclosed.

Prior Art Documents

Non-Patent Documents

[0007]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0008] However, in merge prediction for deriving merge candidates from motion vectors of spatially non-adjacent blocks of a target block and temporally adjacent blocks (collocated blocks), it is confirmed whether the motion information of the merge candidates is the same. When there are two or more merge candidates with the same motion information, pruning processing is generally performed. However, there is a problem that the encoding efficiency decreases due to a large amount of pruning processing, and the processing amount and memory bandwidth increase.

Means for Solving the Problems

[0009] A merge candidate derivation device according to one aspect of the present invention is a merge candidate derivation device that derives a merge candidate for a target block based on motion vectors of spatially adjacent blocks and temporally adjacent blocks of the target block. The merge candidate derivation device includes a NASMVP merge candidate derivation unit that derives a merge candidate using motion vectors of non-adjacent blocks. The NASMVP merge candidate derivation unit derives one merge candidate within each of a plurality of groups of non-adjacent blocks, namely the first, second, ···, Nth groups, and sets each derived NASMVP merge candidate in a merge candidate list. The NASMVP merge candidate derivation unit derives one merge candidate using pruning to check whether motion vectors are close within each group, and when setting each NASMVP merge candidate in the merge candidate list, sets it in the merge candidate list without using pruning.

Advantages of the Invention

[0010] According to one aspect of the present invention, the encoding efficiency can be increased with a small processing amount.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Embodiments for Carrying Out the Invention

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

[0013] Figure 1 is a schematic diagram showing the configuration of the image transmission system 1 according to the present embodiment.

[0014] The image transmission system 1 is a system that transmits an encoded stream obtained by encoding an image to be encoded, and decodes the transmitted encoded stream to display an image. The image transmission system 1 includes a moving image encoding device (image encoding device) 11, a network 21, a moving image decoding device (image decoding device) 31, and an image display device (image display device) 41.

[0015] An image T is input to the moving image encoding device 11.

[0016] The network 21 transmits the encoded stream Te generated by the moving image encoding device 11 to the moving image decoding device 31. The network 21 is the Internet, a wide area network (WAN: Wide Area Network), a local area network (LAN: Local Area Network), or a combination thereof. The network 21 is not necessarily limited to a bidirectional communication network, and may be a unidirectional communication network that transmits broadcast waves such as terrestrial digital broadcasting and satellite broadcasting. Further, the network 21 may be replaced by a storage medium that records the encoded stream Te such as a DVD (Digital Versatile Disc: registered trademark) or a BD (Blue-ray Disc: registered trademark).

[0017] The moving image decoding device 31 decodes each of the encoded streams Te transmitted by the network 21 and generates one or more decoded images Td obtained by decoding.

[0018] The image display device 41 displays all or part of one or more decoded images Td generated by the moving image decoding device 31. The image display device 41 includes, for example, a display device such as a liquid crystal display or an organic EL (Electro-luminescence) display. Examples of the form of the display include a stationary type, a mobile type, and an HMD. Further, when the moving image decoding device 31 has high processing power, an image with high image quality is displayed, and when it has only low processing power, an image that does not require high processing power and display ability is displayed.

[0019] <Operator> The operators used in this specification are described below.

[0020] >> is a right bit shift, << is a left bit shift, & is a bitwise AND, and | is a bitwise OR |= is an OR assignment operator, and || indicates a logical OR.

[0021] x?y:z is a ternary operator that takes y when x is true (non-zero) and z when x is false (0).

[0022] Clip3(a, b, c) is a function that clips c to a value between a and b, inclusive. If c < a, it returns a and if c > b, it returns b; otherwise, it returns c (where a <= b).

[0023] abs(a) is a function that returns the absolute value of a.

[0024] Int(a) is a function that returns the integer value of a.

[0025] floor(a) is a function that returns the smallest integer less than or equal to a.

[0026] ceil(a) is a function that returns the largest integer greater than or equal to a.

[0027] a / d represents the division of a by d (truncating the decimal part).

[0028] <Structure of Symbolized Stream Te> Prior to the detailed description of the moving image encoding device 11 and the moving image decoding device 31 according to the present embodiment, the data structure of the encoded stream Te generated by the moving image encoding device 11 and decoded by the moving image decoding device 31 will be described.

[0029] FIG. 4 is a diagram showing the hierarchical structure of data in the encoded stream Te. The encoded stream Te exemplarily includes a sequence and a plurality of pictures constituting the sequence. FIG. 4 shows, respectively, an encoded video sequence that defines the sequence SEQ, an encoded picture that defines the picture PICT, an encoded slice that defines the slice S, encoded slice data that defines the slice data, an encoded tree unit included in the encoded slice data, and an encoded unit included in the encoded tree unit.

[0030] (Encoded Video Sequence) In the encoded video sequence, a set of data referred to by the moving image decoding device 31 to decode the sequence SEQ to be processed is defined. As shown in the encoded video sequence of FIG. 4, the sequence SEQ includes a Video Parameter Set, a Sequence Parameter Set SPS, a Picture Parameter Set PPS, a picture PICT, and Supplemental Enhancement Information SEI.

[0031] The Video Parameter Set VPS defines a set of encoding parameters common to a plurality of images, a set of encoding parameters related to a plurality of layers included in the image, and a set of encoding parameters related to individual layers in an image composed of a plurality of layers. ​​​

[0032] In the sequence parameter set SPS, a set of encoding parameters that the moving image decoding device 31 refers to for decoding the target sequence is defined. For example, the width and height of a picture are defined. Note that there may be multiple SPSs. In that case, one of the multiple SPSs is selected from the PPS. In the present invention, the sps_nasmvp_enabled_flag shown in the SPS of FIG. 20 is notified. The sps_nasmvp_enabled_flag is a flag indicating whether the encoded data uses the NASMVP mode (Non - adjacent spatial candidate Motion Vector Prediction). When the sps_nasmvp_enabled_flag is 0, the NASMVP mode is not used. When the sps_nasmvp_enabled_flag is 1, the NASMVP mode may be used. Here, the NASMVP mode is a merge prediction mode that uses motion information (motion vectors, reference pictures) of spatially non - adjacent blocks in motion vector prediction for inter - prediction. Specifically, the NASMVP mode is a mode that derives prediction parameters of a target block from a plurality of predetermined motion information at positions not directly adjacent to the target block.

[0033]

[0034] In the picture parameter set PPS, a set of encoding parameters that the moving image decoding device 31 refers to for decoding each picture in the target sequence is defined. For example, it includes a reference value of the quantization width (pic_init_qp_minus26) used for decoding a picture, a flag (weighted_pred_flag) indicating the application of weighted prediction, and a scaling list (quantization matrix). Note that there may be multiple PPSs. In that case, one of the multiple PPSs is selected from each picture in the target sequence.

[0035] (Encoded Picture) In the coded picture, a set of data that the moving image decoding device 31 refers to in order to decode the picture PICT to be processed is defined. The picture PICT includes slices 0 to NS-1 as shown in the coded picture of FIG. 4 (NS is the total number of slices included in the picture PICT). That is, it includes slices 0 to NS-1 (NS is the total number of slices included in the picture PICT). .

[0036] Incidentally, hereinafter, when it is not necessary to distinguish each of slices 0 to NS-1, the subscript of the code may be omitted in the description. The same applies to the data included in the coded stream Te described below and other data with subscripts attached.

[0037] (Coded slice) In the coded slice, a set of data that the moving image decoding device 31 refers to in order to decode the slice S to be processed is defined. As shown in the coded slice of FIG. 4, the slice includes a slice header and slice data.

[0038] The slice header includes a group of coding parameters that the moving image decoding device 31 refers to in order to determine the decoding method of the target slice. The slice type specification information (slice_type) for specifying the slice type is an example of the coding parameters included in the slice header.

[0039] Examples of the slice types that can be specified by the slice type specification information include (1) I slice that uses only intra prediction during coding, (2) P slice that uses either unidirectional prediction or intra prediction during coding, and (3) B slice that uses unidirectional prediction, bidirectional prediction, or intra prediction during coding. Note that inter prediction is not limited to uni-prediction and bi-prediction, and a predicted image may be generated using more reference pictures. Hereinafter, when referring to P and B slices, it refers to a slice including a block that can use inter prediction.

[0040] ​​​Note that the slice header may include a reference (pic_parameter_set_id) to the picture parameter set PPS.

[0041] (Encoded slice data) In the encoded slice data, a set of data that the moving image decoding device 31 refers to in order to decode the slice data to be processed is defined. The slice data includes CTUs as shown in the encoded slice header of FIG. 4. As shown in the slice header, it includes CTUs. A CTU is a block of a fixed size (for example, 64x64) that constitutes a slice, and is sometimes also called the largest coding unit (LCU).

[0042] (Coding tree unit) In the coding tree unit of FIG. 4, a set of data that the moving image decoding device 31 refers to in order to decode the CTU to be processed is defined. A CTU is divided into coding units (CUs), which are the basic units of the encoding process, by recursive quadtree (QT) splitting, binary tree (BT) splitting, or ternary tree (TT) splitting. The combination of BT splitting and TT splitting is called multi-tree splitting (MT splitting). A node of the tree structure obtained by recursive quadtree splitting is called a coding node. Intermediate nodes of the quadtree, binary tree, and ternary tree are coding nodes, and the CTU itself is also defined as the topmost coding node. split), binary tree split (BT (Binary Tree) split), or ternary tree split (TT (Ternary Tree) split). The combination of BT splitting and TT splitting is called multi-tree splitting (MT splitting). The nodes of the tree structure obtained by recursive quadtree splitting are called coding nodes. The intermediate nodes of the quadtree, binary tree, and ternary tree are coding nodes, and the CTU itself is also defined as the topmost coding node. The CT, as CT information, includes a QT split flag (cu_split_flag) indicating whether to perform QT splitting, an MT split flag (split_mt_flag) indicating the presence or absence of MT splitting, and an MT split direction indicating the split direction of MT splitting.

[0043] CT, as CT information, includes a QT split flag (cu_split_flag) indicating whether to perform QT splitting, an MT split flag (split_mt_flag) indicating the presence or absence of MT splitting, and an MT split direction indicating the split direction of MT splitting (split_mt_dir), including the MT split type (split_mt_type) indicating the split type of MT splitting. cu_split_flag, split_mt_flag, split_mt_dir, and split_mt_type are transmitted for each encoding node.

[0044] When cu_split_flag is 1, the encoding node is split into four encoding nodes (QT in Figure 5).

[0045] When cu_split_flag is 0 and split_mt_flag is 0, the encoding node is not split and has one CU as a node (no split in Figure 5). The CU is the terminal node of the encoding node and will not be split further above. The CU is the basic unit of the encoding process.

[0046] When split_mt_flag is 1, the encoding node is MT split as follows. When split_mt_type is 0 and split_mt_dir is 1, the encoding node is horizontally split into two encoding nodes (BT (horizontal split) in Figure 5), and when split_mt_dir is 0, the encoding node is vertically split into two encoding nodes (BT (vertical split) in Figure 5). Also, when split_mt_type is 1 and split_mt_dir is 1, the encoding node is horizontally split into three encoding nodes (TT (horizontal split) in Figure 5), and when split_mt_dir is 0, the encoding node is vertically split into three encoding nodes (TT (vertical split) in Figure 5). These are shown in the CT information of Figure 5.

[0047] Also, when the size of the CTU is 64x64 pixels, the size of the CU can be any of 64x64 pixels, 64x32 pixels, 32x64 pixels, 32x32 pixels, 64x16 pixels, 16x64 pixels, 32x16 pixels, 16x32 pixels, 16x16 pixels, 64x8 pixels, 8x64 pixels, 32x8 pixels, 8x32 pixels, 16x8 pixels, 8x16 pixels, 8x8 pixels, 64x4 pixels, 4x64 pixels, 32x4 pixels, 4x32 pixels, 16x4 pixels, 4x16 pixels, 8x4 pixels, 4x8 pixels, and 4x4 pixels.

[0048] (Coding Unit) As shown in the coding unit of FIG. 4, a set of data referred to by the video image decoding device 31 for decoding the coding unit to be processed is defined. Specifically, the CU is composed of a CU header CUH, prediction parameters, transform parameters, quantized transform coefficients, etc. The prediction mode and the like are defined in the CU header.

[0049] The prediction process may be performed in units of CU or in units of sub-CUs obtained by further dividing the CU. When the sizes of the CU and the sub-CU are equal, there is one sub-CU in the CU. When the CU is larger than the size of the sub-CU, the CU is divided into sub-CUs. For example, when the CU is 8x8 and the sub-CU is 4x4, the CU is divided into four sub-CUs consisting of two horizontal divisions and two vertical divisions.

[0050] The types of prediction (prediction mode CuPredMode) include at least two types: intra prediction (MODE_INTRA) and inter prediction (MODE_INTER). Furthermore, intra block copy prediction (MODE_IBC) may be provided. Intra prediction and intra block copy prediction are predictions within the same picture, and inter prediction refers to prediction processing performed between different pictures (for example, between display times, between layer images).

[0051] The transform and quantization processing is performed in units of CU, but the quantized transform coefficients are in units of sub-blocks such as 4x4 It may be entropy encoded.

[0052] (Prediction parameter) The predicted image is derived from the prediction parameters associated with the block. The prediction parameters include intra-prediction and inter-prediction prediction parameters.

[0053] Hereinafter, the prediction parameters for inter-prediction will be described. The inter-prediction parameters are composed of the prediction list utilization flags predFlagL0 and predFlagL1, the reference picture indexes refIdxL0 and refIdxL1, and the motion vectors mvL0 and mvL1. predFlagL0 and predFlagL1 are flags indicating whether the reference picture list (L0 list, L1 list) is used. When the value is 1, the corresponding reference picture list is used. In this specification, when it is described as "a flag indicating whether XX", when the flag is other than 0 (for example, 1) is the case of XX, 0 is the case of not XX, and in logical negation, logical product, etc., 1 is true and 0 is false (the same applies hereinafter). However, in an actual apparatus or method, other values can be used as true values and false values.

[0054] Syntax elements for deriving inter-prediction parameters include, for example, the merge flag merge_flag used in the merge mode, the merge index merge_idx, the inter-prediction identifier inter_pred_idc for selecting the reference picture used in the AMVP mode, the reference picture index refIdxLX, the prediction vector index mvp_LX_idx for deriving the motion vector, the differential vector mvdLX, and the motion vector precision mode amvr_mode. There are the reference picture index refIdxLX, the prediction vector index mvp_LX_idx for deriving the motion vector, the differential vector mvdLX, and the motion vector precision mode amvr_mode.

[0055] (Reference picture list) The reference picture list is a list composed of the reference pictures stored in the reference picture memory 306. FIG. 6 is a conceptual diagram showing an example of the reference picture and the reference picture list. . In FIG. 6(a), the rectangle represents a picture, the arrow represents the reference relationship of the picture, the horizontal axis represents time, I, P, and B in the rectangle represent an intra picture, a single prediction picture, and a dual prediction picture respectively, and the numbers in the rectangle represent the decoding order. As shown in the figure, the decoding order of the pictures is I0, P1, B2, B3, B4, and the display order is I0, B3, B2, B4, P1. FIG. 6(b) shows an example of the reference picture list of picture B3 (the target picture). The reference picture list is a list representing candidates for reference pictures, and one picture (slice) may have one or more reference picture lists. In the example of the figure, the target picture B3 has two reference picture lists, the L0 list RefPicList0 and the L1 list RefPicList1. For each individual CU, refIdxLX is used to specify which picture in the reference picture list RefPicListX (X = 0 or 1) is actually referenced. The figure shows an example of refIdxL0 = 2 and refIdxL1 = 0. Note that LX is a description method used when not distinguishing between L0 prediction and L1 prediction. Hereinafter, by replacing LX with L0 and L1, the parameters for the L0 list and the parameters for the L1 list are distinguished.

[0056] (Merge Prediction and AMVP Prediction) There are a merge prediction (merge) mode and an AMVP (Advanced Motion Vector Prediction) mode in the method for decoding (encoding) prediction parameters, and merge_flag is a flag for identifying these. The merge prediction mode is a mode that derives from the prediction parameters of adjacent blocks that have already been processed without including the prediction list utilization flag predFlagLX, the reference picture index refIdxLX, and the motion vector mvLX in the encoded data. The AMVP mode is a mode that includes inter_pred_idc, refIdxLX, and mvLX in the encoded data. Note that mvLX is encoded as mvp_LX_idx for identifying the prediction vector mvpLX and the differential vector mvdLX.

[0057] The inter_pred_idc is a value indicating the type and number of reference pictures, and takes one of the values of PRED_L0, PRED_L1, and PRED_BI. PRED_L0 and PRED_L1 are managed in the L0 list and the L1 list, respectively. It indicates single prediction using one reference picture. PRED_BI is managed in the L0 list and the L1 list. It indicates bi-prediction using two reference pictures.

[0058] The merge_idx is an index indicating which prediction parameter among the prediction parameter candidates (merge candidates) derived from the processed blocks is used as the prediction parameter of the target block.

[0059] (Motion Vector) The mvLX indicates the shift amount between blocks on two different pictures. The prediction vector and the differential vector related to mvLX are called mvpLX and mvdLX, respectively.

[0060] (Inter-prediction identifier inter_pred_idc and prediction list usage flag predFlagLX) The relationship between the inter_pred_idc and the predFlagL0 and predFlagL1 is as follows and they are mutually convertible.

[0061] inter_pred_idc = (predFlagL1<<1)+predFlagL0 predFlagL0 = inter_pred_idc & 1 predFlagL1 = inter_pred_idc >> 1 Note that the inter-prediction parameters may use the prediction list usage flag or the inter-prediction identifier. Also, the determination using the prediction list usage flag may be replaced with the determination using the inter-prediction identifier. Conversely, the determination using the inter-prediction identifier may be replaced with the determination using the prediction list usage flag.

[0062] (Determination of biPred) The flag biPred indicating whether it is a bi-prediction can be derived based on whether both of the two prediction list usage flags are 1. For example, it can be derived using the following formula.

[0063] biPred = (predFlagL0==1 && predFlagL1==1) Alternatively, biPred can also be derived based on whether the inter-prediction identifier is a value indicating the use of two prediction lists (reference pictures). For example, it can be derived using the following formula.

[0064] biPred = (inter_pred_idc==PRED_BI)? 1 : 0 (Intra prediction parameters) The prediction parameters of intra prediction will be described below. The intra prediction parameters are composed of the luminance prediction mode IntraPredModeY and the chrominance prediction mode IntraPredModeC. For example, planar prediction (0), DC prediction (1), Angular prediction (otherwise). Furthermore, the CCLM mode (81 - 83) may be added for chrominance.

[0065] (Configuration of video decoder) The configuration of the video decoder 31 (Figure 7) according to this embodiment will be described.

[0066] The video decoder 31 includes an entropy decoder 301, a parameter decoder (predicted image decoder )302, a loop filter 305, a reference picture memory 306, a prediction parameter memory 307, a predicted image generation unit (predicted image generation device) 308, an inverse quantization and inverse transformation unit 311, and an addition unit 312, and a prediction para meter derivation unit 320. Note that, in accordance with the video encoder 11 described later, there is also a configuration in which the video decoder 31 does not include the loop filter 305.

[0067] The parameter decoding unit 302 further includes a header decoding unit 3020, a CT information decoding unit 3021, and a CU decoding unit 3022 (prediction mode decoding unit), and the CU decoding unit 3022 further includes a TU decoding unit 3024. These may be collectively referred to as a decoding module. The header decoding unit 3020 decodes parameter set information such as VPS, SPS, PPS, and APS, and slice header (slice information) from the encoded data. The CT information decoding unit 3021 decodes CT from the encoded data. The CU decoding unit 3022 decodes CU from the encoded data. When the TU contains prediction error, the TU decoding unit 3024 decodes QP update information (quantization correction value) and quantized prediction error (residual_coding) from the encoded data. Decode.

[0068] The TU decoding unit 3024 decodes QP update information and quantized prediction error from the encoded data when it is not in the skip mode (skip_mode == 0). More specifically, when skip_mode == 0, the TU decoding unit 3024 decodes a flag cu_cbp indicating whether the target block contains quantized prediction error, and decodes the quantized prediction error when cu_cbp is 1. If cu_cbp does not exist in the encoded data it is derived as 0.

[0069] The TU decoding unit 3024 decodes an index mts_idx indicating the transform basis from the encoded data. Also, the TU decoding unit 3024 decodes an index stIdx indicating the use of secondary transform and the transform basis from the encoded data. When stIdx is 0, it indicates non - application of the secondary transform. When stIdx is 1, it indicates one of the transforms in a set (pair) of secondary transform bases. When stIdx is 2, it indicates the other transform in the above pair.

[0070] The predicted image generation unit 308 is configured to include an inter - predicted image generation unit 309 and an intra - predicted image generation unit.

[0071] The prediction parameter derivation unit 320 includes an inter prediction parameter derivation unit 303 and an intra prediction parameter derivation unit.

[0072] In the following, an example will be described in which CTU and CU are used as processing units, but this is not limitative. Alternatively, the processing may be performed in units of sub-CUs. and processing may be performed in units of blocks or sub-blocks.

[0073] The entropy decoding unit 301 performs entropy decoding on the coded stream Te input from the outside. Entropy coding is performed to decode individual codes (syntax elements). There are two types of entropy coding: CABAC (Context Adaptive Binary Arithmetic Coding), which uses a context (probability model) adaptively selected according to the type of syntax element and the surrounding circumstances to perform variable-length coding of syntax elements, and CABAC (Context Adaptive Binary Arithmetic Coding), which uses a predetermined table or formula to perform variable-length coding of syntax elements.

[0074] The entropy decoding unit 301 outputs the decoded code to the parameter decoding unit 302. The decoded code is, for example, a prediction mode predMode, merge_flag, merge_idx, inter_pred_idc, refIdxLX, mvp_LX_idx, mvdLX, amvr_mode, etc. Control of which code to decode is performed based on an instruction from the parameter decoding unit 302.

[0075] (Basic flow) FIG. 8 is a flowchart illustrating the general operation of the video decoding device 31.

[0076] (S1100: Decode Parameter Set Information) The header decoder 3020 decodes parameter set information such as VPS, SPS, and PPS from the coded data.

[0077] (S1200: Slice Information Decoding) The header decoding unit 3020 decodes the slice header (slice information) from the encoded data.

[0078] Subsequently, for each CTU included in the target picture, the video decoding apparatus 31 repeats the processes from S1300 to S5000 to derive a decoded image for each CTU.

[0079] (S1300: CTU Information Decoding) The CT information decoding unit 3021 decodes the CTU from the encoded data.

[0080] (S1400: CT Information Decoding) The CT information decoding unit 3021 decodes the CT from the encoded data.

[0081] (S1500: CU Decoding) The CU decoding unit 3022 performs S1510 and S1520 to decode the CU from the encoded data (S1510: CU Information Decoding) The CU decoding unit 3022 decodes CU information, prediction information, TU split

[0082] flag split_transform_flag, CU residual flags cbf_cb, cbf_cr, cbf_luma, etc. from the encoded data. (S1520: TU Information Decoding) When the TU contains prediction errors, the TU decoding unit 3024 decodes QP update information, quantized prediction errors, and transform index mts_idx from the encoded

[0083] data. Note that the QP update information is the difference value from the quantization parameter prediction value qPpred, which is the predicted value of the quantization parameter QP.

[0084] (S2000: Predicted Image Generation) The predicted image generation unit 308 generates a predicted image for each block included in the target CU based on the prediction information.

[0085] ​​(S3000: Inverse Quantization and Inverse Transformation) For each TU included in the target CU, the inverse quantization and inverse transformation unit 311 performs inverse quantization and inverse transformation processing.

[0086] (S4000: Decoded Image Generation) The addition unit 312 adds the predicted image supplied from the predicted image generation unit 308 and the prediction error supplied from the inverse quantization and inverse transformation unit 311 to generate the decoded image of the target CU.

[0087] (S5000: Loop Filter) The loop filter 305 applies loop filters such as a deblocking filter, SAO, and ALF to the decoded image to generate a decoded image.

[0088] (Configuration of Inter-Prediction Parameter Derivation Unit) The inter-prediction parameter derivation unit 303 (Fig. 9) refers to the prediction parameters stored in the prediction parameter memory 307 based on the syntax elements input from the parameter decoding unit 302 and derives inter-prediction parameters. Also, the inter-prediction parameters are output to the inter-prediction image generation unit 309 and the prediction parameter memory 307. Since the inter-prediction parameter derivation unit 303 and its internal elements, the AMVP prediction parameter derivation unit 3032, the merge prediction parameter derivation unit 3036, and the MV addition unit 3038 are common means in the video encoding device and the video decoding device, they may be collectively referred to as a motion vector derivation unit (motion vector derivation device). When merge_flag is 1, that is, when indicating the merge prediction mode, merge_idx is derived and output to the merge prediction parameter derivation unit 3036.

[0089]

[0090] When the merge_flag is 0, that is, when indicating the AMVP prediction mode, the AMVP prediction parameter derivation unit 3032 derives mvpLX from inter_pred_idc, refIdxLX, or mvp_LX_idx.

[0091] (MV Addition Unit) In the MV addition unit 3038, the derived mvpLX and mvdLX are added to derive mvLX.

[0092] (Merge Prediction) FIG. 10(a) is a schematic diagram showing the configuration of the merge prediction parameter derivation unit 3036 according to the present embodiment. The merge prediction parameter derivation unit 3036 includes a merge candidate derivation unit 30361, a merge candidate selection unit 30362, and a merge candidate storage unit 30363. The merge candidates are configured to include prediction parameters (predFlagLX, mvLX, refIdxLX) and are stored in a merge candidate list. An index is assigned to the merge candidates stored in the merge candidate list according to a predetermined rule.

[0093] The merge candidate derivation unit 30361 derives merge candidates from the motion vectors of the decoded adjacent blocks and refIdxLX. The merge candidate derivation unit 30361 may apply NASMVP (Non-adjacent spatial candidate Motion Vector Prediction) merge candidate derivation processing, spatial merge candidate derivation processing, temporal merge candidate derivation processing, pairwise merge candidate derivation processing, and zero merge candidate derivation processing. The merge candidate derivation unit 30361 includes a NASMVP merge candidate derivation unit 30366, a spatial merge candidate derivation unit 30364, a temporal merge candidate derivation unit 30365, a pairwise merge candidate derivation unit 30367, and a zero merge candidate derivation unit 30368. NASMVP (Non-adjacent spatial candidate Motion Vector Prediction) The NASMVP merge candidate derivation unit 30366 predicts from the motion information of the non-adjacent blocks of the target block.

[0094] The NASMVP merge candidate derivation unit 30366 predicts from the motion information of the non-adjacent blocks of the target block. Derive the parameter (NASMVP merge candidate).

[0095] The spatial merge candidate derivation unit 30364 reads out the prediction parameters stored in the prediction parameter memory 307 according to a predetermined rule and sets them as merge candidates. The merge candidates are, for example, the prediction parameters related to each of the adjacent blocks within a predetermined range from the target block. The adjacent blocks are, for example, all or part of the blocks that are respectively adjacent to the left A1, right B1, upper right B0, lower left A0, and upper left B2 of the target block. Each merge candidate is called A1, B1, B0, A0, B2, and is the prediction parameter derived from the block including the following coordinates. The positions of A1, B1, B0, A0, B2 are shown in Fig. 15(a).

[0096] A1: (xCb - 1, yCb + cbHeight - 1) B1: (xCb + cbWidth - 1, yCb - 1) B0: (xCb + cbWidth, yCb - 1) A0: (xCb - 1, yCb + cbHeight) B2: (xCb - 1, yCb - 1) Let the upper left coordinates of the target block be (xCb, yCb), the width be cbWidth, and the height be cbHeight.

[0097] The temporal merge candidate derivation unit 30365 reads out the prediction parameters of the lower right block C[0] of the target block in the reference image, or the prediction parameters of the block C[1] including the central coordinates from the prediction parameter memory 307, and derives the merge candidate Col. An example of the blocks C[0] and C[1] is shown in Fig. 15(b).

[0098] The pairwise merge candidate derivation unit 30367 derives the pairwise merge candidate avgK from the average of two merge candidates already stored in the merge candidate list. Derive the pairwise merge candidate avgK from the average of the two merge candidates already stored in the merge candidate list.

[0099] The zero merge candidate derivation unit 30368 derives zero merge candidates Z0, …, ZM where refIdxLX is from 0 to M and both the X component and Y component of mvLX are 0. The merge candidate storage unit 30363 stores the merge candidates derived by the merge candidate derivation unit 30361 in the merge candidate list (mergeCandList[]).

[0100] The order in which the merge candidate storage unit 30363 stores the merge candidates in mergeCandList[] is, for example, spatial merge candidates (A1, B1, B0, A0, B2), temporal merge candidate Col, NAS MVP merge candidate NAS, pairwise merge candidate avgK, and zero merge candidate ZK. An example of the merge candidate list is shown in FIG. 14. Note that the merge candidate N is stored in the merge candidate list only when the flag availableFlagN indicating the availability of the merge candidate N is 1. If availableFlagN is 0, it is not stored in the merge candidate list.

[0101] i = 0 If (availableFlagA1) mergeCandList[i++] = A1 If (availableFlagB1) mergeCandList[i++] = B1 If (availableFlagB0) mergeCandList[i++] = B0 If (availableFlagA0) mergeCandList[i++] = A0 If (availableFlagB2) mergeCandList[i++] = B2 If (availableFlagCol) mergeCandList[i++] = Col If (availableFlagNAS) mergeCandList[i++] = NAS If (availableFlagZK) if(availableFlagAvgK) mergeCandList[i++] = avgK if(i < MaxNumMergeCand) mergeCandList[i++] = ZK The merge candidate selection unit 30362 selects the merge candidate N indicated by merge_idx from among the merge candidates included in the merge candidate list by the following formula.

[0102] N = mergeCandList[merge_idx] Here, N is a label indicating a merge candidate, and can be any of NAS, A1, B1, B0, A0, B2, Col, avgK, ZK. The prediction parameters of the merge candidate indicated by the label N are (mvLXN[0], mvLXN[1]) and are indicated by predFlagLXN and refIdxLXN.

[0103] When NAS is selected as the merge candidate, an image on the reference picture RefPicListX[refIdxLXNAS] shifted by the motion vector mvLXNAS from the target block is read out as the prediction image.

[0104] The merge candidate selection unit 30362 stores the inter prediction parameters ((mvLXN[0], mvLXN[1]), predFlagLXN, refIdxLXN) of the selected merge candidate in the prediction parameter memory 307 and outputs them to the inter prediction image generation unit 309.

[0105] (Availability determination of reference block) (Availability determination of reference block) The availability availableN of the adjacent block (reference block) with (xNbY, yNbY) as the upper left coordinates of the block with respect to the target block may be derived as follows. If any of the following is true, availableN is set to false. ·xNbY < 0 ·yNbY < 0 ·xNbY >= pps_pic_width_in_luma_samples ·yNbY >= pps_pic_height_in_luma_samples ·( xNbY>>CtbLog2SizeY) > (xCurr>>CtbLog2SizeY) and (yNbY>>CtbLog2SizeY) >= (yCurr>>CtbLog2SizeY) ·(yNbY>>CtbLog2SizeY) >= (yCurr>>CtbLog2SizeY)+1 ·The adjacent block is included in a slice different from the target block. ·The adjacent block is included in a tile different from the target block. ·The wavefront flag (entropy coding synchronization flag) sps_entropy_coding_sync_enabled_flag is 1 and (xNbY>>CtbLog2SizeY) >= (xCurr>>CtbLog2SizeY)+1. Otherwise, set availableN to true.

[0106] After the above determination, if all of the following conditions are true, set availableN to false. ·checkPredModeY == TRUE. ·CuPredMode[0][xNbY][yNbY] != CuPredMode[0][xCurr][yCurr] Here, pps_pic_width_in_luma_samples and pps_pic_height_in_luma_samples are the screen size and CtbLog2SizeY is the CTU size. Shift the X coordinate and Y coordinate to the right (>>) by CtbLog2SizeY By doing so, the X coordinate and Y coordinate of the CTU unit can be obtained. CuPredMode indicates the prediction mode and may be any one of MODE_INTRA, MODE_INTER, and MODE_IBC. Also, checkPredModeY is set to 1 in the case of inter prediction, motion vector prediction, or merge prediction, and 0 otherwise. That is, when the target block is an inter prediction block (CuPredMode[0][xCurr][yCurr] == MODE_INTER) and the reference block is an intra prediction block (uPredMode[0][xNbY][yNbY] == MODE_INTRA), availableN is set to false.

[0107] The method for deriving NASMVP merge candidates according to the present invention will be described.

[0108] (NASMVP Merge Candidate Derivation) (Embodiment 1: Grouping by Direction of Non-Adjacent Blocks) The merge candidate derivation unit 30361 includes a spatial merge candidate derivation unit 30364, a temporal merge candidate derivation unit 30365 , a NASMVP merge candidate derivation unit 30366, a pairwise merge candidate derivation unit 30367, and a zero merge candidate derivation unit 30368.

[0109] The spatial merge candidate derivation unit 30364 derives the prediction parameters of the blocks adjacent to the lower left A0, left A1, upper left B2, upper right B0, and upper B1 of the target block shown in FIG. 15(a). However, when sps_nasmvp_enabled_flag is 1, the NASMVP merge candidate derivation unit 30366 uses the spatial non-adjacent blocks of the target block CurBLK to derive the merge candidates of the target block. That is, the search for candidates is performed from blocks at positions farther from the target block.

[0110] Here, the spatial non-adjacent block is a block that exists around the target block and is not directly adjacent to the target block.

[0111] In the target picture CurPic, FIG. 16 is another diagram showing the coordinates of adjacent and non - adjacent blocks of the target block CurBLK. Here, bW and bH are the width and height of the target block, and (xPb, yPb) is the upper - left coordinate of the target block. The coordinates of the adjacent block B2 can be represented as (xPb - 1, yPb - 1), the coordinates of B0 as (xPb + bW, yPb - 1), and the coordinates of A0 as (xPb - 1, yPb + bH). The coordinates of non - adjacent blocks can be represented by the following formula. {xPb + bW * i + (i < 2? - 1 : -bW), yPb + bH * j + (j < 2? - 1 : -bH)}, where i = - 1..3, j = - 1..3, except when (i == 1, j == 1), i>1 && j>1.

[0112] {xPb + bW * i + (i < 2? - 1 : -bW), yPb + bH * j + (j < 2? - 1 : -bH)}, i = -1..3, j = -1..3, provided that (i==1, j==1), i>1 && j>1 are excluded.

[0113] Since the above is for j = - 1, 0, i = - 1..3 and j = 1..3, i = - 1, 0, when enumerating from the smaller Y - coordinate as j, it can also be expressed as the following movement vectors of coordinates.

[0114] {xPb + bW * i + (i < 2? - 1 : -bW), xPb - bH - 1}, i = -1..3 {xPb + bW * i + (i < 2? - 1 : -bW), xPb - 1}, i = -1..3 {xPb + bW * i + (i < 2? - 1 : -bW), xPb + bH -1}, i = -1..3 {xPb + bW * i - 1, xPb + bH}, i = -1..0 {xPb + bW * i - 1, xPb + bH * 2}, i = -1..0 Also, the position of the non - adjacent block may be any of the following.

[0115] {xPb + bW * i, xPb - bH * i}, i = n {xPb + (bW>>1), xPb - bH * i}, i = n {xPb - bW * i, xPb - bH * i}, i = n {xPb - bW * i, xPb + (bH>>1)}, i = n {xPb - bW * i, xPb + bH * i}, i = n {xPb + bW * i, xPb - 1}, i = n {xPb - 1, xPb + bH * i}, i = n {xPb + bW-1, xPb - bH * i}, i = n {xPb - bW * i, xPb + bH-1}, i = n Next, as an example, a method for deriving NASMVP merge candidates by grouping non-adjacent blocks will be described.

[0116] The NASMVP merge candidate derivation unit 30366 searches for blocks divided into a plurality of groups according to the positional relationship with the target block, and derives NASMVP merge candidates. The NASMVP merge candidate derivation unit 30366 derives one non-adjacent block from each group, and the merge candidate storage unit 30363 stores one NASMVP merge candidate in the merge candidate list for each group.

[0117] Step 1) Search for non-adjacent blocks according to the direction from the target block The NASMVP merge candidate derivation unit 30366 divides non-adjacent blocks into a plurality of groups according to the direction from the target block. For each of these groups, search for NASMVP merge candidates. Specifically, the non-adjacent blocks may be divided into five groups shown in FIG. 17. Note that the number of groups is not limited to the following directions and numbers, and only groups A, C, and E may be used. ​Group A (SearchGroupA) includes the non - adjacent blocks above the target block.

[0118] Aa: (xPb - 1, yPb - bH - 1) Ab: (xPb + bW - 1, yPb - bH - 1) Group B (SearchGroupB) includes the non - adjacent blocks in the upper - right direction of the target block.

[0119] Ba: (xPb + bW * 2, yPb - 1) Bb: (xPb + bW * 2, yPb - bH - 1) Group C (SearchGroupC) includes the non - adjacent blocks to the left of the target block.

[0120] Ca: (xPb - bW - 1, yPb - 1) Cb: (xPb - bW - 1, yPb + bH - 1) Group D (SearchGroupD) includes the non - adjacent blocks in the lower - left direction of the target block Da: (xPb - 1, yPb + bH * 2) Db: (xPb - bW - 1, yPb + bH * 2) Group E (SearchGroupE) includes the non - adjacent blocks in the upper - left direction of the target block Ea: (xPb - bW - 1, yPb - bH - 1) Eb: (xPb - 2 * bW - 1, yPb - 2 * bH - 1) The above is an example of searching two blocks from each group.

[0121] The blocks searched in each group by the NASMVP merge candidate derivation unit 30366 are not limited to two 、and can be 1 to n. For example, when searching three blocks from each of the groups shown in Fig. 17 、the coordinates of groups A, B, and C are as follows.

[0122] Group A (SearchGroupA) Aa: (xPb - 1, yPb - bH - 1) Ab: (xPb + bW - 1, yPb - bH - 1) Ac: (xPb + bW, yPb - bH - 1) Group B (SearchGroupB) Ba: (xPb + bW * 2, yPb - 1) Bb: (xPb + bW * 2, yPb - bH - 1) Bc: (xPb + bW * 3, yPb - 1) Group C (SearchGroupC) Ca: (xPb - bW - 1, yPb - 1) Cb: (xPb - bW - 1, yPb + bH - 1) Cc: (xPb - bW - 1, yPb + bH) The same applies to the other groups (D, E), and the description is omitted. The NASMVP merge candidate derivation unit 30366 searches for available merge candidates for each of the five groups from A to E above. When one available candidate is found in a certain group, the search in that group is stopped and the next group is searched. That is, the NASMVP merge candidate derivation unit 30366 selects one non-adjacent block and its motion information (merge candidate) from each direction group respectively.

[0123] Pruning process example 1: When finding available merge candidates by the search in step 1 above, the NASMVP merge candidate derivation unit 30366 performs a pruning process when a certain condition is met. As an example of a certain condition For example, there is a case where the movement information (motion vector, reference picture) of a certain group of NASMVP merge candidates is the same as that of the searched spatial or temporal merge candidates. Here, the pruning process means that when multiple merge candidates have the same motion information, one of the merge candidates is not included in the merge candidate list. This can prevent multiple merge candidates with the same motion information from being stored in the merge candidate list, and has the effect of improving the encoding efficiency. The pruning process of this embodiment compares the identity of each of the five direction groups with one of the spatial or temporal merge candidates (A1, B1, B0, A0, Col). Therefore, a total of 5 times of pruning processes are performed. Since NASMVP merge candidates are obtained in group units, the number of pruning processes can be limited. Thereby, the encoding efficiency can be improved while suppressing the processing amount. Note that the definition of the same motion information may be "the motion vectors match each other", or "the difference between the motion vectors is within a predetermined range".

[0124] Pruning process example 2: When the NASMVP merge candidate derivation unit 303 finding available merge candidates, if the motion information of the non-adjacent blocks in the search target group is not the same as the motion information of one spatial merge candidate stored in the merge candidate list, the non-adjacent block is used as the NASMVP merge candidate. Otherwise, it is determined that the non-adjacent block is not available. Then, the identity between the motion information of the next non-adjacent block in the same group and the motion information of the spatial merge candidate is determined. For example, the spatial merge candidate for which the identity is determined may be the upper spatial merge candidate (B1) in group A , the upper right spatial merge candidate (B0) in group B, and the left spatial merge candidate (A1) in group C. Also, it may be the lower left spatial merge candidate (A0) in group D and the upper left spatial merge candidate (B2) in group E.

[0125] For example, the NASMVP merge candidate derivation unit 30366 may perform the following operations. In group A, if Aa is available and the movement information of Aa and B1 is different, Aa is set as the NASMVP merge candidate, and the subsequent processing of group A is stopped. If Aa is not available or the movement information of Aa and B1 is the same, search for Ab. If Ab is available and the movement information of Ab and B1 is different, Ab is set as the NASMVP merge candidate, and the subsequent processing of group A is stopped. If Ab is not available or the movement information of Ab and B1 is the same, search for Ac. If Ac is available and the movement information of Ac and B1 is different, Ac is set as the NASMVP merge candidate. If Ac is not available or the movement information of Ac and B1 is the same, it is determined that group A is not available.

[0126] For example, in group B, if Ba is available and the movement information of Ba and B0 is different, Ba is set as the NASMVP merge candidate, and the subsequent processing of group B is stopped. If Ba is not available or the movement information of Ba and B0 is the same, search for Bb. If Bb is available and the movement information of Bb and B0 is different, Bb is set as the NASMVP merge candidate and the subsequent processing of group B is stopped. Bb is not available or the movement information of Bb and B0 is the same, it is determined that group B is not available .

[0127] For example, in Group C, if Ca is available and the motion information of Ca and A1 is different, Ca is set as a NASMVP merge candidate and the subsequent processing of Group C is stopped. If Ca is not available or the motion information of Ca and C0 is the same, search for Cb. If Cb is available and the motion information of Cb and A1 is different, Cb is set as a NASMVP merge candidate and the subsequent processing of Group C is stopped. If Cb is not available or the motion information of Cb and C0 is the same, search for Cc. If Cc is available and the motion information of Cc and A1 is different, Cc is set as a NASMVP merge candidate. If Cc is not available or the motion information of Cc and C0 is the same, Group C is determined to be not available.

[0128] For example, in Group D, if Da is available and the motion information of Da and A0 is different, Da is set as a NASMVP merge candidate and the subsequent processing of Group D is stopped. If Da is not available or the motion information of Da and A0 is the same, search for Db. If Db is available and the motion information of Bb and A0 is different, Db is set as a NASMVP merge candidate and the subsequent processing of Group D is stopped. If Db is not available or the motion information of Db and A0 is the same, Group D is determined to be not available.

[0129] For example, in Group E, if Ea is available and the motion information of Ea and B2 is different, Ea is set as a NASMVP merge candidate and the subsequent processing of Group E is stopped. If Ea is not available or the motion information of Ea and B2 is the same, search for Eb. If Eb is available and the motion information of Eb and B2 is different, Eb is set as a NASMVP merge candidate and the subsequent processing of Group E is stopped. If Eb is not available or the motion information of Eb and B2 is the same, Group E is determined to be not available.

[0130] In the above, the same motion information may include the following cases: 1) the motion vectors are the same and the reference picture indexes are the same, or 2) the absolute difference value of the motion vectors of two blocks is less than or equal to a predetermined value and the reference picture indexes are the same.

[0131] In this configuration, if a spatial merge candidate and a non-adjacent block have the same or similar motion information, the motion information of the non-adjacent block is not used by pruning. This improves coding efficiency. Furthermore, pruning is performed only between the NASMVP merge candidate and a specific spatial merge candidate, reducing the amount of pruning processing.

[0132] Pruning process example 3: The motion information of a non-adjacent block in the search target group (e.g., B) is For example, if the motion information of the NASMVP merge candidate in A) is not the same as that of the non-adjacent block, If not, the next non-NASMVP merge candidate in the search group is In this configuration, multiple NASMVP merge candidates all have different motion information, resulting in high coding efficiency.

[0133] Step 2) Store the merge candidate list The merge candidate storage unit 30363 stores the NASMVP merge candidates in the pruning process of step 1. The subsequent merge candidates are stored in the merge candidate list mergeCandList[].

[0134] For example, the NASMVP merge candidates for groups A, B, C, D, and E are NASA, NASB, NASC, NASD, and NASE, respectively. Then, it can be stored in the merge candidate list as follows: i = 0 if(availableFlagA1) mergeCandList[i++] = A1 if(availableFlagB1) mergeCandList[i++] = B1 if(availableFlagB0) mergeCandList[i++] = B0 if(availableFlagA0) mergeCandList[i++] = A0 if(availableFlagB2) mergeCandList[i++] = B2 if(availableFlagCol) mergeCandList[i++] = Col if(availableFlagNASA) mergeCandList[i++] = NASA if(availableFlagNASB) mergeCandList[i++] = NASB if(availableFlagNASC) mergeCandList[i++] = NASC if(availableFlagNASD) mergeCandList[i++] = NASD if(availableFlagNASE) mergeCandList[i++] = NASE if(availableFlagAvgK) mergeCandList[i++] = avgK if(i < MaxNumMergeCand) mergeCandList[i++] = ZK The merge candidate selection unit 30362 selects the merge candidate mergeCandList[merge_idx] of the target block from this list using the merge_idx derived by the parameter decoding control unit 3031 in Fig. 10(a). Do it.

[0135] Here, let the motion vector of the NASMVP merge candidate be mvLXNASGP, the reference picture index be RefIdxLXNASGP, the reference picture list be RefLXNASGP, and increment the count cnt by 1. If there are no available non-adjacent blocks, set the count cnt = 0 and mvLXNASGP = 0. This process can be represented by the following pseudo-code as an example.

[0136] for GP in A, B, C, D, E / / Group loop for (j < 0; j < NumSearchGroupGP; j++) xNb = SearchGroupGP[j][0] yNb = SearchGroupGP[j][1] if (availableFlagLXNASGP(xCurr,yCurr,xNb, yNb)==1) { mvLXNASGP = mvLX[xNb][yNb]; refIdxLXNASGP = refIdxLX[xNb][yNb]; RefLXNASGP = RefPicListX[refIdxLXNAS]; break; } Here, when the inter-prediction image generation unit 309 uses the merge candidate as NAS, that is, when the NASMVP merge candidate is selected, the block on the reference picture RefPicListX[refIdxLX] is read, and a prediction image is generated by interpolation. The block is located at a position shifted by MvLXNAS from the target block.

[0137] According to the above configuration, when deriving the NASMVP merge candidate from the periphery of the target block, by limiting the number of pruning process times through grouping, it is possible to derive a highly accurate merge candidate while limiting the processing amount.

[0138] (Embodiment 2: Grouping by distance to non-adjacent blocks) Step 1) In the implementation mobile device 2, an example of grouping non-adjacent blocks by distance from the target block rather than by direction will be described. That is, the NASMVP merge candidate derivation unit 30366 searches for NASMVP merge candidates for each distance group. As an example, it is divided into a distance 1 group and a distance 2 group as shown in FIG. 18. Here, if bW and bH are the width and height of the target block, and the upper left coordinates of the target block are represented as (xPb, yPb), the grouping is represented by the following formula. {xPb + bW * i + (i < 2? -1 : -bW), yPb + bH * j + (j < 2? -1 : -bH)}, i = -1..3, j = -1..2,

[0139] Specifically, it is represented by the following coordinates. Distance 1 group (SearchGroupDisn)

[0140] {xPb + bW * i, xPb - bH * i}, i = 1 {xPb + (bW>>1), xPb - bH * i}, i = 1 {xPb - bW * i, xPb - bH * i}, i = 1 {xPb - bW * i, xPb + (bH>>1)}, i = 1 {xPb - bW * i, xPb + bH * i}, i = 1 Distance 2 group (SearchGroupDis2) {xPb + bW * i, xPb - bH * i}, i = 2 {xPb + (bW>>1), xPb - bH * i}, i = 2 {xPb - bW * i, xPb - bH * i}, i = 2 {xPb - bW * i, xPb + (bH>>1)}, i = 2 {xPb - bW * i, xPb + bH * i}, i = 2 {xPb - bW * i, xPb + bH * i}, i = 2 The above is an example where the distance group SearchGroupDis is searched up to 2. However, the number of distance groups used by the NASMVP merge candidate derivation unit 30366 is not limited to 2. For example, within the CTU range to which the target block belongs, it may be searched up to n times (for example, n = 1, 2, 3, 4, 5..).

[0141] Distance n group (SearchGroupDisn) {xPb + bW * i, xPb - bH * i}, i = n {xPb + (bW>>1), xPb - bH * i}, i = n {xPb - bW * i, xPb - bH * i}, i = n {xPb - bW * i, xPb + (bH>>1)}, i = n {xPb - bW * i, xPb + bH * i}, i = n Also, the above is an example referring to the upper right, upper, upper left, left, and lower left. However, the NASMVP merge candidate derivation unit 30366 may refer to other positions. For example, -1 may be used instead of -bH*i in the upper right, and -1 may be used instead of bW*i in the lower left.

[0142] Distance n group (SearchGroupDisn) {xPb + bW * i, xPb - 1}, i = n {xPb + (bW>>1), xPb - bH * i}, i = n {xPb - bW * i, xPb - bH * i}, i = n {xPb - bW * i, xPb + (bH>>1)}, i = n {xPb - 1, xPb + bH * i}, i = n The NASMVP merge candidate derivation unit 30366 may use other reference positions. For example, bw - 1 may be used instead of bw>>1, and bH - 1 may be used instead of bH>>1.

[0143] Distance n group (SearchGroupDisn) {xPb + bW * i, xPb - 1}, i = n {xPb + bW - 1, xPb - bH * i}, i = n {xPb - bW * i, xPb - bH * i}, i = n {xPb - bW * i, xPb + bH - 1}, i = n {xPb - 1, xPb + bH * i}, i = n Step 2), and Step 3 Steps 2 and 3 of this embodiment are the same as Steps 2 and 3 of Embodiment 1. That is, even when searching for NASMVP merge candidates in distance group units as shown in Processing Example 1 of the pruning process, pruning of NASMVP merge candidates may be performed. Also, as shown in Processing Example 2 of the pruning process, pruning with specific spatial merge candidates in distance group units may be performed. Also, as shown in Processing Example 3 of the pruning process, pruning may be performed within distance groups and between distance groups.

[0144] According to the above configuration, when deriving NASMVP merge candidates around the target block, by restricting the number of pruning process times through grouping, it is possible to derive high-precision merge candidates while restricting the processing amount.

[0145] (Embodiment 3: Selection of Direction) Embodiment 3 is a modification of Embodiment 1. For example, direction groups A and B shown in FIG. 17 search for groups selected according to predetermined conditions. Similarly, direction groups C and D also search for groups selected according to predetermined conditions. As an example of the selection conditions, for example, the groups to be searched may be switched according to the ratio of bW and bH, which are the width and height of the target block. As an example, it can be expressed by the following pseudo-code.

[0146] mvNAS = 0; cnt = 0; NumSearchNAS = 3; for (i = 0; i < NumSearchNAS; i++) { switch (NumSearchNAS) { case 0: blkNAS = bW / bH > 2? SearchGroupA : SearchGroupB; break; case 1: blkNAS = bH / bW > 2? SearchGroupC : SearchGroupD; break; case 2: blkNAS = SearchGroupE; break; } if (availableFlag[blkNAS] == 1) { mvNAS = mvLX[xNb[blkNAS]][yNb[blkNAS]]; refIdxNAS = refIdxLX[xNb[blkNAS]][yNb[blkNAS]]; RefNAS = RefPicListX[refIdxNAS]; cnt++; break; } According to the above configuration, when deriving NASMVP merge candidates from around the target block, it is possible to adaptively change the search pattern while restricting the processing amount. As a result, it is possible to derive highly accurate merge candidates.

[0147] (Embodiment 4: Block Size Limit) In Embodiment 4, the restriction conditions when storing the NASMVP merge candidates of Embodiments 1 to 3 in the merge candidate list are described.

[0148] When the merge candidate storage unit 30363 stores the merge candidate in mergeCandList[], if the size of the target block is equal to or less than a predetermined size, the NASMVP merge candidate NAS is stored, otherwise It may also be a configuration that does not accept. Specifically, when the width and height of the target block exceed a predetermined size n (bW > n && bH > n), NASMVP is not stored in the merge candidate list. Here, n = 32, Constants such as 16, 8.. etc. The availability determination conditions of the reference block when searching for NASMVP candidates are shown below.

[0149] The availability availableFlagN of the adjacent block with respect to the target block may be derived as follows. When the following conditions are true, set availableFlagN of the NASMVP candidate to false. ·bW > n && bH > n Here, bW and bH are the sizes of the target block, and n = 8, 16, 32...

[0150] Only when the flag availableFlagN indicating the availability of the merge candidate N is 1, store the merge candidate N in the merge candidate list. If availableFlagN is 0, do not store it in the merge candidate list. i = 0 if(availableFlagA1) mergeCandList[i++] = A1 if(availableFlagB1) mergeCandList[i++] = B1 if(availableFlagB0) mergeCandList[i++] = B0 if(availableFlagA0) mergeCandList[i++] = A0 if(availableFlagB2) mergeCandList[i++] = B2 if(availableFlagCol) mergeCandList[i++] = Col if(availableFlagNA) mergeCandList[i++] = NAS if(availableFlagAvgK) mergeCandList[i++] = avgK if(i < MaxNumMergeCand) mergeCandList[i++] = ZK According to the above configuration, when deriving NAS MVP merge candidates from around the target block, the search for non-adjacent blocks is restricted according to the size of the target block. Thereby, the search for non-adjacent blocks that far exceeds the distance of the CTU is restricted, and the effect of reducing memory is achieved.

[0151] (Embodiment 5: Collocate taken from the lower right of the CTU) Embodiment 5 is a configuration that uses non-adjacent blocks in the temporal merge candidates. Here, the general temporal merge candidate derivation process will be described first.

[0152] As shown in FIG. 15(b), the temporal merge candidate derivation unit 30365 reads the prediction parameters of blocks C[0] and C[1] from the prediction parameter memory 307 as merge candidates, and stores them in the merge candidate list mergeCandList[]. The collocate block is the block at the same position as the target block on the collocate picture. Blocks C[0] and c[1] are blocks including the lower right position (Br) or the center position (Ctr) of the collocate block on the collocate picture. Generally, block C[0] is preferentially added to the merge candidate list mergeCandList[]. When block C[0] does not have a motion vector (for example, an intra-predicted block) or when block C[0] is located outside the picture, the motion vector of block C[1] is added to the merge candidate list.

[0153] For example, the time merge candidate derivation unit 30365 may derive the position (xColCtr, yColCtr) of block C[1] and the position (xColBr, yColBr) of block C[0] using the following equations.

[0154] xColCtr = xPb+(bW>>1) yColCtr = yPb+(bH>>1) xColBr = xPb+bW yColBr = yPb+bH Furthermore, as the coordinates of the Br block of Ctr, the lower bits (e.g., lower 3 bits) may be ignored and it may be referenced in a coarser unit. The reference may be realized using a shift as follows, or the values of the 3rd bit and above may be directly referenced.

[0155] ((xColCtr>>3)<<3, (yColCtr>>3)<<3) ((xColBr>>3)<<3, (yColBr>>3)<<3) Here, (xPb, yPb) is the upper left coordinate of the target block, and (bW, bH) is the width and height of the target block. If block C[0] is available, the motion information of block C[0] is used to derive the merge candidate Col. If block C[0] is not available, block C[1] is used to derive the merge candidate Col. When an available merge candidate is found, the merge candidate Col is stored in the merge candidate list. i = 0 if(availableFlagA1) mergeCandList[i++] = A1 if(availableFlagB1) mergeCandList[i++] = B1 if(availableFlagB0) mergeCandList[i++] = B0 if(availableFlagA0) mergeCandList[i++] = A0 if(availableFlagB2) mergeCandList[i++] = B2 if(availableFlagCol) mergeCandList[i++] = Col if(availableFlagNAS) mergeCandList[i++] = NAS if(availableFlagAvgK) mergeCandList[i++] = avgK if(i < MaxNumMergeCand) mergeCandList[i++] = ZK As another example, the lower right position and the center position of the target block that can be a temporal merge candidate are not limited to C[0] and C[1], and non-adjacent blocks away from the position of the collocated block may be used. For example, using the lower right position CTUBr of the CTU including the collocated block and the center position CTUCtr of the CTU is also acceptable. These are referred to as non-adjacent temporal merge candidates.

[0156] In this case, the merge candidate derivation unit 30361 shown in FIG. 10(a) is replaced with a non-adjacent temporal merge candidate derivation unit 30369 in the NASMVP merge candidate derivation unit 30366. Alternatively, the non-adjacent temporal merge candidate derivation unit 30369 and the NASMVP merge candidate derivation unit 30366 may exist simultaneously.

[0157] The non-adjacent temporal merge candidate derivation unit 30369 searches for the lower right position and then the center position in the CTU including the collocated block (C[2] and C[3] in FIG. 19). If an available block exists, the block is set as the non-adjacent temporal merge candidate NASCol.

[0158] ​For example, the non-adjacent time merge candidate derivation unit 30369 derives non-adjacent time merge candidates NASCol from the coordinates (xCTUBr, yCTUBr) of the lower right position c[2] of the CTU including the collocated block and the coordinates (xCTUCtr, yCTUCtr) of the center position c[3] of the CTU. These coordinates may be derived by the following equations. (xPCTU, yPCTU) are the upper left coordinates of the CTU including the collocated block, and (wCTU, hCTU) are the width and height of the CTU.

[0159] xCTUCtr = xPCTU+(wCTU>>1) yCTUCtr = yPCTU+(hCTU>>1)

[0160] xCTUBr = xPCTU+wCTU-1 yCTUBr = yPCTU+hCTU-1 Here, xPCTU and yPCTU may be derived as follows from the logarithmic representation of base 2 of the CTU size.

[0161] xPCTU = (xPb >> CtbLog2SizeY)<< CtbLog2SizeY yPCTU = (yPb >> CtbLog2SizeY)<< CtbLog2SizeY Alternatively, they may be derived by setting the lower bits to 0 as follows.

[0162] xPCTU = (xPb & ~(1<<CtbLog2SizeY-1) yPCTI = (yPb & ~(1<<CtbLog2SizeY-1) Here, "~" is a bitwise negation that converts 0 to 1 and 1 to 0 bit by bit. The width and height of the CTU size may be the same value CtbSizeY.

[0163] wCTU = hCTU = CtbSizeY In addition, the position of the non-adjacent time merge candidate is not limited to the center and the lower right. Blocks including the upper right CTBB1, lower left CTBA1, upper CTBB0, left CTBA0, and upper left CTBB2 may be used to derive the non-adjacent time merge candidate.

[0164] (xCTUB1, xCTUB1) = (xPCTU+wCTU-1, yPCTU-1) (xCTUA1, yCTUA1) = (xPCTU-1, yPCTU+hCTU-1) (xCTUB0, yCTUB0) = (xPCTU+wCTU, yPCTU-1) (xCTUA0, yCTUA0) = (xPCTU-1, yPCTU+hCTU) (xCTUB2, yCTUB2) = (xPCTU-1, yPCTU-1) In addition, blocks including the right CTBR and lower CTBB may be used to derive the non-adjacent time merge candidate.

[0165] (xCTUR, yCTUR) = (xPCTU+wCTU, yPCTU+(hCTU>>1)) (xCTUB, yCTUB) = (xPCTU+(wCTU)>>1, yPCTU+hCTU) When an available time merge candidate is found, the merge candidate storage unit 30363 stores the merge candidate including the non-adjacent time merge candidate NASCol in mergeCandList[]. For example, the spatial merge candidates (A1, B1, B0, A0, B2), the time merge candidate Col, the non-adjacent time merge candidate NASCol, the pairwise merge candidate avgK, and the zero merge candidate ZK. i = 0 if(availableFlagA1) mergeCandList[i++] = A1 if(availableFlagB1) mergeCandList[i++] = B1 if(availableFlagB0) mergeCandList[i++] = B0 if(availableFlagA0) mergeCandList[i++] = A0 if(availableFlagB2) mergeCandList[i++] = B2 if(availableFlagCol) mergeCandList[i++] = Col if(availableFlagNASCol) mergeCandList[i++] = NASCol if(availableFlagAvgK) mergeCandList[i++] = avgK if(i < MaxNumMergeCand) mergeCandList[i++] = ZK According to the above configuration, not only in the spatial merge candidates but also in the temporal merge candidates, in addition to the adjacent positions of the target block, non-adjacent positions are added. As a result, the motion vectors of collocated blocks with a high possibility of different motions can be added as prediction candidates. Therefore, the options for the prediction vector increase, and the coding efficiency is improved. Also, as the non-adjacent position, by using the relative position with respect to the upper left coordinate of the CTU including the collocated block, the non-adjacent position can be fixed in CTU units. Thereby, an increase in complexity due to referring to non-adjacent positions can be minimized.

[0166] (AMVP Prediction) FIG. 10(b) is a schematic diagram showing the configuration of the AMVP prediction parameter derivation unit 3032 according to the present embodiment. The AMVP prediction parameter derivation unit 3032 includes a vector candidate derivation unit 3033, a vector candidate reference unit 30331, an NNMVP vector candidate derivation unit 30332, a vector candidate selection unit 3034, and a vector candidate storage unit 3035.

[0167] The vector candidate selection unit 3034 selects the motion vector mvpListLX[mvp_LX_idx] indicated by the motion vector index mvp_LX_idx among the predicted vector candidates in mvpListLX[] as the predicted vector mvpLX. The vector candidate selection unit 3034 outputs the selected predicted vector mvpLX to the addition unit 3038. The addition unit 3038 adds the predicted vector mvpLX input from the AMVP prediction parameter derivation unit 3032 and the differential vector mvdLX input from the parameter decoding control unit 3031 to calculate the motion vector mvLX. The addition unit 3038 outputs the calculated motion vector mvLX to the predicted image generation unit 309 and the prediction parameter memory 307.

[0168] (MV addition unit)

[0169] mvLX[0] = mvpLX[0] + mvdLX[0] mvLX[1] = mvpLX[1] + mvdLX[1] (Precision of motion vector) amvr_mode is a syntax element that switches the precision of the motion vector derived in the AMVP mode. For example, at amvr_mode = 0, 1, 2, it switches between 1 / 4 pixel, 1 pixel, and 4 pixel precision. Instead of amvr_mode, a flag amvr_flag indicating whether it is 1 / 4 and a flag amvr_precision_flag that switches between 1 / 16 and 1 may be used.

[0170] When the precision of the motion vector is 1 / 16 precision, in order to change the motion vector differences of 1 / 4, 1, and 4 pixel precisions to the motion vector difference of 1 / 16 pixel precision, inverse quantization may be performed using MvShift (= 1 << amvr_mode = (amvr_flag + amvr_precision_flag) << 1) derived from amvr_mode as follows.

[0171] MvdLX[0] = MvdLX[0] << (MvShift + 2) MvdLX[1] = MvdLX[1] << (MvShift + 2) Similarly, when affine_flag is 1, it is derived by the following formula.

[0172] MvShift = amvr_precision_flag? (amvr_precision_flag << 1) : (-(amvr_flag << 1))) MvdCpLX[cpIdx][0] = MvdLX[cpIdx][0] << (MvShift + 2) MvdCpLX[cpIdx][1] = MvdLX[cpIdx][1] << (MvShift + 2) Note that the parameter decoding unit 302 may also decode and derive the mvdLX[] before shifting by the above MvShift using the following syntax elements. ·abs_mvd_greater0_flag ·abs_mvd_minus2 ·mvd_sign_flag Then, the parameter decoding unit 302 decodes the differential vector lMvd[] from the following formula using the syntax elements or.

[0173] lMvd[compIdx] = abs_mvd_greater0_flag[compIdx] * (abs_mvd_minus2[compIdx] + 2) * (1 - 2 * mvd_sign_flag[compIdx]) Furthermore, lMvd[] is set to MvdLX in the case of translational MVD (MotionModelIdc == 0), and set to MvdCpLX in the case of control point MVD (MotionModelIdc!= 0).

[0174] if (MotionModelIdc == 0) MvdLX[compIdx] = lMvd[compIdx] else MvdCpLX[cpIdx][compIdx] = lMvd[cpIdx][compIdx] Here, compIdx = 0, 1 and cpIdx = 0, 1, 2.

[0175] (Configuration of Intra Prediction Parameter Derivation Unit) Based on the input from the parameter decoding unit 302, the intra prediction parameter derivation unit refers to the prediction parameters stored in the prediction parameter memory 307 to derive intra prediction parameters, for example, to derive the intra prediction mode IntraPredMode. The intra prediction parameter derivation unit outputs the intra prediction parameters to the prediction image generation unit 308 and stores them in the prediction parameter memory 307. The intra prediction parameter derivation unit may derive different intra prediction modes for luminance and color difference.

[0176] The loop filter 305 is a filter provided within the encoding loop, which is a filter for removing block distortion and ringing distortion and improving the image quality. The loop filter 305 performs filtering such as a deblocking filter, sample adaptive offset (SAO), adaptive loop filter (ALF), etc. on the decoded image of the CU generated by the addition unit 312.

[0177] The reference picture memory 306 stores the decoded image of the CU at a predetermined position for each target picture and target CU.

[0178] The prediction parameter memory 307 stores the prediction parameters at a predetermined position for each CTU or CU. Specifically, the prediction parameter memory 307 stores the parameters decoded by the parameter decoding unit 302, the parameters derived by the prediction parameter derivation unit 320, etc.

[0179] ​​The prediction parameter derivation unit 320 derives the parameters that are input to the prediction image generation unit 308. Further, the prediction image generation unit 308 reads a reference picture from the reference picture memory 306. The prediction image generation unit 308 generates a prediction image of a block or a sub-block in the prediction mode indicated by predMode, using the parameters and the reference picture (reference pic ture block). Here, the reference picture block is a set of pixels on the reference picture (usually a rectangle, so it is called a block), and is an area referred to for generating a prediction image.

[0180] (Inter prediction image generation unit 309) When predMode indicates the inter prediction mode, the inter prediction image generation unit 309 generates a prediction image of a block or a sub-block by inter prediction, using the inter prediction parameters input from the inter prediction parameter derivation unit 303 and the reference picture. using the inter prediction parameters input from the inter prediction parameter derivation unit 303 and the reference picture to generate a prediction image of a block or a sub-block by inter prediction.

[0181] FIG. 11 is a schematic diagram showing the configuration of the inter prediction image generation unit 309 included in the prediction image generation unit 308 according to the present embodiment. The inter prediction image generation unit 309 includes a motion compensation unit (prediction image generation device position) 3091 and a synthesis unit 3095. The synthesis unit 3095 includes a weight prediction unit 3094.

[0182] (Motion compensation) The motion compensation unit 3091 (interpolation image generation unit 3091) is powered by the inter prediction parameter derivation unit 303, and based on the inter prediction parameters (predFlagLX, refIdxLX, mvLX), reads a reference block from the reference picture memory 306 to generate an interpolation image (motion compensation image). By reading a reference block from the reference picture memory 306, an interpolation image (motion compensation image) is It is generated. The reference block is the block at the position shifted by mvLX from the position of the target block on the reference picture RefPicLX specified by refIdxLX. Here, when mvLX does not have integer precision, a filter for generating pixels at fractional positions called a motion compensation filter is applied to generate an interpolated image.

[0183] The motion compensation unit 3091 first derives the integer position (xInt, yInt) and phase (xFrac, yFrac) corresponding to the coordinates (x, y) within the prediction block using the following equations.

[0184] xInt = xPb+(mvLX[0]>>(log2(MVPREC)))+x xFrac = mvLX[0]&(MVPREC-1) yInt = yPb+(mvLX[1]>>(log2(MVPREC)))+y yFrac = mvLX[1]&(MVPREC-1) Here, (xPb, yPb) is the upper left coordinate of a block of size bW*bH, where x = 0…bW-1 and y = 0…bH-1, and MVPREC indicates the precision of mvLX (1 / MVPREC pixel precision). For example, MVPREC = 16.

[0185] The motion compensation unit 3091 performs horizontal interpolation processing on the reference picture refImg using an interpolation filter to derive a temporary image temp[][]. The following Σ is the sum over k for k = 0..NTAP-1, shift1 is a normalization parameter for adjusting the value range, and offset1 = 1<<(shift1-1).

[0186] temp[x][y] = (ΣmcFilter[xFrac][k]*refImg[xInt+k-NTAP / 2+1][yInt]+offset1)>>shift1 Subsequently, the motion compensation unit 3091 derives an interpolated image Pred[][] from the temporary image temp[][] through vertical interpolation processing. The following Σ represents the sum with respect to k where k = 0..NTAP - 1, shift2 is a normalization parameter for adjusting the value range, and offset2 = 1 << (shift2 - 1).

[0187] Pred[x][y] = (ΣmcFilter[yFrac][k]*temp[x][y + k - NTAP / 2 + 1]+offset2)>>shift2 In the case of dual prediction, the above Pred[][] is derived for each of the L0 list and the L1 list (referred to as the interpolated images PredL0[][] and PredL1[]), and the interpolated image Pred[][] is generated from PredL0[][] and PredL1[]

[0188] The synthesis unit 3095 includes a weight prediction unit 3094.

[0189] (Weight Prediction) The weight prediction unit 3094 generates a predicted image of a block by multiplying the interpolated image PredLX by a weight coefficient. When one of the prediction list usage flags (predFlagL0 or predFlagL1) is 1 (single prediction) and weight prediction is not used, the following processing of the formula for adjusting PredLX (LX is L0 or L1) to the pixel bit depth bitDepth is performed.

[0190] Pred[x][y] = Clip3(0,(1<<bitDepth)-1,(PredLX[x][y]+offset1)>>shift1) Here, shift1 = 14 - bitDepth and offset1 = 1 << (shift1 - 1). Also, when both of the prediction list usage flags (predFlagL0 and predFlagL1) are 1 (dual prediction PRED_BI) and weight prediction is not used, the following processing of the formula for averaging PredL0 and PredL1 and adjusting to the pixel bit depth is performed.

[0191] Pred[x][y] = Clip3(0,(1<<bitDepth)-1,(PredL0[x][y]+PredL1[x][y]+offset2)>>shift2) Here, shift2 = 15 - bitDepth, and offset2 = 1<<(shift2 - 1).

[0192] Furthermore, when performing single prediction and weighted prediction, the weighted prediction unit 3094 derives the weighted prediction coefficient w0 and the offset o0 from the encoded data and performs the following equation processing.

[0193] Pred[x][y] = Clip3(0,(1<<bitDepth)-1,((PredLX[x][y]*w0+2^(log2WD - 1))>>log2WD)+o0) Here, log2WD is a variable indicating a predetermined shift amount.

[0194] Furthermore, when performing bi - prediction PRED_BI and weighted prediction, the weighted prediction unit 3094 derives the weighted prediction coefficients w0, w1, o0, and o1 from the encoded data and performs the following equation processing.

[0195] Pred[x][y] = Clip3(0,(1<<bitDepth)-1,(PredL0[x][y]*w0+PredL1[x][y]*w1+((o0+o1+1)<<log2WD))>>(log2WD + 1)) The inter - prediction image generation unit 309 outputs the predicted image of the generated block to the addition unit 312.

[0196] (Intra - prediction image generation unit) When predMode indicates the intra - prediction mode, the intra - prediction image generation unit performs intra - prediction using the intra - prediction parameters input from the intra - prediction parameter derivation unit and the reference pixels read from the reference picture memory 306. performs intra - prediction using the intra - prediction parameters input from the intra - prediction parameter derivation unit and the reference pixels read from the reference picture memory 306.

[0197] The inverse quantization and inverse transformation unit 311 inverse quantizes the quantization conversion coefficients input from the parameter decoding unit 302 to obtain the conversion coefficients.

[0198] The addition unit 312 adds the predicted image of the block input from the predicted image generation unit 308 and the prediction error input from the inverse quantization and inverse transformation unit 311 for each pixel to generate the decoded image of the block. The addition unit 312 stores the decoded image of the block in the reference picture memory 306 and outputs it to the loop filter 305.

[0199] (Configuration of the moving image encoding device) Next, the configuration of the moving image encoding device 11 according to the present embodiment will be described. FIG. 12 is a block diagram showing the configuration of the moving image encoding device 11 according to the present embodiment. The moving image encoding device 11 includes a predicted image generation unit 101, a subtraction unit 102, a conversion and quantization unit 103, an inverse quantization and inverse transformation unit 105, an addition unit 106, a loop filter 107, a prediction parameter memory (prediction parameter storage unit, frame memory) 108, a reference picture memory (reference image storage unit, frame memory) 109, an encoding parameter determination unit 110, a parameter encoding unit 111, a prediction parameter derivation unit 120, and an entropy encoding unit 104.

[0200] The predicted image generation unit 101 generates a predicted image for each CU. The predicted image generation unit 101 includes the inter-predicted image generation unit 309 and the intra-predicted image generation unit that have already been described, and the description thereof is omitted.

[0201] The subtraction unit 102 subtracts the pixel value of the predicted image of the block input from the predicted image generation unit 101 from the pixel value of the image T to generate a prediction error. The subtraction unit 102 outputs the prediction error to the conversion and quantization unit 103.

[0202] The conversion and quantization unit 103 calculates conversion coefficients by frequency conversion for the prediction error input from the subtraction unit 102, and derives quantization conversion coefficients by quantization. The conversion and quantization unit 103 The quantized transform coefficients are output to the parameter coding unit 111 and the inverse quantization and inverse transform unit 105 .

[0203] The inverse quantization and inverse transform unit 105 is the same as the inverse quantization and inverse transform unit 311 (FIG. 7) in the video decoding device 31. The calculated prediction error is output to the adder 106.

[0204] The parameter coding unit 111 includes a header coding unit 1110, a CT information coding unit 1111, and a CU coding unit 1112 (prediction mode coding unit). The CU coding unit 1112 further includes a TU coding unit 1114. The following describes an outline of the operation of each module.

[0205] The header encoding unit 1110 performs encoding processing of parameters such as header information, division information, prediction information, and quantized transform coefficients.

[0206] The CT information encoding unit 1111 encodes QT, MT (BT, TT) division information and the like.

[0207] The CU encoding unit 1112 encodes CU information, prediction information, division information, and the like.

[0208] When a prediction error is included in a TU, the TU encoding unit 1114 encodes the QP update information and the quantized prediction error.

[0209] The CT information encoding unit 1111 and the CU encoding unit 1112 supply syntax elements such as inter-prediction parameters (predMode, merge_flag, merge_idx, inter_pred_idc, refIdxLX, mvp_LX_idx, mvdLX), intra-prediction parameters (intra_luma_mpm_flag, intra_luma_mpm_idx, intra_luma_mpm_reminder, intra_chroma_pred_mode), and quantized transform coefficients to the parameter encoding unit 111.

[0210] The entropy encoding unit 104 receives the quantized transform coefficients and encoding parameters (partition information, prediction parameters) from the parameter encoding unit 111. The entropy encoding unit 104 entropy-encodes these to generate and output an encoded stream Te.

[0211] The prediction parameter derivation unit 120 is a means including an inter-prediction parameter encoding unit 112 and an intra-prediction parameter encoding unit, and derives intra-prediction parameters and intra-prediction parameters from the parameters input from the encoding parameter determination unit 110. The derived intra-prediction parameters and intra-prediction parameters are output to the parameter encoding unit 111 and.

[0212] (Configuration of the inter-prediction parameter encoding unit) The merge candidate derivation unit according to one aspect of the present invention includes the above-described NASMVP merge candidate derivation unit, and when the sps_nnmvp_enabled_flag notified in the SPS is set to 1, uses the NASMVP merge candidate derivation unit to derive merge candidates. The sps_nnmvp_enabled_flag is a flag indicating whether to use the NASMVP mode.

[0213] As shown in FIG. 13, the inter-prediction parameter encoding unit 112 includes a parameter encoding control unit 1121 and an inter-prediction parameter derivation unit 303. The inter-prediction parameter derivation unit 303 has a configuration common to the moving image decoding device. The parameter encoding control unit 1121 includes a merge index derivation unit 11211 and a vector candidate index derivation unit 11212.

[0214] The merge index derivation unit 11211 derives merge candidates and the like, and outputs them to the inter-prediction parameter derivation unit 303. The vector candidate index derivation unit 11212 derives prediction vector candidates and the like, and outputs them to the inter-prediction parameter derivation unit 303 and the parameter encoding unit 111.

[0215] (Configuration of Intra Prediction Parameter Encoding Unit) The intra prediction parameter encoding unit includes a parameter encoding control unit and an intra prediction parameter derivation unit. The intra prediction parameter derivation unit has the same configuration as the moving image decoding device.

[0216] However, different from the moving image decoding device, the input to the inter prediction parameter derivation unit 303 and the intra prediction The input to the parameter derivation unit is the encoding parameter determination unit 110 and the prediction parameter memory 108, and outputs to the parameter encoding unit 111.

[0217] The addition unit 106 adds the pixel values of the prediction block input from the prediction image generation unit 101 and the prediction error input from the inverse quantization / inverse transformation unit 105 for each pixel to generate a decoded image. The addition unit 106 stores the generated decoded image in the reference picture memory 109.

[0218] The loop filter 107 performs a deblocking filter, SAO, and ALF on the decoded image generated by the addition unit 106. Note that the loop filter 107 does not necessarily include the above three types of filters and may be configured with only the deblocking filter, for example.

[0219] The prediction parameter memory 108 stores the prediction parameters generated by the encoding parameter determination unit 110 at positions determined in advance for each target picture and CU.

[0220] The reference picture memory 109 stores the decoded image generated by the loop filter 107 at positions determined in advance for each target picture and CU.

[0221] The encoding parameter determination unit 110 selects one set from a plurality of sets of encoding parameters Select the encoding parameters. The encoding parameters are the QT, BT, or TT splitting information, prediction parameters, or parameters to be encoded generated in relation to these, as described above. The prediction image generation unit 101 generates a prediction image using these encoding parameters.

[0222] The encoding parameter determination unit 110 calculates the RD cost value indicating the amount of information and the encoding error for each of the plurality of sets. The RD cost value is, for example, the sum of the amount of code and the value obtained by multiplying the squared error by a coefficient λ. The amount of code is the amount of information of the encoded stream Te obtained by entropy encoding the quantization error and the encoding parameters. The squared error is the sum of the squares of the prediction errors calculated in the subtraction unit 102. The coefficient λ is a real number greater than zero set in advance. The encoding parameter determination unit 110 selects the set of encoding parameters that minimizes the calculated cost value. The encoding parameter determination unit 110 outputs the determined encoding parameters to the parameter encoding unit 111 and the prediction parameter derivation unit 120. Note that a part of the moving image encoding device 11 and the moving image decoding device 31 in the above-described embodiment, for example, the entropy decoding unit 301, the parameter decoding unit 302, the loop filter 305, the prediction image generation

[0223] unit 101, etc., may be implemented by a CPU, a GPU, or a dedicated circuit. Part 308, inverse quantization and inverse transformation unit 311, addition unit 312, prediction parameter derivation unit 320, predicted image generation unit 101, subtraction unit 102, transformation and quantization unit 103, entropy encoding unit 104, inverse quantization and inverse transformation unit 105, loop filter 107, encoding parameter determination unit 110, parameter encoding unit 111, and prediction parameter derivation unit 120 may be realized by a computer. In that case, a program for realizing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read into a computer system and executed to realize it. Here, the "computer system" refers to a computer system built into either the moving image encoding device 11 or the moving image decoding device 31, and includes hardware such as an OS and peripheral devices. Also, the "computer-readable recording medium" refers to portable media such as flexible disks, magneto-optical disks, ROMs, CD-ROMs, and storage devices such as hard disks built into a computer system. Furthermore, the "computer-readable recording medium" also includes those that hold a program dynamically for a short time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and those that hold a program for a certain time, such as volatile memory inside a computer system serving as a server or a client in that case. Also, the above program may be for realizing a part of the functions described above, and may further be realizable in combination with a program already recorded in a computer system for realizing the functions described above.

[0224] Further, part or all of the moving image encoding device 11 and the moving image decoding device 31 in the above-described embodiment may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each functional block of the moving image encoding device 11 and the moving image decoding device 31 may be individually processed by a processor, or part or all of them may be integrated and processed by a processor. Further, the method of integrating into a circuit is not limited to an LSI, and may be realized by a dedicated circuit or a general-purpose processor. Also, when a circuit integration technology that replaces an LSI appears due to the progress of semiconductor technology, an integrated circuit using such technology may be used.

[0225] As described above, an embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist of the present invention.

[0226] 〔Application Example〕 The above-described moving image encoding device 11 and moving image decoding device 31 can be mounted and used in various devices that transmit, receive, record, and play back moving images. The moving image may be a natural moving image captured by a camera or the like, or an artificial moving image (including CG and GUI) generated by a computer or the like.

[0227] First, the fact that the above-described moving image encoding device 11 and moving image decoding device 31 can be used for transmitting and receiving moving images will be described with reference to FIG. 2.

[0228] FIG. 2(a) is a block diagram showing the configuration of a transmission device PROD_A equipped with the moving image encoding device 11. As shown in the figure, the transmission device PROD_A includes an encoding unit PROD_A1 that obtains encoded data by encoding a moving image, a modulation unit PROD_A2 that obtains a modulation signal by modulating a carrier wave with the encoded data obtained by the encoding unit PROD_A1, and a transmission unit PROD_A3 that transmits the modulation signal obtained by the modulation unit PROD_A2. The above-described moving image encoding device 11 is used as this encoding unit PROD_A1.

[0229] As a source of the moving image input to the encoding unit PROD_A1, the transmission device PROD_A further includes a camera PROD_A4 that captures the moving image, a recording medium PROD_A5 that records the moving image, an input terminal PROD_A6 for externally inputting the moving image, and an image processing unit A7 that generates or processes an image. This is also acceptable. In the figure, a configuration in which the transmission device PROD_A includes all of these is illustrated, but some of them may be omitted. Note that the recording medium PROD_A5 may record a non-encoded moving image, or may record a moving image encoded by a recording encoding method different from the transmission encoding method. In the latter case, a decoding unit (not shown) for decoding the encoded data read from the recording medium PROD_A5 according to the recording encoding method may be interposed between the recording medium PROD_A5 and the encoding unit PROD_A1.

[0230] Note that the recording medium PROD_A5 may record a non-encoded moving image, or may record a moving image encoded by a recording encoding method different from the transmission encoding method. In the latter case, a decoding unit (not shown) for decoding the encoded data read from the recording medium PROD_A5 according to the recording encoding method may be interposed between the recording medium PROD_A5 and the encoding unit PROD_A1. It is advisable to interpose such a decoding unit (not shown).

[0231] FIG. 2(b) is a block diagram showing the configuration of the receiving device PROD_B equipped with the moving image decoding device 31. As shown in the figure, the receiving device PROD_B includes a receiving unit PROD_B1 that receives a modulated signal, a demodulating unit PROD_B2 that obtains encoded data by demodulating the modulated signal received by the receiving unit PROD_B1, and a decoding unit PROD_B3 that obtains a moving image by decoding the encoded data obtained by the demodulating unit PROD_B2. The above-described moving image decoding device 31 is used as this decoding unit PROD_B3. The receiving device PROD_B may further include a display PROD_B4 that displays the moving image, a recording medium PROD_B5 for recording the moving image, and an output terminal PROD_B6 for outputting the moving image externally, as destinations for the moving image output by the decoding unit PROD_B3. In the figure, all of these are shown. .

[0232] As destinations for the moving image output by the decoding unit PROD_B3, the receiving device PROD_B may further include a display PROD_B4 that displays the moving image, a recording medium PROD_B5 for recording the moving image, and an output terminal PROD_B6 for outputting the moving image externally. In the figure, all of these are shown. Although an example of a configuration in which the receiving device PROD_B is provided is illustrated, some parts may be omitted.

[0233] Note that the recording medium PROD_B5 is for recording an unencoded moving image or may be encoded using a recording encoding method different from the transmission encoding method. In the latter case, between the decoding unit PROD_B3 and the recording medium PROD_B5, from the decoding unit PROD_B3 it is preferable to interpose an encoding unit (not shown) that encodes the acquired moving image according to the recording encoding method.

[0234] Note that the transmission medium for transmitting the modulation signal may be wireless or wired. Also, the transmission mode for transmitting the modulation signal may be broadcast (here, it refers to a transmission mode in which the transmission destination is not specified in advance) or communication (here, it refers to a transmission mode in which the transmission destination is specified in advance). That is, the transmission of the modulation signal may be realized by any of terrestrial digital broadcast, cable broadcast, wireless communication, and wired communication.

[0235] For example, a broadcast station (broadcast equipment, etc.) / reception station (television receiver, etc.) of terrestrial digital broadcast is an example of the transmission device PROD_A / receiving device PROD_B that transmits and receives a modulation signal by wireless broadcast. Also, a broadcast station (broadcast equipment, etc.) / reception station (television receiver, etc.) of cable television broadcast is an example of the transmission device PROD_A / receiving device PROD_B that transmits and receives a modulation signal by wired broadcast.

[0236] In addition, servers (such as workstations) / clients (such as television receivers, personal computers, smartphones, etc.) for VOD (Video On Demand) services and video sharing services using the Internet are examples of a transmission device PROD_A / a reception device PROD_B that transmits and receives a modulated signal through communication (usually, either wireless or wired is used as a transmission medium in a LAN, and wired is used as a transmission medium in a WAN). Here, personal computers include desktop PCs, laptop PCs, and tablet PCs. In addition, smartphones include multifunctional mobile phone terminals.

[0237] Note that in addition to the function of decoding the encoded data downloaded from the server and displaying it on the display, the client of the video sharing service has a function of encoding the moving image captured by the camera and uploading it to the server. That is, the client of the video sharing service functions as both the transmission device PROD_A and the reception device PROD_B.

[0238] Next, the fact that the above-described moving image encoding device 11 and moving image decoding device 31 can be used for recording and playing back moving images will be described with reference to FIG. 3.

[0239] FIG. 3(a) is a block diagram showing the configuration of a recording device PROD_C equipped with the above-described moving image encoding device 11. As shown in the figure, the recording device PROD_C includes an encoding unit PROD_C1 that obtains encoded data by encoding a moving image, and a writing unit PROD_C2 that writes the encoded data obtained by the encoding unit PROD_C1 to a recording medium PROD_M. The above-described moving image encoding device 11 is used as this encoding unit PROD_C1.

[0240] Note that the recording medium PROD_M may be of a type built into the recording device PROD_C, such as (1) an HDD (Hard Disk Drive) or an SSD (Solid State Drive), or (2) a type connected to the recording device PROD_C, such as an SD memory card or a USB (Universal Serial Bus) flash memory, or (3) a type loaded into a drive device (not shown) built into the recording device PROD_C, such as a DVD (Digital Versatile Disc: registered trademark) or a BD (Blu-ray Disc: registered trademark).

[0241] Also, the recording device PROD_C may further include a camera PROD_C3 that captures a moving image, an input terminal PROD_C4 for inputting a moving image from the outside, a receiving unit PROD_C5 for receiving a moving image, and an image processing unit PROD_C6 for generating or processing an image, as a source of the moving image input to the encoding unit PROD_C1. In the figure, a configuration in which the recording device PROD_C includes all of these is illustrated, but some of them may be omitted. Note that the receiving unit PROD_C5 may receive an unencoded moving image or may receive encoded data encoded by a transmission encoding method different from the encoding method for recording. In the latter case, a transmission decoding unit (not shown) for decoding the encoded data encoded by the transmission encoding method may be interposed between the receiving unit PROD_C5 and the encoding unit PROD_C1.

[0242]

[0243] ​​Examples of such a recording device PROD_C include a DVD recorder, a BD recorder, an HDD (Hard Disk Drive) recorder, etc. (in this case, the input terminal PROD_C4 or the receiving unit PROD_C5 serves as the main source of the moving image). Also, a camcorder (in this case, the camera PROD_C3 serves as the main source of the moving image), a personal computer (in this case, the receiving unit PROD_C5 or the image processing unit C6 serves as the main source of the moving image), a smartphone (in this case, the camera PROD_C3 or the receiving unit PROD_C5 serves as the main source of the moving image), etc. are also examples of such a recording device PROD_C.

[0244] Figure 3(b) is a block diagram showing the configuration of a playback device PROD_D equipped with the above-described moving image decoding device 31. As shown in the figure, the playback device PROD_D includes a reading unit PROD_D1 that reads the encoded data written on the recording medium PROD_M, and a decoding unit PROD_D2 that obtains a moving image by decoding the encoded data read by the reading unit PROD_D1. The above-described moving image decoding device 31 is used as this decoding unit PROD_D2.

[0245] Note that the recording medium PROD_M may be of a type built into the playback device PROD_D, such as an HDD or an SSD, (2) may be of a type connected to the playback device PROD_D, such as an SD memory card or a USB flash memory, or (3) may be loaded into a drive device (not shown) built into the playback device PROD_D, such as a DVD or a BD.

[0246] Also, the playback device PROD_D may further include a display PROD_D3 that displays the moving image, an output terminal PROD_D4 for outputting the moving image externally, and a transmitting unit PROD_D5 for transmitting the moving image, as destinations for the moving image output by the decoding unit PROD_D2. In the figure, all of these are shown. Although the configuration of the playback device PROD_D is illustrated, some parts may be omitted.

[0247] Note that the transmission unit PROD_D5 may transmit unencoded moving images, or it may transmit encoded data encoded by an encoding method for transmission different from the encoding method for recording. In the latter case, an encoding unit (not shown) for encoding the moving image by the encoding method for transmission may be interposed between the decoding unit PROD_D2 and the transmission unit PROD_D5.

[0248] Examples of such a playback device PROD_D include a DVD player, a BD player, an HDD player, etc. (in this case, the output terminal PROD_D4 to which a television receiver or the like is connected becomes the main supply destination of the moving image). Also, a television receiver (in this case, the display PROD_D3 becomes the main supply destination of the moving image), digital signage (also referred to as an electronic billboard or an electronic bulletin board, etc., and the display PROD_D3 or the transmission unit PROD_D5 becomes the main supply destination of the moving image), a desktop PC (in this case, the output terminal PROD_D4 or the transmission unit PROD_D5 becomes the main supply destination of the moving image), a laptop or tablet PC (in this case, the display PROD_D3 or the transmission unit PROD_D5 becomes the main supply destination of the moving image), a smartphone (in this case, the display PROD_D3 or the transmission unit PROD_D5 becomes the main supply destination of the moving image), etc. are also examples of such a playback device PROD_D.

[0249] (Hardware implementation and software implementation) Also, each block of the above-described moving image decoding device 31 and moving image encoding device 11 may be implemented hardware-wise by a logic circuit formed on an integrated circuit (IC chip), or it may be implemented software-wise using a CPU (Central Processing Unit).

[0250] In the latter case, each of the above devices includes a CPU that executes instructions of a program for realizing each function, the above ROM (Read Only Memory) that stores the program, RAM (Random Access Memory) that expands the program, a storage device (recording medium) such as a memory that stores the program and various data, and the like. And the object of the embodiment of the present invention is to supply a recording medium in which program codes (executable format programs, intermediate code programs, source programs) of the control programs of the above devices, which are software for realizing the above-described functions, are recorded in a computer-readable manner to each of the above devices, and the computer (or CPU or MPU) reads and executes the program codes recorded on the recording medium, which can also achieve the object.

[0251] As the above recording medium, for example, tapes such as magnetic tapes and cassette tapes, magnetic disks such as floppy (registered trademark) disks / hard disks, and disks including optical disks such as CD-ROM (Compact Disc Read-Only Memory) / MO disks (Magneto-Optical disc) / MD (Mini Disc) / DVD (Digital Versatile Disc: registered trademark) / CD-R (CD Recordable) / Blu-ray Disc (Blu-ray Disc: registered trademark), cards such as IC cards (including memory cards) / optical cards, semiconductor memories such as mask ROM / EPROM (Erasable Programmable Read-Only Memory) / EEPROM (Electrically Erasable and Programmable Read-Only Memory: registered trademark) / flash ROM, or logic circuits such as PLD (Programmable logic device) and FPGA (Field Programmable Gate Array) can be used.

[0252] Further, each of the above devices may be configured to be connectable to a communication network, and the above program code may be supplied via the communication network. This communication network only needs to be capable of transmitting the program code and is not particularly limited. For example, the Internet, intranet, extranet, LAN (Local Area Network), ISDN (Integrated Services Digital Network), VAN (Value-Added Network), CATV (Community Antenna television / Cable Television) communication network, virtual private network, telephone line network, mobile communication network, satellite communication network, etc. can be used. Also, the transmission medium constituting this communication network only needs to be a medium capable of transmitting the program code and is not limited to a specific configuration or type. For example, it can be wired such as IEEE (Institute of Electrical and Electronic Engineers) 1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line, etc., or wireless such as infrared rays like IrDA (Infrared Data Association) and remote controls, Bluetooth (registered trademark), IEEE802.11 wireless, HDR (High Data Rate), NFC (Near Field Communication), DLNA (Digital Living Network Alliance: registered trademark), mobile phone network, satellite line, terrestrial digital broadcast network, etc. Note that the embodiments of the present invention can also be realized in the form of a computer data signal embedded in a carrier wave in which the above program code is embodied by electronic transmission.

[0253] The embodiments of the present invention are not limited to the above-described embodiments, and various modifications are possible within the scope shown in the claims. That is, embodiments obtained by combining technical means appropriately modified within the scope shown in the claims are also included in the technical scope of the present invention.

Industrial Applicability

[0254] Embodiments of the present invention can be suitably applied to a moving image decoding apparatus that decodes encoded data in which image data is encoded, and a moving image encoding apparatus that generates encoded data in which image data is encoded. Further, it can be suitably applied to the data structure of the encoded data generated by the moving image encoding apparatus and referred to by the moving image decoding apparatus.

Explanation of Signs

[0255] 31 Image decoding apparatus 301 Entropy decoding unit 302 Parameter decoding unit 303 Inter prediction parameter derivation unit 305, 107 Loop filter 306, 109 Reference picture memory 307, 108 Prediction parameter memory 308, 101 Predicted image generation unit 309 Inter predicted image generation unit 311, 105 Inverse quantization and inverse transform unit 312, 106 Addition unit 320 Prediction parameter derivation unit 11 Image encoding apparatus 102 Subtraction unit 103 Transform and quantization unit 104 Entropy encoding unit 110 Encoding parameter determination unit 111 Parameter encoding unit 112 Inter prediction parameter encoding unit 120 Prediction parameter derivation unit

Claims

1. In a merge candidate derivation device that derives a merge candidate for a target block based on motion vectors of spatial blocks and collocate blocks around the target block, comprising a non-adjacent merge candidate derivation unit that derives a merge candidate using motion vectors of non-adjacent blocks that are not adjacent to the target block, the non-adjacent merge candidate derivation unit derives a merge candidate for one of the non-adjacent blocks in each of a plurality of groups composed of non-adjacent blocks that are not adjacent to the target block, and sets it in a merge candidate list, and is characterized in that it is a merge candidate derivation device.

2. The non-adjacent merge candidate derivation unit derives the merge candidate using pruning for checking whether motion vectors are close from the group, When setting the merge candidate of the non-adjacent block in the merge candidate list, the merge candidate derivation device according to claim 1, wherein the merge candidate is set in the merge candidate list without using the pruning.

3. Each of the plurality of groups composed of the non-adjacent blocks is grouped according to the direction from the target block, and is at least a group in the upper, upper right, left, lower left, and upper left directions of the target block, and is characterized in that it is a merge candidate derivation device according to claim 1 or 2.

4. Each of the plurality of groups composed of the non-adjacent blocks is grouped according to the distance from the target block, and is at least a group separated from the target block by a first distance and a group separated by a second distance, and is characterized in that it is a merge candidate derivation device according to claim 1 or 2.

5. The non-adjacent merge candidate derivation unit derives a merge candidate for the non-adjacent block when the size of the target block is equal to or less than a predetermined size, The merge candidate derivation device according to any one of claims 1 to 4, wherein when the size of the target block is larger than the predetermined size, a merge candidate for the non-adjacent block is not derived.

6. Comprising a non-adjacent merge candidate derivation unit that derives the merge candidate using motion vectors of non-adjacent blocks of the collocate block, The non-adjacent merge candidate derivation unit derives a temporal merge candidate from a position at the lower right and a central position of an encoded tree unit including a target collocate block, and is characterized in that it is a merge candidate derivation device according to claim 1.

7. A non-adjacent merge candidate derivation unit according to any one of claims 1 to 6, a prediction image generation unit that generates a prediction image using a prediction parameter derived from the non-adjacent merge candidate derivation unit and a reference image stored in a reference picture memory, wherein the moving image decoding apparatus is characterized by comprising:

8. A non-adjacent merge candidate derivation unit according to any one of claims 1 to 6, a prediction image generation unit that generates a prediction image using a prediction parameter derived from the non-adjacent merge candidate derivation unit and a reference image stored in a reference picture memory, wherein the moving image encoding apparatus is characterized by comprising:

Images