Size Limitations Based on Color Format

Abstract

A method for video processing is provided, including: performing a conversion between a video and an encoded / decoded representation of the video according to a rule, where the video includes one or more video regions each including one or more luminance blocks and one or more chrominance blocks; wherein the rule specifies that an intra mode or an intra block copy mode is not allowed to represent a chrominance block with a size of MxN in the one or more chrominance blocks in the encoded / decoded representation, where M and N are integers indicating the width and height of the chrominance block respectively; wherein the intra mode includes encoding the chrominance block based on previously encoded or reconstructed video blocks, and wherein the intra block copy mode includes encoding the chrominance block using at least a block vector pointing to a video frame including the video region.

Description

[0001] Cross - reference to related applications

[0002] In accordance with applicable patent laws and / or the rules applicable to the Paris Convention, this application timely claims the priority and benefits of International Patent Application No. PCT / CN2019 / 099447, filed on August 6, 2019. For all purposes of law, the entire disclosure of the above - mentioned application is incorporated by reference as part of the disclosure of this application. Technical Field

[0003] This document relates to video and image encoding, decoding, and transcoding technologies. Background Art

[0004] Digital video occupies the largest bandwidth usage on the Internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video usage is expected to continue to grow. Summary of the Invention

[0005] The disclosed technology can be implemented by video or image decoder or encoder embodiments, in which reference pictures are used in video encoding or decoding.

[0006] In one exemplary aspect, a method of video processing is disclosed. The method includes: determining a segmentation scheme for dividing a chrominance video region of a video into one or more chrominance blocks based on a rule according to a color format of the video; and converting between the video and a codec representation of the video according to the segmentation scheme.

[0007] In another exemplary aspect, another method of video processing is disclosed. The method includes: determining a prediction mode or prediction type for sub - blocks of a codec tree node of a video based on a color format of the video; and converting between the video and a codec representation of the video based on the determination, wherein the codec tree node is divided into sub - blocks for encoding and decoding in the codec representation.

[0008] In another exemplary aspect, another method of video processing is disclosed. The method includes: converting between a video and a codec representation of the video according to a rule, the video including one or more video regions each including one or more luma blocks and one or more chrominance blocks; wherein the rule specifies that an in - frame mode or an in - frame block copy mode is not allowed to represent a chrominance block of size MxN in one or more chrominance blocks in the codec representation, where M and N are integers indicating the width and height of the chrominance block respectively; wherein the in - frame mode includes encoding a chrominance block based on a previously encoded or reconstructed video block, and wherein the in - frame block copy mode includes encoding a chrominance block using at least a block vector pointing to a video frame including the video region.

[0009] In another example aspect, another method for video processing is disclosed. The method includes: for the conversion between the video region of a video and the coded representation of the video, determining to use a combined inter and intra prediction (CIIP) mode as an intra mode or an inter mode according to a rule; and performing the conversion based on the determination, and wherein the CIIP mode includes using a weighting coefficient to combine an intra prediction signal and an inter prediction signal.

[0010] In another example aspect, another method for video processing is disclosed. The method includes: performing a conversion between a chrominance block of a video and the coded representation of the video, wherein the chrominance block is represented in the coded representation using an intra coding mode according to a size rule; where the size rule specifies that in the case where the width of the chrominance block is equal to M or the height of the chrominance block is equal to N, where M and N are integers, the intra coding mode is from a first set of intra coding mode types; otherwise, the intra coding mode is from a second set of intra coding mode types.

[0011] In another example aspect, another method for video processing is disclosed. The method includes: performing a conversion between a chrominance block of a video and the coded representation of the video, wherein the chrominance block is represented in the coded representation using a transform type according to a rule; where the rule specifies that in the case where the width of the chrominance block is equal to M or the height of the chrominance block is equal to N, where M and N are integers, the transform type is from a first set of transform types; otherwise, the transform type is from a second set of transform types.

[0012] In another example aspect, another method for video processing is disclosed. The method includes: performing a conversion between a video and the coded representation of the video according to a rule, the video including a video region having one or more luma blocks and one or more chrominance blocks, where the rule specifies that the use of the intra block copy (IBC) mode can be used for one or more luma blocks and one or more chrominance blocks having a block size of MxN, for all values of M and N, where M and N are integers; where, using the IBC mode, at least a block vector pointing to a video frame containing the video block is used to decode the video block.

[0013] In another example aspect, another method for video processing is disclosed. The method includes: performing a conversion between a video block of a video and the coded representation of the video block, wherein the coded representation conforms to a formatting rule, where the formatting rule specifies selectively including a syntax element indicating the use of the inter block copy (IBC) mode in the coded representation based on the mode type of the video block, and wherein the IBC mode includes encoding the video block using at least a block vector pointing to a video frame containing the video block.

[0014] In another example aspect, another method for video processing is disclosed. The method includes: converting between a video block of a video and an encoded / decoded representation of the video block, where the encoded / decoded representation conforms to formatting rules, where the formatting rules specify that regardless of the mode type of the video block, a syntax element indicating the use of the palette mode is included in the encoded / decoded representation, and where the palette mode includes encoding the video block using a palette of representative sample values.

[0015] In another example aspect, another method for video processing is disclosed. The method includes: for the conversion between a video region of a video and an encoded / decoded representation of the video, determining, based on rules, that the use of the inter-block copy (IBC) mode is permitted for the video region; and performing the conversion based on the determination, where the IBC mode includes encoding the video region using at least block vectors pointing to video frames containing the video region.

[0016] In another example aspect, another method for video processing is disclosed. The method includes: for the conversion between a video region of a video and an encoded / decoded representation of the video, determining, based on rules, whether the use of the palette mode is permitted for the video region; and performing the conversion based on the determination, where the rules are based on the encoded / decoded mode type of the video region or the color type of the video region; and where the palette mode includes encoding the video region using a palette of representative sample values.

[0017] In yet another example aspect, the above method can be implemented by a video encoder device including a processor.

[0018] In yet another example aspect, the above method can be implemented by a video decoder device including a processor.

[0019] In yet another example aspect, these methods can be implemented in the form of processor-executable instructions and stored on a computer-readable program medium.

[0020] These and other aspects are further described in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 An example of an intra-block copy encoding / decoding tool is shown.

[0022] Figure 2 An example of a block encoded / decoded in the palette mode is shown.

[0023] Figure 3 An example of signaling palette entries using a palette predictor is shown.

[0024] Figure 4 Examples in examples of horizontal and vertical traversal scans are shown.

[0025] Figure 5 Shows an example of encoding and decoding palette indices.

[0026] Figure 6 Shows an example of 67 intra prediction modes.

[0027] Figure 7 Shows examples of the left and upper neighborhoods of the current block.

[0028] Figure 8 Shows an example of the ALF filter shape (chrominance: 5×5 rhombus, luminance: 7×7 rhombus).

[0029] Figure 9 Shows an example of subsampled Laplacian calculation.

[0030] Figure 10 Shows an example of modified block classification at the virtual boundary.

[0031] Figure 11 Is an example of modified ALF filtering for the luminance component at the virtual boundary.

[0032] Figure 12 Shows examples of four 1D 3-pixel patterns of pixel classification in EO.

[0033] Figure 13 Shows that four bands are grouped together and represented by their starting band positions.

[0034] Figure 14 Shows the top and left neighborhood blocks used in CIIP weight derivation.

[0035] Figure 15 Shows luminance mapping with a chrominance scaling architecture.

[0036] Figure 16 Shows an example of SCIPU.

[0037] Figure 17A and 17B Is a block diagram of an example of a hardware platform for implementing the technologies described in this document.

[0038] Figure 18 Is a flowchart of an example method for video processing.

[0039] Figure 19 Shows an example of the position of spatial Merge candidates.

[0040] Figure 20 Shows an example of candidate pairs considering redundancy checking for spatial Merge candidates.

[0041] Figure 21A and21B A flowchart showing an example method of video processing based on some implementations of the disclosed technology.

[0042] Figure 22A and 22B A flowchart showing an example method of video processing based on some implementations of the disclosed technology.

[0043] Figure 23A and 23B A flowchart showing an example method of video processing based on some implementations of the disclosed technology. Detailed Description

[0044] This document 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 the sake of brevity, the term "video" is used herein to include sequences of pictures (traditionally called video) and individual images. Additionally, a video encoder can also implement these techniques during the encoding process to reconstruct decoded frames for further encoding.

[0045] The section headings are used in this document for ease of understanding and do not limit the embodiments and techniques to the corresponding sections. Thus, the embodiments of one section can be combined with the embodiments of other sections.

[0046] 1. Overview

[0047] This document is related to video codec technology. Specifically, it relates to palette coding and decoding that employs a base - color - based representation in video codec. It can be applied to existing video codec standards (such as HEVC) or standards to be finalized (Universal Video Coding). It may also be applicable to future video codec standards or video encoders.

[0048] 2. Preliminary Discussion

[0049] Video coding standards have evolved mainly through the development of well-known ITU-T and ISO / IEC standards. ITU-T produced H.261 and H.263, ISO / IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced the H.262 / MPEG-2 video and H.264 / MPEG-4 Advanced Video Coding (AVC) and H.265 / HEVC standards. Starting from H.262, video coding standards are based on a hybrid video coding structure, which utilizes temporal prediction plus transform coding. To explore future video coding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and incorporated them into a reference software called the "Joint Exploration Model" (JEM). In April 2018, the Joint Video Experts Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) was founded, dedicated to the VVC standard, with the goal of reducing the bitrate by 50% compared to HEVC.

[0050] The latest version of the VVC draft can be found at the following location, namely the Versatile Video Coding (Draft 4):

[0051] http: / / phenix.it-sudparis.eu / jvet / doc_end_user / current_document.php?id=5755

[0052] The latest reference software for VVC called VTM can be found at the following location:

[0053] https: / / vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM / tags / VTM-5.0

[0054] 2.1 Intra Block Copy

[0055] Intra Block Copy (IBC), also known as current picture reference, has been adopted in the HEVC Screen Content Coding Extension (HEVC-SCC) and the current VVC test model (through VTM-4.0). IBC extends the concept of motion compensation from inter coding to intra coding. As Figure 1As shown, when applying IBC, the current block is predicted from the reference block in the same picture. Before encoding / decoding or decoding the current block, the samples in the reference block must have been reconstructed. Although IBC is not efficient for most sequences captured by cameras, it shows significant encoding / decoding gains for screen content. The reason is that there are many repetitive patterns in screen content pictures, such as icons and text characters. IBC can effectively remove the redundancy between these repetitive patterns. In HEVC-SCC, if the current picture is selected as a reference picture, the inter-frame coding unit (CU) can apply IBC. In this case, the MV is renamed as the block vector (BV), and the BV always has integer pixel precision. To be compatible with the main profile HEVC, the current picture is marked as a "long-term" reference picture in the decoded picture buffer (DPB). It should be noted that, similarly, in the multi-view / 3D video coding standard, the inter-view reference pictures are also marked as "long-term" reference pictures.

[0056] After the BV finds its reference block, the prediction can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Then, the transform and quantization can be applied as in other coding modes.

[0057] Figure 1 is an illustration of intra-block copy.

[0058] However, when the reference block is outside the picture, or overlaps with the current block, or is outside the reconstructed area, or is outside the valid area restricted by some constraints, some or all of the pixel values are not defined. Basically, there are two ways to solve this problem. One is to not allow such a situation, for example, in terms of bitstream consistency. The other is to apply padding to those undefined pixel values. The following subsections describe the solutions in detail.

[0059] 2.2 IBC in HEVC Screen Content Coding Extension

[0060] In the HEVC screen content coding extension, when a block uses the current picture as a reference, it should be ensured that the entire reference block is within the available reconstructed area, as shown in the following specification text:

[0061] The derivation of the variables offsetX and offsetY is as follows:

[0062] offsetX = (ChromaArrayType == 0)? 0 : (mvCLX[0] & 0x7? 2 : 0)

[0063] (8 - 104)

[0064] offsetY = (ChromaArrayType == 0)? 0 : (mvCLX[1] & 0x7? 2 : 0)

[0065] (8-105)

[0066] For the requirements of bitstream consistency, when the reference picture is the current picture, the luminance motion vector mvLX shall follow the following restrictions:

[0067] - When calling the export process of z-scan order block availability specified in Section 6.4.1 with the input of (xCurr, yCurr) set to (xCb, yCb) and the adjacent luminance position (xNbY, yNbY) set to be equal to (xPb+(mvLX[0]>>2)-offsetX, yPb+(mvLX[1]>>2)-offsetY), the output shall be TRUE.

[0068] - When calling the export process of z-scan order block availability specified in Section 6.4.1 with the input of (xCurr, yCurr) set to (xCb, yCb) and the adjacent luminance position (xNbY, yNbY) set to be equal to (xPb+(mvLX[0]>>2)+nPbW-1+offsetX, yPb+(mvLX[1]>>2)+nPbH-1+offsetY), the output shall be TRUE.

[0069] - One or both of the following conditions shall be true:

[0070] - The value of (mvLX[0]>>2)+nPbW+xB1+offsetX is less than or equal to 0.

[0071] - The value of (mvLX[1]>>2)+nPbH+yB1+offsetY is less than or equal to 0.

[0072] - The following condition shall be true:

[0073] (xPb+(mvLX[0]>>2)+nPbSw-1+offsetX) / CtbSizeY-xCurr / CtbSizeY <= yCurr / CtbSizeY-(yPb+(mvLX[1]>>2)+nPbSh-1+offsetY) / CtbSizeY (8-106)

[0074] Therefore, there will be no situation where the reference block overlaps with the current block or the reference block is outside the picture. There is no need to fill the reference block or the prediction block.

[0075] 2.3 IBC in the VVC Test Model

[0076] In the current VVC test model, i.e., the VTM-4.0 design, the entire reference block should be within the current coding tree unit (CTU) and not overlap with the current block. Therefore, there is no need to pad the reference block or the prediction block. The IBC flag is coded as the prediction mode of the current CU. Therefore, for each CU, there are a total of three prediction modes: MODE_INTRA, MODE_INTER, and MODE_IBC.

[0077] 2.3.1 IBC Merge Mode

[0078] In the IBC Merge mode, an index pointing to an entry in the IBC Merge candidate list is parsed from the bitstream. The construction of the IBC Merge list can be summarized in the following steps in sequence:

[0079] Step 1: Derive spatial candidates

[0080] Step 2: Insert HMVP candidates

[0081] Step 3: Insert pairwise average candidates

[0082] When deriving spatial Merge candidates, at most four Merge candidates are selected from the candidates located at the Figure 19 shown positions. The derivation order is A1, B1, B0, A0, and B2. Position B2 is considered only when any of the PUs at positions A1, B1, B0, A0 is not available (e.g., because it belongs to another strip or slice) or is not coded using the IBC mode. After adding the candidate at position A1, a redundancy check is performed on the insertion of the remaining candidates to ensure that candidates with the same motion information are excluded from the list, thus improving the coding efficiency. To reduce the computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Instead, only the pairs linked by the Figure 20 arrows are considered, and a candidate is added to the list only if the corresponding candidate used for the redundancy check does not have the same motion information.

[0083] After inserting the spatial candidates, if the IBC Merge list size is still less than the maximum IBC Merge list size, IBC candidates from the HMVP table can be inserted. A redundancy check is performed when inserting HMVP candidates.

[0084] Finally, the pairwise average candidates are inserted into the IBC Merge list.

[0085] When the reference block identified by a Merge candidate is outside the picture, or overlaps with the current block, or is outside the reconstructed region, or is outside the valid region restricted by some constraints, the Merge candidate is called an invalid Merge candidate.

[0086] Note that invalid Merge candidates can be inserted into the IBC Merge list.

[0087] 2.3.2 IBC AMVP Mode

[0088] In the IBC AMVP mode, the AMVP index pointing to an entry in the IBC AMVP list is parsed from the bitstream. The construction of the IBC AMVP list can be summarized in the following steps in sequence:

[0089] Step 1: Derive spatial candidates

[0090] Check A0, A1 until an available candidate is found.

[0091] Check B0, B1, B2 until an available candidate is found.

[0092] Step 2: Insert HMVP candidates

[0093] Step 3: Insert zero candidates

[0094] After inserting the spatial candidates, if the IBC AMVP list size is still less than the maximum IBC AMVP list size, IBC candidates from the HMVP table can be inserted.

[0095] Finally, zero candidates are inserted into the IBC AMVP list.

[0096] 2.4 Palette Mode

[0097] The basic idea behind the palette mode is that the samples in a CU are represented by a small set of representative color values. This set is called the palette. Also, samples outside the palette may be indicated by signaling an escape symbol followed by (possibly quantized) component values. Such samples are called escape samples. The palette mode is as Figure 2 shown.

[0098] Figure 2 shows an example of a block encoded and decoded in the palette mode.

[0099] 2.5 Palette Mode in High Efficiency Video Coding Screen Content Coding Extension (HEVC-SCC)

[0100] In the palette mode of HEVC-SCC, a prediction method is used to encode and decode the palette and the index map.

[0101] 2.5.1 Encoding and Decoding of Palette Entries

[0102] To encode and decode palette entries, a palette predictor is maintained. The maximum size of the palette and the palette predictor are signaled in the SPS. In HEVC-SCC, the palette_predictor_initializer_present_flag is introduced in the PPS. When this flag is 1, the entries used to initialize the palette predictor are signaled in the bitstream. The palette predictor is initialized at the start of each CTU row, each slice, and each tile. Depending on the value of the palette_predictor_initializer_present_flag, the palette predictor is reset to 0 or initialized with the palette predictor initializer entries signaled in the PPS. In HEVC-SCC, a palette predictor initializer of size 0 is enabled to allow explicit disabling of palette predictor initialization at the PPS level.

[0103] For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette. This is as Figure 3 shown. The reuse flags are sent using run-length encoding of zeros. Thereafter, the number of new palette entries is signaled using an exponential Golomb code of order 0. Finally, the component values of the new palette entries are signaled.

[0104] Figure 3 An example of signaling palette entries using the palette predictor is shown.

[0105] 2.5.2 Palette Index Encoding and Decoding

[0106] As Figure 4 shown, the palette indices are encoded and decoded using horizontal and vertical traversal scans. The scan order is explicitly signaled in the bitstream using the palette_transpose_flag. For the remainder of the subsection, a horizontal scan is assumed.

[0107] Figure 4 Examples of horizontal and vertical traversal scans are shown.

[0108] The palette indices are encoded and decoded using two main palette sample point patterns: "INDEX" and "COPY_ABOVE". As previously mentioned, the escape symbol is also signaled as the "INDEX" pattern and is assigned an index equal to the maximum palette size. This pattern is signaled using a flag other than the top row or when the previous pattern was "COPY_ABOVE". In the "COPY_ABOVE" pattern, the palette index of the sample in the row above is copied. In the "INDEX" pattern, the palette index is explicitly signaled. For both the "INDEX" and "COPY_ABOVE" patterns, a run value is signaled, which specifies the number of subsequent samples that are also encoded and decoded using the same pattern. When the escape symbol is part of a run in the "INDEX" or "COPY_ABOVE" pattern, an escape component value is signaled for each escape symbol. The encoding and decoding of the palette indices are as Figure 5 shown.

[0109] The syntax order is completed as follows. First, the number of index values for the CU is signaled. This is followed by signaling the actual index values for the entire CU using truncated binary encoding. Both the number of indices and the index values are encoded in bypass mode. This groups the bypass binary numbers (bins) related to the indices together. Then, the palette sample point patterns (if required) and runs are signaled in an interleaved manner. Finally, the component escape values corresponding to the escape samples of the entire CU are grouped together and encoded in bypass mode.

[0110] After signaling the index values, an additional syntax element, last_run_type_flag, is signaled. This syntax element combines with the number of indices, eliminating the need to signal the run value corresponding to the last run in the block.

[0111] In HEVC-SCC, the palette mode is also enabled for 4:2:2, 4:2:0, and monochrome chroma formats. For all chroma formats, the signaling of the palette entries and palette indices is almost the same. In the case of non-monochrome formats, each palette entry consists of 3 components. For monochrome formats, each palette entry consists of a single component. For subsampled chroma directions, the chroma samples are associated with luminance sample indices that are divisible by 2. After reconstructing the palette indices for the CU, if a sample has only a single component associated with it, only the first component of the palette entry is applicable. The only difference in signaling is the escape component value. For each escape sample, depending on the number of components associated with the sample, the number of escape component values signaled may vary.

[0112] In VVC, the dual-tree codec structure is used for encoding and decoding intra-bands, so the luminance component and the two chrominance components can have different palettes and palette indices. Additionally, the two chrominance components share the same palette and palette index.

[0113] Figure 5 An example of encoding and decoding palette indices is shown.

[0114] 2.6 Intra-mode encoding and decoding in VVC

[0115] To capture any edge direction presented in natural videos, the number of directional intra-modes in VTM5 is extended from 33 used in HEVC to 65. The new directional modes not available in HEVC are depicted by red dashed arrows in Figure 6 and the planar and DC modes remain the same. These denser directional intra-prediction modes apply to all block sizes as well as luminance and chrominance intra-prediction.

[0116] In VTM5, for non-square blocks, several conventional angular intra-prediction modes are adaptively replaced by wide-angle intra-prediction modes.

[0117] In HEVC, each intra-encoding and decoding block has a square shape and the length of each of its sides is a power of 2. Therefore, no division operation is required to generate an intra-predictor using the DC mode. In VTM5, blocks can have a rectangular shape, which usually requires a division operation for each block. For DC prediction, to avoid division operations, only the longer side is used to calculate the average for non-square blocks.

[0118] Figure 6 An example of 67 intra-prediction modes is shown.

[0119] To keep the complexity of the most probable mode (MPM) list generation low, an intra-mode encoding and decoding method with 6 MPMs is used by considering two available neighboring intra-modes. The following three aspects are considered to construct the MPM list:

[0120] - Default intra-mode

[0121] - Neighboring intra-modes

[0122] - Derived intra-modes

[0123] Regardless of whether MRL and ISP encoding and decoding tools are applied, a unified 6-MPM list is used for intra-blocks. The MPM list is constructed based on the intra-modes of the left and upper neighboring blocks. Assuming the mode of the left block is represented as Left and the mode of the upper block is represented as Above, the construction of the unified MPM list is as follows (the left block and the upper block are as Figure 7 shown):

[0124] Figure 7 They are examples of the left area and the upper area of the current block.

[0125] – When the neighboring block is not available, its internal mode is default set to planar.

[0126] – If both Left and Above are non-angular modes:

[0127] ○MPM list → {Planar, DC, V, H, V-4, V+4}

[0128] – If one of "Left" and "Above" is an angular mode and the other is a non-angular mode:

[0129] ○ Set mode Max as the maximum mode among "Left" and "Above"

[0130] ○MPM list → {Planar, Max, DC, Max-1, Max+1, Max-2}

[0131] – If Left and Above are both angular and they are different:

[0132] ○ Set mode Max as the maximum mode among "Left" and "Above"

[0133] ○ If the difference between the modes "Left" and "Above" is in the range of 2 to 62 (including the end values)

[0134] ■MPM list → {Planar, Left, Above, DC, Max-1, Max+1}

[0135] ○ Otherwise

[0136] ■MPM list → {Planar, Left, Above, DC, Max-2, Max+2}

[0137] – If Left and Above are both angular and they are the same:

[0138] ○MPM list → {Planar, Left, Left-1, Left+1, DC, Left-2}

[0139] In addition, the first binary number of the mpm index codeword is CABAC context encoded and decoded. A total of three contexts are used, corresponding to whether the block within the current frame is an MRL-enabled block, an ISP-enabled block, or a normal intra-block.

[0140] During the generation of the 6 MPM lists, pruning is used to remove duplicate patterns so that only unique patterns can be included in the MPM list. For entropy coding / decoding of 61 non-MPM patterns, Truncated Binary Code (TBC) is used.

[0141] For chrominance intra mode coding / decoding, a total of 8 intra modes are allowed for chrominance intra mode coding / decoding. These modes include 5 traditional intra modes and 3 Cross-Component Linear Model modes (CCLM, LM_A, and LM_L). The chrominance mode signaling and derivation processes are shown in Table 2-4. The chrominance mode coding / decoding directly depends on the intra prediction mode of the corresponding luma block. Since a separate block splitting structure for luma and chrominance components is enabled in an I slice, one chrominance block can correspond to multiple luma blocks. Therefore, for the chrominance DM mode, the intra prediction mode of the corresponding luma block covering the center position of the current chrominance block is directly inherited.

[0142] Table 2-4 Deriving Chrominance Prediction Modes from Luma Modes when CCLM is Enabled

[0143]

[0144] 2.7 Quantized Residual Block Differential Pulse Coding Modulation (QR-BDPCM)

[0145] In JVET-M0413, a Quantized Residual Block Differential Pulse Coding Modulation (QR-BDPCM) is proposed to efficiently code / decode screen content.

[0146] The prediction directions used in QR-BDPCM can be vertical and horizontal prediction modes. Intra prediction for the entire block is performed by replicating samples in a prediction direction (horizontal or vertical prediction) similar to intra prediction. The residuals are quantized, and the increment between the quantized residuals and the quantized values of their predictors (horizontal or vertical) is coded / decoded. This can be described as follows: For a block of size M (rows) × N (columns), let r i,j , 0 ≤ i ≤ M - 1, 0 ≤ j ≤ N - 1 be the prediction residuals after performing intra prediction horizontally (copying pixel values of the left neighborhood line by line on the prediction block) or vertically (copying the top neighborhood line to each line in the prediction block) using unfiltered samples from the upper block or left block boundary samples. Let Q(r i,j ), 0 ≤ i ≤ M - 1, 0 ≤ j ≤ N - 1 denote the quantized version of the residual r i,j , where the residual is the difference between the original block and the prediction block values. Then, block DPCM is applied to the quantized residual samples, resulting in a modified M × N array with elements When signaling vertical BDPCM: ​

[0147]

[0148] For horizontal prediction, similar rules apply and the samples after residual quantization are obtained as follows:

[0149]

[0150] Samples after residual quantization are sent to the decoder.

[0151] On the decoder side, the above calculations are performed inversely to generate Q(r i,j ), 0 ≤ i ≤ M - 1, 0 ≤ j ≤ N - 1. For the vertical prediction case,

[0152]

[0153] For the horizontal case,

[0154]

[0155] The inverse quantized residual Q -1 (Q(r i,j )) is added to the intra-block prediction value to generate the reconstructed sample value.

[0156] The main advantage of this scheme is that inverse DPCM can be completed instantaneously during coefficient parsing, or a predictor can be simply added when parsing the coefficients, or inverse DPCM can be performed after parsing.

[0157] 2.8 Adaptive Loop Filter

[0158] In VTM5, an Adaptive Loop Filter (ALF) with block-based filter adaptation is applied. For the luminance component, one of 25 filters is selected for each 4×4 block based on the direction and activity of the local gradient.

[0159] 2.8.1.1 Filter Shape

[0160] In VTM5, two diamond filter shapes are used (as Figure 8 shown). A 7×7 diamond is applied to the luminance component, while a 5×5 diamond is applied to the chrominance component.

[0161] Figure 8 An example of the ALF filter shape is shown (chrominance: 5×5 diamond, luminance: 7×7 diamond)

[0162] 2.8.1.2 Block Classification

[0163] For the luminance component, each 4×4 block is classified into one of 25 classes. The classification index C is based on the quantization values of its directionality D and activity and exported as follows:

[0164]

[0165] To calculate D and First, use one-dimensional Laplacian calculations to compute the gradients in the horizontal, vertical, and two diagonal directions:

[0166]

[0167]

[0168]

[0169]

[0170] where the indices i and j refer to the coordinates of the top-left sample point within the 4×4 block, and R(i,j) indicates the reconstructed sample point at the coordinates (i,j).

[0171] To reduce the complexity of block classification, apply subsampled one-dimensional Laplacian calculations. As Figure 9 shown, the same subsampling positions are used for gradient calculations in all directions.

[0172] Figure 9 Shows an example of the subsampled Laplacian calculation. (a) Subsampling positions for the vertical gradient (b) Subsampling positions for the horizontal gradient (c) Subsampling positions for the diagonal gradient (d) Subsampling positions for the diagonal gradient.

[0173] Then, set the maximum and minimum D values of the gradients in the horizontal and vertical directions to:

[0174]

[0175] Set the maximum and minimum values of the gradients in the two diagonal directions to:

[0176]

[0177] To derive the directional D value, compare these values with each other and use two thresholds t1 and t2:

[0178] Step 1. If are both true, then set D to 0.

[0179] Step 2. If then proceed to Step 3; otherwise, proceed to Step 4.

[0180] Step 3. If then set D to 2; otherwise, set D to 1.

[0181] Step 3. If then D is set to 4; otherwise, D is set to 3.

[0182] The activity value A is calculated as:

[0183]

[0184] A is further quantized to the range from 0 to 4 (including the end values), and the quantized value is denoted as

[0185] For the chrominance components in the picture, the classification method is not applied, that is, a single set of ALF coefficients is applied to each chrominance component.

[0186] 2.8.1.3 Geometric Transformations of Filter Coefficients and Clipping Values

[0187] Before filtering each 4×4 luma block, depending on the gradient value calculated for that block, geometric transformations such as rotation or diagonal and vertical flipping are applied to the filter coefficients f(k, l) and the corresponding filter clipping values c(k, l). This is equivalent to applying these transformations to the points in the filter support region. The idea is to make the different blocks to which ALF is applied more similar by aligning the directionality.

[0188] Three geometric transformations are introduced, including diagonal, vertical flipping, and rotation:

[0189] Diagonal: f D (k, l) = f(l, k), c D (k, l) = c(l, k) (2-9-9)

[0190] Vertical flipping: f V (k, l) = f(k, K-l-1), c V (k, l) = c(k, K-l-1) (2-9-10)

[0191] Rotation: f R (k, l) = f(K-l-1, k), c R (k, l) = c(K-l-1, k) (2-9-11)

[0192] where K is the size of the filter, and 0 ≤ k, l ≤ K-1 are the coefficient coordinates such that the position (0, 0) is in the upper left corner and the position (K-1, K-1) is in the lower right corner. Depending on the gradient value calculated for that block, the transformation is applied to the filter coefficients f(k, l) and the clipping values c(k, l). The following table summarizes the relationship between the transformation and the four gradients in four directions.

[0193] Table 2-5 Mapping of Gradients Calculated for a Block and Transformations

[0194] Gradient value Transformation <![CDATA[g d2 <g d1 and g h <g v > No transformation <![CDATA[g d2 <g d1 and g v <g h > Diagonal <![CDATA[g d1 <g d2 and g h <g v > Vertical flip <![CDATA[g d1 <g d2 and g v <g h > Rotation

[0195] 2.8.1.4 Filter Parameter Signaling

[0196] In VTM5, the ALF filter parameters are signaled in the Adaptive Parameter Set (APS). In one APS, up to 25 sets of luma filter coefficients and clipping value indices, and up to one set of chroma filter coefficients and clipping value indices can be signaled. To reduce the bit overhead, filter coefficients of different classifications can be merged. In the slice header, the index of the APS used for the current slice is signaled.

[0197] The clipping value indices decoded from the APS allow the use of the luma table of clipping values and the chroma table of clipping values to determine the clipping values. These clipping values depend on the internal bit depth. More precisely, the luma table of clipping values and the chroma table of clipping values are obtained by the following formula:

[0198]

[0199] where B is equal to the internal bit depth and N is equal to 4, which is the number of clipping values allowed in VTM5.0.

[0200] The filtering process can be controlled at the CTB level. A flag is always signaled to indicate whether ALF is applied to the luma CTB. The luma CTB can select the filter set from 16 fixed filter sets and the filter set from the APS. The index of the filter set used for the luma CTB is signaled to indicate which filter set is applied. The 16 fixed filter sets are predefined and hard-coded in both the encoder and the decoder.

[0201] The filter coefficients are quantized with a norm equal to 128. To limit the multiplication complexity, bitstream consistency is applied such that the coefficient values at non-central positions should be in the range of -2 7 to 2 7 -1 (including the end values). The central position coefficient is not signaled in the bitstream and is considered equal to 128.

[0202] 2.8.1.5 Filtering Process

[0203] On the decoder side, when ALF is enabled for the CTB, each sample R(i, j) within the CU is filtered to obtain the sample value R′(i, j) as follows,

[0204] R′(i, j) = R(i, j) + ((∑ k≠0 ∑ l≠0(f(k, l) × K(R(i + k, j + l) - R(i, j), c(k, l)) + 64) >> 7) (2 - 9 - 14)

[0205] Among them, f(k, l) represents the decoded filter coefficient, K(x, y) is the clipping function, and c(k, l) represents the decoded clipping parameter. The variables k and l vary between and where L represents the filter length. The clipping function K(x, y) = min(y, max(-y, x)) corresponds to the function Clip3(-y,,).

[0206] 2.8.1.6 Reducing the Virtual Boundary Filtering Process of the Line Buffer

[0207] In VTM5, to reduce the line buffer requirements of ALF, modified block classification and filtering are applied to the samples near the horizontal CTU boundary. For this purpose, the virtual boundary is defined as a line by shifting the horizontal CTU boundary with "N" samples, as Figure 10 shown, where N is equal to 4 for the luminance component and N is equal to 2 for the chrominance component.

[0208] Figure 10 An example of the modified block classification at the virtual boundary is shown.

[0209] As Figure 11 shown, the modified block classification is applied to the luminance component, and the activity value A is scaled accordingly by considering the reduced number of samples used in the one-dimensional Laplacian gradient calculation.

[0210] For the filtering process, symmetric padding operations at the virtual boundary are used for both the luminance and chrominance components. As Figure 11 shown, when the sample to be filtered is below the virtual boundary, the neighboring samples above the virtual boundary are padded. At the same time, the corresponding samples on the other side are also padded symmetrically.

[0211] Figure 11 An example of the modified ALF filtering for the luminance component at the virtual boundary is shown.

[0212] 2.9 Sample Adaptive Offset (SAO)

[0213] The encoder applies Sample Adaptive Offset (SAO) to the reconstructed signal after the deblocking filter by using the offsets specified for each Coding Tree Block (CTB). The HM encoder first decides whether to apply the SAO process to the current slice. If SAO is applied to the slice, each CTB is classified into one of the five SAO types shown in Table 2-6. The concept of SAO is to classify pixels into categories and reduce distortion by adding an offset to the pixels in each category. The SAO operation includes Edge Offset (EO) and Band Offset (BO). The Edge Offset (EO) uses the edge attribute for pixel classification in SAO types 1-4, and the Band Offset (BO) uses the pixel intensity for pixel classification in SAO type 5. Each applicable CTB has SAO parameters, including sao_merge_left_flag, sao_merge_up_flag, SAO type, and four offsets. If sao_merge_left_flag is equal to 1, the current CTB will reuse the SAO type and the offset to the left of the CTB. If sao_merge_up_flag is equal to 1, the current CTB will reuse the SAO type and the offset above the CTB.

[0214] Table 2–6 Specification of SAO Types

[0215] SAO type Sampling point adaptive offset type to be used Category number 0 None 0 1 1D 0-degree pattern edge offset 4 2 1D 90-degree pattern edge offset 4 3 1D 135-degree pattern edge offset 4 4 1D 45-degree pattern edge offset 4 5 With offset 4

[0216] 2.9.1 Operations of Each SAO Type

[0217] The Edge Offset classifies the current pixel p by considering the edge orientation information using four 1-D 3-pixel patterns, as Figure 12 shown. From left to right, they are: 0 degrees, 90 degrees, 135 degrees, and 45 degrees.

[0218] Figure 12 Examples of the four 1-D 3-pixel patterns for pixel classification in EO are shown.

[0219] Each CTB is classified into one of five categories according to Table 2–7.

[0220] Table 2–7 Pixel Classification Rules for EO

[0221] Category Condition Meaning 0 None of the following Mostly monotonic 1 Field p<2 Local minimum 2 p < 1 field && p == 1 field Edge 3 p>1 region && p==1 region Edge 4 p>2 region Local maximum

[0222] The Band Offset (BO) classifies all the pixels in a CTB region into 32 uniform bands by using the five most significant bits of the pixel value as the band index. In other words, the pixel intensity range is divided into 32 equal segments from zero to the maximum intensity value (e.g., 255 for 8-bit pixels). Four adjacent bands are grouped together, and each group is indicated by its leftmost position, asFigure 13 As shown, the encoder searches all positions to obtain a group with the maximum distortion reduction by compensating for the offset of each band.

[0223] Figure 13 An example is shown where four bands are grouped together and represented by their starting band positions.

[0224] 2.10 Combined Inter - and Intra - Prediction (CIIP)

[0225] In VTM5, when coding / decoding a CU in Merge mode, if the CU contains at least 64 luma samples (i.e., the CU width multiplied by the CU height is equal to or greater than 64), and if both the CU width and CU height are less than 128 luma samples, an additional flag is signaled to indicate whether the combined inter / intra - prediction (CIIP) mode is applied to the current CU. As the name implies, CIIP prediction combines the inter - prediction signal with the intra - prediction signal. The inter - prediction signal P inter is derived using the same inter - prediction process as applied to the regular Merge mode; and the intra - prediction signal P intra is derived after the regular intra - prediction process with the planar mode. Then, the intra - and inter - prediction signals are combined using weighted averaging, where the weight values are calculated depending on the coding / decoding modes of the top - neighboring block and the left - neighboring block (as Figure 14 shown) as follows:

[0226] – If the top neighborhood is available and is intra - coded, set isIntraTop to 1, otherwise set isIntraTop to 0;

[0227] – If the left neighborhood is available and is intra - coded, set isIntraLeft to 1, otherwise set isIntraLeft to 0;

[0228] – If (isIntraLeft + isIntraLeft) equals 2, set wt to 3;

[0229] – Otherwise, if (isIntraLeft + isIntraLeft) equals 1, set wt to 2;

[0230] – Otherwise, set wt to 1.

[0231] The CIIP prediction is formed as follows:

[0232] P CIIP = ((4 - wt)*P inter + wt*P intra + 2) >> 2 (3 - 2)

[0233] Figure 14 Shows examples of the top neighborhood block and the left neighborhood block used in CIIP weight derivation.

[0234] 2.11 Luminance Mapping with Chroma Scaling (LMCS)

[0235] In VTM5, before the loop filter, a coding tool called Luminance Mapping with Chroma Scaling (LMCS) is added as a new processing block. LMCS has two main components: 1) Loop mapping of the luminance component based on an adaptive piecewise linear model; 2) For the chroma component, application of chroma residual scaling depending on luminance. Figure 15 The LMCS architecture is shown from the perspective of the decoder. In the Figure 15 block, which includes inverse quantization, inverse transform, intra prediction of luminance, and addition of the luminance prediction and the luminance residual, this processing is applied in the mapping domain. Figure 15 The unshaded blocks in indicate where the processing is applied in the original (i.e., non-mapped) domain; and these include loop filters such as deblocking, ALF, and SAO, motion compensation prediction, intra prediction of chroma, addition of the chroma prediction and the chroma residual, and storing the decoded picture as a reference picture. Figure 15 Shows the new LMCS functional block, including forward mapping and inverse mapping of the luminance signal and the chroma scaling process depending on luminance. Like most other tools in VVC, LMCS can be enabled / disabled at the sequence level using an SPS flag.

[0236] Figure 15 Shows an example of the luminance mapping architecture with chroma scaling.

[0237] 2.12 Dual-Tree Partitioning

[0238] In the current VVC design, for I slices, each CTU can be partitioned into coding units with 64x64 luminance samples using implicit quadtree partitioning, and these coding units are the roots of two separate coding_tree syntax structures for luminance and chroma.

[0239] Since the dual-tree in intra pictures allows different partitions to be applied in the chroma coding tree compared to the luminance coding tree, the dual-tree introduces a longer coding pipeline, and the range of QTBT MinQTSizeC values and MinBtSizeY and MinTTSizeY in the chroma tree allow smaller chroma blocks such as 2x2, 4x2, and 2x4. This poses difficulties for the actual decoder design. In addition, several prediction modes (such as CCLM, planar, and angular modes) require multiplications. To mitigate the above problems, small chroma block sizes (2×2 / 2×4 / 4×2) are restricted as partitioning limits in the dual-tree.

[0240] 2.13 Small Chroma Intra Prediction Unit (SCIPU) in JVET-O0050

[0241] Small chroma sizes are not friendly to hardware implementations. In the dual-tree case, chroma blocks with too small sizes are not allowed. However, in the single-tree case, VVC Draft 5 still allows 2x2, 2x4, and 4x2 chroma blocks. To limit the size of chroma blocks, in a single coding tree, the SCIPU is defined in JVET-O0050 as a coding tree node whose chroma block size is greater than or equal to TH chroma samples and has at least one sub-luma block smaller than 4TH luma samples, where TH is set to 16 in this draft. It is required that in each SCIPU, all CBs are inter-frame or all CBs are non-inter-frame, i.e., intra-frame or IBC. In the case of a non-inter-frame SCIPU, it is further required that the chroma of the non-inter-frame SCIPU should not be further partitioned and the luma of the SCIPU is allowed to be further partitioned. In this way, the smallest chroma intra CB size is 16 chroma samples, and 2x2, 2x4, and 4x2 chroma CBs are removed. Additionally, in the case of a non-inter-frame SCIPU, chroma scaling is not applied.

[0242] Figure 16 Two SCIPU examples are shown. In Figure 16 (a), a chroma CB of 8x4 chroma samples and three luma CBs (4x8, 8x8, 4x8 luma CBs) form a SCIPU because the ternary tree (TT) partitioned from the 8x4 chroma samples will result in a chroma CB smaller than 16 chroma samples. In Figure 16 (b), a chroma CB of 4x4 chroma samples (left side of the 8x4 chroma samples) and three luma CBs (8x4, 4x4, 4x4 luma CBs) form a SCIPU, and another chroma CB of 4x4 samples (right side of the 8x4 chroma samples) and two luma CBs (8x4, 8x4 luma CBs) form a SCIPU because the binary tree (BT) partitioned from the 4x4 chroma samples will result in a chroma CB smaller than 16 chroma samples.

[0243] Figure 16 SCIPU examples are shown.

[0244] If the current slice is an I slice or the current SCIPU has 4x4 luma splitting after being further partitioned once (because 4x4 inter-frame is not allowed in VVC), the type of the SCIPU is inferred as non-inter-frame; otherwise, before parsing the CUs in the SCIPU, the type of the SCIPU (inter-frame or non-inter-frame) is indicated by a signaling notified flag.

[0245] 2.14 Small Chroma Block Constraints in VVC Draft 6

[0246] In VVC Draft 6 (JVET-O2001-vE.docx), the constraints on small chroma blocks are implemented as follows (the relevant parts are marked in bold italics).

[0247]

[0248]

[0249]

[0250]

[0251]

[0252]

[0253] The variable modeTypeCondition is derived as follows:

[0254] – If one of the following conditions is true, set modeTypeCondition to be equal to 0

[0255] – slice_type == I and qtbtt_dual_tree_intra_flag is equal to 1

[0256] – modeTypeCurr is not equal to MODE_TYPE_ALL

[0257] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1

[0258] – cbWidth * cbHeight is equal to 64 and split_qt_flag is equal to 1

[0259] – cbWidth * cbHeight is equal to 64 and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0260] – cbWidth * cbHeight is equal to 32 and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0261] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1 + (slice_type!= I? 1 : 0)

[0262] – The product of cbWidth and cbHeight equals 64, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER

[0263] – The product of cbWidth and cbHeight equals 128, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER

[0264] – Otherwise, set modeTypeCondition to equal 0

[0265] Allowed four - partition process

[0266] The inputs to this process are:

[0267] – The coded - block size cbSize in the luma samples,

[0268] – Multiple types of tree depth mttDepth,

[0269] – The variable treeType, which specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the CTU, and when using a dual tree, specifies whether the current luminance (DUAL_TREE_LUMA) or chrominance component (DUAL_TREE_CHROMA) is being processed,

[0270] – The variable modeType, which specifies whether intra - frame (MODE_INTRA), IBC (MODE_IBC), palette (MODE_PLT), and inter - frame coding modes (MODE_TYPE_ALL) can be used, or only intra - frame, IBC, and palette coding modes (MODE_TYPE_INTRA), or only inter - frame coding modes (MODE_TYPE_INTER) for the coding units inside the coding tree nodes.

[0271] The output of this process is the variable allowSplitQt.

[0272] The variable allowSplitQt is derived as follows:

[0273] – If one or more of the following conditions are true, set allowSplitQt to equal false:

[0274] – The treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, and cbSize is less than or equal to MinQtSizeY

[0275] – The treeType is equal to DUAL_TREE_CHROMA, and cbSize / SubWidthC is less than or equal to MinQtSizeC

[0276] – mttDepth is not equal to 0

[0277] – The treeType is equal to DUAL_TREE_CHROMA, and (cbSize / SubWidthC) is less than or equal to 4

[0278] – The treeType is equal to DUAL_TREE_CHROMA, and modeType is equal to MODE_TYPE_INTRA

[0279] – Otherwise, set allowSplitQt to be equal to true.

[0280] Allowed binary partitioning process

[0281] The inputs to this process are:

[0282] – The binary partitioning mode btSplit,

[0283] – The coded block width cbWidth in the luma samples,

[0284] – The coded block height cbHeight in the luma samples,

[0285] – The position (x0, y0) of the top-left luma sample of the coded block under consideration relative to the top-left luma sample of the picture,

[0286] – The multiple tree depth mttDepth of multiple types,

[0287] – The maximum multiple tree depth maxMttDepth with an offset,

[0288] – The maximum binary tree size maxBtSize,

[0289] – The minimum quadtree size minQtSize,

[0290] – The split index partIdx,

[0291] – A variable treeType that specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the CTU, and when using a dual tree, specifies whether the current luminance (DUAL_TREE_LUMA) or chrominance component (DUAL_TREE_CHROMA) is being processed,

[0292] – A variable modeType that specifies whether intra (MODE_INTRA), IBC (MODE_IBC), palette (MODE_PLT), and inter coding modes (MODE_TYPE_ALL) can be used, or only intra, IBC, and palette coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) for coding units inside the coding tree node.

[0293] The output of this process is the variable allowBtSplit.

[0294] Table 6–2 Regulations of parallelTtSplit and cbSize Based on btSplit

[0295] btSplit == SPLIT_BT_VER btSplit == SPLIT_BT_HOR parallelTtSplit SPLIT_TT_VER SPLIT_TT_HOR cbSize cbWidth cbHeight

[0296] The variables parallelTtSplit and cbSize are derived as specified in Table 6–2.

[0297] The variable allowBtSplit is derived as follows:

[0298] – If one or more of the following conditions are true, then set allowBtSplit to be equal to false:

[0299] – cbSize is less than or equal to MinBtSizeY

[0300] – cbWidth is greater than maxBtSize

[0301] – cbHeight is greater than maxBtSize

[0302] – mttDepth is greater than or equal to maxMttDepth

[0303] – treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0304] – treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA

[0305] – Otherwise, if all of the following conditions are true, set allowBtSplit to be equal to false

[0306] – btSplit is equal to SPLIT_BT_VER

[0307] – y0 + cbHeight is greater than pic_height_in_luma_samples

[0308] – Otherwise, if all of the following conditions are true, set allowBtSplit to be equal to false

[0309] – btSplit is equal to SPLIT_BT_VER

[0310] – cbHeight is greater than MaxTbSizeY

[0311] – x0 + cbWidth is greater than pic_width_in_luma_samples

[0312] – Otherwise, if all of the following conditions are true, set allowBtSplit to be equal to false

[0313] – btSplit is equal to SPLIT_BT_HOR

[0314] – cbWidth is greater than MaxTbSizeY

[0315] – y0 + cbHeight is greater than pic_height_in_luma_samples

[0316] – Otherwise, if all of the following conditions are true, set allowBtSplit to be equal to false

[0317] – x0 + cbWidth is greater than pic_width_in_luma_samples

[0318] – y0 + cbHeight is greater than pic_height_in_luma_samples

[0319] – cbWidth is greater than minQtSize

[0320] – Otherwise, if all of the following conditions are true, set allowBtSplit to be equal to false

[0321] – btSplit is equal to SPLIT_BT_HOR

[0322] – x0 + cbWidth is greater than pic_width_in_luma_samples

[0323] – y0 + cbHeight is less than or equal to pic_height_in_luma_samples

[0324] – Otherwise, if all of the following conditions are true, then set allowBtSplit to be equal to false:

[0325] – mttDepth is greater than 0

[0326] – partIdx is equal to 1

[0327] - MttSplitMode[x0][y0][mttDepth - 1] is equal to parallelTtSplit

[0328] – Otherwise, if all of the following conditions are true, then set allowBtSplit to be equal to false

[0329] – btSplit is equal to SPLIT_BT_VER

[0330] – cbWidth is less than or equal to MaxTbSizeY

[0331] – cbHeight is greater than MaxTbSizeY

[0332] – Otherwise, if all of the following conditions are true, then set allowBtSplit to be equal to false

[0333] – btSplit is equal to SPLIT_BT_HOR

[0334] – cbWidth is greater than MaxTbSizeY

[0335] – cbHeight is less than or equal to MaxTbSizeY

[0336] – Otherwise, set allowBtSplit to be equal to true.

[0337] Allowed ternary partitioning process

[0338] The input to this process is:

[0339] – Ternary partitioning mode ttSplit,

[0340] – Coding / decoding block width cbWidth in luma samples,

[0341] – The coding / decoding block height cbHeight in the luma samples,

[0342] – The position (x0, y0) of the top-left luma sample of the coding / decoding block under consideration relative to the top-left luma sample of the picture,

[0343] – Multiple types of tree depth mttDepth

[0344] – The maximum multiple types of tree depth maxMttDepth with an offset,

[0345] – The maximum ternary tree size maxTtSize,

[0346] – The variable treeType, which specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the CTU, and when using a dual tree, specifies whether the current luminance (DUAL_TREE_LUMA) or chrominance component (DUAL_TREE_CHROMA) is being processed,

[0347] – The variable modeType, which specifies whether intra (MODE_INTRA), IBC (MODE_IBC), palette (MODE_PLT), and inter coding modes (MODE_TYPE_ALL) can be used, or only intra, IBC, and palette coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) can be used for the coding / decoding units inside the coding / decoding tree nodes.

[0348] The output of this process is the variable allowTtSplit.

[0349] Table 6–3 Specification of cbSize based on ttSplit

[0350] ttSplit == SPLIT_TT_VER ttSplit == SPLIT_TT_HOR cbSize cbWidth cbHeight

[0351] The variable cbSize is derived as specified in Table 6–3.

[0352] The variable allowTtSplit is derived as follows:

[0353] – If one or more of the following conditions are true, then set allowTtSplit to be equal to false:

[0354] – cbSize is less than or equal to 2*MinTtSizeY

[0355] – cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0356] – The cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0357] – The mttDepth is greater than or equal to maxMttDepth

[0358] – x0 + cbWidth is greater than pic_width_in_luma_samples

[0359] – y0 + cbHeight is greater than pic_height_in_luma_samples

[0360] – The treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) * (cbHeight / SubHeightC) is less than or equal to 32

[0361] – The treeType is equal to DUAL_TREE_CHROMA, and the modeType is equal to MODE_TYPE_INTRA

[0362] – Otherwise, set allowTtSplit to be equal to true.

[0363] The pred_mode_flag being equal to 0 specifies that the current coding unit is coded in an inter prediction mode. The pred_mode_flag being equal to 1 specifies that the current coding unit is coded in an intra prediction mode.

[0364] When there is no pred_mode_flag, the following inferences are made:

[0365] - If cbWidth is equal to 4 and cbHeight is equal to 4, then infer that pred_mode_flag is equal to 1.

[0366] – Otherwise, if the modeType is equal to MODE_TYPE_INTRA, then infer that pred_mode_flag is equal to 1.

[0367] – Otherwise, if the modeType is equal to MODE_TYPE_INTER, then infer that pred_mode_flag is equal to 0.

[0368] – Otherwise, infer that pred_mode_flag is equal to 1 when decoding an I slice and pred_mode_flag is equal to 0 when decoding a P or B slice, respectively.

[0369] For x = x0..x0+cbWidth-1 and y = y0..y0+cbHeight-1, the variable CuPredMode[chType][x][y] is derived as follows:

[0370] – If pred_mode_flag is equal to 0, set CuPredMode[chType][x][y] to be equal to MODE_INTER.

[0371] – Otherwise (pred_mode_flag is equal to 1), set CuPredMode[chType][x][y] to be equal to MODE_INTRA.

[0372] pred_mode_ibc_flag being equal to 1 indicates that the current coding unit is coded in IBC prediction mode. pred_mode_ibc_flag being equal to 0 indicates that the current coding unit is not coded in IBC prediction mode.

[0373] When there is no pred_mode_ibc_flag, the following inferences are made:

[0374] – If cu_skip_flag[x0][y0] is equal to 1, and cbWidth is equal to 4, and cbHeight is equal to 4, then infer that pred_mode_ibc_flag is equal to 1.

[0375] – Otherwise, if both cbWidth and cbHeight are equal to 128, then infer that pred_mode_ibc_flag is equal to 0.

[0376] – Otherwise, if modeType is equal to MODE_TYPE_INTER, then infer that pred_mode_ibc_flag is equal to 0.

[0377] – Otherwise, if treeType is equal to DUAL_TREE_CHROMA, then infer that pred_mode_ibc_flag is equal to 0.

[0378] – Otherwise, infer that pred_mode_ibc_flag is equal to the value of sps_ibc_enabled_flag when decoding an I slice, and infer that pred_mode_ibc_flag is equal to 0 when decoding a P or B slice.

[0379] When pred_mode_ibc_flag is equal to 1, for x = x0..x0 + cbWidth–1 and y = y0..y0 + cbHeight-1, set the variable CuPredMode[chType][x][y] to be equal to MODE_IBC.

[0380] 3. Problems

[0381] 1. Currently, IBC is regarded as MODE_TYPE_INTRA, and thus small chroma blocks are not allowed, which results in unnecessary loss of coding and decoding efficiency.

[0382] 2. Currently, the palette is regarded as MODE_TYPE_INTRA, and thus small chroma blocks are not allowed, which results in unnecessary loss of coding and decoding efficiency.

[0383] 3. Currently, the small chroma block constraint does not consider the color subsampling format.

[0384] 4. Currently, the same splitting and prediction mode constraints for small blocks are applied to all chroma formats. However, it may be desirable to design different constraint mechanisms for small blocks in 4:2:0 and 4:2:2 chroma formats.

[0385] 5. Currently, the palette mode flag signaling depends on modeType, which is not desirable because the palette may not apply small block constraints.

[0386] 6. Currently, when cu_skip_flag is equal to 1 but MODE_TYPE is equal to MODE_TYPE_INTRA, for P / B stripes, the IBC mode flag is inferred to be 0, which is illegal in syntax parsing.

[0387] 7. Currently, non-4x4 luminance IBC mode is not allowed for SCIPU luminance blocks, which may be undesirable and may result in loss of coding and decoding efficiency.

[0388] 8. 2x H chroma blocks are still allowed, which is not friendly to the hardware implementation.

[0389] 9. Although CIIP uses intra prediction, CIIP is regarded as MODE_INTER, which breaks the constraints in some cases.

[0390] 4. Examples of technical solutions and embodiments

[0391] Those listed below should be regarded as examples. These technologies should not be interpreted narrowly. In addition, these technologies can be combined in any way.

[0392] In this document, an "MxN codec tree node" refers to an M×N block, where M is the block width and N is the block height in the luma samples, which can be further divided, such as by QT / BT / TT. For example, a block can be a QT node or a BT node or a TT node. A codec tree node can be a coding unit (e.g., having three color components for a single tree, two chroma color components for dual-tree chroma coding, and only a luma color component for dual-tree luma coding), or a luma coding block, or a chroma coding block. A "small codec tree node unit" can refer to a codec tree node where the block size MxN in the luma samples is equal to 32 / 64 / 128.

[0393] If not otherwise specified, the width W and height H of a coding block are measured in the luma samples. For example, an MxN coding block refers to an MxN luma block, and / or two (M / SubWidthC)x(N / SubHeightC) chroma blocks, where SubWidthC and SubHeightC are derived from the chroma format as follows.

[0394]

[0395] 1. Whether and / or how to divide into small blocks can depend on the color format.

[0396] a. In one example, for the 4:4:4 color format, the constraints on the chroma block size can follow those for the luma blocks.

[0397] b. In one example, for the 4:2:2 color format, the constraints on the chroma block size can follow those for the 4:2:0 color format.

[0398] c. In one example, for the 4:0:0 and / or 4:4:4 chroma formats, the constraints on small block division and / or prediction mode may not be applied.

[0399] d. In one example, the constraints on small block division and / or prediction mode can be applied differently for different chroma formats.

[0400] i. In one example, for an MxN (such as 8x8) codec tree node with a horizontal BT division, in the 4:2:2 chroma format, horizontal BT division can be allowed for both chroma and luma blocks, while in the 4:2:0 chroma format, horizontal BT division can be allowed for luma blocks but disabled for chroma blocks.

[0401] ii. In one example, for an MxN (such as 16x4) codec tree node with a vertical BT partition, in the 4:2:2 chroma format, vertical BT partitioning can be allowed for both chroma blocks and luma blocks, while in the 4:2:0 chroma format, vertical BT partitioning can be allowed for luma blocks but disabled for chroma blocks.

[0402] iii. In one example, for an MxN (such as 8x16) codec tree node with a horizontal TT partition, in the 4:2:2 chroma format, horizontal TT partitioning can be allowed for both chroma blocks and luma blocks, while in the 4:2:0 chroma format, horizontal TT partitioning can be allowed for luma blocks but disabled for chroma blocks.

[0403] iv. In one example, for an MxN (such as 32x4) codec tree node with a vertical TT partition, in the 4:2:2 chroma format, vertical TT partitioning can be allowed for both chroma blocks and luma blocks, while in the 4:2:0 chroma format, vertical TT partitioning can be allowed for luma blocks but disabled for chroma blocks.

[0404] v. In one example, for the 4:0:0 and / or 4:4:4 color formats, the small block constraint may not be applied.

[0405] e. In one example, whether to enable SCIPU depends on the color format.

[0406] i. In one example, SCIPU is enabled for the 4:2:0 and 4:2:2 color formats.

[0407] ii. In one example, SCIPU is disabled for the 4:0:0 and / or 4:4:4 color formats.

[0408] 2. How to determine the prediction mode (and / or modeType) of the (sub) blocks for a codec tree node

[0409] It can depend on the chroma format.

[0410] a. In one example, if one of the following conditions is true, then for the 4:2:2 chroma format, the modeType of the (sub) blocks split by this codec tree node can be equal to MODE_TYPE_ALL, while for the 4:2:0 chroma format, the modeType can be equal to MODE_TYPE_INTRA or MODE_TYPE_INTER.

[0411] i. An MxN (such as 8x8) codec tree node with a horizontal BT partition

[0412] ii. An MxN (such as 16x4) codec tree node with a vertical BT partition

[0413] iii. MxN (such as 8x16) codec tree nodes with horizontal TT partitioning

[0414] iv. MxN (such as 32x4) codec tree nodes with vertical TT partitioning

[0415] For example, when one of the following conditions is true, modeType can be set to MODE_TYPE_ALL for 4:2:2; while for 4:2:0, modeType must be MODE_TYPE_INTRA or MODE_TYPE_INTER: i) a luminance 8x8 block with horizontal BT, ii) a luminance 16x4 block with vertical BT, iii) a luminance 8x16 block with horizontal TT, iv) a luminance 32x4 block with vertical TT.

[0416] Therefore, for a block with three color components in the codec tree, when one of the above conditions is true, a 4:2:0 block is not classified as MODE_TYPE_ALL (where all codec modes can be selected). It is MODE_TYPE_INTRA (where the block can select palette, intra, or intra block copy) or MODE_TYPE_INTER (where only inter mode can be selected).

[0417] 3. Chroma intra (and / or IBC) blocks with a block width equal to M (such as, M = 2) chroma samples may not be allowed.

[0418] a. In one example, 2xN (such as N ≤ 64) chroma intra blocks may not be allowed in a dual tree.

[0419] i. In one example, when treeType is equal to DUAL_TREE_CHROMA and the block width is equal to 4 chroma samples, vertical BT partitioning can be disabled.

[0420] ii. In one example, when treeType is equal to DUAL_TREE_CHROMA and the block width is equal to 8 chroma samples, vertical TT partitioning can be disabled.

[0421] b. In one example, 2xN (such as N <= 64) chroma intra (and / or IBC) blocks may not be allowed in a single tree.

[0422] i. In one example, for MxN (such as M = 8 and N <= 64) codec tree nodes with vertical BT partitioning, one of the following procedures can be applied.

[0423] 1. For 4xN or 4x(N / 2) chroma blocks, vertical BT partitioning may not be allowed, but for 8xN luminance blocks, vertical BT partitioning may be allowed.

[0424] A 2.4xN or 4x(N / 2) chrominance block may not be vertically BT partitioned and it may be coded or decoded by MODE_INTRA or MODE_IBC.

[0425] 3. For both 8xN luma blocks and 4xN or 4x(N / 2) chrominance blocks, vertical BT partitioning may be allowed, but neither the luma blocks nor the chrominance blocks are coded or decoded by MODE_INTRA (e.g., they may be coded or decoded by MODE_INTER or MODE_IBC).

[0426] ii. In one example, for an M×N (such as M = 16 and N <= 64) coding tree node with a vertical TT partition, one of the following processes may be applied.

[0427] 1. For 8xN or 8x(N / 2) chrominance blocks, vertical TT partitioning may not be allowed, but for 16xN luma blocks, vertical TT partitioning may be allowed.

[0428] 2. An 8xN or 8×(N / 2) chrominance block may not be vertically TT partitioned and is coded or decoded by MODE_INTRA or MODE_IBC.

[0429] 3. For both 16xN luma blocks and 8xN or 8×(N / 2) chrominance blocks, vertical TT partitioning may be allowed, but neither the luma blocks nor the chrominance blocks may be coded or decoded by MODE_INTRA (e.g., they may be coded or decoded by MODE_INTER or MODE_IBC).

[0430] 4. Regardless of whether the luma blocks and / or chrominance blocks are of small block sizes, the IBC mode may be allowed for the luma blocks and / or chrominance blocks.

[0431] a. In one example, for luma blocks - including 8×4 / 8×8 / 16×4 and 4xN (such as N <= 64) luma blocks - the IBC mode may be allowed even if modeType is equal to MODE_TYPE_INTRA.

[0432] b. In one example, for chrominance blocks, the IBC mode may be allowed even if modeType is equal to MODE_TYPE_INTRA.

[0433] 5. The signaling of the IBC prediction mode flag may depend on the prediction mode type (e.g., MODE_TYPE_INTRA).

[0434] a. In one example, when treeType is not equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA, an IBC prediction mode flag for non - SKIP blocks (e.g., coded blocks not coded in skip mode) can be signaled explicitly in the bitstream.

[0435] 6. The IBC prediction mode flag can be inferred depending on the CU SKIP flag and the mode type (e.g., modeType).

[0436] a. In one example, if the current block is coded in skip mode (such as cu_skip_flag equal to 1) and modeType is equal to MODE_TYPE_INTRA, the IBC prediction mode flag (such as pred_mode_ibc_flag) can be inferred to be equal to 1.

[0437] 7. The explicit signaling of the palette mode flag may not depend on modeType.

[0438] a. In one example, regardless of what modeType is, the signaling of the palette mode flag (such as pred_mode_plt_flag) can depend on the slice type, block size, prediction mode, etc.

[0439] b. In one example, when modeType is equal to MODE_TYPE_INTER or MODE_TYPE_INTRA, the palette mode flag (such as pred_mode_plt_flag) is inferred to be 0.

[0440] 8. The IBC mode can be allowed when modeType is equal to MODE_TYPE_INTER

[0441] a. In one example, when modeType is equal to MODE_TYPE_INTRA, chroma IBC may not be allowed.

[0442] b. In one example, when modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER, the IBC mode can be allowed.

[0443] c. In one example, regardless of what modeType is, the IBC mode can be allowed.

[0444] d. In one example, within a SCIPU, both IBC and inter - frame mode can be allowed.

[0445] e. In one example, the size of the IBC chroma block can always correspond to the size of the corresponding luma block.

[0446] f. In one example, when modeType is equal to MODE_TYPE_INTER and the size of the coding / decoding unit in luma is 4x4, signaling of pred_mode_ibc_flag can be skipped and pred_mode_ibc_flag can be inferred to be equal to 1.

[0447] 9. When modeType is MODE_TYPE_INTER, use of the palette mode can be allowed.

[0448] a. In one example, when modeType is MODE_TYPE_INTRA, the chroma palette can be not allowed.

[0449] b. In one example, when modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER, use of the palette mode can be allowed.

[0450] c. In one example, regardless of what modeType is, use of the palette mode can be allowed.

[0451] d. In one example, within a SCIPU, both the palette and the inter mode can be allowed.

[0452] e. In one example, within a SCIPU, all of the palette, IBC, and the inter mode can be allowed.

[0453] f. In one example, the size of the palette chroma block can always correspond to the size of the corresponding luma block.

[0454] g. In one example, when modeType is equal to MODE_TYPE_INTER and the size of the coding / decoding unit in luma is 4x4, signaling of pred_mode_plt_flag can be skipped and pred_mode_plt_flag can be inferred to be equal to 1.

[0455] h. In one example, when modeType is equal to MODE_TYPE_INTER and the size of the coding / decoding unit in luma is 4×4, a message can be sent to indicate whether the current prediction mode is IBC or the palette.

[0456] 10. For small chroma blocks with a width equal to M (e.g., M = 2) or a height equal to N (e.g., N = 2), the allowed intra prediction modes can be restricted to be different from those allowed for large chroma blocks.

[0457] a. In one example, only a subset of the intra prediction modes of the available chrominance intra prediction modes may be used.

[0458] b. In one example, only the INTRA_DC mode may be used.

[0459] c. In one example, only the INTRA_PLANAR mode may be used.

[0460] d. In one example, only the INTRA_ANGULAR18 mode may be used.

[0461] e. In one example, only the INTRA_ANGULAR50 mode may be used.

[0462] f. In one example, the CCLM mode may not be allowed.

[0463] 11. For small chrominance blocks with a width equal to M (e.g., M = 2) or a height equal to N (e.g., N = 2), the transform type may be restricted to be different from the transform types allowed for large chrominance blocks.

[0464] a. In one example, only transform skip may be used.

[0465] b. In one example, only one-dimensional transforms may be used.

[0466] c. In one example, codec tools that support multiple types of transforms are not allowed.

[0467] i. Alternatively, signaling of codec tools that support multiple types of transforms may be omitted.

[0468] 12. CIIP may be regarded as MODE_TYPE_INTRA.

[0469] a. In one example, when using dual-tree segmentation, the CIIP mode may be allowed.

[0470] i. In one example, when the CU type is DUAL_TREEE_CHROMA, the CIIP mode may be allowed.

[0471] b. Alternatively, CIIP may be regarded as MODE_TYPE_INTER

[0472] i. In one example, when the chrominance block width is equal to M (e.g., M = 2), the CIIP mode may not be allowed.

[0473] ii. In one example, when the chrominance block width is equal to M (e.g., M = 2), the intra prediction modes for chrominance in CIIP may be restricted to simple intra prediction modes.

[0474] 1. In one example, when the chroma block width is equal to M (e.g., M = 2), INTRA_DC can be used for chroma intra prediction.

[0475] 2. In one example, when the chroma block width is equal to M (e.g., M = 2), INTRA_ANGULAR18 can be used for chroma intra prediction.

[0476] 3. In one example, when the chroma block width is equal to M (e.g., M = 2), INTRA_ANGULAR50 can be used for chroma intra prediction.

[0477] iii. In one example, the intra prediction modes for chroma in CIIP can be restricted to simple intra prediction modes.

[0478] 1. In one example, INTRA_DC can be used for chroma intra prediction.

[0479] 2. In one example, the INTRA_ANGULAR18 mode can be used for chroma intra prediction.

[0480] 3. In one example, the INTRA_ANGULAR50 mode can be used for chroma intra prediction.

[0481] 13. For the above bullet points, the variables M and / or N can be predefined or signaled.

[0482] a. In one example, M and / or N can further depend on the color format (e.g., 4:2:0, 4:2:2, 4:4:4).

[0483] 5. Embodiments

[0484] The newly added parts are highlighted in bold and italic, and the parts deleted from the VVC working draft are marked with double brackets (e.g., [[a]] means deleting the character 'a'). The modifications are based on the latest VVC working draft (JVET - O2001 - v11)

[0485] 5.1 Example Embodiment #1

[0486] The following embodiments relate to: the constraints on small block splitting and prediction modes are only applied to 4:2:0 and 4:4:4 chroma formats (not applied to 4:0:0 and 4:4:4 chroma formats).

[0487] 7.4.9.4 Coding Tree Semantics

[0488] The variable modeTypeCondition is derived as follows:

[0489] – Set modeTypeCondition equal to 0 if one of the following conditions is true

[0490] – slice_type == I and qtbtt_dual_tree_intra_flag equals 1

[0491] – modeTypeCurr is not equal to MODE_TYPE_ALL

[0492] – chroma_format_idc equals 0

[0493] – chroma_format_idc equals 3

[0494] – Otherwise, set modeTypeCondition equal to 1 if one of the following conditions is true

[0495] – cbWidth * cbHeight equals 64 and split_qt_flag equals 1

[0496] – cbWidth * cbHeight equals 64 and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER

[0497] – cbWidth * cbHeight equals 32 and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER

[0498] – Otherwise, set modeTypeCondition equal to 1+(slice_type!= I? 1 : 0) if one of the following conditions is true

[0499] – cbWidth * cbHeight equals 64 and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER

[0500] – cbWidth * cbHeight equals 128 and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER

[0501] – Otherwise, set modeTypeCondition equal to 0

[0502] 5.2 Example Embodiment #2

[0503] The following embodiment relates to: signaling of the palette mode flag does not depend on modeType.

[0504] 7.3.8.5 Coding and Decoding Unit Syntax

[0505]

[0506]

[0507] 5.3 Example Embodiment #3

[0508] The following embodiment relates to: inferring the IBC prediction mode flag depending on the CU SKIP flag and modeType.

[0509] pred_mode_ibc_flag being equal to 1 specifies that the current coding and decoding unit is coded in the IBC prediction mode. pred_mode_ibc_flag being equal to 0 specifies that the current coding and decoding unit is not coded in the IBC prediction mode.

[0510] When pred_mode_ibc_flag does not exist, the inference is as follows:

[0511] – If cu_skip_flag[x0][y0] is equal to 1, and cbWidth is equal to 4, and cbHeight is equal to 4, then infer that pred_mode_ibc_flag is equal to 1.

[0512] – Otherwise, if both cbWidth and cbHeight are equal to 128, then infer that pred_mode_ibc_flag is equal to 0.

[0513] – Otherwise, if cu_skip_flag[x0][y0] is equal to 1, and modeType is equal to MODE_TYPE_INTRA, then infer that pred_mode_ibc_flag is equal to 1.

[0514] – Otherwise, if modeType is equal to MODE_TYPE_INTER, then infer that pred_mode_ibc_flag is equal to 0.

[0515] – Otherwise, if treeType is equal to DUAL_TREE_CHROMA, then infer that pred_mode_ibc_flag is equal to 0.

[0516] – Otherwise, infer that pred_mode_ibc_flag is equal to the value of sps_ibc_enabled_flag when decoding an I slice, and infer that pred_mode_ibc_flag is equal to 0 when decoding a P or B slice.

[0517] When pred_mode_ibc_flag is equal to 1, for x = x0..x0 + cbWidth – 1 and y = y0..y0 + cbHeight - 1, set the variable CuPredMode[chType][x][y] to be equal to MODE_IBC.

[0518] 5.4 Example embodiment #4

[0519] The following embodiment relates to: the signaling of the IBC prediction mode flag depends on MODE_TYPE_INTRA, and / or allows the IBC mode for luma blocks regardless of whether the luma blocks are of small block size.

[0520] 7.3.8.5 Coding and decoding unit syntax

[0521]

[0522]

[0523] 5.5 Example embodiment #5

[0524] The following embodiment relates to: applying different intra block constraints for 4:2:0 and 4:2:2 color formats.

[0525] 7.4.9.4 Coding tree semantics

[0526] The variable modeTypeCondition is derived as follows:

[0527] – If one of the following conditions is true, set modeTypeCondition to be equal to 0

[0528] – slice_type == I, and qtbtt_dual_tree_intra_flag is equal to 1

[0529] – modeTypeCurr is not equal to MODE_TYPE_ALL

[0530] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1

[0531] – cbWidth * cbHeight is equal to 64, and split_qt_flag is equal to 1

[0532] – cbWidth * cbHeight equals 64, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER

[0533] – cbWidth * cbHeight equals 32, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER

[0534] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1 + (slice_type!= I? 1 : 0)

[0535] – cbWidth * cbHeight equals 64, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER, and chroma_format_idc equals 1

[0536] – cbWidth * cbHeight equals 128, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER, and chroma_format_idc equals 1

[0537] – cbWidth equals 8, and cbHeight equals 8, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_VER, and chroma_format_idc equals 2

[0538] – cbWidth equals 4, and cbHeight equals 16, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR, and chroma_format_idc equals 2

[0539] – cbWidth equals 16, and cbHeight equals 8, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_VER, and chroma_format_idc equals 2

[0540] – cbWidth is equal to 4, and cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR, and chroma_format_idc is equal to 2

[0541] – Otherwise, set modeTypeCondition to be equal to 0

[0542] 5.6 Example Embodiment #6

[0543] The following embodiment relates to: 2×N chroma intra blocks are not allowed in a single tree.

[0544] 7.4.9.4 Coding and Decoding Tree Semantics

[0545] The variable modeTypeCondition is derived as follows:

[0546] – If one of the following conditions is true, set modeTypeCondition to be equal to 0

[0547] – slice_type == I, and qtbtt_dual_tree_intra_flag is equal to 1

[0548] – modeTypeCurr is not equal to MODE_TYPE_ALL

[0549] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1

[0550] – cbWidth * cbHeight is equal to 64, and split_qt_flag is equal to 1

[0551] – cbWidth * cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0552] – cbWidth * cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0553] – Otherwise, if one of the following conditions is true, set modeTypeCondition to be equal to 1+(slice_type!= I? 1 : 0)

[0554] – cbWidth * cbHeight equals 64, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_HOR or SPLIT_BT_VER

[0555] – cbWidth * cbHeight equals 128, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_HOR or SPLIT_TT_VER

[0556] – cbWidth equals 8, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_BT_VER

[0557] – cbWidth equals 16, and MttSplitMode[x0][y0][mttDepth] equals SPLIT_TT_VER

[0558] – Otherwise, set modeTypeCondition to be equal to 0

[0559] 5.7 Example Embodiment #7

[0560] The following embodiment relates to: not allowing 2×N chroma intra-blocks in a dual tree.

[0561] 6.4.2 Allowed Binary Partitioning Processes

[0562] The variable allowBtSplit is derived as follows:

[0563] – If one or more of the following conditions are true, set allowBtSplit to be equal to false:

[0564] – cbSize is less than or equal to MinBtSizeY

[0565] – cbWidth is greater than maxBtSize

[0566] – cbHeight is greater than maxBtSize

[0567] – mttDepth is greater than or equal to maxMttDepth

[0568] – treeType equals DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) * (cbHeight / SubHeightC) is less than or equal to 16

[0569] – btSplit is equal to SPLIT_BT_VER, and treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) is less than or equal to 4

[0570] – treeType is equal to DUAL_TREE_CHROMA, and modeType is equal to MODE_TYPE_INTRA

[0571] …

[0572] 6.4.3 Allowed ternary partitioning process

[0573] The variable allowTtSplit is derived as follows:

[0574] – If one or more of the following conditions are true, then set allowTtSplit to be equal to false:

[0575] – cbSize is less than or equal to 2 * MinTtSizeY

[0576] – cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0577] – cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0578] – mttDepth is greater than or equal to maxMttDepth

[0579] – x0 + cbWidth is greater than pic_width_in_luma_samples

[0580] – y0 + cbHeight is greater than pic_height_in_luma_samples

[0581] – treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) * (cbHeight / SubHeightC) is less than or equal to 32

[0582] – btSplit is equal to SPLIT_TT_VER, and treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) is less than or equal to 8

[0583] – treeType is equal to DUAL_TREE_CHROMA, and modeType is equal to MODE_TYPE_INTRA

[0584] – Otherwise, set allowTtSplit equal to true.

[0585] 5.8 Example embodiment #8

[0586] The following embodiment relates to enabling MODE_IBC for SCIPU chrominance blocks.

[0587] 7.3.8.5 Coding and decoding unit syntax

[0588]

[0589]

[0590] Figure 17A is a block diagram of a video processing apparatus 1700. The apparatus 1700 can be used to implement one or more of the methods described herein. The apparatus 1700 can be implemented in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. The apparatus 1700 can include one or more processors 1702, one or more memories 1704, and video processing hardware 1706. The (one or more) processors 1702 can be configured to implement one or more of the methods described in this document. The (one or more) memories 1704 can be used to store data and code for implementing the methods and techniques described herein. The video processing hardware 1706 can be used to implement some of the techniques described in this document in hardware circuitry. In some embodiments, the hardware 1706 can be at least partially or fully included within the processor 1702 (e.g., a graphics coprocessor).

[0591] Figure 17B is another example of a block diagram of a video processing system in which the disclosed techniques can be implemented. Figure 17B is a block diagram showing an example video processing system 1710 in which various techniques disclosed herein can be implemented. Various implementations can include some or all components of the system 1710. The system 1710 can include an input 1712 for receiving video content. The video content can be received in a raw or uncompressed format (e.g., 8- or 10-bit multi-component pixel values), or it can be received in a compressed or encoded format. The input 1712 can represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces (such as Ethernet, Passive Optical Network (PON), etc.) and wireless interfaces (such as Wi-Fi or cellular interfaces).

[0592] System 1710 may include a codec component 1714 that may implement various codec or encoding methods described herein. The codec component 1714 may reduce the average bit rate of the video from the input 1712 of the codec component 1714 to the output to produce a coded representation of the video. Thus, codec techniques are sometimes referred to as video compression or video transcoding techniques. As shown by component 1716, the output of the codec component 1714 may be stored or transmitted via the connected communication. The stored or transmitted bitstream (or coded) representation of the video received at the input 1712 may be used by component 1718 to generate pixel values or a displayable video that is sent to the display interface 1720. The process of generating a user-visible video from the bitstream representation is sometimes referred to as video decompression. Additionally, although some video processing operations are referred to as "codec" operations or tools, it should be understood that codec tools or operations are used at the encoder and corresponding decoding tools or operations that reverse the codec results will be performed by the decoder.

[0593] Examples of a peripheral bus interface or a display interface may include a Universal Serial Bus (USB), a High-Definition Multimedia Interface (HDMI), or a Displayport, etc. Examples of a storage interface include Serial Advanced Technology Attachment (SATA), PCI, an IDE interface, etc. The techniques described in this document may be implemented in various electronic devices such as a mobile phone, a laptop computer, a smartphone, or other devices capable of performing digital data processing and / or video display.

[0594] Figure 18 is a flowchart of a method 1800 for processing video. The method 1800 includes: 1802, for the conversion between a video region of a video and a coded representation of the video region, parsing the coded representation according to a syntax rule that defines a relationship between a chroma block size and a color format of the video region; 1804, performing the conversion by executing the parsing according to the syntax rule.

[0595] Figure 21A is a flowchart of a method 2110 for processing video. The method 2110 includes, at step 2112, determining a segmentation scheme for segmenting a chroma video region of the video into one or more chroma blocks based on a rule according to a color format of the video. The method 2110 further includes, at step 2114, performing a conversion between the video and a coded representation of the video according to the segmentation scheme.

[0596] Figure 21BIt is a flowchart of a method 2120 for processing video. The method 2120 includes, at step 2122, determining a prediction mode or prediction type for sub-blocks of a coding tree node for the video based on the color format of the video. The method 2120 also includes, at step 2124, performing a conversion between the video and a coded representation of the video based on the determination. In some implementations, the coding tree node is split into multiple sub-blocks for coding in the coded representation.

[0597] Figure 22A It is a flowchart of a method 2210 for processing video. The method 2210 includes, at step 2212, performing a conversion between the video and a coded representation of the video. In some implementations, the conversion between the video and the coded representation is performed according to a rule, where the video includes one or more video regions each including one or more luma blocks and one or more chroma components, and where the rule specifies that an intra mode or an intra block copy mode is not allowed to represent a chroma block having a size of MxN in the coded representation among one or more chroma blocks, where M and N are integers indicating the width and height of the chroma block respectively, where the intra mode includes encoding the chroma block based on a previously encoded or reconstructed video block, and where the intra block copy mode includes encoding the chroma block using at least a block vector pointing to a video frame including the video region.

[0598] In some implementations, a conversion is performed between a chroma block of the video and a coded representation of the video, where an intra coding mode is used to represent the chroma block in the coded representation according to a size rule; where the size rule specifies that, in a case where the width of the chroma block is equal to M or the height of the chroma block is equal to N, where M and N are integers, the intra coding mode is from a first set of intra coding mode types; otherwise, the intra coding mode is from a second set of intra coding mode types.

[0599] In some implementations, a conversion is performed between a chroma block of the video and a coded representation of the video, where a transform type is used to represent the chroma block in the coded representation according to a rule, where the rule specifies that, in a case where the width of the chroma block is equal to M or the height of the chroma block is equal to N, where M and N are integers, the transform type is from a first set of transform types; otherwise, the transform type is from a second set of transform types.

[0600] In some implementations, a conversion is performed between a video and an encoded / decoded representation of the video according to rules, where the video includes a video region having one or more luma blocks and one or more chroma blocks, and where the rules specify that the use of the Intra Block Copy (IBC) mode can be used for one or more luma blocks and one or more chroma blocks having a block size of MxN, for all values of M and N, where M and N are integers; and where, using the IBC mode, at least a block vector pointing to a video frame containing the video block is used to encode the video block.

[0601] In some implementations, a conversion is performed between a video block of a video and an encoded / decoded representation of the video block, where the encoded / decoded representation conforms to formatting rules, where the formatting rules specify that a syntax element indicating the use of the Inter Block Copy (IBC) mode is selectively included in the encoded / decoded representation based on the mode type of the video block, and where the IBC mode includes at least using a block vector pointing to a video frame containing the video block to encode the video block.

[0602] In some implementations, a conversion is performed between a video block of a video and an encoded / decoded representation of the video block, where the encoded / decoded representation conforms to formatting rules, where the formatting rules specify that a syntax element indicating the use of a palette mode is included in the encoded / decoded representation regardless of the mode type of the video block, and where the palette mode includes encoding the video block using a palette of representative sample values.

[0603] Figure 22B is a flowchart of a method 2220 for processing video. Method 2220 includes, at step 2222, determining, according to rules, to use a Combined Inter and Intra Prediction (CIIP) mode as an intra mode or an inter mode for the conversion between a video region of a video and an encoded / decoded representation of the video. Method 2220 also includes performing the conversion at step 2224 based on the determination. The CIIP mode includes using weighting coefficients to combine an intra prediction signal and an inter prediction signal.

[0604] Figure 23A is a flowchart of a method 2310 for processing video. Method 2310 includes, at step 2312, determining, based on rules, that the use of the Inter Block Copy (IBC) mode is permitted for a video region for the conversion between the video region of the video and an encoded / decoded representation of the video. Method 2310 also includes, at step 2314, performing the conversion based on the determination. The IBC mode includes at least using a block vector pointing to a video frame containing the video region to encode the video region.

[0605] Figure 23BIt is a flowchart of a method 2320 for processing video. The method 2320 includes, at step 2322, determining whether to permit the use of a palette mode for a video region based on rules for the conversion between the video region of the video and the codec representation of the video. The method 2320 also includes, at step 2324, performing the conversion based on the determination. In some implementations, the rules are based on the codec mode type of the video region or the color type of the video region, and wherein the palette mode includes encoding the video region using a palette of representative sample values.

[0606] Some embodiments of the disclosed technology include deciding or determining to enable a video processing tool or mode. In an example, when a video processing tool or mode is enabled, the encoder will use or implement the tool or mode in the processing of video blocks, but not necessarily modify the resulting bitstream based on the use of the tool or mode. In other words, the conversion from a video block to the bitstream representation of the video will use the video processing tool or mode when it is decided or determined to enable the video processing tool or mode. In another example, when a video processing tool or mode is enabled, the decoder will process the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. In other words, the conversion from the bitstream representation of the video to video blocks will be performed using the video processing tool or mode enabled based on the decision or determination.

[0607] Some embodiments of the disclosed technology include deciding or determining to disable a video processing tool or mode. In an example, when a video processing tool or mode is disabled, the encoder will not use the tool or mode in the conversion from a video block to the bitstream representation of the video. In another example, when a video processing tool or mode is disabled, the decoder will process the bitstream knowing that the bitstream has not been modified using the video processing tool or mode that was disabled based on the decision or determination.

[0608] In this document, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from the pixel representation of a video to the corresponding bitstream representation, and vice versa. As defined by the syntax, the bitstream representation of the current video block may, for example, correspond to bits that are juxtaposed or scattered at different positions within the bitstream. For example, a macroblock may be encoded according to transform and codec error residual values and also using bits in the header and other fields in the bitstream.

[0609] The following clauses describe some embodiments and techniques. The first set of clauses describes certain features and aspects of the technology disclosed in the previous sections.

[0610] 1. A method for video processing, comprising: for the conversion between a video region of a video and the codec representation of the video region, parsing the codec representation according to a syntax rule that defines the relationship between the chrominance block size and the color format of the video region; and performing the conversion by performing the parsing according to the syntax rule.

[0611] 2. The method according to clause 1, wherein the color format is 4:4:4, and wherein the syntax rule specifies that the chrominance block is subject to the same size constraints as those for the luminance block.

[0612] 3. The method according to clause 1, wherein the color format is 4:2:2, and wherein the syntax rule specifies that the chrominance block is subject to the same size constraints as those for the 4:2:0 color format.

[0613] 4. The method according to any one of clauses 1-3, wherein the syntax specifies the use of prediction modes and small block partitioning in a manner that depends on the chrominance format.

[0614] 5. The method according to clause 1, wherein the syntax rule defines a minimum allowable size feature for the conversion of the video region based on the color format of the video region.

[0615] The following clauses can be implemented together with the additional techniques described in item 2 of the previous section.

[0616] 6. A method for video processing, comprising: determining a codec mode of a codec tree node of the video based on an attribute of the video and the chrominance format of the video; and using the determined codec mode to perform a conversion between the codec representation of the video and the video blocks of the codec tree node.

[0617] 7. The method according to clause 6, wherein, when the attribute is as follows, for the chrominance format of 4:2:2, the codec mode is determined to be MODE_TYPE_ALL, and for the chrominance format of 4:2:0, the codec mode is determined to be MODE_TYPE_INTRA or MODE_TYPE_INTER:

[0618] i. The codec node is an MxN codec tree node with a horizontal binary tree partition;

[0619] ii. The codec node is an MxN codec tree node with a vertical binary tree partition;

[0620] iii. The codec node is an MxN codec tree node with a horizontal ternary tree partition; or

[0621] iv. The encoding / decoding node is an MxN encoding / decoding tree node with a vertical ternary tree partition.

[0622] 8. The method according to clause 7, wherein M = 8 or 16 or 32, and N = 4 or 8 or 16.

[0623] The following clauses can be implemented together with the additional techniques described in item 3 of the previous section.

[0624] 9. A method for video processing, comprising: determining whether a chrominance block of a certain size is allowed in a video region of a video based on a rule; and performing a conversion between the video region and an encoded / decoded representation of the video region based on the determination.

[0625] 10. The method according to clause 9, wherein the rule specifies that 2xN chrominance blocks are not allowed because the video region includes a dual-tree split.

[0626] 11. The method according to clause 9, wherein the rule specifies that 2N chrominance blocks are not allowed because the video region includes a single-tree split.

[0627] 12. The method according to clause 10 or 11, wherein N ≤ 64.

[0628] The following clauses can be implemented together with the additional techniques described in items 4, 8, and 9 of the previous section.

[0629] 13. A method for video processing, comprising: determining an encoding / decoding mode allowed for a video region based on a rule that allows an encoding / decoding mode for video conditions; and performing a conversion between an encoded / decoded representation of pixels in the video region and the pixels in the video region based on the determination.

[0630] 14. The method according to clause 13, wherein the video condition is a block size, and wherein the rule allows the intra-block copy mode for small block size luminance blocks.

[0631] 15. The method according to clause 14, wherein the small block size includes 8x4, 8x8, 16x4, or 4xN luminance block sizes.

[0632] 16. The method according to clause 13, wherein the rule allows the intra-block copy mode for the conversion of the video region encoded / decoded using the MODE_TYPE_INTER mode.

[0633] 17. The method according to clause 13, wherein the rule allows the palette encoding / decoding mode for the conversion of the video region encoded / decoded using the MODE_TYPE_INTER mode.

[0634] The following clauses can be implemented together with the additional techniques described in Items 5, 6, and 7 of the previous section.

[0635] 18. A method for video processing, comprising: converting between a video block of a video and a decoded representation of the video block using a video codec mode, wherein a syntax element signaling the codec mode is selectively included in the decoded representation based on a rule.

[0636] 19. The method according to Clause 18, wherein the video codec mode is an intra block decoding mode, and wherein the rule specifies using the type of the video codec mode to control inclusion of the syntax element in the decoded representation.

[0637] 20. The method according to Clause 19, wherein the rule specifies explicit signaling of non-SKIP blocks.

[0638] 21. The method according to Clause 18, wherein the rule specifies implicit signaling of an intra block copy flag based on a mode type of the video block and a skip mode.

[0639] 22. The method according to Clause 18, wherein the codec mode is a palette decoding mode, and wherein the rule specifies selectively including a palette decoding indicator based on a mode type of the video block.

[0640] The following clauses can be implemented together with the additional techniques described in Item 11 of the previous section.

[0641] 23. A method for video processing, comprising: determining that a transform type used during conversion between a chrominance block and a decoded representation of the chrominance block is different from a transform type used for conversion of a corresponding luma block because the chrominance block has a size smaller than a threshold size; and performing the conversion based on the determination.

[0642] 24. The method according to Clause 23, wherein the threshold size is MxN, where M is 2 or N is 2.

[0643] The following clauses can be implemented together with the additional techniques described in Item 12 of the previous section.

[0644] 25. The method according to any one of Clauses 1 to 24, wherein the conversion uses a combined inter and intra prediction mode as the MODE_TYPE_INTRA mode.

[0645] 26. The method according to any one of clauses 18 to 22, wherein the conversion uses a combined inter - and intra - prediction mode as the MODE_TYPE_INTER mode. For example, when CIIP is regarded as MODE_TYPE_INTER, the methods described in items 5 + 6 + 7 of the previous section can be applied. Or, when the methods described in items 5 + 6 + 7 are applied, CIIP can be regarded as MODE_TYPE_INTER.

[0646] 27. The method according to any one of clauses 1 to 26, wherein the conversion includes encoding the video into the codec representation.

[0647] 28. The method according to any one of clauses 1 to 26, wherein the conversion includes decoding the codec representation to generate pixel values of the video.

[0648] 29. A video decoding apparatus, comprising a processor configured to implement one or more of the methods described in clauses 1 to 28.

[0649] 30. A video encoding apparatus, comprising a processor configured to implement one or more of the methods described in clauses 1 to 28.

[0650] 31. A computer program product having computer code stored thereon, which when executed by a processor causes the processor to implement the method according to any one of clauses 1 to 28.

[0651] 32. The method, apparatus or system described in this document.

[0652] The second set of clauses describes certain features and aspects of the techniques disclosed in the previous section, for example, example implementations 1, 2, and 13.

[0653] 1. A method for video processing, comprising: determining a segmentation scheme for dividing a chrominance video region of a video into one or more chrominance blocks based on a rule according to a color format of the video; and performing a conversion between the video and a codec representation of the video according to the segmentation scheme.

[0654] 2. The method according to clause 1, wherein the rule specifies that for an inter - strip or an intra - strip, three color components are represented by the same codec tree node.

[0655] 3. The method according to clause 1 or 2, wherein the rule specifies that for a 4:4:4 color format, the same segmentation scheme is used for chrominance blocks and luminance blocks.

[0656] 4. The method according to clause 1 or 2, wherein the rule specifies the same splitting constraint for 4:2:0 and 4:2:2 color formats.

[0657] 5. The method according to clause 1 or 2, wherein the rule specifies a splitting scheme and / or constraint for which the prediction mode is not applied for 4:0:0 or 4:4:4 color formats.

[0658] 6. The method according to any one of clauses 1 or 2, wherein the rule specifies applying the splitting scheme and / or prediction mode based on the color format of the video.

[0659] 7. The method according to clause 6, wherein for an M×N codec tree node having a horizontal BT (binary tree) partition or a horizontal TT (ternary tree) partition, in 4:2:2 color format, the horizontal BT partition or the horizontal TT partition is allowed for both the chrominance block and the luminance block.

[0660] 8. The method according to clause 6, wherein for an M×N codec tree node having a horizontal BT (binary tree) partition or a horizontal TT (ternary tree) partition, in 4:2:0 color format, the horizontal BT partition or the horizontal TT (ternary tree) partition is allowed for the luminance block but not for the chrominance block.

[0661] 9. The method according to clause 6, wherein for an MxN codec tree node having a vertical BT (binary tree) partition or a vertical TT (ternary tree) partition, in 4:2:2 color format, the vertical BT partition or the vertical TT partition is allowed for both the chrominance block and the luminance block.

[0662] 10. The method according to clause 6, wherein for an MxN codec tree node having a vertical BT (binary tree) partition or a vertical TT (ternary tree) partition, in 4:2:0 color format, the vertical BT partition or the vertical TT (ternary tree) partition is allowed for the luminance block but not for the chrominance block.

[0663] 11. The method according to any one of clauses 7-10, wherein M and / or N is predefined or signaled.

[0664] 12. The method according to clause 11, wherein M and / or N depends on the color format of the video region.

[0665] 13. The method according to clause 6, wherein the rule specifies not applying the splitting scheme to 4:0:0 and / or 4:4:4 color formats.

[0666] 14. The method according to clause 1, wherein the rule specifies a minimum chrominance intra prediction unit (SCIPU) that defines the size of chrominance blocks for enabling the conversion based on the color format of the video.

[0667] 15. The method according to clause 14, wherein a minimum chrominance intra prediction unit is allowed for 4:2:0 and / or 4:2:2 color formats.

[0668] 16. The method according to clause 14, wherein a minimum chrominance intra prediction unit is not allowed for 4:0:0 and / or 4:4:4 color formats.

[0669] 17. A method for video processing, comprising: determining a prediction mode or a prediction type for sub - blocks of a coding tree node for the video based on the color format of the video; and performing a conversion between the video and a coded representation of the video based on the determination, wherein the coding tree node is split into the sub - blocks for coding in the coded representation.

[0670] 18. The method according to clause 17, wherein, since the color format is 4:2:2, the prediction mode of the sub - blocks is determined as MODE_TYPE_ALL, which indicates the applicability of inter - coding mode, intra mode, palette mode, and intra - block copy mode.

[0671] 19. The method according to clause 17, wherein, since the color format is 4:2:0, the prediction mode of the sub - blocks is determined as i) MODE_TYPE_INTER, which only indicates the applicability of the inter - coding mode, or ii) MODE_TYPE_INTRA, which indicates the applicability of the intra mode, palette mode, and intra - block copy mode.

[0672] 20. The method according to clause 18 or 19, wherein the inter - coding mode includes using temporal correlation to represent or reconstruct the video, the inter mode includes representing or reconstructing the video based on previously processed video blocks, the palette mode includes representing or reconstructing the video using a palette of representative sample values, or the intra - block copy mode includes representing or reconstructing the video using at least a block vector pointing to a video frame.

[0673] 21. The method according to any one of clauses 18 to 20, wherein the codec tree node satisfies one of the following conditions: i) the codec tree node corresponds to an 8x8 luma block having a horizontal binary tree partition, ii) the codec tree node corresponds to a 16x4 luma block having a vertical binary tree partition, iii) the codec tree node corresponds to an 8x16 luma block having a horizontal ternary tree partition, or iv) the codec tree node corresponds to a 32x4 luma block having a vertical ternary tree partition.

[0674] 22. The method according to clause 17, wherein the codec tree node is an M×N codec tree node, and M and / or N are predefined or signaled.

[0675] 23. The method according to clause 22, wherein M and / or N depend on the color format of the video.

[0676] 24. The method according to any one of clauses 1 to 23, wherein performing the conversion includes generating the codec representation from the video.

[0677] 25. The method according to any one of clauses 1 to 23, wherein performing the conversion includes generating the video from the codec representation.

[0678] 26. A video processing apparatus, comprising a processor configured to implement the method according to any one or more of clauses 1 to 25.

[0679] 27. A computer-readable medium storing program code, which when executed causes a processor to implement the method according to any one or more of clauses 1 to 25.

[0680] The third set of clauses describes certain features and aspects of the techniques disclosed in the previous sections, e.g., example implementations 3 and 10 - 13.

[0681] 1. A method for video processing, comprising: converting between a video and a codec representation of the video according to a rule, the video including one or more video regions each including one or more luma blocks and one or more chroma blocks; wherein the rule specifies that an intra mode or an intra block copy mode is not allowed to represent a chroma block of size MxN in the one or more chroma blocks in the codec representation, where M and N are integers indicating the width and height of the chroma block, respectively; wherein the intra mode includes encoding the chroma block based on previously encoded or reconstructed video blocks, and wherein the intra block copy mode includes encoding the chroma block using at least a block vector pointing to a video frame including the video region.

[0682] 2. The method according to clause 1, wherein the rule specifies that chrominance blocks of size 2×N are not allowed due to the video region being partitioned into a dual-tree partition.

[0683] 3. The method according to clause 2, wherein the rule specifies that vertical BT (binary tree) partitioning is disabled for the chrominance blocks in the following cases: i) the tree type of the chrominance block is equal to the dual-tree type, and ii) M is equal to 4 chrominance samples.

[0684] 4. The method according to clause 2, wherein the rule specifies that vertical TT (ternary tree) partitioning is disabled for the chrominance blocks in the following cases: i) the tree type of the chrominance block is equal to the dual-tree type, and ii) M is equal to 8 chrominance samples.

[0685] 5. The method according to clause 1, wherein the rule specifies that chrominance blocks of size 2×N are not allowed due to the video region being partitioned into a single-tree partition.

[0686] 6. The method according to clause 5, wherein for an M×N codec tree node with vertical BT (binary tree) partitioning, the vertical BT partitioning is not allowed for the chrominance blocks of size 4×N or 4x(N / 2), but is allowed for the luma blocks of size 8xN.

[0687] 7. The method according to clause 5, wherein for an MxN codec tree node with vertical BT (binary tree) partitioning, the vertical BT partitioning is not allowed for the chrominance blocks of size 4xN or 4x(N / 2).

[0688] 8. The method according to clause 5, wherein for an MxN codec tree node with vertical BT (binary tree) partitioning, the vertical BT partitioning is allowed for the chrominance blocks of size 4xN or 4x(N / 2) and the luma blocks of size 8×N, and wherein the chrominance blocks and the luma blocks are not coded in the intra mode.

[0689] 9. The method according to clause 5, wherein for an MxN codec tree node with vertical TT (ternary tree) partitioning, the vertical TT partitioning is not allowed for the chrominance blocks of size 8xN or 8x(N / 2), but is allowed for the luma blocks of size 16xN.

[0690] 10. The method according to clause 5, wherein for an MxN codec tree node with vertical TT (ternary tree) partitioning, the vertical TT partitioning is not allowed for the chrominance blocks of size 8xN or 8x(N / 2).

[0691] 11. The method according to clause 5, wherein for an MxN codec tree node with a vertical TT (trinary tree) partition, the vertical TT partition is allowed for the chrominance blocks of size 8xN or 8x(N / 2) and the luma blocks of size 16×N, and wherein the chrominance blocks and the luma blocks are not coded or decoded in the intra mode.

[0692] 12. A method for video processing, comprising: determining, according to a rule, to use a combined inter and intra prediction (CIIP) mode as an intra mode or an inter mode for the conversion between a video region of a video and a coded or decoded representation of the video; and performing the conversion based on the determination, and wherein the CIIP mode includes using a weighting coefficient to combine an intra prediction signal and an inter prediction signal.

[0693] 13. The method according to clause 12, wherein the rule specifies using the CIIP mode as the intra mode due to the use of a double-tree segmentation in the video region.

[0694] 14. The method according to clause 12, wherein the rule specifies using the CIIP mode as the inter mode.

[0695] 15. The method according to clause 14, wherein the rule specifies disabling the CIIP mode due to the chrominance block width being equal to M.

[0696] 16. The method according to clause 12, wherein the rule specifies restricting the intra prediction mode for the chrominance blocks to be coded or decoded in the CIIP mode to the intra mode.

[0697] 17. The method according to clause 16, wherein the intra prediction mode includes intra_DC, intra_angular18 mode or intra_angular50 mode.

[0698] 18. The method according to clause 16, wherein the chrominance block width is equal to 2.

[0699] 19. A method for video processing, comprising: converting between chrominance blocks of a video and a coded or decoded representation of the video, wherein an intra coding or decoding mode is used to represent the chrominance blocks in the coded or decoded representation according to a size rule; wherein the size rule specifies that in the case where the width of the chrominance block is equal to M or the height of the chrominance block is equal to N, where M and N are integers, the intra coding or decoding mode is from a first set of intra coding or decoding mode types; otherwise, the intra coding or decoding mode is from a second set of intra coding or decoding mode types.

[0700] 20. The method according to clause 19, wherein M = 2 or N = 2.

[0701] 21. The method according to clause 19 or 20, wherein the first set of intra coding / decoding mode types is a subset of all allowed intra coding / decoding mode types in the transformation.

[0702] 22. The method according to clause 19 or 20, wherein the first set of intra coding / decoding mode types corresponds to the INTRA_DC mode.

[0703] 23. The method according to clause 19 or 20, wherein the first set of intra coding / decoding mode types corresponds to the INTRA_PLANAR mode.

[0704] 24. The method according to clause 19 or 20, wherein the first set of intra coding / decoding mode types corresponds to the INTRA_ANGULAR18 mode.

[0705] 25. The method according to clause 19 or 20, wherein the first set of intra coding / decoding mode types corresponds to the INTRA_ANGULAR50 mode.

[0706] 26. The method according to clause 19 or 20, wherein the rule specifies that the CCLM mode is not allowed, and the CCLM mode uses a linear mode to derive a prediction value of a chrominance component from another component.

[0707] 27. A method for video processing, comprising: performing a transformation between a chrominance block of a video and a coded / decoded representation of the video, wherein the chrominance block is represented in the coded / decoded representation using a transform type according to a rule; wherein the rule specifies that: when the width of the chrominance block is equal to M or the height of the chrominance block is equal to N, where M and N are integers, the transform type is from a first set of transform types; otherwise, the transform type is from a second set of transform types.

[0708] 28. The method according to clause 27, wherein M is 2 or N is 2.

[0709] 29. The method according to any one of clauses 1 - 11, 15, 19 - 28, wherein M and / or N are predefined or signaled.

[0710] 30. The method according to clause 29, wherein M and / or N depend on the color format of the video region.

[0711] 31. The method according to any one of clauses 1 to 30, wherein the transformation includes encoding the video into the coded / decoded representation.

[0712] 32. The method according to any one of clauses 1 to 30, wherein the conversion includes decoding the codec representation to generate the video.

[0713] 33. A video processing apparatus, comprising a processor configured to implement the method according to any one or more of clauses 1 to 32.

[0714] 34. A computer-readable medium storing program code, which when executed causes a processor to implement the method according to any one or more of clauses 1 to 32.

[0715] The fourth set of clauses describes certain features and aspects of the techniques disclosed in the previous sections, for example, example implementations 4-9 and 13.

[0716] 1. A method for video processing, comprising: converting between a video and a codec representation of the video according to a rule, the video including a video region having one or more luminance blocks and one or more chrominance blocks, wherein the rule specifies that the use of the intra block copy (IBC) mode can be used for the one or more luminance blocks and the one or more chrominance blocks having a block size of MxN, for all values of M and N, where M and N are integers; wherein, using the IBC mode, at least a block vector pointing to a video frame containing the video block is used to encode and decode the video block.

[0717] 2. The method according to clause 1, wherein the rule specifies that the size of the luminance block is 8×4, 8×8, 16×4 or 4×N.

[0718] 3. The method according to clause 2, wherein the luminance block has a mode type equal to MODE_TYPE_INTRA, and MODE_TYPE_INTRA indicates the applicability of the intra mode, the IBC mode, and the palette mode.

[0719] 4. The method according to clause 1, wherein the rule specifies that the chrominance block has a mode type equal to MODE_TYPE_INTRA, and MODE_TYPE_INTRA indicates the applicability of the intra mode, the IBC mode, and the palette mode.

[0720] 5. A method for video processing, comprising: converting between a video block of a video and a codec representation of the video block, wherein the codec representation conforms to a formatting rule, wherein the formatting rule specifies that a syntax element indicating the use of the inter block copy (IBC) mode is selectively included in the codec representation based on the mode type of the video block, and wherein the IBC mode includes encoding the video block using at least a block vector pointing to a video frame containing the video block.

[0721] 6. The method according to clause 5, wherein the formatting rule specifies that when the tree type of the video block is not equal to DUAL_TREE_CHROMA and the mode type of the video block is equal to the MODE_TYPE_INTRA, where the MODE_TYPE_INTRA indicates the applicability of the intra mode, the IBC mode, and the palette mode, the syntax elements of the video block encoded and decoded in a non-skip mode are signaled explicitly.

[0722] 7. The method according to clause 5, wherein the formatting rule specifies that the syntax elements are inferred based on the mode type and skip flag of the video block.

[0723] 8. The method according to clause 7, wherein the formatting rule specifies that when the mode type of the video block is equal to MODE_TYPE_INTRA, where the MODE_TYPE_INTRA indicates the applicability of the intra mode, the IBC mode, and the palette mode, for the video block encoded and decoded in a skip mode, the inferred syntax elements are equal to 1.

[0724] 9. A method for video processing, comprising: converting between a video block of a video and an encoded and decoded representation of the video block, wherein the encoded and decoded representation conforms to a formatting rule, wherein the formatting rule specifies that regardless of the mode type of the video block, a syntax element indicating the use of the palette mode is included in the encoded and decoded representation, and wherein the palette mode includes encoding the video block using a palette of representative sample values.

[0725] 10. The method according to clause 9, wherein the formatting rule specifies the explicit signaling based on at least one of the slice type, block size, or prediction mode of the video block.

[0726] 11. The method according to clause 9, wherein the formatting rule specifies that when the mode type of the video block is equal to the MODE_TYPE_INTER or the MODE_TYPE_INTRA, where the MODE_TYPE_INTER only indicates the applicability of the inter-frame encoding mode, and the MODE_TYPE_INTRA indicates the applicability of the intra mode, the IBC mode, and the palette mode, the inferred syntax elements are equal to 0.

[0727] 12. A method for video processing, comprising: for the conversion between a video region of a video and an encoded / decoded representation of the video, determining, based on a rule, that the use of the inter-block copy (IBC) mode is permitted for the video region; and performing the conversion based on the determination, wherein the IBC mode includes at least encoding the video region using a block vector pointing to a video frame containing the video region.

[0728] 13. The method according to clause 12, wherein the rule specifies that the IBC mode is permitted when the mode type of the video region is equal to MODE_TYPE_INTER, where MODE_TYPE_INTER only indicates the applicability of the inter-frame encoding / decoding mode.

[0729] 14. The method according to clause 12, wherein the rule specifies that when the mode type of the video region is equal to MODE_TYPE_INTRA, where MODE_TYPE_INTRA indicates the applicability of the intra-frame mode, the IBC mode, and the palette mode, the IBC mode is not permitted for chrominance blocks.

[0730] 15. The method according to clause 12, wherein the rule specifies that when the mode type is equal to MODE_TYPE_INTER or MODE_TYPE_INTRA, where MODE_TYPE_INTER only indicates the applicability of the inter-frame encoding / decoding mode, and MODE_TYPE_INTRA indicates the applicability of the intra-frame encoding / decoding mode, the IBC mode, and the palette mode, the IBC mode is permitted.

[0731] 16. The method according to clause 12, wherein the rule specifies that the IBC mode is permitted independent of the mode type of the video region.

[0732] 17. The method according to clause 12, wherein the IBC mode and the inter-frame mode are permitted within a smallest chrominance intra-prediction unit (SCIPU) defined as restricting the size of chrominance blocks.

[0733] 18. The method according to clause 12, wherein a chrominance block encoded / decoded using the IBC mode has a size corresponding to the size of the luminance block corresponding to the chrominance block.

[0734] 19. The method according to clause 12, wherein, when the mode type of the video region is equal to MODE_TYPE_INTER and the video region corresponds to a 4x4 luma block, where MODE_TYPE_INTER only indicates the applicability of the inter-frame coding mode, signaling of syntax elements indicating the use of the IBC mode is skipped, and it is inferred that the syntax element is equal to 1.

[0735] 20. A method for video processing, comprising: for the conversion between a video region of a video and the coded representation of the video, determining whether to permit the use of a palette mode for the video region based on a rule; and performing the conversion based on the determination, wherein the rule is based on the coding mode type of the video region or the color type of the video region; wherein the palette mode includes encoding the video region using a palette of representative sample values.

[0736] 21. The method according to clause 20, wherein the rule specifies that when the mode type of the video region is equal to MODE_TYPE_INTER, where MODE_TYPE_INTER only indicates the applicability of the inter-frame coding mode, the palette mode is permitted.

[0737] 22. The method according to clause 20, wherein the rule specifies that when the mode type of the video region is equal to MODE_TYPE_INTRA, where MODE_TYPE_INTRA indicates the applicability of the intra-frame mode, the IBC mode, and the palette mode, the palette mode is not permitted for chrominance blocks, and wherein the IBC mode includes encoding the video region using at least a block vector pointing to a video frame containing the video region.

[0738] 23. The method according to clause 20, wherein the rule specifies that when the mode type is equal to MODE_TYPE_INTER or MODE_TYPE_INTRA, where MODE_TYPE_INTER only indicates the applicability of the inter-frame coding mode, and MODE_TYPE_INTRA indicates the applicability of the intra-frame mode, the IBC mode, and the palette mode, the palette mode is permitted, and wherein the IBC mode includes encoding the video region using at least a block vector pointing to a video frame containing the video region.

[0739] 24. The method according to clause 20, wherein the rule specifies that the palette mode is permitted independent of the mode type of the video region.

[0740] 25. The method according to clause 20, wherein the palette mode and the inter mode are allowed within a smallest chroma frame prediction unit (SCIPU) defined as restricting the size of a chroma block.

[0741] 26. The method according to clause 20, wherein all of the palette mode, the IBC mode, and the inter mode are allowed within a smallest chroma frame prediction unit (SCIPU) defined as restricting the size of a chroma block, and the IBC mode includes encoding the video region using at least a block vector pointing to a video frame containing the video region.

[0742] 27. The method according to clause 20, wherein a chroma block encoded or decoded using the palette mode has a size corresponding to the size of a luma block corresponding to the chroma block.

[0743] 28. The method according to clause 20, wherein when the mode type of the video region is equal to MODE_TYPE_INTER and the video region corresponds to a 4x4 luma block, where MODE_TYPE_INTER only indicates the applicability of the inter encoding / decoding mode, signaling of a syntax element indicating the use of the palette mode is skipped, and the syntax element is inferred to be equal to 1.

[0744] 29. The method according to clause 20, wherein a syntax element indicating the use of the palette mode or the IBC mode is included in the encoded / decoded representation when: 1) the mode type of the video region is equal to MODE_TYPE_INTER, and MODE_TYPE_INTER only indicates the applicability of the inter encoding / decoding mode; 2) the video region corresponds to a 4x4 luma block, and the IBC mode includes encoding the video region using at least a block vector pointing to a video frame containing the video region.

[0745] 30. The method according to any one of clauses 1 - 4, wherein M and / or N are predefined or signaled.

[0746] 31. The method according to clause 30, wherein M and / or N depend on the color format of the video region.

[0747] 32. The method according to any one of clauses 1 to 31, wherein performing the conversion includes generating the encoded / decoded representation from the video.

[0748] 33. The method according to any one of clauses 1 to 31, wherein performing the conversion includes generating the video from the encoded / decoded representation.

[0749] 34. A video processing apparatus includes a processor configured to implement the method according to any one or more of clauses 1 to 33.

[0750] 35. A computer-readable medium storing program code, which when executed, causes a processor to implement the method according to any one or more of clauses 1 to 33.

[0751] The disclosed and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware (including the structures disclosed in this document and their structural equivalents), or in a combination of one or more of them. The disclosed and other embodiments can 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 execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" includes all apparatus, devices, and machines for processing data, including, for example, programmable processors, computers, or multiple processors or computers. In addition to hardware, the apparatus can include code that creates an execution environment for the computer programs being discussed, e.g., code constituting processor firmware, protocol stacks, database management systems, operating systems, and combinations of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0752] A computer program (also referred to as 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 a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. The program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts in a markup language document), in a single file dedicated to the program being discussed, or in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to be executed on one or more computers, which are located at one site or distributed across multiple sites and interconnected by a communication network.

[0753] The processes and logical flows described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be executed by dedicated logic circuitry, and the apparatus can also be implemented as dedicated logic circuitry, e.g., an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0754] For example, processors suitable for executing computer programs include any one or more processors of general and special microprocessors, as well as any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing the instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, e.g., magnetic disks, magneto-optical disks, or optical disks, or be operatively coupled to one or more mass storage devices to receive data therefrom, or transfer data thereto, or both. 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, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, dedicated logic circuitry.

[0755] Although this patent document contains many details, it should not be construed as limiting any subject matter or the scope of what is claimed, but rather as a description of features of particular embodiments of a particular technology. Certain features that are described in the context of separate embodiments in this patent document can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented separately in multiple embodiments, or in any suitable sub-combination. Moreover, although features may be described as acting in certain combinations, and even initially claimed as such, in some cases, one or more features from a claimed combination can be removed from the combination, and the claimed combination can be directed to a sub-combination or a variant of a sub-combination.

[0756] Similarly, although operations are described in the figures in a particular order, this should not be understood to mean that the operations must be performed in the particular order shown or in sequential order to achieve the desired result, or that all illustrated operations must be performed. Additionally, the separation of various system components in the embodiments described in this patent document should not be understood to mean that such separation is required in all embodiments.

[0757] Only some implementation manners and examples are described, and other implementation manners, enhancements and variations can be made based on the content described and illustrated in this patent document.

Claims

1. A method for processing video data, comprising: For the conversion between the codec tree nodes of a video and the bitstream of the video, determining, according to rules, a luminance mother block and a chrominance mother block for partitioning the codec tree nodes, and a scheme for predicting one or more luminance blocks from the luminance mother block and one or more chrominance blocks from the chrominance mother block, wherein the luminance mother block is generated from a luminance codec tree block based on a luminance segmentation scheme including a recursive segmentation operation, and the chrominance mother block is generated from a chrominance codec tree block based on a chrominance segmentation scheme having the same recursive segmentation operation as the luminance segmentation scheme; and Performing the conversion based on the scheme, wherein the rules specify that in a single tree, when the luminance mother block has a width equal to 8 luminance samples and the chrominance mother block has a width equal to 4 chrominance samples, in the case where the mode type of the chrominance mother block is MODE_TYPE_INTRA, vertical BT (binary tree) partitioning is disabled for the chrominance mother block and enabled for the luminance mother block; the rules further specify that in a single tree, when the luminance mother block has a width equal to 8 luminance samples and the chrominance mother block has a width equal to 4 chrominance samples, in the case where the mode type of the chrominance mother block is not MODE_TYPE_INTRA, vertical BT partitioning is enabled for both the chrominance mother block and the luminance mother block; wherein MODE_TYPE_INTRA indicates the applicability of the intra mode, palette mode, and intra block copy mode; wherein the rules specify that chrominance blocks applying a third prediction mode are restricted to having a width greater than or equal to 4, in which an intra prediction signal and an inter prediction signal are combined by coefficients to generate a prediction signal.

2. The method according to claim 1, wherein The rules specify that chrominance blocks applying a first prediction mode or a second prediction mode among the one or more chrominance blocks are restricted to having a width greater than two chrominance samples, wherein the first prediction mode is an intra codec mode, and in the second prediction mode, prediction samples are derived from a video block of sample values of the same picture determined by a block vector; The second prediction mode is an intra block copy (IBC) mode.

3. The method according to claim 1, wherein The rules specify that when the tree type of the chrominance block is equal to the dual tree type, the chrominance block is restricted to having a width greater than two chrominance samples.

4. The method according to claim 3, wherein The rules specify that in the case where the tree type of the chrominance mother block is equal to the dual tree type and the width of the chrominance mother block is equal to 4 chrominance samples, vertical BT (binary tree) partitioning is disabled for the chrominance mother block.

5. The method according to claim 3, wherein, The rules specify that in the case where the tree type of the chrominance mother block is equal to the dual tree type and the width of the chrominance mother block is equal to 8 chrominance samples, vertical TT (ternary tree) partitioning is disabled for the chrominance mother block.

6. The method according to claim 1, wherein, The rule specifies that when the luminance master block has a width equal to 16 luminance samples and the chrominance master block has a width equal to 8 chrominance samples, in the case where the mode type of the chrominance master block is MODE_TYPE_INTRA, the vertical TT (ternary tree) partitioning is disabled for the chrominance master block and enabled for the luminance master block. Where MODE_TYPE_INTRA indicates the applicability of the intra mode, palette mode, and intra block copy mode.

7. The method according to claim 1, wherein The rule specifies that when the luminance master block has a width equal to 16 luminance samples and the chrominance master block has a width equal to 8 chrominance samples, in the case where the mode type of the chrominance master block is not MODE_TYPE_INTRA, the vertical TT (ternary tree) partitioning is enabled for both the chrominance master block and the luminance master block. Where MODE_TYPE_INTRA indicates the applicability of the intra mode, palette mode, and intra block copy mode.

8. The method according to claim 1, wherein The rule specifies that the intra prediction signal in the third prediction mode is derived based on the planar mode.

9. The method according to claim 1, wherein The transformation includes encoding the video into the bitstream.

10. The method according to claim 1, wherein, The transformation includes decoding the video from the bitstream.

11. A device for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein, When executed by the processor, the instruction causes the processor to: For the transformation between the codec tree node of the video and the bitstream of the video, determine, according to the rule, the luminance master block and the chrominance master block for partitioning the codec tree node, and the scheme for predicting one or more luminance blocks from the luminance master block and one or more chrominance blocks from the chrominance master block, where the luminance master block is generated from the luminance codec tree block based on a luminance partitioning scheme including a recursive splitting operation, and the chrominance master block is generated from the chrominance codec tree block based on a chrominance partitioning scheme having the same recursive splitting operation as the luminance partitioning scheme; and Perform the transformation based on the scheme. Where the rule specifies that in a single tree, when the luminance master block has a width equal to 8 luminance samples and the chrominance master block has a width equal to 4 chrominance samples, in the case where the mode type of the chrominance master block is MODE_TYPE_INTRA, the vertical BT (binary tree) partitioning is disabled for the chrominance master block and enabled for the luminance master block; the rule further specifies that in a single tree, when the luminance master block has a width equal to 8 luminance samples and the chrominance master block has a width equal to 4 chrominance samples, in the case where the mode type of the chrominance master block is not MODE_TYPE_INTRA, the vertical BT partitioning is enabled for both the chrominance master block and the luminance master block. Where MODE_TYPE_INTRA indicates the applicability of the intra mode, palette mode, and intra block copy mode. Where the rule specifies that the chrominance block to which the third prediction mode is applied is restricted to have a width greater than or equal to 4, in the third prediction mode, the intra prediction signal and the inter prediction signal are combined by coefficients to generate the prediction signal.

12. The device according to claim 11, wherein, The rule specifies that when the tree type of the chrominance block is equal to the dual-tree type, the chrominance block is restricted to have a width greater than two chrominance samples.

13. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the following: For the conversion between the codec tree nodes of a video and the bitstream of the video, rules are used to determine the luminance mother block and the chrominance mother block for partitioning the codec tree nodes, and a scheme for predicting one or more luminance blocks from the luminance mother block and one or more chrominance blocks from the chrominance mother block, wherein, The luma parent block is generated from a luma coding tree block based on a luma splitting scheme including a recursive splitting operation, and the chroma parent block is generated from a chroma coding tree block based on a chroma splitting scheme having the same recursive splitting operation as the luma splitting scheme; and perform the conversion based on the scheme, wherein the rule specifies that in a single tree, when the luma parent block has a width equal to 8 luma samples and the chroma parent block has a width equal to 4 chroma samples, in the case where the mode type of the chroma parent block is MODE_TYPE_INTRA, vertical BT (binary tree) partitioning is disabled for the chroma parent block and enabled for the luma parent block; the rule further specifies that in a single tree, when the luma parent block has a width equal to 8 luma samples and the chroma parent block has a width equal to 4 chroma samples, in the case where the mode type of the chroma parent block is not MODE_TYPE_INTRA, vertical BT partitioning is enabled for both the chroma parent block and the luma parent block; where MODE_TYPE_INTRA indicates the applicability of the intra mode, palette mode, and intra block copy mode; wherein the rule specifies that a chrominance block to which a third prediction mode is applied is restricted to have a width greater than or equal to 4, in the third prediction mode, an intra prediction signal and an inter prediction signal are combined by coefficients to generate a prediction signal.

14. A method for storing a bitstream of video, comprising: For a coding tree node of video, determine, according to a rule, a luma parent block for partitioning the coding tree node and a chroma parent block for partitioning the coding tree node, and a scheme for predicting one or more luma blocks from the luma parent block and one or more chroma blocks from the chroma parent block, wherein the luma parent block is generated from a luma coding tree block based on a luma splitting scheme including a recursive splitting operation, and the chroma parent block is generated from a chroma coding tree block based on a chroma splitting scheme having the same recursive splitting operation as the luma splitting scheme; and generate the bitstream based on the scheme, store the bitstream in a non-transitory computer-readable storage medium, Among them, the rule specifies that in a single tree, when the luma mother block has a width equal to 8 luma samples and the chroma mother block has a width equal to 4 chroma samples, in the case where the mode type of the chroma mother block is MODE_TYPE_INTRA, vertical BT (binary tree) partitioning is disabled for the chroma mother block and enabled for the luma mother block; the rule further specifies that in a single tree, when the luma mother block has a width equal to 8 luma samples and the chroma mother block has a width equal to 4 chroma samples, in the case where the mode type of the chroma mother block is not MODE_TYPE_INTRA, vertical BT partitioning is enabled for both the chroma mother block and the luma mother block; Among them, MODE_TYPE_INTRA indicates the applicability of the intra-frame mode, palette mode, and intra-block copy mode; Among them, the rule specifies that the chroma block to which the third prediction mode is applied is limited to have a width greater than or equal to 4, in the third prediction mode, the intra-frame prediction signal and the inter-frame prediction signal are combined by coefficients to generate a prediction signal.

15. A video processing apparatus, including a processor configured to implement the method according to any one of claims 2, 4 to 10.

16. A computer-readable medium storing program code, the program code when executed causes a processor to implement the method according to any one of claims 2 to 10.

Images