Derivation of linear parameters in cross-component video coding.

Abstract

To provide a video processing method for use by a video or image decoder or encoder to perform encoding or decoding using cross-component linear model prediction.SOLUTION: A method includes deriving a parameter of a cross-component linear model, and performing the transformation by using a predicted chroma block generated using the cross-component linear model by using a downsampled luminance sample generated from N (positive integer) upper neighboring lines of the juxtaposed luminance block of the chroma block by using a downsampling filter to convert between the video's chroma blocks and the video's bitstream representation.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS Under applicable patent laws and / or regulations under the Paris Convention, this application is intended to timely claim priority to and the benefit of International Patent Application No. PCT / CN2019 / 115034, filed November 1, 2019. For all purposes under law, the entire disclosure of the above application is incorporated by reference as part of the disclosure of this application.

[0002] This application relates to video and image encoding and decoding techniques. [Background technology]

[0003] Digital video accounts for the largest bandwidth usage on the Internet and other digital communications networks, and the bandwidth demands for digital video use are expected to continue to grow as the number of connected user devices capable of receiving and displaying video increases. Summary of the Invention

[0004] The disclosed techniques may be used by embodiments of a video or image decoder or encoder to encode or decode using cross-component linear model prediction.

[0005] In one exemplary aspect, a method for processing video is disclosed that includes deriving parameters of a cross-component linear model by using downsampled luma samples generated from a positive integer number N of upper neighboring lines of a juxtaposed luma block of the chroma block using a downsampling filter for conversion between a chroma block of the video and a bitstream representation of the video, and performing the conversion using a predicted chroma block generated using the cross-component linear model.

[0006] In another exemplary aspect, a method for processing video is disclosed that includes determining a maximum allowable block size for video blocks coded using transform skip mode for conversion between a video domain of a component of the video and a bitstream representation of the video, and performing the conversion based on the determination.

[0007] In another exemplary aspect, a method of processing video is disclosed, the method including converting between video including a video block and a bitstream representation of the video according to first and second rules, using a transform skip coding tool for coding a first portion of the video block and using a transform coding tool for coding a second portion of the video block, the first rule specifying a maximum allowed block size for the first portion of the video block and the second rule specifying a maximum allowed block size for the second portion of the video block, the maximum allowed block size for the first portion of the video block being different from the maximum allowed block size for the second portion of the video block.

[0008] In another exemplary aspect, a method for processing video is disclosed that includes converting between video that includes one or more blocks and a bitstream representation of the video, where the bitstream representation complies with a format rule that specifies that whether a syntax element indicating use of a transform skip tool is included in the bitstream representation depends on a maximum allowable size of a chroma block coded using the transform skip tool.

[0009] In another exemplary aspect, a method for processing video is disclosed. The method includes converting between video including one or more first video blocks of a first chroma component and one or more second video blocks of a second chroma component and a bitstream representation of the video, where the bitstream representation conforms to format rules that specify use of syntax elements that together indicate availability of a transform skip tool for coding the one or more first chroma blocks and the one or more second chroma blocks.

[0010] In another exemplary aspect, the above-described methods may be implemented by a video encoder including a processing device.

[0011] In yet another exemplary aspect, the methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.

[0012] These and other aspects are further described herein. [Brief explanation of the drawings]

[0013] [Figure 1A] Indicates the nominal vertical and horizontal positions of 4:2:2 luma and chroma samples in the picture. [Figure 1B] An example of a video encoder is shown. [Figure 2] 67 examples of intra prediction modes are shown. [Figure 3] 1 shows examples of horizontal and vertical traverse scans. [Figure 4] An example of the sample positions used to derive α and β is shown below. [Figure 5] An example is shown in which one 4x8 sample block is divided into two independently decodable regions. [Figure 6] 1 shows an exemplary order for processing rows of pixels to maximize throughput for a 4xN block with a vertical prediction module. [Figure 7]An example of the low frequency non-separable transform (LFNST) process is shown. [Figure 8] 10 shows an example of neighboring chroma samples and downsampled collocated neighboring luma samples used to derive CCLM parameters for 4:2:2 video. [Figure 9] 1 shows an example of a video processing device. [Figure 10] 1 shows a block diagram of an exemplary video encoder. [Figure 11] 1 is a flowchart illustrating an example of a video processing method according to some implementations of the disclosed technology. [Figure 12] FIG. 1 is a block diagram illustrating an example of a video processing system. [Figure 13] 1 is a block diagram illustrating an example video coding system. [Figure 14] FIG. 1 is a block diagram illustrating an encoder in accordance with some embodiments of the disclosed techniques. [Figure 15] FIG. 2 is a block diagram illustrating a decoder in accordance with some embodiments of the disclosed techniques. [Figure 16A] 1 is a flowchart illustrating an example of video processing according to some implementations of the disclosed technology. [Figure 16B] 1 is a flowchart illustrating an example of video processing according to some implementations of the disclosed technology. DETAILED DESCRIPTION OF THE INVENTION

[0014] This specification provides various techniques that can be used by a decoder of an image or video bitstream to improve the quality of decompressed or decoded digital video or images. For simplicity, the term "video" is used herein to include both a series of pictures (conventionally called video) and individual images. Furthermore, a video encoder may implement these techniques during the encoding process to reconstruct decoded frames for use in further encoding.

[0015] Section headings are used herein for ease of understanding and are not intended to limit embodiments disclosed in one section to only that section, and thus embodiments in one section may be combined with embodiments in other sections.

[0016] 1. Summary of the invention The present invention relates to video coding techniques. Specifically, the present invention relates to cross-component linear model prediction and other coding tools in image / video coding. The present invention may be applied to existing video coding standards such as HEVC or to finalize standards (Versatile Video Coding). The present invention may also be applied to future video coding standards or video codecs.

[0017] 2. Introduction of video coding Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, while ISO / IEC created MPEG-1 and MPEG-4 Visual, and the two organizations jointly developed the H.262 / MPEG-2 Video, H.264 / MPEG-4 AVC (Advanced Video Coding), and H.265 / HEVC standards. Since H.262, video coding standards have been based on hybrid video coding structures that utilize temporal prediction and transform coding. To explore future video coding technologies beyond HEVC, the International Standard for Video Coding (ISC) was established in 2015. In 2015, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET). Since then, many new methods have been adopted by JVET and incorporated into reference software called JEM (Joint Exploration Mode). In April 2018, the Joint Video Expert Team (JVET) was established between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG), and is working on formulating the VVC standard with the goal of achieving a 50% bitrate reduction compared to HEVC.

[0018] 2.1. Color Space and Chroma Subsampling A color space, also known as a color model (or color system), is an abstract mathematical model that simply describes a range of colors as a tuple of numbers, typically three or four values ​​or color components (e.g., RGB). Essentially, a color space is a combination of a coordinate system and a subspace.

[0019] For video compression, the most frequently used color spaces are YCbCr and RGB.

[0020] YCbCr, Y'CbCr, or Y Pb / Cb Pr / Cr, also known as YCBCR or Y'CBCR, is a family of color spaces used as part of the color image pipeline in video and digital photography systems. Y' is the luma component, and CB and CR are the blue-difference and red-difference chroma components. Y' (with a prime number) is distinguished from Y, which is luma, by the fact that light intensity is coded nonlinearly based on gamma-corrected RGB primaries.

[0021] Chroma subsampling is a method of encoding images by implementing chrominance information at a lower resolution than luminance information, taking advantage of the fact that the human visual system perceives color differences less than luminance.

[0022] 2.1.1. 4:4:4 Each of the three Y'CbCr components has the same sample rate, so there is no chroma subsampling. This method is sometimes used in high-end film scanners and cinema post-production.

[0023] 2.1.2. 4:2:2 The two chroma components are sampled at half the luma sample rate, halving the horizontal chroma resolution while leaving the vertical chroma resolution unchanged. This reduces the bandwidth of the uncompressed video signal by a factor of three with little or no visible difference. An example of the nominal vertical and horizontal positions of the 4:2:2 color format is shown, for example, in Figure 1A of the VVC Working Draft.

[0024] 2.1.3. 4:2:0 In 4:2:0, horizontal sampling is doubled compared to 4:1:1, but the vertical resolution is halved because this scheme samples the Cb and Cr channels only on every other line. Thus, the data rate is the same. Cb and Cr are each subsampled by a factor of two in both the horizontal and vertical directions. There are three variants of the 4:2:0 scheme, with different horizontal and vertical positions: ● In MPEG-2, Cb and Cr are co-located in the horizontal direction. Cb and Cr are located between pixels in the vertical direction (located between the lattices). In JPEG / JFIF, H.261, and MPEG-1, Cb and Cr are located between the middle grid of alternating luminance samples. ● In 4:2:0 DV, Cb and Cr are horizontally co-located. Vertically, they alternately co-locate.

[0025] [Table 1]

[0026] 2.2. Typical video codec coding flow FIG. 1B shows an example of a VVC encoder block diagram, including three in-loop filtering blocks: a deblocking filter (DF), a sample adaptive offset (SAO), and an ALF. Unlike DF (which uses a predefined filter), SAO and ALF utilize the original samples of the current picture and reduce the mean square error between the original and reconstructed samples by adding an offset and applying a finite impulse response (FIR) filter, respectively, using coded side information to signal the offset and filter coefficients. The ALF is located at the last processing stage of each picture and can be considered a tool that attempts to capture and correct artifacts generated in previous stages.

[0027] 2.3. Intra-mode coding with 67 intra-prediction modes To capture any edge direction represented in natural video, the number of directional intra modes, as used in HEVC, is expanded from 33 to 65. The additional directional modes are indicated by the 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.

[0028] The traditional angular intra prediction direction is specified from 45 degrees to -135 degrees clockwise, as shown in Figure 2. In VTM, some traditional angular intra prediction modes are adaptively replaced with wide-angle intra prediction modes for non-square blocks. The replaced modes are signaled using the original method and, after parsing, are remapped to the wide-angle mode index. The total number of intra prediction modes remains unchanged, i.e., 67, and the coding of the intra modes remains unchanged.

[0029] In HEVC, all intra-coded blocks have a square shape, and the length of each side is a power of two. Thus, no division operation is required to generate an intra predictor using DC mode. In VVC, blocks may be rectangular, and in the general case, it is necessary to use a division operation for each block. To avoid division operations for DC prediction, only the long side is used to calculate the average of non-square blocks. Figure 2 shows examples of 67 intra prediction modes.

[0030] 2.4. Inter Prediction For each inter-predicted CU, motion parameters consisting of a motion vector, a reference picture index, and a reference picture list usage index, as well as additional information required for the new coding features of VVC, are used to generate inter-predicted samples. The motion parameters may be signaled explicitly or implicitly. When a CU is coded in skip mode, it is associated with one PU and has no significant residual coefficients, coding motion vector deltas, or reference picture indexes. A merge mode is specified, which obtains motion parameters for the current CU, including spatial and temporal candidates and the additional schedule introduced in VVC, from neighboring CUs. The merge mode can be applied to any inter-predicted CU, not just skip mode. An alternative to the merge mode is to explicitly transmit motion parameters, whereby the motion vector, the reference picture index corresponding to each reference picture list and reference picture list usage flag, and other necessary information are explicitly signaled for each CU.

[0031] 2.5. Intra-Block Copy (IBC) Intra Block Copy (IBC) is a tool adopted in the HEVC extension of SCC. It is known to significantly improve the coding efficiency of screen content material. Since IBC mode is implemented as a block-level coding mode, block matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to a reference block already reconstructed within the current picture. The luma block vectors of IBC-coded CUs are integer-precision. The chroma block vectors are also rounded to integer precision. When combined with AMVR, IBC mode can switch between 1-pixel and 4-pixel motion vector precision. IBC-coded CUs are treated as a third prediction mode other than intra or inter prediction modes. IBC mode is applicable to CUs whose width and height are both 64 luma samples or less.

[0032] On the encoder side, we perform hash-based motion estimation for IBC. The encoder performs RD checks on blocks with width or height less than 16 luma samples. In non-merge mode, we first perform block vector lookup using hash-based search. If the hash search does not return valid candidates, we perform local search-based block matching.

[0033] In hash-based search, the hash key matching (32-bit CRC) between the current block and the reference block is expanded to all allowed block sizes. The calculation of hash keys for all positions in the current picture is based on 4x4 sub-blocks. If the size of the current block is larger, the hash key is determined to match that of the reference block if all hash keys of all 4x4 sub-blocks match the hash key of the corresponding reference position. If the hash keys of multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matching reference block is calculated and the one with the minimum cost is selected. In block matching search, the search range is set to cover both the previous CTU and the current CTU. At the CU level, IBC mode is signaled by a flag and can be signaled as IBC AMVP mode or IBC skip / merge mode as follows:

[0034] IBC Skip / Merge Mode: The merge candidate index is used to indicate which block vector in the list from neighboring candidate IBC coded blocks to use to predict the current block. The merge list consists of spatial candidates, HMVP candidates, and pairwise candidates.

[0035] - IBC AMVP mode: Block vector differences are coded similarly to motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the upper neighbor (if IBC coded). If either neighbor is not available, a default block vector is used as the predictor. A flag is signaled to indicate the block vector predictor index.

[0036] 2.6.Palette Mode For palette mode signaling, the palette mode is coded as the prediction mode for the coding unit, i.e., the prediction mode for the coding unit may be MODE_INTRA, MODE_INTER, MODE_IBC, or MODE_PLT. When palette mode is used, pixel values ​​in a CU are represented by a small set of representative color values. The set is called the palette. For pixels with values ​​close to the colors in the palette, a palette index is signaled. For pixels with values ​​outside the palette, the pixel is represented by an escape symbol and the quantized pixel value is signaled directly.

[0037] To decode a palette-coded block, the decoder needs to decode the palette colors and indices. The palette colors are described in a palette table and are coded by a palette table coding tool. An escape flag is signaled for each CU to indicate whether an escape symbol exists in the current CU. If an escape symbol exists, the palette table is incremented by one and the last index is assigned to the escape mode. The palette indices of all pixels in a CU form a palette index map and are coded by a palette index map coding tool.

[0038] To code the palette table, a palette predictor is maintained. The predictor is initialized at the beginning of each slice, where the predictor is reset to 0. For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette. The reuse flag is transmitted using run-length coding of zeros. After this, the number of new palette entries is signaled using an Exponential-Golomb code of degree 0. Finally, the component values ​​of the new palette entry are signaled. After encoding the current CU, the palette predictor is updated using the current palette, and entries from the previous palette predictor that are not reused in the current palette are added to the end of the new palette predictor until the maximum allowed size is reached (palette stuffing).

[0039] To code a palette index map, the indices are coded using horizontal and vertical transverse scans as shown in Figure 3. The palette_transpose_flag is used to explicitly signal the scan order in the bitstream.

[0040] FIG. 3 shows an example of horizontal and vertical traverse scanning.

[0041] The palette index is coded using the two main palette sample modes: 'INDEX' and 'COPY_ABOVE'. This mode is signaled using the top row excluded flag if horizontal scanning is used, the first column excluded flag if vertical scanning is used, or a flag if the previous mode was 'COPY_ABOVE'. 'COPY_ABOVE' mode copies the palette index of the sample in the row above. In 'INDEX' mode, the palette index is signaled explicitly. For both 'INDEX' and 'COPY_ABOVE' modes, a run value is signaled that specifies the number of pixels to be coded using the same mode.

[0042] The coding order for the index map is as follows: First, the number of index values ​​for the CU is signaled. Following this, the actual index value for the entire CU is signaled using truncated binary coding. In bypass mode, both the number of indices and the index value are coded, which groups index-related bypass bins. Next, the palette mode (INDEX or COPY_ABOVE) and run are signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape samples for the entire CU are grouped and coded in bypass mode. After signaling the index value, an additional syntax element, last_run_type_flag, is signaled. This syntax element, in conjunction with the number of indices, eliminates the need to signal the run value corresponding to the last run in the block.

[0043] In VTM, a dual tree is enabled for I-slices, which separates the division of coding units for luma and chroma. Therefore, in this proposal, palettes are applied separately to luma (Y component) and chroma (Cb, Cr components). When the dual tree is disabled, a palette is applied jointly to Y, Cb, Cr components, similar to the HEVC palette.

[0044] 2.7. Cross-component linear model prediction A cross-component linear model (CCLM) prediction mode is used in VVC, where a linear model is used to predict chroma samples based on the reconstructed luma samples of the same CU as follows: pred C (i,j)=α·rec L '(i,j)+β (2-1)

[0045] where pred C (i,j) represents the predicted chroma sample in one CU, and rec L(i,j) represents the downsampled and reconstructed luma sample of the same CU.

[0046] FIG. 4 illustrates the location of the top left sample and the current location sample involved in LM mode.

[0047] FIG. 4 shows an example of the sample positions used to derive α and β.

[0048] In addition to being able to use the upper and left templates to jointly calculate the linear model coefficients in LM mode, they can also be used alternatively in two other LM modes called LM_A and LM_L modes. In LM_A mode, only the upper template is used to calculate the linear model coefficients. To obtain more samples, the upper template is dilated to (W+H). In LM_L mode, only the left template is used to calculate the linear model coefficients. To obtain more samples, the left template is dilated to (H+W). For non-square blocks, the upper template is dilated to W+W and the left template is dilated to H+H.

[0049] The CCLM parameters (α and β) are derived using at most four neighboring chroma samples and their corresponding downsampled luma samples. Given the current chroma block dimensions as W × H, W' and H' are set as follows: - When LM mode is applied, W'=W,H'=H; - When LM-A mode is applied, W'=W+H; - If LM-L mode is applied, H'=H+W;

[0050] The upper neighbor positions are denoted as S[0,-1]...S[W'-1,-1], and the left neighbor positions are denoted as S[-1,0]...S[-1,H'-1]. Then, the four samples are selected as follows: - S[W' / 4,-1],S[3W' / 4,-1],S[-1,H' / 4],S[-1,3H' / 4] if LM mode is applied and both upper and left neighbor samples are available; - If LM-A mode is applied or only upper neighbor samples are available, S[W' / 8,-1],S[3W' / 8,-1],S[5W' / 8,-1],S[7W' / 8,-1]; - S[-1,H' / 8],S[-1,3H' / 8],S[-1,5H' / 8],S[-1,7H' / 8] if LM-L mode is applied or only left neighbor samples are available;

[0051] [ka]

[0052] Finally, the linear model parameters α and β are determined according to the following equations:

[0053]

number

[0054] [ka]

[0055] This has the advantage of reducing the computational complexity as well as reducing the memory size required to store the required tables.

[0056] To match the chroma sample positions of a 4:2:0 video sequence, two types of downsampling filters are applied to the luma samples to achieve a 2:1 downsampling ratio in both the horizontal and vertical directions. The selection of the downsampling filter is dictated by the SPS level flag. The two downsampling filters correspond to "Type 0" and "Type 2" content, respectively.

[0057]

number

[0058] Note that if the upper reference line is at a CTU boundary, only one luma line (a typical line buffer in intra prediction) is used to generate the downsampled luma samples.

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

[0060] For chroma intra mode coding, a total of eight intra modes are allowed for chroma intra mode coding. These modes include five traditional intra modes and six component common linear model modes (LM, LM_A, and LM_L). The chroma mode signaling and derivation process is shown in Table 2-2. Chroma mode coding directly depends on the intra prediction mode of the corresponding luma block. In an I slice, since the separation of the block partition structure for luma and chroma components is enabled, one chroma block may correspond to multiple luma blocks. Therefore, for chroma DM mode, the intra prediction mode of the corresponding luma block, including the center position of the current chroma block, is directly inherited.

[0061] [Table 2]

[0062] 2.8. Block Differential Pulse Code Modulation Coding (BDPCM) In JVET-M0057, BDPCM is proposed. Due to the shape of the horizontal (or vertical) prediction module, which uses the pixel on the left (A) (or above (B)) to predict the current pixel, the most throughput-efficient way to process a block is to process all pixels of one column (or line) in parallel and process these columns (or lines) sequentially. To improve the throughput, we introduce the following process: if the predictor selected for this block is vertical, we divide a block of width 4 into two by the horizontal frontier, and if the predictor selected for this block is horizontal, we divide a block of height 4 into two by the horizontal frontier. The block is divided into two parts by the vertical frontier.

[0063] When a block is divided, it is not possible to calculate a prediction for a sample from one region using pixels from another region; if this occurs, the predicted pixel is replaced by a reference pixel in the prediction direction. This is illustrated in Figure 5 for different positions of the current pixel X in a 4x8 block predicted vertically.

[0064] FIG. 5 shows an example of dividing one 4×8 sample block into two independently decodable regions.

[0065] Thanks to this property, a 4x4 block can be processed in two cycles, and a 4x8 or 8x4 block may be processed in four cycles, as shown in FIG.

[0066] FIG. 6 shows an exemplary order for processing rows of pixels to maximize throughput for a 4×N block with a vertical prediction module.

[0067] Table 2-3 summarizes the number of cycles required to process a block depending on its size. Note that for any block where both dimensions are 8 or more, it is trivial to say that more than 8 pixels can be processed per cycle.

[0068] [Table 3]

[0069] 2.9. Quantized Residual Domain BDPCM In JVET-N0413, quantized residual domain BDPCM (hereinafter referred to as RBDPCM) is proposed. Intra prediction, similar to intra prediction, predicts the entire block by copying samples in the prediction direction (horizontal or vertical prediction). The residual is quantized, and the delta between the quantized residual and its predictor (horizontal or vertical) quantized value is coded.

[0070] [ka]

[0071] For horizontal prediction, a similar rule applies and the residual quantized samples are given by:

[0072]

number

[0073] [ka]

[0074] [ka]

[0075] In the horizontal direction,

[0076]

number

[0077] [ka]

[0078] The main advantage of this scheme is that the inverse DPCM can be done on the fly while parsing the coefficients, only requiring the addition of a predictor while parsing the coefficients, or it can be done after parsing.

[0079] In quantized residual domain BDPCM, transform skip is always used.

[0080] 2.10. Multiple Transformation Sets (MTS) in VVC The VTM enables large block size transforms up to 64x64, which is primarily useful for high-resolution video, e.g., 1080p and 4K sequences. For transform blocks with a size (width or height, or both width and height) of 64, high-frequency transform coefficients are zeroed out and only low-frequency coefficients are retained. For example, for an MxN transform block, where M is the block width and N is the block height, if M is 64, only the left 32 columns of transform coefficients are retained. Similarly, if N is 64, only the top 32 rows of transform coefficients are retained. When using transform skip mode for large blocks, the entire block is used without zeroing values. The VTM also supports a configurable maximum transform size in SPS, allowing encoders the flexibility to select transform sizes up to 16, 32, or 64 based on the needs of a particular implementation.

[0081] In addition to the DCT-II used in HEVC, a Multiple Transform Selection (MTS) scheme is used for residual coding of both inter-coded and intra-coded blocks. It uses multiple transforms selected from DCT8 / DST7. The newly introduced transform matrices are DST-VII and DCT-VIII. The selected DST / DCT basic functions are listed in Table 2-4 below.

[0082] [Table 4]

[0083] To maintain the orthogonality of the transform matrices, they are quantized more precisely than in HEVC: after horizontal and vertical transforms, all coefficients have 10 bits to keep the intermediate values ​​of the transform coefficients within the 16-bit range.

[0084] To control the MTS scheme, separate enable flags are defined for intra and inter at the SPS level. When MTS is enabled in the SPS, a CU level flag is signaled to indicate whether MTS is applied, where MTS is only applied to luma. The MTS CU level flag is signaled when the following conditions are met: - Width and height are both 32 or less - CBF flag is 1

[0085] If the MTS CU flag is zero, DCT2 is applied in both directions. However, if the MTS CU flag is one, two other flags are additionally signaled to indicate the horizontal and vertical transform types, respectively. The transform mapping table is signaled as shown in Table 2-5. A unified transform selection for ISP and implicit MTS is used by removing the dependency on intra mode and block shape. If the current block is in ISP mode, or if the current block is an intra block and both intra and inter explicit MTS are on, only DST7 is used for both the horizontal and vertical transform cores. When converting matrix precision, an 8-bit primary transform core is used. Therefore, all transform cores used in HEVC remain the same, including 4-point DCT-2 and DST-7, 8-point, 16-point, and 32-point DCT-2, etc. Other transform cores, such as 64-point DCT-2, 4-point DCT-8, 8-point, 16-point, and 32-point DST-7 and DCT-8, use an 8-bit primary transform core.

[0086] [Table 5]

[0087] To reduce the complexity of large sizes of DST-7 and DCT-8, the high-frequency transform coefficients are zeroed for DST-7 and DCT-8 blocks whose size (width or height, or both width and height) is 32. Only the coefficients in the 16x16 low-frequency region are retained.

[0088] As in HEVC, the residual of a block may be coded in transform skip mode. To avoid syntax coding redundancy, the transform skip flag is not signaled if the CU-level MTS_CU_flag is non-zero. The block size restriction for transform skip is the same as for MTS in JEM4: if the width and height of a block are both 32 or less, it indicates that transform skip is applicable to the CU. Note that when LFNST or MIP is activated for the current CU, the implicit MTS transform is set to DCT2. Also, if MTS is enabled for inter-coded blocks, implicit MTS can still be enabled.

[0089] 2.11. Low Frequency Non-Separable Transform (LFNST) In VVC, as shown in Figure 7, a low-frequency non-separable transform (LFNST), also known as a contraction secondary transform, is applied between the forward primary transform and quantization (encoder side) and between the inverse quantization and the inverse primary transform (decoder side). In the LFNST, a 4x4 non-separable transform or an 8x8 non-separable transform is applied according to the block size. For example, a 4x4 LFNST is applied to small blocks (i.e., min(width, height)<8), and an 8x8 LFNST is applied to larger blocks (i.e., min(width, height)>4).

[0090] FIG. 7 shows an example of the low frequency non-separable transform (LFNST) process.

[0091] [ka]

[0092] [ka]

[0093] [ka]

[0094] Narrowing Non-Separable Transformations

[0095] [ka]

[0096] [ka] The inverse transform matrix for RT is the transpose of its forward transform. For the 8x8 LFNST, a 4x reduction factor is applied, reducing the traditional 8x8 non-separable transform matrix size (64x64 direct matrix) to a 16x48 direct matrix. That is, at the decoder side, a 48x16 inverse RST matrix is ​​used to generate the core (first-order) transform coefficients in the upper-left region of the 8x8. When applying a 16x48 matrix instead of a 16x64 matrix with the same transform set configuration, each matrix takes 48 input data from three 4x4 blocks in the upper-left 8x8 block, excluding the lower-right 4x4 block. By reducing the dimensions, the memory usage for storing all LFNST matrices is reduced from 10KB to 8KB, resulting in a reasonable performance degradation. To reduce complexity, LFNST is restricted to be applicable only when all coefficients outside the first coefficient subgroup are insignificant. Therefore, when LFNST is applied, all first-order-only transform coefficients must be zero. This allows for adjustment of the LFNST index signaling the previous significant position, thus avoiding the extra coefficient scan in current LFNST designs, which is required to check significant coefficients only at specific positions. The worst-case handling of LFNST (in terms of multiplications per pixel) limits non-separable transforms for 4x4 and 8x8 blocks to 8x16 and 8x48 transforms, respectively. In such cases, when LFNST is applied, the previous significant scan position must be less than 8 for other sizes less than 16. For blocks with shapes of 4xN, Nx4, and N>8, the proposed restriction means that LFNST is applied only once, and only to the top-left 4x4 region. When LFNST is applied, all first-order-only coefficients are zero, reducing the number of operations required for the primary transform in such cases. From the encoder's perspective, coefficient quantization becomes significantly simpler when testing LFNST transforms. The first 16 coefficients (in scan order) must undergo maximum distortion-optimized quantization, with the remaining coefficients forced to zero.

[0097] 2.11.2. LFNST (Low Frequency Non-Separable Transform) Transform Selection There are four transform sets in total, with two non-separable transform matrices (kernels) per transform set used in LFNST. The mapping from intra prediction modes to transform sets is pre-defined, as shown in Table 2-6. If one of the three CCLM modes (INTRA_LT_CCLM, INTRA_T_CCLM, or INTRA_L_CCLM) is used for the current block (81<=predModeIntra<=83), transform set 0 is selected for the current chroma block. For each transform set, the selected non-separable secondary transform candidate is further defined by an explicitly signaled LFNST index. This index is signaled in the bitstream once per intra CU after the transform coefficients.

[0098] [Table 6]

[0099] 2.11.3. LFNST Index Signals and Interaction with Other Tools Because LFNST is restricted to be applicable only when all coefficients outside the first coefficient subgroup are non-significant, the coding of the LFNST index depends on the position of the last significant coefficient. Also, the LFNST index is context coded, but is independent of the intra prediction mode; only the first bin is context coded. Furthermore, LFNST is applied in both intra slices and inter slices, and for both luma and chroma. When dual trees are enabled, LFNST indexes for luma and chroma are signaled separately. For inter slices (dual trees are disabled), a single LFNST index is signaled and used for both luma and chroma.

[0100] When ISP mode is selected, LFNST is disabled and the RST index is not signaled because the performance improvement is marginal even if RST is applied to all feasible partition blocks. Furthermore, disabling RST for ISP predicted residuals may reduce coding complexity. When MIP mode is selected, LFNST is also disabled and the index is not signaled.

[0101] Considering that CUs larger than 64x64 are implicitly split (TU tiling) due to the existing maximum transform size limitation (64x64), LFNST index lookup can increase data buffering by a factor of four for a certain number of decoding pipeline stages. Therefore, the maximum size allowed for LFNST is limited to 64x64. Note that LFNST is only enabled for DCT2.

[0102] 2.12. Chroma conversion skip In VVC, chroma transform skip (TS) is introduced. The motivation is to unify TS and MTS signaling between luma and chroma by relocating transform_skip_flag and mts_idx to the residual_coding part. One context model is added for chroma TS. For mts_idx, neither the context model nor the binarization is changed. Furthermore, TS residual coding is also applied when using chroma TS.

[0103] Semantics

[0104] [ka]

[0105] 2.13.BDPCM for Chroma

[0106] [ka]

[0107] [Table 7]

[0108] [ka]

[0109] The deblocking filter is deactivated at the boundary between two Block-DPCM blocks, since neither block uses the transform stage that usually causes blocking artifacts. This deactivation is done independently for the luma and chroma components.

[0110] 3. Examples of technical problems that the disclosed solution aims to solve The current design for deriving linear parameters in CCLM and TS has the following problems. 1. For non-4:4:4 color formats, the derivation of linear parameters in CCLM involves the neighboring chroma samples and the neighboring downsampled juxtaposed luma samples. As shown in Figure 8, in the current VVC, if the nearest line is not on a CTU boundary, the second line above the current block for 4:2:2 video is used to derive the neighboring downsampled juxtaposed luma sample. However, for 4:2:2 video, the vertical resolution does not change. Therefore, there is a phase shift between the neighboring downsampled juxtaposed luma sample and the neighboring chroma sample.

[0111] FIG. 8 shows an example of nearby chroma samples and downsampled, collocated nearby luma samples used to derive CCLM parameters for 4:2:2 video. 2. In the current VVC, the same maximum block size is used in the condition check for signaling the luma transform skip flag and the chroma transform skip flag. Such a design does not consider the color format and is undesirable. a. Similar issues exist for luma BDPCM flag signaling and chroma BDPCM flag signaling, and the same maximum block size is used for the condition check.

[0112] 4. List of embodiments and techniques The following should be considered examples to illustrate the general concept. These items should not be construed in a narrow sense. Furthermore, these items can be combined in any way.

[0113] In this document, the term "CCLM" refers to a coding tool that utilizes cross-color component information to predict samples / residuals of a current color component or to derive a reconstruction of samples in the current color component. The present invention is not limited to the CCLM technique described in VVC.

[0114] [ka] 1. When deriving CCLM parameters for a chroma block, one or more upper neighboring lines of its collocated luma block may be used to derive the top luma sample of its downsampled collocated neighborhood. a. In one example, if the current chroma block is not at the topmost CTU boundary, the closest upper line of the adjacent luminance block may be downsampled and used to derive the topmost adjacent luminance sample instead of the second line above. i. In one example, one and the same downsampling filter may be used to derive the top luminance sample of the downsampled collocated neighborhood and the left luminance sample of the downsampled collocated neighborhood. 1) For example, a

[0121] filter may be used. More specifically, pDsY[x]=(pY[2*x-1][-1]+2*pY[2*x][-1]+pY[2*x+1][-1]+2)>>2, where pY[2*x][-1], pY[2*x-1][-1], pY[2*x+1][-1] are the luminance samples from the nearest upper neighbors, and pDstY[x] is the downsampled and aligned top luminance sample. ii. In one example, different downsampling filters (e.g., different filter taps / different filter coefficients) may be used to derive the downsampled adjacent top luminance sample and the downsampled adjacent left luminance sample. iii. In one example, one and the same downsampling filter may be used to downsample and derive the topmost luminance sample of a neighboring juxtaposed pixel, regardless of the location of the chroma block (e.g., the chroma block may or may not be at the topmost CTU boundary). iv. In one example, the above method may only be applied to images / videos in 4:2:2 format. b. In one example, if the current chroma block is not at the topmost CTU boundary, the upper neighboring luma samples, including the nearest upper line of the adjacent luma block, excluding the second line above, may be downsampled and used to derive the top adjacent luma sample. c. In one example, the derivation of the top luminance sample in a downsampled collocated neighborhood may depend on samples located on multiple lines. i. In one example, it may depend on both the second closest line and the closest line above the adjacent luminance block. ii. In one example, the downsampled, juxtaposed neighboring top luminance samples may be derived using one and the same downsampling filter for different color formats (eg, 4:2:0 and 4:2:2). 1) In one example, a 6-tap filter (eg, [1 2 1; 1 2 1]) may be utilized. a) In one example, the top luminance sample in the downsampled collocated neighborhood may be derived as pDsY[x]=(pY[2*x-1][-2]+2*pY[2*x][-2]+pY[2*x+1][-2]+pY[2*x-1][-1]+2*pY[2*x][-1]+pY[2*x+1][-1]+4)>>3, where pY is the corresponding luminance sample and pDstY[x] represents the top luminance sample in the downsampled collocated neighborhood. b) Additionally, alternatively, the above method may be applied when sps_cclm_colocated_chroma_flag is equal to 0. 2) In one example, a 5-tap filter (eg, [0 1 0; 1 4 1; 0 1 0]) may be utilized. a) In one example, the top luminance sample in the downsampled collocated neighborhood may be derived as pDsY[x]=(pY[2*x][-2]+pY[2*x-1][-1]+4*pY[2*x][-1]+pY[2*x+1][-1]+pY[2*x][0]+4)>>3, where pY is the corresponding luminance sample and pDstY[x] represents the top luminance sample in the downsampled collocated neighborhood. b) Further alternatively, the above method may be applied when sps_cclm_colocated_chroma_flag is equal to 1. iii. In one example, the above method may only be applied to images / videos in 4:2:2 format. [ka] 2. The maximum block size of a transform skip coded block may depend on the color component, where MaxTsSizeY and MaxTsSizeC are the maximum block sizes of a transform skip coded block for luma and chroma, respectively. In one example, the maximum block size for the luma and chroma components may be different. b. In one example, the maximum block size for the two chroma components may be different. c. In one example, the maximum block size for luma and chroma components, or for each color component, may be signaled separately. i. In one example, MaxTsSizeC / MaxTsSizeY may be signaled at the sequence level / picture level / slice level / tile group level, e.g., in the sequence header / picture header / SPS / VPS / DPS / PPS / APS / slice header / tile group header. ii. In one example, MaxTsSizeY may be conditionally signaled, for example, according to whether transform skip is enabled or not, or whether / BDPCM is enabled or not. iii. In one example, MaxTsSizeC may be conditionally signaled according to, for example, color format / convert skip enabled or not / BDPCM enabled or not. iv. Alternatively, predictive coding of the largest block size between the luma and chroma components may be used. d. In one example, MaxTsSizeC may depend on MaxTsSizeY. i. In one example, MaxTsSizeC may be set equal to MaxTsSizeY. ii. In one example, MaxTsSizeC may be set equal to MaxTsSizeY / N (where N is an integer), e.g., N=2. e. In one example, MaxTsSizeC may be set according to the chroma subsampling ratio. i. In one example, MaxTsSizeC is set equal to MaxTsSizeY>>SubWidthC, where SubWidthC is defined in Table 2-1. ii. In one example, MaxTsSizeC is set equal to MaxTsSizeY>>SubHeightC, where SubHeightC is defined in Table 2-1. iii. In one example, MaxTsSizeC is set equal to MaxTsSizeY>>max(SubWidthC, SubHeightC). iv. In one example, MaxTsSizeC is set equal to MaxTsSizeY>>min(SubWidthC, SubHeightC).

[0115] 3. The width and height of the maximum allowable block size for transform-coded blocks may be defined differently. In one example, the width and height of the maximum allowed block size may be signaled separately. b. In one example, the maximum allowed block size width and height for chroma transform coded blocks may be denoted as MaxTsSizeWC and MaxTsSizeHC, respectively. MaxTsSizeWC may be set equal to MaxTsSizeY>>SubWidthC, and MaxTsSizeHC may be set equal to MaxTsSizeY>>SubHeightC. i. In one example, MaxTsSizeY is as defined in bullet 2. [ka] In one example, the chroma transform skip flag may be conditionally signaled according to the following conditions: i. In one example, the conditions are: tbW is less than or equal to MaxTsSizeC, and tbH is less than or equal to MaxTsSizeC, where tbW and tbH are the width and height of the current chroma block. 1) In one example, MaxTsSizeC can be defined in the same way as that of bullets 2-3. ii. In one example, the conditions are: tbW is less than or equal to MaxTsSizeWC, and tbH is less than or equal to MaxTsSizeHC, where tbW and tbH are the width and height of the current chroma block, and MaxTsSizeWC and MaxTsSizeHC represent the width and height of the maximum allowed block size of a chroma transform skip coded block, respectively. 1) In one example, MaxTsSizeWC and / or MaxTsSizeHC can be defined similarly to that in bullet 3. [ka]

[0116] 5. Instead of coding two TS flags for two chroma color components, it is proposed to use one syntax to indicate the use of TS for two chroma color components. [ka] i. In one example, the value of a single syntax element is a binary value. 1) Alternatively, two chroma component blocks share the same TS mode on / off control according to a single syntax element. a) In one example, a value of a single syntax element equal to 0 indicates that the TS is disabled for both. b) In one example, a value of a single syntax element equal to 0 indicates that the TS is enabled for both. 2) Alternatively, a second syntax element can be further signaled based on whether the value of the single syntax element is equal to K (eg, K=1). a) In one example, a value of a single syntax element equal to 0 indicates that TS is disabled for both syntax elements, and a value of a single syntax element equal to 0 indicates that TS is enabled for at least one of the two chroma components. b) A second syntax element may be used to indicate whether the TS applies to either one of the two chroma components and / or whether the TS applies to both. ii. In one example, the value of the single syntax element is a non-binary value. 1) In one example, a single syntax element value equal to K0 indicates that the TS is disabled for both. 2) In one example, a single syntax element value equal to K1 indicates that TS is enabled for the first chroma color component and TS is disabled for the second color component. 3) In one example, a value of a single syntax element equal to K2 indicates that TS is disabled for the first chroma color component and TS is enabled for the second color component. 4) In one example, a single syntax element value equal to K3 indicates that the TS is valid for both. 5) In one example, a single syntax element may be coded using a fixed-length, unary, truncated unary, k-th order EG binarization method. iii. In one example, the single syntax element and / or the second syntax element may be context coded or bypass coded.

[0117] [ka]

[0118] 6. Whether and / or how to apply the above disclosed methods may be signaled at the sequence level / picture level / slice level / tile group level, for example, in the sequence header / picture header / SPS / VPS / DPS / PPS / APS / slice header / tile group header.

[0119] 7. Whether and / or how to apply the above disclosed methods may depend on coded information such as color format, single / dual tree split, etc.

[0120] 5. Implementation form This section presents exemplary embodiments and how the current VVC standard can be modified to account for these embodiments. Changes to the VVC specification are highlighted in bold and italic text. Deleted text is marked in double brackets (e.g., [[a]] means the letter "a" is deleted).

[0121] 5.1. Embodiment 1 The working draft specified in JVET-P2001-v9 can be modified as follows:

[0122] [ka] … 3. When x=0..nTbW-1, y=0..nTbH-1, the downsampled and aligned luminance samples pDsY[x][y] are derived as follows: - If both SubWidthC and SubHeightC are equal to 1, the following applies: - pDsY[x][y], where x=1..nTbW-1 and y=1..nTbH-1, is derived as follows: pDstY[x][y]=pY[x][y] (8-159) - Otherwise, the following applies: The one-dimensional filter coefficient arrays F1, F2 and the two-dimensional filter coefficient arrays F3, F4 are defined as follows: F1[i]=1, with i=0..1 (8-160) F2[0]=1,F2[1]=2,F2[2]=1 (8-161) F3[i][j]=F4[i][j]=0,with i=0..2,j=0..2 (8-162) - If both SubWidthC and SubHeightC are equal to 2, the following applies: F1[0]=1,F1[1]=1 (8-163) F3[0][1]=1,F3[1][1]=4,F3[2][1]=1,F3[1][0]=1,F3[1][2]=1 (8-164) F4[0][1]=1,F4[1][1]=2,F4[2][1]=1 (8-165) F4[0][2]=1,F4[1][2]=2,F4[2][2]=1 (8-166) - Otherwise, the following applies: F1[0]=2,F1[1]=0 (8-167) F3[1][1]=8 (8-168) F4[0][1]=2,F4[1][1]=4,F4[2][1]=2, (8-169)

[0123] … 5. If numSampT is greater than 0, the top chroma sample of the selected neighborhood pSelC[idx] is set equal to p[pickPosT[idx-cntL]][-1], where idx=cntL..cntL+cntT-1, and the top luma sample of the downsampled neighborhood pSelDsY[idx], for idx=0..cntL+cntT-1, is defined as follows: … - Otherwise (sps_cclm_colocated_chroma_flag is equal to 0), the following applies: - If x is greater than 0, the following applies: - If bCTUboundary is equal to FALSE, the following applies: [ka] - Otherwise (bCTUboundary is equal to TRUE), the following applies: pSelDsY[idx]=(F2[0]*pY[SubWidthC*x-1][-1]+ F2[1]*pY[SubWidthC*x][-1]+ F2[2]*pY[SubWidthC*x+1][-1]+2)>>2(8-194) - Otherwise (x is equal to 0), the following applies: - If availTL is equal to TRUE and bCTUboundary is equal to FALSE, the following applies: [ka] - Otherwise, if availTL is equal to TRUE and bCTUboundary is equal to TRUE, the following applies: pSelDsY[idx]=(F2[0]*pY[-1][-1]+F2[1]* p Y[0][-1]+ F2[2]*pY[1][-1]+2)>>2 (8-196) - Otherwise, if availTL is equal to FALSE and bCTUboundary is equal to FALSE, the following applies: pSelDsY[idx]=(F1[1]*pY[0][-2]+F1[0]*pY[0][-1]+1)>>1 (8-197) - Otherwise (availTL equals FALSE and bCTUboundary equals TRUE), the following applies: pSelDsY[idx]=pY[0][-1] (8-198) …

[0124] 5.2. Embodiment 2 In this embodiment, an example of chroma transform skip flag coding according to the maximum allowed transform skip coded block size is shown. The working draft specified in JVET-P2001-v9 can be modified as follows:

[0125] [Table 8]

[0126] 5.3. Embodiment 3 In this embodiment, an example of chroma transform skip flag coding according to the maximum allowed transform skip coded block size is shown. The working draft specified in JVET-P2001-v9 can be modified as follows:

[0127] [Table 9] [Table 10]

[0128] 9 is a block diagram of a video processing device 900. The device 900 may be used to implement one or more of the methods described herein. The device 900 may be implemented by a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 900 may include one or more processing devices 902, one or more memories 904, and video processing hardware 906. The one or more processing devices 902 may be configured to implement one or more of the methods described herein. The memory(s) 904 may be used to implement the methods and techniques described herein. It may be used to store data and code. Video processing hardware 906 may be used to implement the techniques described herein in hardware circuitry (e.g., as described in the previous section). In some embodiments, hardware 906 may be partially or wholly contained within processing unit 902, e.g., a graphics processing unit.

[0129] FIG. 10 shows a block diagram of an exemplary video encoder.

[0130] 11 is a flowchart of a method 1100 for processing video. The method 1100 includes deriving parameters of a cross-component linear model for converting between chroma blocks of video and a coded representation of the video by using downsampled, co-located neighboring top-most luma samples generated from a positive integer number N of upper neighboring lines of the co-located luma block using a downsampling filter (1102), and performing the conversion using a predicted chroma block generated using the cross-component linear model (1104).

[0131] FIG. 12 is a block diagram illustrating an exemplary video processing system in which the disclosed techniques can be implemented.

[0132] 12 is a block diagram illustrating an example video processing system 1200 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the modules of system 1200. System 1200 may include an input unit 1202 for receiving video content. The video content may be received in a raw or uncompressed format, e.g., 8- or 10-bit multi-component pixel values, or in a compressed or encoded format. Input unit 1202 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 networks (PONs), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0133] System 1200 may include a coding component 1204 that can implement various coding or encoding methods described herein. Coding component 1204 may reduce the average bit rate of the video from input unit 1202 to the output of coding component 1204, generating a coded representation of the video. Thus, this coding technique may be referred to as video compression or video transcoding technique. The output of coding component 1204 may be stored or transmitted via a communication link, as represented by component 1206. A bitstream (or coded) representation of a stored or communicated video received at input unit 1202 may be used by component 1208 to generate pixel values ​​or displayable video that are sent to display interface 1210. The process of generating a user-viewable video from a bitstream representation is sometimes referred to as video decompression. Furthermore, while 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 are performed by a decoder.

[0134] Examples of peripheral bus interfaces or display interfaces may 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 implemented in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[0135] Some embodiments of the disclosed technology include determining or deciding to enable a video processing tool or mode. In one example, when a video processing tool or mode is enabled, an encoder uses or implements the tool or mode when processing a single video block, but may not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, the conversion from a block of video to a bitstream representation of video uses the video processing tool or mode if the video processing tool or mode is enabled based on the decision or determination. In another example, when a video processing tool or mode is enabled, a decoder processes the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, the conversion from the bitstream representation of video to a block of video is performed using the video processing tool or mode enabled based on the decision or determination.

[0136] Some embodiments of the disclosed techniques include deciding or determining 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 when 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 knowing that the bitstream has not been modified using the video processing tool or mode that was enabled based on the decision or determination.

[0137] Implementations of the solutions, examples, embodiments, modules, and functional operations disclosed herein, including the structures disclosed herein and their structural equivalents, may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, or in one or more combinations thereof. The disclosed and other embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for implementation by or controlling the operation of a data processing apparatus. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter providing a machine-readable propagated signal, or one or more combinations thereof. The term "data processing apparatus" includes all apparatuses, devices, and machines for processing data, including, for example, a programmable processing apparatus, a computer, or multiple processing apparatuses or computers. In addition to hardware, the apparatus may include code that creates an execution environment for the computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof. A propagated signal is an artificially generated signal, for example, a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to an appropriate receiving device.

[0138] A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be recorded as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), may be stored in a single file dedicated to the program, or may be stored in multiple coordinating files (e.g., files containing one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer located at a single site or on multiple computers distributed across multiple sites and interconnected by a communications network.

[0139] The processes and logic flows described herein may be performed by one or more programmable processing devices 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 devices may be implemented as, special purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0140] Processors suitable for executing a computer program include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives 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 include one or more mass storage devices, e.g., magnetic, magneto-optical, or optical disks, for storing data, or be operatively coupled to receive data from or transfer data to these mass storage devices. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, EPROMs, EEPROMs, flash storage devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, and semiconductor storage devices such as CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special-purpose logic circuitry.

[0141] FIG. 13 is a block diagram illustrating an example video coding system 100 that may utilize techniques of this disclosure.

[0142] 13, video coding system 100 may include source device 110 and destination device 120. Source device 110 generates encoded video data, which may also be referred to as a video encoding device. Destination device 120 may decode the encoded video data, which may also be referred to as a video decoding device, generated by source device 110.

[0143] Source device 110 may include a video source 112, a video encoder 114, and an input / output (I / O) interface .

[0144] 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 these sources. The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 and generates a bitstream. The bitstream may include a bit sequence 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 transmitter. The coded video data can be transmitted via the network 130a or directly through the I / O interface 116 to the destination device 120. The coded video data may be stored on a storage medium / server 130b for access by the destination device 120.

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

[0146] 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 interface with an external display device.

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

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

[0149] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 14, video encoder 200 comprises multiple functional modules. Techniques described in this disclosure may be shared among various modules of video encoder 200. In some examples, a processing unit may be configured to perform any or all of the techniques described in this disclosure.

[0150] The functional modules of the video encoder 200 may include a partitioning 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 coding unit 214.

[0151] 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 can perform prediction in an IBC mode in which at least one reference picture is the picture in which the current video block is located.

[0152] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, may be highly integrated, but are represented separately in the example of FIG. 14 for purposes of illustration.

[0153] The division unit 201 can divide a picture into one or more video blocks. The video encoder 200 and the video decoder 300 may support a variety of video block sizes.

[0154] The mode selection unit 203 may select one of intra or inter coding modes based on, for example, an error result, and provide 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 a coded block as a reference picture. In an embodiment of the present invention, the mode selection unit 203 may select a combination of intra and inter prediction (CIIP) modes for performing prediction based on an inter prediction signal and an intra prediction signal. In the case of inter prediction, the mode selection unit 203 may also select the resolution of a motion vector for the block (e.g., sub-pixel or integer pixel accuracy).

[0155] To perform inter prediction on the current video block, motion estimation unit 204 may generate motion information for the current video block by comparing the current video block to one or more reference frames from buffer 213. Motion compensation unit 205 may determine 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.

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

[0157] In some examples, motion estimation unit 204 performs unidirectional prediction on the current video block, and motion estimation unit 204 may search reference pictures in list 0 or list 1 for the current video block to find a reference video block. Motion estimation unit 204 may then generate a reference index indicating the 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 prediction video block for the current block based on the reference video block indicated by the motion information of the current video block.

[0158] In another example, motion estimation unit 204 may bidirectionally predict the current video block, and motion estimation unit 204 may search for a reference video block for the current video block from among the reference pictures in list 0 and may search for another reference video block for the current video block from among the reference pictures in list 1. Motion estimation unit 204 may then generate reference indexes that indicate the reference pictures in lists 0 and 1 that contain the reference video blocks, and motion vectors that indicate the spatial displacement between the reference video blocks and the current video block. Motion estimation unit 204 may output the reference index and motion vector for the current video block as motion information for the current video block. Motion compensation unit 205 may generate a prediction video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0159] In some examples, the motion estimation unit 204 may output a full set of motion information for decoding processing in a decoder.

[0160] In some examples, motion estimation unit 204 may not output a full set of motion information for the current picture. Rather, motion estimation unit 204 may signal motion information for the current video block by reference to motion information of another video block. 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 a neighboring video block.

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

[0162] 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 determine the motion vector of the current video block using the motion vector difference and the motion vector of the indicated video block.

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

[0164] Intra prediction unit 206 may perform intra prediction on the current video block. If intra prediction unit 206 intra predicts the current video block, intra prediction unit 206 may generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block may include a predicted video block and various syntax elements.

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

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

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

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

[0169] 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 prediction video blocks generated by prediction unit 202 to generate a reconstructed video block associated with the current block, which is stored in buffer 213.

[0170] After reconstruction unit 212 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking artifacts in the video block.

[0171] Entropy encoding unit 214 may receive data from other functional components of video encoder 200. Upon receiving the data, entropy encoding unit 214 may perform one or more entropy encoding operations to generate entropy-coded data and output a bitstream that includes the entropy-coded data.

[0172] FIG. 15 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.

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

[0174] 15, video decoder 300 includes entropy decoding unit 301, motion compensation unit 302, intra prediction unit 303, inverse quantization unit 304, inverse transform unit 305, and reconstruction unit 306, as well as 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 (e.g., FIG. 14).

[0175] The entropy decoding unit 301 retrieves an encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., coded 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.

[0176] The motion compensation unit 302 may generate motion-compensated blocks, possibly performing interpolation based on an interpolation filter. The syntax element may include an identifier for the interpolation filter to be used with sub-pixel precision.

[0177] Motion compensation unit 302 may calculate interpolated values ​​for sub-integer pixels of the reference block using an interpolation filter as used by video encoder 200 during encoding of the video block. Motion compensation unit 302 may determine the interpolation filter used by video encoder 200 based on received syntax information and use this interpolation filter to generate the predictive block.

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

[0179] 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 (i.e., 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.

[0180] Reconstruction unit 306 may sum the residual block with the corresponding prediction block generated by motion compensation unit 202 or intra prediction unit 303 to form a decoded block. If desired, a deblocking filter may be applied to filter the decoded block to remove blocking artifacts. The decoded video block is stored in buffer 307, which provides a reference block for subsequent motion compensation.

[0181] Some embodiments of the disclosed techniques include determining or deciding to enable a video processing tool or mode. In one example, if a video processing tool or mode is enabled, the encoder uses or implements the tool or mode when processing a single video block, but may not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, the conversion of a block of video to a bitstream representation of the video uses the video processing tool or mode if the video processing tool or mode is enabled based on the determination or decision. Another example In the case where a video processing tool or mode is enabled, the decoder processes the bitstream knowing that the bitstream has been modified based on the video processing tool or mode, i.e., performs the conversion from the bitstream representation of video to blocks of video using the video processing tool or mode that was enabled based on the decision or determination.

[0182] As used herein, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion of a pixel representation of video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits spread to the same or different locations in the bitstream, e.g., as specified by a syntax. For example, a macroblock may be encoded in terms of transformed and coded error residual values ​​and using bits in a header and other fields in the bitstream.

[0183] Next, preferred items in some embodiments will be listed.

[0184] The following items present exemplary embodiments of the techniques described in the previous section.

[0185] 1. A video processing method comprising: deriving parameters of a cross-component linear model by using a downsampling filter to convert between chroma blocks of the video and a coded representation of the video, using a downsampling filter to use top-most luminance samples of a downsampled collocated neighborhood generated from N positive integer upper neighboring lines of a collocated luminance block; and performing the conversion using a predicted chroma block generated using the cross-component linear model.

[0186] 2. The method according to item 1, wherein the N upper neighboring lines correspond to the nearest upper lines of the adjacent luminance block because the chroma block is not at the boundary of the top coding tree unit.

[0187] 3. The method according to any one of items 1 to 2, wherein the downsampling filter is also applied to downsample to generate adjacent juxtaposed left luminance samples.

[0188] 4. The method according to any one of items 1 to 2, wherein the downsampling filter is different from another downsampling filter used to downsample to generate the adjacent left luminance sample.

[0189] 5. The method according to any of the preceding items, wherein the downsampling filter is independent of the position of the chroma block relative to the top boundary of the coding tree unit.

[0190] 6. The method according to any of items 1 to 5, wherein the method is selectively applied due to video having a 4:2:2 format.

[0191] 7. The method according to item 1, wherein N is greater than 1.

[0192] 8. The method according to item 7, wherein the N upper neighboring lines include the nearest upper line and the second nearest upper line.

[0193] 9. The method according to item 1, wherein the downsampling filter depends on the color format of the image.

[0194] 10. The method according to any one of items 1 to 9, wherein the downsampling filter is a 6-tap filter.

[0195] 11. The method according to any one of items 1 to 9, wherein the downsampling filter is a 5-tap filter.

[0196] 12. The method according to any one of items 1 to 11, wherein the conversion comprises encoding the video into the coded representation.

[0197] 13. A method according to any one of items 1 to 11, wherein the conversion comprises decoding the coded representation to generate pixel values ​​of the image.

[0198] 14. A video decoding device comprising a processing device configured to implement the method according to one or more of items 1 to 13.

[0199] 15. A video encoding device comprising a processing device configured to implement the method according to one or more of items 1 to 13.

[0200] 16. A computer program product having computer code stored therein, wherein when the code is executed by a processing device, the processing device implements the method according to any one of items 1 to 13.

[0201] 17. A method, apparatus or system as described herein.

[0202] The second set of items describes particular features and aspects of the technology disclosed in the previous section (eg, item 1).

[0203] 1. A video processing method for converting between a chroma block of a video and a bitstream representation of the video, comprising: deriving 1602 parameters of a cross-component linear model by using downsampled luma samples generated from a positive integer number N of upper neighboring lines of a juxtaposed luma block of the chroma block using a downsampling filter; and performing the conversion using a predicted chroma block generated using the cross-component linear model.

[0204] 2. The method according to item 1, wherein the N upper neighboring lines correspond to the nearest upper lines of the adjacent luminance block because the chroma block is not at the boundary of the top coding tree unit.

[0205] 3. The method according to any one of items 1 to 2, wherein the downsampling filter is also applied to other downsampled luminance samples generated from the left neighboring line of the juxtaposed luminance block.

[0206] 4. The method according to any one of items 1 to 2, wherein another downsampling filter is applied to generate another downsampled luminance sample generated from a left neighboring line of adjacent luminance blocks.

[0207] 5. The method according to any one of items 1 to 4, wherein the downsampling filter has filter coefficients of [1, 2, 1].

[0208] 6. The method according to any one of items 1 to 5, wherein the downsampled luminance samples pDsY[x] satisfy the equation pDsY[x]=(pY[2*x-1][-1]+2*pY[2*x][-1]+pY[2*x+1][-1]+2)>>2, where pY[2*x][-1], pY[2*x-1][-1] and pY[2*x+1][-1] are luminance samples from the nearest upper neighboring lines, and x is an integer.

[0209] 7. The method according to any one of items 1 to 6, wherein the downsampling filter is independent of the position of the chroma block relative to the top boundary of the coding tree unit.

[0210] 8. The method according to any one of items 1 to 6, wherein the method is selectively applied due to the 4:2:2 color format of the video.

[0211] 9. The method described in item 1, wherein the N upper neighboring lines include the closest upper line of the adjacent luminance block but exclude the second-closest upper line because the chroma block is not at the boundary of the top coding tree unit.

[0212] 10. The method according to item 1, wherein N is greater than 1.

[0213] 11. The method according to item 10, wherein the N upper neighboring lines include the nearest upper line and the second nearest upper line.

[0214] 12. The method according to item 1, wherein the downsampling filter depends on the color format of the image.

[0215] 13. The method according to any one of items 1 to 12, wherein the downsampling filter is a 6-tap filter.

[0216] 14. The method according to any one of items 1 to 12, wherein the downsampling filter is a 5-tap filter.

[0217] 15. The method according to any one of items 1 to 14, wherein the conversion comprises encoding the video into the bitstream representation.

[0218] 16. A method according to any one of items 1 to 14, wherein the conversion comprises decoding the video from the bitstream representation.

[0219] 17. A video processing device comprising a processing device configured to perform the method according to any one or more of items 1 to 16.

[0220] 18. A computer-readable medium having stored thereon program code that, when executed, causes a processing device to perform the method recited in any one or more of items 1 to 16.

[0221] 19. A computer-readable medium storing a bitstream representation generated according to any of the methods described above.

[0222] The third set of items describes particular features and aspects of the techniques disclosed in the previous section (eg, items 2-7).

[0223] 1. A video processing method (e.g., method 1610 shown in FIG. 16A) including determining 1612 a maximum allowable block size for a video block coded using a transform skip mode for conversion between a video domain of a component of the video and a bitstream representation of the video, and performing 1614 the conversion based on the determination.

[0224] 2. The method of claim 1, wherein the transform skip mode includes, during encoding, coding a residual of the video block without applying a non-identity transform, or, during decoding, determining a decoded video block without applying a non-identity inverse transform to the residual coded in the bitstream representation.

[0225] 3. The method according to item 1, wherein the transform skip mode includes BDPCM (Block Differential Pulse Code Modulation), which corresponds to an intra-coding tool that uses Differential Pulse Code Modulation (DPCM) at the block level.

[0226] 4. The method according to item 1, wherein the maximum allowable block size depends on whether the transform-skipped block is a chroma block or a luminance block.

[0227] 5. The method according to item 1, wherein the maximum allowable block size depends on the chroma components of the transform-skipped block.

[0228] 6. The method of item 1, wherein the maximum allowed block size for luminance blocks (MaxTsSizeY) and the maximum allowed block size for chroma blocks (MaxTsSizeC) are signaled separately in the bitstream representation.

[0229] 7. The method of item 6, wherein MaxTsSizeC and / or MaxTsSizeY are signaled at the sequence level, picture level, slice level, or tile group level.

[0230] 8. The method of claim 6, wherein the MaxTsSizeY is conditionally signaled based on an enablement state of the transform skip mode.

[0231] 9. The method of item 6, wherein the MaxTsSizeY is conditionally signaled based on a color format and / or an enabled state of the transform skip mode.

[0232] 10. The method according to item 1, wherein the conversion is performed by utilizing predictive coding between the maximum block size of the luminance component and the maximum block size of the chroma component.

[0233] 11. The method of claim 1, wherein the video block is a chroma video block, and the maximum allowed block size (MaxTsSizeC) for the video block depends on the maximum allowed block size (MaxTsSizeY) for another video block of a luminance component.

[0234] 12. The method of item 11, wherein MaxTsSizeC is set equal to MaxTsSizeY.

[0235] 13. The method of item 11, wherein MaxTsSizeC is set equal to MaxTsSizeY / N, where N is an integer.

[0236] 14. The method of claim 1, wherein the video block is a chroma video block, and a maximum allowable block size (MaxTsSizeC) for the video block is set according to a chroma subsampling ratio.

[0237] 15. The method according to item 14, wherein MaxTsSizeC is set equal to i) MaxTsSizeY>>SubWidthC, ii) MaxTsSizeY>>SubHeightC, iii) MaxTsSizeY>>max(SubWidthC,SubHeightC), iv) MaxTsSizeY>>min(SubWidthC,SubHeightC), where MaxTsSiZeY indicates the maximum block size of a luma video block, and SubWidthC and SubHeightC are predefined.

[0238] 16. A video processing method (e.g., method 1610 shown in FIG. 16A) comprising converting between a video including a video block and a bitstream representation of the video according to a first rule and a second rule, wherein a transform skip coding tool is used to code a first portion of the video block, and a transform coding tool is used to code a second portion of the video block, the first rule specifying a maximum allowable block size for the first portion of the video block, the second rule specifying a maximum allowable block size for the second portion of the video block, and the maximum allowable block size for the first portion of the video block differs from the maximum allowable block size for the second portion of the video block.

[0239] 17. The method according to item 16, wherein the maximum allowable block size corresponds to the width and height of the corresponding block.

[0240] 18. The method of item 17, wherein the width and height of the maximum allowable block size are signaled separately.

[0241] 19. For a second portion of the video blocks that are chroma blocks, the width (MaxTsSizeWC) is set equal to MaxTsSizeY>>SubWidthC and the height (MaxTsSizeHC) is set equal to MaxTsSizeY>>SubHeightC, where MaxTsSizeY indicates the maximum allowed block size for luma blocks. Item 17. The method according to item 17.

[0242] 20. A method of processing video (e.g., method 1610 shown in FIG. 16A ), comprising converting between video including one or more chroma blocks and a bitstream representation of said video, wherein the bitstream representation complies with format rules specifying that whether a syntax element indicating use of a transform skip tool is included in the bitstream representation depends on the maximum allowable size of a chroma block coded using the transform skip tool.

[0243] 21. The method of claim 20, wherein the transform skipping tool includes bypassing a transform or applying an identity transform.

[0244] 22. The method of item 20, wherein a syntax element is signaled if tbW is less than or equal to MaxTsSizeC and tbH is less than or equal to MaxTsSizeC, where tbW and tbH are the width and height of the chroma block, respectively, and MaxTsSizeC is the maximum allowable size of the chroma block, respectively.

[0245] 23. The method of item 20, wherein a syntax element is signaled if tbW is less than or equal to MaxTsSizeWC and tbH is less than or equal to MaxTsSizeHC, where tbW and tbH are the width and height, respectively, of a chroma block, and MaxTsSizeWC and MaxTsSizeHC represent the width and height, respectively, of the maximum allowable size of a chroma block.

[0246] 24. The method according to claim 20, wherein the transform skip tool comprises a BDPCM (Block Differential Pulse Code Modulation) corresponding to an intra-coding tool using a Differential Pulse Code Modulation (DPCM) mode at the block level.

[0247] 25. A video processing method (e.g., method 1610 shown in FIG. 16A ) that includes converting between a video including one or more first video blocks of a first chroma component and one or more second video blocks of a second chroma component and a bitstream representation of the video, wherein the bitstream representation conforms to format rules that specify the use of syntax elements that together indicate the availability of a transform skip tool for coding the one or more first chroma blocks and the one or more second chroma blocks.

[0248] 26. The method of claim 25, wherein the syntax element has a binary value.

[0249] 27. The method of item 25, wherein the transform skip tool is enabled or disabled in the one or more first video blocks and the one or more second video blocks according to the syntax element.

[0250] 28. The method of item 25, wherein the formatting rules further specify including additional syntax elements in the bitstream representation based on whether the value of the syntax element is equal to K, where K is an integer.

[0251] 29. The method of item 28, wherein the second syntax element is used to indicate which of one or more first video blocks and one or more second video blocks to apply the transform skip tool to.

[0252] 30. The method of claim 25, wherein the syntax element has a non-binary value.

[0253] 31. The method according to item 30, wherein the syntax elements are coded using fixed-length, unary, truncated unary, or k-th order Exponential-Golomb (EG) binarization methods.

[0254] 32. The method of claim 25, wherein the syntax elements are context coded or bypass coded.

[0255] 33. The method of any one of the preceding items, wherein whether and / or how to apply the method is signaled at a sequence level, a picture level, a slice level, or a tile group level.

[0256] 34. The method of any one of the preceding items, wherein the method is further based on coded information.

[0257] 35. A method according to any one of items 1 to 34, wherein the conversion comprises encoding the video into the bitstream representation.

[0258] 36. A method according to any one of items 1 to 34, wherein the conversion includes decoding the video from the bitstream representation.

[0259] 37. A video processing device comprising a processing device configured to implement the method described in any one or more of items 1 to 36.

[0260] 38. A computer-readable medium having stored thereon program code that, when executed, causes a processing device to perform the method recited in any one or more of items 1 to 36.

[0261] 39. A computer-readable medium storing a coded or bitstream representation generated according to any of the methods described above.

[0262] While this patent specification contains many details, these should not be construed as limiting the scope of any subject matter or the scope of the claims, but rather as descriptions of features that may be specific to particular embodiments of a particular technology. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single example. Conversely, various features described in the context of a single example may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while features may be described above as acting in a particular combination and initially claimed as such, one or more features from a claimed combination may, in some cases, be extracted from the combination, and the claimed combination may be directed to subcombinations or variations of the subcombination.

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

[0264] Only a few implementations and examples are described; other embodiments, extensions and variations are possible based on the content described and illustrated in this patent document.

Claims

1. determining a prediction mode to be applied to a chroma block for conversion between a chroma block of an image and a bitstream of the image, wherein prediction samples of the chroma block are derived based on reconstructed luma samples of a luma block adjacent to the chroma block; deriving parameters of the prediction mode based on neighboring chroma samples of the chroma block and a downsampled neighboring top luma sample of the collocated luma block; performing the conversion based on the parameters; different downsampling filters are used depending on different color formats of the chroma blocks and different values ​​of the variable SubHeightC; if the chroma block has a 4:2:0 color format, the variable SubHeightC is equal to 2, a chroma juxtaposition flag is equal to 0, the chroma block is not at a top coding tree unit boundary, and the top luma sample of the downsampled neighborhood is derived based on at least a second-closest upper neighboring line of the juxtaposed luma block; if the chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top-most coding tree unit, the chroma block has a 4:2:0 color format, and the chroma juxtaposition flag is included in a sequence parameter set in the bitstream; (pY[SubWidthC*x-1][-1]+pY[SubWidthC*x-1][-2]+2*pY[SubWidthC*x][-1]+2*pY[SubWidthC*x][-2]+pY[SubWidthC*x+1][-1]+pY[SubWidthC*x+1][-2]+4)>>3 is used to derive the top luminance sample of at least one downsampled neighborhood, pY[SubWidthC*x-1][-1], pY[SubWidthC*x-1][-2], pY[SubWidthC*x][-1], pY[SubWidthC*x][-2], pY[SubWidthC*x+1][-1], pY[SubWidthC*x+1][-2] indicate luminance samples from neighboring lines of said juxtaposed luminance blocks; if the chroma block has a 4:2:0 color format, x is an integer and SubWidthC is equal to 2; a first syntax element specifying a maximum block size for a transform skip mode is conditionally included in the bitstream based on a value of a transform skip enable flag included in the sequence parameter set in the bitstream; Image processing methods.

2. In response to the chroma block having a 4:2:2 color format, a second upper neighboring line of the juxtaposed luma block is excluded to derive the uppermost luma sample of the downsampled neighborhood. The method of claim 1.

3. In response to the chroma block having a 4:2:2 color format, the same downsampling filter is used to derive the top luma sample of the downsampled neighborhood regardless of whether the chroma block is at the top coding tree unit boundary.

3. The method according to claim 1 or 2.

4. In response to the chroma block being at the top coding tree unit boundary, the top luma sample of the downsampled neighborhood is derived based on a nearest upper neighboring line of the juxtaposed luma block. The method of claim 3.

5. pDsY[x]=(pY[2*x-1][-1]+2*pY[2*x][-1]+pY[2*x+1][-1]+2)>>2 in response to the chroma block being at the top coding tree unit boundary or having a 4:2:2 color format; pDsY[x] denotes the top luminance sample in the downsampled neighborhood, pY[2*x][-1], pY[2*x-1][-1], pY[2*x+1] indicate luminance samples from the nearest upper neighboring line of the juxtaposed luminance block; The method of claim 4.

6. the parameters of the prediction mode are further derived based on downsampled neighboring left luminance samples of the juxtaposed luminance block; the downsampled neighboring top luminance sample and the downsampled neighboring left luminance sample are derived using a downsample filter having identical filter coefficients according to the chroma block having a 4:2:2 color format. The method according to any one of claims 1 to 5.

7. The identical filter coefficients are [1, 2, 1]. The method of claim 6.

8. the converting includes encoding the video into the bitstream; The method according to any one of claims 1 to 7.

9. the converting includes decoding the video from the bitstream. The method according to any one of claims 1 to 7.

10. 1. An apparatus for video processing comprising a processor and a non-transitory memory having instructions, the instructions, when executed by the processor, causing the processor to: determining a prediction mode to be applied to a chroma block for conversion between a chroma block of an image and a bitstream of the image, wherein prediction samples of the chroma block are derived based on reconstructed luma samples of a luma block adjacent to the chroma block; deriving parameters of the prediction mode based on neighboring chroma samples of the chroma block and a downsampled neighboring top luma sample of the collocated luma block; performing the conversion based on the parameters; different downsampling filters are used depending on different color formats of the chroma blocks and different values ​​of the variable SubHeightC; if the chroma block has a 4:2:0 color format, the variable SubHeightC is equal to 2, a chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top coding tree unit, and the top luma sample of the downsampled neighborhood is derived based on at least a second-closest upper neighboring line of the juxtaposed luma block; if the chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top-most coding tree unit, the chroma block has a 4:2:0 color format, and the chroma juxtaposition flag is included in a sequence parameter set in the bitstream; (pY[SubWidthC*x-1][-1]+pY[SubWidthC*x-1][-2]+2*pY[SubWidthC*x][-1]+2*pY[SubWidthC*x][-2]+pY[SubWidthC*x+1][-1]+pY[SubWidthC*x+1][-2]+4)>>3 is used to derive the top luminance sample of at least one downsampled neighborhood, pY[SubWidthC*x-1][-1], pY[SubWidthC*x-1][-2], pY[SubWidthC*x][-1], pY[SubWidthC*x][-2], pY[SubWidthC*x+1][-1], pY[SubWidthC*x+1][-2] indicate luminance samples from neighboring lines of said juxtaposed luminance blocks; if the chroma block has a 4:2:0 color format, x is an integer and SubWidthC is equal to 2; a first syntax element specifying a maximum block size for a transform skip mode is conditionally included in the bitstream based on a value of a transform skip enable flag included in the sequence parameter set in the bitstream; Device.

11. A non-transitory computer-readable storage medium storing instructions, the instructions causing a processor to: determining a prediction mode to be applied to a chroma block for conversion between a chroma block of an image and a bitstream of the image, wherein prediction samples of the chroma block are derived based on reconstructed luma samples of a luma block adjacent to the chroma block; deriving parameters of the prediction mode based on neighboring chroma samples of the chroma block and a downsampled neighboring top luma sample of the collocated luma block; performing the conversion based on the parameters; different downsampling filters are used depending on different color formats of the chroma blocks and different values ​​of the variable SubHeightC; if the chroma block has a 4:2:0 color format, the variable SubHeightC is equal to 2, a chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top coding tree unit, and the top luma sample of the downsampled neighborhood is derived based on at least a second-closest upper neighboring line of the juxtaposed luma block; if the chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top-most coding tree unit, the chroma block has a 4:2:0 color format, and the chroma juxtaposition flag is included in a sequence parameter set in the bitstream; (pY[SubWidthC*x-1][-1]+pY[SubWidthC*x-1][-2]+2*pY[SubWidthC*x][-1]+2*pY[SubWidthC*x][-2]+pY[SubWidthC*x+1][-1]+pY[SubWidthC*x+1][-2]+4)>>3 is used to derive the top luminance sample of at least one downsampled neighborhood, pY[SubWidthC*x-1][-1], pY[SubWidthC*x-1][-2], pY[SubWidthC*x][-1], pY[SubWidthC*x][-2], pY[SubWidthC*x+1][-1], pY[SubWidthC*x+1][-2] indicate luminance samples from neighboring lines of said juxtaposed luminance blocks; if the chroma block has a 4:2:0 color format, x is an integer and SubWidthC is equal to 2; a first syntax element specifying a maximum block size for a transform skip mode is conditionally included in the bitstream based on a value of a transform skip enable flag included in the sequence parameter set in the bitstream; A non-transitory computer-readable storage medium.

12. 1. A method for storing a video bitstream, comprising: determining a prediction mode to be applied to a chroma block for conversion between a chroma block of an image and a bitstream of the image, wherein prediction samples of the chroma block are derived based on reconstructed luma samples of a luma block adjacent to the chroma block; deriving parameters of the prediction mode based on neighboring chroma samples of the chroma block and a downsampled neighboring top luma sample of the collocated luma block; generating the bitstream based on the parameters; storing the bitstream on a non-transitory computer-readable storage medium; different downsampling filters are used depending on different color formats of the chroma blocks and different values ​​of the variable SubHeightC; if the chroma block has a 4:2:0 color format, the variable SubHeightC is equal to 2, a chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top coding tree unit, and the top luma sample of the downsampled neighborhood is derived based on at least a second-closest upper neighboring line of the juxtaposed luma block; if the chroma juxtaposition flag is equal to 0, the chroma block is not at a boundary of a top-most coding tree unit, the chroma block has a 4:2:0 color format, and the chroma juxtaposition flag is included in a sequence parameter set in the bitstream; (pY[SubWidthC*x-1][-1]+pY[SubWidthC*x-1][-2]+2*pY[SubWidthC*x][-1]+2*pY[SubWidthC*x][-2]+pY[SubWidthC*x+1][-1]+pY[SubWidthC*x+1][-2]+4)>>3 is used to derive the top luminance sample of at least one downsampled neighborhood, pY[SubWidthC*x-1][-1], pY[SubWidthC*x-1][-2], pY[SubWidthC*x][-1], pY[SubWidthC*x][-2], pY[SubWidthC*x+1][-1], pY[SubWidthC*x+1][-2] indicate luminance samples from neighboring lines of said juxtaposed luminance blocks; if the chroma block has a 4:2:0 color format, x is an integer and SubWidthC is equal to 2; a first syntax element specifying a maximum block size for a transform skip mode is conditionally included in the bitstream based on a value of a transform skip enable flag included in the sequence parameter set in the bitstream; method.

Images