Moving image decoding device and moving image encoding device

The video decoding device addresses the high computational burden of convolutional models in video coding by deriving prediction parameters from adjacent blocks and applying them to reduce computational complexity, thereby enhancing decoding efficiency.

JP2025055374APending Publication Date: 2025-04-08SHARP KK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2023164676
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-27
Publication Date
2025-04-08

AI Technical Summary

Technical Problem

Existing video coding methods that use convolutional models for predicting images and residual images face a significant challenge in managing the large amount of computation required to derive parameters for these models.

Method used

A video decoding device is designed with a prediction parameter derivation unit that uses prediction parameters from adjacent blocks to derive inter-color components prediction parameters, and a prediction filter unit that applies these parameters to generate output images using an inter-color component prediction model.

Benefits of technology

This approach effectively suppresses the increase in computational complexity even when convolutional operation models are used, enhancing the efficiency of video decoding processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025055374000001_ABST
    Figure 2025055374000001_ABST
Patent Text Reader

Abstract

To solve the problem that, in a conventional encoding system for predicting a predictive image or a residual image according to a convolution model between color components, computational complexity may be increased because of parameter derivation of the convolution model.SOLUTION: A moving image decoding device comprises: a prediction parameter derivation section for deriving a prediction parameter between color components; and a predictive filter section for generating an output image by applying the prediction model between color components using the derived prediction parameter to an input image. The prediction parameter of an adjacent block is used to derive the prediction parameter and generate the output image from the input image.SELECTED DRAWING: Figure 9
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] An embodiment of the present invention relates to a video decoding device and a video encoding device. [Background technology]

[0002] In order to efficiently transmit or record moving images, a moving image encoding device is used that generates encoded data by encoding moving images, and a moving image decoding device is used that generates a decoded image by decoding the encoded data.

[0003] Specific examples of video coding methods include the methods proposed in H.264 / AVC and High-Efficiency Video Coding (HEVC).

[0004] In such a video coding method, images (pictures) constituting a video are divided into slices obtained by dividing the images, coding tree units (CTUs) obtained by dividing the slices, coding tree units (CTUs) obtained by dividing the coding tree units, and so on. The coding unit (sometimes called a coding unit (CU)) that is to be encoded, and The coding unit is divided into transform units (TUs), which are managed in a hierarchical structure, and the coding unit is encoded / decoded for each CU.

[0005] In such a video coding method, a predicted image is usually generated based on a locally 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 predicted image from the input image (original image) is coded. Methods for generating a predicted image include inter-prediction and intra-prediction.

[0006] Recent video encoding and decoding techniques include Non-Patent Document 1 and Non-Patent Document 2. Non-Patent Document 1 discloses inter-color component convolution operation model prediction, in which a chrominance predicted image is predicted from a luminance predicted image by a convolution operation model. Non-Patent Document 2 discloses inter-color component residual model prediction, in which a chrominance pixel residual is predicted by a model based on a convolution operation using a luminance pixel residual. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] "AHG12: Convolutional cross-component model (CCCM) for intraprediction", Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, JVET-Z0064, 2022 [Non-Patent Document 2] "AHG12: Cross-component residual model (CCRM) for inter prediction", Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC1 / SC 29 / WG 11, JVET-AD0108, 2023 Summary of the Invention [Problem to be solved by the invention]

[0008] In the coding method for predicting a predicted image or a residual image based on a convolution model between color components as in Non-Patent Documents 1 and 2, there is a problem that the amount of calculation required to derive parameters of the convolution calculation model is large.

[0009] An object of the present invention is to suppress an increase in the amount of calculation even when a convolution calculation model is used. [Means for solving the problem]

[0010] In order to solve the above problem, a video decoding device according to one embodiment of the present invention is a video decoding device that includes a prediction parameter derivation unit that derives inter-color component prediction parameters, and a prediction filter unit that applies an inter-color component prediction model using the derived prediction parameters to an input image to generate an output image, and is characterized in that the prediction parameters are derived using prediction parameters of adjacent blocks to generate an output image from the input image. Effect of the Invention

[0011] According to one aspect of the present invention, an increase in the amount of calculation can be suppressed even when a convolution calculation model is used. [Brief description of the drawings]

[0012] [Figure 1] 1 is a schematic diagram showing a configuration of an image transmission system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram showing a hierarchical structure of data in an encoded stream. [Diagram 3] FIG. 13 is a schematic diagram showing types of intra-prediction modes (mode numbers). [Figure 4] FIG. 1 is a schematic diagram showing a configuration of a video decoding device. [Diagram 5] FIG. 2 is a schematic diagram showing a configuration of an intra-prediction image generating unit. [Figure 6] FIG. 13 is a schematic diagram showing a configuration of an inter-prediction image generating unit. [Figure 7] 1 is a syntax table showing the syntax of intra prediction parameters. [Figure 8] 13 is a syntax table showing the syntax of inter prediction parameters. [Figure 9] FIG. 2 is a schematic diagram showing a configuration of a CCxM prediction unit. [Figure 10] 1 is a schematic diagram showing a configuration of a CCCM prediction unit. [Figure 11] FIG. 2 is a schematic diagram showing a configuration of a CCRM prediction unit. [Figure 12] 13 is a schematic diagram showing another configuration of the CCCM prediction unit. [Figure 13] FIG. 13 is a schematic diagram showing another configuration of the CCRM prediction unit. [Figure 14] FIG. 1 is a block diagram showing a configuration of a video encoding device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] (First embodiment) Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0014] FIG. 1 is a schematic diagram showing the configuration of an image transmission system 1 according to this embodiment.

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

[0016] An image T is input to the video encoding device 11 .

[0017] The network 21 transmits the encoded stream Te generated by the video encoding device 11 to the video decoding device 31. The network 21 may be the Internet, a wide area network (WAN), a local area network (LAN), or any of these. The network 21 is not necessarily limited to a two-way communication network, but may be a one-way communication network that transmits broadcast waves such as terrestrial digital broadcasting and satellite broadcasting. The network 21 may also be a network that transmits DVD (Digital Versatile Disc: registered trademark), BD (Blu-ray Disc: registered trademark), It may be replaced with a storage medium that records an encoded stream Te such as this.

[0018] 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 that have been decoded.

[0019] The moving image display device 41 displays all or part of the one or more decoded images Td generated by the moving image decoding device 31. The moving 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, an HMD, etc. Also, when the moving image decoding device 31 has high processing power it displays an image with high image quality, and when it has only lower processing power, it displays an image that does not require high processing power and display capabilities.

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

[0021] >> is a right bit shift, << is a left bit shift, & is a bitwise AND, | is a bitwise OR ^ is a bitwise XOR (exclusive OR), |= is an OR assignment operator,! is a logical negation (NOT), && is a logical AND, and || is a logical OR.

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

[0023] Clip3(a, b, c) is a function that clips c to a value between a and b. When c < a, it returns a, when c > b, it returns b, and in other cases, it returns c (however, a <= b).

[0024] Clip1Y(c) is an operator where in Clip3(a, b, c), a = 0 and b = (1 << BitDepthY) - 1 are set. BitDepthY is the bit depth of luminance.

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

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

[0027] Log2(a) is a function that returns the logarithm to the base 2 of a.

[0028] Ceil(a) is a function that returns the smallest integer greater than or equal to a.

[0029] Round(a) is a function that returns an integer close to a by rounding.

[0030] Int(a) is a function that returns the integer value of a. It may also be Round, Floor, or Ceil.

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

[0032] Min(a, b) is a function that returns the smaller value of a and b.

[0033] <Structure of the encoded stream Te> Prior to the detailed description of the moving image encoding device 11 and the moving image decoding device 31 according to this 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.

[0034] Figure 2 is a diagram showing the hierarchical structure of the data in the encoded stream Te. The encoded stream Te illustratively includes a sequence and a plurality of pictures that make up the sequence. In Figure 2, there is an encoded video sequence that defines the sequence SEQ, and a picture PICT respectively. a coded picture that specifies a slice S, a coded slice that specifies slice data coding slice data to be determined; coding tree units included in the coding slice data; A diagram showing coding units contained in a coding tree unit is shown.

[0035] (Coded Video Sequence) In the case of a coded video sequence, a video decoder is used to decode the sequence SEQ to be processed. A set of data to which the device 31 refers is defined. The sequence SEQ is the encoded video sequence of FIG. As shown in the sequence, the video parameter set includes a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a picture PICT, and supplemental enhancement information (SEI).

[0036] The video parameter set VPS is used to determine the number of layers of a video image. A set of coding parameters common to multiple video images and a set of coding parameters related to multiple layers and individual layers included in the video images are defined.

[0037] The sequence parameter set SPS is used to decode the target sequence. A set of coding parameters to be referenced by the PPS is specified. For example, the width and height of a picture are specified. Note that there may be multiple SPSs. In that case, one of the multiple SPSs can be selected from the PPS. Select .

[0038] The picture parameter set PPS specifies the number of pictures to be decoded for each picture in the target sequence. A set of coding parameters to be referred to by the video decoding device 31 is defined. For example, the reference value of the quantization width (pic_init_qp_minus26) used for decoding a picture and the application of weighted prediction are defined. A flag (weighted_pred_flag) indicating the weighted pred is included. Note that there may be multiple PPSs. In this case, one of multiple PPSs is selected from each picture in the target sequence.

[0039] (Encoded Picture) The coded picture defines a set of data that the video decoding device 31 refers to in order to decode the picture PICT to be processed. As shown in the coded picture of FIG. 2, the picture PICT includes slices 0 to NS-1 (NS is the total number of slices included in the picture PICT). .

[0040] In the following, when there is no need to distinguish between slices 0 to NS-1, the symbols are The subscripts may be omitted in the description, and the same applies to other data to which subscripts are added that are included in the coded stream Te described below.

[0041] (Coded Slice) In the case of the coded slice, the video decoding device 31 refers to the slice S to be processed in order to decode the slice S. A slice includes a slice header and slice data, as shown in the coded slice of FIG.

[0042] The slice header includes a group of coding parameters to be referred to by the video decoding device 31 in order to determine a decoding method for the current slice. Slice type designation information (slice_type) that designates the slice type is an example of a coding parameter included in the slice header.

[0043] Slice types that can be specified by the slice type specification information include (1) an I slice that uses only intra prediction during encoding, (2) a P slice that uses unidirectional prediction or intra prediction during encoding, and (3) a B slice that uses unidirectional prediction, bidirectional prediction, or intra prediction during encoding. Note that inter prediction is not limited to uni-prediction or bi-prediction, and a predicted image may be generated using more reference pictures. Hereinafter, P When called a B slice, it is a slice that includes blocks that can use inter prediction. This refers to the s.

[0044] In addition, the slice header may include a reference to the picture parameter set PPS (pic_parameter_set_id).

[0045] (Encoded slice data) The coded slice data specifies a set of data to be referenced by the video decoding device 31 in order to decode the slice data to be processed. The slice data includes a CTU, as shown in the coded slice header in Fig. 2. A CTU is a block of a fixed size (e.g., 64x64) that constitutes a slice, and is also called a Largest Coding Unit (LCU).

[0046] (coding tree unit) In the coding tree unit of FIG. 2, a video decoder 31 is configured to decode a CTU to be processed. The set of data referenced by the CTU is specified. The CTU is divided into coding units CU, which are the basic units of the coding process, by recursive quad tree (QT) division, binary tree (BT) division, or ternary tree (TT) division. The combination of quadtree partitioning and TT partitioning is called multi-tree partitioning (MT (Multi Tree) partitioning). A node in the tree structure obtained by recursive quadtree partitioning is called a coding node. The intermediate nodes of the quadtree, binary tree, and ternary tree are coding nodes, and the CTU itself is the top-level They are defined as coding nodes.

[0047] (Encoding Unit) As shown in the coding unit of Fig. 2, a set of data to be referenced by the video decoding device 31 in order to decode the coding unit to be processed is specified. Specifically, the CU is composed of a CU header CUH, prediction parameters, transformation parameters, quantization transformation coefficients, etc. The CU header includes A prediction mode, etc. are defined.

[0048] The prediction process may be performed in units of CUs, or in units of sub-CUs obtained by further dividing a CU. When the size of a CU and a sub-CU are equal, there is one sub-CU in the CU. When the size of a CU is larger than that of a sub-CU, the CU is divided into sub-CUs. For example, when a CU is 8x8 and a sub-CU is 4x4, the CU is divided into 2 parts horizontally and 2 parts vertically, into 4 sub-CUs.

[0049] There are two types of prediction (prediction modes): intra prediction and inter prediction. Intra prediction is a prediction within the same picture, while inter prediction refers to a prediction process performed between different pictures (for example, between display times or between layer images).

[0050] Transformation and quantization are performed in units of CUs, but quantization coefficients are stored in units of subblocks such as 4x4. It may be entropy coded.

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

[0052] The intra prediction parameters are composed of a luminance prediction mode IntraPredModeY and a color difference prediction mode IntraPredModeC. FIG. 3 is a schematic diagram showing types of intra prediction modes (mode numbers). As shown in the figure, there are, for example, 67 types (0 to 66) of intra prediction modes. For example, planar prediction (0), DC prediction (1), and angular prediction (2 to 66). In addition, linear models such as cross component linear model (CCLM) prediction and multi-mode linear model (MMLM) prediction are available as color difference prediction modes. Alternatively, a Convolutional Cross Component Model (CCCM) prediction may be used. Syntax elements for deriving parameters related to CCCM prediction include, for example, a CCCM flag cccm_flag, a CCCM merge flag cccm_merge_flag, a CCCM merge index cccm_merge_idx, and a CCCM filter index cccm_multi_flt_idx. The CCCM merge index cccm_merge_idx is coded only when CCCM merging is applied, and specifies the target to be merged. Note that the Convolutional Cross Component Model prediction is a prediction performed by the sum of products of input signals derived from multiple reference pixels around the target pixel and weighting coefficients (prediction parameters). Convolution is a process in which the positional relationship between the target pixel and the surrounding pixels (dxK, dyK) and the weighting coefficient (a described later) do not depend on the position of the target pixel. The input signal derived from the reference pixels may be simply a plurality of reference pixels themselves, or The input is not limited to the pixels around the target pixel, but may be any coordinate function. You can also input additional values ​​such as offset and shift values ​​for the prediction parameter a. It may include.

[0053] The inter prediction parameters are composed of prediction list use flags predFlagL0 and predFlagL1, reference picture indexes refIdxL0 and refIdxL1, and motion vectors mvL0 and mvL1. predFlagL0 and predFlagL1 are flags indicating whether or not a reference picture list (L0 list, L1 list) is used, and when the value is 1, the corresponding reference picture list is used. Note that in this specification, when the term "flag indicating whether or not XX" is used, a flag other than 0 (for example, 1) is XX, and 0 is not XX, and in logical negation, logical product, etc., 1 is treated as true and 0 is treated as false (similar below). However, in an actual device or method, other values ​​can also be used as true and false values.

[0054] Syntax elements for deriving inter prediction parameters include, for example, a merge flag merge_flag (general_merge_flag), a merge index merge_idx, merge_subblock_flag, regulare_merge_flag, ciip_flag, merge_gpm_partition_idx, merge_gpm_idx0, merge_gpm_idx1, inter_pred_idc, reference picture index refIdxLX, mvp_LX_idx, a difference There are vector mvdLX, motion vector precision mode amvr_mode. merge_subblock_flag is subblock A flag indicating whether to use block-based inter prediction. A flag indicating whether the normal merge mode or MMVD is used. ciip_flag is a flag indicating whether the CIIP (combined inter-picture merge and intra-picture prediction) mode is used. merge_gpm_partition_idx is an index indicating the partition shape in GPM mode. merge_gpm_idx0 and merge_gpm_idx1 are indexes indicating the merge index in GPM mode. inter_pred_idc is an inter prediction identifier for selecting a reference picture to be used in AMVP mode. mvp_LX_idx is a predicted vector index for deriving a motion vector. Cross-component residual model (CCRM) prediction may be used as an inter prediction mode. CCRM is a method of predicting chrominance prediction pixels using a model based on a convolution operation of luminance local decoded pixels. Syntax elements for deriving parameters related to CCRM used in inter prediction include, for example, a CCRM flag ccrm_flag, a CCRM merge flag ccrm_merge_flag, a CCRM merge index ccrm_merge_idx, and a CCRM filter index ccrm_multi_flt_idx. ccrm_flag is a flag indicating whether or not CCRM is applied to a color difference predicted image. The CCRM merge flag is a flag indicating whether or not a merge process is used when deriving CCRM parameters, and when CCRM is applied, Only the CCRM flag is coded. If the CCRM flag is false (0), the CCRM merge flag is false (0). The CCRM merge index ccrm_merge_idx is coded only when CCRM merge is applied, and specifies what to merge. The CCRM filter index ccrm_multi_flt_idx is an index that selects the filter to be applied to the input image when deriving a CCRM predicted image.

[0055] (Configuration of a video decoding device) The configuration of a video decoding device 31 (FIG. 4) according to this embodiment will be described.

[0056] The video decoding device 31 includes an entropy decoding unit 301, a parameter decoding unit (prediction image decoding device The image processing unit 302 includes a loop filter 305, a reference picture memory 306, a prediction parameter memory 307, a prediction image generating unit (prediction image generating device) 308, an inverse quantization and inverse transformation unit 311, and an adder 312. In addition, in accordance with a video encoding device 11 described later, the video decoding device 31 may have a configuration in which the loop filter 305 is not included.

[0057] Moreover, the parameter decoding unit 302 is configured to include an inter prediction parameter derivation unit 303 and an intra prediction parameter derivation unit 304. The predicted image generation unit 308 is configured to include an inter prediction image generation unit 309 and an intra prediction image generation unit 310.

[0058] In the following, we will describe an example in which CTU and CU are used as processing units, but this is not limiting. Alternatively, the processing may be performed in units of sub-CUs. The block may be replaced with a block, and processing may be performed in units of blocks or subblocks.

[0059] The entropy decoding unit 301 performs entropy decoding on the encoded stream Te input from the outside. Entropy coding is then performed to separate and decode the individual codes (syntax elements). There are two types of entropy coding: one is to variable-length code syntax elements using a context (probability model) that is adaptively selected according to the type of syntax element and the surrounding circumstances, and the other is to variable-length code syntax elements using a pre-defined table or formula. The former, CABAC (Context Adaptive Binary Arithmetic Coding), stores an updated probability model in memory for each coded or decoded picture (slice). Then, for P pictures, Alternatively, as the initial state of the B-picture context, the probability model stored in memory is From the above, a probability model for pictures using the same slice type and quantization parameters at the same slice level is set. This initial state is used for encoding and decoding processes. The separated codes include prediction information for generating a predicted image and prediction error for generating a difference image.

[0060] The entropy decoding unit 301 outputs the separated codes to the parameter decoding unit 302. For example, the codes include a prediction mode predMode, general_merge_flag, merge_idx, inter_pred_idc, refIdxLX, mvp_LX_idx, mvdLX, amvr_mode, a CCCM flag cccm_flag, a CCCM merge flag cccm_merge_flag, a CCCM filter index cccm_multi_flt_idx, a CCRM flag ccrm_flag, a CCRM merge flag ccrm_merge_flag, a CCRM filter index ccrm_multi_flt_idx, etc. The control as to whether to decode the signal is performed based on an instruction from the parameter decoding unit 302.

[0061] The loop filter 305 is a filter provided in the coding loop, and is used to remove block distortion and ringing. The loop filter 305 is a filter that removes distortion and improves image quality. The loop filter 305 applies a deblocking filter, a sample adaptive offset (SAO), and an adaptive filter to the decoded image of the CU generated by the adder 312. Apply a filter such as an automatic loop filter (ALF).

[0062] The reference picture memory 306 stores the decoded image of the CU generated by the adder 312 in a location that is determined in advance for each current picture and current CU.

[0063] The prediction parameter memory 307 stores prediction parameters at a predetermined position for each CTU or CU to be decoded. Specifically, the prediction parameter memory 307 stores the parameters decoded by the parameter decoding unit 302 and the prediction mode predMode separated by the entropy decoding unit 301. do.

[0064] The predicted image generating unit 308 receives predMode, prediction parameters, etc. The generation unit 308 reads the reference picture from the reference picture memory 306. generates a predicted image of a block or subblock using prediction parameters and the read reference picture (reference block) in the prediction mode indicated by predMode. Here, the reference block is a set of pixels on the reference picture (usually rectangular, so called a block), and is an area to be referenced to generate a predicted image.

[0065] (CCxM Prediction Department) As shown in Fig. 9, the CCxM prediction unit 313 includes a CCxM prediction parameter derivation unit 3131, a CCxM prediction filter unit 3132, and a reference image filter unit 3133. The CCxM prediction parameter derivation unit 3131 inputs a luminance reference image ccRefY and chrominance reference images ccRefCb, ccRefCr, and derives parameters of a prediction model between color components (CCxM prediction parameters). The CCxM prediction filter unit 3132 inputs a luminance locally decoded image recY, and generates chrominance predicted images predCb', predCr' based on the derived CCxM prediction parameters.

[0066] The reference images ccRefY, ccRefCb, and ccRefCb used for deriving the prediction parameters may be decoded images of the current block or decoded images of adjacent blocks. Alternatively, they may be predicted images of the current block or predicted images of adjacent blocks. For example, ccRefY, ccRefCb, and ccRefCb are the luminance decoded image recY and the chrominance decoded images recCb and recCr of the adjacent blocks. Alternatively, as another example, ccRefY, ccRefCb, and ccRefCb are the luminance predicted image predY and the chrominance predicted images predCb and predCr of the current block.

[0067] The reference image filter unit 3133 may apply filter processing to the input image to the CCxM prediction parameter derivation unit and the input image to the CCxM prediction filter unit. In the following description, the filter processing for the reference images ccRefY, ccRefCb, ccRefCr, and the decoded image recY may be a weighted sum of each pixel and neighboring pixels. Also, a downsampling process may be applied to reduce the number of input pixels. Furthermore, a plurality of different filter processes, for example with different weight values, may be applied. In this case, the reference images to which different filters have been applied are distinguished by being called ccRefY0, ccRefY1, recY0, recY1, etc. The reference image filter unit 3133 determines the filter to be applied. The process may be selected based on the filter control parameter ccxmMultiFltIdx. The value of the control parameter ccxmMultiFltIdx may be set and provided by a processing unit that uses the CCxM prediction unit 313, such as the CCCM prediction unit 31044 or the CCRM prediction unit 3096. For example, the CCCM prediction unit 31044 may provide the syntax element cccm_multi_flt_idx as ccxmMultiFltIdx to the CCxM processing unit 313. Similarly, the CCRM prediction unit 3096 may provide the syntax element ccrm_multi_flt_idx as ccxmMultiFltIdx. may be provided to the CCxM processing unit 313 as

[0068] The CCxM prediction parameter derivation unit 3131 derives the chrominance reference image ccRefCb and The parameters of the function for deriving ccRefCr and ccxM prediction parameters are derived, and the prediction parameters are The data is stored in the data memory 307.

[0069] The CCxM prediction parameters are derived, for example, by using the least squares method to find function coefficients for each pair of ccRefY and ccRefCb, and ccRefY and ccRefCr in a function (linear function, convolution calculation model) that converts the luminance reference image ccRefY into the chrominance reference images ccRefCb, ccRefCr. The function coefficients may be, for example, a coefficient a[i] and an offset b that are multiplied by the input image. The range of the subscript i is determined based on the number numCCXM of CCxM prediction parameters. The number numCCXM of CCxM prediction parameters may be a fixed value, or may be set by another processing unit that controls the CCxM prediction unit 313. For example, For example, when used by the CCCM prediction unit 31044, numCCXM=7, and when used by the CCRM prediction unit 3096, numCCXM=8. The value of numCCXM is not limited to this, and may be 2, 3, 4, 5, 6, etc. Other numbers such as pieces may also be used.

[0070] (CCxM prediction parameter derivation unit 3131) The CCxM prediction parameter derivation unit 3131 derives temporary variables tempY and tempC from the reference images ccRefY[] and ccRefC[] (=ccRefCb or ccRefCr) in the reference region (x, y) and offset (dxK, dyK). K is, for example, from 0 to 4, and is used to distinguish the offset of each pixel and its neighboring pixels. Here, (x,y) are the luminance coordinates.

[0071] for ((x,y) in ccRefY) { tempY[cnt][0] = ccRefY[x+dx0*SubWidthC][x+dy0*SubHeightC] tempY[cnt][1] = ccRefY[x+dx1*SubWidthC][y+dy1*SubHeightC] tempY[cnt][2] = ccRefY[x+dx2*SubWidthC][y+dy2*SubHeightC] tempY[cnt][3] = ccRefY[x+dx3*SubWidthC][y+dy3*SubHeightC] tempY[cnt][4] = ccRefY[x+dx4*SubWidthC][y+dy4*SubHeightC] tempY[cnt][5] = nonlinear(tempY[0][cnt]) tempY[cnt][6] = 1 tempC[cnt] = ccRefC[x / SubWidthC][y / SubHeightC] cnt=cnt+1 } Here, SubWidthC and SubHeightC are values ​​determined by the color difference format. In the 4:2:0 format, SubWidthC = 1, SubHeightC = 1, in the 4:2:0 format, SubWidthC = 2, SubHeightC = 2, in the 4:2:2 format, SubWidthC = 2, SubHeightC = 1, in the 4:4:4 format, SubWidthC = 1, SubHeightC = 1. Also, nonlinear is, for example, the following function. nonlinear(x) = x*x + ((1<<(bitDepth-1))>>bitDepth) Furthermore, (dx0,dy0), (dx1,dy1), (dx2,dy2), (dx3,dy3), and (dx4,dy4) are, for example, (0,0), (-1,0), (1,0), (0,-1), and (0,1). In this example, the target pixel (x,y) and its surrounding pixels above, below, left, and right are is used.

[0072] The CCxM prediction parameter derivation unit 3131 derives the following matrix sumXX and vector from the temporary images tempY and tempC. Derive the torque sumXY. In the following, numCCXM=7.

[0073] for (i=0; i <numCCXM; i++) { for (j=i; j <numCCXM; j++) { sumXX[i][j] = sumXX[j][i] = Σ(tempY[i][cnt]*tempY[j][cnt]) sumXY[i] = Σ(tempY[i][cnt]*tempC[cnt]) } } Here, Σ represents summation over the temporary variable cnt.

[0074] As in the following example, it is possible to derive sumXX and sumXY directly without deriving the temporary variable cnt.

[0075] numCCXM = 7 for ((x,y) in ccRefY) { tempY[0] = ccRefY[x+dx0*SubWidthC][x+dy0*SubHeightC] tempY[1] = ccRefY[x+dx1*SubWidthC][y+dy1*SubHeightC] tempY[2] = ccRefY[x+dx2*SubWidthC][y+dy2*SubHeightC] tempY[3] = ccRefY[x+dx3*SubWidthC][y+dy3*SubHeightC] tempY[4] = ccRefY[x+dx4*SubWidthC][y+dy4*SubHeightC] tempY[5] = nonlinear(tempY[0]) tempY[6] = 1 tempC = ccRefC[x / SubWidthC][y / SubHeightC] for (i=0; i <numCCXM; i++) { for (j=i; j <numCCXM; j++) { sumXX[i][j] = sumXX[j][i] += tempY[i]*tempY[j] sumXY[i] += tempY[i]*tempC } } } In addition, the regularization term reg is added to the diagonal elements. sumXX[i][i] = sumXX[i][i] + reg reg = (1<<(bitDepth-1)) The CCxM prediction parameter derivation unit 3131 calculates a linear function corresponding to cparam[k]=sumXY[k]*inverse(sumXX). The calculation derives cparam[k], k = 0..numCCXM-1, where inverse(X) is the inverse matrix of X.

[0076] a[0] = cparam[0] a[1] = cparam[1] a[2] = cparam[2] ... a[numCCXM-2] = cparam[numCCXM-2] b = a[numCCXM-1] = cparam[numCCXM-1] In this manner, the CCxM prediction unit 313 generates a filter coefficient for converting ccRefY to ccRefC, i.e., a prediction Here, ccRefC is either ccRefCb or ccRefCr, so CCxM The prediction unit 313 derives two sets of prediction parameters a[ ].

[0077] For tempY, neighboring pixels at different positions may be used for each target pixel on the reference image ccRefY based on ccxmMultiFltIdx. For example, use the following pseudo code. The derivation of sumXY is the same as that already explained, so it will be omitted. if(ccxmMultiFltIdx == 1) { for ((x,y) in ccRefY) { tempY[0] = ccRefY[x+dx0*SubWidthC][y+dy0*SubHeightC] tempY[1] = ccRefY[x+dx1*SubWidthC][y+dy1*SubHeightC] tempY[2] = ccRefY[x+dx2*SubWidthC][y+dy2*SubHeightC] tempY[3] = ccRefY[x+dx3*SubWidthC][y+dy3*SubHeightC] tempY[4] = nonlinear(tempY[0]) tempY[5] = nonlinear(tempY[1]) tempY[6] = nonlinear(tempY[2]) tempY[7] = x tempY[8] = y tempY[9] = 1 numCCXM = 10 tempC = ccRefC[x / SubWidthC][y / SubHeightC] ... / / update sumXX and sumXY } } For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3) may be (0, 0), (-1, 0), (1, 0), (0, 1). This means that for each target pixel, the target pixel, the left, right, and upper positions of the target pixel This is an example using pixels.

[0078] The following else-if clause is an example when ccxmMultiFltIdx is 2. else if(ccxmMultiFltIdx == 2) { for ((x,y) in ccRefY) { tempY[0] = ccRefY[x+dx0*SubWidthC][y+dy0*SubHeightC] tempY[1] = ccRefY[x+dx1*SubWidthC][y+dy1*SubHeightC] tempY[2] = ccRefY[x+dx2*SubWidthC][y+dy2*SubHeightC] tempY[3] = ccRefY[x+dx3*SubWidthC][y+dy3*SubHeightC] tempY[4] = ccRefY[x+dx4*SubWidthC][y+dy4*SubHeightC] tempY[5] = ccRefY[x+dx5*SubWidthC][y+dy5*SubHeightC] tempY[6] = nonlinear(tempY[0]) tempY[7] = nonlinear(tempY[1]) tempY[8] = nonlinear(tempY[2]) tempY[9] = x tempY

[10] = 1 numCCXM = 11 tempC = ccRefC[x / SubWidthC][y / SubHeightC] ... / / update sumXX and sumXY } } For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3), (dx4, dy4), and (dx5, dy5) may be (0, 0), (-1, 0), (1, 0), (0, -1), (-1, -1), or (1, -1). This is an example in which the target pixel and the pixels to the left, right, above, upper left, and upper right of the target pixel are used as the locally decoded image.

[0079] The following else-if clause is an example when ccxmMultiFltIdx is 3. else if(ccxmMultiFltIdx == 3) { for ((x,y) in ccRefY) { tempY[0] = ccRefY[x+dx0*SubWidthC][y+dy0*SubHeightC] tempY[1] = ccRefY[x+dx1*SubWidthC][y+dy1*SubHeightC] tempY[2] = ccRefY[x+dx2*SubWidthC][y+dy2*SubHeightC] tempY[3] = ccRefY[x+dx3*SubWidthC][y+dy3*SubHeightC] tempY[4] = ccRefY[x+dx4*SubWidthC][y+dy4*SubHeightC] tempY[5] = ccRefY[x+dx5*SubWidthC][y+dy5*SubHeightC] tempY[6] = nonlinear(tempY[0]) tempY[7] = nonlinear(tempY[1]) tempY[8] = nonlinear(tempY[2]) tempY[9] = y tempY

[10] = 1 numCCXM=11 tempC = ccRefC[x / SubWidthC][y / SubHeightC] ... / / update sumXX and sumXY } } For example, in the above formula, (dx0,dy0), (dx1,dy1), (dx2,dy2), (dx3,dy3), (dx4,dy4), (dx5,dy5) may be (0,0), (1,-1), (-1,1), (0,0), (1,-1), (-1,1). recY0 and recY1 are the A different filter is applied by the reference pixel filter unit 3133. This is an example in which two sets of pixels, a target pixel, and pixels at the upper right and lower left positions of the target pixel, are used as a locally decoded image with different filters.

[0080] Note that the CCxM prediction unit may downsample ccRefY to an image ccRefYs of the same size as the chrominance images ccRefCb and ccRefCr using the reference pixel filter 3133. In this case, (x, y) are chrominance coordinates. An example when ccxmMultiFltIdx is 1 is as follows. if(ccxmMultiFltIdx == 1) { for ((x,y) in ccRefYs) { tempY[0] = ccRefY[x+dx0][y+dy0] tempY[1] = ccRefY[x+dx1][y+dy1] tempY[2] = ccRefY[x+dx2][y+dy2] tempY[3] = ccRefY[x+dx3][y+dy3] tempY[4] = nonlinear(tempY[0]) tempY[5] = nonlinear(tempY[1]) tempY[6] = nonlinear(tempY[2]) tempY[7] = x tempY[8] = y tempY[9] = 1 numCCXM = 10 tempC = ccRefC[x][y] ... / / update sumXX and sumXY } } Similarly, when ccxmMultiFltIdx is another value, coordinate conversion using SubWidthC and SubHeightC is not necessary.

[0081] In this way, in the CCxM prediction parameter derivation part, the pixel of the input image is determined by ccxmMultiFltIdx. The method of referencing ccxmMultiFltIdx can be changed. Note that ccxmMultiFltIdx is also referenced by the CCxM prediction filter section described later. The CCxM prediction parameter derivation unit changes the way pixels of the input image are referenced in a corresponding manner.

[0082] The CCxM prediction unit 313 converts the CCxM prediction parameters derived for a certain block into prediction parameters. The parameters stored in the predicted parameter memory are stored in the processing block 307. For example, the parameters derived under the control of the CCCM prediction unit may be stored in association with a specific PU, and the parameters derived under the control of the CCRM prediction unit 3096 may be stored in association with a specific TU.

[0083] When the variable ccxmMergeFlag is set to true (1), the CCxM prediction unit 313 performs CCxM prediction parameter derivation. The CCxM prediction parameters a′[] derived by the output unit 3131 and stored in the prediction parameter memory 307, Or, a new merge process is performed using a predefined default parameter a_def[]. The variable ccxmMergeFlag indicates, for example, whether the CCxM prediction unit is a CCCM prediction unit or not. When the CCxM prediction unit uses the CCRM prediction unit, the value of cccm_merge_flag is substituted. When used from the ccrm_merge_flag register, the value of ccrm_merge_flag is substituted.

[0084] The CCxM prediction filter unit 3132 may derive predicted images predCb' and predCr' using the CCxM prediction parameters derived by merging. At this time, the CCxM prediction unit 313 derives new CCxM prediction filter parameters a[i] of a block including coordinates (x, y) as a'[x][y][i]. Such prediction parameters may be derived.

[0085] The CCxM prediction unit 3131 performs CCxM prediction for the block A adjacent above (x, y) = (xC + nW, yC - 1). The prediction parameter a'[xC + nW][yC - 1][i] may be used as the CCxM prediction parameter a[i]. The top left coordinate of the block is denoted as (xC, yC), the width of the block is denoted as nW, and the height of the block is denoted as nH. Similarly, the CCxM prediction parameter a'[x, y] of the adjacent block L on the left (x, y) = (xC - 1, yC + nH - 1) may be used as the CCxM prediction parameter a[i]. The data a'[xC - 1][yC + nH - 1][i] may be used as the CCxM prediction parameter a[i]. The reference position N may be changed according to the merge direction of the CCxM prediction filter (the position of the block referenced by the CCxM prediction filter 3132) or the value of the variable ccxmMergeIdx that selects the prediction parameter to be used for merging. For example, when ccxmMergeIdx=0, the value of ccxmMergeIdx is set to 0, and the left adjacent block is set to 0. When ccxmMergeIdx=1, the upper adjacent block (A) may be selected. The value of the variable ccxmMergeIdx may be set from outside the CCxM prediction unit. For example, when the CCCM prediction unit uses the CCxM prediction unit, the value of cccm_merge_idx is substituted, and when the CCRM prediction unit uses the CCxM prediction unit, the value of cccm_merge_idx is substituted. The value of cccm_merge_idx and ccrm_merge_idx may be substituted. Alternatively, a predetermined offset may be added to each prediction unit. For example, when the CCCM prediction unit uses the CCxM prediction unit, the value of cccm_merge_idx+CCCM_MERGE_IDX_OFFSET may be substituted, and when the CCRM prediction unit uses the CCxM prediction unit, the value of ccrm_merge_idx+CCRM_MERGE_IDX_OFFSET may be substituted. In this way, the value range of cccm_merge_idx and ccrm_merge_idx can be narrowed to improve coding efficiency.

[0086] if (ccxmMergeFlag) if (ccxmMergeIdx==0) a[i] = a'[xC - 1][yC + nH - 1][i] / / a = a'L else if (ccxmMergeIdx==1) a[i] = a'[xC + nW - 1][yC - 1][i] / / a = a'L It is also possible to obtain the position N based on the availability of adjacent blocks and use the parameter a' of the position N (and so on). if (ccxmMergeFlag) if (ccxmMergeIdx==0) N = L else if (ccxmMergeIdx==1) N= A a = a'N In this way, for all i, the value obtained from the upper adjacent block or the left adjacent block is used as the target. If the CCxM prediction parameter of the left adjacent block is available, the CCxM prediction parameter a′L of the left adjacent block is used, and if the CCxM prediction parameter of the upper adjacent block is available, the CCxM prediction parameter a′L of the upper adjacent block is used. When the CCxM prediction parameters of the upper adjacent block are available, the CCxM prediction parameters a'A are used. That is, the available CCxM prediction parameters of the neighboring blocks may be set as the CCxM prediction parameters of the current block.

[0087] Alternatively, if both blocks are available, a value derived from the two CCxM prediction parameters (eg, an average value) may be used.

[0088] if (ccxmMergeFlag) if (ccxmMergeLeftAvailable) if (ccxmMergeUpperAvailable) a[i] = (a'[xC - 1][yC + nH - 1][i] + a'[xC + nW - 1][yC - 1][i] + 1) >> 1 / / a' = (a'A + a'L + 1)>>1 else a[i] = a'[xC - 1][yC + nH - 1][i] / / a' = a'L else if (ccxmMergeUpperAvailable) a[i] = a'[xC + nW - 1][yC - 1][i] / / a' = a'A In the above example, the decoding of parameters given to ccxmMergeIdx, for example cccm_merge_idx and ccrm_merge_idx, can be omitted.

[0089] The next example shows how to use a weighted average to combine two CCxM prediction parameters.

[0090] if (ccxmMergeFlag) if (ccxmMergeLeftAvailable) if (ccxmMergeUpperAvailable) a[i] = ( w * a'[xC - 1][yC + nH - 1][i] + ((1< <M)-w) * a'[xC + nW - 1][yC - 1][i] + 1<<(M-1)) > > (1< <M) else a[i] = a'[xC - 1][yC + nH - 1][i] else if (ccxmMergeUpperAvailable) a[i] = a'[xC + nW - 1][yC - 1][i] Here, w is the weight of the prediction parameter. For example, w is the weight a'L[i], a'A[i] of the adjacent blocks L and A, that is, a'[xC - 1][yC + nH - 1][i] and a'[xC + nW - 1][yC - 1][i], respectively. It may be derived from the horizontal and vertical dimensions (widthA, heightA) and (widthL, heightL). w = ((widthA + heightA) << M) / (widthA + heightA + widthL + heightL) M is the precision for converting the weight calculation into integers, for example M=6.

[0091] ccxmMergeLeftAvailable and ccxmMergeUpperAvailable are the available options for the left adjacent block. The flags indicate whether the measurement parameters and the prediction parameters of the upper adjacent block are available (availability). The CCxM prediction unit 313 or another processing unit, for example, the parameter decoding unit 302, may derive these flags using the following formula. In the following, the position of the adjacent block is denoted by (xNbY, yNbY). The position of the target block is denoted by (xC, yC).

[0092] The CCxM prediction unit 313 sets the position of the left adjacent block (xC - 1, yC + nH - 1) to the position (xNbY, yNbY) of the adjacent block, performs the following determination, and stores the determination result in ccxmMergeLeftAvailable. Here, it is okay to use (xC - 1, yC) or (xC - 1, yC + nH) for the position of the left adjacent block. stomach.

[0093] The CCxM prediction unit 313 sets the position of the upper adjacent block (xC-nW-1, yC-1) to the position of the adjacent block (xNbY, yNbY), performs the following determination, and stores the determination result in ccxmMergeUpperAvailable. Here, (xC, yC1) or (xC+nW, yC-1) may be used as the position of the left adjacent block.

[0094] The CCxM prediction unit 313 determines that there is no adjacent block if one or more of the following determinations are true: If you want to use the merge service, set mergeAvailable to false. Otherwise, set mergeAvailable to true. Determine. -The adjacent block is off-screen. (xNbY < 0 or yNbY < 0 or xNbY >= picWidth or yNbY >= picHeight) -The adjacent block is in a later CTU than the target block. ((xNbY >> CtbLog2SizeY) > (xCurr >> CtbLog2SizeY) && (yNbY >> CtbLog2SizeY) >= (yC >> CtbLog2SizeY) -The adjacent block is in a later CTU than the target block. (yNbY >> CtbLog2SizeY) >= (yC >> CtbLog2SizeY) + 1 The adjacent block is in a different slice from the target block (slice boundary). The adjacent block is in a different tile than the target block (tile boundary). The synchronous decoding flag is 1 and the adjacent block is one or more blocks to the right of the target block. . sps_entropy_coding_sync_enabled_flag == 1 && (xNbY >> CtbLog2SizeY) >= (xC >> CtbLog2SizeY) + 1 Here, picWidth and picHeight are the picture width and height, and may be values ​​obtained by decoding the PPS syntax pps_pic_width_in_luma_samples and pps_pic_height_in_luma_samples. .

[0095] Furthermore, the above presence determination is based on CTU boundaries, sub-picture boundaries, and virtual boundaries. The virtual boundary indicates the boundary between the refreshed area and the unrefreshed area.

[0096] Furthermore, after making the following determination (even if adjacent blocks exist), the CCxM prediction unit 313 sets mergeAvailable to false if the following is true: · Prediction parameters for position (xNbY, yNbY) are not available. Alternatively, "prediction parameters are not available" may be determined as follows. The color difference prediction mode (PredModeC) of (xNbY, yNbY) is intra and the color components of multiple reference positions are It is not CCXM, which uses component prediction. The PredMode of (xNbY, yNbY) is not CCRM, which uses color component prediction with multiple reference positions in inter prediction. In addition, if the size of the adjacent block is sufficiently large, even if the adjacent block does not actually use CCXM, it is possible to operate the CCXM prediction parameter derivation internally, store it in internal memory, and use the parameters in the CCXM merge. Taking this table into consideration, the following conditions may be used. The size of (xNbY, yNbY) is smaller than the specified size. For example, nWNb + nHNb < TH , TH = 64, where nWNb, nHNb are the width and height of the neighboring blocks.

[0097] Furthermore, if the size of the target block is small enough, do not use ccxmMergeFlag. It is also possible to always perform the merge process. For example, when the width is WMAX pixels or less and the height is HMAX pixels or less (e.g. WMAX=4, HMAX=4), or when the area is AMAX pixels or less (e.g. AMAX=16), it is advisable to derive the prediction parameters by the merge process. In this case, the syntax elements cccm_merge_flag and ccrm_merge_flag to be given to ccxmMergeFlag are decoded. This eliminates the need for a large number of iterations, improving coding efficiency. Also, the amount of calculation required to derive prediction parameters for small blocks can be reduced.

[0098] (Additional configuration) Furthermore, the CCxM prediction unit 313 calculates the ccxmMergeLeftAvailable and ccxmMergeUpperAvailable may be set. For example, adjacent block (xNbY, yNbY) If the width of the adjacent block (xNbY, yNbY) is greater than or equal to a certain value (4, 8, 16, etc.) or the width of the target block, it may be determined that the block is unavailable and mergeAvailable may be set to false. The height, the sum of the width and height, the area, and the aspect ratio of the neighboring blocks may be used, or the height, the sum of the width and height, the area, and the aspect ratio of the target block may be used instead of the width of the target block.

[0099] The CCxM prediction unit 313 may use ccxmMergeLeftAvailable, ccxmMergeUpperAvailable, and the variable ccxmMergeIdx in combination as follows.

[0100] if (ccxmMergeFlag) if (ccxmMergeLeftAvailable) if (ccxmMergeUpperAvailable) if (ccxmMergeIdx == 0) a[i] = a'[xC - 1][yC + nH - 1][i] else if (ccxmMergeIdx == 1) a[i] = a'[xC + nW - 1][yC - 1][i] else a[i] = (a'[xC - 1][yC + nH - 1][i] + a'[xC + nW - 1][yC - 1][i] + 1) >> 1 else a[i] = a'[xC - 1][yC + nH - 1][i] else if (ccxmMergeUpperAvailable) a[i] = a'[xC + nW - 1][yC - 1][i] According to this example, it is necessary to decode ccxmMergeIdx only when both the left adjacent block and the above adjacent block are available, which can improve the coding efficiency.

[0101] Also, if the CCxM prediction filter parameters of the neighboring blocks are not available, the default CCxM prediction filter parameters a_def[] may be used. The CCxM prediction filter parameters are unavailable when ccxmMergeLeftAvailable or ccxmMergeUpperAvailable is false. For example, a_def[] uses the CCxM prediction parameters that have been used recently, not limited to adjacent blocks. In this way, the history of the CCxM prediction filter parameters that have already been derived can be stored in the prediction parameter memory 307 so that they can be obtained in the order of use, and the history can be used. In addition, the CCxM prediction filter parameters may be fixed values ​​a_const[].

[0102] The CCxM prediction filter parameters of the adjacent blocks are not limited to directly adjacent blocks, and may be CCxM prediction filter parameters of non-adjacent blocks. This is called a non-local CCxM merge. Here, CCxM can be CCCM, CCRM, CCPM (Cross-component prediction model), etc.

[0103] The CCxM prediction filter unit 3132 further generates two predicted images predC for chrominance predCb' and predCr', using the locally decoded luma image recY.

[0104] predC[x][y] =(Σ(a[i]*tempY[i]) + offsetK) >> shiftK (Equation-Pred) Here, x, y are coordinates in the chrominance block, x = 0..nW-1, y = 0..nH-1. Σ is the sum of i = 0..numCCXM-1. offsetK = (1 << (shiftK-1)), tempY is a temporary variable that stores recY. Note that instead of storing in tempY, it is also possible to directly multiply the elements of recY by a[i]. a[i] is the CCxM prediction. The parameter derivation unit 3131 uses the values ​​derived for Cb and Cr, respectively, to calculate the two A set of predicted images is generated. tempY[0] = recY[x*SubWidthC+dx0][y*SubHeightC+dy0] tempY[1] = recY[x*SubWidthC+dx1][y*SubHeightC+dy1] tempY[2] = recY[x*SubWidthC+dx2][y*SubHeightC+dy2] tempY[3] = recY[x*SubWidthC+dx3][y*SubHeightC+dy3] tempY[4] = recY[x*SubWidthC+dx4][y*SubHeightC+dy4] tempY[5] = nonlinear(tempY[0]) tempY[6] = 1 nonlinear(x) = x*x + ((1<<(bitDepth-1))>>bitDepth) For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3), (dx4, dy4) may be (0, 0), (0, -1), (0, 1), (-1, 0), (1, 0). This is an example in which the target pixel and the pixels above, below, left, and right of the target pixel are used for each target pixel in the locally decoded image.

[0105] In addition, in (Equation-Pred), the offset term b is also derived as a multiplication with a[numCCXM-1], but it may be derived as a sum of offset terms as follows.

[0106] predC[x][y] =(Σ(a[i]* tempY[i]) + b + offsetK) >> shiftK Σ is the sum for i=0..numCCXM-2 and b=a[numCCXM-1].

[0107] Furthermore, based on ccxmMultiFltIdx, a different position is set for each target pixel on the local decoded image recY. Alternatively, the pixel value obtained by applying a nonlinear function or the coordinate value may be used as the pixel value of tempY. It may be given as an element. if(ccxmMultiFltIdx == 1) { tempY[0] = recY[x*SubWidthC+dx0][y*SubHeightC+dy0] tempY[1] = recY[x*SubWidthC+dx1][y*SubHeightC+dy1] tempY[2] = recY[x*SubWidthC+dx2][y*SubHeightC+dy2] tempY[3] = recY[x*SubWidthC+dx3][y*SubHeightC+dy3] tempY[4] = nonlinear(tempY[0]) tempY[5] = nonlinear(tempY[1]) tempY[6] = nonlinear(tempY[2]) tempY[7] = x tempY[8] = y tempY[9] = 1 numCCXM = 10 } For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3) may be (0, 0), (-1, 0), (1, 0), (0, 1). This means that for each target pixel, the target pixel, the left, right, and upper positions of the target pixel This is an example using pixels.

[0108] The following else-if clause is an example when ccxmMultiFltIdx is 2. else if(ccxmMultiFltIdx == 2) { tempY[0] = recY[x*SubWidthC+dx0][y*SubHeightC+dy0] tempY[1] = recY[x*SubWidthC+dx1][y*SubHeightC+dy1] tempY[2] = recY[x*SubWidthC+dx2][y*SubHeightC+dy2] tempY[3] = recY[x*SubWidthC+dx3][y*SubHeightC+dy3] tempY[4] = recY[x*SubWidthC+dx4][y*SubHeightC+dy4] tempY[5] = recY[x*SubWidthC+dx5][y*SubHeightC+dy5] tempY[6] = nonlinear(tempY[0]) tempY[7] = nonlinear(tempY[1]) tempY[8] = nonlinear(tempY[2]) tempY[9] = x tempY

[10] = 1 numCCXM = 11 } For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3), (dx4, dy4), and (dx5, dy5) may be (0, 0), (-1, 0), (1, 0), (0, -1), (-1, -1), or (1, -1). This is an example in which the target pixel and the pixels to the left, right, above, upper left, and upper right of the target pixel are used as the locally decoded image.

[0109] The following else-if clause is an example when ccxmMultiFltIdx is 3. else if(ccxmMultiFltIdx == 3) { tempY[0] = recY0[x*SubWidthC+dx0][y*SubHeightC+dy0] tempY[1] = recY0[x*SubWidthC+dx1][y*SubHeightC+dy1] tempY[2] = recY0[x*SubWidthC+dx2][y*SubHeightC+dy2] tempY[3] = recY1[x*SubWidthC+dx3][y*SubHeightC+dy3] tempY[4] = recY1[x*SubWidthC+dx4][y*SubHeightC+dy4] tempY[5] = recY1[x*SubWidthC+dx5][y*SubHeightC+dy5] tempY[6] = nonlinear(tempY[0]) tempY[7] = nonlinear(tempY[1]) tempY[8] = nonlinear(tempY[2]) tempY[9] = y tempY

[10] = 1 numCCXM=11 } For example, in the above formula, (dx0, dy0), (dx1, dy1), (dx2, dy2), (dx3, dy3), (dx4, dy4), and (dx5, dy5) may be (0, 0), (1, -1), (-1, 1), (0, 0), (1, -1), or (-1, 1). The reference pixel filter unit 3133 applies different filters to recY to derive recY0 and recY1. This is the locally decoded image In this example, two sets of pixels are used, one for the target pixel and one for the upper right and one for the lower left of the target pixel, with different filters.

[0110] Note that the CCxM prediction unit may downsample recY to an image recYs of the same size as the chrominance image of the current block using the reference pixel filter 3133. In this case, an example in which ccxmMultiFltIdx is 1 is as follows. if(ccxmMultiFltIdx == 1) { tempY[0] = recYs[x+dx0][y+dy0] tempY[1] = recYs[x+dx1][y+dy1] tempY[2] = recYs[x+dx2][y+dy2] tempY[3] = recYs[x+dx3][y+dy3] tempY[4] = nonlinear(tempY[0]) tempY[5] = nonlinear(tempY[1]) tempY[6] = nonlinear(tempY[2]) tempY[7] = x tempY[8] = y tempY[9] = 1 numCCXM = 10 } Similarly, when ccxmMultiFltIdx is another value, coordinate conversion using SubWidthC and SubHeightC is not necessary.

[0111] (Configuration of intra prediction parameter derivation unit) The intra prediction parameter derivation unit 304 performs intra prediction by referring to prediction parameters stored in the prediction parameter memory 307 based on the code input from the entropy decoding unit 301. Decode the parameters, for example, the intra prediction mode IntraPredMode. The meter derivation unit 304 outputs the decoded intra prediction parameters to the predicted image generation unit 308, and also stores them in the prediction parameter memory 307. The intra prediction parameter derivation unit 304 may derive different intra prediction modes for luma and chroma.

[0112] FIG. 7 illustrates a syntax structure of intra prediction parameters according to an embodiment of the present invention. As shown in the figure, the intra prediction parameter derivation unit 304 predicts chrominance from luminance. If cclm_mode_flag is a value (here, 1) indicating that LM prediction is to be performed, a flag cccm_flag indicating whether or not CCCM prediction is to be performed, which predicts color difference by performing a convolution operation on multiple luminance values, is decoded. If cccm_flag is true, cccm_merge_flag and cccm_multi_flt_idx are decoded. cccm_merge_flag is the value indicating whether the CCCM prediction unit 31044 will perform merge. A flag indicating whether or not prediction is used. cccm_multi_flt_idx is an index that selects the filtering method for reference pixels in CCCM prediction. For example, it may be a syntax that switches between multiple reference pixels around the target pixel and a function of a weighting coefficient, and may switch the position of the reference pixel. It may also be a syntax that switches whether or not coordinates are input, or the number of second-order terms. . If cccm_merge_flag indicates that merge prediction is used (here 1), cccm_merge_idx The cccm_merge_idx is a parameter indicating a reference block to be used for merge prediction.

[0113] In addition, as another configuration not shown, the CCCM prediction unit 31044 may be configured to decode cccm_multi_flt_idx according to cccm_merge_flag. Specifically, cccm_multi_flt_idx may be decoded only when cccm_merge_flag is false. When cccm_multi_flt_idx does not appear, a specific value, for example, 0, may be used as cccm_multi_flt_idx. Also, when cccm_merge_flag is true, the value of cccm_multi_flt_idx may also be predicted from the adjacent block of the repair. For example, the label of the adjacent block is N, and a variable with N as a suffix is ​​the label of the adjacent block N. represents the relevant variable, cccm_multi_flt_idxN, which is the cccm_multi_flt_idx of adjacent block N, may be used for cccm_multi_flt_idx.

[0114] cccm_multi_flt_idx = cccm_multi_flt_idxN (Color component prediction) Color component (inter-color component) prediction is modeled using correlation between pixel values ​​of color components, derives prediction parameters, and performs filtering using the prediction parameters to derive an image of one color component from an image of another color component. In this embodiment, several color component predictions such as the following examples may be used for the color difference block.

[0115] (CCLM forecast) As shown in FIG. 10, the CCCM prediction unit 31044 performs CCLM prediction and CCCM prediction using the CCxM prediction unit. CCLM prediction uses a simpler linear model than CCCM prediction. The CCCM prediction unit 31044 operates as follows based on the values ​​of cclm_mode_flag and cccm_flag.

[0116] (CCCM forecast) When cclm_mode_flag is true (1) and cccm_flag is true (1), the CCCM prediction unit 31044 performs CCCM prediction. When cccm_flag is true, the intra prediction parameter derivation unit 304 may further decode cccm_merge_flag. The CCCM prediction unit 31044 uses the CCxM prediction unit 313 to derive a luminance local decoded image recY from the luminance local decoded image recY. The prediction images of the color differences predCb and predCr are generated from the input image. Specifically, the process is as follows.

[0117] When cccm_merge_flag is false, the CCCM prediction unit 31044 sets the reference images ccRefY, ccRefCb, ccRefCr using the locally decoded images recY, recCb, recCr of adjacent areas (e.g., including the left, top, and top right of the target block) as follows and provides them to the CCxM prediction unit. ccRefY = recY ccRefCb = recCb ccRefCr = recCr The CCxM prediction unit 313 derives CCxM prediction parameters based on a given reference image.

[0118] When cccm_merge_flag is true, the CCCM prediction unit 31044 uses the syntax element cccm_merge_idx to select the filter parameters to be used for merging, and sets ccxmMergeIdx = cccm_merge_idx The CCxM prediction unit 313 may then derive prediction parameters by merging. This makes it possible to omit the process of deriving prediction parameters from pixel values ​​using linear calculations, thereby achieving the effect of reducing the amount of calculations.

[0119] Next, the luminance local decoded image recY of the target block is input to the CCxM prediction unit 313, and the derived CCxM A model having prediction parameters is applied to derive color difference predicted images predCb and predCr, which are output to an adder.

[0120] (CCLM forecast) When cclm_mode_flag is true (1) and cccm_flag is false (0), the CCCM prediction unit 31044 performs CCLM prediction. The CCCM prediction unit 31044 uses the CCxM prediction unit 313 to generate predicted images of chrominance predCb and predCr from the locally decoded luminance image recY. Specifically, the CCxM prediction parameter derivation unit 3131 derives CCCM prediction parameters consisting of a[k], k=0..numCCLM-1, using a luminance reference pixel ccRefY and a chrominance reference pixel ccRefC adjacent to the target block. numCCLM-1 is, for example, 2. The CCxM prediction parameters in this case are called CCLM prediction parameters.

[0121] (Block size limit) When the size of the target block is equal to or smaller than a predetermined size, the intra-prediction parameter derivation unit 304 In this case (or when the size of the target block is equal to a predetermined minimum size), the intra prediction parameter derivation unit 304 may use CCCM merging, which always uses the already derived CCCM parameters as is. In this case, cccm_merge_flag may be estimated to be 1 without being decoded from the encoded data. This allows the derived CCCM parameters to be used, and the CCxM prediction unit 313 can perform the parameter derivation process. It can be omitted.

[0122] The CCCM processing unit 31044 may include a CCxM prediction unit 310441 as shown in FIG. The prediction unit 310441 is the same as the CCxM prediction unit 313 already described, so the description will be omitted.

[0123] (Configuration of inter-prediction parameter derivation unit) As shown in FIG. 4, the inter-prediction parameter derivation unit 303 receives the input from the parameter decoding unit 302. Based on the input syntax element, the prediction parameters stored in the prediction parameter memory 307 are The inter prediction parameter derivation unit 303 and the AMVP prediction parameter derivation unit 3032, which are the internal elements of the inter prediction parameter derivation unit 303, and the merge prediction parameter derivation unit 3033 are also included. The parameter derivation unit 3036, the MMVD prediction unit 30376, and the MV addition unit 3038 are Since these are means common to all decoding devices, they may be collectively referred to as a motion vector derivation unit (motion vector derivation device).

[0124] If general_merge_flag is 1, i.e., indicates merge prediction mode, derive merge_idx. and outputs it to the merge prediction parameter derivation unit 3036.

[0125] When general_merge_flag is 0, that is, when it indicates the AMVP prediction mode, the AMVP prediction parameter derivation unit 3032 derives mvpLX from inter_pred_idc, refIdxLX, or mvp_LX_idx.

[0126] FIG. 8 illustrates a syntax structure of inter-prediction parameters according to an embodiment of the present invention. As shown in the figure, when ccrmAllowed() returns true (here, 1) for the current block, the inter prediction parameter derivation unit 303 decodes ccrm_flag, which indicates whether or not to perform CCRM prediction. Here, the function ccrmAllowed() is a function for determining whether or not CCRM prediction is possible. For example, if the target block is an inter-prediction block, the IBC (Intra Block Copy) mode is not used for the target block, and the number of chrominance pixels of the target block is less than a predetermined value (for example, 16). If all of the following are true, the transformation coefficients of the luminance image in the target block are non-zero: The inter prediction parameter derivation unit 303 returns true. If ccrm_flag is true, the inter prediction parameter derivation unit 303 further decodes ccrm_merge_flag and ccrm_multi_flt_idx. ccrm_merge_flag indicates whether or not to derive prediction parameters by merging. ccrm_multi_flt_idx is an index that selects a filtering method for reference pixels.

[0127] (MV addition section) The MV adder 3038 adds the derived mvpLX and mvdLX to derive mvLX.

[0128] (Merge prediction) The merge prediction parameter derivation unit 3036 derives merge candidates including prediction parameters (predFlagLX, mvLX, refIdxLX) and constructs a merge candidate list. Furthermore, the merge prediction parameter derivation unit 3036 derives merge candidates including prediction parameters (merge_idxLX, refIdxLX, refIdxLX) and constructs a merge candidate list. The motion information (mvLXN[0], mvLXN[1]), predFlagLXN, and refIdxLXN of the merge candidate N indicated by The merge prediction parameter derivation unit 3036 stores the inter prediction parameters of the selected merge candidates in the prediction parameter memory 307. Both are output to the inter-prediction image generation unit 309.

[0129] (Inter-prediction image generation unit 309) When the predMode indicates inter prediction, the inter prediction image generation unit 309 The inter prediction parameter derivation unit 303 calculates the inter prediction parameter and the reference picture. A predicted image of a block or sub-block is generated by super-prediction.

[0130] FIG. 6 is a block diagram of the inter-prediction image generating unit 309 included in the prediction image generating unit 308 according to this embodiment. 1 is a schematic diagram showing a configuration of an inter-prediction image generating unit 309. The synthesizer 3095 includes a weighted prediction unit 3094.

[0131] (Motion Compensation) The motion compensation unit 3091 (interpolated image generation unit 3091) receives the input from the inter prediction parameter derivation unit 303. Based on the input inter prediction parameters (predFlagLX, refIdxLX, mvLX), an interpolated image (motion compensated image) is generated by reading a reference block from the reference picture memory 306. The reference block is a block shifted by mvLX from the position of the target block on the reference picture RefPicLX specified by refIdxLX. If mvLX does not have integer precision, an interpolated image is generated by applying a filter called a motion compensation filter for generating pixels at decimal positions.

[0132] The motion compensation unit 3091 derives the integer position (xInt, yInt) and phase (xFrac, yFrac) corresponding to the top left coordinates (xPb, yPb) of a block of size bW*bH, the coordinates within the prediction block (xL, yL), and the motion vector (mvLX[0], mvLX[1]) using the following formula (MC-P1).

[0133] xInt = xPb+(mvLX[0]>>(log2MVPREC))+xL xFrac = mvLX[0]&(MVPREC-1) yInt = yPb+(mvLX[1]>>(log2MVPREC))+yL yFrac = mvLX[1]&(MVPREC-1) Here, MVPREC indicates the accuracy of mvLX (1 / MVPREC pixel accuracy), log2MVPREC=log2(MVPREC), x=0...bW-1, y=0...bH-1. For example, MVPREC=16.

[0134] The motion compensation unit 3091 derives a temporary image temp[][] by performing horizontal interpolation processing on the reference pictures refY, refCb, and refCr using an interpolation filter. In the following, Σ is the sum for k=0..NTAP-1, mcFilter[Frac][k] is the k-th interpolation filter coefficient in phase Frac, shift1 is a normalization parameter that adjusts the value range, and offset1=1<<(shift1-1).

[0135] temp[x][y] = (ΣmcFilter[xFrac][k]*ref[xInt+k-NTAP / 2+1][yInt]+offset1)>>shift1 Next, the motion compensation unit 3091 derives the interpolated image Pred[][] by vertically interpolating the temporary image temp[][]. In the following, Σ is the sum for k=0..NTAP-1, shift2 is a normalization parameter that adjusts the value range, and offset2=1<<(shift2-1).

[0136] Pred[x][y] = (Σ(mcFilter[yFrac][k]*temp[x][y+k-NTAP / 2+1])+offset2)>>shift2 (Formula MC-1) (Weighted prediction) The weighted prediction unit 3094 generates a predicted image of the block by multiplying the interpolated image PredLX by a weighting coefficient.

[0137] As shown in Fig. 11, the CCRM prediction unit 3096 performs CCRM prediction using the CCxM prediction unit. When ccrm_flag is true, the CCRM prediction unit performs the following processing for each block of a TU. When ccrm_merge_flag is false, the prediction unit 3096 generates chrominance predicted images predCb, predCr from the luminance locally decoded image recY using the CCxM prediction unit 313. Specifically, the prediction unit 3096 uses the predicted images predY, predCb, predCr of the current block to generate reference images ccRefY, ccRefCb, ccRefCr as follows: The set value is provided to the CCxM prediction unit 313 as above. ccRefY = predY ccRefCb = predCb ccRefCr = predCr The CCxM prediction unit 313 derives CCxM prediction parameters based on a given reference image.

[0138] If ccrm_merge_flag is true, the CCRM prediction unit 3096 sets the filter parameters to be used for merging. Alternatively, a syntax element ccrm_merge_idx for selecting a CCxM prediction parameter may be used, and ccxmMergeIdx = ccrm_merge_idx may be provided to the CCxM prediction unit 313 to derive the CCxM prediction parameters by merging. This has the effect of omitting the process of deriving the prediction parameters from the pixel values ​​using linear calculations, thereby reducing the amount of calculation.

[0139] Next, the luminance decoded image recY of the target block is input to the CCxM prediction unit 313, and the derived CCxM prediction A model having parameters is applied to derive new color difference prediction images predCb and predCr, which are output to an adder.

[0140] The CCRM prediction unit 3096 may include a CCxM prediction unit 30961 as shown in FIG. The measurement unit 30961 is the same as the CCxM prediction unit 313 already described, so the description will be omitted.

[0141] As described above, the CCRM prediction unit derives a chrominance predicted image from a luma locally decoded image. The chrominance predicted images predCb and predCr generated from the luma locally decoded image recY in this way are closer to the original image, reducing residuals and improving coding efficiency.

[0142] The inverse quantization and inverse transform unit 311 inverse quantizes the quantized transform coefficients input from the entropy decoding unit 301 to obtain transform coefficients. The quantized transform coefficients are coefficients obtained by performing frequency transform such as DCT (Discrete Cosine Transform) and DST (Discrete Sine Transform) on prediction errors and quantizing them in the encoding process. The inverse quantization and inverse transform unit 311 performs inverse frequency transform such as inverse DCT and inverse DST on the transform coefficients to obtain the transform coefficients. The inverse quantization and inverse transform unit 311 outputs the prediction error to the addition unit 312.

[0143] The inverse quantization and inverse transform unit 311 includes a scaling unit 31111, an inverse non-separable transform unit 31121, and an inverse separable transform unit 31131. It consists of 31123 parts.

[0144] The adder 312 adds, for each pixel, 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 transform unit 311 to generate a decoded image of the block. The adder 312 stores the decoded image of the block in the reference picture memory 306 , and also outputs it to the loop filter 305 .

[0145] (Configuration of a video encoding device) Next, the configuration of the video encoding device 11 according to this embodiment will be described. Fig. 14 is a block diagram showing the configuration of the video encoding device 11 according to this embodiment. The video encoding device 11 includes a prediction image generating unit 101, a subtraction unit 102, a transformation 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 determining unit 110, a parameter encoding unit 111, and an entropy encoding unit 104.

[0146] The predicted image generating unit 101 generates a predicted image for each CU, which is an area obtained by dividing each picture of the image T. The predicted image generating unit 101 operates in the same manner as the predicted image generating unit 308 already described, and so a description thereof will be omitted.

[0147] The subtraction unit 102 subtracts pixel values ​​of the predicted image of the block input from the predicted image generation unit 101 from the image The subtraction unit 102 generates a prediction error by subtracting the prediction error from the pixel value of T. The subtraction unit 102 outputs the prediction error to the transformation and quantization unit 103.

[0148] The transform / quantization unit 103 calculates transform coefficients by frequency transforming the prediction error input from the subtraction unit 102, and derives quantized transform coefficients by quantizing the prediction error. The quantized transform coefficients are output to the entropy coding unit 104 and the inverse quantization and inverse transform unit 105 .

[0149] The inverse quantization and inverse transform unit 105 is the same as the inverse quantization and inverse transform unit 311 in the video decoding device 31, and a description thereof will be omitted. The calculated prediction error is output to the adder .

[0150] The entropy coding unit 104 receives the quantized transform coefficients from the transform / quantization unit 103 and the coding parameters from the parameter coding unit 111. The entropy coding unit 104 entropy codes the partition information, the prediction parameters, the quantized transform coefficients, etc. to generate and output a coded stream Te.

[0151] The parameter encoding unit 111 includes a header encoding unit 1110, a CT information encoding unit 1111, and a CU The encoding unit 1112 (prediction mode encoding unit), and the inter-prediction parameter encoding unit 112 and the inter The CU encoding unit 1112 further includes a TU encoding unit 1114.

[0152] The inter-prediction parameter encoding unit 112 includes a parameter encoding control unit 1121, an inter-prediction The parameter encoding control unit 1121 includes a parameter derivation unit 303. The inter prediction parameter derivation unit 303 is a common component to that of the video decoding device. The parameter encoding control unit 1121 includes a merge index derivation unit 11211 and a vector candidate index derivation unit 11212.

[0153] The merge index derivation unit 11211 derives merge candidates and the like, and calculates inter prediction parameters The vector candidate index derivation unit 11212 derives predicted vector candidates and the like, and outputs them to the inter prediction parameter derivation unit 303 and the parameter coding unit 111.

[0154] The intra prediction parameter encoding unit 113 encodes the IntraPredMode and the like input from the encoding parameter determination unit 110. The intra prediction parameter encoding unit 113 includes a part of the same configuration as the configuration in which the parameter decoding unit 302 derives the intra prediction parameters.

[0155] The adder 106 adds, for each pixel, the pixel value of the predicted image of the block input from the predicted image generation unit 101 and the prediction error input from the inverse quantization and inverse transform unit 105 to generate a decoded image. The unit 106 stores the generated decoded image in a reference picture memory 109 .

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

[0157] The prediction parameter memory 108 stores the prediction parameters generated by the coding parameter determination unit 110 in a predetermined location for each current picture and CU.

[0158] The reference picture memory 109 stores the decoded image generated by the loop filter 107 at a predetermined position for each current picture and CU.

[0159] The encoding parameter determination unit 110 determines one of the multiple sets of encoding parameters. The coding parameters are the above-mentioned QT, BT or TT division information, prediction parameters, or parameters generated in relation to these and to be coded. The image generator 101 generates a predicted image using these coding parameters.

[0160] The coding parameter determination unit 110 determines the size of the amount of information and the coding parameter for each of the plurality of sets. The coding parameter determination unit 110 calculates an RD cost value indicating an error. The entropy coding unit 104 then selects the set of coding parameters that results in the smallest coding rate. The entropy coding unit 104 then outputs the selected set of coding parameters as the coded stream Te. The parameter determination unit 110 stores the determined coding parameters in the prediction parameter memory 108 .

[0161] In addition, in the above-described embodiment, a part of the video encoding device 11 and the video decoding device 31, for example, the entropy decoding unit 301, the parameter decoding unit 302, the loop filter 305, the predicted image generating unit 306, 308, an inverse quantization and inverse transform unit 311, an addition unit 312, a predicted image generation unit 101, a subtraction unit 102, a transform and The quantization unit 103, the entropy coding unit 104, the inverse quantization and inverse transform unit 105, the loop filter 107, the coding parameter determination unit 110, and the parameter coding unit 111 may be realized by a computer. In this case, the control functions may be realized by recording a program for realizing the control functions in a computer-readable recording medium, and having a computer system read and execute the program recorded in the recording medium. Note that the "computer system" referred to here is a computer system built into either the video coding device 11 or the video decoding device 31, and includes hardware such as an OS and peripheral devices. Also, the "computer-readable recording medium" refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM, a CD-ROM, or a storage device such as a hard disk built into a computer system. Furthermore, the term "computer-readable recording medium" may also include a device that dynamically stores a program for a short period of 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, or a device that stores a program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client in such a case. The above program may be one that realizes part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0162] In addition, a part or the whole of the video encoding device 11 and the video decoding device 31 in the above-mentioned embodiment may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each functional block of the video encoding device 11 and the video decoding device 31 may be individually processed, or a part or the whole may be integrated and processed. The integrated circuit method is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. In addition, when an integrated circuit technology that replaces LSI appears due to the progress of semiconductor technology, an integrated circuit based on that technology may be used.

[0163] Although one embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes, etc. are possible within the scope that does not deviate from the gist of the present invention. [Industrial Applicability]

[0164] The embodiments of the present invention can be suitably applied to a video decoding device that decodes coded data in which image data is coded, and a video coding device that generates coded data in which image data is coded, and can also be suitably applied to the data structure of coded data that is generated by a video coding device and referenced by the video decoding device.

Claims

1. A video decoding device comprising a prediction parameter derivation unit that derives inter-color component prediction parameters, and a prediction filter unit that applies an inter-color component prediction model using the derived prediction parameters to an input image to generate an output image, wherein the video decoding device derives prediction parameters using prediction parameters of an adjacent region to generate an output image from the input image.

2. 2. The video decoding device according to claim 1, wherein the prediction parameter derivation unit derives prediction parameters of a convolution operation model expressing a conversion process from a local luminance decoded image of the adjacent region to a local chrominance decoded image of the adjacent region by using the prediction parameters of the adjacent region, and the prediction filter unit applies the model to the local luminance decoded image of the target block to generate a local chrominance predicted image of the target block.

3. 2. The video decoding device according to claim 1, wherein the prediction parameter derivation unit derives prediction parameters of a convolution operation model expressing a conversion process from a local luminance predicted image of a target block to a local chrominance predicted image of the target block by using prediction parameters of an adjacent region, and the prediction filter unit applies the model to the local luminance decoded image of the target block to generate a local chrominance predicted image of the target block.

4. 2. The video decoding device according to claim 1, wherein the prediction parameter derivation section derives the prediction parameters by selecting prediction parameters of a plurality of adjacent regions based on the decoded index.

5. 2. The video decoding device according to claim 1, wherein the prediction parameter derivation section derives the prediction parameter by combining prediction parameters of a plurality of adjacent regions using a weighted sum.

6. 6. The video decoding device according to claim 5, wherein the prediction parameter derivation section derives the weight based on a ratio between a sum of a width and a height of a target region and a sum of a width and a height of an adjacent region.

7. The video decoding device according to claim 1 , wherein the prediction parameter derivation unit derives availability of prediction parameters of the adjacent region based on attributes of the adjacent region, and derives prediction parameters using prediction parameters of the adjacent region that are available.

8. 8. The video decoding device according to claim 7, wherein the prediction parameter derivation section derives the availability of the prediction parameters of the adjacent region based on a width and a height of the adjacent region.

9. 8. The video decoding device according to claim 7, wherein the prediction parameter derivation section derives the availability of the prediction parameter of the adjacent region based on a positional relationship between the adjacent region and the target region.

10. 10. A video coding device comprising the prediction parameter derivation device according to claim 1, wherein the video coding device codes a residual between a predicted image generated by applying an inter-color component prediction model represented by the prediction parameters to a local image and a target image to be coded.