Storing cross-component models for non-intra coded blocks

Abstract

The invention provides a video coding and decoding method. The video coding and decoding method comprises the following steps: receiving data to encode or decode pixels of a current block of a current picture; the current block includes a first color block and a second color block. Non-intra prediction is performed to generate a reconstruction of the first color block based on motion information of the current block. A cross-component model is retrieved from an index table having table entries storing one or more cross-component models corresponding to different index values. Locations in a picture may be used to look up index values in an index buffer having buffer entries storing index values corresponding to different locations of the picture. The cross-component model is applied to reconstruction of the first color block to generate a prediction of the second color block. The prediction of the second color block is used to encode or decode the current block.

Description

Technical Field

[0001] This disclosure relates to video encoding and decoding. More specifically, it relates to a method for encoding and decoding pixel blocks via cross-component prediction, particularly non-intra-coded blocks. Background Technology

[0002] Unless otherwise stated herein, the methods described in this section are not prior art to the following claims and are not acknowledged as prior art by virtue of being included in this section.

[0003] High-Efficiency Video Coding (HEVC) is an international video coding and decoding standard developed by the Joint Collaborative Team on Video Coding (JCT-VC). HEVC is based on a hybrid block-based motion-compensated DCT transform encoding / decoding architecture. The basic unit of compression is called a Coding Unit (CU), which 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).

[0004] 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 a reconstructed signal derived from a region of the encoded picture. The predicted residual signal is processed through block conversion. The conversion 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 conversion of the dequantized conversion coefficients. The reconstructed signal is further processed by loop filtering to remove coding artifacts. The decoded picture is stored in a frame buffer and used to predict future pictures in the input video signal.

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

[0006] CTUs can use quadtrees (QTs) with nested multi-type-tree (MTT) structures and be divided into one or more non-overlapping codec units (CUs) to accommodate various local motion and texture features. CUs can be further divided into smaller CUs using one of five segmentation types: quadtree segmentation, vertical binary tree segmentation, horizontal binary tree segmentation, vertical mid-side ternary tree segmentation, and horizontal mid-side ternary tree segmentation. Each CU contains one or more prediction units (PUs). The prediction unit, along with the associated CU syntax, serves as the basic unit for sending predictor information. A specified prediction process is used to predict the values ​​of relevant pixel samples within the PU. Each CU may contain one or more transformation units (TUs) to represent prediction residual blocks. A transformation unit (TU) consists of a transformation block (TB) for the luminance sample and two corresponding transformation blocks for the chrominance samples; each TB corresponds to a residual block from one color component. Integer transformations are applied to the transformation blocks. The quantization coefficient rank values, 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 2-D sample arrays of the monochromatic components associated with CTU, CU, PU, ​​and TU, respectively. Therefore, a CTU includes one luma CTB, two chroma CTBs, and associated syntax elements. Similar relationships apply to CU, PU, ​​and TU.

[0007] For each inter-frame predicted CU, motion parameters include motion vectors, reference image indices, reference image list usage indices, and additional information for inter-frame predicted sample generation. Motion parameters can be sent explicitly or implicitly. When a CU is encoded in skip mode, the CU is associated with a PU and has no significant residual coefficients, no encoded motion vector increments, and no reference image indices. 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 the 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 the motion vectors, the corresponding reference image indices for each reference image list, the reference image list usage indices, and other necessary information are explicitly transmitted by signal for each CU.

[0008] In Advanced Motion Vector Prediction (AMVP) mode, motion vector predictor (MVP) candidates are determined based on template matching (TM) errors. The candidate that minimizes the difference between the current block template and the reference block template is selected, and then TM is performed only on this specific MVP candidate for MV refinement. The TM process may iteratively search and refine this MVP candidate according to an Adaptive Motion Vector Resolution (AMVR) mode search pattern. To improve encoding / decoding performance and / or reduce the complexity of systems using cross-component prediction, a method and apparatus for predicting encoded / decoded pixel blocks via cross-component prediction are disclosed. Summary of the Invention

[0009] The following summary is for illustrative purposes only and is not intended to limit in any way. That is, the following summary 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. Therefore, the following summary 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.

[0010] Some embodiments of the present invention provide a method for encoding and decoding non-intra-coded blocks using cross-component prediction. A video codec receives data to encode or decode pixels of a current block in a current image. The current block includes a first color block and a second color block. The video codec performs non-intra-frame prediction to generate a reconstruction of the first color block based on motion information of the current block. The video codec retrieves a cross-component model from an index table having entries storing one or more cross-component models corresponding to different index values, wherein a position in the image is used to look up an index value in an index buffer having buffer entries storing index values ​​corresponding to different positions in the image, and uses the index value to retrieve the cross-component model. The video codec applies the cross-component model to the reconstruction of the first color block to generate a prediction of the second color block. The video codec uses the prediction of the second color block to encode or decode the current block.

[0011] In some embodiments, the first color block is used for the luminance component, and the second color block is used for the chrominance component. In some embodiments, the first color block is used for a first chrominance component (e.g., Cb), and the second color block is used for a second chrominance component (e.g., Cr).

[0012] The cross-component model may be inherited from a temporal candidate in a list of candidates, including spatial candidates, non-nearby candidates, temporal candidates, and / or historical candidates. In some embodiments, the cross-component model can be located using motion information of a reference block and propagated from a further reference block to the reference block.

[0013] The motion vector may be used to locate the position in a co-located CTU row of a further reference image within a CTU row located by a reference image, or the motion vector may be cropped to locate the position in the co-located CTU row.

[0014] In some embodiments, the index table stores the cross-component models of all images in the video. In some embodiments, the index table is an image-level table. In some embodiments, the index table is associated with one of a plurality of regions of an image. In some embodiments, the index table is associated with a temporal identifier layer that includes the current image. In some embodiments, no index table is created for images in the temporal identifier layer with the largest temporal identifier.

[0015] In some embodiments, the index buffer entries store default index values ​​to indicate that no cross component model is available at the corresponding location in the image. When a cross component model is deleted from the index table, each buffer entry of the index buffer having an index value indicating the deleted cross component model is reset to the default index value, and each index value in the index buffer is decremented by one if it is greater than the index value indicating the deleted cross component model. When a cross component model is to be added to the index table for a location in the image, if the cross component model to be added is sufficiently similar to an existing cross component model already stored in the index table, the cross component model to be added is not added to the index table, and the index value indicating the existing cross component model is stored in the buffer entry of the index buffer corresponding to that location.

[0016] In some embodiments, the index table has a maximum size limit. In some embodiments, when the index table reaches its maximum size limit while storing a new cross-component model, the oldest stored cross-component model is removed from the index table to free up space for the new cross-component model. In some embodiments, when the index table reaches its maximum size limit while storing a new cross-component model, the new cross-component model is not stored in the index table. The maximum size limit may be determined based on whether the image is an inter-frame shot or an intra-frame shot, or based on the image's time identifier, or based on the picture order count (POC) distance between the image and the most recently encoded intra-frame shot.

[0017] In some embodiments, when no cross-component model is available at the first position in the first index table, a cross-component model is copied from a second index table associated with a reference image (which may be located by the motion information) to the first index table, or a block vector is used to locate the second position in the image, and the index value of the buffer entry at the second position is copied to the buffer entry at the first position. In some embodiments, the index table is reset when the video codec is encoding or decoding an Instantaneous Decoding Refresh (IDR) or Clear Random Access (CRA) image. Attached Figure Description

[0018] The accompanying drawings are included in this disclosure to provide a further understanding of the disclosure and form part of it. The drawings illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the 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 the disclosure.

[0019] Figure 1 The gradient filters enabled for the Gradient Linear Model (GLM) are marked.

[0020] Figure 2 A 3x2 filter using unsampled luminance samples as input is shown.

[0021] Figure 3 The component sample reconstruction using the cross-component residual model (CCRM) is shown.

[0022] Figure 4 The locations of the spatial merging candidates are marked.

[0023] Figure 5 The patterns of adjacent and non-adjacent spatial merging candidates are shown.

[0024] Figure 6 The motion vector scaling of the time merging candidates is shown.

[0025] Figure 7 The candidate positions of time merging candidates C0 and C1 are shown.

[0026] Figure 8A and Figure 8B This shows a current block and its non-adjacent spatial neighboring blocks.

[0027] Figure 9 The propagation of the Cross-Component Model (CCM) based on block vectors is illustrated.

[0028] Figure 10 The diagram shows a current block with two block vectors that identify two reference blocks, both of which have CCM information.

[0029] Figure 11 An example of CCM information propagation based on motion vectors is shown.

[0030] Figure 12 The diagram shows a current block with two motion vectors that identify two reference blocks, both of which have CCM information.

[0031] Figure 13 The positions located in the reference image by the motion vectors are marked.

[0032] Figure 14 A picture-level index buffer is conceptually shown for the index used to store the CCM information storage table.

[0033] Figure 15 The index table for copying CCM information from the index table of the co-located image to the index table of the current image is marked.

[0034] Figure 16 The process of exporting and storing CCM information by copying entries of the index buffer based on block vectors is conceptually illustrated.

[0035] Figure 17 The process of exporting and storing CCM information by copying and storing entries of an index table based on motion vectors is illustrated.

[0036] Figure 18 Example patterns of n points in a window region MxN are marked.

[0037] Figure 19 Example patterns of m points in the window region M2xN2 are marked.

[0038] Figure 20 The spatial neighboring regions of the current block that may serve as reference areas are marked.

[0039] Figure 21 An example video encoder that may implement cross-component prediction is shown.

[0040] Figure 22 The portion of the video encoder that implements cross-component prediction for non-intra-coded blocks is marked.

[0041] Figure 23 The process of encoding non-intra-coded blocks using cross-component prediction is conceptually illustrated.

[0042] Figure 24 An example video decoder that may implement cross-component prediction is shown.

[0043] Figure 25 The portion of the video decoder that performs cross-component prediction for non-intra-coded blocks is marked.

[0044] Figure 26 The process of decoding non-intra-coded blocks by using cross-component prediction is conceptually illustrated.

[0045] Figure 27 An electronic system for implementing some embodiments of the present invention is conceptually illustrated. Detailed Implementation

[0046] In the following detailed description, the invention is made thorough and complete by disclosing detailed embodiments and implementations of the claimed subject matter. Any variations, derivatives, and / or extensions based on the exemplary embodiments described herein are within the scope of protection of this invention. In some cases, methods, procedures, components, and / or circuits well known in one or more example embodiments and implementations disclosed herein may be described at a relatively high level without detail to avoid unnecessarily obscuring the embodiments and presentations of the invention.

[0047] I. Cross-component model a. Cross-Component Linear Model (CCLM) Prediction To reduce redundancy in cross-components, the Versatile Video Coding (VVC) standard uses the Cross-Component Linear Model (CCLM) prediction mode. In this mode, chroma samples are reconstructed from luminance samples based on the same coding unit (CU) using a linear model, as shown below: Among them, pred C (i, j) represents the predicted chromaticity samples in the CU. Represents downsampled reconstructed brightness samples from the same CU. CCLM parameters ( β) is derived from at most four neighboring chroma samples and their corresponding downsampled luminance samples. Assuming the current chroma block size is W×H, then W' and H' are set to... W'= W, H'= H when the LM_LA mode is applied; W' = W + H when the LM_A mode is applied; H' = H + W when the LM_L mode is applied; In this disclosure, the terms {LM_LA, LM_A, LM_L} and {CCLM_LT, CCLM_T, CCLM_L} are used interchangeably.

[0048] b. Multi-model CCLM Multiple Model CCLM (MMLM) uses two models to predict chroma samples for the entire Cubic Cubic (CU) from luminance samples. In MMLM, neighboring luminance samples and neighboring chroma samples of the current block are classified into two groups, each used as a training set to derive a linear model (i.e., derive a specific model for a specific group). And β). In addition, the samples of the current luminance block are also classified according to the classification rules of the neighboring luminance samples.

[0049] The threshold is calculated as the average of the neighboring reconstructed brightness samples. A neighboring sample is defined as Rec' L If [x,y] ≤ the threshold, it is classified as the first group; while a neighboring sample if Rec' L If the threshold [x,y] is exceeded, it is classified into the second group. Specifically: In this disclosure, the terms {MMLM_LA, MMLM_A} and {MMLM_LT, MMLM_T} are used interchangeably.

[0050] c. Convolutional Cross-Component Model (CCCM) In CCCM, a convolutional model is used for cross-component prediction. The convolutional model has a 7-tap filter, consisting of a 5-tap plus-shaped spatial component, a nonlinear term (P), and a bias term (B). The spatial 5-tap component input to the filter includes a center (C) luminance sample (co-located with the chrominance sample to be predicted) and its top / north (N), bottom / south (S), left / west (W), and right / east (E) adjacent samples. The filter output is calculated as the filter coefficients c. i Convolve the input values ​​and crop them to the range of valid chromaticity samples: predChromaVal = c0C + c1N + c2S + c3E + c4W + c5P + c6B The filter coefficients are calculated by minimizing the mean squared error (MSE) between the predicted and reconstructed chroma samples in the reference region.

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

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

[0053] Figure 1 The gradient linear model (GLM) with gradient filter enabled is shown. Specifically, the figure illustrates 16 Sobel-based gradient patterns 101-116 used for GLM. The gray dot in the middle of each gradient pattern represents the chromaticity position (C).

[0054] e. CCCM using non-downsampled brightness samples In some embodiments, a CCCM mode with a 3x2 filter can be used, which uses unsampled luminance samples. The filter consists of a 6-tap spatial term, four nonlinear terms, and a bias term. Figure 2 A 3x2 filter using unsampled luminance samples as input is shown. The 6-tap spatial term corresponds to 6 neighboring luminance samples (i.e., L0, L1, …, L5) surrounding the chrominance sample to be predicted (i.e., C), and four nonlinear terms are derived from samples L0, L1, L2, and L3: f. Cross-Component Residual Model (CCRM) Cross-component residual model (CCRM) can be used to predict chrominance samples from reconstructed luminance samples, when blocks use inter-frame prediction or intra-block copy (IBC, which refers to encoding pixel blocks by using block vectors to reference pixel positions within the same current image). Figure 3The diagram illustrates the reconstruction of component samples using the Cross Component Residual Model (CCRM). The figure shows the decoder side of the method. The cross component filters are derived using the predicted luminance and chrominance signals (predY, predCb, predCr). The derived filters are applied to the reconstructed luminance signal (resY) to produce the final chrominance prediction.

[0055] II. Current image reference a. Intra-block copy (IBC) of the current image Intra-Picture Block Copying (IBC), or Current Picture Referencing (CPR), refers to encoding pixel blocks by using block vectors to reference pixel locations within the same current picture. The block vectors indicate the displacement from the current block to a reference block that has already been reconstructed within the current picture. The luma block vectors of IBC-encoded CUs are integer-precision. The chroma block vectors are also rounded to integer precision. When combined with AMVR, the IBC mode can switch between 1-pel and 4-pel motion vector precision. IBC-encoded CUs can be considered a third prediction mode besides intra-frame or inter-frame prediction modes. The IBC mode is suitable for CUs with a width and height of 64 luma samples or less.

[0056] b. 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, whose L-shaped template matches the current template. For a predetermined 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 sends a signal using this mode, and the same prediction operation is performed at the decoder.

[0057] III. Consolidation Forecast For each inter-frame predicted CU, motion parameters may include motion vectors, a reference image index, and a reference image list usage index, as well as additional information about the specific codec functions required to generate the inter-frame predicted samples. A merging mode is specified, where the motion parameters of the current CU are obtained from neighboring CUs, including spatial and temporal candidates. The merging mode can be applied to any inter-frame predicted CU, not just the skip mode. In some embodiments, the merging candidate list is constructed by including candidates of the following types: -Space MVP from adjacent CU -Time MVP from the same CU - Historical MVP from FIFO table - Paired average MVP - Candidates such as zero motion vector.

[0058] a. Spatial candidate derivation For the derivation of spatial merge candidates, select up to four merge candidates from the candidates located at the location. Figure 4 The positions of the spatial merge candidates are marked. The order of derivation is B. 0, A 0, B 1, A1 and B2. Position B2 is only considered if the CU of one or more positions B0, A0, B1, A1 is unavailable (e.g., because it belongs to another slice or tile) or if it is intra-frame coded. After a candidate for position A0 is added, the addition of the remaining candidates is subject to a redundancy check to ensure that candidates with the same motion information are excluded from the list, thereby improving encoding and decoding efficiency.

[0059] In addition to the space candidates mentioned above, non-neighboring space merge candidates may be inserted after the TMVP in the regular merge candidate list. Figure 5 The pattern of neighboring and non-neighboring space merging candidates is displayed. The distance between the non-neighboring space candidate and the current code block (CB) is based on the width and height of the current code block.

[0060] b. Time candidate export In some embodiments, only one temporal merge candidate is added to the merge list. Specifically, when deriving this temporal merge candidate, a scaled motion vector is derived based on the co-located CU belonging to the co-located reference image. The list of reference images and reference indices used to derive the co-located CU are explicitly sent in the slice header. Figure 6 The scaling of motion vectors for time merge candidates is illustrated. Specifically, the motion vectors of time merge candidates for the current block (curr_CU) are obtained by scaling the motion vectors of the corresponding CUs (col_CU) in the co-located image (col_pic) using the POC distance, tb, and td. Here, tb is defined as the POC difference between the reference image (curr_ref) and the current image (curr_pic), and td is defined as the POC difference between the reference image (col_ref) and the co-located image (col_pic). The reference image index for the time merge candidates is set to zero.

[0061] The position of the time candidate is selected between candidates C0 and C1, such as Figure 7As shown, it displays the candidate positions for time merge candidates C0 and C1. Position C1 is used if the CU at position C0 is unavailable, is intra-coded, or is outside the current CTU line. Otherwise, position C0 is used when deriving the time merge candidate.

[0062] c. Derivation of historical merge candidates History-based motion vector prediction (HMVP) merging candidates are added to the merging list after spatial and temporal motion vector predictions. In this approach, motion information from previous coded blocks is stored in a table and used as the motion vector prediction for the current codec unit. A table containing multiple HMVP candidates is maintained during encoding / decoding. The table is reset (cleared) when a new code tree unit (CTU) row is encountered. Whenever a non-inter-block encoded codec unit occurs, the associated motion information is added to the last entry of the table as a new HMVP candidate.

[0063] d. Derivation of pairwise average merge candidates Pairwise averaged candidates are generated by averaging predefined candidate pairs in the existing merge candidate list, using the first two merge candidates. The first merge candidate is defined as p0Cand, and the second merge candidate can be defined as p1Cand. Averaged motion vectors are calculated for each reference list based on the availability of motion vectors for p0Cand and p1Cand. If both motion vectors in a list are available, even if they point to different reference images, these two motion vectors are averaged, and the reference image is set to the one for p0Cand; if only one motion vector is available, that motion vector is used directly; if no motion vector is available, the list remains invalid. Furthermore, if the half-pixel interpolation filter indices of p0Cand and p1Cand are different, they are set to 0.

[0064] If the merge list is not full after adding pairwise average merge candidates, zero motion vector predictions may be inserted at the end until the maximum number of merge candidates is encountered.

[0065] IV. Cross-Component Prediction for Non-intra-coded Blocks In some embodiments, cross-component information is used to improve the prediction accuracy of inter-coded blocks (blocks coded via inter-predictive coding) or non-intra-blocks (blocks not coded via intra-predictive coding). Luminance information from the luminance component corresponding to the current chroma block and / or chroma information from the current chroma block and / or chroma information from previously coded chroma components can be used to improve the prediction accuracy of the chroma components of inter-coded blocks or non-intra-blocks.

[0066] In some embodiments, for a codec unit containing luminance (Y) and chrominance (Cb and / or Cr) components (under a single tree segmentation), the prediction of Cb and / or Cr is improved by applying a cross-component model to information from Y (first scheme) (current reconstruction or prediction). In some embodiments, the prediction of Cr is improved by applying a cross-component model to information from Cb (second scheme) (current reconstruction or prediction).

[0067] When the selected model information refers to a traditional cross-component linear model, the proposed method is called the inter-cross-component linear model (inter CCLM) mode. When the selected model information refers to a convolutional cross-component model derived through a regression-based method (such as CCCM), the proposed method is called the inter-cross-component convolutional model (inter CCCM) mode.

[0068] In some embodiments, an inherited cross-component mode can be used for the current chroma block, the steps of which include: (i) creating a candidate list (modelList) for the current block, wherein the candidate list includes multiple cross-component models; (ii) selecting one or more model information from the list; and (iii) using the model information to generate one or more prediction hypotheses for the current chroma component (Cb or Cr) by applying and / or modifying the selected model information to the corresponding luminance component (Y) or the reconstructed or predicted sample of the corresponding chroma component (Cb).

[0069] In some embodiments, self-derived cross-component patterns are added to the aforementioned candidate list (i.e., modelList). (The self-derived pattern is also known as the re-derived mode, in which reconstructed samples or neighboring samples of the selected candidate block are used to derive the cross-component model.) In some embodiments, self-derived cross-component patterns are not added to the list, and the selection to use the proposed inheritance mode and / or the proposed self-derived mode is designed. In some embodiments, the selection to use the inheritance mode and / or the self-derived mode is determined according to an explicit rule, an implicit rule, or both. Further details are described in Section IV.e.

[0070] a. Model storage and inheritance In some embodiments, when the current inter-block or non-intra-block uses model parameters from a self-derived cross-component model, the model parameters used can be saved and / or referenced by one or more subsequent or following codec blocks. For example, if the self-derived cross-component model is CCRM, all or any subset of the model parameters can be saved. In some embodiments, when the current inter-block uses an inherited cross-component mode, the model parameters used can be saved and / or referenced by one or more subsequent or following codec blocks. For example, if the inherited cross-component model is CCCM, all or any subset of the model parameters can be saved.

[0071] In some embodiments, saved model parameters are allowed if the subsequent codec block is intra-frame. In some embodiments, saved model parameters are allowed if the subsequent codec block is encoded via an inter- or current picture reference (e.g., IBC) or any other mode type. In some embodiments, saved model parameters are not allowed if the subsequent codec block and the current block have different mode types (e.g., the subsequent block is an inter-block while the current block is not).

[0072] In some embodiments, when the current inter-frame block uses any cross-component model (e.g., an inherited cross-component model, a self-derived cross-component model, a cross-component model used in chroma fusion, meaning that chroma prediction is based on adding one or more cross-component prediction assumptions to one or more existing assumptions of non-cross-component predictions), or any combination thereof, the model parameters used can be saved and / or referenced by subsequent codec blocks. For example, if the cross-component model is an inherited CCCM model, all or any subset of the model parameters can be saved. In some embodiments, if the subsequent codec block is intra-frame, the saved model parameters are allowed to be used. If the subsequent codec block is inter-frame or another mode type (e.g., IBC), the subsequent codec block is allowed to use the saved model parameters. In some embodiments, if the mode type of the subsequent codec block (e.g., not an inter-frame block) is different from the current block, the subsequent codec block is not allowed to use the saved model parameters.

[0073] b. Establish a candidate list including cross-component models. In some embodiments, when a merge-like candidate model list (modelList) is created, one or more of the following candidate model information are included in the candidate list. Each candidate in the candidate list corresponds to one candidate model information. More details on the definition of model information can be found in Section Va, “Inheriting Cross Component Model (CCM) Information.” Examples of model information include: - Spatial model information from spatially neighboring blocks (corresponding to the "spatial MVP from spatially neighboring CUs" between frames) -Temporal model information from the same block (corresponding to the "temporal MVP from the same CU" between frames) - Historical model information from the FIFO table (corresponding to "historical MVP from the FIFO table" between frames) - Pairwise average model information (corresponding to the "pairwise average MVP" between frames) - Default model information (corresponding to "zero MVs" between frames) In some embodiments, a predefined condition is used to determine whether a particular candidate in the candidate list is a valid or available candidate for providing model information. The predefined condition may differ for different candidate types. For example, when a candidate is used to provide spatial model information (e.g., candidate type = spatial neighbor), the candidate is considered valid if it comes from one of the spatial neighbors and non-neighbors that satisfy the predefined condition (or any subset of blocks in the current block's neighborhood search region). Another example is when the candidate type is non-neighbor, the predefined condition might require that the non-neighbor candidate be in a predefined "available" region for non-neighbor spatial candidates.

[0074] Another example is that predefined conditions might stipulate that a candidate is valid only if it is a neighbor encoded by or in combination with a cross-component mode. A cross-component mode refers to a syntax such as CCLM, MMLM, CCCM, GLM, modes that inherit mode information from a similar merged candidate list, multi-hypothesis CCLM, and / or any cross-component mode that belongs to a cross-component branch (containing multiple cross-component modes) but not to a traditional intra-prediction mode. Combining with a cross-component mode refers to a syntax where the candidate block uses cross-component information in combination with chroma blending (or LM-assisted Angular / Planar mode), inter-frame CCLM, inter-frame CCCM, and / or any traditional mode to generate a prediction, but does not belong to a cross-component branch.

[0075] In some embodiments, when checking the validity of neighboring code-decode blocks, a second round of validity checks is further used if the aforementioned validity checks (e.g., the neighboring block is not in a cross-component mode or the neighboring block does not use / combines cross-component modes) are met. If a model is found, the second round of validity checks for the neighboring block is satisfied, and the found model can be inserted into the list; otherwise, the neighboring block is invalid for insertion. When scanning spatial neighboring blocks, if a candidate is valid, it is added to the list. How to use motion vectors and / or block vectors to find changes in the model can be found in the description related to the temporal model information of co-occurring blocks in this disclosure.

[0076] In some embodiments, when the candidate type is temporal model information from a co-position block, the co-position block may originate from a block in a reference image or a predefined co-position image, and is used as an inter-frame mode by employing the current block position and / or the current block motion.

[0077] For example, when using the current block position and / or current block motion to locate co-op blocks, and when the current block is encoded in inter-frame prediction mode, co-op blocks are referenced by the motion information of the current block (including motion vectors and a reference picture indicated by a reference index). If the current block is in sub-block motion mode (e.g., affine mode), each sub-block in the current block has its own co-op temporal model information. The co-op temporal model information of all or any subset of these sub-blocks, referenced by the different sub-block motions of each sub-block, is added to a list. Another example is that when the reference picture indicated by the reference index is different from a predefined co-op picture, the temporal information from the reference picture is disabled. The co-op picture referred to in this example can be used for temporal motion vector prediction in inter-frame mode or any co-op picture specified in the standard, such that motion or cross-component model information is stored and provided for the current block. Another example is that when the reference picture indicated by the reference index is different from a predefined co-op picture, the motion vectors are scaled to reference the predefined co-op picture, and the scaled motion vectors are used to find the co-op block in the co-op picture to obtain the cross-component model in the co-op block. The co-location image referred to in this example can be used for temporal motion vector prediction in inter-frame mode or any co-location image specified in the standard, so that motion or cross-component model information is stored and provided for the current block. The scaling process is shown in Section Vc, “Inheriting Temporal Proximity Model Parameters” and Section III.b, “Temporal Candidate Derivation”.

[0078] For example, when locating a co-located block using the current block position and / or neighboring block motion, the temporal model information can be derived from the co-located block referenced by the motion information of the neighboring block. Similarly, the prohibition method or scaling method can be used when locating a co-located block using the current block position and / or neighboring block motion. If the proposed method is applied to IBC blocks or any pattern using block vectors (where the current block is IBC when using the current block position and / or current block motion; and neighboring blocks are IBC when using the current block position and / or neighboring block motion), block vector information is used as the motion vector, where the block vector information is determined by signals and / or template matching within a predefined search range, such as intraTMP and / or any implicit or explicit predefined rules. More details can be found in Section Vc, “Inheriting Temporal Proximity Model Parameters”.

[0079] In some embodiments, for candidate types "history-based model information," a history-based table (FIFO table) is built by storing model information from previous encoded blocks. This table can be reset at the beginning and / or end of a CTU, slice, image, tile, and / or sequence. One or more history-based candidates can be added to the candidate list in either head-to-tail or tail-to-head order.

[0080] In some embodiments, when the candidate type is "pairwise averaged model information," the candidate's model information is derived from the model information of more than one previous candidate in the list. For example, a video codec may average and / or modify the model parameters of more than one candidate as the model parameters to be applied. Another example is that a video codec may combine more than one prediction as the final prediction, where each of the more than one prediction is generated by applying a model from the candidate list.

[0081] In some embodiments, if the list is not full after inserting all predefined candidates, default model information is added. For example, the default model could be a CCLM model. The default alpha (or named...) The scaling parameter (a, or scaling parameter) is {0, 1 / 8, -1 / 8, 2 / 8, -2 / 8, 3 / 8, -3 / 8, …}, while beta (or named (b, or offset parameter) is based on the selected default alpha, average neighbor reconstructed luminance sample value, and average neighbor reconstructed chromaticity (Cb / Cr) sample value.

[0082] In some embodiments, the candidate list for inter-frame chroma blocks is unified with the candidate list for intra-frame chroma blocks, and / or may be generated based on the candidate list for intra-frame chroma blocks, further including inter-frame specific candidates (e.g., temporal model information referenced by the current motion), and / or may be any subset of the candidate list for intra-frame chroma blocks.

[0083] In some embodiments, one or more self-derived cross-component candidates are included in the modelList when it is built. Self-derived cross-component candidates are described in Section IV.L. In some embodiments, self-derived cross-component candidates are added only when the candidate list (i.e., modelList) does not contain enough inherited candidates. For example, self-derived candidates are added before adding a default candidate or when a self-derived candidate is considered the default candidate. In some embodiments, self-derived cross-component candidates are added to any predefined position in the modelList. For example, the position is after spatially neighboring candidates. Another example is that the position is after spatially non-neighboring candidates. Another example is that the position is after all or any subset of temporal candidates. After the list is built, in some embodiments, the list is reordered as described in Section Vk, “Reordering the Candidate List”.

[0084] c. Enabling and selecting signaling model information (In this section, "inter-frame CCLM" refers to "inter-frame CCLM or inter-frame CCCM".) In some embodiments, when the inter-frame CCLM (or inter-frame CCCM) method described above is not applied, the prediction of the current block is derived from the original inter-frame prediction. In some embodiments, the choice to apply inter-frame CCLM depends on the signal.

[0085] In some embodiments, the signal refers to an encoded TU / TB / CU / CB level flag. This flag may or may not be context-dependent in its encoding. In some embodiments, the TU / TB flag is transmitted only if the luminance Cbf of the TU / TB is non-zero and the inter-frame mode enable flag is true. For example, the CU / CB flag is transmitted only if the luminance Cbf of the CU / CB is non-zero and the inter-frame mode enable flag is true. The inter-frame mode enable flag means that when the proposed inter-frame CCLM (or inter-frame CCCM) supports all inter-frame modes, the predMode of the CU is MODE_INTER. When the inter-frame CCLM (or inter-frame CCCM) only supports IBC, the IBC enable flag is checked first, and the inter-frame CCLM (or inter-frame CCCM) signal is encoded and decoded based on the CU's predMode being MODE_IBC.

[0086] In some embodiments, when the inter-frame CCLM (or inter-frame CCCM) is supported only by CIIP, the CIIP enable flag is checked first, and the inter-frame CCLM (or inter-frame CCCM) signal is encoded if the CIIP flag is true. When the proposed inter-frame CCLM (or inter-frame CCCM) is supported only by merging, the merging flag is checked first, and the inter-frame CCLM (or inter-frame CCCM) signal is encoded if the merging flag is true. When the proposed inter-frame CCLM (or inter-frame CCCM) is supported only by AMVP, the merging flag is checked first, and the inter-frame CCLM (or inter-frame CCCM) signal is encoded if the merging flag is false. The proposed inter-frame CCLM (or inter-frame CCCM) can only support any predefined subset of merging modes, any predefined subset of inter-frame modes, or any predefined subset of non-intra-frame modes.

[0087] In some embodiments, when a signal indicates the application of inter-frame CCLM (or inter-frame CCCM), an additional signal is used to select one or more models from the total candidates. The candidate index is referred to herein as modelIdx. If the modelList containing the total candidates (e.g., the candidates described in Section IV.b, “Establishing a Candidate List Including Cross-Component Models,” CCLM_LT, CCLM_L, CCLM_T, MMLM_LT, MMLM_L, MMLM_T) or any subset of candidates is reordered as described in Section Vk, the additional signal specifies the candidate index in the reordered list. For example, if one LM mode is selected, LM predictions are generated from the selected LM. As another example, if more than one LM mode is selected, LM predictions are generated from a mixture of prediction hypotheses from multiple LM modes.

[0088] In some embodiments, no additional signaling is required, and one or more models are selected based on implicit rules. For example, in some embodiments, one or more selected models are implicitly determined, or one or more models used in the current block are determined or selected without sending modelIdx. In some embodiments, the first candidate in a list may be selected. If the list is reordered by template cost, the first candidate is the one with the lowest template cost.

[0089] In some embodiments, the original inter-frame prediction (generated by motion compensation) is used for luma, and the prediction of the chroma component is generated by CCLM and / or any other LM mode. In some embodiments, the current CU can be considered (classified as) an inter-frame CU, an intra-frame CU, or a new type of prediction mode (neither intra-frame nor inter-frame).

[0090] In some embodiments, one or more LM modes (i.e., cross-component modes) predicted by one or more assumptions for generating LM-assisted angle / plane mode / inter-frame CCLM / inter-frame CCCM / MHCCLM are selected from a predefined list of merged candidates (i.e., modelList). A modelIdx signal is sent to select a candidate from the candidate list (modelList) and the selected candidate is used for the current block. modelList contains one or more candidates, each candidate representing a model (or cross-component mode) information. If there is only one candidate in the list (the list size is only 1), the modelIdx signal is not sent and can be inferred to be 0 or a default value. For example, in some embodiments, one or more selected models (i.e., modelIdx) are implicitly determined, or one or more models used by the current block are determined or selected without sending modelIdx. In some embodiments, the first candidate in the list may be selected. If the list is reordered by template cost, the first candidate is the one with the lowest template cost. In some embodiments, the candidate / model to be used is implicitly selected from the list based on the block's encoding and decoding information and predefined rules for the candidates to be used. When building the modelList, some embodiments may add one or more predefined candidates. Predefined candidates may include any subset / expansion and / or more of the following candidates: - CCLM family: CCLM_LT, CCLM_L, CCLM_T - MMLM family: MMLM_LT, MMLM_L, MMLM_T - CCCM family: CCCM_LT, CCCM_L, CCCM_T The method described above can also be applied to IBC blocks or blocks of any IBC submode (e.g., IBC merging, IBC AMVP, or any IBC mode under the IBC syntax). The term "inter-frame" in this document can be replaced with IBC. That is, in some embodiments, for chroma components, block vector prediction can be combined with or replaced by cross-component prediction.

[0091] d. Use model information to generate predictive hypotheses for the current chromaticity. In some embodiments, a prediction- or reconstruction-based model is used to generate a predictive hypothesis for the current chromaticity component. In some embodiments using a prediction-based linear model, the derived model parameters are applied to a predicted sample of the first component (Y) to obtain a predicted sample of the second or third component.

[0092] The first component sample of the prediction is downsampled using downsampling filters (these filters may be fixed to a predefined filter or selected from some candidate filters).

[0093] In some embodiments that use a reconstruction-based linear model, the derived model parameters are applied to the reconstructed samples of the first component (Y) to obtain predicted samples of the second or third component (Cb or Cr).

[0094] The reconstructed samples of the first component are downsampled using downsampling filters (these filters may be fixed to a predefined filter or selected from some candidate filters).

[0095] The proposed methods for prediction- or reconstruction-based convolutional models are similar to those for prediction- or reconstruction-based linear models. The main difference is that the model coefficient pattern follows CCCM (rather than CCLM), and the brightness samples may or may not be downsampled first.

[0096] In some embodiments, multiple hypotheses (MHs) of cross-component predictions are blended or multiple models are used to generate the prediction hypothesis for the current block. Multiple Hypothesis (CCLM) is used to blend predictions from multiple CCLM methods. The term "CCLM method" may refer to all cross-component modes. The CCLM method to be blended can be (but is not limited to) one of the CCLM methods mentioned above (e.g., CCLM, MMLM, CCCM, GLM, CCRM, etc.) and / or a model implicitly selected from a candidate list using predefined rules based on the block's encoding and decoding information. A weighting scheme may be used when blending multiple hypotheses.

[0097] In some embodiments, for the chroma component, in addition to the original inter-frame prediction (generated by motion compensation, which may be a single prediction and / or bidirectional prediction, multiple prediction hypotheses of multiple motion candidates, which may refer to one or more merged candidates and / or one or more AMVP candidates, and / or any combination of the above, or may be only a single prediction), one or more prediction hypotheses (generated by CCLM and / or any other LM mode) are used to generate the current prediction.

[0098] In some embodiments, the current prediction is a weighted sum of inter-frame prediction and CCLM (or CCCM, or other LM modes) prediction. In some embodiments, the inter-frame prediction can be generated by any inter-frame mode mentioned in the above description / documentation. For example, the inter-frame mode can be a regular merging mode. Another example is that the inter-frame mode can be a CIIP mode. Yet another example is that the inter-frame mode can be GPM or any GPM variant (e.g., GPM intra-references a prediction cell using intra-frame prediction).

[0099] In some embodiments, inter-frame CCLM (or inter-frame CCCM) is supported only when one or more predefined inter-frame modes are used for the current block, or when one (or more) enable flags for enabling predefined inter-frame modes are indicated as enabled. Video codecs that support inter-frame CCLM (or inter-frame CCCM) may allow selection of the prediction for the current block, whether to apply inter-frame CCLM (or inter-frame CCCM) or not.

[0100] In some embodiments, when inter-frame CCLM (or inter-frame CCCM) is applied, the prediction for the current block is generated by mixing one or more prediction assumptions (generated by CCLM and / or any other LM mode) with the original inter-frame prediction. The video codec may mix the chroma predictions from existing inter-frame modes with the predictions from the LM in the following manner: Predfinal = ( wInter * PredInter + wLM * PredLM + 2 )>>2 The weighted rules are applied to determine wInter and wLM according to the following rules: - If the top and left sides are both intra-frame (or any cross-component mode), then (wInter, wLM) = (1, 3) Otherwise, if either the top or left side is within the frame, then (wInter, wLM) = (2, 2). Otherwise, (wInter, wLM) = (3, 1) Another example is that the weighting follows the CIIP weighting rules. For instance, predInter = inter-frame prediction passes through OBMC (if OBMC is used). Another example is that predInter = inter-frame prediction precedes OBMC (OBMC can be applied after mixing).

[0101] In some embodiments, when inter-frame CCLM (or inter-frame CCCM) is applied, the prediction for the current block is generated by replacing the original inter-frame prediction with one or more prediction assumptions (generated by CCLM and / or any other cross-component mode).

[0102] Another example: if a CCLM (or CCCM, or other LM mode) mode is used to generate chroma prediction samples, while luma prediction comes from inter-frame codec tools, a flag is used to indicate whether the CCLM model used for chroma prediction is inherited from a CCLM model used in a previous coding block, or whether the CCLM model comes from a predefined CCLM mode. If the CCLM model is inherited from a CCLM model used in a previous coding block, an index is used to indicate which model in the list was inherited or modified. Otherwise, the CCLM model for the current chroma prediction is implicitly derived using a predefined CCLM mode.

[0103] e. Choosing between inheritance and self-derived models In some embodiments, a flag may be emitted to indicate / select whether to use a re-derived model. If the flag is 0, the cross-component model used to encode the neighbor merging candidate is inherited. If the flag is 1, the re-derived approach is used. In some embodiments, an implicit rule (instead of using an additional flag) is used to determine whether to use a re-derived model. In some embodiments, a re-derived model may be used if no model is available to inherit during the creation of the modelList, or if spatially adjacent and / or non-adjacent candidates and / or historical candidates and / or temporal candidates and / or all or any subset of mentioned candidates (e.g., before the default candidate) are not available in this invention. In some embodiments, when a model is selected to inherit, the candidate with the lowest cost (e.g., the first candidate in the modelList) is implicitly selected to generate cross-component predictions. In some embodiments, an index is emitted to select one or more candidates from the modelList. More details on emitting information to select candidate models can be found in Section IV.c, “Signaling Enable and Select Model Information.”

[0104] V. Cross component patterns in the candidate list a. Inherit Cross Component Model (CCM) information In some embodiments, inherited cross-component model (CCM) information may be stored along with inherited model parameters. CCM information can be inherited along with inherited model parameters. Prediction for the current block can be generated based on the inherited CCM information and inherited model parameters. CCM information may include, but is not limited to, prediction patterns (e.g., CCLM, MMLM, CCCM, CCCM with multiple models, 2-parameter GLM, 3-parameter GLM (GLM model with a luminance term), 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, downsampling filter flags (whether downsampling is performed), downsampling filter indexes when multiple downsampling filters are used, information indicating whether multiple downsampling filters are used, the number of neighboring lines used for the derived model, template types used for the derived model (e.g., top-left template, top template, left template), post-filter flags, and model parameters.

[0105] In some embodiments, the hybrid CCCM model, composed of various terms (e.g., spatial, gradient, positional, nonlinear, and bias terms), can be inherited. In addition to storing model parameters, the prediction pattern can be stored in the CCM information to indicate that the inherited model is a hybrid CCCM model including various terms. If there are multiple types of hybrid CCCM models, the 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) is 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. The prediction pattern can be stored in the CCM information to indicate that the inherited model is a GL-CCCM model.

[0106] b. Inheritance Spatial Proximity Model Parameters In some embodiments, inherited model parameters may come from an immediately neighboring block. Models from blocks at predetermined locations are added to a candidate list in a predetermined order. This predetermined order can be any possible order of spatially neighboring blocks.

[0107] In some embodiments, the predetermined position and predetermined order may be the same as the spatial candidates for the inter-frame merging mode. In some embodiments, the predetermined position may be... Figure 4 The positions depicted in the diagram. The predetermined order can be B0, A0, B1, A1, and B2.

[0108] In some embodiments, assuming the current block's position, width, and height are (x, y), W, and H, respectively, the predetermined 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 predetermined 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 predetermined position includes the position directly above (W>>1) or ((W>>1)-1) if W is greater than or equal to TH, and the position directly to the left (H>>1) or ((H>>1)-1) if H is greater than or equal to TH.

[0109] In some embodiments, a maximum number of models inherited from spatial neighbors can be added to the candidate list, and the maximum number is less than the number of predetermined locations.

[0110] c. Inheritance temporal proximity model parameters In some embodiments, if the current slice / image is not an intra-frame slice / image, the inherited model parameters can be derived from blocks in previously encoded slices / images. In some embodiments, the current block is located at (x, y) and the block size is [missing information]. The inherited model parameters can come from blocks at some predefined locations in previously encoded slices / images. In some embodiments, the predefined locations can be the same as the predefined locations of temporal candidates for inter-frame merging patterns. In some embodiments, the predefined locations can be... or ,in Two value sets and Defined as: and All values ​​in the set are positive. For example, It can be .For example, .For example, .For example, .For example, and In some embodiments, predefined positions Located within the corresponding region of the current coded block, i.e. and Predefined positions can be .

[0111] In some embodiments, predefined positions Located outside the corresponding region of the current coding block, i.e. ,and Predefined positions can be .

[0112] In some embodiments, models located closer at (x, y) are first added to the final merge candidate list. The previously encoded image from which the inherited parameter model originates is obtained, hereinafter referred to as the co-image. In some embodiments, the previously encoded image from which the inherited parameter model originates, i.e., the co-image, is one of the images in a reference list. In some embodiments, the co-image may be the same as the co-image in the inter-frame merge mode.

[0113] In some embodiments, the co-position image is marked in the image / slice header. A reference list and reference index are also marked in the image / slice header. For example, the co-position image is selected as L0[0]. In another example, the co-position image is selected as L1[0].

[0114] In some embodiments, the co-position image is selected as the image with the smallest POC difference between the corresponding image and the current image in the reference list. In some embodiments, the co-position image is selected as the image with a larger QP in the reference list. In some embodiments, the position in the previously encoded slice / image from which the inherited parameter model comes 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 the selected neighboring blocks, the current block position is (x, y), and the block size is w × h. 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.

[0115] In some embodiments, a specific flag of the co-image (e.g., RprConstraintsActiveFlag) can be used to indicate that time candidates from the co-image are not inherited.

[0116] d. Model of inheriting neighboring blocks from non-neighboring spaces In some embodiments, the inherited model parameters may come from non-nearest spatial neighbor blocks. Models from blocks at predefined locations are added to the candidate list in a predefined order. In some embodiments, the predefined locations and predefined order are the same as the non-nearest spatial neighbor candidates for the inter-frame merge mode.

[0117] Figure 8A and Figure 8BThe current block (labeled CB) and its non-nearest spatial neighboring blocks are marked, from which model parameters may be inherited. The graph also shows predefined locations and their predefined order. Figure 8A Displays non-neighboring spatial locations according to a predefined order based on the first mode (Mode 1). Figure 8B Displays non-proximity spatial locations according to a predefined order based on the second mode (Mode 2). The positions of the numbered squares are predefined positions. The numbers within each square indicate the predefined order. Positions in Mode 1 are added to the CCP merge candidate list before those in Mode 2. The distance between each predefined position is proportional to the width and height of the current block.

[0118] In some embodiments, there is a limit to the maximum number of models inherited from non-nearby spatial neighbors, and the maximum number is less than the number of predefined locations.

[0119] e. Inheriting model parameters from history tables In some embodiments, the 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 candidate list in a predefined order. In some embodiments, the order in which historical candidates are added to the list can be from the beginning to the end of the table. In some embodiments, the order in which historical candidates are added to the list can be from the end to the beginning of the table.

[0120] In some embodiments, a cross component model history table can be maintained to store previous cross component models (i.e., CCM information), and the cross component model history table can be reset at the start of the current image, the current slice, the current tile, every MCTU 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 can be reset at the end of the current image, the current slice, the current tile, the current CTU row, or the current CTU.

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

[0122] In some embodiments, when adding historical candidates to a 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.

[0123] f. CCM information propagated by vector In some embodiments, after an encoding / decoding block, the cross-component model (CCM) information of the current block is exported and stored in the current block. The stored CCM information can be referenced by subsequent or following encoding / decoding blocks. Subsequent encoding / decoding blocks may inherit the CCM information of the current block. The stored CCM information can be inherited by spatial candidates, non-nearby candidates, temporal candidates, historical candidates, and / or other types of candidates.

[0124] In some embodiments, if the current block is not encoded using Cross Component Prediction (CCP) and there are available block vectors in the current block (e.g., the current luma block is encoded in IBC or IntraTMP mode, or a co-located luma block is encoded in IBC or IntraTMP mode), the CCM information of the current block can be obtained by copying the CCM information of a reference block located by the block vectors. (A CCP-encoded block refers to a block encoded using a cross component model, such as an inherited cross component model, a self-derived cross component model, or a cross component model used in chroma fusion, meaning that chroma prediction is based on adding one or more cross component prediction assumptions to one or more existing non-cross component prediction assumptions, or any combination thereof.)

[0125] Figure 9 The propagation of the cross-component model (CCM) based on block vectors is illustrated. The example diagram shows blocks A, B, C, D, E, F, G, and H. In the example shown, blocks A, E, and G are encoded using a cross-component model (e.g., CCLM, MMLM, GLM, CCCM, chroma blending). Block B is not CCP encoded, but block vectors are available at block B. Reference block A is located by block vectors. The CCM information of reference block A, using the cross-component model, is copied and stored (or is) in block B. In some embodiments, if a reference block located by block vectors is also not CCP encoded, but CCM information is stored in the reference block, the CCM information of the current block can be obtained by copying the CCM information stored in the reference block. For example, as... Figure 9 As shown, current block C has available block vectors, and its reference block B is not CCP-encoded but stores CCM information. The CCM information of block B is copied and stored (or used for) block C. The CCM information stored in block B is copied from block A. Therefore, the CCM information of block A is propagated to block C. In some embodiments, if the reference block located by the block vector is not CCP-encoded and does not store CCM information, then CCM information is not stored for the current block.

[0126] In some embodiments, when the current block has multiple available block vectors (e.g., block vectors can be bidirectional, the block can have multiple IntraTMP block vectors, or the current chroma block is co-located with multiple luma blocks and more than one luma block has block vectors), in order to derive the CCM information of the current block, if only one reference block located by a block vector has CCM information, then the CCM information of the reference block is copied and stored in the current block. For example, as... Figure 9 As shown, assume block F has two block vectors (BV0, BV1) and two reference blocks G and H. Block G has CCM information, while block H does not. The CCM information of block G is copied (CCMinfo propagate) and stored in block F.

[0127] In some embodiments, when the current block has multiple block vectors and more than one reference block located by the block vectors has CCM information, the video codec determines / derives the CCM information to be stored (or used as) in the current block based on the CCM information of the more than one reference block. Figure 10 This illustrates a scenario where a current block has two block vectors identifying two reference blocks, both of which possess CCM information. As shown in the figure, a current block (block X) has two reference blocks (block Y and block Z) within the same current image 1000. Reference block Y is identified by block vector BV0 and has CCM information 1015. Reference block Z is identified by block vector BV1 and has CCM information 1025. Blocks Y and Z may or may not be CCP encoded. The video codec determines the CCM information 1005 of the current block X based on CCM information 1015 and CCM information 1025.

[0128] In different embodiments, the video codec determines the current block CCM information 1005 in different ways. For example, in some embodiments, the current block CCM information 1005 is derived by combining all or part of the CCM models of its reference blocks (e.g., CCM models 1015 and 1025 of reference blocks 1010 and 1020).

[0129] In some embodiments, when the current block (e.g., Figure 10 The current block X has multiple block vectors, and more than one reference block is located by the block vectors (e.g., Figure 10 When reference blocks Y and Z have CCM information, one of the reference blocks is selected according to a set of predefined rules. The CCM information of the selected reference block is then copied and stored in the current block. In some embodiments, a reference block encoded with CCP is selected. In some embodiments, a reference block encoded with internal encoding is selected. In some embodiments, a reference block encoded with inter-frame or IBC encoding is selected.

[0130] In some embodiments, a reference block with the smallest distance to the current block is selected. The CCM information of the selected reference block is copied and stored in the current block. The distance between the reference block and the current block is located at (x... r y r ) and (x c y c ), can be obtained through Euclidean distance Calculate. (x) r y r ) and (x c y c The reference block and the current block can be located at their top-left, top-right, bottom-left, bottom-right, or center positions. The distance metric can also be Manhattan distance or Minkowski distance.

[0131] For some embodiments, the one with the minimum horizontal distance, |x r - x c The reference block is selected. The CCM information of the selected reference block is copied and stored in the current block. For some embodiments, the reference block with the smallest vertical distance, |y r - y c The CCM information of the selected reference block is copied and stored in the current block. In some embodiments, the previously described rules can be used in combination, and it is not necessary to apply all the previously described rules. For example, a CCP-encoded reference block is selected. If there is more than one CCP-encoded reference block, the CCP-encoded reference block with the shortest distance to the current block is selected. If there is more than one CCP-encoded reference block with the smallest distance to the current block, the one with the smallest horizontal distance, |x r - x c |, the reference block. Another example is selecting a reference block encoded by CCP. If there is more than one CCP-encoded reference block, the CCP-encoded reference block with the shortest distance to the current block is selected. If there is more than one CCP-encoded reference block with the smallest distance to the current block, the one with the smallest vertical distance |y is selected. r - y c The CCM information of the selected reference block is copied and stored in the current block. In some embodiments, if the current block is not CCP-coded and there are available motion vectors in the current block (e.g., the current luma block is inter-frame coded), the CCM information of the current block can be derived by copying the CCM information of its reference block in a reference image, which is located by the motion vectors of the current block. Figure 11An example of motion vector-based CCM information propagation is illustrated. The figure shows several blocks A through H. Blocks A, E, and G are encoded using a cross-component model (e.g., CCLM, MMLM, GLM, CCCM). As shown, block B is not CCP-encoded, and motion vectors are available at block B. A reference block A is located by motion vectors. The CCM information of the reference block A, using a cross-component model, is copied and stored in block B. In some embodiments, if a reference block located by motion vectors is also not CCP-encoded, but CCM information is stored in the reference block, the CCM information of the current block can be derived by copying the CCM information stored in the reference block. Figure 11 In the example, block C has available motion vectors MV, and its reference block B is not CCP-coded but stores CCM information. The CCM information of block B is copied and stored in block C. The CCM information stored in block B is copied from block A. Therefore, the CCM information of block A is propagated to block C. In some embodiments, if a reference block located by motion vectors is not CCP-coded and does not store CCM information, then CCM information is not stored for the current block. In some embodiments, when the current block is inter-coded using bidirectional prediction, in order to derive the CCM information of the current block, if only one reference block located by motion vectors has CCM information, then the CCM information of the reference block with CCM information is copied and stored in the current block. For example, as... Figure 11 As shown, block F is inter-coded using bidirectional prediction. The two reference blocks located by the motion vectors (MV0 and MV1) of block F are block G and block H. Block G stores CCM information, while block H does not. The CCM information of block G is copied and stored in block F. In some embodiments, when the current block is inter-coded using bidirectional prediction and both reference blocks located by motion vectors store CCM information, the video codec determines / derives the CCM information stored in the current block based on the CCM information of more than one reference block. Figure 12The diagram illustrates a current block with two reference blocks identified by two motion vectors, both of which have CCM information. As shown, a current block (block P) is inter-coded in the current frame 1202 using bidirectional prediction. Two reference blocks (block Q and block R) are located by motion vectors in different reference frames 1201 and 1203. Reference block Q is located by block vector MV0 and has CCM information 1215. Reference block R is located by block vector MV1 and has CCM information 1225. Reference blocks Q and R may or may not be CCP-coded. The video codec determines the CCM information 1205 of the current block P based on CCM information 1215 and CCM information 1225. In different embodiments, the video codec determines the current block CCM information 1205 in different ways. For example, in some embodiments, the current block CCM information 1205 is derived by combining all or a subset of CCM models 1215 and 1225 of reference blocks Q and R. In another example, in some embodiments, one of the reference blocks is selected according to a set of predefined rules. The CCM information of the selected reference block is then copied and stored in the current block. In some embodiments, to select from one or more reference blocks to obtain CCM information, a reference block encoded with CCP is selected. In some embodiments, a reference block encoded intra-frame is selected. In some embodiments, a reference block encoded inter-frame or IBC is selected. In some embodiments, a reference block whose reference picture (i.e., the picture containing the reference block) has a small POC distance from the current picture is selected. In some embodiments, a reference block whose reference picture has a small / minimum quantization parameter (QP) value difference from the current picture is selected. In some embodiments, a reference block whose reference picture has a small QP value is selected. In some embodiments, a reference block whose reference picture has a large QP value is selected.

[0132] In some embodiments, the reference block indicated by the L0 motion vector is selected. In some embodiments, the reference block indicated by the L1 motion vector is selected. In some embodiments, the previously described rules can be combined and not all of the previously described rules need to be applied. For example, the reference block encoded by CCP is selected. If both blocks are encoded by CCP, the block whose reference picture has a smaller POC distance from the current picture is selected. If both blocks are encoded by CCP and have the same POC distance from the current picture, the reference block whose reference picture has a smaller QP difference from the current picture is selected. If both blocks are encoded by CCP, have the same POC distance from the current picture, and have the same QP difference from the current picture, the reference block whose reference picture has a smaller QP value is selected. Another example, the block whose reference picture has a smaller POC distance from the current picture is selected. If the POC distances of both blocks from the current picture are the same, the reference block whose reference picture has a smaller QP difference from the current picture is selected. If the POC distances of both blocks from the current picture are the same and the QP differences from the current picture are the same, the reference block whose reference picture has a smaller QP value is selected.

[0133] In some embodiments, if the RprConstraintsActiveFlag of the reference picture is true, the CCM information is not retrieved and stored. In some embodiments, if the RprConstraintsActiveFlag of the reference picture is true, the motion vectors are scaled according to the ratio between the current picture and the reference picture (the ratio is based on, for example, the corresponding scaling windows of the current picture and the reference picture).

[0134] In some embodiments, the position located by the motion vector is in the current CTU row of the co-located CTU row of the reference picture. Figure 13 The position located by the motion vector in the reference picture is marked. In some embodiments, if the position located by the motion vector is outside the co-located CTU row, the vertical component of the motion vector is clipped. In Figure 13 In the example shown, the minimum and maximum vertical positions of the current CTU row are Y1 and Y2 respectively. Assume the position located by the motion vector is (Xm, Ym). If Ym < Y1, the position is changed to (Xm, Y1). If Ym > Y2, the position is changed to (Xm, Y2).

[0135] g. Inheritance from the merge mode 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 a cross-component prediction (CCP) codec tool (e.g., CCLM, MMLM, CCCM) is fused with another chroma intra-frame prediction generated using a cross-component prediction codec tool to obtain the final intra-frame prediction. 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.

[0136] In some embodiments, when inheriting cross-component model parameters from blocks / positions encoded in 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 CCP model parameters, fusion weights and the encoding / decoding mode of non-CCP-encoded intra-prediction are also inherited. That is, the chroma intra-fusion mode is inherited.

[0137] h. Store the time model 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 indexes of the table. The size of the index buffer is the same as the image. When referencing CCM information at position (x, y) within a co-image (as described in Section Vc, “Inheriting Temporal Proximity Model Parameters”), an index value is retrieved from the co-image's index buffer at position (x, y). If the index value indicates that no CCM information is available at position (x, y), the CCM information cannot be referenced. Otherwise, an item is obtained from the table indicated by the index value as the CCM information to be referenced.

[0138] In some embodiments, the table used to store CCM information is an image-level table. The CCM information for each image is stored in a separate table. Figure 14 A conceptual diagram illustrates an image-level index buffer for storing CCM information indices in a storage table. When a pixel block in a future image selects the current image as its co-location image, a set of CCM information (including model parameters) from the current image may be inherited as a temporal candidate to encode the pixel block in the future image using a cross-component merging pattern. The current image is labeled as CCM image 1400.

[0139] CCM image 1400 has a corresponding index buffer 1420. When referencing CCM information at position (x, y) (which could be a pixel position or a block position) within CCM image 1400, an index value is retrieved from position (x, y) in index buffer 1420. If the index value indicates that no CCM information is available at position (x, y), the CCM information cannot be referenced. Otherwise, an item is obtained from indexed CCM table 1430, indicated by the index value, as the CCM information to be referenced. In the example, the index value of position (x, y) in index buffer 1420 is '2', corresponding to index position 2 in indexed CCM table 1430. Index position 2 in indexed CCM table 1430 stores a set of CCM information labeled "CCP2". (Index value '0' indicates no CCM information). In order for future images to reference the 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, and the corresponding index value is stored in the corresponding position in the index buffer.

[0140] In some embodiments, a single table is created to store the cross-component model information for all images. In other embodiments, multiple tables are used to store the cross-component model information for a single image. An image can be divided into several regions, each corresponding to its own table.

[0141] In some embodiments, a table is created for each time identifier, such that cross-component model information for layers with the same time identifier is stored in the same table. Images with different time identifiers (or in different time identifier layers) are at different encoding or decoding levels. Specifically, an image with time identifier = 0 is encoded before an image with time identifier = 1, which in turn is encoded before an image with time identifier = 2, and so on. Images with larger time identifiers may be encoded or decoded based on images with smaller time identifiers.

[0142] In some embodiments, after storing the cross-component model information to the corresponding table at position (x, y) of the current encoded / decoded image, the table index value of the cross-component model information is stored at position (x, y) in the index buffer of the current encoded / decoded image. If no cross-component model 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 cross-component model information is available.

[0143] In some embodiments, if there is no available cross component model information at position (x, y) of the current encoded / decoded image, the cross component model indicated by the index value of position (x, y) in the index buffer of the co-occurring image can be stored in the index table of the current encoded / decoded image, and the corresponding index value is stored at position (x, y) of the index buffer of the current encoded / decoded image. Figure 15 The diagram illustrates the copying of cross-component model information from the index table of the co-located image to the index table of the current image. The icon shows a current image 1500 with index buffer 1505 for accessing cross-component model information. At position (x, y), the current image 1500 has no available cross-component model information, as indicated by index value '0' in index buffer 1505. On the other hand, the co-located image 1520 at position (x, y) stores CCM information 1533 ("CCP3") in index table 1530, as indicated by index value '3' in index buffer 1525 of the reference image 1520. To make CCM information 1533 available to the current image 1500, CCM information 1533 is copied from index table 1530 to index table 1510 of the current image 1500. In index buffer 1505 at position (x, y) of the current image, CCM information 1533 in index table 1510 is indicated by index value '2'.

[0144] In some embodiments, if no cross-component model information is available at position (x, y) of the current encoded / decoded image, and a block vector (Δx, Δy) is available at position (x, y) (e.g., the current luma block is encoded in IBC or IntraTMP mode, and the co-occurring luma block is encoded in IBC or IntraTMP mode), then the index value of position (x+Δx, y+Δy) in the index buffer can be stored at position (x, y) of the index buffer of the current encoded / decoded image.

[0145] Figure 16This conceptually illustrates the export and storage of cross-component model information based on block vector copy index buffer entries. As shown, a CCM image 1600 (the current image that has been encoded / decoded or a reconstructed portion used as a reference for subsequent encoding portions) has an index buffer 1605 for locating cross-component model information in index table 1610. As shown, at position (x, y), CCM image 1600 has no available cross-component model information, as indicated by the value '0' at the corresponding position in index buffer 1605. 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 1600. Position (x', y') has cross-component model information, as indicated by the corresponding non-zero index value ('4') for position (x', y') in index buffer 1605. 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 cross-component model information pointing to the index value ('4').

[0146] 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

[0147] In some embodiments, if there is no available CCM information at position (x, y) of the current encoded / decoded image, and the block at position (x, y) is inter-frame coded and the motion vector is (Δx, Δy), the index value of position (x+Δx, y+Δy) in the index buffer of the reference image (also indicated by the motion vector) can be stored at position (x, y) of the index buffer of the current encoded / decoded image.

[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 inter-frame coded, and the motion vector is bidirectional (Δxi, Δyi), i = 0 or 1, the index value of position (x+Δxi, y+Δyi) in the index buffer of the reference image (also indicated by the motion vector) can be stored at position (x, y) of the index buffer of the current encoded / decoded image.

[0149] In some embodiments, a set of predefined rules may be used to determine how to select one of the motion vectors (i.e., retrieve the index value located by the motion vector (Δxi, Δyi) and store the corresponding cross component model in the current table). These rules may be the same as those described in Section Vf for selecting the reference block located by the motion vector.

[0150] 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 inter-frame coded with motion vector (Δx, Δy), the index value of position (x+Δx, y+Δy) in the index buffer of the reference image, also indicated by the motion vector, 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.

[0151] 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 inter-frame coded, and the motion vector is bidirectional (Δxi, Δyi), i = 0 or 1, the index value of a position (x+Δxi, y+Δyi) in the index buffer of the reference image, also indicated by the motion vector, 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.

[0152] Figure 17The diagram illustrates the export and storage of CCM information based on motion vector copying and storing index table entries. The icon shows a current image 1700 with an index buffer 1705 for accessing CCM information in index table 1710. At position (x, y), current image 1700 has no available CCM information, as indicated by index value '0' in index buffer 1705. Position (x, y) is inter-frame coded using a motion vector 1702, which references a reference image 1720 at position (x', y') = (x+Δx, y+Δy). Reference image 1720 at position (x', y') has CCM information 1732 stored in index table 1730, as indicated by index value '2' in index buffer 1725. To make CCM information 1732 available for use by the current image 1700, CCM information 1732 is copied from index table 1730 to index table 1710 of the current image 1700. The CCM information 1732 in index table 1710 is represented by the index value '3' in index buffer 1705 of the current image 1700 at position (x, y).

[0153] 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. Assuming the index value of the CCM information to be deleted is N, all values ​​in the index buffer greater than N will be decremented by 1.

[0154] In some embodiments, the table used to store CCM information has a maximum size limit. The high-level syntax can be signaled in the Sequence Parameter Set (SPS), Picture Parameter Set (PPS), Picture Header (PH), or Slice Header (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.

[0155] In some embodiments, when the table storing CCM information is an image-level table, the maximum size limit for tables of intra-frame images is greater than the maximum size limit for tables of inter-frame images. In some embodiments, tables associated with images having larger time identifiers have smaller maximum size limits. In some embodiments, for random access configurations, CCM information for images in the maximum time identifier layer is not stored. Therefore, the table size is 0 (i.e., these tables and their associated index buffers are not created). In some embodiments, the maximum size limit of the table is related to the POC distance between the associated image and the nearest intra-frame image of the associated image (in terms of POC distance). The shorter the POC distance, the larger the maximum size limit.

[0156] In some embodiments, when a table is created for each time identifier, CCM information from the same time identifier layer is stored in the same table. Tables associated with larger time identifiers have smaller maximum size limits. In some embodiments, for random access configurations, CCM information for images in the largest time identifier layer is not stored. Therefore, the table size is 0 (i.e., the table and its associated index buffer are not created). In some embodiments, the maximum size limit of the table is related to the POC distance between the associated image and its nearest intra-frame image (in terms of POC distance). The shorter the POC distance, the larger the maximum size limit.

[0157] In some embodiments, when using multiple tables to store CCM information from an image, the image can be divided into multiple regions, each corresponding to its own table. The tables can have different maximum size limits or the same maximum size limit. In some embodiments, the table associated with an image having a larger time identifier has a smaller maximum size limit. In some embodiments, the maximum size limit of the table is related to the POC distance between the associated image and its nearest intra-frame frame (in terms of POC distance). The shorter the POC distance, the larger the maximum size limit.

[0158] In some embodiments, when attempting to store CCM information at position (x, y) in an image into a table, the similarity between the CCM information to be added and existing CCM information in the table can be compared. If the CCM information to be added is similar to existing CCM information, the CCM information to be added is not stored, and the index of the existing CCM information is stored at position (x, y) in the index buffer. The similarity between CCM information can be determined using the same method used when adding a model to the history table, as described in Section Vj. In some embodiments, the similarity between CCM information can be determined using a method similar to that used when adding a model to the merge candidate list, as described in Section Vi above.

[0159] In some embodiments, the table may be reset at the start of the code-decode real-time decode refresh (IDR) screen. In some embodiments, the table may be reset after the code-decode IDR screen. In some embodiments, the table may be reset at the start of the code-decode clean random access (CRA) screen. In some embodiments, the table may be reset after the code-decode CRA screen. In some embodiments, the reset mechanism may be the same as the reset mechanism used in the parameter set or reference screen.

[0160] In some embodiments, indices stored in the index buffer can only be referenced by units greater than or equal to the smallest code-decoding unit. For example, if the smallest code-decoding unit is 4x4, then an index can be referenced by an 8x8 grid. That is, an 8x8 block has the same index value. To retrieve an index value at 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 to the nearest point on the grid.

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

[0162] i. Remove or modify similar neighbor model parameters When inheriting cross-component model parameters from other blocks, the video codec may further examine the similarity between the inherited model and existing models in the candidate list or model candidates derived from neighboring reconstructed samples of the current block (e.g., CCLM, MMLM, or CCCM models derived from neighboring reconstructed samples of the current block). If a candidate parameter's model is similar to an existing model, that model will not be included in the candidate list.

[0163] In some embodiments, when comparing two models, the two models are considered dissimilar if their cross-component encoding / decoding patterns (e.g., CCLM, MMLM, CCCM, CCCM with multiple models, GLM, CCRM, ...) are different. In some embodiments, when comparing a model with existing models in a candidate list, the two models are considered similar if their encoding / decoding patterns are the same and all corresponding parameters of the two models are the same or similar, and the model will not be added to the candidate list. In some embodiments, two parameters are considered similar if the difference between them is less than or equal to a threshold.

[0164] In some embodiments, if a candidate model is similar to one of the existing candidate models, the video codec may adjust the inherited model parameters to make the inherited model different from the existing candidate model. For example, if the inherited scaling parameters are similar to one of the existing candidate models, the inherited scaling parameters may be increased by a predetermined offset (e.g., 1>>S or -(1>>S), where S is a displacement parameter) to make the inherited parameters different from the existing candidate model.

[0165] In some embodiments, the video codec may only compare a subset of model parameters (of the model to be added) with existing models in the candidate list. For example, when a CCLM candidate model to be added has scaling and offset parameters, the video codec may only determine whether the scaling or offset parameters are the same as or similar to those of existing candidates. If the scaling or offset parameters of the model to be added are the same as or similar to those of existing models, the new candidate will not be included in the candidate list. As another example, when a CCCM candidate to be added has parameters c0 through c6, the video codec may only determine whether n parameters (n < 7) are the same as or similar to those of existing candidates. If all the parameters to be compared are the same or similar, the candidate model to be added will not be included in the candidate list.

[0166] In some embodiments, the number of candidates with the same type (e.g., MMLM, CCCM, or GLM) is limited when adding candidates to the list. For example, if the current list has k candidates of type MMLM, the video codec will not add any more candidates of type MMLM to the list. Similarly, if the current list has k candidates of type CCCM, the video codec will not add any more candidates of type CCCM to the list. Likewise, if the current list has k candidates of type GLM, the video codec will not add any more candidates of type GLM to the list.

[0167] j. Remove or modify similar model parameters when adding candidates to the history table. When a cross-component model is added to the history table, the video codec may further check the similarity between the model to be added and existing models in the history table. If the model to be added is similar to an existing model, it will not be included in the history table.

[0168] In some embodiments, if the inherited model to be added is similar to one of the existing candidate models, the video codec may adjust the inherited model parameters to make the model to be added different from the existing candidate models. For example, if the scaling parameters of the model to be added are similar to one of the existing candidate models, the video codec may add a predetermined offset (e.g., 1>>S or -(1>>S), where S is a displacement parameter) to the scaling parameters of the model to be added to make the model to be added different from the existing candidate models.

[0169] In some embodiments, the video codec may only compare some model parameters with existing models in the history table. For example, a CCLM candidate has scaling and offset parameters, and the video codec may only determine whether the scaling or offset parameters are the same as or similar to existing candidates. If the scaling or offset parameters of the model to be added are the same as or similar to existing models, the model to be added will not be included in the history table. As another example, a CCCM candidate has parameters c0 to c6, and the video codec may only determine whether n parameters (n<7) are the same as or similar to existing candidates. If all the parameters to be compared are the same or similar, the model to be added will not be included in the history table.

[0170] In some embodiments, the number of candidates with the same type (e.g., MMLM, CCCM, or GLM) is limited when adding candidates to the history table. For example, if the current history table has k candidates of type MMLM, then further additions of candidates of type MMLM to the history table are not allowed. Similarly, if the current history table has k candidates of type CCCM, then further additions of candidates of type CCCM to the history table are not allowed. And if the current history table has k candidates of type GLM, then further additions of candidates of type GLM to the history table are not allowed.

[0171] In some embodiments, the constraints or rules preventing the addition of redundant candidates to the history table will be the same as / shared with the rules preventing the addition of redundant candidates to the candidate list. Examples of these rules or constraints can be found in Section Vi, “Removing or Modifying Similar Neighbor Model Parameters”.

[0172] k. Reorder the candidate list Candidates in the list can be reordered to reduce the syntax overhead of candidate indexing in signal selection, or the syntax of candidate indexing in signal selection can be bypassed by selecting one or more candidates using implicit rules.

[0173] In some embodiments, the reordering rules may rely on the encoding / decoding information or model error of neighboring blocks. For example, if the neighboring block above or to the left is MMLM encoded, an MMLM candidate in the list can be moved to the head of the current list.

[0174] In some embodiments, the reordering rule is based on applying the candidate model to the neighboring templates of the current block and then comparing the error with the reconstructed samples of the neighboring templates.

[0175] L. Self-derived cross-component model A self-derived cross-component model refers to a model whose parameters are derived from the current chroma sample and co-located luma sample (e.g., motion compensation result if the current block is inter-frame). An example of a self-derived cross-component model is CCRM. In some embodiments, when using self-derived models to generate cross-component models, the model (filter shape / mode, parameter terms) is unified with models in regular intra-frame models. For example, a CCRM model can be unified with any predefined existing intra-frame cross-component model (e.g., CCCM, GLM, MMLM using non-downsampled luma samples).

[0176] In some embodiments, self-derived cross-component candidates refer to one or more models used to generate cross-component predictions for the current block. The cross-component predictions for the current block (used to generate target prediction samples) are formed by combining one or more source terms according to the following weight settings: pred(i, j) = (sourceTermSet0(i, j) + sourceTermSet1(i, j) + … +biasTermSet) (1) Where (i, j) is the sample position in the current block.

[0177] As shown in equation (1) above, pred(i, j) is the target (predicted) sample in the current block, which can be obtained after our proposed mechanism. sourceTermSet0 includes one or more source terms from the luma component, sourceTermSet1 includes one or more source terms from the chroma component, and biasTermSet includes one or more bias terms.

[0178] Equation (1) is an example, and the proposed mechanism can use any subset or extension of sourceTermSet0, sourceTermSet1, and biasTermSet. Each sample or any subset of samples in the current block obtains its target (predicted) sample according to Equation (1). The contents of sourceTermSet0(i,j), sourceTermSet1(i,j), and biasTermSet are as follows.

[0179] SourceTermSet0(i, j) includes one or more luminance source terms, denoted as sourceTerm00, sourceTerm01, ..., and / or sourceTerm0n-1. The value of n represents the number of taps in the source term set. In some embodiments, source terms may be linear terms and / or nonlinear terms, linear terms only, and / or nonlinear terms only.

[0180] In some embodiments, n is a predefined value, such as 1, 2, ... or any positive integer. For example, the predefined value is fixed in a standard. In some embodiments, n is determined by the encoding / decoding information of the current block and / or the sample position (i, j). For example, when the current block is encoded by a specific encoding / decoding tool, n may be fixed to a predefined value of that specific encoding / decoding tool.

[0181] In some embodiments, the pattern of n-tap refers to a pattern defined as surrounding / containing a location (i L j L The pattern of any subset of the window region Mx N. Figure 18 An example pattern of n taps in a window region MxN is shown. If the target sample is luminance, (i L j L (i, j). The icon shows a 5x5 intersection pattern: (including or not excluding (i) L j L If the target sample is chromatic (e.g., Cb or Cr), (i L j L ) is the same brightness position as (i, j). For example, only the center (i) of the window is used. L j L ).

[0182] In some embodiments, the source content is based on predicted samples generated from a prediction model and / or reconstructed samples generated from the predicted samples and reconstruction residuals. In some embodiments, the source content is a filtered source or a source that has undergone any preprocessing. For example, the source content is predicted / reconstructed samples filtered by a predefined model or filter.

[0183] In some embodiments, the source content is gradient information from predicted and / or reconstructed samples. If the target sample (i, j) belongs to chroma and the gradient information of the isotopic luminance sample (as the center circle) is calculated using a Sobel filter or a predefined filter. The above... Figure 1 Several different Sober filter examples are shown. In each Sober filter example, each value around the central circle is multiplied by the corresponding predicted / reconstructed sample in the same brightness block, and then summed to form the gradient information of the source term for the target sample (i, j).

[0184] In some embodiments, since the target sample is a chromaticity sample (e.g., Cb or Cr), the predicted and / or reconstructed samples are located within a co-located (luminance) block from the current (chromaticity) block. The predicted and / or reconstructed samples are treated as initial samples and used as source content to generate the target sample. In some embodiments, the source item may further include positional information. For example, if the target sample refers to luminance, the horizontal position (i) of (i, j) is used in the source item, while the vertical position (j) of (i, j) is used in the source item. Otherwise, the horizontal position from the co-located luminance block of sample (i, j) is used in the source item, while the vertical position from the co-located luminance block of sample (i, j) is used in the source item.

[0185] In some embodiments, the source term may further include location information. For example, if the target sample refers to chromaticity, the horizontal position of the isotopic luminance of sample (i, j) is used in the source term, while the vertical position of the isotopic luminance of sample (i, j) is used in the source term.

[0186] SourceTermSet1(i, j) includes one or more chromaticity (Cb or Cr) source terms, denoted as sourceTerm00, sourceTerm01, ... and / or sourceTerm0m-1. The value of m represents the number of points in the source terms set. In some embodiments, source terms can be linear terms and / or nonlinear terms, linear terms only, and / or nonlinear terms only. In another embodiment, m is a predefined value, such as 1, 2, ... or any positive integer. For example, the predefined value is fixed in a standard.

[0187] In some embodiments, m is determined by the codec information and / or the sample position (i, j). For example, when the current block is encoded by a specific codec tool, m is fixed to a predefined value for that specific tool. In some embodiments, the pattern of the m point refers to a pattern defined around / containing the position (i, j). C , j C The pattern of any subset of the window region M2 x N2. Figure 19 The surrounding position (i) is marked C, j C An example pattern of n points in a window region M2xN2. If the target sample is chromaticity (Cb or Cr), (i C ,j C (i, j). The icon shows a pattern of a 5x5 cross (containing or not excluding (i)). C ,j C Example of (i). If the target sample is brightness, (i C ,j C (i, j) is the isotropic chromaticity position from (i, j). For example, only the center (i, j) of the window is used. C ,j C ).

[0188] In some embodiments, the source content is based on predicted samples generated by a prediction model and / or reconstructed samples generated from the prediction model and reconstruction residuals based on the predicted samples. In some embodiments, the source content is a filtered source or a source that has undergone any preprocessing. For example, the source content is predicted / reconstructed samples filtered by a predefined model or filter.

[0189] In some embodiments, the source content is gradient information from predicted and / or reconstructed samples. If the target sample (i, j) belongs to the luminance and isotopic chrominance samples, the gradient information is obtained using any Sober filter (e.g., Figure 1 The predicted and / or reconstructed samples are calculated using either the target sample (as shown) or any predefined filter. In some embodiments, if the target sample is a chroma sample, the predicted and / or reconstructed samples are located within the current block. The predicted and / or reconstructed samples are treated as initial samples and used as source content for generating the target sample. In some embodiments, the source item may also include positional information. For example, if the target sample refers to chroma, the horizontal position (i) of (i, j) is used for the source item, and the vertical position (j) of (i, j) is used for the source item.

[0190] BiasTermSet is a predefined value. In one embodiment, the bias term is the midValue of bitDepth specified in the standard. For example, the bias term is set to... In some embodiments, the bias term is the same for every sample in the current block. That is, the bias term is independent of position (i, j).

[0191] In some embodiments, a weighted setting is used to (i) estimate the relationship between the reference region of the current (chroma) block and the predicted and / or reconstructed samples of the reference region of the corresponding luma block (e.g., to minimize distortion), (ii) generate weights (referring to model parameters) according to a regression method, and then (iii) apply the weights to the source terms to obtain the target (predicted) sample in the current block.

[0192] In some embodiments, the predefined regression method may be a linear minimum mean square error (LMMSE) method, such as CCLM, or any unified method with the regression method used by CCLM. In some embodiments, the predefined regression method may be an LDL decomposition method, such as CCCM, or any unified method with the regression method used by CCCM. In some embodiments, the predefined regression method may be Gaussian elimination.

[0193] In some embodiments, the reference region of the current block is the spatial neighbor region of the current block. The reference region of the corresponding luminance block is the spatial neighbor region of the corresponding luminance block. Figure 20 The spatial neighboring regions of the current block 2000 that could potentially serve as reference areas are marked. As shown in the figure, the spatial neighboring regions of the current block include the upper reference region, the left reference region, the upper-left reference region, and / or any subset thereof. The size of the upper reference region is A. W x A H The size of the reference region on the left is L. W xL H The size of the upper left reference area is AL. W x AL H ,in A W = Current block width (W), k*W, W + current block height (H), any predefined value, or any adaptive value based on the current block's block position, block width, block height, and / or block area.

[0194] A H or AL H = H, any predefined value (1, 2, 4, …), or any adaptive value based on the current block's position, width, height, and / or area.

[0195] L W or AL W = W, any predefined value (1, 2, 4, …), or any adaptive value based on the current block's position, width, height, and / or area.

[0196] L H = H, k*H, H + W, any predefined value, or any adaptive value based on the current block's position, width, height, and / or area.

[0197] In some embodiments, the reference region of the current block is the vector co-location region of the current block, while the reference region of the corresponding luma block is the vector co-location region of the corresponding luma block. For inter-frame encoding / decoding units containing luma and chroma blocks, the vector co-location region of the current block refers to the motion compensation result obtained using the motion information (motion vector and reference image) of the current block, while the vector co-location region of the corresponding luma block refers to the motion compensation result obtained using the motion information (motion vector and reference image) of the corresponding luma block. For IBC or intra-frame TMP, the vector co-location region of the current block refers to the motion compensation result generated based on the motion information (block vector and current image) of the current block, while the vector co-location region of the corresponding luma block refers to the motion compensation result generated based on the motion information (block vector and current image) of the corresponding luma block.

[0198] In some embodiments, the two reference regions for the current block described above can be used together. For example, typically, when deriving model parameters, samples in the vector co-location region of the current block are used as input samples; however, for smaller blocks, when deriving model parameters, samples in the spatially neighboring reference region are used as additional input samples.

[0199] In this invention, the term "block" can refer to TU / TB, CU / CB, PU / PB, or CTU / CTB. The term "LM" in this invention can be considered a CCLM / MMLM mode, or any other extension / variant of CCLM (e.g., the CCLM extension / variant proposed in this invention). One variant is MMLM, which uses a threshold to determine different models for different samples in the current chroma component. Another variant, for Cb (or Cr), derives model parameters from multiple iso-luminance blocks. More possible variants are shown below. CCLM variants here mean that when the block indication reference uses one of the cross-component modes (e.g., CCLM_LT, MMLM_LT, CCLM_L, CCLM_T, MMLM_L, MMLM_T and / or an intra-prediction mode that is not one of the traditional DC, planar, and angular modes), several optional modes can be selected. An example of the Convolutional Cross-Component Mode (CCCM) as an optional mode is shown below. When this optional mode is applied to the current block, cross-component information from the model containing nonlinear terms is used to generate chroma predictions. Optional modes may follow the template selection of CCLM, so the CCCM family includes CCCM_LT, CCCM_L and / or CCCM_T.

[0200] The methods proposed in this invention (for CCLM) can be used for any other cross-component mode. Any combination of methods proposed in this invention can be applied. Any of the foregoing methods can be implemented in the encoder and / or decoder. For example, any proposed method can be implemented in the inter-frame / intra-frame / prediction / IBC / transform / quantization module of the encoder, and / or in the inter-frame / intra-frame / prediction / IBC / transform / quantization module of the decoder. Alternatively, any proposed method can be implemented as circuitry connected to the inter-frame / intra-frame / prediction / transform / quantization module of the encoder and / or the inter-frame / intra-frame / prediction / IBC / transform / quantization module of the decoder to provide the information required by the inter-frame / intra-frame / prediction / IBC / transform / quantization module.

[0201] VI. Example of a video encoder Figure 21 An example of a video encoder 2100 that may implement cross-component prediction is shown. As shown, the video encoder 2100 receives an input video signal from a video source 2105 and encodes the signal into a bitstream 2195. The video encoder 2100 has multiple components or modules for encoding the signal from the video source 2105, including at least some components selected from the transform module 2110, quantization module 2111, inverse quantization module 2114, inverse transform module 2115, intra-frame picture estimation module 2124, intra-frame prediction module 2125, motion compensation module 2130, motion estimation module 2135, loop filter 2145, reconstructed picture buffer 2150, MV buffer 2165, MV prediction module 2175, and entropy encoder 2190. The motion compensation module 2130 and motion estimation module 2135 are part of the inter-frame prediction module 2140. Intra-frame prediction module 2125 and intra-frame prediction estimation module 2124 are part of current image prediction module 2120, which uses current image reconstruction samples as reference samples for predicting the current block.

[0202] In some embodiments, modules 2110 to 2190 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 2110 to 2190 are modules of hardware circuitry implemented by one or more integrated circuits (ICs) of an electronic device. Although modules 2110 to 2190 are depicted as independent modules, some modules may be combined into a single module.

[0203] Video source 2105 provides an uncompressed raw video signal, which represents the pixel data of each video frame. Subtractor 2108 calculates the difference between the raw video pixel data from video source 2105 and the predicted pixel data 2113 from motion compensation module 2130 or intra-frame prediction module 2125, as a prediction residual 2109. Transform module 2110 converts the difference (or residual pixel data or residual signal 2108) into transform coefficients (e.g., by performing a discrete cosine transform, or DCT). Quantization module 2111 quantizes the transform coefficients into quantized data (or quantization coefficients) 2112, which is encoded into a bitstream 2195 by entropy encoder 2190.

[0204] Inverse quantization module 2114 inverse-quantizes quantized data (or quantization coefficients) 2112 to obtain transform coefficients, and inverse transform module 2115 performs inverse transform on the transform coefficients to generate reconstruction residual 2119. Reconstruction residual 2119 is added to predicted pixel data 2113 to generate reconstructed pixel data 2117. In some embodiments, reconstructed pixel data 2117 is temporarily stored in an online buffer 2127 (or intra-frame prediction buffer) for intra-frame image prediction and spatial MV prediction. Reconstructed pixels are filtered via loop filter 2145 and stored in reconstructed image buffer 2150. In some embodiments, reconstructed image buffer 2150 is external to the storage of video encoder 2100. In some embodiments, reconstructed image buffer 2150 is internal to the storage of video encoder 2100.

[0205] Intra-frame image estimation module 2124 performs intra-frame prediction based on reconstructed pixel data 2117 to generate intra-frame prediction data. The intra-frame prediction data is provided to entropy encoder 2190 for encoding into a bitstream 2195. The intra-frame prediction data is also used by intra-frame prediction module 2125 to generate predicted pixel data 2113.

[0206] The motion estimation module 2135 performs inter-frame prediction by generating MVs (Motion Values) to reference reference pixel data stored in the reconstructed image buffer 2150 from previously decoded frames. These MVs are provided to the motion compensation module 2130 to generate predicted pixel data.

[0207] Instead of encoding the complete actual MV in the bitstream, the video encoder 2100 uses MV prediction to generate a predicted MV, and the difference between the MV used for motion compensation and the predicted MV is encoded as residual motion data and stored in the bitstream 2195.

[0208] The MV prediction module 2175 generates a predicted MV based on a reference MV generated for encoding a previous video frame, i.e., a motion-compensated MV used for motion compensation. The MV prediction module 2175 retrieves the reference MV of the previous video frame from the MV buffer 2165. The video encoder 2100 stores the MV generated for the current video frame in the MV buffer 2165 as a reference MV for generating the predicted MV.

[0209] The MV prediction module 2175 uses a reference MV to create a predicted MV. The predicted MV can be calculated by 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 the bitstream 2195 by the entropy encoder 2190.

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

[0211] Loop filter 2145 filters or smooths the reconstructed pixel data 2117 to reduce artistic effects during encoding and decoding, particularly at pixel block boundaries. In some embodiments, the filtering or smoothing operations performed by loop filter 2145 include deblocking filter (DBF), sample adaptive offset (SAO), and / or adaptive loop filter (ALF). In some embodiments, luma-mapped chroma scaling (LMCS) is performed before the loop filter.

[0212] Figure 22 Parts of the video encoder 2100 are labeled, which implement cross-component prediction for non-intra-coded blocks. The luma component of the current block may be encoded via inter-frame prediction (inter-frame prediction module 2140) or current picture reference (e.g., IBC) to generate a luma reconstruction 2215 for the luma component. A cross-component model 2210 is applied to the luma reconstruction 2215 to generate a cross-component predictor 2225 for the chroma component. The cross-component predictor 2225 is contained in the predicted pixel data 2113.

[0213] Cross component model 2210 may be generated by model builder 2205 based on samples retrieved from reconstructed image buffer 2150 and / or line buffer 2127 (within and / or around and / or reference blocks), for example, when a re-exported cross component model will be used for the current block. Section I above describes several types of cross component models that may be used as cross component model 2210.

[0214] The cross-component model 2210 may also be provided by the CCM selection module 2230, which selects a cross-component model (CCM) information or other cross-component prediction (CCP) information inherited from a plurality of candidates as a merging pattern. The merging pattern used for cross-component prediction is described in Section V above.

[0215] CCM storage 2235 stores CCM information and corresponding supporting data structures. CCM storage 2235 represents (or is constituted by) any form of storage used to store CCM information, including the cross-component model generated by model builder 2205. CCM storage 2235 may store index buffers and index tables associated with different images, different image regions, or different time IDs. The stored CCM information and / or CCP information can be inherited by subsequent blocks as merge pattern candidates.

[0216] Each index table (also known as a CCM table) has a corresponding index buffer used to map locations in the image to locations in the index table. To retrieve the CCM and / or CCP information of a selected CCP merge pattern candidate, the encoder identifies the CCM table and corresponding index buffer for the selected merge candidate (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 CCM and / or CCP information in the CCM table.

[0217] CCM propagation module 2240 operates to propagate CCM information between blocks and / or images. For locations or the current block without CCM and / or CCP information, CCM propagation module 2240 may follow the BV or MV of the current block to locate the CCM / CCP information of a reference block. CCM propagation module 2240 can then propagate 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 table stored in CCM storage 2235. CCM propagation module 2240 can 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.

[0218] Figure 23A conceptual illustration shows a process 2300 for encoding non-intra-coded blocks using cross-component prediction. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing encoder 2100 execute process 2300 by executing instructions stored in a computer-readable medium. In some embodiments, an electronic device implementing encoder 2100 executes process 2300.

[0219] The encoder receives (at block 2310) data to encode pixels of the current block in the current image. The current block has a first color block and a second color block. In some embodiments, the first color block is used for the luminance component and the second color block is used for the chrominance component. In some embodiments, the first color block is used for the first chrominance component (e.g., Cb) and the second color block is used for the second chrominance component (e.g., Cr).

[0220] The encoder performs (at block 2320) non-intra-frame prediction to generate a reconstruction of the first color block based on the motion information of the current block. (Non-intra-frame prediction may refer to inter-frame prediction or current image reference, such as IBC.) The cross-component model may be inherited from a list of temporal candidates, including spatial candidates, non-nearby candidates, temporal candidates, and / or historical candidates. In some embodiments, the cross-component model may propagate from the reference block to further reference blocks located by the motion information of the reference block. The motion vector may be located in the CTU row of the co-location code-decode tree unit (CTU) row of the further reference image, or the motion vector may be cropped to be located in the co-location CTU row.

[0221] The encoder retrieves (at block 2325) a cross component model from an index table with table entries that stores one or more cross component models corresponding to different index values.

[0222] In some embodiments, locations within an image are used to look up index values ​​in an index buffer that has buffer entries storing index values ​​corresponding to different locations within the image, and these index values ​​are used to retrieve cross-component models. Index tables and index buffers are described in Section IV.h. In some embodiments, the index table stores cross-component models for all images. In some embodiments, the index table is an image-level table. In some embodiments, the index table is associated with one of a plurality of regions of an image. In some embodiments, the index table is associated with a temporal identifier layer that includes the current image. In some embodiments (e.g., for a random access configuration), no index table is created for images in the temporal identifier layer with the maximum temporal identifier. In some embodiments, all images are in the same temporal identifier layer, and all images are in a layer with the maximum temporal identifier.

[0223] In some embodiments, the index buffer entries store a default index value to indicate that no cross component model is available at the corresponding location in the image (in... Figure 14- Figure 17 In the example, the default index value is '0'. When a cross component model is deleted from the index table, each buffer entry in the index buffer that indicates the deleted cross component model is reset to the default index value, and each index value in the index buffer is decremented by one if it is greater than the index value indicating the deleted cross component model. When a cross component model is to be added to the index table at a location in an image, if the cross component model to be added is sufficiently similar to an existing cross component model already stored in the index table, the cross component model to be added is not added to the index table, and the index value used to indicate an existing cross component model is stored in the buffer entry of the index buffer corresponding to that location.

[0224] In some embodiments, the index table has a maximum size. In some embodiments, when the index table reaches its maximum size limit while storing a new cross-component model, the oldest stored cross-component model is removed from the index table to free up space for the new cross-component model. In some embodiments, when the index table reaches its maximum size limit while storing a new cross-component model, the new cross-component model is not stored in the index table. The maximum size limit may be based on whether the image is an inter-frame or intra-frame image, or based on the image's temporal identifier (e.g., the maximum size limit of the index table for images with larger time IDs is smaller than that for images with smaller time IDs), or based on the image sequence count (POC) distance between the image and the most recently previously encoded intra-frame image.

[0225] In some embodiments, when no cross-component model is available at a first position in the first index table, a cross-component model is copied from a second index table associated with a reference image (which may be located by motion information) to the first index table, or a block vector is used to locate a second position in the image, and the index value of the buffer entry for the second position is copied to the buffer entry for the first position. In some embodiments, the index table is reset when the encoder encodes a real-time decode update (IDR) or clean random access (CRA) image.

[0226] The encoder applies the cross-component model (at block 2330) to the reconstruction of the first color block to generate a prediction for the second color block. The encoder encodes (at block 2340) the current block, generating a prediction residual by using the prediction of the second color block.

[0227] VII. Example Video Decoder In some embodiments, the encoder may signal (or generate) one or more syntax elements in the bitstream, so that the decoder can parse one or more syntax elements shown in the bitstream.

[0228] Figure 24 An example video decoder 2400 implementing cross-component prediction is shown. As shown, the video decoder 2400 is an image decoder or video decoder circuit that receives a bitstream 2495 and decodes the contents of the bitstream into pixel data of video frames for display. The video decoder 2400 has multiple components or modules for decoding the bitstream 2495, including some components selected from an inverse quantization module 2411, an inverse transform module 2410, an intra-frame prediction module 2425, a motion compensation module 2430, a loop filter 2445, a decoded image buffer 2450, an MV buffer 2465, an MV prediction module 2475, and a parser 2490. The motion compensation module 2430 is part of the inter-frame prediction module 2440. The intra-frame prediction module 2425 is part of the current image prediction module 2420, which uses current image reconstruction samples as reference samples for predicting the current block.

[0229] In some embodiments, modules 2410 to 2490 are modules of software instructions executed by a computing device comprising one or more processing units (e.g., processors). In some embodiments, modules 2410 to 2490 are modules of hardware circuitry implemented by electronic devices comprising one or more ICs. Although modules 2410 to 2490 are depicted as separate modules, some modules may be combined into a single module.

[0230] Parser 2490 (or entropy decoder) receives bitstream 2495 and performs initial parsing according to the syntax defined by the video-to-code or image-to-code standard. The parsed syntax elements include various header elements, flags, and quantization data (or quantization coefficients) 2412. Parser 2490 uses entropy-based encoding / decoding techniques such as context-adaptive binary arithmetic codec (CABAC) or Huffman coding to parse the various syntax elements.

[0231] Inverse quantization module 2411 performs inverse quantization on quantized data (or quantization coefficients) 2412 to obtain transform coefficients, and inverse transform module 2410 performs inverse transform on transform coefficients 2416 to generate reconstructed residual signal 2419. Reconstructed residual signal 2419 is added to predicted pixel data 2413 from intra-frame prediction module 2425 or motion compensation module 2430 to generate decoded pixel data 2417. Decoded pixel data is filtered by loop filter 2445 and stored in decoded image buffer 2450. In some embodiments, decoded image buffer 2450 is external to video decoder 2400 storage. In some embodiments, decoded image buffer 2450 is internal to video decoder 2400 storage.

[0232] Intra-prediction module 2425 receives intra-prediction data from bitstream 2495 and, based on this, generates predicted pixel data 2413 from decoded pixel data 2417 stored in decoded image buffer 2450. In some embodiments, decoded pixel data 2417 is also stored in online buffer 2427 (or intra-prediction buffer) for intra-image prediction and spatial MV prediction.

[0233] In some embodiments, the contents of the decoded image buffer 2450 are used for display. The display device 2405 can retrieve content directly from the decoded image buffer 2450 for display, or it can retrieve 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 2450 via pixel transfer.

[0234] The motion compensation module 2430 generates predicted pixel data 2413 from the decoded pixel data 2417 stored in the decoded image buffer 2450 based on the motion compensation MV (MC MV). These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 2495 to the predicted MV received from the MV prediction module 2475.

[0235] The MV prediction module 2475 generates a predicted MV based on a reference MV generated for decoding a previous video frame, such as a motion-compensated MV for motion compensation. The MV prediction module 2475 retrieves the reference MV of the previous video frame from the MV buffer 2465. The video decoder 2400 stores the motion-compensated MV generated for decoding the current video frame in the MV buffer 2465 as a reference MV for generating the predicted MV.

[0236] Loop filter 2445 filters or smooths the decoded pixel data 2417 to reduce artifacts in the encoding and decoding process, particularly at pixel block boundaries. In some embodiments, the filtering or smoothing operations performed by loop filter 2445 include deblocking filtering (DBF), sample adaptive offset (SAO), and / or adaptive loop filtering (ALF). In some embodiments, luma-mapped chroma scaling (LMCS) is performed before the loop filter.

[0237] Figure 25 A portion of a video decoder 2400 implementing cross-component prediction for non-intra-coded blocks is shown. The luma component of the current block may be encoded via inter-frame prediction (inter-frame prediction module 2440) or current picture reference (e.g., IBC) to generate a luma reconstruction 2515 for the luma component. A cross-component model 2510 is applied to the luma reconstruction 2515 to generate a cross-component predictor 2525 for the chroma component. The cross-component predictor 2525 is included in the predicted pixel data 2413.

[0238] Cross-component model 2510 may be generated by model builder 2505 based on samples retrieved from decoded image buffer 2450 and / or line buffer 2427 (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 model 2510.

[0239] The cross-component model 2510 may also be provided by the CCM selection module 2530, which provides cross-component model (CCM) information or other cross-component prediction (CCP) information, which is a merging pattern inherited from one of the plurality of candidates. The merging pattern of the cross-component predictions is described in Section V above.

[0240] CCM storage 2535 stores CCM information and corresponding supporting data structures. CCM storage 2535 represents (or is constituted by) any form of storage used to store CCM information, including the cross-component model generated by model builder 2505. CCM storage 2535 may store an index buffer and index tables associated with different images, different image regions, or different time IDs. The stored CCM information and / or CCP information can be inherited by subsequent blocks as merge pattern candidates.

[0241] Each index table (also known as a CCM table) has a corresponding index buffer used to map locations in an image to locations in the index table. To retrieve CCM and / or CCP information for selected CCP merge pattern candidates, the decoder identifies the CCM table and corresponding index buffer for the selected merge candidate (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, in turn, is used to access the selected CCM and / or CCP information in the CCM table.

[0242] CCM propagation module 2540 operates to propagate CCM information between blocks and / or images. For a location or current block without CCM and / or CCP information, CCM propagation module 2540 may follow the BV or MV of the current block to locate the CCM / CCP information of a reference block. CCM propagation module 2540 may then propagate 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 CCM storage 2535. CCM propagation module 2540 may propagate the CCM / CCP information by copying the index value of one location in the same index buffer to another location, or by copying the CCM / CCP information from one CCM table to another.

[0243] Figure 26 A conceptual illustration of process 2600 for predicting and decoding inter-frame coded blocks using cross-components is provided. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing video decoder 2400 execute process 2600 by executing instructions stored in a readable computing medium. In some embodiments, an electronic device implementing video decoder 2400 executes process 2600.

[0244] The decoder receives (in block 2610) data to decode it into pixels of the current block in the current image. The current block has a first color block and a second color block. In some embodiments, the first color block is used for the luminance component and the second color block is used for the chrominance component. In some embodiments, the first color block is used for the first chrominance component (e.g., Cb) and the second color block is used for the second chrominance component (e.g., Cr).

[0245] The decoder performs (in block 2620) non-intra-frame prediction to generate a reconstruction of the first color block based on the motion information of the current block. (Non-intra-frame prediction may refer to inter-frame prediction or current picture reference, such as IBC.) The cross-component model may be inherited from a temporal candidate in a candidate list that includes spatial candidates, non-nearby candidates, temporal candidates, and / or historical candidates. In some embodiments, the cross-component model may be propagated to a reference block from another reference block located by the motion information of the reference block. The motion vector may be located in a position in the CTU row of another reference picture in a co-location code-decode tree unit (CTU) row, or the motion vector may be cropped to be located in a position in the co-location CTU row.

[0246] The decoder retrieves (in block 2625) the cross component model from an index table with table entries that store one or more cross component models corresponding to different index values.

[0247] In some embodiments, locations within an image are used to look up index values ​​in an index buffer with buffer entries storing index values ​​corresponding to different locations within the image, and these index values ​​are used to retrieve cross-component models. Index tables and index buffers are described in Section IV.h. In some embodiments, the index table stores cross-component models for all images. In some embodiments, the index table is an image-level table. In some embodiments, the index table is associated with one of a plurality of regions of an image. In some embodiments, the index table is associated with a temporal identifier layer that includes the current image. In some embodiments (e.g., for a random access configuration), no index table is created for images in the temporal identifier layer with the maximum temporal identifier. In some embodiments, all images are in the same temporal identifier layer, and all images are in a layer with the maximum temporal identifier.

[0248] In some embodiments, the index buffer entries store default index values ​​to indicate that no cross component model is available at the corresponding location in the image (in... Figure 14- Figure 17 In the example, the default index value is '0'. When a cross component model is deleted from the index table, each buffer entry of the index buffer having an index value indicating the deleted cross component model is reset to the default index value, and each index value in the index buffer is decremented by one if it is greater than the index value indicating the deleted cross component model. When a cross component model is to be added to the index table at a location in an image, if the cross component model to be added is sufficiently similar to an existing cross component model already stored in the index table, the cross component model to be added is not added to the index table, and an index value indicating the existing cross component model is stored in the buffer entry of the index buffer corresponding to that location.

[0249] In some embodiments, the index table has a maximum size. In some embodiments, when the index table reaches the maximum size limit while storing a new cross-component model, the oldest stored cross-component model is removed from the index table to free up space for the new cross-component model. In some embodiments, when the index table reaches the maximum size limit while storing a new cross-component model, the new cross-component model is not stored in the index table. The maximum size limit may be based on whether the image is an inter-frame or intra-frame image, or on the image's time identifier (e.g., an image with a larger time ID has a smaller maximum size limit for its index table than an image with a smaller time ID), or on the image sequence count (POC) distance between the image and the most recently encoded intra-frame image.

[0250] In some embodiments, when no cross-component model is available at the first position in the first index table, a cross-component model is copied from a second index table associated with a reference image (which may be located by the motion information) to the first index table, or a block vector is used to locate the second position in the image, and the index value of the buffer entry at the second position is copied to the buffer entry at the first position. In some embodiments, the index table is reset when the decoder is decoding a real-time decode update (IDR) or clean random access (CRA) image.

[0251] The decoder applies a cross-component model (in block 2630) to the reconstruction of the first color block to generate a prediction for the second color block. The decoder reconstructs (in block 2640) the current block using the prediction of the second color block and the corresponding prediction residuals. The decoder may then provide the reconstructed current block to be displayed as part of the reconstructed current image.

[0252] VIII. Example Electronic Systems Many of the functions and applications described above are implemented as software processes, which are designated as a set of instructions recorded on a calculator-readable storage medium (also known as a calculator-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 calculator-readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard disks, erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), etc. Calculator-readable media do not include carrier waves and electronic signals transmitted over wireless or wired connections.

[0253] In this specification, the term "software" means including firmware stored 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 independent programs. Finally, any combination of independent programs that together implement the software inventions described herein is within the scope of this disclosure. In some embodiments, a software program, when installed on one or more electronic systems and running, defines one or more specific machine implementations to execute and perform the operations of the software program.

[0254] Figure 27 An electronic system 2700 implementing certain embodiments of the present disclosure is conceptually illustrated. The electronic system 2700 may be a calculator (e.g., a desktop calculator, personal calculator, tablet calculator, etc.), a telephone, a PDA, or any other type of electronic device. Such an electronic system includes interfaces to various types of calculator-readable media and various other types of calculator-readable media. The electronic system 2700 includes a bus 2705, a processing unit 2710, a graphics processing unit (GPU) 2715, system memory 2720, a network 2725, a read-only memory 2730, a permanent storage device 2735, an input device 2740, and an output device 2745.

[0255] Bus 2705 collectively represents all system, peripheral, and chipset buses that communicate with numerous internal devices of electronic system 2700. For example, bus 2705 communicates with processing unit 2710 and GPU 2715, read-only memory 2730, system memory 2720, and permanent storage device 2735.

[0256] From these various memory units, processing unit 2710 retrieves instructions for execution and processes data to carry out 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 2715. GPU 2715 may offload various computations or supplement image processing provided by processing unit 2710.

[0257] Read-only memory (ROM) 2730 stores static data and instructions used by processing unit(s) 2710 and other modules of the electronic system. On the other hand, permanent storage device 2735 is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 2700 is 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 2735. 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 2735, system memory 2720 is a read-write memory device. However, unlike storage device 2735, system memory 2720 is volatile read-write memory, such as random access memory. System memory 2720 stores some instructions and data used by the processor during operation. In some embodiments, the processes according to this disclosure are stored in system memory 2720, permanent storage device 2735, and / or read-only memory 2730. For example, various memory units include instructions for processing multimedia clips according to certain embodiments. From these various memory units, processing units(a) 2710 retrieve instructions to execute and process data to perform processes according to certain embodiments.

[0258] Bus 2705 also connects input and output devices 2740 and 2745. Input device 2740 allows the user to communicate information and select commands with the electronic system. Input device 2740 includes an alphanumeric keypad and pointing device (also called a "cursor control device"), a camera (e.g., a webcam), a microphone, or similar device for receiving voice commands, etc. Output device 2745 displays images generated by the electronic system or otherwise outputs data. Output device 2745 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 serve as both input and output devices.

[0259] Finally, as Figure 27 As shown, bus 2705 also connects electronic system 2700 to network 2725 via network adapter (not shown). In this way, the calculator can become part of a calculator network (e.g., a local area network (“LAN”), wide area network (“WAN”), intranet, or a network of networks such as the Internet). Any or all components of electronic system 2700 can be used with this disclosure.

[0260] 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 multipurpose 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 that generated by a compiler, and files containing high-level code that are executed by a calculator, electronic component, or microprocessor using an interpreter.

[0261] While the foregoing discussion primarily concerns microprocessors or multi-core processors that execute software, many of the functions and applications described above are performed 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.

[0262] The terms “calculator,” “server,” “processor,” and “memory” as used in this specification and any claim of this application 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 “displayed” or “shown” means displayed on an electronic device. The terms “calculator-readable medium,” “machine-readable medium,” as used in this specification and any claim of this application are entirely limited to tangible, physical objects that store information in a calculator-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0263] Although this disclosure has been described with reference to numerous 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, some figures (including...) Figure 23 and Figure 26This invention conceptually illustrates a 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; 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.

[0264] The topics described herein sometimes demonstrate 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 “associated” to achieve the desired functionality. Therefore, any two components combined here to achieve a specific function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associating 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 associating 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 and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.

[0265] Furthermore, regarding any substantially plural and / or singular terms used herein, a person with technical skill may translate from plural to singular and / or from singular to plural depending on the context and / or application. Various singular / plural arrangements may be explicitly set forth herein for clarity.

[0266] Furthermore, those skilled in the art will understand that the terminology used herein, particularly in appended claims, such as the body of an appended claim, is generally considered to be “open” terms; for example, the word “comprising” should be interpreted as “comprising but not limited to,” the word “having” should be interpreted as “having at least,” and the word “includes” should be interpreted as “including but not limited to,” etc. Those skilled in the art will also further understand that if a particular number of introduced claim statements are intentional, such intention will be explicitly stated in the claims, and without such a statement, no such intention exists. 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 these phrases should not be construed as implying that any particular claim introducing a claim statement by the indefinite article “a” or “an” is limited to an implementation containing only one such statement, even if the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an,” for example, “a” and / or “an” should be interpreted as “at least one” or “one or more”; the same applies to the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of claims is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as at least the number stated. For example, simply stating "two statements" without any other modifiers implies at least two statements, or two or more statements. Additionally, when using conventions such as "at least one A, B, and C, etc.", this construction is generally intended according to conventions understood by those skilled in the art. For example, "a system having at least A, B, and C" includes, 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. Similarly, when using conventions such as "at least one A, B, or C, etc.", this construction is generally intended according to conventions understood by those skilled in the art. For example, "a system having at least A, B, or C" includes, 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. Those skilled in the art will further understand that virtually any separate word and / or phrase presenting two or more alternative terms in a description, claim, or drawing should be understood to imply the possibility of including one, any, or both terms. For example, the phrase “A or B” would be understood to include the possibility of including “A” or “B” or “A and B”.

[0267] As can be seen from the foregoing, various embodiments of this disclosure have been described herein for illustrative purposes, and various modifications may 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, characterized in that, include: The pixel of the current block of the current image, which is received as data encoded or decoded into video, is characterized in that the current block includes a first color block and a second color block; Perform non-intra-frame prediction to generate a reconstruction of the first color block based on the motion information of the current block; Retrieving cross component models from an index table having table entries storing one or more cross component models corresponding to different index values, characterized in that the position in the image is used to look up the index value in an index buffer having buffer entries storing index values ​​corresponding to different positions in the image; Apply the cross-component model to the reconstruction of the first color patch to generate a prediction of the second color patch; and The prediction of the second color block is used to encode or decode the current block.

2. The video encoding / decoding method as described in claim 1, characterized in that, The index buffer stores default index values ​​in its buffer entries to indicate that no cross component model is available at the corresponding location in the image.

3. The video encoding / decoding method as described in claim 2, characterized in that, When a cross component model is deleted from the index table, each buffer entry of the index buffer that has an index value indicating the deleted cross component model is reset to the default index value.

4. The video encoding / decoding method as described in claim 3, characterized in that, If each index value in the index buffer is greater than the index value indicating the deleted cross component model, it is reduced by one.

5. The video encoding / decoding method as described in claim 1, characterized in that, When a cross component model is to be added to the index table at a location in an image, if the cross component model to be added is sufficiently similar to an existing cross component model already stored in the index table, then the cross component model to be added is not added to the index table, and an index value indicating the existing cross component model is stored in a buffer entry of the index buffer corresponding to the location.

6. The video encoding / decoding method as described in claim 1, characterized in that, The cross-component model propagates from a further reference block to the reference block, wherein the further reference block is located using the motion information of the reference block.

7. The video encoding / decoding method as described in claim 6, characterized in that, The motion information locates the position of a further reference image in the same CTU row of the reference block, or is cropped to locate the position of the same CTU row.

8. The video encoding / decoding method as described in claim 1, characterized in that, The cross-component model is inherited from a temporal candidate in a candidate list, wherein the candidate list includes spatial candidates, non-nearby candidates, temporal candidates, or historical candidates.

9. The video encoding / decoding method as described in claim 1, characterized in that, The index table is an image-level table.

10. The video encoding / decoding method as described in claim 1, characterized in that, The index table stores the cross-component models of all images in the video.

11. The video encoding / decoding method as described in claim 1, characterized in that, The index table is associated with a time identifier layer that includes the current image.

12. The video encoding / decoding method as described in claim 1, characterized in that, The index table is associated with one of the multiple regions of the image.

13. The video encoding / decoding method as described in claim 1, characterized in that, The index table has a maximum size limit.

14. The video encoding / decoding method as described in claim 13, characterized in that, When the index table reaches the maximum size limit while storing a new cross component model, the oldest stored cross component model is deleted from the index table to free up space for the new cross component model.

15. The video encoding / decoding method as described in claim 13, characterized in that, When the index table reaches the maximum size limit while storing a new cross component model in the index table, the new cross component model is not stored in the index table.

16. The video encoding / decoding method as described in claim 13, characterized in that, The maximum size limit is determined based on whether the image is an inter-frame shot or an intra-frame shot.

17. The video encoding / decoding method as described in claim 13, characterized in that, The maximum size limit is determined based on the time identifier of the image.

18. The video encoding / decoding method as described in claim 17, characterized in that, No index table was created for the images in the time identifier layer for the maximum time identifier.

19. The video encoding / decoding method as described in claim 1, characterized in that, The maximum size limit of the index table is determined based on the picture sequence count (POC) distance between the picture and the most recently previously encoded intraframe.

20. The video encoding / decoding method as described in claim 1, characterized in that, When no cross component model is available at the first position in the first index table, a cross component model is copied from the second index table associated with the reference image to the first index table, wherein the reference image is located by the motion information.

21. The video encoding / decoding method as described in claim 1, characterized in that, When no cross component model is available at the first position in the first index table, a block vector is used to locate the second position in the image, and the index value of the buffer entry at the second position is copied to the buffer entry at the first position.

22. The video encoding / decoding method as described in claim 1, characterized in that, The index table is reset when the encoding or decoding is updated in real time or when a clean random access image is performed.

23. An electronic device, characterized in that, include: A video codec circuit is configured to perform a plurality of operations, including: receiving data to encode or decode pixels of a current block of a current image of video, wherein the current block comprises a first color block and a second color block; performing non-intra-frame prediction to generate a reconstruction of the first color block based on motion information of the current block; and retrieving cross-component models from an index table having table entries storing one or more cross-component models corresponding to different index values, wherein a position in the image is used to look up an index value in an index buffer having buffer entries storing index values ​​corresponding to different positions in the image. Apply the cross-component model to the reconstruction of the first color patch to generate a prediction of the second color patch; and The prediction of the second color block is used to encode or decode the current block.

24. A video decoding method, characterized in that, include: The pixel of the current block of the current image, which is received and decoded into video, is characterized in that the current block includes a first color block and a second color block; Perform non-intra-frame prediction to generate a reconstruction of the first color block based on the motion information of the current block; Retrieving cross component models from an index table having table entries storing one or more cross component models corresponding to different index values, characterized in that the position in the image is used to look up the index value in an index buffer having buffer entries storing index values ​​corresponding to different positions in the image; Apply the cross-component model to the reconstruction of the first color patch to generate a prediction of the second color patch; and The prediction of the second color block is used to reconstruct the current block.

25. A video encoding method, characterized in that, include: The pixel of the current block of the current image encoded as video is received, characterized in that the current block includes a first color block and a second color block; Perform non-intra-frame prediction to generate a reconstruction of the first color block based on the motion information of the current block; Retrieving cross component models from an index table having table entries storing one or more cross component models corresponding to different index values, characterized in that the position in the image is used to look up the index value in an index buffer having buffer entries storing index values ​​corresponding to different positions in the image; Apply the cross-component model to the reconstruction of the first color patch to generate a prediction of the second color patch; and The prediction of the second color block is used to encode the current block.

Images