Color component based syntax signaling and parsing

Abstract

To provide methods and devices for digital video coding, which includes matrix-based intra prediction methods for video coding.SOLUTION: A method includes generating, for a conversion between a current video block of a video comprising multiple video blocks and a bitstream representation of the video, a most probable mode (MPM) list for a matrix based intra prediction (MIP) tool based on a rule, where, the MIP tool comprises determining, during the conversion, a prediction block of the current video block by performing, on previously coded samples of the video, a boundary downsampling operation, followed by a matrix vector multiplication operation, and selectively followed by an upsampling operation, and where the rule specifies a mapping between a number of MIP modes and dimensions of the multiple video blocks; and performing the conversion based on the generating.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] Pursuant to applicable patent law and / or the rules pursuant to the Paris Convention, this application timely claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 113646, filed October 8, 2019. For all purposes under law, the entire disclosure of the aforementioned application is incorporated by reference into the disclosure of this application.

[0002] This application relates to video coding techniques, devices and systems. [Background technology]

[0003] Despite advances in video compression, digital video still accounts for the largest bandwidth usage on the Internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the demand for bandwidth for digital video usage is expected to continue to increase. Summary of the Invention

[0004] Apparatuses, systems, and methods related to digital video coding are described, particularly matrix-based intra prediction methods for video coding. The described methods may be applied to both existing video coding standards (e.g., High Efficiency Video Coding (HEVC)) and future video coding standards (e.g., Versatile Video Coding (VVC)) or codecs.

[0005] In a representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes generating a most probable mode (MPM) list for a matrix-based intra-prediction (MIP) tool based on rules for converting between a current video block of a video including a plurality of video blocks and a bitstream representation of the video, the MIP tool including, during the conversion, determining a prediction block for the current video block by performing a boundary downsampling operation, then a matrix-vector multiplication operation, and then, optionally, an upsampling operation on previously coded samples of the video, the rules specifying a mapping between a number of MIP modes and dimensions of the plurality of video blocks, and performing the conversion based on the generating.

[0006] In another exemplary aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes converting between chroma video blocks of a video and a bitstream representation of the video using side information of a secondary transform tool that is applied to the chroma video blocks based on rules, where the secondary transform tool, if applied based on the rules, includes applying a forward secondary transform during encoding to an output of a forward primary transform applied to a residual of the chroma video blocks prior to quantization, or applying an inverse secondary transform during decoding to an output of an inverse quantization of the chroma video blocks before applying an inverse primary transform, where the manner in which the side information is coded in the bitstream representation is independent of the coding mode of a corresponding luma video block.

[0007] In another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, constructing, based on the determining, at least a portion of a most probable mode (MPM) list for the ALWIP mode based on at least a portion of an MPM list for a non-ALWIP intra mode, and converting between the current video block and a bitstream representation of the current video block based on the MPM list for the ALWIP mode.

[0008] In another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes determining that a luma component of a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, estimating a chrominance intra mode based on the determining, and converting between the current video block and a bitstream representation of the current video block based on the chrominance intra mode.

[0009] In yet another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode and, based on the determination, converting between the current video block and a bitstream representation of the current video block.

[0010] In yet another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes determining that a current video block is coded using a coding mode other than an affine linear weighted intra prediction (ALWIP) mode, and converting between the current video block and a bitstream representation of the current video block based on the determination.

[0011] In yet another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes generating a first prediction for a current video block using an affine linear weighted intra prediction (ALWIP) mode, generating a second prediction based on the first prediction using position dependent intra prediction combination (PDPC), and converting between the current video block and a bitstream representation of the current video block based on the second prediction.

[0012] In yet another representative aspect, the disclosed techniques may be used to provide a method for video processing. This example method includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, predicting a plurality of sub-blocks of the current video block based on the ALWIP mode, and converting between the current video block and a bitstream representation of the current video block based on the prediction.

[0013] In yet another representative aspect, a method of video processing is disclosed that includes determining a context of a flag indicating use of an affine linear weighted intra-prediction (ALWIP) mode during conversion between the current video block and a bitstream representation of the current video block based on a rule for the current video block, predicting a plurality of sub-blocks of the current video block based on the ALWIP mode, and converting between the current video block and the bitstream representation of the current video block based on the prediction.

[0014] In yet another representative aspect, a method of video processing is disclosed that includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during a conversion between the current video block and a bitstream representation of the current video block, wherein a first precision of the samples in a first filtering stage of the at least two filtering stages differs from a second precision of the samples in a second filtering stage of the at least two filtering stages.

[0015] In yet another aspect, a method of video processing is disclosed that includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during conversion between the current video block and a bitstream representation of the current video block, the upsampling process being performed in a fixed order for both vertical and horizontal upsampling.

[0016] In yet another aspect, a method of video processing is disclosed that includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during a conversion between the current video block and a bitstream representation of the current video block, the conversion including performing a transposing operation before the upsampling process.

[0017] In yet another aspect, a method of video processing is disclosed that includes determining that a current video block satisfies a condition for converting between a current video block of a video and a bitstream representation of the video such that signaling of use of a secondary transform in the conversion is decoupled from signaling of a luma matrix-based intra-prediction (MIP) tool, and performing the conversion based on the determining.

[0018] In yet another aspect, a method of video processing is disclosed that includes determining, based on a coding condition associated with a current video block of the video, whether side information associated with a secondary transform is included in a bitstream representation of the video, and converting between the current video block and the bitstream representation based on the determining.

[0019] In yet another exemplary aspect, the above-described methods are embodied in the form of processor-executable code and stored on a computer-readable program medium.

[0020] In yet another exemplary aspect, an apparatus configured or operable to perform the above-described method is disclosed. The apparatus may include a processor programmed to implement the method.

[0021] In yet another exemplary aspect, a video decoder device may implement the methods described herein.

[0022] These and other aspects and features of the disclosed technology are described in more detail in the drawings, specification and claims. [Brief explanation of the drawings]

[0023] [Figure 1] FIG. 1 shows an example of 33 intra prediction directions. [Figure 2] FIG. 2 shows an example of the 67 intra prediction modes. [Figure 3]FIG. 3 shows an example of sample locations used for the derivation of the linear model weights. [Figure 4] FIG. 4 shows an example of four reference lines adjacent to a prediction block. [Figure 5] 5A and 5B show examples of sub-partitions according to block size. [Figure 6] FIG. 6 shows an example of ALWIP for a 4×4 block. [Figure 7] FIG. 7 shows an example of ALWIP for an 8x8 block. [Figure 8] FIG. 8 shows an example of ALWIP for an 8x4 block. [Figure 9] FIG. 9 shows an example of ALWIP for a 16×16 block. [Figure 10] FIG. 10 shows an example of neighboring blocks used in constructing an MPM list. [Figure 11] FIG. 11 shows a flowchart of an example method for matrix-based intra prediction in accordance with the disclosed technique. [Figure 12] FIG. 12 shows a flowchart of another example method for matrix-based intra prediction in accordance with the disclosed techniques. [Figure 13] FIG. 13 shows a flowchart of yet another example method for matrix-based intra prediction in accordance with the disclosed techniques. [Figure 14] FIG. 14 shows a flowchart of yet another example method for matrix-based intra prediction in accordance with the disclosed techniques. [Figure 15] FIG. 15 is a block diagram of an example hardware platform for implementing the visual media decoding or encoding techniques described herein. [Figure 16] FIG. 16 shows an example of adjacent blocks. [Figure 17] FIG. 17 is an example of the proposed reduced boundary sample generation. [Figure 18]Figure 18 shows an example of the proposed upsampling using the original reconstructed neighboring samples. [Figure 19] FIG. 19 is a block diagram illustrating an example of a video decoder. [Figure 20] FIG. 20 is a block diagram illustrating an example video processing system in which various techniques disclosed herein may be implemented. [Figure 21] FIG. 21 is a block diagram illustrating an example video coding system that may utilize the techniques of this disclosure. [Figure 22] FIG. 22 is a block diagram illustrating an example of a video encoder. [Figure 23] FIG. 23 shows an example flowchart of yet another example method for matrix-based intra prediction in accordance with the disclosed techniques. [Figure 24] FIG. 24 shows an example flowchart of yet another example method for matrix-based intra prediction in accordance with the disclosed techniques. [Figure 25] FIG. 25 shows an updated table containing the assignment of ctxInc to syntax elements with context coding bins. [Figure 26] FIG. 26 shows an updated table containing the assignment of ctxInc to syntax elements with context coding bins. [Figure 27] FIG. 27 shows an updated table for the specification of the mapping between intra-prediction modes and MIP modes. [Figure 28] FIG. 28 shows an updated table for the specification of the mapping between MIP and intra prediction modes. DETAILED DESCRIPTION OF THE INVENTION

[0024] Due to the increasing demand for higher resolution video, video coding methods and techniques have become commonplace in modern technology. Video codecs typically include electronic circuits or software that compress or decompress digital video and are constantly being improved to provide higher coding efficiency. Video codecs convert uncompressed video to a compressed format or vice versa. There is a complex relationship between video quality, the amount of data used to represent the video (determined by bitrate), the complexity of the encoding and decoding algorithms, sensitivity to data loss and errors, ease of editing, random access, and end-to-end delay (latency). Compressed formats usually comply with standard video compression standards, such as the High Efficiency Video Coding (HEVC) standard (also known as H.265 or MPEG-H Part 2), the finalized Versatile Video Coding (VVC) standard, or other current and / or future video coding standards.

[0025] Embodiments of the disclosed technology can be applied to existing video coding standards (e.g., HEVC, H.265) and future standards to improve runtime performance. Section headings are used herein to improve readability of the description, but are not intended to limit the description or embodiments (and / or implementations) to only the respective sections.

[0026] 1. A brief review of HEVC 1.1 Intra Prediction in HEVC / H.265 Intra prediction involves generating samples for a given TB (transform block) using previously reconstructed samples in the considered color channel. Intra prediction modes are signaled separately for the luma and chroma channels, and the chroma channel intra prediction mode optionally depends on the luma channel intra prediction mode via the "DM_CHROMA" mode. Although the intra prediction mode is signaled at the PB (prediction block) level, the intra prediction process is applied at the TB level according to the residual quadtree hierarchy of the CU, so that coding of one TB can affect the coding of the next TB within the CU, thereby reducing the distance to the samples used as reference values.

[0027] HEVC includes 35 intra-prediction modes: DC mode, planar mode, and 33 directional or "angular" intra-prediction modes. The 33 angular intra-prediction modes are shown in Figure 1.

[0028] For PBs associated with chroma color channels, the intra prediction mode is specified as either planar, DC, horizontal, vertical, "DM_CHROMA" mode or sometimes as diagonal mode "34".

[0029] In chroma formats 4:2:2 and 4:2:0, a chroma PB may overlap with two or four luma PBs (respectively), in which case the luma direction for DM_CHROMA is taken from the top-left of these luma PBs.

[0030] The DM_CHROMA mode indicates that the intra prediction mode of the luma color channel PB is applied to the chroma color channel PB. Since this is relatively common, the most probable mode coding scheme for intra_chroma_pred_mode is biased in favor of this mode being selected.

[0031] 2. Example of intra prediction in VVC 2.1 Intra-mode coding with 67 intra-prediction modes To capture any edge direction presented in natural video, the number of directional intra modes is expanded from 33 used in HEVC to 65. The additional directional modes are indicated as red dotted arrows in Figure 2, while the planar and DC modes remain the same. These denser directional intra prediction modes apply to all block sizes and to both luma and chroma intra prediction.

[0032] 2.2 Cross-Component Linear Model (CCLM) Example In some embodiments, to reduce cross-component redundancy, a cross-component linear model (CCLM) prediction mode (also referred to as LM) is used in JEM, where chroma samples are predicted based on the reconstructed luma samples of the same CU by using a linear model as follows: pred C (i,j)=α·rec L '(i,j)+β (1)

[0033] Here, pred C (i,j) represents the predicted chroma sample in the CU, and rec L '(i,j) represents the downsampled reconstructed luma sample of the same CU. The linear model parameters α and β are derived from the relationship between luma and chroma values ​​from two samples, which are the luma samples with the smallest and largest sample values ​​in a set of downsampled adjacent luma samples and their corresponding chroma samples. Figure 3 shows an example of the positions of the left and top samples and the samples of the current block involved in CCLM mode.

[0034] This parameter calculation is done as part of the decoding process, and not simply as an encoder search operation, and as a result, no syntax is used to communicate the values ​​of α and β to the decoder.

[0035] A total of eight intra modes are allowed for chroma intra mode coding. These modes include five traditional intra modes and three cross-component linear model modes (CCLM, LM_A, and LM_L). Chroma mode coding directly depends on the intra prediction mode of the corresponding luma block. Because separate block partitioning structures are enabled for luma and chroma components in an I slice, one chroma block may correspond to multiple luma blocks. Therefore, chroma DM mode directly inherits the intra prediction mode of the corresponding luma block that covers the center position of the current chroma block.

[0036] 2.3 Multiple Reference Line (MRL) Intra Prediction Multiple reference line (MRL) intra prediction uses more reference lines for intra prediction. Figure 4 shows an example of four reference lines, where samples from segments A and F are padded with the nearest samples from segments B and E, respectively, rather than fetched from reconstructed neighboring samples. HEVC intra picture prediction uses the nearest reference line (i.e., reference line 0). In MRL, two additional lines (reference line 1 and reference line 3) are used. The index of the selected reference line (mrl_idx) is signaled and used to generate the intra predictor. For reference line idx greater than 0, the MPM list contains only the additional reference line modes, and only the MPM index is signaled without the remaining modes.

[0037] 2.4 Intra-Subpartition (ISP) The Intra Subpartition (ISP) tool divides an intra-predicted luma block into two or four subpartitions vertically or horizontally depending on the block size. For example, the minimum block size for ISP is 4x8 (or 8x4). If the block size is larger than 4x8 (or 8x4), the corresponding block is divided into four subpartitions. Figure 5 shows two possible examples. All subpartitions meet the condition of having at least 16 samples.

[0038] For each subpartition, a reconstructed sample is obtained by adding a residual signal to a prediction signal. Here, the residual signal is generated by processes such as entropy decoding, inverse quantization, and inverse transform. Therefore, the reconstructed sample values ​​of each subpartition can be used to generate a prediction for the next subpartition, and each subpartition is processed iteratively. In addition, the first subpartition to be processed contains the top-left sample of the CU, and continues downward (horizontal division) or right (vertical division). As a result, the reference samples used to generate a subpartition prediction signal are located only on the left and top of the line. All subpartitions share the same intra mode.

[0039] 2.5 Affine Linear Weighted Intra Prediction (ALWIP or Matrix-Based Intra Prediction) Affine linear weighted intra prediction (ALWIP, also known as matrix-based intra prediction (MIP)) is proposed in JVET-N0217.

[0040] In JVET-N0217, two tests are conducted. In Test 1, ALWIP is designed with a memory limit of 8K bytes and a maximum of 4 multiplications per sample. Test 2 is similar to Test 1, but the design is further simplified in terms of memory requirements and model architecture. A single set of matrices and offset vectors for all block shapes. Reduce the number of modes to 19 for all block shapes. Reduce memory requirements to 5760 10-bit values, or 7.20 kilobytes. Linear interpolation of the predicted samples is done in a single step per direction, replacing the iterative interpolation as in the first test.

[0041] 2.5.1 Test 1 of JVET-N0217 To predict samples of a rectangular block of width W and height H, Affine Linear Weighted Intra Prediction (ALWIP) takes as input one line of H reconstructed adjacent boundary samples to the left of the block and one line of W reconstructed adjacent boundary samples above the block. If reconstructed samples are not available, they are generated as in conventional intra prediction. The generation of the prediction signal is based on the following three steps:

[0042] Of the boundary samples, four samples are extracted by averaging when W=H=4, and eight samples in all other cases.

[0043] The averaged samples are used as input for a matrix-vector multiplication followed by the addition of an offset, resulting in a reduced prediction signal for the subsampled set of samples within the original block.

[0044] The prediction signals at the remaining positions are generated from the prediction signals for the subsampled set by linear interpolation, which is a single-step linear interpolation in each direction.

[0045] The matrices and offset vectors required to generate the prediction signal are taken from three sets of matrices S0, S1, S2. Set S0 consists of 18 matrices A, each with 16 rows and 4 columns. i 0 ,i∈{0,…,17} and 18 offset vectors b, each of size 16.i 0 , i∈{0,...,17}. The matrices and offset vectors in the set are used for blocks of size 4x4. The set S1 consists of 10 matrices A, each with 16 rows and 8 columns. i 1 ,i∈{0,…,9} and 10 offset vectors b, each of size 16. i 1 , i∈{0,...,9}. The matrices and offset vectors in the set are used for blocks of size 4x8, 8x4 and 8x8. Finally, the set S2 consists of six matrices A, each with 64 rows and 8 columns. i 2 ,i∈{0,…,5} and six offset vectors b, each of size 64. i 2 , i∈{0,...,5}. The matrices and offset vectors of that set, or a subset of these matrices and offset vectors, are used for all other block shapes.

[0046] The total number of multiplications required to compute a matrix-vector product is always less than or equal to 4xWxH, meaning that in ALWIP mode, a maximum of four multiplications are required per sample.

[0047] 2.5.2 Boundary Equalization In the first step, the input boundary bdry top and bdry left is the smaller boundary (outside 1) TIFF0007803913000001.tif9127 and (outside 2) is reduced to TIFF0007803913000002.tif10127, where: (outside 1) TIFF0007803913000003.tif9127 and (outside 2) TIFF0007803913000004.tif10127 consists of two samples on each side for 4x4 blocks, and four samples on each side for all other cases.

[0048] For a 4x4 block, for 0≦i≦2, it is defined as follows:

[0049]

number

[0050] Otherwise, the block width W is W=4·2 k and for 0≦i≦2, it is defined as follows:

[0051]

number

[0052] Two reduced boundaries (outside 1) TIFF0007803913000009.tif9127 and (outside 2) TIFF0007803913000010.tif10127 is the reduced boundary vector bdry red and the boundary vector bdry red has size 4 for blocks of 4x4 shape, and size 8 for blocks of all other shapes. If mode means ALWIP mode, the concatenation is defined as follows:

[0053]

number

[0054] Finally, for large blocks, a second version of the averaging boundary is needed for the interpolation of the subsampled prediction signal: W = 8 * 2 if min(W,H) > 8 and W >= H. l and when 0≦i<8, it is defined as follows:

[0055]

number

[0056] If min(W,H)>8 and H>W, (outside 2) TIFF0007803913000013.tif10127 is defined similarly.

[0057] 2.5.3 Generating a reduced prediction signal by matrix-vector multiplication The reduced input vector bdry red From the reduced prediction signal pred red The latter signal has a width W red and height H red where W red and H red is defined as follows:

[0058]

number

[0059]

number

[0060] The reduced prediction signal pred red is calculated by calculating the matrix vector and adding an offset as follows:

[0061] pred red =A·bdry red +b where A is W red H red is a matrix with rows and 4 columns when W=H=4, and 8 columns in all other cases. b is a matrix of size W red H red is a vector of

[0062] The matrix A and vector b are taken from one of the sets S0, S1, S2 as follows: The index idx=idx(W,H) is defined as follows:

[0063]

number

[0064] Furthermore, m is as follows:

[0065]

number

[0066] And if idx≦1 or idx=2 and min(W,H)>4, then A= (Outside 3) TIFF0007803913000018.tif8127 and b= (outside 4) TIFF0007803913000019.tif6127. If idx=2 and min(W,H)=4, then A corresponds to odd x coordinates of the downsampled block when W=4, and corresponds to odd y coordinates of the downsampled block when H=4. (Outside 3) This is the matrix that results from excluding each column of TIFF0007803913000020.tif8127.

[0067] Finally, the reduced prediction signal is W=H=4 and mode≧18 max(W,H)=8 and mode≧10 max(W,H)>8 and mode≧6 is replaced by its transpose if

[0068] When W=H=4, pred red The number of multiplications required to compute W is 4 because in this case A has 4 rows and 16 columns. In all other cases A has 8 rows and W red H red In those cases, 8 W red H red We immediately check that ≤ 4 W H multiplications are required. That is, even in these cases, pred red Calculating requires up to four multiplications per sample.

[0069] 2.5.4 Explaining the Overall ALWIP Process The entire process of averaging, matrix-vector multiplication and linear interpolation is illustrated in Figures 6-9 for different shapes, where the remaining shapes are treated the same as one of the cases shown.

[0070] 1. Assuming a 4x4 block, ALWIP takes two averages along each axis of the boundary. The resulting four input samples go into a matrix-vector multiplication. The matrix is ​​taken from set S0. After adding an offset, we get 16 final predicted samples. No linear interpolation is required to generate the predicted signal. So, a total of (4 16) / (4 4) = 4 multiplications per sample are performed.

[0071] 2. Assuming an 8x8 block, ALWIP takes four averages along each axis of the boundary. The resulting 8 input samples go into a matrix-vector multiplication. The matrix is ​​taken from set S1. 16 samples are obtained at odd positions in the prediction block. So, a total of (8 16) / (8 8) = 2 multiplications per sample are performed. After adding the offset, these samples are interpolated vertically using the reduced upper boundary. Then, horizontal interpolation is performed using the original left boundary.

[0072] 3. Assuming an 8x4 block, ALWIP takes four averages along the horizontal axis of the boundary and the four original boundary values ​​at the left boundary. The resulting eight input samples go into a matrix-vector multiplication. The matrix is ​​taken from set S1. 16 samples are obtained at odd horizontal positions and at each vertical position of the predicted block. Therefore, a total of (8 16) / (8 4) = 4 multiplications are performed per sample. After adding the offset, these samples are horizontally interpolated using the original left boundary.

[0073] 4. Assuming a 16x16 block, ALWIP takes four averages along the horizontal axis of the boundary. The resulting eight input samples go into a matrix-vector multiplication. The matrix is ​​taken from set S2. 16 samples are obtained at odd positions in the prediction block. Therefore, a total of (8 64) / (16 16) = 2 multiplications per sample are performed. After adding the offset, these samples are vertically interpolated using the eight averages of the upper boundary. Then, horizontal interpolation is performed using the original left boundary. In this case, the interpolation process does not add any multiplications. Therefore, a total of two multiplications per sample are required to compute the ALWIP prediction.

[0074] For larger shapes, the procedure is essentially the same, and the number of multiplications per sample is less than four, making it easier to check.

[0075] For W×8 blocks with W>8, only horizontal interpolation is required since samples are provided at odd horizontal positions and at every vertical position.

[0076] Finally, for Wx4 blocks with W>8, let A_kbe be the matrix resulting from excluding each row corresponding to odd entries along the horizontal axis of the downsampled block, so the output size is 32, and again only horizontal interpolation is performed.

[0077] The transposed case is handled accordingly.

[0078] 2.5.5 Single-step linear interpolation For a W×H block where max(W,H)≥8, the prediction signal is generated from a prediction signal reduced for W by linear interpolation. Depending on the block shape, linear interpolation is performed vertically, horizontally, or in both directions. When linear interpolation is applied in both directions, it is first applied horizontally when W<H, and vertically first otherwise. red ×H red Without loss of generality, consider a W×H block where max(W,H)≥8 and W≥H. Then, one-dimensional linear interpolation is performed as follows. Without loss of generality, it is sufficient to describe the linear interpolation in the vertical direction. First, the reduced prediction signal is extended upward by the boundary signal. Define the vertical upsampling coefficient U

[0079] =H / H ver =H / H red Define U ver =2 uver >1. And the extended reduced prediction signal is defined as follows.

[0080]

Equation

[0081] Then, from this extended reduced prediction signal, the vertical linear interpolation prediction signal is generated as follows.

[0082]

Equation

[0083] 2.5.6 Signaling of the proposed intra prediction mode For each coding unit (CU) in intra mode, a flag is transmitted in the bitstream indicating whether the ALWIP mode applies to the corresponding prediction unit (PU). The signaling of the latter index is harmonized with the MRL as in JVET-M0043. If the ALWIP mode applies, the ALWIP mode index premode is signaled using the MPM-list of 3MPM.

[0084] Here, the MPM is derived using the intra modes of the top and left PUs as follows: Angular Three fixed tables assigned to map_angular_to_ALWIP idx (idx∈{0,1,2}).

[0085] premode ALWIP =map_angular_to_ALWIP idx [premode Angular ] For each PU of width W and height H, an index idx(PU) = idx(W,H) ∈ {0,1,2} is defined that indicates from which of the three sets the ALWIP parameters should be taken as in section 2.5.3.

[0086] Prediction Unit PU above is available, belongs to the same CTU as the current PU, is in intra mode, and idx(PU) = idx(PU above ) and ALWIP is in ALWIP mode (outside 5) TIFF0007803913000023.tif8127 PU above When applied to , it becomes:

[0087]

number

[0088] The upper prediction unit PU is available, belongs to the same CTU as the current PU, is in intra mode, and the upper PU is in conventional intra prediction mode. (outside 6) When TIFF0007803913000025.tif8127 is applied, it will look like this:

[0089]

number

[0090] In all other cases it is as follows:

number

[0091] This means that this mode is not available. The method is the same but without the constraint that the left PU must belong to the same CTU as the current PU. (outside 7) TIFF0007803913000028.tif9127 is derived.

[0092] Finally, three fixed default lists: idx (idx∈{0,1,2}) are provided, each containing three different ALWIP modes. idx(PU) and mode (outside 5) TIFF0007803913000029.tif8127 and (outside 7) Construct three different MPMs by substituting -1 for the default value and excluding repeats from TIFF0007803913000030.tif9127.

[0093] The left and top neighboring blocks used in ALWIP's MPM list construction are A1 and B1 as shown in FIG.

[0094] 2.5.7 Adaptive MPM List Derivation for Conventional Luma and Chroma Intra Prediction Modes The proposed ALWIP mode is harmonized with the MPM-based coding of conventional intra prediction modes as follows: The derivation process of luma and chroma MPM lists for conventional intra prediction modes is performed using a fixed table, map_ALWIP_to_angular idx (idx∈{0,1,2}) and the ALWIP mode premode of a given PU ALWIP to one of the conventional intra prediction modes. premode Angular =map_ALWIP_to_angular idx(PU) [premode ALWIP ]

[0095] In the derivation of the Luma MPM list, the ALWIP mode premode ALWIP When a neighboring luma block using the conventional intra prediction mode premode is encountered, this block is Angular In deriving the chroma MPM list, whenever the current luma block uses LWIP mode, the same mapping is used to convert ALWIP mode to traditional intra prediction mode.

[0096] 2.5.8 Corresponding revised work draft In some embodiments, the portions relating to intra_lwip_flag, intra_lwip_mpm_flag, intra_lwip_mpm_idx, and intra_lwip_mpm_remainder as described in this section have been added to the working draft based on embodiments of the disclosed technology.

[0097] In some embodiments, a working draft may be used to indicate additions and modifications made to the working draft based on embodiments of the disclosed technology, as described in this section. <begin>and <end>Tags are used.

[0098] Syntax Table Coding Unit Syntax

[0099] [Table 1] TIFF0007803913000032.tif249166TIFF0007803913000033.tif66167

[0100] Semantics <begin>intra_lwip_flag[x0][y0]=1 specifies that the type of intra prediction for the luma sample is affine linear weighted intra prediction. intra_lwip_flag[x0][y0]=0 specifies that the type of intra prediction for the luma sample is not affine linear weighted intra prediction. If intra_lwip_flag[x0][y0] is not present, it is inferred to be equal to 0. The syntax elements intra_lwip_mpm_flag[x0][y0], intra_lwip_mpm_idx[x0][y0], and intra_lwip_mpm_remainder[x0][y0] specify the affine linear weighted intra prediction mode for the luma sample. The array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. If intra_lwip_mpm_flag[x0][y0]=1, the affine linear weighted intra prediction mode is inferred from neighboring intra-prediction coding units according to Section 8.4.X. If intra_lwip_mpm_flag[x0][y0] is not present, it is inferred to be equal to 1. <end> intra_subpartitions_split_flag[x0][y0] specifies whether the type of intra subpartition split is horizontal or vertical. If intra_subpartitions_split_flag[x0][y0] is not present, it is inferred as follows: - If intra_lwip_flag[x0][y0]=1, then intra_subpartitions_split_flag[x0][y0] is inferred to be equal to 0. - Otherwise, the following applies: - If cbHeight is greater than MaxTbSizeY, intra_subpartitions_split_flag[x0][y0] is inferred to be equal to 0. - Otherwise (cbWidth is greater than MaxTbSizeY), intra_subpartitions_split_flag[x0][y0] is inferred to be equal to 1.

[0101] Decoding Process 8.4.1 General Decoding Process for Coding Units Coded in Intra-Prediction Mode The inputs to this process are: a luma position (xCb, yCb) specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, a variable treeType that specifies whether a single or dual tree is being used, and if a dual tree is being used, whether the current tree corresponds to the luma or chroma component; is. The output of this process is a modified reconstructed picture before in-loop filtering. The quantization parameter derivation process specified in Section 8.7.1 is called with the luma position (xCb, yCb), the width of the current coding block in luma samples, cbWidth, the height of the current coding block in luma samples, cbHeight, and the variable treeType as input. If treeType is equal to SINGLE_TREE or treeType is equal to DUAL_TREE_LUMA, the decoding process for luma samples is specified as follows: If pcm_flag "xCb" "yCb" = 1, the reconstructed picture is modified as follows:

[0102]

number

[0103] Otherwise, the following applies: 1. The luma intra prediction mode is derived as follows: If -intra_lwip_flag[xCb][yCb]=1, the affine linear weighted intra prediction mode derivation process specified in Section 8.4.X is invoked with the luma position (xCb, yCb), the width of the current coding block in luma samples, cbWidth, and the height of the current coding block in luma samples, cbHeight, as input. Otherwise, the luma intra prediction mode derivation process specified in Section 8.4.2 is called with the luma position (xCb, yCb), the width of the current coding block in luma samples, cbWidth, and the height of the current coding block in luma samples, cbHeight, as input. 2. The general decoding process for intra blocks specified in Section 8.4.4.1 is called with inputs luma position (xCb, yCb), tree type treeType, variable nTbW set equal to cbWidth, variable nTbH set equal to cbHeight, variable predModeintra set equal to IntraPredModeY[xCb][yCb], variable cldx set equal to 0, and the output is the modified reconstructed picture before in-loop filtering. ... <begin>

[0104] 8.4.X Affine Linear Weighted Intra Prediction Mode Derivation Process The inputs to this process are: a luma position (xCb, yCb) specifying the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, is. In this process, an affine linear weighted intra prediction mode IntraPredModeY[xCb][yCb] is derived. IntraPredModeY[xCb][yCb] is derived by the following steps in order: 1. The neighboring positions (xNbA, yNbA) and (xNbB, yNbB) are set equal to (xCb-1, yCb) and (xCb, yCb-1), respectively. 2. For X to be replaced by either A or B, the variable candLwipModeX is derived as follows: The Block Availability Derivation Process [Ed.(BB): Neighbor Block Availability Check Process tbd] specified in Section 6.4.X is invoked with inputs location (xCurr, yCurr) set equal to (xCb, yCb) and neighboring location (xNbY, yNbY) set equal to (xNbX, yNbX), and the output is assigned to avalableX. Affine linear weighted intra prediction mode candidate candLwipModeX is derived as follows. -candLwipModeX=-1 if one or more of the following conditions are true: - If variable availableX=FALSE. -When -CuPredMode[xNbX][yNbX] is not equal to MODE_INTRA and mh_intra_flag[xNbX][yNbX] is not equal to 1. -When pcm_flag[xNbX][yNbX] = 1. -When X = B and yCb-1 is less than ((yCb >> CtbLog2SizeY) << CtbLog2SizeY). -Otherwise, the following applies. -The block size type derivation process defined in Clause 8.4.X.1 is called with the width cbWidth of the current coding block in the luma sample and the height cbHeight of the current coding block in the luma sample as inputs, and the output is assigned to the variable sizeId. -When intra_lwip_flag[xNbX][yNbX] = 1, the block size type derivation process defined in Clause 8.4.X.1 is called with the width nbWidthX of the adjacent coding block in the luma sample and the height nbHeightX of the adjacent coding block in the luma sample as inputs, and the output is assigned to the variable sizeIdX. -When sizeId = sizeIdX, candLwipModeX is set to IntraPredModeY[xNbX][yNbX]. Otherwise, candLwipModeX is set to -1. -Otherwise, candLwipModeX is derived using IntraPredModeY[xNbX][yNbX] and the sizeId defined in Table 8-X1. 3. candLwipModeList[x] (x = 0..2) is derived as follows using lwipMPMCand[sizeId] defined in Table 8-X2. -When both candLwipModeA and candLwipModeB are = -1, the following applies. candLwipModeList[0] = lwipMpmCand[sizeId][0] (8-X1) candLwipModeList[1]=lwipMpmCand[sizeId][1] (8-X2) candLwipModeList[2]=lwipMpmCand[sizeId][2] (8-X3) - Otherwise, the following applies: If -candLwipModeA=candLwipModeB or if either candLwipModeA or candLwipModeB = -1, the following applies: candLwipModeList[0]=(candLwipModeA!=-1)?candLwipModeA:candLwipModeB (8-X4) If -candLwipModeList[0]=lwipMpmCand[sizeId][0], the following applies: candLwipModeList[1]=lwipMpmCand[sizeId][1] (8-X5) candLwipModeList[2]=lwipMpmCand[sizeId][2] (8-X6) - Otherwise, the following applies: candLwipModeList[1]=lwipMpmCand[sizeId][0] (8-X7) candLwipModeList[2]=(candLwipMode[0]!=lwipMpmCand[sizeId][1])?lwipMpmCand[sizeId][1]:lwipMpmCand[sizeId][2] (8-X8) - Otherwise, the following applies: candLwipModeList[0]=candLwipModeA (8-X9) candLwipModeList "0" = candLwipModeB (8-X10) -If both candLwipModeA and candLwipModeB are not equal to lwipMpmCand[sizeId][0], the following applies: candLwipModeList[2]=lwipMpmCand[sizeId][0] (8-X11) - Otherwise, the following applies: -If both candLwipModeA and candLwipModeB are not equal to lwipMpmCand[sizeId][1], the following applies: candLwipModeList[2]=lwipMpmCand[sizeId][1] (8-X12) - Otherwise, the following applies: candLwipModeList[2]=lwipMpmCand[sizeId][2] (8-X13) 4. IntraPredModeY[xCb][yCb] is derived by applying the following procedure: -If intra_lwip_mpm_flag[xCb][yCb]=1, IntraPredModeY[xCb][yCb]=candLwipModeList[intra_lwip_mpm_idx[xCb][yCb]] is set. Otherwise, IntraPredModeY[xCb][yCb] is derived by applying the following steps in order: 1. If candLwipModeList[i] is greater than candLwipModeList[j] (i=0..1 and for each i, j=(i+1)..2), both values ​​are swapped as follows: (candLwipModeList[i],candLwipModeList[j])=Swap(candLwipModeList[i],candLwipModeList[j]) (8-X14) 2. IntraPredModeY[xCb][yCb] is derived by the following steps in order: i. IntraPredModeY[xCb][yCb] is set to intra_lwip_mpm_remainder[xCb][yCb]. ii. When i=0 to 2, if IntraPredModeY[xCb][yCb] is equal to or greater than candLwipModeList[i], the value of IntraPredModeY[xCb][yCb] is incremented by 1. The variable IntraPredModeY[x][y] (x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1) is set equal to IntraPredModeY[xCb][yCb].

[0105] 8.4.X.1 Prediction Block Size Type Derivation Process The inputs to this process are: - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, is. The output of this process is the variable sizeId. The variable sizeId is derived as follows: - If both cbWidth and cbHeight are =4, then sizeId is set to =0. - Else, if both cbWidth and cbHeight are less than or equal to 8, set sizeId=1. - Otherwise, sizeId is set to =2.

[0106] [Table 2] TIFF0007803913000036.tif123127 Table 8-X1: Specification of the mapping between intra prediction and affine linear weighted intra prediction modes

[0107] [Table 3] Table 8-X2: Affine linear weighted intra prediction candidate mode specifications <end>

[0108] 8.4.2. Luma Intra Prediction Mode Derivation Process The inputs to this process are: a luma position (xCb, yCb) specifying the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - The variable cbHeight specifies the height of the current coding block in luma samples. In this process, the luma intra prediction mode IntraPredModeY[xCb][yCb] is derived. Table 8-1 defines the values ​​and associated names of the intra prediction modes IntraPredModeY[xCb][yCb].

[0109] [Table 4]

[0110] IntraPredModeY[xCb][yCb] is derived by the following steps in order: 1. The neighbor positions (xNbA, yNbA) and (xNbB, yNbB) are set equal to (xCb-1, yCb+cbHeight-1) and (xCb+cbWidth-1, yCb-1), respectively. 2. For X to be replaced by either A or B, the variable candIntraPredModeX is derived as follows: -section <begin>6.4.X "Ed.(BB): Adjacent Block Availability Check Process tbd" <end>The availability derivation process of the block defined by is called with the position (xCurr, yCur) set equal to (xCb, yCb) and the adjacent position (xNbY, yNbY) set equal to (xNbY, yNbY) as inputs, and the output is assigned to availableX. - The intra prediction candidate mode candIntraPredModeX is derived as follows. If one or more of the following conditions are met, candIntraPredModeX is set to INTRA_PLANAR: - When the variable availableX = FALSE. - When CuPredMode[xNbX][yNbX] is not equal to MODE_INTRA and clip_flag[xNbX][yNbX] is not equal to 1. - When pcm_flag[xNbX][yNbX] = 1. - When X = B and yCb - 1 is less than ((yCb >> CtbLog2SizeY) << CtbLog2SizeY). Otherwise, candIntraPredModeX is derived as follows. - When intra_lwip_flag[xCb][yCb] = 1, candIntraPredModeX is derived by the following steps in order. i. The block size type derivation process defined in Section 8.4.X.1 is called with the width cbWidth of the current coding block in the luma sample and the height cbHeight of the current coding block in the luma sample as inputs, and the output is assigned to the variable sizeId. ii. candIntraPredModeX is derived using IntraPredModeY[xNbX][yNbX] and sizeId defined in Table 8-X3. - Otherwise, candIntraPredModeX is set to IntraPredModeY[xNbX][yNbX]. 3. The variables ispDefaultMode1 and ispDefaultMode2 are defined as follows: -If IntraSubPartitionsSplitType=ISP_HOR_SPLIT, ispDefaultMode1=INTRA_ANGULAR18 and ispDefaultMode2=INTRA_ANGULAR5. Otherwise, set ispDefaultMode1=INTRA_ANGULAR50 and ispDefaultMode2=INTRA_ANGULAR63. ...

[0111] [Table 5] TIFF0007803913000040.tif248127TIFF0007803913000041.tif104127Table 8-X3: Specification of the mapping between affine linear weighted intra prediction modes and intra prediction modes

[0112] 8.4.3 Chrominance Intra Prediction Mode Derivation Process The inputs to this process are: a luma position (xCb, yCb) that specifies the top-left sample of the current chroma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - The variable cbHeight specifies the height of the current coding block in luma samples. In this process, the intra-chroma prediction mode IntraPredModeC[xCb][yCb] is derived. The corresponding luma intra prediction mode lumaIntraPredMode is derived as follows: When -intra_lwip_flag[xCb][yCb]=1, lumaIntraPredMode is derived by the following steps in order: i. The block size type derivation process specified in Section 8.4.X.1 is called with the width of the current coding block in luma samples, cbWidth, and the height of the current coding block in luma samples, cbHeight, as input, and the output is assigned to the variable sizeId. ii. The luma intra prediction mode is derived using IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2] and sizeId specified in Table 8-X3, and the value of candIntraPredModeX is assigned to lumaIntraPredMode. - Otherwise, set lumaIntraPredMode=IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2]. The intra-chroma prediction mode IntraPredModeC[xCb][yCb] is the intra_croma_pred_mode[xCb][yCb] specified in Table 8-2 and Table 8-3. and lumaIntraPredMode. ...

[0113] xxx. Intra-sample prediction <begin> The inputs to this process are: a sample position (xTbCmp, yTbCmp) that specifies the top-left sample of the current transform block relative to the top-left luma sample of the current picture; a variable predModeIntra that specifies the intra prediction mode; - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, a variable nCbW specifying the coding block width, a variable nCbH specifying the coding block height; - a variable cIdx that specifies the color component of the current block; The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1). The predicted samples predSamples[x][y] are derived as follows: - If intra_lwip_flag[xTbCmp][yTbCmp]=1 and cIdx=0, the affine linear weighted intra sample prediction process specified in Section 8.4.4.2.X1 is called with the position (xTbCmp, yTbCmp), the intra prediction mode predModeIntra, the transform block width nTbW and the transform block height nTbH as input, and the output is predSamples. Otherwise, the general intra sample prediction process specified in clause 8.4.4.2.X1 is called with the position (xTbCmp, yTbCmp), the intra prediction mode predModeIntra, the transform block width nTbW and transform block height nTbH, the coding block width nCbW and coding block height nCbH and the variable CIdx as inputs, and the output is predSamples.

[0114] 8.4.4.2.X1 Affine Linear Weighted Intra-Sample Prediction The inputs to this process are: a sample position (xTbCmp, yTbCmp) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture; a variable predModeIntra that specifies the intra prediction mode; - a variable nTbW that specifies the transform block width, - A variable nTbH that specifies the transform block height. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1). The block size type derivation process specified in Section 8.4.X.1 is called with the transform block width nTbW and transform block height nTbH as input, and the output is assigned to the variable sizeId. The variables numMode, boundarySize, predW, predH, and predC are derived using the sizeId specified in Table 8-X4.

[0115] [Table 6] Table 8-X4: Number of modes, boundary sample size and prediction size specifications according to sizeId

[0116] The flag isTransposed is derived as follows: isTransposed=(predModeIntra>(numModes / 2))?1:0 (8-X15) The flags needUpsBdryHor and needUpsBdryVer are derived as follows: needUpsBdryHor=(nTbW>predW)?TRUE:FALSE(8-X16) needUpsBdryHor=(nTbH>predH)?TRUE:FALSE(8-X17) The variables upsBdryW and upsBdryH are derived as follows: upsBdryW=(nTbH>nTbW)?nTbW:predW (8-X18) upsBdryH=(nTbH>nTbW)?predH:nTbH (8-X19) The variables lwipW and lwipH are derived as follows: lwipW=(isTransposed= =1)?predH:predW (8-X20) lwipH=(isTransposed= =1)?predW:predH (8-X21) To generate the reference samples refT[x] (x=0..nTbW-1) and refL[y] (y=0..nTbH-1), the reference sample derivation process specified in Section 8.4.4.2.X2 is called with the position (xTbCmp, yTbCmp), the transform block width nTbW, and the transform block height nTbH as inputs, and the top-left refT[x] (x=0..nTbW-1) and refL[y] (y=0..nTbH-1) as outputs. For generation of boundary samples p[x] (x=0..2*boundarySize-1), the following applies: - For the upper reference sample, the boundary reduction process specified in clause 8.4.4.2.X3 is called with the block size nTbW, the reference sample refT, the boundary size boundarySize, the upsampling boundary flag needUpsBdryVer and the upsampling boundary size upsBdryW as inputs, and with the upsampling boundary samples upBdryT[x] (x = 0..boundrySize-1) and the reduced boundary samples redT[x] (x = 0..upsBdryW-1) as outputs. - For the left reference sample, the boundary reduction process specified in clause 8.4.4.2.X3 is called with the block size nTbW, the reference sample refL, the boundary size boundarySize, the upsampling boundary flag needUpsBdryVer and the upsampling boundary size upsBdryW as inputs, and with the reduced boundary samples redL[x] (x = 0..boundarySize-1) and the upsampling boundary samples upBdryT[x] (x = 0..upsBdryW-1) as outputs. The reduced upper boundary samples redT and reduced left boundary samples redL are assigned to the boundary sample array p as follows: If isTransposed=1, set p[x]=redL[x](x=0..boundarySize-1) and set p[x+boundarySize]=redT[x](x=0..boundarySize-1). Otherwise, set p[x] = redT[x] (x=0..boundarySize-1) and set p[x+boundarySize] = redL[x] (x=0..boundarySize-1). In the intra sample prediction process according to predModeIntra, the following steps are applied in order: 1. Affine linear weighted sample predLwip[x][y] (x=0..lwipW-1, y=0..lwipH-1) is derived as follows: The variable modeId is derived as follows: modeId=predModeIntra-(isTransposed= =1)?(numModes / 2):0 (8-X21) -The weight matrix mWeight[x][y] (x=0..2*boundarySize-1, y=0..predC*predC-1) is shown in Table 8-XX[TBD: Additional weight matrix] using the specified sizeId and modeId. - The bias vector vBias[y] (y=0..predC*predC-1) is defined in Table 8-XX[TBD: Additional weight matrix] using the specified sizeId and modelId. The variable sW is derived using the sizeId and modelId specified in Table 8-X5. -The affine linear weighted sample predLwip[x][y] (x=0..lwipW-1, y=0..lwipH-1) is derived as follows: oW=1<<(sW-1) (8-X23) sB=BitDepth Y -1 (8-X24) incW=(predC>lwipW)?2:1 (8-X25) incH=(predC>lwipH)?2:1 (8-X26)

[0117]

number

[0118] The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: If -isTransposed=1, predLwip[x][y](x=0..nTbW-1,y=0..nTbH-1)=predLwip[y][x] is set. If -needUpsBdryVer=TRUE or needUpsBdryHor=TRUE, the predictive upsampling process specified in Section 8.4.4.2.X4 is called with inputs the input block width preW, input block height predH, affine linear weighted samples predLwip, transform block width nTbW, transform block height nTbH, upsampling boundary width upsBdryW, upsampling boundary height upsBdryH, upper upsampling boundary samples upsBdryT, and left upsampling boundary samples upsBdryL, and the output is the predicted sample array predSamples. - Otherwise, set predSamples[x][y](x=0..nTbW-1,y=0..nTbH-1) = predLwip[x][y].

[0119] [Table 7] Table 8-X5: Weight shift specifications according to sizeId and modeId

[0120] 8.4.4.2.X2 Reference Sample Derivation Process The inputs to this process are: a sample position (xTbY, yTbY) that specifies the top-left luma sample of the current transform block relative to the top-left luma sample of the current picture; - a variable nTbW that specifies the transform block width, - A variable nTbH that specifies the transform block height. The output of this process is the upper reference samples refT[x] (x=0..nTbW-1) and the left reference samples refL[y] (y=0..nTbH-1). The adjacent samples refT[x] (x=0..nTbW-1) and samples refL[y] (y=0..nTbH-1) are samples constructed before the in-loop filter process and are derived as follows: The top neighbor luma position (xNbT, yNbT) and the left neighbor luma position (xNbL, yNbL) are specified as follows: (xNbT,yNbT)=(xTbY+x,yTbY-1) (8-X28) (xNbL,yNbL)=(xTbY-1,yTbY+y) (8-X29) The block availability derivation process [Ed.(BB): Neighboring Block Availability Check Process tbd] specified in Section 6.4.X is called with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY) and the upper neighbor luma position (xNbT, yNbT) as input, and the output is assigned to avalTop[x] (x=0..nTbW-1). - The block availability derivation process [Ed.(BB): Neighboring Block Availability Check Process tbd] specified in Section 6.4.X is called with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY) and the left neighbor luma position (xNbT, yNbT) as input, and the output is assigned to avalLeft[x] (y=0..nTbH-1). The upper reference sample refT[x] (x=0..nTbW-1) is derived as follows: - If all avalTop[x](x=0..nTbW-1)=TRUE, the sample at position (xNbT, yNbT) is assigned to refT[x](x=0..nTbW-1). - Otherwise, if availTop[0]=FALSE, then all refT[x](x=0..nTbW-1) are 1<<(BitDepth Y -1). Otherwise, the reference sample refT[x] (x=0.nTbW−1) is derived by the following steps in order: 1. The variable lastT is set equal to the position x of the first element in the sequence availTop[x] (x=1..nTbW-1) that is equal to FALSE. 2. For each x=0..lastT-1, the sample at position (xNbT, yNbT) is assigned to refT[x]. 3. For each x=lastT..ntbW-1, set refT[x]=refT[lastT-1]. The left reference sample refL[y] (x=0..nTbH-1) is derived as follows: - If all avalLeft[y](y=0..nTbH-1)=TRUE, the sample at position (xNbT, yNbT) is assigned to refL[y](y=0..nTbH-1). - Otherwise, if availLeft[0]=FALSE, then all refL[y](y=0..nTbH-1) are 1<<(BitDepth Y -1). Otherwise, the reference sample refL[y] (y=0.nTbH−1) is derived by the following steps in order: 1. The variable lastL is set equal to the position y of the first element in the sequence availLeft[y] (y=1..nTbH-1) that is equal to FALSE. 2. For each y=0..lastL-1, the sample at position (xNbT, yNbT) is assigned to refL[y]. 3. For each y=lastL..ntbH-1, set refL[y]=refL[lastL-1].

[0121] Specification of the boundary reduction process The inputs to this process are: a sample position (xTbY, yTbY) that specifies the top-left luma sample of the current transform block relative to the top-left luma sample of the current picture; - a variable nTbX that specifies the transformation block size, - Reference sample refX[x] (x=0..nTbX-1) and - A variable boundarySize that specifies the downsampling boundary size, - a flag needUpsbdryX that specifies whether intermediate boundary samples are needed for upsampling, and - The variables UpsbdrySize and UpsbdrySize specify the boundary size for upsampling. The output of this process is the reduced boundary samples redX[x] (x=0..boundarySize-1) and the upsampled boundary samples upBdryX[x] (x=0..upsBdrySize-1). The upsampling boundary samples upBdryX[x] (x=0..upsBdrySize-1) are derived as follows. If -needUpsBdryX=TRUE and upsBdrySize is smaller than nTbX, the following applies: uDwn=nTbX / upsBdrySize (8-X28)

[0122]

number

[0123] - Otherwise (upsBdrySize=nTbX), set upBdryX[x]=refX[x]. The reduced boundary samples redX[x] (x=0..boundarySize-1) are derived as follows: If -boundarySize is smaller than upsBdrySize, the following applies: uDwn=nTbX / upsBdrySize (8-X28) bDwn=upsBdrySize / boundarySize (8-X32)

[0124]

number

[0125] - Otherwise, (boundarySize=upsBdrySize), set redX[x]=upBdryX[x].

[0126] 8.4.4.2.X4 Specification of the predictive upsampling process The inputs to this process are: - a variable predW that specifies the input block width, - a variable predH that specifies the input block height, - Affine linear weighted sample predLwip[x][y](x=0..predW-1,y=0..predH-1) and - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, - A variable upsBdryW that specifies the upsampling boundary width, - A variable upsBdryH that specifies the upsampling boundary height, - the upper upsampling boundary sample upsBdryT[x] (x=0..upsBdryW-1), - The left upsampling boundary sample upsBdryL[x] (x=0..upsBdryH-1). The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, x=0..nTbF-1). The sparse prediction samples predSamples[m][n] and predLwip[x][y] (x=0..predW-1, y=0..predH-1) are derived as follows: upHor=nTbW / predW (8-X34) upVer=nTbH / predH (8-X35) predSamples[(x+1)*upHor-1][(y+1)*upVer-1]=predLwip[x][y] (8-X36) The upper boundary samples upsBdryT[x] (x=0..upsBdryW-1) are assigned to predSamples[m][-1] as follows: predSamples[(x+1)*(nTbW / upsBdryW)-1][-1]=upsBdryT[x] (8-X37) The left boundary samples upsBdryL[y] (y=0..upsBdryH-1) are assigned to predSamples[-1][n] as follows: predSamples[-1][(y+1)*(nTbH / upsBdryH)-1]=upsBdryL[y] (8-X38) The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: If nTbH is greater than nTbW, the following steps are applied: 1. If upHor is greater than 1, then all sparse positions (xHor, yHor) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=1..predH) are applied to dX=1..upHor-1 as follows: predSamples[xHor+dX”[yHor]=((upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor]) / upHor (8-X39) 2. For every sparse position (xVer, yVer) = (m, n*upVer-1), where M = 0..nTbW-1, n = 0..predH-1, vertical sampling is applied with dY = 1..upVer-1 as follows: predSamples[xVer][yVer+dY]=((upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer]) / upVer (8-X40) Otherwise, the following steps are applied in order: 1. If upVer is greater than 1, vertical sampling is applied with dY=1..upVer-1 for all sparse positions (xVer, yVer)=(m*upHor-1, n*upVer-1), where m=1..predW, n=0..predH-1, as specified in (8-X40). 2. Horizontal sampling is applied for all sparse locations (xHor, yHor) = (m*upHor-1, n), where m = 0..predW-1, n = 0..nTbH-1, with dX = 1..upHor-1 as specified in (8-X39). <end>

[0127] [Table 8] Table 9-9: Syntax elements and associated thresholding

[0128] [Table 9] Table 9-15: Assignment of ctxInc to syntax elements using context-coded bins

[0129] [Table 10] Table 9-16: ctxInc specification using left and top context elements <end>

[0130] Overview of ALWIP To predict samples of a rectangular block of width W and height H, affine linear weighted intra prediction (ALWIP) takes as input one line of H reconstructed adjacent boundary samples on the left side of the block and one line of W reconstructed adjacent boundary samples on the top side of the block. If reconstructed samples are not available, they are generated similarly to conventional intra prediction. ALWIP applies only to luma intra blocks. For chroma intra blocks, conventional intra coding modes are applied.

[0131] The generation of the prediction signal is based on the following three steps: 1. Among the boundary samples, four samples are extracted by averaging when W=H=4, and eight samples in all other cases. 2. The averaged samples are taken as input and subjected to a matrix-vector multiplication followed by the addition of an offset, resulting in a downscaled prediction signal for the subsampled set of samples within the original block. 3. Predicted signals at the remaining positions are generated from the predicted signals for the subsampled set by linear interpolation, which is a single-step linear interpolation in each direction.

[0132] When the ALWIP mode is applied, the index premode of the ALWIP mode is signaled using the MPM list of 3MPMS, where the MPM is derived using the intra modes of the top and left PUs as follows: Angular Three fixed tables that assign ALWIP mode to map_angular_to_ALWIP idx (idx∈{0,1,2}).

[0133] premode ALWIP =map_angular_to_ALWIP idx [premode Angular ] For each PU of width W and height H, an index idx(PU)=idx(W,H)∈{0,1,2} is defined that indicates from which of the three sets the ALWIP parameters should be taken.

[0134] Upper prediction unit PU above is available, belongs to the same CTU as the current PU, is in intra mode, and idx(PU) = idx(PU above ) and ALWIP is in ALWIP mode (outside 5) TIFF0007803913000050.tif8127 PU above When applied to , it becomes:

[0135]

number

[0136] The upper PU is available, belongs to the same CTU as the current PU, is in intra mode, and the upper PU is in conventional intra prediction mode. (outside 6) When TIFF0007803913000052.tif8127 is applied, it will look like this:

[0137]

number

[0138] In all other cases it is as follows:

[0139]

number

[0140] This means that this mode is not available. The method is the same but without the constraint that the left PU must belong to the same CTU as the current PU. (outside 7) TIFF0007803913000055.tif9127 is derived.

[0141] Finally, three fixed default lists: idx (idx∈{0,1,2}) are provided, each containing three different ALWIP modes. idx(PU) and mode (outside 5) TIFF0007803913000056.tif8127 and (outside 7) Construct three different MPMs by substituting -1 for the default value and excluding repeats from TIFF0007803913000057.tif9127.

[0142] For luma MPM list derivation, ALWIP mode premode ALWIP Whenever a neighboring luma block using the conventional intra prediction mode premode is encountered, this block is Angular is treated as using

[0143] premode Angular =map_ALWIP_to_angular idx(PU) [premode ALWIP ]

[0144] 33 Conversion in VVC 3.1 Multiple Transform Selection (MTS) In addition to the DCT-II used in HEVC, the Multiple Transform Selection (MTS) scheme is used for residual coding of both inter- and intra-coded blocks. It uses multiple selection transforms from DCT8 / DST7. The newly introduced transform matrices are DST-VII and DCT-VIII.

[0145] 3.2 Reduced Quadratic Transform (RST) proposed in JVET-N0193 The reduced quadratic transform (RST) applies 16x16 and 16x64 non-separable transforms to 4x4 and 8x8 blocks, respectively. The linear forward and inverse transforms are still performed in the same manner as the two 1-D horizontal / vertical transform passes. The secondary forward and inverse transforms are separate process steps from the linear transform. For the encoder, the linear forward transform is performed first, followed by the secondary forward transform and quantization, and CABAC bit encoding. For the decoder, CABAC bit decoding and inverse quantization are performed, then the secondary inverse transform is performed first, followed by the linear inverse transform. The RST is only applied to intra-coded TUs, both intra-slice and inter-slice.

[0146] 3.3 Unified MPM List for Intra-mode Coding in JVET-N0185 A unified 6-MPM list for intra blocks is proposed, regardless of whether multiple reference line (MRL) and intra subpartition (ISP) coding tools are applied. The MPM list is constructed based on the intra modes of the left and upper neighboring blocks, as in VTM4.0. Assuming that the mode of the left side is denoted as Left and the mode of the upper block is denoted as Above, the unified MPM list is constructed as follows: If no adjacent blocks are available, the intra mode defaults to planar. ·If both Left and Above modes are non-angle modes, a. MPM list → {Planar, DC, V, H, V-4, V+4}. When one of the Left and Above modes is an angle mode and the other is a non-angle mode, a. Mode Max is set as the larger mode in Left and Above, b. MPM list → {Planar, Max, DC, Max-1, Max+1, Max-2}. ·If both Left and Above are angle modes and they are different, a. Mode Max is set as the larger mode in Left and Above, b. If the difference between the Left and Above modes is within the range of 2 to 62, i.MPM list → {Planar, Left, Above, DC, Max-1, Max+1} c. Otherwise, i.MPM list → {Planar, Left, Above, DC, Max-2, Max+2}. If both Left and Above are angles and they are the same, a. MPM list → {Planar, Left, Left-1, Left+1, DC, Left-2}.

[0147] Furthermore, the first bin of the MPM index codeword is CABAC context coded. A total of three contexts are used depending on whether the current intra block is MRL-enabled, ISP-enabled, or a normal intra block.

[0148] The left adjacent block and the upper adjacent block used in the unified MPM list construction are A2 and B2 shown in FIG.

[0149] One MPM flag is coded first, if the block is coded with one of the modes in the MPM list, the MPM index is coded further, otherwise the indices of the remaining modes (excluding the MPM) are coded.

[0150] LFNST signaling in VVC The LFNST signaling specified in JVET-P2001-v9 is as follows:

[0151] 7.3.9.5 Coding Unit Syntax

[0152] [Table 11] TIFF0007803913000059.tif135168

[0153] 4 Examples of shortcomings in existing implementations The ALWIP design in JVET-N0217 has the following problems.

[0154] 1) At the JVET meeting in March 2019, a unified 6-MPM list generation was adopted for MRL mode, ISP mode, and normal intra mode. However, the affine linear weighted prediction mode uses a different 3-MPM list construction, which complicates the MPM list construction. The complex MPM list construction can impair decoder throughput, especially for small blocks such as 4x4 samples.

[0155] 2) ALWIP is only applied to the luma component of a block. For the chroma components of an ALWIP coded block, the chroma mode index is coded and transmitted to the decoder, which may result in unnecessary signaling.

[0156] 3) The interaction of ALWIP with other coding tools should be considered.

[0157] 4) When calculating upsBdryX using the following formula,

[0158]

number

[0159] 5) When upsampling the prediction samples, no rounding is applied.

[0160] 6) In the deblocking process, ALWIP coded blocks are treated as normal intra blocks.

[0161] 7) Too many contexts (e.g., four) are used to code the ALWIP flag (e.g., intra_lwip_flag).

[0162] 8) When both vertical and horizontal upsampling are required, the upsampling order depends on the block shape, which is not hardware friendly.

[0163] 9) Linear interpolation filters are used for upsampling, but this can be inefficient.

[0164] The two-stage downsampling method used in ALWIP may introduce unnecessary computational complexity. In addition, using downsampled reference samples to generate upsampled prediction blocks may be inaccurate.

[0165] While MIP was applied only to the luma component, LFNST can be applied to both luma and chroma components under the dual-tree case with separate signaling of transformation matrix indices. However, in the dual-tree chroma case, parsing the syntax elements of the chroma components can depend on whether MIP is applied to the luma block (i.e., whether intra_MIP_flag[x0][y0]=0). Such dependency between different color components is undesirable.

[0166] 5. Exemplary Methods for Matrix-Based Intra-Coding Embodiments of the techniques of the present disclosure provide video coding with higher coding efficiency but lower computational complexity by overcoming the shortcomings of existing embodiments. The matrix-based intra prediction method for video coding, as described herein, improves both existing and future video coding standards, as demonstrated in the following examples illustrating various implementations. The examples of the disclosed techniques provided below are intended to illustrate general concepts and are not intended to be limiting. Unless otherwise specified in the examples, various features described in these examples may be combined.

[0167] In the following description, intra prediction mode refers to angular intra prediction mode (including DC, planar, CLM and other possible intra prediction modes), and intra mode refers to normal intra mode or MRL or ISP or ALWIP.

[0168] In the following description, "other intra modes" may refer to one or more intra modes other than ALWIP, such as normal intra mode, MRL, ISP, etc.

[0169] In the following discussion, SatShift(x,n) is defined as follows:

[0170]

number

[0171] In one example, offset0 and / or offset1 are (1<<n)> Set to 1 or (1<<(n-1)). In another example, offset0 and / or offset1 are set to 0.

[0172] Another example is offset0=offset1=((1<n)> >1)-1 or ((1<<(n-1)))-1.

[0173] Clip3(min,max,x) is defined as follows:

[0174]

number

[0175] Building an MPM list for ALWIP 1. It is proposed that the MPM list for ALWIP may be constructed in whole or in part according to the procedure for constructing the MPM list for non-ALWIP intra-mode (normal intra-mode, MRL or ISP, etc.). In one example, the size of the MPM list for ALWIP may be the same as the size of the MPM list for non-ALWIP intra mode. i. For example, the size of the MPM list is 6 in both ALWIP mode and non-ALWIP intra mode. b. In one example, the MPM list for ALWIP may be derived from the MPM list for non-ALWIP intra-mode. i. In one example, an MPM list for non-ALWIP intra modes may be built first, and then some or all of them may be converted to MPMs, which may then be further added to the MPM list for ALWIP coded blocks. 1) Alternatively or additionally, pruning can be applied when adding the transformed MPM to the MPM list for the ALWIP coded block. 2) A default mode may be added to the MPM list for ALWIP coded blocks. In one example, a default mode may be added before conversion from the MPM list of non-ALWIP intra modes. b. Alternatively, the default mode can be added after being converted from the MPM list of non-ALWIP intra modes. c. Alternatively, the default mode may be added in an interleaved manner with those converted from the MPM list of non-ALWIP intra modes. d. In one example, the default mode may be fixed to be the same for all types of blocks. e. Alternatively, the default mode may be determined according to coded information such as availability of neighboring blocks, mode information of neighboring blocks, block size, etc. ii. In one example, one intra-prediction mode in a non-ALWIP intra-mode MPM list may be converted to a corresponding ALWIP intra-prediction mode when it is placed in an ALWIP MPM list. 1) Alternatively, all intra-prediction modes in the MPM list for non-ALWIP intra modes may be converted to corresponding ALWIP intra-prediction modes before being used to construct the ALWIP MPM list. 2) Alternatively, all candidate intra prediction modes (which may include intra prediction modes from neighboring blocks and default intra prediction modes such as planar or DC) may be converted to corresponding ALWIP intra prediction modes before being used to construct an MPM list for a non-ALWIP intra mode when an MPM list for a non-ALWIP intra mode is used to derive an ALWIP MPM list. 3) In one example, two transformed ALWIP intra prediction modes may be compared. In one example, if they are the same, only one of them may be put into the MPM list for ALWIP. b. In one example, if they are the same, only one of them may be put into the MPM list for non-ALWIP intra mode. iii. In one example, K of the S intra prediction modes in the MPM list for the non-ALWIP intra mode may be selected as the MPM list for the ALWIP mode, e.g., K=3 and S=6. 1) In one example, the first K intra prediction modes in the MPM list for the non-ALWIP intra modes may be selected as the MPM list for the ALWIP mode.

[0176] 2. It is proposed that one or more neighboring blocks used to derive an MPM list for ALWIP can also be used to derive an MPM list for non-ALWIP intra modes (such as normal intra modes, MRL or ISP). a. In one example, the left neighboring block of the current block used to derive the MPM list for ALWIP should be the same as that used to derive the MPM list for non-ALWIP intra mode. i. Assuming the top-left corner of the current block is (xCb, yCb) and the width and height of the current block are W and H, in one example, the left neighboring block used to derive MPM lists for both ALWIP and non-ALWIP intra modes may cover position (xCb-1, yCb). In an alternative example, the left neighboring block used to derive MPM lists for both ALWIP and non-ALWIP intra modes may cover position (xCb-1, yCb+H-1). ii. For example, the left and upper neighboring blocks used in constructing the unified MPM list are A2 and B2 shown in FIG. b. In one example, the neighboring blocks above the current block used to derive the MPM list for ALWIP should be the same as those used to derive the MPM list for non-ALWIP intra mode. i. Assuming the top-left corner of the current block is (xCb, yCb) and the width and height of the current block are W and H, in one example, the upper neighboring block used to derive MPM lists for both ALWIP and non-ALWIP intra modes may cover position (xCb, yCb-1). In an alternative example, the upper neighboring block used to derive MPM lists for both ALWIP and non-ALWIP intra modes may cover position (xCb+W-1, yCb-1). ii. For example, the left adjacent block and the upper adjacent block used in constructing the unified MPM list are A1 and B1 shown in FIG.

[0177] 3. It is proposed that the MPM list for ALWIP can be constructed in different ways depending on the width and / or height of the current block. In one example, different adjacent blocks may be accessed for different block sizes.

[0178] 4. It is proposed that the MPM list for ALWIP and the MPM list for non-ALWIP intra-mode can be constructed using the same procedure, although with different parameters. a. In one example, K of the S intra prediction modes in the MPM list for non-ALWIP intra modes may be derived for the MPM list used in ALWIP mode, e.g., K=3 and S=6. i. In one example, the first K intra prediction modes in the MPM list construction procedure may be derived for the MPM list used in the ALWIP mode. b. In one example, the first mode in the MPM list may be different. i. For example, the first mode in an MPM list for a non-ALWIP intra mode may be planar, but in an MPM list for ALWIP it may be mode X0. 1) In one example, X0 may be an ALWIP intra prediction mode converted from planar. c. In one example, the stuffing modes within the MPM list may be different. i. For example, the first three stuffing modes in the MPM list for non-ALWIP intra modes may be DC, vertical and horizontal, but in the MPM list for ALWIP they may be modes X1, X2, X3. 1) In one example, X1, X2, X3 can be different for different sizeId. ii. In one example, the number of stuffing modes may vary. d. In one example, the neighboring modes in the MPM list may be different. For example, the normal intra prediction modes of neighboring blocks are used to construct an MPM list for non-ALWIP intra modes, and then converted to ALWIP intra prediction modes to construct an MPM list for the ALWIP modes. e. In one example, the shifted modes in the MPM list may be different. For example, X+K0 (where X is a normal intra-prediction mode and K0 is an integer) may be placed in the MPM list for a non-ALWIP intra-prediction mode, and Y+K1 (where Y is an ALWIP intra-prediction mode and K1 is an integer) may be placed in the MPM list for ALWIP, where K0 may be different from K1. 1) In one example, K1 may depend on the width and height.

[0179] 5. When building an MPM list for a current block in non-ALWIP intra mode, it is proposed that if a neighboring block is coded with ALWIP, then the neighboring block is treated as unavailable. a. Alternatively, when constructing an MPM list for a current block in non-ALWIP intra mode, if a neighboring block is coded in ALWIP, the neighboring block is treated as being coded in a pre-set intra prediction mode (e.g., planar).

[0180] 6. When building an MPM list for a current block in ALWIP mode, it is proposed that if a neighboring block is coded in non-ALWIP intra mode, then the neighboring block is treated as unusable. a. Alternatively, when constructing an MPM list for a current block in ALWIP mode, if a neighboring block is coded in a non-ALWIP intra mode, the neighboring block is treated as being coded in a pre-defined ALWIP intra prediction mode X. i. In one example, X may depend on the block dimensions, such as width and / or height.

[0181] 7. It is proposed to remove the storage of the ALWIP flag from the line buffer. a. In one example, if the second block to be accessed is located in a different LCU / CTU row / region compared to the current block, the condition check whether the second block is coded with ALWIP is skipped. b. In one example, if the second block to be accessed is located in a different LCU / CTU row / region than the current block, the second block is treated similarly to non-ALWIP mode, e.g., treated as a normal intra-coded block.

[0182] 8. When coding the ALWIP flag, up to K (K>=0) contexts can be used. In one example, K=1.

[0183] 9. Instead of directly storing the mode index associated with the ALWIP mode, it is proposed to store the transformed intra-prediction mode of the ALWIP coded block. a. In one example, the decoded mode index associated with one ALWIP coded block is mapped to a regular intra mode, eg, according to map_alwip_to_angular, as described in Section 2.5.7. b. Alternatively or additionally, storage of the ALWIP flag may be removed entirely. c. Alternatively or additionally, the ALWIP mode memory is removed entirely. d. Alternatively, the condition check whether one adjacent / current block is coded with the ALWIP flag can be skipped. e. Alternatively or additionally, the mode transformation assigned to the ALWIP coded block and the normal intra prediction associated with one accessed block may be skipped.

[0184] ALWIP for different color components 10. It is proposed that an estimated chroma intra mode (eg, DM mode) may always be applied if the corresponding luma block is coded in ALWIP mode. a. In one example, if the corresponding luma block is coded in ALWIP mode, the chroma intra mode is inferred to be DM mode without signaling. b. In one example, the corresponding luma block may be the one that covers the corresponding sample of the chroma sample located at a given position (e.g., top left of the current chroma block, center of the current chroma block). c. In one example, the DM mode may be derived according to the intra prediction mode of the corresponding luma block, for example, via mapping the (ALWIP) mode to one of the regular intra modes.

[0185] 11. If the corresponding luma block of a chroma block is coded in ALWIP mode, several DM modes can be derived.

[0186] 12. In the chroma mode decision process (e.g., direct mode / derived mode), the corresponding luma block used to identify whether it is ALWIP coded and / or its ALWIP mode may be determined according to the top-left position, along with the dimensions of the coded chroma block and / or color format. a. Assume the top-left position of the coded chroma block is (xCb, yCb), the width and height of the coded chroma block are CbWidth and CbHeight, respectively, and all positions and lengths are in luma sample units. b. In one example, the corresponding luma block may be selected as the luma block (e.g., coding block) covering the position (xCb+offsetY, yCb+offsetY), where both offsetX and offsetY are not allowed to be =0. i. In one example, offsetX=(CbWidth / 2) or (CbWidth / 2-1) or (CbWidth / 2+1). ii. In one example, offsetY=(CbHeight / 2) or (CbHeight / 2-1) or (CbHeight / 2+1).

[0187] 13. It is proposed that a chroma block be assigned a special mode if one corresponding luma block is coded in ALWIP mode. a. In one example, a special mode is defined as a given normal intra-prediction mode regardless of the intra-prediction mode associated with the ALWIP coded block. b. In one example, intra prediction may be assigned to this special mode in a different way. c. Alternatively, if a luma block is coded in ALWIP mode, the associated normal intra mode for the chroma DM mode may be inferred to always be identified as a special mode. d. Alternatively or additionally, the chroma mode signaling can be skipped. e. Alternatively, if the corresponding luma block of a chroma block is coded in ALWIP mode and DM mode is signaled for the chroma block, a predefined intra prediction mode is applied for the chroma block. i. For example, the predefined intra prediction mode may be a planar mode. ii. For example, the predefined intra prediction modes may depend on coded information such as the display of screen content. 1) In one example, if the display of the screen content indicates that the content is camera-captured content, it may be set to planar mode. 2) In one example, if the display of the screen content indicates that the content is screen content, it may be set to horizontal prediction mode. f. In one example, DM mode may never be used for a chroma block if its corresponding luma block is coded in ALWIP mode. i. For example, DM mode related syntax may not be signaled. 1) In one example, four chroma modes can be signaled for a chroma block if the corresponding luma block is in ALWIP mode and sps_cclm_enabled_flag=false. a. For example, in this case, intrachroma mode binarization may require a maximum of two bins. 1) In one example, seven chroma modes can be signaled for a chroma block if the corresponding luma block is in ALWIP mode and sps_cclm_enabled_flag=true. a. For example, in this case, intrachroma mode binarization may require up to four bins.

[0188] 14. It is proposed that ALWIP can also be applied to chroma components. In one example, the matrix and / or bias vector may be different for different color components. b. In one example, matrices and / or bias vectors may be predefined for both Cb and Cr. i. In one example, the Cb and Cr components may be concatenated. ii. In one example, the Cb and Cr components may be interleaved. c. In one example, a chroma component may share the same ALWIP intra prediction mode as the corresponding luma block. i. In one example, if the corresponding luma block applies the ALWIP mode and the chroma block is coded in DM mode, the same ALWIP intra prediction mode is applied to the chroma component. ii. In one example, the same ALWIP intra prediction mode can be applied to the chroma component and subsequent linear interpolation can be skipped. iii. In one example, the same ALWIP intra prediction mode is applied to a chroma component having a subsampled matrix and / or a bias vector. d. In one example, the number of ALWIP intra prediction modes for different components can be different. i. For example, the number of ALWIP intra prediction modes for the chroma component may be less than the number for the luma component of the same block width and height.

[0189] Applicability of ALWIP 15. It is proposed that it can be signaled whether ALWIP is applicable. a. For example, it can be signaled at the sequence level (e.g., in SPS), at the picture level (e.g., in PPS or picture header), at the slice level (e.g., in slice header), at the tile group level (e.g., in tile group header), at the tile level, at the CTU row level or at the CTU level. b. For example, if ALWIP is not applicable, the intra_lwip_flag is not signaled and can be presumed to be 0.

[0190] 16. It is proposed that whether ALWIP can be applied may depend on the block width (W) and / or height (H). c. For example, when W >= T1 (or W > T1) and H >= T2 (or H > T2), ALWIP may not be applied (e.g., T1 = T2 = 32). i. For example, when W <= T1 (or W < T1) and H <= T2 (or H < T2), ALWIP may not be applied (e.g., T1 = T2 = 32). d. For example, when W >= T1 (or W > T1) or H >= T2 (or H > T2), ALWIP may not be applied (e.g., T1 = T2 = 32). i. For example, when W <= T1 (or W < T1) or H <= T2 (or H < T2), ALWIP may not be applicable (e.g., T1 = T2 = 32). e. For example, when W + H >= T (or W * H > T), ALWIP may not be applicable (e.g., T = 256). i. For example, when W + H <= T (or W + H < T), ALWIP may not be applicable (e.g., T = 256). f. For example, when W * H >= T (or W * H > T), ALWIP may not be applicable (e.g., T = 256). i. For example, when W * H <= T (or W * H < T), ALWIP may not be applicable (e.g., T = 256). g. For example, when ALWIP cannot be applied, intra_lwip_flag is not signaled and may be assumed to be 0.

[0191] Computational Problems in ALWIP 17. It is proposed that the shift operation associated with ALWIP can only be a left shift or a right shift of the number of S (S must be non - negative). a. In one example, when S = 0 or S > 0, the right - shift operation may be different. i. In one example, upsBdryX[x] is calculated as follows.

[0192]

Number

[0193] b. In one example, upsBdryX[x] is calculated as follows.

[0194]

Number

[0195] 18. It is proposed that in the upsampling process of ALWIP, the result should be rounded towards or away from zero. a. In one example, predSamples[xHor+dX][yHor]=((upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor]+offsetHor) / upHor (8-X39) and predSamples[xVer][yVer+dY]=((upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer]+offsetVer) / upVer (8-X40) where offsetHor and offsetVer are integers, e.g., offsetHor=upHor / 2 and offsetVer=upVer / 2.

[0196] Interaction with other coding tools 19. It has been suggested that ALWIP can be used for CIIP coded blocks. a. In one example, in a CIIP coded block, it may be explicitly signaled whether an ALWIP intra prediction mode or a regular intra prediction mode such as planar is used to generate the intra prediction signal. b. In one example, it may be implicitly inferred whether an ALWIP intra-prediction mode or a regular intra-prediction mode such as planar is used to generate the intra-prediction signal. i. In one example, the ALWIP intra prediction mode may never be used in CIIP coded blocks. 1) Alternatively, regular intra prediction may never be used on CIIP coded blocks. ii. In one example, from information of neighboring blocks, it can be inferred whether an ALWIP intra prediction mode or a regular intra prediction mode such as planar is used to generate the intra prediction signal.

[0197] 20. It is proposed that all or part of the procedure used to downsample neighboring luma samples in CCLM mode may be used to downsample neighboring samples in ALWIP mode. a. Alternatively, all or part of the procedure used to downsample neighboring luma samples in ALWIP mode may be used to downsample neighboring samples in CCLM mode. b. The downsampling procedure may be invoked with different parameters / arguments when it is used in the CCLM process and the ALWIP process. c. In one example, the downsampling method in the CCLM process (eg, selection of neighboring luma positions, downsampling filters) may be utilized in the ALWIP process. d. The procedure of downsampling neighboring luma samples includes at least the following operations: selection of downsampled positions, downsampling filter, rounding, and clipping operations.

[0198] 21. It is proposed that blocks coded in ALWIP mode cannot have RST or / and quadratic transformation or / and rotation transformation or / and non-separable quadratic transformation (NSST) applied. In one example, whether such a constraint can be applied may depend on the dimensional information of the block, for example, similar to the condition described in (15). b. Alternatively, ALWIP mode may not be allowed if RST or / and secondary transformation or / and rotation transformation or / and NSST are applied. c. Alternatively, blocks coded in ALWIP mode may apply RST or / and quadratic transform or / and rotation transform or / and non-separable quadratic transform (NSST). i. In one example, the selection of the transformation matrix may depend on the ALWIP intra prediction mode. ii. In one example, the selection of the transformation matrix may depend on the normal intra-prediction mode converted from the ALWIP intra-prediction mode. iii. In one example, the selection of the transformation matrix may depend on the classification of the normal intra-prediction mode converted from the ALWIP intra-prediction mode.

[0199] 22. It is proposed that blocks coded in ALWIP mode cannot be subjected to block-based DPCM (BDPCM) or residual RDPCM. Alternatively, if BDPCM or RDPCM is applied, ALWIP mode may not be allowed.

[0200] 23. It is proposed that blocks coded in ALWIP mode may use only DCT-II as transform. a. In one example, the signaling of the transformation matrix index is always skipped. Alternatively, it is proposed that the transform used for blocks coded in ALWIP mode may be derived implicitly rather than being explicitly signaled, e.g., the transform may be selected according to the method proposed in JVET-M0303. c. Alternatively, it is proposed that blocks coded in ALWIP mode may use transform skipping only. i. Alternatively or additionally, if ALWIP is used, the signaling indicating the use of transform skip is skipped. d. In one example, ALWIP mode information (eg, enable / disable, prediction mode index) may be conditionally signaled after the display of the transformation matrix. i. In one example, for a given transform matrix (eg, transform-skip or DCT-II), an indication of ALWIP mode information may be signaled. ii. Alternatively or additionally, the display of ALWIP mode information may be skipped for some predefined transformation matrices.

[0201] 24. A block coded in ALWIP mode is considered to have been coded with normal intra prediction converted from ALWIP intra prediction mode if the selected transform is mode dependent.

[0202] 25. Conversion skip does not need to be used in ALWIP mode. a. For example, in this case, there is no need to further signal an indication of the use of transform skip. b. Alternatively, if transform skipping is applied, ALWIP mode may not be allowed. i. For example, in this case, if transform skipping is applied, there is no need to signal ALWIP mode information.

[0203] 26. In filtering processes such as deblocking filters, sample adaptive offset (SAO), adaptive loop filters (ALF), etc., how to select filters and / or whether to filter samples can be determined using ALWIP.

[0204] 27. Unfiltered adjacent samples can be used in ALWIP mode. Alternatively, filtered adjacent samples can be used in ALWIP mode. b. In one example, filtered neighboring samples may be used for downsampling and unfiltered neighboring samples may be used for upsampling. c. In one example, unfiltered adjacent samples may be used for downsampling and unfiltered adjacent samples may be used for upsampling. d. In one example, the filtered left-neighboring sample may be used for upsampling, and the unfiltered upper-neighboring sample may be used for upsampling. e. In one example, the unfiltered left-neighboring sample may be used for upsampling, and the filtered upper-neighboring sample may be used for upsampling. f. In one example, whether to use filtered or unfiltered neighboring samples may depend on the ALWIP mode. In one example, the ALWIP mode may be converted to a conventional intra-prediction mode, and whether filtered or unfiltered neighboring samples are used may depend on the converted conventional intra-prediction mode. For example, such a decision is the same as for the conventional intra-prediction mode. ii. Alternatively, whether to use filtered or unfiltered neighboring samples for the ALWIP mode can be signaled. g. In one example, the filtered samples may be generated in the same manner as in a conventional intra-prediction mode.

[0205] 28. Which matrix and / or offset vector to use may depend on the reshaping (LMCS, also known as luma mapping with chroma scaling) information. In one example, different matrices and / or offset vectors may be used when reshaping is on and off. b. In one example, different matrices and / or offset vectors may be used for different reshaping parameters. c. In one example, ALWIP can always occur in the originating domain. i. For example, adjacent samples are mapped to the original domain (if reshaping is applied) before being used in ALWIP.

[0206] 29. ALWIP may be overridden if reshaping is applied. Alternatively, if ALWIP is enabled, reshaping can be disabled. b. In one example, ALWIP may be disabled for HDR (High Dynamic Range) content when reshaping is applied.

[0207] 30. The matrices used in ALWIP may depend on the bit depth of the samples. a. Alternatively or additionally, the offset value used in ALWIP may depend on the bit depth of the sample. b. Alternatively, the matrix parameters and offset values ​​can be stored with M-bit precision for N-bit samples (M<=N), for example, the matrix parameters and offset values ​​can be stored with 8-bit precision for 10-bit samples. c. The sample bit depth may be the bit depth of the input array for a color component such as luma. d. Sample bit depth may be the bit depth of the internal array / reconstructed samples for color components such as luma.

[0208] 31. Matrix parameters and / or offset values ​​for a specified block size may be derived from matrix parameters and / or offset values ​​for other block sizes.

[0209] 32. In one example, a 16x8 matrix of 8x8 blocks can be derived from a 16x4 matrix of 4x4 blocks.

[0210] 33. It is proposed that the predictions generated by ALWIP can be treated as intermediate signals that are processed to obtain prediction signals that are used further. a. In one example, position-dependent intra-prediction combining (PDPC) may be applied to the predictions generated by ALWIP to generate the prediction signal that is further used. i. In one example, PDPC is performed on an ALWIP coded block in the same way as if the block were coded in a particular regular intra prediction mode, such as planar or DC. ii. In one example, PDPC is performed on ALWIP coded blocks in the same way as blocks coded in normal intra prediction mode that are converted from ALWIP intra prediction mode. iii. In one example, PDPC is conditionally applied to ALWIP coded blocks. 1) For example, PDPC is applied to an ALWIP coded block only if PDPC is applied to a normal intra prediction mode converted from an ALWIP intra prediction mode. a. In one example, the boundary sample prediction generated by ALWIP may be filtered with neighboring samples to generate a prediction signal that is further used. i. In one example, filtering on boundary samples is performed on ALWIP coded blocks in the same way as if the block were coded in a particular regular intra prediction mode such as planar or DC. ii. In one example, filtering on boundary samples is performed on an ALWIP coded block in the same way as if the block were coded in a normal intra prediction mode converted from the ALWIP intra prediction mode. iii. In one example, filtering on boundary samples is conditionally applied to ALWIP coded blocks. 1) For example, filtering on boundary samples is applied to an ALWIP coded block only if filtering on boundary samples is applied to a normal intra prediction mode converted from the ALWIP intra prediction mode.

[0211] 34. It is proposed that interpolation filters other than bilinear interpolation filters can be used in the upsampling process of ALWIP. In one example, a 4-tap interpolation filter may be used in the upsampling process of ALWIP. i. For example, the 4-tap interpolation filter of VVC used to perform motion compensation for chroma components can be used in the upsampling process of ALWIP. ii. For example, the 4-tap interpolation filter of VVC used to perform angular intra prediction can be used in the upsampling process of ALWIP. iii. For example, the 8-tap interpolation filter of VVC used to perform motion compensation for the luma component can be used in the upsampling process of ALWIP.

[0212] 35. Samples within a block coded in ALWIP mode can be predicted in different ways. a. In one example, for a W*H block, a prediction of a sW*sH sub-block within the block may be generated by applying sW*sH ALWIP to it. i. In one example, for a W*H block, the prediction of its upper-left W / 2*H / 2 block may be generated by applying W / 2*H / 2 ALWIP to it. ii. In one example, for a W*H block, a prediction of the W / 2*H blocks to its left may be generated by applying W / 2*H ALWIP to it. iii. In one example, for a W*H block, a prediction of the W*H / 2 block above it may be generated by applying W*H / 2 ALWIP to it. iv. In one example, the sW*sH sub-block may have left and / or upper neighboring samples available. b. In one example, how to determine the position of a sub-block may depend on the dimensions of the block. i. For example, if W>=H, then a prediction of the W / 2*H blocks to its left can be generated by applying W / 2*H ALWIP to it. ii. For example, if H>=W, then a prediction of the W*H / 2 blocks above it can be generated by applying W*H / 2 ALWIP to it. iii. For example, if W=H, then the prediction of the W / 2*H / 2 block to its upper left can be generated by applying W / 2*H / 2 ALWIP to it. c. Furthermore, in one example, predictions for the remaining samples (eg, samples that do not belong to the sW*sH sub-block) may be generated by applying W*H ALWIP. i. Alternatively, predictions of the remaining samples may be generated by applying conventional intra prediction (eg, using the return intra prediction mode as the intra mode). ii. Furthermore, calculations can be skipped for samples within sW*sH sub-blocks.

[0213] 35. Samples within a block coded in ALWIP mode may be predicted at the sub-block (eg, size sW*sH) level. a. In one example, sW*sH ALWIP may be applied to each sub-block using neighboring reconstructed samples (e.g., for boundary sub-blocks) or / and neighboring predicted samples (e.g., for interior sub-blocks). b. In one example, the sub-blocks may be predicted in raster scan order. c. In one example, the sub-blocks may be predicted in a zigzag order. d. In one example, the width (height) of a sub-block may be less than or equal to sWMax (sHMax). e. In one example, if a block has either a width or a height or both a width and a height greater than (or equal to) a threshold L, the block may be divided into multiple sub-blocks. f. The threshold L may be predefined or signaled at the SPS / PPS / picture / slice / tile group / tile level. i. Alternatively, the threshold may depend on specific coding information such as block size, picture type, temporal layer index, etc.

[0214] 37. It is proposed that adjacent samples (neighboring or non-neighboring) be filtered before being used in ALWIP. Alternatively, the adjacent samples are not filtered before being used in ALWIP. b. Alternatively, the adjacent samples are conditionally filtered before being used in ALWIP. i. For example, neighboring samples are filtered before being used in ALWIP only if the ALWIP intra prediction mode is equal to 1 or some specific value.

[0215] 38. When encoding the ALWIP flag, it is proposed that the method of deriving the context for the ALWIP flag in arithmetic coding is the same for all dimensions of the current block. a. In one example, the method for deriving the context for the ALWIP flag in arithmetic coding is the same if (Abs(Log2(cbWidth)-Log2(cbHeight))) is greater than 1 or not, where CbWidth and CbHeight are the width and height of the current block, respectively. b. In one example, the derivation of the context for the ALWIP flag in arithmetic coding depends only on the ALWIP information of neighboring blocks and / or the availability of neighboring blocks. i. In one example, the ALWIP information (e.g., intra_lwip_flag) of multiple neighboring blocks and / or the availability of the neighboring blocks are used directly. For example, the ALWIP flags of the left and upper neighboring blocks and / or the availability of the left and upper neighboring blocks are used to derive a context for the ALWIP flag in arithmetic coding. An example is shown in Table 5. Alternatively, and further, the context index offset ctxInc=(condL && availableL)+(condA && availableA)+ctxSetIdx*3.

[0216] [Table 12] Table 5: Specification of ctxInc using the syntax elements on the left and above

[0217] ii. In one example, one of the ALWIP information (e.g., intra_lwip_flag) of the neighboring block is used to derive the context for the ALWIP flag in arithmetic coding, and the neighboring block may be the left-neighboring block. An example is shown in Table 6. Alternatively, and further, the context index offset ctxInc=(condL && availableL)+ctxSetIdx*3.

[0218] [Table 13] Table 6: Specification of ctxInc using the syntax elements on the left and above

[0219] iii. In one example, one of the ALWIP flag information (e.g., intra_lwip_flag) of the neighboring block is used to derive the context of the ALWIP flag in arithmetic coding, and the neighboring block may be the upper neighboring block. An example is shown in Table 7. Alternatively, further, the context index offset ctxInc=(condA && availableA)+ctxSetIdx*3.

[0220] [Table 14] Table 7: Specification of ctxInc using the syntax elements on the left and above

[0221] c. In one example, one fixed context is used to encode the ALWIP flag in the arithmetic encoding. d. In one example, the ALWIP flag is bypass coded in the arithmetic coding. e. Alternatively, K contexts may be used to code the ALWIP flag in arithmetic coding. The context used may depend on the dimensions of the block (e.g., width denoted W and height denoted H). i. In one example, K = 2. If W > N*H or H > N*W (e.g., N = 2), the first context is used, otherwise the second context is used.

[0222] 39. It is proposed that N (N>=0) contexts can be used to code the ALWIP flag (eg, intra_lwip_flag) in arithmetic coding. In one example, N = 3. The ALWIP flags and / or availability of two adjacent and / or non-adjacent blocks may be used to derive the context used for the ALWIP flag in arithmetic coding. i. In one example, the two adjacent blocks may include an upper (eg, B1 in FIG. 10) block and a left (eg, A1 in FIG. 10) block. ii. In one example, the two adjacent blocks may include an upper block and a lower-left (eg, A2 in FIG. 10) block. iii. In one example, the two adjacent blocks may include an upper block and an upper right (eg, B2 in FIG. 10) block. iv. In one example, the two adjacent blocks may include an upper right (eg, B2 in FIG. 10) block and a left (eg, A1 in FIG. 10) block. v. In one example, the two adjacent blocks may include an upper right (eg, B2 in FIG. 10) block and a lower left (eg, A2 in FIG. 10) block. vi. In one example, the two adjacent blocks may include a left block (eg, A1 in FIG. 10) and a bottom-left block (eg, A2 in FIG. 10). vii. In one example, adjacent blocks may be defined differently from those in FIG. 10. An example is shown in FIG. 16. Two adjacent blocks may include any two of the {top right, top left, top left, bottom left} blocks. For example, two adjacent blocks may include any two of {B0, B1, B2, A0, A1} blocks. b. In one example, N = 2. The ALWIP flag and / or availability of one adjacent and / or non-adjacent block may be used to derive the context used for the ALWIP flag in arithmetic coding. In one example, the neighboring blocks can be any of {top right, top left, top left, bottom left}. An example of neighboring blocks is shown in Figure 10. ii. In one example, the neighboring block can be any of the {top right, top left, top left, bottom left} blocks. An example of the neighboring block is shown in Figure 16. c. In one example, one fixed context may be used to encode the ALWIP flag in the arithmetic coding. d. In one example, the ALWIP flag may be bypass coded in the arithmetic coding. Figure 16 shows an example of neighboring blocks.

[0223] 40. It is proposed that reduced boundary samples can be generated without computing upsampled boundary samples. In one example, the reference sample at the upsampling boundary sample position is directly used in the predictive upsampling process. i. In one example, the upsampling boundary samples may not be calculated by averaging multiple adjacent reference samples. b. In one example, the reduced boundary samples may be calculated directly from the reference samples and the downscaling coefficients. i. In one example, the downscaling factor may be calculated by the transform block size and the downsampled boundary size.

[0224] 41. It is proposed that the reduced boundary samples used for matrix multiplication can be generated in one stage. a. In one example, they may be generated directly from the original reconstructed neighboring samples in one stage (note that VVC WD5 uses two-stage downsampling to generate ALWIP reduced boundary samples, as described in Section 2.2.1.5.4.4). The original reconstructed neighboring samples may be decoded neighboring samples without further processing. For example, the original reconstructed neighboring samples may be used to generate angular inter-predicted samples. b. In one example, the reduced boundary samples may be generated from the original reconstructed samples located in the adjacent rows above and / or adjacent columns to the left of the current block. i. In one example, suppose N reduced boundary samples need to be generated from M original reconstructed samples adjacent to a current block (in a given order), then each of K consecutive original reconstructed adjacent samples may be used to obtain one output reduced boundary sample. 1) In one example, K=M / N. a. Alternatively, K=(M+N / 2) / N. 2) In one example, one output reduced boundary sample may be derived as the average of K consecutive original reconstructed neighboring samples. 3) In one example, one output reduced boundary sample may be derived as a weighted average of K consecutive original reconstructed neighboring samples. c. In one example, the left reduced boundary sample may be generated from the original reconstructed sample located in the adjacent column to the left of the current block, while the upper reduced sample may be generated from the original reconstructed sample located in the adjacent row above the current block. i. For example, as shown in Figure 17, left and boundary top The four reduced boundary samples on the left and top boundaries, denoted as , respectively, are generated by the original neighboring reconstruction samples on the left / top sides of the current 16x16 ALWIP block (denoted as the gray grid adjacent to the 16x16 block in the figure). d. How the reduced boundary samples are generated may depend on the block dimensions / coding information (eg, intra-prediction mode, transform type, etc.). e. In one example, the above method may be applied to ALWIP blocks of any size that require generation of reduced boundary samples (e.g., from 4x4 ALWIP blocks to 64x64 ALWIP blocks). f. In one embodiment, the process of generating reduced boundary samples for the adjacent columns to the left of the current block and the adjacent rows above the current block can be done in different ways. i. For example, for an 8x4 ALWIP block, the predefined number of reduced boundary samples is four on the top and four on the left, and the eight adjacent samples located on the top side of the 8x4 ALWIP block are used to generate the four reduced boundary samples on the top, while the four adjacent samples located on the left column of the 8x4 ALWIP block are directly copied as the four reduced boundary samples on the left.

[0225] 42. To generate the final predicted block from the reduced predicted block, we propose to use all or part of the original reconstructed neighboring samples (near or not near the current block) in the upsampling process. In one example, the original reconstructed neighboring samples may be located in the upper adjacent row and / or the left adjacent column of the current block. An example is shown in Figure 18, in which a 64x64 final prediction block is generated by upsampling from the 64x64 block of original reconstructed neighboring samples in addition to an 8x8 reduced prediction block. i. Alternatively, the reduced boundary samples may be used only in the matrix multiplication to obtain the reduced prediction block, but may not be used in the upsampling process to generate the final prediction block. For example, K reduced boundary samples may be input to the matrix multiplication of ALWIP to generate an MxN reduced prediction block, but may not be used to generate the final prediction block in the upsampling process. For example, K=8, and MxN is 8x8. b. In one example, selected original reconstructed neighboring samples may be used in an upsampling process to generate a final prediction block from the reduced prediction block. i. For example, all original reconstructed neighboring samples to the left of the current block may be selected. ii. For example, all original reconstructed neighboring samples above the current block may be selected. iii. For example, K of each M consecutive original reconstructed neighboring samples to the left of the current block may be selected, e.g., K=1 and M=2 / 4 / 8. 1) For example, the last K original reconstructed adjacent samples of each M consecutive adjacent samples may be selected. 2) For example, the first K original reconstructed adjacent samples of each M consecutive adjacent samples may be selected. iv. For example, K of each of the M consecutive original reconstructed neighboring samples above the current block may be selected, e.g., K=1 and M=2 / 4 / 8. 1) For example, the last K original reconstructed adjacent samples of each M consecutive adjacent samples may be selected. 2) For example, the first K original reconstructed adjacent samples of each M consecutive adjacent samples may be selected. v. For example, the selection may depend on the width and height of the block. Suppose blkW and blkH denote the width and height of the ALWIP block, respectively, and (blkX,blkY) represents the position of the top left corner of the block. 1) For example, if blkW is greater than or equal to blkH, all original reconstructed neighboring samples on the left side of the current block may be selected and / or the number of selected original reconstructed neighboring samples on the upper side of the current block, denoted by M, may depend on blkW. a. In one example, the kth selected sample above the current block may be at position (blkX+(k+1)*blkW / M-1,blkY-1), where k ranges from 0 to M-1. b. For example, if blkW<=8, then M=4. c. For example, if blkW>8, then M=8. d. Alternatively, regardless of the relationship between blkW and blkH, all of the original reconstructed neighboring samples to the left of the current block may be selected and / or M original reconstructed neighboring samples above the current block may be selected, where M is determined by the rules above. 2) For example, if blkW is smaller than blkH, all of the original reconstructed neighboring samples above the current block may be selected and / or the number of selected original reconstructed neighboring samples to the left of the current block, denoted by M, may depend on blkH. a. In one example, the kth selected sample on the side of the current block may be at position (blkX-1, blkY+(k+1)*blkH / M-1), where k ranges from 0 to M-1. b. For example, if blkH<=8, then M=4. c. For example, if blkH>8, then M=8. d. Alternatively, regardless of the relationship between blkW and blkH, all of the original reconstructed neighboring samples above the current block may be selected and / or M original reconstructed neighboring samples to the left of the current block may be selected, where M is determined by the rules above. c. In one example, the neighboring samples used for ALWIP upsampling may be further modified (e.g., filtered, where the filter is an N-tap filter, e.g., N=2 or 3) before being used to generate the final predicted block. i. In one example, the adjacent sample filtering process may be adaptively applied according to an ALWIP mode. d. How the final prediction block is generated (eg, linear interpolation) may depend on block dimensions / coding information (eg, intra-prediction direction, transform type, etc.).

[0226] 43. In one example, samples may have different precision at different filtering stages in the upsampling process in ALWIP. A "sample" refers to a predicted sample or an intermediate sample before or after upsampling. a. In one example, in the upsampling process in ALWIP, samples are upsampled horizontally along a first dimension in a first filtering stage, and then the samples are upsampled vertically along a second dimension in a second filtering stage. i. Alternatively, in the upsampling process in ALWIP, samples are upsampled vertically along a first dimension in a first filtering stage, and then samples are upsampled horizontally along a second dimension in a second filtering stage. b. In one example, the output upsampling results without right shifting or division in the first filtering stage may be used as input samples to the second filtering stage. i. In one example, the output upsampling filtering result in the second filtering stage may be shifted right by Shift1 or divided by Dem1 to derive the final upsampling result. ii. In one example, the output upsampling filtering result in the second filtering stage may be shifted right by Shift2 or divided by Dem2 to derive the final upsampling result. 1) In one example, Shift1 = 2 x Shift2; Dem1 = Dem2 x Dem2. iii. In one example, samples that are input to the second filtering stage but are not the result of output upsampling in the first filtering stage may be shifted to the left by Shift3 or divided by Dem3 before being input to the second filtering stage. 1) In one example, Shift3=Shift1; Dem3=Dem2. c. In one example, the output upsampling result in the first filtering stage may be shifted to the right by Shift1 or divided by Dem1 before being used as an input sample to the second filtering stage. i. In one example, the output upsampling filtering result in the second filtering stage can be shifted right by Shift2 or divided by Dem2 to derive the final upsampling result, where Shift2 may not be equal to Shift1, for example, Shift2>Shift1, and Dem2 may not be equal to Dem1, for example, Dem2>Dem1. ii. In one example, the output upsampling filtering result in the first filtering stage can be shifted right by Shift3 or divided by Dem3 to derive the final upsampling result, where Shift3 may be equal to Shift1, and Dem3 may not be equal to Dem1. 1) In one example, Shift3 = Shift1 + Shift2. iii. In one example, samples that are input to the second filtering stage but are not the output upsampling results in the first filtering stage may be shifted to the left or multiplied by a factor before being input to the second filtering stage. d. In one example, the output upsampling result in the first filtering stage may be shifted to the left by Shift1 or multiplied by Dem1 before being used as an input sample to the second filtering stage. i. In one example, the output upsampling result in the second filtering stage may be shifted to the right or divided by a factor to derive the final upsampling result. ii. In one example, the output upsampling result in the first filtering stage may be shifted to the right or divided by a factor to derive the final upsampling result. In one example, samples that are input to the second filtering stage but are not the output upsampling results in the first filtering stage may be shifted left by Shift2 or multiplied by Dem2 before being input to the second filtering stage, where Shift2 may not be equal to Shift1, e.g., Shift2>Shift1, and Dem1 may not be equal to Dem2, e.g., Dem2>Dem1. e. In one example, the samples input to the first filtering stage may be shifted to the left by Shift1 or multiplied by Dem1 before being used as input samples to the first filtering stage. i. In one example, the output upsampling result in the second filtering stage may be shifted to the right or divided by a factor to derive the final upsampling result. ii. In one example, the output upsampling result in the first filtering stage may be shifted to the right or divided by a factor to derive the final upsampling result. In one example, samples that are input to the second filtering stage but are not the output upsampling results in the first filtering stage may be shifted left by Shift2 or multiplied by Dem2 before being input to the second filtering stage, where Shift2 may not be equal to Shift1, e.g., Shift2>Shift1, and Dem1 may not be equal to Dem2, e.g., Dem2>Dem1.

[0227] 44. It is proposed that upsampling in ALWIP can be done in a fixed order when both vertical and horizontal upsampling are required. In one example, horizontal upsampling may be performed first and vertical upsampling may be performed second. b. In one example, vertical upsampling may be performed first and horizontal upsampling may be performed second.

[0228] 45. In one example, the prediction samples in ALWIP before upsampling may be transposed according to the block dimension. a. In one example, a W*H block may first be transposed to a H*W block, after which upsampling may be applied. b. Alternatively or additionally, after the upsampling process, the upsampled samples may be transposed in the opposite manner.

[0229] 46. ​​It is proposed that instead of bilinear filters, alternative interpolation filters can be used for upsampling in ALWIP. In one example, a (4-tap, 6-tap, 8-tap, etc.) Gaussian filter may be used. b. In one example, a cubic filter (4-tap, 6-tap, 8-tap, etc.) may be used. c. In one example, an interpolation filter used for motion compensation for chroma samples may be used. d. In one example, an interpolation filter (6 tap, 8 tap, etc.) used for motion compensation for luma samples may be used. e. Which interpolation filter to use may depend on the block size. f. Which interpolation filter to use may depend on the upsampling ratio. g. Which interpolation filter to use may depend on the ALWIP prediction mode. h. Which interpolation filter to use may depend on how many samples are available for upsampling. i. For example, if there are four available samples in a row (or column) (excluding adjacent reference samples), a 4-tap interpolation filter may be used. ii. For example, if there are 8 available samples in a row (or column) (excluding adjacent reference samples), a 4-tap or 8-tap interpolation filter can be used.

[0230] 47. It is proposed that the MPM for a block coded in ALWIP mode can be constructed independently from neighboring blocks. In one example, the MPM for blocks coded in ALWIP mode is predefined. i. For example, a predefined MPM is {M0, M1, M2} for all block dimensions, e.g., M0=0, M1=1 and M2=2. ii. For example, the predefined MPM for a block coded in ALWIP mode may depend on the dimensions of the block. For example, the predefined MPM for a block coded in ALWIP mode may depend on the sizeId defined in Section 2.2.1.5. 1) For example, if sizeId=0, the MPM will be ordered as {17,34,5}. 2) For example, if sizeId=1, the MPM will be in the order {0,7,16}. 3) For example, if sizeId=2, the MPM will be ordered as {1,4,6}. iii. For example, the predefined MPM for a block coded in ALWIP mode should be fixed relative to the first K matrices. 1) In one example, K=3. 2) In one example, K may depend on the block size. b. In one example, there are a fixed number of MIP modes (eg, 11) for blocks with all kinds of widths and heights, but the MPMs can be different for blocks with different sizeIds. i. For example, if sizeId=0, the MPM will be ordered as {10,5,1}. ii. For example, if sizeId=1, the MPM will be ordered as {9,7,1}. iii. For example, if sizeId=2, the MPM will be ordered as {6,1,8}. c. In one example, there are a fixed number of MIP modes (eg, 11) for blocks with all kinds of widths and heights, and the MPM is the same for blocks with all kinds of widths and heights.

[0231] 48. It is proposed to unify the number of matrices used for ALWIP regardless of block size. In one example, S matrices can be stored for all block sizes, e.g., S=11 or S=19 or S=35. b. In one example, ALWIP mode signaling is done in the same way for all block sizes. c. Alternatively or additionally, the matrix may be different for different block sizes.

[0232] 49. It is proposed that coding / parsing side information of secondary transforms (e.g., LFNST) of chroma blocks can be decoupled from the corresponding luma MIP information, i.e., the side information can still be signaled / parsed even if the corresponding luma block is coded in MIP mode. a. Alternatively or additionally, whether to apply a secondary transform for a chroma block can be decoupled from the corresponding luma MIP information. i. In one example, a secondary transform may still be applied even if the corresponding luma block is coded in MIP mode. b. In one example, the chroma blocks may be in a dual tree structure or a local dual tree structure. c. In one example, in the case of dual-tree chroma, whether LFNST is applied can be decoupled from whether the corresponding luma block is MIP-coded. i. Alternatively or additionally, in the case of dual tree chroma, whether to apply LFNST can be decoupled from whether the block is smaller than M×N (e.g., M=N=16). d. In one example, in the case of dual-tree chroma, whether to apply LFNST can be decoupled from whether the current chroma block is MIP coded. i. Alternatively or additionally, MIP can always be disabled for chroma blocks. ii. Alternatively, in the case of dual-tree chroma, whether to apply LFNST can be decoupled from whether the current chroma block is coded by MIP. e. In one example, in the case of dual-tree chroma, the signaling of the LFNST index (such as lfnst_idx) may be decoupled from the MIP flag (e.g., intra_MIP_flag). Alternatively, in the case of single-tree or dual-tree luma, whether LFNST is applied may be conditioned on whether the corresponding luma block is MIP coded. i. In one example, in the case of single-tree or dual-tree luma (e.g., when treeType=not DUAL_TREE_CHROMA), the signaling of the LFNST index (such as lfnst_idx) may be conditioned by the dimensions of the corresponding MIP-coded luma block. 1) For example, an LFNST index (such as lfnst_idx) can be signaled only if treeType=DUAL_TREE_CHROMA, the corresponding luma block is coded in MIP (intra_MIP_flag is true) mode, and the min(width, height) of the corresponding luma block is greater than or equal to 16.

[0233] 50. It is proposed to signal side information of secondary transformations (e.g., lfnst_idx) under tree-type condition checking. a. In one example, whether to signal side information may depend on whether the tree type is a chroma dual tree (eg, treeType==DUAL_TREE_CHROMA), which may include the case of a chroma-local dual tree. i. Alternatively, whether to signal side information may depend on whether the tree type is a chroma duplex tree, except in the case of a chroma local duplex tree. b. Condition A is defined as "MIP is not applied, and both the block width and block height considered by LFNST are not less than an integer N, such as 16." For example, condition A may be described as (!intra_mip_flag[x0][y0]||Min(lfnstWidth,lfnstHeight)>=16) in JVET-P2001-v9. Condition B is defined as "the current block is a chroma block in a dual tree (or local dual tree) structure," and may be described as (treeType==DUAL_TREE_CHROMA). Condition C is defined as "the current block is a luma block in a dual tree (or local dual tree) structure." For example, condition C may be described as (treeType==DUAL_TREE_LUMA). i. It is proposed that whether condition A is used to determine whether LFNST can be used may depend on condition B. 1) For example, if condition B is TRUE, condition A is ignored. Otherwise (condition B is FALSE), if condition A is FALSE, LFNST is not used. ii. It is proposed that whether condition A is used to determine whether all or part of the information about the LFNST can be signaled may depend on condition B. 1) For example, if condition B is TRUE, condition A is ignored. Otherwise (condition B is FALSE), if condition A is FALSE, all or part of the information about LFNST is not signaled. iii. It is proposed that whether condition A is used to determine whether LFNST can be used may depend on condition C. 1) For example, if condition C is FALSE, then condition A is ignored. Otherwise (condition B is FALSE), if condition A is FALSE, then LFNST is not used. iv. It is proposed that whether condition A is used to determine whether all or part of the information about the LFNST can be signaled may depend on condition C. 1) For example, if condition C is FALSE, condition A is ignored. Otherwise (condition B is FALSE), if condition A is FALSE, all or part of the information about LFNST is not signaled. v. In one example, in the case of a single tree, condition A may only control whether to apply LFNST to the luma component. 1) For example, in one example, if the condition to apply LFNST to the chroma components is met, but condition A is FALSE, LFNST is not applied to the luma component, but may be applied to the chroma components. a. In this case, all or some information regarding LFNST is signaled to control whether and / or how LFNST is applied to chroma components.

[0234] 51. The signaling / parsing of side information (e.g., lfnst_idx) of secondary transforms can be categorized depending on the color component. a. In one example, the individual side information (e.g., lfnst_idx) of the secondary transform is Cr). For example, lfnst_idx[cIdx] can be different for different cIdx. cIdx can be 0, 1 and 2 for color components Y, Cb and Cr, respectively. i. In one example, the chroma components (such as Cb and Cr) may share the same side information of the secondary transform. a. In one example, individual side information (e.g., lfnst_idx) of the secondary transform may be signaled / parsed for luma and chroma components. For example, lfnst_idx[cIdx] may be different for different cIdx. cIdx may be 0 and 1 for luma and chroma components, respectively.

[0235] 52. Signaling / parsing of MIP side information (e.g., intra_mip_flag) can be categorized depending on the color component. a. In one example, individual side information of MIP (e.g., intra_mip_flag) may be signaled / parsed for each color component (e.g., Y, Cb, Cr). For example, intra_mip_flag[cIdx] may be different for different cIdx. cIdx may be 0, 1, and 2 for color components Y, Cb, and Cr, respectively. i. In one example, the chroma components (such as Cb and Cr) may share the same side information of the MIP. b. In one example, individual side information of MIP (e.g., intra_MIP_flag) may be signaled / parsed for luma and chroma components. For example, intra_mip_flag[cIdx] may be different for different cIdx. cIdx may be 0 and 1 for luma and chroma components, respectively.

[0236] 5. Implementation form Newly added portions are highlighted in bold italics, and deleted portions are highlighted in strikethrough in the drawings or in bold underlined text herein.

[0237] 5.1 An example Three contexts are used to code the ALWIP flag: Figure 25 shows an updated table containing the assignment of ctxInc to syntax elements with context coding bins.

[0238] 5.2 An example One fixed context is used to code the ALWIP flag. Figure 26 shows an updated table containing the assignment of ctxInc to syntax elements with context coding bins.

[0239] 5.3 An example The boundary reduction process is performed in one step.

[0240] The following embodiment is based on the proposed test CE3-4.1_v2 of JVET-N0220.

[0241] 8.4.4.2.X1 Affine Linear Weighted Sample Prediction 8.4.4.2.X3 Boundary Reduction Process Specification The inputs to this process are: - a variable nTbX that specifies the transformation block size, - Reference sample refX[x] (x=0..nTbX-1) and - a variable boundySize that specifies the downsampled boundary size, - A flag needUpsBdryX that specifies whether intermediate boundary samples are needed for upsampling, and - a variable upsBdrySize that specifies the boundary size for upsampling, is. The output of this process is the reduced boundary samples redX[x] (x=0..boundarySize-1) and the upsampled boundary samples upsBdryX[x] (x=0..upsBdrySize-1).

[0242] The upsampling boundary samples upsBdryX[x] (x=0..upsBdrySize-1) are derived as follows: If -needUpsBdryX=TRUE and upsBdrySize is less than nTbX, the following applies: uDwn=nTbX / upsBdrySize (8-X30)

[0243]

number

[0244] - Otherwise (upsBdrySize=nTbX), set upsBdryX[x]=refX[x].

[0245] The reduced boundary samples redX[x] (x=0..boundarySize-1) are derived as follows: -boundarySize upBdrySize If it is less than nTbX, the following applies: bDwn=upsBdrySize nTbX / boundarySize (8-X32)

[0246]

number

[0247] -otherwise (boundarySize= upsBdrySize nTbX), redX[x] is upsBdryX[x] It is set equal to refX[x].

[0248] 5.4 An example In the upsampling process of ALWIP, different filtering stages derive predicted samples with different accuracies.

[0249] The following embodiment is based on the proposed test CE3-4.1_v2 of JVET-N0227.

[0250] 8.4.4.2.X4 Specification of the predictive upsampling process The inputs to this process are: - a variable predW that specifies the input block width, - a variable predH that specifies the height of the input block, - Affine linear weighted sample predLwip[x][y](x=0..predW-1,y=0..predH-1) and - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, - A variable upsBdryW that specifies the upsampling boundary width, - A variable upsBdryH that specifies the upsampling boundary height, - the upper upsampling boundary sample upsBdryT[x] (x=0..upsBdryW-1), - the left upsampling boundary sample upsBdryL[x] (x=0..upsBdryH-1), is. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1).

[0251] The sparse prediction samples predSamples[m][n] are derived from predLwip[x][y] (x=0..predW-1, y=0..predH-1) as follows: upHor=nTbW / predW (8-X34) upVer=nTbH / predH (8-X35) predSamples[(x+1)*upHor-1][(y+1)*upVer-1]=predLwip[x][y] (8-X36) The upper boundary samples upsBdryT[x] (x=0..upsBdryW-1) are assigned to predSamples[m][-1] as follows: predSamples[(x+1)*(nTbW / upsBdryW)-1][-1]=upsBdryT[x] (8-X37) The left boundary samples upsBdryL[y] (y=0..upsBdryH-1) are assigned to predSamples[-1][n] as follows: predSamples[-1][(y+1)*(nTbH / upsBdryH)-1]=upsBdryL[y] (8-X38) The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: If nTbH is greater than nTbW, the following steps are applied in order: 1. If upHor is greater than 1, all sparse positions (xHor, yHor) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=1..predH) are dX=1..upHor -1 is applied as follows: predSamples[xHor+dX][yHor]=((upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor]) / upHor (8-X39) 2. Vertical upsampling for all sparse positions (xVer, yVer) = (m, n*upVer-1) (m=0..nTbW-1, n=0..predH-1) is dY=1..upVer -1 is applied as follows: If yVer=-1, predSamples[xVer][yVer]=predSamples[xVer][yVer]< <log2(upHor) predSamples[xVer][yVer+dY]=((upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer]) / upVer +(1<<(log2(upHor)+log2(upVer)-1)))>>(log2(upHor)+log2(upVer)) (8-X40) - Otherwise, the following steps apply: 1. If upVer is greater than 1, (8-X40) As specified in (8-X41), the vertical upsampling for all sparse positions (xVer, yVer) = (m*upVer-1, n*Ver-1) (m=1..predW, n=0..predH-1) is dY=1..upVer -1 is applied. predSamples[xVer][yVer+dY]=((upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer]) (8-X41) 2. Horizontal upsampling for all sparse positions (xHor, yHor)=(m*upHor-1,n) (m=0..predW-1,n=0..nTbH-1) is dX=1..upHor -1 but (8-X39) As specified in As below Applies. If xHor=-1, predSamples[xHor][yHor]=predSamples[xHor][yHor]< <log2(upver) predSamples[xHor+dX][yHor]=((upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor]+(1<<(log2(upHor)+log2(upVer)-1)))>>(log2(upHor)+log2(upVer)) (8-X42)

[0252] 5.5 Example corresponding to Bullet 40 Let the block dimensions be W x H. Samples P(x,y) (x=Sx, Sx+Kx, Sx+2Kx, Sx+3Kx,..., y=Sy, Sy+Ky, Sy+2Ky, Sy+3Ky...) are input to the upsampling process to derive upsampled samples S(x,y) (x=0,1,2...W-1, y=0,1,2...H-1). Kx and Ky are the step sizes along the horizontal and vertical directions, respectively. (Sx,Sy) is the starting position.

[0253] Let 1-D upsampling be performed horizontally in the first stage and 1-D upsampling be performed vertically in the second stage.

[0254] In one example, the output result in the first stage without right shifting can be derived as follows: S'(Sx+Kx-1,Sy)=F1*P(Sx,Sy)+F2*P(Sx+Kx,Sy) S'(Sx+Kx-1,Sy+Ky)=F1*P(Sx,Sy+Ky)+F2*P(Sx+Kx,Sy+Ky) F1 and F2 are the coefficients of the 2-tap filter, F1+F2=2 N is.

[0255] Then, the output result of the second stage can be derived as follows: S'(Sx+Kx-1,Sy+1)=F3*S'(Sx+Kx-1,Sy)+F4*S'(Sx+Kx-1,Sy+Ky) F3 and F4 are the coefficients of the 2-tap filter, F3+F4=2 N is.

[0256] The final upsampled sample values ​​are then derived as follows: S(Sx+Kx-1,Sy+1)=Shift(S'(Sx+Kx-1,Sy+1),2N); S(Sx+Kx-1,Sy)=Shift(S'(Sx+Kx-1,Sy),N); S(Sx+Kx-1,Sy+Ky)=Shift(S'(Sx+Kx-1,Sy+Ky), N);

[0257] 5.6 An example The reduced boundary samples are derived in one step to generate the reference buffer for upsampling.

[0258] The following embodiment is based on the proposed test CE3-4.1_v2 of the adopted JVET-N0217.

[0259] 8.4.4.2.X1 Affine Linear Intra-Sample Prediction 8.4.4.2.X3 Boundary Reduction Process Specification ... The upsampling boundary samples upsBdryX[x] (x=0..upsBdrySize-1) are derived as follows: If -needUpsBdryX=TRUE and upsBdrySize is smaller than nTbX, the following applies: uDwn=nTbX / upsBdrySize (8-X30)

[0260]

number

[0261] - Otherwise (upsBdrySize=nTbX), set upsBdryX[x]=refX[x].

[0262] The reduced boundary samples redX[x] (x=0..boundarySize-1) are derived as follows: -boundarySize upBdrySize If it is less than nTbX, the following applies: bDwn= upsBdrySize nTbX / boundarySize (8-X32)

[0263]

number

[0264] -otherwise (boundarySize= upsBdrySize nTbX), redX[x] = upsBdryX[x].

[0265] 5.7 An example An example of fixed order upsampling for ALWIP (also known as matrix-based intra prediction or MIP) is presented here. The text is based on JVET-N1001-v6.

[0266] 5.7.1 Horizontal upsampling first, then vertical upsampling 8.4.5.2.1 Matrix-based intra-sample prediction The inputs to this process are: a sample position (xTbCmp, yTbCmp) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture; a variable predModeIntra that specifies the intra prediction mode; - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, is. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1).

[0267] The variables numModes, boundarySize, predW, predH, and predC are derived using MIPSizeId[xTbCmp][yTbCmp] as specified in Table 8-7.

[0268] [Table 15] Table 8-7: Specifications of the number of prediction modes numMode, boundary size boundarySize, prediction sizes predW, predH and predC using MipSizeId

[0269] The transposed flags are derived as follows: isTransposed=(predModeIntra>(numModes / 2))?TRUE:FALSE (8-52) The flags needUpsBdryHor and needUpsBdryVer are derived as follows: needUpsBdryHor=(nTbW>predW)?TRUE:FALSE (8-57) needUpsBdryVer=(nTbH>predH)?TRUE:FALSE (8-58)

[0270] The variables upsBdryW and upsBdryH are derived as follows: upsBdryW=(nTbH>nTbW)?nTbW:predW (8-59) upsBdryH=(nTbH>nTbW)?predH:nTbH (8-60) upsBdryW=nTbW (8-59) upsBdryH=predH (8-60)

[0271] The variables mipW and mipH are derived as follows: mipW=isTransposed?predH:predW (8-61) mipH=isTransposed?predW:predH (8-62)

[0272] To generate the reference samples refT[x] (x=0..nTbW-1) and refL[y] (y=0..nTbH-1), the MIP reference sample derivation process specified in Section 8.4.5.2.2 is called with the sample position (xTbCmp, yTbCmp), the transform block width nTbW, and the transform block height nTbH as inputs, and the top and left reference samples refT[x] (x=0..nTbW-1) and refL[y] (y=0..nTbH-1) as outputs.

[0273] For generation of boundary samples p[x] (x=0..2*boundarySize-1), the following applies: The MIP boundary downsampling process specified in clause 8.4.5.2.3 is called for the upper reference samples of block size nTbW with inputs reference samples refT[x] (x=0..nTbW-1), boundary size boundarySize, upsampling boundary flag needUpsBdryHor and upsampling boundary size upsByW, and output reduced boundary samples redT[x] (x=0..boundarySize-1) and upsampling boundary samples upsBdryT[x] (x=0..upsByW-1). The MIP boundary downsampling process specified in clause 8.4.5.2.3 is called for the left reference sample of block size nTbH with the reference samples refL[y] (y=0..nTbH-1), boundary size boundarySize, upsampling boundary flag needUpsBdryVer and upsampling boundary size upsByH as inputs, and with the reduced boundary samples redL[x] (x=0..boundarySize-1) and upsampling boundary samples upsBdryL[x] (x=0..upsByH-1) as outputs. The reduced upper and left boundary samples redT and redL are assigned to the boundary sample array p as follows:

[0274] If -isTransposed=1, set p[x]=redL[x](x=0..boundarySize-1) and set p[x+boundarySize]=redT[x](x=0..boundarySize-1).

[0275] - Otherwise, set p[x]=redT[x](x=0..boundarySize-1) and set p[x+boundarySize]=redL[x](x=0..boundarySize-1).

[0276] For the intra sample prediction process according to predModeIntra, the following ordered steps are applied: 3. Matrix-based intra prediction samples predmip[x][y] (x=0..mipW-1, y=0..mipH-1) are derived as follows: The variable modeId is derived as follows: modeId=predModeIntra-(isTransposed?numModes / 2:0) (8-63) -The weight matrix mWeight[x][y] (x=0..2*boundarySize-1, y=0..predC*predC-1) is derived using MipSizeId[xTbCmp][yTbCmp] and Table 8-XX [Ed.(BB): Add weight matrix after non-10-bit weight solution is adopted]. The bias vector vBias[y] (y=0..predC*predC-1) is derived using the sizeId and modeId specified in Table 8-XX [Ed.(BB): Bias vector added after non-10-bit weight solution is adopted]. The variable sW is derived using MipSizeId[xTbCmp][yTbCmp] and modeId as specified in Table 8-8. The matrix-based prediction samples predMIP[x][y] (x=0..mipW-1, y=0..mipH-1) are derived as follows: oW=1<<(sW-1) (8-64) sB=BitDepth Y -1 (8-65) incW=(predC>mipW)?2:1 (8-66) incH=(predC>mipH)?2:1 (8-67)

[0277]

number

[0278] 4. If isTransposed=TRUE, the predH×predW array predMip[x][y] (x=0..predH-1, y=0..predW-1) is transposed as follows: predTemp[y][x]=predMip[x][y] (8-69) predMip=predTemp (8-70) 5. The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: If -needUpsBdryVer=TRUE or needUpsBdryHor=TRUE, the MIP prediction upsampling process specified in Section 8.4.5.2.4 is called with the inputs input block width preW, input block height predH, matrix-based intra prediction samples predMip[x][y] (x=0..predW-1, y=0..predH-1), transform block width nTbW, transform block height nTbH, upsampling boundary width updryW, upsampling boundary height upsBdryH, upper upsampling boundary samples upsBdryT, and left upsampling boundary samples upsBdryL, and the output is the prediction sample array predSamples. - Otherwise, set predSamples[x][y](x=0..nTbW-1,y=0..nTbH-1)=predMip[x][y]. 6. Prediction samples predSamples[x][y](x=0..nTbW-1,y=0..nTbH-1) is clipped as follows: predSamples[x][y]=Clip1 Y (predSamples[x][y]) (8-71)

[0279] [Table 16] Table 8-8: Weight shift sW specifications according to MipSizeId and modeId

[0280] 8.4.5.2.4 MIP Prediction Upsampling Process The inputs to this process are: - a variable predW that specifies the input block width, - a variable predH that specifies the height of the input block, -Matrix-based prediction samples predMip[x][y] (x=0..predW-1, y=0..predH-1) and - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, - A variable upsBdryW that specifies the upsampling boundary width, - A variable upsBdryH that specifies the upsampling boundary height, - the upper upsampling boundary sample upsBdryT[x] (x=0..upsBdryW-1), - the left upsampling boundary sample upsBdryL[x] (x=0..upsBdryH-1), is. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1).

[0281] The sparse prediction samples predSamples[m][n] are derived from predMip[x][y] (x=0..predW-1, y=0..predH-1) as follows: upHor=nTbW / predW (8-78) upVer=nTbH / predH (8-79) predSamples[(x+1)*upHor-1][(y+1)*upVer-1]=predMip[x][y] (8-80) The upper boundary samples upsBdryT[x] (x=0..upsBdryW-1) are assigned to predSamples[m][-1] as follows: predSamples[(x+1)*(nTbW / upsBdryW)-1][-1]=upsBdryT[x] (8-81) The left boundary samples upsBdryL[y] (y=0..upsBdryH-1) are assigned to predSamples[-1][n] as follows: predSamples[-1][(y+1)*(nTbH / upsBdryH)-1]=upsBdryL[y] (8-82) The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: - If nTbH is greater than nTbW, the following steps are applied in order: 1. If upHor is greater than 1, then for all sparse positions (xHor, yHor) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=1..predH) the following is applied with dX=1..upHor-1: sum=(upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor] (8-83) predSamples[xHor+dX”[yHor]=(sum+upHor / 2-(sum<0?1: 0) / upHor (8-84) 2. Vertical upsampling for all sparse positions (xVer, yVer) = (m, n*upVer-1) (m = 0.. nTbW-1, n = 0.. predH-1) is applied with dY = 1.. upVer-1 as follows: sum=(upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer] (8-85) predSamples[xVer][yVer+dY]=(sum+upVer / 2-(sum<0?1:0)) / upVer (8-86) - Otherwise, the following steps apply in order: 1. If upVer is greater than 1, vertical upsampling for all sparse positions (xVer, yVer) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=0..predH-1) is applied with dY=1..upVer-1 as follows:

[0282] sum=(upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer] (8-87) predSamples[xVer][yVer+dY]=(sum+upVer / 2-(sum<0?1:0)) / upVer (8-88) 2. Horizontal upsampling for all sparse positions (xHor, yHor) = (m*upHor-1, n) (m = 0..predW-1, n = 0..nTbH-1) is applied with dY = 1..upHor-1 as follows:

[0283] sum=(upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor] (8-89) predSamples[xHor+dX][yHor]=(sum+upHor / 2-(sum<0?1:0)) / uPHor (8-90)

[0284] 5.7.2 Vertical upsampling first, then horizontal upsampling 8.4.5.2.1 Matrix-based intra-sample prediction The inputs to this process are: a sample position (xTbCmp, yTbCmp) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture; a variable predModeIntra that specifies the intra prediction mode; - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the height of the transformation block, is. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1).

[0285] The variables numModes, boundarySize, predW, predH, and predC are derived using MipSizeId[xTbCmp][yTbCmp] as specified in Table 8-7.

[0286] [Table 17] Table 8-7: Specifications for the number of prediction modes numMode, boundary size boundarySize, and prediction sizes predW, predH, and predC using MipSizeId

[0287] The flag isTransposed is derived as follows: isTransposed=(predModeIntra>(numModes / 2)) ?TRUE:FALSE (8-56)

[0288] The flags needUpsBdryHor and needUpsBdryVer are derived as follows: needUpsBdryHor = (nTbW > predW) ?TRUE:FALSE (8-57) needUpsBdryVer = (nTbH > predH) ?TRUE:FALSE (8-58)

[0289] The variables upsBdryW and upsBdryH are derived as follows: upsBdryW=(nTbH>nTbW)?nTbW:predW (8-59) upsBdryH=(nTbH>nTbW)?predH:nTbH (8-60) upsBdryW=predW (8-59) upsBdryH=nTbH (8-60)

[0290] The variables mipW and mipH are derived as follows: mipW=isTransposed?predH:predW (8-61) mipH=isTransposed?predW:predH (8-62)

[0291] To generate the reference samples refT[x] (x=0..nTbW-1) and refL[y] (y=0..nTbH-1), the MIP reference sample derivation process specified in Section 8.4.5.2.2 is called with the sample position (xTbCmp, yTbCmp), the transform block width nTbW, and the transform block height nTbH as inputs, and with the top reference samples refT[x] (x=0..nTbW-1) and the left reference samples refL[y] (y=0..nTbH-1) as outputs.

[0292] For generation of boundary samples p[x] (x=0..2*boundarySize-1), the following applies: The MIP boundary downsampling process specified in Section 8.4.5.2.3 is called for the upper reference sample with the block size nTbW, reference samples refT[x] (x=0..nTbW-1), boundary size boundarySize, upsampling boundary flag needUpsBdryHor, and upsampling boundary size upsBdryW as inputs, and with the reduced boundary samples redT[x] (x=0..boundySize-1) and upsampling boundary samples upBdryT[x] (x=0..upsBdryW-1) as outputs. The MIP boundary downsampling process specified in Section 8.4.5.2.3 is called for the left reference sample with the block size nTbH, reference sample refL[y] (y=0..nTbH-1), boundary size boundarySize, upsampling boundary flag needUpsBdryVer, and upsampling boundary size upsBdryH as inputs, and with the reduced boundary sample redL[x] (x=0..boundySize-1) and upsampling boundary sample upBdryL[x] (x=0..upsBdryH-1) as outputs. The reduced upper and left boundary samples redT and redL are assigned to the boundary sample array p as follows: If -isTransposed=1, set p[x]=redL[x](x=0..boundarySize-1) and set p[x+boundarySize]=redT[x](x=0..boundarySize-1). - Otherwise, set p[x] = redT[x](x=0..boundarySize-1) and p[x+boundarySize] = redL[x](x=0..boundarySize-1).

[0293] For the intra sample prediction process according to predModeIntra, the following ordered steps are applied:

[0294] 7. Matrix-based prediction samples predMip[x][y] (x=0..mipW-1, y=0..mipH-1) are derived as follows: The variable modeId is derived as follows:

[0295] modeId=predModeIntra-(isTransposed?numModes / 2:0) (8-63) -The weight matrix mWeight[x][y] (x=0..2*boundarySize-1, y=0..predC*predC-1) is derived using MipSizeId[xTbCmp][yTbCmp] and modeId as specified in Table 8-XX [Ed.(BB): Add weight matrix if non-10-bit weight solution is used]. The bias vector vBias[y] (y=0..predC*predC-1) is derived using the sizeId and modeId specified in Table 8-XX [Ed.(BB): Add bias vector if non-10-bit weight solution is adopted]. The variable sW is derived using MipSizeId[xTbCmp][yTbCmp] and modeId as specified in Table 8-8. -Matrix-based prediction samples predMip[x][y] (x=0..mipW-1, y=0..mipH-1) are derived as follows:

[0296] oW=1<<(sW-1) (8-64) sB=BitDepth Y -1 (8-65) incW=(predC>mipW)?2:1 (8-66) incH=(predC>mipH)?2:1 (8-67)

[0297]

number

[0298] 8. If isTransposed = TRUE, the predH x predW array predMip[x][y] (x=0..predH-1, y=0..predW-1) is transposed as follows: predTemp[y][x]=predMip[x][y] (8-69) predMip=predTemp (8-70)

[0299] 9. The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: If -needUpsBdryVer=TRUE or needUpsBdryHor=TRUE, the MIP prediction upsampling process specified in Section 8.4.5.2.4 is called with the input block width preW, input block height predH, matrix-based intra prediction samples predMip[x][y] (x=0..predW-1, y=0..predH-1), transform block width nTbW, transform block height nTbH, upsampling boundary width upBdryW, upsampling boundary height upsBdryH, upper upsampling boundary samples upsBdryT, and left upsampling boundary samples upsBdryL, and the output is the prediction sample array predSamples. - Otherwise, set predSamples[x][y](x=0..nTbW-1,y=0..nTbH-1) = predMip[x][y].

[0300] 10. The predicted samples predSamples[x][y](x=0..nTbW-1,y=0..nTbH-1) are clipped as follows: predSamples[x][y]=Clip1 Y (predSamples[x][y]) (8-71)

[0301] [Table 18] Table 8-8: Specifications of weight shift sW according to MipSizeId and modeId

[0302] 8.4.5.2.4 MIP Prediction Upsampling Process The inputs to this process are: - a variable predW that specifies the input block width, - a variable predH that specifies the height of the input block, -Matrix-based prediction samples predMip[x][y] (x=0..predW-1, y=0..predH-1) and - a variable nTbW that specifies the transform block width, - a variable nTbH that specifies the transformation block height, - A variable upsBdryW that specifies the upsampling boundary width, - A variable upsBdryH that specifies the upsampling boundary height, - the upper upsampling boundary sample upsBdryT[x] (x=0..upsBdryW-1), - the left upsampling boundary sample upsBdryL[x] (x=0..upsBdryH-1), is. The output of this process is the predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1).

[0303] The sparse prediction samples predSamples[m][n] are derived from predMip[x][y] (x=0..predW-1, y=0..predH-1) as follows: upHor=nTbW / predW (8-78) upVer=nTbH / predH (8-79) predSamples[(x+1)*upHor-1][(y+1)*upVer-1]=predMip[x][y] (8-80) The upper boundary samples upsBdryT[x] (x=0..upsBdryW-1) are assigned to predSamples[m][-1] as follows: predSamples[(x+1)*(nTbW / upsBdryW)-1][-1]=upsBdryT[x] (8-81) The left boundary samples upsBdryL[y] (y=0..upsBdryH-1) are assigned to predSamples[-1][n] as follows: predSamples[-1][(y+1)*(nTbH / upsBdryH)-1]=upsBdryL[y] (8-82) The predicted samples predSamples[x][y] (x=0..nTbW-1, y=0..nTbH-1) are derived as follows: - If nTbH is greater than nTbW, the following steps are applied in order:

[0304] 1. If upHor is greater than 1, then for all sparse positions (xHor, yHor) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=1..predH) the following is applied with dX=1..upHor-1: sum=(upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor] (8-83) predSamples[xHor+dX”[yHor]=(sum+upHor / 2-(sum<0?1: 0) / upHor (8-84) 2. Vertical upsampling for all sparse positions (xVer, yVer) = (m, n*upVer-1) (m = 0.. nTbW-1, n = 0.. predH-1) is applied with dY = 1.. upVer-1 as follows: sum=(upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer] (8-85) predSamples[xVer][yVer+dY]=(sum+upVer / 2-(sum<0?1:0)) / upVer (8-86) - Otherwise, the following steps apply in order:

[0305] 1. If upVer is greater than 1, vertical upsampling for all sparse positions (xVer, yVer) = (m*upHor-1, n*upVer-1) (m=0..predW-1, n=0..predH-1) is applied with dY=1..upVer-1 as follows:

[0306] sum=(upVer-dY)*predSamples[xVer][yVer]+dY*predSamples[xVer][yVer+upVer] (8-87) predSamples[xVer][yVer+dY]=(sum+upVer / 2-(sum<0?1:0)) / upVer (8-88) 2. Horizontal upsampling for all sparse positions (xHor, yHor)=(m*upHor-1,n) (m=0..predW-1,n=0..nTbH-1) is applied with dY=1..upHor-1 as follows:

[0307] sum=(upHor-dX)*predSamples[xHor][yHor]+dX*predSamples[xHor+upHor][yHor] (8-89) predSamples[xHor+dX][yHor]=(sum+upHor / 2-(sum<0?1:0)) / uPHor (8-90)

[0308] 5.8 Example working draft based on JVET-N1001-v7 for MPM coding 8.4.2 MIP Mode Derivation Process The inputs to this process are: a luma position (xCb, yCb) specifying the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, is.

[0309] In this process, a matrix-based intra prediction mode IntraPredModeY[xCb][yCb] is derived by the following steps in order:

[0310] 5. The neighboring positions (xNbA, yNbA) and (xNbB, yNbB) are set equal to (xCb-1, yCb) and (xCb, yCb-1), respectively.

[0311] 6. For X to be replaced by A or B, the variable candMIPModeX is derived as follows: The availability derivation process for the block specified in Section 6.4.X [Ed.(BB): Adjacent Block Availability Check Process tbd] is invoked with inputs of position (xCurr, yCur) set equal to (xCb, yCb) and adjacent position (xNbY, yNbY) set equal to (xNbX, yNbX), and the output is assigned to availableX. The MIP mode candidate candMIPModeX is derived as follows. - If one or more of the following conditions are true, set candMIPModeX=-1: - If variable availableX=FALSE. - When -CuPredMode[xNbX][yNbX] is not equal to MODE_INTRA and ciip_flag[xNbX][yNbX] is not equal to 1. - When pcm_flag[xNbX][yNbX] = 1. - When X = B and yCb-1 is less than ((yCb >> CtbLog2SizeY) << CtbLog2SizeY). - Otherwise, the following applies. - When intra_MIP_flag[xNbX][yNbX] = 1, the following applies. - When MIPSizeId[xCb][yCb] = MipSizeId[xNbX][yNbX], candMipModeX is set to IntraPredModeY[xNbX][yNbX]. - Otherwise, candMipModeX is set to -1. - Otherwise, candMipModeX is derived using IntraPredModeY[xNbX][yNbX] and MipSizeId[xCb][yCb] specified in Table 8-4.

[0312] 7. candMipModeList[x] (x=0..2) is derived as follows using mipMpmCand[sizeId] specified in Table 8-2.

[0313] - When both candMipModeA and candMipModeB are = -1, the following applies. candMipModeList[0]=mipMpmCand[sizeId][0] (8-10) candMipModeList[1]=mipMpmCand[sizeId][1] (8-11) candMipModeList[2]=mipMpmCand[sizeId][2] (8-12)

[0314] - Otherwise, the following applies. - When candMipModeA = candMipModeB or either candMipModeA or candMipModeB is = -1, the following applies. candMipModeList[0]=(candMipModeA!=-1)?candMipModeA:candMipModeB (8-13) - candMipModeList[0]=mipMpmCand[sizeId][0] If , the following applies: candMipModeList[1]=mipMpmCand[sizeId][1] (8-14) candMipModeList[2]=mipMpmCand[sizeId][2] (8-15) - Otherwise, the following applies. candMipModeList[1]=mipMpmCand[sizeId][0] (8-16) candMipModeList[2]=(candMipModeList[0]!=mipMpmCand[sizeId][1])? mipMpmCand[sizeId][1]:mipMpmCand[sizeId][2] (8-17) - Otherwise, the following applies. candMipModeList[0]=candMipModeA (8-18) candMipModeList[1]=candMipModeB (8-19) -If both candMipModeA and candMipModeB are not equal to MipMpmCand[sizeId][0], the following applies: candMipModeList[2]=mipMpmCand[sizeId][0] (8-20) - Otherwise, the following applies: -If both candMipModeA and candMipModeB are not equal to mipMpmCand[sizeId][1], the following applies: candMipModeList[2]=mipMpmCand[sizeId][1] (8-21) - Otherwise, the following applies: candMipModeList[2]=mipMpmCand[sizeId][2] (8-22)

[0315] 8. IntraPredModeY[xCb][yCb] is derived by applying the following procedure: -When intra_mip_mpm_flag[xCb][yCb]=1, IntraPredModeY[xCb][yCb]=candMipModeList[intra_mip_mpm_idx[xCb][yCb]] is set. Otherwise, IntraPredModeY[xCb][yCb] is derived by applying the following steps in order: 3. If candMipModeList[i] is greater than candMIPModeList[j] for i=0..1 and for each i,j=(i+1)..2, then both values ​​are swapped as follows: (candMipModeList[i],candMipModeList[j])=Swap(candMipModeList[i],candMipModeList[j]) (8-23) 4. IntraPredModeY[xCb][yCb] is derived by the following steps in order: i. IntraPredModeY[xCb][yCb]=intra_mip_mpm_remainder[xCb][yCb] is set. ii. When i=0 to 2, if IntraPredModeY[xCb][yCb] is equal to or greater than candMipModeList[i], the value of IntraPredModeY[xCb][yCb] is incremented by 1. The variable IntraPredModeY[x][y] (x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1) is set equal to IntraPredModeY[xCb][yCb].

[0316] FIG. 27 shows an updated table for the specification of mapping between intra-prediction modes and MIP modes.

[0317] [Table 19] Table 8-2: MIP candidate mode MipMpmCand[sizeId][x] specifications

[0318] i. Derivation process for luma intra prediction mode The inputs to this process are: a luma position (xCb, yCb) that specifies the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, is.

[0319] In this process, the luma intra-prediction mode IntraPredModeY[xCb][yCb] is derived. Table 8-3 specifies the values ​​and associated names of the intra-prediction mode IntraPredModeY[xCb][yCb].

[0320] [Table 20] Table 8-3: Intra prediction mode and associated name specifications

[0321] IntraPredModeY[xCb][yCb] is derived as follows: - If BdpcmFlag[xCb][yCb]=1 or intra_luma_not_planar_flag[xCb][yCb]=0, IntraPredModeY[xCb][yCb]=INTRA_PLANAR is set. - Otherwise (when intra_luma_not_planar_flag[xCb][yCb] = 1), the steps in the following order are applied. 9. The adjacent positions (xNbA, yNbA) and (xNbB, yNbB) are set equal to (xCb - 1, yCb + cbHeight - 1) and (xCb + cbWidth - 1, yCb - 1), respectively. 10. For the case of X that can be replaced by either A or B, the variable candIntraPredModeX is derived as follows. - 6.4. The availability derivation process for the block defined in item X [Ed.(BB): Adjacent block availability confirmation process tbd] is called with the position (xCurr, yCurr) set equal to (xCb, yCb) and the adjacent position (xNbY, yNbY) set equal to (xNbX, yNbX), and the output is assigned to availableX. - The intra prediction mode candidate candIntraPredModeX is derived as follows. - If one or more of the following conditions are true, candIntraPredModeX is set to INTRA_PLANAR. - When the variable availableX = FALSE. - When CuPredMode[xNbX][yNbX] is not equal to MODE_INTRA and ciip_flag[xNbX][yNbX] is not equal to 1. - When pcm_flag[xNbX][yNbX] = 1. - When X = B and yCb - 1 is less than ((yCb >> CtbLog2SizeY) << CtbLog2SizeY). - When intra_mip_flag[xCb][yCb] = 1. - Otherwise, candIntraPredModeX is derived as follows. -If intra_mip_flag[xCb][yCb]=1, candIntraPredModeX is derived using IntraPredModeY[xNbX][yNbX] and MipSizeId[xCb][yCb] as specified in Table 8-4. - Otherwise , candIntraPredModeX is set to IntraPredModeY[xNbX][yNbX]. 11. candModeList[x](x=0..4) is derived as follows: - If candIntraPredModeB=candIntraPredModeA and candIntraPredModeA is greater than INTRA_DC, candModeList[x] (x=0..4) is derived as follows: candModeList[0]=candIntraPredModeA (8-24) candModeList[1]=2+((candIntraPredModeA+61)%64) (8-25) candModeList[2]=2+((candIntraPredModeA-1)%64) (8-26) candModeList[3]=INTRA_DC (8-27) candModeList[4]=2+((candIntraPredModeA+60)%64) (8-28) - Else, if candIntraPredModeB is not equal to candIntraPredModeA and candIntraPredModeA or candIntraPredModeB is greater than INTRA_DC, then the following applies: The variables minAB and maxAB are derived as follows: minAB=Min(candIntraPredModeA,candIntraPredModeB) (8-29) maxAB=Max(candIntraPredModeA, candIntraPredModeB) (8-30) If both candIntraPredModeA and candIntraPredModeB are greater than INTRA_DC, candModeList[x] (x=0..4) is derived as follows: candModeList[0]=candIntraPredModeA (8-31) candModeList[1]=candIntraPredModeB (8-32) candModeList[2]=INTRA_DC (8-33) If -maxAB-minAB is in the range 2 to 62, the following applies: candModeList[3]=2+((maxAB+61)%64) (8-34) candModeList[4]=2+((maxAB-1)%64) (8-35) - Otherwise, the following applies: candModeList[3]=2+((maxAB+60)%64) (8-36) candModeList[4]=2+((maxAB)%64) (8-37) Otherwise (if candIntraPredModeA or candIntraPredModeB is greater than INTRA_DC), candModeList[x] (x=0..4) is derived as follows: candModeList[0]=maxAB (8-38) candModeList[1]=INTRA_DC (8-39) candModeList[2]=2+((maxAB+61)%64) (8-40) candModeList[3]=2+((maxAB-1)%64) (8-41) candModeList[4]=2+((maxAB+60)%64) (8-42) - Otherwise, the following applies: candModeList[0]=INTRA_DC (8-43) candModeList[1]=INTRA_ANGULAR50 (8-44) candModeList[1]=INTRA_ANGULAR18 (8-45) candModeList[1]=INTRA_ANGULAR46 (8-46) candModeList[1]=INTRA_ANGULAR54 (8-47) 12. IntraPredModeY[xCb][yCb] is derived by applying the following procedure: -If intra_luma_mpm_flag[xCb][yCb]=1, IntraPredModeY[xCb][yCb]=candModeList[intra_luma_mpm_idx[xCb][yCb]] is set. Otherwise, IntraPredModeY[xCb][yCb] is derived by applying the following steps in order: 5. If candModeList[i] is greater than candModeList[j] for i=0..3 and for each i,j=(i+1)..4, then both values ​​are swapped as follows: (candModeList[i],candModeList[j])=Swap(candModeList[i],candModeList[j]) (8-48) 6. IntraPredModeY[xCb][yCb] is derived by the following steps in order: i. IntraPredModeY[xCb][yCb]=intra_luma_mpm_remainder[xCb][yCb] is set. ii. The value of IntraPredModeY[xCb][yCb] is incremented by 1. iii. When i=0 to 4 and IntraPredModeY[xCb][yCb] is equal to or greater than candModeList[i], the value of IntraPredModeY[xCb][yCb] is incremented by 1.

[0322] The variable IntraPredModeY[x][y] (x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1) is set to IntraPredModeY[xCb][yCb].

[0323] FIG. 28 shows an updated table for the specification of mapping between MIP modes and intra prediction modes.

[0324] 8.4.4 Derivation Process for Chroma Intra Prediction Modes The inputs to this process are: a luma position (xCb, yCb) that specifies the top-left sample of the current chroma coding block relative to the top-left luma sample of the current picture; - a variable cbWidth that specifies the width of the current coding block in luma samples; - a variable cbHeight that specifies the height of the current coding block in luma samples, is.

[0325] In this process, a chrominance intra-prediction mode IntraPredModeC[xCb][yCb] is derived. The corresponding luma intra-prediction mode lumaIntraPredMode is derived as follows:

[0326] -If intra_mip_flag[xCb+cbWidth / 2][yCb+cbHeight / 2] =1, lumaIntraPredMode is Derived using IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2] and sizeId as specified in Table 8-4 Set equal to INTRA_PLANAR , the value of candIntraPredModeX is assigned to lumaIntraPredMode .

[0327] - Otherwise, set lumaIntraPredMode=IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2].

[0328] The chrominance intra prediction mode IntraPredModeC[xCb][yCb] is derived using intra_chroma_pred_mode[xCb][yCb] and lumaIntraPredMode specified in Table 8-5 and Table 8-6.

[0329] 5.9 Implementation of signaling lfnst_idx in case of dual tree chroma The following modifications are based on JVET_P2001_v9. Modifications are indicated by highlighted text in bold italics.

[0330] 7.3.9.5 Coding Unit Syntax

[0331] [Table 21] TIFF0007803913000081.tif247168TIFF0007803913000082.tif199167TIFF0007803913000083.tif131169

[0332] 7.4.10.5 Coding Unit Semantics ...

[0333] intra_mip_flag[x0][y0] equal to 1 specifies that the intra prediction type for the luma sample is matrix-based intra prediction. intra_mip_flag[x0][y0] equal to 0 specifies that the intra prediction type for the luma sample is not matrix-based intra prediction.

[0334] If intra_mip_flag[x0][y0] is not present in the SINGLE_TREE or DUAL_TREE_LUMA cases, it is inferred to be equal to 0.

[0335] The above examples may be incorporated into the context of the methods described below, such as methods 1100, 1200, 1300, 1400, 2300 and / or 2400, which may be implemented in a video encoder and / or decoder.

[0336] 11 shows a flowchart of an example method for video processing. The method 1100 includes, at step 1110, determining that a current video block is coded using affine linear weighted intra prediction (ALWIP) mode.

[0337] At step 1120, the method 1100 includes, based on the determining, constructing at least a portion of a Most Probable Mode (MPM) list for the ALWIP mode based at least a portion of the MPM list for the non-ALWIP intra mode.

[0338] At step 1130, the method 1100 includes converting between the current video block and a bitstream representation of the current video block based on the MPM list for the ALWIP mode.

[0339] In some embodiments, the size of the MPM list for ALWIP mode is the same as the size of the MPM list for non-ALWIP intra mode. In an example, the size of the MPM list for ALWIP mode is 6.

[0340] In some embodiments, method 1100 further includes inserting a default mode into the MPM list for the ALWIP mode. In one example, the default mode is inserted before a portion of the MPM list for the ALWIP mode that is based on the MPM list for the non-ALWIP intra mode. In another example, the default mode is inserted after a portion of the MPM list for the ALWIP mode that is based on the MPM list for the non-ALWIP intra mode. In yet another example, the default mode is inserted alternately with a portion of the MPM list for the ALWIP mode that is based on the MPM list for the non-ALWIP intra mode.

[0341] In some embodiments, the construction of the MPM list for ALWIP mode and the MPM list for non-ALWIP intra mode is based on one or more neighboring blocks.

[0342] In some embodiments, the construction of the MPM list for ALWIP mode and the MPM list for non-ALWIP intra mode is based on the height or width of the current video block.

[0343] In some embodiments, construction of the MPM list for the ALWIP mode is based on a first parameter set, which is different from a second parameter set used to construct the MPM list for the non-ALWIP intra mode.

[0344] In some embodiments, the method 1100 further includes determining that a neighboring block of the current video block is coded in ALWIP mode and designating the neighboring block as unavailable when constructing the MPM list for non-ALWIP intra mode.

[0345] In some embodiments, the method 1100 further includes determining that a neighboring block of the current video block is coded in a non-ALWIP intra mode and designating the neighboring block as unavailable when constructing the MPM list for the ALWIP mode.

[0346] In some embodiments, the non-ALWIP intra mode is based on a normal intra mode, a multiple reference line (MRL) intra prediction mode, or an intra sub-partition (ISP) tool.

[0347] 12 shows a flowchart of an example method for video processing. The method 1200 includes, at step 1210, determining that the luma component of a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode.

[0348] The method 1200 includes, at step 1220, inferring a chroma intra mode based on the determining.

[0349] At step 1230, the method 1200 includes converting between the current video block and a bitstream representation of the current video block based on a chroma intra mode.

[0350] In some embodiments, the luma component covers a predetermined chroma sample of the chroma component, in one example, the predetermined chroma sample is the top-left sample or the center sample of the chroma component.

[0351] In some embodiments, the inferred chroma intra mode is a DM mode.

[0352] In some embodiments, the inferred chroma intra mode is an ALWIP mode.

[0353] In some embodiments, the ALWIP mode is applied to one or more chroma components of the current video block.

[0354] In some embodiments, different matrices or bias vectors in ALWIP mode are applied to different color components of the current video block. In one example, different matrices or bias vectors are jointly defined for the Cb and Cr components. In another example, the Cb and Cr components are concatenated. In yet another example, the Cb and Cr components are interleaved.

[0355] 13 shows a flowchart of an example method for video processing. The method 1300 includes, at step 1310, determining that a current video block is coded using an affine linear weighted intra prediction mode (ALWIP).

[0356] At step 1320, method 1300 includes converting between the current video block and a bitstream representation of the current video block based on the determining.

[0357] In some embodiments, the determining is based on signaling in a sequence parameter set (SPS), a picture parameter set (PPS), a slice header, a tile group header, a tile header, a coding tree unit (CTU) row or a CTU region.

[0358] In some embodiments, the determination is based on the height (H) or width (W) of the current video block. In one example, W > T1 or H > T2. In another example, W ≥ T1 or H ≥ T2. In yet another example, W < T1 or H < T2. In yet another example, W ≤ T1 or H ≤ T2. In yet another example, T1 = 32 and T2 = 32.

[0359] In some embodiments, the determination is based on the height (H) or width (W) of the current video block. In one example, W + H ≤ T. In another example, W + H ≥ T. In yet another example, W × H ≤ T. In yet another example, W × H ≥ T. In yet another example, T = 256.

[0360] FIG. 14 shows a flowchart of an exemplary method for video processing. This method 1400 includes, at step 1410, determining that the current video block is encoded using a coding mode different from the affine linear weighted intra prediction (ALWIP) mode.

[0361] Method 1400 includes, at step 1420, performing a conversion between the current video block and the bitstream representation of the current video block based on the determination.

[0362] In some embodiments, the coding mode is a combined intra- and inter-prediction mode (CIIP), and method 1400 further includes selecting between the ALWIP mode and a normal intra-prediction mode. In one example, making the selection is based on explicit signaling in a bitstream representation of the current video block. In another example, making the selection is based on a predetermined rule. In yet another example, the predetermined rule always selects the ALWIP mode if the current video block is coded using a CIIP mode. In yet another example, the predetermined rule always selects the normal intra-prediction mode if the current video block is coded using a CIIP mode.

[0363] In some embodiments, the coding mode is a cross-component linear model (CCLM) prediction mode. In one example, the downsampling procedure for the ALWIP mode is based on the downsampling procedure for the CCLM prediction mode. In another example, the downsampling procedure for the ALWIP mode is based on a first parameter set, and the downsampling procedure for the CCLM prediction mode is based on a second parameter set different from the first parameter set. In yet another example, the downsampling procedure for the ALWIP mode or the CCLM prediction mode includes at least one of selecting a downsampling position, selecting a downsampling filter, a rounding operation, or a clipping operation.

[0364] In some embodiments, the method 1400 further includes applying one or more of a reduction quadratic transformation (RST), a quadratic transformation, a rotation transformation, or a non-separable quadratic transformation (NSST).

[0365] In some embodiments, the method 1400 further includes applying block-based differential pulse coded modulation (DPCM) or residual DPCM.

[0366] In some embodiments, a video processing method includes determining a context of a flag indicating use of an affine linear weighted intra-prediction (ALWIP) mode during conversion between the current video block and a bitstream representation of the current video block based on a rule for the current video block, predicting a plurality of sub-blocks of the current video block based on the ALWIP mode, and converting between the current video block and the bitstream representation of the current video block based on the prediction. The rule may be implicitly specified using a priori techniques or may be signaled in a coded bitstream. Other examples and aspects of this method are further described in Section 4, items 37 and 38.

[0367] In some embodiments, a method for video processing includes determining that a current video block is coded using an affine linear weighted intra prediction (ALWIP) mode, and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during a conversion between the current video block and a bitstream representation of the current video block, wherein a first precision of the samples in a first filtering stage of the at least two filtering stages is different from a second precision of the samples in a second filtering stage of the at least two filtering stages.

[0368] In one example, the samples of the current video block are predicted samples, intermediate samples before the upsampling process, or intermediate samples after the upsampling process. In another example, the samples are upsampled in a first dimension horizontally in a first filtering stage, and the samples are upsampled in a second dimension vertically in a second filtering stage. In yet another example, the samples are upsampled in a first dimension vertically in a first filtering stage, and the samples are upsampled in a second dimension horizontally in a second filtering stage.

[0369] In one example, the output of the first filtering stage is right-shifted or divided to produce a processed output, which is the input to the second filtering stage. In another example, the output of the first filtering stage is left-shifted or multiplied to produce a processed output, which is the input to the second filtering stage. Other examples and aspects of this method are further described in Section 4, item 40.

[0370] As further described in Section 4, items 41-43, a video processing method includes determining that a current video block is coded using an affine linear weighted intra-prediction (ALWIP) mode, and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during a conversion between the current video block and a bitstream representation of the current video block, the upsampling process being performed in a fixed order when both vertical and horizontal upsampling is performed. As further described in Section 4, items 41-43, another method includes determining that a current video block is coded using an affine linear weighted intra-prediction (ALWIP) mode, and performing at least two filtering stages on samples of the current video block in an upsampling process associated with the ALWIP mode during a conversion between the current video block and a bitstream representation of the current video block, the conversion including performing a transposition operation before the upsampling process.

[0371] Further features of the above method are described in Section 4, items 41-43.

[0372] In some embodiments, a method of video processing includes determining, for a conversion between a current video block of a video and a bitstream representation of the video, that signaling of use of a secondary transform in the conversion is decoupled from signaling of a luma matrix-based intra-prediction (MIP) tool due to the current video block satisfying a condition, and performing the conversion based on the determining. Additional example features are described in item 49 in the previous section.

[0373] In some embodiments, a video processing method includes determining, based on a coding condition associated with a current video block of the video, whether side information associated with a secondary transform is included in a bitstream representation of the video, and converting between the current video block and the bitstream representation based on the determining. Additional features and examples are described in items 50 and 51 in the previous section.

[0374] 6. ILLUSTRATIVE EMBODIMENTS OF THE DISCLOSED TECHNOLOGY FIG. 15 is a block diagram of a video processing device 1500. The device 1500 may be used to implement one or more of the methods described herein. The device 1500 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, etc. The device 1500 may include one or more processors 1502, one or more memories 1504, and video processing hardware 1506. The processor 1502 may be configured to implement one or more of the methods described herein (including, but not limited to, methods 1100, 1200, 1300, 1400, 2300, and / or 2400). The memory(s) 1504 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 1506 is a hardware circuit and may be used to implement some of the techniques described herein.

[0375] In some embodiments, the video coding method may be performed using an apparatus implemented on the hardware platform described with respect to FIG.

[0376] Some embodiments of the disclosed techniques include making a decision or determination to enable a video processing tool or mode. In one example, if a video processing tool or mode is enabled, an encoder uses or implements the tool or mode in processing blocks of video, but may not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, conversion of blocks of video to a bitstream representation of video uses the video processing tool or mode if enabled based on the decision or determination. In another example, if a video processing tool or mode is enabled, a decoder processes the bitstream with the knowledge that the bitstream has been modified based on the video processing tool or mode. That is, conversion of a bitstream representation of video to blocks of video occurs using the video processing tool or mode that is enabled based on the decision or determination.

[0377] Some embodiments of the disclosed techniques include making a decision or determination to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, an encoder does not use the tool or mode in converting blocks of video into a bitstream representation of the video. In another example, when a video processing tool or mode is disabled, a decoder processes the bitstream with the knowledge that the bitstream has not been modified using the video processing tool or mode that was disabled based on the decision or determination.

[0378] Figure 21 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure. As shown in Figure 21, video coding system 100 may include a source device 110 and a destination device 120. Source device 110 generates encoded video data and may be referred to as a video encoding device. Destination device 120 decodes the encoded video data generated by source device 110 and may be referred to as a video decoding device. Source device 110 may include a video source 112, a video encoder 114, and an input / output (I / O) interface 116.

[0379] The video source 112 may include a source such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system for generating video data, or a combination of such sources. The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming a coded representation of the video data. The bitstream may include coded pictures and associated data. A coded picture is a coded representation of a picture. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The encoded video data may be transmitted directly to the destination device 120 via the I / O interface 116 over the network 130a. The encoded video data may also be stored on a storage medium / server 130b for access by the destination device 120.

[0380] The destination device 120 may include an I / O interface 126 , a video decoder 124 , and a display device 122 .

[0381] I / O interface 126 may include a receiver and / or a modem. I / O interface 126 may obtain encoded video data from source device 110 or storage medium / server 130b. Video decoder 124 may decode the encoded video data. Display device 122 may display the decoded video data to a user. Display device 122 may be integrated with destination device 120 or may be external to destination device 120 configured to interact with an external display device.

[0382] Video encoder 114 and video decoder 124 may operate according to a video compression standard, such as the High Efficiency Video Coding (HEVC) standard, the Versatile Video Coding (VVC) standard, and other current and / or future standards.

[0383] FIG. 22 is a block diagram illustrating an example of a video encoder 200, which may be video encoder 114 in system 100 shown in FIG.

[0384] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 22, video encoder 200 includes multiple functional components. The techniques described in this disclosure may be shared among various components of video encoder 200. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0385] The functional components of the video encoder 200 may include a division unit 201, a prediction unit 202, which may include a mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205, and an intra prediction unit 206, a residual generation unit 207, a transform unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transform unit 211, a reconstruction unit 212, a buffer 213, and an entropy encoding unit 214.

[0386] In other examples, video encoder 200 may include more, fewer, or different functional components. In one example, prediction unit 202 may include an intra block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode in which at least one reference picture is the picture in which the current video block is located.

[0387] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, may be highly integrated, but are depicted separately in the example of FIG. 22 for illustrative purposes.

[0388] Partition unit 201 may divide a picture into one or more video blocks. Video encoder 200 and video decoder 300 may support a variety of video block sizes.

[0389] The mode select unit 203 selects one of the coding modes (intra or inter) based on, for example, an error result, and provides the resulting intra- or inter-coded block to the residual generation unit 207 to generate residual block data and to the reconstruction unit 212 to reconstruct an encoded block for use as a reference picture. In some examples, the mode select unit 203 may select a combination of intra- and inter-prediction (CIIP) modes, in which prediction is based on an inter-prediction signal and an intra-prediction signal. The mode select unit 203 may also select the resolution of the motion vector for the block (e.g., sub-pixel or integer-pixel precision) in the case of inter-prediction.

[0390] To perform inter prediction on the current video block, motion estimation unit 204 may generate motion information for the current video block by comparing one or more reference frames from buffer 213 with the current video block. Motion compensation unit 205 may identify a prediction video block for the current video block based on the motion information and decoded samples of pictures from buffer 213 other than the picture associated with the current video block.

[0391] Motion estimation unit 204 and motion compensation unit 205 may perform different operations on the current video block depending on whether the current video block is in an I slice, a P slice, or a B slice, for example.

[0392] In some examples, motion estimation unit 204 may perform unidirectional prediction on the current video block, and motion estimation unit 204 may search reference pictures of list 0 or list 1 for a reference video block for the current video block. Motion estimation unit 204 may then generate a reference index indicating a reference picture in list 0 or list 1, including the reference video block and a motion vector indicating a spatial displacement between the current video block and the reference video block. Motion estimation unit 204 may output the reference index, prediction direction indicator, and motion vector as motion information for the current video block. Motion compensation unit 205 may generate a predictive video block for the current block based on the reference video block indicated by the motion information of the current video block.

[0393] In other examples, motion estimation unit 204 may perform bidirectional prediction for the current video block, where motion estimation unit 204 may search reference pictures in list 0 for a reference video block for the current video block and search reference pictures in list 1 for another reference video block for the current video block. Motion estimation unit 204 may then generate reference indexes indicating the reference pictures in lists 0 and 1, each including a reference video block and a motion vector indicating a spatial displacement between the reference video block and the current video block. Motion estimation unit 204 may output the reference index and the motion vector for the current video block as motion information for the current video block. Motion compensation unit 205 may generate a predictive video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0394] In some examples, the motion estimation unit 204 may output a complete set of motion information for the decoding process of the decoder.

[0395] In some examples, motion estimation unit 204 may not output a complete set of motion information for the current video. Rather, motion estimation unit 204 may signal the motion information of the current video block with reference to motion information of other video blocks. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.

[0396] In one example, motion estimation unit 204 may indicate, in a syntax structure associated with the current video block, a value that indicates to video decoder 300 that the current video block has the same motion information as another video block.

[0397] In another example, motion estimation unit 204 may identify another video block and a motion vector difference (MVD) in a syntax structure associated with the current video block. The motion vector difference indicates the difference between the motion vector of the current video block and the motion vector of the indicated video block. Video decoder 300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0398] As mentioned above, video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by video encoder 200 include advanced motion vector prediction (AMVP) and merge mode signaling.

[0399] Intra prediction unit 206 may perform intra prediction on the current video block. When intra prediction unit 206 performs intra prediction on the current video block, intra prediction unit 206 may generate predictive data for the current video block based on decoded samples of other video blocks within the same picture. The predictive data for the current video block may include a predicted video block and various syntax elements.

[0400] Residual generation unit 207 may generate residual data for the current video block by subtracting (e.g., indicated by a minus sign) the predicted video block of the current video block from the current video block. The residual data for the current video block may include residual video blocks that correspond to different sample components of the samples in the current video block.

[0401] In other examples, for example in skip mode, residual data may not exist for the current video block, and residual generation unit 207 may not perform the subtraction operation.

[0402] Transform processing unit 208 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video block associated with the current video block.

[0403] After transform processing unit 208 generates a transform coefficient video block associated with the current video block, quantization unit 209 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0404] Inverse quantization unit 210 and inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct a residual video block from the transform coefficient video block. Reconstruction unit 212 may add the reconstructed residual video block to corresponding samples from one or more predicted video blocks generated by prediction unit 202 to generate a reconstructed video block related to the current block for storage in buffer 213.

[0405] After reconstruction unit 212 reconstructs the video blocks, a loop filter operation may be performed to reduce video blocking artifacts in the video blocks.

[0406] Entropy encoding unit 214 may receive data from other functional components of video encoder 200. Once entropy encoding unit 214 receives the data, entropy encoding unit 214 may perform one or more entropy encoding operations to generate entropy encoded data and output a bitstream including the entropy encoded data.

[0407] FIG. 19 is a block diagram illustrating an example of a video decoder 300, which may be the video decoder 114 in the system 100 shown in FIG.

[0408] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 19, video decoder 300 includes multiple functional components. The techniques described in this disclosure may be shared among various components of video decoder 300. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0409] 19, video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. Video decoder 300 may, in some examples, perform a decoding path that is generally the reverse of the encoding path described with respect to video encoder 200 (FIG. 22).

[0410] The entropy decoding unit 301 may read an encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 decodes the entropy-coded video data, and from the entropy-decoded video data, the motion compensation unit 302 may determine motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 302 may determine such information by, for example, implementing AMVP and merge mode.

[0411] The motion compensation unit 302 generates motion-compensated blocks and may optionally perform interpolation based on an interpolation filter. Identifiers for interpolation filters to be used with sub-pixel accuracy may be included in syntax elements.

[0412] Motion compensation unit 302 may calculate interpolated values ​​for sub-integer pixels of the reference block using interpolation filters used by video encoder 200 during coding of the video block. Motion compensation unit 302 may determine the interpolation filters used by video encoder 200 according to received syntax information and use the interpolation filters to generate the predictive block.

[0413] The motion compensation unit 302 may use some of the syntax information to determine the size of the blocks used to encode the frames and / or slices of the encoded video sequence, partition information describing how each macroblock of a picture of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-encoded block, and other information for decoding the encoded video sequence.

[0414] The intra prediction unit 303 may form a prediction block from spatially adjacent blocks, for example, using an intra prediction mode received in the bitstream. The inverse quantization unit 303 inverse quantizes, or dequantizes, the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 303 applies an inverse transform.

[0415] Reconstruction unit 306 may sum the residual block with a corresponding prediction block generated by motion compensation unit 202 or intra prediction unit 303 to form a decoded block. Optionally, a deblocking filter may also be applied to filter the decoded block to remove blockiness artifacts. The decoded video block is then stored in buffer 307, which provides reference blocks for subsequent motion compensation and also generates decoded video for presentation on a display device.

[0416] 20 is a block diagram illustrating an example video processing system 2000 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 2000. System 2000 may include an input 2002 for receiving video content. The video content may be received in raw or uncompressed format, e.g., 8- or 10-bit multi-component pixel values, or may be received in compressed or coded format. Input 2002 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, passive optical network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0417] System 2000 may include a coding component 2414 that may implement various coding or encoding methods described herein. The coding component 2414 may reduce the average bitrate of the video from the input 2002 to the output of the coding component 2004 to generate a coded representation of the video. Thus, coding techniques are sometimes referred to as video compression or video transcoding techniques. The output of the coding component 2414 may be stored or transmitted over a communication connection, as represented by component 2006. The stored or communicated bitstream (or coded) representation of the video received at the input 2002 may be used by component 2418 to generate displayable video or pixel values ​​sent to the display interface 2010. The process of generating user-viewable video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although certain video processing operations are referred to as “coding” operations or tools, it will be understood that the coding tools or operations are used in an encoder and that corresponding decoding tools or operations that reverse the results of the coding will occur in a decoder.

[0418] Examples of peripheral bus interfaces or display interfaces include Universal Serial Bus (USB) or High-Definition Multimedia Interface (HDMI®) or DisplayPort, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), PCI, IDE interfaces, etc. The techniques described herein may be embodied in a variety of electronic devices such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[0419] In some embodiments, ALWIP mode or MIP mode is used to calculate a predictive block for a current video block by performing a boundary downsampling operation (or averaging operation) on previously coded samples of the video, followed by a matrix-vector multiplication operation, and optionally (or optionally) an upsampling operation (or linear interpolation operation). In some embodiments, ALWIP mode or MIP mode is used to calculate a predictive block for a current video block by performing a boundary downsampling operation (or averaging operation) on previously coded samples of the video, followed by a matrix-vector multiplication operation. In some embodiments, ALWIP mode or MIP mode can also perform an upsampling operation (or linear interpolation operation) after the matrix-vector multiplication operation.

[0420] 23 shows an example flowchart of yet another example method 2300 for matrix-based intra prediction in accordance with the disclosed techniques. Operation 2302 includes generating a most probable mode list for a matrix-based intra prediction (MIP) tool based on rules for converting between a current video block of a video including a plurality of video blocks and a bitstream representation of the video, the MIP tool including, during the conversion, identifying a prediction block for the current video block by performing a boundary downsampling operation, followed by a matrix-vector multiplication operation, followed by a selective upsampling operation, on previously coded samples of the video, the rules specifying a mapping between a number of MIP modes and dimensions of the plurality of video blocks. Operation 2304 includes performing the conversion based on the generating.

[0421] In some embodiments of method 2300, the rule specifies that the number of MIP modes is the same for blocks of different dimensions. In some embodiments of method 2300, the number of MIP modes is equal to 11. In some embodiments of method 2300, the rule specifies that in response to a dimension identifier of the current video block being equal to zero, the MPM list includes {10, 5, 1}. In some embodiments of method 2300, the rule specifies that in response to a dimension identifier of the current video block being equal to 1, the MPM list includes {9, 7, 1}. In some embodiments of method 2300, the rule specifies that in response to a dimension identifier of the current video block being equal to 2, the MPM list includes {6, 1, 8}. In some embodiments of method 2300, the rule specifies that the MPM list of the current video block is the same as another MPM list of an adjacent video block.

[0422] 24 shows an example flowchart of yet another example method 2400 for matrix-based intra prediction in accordance with the disclosed techniques. Operation 2402 includes converting between chroma video blocks of a video and a bitstream representation of the video using side information of a secondary transform tool that is applied to the chroma video blocks based on rules, where the secondary transform tool, if applied based on the rules, includes applying a forward secondary transform to an output of a forward primary transform applied to a residual of the chroma video blocks prior to quantization during encoding or applying an inverse secondary transform to an output of a dequantization of the chroma video blocks before applying an inverse primary transform during decoding, where the manner in which the side information is coded in the bitstream representation is independent of the coding mode of the corresponding luma video block.

[0423] In some embodiments of method 2400, the coding mode includes a matrix-based intra-prediction (MIP) mode in which a prediction block of a corresponding luma video block is determined by performing a boundary downsampling operation on previously coded samples of the video, followed by a matrix-vector multiplication operation, followed by a selective upsampling operation. In some embodiments of method 2400, the secondary transform tool includes a low-frequency non-separable transform (LFNST) tool. In some embodiments of method 2400, the rule specifies that whether the secondary transform tool is applied to a chroma video block is independent of the coding mode of the corresponding luma video block. In some embodiments of method 2400, the rule specifies that the secondary transform tool is applied to a chroma video block if the corresponding luma video block is coded in the coding mode. In some embodiments of method 2400, the chroma video block is in a dual tree structure or a local dual tree structure.

[0424] In some embodiments of method 2400, the rules specify that if the chroma video block is in a dual-tree structure, whether the LFNST tool is applied to the chroma video block does not depend on whether the corresponding luma video block is coded in a matrix-based intra-prediction (MIP) coding mode. In some embodiments of method 2400, the rules specify that whether the LFNST tool is applied to the chroma video block does not depend on whether the chroma video block has dimensions greater than or equal to M×N, where M and N are integers. In some embodiments of method 2400, M=16 and N=16. In some embodiments of method 2400, the chroma video block is in a dual-tree structure, and the rules specify that whether the LFNST tool is applied to the chroma video block does not depend on whether the chroma video block is coded in a coding mode. In some embodiments of method 2400, the coding mode is disabled for the chroma video block.

[0425] In some embodiments of method 2400, the chroma video blocks are in a dual tree structure, and the signaling of the index of the LFNST tool in the bitstream representation is independent of the signaling of a syntax element indicating whether the corresponding luma video block is coded in the coding mode. In some embodiments of method 2400, the corresponding luma video blocks are in a single tree structure or a dual tree structure, and the rules specify that whether the LFNST tool is applied to the chroma video block depends on whether the corresponding luma video block is coded in the coding mode. In some embodiments of method 2400, the signaling of the index of the LFNST tool in the bitstream representation depends on the dimensions of the corresponding luma video block coded in the coding mode.

[0426] In some embodiments of method 2400, an index of an LFNST tool is signaled in the bitstream representation in response to the chroma video block not being in a dual tree structure, the corresponding luma video block being coded in a coding mode, and the corresponding luma video block having a minimum width or height of 16 pixels or greater. In some embodiments of method 2400, whether the bitstream representation includes side information is based on a tree type associated with the chroma video block. In some embodiments of method 2400, whether the bitstream representation includes side information is based on the chroma video block being in a dual tree structure. In some embodiments of method 2400, the dual tree structure includes a local dual tree structure. In some embodiments of method 2400, the dual tree structure excludes a local dual tree structure.

[0427] In some embodiments of method 2400, condition A being true is defined as the coding mode not being applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool being greater than or equal to the integer N, condition B being true is defined as the current video block being a chroma video block and the chroma video block being within a dual tree structure or a local dual tree structure, and whether condition A is used to determine whether to apply the LFNST tool to the chroma video block depends on condition B. In some embodiments of method 2400, if condition B is true, condition A is not used to determine whether the LFNST tool is applied to the chroma video block. In some embodiments of method 2400, if condition B is not true, the LFNST tool is not applied to the chroma video block in response to condition A not being true. In some embodiments of method 2400, condition A being true is defined as a coding mode not being applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool being greater than or equal to an integer N; condition B being true is defined as a chroma video block being within a dual tree structure or a local dual tree structure; and whether condition A is used to determine whether all or part of the information regarding the LFNST tool is signaled in the bitstream representation depends on condition B. In some embodiments of method 2400, if condition B is true, condition A is not used to determine whether to apply the LFNST tool to the chroma video block. In some embodiments of method 2400, if condition B is not true, the LFNST tool is not applied to the chroma video block corresponding to condition A not being true.In an embodiment of method 2400, condition A being true is defined as no coding mode is applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool are greater than or equal to an integer N, condition B being true is defined as the current video block is a chroma video block and the chroma video block is within a dual tree structure or a local dual tree structure, and whether condition A is used to determine whether to signal all or part of the information about the LFNST tool in the bitstream representation depends on condition B.

[0428] In some embodiments of method 2400, if condition B is true, then condition A is not used to determine whether to signal all or some of the information related to the LFNST tool in the bitstream representation. In some embodiments of method 2400, if condition B is not true, then all or some of the information related to the LFNST tool is not signaled in the bitstream representation, corresponding to condition A not being true. In some embodiments of method 2400, condition A being true is defined as the coding mode not being applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool being greater than or equal to an integer N, condition B being true is defined as the current video block being a chroma video block and the chroma video block being in a dual tree structure or a local dual tree structure, and condition C being true is defined as the current video block being a luma video block and the luma video block being in a dual tree structure or a local dual tree structure, and whether condition A is used to determine whether the LFNST tool is applied to the chroma video block depends on condition C.

[0429] In some embodiments of method 2400, if condition C is not true, then condition A is not used to determine whether the LFNST tool is applied to the chroma video block. In some embodiments of method 2400, if condition B is not true, then the LFNST tool is not applied to the chroma video block, corresponding to condition A not being true. In some embodiments of method 2400, condition A being true is defined as a coding mode not being applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool being greater than or equal to an integer N, condition B being true is defined as the current video block being a chroma video block and the chroma video block being in a dual tree structure or a local dual tree structure, and condition C being true is defined as the current video block being a luma video block and the luma video block being in a dual tree structure or a local dual tree structure, and whether condition A is used to determine whether to signal all or part of the information related to the LFNST tool in the bitstream representation depends on condition C.

[0430] In some embodiments of method 2400, if condition C is not true, then condition A is not used to determine whether to signal all or part of the information regarding the LFNST tool in the bitstream representation. In some embodiments of method 2400, if condition B is not true, then all or part of the information regarding the LFNST tool is not signaled in the bitstream representation, corresponding to condition A not being true. In some embodiments of method 2400, condition A being true is defined as the coding mode not being applied to the corresponding luma video block and the width and height of the chroma video block considered by the LFNST tool being greater than or equal to an integer N, and in the case of a single tree structure, condition A is only used to determine whether the LFNST tool is applied to the corresponding luma video block.

[0431] In some embodiments of method 2400, corresponding to condition A not being true, the LFNST tool is not applied to the corresponding luma video block, the LFNST tool is applied to the chroma video block, or the LFNST tool is applicable to the chroma video block. In some embodiments of method 2400, all or some of the information related to the LFNST tool is signaled in the bitstream representation to control whether and / or how the LFNST tool is applied to the chroma video block. In some embodiments of method 2400, the encoding or decoding of the side information of the secondary transform tool is classified based on color component. In some embodiments of method 2400, individual pieces of side information are encoded or decoded for each color component. In some embodiments of method 2400, the color components include a luma component, a blue-difference chroma component, and a red-difference chroma component. In some embodiments of method 2400, the individual pieces of side information for one color component differ from that of another color component.

[0432] In some embodiments of method 2400, the blue-difference chroma component and the red-difference chroma component share the same additional side information of the coding mode. In some embodiments of method 2400, first individual side information of the side information is encoded or decoded for the luma component, and second individual side information of the side information is encoded or decoded for multiple chroma components. In some embodiments of method 2400, the first individual side information of the side information for the luma component is different from the second individual side information of the side information for the multiple chroma components. In some embodiments of method 2400, performing the conversion further includes encoding or decoding additional side information of the coding mode classified based on a color component. In some embodiments of method 2400, individual side information of the additional side information is encoded or decoded for each color component. In some embodiments of method 2400, the color components include a luma component, a blue-difference chroma component, and a red-difference chroma component. In some embodiments of method 2400, the individual additional side information for one color component is different from that for another color component. In some embodiments of the method 2400, the blue difference chroma component and the red difference chroma component share the same separate side information for the coding mode.

[0433] In some embodiments of method 2400, a first individual side information of the other side information is encoded or decoded for the luma component, and a second individual side information of the other side information is encoded or decoded for the multiple chroma components. In some embodiments of method 2400, the first individual side information of the side information for the luma component is different from the second individual side information of the side information for the multiple chroma components. In some embodiments of method 2300 and / or 2400, the converting includes decoding the bitstream representation to generate a chroma video block or the current video block. In some embodiments of method 2300 and / or 2400, the converting includes encoding the video to generate the bitstream representation.

[0434] From the foregoing, it will be understood that, although specific embodiments of the disclosed technology have been described herein for purposes of illustration, various modifications can be made without departing from the scope of the disclosed technology. Accordingly, the disclosed technology is not limited except as by the appended claims.

[0435] Implementations of the subject matter and functional operations described herein can be embodied in various systems, digital electronic circuits, or computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or one or more combinations thereof. Implementations of the subject matter described herein can be embodied as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-transitory computer-readable medium for execution by or to control the operation of a data processing apparatus. A computer-readable medium can be a machine-readable storage device, a machine-readable storage carrier, a memory device, a composition of matter bearing a machine-readable propagated signal, or one or more combinations thereof. The term "data processing unit" or "data processing apparatus" encompasses all apparatus, devices, and machines that process data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, an apparatus can include code that creates an execution environment for the computer program in question, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof.

[0436] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a single file dedicated to the program in question or in multiple coordinated files (e.g., a file storing one or more modules, subprograms, or portions of code), or in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communications network.

[0437] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may be implemented as, special purpose logic circuitry, such as a Field Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC).

[0438] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices, e.g., magnetic, optical, or magnetic disks, for storing data, or be operatively coupled to receive data from and / or transfer data to such one or more mass storage devices. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include, by way of example, all types of non-volatile memory, media, and memory devices, including semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices. The processor and memory may be enhanced by, or incorporated in, dedicated logic circuitry.

[0439] This specification, together with the drawings, are intended to be considered exemplary only, and by exemplary I mean by example. As used herein, the use of "or" is intended to include "and / or" unless expressly stated otherwise.

[0440] While this specification contains numerous details, these should not be construed as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features that are described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while features may be described above as operating in a particular combination, and even initially claimed as such, one or more features from a claimed combination may in some cases be deleted from that combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0441] Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown, or in a sequential order, or that all of the depicted operations be performed, to achieve desired results. Further, the separation of various system components in the embodiments described herein should not be understood as requiring such separation in all embodiments.

[0442] Only a few implementations and examples have been described; other implementations, enhancements, and variations may be made based on what is described and illustrated herein.< / end> < / end> < / begin> < / end> < / begin> < / end> < / begin> < / end> < / begin> < / end> < / begin>

Claims

1. 1. A method of video processing, comprising: determining whether first side information related to a secondary conversion tool is included in the bitstream for conversion between a current chroma block of a video and the bitstream of the video by checking whether one or more conditions are met; performing said converting based at least on said identifying; Including, the secondary transform tool includes applying a forward secondary transform during encoding to an output of a forward linear transform applied to a residual of the video block prior to quantization, or applying an inverse secondary transform during decoding to an output of an inverse quantization of the video block prior to applying an inverse linear transform; determining whether the one or more conditions are met includes determining whether a tree type of the current chroma block is dual tree chroma; the first side information is a syntax element indicating an LFNST index; corresponding to the tree type of the current chroma block not being dual-tree chroma, checking whether the one or more conditions are satisfied includes checking whether a coding mode of the corresponding luma block is a first coding mode or checking whether both a block width and a block height considered by an LFNST are greater than or equal to 16; The method, wherein in the first coding mode, the prediction block of the corresponding luma block is identified by performing a boundary downsampling operation, followed by a matrix-vector multiplication operation, and then, optionally, an upsampling operation.

2. 2. The method of claim 1 , wherein, corresponding to a tree type of the current chroma block being dual-tree chroma, whether the first side information is included in the bitstream for the current chroma block is decoupled from whether the coding mode of the corresponding luma block is the first coding mode.

3. 2. The method of claim 1, wherein whether the first side information is included in the bitstream for the current chroma block is decoupled from the block width and the block height considered by LFNST, corresponding to the tree type of the current chroma block being dual-tree chroma.

4. The method of claim 1 , wherein the tree type of the current chroma block is dual-tree chroma, corresponding to the current chroma block being in a dual-tree structure or a local dual-tree structure.

5. The method of claim 1 , wherein the transforming comprises encoding the current chroma block into the bitstream.

6. The method of claim 1 , wherein the transforming comprises decoding the current chroma block from the bitstream.

7. 1. An apparatus for processing video data, comprising: a processor; and a non-transitory memory having instructions that, when executed by the processor, cause the processor to: determining whether first side information related to a secondary conversion tool is included in the bitstream for conversion between a current chroma block of a video and the bitstream of the video by checking whether one or more conditions are met; performing said converting based at least on said identifying; Let them do this, the secondary transform tool includes applying a forward secondary transform during encoding to an output of a forward linear transform applied to a residual of the video block prior to quantization, or applying an inverse secondary transform during decoding to an output of an inverse quantization of the video block prior to applying an inverse linear transform; determining whether the one or more conditions are met includes determining whether a tree type of the current chroma block is dual tree chroma; the first side information is a syntax element indicating an LFNST index; corresponding to the tree type of the current chroma block not being dual-tree chroma, checking whether the one or more conditions are satisfied includes checking whether a coding mode of the corresponding luma block is a first coding mode or checking whether both a block width and a block height considered by an LFNST are greater than or equal to 16; In the first coding mode, the prediction block of the corresponding luma block is identified by performing a boundary downsampling operation, followed by a matrix-vector multiplication operation, and then, optionally, an upsampling operation.

8. A non-transitory computer-readable storage medium storing instructions that cause a processor to: determining whether first side information related to a secondary conversion tool is included in the bitstream for conversion between a current chroma block of a video and the bitstream of the video by checking whether one or more conditions are met; performing said converting based at least on said identifying; Let them do this, the secondary transform tool includes applying a forward secondary transform during encoding to an output of a forward linear transform applied to a residual of the video block prior to quantization, or applying an inverse secondary transform during decoding to an output of an inverse quantization of the video block prior to applying an inverse linear transform; determining whether the one or more conditions are met includes determining whether a tree type of the current chroma block is dual tree chroma; the first side information is a syntax element indicating an LFNST index; corresponding to the tree type of the current chroma block not being dual-tree chroma, checking whether the one or more conditions are satisfied includes checking whether a coding mode of the corresponding luma block is a first coding mode or checking whether both a block width and a block height considered by an LFNST are greater than or equal to 16; a non-transitory computer-readable storage medium, wherein in the first coding mode, a prediction block of the corresponding luma block is identified by performing a boundary downsampling operation, followed by a matrix-vector multiplication operation, and then, optionally, an upsampling operation.

9. 1. A method for storing a video bitstream, the method comprising: determining, for a current chroma block of a video, whether first side information related to a secondary transformation tool is included in the bitstream for the current chroma block by checking whether one or more conditions are met; generating the bitstream based at least on said identifying; storing the bitstream on a non-transitory computer-readable storage medium; Including, the secondary transform tool includes applying a forward secondary transform during encoding to an output of a forward linear transform applied to a residual of the video block prior to quantization, or applying an inverse secondary transform during decoding to an output of an inverse quantization of the video block prior to applying an inverse linear transform; determining whether the one or more conditions are met includes determining whether a tree type of the current chroma block is dual tree chroma; the first side information is a syntax element indicating an LFNST index; corresponding to the tree type of the current chroma block not being dual-tree chroma, checking whether the one or more conditions are satisfied includes checking whether a coding mode of the corresponding luma block is a first coding mode or checking whether both a block width and a block height considered by an LFNST are greater than or equal to 16; The method, wherein in the first coding mode, the prediction block of the corresponding luma block is identified by performing a boundary downsampling operation, followed by a matrix-vector multiplication operation, and then, optionally, an upsampling operation.

Images