Cross-component model propagation

Abstract

A method of encoding and decoding a tile of a video using cross-component prediction is provided. A video codec receives data to encode or decode pixels of a current block of a video that is a current picture, wherein the current block includes a first color block and a second color block. The video encoding and decoding device generates a reconstruction for the first color block of the current block. The video codec applies a propagated cross-component model to the reconstruction of the first patch to generate a cross-component prediction of the second patch. The propagated cross-component model is derived using motion information of a reference block of the current block. The video codec uses the generated cross-component prediction to encode or decode the current block.

Description

[0001] Cross-referencing This disclosure is part of a non-provisional application that claims priority to U.S. Provisional Patent Application No. 63 / 526,896, filed July 14, 2023. The contents of the above-listed applications are incorporated herein by reference. [Technical Field] This disclosure is generally related to video encoding and decoding. In particular, this disclosure relates to methods for predicting encoded and decoded pixel blocks across components. [Background Technology] Unless otherwise stated herein, the methods described in this section are not prior art to the following claims, and are not considered prior art by virtue of being included in this section.

[0004] High-Efficiency Video Coding (HEVC) is an international video coding standard developed by the Joint Collaborative Team on Video Coding (JCT-VC). HEVC is based on a hybrid block-based motion-compensated DCT transform-like coding architecture. The basic unit of compression, called a coding unit (CU), is a 2Nx2N square pixel block. Each CU can be recursively divided into four smaller CUs until a predetermined minimum size is reached. Each CU contains one or more prediction units (PUs).

[0005] Versatile Video Coding (VVC) is the latest international video coding standard developed by the Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC1 / SC29 / WG11. The input video signal is predicted from the reconstructed signal derived from the coded picture region. The predicted residual signal is processed through block transform. The transform coefficients are quantized and entropy-coded in the bitstream along with other side information. The reconstructed signal is generated from the predicted signal and the reconstructed residual signal after inverse transform and dequantization of the transform coefficients. The reconstructed signal is further processed through loop filtering to remove coding artifacts. The decoded picture is stored in the frame buffer and used to predict future pictures in the input video signal.

[0006] In VVC, the coded image is divided into non-overlapping square blocks, represented by associated Coding Tree Units (CTUs). The leaf nodes of the code tree correspond to Coding Tree Units (CUs). The coded image can be represented by a series of slices, each containing an integer number of CTUs. Individual CTUs within a slice are processed in raster scan order. Bidirectional prediction (B) slices may use intra-frame prediction or inter-frame prediction, with at most two motion vectors and a reference index to predict the sample value for each block. Predictive (P) slices use intra-frame prediction or inter-frame prediction decoding, with at most one motion vector and a reference index to predict the sample value for each block. Intra-frame (I) slices use only intra-frame prediction decoding.

[0007] CTU can be partitioned into one or more non-overlapping codec units (CUs) using a quadtree (QT) with a nested multi-type-tree (MTT) structure to accommodate various local motion and texture characteristics. CUs can be further partitioned into smaller CUs using one of five partitioning types: quadtree partitioning, vertical binary tree partitioning, horizontal binary tree partitioning, vertical mid-side ternary tree partitioning, and horizontal mid-side ternary tree partitioning.

[0008] Each CU contains one or more prediction units (PUs). A prediction unit, along with its associated CU syntax, serves as the basic unit of signal predictor information. A specified prediction process is used to predict the values ​​of associated pixel samples within a PU. Each CU may contain one or more transform units (TUs) to represent prediction residual blocks. A transform unit (TU) consists of a transform block (TB) for one luma sample and two corresponding transform blocks for two chroma samples; each TB corresponds to a residual block from a color component. Integer transforms are applied to the transform blocks. The level values ​​of the quantization coefficients, along with other side information, are entropy-encoded in the bitstream. The terms Coding Tree Block (CTB), Coding Block (CB), Prediction Block (PB), and Transform Block (TB) are defined as two-dimensional sample arrays of the monochrome components associated with the CTU, CU, PU, ​​and TU, respectively. Therefore, a CTU consists of one luma CTB, two chroma CTBs, and associated syntax elements. Similar relationships exist between CUs, PUs, and TUs.

[0009] For each inter-frame predicted CU, motion parameters include motion vectors, reference picture indices, and reference picture list usage indices, as well as additional information used for generating inter-frame predicted samples. Motion parameters can be signaled explicitly or implicitly. When a CU is encoded in skip mode, the CU is associated with a PU, with no significant residual coefficients, no encoded motion vector difference, and no reference picture index. A merging mode is specified where the motion parameters of the current CU are obtained from neighboring CUs, including spatial and temporal candidates, and additional plans introduced in VVC. The merging mode can be applied to any inter-frame predicted CU. An alternative to the merging mode is explicit transmission of motion parameters, where each CU explicitly signales its motion vector, the reference picture index corresponding to each reference picture list, and the reference picture list usage flag, along with other necessary information.

[0010] To improve encoding / decoding performance and / or reduce complexity for systems using cross-component prediction, methods and apparatus for encoding / decoding video blocks using cross-component prediction are disclosed. [Summary of the Invention] The following abstract is for illustrative purposes only and is not intended to be limiting in any way. That is, the following abstract aims to introduce the concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Selective and not exhaustive embodiments will be further described in the detailed description below. Therefore, the following abstract is not intended to define the essential characteristics of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.

[0012] Certain embodiments of this disclosure provide a method for encoding / decoding a video block using cross-component prediction. A video codec (i.e., encoder or decoder) receives data to encode or decode pixels of a current block of a video into a current image, wherein the current block comprises a first color patch and a second color patch. The video codec generates a reconstruction for the first color patch of the current block. The video codec applies a propagated cross-component model to the reconstruction of the first color patch to generate a cross-component prediction for the second color patch. The propagated cross-component model is derived using motion information from a reference block of the current block. The video codec uses the generated cross-component prediction to encode or decode the current block.

[0013] In some embodiments, when it is determined that a reference block is not decoded in a mode that includes cross-component prediction, the cross-component model of the propagation is derived for that reference block.

[0014] In some embodiments, the cross-component model of the propagation is derived from a further reference block identified using motion information from the reference block. In some embodiments, the propagation model is derived by copying the cross-component model of the further reference block to the reference block.

[0015] In some embodiments, the motion information of the reference block may be a motion vector or a block vector of the reference block. In some embodiments, the block vector of the reference block is the block vector of a co-position brightness block of the reference block.

[0016] In some embodiments, the video codec looks up an index value based on a position within a reference block and uses that index value to locate a propagation cross-component model of motion information corresponding to the reference block in an index table. This index value is provided by an index buffer that stores multiple indices for different positions in a reference image containing the reference block. In some embodiments, this propagation cross-component model is derived by copying the index value from a further reference block of the reference block into the index buffer of the reference block, where the further reference block is identified by the block vector of the reference block.

[0017] In some embodiments, the propagation cross-component model is derived by copying the cross-component model from an index table associated with a further reference image, which contains a further reference block identified by the motion vectors of the reference block. The video codec may store index values ​​used to locate the propagation cross-component model in the index table into the reference block's index buffer based on its position within the reference block.

[0018] In some embodiments, when a reference block has two or more motion vectors or block vectors for identifying two or more further reference blocks, two or more cross-component models may be identified from these two or more further reference blocks, and the propagated cross-component model is a cross-component model whose corresponding further reference block is intra-coded. In some embodiments, when a reference block has two or more motion vectors or block vectors for identifying two or more further reference blocks, two or more cross-component models may be identified from these two or more further reference blocks, and the propagated cross-component model is a combination of these two or more different cross-component models. [Attached Image Description] The accompanying drawings are included to provide a further understanding of this disclosure and are incorporated into and constitute a part of this disclosure. The drawings illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure. It is worth noting that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual size in order to clearly illustrate the concepts of this disclosure.

[0020] Figure 1 This provides a conceptual illustration of chromaticity and luminance samples used to derive parameters for linear models.

[0021] Figure 2 This shows an example of classifying neighboring samples into two groups.

[0022] Figure 3 A conceptual description of the spatial components of a convolutional filter.

[0023] Figure 4 This indicates the gradient filter enabled for the Gradient Linear Model (GLM).

[0024] Figure 5 This describes the predefined search region used for intra-frame template matching.

[0025] Figure 6 Displays the luminance blocks used to derive the direct block vectors of the corresponding chroma blocks.

[0026] Figure 7 This describes the predefined locations of spatially neighboring blocks from which model parameters are inherited.

[0027] Figure 8 This section provides a conceptual explanation of the parameters for the inheritance time proximity model.

[0028] Figures 9A-9B This describes a current block and its non-adjacent spatial neighboring blocks from which model parameters can be inherited.

[0029] Figure 10 This indicates that CCM information is propagated from a reference block pointed to by a block vector to the current block.

[0030] Figure 11 This describes how CCM information is propagated from one of multiple reference blocks to the current block based on one of multiple block vectors.

[0031] Figure 12 This demonstrates how CCM information is propagated from the reference block to the current block via motion vectors.

[0032] Figure 13 This demonstrates that CCM information is propagated from the reference block to the current block using two predicted motion vectors.

[0033] Figure 14 This indicates that CCM information is inherited from the reference block of the reference block.

[0034] Figure 15 This section provides a conceptual description of an image-level index buffer used to store indexes of CCM information storage tables.

[0035] Figure 16 This demonstrates how CCM information is derived and stored by copying entries from the index table of the co-located image to the index table of the current image.

[0036] Figure 17 This concept illustrates how CCM information is derived and stored by copying index buffer entries based on block vectors.

[0037] Figure 18This demonstrates how CCM information is derived and stored by copying entries from the index table of the reference image to the index table of the current image based on motion vectors.

[0038] Figure 19 This illustrates an example of a video encoder that may implement cross-component prediction.

[0039] Figure 20 This section describes the film encoder portion that implements cross-component predictive information propagation.

[0040] Figure 21 This conceptually illustrates the process of propagating cross-component predictive information when encoding movie images.

[0041] Figure 22 This illustrates an example of a video decoder that may implement cross-component prediction.

[0042] Figure 23 This section describes the video decoder part that implements cross-component predictive information propagation.

[0043] Figure 24 This conceptually illustrates the process of propagating cross-component prediction information when decoding video images.

[0044] Figure 25 This invention provides a conceptual illustration of an electronic system in which some embodiments of the present disclosure are implemented.

Detailed Implementation Methods

[0046] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the instruction. Any variations, derivatives, and / or extensions of the instruction described herein are within the scope of this disclosure. In some cases, well-known methods, procedures, components, and / or circuits implemented with respect to one or more examples disclosed herein may be described at a relatively high level without detailed description in order to avoid unnecessarily obscuring the pedagogical aspects of this disclosure.

[0047] I. Cross-component prediction a. Cross Component Linear Model (CCLM) Cross-Component Linear Model (CCLM) or Linear Model (LM) mode is a cross-component prediction mode in which the chromaticity component of a block is predicted from co-located luminance samples based on a linear model. The parameters of the linear model (e.g., scale and offset) are derived from reconstructed luminance and chromaticity samples that are adjacent to the block. For example, in VVC, CCLM mode uses inter-channel dependencies to predict chromaticity samples from reconstructed luminance samples. This prediction uses a linear model of the following form: (1) In equation (1), the predicted chromaticity sample in the CU (or the predicted chromaticity sample of the current CU) is represented. A downsampled reconstructed luminance sample representing the same CU (or the corresponding reconstructed luminance sample of the current CU).

[0048] The CCLM model parameters (scale parameter) and (offset parameter) are derived from up to four neighboring chromaticity samples and their corresponding downsampled luminance samples. In LM_A mode (also known as LM-T mode), only the top or top neighboring template is used to calculate the linear model coefficients. In LM_L mode (also known as LM-L mode), only the left template is used to calculate the linear model coefficients. In LM-LA mode (also known as LM-LT mode), both the left and top templates are used to calculate the linear model coefficients.

[0049] Figure 1 This diagram conceptually illustrates the chromaticity and luma samples used to derive the parameters of a linear model. The figure shows the current block 100 with luma component samples and chromaticity component samples, formatted as 4:2:0. The luma and chromaticity samples adjacent to the current block are reconstructed samples. These reconstructed samples are used to derive the cross-component linear model (parameters α and β). Because the current block is in 4:2:0 format, the luma samples are first down-smapped before being used for linear model derivation. In this example, there are 16 pairs of reconstructed luma (downsampled) and chromaticity samples adjacent to the current block. These 16 pairs of luma and chromaticity values ​​are used to derive the linear model parameters.

[0050] Assuming the current chroma block size is W×H, then W' and H' are set to... – W' = W, H' = H when applying LM-LT mode; – W' = W + H when applying LM-T mode; – H' = H+W when applying LM-L mode The nearest neighbor positions are denoted as S[0, -1]...S[W' - 1, -1], and the left nearest neighbor positions are denoted as S[-1, 0]...S[-1, H' - 1]. Then, four samples are selected as... – S[W' / 4, -1 ], S[ 3 * W' / 4, -1 ], S[ -1, H' / 4 ], S[ -1, 3 * H' / 4 ] When applying LM-LT mode (both the top and left neighboring samples are available); – S[ W' / 8, -1 ], S[ 3 * W' / 8, -1 ], S[ 5 * W' / 8, -1 ], S[ 7 * W' / 8, -1 ] When applying LM-T mode (only the top neighbor sample is available); – S[ -1, H' / 8 ], S[ -1, 3 * H' / 8 ], S[ -1, 5 * H' / 8 ], S[ -1, 7 * H' / 8 ] When applying LM-L mode (only left neighbor samples are available); Four neighboring brightness samples at the selected location were downsampled and compared four times to find the two larger values: x 0A and x 1A and two smaller values: x 0B and x 1B Their corresponding chromaticity sample values ​​are represented as y. 0A y 1A y 0B and y 1B Then X A X B Y A and Y B Derived as: X a = (x 0A + x 1A +1)>>1; X b = (x 0B + x 1B +1)>>1; (2) Y a = (y 0A + y 1A+1)>>1; Y b = (y 0B + y 1B +1)>>1 (3) The linear model parameters ( and ( are obtained according to the following procedure): (4) (5) In some embodiments, to obtain more samples for calculating the CCLM model parameters (and), the above template is expanded to include (W+H) samples for the LM-T mode, and the left template is expanded to include (H+W) samples for the LM-L mode. For the LM-LT mode, both the left and top templates are used to calculate the linear model coefficients.

[0051] To match the chroma sample positions of a 4:2:0 video sequence, two types of downsampling filters are applied to the luminance samples to achieve downsampling ratios of 2 to 1 in both the horizontal and vertical directions. The selection of the downsampling filters is specified by the sequence parameter set (SPS) level flags. These two downsampling filters are as follows, corresponding to "Type-0" and "Type-2" respectively.

[0052] (6) (7) Because independent block segmentation of luma and chroma components is enabled in I-frames, one chroma block may correspond to multiple luma blocks. Therefore, for chroma-derived mode (DM), the intra-prediction mode that directly inherits the luma block corresponding to the center position of the current chroma block is inherited.

[0053] Based on the following table, a single, uniform binary table (mapped to binary strings) is used for chroma intra-frame prediction mode: In the table, the first bit indicates whether it is normal (0) or LM mode (1). If it is LM mode, the next bit indicates whether it is LM_CHROMA (0). If it is not LM_CHROMA, the next bit indicates whether it is LM_L (0) or LM_A (1). In this case, when sps_cclm_enabled_flag is 0, the first bit of the corresponding binary table of intra_chroma_pred_mode can be discarded before entropy encoding and decoding. Or in other words, the first bit is inferred to be 0 and therefore not encoded. This single binary table is used for the cases where sps_cclm_enabled_flag equals 0 and 1. The first two bits in the table are context-encoded using their own context model, and the remaining bits are bypass-encoded.

[0054] b. Multi-model CCLM (MMLM) The Multi-Model CCLM (MMLM) mode uses two models to predict the chromaticity samples of the entire CU from the luminance samples. Similar to CCLM, three Multi-Model CCLM modes (MMLM_LA, MMLM_A, and MMLM_L) are used to indicate whether to use the top and left neighbor samples, use only the top neighbor samples, or use only the left neighbor samples for model parameter derivation.

[0055] In MMLM, the neighboring luminance samples and neighboring chrominance samples of the current block are classified into two groups, each of which serves as a training set to derive a linear model (i.e., specific α and β are derived for a specific group). Furthermore, the samples of the current luminance block are also classified according to the classification rules for neighboring luminance samples.

[0056] Figure 2 This example shows how neighboring samples are classified into two groups. The threshold is calculated as the average of the neighboring reconstructed luminance (Luma) samples. A neighboring sample at position [x,y] is classified into group 1 if Rec′L [x,y] <= the threshold; and a neighboring sample at position [x,y] is classified into group 2 if Rec′L [x,y] > the threshold. Therefore, the multi-model CCLM predicts the chroma samples as follows: Pred c [x,y] = α1×Rec′ L [x,y]+ β1 if Rec′ L [x,y] ≤ threshold Pred c [x,y] = α2×Rec′L [x,y]+ β2 if Rec′ L [x,y]>threshold c. Convolutional Cross-Component Model (CCCM) In some embodiments, a convolutional cross-component model (CCCM) is applied to improve cross-component prediction performance. In some embodiments, the convolutional model has a 7-tap filter with a 5-tap plus shapespace component, a nonlinear term, and a bias term. The input to the spatial 5-tap component of this filter includes a center (C) luminance sample (co-located with the chrominance sample to be predicted) and its above / north (N), below / south (S), left / west (W), and right / east (E) neighbors. Figure 3 The spatial components of a convolutional filter are conceptually illustrated. The nonlinear term (denoted as P) is expressed as the square of the center brightness sample C, scaled to the range of sample values ​​of the content: P = ( C*C + midVal )>>bitDepth (8) Therefore, for 10-bit content, the nonlinear term P is calculated as follows: P = (C*C + 512) >> 10 The bias term (denoted as B) represents the scalar offset between the input and output (similar to the offset term in CCLM) and is set to an intermediate chroma value (512 in 10-bit content). The filter output is calculated as the filter coefficients c. i Convolve the input values ​​and crop to the range of valid chromaticity samples: predChromaVal = c0C + c1N + c2S + c3E + c4W + c5P +c6B (9) d. Gradient Linear Model (GLM) For the YUV 4:2:0 color format, the Gradient Linear Model (GLM) method can be used to predict chromaticity samples from the gradient of luminance samples. Two modes are supported: two-parameter GLM mode and three-parameter GLM mode.

[0057] Compared to CCLM, the two-parameter GLM uses the gradient of luminance samples instead of downsampled luminance values ​​to derive a linear model. Specifically, when applying the two-parameter GLM, the input to the CCLM process is the downsampled luminance samples... The gradient of the brightness sample replace.

[0058] C = α·G + β Other parts of CCLM (e.g., parameter derivation, linear transformation of predicted samples) remain unchanged. In three-parameter GLM, chromaticity samples can be predicted based on the gradient of luminance samples and downsampled luminance values ​​with different parameters. The model parameters of the three-parameter GLM are derived from the 6-row and column neighbor samples based on the MSE minimization method of LDL decomposition, as used in CCCM.

[0059] For signals, when the current CU has CCLM mode enabled, a flag is signaled to indicate whether GLM is enabled for the Cb and Cr components; if GLM is enabled, another flag is signaled to indicate which of the two GLM modes is selected, and a syntax element is further signaled to select one of the four gradient filters for gradient calculation. Figure 4 This diagram illustrates the gradient filters enabled for the Gradient Linear Model (GLM). Specifically, the figure shows four Sobel-based gradient modes 401-404 used for GLM.

[0060] II. Current Image Reference Motion compensation is a video encoding / decoding process that explores pixel correlations between adjacent images. It typically assumes that in a video sequence, a pattern corresponding to an object or background is displaced in one frame to form a corresponding object in a subsequent frame or to correlate with other patterns within the current frame. By estimating this displacement (e.g., using block matching techniques), the pattern can be roughly reproduced without re-encoding it. Block matching and copying allow for the selection of reference blocks from the same image, but have been observed to be inefficient when applied to camera-captured video. This is partly because while spatially adjacent text patterns may resemble the currently encoded block, they typically change spatially. Therefore, for camera-captured video, the likelihood of finding a good match for a block within the same image is low, limiting improvements in encoding / decoding performance.

[0061] However, the spatial correlation between pixels within the same image varies for different screen content. For typical videos with text and graphics, there are often repeating patterns within the same image. Therefore, intra-block copy (IBC) compensation has been observed to be very effective. Thus, screen content can be encoded and decoded using either Intra-Block Copy (IBC) mode or Current Picture Referencing (CPR).

[0062] a. Intra-frame template matching Intra Template Matching Prediction (IntraTMP) is a special intra-frame prediction mode that copies the best prediction block from the reconstructed portion of the current frame, matching its L-shaped template with the current template. For a predefined search range, the encoder searches the reconstructed portion of the current frame for the template most similar to the current template and uses the corresponding block as the prediction block. The encoder then signals the use of this mode and performs the same prediction operation at the decoder. The prediction signal is generated by matching the L-shape of the current block, only its top or only its left causal neighbors, with another block in the predefined search area.

[0063] Figure 5 This illustrates the predefined search regions for intra-frame template matching. As shown in the figure, for the current block (Cur Block) 510 with the current template region 520, the search within the current CTU 505 is performed in several predefined search regions to search for a matching reference template region 530 (thus finding the corresponding reference block 535 (Cur Block)). The predefined search regions include R1 (within the current CTU), R2 (upper left of the current CTU), R3 (above the current CTU), and R4 (to the left of the current CTU). Template matching is based on the Sum of Absolute Differences (SAD) as the cost function.

[0064] b. Direct block vector of chroma blocks Direct block vectors can be used for chroma blocks in a dual-tree slice. When a chroma dual-tree is initiated, a flag is sent to indicate whether the chroma block is encoded using IBC mode. Specifically, if a luma block at one of the five predetermined locations is encoded in IBC or intraTMP mode, its block vector (BV) will be scaled and used as the block vector for the chroma block. Template matching is used to perform block vector scaling (from the luma domain to the chroma domain). Figure 6 This diagram shows the luma blocks used to derive the direct block vectors for the corresponding chroma blocks. The diagram illustrates five predetermined locations used to determine whether the bv of the luma block is scaled and used as the bv of the chroma block.

[0065] III. Cross-component merging mode a. Inherit parameters to refine cross-component model parameters In some embodiments, if the inherited neighboring blocks are encoded in CCLM mode (i.e., encoded or decoded), the final scaling parameters of the current block are inherited from the neighboring blocks. Once the final scaling parameters are determined, the offset parameters (e.g., in CCLM) are... It can be derived based on the inherited scaling parameters and the average value of the neighboring luminance and chrominance samples of the current block.

[0066] In some embodiments, if the inherited neighboring block is encoded in CCLM mode, the offset parameter can be inherited or further refined by dB after inheriting the model parameters. For example, if the offset parameter is inherited from a selected neighboring block, and the inherited offset parameter is... Then the final offset parameter is ( + dB). dB can be zero.

[0067] In some embodiments, if the inherited neighboring block is coded in CCCM, then the inherited filter coefficients ( Offset parameters (e.g., in CCCM) or The inherited parameters can be re-derived based on the inherited parameters and the average values ​​of the luminance and chrominance samples at the corresponding positions of the current block. In some embodiments, if the inherited neighboring blocks are coded in CCCM, the inherited filter coefficients ( Offset parameters (e.g., in CCCM) or The current block is also inherited and not re-exported. In some embodiments, if the inherited candidate block applies the GLM gradient mode to its brightness reconstruction sample, the current block should also inherit the candidate block's GLM gradient mode and apply it to the current brightness reconstruction sample.

[0068] In some embodiments, if the inherited neighboring blocks are encoded with multiple cross-component models (e.g., MMLM, or CCCM with multiple models), the classification threshold is also inherited to classify the neighboring samples of the current block into multiple groups, and the inherited multiple cross-component model parameters are further assigned to each group.

[0069] b. Inherit CCM information When applying a cross-component predictive encoding / decoding tool to the current block to generate a predicted signal, cross-component model (CCM) information, including model parameters, can be inherited from neighboring blocks. In some embodiments, the inherited CCM information of the cross-component model can be stored together with the inherited model parameters. CCM information can be inherited along with the inherited model parameters. The prediction for the current block can be generated based on the inherited CCM information and the inherited model parameters. CCM information may include, but is not limited to, (cross-component) prediction modes (e.g., CCLM, MMLM, CCCM, CCCM with multiple models, 2-parameter GLM, 3-parameter GLM (GLM with a luminance term), CCRM), information indicating whether nonlinear terms are used in the model, model indexes indicating which model shape is used in the convolutional model, classification thresholds for multiple models, information indicating whether non-downsampled samples are used in the convolutional model, downsampled filter flags, downsampled filter indexes when multiple downsampled filters are used, information indicating whether multiple downsampled filters are used, the number of neighboring lines used to derive the model, template types used to derive the model (e.g., top left, top, left), multiple model flags, post-filter flags, or model parameters.

[0070] In some embodiments, a hybrid CCCM model with various terms (e.g., spatial, gradient, positional, nonlinear, and bias terms) can be inherited. In addition to storing model parameters, the CCM information may also include a prediction pattern to indicate that the inherited model is a hybrid CCCM model with various terms. If there are multiple types of hybrid CCCM models, a model index can also be stored in the CCM information to indicate which type of hybrid CCCM model is being inherited. For example, gradient-based and position-based CCCM (GL-CCCM) might be a hybrid CCCM model consisting of a spatial term at the center position, two gradient terms in the horizontal and vertical directions, two positional terms X and Y relative to the horizontal and vertical positions, a nonlinear term, and a bias term. A prediction pattern can be stored in the CCM information to indicate that the inherited model is a GL-CCCM model.

[0071] c. Inheritance Spatial Proximity Model Parameters In some embodiments, the inherited model parameters may come from a block that is a direct neighbor. Models from blocks at predetermined locations are added to a CCP merge candidate list in a predetermined order. The CCP merge candidate list may include models from spatial, temporal, and non-adjacent neighbors, and / or models from a history table and / or from a default model.

[0072] A video encoder may signal an index to select a CCP merge candidate from a list. A video decoder may generate a corresponding current block predictor based on the selected inherited candidate model parameters. In some embodiments, the video encoder may signal a flag to indicate whether a CCP merge mode is used (e.g., after `cclm_mode_flag`). In some embodiments, an on / off flag is signaled to indicate whether the current block inherits cross-component model parameters from neighboring blocks (i.e., whether a CCP merge mode is used). This flag can be signaled by CU / CB, by PU, by TU / TB, by color component, or by chroma color component. In some embodiments, when the flag is true, an index is signaled to indicate which CCP merge candidate has been selected. If the current block inherits cross-component model parameters from neighboring blocks, the inherited candidate index is signaled. The index can be signaled (e.g., using truncated unary codes, Exp-Golomb codes, or fixed-length code signals) and shared between the current Cb and Cr blocks.

[0073] In some embodiments, the predefined positions and predefined order can be the same as the mutual merging pattern of spatial candidates. Figure 7 This describes the predefined locations of spatially neighboring blocks from which model parameters are inherited. The predefined order can be B. 0, A 0, B 1, A1 and B2 were added to the CCP merge candidate list because their corresponding model parameters were added.

[0074] In some embodiments, assuming the position, width, and height of the current block are (x, y), W, and H, respectively, the predefined position may include the position directly above the current block, such as (x + W>>1, y-1) or (x + (W+1)>>1, y-1), if W is greater than or equal to a threshold TH. The predefined position may also include the position to the left of the current block, such as (x-1, y+H>>1) or (x-1, y+(H+1)>>1), if H is greater than or equal to the threshold TH. TH can be 2, 4, 8, 16, 32, or 64. The predefined position includes being directly above (W>>1) or ((W>>1) - 1) if W is greater than or equal to TH, and being directly to the left (H>>1) or ((H>>1) - 1) if H is greater than or equal to TH.

[0075] In some embodiments, the maximum number of models inherited from spatial neighbors can be added to the CCP merge candidate list, and the maximum number is less than the number of predefined locations.

[0076] d. Inheritance time proximity model parameters In some embodiments, if the current slice / picture is a non-intra-frame slice / picture, model parameters can be inherited from blocks in the previously encoded slice / picture.

[0077] Figure 8 This conceptually illustrates Temporal Inherit Model Parameters. As shown in the figure, the current position is (x, y), and the block size is... The model parameters can be inherited from the block at positions (x', y'), (x', y' + h / 2), (x' + w / 2, y'), (x' + w / 2, y' + h / 2), (x' + w, y'), (x', y' + h), or (x' + w, y' + h) in the previously encoded slice / picture, where x' = x + Δx and y' = y + Δy. In some embodiments, if the prediction mode of the current block is intra-frame, Δx and Δy are set to 0. If the prediction mode of the current block is inter-frame, Δx and Δy are set to the horizontal and vertical motion vectors of the current block. In some embodiments, if the current block is inter-frame bidirectional prediction, Δx and Δy are set to the horizontal and vertical motion vectors in reference picture list 0. In some embodiments, if the current block is an inter-frame bidirectional prediction, then Δx and Δy are set as the horizontal and vertical motion vectors in the reference image list 1.

[0078] In some embodiments, if the current slice / image is a non-intra-frame slice / image, model parameters can be inherited from blocks in the previously encoded slice / image. In one embodiment, the current block position is (x, y), and the block size is... Two value sets and Defined as: In some embodiments, and All values ​​in the set are positive. Let... The inherited model parameters can come from the position in the previous encoded slice / image. The block.

[0079] In some embodiments, the current block position is (x, y), and the block size is The inherited model parameters can come from the position in the previous encoded slice / image. The block.

[0080] In some embodiments, ,For example In some embodiments, ,For example and .

[0081] In some embodiments, from proximity The location model is first added to the final cross-component prediction (CCP) merging candidate list. In some embodiments, models from proximity are used. The location model is first added to the final cross-component prediction (CCP) merge candidate list.

[0082] In some embodiments, it is set and For two fixed positive numbers, the inherited model parameters can be derived from positions in previously encoded slices / images. Let the current block position be (x, y) and the block size be... .set up and For two fixed positive numbers, the inherited model parameters can be derived from positions in previously encoded slices / images. The block.

[0083] In some embodiments, the current block position is (x, y), and the block size is The inherited model parameters can come from certain predefined locations in previously encoded slices / images. The block. For example, the position is inside the region corresponding to the current coding block, i.e. and Inherited model parameters can come from positions in The block. Another example is a position outside the region corresponding to the current coded block, i.e. and Inherited model parameters can come from positions in The block.

[0084] In some embodiments, the inherited model parameters may come from blocks at certain predefined locations. The predefined locations and inclusion order may be the same as in the inter-frame merge mode. The previously encoded image from which the inherited parameter model originates is subsequently referred to as the co-occurring image. In some embodiments, the previously encoded image from which the inherited parameter model originates, i.e., the co-occurring image, is one of the images in a reference list.

[0085] In some embodiments, the co-op image may be the same as the co-op image in the inter-frame merge mode. In some embodiments, the co-op image is marked in the image / slice header. Reference lists and reference indices are marked in the image / slice header. For example, the co-op image is selected as L0[0]. Another example is that the co-op image is selected as L1[0]. In some embodiments, the co-op image is selected as the image in the reference list that has the smallest difference in picture order count (POC) with the current image. (The picture order count is a value that indicates the temporal order of an image in a series of images.) For example, if the current image has a POC of 8, the images in reference list 0 have a POC of {7, 6, 5, 0}, and the images in reference list 1 have a POC of {7, 6, 5, 4}, then L0[0] (equivalent to L1[0]) is selected because it has the smallest POC difference. In some embodiments, if there are two images with the smallest POC difference from the current image, the image with the smaller POC is selected. In some embodiments, if two images have the smallest difference in Proof of Value (POC) compared to the current image, the image with the larger POC is selected. In some embodiments, if two images have the smallest difference in POC compared to the current image, the image with the smaller QP difference is selected. In some embodiments, if two images have the smallest difference in POC compared to the current image, the image with the smaller QP is selected. In some embodiments, if two images have the smallest difference in POC compared to the current image, the image with the larger QP is selected.

[0086] In some embodiments, the co-position image is selected from the reference list of images with the smallest QP difference from the current image. For example, if the QP of the current image is 28, the QP of the images in reference list 0 is {19, 26, 23}, and the QP of the images in reference list 1 is {23, 22, 21}, then L0[1] is selected. In some embodiments, if more than one image in the reference list has the smallest QP difference from the current image, the image with the smaller QP is selected. In some embodiments, if more than one image in the reference list has the smallest QP difference from the current image, the image with the larger QP is selected. In some embodiments, if more than one image has the smallest QP difference from the current image, the image with the smaller POC distance is selected. In some embodiments, the co-position image is selected as the image with the smallest QP in the reference list. In some embodiments, the co-position image is selected as the image with the largest QP in the reference list.

[0087] In some embodiments, the previously encoded image from which the inherited parameter model originates, i.e., the co-occurring image, is the most recently encoded I-image. Cross-component model information for the most recently encoded I-slice / image is stored in a long-term reference buffer.

[0088] In some embodiments, the predefined positions from which the co-location image and inherited parameter model originate are determined by the motion vectors of neighboring blocks. For example, if the current block position is (x, y) and the block size is... The inherited model parameters can come from blocks in the co-located image at positions (x', y'), (x', y' + h / 2), (x' + w / 2, y'), (x' + w / 2, y' + h / 2), (x' + w, y'), (x', y' + h), or (x' + w, y' + h), where x' = x + Δx and y' = y + Δy. In some embodiments, Δx and Δy are set as the L0 horizontal and vertical motion vectors of the neighboring blocks, and the co-located image is an L0 reference image indicated by the L0 motion vectors of the neighboring blocks. In some embodiments, if the neighboring blocks are bidirectional predictions, Δx and Δy are set as the L1 horizontal and vertical motion vectors of the neighboring blocks, and the co-located image is an L1 reference image indicated by the L1 motion vectors of the neighboring blocks. In some embodiments, the neighboring block is the block to the left of the current block. In some embodiments, the neighboring block is the block above the current block.

[0089] In some embodiments, the predefined location from which the inherited parametric model in the previously encoded slice / image originates is determined by the motion vectors of neighboring blocks. Let Δx and Δy be the horizontal and vertical displacements determined based on the motion vectors of selected neighboring blocks, the current block position is (x, y), and the block size is... The inherited model parameters can come from the block at position (x', y'), where x' = x + Δx and y' = y + Δy, or x' = x + w / 2 + Δx and y' = y + h / 2 + Δy.

[0090] In some embodiments, the inherited model parameters may also come from positions in the pattern described in the preceding paragraphs. These positions are centered at (x', y'), where x' = x + Δx and y' = y + Δy, or x' = x + w / 2 + Δx and y' = y + h / 2 + Δy. That is, the predefined positions are represented as... The inherited model parameters can come from ,in and The horizontal and vertical displacements are determined based on the motion vectors of selected neighboring blocks. For example, suppose the current block size is... Two value sets and Defined as: exist and All values ​​are positive. Inherited model parameters can be derived from positions in previously encoded slices / images. The block. For example, let... and These are two fixed positive numbers. The inherited model parameters can be derived from positions in previously encoded slices / images. The block. Another example is that inherited model parameters can come from the previous encoded slice / image. Some predefined locations of blocks. These locations can be Another example is that these locations could be... .

[0091] In some embodiments, neighboring blocks can be located at a predefined location. For example, the location can be... Figure 7 The predefined location is A0. Predefined locations can also be A1, B0, B1, or B2. If the block at the predefined location is not an internal block, neighboring blocks are not selected.

[0092] In some embodiments, when selecting a neighboring block, there may be a predefined list of locations. These locations are placed according to the inspection order. For example, location B could be... 0, A 0, B 1, A1 and B2, such as Figure 7 As shown. The selected neighboring block can be the first position in the list that spans a frame block. The L0 motion vector is selected. If the L0 motion vector is unavailable, the L1 motion vector is selected. In another example, the L1 motion vector is selected. If the L1 motion vector is unavailable, the L0 motion vector is selected.

[0093] In some embodiments, if a co-located image has been determined (e.g., using the methods described in the preceding paragraphs of this section), positions in a predefined list of positions are checked in a predefined checking order. The motion vector selected is the first one whose reference image is a co-located image. For example, position B could be B. 0, A 0, B 1, A1 and B2, such as Figure 7 As shown. For each position, first check the L0 motion vector, then check the L1 motion vector. That is, the checking order is (B 0, L0), (B 0, L1), (A 0, L0), (A 0, L1), ..., (B) 2,L1). In some embodiments, the L1 motion vector is checked first, and then the L0 motion vector is checked.

[0094] In some embodiments, the inherited model parameters may also be derived from the positions in the above-described pattern. The position is located at (x', y'), where x' = x + Δx and y' = y + Δy. The horizontal and vertical displacements Δx and Δy are determined based on the motion vectors of the selected neighboring blocks. For example, if the reference image and the co-location image of the selected motion vector are the same image, Δx equals the horizontal portion of the selected motion vector, and Δy equals the vertical portion. If the horizontal or vertical portion of the selected motion vector is a fraction, Δx equals the rounded value of the horizontal portion of the selected motion vector, and Δy equals the rounded value of the vertical portion. The rounding method used may include, but is not limited to, rounding towards negative infinity, rounding towards positive infinity, rounding towards zero, or rounding to the nearest integer (e.g., rounding away from zero, rounding half up, rounding half down, ...). In another example, if the reference image and the co-location image of the selected motion vector are not the same image. The reference image can be one of the images in the reference list, while the co-image is marked in the image / slice header. Let the POC distance between the current image and the reference image of the selected motion vector be tb, the POC distance between the current image and the co-image be td, and the selected motion vector be (mv_x, mv_y). Δx = mv_x * (td / tb) and Δy = mv_y * (td / tb). If mv_x * (td / tb) or mv_y * (td / tb) is a fraction, Δx is equal to the rounded value of mv_x * (td / tb) or the rounded value of the horizontal portion of the selected motion vector, and Δy is equal to the rounded value of mv_y * (td / tb) or the rounded value of the vertical portion of the selected motion vector. The rounding method used may include, but is not limited to, the following: rounding to negative infinity, rounding to positive infinity, rounding to zero, or rounding to the nearest integer (e.g., rounding away from zero, rounding up by half, rounding down by half, etc.).

[0095] In some embodiments, the inherited model parameters are derived by reconstructing samples using the luminance and chrominance of the corresponding blocks. Let the current block position be (x, y) and the block size be... A co-position block is a block located at position (x', y') in a co-position image, and its size is [size missing]. This occurs when the inherited model comes from position (x', y'). In another example, a co-positional block can be a block located at position (x', y') in the co-positional image, with a block size of... Where m and n are fixed positive values. For example, a sibling block can be located at (x, y). In another example, if Δx and Δy are the L0 horizontal and vertical motion vectors of neighboring blocks, and the sibling picture is the L0 reference picture indicated by the L0 motion vectors of neighboring blocks, the sibling block can be located in the sibling picture. (x', y') can be a position within the pattern described in the preceding paragraph. For example, (x', y') could be... .

[0096] In some embodiments, the cross-component parameter model can inherit from more than one previously encoded image. The cross-component parameter model can inherit from any image in a set of images containing N previously encoded images. An index can be sent / parsed in the bitstream to indicate the selected image. The index ranges from 0 to N-1. In some embodiments, images with smaller POC differences from the current image are associated with smaller indexes. In another sub-implementation, images with smaller QP differences from the current image are associated with smaller indexes. In some embodiments, images with smaller QPs are associated with smaller indexes. In some embodiments, images with larger QPs are associated with smaller indexes.

[0097] e. Inheriting the proximity model of non-proximity space In some embodiments, the inherited model parameters may come from non-nearest spatial neighbor blocks (blocks not adjacent to the current block). Models from predetermined locations are added to the CCP merge candidate list in a predetermined order. In some embodiments, the predetermined locations and predetermined order are the same as the locations and order of non-nearest spatial neighbor candidates used in the interactive merge mode.

[0098] Figures 9A-9B This diagram illustrates the current block 900 and its non-neighboring spatial neighboring blocks, from which model parameters may be inherited. The diagram also illustrates the predetermined locations and their predetermined order. Figure 9A The non-proximity spatial locations are displayed according to a predetermined order based on the first mode (mode 1). Figure 9B This displays the non-proximity spatial locations according to a predetermined order based on Mode 2. The positions of the numbered squares are predetermined locations. The numbers within each square indicate the predetermined order. Positions in Mode 1 are added to the CCP merge candidate list before positions in Mode 2. The distance between each predetermined location is proportional to the width and height of the current block.

[0099] In some embodiments, there exists a maximum number of inherited models from non-nearby spatial neighbors that can be added to the CCP merge candidate list, and this maximum number is less than the number of predetermined locations.

[0100] In some embodiments, the current block position is set to (x, y) and the block size is... Two value sets and Defined as: All in and The values ​​in the equations are all positive. Let x' = x + Δx and y' = y + Δy. Inherited model parameters can come from the positions determined by x' and y'. For example, inherited model parameters can come from the position... The block. Another example, let's say... and These are two fixed positive numbers. Inherited model parameters can come from position. The block. Another example is that inherited model parameters can come from slices / images relative to the previous encoding. Some predefined locations of blocks. These locations can be Another example is that these locations could be... Another example is that the position can be (x', y'), (x', y' + h / 2), (x' + w / 2, y'), (x' + w / 2, y' + h / 2), (x' + w, y'), (x', y' + h), or (x' + w, y' + h).

[0101] In some embodiments, if the prediction mode of the current block is based on the block vector of the reference current image (e.g., intra-block copy mode (IBC) or IntraTMP), Δx and Δy can be set according to the horizontal and vertical block vectors of the current block. For example, Δx and Δy can be equal to the horizontal and vertical block vectors of the current block. In some embodiments, Δx and Δy can be set according to the horizontal and vertical block vectors of neighboring blocks. For example, Δx and Δy can be equal to the horizontal and vertical block vectors of neighboring blocks.

[0102] f. Inheriting model parameters from the history table In some embodiments, inherited model parameters may come from a cross-component model history table. The history table stores CCM information for valid previously encoded blocks. A valid previously encoded block refers to any block containing valid CCM information. Cross-component models in the history table can be added to a CCP merge candidate list in a predefined order. In some embodiments, the order in which historical candidates are added can be from the beginning to the end of the table. In some embodiments, the order in which historical candidates are added can be from the end to the beginning of the table.

[0103] In some embodiments, a cross-component model history table may be maintained to store previous cross-component models (i.e., CCM information), and the cross-component model history table may be reset at the beginning of the current image, current tile, current tile, every M CTU row, or every N CTU, where N and M can be any value greater than 0. In some embodiments, the cross-component model history table may be reset at the end of the current image, current tile, current tile, current CTU row, or current CTU.

[0104] In some embodiments, multiple history tables are used to store different types of cross-component models. For example, the first history table stores a single model, and the second history table stores multiple models. Another example is that the first history table stores gradient models, and the second history table stores non-gradient models. Yet another example is that the first history table stores simple linear models (e.g., y = ax + b), and the second history table stores complex models (e.g., CCCM).

[0105] In some embodiments, when adding historical candidates to the CCP merge candidate list from multiple historical tables, the addition order can be from the beginning to the end of a table, and then the next historical table can be added in the same or reverse order.

[0106] g. Inherit from the fusion pattern Fusion mode refers to the mode of fusing two predictions to generate a final prediction. In chroma intra-frame fusion mode, a chroma intra-frame prediction generated without using cross-component prediction (CCP) encoding / decoding tools (e.g., CCLM, MMLM, CCCM) is fused with another chroma intra-frame prediction generated using cross-component prediction encoding / decoding tools. For example, a non-CCLM-coded intra-frame prediction and a CCLM-coded intra-frame prediction are fused together to obtain the final intra-frame prediction.

[0107] In some embodiments, when inheriting cross-component model parameters from blocks / positions encoded by the chroma intra-fusion mode, the model parameters used to obtain CCP-encoded intra-prediction are inherited and further refined. In some embodiments, in addition to inheriting and refining the CCP model parameters, the fusion weights and the encoding / decoding modes for non-CCP-encoded intra-prediction are also inherited. That is, the chroma intra-fusion mode is inherited.

[0108] h. Disseminating CCM information based on MV or BV. In some embodiments, after a block is decoded, the cross-component model (CCM) information of the current block is derived and stored for subsequent reconstruction of neighboring blocks. During reconstruction, neighboring blocks can inherit model parameters from the current block. CCM information (as described in Section III.b above) may include, but is not limited to, prediction patterns (e.g., CCLM, MMLM, CCCM), GLM pattern indexes, model parameters, or classification thresholds.

[0109] In some embodiments, if the current block is not encoded in a cross-component prediction mode or a mode that includes cross-component prediction, and block vectors are available in the current block (e.g., the current block is encoded in IBC or IntraTMP mode, or the current chroma block is encoded in direct block vector mode (as described in Section II.b above)), the CCM information of the current block can be derived by copying the CCM information of the reference block pointed to by the block vector.

[0110] Figure 10 This illustrates the propagation of CCM information (CCM Infopropogation) from a reference block pointed to by a block vector to the current block. The diagram illustrates a block A, which is referenced by a block B using BV 1011. Block B, in turn, is referenced by a block C using BV 1012. Block A is encoded using a set of CCM information 1020 via cross-component prediction (CCP).

[0111] When encoding or decoding block B, its block vector (BV 1011) is used to identify block A, and the cross-component model information 1020 of block A is copied as the cross-component model information of block B and stored. When encoding or decoding block C, its block vector (BV 1012) is used to identify block B, and the cross-component model information 1020 copied from block A by block B is copied as the cross-component model information of block C and stored. Thus, the cross-component model information 1020 is effectively propagated from block A to block B, and then to block C, following block vectors 1011 and 1012 (although block C only needs to access block B). For example, when a block vector (e.g., BV 1011) is available for block B, the cross-component model information of block B is copied from the reference block of block B, block A, which is indicated by block vector 1011. For example, when a block vector (e.g., BV 1012) is available for block C, the cross-component model information for block C is copied from its reference block, block B, which is indicated by block vector 1012. Although block B does not perform cross-component predictive coding, the cross-component model information for block A has been copied and stored in block B. Therefore, the cross-component model information for block C is effectively propagated from block A, even though block C only needs to access block B. In some embodiments, if a reference block pointed to by a block vector also does not perform cross-component prediction, but a block vector is also available for the reference block, the cross-component model information for the reference block is copied from the cross-component model information of a further reference block of the reference block, indicated by the block vector of the reference block. For example, if a block vector (i.e., BV 1012) is available for current block C, and a block vector (i.e., BV 1011) is also available for its reference block, block B, since the cross-component model information for block B is copied from block A, the cross-component model information for block A is also propagated to current block C.

[0112] In some embodiments, when multiple block vectors are available for the current block (e.g., when the block vectors are bidirectional, or when the current chroma block is co-located with multiple luma blocks and more than one luma block has a block vector), multiple reference blocks can be located using multiple block vectors, and more than one reference block may store cross-component model information. If one of the reference blocks is intra-coded and has cross-component model information, the cross-component model information of that reference block may be copied and stored as the cross-component model information of the current block.

[0113] Figure 11This describes the propagation of cross-component model information (CCM Info propagation) from one or more reference blocks to the current block based on one or more block vectors. As shown in the figure, block F has two block vectors 1110 and 1111 (BV0 and BV1) as reference blocks G and H. Block G is intra-coded and has CCM Info 1120. Block H is not intra-coded and may or may not have CCM Info. When block F is the current block, following BV0, the CCM Info 1120 of block G may be copied and stored as the CCM Info of block F. In other words, the CCM Info of block G is propagated to block F through one of the two block vectors of block F (in this case, block vector 1110 or BV0). For example, suppose block F has two block vectors (i.e., BV0 and BV1) and two reference blocks G and H. Block G is intra-coded and has CCM Info. The CCM Info of block F is copied from block G, which is encoded in CCM Info mode.

[0114] In some embodiments, when the current block has multiple block vectors, the cross-component model information of the current block is a combination of all or a portion of the cross-component model information of its reference blocks. Methods for combining multiple cross-component model information will be described in Section III.n below (“Inheriting Multiple Cross-Component Models”).

[0115] In some embodiments, when the current slice is a non-intra-slice (e.g., a P-slice or a B-slice), the cross-component model of the current block is derived and stored for later reconstruction using neighboring blocks that inherit neighbor model parameters. In some embodiments, when the current block is inter-coded, the cross-component model information of the current inter-coded block is copied from a reference block in a reference image located by motion vector localization of the current inter-coded block.

[0116] Figure 12 This illustrates the propagation of Cross-Component Model Information (CCM Info) from a reference block to the current block via motion vectors. The icon shows block A in image 1201. Inter-frame decoded block B in image 1202 references block A using MV 1211. Block B is then referenced by inter-frame decoded block C in image 1203 using MV 1212. Block A is encoded using a set of Cross-Component Model Information (CCM Info) 1220 via Cross-Component Prediction (CCP). After block B is encoded as the current block, the CCM Info 1220 is copied from reference block A and stored as the CCM Info for block B. For example, if block B is inter-frame decoded, then the CCM Info for block B is copied from the reference block (block A) of block B, which contains the CCM Info.

[0117] In some embodiments, if a reference block in a reference frame is also inter-frame decoded, and that reference block stores CCM information (the CCM information of that reference block may be copied from another reference block in another reference frame), then the CCM information of the current inter-frame decoded block is derived by copying the CCM information from its reference inter-frame decoded block. Figure 12 In the example, block C is inter-coded with reference to block B via motion vector 1212. Since block B is inter-coded and its CCM information is copied from block A, the CCM information 1220 of block A is effectively propagated to the current block C via block B, even if block B is not CCP-coded. Furthermore, since the CCM information 1220 of block A has been copied and stored in block B, the video codec only needs to access block B to obtain the CCM information when deriving CCM information for block C. For example, if the current block C is inter-coded and its reference block, block B, is also inter-coded, the CCM information of block B is also propagated to the current block C because it is copied from block A. For example, if block C has a motion vector (e.g., motion vector 1212) available, the CCM information of block C is copied from its reference block B, which is indicated by the motion vector (motion vector 1212). Although block B is not CCP encoded, the CCM information of block A has been copied and stored in block B. Therefore, the CCM information of block C is effectively propagated from block A, even though block C only needs to access block B.

[0118] In some embodiments, when the current block is inter-frame encoded using bidirectional prediction, if one of the two reference blocks is intra-coded and has CCM information, the CCM information of that reference block in the reference picture is copied for the current block and stored.

[0119] Figure 13This illustrates the propagation of CCM information (CCM Infopropogation) from a reference block to the current block using dual-prediction motion vectors. As shown in the figure, block F is inter-coded using dual-prediction and has two motion vectors 1310 and 1311 (MV0 and MV1), referencing blocks G and H respectively. Block G is intra-coded and has CCM information 1320. Block H is not intra-coded and may or may not have CCM information. During decoding, or when block F is the current block, CCM information 1320 is copied from block G and stored as the CCM information for block F. For example, suppose block F is inter-coded using dual-prediction and has reference blocks G and H. Block G is intra-coded and has CCM information. The CCM information for block F is copied from block G. In some embodiments, when the current block is inter-coded using bidirectional prediction, the CCM information of the current block is a combination of the CCM information of its reference blocks. The method for combining multiple CCM information will be described in Section III.n below ("Inheriting Multiple Cross-Component Models").

[0120] In some embodiments, after a block is decoded, the cross-component model (CCM) information of the current block is derived and stored for use in the reconstruction of subsequent neighboring blocks. During reconstruction, neighboring blocks may inherit the model parameters of the current block. CCM information may include, but is not limited to, prediction modes (e.g., CCLM, MMLM, CCCM), GLM mode indexes, model parameters, or classification thresholds. If the current block is inter-frame encoded or decoded, or if block vectors are available in the current block (e.g., the current block is encoded in IBC or IntraTMP mode, or the current chroma block is encoded in direct block vector mode), the CCM information of the current block can be derived by copying the CCM information of the reference block pointed to by the motion vector or block vector. In some embodiments, if the reference block pointed to by the motion vector or block vector also does not have cross-component prediction, but motion vectors or block vectors are available on the reference block, the CCM information of the reference block is copied from the CCM information of the reference block of the reference block, indicated by the motion vector or block vector.

[0121] Figure 14Blocks A, B, and D are described. Block D has block vectors available, and block B has motion vectors available. Block A references block B by motion vector 1410, and block B references block D by block vector 1411. Block A has CCM information 1420. CCM information 1420 is copied from block A to block B, and then the CCM information of block B is copied to block D. In other words, CCM information 1420 is propagated from block A to block B via motion vector 1410 and block vector 1411, and then to block D. For example, if block D has block vectors available and its reference block B has motion vectors available, since the CCM information of block B is copied from block A, the CCM information of block A is also propagated (CCMInfo propagation) to the current block D.

[0122] j. Available time candidate regions In some embodiments, to limit buffer / storage resource requirements, the available range of temporal candidates may be limited. The temporal candidates mentioned in this section refer to candidates that inherit model parameters from blocks in previously encoded slices / images, as described in Section III.d above, “Inheriting Temporally Proximity Model Parameters.” For example, assuming the current block position is (x, y), the parameter model inherited from the previously encoded slice / image could come from the position (x + Δxi, y + Δyi), where i ranges from 1 to M, and M is a positive integer greater than 0. Δxi and Δyi are predefined displacements.

[0123] For example, assuming the current block is located at (x, y), the position of the previously encoded slice / image from which the inherited parameter model comes can be (x + dx + Δxi, y + dy + Δyi), where i ranges from 1 to M, and M is a positive integer greater than 0. Δxi and Δyi are predefined displacements. dx and dy are determined by the motion vectors of the current block's neighboring blocks. Details on how to determine the motion vectors are described in Section III.d, "Inheriting Temporal Proximity Model Parameters," above.

[0124] For example, assuming the current block position is (x, y), the position of the previously encoded slice / image from which the inherited parameter model comes can be (x + dx + Δxi, y + dy + Δyi), where i ranges from 1 to M, and M is a positive integer greater than 0. Δxi and Δyi are predefined displacements. If the prediction mode of the current block is inter, dx and dy are set to the horizontal and vertical components of the current block's motion vector. If the horizontal or vertical component of the motion vector is a fraction, dx is set to the rounded value of the horizontal component of the motion vector, and dy is set to the rounded value of the vertical component of the motion vector.

[0125] The rounding method used may include, but is not limited to, rounding towards negative infinity, rounding towards positive infinity, rounding towards zero, rounding to the nearest integer (e.g., rounding away from zero, rounding up by half, rounding down by half, etc.), or rounding to the nearest predefined precision (e.g., rounding to the nearest k-pixel or 1 / k-pixel precision position, where k can be 2, 4, 8, 16, or 32). If the prediction mode of the current block is IBC or IntraTMP, dx and dy are set to the horizontal and vertical block vectors of the current block. If the horizontal or vertical portion of the block vector is a fraction, dx is set to the rounded value of the horizontal portion of the block vector, and dy is set to the rounded value of the vertical portion of the block vector. The rounding method used may include, but is not limited to, the following: rounding to negative infinity, rounding to positive infinity, rounding to zero, rounding to the nearest integer (e.g., rounding away from zero, rounding up by half, rounding down by half, etc.), or rounding to the nearest predefined precision (e.g., rounding to the nearest k-pixel or 1 / k-pixel precision position, where k can be 2, 4, 8, 16, or 32).

[0126] k. Construct a candidate list In some embodiments, the CCP merging candidate list is constructed by adding candidates in a predefined order until a maximum number of candidates is reached. The added candidates may include, but are not limited to, all or some of the previously mentioned candidates. For example, the predefined order could be spatially adjacent candidates, temporally adjacent candidates, spatially non-adjacent candidates, historical candidates, and then the default candidate.

[0127] In some embodiments, if all predefined neighboring and historical candidates have been added but the maximum number of candidates has not been reached, some default candidates are added to the CCP merged candidate list until the maximum number of candidates is reached. In some embodiments, the default candidates may be CCLM models. Scaling parameters It comes from the set {0, 1 / 8, –1 / 8, 2 / 8, –2 / 8,…., N / 8, –N / 8}, where N is a positive integer.

[0128] The offset parameter β can be Alternatively, it can be derived based on neighboring luminance and chrominance samples. For example, if the average values ​​of neighboring luminance and chrominance samples are lumaAvg and chromaAvg, .

[0129] In some embodiments, the inclusion order of default candidates may depend on scaling parameters. The absolute value and sign. For example, the default candidates are added to the CCP merge candidate list in the following order: 0, 1 / 8, –1 / 8, 2 / 8, –2 / 8, …, N / 8, –N / 8.

[0130] In some embodiments, the default candidate can be an earlier candidate refined with an incremental scaling parameter. The earlier candidate is a CCLM model. If the scaling parameter of the earlier candidate is... The default scaling parameter for candidates is ( +Δ For example, Δ It can be 1 / 8, -1 / 8, 2 / 8, -2 / 8, ..., N / 8, -N / 8, where N is a positive integer. The offset parameter β can be based on ( +Δ The value is derived from the average of the luminance and chrominance samples neighboring the current block. In some embodiments, an earlier candidate is the first CCLM candidate added to the CCP merge candidate list. In some embodiments, the inclusion order of the default candidates may depend on the refinement Δ. The absolute value and sign. For example, for Δ The default candidates are added to the CCP merge candidate list in the following order: 0, 1 / 8, –1 / 8, 2 / 8, –2 / 8, …, N / 8, –N / 8.

[0131] m. Reorder the candidates in the list Candidates in the CCP merge candidate list can be reordered to reduce the syntactic overhead of tagging selected candidate indices. In some embodiments, the reordering rules may depend on the encoding / decoding information of neighboring blocks. For example, if the neighboring block above or to the left is encoded by MMLM, MMLM candidates in the list can be moved to the head of the current list. Similarly, if the neighboring block above or to the left is encoded by Single Model LM (i.e., CCLM) or CCCM, Single Model LM or CCCM candidates in the list can be moved to the head of the current list. Likewise, if GLM is used by the neighboring block above or to the left, GLM-related candidates in the list can be moved to the head of the current list.

[0132] In some embodiments, the reordering rule is based on model error (i.e. template cost) by applying a candidate model to the current block of a neighboring template and then comparing it with the error of the reconstructed sample of the neighboring template (i.e. the difference with the reconstructed sample of the neighboring template).

[0133] For example, suppose the size of the adjacent template above the current block is The size of the template to the left of the current block is Suppose there are K models (which can be CCLM or 2-parameter GLM) in the current candidate list, and and These are the final scaling and offset parameters after inheriting from candidate k. The model error of candidate k, derived from the upper neighboring template, is: in, and These are the luminance reconstructed sample (e.g., after downsampling or applying GLM mode) and chrominance reconstructed sample at position (i, j) in the upper template, and and Similarly, the model error for candidate k based on its left-neighbor template is: in and These are the luminance reconstructed sample (e.g., after downsampling or GLM mode) and chrominance reconstructed sample at position (m, n) in the left template, and and Then the model error for candidate k is: After calculating the model errors for all candidates, a list of model errors may be obtained. Then, the video codec can reorder the candidate indices in the inherited candidate list (i.e., the CCP merged candidate list) by sorting the model error list in ascending order. For example, a model error could also be the SATD between the predicted chroma sample on the template generated from the luminance sample on the neighboring template and the reconstructed chroma sample on the neighboring template.

[0134] In some embodiments, if candidate k is predicted using CCCM, then and It may be defined as: in ,and These are the final filtering coefficients after inheriting candidate k. P and B are the nonlinear term and bias term, respectively. In some embodiments, if the aforementioned neighbor template is unavailable, then... Similarly, if the adjacent template on the left is unavailable, then If neither template is available, the candidate index reordering method using model error should not be applied.

[0135] n. Inheriting multiple cross-component models In some embodiments, if the current candidate list is N in size, the video codec may select k candidates from a total of N candidates (where k ≤ N). These k cross-component models can be combined into a final cross-component model by a weighted average of their corresponding model parameters. For example, if a cross-component model has M parameters, the j-th parameter of the final cross-component model is the weighted average of the j-th parameters of the k selected candidates, where j is 1…M. The final prediction is then generated by applying the final cross-component model to the corresponding brightness reconstruction samples. For example, if there are two candidate models... and The final cross-component model is ,in It is a weighting factor, which can be predefined or implicitly derived from the cost of neighboring templates, while It is the x-th model parameter of the y-th candidate. For example, using template cost (e.g., as defined in Section III.m above, "Candidates in the Reordering List"), the corresponding template costs of the two candidates are and ,So yes Another example is that two candidate models might include one from a spatially neighboring candidate and the other from a non-neighboring spatial candidate or a historical candidate. If a spatially neighboring candidate is unavailable, then both candidate models are from non-neighboring spatial candidates or historical candidates.

[0136] In some embodiments, the video codec may combine multiple cross-component models into a single final cross-component model. For example, the video codec may select a first model from a first candidate and a second model from a second candidate to form a multi-model pattern (e.g., an MMLM or MM-CCCM). The selected candidate may be a candidate encoded with CCLM / MMLM / GLM / CCCM. The multi-model classification threshold may be an offset parameter between the two selected patterns (e.g., an offset in CCLM / ...). or in CCCM or The average value of the light and chromaticity samples of the current block. In some embodiments, the classification threshold is set as the average value of the neighboring light and chromaticity samples of the current block.

[0137] o. Store temporary models in the index table In some embodiments, CCM information from previously encoded slices / images is stored in a table, and an image-level index buffer is created to store the table's index. The size of the index buffer is the same as the image.

[0138] Figure 15A conceptual diagram illustrates an image-level index buffer for storing CCM information storage table indexes. When a pixel patch in a future image selects the current image as its co-image (using the method described in Section III.d above), a set of CCM information (including model parameters) from the current image may be inherited as a temporary candidate (as described in Section III.d above) to encode the pixel patch in the future image in a cross-component merging mode. The current image is labeled as CCM image 1500.

[0139] CCM image 1500 has a corresponding index buffer 1520. When referencing CCM information at a location (x, y) (which could be a pixel location or a block location) within CCM image 1500, an index value is retrieved from the location (x, y) in index buffer 1520. If the index value indicates that no CCM information is available at location (x, y), the CCM information cannot be referenced. Otherwise, the CCM information to be referenced is obtained from the item indicated by the index value in index CCM table 1530. In the example, the index value of location (x, y) in index buffer 1520 is '2', corresponding to index position 2 in index CCM table 1530. Index position 2 in index CCM table 1530 stores a set of CCM information labeled "CCP2". (Index value '0' indicates no CCM information). To enable future images to reference CCM information from the current image, after encoding or decoding the current image, the CCM information from the current image is stored in the corresponding indexed CCM table (e.g., Figure 15 (1530 in the middle) and store the corresponding index value in the corresponding position in the index buffer (e.g., Figure 15 (1520 in the middle).

[0140] In some embodiments, a table storing CCM information (e.g., Figure 15 Index table 1530 (also known as the CCM table) is an image-level table. CCM information from different images is stored in separate tables. In some embodiments, a single table is created to store CCM information from all images. In some embodiments, a table is created for each time ID (or for each time layer ID). CCM information for layers with the same time ID is stored in the same table. In some embodiments, several tables are used to store CCM information from a single image. An image can be divided into several regions, each corresponding to its own table.

[0141] In some embodiments, after CCM information is stored in the corresponding table at position (x, y) of the current encoded / decoded image, the table index value of the CCM information is saved at position (x, y) of the index buffer of the current encoded / decoded image. If no CCM information is available at position (x, y) (e.g., the CU covering position (x, y) is not encoded in a cross-component prediction mode, such as CCLM, MMLM, CCCM, CCCM multi-model, chroma fusion, or other cross-component models), the value of position (x, y) in the index buffer is set to indicate that no CCM information is available.

[0142] In some embodiments, if no CCM information is available at the current encoding / decoding image position (x, y), the index value of the position (x, y) in the index buffer of the current image's co-image can be stored at the current encoding / decoding image's index buffer position (x, y). In some embodiments, if no CCM information is available at the current encoding / decoding image position (x, y), and the index value of the position (x, y) in the index buffer of the current image's co-image indicates a saved model (i.e., stored CCM information) in the corresponding table of the co-image, the saved model can be inserted into the table corresponding to the current position, and the index of the saved model in the current table (i.e., the table corresponding to the current position) can be stored at the current encoding / decoding image's index buffer position (x, y). Figure 16This illustrates the copying of CCM information from the collocated picture's index table to the current picture's index table. The figure illustrates a current picture 1600 with an index buffer of current picture 1605 for accessing CCM information. At position (x, y), current picture 1600 has no available CCM information, as indicated by the index value '0' in index buffer 1605. On the other hand, collocated picture 1620 has CCM information 1633 ("CCP3") stored at position (x, y) in index table 1630, as indicated by the index value '3' in index buffer 1625 of collocated picture 1620. To make CCM information 1633 available to current picture 1600, CCM information 1633 is copied from index table 1630 to the current picture's index table 1610. The CCM information 1633 in index table 1610 is indicated by the index value '2' at position (x, y) of the index buffer 1605 of the current image.

[0143] In some embodiments, if no CCM information is available at the current encoding / decoding image position (x, y), and a block vector (Δx, Δy) is available at that position (x, y) (e.g., the block at position (x, y) can be IBC encoded or IntraTMP encoded), then the index value of position (x+Δx, y+Δy) in the index buffer can be stored at position (x, y) of the current encoding / decoding image's index buffer.

[0144] Figure 17This conceptually illustrates the derivation and storage of CCM information based on block vector copy index buffer entries. As shown, a CCM image 1700 (the current image that has been encoded / decoded, or partially reconstructed for reference in subsequent encoding) has an index buffer 1705 for locating CCM information in an index table 1710. As shown, at position (x, y), CCM image 1700 has no available CCM information, as indicated by the value '0' at the corresponding position in index buffer 1705. However, position (x, y) is encoded in a mode (e.g., IBC, IntraTMP) using a BV(Δx, Δy) pointing to another position (x', y') = (x+Δx, y+Δy) in the reference image 1700. Position (x', y') has CCM information, as indicated by the corresponding non-zero index value ('4') in index buffer 1705. Then, the index value ('4') of position (x', y') is copied at position (x, y) in the index buffer. This allows the block at position (x, y) to be encoded using the CCM information pointed to by the index value ('4').

[0145] In some embodiments, if no CCM information is available at the current encoding / decoding image position (x, y), and multiple block vectors are available (Δxi, Δyi), 0

[0146] ​In some embodiments, if no CCM information is available at position (x, y) of the current encoded / decoded image, and the block at position (x, y) is encoded across frames, and the motion vector is (Δx, Δy), then the index value (also indicated by the motion vector) of position (x+Δx, y+Δy) in the index buffer of the reference image can be stored at position (x, y) of the current encoded / decoded image. In some embodiments, if no CCM information is available at position (x, y) of the current encoded / decoded image, and the block at position (x, y) is encoded across frames, and the motion vector is (Δx, Δy), then the index value (indicated by the motion vector) of position (x+Δx, y+Δy) in the index buffer of the reference image can be used to retrieve CCM information from the table corresponding to the reference image. The retrieved CCM information is then stored in the table corresponding to the current image. The table index value of the retrieved CCM information is stored at position (x, y) in the index buffer of the current encoded / decoded image.

[0147] Figure 18 This illustrates how index table entries are copied and stored based on motion vectors to derive and store CCM information. The diagram illustrates a current picture 1800 with an index buffer of current picture 1805, used to access CCM information in the index table of current picture 1810. At position (x, y), current picture 1800 has no available CCM information, as indicated by the index value '0' in index buffer 1805. Position (x, y) is encoded across frames using an MV 1802, which references the reference picture 1820 at position (x', y') = (x+Δx, y+Δy). Reference Picture 1820 has CCM information 1832 at position (x', y') stored in Index Table of Ref Pic 1830, as indicated by index value '2' in Index Buffer 1825. To make CCM information 1832 available to the current picture 1800, CCM information 1832 is copied from Index Table 1830 to Index Table 1810 of the current picture 1800. The CCM information 1832 in Index Table 1810 is indicated by index value '3' at position (x, y) in Index Buffer 1805 of the current picture 1800.

[0148] In some embodiments, if no CCM information is available at position (x, y) of the current encoded / decoded image, and the block at position (x, y) is encoded across frames, and the motion vector is bidirectional (Δx0, Δy0) and (Δx1, Δy1), the index value (also indicated by the motion vector) of a position (x+Δx0, y+Δy0) or (x+Δx1, y+Δy1) in the index buffer of the reference image can be stored at position (x, y) of the current encoded / decoded image's index buffer.

[0149] In some embodiments, if no CCM information is available at position (x, y) of the current encoded / decoded image, and the block at position (x, y) is encoded across frames, and the motion vectors are bidirectional (Δx0, Δy0) and (Δx1, Δy1), the index value (also indicated by the motion vector) of a position (x+Δx0, y+Δy0) or (x+Δx1, y+Δy1) in the index buffer of the reference image can be used to retrieve CCM information from the table corresponding to the reference image. The retrieved CCM information is then stored in the table corresponding to the current image. The table index value of the retrieved CCM information is stored at position (x, y) in the index buffer of the current encoded / decoded image.

[0150] In some embodiments, when CCM information is deleted from a table, all values ​​in the index buffer that indicate the use of the CCM information to be deleted are reset to indicate that no CCM information is available.

[0151] In some embodiments, the size of the table used to store CCM information (e.g., index table 1530) has a maximum size limit. A high-level syntax can be signaled in SPS, PPS, PH, or SH to indicate the maximum size limit. If the table has reached its maximum size when attempting to store new CCM information, the new CCM information will not be stored. In some embodiments, if the table has reached its maximum size when attempting to store new CCM information, the oldest stored CCM information will be deleted to free up space in the table.

[0152] In some embodiments, the CCM information to be stored in the table can be explicitly signaled in the bitstream, in SPS, PPS, PH, or SH. The corresponding positions of the CCM information can also be signaled.

[0153] In some embodiments, the table may be reset at the beginning of an Instantaneous Decoder Refresh (IDR) image. In some embodiments, the table may be reset after an IDR image. In some embodiments, the table may be reset at the beginning of a Clean Random Access (CRA) image. In some embodiments, the table may be reset after a CRA image. In some embodiments, the reset mechanism may be the same as that used in the parameter set or reference image.

[0154] In some embodiments, the indices stored in the index buffer can only be referenced by units greater than or equal to the smallest decoding unit. For example, if the smallest decoding unit is 4x4, the index can be referenced by an 8x8 grid. That is, an 8x8 block has the same index value. To retrieve the index value of position (x, y), the position (x, y) can be rounded to a point on the grid (e.g., (x>>3)<<3, (y>>3)<<3) or its nearest point on the grid.

[0155] Any of the aforementioned methods can be implemented in an encoder and / or decoder. For example, any of the proposed methods can be implemented in an inter-frame / intra-frame / prediction module of the encoder, and / or in an inter-frame / intra-frame / prediction module of the decoder. Alternatively, any of the proposed methods can be connected as a circuit to the inter-frame / intra-frame / prediction module of the encoder and / or the inter-frame / intra-frame / prediction module of the decoder to provide the information required by the inter-frame / intra-frame / prediction module.

[0156] IV. Example Video Encoder Figure 19An example of cross-component prediction, a video encoder 1900, is illustrated. As shown, the video encoder 1900 receives an input video signal from a video source 1905 and encodes the signal into a bitstream 1995. The video encoder 1900 has multiple components or modules for encoding signals from the video source 1905, including at least some components selected from the following modules: Transform module 1910, Quantization module 1911, Inverse Quantization module 1914, Inverse Transform module 1915, Intra-Picture Estimation module 1920, Intra Prediction module 1925, Motion Compensation module 1930, Motion Estimation module 1935, In-loop Filter 1945, Reconstructed Picture Buffer 1950, MV Buffer 1965, MV Prediction module 1975, and Entropy Encoder 1990. Motion Compensation module 1930 and Motion Estimation module 1935 are part of Inter-Frame Prediction module 1940.

[0157] In some embodiments, modules 1910-1990 are modules of software instructions executed by one or more processing units (e.g., processors) of a computing device or electronic device. In some embodiments, modules 1910-1990 are modules of hardware circuitry implemented by one or more integrated circuits (ICs) of an electronic device. Although modules 1910-1990 are depicted as separate modules, some modules may be combined into a single module.

[0158] Movie source 1905 provides a raw movie signal that presents the pixel data of each movie frame without compression. Subtractor 1908 calculates the difference between the raw movie pixel data from movie source 1905 and the predicted pixel data 1913 from motion compensation module 1930 or intra-frame prediction module 1925 as a prediction residual 1909. Transform module 1910 converts the difference (or residual pixel data or residual signal 1908) into transform coefficients (e.g., by performing a discrete cosine transform, or DCT). Quantization module 1911 quantizes the transform coefficients into quantized data (or quantization coefficients) 1912, which is encoded into a bitstream 1995 by entropy encoder 1990.

[0159] Inverse quantization module 1914 inverse-quantizes quantized data (or quantization coefficients) 1912 to obtain transform coefficients, and inverse transform module 1915 performs inverse transform on the transform coefficients to generate reconstruction residual 1919. Reconstruction residual 1919 is added to predicted pixel data 1913 to generate reconstructed pixel data 1917. In some embodiments, reconstructed pixel data 1917 is temporarily stored in an online buffer (not shown) for intra-frame prediction and spatial MV prediction. The reconstructed pixels are filtered by loop filter 1945 and stored in reconstructed image buffer 1950. In some embodiments, reconstructed image buffer 1950 is external storage to the video encoder 1900. In some embodiments, reconstructed image buffer 1950 is internal storage to the video encoder 1900.

[0160] Intra-frame estimation module 1920 performs intra-frame prediction based on reconstructed pixel data 1917 to generate intra-frame prediction data. The intra-frame prediction data is provided to entropy encoder 1990 to be encoded into bitstream 1995. The intra-frame prediction data is also used by intra-frame prediction module 1925 to generate predicted pixel data 1913.

[0161] The motion estimation module 1935 performs inter-frame prediction by generating MVs (Motion Values) that reference pixel data from previously decoded frames stored in the reconstructed image buffer 1950. These MVs are then provided to the motion compensation module 1930 to generate predicted pixel data.

[0162] The video encoder 1900 uses MV prediction to generate predicted MVs instead of encoding the complete actual MVs in the bitstream, and the difference between the MV used for motion compensation and the predicted MVs is encoded as residual motion data and stored in the bitstream 1995.

[0163] The MV prediction module 1975 generates a predicted MV (Motion Compensation MV) based on the reference MV generated for encoding previous movie frames; this predicted MV is used for motion compensation. The MV prediction module 1975 retrieves the reference MV from the previous movie frames in the MV buffer 1965. The movie encoder 1900 stores the MV generated for the current movie frame in the MV buffer 1965 as the reference MV for generating the predicted MV.

[0164] The MV prediction module 1975 uses a reference MV to create a predicted MV. The predicted MV can be calculated through spatial MV prediction or temporal MV prediction. The difference (residual motion data) between the predicted MV and the motion compensation MV (MC MV) of the current frame is encoded into a bitstream 1995 by the entropy encoder 1990.

[0165] The entropy encoder 1990 uses entropy encoding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman coding to encode various parameters and data into a bitstream 1995. The entropy encoder 1990 encodes various header elements, flags, quantization transform coefficients 1912, and residual motion data as syntax elements into the bitstream 1995. The bitstream 1995 is then stored in a storage device or transmitted to the decoder via a communication medium such as a network.

[0166] The loop filter 1945 performs filtering or smoothing operations on the reconstructed pixel data 1917 to reduce encoding / decoding artifacts, particularly at pixel block boundaries. In some embodiments, the filtering or smoothing operations performed by the loop filter 1945 include deblocking filtering (DBF), sample adaptive offset (SAO), and / or adaptive loop filtering (ALF).

[0167] Figure 20 This describes a portion of the movie encoder 1900 that implements cross-component prediction information propagation. The luma component of the current block may be encoded by the intra-frame prediction module 1925 and a reconstructed luma 2015 is generated for the luma component. The cross-component model 2010 is applied to the reconstructed luma 2015 to generate the cross-component predictor 2025 for the chroma component. The cross-component predictor 2025 is contained in the predicted pixel data 1913.

[0168] A cross-component model 2010 may be generated by a model constructor 2005 based on reference samples and / or current samples retrieved from the reconstructed image buffer 1950 (within and / or around the current block and / or reference block). Section I above describes several types of cross-component models that may be used as cross-component models 2010.

[0169] The cross-component model 2010 may also be provided by the CCP Merge module 2030, which provides cross-component model (CCM) information or other cross-component prediction (CCP) information inherited from multiple candidates as a CCP merging pattern. The CCP merging pattern is described in more detail in Section III above. CCM Storage 2035 represents (or is provided by) any form of storage for storing CCM information, including the cross-component model generated by the model builder 2305. CCM Storage 2335 may be part of a block-level buffer, part of a picture-level buffer, or a CCM table (or index table) for different pictures, different time IDs, or different regions of different pictures. CCM tables may be associated with movie pictures and store CCM information or other CCP information for the associated pictures. CCM tables may also be associated with time IDs and store CCM information or other CCP information for pictures with the associated time IDs. CCM tables may be associated with regions in movie pictures and store CCM information or other CCP information for the associated regions. The stored CCM and / or CCP information can be inherited by subsequent blocks as merge mode candidates.

[0170] Each CCP table has a corresponding index buffer, used to map locations in the image to their corresponding locations in the CCP table. To retrieve the CCP information and / or CCP information for selected CCP merge pattern candidates, the encoder identifies the candidate's CCP table and its corresponding index buffer (based on the image, time ID, or region within the image), and then uses the candidate's location in the image to find its index in the identified index buffer. This index is then used to access the selected CCP information and / or CCP information within the CCP table.

[0171] The CCM Propogation module 2040 operates to propagate CCM information between blocks and / or images. For a location or current block without CCM and / or CCP information, the CCM Propogation module 2040 may follow the BV or MV of the current block to locate the CCM / CCP information of a reference block. The CCM Propogation module 2040 then propagates the CCM / CCP information by copying the CCM information of the reference block to the current block. The CCM / CCP information of the reference block may need to be accessed through the index buffer and CCM tables stored in the CCM storage 2035. The CCM Propogation module 2040 then propagates the CCM / CCP information by copying the index value of one location in the index buffer to another location in the same index buffer, or by copying the CCM / CCP information from one CCM table to another.

[0172] Figure 21 The process 2100 of propagating cross-component predictive information when encoding video images is conceptually illustrated. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing encoder 1900 execute process 2100 by executing instructions stored in a computer-readable medium. In some embodiments, an electronic device implementing encoder 1900 executes process 2100.

[0173] The encoder receives (in block 2110) data to encode the pixels of the current block of the current picture into a movie. The current block has a first color block (e.g., the Y component) and a second color block (Cr or Cb component). The encoder generates (in block 2120) a reconstruction of the first color block.

[0174] The encoder derives (in block 2130) a cross-component model using motion information from a reference block of the current block, for example, by propagating the cross-component model from a further reference block to another reference block (which is identified by the motion information of the reference block). In some embodiments, when it is determined that a reference block is not encoded in a mode that includes cross-component prediction, a cross-component model for propagation is derived for the reference block. In some embodiments, the propagation model is derived by copying the cross-component model of a further reference block to the reference block. The motion information of the reference block may be a motion vector or a block vector of the reference block. The block vector of the reference block may be the block vector of a co-positional lumen block of the reference block.

[0175] The encoder applies (in block 2140) the propagated cross-component model to the reconstruction of the first color block to generate a cross-component prediction for the second color block. The encoder uses the generated cross-component prediction to encode (in block 2150) the current block.

[0176] In some embodiments, the encoder looks up an index value based on a position in a reference block and uses that index value to locate the propagation cross-component model corresponding to the motion information of that reference block in an index table, wherein the index value is provided by an index buffer that stores a plurality of indices for different positions of the reference image containing the reference block. In some embodiments, the propagation cross-component model is derived by copying the index value in the index buffer from a further reference block of the reference block to the index buffer of the reference block, wherein the further reference block is identified by a block vector of the reference block.

[0177] In some embodiments, the propagation cross-component model is derived by copying the cross-component model from an index table associated with a further reference image, wherein the further reference image contains a further reference block identified by a motion vector of the reference block. The encoder may store an index value for locating the propagation cross-component model in the index table into the index buffer of the reference block based on its position in the reference block.

[0178] In some embodiments, when the reference block has two or more motion vectors or block vectors for identifying two or more further reference blocks, two or more cross-component models may be identified from the two or more further reference blocks. In some embodiments, the propagation cross-component model may be a combination of the two or more different cross-component models. In some embodiments, the propagation cross-component model is the cross-component model whose corresponding further reference block is intra-frame encoded / decoded.

[0179] V. Example Video Decoder In some embodiments, the encoder may signal (or generate) one or more syntax elements in a bitstream, such that the decoder can parse the one or more syntax elements from the bitstream.

[0180] Figure 22An example video decoder 2200 that may implement cross-component prediction is illustrated. As shown, the video decoder 2200 is an image decoding or video decoding circuit that receives a bitstream 2295 and decodes the contents of the bitstream into pixel data of video frames for display. The video decoder 2200 has multiple components or modules for decoding the bitstream 2295, including some components selected from the following: Inverse Quantization module 2211, Inverse Transform module 2210, Intra Prediction module 2225, Motion Compensation module 2230, In-loop Filter 2245, Decoded Picture Buffer 2250, MV Buffer 2265, MV Prediction module 2275, and Parser 2290. The motion compensation module 2230 is part of the inter-frame prediction module 2240.

[0181] In some embodiments, modules 2210-2290 are modules of software instructions executed by a computing device of one or more processing units (e.g., processors). In some embodiments, modules 2210-2290 are modules of hardware circuitry implemented by electronic devices of one or more integrated circuits. Although modules 2210-2290 are depicted as separate modules, some modules may be combined into a single module.

[0182] Parser 2290 (or entropy decoder) receives bitstream 2295 and performs initial parsing according to the syntax defined by the video-encoding or image-encoding standard. The parsed syntax elements include various header elements, flags, and quantization data (or quantization coefficients) 2212. Parser 2290 uses entropy encoding techniques such as context-adaptive binary arithmetic encoding (CABAC) or Huffman coding to parse the various syntax elements.

[0183] Inverse quantization module 2211 performs inverse quantization on quantized data (or quantization coefficients) 2212 to obtain transform coefficients. Inverse transform module 2210 performs inverse transform on transform coefficients 2216 to generate reconstructed residual signal 2219. Reconstructed residual signal 2219 is added to predicted pixel data 2213 from intra-frame prediction module 2225 or motion compensation module 2230 to generate reconstructed pixel data 2217. The reconstructed pixel data is filtered by loop filter 2245 and stored in deconstructed image buffer 2250. In some embodiments, deconstructed image buffer 2250 is external to video decoder 2200 storage. In some embodiments, deconstructed image buffer 2250 is internal to video decoder 2200 storage.

[0184] Intra-prediction module 2225 receives intra-prediction data from bitstream 2295 and, based on this, generates predicted pixel data 2213 from decoded pixel data 2217 stored in decoded image buffer 2250. In some embodiments, decoded pixel data 2217 is also stored in a line buffer (not shown) for intra-image prediction and spatial MV prediction.

[0185] In some embodiments, the contents of the decoded image buffer 2250 are used for display. The display device 2205 either retrieves the contents directly from the decoded image buffer 2250 for display or retrieves the contents of the decoded image buffer into a display buffer. In some embodiments, the display device receives pixel values ​​from the decoded image buffer 2250 via pixel transfer.

[0186] The motion compensation module 2230 generates predicted pixel data 2213 from the decoded pixel data 2217 stored in the decoded image buffer 2250 based on the motion compensation MV (MC MV). These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 2295 to the predicted MV received from the MV prediction module 2275.

[0187] The MV prediction module 2275 generates a predicted MV based on a reference MV used for decoding a previous video frame, such as a motion-compensated MV used for motion compensation. The MV prediction module 2275 retrieves the reference MV of the previous video frame from the MV buffer 2265. The video decoder 2200 stores the motion-compensated MV used for decoding the current video frame in the MV buffer 2265 as a reference MV for generating the predicted MV.

[0188] The loop filter 2245 performs filtering or smoothing operations on the decoded pixel data 2217 to reduce encoding / decoding artifacts, particularly at the boundaries of pixel blocks. In some embodiments, the filtering or smoothing operations performed by the loop filter 2245 include a deblocking filter (DBF), a sample adaptive offset (SAO), and / or an adaptive loop filter (ALF).

[0189] Figure 23 This demonstrates the portion of the video decoder 2200 that implements cross-component prediction information propagation. The luma component of the current block may be encoded by the intra-frame prediction module 2225, generating a reconstructed luma 2315 for the luma component. A cross-component model 2310 is applied to the reconstructed luma 2315 to generate a cross-component predictor 2325 for the chroma component. The cross-component predictor 2325 is contained in the predicted pixel data 2213.

[0190] The cross-component model 2310 may be generated by the model constructor 2305 based on reference samples and / or current samples (within and / or around the current block and / or within and / or around the reference block) retrieved from the decoded image buffer 2250. Section I above describes several types of cross-component models that can be used as the cross-component model 2310.

[0191] The cross-component model 2310 may also be provided by the CCP Merge module 2330, which provides cross-component model (CCM) information or other cross-component prediction (CCP) information inherited from multiple candidates as a CCP merging pattern. CCP merging patterns are described in more detail in Section III above. The CCM store 2335 represents (or is provided by) any form of storage for storing CCM information, including the cross-component model generated by the model builder 2305. The CCM store 2335 may be part of a block-level buffer, part of a picture-level buffer, or a CCM table (or index table) for different pictures, different time IDs, or different regions of different pictures. A CCM table may be associated with a movie picture and store CCM information or other CCP information for that picture. A CCM table may also be associated with a time ID and store CCM information or other CCP information for a picture with that time ID. A CCM table may be associated with a region in a movie picture and store CCM information or other CCP information for that region. The stored CCM and / or CCP information is available for subsequent blocks to inherit as merge pattern candidates.

[0192] Each CCP table has a corresponding index buffer, used to map locations in the image to their corresponding locations in the CCP table. To retrieve the CCP information and / or CCP information of a selected CCP merge pattern candidate, the decoder identifies the candidate's CCP table and its corresponding index buffer (based on the image, time ID, or region within the image), and then uses the candidate's location in the image to look up the index in the identified index buffer. This index is then used to access the selected CCP information and / or CCP information within the CCP table.

[0193] The CCM Propogation module 2340 operates to propagate CCM information between blocks and / or images. For a location or the current block without CCM and / or CCP information, the CCM Propogation module 2340 may follow the BV or MV of the current block to locate the CCM / CCP information of a reference block. The CCM Propogation module 2340 may then propagate the CCM / CCP information by copying the CCM information from the reference block to the current block. The CCM / CCP information of the reference block may need to be accessed through the index buffer and CCM table stored in the CCM storage 2335. The CCM Propogation module 2340 may then propagate the CCM / CCP information by copying the index value from one location to another location in the same index buffer, or by copying the CCM / CCP information from one CCM table to another CCM table.

[0194] Figure 24 A conceptual illustration of process 2400 for propagating cross-component predictive information when decoding video images is provided. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing decoder 2200 execute process 2400 by executing instructions stored in a readable computing medium. In some embodiments, an electronic device implementing decoder 2200 executes process 2400.

[0195] The decoder receives (in block 2410) data to decode into pixels of the current block of the current picture of the video. The current block has a first color block (e.g., the Y component) and a second color block (Cr or Cb component).

[0196] The decoder generates a reconstruction of the first color block (in block 2420); The decoder derives (in block 2430) a cross-component model using motion information from a reference block of the current block, for example, by propagating the cross-component model from a further reference block to the reference block (the further reference block is identified by the motion information of the reference block).

[0197] In some embodiments, when it is determined that a reference block is not encoded in a mode that includes cross-component prediction, a propagation cross-component model is derived for the reference block. In some embodiments, the propagation model is derived by copying the cross-component model of a further reference block to the reference block. The motion information of the reference block may be a motion vector or a block vector of the reference block. The block vector of the reference block may be the block vector of a co-positional lumen block of the reference block.

[0198] The decoder applies (in block 2440) the propagated cross-component model to the reconstruction of the first color block to generate a cross-component prediction for the second color block. The decoder reconstructs (in block 2450) the current block using the generated cross-component prediction. The decoder may then provide the reconstructed current block to be displayed as part of the reconstructed current image.

[0199] In some embodiments, the decoder looks up an index value based on a position in a reference block and uses that index value to locate a propagation cross-component model of motion information corresponding to the reference block in an index table. This index value is provided by an index buffer that stores indices for different positions in the reference image. In some embodiments, the propagation cross-component model is derived by copying the index value from a further reference block of the reference block to the index buffer of the reference block, where the further reference blocks are identified by the block vector of the reference block.

[0200] In some embodiments, the propagated cross-component model is derived by copying the cross-component model from an index table associated with a further reference image, wherein the further reference image contains a further reference block identified by a motion vector of the reference block. The decoder may store an index value for locating the propagated cross-component model in the index table into the index buffer of the reference block based on its position in the reference block.

[0201] In some embodiments, when the reference block has two or more motion vectors or block vectors for identifying two or more further reference blocks, two or more cross-component models may be identified from the two or more further reference blocks. In some embodiments, the propagated cross-component model may be a combination of the two or more different cross-component models. In some embodiments, the propagated cross-component model is the cross-component model whose corresponding further reference block is intra-coded.

[0202] VI. Exemplary Electronic Systems Many of the features and applications described above are software flows implemented as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium). When these instructions are executed by one or more computing or processing units (e.g., one or more processors, processor cores, or other processing units), they cause the processing unit to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard disk drives, erasable programmable read-write memory (EPROM), electrically erasable programmable read-write memory (EEPROM), etc. Computer-readable media do not include electronic signals transmitted via carrier waves or wireless or wired connections.

[0203] In this specification, the term "software" is intended to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processor processing. Furthermore, in some embodiments, multiple software inventions may be implemented as sub-parts of a larger program while remaining independent software inventions. In some embodiments, multiple software inventions may also be implemented as separate programs. Finally, any combination of separate programs that together implement the software inventions described herein is within the scope of this disclosure. In some embodiments, when a software program is installed and run on one or more electronic systems, one or more specific machine implementations are defined that execute and perform the operations of the software program.

[0204] Figure 25 An electronic system 2500 implementing certain embodiments of the present disclosure is conceptually illustrated. The electronic system 2500 may be a computer (e.g., a desktop computer, personal computer, tablet computer, etc.), a mobile phone, a PDA, or any other type of electronic device. Such an electronic system includes interfaces to various types of computer-readable media and various other types of computer-readable media. The electronic system 2500 includes a bus 2505, a processing unit(s) 2510, a graphics processing unit (GPU) 2515, system memory 2520, a network 2525, read-only memory (ROM) 2530, permanent storage 2535, input devices 2540, and output devices 2545.

[0205] The bus 2505 set represents all system, peripheral, and chipset buses that communicate with multiple devices within the electronic system 2500. For example, bus 2505 communicates with the processing unit 2510 and the GPU 2515, read-only memory 2530, system memory 2520, and permanent storage device 2535.

[0206] From these various memory units, processing unit 2510 retrieves instructions for execution and data for processing to perform the processes of this disclosure. The processing unit may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to and executed by GPU 2515. GPU 2515 may offload various computational or supplemental image processing provided by processing unit 2510.

[0207] Read-only memory (ROM) 2530 stores static data and instructions, which are used by processing unit 2510 and other modules of the electronic system. On the other hand, permanent storage device 2535 is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 2500 is turned off. Some embodiments of this disclosure use mass storage devices (such as disks or optical discs and their corresponding disk drives) as permanent storage device 2535.

[0208] Other embodiments use removable storage devices (such as floppy disks, flash memory devices, etc., and their corresponding disk drives) as permanent storage devices. Like permanent storage device 2535, system memory 2520 is a read-write memory device. However, unlike storage device 2535, system memory 2520 is a volatile read-write memory, such as random access memory. System memory 2520 stores some instructions and data used by the processor during runtime. In some embodiments, processes according to this disclosure are stored in system memory 2520, permanent storage device 2535, and / or read-only memory 2530. For example, various memory units include instructions for processing multimedia clips according to some embodiments. From these various memory units, processing unit 2510 retrieves instructions for execution and data for processing to perform the processes of some embodiments.

[0209] Bus 2505 is also connected to input and output devices 2540 and 2545. Input device 2540 allows the user to communicate information and select commands to the electronic system. Input device 2540 includes an alphanumeric keypad and pointing device (also known as a "cursor control device"), a camera (e.g., a webcam), a microphone, or similar device for receiving voice commands, etc. Output device 2545 displays images generated by the electronic system or otherwise outputs data. Output device 2545 includes printers and display devices such as cathode ray tube (CRT) or liquid crystal display (LCD), and speakers or similar audio output devices. Some embodiments include devices such as touchscreens, which act as both input and output devices.

[0210] Finally, as Figure 25As shown, bus 2505 also connects electronic system 2500 to network 2525 via network adapter (not shown). In this way, the calculator can become part of a computer network (such as a local area network ("LAN"), wide area network ("WAN"), or intranet), or a network of networks such as the Internet. Any or all components of electronic system 2500 can be used with this disclosure.

[0211] Some embodiments include electronic components, such as microprocessors, storage, and memory, that store calculator program instructions in a machine-readable or calculator-readable medium (also referred to as a calculator-readable storage medium, machine-readable medium, or machine-readable storage medium). Examples of such calculator-readable media include RAM, ROM, read-only optical disc (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), read-only digital versatile optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini-SD card, micro-SD card, etc.), magnetic and / or solid-state drives, read-only and recordable Blu-ray® optical discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. A calculator-readable medium may store a calculator program that can be executed by at least one processing unit and includes a set of instructions for performing various operations. Examples of calculator programs or calculator code include machine code, such as code generated by a compiler, and archives containing high-level code executed by a calculator, electronic component, or microprocessor using an interpreter.

[0212] While the foregoing discussion primarily refers to microprocessors or multi-core processors that execute software, many of the features and applications described above are executed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, these integrated circuits execute instructions stored on the circuit itself. Furthermore, some embodiments execute software stored in programmable logic devices (PLDs), ROM, or RAM devices.

[0213] In this specification and any claim of this application, the terms "calculator," "server," "processor," and "memory" refer to electronic or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the term "display" or "show" means "displayed on an electronic device." In this specification and any claim of this application, the terms "calculator-readable medium," "machine-readable medium," and "computer-readable medium" are entirely limited to tangible, physical objects that store information in a form readable by a calculator. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0214] While this disclosure has been described with reference to many specific details, those skilled in the art will recognize that this disclosure may be embodied in other specific forms without departing from its spirit. Furthermore, many figures (including...) Figure 21 and Figure 24 This disclosure conceptually illustrates the process. The specific operations of these processes may not be performed in the exact order shown and described. Specific operations may not be performed in a continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process may be implemented using several sub-processes or as part of a larger macro-process. Therefore, those skilled in the art will understand that this disclosure is not limited to the foregoing illustrative details, but should be defined by the appended claims.

[0215] Additional notes The topics described herein sometimes show different components contained within or connected to other components. It should be understood that the architectures depicted are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same function is actually "related" in order to achieve the desired functionality. Therefore, any two components combined here to achieve a particular function can be considered "related" to each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such related components can also be considered "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so related can also be considered "operably coupled" to each other to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components, wirelessly interactive and / or wirelessly interactive components, and logically interactive and / or logically interactive components.

[0216] Furthermore, regarding any substantially plural and / or singular terms used herein, those skilled in the art can translate them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, these various singular / plural arrangements may be explicitly set forth herein.

[0217] Furthermore, those skilled in the art will understand that, in general, the terms used herein, particularly in the appended claims, such as the body of the appended claims, are generally considered "open" terms; for example, the word "comprising" should be interpreted as "including but not limited to," the word "possessing" should be interpreted as "at least possessing," and the word "including" should be interpreted as "including but not limited to," etc. Those skilled in the art will further understand that if a particular number of introduced claim statements are intentional, such intention will be expressly stated in the claims, and without such a statement, such intention does not exist. For example, as an aid to understanding, the following appended claims may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim statements. However, the use of such phrases should not be construed as implying that the claim statement introduced by the indefinite article "a" or "one" limits any particular claim containing such an introduced claim statement to containing only one such statement, even if the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "one," for example, "a" and / or "one" should be interpreted as "at least one" or "one or more"; the same rule applies to the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of introduced claim statements are explicitly stated, those skilled in the art will recognize that such statements should be interpreted as including at least the stated number; for example, simply stating "two statements" without other modifiers means at least two statements, or two or more statements. Moreover, in the use of conventions such as "at least one A, B, and C, etc.", such constructions are generally intended according to the conventions understood by those skilled in the art; for example, "a system having at least one A, B, and C" will include, but is not limited to, systems with only A, only B, only C, A and B together, A and C together, B and C together, and / or systems with A, B, and C together, etc. When using conventions such as "at least one A, B, or C," such a construction is generally intended according to the conventions understood by a person skilled in the art. For example, "a system having at least one A, B, or C" will include, but is not limited to, systems with only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together. Those skilled in the art will further understand that virtually any separate word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to include the possibility of including one term, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B."

[0218] As can be seen from the foregoing, various embodiments of this disclosure have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of this disclosure. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.

Claims

1. A video encoding / decoding method, comprising: Receive data as pixels of a current block of a video, encoded or decoded into a current image, wherein the current block comprises a first color block and a second color block; Generate a reconstruction for the first color block; A propagated cross-component model is applied to the reconstruction of the first color patch to generate a cross-component prediction for the second color patch, wherein the propagated cross-component model is derived from motion information of a reference patch using the current patch; and Use the generated cross-component prediction to encode or decode the current block.

2. The video encoding / decoding method of claim 1, wherein the cross-component propagation model is derived for the reference block when it is determined that the reference block is not encoded / decoded in a mode that includes cross-component prediction.

3. The video encoding / decoding method as described in claim 1, wherein the cross-component propagation model is derived from a further reference block identified using the motion information of the reference block.

4. The video encoding / decoding method as described in claim 3, wherein the propagation model is derived by copying the cross-component model of the further reference block to the reference block.

5. The video encoding / decoding method as described in claim 1, wherein the motion information of the reference block is a motion vector or block vector of the reference block.

6. The video encoding / decoding method as described in claim 5, wherein the block vector of the reference block is the block vector of a co-position luminance block of the reference block.

7. The video encoding / decoding method of claim 1, further comprising finding an index value based on the position in the reference block, and using the index value to locate the propagation cross-component model corresponding to the motion information of the reference block in an index table, wherein the index value is provided by an index buffer that stores a plurality of indices for different positions of the reference image containing the reference block.

8. The video encoding / decoding method of claim 7, wherein the propagation cross-component model is derived by copying the index value in the index buffer from a further reference block of the reference block to the index buffer of the reference block, wherein the further reference block is identified by a block vector of the reference block.

9. The video encoding / decoding method of claim 7, wherein the propagation cross-component model is derived by copying the cross-component model in an index table associated with a further reference image to the index table associated with the reference image, wherein the further reference image contains a further reference block identified by a motion vector of the reference block.

10. The video encoding / decoding method of claim 9, further comprising storing an index value for locating the propagation cross-component model in the index table into the index buffer of the reference block according to the position in the reference block.

11. The video encoding / decoding method as described in claim 1, wherein the reference block has two or more motion vectors or block vectors for identifying two or more further reference blocks.

12. The video encoding / decoding method of claim 11, wherein two or more cross-component models are identified from the two or more further reference blocks, and the propagation cross-component model is the cross-component model whose corresponding further reference block is intra-frame encoded / decoded.

13. The video encoding / decoding method of claim 11, wherein two or more cross-component models are identified from the two or more further reference blocks, and the propagation cross-component model is a combination of the two or more different cross-component models.

14. An electronic device comprising: A video encoder / decoder circuit, configured to perform operations including: Receive data as pixels of a current block of a video, encoded or decoded into a current image, wherein the current block comprises a first color block and a second color block; Generate a reconstruction for the first color block; A propagated cross-component model is applied to the reconstruction of the first color patch to generate a cross-component prediction for the second color patch, wherein the propagated cross-component model is derived from motion information of a reference patch using the current patch; and Use the generated cross-component prediction to encode or decode the current block.

15. A video decoding method, comprising: Receive data to decode the pixels of the current block of a video into a current image, wherein the current block contains a first color block and a second color block; Generate a reconstruction for the first color block; A propagating cross-component model is applied to the reconstructed first color patch to generate a cross-component prediction of the second color patch, wherein the propagating cross-component model is derived using motion information from a reference patch of the current patch; and Use the generated cross-component prediction to reconstruct the current block.

Images